Internet-Draft Common Catalog Format for moq-transport July 2024
Nandakumar, et al. Expires 9 January 2025 [Page]
Workgroup:
Media Over QUIC
Internet-Draft:
draft-ietf-moq-catalogformat-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Nandakumar
Cisco
W. Law
Akamai
M. Zanaty
Cisco

Common Catalog Format for moq-transport

Abstract

This specification defines a Common Catalog specification for streaming formats implementing the MOQ Transport Protocol [MoQTransport]. Media over QUIC Transport (MOQT) defines a publish/subscribe based unified media delivery protocol for delivering media for streaming and interactive applications over QUIC. The catalog describes the content made available by a publisher, including information necessary for subscribers to select, subscribe and initialize tracks.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://moq-wg.github.io/catalog-format/ draft-ietf-moq-catalogformat.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-moq-catalogformat/.

Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/.

Source for this draft and an issue tracker can be found at https://github.com/moq-wg/catalog-format.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 9 January 2025.

▲

Table of Contents

1. Introduction

MOQT [MoQTransport] defines a transport protocol that utilizes the QUIC network protocol [QUIC] and WebTransport[WebTrans] to move objects between publishers, subscribers and intermediaries. Tracks are identified using a tuple of the Track Namespace and the Track Name. A MOQT Catalog is a specialized track which captures details of all the tracks output by a publisher, including the identities, media profiles, initialization data and inter-track relationships. The mapping of media characteristics of objects with the tracks, as well as relative prioritization of those objects, are captured in separate MoQ Streaming Format specifications. This specification defines a JSON encoded catalog.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Catalog

A Catalog is a MOQT Object that provides information about tracks from a given publisher. A Catalog is used by publishers for advertising their output and for subscribers in consuming that output. The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted. The Catalog provides the names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data.

A special case of the catalog exists which describes other catalogs instead of tracks. A catalog might describe tracks, or catalogs, but never both at the same time.

3.1. Catalog Fields

A catalog is a JSON [JSON] document, comprised of a series of mandatory and optional fields. At a minimum, a catalog MUST provide all mandatory fields and one of either a 'tracks' field or a 'catalogs' field. A producer MAY add additional fields to the ones described in this draft. Custom field names MUST NOT collide with field names described in this draft. To prevent custom field name collisions with future versions, custom field names SHOULD be prefixed using reverse domain name notation e.g "com.example-size". The order of field names within the JSON document is not important. Any track or catalog field declared at the root level is inherited by all tracks or catalogs. Any track or catalog field declared within a track or catalog object overwrites any inherited value.

A parser MUST ignore fields it does not understand.

Table 1 provides an overview of all fields defined by this document.

Table 1
Field Name Definition
Catalog version version Section 3.2
Streaming format streamingFormat Section 3.2.1
Streaming format version streamingFormatVersion Section 3.2.2
Supports delta updates supportsDeltaUpdates Section 3.2.3
Common Track Fields commonTrackFields Section 3.2.4
Tracks tracks Section 3.2.5
Catalogs catalogs Section 3.2.6
Track namespace namespace Section 3.2.9
Track name name Section 3.2.10
Packaging packaging Section 3.2.11
Track label label Section 3.2.12
Render group renderGroup Section 3.2.13
Alternate group altGroup Section 3.2.14
Initialization data initData Section 3.2.15
Initialization track initTrack Section 3.2.16
Selection parameters selectionParams Section 3.2.17
Dependencies depends Section 3.2.18
Temporal ID temporalId Section 3.2.19
Spatial ID spatialId Section 3.2.20
Codec codec Section 3.2.21
Mime type mimeType Section 3.2.22
Framerate framerate Section 3.2.23
Bitrate bitrate Section 3.2.24
Width width Section 3.2.25
Height height Section 3.2.26
Audio sample rate samplerate Section 3.2.27
Channel configuration channelConfig Section 3.2.28
Display width displayWidth Section 3.2.29
Display height displayHeight Section 3.2.30
Language lang Section 3.2.31

