Broadcast IP Transition: Verify Before You Replace the SDI Router

Signals considered

SDI equipment end-of-life replacement
IP production standards advancing
studio upgrade budget approved
peer station IP transition precedent
vendor IP solution demonstrations

Illustrative scenario. This article explains business-signal judgement and human verification. It does not represent a real customer, conversation, contract, revenue result or conversion claim.

A Station That Knows Where It Needs to Go — But Not What the Road Looks Like

A regional TV station’s studio equipment is reaching end-of-life. The current system runs on SDI baseband — video routers, production switchers, monitor walls and signal distribution across every station all travel over coaxial cable. Management has approved a technology upgrade budget and forwards industry reports into the technical discussion channel: “All three major equipment vendors have released ST 2110 product lines,” and “the neighboring provincial station is reportedly already on IP production.” The message ends with: “Shouldn’t we start too?”

You lead broadcast technology at this station. You know IP is the direction and the SMPTE ST 2110 family of standards is maturing. But you also know this: a 3G-SDI signal travels deterministically over a single coax cable with predictable latency over tens of meters. The same signal in an IP network goes through encapsulation, packetization, switching, clock synchronization and de-encapsulation. A configuration error at any one of these stages can cause frame tearing, audio desynchronization or complete signal loss. Running a demo signal through a studio once is not validation.

While management and vendors push for progress, you need to build a technical evaluation framework that is independent of vendor recommendations — because you are ultimately responsible for the station’s technical reliability and broadcast safety.

This is an illustrative business scenario. No real customer, data point, or result is claimed.

Why Standard Compliance Is Not System Interoperability

Broadcast IP transition is a textbook case of a decision where the direction is correct but the path is easily oversimplified. Several layers tend to get skipped under urgency.

Standards compliance does not equal system interoperability. SMPTE ST 2110 is a family of standards. Different vendors’ equipment may implement optional features of the standard differently. Device A passes ST 2110-20 certification for uncompressed video transport. Device B does too. That does not mean the two, sharing a single PTP clock source, will reconstruct the signal with identical pixel accuracy. Encapsulation details, packet timing and seamless redundancy switching logic all need verification in a mixed-vendor environment.

Clock precision requirements are systematically underestimated. In SDI, the clock is implicit in the signal. In IP, explicit PTP clock distribution is required. In a hybrid SDI/IP transition environment, if one PTP boundary clock is misconfigured — for instance, jitter introduced during conversion from SDI-embedded reference black burst to PTP — every signal on the IP chain is affected. This is not a device problem. It is a system integration problem.

Parallel production is a hard requirement that is easy to overlook. During the IP migration, the station cannot go off air. The existing SDI chain and the new IP chain must carry signals simultaneously with hitless switching between them. If the migration plan does not include an explicit parallel operation design — signal splitting, switching logic, rollback trigger conditions and human intervention procedures — the migration itself becomes a broadcast safety risk.

Evidence to Verify Before You Touch Any Equipment

Before entering any equipment comparison, complete these six verification steps.

First, map the current SDI equipment and workflows. List every signal node in the studio targeted for migration — from camera output through the production switcher, monitor wall, recording system and playout chain. Note the signal format, cable type, length and redundancy method for each link. This is not about migrating data — it is about having a precise benchmark to judge whether the IP replacement achieves at least equivalent functional coverage and reliability.

Second, calculate IP network infrastructure requirements. Work out the bandwidth needed after IP migration for this studio. One uncompressed 1080p50 video stream under ST 2110-20 needs approximately 3 Gbps. A six-camera studio with return feeds and multiviewer splits may exceed 25 Gbps for video alone, before audio, intercom and control bandwidth. Confirm whether the existing core switches have sufficient port speed and PTP transparent clock support.

Third, verify SMPTE ST 2110 equipment compatibility across vendors. For candidate cameras, production switchers, gateways, multiviewers and monitors — which ST 2110 sub-standards does each claim to support? Does coverage include -20 (uncompressed video), -30 (audio), and -40 (ancillary data)? Are NMOS IS-04 and IS-05 device discovery and connection management available? Assemble these compatibility claims into a matrix. Empty cells are the risk points you must test.

