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.

Received on Tuesday, 19 June 2012 11:50:25 UTC