]> Meta

afrind@meta.com

Google

ianswett@google.com

Web and Internet Transport Media Over QUIC media over quic timestamp This document defines a set of MOQT Properties for carrying per-Object timestamps efficiently. The encoded timestamp is intended for use in MOQT, but can be referenced for application specific purposes. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Media over QUIC Transport (MOQT) delivers Tracks that contain a sequence of Objects. Though the transport layer does not need to know media-oriented or application level timestamps, timing information can help it make optimal scheduling decisions. Additionally, they provide visibility into latency and offer a Property applications can extend. This document defines how a MOQT timestamp is encoded. The design has three features:

• Initial time: A Track declares its start time once, so Objects can delta encode their timestamps from the Initial time.
• Default Inter-Group/Object timing: A Track can define a mapping from Group ID and Object ID to a timestamp, conveying timing with no per-Object bytes at all.
• Compact encoding: Per-Object timestamps are integers, expressing either a delta value from the initial time or a correction to the default value.

Relationship to Other Specifications Several specifications already carry timing for MOQT Objects. The Low Overhead Media Container defines Timestamp and Timescale Properties for media carried in LOC. specifies transport-level use of those same LOC Properties so that Relays can make age-based decisions. The MOQT Streaming Format relates media time, wall-clock time, and Location through catalog fields and timeline tracks, including a template for regular cadences, and numbers Groups by capture time in its log and metrics tracks. stamps each Object with its playout time and send time, which Relays update as they forward, to synchronize playout across subscribers. This document aims to provide a single, general representation that these and other specifications can reference.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms Track, Object, Group, and Subgroup as defined in . A "tick" is one unit of the Track's Timescale (see ). All Property values in this document are encoded as variable-length integers (, introduced in draft-ietf-moq-transport-17) unless otherwise noted. The integers in TIMESTAMP_MAPPING are not re-encoded when it is carried over a draft-16 or earlier session.

Signed Integer Zig-Zag Encoding Signed values, such as the timestamp correction (), are carried in a variable-length integer using a zig-zag mapping that keeps small-magnitude values short: non-negative and negative values are interleaved so that the encoded value grows with the magnitude, in the order 0, -1, 1, -2, 2, ... To encode a signed value v as the variable-length integer u, and to decode it back (both using an arithmetic, sign-extending right shift): > (WIDTH - 1)) ; encode v = (u >> 1) ^ -(u & 1) ; decode ]]> WIDTH is the bit width of the two's-complement representation of v (for example, 64). Values outside the range -2^63 to 2^63-1 cannot be represented.

Property Handling and Encoding The Properties defined in this document are serialized as Key-Value-Pairs . Each Property defined here MUST appear at most once on a given Track or Object, counting both the mutable list and Immutable Properties (), and MUST appear only in its defined scope: OBJECT_TIMESTAMP MUST NOT appear as a Track Property, and the Track Properties (TIMESCALE, CLOCK_ID, TIMESTAMP_ORIGIN, TIMESTAMP_MAPPING) MUST NOT appear as Object Properties. A subscriber that receives a Track or Object that violates these rules treats the track as malformed, as specified in . These Properties are set by the Original Publisher. Relays MUST NOT add, modify, or remove them. A publisher MAY carry them in Immutable Properties (), for example to enable end-to-end authentication of timing. Because the Properties defined here are interdependent, an endpoint that interprets any of them MUST implement all of them.

Track Properties A Track that uses the timestamps defined in this document declares a Timescale () and, optionally, a Clock ID () and Timestamp Origin () that place its timeline on a clock. All Object timestamps in the Track are interpreted against this clock.

Timescale TIMESCALE is a Track Property giving the number of ticks per second used by all timestamps in the Track. Common values are 1000 for millisecond resolution and 1000000 for microsecond resolution, but any positive value MAY be used (for example, a media Track might use its codec sample rate). There is no default Timescale, to avoid silent unit errors such as confusing milliseconds with microseconds. A subscriber that receives a Track with other Properties defined in this document but no TIMESCALE, or a TIMESCALE value of 0, treats the Track as malformed.

Clock ID CLOCK_ID is a Track Property identifying the clock on which the Track's timeline is placed:

• If no CLOCK_ID Property is specified, but other Properties in this extension are, the time is measured from POSIX time (in TIMESCALE ticks since 1970-01-01T00:00:00Z, excluding leap seconds).
• CLOCK_ID values from 0 to 63 are reserved for clocks listed in the "MOQ Clock IDs" registry (). A receiver treats a reserved value it does not recognize as a clock with no known relationship to wall-clock time.
• A CLOCK_ID of 1 identifies International Atomic Time (TAI), a continuous time scale with no leap seconds, measured in TIMESCALE ticks since 1970-01-01T00:00:00 TAI.
• Any value above 63 identifies a clock with no defined relationship to wall-clock time. Tracks that carry the same CLOCK_ID share that clock, so their timestamps can be compared -- for example, the audio and video Tracks of an on-demand asset.

