Re: [MSE] Timestamp offset mechanism

Yes. The idea was to prevent the app from having to worry about the
internal timestamp and only worry about the presentation times. I think
this API needs some polishing though.

Here are some outstanding questions I have:

1. nextSegmentStartTime() & clearTimestampOffset() names are a little
clunky and don't seem related. Alternate name ideas anyone?

2. How does the app determine that an offset is currently being applied?

3. Should we model this as offset stack? I think Adrian suggested this
during the last Media Source telecon.

4. Should events be defined to signal when an offset starts/stops being
applied? Effectively this marks the beginning of the next media segment
after either method is called.

5. Does anyone have an alternate proposal for applying offsets?

Aaron

On Wed, Jul 11, 2012 at 9:26 AM, Mark Watson <watsonm@netflix.com> wrote:

>  Actually, I liked the nextSegmentStartTime (option 3). That is, assuming
> I remember correctly that what it does: establish a mapping from internal
> media time to source buffer time such that the next segment is placed at
> the provided source buffer time. (strictly, the mapping is established when
> the next segment arrives).
>
>  This obviates the need for the app to understand much about the internal
> media time.
>
>  ...Mark
>
>  Sent from my iPhone
>
> On Jul 10, 2012, at 11:50 AM, "Aaron Colwell" <acolwell@google.com> wrote:
>
>   Hi All,
>
>  I'm going to try to summarize what I've read on this thread to see if I
> understand everyone's position
>
>  1. Eric, Steve, & Kevin all support the sourceTimestampOffset() signature
> 2. Mark doesn't have a strong preference either way, but is leaning
> towards sourceTimestampMapping() because it is more explicit about the
> application needing to know about the internal timestamps in the media
> segments and how they should map to the presentation timeline.
> 3. The alternative nextSegmentStartTime()/clearTimestampOffset()
> suggestion mentioned at the bottom of
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0095.html got
> no votes
> 4. Duncan feels this mechanism isn't sufficient to address ad-insertion
> use cases he cares about. I just started an Ad Insertion thread<http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0033.html> to
> continue the discussion. This may require adding a new feature.
>
>  Let me know if this is correct or if I've missed something.
>
>  Thanks,
> Aaron
>
>
> On Fri, Jun 15, 2012 at 3:40 PM, Aaron Colwell <acolwell@google.com>wrote:
>
>> Hi,
>>
>>  Bug 17004 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17004> proposes
>> a mechanism for adjusting timestamps inside media segments. This enables
>> seamlessly splicing content together that doesn't originally exist on a
>> common presentation timeline. Inserting advertisements into content is the
>> most straight forward use case. There has been some useful discussion in
>> the bug comments, but we haven't decided on which method signature to use
>> for specifying the timestamp adjustments.
>>
>>  Here are the proposed signatures at this point:
>>
>>  void sourceTimestampMapping(in double presentationTimestamp, in double
>> segmentTimestamp)
>>  -- or --
>> void sourceTimestampOffset(in double timestampOffset)
>>
>>  sourceTimestampMapping() just provides a way to say, "I want this
>> timestamp in the segment to map to this presentation time."
>> sourceTimestampOffset() is basically just saying, "Add this offset to any
>> timestamp in the segment to get the desired presentation time."
>>
>>  Fundamentally they do the exact same thing, but I'm looking for input
>> on which option people feel more comfortable with.
>>
>>  Which do you prefer?
>> Are you ok with the semantics outlined in the bug description<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17004#c0>
>> ?
>>
>>  Aaron
>>
>>
>