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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
