[FFmpeg-cvslog] r13899 - in trunk/libavformat: isom.c mov.c

[Benoit Fouet]

Baptiste Coudurier wrote:
> Benoit Fouet wrote:
>   
>> Baptiste Coudurier wrote:
>>     
>>> Hi,
>>>
>>> Michael Niedermayer wrote:
>>>   
>>>       
>>>> On Mon, Jun 23, 2008 at 10:53:07AM +0200, Benoit Fouet wrote:
>>>>     
>>>>         
>>>>> Benoit Fouet wrote:
>>>>>       
>>>>>           
>>>>>> Baptiste Coudurier wrote:
>>>>>>   
>>>>>>         
>>>>>>             
>>>>>>> Hi,
>>>>>>>
>>>>>>> bcoudurier wrote:
>>>>>>>
>>>>>>>     
>>>>>>>           
>>>>>>>               
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>  static const MOVParseTableEntry mov_default_parse_table[] = {
>>>>>>>> +{ MKTAG('a','v','s','s'), mov_read_extradata },
>>>>>>>>  { MKTAG('c','o','6','4'), mov_read_stco },
>>>>>>>>  { MKTAG('c','t','t','s'), mov_read_ctts }, /* composition time to sample */
>>>>>>>>  { MKTAG('d','i','n','f'), mov_read_default },
>>>>>>>>
>>>>>>>>       
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Btw this is really annoying to have to add specific atom parsing to
>>>>>>> retrieve extradata, applications cannot decode file with lavf, even if
>>>>>>> demuxer currently ouput correctly all samples.
>>>>>>>
>>>>>>> A generic way for exporting this is needed. Atm Im thinking of putting
>>>>>>> everything after 'stsd' generic fields in extradata. What do you guys
>>>>>>> think ?
>>>>>>>
>>>>>>>
>>>>>>>     
>>>>>>>           
>>>>>>>               
>>>>>> well, that will need some rework in decoders, but would save a lot of
>>>>>> work in the demuxer
>>>>>>
>>>>>>   
>>>>>>         
>>>>>>             
>>>>> well, on second thought... this will also break compatibility with other
>>>>> containers
>>>>>       
>>>>>           
>>>> yes
>>>>
>>>>
>>>>     
>>>>         
>>>>> , no ? and also break decoders people would have written using
>>>>> lavf...
>>>>>       
>>>>>           
>>>> yes
>>>>
>>>> it would also break stream copy
>>>>
>>>>     
>>>>         
>>> Of course there are some things to change, to allow this, but definitely
>>> this is the goal to achieve, I mean there is no use to be so correct and
>>> generic when exporting samples, but not exporting extradata in a generic
>>> way.
>>>
>>>   
>>>       
>> I'm not sure there is a generic way to export extradata...
>>     
>
> In Quicktime there is, by looking at how mplayer handles binary qt
> codecs, it passes full stsd to codec, passing just atoms after standard
> fields might be enough.
>
>   

as long as it is not done in extradata, that could work...

>>> One solution Benoit suggested is to have a default case, and export
>>> everything after stsd when atoms are not recognized, but this will
>>> produce a different behaviour based on codecs and Im not sure this is
>>> good for the API.
>>>
>>>   
>>>       
>> and this will also break when we know how to handle the extradata we
>> pushed in a "generic" way.
>>
>>     
>
> Humm Im not sure to understand what you mean here.
>
> IMHO the only solution is to export more that what it is atm.
> What needs to be discussed is formatting and api.
>
> A solution which would not breaking anything would be to add
> extended_codec_data field to AVCodecContext which would contain full
> stsd or atoms, so original extradata is kept for backward compat.
>
>   

that could be a solution, even though it would duplicate extradata when
lavf knows how to handle it.

> Also it's up to the application to follow the <defined> api to pass
> extradata to muxers. Muxers should document what they expect as
> extradata especially mov and mkv, and because of their mess, for each codec.
>
>   

this is going to be a good documentation round :)

-- 
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com