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

Re: [MSE] Timestamp offset mechanism

From: Aaron Colwell <acolwell@google.com>
Date: Mon, 18 Jun 2012 12:28:35 -0700
Message-ID: <CAA0c1bAFo2iE+5anGKY-74OfSBvevF1OUWvpXgOQfr5uSZPYHw@mail.gmail.com>
To: Steven Robertson <strobe@google.com>
Cc: public-html-media@w3.org
comments inline...

On Fri, Jun 15, 2012 at 10:12 PM, Steven Robertson <strobe@google.com>wrote:

> On Fri, Jun 15, 2012 at 3:40 PM, Aaron Colwell <acolwell@google.com>
> wrote:
> > Which do you prefer?
> I prefer sourceTimestampOffset() for two reasons:
> - Edit lists and non-rational timescale fractions can complicate the
> process of matching the user-specified `segmentTimestamp` to the exact
> timestamp parsed from a media segment when using BMFF.

[acolwell] Both schemes assume that you know the actual timestamps in the
segment. One is not better than the other in this regard.

> - sourceTimestampMapping() requires a manifest with an entry for every
> media segment in order to identify the right value of
> `segmentTimestamp` before appending. Since pre-appending all of a
> stream's values might leave landmines in the timeline when appending
> future segments, this also encourages segments to be handed in
> separately. sourceTimestampOffset() is more flexible, allowing data
> (or, in the future, URLs) to be added in a less strictly
> segment-oriented manner.

[acolwell] I must not have explained things well when I described the two
options. You do not need a manifest with an entry for each segment if you
use sourceTimestampMapping(). sourceTimestampMapping() is the same as
calling sourceTimestampOffset(presentationTimestamp - segmentTimestamp).
 The only difference is that in one case you are explicitly providing an
example of how a segmentTimestamp maps to a presentationTimestamp.
sourceTimestampOffset() does this implicitly instead. There is no
difference in flexibility between the two.

> > Are you ok with the semantics outlined in the bug description?
> Looks good to me, barring one ambiguity: what's the lifetime of this
> setting? Does it get reset by an event/method call/initialization
> segment, or does it stick around on a source until it is changed by
> another call to sourceTimestampOffset()?

[acolwell] The intent is for the offset/mapping to stay active until it is
set again. The starting offset/mapping would be 0/(0,0) since this
indicates that no timestamp modification is occurring.
Received on Monday, 18 June 2012 19:29:05 UTC

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