FLICS LIVE INGEST WRITES NATIVELY TO TAMS

Live production has moved to the cloud, but does your live workflows still wait for files to finish before anyone can touch the content?

THE SHORT END OF IT:

FLICS Live Ingest, Hiscale's cloud-native live ingest platform, can now write a live feed directly into a Time Addressable Media Store (TAMS) as it arrives. TAMS is an open API specification from BBC R&D that holds media as timestamped segments in object storage, addressable by flow and time range. Any application with access to the store can read the feed while it is still being captured, so editing, clipping and delivery start before the event ends.

THE PROBLEM: LIVE CONTENT STAYS LOCKED UP UNTIL THE FILE CLOSES

Live content stays locked up until the file closes because the file is the unit every other tool in the chain understands. The stream lands as a growing file in a temporary location, mostly because object storage (like S3) expects finished, complete files—not things that are still being written. You can’t easily add data to an object while it’s in use, and other tools can’t touch that data until the file is finished and closed. This forces an inefficient file-based workflow: wait for the file to close, and only then move it to object storage.

Teams work around it in the usual ways. Someone runs a second low-res recording so the highlights desk has something to cut from. Someone else copies the file to a shared volume for the editor, then copies it again into the MAM. Every copy is storage, egress and minutes you do not have during a live event, and the versions drift apart as soon as more than one team is working. Quality control, logging, packaging and clipping all queue behind the same file, so a pipeline designed to run in parallel ends up running in sequence.

THE SOLUTION: A LIVE FEED THAT IS ADDRESSABLE WHILE IT IS STILL RECORDING

FLICS Live Ingest takes an IP-based live stream, transcodes it on the fly, and writes the output into a TAMS store as segments placed on a flow timeline. Each segment is immutable and identified by a flow ID and a timestamp, so a time range always points at the same media without anyone copying anything.

The useful part is what happens next. Segments become readable the instant they're written, so a cloud-based editor, a packager and a QC tool can all read from the same flow at the same time, well before the recording finishes. Because applications work by reference instead of by copy, a highlight cut becomes a set of time ranges, not a new file that has to be produced and moved before anyone can review it.

TAMS came out of BBC R&D and is being pushed toward wider adoption through the Cloud-Native Agile Production programme. It is an open API specification rather than a product, so the store is yours, sitting on commodity object storage in your own environment. That fits how FLICS already works, running in the cloud, on-premises, or across both. Run the whole thing in the cloud and the chain from ingest through to editing is cloud native end to end, with nothing landing on a local volume before work can start.

HOW TO USE IT: WORKFLOWS THIS OPENS UP

The clearest use is live highlight editing. An editor opens the growing recording in a cloud editing tool such as CuttingRoom, cuts against the live timeline, and publishes to social media while the match or the press conference is still running. The clip comes from the same segments the stream is writing, so there is no proxy path to keep in sync and no waiting for the master.

Asset management is the other immediate one. A MAM or a logging tool can register, tag and browse content within minutes of capture, instead of picking it up as a new file an hour after the event. A single store then serves teams that normally each get their own copy, with broadcast, social, VOD and archive all reading from one flow, which is one of the main arguments BBC R&D makes for the model. Your MAM holds references and editorial metadata instead of duplicate essence, and content moves between storage tiers underneath without breaking anything above it.

It also changes what archiving looks like. Because the flow is already in object storage and addressed by time, the live event is the archive from the moment it starts. FLICS produces whatever deliverable formats you need from the same source afterwards, and long-form exports still get the split-and-stitch treatment without holding up the rest of the queue.

FREQUENTLY ASKED QUESTIONS

What is TAMS in broadcast?

TAMS stands for Time Addressable Media Store. It is an open API specification from BBC R&D that stores media as immutable, timestamped segments in object storage instead of as files. Media is addressed by flow ID and time range, so applications can read any part of a recording, including one still in progress, without copying it

Do I need to run my own TAMS store? 

Yes. FLICS writes into a TAMS store that you operate, whether that is the AWS reference implementation, another vendor's, or your own build against the open specification. Because TAMS is a shared API specification, a workflow you build on FLICS stays portable across compliant implementations.

How is this different from ingesting to a growing file?

A growing file has one writer and awkward rules for readers, so most tools wait for it to close. TAMS segments are immutable and readable as soon as they land, so several applications can read the same flow at once. You address content by time rather than parsing a file that is still changing underneath you.

THE BOTTOM LINE

Native TAMS support in FLICS Live Ingest removes the wait between capture and everything downstream. Instead of one team finishing before the next can start, editing, clipping, QC and packaging all work against the same live timeline at once, with nobody touching a copy. Because TAMS is an open specification built on commodity object storage, you keep that flexibility in your own infrastructure and stay portable to any other compliant implementation. For news, sports and live events, that's the difference between a sequential, file-based chain and parallel work against one shared timeline. 

If you're running live production in the cloud, talk to us about turning on TAMS support in your FLICS workflow.