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

[Hannes]

Wow,

thank you so much, Tor. I will try to use these parameters to tune vorbis
and come back to you with our results, if you are interesed. 300ms max.
latency isn't too bad - it was worse to work on our rule-of-thumb basis.

Later,
  Hannes

P.S. We try to cover processing latency adaptively, because it is platform
specific, so I left it out of the equation.

//
// we apologize for the inconvenience
//
// Hannes Guddat
// Fraunhofer IGD
// A9 - Communication and Cooperation
// Fraunhoferstrasse 5
// 64283 Darmstadt
//
// Tel.: 	+49 6151 155-217
// Fax.: 	+49 6151 155-559
//

<p><p>> -----Ursprüngliche Nachricht-----
> Von: owner-vorbis-dev at xiph.org [mailto:owner-vorbis-dev at xiph.org]Im
> Auftrag von Tor-Einar Jarnbjo
> Gesendet: Freitag, 31. Januar 2003 13:57
> An: vorbis-dev at xiph.org
> Betreff: Re: AW: AW: [vorbis-dev] PlusV algorithm -> CBR
>
>
> Fredag, 31 januar 2003, skrev du:
>
>
> >Next thing is, that I would like to clarify the difference between
> a codec's
> >latency (which I would die to know in exact figures for the vorbis
> codec one
> >day - as well as block sizes, but that's another story) and the
> (bandwidth)
> >"smoothing window" latency - call it buffering or whatever.
>
> One thing is the codec latency (which depends on the implementation),
> another thing is the latency caused by the file format, which is
> IMHO the interesting number. The file format itself allows block
> lengths between 1 and 32768 samples (in powers of two), but this
> is restricted in Vorbis I to be between 64 and 8192.
>
> The encoder has a minimum latency equal to the block length. With
> a sample rate of 44100Hz, this is between 1.5 and 186ms.
>
> Due to block overlapping, the minimum possible latency in the decoder
> would be 1.5 * max block length. Using only blocks with 64 samples,
> you have the "worst case" when computing the 33rd sample of each
> block, for which you need the following block to have been received
> and decoded. With a sample rate of 44100Hz, this is just above 2ms.
> Using a block length of 8192, the minimum possible latency would
> be 279ms with the same sample rate.
>
> Adding both values together, you get a minimum total latency of 3.
> 6ms. In addition to this you have to add an implementation dependent
> value for the encoding and decoding of the packets. A single-threaded
> encoder and decoder fast enough to operate in realtime will not use
> more than 2,9ms for encoding and decoding a 64 sample block.
>
> Tor
>
>
>
> ===================================================================
> EASY and FREE access to your email anywhere: http://Mailreader.com/
> ===================================================================
>
>
> --- >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.

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