recording
Clock
- All channels in a recording MUST share one clock. Do not mix time sources, e.g. a camera on host time and a CAN bus on its own counter.
- Timestamps MUST be non-decreasing within each channel. Messages SHOULD be written in
non-decreasing
log_timeorder across the whole file: merge your channels by time before writing. t0_nsMUST be the earliest timestamp in the file.- Timestamps SHOULD be absolute Unix epoch nanoseconds. A relative clock is accepted with a
warning, but a recording on a relative clock cannot be aligned with another recording.
Preflight warns when
t0_nsis below 1018 (before 2001), which usually means a relative clock or microseconds that were never scaled.
Write the same nanosecond time to a message’s
log_time, its publish_time and its own
timestamp field. Signals, keypoints and GPS fixes are timed by their MCAP log_time; the
timestamp inside a nomadic.Signal or nomadic.Skeleton is not read. Keeping all three equal
removes any ambiguity.Task
One instruction for the whole recording goes inrecording.task:
Every present field MUST be a non-empty string. Text is kept as written.
For an instruction that changes during the recording, such as turn-by-turn navigation, use a
navigation_instruction signal instead.
Segments
Annotations of spans of the recording, such as the subtasks of its task, go inrecording.segments, one entry per span:
- Segments MAY overlap and need not cover the whole recording.
- Segments are ground-truth annotations. They are kept with the recording and are never used as input to its analysis.