A CLOCK_ID value identifies the same clock wherever it appears, so values chosen independently by different publishers can collide. A publisher SHOULD choose values from a large space (at least 62 bits) in a way that makes accidental collisions negligible without coordination. A value can be random, or derived deterministically -- for example, by hashing a stable identifier for the content -- so that separate encoders, or a publisher that restarts, use the same value for the same clock. A publisher MUST NOT use a reserved value for any clock other than the one defined for it.

Timestamp Origin TIMESTAMP_ORIGIN is a Track Property giving the position, in ticks on the Track's clock (), that corresponds to a timestamp of 0. An Object's time on that clock (in TIMESCALE ticks) is: Because each Track's origin and timestamps are counted in its own ticks, Tracks with different Timescales are compared by converting clock_time to seconds. If TIMESTAMP_ORIGIN is absent, the default value is 0.

Timestamp Mapping TIMESTAMP_MAPPING is a Track Property that defines how to compute an Object's timestamp from its Group ID and Object ID, with no per-Object Property. Drift can be expressed with a property on any Object (). The property value is four variable-length integers: a Base Group ID, a Base Timestamp, a Group Multiplier, and an Object Multiplier. A value that does not parse as exactly four variable-length integers is malformed. An Object's mapped timestamp is a linear function of its Group ID and Object ID: The computation uses signed arithmetic, so it applies to every Group, including Groups before the Base Group. A negative mapped_timestamp is valid only if a correction brings the Object's timestamp to a non-negative value. The publisher chooses the values from the meaning it gives its Group and Object identifiers:

• The Group Multiplier converts a Group ID into the Group's start time. Set it to 1 when Group IDs are themselves timestamps in ticks, so each Group is placed directly by its ID; or to the number of ticks per Group when Group IDs are sequential indices and Groups have a fixed duration.
• The Object Multiplier converts an Object ID into an offset within its Group, giving the per-Object cadence, or 0 when every Object in a Group shares the Group's time.
• The Base Group and Base Timestamp anchor the mapping, so that a publisher whose Group IDs do not start at 0 -- for example, one that begins numbering at a wall-clock value and increments by one -- can still use a fixed Group Multiplier. Both are 0 when Group 0 starts at timestamp 0.

A publisher can thus rely on the mapping for the regular majority of Objects and spend per-Object bytes only where an Object's timestamp differs from the schedule.

Object Timestamp OBJECT_TIMESTAMP is an Object Property that conveys the Object's timestamp, in ticks of the Track's Timescale. How its value is interpreted depends on whether the Track has a Timestamp Mapping ():

• On a Track without a Timestamp Mapping, the value is the Object's timestamp, encoded as an unsigned variable-length integer. An Object that does not carry OBJECT_TIMESTAMP has no timestamp.
• On a Track with a Timestamp Mapping, the value is a signed correction to the Object's mapped timestamp, encoded using the zig-zag mapping in . An Object that does not carry OBJECT_TIMESTAMP takes its mapped timestamp:

A receiver interprets an Object's timestamp using the Track Properties received with the message that associates the Object with its Track, so it always knows which rule applies. The timestamp of an Object is computed only from Track Properties and properties on the Object itself, and not any other Object. This allows for correct computation even when Objects are filtered or arrive out of order. If a subscriber computes an Object's timestamp that is less than 0 or greater than 2^64-1, it treats the Track as malformed.

Locating Objects by Time When a Track has a Timestamp Mapping with a non-zero Group Multiplier, a receiver can estimate the Location of the Object with a given timestamp t without receiving any Object: If the Object Multiplier is 0, only the Group is estimated. For a time c on the Track's clock (), t is c - timestamp_origin. The result is an estimate: it does not indicate whether the Location exists, and Objects that carry a correction might not be close to the estimate.

Publisher Restarts Because Track Properties cannot change, a publisher that restarts and resumes publishing the same Track cannot revise its origin or re-anchor its mapping; it MUST reuse already established Track Properties. A publisher that might restart SHOULD choose Properties that remain valid and compress well across a restart.

Defining Additional Timestamps Some applications might require more than one timestamp per Object. Such applications can use the properties in this document to convey transport relevant timestamps, and define additional timestamps properties as an offset.

IANA Considerations This document registers the following entries in the "MOQ Properties" registry established by , and establishes the "MOQ Clock IDs" registry (). The code points below are provisional values for interoperability testing; final values are to be assigned by IANA. The Object Property uses a short (two-byte) code point because it is sent per Object.

TIMESCALE Property

Type	Name	Scope	Specification
0x2C7A51E0	TIMESCALE	Track	This document,

The value is a variable-length integer giving ticks per second.

CLOCK_ID Property

Type	Name	Scope	Specification
0x3E8D2B70	CLOCK_ID	Track	This document,

The value is a variable-length integer identifying the Track's clock: 1 identifies TAI, other values from 0 to 63 are reserved for clocks listed in the "MOQ Clock IDs" registry (), and values above 63 identify shared clocks with no defined relationship to wall-clock time. A Track without CLOCK_ID uses POSIX time.

TIMESTAMP_ORIGIN Property

Type	Name	Scope	Specification
0x31B49A6E	TIMESTAMP_ORIGIN	Track	This document,

