Ep. #14, Low-Latency HLS, Pt. 1

Matt: Hey everybody, welcome to the Demuxed podcast.

This is our first attempt at recording during quarantine.

So all of us are at our respective home, social distancing.

Today we wanted to try something new.

You might've noticed that we didn't introduce a guest that's because we didn't have one today.

We had been talking a lot about this low latency stuff going on with Apple's announcements, and it's kind of a really hot topic right now with everybody trying to start new work from home distributed apps and things.

So low latency realtime video, has all kind of come to the forefront again, and that's dovetailed with Apple's recent announcements, which we'll dig into in a second, but we were like, we can just talk about this.

So we're going to do a two-parter. Phil and Steve in particular, have spent a lot of time thinking about this as a topic and writing about it.

You might've read a blog post on the Mux blog or seen Steve talk about it in the last year or so.

So we figured we'd just dig in, this first episode is going to be more long.

The history of low latency, real time video, what that ecosystem looks like, make some definitions, and then talk about kind of Apple's announcements up to this point and where we are.

So, that being said, we're going to kick this off.

So Steve, since you've kind of done a few of these talks actually and Phil, you've both defined this. Why don't y'all define low latency.

Steve: So I'm just kind of like, I'm hesitant to jump too deep into it, just cause it seems like, maybe people don't know exactly what we're talking about.

So kind of stepping back to like, I think maybe the applications that are using low latency might help kind of frame the conversation here.

And I kind of see the main use case for this concept of low latency live streaming, being interactive, live streaming at scale specifically.

So, let me talk about that in specifics here. So, you have this idea of like real time chat, right?

So, Zoom, Google Hangouts, that's already like real time interactive audio and video, you can talk back and forth to each other in real time.

There's not like weird latency that feels like you're on an you know a long distance phone call and you have to pause and wait for people.

That's what we mean by latency, right? Is that like the time between something happens in real life, to when it shows up on the other person's screen.

Phil: Yeah, and in video we tend to call that glass-to-glass latency. The glass of a camera lens, to the glass of device.

Steve: Yeah, so you have this idea of real time chat and then on the other side you have say like broadcast live streaming.

So think like the super bowl, like you're streaming to millions of people.

Typically the Superbowl already have baked into it.

At least I heard that it had like as much as 30 seconds of latency already baked into it, so that they could respond to issues that happened in the stream quickly.

Or even just like weird things that happen, like a newscaster, like flubbed something or curses or something. And they have to go back and bleep it out. It's already latency built in. So you're not really talking about low latency in that type of scenario. Like the big live streaming event scenarios or talking about is kind of landing right in between.

And we're thinking about applications like Twitch, where you're watching your favorite gamer live stream their video game and you're chatting alongside and the gamers maybe responding to your chat in real time or games like a HQ Trivia, the phone app where you can do it, they'll have a live host answering questions or giving you questions to answer.

And you want that responsiveness to feel interactive. So It's not real time chat.

It's somewhere in between where you have a large audience, not all interacting with each other, just interacting with a host, but you have that like real time feedback happening.

Phil: Yeah, what, I think it's interesting there is really the, differentiation between this interactivity, that is a few seconds and this interactivity, that's immediate, this real time communication as it's called.

And that really feeds into the technologies that people think about and select when they're trying to solve these business cases, because you don't need a real time technology for five seconds of latency, but you do need a real time technology for sub-second latency.

That tends to be where people start to think about drawing a line around sub-second is infeasible with more traditional technology approaches and is why we have things like web LTC on the internet.

Which we'll get onto in, in depth, I'm sure in a minute, but this is tends to be where the line is drawn somewhere between, 500 milliseconds and a second is a real time experience versus kind of these low or ultra low latency concept.

Matt: The way I started describing this to people that are like programmers and familiar with the concepts of the internet the huge difference is, how much of your normal like web application stack you can use for one versus the other, and how much of a difference that makes for both cost who you can hire to help work on it.

Like all of those kinds of things like HLS and these streaming protocols over HTTP, they all use your normal CDN, they're all your same, like CDN contracts.

You scale it in the same way that you would scale or a very similar way that you would scale a normal application under heavy load.

You have all the same caching parameters, like all that kind of stuff maps really well to a normal high traffic static website. To some extent.

Steve: And cheaper.

Matt: Yeah, and you use all your same contracts and your relationships.

Steve: Commodity CDN hardware. That's been tuned over the last 20 years to deliver these little packets of data compared to like these real time.