Table 2 defines the allowed locations for these fields within the document

Table 2
Location Allowed locations for the field
R The Root of the JSON object
RC The Root or a Catalog object
TFC A Track object, Common Track Fields object or Catalog object.
TF A Track object or a Common Track Fields object
T Track object
S Selection Parameters object.

3.2. Catalog version

Location: R Required: Yes Json Type: String

Versions of this catalog specification are defined using monotonically increasing integers. There is no guarantee that future catalog versions are backwards compatible and field definitions and interpretation may change between versions. A subscriber MUST NOT attempt to parse a catalog version which it does not understand.

This document defines version 1.

3.2.1. Streaming format

Location: RC Required: Yes Json Type: String

A number indicating the streaming format type. Every MoQ Streaming Format normatively referencing this catalog format MUST register itself in the "MoQ Streaming Format Type" table. See Section 5 for additional details.

3.2.2. Streaming format version

Location: RC Required: Yes Json Type: String

A string indicating the version of the streaming format to which this catalog applies. The structure of the version string is defined by the streaming format.

3.2.3. Supports delta updates

Location: RC Required: Optional Json Type: Boolean

A boolean that if true indicates that the publisher MAY issue incremental (delta) updates - see Section 3.3. If false or absent, then the publisher gaurantees that they will NOT issue any incremental updates and that any future updates to the catalog will be independent. The default value is false. This field MUST be present if its value is true, but may be omitted if the value is false.

3.2.4. Common track fields

Location: R Required: Optional Json Type: Object

An object holding a collection of Track Fields (objects with a location of TF or TFC in table 1) which are to be inherited by all tracks. A field defined at the Track object level always supercedes any value inherited from the Common Track Fields object.

3.2.5. Tracks

Location: R Required: Optional Json Type: Array

An array of track objects Section 3.2.8. If the 'tracks' field is present then the 'catalog' field MUST NOT be present.

3.2.6. Catalogs

Location: R Required: Optional Json Type: Array

An array of catalog objects Section 3.2.7. If the 'catalogs' field is present then the 'tracks' field MUST NOT be present. A catalog MUST NOT list itself in the catalog array.

3.2.7. Catalog object

A catalog object is a collection of fields whose location is specified as 'RC' or 'TFC' in Table 2.

3.2.8. Tracks object

A track object is a collection of fields whose location is specified as 'TFC', 'TF' or 'T' in Table 2.

3.2.9. Track namespace

Location: TFC Required: Optional Json Type: String

The name space under which the track name is defined. See section 2.3 of [MoQTransport]. The track namespace is optional. If it is not declared within the Common Track Fields object or within a track, then each track MUST inherit the namespace of the catalog track. A namespace declared in a track object or catalog object overwrites any inherited name space.

3.2.10. Track name

Location: TFC Required: Yes Json Type: String

A string defining the name of the track. See section 2.3 of [MoQTransport]. Within the catalog, track names MUST be unique per namespace.

3.2.11. Packaging

Location: TF Required: Yes Json Type: String

A string defining the type of payload encapsulation. Allowed values are strings as defined in Table 3.

Table 3: Allowed packaging values

Table 3
Name Value Draft
CMAF "cmaf" See [CMAF]
LOC "loc" See RFC XXXX

3.2.12. Track label

Location: TF Required: Optional Json Type: String

A string defining a human-readable label for the track. Examples might be "Overhead camera view" or "Deutscher Kommentar". Note that the [JSON] spec requires UTF-8 support by decoders.

3.2.13. Render group

Location: TF Required: Optional Json Type: Number

An integer specifying a group of tracks which are designed to be rendered together. Tracks with the same group number SHOULD be rendered simultaneously, are usually time-aligned and are designed to accompany one another. A common example would be tying together audio and video tracks.

3.2.14. Alternate group

Location: TF Required: Optional Json Type: Number

