[FFmpeg-cvslog] r13899 - in trunk/libavformat: isom.c mov.c
Baptiste Coudurier
baptiste.coudurier
Tue Jun 24 10:40:58 CEST 2008
Benoit Fouet wrote:
> 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.
lavf does not have to know how to handle extradata, it only has to
export it. Only codecs use extradata.
The more generic lavf is, the better it is for its users, that's why it
has codec_tag field etc.. to let applications handling what lavf does
not know (yet).
Only application has to know how to fetch extradata and pass it to codec.
All players not using lavf do that to use lavc decoders like qdm2/alac ...
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
More information about the ffmpeg-cvslog
mailing list