[Moq] Scope of MOQ and ULL Streaming

[Nathan Burr <[e-mail]>]

*Discussion #1:*

I've spent a bit of time trying to wrap my head around what MOQ is and I
feel like this needs to be discussed further. I've seen everything from VR,
Conferencing, ULL Broadcasting and gaming as possible use cases. I feel
like this is an important discussion because MOQ could be a base layer spec
that supports all of these. But that means possibly the need for more
specs. Such as VR ov MOQ or ULL Streaming over MOQ. Or it could be a Spec
that is more specific to just one thing. The original work around WARP
seemed to lean more towards ULL Streaming while RUSH leaned more towards VR
and gaming.

So where does MOQ fit into all of this? Maybe this has already been
discussed and I'm just missing context..

My expertise is around ABR Streaming. So I'll be providing more feedback on
that side of the conversation of where I would like things to go.

*Discussion #2:*

What is the target latency? Maybe that depends on the answer to Discussion
#1. For ULL Streaming I would think somewhere between 500ms - 2.5s.

*Discussions around ULL Streaming involving MOQ:*

[image: image.png]

In my opinion, MOQ should be a stateless forwarding machine. I would like
to do two basic types of requests.

   - Subscribe
      - I picture this is something similar to how MQTT works with topics.
      Subscribe to a topic or sub topics and use wildcards. Example:

      Big_Buck_Bunny/VideoTrack{N}/Representation{N}/
      Big_Buck_Bunny/AudioTrack{N}/Representation{N}/
      Big_Buck_Bunny/SubtitleTrack{N}/Representation{N}/
      - GET
   - I feel like this would still be important to discover information
      about the channel without having to subscribe. IMO each topic should have
      an associated metadata endpoint. that describes the channel, track,
      representation. This way a client can get stream details without needing
      information from a manifest.

Relaying is probably out of scope for MOQ. Looks like some are working on
that process. But I would imagine some sort of smart relaying where you
only relay what is being subscribed to down the subscription chain.

In order to support channel composition (inserting ads, blackout, slate,
scheduling, switching channels, PiP, contributor feed, commentary, etc.) I
feel like we will still need a manifest of some sort that contains
different metadata from different assets and channels. In this scenario
having the ability to share a session ID between the manifest and transport
would be important. This would probably fall under some of the other AuthZ
type of discussions.

Session ID would be needed to make sure to terminate any subscriptions
after their subscription has expired.

*Next Gen ULL Streaming Wish List:*

   - "Synchronization Tracks" for quick channel switching and recovery.
   https://media.idlab.ugent.be/keyframe-insertion-electronics
      - AV1 - Switch Frames
   - DRM - EME requires ISOBFF. Would be nice if EME supported raw ES. Some
   discussions around content protection and WebCodecs:
   https://github.com/w3c/webcodecs/issues/41
   Could make it so we transport CMAF over MOQ or make a polyfill around
   EME/MediaSource that muxes content into ISOBFF format. as long as the ES
   conforms to CENC spec.
   - No more polling. Updates to the manifest are streamed.


-Nate