Ajuster la fidélité visuelle du Super Bowl avec Elixir
(elixir-lang.org)- Cyanview fabrique des équipements de camera shading qui harmonisent la couleur, l’exposition et les tons de peau de centaines de caméras lors de grands directs comme le Super Bowl, et utilise Elixir dans son chemin de contrôle critique
- Sur un plateau de diffusion, un seul échec peut être fatal ; Cyanview a donc fondé son produit sur le contrôle réseau IP et sur la capacité de la VM Erlang à coordonner des appareils
- Les équipements RCP et RIO fonctionnent sous Yocto Linux avec une logique en Elixir et en C, et prennent en charge la production à distance via des communications basées sur MQTT et un relais cloud limité
- L’encodage et le décodage binaires d’Elixir, ainsi que sa supervision tree, servent à intégrer divers équipements propriétaires, à isoler les pannes de connexion et à valider rapidement des fonctionnalités
- Une équipe de 9 personnes prend en charge plus de 200 caméras connectées et des événements comme Le Mans, Ninja Warrior, l’Australian Open et l’US Open, élargissant ainsi la portée produit d’une petite équipe
Le problème que Cyanview résout sur les plateaux de diffusion
- Lors d’un direct comme le Super Bowl, il faut harmoniser la couleur, l’exposition et le rendu visuel d’environ 200 caméras
- Le camera shading consiste à régler chaque caméra pour qu’elle affiche la même couleur de pelouse et les mêmes tons de peau
- Les équipements concernés vont des grandes caméras de broadcast aux caméras de drones, en passant par les caméras PTZ et les hybrides montés sur stabilisateur
- Cyanview est une petite entreprise belge qui vend des produits pour l’industrie de la vidéo en direct, avec le shading comme spécialité principale
- Dans l’industrie broadcast, les outils doivent être validés directement lors d’un événement live, et les pannes matérielles sont difficilement tolérables
Comment le RCP s’est diffusé et où il est utilisé
- Le Remote Control Panel (RCP), créé par une petite équipe de 3 personnes, s’est diffusé dans le secteur par ses fonctionnalités plutôt que par le marketing
- Le RCP est utilisé par des opérateurs vidéo professionnels sur les événements et contextes suivants
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- de nombreux défilés de mode à Paris
- Il existe des cas où un seul RCP a piloté plus de 100 caméras sans problème, sur une implémentation construite au-dessus de la pile réseau d’Elixir
- En choisissant Elixir, Cyanview a obtenu des capacités réseau, de la résilience et une itération rapide des fonctionnalités produit
Pourquoi Elixir a été choisi
- L’équipe fondatrice de Cyanview avait principalement une expérience en développement embarqué, et le produit intègre beaucoup de code C bas niveau et de FPGA
- Les détails bas niveau de la science des couleurs et les contraintes de timing serrées imposent des implémentations bas niveau
- Même après la numérisation complète, les logiciels de caméra restent souvent liés à des systèmes analogiques ou à des modes de connexion propriétaires
- Dès le départ, l’objectif était un contrôle basé sur IP, avec une architecture où le logiciel pilote les équipements sur un réseau généraliste
- Avec la croissance de la production à distance, il est devenu courant que les équipes de production opèrent depuis un lieu central tout en réduisant le personnel sur site
- Les fréquences radio personnalisées ou les protocoles série filaires s’étendent difficilement à des distances intercontinentales
- La VM Erlang a été conçue pour permettre à de très nombreux appareils de communiquer et d’être coordonnés de manière fiable sur le réseau, ce qui a conduit à l’adoption d’Elixir
Intégration de protocoles et exemple de production à distance
- Le développeur Ghislain a introduit Elixir pour intégrer caméras et équipements vidéo via plusieurs protocoles réseau
- Elixir fournit des fonctionnalités pratiques pour encoder et décoder des données binaires jusqu’au niveau du bit individuel
- La propriété intellectuelle centrale de Cyanview réside dans l’intégration massive d’équipements et le reverse engineering
- Le produit est conçu pour être compatible avec les différents systèmes de caméras professionnelles et équipements associés utilisés par les clients
- Des API sont également fournies pour s’intégrer facilement à des équipements externes
-
Exemple de contrôle à distance Beijing–Paris
- Dans le cas des Olympics en Chine, le studio de Beijing utilisait de nombreuses caméras Panasonic PTZ, et la majeure partie de l’équipe devait les contrôler à distance depuis Paris
- Le protocole des caméras Panasonic n’était pas pensé pour Internet, et chaque réglage nécessitait un timing précis ainsi que plusieurs messages
- La latence réseau pouvait entraîner des timeouts, des déconnexions et des défaillances système
- L’exploitation s’est faite en plaçant les équipements Cyanview à Beijing, à côté des caméras, puis en les contrôlant depuis Paris via IP
- Les équipements situés au même endroit communiquent et se coordonnent sur le réseau au moyen d’un protocole MQTT personnalisé
RCP, RIO et composition de l’UI
- L’ensemble du système se compose d’équipements RCP exécutant Yocto Linux et d’une logique basée sur Elixir et C
- Python est encore utilisé pour le scripting et les outils, mais son rôle diminue progressivement
- Plusieurs microcontrôleurs et dispositifs montés sur caméra communiquent via MQTT
- Le relais cloud aide à la connectivité, tandis que les dashboards et l’UI des contrôleurs assurent la supervision et le contrôle
- Les équipements clés sont au nombre de deux
- RCP : équipement de contrôle côté production
- RIO : équipement chargé des manipulations à faible latence de la caméra
- Le RCP et le RIO exécutent tous deux Elixir
- L’UI de configuration est actuellement construite avec Elm
- Selon les priorités, l’UI de configuration pourrait migrer vers Phoenix LiveView afin de réduire le nombre de langages
- L’UI web du contrôleur est déjà en LiveView et fonctionne bien même sur des machines Linux embarquées peu puissantes
Cloud limité et cluster d’équipements locaux
- La partie cloud de Cyanview est actuellement limitée et ne repose pas sur une architecture centrée sur le SaaS
- Le relais cloud gère la distribution et le partage du contrôle des caméras, la redirection de ports réseau entre sites, ainsi que des fonctions associées
- Le relais cloud est lui aussi construit avec Elixir
- Sur le terrain, les équipements Elixir forment un cluster IP au moyen d’un protocole personnalisé basé sur MQTT et adapté à la tâche
- Ces équipements communiquent avec des centaines de caméras et d’autres appareils vidéo
Isolation des pannes et supervision tree
- Lorsqu’on intègre beaucoup d’équipements propriétaires, la fiabilité et la qualité de la documentation varient fortement selon les appareils
- Certains équipements sont courants et leurs caractéristiques sont bien connues, d’autres fournissent une bonne documentation, tandis que d’autres encore ont des comportements difficiles à prévoir
- Si un problème temporaire, un protocole bogué ou une défaillance de connexion physique survient sur une connexion caméra, le reste doit continuer à fonctionner
- La supervision tree d’Elixir est avantageuse pour empêcher qu’un problème de connexion individuel ne se propage en panne globale du système
Répartition des rôles dans une équipe de 9 personnes
- Cyanview a grandi lentement pendant 9 ans, en ajoutant en moyenne une personne par an
- Aujourd’hui, une équipe de 9 personnes prend en charge certains des plus grands événements broadcast au monde
- Il y a 2 développeurs Elixir
- Daniil s’occupe d’une partie de la refonte de l’UI et de l’orientation vers davantage de fonctionnalités cloud
- Ghislain s’occupe des caméras et des intégrations
- LiveView et Elm sont utilisés pour les UI des équipements et les dashboards
- Les autres développeurs embarqués n’utilisent pas beaucoup Elixir dans leur travail quotidien, mais ils sont à l’aise pour implémenter des protocoles et de l’encodage avec Elixir
- La principale raison pour laquelle ils n’ont pas approfondi Elixir est le manque de temps, et le fait qu’une expertise poussée d’Elixir n’était pas indispensable
- Le travail de l’équipe couvre la conception de PCB, le choix de composants électroniques, le reverse engineering de protocoles, les interfaces d’affichage, l’implémentation FPGA, la gestion des tests de production, la production réelle et les mises à jour firmware
Extension fonctionnelle et développement centré client
- Les équipements Cyanview sont utilisés dans les contextes suivants
- plus de 40 caméras embarquées dans les voitures des 24 Heures du Mans
- Ninja Warrior
- Australian Open
- US Open
- un studio au Louvre
- pylônes NFL
- plus de 200 caméras connectées simultanément
- Cyanview a créé des équipements basés sur Elixir pour un monde fonctionnant sur IP, ce qui permet à la fois de prendre en charge des équipements variés et de proposer de nouvelles fonctionnalités
- Le passage des fréquences radio locales, des connexions série et des protocoles propriétaires peu flexibles aux réseaux IP a changé la manière d’exploiter les systèmes de caméras
- L’ensemble de fonctionnalités comprend notamment
- multicam sans limite
- Tally lights
- contrôle Pan & Tilt
- intégration de correcteurs colorimétriques
- production à distance à l’échelle mondiale
- Lorsque la demande de tournage de scènes de public avec des hybrides montés sur stabilisateur a augmenté, Cyanview a rapidement prototypé le contrôle de stabilisateur, puis l’a testé et validé avec les clients
- L’architecture flexible permet de livrer rapidement de nouvelles fonctionnalités sans casser les fondations essentielles
- Les fabricants de caméras qui, comme Canon ou RED, ne produisent pas de télécommandes de shading broadcast recommandent Cyanview à leurs clients
- Cyanview se voit comme un partenaire de la plupart des fabricants de matériel broadcast plutôt que comme un concurrent
- L’entreprise privilégie la réussite des événements clients et un service client approfondi plutôt que le marketing
Orientations futures
- David Bourgeois répond que, s’il devait refaire ce choix, il choisirait à nouveau Elixir
- La VM Erlang correspondait bien aux besoins de Cyanview, et la valeur des fonctionnalités fournies par défaut par Elixir est difficile à mesurer pleinement avant d’avoir essayé de les implémenter soi-même
- Cyanview souhaite agrandir son équipe, mais veut croître de manière responsable, même si cela prend du temps
- Il y a actuellement plus de travail que ce que la petite équipe peut absorber
- Des produits complémentaires existent déjà aux côtés de l’équipement RCP principal, et davantage de produits sont prévus
- Des produits cloud et des projets hardware fondés sur les apprentissages accumulés jusqu’ici sont prévus
- Elixir jouera un rôle plus important dans certaines des plus grandes diffusions live au monde
1 commentaires
Avis sur Hacker News
Une fois qu’on le sait, cela paraît évident qu’il faut faire l’étalonnage des couleurs pour chaque caméra placée sous différents angles lors d’un événement sportif
C’est vraiment intéressant de lire sur des problèmes difficiles que la plupart des gens ne voient pas
Il existe une vidéo qui suit toutes les transitions entre plans caméra du spectacle de la mi-temps : https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton a réalisé tous les spectacles de mi-temps du Super Bowl depuis 2010
https://x.com/SNYtv/status/1832250958258036871
Le passage disant que « sans marketing, ils ont acquis une réputation auprès de professionnels chevronnés et sont devenus indispensables aux plus grands événements live du monde » sonne très industrie du divertissement
Quand on fait le même show avec la même équipe année après année, tout le monde finit vraiment par connaître tout le monde, dans une structure qui ressemble à une sorte de famille
Cyanview a aussi un site vitrine et des posts marketing sur LinkedIn
C’est réjouissant de voir Elixir prendre de l’importance dans des systèmes de diffusion critiques
Je me demande dans quelle mesure la fiabilité de Cyanview vient d’Elixir lui-même, ou plutôt d’une bonne implémentation de MQTT
Je me demande aussi s’il y avait des fonctionnalités spécifiques d’Elixir difficiles à reproduire dans d’autres langages
BEAM et OTP offrent une approche saine de la concurrence, et Elixir est un bon langage construit par-dessus
L’isolation des processus est bonne, jusqu’au tas qui est séparé par processus, ce qui permet de faire tourner du code mature et stable avec des fonctionnalités expérimentales sans trop craindre que tout s’effondre, et la communication entre processus est également simple
Les arbres de supervision facilitent la gestion des processus, et nous avons aussi pu créer des superviseurs spécialisés avec différentes stratégies de redémarrage
Dans un environnement où les connexions réseau se coupent puis reviennent, la résilience du système est souvent mise à l’épreuve comme par un chaos monkey physique
L’immuabilité façon BEAM simplifie beaucoup l’écriture de code concurrent : dans un processus, on n’a pas à craindre que les données changent en douce, et aucun autre processus ne peut modifier mon état
Du coup, les mutex ou sections critiques sont rarement nécessaires, mais les interblocages restent possibles, donc ce n’est pas une solution miracle
Il s’agit de coordonner et router d’innombrables flux en temps réel avec bascule et chemins alternatifs, et la cible d’origine était les appels téléphoniques
Les flux vidéo représentent bien plus de données par seconde, mais les principes restent en grande partie les mêmes
Je suis plutôt critique envers ce système, mais pour cet usage, même l’état de base offre déjà une fondation très solide
La différence est à quel point ils rendent cette tâche facile
J’ai appliqué Elixir à des applications financières critiques, à de l’intelligence de croissance B2B, à la détection de fraude, au scan-and-go shopping et à plusieurs autres domaines
À chaque fois, comme pour l’équipe d’ingénierie de cet article, l’expérience développeur et le résultat final ont dépassé les attentes ; si vous n’avez pas encore essayé Elixir, cela vaut le coup de tenter
Je ne fais pas exception : j’en entends du bien depuis des décennies, mais je ne les ai jamais utilisés sur un vrai projet
Par exemple, nous venons de déployer dans notre produit cloud une fonctionnalité qui permet à un utilisateur d’appeler à distance un robot vers un waypoint désigné dans l’installation, puis d’afficher en temps réel sa position sur la carte pendant qu’il se déplace
Nous avons fait cela avec MQTT, LiveView, Phoenix PubSub et très peu de JavaScript pour manipuler la carte ; en dehors du code existant d’affichage des PNG de carte depuis S3 ou du traitement de réception MQTT, la partie cloud a été implémentée par une seule personne en environ 2 à 3 semaines
Bien sûr, on pourrait le faire dans d’autres langages, mais les fonctionnalités fondamentales du langage sont tellement bonnes qu’elles écrasent les autres options pour notre cas d’usage
Je me demande si Gleam serait pratique pour des applications similaires, au-delà du runtime OTP/BEAM
Il faudra sans doute utiliser des bibliothèques Elixir qui n’existent pas encore dans Gleam, et même si le typage statique peut ralentir la compilation, il pourrait permettre de détecter plus tôt des erreurs à l’exécution
Je me demande si cela relève plutôt d’un compromis entre débogage et itération dynamique rapide, et j’essaie de choisir entre Gleam et Elixir
J’aimais aussi l’ancienne syntaxe de Gleam, façon ML, et j’aime le typage statique
Je remplace C par Zig, et en plus de x64 j’apprends ARM tout en révisant l’assembleur
Le bilan de fiabilité d’Erlang est plus solide que celui de nombreux langages à typage statique, y compris Java
Il existe bien des catégories d’erreurs que le typage statique empêche, mais il y en a beaucoup plus qu’il ne peut pas empêcher
Pour affirmer que des langages comme TS, Java, Swift, Go ou Gleam réduisent les défauts réels à l’exécution par rapport à Erlang ou Elixir, il faudrait des données du monde réel
C’est en cours de développement, mais je n’ai pas encore pu l’essayer, donc Gleam pourrait aussi convenir
Cela dit, quand nous avons commencé, Gleam n’en était même pas à la version 0.1 et je n’en avais jamais entendu parler
Un projet mélangeant Erlang, Elixir et Gleam serait possible, mais je ne sais pas à quel point ce serait pratique
La compilation est aussi très rapide
Je n’ai pas encore travaillé sur de très gros projets, mais même avec des bibliothèques assez lourdes, tout compilait très vite
Le monde de la vidéo numérique ressemble à un cousin de l’IT, et pourtant, pour quelqu’un extérieur au secteur vidéo, il donne toujours l’impression d’avoir une barrière à l’entrée élevée
La façon de nommer la résolution, la couleur, le réseau et le stockage semble presque volontairement différente
Ce ne sont que les éléments permettant à un ingénieur vidéo d’ajuster la qualité d’image, et cela ne couvre généralement pas les fonctions destinées aux opérateurs caméra
La difficulté consiste à créer de la cohérence entre autant de caméras et de protocoles
Ce n’est qu’ensuite qu’on peut passer aux questions de vidéo brute yuv/y4m non compressée, de vidéo à très haut bitrate et faible compression, puis de création de proxies parce que les données originales sont si volumineuses qu’elles sont difficiles à monter même sur de puissantes stations de travail
Sauf raison professionnelle, un utilisateur final ordinaire a très peu d’intérêt à creuser aussi loin
En revanche, si vous envisagez de dépenser 7 000 dollars dans une caméra RED, puis 13 000 dollars de plus en objectifs, gimbal, cage, follow focus, matte box, cartes mémoire, etc., afin de constituer un petit package de production à caméra unique, compact et rentable, cela vaut la peine de s’y plonger
Il y a une trentaine d’années, dans un environnement de studio, régler la balance des couleurs des caméras faisait partie de mon travail
Aucun ordinateur n’était nécessaire, mais il n’y avait au maximum que 5 caméras
Dans l’article, le passage qui dit que « les appareils d’un même site communiquent et se coordonnent sur le réseau via un protocole MQTT personnalisé, et qu’un unique Remote Control Panel (RCP), implémenté au-dessus de la stack réseau Elixir, gère sans problème plus de 100 caméras » a attiré mon attention
Je comprends que MQTT est construit au-dessus de TCP ; je ne sais pas si j’aurais trouvé la même solution, mais cela semble être un assez bon choix