O video wall mais engenhoso já feito com Chromebooks

• Levou cerca de 3 anos para desmontar e reaproveitar Chromebooks Lenovo ThinkPad 11e distribuídos pela escola e destinados ao descarte, transformando-os em um video wall de 10 telas
• Em vez de usar um controlador de display separado, a placa-mãe do notebook original aciona cada tela, e um sistema de sincronização baseado na web reproduz um único vídeo dividido em 10 partes
• O c-sync baseado em socket.io enfrentou desempenho lento, diferenças no tempo de carregamento, latência e problemas de relógio do sistema, mas conseguiu reprodução quase sincronizada ao desacelerar o loop para acompanhar o cliente mais lento
• As limitações de registro corporativo do ChromeOS, modo desenvolvedor e problemas de energia ao remover a bateria foram contornadas com coreboot, ferramentas do MrChromebox, USB de instalação automática do Debian e controle de ventoinha com ectool
• Ainda restam limitações como ângulo de visão do painel TN, diferenças de cor e sincronização imperfeita, mas o projeto mostra como lixo eletrônico pode virar uma instalação funcional por meio de colaboração e design iterativo

---

Um video wall que começou com Chromebooks prestes a ser descartados

• O projeto começou quando a escola estava prestes a descartar seus Chromebooks antigos, e surgiu a ideia de aproveitar esse material para criar algo
• O equipamento usado foi o Lenovo ThinkPad 11e, um notebook fornecido pela escola que já não recebia atualizações de software do Google
• A maioria mal conseguia carregar páginas web e ainda estava presa a um antigo Enterprise Enrolment, o que dificultava o uso sem uma conta Google da escola
• O objetivo era criar um video wall em que várias telas funcionassem como se fossem um único display grande

Como as telas foram acionadas e os testes de sincronização

• No início, foi considerada a ideia de remover apenas os painéis de display dos notebooks e usar um único computador potente para acionar as 10 telas ao mesmo tempo
• Como isso exigiria muito tempo e custo, e as telas já estavam conectadas a notebooks funcionais, a abordagem mudou para usar a placa-mãe de cada notebook para acionar sua própria tela
• Também foram feitos testes com streaming via VLC para enviar vídeo a vários dispositivos na mesma rede, mas isso não atendia às exigências do video wall
  • Não era um sistema projetado para sincronização perfeita de vídeo
  • Em vez de repetir o mesmo vídeo nas 10 telas, era necessário dividir um único vídeo longo em 10 partes e mostrar uma entrada diferente em cada tela

Ajustando o tempo de reprodução com c-sync

• Foi criado o c-sync, um sistema servidor/cliente em ExpressJS que usa uma página web e socket.io para sincronizar a reprodução de vídeo entre os clientes
• A estrutura básica era que o servidor enviava um evento play, e então o elemento <video> de cada cliente começava a reprodução
• Em testes em computadores desktop, parecia funcionar bastante bem, mas nos Chromebooks reais a sincronização não se mantinha de forma estável por falta de desempenho
  • Diferenças no tempo de carregamento
  • Latência de rede
  • Diferenças no relógio do sistema
• A solução final passou a fazer com que cada cliente emitisse um evento start ao chegar ao fim do vídeo
  • O computador mais lento fazia os mais rápidos esperarem, garantindo tempo para carregar o vídeo
  • Cada tela podia receber 10 eventos start, então o ponto de loop podia oscilar um pouco
  • Se os primeiros quadros do vídeo fossem iguais, seria difícil para o usuário perceber a diferença
• A reprodução agendada com base em timestamp também parecia possível, mas esses Chromebooks não conseguiam manter seus relógios alinhados com estabilidade na casa dos milissegundos, então isso não funcionou

Trabalho de firmware para sair do ChromeOS

