Skip to main content Link Menu Expand (external link) Document Search Copy Copied
AWS Solutions Library Samples

Frequently Asked Questions

  1. What is the relationship between TAMS and a MAM or PAM?
  2. What about time based metadata?
  3. What is the latency through a TAMS solution?
  4. Do all my segments have to be the same length?
  5. What format media does TAMS use?
  6. Who hosts the TAMS API?
  7. I’m thinking of including a TAMS API in my product, what should I be aware of?
  8. I have existing files, should I put them into TAMS?
  9. There are multiple flows, how do I know which to use?
  10. The segment endpoint returns multiple URL’s which should I use?

What is the relationship between TAMS and a MAM or PAM?

TAMS is designed to be purely a media storage layer to allow the separation of content and the media elements of which it consists. The store holds just the bare minimum metadata required to be able to describe the content and how to put it together.

The TAMS specification does not include rich metadata for editorial or time based purposes, nor is it expected that a user would interact with the TAMS layer directly. Instead, TAMS is designed to exist as part of a wider ecosystem of components, such as a MAM or PAM system. It is expected that a user would continue to interact with the MAM or PAM layer to search for content and manage the rich metadata.

There are two approaches for the MAM or PAM to integrate with the TAMS API:

  1. The MAM or PAM treats the TAMS layer in the same way it would object storage. It would track the location of content in TAMS and if it needs updating or deleting, then it would call the TAMS API to carry out the actions.

  2. The MAM or PAM may choose to integrate TAMS into their product set directly such that all the capabilities that it includes become part of the wider product set natively.

App Note 0014 provides guidance on how to reference content that is stored within TAMS in other systems, such as a MAM or PAM: https://github.com/bbc/tams/blob/main/docs/appnotes/0014-referencing-tams-content-in-other-systems.md

What about time based metadata?

The TAMS specification is for a media storage layer and has been purposefully kept to be as small as possible. Both editorial and time based metadata should not be stored at the TAMS layer but should instead be retained in other elements of a wider ecosystem, such as a MAM or PAM.

There is a logic in holding both the media and metadata in systems which share a common identity and timing model. The section on Time Based Metadata and TAMS provides more recommendations on this topic.

What is the latency through a TAMS solution?

The latency through a TAMS solution is determined by three core factors:

  • The delay in the encoder process
  • The length of the segments within the TAMS store
  • The buffer within the player

The chunk length is the element which varies and is not defined in the specification, as it depends on the use case and implementation. For example, for a wildlife documentary using the store for AI analysis, 30-second segments could be acceptable. However, for fast turnaround sports, 1 or 2 seconds is more likely.

The critical point to measure is how long it takes to get a segment created, uploaded to the object storage. and registered with the TAMS API. At this point, the segment is available to be ready by any other system with access to the API. In theory, the reading systems can be one chunk behind what is currently being written.

Do all my segments have to be the same length?

The TAMS API does not specify the segment length or that they even need to be a constant length. The flow technical metadata does include a target length for the segments within that flow. However, this is not mandatory and only exists to provide a level of information for systems to calculate buffer sizes.

It is possible within the API to have different segment lengths for the same time range on different flows for a given source. For example, the source audio and video may have 2-second segments for the original ingest. However, the audio may be collected together into longer segments in another format for AI analysis.

It should be noted that if TAMS is being used as part of a live to VOD solution and an HLS compliant output is required, then those flows should follow the HLS best practises for segment alignment to ensure that the adaptive bitrate in the player works correctly.

What format media does TAMS use?

The TAMS API is format agnostic. This means that it is up the implementation to specify the media formats being used. At the flow level, the technical characteristics of the segments is declared and includes fields such as resolution, frame rate, bit rate, and codec wrapper. Since multiple flows exist for a single source, it is possible to store multiple formats for the same content. Examples of this include:

  • High quality for broadcast workflows alongside a proxy version
  • Full ABR ladders for live to VOD workflows
  • Standard converted content existing in different frame rates

We strongly recommended that the segments within a TAMS store are independently decodable, and if codecs are being used where there are Long GOPs present, then these do not span segments. More information on this can be found on App Note 0005: https://github.com/bbc/tams/blob/main/docs/appnotes/0005-indepentent-segments.md

Who hosts the TAMS API?

A typical customer deployment would be expected to have a single TAMS API holding the master copy of the content with a set of tools then accessing the API and working with the content.

There are two main options available to host the TAMS API:

  1. Host the TAMS API as part of another product such as a MAM or PAM system
  2. Host a standalone TAMS API

It is expected that long-term option 1 will become the usual approach. However, in the short term when product adoption is growing, option 2 is more likely. AWS has released the open source implementation of the TAMS API, which can be deployed in this model.

I’m thinking of including a TAMS API in my product, what should I be aware of?

It is expected that over time, the TAMS API will be integrated into commercial products. By adding the TAMS API to a product, it is expected that it will gain the interoperability with all other tools which support reading the TAMS API.

The key consideration when looking to add support for hosting the TAMS API is to think through what happens if a customer wants to use two different solutions–both of which provide API capabilities. With both tools providing API hosting, they will not integrate together, breaking the interoperability.

We recommend that any vendor looking to add TAMS API hosting does this as an optional module within the product set. For customers which who no other TAMS API within their ecosystem. this can be deployed and used. Where a TAMS API already exists, the optional API is not deployed and instead, the product is pointed at the existing API instance.

I have existing files, should I put them into TAMS?

For existing flat files, it is possible to import these into TAMS either by importing as a single segment or by processing into small chunks and then uploading these. It is also possible to mix these approaches so that the original file is held in one flow as a single segment. However, a proxy could be created in a second flow in a chunked format. This would allow the benefits of the store to be used through the proxy version but with the content conformed against the original file. As such, TAMS could act as the asset repository of a simple MAM setup.

Alternatively, if there is a MAM already in place, then it may be easier to store the content alongside the references to the live content in TAMS. The decision on how to handle this will need to be made in context of the workflow and understanding the benefits and impacts of each approach.

There are multiple flows, how do I know which to use?

In most cases, it is the responsibility of the TAMS reader to work out which of the flows it should read for a given source ID. This is likely to be determined by a combination of formats that the reader can cope with. Often, this will be the highest available quality. However, in cases like live to VOD, it may be that the reader should only use flows that have a bitrate lower than 10 Mbps.

In circumstances where it is important that the reader uses specific flows, the flow IDs should be provided in addition to providing the source ID.

App note 14 in the TAMS Specification repo detail the best practices for referencing TAMS content, either in other systems or in passing references between systems:
https://github.com/bbc/tams/blob/main/docs/appnotes/0014-referencing-tams-content-in-other-systems.md

The segment endpoint returns multiple URL’s which should I use?

When retrieving the list of segments, TAMS supports having one or more get URLs for a given segment. This could be required for a number of reasons:

  1. The store is returning both a pre-signed URL and a non pre-signed URL that points directly at the media object.
  2. The store is tracking more than one object store and is returning multiple locations of which it is aware.

The get_urls object support an option text label for each URL. If there is only one URL being returned from the store, this is not important. But in circumstances where the store returns multiple URLs, this should be populated to assist the reader in understanding which to use.

App note 9 in the TAMS Specification repo detail the best practices for storage labels in the TAMS store. Where multiple URLs are to be returned, we recommend to following the defined label convention:
https://github.com/bbc/tams/blob/main/docs/appnotes/0009-storage-label-format.md.