Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Brad Wilson]

Ok, so I installed the AC97 audio drivers to fix my audio device in the guest 
vm.  Using Virt-Viewer with qxl, the video streaming has improved and I am 
seeing closer to 1.5Mbps network traffic now when watching hd videos but the 
quality is still suffering a bit.  What I would like to know is if there is a 
way to allow the spice protocol to use more bandwidth in order to increase 
video quality and frame rate.  In windows RDP you can set the quality to be 
super high which gives a much nicer video experience at the cost of about 
15Mbps... I am curious if Spice or Virt-Viewer have such a setting? And just to 
be clear, I can get near native quality using rdp to this same VM. 
Thanks,Brad

  From: Victor Toso 
 To: Francois Gouget  
Cc: Frediano Ziglio ; Spice Devel 
; Brad Wilson 
 Sent: Saturday, October 15, 2016 10:26 AM
 Subject: Re: [Spice-devel] Very poor video performance using Virt Viewer 
compared to RDP
   
Hi!

On Fri, Oct 14, 2016 at 04:55:35PM +0200, Francois Gouget wrote:
> On Thu, 13 Oct 2016, Frediano Ziglio wrote:
> [...]
> > I discovered where the main lag came quite by "accident". To test
> > I used one small utility and this utility don't have a way to change
> > parameters (like bandwidth) so knowing how the tcp work I stopped
> > the utility and started again as fast as I can with different
> > parameters. This of course create packets loss and some delay but
> > the connection works fine as tcp retransmit the packets lost.
> > But surprisingly the delay introduced by this accident was maintained
> > in the video! I then removed all Virgl stuff, tried again with a video
> > and the lag is still present. Also interrupting the utility and
> > starting again was increasing the lag (I managed to have about
> > 3 seconds lag!).
> >
> > Now... I have a patch for the client but as I said I'm not familiar
> > with the client too much and it's really terrible. It mainly remove
> > the synchronization with the audio (with still lags) and play the
> > video as fast as possible. By the way, I think is time to send as
> > someone could be able to make a sensible version of this patch
> > (perhaps fixing the sound too)
>
> This could be caused by what I consider to be a bug in spice-gtk's
> audio handling. This bug is triggered by the PulseAudio backend. I
> don't know about the others as I have never used them.
>
> So what happens is that PulseAudio sends regular notifications about
> changes in the latency of the audio device. I suppose this can be
> useful in case the audio goes to a network device, or if it gets
> rerouted from the builtin audio card to a USB headset or other such
> scenarios.
>
> spice-pulse.c handles these notifications in
> stream_update_latency_callback() and forwards the information to
> spice_playback_channel_set_delay() (in channel-playback.c). There the
> delay gets added to the timestamp of the **last received audio
> packet** and set as the current mmtime.

In spice-pulse, this was introduced in:
https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=54bd520f342f83bbc3bef

Not sure if this was intentionally bound with video stream. IMHO, it
seems error prone to do as much as sending the audio samples to
pulseaudio to later recover latency information and then trying to fix
it with mmtime.

Still, this is very interesting. I played a lot with audio and I don't
recall any sync issues so far.

> This means that if you stop receiving audio packets the mmtime gets
> stuck. Essentially time stands still as far as spice-gtk is concerned!
> So anything that deals with mmtimes breaks down, like the video
> playback.

Using only audio playback, I'm not able to easily make mmtime to
increase greatly. I'll try to setup my environment with the latency
utility [0] from Frediano to investigate it further.

[0] https://github.com/freddy77/latency

>
> Why would one stop receiving audio packets?
> * This happens whenever an application opens the audio device but then
>  does not write anything to it. For instance if you start mplayer and
>  then pause playback it will keep the audio device open but stop
>  writing audio data to it.
>  Fortunately QEMU has a workaround for this: it closes the playback
>  channel if there is nothing to play for 300 ms or more. 300 ms is
>  short enough that you will not really notice the short pause in the
>  video playback.

