Name: Is It Primetime for TAMS? How this open-source, software-defined technology is breaking down broadcast barriers
Uploaded: 2026-02-12T17:30:23.268Z
Duration: 1 h 8 s
Description: Is It Primetime for TAMS? How this open-source, software-defined technology is breaking down broadcast barriers

Transcript for "Is It Primetime for TAMS? How this open-source, software-defined technology is breaking down broadcast barriers": Hello. My name is Jenny Priestley. I'm TBB Europe's content director, and I'm hosting today's webinar. Time addressable media store is a software and cloud native solution which could revolutionize I can't even speak today. Revolutionize content storage and creation within the media industry. Today, we're going to be exploring what TAMs, as it's known, could do for broadcasters and production companies, What makes it so special and how it will work with both video and audio. But first, a bit of housekeeping. There is a chat tab on screen, should you need to reach out to the TV Big Europe team if you have any technical issues during the session. But a browser refresh should get rid of the usual tech gremlins. And I can see that some of you are already saying hello before we even get going. Welcome everyone. I also want to point out that we have subtitles available on the platform. Just click on the CC button to add and you can select from a variety of languages. And you should be able to see some links for downloadable material which you can use. Just don't read those documents just yet. Just do stay with us for the next hour. And there's a Q and A tab if you want to ask any of our panel questions. I always encourage you to do so. If we don't manage to get to your question today, we will try and follow-up after the webinar. But please go ahead and ask those questions throughout our webinar today. Right, we're actually gonna begin today with an introduction to TAMs from Kieran Ennis, engineer at TechX. Kieran, over to you. Hello, everyone. My name is Kirron Eis. I'm an engineer at TechX, and I've been working alongside our development team in the early adoption of TAMs in our product TX Darwin. I've been a part of this journey over the last year or so, and I'm very excited to show you what TAMs is and how it can be used. So TechX, we are a broadcast technology company, and we work on a global scale with some of the biggest entertainment and sports brands across the world. We specialize in transport and transform of content that can be in the cloud or in hybrid environments. So it made a lot of sense for us to incorporate TAMs into some of those workflows. So, yeah. I think it's important to start off to tell you what the state of play is in today's world. So it's important to know that a lot of broadcasters are recording everything all the time, and that's for compliance and archives. And it's causing a lot of duplicate storage costs, And sometimes, that content isn't on demand and easily accessible. So that's where TAMs comes into play. TAMs stands for Time Addressable Media Store, and it's open source, designed and created by the BBC. Audio and video and metadata are all time indexed in segments or fragments, and it can be code agnostic up to you completely. And it's for live editing and manipulation of that as well. And you're able to pull out precise moments within that content that you want to use. It's perfect for broadcast and live events and it's not just for archives and MAMS really. So yeah, this is how a environment could look. You have a TAMs API that sits on top of your content lake, which hosts all your fragments. And they the TAMs API speaks everything within this workflow and can do the authentication. And your live ingests and your file ingests are chopped up into small fragments, sent into your content lake, and then your web based editors or your craft editors able to pull them out. And your live playback and file exporter is also able to pull out those fragments within that. So this workflow that I was just showing you was developed into the CNAP demo that was shown in IBC twenty twenty four. And since then, that workflow has evolved into this one here, which was a, broadcast tech innovations award winning design. And we were able to luckily take home an award for this. And it exists over three different AWS regions, as you can see, and three different TAM stores that are able to synchronize and replicate across all of them. So, yeah, it really showcases what sort of environments that you'd see, TAMs live in. So yeah. So in terms of the use cases for TAMs, it can be in any sort of production environment, really. And it can be in live sport, live news, live events, as you can see there. And really in those environments, enables various different use cases from enhanced replays, highlights, and timestamps viewer feedback and engagements. So overall, TAMs makes contents more interactive, searchable, and viewer controlled. So yeah. Also, I'd like to call out that we've got a TAMs con next month. Scan that QR code there if you'd like to sign up for that. And the second link there is if you'd like to find out more information about TAMs and our product TX Darwin. Yeah. Thank you everyone. I'll hand back to Jenny now. Thanks, Kieran. Now because we might like to make these things as interactive as possible, we are going to ask you, the audience, to share your thoughts with us. And we have a poll question for you, which my able assistant will be adding up right now putting on the screen right now. We want to know what your potential use case is for TAMs. Is it dynamic advertising and product placement, fast turnaround workflows, timestamps viewer feedback and engagement, on demand playback with enhanced searchability, enhanced replay and social media highlights or other. And we will come back. We'll leave that on screen for a few moments, but we'll be back to look at the results of that very shortly. Right. I think it's time we introduce the rest of our expert panel. Please welcome, and I'm going to do this and you'll see them pop up as we do it, Kevin Morris, Product Manager at the BBC Rebecca Light, Group Head of Content Management and Quality Control, Content Technology and Innovation at Sky Dave Mitchinson, solutions director at TechX. AWS senior solutions architect, John Biltcliffe. And James Elliott, managing director, Elliott Media. Welcome everyone. Hello? Thank you. Hi. Hello? Hi. Let's get into this. First of all, I want to know why it's important that TAMIS is open source. John, can you give us an answer to that? Yes. So TEMS is all about sort of open and interoperable workflows rather than being tied to a particular vendor or particular formats, the TAM's API is open source means it's open for anybody to go and build tools, adopt without licensing their SDKs, and really about trying to give ultimately customers and users the choice of the tools they want and make it as easy as it is possible for them to adopt it. So if a tool talks to TAMs, they should be able to plug into a TAM store very quickly and easily and share that content with any other tools that also use the TAMs API. So removing that need for lots of kind of point to point direct integrations and really just enabling customers to pick and choose tools and swap them and add them into their workflows much more quickly and easily. Fantastic. So I think the really big question here is, what can how can TAMs help broadcasters do what they weren't able to do before? James, I know that you've been exploring this. Yeah. Absolutely. So I think what I'd say is that the key thing about TAMs is that it's a potential agnostic handoff point for live and recorded content. So that's important for rights holders and content producers and broadcasters who are consuming that content for use in their programming. Previously, broadcasters needed to be always across a live feed, okay, provided by rights holder or content producer, constantly recording content. So missing the start of something is an issue or getting across something in the first place is an issue. With TAMs with TAMs, broadcasters no need no longer need to record everything. Okay? So if the source is available in TAM's TAM's store, they can obtain a copy of the recording from the live feed, so just after it's happened, or they can seek back into the past and find content from hours before. Now this is particularly important with procedural content. So those of you who know me know that I'm a parliamentary nerd. And there's a lot of long form audio and video. And being able to access content from a TAM store systematically without human intervention means that you can obtain access to content quickly and easily. So you haven't got to record the hours and hours and hours of the commons and lords. You can come and get the bits that you want and the bits that you need. Fantastic. That makes takes me back to my days in radio where we would have to go through lots of video tapes to find the clips that we wanted. TAM sounds like that's gonna make that a lot easier. Rebecca, you're coming at this from an operations point of view. What benefits do you see TAMs offering in the in the future for operations? I spoke just I'm I'm struggling with my voice a bit today, so please forgive me, but I'll do my best. So from what I've learned so far, I think there's a few standout advantages for me. I think the first, the potential for real scale, so no longer being tied to port recordings or those other sort of physical constraints, which, you know, within that, that means we can provide far more flexibility and choice for production. I think we can then get to production much faster. So whether that's editors, compliance, localization, everyone being able to start straight away and sort of simultaneously as well because that content is just because the content is instantly accessible. I think it has the potential to sort of open new doors for linear, given that traditional linear transmission, perhaps more of the agility of a of a streaming platform. And then we say, you know, it's all about trying to to to smooth out that glass to glass process for for us in operations. If we can remove some kind of core steps from our content supply chain, within that, you know, I'm confidently I'm confident that we can significantly improve our time to on on demand as a result. I think what, though, interests me the most from what I've seen is it would give us a really strong foundation for more of that smart automation AI. It aligns with our cloud strategy, sort of that one platform initiative. And and then also it sort of is in line with that simplifying the technology estate as well, I think instead of sort of constantly adding to it. So, yeah, they've been my sort of key standouts so far. K. Thank you. So these all sound great, but there must be challenges of implementing TAMs. Aren't there, Kevin? Yeah. We've started our journey with TAMs, really. So we're finding out a few things. Ownership is one. So having a great big data lake is great, but, you know, if you're news and you wanna protect some content and not have it accessible to other people, how do you how do you create some authentication or authorization against some of that content? This question is about monoessence and multiessence, so how you organize those segments in in the store. So monoessence is great because you've got all the, the different video and audio tracks, but you might be paying for things to create those separate audio tracks. So the video and audio are all separate, and then you have to demaps the content to be able to store those. Choosing a tom TAMs model to the relationship between source and, the source IDs and the flow IDs, you have to model all that. So you choose what modeling you're going to do. And media discovery. So TAMs is about maybe a source ID and a time range, essentially. It's like, okay. It's great that you've got a common language across domains, but how do you how do you allow those different domains to discover those source IDs? I have meet your asset management system. Do you create something else? Yeah. So some of those things are we're working through now. Okay. Great. I learned new things already, new phrases already, mono essence and multi essence. These are new things for me already. So this is this is good. You talked about audio there actually. And I wanna ask Dave, is it possible to store video and audio separately so you can make audio only workflow flows more efficient? The answer to that, Jenny, is yes. But let me just wind back a bit because, you know, we really love new technologies that move the needle when it when it comes to software workflows, cloud workflows that leverage the extensibility and the collaborative potential of cloud in particular. And and TAMs fits that model precisely. So as a technology, TAMs can leverage efficiencies, in a way which you can't do by just lifting and shifting traditional, linear files and and and working with growing files. Though, again, in terms of efficiency, a lot of our customers want to work with a methodology which is similar, if you like, to the twenty one ten essence methodology of keeping video and audio separate so that you can access them independently. And with the Darwin platform, you can absolutely do that. You can choose to actually store video and audio transport stream elements independently on each other, but still timestamp to each other. Okay. Thanks, Dave. TAMIS is interoperable, I believe. John, why is that important? I think that ties in with what I said at the beginning. For customers, it's really key that tools work together. No single piece of the kind of workflow of a customer now is in isolation. Customers are looking at more and more complicated workflows that are changing faster and faster. So being able to pick and choose different tools for different jobs is absolutely key on that. And traditionally, if you've turned around and said, want system A to talk to system B, it means going and talking to different vendors, getting them to actually agree to work together, doing that integration piece of work, testing it. And then as a customer, often, may be charged for that work if you're the first to sort of ask for it. So by stepping back and looking at something like TAMs, which is an open source API, you get that direct interoperability that from a partner point of view and a vendor, you've only got one integration to go and do, meaning that you can then focus your development time on actually making your tool better rather than having to do lots and lots of integrations. But from a customer point of view, then it's much easier to pick and choose the tools that you want and not be forced down a particular route. You can go out and pick your choice of ingest tools, editors, AI play outs, distribution tools and tie them into the TAM store without having to go through that complex integration process. So that interoperability is really key for the modern workflow and enabling customers to move faster and deliver all the outcomes that they want to. Okay. Great. I want to talk to our end user panelists, Rebecca, James, and Kevin. Can you tell me what change what challenges you're currently facing in fast turnaround work flows? Rebecca. Sorry to make you talk when you've got a sore throat. Okay. So, yeah, I lead the operational teams delivering fast turnaround content primarily for Sky Sports and key entertainment shows. So we've got the Saturday Night Live coming up in March, massive title for us. And I'd say, like, the scale of what we're working at today is just completely different to what we were doing a few years ago. Know, live sports volumes keep growing. Our rights portfolio is just expanding. And then I think customer expectations are also growing. They're expecting, you know, near instant but high quality content across multiple devices. So the challenge that I have is that the workflow that we're using to deliver this very critical service for the business was designed around a decade ago, and it was absolutely the right solution for its time then. And my team have done and always do such a fantastic job at, you know, maintaining a very near faultless service. But if I step back, you know, today, it's fragmented. It's more manual than we'd like. We're we're still duplicating, converting media, copying metadata between systems, moving between multiple different user interfaces, all just to get a single highlight to wear. The other part for me is a challenge of an operational leader is we can't meet future demand by just simply adding more people. It's just not sustainable for us. So I think that's really key. What we really, really need is, you know, smarter, more connected workflows that are allowing us to sort of remove that friction and reduce any repetition and then really give, I suppose, the team's time back to focus on quality and value, not not all of the admin. I I was just gonna give a bit of context about sort of where my role comes in because I'm I'm not the technologist, and and I don't decide the technology that we're we're using at Sky. But I work very, very closely with our content engineering team. It is my responsibility to ensure that we're delivering that trusted service to our stakeholders. So I'm really there pulling in and helping to set sort of the business needs and make sure that our current and our future workflows are sort of genuinely adding that value. I think within that, pinpointing, you know, areas of opportunity where where we must and need to do things differently through technology. So, yeah, I think that that those challenges, the scale, the fragmentation, inefficiency, all of that, you know, has made it really clear that our sort of our current approach to working, it it it won't take us to to where we need to be, so we need to do something now. Yeah. Kevin, is that is this all the same for you? Yes. It's a large organization. Right? So we have siloed content stores, really. So we're you know, news will have its own sport. And, you know, if you take a use case like, I don't know, strictly come dancing or something, that Always a good good case for me. dancing, with. the stars of your America. Think that that one piece of content, you know, that's a video on demand asset for iPlayer that if something occurs in that program, news might want to click that. If there's a sports star as one of the dance sport might want that. And moving content around, for each of those domains, really, is quite difficult. So if you've got one content store that people can access with a common language, which is what's the source, BBC one, what time do you want in that source? That's quite simple, right, to to manage that across the different domains. VOD, I want the whole thing, a clip of etcetera, etcetera. So, yeah, that's some of the challenges that TAMs can overcome. Fantastic. Thank you. James, you've seen TAMs used for news. What can you tell us about that, and how did it help? Yeah. Sure. So so the the proof of concept that we put together for IBC in September used parliamentary content, and that was really all about showing how we could replicate content between different TAM stores and to illustrate how you could access the content more easily. And the focus really was on the speed of replication and what we could choose to replicate. But trying to answer two questions at once here. So the previous question was about the challenges, and I think the the big challenge, I would say, is provenance. So provenance in news has always been a problem, but the the effect of not keeping good provenance is not severe as it is today. Okay? So some customers with big newsrooms have a lot of churn. So they have a lot of live content coming in. Some of that live content might go straight to air, might be recorded, then it's brought back into the newsroom again, and it's not clear where the content is originated from. If I think about it with a a parliamentary hat on, there's a responsibility really for large content producers to provide a mechanism to stamp their content on the way into people's newsrooms so that it's clear where the source is and what the provenance is. And I think TAMs is a potential answer to that. So if you've got a large content producer like parliament who has got hours and hours of content each day, and we are actually digitally signing each chunk that we put into our store, that means that we've got a unique worldwide reference all over the a unique worldwide reference to point to that piece of content and say, yes, those people on those green or red benches did come from parliament, and it was on this day. That's really important, of course. So we we talked about our next generation solution. So Rebecca, sorry. I'm gonna make you talk again. What is Sky looking for in the next generation solution? Yeah. So for me, next generation solution has to do more than just give us small efficiencies. Right? It's it's gotta be a bit of a step change. It it genuinely has to change how we work and the value we can deliver to both the business and and to customers. TAMs, you know, is obviously one example, but if I if I talk more broadly when we talk about next generation, we're looking for solutions that are really there to sort of simplify the landscape. So fewer platforms to navigate, single user interfaces to interact with, cleaner operational steps, far less of that repetitive manual work that I spoke about. I think we need to ensure that data is not secondary. Like, it should be absolutely driving these workflows. We've got to do everything we can to remove remove any of the risk around these critical services. We need to integrate, you know, cleanly with the with the cloud. And then, yeah, just find ways to give us that scalability to keep up with the pace and and and that growth of of content demand. But I'm gonna be biased, but I'm gonna say, you you know, the most important part for me is the operational input. If a solution isn't, you know, shaped around the people who are using it every day, it's not gonna deliver its full potential. We we have to be ensuring that, you know, technology is making life easier for teams and and not harder. So, yeah, I think that's that's what next generation means for me. Yeah. And Kevin, for the BBC? No. I'm making you speak about, you know, you having to speak on behalf of the whole of BBC, I from your point of view. think it's doing more with the content. We're just being asked all the time, you know, can we make this available to more people in all the different ways you can imagine and be agile about it. So when a new platform comes along, maybe we need to be ready to be able to serve that platform. And if we're having to manually move content around, that's quite a difficult thing, isn't it, to be agile? Especially, Rebecca said, if you have to put operational wraps around everything and support for that new, supply chain. So just being agile, really, and to be able to use that content across the whole organization or make it available to the whole organization, I think. Okay, thanks. Just going to pause and remind the audience you can submit questions to our brilliant panellists. I can see some are coming in and we will get to them very shortly, but please, you know, this is your chance to talk to the experts. I'm here to be your voice. Please submit your questions as we go ahead. So we've talked about news, we've talked about strictly, two of my favorite things. Are there other areas where TAMs could be used by a broadcaster? Dave. Yes. Absolutely. Anywhere where media storage is required, in a in a really efficient way that avoids the use of growing files. And and I would say further to that, one key advantage that TAMs has, and I think also is shared with some of the other newer interesting technologies that we're seeing, is that it embraces the challenges that the IT industry has already solved. So in other words, it uses standard IT industry techniques like HTTP, OAuth two predominantly for authentication, although there are other options. And that means that the barrier for client integration into a TAM store is actually fairly low. And for that reason, we're seeing quite a an expansion in that area. And even, for example, playout systems, I'm aware that there are playout systems now which are integrated within a TAM store. So so in theory, you can use it for pretty much any application where you want to store content, manipulate metadata, and run a very efficient operation, which is if you implement it in cloud, can be highly scalable as well and use the, the connectivity advantage of of of cloud. Thanks, Steve. Anyone else want to pick up on that one? Because it's, you know, it's quite a broad question. So if anyone else got a point of view, please feel free to share. I'll come in there, Jenny. So, yeah, where where else can Tanzu be? We talk a lot about kind of fast turnaround workflows because that's kind of where a lot of the Tanzu thinking was born. But it's actually anywhere that content owners, broadcasters have got live, near live, as live kind of workflows. So that's not just news and sports, but you've got things like Saturday night entertainment. We think it's quite a good fit for reality TV shows where you've got maybe lots of cameras recording for weeks and weeks at a time where you want to have all that content synchronized to the time it actually happened. Because, Tams, you're not limited to the record durations in there. You can have these long running records. So that kind of reality TV workload we think will be a very, very good fit here. We're seeing quite a lot of interest in compliance recording off the back of playouts. They need to record for months, even years and hold that for legal purposes. Again, you're recording and accessing that content as it's happening. And particularly in the modern era AI. I can't believe we've got thirty minutes in before we kind of said that. It's the ability to go and take the chunks of media out of a time storm, pass those into the AI models, go and evaluate that content, find their insights from it, and then go and trigger other workflows, whether that's automated clipping, transcription for semantic search, all those kind of really good workflows we think can hang off the back of the TAM store as well. So while news and sport are kind of probably, they're kind of bedding early places for TAMs, there's a huge amount of more opportunities we think that it can be appropriate for. Okay. I was gonna ask you what you would say is the biggest advantage of employing TAMs, but I always feel like we've answered that over the last half hour or so. So I'm gonna move on to my next question, and it's actually a question that's also been submitted by one of our our audience. And that is, does TAMs have to be in the cloud? John, Okay. I you're the best person to answer that one. yeah, it's cloud solution architects in the room, yes. So, I need to be really fair to the Tanzu API specification here. It does not mandate the use of any particular technologies in there. The only thing it mandates is that the content is available over HTTP, so you get the benefits we talked about earlier with standard IT approaches. And that does drive the use of object storage. But beyond that, you can implement TAMs in any technology you like, containers, virtual machines, choice of your databases. It's the API specification that's the important thing. As AWS, we recognize the need from our customers in this area, is why we've leaned in so hard. And we've released a kind of reference implementation that obviously uses our technologies to go in as part of that. But this is not the only way you can implement TAMs. So you could, as I said, implement it in any technology like the store itself can have multiple locations. So you can have multi cloud, hybrid cloud and on prem within the same store itself. So it's really flexible in terms of those capabilities there. Okay. Right. Thank you. Go. Somebody wanted to fuck. it's a framework. Right? So, like, we've been going around internally in the BBC, and people ask, is there a box I can buy or and put in? And, yeah, it's it's a framework that you can apply to a load of use cases. It's, yeah. Okay. Dave, Kieran kind of touched on TX Darwin in his presentation, but why did TechX think TAMs was a good fit to implement on TX Darwin? Well, having said that the barrier to entry is quite low to be able to interact with a TAM store because it's based on standard IT technologies, I think we've taken on the tougher challenge of being able to write linear content into the TAM store. And when we wanted to do that, it was really a no brainer for us to build that capability into a really, really flexible media processing platform, I. E. Tech x Darwin. So just imagining the journey of a customer wanting to take linear content and write to a TAM store. First of all, where does that content come from? You need the flexibility in terms of ingest. You need flexibility in terms of being able to monitor and switch between sources potentially. All of this, Darwin can do. Then there's a question of what format do you want to store your content within the TAM's environment? Is it the same as you've ingested, or do you need to transcode it? Do you need to change the PID structure? All of these manipulations, even as far as doing a full standards conversion. And then, of course, are you doing other workflows which can ride on the back of the processing you're doing? So recording to a TAM store can just be added to other things which which is happening to that particular screen. And I can I can go on from the flexibility aspect? I won't do, but I'll just mention when you're writing to a TAM store, I are you writing? You're defining a timeline, but where does time come from? You need options. And and this is really the fabric that Darwin can provide around the TAM's writing functionality, and it's why it's such a good fit. thought you were going all timey wimey there, we were about to enter Doctor Who, but it's fine. We pulled back. We've gone we've not gone down that route. I'm really interested to hear what you guys are hearing from the wider industry about their interest in Sam's. I can see we've got questions coming in that people are definitely interested. But, James, I know that you were obviously showing at IBC. What's what what are you hearing from the wider industry so far? Well, lots of different things, really. I think, people were particularly surprised, I think, to see parliamentary content on an IBC stand, if we're completely honest. And it's I think it's because of the long form nature of parliamentary content, it's particularly well it's it's particularly well suited to terms. Right? Because having to get across a lot of things and record a lot of stuff is a problem. And the the other thing around that, I would say, is that we're seeing more and more decentralized workflows. So when, you know, when we started using more kind of traditional MAM systems with ingest servers and so on, What we had there were large POSIX based file systems in data centers, right, or in or in comms rooms with people sat around all trying to access that same piece of content at once. And all those people were generally sat in the same building, if not the same campus. And and systems were built in silos based on the physicality of where the people are. What we what we've got now is we've got a situation where the work force is even more decentralized. Right? We've got people who wanna work from home. We've got people who wanna work in the office. And we're trying to you know, from an IT point of view, IT is trying to move towards a sort of cloud network model where it doesn't matter whether you're in the office or whether you're at home. And the broadcast systems and broadcast workflows are kind of behind the times on that point of view. So what I would say is that TAMs is gonna support stuff, or support more decentralized workflows, enable more flexibility with kind of common IT architecture, common IT systems, and less of a need for kind of specialist, meaty compute infrastructure and being able to do more on your laptop at home and being able to access the content. So if you imagine a TAM store, you should be able to access that content wherever you are if your connection is good enough or fast enough. Does that make sense? I think so. Yeah. Thank you. One of the things we've been talking a lot about TBB Europe since IBC is MXL, the media exchange layer. Both TAMs and MXL are open source. Can they work together? Kevin? So we're not looking at that at the moment. We're we're. just trying to get the basic sort of TAMs implementation off the ground. I I'm not sure within TAMs. Our first use cases for MXL will probably be some functions within a cape like a transform capability for a master control room where you might want some in like an individual company's capability or function as a as a tool and then hook those things together maybe. So we're not in that space at the moment, so I shall pass over to maybe other people who might have thought about that a bit more. Anyone else wanna pick up on that one? Or if I flimmoxed you all? Sorry. Yes. I can. I I can say a few words. Please. I I think absolutely. So so let's just consider the differences between between TAMs and MXL. So MXL is designed to enable vast amounts of traffic to be exchanged between processes. So it's not about storage, although it does use a ring buffer. It's all about exchanging content, predominantly uncompressed video content as an enabler, between two processes. And so I guess you can ask, what does that open up? It it really opens up interoperability between, multi vendor environments, particularly when working within containerized environments. That that's really what it's all about. So if you wanted to take, for example, uncompressed media into an engine like against Darwin, which is capable of then storing that within a TAM store and performing all of the manipulations and and and storage functions that the TAM store is built for, then absolutely, there's a marriage between the two. It's important to to realize that the functions are very different. And once again, in terms of video processing, it may be that you want to ingest uncompressed video because you can with MXL, and there are often advantages to do that. But you may well want to encode it into a different format and store it efficiently within a TAM store. And so once again, media processing format is exactly what you need. Okay. John, you wanted to. pick up something. I was going to say Dave's done a very good job there, sort of how they fit together. But yes, ultimately, MXL is for live, TAMs is for that, everything else you need to do as soon as you come off the live edge to be able to store, manipulate, and deal with that content. One of the biggest challenges in the industry actually right now to address with this is around timing. The T in TAMs is time. And as we described earlier, creating a timeline that your media is attached to within TAMs. And that can actually use genuine time, not time code, genuine time. But the challenge is always where does that come from? So there's actually a joint task force at the moment looking at some of these synchronization and timing questions. Because ultimately, what you want is to preserve your timing from as far up the chain as possible. Ideally, the glass of the camera, that's the timestamps you want with your media. Preserve that all the way through your contribution chain, through your MXL, through the vision mixers, and ultimately into the store itself. And there's definitely work as an industry that we've got to do on making that flow absolutely work. So often today, the recorded media is offset because it's been through an SRT feed and then just there and everything else. You end up with an offset between, for example, live sports data, which is time to the stadium time versus the time that the media ends up with. So as an industry, if we can get these standards right and these approaches right with things like SRTM, Excel and TAMs and actually preserve that timing all the way through, we'll end up with much more powerful workflows at the end of it. This industry loves a good acronym, doesn't it? James, you wanted to talk about using TAMs in a production workflow? Yeah. So so building on the back of what John's just talking about with timing and preserving the timing, I think one of the things the concepts we've talked about today assume that we've got a program signal that has been produced and we're recording that program signal into the TAM store. I think there's a really interesting synergy between the concept of live and near live. So if you consider the point that the duration of the of each segment that you record into TAMs can be whatever you want. Okay? So let's say that we actually recorded our content in frame by frame into a TAM store. Right? There were sports production workflows where we need to be able to produce lots of different versions or several different versions of the same piece of content or the same event to create multiple program outputs. And I think that TAM is a really interesting concept for that because you could record every camera into a TAM store and apply, like, a live edit decision list across the top of the TAM store and play it out within a couple of frames and actually produce different program outputs based on the same content coming in and have a representation of them all. And that's this is where we're getting to the point of kind of near live versus the live nature of MXL. It's fascinating. So I I the final question for me really, I think, is what's next for TAMs? John? Yeah. So I'll pick that one up. I think 2026, all indications are it's going be a really big year for TAMs. We are seeing deployments at scale. So BBC and Sky are really good examples where we're going to see big stores deploying. It's not simple workflows that either BBC or Sky are implementing. We're talking about big production workflows at scale going out here. We're seeing multiple proof of concepts kicked off even just this year at the moment. So and new partners, vendors asking to get involved. I think a lot of people clearly came back after Christmas and their New Year's resolution was, let's go and ask about TAMs because we've seen such an uptick in interest this year. So I think it's going be a big year from the development and deployment kind of side of things. In the TAMs API, we're also seeing new features coming in. So while the core is incredibly stable and hasn't changed, we are seeing new features that are coming in to make workflows easier. So we're talking at the moment about things like profiles, fine grained auth kind of work continues. So the terms of specification will continue to evolve throughout the year and ongoing. I very much welcome its open source input into that process. And then finally, the kind of big one for this year is the governance. The BBC has put out statements quite talking about that their plan is to move TAMs from being under their ownership to an open source foundation. I'm part of the initial technical steering committee for that, and we're currently in that process of seeking out more people to be part of that. But the idea is that once that technical steering committee is formed, the first piece of work to go and do is work out which open source foundation and set up that long term open source governance. So I think '26 is going to be a really big year all the way from, as I said, deployment features and how TAMs actually is governed going forward. Sounds really exciting. And I love the idea of people saying all I want for Christmas is Tams. But anyway, that is my questions for today. Before we get to the questions from the audience, and there are a lot, I want to take a quick look at the poll we asked you earlier. So we asked you, what's your potential use case for TAMs? Dynamic advertising and product placement, fast turnaround workflows, timestamps for your feedback and engagement, on demand playback with enhanced searchability, enhanced replay and social media highlights, or other. And this is where I always have a problem because I can't see them all. But it looks I think it looks like fast turnaround workflows seems to be the majority vote. So which is I think kind of replicating all that we've heard from our brilliant speakers so far. So, alright, it is time. It is time to get to the audience q and a. I'm sorry we didn't get there sooner, but we're gonna do it now. So first of all, Brian says, how do teams typically implement and govern access control for TAMs flows? Sorry. Didn't read that very well. Who can view, run, edit, or deploy? And what practices have proven most reliable? Who would like to answer that? And then could let you know if you want. on. The TAMs there's been quite a lot of work done over the last year around Fine Grain North. I need to call out James Sanford from BBC R and D who's been leading that work because we recognize that actually for TAMs to be successful, you don't you wouldn't just want a flat store where everybody can access everything. You need to be able to provide access controls on there. So there's been a lot of thinking done to add those controls in. There's a whole app note on the GitHub with the API specification to talk you about the detail of how that can work. It's fair to say right now the AWS reference implementation doesn't have that built into it. We've been looking and thinking about how we do that to be able to demonstrate that. But James particularly, as I said, done an awful lot of thinking about how this should be implemented, what's needed in the TAM specification, and how you can do it. And that will then allow you to apply fine grained authorization at the source and flow level. We took a decision not to do it at the segment level just because the overhead becomes very, very high if you do that. And one of the things we want to make sure that Tanz is capable of doing is working at speed to find that fast access to content. So there are ways of doing edit by reference and other pieces to deal with that. So ultimately the design is that you can restrict the permissions based on the flows and sources. So you could have somebody who has access to the proxy but not their high res. Or you can have people who've got access to content a and not content b in there. Okay. Next. James, 2.7 in the chat actually that Sam's also Sam, Weston, Gibbons and R and D has also been involved in that work. So, yes, they'll probably all be crediting both of them there. Gotta get the credits right. Okay. Right. Daniel asks, are there any recommendations on size of TAM's data pieces? James, Dave, Kevin, who who wants to answer that one? So, I think what I would say and this is gonna be an awful answer, really, but it depends on the use case. Right? And, also, it depends on the size of your infrastructure. So, if you think about so the the smaller the, the TAMs data pieces are, the more API calls you're gonna need to make. Right? And the more content you're gonna have to read and write in and out of the object storage. So it all depends on what you're doing with it. What I would say is I think we were working on four, six second chunks, John, when we did the demo at IBC. Was it six? Six. Yep. It was six. Yeah. And when we were doing the replication, the interesting thing was was that we could effectively do the replication between three TAM's data stores, one in London, one in Paris, and one in Ireland, and we could do that within six seconds, which was a coincidental I think it was six seconds. Right, John? Is that about right? But, yeah, within a few seconds of that. Yeah. Yeah. Yeah. Exactly. Okay. Yeah. Thanks, Claire. Michael asks, forgive me, Michael, because I'm not quite sure. I know most of the acronyms but not all of them. Any thoughts about using MOQ for retrieving video down the line? Whoever takes that question, could you explain to us, oh, thank you, Michael. Media over quick. Media over quick? Okay. Any thoughts about using media over quick for retrieving video down the line? Who would like to answer that one? I think it's fair to say we've not thought about that. We've focused on the HTTP access straight from the object storage. TAMs doesn't actually own the content itself. It references the content that's on object storage. It does provide access through pre signed URLs. But actually, when you access the content, you're then pulling it straight off the object storage directly. So that's been the focus today. Media and Quicks could be an interesting concept for the future to look at. And very much this is kind of it's an open source project, so very much welcome that for the feedback and the discussion in that area. But no, it's not something we've focused on today that I'm aware of. Okay. Alexander says, do I need a TAM server to catalog everything in my lake of data Or is this handled by individual devices that interface with the lake such as Darwin? Dave, I feel that's one for you. Well, our role is to write to the TAM store. So the the way in that the way in which that works is that we receive a URL from the TAM store directly in which to push that content. And the the way in which content is identified is very much along the structure of NMOS feed. So so that is the extent of our involvement. Okay. Anyone else want to talk to? of, carry on. in, terms. of, yeah, in in terms of, recovering content from the TAM store, then that really is the, the, role of ecosystem part partners. That's. what we're struggling with. It's that media discovery piece. It's it's how do we share source IDs. So you've got that data lake. How does someone know where b c one is and how to get to it? That's yeah. We're going through that process now. One one of the things we talk about at TAMs is it is it's a media store layer. So it is indexing the chunks and referencing where they are and telling you what you've got and where it is. But we do still see the need for your MANs and your PANs of this world to be the user interfaces for people above it. TAMs doesn't store all your editorial metadata. It's about managing the media, what resolutions versions have you got, where is it, how do I access it, all of that sort of side of things. So there's still a role for content discovery, as Kevin's been talking about, for the MAMS, PAMs in this world to have the rich metadata, the search capabilities, the content discovery, all of that workflow. If anything, TAM should almost be hidden underneath that from a user point of view, just enabling these workflows to work really efficiently. I apologize for laughing whenever you mentioned, Pam. It makes me think of a particular BBC comedy series, and I'll stop. Giancarlo asks, for lifeline's recordings, what is the panel's experience what in the panel's experience is the highest volume of concurrent feeds they have seen recorded into TAMs at one time? James, can you answer that one? I kind of can. So when we did the demo, we didn't we didn't have a lot of concurrent feeds coming in. We had a handful of a lot of long form. Okay? So so as in multiple channels. So I think we did in the demo, we did up to six channels at once. The the key point I would say is that be because we were using AWS's implementation, the way that that is implemented using serverless API architecture, it means that we're not effectively, the number of calls that we can make to the API layer is infinite. So we're not really prevented from making lots and lots of calls and ingest ingesting lots and lots of things at once. The limiting factor in our implementation would be the number of instances that we're running Darwin on. So in in the implementation, we use Darwin. K. I had quite a big, meaty instance, and I could use one instance and do I could have done probably 15 simultaneous ingests using that instance. But you may want to architect it in a different way. So you might want to make it more scalable and say, okay. Well, I'm gonna have a smaller size instance running my software, running Darwin. And then when I want another ingest another one, I'll just spin another instance up and spin another instance up, which is kind of interesting from another point of view because if you're looking for a solution that is based on events, so news, especially parliamentary content, can be very peaky. Right? So sometimes there's 22 things going on at Westminster, and sometimes there's nothing. So actually having the ability to scale up and scale down that kind of software infrastructure to do simultaneous ingest or to just do one or two or to do none is particularly advantageous. So I realize that hasn't directly answered the question, but, hopefully, what I've done is I've provided you an answer in a roundabout way. Thank you. Okay, Three. time for, sorry, one last question. Just want to fit it in before we have to wrap up. It's from, I'm sorry if I get this name wrong. I think it's Kushagra who says multiple applications can also read files directly from the s three and also fetch the file from any specific point in media. What does it compare how does that, I guess, compare with TAMs? Also, given four to six second sec segments, is it similar to HLS chunks? I don't know who to direct that one to, so I'm gonna let you guys fight it out. So I think it's fair to say with TAMs, what we're doing isn't isn't new. If you look around the market, you'll you'll find other vendors who realize that small chunks of media on object storage is the way to go in the cloud for these kind of workloads. What is unique about TAMs is that open source API. A lot of the vendors who've done this have done it within their own closed ecosystem, within their own system, and not opened it up. TAM the thing TAMs gives us is that open interoperability that we talked about earlier. And by using the direct access to object storage like s three, you then get the scale to be able to underpin the kind of workflows in there. So yes, there are other systems out there that are very similar, but we don't there's no others that we're aware of that have that open and tropical kind of piece to it. And in terms of the question around segment length and HLS, TAMs is compatible with HLS. It actually goes much further. We found the times that we kind of converted TAMs to HLS or imported HLS into TAMs, it's absolutely doable. But actually what you hit is the restrictions in HLS well before you hit the restrictions in TAMs in there. So you can do that kind of cross compatibility if you've got the right media formats to be able to do it. But TAMs is actually so much more. It can do subsegment workflows, frame accurate. It's not restricted to TS files. Can put any you can define your segment length, wrap as codecs. It's incredibly flexible framework to go and work within. Okay. Anyone else? Any more points? Yeah. Yep, go on. Just to expand on the HLS relationship, I I should say that when we chose to implement the TAMs writer, we based it on an HLS writer that we had done, but you cannot call what is written to a TAM store HLS. It's it's in a similar form, but it has no manifest to go with it, for example. There's no m three zero eight file. So strictly speaking, it is not HLS, but but the relationship is there. Okay. Thank you Dave. Unfortunately, that is all the time we've had for today. I want to remind you about the downloadable links that you can see on screen. Before we go, I want to let you know about the first ever TAMsCon, which is taking place on the March. You can find out more details about that at the official TAMS website, timeaddressablemediastore.org. We'll also that's a very good website. I read it quite a lot to keep up to date. Please join me in thanking our expert panellists today, Kevin Morris, Rebecca Light, Dave Mitchison, John Biltcliffe and James Elliott. If you joined us late, this webinar will be available on demand soon. I don't think we're using TAMs for that. But I would say finally, keep an eye on tvbeurope.com for all the latest industry news as well as future webinar announcements. And we will see you all again soon. Thank you.