Table 1 lists the fields defined at the root of the catalog JSON object.
| Field | Name | Definition |
|---|---|---|
| MSF version | version | Section 5.1.1 |
| Generated at | generatedAt | Section 5.1.2 |
| Is Complete | isComplete | Section 5.1.3 |
| Tracks | tracks | Section 5.1.4 |
| Publish tracks | publishTracks | Section 5.1.5 |
| Delta update | deltaUpdate | Section 5.1.6 |
| Initialization Data List | initDataList | Section 5.1.7 |
5.1.1. MSF version
Required: Yes JSON Type: String 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.
For usage against IETF Internet-Draft releases, follow the convention of specifying the version as "draft-XX". For example "draft-03" refers to the -03 draft release.
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.2.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.2.1.
5.1.5. Publish tracks
Location: R Required: Optional JSON Type: Array
An array of publish track objects. Publish tracks define tracks to which the subscriber can publish data, such as logs, metrics, or other QoE data. This enables bi-directional communication where the subscriber acts as a publisher for specific tracks. Each publish track object follows the same structure as a regular track object Section 5.2.1 but is used for the reverse direction of data flow.
5.1.6. Delta update
Required: Optional JSON Type: Array Location: Root Catalog
An ordered Array of operation objects that specify changes to apply to the catalog. If this field is present, the catalog represents a delta (or partial) update with a restricted set of fields and special processing rules - see Section 5.3. If this field is absent, the catalog is independent.
Operations are applied sequentially in the order they appear in the array. Each operation object MUST contain an "op" field indicating the operation type, and a "tracks" field containing an Array of track objects Section 5.2.1. The following operation types are defined:
-
"add" - Add new tracks that have not previously been declared. The value of the "tracks" field is an Array of track objects Section 5.2.1.
-
"remove" - Remove tracks that have been previously declared. The value of the "tracks" field is an Array of track objects Section 5.2.1. Each track object MUST include a Track Name Section 5.2.3 field, MAY include a Track Namespace Section 5.2.2 field, and MUST NOT hold any other fields.
-
"clone" - Clone new tracks from previously declared tracks. The value of the "tracks" field is an Array of track objects Section 5.2.1. Each track object MUST include a Parent Name Section 5.2.33 field and MAY include a Parent namespace Section 5.2.34 field. The cloned track inherits all attributes from the parent except the Track Name which MUST be new. Attributes redefined in the track object override inherited values.
5.1.7. Initialization Data List
Required: Optional JSON Type: Array Location: Root Catalog
An array of initialization reference objects. Each initialization reference object has the following fields:
-
id : a string defining a reference to this initialization data which is unique within the scope of the catalog.
-
type: as string defining the type of reference. This version of the specification defines a single allowed type, per the table below
| Type | Data field definition |
|---|---|
| inline | Base64 [BASE64] encoded initialization data |
-
data: a string holding the init payload as defined by the type.
The Initialization Data List, if present, MUST be located after the tracks array in the root of the JSON catalog. The purpose of this is to improve the human readability of the catalog tracks by moving the verbose init data towards the end of the document.