- From: Pierre-Yves Kerembellec <pierre-yves.kerembellec@dailymotion.com>
- Date: Fri, 13 Jan 2012 10:33:23 +0100
- To: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Cc: Media Fragment <public-media-fragment@w3.org>
>> 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. 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). 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 09:34:20 UTC