Ah, so, that's the reason I'm not able to easily reproduce this. I read
your email twice but missed this info. Do you know the hash for this in
QEMU?

>  The Xspice server was missing this workaround which
>  is how I discovered this bug. But I updated it to match QEMU in
>  commit 76fd0a37.

(just for reference)
https://cgit.freedesktop.org/xorg/driver/

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Brad Wilson]

Ok, So is there a command I can initiate to re-evaluate the bandwidth 
availability or a way to check to see the results are correct?  I've got a 
gigabit connection and I want it to use as much as possible to provide the 
maximum user experience for my VDI users. Like I said, RDP uses 15Mbps which is 
fine and gives a great experience but my vdi solution requires spice protocol 
and to be used with virt viewer. 
Thanks for your help. 
  From: Francois Gouget 
 To: Brad Wilson  
Cc: Victor Toso ; Frediano Ziglio ; 
Spice Devel 
 Sent: Monday, October 17, 2016 10:07 AM
 Subject: Re: [Spice-devel] Very poor video performance using Virt Viewer 
compared to RDP
   
On Mon, 17 Oct 2016, Brad Wilson wrote:

> Ok, so I installed the AC97 audio drivers to fix my audio device in 
> the guest vm.  Using Virt-Viewer with qxl, the video streaming has 
> improved and I am seeing closer to 1.5Mbps network traffic now when 
> watching hd videos but the quality is still suffering a bit.  What I 
> would like to know is if there is a way to allow the spice protocol to 
> use more bandwidth in order to increase video quality and frame rate. 
>  In windows RDP you can set the quality to be super high which gives a 
> much nicer video experience at the cost of about 15Mbps... I am 
> curious if Spice or Virt-Viewer have such a setting? And just to be 
> clear, I can get near native quality using rdp to this same VM. 

There is no such setting. Spice automatically uses all the available 
bandwidth.

That said if for some reason it settled on a bandwidth lower than what 
is truly available, it will only try to increase bandwidth usage again 
after a while and only quite progressively (at least for the GStreamer 
backend, I don't really remember what the mjpeg one does in that case).


-- 
Francois Gouget 

   ___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Francois Gouget]

On Mon, 17 Oct 2016, Brad Wilson wrote:

> Ok, so I installed the AC97 audio drivers to fix my audio device in 
> the guest vm.  Using Virt-Viewer with qxl, the video streaming has 
> improved and I am seeing closer to 1.5Mbps network traffic now when 
> watching hd videos but the quality is still suffering a bit.  What I 
> would like to know is if there is a way to allow the spice protocol to 
> use more bandwidth in order to increase video quality and frame rate. 
>  In windows RDP you can set the quality to be super high which gives a 
> much nicer video experience at the cost of about 15Mbps... I am 
> curious if Spice or Virt-Viewer have such a setting? And just to be 
> clear, I can get near native quality using rdp to this same VM. 

There is no such setting. Spice automatically uses all the available 
bandwidth.

That said if for some reason it settled on a bandwidth lower than what 
is truly available, it will only try to increase bandwidth usage again 
after a while and only quite progressively (at least for the GStreamer 
backend, I don't really remember what the mjpeg one does in that case).


-- 
Francois Gouget ___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Victor Toso]

Hi!

