Die originellste Video Wall aus Chromebooks

 (varun.ch)
1 Punkte von GN⁺ 2025-03-02 | 1 Kommentare | Auf WhatsApp teilen
  • Es dauerte etwa 3 Jahre, aus ausgemusterten schulischen Lenovo ThinkPad 11e Chromebooks durch Zerlegen und Wiederverwertung eine Video Wall mit 10 Bildschirmen zu bauen
  • Statt eines separaten Display-Controllers treibt das vorhandene Laptop-Mainboard jeden Bildschirm an, und ein webbasiertes Synchronisierungssystem teilt ein einziges Video in 10 Stücke zur Wiedergabe auf
  • Das auf socket.io basierende c-sync hatte mit langsamer Leistung, unterschiedlichen Ladezeiten, Latenz und Problemen mit den Systemuhren zu kämpfen, erreichte aber eine nahezu synchronisierte Wiedergabe, indem die Schleife an den langsamsten Client angepasst wurde
  • Probleme mit der Unternehmensregistrierung von ChromeOS, Einschränkungen des Entwicklermodus und der Stromversorgung nach dem Entfernen des Akkus wurden mit coreboot, den MrChromebox-Tools, einem Debian-Auto-Installations-USB und ectool zur Lüftersteuerung umgangen
  • Eingeschränkte Blickwinkel der TN-Panels, Farbunterschiede und keine perfekte Synchronisierung blieben bestehen, aber das Projekt zeigt, wie Elektroschrott durch Zusammenarbeit und iterative Entwicklung in eine funktionierende Installation verwandelt werden kann

Eine Video Wall aus ausgemusterten Chromebooks

  • Das Projekt begann damit, dass die Schule ihre alten Chromebooks entsorgen wollte und die Frage aufkam, was sich daraus machen ließe
  • Verwendet wurde das Lenovo ThinkPad 11e, ein Schul-Laptop, das jedoch keine Google-Software-Updates mehr erhielt
  • Die meisten Geräte hatten schon beim Laden von Webseiten Mühe und waren an eine alte Enterprise Enrolment-Registrierung gebunden, sodass sie ohne ein Google-Konto der Schule kaum nutzbar waren
  • Ziel war es, eine Video Wall zu bauen, bei der mehrere Bildschirme wie ein einziges großes Display angeordnet und betrieben werden

Display-Ansteuerung und Synchronisationsversuche

  • Zunächst wurde erwogen, nur die Laptop-Display-Panels auszubauen und alle 10 Bildschirme gleichzeitig von einem einzigen leistungsstarken Computer anzusteuern
  • Das war zeit- und kostenintensiv, und da die Bildschirme bereits an funktionierenden Laptops hingen, wurde stattdessen jeder Bildschirm über sein eigenes Laptop-Mainboard betrieben
  • Es gab auch Versuche mit VLC-Streaming, um Videos an mehrere Geräte im selben Netzwerk zu senden, doch das passte nicht zu den Anforderungen der Video Wall
    • Das System war nicht für perfekte Synchronisierung ausgelegt
    • Statt dasselbe Video 10-mal zu zeigen, musste ein langes Video in 10 Stücke geteilt werden, sodass jeder Bildschirm einen anderen Ausschnitt erhielt

Mit c-sync das Playback-Timing abstimmen

  • Es wurde ein ExpressJS-Server/Client-System namens c-sync entwickelt, das per Webseite und socket.io die Videowiedergabe zwischen Clients abstimmt
  • Grundsätzlich schickte der Server ein play-Event, worauf das <video>-Element jedes Clients die Wiedergabe startete
  • In Tests auf Desktop-Computern wirkte die Synchronisierung recht gut, auf den tatsächlichen Chromebooks war sie wegen der schwachen Leistung jedoch nicht stabil
    • Unterschiedliche Ladezeiten
    • Netzwerklatenz
    • Unterschiede bei den Systemuhren
  • Die finale Methode wurde so geändert, dass jeder Client beim Erreichen des Videoendes ein start-Event sendet
    • Der langsamste Computer zwingt die schnelleren zum Warten und verschafft ihnen so genug Zeit zum Laden des Videos
    • Jeder Bildschirm kann 10 start-Events empfangen, wodurch der Loop-Zeitpunkt leicht schwanken kann
    • Wenn die ersten Frames des Videos identisch sind, fällt der Unterschied den Nutzern kaum auf
  • Eine geplante Wiedergabe auf Basis von Zeitstempeln schien ebenfalls möglich, funktionierte aber nicht, weil diese Chromebooks ihre Uhren nicht zuverlässig auf Millisekundenebene synchron halten konnten

