MOQT Streaming Format

4.3.1. Encryption scheme signaling

The encryption scheme and parameters are signaled in the catalog using the following track-level fields:¶

• encryptionScheme Section 5.3.31 - identifies the encryption mechanism¶

• cipherSuite Section 5.3.32 - specifies the AEAD algorithm¶

• keyId Section 5.3.33 - identifies the key material for decryption¶

• trackBaseKey Section 5.3.34 - the base key material for this track¶

When the encryptionScheme field is present in a track definition, subscribers MUST decrypt the object payload using the specified scheme before processing.¶

4.3.2. Key management

The keyId and trackBaseKey values are obtained from an external key management system and the mechanism for obtaining these values is out of scope for this specification. Examples of key management systems include MLS-based key distribution [E2EE-MLS] or other out-of-band key exchange mechanisms.¶

Depending on the key management mechanism in use, a keyId MAY be scoped to:¶

• A single track¶

• A single MoQ Session¶

• Multiple tracks across one or more MoQ sessions¶

Publishers and subscribers MUST use the same key management system and agree on the keyId scope semantics for interoperable operation.¶

4.3.3. Recommended encryption scheme

The RECOMMENDED encryption scheme for MSF is "moq-secure-objects". Implementations supporting content encryption MUST implement the "moq-secure-objects" scheme as defined in [SecureObjects].¶

When using the "moq-secure-objects" scheme:¶

• The cipherSuite field MUST be present and set to a supported cipher suite value¶

• The keyId field MUST be present to identify the key material¶

• The trackBaseKey field MUST be present to provide the base key material¶

4.3.4. Encrypted object structure

For LOC-packaged tracks with encryption enabled (see [SecureObjects], Section 4):¶

• The immutable header extensions (including Group ID and Object ID) remain in plaintext and are authenticated¶

• The object payload is encrypted and authenticated using the specified cipher¶

• Private header extensions (type 0xA) are encrypted alongside the payload¶

5.1.1. MSF version

Required: Yes JSON Type: Number Location: Root Catalog¶

Specifies the version of MSF referenced by this catalog. 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.¶

5.1.2. Generated at

Required: Optional JSON Type: Number Location: Root Catalog¶

The wallclock time at which this catalog instance was generated, expressed as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT). This field SHOULD NOT be included if the isLive field is false.¶

5.1.3. Is Complete

Required: Optional JSON Type: Boolean Location: Root Catalog¶

A catalog-level indication that the broadcast is complete. This is a commitment that all tracks are complete, no new tracks will be added to the catalog, and no new content will be published on any track. Note that even if all individual tracks have isLive Section 5.3.7 set to FALSE, new tracks could still be added to the catalog until isComplete is set to TRUE. This field MUST NOT be included if it is FALSE. This field MUST NOT be removed from a catalog once it has been added.¶

5.1.4. Tracks

Required: Yes JSON Type: Array Location: Root Catalog¶

An array of track objects Section 5.3.1.¶

5.2.1. Delta update

Required: Optional JSON Type: Boolean Location: Delta Update¶

A Boolean that if true indicates that this catalog object represents a delta (or partial) update. A delta update has a restricted set of fields and special processing rules - see Section 5.4. This value SHOULD NOT be added to a catalog if it is false.¶

5.2.2. Add tracks

Required: Optional JSON Type: Array Location: Delta Update¶

Indicates a delta processing instruction to add new tracks. The value of this field is an Array of track objects Section 5.3.1. This field MUST NOT be present when the deltaUpdate field is absent or false.¶

5.2.3. Remove tracks

Required: Optional JSON Type: Array Location: Delta Update¶

Indicates a delta processing instruction to remove new tracks. The value of this field is an Array of track objects Section 5.3.1. Each track object MUST include a Track Name Section 5.3.3 field, MAY include a Track Namespace Section 5.3.2 field and MUST NOT hold any other fields. This field MUST NOT be present when the deltaUpdate field is absent or false.¶

5.2.4. Clone tracks

Required: Optional JSON Type: Array Location: Delta Update¶

