[Spice-devel] Streaming video performance concepts

[Alon Levy]

On Tue, Jun 21, 2011 at 11:46:59PM -0400, John A. Sullivan III wrote:
> On Wed, 2011-06-22 at 01:46 +0200, Alon Levy wrote:
> > On Tue, Jun 21, 2011 at 07:33:58PM -0400, John A. Sullivan III wrote:
> > > Hello, all.  This isn't a critical question so please do not take lots
> > > of time to answer it unless it would be a helpful general discussion.
> > > We are still trying to properly set our expectations about video
> > > streaming using SPICE on low bandwidth networks.  Indeed, this is our
> > > principle interest in SPICE for Linux as NX still seems considerably
> > > faster for general screen updates.  In Windows, SPICE does seem to be a
> > > bit faster than RDP although the way in which it responds is noticeably
> > > different.  The common advantage on both platforms is the possibility of
> > > video.
> > > 
> > > Let's take the case of streaming video; by this I mean something like
> > > watching YouTube videos as opposed to playing a locally stored video
> > > file.  If I play this streaming video on my physical desktop browser, I
> > > assume it is using some sort of lossy codec and is probably doing a good
> > > job of saturating say my 2Mbps DSL or cable connection and performance
> > > is adequate.
> > > 
> > > I am assuming from reading the SPICE documentation (still reading!) that
> > > the beauty of SPICE is that it will detect a rapidly changing screen
> > > area, assume it is video and transmit it using a lossy codec.  So, I
> > > assume, when I open that YouTube video in my browser on my SPICE
> > > desktop, I assume, will also do a pretty good job of saturating my 2Mbps
> > > connection (I confess I've not yet done a packet trace to actually
> > > measure it) with a lossy codec and would expect similar results.
> > > 
> > > Since both videos are saturating the 2Mbps pipe and both are using
> > > similar(?) lossy codecs, why is the performance so much worse via SPICE
> > > than streaming it locally? Is it strictly a lack of buffering? Is there
> > > something else we can tweak? Or have we fundamentally misunderstood the
> > > protocol and have highly unrealistic expectations? Thanks - John
> > > 
> > by both you mean flv vs. the mjpeg we use? if so then the answer is simply
> > that the flv is compressed much better then our mjpeg. mainly because we
> > don't have the cpu to throw at it, we need to do it at realtime. The root
> > of the problem is why uncompress to recompress immediately, and the answer
> > is because flash is closed of course. For youtube specifically we could
> > probably have some specific solution. Implementing Video Acceleration (
> > DirectDraw in windows) may help.
> > 
> > ><snip>
> Thank you very much for the explanation.  It's pretty much what I
> expected - that the codec is different, trading CPU efficiency for
> bandwidth inefficiency and I certainly understand the reasons why.
> 
> Is there any thought or plan to make the codec configurable for those
> who are willing to sacrifice CPU for bandwidth, e.g., VP8, Theora, or
> H.264?
> 

I haven't done any testing on this but I think the cpu requirements are large.
maybe with hardware doing the encoding this would work well enough. Technically
just dropping in a different codec and extending the protocol doesn't sound like
a lot of work. Patches welcome?

> Sorry to be so focused on such a narrow subject but it is becoming the
> principle marketing differentiator for us (as you can tell, I'm more on
> the management side than the technical side!) and so we are quite
> interested in the current plans for improving low bandwidth video if any
> - John
>