Firmware-Arbeit, um ChromeOS zu verlassen

  • Nach ein bis zwei Monaten war ein Stand erreicht, bei dem sich per Hand eine Webseite öffnen ließ, die ein synchronisiertes Vollbild-Video zeigte
  • Für den Einsatz als echte Installation musste das System beim Einschalten automatisch booten und die c-sync-Client-Seite öffnen
  • Das standardmäßige ChromeOS startete jedoch in einen Google-Login-Bildschirm, der an die Schuldomäne gebunden war, und ohne Akku schalteten sich die Geräte beim Anlegen von Strom nicht automatisch ein
  • Mit dem ChromeOS Firmware Recovery Script von MrChromebox wurde auf dem GLIMMER-Mainboard gearbeitet
    • Wechsel in den Recovery Mode
    • Aktivierung des Developer Mode
    • Ausführen des Skripts in der ChromeOS Shell
  • Einige Chromebooks verweigerten wegen Enterprise Enrolment den Wechsel in den Developer Mode, und selbst Geräte mit erfolgreicher Linux-Installation stoppten nach einiger Zeit die Videowiedergabe oder froren komplett ein
  • Die Lösung bestand darin, auf jedem Laptop-Mainboard die Write-Protection-Schraube zu entfernen und die komplette Standard-Firmware mit coreboot zu überschreiben
    • Dadurch wurden offenbar auch die Registrierungsbeschränkungen umgangen
    • Da dies auf mehr als 20 Computern wiederholt werden musste, war es langsam und mühsam
    • Danach funktionierte Wake on AC als Firmware-Feature, und die Videowiedergabe brach nicht mehr zufällig ab

Ein Linux-Kiosk mit Auto-Boot

  • Anfangs wurde ein Startskript genutzt, das Chromium öffnete und per simulierten Tastendrücken in den Vollbildmodus wechselte
  • FullPageOS war schon in einem früheren Projekt ausprobiert worden, lief aber nicht auf x86-Hardware
  • Porteus Kiosk funktionierte gut, da diese minimale Linux-Distribution Chromium im Vollbild ausführen und Flags setzen konnte, die Videowiedergabe ohne Benutzerinteraktion erlauben
  • Allerdings hatte Porteus Kiosk Hürden für den Betrieb als echte Installation
    • Der beim Booten angezeigte Porteus-Logo-Splashscreen ließ sich nicht ersetzen
    • Nach der Installation waren Fernänderungen wie ein URL-Wechsel nicht möglich, was nach der Wandmontage problematisch sein konnte
  • Deshalb wurde versucht, etwas näher an einer eigenen Distribution zu bauen: ein minimales System ohne Desktop-Umgebung, das Chromium im Kiosk-Modus automatisch startet
  • NixOS scheiterte an dem kleinen Speicher der Chromebooks
  • Danach wurde ein Provisioning-Skript auf Basis einer minimalen Debian-Installation geschrieben
    • Erzeugen einer KIOSK_ID
    • Setzen des Hostnamens auf csync-client-$KIOSK_ID
    • Verbindung mit dem Schul-WLAN
    • Anlegen von Benutzern und Berechtigungen
    • Automatischer Start von Chromium im Vollbild-Kioskmodus mit openbox
  • Da die manuelle Debian-Installation umständlich war, kamen FAI - Fully Automatic Installation und FAI.me zum Einsatz
  • Am Ende entstand ein einzelner USB-Stick, der beim Einstecken in ein mit coreboot versehenes Chromebook automatisch das Provisioning für den c-sync-Client durchführt
  • Zu c-sync kam außerdem ein Controller hinzu, um verbundene Clients zu verwalten und ihnen Videos zuzuweisen
  • Nach einem dreitägigen Stresstest mit stabiler, flüssiger Wiedergabe ging es zum nächsten Schritt: der Wandmontage