On Fri, Oct 14, 2016 at 04:55:35PM +0200, Francois Gouget wrote:
> On Thu, 13 Oct 2016, Frediano Ziglio wrote:
> [...]
> > I discovered where the main lag came quite by "accident". To test
> > I used one small utility and this utility don't have a way to change
> > parameters (like bandwidth) so knowing how the tcp work I stopped
> > the utility and started again as fast as I can with different
> > parameters. This of course create packets loss and some delay but
> > the connection works fine as tcp retransmit the packets lost.
> > But surprisingly the delay introduced by this accident was maintained
> > in the video! I then removed all Virgl stuff, tried again with a video
> > and the lag is still present. Also interrupting the utility and
> > starting again was increasing the lag (I managed to have about
> > 3 seconds lag!).
> >
> > Now... I have a patch for the client but as I said I'm not familiar
> > with the client too much and it's really terrible. It mainly remove
> > the synchronization with the audio (with still lags) and play the
> > video as fast as possible. By the way, I think is time to send as
> > someone could be able to make a sensible version of this patch
> > (perhaps fixing the sound too)
>
> This could be caused by what I consider to be a bug in spice-gtk's
> audio handling. This bug is triggered by the PulseAudio backend. I
> don't know about the others as I have never used them.
>
> So what happens is that PulseAudio sends regular notifications about
> changes in the latency of the audio device. I suppose this can be
> useful in case the audio goes to a network device, or if it gets
> rerouted from the builtin audio card to a USB headset or other such
> scenarios.
>
> spice-pulse.c handles these notifications in
> stream_update_latency_callback() and forwards the information to
> spice_playback_channel_set_delay() (in channel-playback.c). There the
> delay gets added to the timestamp of the **last received audio
> packet** and set as the current mmtime.

In spice-pulse, this was introduced in:
https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=54bd520f342f83bbc3bef

Not sure if this was intentionally bound with video stream. IMHO, it
seems error prone to do as much as sending the audio samples to
pulseaudio to later recover latency information and then trying to fix
it with mmtime.

Still, this is very interesting. I played a lot with audio and I don't
recall any sync issues so far.

> This means that if you stop receiving audio packets the mmtime gets
> stuck. Essentially time stands still as far as spice-gtk is concerned!
> So anything that deals with mmtimes breaks down, like the video
> playback.

Using only audio playback, I'm not able to easily make mmtime to
increase greatly. I'll try to setup my environment with the latency
utility [0] from Frediano to investigate it further.

[0] https://github.com/freddy77/latency

>
> Why would one stop receiving audio packets?
> * This happens whenever an application opens the audio device but then
>   does not write anything to it. For instance if you start mplayer and
>   then pause playback it will keep the audio device open but stop
>   writing audio data to it.
>   Fortunately QEMU has a workaround for this: it closes the playback
>   channel if there is nothing to play for 300 ms or more. 300 ms is
>   short enough that you will not really notice the short pause in the
>   video playback.

Ah, so, that's the reason I'm not able to easily reproduce this. I read
your email twice but missed this info. Do you know the hash for this in
QEMU?

>   The Xspice server was missing this workaround which
>   is how I discovered this bug. But I updated it to match QEMU in
>   commit 76fd0a37.

(just for reference)
https://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=76fd0a37

>
> * This can also happen if you start losing audio packets. I suspect
>   this is what you're seeing. The video streaming code tries hard to
>   leave enough bandwidth for the audio streams, mostly because it's
>   better to degrade video quality a bit than have choppy audio. But
>   this also helps avoid this isue.
>
> But even in the normal case this bug can disrupt video playback a bit.
>
> Audio packets are sent at regular intervals, typically every 10ms in
> Xspice's case. Meanwhile stream_update_latency_callback() is called on a
> totally independent schedule and when that happens the last audio packet
> will be somehwere between 0 and 10 ms old. This means this bug
> introduces a 10 ms jitter in mmtime.

The synchronization between video/audio should come from source
(spice-server or qemu) and not from pulseaudio. Actually, you can see
that spice-server does send mmtime with SPICE_MSG_MAIN_MULTI_MEDIA_TIME
and it seems to be used in a few places:

server/sound.c:1080: reds_enable_mm_time(snd_channel_get_server(channel));
server/sound.c:1205: reds_enable_mm_time(snd_channel_get_server(channel));
server/main-dispatcher.c:219: reds_set_client_

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Francois Gouget]