I always kind of like stateful connections, persistent connections between an end user and a server that has to be kept up. I guess really expensive at scale.

Matt: Right, having to maintain a connection to every single viewer, that part alone is expensive.

That's kind of like where I've been explaining a lot of the difference here is like, yes, low latency is feasible.

You're just also probably going to pay out the butt for it, which as we mentioned earlier, I think HQ learned pretty quickly.

Steve: To stay on the on HQ note. I think we were doing some math early on.

So HQ, we were like snooping their traffic when they're early on streaming.

And they were doing some stuff that you would expect to start up to do, just kind of using, the quickest technology to get them to what they were trying to achieve.

And originally we saw them using RTMP to stream video, directly to every one of their users.

And when we did the math on that, and it was with hundreds of thousands of viewers, RTMP connections to each, thinking about just the transcoding and the Flash servers or Wowza the servers involved was probably around like 30,000 a show without even getting into the network delivery and things like that.

So probably not the most efficient, probably not the most accessible to other people trying to do the same thing.

Phil: What's interesting is drawing these lines around where these spectrums start and end people has been traditionally very, very woolly from a business perspective, right?

This commonly fault of number, the broadcast television particular in America is somewhere in the region of the 15 second delay, glass-to-glass, which obviously varies massively.

As Steve said, the super bowl had a lot of built in latency designer outcome for many reasons.

And then there's this very woolly area of how close can you get to kind of that 15 second broadcast latency with the traditional technologies that Matt mentioned.

The H license, the trunk delivery technologies, and then anything lower than that, kind of becomes this super woolly area where we need some new technology that looks a bit like real time, but also looks a bit like these traditional HTP based technologies before you get down to that true real time conversation component.

I think to us like low latency would be anything above a second, but below 15 seconds and vendor's a scale there of ultra low latency being kind of that first one to five seconds and then low latency being kind of five up to that kind of broadcast latency level.

Matt: Would you agree with that, Steve?

Steve: You're saying ultra low sub four seconds. Is that what I'm hearing?

Phil: Yeah, pretty much four to five somewhere in that region.

Steve: Okay, yeah, and like real time being sub one second.

Phil: Yeah.

Steve: Or really, real time is really except 300 milliseconds essentially, right?

Phil: Yeah, it should be a lot of people advertise and claim real time, that is about a second as we're experiencing now, I don't think everyone would agree with that.

Steve: No anything above 300 milliseconds. Like if you're trying to have a Zoom call, that's above 300 milliseconds, you're pissed off. It's not a fun experience.

Phil: Right.

Matt: Even this where the latency is probably actually like, I'm assuming 700, 800 milliseconds.

Like it's not that high, but it's still just high enough where we keep like running into each other, trying to start talking.

Because that queue is just slow enough where it makes it tough, you know?

Phil: Mhm.

Steve: So yeah, that feels like pretty good lines to draw.

We've seen different groups try to, like Wowza I think was the original post that, attempted to like name these things and Will Law had a good update on that.

And then Phil, you created a version of it for your post. I think it's all hovering around the same seconds.

We have four to zero to one real time, one to four or five, low latency things above five, starting to get into more standard latency.

And it's this kind of juggle that maps somewhat closely, the technology that's driving you to those different levels.

Phil: And sometimes one of the challenges is there is this association of low latency being a parallel for like synchronous.

Like it doesn't matter necessarily in some use cases, if the latency is low as long as the streams are, for example well aligned, and so long as everyone's getting experienced at the same time.

And so long as metadata is timed, that can be part of an experience.

For example, if you were building your own HQ Trivia, but you didn't want to have that interactivity with the audience, as much fans, so long as the questions appeared at the right times and that sort of thing you actually don't care as much about the latency as the fact that all the questions are aligned and the viewers are all aligned as well.

Steve: Yeah, that's a really good point because it takes slightly different technologies to achieve synchronicity then low latency the lower the laser you get, the more you get synchronicity built in, they're not necessarily synonymous.

Phil: One of the things I always like to highlight when we have a lot of conversations about this at work with clients, as well as on video-dev and in Demuxed circles as well.

But one of the challenges and the things that a lot of people who aren't deeply versed in the industry is that there is always a sacrifice of stability with latency, stability and quality in many cases for latency, right?

If you want to bring your latency down, you probably want to send smaller packets more frequently.

That's going to make you kind of more susceptible to any network conditions that might be going on whether that, so I'm putting reader on top of microwave and turning a microwave on, whether that's someone's starting to watch Netflix in the next room.