Indicates a delta processing instruction to clone new tracks from previously declared tracks. The value of this field is an Array of track objects Section 5.3.1. Each track object MUST include a Parent Name Section 5.3.29 field. This field MUST NOT be present when the deltaUpdate field is absent or false.¶

5.3.1. Tracks object

A track object is a JSON Object containing a collection of fields whose location is specified in Table 3.¶

5.3.2. Track namespace

Required: Optional JSON Type: String Location: Track Object¶

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 a track, then each track MUST inherit the namespace of the catalog track. A namespace declared in a track object overrides any inherited name space.¶

5.3.3. Track name

Required: Yes JSON Type: String Location: Track Object¶

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

5.3.4. Packaging

Required: Yes JSON Type: String Location: Track Object¶

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

Table 4: Allowed packaging values¶

5.3.5. Event timeline type

Required: Optional JSON Type: String Location: Track Object¶

A String defining the type & structure of the data contained within the data field of the Event timeline track. Types are defined by the application provider and are not centrally registered. Implementers are encouraged to use a unique naming scheme, such as Reverse Domain Name Notation, where domain name components are listed in reverse order (e.g., "com.example.myeventtype"), to avoid naming collisions. This field is required if the Section 5.3.4 value is "eventtimeline". This field MUST NOT be used if the packaging value is not "eventtimeline".¶

5.3.6. Track role

Required: Optional JSON Type: String Location: Track Object¶

A string defining the role of content carried by the track. Specified roles are described in Table 5. These role values are case-sensitive.¶

This role field MAY be used in conjunction with the Mimetype Section 5.3.18 to fully describe the content of the track.¶

Table 5: Reserved track roles¶

Custom roles MAY be used as long as they do not collide with the specified roles.¶

5.3.7. Is Live

Required: Yes JSON Type: Boolean Location: Track Object¶

A track-level indication of whether new Objects will be added to this specific track. True if new Objects will be added to the track. False if no new Objects will be added to the track. A False value is sent under two possible conditions: * the publisher of a previously live track has ended the track. * the track is Video-On-Demand (VOD) and was never live. A True value MUST never follow a False value.¶

5.3.8. Target latency

Required: Optional JSON Type: Number Location: Track Object¶

The target latency in milliseconds. Target latency is defined as the offset in wallclock time between when content was encoded and when it is displayed to the end user. For example, if a frame of video is encoded at 10:08:32.638 UTC and the target latency is 5000, then that frame should be rendered to the end-user at 10:08:37.638 UTC. If isLive is FALSE, this field MUST be ignored. All tracks belonging to the same render group MUST have identical target latencies. All tracks belonging to the same alternate group MUST have identical target latencies. If this field is absent from the track definition, and isLive is TRUE, then the player MAY choose the latency with which it renders the content.¶

5.3.9. Track label

Required: Optional JSON Type: String Location: Track Object¶

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.¶

5.3.10. Render group

Required: Optional JSON Type: Number Location: Track Object¶

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

5.3.11. Alternate group

Required: Optional JSON Type: Number Location: Track Object¶

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 MUST have matching 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.¶

5.3.12. Initialization data

Required: Optional JSON Type: String Location: Track Object¶

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

5.3.13. Dependencies

Required: Optional JSON Type: Array Location: Track Object¶

Certain tracks may depend on other tracks for decoding. Dependencies holds an array of track names Section 5.3.3 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.¶

5.3.14. Template

Location: T Required: Optional JSON Type: Array¶

A media timeline template for tracks with fixed-duration segments. It specifies the relationship between media time, MOQT Location, and wallclock time through starting points and intervals. See Section 7.4 for the complete format specification, field definitions, and computation formulas.¶

Tracks that include a template field SHOULD NOT also have a separate media timeline track, as the template provides equivalent functionality. Different tracks (e.g., audio and video) MAY have independent template values to accommodate different group durations.¶

5.3.15. Temporal ID

Required: Optional JSON Type: Number Location: Track Object¶

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

5.3.16. Spatial ID

Required: Optional JSON Type: Number Location: Track Object¶

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

5.3.17. Codec

Required: Optional JSON Type: String Location: Track Object¶

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].¶

5.3.18. Mimetype

Required: Optional JSON Type: String Location: Track Object¶

