# About Constant Bitrate Encoding

What most of us are used to when we encode an MP3 File, is that we can set a bitrate – such as 192kbps – and, the codec will produce an MP3 File with that bitrate. If that was all there is to it, we’d have Constant Bitrate encoding, aka ‘CBR’.

But in many cases, the actual encoding scheme is Variable Bitrate (‘VBR’), which has been modified to be Adaptive Variable Bitrate (‘AVBR’).

The way AVBR works, is that it nests the actual encoding algorithm inside a loop, with the premise that the user has nevertheless set a target bitrate. The loop then feeds the actual algorithm several quality-factors, to encode the same granule of sound, in multiple attempts, to find the maximum quality-factor, which does not cause the encoding to exceed the number of bits, which have been allocated for the algorithm to take up, in its encoding of 1 granule of sound.

This quality-factor is then also used, to produce output. And, in case the actual number of bits output are less than the allocated number of bits, the difference is next added to the number of bits that act as a target, with which the next granule of sound is to be encoded.

Encoding schemes that are truly CBR, are often ones which are not compressed, plus also perhaps ‘DPCM‘… Most of the other schemes, such as ‘MP3′ and ‘OGG’, are really AVBR or VBR.

(Updated 03/11/2018 : )

(As of 03/06/2018 : )

I think that in the case of Video codecs, the approach is modified slightly, due to the high computational cost of compressing 1 frame. In this case, if the present frame-set consumed fewer bits than allocated, the quality-factor is increased, with which the next frame-set is to be encoded. Conversely, since it can happen that the present frame-set took up more bits when encoded than the target suggested, the quality-factor can also be decreased for the next frame.

That way, with Video codecs, no frame actually needs to be encoded twice.

I guess that this poses the question, of how the initial quality-level is to be chosen, so that the first set of frames including a key-frame produces approximately the correct number of encoded bits, just So that the loop doesn’t go wild – an unstable feedback-loop – with a great excess or a great shortage to start. And there are two answers that would help:

1. The encoder could apply both a maximum bitrate, and a maximum q-factor, the lower of the two defining the actual quality, and
2. In the case of video, only the q-factor may be adjusted from one frame-set to the next, not the target bit-number, to enhance the stability of the loop. The result would be a slight but consistent undershoot, of the target bitrate.

(Edit 03/11/2018 : )

In fact, to prevent the q-factor from oscillating from one frame-set to the next, the algorithm can actually wait, until the real bitrate differs from the ideal bitrate, by a ratio that exceeds the ratio between two q-factors. It’s not perfect, but may prevent oscillation:


a = 'Patience'
a > 1.0
a ~= 2.0

Qmin ~= 6

r =
(float(Bitsmax) / Bitsreal - 1.0) * Qcurrent

if ( r > a && Qcurrent < Qmax ) {
Qcurrent++;
}

if ( r < 0.0 && Qcurrent > Qmin ) {
Qcurrent--;
}




Dirk

## One thought on “About Constant Bitrate Encoding”

This site uses Akismet to reduce spam. Learn how your comment data is processed.