¶ What is IPMX
IPMX (Internet Protocol Media Experience) is an open, royalty-free professional AV networking standard spearheaded by AIMS (Alliance for IP Media Solutions). It democratizes top-tier, broadcast-grade uncompressed transmission technology, adapting and tailoring it specifically for the ProAV market. In short, IPMX is the universal language of the future professional AV industry.
¶ Core Technologies of IPMX
¶ ST 2110-based
The fundamental bedrock of IPMX is the SMPTE ST 2110 standard. Its most defining characteristic is Essence Separation: it deconstructs video, audio, and ancillary data into distinct, independent streams for transmission over the network.
This means you can route video exclusively to a large-screen display and audio exclusively to a sound system without the need for complex de-embedding at the endpoint. This architecture provides unparalleled routing flexibility.
¶ AMWA NMOS Suite of Specifications
IS-04 (Discovery & Registration): Plug-and-Play. Once a new device is connected to the network, it automatically registers with the server, announcing: "Who I am, and what signals I can transmit."
IS-05 (Device Connection Management): This protocol is responsible for establishing connections between encoders and decoders, enabling seamless, millisecond-level signal switching.
¶ Visually Lossless Compression: JPEG-XS
Native ST 2110 is uncompressed, offering flawless image quality but requiring massive network bandwidth (for instance, uncompressed 4K60 needs approximately 12Gbps, necessitating 25GbE switches). To allow IPMX to operate on more cost-effective Gigabit(1GbE) networks, the standard incorporates JPEG-XS compression technology.
What is JPEG-XS? It is the next-generation international standard for lightweight compression. Its defining features are visually lossless quality (where degradation is imperceptible to the human eye) and Ultra-low Latency (with encoding/decoding speeds at the sub-millisecond level, i.e., less than 1ms).
JPEG-XS can compress video at a ratio of approximately 10:1, enabling high-quality 4K signals to be transmitted over standard Gigabit Ethernet while maintaining near-zero latency.
While JPEG-XS is an integral component of the IPMX standard, current COEX devices supporting IPMX primarily focus on "Uncompressed / Native Quality" high-end transmission solutions, therefore, JPEG-XS is not currently supported.
¶ Custom Extensions Designed Specifically for ProAV
Asynchronous signal compatibility: Broadcast standards require extremely precise frame rates (e.g., a strict 59.94 Hz), whereas the frame rates produced by PC graphics cards are often variable. IPMX has been specifically optimized to address this discrepancy, enabling seamless ingestion of irregular computer-generated signals.
¶ Automatic Synchronization Without PTP Clock
It incorporates a flexible asynchronous synchronization mechanism, enabling precise audio–video alignment even in standard network environments without a PTP hardware clock. This capability fundamentally removes the reliance of professional AV systems on costly IT infrastructure, substantially reducing both deployment costs and configuration complexity.
¶ Core Advantages of IPMX (Uncompressed Architecture)
Under network conditions supporting 10 GbE / 25 GbE or higher, systems based on the uncompressed IPMX standard represent the current state of the art in professional audiovisual transmission and exhibit the following four principal advantages.
- 100% pixel-perfect image quality: Abandon any form of image compression algorithms and directly transmit raw uncompressed data streams. Completely eliminate color banding, blurred text edges, or mosaic artifacts in high-motion scenes, perfectly preserving 4:4:4 chroma sampling and HDR high dynamic range.
- True absolute zero latency: Without the computational processes of encoding and decoding, the waiting time of traditional algorithms is eliminated, achieving end-to-end latency at the microsecond level (equivalent to the time of a few video scan lines). For demanding scenarios requiring perfect hand-eye synchronization (such as esports and microsurgery), the experience is equivalent to directly plugging in an HDMI cable.
- A truly open standard: Unlike certain proprietary 10Gb protocols (such as SDVoE) that rely on dedicated chips from a single vendor, IPMX is an open international standard. Any manufacturer can develop devices based on standard FPGA or SoC platforms, giving the industry stronger overall vitality and freeing system scalability from single-vendor limitations.
- Flexible routing with inherent separation: Inheriting broadcast-industry principles, video, audio, and auxiliary data (such as control signals) exist as independent IP packets within the network. There is no need for embedding and de-embedding audio as in traditional systems; audio and video can be freely routed and scheduled independently.
¶ The Differences and Connections Between IPMX and ST 2110
One of the most core advantages of the IPMX architecture is that it does not require a redesign of the underlying hardware; it can directly reuse existing SMPTE ST 2110 hardware interfaces.
¶ The Core Protocol Stacks are Completely Identical
Identical Encapsulation Formats: Whether dealing with uncompressed video (ST 2110-20), audio (ST 2110-30), or ancillary data (ST 2110-40), IPMX is completely consistent with ST 2110 in terms of data plane packetization rules and RTP (Real-time Transport Protocol) header structures.
Hardware Transparency: This means that existing ST 2110 hardware interfaces—whether based on FPGA, ASIC, or SmartNICs—require absolutely no changes to their underlying hardware logic or register configurations when decapsulating or encapsulating IPMX media streams.
¶ Differentiation in Control Plane and Software Architecture
The proprietary features introduced in IPMX, as compared to ST 2110, primarily consist of extensions at the control plane or higher protocol layers. These can be implemented via firmware upgrades or software stack updates without requiring modifications to the underlying baseband processing hardware:
NMOS Device Discovery and Routing: IPMX mandates the use of AMWA NMOS (e.g., IS-04, IS-05) for device management and connection routing. This relies entirely on software-based network signaling interactions executing on the device's CPU control system.
EDID Handshake and Management: The handling of resolution adaptation for endpoint displays is similarly intercepted and processed by the software control layer.
¶ Downward-Compatible Clock Synchronization Mechanism
SMPTE ST 2110 imposes stringent requirements on clock synchronization, strictly relying on PTP (Precision Time Protocol, ST 2059) to achieve nanosecond-level synchronization across the network. Because broadcast-grade hardware is inherently designed to meet these rigorous demands, it can accommodate IPMX effortlessly:
Relaxed Timing Requirements: IPMX introduces asynchronous transmission capabilities, enabling operation over standard IT networks without the presence of a PTP grandmaster clock.
Downward Compatibility: From a hardware logic perspective, utilizing hardware designed for strict clocking to process data streams with relaxed clocking requirements constitutes downward compatibility. Existing ST 2110 hardware interfaces seamlessly adapt to the permissive timing environment of IPMX, while remaining capable of providing broadcast-grade, high-precision synchronization when required.
¶ Why the RX Endpoint Requires IPMX Over Native ST 2110
While the underlying format of the uncompressed video stream transmitted via IPMX is identical to native broadcast ST 2110-20, IPMX introduces substantial modifications at the receiver (RX) device to address commercial integration pain points. The differences between the two directly dictate the product's usability.
| Key Parameter | Native Broadcast-Grade SMPTE ST 2110 Receiver | High-End ProAV IPMX Receiver (RX) |
|---|---|---|
| Clocking Mechanism & Fault Tolerance | Highly Stringent: Strict network reliance on a flawless PTP grandmaster. Ingesting non-standard signals (e.g., PCs) makes the RX highly susceptible to signal loss (black screens) or frame tearing. | Robust Asynchronous Tolerance: Features built-in, flexible clock recovery and buffering mechanisms. Seamlessly accommodates asynchronous sources with non-standard frame rates, ensuring continuous, stable RX output. |
| Device Discovery & Control | Manual Configuration: Requires broadcast engineers to manually assign multicast addresses and author SDP files. Prohibitively complex for standard IT personnel. | Plug-and-Play (NMOS): The RX automatically registers with the controller upon connecting to a 10GbE switch. Signal subscription is executed via simple drag-and-drop on a web GUI. |
| EDID Management | None: Broadcast standards do not account for endpoint display resolutions. | Fully Supported: The RX performs EDID handshakes with downstream displays or LED controllers to ensure optimal output resolution. |
¶ Side-by-Side Comparison of Mainstream AV Protocols
| Feature/ Protocol | IPMX (Uncompressed Profile) | SDVoE | NDI | Dante AV |
| Ecosystem & Licensing | Open standard (Royalty-free) | Proprietary alliance (Reliant on a single ASIC vendor) | Proprietary protocol (Controlled by NewTek/Vizrt) | Proprietary protocol (Licensed by Audinate) |
| Underlying Architecture | Broadcast-grade SMPTE ST 2110 | Proprietary ASIC | Software-algorithm driven | Proprietary hardware/software |
| Bandwidth Requirements | Scalable from 1GbE to 100GbE | Strict 10GbE requirement | ~150–250 Mbps | 1GbE |
| End-to-End Latency | < 0.1 ms (Microsecond level, true zero latency) | ~0.1ms (100 µs) | ~16ms (~1 frame) | ~8ms(~0.5 frames) |
| A/V Decoupling | Fully supported (Native essence separation) | Limited | Limited | Strong (Native Dante audio integration) |
| Core Advantages | Universal interoperability, broadcast-grade quality, flexible architecture | Uncompressed 10G video quality | Rich software ecosystem, strong WAN/internet routing capabilities | Unified audio and video management |
Navigating the current AV-over-IP landscape reveals that despite the multitude of protocols, all technologies fundamentally grapple with complex trade-offs across four key dimensions: bandwidth, latency, image quality, and openness.
- The NDI & Dante AV Compromise: These protocols trade away pristine image quality (via high-ratio compression) and real-time performance (adding distinct millisecond latency) to function easily on basic networks. They are viable for everyday conferencing and commercial streaming but struggle in high-stakes, zero-margin-for-error environments like command center video walls or surgical displays. Additionally, their proprietary nature introduces hidden licensing fees that are ultimately borne by the customer.
- The SDVoE Trap: While SDVoE delivers on ultra-low latency and lossless video, it is crippled by single-chip vendor lock-in. Because the core technology is controlled by a solitary manufacturer, it introduces unacceptable supply chain risks for government, military, and critical infrastructure projects, completely stripping the customer of long-term pricing leverage.
- The IPMX Paradigm Shift: IPMX acts as the ultimate "best-of-both-worlds" disruptor. Backed by the authoritative Alliance for IP Media Solutions (AIMS), it is a rigorously open standard that breaks the chains of proprietary protocols and single-vendor hardware. Built on a true broadcast-grade foundation, IPMX delivers guaranteed, seamless interoperability across diverse brands and ecosystems.
¶ 7. IPMX Deployment Scenarios
¶ xR Virtual Production and Film Production
Key IPMX Capabilities:
Flawless Synchronization: Strict phase alignment between camera shutters, real-time rendering engines (such as Unreal Engine), and LED screen refresh cycles is mandatory. IPMX employs PTP (IEEE 1588) to deliver nanosecond-precision timing, completely eradicating on-camera artifacts like scan bands, visual tearing, or flickering (Genlock over IP).
Ultra-Low Latency: Dynamic shifts in background perspective during camera movement demand instantaneous rendering updates. The sub-frame latency inherent to IPMX guarantees exact temporal correlation between the camera tracking data and the LED volume output.
¶ Broadcast Studios and News Center Video Walls
Key IPMX Capabilities:
Lossless Image Quality: IPMX supports uncompressed transmission, ensuring pristine color fidelity on large screens under rigorous studio lighting conditions, entirely free from compression artifacts.
Decoupled Audio/Video Routing: Inheriting the core architecture of ST 2110, IPMX transmits video, audio, and ancillary data as independent multicast streams (native essence separation). Video streams can be routed directly to LED controllers, while audio streams are routed independently to audio mixing consoles, eliminating the need for cumbersome embedding and de-embedding processes.
¶ Smart City and Security Command & Control Centers
Key IPMX Capabilities:
Limitless I/O Expansion: Traditional hardware-based video wall processors are constrained by physical chassis slot limits (e.g., a fixed 144x144 matrix). With IPMX, provided there is sufficient network switch bandwidth, any networked IP camera or desktop feed can be dynamically routed via the NMOS protocol to any location on the LED wall, seamlessly supporting windowing, roaming, and overlapping layouts.
Multi-Display Frame Synchronization: When multiple LED sender cards receive discrete sections of an image, the IPMX network synchronization mechanism guarantees that high-speed moving objects (such as dynamic maps or high-speed rail monitoring feeds) do not experience misalignment or visual tearing when traversing sender card boundaries.
¶ Large-Scale Live Events, Concerts, and Stadiums
Key IPMX Capabilities:
Streamlined Cabling Infrastructure: Replaces heavy, distance-limited HDMI, DisplayPort, or SDI cable bundles with standard 10GbE/25GbE fiber optic networks. A single fiber optic cable can transmit multiple 4K or even 8K signals to LED screens positioned anywhere across a stage or venue.
High-Reliability Seamless Redundancy: IPMX supports hitless redundancy based on SMPTE ST 2022-7 (Seamless Protection Switching). By transmitting identical data streams simultaneously across two physically isolated network paths, the LED wall is guaranteed zero milliseconds of blackout or stutter—even in the event of an active cable being severed or a switch failing.
¶ Utilizing IPMX with COEX Equipment
IPMX-Supported Equipment: MX2000 Pro, MX6000 Pro
Input Cards: MX_4CH 1-Channel ST 2110 (25G) Input Card [100G version under development]
¶ Video Source Configuration
¶ Manual Configuration
Destination IP: Enter the multicast IP address to which the transmitter (TX) is outputting the video stream. Note that this is neither the local IP address of the TX nor the receiver (RX). Functionally, when the TX initiates the stream, it routes the video to this specific destination IP—similar to creating a "group chat" (e.g., 239.0.20.20) and continuously broadcasting video into it for others to join.
Port: Enter the corresponding port number (e.g., 5004).
Source IP: If your network utilizes IGMPv3 for Source-Specific Multicast (SSM), enter the actual unicast IP address of the transmitter here. If using Any-Source Multicast (ASM), this field is typically left blank or set to 0.0.0.0.
Verify that parameters such as resolution, frame rate, and color space precisely match those of the transmitting source.
¶ SDP Import
Click Load SDP to load the .sdp session description file generated by the transmitting node. The system will automatically extract and configure all relevant stream data, including video resolution, multicast IP, and port assignments.
If manual verification is required, the .sdp file can be opened in any basic text editor. The specific lines corresponding to the destination IP, port number, source IP, and source formatting parameters are outlined below:
¶ Automated Routing via NMOS
Beyond the manual provisioning of SDP files or multicast parameters within the VMP ecosystem, the primary strength of IPMX lies in its interoperability with third-party NMOS control software for global system orchestration. Utilizing standard interfaces like the Riedel NMOS Explorer allows for streamlined "drag-and-drop" stream routing:
Locate the desired video stream (TX) within the Senders directory.
Drag the selected sender and release it over the designated destination node (RX) in the Receivers directory.
The system will automatically establish the connection, and the controller will get the image.
¶ 1-to-4 Channel Mode Switching
The MX_4CH 1-Channel ST 2110 (25G) Input Card features dynamic interface channel mapping. The module can be provisioned to run in either a dedicated 4K UHD configuration (1 × 4K) or subdivided into four distinct Full HD channels (4 × FHD).
¶ NMOS Registration & Discovery
¶ Control Interface Selection
ST 2110 SFP1: Selecting "ST 2110" utilizes the physical port on the input card to handle NMOS registration traffic.
ETHERNET: Selecting "ETHERNET" utilizes the dedicated network port on the device's main control card for NMOS registration, entirely bypassing the ST 2110 input card's port.
¶ Discovery Method Selection
MDNS (Multicast DNS): The device sends a multicast message across the local area network (LAN)—essentially asking, "Where is the NMOS Registration Server?". As long as the device and the server reside on the same subnet, they will discover each other automatically. However, the limitation is that multicast traffic cannot cross routers or different VLANs by default.
DNS-SD (Unicast DNS Service Discovery): Operating similarly to how a web browser resolves a website, the device sends a direct, unicast query to a standard DNS server on the network. The DNS server then responds with the precise IP address and port of the NMOS Registration Server.
STATIC: This disables all automated discovery protocols. When selected, you must manually enter the exact IP address and port number of the NMOS Registration Server into the VMP software.
¶ Primary/Backup Optical Port IP Configuration
¶ DHCP
When configured for DHCP, the RX fiber interface dynamically leases its network parameters—including the IP address, subnet mask, and gateway—from the network's designated DHCP server.
¶ Static IP
When set to Static mode, the network parameters for the fiber interface (IP address, subnet mask, and default gateway) must be manually and explicitly provisioned.
¶ PTP Configuration
¶ Parameter Configuration
Domain: The Domain acts as a logical group or channel" for the PTP network. Multiple independent PTP clock systems can operate simultaneously on a single physical network, kept completely isolated by assigning them different Domain numbers. Devices will only listen to and synchronize with other devices sharing their exact Domain. The standard value range is typically 0 to 127.
Log Sync Interval: This determines how frequently the master clock broadcasts Sync messages to the slave devices on the network. In the referenced Matrox PTP settings, a value of -3 represents an interval of 2-3 seconds (which equals 0.125 seconds). Expressed as a frequency, this means the system sends 8 messages per second (8Hz).
Log Delay Req Interval: This dictates how often slave devices proactively send Delay_Req messages back to the master clock. These messages are used to measure the round-trip network path delay, allowing for precise temporal compensation. The setting of 1 in the Matrox example represents an interval of 21 seconds, which equals 2 seconds (or 0.5Hz, meaning one message every two seconds). This interval does not need to be as frequent as the Sync message. In large-scale networks, overly frequent requests from hundreds of endpoints simultaneously can overwhelm the master clock.
¶ PTP Status Monitoring
Leader/Follower Status: This indicates the current device's role within the PTP network. "Leader" acts as the time source, while "Follower" receives the time. All TX and RX endpoint devices should operate as Followers. The Leader role should be fulfilled by a core network switch or a dedicated PTP timing server (Grandmaster). This is a read-only status and cannot be manually changed in VMP.
Master Clock ID: This is a globally unique identifier (often based on a MAC address) that tells you which device is currently acting as the "boss" dictating the standard time across the network. This is a read-only parameter. Ensure that the Master Clock ID displayed across all TX and RX interfaces is completely identical.
Synchronization Status: This is a read-only parameter indicating the current sync phase:
Locked: The device is fully synchronized with the master clock, ensuring seamless, artifact-free AV transmission.
Locking: The device has just powered on or joined the network and is fine-tuning its internal clock. This alignment process typically takes anywhere from a few seconds to nearly a minute.
Unlocked: Critical error. The device cannot locate the master clock, or network jitter/latency is too severe to achieve synchronization. You will likely experience video stuttering, screen tearing, or a complete loss of the video feed.
Offset from Leader: This represents the time difference, measured in nanoseconds, between the device's internal clock and the master clock's standard time. It is normal for this value to constantly fluctuate slightly between positive and negative numbers. This is a read-only monitoring metric.
¶ FEC Configuration
FEC (Forward Error Correction) is a feature that adds redundant data to the video stream at the transmitting end. This allows the receiving end to automatically recover lost data in the event of minor network packet loss. This feature can be toggled on or off within the VMP software.
For FEC to function correctly, your network configurations must align perfectly:
If the physical network switch port connected to the input card has FEC enabled, you must also enable it within VMP to activate the error-correction protection.
Additionally, the transmitting device (TX) must have FEC enabled; if the TX is not sending redundant data, enabling FEC on the receiving end (VMP) will have no effect.
¶ IGMP Configuration
IGMPv2: The receiver (RX) tells the network switch, "I want to subscribe to the multicast channel 239.1.1.10, and I will accept the video feed regardless of who is sending it."
IGMPv3: The receiver (RX) tells the network switch, "I want to subscribe to the channel 239.1.1.10, but I only want to receive the feed if it is coming directly from the transmitter (TX) with the IP address 10.10.130.211."
We consistently enhance and refine the content of our Wiki articles.
If you find any mistakes or errors, please contact us.
Your continuous feedback and support will help us further improve our products and content.