Posted by Chris Poole on , last updated
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. Here at BBC R&D we want to do better and we’ll be showing our latest work in this area at the IBC exhibition this month.
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.
Our demonstration for IBC shows several techniques that we’ve been working on to reduce the latency. We’ll be showing a live demonstration of a TV channel being encoded in London and distributed over the internet with comparable end-to-end latency to our current broadcast services on Freeview. As well as the low-latency HD service, we’ll also be showing a Ultra High Definition service encoded locally on the stand.
The demonstration builds on work taking place in industry standardisation groups including DVB and the DASH Industry Forum and aims to validate the techniques under discussion in those groups.
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.
We can reduce other causes of delay, too. For many users with a good broadband Internet connection, the media buffer used by players to ensure reliable playback is larger than needed, which introduces unnecessary delay. So, we’ve also been investigating how we can reduce the delay for viewers whose Internet connection allows it, whilst introducing appropriate delay for those who need it for reliability.
The final latency improvement we have made comes from optimising and streamlining the various processes that our media goes through before it emerges as segments available on the Internet. By doing this, we can show what is possible in terms of low latency distribution, though it’s fair to say that some additional delay is likely to return here if we were to take our prototype and scale it up for full production use.
This post is part of the Broadcast and Connected Systems section