[Vorbis-dev] contstant bittrate mode - block size - packet size

[xiphmont at xiph.org]

On 5/1/07, ian lutz <ianlutz at gmail.com> wrote:

> since we need a constant bittrate (i.e. constant packet size)

You will never get constant packet size out of the reference libs, and
you will have some amount of trouble doing that within spec (ie, doing
a good job) even if you wrote your own algorithms.  For a start,
vorbis does not group 'short blocks' together into a single packet
equal in length to a long block, so that alone will give you fits.

Leaving that aside, both vorbis and mp3 'cheat' to get CBR.

In mp3 a single mp3 packet does not always equal an integral mp3 frame
(the frame size is kept the same but the amount of audio it holds
sloshes around using a 'bit reservoir').  I believe the rule of thumb
in mp3 is that you need up to nine frames to make sure you're certain
to reconstruct a desired frame of audio (it was either nine or seven,
can't remember which).

In Vorbis, a single packet always yields a single frame of audio.
However, the packet size varies significantly.  CBR is implemented by
implementing a 'bit reservoir' like in mp3, but the reservoir is not
hidden behind constant sized frames.  However, like mp3, the reservoir
limits will not be viloated.

> my tests on changing the different parameters for encoding shows that no
> matter what settings i use (at least i can think of) do I get a constant
> packet size out of the encode.

Correct.

> also when getting a block to encode from the vd structure the encode seems
> to require multiple reads of the imput to get enough data to get a block for
> encode

Correct.  the blocking algorithm must work ahead by a minimum amount
to do short/long block detection.  Unlike most mp3 decoders, it is not
always working ahead the maximum amount; it appears to vary due to
lazy evaluation.  It will not blindly buffer blocks if it already
knows it does not need to and also if it suddenly needs blocks to work
ahead it can ask for them all at once.

> the expected behaviour of CBR is that we put in say 20ms of audio (882)
> samples and for a CBR compression to 384kbs should produce 960 Byte packets
> iof compressed audio.

That is likely impossible in the current Vorbis->Ogg mapping.  You'd
need to write a layer, like in mp3, where the varying packet sizes are
hidden by the framing algorithm (thus making the framing provided by
Ogg unnecessary, which was part of the impetus for doing that in mp3.
If you provide your own framing, the container doesn't need to, and
many containers can't).

Monty