- Cyanview fabrica equipos de camera shading para igualar color, exposición y tonos de piel de cientos de cámaras en grandes transmisiones en vivo como el Super Bowl, y usa Elixir en la ruta de control principal
- En el entorno de broadcast, donde una sola falla puede ser crítica, Cyanview basa su producto en el control por red IP y en la capacidad de la Erlang VM para coordinar dispositivos
- Los equipos RCP y RIO funcionan sobre Yocto Linux con lógica en Elixir y C, y soportan producción remota mediante comunicación basada en MQTT y un relay de nube limitado
- La codificación y decodificación binaria de Elixir y su supervision tree se usan para integrar distintos equipos propietarios, aislar fallas de conexión y validar funciones con rapidez
- Un equipo de 9 personas da soporte a entornos como Le Mans, Ninja Warrior, Australian Open y US Open, además de conexiones con más de 200 cámaras, ampliando el alcance del producto de un equipo pequeño
El problema que Cyanview resuelve en el broadcast
- En transmisiones en vivo como el Super Bowl, hay que igualar el color, la exposición y el tono visual de unas 200 cámaras
- El camera shading consiste en ajustar cada cámara para que muestre el mismo color del césped y los mismos tonos de piel
- El equipo involucrado es diverso: cámaras de broadcast de gran tamaño, cámaras en drones, cámaras PTZ y cámaras mirrorless montadas en gimbals
- Cyanview es una pequeña empresa belga que vende productos para la industria del video en vivo, y su especialidad principal es el shading
- Las herramientas de la industria de broadcast deben validarse directamente en un evento en vivo, y es difícil permitir fallas graves
Cómo se expandió el RCP y dónde se usa
- El Remote Control Panel (RCP), creado por un equipo pequeño de 3 personas, se difundió en la industria más por sus funciones que por marketing
- El RCP es usado por operadores profesionales de video en eventos como
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- múltiples desfiles de moda en Paris
- Ha habido casos en los que un solo RCP manejó más de 100 cámaras sin problemas, implementado sobre el stack de red de Elixir
- Cyanview eligió Elixir para obtener capacidades de red, resiliencia e iteración rápida de funciones de producto
Por qué eligieron Elixir
- El equipo fundador de Cyanview tenía principalmente experiencia en desarrollo embebido, y el producto incluye mucho código C de bajo nivel y FPGA
- Los detalles de bajo nivel de la ciencia del color y los requisitos estrictos de timing hacen necesaria una implementación de bajo nivel
- El software de cámara muchas veces sigue atado a sistemas analógicos o métodos de conexión propietarios incluso después de la digitalización total
- Al apuntar desde el inicio a un control basado en IP, la arquitectura quedó centrada en software que maneja equipos sobre redes estándar
- A medida que creció la producción remota, se extendió el modelo en el que el equipo de producción opera desde una ubicación central y se reduce el personal en sitio
- Las frecuencias inalámbricas personalizadas o los protocolos seriales por cable son difíciles de escalar a distancias intercontinentales
- La Erlang VM fue diseñada para comunicar y coordinar de forma estable una gran cantidad de dispositivos a través de la red, y eso llevó a adoptar Elixir
Integración de protocolos y caso de producción remota
- El desarrollador Ghislain adoptó Elixir para integrar cámaras y equipos de video a través de varios protocolos de red
- Elixir ofrece funciones prácticas para codificar y decodificar datos binarios hasta el nivel de bits individuales
- La propiedad intelectual central de Cyanview está en la integración masiva de equipos y la ingeniería inversa
- El producto está diseñado para ser compatible con los distintos sistemas de cámaras profesionales y equipos relacionados que usan sus clientes
- También ofrece APIs para integrarse sin fricción con equipos externos
-
Caso de control remoto Beijing–Paris
- En un caso de los Olympics en China, el estudio en Beijing usaba muchas cámaras Panasonic PTZ, y la mayor parte del equipo debía controlarlas en remoto desde Paris
- El protocolo de las cámaras Panasonic no estaba pensado para usarse por internet, y cada ajuste requería timing preciso y múltiples mensajes
- La latencia de red podía provocar timeouts, desconexiones y fallas del sistema
- Operaron colocando equipos de Cyanview junto a las cámaras en Beijing y controlándolos por IP desde Paris
- Los equipos del mismo lugar se comunican y coordinan en la red mediante un protocolo MQTT personalizado
RCP, RIO y la composición de la UI
- El sistema completo está compuesto por equipos RCP que ejecutan Yocto Linux y lógica basada en Elixir y C
- Python todavía se usa para scripting y herramientas, pero su rol se ha ido reduciendo
- Varios microcontroladores y dispositivos en cámara se comunican por MQTT
- El relay de nube ayuda con la conectividad, y el dashboard y la UI del controlador ofrecen monitoreo y control
- Hay dos equipos principales
- RCP: equipo de control del lado de producción
- RIO: equipo encargado de la operación de baja latencia en la cámara
- Tanto RCP como RIO ejecutan Elixir
- La UI de configuración está construida actualmente con Elm
- Según las prioridades, la UI de configuración podría migrar a Phoenix LiveView para reducir la cantidad de lenguajes
- La UI web del controlador ya está hecha con LiveView y funciona bien incluso en máquinas embebidas Linux de bajos recursos
Nube limitada y clúster local de equipos
- La parte en la nube de Cyanview es actualmente limitada y no está centrada en una estructura SaaS
- El relay de nube se encarga de desplegar y compartir el control de cámaras, del reenvío de puertos de red entre ubicaciones y de funciones relacionadas
- El relay de nube también está construido con Elixir
- Los equipos Elixir en sitio forman un clúster IP mediante un protocolo personalizado basado en MQTT y adaptado al trabajo
- Estos equipos se comunican con cientos de cámaras y otros dispositivos de video
Aislamiento de fallas y supervision tree
- Al integrar muchos equipos propietarios, la confiabilidad y la calidad de la documentación varían mucho según el dispositivo
- Algunos equipos son muy usados y sus características son bien conocidas; algunos ofrecen buena documentación; otros muestran comportamientos difíciles de predecir
- Aunque ocurra un problema temporal, un protocolo con bugs o una falla física de conexión en una cámara, el resto debe seguir funcionando
- El supervision tree de Elixir es útil para evitar que los problemas de conexiones individuales se conviertan en una falla total del sistema
Cómo se reparte el trabajo en un equipo de 9 personas
- Cyanview ha crecido lentamente durante 9 años, sumando en promedio una persona por año
- Hoy, un equipo de 9 personas da soporte a algunos de los eventos de broadcast más grandes del mundo
- Hay 2 desarrolladores de Elixir
- Daniil se encarga de parte de la renovación de la UI y de una dirección con más funciones en la nube
- Ghislain se encarga de las cámaras y del trabajo de integración
- LiveView y Elm se usan en la UI del equipo y en los dashboards
- Los otros desarrolladores embebidos no usan mucho Elixir en su trabajo diario, pero están acostumbrados a implementar protocolos y codificación con Elixir
- La razón principal por la que no aprendieron Elixir a fondo es la falta de tiempo y que no era indispensable una especialización profunda en Elixir
- El trabajo del equipo incluye diseño de PCB, selección de componentes electrónicos, ingeniería inversa de protocolos, interfaces de display, implementación en FPGA, gestión de pruebas de producción, producción real y actualizaciones de firmware
Expansión de funciones y desarrollo centrado en el cliente
- Los equipos de Cyanview se usan en entornos como
- más de 40 cámaras onboard en vehículos de 24 Hours of Le Mans
- Ninja Warrior
- Australian Open
- US Open
- estudios en el Louvre
- pylons de la NFL
- conexión simultánea con más de 200 cámaras
- Crearon equipos basados en Elixir para un mundo que opera sobre IP, y así pueden dar soporte a una gran variedad de equipos y al mismo tiempo ofrecer nuevas funciones
- El paso desde radiofrecuencia local, conexiones seriales y protocolos propietarios poco flexibles hacia redes IP cambió la forma de operar los sistemas de cámaras
- El conjunto de funciones incluye
- multicámara sin límites
- Tally lights
- control de Pan & Tilt
- integración con color correctors
- producción remota con alcance global
- Cuando aumentó la demanda de filmar al público con cámaras mirrorless montadas en gimbals, Cyanview pudo prototipar rápidamente el control del gimbal y validarlo con pruebas junto al cliente
- La arquitectura flexible permite entregar nuevas funciones con rapidez sin romper la base central
- Empresas de cámaras como Canon o RED, que no fabrican controles remotos de shading para broadcast, recomiendan Cyanview a sus clientes
- Cyanview se ve más como socio que como competidor de la mayoría de las empresas de hardware para broadcast
- Da más importancia a ayudar a que los eventos de sus clientes salgan bien y a un servicio profundo al cliente que al marketing
La dirección a futuro
- David Bourgeois respondió que volvería a elegir Elixir si tuviera que decidir de nuevo
- Considera que la Erlang VM encajó muy bien con las necesidades de Cyanview, y que es difícil apreciar por completo el valor de lo que Elixir ofrece por defecto hasta intentar implementarlo por cuenta propia
- Cyanview quiere seguir creciendo como equipo, pero busca hacerlo de manera responsable aunque tome tiempo
- Hoy ya hay más trabajo del que el equipo pequeño puede absorber
- Además de los equipos RCP principales, ya existen productos complementarios y hay más productos previstos
- Están planeados productos de nube y proyectos de hardware basados en lo aprendido hasta ahora
- Elixir asumirá un papel aún más importante en parte de las transmisiones en vivo más grandes del mundo
1 comentarios
Opiniones en Hacker News
Que en un evento deportivo haya que hacer corrección de color para cada cámara colocada en distintos ángulos resulta demasiado obvio una vez que lo sabes.
Es realmente interesante leer sobre problemas difíciles que la mayoría no ve.
Hay un video que rastrea todos los cambios de toma de cámara del show de medio tiempo: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton ha dirigido todos los shows de medio tiempo del Super Bowl desde 2010.
https://x.com/SNYtv/status/1832250958258036871
La parte de que “sin marketing, se ganó una reputación entre profesionales expertos y se convirtió en algo indispensable para los mejores eventos en vivo del mundo” suena muy propia de la industria del entretenimiento.
Cuando haces el mismo show con el mismo equipo año tras año, realmente todos conocen a todos y se forma una especie de estructura familiar.
Cyanview tiene un sitio web tipo escaparate y también publicaciones de marketing en LinkedIn.
Da gusto ver que Elixir gane tracción en sistemas de transmisión mission-critical.
Me pregunto cuánto de la confiabilidad de Cyanview viene de Elixir en sí y cuánto de una buena implementación de MQTT.
También me pregunto si hubo alguna característica específica de Elixir que habría sido difícil de reproducir en otros lenguajes.
BEAM y OTP ofrecen un enfoque sano para la concurrencia, y Elixir es un buen lenguaje montado sobre eso.
El aislamiento de procesos es bueno, hasta el heap está separado por proceso, así que se puede ejecutar código maduro y estable junto con funciones experimentales sin preocuparse tanto de que todo se venga abajo, y la comunicación entre procesos también es sencilla.
Gracias a los árboles de supervisión, la gestión de procesos es fácil, y también pudimos crear supervisores especializados con distintas estrategias de reinicio.
En un entorno donde las conexiones de red se caen y vuelven, la resiliencia del sistema se pone a prueba con frecuencia, como si fuera un chaos monkey físico.
La inmutabilidad al estilo BEAM simplifica mucho escribir código concurrente: dentro de un proceso no hay que preocuparse de que los datos cambien a escondidas, y otros procesos tampoco pueden modificar mi estado.
Por eso casi no se necesitan mutexes ni secciones críticas, aunque los deadlocks siguen siendo posibles, así que no es una solución mágica.
Se trata de coordinar y enrutar muchísimos feeds en tiempo real con failover y rutas alternativas, y el objetivo original eran las llamadas telefónicas.
Los streams de video manejan muchos más datos por segundo, pero la mayoría de los principios se mantienen.
Tiendo a ser crítico con este sistema, pero para este tipo de uso ofrece una base muy sólida incluso con su estado por defecto.
La diferencia está en qué tan fácil te hace hacerla.
He aplicado Elixir en aplicaciones financieras críticas, inteligencia de crecimiento B2B, detección de fraude, compras scan-and-go y otros ámbitos.
Cada vez, como al equipo de ingeniería de este artículo, la experiencia de desarrollo y el resultado final superaron las expectativas; si todavía no has probado Elixir, vale la pena intentarlo.
Yo tampoco soy la excepción: llevo décadas oyendo cosas buenas, pero nunca los he usado en un proyecto real.
Por ejemplo, acabamos de desplegar en nuestro producto cloud una función que permite al usuario llamar de forma remota a un robot hacia un waypoint designado dentro de una instalación y ver en tiempo real su ubicación sobre el mapa mientras se desplaza.
Lo hicimos solo con MQTT, LiveView, Phoenix PubSub y muy poco JavaScript para manipular el mapa; excluyendo el código existente para mostrar PNG de mapas desde S3 y el procesamiento de recepción MQTT, la parte cloud la implementó una sola persona en unas 2 o 3 semanas.
Claro que se podría hacer con otros lenguajes, pero las funcionalidades centrales del lenguaje son tan buenas que, para nuestro caso, superan por mucho a otras opciones.
Me pregunto si Gleam sería práctico para aplicaciones similares, más allá del runtime OTP/BEAM.
Parece que habría que aprovechar librerías de Elixir que todavía no existen en Gleam, y aunque la compilación podría ser más lenta por los tipos estáticos, tal vez permitiría detectar antes los errores en runtime.
Me pregunto si se parece más a un compromiso entre depuración e iteración dinámica rápida, y estoy tratando de decidir entre Gleam y Elixir.
También me gustaba la sintaxis estilo ML del Gleam anterior, y me gustan los tipos estáticos.
Estoy reemplazando C por Zig y, además de x64, estoy aprendiendo ARM y volviendo a reforzar ensamblador.
El historial de confiabilidad de Erlang es más sólido que el de muchos lenguajes con tipos estáticos, incluido Java.
Los tipos estáticos sí previenen ciertas clases de errores, pero hay muchas más que no pueden prevenir.
Para afirmar que lenguajes como TS, Java, Swift, Go o Gleam reducen los defectos reales en runtime más que Erlang o Elixir, harían falta datos del mundo real.
Ya están trabajando en eso, pero todavía no lo he probado, así que Gleam también podría ser una buena opción.
Dicho eso, cuando empezamos, Gleam ni siquiera llegaba a 0.1 y nunca había oído hablar de él.
También sería posible un proyecto que mezcle Erlang, Elixir y Gleam, aunque no sé qué tan práctico sería.
Además compila muy rápido.
Todavía no he hecho un proyecto muy grande, pero incluso usando librerías bastante pesadas, todo compiló muy rápido.
El mundo del video digital es como un pariente de IT, pero para quienes no son de la industria del video siempre se siente con una barrera de entrada alta.
La forma de referirse a resolución, color, redes y almacenamiento casi parece distinta a propósito.
Son solo elementos para que un ingeniero de video ajuste la calidad de imagen, y por lo general no cubren funciones para operadores de cámara.
La dificultad está en crear consistencia entre tantas cámaras y protocolos.
Recién después se puede pasar a temas como video sin compresión yuv/y4m crudo, video de altísimo bitrate con baja compresión, y el problema de crear videos proxy porque los datos originales son tan grandes que resultan difíciles de editar incluso en estaciones de trabajo potentes.
Si no hay una razón profesional, para un usuario final común hay muy poco beneficio en meterse a fondo.
Vale la pena si estás pensando en gastar 7.000 dólares en una cámara RED y otros 13.000 dólares en lentes, gimbal, cage, follow focus, matte box, tarjetas de memoria, etc., para armar un paquete pequeño y rentable de producción con una sola cámara.
Hace unos 30 años, en un entorno de estudio, parte de mi trabajo era ajustar el balance de color de las cámaras.
No hacían falta computadoras, pero como mucho había solo 5 cámaras.
Me llamó la atención la parte del artículo que dice que “los dispositivos de una ubicación se comunican y coordinan en la red mediante un protocolo MQTT personalizado, y un único Remote Control Panel (RCP) implementado sobre el stack de red de Elixir maneja sin problemas más de 100 cámaras”.
Entiendo que MQTT está construido sobre TCP, y no sé si yo habría encontrado la misma solución, pero parece una muy buena elección.