Video showing an old frame after switching from background to foreground tab |
||||||
Issue descriptionVersion: M54+ (and some previous versions) OS: All What steps will reproduce the problem? (1) Play a HTML5 <video> (2) Switch to another tab so the video is playing in a background tab (3) Wait for a few minutes (4) Switch back to the tab playing video What is the expected output? Video keep playing, showing latest video frames. What do you see instead? Seeing a very old video frame that could stay on the screen for as long as 0.5-1 second, then video start to show latest frames. Please use labels and text to provide additional information. This is not a severe issue, but to me this is annoying. I wonder how we can improve it. I guess the issue is not in media/, because the compositor decided not to update video frames when the video is in background tab. Some potential ideas: - When user hovers on a background tab, we start to update (video) frames. - When video is in the background tab, still update video frames but slowly, e.g. 5 fps, or 2 fps. - Paint a black frame instead of an old frame when video goes to background, I feel switching from black to new frame is not as annoying (no sudden scene change).
,
Oct 25 2016
I definitely support the idea to disable video decoding when in background. At the same time, it would be great to deliver a smoother user experience to users. We can start with a black frame, then try to improve the speed to resume playback, e.g. if we have any indication that the tab may go back to foreground, we can start to resume playback early.
,
Oct 25 2016
+compositing folk. We still notify the compositor of new frames in the background, so the frame should not be more than 250ms old unless the redraw is delayed for the whole page.
,
Oct 26 2016
cc folks that might know how compositor deal with videos. enne@ and fsamuel@, do you have any idea?
,
Oct 26 2016
This is a consequence of our use of DelegatedFrameEvictor, and is by design. We put up the last frame that we drew, ignoring what content elements it had. If one of these elements was video, that frame will be noticeably old. The reason for this strategy is that we have to go with one of the following 1. draw nothing and flash some color (maybe page's background color) 2. hang until the renderer provides a frame (sometimes seconds) 3. draw the last frame that we got from the renderer. We go with 3 if we have it. If we don't have it, then we do 2 for ~50 msec, and then we do 1.
,
Oct 28 2016
I see this is happening by design. But to me, this results in a flaw in the overall user experience. Do you have any suggestion how we could fix this?
,
Nov 4 2016
as per #6, assign to xhwang, remove from untriaged bucket.
,
Dec 7 2016
I saw this again today which reminds me of this issue. There's nothing I can do here and I am not familiar with CC code. Tentatively assign to ccameron@ to explore possibilities.
,
Dec 20 2016
Per #5, this is intended behavior. It's a trade-off. This results in a more responsive tab-switch in general, but can look "odd/wrong" if the old tab has changed substantially.
,
Feb 27 2017
Alex suggested UX treatment on the 'old' frame until it starts playing again (one example was a blur). |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by avayvod@chromium.org
, Oct 25 2016