IPMX H.265 vs NDI-HX3 for PTZ Cameras: Why ProAV Deserves an Open Alternative

Vadim Shilov

Head of Broadcasting & Telecom at Promwad

NDI dominates the PTZ camera segment in ProAV — not because it is the best technology available, but because it showed up first with a complete, easy-to-adopt package. Meanwhile, IPMX already has the architecture to deliver an open, multi-vendor alternative using the same H.265 codec that NDI-HX3 relies on — yet the H.265 profile is still being finalized, no formal certification event has tested it, and no developer toolkit exists to make adoption frictionless.

This article examines what IPMX can and cannot do for PTZ cameras today, where the gaps are, and what the industry needs to build to give ProAV vendors a genuine choice between proprietary convenience and open-standard control.

Table of contents

1. PTZ Cameras: NDI's Strongest Foothold in ProAV

2. What IPMX Actually Supports Today — And What It Doesn't (Yet)

3. NDI-HX3 Under the Hood

4. The JPEG-XS Question

5. H.265 Inside IPMX

6. Latency, Jumbo Packets, and the "Good Enough" Threshold

7. The UC Platform Question

8. The Toolkit Gap

9. What Needs to Happen

10. Conclusion
 

1. PTZ Cameras: NDI's Strongest Foothold in ProAV

If you ask a ProAV integrator what NDI is for, the most likely answer is PTZ cameras.

Not production switchers, not graphics engines — cameras. PTZ cameras are where NDI made its deepest mark because the value proposition is immediate: plug a camera into a standard Ethernet switch, discover it on the network, and start streaming. No SDI cabling, no dedicated infrastructure, no specialized IT knowledge.
 

Digital Media In IP. Source: IPMX Marketing and Communications Update. Feb 2025

NDI-HX3, the latest compressed format from Vizrt, doubled down on this advantage. It uses H.264 or H.265 encoding with a short GOP to deliver 1080p60 at roughly 20–50 Mbps with glass-to-glass latency under 100 ms. For conference rooms, houses of worship, lecture halls, and corporate events — the bread and butter of PTZ deployment — this is more than enough.

The result is that NDI has become the default IP protocol for PTZ cameras in ProAV. Not because it is technically superior, but because nothing else offers the same combination of speed, simplicity, and ecosystem tooling.

The question the industry is now asking: does it have to stay this way?
 

2. What IPMX Actually Supports Today — And What It Doesn't (Yet)

IPMX is built on SMPTE ST 2110 and AMWA NMOS, extended by the VSF TR-10 series of technical recommendations. As of early 2026, the two fully certified IPMX profiles cover uncompressed video (TR-10-2) and JPEG-XS compressed video (TR-10-11). The first 48 products from ten manufacturers — including Panasonic, Matrox, Evertz, and intoPIX — were officially certified at the inaugural IPMX testing event in Geneva in January 2026 and unveiled at ISE 2026 in Barcelona.
 

IMPX Conformance Structure. Image credit: AIMS

But H.265 is not absent from the IPMX roadmap — far from it. VSF TR-10-7 provides the RTP transport framework for compressed video within IPMX, explicitly supporting codecs beyond JPEG-XS, including H.265 and H.264. A February 2025 VSF presentation lists an HEVC video profile among the target IPMX profiles alongside uncompressed, JPEG-XS, and AVC. Products like the Matrox VION-NX gateway already advertise H.265 support within the IPMX framework.

What has not yet happened is formal certification. The H.265 profile has not gone through the same multi-vendor testing and certification process that validated the first 48 IPMX products in Geneva. There is no published test plan specific to H.265 interoperability, and integrators cannot yet look up H.265-certified devices in the IPMX registry.

The gap, then, is not architectural — it is procedural. The transport mechanism exists. The profile is in active development. Early products are already shipping. What remains is the final push: completing the profile document, building the test plan, and running a certification event that gives the industry the same confidence in IPMX H.265 that it now has in IPMX uncompressed and JPEG-XS.

This distinction matters. The industry conversation often frames IPMX H.265 as a theoretical possibility. The reality is that it is an emerging capability — closer to deployment than most ProAV professionals realize.
 

IPMX Product Certification. Image credit: AIMS
 

3. NDI-HX3 Under the Hood: What PTZ Manufacturers Actually Get

NDI-HX3 is effective in the PTZ segment not because of any single technical advantage, but because Vizrt has assembled a complete package around it.

The codec layer uses H.264 or H.265 with a short GOP — typically around 20 frames — balancing compression efficiency against decode latency. At 1080p60, a typical HX3 stream requires 20–50 Mbps depending on scene complexity, fitting comfortably within a 1 GbE network. Glass-to-glass latency is specified at under 100 ms, with real-world measurements often in the 60–80 ms range. For most PTZ use cases — remote camera feeds, preview monitoring, confidence monitors — this is well within acceptable limits.
 

Table: NDI HX3 h.265 (8bit 4:2:0). Bandwidth & Framerate

Source: NDI HX3 Stream Specifications

Beyond the codec, NDI provides automatic discovery via mDNS, tally signaling, bidirectional metadata for PTZ control, and a free suite of desktop tools (NDI Studio Monitor, NDI Screen Capture) that let end users validate setups without purchasing additional software.

For PTZ manufacturers, integration means licensing the NDI Advanced SDK through Vizrt, which is required for encoding HX3 natively on hardware. The basic NDI SDK remains royalty-free for receiving and decoding, but sending HX3 streams — the core function of a PTZ camera — requires a commercial license with volume-based pricing. The exact terms are negotiated per vendor, which introduces commercial uncertainty that some manufacturers find uncomfortable.
 

Image source: Technical Info & Product Marketing Guidelines for NDI HX3

The deeper structural concern is ecosystem control. NDI is not an open standard governed by a multi-vendor body. It is a proprietary specification owned and evolved by a single company. Every SDK update, every format change, every certification requirement flows from Vizrt. For manufacturers building products with five- to ten-year lifecycles, this creates a dependency that open standards are specifically designed to avoid.
 

4. The JPEG-XS Question: Right Codec, Wrong Segment?

JPEG-XS is the compression codec that IPMX has formally certified and actively promotes. On technical merits, it is impressive: visually lossless quality at compression ratios of 2:1 to 10:1, end-to-end latency measured in lines rather than frames, and deterministic constant bitrate behavior that maps cleanly onto ST 2110 timing models. For studio production, LED wall processing, and high-end AV installations, JPEG-XS is a genuine step forward.

But for PTZ cameras in typical ProAV environments, JPEG-XS presents a cost-structure mismatch.

The codec requires dedicated silicon. Today, the primary source of JPEG-XS encoder/decoder IP cores is intoPIX, a Belgian company whose technology underpins much of the IPMX compressed video ecosystem. While intoPIX offers proven, high-quality implementations, the practical effect is that PTZ manufacturers face a licensing and integration path that routes through a single IP vendor — ironically echoing the same single-vendor concern that critics raise about NDI.

JPEG-XS silicon adds meaningful BOM cost to a PTZ camera. For a conference room camera selling at $2,000–5,000, this cost is harder to absorb than it is for a $30,000 broadcast production switcher. PTZ manufacturers operate on tighter margins and higher volumes, and every dollar on the encoder side competes with spending on optics, sensors, and mechanical pan-tilt assemblies.

The result is a perception gap: IPMX's certified compression path is optimized for quality tiers above where most PTZ cameras compete, while the compression tier that PTZ cameras actually need — efficient H.264/H.265 with manageable latency — remains outside the formal IPMX certification framework.
 

5. H.265 Inside IPMX: The Missing Profile

This is where the opportunity sits.

H.265 hardware encoding is now commodity technology. SoCs from Ambarella, HiSilicon, Rockchip, and others have shipped HEVC encoders in millions of surveillance and PTZ cameras for years. The silicon is mature, inexpensive, and power-efficient. A PTZ manufacturer choosing H.265 encoding today is not making a technology bet — it is using a thoroughly proven building block.

IPMX's transport layer is already capable of carrying H.265 streams. ST 2110-22 defines the mechanism for constant-bitrate compressed video over RTP, and the TR-10-7 draft outlines how compressed codecs beyond JPEG-XS could be accommodated within the IPMX framework. The NMOS discovery and connection management layer (IS-04/IS-05) is codec-agnostic by design: it registers senders and receivers by media type and capability, not by specific codec identity.

The H.265 profile is already taking shape within the VSF TR-10 framework, and early implementations exist in shipping products. What is still needed is the last mile of formalization: finalizing the profile document with specific encoding constraints (Main profile, defined levels, GOP structures, bitrate ranges per resolution), publishing a corresponding test plan, and running H.265-specific certification events so that integrators can specify IPMX H.265 devices with the same confidence they now have for uncompressed and JPEG-XS products.

Creating this profile would not require reinventing the IPMX architecture. It would mean defining a constrained, interoperable subset of H.265 — much like NDI-HX3 constrains H.265 to specific GOP lengths, bitrate ceilings, and latency targets — and wrapping it in the same NMOS-based discovery and connection management that already works for uncompressed and JPEG-XS streams.

