- 廃棄予定だった学校支給の Lenovo ThinkPad 11e Chromebook を分解・再利用し、10画面のビデオウォールを作るのに約3年かかった
- 専用のディスプレイコントローラを使わず、既存の ノートPCのマザーボード が各画面を駆動し、Webベースの同期システムで1本の映像を10個に分割して再生する
socket.io ベースの c-sync は低速な性能、読み込み時間の差、遅延、システムクロックの問題に悩まされたが、最も遅いクライアントに合わせてループを遅らせる方式で、ほぼ同期した再生を実現した- ChromeOS の Enterprise Enrolment、デベロッパーモード制限、バッテリー取り外し時の電源問題は、coreboot、MrChromebox ツール、Debian 自動インストール USB、
ectool によるファン制御で回避した
- TN パネルの視野角、色の違い、完全ではない同期といった課題は残ったが、電子廃棄物を協業と反復設計によって実際に動くインスタレーションへと変えた事例である
廃棄予定のChromebookから始まったビデオウォール
- 学校が既存の Chromebook を廃棄しようとしていたことから、それを使って何を作れるかという発想でプロジェクトが始まった
- 使用された機種は Lenovo ThinkPad 11e で、学校支給用ノートPCだったが、すでに Google のソフトウェアアップデートを受けられなくなっていた
- ほとんどの機体は Web ページの読み込みさえ重く、古い Enterprise Enrolment に縛られていて、学校の Google アカウントなしでは使いづらかった
- 目標は、複数の画面を1つの大きなディスプレイのように配置して動作する ビデオウォール を作ることだった
画面駆動方式と同期の試行錯誤
- 当初はノートPCのディスプレイパネルだけを取り外し、高性能な1台のコンピュータで10画面を同時に駆動する方法を検討した
- 時間とコストの負担が大きく、しかも画面はすでに動作するノートPCに接続されていたため、各画面をそれぞれの ノートPCのマザーボード で動かす方式に切り替えた
- VLC ストリーミングで同じネットワーク上の複数デバイスに映像を送る実験も行ったが、ビデオウォールの要件には合わなかった
- 映像が 完全に同期 するよう設計されたシステムではなかった
- 10画面に同じ映像を繰り返し表示するのではなく、1本の長い映像を10分割して各画面に異なる入力を表示する必要があった
c-sync で再生タイミングを合わせる
- Web ページと
socket.io を使ってクライアント間の映像再生を合わせる ExpressJS のサーバー/クライアントシステム c-sync を作成した
- 基本構造は、サーバーが
play イベントを送ると各クライアントの <video> 要素が再生を開始するというものだった
- デスクトップPCでのテストではかなりうまく同期しているように見えたが、実際の Chromebook では性能不足のため安定して揃わなかった
- 読み込み時間の差
- ネットワーク遅延
- システムクロックのずれ
- 最終的な方式では、各クライアントが映像の終端に到達すると
start イベントを送信するように変更した
- 最も遅いコンピュータに合わせて速いコンピュータを待たせ、映像の読み込み時間を確保した
- 各画面は10個の
start イベントを受け取る可能性があり、ループのタイミングがわずかに揺れることがあった
- 映像の最初の数フレームが同じであれば、ユーザーは差に気づきにくかった
- タイムスタンプベースの予約再生も可能に見えたが、これらの Chromebook はミリ秒単位で時刻を安定して合わせられず、機能しなかった
ChromeOS を離れるためのファームウェア作業
- 1〜2か月のうちに、Web ページを手動で開いて全画面の同期映像を表示する段階には到達した
- 実際のインスタレーションとして使うには、電源が入ると自動起動し、
c-sync クライアントページが開く必要があった
- 標準の ChromeOS は学校ドメインにロックされた Google ログイン画面で起動し、バッテリーを外した状態では電源をつないでも自動的に起動しなかった
- MrChromebox の ChromeOS Firmware Recovery Script を使って GLIMMER マザーボードを扱った
- Recovery Mode への移行
- Developer Mode の有効化
- ChromeOS Shell でスクリプトを実行
- 一部の Chromebook は Enterprise Enrolment のため Developer Mode への移行を拒み、Linux のインストールに成功した機体でも、時間がたつと映像再生が止まったりシステム全体がフリーズしたりした
- 解決策は、各ノートPCのマザーボードで Write Protection ネジを外し、標準ファームウェア全体を
coreboot で上書きすることだった
- この作業によって登録制限も回避できたようだ
- 20台を超えるコンピュータで繰り返す必要があり、時間も手間もかかった
- その後は
Wake on AC がファームウェア機能として動作し、映像再生もランダムに壊れなくなった
自動起動する Linux キオスクを作る
- 当初は Chromium を開き、キー入力を擬似的に送って全画面化する起動スクリプトを使っていた
FullPageOS は以前のプロジェクトで使ったことがあったが、x86 ハードウェアでは動作しなかった- Porteus Kiosk は最小構成の Linux ディストリビューションで、全画面 Chromium を実行し、ユーザー操作なしで映像再生を許可するフラグも設定できるため、うまく機能した
- ただし Porteus Kiosk には実際のインスタレーション運用上の障害があった
- 起動のたびに表示される Porteus ロゴのスプラッシュ画面を変更できなかった
- インストール後にページ URL を変更するようなリモート作業ができず、壁面設置後には問題になり得た
- 独自ディストリビューションに近い構成を作るため、最小システム上でデスクトップ環境なしに kiosk モードの Chromium を自動起動する方法を試した
- NixOS は Chromebook の小さなストレージ容量のためインストールに失敗した
- その後 Debian minimal install をベースにプロビジョニングスクリプトを作成した
KIOSK_ID の生成- ホスト名を
csync-client-$KIOSK_ID に設定
- 学校の WiFi へ接続
- ユーザーと権限の作成
openbox による全画面 kiosk モード Chromium の自動起動
- 手動の Debian インストールは煩雑だったため、FAI - Fully Automatic Installation と FAI.me を使った
- 最終的に、
coreboot を適用した Chromebook に挿せば c-sync クライアントへ自動プロビジョニングされる単一の USB を作成した
c-sync には、接続されたクライアントを管理し、各クライアントに映像を割り当てる controller も追加された- 3日間のストレステストで再生が滑らかに維持された後、壁面への設置段階に進んだ
取り付け、電源、発熱対策
- 取り付け用ハードウェアは Aksel Salmi が設計し、マザーボードとディスプレイを壁に掛けられる構造が採用された
- 電源ユニットは、各アダプタが2台のコンピュータに給電できるよう、ケーブルをつなぎ合わせる方式で構成された
- 設置後の最大の問題は発熱で、ファームウェアを消去する工程の後、ノートPCのファンが回らなくなっていた
- ChromeOS Embedded Controller には
ectool でアクセスでき、ファン回転数を手動で設定できる
- オンライン文書が少なく、
coreboot 側と Google 側の ectool の違いもあって混乱があったが、Wayback Machine 経由で入手したバイナリはファン速度設定に正常に動作した
- テストを重ね、騒音と温度のバランスが取れるファン速度の値を見つけた
10画面用映像の制作
- 各ディスプレイの解像度は 1366×768 で、10画面全体の映像は 13660×768 になる
- このような横長の映像を編集できるソフトウェアは多くなく、実際に使えたのは Final Cut Pro と Blender だけだった
- 全幅の映像をレンダリングした後、
ffmpeg で10区間に切り分けて各画面に割り当てた
- 分割スクリプトは
crop=1366:768:x_offset:0 という形で、各画面位置に対応するセグメントを生成した
完成結果と残る限界
- 完成したビデオウォールには、起動シーケンス、自己補正のように見える処理、同期映像の再生、筐体とケーブル配線まで含まれていた
- 結果は完璧ではない
- TN パネルの視野角が悪い
- 画面ごとに色が異なる
- 同期が完全ではない
- それぞれの意思決定には、もっと良い代替案があったかもしれない
- それでも 電子廃棄物 を興味深いインスタレーションへと変え、反復設計とチーム協業を示す成果物として完成した
1件のコメント
Hacker News のコメント
面白いプロジェクトを完成させたことにお祝いを言いたい。複数デバイスでのメディア同期にはかなり携わってきたので、人々がどんな解決策を出してくるのか見るのはいつも楽しい。
こうした同期ビデオウォールを作る業界標準の方法は BrightSign メディアプレーヤーを使うことだが、20台規模のディスプレイだと、プレーヤーと画面の購入費だけで簡単に数万ドルまで上がり得る。再利用機器で動くようにした点は本当にすごい。
メディア同期関連のコードベース作業に興味があれば連絡してほしい。フリーランス契約の開発者はかなり頻繁に採用している。
コストのうちハードウェアとソフトウェアがそれぞれどれくらいの割合なのかはいつも気になっていたし、プロ向けデジタルサイネージは信頼性や寿命といった部分まで考慮して設計されているのだと思う。
Chromebook が発売されたとき Google で働いていて、ロビー装飾のアイデアを募集していたので似たものを提案したが却下された。おそらく40〜64台のデバイスを要求したからかもしれない。
ただし動画を同期しようとはしなかったと思う。代わりに時間ベースのアニメーションを作り、ネットワークで時計を合わせるつもりだった。
例はこちらで見られる: https://www.youtube.com/watch?v=64TcBiqmVko
Chrome を実行する8台のデバイスで、同期されているのは設定と時刻だけ。デバイスが必ずしも格子状である必要もなく、Boston Science Museum の仮想水族館から着想を得た。
「残念ながら、これらの Chromebook は互いにミリ秒単位で安定して時刻を合わせられなかったため、この方法は私たちには機能しなかった」という内容。
言われているように良い時計同期が必要で、特に音声があると20〜30msのズレでも非常に目立つので簡単ではない。それでも NTP/PTP を使えばかなりのところまで行ける。
すばらしい。4x4 のタブレットで似たことをやったことがあり、16台すべてを ADB と単一ホストに接続して、大半を自動化できた。
その後 sway で仮想画面16個と VNC クライアント16個を作り、Wi-Fi 経由ですべてストリーミングしてテストしたところ、Wi-Fi があまりにうまく動いたので、より効率的な解決策は探さなかった。
その期間、私の PC には19個のディスプレイがあり、そのうち17個が VNC で、壮観だった。全体に同じ作業をさせることも、音楽・htop・カレンダー・時計・ssh セッションのようにそれぞれ別用途に使うこともできた。
ただしハードウェアを扱うのはかなり面倒だった。一部はスロットリングがかかり、一部は接続の問題があり、充電を維持できないバッテリーもあった。
昔、似たものとして Junkyard Jumbotron があった。ばらばらのディスプレイを集めて、より大きな画像の各部分を表示できるようにするものだった。
https://github.com/mitmedialab/Junkyard-Jumbotron
動画: https://youtu.be/cAUtSVSTbzU?feature=shared
位置合わせ用の写真をメールで送る方式も、それはそれで面白そうに見える。
ざっと眺めただけでブログ全体を読んでいないなら、このプロジェクトは高校生たちが高校在学中に作ったものだ。だからさらに印象的に見える。
「なぜこれほどよく動くのか完全には確信がないが、偶然にもばかげた解決策を思いついた」と「最も遅いコンピュータが最も速いコンピュータを足止めする」という部分を見ると、ボトルネックに合わせてシステム設計を最適化したからうまく動いているのだ。
制約理論を見てみるとよい。
一度、大型タッチスクリーン TV 5台をテーブルのように配置して、似たようなことをしなければならなかった。各面は別々のタッチスクリーンアプリである必要があり、全画面が背景で同期された動画を再生しつつ、ユーザーが片端から反対側へ流れる要素とインタラクションしたり、テーブルの反対側のユーザーへ見つけたオブジェクトを送ったりするものだった。
結局、すべての画面を同時に駆動できる予算内の機材がほぼ円筒形 Mac Proだけだったのでそれを使い、アプリ群は Redis で同期した。その部分は私が書いた。
かなりうまく動いたが、会社を辞める前に完成品は見られなかった。本当は別々のコンピュータを同期したかったが、十分に安定させられず、しばらく動いた後に複数の要因で同期がずれて、アプリケーションを定期的に再起動する必要があったが、それは不可能だった。
PC の初期からずっと望んでいたのは、複数のデバイスをネットワークで結び、リソースを共有してもっと協調させる能力だった。オフィス内のすべてのコンピュータをスーパーコンピュータのように活用して処理する様子を想像してきた。もちろん非常に難しい問題で、アプリと OS がそういうふうに設計される必要があり、新しいアルゴリズムも必要になる。同じボード上の単一デバイス内でマルチプロセッサをまともに活用するのにも長い時間がかかったことを考えるとなおさらだが、seti@home や folding@home のようなプロジェクトはある程度そうしたことをやっていたし、いつかコンピュータ自体がそれをサポートしてくれることを願っていた。
「ノート PC にインストールできる『自分のディストリビューション』を作り始めた。システムは最小構成で起動し、デスクトップ環境なしで kiosk モードの Chromium インスタンスを自動起動するエレガントなスクリプトが必要だった。最初は NixOS を試したが、これらの Chromebook のストレージが小さすぎて不可能だとすぐに気づき、毎回インストールにも失敗した。結局あきらめて Debian の最小インストールから始めたが、Debian のインストールはボタンをたくさん押す必要があって時間の無駄が大きすぎると気づき、『FAI - Fully Automatic Installation』と Web ツール FAI.me を見つけた」という部分を見ると、DietPi、OpenWrt、OpenBalena にも特定のパッケージを選んで最小ベアメタルにインストールする自動インストールの選択肢がある。
ほかに非デスクトップの選択肢がもっとあるのかも気になる。
最も興味深いのは、coreboot に変えたらフリーズが解決した点だ。なぜそうなったのか、何か理論があるのか気になる。
ACPI/DSDT 関連かもしれないし、元の BIOS がハードウェアコントローラを誤って初期化していたからかもしれないように見える。