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