RE: [MSE] Timestamp offset mechanism

Yang,

One problem I mentioned earlier (and you may be alluding to as the segment overlapping part?) was around inserting ads midway through a segment.
Another use-case that can't be supported is when a content provider doesn't know in advance what ads are going to played and therefore how big your advert gap on the timeline has to be.

Duncan


-----Original Message-----
From: Sunyang (Eric) [mailto:eric.sun@huawei.com] 
Sent: 19 June 2012 15:06
To: Duncan Rowden; Kevin Streeter; Mark Watson; Steven Robertson
Cc: Aaron Colwell; public-html-media@w3.org
Subject: 答复: [MSE] Timestamp offset mechanism

Hi Duncan

I am not very familiar about the video editing mechanism.
But I can see that this proposal is closely relative with ad-insertion use case, I add ad in some range of the timeline....etc.
Can you elaborate which use cases of ad-insertion not supported by offset-mapping proposal?

But for the segment overlapping part of the method, I agree with you, it is a little complex.

Yang
Huawei

-----邮件原件-----
发件人: Duncan Rowden [mailto:Duncan.Rowden@bbc.co.uk]
发送时间: 2012年6月19日 19:50
收件人: Kevin Streeter; Mark Watson; Steven Robertson
抄送: Aaron Colwell; public-html-media@w3.org
主题: RE: [MSE] Timestamp offset mechanism

All,

I think it would be useful to consider which specific use cases this proposal caters for.  In the recent discussion, I think it's clear that there are a number of ad-insertion related use cases that are not supported by the offset-mapping proposal and which would have to be handled at the application level.

I also think that implementing the offset-mapping proposal including its support for partially overlapping segments would be complex. My gut feeling is that the complexity may outweigh the benefits of the
(limited) use-cases that it supports.

Are there other use cases besides ad-insertion that require this approach?

If the full range of ad-insertion use cases has to be handled in the application layer, it seems to me that there needs to be a mechanism to act on the media timeline in a frame-accurate manner.  The proposal to use a TextTrackCue on bug 17004 seems to go some way towards this perhaps through the use of the pauseOnExit flag? This is something that would empower more use-cases than just ad-insertion, such as event driven augmented media.

Regards
Duncan

-----Original Message-----
From: Kevin Streeter [mailto:kstreete@adobe.com]
Sent: 18 June 2012 21:10
To: Mark Watson; Steven Robertson
Cc: Duncan Rowden; Aaron Colwell; <public-html-media@w3.org>
Subject: RE: [MSE] Timestamp offset mechanism

I think Mark and Steve have described the situation well: the ability to map content into a single media source timeline is distinct from the ability to switch sources.  It may be useful and powerful to be able to do the latter, but it is the former the timestamp offset mechanism is intended to solve for.  As Steve noted, to create a truly seamless playback experience that works well across implementations you really need to map the content into a single source timeline.

Duncan is definitely right about needing to support different ways to manage the ads that are spliced in, though.  In the commentary on Bug
17004 there is a discussion around timeline tracking that is directly related to this issue.  In order to create proper user interfaces for presentations with ads we need a robust way to know where the ads are in the timeline, and to be able to create user experiences that utilize this information.  This would allow the application writer to force ad playback or to prevent seeking into the middle of an ad.  Importantly, it should also allow cases where seeking into the middle of an ad or skipping an ad is encouraged.  We should just set up the mechanism and allow the application to determine the policy.

-K


-----Original Message-----
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Monday, June 18, 2012 11:42 AM
To: Steven Robertson
Cc: Duncan Rowden; Aaron Colwell; <public-html-media@w3.org>
Subject: Re: [MSE] Timestamp offset mechanism

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

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.

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.

...Mark

On Jun 18, 2012, at 10:01 AM, Steven Robertson wrote:

> On Mon, Jun 18, 2012 at 4:25 AM, Duncan Rowden
<Duncan.Rowden@bbc.co.uk> wrote:
>> -          Ideally, when inserting an advert, this won't contaminate
the
>> main media item's timeline. The reasoning for this is that when ads 
>> are inserted, a content provider may only wish these to be viewed 
>> once. So when rewinding back through a given point either another ad 
>> can be inserted or playback can occur without showing an ad.
> 
> My understanding was that duration calculation from an initialization 
> segment was not possible, at least in BMFF, given that neither edit 
> lists nor the 'mehd' box are required, and anyway hitherto-unimagined 
> uses of the Media Source API would be difficult to account for with 
> any standard notion of a single timeline. As a result, it seems like 
> the intention is to leave presentation of a scrubber and transport 
> controls to the application for complex cases. It's easy to verify the

> behavior of a scrubber across multiple platforms (just look at it and 
> maybe interact with it); it seems much harder to deal with subtle 
> implementation-specific details of a source buffer switching mechanism

> across multiple platforms, since one can only interact with it 
> temporally and indirectly.
> 
> Although using source-switching to composite seamlessly to a single 
> timeline below the source-buffer level is conceptually similar to 
> compositing to a single timeline at an application-controlled level, I

> feel that source-switching would be the origin of a lot of platform 
> quirks that would be challenging to understand and correct for. The 
> source buffer logic is already both very author-friendly and quite 
> non-trivial to implement correctly; adding another invisible layer 
> beneath that would be more complicated still. I believe that making 
> things easier on implementors by giving them a single contiguous 
> stream of buffers with consistent timestamps - which is basically what

> they get anyway from a traditional demuxer - will result in much more 
> consistent behavior across platforms, which is better for authors and 
> users.
> 
>> -          The point at which ads need to be inserted may not
necessarily
>> coincide with a segment boundary, which as I understand it would be 
>> required using this proposal.
> 
> Interstitials must always start _with_ a segment boundary, but they 
> don't necessarily need to be inserted starting _on_ a segment boundary

> in the original timeline. A UA can call sourceAbort() and start 
> appending the interstitial, or can simply append a complete segment of

> the original content and then append the interstitial media.
> 
> [That said, the quality of experience on some platforms is likely to 
> be significantly degraded (i.e. system crash) if interstitials start 
> anywhere but a segment boundary. We're working around it, but these 
> kinds of issues are likely to be common, and unlikely to be fixable 
> without some kind of user-obvious deviation from the spec like long 
> pipeline flushes.]
> 
> Steve
> 
> 



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
					


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Tuesday, 19 June 2012 17:00:19 UTC