Re: [MSE] Timestamp offset mechanism

comments inline...

On Mon, Jun 18, 2012 at 11:41 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> I think there are a couple of mis-understandings in the thread below.
>
> Firstly, this offset mechanism is not intended as a general solution to ad
> insertion. Certain simple kinds of ad insertion can be implemented this way
> (specifically the kind where the ads occupy specific intervals on a simple
> global linear presentation timeline and the only problem is mapping the
> ad-internal media timestamps to that timeline. For more complex ad
> insertion scenarios, I think we need to assume these will be taken care of
> by the application (absent some more worked out use-cases and proposals for
> browser features to support them).
>

[acolwell] Yes. I agree with Mark here. This is not intended to be a
general ad insertion framework. It is simply to facilitate embedding media
created on a different timeline into the presentation. If more complicated
insertion scenarios are needed, I think that is best handled by the
application.


>
> Secondly, I don't see any practical difference between the two proposals.
> There is no more or less need for "mapping tables" at the application in
> either case. It's am important feature of the current draft that media
> segments carry their own timing. No assumptions are made about the timing
> of a media segment on the basis of the previous media segment. For example,
> suppose I have media segments A with internal media timestamp range [ 0s,
> 2s ), B with [ 2s, 4s ) and C with [ 20s, 22s ). If I append A then B the
> result is a source buffer with media from 0s to 4s. If I append C then B
> the result is a source buffer with media from 2s to 4s and 20s to 22s. B
> ends up in the same place whatever went before.
>
> So, to correctly make use of either proposed function for insertion of
> content with a different internal timeline, the application needs knowledge
> about the current position in the timeline (i.e. the media internal
> timestamps of the already provided data) and the media internal timestamps
> of the to-be-inserted data.
>
> Another example. Suppose I have segments with media timestamps filling the
> range D= [0s, 60s) and more filling the range E=[60s,120s) and an advert
> the internal timestamps of which file the range F= [15,30s). If I want to
> play D then F then E, using mapping, I feed D, then a mapping (15s media ->
> 60s presentation), then F then another mapping (60s media -> 75s
> presentation) then E.
>
> Using offsets I feed D, then offset 45s, then F then offset 15s then E.
>
> I need to know the internal timestamps of both the segments and the
> advert, whether I use the "mapping" or "offset" function.
>

[acolwell] Yes. This is great description. I should have been more clear.


>
> Based on the above, I have no strong preference. The mapping option is
> perhaps better because it is more explicit. that the script needs to
> knowledge described above.
>

[acolwell] Another option we could consider is something along the lines of
nextSegmentStartTime(presentationTimestamp). The idea here is that you are
simply specifying where you want the next segment to be placed in the
presentation and the timestamp offset is computed implicitly. This would
prevent the application from having to know the exact timestamps in the
segment. Clearing this offset could be tricky though since using the same
method implies that you know the underlying timestamp in the segment. We
could add a clearTimestampOffset() to handle this, but it doesn't feel as
clean.