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

[Benoit Fouet]

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...

> 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.

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