[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