An integer specifying a group of tracks which are alternate versions of one-another. Alternate tracks represent the same media content, but differ in their selection properties. Alternate tracks SHOULD have matching framerate Section 3.2.23 and media time sequences. A subscriber typically subscribes to one track from a set of tracks specifying the same alternate group number. A common example would be a set video tracks of the same content offered in alternate bitrates.

3.2.15. Initialization data

Location: TF Required: Optional Json Type: String

A string holding Base64 [BASE64] encoded initialization data for the track.

3.2.16. Initialization track

Location: TF Required: Optional Json Type: String

A string specifying the track name of another track which holds initialization data for the current track. Initialization tracks MUST NOT be added to the tracks array Section 3.2.5. They are referenced only via the initialization track field of the track which they initialize.

3.2.17. Selection parameters

Location: TF Required: Optional Json Type: Object

An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription. If present, the selection parameters object MUST NOT be empty. Any selection parameters declared at the root level are inherited by all tracks. A selection parameters object may exist at both the root and track level. Any declaration of a selection parameter at the track level overrides the inherited root value.

3.2.18. Dependencies

Location: T Required: Optional Json Type: Array

Certain tracks may depend on other tracks for decoding. Dependencies holds an array of track names Section 3.2.10 on which the current track is dependent. Since only the track name is signaled, the namespace of the dependencies is assumed to match that of the track declaring the dependencies.

3.2.19. Temporal ID

Location: T Required: Optional Json Type: Number

A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity.

3.2.20. Spatial ID

Location: T Required: Optional Json Type: Number

A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity.

3.2.21. Codec

Location: S Required: Optional Json Type: String

A string defining the codec used to encode the track. For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of [WEBCODECS-CODEC-REGISTRY]. For CMAF packaged content, the string codec registrations are defined in XXX.

3.2.22. Mimetype

Location: S Required: Optional Json Type: String

A string defining the mime type [MIME] of the track. This parameter is typically supplied with CMAF packaged content.

3.2.23. Framerate

Location: S Required: Optional Json Type: Number

A number defining the framerate of the track, expressed as frames per second.

3.2.24. Bitrate

Location: S Required: Optional Json Type: Number

A number defining the bitrate of track, expressed in bits second.

3.2.25. Width

Location: S Required: Optional Json Type: Number

A number expressing the encoded width of the track content in pixels.

3.2.26. Height

Location: S Required: Optional Json Type: Number

A number expressing the encoded height of the video frames in pixels.

3.2.27. Audio sample rate

Location: S Required: Optional Json Type: Number

The number of audio frame samples per second. This property SHOULD only accompany audio codecs.

3.2.28. Channel configuration

Location: S Required: Optional Json Type: String

A string specifying the audio channel configuration. This property SHOULD only accompany audio codecs. A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas.

3.2.29. Display width

Location: S Required: Optional Json Type: Number

A number expressing the intended display width of the track content in pixels.

3.2.30. Display height

Location: S Required: Optional Json Type: Number

A number expressing the intended display height of the track content in pixels.

3.2.31. Language

Location: S Required: Optional Json Type: String

A string defining the dominant language of the track. The string MUST be one of the standard Tags for Identifying Languages as defined by [LANG].

3.3. Catalog Patch

A catalog update might contain incremental changes. This is a useful property if many tracks may be initially declared but then there are small changes to a subset of tracks. The producer can issue a patch to describe these small changes. Changes are described incrementally, meaning that a patch can itself modify a prior patch. Patching leverages JSON PATCH [JSON-PATCH] to modify the catalog. JSON Patch is a format for expressing a sequence of operations to apply to a target JSON document.

The following rules MUST be followed in processing patches:

  • The target JSON to be modified is the JSON document described by the preceding [MoQTransport] Object in the Catalog track, post any patching that may have been applied to that Object.

  • A Catalog Patch is identified by having a single array at the root level, holding a series of JSON objects, each object representing a single operation to be applied to the target JSON document.

  • Operations are applied sequentially in the order they appear in the array. Each operation in the sequence is applied to the target document; the resulting document becomes the target of the next operation. Evaluation continues until all operations are successfully applied or until an error condition is encountered.

  • Track namespaces and track names may not be changed across patch updates To change either namespace or name, remove the track and then add a new track with matching properties and the new namespace and name.

  • Contents of the track selection properties object may not be varied across updates. To adjust a track selection property, the track must first be removed and then added with the new selection properties and a different name.

3.4. Catalog Examples

The following section provides non-normative JSON examples of various catalogs compliant with this draft.

3.4.1. Time-aligned Audio/Video Tracks with single quality

This example shows catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "commonTrackFields": {
     "namespace": "conference.example.com/conference123/alice",
     "packaging": "loc",
     "renderGroup": 1
  },
  "tracks": [
    {
      "name": "video",
      "selectionParams":{"codec":"av01.0.08M.10.0.110.09","width":1920,
      "height":1080,"framerate":30,"bitrate":1500000}
    },
    {
      "name": "audio",
      "selectionParams":{"codec":"opus","samplerate":48000,"channelConfig":"2",
      "bitrate":32000}
    }
   ]
}

3.4.2. Simulcast video tracks - 3 alternate qualities along with audio

This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track. In this example the namespace is absent, which infers that each track must inherit the namespace of the catalog. Additionally this example shows the presence of the supportsDeltaUpdates flag.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "supportsDeltaUpdates": true,
  "commonTrackFields": {
     "renderGroup": 1,
     "packaging": "loc"
  },
  "tracks":[
    {
      "name": "hd",
      "selectionParams": {"codec":"av01","width":1920,"height":1080,
      "bitrate":5000000,"framerate":30},
      "altGroup":1
    },
    {
      "name": "md",
      "selectionParams": {"codec":"av01","width":720,"height":640,
      "bitrate":3000000,"framerate":30},
      "altGroup":1
    },
    {
      "name": "sd",
      "selectionParams": {"codec":"av01","width":192,"height":144,
      "bitrate":500000,"framerate":30},
      "altGroup":1
    },
    {
      "name": "audio",
      "selectionParams":{"codec":"opus","samplerate":48000,"channelConfig":"2",
      "bitrate":32000}
    }
   ]
}

3.4.3. SVC video tracks with 2 spatial and 2 temporal qualities

This example shows catalog for a media producer capable of sending scalable video codec with 2 spatial and 2 temporal layers with a dependency relation as shown below:

                  +----------+
     +----------->|  S1T1    |
     |            | 1080p30  |
     |            +----------+
     |                  ^
     |                  |
+----------+            |
|  S1TO    |            |
| 1080p15  |            |
+----------+      +-----+----+
      ^           |  SOT1    |
      |           | 480p30   |
      |           +----------+
      |               ^
+----------+          |
|  SOTO     |         |
| 480p15    |---------+
+----------+

The corresponding catalog uses "depends" attribute to express the track relationships.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "supportsDeltaUpdates": true,
  "commonTrackFields": {
     "namespace": "conference.example.com/conference123/alice",
     "renderGroup": 1,
     "packaging": "loc"
  },
  "tracks":[
    {
      "name": "480p15",
      "selectionParams": {"codec":"av01.0.01M.10.0.110.09","width":640,
      "height":480,"bitrate":3000000,"framerate":15}
    },
    {
      "name": "480p30",
      "selectionParams": {"codec":"av01.0.04M.10.0.110.09","width":640,
      "height":480,"bitrate":3000000,"framerate":30},
      "depends": ["480p15"]
    },
    {
      "name": "1080p15",
      "selectionParams": {"codec":"av01.0.05M.10.0.110.09","width":1920,
      "height":1080,"bitrate":3000000,"framerate":15},
      "depends":["480p15"]
    },

    {
      "name": "1080p30",
      "selectionParams": {"codec":"av01.0.08M.10.0.110.09","width":1920,
      "height":1080,"bitrate":5000000,"framerate":30},
      "depends": ["480p30", "1080p15"]
    },
    {
      "name": "audio",
      "selectionParams":{"codec":"opus","samplerate":48000,"channelConfig":"2",
      "bitrate":32000}
    }
   ]
}

3.4.4. Patch update adding a track

This example shows catalog for the media producer adding a slide track to an established video conference.

[
    {
        "op": "add",
        "path": "/tracks/-",
        "value": {
            "name": "slides",
            "selectionParams": {
                "codec": "av01.0.08M.10.0.110.09",
                "width": 1920,
                "height": 1080,
                "framerate": 15,
                "Bitrate": 750000
            },
            "renderGroup": 1
        }
    }
]

3.4.5. Patch update removing a track

This example shows patch catalog update for a media producer removing the track from an established video conference.

[
  { "op": "remove", "path": "/tracks/2"}
]

3.4.6. Patch update removing all tracks and terminating the broadcast

This example shows a patch catalog update for a media producer removing all tracks and terminating the broadcast.

[
  { "op": "remove", "path": "/tracks/2"},
  { "op": "remove", "path": "/tracks/1"},
  { "op": "remove", "path": "/tracks/0"},
]

3.4.7. CMAF Tracks with multiple qualities of audio and video

This example shows catalog for a sports broadcast sending time-aligned audio and video tracks using CMAF packaging. Init segments are delivered as separate tracks.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "supportsDeltaUpdates": true,
  "commonTrackFields": {
     "namespace": "sports.example.com/games/08-08-23/12345",
     "packaging": "cmaf",
     "renderGroup":1
  },
  "tracks": [
    {
      "name": "video_4k",
      "selectionParams":{"codec":"avc1.640033","mimeType":"video/mp4",
      "width":3840,"height":2160,"framerate":30,"bitrate":14931538},
      "initTrack":"init_video_4k",
      "altGroup": 1
    },
    {
      "name": "video_1080",
      "selectionParams":{"codec":"avc1.640028","mimeType":"video/mp4",
      "width":1920,"height":1080,"framerate":30,"bitrate":9914554},
      "initTrack":"init_video_1080",
      "altGroup": 1
    },
    {
      "name": "video_720",
      "selectionParams":{"codec":"avc1.64001f","mimeType":"video/mp4",
      "width":1280,"height":720,"framerate":30,"bitrate":4952892},
      "initTrack":"init_video_720",
      "altGroup": 1
    },
    {
      "name": "audio_aac",
      "selectionParams":{"codec":"mp4a.40.5","mimeType":"audio/mp4",
      "samplerate":48000,"channelConfig":"2","bitrate":67071},
      "initTrack":"init_audio_aac",
      "altGroup": 2
    },
    {
      "name": "audio_ec3",
      "selectionParms":{"codec":"ec-3","mimeType":"audio/mp4",
      "samplerate":48000,"channelConfig":"F801","bitrate":256000},
      "initTrack":"init_audio_ec3",
      "altGroup": 2
    }
   ]
}

3.4.8. Mixed format example - CMAF and LOC packaging in the same catalog

This example shows catalog describing a broadcast with CMAF packaged video and LOC packaged audio.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "commonTrackFields": {
     "namespace": "output.example.com/event/12345",
     "renderGroup":1
  },
  "tracks": [
    {
      "name": "video0",
      "selectionParams":{"codec":"avc1.64001f","mimeType":"video/mp4",
      "width":1280,"height":720,"framerate":30,"bitrate":4952892},
      "initTrack":"init_video_720",
      "packaging":"cmaf"
    },
    {
      "name": "audio",
      "selectionParams":{"codec":"opus","samplerate":48000,"channelConfig":"2",
      "bitrate":32000},
      "packaging": "loc"
    }
   ]
}

3.4.9. CMAF Tracks with inband init segments

