HLS 低延迟 的创新

Hello, and welcome to WWDC.

My name is Roger Pantos. And today we are gonna talk about some updates to Low-Latency HLS.

The first thing I'd like to announce is that Low-Latency HLS is coming out of beta! That means it will be available to everyone in iOS 14, tvOS 14, and this year's macOS.

That includes support for bit-rate switching, FairPlay Streaming, fMP4 CMAF, and all your other favorite HLS features.

It's available to any native application, and this year there's no entitlement necessary.

Also, given that we're finalizing the Low-Latency protocol, the time has come to add them to the HLS spec itself. So, the second revision draft of the HLS RFC on ietf.org now includes all of the rules for Low-Latency. And in addition to those rules, it also includes a couple new appendices for the Low-Latency Server Configuration Profile and describing the CDN tune-in algorithm. Also, the page that was hosting the provisional Low-Latency spec while it was in beta is now being turned into an informative article with some more descriptions and examples.

You can find information about Apple device support in the HLS authoring spec on developer.apple.com. Now, in the year that Low-Latency HLS has been in beta, we got some great feedback, and, as a result, we made some significant changes to the protocol.

One of the areas that we focused on since the beginning of the original Low-Latency design was reducing segment delay. That's the time between when a new segment is produced and when the client begins to receive it.

The approach that we took initially was to have that segment ride along with the Playlist update using HTTP/2 Push. But one of the biggest areas of feedback we received is that the Push approach doesn't really work for how a lot of people deliver their content, and, in particular, it's not compatible with how a lot of ad-supported content gets delivered.

And so we replaced H2 Push with a new approach that we call "Blocking Preload Hints." The basic idea is that, similar to Blocking Playlist Reload, the client will ask for the next part before it's ready and then the server will hold on to the request until it can send it.

If you'd like to know more about Blocking Preload Hints, we've got an entire talk where we go into it in more detail. One of the things that we're really pleased about is that Blocking Preload Hints actually perform better than H2 Push when you're using a CDN. And that's because driving the request from the client also triggers CDN cache fill without requiring an extra round trip between the edge and the origin.

And so that's great for CDNs. And it's also good that we're no longer asking them to support Push, although they do still need to support HTTP/2. In addition to moving away from Push, we made some other improvements as well.

One of the bits of feedback that we received from the CDN folks was that allowing a client to ask for specific rendition reports could lead to a combinatorial explosion of different request URLs that all reference the same playlist update, and that reduced caching efficiency. So we changed the spec to eliminate the report delivery directive, and, instead, we now put all Rendition Reports into every playlist update.

We also heard from providers who are using lots of date-range tags with long DVR windows. So we added a way for them to incorporate date-range tags into Playlist Delta Updates, so the update only carries the most recent one.

And we go into more detail about that in our separate video about Playlist Delta Updates. Finally, we added gap signaling to Rendition Reports and Partial Segments in the form of new attributes on the Part and Rendition Report tags. This allows clients to deal better with encoded outages in Low-Latency streams.

Beyond improving the spec, we also updated our server reference implementation. Now if you remember that from last year, we have a set of Low-Latency tools that allow you to generate your own Low-Latency stream.

Late last year, we added an option to that to package media as fragmented MPEG-4 so it's compatible with CMAF.

The web server is also much easier to set up. Rather than having to configure your own web server and then mating a PHP script to it, you can now just run a Go script and that will implement the delivery directives and an HTTP/2 web server in a single package.

Finally, we've incorporated the Low-Latency tools into the regular HLS tools package. So now, once again, there's a single download for everything.

You can find out more about that in Eryk's talk about improving stream authoring using the HLS tools. So to summarize what's new in Low-Latency HLS, we've made several important improvements, including using Preload Hinting instead of Push, improving the Delivery Directive interface, and providing CMAF support in the server reference implementation.

The Low-Latency extensions are now part of the core HLS spec on ietf.org.

And with all of this in place, Low-Latency HLS will be available to users later this year.

So if your users have been asking you for a lower-latency live stream, now is the time to act, and we will look forward to seeing them. Thank you very much.