El video wall más ingenioso hecho con Chromebooks

• Tomó cerca de 3 años desarmar y reutilizar Chromebooks Lenovo ThinkPad 11e entregadas por una escuela y destinadas al descarte para crear un video wall de 10 pantallas
• En lugar de un controlador de pantalla separado, las motherboards de las laptops existentes manejan cada pantalla, y un sistema de sincronización basado en la web reproduce un solo video dividido en 10 partes
• c-sync, basado en socket.io, sufrió problemas de bajo rendimiento, diferencias en tiempos de carga, latencia y relojes del sistema, pero logró una reproducción casi sincronizada al ralentizar el loop para ajustarse al cliente más lento
• El registro empresarial de ChromeOS, las restricciones del modo desarrollador y los problemas de energía al quitar la batería se sortearon con coreboot, las herramientas de MrChromebox, un USB de instalación automática de Debian y control de ventiladores con ectool
• Aunque quedan limitaciones como los ángulos de visión de los paneles TN, diferencias de color y una sincronización imperfecta, es un caso de cómo convertir residuos electrónicos en una instalación funcional mediante colaboración y diseño iterativo

---

Un video wall que empezó con Chromebooks destinadas al descarte

• El proyecto comenzó cuando la escuela intentó desechar sus Chromebooks antiguas y surgió la idea de qué se podía construir con ellas
• Los equipos usados eran Lenovo ThinkPad 11e, laptops entregadas por la escuela que ya no recibían actualizaciones de software de Google
• A la mayoría les costaba incluso cargar páginas web y estaban atadas a una Enterprise Enrolment antigua, lo que las hacía difíciles de usar sin una cuenta de Google de la escuela
• El objetivo era crear un video wall que funcionara acomodando varias pantallas como si fueran una sola pantalla grande

Cómo manejar las pantallas y experimentos de sincronización

• Al principio se evaluó separar solo los paneles de pantalla de las laptops y manejar 10 pantallas a la vez con una sola computadora potente
• Como eso implicaba mucho tiempo y costo, y las pantallas ya estaban conectadas a laptops funcionales, se cambió a un enfoque donde cada pantalla sería manejada por su propia motherboard de laptop
• También se experimentó con streaming de VLC para enviar video a varios dispositivos dentro de la misma red, pero no encajaba con los requisitos del video wall
  • No era un sistema diseñado para que el video estuviera perfectamente sincronizado
  • No se trataba de mostrar el mismo video repetido en 10 pantallas, sino de dividir un video largo en 10 partes y mostrar una entrada distinta en cada pantalla

Sincronización de la reproducción con c-sync

• Se creó c-sync, un sistema servidor/cliente en ExpressJS que usa una página web y socket.io para sincronizar la reproducción de video entre clientes
• La estructura básica era que, cuando el servidor enviaba un evento play, el elemento <video> de cada cliente comenzaba a reproducirse
• En pruebas con computadoras de escritorio parecía sincronizar bastante bien, pero en las Chromebooks reales no se mantenía estable por falta de rendimiento
  • Diferencias en el tiempo de carga
  • Latencia de red
  • Diferencias entre relojes del sistema
• El enfoque final cambió para que cada cliente emitiera un evento start al llegar al final del video
  • Así, la computadora más lenta hacía esperar a las más rápidas, dando tiempo para cargar el video
  • Cada pantalla podía recibir 10 eventos start, por lo que el punto de loop podía oscilar ligeramente
  • Si los primeros fotogramas del video eran iguales, al usuario le resultaba difícil notar la diferencia
• La reproducción programada basada en timestamps también parecía posible, pero estas Chromebooks no podían mantener sus relojes sincronizados de forma estable a nivel de milisegundos, así que no funcionó

Trabajo de firmware para salir de ChromeOS

