The cloud took over broadcast production. Here's what still belongs on-prem.
Ask a broadcast engineer where live production happens today, and the answer increasingly is "somewhere else." Switching, graphics, replay, and multiviewing that once required a rack room now run on cloud instances that spin up for an event and disappear afterward. For a growing share of production tasks, the cloud did not just join the workflow. It became the workflow.
That raises a fair question: What is left on-premises, and why? The answer is more useful than the usual hybrid-cloud talking points because it reveals which parts of production depend on physical infrastructure and which depend on how the work gets done.
A single machine does not require IP video
Start with a simple observation. When video processing happens entirely on one machine, there is no need to transport video over a network. A creator editing footage on a desktop workstation, for example, can work with video entirely within that system. The same is true of a single AI model running on a single GPU. Video moves from storage to memory to the processor inside the box, and no network protocol is involved.
The need for IP video appears the moment a workflow becomes distributed, and cloud production is distributed by definition. A graphics engine runs on one node, a switcher on another, a captioning service on a third, and a distribution encoder on a fourth. Every handoff is a network hop, and every hop has to carry video.
The cost hiding in every handoff
Video is among the most data-intensive formats a network will ever carry. A single uncompressed 1080p60 stream runs well over 2 gigabits per second. Multiply that by dozens of sources moving between cloud nodes, and bandwidth and data-transfer costs climb quickly.
This is why the transport format matters as much as the compute. A codec designed for software can cut the data rate to roughly a tenth of the raw stream at a cost of only a few percent of CPU. That works out to about an order of magnitude more from the same network and compute budget, depending on the workload. Cloud providers bill for both, so efficiency in the handoffs shows up directly on the invoice.
The same logic applies well beyond broadcast. Distributed AI pipelines, built from many small models on separate nodes, face the same problem of moving heavy video between lightweight components. Wherever work is split across machines, the economics of moving video helps determine what is practical.
What stays on-prem
If distributed workflows belong in the cloud, what keeps hardware in the building? Three categories stand out.
Sources and displays: Cameras, microphones, LED walls, and confidence monitors exist in physical places. They cannot move to a data center, and they often run on resource-constrained embedded processors that support only part of a given protocol. As more devices ship with IP video built in, compatibility becomes a practical concern. When two devices cannot agree on a codec or frame rate, operators need a clear explanation of the problem and how to resolve it. A black screen with no explanation is not acceptable in a live environment.
Timing-critical work: Hardware-centric approaches such as SMPTE ST 2110 and IPMX offer low-latency transport and precise synchronisation for demanding production environments. Facilities with those requirements will keep dedicated gear for the foreseeable future. But many productions do not need that level of precision, and for them software-based transport is more than adequate. Engineers should match timing requirements to the actual need rather than defaulting to the strictest option. The protocols are better understood as complementary than competing, and a single facility can reasonably use more than one.
Controlled environments: Government agencies, courts and corporations often require that video stay inside a secured network. Open, easily discovered video transport and locked-down enterprise IT pull in opposite directions. The industry is still working out how to deliver strong authentication and encryption without making setup painful. Until that balance is struck, some videos will stay on local infrastructure by policy rather than by preference.
Metadata keeps the chain intact
Moving video is only half the job. A workflow that carries a clean picture but drops the data around it is not a working workflow.
Consider a common path. A contribution feed arrives over SRT, passes through an ST 2110 facility, moves into the cloud for software-based production and returns to SRT for distribution. That signal crosses at least three different technologies. At each boundary, the information that makes it broadcast-ready can be lost.
Closed captioning is a distinct example, illustrating why metadata matters. Captions are required for broadcast programmes and are essential to accessibility. SCTE-35 triggers serve a different purpose. They signal when downstream systems should insert ads or switch content. If those markers are lost, an ad break can be missed, potentially costing revenue.
Metadata is nothing new in IP video. Most transport formats can carry arbitrary data, and for years each vendor decided for itself how to package captions, triggers and other broadcast messages. That meant two systems could both handle the data and still fail to understand each other.
The fix is standardisation. When a group of vendors agree on exactly how these messages are formatted and carried, devices and software from different companies can interoperate without custom integration. Cloud platforms have started supporting these standardised messages, which allows captions and triggers to survive an SRT-to-2110-to-cloud-to-SRT round trip intact. Interoperability is not just whether the picture and sound show up. It is whether the workflow still does its job.
Practical takeaways
Engineers planning the next phase of a hybrid architecture can start with four questions.
- Where does the workflow become distributed? Single-machine tasks do not need IP video. Multi-node tasks do, and the transport choice affects cost.
- How much timing precision is truly required? Reserve hardware-centric approaches for work that demands them.
- Does metadata survive every boundary? Test captions and SCTE-35 triggers end to end before air, not after.
- Will failure be legible? Whether it is a codec mismatch or a dropped stream, operators need to see what went wrong and how to fix it.
The cloud has taken over much of broadcast production. What remains on the ground is what is physical, what is timing-critical and what is controlled. The connective tissue between the two worlds, efficient transport and standardised metadata, is what lets them work as one.
[Editor's note: This is a contributed article from NDI. Streaming Media accepts vendor bylines based solely on their value to our readers.]