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

[Baptiste Coudurier]

Benoit Fouet wrote:
> 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

Yes, I understand this, and this is the goal.

There are 4 points:
- How to retrieve extradata from the demuxer.
- Format it to feed the decoder.
- How to retrieve extradata from the encoder.
- Format it to feed the muxer.

Exporting all sufficient data is required which is what current
implementation misses atm.

Having functions would certainly be handy, and I guess this should go in
a bitstream filter especially for h264.

Also I think user could want to add a few other atoms in stsd while
muxing, it would be nice to allow this.

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

Yes, we need to move forward and address points separatly. Breaking
functionnal situation is not wanted, though uniformizing existing ones
would be nice.

For example svq3/alac/qdm2/mjpa decoder parses atoms to retrieve
informations, these codecs are almost only available in quicktime
however. mkv/flv uses mov formating for h264 extradata without atom
structure.

We all agree that extradata handling in mov is braindead.

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