During the OTT Blitz Week, organized by Fierce Video, Broadpeak took a part into a conversation about low-latency.
Kevin Gray, VP Technology, Media, and Telecom at Questex, discussed with Xavier Leclercq, VP Sales at Broadpeak the latest about low latency.
Watch the video to hear about where the industry is at right now with regards to low latency, where the latency comes from. Xavier also talks about the current approach to reduce the latency, the newest HLS Low Latency and innovative technologies such as S4Streaming. The interviewed concludes with addressing the way the industry can actually deploys low latency streaming services.
You can watch the panel discussion that followed the interview here.
We can read the transcription here:
Kevin Gray, Publisher at Fierce – First things first. Can you just give me a quick breakdown of where the industry is at today with low latency?
Xavier Leclercq, Business Development Director at Broadpeak – Sure. Thank you for having me today. So, the industry is obviously evolving. The market is starting to bubble and we see a lot of interest from the consumers, the content providers, and the service providers. I think in the next six months we’re going to see mainstream adoption of low-latency streaming. What I mean by that, is that we’re going to see many deployments of solutions offering many streams with only a few seconds of latency. Now you may ask, how did we get here? A few years ago Taking low latency became hype after major events started to be broadcasted via IP by OTT services. For me, a milestone was reached when the BBC, the national broadcaster in the UK, offered the FIFA World’s Cup in 2018 in 4K over IP. [It’s also true for Euro 2020]
At the time, it was the only way to get soccer in 4K and the broadcast was SD or HD over the terrestrial networks, many people use the service to experience the highest quality of soccer in 4K. What is really interesting is when the service became popular and England was doing very well in the tournament, the latency problem became clear. Viewers were complaining about the delay of IP streams compared to the other broadcast. The visual experience was great, these streams were looking great on screen. But watching a live stream 45 seconds behind the broadcast was simply painful. For me, this is when the latency problem became a real consumer issue. It made the news. People were talking about it everywhere and consumers wanted it to be fixed.
If you look at the market today, there are few digital services or live events that are available in low latency. I mean, this is somehow modest for technology that has been talked about for many years. If you remember, low latency was already a big topic at IBC 2016, six years ago.
So, I’m convinced we are going to see many more rational solutions being deployed with a general target of being about less than 5 seconds in production, in the network, in the coming months.
Kevin Gray – That makes sense, as we move to more streaming sports over the year ahead, probably accelerated by the pandemic. Can you just walk us through why we have the latency issue to begin with and what causes it?
Xavier Leclercq – The first thing to realize is that latency is an “accumulation of delays”. We have a bit of delay introduced along the whole delivery chain: from transcoding the content, packaging it, delivery through the content within the network, and then the client’s delays. All of this adds up to the total latency. So, Latency happens throughout the whole delivery chain. If you want to reduce latency to a very low number and the biggest contributor to latency today is the client.
Kevin Gray – I know there are a number of companies working together to solve this issue right now. What is the industry approach to reducing latency?
Xavier Leclercq – There are multiple initiatives. One of them, the one that has the biggest impact, in my opinion, is by focusing on client buffering. If my client can play content as soon as it is received or with a very small buffer, then my latency will reduce significantly, and this is where CMAF and CTE are, an industry response.
The idea is to use sub-chunks within the video segment where as before, you had your segments with about 2 to 6 seconds. With sub-chunks, the video is chunked into even smaller parts, between 50 milliseconds to 500 milliseconds. Also, the definition of chunk transfer encoding, means that together each chunk can be immediately pushed upon encoding. This allows the client to access the video before the segment is completely finished. This allows real-time delivery. To do this, it requires an origin server package capable of creating the small chunks, a content delivery network that will support the chunk transfer encoding function, which is a basic function of the CDN, and then the video player supporting both CMAF and CTE. And this can be done today with various solutions through Broadpeak’s Packager and CDN, or the global CDNs also supporting it. As for a video player that can both support CMAF and CTE.
The technology is available, but low latency is not yet available at scale. Not many sports events are being broadcasted today in low latency. For me, this is due to a certain risk involving delivering low latency.
I mean, the buffering of the client was introduced for reason, right? As well as on OTT, the network bandwidth is not guaranteed. So, if or when the bandwidth drops (when I’m watching a livestream and have a very little buffer in front of me) then I’m going to have a big problem. I’m going to have the frozen scream and the rebuffering event.
To be clear, a re-buffering event is ten times worse than a few seconds of latency. First, [because] my playback is interrupted, and we know that this leads to some abandonment of the stream. It can also lead to churn if the re-buffering happens too often, there’s a clear link between re-buffering events and churn
Once you start having a freeze, if you have a frozen screen for 2 seconds, 3 seconds. You are also adding another say another 3 seconds of latency to your session. What I’m trying to say here, is that if you are being too aggressive on latency to improve the experience that can lead to the opposite effect.
Where your experience can be a lot worse for the end user with more re-buffering and a general really bad experience. Another way to say this, is that if you remove a safety net and you happen to fall, it will hurt, right? In the end, I think low latency today is about finding the right balance between reducing the buffering and not creating a bigger problem by reducing the buffering so much that freezes and re-buffering happen.
Kevin Gray – Thank you. That was really helpful. It seems like there are so many small pieces that can add up to causing all this. I’m just curious, what else can be done? Is there anything besides some of the industry approaches you just mentioned?
Xavier Leclercq – yes, when trying low-latency streaming with our customers, it became very clear that low latency puts more emphasis on the quality of the network. Right? If you are using a perfect network, then you can be very aggressive with the latency on the client. You can run a very small buffer. If not, you will want to be careful to avoid freezes on the screen.
Today we probably recommend about 3-5 seconds of latency to be on the safe side. We came up with two approaches that can be used to improve the experience.
The first one is very simple, which is to make the network perfect or nearly perfect, I should say. We do this on managed networks. On an operator network, an ISP network, by using multicastABR technology. This is where live OTT content is being transported using multicast inside your operator network all the way to the home.
In this configuration, the live streams benefit from a higher priority than all the other traffic, all the unicast traffic. This means, that the buffer can be minimal, in a way similar to the legacy IPTV technology that was also enabled by multicast, and this multicast technology is deployed today and with it, we can target latency of about 2 seconds in a production environment. This is a good way to improve the network quality.
The second approach we came up with is to improve the choice of ABR quality. If you go back to the principle of ABR. You find the client: I can choose what is the best quality for me and a choice is typically a function of two parameters. 1. the state of my buffer, how much content are stored locally ready for playback. 2. The bandwidth available for me in the network. I estimate the bandwidth when I download the video segment. The issue is, in low latency I don’t have a buffer anymore or a very small buffer. So, I’m relying a lot more on my bandwidth estimation, what the client thinks it is available for downloading its content.
Rather than relying on a firm estimation made by the client, Broadpeak has introduced a mechanism in the CDN that measures the bandwidth available at the network level. When setting the content, we know if a chunk of video can be delivered in time or not. It’s really interesting. It’s called S4Streaming. It is used server-side to be implemented in the CDN and allows the server to choose the best video quality based on real-time network measurement.
We’ve launched this capability a few months ago and the initial trials show that it allows true multi bitrate, which is quite difficult to do today with low latency streaming (doing the two together is quite hard). So, those are some interesting ideas, and I’m sure you will hear more during the panels, but I think those two are well worth mentioning.
Kevin Gray – Great. We’ve got about 2 minutes left here and I’ve got two more questions I really want to get to. First off, last year at Apple’s conference, I know Apple announced the spec for the brand new extension of HLS, specifically low latency HLS. So what’s the latest with this? Is it making any progress? Can you walk us through that really quick if you got about 30 seconds on that one?
Xavier Leclercq – Absolutely. Low latency HLS is an extension of the HLS protocol. It delivers the same simplicity, scalability, and quality as HLS while reducing latency to less than 2 seconds. It’s been standardized since April this year, 2020, and we believe is going to be adopted by the industry really quickly simply because it doesn’t change the architecture much. And that would remove some of the most challenging requirements in the ecosystem. Low-latency HLS will also make it to the main screen.
Kevin Gray – Great. The last question I have for to just kind of wrap things up. So, what does it all mean to customers and entertainment providers that are all tuning in here today? How can the industry deploy low-latency services?
Xavier Leclercq – There’s been a lot of prototyping with low latency with DASH with low latency, low latency . We’ve been doing prototyping with a bunch of customers in the labs and I think the production will, production code will be available very soon. I think based on the conversation we had, I’m confident we will see deployments of low latency HLS by the end of the year.
One interesting approach is when you start cobbling new tools like A/B testing that is available to find the most appropriate latency in the network. The concept is to measure the quality of the experience for multiple groups of users within the network and then deploy what worked out to reach the best possible latency while avoiding impacting the quality of experience.
In the end, what we need to do is improve the quality of experience and whether we do with low latency HLS or DASH , that’s what really matters to the consumers.
