Delivering live, high quality broadcast video over the internet has always been an interesting challenge. Broadcast engineers are expected to understand and manage complex video, networking, scale, reliance, and playback to deliver reliable programming to multi-platform viewing devices. In this series of articles, we delve deeper into live-OTT broadcasting, identify some of these challenges, and present strategies for achieving reliable live-OTT distribution.
Streaming over the internet enables broadcasters to reach a much larger audience than traditional terrestrial, cable, and satellite models. Viewers are now watching their favorite programing on a whole plethora of devices including cellular phones, gaming systems, PC’s, and Smart-TV’s. And to increase their audience base and hence revenue, broadcasters must deliver to these viewers.
The public internet opens new opportunities for multi-platform delivery providing audiences with many new viewing options. However, this is not as straightforward as it would first appear as there are three specific challenges that will be faced by most broadcasters; bandwidths vary, latency is unpredictable, and picture sizes are determined by the playback device the viewer is using.
OTT Pulls Data Streams
Fundamentally, broadcasting and OTT delivery differs in one important aspect. Satellite, cable, and terrestrial systems all push data to the set-top-box and TV set. In contrast, OTT playback devices request a stream and pull the data from the broadcaster, giving each audience member a unique view.
The internet was developed to deliver textual documents using a client-server model. To initiate any data transfer, a client often starts by sending a “GET” command to the listening agent, often a web server. Web-servers are in permanent listening mode and when they receive the “GET” command from an authorized client, they will send the requested information back to the browser at the appropriate IP address.
Internet connected devices generally use the HTTP (Hyper Text Transfer Protocol) model to communicate with web servers. HTTP sits on top of a TCP (Transfer Control Protocol), which in turn sits on top of IP datagrams. Although more commands have been added to the HTTP protocol as it has developed over the years, the client-server, demand-supply model, is how most internet connected devices work today. Even if the viewer watches on a dedicated app, the HTTP client-server approach is used.
HTTP generally operates on top of TCP/IP to guarantee data is reliably exchanged between the client and server. Although TCP is highly effective in resending lost packets that if not resent would significantly degrade a video feed and affect the viewing experience, there is an overhead associated with TCP that can lead to increased latency and network traffic.
Other systems do exist such as RTMP (Real Time Messaging Protocol) and webRTP (web Real-Time-Protocol). Traditionally, RTMP was used in Flash viewers, but it’s use has declined as delivery networks look to consolidate infrastructures to a common delivery method and Flash has become deprecated in many viewing environments.
While not initially developed to stream live video over the public internet, HTTP has become the most commonly used video stream delivery protocol today. Because it is the de-facto language for most web traffic, standards-based infrastructure already broadly exists.
Work Back from the Playback Device
To understand OTT distribution, from a broadcast engineers’ point of view, is to start at the playback divide and work back to the playout center.
In IT terms, streaming is the process of breaking a file into segments and making them available to a playback device to facilitate video and audio viewing. The alternative is to download the entire file into the player. While progressive download exists for on-demand, it’s not ideal as the long download times will affect the viewer experience and cost.
VOD and live-OTT are similar in that they both fragment the media, so the playback device can request consecutive chunks of data and play the clips in an orderly fashion. Where they differ is that VOD has all the data available before fragmentation begins, whereas live-OTT does not, and must compress and fragment video, audio, and metadata on the fly.
In a live-OTT single client-server model, this works well as the viewers’ playback device will be sending HTTP-GET commands to the web-server approximately once every second to retrieve consecutive chunks of video and audio data. However, life gets interesting when the number of people watching the event increases to national and international volumes. If 10 million people are watching the event, then 10 million HTTP-Get requests will be sent every second.
More details contact sales:
Regional Sales Manager
DIBSYS Technologies Co., Ltd
Tel: +86-571-87068982 Fax: +86-571-89714580
Mobile: +86 15356661487 What's App: +86 15356661487 Skype: dibsys0801