AW: AW: AW: [vorbis-dev] PlusV algorithm -> CBR

gtgbr at gmx.net gtgbr at gmx.net
Fri Jan 31 13:52:51 PST 2003



Hannes wrote:
> > So even if I
> > > never meant strict CBR: what I really want is, correct,
> > constrained VBR,
> > > because it may of course also be less bandwidth than
> > possible. Does anyone
> > > know how can I tune vorbis to do that?
> >
> > With oggenc, a sample line would be
> >
> > oggenc --managed -b 30 -M 32 --resample 22050 input.wav
> Thank you, but I'm ashamed to confess I never used oggenc in my life, sorry.
> If you can speak 'vorbisenc', this would be more to the point. I will check
> the meaning of these settings and how oggenc handles them, however. There
> seems to be a lot of vorbis knowledge hidden in oggenc.

Sorry, I don't speak vorbisenc. oggenc.c, and most of all encode.c do.
:)

oggenc is the reference implementation of a Vorbis encoder, and it
supports everything that libvorbis* does (and a bit more, like
resampling and downmixing etc, to make it more useful).

It's a nice way to create .ogg files to test your streaming plans on
your own implementation with, I guess:

oggenc -h will give you the command line options; and the interesting
parameters would be -q, --managed, -b, -m and -M.

"-q <quality>" sets the quality for full VBR mode, the recommended
default of using Vorbis.
"-b <bitrate>" (without --managed and without -m or -M) indirectly sets
-q through the "nominal bitrate", which is a hint (no more, no less) on
where the resulting .ogg file will probably average. Like with -q, it's
full VBR.
"-b <bitrate> --managed" enables the bitrate management engine, and the
encoder tries to average around <bitrate> (ABR mode). Bitrate peaks are
much weaker and the result is pretty close to what you want in terms of
bitrates.
-m and -M always imply --managed and work with the -b switch. -m sets
the minimum bitrate, -M sets the max. It's still possible that short
peaks exceed -M, for example, but never for longer than 2 seconds, and
those 2 seconds are the theoretical maximum.

My experiments with oggenc's --advanced-encode-option (bitrate_hard_min
& -max) didn't work out either, so maybe we both do something wrong or
it just doesn't work right.

About that buffering and how long it has to be... how about this:

The user has 64 kbps ISDN or a 56 kbps modem. I would consider 40 kbps
to be the guaranteed downstream such a user can get. My stream is set to
average around 32 kbps and limited at 40 kbps (--managed -b 32 -M 40).
Although rare, it is possible that I get peaks over 40, but never for
longer than two seconds. During a peak, the listener still gets data
with 40 kbps, so the minimum buffer size has only to care about the
peak. Let's assume that it's a really evil peak - the stream is 44 kbps
during the whole two seconds, so in the end, 8 kilobits are missing.
With an 32kbps-average stream, 8kbits are 250ms. I don't know about
Vorbis' own latency that also adds up to this, but a buffer size/latency
of ~500ms (including a paranoia bonus) sounds reasonable to me. I might
be completely wrong, but I'm absolutely positive that at least 2 seconds
of buffering are not required - especially not in this example. It's
pretty rare that, even without the -M limit, the bitrate would get even
close to 40 kbps. Since the average of the stream is supposed to be 32
kbps, refilling that buffer with a 40 kbps downstream should be no
problem either.

Maybe some dynamic buffering mojo can make things even better ... like
not only having the buffering based on time (variable size in bytes) but
also make the time that the buffer holds variable, based on how good the
connectivity currently is. Would that work? :)

This is mostly based on my experience with the occasional
streaming-to-a-few-friends and the music I listen to - in the end, it
boils down to "make some real world experiments and see how it turns
out", I guess. Managed mode, without -m/-M, is restrictive enough for
the huge majority of streamable music. Also keep in mind that voice,
when applying a noise gate, contains much silence that compresses very
well, even with Vorbis.

Well ... I hope that's worth two cents. :)

<p>Moritz
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Vorbis-dev mailing list