W3C home > Mailing lists > Public > public-html-media@w3.org > July 2012

Re: [MSE] Define how presentation duration is set & updated

From: Aaron Colwell <acolwell@google.com>
Date: Wed, 18 Jul 2012 11:40:31 -0700
Message-ID: <CAA0c1bB8U4zKQ6-utmOXux6BdwkqiPuyqceET75Nnf6HLLkiAw@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
Hi Mark,

Comments inline...

On Thu, Jul 12, 2012 at 2:06 PM, Mark Watson <watsonm@netflix.com> wrote:

>  On Jul 12, 2012, at 1:28 PM, Aaron Colwell wrote:
> Hi,
>  I wanted to start a discussion about Bug 17071<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17071> which
> talks about how to establish the presentation duration. Here is the gist of
> the proposal.
>  1. Add a duration attribute to the MediaSource object
> partial interface MediaSource {
>   attribute unrestricted double duration
> };
>  2. duration is NaN while MediaSource.readyState == "closed"
>  3. If duration is NaN and an initialization segment with a duration is
> appended, then duration becomes the value contained in the initialization
> segment.
>  4. When MediaSource.readyState == "open", duration can be set anytime
>  by the web application with a value > 0 or positive Infinity. Using other
> values will be ignored and trigger an exception.
>  5. If duration is set to a value less than what is buffered in the
> MediaSource.sourceBuffers, then all data beyond the duration will be
> removed from each SourceBuffer.
>  6. HTMLMediaElement.readyState can't transition to HAVE_METADATA until
> duration becomes something other than NaN.
>  I expect people with live content will want to have the duration remain
> as NaN.

[acolwell] I believe the HTML spec
should be positive Infinity for live.

>  I think all of the above should be pretty uncontroversial, but I have a
> few questions.
>  - What should happen if a media segment is appended that starts before
> the duration and ends past the duration? Should the duration be updated or
> should the segment be truncated?
>  I'm not sure it matters much which we choose, but perhaps it is more
> robust to update it ? Frequently there are minor differences in the
> durations of different tracks of a piece of content (of the order of a
> frame or sample duration) and the duration reported in some content-wide
> metadata may be any one of these or even some duration taken from the
> source material.
[acolwell] I agree. I think it is best to update the duration.

> - What should happen if the entire media segment is beyond the duration?
>  Depends on the answer to the above question. If we're auto-updating the
> duration in that case I think the duration should be updated in this case
> too.

[acolwell] Agreed. This will update the duration as well.

> - What should happen if a new duration is set and
> HTMLMediaElement.currentTime is beyond that? Should this act like a seek to
> duration?
>  Seems reasonable. How does a media element deal with this in the
> non-MediaSource case ?

[acolwell] I don't think this case is possible in any current
implementation of the spec because I can't think of a way for any existing
http resource to suddenly get truncated to before the current playback
position. I think this only becomes possible when the application can
actually specify a duration.

I also thought of one other case:

If MediaSource.endOfStream() is called and media segments don't go all the
way to the current duration, should duration be updated to reflect the end
of the appended data?

For example, say I set the duration to 10 seconds, but only append 0-5
seconds and then call endOfStream(). Should duration become 5 seconds since
I can't append any more data? I think the answer should be yes, but I just
wanted to see what people think.

Another variant of this example is playing a live stream where the duration
is positive Infinity and then the event ends. It seems like it would make
sense to cause the duration to transition from positive Infinity to
whatever the difference between the start time of the presentation and the
end time of the last segment appended.

Received on Wednesday, 18 July 2012 18:41:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:24 UTC