A string defining the mime type [MIME] of the track.¶

5.3.19. Framerate

Required: Optional JSON Type: Number Location: Track Object¶

A number defining the framerate of the track, expressed as frames per second. This property SHOULD only accompany video or other frame-based content.¶

5.3.20. Timescale

Required: Optional JSON Type: Number Location: Track Object¶

The number of time units that pass per second.¶

5.3.21. Bitrate

Required: Optional JSON Type: Number Location: Track Object¶

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

5.3.22. Width

Required: Optional JSON Type: Number Location: Track Object¶

A number expressing the encoded width of the video frames in pixels. This property SHOULD only accompany tracks which have a visual representation.¶

5.3.23. Height

Required: Optional JSON Type: Number Location: Track Object¶

A number expressing the encoded height of the video frames in pixels. This property SHOULD only accompany tracks which have a visual representation.¶

5.3.24. Audio sample rate

Required: Optional JSON Type: Number Location: Track Object¶

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

5.3.25. Channel configuration

Required: Optional JSON Type: String Location: Track Object¶

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.¶

5.3.26. Display width

Required: Optional JSON Type: Number Location: Track Object¶

A number expressing the intended display width of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation.¶

5.3.27. Display height

Required: Optional JSON Type: Number Location: Track Object¶

A number expressing the intended display height of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation.¶

5.3.28. Language

Required: Optional JSON Type: String Location: Track Object¶

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].¶

5.3.29. Parent name

Required: Optional JSON Type: String Location: Track Object¶

A string defining the parent track name Section 5.3.3 to be cloned. This field MUST only be included inside a Clone tracks Section 5.2.4 object.¶

5.3.30. Track duration

Required: Optional JSON Type: Number Location: Track Object¶

The duration of the track expressed in integer milliseconds. This field MUST NOT be included if the isLive Section 5.3.7 field value is true.¶

5.3.31. Encryption scheme

Location: T Required: Optional JSON Type: String¶

A string identifying the encryption scheme used to protect the track content. The default and RECOMMENDED value is "moq-secure-objects" as defined in [SecureObjects]. If this field is absent, the track content is unencrypted.¶

Table 5: Registered encryption schemes¶

Custom encryption schemes MAY be used. Custom scheme names SHOULD use Reverse Domain Name Notation to avoid collisions (e.g., "com.example.custom-encryption").¶

5.3.32. Cipher suite

Location: T Required: Optional JSON Type: String¶

A string identifying the AEAD cipher suite used for encryption. This field MUST be present when encryptionScheme is specified. For the "moq-secure-objects" scheme, the following cipher suites are defined:¶

Table 6: Cipher suites for moq-secure-objects¶

Implementations MUST support "aes-128-gcm-sha256". Implementations SHOULD support "aes-128-ctr-hmac-sha256-80" for scenarios requiring smaller authentication tags.¶

5.3.33. Key ID

Location: T Required: Optional JSON Type: String¶

A string identifying the key material used for encryption. This value is transmitted in the Secure Object KID extension header as defined in ([SecureObjects], Section 4.2) of each encrypted object.¶

The keyId and associated trackBaseKey are obtained from an external key management system. The mechanism for obtaining these values is out of scope for this specification. Examples include MLS-based key distribution [E2EE-MLS] or other out-of-band key exchange mechanisms.¶

The scope of a keyId is determined by the key management system in use. A keyId MAY be scoped to a single track, a single MSF session, or multiple tracks and sessions. When multiple tracks share the same Key ID, they MAY share the same base key material, though per-track keys are derived using the track name as defined in ([SecureObjects], Section 5).¶

5.3.34. Track Base Key

Location: T Required: Optional JSON Type: String¶

A base64-encoded [BASE64] string containing the base key material for this track, as defined in ([SecureObjects], Section 5). This field works in conjunction with keyId to provide the cryptographic material needed for decryption. The trackBaseKey is obtained from the same key management system that provides the keyId.¶

When present, this field contains the raw key material that, together with the track name and other parameters defined in ([SecureObjects], Section 5), is used to derive the actual encryption keys. Publishers and subscribers MUST use matching trackBaseKey values for successful decryption.¶

