Re: Question regarding endOfStream

Hi Guy,

Most of this sounds like it should be reported in a Chromium bug instead of
here, but I'll answer the questions here because it will show how MSE is
intended to operate in this situation.

Comments inline...

On Wed, Feb 20, 2013 at 5:42 AM, guy paskar <guypaskar@gmail.com> wrote:

> There is an issue I see when I play to the end of an fmp4 using MSE. The
> problem is that if I do not call endOfStream then the file is not really
> played until the end here are couple of symptoms that happened to me:
> 1)currentTime is not equal to duration when the movie paused (there is a
> small difference of ~0.02 in favor of duration)
>

This is because the UA doesn't know that all the data has been appended
yet. You have to call endOfStream() so the UA knows that more data isn't
coming. The difference is likely because the audio and video track are
slightly different lengths. Only when endOfStream() is called does the UA
know that it isn't missing data for that last 0.02 seconds of the
presentation.


> 2)'ended' event is not triggered when video stopped playing
>

This is because the UA doesn't know that it is at the end of the
presentation. The endOfStream() call is how the application signals that
"no more data is coming".


> 3) .buffered  values are wrong (same thing with the 0.02)
>

The buffered values are the intersection of the buffered ranges for each
track while in the "open" state. If one track is slightly longer then the
other, buffered will only show the time ranges where there is data for all
tracks. Once endOfStream() is called, the ranges are updated to reflect
that one track happens to be longer then the other one. This is why there
is a special step that checks for the "ended" state in the algorithm that
computes the buffered
attribute<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#htmlmediaelement-attributes>
.


>
> This is not happening when I play a webm. Is this an MSE bug or maybe a
> Gpac bug?
>

The content is likely muxed/encoded slightly different so the issue may not
be observable. There is also a known Chromium/WebKit bug where "ended" will
fire if currentTime reaches duration even if the media engine hasn't
explicitly signalled that the end of the presentation has been reached.


>
> Now this results the following problem:
> Consider the following scenario: a user start playing a video and seeks to
> 10 seconds before video ends and now see the video until the end. Now after
> appending the last chunk, if I do call . endOfStream() and the user decides
> to seek back and watch the rest of the video I can't really append more
> chunks because endOfStream was already called.
>

This is not quite right. The behavior in this situation has changed over
the life of the spec. Before the October 8th
update<https://dvcs.w3.org/hg/html-media/raw-file/6d127e69c9f8/media-source/media-source.html>to
the spec, the seek would have caused an automatic transition from
"ended" to "open". The current
spec<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html>text
causes this transition to happen when you call an append method in the
"ended" state. That behavior was introduced in the October 1st
revision<https://dvcs.w3.org/hg/html-media/raw-file/7bab66368f2c/media-source/media-source.html>to
the spec. Also seeking no longer causes a readyState transition.
Chrome
25 & above should have the current spec behavior & all previous versions
should have the older spec behaviors.


> If i decide not to call endOfStream() then it results the problem
> described above.
>

This is working as expected.

Aaron

>