The basic data element of MOQT is an object. An object is an addressable unit whose payload is a sequence of bytes. All objects belong to a group, indicating ordering and potential dependencies (see Section 2.3). An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved. An Object can become unavailable, but its contents MUST NOT change over time.
Every Object within a Group belongs to exactly one Subgroup or Datagram. An Original Publisher MAY use both Subgroups and Datagrams within a Group or Track.
Objects are comprised of two parts: metadata and a payload. The metadata is never encrypted and is always visible to relays (see Section 7). The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers. The Original Publisher is solely responsible for the content of the object payload. This includes the underlying encoding, compression, any end-to-end encryption, or authentication.
2.1.1. Object Fields
A MOQT Object has the following fields:
Track Namespace and Track Name: The track this object belongs to.
Group ID: The identifier of the Object's Group (see Section 2.3) within the Track.
Object ID: The order of the object within the group.
Publisher Priority: An integer indicating the publisher's priority for the Object (Section 5.1).
Delivery Mode: An enumeration indicating whether an Object is sent in a Subgroup or Datagram. The Original Publisher establishes an Object's Delivery Mode by how it first transmits the Object. In a subscription, an Object MUST be sent according to its Delivery Mode.
Subgroup ID: The identifier of the Object's Subgroup (see Section 2.2) within the Group. Objects sent in Datagrams do not have a Subgroup ID.
Object Properties : A sequence of key-value pairs associated with the object. See Section 11.1.2.
Object Payload: A possibly empty sequence of bytes.
2.1.2. Object States
From the perspective of a subscriber or a cache, an Object can be in three possible states:
-
The Object is known to not exist. This state is permanent. All signals that an Object does not exist are authoritative.
-
The Object is known to exist. From this state, it can transition to not existing, but not vice versa.
-
The state of the Object is unknown, either because it has not yet been received, or it has not yet been produced.
A gap in the observed Object IDs does not by itself convey any information about the skipped Objects. Skipped Objects remain in the unknown state until they are received or their non-existence is signalled, for example in a FETCH stream (see Section 11.4.1) or via a Prior Object ID Gap (see Section 10.9).
Since Objects can be delivered out of order, an endpoint can receive an Object after it has already recorded that the Object does not exist (e.g., via a FETCH gap from one source and delayed delivery via a subscription). This is not a protocol error and the Track is not malformed.
Whenever the publisher communicates that certain objects do not exist, this fact is expressed as a contiguous range of non-existent objects and by including Properties indicating the group/object gaps; MOQT implementers should take that into account when selecting appropriate data structures.