Context: regional football match, 2 to 3 cameras, OTT broadcast and local channel TNT
Sport is the most demanding use case for REMI. It combines all the constraints: critical latency (the director must switch to the action, not after), multi-source synchronization essential to avoid switching artifacts, IFB commentator sensitive to delay, and zero tolerance to signal interruption. This is where the difference between well-designed architecture and DIY is measured in lost antenna seconds.
1.1 — Field architecture
On a stadium, the field device of a professional REMI sport production is based on hardware encoders dedicated by camera source. Each SDI camera (3G-SDI 1080p50) is connected to a Haivision Makito X4 or Matrox Monarch EDGE encoder configured in Low Latency mode: short GOP (1 second maximum), H.264 High or HEVC Main profile, H.264 High or HEVC Main profile, 4:2:2 Main, 4:2:2 10-bit, bitrate between 15 and 25 Mbps per source.
Field connectivity is the most critical variable. Three options coexist depending on the stadium:
Sport multi-source sync
In sports, synchronization between sources is critical because the director switches to the action — a lag of more than one frame between two cameras produces a visible artifact. The professional solution is genlock on each field encoder via an SPG reference signal distributed by cable, or the use of PTP/IEEE 1588 on the stadium's local IP network. Without genlock, micro jumps when switching occur systematically as soon as two sources have slightly offset timings.
1.2 — Production center architecture
At the remote production center, the 6 SRT streams are received by a Haivision StreamHub gateway or an AWS Elemental MediaConnect. Each stream is decoded, reclocked to a common reference (internal SPG or PTP), then presented to the production switcher in the form of synchronized signals.
The switcher used in demanding REMI sports productions is a hardware switcher with a remote control surface — typically a Grass Valley K-Frame XG with Kayenne or Karrera surface connected via IP to the frame installed at the production center, or a Ross Acuity in a similar configuration. The switching latency is then less than one frame (20 ms in 1080p50), identical to a conventional physical control system.
The sports graphics (scores, timer, statistics) is managed by a Chyron Prime or Vizrt Viz Engine server connected to the production network, with a control surface operated from the center. The integration of live data (sports federation API, real-time data flow) does not change compared to a physical control room — it is simply hosted in the same place as the remote control room.
1.3 — Workflow IFB commentators
The commentator is often physically present at the stadium — in a press box or a commentary booth. It receives its program signal (the “world” — the ambient sound + video program) via a dedicated IFB feedback stream. In a REMI sport architecture, this IFB feedback uses the same network link as the contribution, in the opposite direction.
The total IFB latency — field to production to field — is typically 300 to 600 ms in a well-optimized REMI workflow. It's audible: an unprepared commentator will tend to talk about himself. The operational solution is twofold: brief the commentator in advance on the existing delay, and use a delay management system that partially compensates for the feedback by advancing the IFB mix by a fixed value measured during pre-event tests.
1.4 — The “law”: recording and broadcasting sports events
In the sports broadcast world, “law” refers to the recording and broadcasting of events covered by exclusive audiovisual rights — championship matches, federal competitions, licensed events. This is the most demanding use case of REMI sport: the technical constraints described in the previous sections (latency, genlock, IFB) apply in their entirety, in addition to specific contractual and regulatory obligations.
Law-specific constraints
Broadcast under law requires an uncompromising technical channel. End-to-end latency must be controlled below 300ms to ensure synchronicity with federal score systems and data flows. Field encoders must be certified for transporting protected content, with AES-128 or AES-256 encryption enabled on SRT links — a frequent contractual requirement for rights holders. Signal redundancy is non-negotiable: an unwanted cut in a competition under law can generate contractual penalties.
The REMI architecture for sports law faithfully reproduces the requirements of a physical control system: hardware encoders with genlock (section 1.1), remote hardware switcher (section 1.2), dual encoder redundancy on each key source, and a dedicated fiber or 5G campus contribution link guaranteed. Cloud-native REMI — a software platform on shared infrastructure — is generally insufficient for this type of production: variable latency and the absence of a service guarantee (SLA) are incompatible with the obligations to distribute exclusive rights.
Sports law — non-negotiable technical requirements
End-to-end latency ≤ 300 ms • AES-128/256 encryption on SRT links • Dual encoder redundancy mandatory • Guaranteed network SLA (dedicated fiber or 5G campus) • Certified broadcast hardware encoders • Genlock SDI on all sources • Genlock SDI on all sources • Remote hardware switcher (latency < 1 frame)
1.5 — The “outlaw”: interviews, press conferences and debriefs
Ex-law refers to all content produced around the sporting event but outside the scope of exclusive broadcasting rights: interviews with players or coaches, pre-and post-match press conferences, editorial debriefs, media flashes in mixed zones, media flashes in mixed zones, social media content and OTT platforms, club content. This segment now represents a growing part of broadcast sports production, especially for digital media, club chains and federations that manage their own distribution.
Lighter technical requirements, a fully adapted native REMI
Unlike productions under law, non-legal content accepts higher latencies without impacting editorial quality. A mixed interview or press conference does not require a genlock between sources, no dedicated hardware switcher, and the IFB does not have the critical nature of a live commentator on action. The risk of signal interruption has no contractual consequences.
It is precisely this profile that cloud-native REMI — and in particular BenaNative — best covers. A post-match press conference can be produced from a room adjacent to the stadium with a minimal kit: a smartphone or a lightweight camera connected to SRT via 4G or the stadium's Wi-Fi, a microphone, and a cloud platform for simultaneous production and distribution to partner channels. The remote operator receives the stream, adds a graphic banner with the speaker's name, and distributes to YouTube, the club's OTT platforms, and pool feeds for accredited media — all without an additional technician on site.
BenaNative: a natural positioning on sports law
BenaNative is particularly suited to these off-law productions for several converging reasons. Its cloud-native architecture natively integrates mobile application capture (iOS/Android), low-configuration SRT encoding and multi-destination distribution from a unified interface — without heavy field infrastructure. The integrated graphic features (name overlay, club logos, banners) meet the usual needs of a press conference or debrief without using an external graphics engine.
The typical scenario: a Ligue 1 or Ligue 2 club produces its own content for its YouTube channel and social networks. After the match (covered by law by a third party broadcaster), the club's production manager activates BenaNative from the dedicated iPhone, frames the press conference from the stadium press room, and the remote operator in a virtual control room manages the production and the simultaneous broadcast — without any broadcast equipment on site other than the iPhone and a compact microphone. The operational cost is incomparable to that of conventional production.
1.6 — Summary table: REMI sport
Context: reporter on the go, 1 to 2 sources, live stream integrated into a news
Field journalism is the most common use case of REMI in newsrooms. It preceded the acronym itself: the first systems deployed in 2009 were already REMI before their time. The main constraint is not latency or synchronization—it's the reliability of the signal on an unpredictable network, and the ability of the journalist-cameraman to operate the entire technical chain alone.
2.1 — The JRI field kit
The standard equipment of a JRI (journalist-image reporter) in REMI news configuration is evolving rapidly with the democratization of broadcast-grade smartphones. According to the editors, two levels of kit coexist.
Professional kit (TV newsrooms)
Professional JRI kit cost
Bonding transmitter: 3,000—6,000 € + SIM data subscription 200—400 €/month. The bonding transmitter is the most expensive and the most critical component: it guarantees the continuity of the signal by aggregating several operators simultaneously.
Light kit (JRI mobile, web, corporate)
2.2 — Network management in real conditions
The main technical challenge of REMI news terrain is not encoding — it's managing the network in hostile environments: demonstrations with cellular saturation, rural areas with poor coverage, building interiors, buildings, tunnels, basements. Professional bonding transmitters (Haivision, LiveU, TVU) manage this variability in real time with proprietary algorithms that dynamically distribute the bitrate between the available interfaces.
Operational rule: the contribution bitrate must be at least 20% lower than the measured available bandwidth. Broadcast at 8 Mbps on a link that displays 10 Mbps available means taking a high risk of freezing at the slightest peak of network congestion. Experienced operators set up their transmitters at 5—6 Mbps in H.264 for live news, leaving enough room to absorb variations.
2.3 — Integration into the writing workflow
On the control side, the JRI field streams arrive in a centralized reception gateway — often a Streamhub server for Haivision, LiveU Studio or TVU Grid — which presents all active field connections in a unified interface. The on-call journalist can monitor signal quality (bitrate, SIM signal strength, audio level) from this interface, and alert the JRI in case of problems via the IFB channel.
The integration into the JT flow (for a duplex) is done like any studio source: the JRI flow is assigned to a switcher input bus, and the director can call it on the antenna exactly as he would call a satellite set. From the point of view of editorial workflow, the REMI JRI is now perfectly integrated into the production routines of major newsrooms.
2.4 — Summary table: JRI news
Context: international conference, 4 sources, simultaneous multi-destinations
Corporate events are the natural playground for cloud-native REMI platforms. The constraints are less severe than in sports or news: no critical genlock, no complex IFB, generally acceptable latency of a few seconds, and often more flexible budget on the software platform part. On the other hand, graphic richness, simultaneous multi-destination and ease of operation for non-specialist broadcast teams are becoming key criteria.
3.1 — Event field architecture
The field configuration for a high-end corporate conference generally consists of 3 to 5 sources: main stage camera, room camera (overview of the audience), prompter/podium camera, presentation screenshot (HDMI capture card → SRT), and sometimes a corridor or backstage camera for cut shots.
The presentation screenshot deserves special attention. It is often done via an HDMI capture card (Elgato 4K60 Pro, AVerMedia Live Gamer 4K) connected to the presentation laptop. This source is encoded in SRT by software (OBS, VMix) on the same laptop or a dedicated PC. The risk: if the presenter changes machines or restarts his software, the source disappears from the workflow. The best practice is to use an HDMI splitter between the presenter's laptop and the capture card, and to provide a replacement source (emergency static slide) in the switcher.
3.2 — Real-time graphics and layout
Graphic design is often the job that distinguishes careful event production from a simple stream. In a cloud-native REMI workflow, graphics can be managed in two ways:
3.3 — Multi-destination and simultaneous distribution
One of the most concrete advantages of cloud-native REMI in event planning is the ability to simultaneously distribute to multiple destinations without additional infrastructure. A single stream produced in the cloud can be simultaneously sent to:
This multi-destination is managed by the cloud switcher itself, without additional re-encoding on the operator side. The platforms each impose their bitrate, resolution and codec profile constraints — you must check compatibility beforehand and provide an output profile adapted to each destination.
3.4 — The particular case of hybrid events
The hybrid event — face-to-face + remote participants by videoconference — has become the post-2020 norm. It introduces additional complexity: how do you properly integrate Zoom, Teams, or WebRTC flows into a broadcast-grade REMI workflow?
The standard solution is Virtual Camera Output: Zoom or Teams exports its video stream to a virtual camera (NDI Virtual Camera, or OBS Virtual Camera) which is captured by the cloud switcher like any NDI source. The quality is limited to the resolution and codec of the videoconferencing platform (720p in H.264 for standard Zoom, 1080p in Teams Premium), with an additional latency of 200 to 600 ms. For important interventions, prefer a direct SRT connection from the remote speaker's room, which bypasses the video platform and regains broadcast quality.
3.5 — Summary table: corporate events
Comparative summary: which workflow for which case?
The three use cases analyzed reveal clearly distinct architectural families. The matrix below summarizes the choice criteria to quickly guide an architectural decision.
Conclusion: the right architecture does not exist, the right compromise does
These three cases illustrate a fundamental principle: there is no universal REMI architecture. Live sport requires radically different compromises from corporate events, even if both use SRT as a transport protocol. Confusing the two—deploying a lightweight cloud-switcher to produce a soccer match, or investing in genlock hardware encoders to broadcast a YouTube conference—generates either antenna incidents or a waste of budget.
The key is to start from business constraints — acceptable latency, IFB criticality, synchronization requirements, source volume — to go back to the architecture, and not the other way around. Articles 1 and 2 in this series provided the tools to assess each component; this article showed how they fit together into real workflows. The fourth and final article maps market solutions to help you make a concrete choice among the available offers.
Cross-cutting point of vigilance
Whatever the use case, the full-scale production test — complete repetition with the real signal, under real network conditions — is non-negotiable. Surprises always arrive at details that the technical specifications do not anticipate: a network switch that throttles the SRT speed, an encoder firmware that is incompatible with the gateway, a Zoom stream whose delay exceeds what the talent can handle in IFB.