This example shows catalog for a sports broadcast sending time-aligned audio and video tracks using CMAF packaging. Init segments are delivered as inband data. The data has been truncated for clarity.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "commonTrackFields": {
     "namespace": "sports.example.com/games/08-08-23/12345",
     "packaging": "cmaf",
     "renderGroup":1
  },
  "tracks": [
    {
      "name": "video_1080",
      "selectionParams":{"codec":"avc1.640028","mimeType":"video/mp4",
      "width":1920,"height":1080,"framerate":30,"bitrate":9914554},
      "initData":"AAAAGG...BAAAx"
    },
    {
      "name": "audio_aac",
      "selectionParams":{"codec":"mp4a.40.5","mimeType":"audio/mp4",
      "samplerate":48000,"channelConfig":"2","bitrate":67071},
      "initData":"AAAAGG...EAADE="
    }
   ]
}

3.4.10. Time-aligned Audio/Video Tracks with custom field values

This example shows catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks along with custom fields in each track description.

{
  "version": 1,
  "streamingFormat": 1,
  "streamingFormatVersion": "0.2",
  "commonTrackFields": {
     "namespace": "conference.example.com/conference123/alice",
     "packaging": "loc",
     "renderGroup": 1
  },
  "tracks": [
    {
      "name": "video",
      "selectionParams":{"codec":"av01.0.08M.10.0.110.09","width":1920,
      "height":1080,"framerate":30,"bitrate":1500000},
      "com.example-billing-code": 3201,
      "com.example-tier": "premium",
      "com.example-debug": "h349835bfkjfg82394d945034jsdfn349fns"
    },
    {
      "name": "audio",
      "selectionParams":{"codec":"opus","samplerate":48000,"channelConfig":"2",
      "bitrate":32000}
    }
   ]
}

3.4.11. A catalog referencing catalogs for two different formats

This example shows the catalog for a media producer that is outputting two streaming formats simultaneously under different namespaces. Note that each track name referenced points at another catalog object and that only the first catalog supports incremental delta updates.

{
  "version": 1,
  "catalogs": [
    {
      "name": "catalog-for-format-one",
      "namespace": "sports.example.com/games/08-08-23/live",
      "streamingFormat":1,
      "streamingFormatVersion": "0.2",
      "supportsDeltaUpdates": true,
    },
    {
      "name": "catalog-for-format-five",
      "namespace": "chat.example.com/games/08-08-23/chat",
      "streamingFormat":5,
      "streamingFormatVersion": "1.6.2"
    }
  ]
}

4. Security Considerations

The catalog contents MAY be encrypted. The mechanism of encryption and the signaling of the keys are left to the Streaming Format referencing this catalog format.

5. IANA Considerations

This section details how the MoQ Streaming Format Type and new fields can be registered for inclusion in a catalog.

5.1. MoQ Streaming Format Type Registry

This document creates a new registry, "MoQ Streaming Format Type". This registry is managed by the IANA according to the RFC Required policy of [RFC5226]. The Type value is 2 octets. The range is 0x0000-0xFFFF. The initial entry in the registry is:

Table 4
Type Name RFC
0x0000 Reserved https://datatracker.ietf.org/doc/
    draft-wilaw-moq-catalogformat/

No RFC is provided for the initial entry as it is reserved. Every MoQ streaming format draft normatively referencing this catalog format MUST register itself a unique type identifier. The type registry can be updated by incrementally expanding by allocating and reserving new type identifiers.

5.2. Common Catalog Field Registry

This document creates a new IANA registry for the Common Catalog fields. The registry is called "MoQ Common Catalog Fields". This registry is managed by the IANA according to the Specification Required policy of [RFC5226]. The initial entries in the registry are:

Descriptive Name: Catalog version
Field Name: version
Required: yes
Location: R
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Streaming format
Field Name: streamingFormat
Required: yes
Location: RC
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Streaming format version
Field Name: streamingFormatVersion
Required: yes
Location: RC
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Tracks
Field Name: stracks
Required: opt
Location: R
JSON Type: Array
Specification: [MoQCatalog]