On Thu, 13 Oct 2016, Frediano Ziglio wrote:
[...]
> I discovered where the main lag came quite by "accident". To test
> I used one small utility and this utility don't have a way to change
> parameters (like bandwidth) so knowing how the tcp work I stopped
> the utility and started again as fast as I can with different
> parameters. This of course create packets loss and some delay but
> the connection works fine as tcp retransmit the packets lost.
> But surprisingly the delay introduced by this accident was maintained
> in the video! I then removed all Virgl stuff, tried again with a video
> and the lag is still present. Also interrupting the utility and
> starting again was increasing the lag (I managed to have about
> 3 seconds lag!).
> 
> Now... I have a patch for the client but as I said I'm not familiar
> with the client too much and it's really terrible. It mainly remove
> the synchronization with the audio (with still lags) and play the
> video as fast as possible. By the way, I think is time to send as
> someone could be able to make a sensible version of this patch
> (perhaps fixing the sound too)

This could be caused by what I consider to be a bug in spice-gtk's audio 
handling. This bug is triggered by the PulseAudio backend. I don't know 
about the others as I have never used them.


So what happens is that PulseAudio sends regular notifications about 
changes in the latency of the audio device. I suppose this can be useful 
in case the audio goes to a network device, or if it gets rerouted from 
the builtin audio card to a USB headset or other such scenarios.

spice-pulse.c handles these notifications in 
stream_update_latency_callback() and forwards the information to 
spice_playback_channel_set_delay() (in channel-playback.c). There the 
delay gets added to the timestamp of the **last received audio packet** 
and set as the current mmtime.

This means that if you stop receiving audio packets the mmtime gets 
stuck. Essentially time stands still as far as spice-gtk is concerned! 
So anything that deals with mmtimes breaks down, like the video 
playback.

Why would one stop receiving audio packets?
* This happens whenever an application opens the audio device but then 
  does not write anything to it. For instance if you start mplayer and 
  then pause playback it will keep the audio device open but stop 
  writing audio data to it.
  Fortunately QEMU has a workaround for this: it closes the playback 
  channel if there is nothing to play for 300 ms or more. 300 ms is 
  short enough that you will not really notice the short pause in the 
  video playback. The Xspice server was missing this workaround which is 
  how I discovered this bug. But I updated it to match QEMU in commit 
  76fd0a37.

* This can also happen if you start losing audio packets. I suspect this 
  is what you're seeing. The video streaming code tries hard to leave 
  enough bandwidth for the audio streams, mostly because it's better to 
  degrade video quality a bit than have choppy audio. But this also 
  helps avoid this isue.

But even in the normal case this bug can disrupt video playback a bit.

Audio packets are sent at regular intervals, typically every 10ms in 
Xspice's case. Meanwhile stream_update_latency_callback() is called on a 
totally independent schedule and when that happens the last audio packet 
will be somehwere between 0 and 10 ms old. This means this bug 
introduces a 10 ms jitter in mmtime.

The issue is that the mmtime is pretty important for streaming, 
particularly video streaming. It's used by the client to measure how 
much margin it has between reception of a frame and when that frame 
should be displayed. Based onthat margin the video streaming code 
decides whether it should lower the bandwidth or keep it as is. When 
bandwidth is plentiful the margin would typically be around 300 ms and 
if you divide that into four that gives you 75 ms buckets. So a 10 ms 
error could relatively easily move you from one bucket to another. A 10 
ms error is also likely to exceed the rtt jitter in many cases.


I'm not sure what the right fix is. It most likely involves ignoring the 
last audio packet mmtime. Maybe keep track of the last delay value and 
adjust mmtime by the difference between the old and new value?


-- 
Francois Gouget   
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Victor Toso]

Hi,

On Thu, Oct 13, 2016 at 06:00:10PM +, Brad Wilson wrote:
> So one thing I notice is that there is a multimedia audio device that
> has a bad driver in the device manager...

Can you elaborate in the issue you see/hear? Might be this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1203507

> maybe that is screwing things up, forcing the video to wait for audio
> that will never come...  I'll see if i can get that working properly
> and maybe it will help. 

I think Frediano can have sync issues even on Linux Guest.

  toso

