How much is it delaying live television?

Reduce latency for online live TV

Guest Post Events like the Super Bowl, the World Cup or the Eurovision Song Contest live from the moment of tension. This is precisely why they are lucrative for online media providers. But even an average delay of around 30 seconds in the online stream compared to conventional television can destroy this experience: When a football fan sees his team's player running for a penalty on his cell phone, it is extremely annoying from viewers on TV via Facebook comments to learn that the ball went into the goal. The tension is also over when the audience at the public viewing via Internet TV on the restaurant terrace already knows the result of a dribbling from the reactions inside.

Steve Miller-Jones, the author of this post, is VP Edge Strategic & Solutions Architecture at Limelight Networks (Image: Limelight Networks).

Signal transmission that is slower than traditional television reduces the acceptance of online live TV. According to the State of Online Video 2019 study conducted by Limelight, every second viewer in Germany would watch more live sport online if the broadcast wasn't slower than conventional TV. Even less can content with interaction - such as online gaming events, auctions, quiz programs or bets - allow the next video sequence to be displayed too slowly. They also require the signals to be sent back quickly.

A certain amount of time can pass when processing a live video and transmitting it over the network to the end device. This is mainly due to the fact that the Internet protocol HTTP TCP / IP was not originally intended for broadcasting video content. The time it takes to encrypt a camera video and deliver it to an online player or OTT device is known as live streaming latency. There are numerous ways to reduce arrears, but there is no one-size-fits-all solution. The appropriate method in each case results from the content and your specific requirements.

Shorter chunks can help

To solve the problem, the chunk size can be adjusted: Before each video playback via the HTTP-TCP / IP protocol, a player temporarily stores three video segments created by the encoder - chunks - in the buffer. This will need time. With a chunk length of 10 seconds, 30 seconds are to be buffered, with six seconds corresponding to 18 seconds. A shorter video segment speeds up the transmission: With lengths of up to one second, an end-to-end latency of just 6 seconds can be achieved. Common HTTP chunked protocols such as HLS and MPEG-DASH are supported. The method is suitable for content that does not require real-time display of signals or interactivity. But it also has its limits: If the data stream is interrupted and the buffer is empty, chunks that are too short can require repeated caching by the player. Therefore, every workflow should be tested accordingly.

Playback devices must buffer three video chunks before playback begins (Image: Limelight Networks).

Lower latency through CMAF encryption

The Common Media Application Format (CMAF) also accelerates the display of signals on the player. A uniform framework is used to store the data in HLS and MPEG-DASH. This has the advantage that content only needs to be saved and packed once. Broadcasters no longer have to create two separate data sets of the same audio and video data in order to record different end devices such as tablets, computers, smartphones or other end devices.

The CMAF encryption of the chunks ensures a lower latency. When transmitting segments without a CMAF chunk, the video samples are only output by the encoder and sent over the network when a complete segment has been created. The decoder then starts decoding. A segment divided into CMAF chunks, on the other hand, uses coded video chunks, so-called video fragments. The coding of the medium is necessary to correctly describe the sections and signals the availability of smaller sections. The individual fragments can be transmitted before the entire video segment has been processed. As a result, the decoder also starts playing before the entire segment has been received.

Figure 2: Playback devices have to cache three video chunks before playback begins (Image: Limelight Networks).

WebRTC for real-time broadcasts

Web Real-Time Communications (WebRTC) is an open source project for communication via browsers and mobile applications. WebRTC is supported by Google, Mozilla, Opera and other large players in the market. Originally used for web conferences, the technology now enables video broadcasts with large audiences. To do this, it uses the more effective network protocol UDP compared to TCP / IP. There is no chunk segmentation of the data streams by the encoder or intermediate storage.

WebRTC also enables the content to be played on standard web browsers - plugins or special video players are superfluous. The bit rate can be adjusted so that the viewer sees content in optimal picture quality even under variable network conditions. In addition, the technology enables the bidirectional transmission of data in real time by the viewer or online gamer. The 2-way data channel enables a latency of less than one second and thus also the interaction required for gaming.

Limelight Realtime Streaming (Image: Limelight Networks)

To keep viewers happy and engaged, media and broadcast companies need the services and technologies of content delivery network (CDN) providers like Limelight Networks. They support the industry in delivering a high-quality viewing experience to every user and in remaining competitive in the lucrative event sector. In order to be able to provide appropriate streams, obstacles for web traffic must be removed and interference-free transmission must be guaranteed. The media delivery infrastructure must remain flexible, as users are increasingly following live events online and are becoming more and more mobile. The challenge is to create a TV-quality, real-time experience through these channels.