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!

Safari is still working to add full support for WebTransport.

You can enable webtransport in safari, in privacy settings experimental tag, but its just black on the page

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

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!

So... MoQ represents a bit of a moving away from the all-in-one "black box" of web APIs like WebRTC. From the browser perspective, the main thing that matters is the WebTransport API. Using MoQT in conjunction with that WebTransport API, you now have various options for rendering the video as a player, for example: WebCodecs. But, if you can afford a bit more latency, you can also use APIs like MSE for playback and be able to use DRM.

And yeah, being able to publish from something like OBS is something I worked on before joining Cloudflare, but it depends a lot on what you do at the "streaming format" layer which is where all the media-aware details live. That layer is still evolving and developing with WARP being the leading spec so far. As that gels more, it'll make sense to bake things into OBS, etc. Already today though you can use Norsk (https://norsk.video/) to publish video using a rudimentary fMP4-based format similar to early versions of the WARP draft.

As for YouTube, Google has some folks who have been very active contributors to MoQT, but I'm not certain exactly how/where/when they plan to deploy it in products like YouTube.

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)

I e-mailed to ask they swap it back - I like your post, too!

Also, putting it out here, we're building on a _lot_ of kixelated's work with what we've deployed, so he really deserves a lot of credit.

Ok guys, we'll swap it back. Give me a minute... Edit: done now.

Thank you so much dang.

You might be interested in looking at this RTC example for ideas about how to make bi-directional data flows for arbitrary groups of participants (or players) work through a relay.

https://hang.live/

It uses a feature we haven't yet implemented, but we're thinking about how we might implement it at our scale, SUBSCRIBE_ANNOUNCES[1].

[1]: https://www.ietf.org/archive/id/draft-ietf-moq-transport-12....

It could! We've mainly been focused on using it for audio and video for live streaming and RTC use cases, but the MoQT layer is very intentionally decoupled from the media details so the fan out infrastructure could actually be used for a lot of different things. You'd need to decide how you want to map your data to MoQT objects, groups, tracks, etc.

Sweet, thanks! I'll tinker with it.