Some media encoding/conversion pipelines are sloppy when doing sample time/timescale math, and the error accumulation results in small gaps in the media timeline. r202641 increased the maximum allowable gap from 0.01 second to one 24fps frame, but it turns out that at least one large provider has a significant amount of content encoded with up to two 24fps frames.
<rdar://problem/27372033>
Created attachment 283763 [details] Proposed patch.
Comment on attachment 283763 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=283763&action=review > LayoutTests/media/media-source/media-source-small-gap.html:41 > + makeASample(7, 7, 1, 1, SAMPLE_FLAG.NONE), The spacing is odd here.
Comment on attachment 283763 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=283763&action=review >> LayoutTests/media/media-source/media-source-small-gap.html:41 >> + makeASample(7, 7, 1, 1, SAMPLE_FLAG.NONE), > > The spacing is odd here. I originally used one space after each comma, but found that it was difficult to see exactly what was different in each sample.
Comment on attachment 283763 [details] Proposed patch. Clearing flags on attachment: 283763 Committed r203277: <http://trac.webkit.org/changeset/203277>
All reviewed patches have been landed. Closing bug.
I think we should have different allowable gaps for Audio and Video tracks, and they should be calculated based on the current frame duration. Otherwise AudioWithLargeGap test from http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2016.html fails.
A note on my previous comment: the test failure is reportedly not reproducible with the latest (2017) MSE test cases http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2017.html