Re: [MSE] Timestamp offset mechanism

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.