[Moq] Re: TImestamp Draft

[Steven Riedl <[e-mail]>]

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:
1. 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.
2. 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.
3. 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.
4. 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 <[e-mail]>
wrote:

>
> Any comments on pro / cons of this relative to
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-nandakumar-moq-tempo/__;!!CxwJSw!KiTNKt7NFTEosqaIWKdAHtqYEgDgss0iOLmrUguiuV1S_YDlivlAoxFbgX7kWesTH2_CYvzheW8hp13OTQ$
>
>
>
> > On Oct 5, 2026, at 10:30 AM, Alan Frindell <afrind=
> [e-mail]> wrote:
> >
> > Hi MoQ, Ian and I collaborated on an extension draft with a generic set
> of timestamp related Track and Object properties (see also MOQT issue #475).
> >
> > The draft acknowledges prior art here, in LOC, MSF and in Luke's
> Timestamp draft - the goal is to factor out the properties that can be
> referenced and/or extended in those places, and offer some compression
> techniques.  At present, it only defines properties, not any relay behavior
> for them.
> >
> > The draft defines 4 Track properties
> >
> > TIMESCALE - required, how many ticks make one second
> > CLOCK_ID - optional, identifies a common time source
> > TIMESTAMP_ORIGIN - optional base timestamp that others are delta encoded
> from
> > TIMESTAMP_MAPPING - optional parameters to a linear function that
> determines an object's timestamp from group and object ID
> >
> > It also defines one Object Property
> >
> > OBJECT_TIMESTAMP - optional.  With TIMESTAMP_MAPPING, a +/- adjustment
> to the mapped value.  Without TIMESTAMP_MAPPING, a delta from
> TIMESTAMP_ORGIIN.
> >
> > Feedback appreciated here, or in the github repo as issues or PRs.
> >
> > Thanks
> >
> > -Alan and Ian
> > _______________________________________________
> > Moq mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>