A friend and I were recently talking about the possible downfall of Internet radio, and as everyone seems to these days, decided that a nice solution would be to set up a P2P broadcasting solution. However, streaming has a completely different set of requirements than file sharing, with bandwidth and QOS become much larger issues. As such, we started to realize that a new audio compression scheme might be needed for such a network. As an open source developer and user, I thought of the immediately Vorbis project, and its developers. As such, I thought I'd run this idea by the list, and test it for feasibility. the basic idea follows: Most 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 thought of it as a way to limit personal publishing ability). As such, a P2P radio broadcast network could not use the upstream of such users, putting the burden of distribution on a few, and thereby defeating the major point of the whole thing P2P in the first place. If there was a way to break up the audio streams and re-sync them on the listeners side, this problem could be avoided (maybe). For example, imagine a 128 kbps stream (OGG, of course). A lucky cable modem user could barely support one user at such a bit-rate. However, if the stream was split into left and right channels, each one a different stream, a listener could get one channel from one location, the other from somewhere else. 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 very handy (and cool) solution to the problem. A stream could be broken into multiple levels, where each level would add more definition to the previous. For example, if each level took 16 Kbps of bandwidth, a user who had been able to find a source for both level 1 and 2 would be able to listen to the stream as if it was at a quality of 32 Kbps. maybe the scaling wouldn't be that linear, I don't know, but I think you get the idea. 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. ;-) This idea doesn't really fit into OGG at all, I understand that. However, I was hoping that maybe some of you would have a more technical base in the field than I, and could point me in the right direction to start researching such. thanks, Cyrus <p>--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
http://www.allcast.com is using peer-to-peer streaming technology (with WMA unfortunately). An Ogg solution would be great. Their website may give you some ideas. Ross Levis. HALL CYRUS P wrote:>A friend and I were recently talking about the possible >downfall of Internet radio, and as everyone seems to these days, decided >that a nice solution would be to set up a P2P broadcasting solution. >However, streaming has a completely different set of requirements than >file sharing, with bandwidth and QOS become much larger issues. As such, >we started to realize that a new audio compression scheme might be needed >for such a network. > >As an open source developer and user, I thought of the immediately Vorbis >project, and its developers. As such, I thought I'd run this idea by the >list, and test it for feasibility. the basic idea follows: Most >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 >thought of it as a way to limit personal publishing ability). As such, a >P2P radio broadcast network could not use the upstream of such users, >putting the burden of distribution on a few, and thereby defeating the >major point of the whole thing P2P in the first place. > >If there was a way to break up the audio streams and re-sync them on the >listeners side, this problem could be avoided (maybe). For example, >imagine a 128 kbps stream (OGG, of course). A lucky cable modem user >could barely support one user at such a bit-rate. However, if the stream >was split into left and right channels, each one a different stream, a >listener could get one channel from one location, the other from somewhere >else. > >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 >very handy (and cool) solution to the problem. A stream could be broken >into multiple levels, where each level would add more definition to the >previous. For example, if each level took 16 Kbps of bandwidth, a user >who had been able to find a source for both level 1 and 2 would be able to >listen to the stream as if it was at a quality of 32 Kbps. maybe the >scaling wouldn't be that linear, I don't know, but I think you get the >idea. > >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. ;-) > >This idea doesn't really fit into OGG at all, I understand that. However, >I was hoping that maybe some of you would have a more technical base in >the field than I, and could point me in the right direction to start >researching such. > >thanks, >Cyrus ><p><p>--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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 alwaysThis (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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.