Oct 3, 2023, 18:39 by [email protected]: > Lynne: > >> The FFmpeg encoder will be modified to also output 2048 samples of >> padding at the start, to make it in line with other encoders. >> > > Once again: What is the advantage? Doing what lots of other codecs do is > not a real advantage. > >> >> + { "padding", "Override the padding at the start of a stream.\n", >> + offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 = >> 2048 }, 1024, 8192, AACDEC_FLAGS }, >> + >> > > A decoder is supposed to decode and output what is given to it by > default and not trim it according to what you expect to be normal for > encoders for a given format. It is not even clear that there are any > padding samples at the start: The first packet to be fed to the decoder > could be from the middle of a file. In other words, the default value of > samples to discard should be zero. >
There are always at least 1024 samples padded in all AAC files, this is how an MDCT operates. Currently, we let that bit of padding through, so absolutely no streams are gapless when played through our AAC decoder. 2048 is just more widely encountered. I'm posting these patches to get an opinion: - do we cut nothing at all (currently) - do we cut 1024 (required by the standard/algorithm, and currently what our AAC ENcoder outputs) - do we cut 2048 (what is most widely expected) My preference would be 1024. Note: this is only for raw AAC streams outside of a container. Streams inside of a container are currently correctly cut, with this value being overridden. There is also the issue of HE-AAC streams having a lot more padding, with a lot more variation, but that's for another patch to attempt to solve (which it probably couldn't). _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
