tams-recorder / player

The two ends of TAMS in motion: the recorder captures live frames into segments; the player brings them back — with seek, slow-mo, reverse, and live-edge tracking, straight onto the frame bus.

Language: Rust (workspace: tams-common, tams-codecs, tams-player, tams-recorder) · Codecs: JPEG-XS (libSvtJpegxs) and H.264 (FFmpeg)
No listening port (player optionally takes MQTT control).

How it works

Record — VDI in → encode → batch into segments (by duration for H.264, by frame count for JPEG-XS) → POST /flows/{id}/storage for signed PUT URLs → upload blobs (concurrently) → POST /flows/{id}/segments in order → the server extends the flow’s timerange.

Play — fetch flow metadata → page through segments → fetch + decode → push to a VDI output. Prefetch scales with playback speed; live-tail polling tracks the edge; a 404 on a rolled-off segment re-queries and resumes.

Configuration (environment)

Common: TAMS_URL (req), TAMS_FLOW_ID (req), TAMS_SOURCE_ID (recorder), TAMS_TOKEN or TAMS_USERNAME/TAMS_PASSWORD, VDI_PLUGIN (vdi), VDI_CONFIG, RUST_LOG.

Player: TAMS_START_POSITION (start / end / start+30s / end-10s / <ns>), TAMS_PLAY_SPEED (1.0, -1.0 reverse, 0.0 paused), MQTT_BROKER_URL / MQTT_TOPIC for remote control, plus buffer-tuning vars (PLAYER_*).

Recorder: TAMS_CODEC (jpegxs / h264), TAMS_SEGMENT_DURATION (H.264), FRAMES_PER_SEGMENT (JPEG-XS), flow/source label & description, plus RECORDER_* buffer/concurrency tuning.

Build & notes

./phrame-make.sh <TAG> build-image (or docker buildx bake, or cargo build --release → target/release/tams-{player,recorder}). Needs FFmpeg dev headers and libvdi.so at runtime, libSvtJpegxs.so for JPEG-XS. Deeper guides live in the module’s docs/ (architecture, player/recorder pipelines, docker, troubleshooting). Stack: reqwest, tokio, paho-mqtt, OpenTelemetry.