[FFmpeg-devel] [PATCH] aacdec: padding skip improvements
Lynne
dev at lynne.ee
Thu Oct 5 05:37:55 EEST 2023
Oct 3, 2023, 18:39 by andreas.rheinhardt at outlook.com:
> 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).
More information about the ffmpeg-devel
mailing list