• Em um ou dois meses, o projeto já havia chegado ao ponto de abrir manualmente a página web e mostrar o vídeo sincronizado em tela cheia
• Para uso em uma instalação real, era necessário que o sistema inicializasse automaticamente ao receber energia e abrisse a página cliente do c-sync
• O ChromeOS padrão iniciava em uma tela de login do Google bloqueada pelo domínio da escola, e sem a bateria o notebook não ligava automaticamente ao conectar a energia
• A placa-mãe GLIMMER foi tratada com o ChromeOS Firmware Recovery Script do MrChromebox
  • Entrada no Recovery Mode
  • Ativação do Developer Mode
  • Execução do script no ChromeOS Shell
• Alguns Chromebooks se recusavam a entrar em Developer Mode por causa do Enterprise Enrolment, e mesmo os que recebiam Linux com sucesso acabavam, com o tempo, parando a reprodução de vídeo ou travando o sistema inteiro
• A solução foi remover o parafuso de Write Protection de cada placa-mãe e sobrescrever todo o firmware original com coreboot
  • Esse processo aparentemente também contornou as restrições de registro
  • Como isso precisou ser repetido em mais de 20 computadores, foi um processo lento e trabalhoso
  • Depois disso, o Wake on AC passou a funcionar como recurso de firmware, e a reprodução de vídeo deixou de falhar aleatoriamente

Criando um quiosque Linux com boot automático

• No começo, foi usado um script de inicialização que abria o Chromium e simulava pressionamentos de tecla para colocá-lo em tela cheia
• O FullPageOS já havia sido testado em um projeto anterior, mas não funcionava em hardware x86
• O Porteus Kiosk funcionou bem por ser uma distribuição Linux mínima que executa o Chromium em tela cheia e permite configurar flags para reprodução de vídeo sem interação do usuário
• Ainda assim, o Porteus Kiosk trazia obstáculos para operar a instalação de verdade
  • Não era possível trocar a tela de splash com o logo do Porteus exibida durante o boot
  • Não havia como fazer tarefas remotas, como alterar a URL da página após a instalação, o que poderia virar um problema depois de montar tudo na parede
• Para chegar a algo mais próximo de uma distribuição própria, foi testada uma configuração em sistema mínimo que iniciava automaticamente o Chromium em modo kiosk, sem ambiente desktop
• O NixOS falhou na instalação por causa do pequeno espaço de armazenamento dos Chromebooks
• Depois disso, foi escrito um script de provisionamento baseado em instalação mínima do Debian
  • Geração de KIOSK_ID
  • Definição do hostname como csync-client-$KIOSK_ID
  • Conexão ao Wi‑Fi da escola
  • Criação de usuário e permissões
  • Inicialização automática do Chromium em modo kiosk com openbox
• Como a instalação manual do Debian era trabalhosa, foram usados FAI - Fully Automatic Installation e FAI.me
• No fim, foi criado um único USB que, ao ser conectado a um Chromebook com coreboot, fazia o provisionamento automático para cliente do c-sync
• O c-sync também ganhou um controller para gerenciar os clientes conectados e atribuir vídeos a cada um
• Depois de um teste de estresse de 3 dias com reprodução estável, o projeto seguiu para a etapa de montagem na parede

Montagem, energia e controle térmico

• O hardware de montagem foi projetado por Aksel Salmi, com uma estrutura que permite fixar na parede a placa-mãe e o display
• A fonte de alimentação foi montada emendando cabos para que cada adaptador pudesse alimentar dois computadores
• Depois da instalação, o maior problema foi o calor, e após o processo de apagar o firmware as ventoinhas dos notebooks deixaram de girar
• O ChromeOS Embedded Controller podia ser acessado com ectool, permitindo configurar manualmente a velocidade da ventoinha
• Havia pouca documentação online, e diferenças entre o ectool do coreboot e o da Google causavam confusão, mas um binário obtido via Wayback Machine funcionou corretamente para ajustar a velocidade da ventoinha
• Após testes, foi encontrado um valor de velocidade que equilibrava ruído e temperatura

Produzindo o vídeo para 10 telas

• A resolução de cada display é 1366×768, então o vídeo total para as 10 telas ficou em 13660×768
• Não havia muitos softwares capazes de editar um vídeo tão largo; na prática, só foi possível usar Final Cut Pro e Blender
• Depois de renderizar o vídeo em largura total, ele foi dividido em 10 partes com ffmpeg para atribuir uma a cada tela
• O script de corte gerava segmentos na forma crop=1366:768:x_offset:0, de acordo com a posição de cada tela

