Should set the HTMLMediaElement.readyState attribute to HAVE_METADATA after received initialization segment

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: alwu, Assigned: alwu)

Tracking

(Blocks 1 bug)

Other Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
See spec [1], step6,

> 6. If the HTMLMediaElement.readyState attribute is HAVE_NOTHING
>   6.1 ...
>   6.2 Set the HTMLMediaElement.readyState attribute to HAVE_METADATA. 

In present code, if appended data contains both init segment and media segment, we wouod change readyState to HAVE_METADATA after received media segment. It's too late.

Also, [2] is not correct. In this situation, we've receive all segments in input buffer at that time, not just receive init segment.

You can reproduce this issue on following webpage.
https://alastor0325.github.io/htmltests/mse_tests/mse_no_end_of_stream.html

Open MediaDecoder:5,MediaSource:5,nsMediaElement:5, and then you could see the result.

[1] https://w3c.github.io/media-source/#sourcebuffer-init-segment-received
[2] http://searchfox.org/mozilla-central/rev/2ef8bd8a46a02c68ddbb1d5f25fa254dd7be1fbd/dom/media/mediasource/SourceBuffer.cpp#436
(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #0)
> Created attachment 8911063 [details]
> Log with MediaDecoder:5,MediaSource:5,nsMediaElement:5
> 
> See spec [1], step6,
> 
> > 6. If the HTMLMediaElement.readyState attribute is HAVE_NOTHING
> >   6.1 ...
> >   6.2 Set the HTMLMediaElement.readyState attribute to HAVE_METADATA. 
> 
> In present code, if appended data contains both init segment and media
> segment, we wouod change readyState to HAVE_METADATA after received media
> segment. It's too late.

No it is not, Because you won't get there until *all* buffer has been processed. So it is not too late.
What matters is when you return to the main event loop.

The operation is asynchronous, so as long as the events are in the proper order on the main thread, it's all that matter. The observable state will be no different between changing readyState after processing all the buffer, or processing just the init segment.



> 
> Also, [2] is not correct. In this situation, we've receive all segments in
> input buffer at that time, not just receive init segment.
> 
> You can reproduce this issue on following webpage.
> https://alastor0325.github.io/htmltests/mse_tests/mse_no_end_of_stream.html
> 
> Open MediaDecoder:5,MediaSource:5,nsMediaElement:5, and then you could see
> the result.
> 
> [1] https://w3c.github.io/media-source/#sourcebuffer-init-segment-received
> [2]
> http://searchfox.org/mozilla-central/rev/
> 2ef8bd8a46a02c68ddbb1d5f25fa254dd7be1fbd/dom/media/mediasource/SourceBuffer.
> cpp#436

You're misreading the line, or reading too much into it.

The value indicates that an init segment was received, and as such, per spec, the SourceBuffer should be added to Active source buffer list.

It has nothing to do with receiving a media segment or not.

What is a problem however, is that upon receiving a media segment, readyState should be moved to HAVE_CURRENT_DATA, however this is not happening synchronously and the task of doing so would be extremely complicated. Our whole architecture is asynchronous,and it's the MDSM that control when readyState change. At present, there's no way of linking data in a SourceBuffer to a particular decoded data received by the MDSM.

We will change the readyState once data has been decoded and displayed, and not once the media segment has been added to the source buffer.

I don't believe however that we can handle this task without a complete overall of the media architecture, for extremely little benefit (if any)
(Assignee)

Comment 2

2 years ago
After discussed with jya, we don't need this change, because it won't change anything from JS perspective, it's just change our internal state order.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.