Ajustando a fidelidade visual do Super Bowl com Elixir
(elixir-lang.org)- A Cyanview fabrica equipamentos de camera shading que alinham cor, exposição e tons de pele de centenas de câmeras em grandes transmissões ao vivo como o Super Bowl, usando Elixir no caminho central de controle
- Como no ambiente de transmissão uma única falha pode ser fatal, a Cyanview baseia seu produto em controle por rede IP e na capacidade da Erlang VM de coordenar dispositivos
- Os equipamentos RCP e RIO rodam sobre Yocto Linux com lógica em Elixir e C, e oferecem suporte a produção remota com comunicação baseada em MQTT e um relay de nuvem limitado
- A codificação e decodificação binária do Elixir e a supervision tree são usadas para integrar diversos equipamentos proprietários, isolar falhas de conexão e validar recursos rapidamente
- Uma equipe de 9 pessoas dá suporte a cenários com mais de 200 câmeras conectadas, além de eventos como Le Mans, Ninja Warrior, Australian Open e US Open, ampliando o alcance do produto de um time pequeno
O problema que a Cyanview resolve no ambiente de transmissão
- Em transmissões ao vivo como o Super Bowl, é preciso alinhar cor, exposição e tom visual de cerca de 200 câmeras
- Camera shading é o trabalho de ajustar cada câmera para que todas mostrem a mesma cor de grama e o mesmo tom de pele
- Os equipamentos envolvidos variam de grandes câmeras de transmissão a câmeras de drone, câmeras PTZ e câmeras mirrorless montadas em gimbal
- A Cyanview é uma pequena empresa belga que vende produtos para a indústria de transmissão de vídeo ao vivo, e sua principal especialidade é shading
- As ferramentas da indústria de transmissão precisam ser validadas imediatamente em um único evento ao vivo, e falhas graves são difíceis de tolerar
Como o RCP se espalhou e onde é usado
- O Remote Control Panel (RCP), criado por uma pequena equipe de 3 pessoas, se espalhou na indústria mais por suas funções do que por marketing
- O RCP é usado por operadores profissionais de vídeo nos seguintes eventos e organizações
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- vários desfiles de moda em Paris
- Já houve casos em que um único RCP controlou mais de 100 câmeras sem problemas, implementado sobre a stack de rede do Elixir
- A Cyanview escolheu Elixir para obter recursos de rede, resiliência e rápida iteração de funcionalidades do produto
Por que escolheram Elixir
- A equipe fundadora da Cyanview tinha principalmente experiência em desenvolvimento embarcado, e o produto inclui muito código C de baixo nível e FPGA
- A necessidade de lidar com detalhes de baixo nível da ciência de cor e com exigências rígidas de timing exigiu implementações de baixo nível
- O software de câmeras muitas vezes continua preso a sistemas analógicos ou formas proprietárias de conexão, mesmo após a digitalização completa
- Ao mirar desde o início em controle baseado em IP, a arquitetura passou a ser de software controlando equipamentos sobre redes genéricas
- Com o aumento da produção remota, se espalhou o modelo em que a equipe de produção opera de uma localização central e reduz a equipe no local
- Protocolos seriais ou de radiofrequência personalizados são difíceis de escalar para distâncias entre continentes
- A Erlang VM foi projetada para comunicar e coordenar com confiabilidade um grande número de dispositivos pela rede, e isso levou à adoção de Elixir
Integração de protocolos e caso de produção remota
- O desenvolvedor Ghislain adotou Elixir para integrar câmeras e equipamentos de vídeo por meio de vários protocolos de rede
- O Elixir oferece recursos práticos para codificar e decodificar dados binários até o nível de bits individuais
- A principal propriedade intelectual da Cyanview está na integração em larga escala de equipamentos e em engenharia reversa
- Os produtos são projetados para serem compatíveis com os diversos sistemas profissionais de câmera e equipamentos relacionados usados pelos clientes
- A empresa também fornece APIs para integração fluida com equipamentos externos
-
Caso de controle remoto Beijing–Paris
- No caso das Olympics na China, o estúdio em Beijing usava muitas câmeras PTZ da Panasonic, e a maior parte da equipe precisava controlá-las remotamente a partir de Paris
- O protocolo das câmeras Panasonic não foi pensado para uso pela internet, e cada ajuste exigia timing preciso e várias mensagens
- A latência de rede podia causar timeout, desconexão e falha do sistema
- A operação foi feita colocando equipamentos da Cyanview ao lado das câmeras em Beijing e controlando tudo por IP a partir de Paris
- Os equipamentos no mesmo local se comunicavam e se coordenavam pela rede com um protocolo MQTT personalizado
RCP, RIO e a composição da UI
- Todo o sistema é composto por equipamentos RCP rodando Yocto Linux e lógica baseada em Elixir e C
- Python ainda é usado para scripts e ferramentas, mas seu papel vem diminuindo gradualmente
- Vários microcontroladores e dispositivos acoplados à câmera se comunicam via MQTT
- O relay de nuvem ajuda na conectividade, e os painéis e a UI do controlador oferecem monitoramento e controle
- Há dois equipamentos principais
- RCP: equipamento de controle do lado da produção
- RIO: equipamento responsável pela operação de baixa latência da câmera
- Tanto o RCP quanto o RIO executam Elixir
- A UI de configuração atualmente é construída em Elm
- Dependendo das prioridades, a UI de configuração pode migrar para Phoenix LiveView para reduzir o número de linguagens usadas
- A UI web do controlador já é feita em LiveView e funciona bem mesmo em máquinas embarcadas Linux de baixa potência
Nuvem limitada e cluster local de equipamentos
- A parte em nuvem da Cyanview ainda é limitada e não segue uma estrutura centrada em SaaS
- O relay de nuvem cuida da distribuição e do compartilhamento de controle de câmera, encaminhamento de portas de rede entre locais e funções relacionadas
- O relay de nuvem também é construído em Elixir
- No local, os equipamentos em Elixir formam um cluster IP com um protocolo personalizado baseado em MQTT adaptado ao trabalho
- Esses equipamentos se comunicam com centenas de câmeras e outros dispositivos de vídeo
Isolamento de falhas e supervision tree
- Ao integrar muitos equipamentos proprietários, a confiabilidade e a qualidade da documentação variam muito de dispositivo para dispositivo
- Alguns equipamentos são usados com frequência e suas características são bem conhecidas, alguns oferecem boa documentação, enquanto outros mostram comportamentos imprevisíveis
- Mesmo que ocorram problemas temporários, protocolos com bugs ou falhas físicas de conexão em uma câmera, o restante precisa continuar funcionando
- A supervision tree do Elixir é vantajosa para impedir que problemas individuais de conexão se espalhem e derrubem o sistema inteiro
Divisão de funções em uma equipe de 9 pessoas
- A Cyanview cresceu lentamente ao longo de 9 anos, acrescentando em média 1 pessoa por ano
- Hoje, uma equipe de 9 pessoas dá suporte a alguns dos maiores eventos de transmissão do mundo
- Há 2 desenvolvedores de Elixir
- Daniil cuida de parte da reformulação da UI e da direção de mais recursos de nuvem
- Ghislain cuida do trabalho de integração com câmeras
- LiveView e Elm são usados na UI dos equipamentos e nos dashboards
- Outros desenvolvedores embarcados não usam muito Elixir no dia a dia, mas estão acostumados a implementar protocolos e codificação em Elixir
- A principal razão para não terem se aprofundado mais em Elixir foi a falta de tempo, e porque expertise profunda em Elixir não era essencial
- O trabalho da equipe inclui design de PCB, escolha de componentes eletrônicos, engenharia reversa de protocolos, interfaces de display, implementação em FPGA, gestão de testes de produção, produção real e atualizações de firmware
Expansão de recursos e desenvolvimento orientado ao cliente
- Os equipamentos da Cyanview são usados em cenários como
- câmeras onboard em mais de 40 carros das 24 Hours of Le Mans
- Ninja Warrior
- Australian Open
- US Open
- estúdios no Louvre
- pylons da NFL
- conexão simultânea de mais de 200 câmeras
- A empresa construiu equipamentos baseados em Elixir para um mundo que opera sobre IP, o que permite ao mesmo tempo dar suporte a vários equipamentos e entregar novos recursos
- A migração de rádio local, conexões seriais e protocolos proprietários inflexíveis para redes IP mudou a forma de operar sistemas de câmera
- O conjunto de recursos inclui
- multicâmera sem limites
- Tally lights
- controle de Pan & Tilt
- integração com color correctors
- produção remota em escala global
- Com o aumento da demanda para filmar o público com câmeras mirrorless montadas em gimbal, a Cyanview conseguiu prototipar rapidamente o controle de gimbal e validá-lo com clientes
- A arquitetura flexível permite entregar novos recursos rapidamente sem quebrar a base central
- Fabricantes de câmeras como Canon ou RED, que não produzem controles remotos de shading para transmissão, recomendam a Cyanview aos clientes
- A Cyanview se vê mais como parceira do que como concorrente da maioria das empresas de hardware para transmissão
- Mais do que marketing, a empresa valoriza ajudar seus clientes a ter sucesso nos eventos e oferecer serviço profundo
Direção futura
- David Bourgeois afirma que escolheria Elixir novamente se tivesse que decidir de novo
- A Erlang VM se encaixou bem nas necessidades da Cyanview, e ele considera que o valor dos recursos que Elixir oferece por padrão é difícil de entender plenamente antes de tentar implementá-los por conta própria
- A Cyanview quer ampliar a equipe, mas pretende crescer com responsabilidade, mesmo que isso leve tempo
- Hoje há mais trabalho do que a pequena equipe consegue absorver
- Já existem produtos complementares ao lado do equipamento principal RCP, e mais produtos estão planejados
- Estão em planejamento produtos de nuvem e projetos de hardware baseados no que aprenderam até agora
- O Elixir deve assumir um papel ainda mais importante em parte das maiores transmissões ao vivo do mundo
1 comentários
Opiniões no Hacker News
Depois que você sabe, parece óbvio demais que, em eventos esportivos, é preciso fazer correção de cor para cada câmera posicionada em vários ângulos
É muito interessante ler sobre problemas difíceis que são invisíveis para a maioria das pessoas
Há um vídeo que acompanha todas as trocas de tomadas de câmera do show do intervalo: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton dirige todos os shows do intervalo do Super Bowl desde 2010
https://x.com/SNYtv/status/1832250958258036871
O trecho dizendo que “mesmo sem marketing, ganhou reputação entre profissionais experientes e se tornou item essencial dos maiores eventos ao vivo do mundo” soa bem típico da indústria do entretenimento
Quando você faz o mesmo show com a mesma equipe ano após ano, todo mundo realmente conhece todo mundo, e isso vira uma estrutura meio familiar
A Cyanview tem um site vitrine e também posts de marketing no LinkedIn
É bom ver o Elixir ganhando força em sistemas de transmissão mission-critical
Fico curioso sobre quanto da confiabilidade da Cyanview vem do próprio Elixir, ou se é mérito de uma boa implementação de MQTT
Também me pergunto se havia algum recurso específico do Elixir que teria sido difícil reproduzir em outras linguagens
BEAM e OTP oferecem uma abordagem saudável para concorrência, e Elixir é uma boa linguagem em cima disso
O isolamento de processos é bom, com heaps separados por processo; assim, dá para rodar código maduro e estável junto com recursos experimentais sem se preocupar tanto em derrubar tudo, e a comunicação entre processos também é fácil
Graças às árvores de supervisão, o gerenciamento de processos é simples, e também foi possível criar supervisores especiais com diferentes estratégias de reinicialização
Em ambientes em que a conexão de rede cai e volta, a resiliência do sistema é testada com frequência, como uma espécie de chaos monkey físico
A imutabilidade ao estilo BEAM simplifica muito a escrita de código concorrente: dentro de um processo, você não precisa se preocupar que os dados mudem sorrateiramente, e outro processo também não pode alterar seu estado
Por isso, quase não são necessários mutexes ou seções críticas, mas deadlocks ainda são possíveis, então não é uma solução mágica
Trata-se de coordenar e rotear muitos feeds em tempo real com failover e caminhos alternativos; o alvo original eram chamadas telefônicas
Streams de vídeo têm muito mais dados por segundo, mas o princípio em grande parte se mantém
Costumo ser crítico desse sistema, mas, para esse tipo de uso, mesmo o estado básico já oferece uma base muito forte
A diferença está em quão fácil ela torna essa tarefa
Já apliquei Elixir em vários lugares, como aplicações financeiras críticas, inteligência de crescimento B2B, detecção de fraudes e compras scan-and-go
Em todos os casos, assim como a equipe de engenharia deste texto, a experiência de desenvolvimento e o resultado final superaram as expectativas; se você ainda não experimentou Elixir, vale a pena tentar
Eu mesmo não sou exceção: ouvi coisas boas por décadas, mas nunca usei em um projeto real
Por exemplo, acabamos de lançar no produto em nuvem uma função em que o usuário chama remotamente um robô para um waypoint designado dentro da instalação e vê, em tempo real no mapa, a posição do robô enquanto ele se desloca
Fizemos isso com MQTT, LiveView, Phoenix PubSub e pouquíssimo JavaScript para manipulação do mapa; excluindo o código existente para exibir PNGs de mapas no S3 e o processamento de recebimento via MQTT, a parte em nuvem foi implementada por uma pessoa em cerca de 2 a 3 semanas
Claro que daria para fazer em outras linguagens, mas os recursos essenciais da linguagem são tão bons que, para o nosso uso, ela supera de longe as outras opções
Fico me perguntando se Gleam seria prático para aplicações parecidas, além do runtime OTP/BEAM
Parece que eu ainda precisaria aproveitar bibliotecas de Elixir que ainda não existem em Gleam e, por causa da tipagem estática, a compilação poderia ser mais lenta, mas talvez desse para detectar erros de runtime mais cedo
Fico curioso se isso é mais uma troca entre depuração e iteração dinâmica rápida, e estou tentando decidir entre Gleam e Elixir
Eu gostava da sintaxe estilo ML do Gleam antigo e também gosto de tipagem estática
Estou substituindo C por Zig e, além de x64, estou aprendendo ARM e retomando meus estudos de assembly
O histórico de confiabilidade do Erlang é mais forte que o de muitas linguagens com tipagem estática, incluindo Java
A tipagem estática realmente impede certas classes de erros, mas há muito mais erros que ela não impede
Para afirmar que linguagens como TS, Java, Swift, Go ou Gleam reduzem defeitos reais em runtime em comparação com Erlang ou Elixir, seriam necessários dados do mundo real
Isso está em desenvolvimento agora, mas ainda não pude usar; por isso Gleam também me parece uma boa opção
Só que, quando começamos, Gleam nem tinha chegado à versão 0.1 e eu nunca tinha ouvido falar dele
Um projeto misturando Erlang, Elixir e Gleam também seria possível, mas não sei o quanto isso seria prático
A compilação também é muito rápida
Ainda não trabalhei em um projeto muito grande, mas mesmo usando bibliotecas bem pesadas, tudo compilou muito rápido
O mundo do vídeo digital parece um parente da TI, mas, para quem é de fora da indústria de vídeo, sempre dá a impressão de ter uma barreira de entrada alta
A forma de nomear resolução, cor, redes e armazenamento quase parece propositalmente diferente
Isso é apenas o conjunto de itens para engenheiros de vídeo ajustarem a qualidade de imagem, e normalmente não cobre funções voltadas ao operador de câmera
A dificuldade está em criar consistência entre tantas câmeras e protocolos
Só depois disso dá para avançar para questões como vídeo bruto yuv/y4m sem compressão, vídeo de bitrate altíssimo com baixa compressão e a criação de vídeos proxy porque os dados originais são grandes demais e difíceis de editar até em workstations potentes
Se não houver um motivo profissional, há pouco benefício para um usuário final comum se aprofundar nisso
Se você estiver pensando em gastar US$ 7.000 em uma câmera RED e mais US$ 13.000 em lentes, gimbal, cage, follow focus, matte box, cartões de memória etc. para montar um pacote de produção compacto e econômico com uma única câmera, aí vale a pena se aprofundar
Há mais de 30 anos, em um ambiente de estúdio, equilibrar o balanço de cores das câmeras fazia parte do meu trabalho
Não precisava de computador, mas havia no máximo 5 câmeras
A parte do texto que chamou minha atenção foi: “os dispositivos de um local se comunicam e se coordenam na rede por meio de um protocolo MQTT customizado, e um único Remote Control Panel (RCP), implementado sobre a stack de rede em Elixir, lida sem problemas com mais de 100 câmeras”
Entendo que MQTT é construído sobre TCP, e não sei se eu teria encontrado a mesma solução, mas parece uma escolha muito boa