Re: ACTION-245: Implementation of Media Fragments from Dailymotion

Hi Davy,

>>>> For the ISO MP4 container (+ AVC/AAC codecs), serving the codecs setup data (AVC SPS/PPS and AAC setup) and the raw
>>>> samples is not enough, since there is no DTS/PTS information in the raw samples area (samples are just ... well, raw
>>>> data, sample after sample, audio and video samples interleaved in the file). You need to rebuild and provide some
>>>> time/space index tables (namely stts/ctts/stsc/stsz/stco/stss atoms, see ISO 14496-10).
>>>> 
>>>> So maybe you meant codecs setup data _and_ these index tables by "codec setup data". Otherwise these recipe won't work
>>>> for ISO MP4.
>>> 
>>> Thanks for raising this issue. Indeed, we never really defined in the spec what we mean with the term 'codec setup data'.
>>> From our point of view and as Davy clarified it in another thread, it consists of:
>>> - setup data for the decoder (such as resolution, quantification parameter, ...);
>>> - timing information (i.e., when to display a certain frame);
>>> - track information (i.e., which tracks are present and how does the raw samples relate to these tracks).
>>> So it _does_ include the index tables you are referring to which makes "workable" the recipe.
>> 
>> 
>> Understoud. So we would typically send the entire moov atom as "setup data". This would however prove sub-optimal
>> from a standpoint of bandwitdh, since the whole tables would need to be transferred, even is only a small portion of the
>> final media is played back to the user.
> That's right, but compared to the size of the media samples the size of the moov atom is limited.

Indeed, but it's still a performance hit for long video footages (for instance a 2 hours-long movie), both in terms of bandwidth
and memory space at the client side. It also mean that pre-seeked URLs (an URL with a pre-specified starting cuepoint)
would necessitate the download of the whole moov atom (not taking container pre-probing requests into account).

> Also, it seems hard to me that today's media players will not only load a part of the media samples, but also only a part of the moov atom.

I don't really see how you may load only part of the moov atom, since everything is packed in successive boxes and some
boxes use RLE compression. This would also result in multiple byte-range requests and unnecessary roundtrips, leading
to high latency on the first access.

> Does your player have such a behavior?
> 
>> Fragmented MP4 delivery address this issue by dividing the index tables and
>> packing them near the samples themselves (only the effective codec setup data remain separate).
> Agreed.


Regards,

-- 
Pierre-Yves Kerembellec | Senior IT Expert
Dailymotion | 49-51 rue Ganneron | 75018 Paris - France
Tel : +33 1 77 35 11 09 | Mobile : +33 6 08 91 46 15

Received on Friday, 13 January 2012 15:07:16 UTC