Le Remote Integration Model (REMI), parfois appelé "at-home production" dans la littérature anglo-saxonne, désigne un workflow broadcast dans lequel la capture vidéo et audio s'effectue sur site — plateau de sport, salle de conférence, terrain — tandis que l'ensemble de la production (commutation, mixage son, graphisme, réalisation) est réalisée à distance, dans un centre de production centralisé ou dans le cloud.
Ce modèle s'oppose radicalement au modèle traditionnel OB (Outside Broadcast), dans lequel un car régie complet — mélangeur, graphisme, son, monitoring, équipe technique — est transporté et déployé sur site pour chaque événement. Le REMI inverse la logique : on transporte les pixels, pas les personnes ni les équipements.
Trois convergences ont rendu le REMI viable à grande échelle : la banalisation des réseaux IP haute capacité (fibre, 5G), la normalisation du protocole SRT pour la contribution sécurisée sur internet public, et la disponibilité de switchers logiciels performants tournant sur infrastructure cloud standard. Avant ces trois éléments réunis, le REMI restait réservé à quelques grands acteurs disposant de liaisons fibre dédiées.
Comprendre le REMI, c'est comprendre le parcours du signal à travers sept couches distinctes. Chaque couche introduit une latence, une dépendance et des contraintes de qualité qu'il faut maîtriser.
2.1 — Couche 1 : la capture
Tout commence par les caméras. En environnement REMI professionnel, les sources vidéo sont des caméras broadcast standard (Sony, Ikegami, Grass Valley LDX) qui délivrent un signal SDI (Serial Digital Interface) en 3G-SDI (1080i/1080p) ou 12G-SDI (4K). Ce signal SDI, non compressé, représente environ 1,5 Gbps pour du 1080i — un débit totalement incompatible avec un transport IP sur internet public.
À ce stade entrent en jeu les encodeurs terrain, qui constituent le premier maillon critique de la chaîne REMI.
2.2 — Couche 2 : l'encodage terrain
L'encodeur hardware est le composant le plus stratégique du REMI terrain. Son rôle est double : compresser le signal SDI en un flux IP transportable, et l'encapsuler dans un protocole de transport adapté au réseau disponible.
Encodeurs hardware vs logiciels
Il convient de distinguer clairement deux catégories :
Point critique
Pour toute production broadcast mission-critique — journal télévisé, sport en direct, événement institutionnel —, l'encodeur hardware reste le standard incontournable. La différence ne se voit pas sur le flux lui-même, elle se manifeste lors des incidents réseau ou des variations de charge CPU : l'encodeur hardware continue, le logiciel s'emballe.
Codecs et profils
H.264 (AVC) reste le plus répandu en contribution REMI : excellent support matériel, faible latence d'encodage (mode "Baseline" ou "Low Latency"), bitrates de 5 à 50 Mbps selon la qualité cible. En 1080p50, un encodage broadcast-grade H.264 4:2:0 tourne autour de 15–25 Mbps ; en 4:2:2 10 bits, comptez 30–50 Mbps.
HEVC (H.265) offre une compression supérieure à qualité égale — typiquement 40 % de bitrate en moins par rapport à H.264 — ce qui le rend intéressant pour les liens 5G ou les connexions à bande passante limitée. En contrepartie, la latence d'encodage est légèrement supérieure et les exigences de traitement hardware sont plus élevées.
2.3 — Couche 3 : le transport IP
C'est ici que les protocoles entrent en jeu, et c'est souvent le point le moins bien compris de l'architecture REMI. Trois protocoles coexistent dans l'écosystème actuel, avec des usages très distincts.
SRT — Secure Reliable Transport
Développé par Haivision et versé en open source en 2017, SRT est devenu le protocole de référence pour la contribution REMI sur internet public. Son principe fondamental : emprunter les mécanismes de correction d'erreur de QUIC/UDP tout en ajoutant un chiffrement AES-256 et un système de retransmission sélective des paquets perdus (ARQ — Automatic Repeat reQuest).
SRT opère en mode caller/listener ou en mode rendezvous. La latence est configurable via le paramètre "latency" qui définit la fenêtre de buffer dans laquelle la retransmission peut s'opérer : plus la latence SRT est élevée (ex. 2 000 ms), plus le réseau peut être instable sans perte de paquets ; plus elle est basse (ex. 120 ms), plus le lien réseau doit être de qualité.
Règle empirique
La latence SRT doit être réglée à au moins 2,5 fois le RTT (Round Trip Time) du lien réseau. Sur un lien avec un RTT de 80 ms (Paris–Lyon par exemple), une latence SRT de 200–300 ms est un minimum raisonnable pour une production sans artefact. Sur des liaisons intercontinentales (RTT > 150 ms), prévoir 500–800 ms de buffer SRT.
NDI — Network Device Interface
Développé par NewTek (désormais Vizrt Group), NDI est un protocole LAN conçu pour la distribution vidéo haute qualité sur réseau local. NDI utilise TCP/IP et offre une qualité d'image exceptionnelle (proche du non compressé en NDI HX3) mais n'est pas adapté au transport sur internet public : il n'a pas de mécanisme de correction d'erreur sur réseau wan et sa bande passante peut atteindre plusieurs centaines de Mbps en qualité maximale.
NDI trouve sa place dans le REMI pour la distribution interne au centre de production : des flux reçus en SRT sont décodés et redistribués en NDI vers les postes de réalisation, les stations graphiques Vizrt, les multiviewers logiciels. C'est un protocole de studio, pas de contribution terrain.
SMPTE ST 2110
ST 2110 est le standard professionnel broadcast pour la distribution vidéo/audio non compressée sur IP. Il transporte vidéo (ST 2110-20), audio (ST 2110-30/31 AES67) et métadonnées sur des réseaux dédiés 10 ou 25 GbE avec précision PTP (IEEE 1588). C'est le standard des grandes régies broadcast qui ont migré de l'infrastructure SDI vers l'IP.
Dans un contexte REMI, ST 2110 n'est pas utilisé pour le transport terrain (trop exigeant en bande passante et en infrastructure réseau). En revanche, une fois les flux SRT reçus au centre de production, ils sont souvent décodés et redistribués en ST 2110 pour alimenter un switcher broadcast hardware — Grass Valley K-Frame, Sony XVS — qui opère nativement sur ce standard.
RTMP — Real-Time Messaging Protocol
Développé à l’origine par Macromedia pour le streaming Flash, le RTMP (Real-Time Messaging Protocol) est aujourd’hui omniprésent dans les workflows de distribution vers les plateformes de diffusion — YouTube Live, Twitch, Facebook Live, LinkedIn Live — ainsi que vers les encodeurs de diffusion OTT. Il s’appuie sur TCP, ce qui garantit la livraison ordonnée des paquets mais au prix d’une latence structurellement plus élevée que SRT : de 1 à 5 secondes en conditions normales, sans mécanisme natif de correction d’erreur adaptatif.
Dans une architecture REMI, le RTMP n’intervient pas (ou peu) au niveau de la contribution terrain — il est trop fragile sur des réseaux instables et ne supporte pas le chiffrement AES natif. Son rôle est principalement celui d’un protocole de sortie, en bout de chaîne : une fois le programme produit au centre de production, il est encodé une dernière fois (souvent en H.264, profil Baseline ou Main) et poussé en RTMP vers une ou plusieurs destinations de diffusion simultanées. Ce flux sortant RTMP est distinct du flux de contribution entrant en SRT — les confondre est une erreur d’architecture fréquente chez les équipes moins expérimentées.
2.4 — Couche 4 : le gateway et l'ingest cloud
Les flux SRT terrain arrivent dans un système de réception appelé gateway ou media server. Dans les architectures cloud, ce composant est souvent une instance de Haivision StreamHub, AWS Elemental MediaConnect mais aussi BeNarative tournant sur infrastructure cloud (AWS, Azure, GCP ou Akamai).
Le gateway a plusieurs responsabilités : décoder le flux SRT entrant, vérifier l'intégrité du signal (détection de perte de sync, monitoring des niveaux audio), et redistribuer le signal vers les composants de production — le switcher cloud, les serveurs graphiques, les systèmes d'enregistrement.
C'est également à ce niveau que s'effectue la conversion entre protocoles : un flux SRT peut être converti en RTMP pour alimenter une plateforme de streaming, en HLS pour une diffusion OTT, ou en NDI pour une régie logicielle.
2.5 — Couche 5 : la commutation et la production
Le switcher est le cœur de la production REMI. Deux grandes familles coexistent selon le niveau d'exigence.
Switchers hardware avec accès distant
Des constructeurs comme Grass Valley (AMPP avec K-Frame), Ross Video (Ultrix) ou Sony ont développé des architectures où le moteur de commutation reste un hardware dédié (ou un serveur optimisé), mais la surface de contrôle peut être déportée à distance via IP. L'opérateur travaille depuis son domicile ou un autre site sur une surface physique connectée en réseau au frame de commutation distant. Cette approche préserve toutes les qualités du switcher hardware : latence de commutation inférieure à la frame, keyers broadcast-grade, gestion des signaux SDI natifs.
Switchers cloud natifs
Des solutions comme TVU Producer Grabyo ou BeNarative proposent un moteur de commutation entièrement dans le cloud, opéré via navigateur web (et tablette et iphone pour BeNarative). Ces solutions sont plus légères à déployer mais imposent une latence de preview supplémentaire.
2.6 — Couche 6 : le retour plateau (IFB)
L'IFB (Interruptible Foldback) est le signal audio de retour envoyé dans l'oreillette du présentateur ou du journaliste terrain. C'est souvent le maillon négligé du REMI — et pourtant l'un des plus critiques pour les talents sur le terrain.
Dans un workflow REMI, l'IFB emprunte le chemin inverse du signal programme : le mixeur son au centre de production envoie un mix retour vers le terrain via un flux audio IP. La latence totale de l'IFB est la somme de la latence aller (terrain → production) et de la latence retour (production → terrain).
2.7 — Couche 7 : la synchronisation et le genlock
La synchronisation multi-source est le défi technique le plus sous-estimé du REMI. Dans une régie SDI classique, toutes les sources sont synchronisées via un SPG (Sync Pulse Generator) qui distribue un signal de référence Blackburst ou Tri-Level Sync à tous les équipements. Les encodeurs hardware acceptent ce signal de genlock, garantissant que toutes les caméras sont phase-alignées : commuter entre deux sources revient à commuter entre deux signaux parfaitement synchrones, sans artefact de commutation.
Dans un workflow REMI, cette synchronisation se complexifie considérablement. Chaque flux SRT arrive au centre de production avec une latence variable et non déterministe. Le gateway doit donc effectuer un reclocking : il reconstitue un timing de référence et resynchronise tous les flux entrants avant de les présenter au switcher. Selon la qualité du lien réseau, cette opération peut introduire des variations de timing (jitter résiduel) qui se traduisent par des micro-artefacts à la commutation.
PTP — IEEE 1588
Les architectures REMI les plus exigeantes utilisent le Precision Time Protocol (PTP/IEEE 1588) pour distribuer une référence de temps commune entre le terrain et le centre de production via le réseau IP. Les encodeurs compatibles PTP (Matrox Monarch EDGE, certains Haivision Makito) peuvent ainsi maintenir une synchronisation sub-milliseconde même sur des réseaux longue distance — une avancée majeure pour la production sport.
La notion de budget latence est centrale dans la conception d'un workflow REMI. Chaque composant de la chaîne contribue au délai total entre l'action sur le terrain et la commutation en régie. Ce délai cumulé est ce qui permet — ou empêche — certains types de production.
Ces chiffres ont des implications opérationnelles concrètes :
5.1 — La redondance réseau
Un workflow REMI professionnel ne peut pas reposer sur un seul lien réseau. La pratique standard est le bonding ou la redondance de liens : combiner plusieurs connexions physiques (fibre, 4G, 5G, satellite) pour garantir la continuité du signal même en cas de perte d'un lien. Des solutions comme Haivision LiveU, ou TVU Pack implémentent ce bonding avec des algorithmes de gestion de la qualité réseau en temps réel.
5.2 — L'audio multi-pistes
La gestion audio en REMI est souvent plus complexe que la gestion vidéo. En SDI, les pistes audio sont embarquées dans le signal vidéo (SDI embedded audio, jusqu'à 16 canaux en 3G-SDI). En IP, l'audio peut être transporté en embedded dans le flux H.264/HEVC, ou séparément en AES67 (ST 2110-30) pour les architectures les plus exigeantes. La synchronisation lip-sync est une préoccupation permanente : chaque étape de décodage/ré-encodage peut introduire un désalignement audio/vidéo qu'il faut monitorer et corriger.
5.3 — Le monitoring signal
En régie physique, le monitoring est omniprésent et immédiat : murs de moniteurs, waveform, vectorscope. En REMI, le monitoring à distance souffre de la même latence que le signal de production. Il est impératif de mettre en place un monitoring au plus proche de l'ingest — idéalement au niveau du gateway, avant toute commutation — pour détecter les problèmes de signal avant qu'ils n'atteignent l'antenne.
5.4 — Le tally système
Le tally est le signal qui indique aux caméramans quelle caméra est à l'antenne (voyant rouge = en direct). En REMI, ce signal doit traverser la chaîne en sens inverse du signal vidéo, avec la contrainte que sa latence doit être cohérente avec la latence de production pour que le caméraman voit son voyant s'allumer en même temps que sa caméra est effectivement commutée à l'antenne.
5.5 — La sécurité et le chiffrement
Transporter des contenus live non encore diffusés sur internet public est un vrai enjeu de sécurité. SRT avec chiffrement AES-256 est le minimum requis. Pour les productions très sensibles (avant-premières, événements institutionnels).
Le REMI n'est pas une technologie — c'est une architecture. Sa performance n'est pas déterminée par son composant le plus sophistiqué mais par son maillon le plus faible. Un encodeur hardware de dernier génération ne peut rien si le lien SRT est mal dimensionné. Un switcher cloud puissant ne corrigera pas un défaut de genlock en amont.
La bonne approche consiste à raisonner de bout en bout, en documentant le budget latence de chaque composant, en testant la synchronisation multi-source dans des conditions réseau représentatives, et en dimensionnant la redondance en fonction du niveau de criticité de la production.
Le prochain article de cette série aborde la question économique : comment calculer le TCO d'un workflow REMI et à quel seuil de volumétrie il devient financièrement justifiable face à une régie physique traditionnelle.
