IETF MOQ WG: TImestamp Draft
Steven Riedl posted to the MOQ working group mailing list on October 6, 2026. From an operator running linear channels over MoQ, the two look mostly complementary to me: draft-frindell-moq-timestamp is a representation…
Message Snapshot
- List:
moq@ietf.org - Thread subject: TImestamp Draft
- Message subject: [Moq] Re: TImestamp Draft
- Author: Steven Riedl
- Published: 2026-10-06T18:23:21.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Steven Riedl posted to the MOQ working group mailing list on October 6, 2026. From an operator running linear channels over MoQ, the two look mostly complementary to me: draft-frindell-moq-timestamp is a representation…
Why It Matters
This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.
Message Excerpt
From an operator running linear channels over MoQ, the two look mostly complementary to me: draft-frindell-moq-timestamp is a representation of time on a track, and TEMPO is a playout-synchronization system that needs
Plain-Text Body
From an operator running linear channels over MoQ, the two look mostly complementary to me: draft-frindell-moq-timestamp is a representation of time on a track, and TEMPO is a playout-synchronization system that needs one. Where they overlap (per-object capture time, and mapping Group IDs to time), one encoding would be better, and the timestamp draft's covers cases TEMPO's doesn't:
- Broadcast frame rates. With a timescale of 30000 (or 60000) and 1001 ticks per frame, 29.97 (or 59.94) fps is exact. TEMPO's time-aligned groups count objects per 720 s, and 29.97 fps comes to 21,578.4, so NTSC rates can't be expressed exactly.
- On the wire, where relays can see it. TEMPO carries the rate and start time out of band, in the catalog, and relays don't read catalogs. Switching (SWITCH_FROM soft mode, SSTS) needs equal Group IDs to mean the same instant on every track. Tracks with the same CLOCK_ID, TIMESCALE, TIMESTAMP_ORIGIN and TIMESTAMP_MAPPING map equal Group IDs to the same instant, which is close to the alignment declaration we asked about in moq-transport issue #1354.
- Immutable at relays. The timestamp draft's properties can't be changed by relays, so they can sit under end-to-end authentication. TEMPO's HopTime has each participating relay rewrite a property on every object it forwards, outside any end-to-end integrity.
- Channel time, not capture time. With server-side ad insertion, the timeline that matters is the channel's; an ad creative's capture time means nothing there. A track clock with per-object corrections fits that; TEMPO's CaptureTimestamp assumes live capture. What TEMPO adds is the playout side: a target delay and last-hop delay estimates for synchronized viewing. Those could be defined on top of the timestamp draft (its Section 8 anticipates additional timestamps defined as offsets), rather than as a second timestamp encoding. Neither draft says whether a group starts at a decodable point, which is the other half of what switching needs. I'll bring both to our slot in Seattle.
On Tue, Oct 6, 2026 at 12:21 PM Cullen Fluffy Jennings fluffy@iii.ca wrote: