[Spice-devel] Streaming video performance concepts

[Alon Levy]

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.

> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel