Use-Cases

Open Source Meets Broadcast: OMT Challenges NDI in Low-Latency Video

Many have already heard of the OMT protocol—an open-source alternative to the proprietary NDIprotocol developed by the vMix team.

Both protocols are designed for low-latency video transmission over local networks.

At the core of NDI and OMT compression lies a variant of the Discrete Cosine Transform (DCT)—the same mathematical foundation used, for example, when saving images in the JPEG format. This approach allows the original gigabit video stream to be compressed 8–10 times with no perceptible loss in quality.

You might reasonably ask: why use a specialized compression scheme when universal codecs like H.264 or HEVC exist—and can transmit video not only over local networks but also over the internet?

The answer is straightforward: H.264 and HEVC do not tolerate multiple encode–decode cycles well. Each round of re-encoding introduces artifacts and irreversibly degrades image quality.

In contrast, NDI and OMT are specifically engineered for repeated use in production environments. You can route video signals between multiple devices and applications—without accumulating compression artifacts or noticeable quality loss.

Comparison Methodology

For this evaluation, we use our product SRTMiniServer, which can convert an incoming SRT stream into NDI and OMT—either simultaneously or individually.

The test is conducted in two phases:

  1. Six incoming SRT streams are converted exclusively to NDI, and system metrics are recorded.
  2. The same six streams are then converted exclusively to OMT (high), and identical measurements are taken again.

During testing, we assess:

  • CPU utilization during NDI and OMT encoding;
  • Network bandwidth consumption when 6 clients are simultaneously connected to output streams.

To ensure a fair and objective comparison, we deliberately feed both protocols a UYVY (4:2:2) video signal. This format is natively supported by both NDI and OMT, eliminating the need for color subsampling conversion and ensuring that performance differences reflect protocol behavior—not preprocessing overhead.

For example, if the input were NV12 (4:2:0), OMT would internally convert it to 4:2:2:4, while NDI would process the 4:2:0 signal natively. As a result, OMT would consume more bandwidth, skewing the comparison.

NOTE: The measurements without prior conversion are presented in the final section of this article.

We record the initial CPU consumption

no NDI, no OMT, only decode 6x1080@50p and convert to 422

Before test we have 45% CPU

NDI

6 x NDI encoding (no connected clients, so no bandwidth )

now we connect 6 clients (NDI Studio Monitor, macOS)

6 x NDI encoding, 6 x clients

Result for 6xNDI output: +12% CPU, 825 Mbs

OMT

6 x OMT(high) encoding (no connected clients, so no bandwidth )

now we connect 6 clients (OMT Video Monitor, macOS)

6 x OMT(high) encoding, 6 x clients

Result for 6xOMT(high) output: +11% CPU, 865 Mbs
OMT(low)

6 x OMT(low) encoding, 6 x clients

Result for 6xOMT(low) output: +9% CPU, 506 Mbs

Measurements Without Pre-Conversion: Balancing Efficiency and the Future

In our baseline test, we intentionally used a 4:2:2 video signal to eliminate any internal color subsampling conversions, ensuring the fairest possible comparison between NDI and OMT.

However, in real-world scenarios, most SRT streams arrive in a compressed format—typically H.264 with 4:2:0 chroma subsampling. Support for 4:2:2 in H.264 is rare, especially in common broadcast and IP delivery workflows.

In SRTMiniServer, such streams are decoded locally, yielding a 4:2:0 signal at the output. If no explicit conversion is enabled, this native 4:2:0 format is passed directly to both NDI and OMT.

This is where a fundamental difference in protocol philosophy becomes apparent:
  • NDI is optimized for today’s reality: it handles 4:2:0 natively and efficiently, minimizing network load and system resources—making it an excellent choice for established, performance-sensitive production environments.
  • OMT, by contrast, is designed with the future in mind. As specified in its documentation, it automatically upgrades incoming 4:2:0 content to 4:2:2:4, delivering superior color fidelity and compatibility with professional workflows where color accuracy is critical—such as studio production, virtual sets, or graphics-intensive applications like chroma keying.
Yes, this results in slightly higher bandwidth usage compared to NDI—but this is an intentional architectural choice, not a drawback. As network capacities continue to grow and visual quality expectations rise, this forward-looking approach becomes increasingly justified.

SRTMiniServer seamlessly supports both paradigms: it lets you leverage NDI where efficiency is paramount, and OMT where quality and readiness for next-generation standards matter most. Thanks to its intelligent, on-the-fly video processing during decoding, you gain true flexibility—without compromise.
2025-11-26 21:12