Orchestrateur de production vidéo IP
La Dynamic Media Facility, du schéma à la régie.
Bobi.Studio pilote une chaîne de production vidéo complète sur un cluster de nœuds Docker, autour du bus MXL de l’EBU : la vidéo et l’audio y circulent non compressés de bout en bout, répliqués entre nœuds en RDMA. SMPTE ST 2110, SRT et RTMP cohabitent, source par source. Une seule interface pour déployer, câbler, contrôler et surveiller.
- Entrées
- ST 2110 · SRT · RTMP
- Sorties
- ST 2110 · UDP · SRT · WebRTC
- Plan de données
- MTL · DPDK · AF-XDP
- NMOS
- IS-04/05/07/09/12/14
- Synchronisation
- PTP IEEE 1588
- Licence
- GNU GPL v3
Ce que c’est
Un plan de contrôle. Les nœuds font le travail, le contrôleur sait ce qu’ils font.
Un contrôleur
Une application web centrale tient l’inventaire, déploie les conteneurs, garde la trace de ce qui est câblé à quoi, et surveille le parc en boucle. Elle n’exécute aucun traitement vidéo elle-même.
Des nœuds
Des serveurs Debian enrôlés, chacun avec son agent. Ils exécutent les conteneurs de production : ingest, composition, encodage, émission. On en ajoute un en une commande.
Un bus mémoire
Les images et le son ne transitent pas par le réseau à l’intérieur d’un nœud : ils vivent en mémoire partagée sur le bus MXL, la Media eXchange Layer issue des travaux de l’EBU. Entre nœuds, la réplication passe par RDMA.
Des plugins
Chaque traitement — multiviewer, mixer, encodeur, correcteur colorimétrique, convertisseur — est un plugin versionné indépendamment, qui tourne dans son propre conteneur. On l’installe depuis un catalogue, sans cloner un dépôt ni toucher au reste.
Le périmètre couvert va de la carte réseau au pupitre de régie : préparation de l’hôte, allocation multicast, synchronisation PTP, mesure des ressources, protocoles de contrôle broadcast, haute disponibilité du contrôleur.
La chaîne du signal
Un seul modèle : tout se raccorde au bus, rien n’est câblé en dur.
Un conteneur ne connaît pas ses voisins, seulement les flux qu’il consomme et ceux qu’il produit. Changer une source revient à changer un raccordement : la page Câbles montre la topologie réelle, bascule à chaud, et insère un convertisseur quand les formats ne correspondent pas.
C’est ce qui rend le ST 2110 optionnel. Le bus ne connaît que des essences vidéo, audio et données ; la façon dont elles entrent et sortent est affaire de conteneurs de bord. Une régie 2110 branche le moteur MTL ; une production distante entre en SRT et ressort en SRT, sans carte dédiée, sans PTP et sans multicast. Les traitements, le câblage, les macros et la supervision sont les mêmes dans les deux cas.
La console
L’état prime sur tout. Un conteneur dégradé se voit sans le chercher.