HEVC patents holders: MPEG LA, Access Advance, and Velos Media

The licensing landscape for H.265 does add complexity. HEVC patents are held across three separate pools — MPEG LA, Access Advance, and Velos Media — with per-unit royalties that vary by product category. But PTZ camera manufacturers using H.265 today already navigate this licensing structure for their existing RTSP and NDI-HX3 implementations. Moving H.265 into IPMX does not introduce new patent exposure; it reuses an obligation that manufacturers have already accepted.

6. Latency, Jumbo Packets, and the "Good Enough" Threshold

One of the most pragmatic observations in the original discussion was about acceptable latency. For remote PTZ camera feeds where IMAG (image magnification for live screens) is not required, two to three frames of delay are perfectly acceptable. This covers the vast majority of PTZ deployments: corporate boardrooms, classrooms, houses of worship, event overflow rooms, and remote production feeds.

NDI-HX3 targets this exact window, specifying glass-to-glass latency under 100 ms. An IPMX H.265 profile could match or improve upon this if the specification accounted for a few practical network-layer considerations.
 

Ethernet frame with variable length payload. Jumbo frames have payloads > 1500 bytes.

Jumbo frames are one such consideration. Standard Ethernet MTU of 1500 bytes forces high-bitrate video streams into many small packets, increasing per-packet overhead and switch processing load. Enabling jumbo frames (typically 9000-byte MTU) reduces packet count significantly, lowering both CPU interrupt load on camera SoCs and switch forwarding overhead. The bandwidth cost is negligible; the latency benefit is measurable, particularly at 4K resolutions where per-frame data volumes are substantial.

Most managed switches deployed in ProAV environments already support jumbo frames. The barrier is not hardware — it is documentation and default configuration. An IPMX H.265 profile that explicitly recommended jumbo frame support and provided configuration guidance for common switch families would remove a real source of deployment friction.

The broader point is that an IPMX H.265 profile does not need to compete with JPEG-XS on latency. It needs to compete with NDI-HX3 on latency — and that is a much more achievable target.
 

7. The UC Platform Question: Teams, Zoom, and the Standard That Gets Chosen

NDI has a presence inside Microsoft Teams and Zoom, though the integration is narrower than it might appear. Teams supports NDI output — allowing a production team to pull individual participant video feeds out of a Teams call as NDI streams for external mixing. Zoom offers a similar capability. In both cases, NDI acts as a bridge between the UC platform and external production tools, not as the primary media transport within the platform itself.

NDI works in Microsoft Teams and Zoom as a bridge between the UC platform and external production tools

This integration exists because NDI offered a ready-made, easy-to-adopt SDK at the moment when UC platforms needed a way to interface with professional video workflows. It was a timing advantage, not a deep architectural commitment. Neither Teams nor Zoom relies on NDI internally for media transport; both use their own optimized WebRTC-derived or proprietary stacks.

For IPMX to enter this space, the approach would likely not involve replacing NDI inside UC platforms directly. Instead, it would mean ensuring that IPMX-capable PTZ cameras and encoders can interoperate cleanly with UC environments through standardized interfaces — USB, HDMI capture, or lightweight gateway devices that bridge IPMX streams into the formats UC platforms already consume.

The more strategic path is to ensure that the same PTZ camera can serve both workflows without requiring separate protocol stacks or hardware SKUs. A camera that outputs IPMX H.265 natively, while also supporting a secondary NDI-HX3 or USB output for UC compatibility, would give integrators the flexibility they need today while positioning the installation for open-standard migration over time.
 

8. The Toolkit Gap: What IPMX Can Learn from NDI's Playbook

One of NDI's most underappreciated advantages has nothing to do with codecs or latency. It is the free toolset.

NDI Tools — Studio Monitor, Screen Capture, Webcam Input, and others — give any user with a laptop the ability to discover, preview, and route NDI streams without purchasing additional software. For integrators evaluating a PTZ camera, this means a zero-cost validation path: plug in the camera, open Studio Monitor, confirm the stream works. For end users, it means basic monitoring and recording are available out of the box.

IPMX has no equivalent today. Validating an IPMX stream currently requires either vendor-specific software, professional test and measurement tools, or enough ST 2110 expertise to set up a receiver manually. This is entirely appropriate for broadcast engineers commissioning a production facility, but it creates a steep ramp for the ProAV integrator who needs to demonstrate a PTZ camera to a facilities manager in a conference room.