• En uno o dos meses se llegó a la etapa de abrir manualmente la página web y mostrar el video sincronizado a pantalla completa
• Para usarlo como una instalación real, debía arrancar automáticamente al recibir energía y abrir la página cliente de c-sync
• El ChromeOS predeterminado arrancaba en una pantalla de inicio de sesión de Google bloqueada al dominio de la escuela, y sin batería no se encendía automáticamente aunque se conectara la corriente
• Se usó el ChromeOS Firmware Recovery Script de MrChromebox para trabajar con la motherboard GLIMMER
  • Entrar en Recovery Mode
  • Activar Developer Mode
  • Ejecutar el script desde ChromeOS Shell
• Algunas Chromebooks se negaban a entrar en Developer Mode por Enterprise Enrolment, y aun en las máquinas donde se logró instalar Linux, después de un tiempo la reproducción de video se detenía o todo el sistema se bloqueaba
• La solución fue quitar el tornillo de Write Protection de cada motherboard de laptop y sobrescribir todo el firmware base con coreboot
  • Este proceso también pareció sortear las restricciones de registro
  • Había que repetirlo en más de 20 computadoras, así que fue lento y engorroso
  • Después, Wake on AC funcionó como una función de firmware y la reproducción de video dejó de romperse al azar

Crear un kiosco Linux con arranque automático

• Al principio se usaba un script de inicio que abría Chromium y simulaba pulsaciones de teclas para ponerlo en pantalla completa
• FullPageOS ya se había usado en un proyecto anterior, pero no funcionaba en hardware x86
• Porteus Kiosk funcionó bien porque es una distribución Linux mínima que ejecuta Chromium en pantalla completa y permite configurar flags para reproducir video sin interacción del usuario
• Sin embargo, Porteus Kiosk tenía obstáculos para operar la instalación real
  • No se podía cambiar la pantalla splash con el logo de Porteus que aparecía en cada arranque
  • Después de instalar, no se podían hacer cambios remotos como modificar la URL de la página, lo que podía ser un problema una vez montado en la pared
• Para armar una configuración cercana a una distribución propia, se intentó ejecutar automáticamente Chromium en modo kiosco sobre un sistema mínimo, sin entorno de escritorio
• NixOS falló durante la instalación por el poco espacio de almacenamiento de las Chromebooks
• Luego se escribió un script de aprovisionamiento basado en una instalación mínima de Debian
  • Generar KIOSK_ID
  • Configurar el hostname como csync-client-$KIOSK_ID
  • Conectarse al WiFi de la escuela
  • Crear usuario y permisos
  • Iniciar automáticamente Chromium en modo kiosco de pantalla completa con openbox
• Como instalar Debian manualmente era tedioso, se usaron FAI - Fully Automatic Installation y FAI.me
• Al final se creó un único USB que, al conectarlo a una Chromebook con coreboot, la aprovisionaba automáticamente como cliente de c-sync
• También se agregó a c-sync un controller para administrar los clientes conectados y asignar video a cada cliente
• Tras una prueba de estrés de 3 días en la que la reproducción se mantuvo fluida, se pasó a la etapa de montaje en la pared

Montaje, energía y manejo del calor

• El hardware de montaje fue diseñado por Aksel Salmi y usaba una estructura que permitía colgar en la pared la motherboard y la pantalla
• La fuente de alimentación se armó empalmando cables para que cada adaptador pudiera alimentar dos computadoras
• Después de la instalación, el mayor problema fue el calor: los ventiladores de las laptops no giraban tras el proceso de borrar el firmware
• Se puede acceder al ChromeOS Embedded Controller con ectool, lo que permite configurar manualmente la velocidad de los ventiladores
• Había poca documentación en línea y resultaba confuso que coreboot y el ectool de Google fueran distintos, pero un binario obtenido mediante Wayback Machine funcionó correctamente para configurar la velocidad de los ventiladores
• Tras las pruebas, se encontró un valor de velocidad de ventilador que equilibraba ruido y temperatura

Producción de video para 10 pantallas

• Cada pantalla tiene una resolución de 1366×768, por lo que el video total para las 10 pantallas es de 13660×768
• No había mucho software capaz de editar un video tan ancho; en la práctica solo pudieron usarse Final Cut Pro y Blender
• Tras renderizar el video de ancho completo, se usó ffmpeg para cortarlo en 10 secciones y asignarlas a cada pantalla
• El script de división genera segmentos según la posición de cada pantalla, con una forma como crop=1366:768:x_offset:0

Resultado final y limitaciones pendientes

• El video wall terminado incluye una secuencia de arranque, un proceso que parece de autocalibración, reproducción de video sincronizada, además de enclosure y enrutado de cables
• El resultado no es perfecto
  • Los ángulos de visión de los paneles TN no son buenos
  • Los colores varían entre pantallas
  • La sincronización no es perfecta
  • En cada decisión podría haber habido mejores alternativas
• Aun así, se completó como un resultado que convierte residuos electrónicos en una instalación interesante y demuestra diseño iterativo y colaboración en equipo

[GN⁺]

Opiniones en Hacker News

• Felicitaciones por completar un proyecto tan divertido. He trabajado bastante en sincronización de medios entre varios dispositivos, así que siempre disfruto ver qué soluciones se le ocurren a la gente.
  La forma estándar de la industria para crear un video wall sincronizado como este es usar reproductores multimedia BrightSign, pero con unas 20 pantallas, solo el costo de comprar los reproductores y las pantallas puede subir fácilmente a decenas de miles de dólares. Es realmente impresionante que lo hayan hecho funcionar con equipos reciclados.
  Si te interesa trabajar en bases de código relacionadas con sincronización de medios, puedes contactarme. Contratamos desarrolladores freelance con bastante frecuencia.

  • Gracias. No lo puse en el post del blog, pero también revisé las listas de precios de soluciones comerciales, y eran realmente caras.
    Siempre me dio curiosidad qué proporción del costo corresponde al hardware y cuál al software, y supongo que la señalización digital profesional está diseñada considerando también aspectos como confiabilidad y vida útil.

• Cuando salió la Chromebook, yo trabajaba en Google, y cuando pidieron ideas para decorar el lobby propuse algo parecido, pero lo rechazaron. Tal vez fue porque pedí entre 40 y 64 dispositivos.
  Aunque no creo que hubiera intentado sincronizar video; más bien habría creado animaciones basadas en tiempo y sincronizado los relojes por red.
  Se puede ver un ejemplo aquí: https://www.youtube.com/watch?v=64TcBiqmVko
  Son 8 dispositivos corriendo Chrome, y lo único sincronizado son la configuración y la hora. Los dispositivos ni siquiera tienen que estar en una cuadrícula; la inspiración fue el acuario virtual del Boston Science Museum.

  • El autor también lo intentó, pero los relojes no lograron mantenerse sincronizados. Está en una nota lateral plegable.
    Dice: “Lamentablemente, estas Chromebooks no podían mantener sus horas alineadas de forma confiable entre sí a nivel de milisegundos, así que este método no nos funcionó”.
  • Si es contenido multimedia fijo, y no algo generado dinámicamente en tiempo real o transmitido por streaming, este truco puede llevarte bastante lejos. Incluso si es generativo, puede funcionar si el tiempo se usa como valor para impulsar la animación.
    Como mencionaste, necesitas una buena sincronización de relojes, y especialmente si hay audio, una diferencia de 20 a 30 ms se nota muchísimo, así que no es fácil. Aun así, con NTP/PTP se puede llegar bastante lejos.

• Genial. Hice algo parecido con tablets en una configuración 4x4, conecté las 16 por ADB a un solo host y pude automatizar casi todo.
  Después, en sway, creé 16 pantallas virtuales y 16 clientes VNC, y probé transmitiendo todo por Wi-Fi; el Wi-Fi funcionó tan bien que no busqué una solución más eficiente.
  Durante ese período mi PC tenía 19 pantallas, 17 de ellas por VNC, y era espectacular. Podía hacer lo mismo en todas, o usar cada una para algo distinto, como música, htop, calendario, reloj o sesiones ssh.
  Eso sí, lidiar con el hardware fue bastante molesto. Algunas tenían throttling, otras problemas de conexión, y algunas baterías no lograban mantenerse cargadas.

• Hace mucho tiempo existía algo parecido llamado Junkyard Jumbotron. Permitía juntar pantallas dispares para mostrar cada una una parte de una imagen más grande.
  https://github.com/mitmedialab/Junkyard-Jumbotron
  Video: https://youtu.be/cAUtSVSTbzU?feature=shared

  • El Media Lab hace muchísimas cosas aleatorias y divertidas. Sería interesante recrear esto con tecnologías web modernas.
    El método de enviar por email una foto para la alineación también suena bastante divertido.

• Si solo lo leíste por encima y no viste todo el blog, este proyecto fue hecho por estudiantes de preparatoria mientras estaban en la preparatoria. Eso lo hace aún más impresionante.

• Al ver las partes de “No estoy completamente seguro de por qué funciona tan bien, pero se me ocurrió por accidente una solución absurda” y “la computadora más lenta frena a la más rápida”, la razón por la que funciona tan bien es que optimizaron el diseño del sistema alrededor del cuello de botella.
  Vale la pena ver la teoría de las restricciones.

• Una vez tuve que hacer algo parecido con 5 televisores táctiles grandes colocados como una mesa. Cada lado tenía que ser una app táctil independiente, y todos reproducían un video sincronizado de fondo mientras los usuarios interactuaban con elementos que fluían de un extremo al otro, o enviaban objetos encontrados a usuarios del lado opuesto de la mesa.
  Al final, casi el único equipo dentro del presupuesto que podía manejar todas las pantallas a la vez era el Mac Pro cilíndrico, así que usamos eso, y las apps se sincronizaban con Redis. Esa parte la escribí yo.
  Funcionó bastante bien, pero no llegué a ver el producto terminado antes de irme de la empresa. Originalmente queríamos sincronizar computadoras separadas, pero no pudimos hacerlo lo suficientemente estable; funcionaba un rato y luego la sincronización se desviaba por varios factores, así que había que reiniciar periódicamente la aplicación, lo cual no era viable.
  Desde los inicios de la PC siempre quise tener la capacidad de unir varios equipos por red para compartir recursos y cooperar más. Me imaginaba usar todas las computadoras de una oficina como una supercomputadora para procesar tareas. Claro que es un problema muy difícil, y las apps y los sistemas operativos tendrían que estar diseñados de esa forma, además de requerir nuevos algoritmos. Más aún si consideramos que incluso tomó mucho tiempo aprovechar bien múltiples procesadores dentro de una sola máquina en la misma placa. Pero proyectos como seti@home o folding@home hicieron algo de eso, y siempre esperé que algún día las propias computadoras lo soportaran.

  • Eso se llama computación distribuida (https://en.m.wikipedia.org/wiki/Distributed_computing) y es posible desde hace mucho tiempo con Linux/BSD.

• Al ver la parte que dice: “Empecé a crear ‘mi propia distribución’ que pudiera instalar en las laptops. El sistema tenía que arrancar con una configuración mínima y tener un script elegante que iniciara automáticamente una instancia de Chromium en modo kiosk, sin entorno de escritorio. Primero probé NixOS, pero pronto me di cuenta de que el almacenamiento de estas Chromebooks era demasiado pequeño y no era posible; además, cada instalación fallaba. Al final me rendí y empecé con una instalación mínima de Debian, pero me di cuenta de que instalar Debian requería presionar demasiados botones y era una enorme pérdida de tiempo, y descubrí ‘FAI - Fully Automatic Installation’ y la herramienta web FAI.me”, DietPi, OpenWrt y OpenBalena también tienen opciones de instalación automática para instalar paquetes específicos en bare metal mínimo.
  Me da curiosidad si hay más alternativas sin escritorio.

• Lo más interesante es que al cambiar a coreboot se resolvieron los cuelgues. Me pregunto si hay alguna teoría de por qué.
  Podría estar relacionado con ACPI/DSDT, o quizá el BIOS original inicializaba mal algún controlador de hardware.

  • Tal vez se activaba un watchdog timer.