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

Benoit Fouet benoit.fouet
Tue Jun 24 10:49:38 CEST 2008


Baptiste Coudurier wrote:
> Benoit Fouet wrote:
>   
>> Baptiste Coudurier wrote:
>>     
>>

[...]

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

well, let me rephrase: lavf has to know how to export extradata, and
this is where I fail to see any generic way.
for instance, for H.264 in QT, only the demuxer knows how to parse the
atom to reformat the SPS/PPS data.

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

"yet" being the important word here
that means you cannot use extradata field to handle a "generic" case

> Only application has to know how to fetch extradata and pass it to codec.
>
>   

the formatting of the extradata depends on the container, no ?
how is an application supposed to know how to parse / reformat extradata
to pass it to the decoder ?

> All players not using lavf do that to use lavc decoders like qdm2/alac ...
>
>   

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




More information about the ffmpeg-cvslog mailing list