There is always going to be, regardless of any of these technologies, no matter what any vendor tells you, there will always be this challenge of making sure that, sacrificing a stability component for a latency component.

Matt: Yeah, that's an important note that I think gets lost in a lot of this is that trade off.

Like we can continue to, even as we reliably start decreasing latency, all throughout the chain from end to end from broadcaster out to delivery, every issue that you can have along the way, which are legion, it's the internet all the way through--

Every issue you can have along the way it gets magnified when your margin for error is down to milliseconds, instead of potentially seconds.

All of those things that could potentially save you and help along the way, those all just go away.

And you're just kind of generally screwed, if the encoder disconnects or even the viewer's connection gets bad and like their buffer completely, is exhausted within 500 milliseconds.

Like all those cause problems

Steve: Yep, Yeah. At the player level that's essentially what it is.

Like we are talking about decreasing the buffer in order to get lower and lower, like closer and closer to real time, but by decreasing that buffer you're introducing the risk of rebuffers and having to pause to download more video and rebuffers are probably the most annoying thing when you're watching a video.

So, absolutely that's a good point. So, we have this kind of the bands for what different kinds of latency are, but we have had low latency video in the past.

So let's go through real quick the pre-Apple. This latency was possible. We talked about with HQ trivia and it's been done.

So talking about those technologies real quick, the first one that obviously comes to mind is RTMP.

I remember that was like when I first started helping with VideoJS, that was one of the most common issues and questions that I think we saw, was people wanted RTMP support and the flash fallback.

Matt: Oh my gosh. That was rough.

Phil: There is still people asking for that right? It's 2020 there's still people actively adding flash to things just to reduce latency.

Steve: Yeah, with RTMP on average I think it was actually around like five seconds latency honestly, but if you tuned it you could get it down to about two seconds.

I don't remember a lot of Google Hangout style applications, I guess, you did have some but they weren't the greatest latency when it came down to it.

Like not quite as good as like we have RTC today, but like you could get it down there.

Matt: Well the huge difference there if I recall correctly wasn't even necessarily that the latency was hyper-low, but that the playback was all synced

Steve: Mhm. Mhm.

Matt: Right?

Steve: Yeah, that makes sense. Because you have like a flash media server and the center that was like transcoding the stream and then basically the same type of concept of like a persistent connection out to each one of the users.

And at the time CDNs were stocking up on flash media servers basically like scaling those out in the same way that they were scaling just your normal HTTP traffic servers and you know, super expensive.

But yeah, that's how they were making this kind of large live streaming.

And even like on demand streaming, even YouTube I think was using RTMP to stream on demand video, just because you could get a little bit more consistent, sometimes a more adaptive experience using that protocol.

Matt: Well, Steve Jobs went on stage and killed flash was the big one.

So yeah, once flash died. RTMP died on the vine in terms of like playback, because if you can't play back in the browser go home, honestly.

RTMP is still incredibly prevalent because it's the most common way that anybody broadcast video I've talked a lot about this with like how to go live from the browser.

Because really you can't unless you, go through an intermediary service and then go to an RTMP endpoint.

Because that's what Twitch wants, YouTube, Facebook, Mux, I think Wowza has alternative ingest protocols, but the most common one is RTMP.

So anyway, like if you want to broadcast live, you are almost certainly doing it with RTMP right now. The flip side of that is I think why we're seeing so many requests for WebRTC now just because that's a word that web developers know when it comes to video.

This is where we get to this really interesting split and understanding between these things, where like--

If you're a developer that's primarily focused in the web, you work a lot in the browser, you know that you can build these chat applications using WebRTC and you know, that a service like mux or YouTube live or whatever else does video.

So you're like, It follows, why can't I just use this, to get to that? So I guess I'd love to hear a little bit of just about your all's thoughts on like WebRTC and the history here and how it fits into this story.

Steve: That is like from a technology perspective, it does get kind of like frustrating to hear the confusion behind it, but it makes perfect sense.

Like video is video to most people, but WebRTC was made to serve like a very different use case than like streaming video to many people.

And it's meant for like a direct connection between the people who are communicating.

And it does things like basically like aggressively throw out quality in order to stay close to real time.

And it says if your connection starts falling back, like it'll start scaling back the quality of the video in order to stay close to the live edge, compare that to the RTMP, which might get a little bit delayed, but it'll continue to send the high quality stream to the server.

And so that's a little bit of a difference between the two and you can kind of see where they start to differ.

Matt: It might help here to talk a little bit about, like I wrote this demo pushing WebSockets to a server that then takes those pipes as into FFmpeg and then it goes out.

