(IA-generated image)

Current industry standards define how video moves between software functions, but not how to keep the video and the commands controlling it perfectly synchronized when those functions are distributed across different servers and locations. That timing and control problem remains unsolved industry-wide

*This content is included in the July issue of TM BROADCAST. You can access the full magazine here.

By Daniel Robinson, Product Manager at Matrox Video

The industry has embraced “software-defined production”, running broadcast functions (switching, graphics, encoding) as software instead of dedicated hardware. Industry-wide efforts like the EBU’s Dynamic Media Facility (DMF) and Media eXchange Layer (MXL) have created an open-source, vendor-neutral library for moving video between software functions. That’s real progress, and the right foundation.

But moving video is the easy part. The harder problem is keeping everything in sync.

Traditional broadcast hardware runs off a single master clock, so every device agrees on what “now” means. Modern software-based systems give up that shared clock in exchange for flexibility. You can add servers, move workloads between locations, and recover from failures without losing a frame. The tradeoff is that video and the commands controlling it can now travel through the system at different speeds. Without a way to keep them precisely aligned, “flexible and scalable” can turn into “unpredictable”. In broadcast, unpredictable means dropped frames and missed cues in front of a live audience.

Current industry standards define how video moves between software functions, but not how to keep the video and the commands controlling it perfectly synchronized when those functions are distributed across different servers and locations. That timing and control problem remains unsolved industry-wide.

“Current industry standards define how video moves between software functions, but not how to keep the video and the commands controlling it perfectly synchronized when those functions are distributed across different servers and locations”

This is what Matrox ORIGIN was built to fix. Every piece of video is time-stamped against a shared time reference, so any component always knows where it is in the timeline. The commands that control the video are also handled separately from the video itself, so they can be kept in sync with it instead of racing it. Video processing then runs as flexible, independent jobs that can execute as fast as needed within set timing limits.

Traditionally, handling more video inputs/outputs meant buying a larger system and taking it offline to install. Because Matrox ORIGIN’s components are independent, capacity comes from adding servers, not replacing them, scaling from a handful of video feeds to hundreds without downtime, then scaling back down just as easily. That translates into lower infrastructure cost and less operational risk.

Industry initiatives like MXL deserve continued support. They solve the media movement problem, and that work should continue. The next milestone is synchronized control at scale—a key part of what Matrox ORIGIN solves today. By keeping video and control perfectly aligned under one shared timing model, Matrox ORIGIN is turning “asynchronous and scalable “into” asynchronous, scalable, and reliable” in live production today.