TAMS Gateway: a time-addressable media store, one click from running
Live production has spent the last decade moving from dedicated hardware onto commodity infrastructure. The way we store and address media in those workflows has not kept up. Files, growing MP4s, and ad hoc naming conventions still sit at the center of most pipelines. The BBC’s Time-Addressable Media Store specification — TAMS — proposes a cleaner model: treat media as flows of timestamped segments that you address by time, independent of files and independent of the underlying object storage.
A specification is not a running service. To use TAMS you need an implementation, a database, object storage, an authentication story, and somewhere to deploy it all. The TAMS Gateway is an open source implementation of the TAMS API that you can run locally in minutes and deploy to Eyevinn Open Source Cloud as a single unit, no hyperscaler cloud account required.
What TAMS models
The core of TAMS is the separation of three things. Sources are the conceptual entities being captured: a camera, a program feed, a microphone. Flows are specific encoded representations of a source over time. Segments are the timestamped chunks of media that make up a flow.
Because everything is addressed by time rather than by filename, a client can ask for a flow between two timestamps without knowing or caring how the bytes are laid out on disk. Time-addressing is what lets multiple tools collaborate on the same growing recording. A packager and a quality control tool can both read from the same flow as it is being written, each working from the time range they care about.
What the gateway implements
The gateway exposes the parts of the TAMS API surface that matter for real workflows. Sources and flows support create, list, fetch, and delete operations, along with properties and tags for attaching metadata. Segments are written and read by time range, with cursor-based paging for large recordings and a newest-first ordering mode that makes “what is the latest media” a cheap query. Deletion requests reclaim the underlying objects when a flow or a time range is removed, so storage does not silently grow. Webhooks let downstream systems react to changes rather than polling on a schedule.
Metadata lives in a document database. The media segments themselves live in object storage, and the storage target is deliberately flexible: point the gateway at the bundled local object store, at a self-hosted MinIO instance, or at native cloud object storage by leaving the endpoint configuration unset. The same gateway binary runs in all three modes.
Playback and inspection built in
A media store is more useful when you can watch what is in it without wiring up a separate player.
The gateway ships with a built-in HLS output endpoint. Any flow becomes a standard output.m3u8 playlist, generated on the fly from its segments. It handles both live flows and completed recordings, closes playlists correctly when a flow stops producing, and emits civil UTC timestamps so the timeline aligns with the wall clock.
There is also a read-only inspector UI. Open it in a browser to browse sources, flows, and segments, and play a flow back with an embedded HLS player. A time navigator lets you step through a recording; a live mode follows the edge of an ongoing capture. It is the fastest way to confirm that media is actually flowing before integrating anything else.
Authentication
The gateway does not impose one auth model because TAMS deployments vary widely. Set an API token and the gateway enforces it on every request. Leave it unset and the gateway delegates to an upstream access gate, which is exactly how it behaves when deployed behind the Open Source Cloud access gate. The same binary handles both cases, so local development does not require a different configuration file than production.
Deploying as a Solution
The gateway is packaged as an Open Source Cloud Solution: a single deployable unit that provisions the gateway together with its object storage bucket and wires the two together. There is no manual stitching of services and no per-component configuration to trace through. For local development, the same service runs against a local object store so you can iterate before deploying.
Provisioning, credential threading, and infrastructure glue are not the interesting part of evaluating a new storage model. Packaging the gateway as a Solution is an attempt to keep that work as thin as possible so you can get to the interesting part sooner.
Open source and specification-aligned
The gateway is written in TypeScript and ships with a typed schema covering the full TAMS data model. CI runs it against the BBC TAMS specification to verify interoperability, so what you build on it stays portable to other TAMS implementations.
If you work with live media and have been looking for a concrete way to try time-addressable storage in a real pipeline, this is the shortest path from curiosity to running.
Source code and documentation are at github.com/Eyevinn/tams-gateway, the BBC’s TAMS specification is at github.com/bbc/tams, and the platform is at www.osaas.io.
Documentation:
There is more coming. We are currently working on a tams_output block for Strom — the GStreamer engine that powers Open Live — that records pre-encoded video and audio directly into a TAMS Gateway as GOP-aligned segments on a deterministic timeline. When that lands, Open Live will be able to write its program output to a time-addressable store as a side effect of a live production, with no extra tooling. If you want to see where that is heading, the work is in progress at github.com/Eyevinn/strom/pull/647. And if live production is already part of your workflow, Open Live is worth a look.
- TAMS Solution in Open Source Cloud: https://docs.osaas.io/osaas.wiki/Solution%3A-TAMS-storage.html
What is Open Source Cloud?
Managed open-source cloud for developers who want infrastructure, not DevOps
Open source as a service: run 183+ unmodified open-source services. Deploy your own code alongside them as a My App. Spin up Postgres, Valkey, and S3-compatible storage, push your Next.js app, done. No Kubernetes, no cloud config.
