This can be seen in this example: http://people.mozilla.org/~jyavenard/tests/mse_webm/youtube-repeatframe.html The last sample of a cluster is getting its duration estimated as we can't know yet the exact duration (we will only know once the next cluster is appended) [MediaPlayback #1]: D/MediaSourceSamples TrackBuffersManager(11d7f5000:video/webm)::ProcessFrames: Processing video/webm; codecs=vp9 frame(pts:65065000 end:65132000, dts:65065000, duration:67000, kf:0) the next frame when demuxed is: [MediaPlayback #1]: D/MediaSourceSamples TrackBuffersManager(11d7f5000:video/webm)::ProcessFrames: Processing video/webm; codecs=vp9 frame(pts:65065000 end:65132000, dts:65065000, duration:67000, kf:1) so we get two frames with the same start time and duration. The first frame should have had a duration of 0 and not be dropped. This is the real cause behind bug 1276184. For now following the patches there, the frame will be dropped instead. As we always estimate the duration of the last frame of a cluster, sometimes the estimation is wrong. We should hold off demuxing the last sample with MSE if we can't determine exactly its duration, unless it's the last frame received and the source buffer goes into ended mode.
For now, I will simply attempt to process the entire content before attempting to demux it rather than doing it cluster by cluster; this will lower the impact of where the last sample's duration can't be determined.
3 years ago
Priority: -- → P2
Mass change P2 -> P3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.