[vorbis] RE: [advanced] Response to Ogg Vorbis comments

[Gregory Maxwell]

On Fri, Jun 22, 2001 at 11:37:01PM -0700, Amir Majidimehr wrote:
[snip]
> >  I
> > originally thought it was going to be much more important for
> streaming,
> > but apparently this isn't so.  Vorbis in it's current VBR-like form
> > works wonderfully.
> 
> Again, what you call streaming and what we call streaming are two
> different things.  Just because a server can send the bits and have the
> receiver play it as it receives it is not enough.  The trick is to meet
> the bandwidth constraints of the link.  Without this, it is not the real
> thing.

If you are streaming over any best effort network (like the Internet), you
*MUST* have buffering. Why? Because the bandwidth is variable, and can have
bursts of latency. 

VBR streaming is totally possible as long as you bound the stream to a
maximum bitrate within the buffering window. 

No transform based codec can be a pure CBR codec: In a truly CBR codec,
each input sample is represented with a definite number of bits. In a 'CBR'
transform codec, a non-time-domain 'block' is represented in a certain number
of bits. From a time domain prospective, the bitrate value of bits within
the block are clustered around 'interesting events: The bitrate varies but
remains constant within the block.

Some codecs (MP3, probably WMA) allow a small amount of block to block
variance by using a bit reservoir technique, even in a CBR mode.  This is
just an assumption of a small buffering size in the player codec into the
format, and can improve quality somewhat and simplify some of the bit
allocation issues (mostly, achieving a constant bitrate after performing
lossless entropy coding).

You seem to have a big problem separating the format (Vorbis) from it's
implementation (libvorbis). Today the released libvorbis does not support
much bitrate control (a stereo 2channel 44.1k file encoded with beta4 @128kbit
can be from 2kbit/sec-306kbit/sec), nor a few other things like channel
coupling..  BUT THE FORMAT (and the decoder) already do, I can give you
files that are bitrate shaped, and channel coupled if you like to test them
on the decoder.  The current encoder may be immature, but that doesn't
reflect on the superiority of the *format*.

You make the claim that VBR is much easier then CBR, and from a bit
allocation perspective, it can be. But in most other ways, it's a lot
harder: For example, your perceptual model has to be smarter. For a CBR
stream, the overall quality to the listener (which is determined by the worst
audible distortion) could be achieved by a much lower bitrate as you are
only under pressure a small amount of the time, the rest of your frames are
easy, the perceptual model functions to tell you where to put your bits, not
how many you need. The extra bits on the majority of frames makes it easy to
cover flaws in your psymodel.

If VBR were so easy, why don't you perform 'maximum bitrate encoding'? 
Right now, you faithfully encode a block of digital silence into many bits.
Although having a maximum bitrate over a time window is useful, there is *NO*
advantage to wasting bits, if you had some kind of strange physical
transport that needed to be stuffed full, you could pad your frames
(hopefully with non-realtime data useful to other activities, but otherwise,
zeros).  The reason that you don't is that your poor psymodel and inflexible
bit allocation scheme will lie to you and cause you to make suboptimal
quality sounding files in such a way.

The vorbis *format* offers a much better solution: Encode in such a way as
to achieve a consistent high level of quality, then shape the output to
meet the listener requirements (via bitrate peeling), in realtime and on
demand. No extraneous bits are wasted (such bits could be used to reduce the
bitrate reduction required to fit a video codec into the same fixed pipe, or
just left untransmitted to be a better netizen).

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