[Bug 21302] Support for inserting adverts as non-fragmented MP4 files

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21302

--- Comment #4 from Jon Piesing (OIPF) <oipfjon@gmail.com> ---
(In reply to comment #3)
> (In reply to comment #0)

<snip>

> > >Supporting non-fragmented files would require the UA to hold the whole file in memory which could be very problematic on memory constrained devices. 
> > 
> > The connected TVs and set-top boxes that are the primary target of our 3
> > organisations already support HTTP streaming of non-fragmented MP4 files
> > without having the whole file in memory.
> 
> That is because they are given a URL that contains the whole resource. The
> UA can fetch subsegments of the resource whenever it needs them. MSE
> intentionally defers media fetching to the web applications so this isn't an
> option.

Clearly this is the case for append but it is not remotely obvious that this is
still the case for appendStream(). See some of our other bugzilla issues.

<snip>

> As explained in my response on that bug, remove() and eviction (aka garbage
> collection) can happen for any time range. This means that any number of
> coded
> frames can be removed portions of the timeline covered by the non-fragmented
> file. Since the file isn't fragmented, the application has no choice but to
> reappend the whole file instead of only appending the relevant fragment that
> covers the evicted range.

For the specific case of adverts, this behaviour might be fine. If the advert
is appendStream()'d (say) 20-30s before it's needed, if it's evicted once it's
been played once then that's fine. The most likely scenario communicated by the
broadcasters is that adverts would only be played once and if the user played
through the content again, they would either see it without adverts or with
different ones.

We should discuss in the phone conference if these constraints would in fact be
fine for the specific case of adverts.

>  
> > >Non-fragmented files are so permissive about how they can store samples, there is no simple way to collect segments of the timeline w/o essentially exposing a random access file API.
> > 
> > In practise, the formatting of non-fragmented files must be constrained to
> > be playable on any kind of embedded device. These constraints don't seem to
> > cause particular problems in the industry.
> >
> 
> I would prefer to make this requirement explicit instead of just providing a
> blanket statement about non-fragmented files must be supported. I think
> tighter restrictions on the format of the files should be made.

I'll see if I can arrange someone to produce a summary of the restrictions that
can be discussed.

>  
> > >My expectation is that the web application using MSE will make sure that all the content it intends to use in a presentation is in fragmented format.
> > 
> > Fragmenting a 30s advert would seem to be unnecessary.
> > 
> 
> You can use a single fragment if you'd like, but it means that you'll have
> to reappend the whole thing if part of it happens to get evicted.

See my above comment - for the case of an advert that is played once only from
beginning to end then this restriction may be OK.

> 
> > >In my opinion the ad's should just be remuxed to fragmented form as part of the ingest process. Tools like GPAC<http://gpac.wp.mines-telecom.fr/> make this super easy.
> > 
> > The broadcasters that we are working with have a requirement to be able to
> > re-use their existing web advertising infrastructure as-is. Any changes that
> > have to be made for a particular platform will either delay or reduce the
> > probability of them providing content to that platform.
> 
> I don't understand this hard requirement. If they want to use MSE at all
> they are already going to have to reformat their non-ad content so I don't
> see why it is unreasonable for them to reformat the ad content as well. The
> required format conversion tools would be the same.

Firstly the 3 groups do not have a requirement to use MSE. They have a
requirement to support advert insertion for on-demand content. The 3 groups are
evaluating MSE as a solution to meet this requirement with the encouragement of
some common members between the 3 groups and the W3C.

The comment "If they want to use MSE at all they are already going to have to
reformat their non-ad content so I don't see why it is unreasonable for them to
reformat the ad content as well" indicates that some of the realities of how
web video advertising works haven't been communicated well enough. 

What I had to learn 6 months ago is that the ad content is provided and served
by 3rd parties. The broadcasters app just makes an XHR request to a server
operated by one of these 3rd parties, gets a response back (most likely in a
format called VAST). The response is parsed in JS and the URLs of the adverts
extracted. The video of the adverts is delivered by those 3rd parties, the
broadcaster has no involvement with the video at all. If MSE doesn't support
non-fragmented MP4 files then the broadcaster would have to find a video ad
provider who delivered video in fragmented MP4 files and switch their contracts
to them or just wait and not launch the service until video ad providers have
switched.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 17 March 2013 10:01:12 UTC