[FFmpeg-devel] [PATCH] avformat/apngenc: use the stream parameters extradata if no updated one is made available

Hendrik Leppkes h.leppkes at gmail.com
Thu Nov 3 10:52:54 EET 2016


On Wed, Nov 2, 2016 at 9:20 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 02.11.2016 21:10, Hendrik Leppkes wrote:
>> On Wed, Nov 2, 2016 at 8:13 PM, Andreas Cadhalpun
>> <andreas.cadhalpun at googlemail.com> wrote:
>>> On 01.11.2016 23:10, Hendrik Leppkes wrote:
>>>> Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
>>>> andreas.cadhalpun at googlemail.com>:
>>>>> Not again, but instead, as the extradata is then only transferred as side data.
>>>>> That way it is again consistent between demuxer/decoder and encoder/muxer.
>>>>>
>>>>
>>>> I don't think thats a good idea. Demuxers should fill the extradata field
>>>> if any is present and required for decoding - some other decoder might want
>>>> extradata for init or something, and that way you can accommodate it
>>>> without having to wait for the first packet.
>>>
>>> Is this documented somewhere?
>>
>> What documented?
>
> You're claim that 'Demuxers should fill the extradata field'.
>
>> This seems quite logical. If you have extradata, set extradata in codecpar
>
> It's not logical to do this, if it's not necessary, e.g. for the apng demuxer.
> It is only necessary if the decoder actually needs this information during
> init, but the apng decoder does not.

Hence my point about trying to stick to a common behavior scheme
without looking at what *OUR* decoder needs - there could be others,
after all.
Its common to write extradata into codecpar if its present. You can
try to dispute that as long as you wish, but that doesn't make it any
less true.

avcodec is not the only thing people use avformat with, and
vice-versa, so sticking to common patterns makes the life easier for
those.

Do we really need to write this down somewhere to convince you, what
do we have the ML for then if we can't inform contributors about
common practice?

- Hendrik


More information about the ffmpeg-devel mailing list