[Spice-devel] Streaming video performance concepts

[John A. Sullivan III]

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?

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