5.5.1. Variable Syntax

Variables are denoted by enclosing the variable name in percent characters (%). Variable names MUST consist of alphanumeric characters, hyphens, and underscores. Variable names are case-sensitive.¶

The percent character (%) MUST NOT appear in catalog field values except as part of a variable reference. Literal percent characters are not permitted.¶

Variable values MUST consist only of alphanumeric characters, hyphens, underscores, and the at sign (@). Special characters including commas, semicolons, quotes, ampersands, and other punctuation MUST NOT appear in variable values. This restriction prevents injection attacks and ensures safe substitution into catalog field values.¶

5.5.2. Variable Resolution

Variables are resolved from the fragment identifier of the URI used to access the catalog. The fragment identifier is the portion following the # character and is processed entirely client-side, making it suitable for per-viewer customization without affecting server-side caching.¶

Query parameters (following the ? character) are reserved for server-side processing and MUST NOT be used for variable substitution.¶

When a subscriber requests a catalog using a URI containing a fragment identifier, the fragment is parsed as key-value pairs (using & as delimiter and = as separator). Each key becomes available as a variable name, and the variable is replaced with the corresponding value.¶

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

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

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "1080p-video",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "video",
      "renderGroup": 1,
      "codec":"av01.0.08M.10.0.110.09",
      "width":1920,
      "height":1080,
      "framerate":30,
      "bitrate":1500000
    },
    {
      "name": "audio",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "audio",
      "renderGroup": 1,
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

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

This example shows a 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.¶

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks":[
    {
      "name": "hd",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 1500,
      "role": "video",
      "codec":"av01",
      "width":1920,
      "height":1080,
      "bitrate":5000000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "md",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 1500,
      "role": "video",
      "codec":"av01",
      "width":720,
      "height":640,
      "bitrate":3000000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "sd",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 1500,
      "role": "video",
      "codec":"av01",
      "width":192,
      "height":144,
      "bitrate":500000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "audio",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 1500,
      "role": "audio",
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

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

This example shows a 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,
  "generatedAt": 1746104606044,
  "tracks":[
    {
      "name": "480p15",
      "namespace": "conference.example.com/conference123/alice",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "codec":"av01.0.01M.10.0.110.09",
      "width":640,
      "height":480,
      "bitrate":3000000,
      "framerate":15
    },
    {
      "name": "480p30",
      "namespace": "conference.example.com/conference123/alice",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "codec":"av01.0.04M.10.0.110.09",
      "width":640,
      "height":480,
      "bitrate":3000000,
      "framerate":30,
      "depends": ["480p15"]
    },
    {
      "name": "1080p15",
      "namespace": "conference.example.com/conference123/alice",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "codec":"av01.0.05M.10.0.110.09",
      "width":1920,
      "height":1080,
      "bitrate":3000000,
      "framerate":15,
      "depends":["480p15"]
    },

    {
      "name": "1080p30",
      "namespace": "conference.example.com/conference123/alice",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "codec":"av01.0.08M.10.0.110.09",
      "width":1920,
      "height":1080,
      "bitrate":5000000,
      "framerate":30,
      "depends": ["480p30", "1080p15"]
    },
    {
      "name": "audio",
      "namespace": "conference.example.com/conference123/alice",
      "renderGroup": 1,
      "packaging": "loc",
      "isLive": true,
      "role": "audio",
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

5.6.4. Delta update - adding two tracks

This example shows the catalog delta update for a media producer adding two tracks to an established video conference. One track is newly declared, the other is cloned from a previous track.¶

{
  "deltaUpdate": true,
  "generatedAt": 1746104606044,
  "addTracks": [
      {
        "name": "slides",
        "isLive": true,
        "role": "video",
        "codec": "av01.0.08M.10.0.110.09",
        "width": 1920,
        "height": 1080,
        "framerate": 15,
        "bitrate": 750000,
        "renderGroup": 1
      }
   ],
   "cloneTracks": [
      {
        "parentName": "video-1080",
        "name": "video-720",
        "width":1280,
        "height":720,
        "bitrate":600000
      }
   ]
}

5.6.5. Delta update removing tracks

This example shows a delta update for a media producer removing two tracks from an established video conference.¶

{
  "deltaUpdate": true,
  "generatedAt": 1746104606044,
  "removeTracks": [{"name": "video"},{"name": "slides"}]
}

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

This example shows a 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,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "1080p-video",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "renderGroup": 1,
      "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",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "role": "audio",
      "renderGroup": 1,
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

5.6.7. Time-aligned VOD Audio/Video Tracks

This example shows a catalog for a media producer offering VOD (video on-demand) non-live content. The content is LOC packaged, and includes time-aligned audio and video tracks.¶

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "namespace": "movies.example.com/assets/boy-meets-girl-season3/episode5",
      "packaging": "loc",
      "isLive": false,
      "trackDuration": 8072340,
      "renderGroup": 1,
      "codec":"av01.0.08M.10.0.110.09",
      "width":1920,
      "height":1080,
      "framerate":30,
      "bitrate":1500000
    },
    {
      "name": "audio",
      "namespace": "movies.example.com/assets/boy-meets-girl-season3/episode5",
      "packaging": "loc",
      "isLive": false,
      "trackDuration": 8072340,
      "renderGroup": 1,
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

5.6.8. Encrypted Audio/Video Tracks

This example shows a catalog for encrypted LOC-packaged audio and video tracks using MoQ Secure Objects with AES-128-GCM.¶

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "1080p-video",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "video",
      "renderGroup": 1,
      "codec": "av01.0.08M.10.0.110.09",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "bitrate": 1500000,
      "encryptionScheme": "moq-secure-objects",
      "cipherSuite": "aes-128-gcm-sha256",
      "keyId": "key-2024-q1-premium",
      "trackBaseKey": "dGhpc2lzYXNhbXBsZWJhc2VrZXk="
    },
    {
      "name": "audio",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "audio",
      "renderGroup": 1,
      "codec": "opus",
      "samplerate": 48000,
      "channelConfig": "2",
      "bitrate": 32000,
      "encryptionScheme": "moq-secure-objects",
      "cipherSuite": "aes-128-gcm-sha256",
      "keyId": "key-2024-q1-premium",
      "trackBaseKey": "dGhpc2lzYXNhbXBsZWJhc2VrZXk="
    }
  ]
}

5.6.9. Media timeline and Event timeline

This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks, along with a Media Timeline which describes the history of those tracks and an Event Timeline providing synchronized data.¶

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "history",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "mediatimeline",
      "mimetype": "application/json",
      "depends": ["1080p-video","audio"]
    },
    {
      "name": "identified-objects",
      "namespace": "another-provider/time-synchronized-data",
      "packaging": "eventtimeline",
      "eventType": "com.ai-extraction/appID/v3",
      "mimetype": "application/json",
      "depends": ["1080p-video"]
    },
    {
      "name": "1080p-video",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "video",
      "renderGroup": 1,
      "codec":"av01.0.08M.10.0.110.09",
      "width":1920,
      "height":1080,
      "framerate":30,
      "bitrate":1500000
    },
    {
      "name": "audio",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "audio",
      "renderGroup": 1,
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

5.6.10. Media timeline template

This example shows a catalog using inline media timeline templates instead of an explicit media timeline track. The Section 5.3.14 attribute on each track defines a regular pattern where each segment is 2002ms long. Clients can compute any entry using the template parameters. Note that different tracks MAY have different template values to accommodate different group durations.¶

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "1080p-video",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "video",
      "renderGroup": 1,
      "template": [0, 2002, [0, 0], [1, 0], 1759924158381, 2002],
      "codec":"av01.0.08M.10.0.110.09",
      "width":1920,
      "height":1080,
      "framerate":30,
      "bitrate":1500000
    },
    {
      "name": "audio",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
      "targetLatency": 2000,
      "role": "audio",
      "renderGroup": 1,
      "template": [0, 2002, [0, 0], [1, 0], 1759924158381, 2002],
      "codec":"opus",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":32000
    }
   ]
}

