Recently introduced bug causes incorrect seek behavior (multiple codecs)
Reported by
meek...@gmail.com,
Aug 31 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Example URL: http://spins.arqspin.com.s3.amazonaws.com/chromebug/chromebug4.html Steps to reproduce the problem: 1. repeatedly seek forward in an HTML5 video What is the expected behavior? Smooth seeking What went wrong? Seeking is unpredictable -- sometimes faster/slower and sometimes not ending up in the correct location at all. See Firefox. Did this work before? Yes June or July 2016 Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 52.0.2743.116 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 22.0 r0 This has worked for a very long time, not sure what recent change caused the issue. This is top priority for our company that relies on this feature to work correctly cross-browser, so let me know if I can help!
,
Aug 31 2016
(Also interested in any known work-around for this issue, including re-encoding videos if needed.)
,
Sep 1 2016
I can confirm this also affects Chrome on Windows.
,
Sep 7 2016
meekohi@gmail.com, I am able to seek forward or backward without any obvious issues. honestly the video is too short to observe any abnormal. I use Chrome 54.0.2840.6 build on Mac.
,
Sep 7 2016
I updated the bug example to make it a little more obvious. On the left (webm) I observe a frequent "jitter" where the video briefly goes backward a frame (if you view the source you'll see the currenttime is always progressing forward) and on the right (mp4) there is extreme lag while seeking to a frame. Again I want to emphasize that this was *not* the behavior until very recently.
,
Sep 7 2016
Just did an update and confirmed this issue still exists on Chrome Version 53.0.2785.89 (64-bit)
,
Sep 8 2016
this is indeed a regression caused in 52.0.2743.31. I searched CL after 52.0.2743.28(the last good build), the issue seems caused by one of the below two changes (both checked in by dale) https://chromium.googlesource.com/chromium/src/+/53a26bbba055a92b014a2ac4c3693d2488611d85 https://chromium.googlesource.com/chromium/src/+/c3567d7e3ebcced8aa4eca771ed5c2d410f25481 Dale, can you take a look?
,
Sep 8 2016
Firefox shows the same issue with the mp4 clip. I think it's simply a function of keyframe distance. Looking at the webm one now.
,
Sep 9 2016
There does seem to be something weird going on, we're choosing to paint a different frame, but I'm not sure where the first frame is going since playback is never started. [1:10:0908/170457:ERROR:video_renderer_impl.cc(380)] FrameReady -- Cleared queue -- Added ready frame: 0 [1:10:0908/170457:ERROR:video_renderer_impl.cc(383)] FrameReady -- Added ready frame: 40000 [1:10:0908/170457:ERROR:video_renderer_impl.cc(413)] Painting, queued: 2, eos: 0, low_delay_: 0, ts: 0, start_ts: 29999, stall: 1 [1:10:0908/170457:ERROR:video_renderer_impl.cc(383)] FrameReady -- Added ready frame: 80000 [1:10:0908/170457:ERROR:video_renderer_impl.cc(413)] Painting, queued: 2, eos: 0, low_delay_: 0, ts: 40000, start_ts: 29999, stall: 1 [1:10:0908/170457:ERROR:video_renderer_impl.cc(383)] FrameReady -- Added ready frame: 120000 [1:10:0908/170457:ERROR:video_renderer_impl.cc(413)] Painting, queued: 3, eos: 0, low_delay_: 0, ts: 40000, start_ts: 29999, stall: 1 [1:10:0908/170457:ERROR:video_renderer_impl.cc(383)] FrameReady -- Added ready frame: 160000 [1:10:0908/170457:ERROR:video_renderer_impl.cc(413)] Painting, queued: 4, eos: 0, low_delay_: 0, ts: 40000, start_ts: 29999, stall: 1 Somewhere along the line we toss frame 0ms and the first frame becomes 40ms. Will take a closer look tomorrow. cc: sandersd@ who looked into this before.
,
Sep 9 2016
I'd guess RemoveFramesForUnderflowOrBackgroundRendering() is misbehaving somehow.
,
Sep 9 2016
Yeah, https://cs.chromium.org/chromium/src/media/renderers/video_renderer_impl.cc?l=632 this line isn't blocking underflow removal during preroll anymore. Will give it another look tomorrow.
,
Sep 9 2016
https://codereview.chromium.org/2322393002/ fix here, affects only video-only tracks.
,
Sep 9 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/983881fde249f0bcc6e63426237016a98536d1ea commit 983881fde249f0bcc6e63426237016a98536d1ea Author: dalecurtis <dalecurtis@chromium.org> Date: Fri Sep 09 20:05:02 2016 Clear reference time after SetMediaTime in video-only time source. Without this, after a seek we may remove valid frames because we think we are in an underflow state. BUG= 642761 TEST=new unittest. Review-Url: https://codereview.chromium.org/2322393002 Cr-Commit-Position: refs/heads/master@{#417678} [modify] https://crrev.com/983881fde249f0bcc6e63426237016a98536d1ea/media/base/time_source.h [modify] https://crrev.com/983881fde249f0bcc6e63426237016a98536d1ea/media/base/wall_clock_time_source.cc [modify] https://crrev.com/983881fde249f0bcc6e63426237016a98536d1ea/media/base/wall_clock_time_source_unittest.cc
,
Sep 9 2016
,
Sep 13 2016
Tested the issue on Mac 10.11.6,Ubuntu 14.04 and Win 10 using 55.0.2859.0 and attached the screen cast of Mac here. Still observing the seeking is not smooth,even Firefox behaves the same way. URL used : http://spins.arqspin.com.s3.amazonaws.com/chromebug/chromebug4.html dalecurtis@ : Could you please review the attached screen cast and let us know if its fine.
,
Sep 13 2016
This is as good as it gets using the implementation on the website.
,
Sep 13 2016
Let me know if there is anything else that would be helpful for me to try -- happy to do some leg work. We generally use the webm version in practice.
,
Sep 13 2016
If you can check out Chrome Canary and see if the behavior matches your expectations that'd be helpful.
,
Sep 13 2016
Looks good to me in Canary -- I agree the mp4 seek performance is pretty bad but probably that is outside the scope of this issue. Version 55.0.2859.0 canary (64-bit)
,
Sep 13 2016
Great thanks!
,
Sep 13 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ff96ab1a1beaa930cb4db6b43c4068066d061cff commit ff96ab1a1beaa930cb4db6b43c4068066d061cff Author: Dale Curtis <dalecurtis@chromium.org> Date: Tue Sep 13 18:31:03 2016 Merge M54: "Clear reference time after SetMediaTime in video-only time source." Without this, after a seek we may remove valid frames because we think we are in an underflow state. BUG= 642761 TEST=new unittest. Review-Url: https://codereview.chromium.org/2322393002 Cr-Commit-Position: refs/heads/master@{#417678} (cherry picked from commit 983881fde249f0bcc6e63426237016a98536d1ea) Review URL: https://codereview.chromium.org/2340543002 . Cr-Commit-Position: refs/branch-heads/2840@{#336} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/time_source.h [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/wall_clock_time_source.cc [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/wall_clock_time_source_unittest.cc
,
Sep 13 2016
,
Sep 14 2016
Verified the merge on Windows-10, Mac OS 10.11.6 and Linux Ubuntu 14.04 on the chrome version: 54.0.2840.27. Seeking is working as intended on the left part(webm video) of the URL: http://spins.arqspin.com.s3.amazonaws.com/chromebug/chromebug4.html
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ff96ab1a1beaa930cb4db6b43c4068066d061cff commit ff96ab1a1beaa930cb4db6b43c4068066d061cff Author: Dale Curtis <dalecurtis@chromium.org> Date: Tue Sep 13 18:31:03 2016 Merge M54: "Clear reference time after SetMediaTime in video-only time source." Without this, after a seek we may remove valid frames because we think we are in an underflow state. BUG= 642761 TEST=new unittest. Review-Url: https://codereview.chromium.org/2322393002 Cr-Commit-Position: refs/heads/master@{#417678} (cherry picked from commit 983881fde249f0bcc6e63426237016a98536d1ea) Review URL: https://codereview.chromium.org/2340543002 . Cr-Commit-Position: refs/branch-heads/2840@{#336} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/time_source.h [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/wall_clock_time_source.cc [modify] https://crrev.com/ff96ab1a1beaa930cb4db6b43c4068066d061cff/media/base/wall_clock_time_source_unittest.cc |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by meek...@gmail.com
, Aug 31 2016