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

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

Aaron Colwell <acolwell@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acolwell@chromium.org

--- Comment #3 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #0)
> This issue results from a joint meeting between the Open IPTV Forum, HbbTV
> and the UK DTG. These organizations originally sent a liaison statement to
> the W3C Web & TV IG:
> 
> https://lists.w3.org/Archives/Member/member-web-and-tv/2013Jan/0000.html
> (W3C member only link)
> 
> The broadcasters in our groups have a preference to work with existing web
> advertising solutions. We are told that a number of these deliver adverts as
> non-fragmented MP4 files.
> 
> While we note the discussion in response to the email http://lists.w3.org
> /Archives/Public/public-html-media/2013Feb/0070.html, we don't understand a
> number of the reasons given for not supporting this. Here are comments on
> some of the reasons given in the public email thread.
> 
> >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.

> 
> >If the UA decides to garbage collect part of the presentation timeline to free up space for new appends it is not clear how the web application could reappend the garbage collected regions without appending the whole file again. The fragmented form allows the application to easily select the desired segment and reappend it. Applications can control the level of duplicate appending by adjusting the fragment size appropriately. 
> 
> As explained in W3C bugzilla #21299 the specification being rather unclear
> on memory management and garbage collection. It's hard to react to this
> comment based on what's currently in the specification.
>

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.

> >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.

> >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.

> >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.

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

Received on Saturday, 16 March 2013 16:20:49 UTC