Bug 36186

Summary: Video playback with client on host vs client on remote
Product: Spice Reporter: gvenkat
Component: spicec (deprecated)Assignee: Spice Bug List <spice-bugs>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description gvenkat 2011-04-12 14:43:57 UTC
In my latest set up, I am noticing a serious problem in flash playback in a browser when the guest is displayed on the host itself or from a remote machine using spice client. The problem occurs with both 0.6 and 0.8 versions (and all combinations of them) of spice.

When seen from a remote client, the flash playback is very good even in full screen mode. But when spice client is run on the host itself, the flash video playback is extremely bad and in full screen mode unusable.

Since there are many. many variables here that could cause this and I am not sure how kvm, libvirt, spice all play together, I will be happy to provide more information to anyone who knows which of them could make a difference. 

Some obvious info:

OpenSuSE 11.4 linux on server (64-bit), Ubuntu 10.10 on client (32-bit). Guest OS is Windows XP with SP3 (32 bit).

I have eliminated poor graphics subsystem as a reason on the host. It has excellent graphics integrated (i7 2600k cpu, much better than the client which is an old generation Mac Mini) and the host is not even close to being loaded in CPU. Looking at the same video on the host using VNC shows typical VNC problems but usable (without audio) but the SPICE version is really bad. It is just the opposite when the very same session is switched to the client (simply by starting the client on the remote which drops the local spice client and continues playing the video on the desktop). The VNC version is inadequate on the remote as we all know but the SPICE version is very usable. This seems very strange and I am trying to figure out where the bottleneck is when spice client is local. Audio works fine in both cases.

Has anyone else done this experiment of running the same video with host local and remote invocations of the spice client to see if there is a significant difference? If anything, I would have expected better performance locally than at the remote.

Other info: This problem is much less with HTML5 videos it seems but I am not sure this problem is with Flash.

I am hoping that this is some configuration issue with Spice based on the different versions of things involved than a design/bug with Spice that gets triggered running on the host.

Do let me know if there are things I can try and report.

Thanks
Comment 1 gvenkat 2011-05-11 02:10:32 UTC
Just want to update to say that this problem was solved by increasing the memory for the video card for the guest VM to 64MB from the default 9MB provided by virt-manager. This has nothing to do with host or client per se but the monitor resolutions used on client and host which sets the video requirements. In my case, the host happened to have a much bigger and high resolution screen so the memory allocated to the video card has to be higher. Eventually qxl on Windows will crash with just 9MB.

Many people using virt-manager will be unaware of this as the GUI assigns 9MB and there is no way to change that in the GUI of virt-manager.

This should be mentioned in the FAQ in the wiki to help people trying this out.
Comment 2 Christophe Fergeau 2011-05-11 02:43:26 UTC
This has been discussed here http://thread.gmane.org/gmane.comp.emulators.spice.devel/3868 and is now fixed in virt-manager. Leaving this bug open since I don't know how to proceed about adding this to the FAQ.
Comment 3 Marc-Andre Lureau 2011-06-16 06:58:53 UTC
(In reply to comment #2)
> This has been discussed here
> http://thread.gmane.org/gmane.comp.emulators.spice.devel/3868 and is now fixed
> in virt-manager. Leaving this bug open since I don't know how to proceed about
> adding this to the FAQ.

added a link to the FAQ: http://spice-space.org/page/FAQ

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.