>
>   From: Frediano Ziglio 
>  To: Brad Wilson  
> Cc: spice-devel@lists.freedesktop.org
>  Sent: Thursday, October 13, 2016 10:08 AM
>  Subject: Re: [Spice-devel] Very poor video performance using Virt Viewer 
> compared to RDP
>  
> > I have a Windows 7 VM running via Qemu on Gentoo Linux using a product 
> > called
> > Foss-Cloud.
> > I have spice tools and the QXL video driver installed
> > Using Virt-Viewer The Vm shows a little lag when typing (always takes a
> > second to catch up when typing my password to log in and such). In general
> > pulling up folders and text heavy web pages is pretty snappy and doesn’t tax
> > the cpu or memory at all. If look at a site that has a lot of pictures I
> > start seeing frame loss and the mouse gets a little laggy when scrolling. If
> > I pull up a video I see the cpu jump a little and the video is extremely
> > laggy and I see about ever 10 th frame of the video, at the same time I lose
> > sight of the mouse pointer for a second at a time and it becomes hard to
> > control.
> > While connecting to this vm using Virt-Viewer I also notice very low
> > bandwidth usage, well below 500Kbps which is strange for a remote session
> > sending video traffic.
> > Using Windows RDP I was able to pull up all the same videos and web pages
> > with no problem, the videos were clear and ran smooth and the websites with
> > a lot of pictures scrolled normally. I did notice that the network traffic
> > using RDP was closer to 10mbps and spiked to 14mbps so it’s understandable
> > that I would get a better experience.
> 
> I'm not really familiar with the client code and I don't know if this
> is really related to your problem but it share the fact of the lag and
> the video.
> 
> While I was trying to code Virgl remote support I noted that in some
> conditions I had EXTREME (like 1/2 seconds) lags. This was worsened
> with low bandwidth. I started putting some debug code to understand
> if server was queueing too data or was just too slow to handle the
> encoding. And if was fast enough to handle all encoded frames and
> the code in the streaming to deal with low bandwidth was apparently
> doing it's job and the network queue (you can see with netstat) was
> low. I then started putting timestamps in the frames trying to
> understand where the lag was coming from and how much time take from
> the encoding to the final client screen (you can see a video at
> https://www.youtube.com/watch?v=D_DCs2sriu0 to understand the
> time stamping, the green time in the video was written in the frames
> before encoding in the server, not by the client).
> 
> I discovered where the main lag came quite by "accident". To test
> I used one small utility and this utility don't have a way to change
> parameters (like bandwidth) so knowing how the tcp work I stopped
> the utility and started again as fast as I can with different
> parameters. This of course create packets loss and some delay but
> the connection works fine as tcp retransmit the packets lost.
> But surprisingly the delay introduced by this accident was maintained
> in the video! I then removed all Virgl stuff, tried again with a video
> and the lag is still present. Also interrupting the utility and
> starting again was increasing the lag (I managed to have about
> 3 seconds lag!).
> 
> Now... I have a patch for the client but as I said I'm not familiar
> with the client too much and it's really terrible. It mainly remove
> the synchronization with the audio (with still lags) and play the
> video as fast as possible. By the way, I think is time to send as
> someone could be able to make a sensible version of this patch
> (perhaps fixing the sound too)
> 
> 
> From 31364b1b1b1e5041ba64441f18104f7f1e978af5 Mon Sep 17 00:00:00 2001
> From: Frediano Ziglio 
> Date: Thu, 13 Oct 2016 15:40:49 +0100
> Subject: [spice-gtk] Try to reduce video lag
> 
> ---
>  src/channel-display-gst.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> 

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Sergio L. Pascual]

