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

[Baptiste Coudurier]

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.

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

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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA