Supporting a publisher outputting multiple media formats simultaneously

[wilaw]

In the current workflow, the client requests a catalog using a reserved name and that catalog specifies which media format it represents using an IANA registered ID. There can only be one catalog, and hence one media format, for a given content bundle.

What happens if the publisher wants to publish content via two different media formats simultaneously? Should we allow this and if so, how can we enable the identification of the formats that are available?

Does the client need to be able to ask which formats are available for a given resource before requesting the catalog for that format?

[suhasHere]

this issue made me think that we need to define following terms in the transport spec

• media format
• media container format
• catalog format

I wonder if meida format is too generic a term ?

[wilaw]

In discussing this with @kixelated we came up with several different solutions

1. We continue what works for HLS and DASH today, which is that the client knows what format it expects before it begins playback. The connection URL to the publisher dictates what format is used by the catalog and only one catalog. IN a world where we have MoQ formats also called HLS and DASH (for simplicity), this would look like:

Client connects to https://cdn.example.com/hls/some/path A 'catalog' subscription returns a catalog in hls format

Client connects to https://cdn.example.com/dash/some/path A 'catalog' subscription returns a catalog in dash format

2. We create reserved catalog names for each media format. They can specify these names as part of their IANA reservation.

Client connects to https://cdn.example.com/some/path A subscription to "catalog-hls' returns a catalog in hls format A subscription to "catalog-dash' returns a catalog in the dash format

3. The publisher returns a master catalog that lists all the media formats and their tracks that it is producing. Client connects to https://cdn.example.com/some/path A subscription to 'catalog' returns a catalog with the following pseudo-structure

Catalog {
    Formats [
        { hls : tracks [ ..] }
        { dash : tracks [ ..] }
    ]
}

[hardie]

On Fri, Apr 21, 2023 at 4:42 PM Will Law @.***> wrote:

In discussing this with @kixelated https://github.com/kixelated we came up with several different solutions

1. We continue what works for HLS and DASH today, which is that the client knows what format it expects before it begins playback. The connection URL to the publisher dictates what format is used by the catalog and only one catalog. IN a world where we have MoQ formats also called HLS and DASH (for simplicity), this would look like:

Client connects to https://cdn.example.com/hls/some/path A 'catalog' subscription returns a catalog in hls format

Client connects to https://cdn.example.com/dash/some/path A 'catalog' subscription returns a catalog in dash format

(personal hat)

Both BCP 56 and BCP 190 strongly urge protocol designers not to assume that you can define path elements as specific to a particular usage of HTTP (Section 3.2 of BCP 56 and BCP 190 Section 2.3). Other than .well-known, this approach has to be a hint or it's probably a non-starter.

regards,

Ted

1. We create reserved catalog names for each media format. They can specify these names as part of their IANA reservation.

Client connects to https://cdn.example.com/some/path A subscription to "catalog-hls' returns a catalog in hls format A subscription to "catalog-dash' returns a catalog in the dash format

1. The publisher returns a master catalog that lists all the media formats and their tracks that it is producing. Client connects to https://cdn.example.com/some/path A subscription to 'catalog' returns a catalog with the following pseudo-structure

Catalog { Formats [ { hls : tracks [ ..] } { dash : tracks [ ..] } ] }

— Reply to this email directly, view it on GitHub https://github.com/kixelated/warp-draft/issues/140#issuecomment-1518017619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKVXZGCKFOWGO3GTXH6DXTXCKTIFANCNFSM6AAAAAAXGMCBNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[suhasHere]

Why can't we either specify in SETUP message or add as Track Request Parameter to identify the format needed ?

[fluffy]

wow - I wish we called this something different than media format. I thought this bug was going to be about if I could output AV1 and AV2 and the same time. We absolutely need to be about have a client that supports AV1 and AV2 be able to do both or we have no way to transitions from AV1 to AV2 before all clients support AV2.

I suspect we have the same issues here, if a system is trying to move from an old format say DASH to something new like QuicDASH, you will want publishes to be able to publish both during the transition and the old clients to subscribe to the old and clients that support both to subscribe to the new.