[FFmpeg-devel] [RFC PATCH 1/3] aacdec: always skip the first 2048 samples if there's no side data

[Lynne]

Sep 12, 2023, 09:43 by andreas.rheinhardt at outlook.com:

> Lynne:
>
>> For some reason, this was never set, which meant all **raw** AAC in ADTS
>> streams, except faac, had extra samples at the start.
>>
>> Despite this being a standard MDCT-based codec with a frame size of 1024,
>> hence a delay of 1024 samples at the start, all major encoders, excluding
>> faac and FFmpeg, use 2048 samples of padding.
>>
>> The FFmpeg encoder will be modified to also output 2048 samples of padding
>> at the start, to make it in line with other encoders.
>>
>
> Does this also have actual advantages besides "being in line with other
> encoders"?
>

Not really. I don't have an opinion on this. 1024 is the natural
delay of the codec, so maybe it would be best to leave it at that.


>> Yes, this leaves FATE pretty sad. Will fix it with the real version of the patch.
>>
>
> Didn't we once guess the number of skip samples like this, only for this
> guesswork to be removed intentionally? (This is not a rhetorical
> question; I thought it to be true, but I see that there is still code
> for faac in decode_fill(); maybe I misremember.)
>

I don't remember something like that. The faac workaround dates back
from 2012 (bfe735b5824c7d10ba42932a17d786db50e3b2d4), and it's only for faac.
It's less of a guess, as most encoders to use the FIL extension to signal
themselves.