Fetch Streams — MoQT draft-21 §11.4.

11.4.1. Fetch Header

When a stream begins with FETCH_HEADER, all objects on the stream belong to the track requested in the message identified by Request ID.

FETCH_HEADER {
  Type (vi64) = 0x5,
  Request ID (vi64),
}

Figure 27: MOQT FETCH_HEADER

Each Object sent on a FETCH stream after the FETCH_HEADER has the following format:

{
  Serialization Flags (vi64),
  [Group ID Delta (vi64),]
  [Subgroup ID (vi64),]
  [Object ID Delta (vi64),]
  [Publisher Priority (8),]
  [Properties (..),]
  Object Payload Length (vi64),
  [Object Payload (..),]
}

Figure 28: MOQT Fetch Object Fields

The Serialization Flags field defines the serialization of the Object. It is a variable-length integer. When less than 128, the bits represent flags described below. The following additional values are defined:

Table 7
Value	Meaning
0x8C	End of Non-Existent Range
0x10C	End of Unknown Range
0x20C	End of Timed-Out Range

Any other value is a PROTOCOL_VIOLATION.

11.4.1.1. Flags

The two least significant bits (LSBs) of the Serialization Flags form a two-bit field that defines the encoding of the Subgroup. To extract this value, the Subscriber performs a bitwise AND operation with the mask 0x03.

Table 8
Bitmask Result (Serialization Flags & 0x03)	Meaning
0x00	Subgroup ID is zero
0x01	Subgroup ID is the prior Object's Subgroup ID
0x02	Subgroup ID is the prior Object's Subgroup ID plus one
0x03	The Subgroup ID field is present

The following table defines additional flags within the Serialization Flags field. Each flag is an independent boolean value, where a set bit (1) indicates the corresponding condition is true.

Table 9
Bitmask	Condition if set	Condition if not set (0)
0x04	Object ID Delta is present	Object ID is the prior Object's ID plus one
0x08	Group ID Delta is present	Group ID is the prior Object's Group ID
0x10	Priority field is present	Priority is the prior Object's Priority
0x20	Properties field is present	Properties field is not present
0x40	Datagram: ignore the two least significant bits	Decode the Subgroup ID as indicated by the two least significant bits

The first Object MUST include a Group ID Delta and Object ID Delta, and these values are the absolute Group ID and Object ID. If the first Object in the FETCH response uses a flag that references fields in the prior Object, the Subscriber MUST close the session with a PROTOCOL_VIOLATION.

If the Group ID Delta field is present on an Object other than the first, the Group ID is computed from the Group ID Delta and the prior Object's Group ID. If the Group Order is Ascending, the Group ID is the prior Object's Group ID plus the Group ID Delta + 1. If the Group Order is Descending, the Group ID is the prior Object's Group ID minus the (Group ID Delta + 1). If the computed Group ID would be less than 0 or greater than 2^64-1, the Subscriber MUST close the Session with error 'PROTOCOL_VIOLATION'.

When the Group ID Delta field is present, the Object ID is the value of Object ID Delta if present. When the Group ID Delta field is not present, the Object ID is the prior Object's ID plus the Object ID Delta if present. If Object ID Delta is not present, the Object ID is the prior Object's ID plus one, regardless of which group it belongs to. If the computed Object ID would be greater than 2^64-1, the Subscriber MUST close the Session with error 'PROTOCOL_VIOLATION'.

The Object Properties structure is defined in Section 11.1.3.

When encoding an Object with a Forwarding Preference of "Datagram" (see Section 11.1.3), the object has no Subgroup ID. The publisher MUST SET bit 0x40 to '1'. When 0x40 is set, it SHOULD set the two least significant bits to zero and the subscriber MUST ignore the bits.

11.4.1.2. End of Range

When Serialization Flags indicates an End of Range (e.g. values 0x8C, 0x10C, or 0x20C), the Group ID and Object ID fields are present. Subgroup ID, Priority and Properties are not present. All Objects with Locations between the last serialized Object, if any, and this Location, inclusive, either do not exist (when Serialization Flags is 0x8C), are unknown (0x10C), or timed out (0x20C). A publisher SHOULD NOT use End of Non-Existent Range in a FETCH response except to split a range of Objects that will not be serialized into those that are known not to exist and those with unknown or timed out status.

When an Object follows an End of Range indicator and uses flags that reference the "prior Object", the prior Object fields are determined as follows:

Prior Group ID and prior Object ID: The values from the End of Range indicator.
Prior Subgroup ID: The Subgroup ID from the last actual Object before the End of Range indicator. If there was no prior Object, using a flag that references the prior Subgroup ID is a PROTOCOL_VIOLATION.
Prior Priority: The Priority from the last actual Object before the End of Range indicator. If there was no prior Object, using a flag that references the prior Priority is a PROTOCOL_VIOLATION.