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

Benoit Fouet benoit.fouet
Tue Jun 24 11:23:59 CEST 2008


Baptiste Coudurier wrote:
> Benoit Fouet wrote:
>   
>> 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.
>>     
>
> Not necessarly. I don't see why lavf would have to know.
>
> What's needed by the codec is in stsd, lavf should export stsd IMHO,
> this would also solve the different codec/display resolutions problem,
> but yet to avoid duplication.
>
> I already said Quicktime API export stsd in a 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
>>     
>
> IMHO "all atoms after stsd" is far more generic than whatever butchered
> data present in any frining atom nobody knows about, same for mkv.
>
> Furthermore it is deadly simple to parse.
>
>   

yes it is...

>> how is an application supposed to know how to parse / reformat extradata
>> to pass it to the decoder ?
>>     
>
> Documentation, API.
>
> "mov/mp4/3gp demuxer exports in extradata all atoms present after stsd
> structure" is documentation, and generic for mov/mp4/3gp.
>
> "avi/asf/wmv/wav demuxer exports in extradata all bytes present after
> WAVEFormat/Ex/Extended structure"  is documentation and generic for
> avi/asf/wmv/wav.
>
> It seems obvious that every application does this currently, see below.
>
>   

then what would you think of having function(s) to parse the extradata
we know how to handle ?
that would ease the application developpers lives

>>> All players not using lavf do that to use lavc decoders like qdm2/alac ...
>>>
>>>       
>
> Anyway, a solution has to be found, will you jump in and propose a
> solution with a patch ?
>   

I don't think I'm not being constructive here...
yes, a solution has to be found, and I'm trying to do it with you, I
thought you saw that...

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




More information about the ffmpeg-cvslog mailing list