Facebook  Twitter  Google +  Linkedin


Warning: file_get_contents(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/lwegabab/public_html/old/plugins/content/al_facebook_comments/al_facebook_comments.php on line 516

Warning: file_get_contents(https://api.facebook.com/restserver.php?method=links.getStats&urls=https://old.yourictmagazine.com/others/technology/822-bbc-solves-the-lag-between-live-streams-and-tv): Failed to open stream: no suitable wrapper could be found in /home/lwegabab/public_html/old/plugins/content/al_facebook_comments/al_facebook_comments.php on line 516

Warning: Undefined array key 1 in /home/lwegabab/public_html/old/plugins/content/al_facebook_comments/al_facebook_comments.php on line 521

BBC has 'solved' the lag between live streams and TV

BBC Research & Development department has finally solved the problem of delays you experience when watching a movie online or a football match. If you’ve ever watched a live event over the Internet near to someone who’s watching the same thing on traditional broadcast television, you’ll know that the Internet version is often many seconds behind.

There are many factors that contribute to the delay or ‘latency’ that you experience when watching a live stream over the internet.  Some of this latency helps give you a reliable stream that will play without interruption despite competing with other traffic on the network. But there are also other causes of delay that we can reduce.

So how does it all work?

Live streams in BBC iPlayer are currently delivered using two main technologies: HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH). Both of these are designed to make use of Internet Content Distribution Networks (CDNs), which help deliver files and web pages to large numbers of users. To distribute a live stream in this way, the stream is split up into a number of ‘segments’ – separate files each carrying around 4-8 seconds worth of media. Today, each complete segment must emerge from the media encoder before it can be passed to the CDN, and players in televisions and other devices will generally start to process a media segment only once they have downloaded the whole thing. They will also buffer two or three before playing them. With this approach, you can easily end up with an end-to-end latency that is several times the segment duration – that is what viewers experience today.

One improvement we could make would be to use shorter segments but doing so reduces the efficiency of the video encoding and leads to many more requests from clients for the CDN servers to handle.

Another approach is to allow segments to be passed progressively through the distribution chain without waiting for them to be complete at each stage. Doing this requires each segment’s internal structure to be more finely partitioned. These “chunked segments”, which follow the MPEG CMAF standard, are the basis of the approach that we’ll be showing in Amsterdam.

Chunked segments can be delivered to the viewer's device progressively using a standard feature of the HTTP/1.1 protocol called Chunked Transfer Encoding. This allows part of a segment to be delivered before the overall size of the segment is known. However, CDNs currently offer differeing levels of support for handling incomplete segments upstream.