Montage, Stromversorgung und Wärme

  • Die Montagehardware wurde von Aksel Salmi entworfen; verwendet wurde eine Konstruktion, mit der sich Mainboards und Displays an die Wand hängen lassen
  • Die Stromversorgung wurde so aufgebaut, dass durch zusammengespleißte Kabel jedes Netzteil zwei Computer mit Strom versorgen konnte
  • Nach der Installation war das größte Problem die Wärmeentwicklung, und nach dem Löschen der Firmware liefen die Lüfter der Laptops nicht mehr
  • Auf den Embedded Controller von ChromeOS ließ sich über ectool zugreifen, sodass die Lüfterdrehzahl manuell gesetzt werden konnte
  • Es gab nur wenig Online-Dokumentation, und Unterschiede zwischen coreboot und Googles ectool sorgten für Verwirrung, doch ein über die Wayback Machine gefundenes Binary funktionierte korrekt zum Setzen der Lüftergeschwindigkeit
  • Durch Tests wurde ein Lüfterwert gefunden, der einen guten Kompromiss zwischen Geräusch und Temperatur bot

Videoerstellung für 10 Bildschirme

  • Die Auflösung jedes Displays beträgt 1366×768, womit das Gesamtvideo für alle 10 Bildschirme auf 13660×768 kommt
  • Es gab nicht viele Programme, die so breite Videos bearbeiten konnten; tatsächlich waren nur Final Cut Pro und Blender nutzbar
  • Nach dem Rendern des Gesamtvideos wurde es mit ffmpeg in 10 Abschnitte geschnitten und den einzelnen Bildschirmen zugewiesen
  • Das Skript zum Aufteilen erzeugte Segmente passend zur Position jedes Bildschirms in der Form crop=1366:768:x_offset:0

Das Ergebnis und die verbleibenden Grenzen

  • Die fertige Video Wall umfasst eine Boot-Sequenz, einen Ablauf, der wie eine eigene Kalibrierung wirkt, synchronisierte Videowiedergabe sowie Gehäuse- und Kabelmanagement
  • Das Ergebnis ist nicht perfekt
    • Die Blickwinkel der TN-Panels sind schlecht
    • Die Farben unterscheiden sich von Bildschirm zu Bildschirm
    • Die Synchronisierung ist nicht perfekt
    • Für jede Entscheidung hätte es möglicherweise eine bessere Alternative gegeben
  • Trotzdem wurde aus Elektroschrott eine interessante Installation, die iterative Entwicklung und Teamarbeit sichtbar macht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-02
