1137574 - Investigate test_WaitingOnMissingData_mp4.html end times

Status: REOPENED

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

Description

[Bobby Holley (:bholley)]

See the bottom of bug 1136399 comment 5.

There are two issues here:

.duration appears to be the length of the longer source buffer (10.03102) rather than the shorter one (10.01).

.currentTime is _intermittently_ 10.076667 at the end.

Probably not super pressing, but worth investigating for the integrity of our media stack.

Comment 1

[Jean-Yves Avenard [:jya]]

As replied in bug 1136399, this is per spec

when sb.appendBuffer is called, source buffer coded frame algorithm is called:
http://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing
"If the media segment contains data beyond the current duration, then run the duration change algorithm with new duration set to the maximum of the current duration and the group end timestamp."

I implemented this behaviour in bug 1118123.

Additionally, when ms.EndOfStream() is called, the end of stream algorithm is called:
http://w3c.github.io/media-source/#end-of-stream-algorithm
"Run the duration change algorithm with new duration set to the highest end time reported by the buffered attribute across all SourceBuffer objects in sourceBuffers."

so videoelement.duration = mediasource.duration = max(sbvideo.buffered.end(sbvideo.buffered.length-1), sbaudio.buffered.end(sbaudio.buffered.length-1)) (assuming we only have an audio and video sourcebuffer).

What is not normal however, is that it could be intermittently 10.076667 : that should never happen.

Comment 2

[Jean-Yves Avenard [:jya]]

this end time will be consistent according the the OS it runs. We no longer drain the decoder when reaching an area with no buffered data ; as such whatever frames is available depends on the platform's decoder

Comment 3

[Jean-Yves Avenard [:jya]]

reopening as comment 2 is no longer correct: we do drain the decoder when reaching a gap. End time should always be consistent

Comment 4

[Jean-Yves Avenard [:jya]]

I believe we hit a condition where skip to next keyframe is hit, or frames are dropped because they were too late