Re: [MSE] Timestamp offset mechanism

Ok. This seems reasonable to me.

Question 2: I was just trying to determine if we wanted to provide a way
for the app to "rediscover" that an offset is currently active in case it
wasn't keeping track. Perhaps:

// Number levels of timestampOffset (ie how many popTimestampOffset() I
need to clear them all)
readonly attribute int timestampOffsetDepth;

or

// Indicates at least one timestamp offset is on the offset stack.
readonly attribute bool usingTimestampOffset;

I'm not sure how critical this is, but I could definitely see people
getting confused if they forgot that they called pushTimestampOffset() and
then had no way to detect that an offset is still being applied.


Question 4: Yes I think that an offset should stay in place across multiple
segments. I was thinking about events that would fire when push & pop
actions actually become active. For example if you pushed an offset while
in the middle of appending a media segment, it wouldn't take effect until
the end of that segment. Once the segment ended a 'timestampoffsetstart'
event would fire since that is when the new offset would start being
applied. If a pop happens mid-segment then a 'timestampoffsetend' would
fire when the current segment has been completely appended.

I'm not sure whether these events are really that useful or not, but I just
wanted to ask the question to see what people thought.

Aaron

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

>
>  On Jul 12, 2012, at 1:59 PM, Mark Watson wrote:
>
>
>  On Jul 12, 2012, at 12:58 PM, Aaron Colwell wrote:
>
> 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?
>
>
>  pushTimestampOffset() and popTimestampOffset() ?
>
>
>  2. How does the app determine that an offset is currently being applied?
>
>
>  Does it need too ? Since the app is the only one which can establish one.
>
>  peekTimestampOffset() ?
>
>
>  3. Should we model this as offset stack? I think Adrian suggested this
> during the last Media Source telecom.
>
>
>  Yes.
>
>
>  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.'
>
>
>  Hmm. I assumed the offset persists across multiple media segments until
> you cancel it.
>
>  You may, for example, have 200 segments of main media content that start
> at timestamps 0, 2, 3, … 398s. You feed in 100 of them without setting an
> offset. Then you have 15 ad segments with timestamps 0, … 28s and before
> feeding these in you call pushTimestampOffset( 200s ). Once finished with
> these you have to call popTimestampOffset() and pushTimestampOffset( 30 )
> before feeding in the rest of the media segments from the main content.
>
>
>  Oops, I mean pushTimestampOffset( 230s ) for the last one here as we are
> specifying the actual source buffer time where we want the next segment to
> appear, not the offset between internal media time and source buffer time.
>
>
>
>  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
>>>
>>>
>>
>
>
>