Bug 162813

Summary: YouTube stalls when seeking beyond buffered range
Product: WebKit Reporter: Jer Noble <jer.noble>
Component: MediaAssignee: Jer Noble <jer.noble>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, buildbot, commit-queue, eric.carlson, gruan, jonlee, rniwa
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
buildbot: commit-queue-
Archive of layout-test-results from ews101 for mac-yosemite
none
Archive of layout-test-results from ews107 for mac-yosemite-wk2
none
Archive of layout-test-results from ews114 for mac-yosemite
none
Patch
none
Patch none

Jer Noble
Reported 2016-09-30 15:46:33 PDT
YouTube stalls when seeking beyond buffered range
Attachments
Patch (4.94 KB, patch)
2016-09-30 16:24 PDT, Jer Noble
buildbot: commit-queue-
Archive of layout-test-results from ews101 for mac-yosemite (1.07 MB, application/zip)
2016-09-30 17:21 PDT, Build Bot
no flags
Archive of layout-test-results from ews107 for mac-yosemite-wk2 (1.10 MB, application/zip)
2016-09-30 17:27 PDT, Build Bot
no flags
Archive of layout-test-results from ews114 for mac-yosemite (1.44 MB, application/zip)
2016-09-30 17:28 PDT, Build Bot
no flags
Patch (37.47 KB, patch)
2016-10-18 15:26 PDT, Jer Noble
no flags
Patch (37.50 KB, patch)
2016-10-20 10:28 PDT, Jer Noble
no flags
Jer Noble
Comment 1 2016-09-30 16:24:48 PDT
Build Bot
Comment 2 2016-09-30 17:21:47 PDT
Comment on attachment 290403 [details] Patch Attachment 290403 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/2178590 New failing tests: media/media-source/media-source-fudge-factor.html imported/w3c/web-platform-tests/media-source/mediasource-config-change-mp4-v-framerate.html
Build Bot
Comment 3 2016-09-30 17:21:50 PDT
Created attachment 290407 [details] Archive of layout-test-results from ews101 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-yosemite Platform: Mac OS X 10.10.5
Build Bot
Comment 4 2016-09-30 17:27:38 PDT
Comment on attachment 290403 [details] Patch Attachment 290403 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/2178609 New failing tests: media/media-source/media-source-fudge-factor.html imported/w3c/web-platform-tests/media-source/mediasource-config-change-mp4-v-framerate.html
Build Bot
Comment 5 2016-09-30 17:27:40 PDT
Created attachment 290408 [details] Archive of layout-test-results from ews107 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Build Bot
Comment 6 2016-09-30 17:28:30 PDT
Comment on attachment 290403 [details] Patch Attachment 290403 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/2178598 New failing tests: media/media-source/media-source-fudge-factor.html
Build Bot
Comment 7 2016-09-30 17:28:32 PDT
Created attachment 290409 [details] Archive of layout-test-results from ews114 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Alex Christensen
Comment 8 2016-09-30 20:29:52 PDT
Do we have no test infrastructure that serves a video in predictable chunks with predictable wait times between chunks? We ought to.
Jer Noble
Comment 9 2016-10-14 14:17:50 PDT
Obsoleted my initial patch. I've uncovered the underlying cause of the seek problem. When seeking, we have to feed the decoder a series of non-displaying samples, starting with an I-frame, in order for the sample representing the seek time to be decoded and displayed. When we seek to the end of a very long GOP [1], we may have to enqueue hundreds of samples. E.g., for a 10-second GOP of 30 FPS video, we could have to enqueue 299 samples in order to decode the 300th. When this happens, if we try to enqueue all 300 (e.g.) samples at once, AVSampleBufferDisplayLayer will fail silently, and do so in such a way as that the AVSampleBufferRenderSynchronizer will fail (again, silently) to seek correctly when asked. The solution is to feed the non-displaying samples into the AVSampleBufferDisplayLayer one at a time until the AVSampleBufferDisplayLayer says it's full, just the same way we do for normal (displaying) samples. [1] https://en.wikipedia.org/wiki/Group_of_pictures
Jer Noble
Comment 10 2016-10-18 15:01:06 PDT
More diagnosis: after we ask the AVSampleBufferRenderSynchronizer to seek to the new time, it will internally set its own time back to what it was previously. It does this because the only displayable video and audio frames have presentation times back at the original currentTime. The solution is to make sure to flush both audio renderers and display layers before seeking. I've been trying for the last few days to make a reproducible test case, but I've failed to come up with one which exhibits the issue. I'll file a separate bug to improve testability in this area. :(
Jer Noble
Comment 11 2016-10-18 15:26:23 PDT
Jer Noble
Comment 12 2016-10-20 10:28:25 PDT
WebKit Commit Bot
Comment 13 2016-10-21 12:55:10 PDT
Comment on attachment 292223 [details] Patch Clearing flags on attachment: 292223 Committed r207694: <http://trac.webkit.org/changeset/207694>
WebKit Commit Bot
Comment 14 2016-10-21 12:55:15 PDT
All reviewed patches have been landed. Closing bug.
Jon Lee
Comment 15 2017-08-30 11:50:12 PDT
*** Bug 160569 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.