Bug 28817 - RFE: detect repeated blank/silent streams
Summary: RFE: detect repeated blank/silent streams
Status: RESOLVED MOVED
Alias: None
Product: Spice
Classification: Unclassified
Component: server (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Spice Bug List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-29 06:18 UTC by Alexander Larsson
Modified: 2018-06-03 10:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Alexander Larsson 2010-06-29 06:18:18 UTC
From: https://bugzilla.redhat.com/show_bug.cgi?id=603767

with vlc and some other players we're sending a lot of data even when paused. Muting helps a bit but not all.

This is probably the app doing something stupid, but we should research this to see if we can do better. For instance, cache the paused video and detect silence in the audio.
Comment 1 gvenkat 2011-04-12 14:22:45 UTC
(In reply to comment #0)
> From: https://bugzilla.redhat.com/show_bug.cgi?id=603767
> 
> with vlc and some other players we're sending a lot of data even when paused.
> Muting helps a bit but not all.
> 
> This is probably the app doing something stupid, but we should research this to
> see if we can do better. For instance, cache the paused video and detect
> silence in the audio.

Yes, I can confirm this for all videos including Flash. This makes browsing on YouTube very annoying as the audio from the previous flash movie keeps playing for 5-10 seconds after moving away from the page in the web browser.

I am not sure this is a problem with the app.

I wonder how much delay there is between the guest driver and the spice client before the audio/video starts being seen/heard on the page. If that delay is large, it may simply be the case that spice client doesn't see the end of stream for a while and continues playing until it sees the end of the stream. Although the audio and video are in sync, the data may have been generated by the app 5-10 seconds ago. 

Since the layer it is drawing to for video has gone away for the spice client, you don't see the video continuing to update but will hear the audio coming through. Spice client may not be able to do much with this kind of a delay since it does not know what the delay is. 

There may not be a clean solution to this, since there may be use cases when the audio/video should play till the end even with the delay and in some cases like the above, it shouldn't. So spice at the guest VM may not know whether to flush the data or signal the client to abort without knowing whether it is necessary based on the use case.

The best bet is to try to reduce the delay as much as possible.

A way to test the above hypothesis is to have a web page that has a visible timer counter that starts counting as soon as the page is loaded (or use a stop watch!). Play the flash video and mark the time you first hear the audio/see the video. Try this with and without SPICE and whether the difference is the same time the audio continues to play after moving away from the page.
Comment 2 Yonit Halperin 2011-05-15 02:23:17 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > From: https://bugzilla.redhat.com/show_bug.cgi?id=603767
> > 
> > with vlc and some other players we're sending a lot of data even when paused.
> > Muting helps a bit but not all.
> > 
> > This is probably the app doing something stupid, but we should research this to
> > see if we can do better. For instance, cache the paused video and detect
> > silence in the audio.
> 
> Yes, I can confirm this for all videos including Flash. This makes browsing on
> YouTube very annoying as the audio from the previous flash movie keeps playing
> for 5-10 seconds after moving away from the page in the web browser.
> 
> I am not sure this is a problem with the app.
> 
> I wonder how much delay there is between the guest driver and the spice client
> before the audio/video starts being seen/heard on the page. If that delay is
> large, it may simply be the case that spice client doesn't see the end of
> stream for a while and continues playing until it sees the end of the stream.
> Although the audio and video are in sync, the data may have been generated by
> the app 5-10 seconds ago. 
> 
> Since the layer it is drawing to for video has gone away for the spice client,
> you don't see the video continuing to update but will hear the audio coming
> through. Spice client may not be able to do much with this kind of a delay
> since it does not know what the delay is. 
> 
> There may not be a clean solution to this, since there may be use cases when
> the audio/video should play till the end even with the delay and in some cases
> like the above, it shouldn't. So spice at the guest VM may not know whether to
> flush the data or signal the client to abort without knowing whether it is
> necessary based on the use case.
> 
> The best bet is to try to reduce the delay as much as possible.
> 
> A way to test the above hypothesis is to have a web page that has a visible
> timer counter that starts counting as soon as the page is loaded (or use a stop
> watch!). Play the flash video and mark the time you first hear the audio/see
> the video. Try this with and without SPICE and whether the difference is the
> same time the audio continues to play after moving away from the page.

This is not the scenario the bug is about. When pausing VLC, (In reply to comment #1)
> (In reply to comment #0)
> > From: https://bugzilla.redhat.com/show_bug.cgi?id=603767
> > 
> > with vlc and some other players we're sending a lot of data even when paused.
> > Muting helps a bit but not all.
> > 
> > This is probably the app doing something stupid, but we should research this to
> > see if we can do better. For instance, cache the paused video and detect
> > silence in the audio.
> 
> Yes, I can confirm this for all videos including Flash. This makes browsing on
> YouTube very annoying as the audio from the previous flash movie keeps playing
> for 5-10 seconds after moving away from the page in the web browser.
> 
> I am not sure this is a problem with the app.
> 
> I wonder how much delay there is between the guest driver and the spice client
> before the audio/video starts being seen/heard on the page. If that delay is
> large, it may simply be the case that spice client doesn't see the end of
> stream for a while and continues playing until it sees the end of the stream.
> Although the audio and video are in sync, the data may have been generated by
> the app 5-10 seconds ago. 
> 
> Since the layer it is drawing to for video has gone away for the spice client,
> you don't see the video continuing to update but will hear the audio coming
> through. Spice client may not be able to do much with this kind of a delay
> since it does not know what the delay is. 
> 
> There may not be a clean solution to this, since there may be use cases when
> the audio/video should play till the end even with the delay and in some cases
> like the above, it shouldn't. So spice at the guest VM may not know whether to
> flush the data or signal the client to abort without knowing whether it is
> necessary based on the use case.
> 
> The best bet is to try to reduce the delay as much as possible.
> 
> A way to test the above hypothesis is to have a web page that has a visible
> timer counter that starts counting as soon as the page is loaded (or use a stop
> watch!). Play the flash video and mark the time you first hear the audio/see
> the video. Try this with and without SPICE and whether the difference is the
> same time the audio continues to play after moving away from the page.

I think this is not the scenario this bug is about. When pausing VLC, it repeatedly sends blank images and silent sound packets.
Comment 3 GitLab Migration User 2018-06-03 10:14:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/spice/spice-server/issues/1.


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.