[FFmpeg-devel] [WIP PATCH 0/1] avcodec/aacenc: improve bit_rate_tolerance=0

[Lynne]

On 15/09/2024 17:14, Pauli Virtanen wrote:
> la, 2024-09-14 kello 00:15 +0300, Pauli Virtanen kirjoitti:
> 
> [clip]
>> - it appears the resulting frame_bits depends also on some other state
>>    than s->lambda. iteration with lambda1, lambda2>lambda1, and then again
>>    with lambda1 can produce different frame_bits on the two lambda1
>>    iterations. Is there some state that is modified across iterations?
> 
> Looking at the code, there seem to be at least a few things:
> 
> 1. aacpsy analyze internal state, AacPsyChannel.prev_band
>     AacPsyContext.pe.previous, get updated on each re-encode iteration
>     of the same frame
> 
> 2. avoid_clipping() is applied on coeffs only on first iteration,
>     in later iterations coeffs can get overwritten by pcoeffs
> 
> 3. adjust_frame_information() changes sce->ics.max_sfb which would
>     affect clipping
> 
> The aacpsy prev state is documented to relate to previous frame, but it
> seems it can here be overwritten by that from the previous re-encode
> iteration. This looks a bit suspicious.
> 
> Probably the clipping factor also should be re-applied on re-encodes.
> 
> Maybe s->psy.model->analyze() should be done only on the first encode
> iteration, and the same bitres.alloc result be used for all potential
> re-encodes of the same frame?

I'll review this in a few days.
In general, the rate control system was hacked on over the years rather 
than designed to perform proper rate control from the start.

If this were a video codec, you'd use a denoiser in combination with 
adjusting the quantizer, but AAC fights you every step of the way to 
making something that makes sense, with vector quantization foiling most 
primitive denoisers, and the scalefactors being tied to both band energy 
and quantization foiling a proper encoder.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA2FEA5F03F034464.asc
Type: application/pgp-keys
Size: 624 bytes
Desc: OpenPGP public key
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240915/5a9ac39b/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240915/5a9ac39b/attachment.sig>