Remote production and REMI decision guide for network, transport and core-IP choices

How it works

Site capture, timing and capture latency

At the venue, cameras and local audio sources are captured and presented as SDI or native IP signals — NDI, SMPTE ST 2022-6, or SMPTE ST 2110 depending on the infrastructure. Capture latency encompasses the camera sensor-to-output delay plus any SDI or IP interface processing, typically ranging from 1 to 10 ms per device, along with any frame-buffering introduced inside the encoder input stage.

For frame-synchronous operations across multiple cameras, PTP (IEEE 1588) provides the timing backbone. Within the production facility, PTP grand-master accuracy targets are typically below 1 µs. Across disciplined WANs, sub-millisecond alignment is the goal where network conditions permit. Without tight PTP discipline, multi-camera switching and lip-sync integrity degrade rapidly, making timing architecture a first-order design consideration rather than an afterthought.

Encoding and local processing latency

The encoding stage presents a spectrum of choices that directly trade bandwidth against latency and quality.

Uncompressed transport (SDI or ST 2110 essence flows) adds no coding delay but demands full-rate bandwidth — approximately 2.1–2.5 Gbit/s for a single 1080p50/59.94 ST 2110-20 video essence stream; an SDI-mapped ST 2022-6 stream carries the full 3G-SDI rate of roughly 3 Gbit/s.

Lightweight, low-latency codecs such as JPEG XS or intra-frame HEVC add sub-frame to single-frame delay. Hardware and FPGA-based encoders typically achieve 1–16 ms per encode/decode pair for these modes.

Higher-efficiency long-GOP codecs (HEVC, AV1) deliver significant bandwidth savings but introduce larger, more variable buffering — tens to hundreds of milliseconds depending on GOP structure, instance type, and whether processing runs on dedicated hardware or cloud software transcoders.

For predictable REMI operation, use fixed encoder operating points and profile locking. This ensures constant bitrate behaviour and deterministic delay, simplifying downstream buffer planning and network capacity allocation.

Network traversal and transport behaviour

The network segment between venue and central facility is where the most consequential engineering trade-offs occur.

Managed carrier links — private circuits, MPLS tunnels, carrier Ethernet services — provide deterministic latency and SLA-backed guarantees for packet loss and jitter. These are the preferred backhaul for high-density, premium REMI feeds where multiple camera channels must arrive reliably and in sync.

Unmanaged public internet links introduce variable latency, congestion, and packet loss. They require error-resilient transport protocols (compared below) and demand provisioning for higher effective bandwidth to accommodate FEC overhead, retransmission traffic, and variable congestion windows.

Regardless of network type, the key metrics to measure and continuously monitor are one-way latency (ms), jitter (ms), sustained and burst packet loss (%), available bandwidth per feed (Mbit/s), and MTU path stability.

Central processing, return feeds and round-trip considerations

The central production facility receives all camera feeds, performs switching, graphics insertion, branding, and generates programme output. It must also produce return feeds — programme confidence monitors, IFB (interruptible foldback) audio for talent, and tally/control signals — all of which add to the total round-trip latency.

A common architectural pattern separates the bulk camera contribution path (a heavy, one-way uplink) from the low-bitrate return path. Camera feeds may travel on managed backhaul with strict SLAs, while return intercom and confidence feeds use best-effort low-latency links or SRT/RIST tunnels. This asymmetric design reflects the different quality and bandwidth requirements of each direction.

For bidirectional remote control — robotic cameras, tally lights, engineering control — plan for symmetrical latency budgets and reserve deterministic control channels. Variable or excessive round-trip delay on these control paths makes remote camera operation impractical and degrades the director’s ability to call shots confidently.

Why it matters in broadcast

REMI’s value proposition is straightforward: centralised teams can produce more events with fewer on-site staff and less trucked equipment. But the engineering choices behind each deployment determine whether that promise is realised or undermined.

Viewer experience depends directly on latency management and synchronisation. A/V lip-sync errors, multi-camera timing mismatches, and delayed instant replays are all symptoms of poorly budgeted latency chains. Technical design controls these parameters, not operational workarounds.

Rights holders and broadcasters face contractual obligations around uptime and content security. Resilient transport design and encrypted contribution paths reduce the risk of blackouts or content leakage that can trigger financial penalties and reputational damage.

Operational agility comes from matching network type and transport protocol to event tier. A single central facility can support a premium, multi-camera sports production on managed circuits while simultaneously handling a lower-tier event over public internet with SRT — provided the architecture is designed to accommodate mixed-quality workflows efficiently.

Technical specifications and trade-offs

Understanding the quantitative parameters of each component in the REMI chain is essential for capacity planning and latency budgeting.

A single uncompressed 1080p50/59.94 ST 2110-20 video essence stream requires approximately 2.1–2.5 Gbit/s; SDI-mapped transport (ST 2022-6) carries the full 3G-SDI rate of roughly 3 Gbit/s. UHD-1 at 2160p50/59.94 requires approximately 8.5–10 Gbit/s over ST 2110-20, or 12 Gbit/s SDI-mapped.

