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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
