Re: [MSE] Ad Insertion (was: [MSE] Timestamp offset mechanism)

Hi Duncan,

Comments inline...

On Wed, Jul 11, 2012 at 8:04 AM, Duncan Rowden <Duncan.Rowden@bbc.co.uk>wrote:

> Hi Aaron,****
>
> ** **
>
> Thanks for your comments. ****
>
> ** **
>
> Your assumptions on my first comment are correct, I believe a frame
> accurate pause and track switch would be very useful. This was what I was
> going for on my follow-up email when I suggested using a TextTrackCue to
> signal the switch:
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0109.html/.
> Kevin S and Steven R mentioned on this point that you could get a
> non-deterministic delay if you use this method, but I don’t think this is a
> problem as long as the content is paused frame-accurately. A viewer won’t
> notice a delay if the switch happens in less than 0.5s, but maybe this
> non-deterministic delay is much bigger than this? If this is the case, then
> as you stated this may be something for the HTML-WG to look at?
>

[acolwell] I think this would be the best path to accomplish what you are
trying to do. I think if you define a new TextTrack kind for playback
commands you could do a variety of other cool things too like timed track
switches, transitions, edits, etc. If you just specify the commands via
TextTrack.addCue() early enough the media engine could act on them in a
frame accurate manner even if the JS event notification is slightly
delayed. I'd be more than happy to provide feedback if you'd like to start
authoring such a proposal.


> ****
>
> ** **
>
> To answer your question on seeking back to an advert, this should be
> dictated through business rules. A Content Provider may wish to only show
> adverts at a given point in the timeline once. If you skip back to the
> ad-break point or before and press play again you won’t see any adverts at
> that ad-break point. It’s also conceivable though that you’re always shown
> the same ad’s at a given ad-break or that new ones are acquired each time.
>

[acolwel] Got it. I was just trying to visualize what the seek bar would
look like for this situation, but I guess the ad doesn't take up space on
it in this use case.


> ****
>
> On a side note: From personal experience I never really want to watch an
> advert again, but if the content provider wished to do so they could make
> references to viewed adverts available within their application.
>

[acolwell] :) I was thinking of something like Super Bowl (World Cup?) ads,
but I agree that I usually don't go back to rewatch ads


> ****
>
> ** **
>
> With regards to the overlap rules, maybe I have misunderstood them. If for
> example you have a segment that is placed on the time-line at t=100s ->
> t=110s and you want insert a 10s ad at t=105s, how would you achieve this?
> From my understanding of the rules the last 5 seconds of the segment would
> be overwritten by the ad and you’d somehow have to acquire those last 5
> seconds of that segment again and add them to the timeline.
>

[acolwell] Yes you are correct. I think I wasn't very precise in my
statement. The overlap can happen anywhere, but to avoid gaps you'll need
to do the insertion at a random access point. You are correct that you'd
need to reappend the last 5 seconds. The timestamp offset mechanism being
proposed would help with this though. Here is how:

sourceBuffer.timestampOffset = 10;
sourceBuffer.append(100-110); // Appends 100s-110s to 110-120s. This places
105s-110s @ 115s-120s.
sourceBuffer.timestampOffset = 0s;
sourceBuffer.append(100-110); // Appends 100s-110s. Establishes 100-105.
sourceBuffer.timestampOffset = 105; // Set offset so we can append 0s-10s
of the ad
sourceBuffer.append(0-10); // Appends the ad into 105s-115s.
sourceBuffer.timestampOffset = 10;
sourceBuffer.append(110-120); // Appends the next 10 seconds of content at
120s-130s.

Assuming there is a random access point @ 105s I believe this should result
in a seamless splice.

>
> In conclusion it appears to me that we are not being as comprehensive in
> covering as many use-cases as we could by adding the complexity of the
> timestamp offset mechanism.
>
[acolwell] I don't think we are talking about a lot of complexity here.
 This really just adds an offset to the timestamps for each frame before
they are inserted into the source buffer.

I agree it doesn't address all the ad use cases. It is just meant to
provide a way to insert/append content from a different timeline into the
presentation. This can enable some ad use cases as well as seamless
playlists or simulated live streams generated by concatenating on-demand
content.

Aaron

> ****
>
> ** **
>
> Regards****
>
> Duncan****
>
> ** **
>
> *From:* Aaron Colwell [mailto:acolwell@google.com]
> *Sent:* 10 July 2012 19:15
> *To:* Duncan Rowden
> *Cc:* public-html-media@w3.org
> *Subject:* [MSE] Ad Insertion (was: [MSE] Timestamp offset mechanism)****
>
> ** **
>
> ** **
>
> Hi Duncan,****
>
> ** **
>
> Sorry for the huge delay in my response. I was solely focusing on the
> object oriented API spec changes for a while. I'll be more responsive in
> the future. :)****
>
> ** **
>
> Comments inline...****
>
> On Mon, Jun 18, 2012 at 4:25 AM, Duncan Rowden <Duncan.Rowden@bbc.co.uk>
> wrote:****
>
> Hi Aaron,****
>
>  ****
>
> I agree that the use-cases you state are important and need to be catered
> for, but I have some reservations about the suggested API’s. ****
>
>  ****
>
> -          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.****
>
> [acolwell] These seem like policy decisions best handled by the web
> application instead of the browser itself. I don't quite understand how the
> ad won't contaminate the media timeline since at a minimum it would
> increase the duration of playback by the duration of the ad. I also don't
> quite understand how seeking is supposed to work. What if I decide I want
> to seek back into the ad after it has completed and the main presentation
> has resumed? Are you saying this wouldn't be allowed or could cause me to
> see a different ad? All this sounds to me like you need a different feature
> than what I am proposing here. It sounds like you want some sort of way **
> **
>
> to trigger a frame accurate track switch or pause.****
>
> -          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.****
>
> [acolwell] The ad does not need to be appended at a segment boundary. The
> standard overlap rules<http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#source-buffer-overlapping-segments> would
> apply which should allow one to place the ad anywhere in the timeline. Care
> would have to be taken though if any end overlaps exist because they may
> cause a gap in the timeline.****
>
>  ****
>
> As an alternative suggestion, I’d recommend keeping the separate media
> items on their own timeline and define a way to switch at particular points
> between the items?****
>
> ** **
>
> [acolwell] I think your best option would be to propose a frame accurate
> track switch feature to the HTML-WG since this doesn't sound like a
> MediaSource specific feature. If you had this then you could simply use two
> source buffers (1 for media and 1 for ad) for this use case and then use
> the track switch feature to switch between the tracks associated with these
> buffers. You'd still need the timestamp offset mechanism though so you
> could place the ad in the proper location in the timeline, but using 2
> source buffers would allow you to avoid the ad clobbering the main
> presentation media.****
>
>  ****
>
> Aaron ****
>
> ** **
>
>  ****
>
> Regards****
>
> Duncan****
>
>  ****
>
> *From:* Aaron Colwell [mailto:acolwell@google.com]
> *Sent:* 15 June 2012 23:41
> *To:* public-html-media@w3.org
> *Subject:* [MSE] Timestamp offset mechanism****
>
>  ****
>
> 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****
>
>  ****
>
>  ****
>
>
> 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.
>