Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×

Ready for the software-defined future

TVBEurope talks to NDI's Miguel Countinho to hear how the protocol is redefining broadcast connectivity by combining video, audio, metadata, and control into a single, accessible ecosystem

How does NDI work alongside other IP protocols? 

NDI was designed to replace traditional, hardware-centric video infrastructures with a software-defined, IT-based approach. In many installations, it has already replaced SDI for signal transport, routing and production workflows, allowing video systems to use standard networks, general-purpose computing platforms and software applications instead of dedicated video hardware. 

Miguel Coutinho

NDI can also coexist with other IP-based systems through gateways, converters, software applications and APIs. This allows organisations to introduce NDI where it provides the greatest operational or economic benefit, while preserving existing investments during the transition. 

NDI’s distinctive value is that it is not limited to compression or media transport. It combines video, audio, metadata, discovery and control within a single, accessible ecosystem. A key part of this approach is the broad availability of the NDI SDK, which gives developers and manufacturers direct access to the technology and enables them to integrate NDI into software, hardware and cloud services without  having to build an entire media-over-IP stack from scratch. 

How is NDI actively optimising its protocol specifically for cloud-native environments in order to handle the massive bandwidth and multi-cloud routing demands of Tier 1 networks? 

NDI is well suited to cloud-native production because it was designed as a software-defined technology rather than as a virtualised version of traditional broadcast hardware. 

A complete production workflow can be built using software applications running on general-purpose computing platforms. Even NDI High Bandwidth uses SpeedHQ, a codec designed for efficient CPU-based processing, without requiring dedicated FPGA hardware or specialised media appliances. 

NDI is also unicast by default, which aligns naturally with the way virtual networks, subnets and cloud security policies are typically designed. For discovery, the NDI Discovery Service provides a centralised alternative to mDNS, avoiding the dependence on multicast discovery that is often unavailable or impractical in cloud environments. 

NDI Audio makes it possible to create software-based mixing, routing,  intercom and commentator systems within the same infrastructure. Video, multichannel audio and metadata can all be handled through a common ecosystem.

The protocol does not require a mandatory facility-wide PTP infrastructure, which removes another layer of specialised broadcast complexity. Its broadly available SDK also allows developers and manufacturers to build cloud applications, services and complete production workflows without having to create an entire media-over-IP architecture from scratch. 

As NDI scales into legacy Tier 1 control environments, what are you doing to ensure interoperability with current broadcast control systems? 

With NDI 6.2 and 6.3, we responded directly to broadcasters asking for greater visibility and control across large NDI infrastructures. These releases expanded the information available about senders and receivers and provided the APIs needed to monitor connections, endpoint capabilities and network behaviour.  

NDI has done its part by providing the required APIs and infrastructure capabilities. Manufacturers, developers and control-system partners must now act, invest and bring products to market that make  these capabilities operational for broadcasters. 

However, NDI should not be judged only by how closely it can reproduce legacy broadcast workflows. It represents a fundamentally different, software-defined production model, rather than a software adaptation of traditional hardware infrastructure. 

For Tier 1 broadcasters, the strongest measure of their value is cost per output. NDI makes it possible to create additional feeds, language versions, digital channels and production outputs without duplicating the dedicated hardware and infrastructure traditionally associated with each one. Its mature ecosystem of software, hardware and development tools therefore gives broadcasters a practical way to reduce the marginal cost of producing and distributing more content. 

How would you convince a major network executive that NDI is reliable enough for their most important live broadcasts? 

We do not need to convince the market that NDI can be used for professional live production. Its adoption has already demonstrated that. A very large number of broadcasters use NDI in their daily production workflows, including Tier 1 organisations operating high-profile and business-critical services. 

NDI’s responsibility is to continue investing in the underlying technology: the SDK, media processing, discovery, control, metadata and the APIs that allow the ecosystem to build increasingly capable solutions. We do not design every camera, switcher, graphics system, recorder or production platform that uses NDI. Those products are created by manufacturers and software developers. 

