[FFmpeg-devel] [PATCH] avformat/matroskaenc: always reserve max aac private data

Andreas Rheinhardt andreas.rheinhardt at gmail.com
Fri May 1 22:42:46 EEST 2020


John Stebbins:
> On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
>> John Stebbins (12020-05-01):
>>> Well, current code in aac_adtstoasc silently ignores any
>>> changes.  It
>>> only generates extradata from the initial packet.  It's not checked
>>> in
>>> subsequent packets.
>>>
>>> So this would have to be "fixed" in aac_adtstoasc as well if you
>>> want
>>> to add error logging.
>>
>> Probably. I want to emphasize that bugs in our current code cannot be
>> considered precedent to accept similar bugs in new code.
>>
>>> This is also a bit beyond my expertise.  I don't know what would
>>> constitute incompitible parameters beyond a few obvious
>>> things.  I'm
>>> not well versed in aac details.
>>
>> Then for now, I would say that we can only accept when it is
>> bit-identical with the extradata already there. If we cannot test for
>> compatibility more finely, then we have to assume incompatibility and
>> reject every AV_PKT_DATA_NEW_EXTRADATA with an error.
>>
>>
> 
> Seems reasonable.  To be clear, this should result in an error returned
> up the call stack (i.e. av_interleaved_write_frame would ultimately
> return an error), and an error log?
> 
I'd rather opt to only warn in such a case unless strict_std_compliance
is >= FF_COMPLIANCE_STRICT. And maybe we should also discard all future
packets from this stream until we get one with side data matching the
CodecPrivate one?

- Andreas


More information about the ffmpeg-devel mailing list