[vorbis] bitrate peeling

[Jack Moffitt]

> It recieves quality information from 
> the client, and tries to send the approprietly wide stream the client 
> can handle (with a ceiling of course, usually being the width of the 
> original stream selected by the client). 

It receives quality information via RTCP and only for UDP based streams
(at least this is what I understand.  In the TCP/HTTP domain they have
the same limitations of QoS as anyone else).  I agree this information
is useful, but it can be determined in other ways, even via TCP, but
maybe not as reliably.

Also, even if RealNetworks can determine pipe width reliably, it cannot
change the size of the streams.  If you encode a SureStream with 20kbps
and 128kbps, it can only give you one of those two options.  If it
detects your pipe is 100kbps, it must give you 20kbps.

With a peeling streamer, you could feed the client a large range of
options from a single source stream.  In addition, the idea is that for
small changes in bandwidth (probably more normal than 128kbps -> 20kbps)
you get a very small change in quality.  With RealNetworks, you jump to
whatever the next step is, and making finer grained steps is (past a
certain point) not practical.

Let's not mention that storing multiple copies of a single stream is a
bit wasteful, especially if you are storing a _lot_ of streams.  I think
Real's big customers are probably doing just that, and they probably
limit their SureStream options to what they can afford.

SureStream is a great stop-gap solution.  It certainly beats losing the
stream altogether.  Peeling is the next step up the evolutionary ladder.

I don't know how far Vorbis can be peeled in practice, and I doubt few
people do, since there are basically no tools to do it and find out.
It's possible that a hybrid solution will turn out to be necessary if
the peeling can't go from 256kbps to 16kbps.  Perhaps Monty can chime in
here.

<p>> This, coupled with UDP transport if possible (RTSP based on UDP), gives 
> quite reliable streaming (e.g. the stream doen's block even if there are 
> fluctuations in the quality of network connection).

RTSP is not based on UDP.  RTSP is basically a child of HTTP/1.1
with GET renamed to PLAY and some features for video/audio stuff.  You
can think of RTSP as a remote control for a stream (although you _can_
put the streaming data in the RTSP stream, I believe this is not
recommended, and the only people doing this are RealNetworks).

RTP (which includes RTCP) is a UDP protocol and probably what you meant
here.

Remember that while UDP is nice, it's is impractical for a lot of
things.  A lot of firewalls block it outright.  How many Real streams
have you listened to lately that were served via UDP?

That is certainly how streaming should be done, but it doesn't look like
it will be the status quo for some time, unfortunately.

> Don't get me wrong, I'm not trying to advocate RealAudio. What I want to 
> point out is, that we're using a protocol (HTTP) for streaming that is 
> quite simply not for streaming. 

Agreed.  But at the moment there is little better with all things taken
into account.

The basic argument here was whether RealNetworks SureStream was the same
as peeling.  I think that it is not, although the pratical applications
of both technologies are similar.  We seemed to have digressed into a
discussion of streaming protocols, etc, but hopefully that was helpful
for some people, too ;)

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