TAMS is designed to be understandable. There are no proprietary protocols, no black-box components, and no vendor lock-in built into the architecture. This page walks through how a TAMS-based system fits together, from the moment a live feed arrives to the moment a user retrieves a clip in their browser.
The four layers of a TAMS system
A TAMS-based system can be thought of in four layers, each building on the one below it.
Object storage
At the base of a TAMS system is standard object storage — the same kind used throughout cloud computing. Media segments are written to S3-compatible storage as they arrive.
TAMS does not require any particular storage provider. You can use:
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Oracle Object Storage
- On-premises systems like MinIO or Garage
This keeps your infrastructure choices open. The TAMS specification defines how media is written and addressed — not where it lives. You can run the same TAMS architecture on a public cloud, a private cloud, or bare metal in your own facility.
The TAMS server
The TAMS server is the index. It does not store media itself — object storage does that. Instead, it records the relationship between time and storage location.
When a recorder writes a segment of media to object storage, it tells the TAMS server: “The media for feed X between timestamps T1 and T2 is at this location in storage.” The TAMS server maintains that index.
When a player or application wants to retrieve media, it asks the TAMS server: “What is available for feed X between T1 and T2?” The server responds with the locations, and the player fetches the media directly from object storage.
This separation of index and storage is important. It means the TAMS server stays lightweight and fast, while storage can scale independently.
Recorders and players
TAMS recorders handle ingest. They accept incoming media — from SDI, SRT, NDI, transport streams, or IP feeds — and write it into the TAMS store in real time. Media is written as small, contiguous segments rather than one large file. This means recordings are accessible almost immediately, even while the feed is still live.
TAMS players handle retrieval. Given a time range and a source, a player fetches the relevant segments from object storage, assembles them in sequence, and delivers them to the consuming application or user. Playback can be forward, reverse or at variable speed — the timeline-indexed architecture makes this straightforward.
Because recorders and players are separate components, you can scale them independently. A system that ingests twenty feeds simultaneously but only ever retrieves from two or three at a time does not need to over-provision the playback layer.
Applications and interfaces
Everything below this layer is infrastructure. At this layer, you build the tools that users actually interact with.
TAMS does not prescribe what applications look like. What it does is make it practical to build them. Because all media is time-indexed and accessible through a consistent query interface, applications can be built without needing to understand the underlying storage layout.
Examples of what gets built at this layer:
- A browser-based compliance review interface with search and export
- A news logging dashboard with clip creation and metadata tagging
- A multiviewer that streams multiple feeds to an operator’s browser
- A replay tool with variable speed and reverse playback
- An automated highlights or content reuse workflow
A practical example — what happens when a feed is recorded
- A live SDI or IP feed arrives at a TAMS recorder.
- The recorder segments the media into short chunks and writes them to object storage.
- For each chunk, the recorder registers the time range and storage location with the TAMS server.
- The media is immediately available for retrieval — a player can begin reading it within seconds of capture.
- A user opens a browser-based review interface, requests the feed for a specific time window, and the interface queries the TAMS server, fetches the relevant segments, and plays them back.
No transcoding. No file duplication. No manual file management.
What TAMS avoids
A key principle in the TAMS architecture is avoiding unnecessary recompression.
In traditional broadcast workflows, content is frequently transcoded as it moves between systems — from ingest to storage, from storage to editing, from editing to compliance, and so on. Each transcode takes time, costs money, and introduces quality loss.
In a TAMS system, the same stored media can be used by multiple workflows simultaneously, without creating new copies. A compliance recorder and a highlights workflow can both read from the same TAMS store at the same time, using different time ranges.
This also means that adding a new workflow later does not require re-ingesting or re-encoding existing content. You extend the application layer; the storage and index remain unchanged.
TAMS and shared memory for media components
For organisations running TAMS components in a containerised environment — for example, using a platform like Phrame — there is an additional efficiency available.
Media components that run on the same host can share raw media in memory rather than writing it to storage and reading it back. This reduces latency for workflows that need very fast turnaround, such as live monitoring or near-real-time multiviewing, while the longer-term storage and indexing functions continue in parallel.
This shared-memory model is optional and infrastructure-specific. It does not affect the core TAMS specification, but it is worth knowing about if you are evaluating containerised deployment options.
Deployment environments
TAMS-based systems can be deployed in several ways:
Public cloud — all components run in a cloud provider’s infrastructure. Storage costs are based on usage. Suitable for organisations that want minimal on-premises footprint.
Private cloud / on-premises — components run in your own data centre, using on-premises S3-compatible storage. Suitable for organisations with strict data residency or security requirements.
Hybrid — some components on-premises (for low-latency ingest), some in the cloud (for storage and remote access). Common for broadcasters transitioning gradually from traditional infrastructure.
The TAMS architecture is designed to work across all three. The specification does not bake in assumptions about where components run.