- Il a fallu environ trois ans pour démonter et réutiliser des Chromebooks Lenovo ThinkPad 11e fournis par une école et destinés à être mis au rebut, afin de créer un mur vidéo à 10 écrans
- Au lieu d’un contrôleur d’affichage séparé, les cartes mères des ordinateurs portables existants pilotent chaque écran, tandis qu’un système de synchronisation web découpe une même vidéo en 10 morceaux et les lit simultanément
c-sync, basé sursocket.io, a souffert de performances lentes, de différences de temps de chargement, de latence et de problèmes d’horloge système, mais il parvient à une lecture presque synchronisée en ralentissant la boucle sur le client le plus lent- L’enregistrement d’entreprise de ChromeOS, les restrictions du mode développeur et les problèmes d’alimentation après retrait de la batterie ont été contournés avec coreboot, les outils MrChromebox, une clé USB d’installation automatique de Debian et le contrôle des ventilateurs via
ectool - Malgré les angles de vision des dalles TN, les différences de couleur et une synchronisation imparfaite, c’est un exemple de transformation de déchets électroniques en installation réellement fonctionnelle grâce à la collaboration et à une conception itérative
Un mur vidéo parti de Chromebooks destinés au rebut
- Le projet a démarré lorsque l’école s’apprêtait à jeter ses anciens Chromebooks, avec l’idée de voir ce qu’il était possible d’en faire
- Les machines utilisées étaient des Lenovo ThinkPad 11e, des ordinateurs portables fournis par l’école qui ne recevaient plus de mises à jour logicielles de Google
- La plupart peinaient même à charger des pages web, et comme ils étaient encore liés à un ancien Enterprise Enrolment, ils étaient difficiles à utiliser sans compte Google de l’école
- L’objectif était de créer un mur vidéo fonctionnant comme un grand écran unique en disposant plusieurs écrans côte à côte
Pilotage des écrans et expériences de synchronisation
- Au départ, l’idée était de ne récupérer que les dalles d’écran des ordinateurs portables et de piloter les 10 écrans simultanément depuis un seul ordinateur puissant
- Comme cela aurait demandé beaucoup de temps et d’argent, et que les écrans étaient déjà attachés à des ordinateurs portables fonctionnels, le projet a basculé vers une solution où chaque écran est piloté par sa propre carte mère d’ordinateur portable
- Des essais ont aussi été menés avec le streaming VLC pour envoyer une vidéo à plusieurs appareils sur le même réseau, mais cela ne répondait pas aux exigences du mur vidéo
- Le système n’était pas conçu pour que la vidéo soit parfaitement synchronisée
- Il ne s’agissait pas d’afficher la même vidéo en boucle sur 10 écrans, mais de découper une longue vidéo en 10 morceaux et d’afficher une entrée différente sur chaque écran
Synchroniser le timing de lecture avec c-sync
- Un système serveur/client ExpressJS nommé
c-synca été créé, utilisant une page web etsocket.iopour synchroniser la lecture vidéo entre clients - Le principe de base était que le serveur envoyait un événement
play, puis l’élément<video>de chaque client commençait la lecture - Lors des tests sur ordinateurs de bureau, la synchronisation semblait assez bonne, mais sur les Chromebooks réels, le manque de performances empêchait une synchronisation stable
- Différences de temps de chargement
- Latence réseau
- Différences d’horloge système
- La solution finale a été modifiée pour que chaque client émette un événement
startlorsqu’il atteint la fin de la vidéo- L’ordinateur le plus lent oblige les plus rapides à attendre, ce qui laisse le temps de charger la vidéo
- Chaque écran pouvant recevoir 10 événements
start, le moment de relance de la boucle peut légèrement fluctuer - Si les premières images de la vidéo sont identiques, l’utilisateur remarque difficilement la différence
- Une lecture planifiée à partir d’horodatages semblait aussi possible, mais ces Chromebooks ne parvenaient pas à maintenir entre eux une synchronisation temporelle fiable à la milliseconde, ce qui empêchait cette approche de fonctionner
Travail sur le firmware pour sortir de ChromeOS
- En un ou deux mois, le projet en était arrivé au stade où une page web pouvait être ouverte manuellement pour afficher une vidéo synchronisée en plein écran
- Pour en faire une installation réelle, il fallait que les machines démarrent automatiquement à la mise sous tension et ouvrent la page client
c-sync - Par défaut, ChromeOS démarrait sur un écran de connexion Google verrouillé sur le domaine de l’école, et une fois la batterie retirée, les machines ne s’allumaient pas automatiquement lorsque l’alimentation était branchée
- Le ChromeOS Firmware Recovery Script de MrChromebox a été utilisé pour intervenir sur les cartes mères GLIMMER
- Entrée en Recovery Mode
- Activation du Developer Mode
- Exécution du script depuis le ChromeOS Shell
- Certains Chromebooks refusaient d’entrer en Developer Mode à cause de l’Enterprise Enrolment, et même sur les machines où l’installation de Linux avait réussi, la lecture vidéo finissait par s’arrêter ou tout le système se verrouillait
- La solution a consisté à retirer la vis de Write Protection sur chaque carte mère d’ordinateur portable, puis à remplacer entièrement le firmware d’origine par
coreboot- Ce processus semblait aussi contourner les restrictions d’enregistrement
- Il a fallu le répéter sur plus de 20 ordinateurs, ce qui était lent et fastidieux
- Ensuite,
Wake on ACfonctionnait comme fonctionnalité du firmware, et la lecture vidéo ne se corrompait plus aléatoirement
Créer un kiosque Linux à démarrage automatique
- Au départ, un script de démarrage ouvrait Chromium et simulait des frappes clavier pour passer en plein écran
FullPageOSavait déjà été utilisé dans un projet précédent, mais ne fonctionnait pas sur le matériel x86- Porteus Kiosk, une distribution Linux minimale, fonctionnait bien car elle lance Chromium en plein écran et permet de définir les flags autorisant la lecture vidéo sans interaction utilisateur
- Cependant, Porteus Kiosk présentait des obstacles pour l’exploitation réelle de l’installation
- Impossible de modifier l’écran de démarrage affichant le logo Porteus à chaque boot
- Impossible d’effectuer des opérations distantes comme changer l’URL de la page après installation, ce qui pouvait poser problème une fois les machines fixées au mur
- Pour obtenir une configuration proche d’une distribution maison, une approche a été tentée avec un système minimal lançant automatiquement Chromium en mode kiosk sans environnement de bureau
- L’installation de NixOS a échoué à cause de la faible capacité de stockage des Chromebooks
- Un script de provisionnement a ensuite été écrit sur la base d’une installation minimale de Debian
- Génération de
KIOSK_ID - Définition du nom d’hôte en
csync-client-$KIOSK_ID - Connexion au Wi-Fi de l’école
- Création de l’utilisateur et des permissions
- Lancement automatique de Chromium en mode kiosk plein écran avec
openbox
- Génération de
- Comme l’installation manuelle de Debian était pénible, FAI - Fully Automatic Installation et FAI.me ont été utilisés
- Au final, une clé USB unique a été créée : insérée dans un Chromebook équipé de
coreboot, elle le provisionne automatiquement en clientc-sync - Un controller a aussi été ajouté à
c-syncpour gérer les clients connectés et attribuer une vidéo à chacun - Après un stress test de trois jours avec une lecture restée fluide, le projet est passé à l’étape de fixation au mur
Fixation, alimentation et gestion thermique
- Le matériel de fixation a été conçu par Aksel Salmi, avec une structure permettant d’accrocher les cartes mères et les écrans au mur
- L’alimentation a été configurée en reliant des câbles afin que chaque adaptateur puisse alimenter deux ordinateurs
- Après l’installation, le principal problème a été la chaleur, car les ventilateurs des ordinateurs portables ne tournaient plus après l’effacement du firmware
- Il est possible d’accéder à l’Embedded Controller de ChromeOS avec
ectoolafin de régler manuellement la vitesse des ventilateurs - La documentation en ligne était limitée, et la différence entre
ectoolcôtécorebootet côté Google a créé de la confusion, mais un binaire récupéré via la Wayback Machine a permis de régler correctement la vitesse des ventilateurs - Après des tests, une valeur de vitesse de ventilateur offrant un bon équilibre entre bruit et température a été trouvée
Production de la vidéo pour 10 écrans
- Chaque écran a une résolution de 1366×768, ce qui donne une vidéo globale de 13660×768 pour les 10 écrans
- Peu de logiciels permettent de monter une vidéo aussi large ; en pratique, seuls Final Cut Pro et Blender étaient utilisables
- Après rendu de la vidéo en pleine largeur,
ffmpega été utilisé pour la découper en 10 segments et les attribuer à chaque écran - Le script de découpage génère les segments correspondant à la position de chaque écran sous la forme
crop=1366:768:x_offset:0
Résultat final et limites restantes
- Le mur vidéo terminé comprend une séquence de démarrage, un processus ressemblant à un auto-étalonnage, la lecture d’une vidéo synchronisée, ainsi que le boîtier et le routage des câbles
- Le résultat n’est pas parfait
- Les angles de vision des dalles TN sont médiocres
- Les couleurs varient d’un écran à l’autre
- La synchronisation n’est pas parfaite
- De meilleures alternatives auraient peut-être existé pour chaque décision
- Malgré cela, le projet transforme des déchets électroniques en installation intéressante et aboutit à un résultat qui illustre la conception itérative et la collaboration en équipe
1 commentaires
Avis de Hacker News
Félicitations pour avoir mené à bien ce projet amusant. Ayant beaucoup travaillé sur la synchronisation de médias entre plusieurs appareils, j’aime toujours voir les solutions que les gens imaginent.
La méthode standard du secteur pour créer ce type de mur vidéo synchronisé consiste à utiliser des lecteurs multimédias BrightSign, mais pour une vingtaine d’écrans, le seul coût des lecteurs et des écrans peut facilement grimper à plusieurs dizaines de milliers de dollars. C’est vraiment impressionnant de l’avoir fait fonctionner avec du matériel recyclé.
Si travailler sur une base de code liée à la synchronisation de médias t’intéresse, n’hésite pas à me contacter. Nous recrutons assez souvent des développeurs contractuels freelance.
Je me suis toujours demandé quelle part du coût revenait respectivement au matériel et au logiciel, et j’imagine que l’affichage dynamique professionnel est aussi conçu en tenant compte de la fiabilité, de la durée de vie, etc.
Je travaillais chez Google au lancement du Chromebook, et quand ils ont sollicité des idées de décoration pour le hall, j’ai proposé quelque chose de similaire, mais cela a été refusé. Peut-être parce que je demandais 40 à 64 appareils.
Cela dit, je n’aurais probablement pas essayé de synchroniser de la vidéo ; j’aurais plutôt créé des animations basées sur le temps et synchronisé les horloges via le réseau.
On peut voir un exemple ici : https://www.youtube.com/watch?v=64TcBiqmVko
Il s’agit de 8 appareils faisant tourner Chrome, et seuls la configuration et l’heure sont synchronisées. Les appareils n’ont même pas besoin d’être disposés en grille, et c’était inspiré de l’aquarium virtuel du Boston Science Museum.
Il y est dit : « Malheureusement, ces Chromebooks n’arrivaient pas à maintenir de façon fiable une synchronisation à la milliseconde entre eux, donc cette approche n’a pas fonctionné pour nous. »
Comme mentionné, il faut une bonne synchronisation des horloges, et ce n’est pas simple, surtout avec de l’audio, où un écart de 20 à 30 ms est très perceptible. Cela dit, avec NTP/PTP, on peut déjà aller assez loin.
Génial. J’ai fait quelque chose de similaire avec des tablettes en 4x4 : les 16 étaient toutes connectées via ADB à un seul hôte, ce qui m’a permis d’automatiser la plupart des choses.
Ensuite, dans sway, j’ai créé 16 écrans virtuels et 16 clients VNC, puis j’ai tout streamé en Wi-Fi pour tester ; le Wi-Fi fonctionnait tellement bien que je n’ai pas cherché de solution plus efficace.
Pendant cette période, mon PC avait 19 écrans, dont 17 en VNC, et c’était spectaculaire. On pouvait faire la même chose sur tous, ou les utiliser séparément pour de la musique, htop, un calendrier, une horloge, des sessions ssh, etc.
En revanche, gérer le matériel était assez pénible. Certains appareils subissaient du throttling, certains avaient des problèmes de connexion, et certaines batteries n’arrivaient pas à rester chargées.
Il y avait quelque chose de similaire il y a longtemps : Junkyard Jumbotron. Cela permettait de rassembler des écrans disparates pour afficher chacun une partie d’une image plus grande.
https://github.com/mitmedialab/Junkyard-Jumbotron
Vidéo : https://youtu.be/cAUtSVSTbzU?feature=shared
La méthode consistant à envoyer par e-mail une photo pour l’alignement paraît aussi assez amusante.
Si vous avez seulement parcouru rapidement l’article sans lire tout le blog, ce projet a été réalisé par des lycéens pendant leurs années de lycée. Cela le rend encore plus impressionnant.
Les passages « je ne suis pas entièrement sûr de la raison pour laquelle ça fonctionne aussi bien, mais je suis tombé par hasard sur une solution absurde » et « l’ordinateur le plus lent retient l’ordinateur le plus rapide » montrent que cela fonctionne parce que la conception du système a été optimisée autour du goulot d’étranglement.
Il faut regarder du côté de la théorie des contraintes.
Une fois, j’ai dû faire quelque chose de similaire avec cinq grands téléviseurs tactiles disposés comme une table. Chaque face devait être une application tactile distincte, toutes lisant en arrière-plan une vidéo synchronisée, pendant que les utilisateurs interagissaient avec des éléments qui circulaient d’un bout à l’autre, ou envoyaient des objets trouvés à un utilisateur de l’autre côté de la table.
Au final, le seul équipement dans le budget capable de piloter tous les écrans en même temps était à peu près le Mac Pro cylindrique, donc nous l’avons utilisé, et les applications étaient synchronisées avec Redis. C’est la partie que j’ai écrite.
Cela fonctionnait plutôt bien, mais je n’ai pas vu le produit fini avant de quitter l’entreprise. À l’origine, nous voulions synchroniser des ordinateurs séparés, mais nous n’avons pas réussi à obtenir une fiabilité suffisante : cela marchait un moment, puis divers facteurs faisaient dériver la synchronisation et il fallait redémarrer périodiquement l’application, ce qui n’était pas envisageable.
Depuis les débuts du PC, j’ai toujours souhaité pouvoir relier plusieurs machines en réseau pour partager les ressources et les faire collaborer davantage. J’imaginais utiliser tous les ordinateurs d’un bureau comme un supercalculateur pour traiter des tâches. Bien sûr, c’est un problème très difficile, les applications et les systèmes d’exploitation doivent être conçus ainsi, et il faut aussi de nouveaux algorithmes. C’est d’autant plus vrai quand on voit le temps qu’il a fallu pour exploiter correctement plusieurs processeurs dans une seule machine sur la même carte, mais des projets comme seti@home ou folding@home ont fait ce genre de choses dans une certaine mesure, et j’espérais qu’un jour les ordinateurs eux-mêmes le prendraient en charge.
Dans le passage « J’ai commencé à créer “ma distribution” à installer sur les ordinateurs portables. Le système devait démarrer avec une configuration minimale, et disposer d’un script élégant lançant automatiquement une instance Chromium en mode kiosk, sans environnement de bureau. J’ai d’abord essayé NixOS, mais j’ai vite compris que l’espace de stockage de ces Chromebooks était trop limité, et chaque installation échouait. J’ai fini par abandonner et partir d’une installation minimale de Debian, mais je me suis rendu compte que l’installation de Debian demandait tellement de clics que c’était une énorme perte de temps, puis j’ai découvert “FAI - Fully Automatic Installation” et l’outil web FAI.me », on peut noter que DietPi, OpenWrt et OpenBalena proposent aussi des options d’installation automatisée pour installer un système bare metal minimal avec un choix de paquets spécifiques.
Je me demande s’il existe d’autres options sans environnement de bureau.
Le plus intéressant, c’est que le passage à coreboot a résolu les blocages. Je me demande s’il existe une théorie expliquant pourquoi.
Cela pourrait être lié à ACPI/DSDT, ou au fait que le BIOS d’origine initialisait mal le contrôleur matériel.