An Object contains a range of contiguous bytes from the specified track, as well as associated metadata required to deliver, cache, and forward it. Objects are sent by publishers.
9.2.1. Canonical Object Properties
A canonical MoQ Object has the following information:
-
Track Namespace and Track Name: The track this object belongs to.
-
Group ID: The object is a member of the indicated group ID Section 2.3 within the track.
-
Object ID: The order of the object within the group.
-
Publisher Priority: An 8 bit integer indicating the publisher's priority for the Object Section 6.
-
Object Forwarding Preference: An enumeration indicating how a publisher sends an object. The preferences are Subgroup and Datagram. When in response to a SUBSCRIBE, an Object MUST be sent according to its
Object Forwarding Preference, described below. -
Subgroup ID: The object is a member of the indicated subgroup ID (Section 2.2) within the group. This field is omitted if the Object Forwarding Preference is Datagram.
-
Object Status: As enumeration used to indicate missing objects or mark the end of a group or track. See Section 9.2.1.1 below.
-
Object Extension Length: The total length of the Object Extension Headers block, in bytes.
-
Object Extensions : A sequence of Object Extension Headers. See Section 9.2.1.2 below.
-
Object Payload: An opaque payload intended for an End Subscriber and SHOULD NOT be processed by a relay. Only present when 'Object Status' is Normal (0x0).
9.2.1.1. Object Status
The Object Status informs subscribers what objects will not be received because they were never produced, are no longer available, or because they are beyond the end of a group or track.
Status can have following values:
-
0x0 := Normal object. This status is implicit for any non-zero length object. Zero-length objects explicitly encode the Normal status.
-
0x1 := Indicates Object does not exist. Indicates that this object does not exist at any publisher and it will not be published in the future. This SHOULD be cached.
-
0x3 := Indicates end of Group. ObjectId is one greater that the largest object produced in the group identified by the GroupID. This is sent right after the last object in the group. If the ObjectID is 0, it indicates there are no Objects in this Group. This SHOULD be cached. A publisher MAY use an end of Group object to signal the end of all open Subgroups in a Group. A non-zero-length Object can be the End of Group, as signaled in the DATAGRAM or SUBGROUP_HEADER Type field (see Section 9.3.1 and Section 9.4.2).
-
0x4 := Indicates end of Track. GroupID is either the largest group produced in this track and the ObjectID is one greater than the largest object produced in that group, or GroupID is one greater than the largest group produced in this track and the ObjectID is zero. This status also indicates the last group has ended. An object with this status that has a Group ID less than any other GroupID, or an ObjectID less than or equal to the largest in the specified group, is a protocol error, and the receiver MUST terminate the session. This SHOULD be cached.
Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (Section 3.4). Any object with a status code other than zero MUST have an empty payload.
9.2.1.2. Object Extension Header
Any Object may have extension headers except those with Object Status 'Object Does Not Exist'. If an endpoint receives a non-existent Object containing extension headers it MUST close the session with a Protocol Violation.
Object Extension Headers are visible to relays and allow the transmission of future metadata relevant to MOQT Object distribution. Any Object metadata never accessed by the transport or relays SHOULD be serialized as part of the Object payload and not as an extension header.
Extension Headers are defined in external specifications and registered in an IANA table Section 12. These specifications define the type and value of the header, along with any rules concerning processing, modification, caching and forwarding. A relay which is coded to implement these rules is said to "support" the extension.
If unsupported by the relay, Extension Headers MUST NOT be modified, MUST be cached as part of the Object and MUST be forwarded by relays.
If supported by the relay and subject to the processing rules specified in the definition of the extension, Extension Headers MAY be modified, added, removed, and/or cached by relays.
Object Extension Headers are serialized as Key-Value-Pairs (see Figure 2).
Header types are registered in the IANA table 'MOQ Extension Headers'. See Section 12.