Keep integer timestamps attached to their rational timebases
Distinguish PTS, DTS, stream timebases, epoch choices, and variable frame intervals before using decoded video as a temporal dataset.
On this page
The question for today
What you’ll understand
- Convert timestamp ticks to seconds using the stated rational unit.
- Distinguish presentation order from decode order and elapsed arrival time.
- Specify handling of missing timestamps, nonzero starts, and variable intervals.
A frame number is an ordinal, while a presentation timestamp locates a decoded image on a media timeline. They coincide through a simple frame-rate formula only under additional assumptions. Containers, codecs, and frames can expose different time units, and compressed video can be decoded in an order different from display order. Preserve the original timestamp and its timebase before normalizing anything. Otherwise a preprocessing pipeline can shift labels or invent uniform timing while still producing visually plausible arrays.
Convert the unit before interpreting the number
A timebase is a rational number of seconds per tick. Multiply an integer timestamp by that rational value to obtain media time, keeping exact arithmetic as long as practical. PyAV v14.2.0 documents time units associated with streams, packets, frames, and containers; FFmpeg 7.1 headers define the relevant packet and frame timestamp fields. Do not assume a container-level microsecond offset and a stream tick count are interchangeable merely because both APIs accept an integer.
Choose a reference origin separately from the unit. Subtracting the first valid presentation timestamp can create a clip-relative timeline, but retain its mapping to the source timeline so annotations and other streams can be aligned. A nonzero or negative start is not automatically corrupt. Missing timestamps need a documented reject, repair, or inference policy with provenance; replacing them silently with frame index divided by nominal FPS converts uncertainty into fabricated timing. Also verify timestamp monotonicity in the presentation sequence rather than packet traversal order.
PTS and DTS answer different ordering questions
PTS describes presentation time, while DTS describes decoding time under the media API's semantics. A bidirectionally predicted picture can be presented between reference pictures even though the later-presented reference must be decoded first. Sorting encoded packets by PTS before feeding a decoder can therefore violate its input requirements. The decoder and demuxer contract governs packet consumption; the resulting frames and their timestamps govern temporal sampling for learning.
Variable frame intervals make a single reported average FPS insufficient for exact clip construction. Even a constant-rate source can have dropped, duplicated, edited, or discontinuous timestamps along a processing path. Measure differences between actual presentation times and preserve discontinuity markers. Presentation duration and elapsed decode time are also different: an offline decoder can process a minute of media quickly, while a live frame may arrive late. A causal system must track availability in addition to media position.
Validate timing with a small timestamp fixture
Store a manifest containing source identity, selected stream, timestamp/timebase pairs, chosen origin, decoding version, and any repair or resampling policy. Include a fixture with nonzero start time and unequal intervals so a frame-index shortcut cannot accidentally pass. Compare selected source timestamps, not only the number of output frames. When joining audio or labels, use their own units and origins explicitly rather than assuming every stream starts at the same tick value.
The modular lab illustrates a limited wrapped-counter ambiguity. Reset, set both modulus m=10 and additive step a=3, predict residues zero, three, six, nine, two, then take four Steps. Reset and set both m=10,a=1 for comparison. The last residue two in the first run corresponds to an unwrapped sum of twelve, showing that a displayed residue lacks an epoch count. This is not a video timestamp implementation and does not assert any particular container wrap rule; it isolates why units and reference information matter.
Work it through
Recover unequal presentation intervals
A fictional decoded stream has timebase 1/90,000 seconds per tick and consecutive frame PTS values 9,000,12,600,20,700. Use the first PTS as the declared relative origin; no timestamp is missing.
Convert source media times: 9000/90000=0.10 s, 12600/90000=0.14 s, and 20700/90000=0.23 s.
Subtract the first timestamp to obtain relative times [0,0.04,0.13] s. Retaining the original 0.10-second origin allows a later annotation join to recover source coordinates.
The frame intervals are 0.04 and 0.09 s. A uniform frame-index rule would erase that difference, so the fixture should compare selected timestamps and not just three returned images.
The correct relative timeline is [0,40,130] ms. The integer ordinals zero, one, and two do not determine these times without the actual timestamp contract.
The living notebook
Explore the model
Interactive lab · modular
Keep the missing epoch separate from the visible residue
Reset → set both m=10,a=3; predict 0,3,6,9,2 and take four Steps. Reset → set both m=10,a=1 for comparison. This toy wrapped counter has no media timebase, PTS/DTS fields, decoder, or claim about a real container's wrap behavior.
- Residue r0
- 0
- Orbit period · m/gcd(m,a)
- 12
- Distinct residues visited
- 1 of 12
Addition modulo m starts at zero: rₙ = na mod m. Playback advances two additions per second. The orbit has period m/gcd(m,a), including period one for a = 0. This is not a cryptographic security test or a primality algorithm. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA temporal identifier needs its unit and reference information before it represents elapsed media time.
Pause & reason
Check your understanding
Your turn
Try it yourself
A stream uses 1/1,000 seconds per tick. Its first valid PTS is 2,500 and a selected frame has PTS 2,780. Calculate source and clip-relative times. Does that establish when the frame became available to a live predictor?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Convert each quantity with the rational timebase, then distinguish a media timestamp from an observed arrival or decode-ready time.
Compare with the solution
The selected frame's source time is 2780/1000=2.78 s. Relative to the declared first-frame origin, it is (2780−2500)/1000=0.28 s. Neither value establishes live availability: transport, buffering, and decode dependencies can delay the image. The predictor needs a separately measured availability timestamp or justified mapping, while the source PTS remains necessary for label alignment.
Keep the idea
Take it with you
- Preserve integer timestamps, rational units, and source-to-relative origin mappings.
- PTS, DTS, frame ordinal, and live availability describe different temporal facts.
- Actual presentation intervals are required when uniform timing is not established.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.