Optimize live streams with HLS Playlist Delta Updates

Hello and welcome to WWDC.

My name is Roger Pantos, and today we will be looking at Playlist Delta Updates. We introduced Playlist Delta Updates to optimize one particular use case of HLS.

As you probably know, when a client is playing a livestream, it is constantly reloading the media playlist to discover new segments. Now, that's fine when the playlist is small, but if you want to present a large DVR window or a long event, the playlist can actually become pretty large, even using gzip. Reloading a big playlist over and over takes time, and the bandwidth it requires can even make the player switch down to a lower quality tier if it's on a bad network.

So Playlist Delta Updates are a new way to reload an HLS playlist, where the server sends only the most recent changes to the client.

The client then combines that update, with the version it already has, to reconstruct the current version that's on the server. Let's walk through the entire process. First, Playlist Delta Updates are optional. The server advertises that it supports them using the Can-Skip-Until attribute of the server control tag.

The value of Can-Skip-Until is the skip limit, which is how old something in the playlist has to be in seconds to be skipped by a delta update. It is always at least six target durations.

The client downloads the first full playlist at least once. If the server has advertised Playlist Delta Updates, then the next time it asks for one, it can use the HLS skip Delivery Directive. It will then use the delta that is produced to update the previous version of the playlist to what's current.

Let's take a closer look to see how a delta update is structured. First, the playlist version is nine or higher, and that indicates to clients that they have to understand Playlist Delta Updates to parse it. A delta update is not a stand-alone playlist, so it's not backward-compatible.

Clients will look at the media sequence tag to find out which segments have been removed since the last update.

And then, the most important part of a Playlist Delta Update, is the skip tag. The skip tag replaces all the segment URL lines which were added to the playlist before the skip limit, as well as any media segment tags applied to one of those lines, such as discontinuity tags or Program-Date-Time tags.

For a long playlist, this one skip tag could replace thousands of lines of playlists that the client already has.

It has a skipped segments attribute that says how many segments were skipped.

After the skip tag is the rest of the playlist. And that will include any segments and tags that were added since the last skip limit. Let's take a look at an example. On the left here, we have a regular live HLS playlist. I've omitted some stuff in the middle to save space, but you can see that it starts with segment 0, and the last segment is segment 20. It has that Can-Skip-Until attribute, so the client knows that as long as it got this playlist comfortably within the last 36 seconds, it can ask for a delta update. And so it does that by adding an HLS skip Delivery Directive to its playlist request.

That will produce the delta update on the right.

It has a version number of nine, and the media sequence is one, which tells us that that first segment has been rolled out of the playlist.

Then we have the skip tag, and that acts as a stand-in for all the segments in the middle. It's followed by all the recently added segments, including a new one, segment 21.

And so the client will take what's new on the right and combine it with the previous version on the left to produce a complete playlist that is up to date with what is now on the server.

Now, Playlist Delta Updates were actually a feature of last year's OS, and one of the bits of feedback we got was that, while they were great, they didn't go quite far enough for providers who had large playlists that also included lots of playlist metadata in DATERANGE tags. And so this year, we are adding an extension to Playlist Delta Updates that supports skipping DATERANGE tags as well.

Servers say they support it by advertising a Can-Skip-Dateranges attribute in their server control tag.

Clients, in turn, will ask for a date range-skipping update with a new form of skip delivery directive, skip=v2.

The way v2 updates work is they skip any date range that was added to the playlist before the skip limit.

Also, they indicate which, if any, DATERANGE tags have been removed since the skip limit, using the Recently-Removed-Dateranges attribute. Now again, this is an incompatible version, so that is signaled with a playlist version of 10.

Next, let's take a look at an example of date range skipping.

So on the left, we have a live HLS playlist, this time with DATERANGE tags and a Can-Skip-Dateranges attribute, saying that the server supports skipping date ranges. Now, DATERANGE tags can go anywhere in a playlist. In this case, the author decided to put them all at the bottom. The client asks for a delta update using the HLS skip=v2 delivery directive.

And that will produce this delta on the right. It's version 10, because it skips date ranges. As before, the media sequence tag indicates that segment 0 has rolled off.

The skip tag also contains a Recently-Removed-Dateranges attribute that says that DATERANGE ID 1 was recently removed from the playlist. At then at the end of the update, we see our new segment 21 as before.

DATERANGE ID 1 is missing because it was removed by the author. DATERANGE 2 is not in the update because it was in the playlist previously, early enough ago that it was skipped. DATERANGE P, on the other hand, is there because it was added to the playlist more recently. And finally, at the end, there's a new DATERANGE, DATERANGE Q. And so, when the client combines the delta with the previous playlist, it will get this: an updated playlist with all the DATERANGE tags still in the playlist present. We've got 2, we've got P, we've got Q. And without the DATERANGE ID 1 that was previously removed.

So Playlist Delta Updates are a powerful tool for optimizing livestreams with large playlists. In this year's OS, they can also do a great job on playlists with lots of DATERANGE tags. They can dramatically improve playlist reload performance, which at the end of the day will improve playback reliability, and ultimately, your users' experience. And so we hope that you can take advantage of them. Thank you very much.