5.6.11. Terminating a live broadcast

This example shows a catalog for a media producer terminating a previously live broadcast containing a video and an audio track.¶

{
  "version": 1,
  "generatedAt": 1746104606044,
  "isComplete": true,
  "tracks": []
}

5.6.12. Variable Substitution for personalized delivery

This example shows a catalog using variable substitution to enable personalized advertising and reporting while maintaining cacheability. Given a catalog request URI of:¶

moqt://relay.example.com/sports/catalog?a=1#token=1234&id=bob&event=xyz

The fragment parameters (token, id, event) are available for variable substitution. The following catalog template:¶

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "renderGroup": 1
    },
    {
      "name": "cmcdv2-%id%",
      "namespace": "advertising-decisions/live-sports/%event%",
      "packaging": "eventtimeline",
      "eventType": "com.example.iab.vast",
      "c4m": "%token%"
    }
  ]
}

Would be resolved by the subscriber as:¶

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "renderGroup": 1
    },
    {
      "name": "cmcdv2-bob",
      "namespace": "advertising-decisions/live-sports/xyz",
      "packaging": "eventtimeline",
      "eventType": "com.example.iab.vast",
      "c4m": "1234"
    }
  ]
}

7.1.1. Explicit entry format

The explicit format contains an array of records. Each record consists of an array of three required items, whose ordinal position defines their type:¶