The value is a variable-length integer giving the position, in ticks on the Track's clock, that corresponds to a timestamp of 0.

TIMESTAMP_MAPPING Property

Type	Name	Scope	Specification
0x27F308C5	TIMESTAMP_MAPPING	Track	This document,

The value is four variable-length integers: a Base Group, and a Base Timestamp, Group Multiplier, and Object Multiplier, each in ticks.

OBJECT_TIMESTAMP Property

Type	Name	Scope	Specification
0x2D1A	OBJECT_TIMESTAMP	Object	This document,

The value is a variable-length integer giving the Object's timestamp in ticks or, on a Track with a Timestamp Mapping, a zig-zag encoded correction to the Object's mapped timestamp.

MOQ Clock IDs Registry This document establishes the "MOQ Clock IDs" registry, which lists the reserved CLOCK_ID values from 0 to 63 (). Values above 63 are chosen by publishers and are not registered. New entries are assigned under the Specification Required policy . Each entry has a Value, a Clock name, and a Specification that defines the clock's time scale and epoch. The initial contents of the registry are:

Value	Clock	Specification
0	Unassigned
1	International Atomic Time (TAI)	This document,
2-63	Unassigned

Security Considerations Timestamps are supplied by the publisher and are not authenticated by the transport. An endpoint that acts on timestamps (for buffering, ordering, or expiry) SHOULD treat them as hints and apply its own sanity checks, since a misbehaving publisher can send misleading values. Timestamps and the Timestamp Origin can reveal information about the publisher's clock and the temporal structure of its content. Where this is sensitive, a publisher MAY place its timeline on a shared clock () rather than POSIX time, use a coarser Timescale, or omit these Properties. An end-to-end encrypted payload can carry timing that is hidden from Relays, but when a Timestamp Mapping is in use, Group IDs and Object IDs reveal timing regardless. See for general considerations on logging untrusted Property values.

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cisco Cisco Microsoft This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the MOQT Streaming Format (MSF) specification, which defines a catalog format for publishers to declare and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. Akamai Cisco This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. This document specifies the transport-level use of the TIMESTAMP and TIMESCALE properties registered by [loc], independent of the LOC container itself. A track-level Timescale property establishes the units, and an object-level Timestamp property carries the presentation time of each object. Exposing media time to the transport lets relays make consistent age-based decisions (e.g. dropping stale objects) without parsing the media container, and it remains consistent across hops regardless of buffering or jitter. No new code points are requested: an endpoint implementing this document is on the wire indistinguishable from a LOC endpoint that carries only these two properties. Cisco Cisco This document defines TEMPO (Timing Extension for Media Playout Orchestration), a synchronized playout mechanism for media tracks delivered over the Media over QUIC Transport (MoQT) protocol. The Original Publisher stamps each object with when it should be played out and when it was sent. Relays replace the send-time stamp with their own clock as they forward, giving each subscriber a fresh timing reference from its nearest relay. Subscribers use these timestamps to decide when to render each object, and report their sync state directly to a coordination server (PlaySyncServer) that can tell the media publisher to adjust timing when subscribers fall behind. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

Examples The following examples show how common timing arrangements, including those of the specifications in , are expressed with the Properties in this document.

Fixed Cadence A Track sends 30000/1001 Objects per second in Groups of 60 Objects, with sequential Group IDs starting at 0, and the publisher knows the wall-clock time W (in ticks since the Unix epoch) at which Group 0 starts: Objects on cadence carry no timestamp Property; an Object that deviates from the cadence carries a small correction in OBJECT_TIMESTAMP.

Explicit Timestamps A Track whose Objects each carry a wall-clock timestamp in microseconds, with its origin at 2026-01-01T00:00:00Z: Each Object carries OBJECT_TIMESTAMP, counted in microseconds since the origin. Omitting TIMESTAMP_ORIGIN instead gives microseconds since the Unix epoch, as LOC does when no Timescale is present , at the cost of larger values.

Group IDs as Timestamps A Track whose Group IDs are microseconds since the Unix epoch and whose Objects share their Group's time, such as an MSF log track : Every Object's timestamp is its Group ID, with no per-Object bytes.

Timeline Template An MSF timeline template with a start media time M, start Location (G, 0), Location delta (1, 0), and start wall-clock time W, in which the media time and wall-clock deltas are both D, all in milliseconds, is expressed as: This requires a known wall-clock time with W at least M. For on-demand content, where MSF sets the wall-clock values to 0, the publisher instead uses a shared Clock ID as in . The template describes only Group start times; a publisher that also knows its per-Object cadence sets the Object Multiplier accordingly.

Shared Clock Without Wall-Clock Time The audio and video Tracks of an on-demand asset have no meaningful wall-clock time but need to be aligned. The publisher derives a Clock ID for the asset, for example from a hash of its identifier; both Tracks carry it and start at time 0 on that clock: A receiver aligns an audio Object and a video Object by comparing their timestamps in seconds.

Acknowledgments The authors thank the authors of , , , and , whose timestamp work () this document builds on, and the participants in the MOQ working group discussions that shaped it. Portions of this document were drafted with the assistance of Claude (Claude Code, Anthropic).