And so I've gotten a lot of questions from people being like, why not just do that? If it works, why not just have that be the protocol?

And the reason I think that WebRTC could ultimately be a pretty interesting ingest protocol just in general, like A, supportive from the browser. B, it has things like rate control.

So that WebSocket thing, if your internet connection started crapping out and you just couldn't push the blobs of video down this WebSocket connection fast enough, you'd fall behind your encoder and eventually choked because it wasn't getting data, unless you did additional stuff behind the scenes, you would get disconnected.

It just wouldn't handle the bad scenarios very well.

Like the unhappy paths look really ugly with that as opposed to things like the RTMP specs, WebRTC, I don't know, RTMP as much as WebRTC, but like WebRTC is designed to keep sending video, however it possibly can.

So you might look like you're being recorded on a potato at times, but you will continue to send the video.

Which oftentimes, is preferable over just like the video capping out and just stopping, right?

Steve: Yeah.

Phil: Well, I think the differences here is and certainly from a broadcast perspective the expectations are super different, which is one of the things that comes up a lot.

For example, picking a product that exists in the market, right?

If you're using something like the Live View to broadcast like a bonded LTE signal over a bunch of cell networks back to like an edit suite somewhere.

The lower bounds on what is considered an acceptable video signal there are still really high in comparison to what WebRTC considers a lower bounce rate.

WebRTC will go to a postage stamp whereas generally, if you're in a broadcast environment, you would say, "well, "we can't risk broadcasting, a postage stamp."

So, if you go anywhere below a mega beta or something, we're actually going to bail out on this thing.

So, I think the interesting thing there is as the internet is a bit of a different world that to what people traditionally have felt fought off for a broadcast background for the minimum bounds there.

And yeah, it makes complete sense when you're talking about WebRTC from a conversational perspective.

Whereas I think WebRTC from an ingest protocol feels like a bit of a different beast in my mind.

I feel like I rarely see WebRTC being sent in higher than 540p video.

I'm trying to remember where I got that from, but, yeah, I don't see anybody streaming 1080p at a WebRTC.

Like it's all about just keeping that connection and enough quality so, you know, what's going on and it looks decent, but we're not talking high quality.

I think one of the things I'd love to highlight there is, there are actually some solutions on the market for kind of low latency and ultra low latency that do use technologies like WebRTC and for super interesting things there are some that utilize that kind of in the, traditional video domain.

But there's also a variety of approaches that just use WebRTC data channels to shuttle video around, which is kind of super interesting for a variety of reasons.

Because that's for example, a way to keep that sustained connection there, but not necessarily have that rate control that's built into WebRTCs video channels, which is kind of a super interesting approach on its own.

And there are a variety of people doing that sort of thing as well.

Steve: Mhm.

Matt: Do we want to dig into low latency Dash for just a second?

Steve: Mhm.

Matt: Since that's probably the thing that's most analogous to the low latency HLS spec that kind of kicked off this conversation.

Phil: Yeah, sure. So, this is one of those super interesting cases where, we're kind of now all talking about this really in my mind because, would we be doing the podcast, if Apple hadn't really thrown some fuel on the fire here?

But low latency and MPEG-DASH has been around for, a few years now and is relatively well understood and works relatively well.

And this is one of the fundamental components to how people think about low latency streaming on the internet today.

And it's also what presents the challenges and also what ultimately Apple set out to address in their specification, right?

Which is that the low latency DASH-MPEG uses something called chunk transfer mode, right? So this is a mode of HTTP.

So allows you to make HTTP request, but send a response that doesn't have a content length header.

So you can start sending your response before, you know, what you're sending.

And so you can send a chunk of a transport stream segment or a C math chunkers as it would be in modern day palliage. So, you have these HTTP requests that get made.

And then, it's kind of going to take, say, you've got a two second segment video.

It's going to take two seconds that to be downloaded 'cause you're kind of streaming these chunks out via encoder and packaging layers as they come. And chunk transfer mode has been around for a very long time. In fact, it predates HTTP 1.1 in fact, and this is how the low latency DASH spec is designed to work. And it works actually really well. And it works really well on actually even relatively lossy networks and high latency networks. It works well.

The place where this technology has been fundamentally challenged over the last year, year and half has been the fact that this is a technology that is really hard to get to work right with changeable networks.

If the other network has got like a one second latency and HTTP request latency in it, this technology will actually work fine with that.

If you're on a network where you've got some packet loss, this technology will generally work fine with that as well, because as long as it's consistent amount.

