Slow seek fails if WebMediaPlayer is idle suspended |
|
Issue descriptionIf a WebMediaPlayer is idle suspended while seeking, after the pipeline reports the seek has completed but before the buffering state changes to BUFFERING_HAVE_ENOUGH, the player incorrectly suspends, and the buffering state never reaches BUFFERING_HAVE_ENOUGH, and thus the seek never finishes (and no |seeked| event is fired.) Idle suspension is not allowed while the |WebMediaPlayerImpl::seeking_| flag is set, but this flag is cleared as soon as the pipeline reports the seek has completed, which typically happens quite soon. Once the flag is cleared, the player can be suspended, even though it is still actually seeking. This issue does typically not reproduce in a normal build. Found while running $ python tools/perf/run_benchmark media.tough_video_cases in Windows with a PGO instrumented (and thus really slow) build.
,
Dec 8 2016
I'm trying to understand this problem a little better. I believe that what can happen here is: - The frame after the seek is never rendered (pre-seek frame stays). - 'seeked' event is not fired. (Also related events, such as ready state changes.) However, if the video is playing (or play() is called while paused in this state), it will be resumed and continue normally. It seems like the bug is limited to sites that either: - Are waiting for 'seeked' to start playback, or - Require that the seek target frame is always rendered when paused. It doesn't seem like this fundamentally breaks the web, so just fixing the idle timeout in this case (to always give the full 15s after a seek) may be an adequate solution. The alternative is to use the same didLoadingProgress() logic we have for initial preroll also for seek preroll (ie. resume each time loading progresses). This makes it somewhat more likely that we will reach HaveFutureData, if sites are relying on that after a seek.
,
Jan 17 2017
My delegate refactor has landed (commit 35d2c3fe00d136c5cdc59f9703c47fba912e5c7b), which means that the timer handling for suspend/resume is much improved. Can you re-test with ToT/Canary and check whether this was sufficient to resolve the issue? |
|
►
Sign in to add a comment |
|
Comment 1 by dalecur...@chromium.org
, Dec 6 2016