YouTube stalls when seeking beyond buffered range
Created attachment 290403 [details] Patch
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
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
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
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
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
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
Do we have no test infrastructure that serves a video in predictable chunks with predictable wait times between chunks? We ought to.
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
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. :(
Created attachment 291993 [details] Patch
Created attachment 292223 [details] Patch
Comment on attachment 292223 [details] Patch Clearing flags on attachment: 292223 Committed r207694: <http://trac.webkit.org/changeset/207694>
All reviewed patches have been landed. Closing bug.
*** Bug 160569 has been marked as a duplicate of this bug. ***