Fourth, define PTP clock accuracy requirements. Establish the clock source and distribution topology for the IP chain. What is the primary clock — GPS or a local precision clock? What is the boundary clock hierarchy? For each PTP-capable switch and device, is the measured time error within design tolerance? If the primary clock fails, what is the convergence time for the backup clock?

Fifth, design for redundancy. ST 2110 relies on ST 2022-7 for seamless path redundancy — two independent network paths carrying identical packets, with the receiver performing hitless switching. Confirm that the switch and endpoint topology achieves true physical path separation, not logical VLAN isolation. Two ports on the same switch do not constitute physical redundancy.

Sixth, assess team skills and parallel production capability. How many team members currently have IP network configuration and troubleshooting experience? ST 2110 multicast IGMP configuration, PTP fault localization, Wireshark ST 2110 protocol analysis — these skills do not transfer from the SDI era. During migration, who keeps the SDI chain running while who debugs the IP chain? If the same people must cover both, the schedule needs explicit time blocks for each.

The Human Next Step

With the evidence collected, proceed in three stages.

First, build a small-scale testbed. In a non-broadcast small studio or lab environment, assemble a minimal end-to-end IP production chain: two cameras, one IP production switcher, one IP-to-SDI gateway, one PTP-capable switch and necessary monitoring equipment. The goal is not “does a picture appear.” It is to measure end-to-end latency distribution across the full chain, packet loss under different switch configurations, PTP lock time and the signal interruption window during primary-to-backup clock switchover. Record these measurements. They become the technical baseline for station-wide planning.

Second, design the parallel production plan. After the testbed validates, design a simultaneous SDI and IP scheme for the first migration studio. Define the signal split point, how both chain outputs feed the playout center simultaneously, and — critically — the trigger conditions and operating procedure for falling back to SDI if the IP chain fails. Is the fallback automatic or manual? The fallback event must be documented and reviewed, because this experience will directly inform subsequent studio migrations.

Third, build the station-wide upgrade roadmap. Based on data from the first studio migration — actual duration, actual problems encountered, team learning curve — sequence the remaining studios. The order is not by studio size or prominence. It is by risk and dependency: migrate the studio with the lowest broadcast pressure and fewest external signal format intersections first, then progress toward the main news studio. Every studio migration passes only when real production tasks are executed successfully over the IP chain.

What Community Messages Cannot Prove

Industry reports and vendor white papers forwarded in group chats confirm that standards are evolving and products are shipping. They cannot confirm what the actual link topology, clock architecture and mixed-vendor interoperability details looked like in deployments described as “successful,” whether the scale and complexity of those projects are comparable to your station’s conditions, or what real failures occurred during deployment and how they were resolved — that information rarely appears in press releases.

A vendor demonstration — whether remote or on-site — runs in a pre-configured environment the vendor controls. A demo can verify that “under ideal conditions, the equipment does work.” It cannot verify whether your switches, your clock source, your cable types and your team under real production pressure can reproduce the same result.

The goal is not to select the vendor that gives the best demo. It is to build an IP production system your team can fully control and troubleshoot — one whose reliability is proven only by running real program signals through the full chain, with your team able to locate and fix issues without calling the vendor.

This article is an illustrative scenario demonstrating typical layered verification and decision sequencing in broadcast IP transition. It does not reference specific vendors, equipment models, project cases or outcome claims. Operational decisions should be based on your station’s technical specifications, broadcast safety requirements and applicable standards.

Frequently asked questions

Does this scenario describe a real customer?

No. This is an illustrative scenario built from common industry patterns. No customer, quotation, revenue figure, or conversion metric is real or claimed.

Which studio should be migrated to IP first?

Start with the smallest studio that has the lowest broadcast pressure and the longest available downtime window. Do not start with the most advanced — start small so that the cost and blast radius of any validation failure are contained.