JPEG XS achieves visually lossless compression at ratios between 4:1 and 10:1 depending on the selected profile and quality target — roughly 200–600 Mbit/s per 1080p50/59.94 stream and 0.8–2.1 Gbit/s for UHD. Encoder-decoder pair latency is typically sub-frame to a few frames, roughly 1–20 ms, making it well suited for contribution where bandwidth is constrained but low latency remains critical.

Low-latency HEVC in intra or low-GOP configurations delivers 1080p50/59.94 at 8–25 Mbit/s for high quality. UHD demands considerably more — 40–150 Mbit/s — depending on content complexity and bitrate targets.

When operating over public internet, budget 10–30% additional capacity beyond the nominal stream bitrate to accommodate FEC, retransmission, and variable congestion behaviour inherent to resilient transport protocols.

Protocol comparison

The mechanics behind ARQ recovery windows, FEC overhead, and receive-buffer sizing for SRT specifically are covered in depth in SRT Packet Loss in Live Video Contribution.

Protocol	Typical one-way latency profile	Packet-loss resilience	NAT/firewall friendliness	Typical REMI use case
RTP/UDP (plain)	Sub-frame to single-frame (lowest) in LAN/ST 2110	None (lossy)	Poor across NAT	ST 2110 inside managed LAN/WAN
SRT	Low to mid, tunable (sub-second to <200 ms)	ARQ + optional FEC; handles moderate loss	Good (UDP tunnel, NAT traversal)	Public internet contribution with low-latency goals
RIST	Similar to SRT; standardised low-latency profiles	ARQ + FEC; standardised resilience profiles	Good (designed for NAT traversal)	Contribution and backup over internet; interoperability focus
Zixi	Low to mid, tunable	ARQ + FEC; advanced resilience	Good (proprietary session and traversal)	Managed cloud distribution and contribution within vendor ecosystem
RTMP/HLS	Higher (200 ms to multiple seconds)	Application-level retry; not suited for packet loss	Excellent (HTTP-based)	Legacy contribution, preview, or non-live workflows

Latency budget decomposition

Total round-trip latency in a REMI workflow can be expressed as:

Round-trip latency = capture delay + encoder latency + network one-way latency + packet buffering/jitter compensation at decoder + central processing and frame alignment + return feed latency

Each segment must be individually measured and allocated. Practical planning assigns specific allowances — for example, capture 10 ms, encode 30–100 ms, network 30–150 ms, decode plus processing 20–50 ms — with margin reserved for failover scenarios.

Target budgets vary by use case:

• Director switching (near-live, low-latency REMI): Aim for total one-way latency of 150–400 ms, with 200–300 ms being a common operational target. This requires aggressive encoder settings, network one-way latency below 100 ms, and tight decoder buffers.

• IFB and director talkback: Target round-trip below 400–600 ms for acceptable conversational intercom. Achieving a sub-250 ms conversational experience typically requires managed low-latency paths or dedicated low-latency audio services.

Failover and resilience

Resilience in REMI is layered: path redundancy (dual-homed connections across different carriers, with hitless dual-path protection under ST 2022-7 or session-level failover in SRT and RIST), stream redundancy (an independent secondary encode as fallback), and operational failover (automated health probes on latency, loss, and buffer occupancy, with pre-defined cutover rules so switchover decisions are deterministic rather than dependent on operator reaction under pressure).

The design decisions behind these layers — path diversity and independence, per-flow versus per-packet bonding, active-active versus active-standby economics, FEC and ARQ selection, and the availability arithmetic for sizing redundant paths — are covered in depth in Path diversity, ARQ and active-active vs active-standby for resilient live contribution. Treat that article as the canonical reference for resilience design; this guide assumes its patterns when budgeting REMI links.

Related approaches and standards

• SMPTE ST 2110: Defines uncompressed, packetised professional media transport for LANs and disciplined WANs. It requires PTP synchronisation and deterministic network behaviour, making it the reference architecture for core facility interconnects.

• JPEG XS (ISO/IEC 21122): A visually lossless, ultra-low-latency, low-complexity codec designed for contribution and short-haul backhaul where reduced bandwidth is required without sacrificing latency performance.

• SRT and RIST: Resilient, low-latency transport protocols designed for unreliable networks. SRT has broad vendor adoption; RIST is an open standard targeting multi-vendor interoperability.

• NMOS (AMWA IS-04/IS-05): Provides discovery and connection management for IP media nodes, enabling device automation and orchestration in centralised REMI infrastructures.

• PTP (IEEE 1588): Delivers precise time synchronisation essential for multi-camera lip-sync and frame-accurate switching in ST 2110 workflows.

• MPEG-TS, HLS, CMAF: Distribution and contribution formats at higher latency, typically used for downstream delivery, preview monitoring, or non-time-critical workflows.

