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

Hi Mark,

 

Comments inline

 

Cheers

Duncan

 

From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: 11 July 2012 17:18
To: Duncan Rowden
Cc: Aaron Colwell; public-html-media@w3.org
Subject: Re: [MSE] Ad Insertion (was: [MSE] Timestamp offset mechanism)

 

Duncan,

 

Because the required behaviour for ad insertion is so dependent on
business rules, we should be thinking in terms of providing applications
with pretty low level tools that they can use to implement the required
behaviour. Otherwise we will inadvertently leave some use-case
unsupported.

 

I particularly think we should avoid having the Media Element manage
multiple timelines - for example a discontinuous 'main media' timeline
overlaid on a 'real time' timeline which also includes ads. 

[DR] As mentioned in my email I agree that frame accurate switching
between timelines should probably be discussed in the HTML WG

 

Despite the overlap rules, I think it's reasonable that if you are going
to do ad insertion with a single track, then it happens at segment
boundaries. In this case, ad insertion must happen immediately before a
random access point, because you are using a single decoder and it needs
to start at a RAP after the advert. The content must be encoded with ad
insertion in mind and precise knowledge of the ad insertion points. The
app must know exactly where these points are. Given this it's no big
deal to put a segment boundary there.

[DR] This isn't how the ad insertions process typically works in the UK
media industry. Content encoding is typically separated out from the
process that defines ad-boundaries (even for adaptive)

 

The Media Source extension with the timing offset feature supports the
use-cases you described, with the assumptions above, with one small
exception.

 

I can place adverts into the video elements timeline. I can render my
own controls which show only the main media timeline if I wish and map
this to the media element timeline in my app. I can fetch new adverts to
replace the previous one when the user seeks, all according to my
business rules.

 

The only issue I see is that when replacing a part of the media element
timeline with new material, I have no way to 'purge' what was there
before. If the network stalls then playback could spin straight off the
end of the 'new' material and into the 'old' material.

[DR] This assumes your ad break always have to be of the same length. If
they aren't some seeking forward or reacquiring of the content will be
required. Also I think you wouldn't end up with a smooth playback
experience if you wanted your media controller to skip the ad after it's
been consumed once.

 

For more advanced scenarios - for example where ad insertion happens
somewhere else than an I-Frame I think  you do need separate tracks or
even separate elements and frame-accurate switching.

[DR] See my first comment

 

Btw, why do you BBC guys care about ads?? ;-)

[DR] You're correct in implying that we don't show ads ourselves. The
BBC usually uses pre- and post-rolls on its content though. We're also
keen to create a standard that works for the UK media industry as a
whole though and is also workable for integration into embedded devices
such as set-top boxes and TVs.

 

...Mark


Sent from my iPhone


On Jul 11, 2012, at 8:06 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?

	 

	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. 

	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.

	 

	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.

	 

	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.

	 

	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. 


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.