Investigate test_WaitingOnMissingData_mp4.html end times

REOPENED
Unassigned

Status

()

P3
normal
REOPENED
4 years ago
2 years ago

People

(Reporter: bholley, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
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.
Component: Audio/Video → Audio/Video: Playback
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
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
reopening as comment 2 is no longer correct: we do drain the decoder when reaching a gap. End time should always be consistent
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I believe we hit a condition where skip to next keyframe is hit, or frames are dropped because they were too late
Depends on: 1314534
You need to log in before you can comment on or make changes to this bug.