Re: [MSE] Timestamp offset mechanism

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<mailto: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<mailto: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<mailto: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