Streaming format negotiation

At June interim Wil Law presented the WARP streaming format, which identifies itself within the payload using the first varint bytes. This is a concern as it implies:

• All formats must at least start with a varint, and does not permit other formats to use different structures
• It could impede negotiation for catalogue formats as it happens after at least one format is sent

Discussion in the chat suggested to provide the format in the transport as part of an ANNOUNCE, but instead of having it as part of the name, if it makes sense to use a varint include it as a separate field.

[kixelated]

I think it's strange to include the catalog format/version inside the catalog itself. It means a subscriber has to request the catalog before it knows if it can parse it.

Here's my proposal for "track format" as part of the ANNOUNCE (#150). It basically moves the track format/version varint to the ANNOUNCE message, allowing it to behave like a catalog of catalogs.

An alternative I kind of like is something @vasilvv has mentioned. We can use the track name to identify the catalog format, much like how an extension is used to identify a file format. For example, ANNOUNCE catalog.moov catalog.m3u8 would advertise two possible catalog tracks.

@kixelated I don't think using "file extensions" like Victor suggested would be good for implementations - all the other data is part of a structure of some kind, but to separate catalog name from format you have to split('.') seems a kludge. I think ANNOUNCE might need a bit more thought on its structure and both sender/receiver behaviours - in particular being descriptive of what happens when a format is unsupported. I'm happy to make a PR.

[vasilvv]

To clarify, my proposal was roughly:

1. Every format has an associated catalog name (/warp, /loc, or, if we unify the catalog format, /catalog_v1 or something).
2. The client knows the names of the catalogs corresponding to formats that it supports, so it just sends something like SUBSCRIBE /warp OR /loc OR /someotherformat, and it will result in being subscribed to the first format that exists.

Note that this does require a SUBSCRIBE message that allows requesting a list of multiple alternative tracks, but it keeps the ANNOUNCE message as-is. An alternative would be having a list of available catalogs in ANNOUNCE, and only subscribing to one of those.

all the other data is part of a structure of some kind, but to separate catalog name from format you have to split('.') seems a kludge

You don't have to separate those, those are fixed strings.

[kixelated]

Sorry @vasilvv, I didn't meant to misrepresent your proposal. Let me try to summarize the options proposed so far.

How does the receiver learn about available catalog tracks?

1. There's a fixed catalog track.
2. There's a fixed catalog track per format, and the receiver blindly subscribes to all supported formats.
3. The ANNOUNCE messages contains a list of tracks.

How is the track format encoded?

1. The first few bytes of the track
2. The full name of the track.
3. The track name prefix/suffix.
4. A separate field in ANNOUNCE.

All of the proposal need some sort of track format registry.

[kixelated]

I personally like making ANNOUNCE mandatory, sent immediately after SETUP when ROLE=publisher. At a minimum, the ANNOUNCE contains a list of catalog tracks and some way to identify the format.

That way receiver knows that a track both exists and is supported prior to subscribing to it.

[wilaw]

I like Victor's proposal of each streaming format defining a unique name for its catalog. We can ensure uniqueness by having the catalog name being one of the registered attributes in the IANA table for MOQT Streaming Formats.

Since a catalog is just a track, the ANNOUNCE does not have to specify the type of streaming format, it simply announces the name of the track, since the the name would then infers the type.

Further, if we enforce the convention that track names are relative to the catalog (or conversely that track names carry the catalog full track name as a prefix), then we have a concise mechanism for announcing multi-format content. Consider the case of a producer emitting two sets of content, one packaged for /warp and the other for /loc.

The total tracks it is producing would be:
example.com/alice/12345/warp
example.com/alice/12345/warp/video
example.com/alice/12345/warp/audio
example.com/alice/12345/loc
example.com/alice/12345/loc/abc/front
example.com/alice/12345/loc/abc/back
example.com/alice/12345/loc/abc/audio

The ANNOUNCE could then simply advertise the catalogs
{
example.com/alice/12345/warp;
example.com/alice/12345/loc
}

In fact, since relays don't need to understand catalog formats, the ANNOUNCE could just advertise the minimum common path for the all the content that client is publishing, which would be
{
example.com/alice/12345/
}

[alvestrand]

Note that reusing the "track" namespace for a set of standardized names now means that you have both a controlled namespace (the standard names) and an uncontrollled namespace (server chosen names) in the same protocol field.

If you want to do that, good practice is to reserve some prefix for one of the usages, so that they can never collide.