On vie, 2016-10-14 at 09:17 +0200, Sergio L. Pascual wrote:
> On jue, 2016-10-13 at 13:30 +, Brad Wilson wrote:
> > 
> > Using Virt-Viewer The Vm shows a little lag when typing (always
> > takes
> > a second to catch up when typing my password to log in and such). 
> > In
> > general pulling up folders and  text heavy web pages is pretty
> > snappy
> > and doesn’t tax the cpu or memory at all.  If look at a site that
> > has
> > a lot of pictures I start seeing frame loss and the mouse gets a
> > little laggy when scrolling.  If I pull up a video I see the cpu
> > jump
> > a little and the video is extremely laggy and I see about ever 10th
> > frame of the video, at the same time I lose sight of the mouse
> > pointer for a second at a time and it becomes hard to control.   
> >  
> Make sure your guest is actually using the QXL driver (check
> /var/log/Xorg.0.log, or your distro's equivalent). Those symptoms
> seem
> to indicate your X is running with a fallback driver (vesa or
> similar).
> 

Just read it again, and noticed you're talking about a Windows 7 VM.
Forget what I wrote, and check your audio device on both sides (guest
and _client_).

-- 
Sergio L. Pascual




___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Sergio L. Pascual]

On jue, 2016-10-13 at 13:30 +, Brad Wilson wrote:
> Using Virt-Viewer The Vm shows a little lag when typing (always takes
> a second to catch up when typing my password to log in and such).  In
> general pulling up folders and  text heavy web pages is pretty snappy
> and doesn’t tax the cpu or memory at all.  If look at a site that has
> a lot of pictures I start seeing frame loss and the mouse gets a
> little laggy when scrolling.  If I pull up a video I see the cpu jump
> a little and the video is extremely laggy and I see about ever 10th
> frame of the video, at the same time I lose sight of the mouse
> pointer for a second at a time and it becomes hard to control.   
>  

Make sure your guest is actually using the QXL driver (check
/var/log/Xorg.0.log, or your distro's equivalent). Those symptoms seem
to indicate your X is running with a fallback driver (vesa or similar).

-- 
Sergio L. Pascual


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Brad Wilson]

So one thing I notice is that there is a multimedia audio device that has a bad 
driver in the device manager... maybe that is screwing things up, forcing the 
video to wait for audio that will never come... I'll see if i can get that 
working properly and maybe it will help. 

  From: Frediano Ziglio 
 To: Brad Wilson  
Cc: spice-devel@lists.freedesktop.org
 Sent: Thursday, October 13, 2016 10:08 AM
 Subject: Re: [Spice-devel] Very poor video performance using Virt Viewer 
compared to RDP
   
> I have a Windows 7 VM running via Qemu on Gentoo Linux using a product called
> Foss-Cloud.
> I have spice tools and the QXL video driver installed
> Using Virt-Viewer The Vm shows a little lag when typing (always takes a
> second to catch up when typing my password to log in and such). In general
> pulling up folders and text heavy web pages is pretty snappy and doesn’t tax
> the cpu or memory at all. If look at a site that has a lot of pictures I
> start seeing frame loss and the mouse gets a little laggy when scrolling. If
> I pull up a video I see the cpu jump a little and the video is extremely
> laggy and I see about ever 10 th frame of the video, at the same time I lose
> sight of the mouse pointer for a second at a time and it becomes hard to
> control.
> While connecting to this vm using Virt-Viewer I also notice very low
> bandwidth usage, well below 500Kbps which is strange for a remote session
> sending video traffic.
> Using Windows RDP I was able to pull up all the same videos and web pages
> with no problem, the videos were clear and ran smooth and the websites with
> a lot of pictures scrolled normally. I did notice that the network traffic
> using RDP was closer to 10mbps and spiked to 14mbps so it’s understandable
> that I would get a better experience.

I'm not really familiar with the client code and I don't know if this
is really related to your problem but it share the fact of the lag and
the video.

While I was trying to code Virgl remote support I noted that in some
conditions I had EXTREME (like 1/2 seconds) lags. This was worsened
with low bandwidth. I started putting some debug code to understand
if server was queueing too data or was just too slow to handle the
encoding. And if was fast enough to handle all encoded frames and
the code in the streaming to deal with low bandwidth was apparently
doing it's job and the network queue (you can see with netstat) was
low. I then started putting timestamps in the frames trying to
understand where the lag was coming from and how much time take from
the encoding to the final client screen (you can see a video at
https://www.youtube.com/watch?v=D_DCs2sriu0 to understand the
time stamping, the green time in the video was written in the frames
before encoding in the server, not by the client).

