Outbound bandwidth used to be easy to calculate, but with more and more streams and encoding/transcoding alternatives, today it can be a challenge.
Here are some tips to figure out how much you need for your event.
Outbound bandwidth can make or break a live streamed event. Unfortunately, while this used to be easy to calculate, it’s now quite challenging as stream counts increase and encoding and transcoding alternatives proliferate.
For perspective, things were simple for the first live event I ever streamed, way back in 2010. Since mobile had not yet exploded, and SD was still the norm, I could get away with a 320x240 Flash stream encoded at 500 kilobits per second (Kbps), which never stressed the 850Kbps output bandwidth provided by the event facility.
Since then, mobile support has become a priority, which has several implications. First, since mobile includes smartphone and tablet viewers connecting via cellular or Wi-Fi, you need adaptive streams to effectively serve the universe of connection types and screen sizes. Second, this set of streams needs to be formatted for iOS using HTTP Live Streaming (HLS), while your desktop streams are usually formatted for Flash. Where a single stream used to suffice, now most live events need multiple streams in multiple formats.
As an example, I recently tested Brightcove’s Live Video Cloud platform, which delivered eight live streams, four each for Flash and HLS, with a combined data rate of 8 megabits per second (Mbps). Most authorities recommend between 30-100% overhead in your outbound bandwidth to sustain a transfer throughout an event. If I produced these streams onsite, I would need between 10.4 and 16Mbps of outbound bandwidth, which would be prohibitively expensive if obtainable at all.
So how to deliver these streams in a bandwidth or budget constrained environment? You have to choose your services and technologies with this issue in mind.
Figure 1. (Right) With YouTube, you send a single stream that gets transcoded into multiple streams by YouTube.
The key question, of course, is where the streams get produced. Back in the early days of live event streaming, the delivery schema was simple; you created a stream onsite, transmitted it to the streaming server, which delivered that stream untouched. Some services today still follow this model, which means that the number of streams that you deliver is limited by your outbound bandwidth.
Other services use a technology called live cloud transcoding to accept a single stream in from the event facility and transcode that in real time to the required streams. In my tests of the Brightcove Video Cloud, for example, I sent a single 720p 3.5Mbps stream to Brightcove’s servers, which transcoded the stream to the eight iterations. Since my office has 5Mbps of outbound bandwidth, this wasn’t a problem. Onstream Media uses a similar scheme for their webcasting service, as does Haivision for their Video Cloud offering and YouTube for YouTube Live.
An ancillary benefit of this approach is that it minimizes the cost of your on-site encoder. I’ve been testing a lot with Telestream Wirecast, which can easily create the single 720p file on a 4-core HP Z400 workstation, but so could Adobe’s free Flash Live Media Encoder.
Figure 2. (Left) With Livestream, you send all encoded streams to the service, which can increase outbound bandwidth requirements.
If you’re rolling your own streaming delivery system, you can duplicate this functionality several ways. For example, most streaming servers can transmux incoming streams for alternative delivery platforms, accepting Flash streams in and outputting HLS as well as Flash, and cutting your outbound bandwidth requirements in half. Or, by using a product like the Wowza Transcoder, you can create your own server or cloud-based transcoding facility and drop outbound bandwidth requirements even further.
These alternatives make early planning critical; you not only have to determine how many streams you’ll be delivering, but where they will be created. This will tell you how many streams you’ll be pushing out of your live event facility, and the bandwidth necessary to support them.