TAMS is an open specification. The full technical detail is publicly available, the repository is on GitHub, and anyone can build a conformant implementation without a commercial agreement or licence fee.

This page is the starting point for developers, engineers and architects who want to build on TAMS or understand it at a technical level.

The specification

The TAMS specification defines:

• How media segments are written to and addressed in object storage
• The data model for the time-indexed registry (the TAMS server)
• The API that recorders use to register media
• The API that players and applications use to query and retrieve media
• How sources, flows and segments are identified and related

The specification is maintained on GitHub. It is the authoritative reference for anyone building a TAMS-compatible component.

Primary repository: https://github.com/bbc/tams

Key concepts

A working knowledge of TAMS requires familiarity with three core concepts.

Sources and flows A source is a logical origin of media — for example, a particular camera or broadcast feed. A flow is a specific representation of that source — for example, the H.264 encoded version at a particular bitrate. One source can have multiple flows. This separation makes it straightforward to record multiple qualities or formats from the same input without ambiguity.

Segments Media in a TAMS store is not held as monolithic files. It is divided into segments — short contiguous chunks that are written to object storage as they arrive. Each segment is registered with the TAMS server with its time range and storage location. Players reconstruct content by fetching the relevant segments in sequence.

The time range query The fundamental operation in TAMS is: “give me the segments for source X, flow Y, between timestamps T1 and T2.” This query is answered by the TAMS server, which returns the storage locations of the relevant segments. The player then fetches them directly from object storage.

Getting started

For developers new to TAMS, the recommended starting point is:

1. Read the specification on GitHub — in particular the README and the API documentation
2. Review the data model — understand sources, flows and segments before writing any code
3. Run the reference implementation — the repository includes reference components that demonstrate a working TAMS system
4. Join the community — questions, discussion and contributions are welcomed

GitHub repository: https://github.com/bbc/tams

What you can build

The TAMS specification is deliberately minimal at its core. It defines the storage model and the query interface — not the applications built on top of them. This gives implementors significant freedom.

Things developers have built or are building on TAMS:

• Live ingest recorders (SDI, SRT, NDI, transport stream)
• Browser-based review and compliance interfaces
• News logging tools with metadata tagging and export
• Multiviewers and monitoring displays
• Replay and variable-speed playback tools
• Automated workflows for highlights, transcription and content reuse
• Cloud-native media platforms (see Phrame on the Implementations page)

If your use case involves capturing, indexing or retrieving time-based media, TAMS is likely a relevant foundation.

Implementation considerations

Storage compatibility TAMS requires S3-compatible object storage. This is a deliberate choice — S3-compatible storage is available from a wide range of commercial and open-source providers, which avoids lock-in. Your implementation should work with any conformant S3 provider.

Segment size Segment duration is not mandated by the specification, but practical implementations typically use segments of one to a few seconds. Shorter segments reduce retrieval latency; longer segments reduce the number of objects in storage. The right balance depends on your use case.

Latency Because media is written to object storage in real time and the TAMS server index is updated continuously, retrieval latency is primarily a function of segment size plus storage access time. For most use cases, this is acceptable. For very low-latency monitoring (sub-second), a shared-memory approach at the component level — as implemented in Phrame, for example — can supplement the TAMS store.

Authentication and access control The TAMS specification does not mandate a specific authentication model. Implementations should apply appropriate access control at the TAMS server API level and at the object storage level, following the security practices of whichever infrastructure platform is in use.

Contributing to TAMS

TAMS is an open project. Contributions are welcomed in several forms:

• Bug reports and clarification requests on the specification
• Pull requests for documentation improvements
• Implementations and tools that you are willing to share
• Interoperability testing with other TAMS implementations
• Discussion of new use cases or specification extensions

The GitHub repository is the right place to start. For broader community discussion, see the About page.