The challenge becomes when you're talking about a network that is fluctuating where the bandwidth for the packet loss over latency on my network is fluctuating.

Because, if you think about traditionally how we measure bandwidth and the HTTP environment, right?

You, do a request, you look at how long that request took to happen.

And then you say, cool, speed equals distance over time.

And you can look at how big that firewall is, how long it took to transfer.

And then you've got a good estimate of the network capability of that device.

And you can do that on every segment in a more traditional HTTP world, right? Or DASH world, right?

If you've got a two second segment, you get to do a bandwidth measurement every two seconds, which allows you to react quickly.

But in a world where you're downloading these parts, every two seconds, but they're taking two seconds to download.

You don't really have an opportunity to do bandwidth measurement there.

This is where this technology has become fundamentally challenged over the last 18 months.

Steve: Mhm.. So adaptive streaming has proven to be difficult, right?

Because of measuring the actual segments that are coming down. That's interesting.

Phil: And these aren't new technologies, right?

So if you look how LL-DASH works, these concepts were all coming out around the same time.

So I'm not going to say directly who, I think really there were three people in the industry all effectively doing the same thing at the same time.

And it was the low latency DASH group, which is Stockhammer, Will Law those sorts of people, there was also Periscope at the time, this is a pre Twitter acquisition.

They also took the exact same approach in their low latency streaming product. It was HTTP chunk transfer mode, but also Twitch.

Twitch even still to this day. Still continue to use a version of chunk to transfer transferred HLS.

It's not DASH, but it is built around this fundamental approach of using a chunk transfer on HTTP based streaming technologies.

Steve: Now that there have been attempts. to improve the adaptivity of that, right?

To actually build an algorithm that can measure the chunk transfer encoding

Phil: Yeah, absolutely. I mean, there's been a variety of ways that people have tried doing this.

The most primitive way which some people still use is every 10 segments go off and get a segment at aligned speed and use that as your measurement.

Now, like I say, that is what gives you challenges in rapidly changing network environments.

And in fact, you can still see this happening on products like Twitch even.

Twitch still falls back to a higher latency experience.

If your connection is fluctuant, there's been other approaches.

For example, one of the common approaches is based on buffer fill rates.

So is your buffer filling or is your buffer draining?

And that can give you a good indication of whether you're getting frames and stuff in quickly enough.

And there's a really good white paper as well on this came out of ACTE last year she was a really good novel approach to this as well.

And in fact, I believe it's still on, I'd have to check.

But I believe Twitch actually offering a pretty big reward in this year's ACTE to someone who can produce a bandwidth estimation strategy for low latency that outperforms current approaches.

Matt: Yeah, before we get into Apple's official low latency HLS spec that I think is kind of the catalyst for a lot of this, there actually was a really good community spec that was released.

It had, a lot of folks interested in it. Quite a few companies were actually starting to develop against it.

It was developed by John Bartos, who is the maintainer of HLS.JS So he announced it at March 2018.

Phil: '18, yeah. I wanted to say '18.

Matt: And it really did. It had legs, People were talking about it, developing against it.

We had started working against it because it didn't seem like the kind of thing that Apple.

Correct me if I'm wrong, at least in my opinion, it didn't feel like this was going to be the type of thing that Apple was going to explicitly do.

So I was kind of shocked when Apple did and we wrote the whole blog post.

Honestly, we were a little bit annoyed that Apple kind of quietly behind the scenes went and did this thing and didn't really involve the community.

And we had this kind of community driven thing.

Steve: Right, yeah. It was that plus just the fact that it was so different from everything that the community was doing.

Phil: Right and this is the thing, the community approach was going to be fundamentally interchangeable with LL DASH, Will Law was working closely with John on that, which I think made a big impact on how people viewed that in the industry.

Steve: Yeah.

Matt: Anyway shout out to Bartos there, he put in a ton of work and it was really impressive and we were really excited about it, and the demos he showed, like he showed a demo at reframe in New York,

Steve: Re-framing.

Phil: Shout out to reframe.

Steve: Shout out reframe.

Matt: He did a demo there and it was really impressive and like the way you can have like patent latency, I was really excited about it.

So it was a shame to kind of feel low latency, HLS jumped from being something that could have been available and I don't know end of 2019 for a lot of people to just like completely stopping all momentum there.

Phil: Yes.

Matt: And certainly like low latency HLS was relegated to be in kind of when we would start seeing--

