englishm

TL;DR:

- API for self-service MoQ relay provisioning.

- simple scope-granularity rw/ro auth (plans for more advanced auth as standards mature).

- globally deployed draft-16 support (draft-18 work already underway).

- SUBSCRIBE_NAMESPACE + PUBLISH support

(this is my team/product)

Yes, you certainly could use MoQ to send multiple streams (WebRTC simulcast style).

There are implementations of traditional receiver-side adaptive bitrate switching with MoQ already today (mostly switching between tracks at group boundaries). There has been interest in exploring sender-side adaptation as well, but it's not clear what that might require and if it's something worth trying to support in the first version of the spec we take all the way to RFC status. Subgroups are something that can be used today, though less experimentation (at least public experimentation) has been done on fully utilizing subgroups at this point. They could be used for independently decodable tracks, though that wastes bandwidth relative to layered codecs. Even layered codecs have some overhead that may not always be worth it. If RTT is low enough and switching is straightforward, it may be that having the original publisher publish multiple tracks into a relay and allowing the end subscriber to switch between them is sufficient.

We could really use more public experimentation with all of these approaches, so if anyone is looking to do that type of research, definitely let us know how we can help support it!

Yes, Safari's WebTransport implementation is still a work in progress.

Safari is still working to add full support for WebTransport.

I plan to cover more of the internal implementation details at a future date, possibly at a conference this fall..

But I can at least say that we use anycast to route to a network-proximal colo.

Looks like it might be a happy eyeballs issue? I'll pass it along to folks who would know more about what that might be, thanks.

Thank you dang!

Synchronized playback is usually primarily a player responsibility, not something you should (solely) rely on your transport to provide. We have had some talk about extensions to allow for synchronizing multiple tracks by group boundaries at each hop through a relay system, but it's not clear if that's really needed yet.

Essentially though, there are typically some small jitter buffers at the receiver and the player knows how draw from those buffers, syncing audio and video. Someone who works more on the player side could probably go into a lot more interesting detail about approaches to doing that, especially at low latencies. I know it can also get complicated with hardware details of how long it takes an audio sample vs. a video frame to actually be reproduced once the application sinks it into the playback queue.

Yes, exactly! I mention that in the post. Streaming formats are where a lot of interesting decisions can be made about how best to optimize QoE for different use cases. MoQT is designed have enough levers to pull to enable a lot of clever tricks across a wide gamut of latency targets, while also being decoupled from all of the media details so we can get good economies of scale sharing fan out infrastructure.

WARP's development (at the IETF) up until now has been largely spearheaded by Will Law, but it's an IETF spec so anyone can participate in the working group and help shape what the final standard looks like. WARP is a streaming format designed mainly for live streaming use cases, and builds on a lot of experience with other standards like DASH. If that doesn't fit your use case, you can also develop your own streaming format, and if it's something you think others could benefit from, too, you could bring it to the IETF to standardize.

(OP of the Cloudflare blog & submission here) I think kixelated is saying enough stuff beyond our post that he deserves the credit for and this shouldn't be treated as a dupe. (emailed to say as much also)