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?"
It all depends on who the target is. If this is targeted to the average person, I doubt they would know what a torrent is, or want to spend the extra 5 seconds to figure out how to download the file. Plus more and more people are behind firewalls and routers, and I don't think the average person would open (or know how to open) the correct ports to seed. So if this site is for the average computer illiterate person I doubt using a torrent as a solution would be much more benefitial.
People like the simplicity of just clicking a link and the video poping up and streaming in media player, no download overhead eather.
Upload video to Google video or YouTube.
Use their bandwidth to stream your video.
Use their API to embed the video on your website.
You lose control over the distribution of the content, but you save a lot of money in the process. The other option is Bit torrent.
Also, have you looked into DigitalBicycle? They are working on a PeerCasting system for Using Bit Torrent, RSS, and web community software
A broadcast organization, like the poster is working for, is most likely in a live environment and can't just Bittorrent to success. There are Peer to Peer streaming tools out there including Abacast and Red Swoosh who I work with on a daily basis that provide sound results for their customers.
Unfortunately, though, a CDN-style infrastructure is still the optimal way to go. There are generally resellers of the CDN technologies that can give you reduced rates on the same service. I know our particular model allows for easy scalability with tools that allow you to control your bandwidth usage. </pitch type="shameless">
It sounds like your problem is bandwidth. Either on the client-side, coming off your net to your ISP, or routing problems elsewhere on the Internet. The hard part is tracking down where the bottleneck is. Try to have multiple end-user test points. The company I work for has employees on a couple of different local ISPs and servers at various colo facilities. Try logging in to each machine and testing the stream. If it's across the board, you can safely bet it's your "unlimited" pipe to your ISP or a problem at your ISP. If it's a problem with a fraction of the clients, try doing traceroutes and see how the packets hop across the Internet and look for any similarities to see where the hang-ups can be. It's also possible that some clients just aren't getting the bandwidth they think they should be getting. Try everything you can to optimize your streaming application of choice. Reduce the number of FPS if you can. If it's only a talking head or something with little movement, try spacing out the keyframes more. Unless you're broadcasting a music video or movie, try using mono instead of stereo for audio. If it's a speech, you probably don't need CD-quality sound. Dropping the sound to 32, 24, or even 16kbps for a WMA/MP3/RA stream will still sound decent for something that doesn't have a lot of variation in sound.
Also, if it is possible, try to expirament around with variable bit-rate streams for video and/or audio. That can come in handy if your target audience spreads from AOL dial-up in the middle of nowhere to your urban 8 Mbps+ broadband connections.
In streaming, the big three big things that you have to worry about are the encoder's connectivity (to push the stream to the distribution point), the encoder's power (to make sure it can really compress all that video without overheating or dropping frames), and the distribution point's connectivity. Distribution servers don't use much bandwidth as all they do is simply regurgitate the data back out to clients without having to do any processing other than logging.
I've been doing streaming for about 5-6 years now. I've done everything from web cam streaming to large convention streaming that put out 300+ Mbps of connectivity. By no means am I an expert (I've done streaming--it's not what I do), but everything above is my experience with it. Most of all, just stick with what you know and are comfortable with. Your client base will determine most things. Personally (even being a BSD guy), my preferred streaming setup is using Windows Media Encoder at the source, Windows Media Server 2003 at the distribution point, and Windows Media Player (or anything else that can play Windows Media v9) at the end-user. In my experience, it has been rock-solid and can be deployed quickly. If you're already running Windows 2000/XP/2003, all the software mentioned above is provided free-of-charge.
Hope this helps.