I discovered where the main lag came quite by "accident". To test
I used one small utility and this utility don't have a way to change
parameters (like bandwidth) so knowing how the tcp work I stopped
the utility and started again as fast as I can with different
parameters. This of course create packets loss and some delay but
the connection works fine as tcp retransmit the packets lost.
But surprisingly the delay introduced by this accident was maintained
in the video! I then removed all Virgl stuff, tried again with a video
and the lag is still present. Also interrupting the utility and
starting again was increasing the lag (I managed to have about
3 seconds lag!).

Now... I have a patch for the client but as I said I'm not familiar
with the client too much and it's really terrible. It mainly remove
the synchronization with the audio (with still lags) and play the
video as fast as possible. By the way, I think is time to send as
someone could be able to make a sensible version of this patch
(perhaps fixing the sound too)


>From 31364b1b1b1e5041ba64441f18104f7f1e978af5 Mon Sep 17 00:00:00 2001
From: Frediano Ziglio 
Date: Thu, 13 Oct 2016 15:40:49 +0100
Subject: [spice-gtk] Try to reduce video lag

---
 src/channel-display-gst.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 430bb95..c1ebfeb 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -48,6 +48,7 @@ typedef struct SpiceGstDecoder {
    GQueue *decoding_queue;
    GQueue *display_queue;
    guint timer_id;
+    guint unique_id;
 } SpiceGstDecoder;
 
 
@@ -94,13 +95,15 @@ static gboolean display_frame(gpointer video_decoder)
    GstBuffer *buffer;
    GstMapInfo mapinfo;
 
-    decoder->timer_id = 0;
-
+ again:
    g_mutex_lock(&decoder->queues_mutex);
+    decoder->timer_id = 0;
    frame = g_queue_pop_head(decoder->display_queue);
    g_mutex_unlock(&decoder->queues_mutex);
    /* If the queue is empty we don't even need to resc

Re: [Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Frediano Ziglio]

> I have a Windows 7 VM running via Qemu on Gentoo Linux using a product called
> Foss-Cloud.
> I have spice tools and the QXL video driver installed
> Using Virt-Viewer The Vm shows a little lag when typing (always takes a
> second to catch up when typing my password to log in and such). In general
> pulling up folders and text heavy web pages is pretty snappy and doesn’t tax
> the cpu or memory at all. If look at a site that has a lot of pictures I
> start seeing frame loss and the mouse gets a little laggy when scrolling. If
> I pull up a video I see the cpu jump a little and the video is extremely
> laggy and I see about ever 10 th frame of the video, at the same time I lose
> sight of the mouse pointer for a second at a time and it becomes hard to
> control.
> While connecting to this vm using Virt-Viewer I also notice very low
> bandwidth usage, well below 500Kbps which is strange for a remote session
> sending video traffic.
> Using Windows RDP I was able to pull up all the same videos and web pages
> with no problem, the videos were clear and ran smooth and the websites with
> a lot of pictures scrolled normally. I did notice that the network traffic
> using RDP was closer to 10mbps and spiked to 14mbps so it’s understandable
> that I would get a better experience.

I'm not really familiar with the client code and I don't know if this
is really related to your problem but it share the fact of the lag and
the video.

While I was trying to code Virgl remote support I noted that in some
conditions I had EXTREME (like 1/2 seconds) lags. This was worsened
with low bandwidth. I started putting some debug code to understand
if server was queueing too data or was just too slow to handle the
encoding. And if was fast enough to handle all encoded frames and
the code in the streaming to deal with low bandwidth was apparently
doing it's job and the network queue (you can see with netstat) was
low. I then started putting timestamps in the frames trying to
understand where the lag was coming from and how much time take from
the encoding to the final client screen (you can see a video at
https://www.youtube.com/watch?v=D_DCs2sriu0 to understand the
time stamping, the green time in the video was written in the frames
before encoding in the server, not by the client).

I discovered where the main lag came quite by "accident". To test
I used one small utility and this utility don't have a way to change
parameters (like bandwidth) so knowing how the tcp work I stopped
the utility and started again as fast as I can with different
parameters. This of course create packets loss and some delay but
the connection works fine as tcp retransmit the packets lost.
But surprisingly the delay introduced by this accident was maintained
in the video! I then removed all Virgl stuff, tried again with a video
and the lag is still present. Also interrupting the utility and
starting again was increasing the lag (I managed to have about
3 seconds lag!).

Now... I have a patch for the client but as I said I'm not familiar
with the client too much and it's really terrible. It mainly remove
the synchronization with the audio (with still lags) and play the
video as fast as possible. By the way, I think is time to send as
someone could be able to make a sensible version of this patch
(perhaps fixing the sound too)


From 31364b1b1b1e5041ba64441f18104f7f1e978af5 Mon Sep 17 00:00:00 2001
From: Frediano Ziglio 
Date: Thu, 13 Oct 2016 15:40:49 +0100
Subject: [spice-gtk] Try to reduce video lag

---
 src/channel-display-gst.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 430bb95..c1ebfeb 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -48,6 +48,7 @@ typedef struct SpiceGstDecoder {
 GQueue *decoding_queue;
 GQueue *display_queue;
 guint timer_id;
+guint unique_id;
 } SpiceGstDecoder;
 
 
@@ -94,13 +95,15 @@ static gboolean display_frame(gpointer video_decoder)
 GstBuffer *buffer;
 GstMapInfo mapinfo;
 
-decoder->timer_id = 0;
-
+ again:
 g_mutex_lock(&decoder->queues_mutex);
+decoder->timer_id = 0;
 frame = g_queue_pop_head(decoder->display_queue);
 g_mutex_unlock(&decoder->queues_mutex);
 /* If the queue is empty we don't even need to reschedule */
