carry review from bug 1184867

This needs to be backed out, if bug 1184867 isn't in.

Backed out because the dependent bug 1184867 was backed out https://hg.mozilla.org/mozilla-central/rev/888e8026ed60

Jan, this video https://www.youtube.com/watch?v=XqLTe8h0-jo stalls at 6s when webm is enabled Very weird, as I tested it only a few days ago and it was all fine The first appendBuffer contains 301 opus frames, ending in 6.021 and after than nothing more until it loads (20.001000, 30.001000) So I don't know if it's a bug with youtube not serving the content but seeing that Chrome doesn't have that stall...

Got a stall here: https://www.youtube.com/watch?v=jEnd8JIMii4 HTMLMediaElement debug data https://www.youtube.com/watch?v=jEnd8JIMii4 mediasource:https://www.youtube.com/68445642-b9eb-2a49-957d-1aecf7665cb9 currentTime: 920.6712 SourceBuffer 0 start=0 end=920.717596 SourceBuffer 1 start=355.356 end=915.982 start=920.92 end=925.992 start=930.93 end=930.997 start=935.935 end=936.002 start=940.94 end=941.007 start=945.945 end=946.012 start=950.95 end=956.022 start=960.96 end=961.027 start=965.965 end=966.032 start=970.97 end=971.037 start=975.975 end=976.042 start=980.98 end=981.047 start=985.985 end=986.052 start=990.99 end=996.062 start=1001 end=1001.067 start=1006.005 end=1006.072 start=1011.01 end=1011.077 start=1016.015 end=1016.082 start=1021.02 end=1021.087 start=1026.025 end=1026.092 start=1031.03 end=1036.102 start=1041.04 end=1041.107 start=1046.045 end=1046.112 start=1051.05 end=1051.117 start=1056.055 end=1066.066 Internal Data: Dumping data for demuxer 1466bc000: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 920.717596 NumSamples:39652 Size:21432904 NextGetSampleIndex:39652 NextInsertionIndex:39652 Buffered: ranges=[(0.000000, 920.717596)] Dumping Video Track Buffer(video/webm; codecs=vp9) - mLastVideoTime: 359.559000 NumSamples:17748 Size:100425469 NextGetSampleIndex:126 NextInsertionIndex:17748 Buffered: ranges=[(355.356000, 915.982000), (920.920000, 925.992000), (930.930000, 930.997000), (935.935000, 936.002000), (940.940000, 941.007000), (945.945000, 946.012000), (950.950000, 956.022000), (960.960000, 961.027000), (965.965000, 966.032000), (970.970000, 971.037000), (975.975000, 976.042000), (980.980000, 981.047000), (985.985000, 986.052000), (990.990000, 996.062000), (1001.000000, 1001.067000), (1006.005000, 1006.072000), (1011.010000, 1011.077000), (1016.015000, 1016.082000), (1021.020000, 1021.087000), (1026.025000, 1026.092000), (1031.030000, 1036.102000), (1041.040000, 1041.107000), (1046.045000, 1046.112000), (1051.050000, 1051.117000), (1056.055000, 1066.066000)]

(In reply to Jean-Yves Avenard [:jya] from comment #6) > Jan, this video https://www.youtube.com/watch?v=XqLTe8h0-jo stalls at 6s > when webm is enabled Looking at the data coming from Youtube, this happens since the chunks appended do not contain a full cluster and MediaSegmentRange is set to all parsed SimpleBlocks available. Also checking for SimpleBlocks in IsMediaSegmentPresent demuxing can continue as more data is appended.

I've noticed that with MP4 now, like when seeking, they only send a partial media segment of about 1s ; probably so that the seek completes quickly and you can get immediately an image. maybe they recently changed how they are appending content.

Comment on attachment 8641610 [details] [diff] [review] Bug-1187247-MediaSegment-can-also-start-at-SimpleBlock.patch Review of attachment 8641610 [details] [diff] [review]: ----------------------------------------------------------------- This should probably accept a regular Block too. And please change the commit message; it's not correct that a media segment can start at a SimpleBlock per the spec. What's really happening (not that the current parser enforces this) is that we should be inside a media segment in the parsing loop and the appendBuffer is adding new frames.

(In reply to Matthew Gregan [:kinetik] from comment #10) > This should probably accept a regular Block too. ok also adding Block. > And please change the commit message; it's not correct that a media segment > can start at a SimpleBlock per the spec. What's really happening (not that > the current parser enforces this) is that we should be inside a media > segment in the parsing loop and the appendBuffer is adding new frames. updated commit message

https://hg.mozilla.org/integration/mozilla-inbound/rev/37ce03221f95 https://hg.mozilla.org/integration/mozilla-inbound/rev/15ef1802114f

https://hg.mozilla.org/mozilla-central/rev/37ce03221f95 https://hg.mozilla.org/mozilla-central/rev/15ef1802114f