Re: [Moq] Scope of MOQ and ULL Streaming

[Nathan Burr <[e-mail]>]

MQTT is a Pub/Sub protocol used for sending data generally for the
"Internet of Things" devices to the cloud. I wouldn't use it here for this
type of thing. but something similar could work. What I like about it is
how you can create topics ( looks like paths ) and use wildcards. This site
<https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/>
might help if you would like to learn more.

encoders would publish data to a topic.

anyone can subscribe to a topic and so any updates get sent to all people
who subscribe as soon as they are available

You could make it so you could subscribe to Big_Buck_Bunny/Metadata  and
then have it send the current persistent data for that topic and all future
updates or just do a regular GET request for the current metadata and not
subscribe to any changes.

On Mon, Feb 6, 2023 at 9:04 PM Shihang(Vincent) <[e-mail]> wrote:

> <External Email>
>
>
> Hi Nathan,
>
>
>
> “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.”
>
> I am not familiar with the MQTT. What is the difference between the
> Subscribe and GET?
>
>
>
> Cheers,
>
> Hang
>
> *From:* Moq <[e-mail]> *On Behalf Of *Nathan Burr
> *Sent:* Tuesday, February 7, 2023 1:05 AM
> *To:* [e-mail]
> *Subject:* [Moq] Scope of MOQ and ULL Streaming
>
>
>
> *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
>    <https://urldefense.com/v3/__https://media.idlab.ugent.be/keyframe-insertion-electronics__;!!CxwJSw!LOoclAmKobZ09z6p5IugHIWxEy8E7fyRwvdOA-UWtCTQzsvTqJ403kaIhBxVsr9_yhbH5gPzeBRAn6qOXBJq$>
>
>
>    - 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
>    <https://urldefense.com/v3/__https://github.com/w3c/webcodecs/issues/41__;!!CxwJSw!LOoclAmKobZ09z6p5IugHIWxEy8E7fyRwvdOA-UWtCTQzsvTqJ403kaIhBxVsr9_yhbH5gPzeBRAn56wzYmv$>
>    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
>
>
>
>
>
>
>
>