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

[Hannes]

Bzzt,

correct.

I've been watching your thoughts on the CBR issue over the last past days
because I liked to know what people's ideas about streaming and oggvorbis
are, many of them profound, some rather not.

I would really like to know the settings how to keep vorbis from producing
the peaks it sometimes does (as of Version1.0), as it will definitely kill
every streaming application, because right now, I can only control my output
bandwidth by rules of thumb.

So you can keep on banging on my head, because I told the "CBR"-word, but it
wouldn't change the situation that you can't send it over a modem line
without buffering for 2 seconds or dramatically decrease the bandwidth. I
take this as the options most of vorbis-dev left me with ?! 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?

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.

First, it is simply not true, that you have to buffer 2 seconds on sound
output on any platform, not even under windows. Actually today you have
pretty good drivers (it even doesn't have to be ASIO) that can deliver a
10ms audio interface to your soundcard. Given DirectSound-buffering and all
that shouldn't be more than 100ms even (in most cases below, how would you
otherwise do conferencing on a PC) if you run your sound output parallel to
other sound applications (background mixing). Not to mention Linux, where
you can go far below that.

Anyway, this has nothing to with the window I would have to provide for
smoothing the codec output, they only add up on top of each other. BTW: I
never said I like MP3 and I never said MP3 would be any better on latency
grounds - it only started a series of fatal audio applications like
http-"streaming" - speaking from the realtime streaming point of view, which
I am interested in.

What I really wanted to tell the vorbis developers, again, is, that your
codec is maybe only missing some details (at least in specification) to
optimize it for use in realtime streaming. For internet streaming it is
already working with vorbis (point-to-point in less than a second, sound
buffering, vorbis, FEC and all, at a little more than ISDN bandwidth) - quod
erat demonstrandum. So please, if you can, put some more work in it or tell
me how we can help, because I would rather support an open codec standard.

A last word on the TCP issue. Of course, if I *really* want telephone
quality I use a phone. I would not stick two modems and a provider
in-between. But for some streaming applications (e.g. videoconferencing)
there is no such standard. And - it is possible, you wouldn't believe how
much realtime potential there is. Where you have a point is, that most
ISDN/DSL providers (except QSL, for example) do not care about latency. I
mean they have to buffer your connection, I'm happy about that, but..)

<p>Thank you,
  Hannes

//
// 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>> -----Ursprungliche Nachricht-----
> Von: owner-vorbis-dev at xiph.org [mailto:owner-vorbis-dev at xiph.org]Im
> Auftrag von Segher Boessenkool
> Gesendet: Donnerstag, 30. Januar 2003 06:31
> An: vorbis-dev at xiph.org
> Betreff: Re: AW: [vorbis-dev] PlusV algorithm -> CBR
>
>
> Hannes wrote:
> >
> > I don't know if you actually know what vorbis is capable of
> in respect of
> > realtime internet streaming, but you are really *only*
> missing a correct CBR
> > to put you in front of the race.
>
> Bzzzt.  You mentioned the "internet" word.  CBR isn't more
> useful for internet
> transport than (constrained) VBR is.
>
> > Vorbis is a really great codec - I value it
> > over most of the available codecs at the moment - but it is
> a shame that you
> > simply cannot rely on some modes when you are intending to
> send your stream
> > over e.g. a modem line.
>
> Modems haven't been CBR for at least a decade now.
>
> > I know it would mean a great deal of damage to vorbis
> quality, but would it
> > really be so bad considering the possibilities? And if, how
> big would the
> > bandwidth adaptation window really have to be - 2 seconds?
> thats about 1.9
> > seconds too long, if this adds on my streaming latency, sorry.
>
> MPEG audio other than Layer I has a >100ms latency, too.
>
> > I mean not to upset you because I know it doesn't work like
> this if you want
> > vorbis quality - but isn't there some kind of compromise?
> The reason I'm
> > writing you is that we are using vorbis as one of our
> codecs for an internet
> > radio demonstrator. We would like to use the 45kbit/s-mode
> for HiFi-Stereo
> > over ISDN (with all 20%FEC and Headers it normally sums up
> to 60-62 kbit/s).
>
> Bzzzt.  ISDN with PPP isn't CBR.  If you are serious about
> CBR and low latency,
> you want a direct ISDN link (without TCP/IP or whatever, just
> the raw B pipes)
> to your customer.  And your telco operator had better not put
> some buffering
> switch inbetween!
>
> > Sadly the 45kbit/s-mode sometimes behaves like a 64kbit/s
> vorbis, meaning
> > that for a lot of slow, montone passages it really keeps
> its speed limit,
> > but if the going gets rough, bandwidth goes up. This made
> us decide to use
> > the 32kbit/s-mono-setting, which is kind of sad, really.
>
> So what you really want is a setting that will keep the peaks
> down a little
> more.  Maybe someone here can tell you what such a setting
> should look like?
>
>
> Segher
>
>
> --- >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.