RE: [MSE] Timestamp offset mechanism

I also prefer sourceTimestampOffset().  

In response to Steve's question on lifetime, I would vote for keeping the setting in place until explicitly reset.  This will make it easy to push several segments of spliced content into the timeline.  I think that with the semantics Aaron described simply setting the offset to '0' will do the job.

Thanks,
-K
________________________________________
From: Steven Robertson [strobe@google.com]
Sent: Friday, June 15, 2012 10:12 PM
To: Aaron Colwell
Cc: public-html-media@w3.org
Subject: Re: [MSE] Timestamp offset mechanism

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.

- 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.

> 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()?

Thanks,
Steve

Received on Sunday, 17 June 2012 17:18:43 UTC