- Cyanviewはスーパーボウルのような大規模ライブ中継で、数百台のカメラの色・露出・肌色をそろえるカメラシェーディング機器を開発しており、中核の制御経路にElixirを採用している
- 放送現場では一度の失敗も致命的になり得るため、CyanviewはIPネットワーク制御とErlang VMの機器調整能力を製品の基盤としている
- RCPとRIO機器はYocto Linux上でElixirとCのロジックにより動作し、MQTTベースの通信と限定的なクラウドリレーでリモート制作を支援する
- Elixirのバイナリエンコード・デコードとsupervision treeは、多様な独自機器の統合、接続障害の切り分け、高速な機能検証に活用されている
- 9人規模のチームが200台以上のカメラ接続、Le Mans・Ninja Warrior・Australian Open・US Openのような現場を支え、小規模チームの製品対応範囲を広げている
放送現場でCyanviewが解決している課題
- スーパーボウルのようなライブ中継では、約200台のカメラの色、露出、映像トーンを一致させる必要がある
- カメラシェーディングは、各カメラが同じ芝の色、同じ肌色を映すように調整する作業である
- 対象機器は大型放送用カメラ、ドローンカメラ、PTZカメラ、ジンバル搭載ミラーレスカメラまで多岐にわたる
- Cyanviewはライブ映像放送業界向け製品を販売するベルギーの小規模企業で、主力分野はシェーディングである
- 放送業界のツールは1回のライブイベントで即座に実証されなければならず、致命的な障害は許されにくい
RCPが広まった経緯と利用現場
- 3人規模の小さなチームが作ったRemote Control Panel(RCP)は、マーケティングよりも機能によって業界に広まった
- RCPはプロの映像オペレーターにより次の現場で使われている
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- Parisの多数のファッションショー
- 単一のRCPで100台以上のカメラを問題なく扱った事例があり、これはElixirのネットワークスタック上に実装されている
- CyanviewはElixirを選ぶことで、ネットワーキング機能、回復力、高速な製品機能の反復を得た
Elixirを選んだ理由
- Cyanviewの創業チームは主に組み込み開発の経験を持ち、製品には低レベルのCコードやFPGAが多く含まれていた
- 色彩科学の低レベルな詳細と厳しいタイミング要件のため、低レベル実装が必要だった
- カメラソフトウェアは完全なデジタル化後も、アナログシステムや独自接続方式に縛られていることが多い
- 初期からIPベース制御を目標に据え、汎用ネットワーク上でソフトウェアが機器を扱う構造にした
- リモート制作の増加に伴い、中央拠点から制作チームが運用し、現地要員を減らす方式が広がっている
- 専用の無線周波数やシリアル有線プロトコルは、大陸間の距離まで拡張しにくい
- Erlang VMはネットワーク越しに多数の機器を安定して通信・調整するよう設計されており、この点がElixir導入につながった
プロトコル統合とリモート制作の事例
- 開発者Ghislainは、複数のネットワークプロトコルでカメラや映像機器を統合するためにElixirを導入した
- Elixirは、個々のビット単位に至るまでバイナリデータをエンコード・デコードする実用的な機能を備えている
- Cyanviewの中核知的財産は、大量の機器統合とリバースエンジニアリングにある
- 製品は、顧客が使う多様な業務用カメラシステムや関連機器と互換性を持つよう設計されている
- 外部機器と円滑に統合できるようAPIも提供している
-
Beijing–Parisリモート制御の事例
- 中国でのOlympicsの事例では、Beijingのスタジオが多数のPanasonic PTZカメラを使用し、チームの大半はParisから遠隔制御する必要があった
- Panasonicカメラのプロトコルはインターネット利用を想定しておらず、各調整に正確なタイミングと複数のメッセージが必要だった
- ネットワーク遅延はタイムアウト、接続切断、システム障害につながり得た
- Cyanviewの機器をBeijingのカメラのそばに置き、ParisからIP経由で制御する形で運用した
- 同じ場所にある機器同士は、カスタムMQTTプロトコルでネットワーク上を通信し調整した
RCP・RIOとUI構成
- 全体システムは、Yocto Linuxを実行するRCP機器とElixir・Cベースのロジックで構成される
- Pythonはスクリプティングやツール用途で今も使われているが、役割は徐々に小さくなっている
- 複数のマイクロコントローラとオンカメラ機器がMQTTで通信する
- クラウドリレーは接続性を助け、ダッシュボードとコントローラUIは監視と制御を提供する
- 中核機器は2種類ある
- RCP: 制作側の制御機器
- RIO: カメラの低遅延操作を担う機器
- RCPとRIOはいずれもElixirを実行する
- 設定UIは現在Elmで構築されている
- 優先順位次第では、設定UIは対応言語数を減らすためにPhoenix LiveViewへ移行する可能性がある
- コントローラのWeb UIはすでにLiveViewで構築されており、低スペックの組み込みLinuxマシンでも快適に動作する
限定的なクラウドとローカル機器クラスタ
- Cyanviewのクラウド部分は現時点では限定的で、SaaS中心の構造ではない
- クラウドリレーは、カメラ制御の配布・共有、拠点間のネットワークポート転送、関連機能を担う
- クラウドリレーもElixirで構築されている
- 現場のElixir機器は、作業に合わせたカスタムMQTTベースのプロトコルでIPクラスタを形成する
- これらの機器は数百台のカメラやその他の映像機器と通信する
障害の切り分けとsupervision tree
- 多数の独自機器と統合する中では、機器ごとに信頼性やドキュメント品質が大きく異なる
- ある機器は広く使われていて特性がよく知られており、ある機器は良質なドキュメントを提供する一方、別の機器は予測しにくい動作を示す
- 1台のカメラ接続で一時的な問題、バグのあるプロトコル、物理接続障害が発生しても、他は動作を継続しなければならない
- Elixirのsupervision treeは、個別接続の問題がシステム全体の障害へ波及するのを防ぐのに有利である
9人チームの役割分担
- Cyanviewは9年間かけてゆっくり成長しており、平均すると毎年1人ずつ増えてきた
- 現在は9人規模のチームが世界最大級の放送イベントを支えている
- Elixir開発者は2人である
- Daniilは一部UI刷新と、より多くのクラウド機能の方向性を担当する
- Ghislainはカメラと統合作業を担当する
- LiveViewとElmは機器UIとダッシュボードに使われている
- 他の組み込み開発者は日常業務でElixirを多用するわけではないが、Elixirでプロトコルやエンコーディングを実装することには慣れている
- 彼らがElixirを深く学んでいない主な理由は時間不足であり、深いElixir専門性が必須ではなかったためである
- チームの業務には、PCB設計、電子部品選定、プロトコルのリバースエンジニアリング、ディスプレイインターフェース、FPGA実装、生産テスト管理、実運用、ファームウェア更新まで含まれる
機能拡張と顧客中心の開発
- Cyanviewの機器は次のような現場で使われている
- 24 Hours of Le Mansの40台以上の車載カメラ
- Ninja Warrior
- Australian Open
- US Open
- Louvreのスタジオ
- NFL pylons
- 200台以上のカメラ同時接続
- IP上で動作する世界を対象にElixirベースの機器を作り、これによって多様な機器対応と新機能提供を同時に進めている
- 従来のローカル無線周波数、シリアル接続、柔軟性のない独自プロトコルからIPネットワークへ移行する中で、カメラシステムの運用方法が変わっている
- 機能セットには次が含まれる
- 制限のないマルチカム
- Tally lights
- Pan & Tilt制御
- カラーコレクタ統合
- 世界規模のリモート制作
- ジンバル搭載ミラーレスカメラで観客の映像を撮る需要が増えると、Cyanviewはジンバル制御を素早くプロトタイピングし、顧客とテストして検証した
- 柔軟なアーキテクチャにより、中核基盤を壊さずに新機能を迅速に提供できる
- CanonやREDのように放送シェーディング用リモートを作っていないカメラメーカーは、顧客にCyanviewを勧めている
- Cyanviewは大半の放送ハードウェア企業と競争するより、パートナーとして自社を位置づけている
- マーケティングよりも、顧客イベントの成功支援と手厚い顧客サービスを重視している
今後の方向性
- David Bourgeoisは、もう一度選ぶとしてもElixirを選ぶと答えている
- Erlang VMはCyanviewの要件によく合っており、Elixirが標準で備える機能の価値は自分で実装してみるまでは十分に理解しにくいと見ている
- Cyanviewはチームをさらに拡大したいが、時間がかかっても責任ある形で成長したいと考えている
- 現在は小規模チームで抱えられる以上にやるべきことが多い
- 主要なRCP機器とあわせて補完製品もすでにあり、今後さらに多くの製品が予定されている
- クラウド製品と、これまでの学びを踏まえたハードウェアプロジェクトが計画されている
- Elixirは世界最大規模のライブ放送の一部で、さらに重要な役割を担うことになる
1件のコメント
Hacker Newsの意見
スポーツイベントでは、複数の角度に配置されたカメラごとにカラー補正が必要だと知ると、あまりにも当然に思える
ほとんどの人には見えない難しい問題について読むのは本当に面白い
ハーフタイムショーのすべてのカメラショット切り替えを追跡した動画がある: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamiltonは2010年以降、すべてのSuper Bowlハーフタイムショーを演出してきた
https://x.com/SNYtv/status/1832250958258036871
「マーケティングなしでも熟練した専門家たちの間で評判を得て、世界最高峰のライブイベントの必需品になった」というくだりは、エンターテインメント業界らしく聞こえる
同じショーを同じクルーで毎年やっていると、本当に誰もが互いを知っていて、一種の家族のような構造になる
CyanviewにはストアフロントのWebサイトもあり、LinkedInのマーケティング投稿もある
Elixirがミッションクリティカルな放送システムで力を発揮しているのを見るのはうれしい
Cyanviewの信頼性がElixir自体からどれほど来ているのか、それともMQTT実装が優れていたおかげなのか気になる
ほかの言語では再現しにくかったElixir固有の機能があったのかも気になる
BEAMとOTPは並行性に対する健全なアプローチを提供し、Elixirはその上に載ったよい言語
プロセス分離が優れていて、ヒープまでプロセスごとに分かれるため、安定した成熟コードと実験的機能を一緒に動かしても全体が崩れる心配が少なく、プロセス間通信も簡単
監督ツリーのおかげでプロセス管理が容易で、異なる再起動戦略を持つ特殊なスーパーバイザーも作れた
ネットワーク接続が切れては戻る環境なので、システムの復元力は物理的なカオスモンキーのように頻繁に試される
BEAM流の不変性は並行コードの記述を大きく単純化し、1つのプロセス内ではデータがこっそり変わる心配がなく、別のプロセスが自分の状態を変えることもできない
そのためミューテックスやクリティカルセクションはほとんど必要ないが、デッドロックは依然として起こり得るので万能の解決策ではない
多数のリアルタイムフィードをフェイルオーバーや代替経路込みで調整しルーティングする仕事で、もともとの対象は電話通話だった
映像ストリームは秒あたりのデータ量がはるかに大きいが、原理の大部分は引き継がれている
このシステムには批判的なほうだが、こうした用途ならデフォルトの状態だけでも非常に強い土台になる
違いは、その作業をどれだけ簡単にしてくれるかにある
Elixirを重要な金融アプリケーション、B2B成長インテリジェンス、不正検知、スキャン＆ゴー型ショッピングなど、さまざまな場所に適用してきた
毎回、この記事のエンジニアリングチームと同じように、開発者体験と最終結果が期待を超えており、まだElixirを試していないなら一度試す価値がある
私も例外ではなく、何十年もよい話を聞いてきたが、実際のプロジェクトで使ったことはなかった
たとえばクラウド製品で、ユーザーが施設内の指定ウェイポイントへロボットをリモートで呼び出し、ロボットが移動している間、地図上の位置をリアルタイムで表示する機能をちょうどリリースした
これはMQTT、LiveView、Phoenix PubSubと、地図操作用のごく少量のJavaScriptだけで作ったもので、既存のS3地図PNG表示コードやMQTT受信処理などを除けば、クラウド側は1人が2〜3週間ほどで実装した
もちろん他の言語でもできるが、中核となる言語機能が非常に優れているため、私たちの用途では他の選択肢を圧倒している
似たようなアプリケーションで、GleamがOTP/BEAMランタイム以外の面でも実用的なのか気になる
まだGleamにはないElixirライブラリを活用する必要がありそうで、静的型付けのせいでコンパイルは遅くなるかもしれないが、ランタイムエラーをより早く捕まえられる可能性はありそう
デバッグと高速な動的イテレーションの間のトレードオフに近いのかが気になっていて、GleamとElixirのどちらかを選ぼうとしているところ
以前のGleamのML風構文も好きだったし、静的型付けも好み
CはZigで置き換えつつあり、x64に加えてARMを学びながらアセンブリも鍛え直している
Erlangの信頼性の実績は、Javaを含む多くの静的型付け言語よりも強い
静的型付けが防いでくれる種類のエラーはあるが、防げないエラーのほうがはるかに多い
TS、Java、Swift、Go、Gleamのような言語がErlangやElixirより実際のランタイム欠陥を減らすと主張するなら、現実のデータが必要
今まさに取り組まれてはいるが、まだ試せておらず、そのためGleamも良さそうに思える
ただ、自分たちが始めた時点ではGleamは0.1にも達しておらず、聞いたこともなかった
Erlang、Elixir、Gleamを混ぜたプロジェクトも可能だろうが、実用性はよく分からない
コンパイルも非常に速い
まだ非常に大きなプロジェクトはやっていないが、かなり重めのライブラリを使っても、すべてとても速くコンパイルできた
デジタルビデオの世界はITの親戚のようなものなのに、ビデオ業界の外の人にはいつも参入障壁が高く感じられる
解像度、色、ネットワーキング、ストレージの呼び方が、ほとんどわざと違えているように見える
これは映像エンジニアが画質を調整するための項目にすぎず、カメラオペレーター向けの機能は通常扱わない
難しい点は、これほど多くのカメラとプロトコルの間で一貫性を作ることにある
その次になってようやく、生のyuv/y4m非圧縮映像、超高ビットレートの低圧縮映像、元データが大きすぎて強力なワークステーションでも編集が難しいためプロキシ映像を作る問題へ進める
専門的な理由がないなら、一般のエンドユーザーが深く掘り下げる利点はほとんどない
REDカメラに7,000ドルを費やし、レンズ、ジンバル、ケージ、フォローフォーカス、マットボックス、メモリーカードなどにさらに13,000ドルを使って、小型で費用対効果の高い単一カメラ制作パッケージを作るつもりなら、掘り下げる価値はある
30年ほど前、スタジオ環境でカメラのカラーバランスを合わせるのが仕事の一部だった
コンピューターは必要なかったが、カメラは多くても5台だけだった
記事で「ある会場の機器がカスタムMQTTプロトコルでネットワーク上で通信・調整し、Elixirネットワークスタック上に実装された単一のRemote Control Panel（RCP）から100台以上のカメラを問題なく扱う」という部分が目に留まった
MQTTはTCPの上に作られていると理解しているが、自分が同じ解決策にたどり着いたかは分からないものの、かなり良い選択に見える