The original commenter's suggestion — a free IPMX multi-viewer, mobile capture apps for iPhone and Android, and a reference toolkit for PTZ manufacturers — is not a luxury. It is an ecosystem prerequisite.

Building such a toolkit would serve two audiences simultaneously. For integrators and end users, it would make IPMX tangible: something you can download, run, and immediately see working.

For PTZ manufacturers, a reference implementation — sample code, tested SoC configurations, NMOS registration examples — would dramatically reduce the engineering effort required to build an IPMX-compliant camera. NDI's adoption in the PTZ segment accelerated precisely when the SDK became easy enough that a firmware engineer could have a working prototype in days rather than weeks. IPMX needs to match that velocity.

AIMS and the broader IPMX community have the technical credibility to deliver this. The question is whether the initiative is prioritized alongside profile development and certification — because without accessible tooling, even a perfect H.265 profile will struggle to gain traction against NDI's frictionless onboarding experience.
 

9. What Needs to Happen: A Practical Roadmap

Turning IPMX H.265 from an architectural possibility into a deployable alternative to NDI-HX3 requires coordinated action across several groups. None of the individual steps is technically unprecedented — but they need to happen in sequence and with enough momentum to reach critical mass.

From AIMS and the IPMX working groups:

The foundation is already in place: TR-10-7 defines the compressed video transport framework, and an HEVC profile is listed among VSF's target specifications. The priority now is to finalize this profile with specific, testable encoding constraints — main profile, Level 4.1 or 5.1, defined GOP structures, bitrate ceilings per resolution — and publish it as a formal TR-10 profile document with the same rigor applied to the uncompressed and JPEG-XS profiles.
 

IPMX Product Qualification and Certification Requirements (PDF)

A corresponding test plan must follow, enabling manufacturers to certify H.265 products through the same multi-vendor events that validated the first 48 IPMX devices in Geneva. Alongside the profile, AIMS should invest in the reference toolkit: an open-source IPMX receiver/viewer application, mobile discovery and preview apps, and a PTZ manufacturer integration guide with sample NMOS registration flows.

From PTZ camera manufacturers:

Manufacturers already shipping H.265-capable SoCs are closer to IPMX compliance than they may realize. The encoding silicon is in place. The primary integration work is on the control plane: implementing NMOS IS-04 for device registration and IS-05 for connection management, packaging H.265 streams into ST 2110-22 RTP transport, and supporting PTP-based timing at whatever precision level the IPMX profile requires.

For manufacturers currently building NDI-HX3 products, much of the encoding pipeline is directly reusable — the codec is the same; only the discovery, transport, and control layers change.

From integrators and end customers:

The market signal matters. Integrators who specify PTZ cameras for enterprise, education, and live event projects can accelerate this transition by including IPMX compatibility in their RFPs and tender documents — even as a future-ready option alongside current NDI support. When manufacturers see procurement language shifting, engineering roadmaps follow.
 

A real-life example: in 2021, Collabora added the H.265 coder and decoder to i.MX 8M processor for smart surveillance PTZ cameras

10. Conclusion: The Standard That Shows Up

The ProAV industry's experience with AV-over-IP has taught one consistent lesson: the technology that wins is not always the most elegant. It is the one that shows up — with working products, accessible tools, and a clear adoption path.

NDI showed up first in the PTZ segment, and it earned its position through practical execution. The ecosystem is real, the tools are free, and the integration path is well-documented. None of that should be dismissed.

But the structural limitations of building an entire industry segment around a single vendor's proprietary protocol are also real. Licensing terms change. SDK conditions evolve. Roadmaps shift according to one company's commercial priorities rather than the industry's collective needs. Every manufacturer that has experienced a unilateral change to an NDI license term or SDK requirement understands this tension.

IPMX offers a credible alternative — one backed by open governance, multi-vendor certification, and an architectural foundation that has already proven itself in broadcast. What it has not yet offered for the PTZ segment is a complete, turnkey path: the right codec profile, the right tooling, and the right ease of adoption to match what NDI delivers today.
 

The pieces are closer than many in the industry realize. H.265 silicon is commodity. IPMX transport and discovery are certified and shipping. The certification infrastructure is operational. What remains is the focused effort to assemble these pieces into a PTZ-specific package and put it in front of the manufacturers and integrators who need it.

At Promwad, we work with ProAV and broadcast hardware manufacturers at exactly this level — helping teams navigate codec selection, SoC integration, and protocol stack implementation for AV-over-IP products.

If you are evaluating IPMX, NDI, or hybrid architectures for your next PTZ camera or encoder platform, we would be glad to compare notes.

Reach Out