[MSE] Re-enqueing due to overlapping appended samples can cause stuttering playback
Created attachment 235754 [details] Patch
Comment on attachment 235754 [details] Patch Attachment 235754 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5310733680115712 New failing tests: media/media-fragments/TC0001.html
Created attachment 235757 [details] Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
<rdar://problem/17868348>
Comment on attachment 235754 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235754&action=review Does it matter that you ignore the "time" parameter? > Source/WebCore/Modules/mediasource/SourceBuffer.cpp:1403 > + if (nextSyncSampleIter != trackBuffer.samples.decodeOrder().end()) { Nit: you use trackBuffer.samples.decodeOrder().end() here and in the loop below, might as well cache it in a variable.
Created attachment 235975 [details] Patch for landing
(In reply to comment #5) > (From update of attachment 235754 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=235754&action=review > > Does it matter that you ignore the "time" parameter? No, but to clarify what's going on, I extracted that if statement into its own method. > > Source/WebCore/Modules/mediasource/SourceBuffer.cpp:1403 > > + if (nextSyncSampleIter != trackBuffer.samples.decodeOrder().end()) { > > Nit: you use trackBuffer.samples.decodeOrder().end() here and in the loop below, might as well cache it in a variable. Ok.
Comment on attachment 235975 [details] Patch for landing Clearing flags on attachment: 235975 Committed r171995: <http://trac.webkit.org/changeset/171995>
All reviewed patches have been landed. Closing bug.
Rolled out in r172007 <http://trac.webkit.org/r172007>. Re-opening.