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.

Attachment: OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

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

Reply via email to