- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 15 Feb 2013 15:20:50 +0100
- To: public-html-media@w3.org
- Message-ID: <511E4442.5020407@telecom-paristech.fr>
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 excluded. > 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. Cyril > > 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 http://concolato.wp.mines-telecom.fr/
Received on Friday, 15 February 2013 14:21:21 UTC