Architectural patterns for spanning on-premise SDI, on-premise IP, and cloud domains — the wider context REMI sits inside — are covered in Hybrid Media Workflows for Live Production and Contribution.

How Appear addresses this

Appear covers the two ends of the REMI contribution path — the venue and the receiving facility — rather than the production tools between them.

At the venue, X5 is the compact encoder and decoder for a flypack or a small fixed site. At the facility, X10 in 1RU and X20 in 2RU take the same module family at density: ECx110 for SDI I/O and ECx210 for ST 2110 and ST 2022-6, both encoding AVC and HEVC with ultra-low-delay modes, alongside JPEG XS modules for sub-frame, visually lossless contribution. Modules lock to PTP, so multi-camera alignment holds across the chassis.

For the backhaul itself, the platform uses hardware-accelerated SRT with ST 2022-7 protection across two independent network paths. One detail matters for latency budgeting: Appear’s SRT is an in-house implementation that recovers loss by ARQ rather than FEC, so the receive buffer is the parameter to size, not an FEC overhead percentage. L2 bonding is available with the SRT image in active-backup mode — path failover rather than bandwidth aggregation.

Every module publishes Prometheus metrics, so the one-way latency, loss, and buffer-occupancy discipline this guide describes runs on an operator’s existing time-series stack rather than in a separate pane.

FAQ

When should I use a managed carrier versus the public internet for REMI?
Use a managed carrier when you require deterministic latency, low jitter, predictable packet loss, and SLA support — typically for premium, multi-camera, high-quality events. Use public internet with resilient transports such as SRT or RIST for lower-tier events, temporary venues, or situations where cost or availability prevent dedicated circuits.

Can ST 2110 run across a WAN?
ST 2110 is designed for disciplined, low-jitter networks. It can operate across WANs only when the network provides PTP synchronisation and deterministic performance, often via managed circuits or latency-controlled carrier services. For general WAN transport, compressed formats with resilient protocols are the practical choice.

How does JPEG XS compare to uncompressed ST 2110 for REMI?
JPEG XS delivers visually lossless quality with significant bandwidth savings (4:1 to 10:1 compression) and sub-frame latency, making it suitable where WAN bandwidth is constrained but low latency is essential. Uncompressed ST 2110 requires far more bandwidth but eliminates coding artefacts entirely and simplifies central processing chains.

Which transport protocol gives the best interoperability?
RTP/UDP is the standard inside managed ST 2110 networks. For public networks, RIST targets open interoperability across vendors, SRT is widely supported and broadly deployed, and proprietary protocols such as Zixi offer ecosystem-specific tooling. Selection depends on vendor support and operational priorities.

How much bandwidth should I budget per camera feed?
Budget depends on format: an uncompressed 1080p50/59.94 ST 2110-20 stream requires approximately 2.1–2.5 Gbit/s; JPEG XS runs roughly 200–600 Mbit/s per 1080p feed (0.8–2.1 Gbit/s for UHD, depending on profile); HEVC at 1080p typically falls between 8 and 25 Mbit/s. Always add 10–30% headroom for FEC and network variance.

What target latency is realistic for director switching in REMI?
Practical low-latency REMI director switching typically targets one-way latencies of 150–400 ms. Tighter budgets are achievable with managed networks and sub-frame codecs but require disciplined end-to-end latency engineering.

How should I design failover for contributor links?
Use dual-path transport across different carriers, transport-level session failover via SRT or RIST or hitless dual-path protection via ST 2022-7, and stream redundancy with independent encoders — with automated health checks and pre-defined cutover rules established before the event goes live. The full design framework, including path sizing and availability estimation, is in Path diversity, ARQ and active-active vs active-standby for resilient live contribution.

Is PTP mandatory for remote production?
PTP is mandatory where sample-accurate timing and multi-camera ST 2110 switching are required. For compressed, asynchronous workflows, packet timestamping and alignment at the decoder can suffice, but PTP ensures the tightest possible synchronisation.

How do I handle return feeds for IFB and programme monitoring?
Return feeds are typically low-bitrate, low-latency streams carried on a separate path. Prioritise low jitter and small buffers for IFB audio, and consider dedicating a managed path or applying prioritised QoS treatment to return audio channels.

What monitoring metrics are essential for REMI operations?
Monitor one-way latency, jitter, instantaneous and sustained packet loss, available and consumed bandwidth, encoder and decoder buffer occupancy, and PTP clock offset and delay. Continuous visibility into these metrics enables proactive intervention before quality degrades on air.

Can cloud resources be used for central production?
Cloud processing is viable for REMI central production. However, factor in additional variable delay from virtualised infrastructure, instance cold-start times, and egress bandwidth costs. Use cloud regions with low latency to your central facility and pre-warm instances ahead of live events.

What security measures are recommended for REMI?
Use encrypted transports such as SRT’s built-in AES encryption or DTLS/TLS tunnels, enforce per-session authentication, implement network segmentation between production and corporate traffic, monitor for anomalies, and maintain secure key management practices. Protect both primary and failover paths equally.