TAMS — Recording & Replay

Nothing that comes through Phrame has to be lost. TAMS records any source as time-addressable media, so any moment — a goal, a fault, a highlight — can be pulled back by its exact time range, replayed, or run in reverse.

Why it matters

Live production is unforgiving: the moment you need is already gone. Dedicated replay hardware is expensive, siloed, and limited to a handful of channels.

TAMS makes capture-everything the default. Because media is stored as time-addressable segments, retrieval is a matter of asking for a time range — not shuttling tapes or hunting through files:

Instant replay and review of any recorded source, by time.
Open standard. TAMS implements the BBC/AMWA Time-Addressable Media Store model — an industry specification, not a proprietary silo.
Storage that scales. Media objects live in ordinary object storage (S3 / MinIO); retention is policy-driven, so cost tracks value.
Same path as live. Replay feeds back onto the same frame bus as live production, so recorded and live material are handled identically.

In one line: a DVR for your entire facility, addressable by time, built on open standards and commodity storage.

How it works

You record and replay against the frame bus (see the Platform Overview). Two roles do the work:

Role	What it does
recorder	Reads frames from the bus, encodes them, batches them into segments, and registers each with the TAMS server.
player	Lists a flow’s segments, fetches them, decodes, and plays back onto the bus — including seek and reverse.

Record. The recorder ingests live frames → encodes (e.g. JPEG-XS or H.264) → uploads segment blobs to object storage → registers each segment so the server extends the flow’s known time range.

Play. The player asks for a flow and a time range → fetches the matching segment blobs → decodes → outputs to the bus. Because everything is indexed by time, seeking and reverse playback are just different queries over the same segments.

Retention is automatic: a flow-manager trims segments older than a policy by issuing deletion requests, keeping storage bounded.

Under the hood

TAMS implements the AMWA Time-Addressable Media Store data model:

Concept	Meaning
Source	An abstract input (e.g. “Camera 1”), identified by a UUID and an NMOS format URN.
Flow	One concrete encoding of a source (codec, container, bitrate, resolution). A source can have many flows.
Flow segment	A time-addressable chunk of a flow, described by a `timerange` and pointing at a stored media object.
Media object	The actual blob in S3/MinIO, fetched/stored via signed URLs.
Time range	`seconds:nanoseconds` bounds, e.g. `[100:0_110:0]`, with inclusive/exclusive/unbounded markers.

Components.

Component	Language	Role
tams-server	Rust (Axum)	REST API + metadata store (MySQL) + storage allocation (MinIO/S3). The hub.
tams-recorder / player	Rust	Recorder ingests → encodes → uploads → registers; player fetches → decodes → outputs.
tams-flow-manager	Rust	Retention daemon: trims segments past a policy via deletion requests.
tams-flow-visualiser	Python (FastAPI)	Web UI to browse sources/flows and visualise segment timelines and gaps.

Storage flow. On record, the recorder asks the server for signed PUT URLs, uploads blobs directly to object storage, then registers each segment’s timerange and object reference via the API; the server extends the flow’s overall timerange. On play, the client lists segments for a timerange and fetches blobs via signed GET URLs — the server holds metadata, object storage holds bytes.

Part of the Phrame documentation system — one Markdown source, four audiences, a code-generated house-style diagram.