Meinungen auf Hacker News

  • Glückwunsch dazu, ein interessantes Projekt fertiggestellt zu haben. Ich habe viel an Mediensynchronisierung über mehrere Geräte hinweg gearbeitet, daher macht es immer Spaß zu sehen, welche Lösungen andere finden.
    Der Industriestandard für den Bau einer solchen synchronisierten Videowall ist der Einsatz von BrightSign-Mediaplayern; bei rund 20 Displays können allein die Kosten für Player und Bildschirme leicht auf Zehntausende Dollar steigen. Dass ihr das mit wiederverwendeten Geräten zum Laufen gebracht habt, ist wirklich großartig.
    Wenn du Interesse hast, an Codebasen rund um Mediensynchronisierung zu arbeiten, melde dich gern. Wir stellen ziemlich häufig freiberufliche Vertragsentwickler ein.

    • Danke. Ich konnte es nicht in den Blogpost aufnehmen, aber ich habe mir auch die Preislisten kommerzieller Lösungen angesehen, und sie waren wirklich teuer.
      Ich habe mich immer gefragt, wie sich die Kosten jeweils auf Hardware und Software verteilen, und professionelle Digital Signage ist vermutlich auch im Hinblick auf Zuverlässigkeit und Lebensdauer ausgelegt.

  • Als Chromebooks auf den Markt kamen, arbeitete ich bei Google, und als Ideen für die Lobby-Dekoration gesammelt wurden, schlug ich etwas Ähnliches vor, wurde aber abgelehnt. Vielleicht lag es daran, dass ich 40 bis 64 Geräte angefragt hatte.
    Allerdings hätte ich wohl nicht versucht, Video zu synchronisieren; stattdessen hätte ich zeitbasierte Animationen erstellt und die Uhren über das Netzwerk abgeglichen.
    Ein Beispiel gibt es hier: https://www.youtube.com/watch?v=64TcBiqmVko
    Es sind acht Geräte mit Chrome, und synchronisiert sind nur Konfiguration und Zeit. Die Geräte müssen auch nicht zwingend in einem Raster angeordnet sein; inspiriert war das virtuelle Aquarium im Boston Science Museum.

    • Der Autor hat das ebenfalls versucht, aber die Uhren blieben nicht synchron. Das steht in einer einklappbaren Randnotiz.
      Dort heißt es sinngemäß: „Leider konnten diese Chromebooks ihre Zeit nicht zuverlässig im Millisekundenbereich miteinander abgleichen, daher funktionierte dieser Ansatz für uns nicht.“
    • Bei festen Medien kann dieser Trick ziemlich weit tragen, solange sie nicht in Echtzeit dynamisch erzeugt oder gestreamt werden. Selbst bei generativen Inhalten ist es möglich, wenn die Zeit als Wert zum Antrieb der Animation verwendet wird.
      Wie gesagt braucht man eine gute Zeitsynchronisierung, und besonders mit Audio ist das nicht einfach, weil schon 20–30 ms Abweichung sehr auffallen. Mit NTP/PTP kommt man aber ziemlich weit.

  • Cool. Ich habe mit einem 4x4-Tablet-Setup etwas Ähnliches gemacht und konnte das meiste automatisieren, nachdem ich alle 16 Geräte per ADB mit einem einzigen Host verbunden hatte.
    Danach habe ich in sway 16 virtuelle Bildschirme und 16 VNC-Clients erstellt und alles per WLAN gestreamt, um es zu testen; das WLAN funktionierte so gut, dass ich keine effizientere Lösung gesucht habe.
    Während dieser Zeit hatte mein PC 19 Displays, davon 17 per VNC, und das war beeindruckend. Man konnte auf allen dasselbe machen oder sie jeweils anders nutzen, etwa für Musik, htop, Kalender, Uhr oder SSH-Sessions.
    Die Hardware zu handhaben war allerdings ziemlich lästig. Einige Geräte wurden gedrosselt, einige hatten Verbindungsprobleme, und manche Akkus hielten die Ladung nicht.

  • Vor langer Zeit gab es etwas Ähnliches namens Junkyard Jumbotron. Damit konnte man unterschiedliche Displays zusammentragen und jeweils Teile eines größeren Bildes anzeigen lassen.
    https://github.com/mitmedialab/Junkyard-Jumbotron
    Video: https://youtu.be/cAUtSVSTbzU?feature=shared

    • Das Media Lab baut wirklich jede Menge zufällig spannendes Zeug. Es wäre interessant, das mit moderner Webtechnologie neu umzusetzen.
      Auch die Methode, zur Ausrichtung ein Foto per E-Mail zu schicken, wirkt auf ihre Art interessant.

  • Falls man nur grob darüberfliegt und nicht den ganzen Blog liest: Dieses Projekt wurde von Highschool-Schülern während ihrer Schulzeit gebaut. Das macht es noch beeindruckender.

  • Wenn man die Stellen „Ich bin mir nicht ganz sicher, warum das so gut funktioniert, aber zufällig kam ich auf eine absurde Lösung“ und „Der langsamste Computer hält den schnellsten Computer zurück“ betrachtet, funktioniert es deshalb gut, weil das Systemdesign auf den Engpass hin optimiert wurde.
    Ein Blick auf die Theory of Constraints lohnt sich.

  • Ich musste einmal etwas Ähnliches mit fünf großen Touchscreen-TVs machen, die wie ein Tisch angeordnet waren. Jede Seite sollte eine eigene Touchscreen-App sein, während alle im Hintergrund ein synchronisiertes Video abspielten und Nutzer mit Elementen interagieren konnten, die von einem Ende zum anderen flossen, oder gefundene Objekte an Nutzer auf der anderen Tischseite schicken konnten.
    Am Ende war praktisch das einzige Gerät innerhalb des Budgets, das alle Bildschirme gleichzeitig antreiben konnte, der zylinderförmige Mac Pro, also nutzten wir den, und die Apps wurden über Redis synchronisiert. Diesen Teil habe ich geschrieben.
    Es funktionierte ziemlich gut, aber bevor ich das Unternehmen verließ, habe ich das fertige Produkt nicht mehr gesehen. Ursprünglich wollten wir separate Computer synchronisieren, bekamen es aber nicht zuverlässig genug hin; es lief kurz und geriet dann durch verschiedene Faktoren aus dem Takt, sodass die Anwendung regelmäßig hätte neu gestartet werden müssen, was nicht möglich war.
    Seit den frühen PC-Tagen habe ich mir immer gewünscht, mehrere Geräte über ein Netzwerk zusammenzuschalten, Ressourcen zu teilen und sie enger zusammenarbeiten zu lassen. Ich stellte mir vor, alle Computer im Büro wie einen Supercomputer für Aufgaben zu nutzen. Natürlich ist das ein sehr schwieriges Problem; Apps und Betriebssysteme müssten dafür entsprechend entworfen sein, und es bräuchte neue Algorithmen. Wenn man bedenkt, wie lange es gedauert hat, mehrere Prozessoren selbst innerhalb eines einzelnen Geräts auf demselben Board richtig auszunutzen, gilt das umso mehr. Projekte wie seti@home oder folding@home haben so etwas immerhin teilweise getan, und ich hoffte, dass Computer eines Tages selbst Unterstützung dafür bieten würden.

  • Zur Passage „Ich begann, ‚meine Distribution‘ zu bauen, die auf den Laptops installiert werden konnte. Das System sollte minimal starten und ein elegantes Skript haben, das automatisch eine Chromium-Instanz im Kiosk-Modus ohne Desktop-Umgebung startet. Zuerst versuchte ich es mit NixOS, merkte aber schnell, dass der Speicherplatz dieser Chromebooks zu klein war und es nicht möglich war; jede Installation schlug fehl. Schließlich gab ich auf und begann mit einer minimalen Debian-Installation, stellte aber fest, dass die Debian-Installation zu viele Tastendrücke erfordert und damit zu viel Zeit verschwendet, und entdeckte ‚FAI – Fully Automatic Installation‘ sowie das Webtool FAI.me“: DietPi, OpenWrt und OpenBalena bieten ebenfalls automatische Installationsoptionen, mit denen bestimmte Pakete ausgewählt und auf minimalem Bare Metal installiert werden können.
    Ich frage mich, ob es noch weitere Nicht-Desktop-Optionen gibt.

  • Am interessantesten ist, dass der Wechsel zu coreboot die Hänger behoben hat. Ich frage mich, ob es dazu eine Theorie gibt.
    Es könnte mit ACPI/DSDT zusammenhängen, oder vielleicht hat das ursprüngliche BIOS die Hardware-Controller falsch initialisiert.

    • Vielleicht wurde ein Watchdog-Timer ausgelöst.