We sat down with Paul Briscoe, TAG's chief architect, to talk about why TAG is developing MXL capabilities and what it means for broadcast operations directors navigating the complexity of IP workflows.
Q: Why did TAG decide to build MXL capabilities now?
Because our customers told us they'd hit a wall. And when that happens, you listen.
As TAG’s Chief Architect, Paul brings to TAG over 30 years of experience delivering leading edge solutions from both the client (CBC) and the vendor (Leitch, Harris, Imagine) engineering perspectives. Paul leads the charge driving TAG's roadmap and helping clients define their requirements for transitioning to IP. A SMPTE Fellow with several patents and author of numerous industry standards to his name, Paul is TAG’s evangelist and visionary. Paul lives in Toronto, Canada with his partner and family.
We've been in the room with broadcast engineers and ops directors through their SDI-to-IP transitions for years. They did everything right: they mastered ST 2110, got PTP timing under control, built out the infrastructure. And then they ran into a new problem: the complexity of 2110 itself became the ceiling.
Every time they wanted to add a workflow or move something to cloud, they were managing exponentially more timing constraints and engineering hours just to keep things running. The technology that was supposed to give them flexibility was now the thing limiting their growth. That's not only a technology problem, it's a business problem.
Q: What do 2110 operational challenges look like day-to-day?
Here's what we kept hearing: "We need to cover more events, but we don't have the engineering capacity to stand up another ST 2110 facility." Or: "We want to scale into cloud for certain productions, but the protocol conversions and timing challenges make it difficult to achieve."
One ops director told us they were burning 60% of their engineering time on commissioning and managing system complexity, not actually improving their workflows. That's the real cost. It's what you can't do because your team is buried in technical tasks that should be simpler.
Q: So how does MXL change that?
MXL takes the parts of ST 2110 that work really well, the formats, the capabilities, and strips out the complexity that's blocking people.
Instead of managing thousands of packets per frame with nanosecond-precision timing, media moves as straightforward memory-to-memory transfers. No PTP. No specialized UDP networks. And the same workflow runs on-prem or in the cloud without protocol gymnastics. For ops engineers, that means teams stop spending the majority of their time managing infrastructure and start spending it on work that actually drives value. That's the whole point.
Q: TAG is known as a monitoring company. Why get into transport layer technology?
We're a software company that specializes in monitoring, and because of that, we've had a front-row seat watching customers wrestle with IP workflow complexity for years.
Here's the thing: you can't monitor what you can't see, and you can't optimize what's technically constrained.
We're building MXL support into TAG's platform because monitoring needs to work seamlessly whether workflows are running on ST 2110, MXL, or any other format, on-prem or in the cloud. MXL also happens to eliminate a lot of the timing and interoperability issues that created monitoring gaps in traditional IP workflows. Our job is to make operations more efficient and workflows more reliable, regardless of transport technology.
Q: Where does an ops director start?
Start by finding where ST 2110 complexity is actually costing you.
Are deployment cycles dragging because your team is navigating integration challenges? Are cloud-hybrid workflows off the table because the complexity doesn't justify the business case? Those are the places where MXL delivers immediate value. You don't need to understand RDMA specs to make this decision. You need to understand whether eliminating PTP timing constraints or multicast networking would let you deploy faster or scale more efficiently. Then have a conversation with your infrastructure partners about how to architect for flexibility.
Q: What does MXL mean for broadcasters who are still mid-way through their ST 2110 journey, or haven't started yet?
Good news on both counts.
If you're mid-transition, nothing you've done is wasted. The video formats, audio, metadata, the fundamental constructs of 2110 are exactly what MXL moves. You're not ripping anything out. ST 2110 compatibility is fully retained, and TAG's platform already monitors both.
If you haven't started yet, you get to skip some of the hardest parts of the 2110 learning curve: the PTP domains, the specialized UDP networking, the timing dependencies that have kept IT departments at arm's length from broadcast infrastructure for years. MXL is built from an IT-centric viewpoint; RDMA and RoCE are standard IT services. That means your IT team can actually be part of this, which changes the economics and the operational model considerably.
Q: What should customers expect from TAG as MXL adoption grows?
The same thing they've always gotten from us: monitoring and multiviewing that works across whatever infrastructure they're running, with unified visibility that helps them operate more efficiently.
MXL support is already in TAG's platform. As customers deploy MXL-based workflows, whether that's in six months or two years, their monitoring keeps working and scales with them.
About TAG Video Systems: TAG Video Systems is the global leader in software-based integrated IP probing, monitoring, visualization and analytics solutions. TAG enables broadcasters, content creators, and service providers to streamline operations, cut through the complexity of IP media workflows, and keep infrastructures ahead of shifting technology and demand with Zero Friction agility. The TAG platform empowers users with innovative toolsets to ensure video quality, improve overall efficiency across all media workflows, and provides invaluable business and operational insights.
