The market for OTT live streaming is not only on the rise, but is also becoming a larger part of the overall OTT streaming market in general. According to Conviva’s Industry Data, live streaming already consists of 20% of streamed video. The most popular programs watched are sports, news, live events (such as Pope coverage, The Oscars), and OTT delivery of linear TV channels such as CNN, ABC, CBS, etc.
On the face of it, live streaming and on-demand streaming seem to have a lot in common: They are viewed on the same devices and delivered using the same codecs and protocols. However, unlike on-demand streaming, live streaming happens in real-time, bringing with it many challenges related to video processing and delivery.
Timing is everything
For on-demand video, the timing of content availability is important, but not critical. Episodic content is prepared months in advance, and even if content is relevant for that same day, there is still some time to prepare it beforehand. When encoding video, having more time means that more complex encoding tools can be used to improve video quality, even if encoding takes longer. For example, two-pass encoding, which first analyzes a video and then sets the best encoding parameters based on the analysis, can be performed when doing offline encoding of on-demand streaming content.
For live video, encoding has to take place on-the-fly, with minimal delay. Nothing (at least in my eyes) is more annoying than watching a live football broadcast on the Internet, and seeing a touchdown only after hearing the (crazy loud) cheers from the next-door neighbors…
Simply put, since live video encoding needs to happen in real-time, the added encoding speed requires a tradeoff on video quality. Two-pass encoding can’t be used, and some of the encoding tools need to be relaxed to meet the real-time constraints, resulting in a lower video quality.
Multiple formats at once
Streaming applications typically require encoding content in various formats (both codecs and protocols), in order to support different devices such as web browsers, mobile phones, streaming boxes and game consoles. When creating content for on-demand streaming, you can initially create only a limited range of formats (based on device popularity), and after releasing the content, you can expand the range of supported devices further by creating more formats.
With live streaming, however there is no “second chance” for releasing the content to more devices: content is viewed in real-time, so all formats have to be prepared at once. This creates an additional processing burden, which requires extra computing resources.
Sometimes tradition is less dedicated
It’s interesting to compare live streaming with traditional live broadcast over terrestrial antennas. With traditional broadcast, a single antenna can serve millions of viewers, who are watching the same program at the same time. Having more viewers does not change the viewing experience for anyone, and doesn’t require any dedicated additional “transmission power” from the antenna.
With live streaming, each viewer has a unicast connection to the streaming server, meaning that a dedicated stream is sent from the broadcaster to that viewer. Now, multiply the typical bandwidth of a live stream (that can be around 1 Megabit per second) by the millions of viewers watching an NBA game or the Papal Visit simultaneously; and the end result is an enormous bandwidth demand that needs to be supported over the (somewhat congested) network.
Clearly, processing and delivering live streaming is technically more challenging than on-demand streaming. And subscribers, who always expect a great viewing experience, do not care about any technical issues, so the challenge is only the content provider’s to solve.
Clearly, being a big fan of media optimization, I believe that as the demand for live streaming increases, the bitrate of live streams delivered over the Internet needs to decrease. Otherwise we will all suffer from the outcome of congestion…
