W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

Re: [MSE] non fragmented MP4

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Fri, 15 Feb 2013 15:20:50 +0100
Message-ID: <511E4442.5020407@telecom-paristech.fr>
To: public-html-media@w3.org
Hi Aaron,

Le 14/02/2013 23:35, Aaron Colwell a écrit :
> Hi Giuseppe,
> There are no current plans to support non-fragmented MP4 files. One 
> thing to remember is that MSE  accepts byte streams and not files per 
> se. For MP4 we use the fragmented format because it allows segments of 
> the timeline to be appended easily and in any order.
Appending segments in any order may not be so easy. The MP4 spec says in 
the Movie Fragment Header Box definition:
"The movie fragment header contains a sequence number, as a safety 
check. The sequence number usually starts at 1 and must increase for 
each movie fragment in the file, in the order in which they occur. This 
allows readers to verify integrity of the sequence; it is an error to 
construct a file where the fragments are out of sequence."

So if you implement MSE on top of a conformant MP4 reader, feeding 
segment data as if they were consecutive in a 'virtual' file, this won't 
work. Segments with a sequence number smaller than the one of the first 
segment provided may be rejected. To make sure, the append happens 
correctly with an unmodified MP4 parser, the MSE implementation will 
have to parse each segment, check the sequence number and if needed 
reinitialize the parser before feeding the out-of-order segment.

> Supporting non-fragmented files would require the UA to hold the whole 
> file in memory which could be very problematic on memory constrained 
> devices.
Is there any requirement in MSE to keep the data in memory and not on disk?
> 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.
You could tell the same thing about non-fragmented files if the fragment 
is very long. Sure, you will more likely find large non-fragmented files 
than fragmented files with large fragments but the problem is the same. 
Small non-fragmented files (such as small clips, ads) should not be 

> The fragmented form allows the application to easily select the 
> desired segment and reappend it.
If possible! If your fragments are large, the application won't be able 
to do it (at least not easily).

> Applications can control the level of duplicate appending by adjusting 
> the fragment size appropriately.
I think you mean 'Content provider can control ...'? Web applications 
should be able to use content from different sources, with no control 
over the content generation, so possibly using non-fragmented files.

> 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.
Which exact difference in the non-fragmented (vs the fragmented storage) 
is problematic? For which situation? I don't understand what you mean by 
'collect segments of the timeline'. Which entity would need to do that? 
The web application? the MSE implementation? the MP4 parser? It is 
certainly easy for the MP4 parser.

In general, I think MSE can be viewed as an API to construct a playlist 
and have seamless playback of the elements of the playlist in an HTML5 
video element. There are complex playlist configurations with 
overlapping elements. I think the simple use case of seamlessly playing 
2 MP4 files sequentially should be supported.


> Aaron
> On Thu, Feb 14, 2013 at 4:19 AM, Giuseppe Pascale <giuseppep@opera.com 
> <mailto:giuseppep@opera.com>> wrote:
>     Hi,
>     is not clear to me if MSE has provision for supporting also non
>     fragmented MP4 files (section 8.2 only seems to describe
>     fragmented MP4).
>     Can someone give me some hints? Is alternating fragmented and non
>     fragmented mp4 files one of the use cases that you have
>     considered? How would that work?
>     /g
>     -- 
>     Giuseppe Pascale
>     Product Manager TV & Connected Devices
>     Opera Software

Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
Received on Friday, 15 February 2013 14:21:21 UTC

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