• The first item holds the media presentation timestamp, expressed as a JSON Number. This value MUST match the media presentation timestamp, rounded to the nearest millisecond, of the first media sample in the referenced Object¶

• The second item holds the MOQT Location of the entry, defined as a tuple of the MOQT Group ID and MOQT Object ID, and expressed as a JSON Array of Numbers, where the first number is the Group ID and the second number is the Object ID.¶

• The third item holds the wallclock time at which the media was encoded, defined as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT) and expressed as a JSON Number. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.¶

An example media timeline is shown below:¶

[
  [0, [0,0], 1759924158381],
  [2002, [1,0], 1759924160383],
  [4004, [2,0], 1759924162385],
  [6006, [3,0], 1759924164387],
  [8008, [4,0], 1759924166389]
]

7.4.1. Template Format

A media timeline template is expressed as an inline track attribute using the Section 5.3.14 field. The template is a JSON Array containing six mandatory values in the following fixed order:¶

1. startMediaTime - The media presentation timestamp of the first entry, as defined for media timeline entries in Section 7.1.1.¶

2. deltaMediaTime - The constant interval between media presentation timestamps, expressed as a JSON Number in milliseconds.¶

3. startLocation - The MOQT Location of the first entry, as defined for media timeline entries in Section 7.1.1.¶

4. deltaLocation - The constant interval between MOQT Locations, expressed as a JSON Array of two Numbers where the first number is the Group ID delta and the second number is the Object ID delta.¶

5. startWallclock - The wallclock time of the first entry, as defined for media timeline entries in Section 7.1.1. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.¶

6. deltaWallclock - The constant interval between wallclock times, expressed as a JSON Number in milliseconds. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.¶

All six values are mandatory and MUST appear in the specified order.¶

Clients compute entry values using the following formulas, where n is the zero-based entry index:¶

mediaTime[n] = startMediaTime + (n * deltaMediaTime)
location[n] = [startLocation[0] + (n * deltaLocation[0]),
               startLocation[1] + (n * deltaLocation[1])]
wallclock[n] = startWallclock + (n * deltaWallclock)

An example template value is shown below:¶

[0, 2002, [0, 0], [1, 0], 1759924158381, 2002]

This template indicates that the first entry has media time 0ms, location [0,0], and wallclock time 1759924158381. Each subsequent entry increments media time by 2002ms, location by [1,0] (next group, same object), and wallclock by 2002ms.¶

7.4.2. Template Immutability

Unlike the explicit media timeline track, the media timeline template is intended to be immutable once publishing starts. Publishers MUST NOT change the template values for a track after the first Object has been published.¶

8.4.1. Event timeline track with wallclock time indexing

This example shows how sports scores and game information might be defined in a live sports broadcast.¶