Resultado final e limitações que permaneceram

• O video wall concluído inclui sequência de boot, um processo que parece uma calibração própria, reprodução de vídeo sincronizada, além de gabinete e roteamento de cabos
• O resultado não é perfeito
  • O ângulo de visão dos painéis TN não é bom
  • As cores variam de uma tela para outra
  • A sincronização não é perfeita
  • Pode ter havido alternativas melhores para cada decisão tomada
• Ainda assim, o projeto conseguiu transformar lixo eletrônico em uma instalação interessante e funcional, além de demonstrar design iterativo e colaboração em equipe

[GN⁺]

Opiniões no Hacker News

• Parabéns por concluir um projeto divertido. Já trabalhei bastante com sincronização de mídia em vários dispositivos, então é sempre interessante ver que soluções as pessoas inventam.
  O jeito padrão da indústria para criar um video wall sincronizado como esse é usar media players BrightSign, mas, para algo na faixa de 20 displays, só o custo de compra dos players e das telas pode facilmente chegar a dezenas de milhares de dólares. É realmente impressionante terem conseguido fazer funcionar com equipamentos reaproveitados.
  Se houver interesse em trabalhar em codebases relacionadas a sincronização de mídia, podem entrar em contato. Contratamos desenvolvedores freelancers com bastante frequência.

  • Obrigado. Não coloquei isso no post do blog, mas também consultei tabelas de preço de soluções comerciais, e eram realmente caras.
    Sempre tive curiosidade sobre quanto do custo é hardware e quanto é software, e imagino que sinalização digital profissional seja projetada levando em conta coisas como confiabilidade e vida útil.

• Eu trabalhava no Google quando o Chromebook foi lançado e, quando estavam pedindo ideias de decoração para o saguão, sugeri algo parecido, mas recusaram. Talvez tenha sido porque eu pedi 40 a 64 dispositivos.
  Acho que eu não teria tentado sincronizar vídeo, porém; em vez disso, teria feito animações baseadas em tempo e sincronizado os relógios pela rede.
  Um exemplo pode ser visto aqui: https://www.youtube.com/watch?v=64TcBiqmVko
  São 8 dispositivos rodando Chrome, e as únicas coisas sincronizadas são a configuração e o tempo. Os dispositivos nem precisam estar em formato de grade; a inspiração veio do aquário virtual do Boston Science Museum.

  • O autor também tentou isso, mas os relógios não se mantiveram sincronizados. Está em uma nota lateral recolhível.
    Diz algo como: “Infelizmente, esses Chromebooks não conseguiam manter seus horários alinhados entre si de forma confiável na escala de milissegundos, então essa abordagem não funcionou para nós”.
  • Se for mídia fixa, e não algo gerado dinamicamente em tempo real ou transmitido por streaming, esse truque pode ir bem longe. Mesmo sendo generativo, funciona se o tempo for usado como o valor que impulsiona a animação.
    Como você disse, é preciso uma boa sincronização de relógio e, especialmente se houver áudio, até uma diferença de 20–30 ms fica muito perceptível, então não é fácil. Ainda assim, com NTP/PTP dá para ir bem longe.

• Muito legal. Fiz algo parecido com tablets em uma matriz 4x4 e consegui automatizar quase tudo depois de conectar os 16 via ADB a um único host.
  Depois, criei 16 telas virtuais no sway e 16 clientes VNC, e testei fazendo streaming de tudo por Wi‑Fi; o Wi‑Fi funcionou tão bem que nem procurei uma solução mais eficiente.
  Durante esse período, meu PC tinha 19 displays, 17 deles via VNC, e era uma cena e tanto. Eu podia fazer a mesma coisa em todos, ou usar cada um para uma finalidade diferente, como música, htop, calendário, relógio e sessões ssh.
  Mas lidar com o hardware foi bem chato. Alguns sofriam throttling, alguns tinham problemas de conexão, e algumas baterias não conseguiam manter a carga.

