W3C home > Mailing lists > Public > public-html-media@w3.org > July 2012

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

From: Aaron Colwell <acolwell@google.com>
Date: Tue, 10 Jul 2012 11:14:47 -0700
Message-ID: <CAA0c1bCyiKwh_PvahqgVizf3wXaT8QYoR65cN2kquX5nGkc8bA@mail.gmail.com>
To: Duncan Rowden <Duncan.Rowden@bbc.co.uk>
Cc: public-html-media@w3.org
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.
>
Received on Tuesday, 10 July 2012 18:15:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:24 UTC