Trois thèmes, un seul produit : un sombre neutre pour le poste de travail, un clair pour le bureau en plein jour, un sombre chaud à accent ambre pour la régie. Le statut n’est jamais porté par la couleur seule : chaque badge a son libellé, lisible sur un écran de contrôle dégradé au fond d’une régie. Interface complète en français et en anglais.
Le parc en chiffres
Ce que couvre la distribution, aujourd’hui.
Ce qu’il parle
Les protocoles d’un environnement broadcast IP de production.
Cliquez sur un sigle pour savoir ce qu’il fait ici.
SMPTE ST 2110-20
Vidéo non compressée sur IP. Le moteur la reçoit et l’émet directement depuis la carte réseau, sans traverser le noyau, en progressif comme en entrelacé champ-natif.
ST 2110-30
Audio PCM sur IP, jusqu’à 8 canaux en L24 à 48 kHz. L’audio voyage dans son propre flux et se recâble indépendamment de la vidéo.
ST 2110-40
Données auxiliaires : timecode, sous-titres, AFD. Encodées selon la RFC 8331 et transportées dans un flux distinct, elles traversent la chaîne sans être régénérées.
ST 2022-7
Redondance de transport. Le même contenu part sur deux chemins et le récepteur reconstruit à partir des deux, sur deux ports ou sur deux chemins d’une même carte.
ST 2059 / PTP IEEE 1588
La synchronisation commune, sans laquelle il n’y a pas de chaîne mais seulement des flux. Chaque nœud se cale sur la référence PTP du site ; l’écart est échantillonné en continu et un décrochage lève une alerte.
AMWA IS-04
Découverte et enregistrement. Les conteneurs publient leurs émetteurs et leurs récepteurs auprès du registre du site, qui devient l’annuaire de la production.
IS-05
Gestion des connexions. Un contrôleur de routage tiers active et bascule les liaisons ; les descriptions de session sont produites et consommées des deux côtés.
IS-07
Event & Tally. Le tally est publié en NMOS à côté du TSL : une Source par flux et par niveau, alignée sur les flux MXL déjà exposés. Deux transports pour deux publics, le même état.
IS-09
System Parameters. Le domaine PTP de l’installation est publié une fois et lu par les équipements conformes, au lieu d’être réglé appareil par appareil — où un désaccord se manifeste par des symptômes qui ressemblent à tout sauf à un désaccord de domaine.
IS-12
Le modèle de contrôle exposé en WebSocket sur un port dédié, pour un pilotage événementiel.
IS-14
Le même modèle exposé en REST, avec sauvegarde et restauration en masse des propriétés d’un appareil.
MS-05-02
Le modèle d’objets lui-même : la description normalisée de ce qu’est un appareil et de ce qu’on peut y régler. IS-12 et IS-14 n’en sont que deux transports, au-dessus d’un modèle unique et partagé.
BCP-002-01
Groupement des ressources. Les émetteurs et les récepteurs d’un même appareil sont déclarés comme un ensemble, avec des indications de groupe stables dans le temps.
BCP-002-02
Identité d’asset : fabricant, modèle, numéro de série. Exposée depuis une source unique, partagée avec le gestionnaire d’appareil du modèle de contrôle.
BCP-008-01
Moniteurs de récepteurs. L’état de chaque Rx, flux présent, synchronisation, erreurs, publié en continu dans le modèle de contrôle.
BCP-008-02
La même chose côté émetteurs : ce qui part, et dans quel état.
SDP
Description de session : le format qui décrit un flux, sa définition, sa cadence et sa référence de synchronisation. Produit pour chaque émetteur, lu pour chaque récepteur.
SAP / SDP (RFC 2974)
Annonce et découverte de flux audio sur le réseau. C’est le seul mécanisme que partagent AES67, Ravenna et Dante en mode AES67 — aucun ne parle NMOS. Nos émetteurs s’annoncent, et les flux tiers découverts sont confrontés au format que le moteur sait recevoir et au domaine PTP de nos annonces.
IGMPv3
Affiliation multicast. Une adresse par flux, réservée de façon atomique par l’orchestrateur, et l’affiliation posée sur l’interface qui porte ce flux.
SNMPv3
Agent SNMPv3 en authPriv, en LECTURE SEULE, servi par le contrôleur actif. La MIB est une MIB de cluster : elle rend l’état agrégé du parc, pas celui d’une machine. Les traps sont un canal du service d’alertes.
Ember+
Arbre de contrôle publié sur les emplacements de production, adressable par un système de supervision tiers sans connaître les identifiants techniques internes.
TSL UMD 5.0
Échange de labels et de tally avec vos outils tiers, contrôleur broadcast inclus. Le protocole va dans les deux sens : nos murs d’images en émettent, et nous consommons ceux qui viennent d’ailleurs.
Skaarhoj Raw Panel
Pupitres Skaarhoj en protocole natif : Quick Bar, presets nommés et routage XY.
SRT
Transport fiable sur un réseau qu’on ne maîtrise pas, avec reprise sur perte. En entrée comme en sortie de chaîne.
RTMP
Ingestion depuis un encodeur ou un logiciel de production, en serveur (la source pousse) ou en pull.
WHIP / WHEP
Signalisation WebRTC normalisée : WHIP pour pousser vers la passerelle, WHEP pour lire dans un navigateur. C’est ce qui alimente les prévisualisations et le panneau de monitoring.
RTSP
Ingestion vers la passerelle média quand WHIP ne convient pas à la source.
MPEG-TS
Conteneur des sorties UDP et SRT, vidéo et pistes audio multiplexées ensemble.
H.264
Codec vidéo de sortie, réglable en débit, preset et GOP. Le choix par défaut quand la compatibilité prime.
HEVC
Codec vidéo de sortie à préférer quand c’est la bande passante qui prime sur la compatibilité des décodeurs.
AAC
Codec audio des destinations UDP et SRT, toutes les pistes comprises.
Opus
Codec audio des destinations WebRTC, sur la première piste.
MXL
Media eXchange Layer : le bus en mémoire partagée sur lequel tout se raccorde à l’intérieur d’un nœud. Ce n’est pas notre format : c’est la couche d’échange qu’appelle l’EBU Dynamic Media Facility Reference Architecture, publiée sous licence Apache 2.0. Bobi.Studio s’appuie sur son SDK plutôt que d’inventer un transport propriétaire. Depuis BCP-007-03, les flux du bus sont publiés en ressources NMOS sous le transport urn:x-nmos:transport:mxl : un contrôleur tiers voit notre graphe interne comme il voit n’importe quel équipement du réseau.
RDMA / RoCE
Réplication du bus mémoire entre nœuds sans traverser la pile réseau, avec répartition sur plusieurs ports et réconciliation automatique des liens.
La conformité NMOS ne s’arrête pas à l’enregistrement : le modèle de contrôle MS-05-02 est publié sur deux transports, IS-12 en WebSocket et IS-14 en REST, et les moniteurs BCP-008 remontent l’état réel de chaque récepteur et de chaque émetteur.
Le code est ouvert.
Bobi.Studio est un logiciel libre publié sous GNU GPL v3. Le dépôt contient l’orchestrateur, l’agent-nœud, les plugins de conteneurs et la documentation d’installation.