When to change formats

Do not change an NDI format in the middle of a production day because a source looks soft or a network graph spikes. Preserve the known working route, capture the symptom, and investigate after the show. A format switch can change endpoint processing, compatibility, and bandwidth enough to create a new failure that hides the original cause.

Schedule format changes with a test window and a clear success condition: every source discovered, correct audio mapping, stable record, expected monitoring delay, and no switch-port errors. Keep the previous working configuration written down until the new one survives a full rehearsal. This makes improvement a controlled change instead of a live gamble.

A decision worksheet for the network owner

Start with a source inventory, not a format preference. For each camera or application, write the needed resolution, frame rate, audio requirement, destination, and whether the source must be recorded, monitored, or controlled. Then identify every link it crosses: camera Ethernet, access point, edge switch, uplink, router, receiver computer, and any bridge. A single constrained link can determine the format choice even if the rest of the building has spare capacity.

Next, mark compatibility as confirmed only when it has been tested with the actual firmware and application. A vendor claim that a product supports NDI does not answer whether it sends or receives HX3 at your desired format. If the answer remains uncertain, choose a known working format for the event and treat the alternative as a later lab test. That avoids making a live program the compatibility experiment.

Finally, document the normal view of health. Name the source, expected frame rate, typical throughput, receiving application, and fallback. The operator does not need a network-engineering dissertation during a show; they need to recognize when a source is abnormal and know whether to restart it, switch to backup, or call the person who owns the network.

The direct answer

NDI High Bandwidth and NDI HX3 are different formats within an NDI workflow, not interchangeable badges for a generic IP camera. NDI identifies High Bandwidth with its SpeedHQ-based format and describes HX3 as an AVC or HEVC option designed for lower bitrate operation. The useful buying question is whether the whole route—from camera or encoder, through switches and Wi-Fi if present, to the receiver, switcher, recorder, and monitoring application—supports the format you intend to send.

For a fixed, wired control room with a well-understood gigabit network, High Bandwidth is often the straightforward production choice. For a route that must preserve bandwidth, especially one involving a supported camera or hardware endpoint on Wi-Fi or a limited network, HX3 can be attractive. That does not mean HX3 is a universal replacement or that High Bandwidth is wasteful. It means the network design should lead the decision.

NDI is a workflow, not one codec

NDI's documentation describes a networked video connectivity system that can carry video, audio, and metadata among supported products. That wider behavior is why a production team may value it: sources can appear in a switcher, graphics tool, monitor, or recording system without rebuilding every connection around an HDMI cable. But the convenience only exists where the particular products implement compatible NDI features.

Do not assume a device marked NDI handles every format, resolution, frame rate, discovery method, control feature, or encode direction. The current support matrix makes this point clearly: encode and decode capability varies by format and hardware class. Before purchasing a camera or bridge, read its own technical specification and confirm the exact receiver application. A one-line compatibility logo is not a substitute for that check.

Why High Bandwidth fits a planned LAN

High Bandwidth is compelling when the production can dedicate proper wired networking and wants quality and responsive source handling without treating compression efficiency as the main constraint. It can make sense for a control room with several cameras, graphics machines, recorders, and a multiview where the team owns the switches, cabling, addressing, and traffic policy.

The hidden requirement is capacity. Add the likely video flows, audio, control traffic, recordings, and ordinary network use. Then leave margin for bursts and operational mistakes. A gigabit link is not an unlimited shared bucket, and a cheap unmanaged switch is not automatically a production network. Test the actual camera count at the target frame rate, observe it during a long rehearsal, and avoid discovering a saturated uplink after the room fills with people.

Why HX3 fits constrained routes

NDI documents HX3 with H.264 and H.265 options and published reference bandwidth figures, including roughly 50 Mbps for 1080p60 H.265 and 84 Mbps for 2160p60 H.265. Those are useful planning references, not promises for every product or network. HX3 is most interesting when a high-bandwidth NDI flow would overwhelm a route but the endpoints actually implement the format.

That can suit a supported PTZ camera, mobile contribution device, or remote room where a lower bitrate is materially more realistic. It still needs a stable network. Wi-Fi contention, weak roaming, packet loss, and overloaded access points do not become harmless just because a format uses fewer megabits. Make the choice with sustained tests at the same time of day and in the same location as the show.

Latency is an end-to-end budget

Do not use an advertised format latency as the audience delay or assume one number settles a switching decision. Capture, camera processing, encoding, transport, buffering, decoding, the switcher, output encoding, platform delivery, and a viewer's player all contribute. NDI's own documentation distinguishes format behavior and endpoint capability; a specific device can add more delay than the format summary suggests.

Measure the route you will operate. Put a visible timer and an audible clap on the source, record the program, and compare camera, return monitor, and delivered stream. The goal is not an impressive headline number. It is a stable timing relationship that keeps cuts, speech, and return communication workable. If a remote guest is late, fix the route deliberately rather than randomly lowering buffers until it breaks.

Compatibility decides more than bandwidth

The support matrix should stop a common mistake: purchasing an HX3 source because the destination says NDI, then learning it only decodes a different format or resolution. Check encode versus decode, hardware versus software support, firmware version, licensing, operating system, and whether the target product exposes the input where you need it. A supported format in a vendor's application does not prove it is supported in every third-party switcher.

Build a one-page route sheet: source model and firmware, desired resolution and frame rate, NDI format, switch, receiver, recording destination, and monitoring path. Get a device from each category on the network before committing to a fleet purchase. This is less glamorous than comparing bitrates, but it is what prevents a format decision from becoming an event-day integration project.

A fair rehearsal plan

Run the number of sources you expect, at the real show format, for at least the duration of a meaningful segment. Change scenes, add graphics, start recordings, open multiview, and have someone move through the room if Wi-Fi will be used. Watch for dropped video, audio slips, discovery loss, processor load, and switch-port errors. Record the program so the crew can inspect faults that did not look obvious during the show.

Then remove one easy assumption. Disconnect a source, restart a receiver, temporarily reduce available network capacity, or swap to the backup camera. The useful result is a recovery runbook: who sees the error, who speaks to the talent, which backup is selected, and what viewers see. A format does not create that procedure; a rehearsal does.

Verdict

Use NDI High Bandwidth when you control a capable wired network and want an NDI-native production workflow without making bitrate the main compromise. Use HX3 when documented endpoint support and constrained network capacity make its lower-bitrate design valuable. Avoid choosing either based on a logo, a single bitrate figure, or a lab demonstration. The right fit is the route that your actual gear and crew can rehearse, monitor, and recover.

This is a desk-researched comparison, not a hands-on benchmark. The linked NDI documentation is the source of record for format behavior; individual product specifications remain the source of record for compatibility.

Quick answers

Frequently asked questions

Is NDI HX3 always better for streaming?

No. It is useful when a supported route needs lower bitrate. A wired production network with sufficient capacity may be better served by High Bandwidth.

Can an NDI device use every NDI format?

No. Confirm the model's encode and decode support, firmware, resolution, and application-specific behavior.

Can Wi-Fi be used for NDI?

It can be used when designed and tested carefully, but shared spectrum and roaming make it a higher-risk choice than a managed wired path.