[
    {
        "t": 1756885678361,
        "data": {
            "status": "in_progress",
            "period": 1,
            "clock": "12:00",
            "homeScore": 0,
            "awayScore": 0,
            "lastPlay": "Game Start"
        }
    },
    {
        "t": 1756885981542,
        "data": {
            "status": "in_progress",
            "period": 1,
            "clock": "09:25",
            "homeScore": 2,
            "awayScore": 0,
            "lastPlay": "Team A: #23 makes 2-pt jump shot"
        }
    }
]

8.4.2. Event timeline track with MOQT Location indexing

This example shows drone GPS coordinates synched with the start of each Group.¶

[
    {
        "l": [0,0],
        "data": [47.1812,8.4592]
    },
    {
        "l": [1,0],
        "data": [47.1662,8.5155]
    }
]

9.1.1. Reserved fragment parameters

Table 5 defines reserved key names for the parameter portion of the msf-fragment. Keynames are case-sensitive.¶

• wallclock-range - a range defined by start and end wallclock times, each expressed as milliseconds since Unix Epoch and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive.¶

• mediatime-range - a range defined by start and end media times, each expressed as milliseconds and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive.¶

• location-range - a range defined by start and end media MOQT Location separated by a "-" dash. Range definitions are inclusive. MOQT Location is expressed as Group ID and Object ID separated by a "." dot. End Location may be omitted to indicate an open range. End Object ID may be ommited, indicating the whole end group is included in the range. The "." dot and "-" dash separators MUST be omitted when the second value is ommited.¶

• c4m - a base64 encoded token, as defined by [C4M].¶

If multiple ranges are specified within the same URL, the client shall process the union of those ranges.¶

Example fragment parameters:¶

• wallclock-range=1761759637565-1761759836189¶

• wallclock-range=1761751753894¶

• mediatime-range=0-13421¶

• mediatime-range=982¶

• location-range=34.0-2145.16¶

• location-range=16.24 //open range starting at Group ID 16 Object ID 24¶

• location-range=16-24 // range from Group ID 16 through to and including all Objects in Group ID 24¶

• c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5u ZWlhdGVwQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM¶

9.1.2. MSF Namespace-Name String Encoding

To represent MoQ Tuples (which are sequences of byte strings) within the URL fragment, MSF uses a specific encoding convention, which is normatively defined by MOQT [MoQTransport] and repeated here for convenience:¶

• Hierarchy: Each element of the Namespace tuple is rendered in order, separated by a single hyphen (-).¶

• Delimiter: The Track Name is appended to the end, separated from the namespace by a double hyphen (--).¶

• Character Escaping:¶

  • Unreserved characters (a-z, A-Z, 0-9, _) are represented literally.¶

  • All other byte values (including hyphens and periods used as data) MUST be¶

  • percent-encoded using a period (.) followed by two lowercase hexadecimal digits (e.g., a literal hyphen in a name becomes .2d).¶

Note: This encoding ensures that the structural delimiters (- and --) remain unambiguous.¶

9.1.3. Example MSF URLs

• URl with a required Webtransport connection pointing at a catalog track: moqt+wt://example.com/server/config?a=1&b=2#customer-livestream-123--catalog¶

  • Session: https://example.com/server/config?a=1&b=2¶

  • Namespace: ('customer', 'livestream', '123')¶

  • Track Name: 'catalog'¶

• URL with a required raw QUIC connection pointing at a catalog: moqt+q://example.com/relay-app/relayID#customerID-broadcastID--catalog¶

• URL pointing at a non-catalog track (either Webtransport or native QUIC may be used): moqt://example.com/relay-app/relayID#customerID-broadcastID--video¶

• URL pointing at a subclip: moqt://example.com/relay-app/relayID#customerID-broadcastID--catalog&location-range=34-64¶

• URL pointing at a catalog and supplying a token for the client: moqt://example.com/relay-app/relayID#customerID-broadcastID-- catalog&c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZl eWV2aW5uZWlhdGVwQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xN zMwNDM¶

• URL pointing at a catalog and supplying a token for the client along with a separate token for the server: moqt://example.com/relay-app/relayID?token=HTRCII74GHFT@JHBCV SW56HKKneH2Dbyq6NHBI2#customerID-broadcastID--catalog&c4m=gqh kYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGV wQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM¶