1141333 - Distinguish readyState=ended due to error

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P2)

Description

[Jean-Yves Avenard [:jya]]

We should be able to distinguish if the end of stream algorithm was called with an error set or not.

If error is not set:
        1. 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.
        Note
        This allows the duration to properly reflect the end of the appended media segments. For example, if the duration was explicitly set to 10 seconds and only media segments for 0 to 5 seconds were appended before endOfStream() was called, then the duration will get updated to 5 seconds.
        2. Notify the media element that it now has all of the media data.

Currently we make no distinction, and only store that we are in ended mode.

When EndOfStream() was explicitly called, MediaSourceReader shouldn't return WAITING_FOR_DATA.

Comment 1

[Jean-Yves Avenard [:jya]]

In the above message, the reference is http://w3c.github.io/media-source/#end-of-stream-algorithm

Comment 2

[Jean-Yves Avenard [:jya]]

Attachment: Mark reader has ended when EndOfStream explicit

Consider an explicit call to EndOfStream (with no error) as meaning we have all the data. Also signal the MediaSourceReader when we move from ended to open (we could only ever turn on ended mode before). We still need to handle properly when going into ended mode, such as aborting current wait. This will be done in bug 1143971.

Comment 3

[Jean-Yves Avenard [:jya]]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/2ee1fb53c59c

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/43525f7e2fd9

Comment 5

[Ralph Giles (:rillian)]

Comment on attachment 8579733 [details] [diff] [review]
Mark reader has ended when EndOfStream explicit

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: Spec compliance. Could cause unnecessary network traffic or confuse player js content.
[Describe test coverage new/current, TreeHerder]: Landed on m-c.
[Risks and why]: Change is confined to the MSE code, and a straightforward implementation of a documented TODO. Looks safe enough to me.
[String/UUID change made/needed]: None.

Comment 6

[Ralph Giles (:rillian)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dcc5ad62d9b2