Like nobody's going to to keep working on something when Apple was going to release an official thing in the next year, two years, so like everything just went on pause and it went from being something that was really tangible and like right there to being a year plus out, which we're still waiting.

Steve: mm-hmm

Phil: I think what's been really important to highlight there though Matt, is while it was there and within touching distance, It didn't give an answer for iOS.

Matt: Yes.

Phil: Which is always going to be kind of one of the biggest challenges here is like yeah we can say "Hey, this is here "and it works with like the the Bartos spec and the LL-DASH spec."

But if it doesn't work on an iPhone, does any of that matter?

Or kind of more specifically if I have to ship, a completely custom app with a bunch of proprietary stuff in it, is that going to make it through Apple's approval process?

Even if it does, is that how you want to go about building and maintaining your app on iOS?

And I think the reason that the part of a reason, at least that Apple gets to kind of win on this by bringing in their own spec is the fact that they can say, "Oh yeah and by the way, it'll actually work on iPhone" at some point down the road.

Of course nobody still knows when that's going to be, even for what we're doing now.

We still don't know when Apple going to release official support for what they're proposing now but one has to imagine a little bit at some point, right?

Steve: Well and then the other side of it is we don't know how well it's going to work in the browser, whereas like the community spec, was built for the browser, the Apple spec really is pretty untested in the browser and relies on things like HT push, which is pretty raw and from browser support standpoint especially for transferring video files, not just CSS files.

So that's kind of open-ended.

Phil: Yeah but hey, the good news is it's no longer HTTP/2 Push, It's not much better for that, so It is marginally better.

Steve: Which is a nice segue into Apple's new low latency HLS approach. Because they essentially bypass that whole issue with the way that they approached it, is that right?

Phil: Yeah now I think this is an interesting one because there's a little bit of background here, but we should touch on.

About a year ago, It was WWDC last year when Apple formally announced, "Hey, we're putting a low latency mode into HLS" Roger Pantos, gets a session WWDC and gets to talk about stuff.

And this year is how we're going to do low latency.

And I think what's interesting here is, the business cases for what they were pitching were pretty much aligned across all of the approaches, right? They were pitching something it gave around five seconds of latency was their number. Utilized traditional HTTP technologies wasn't changing the world per say. It changed the world in a different way. But that was their initial pitch.

'Cause, it's still trying to solve the same business case the LL-DASH and the community, the latency HLS, which we haven't really talked about spec we're designed to solve as well.

It's still that sort of territory of latency tuning. Now, of course, what's interesting.

There is that kind of kickoff process from WWDC when that was announced, really kicked off a lot of conversation in the video developer space around the new specifications.

The new specifications introduced a variety of new features into HLS that, we'll go into in a bit more detail on the next episode.

But the big change really there for Apple was, they wanted to move a low latency into a world of a HTTP/2 push delivery technology rather than kind of a more traditional HTTP gets that you see being executed for a traditional HLS and traditional DASH.

And they very specifically avoided, going down the route of the chunk transfer mode that was common to both LL-DASH and the community approach for low latency HLS as well.

Now, a lot's changed, over the last 12 months. We're coming up to 12 months from last WWDC now and that specs changed a lot and has evolved.

And now it looks quite different to it did and huge thanks to the guys at Apple, but also everyone else in the ecosystem.

A lot of the video industry spent two full days giving feedback to Apple.

Working with Apple, to resolve issues on the low latency, HTTP live streaming specification.

And we believe a lot of those are now resolved in the latest version of specification and one of the critical things to people in the room there.

And to give some idea, this was 35-40 people from around the video streaming industry.

And what was common with all those people is really what everyone wanted was an interchangeable specification here.

They wanted to make sure that they could reuse in particular, the media chunks that were coming out of their encoder and making sure they could be fed in a universal way, ideally through one CDN configuration that worked for the vast majority of devices, right?

If you imagine LL-DASH working well for XO Player on an Android device and potentially a web client.

Everyone's desire was to use those same encoded segments ideally served in the same way over a HLS based technology.

We'll get into that more next episode, right?

Matt: Yeah, hopefully if you weren't familiar with kind of the landscape of what was going on with low latency HLS and the application system and what all this means, hopefully that's a little bit of an overview.

The plan for this next episode is we, and when I say we, I mean, mostly Phil, will dig into the new HLS spec and really explain to us what that means, what the changes are that were recently release.

Because Pantos actually did, they announced all this, but last week or two weeks ago was the first time we saw like an official release of the HLS spec.

So what we'll learn what's in there, what we've actually seen, what the changes are. And I think that's where we'll take the next episode.