スーパーボウルの映像美をElixirで制御だと？舞台裏が凄すぎ！
引用元：https://news.ycombinator.com/item?id=43479094
マジか！スポーツイベントでいろんな角度からカメラがあって、それぞれ色補正が必要なんだね。こういう一般の人が気づかない大変な問題の話、めっちゃ好きだわ。
そうそう、めっちゃニッチだけど超重要な機能の一つだよね。言われてみれば当たり前だけど、普通は考えないよね。
だって、この手の調整なしにたくさんのカメラ使ってたら、放送中にカメラや視点を切り替えるたびに、映像がガクガクして見づらくなるじゃん。
昔のSuperbowlではそんなに気にならなかったのはなんで？
昔はもっと色補正やってたんだよー。カメラも今よりずっと性能悪かったし、アナログだったし！ただ、オフサイトからコントロールしてたわけじゃなくて、放送トラックの中に専用の部屋とエンジニアがいて、カメラの設定とか色補正とかやってたんだよね。
よくあるやり方は、まずステージとかフロアにカラーカード立てて、ベクタースコープ[1]でドットを正しい位置に並べるんだ。で、波形モニターで露出を調整する。イベント中は、目視で微調整したり、ズレてきたものを直したりしてたんだ。
[1] https://en.wikipedia.org/wiki/Vectorscope#/media/File:PAL_Ve…
去年のSuper Bowlでは150台くらいのカメラが使われたんだって。ほとんどがSonyのスタジオ用カメラで、完璧な調整ができるようにSonyのリモコンで制御されてる。でも最近は、特殊なカメラもたくさん追加されてるんだ。例えば、4つか8つのpylonにそれぞれ2～4台のカメラが付いてたり、ドローン、手持ちのミラーレスカメラ、小型のハイスピードカメラ、PoV用のミニカメラとか。去年は、Bellagioからスタジアムまで車にミニカメラを積んで、セルラー回線で遠隔操作してたんだって。車載のRIOではElixirのプロセスが動いてて、カメラを管理したり、クラウドサーバーに接続したりしてたみたい。リモートパネルも同じサーバーに繋がってて、全部Elixirで書かれてたんだ。クラウドサーバーは、ただのデータ中継地点として機能してたみたい。
もしpylonカメラの芝生の緑色をメインのカメラと合わせたいなら、調整は必須だよね。屋外スタジアムだと、これは常に必要な作業で、一日中、天候が変わるたびに調整が必要になるんだ。夜になると、ビデオエンジニアはメインカメラとの完璧な連携を保つためにノンストップで作業してる。
カメラの数が少なかったり、解像度が低かったり、そもそも1台のカメラでも色の再現性が悪かったりしたんじゃない？
受信側のディスプレイの色再現性も今より悪かったんじゃないかな！
この人が言いたいのは、この技術が使われている対象（テレビ放送されるプロスポーツ）が超重要ってことじゃなくて、プロスポーツとか、似たようなカメラワークが必要なイベントをテレビ放送するためには、こういう作業が重要だってことじゃないかな。
もし色の変化が激しい、出来の悪いポルノを見たことあるなら、理由はわかるっしょ…
99% invisible ってポッドキャストの元ネタなんだって。エレベーターの話が好き。
誰かがハーフタイムショーの全てのカメラワークを追跡してるよ。
https://www.youtube.com/watch?v=YXNWfFtgbNI
control room から見た映像は Hamish Hamilton の YouTube チャンネルで見れるよ。AD がショットを指示してるところとか。
https://m.youtube.com/watch?v=gfjWjkTP4p8
（Hamish Hamilton は2010年からずっと Super Bowl のハーフタイムショーの監督なんだって。）
John DeMarsico って人が NY Mets の SNY 中継の監督してて、時々カメラがどうやってプロダクションになるかの舞台裏を投稿してるんだ。見てて結構面白いよ。
https://x.com/SNYtv/status/1832250958258036871
＞マーケティングなしで、ベテランの間で評判になって、世界トップのライブイベントの定番になったんだって。
エンタメ業界って感じだね。みんな知り合いみたいな。特に毎年同じクルーで同じショーやってる時は。
家族みたいなもんだよね。
＂マーケティングなしで＂は明らかに嘘じゃん。Cyanview はストアフロントのウェブサイトもあるし、Linkedin でマーケティング投稿もしてるし。
（記事を書いたのはうちじゃないけど）そのつもりで書いたんじゃないと思うよ。マーケティングもっとやりたいんだけど、時間がないんだよね。ストアフロントのウェブサイトはないよ。古い製品情報しかないサイトだけ。でもサポートに力を入れてるんだ。Linkedin に年2回くらい投稿して、まだ生きてるって安心させてるけど、マーケティング戦略とは言えないよね。今のところ口コミと業界のコネで売れてるよ。今後もっと頑張りたいな。
考えてみたら、記事は明らかに誇張してたね。今の国の状況（USA）のせいで、ちょっとした嘘にも敏感になってるのかも。あと＂ストアフロント＂って言葉のチョイスが悪かったな。最初は＂プロフェッショナル＂って言おうとしたんだけど、なぜかやめたんだ。
とにかく、売れる高品質なソフトウェアを作り続けて！
誇張してごめん。
面白いのは、主なマーケティングとセールスが口コミと製品の質だってこと。ハードウェアはウェブサイトにすらないんだよね。書くときに混乱したよ。リソースの制約があるから仕方ないね。
マジで？
メインの作者として、裏話全部ぶっちゃけちゃうよ。
Cyanviewから開発者探してるって相談されたんだよね。顧客の話聞いて、Elixirにとってデカい話題になると思ったんだ。
彼らのこと気に入ってるんだよね。小規模チームなのに、すごいことやってるし。ハードウェア、ソフトウェア、FPGA、ライブ放送とか、色々詰まってるんだもん。
Elixirの普及が一番大事だから、Elixirチームに連絡して、インタビューさせてくれってお願いしたんだよね。
Elixirの導入事例は、確かにElixirのコンテンツマーケティングだよ。でも、よく聞かれる質問じゃん。「誰が使ってるの？」って。面白い事例だと思ったから、記録に残したかったんだよね。
良い仕事してるね。他の言語コミュニティもこういうのやってほしいわ。 Elixirがミッションクリティカルな放送システムで使われるようになってきて嬉しいね！Cyanviewの信頼性のうち、Elixir由来のものはどれくらいあるんだろう？ただ単にMQTTをうまく実装しただけってことはない？他の言語じゃ再現できないElixir固有の機能ってあるのかな？ メイン開発者です。 ベルギーの企業がこの分野で成功してるのを見るのは嬉しいね！ 生のMQTTの代わりにNATS/Jetstreamとか試したことある？ MQTTは、リモコンパネルとかカメラノードみたいな組み込みデバイス上のプロセス間のメッセージングに使われてるんだ。パネル自体はマイクロコントローラで動いてて、MQTTを通して表示するパラメータを取得したり、変更を要求したりするんだよね。カメラがLAN上にある場合は、別のプロセスが通信を処理するよ。カメラがリモートにある場合は、MQTTブローカーのブリッジ機能じゃなくて、Elixirソケットを使ってデータを送ってるよ。 Elixir使い始めたんだけど、MQTTで農業用灌漑システムを連携させてるんだよね。でもElixirのMQTT実装がいまいちでさー（ドキュメントも少ないし）。なんか良いのを見落としてるのかな？今はTortoiseのfork版使ってるんだけど、色々問題があってさ。連絡してくれたら嬉しいっす！詳細はプロフに。 うちもTortoiseのfork版使ってるよ。使いやすいようにちょっとコードをラップしてる。最初はerlangのemqttってライブラリを使ってたんだけど、メンテされなくなってGitHubから消えちゃったんだよね。それで別のものに乗り換えた。完全には満足してないけど、とりあえず動いてる。 どのバージョンのemqttのこと言ってるのかな？うちは1.11.0をAWS IoT Coreで使ってて、Elixir的にはこれが一番良いバージョンだと思ってるんだけど。 細かいことは忘れちゃったけど、MQTT 3.1から5.0への移行時期だったと思う。うちは3.1しか使ってなくて、5.0のコードはまだ完成してなかった。emqttが古いライブラリへの依存関係をハードコードしてて、それをアップグレードしたかったんだよね。Hex packageはなくて、GitHubから引っ張ってきた。その後、GitHubのリポジトリが消えちゃった（か移動した？）。この新しいパッケージを試してみるよ。期待できそう。 ああ、確かに。うちはGHのタグからpullしてるよ。でも、gunの古いバージョンへのハードコーディングされた依存関係は最近修正されたと思う。IIRCだけど、それが最新バージョンで適切なパッケージがhexになかった原因だったはず。 GH上のemqttの最新タグ（1.14.4）にアップデートできたよ。前はできなかったんだよね。hex.pmにパッケージを公開するのを妨げるものはもうないと思うから、近いうちに利用可能になることを願ってる。 Elixir/Erlang/BEAMの得意分野じゃん。元々そういう用途のために設計されたんだし。大量のリアルタイムフィードを、failoverとかfallbackを駆使して連携・ルーティングするなんて、まさに得意とするところだよ。元々は電話回線のために作られたんだけど、ビデオストリームの方がデータ量が多いってだけで、基本的な考え方は同じ。色々文句もあるけど、この用途なら、Elixir/Erlang/BEAMは非常に強力な基盤になるよ。 そうそう、最初からそこは考慮してたんだよね。Erlangが元々通信のために開発されたってのも、Elixirを選んだ理由の一つ。今はメタデータとか制御データ、ステータスだけを扱ってるよ。ビデオパイプラインとかカラーコレクターも管理してるけど、ビデオストリーム自体は別のところで処理してる。 ビデオストリームがBEAMを通らないってことを言いたかったんだけど、長くなるからやめたんだよね。昔の電話交換機も同じような仕組みだったらしい。BEAMはメタデータを処理して、電話回線そのもののデータは専用のハードウェアに指示してた。2025年なら、2000年の電話交換機が扱ってたくらいのデータ量ならBEAMで処理できると思うけど、音声データでも、パフォーマンスを最大限に引き出したいなら、ビデオストリームと同じように処理した方がいい。音声データは遅延に少し強くなったけど、それでも無駄に遅延を増やしたくないし、BEAM自体はベストエフォート型のソフトリアルタイムだからね。 ＞ couldn’t be replicated in other languages? それなー。他の言語でBEAMの挙動を再現しようとすると、マジで苦労しそう。 それは一般論としてはそうだけど、いつかそうじゃなくなるかもよ。例えば、ElixirはGPUをターゲットにしたコンパイルをサポートしてるし（同じ言語内で、フォークじゃないよ）。ほとんどの言語はそれができないし、実装もかなり難しいと思う。 どんな有限で計算可能なタスクでも、言語がハードウェアにアクセスできて、実用的な時間でタスクを実行できるなら、コンパイルやメモリの問題がなければ、計算する価値があるってことだよね。 ＞記事から引用：”Erlang VMが何ができるかはわかってるし、うちのニーズにはすごく合ってるんだ。Elixirが最初から提供してくれるものを、自分で実装しようとするまで、ありがたみがわからないんだよね。” Elixir特有の機能で、他の言語じゃ再現できないものってあるの？ Elixirを使って、金融、B2B、不正検知、スキャンアンドゴーのアプリとかを作ったことあるけど、この記事のチームと同じで、開発者の体験も結果も期待以上だったよ。Elixirを使ったことないなら、ぜひ試してみて！ ElixirとErlangはいつも評判がいいよね。なんで普及しないのか不思議。俺もそうだけど、何十年もいい話を聞いてるのに、実際にプロジェクトで使ってみたことがないんだ。 Erlang/Elixirが普及しない理由の一つは、OTPの規模だと思う。あれはスーパービジョンツリーとか、プロセスリンクとか、ETSとか、アプリの環境とか設定管理とか、リリースとか、すごいツールがたくさん入ってるんだよね。新しいプログラミング言語っていうより、新しいOSを採用するのに近いかも。CSVを使ってた開発者がPostgresに乗り換えるみたいなもんかな。 みんな最初に学んだ言語か、それに似た言語に落ち着くことが多いんじゃないかな。学校でJavaとかPythonとかJSを教えるけど、どれも似てるし。そういう言語を知ってる人が、何か特別な問題に直面しない限り、immutableな関数型言語を選ばないと思う。 ほんとそれ。PythonのGILとかJavaの面倒くささにうんざりして、OOPも期待外れだったから、10年くらい前にElixirを始めたんだ。それから一度も後悔してないよ。Elixirは使うのがマジで楽しい。マルチスレッドも簡単だし、パターンマッチングでコードも読みやすくなるし。Elixirは最高の秘密兵器だよ。 うちのロボットのスタートアップでも使ってるけど、マジでその通り。例えば、ユーザーがロボットに目的地を指定して、移動状況をリアルタイムでマップに表示する機能をリリースしたんだけど、MQTT、LiveView、Phoenix PubSub、あとはマップ制御用のちょっとしたJSだけでできたんだ。 メールアドレス教えてもらえないかな？もし時間があったら、金融系のアプリでElixirを使った経験について色々聞きたいんだけど。 Gleamって、OTP/BEAM以外の部分でElixirみたいなアプリに使えるかな？GleamにないElixirのライブラリを使ったり、静的型付けでコンパイルが遅くなるかもだけど、ランタイムエラーは早く見つけられるよね？デバッグと高速イテレーションのトレードオフかな？GleamかElixirで迷ってるんだ。CをZigに置き換えてて、アセンブリも勉強中。 ＞you’d catch runtime errors sooner ”sooner”の意味によるんじゃない？Gleamはコード実行前にたくさんエラーを見つけて、Elixirは発生時に見つけて上手く回復する。ユーザーにバグが行くのが嫌ならGleamが良いんじゃない？テストを信じて動的な自由が好きならElixirで良いと思う。どっちもあんまり経験ないけど。Erlangは昔ちょっとやったくらい。Gleamを選ぶか迷ってるんだよね。Gleamのシンタックスが好きってのが大きいかな。 ＞There is a certain class of errors static types can prevent but there’s a much larger set of those it can’t 言語と静的型システムの程度によるけど、一般的に以下のエラーは防げないことが多いよ。 Elixirの不満点は型がないことかな（今は開発中だけど、まだ使ってない）。だからGleamは良いと思う。でも、僕らが始めた頃はバージョン0.1にもなってなかったし、名前も知らなかった。Erlang、Elixir、Gleamの混合プロジェクトも出来るかもね。現実的かは分からないけど。 すごいね。そんな大きなプロジェクトなら、ほどほどで良いってことだね。Gleam vs Elixirの話を出したのは、今年どっちかを勉強しようと思ってるから。LFEも触ったことあるし、Erlangもちょっとやったことあるんだ。 GleamはOTPの機能の一部があるよ[1]。コンパイルもめっちゃ早いし。まだ大きなプロジェクトは作ってないけど、結構大きいライブラリを使っても、コンパイルは超早いよ。 デジタルビデオの世界ってITの親戚みたいなもんなのに、ビデオ業界の人以外にはマジで理解不能なの、あるあるだよね。解像度とか色とか、ネットワーク、ストレージの言い方とか、わざと違うんじゃないかってくらい違うんだよなー。 うちで扱ってる放送用カメラ、ざっと200種類くらいあるんだけど、そのパラメーターを調整するイメージかな。映像エンジニアの仕事で、画質を微調整するんだよね。カメラの機能全部を調整するわけじゃなくて、オペレーター向けの機能もあるし。色んなカメラとプロトコルがあるから、統一するのがマジ大変。 パラメーターを一旦「標準化」して、共通のコンフィグで動くようにしてる？もしそうなら、デバイス固有の設定はどうしてるの？ それが狙いで、最初は主要カメラにあるパラメーターを標準化したんだ。でも、メーカー独自のパラメーターがネックでさ。オペレーターもカメラの設定値を変えたがらなくて。例えば、フットボールとかスタジオ作業に最適な設定を知ってたりするから。だから、主要な機能は標準化して、それ以外はカメラの設定に近づけてるよ。MQTTのトピックは、一種の共通APIみたいな感じで、パートナーや顧客が自動化に使ってるみたい。まだ公式にはリリースしてないけどね。安定性とか保証できないし。 いつも詳細でためになる回答ありがとうございます！ いつも普通のビデオ機器しか触ってない人は、420と422の色空間の違いとか、映画用カメラがグレーディング前の映像を記録する理由とか、ポストプロダクションのワークフローでのカラーグレーディングとか、ちゃんと勉強しないと分かんないと思うよ。RAW YUVとか、非圧縮ビデオとか、プロキシ素材とかもそう。趣味でやるならそこまで深く知らなくてもいいと思うけどね。REDのカメラに7000ドルもかけて、レンズとかジンバルとかに13000ドルもかけるなら、勉強する価値あるかもね。 4：2：0と4：2：2について知りたい人はこれ見てみて：https://youtu.be/7JYZDnenaGc?feature=shared&t=101 最近、グレーディングってやりすぎな気がするんだよね。せっかくキレイな映像なのに、最終的に黄色とか青色になっちゃうの、マジ勘弁。 シェーディングとグレーディングは全然違うんだよね。シェーディングは、テレビ業界でカメラの色味を全部合わせる作業のこと。カメラアングルが変わっても、肌の色とか、草の色とか、空の色が全部同じになるように調整するんだ。スポンサーのロゴの色を正確に再現するのも大事。ITU-R BT.709とか、ITU-R BT.2020みたいな規格に沿ってやるのが基本。 今日初めてシェーディングって言葉を知ったんだけど、グレーディングのチュートリアルであんまり見かけないのが不思議。違うものだけど、グレーディングの前にシェーディングを学ぶべきな気がする。 30年以上前､スタジオでカメラのカラーバランス調整してたんだよね｡コンピューターなんて要らなかったけど､カメラはせいぜい5台だったし｡ めっちゃクールな記事だね｡ このSuperbowl以外だと､似たような放送設定で何が使われてるんだろう？ 主要なイベントでは､メインのスタジオカメラ向けの技術が既にあるから､あらゆる種類の特殊カメラに使われてるんだよ｡だから､うまくいかないもの全てに対して解決策を開発する必要があったんだ｡大規模な制作には､あらゆる種類の新しいおもちゃ（ミニカム､ドローン､ケーブルカム､小型ミラーレスカメラによる映画のようなルック､スローモーションなど）の予算があるんだ｡それは創造性を発揮する多くの可能性を開いたけど､メインカメラと同じくらい信頼性が高く､最高の画質を目指す必要があるんだ｡ ＞今では同じ製品が､スタジオカメラの予算がない非常に小規模な制作で使用されてるんだ 通常は4台のカメラ設定で､1つのリモートで全てのカメラを制御できるよ｡クラシックコンサートでは､2台のPTZロボットカメラと､一部のアーティストや楽器に2台のミニカムを使用するだろうね｡カメラ側にはカメラオペレーターがいない(コスト上の理由で)ので､1人のオペレーターが全てを行う必要があるんだ｡ YouTubeチャンネルの最上位層では､時々REDカメラが使われてるね｡ YouTuberの舞台裏でARRIをあまり見たことがないな｡通常は､ハイエンドなプロシューマー向けのフルフレームミラーレスのSony､Canonまたは同等のものを選ぶね｡それらはCyanviewの製品が意図してるものよりも下か､使用されるエッジにあると思うよ｡ 記事によると､このソフトウェアは全ての主要なスポーツイベントで使用されてるんだってさ｡ マジかよ、俺の経験だとElixirのドキュメントは最高レベルなんだよね。エコシステムの強みの一つで、Elixir書かないと恋しくなるくらい。HexDocsが最初から統合されてて、どのパッケージも一貫性があるし。フォーマットも見やすいし、使いたいライブラリは大体ドキュメントあるし。ガイドとかチートシートもあるからAPIドキュメントと分かれてないのも良い。RubyとかJavascriptで開発してるとマジで恋しくなる。特にJavascriptはマーケティングサイトばっかで標準化されたツールがないのがクソ。 Elixirのドキュメントの内容はマジで同意。ちゃんとドキュメント書く習慣を受け継いでるみたいで最高。でもね、Elixirのドキュメントの見た目がマジで嫌い。Erlangのドキュメントがスタイル真似し始めたのも気に食わない。 Dialyzerのエラーについてだけど、Typescriptからの移行組としては真逆の経験してるんだよね。Typescriptの型でSwagger APIを検証したり色々やってきたけど、Elixir/Dialyzerの型でエラー出ると「マジかよ、こいつ分かってねーな」って思うことが多かった。でも深く調べてみると9割は自分の勘違いだったりするんだよね。それからはDialyzerをリスペクトするようになった。新しい型システムでもっと使いやすくなると良いな。 いくつか同意できる点もあるけど（LSPとか）、俺の会社ではElixirは良い点と悪い点をひっくるめて最高の開発体験になってるよ。Elixirで何作ってるのか気になるな。例えば、リリースは10分で終わるし、Discordで質問したらすぐ返ってくるし。 クリティカルなシステムを構築している場合、実装の詳細を第三者（Discordとか）に公開するのはリスクが高いと思う。ビルドだけでなくテストスイート全体も時間がかかる。GoだとBEAMほどじゃないけど、15分以上デバッグに時間を費やすことはない。循環依存とかも警告が出ないからLSPが止まってドキュメントが見れなくなったりするし。Arrow使うと警告出るのにね。 ＞コードに問題があるのは確かだが、エコシステムが修正を支援してくれることを期待している。例えば、Umbrellaプロジェクトの循環依存関係。それらを持つことができる。印刷できる。警告は表示されない。それらは一貫性のないビルドと40秒のLSPチェックループを引き起こし、その間、ドキュメントにアクセスできない。 フィードバックありがとう！いくつかコメントさせてね。もっとコメントを表示（1）
MQTTはめっちゃ使ってるよ。アーキテクチャの中心的な部分だね。でも、Elixirは疎結合なプロセスをたくさん処理するのに役立つんだ。
BEAMとOTPは、並行処理へのまともなアプローチを提供してくれるし、Elixirは良い感じの言語だよね。重要なメリットはこんな感じ。
・プロセスの分離が良くて、ヒープもプロセスごと。
・スーパービジョンツリーでプロセスの管理が楽。
・BEAMによるイミュータブル（不変性）のおかげで、並行コードが書きやすい。
大学でエキゾチックなカメラやスクリーンを使ったシステムを作ってるんだけど、(商業的にも研究的にも)一緒にプロジェクトについて話せないかな？
次はクラウドポータルを作って、そこからカメラにリモートアクセスできるようにしたいな。そのためにNATSを検討してるんだ。REMIが普及してきてるし。
ビデオストリームに興味がある人のために簡単に説明すると、現場では全部SDI（HD-SDI、3G-SDI、12G-SDI）で、1.5Gbps(HD)から12Gbps(UHD)のシリアルストリームを同軸ケーブルとか光ファイバーで伝送してる。遅延はゼロ。無線伝送はCOFDMを使って、超低遅延のH.264/H.265エンコーダー/デコーダーで、20ms以下のglass-to-glassレイテンシーを実現してる。両端でSDIに変換してるからシームレスに使える。
SMPTE 2110は、SDIデータをIPで非圧縮伝送する新しい規格で、タイミングはSDIとほぼ同じ。ビデオとオーディオは別々のストリームで送られる。HDで10G、UHDで25Gのネットワークポートが必要。今は一部の会社しか、市販のITサーバーで扱えないけどね。
インターネット経由でストリーミングする場合は、10Mbps以下に圧縮して、数秒の遅延が発生する。ほとんどのカメラはSDIを出力するけど、直接ストリーミングできるものもある。ただ、ビデオミキサーとかリプレイサーバーとか、他の制作機器との連携では、SDIがまだまだ主流。
＞“他の言語では再現できない？“
どの言語でもどんなタスクでもできるよ。ただ、そのタスクをどれだけ簡単にできるかって話。もっとコメントを表示（2）
Gleamの方がElixir（またはErlang）よりランタイムバグを早く見つけられるって証拠はないと思うよ。Erlangの信頼性は、Javaみたいな静的型付け言語よりも高いんだから。静的型付けで防げるエラーもあるけど、もっとたくさんのエラーは防げない。TS/Java/Swift/GolangとかGleamがErlangやElixirよりもランタイムエラーが少ないって言うなら、データを見てみたいね。
それについてもっと詳しく教えてほしいな。静的型付けで防げないランタイムエラーってどんなのがあるの？Elixirをちょっと使ってるんだけど、ランタイムエラーは“(FunctionClauseError) no function clause matching”みたいなのが多いんだよね。Gleamなら避けられるし、FFIを使わないと書けないレベル。Elixirにもっと静的型付けが入ってくるのが楽しみ。今はテストがないと不安だし、リファクタリングも怖い。でも楽しい言語だよね。
・ロジックエラー
・NullとかUndefined（最近の言語では防げるのもある）
・範囲外エラー
・並行処理の問題
・算術エラー（ゼロ除算、オーバーフローとか）
・リソース管理エラー
・I/Oエラー
・外部システムのエラー
・未処理の例外（JavaのRuntimeExceptionとか）Rustみたいな言語なら、型システムが色々助けてくれるけど、複雑になりすぎないように限界があるよね。
[1] https://github.com/gleam-lang/otpもっとコメントを表示（3）
と
https://www.red.com/red-101/video-chroma-subsampling
グレーディングは、映像に独自のルックを与えるクリエイティブな作業のこと。ポストプロダクションでやるのが普通だけど、最近はライブでやる方法もある。ライブはコンサートとかファッションショーでよく使われるね。
PS 上の回答、同じようなことが書いてある部分がある気がする。
＞ある場所のデバイスはカスタムのMQTTプロトコルでネットワーク上で通信･連携してるんだって｡Elixirのネットワークスタック上に実装された単一のRemote Control Panel (RCP) で､100台以上のカメラを問題なく制御してるんだって。
なるほどね～! MQTTはTCP上に構築されてるんだよね｡ 同じ解決策を見つけられたかわからないけど､良い解決策みたいだね｡
今では同じ製品が､スタジオカメラの予算がない非常に小規模な制作で使用されてるんだ(通常､レンズなしのカメラで500万円以上)｡その場合､同様のユーザーエクスペリエンスと機能を､はるかに手頃な価格のカメラで提供するように努めてるんだ｡
最終的に､ライブ制作はシネマスタイルのカメラで処理されることが増えてきており､標準の放送リモートパネルがないんだ｡カメラ制御と､手動レンズを駆動する外部モーターや3D Lutビデオプロセッサのような多くの外部ボックスの制御を組み合わせることで､その領域もカバーしてるんだ｡アプリケーションは､ファッションショー､コンサート､劇場､教会､スタジオショー､企業イベントなど｡
結局､Elixirは非常に低レベルの制御プロトコルを処理する多くの小さなプロセスに使用されてるんだ｡そしてその上に､ローカルネットワーク上またはクラウド上でのデバイス間の高レベルの通信を追加してるんだ｡
ずばり聞きたいんだけど､ここでの非常に小規模な制作の例は何かな？ 優れた制作品質の独立したYouTubeチャンネルもこれを使ってるのかな？
重要なポイントは､ライブでなければ､通常はカメラで全てを手動で調整し､ポストプロダクションで仕上げることができるので､リモートはライブ制作の制約の外ではほとんど使用されないってこと｡
その反対に､Love Islandでは約250台のカメラがあったと聞いたけど､一度に多くの変更を加える必要がないので､1つまたは2つのリモートからほとんど全てを制御できるんだ｡アクションはそれらのうちの少数でのみ発生するんだ｡とは言っても､250個のプロセスが実行されて､これらのカメラを継続的に制御してるよ｡
FX30､FX3､FX6はSonyのシネマラインにあり､これらのシステムが調整したい全てのカラー stuff があるかもしれないけど､よくわからないな｡これらのカメラはYouTubeでかなり使われてるよ｡
タイプの説明とか見てよ。関数ごとにタイプが画面のほとんど占めててスクロールしまくり。ヘッディングとかデータ型のリストとか昔はもっと見やすかったのに。左のナビゲーションも邪魔。
それ、再現できる？mix compileを実行すると、Bar.hello/0 is undefinedのような警告が表示されるはず。アプリが起動しないはずだよ。
警告にはコンパイル時の警告と実行時の警告の2種類がある。
CIで警告をエラーにするには--warnings-as-errorsを有効にする必要がある。
テストフレームワークはデフォルトでテストの順序をランダム化する。
依存関係のコンパイルは並列化されていなかったけど、今週PRがマージされた。
Supervisorに動的に子を追加する方法は、ElixirForumとかStackOverflowとかドキュメントに載ってる。
「open newest」へのリンクはExDocに追加された。
サイドバーのExDocsのナビゲーションが壊れている場合はバグなので報告してね。
