Editor's Note: The following is a sponsored guest post by Luke Curley, one of the creators of Media over Quic. The views, technical perspectives, and opinions expressed below are entirely his own and are separate from Fastly's views, product offerings, and technical specifications.

Hello Fastly fans.

I'm Luke aka @kixelated aka one of the creators of Media over QUIC. Fastly likes my MoQ blog posts and sponsored me to write some more. For some reason…

The twist is that there are two copies of this blog post:

1. This normal post about MoQ and Formula 1.

2. An unhinged post about Lightning McQueen.

Pick your poison. We're going to learn about the numerous ways you can use MoQ in the fast lane. Either way, you’re getting a badly traced picture of a car. At least it’s not AI generated.

The State of Race

Let's say you're a big fan of F1. A MASSIVE fan, but this little thing called disposable income prevents you from going to every race.

Sooner or later, you're going to want to watch the race from your living room. We need some way to live stream the race over the internet to your eyeballs.

The answer for the last decade has been HLS/DASH. Take a media stream, split it into 0.5s to 4s long chunks, and serve them over HTTP. It's boring, but it works, and Fastly does it well (sponsored shilling btw).

The problem is that we hit a latency wall:

• Flushing media in batches adds latency (0.5s to 4s).

• Network congestion causes head-of-line blocking and buffering.

• Every second of buffering means even more latency.

This latency wall is why I created MoQ, while at Twitch. The goal was to make live streams more interactive (and less boring). Stream frames, and occasionally drop instead of blocking.

No amount of LL- prefixes or ULTRA LOW LATENCY marketing can fix this. We need a new protocol to avoid head-of-line blocking, stat.

MoQ for the Fans

First, I want to address the elephant in the room. I've stated in the past that you don't need MoQ for high-quality content.

And it's true. If you want to see every frame of a live stream, there's not much to gain from MoQ. You're much better off using HLS/DASH with a large buffer to smooth out network hiccups. Similar to how YouTube downloads minutes of video in advance.

Like yeah duh, waiting is always going to result in better picture quality. But the hypothesis is that some users prefer lower latency at the expense of quality.

Often the thrill of watching a live stream is to be part of the story LIVE, not to see every millisecond of lap 392. It's why Twitch exists in the first place, the interactivity is more important than the quality.

Maybe the user is betting on the race, or posting on social media, or just want to be the first to know. It feels bad being in last place. Knowing that you're still on lap 392 while your neighbor is on lap 393.

Anyway, this wouldn't be much of a technical blog post if I didn't explain how it works. MoQ can prioritize newer content over older content (in dependency order). So each viewer gets to pick if there's a gap in the middle, or a gap at the end.

There's absolutely a tradeoff here. But that's also the beauty of MoQ, it's a configurable latency dial you can crank up or down.

NOTE: MoQ can match the quality/latency you expect from HLS/DASH. We just allow a lower latency floor.

MoQ for the Cars

While I originally made MoQ for the fans, companies insist on running it on the cars. Or the drones. Or the boats.

One of the challenges of live streaming is getting the content off of the vehicle. Cellular and satellite networks are a mess. I don't actually watch F1, but when I do see snippets of it, the camera feeds from the cars are awful.

I'm a video star, not a radio star, but I'm guessing it's probably due to networking. There's going to be deadzones or interference or whatever around the track. A reality of signal transmission is that you're going to have to deal with periods of high, low, and zero bandwidth.

The feed coming from an F1 car is going to use something like RTP over UDP. There are many, many different approaches, but typically an RTP publisher gives a frame a ~100ms deadline before it's dropped forever. So a small blip of signal interference results in artifacting, tearing, or frozen video.

But MoQ doesn't give up.

Like I said earlier, MoQ instead prioritizes transmitting the newer stuff (in dependency order). The old stuff doesn't get dropped, it gets queued in RAM (up to a TTL). When bandwidth recovers, we can backfill old footage instead of losing it forever.

Each MoQ subscriber independently decides how long to wait for each frame:

• The live stream might wait for up to 1 second

• The instant relay might wait for up to 10 seconds

• The VOD recording might wait for up to 1 minute.

All that extra time means more time for old frames to arrive. The real-time feed might be lossy af, but the VOD is pristine.

MoQ for the Robots

Humans aren't the only ones who need live streams. Enter the robots. They byte.

It turns out that MoQ works for more than just media:

• The speedometer? A live stream

• The steering wheel? A live stream

• The G-force sensor? Believe it or not, a live stream

Seriously, there's nothing special about media. It's just delta encoded data. You can delta encode a lot of things, even JSON.

Networks are finite, so we split up media into pieces. Each individual track, group, frame, packet, could be dropped without terminating the media stream. The reality is that some bytes are just less valuable than others.

The hard part is putting humpty back together. That's why we use timestamps; they tell us when stuff happened relative to other stuff. Even metadata gets stamped so it can be associated with audio/video frames.

You can, and should, take the red pill and use MoQ for EVERYTHING. A single cooperative QUIC connection with: ‘controls > audio > metadata > video’

FUN FACT: MoQ is being used remotely to pilot drones over Starlink. Not just for the camera feed, but for the controls too!

And yes, this sounds simple but it's something WebRTC completely botches. You have to use a separate connection for metadata and timestamps aren't exposed in the browser.

MoQ for the Track

It turns out there's a LOT of video cameras around a race track. And there's a LOT of eyeballs that want to see them.

We don't want viewers directly connecting to each camera, of course. There's no way that poor video camera could push 100k copies of the same feed. We want broadcast studios to take those input feeds and combine them into a syndicated feed for distribution.

But what if there are multiple broadcast studios that want the same footage? Satellite trucks are expensive and have a limited bandwidth budget. We don't want to transmit multiple copies of the same footage, nor do we want to transmit footage that no one wants.

Here's where MoQ shines.

moq-relay is a simple proxy that connects 1 publisher with N subscribers (per broadcast/track). When moq-relay instances connect to each other, they automatically form a cluster. You can host them yourselves (it's all open source) or pay a CDN to host them for you.

moq-relay handles discovery, routing, and proxying. For example:

• Each camera connects to a self-hosted moq-relay at 192.168.420.69.

• moq-relay is run with --cluster-connect https://cdn.moq.dev/f1.

• Studio clients (or a relay!) connects to https://cdn.moq.dev/f1.

Magically, all camera feeds are automatically available at every relay, automatically proxied if needed. And only one copy is ever transmitted between each moq-relay instance regardless of the number of downstream subscribers.

This is a huge deal when there's a flakey venue internet and expensive satellite trucks are involved. Run a few moq-relay instances at each race track, aggregating all of the feeds automatically, and publish them to a CDN. ez pz!

And there's no limit to the number of connections you can establish. moq-lite will use the connection with the shortest path if there's a tie. Maybe one connection is over ethernet while the other is over satellite; go wild.

Conclusion

Media over QUIC has a ton of interesting use-cases, even beyond media. It's the future of live streaming and you should join the ride. vroom vroom.

Thanks again to Fastly for sponsoring this post. They just told me to write something about MoQ, so I did. DISCLAIMER: I don't even watch F1 lul.

Written by @kixelated. Feel free to send me an email or check out moq.dev for more MoQ yum yums.