1277733 - [MSE] Last frame of cluster getting wrong duration

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect, P3)

Description

[Jean-Yves Avenard [:jya]]

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.

Comment 1

[Jean-Yves Avenard [:jya]]

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.

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3

Comment 3

[Alastor Wu [:alwu]]

Because the link in comment0 is already invalid, close thig bug.