Descriptive Name: Catalogs
Field Name: catalogs
Required: opt
Location: R
JSON Type: Array
Specification: [MoQCatalog]

Descriptive Name: Track namespace
Field Name: namespace
Required: opt
Location: RTC
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Track name
Field Name: name
Required: yes
Location: TC
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Packaging
Field Name: packaging
Required: yes
Location: RT
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Track label
Field Name: label
Required: opt
Location: RT
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Render group
Field Name: renderGroup
Required: opt
Location: RT
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Alternate group
Field Name: altGroup
Required: opt
Location: RT
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Initialization data
Field Name: initData
Required: opt
Location: RT
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Initialization track
Field Name: initTrack
Required: opt
Location: RT
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Selection parameters
Field Name: selectionParams
Required: opt
Location: RT
JSON Type: Object
Specification: [MoQCatalog]

Descriptive Name: Dependencies
Field Name: depends
Required: opt
Location: T
JSON Type: Array
Specification: [MoQCatalog]

Descriptive Name: Temporal ID
Field Name: temporalId
Required: opt
Location: T
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Spatial ID
Field Name: spatialId
Required: opt
Location: T
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Codec
Field Name: codec
Required: opt
Location: S
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: MIME type
Field Name: mimeType
Required: opt
Location: S
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Framerate
Field Name: framerate
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Bitrate
Field Name: bitrate
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Width
Field Name: width
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Height
Field Name: height
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Audio sample rate
Field Name: samplerate
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Channel configuration
Field Name: channelConfig
Required: opt
Location: S
JSON Type: String
Specification: [MoQCatalog]

Descriptive Name: Display width
Field Name: displayWidth
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Display height
Field Name: displayHeight
Required: opt
Location: S
JSON Type: Number
Specification: [MoQCatalog]

Descriptive Name: Language
Field Name: lang
Required: opt
Location: S
JSON Type: String
Specification: [MoQCatalog]

Any registration for a new Field name MUST provide the following information:

  • Descriptive Name - a descriptive name for the field.

  • Field Name - the JSON field name, as will be used inside the JSON catalog.

  • Required - the string "yes" if the field is required in all catalogs and "opt" if it is not.

  • Location - a string defining the permissible locations for the field within the catalog:

    • 'R' - the field is located in the Root of the JSON object.

    • 'RC' - the field may be located in either the Root or a Catalog object.

    • 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object.

    • 'TC' - the field may be located in either a Track object or a Catalog object.

    • 'RT' - the field may be located in either the Root or a Track object.

    • 'T' - the field is located in a Track object.

    • 'S' - the field is located in the Selection Parameters object.

  • JSON Type - the JSON type of the field value, which must be one of String, Array, Number, Object or Boolean.

  • Specification - a URL to the specification which defines the usage of the field within the catalog, per the Specification Required policy of [RFC5226].

Acknowledgments

Normative References

[BASE64]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
[CMAF]
"Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", .
[JSON]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[JSON-PATCH]
Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, , <https://www.rfc-editor.org/rfc/rfc6902>.
[LANG]
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, , <https://www.rfc-editor.org/rfc/rfc5646>.
[MIME]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/rfc/rfc6838>.
[MoQCatalog]
Nandakumar, S., Law, W., and M. Zanaty, "Common Catalog Format for moq-transport", Work in Progress, Internet-Draft, draft-ietf-moq-catalogformat-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-catalogformat-00>.
[MoQTransport]
Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-05>.
[RFC5226]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, , <https://www.rfc-editor.org/rfc/rfc5226>.
[WEBCODECS-CODEC-REGISTRY]
"WebCodecs Codec Registry", , <https://www.w3.org/TR/webcodecs-codec-registry/>.

Authors' Addresses

Suhas Nandakumar
Cisco
Will Law
Akamai
Mo Zanaty
Cisco