• Muito tempo atrás houve algo parecido chamado Junkyard Jumbotron. Ele permitia juntar displays variados para mostrar partes de uma imagem maior.
  https://github.com/mitmedialab/Junkyard-Jumbotron
  Vídeo: https://youtu.be/cAUtSVSTbzU?feature=shared

  • O Media Lab cria muita coisa aleatória e divertida. Seria interessante refazer isso com tecnologias web modernas.
    O método de enviar uma foto por e-mail para fazer o alinhamento também parece meio divertido.

• Se você só passou os olhos e não leu o blog inteiro: este projeto foi feito por alunos do ensino médio durante o período em que estavam no ensino médio. Isso o torna ainda mais impressionante.

• Pelos trechos “não tenho certeza absoluta de por que funciona tão bem, mas por acaso me ocorreu uma solução absurda” e “o computador mais lento segura o computador mais rápido”, isso funciona bem porque o projeto do sistema foi otimizado em torno do gargalo.
  Vale olhar a Teoria das Restrições.

• Certa vez precisei fazer algo parecido com 5 TVs grandes touchscreen dispostas como uma mesa. Cada lado precisava ser um app touchscreen separado, todos reproduzindo um vídeo sincronizado ao fundo, enquanto os usuários interagiam com elementos que fluíam de uma ponta à outra, ou enviavam objetos encontrados para usuários do outro lado da mesa.
  No fim, praticamente o único equipamento dentro do orçamento capaz de acionar todas as telas ao mesmo tempo era um Mac Pro cilíndrico, então usamos isso, e os apps foram sincronizados via Redis. Essa parte fui eu que escrevi.
  Funcionou muito bem, mas saí da empresa antes de ver o produto final. Originalmente queríamos sincronizar computadores separados, mas não conseguimos deixá-los confiáveis o bastante; funcionava por um tempo e então, por vários fatores, a sincronização saía do eixo e era preciso reiniciar periodicamente a aplicação, o que não era viável.
  Desde o começo dos PCs, algo que sempre quis foi a capacidade de ligar várias máquinas em rede para compartilhar recursos e cooperar mais. Eu imaginava usar todos os computadores do escritório como se fossem um supercomputador para processar tarefas. Claro que é um problema muito difícil, e os apps e sistemas operacionais teriam de ser projetados desse jeito, além de exigir novos algoritmos. Ainda mais considerando que levou bastante tempo até aproveitarmos bem múltiplos processadores dentro de um único dispositivo na mesma placa. Mas projetos como seti@home ou folding@home fizeram algo assim em certa medida, e eu esperava que um dia os próprios computadores dessem suporte a isso.

  • Isso se chama computação distribuída (https://en.m.wikipedia.org/wiki/Distributed_computing) e é possível há muito tempo com Linux/BSD.

• No trecho “comecei a criar a ‘minha distribuição’ que pudesse ser instalada nos laptops. O sistema deveria começar com uma configuração mínima e ter um script elegante que inicializasse automaticamente uma instância do Chromium em modo kiosk, sem ambiente desktop. Primeiro tentei NixOS, mas logo percebi que o armazenamento desses Chromebooks era pequeno demais para isso, e a instalação falhava todas as vezes. Acabei desistindo e comecei com uma instalação mínima do Debian, mas percebi que a instalação do Debian exigia apertar botões demais e desperdiçava muito tempo, então descobri o ‘FAI - Fully Automatic Installation’ e a ferramenta web FAI.me”, vale lembrar que DietPi, OpenWrt e OpenBalena também têm opções de instalação automatizada para instalar pacotes específicos em bare metal mínimo.
  Fico curioso se existem outras opções sem desktop.

• O mais interessante é que trocar para coreboot resolveu os travamentos. Fico curioso se existe alguma teoria sobre o motivo.
  Pode ter relação com ACPI/DSDT, ou talvez o BIOS original inicializasse algum controlador de hardware de forma incorreta.

  • Pode ter sido um watchdog timer disparando.