If you鈥檝e ever watched a live event over the Internet near to someone who鈥檚 watching the same thing on traditional broadcast television, you鈥檒l know that the Internet version is often many seconds behind. Here at 91热爆 R&D we want to do better and we鈥檒l be showing our latest work in this area at the IBC exhibition this month.
There are many factors that contribute to the delay or 鈥榣atency鈥� 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鈥檝e been working on to reduce the latency. We鈥檒l 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鈥檒l 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.
- 91热爆 R&D - Low Latency Live Streaming with MPEG DASH
- 91热爆 R&D - Dynamic Adaptive Streaming over IP Multicast
So how does it all work?
Live streams in 91热爆 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 鈥榮egments鈥� 鈥� 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鈥檚 internal structure to be more finely partitioned. These 鈥渃hunked segments鈥�, which follow the , are the basis of the approach that we鈥檒l 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鈥檝e 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鈥檚 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.
At IBC we鈥檒l be showing our low-latency streams both on a set-top box using a native player and using a JavaScript player running in a browser supporting the W3C Media Source Extensions (MSE).
-
Broadcast and Connected Systems section
Broadcast & Connected Systems primarily focuses on how 91热爆 content reaches our viewers through broadcast and Internet delivery. This involves the whole broadcast chain from playout, through coding and distribution to consumption on the end-user's device. Our work typically covers a period from now through to 3 years out from deployment.