[vorbis-dev] Peer-to-peer audio codec

[Anthony Frazier]

On 3 Apr 2002 at 16:58, HALL CYRUS P wrote:

> broadband users are on cable modems, which unfortunately limit up-stream
> bandwidth to a fraction of what many DSL users get to experience (I know
> the technical issues the cable companies always taut, however, I've always

This (as I'm sure you know) varies wildly.  In my area (NorthEast Ohio/NorthWest 
PA), Residential DSL users are limited to 768 kb/s down, and 128 up.  My cable 
modem access (nothing special, just "standard" RoadRunner) is around 3.0 Mb/s 
down, 512 kb/s up.  (Yeah, yeah, I know about cable segments and shared bandwidth 
and stuff vs. DSL's "dedicated" bandwidth.  That's another discussion entirely 
though.  Point is, my box can handily stream out a 256k mp3.  :-)

> Now splitting stereo channels doesn't seem to get one very far.  But what
> about some sort of a "progressive" audio codec?  Let me at this point
> state I have no real experience with compression, so all of this off the
> hip.  A progressive audio codec that could "build" itself up would be a
  [...]
> If a P2P network could use such an audio codec to distribute its streams,
> it balance load and demand (number of higher quality
> "levels" for each stream goes down as demand goes up) and avoid the
> death of Internet radio.  Both of which are important. ;-)

Much like progressive JPEG images?  Actually, I believe that Intel's Indeo codec 
(whoever owns it now) supports exactly this thing.  Yeah, it's video, and yeah, 
it's closed source, but at least it's something we can point at and go "let's do 
that, only better."  

If I understand Vorbis's bitrate peeling correctly, it would also accomplish 
this.  The client would need to be able to take advantage of all the bandwidth 
that it was able to get at any given point in time.  This way the server could 
just stream out, say, a -q 6.00 stream to everyone, and if a client couldn't go 
that fast, then the decoder would use whatever data it got in a given interval 
(and at a lower quality, of course).  The big gimme here is that the technology 
is already designed into Vorbis, and ogg can handle the transport.  (I'm not 
thinking retarded here, am I?)

Now I don't know how you would integrate this with a swarming technique, like 
BitTorrent or something, but that would be exceptionally cool.  Think of it -- 
streaming clients serving each other, and taking load off of the main server.  
Sure, each "hop" would introduce a delay, but a reasonably intelligent design 
could minimize this.

Making this work with streaming would be difficult.

Making this work with live streaming and webcasting would be hella difficult.

How these ideas would "prevent the death of internet radio," I'm not sure.  You 
still have a single source stream, with many clients re-transmitting that same 
stream.  This could, in fact, accelerate the death of internet radio, because it 
would suddenly become very difficult to accurately track the number of listeners 
any given stream has.  Sure, "sub-stations" could have code to report their own 
usage statistics back up the chain, but if the software is open source, then that 
code could be hacked out easily.  This isn't to say that such code _couldn't_ be 
hacked out if it were closed source, but it would be more difficult.  (Of course, 
"more difficult" than "nearly trivial" may still be "really, really easy".)  Why 
are such stastics important?  For royalty payments, of course.  It's nearly my 
bedtime (so my girlfriend says ;-), so digging links on pending legislation (for 
those of us in the US) is left as an exercise for the reader.

Another problem is the trouble of receiving and playing such streams.  Are we 
writing some heavyweight plugins for Winamp and XMMS?  What about other players?  
Perhaps, if we're "swarmcasting", everyone could run a service to receive and re-
transmit a stream, and users could point their favorite streaming-enabled player 
at localhost to listen.  This is a bit ahead of the point at hand, but still 
important to consider.

Pax,

Anthony Frazier

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