Generic clients connect via single URL

[kixelated]

This is more of a requirement.

We need the ability for generic clients to publish and/or view a broadcast via a single URL. Examples of generic clients include OBS, ffmpeg, ExoPlayer, moq.js (TBD), and any other implementations.

Currently, Twitch broadcasters publish broadcasts via a rtmp:// URL and viewers can consume via a HTTP HLS URL. We would want something similar for MoQ.

If there's a good reason we can require more than just a URL, but it has to be simple enough and explicitly part of the specification. No punting responsibility to the application because it hurts interoperability. An example is WebRTC, which did not specify how to exchange the SDP offer, and was only recently fixed by introducing WHIP and WHEP.

[afrind]

Based on how the current draft reads, I think you could construct a URL like:

https://example.org/webtransport-endpoint?full-track-name=X&auth=token

[or similar for raw QUIC, but using the moq:// scheme]

This would establish a QUIC/H3 connection to example.org, a session to /webtransport-endpoint (WT CONNECT or SETUP PATH) and a SUBSCRIBE to full-track-name, with the associated auth (see moq-wg/moq-transport#159 for example flow).

There are of course other ways to spell this. Should this draft explain how to go from a full URL through connection/session establishment + sequence of messages?

@kixelated

[fluffy]

I think this should be in it's own draft, not part of the transport draft. It need to point at the appropriate catalog, transport etc. I think it should also specify what media codecs are MTI and what are optional. To have interoperable, it needs to be that if I give the player the URL, I know that if can be played. Similarly, if the URL is publish, a client that is implements whatever the spec that de

[kixelated]

Yeah, this would be part of the Warp draft, not the transport draft.

[afrind]

What is the relationship of this issue to moq-wg/moq-transport#268? Can one be closed?