Closed Bug 1139522 Opened 9 years ago Closed 9 years ago

Do we need to delay 'updateend' until readyState has been properly updated?

Categories

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

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bholley, Unassigned)

References

(Blocks 1 open bug)

Details

See bug 1136399 comment 11. To reproduce this issue, just rejigger test_WaitingForData_mp4.html to wait for 'waiting' directly without first waiting for 'playing'. It should fail intermittently on windows when 'waiting' fires at t=0.
In http://w3c.github.io/media-source/#sourcebuffer-init-segment-received

which is called from segment parser loop

"
6. If the HTMLMediaElement.readyState attribute is HAVE_NOTHING, then run the following steps:

    If one or more objects in sourceBuffers have first initialization segment received flag set to false, then abort these steps.
    Set the HTMLMediaElement.readyState attribute to HAVE_METADATA.
    Queue a task to fire a simple event named loadedmetadata at the media element.
"

Right now, we let the MDSM handle all of this, the SourceBuffer/TrackBuffer expect the MDSM to do its magic at some stage in its own thread.

So yes, if we assume that setting HTMLMediaElement.readyState is synchronous, we should wait before continuing the step and fire updateend.

Note, that there's a few other places that require to change the HTMLMediaElement.readyState, in particular sourcebuffer.remove() which can move readyState back to HAVE_METADATA.

All of this could explain some of the intermittent failures we're still seeing.

But how to pass the information that the MDSM has finished?
Priority: -- → P2
Priority: P2 → P3
Component: Audio/Video → Audio/Video: Playback
this was fixed with the new MSE
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.