-g_return_val_if_fail(frame, G_SOURCE_REMOVE);
+if (!frame) {
+return G_SOURCE_REMOVE;
+}
 
 if (!frame->sample) {
 spice_warning("got a frame without a sample!");
@@ -132,26 +135,28 @@ static gboolean display_frame(gpointer video_decoder)
 
  error:
 free_frame(frame);
-schedule_frame(decoder);
-return G_SOURCE_REMOVE;
+goto again;
 }
 
 /* main loop or GStreamer streaming thread */
 static void schedule_frame(SpiceGstDecoder *decoder)
 {
-guint32 now = stream_get_time(decoder->base.stream);
+//guint32 now = stream_get_time(decoder->base.stream);
 g_mutex_lock

[Spice-devel] Very poor video performance using Virt Viewer compared to RDP

[Brad Wilson]

I have a Windows 7 VM running via Qemu on Gentoo Linux usinga product called 
Foss-Cloud.  


 
I have spice tools and the QXL video driver installed


 
Using Virt-Viewer The Vm shows a little lag when typing(always takes a second 
to catch up when typing my password to log in and such).  In general pulling up 
folders and  text heavy web pages is pretty snappy anddoesn’t tax the cpu or 
memory at all.  Iflook at a site that has a lot of pictures I start seeing 
frame loss and themouse gets a little laggy when scrolling. If I pull up a 
video I see the cpu jump a little and the video isextremely laggy and I see 
about ever 10th frame of the video, at thesame time I lose sight of the mouse 
pointer for a second at a time and itbecomes hard to control.   


 
While connecting to this vm using Virt-Viewer I also noticevery low bandwidth 
usage, well below 500Kbps which is strange for a remotesession sending video 
traffic.


 

 
Using Windows RDP I was able to pull up all the same videosand web pages with 
no problem, the videos were clear and ran smooth and thewebsites with a lot of 
pictures scrolled normally.  I did notice that the network traffic usingRDP was 
closer to 10mbps and spiked to 14mbps so it’s understandable that I wouldget a 
better experience.   

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel