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.

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

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.

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

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.