For this reason, the reliability of a complete deployment depends not only on NDI, but also on the quality of the products selected, the network architecture, system design and operational practices.  Broadcasters should therefore evaluate the complete solution they intend to deploy, rather than treating NDI as a single product in isolation.

If a broadcasting company decides to adopt NDI for their main infrastructure, how difficult is it for  their engineering team to learn and adapt, and what kind of support does NDI offer during that transition? 

The first requirement is an open mind. NDI represents a fundamentally different approach from the hardware-centric broadcast infrastructures many engineers have worked with throughout their careers.  The transition becomes much easier when teams are willing to understand NDI on its own terms, rather than trying to reproduce every legacy workflow and operational model. 

Engineers also need a solid foundation in IT and networking. NDI has made discovery, connection management and day-to-day operation remarkably simple, but it cannot eliminate the need to understand how a network works. Teams should be comfortable with basic concepts such as IP addressing, switching, bandwidth, subnets and network configuration. 

The technology itself is highly accessible, and organisations can introduce it progressively rather than changing an entire infrastructure at once. Our AVIXA-certified NDI courses support that transition, taking engineers from the fundamentals through the design, optimisation and troubleshooting of complete NDI  workflows. 

In large-scale, multi-camera live environments, how does NDI ensure phase-accurate synchronisation across dozens of sources without a traditional Precision Time Protocol (PTP) master clock infrastructure? 

The first question should be whether phase-accurate synchronisation is actually required by the workflow. 

PTP can provide extremely precise timing, but it also introduces additional infrastructure, configuration, specialised knowledge and operational cost. That investment is justified for applications that genuinely  require sources to be locked to the same phase, but many production workflows simply need frames to  be correctly aligned when they are switched, mixed or processed. 

NDI takes a pragmatic approach. Sources can operate independently, carrying timing information that allows receiving applications to buffer and align them at the point of use. This may introduce a small and predictable amount of latency, but it avoids imposing a facility-wide timing infrastructure on every deployment. 

There are use cases where precise source synchronisation. Those requirements should be identified and engineered accordingly. But making PTP mandatory for every workflow adds cost and complexity to  solve a problem that many users do not actually have.

What have you learnt from Tier 2 projects that could crossover to Tier 1? 

The traditional boundaries between broadcast and the rest of the  professional video market are disappearing. 

Younger audiences have not stopped watching video. They have stopped thinking in terms of television channels, fixed schedules and traditional broadcast distribution. They expect content to be available on any platform, in multiple formats and whenever they choose to watch it.

This is also changing production. Organisations often described as Tier 2, including sports organisations, corporations, universities, esports producers and independent content creators, are now producing professional live content for large and sometimes global audiences. They often need multiple versions, platforms and outputs, while operating with smaller teams and more constrained budgets. 

These markets have adopted software-defined production, standard computing platforms and IT  networking very quickly because they need flexibility, scalability and a lower cost per output. 

The lesson is that innovation is no longer moving in only one direction. Many of the production models developed outside traditional broadcasting are now directly relevant to the future of broadcast itself. 

What haven’t we asked you about NDI and Tier 1 broadcasters that you think our readers should know? 

We should stop thinking of NDI simply as a Video-over-IP technology. NDI is fundamentally a connectivity technology: it connects devices, software applications and services, allowing them to discover each other, exchange information and interact bidirectionally. 

Video and audio are important, but they are only some of the data that NDI can transport. Metadata and control are equally significant because they allow an NDI-enabled environment to become an integrated production system rather than a collection of independent media sources. 

We sometimes joke that one day we could use NDI to switch on the coffee machine in our Lisbon office. The point is not the coffee machine itself, but the architectural potential: once devices and applications can discover, communicate and control each other through a common ecosystem, the possibilities for integration become enormous. 

This is also directly connected to cost per output. Better integration, automation and software-based control allow organisations to produce and manage more outputs without increasing infrastructure and operational costs at the same rate.