Slashdot Mirror
Low Cost Webcast Optimizations?
ChunKing asks: "I work for a small community broadcasting organization, and we operate a limited streaming media facility for a number of not-for-profit webcasters. It has always been an issue to optimize our streaming media infrastructure to most benefit our users. We operate a small cluster of servers from a data center with good connectivity and a highly-rated ISP, who will occasionally allow us to burst to unlimited bandwidth. For big webcasts, we will load balance the stream over a number of servers using round robin DNS. However, we still get problems with stream buffering and network drop-outs, particularly with streaming video. We cannot afford a network of edge delivery servers like Akamai, so in what ways can we further optimize our streaming media capacity to better produce smooth webcasts?"
But, again, a really, really great idea to produce a torrent-like video streaming system.
-- "In order to have power, I must be taken seriously." -Mojo Jojo
Akamai is a premium priced streaming provider, there are many others, most of whom will do what you need at a much lower cost. We are currently streaming live streams (live television channels) with akamai, vitalstream, limelight, and others. We are pulling the seed streams from the middle east and south asia and broadcasting to thousands of users over a very wide geographic area. We have load tested to the 10s of thousands of users and none of the CDNS have even broken a sweat. I know of several sites that are streaming 24/7 channels that have literally hundreds of thousands of simultaenous viewers and viewerships ranking in the millions per month. (unique).
l
Do yourself a favor, call vitalstream or limelight they have starter streaming packs which you probably cannot even begin to use up and they run in the hundreds of dollars a month if I remember right.
To everyone that said xvid or any other format. xvid is a file format. he wants LIVE streams.
to everyone that said streaming is dead.. get a grip, iptv is the next television revolution..
http://www.cabledatacomnews.com/feb06/feb06-3.htm
Think again. Three copies means you chew up three times the bandwidth to get the same file out. If you multicast, you can: (a) transmit to all three the same information at the bandwidth of a single person, (b) transmit to all three three times the information at no extra bandwidth, (c) anywhere in between.
The first option basically means you can run a broadcast station and be doing other things on the Internet (surfing, downloading, whatever). Because broadcasts eat a lot of bandwidth, cutting out two redundant copies frees up a lot of the broadcaster's resources. Alternatively, as bandwidth costs money, the broadcaster can now reduce the speed of service they've bought, save money, AND still transmit to their entire audience.
The second option is also an important one. If you're doing a video feed, three times the bandwidth can mean the difference between b/w or full colour, or between low res or high res. For audio (such as Internet Radio operations), the difference can be between 8 bit mono and CD-quality MP4-AAC with full Dolby-like stereo.
The other important consideration is that multicast scales. If you go from an audience of 3 to an audience of 300, unicast uses 100 times the bandwidth. What could be done on a cheapo DSL line now takes a fractional T3 line, after which the broadcaster jumps off a bridge from crippling debt. With multicast, you could go from 3 to 3 million and not increase your bandwidth consumption by so much as a single byte.
(If you're running a mobile Internet broadcasting station, using nearby wifi access points or a nearby phone line plus a 56K modem, you'd better damn well have multicast if you expect to reach an audience of more than one.)
Should every router on the Internet participate in the creation of PIM trees or allow the inclusion of hundreds of thousands of /32 routes under the 224 prefix? They shouldn't.
Dunno where this comes from. If there's nobody downstream in the group, then the router doesn't carry that group. Plain and simple. Routers only send to routers to which there is at least one connection with a user subscribed to that group. Routers do not need to know every single group, they need only know of those groups they are explicitly forwarding. In consequence, multicasting is actually very light on the router requirements. (With IGMPv3, the tree can be further reduced. If more than half of the connections want the stream, then the router can invert the logic and transmit to all EXCEPT for those who don't want it. Routers can also filter by source, if instructed to do so, so the tree doesn't even have to carry excess traffic any more.)
How do I know this for sure? Well, aside from having run multicast routers myself, I know that the Internet backbone has been running native multicast for the better part of eight to ten years. Has the Internet obvious suffered from this? Not that I'm aware of. Sure, there have been partial meltdowns of the Internet, but those are invariably unicast, not multicast sessions. Of those, had multicasting been used instead of unicast, the Internet would have barely noticed the impact.
It sounds to me as though you've been learning about multicasting from some highly uninformed sources who aren't aware of the distinction between a broadcast protocol (where everyhing is sent to everyone) and multicasting (where only specifically requested streams within specifically selected groups are forwarded only to explicitly interested parties).
If that is the case, feel free to point them in my direction and I'll be more than happy to go through in meticulous detail every aspect of multicasting that they could possibly want to know about. And more. The same is true of anyone else on Slashdot - I am more than happy to provide detailed information on any aspect o
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)