[vorbis-dev] Re: Vorbis and the nature of VBR

[Kevin Marks]

Hi chaps,
There has been some discussion on the nature of VBR for audio codecs 
on the Streaming Media Advanced group at stremingmedia.com

Some snippets (more there)

o, how variable is Vorbis' VBR? And does it vary up or down from the target?

At 1:01 pm -0700 18/6/01, Kevin Marks wrote:
>At 10:41 am -0700 16/6/01, Amir Majidimehr wrote:
>>Vorbis is a variable rate codec so if by "pulling it in" you mean
>>streaming, this is not going to work (or work well) for a while.  You
>>need a constant bit rate codec for this.
>
>No you don't. It all depends on the magnitude of the variation, and 
>the direction. All successful video codecs are variable bit rate to 
>some extent - the variation acceptable depends on the integration 
>time of the whole system.
>(To make this clearer, key frames (I frames) are usually bigger then 
>difference frames (P or B frames)).
>
>For an audio example, the PureVoice speech codec is fixed bitrate, 
>in that it will encode 160 16-bit samples into a maximum of 35 bytes 
>(17 bytes at half-rate). If you feed it white noise, that's what you 
>see. However, it will use fewer byte if it can - down to 1 byte per 
>160-sample frame (it will do 0 for silence suppression, but that is 
>too easy).
>
>This means its effective streaming bitrate on speech is much lower 
>than the maximum, but it will always fit through the maximum rate.

>Date: Wed, 20 Jun 2001 14:16:02 -0700
>From: Amir Majidimehr <blanked>
>Subject: [advanced] Re: Was MP3Pro -- now vorbis
>To: Streaming Media Advanced Topics <advanced at ls.datareturn.com>
>
>If a system uses true VBR coding (i.e. without bounds as to bit rate
>*and* length of peaks), buffering is not practical because it may need
>to be quite large, potentially longer than the clip itself in order to
>ride out the peaks.  This can make the up-front latency (delay before
>you hear/see the clip) unbearable for the end-user. 
>
>Just imagine how much buffering you need to have a VBR clip that had
>peaks of 1 Mbit/sec for just one second and you try to stream this on a
>28 dial-up modem (22Kbps actual rate).  Even if the rest of the clip is
>at 22Kbps, the up front buffer needs to be 45 seconds to ride out this
>one peak!  Imagine what would happen if the peak continued for more than
>one second or there were more than one.  You also need fair amount of
>RAM to store these bits which may not be an issue for PC these days, but
>may be impractical in non-PC devices.
>
>In general, *true* VBR content should be considered a "download & play"
>solution, not for streaming.  At least this is our recommendation for
>our true VBR scheme for video encoding supported in our tools.
>
>Note that pseudo VBR schemes are possible and are the norm for video
>these days.  Such schemes limit the data rate to a constant average over
>a period (typically 5 seconds).  Equivalent buffering obviously works in
>this case but this is not the same as an unrestricted VBR codecs such as
>Vorbis. 
>
>BTW, there is a lot of confusion around VBR terminology.  For example,
>what Real Networks calls "VBR", I call "pseudo" VBR since it has a
>buffer constraint (and as such, can never achieve the same quality as
>true VBR encoding).  It is probably best to not call these schemes VBR
>despite the internal nature of the implementation.  From the
>system/network point of view, such buffer constrained codecs are best
>treated as constant bit rate (CBR).   Calling these codecs VBR causes
>confusion when it comes to deploying them.
>
>Amir
>Microsoft
>
>-----Original Message-----
>From: Ross Finlayson [mailto:finlayson at live.com]
>
>>Vorbis is a variable rate codec so if by "pulling it in" you mean
>>streaming, this is not going to work (or work well) for a while.  You
>>need a constant bit rate codec for this.
>
>Not true.  You can stream just fine using variable-bitrate data (whether
>
>you stream using TCP, or using RTP/UDP).  Each receiver's buffering will
>be
>able to deal with this.

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