本動画は、インターネット上のあらゆる動画・音声処理を裏で支えるオープンソースソフトウェア「FFmpeg」と「VLCメディアプレイヤー」の真髄に迫る対談である。世界中の数十億ものデバイスで利用されるこれらの技術が、いかにしてボランティアエンジニアたちの情熱と、アセンブリ言語を用いた極限の最適化によって構築されているかを解説する。プロジェクトの中心人物であるジャン＝バティスト・ケンプとキーラン・クンニャをゲストに迎え、ソフトウェア開発の哲学、大企業との軋轢、リバースエンジニアリングの苦労、そして超低遅延通信やマルチメディアの未来に至るまで、多岐にわたるトピックを深く掘り下げている。
- オープンソースコードにおける卓越性の追求
- FFmpegとVLC：インターネット動画の舞台裏
- VLCの驚くべき再生能力とアイコンの歴史
- 動画再生の裏側で起きていること
- コーデックとコンテナの複雑な関係
- FFmpegの魔法と動画処理の民主化
- オープンソースとライセンスの哲学
- リナックスの精神と優れたコードへのこだわり
- 巨額の買収オファーを拒否したVLCの信念
- セキュリティ研究者とオープンソースの軋轢
- バイナリ星系：FFmpegとVLCの共存関係
- リバースエンジニアリングの途方もない労力
- FATE：FFmpegの厳格なテスト環境
- アセンブリ言語による究極の最適化
- Rust言語とメモリ安全性の議論
- オープンソースプロジェクトにおける対立と和解
- メンテナの燃え尽き症候群と直面する圧力
- H.264と動画圧縮技術の進化
- AV1、AV2、そして次世代コーデックへの移行
- ソフトウェア特許という地雷原
- ヨーロッパにおける起業と規制の現実
- VLCのセキュリティとサンドボックス化の挑戦
- ネットワーク上の動画ストリーミングの課題
- Kyber：超低遅延が切り拓くロボティクスの未来
- デジタル遺産のアーカイブと保存
- マルチメディアの未来と脳波インターフェース
オープンソースコードにおける卓越性の追求
重要なのは、あなたの書いたコードが優れているかどうかです。私たちは卓越したコードを重視しています。あなたが誰であるかは気にしません。極端な話、犬であっても構いません。どこから来たのかも関係ありません。コードそのものを見せてほしいのです。イタリアやドイツ、あるいはアメリカの超大企業でエンジニアをしています、と言われても、私たちには関係ありません。私たちが気にするのはコードの品質です。なぜなら、それが私たちのコミュニティを定義づけるものだからです。結果として、全く異なる背景を持つ、非常に内向的な人々が多数貢献してくれることになります。もちろん、それで全く問題ありません。
FFmpegはおそらく、世界で最もCPUを消費しているソフトウェアの一つです。ここ数分で私たちが話したすべての事柄、すべての文章が、誰かの生涯をかけた仕事の結晶なのです。一つの文章だけで本が書けるほどです。ですから、多くの場合、その複雑さのレベルは尋常ではありません。
FFmpegには、すべてのコーデックのために10万行ものアセンブリ言語が書かれています。
すべてのコーデックのためですね。
そして、この特定のプロジェクトだけで24万行もあります。すべてのサイクルが重要なのです。おそらく30億台ものデバイスが、休むことなく動画をデコードし続けることになります。例えば現在、Netflixの動画の30パーセントがAV1形式になり、YouTubeでは50パーセントに達しているからです。
究極のビデオコーデックはこのようになるべきだ、という姿がここにあります。アセンブリ言語が79.9パーセント、C言語が19.6パーセント、その他が0.5パーセントです。
驚くべきことに、これらのツイートは事実に基づくものなのに、人々は激怒するのです。
ここ2年間、彼らは怒り狂っています。組み込み関数で十分だ、コンパイラがやってくれる、と。
コンパイラを最適化すればいい、自動ベクトル化ができるはずだ、あなたが理解していないだけだ、と言ってきます。しかし、私たちはそんなことはずっと昔から試してきているのです。
2年間もそう言われ続け、その2年後に手書きのアセンブリ言語の例を何百も示したにもかかわらず、いやいや、あなたのやり方が間違っている、コンパイラならできるはずだ、とまだ言うのです。
諜報機関が、VLCにバックドアを仕込むことはできないか、と言ってきたこともありました。
ええ、2つの機関からですね。
それに対して何と答えたのですか。
ダメだ、と。まあ、実際はもっとずっと丁寧さを欠いた言い方でしたが。
要するに、絶対に断る、ということですね。
もし自分たちのソフトウェアを妥協させなければならないとしたら、私たちはプロジェクトそのものを閉鎖します。これははっきりしています。
キーラン、後悔しているツイートはありますか。
後悔しているツイートですか。
フランスの歌にありましたよね。何も後悔していない、と。
何も後悔してはいけません。後悔というのは、自分自身の心への攻撃だからです。
FFmpegとVLC：インターネット動画の舞台裏
これよりお送りするのは、ジャン＝バティスト・ケンプとキーラン・クンニャを迎えての、FFmpegとVLCに関する対談です。
FFmpegはオープンソースのソフトウェアシステムであり、YouTube、Netflix、Chrome、VLC、Discordをはじめ、インターネット上で動画や音声に触れる実質的にすべてのプラットフォームを裏で支える目に見えないバックボーンです。これまでに作られたほぼすべての動画や音声のフォーマットを、デコード、エンコード、トランスコード、ストリーミング、そして再生することができます。私にとって、これはこれまでに開発された中で最も驚異的なソフトウェアシステムの一つであり、そのすべてがボランティアによって行われています。
VLCもまた、伝説的なソフトウェアです。これはオープンソースのメディアプレイヤーであり、投げ込まれたほぼすべてのもの、あらゆるフォーマット、あらゆるプラットフォームを再生し、広告もトラッキングもありません。これまでに60億回以上ダウンロードされており、私にとっても、これまでで最もお気に入りのソフトウェアの一つです。その伝説的なロゴに敬意を表して、今回の対談ではずっとVLCのトラフィックコーンの帽子をかぶることにしました。
改めて、何よりもまず、数十億人の人々に愛され使われているこのコードに心血を注いでくれた、信じられないほど素晴らしいボランティアエンジニアの皆さんに感謝します。ありがとうございます。
そして、このエピソードでお話しする2人の偉大なエンジニアであり人間についてご紹介します。ジャン＝バティストはVideoLANのプレジデントであり、VLCとFFmpegの背後にいる重要人物です。キーランは長年のコーデックエンジニアであり、FFmpegの貢献者であり、今や悪名高いTwitter/XのFFmpegアカウントの中の人でもあります。ミームや、オープンソースと素晴らしい低レベルソフトウェアエンジニアリングへの悪びれない称賛のために、誰もがこのアカウントをフォローすることをお勧めします。
また、現代文明の多くが、名声やお金を追い求めるのではなく、エンジニアリングの技術に執念を燃やす人々によって作られたソフトウェアの上に成り立っているということは、感動的であり、同時に謙虚な気持ちにさせられると言わせてください。私たちは、数十億人の人々が毎日動画を消費し、その下にある目に見えない機械仕掛けについて全く考えない世界に生きています。しかし、その機械仕掛けは重要なのです。オープンソースのインフラストラクチャは重要です。それは、私たち人類のために、国境を越えて静かに協力し、有用で耐久性があり、エレガントなものを構築する、人間の素晴らしい例の一つなのです。
ですから、この対談は単なるコーデックやメディアパイプラインについての話ではありません。FFmpegのようなプロジェクトを可能にする、エンジニアリングと寛大さのより深い精神についての話でもあります。何度でも言います。ありがとうございます。
こちらはレックス・フリッドマン ポッドキャストです。サポートしていただける方は、概要欄にあるスポンサーをご確認ください。そこには、私への連絡先、質問、フィードバックの送信先などのリンクもあります。それでは親愛なる友人たちよ、ジャン＝バティスト・ケンプとキーラン・クンニャの登場です。
VLCの驚くべき再生能力とアイコンの歴史
伝説によれば、VLCはあらゆるものを開くことができるそうですね。VLCが開くことができると知っている中で、最も奇妙なものは何ですか。
VHSビデオを録画するためにVLCを使っている人がたくさんいるのをご存知ですか。キャプチャボードに繋ぐだけで、基本的にVHSビデオを録画できるのです。
それはどういう仕組みなのですか。
基本的には、ペリテルやRCAを入力できるタイプのキャプチャボードを使います。それを繋ぐと、実際にVLCはその種のボードを再生でき、さらに一部のVCRカムコーダーを直接コントロールできるモジュールもあるのです。最近ではDVDオーディオもサポートしました。この夏はDVDオーディオのサポート作業に費やしましたが、今時DVDオーディオのサポートなんて誰も作っていません。独自の暗号化スキームがあるのです。
ルーカスフィルムについてはどうですか。
ああ、もちろんFFmpegがサポートしている奇妙なコーデックやゲームコーデックもすべてサポートしています。
あるスターウォーズのビデオゲームで、最初の10秒間のオープニングシーケンスがありました。誰かがそれを実装し、ゲーム内のある特定の小さなシーケンスで、かつて存在した1枚のディスクとビットレベルで完全に一致することを確認したのです。
面白いことに、あるVideoLANのカンファレンスで、VLCが再生できるかどうかを試すために、これまでで最も奇妙で恐ろしいファイルを作るコンペティションを開催しました。
結局何になったのですか。どんなファイルだったのですか。
デレクが作ったMKVファイルでした。フレームごとに解像度やアスペクト比が変わるのです。
回転もしたりして、本当にひどいものでした。
それは動いたのですか。
はい。他にも、動画全体が実はアニメーション化された字幕になっているというものもありました。SSAですね。
ええ、覚えています。
それぞれが、このファイルはフレームごとに黒いフレームになっていて、その上に各フレーム用にアニメーション化された字幕が乗っているのです。
有効なZIPファイルでありながら、同時に有効なMP3ファイルでもあるというようなファイルもありましたね。
そうですね、そんなくだらないファイルのコンペティションをやりました。
そして動いたのですね。くだらないファイルすべてを開くことができた。
はい。
ところで、ご存知ない方のために言っておくと、私は帽子をかぶっています。これは史上最高に最悪なロゴ、コーンだと言っても過言ではないでしょうか。
ええ、間違いなくそうですね。VLCのロゴは本当に象徴的です。私たちは少人数のチームですが、このアイコンは世界中で知られています。インドや中国の本当に何もない田舎に行っても、人々はこのコーンを知っています。メインのウェブサイトへのトラフィックの25パーセントは、コーンプレイヤーで検索してきているのです。非常に多くの人がVLCという名前を知りません。彼らはコーンプレイヤーとして知っているのです。
Googleで検索する時の言葉がコーンプレイヤーなんですね。
そうです。Googleでコーンプレイヤーと検索して、VLCをダウンロードするのです。それくらい象徴的です。一度、ジョークでロゴを変えようとしたことがありました。ある種の建設用キャタピラーにする予定だと言って、4月1日のエイプリルフールに発表したのです。
そうしたら、ロゴを変えないでくれといった内容のメールが1万通ほど届きました。それくらい象徴的で、特徴的なのです。もし動画プレイヤーを作ろうと思ったら、テレビの画面に再生ボタンを置くデザインにするでしょう。それはYouTubeのロゴです。オリジナリティがありません。このロゴはオレンジ色です。
そうですね。
とても明るくて、奇妙です。
馬鹿げていて、不条理で、笑えます。それがミームになり、ミームが文化になります。
そして、皆それを使い続け、知っていて、20年後もこのコーンを見て、ああ、あれは動画プレイヤーだったなと思い出すのです。
そうですね。これから、FFmpegの使命であるアーカイブの側面についても話すことになります。今から1000年後、VLCでしか開けない動画がたくさん残っている状況を想像してみてください。人類文明が何度も滅びてしまった後、残っているのはゴキブリが這い回る中で、VLCが開けるアーカイブ映像とこのVLCのロゴだけかもしれません。宇宙人がやってきて、再生ボタンを押し、すべてを見ることになる。
本当に、本当にそうなることを願っています。でも、DVDドライブの中にパンケーキを入れても、VLCならきっと再生してくれるだろうというミームもたくさんあります。
再生できるんですか。
いえ、試しましたがダメでした。
ダメなんですね。
実際に私たちがそれを試した動画があります。うまくいきませんでした。
物理的な現実のためのコーデック、それがどのようなものになるのか想像もつきません。
それをやった人がいましたよ。私たちがグッズとして配っているような小さなコーンを3Dプリントし、その中に映画を再生するためのRFIDチップを入れました。
それをRFIDリーダーに乗せると、最後のスターウォーズなどの映画が再生されるのです。だから、DVDのケースの代わりにVLCのコーンが周りにたくさんあって、それを繋ぐことで物理的なオブジェクトとして機能していました。
動画再生の裏側で起きていること
私たちが話しているのは、ビデオコーデック、動画のエンコード、動画のデコード、動画ストリーミング、そして私が頭にかぶっているVLCのような動画クライアントに関するすべてのエコシステムであり、それが無料のメディアを可能にしているということです。これからFFmpegについて、VideoLANについて、VLCについて、そしておそらく数十億人に使われている他の素晴らしい動画テクノロジーについて話していきます。
JB、あなたは伝説的なVLCプレイヤーの開発リーダーですね。そしてキーラン、あなたは数ある顔の中でも、伝説的なFFmpegのTwitterハンドルの開発リーダーでもあります。お二人とも、かなり辛口な意見をお持ちですね。
今日はFFmpegとVLCについてお話ししたいと思います。ご存知ない方のために背景を説明しますと、これを聴いているほぼすべての人が、無意識のうちにこの2つのテクノロジーを日常的に使っているはずです。
FFmpegは、YouTube、Netflix、Chrome、Firefox、もちろんVLC、その他無数の動画プラットフォームを含め、インターネット上のほぼすべての動画の基盤となっています。オンラインおよびオフラインの動画処理ワークフローの90パーセント以上で、FFmpegが関与していると推測されています。VLCは少なくとも65億回はダウンロードされています。しかし、正確な数を数えるのは不可能なため、おそらくその数ははるかに多いでしょう。実質的にあらゆるオペレーティングシステムで、実質的にあらゆるメディアフォーマットをサポートしています。
唯一の制限は、パンケーキを開けないことくらいです。さて、これらすべてに何が関わっているのかを理解するために、基本的な部分を説明していただけますか。VLCのような動画プレイヤーで再生ボタンを押した時、何が起きているのでしょうか。ファイルやストリームから、画面上のピクセルやスピーカーからの音声になるまで、どのようなプロセスを辿るのですか。知っておくべき大きな段階は何でしょうか。
いくつかの段階があります。最初の段階は、URLのようなアドレスから、データのストリーム、つまりバイトのストリームを取得することです。例えばHTTP、ファイル、DVDなどです。メディアへのパスを指定すると、データのストリームが返ってきます。
そのストリームは、コンテナ、またはデマルチプレクサ（デマクサ）と呼ばれるものによって切り分けられる必要があります。専門用語はできるだけ避けますが、これは動画と音声のフレームの境界を定める役割を果たします。オペレーティングシステムからブロック単位でデータを受け取り、これらのフレームを圧縮されたデータへと切り分け始めます。その後、動画フレームの簡単な解析を開始します。
これは主に、そのコーデックがGPUでデコード可能か、それともソフトウェア処理にフォールバックする必要があるかを判断するためです。私たちは、GPUがこれらすべてを再生してくれる、ハードウェアアクセラレーションが効くと思い込みがちです。しかし、ファイルの最大45パーセントはGPUでデコードできません。そのため、これらを調査し、検出する必要があります。特定のコーデックの亜種が存在し、その一部だけがGPUでデコード可能な場合もあります。GPUのベンダーによっても機能が異なるため、これらを検出する必要があります。もしGPUが対応していれば、GPUというブラックボックスに処理を任せます。
もしソフトウェアでのフォールバックが必要な場合、最初のステップはエントロピー復号を行うこと、つまりビットストリームの数学的なエンコードを解除することです。これにはハフマン符号や算術符号といった機能を使用し、ビットストリームの数学的な層を実際に解凍します。
次に、イントラ予測のための構文要素を読み取る必要があります。イントラ予測とは、動画の静止画像、つまりIフレームのようなものです。これは空間ドメインで機能し、操作されます。そのため、空間ドメインでイントラ予測を行います。予測は現実と完全に一致するわけではないので、残差が生じます。予測を行った後に少し残る部分、これが残差と呼ばれるものです。これは周波数ドメインで保存されており、スペースを圧縮するために量子化されています。これを逆変換して空間ドメインに戻し、これらの残差を適用する必要があります。
つまり、デコードのプロセスの多くは、圧縮されたものに対して行われるのですね。そして、そこに入るべき最も高品質なものを予測しなければならない。Iフレームは空間的に最高の表現を提供します。そして、コーデックに応じて多くの時間的圧縮が行われ、その後予測を行います。最も生の形でキャプチャされた現実が何であったかを予測するわけですね。
はい。人々が気づいていないのは、動画や音声の圧縮率が100倍にも達するということです。私たちがどれほど圧縮を行っているか、人々は理解していません。音声の場合、通常の音声からMP3に変換する際、10倍に圧縮します。動画になると、100倍、200倍の圧縮が必要になります。そのため、気にしなくてもいいような細部をすべて取り除く必要があります。私たちが忘れてはならない非常に重要なことは、私たちが行うすべての圧縮は、人間に見られることを前提としているということです。
ですから、音声のコーデックも人間の耳の仕組みを模倣しています。耳の反応や、目についても同様のことが言えます。例えば動画では、RGBでは処理しません。誰もがRGBで処理すると思っていますが、そうではありません。私たちはYUVに移行します。基本的には、一つが輝度（明るさ）で、他が色です。
これは人間の目に合致しています。目の中には錐体と桿体があり、一方は明るさを、もう一方は色をより強く認識します。そのため、大幅に圧縮し、劣化させる必要があります。しかし、劣化させる際には人間の知覚に合わせる必要があり、これが非常に難しいのです。
そのために、最大のパワー、数学的なパワー、非常に複雑なテクノロジーを使う必要があります。キーランが言ったように、周波数ドメインに移行します。最高の圧縮を得るために大量の逆量子化を行いますが、それでも見た目は良く保たれます。
人間の知覚にとって最高品質のものを最大化するために、圧縮しようとしているのですね。
その通りです。そしてこれが非常に重要です。圧縮はZIPのようなものではありません。ZIPはデータを入れて、データを取り出すものです。そして、すべてのZIP圧縮で限界に到達しようとします。しかしここでは、信号を意図的に劣化させているのです。そのため、音声と動画の両方の信号を、可能な限り最良の方法で劣化させる必要があります。それは可能ですが、まず目がどのように機能するかについての多くの理論的な知識が必要であり、さらに多くの数学的な変換、数学的なトリックが含まれます。
例えば、RGBからYUVに変換する際、私たちがよく行うのは、明るさに比べて色の解像度を下げることです。ほとんどの場合、圧縮しなくてもこれだけでサイズが半分になりますが、ほとんどの人はその違いに気づきません。他にも多くの手法があります。
その後、非常に複雑な数学的変換に進みます。もちろんフーリエ変換です。実際にはフーリエ変換ではなく離散コサイン変換ですが、基本的な考え方は同じです。周波数ドメインで動画をブロックごとに分割します。ですから、デコードが間違っていたり、エンコードが悪かったりすると、それらのブロックが見えるようになります。そうやって、狂気の沙汰とも言える高い圧縮状態に到達するのです。コーデックの各世代は、同じ品質でサイズが30パーセント小さくなります。
これには膨大な計算能力が必要です。
いえ、もっと詳しく説明すべきです。30パーセント良くなるのですが、その圧縮を達成するための計算能力は、おそらく1桁、あるいは2桁多くなります。そこが大きな違いです。
圧縮能力とはどういう意味ですか。
すみません、そのレベルの圧縮を達成するためのCPUパワーのことです。
なるほど。CPUや、言及されたように時にはGPUを活用できなければならないのですね。そして、このプログラミングの多くは、C言語や、もちろんあの伝説的なTwitterハンドルが何度も強調しているように、大量のアセンブリ言語といった、可能な限り低いレベルのスタックで行われていることに触れておくべきでしょう。
全体的に何が起こるかというと、OSを介してデータストリーム、バイトのストリームを提供するアドレスがあります。これが最初のステップです。第2のステップはデマルチプレクスで、音声、動画、字幕を異なるタイプのトラックに分離します。
そして、それらの各トラックに対して解凍とデコードを行います。音声はオーディオコーデック、動画はビデオコーデック、字幕は字幕コーデックを使います。これらの解凍が終わると、生の画像が得られ、グラフィックカードや画面と通信してそれを表示します。音声も同様にオーディオカードと通信し、アナログに変換されてスピーカーから出力されます。
コーデックとコンテナの複雑な関係
私たちがここ数分で話したすべての文章は、誰かの生涯をかけた仕事です。すべての文章について本が出版されています。そのため、多くの場合、複雑さのレベルは計り知れません。一つ一つの文章に、業界全体で何千人もの人々が関わり、本が書かれているのです。ですから、多くの詳細、多くの微妙なニュアンスがあり、学術的な現実と実用的な現実の両方が存在し、その両方が重要なのです。
コーデックについては触れましたが、コンテナについてはまだ説明していませんね。私たちが話しているものの実際のコンテナとは何でしょうか。人々はMP4、MOV、MKVには馴染みがあります。コンテナと、その中に入るものの違いは何ですか。
コンテナは、私たちがマルチプレクサ（マクサ）とも呼ぶものです。デマルチプレクスと言う時は、コンテナから取り出すことを意味します。実際、muxはマルチプレクサ、demuxはデマルチプレクサの略です。コーデックも同様に、コーダーとデコーダーのことです。
コンテナは、これらの複数のトラックの集合体です。一般の人がファイルフォーマットと呼ぶものですが、実際にはもう少し微妙なものです。最もよく知られているのはもちろんMP4ですが、私が始めた頃はAVIでした。AVIはMicrosoftの動画フォーマットで、MOVはAppleのフォーマットであり、これがMP4になりました。オープンソースコミュニティでは、現在もVideoLANで活動しているスティーブ・ロムという人物が、もう少し複雑で将来性のあるMatroskaというフォーマットを作りました。他にも本当にたくさんあります。
よくあることですが、この対話中でも起こるかもしれませんが、人々がコンテナとコーデックを混同してしまうことがありますよね。例えば、MP4とH.264を混同するなど。それはひどい間違いなのでしょうか。
いいえ、そうでもありません。H.264の正式な技術名称はMPEG-4 Part 10だからです。MPEG-4は実際にはメタ仕様であり、その中にいくつかのものが含まれています。Part 2のようなものもあります。
音声コーデックもありますね。事実上、AACはMP4のオーディオにあたるものです。実はMPEG-4の仕様の中には複数のビデオコーデックが存在します。その一つがMPEG-4 Part 10であり、AVCとも呼ばれ、H.264とも呼ばれます。
物事を理解しにくくしているのは完全に業界の責任です。MPEG-4 Part 10について話しているのに、実はH.264を意味していたり、それがなぜMP4ではないのかを人々が理解できないのは非常に難しい問題です。
つまり、技術的には、コンテナの中に様々な異なるコーデックをごちゃ混ぜに詰め込むこともできるわけですね。
しかし大雑把に言えば、MP4は一般的にH.264の動画とAACの音声の組み合わせだと理解されています。99パーセントのケースでそうであり、残りはごくわずかなエッジケースに過ぎません。ですから、混同しても世界の終わりというわけではありません。それにイライラする人もいますが。
しかし現実には、VLCのようなものでは、ファイルの拡張子が.MP4となっていても、中身が全く異なるものである可能性があります。これこそが、FFmpegとVLCが直面している課題の一つです。現実世界は、たった3文字のファイルフォーマットの拡張子とは全く異なる場所なのです。
そして、これは非常に重要なことです。VLCやFFmpegでは、ファイルフォーマットを無視します。ファイルの中身を調べて、何が入っているのかを理解しようとします。多くの人が「動画だからMP4のはずだ」と言っても、技術的にはMOVだったりMKVだったりするからです。そのため、手元にあるものをリアルタイムで分析し、フォーマットを信用しません。
では、.MP4であるという事実はどのような情報を与えてくれるのですか。
ヒントにはなります。最後が.MP4で終わっているから、まずはMP4コンテナのデマルチプレクサで開いて調べてみよう、と判断の助けになります。しかし信用はしません。もし迷ったら、「よし、これを試してみよう」と、そのモジュールの優先順位を上げるのです。
少し本筋から逸れますが、MP4として試してみて、予想していたコーデックとは異なるものだったと分かった場合、ほとんどのプレイヤーはそこで動作を停止してしまいますよね。
はい。
はい。
では、なぜ壊れないのですか。哲学的な観点からしても、途中に多くのつまずきの石があり、壊れて停止し、パニックになるのは簡単だと思います。VLCはどのようにしてそうならないのですか。
これこそがVLCが人気である理由です。そもそもVLCは、90年代後半に遡るVideoLANというストリーミングソリューションの単なるクライアントとして始まりました。UDPというネットワークプロトコルで動画を再生する場合、データが破損している可能性があります。そのため、入力を信用しません。これもセキュリティにおける非常に重要な点ですが、入力を信用しないのです。VLCのすべては、壊れたファイルでも動作するように準備されています。
これは最初からの哲学的な理念であり、すべてがそのようにエンジニアリングされています。一種の文化ですね。
VLCはそれによって非常に人気が出ました。昔、人々がコンテンツを海賊版としてダウンロードしていた頃（今はかなり減りましたが）、
私たちは誰もそんなことはしていませんよ。
ええ、もちろん誰もしていません。AVIのような一部のファイルでは、再生するためのメタデータがファイルの末尾にあります。ダウンロード中の場合、そのデータはまだありません。しかしVLCは、「このファイルは壊れているけれど、それでも解釈しようと試みる」というアプローチを取り、これが非常に役立ったのです。
FFmpegの魔法と動画処理の民主化
様々なプロセスの素晴らしさについて触れてきましたね。コーデックの素晴らしさ、その奥深さと豊かさ、そしてそこに関わるすべてのものの複雑さについてです。そもそもビデオコーデックとは何なのか、圧縮するとはどういうことなのか、改めて定義してみましょう。すでに少し触れられていますが、もう少し詳しく説明していただけますか。
どんな動画にも、空間的および時間的に膨大な量の冗長性が存在します。すべてのビデオコーデックの目的は、この冗長なデータを取り除き、この削減プロセスの一部として数学的な特性を利用することです。多くの場合、圧縮には数桁多い計算能力を使用します。これは、復元（解凍）するよりも、金銭的にもCPUリソース的にもコストがかかるためです。つまり、その点において非対称なのです。
多くの場合、圧縮は一度しか行われませんが、そのファイルを視聴する人は多数いる可能性があります。そのため、冗長な情報を取り除き、数学的な特性を利用して情報を100倍、200倍に圧縮して小さくしつつ、エラー耐性などの特性も持たせる必要があります。JBが指摘したように、初期のVLCはUDPネットワークフィードの再生に使われており、UDPネットワークフィードはパケットを失います。そのため、コーデックの設計目標の一つは、回復可能であることでもあります。
ストリームの途中から参加できる必要があります。必ずしもファイルではありません。デコードプロセスに途中から参加し、デコードを開始できなければならないのです。
馴染みのない方にもう少しイメージしやすく説明しましょう。どんな映画を見る時でも、カメラがパンしたり移動したりするシーンがありますよね。そうすると、例えば背景の雲が1分間、あるいは30秒間ずっと同じであることに気づくはずです。そのため、背景に見える雲の情報を、あるフレームから次のフレームへと再利用することができます。
メモリや処理能力があればあるほど、より多くの比較を行うことができます。したがって、より高度に圧縮することができます。そして、最新のコーデックのほとんどは基本的にそれを行っています。
さらに明確にしておきましょう。動画とは何でしょうか。動画とは、多くの場合RGBのピクセルの集まりです。3つの値があり、ピクセルのグリッドがあり、秒間24、30、あるいは60のフレームがあり、これらのピクセルが1秒間に30回繰り返され、異なるものを表示しています。そこでの哲学的、技術的な問いは、どうすればこれらすべてを100倍に圧縮し、保存できるかということです。
ええ。あるいは1000倍ですね。
1000倍ですか。
目標は1000倍です。
冗長性と言う時、何が冗長なのでしょうか。欠落していても人間が気づかないようなもの、ということですよね。
例えば、雲の画像があったとします。次のフレームでも同じ雲が存在するので、それは冗長です。一度だけ配置して、あとは省略すればいいのです。あるいは、私の後ろに黒い背景があるとします。画像全体で黒は同じです。ですから、「この画像の左上のピクセルと右上のピクセルを見てください。値は教えません。左上と同じだということだけ伝えます」と言えます。そして、フレーム1に対して、前のフレームやさらにその前のフレームから何かを再利用する、というように続けていくことができます。
基本的には無制限に行えますが、メモリや計算能力の制限にぶつかります。例えば、4K解像度で過去200フレームのピクセルを比較する必要がある場合、それは膨大な計算量になります。
そして表示する時には、それらすべてを解凍しなければなりません。エンコードとデコードは、セットとして開発されるプロセスなのでしょうか。
はい、その通りです。そしてそこには異なるトレードオフがあります。より圧縮率を高めるか。しかしそうすると、デコードがより難しくなるかもしれません。エンコードは複雑でもデコードが簡単なコーデックにするか。高速化のためにエンコードが簡単なコーデックにするか。しかしその場合、クライアント側、つまりプレイヤー側の負荷が増えます。だからこそ、これほど多様なコーデックが存在するのです。常に簡単というわけではありません。
さらに複雑なことに、AV1、AV2、VVCといった最新のコーデックは、実際には単一のコーデックではありません。それらはツールの集合体なのです。画像に応じて最大限の圧縮を得るために、同じコーデックの中に複数のツール、複数のコーデックが組み込まれています。
少し補足すると、AV1やVVCのようなコーデックは、非常に幅広い用途を想定しています。画面共有のコンテンツかもしれないし、動画かもしれないし、アニメーションかもしれない。これらはすべて異なるコーディングツールを必要とします。
最近では、様々なユースケースに対応するためにツールの集合体がまとめられ、それがAV1と呼ばれたり、AV2、VVCと呼ばれたりしています。ZoomでPowerPointを共有していて、その後視聴者に動画を見せる必要があるかもしれません。そのコーデックは、コンテンツに応じてツールセットを変更し、異なる方法で圧縮を開始する必要があります。
おっしゃる通り、例えばAV1を構成するツールの各部分の背後には、素晴らしいエンジニアのグループが存在するのですね。
少し遠回りしましたが、VLCのロゴや帽子について話しました。今度はFFmpegについて話しましょう。FFmpegとは正確には何ですか。
FFmpegは基本的に、圧縮と解凍、マルチプレクサとデマルチプレクサ、そしてフィルターのための低レベルライブラリです。これが中核であり、さらに、あらゆる種類の動画ファイルを処理するためのパイプラインを作成できるツールがいくつかあります。
VLCからChrome、スマートテレビ、オンラインで目にするあらゆる動画に至るまで、文字通りすべての内部でライブラリとして使用されています。FFmpegの中にはこれらのツールすべてが含まれており、x264やlibvpxなどの他のライブラリに依存することもあります。今や画像処理のための事実上の標準ツールとなっています。
哲学的なレベルで考えると、あなたのホームビデオ、おばあちゃんのホームビデオと、何兆ドルもの規模の企業が、同じ技術スタックを使って同じ土俵に立っているというのは信じられないことです。
大企業が3000行にも及ぶFFmpegのコマンドを使っていたとしても驚きません。APIを使用しているところもありますが、長いコマンドラインをそのまま使っているところもあります。
ええ、FFmpegやFFprobeといった文字通りのコマンドラインツールがたくさんあります。libavcodec、libavformat、libavfilterといったライブラリもあります。
しかし、コマンドラインのFFmpegは伝説的です。パラメータが非常に多く、あらゆるものを極限までカスタマイズできるからです。
一つの言語です。実際の言語のようですね。
ええ、プログラミング言語のように考えることができます。
もちろんです。ほとんどの人は、FFmpegで入力ファイルと出力ファイル、そしてフォーマットを指定するだけでしょう。しかし、私たちは数千文字にも及ぶコマンドを見てきましたし、プログラミングを使ってFFmpegのコマンドラインを自動生成している人々も見てきました。AIを使ってFFmpegのコマンドラインを生成している人もたくさんいます。それが何なのか全く分からなくても、コマンドライン上で非常に多くの複雑なフィルターを指定できるからです。FFmpegは誰もが使用するマルチメディア処理のためのツールボックスの集合体なのです。
あなたの動画を見ているすべての人もそれを使っています。あなたはYouTubeを使っていますね。クライアント側ではFFmpegが動いています。サーバー側でも動いています。クライアント側はおそらくChromeで、そこでもFFmpegを使っています。録画にOBSを使っていますね。そこにもFFmpegが使われています。プロ用の大きな機材をたくさん使っていますが、その内部のどこかでFFmpegが動いている可能性は非常に高いのです。
人々にイメージしてもらうために言いますが、私はあらゆることにFFmpegを多用しています。動画の最初にイントロ動画を、最後にアウトロ動画を追加して、一方から他方へフェードさせるような簡単なことです。ディップ・トゥ・ブラックと呼ばれる、暗転してから次の動画を表示し、音声でも同じようにクロスディゾルブを行うような処理です。音声を小さくしてから再び大きくしたり、画面上にキャプションを焼き付けたり、フォントをカスタマイズしたりすることもできます。
音声と動画のあらゆる種類のレイヤー化を行うことができます。数え切れないほどの機能があり、もちろんそのすべてが、事実上あらゆるコーデックで魔法のように機能します。音声でも動画でも、放り込んだものは何でも処理できるのです。
例えば、Adobe After Effectsで行うような処理を、コマンドラインのFFmpegで実行できるのです。これは非常に興味深いことです。画像処理において、これほどの幅広さを持つツールはありません。
ImageMagickも似たような精神を持っていますが。
ええ、しかし複雑なフィルター処理まではできません。コマンドライン上でPhotoshopに相当するものは存在しません。しかし動画に関しては、コマンドラインにFFmpegが存在するのです。
信じられないことです。素晴らしい人々が集まり、ビジョンを持ち、そのビジョンを長年にわたって堅持し続けているということの良い例です。本当に素晴らしいことです。
VLCとFFmpegの背後にあるビジョンは、技術的に非常に複雑なものを、一般の人々、つまりすべての人にとって使いやすくすることです。私たちの目標は、内部的には極めて複雑なものを、使いやすくすることなのです。
人々はVLCを使い、ファイルをドロップします。そのファイルがいかに複雑かを認識することなく、ただ再生します。あるいは、FFmpegにどんなファイルでも複雑なフィルターと一緒に放り込めば、魔法のように機能します。そして人々はそれを使います。これが私たちの使命です。非常に複雑なものを扱うことです。
これがもし従来のテレビスタジオのような設備を必要としていたら、私たちはここにいなかったでしょうし、あなたもここにいなかったはずです。FFmpegのようなツールがこれを民主化したのです。ポッドキャストとストリーミングの革命、YouTubeの革命を引き起こしました。FFmpegはそこに大きく貢献しました。90年代には、圧縮を行うために数十万ドルもする車ほどの大きさの機材が必要だった技術を民主化したからです。今では誰もが、ほぼ完全に平等な土俵でそれを利用できます。これは本当に注目すべきことです。
多くの人々に発言の機会を与えました。念のため明確にしておきますが、「あなたはいなかっただろう」というのは、人間としてのあなたではなく、ポッドキャストのことです。
ポッドキャストですね。すみません、あなたという人間そのものとして捉えていました。
生物学的なレベルで私という人間を創造することに、VLCは一切関与していませんからね。
しかし、テキストから画像へ、そして画像から動画へとすべてが移行していったことにも気づくはずです。ソーシャルネットワークを見てください。動画はどこにでもあります。それは存在する中で最も強力なメディアです。ショート動画やリール、TikTokを見ればわかるように、非常に強力です。動画はそのために素晴らしいものです。しかし、その複雑さこそが重要なのです。
これは人々が気づいていないことです。これが世界中の個人に力を与えたのです。これこそが真の自由です。信じられませんが、なじみのない人々のためにまだ明白なことに触れていませんでした。それは、これがオープンソースであり、その背後にはユーザーと開発者のオープンソースコミュニティが存在するということです。
これは本当に一つのムーブメントです。その背後にあるコミュニティについて、様々な角度から話していきますが、オープンソースの要素について話していただけますか。「FFmpegとは何か」と聞かれたら、それはオープンソースプロジェクトです。
オープンソースとライセンスの哲学
ええ。FFmpeg、VLC、x264、VideoLAN、私たちがやっていることはすべて完全にオープンソースです。オープンソースの仕組みがわからない人に対して、私はよくチョコレートチーズケーキの例え話をします。
通常、チーズケーキを買いたい時はパン屋に行き、チーズケーキを受け取ります。もう一つの方法は、おばあちゃんからレシピを教えてもらうことです。オープンソースでは、チョコレートケーキを渡すと同時に、全く同じケーキを作るためのレシピも渡します。さらに、オーブンの作り方や、レシピを変更して別の人に販売する許可についても伝えます。
ソフトウェアというのは、細かな指示が書かれた非常に長いレシピのようなものだからです。コンピュータはあまり賢くありませんが、非常に高速に動作します。通常のプログラムには、チョコレートケーキのレシピが数十行であるのに対し、数百億もの指示が含まれています。
かつてソフトウェア産業の多くは、完成したチーズケーキだけを売るようなものでした。オープンソースでは、すべてを提供します。それによって、多くの人が協力し合うことができるようになりました。動画のための最高のプログラム、最高のレシピを作ろうと決め、コミュニティを作るのです。FFmpegには、初期からおそらく2000人から3000人の人々が貢献してきました。
何千人もの人々ですね。ええ。
初期から貢献しています。Linuxカーネルと全く同じです。Linuxカーネルにはおそらく1万人の貢献者が世界中にいて、彼らはほとんどオンラインで集まります。仮想的に集まって、何かのための最高のツールを作るのです。FFmpegとVLCでは、「このコーデックが機能しないから、このコーデックの作業をしよう。このファイルのサポートをFFmpegに追加して、みんなの役に立つようにしよう」という風に進みます。なぜなら、私たちはより大きな利益のために、すべての人のために働いているからです。それがオープンソースです。
ライセンスによっては、それをラップするだけで、10億ドル、あるいはおそらく1兆ドル規模の企業を作れることも言及しておくべきでしょう。
ええ、実際にそうしている人はいます。クラウドプロバイダーがいくつかのオープンソースツールを実行し、それにアクセスするためのAPIを提供しているケースで多くの問題がありました。MongoやElasticのような多くのデータベースが、そうしたシナリオを避けるためにライセンスを変更しました。
FFmpegでも「なぜそうしないのか」という質問をよく受けます。しかし、できないのです。何千人もの貢献者がいて、中にはすでに亡くなっている人もいます。それを行うには全員の同意が必要になります。VLCでライセンスを変更するプロセスがどれほど困難だったかについて、後でJBが少し話してくれるかもしれません。
ライセンスは、事実上ルソー的な意味でのコミュニティの社会契約です。コミュニティはライセンス以外についてはあまり合意していません。人々が議論を交わすのはライセンスが理由であり、それによってライセンスのフォークも可能になります。コミュニティが分裂することもありますが、ライセンスのおかげで可能であり、また元に戻ることもできるのです。
そうした例は何度も見てきました。過去のGCCとEGCSなどです。ウェブブラウザでも見られました。KHTMLとして始まり、それがWebKitになり、そしてBlinkになりました。オープンソースのライセンスはコミュニティの核心のようなもので、世界中から、全く異なる宗教や政治的境界を持つ人々が集まり、特定の問題を解決するために同じプロジェクトで協力します。私たちが取り組んでいる特定の問題とは、マルチメディアを誰もが簡単に利用できるようにすることです。
ここでPerplexityで検索してみますと、様々なオープンソースライセンスについて書かれています。主要なオープンソースライセンスのほとんどは、条件が非常に少ない寛容型（パーミッシブ）と、派生物に同じ条件での共有を求めるコピーレフト型の2つのバケットに分類されます。以下は、実際によく見られる主なライセンスの簡単な実践的要約です。MITライセンス、BSD、ISC、Apache、GNU GPL、GNU AGPL。LGPLはどこだ？ああ、LGPLもありました。他にもMozilla Public License、Eclipse Public Licenseなど、たくさんありますね。多様性があります。特に人気なのはMIT、GPL、LGPLでしょうか。
ええ。それにBSDですね。
それからApache。
Apacheもですね。
アンライセンスという選択肢もあります。これはコードをパブリックドメインに捧げようとするもので、フォールバックとして寛容なライセンスを含んでいます。
様々な目的に応じた多くのライセンスがあります。人々が理解していないのは、パブリックドメインという概念が世界共通で存在するわけではないということです。そのため、すべてのオープンソースライセンスは、ソフトウェアの使用方法や変更方法に関する権利を付与するために、国際的な著作権法を利用しています。
事実上、エンドユーザーや開発者に与えられる著作権ライセンス契約なのです。まず、MITやBSDのような非常に寛容なものがあります。コードを提供し、基本的には好きなように使っていいというものです。受け取って、変更して、好きなようにする。これはJavaScriptやBSD系のオペレーティングシステムで人気があります。
そのうちのいくつかのパラメータは、帰属の表示を必要とするかどうか、つまりコードを使用する場合に明記しなければならないかどうかですね。
はい。そのような寛容なライセンスの中には、使用したことを明記する必要がある（帰属表示と呼ばれる）ものと、そうでないものがあります。そしてもう一つのライセンス体系がコピーレフトと呼ばれるもので、コミュニティに変更を還元する必要があり、様々な条件が付随します。Mozilla Public Licenseのような弱いコピーレフトライセンスから、GPLのような強いもの、さらにAGPLのような非常に強いものまであります。
これらはすべて、目標やコミュニティをどのように構成したいかによって異なるライセンス形態です。私が社会契約について話したのはそのためで、これは理解することが非常に重要です。FFmpegとVLCは主にGPLまたはLGPLです。LinuxカーネルはGPLですが、AndroidはApacheです。使用されている多くのJavaScriptフレームワークは主にMITです。OpenBSDやNetBSDなど、すべてのBSDカーネルはもちろんBSDです。このように、人々にどのように貢献してほしいかという哲学的な違いなのです。
プロジェクトのある部分においてGPLからLGPLに移行したとお話しされましたね。この2つの違いを説明していただけますか。より寛容な方向への移行ですよね。LGPLはGPLよりも寛容です。
はい。理解しておくべきなのは、より寛容なものから制限の厳しいものへは常に移行できるということです。これらのライセンスは基本的に宣言なので、制限を強めることは常に可能です。したがって、GPLプロジェクトでMITのコードを使用することはできますが、その逆はできません。より厳しい制約を一致させる必要があるからです。
実際に私は、VLCのエンジンであるlibVLCのコア部分をGPLからLGPLに変更しました。それには2つの理由がありました。1つ目の理由は、サードパーティのアプリケーションでVLCエンジン（libVLC）を使用できるようにするためです。携帯電話やタブレットで動画を再生するアプリケーションの多くは、実は内部でVLCエンジンを動かし、そこからFFmpegを呼び出しています。
そのことが、私が立ち上げた企業の1つを創設する方法となりました。その企業は、ゲームエンジンなどのサードパーティソリューションにVLCを統合するようなアプリケーションのコンサルティングや統合を行っています。GPLのままではそれができませんでした。なぜなら、ゲーム全体をオープンソース化しなければならなくなるからです。ソースコードを公開したくない多くの商業企業にとっては、それは避けたいことでした。
つまり、LGPLならそれを中心に企業を作ることができるのですね。
はい。
商業的な展開が可能で、オープンソース化する必要がない。それは大きな飛躍ですね。
ゲーム内で動画を再生できるということです。
ええ。
問題は、私がゲーム開発者だとして、動画をいくつか再生したいだけなのに、そのためだけにゲーム全体をオープンソース化することを強制されたくないということです。そこで、コンサルティングビジネスや、LGPL化されたlibVLCが役立つのです。かつてLibrary GPLとして知られていたLGPLが、それを可能にしました。
FFmpegも全く同じです。LGPLは、このコンポーネント、つまりこのライブラリに加えた変更を還元することを強制します。だからLibrary GPLなのです。そのため、FFmpegを非オープンソースのアプリケーションにLGPLとして組み込むことはできますが、FFmpegに加えた変更は還元しなければなりません。libVLCでも同じです。
オープンソースの観点から見ると、GPLにするのは制限になるのでしょうか。ライブラリやコードがGPLであるということは、企業がそれを中心にビジネスを構築するのを基本的には思いとどまらせているということですよね。そう言っても差し支えないですか。
企業によりますが、ビジネスモデルがアプリケーションをクローズドソースにすることを要求する企業にとっては、はい、制限になります。だからこそ私はLGPLに移行したのです。
2つ目の理由は少し分かりにくいのですが、iOS向けのApple App Storeの利用規約により、GPLアプリケーションを掲載するのが非常に複雑である一方、LGPLアプリケーションは掲載しやすいからです。Windows、Mac、Linux上のVLCはGPLです。コア部分はLGPLです。しかしiOS版（iPhone版とApple TV版）は、MPLという異なる種類のライセンスになっています。ええ、ライセンスを変更するために動きましたが、それは長い道のりでした。
そうですね、基本的にライセンスを変更するには、すべての貢献者に連絡を取らなければならないのですよね。
はい。オープンソースプロジェクトというのは、米国の著作権法で言う「共同著作物」、大陸法で言う「集合的著作物」または「協同著作物」であることを理解しておくことが非常に重要です。同じ目標に向かって全員で協力し、1つのソフトウェア、1つのリリースを作り上げます。しかし、著作権は各個人が保持したままです。
そうしないオープンソースプロジェクトもあります。著作権の譲渡を強制するのです。しかし私たちはそうしません。私たちはコミュニティです。ですから、自分が変更した部分の著作権は各人が基本的に持っています。そして、その貢献が後に削除されたとしても、新しい貢献が過去のあなたの貢献に基づいているため、この著作権は残るのです。
そのため、適切にライセンスを変更したい場合、すべての貢献者を見つけ出す必要があります。当時、私は350人以上の人々に連絡を取らなければなりませんでした。時にはメールアドレスしか手がかりがないこともあります。実際に追跡しなければならないのです。オンラインで見つけたある人の職場まで実際に出向き、「あなたがライセンスを提供したコードについてですが、GPLからLGPLに変更することに同意していただけませんか」と尋ねたこともありました。
ほとんどの場合、彼らは気にしません。VLCの力になりたいと思ってくれています。しかし、非常に複雑な状況に直面することもありました。ある工場労働者の職場にたどり着いた時のことです。「これにサインしていただきたいのです」と言いました。実際にコードを書いたのは彼ではなく、亡くなった彼の息子さんだったからです。私はオープンソースの意味などすべてを説明しなければなりませんでした。私は、あなたの息子さんが書いた2行や5行のコードを盗み取ろうとしている企業ではありません、そのコードは有用で、コミュニティ全体がこれに同意しているのです、と。彼は工場労働者で、私が何者か全くわかっていませんでした。私は今よりずっと若く、14年も前のことで、もう泣きそうでした。
これは非常に難しいことです。私たちは人々の人生に関わっており、それを説明し、その人の息子の写真について語り合ったりしました。だからこそ、正しく、適切に行うことが重要なのです。しかし、ええ、それはすべての貢献に価値があるからこそ、すべてを追跡することを意味します。これを尊重しないプロジェクトもあり、私たちはライセンス変更を少し強引に進めることもあります。しかし先ほど言ったように、それはコミュニティの心を破壊してしまいます。なぜなら、私たちが同意しているのはライセンスについてだけだからです。だからこそ重要なのです。
コミュニティがいかに幅広い人々の集まりであるかを強調しておきたいですね。シリアの紛争地域で、限られた時間しか電気が使えない人もいます。裕福な人、貧しい人、若い人、お年寄りなど、あらゆる階層の人々がいます。ですから、ある一つのことについて人々の意見を一致させるというのは、それ自体が驚くべき偉業なのです。
ええ。本当に信じられないことです。彼らの多くは内向的ですから、彼らを見つけ出し、捕まえてメールに返信させるのは、かなり難しいかもしれません。
私たちのほとんどは内向的ですよ。もっと正確に言う必要がありますね。極度に内向的な人、超極度に内向的な人、そして普通に内向的な人がいます。様々な人々のスペクトラムが存在するだけです。そんなことは関係ありません。
リナックスの精神と優れたコードへのこだわり
重要なのは、あなたのコードが優れているか、技術が素晴らしいかということです。私たちは卓越したコードを重視しています。あなたが誰であるかは気にしません。申し訳ないですが、確認する術がないのです。確認できません。極端な話、犬であっても構いません。どこから来たのかも関係ありません。あなたのコードを見たいのです。
人々はこのことを理解しておらず、コミュニティにやってきてパッチを送り、それが拒否されると不満を持ちます。「申し訳ないですが、私たちの基準に達していません」と言うと、「でも私はイタリアやドイツ、アメリカのこの超大企業でエンジニアをしています」と言ってきます。私たちは気にしません。私たちが気にするのはコードの品質です。なぜならそれが私たちのコミュニティを定義づけるものだからです。結果として、全く異なる背景を持つ、非常に内向的な人々が多数貢献してくれることになります。もちろん、それで全く問題ありません。
コミュニティの伝説的人物の一人はもちろん、Linuxの生みの親であり、Linuxカーネルの長年のメンテナであるリーナス・トーバルズですね。伝説によれば、彼はこの実力主義のコードレビュープロセスにおいてかなり厳しく、「十分ではない」と切り捨てることもあるそうです。リーナス・トーバルズの伝説について少しお話しいただけますか。
リーナスは唯一無二の存在です。彼がGitで行ったことのほうが、Linuxカーネルで行ったことよりもさらに興味深いとさえ言いたいです。
彼は非常に厳しいですが、人々が見落としているのは、彼が厳しく接するのは通常、カーネルの一部のメンテナに対してだということです。つまり、彼らは互いを知っているのです。だから、誰に対してもあのように厳しいわけではありません。
彼が自分の部屋で作り上げたものが、基本的にオンライン上のすべてのサーバーを動かしているのです。MicrosoftのクラウドであるAzureでさえ、サーバーの70〜80パーセントはLinuxで動いていると確信しています。すべてのAndroidスマートフォンもLinuxで動いています。彼がオープンソースの力を使って成し遂げたことは、確かに驚くべきことです。
そしてええ、Linuxカーネルの品質は非常に高く、それは困難なことですが、私たちはそこで妥協することはできません。品質で妥協することはできないのです。なぜなら、最終的に（そしてこれを理解しなければならないのですが）、VLCのコアコミュニティは5人、FFmpegのコアコミュニティは10〜15人であり、私たちがあなたのコードを維持していくことになるからです。
タイムライン上の1000人の貢献者のうち、10人しか残らないとしたら、誰かがやって来て定着する確率は1パーセントです。たった1パーセントです。仕事が変わったり、妻が変わったり、子供ができたり、人生には予期せぬことが起こります。仕事が変わるなどして、戻ってこない可能性が高いのです。だから私たちがコードを維持しなければなりません。メンテナンス可能で、卓越したものでなければならないのです。
そしてええ、それは時に、あなたの書いたコードが良かったとしても、卓越していないためにやり直さなければならないことを意味します。私たちは全体にとって決定的に重要なものを維持するわずかな人数なので、卓越性を必要としているのです。
しかし、この高い卓越性のハードルを維持する際に使われる言葉には、ある種の辛辣さや厳しさがあることも言及しておくべきでしょう。これについて何か言えることはありますか。
それは事実です。私たちがやっているのは低レベルで、極めて技術的なことです。このコミュニティに入ると、そのトーンは非常に…一種のサブカルチャーのようなものになります。ですから、外部から来た人々はこのサブカルチャーを知りません。FFmpegやVLCに関わる人々のほとんどは、毎年VDD（VideoLAN DevDays）を開催していますが、実生活ではとても楽しくて、それを愛しています。
しかし、オンライン上では確かに、そのトーンがどのようなものか気づかないことがあります。でも、それでいいのです。
これは文化です。ゲーム文化でも同じようなことがありますね。かなり厳しく、激しいコミュニケーションの取り方があり、誰もがそれを理解しています。愛と敬意の示し方がコミュニティによって異なるだけです。読書クラブなら、普通はもっと優しいでしょう。それが、何百万人にも使われている非常に責任の重いオープンソースプロジェクトであれば…
しかし、ゲームなどで見られるような侮辱であることはほとんどありません。ですから、リーナスのトーンはオープンソースコミュニティの中でも少し異質です。もっと結果に対して厳しく、「いや、これは良くない。これはクソだ」というようなことを言います。
人に対する攻撃ではなく、コードに対するものにするように努めるのですね。
そうです。非常に事実に基づいています。そして、「有名なFFmpegはほぼ完全にボランティアによって開発されている」という事実の観点から見るべきだと思います。彼らは昼間の仕事で一日中懸命に働いた後、家に帰ってきているのです。簡潔すぎる言葉遣いになることもあるでしょうし、それを個人的な攻撃として受け取るべきではありません。
疲れていて忙しいけれど、それでもこのオープンソースのことを気に掛けている。しかし、細かい点までいちいち説明して手取り足取り教える余裕はないかもしれない。
それに、ほとんどの人が英語を母国語としていないことも理解しなければなりません。特にFFmpegやVLCのようなオープンソースプロジェクトは、主にヨーロッパを中心に活動しています。アメリカから来た人や、単にそのトーンに不満を持つ人もいますが、ほとんどの場合、彼らも悪気はないのです。難しいのです。英語は難しい言語です。多くの微妙なニュアンスやトーンがありますが、彼らにはそれがわかりません。ですから、そうしたコミュニティでは、異なる文化や言語が絡むことで難しさが生じることもよくあります。
巨額の買収オファーを拒否したVLCの信念
伝説によればJB、あなたはVLCを広告なしで誰でも無料で使えるオープンソースに保つために、数百万ドルのオファーを何度も断ったそうですね。数百万ドルを放棄するというその決断の背後にある理由を教えていただけますか。
ええ、それはRedditや9GAGでほぼミームになっていますね。
実際にRedditにミームがありますよね。「VLCメディアプレイヤーの生みの親、JB。彼はVLCを広告なしに保つために数千万ドルを拒否した。ありがとう、ジャン＝バティスト・ケンプ」と書かれています。魔法使いのようなVLCの帽子をかぶったあなたの画像で。Redditであなたを呼び出すことさえできます。
ええ、たいてい人々が私をタグ付けして、私が「おはよう」と返すと、2万4000ものアップボート（高評価）がつきます。素晴らしいですよね。少なくともそのアカウントでの私のRedditカルマは驚異的です。
まず答えるべき質問は、VLCのストーリーとは何か、ということです。なぜなら、私が数千万ドルを拒否したというのは事実だからです。ええ、何度もありました。ええ、私は億万長者になってどこかのビーチにいることもできたでしょう。しかし、私はそうしませんでした。それは道徳的ではなく、正しいことではないと思ったからです。これは私にとって非常に重要なことです。より大きな利益のために働く、人々のために働く、そしてそれは私だけのものではないということです。
そしてもう一つの理由は、私にはそうする（売却する）完全な正当性がないと感じたからです。その理由を説明しましょう。
VLCの歴史は非常に奇妙なものです。フランスには大学とは別に「グランゼコール」と呼ばれるエリート校があります。これらのトップレベルの優秀な学校は、エンジニアリング、ビジネス、そして弁護士や医療の学校です。これらは一般の大学の枠組みの外にあり、入学するためには、最高のエンジニアリングスクールに入るために2年間、数学や物理を狂ったように勉強します。
そのうちの一つが「エコール・セントラル・パリ」と呼ばれる学校です。現在は名前が変わっていますが、当時はそう呼ばれていました。「セントラル」という名前の通り、かつてはパリの中心部にありましたが、第二次世界大戦後に狭くなったため、フランスの中央部にあるクレルモン・フェランという場所に移転させようとしました。
しかし、同窓生たちがそれに反対しました。この学校はエッフェル塔を設計したエッフェルが通った学校なのです。「ダメだ、我々は素晴らしい学校だ。そんなことはできない」と言って、彼らはパリのすぐ南にある土地を購入しました。それは同窓生の非営利団体によって管理されるキャンパスでした。
そのため、キャンパス内のすべては学生によって管理されていました。大学は何もしていません。ラジオ、テレビ、スーパーマーケット、図書館、誰がどの部屋に入るかを決めることまで、すべて学生が管理していました。
素晴らしいですね。それがすぐに崩壊しなかったという素晴らしい実験です。どういうわけか繁栄したのですね。
非常にうまくいきました。これらの課外活動を通じて、私は人生で多くのことを学びました。22歳でキャンパスを運営しなければならないのです。そうしなければ電気も通らなくなりますから、真剣に取り組みます。
とにかく、80年代に彼らはネットワークを展開する完全な実験を行いました。主にIBMと3Comの支援を受けた、トークンリングネットワークでした。トークンリングは、おそらく今では誰も知らないネットワーク技術です。ルーターがなく、すべてが繋がっている文字通りのリング状のネットワークで、メッセージを送る時は隣のコンピュータに送り、それがまた次へとトークンとしてリングを回っていく仕組みです。
トークンリングの問題は当然ながら非常に遅いことです。ネットワーク上のすべてのコンピュータがメッセージを開き、自分宛てかどうかを確認し、違えば送り返さなければならないからです。
80年代なら、大学としてTelnetを使ったりメールを送ったりする程度なのでそれで十分でした。しかし90年代に入り、ビデオゲームの時代が始まります。DoomやDuke Nukemのようなゲームでは、ネットワークの遅延は致命的です。1994年か95年頃、彼らはより高速なネットワークを求めました。「もっと速いネットワークが必要だ。仕事にも、ビデオゲームにも」と。
学生たちが大学側に相談に行くと、大学はこう言いました。「申し訳ないが助けられない。キャンパスは我々のものではなく君たちが管理しているのだから、自分たちでなんとかしなさい。大学のパートナー企業にでも相談してくれ」。
そこで彼らは実際に、フランスのテレビ事業なども手がけていた大手企業、ブイグのCIOに会いに行きました。彼は「動画の未来は衛星だ」と言いました。今となってはそうでないと分かっていますが、当時は良いアイデアでした。1995年、最初のパラボラアンテナが登場した頃です。
彼は、1500人の学生それぞれにパラボラアンテナと巨大なデコーダーを用意する代わりに、巨大なアンテナとデコーダーを1つだけ設置し、動画をネットワーク上に直接ストリーミングしてはどうかと提案しました。
それには非常に高速なネットワークが必要でした。今日では当たり前のことですが、当時はローカルネットワーク上で動画をストリーミングする初めての試みでした。彼らはこのプロジェクトを構築し、「Network 2000」と名付けました。90年代ですから、未来的なものは何でも2000と呼ばれていました。
ええ、2000ですね。
そして彼らはNetwork 2000プロジェクトを実行しました。完全にハックされたものでした。45秒でクラッシュします。でも大丈夫、デモは40秒だからです。メモリリークも起こします。でも大丈夫、当時は8MBか16MBだったRAMを64MBも積んだからです。デモはそこで終了するはずでした。それが学生たちによるNetwork 2000プロジェクトでした。
彼らが扱う必要があった動画のフォーマットは何だったのですか。
MPEG-2です。衛星放送は伝送用のMPEG-2 TS、MPEG-2ビデオ、そして当時のMPEG-2オーディオだからです。
プロジェクトはそこで終わるはずでした。誰もが満足していました。155Mbpsの素晴らしいATMネットワークを手に入れ、当時のヨーロッパでおそらく最高のネットワークを手に入れたからです。そしてプロジェクトは終了しました。
その半年か1年後、2人の学生がやって来て言いました。「ローカルネットワーク上での動画ストリーミングに興味がある人が他にもいるかもしれない」と。そして彼らはVideoLANプロジェクトを開始しました。そのうちの1人が、キーランと私の親友でもあるクリストフ・マジオで、彼らがプロジェクトを立ち上げました。
まだオープンソースですらありませんでした。彼らは学校を説得してオープンソースにするまでに約3年を費やしました。学生のIPと著作権が絡んでいたため、大学側はこのMPEG-2デコーダーを何らかの形で収益化しようと考えていたからです。
明確にしておきたいのですが、主なアプリケーションはローカルネットワーク上でのストリーミングだったのですね。
はい、ローカルネットワーク上でのストリーミングです。
当たり前のことですが、これはYouTube以前の話ですよね。
YouTubeの10年前です。Pentium 60や75の時代です。メインの機種は33MHzの486DXでした。
忘れてはならないのは、当時の動画の主な形態はテレビだったということです。新しいチャンネルが見られるのです。90年代、4つのチャンネルで育った人々にとって、5つ目や6つ目の新しいチャンネルが見られるというのは大きな出来事でした。ですから、数十、さらには数百のチャンネルがあるこの衛星サービスを持つことは、非常に画期的なことだったのです。
特に、これは様々な国籍の人が集まる大学だったからです。そのため、結果的に彼らは異なる種類の衛星に向けたいくつかのパラボラアンテナを持つことになりました。例えば、マグレブ地域や中東から来た人がたくさんいて、異なる種類の衛星を見たいと望んだからです。
ともかく、このソリューションは非常にうまく機能し、彼らはVideoLANプロジェクトを開始しました。VideoLANプロジェクトにはいくつか完全に狂気じみたソリューションもありました。ユニキャストネットワーク上でどうやってマルチキャストを作成するかなどですが、複雑すぎるのでここでは触れません。
VideoLANのクライアント部分がVLCになったのです。実のところ、彼らは大学を強引に説得してオープンソース化させました。大学側はそれを理解していなかったからです。2001年、まだ初期のことです。基本的には、大学は2001年初頭にオープンソース化に同意しました。私は2003年にこのプロジェクトに参加しました。私が大学に入学した年です。
ですから、まずお伝えしたいのは、VLCを作ったのは私ではないということです。実際のところ、誰かが一人で作ったわけではありません。
VideoLANプロジェクトから自然発生的に生まれたのですね。再度明確にしておきますが、VideoLANは当時、動画に関する技術の集合体であり、あなたがクライアントと呼んだVLCこそが、一般の人々が「そのもの」として認識しているもの、つまり動画をクリックした時にポップアップして再生するあのプレイヤーのことなのですね。
私が2003年に参加した後、VideoLANというオープンソースの非営利組織を設立しました。大学からすべてを切り離し、非営利プロジェクトとして持続可能なものを作りました。私が誰よりもVLCとVideoLANに時間を費やしてきたというのは事実です。間違いありません。
しかし、それは学生のプロジェクトであった以前のVideoLANプロジェクトの連続であり、それはNetwork 2000プロジェクトの連続であり、さらにそれ以前のものの連続なのです。
その道のりの途中で、オープンソースの観点からこれが将来どうなるのかと考えた瞬間があったに違いありません。インターネットが爆発的に普及し、莫大な利益を上げる企業が出てきたわけですから。覚えていない人のために言いますが、大金を生み出している企業がたくさんありました。
お話ししますが、2005年、このプロジェクトは死にかけていました。そして私がプロジェクトを存続させました。ある時点で、アクティブな開発者は私たち2人だけになっていました。私はこれが素晴らしい技術であり、役立つものだと信じていたので、自分の人生と時間をそれに捧げたのです。数十万人のユーザーから数百万人のユーザーへと成長させ、現在では世界中で数十億のVLCが使われるまでに至りました。それがVLCの物語の概要です。
その過程には、シリアやインドの何もない田舎など、世界中の多くの人々が関わった非常に面白いエピソードがたくさんあります。
その道のりの中で、私はいくつかの買収オファーを受けました。あの恐ろしいツールバー（実質的にスパイウェアでした）をバンドルしないかとか、ウェブブラウザや検索エンジンを変更しないかとか、あるいはVLCの中に広告を入れないか、といったものでした。
私はそれが嫌だったのです。人々は理解してくれませんが、私はお金が嫌いなわけではありません。お金を稼ぐのは大歓迎です。いくつかスタートアップも立ち上げましたし、今やっている1つは非常にうまくいくと期待しています。ただ、私は倫理的にお金を稼ぐ必要があると信じているのです。正しい方法があり、こっそり広告を入れたりデータを盗んだりするのは正しい方法ではありません。
例えば、もしNetflixが「VLCの中にNetflixを入れたい」と言ってきたら、おそらく話は違っていたでしょう。しかし、彼らは来ませんでした。私たちのところに来たのは怪しげな広告会社だけでした。
もしそれを受け入れていたら、私は大金を手に入れていたでしょう。しかし3年後、プロジェクトは消滅していたはずです。誰かがフォークして、全く別のものになっていたでしょう。
つまり、必ずしも広告そのものが問題なのではなく、彼らの不誠実さや怪しさが問題だったのですね。「いや、これはこれが表すべき精神を損なうものだ」と見抜く素晴らしいレーダー、素晴らしい基準を持っていたわけですね。
自分自身のためでもあります。私は利己的に、夜ベッドに入った時、自分のやったことに満足して眠りにつきたいのです。育ちのせいかもしれませんし、親の責任かもしれませんが、私は正しいことと間違っていることがあると信じています。そして当時、それは正しい決断でしたし、今でもそうです。私は自分のやってきたことを誇りに思いたいのです。もし私が身売りしていたら、ここで働いてくれている他の多くの人々を裏切ることになっていたでしょう。
私からも、そしてインターネット上の多くの人々からも、その決断に感謝します。自分が正しいと信じることのために、このような大きな犠牲を払ってもいいのだと、オープンソース運動を推進している他の人々にとってインスピレーションになります。そのケースにおいてそれは正しい決断でしたし、VLCが成功した理由でもあります。なぜならVLCは、オープンソースコミュニティが生み出せる自由や可能性の象徴であり、体現だからです。
ええ、そして世界中の多くの人々への奉仕となることです。これが重要です。
2000年代当時、プログラムをダウンロードすると密かにスパイウェアがインストールされるのがごく普通だったことを強調しておくべきです。誰も読まないライセンスのテキストボックスの底や、非常に薄い文字で「このツールバーをインストールし、これらの設定を変更します」と埋もれるように書かれていました。当時、何らかのプログラムをインストールする際に、そうしたことが起こるのは非常に一般的なことでした。
当時の開発者の立場になってみてください。これを聴いている皆さんにとっては、数千ドルを受け取ってそれを行うように自分を納得させるのは、当時は非常に簡単だったと思います。それよりもはるかに大金を断るには、勇気とビジョンが必要です。
最後のオファーは法外な額でした。彼らはこう言いました。「考えてもみてください。そのお金があれば、何か新しいオープンソースのプロジェクトを作れますよ」。その心理的なトリックは厄介でした。しかし私にとっては、「いや、そういう仕組みではない。これは正しいことではないから、やらない」というものでした。繰り返しますが、私がお金が嫌いなわけではありません。ただ、それが正しくなかったのです。
改めて、私とインターネット全体を代表して感謝します。
セキュリティ研究者とオープンソースの軋轢
オープンソース運動についてもう少し話しましょう。あなたが何度も強調しているように、FFmpegや多くのオープンソースプロジェクトはボランティアによって構築されています。最近、インターネット上で、Twitterでちょっとした騒動がありましたね。
キーラン、あなたはTwitterで少し辛口なスタイルをとっていて、一部のコーデックや素晴らしいテクノロジーを構築する際に関わる素晴らしい開発者たちの開発やコード、特にアセンブリ言語を明確に称賛しています。
それが、Googleのセキュリティエンジニアとの間で起きたちょっとした騒動に繋がりました。何が起きたのか、事の顛末を教えてください。
念のため明確にしておきますが、Googleはオープンソースの最大の支援者の一つです。昔からずっとそうです。ただ、今回は少し行き過ぎた部分があったのだと思います。
FFmpeg自体は、秘密でもなんでもなくホームページに書かれているように、信頼できないデータを処理します。信頼できないデータをパースする際にセキュリティ上の問題が発生する可能性があり、それは非常に普通のことです。しかし最近何が変わったかというと、GoogleがAIを使ってオープンソースプロジェクトであるFFmpegのセキュリティレポートを作成し始めたのです。
ボランティアがそれに対処しなければなりませんでした。彼らは資金提供をほとんど行わず、問題が修正される前に、自分たちのAIがいかに優れているかをメディアに真っ先に発表しました。
公開フォーラムでですね。
ええ、すべて公開されています。
つまり、セキュリティの脆弱性であるコードの問題をAIを使って見つけ出し、あなたが修正する前にそれを公に報告したということですね。
ええ。彼らのAIがいかに優れているかを発表し、ボランティア主導の開発の性質をまったく理解せずに、業界標準の90日間の期限を突きつけてきたのです。さらに、この脆弱性は90年代の無名なゲームのコーデックに関するものでした。
彼らの立場から見てみましょう。彼らのケースを教えてもらえますか。
もちろん。彼らはどこにでも存在するオープンソースプロジェクトのセキュリティに取り組むために多大なリソースを投入しています。それを行うために大量の計算リソースを使用し、非常に高価で非常に有能なセキュリティ研究者を抱えています。彼らの視点では、それを行うことで貢献しているのです。
しかし、そこで意見が分かれるのだと思います。これがいくつかの興味深い亀裂を生じさせたと言えるでしょう。
セキュリティコミュニティの一部には、自分たちを現場に一度も行かなくていい建築家のように見なしている人たちがいるようです。現場に行くことは彼らにとって少し見下すべきことであり、日々の実際の構築作業は他の誰かの問題だというわけです。
また、セキュリティ業界には物事に対して非常に攻撃的なトーンをとる傾向があります。彼らが使う言葉は極めて攻撃的で、「あなたはポップされる（乗っ取られる）」といった強い言葉を使います。一般の人にとって「ポップされる」というのは何かかなり悪いことを意味しますが、彼らにとってはハッキングされるという意味です。
私が個人的にこれをどう見るかというと、家の南京錠のようなものです。家の南京錠や鍵は、それが守るべきものに見合った能力で保護するために存在しています。国家の核の秘密を守るためではありません。フォートノックスの金塊を守るためではありません。
彼らは大規模にAIを使い、それらの鍵をこじ開けに行き、「ほら、あなたの鍵は安全じゃない。これに対処しなければならない」と言っているように見えます。実際には、彼らこそがこれを修正するリソースを持っているのに、パッチでの貢献や資金的な貢献は彼らが行うことではないようです。そしてAIの規模が問題なのです。
バグレポートは非常に長たらしく、それはもはや、非常にニッチなコーデックに対するAI生成のバグレポートによるサービス拒否攻撃（DoS）に近いものです。
セキュリティコミュニティのもう一つの問題は、すべてが「高優先度」とマークされることです。「これは世界で最も重要なことであり、対処しなければならない。高い、高い、高い、脆弱だ、怖い、怖い、怖い」と。1993年の1枚のディスクで使われたゲームのコーデックに対してですよ。
そこに二面性があるのです。みんなの南京錠が安全じゃないと言いふらすこと、それは誰かの趣味のプロジェクトなのです。そのコーデックの安全性は、その人がどう考えるかという程度のものでしかありません。それは彼らの趣味です。セキュリティ分析をしてくれるのは良いことですが、「これは致命的な脆弱性だ」と大きな警告を出す必要はありません。
最近ではGoogleではありませんでしたが、フィルターがオーバーフローして整数のオーバーフローが発生し、1つのピクセルの色が間違ってしまう可能性があるという、いわゆる「脆弱性」もありました。そしてこれは赤字で深刻度7.5、高優先度とマークされました。
セキュリティ業界は、このように「オオカミが来た」と叫び続けることはできないと、ある時点で気づく必要があります。なぜならこれは、PCにパスワードのステッカーを貼るのと同じような結果を招くだけだからです。毎日毎日「オオカミが来た」と叫び続けることはできません。恐怖を煽ることが彼らのやり方であることは理解していますが。
Googleの立場から言えば、最終的にはパッチか資金のどちらかで貢献する必要があります。Googleはあなたや私が想像もできないような規模、数百万のCPUコアでFFmpegを使用しています。ええ、彼らはVP9やAV1といった自社製品に関する分野には貢献しています。しかし広い意味では、不釣り合いなレベルの貢献しかありません。学生に資金を提供したり、Summer of Codeに資金を提供したりはしていますが。
元FFmpeg開発者のアレックス・ストレンジが、個人の立場でHacker Newsにセキュリティエンジニアについて投稿していました。
「セキュリティレポート全般の問題は、セキュリティ関係者が自分の宣伝ばかりすることだ。（リーナスはかつて彼らをさらにひどい言葉で呼んだ）。自分が謙虚なボランティアのオープンソース開発者だと想像してみてほしい。もしセキュリティ研究者があなたのコードにバグを見つけたら、彼らはそれに可愛い名前を付け、ロゴ付きのウェブサイトを立ち上げるだろう。Googleは彼らに100万ドルの報奨金を与える。彼らはDEF CONに行って賞をもらい、そして皆がマトリックスのような服を着た秘密のセキュリティ関係者の乱交パーティーにでも行くのだろう。あなたがバグを修正したところで、誰もそんなことはしてくれない」。
関わっている様々な人々のインセンティブがずれていることを指摘していますね。
ここでの問題は、パッチを当てることに比べて、発見することへの手段の不均衡です。これが最大の問題です。あの騒動の後、Googleはいくつかの変更を行いました。
彼らはパッチを送り始めましたね。
そして問題の修正に対する報酬ツールも用意しました。あの騒動のおかげで状況は少し変わりました。それは良いことです。Googleについて話しましたが、私たちの製品において致命的だからこのバグを直せ、と言ってくる他の大企業も見てきました。
XZの騒動について説明してもらえますか。FFmpegのツイートはこうです。
「XZの騒動は、無給のボランティアへの依存がいかに大きな問題を引き起こすかを示した。1兆ドル規模の企業がボランティアに無償で緊急のサポートを期待している。Microsoft Teamsはボランティアだらけのバグトラッカーに、自分たちの問題は優先度が高いと投稿した。
長期的なメンテナンスのためのサポート契約を丁寧にMicrosoftに要求したところ、代わりに数千ドルの1回限りの支払いを申し出てきた。これは受け入れられない。これは作り話ではない。これがMicrosoft Teamsが実際にやったことだ」。
そして画像と詳細を示し、これらの兆ドル規模の企業が十分なお金もサポートも提供していないことを示しました。
彼らはオープンソースプロジェクトを、SLA（サービスレベル契約）を結んでいる従来のベンダーだと考えているのです。公開されたバグトラッカーを、あらゆる要求ができるサードパーティベンダーのJiraだと思っています。そうではありません。そこはバグを報告するための場所です。
これを特にひどいものにしたのは、Microsoftの名前を出したこと、これが目に見える製品であるという名前を出したことだと思います。もしこれが一般的なバグレポートだったら、ずっとマシだったでしょう。
ええ、彼らは文字通り「Microsoftで多くの人が使っているから大問題だ」と言ったのですね。これらの企業で心理的に何が起きているのか不思議に思います。あなたが言うように、彼らはFFmpegをMicrosoftが巨額のお金を払っているベンダーのように考えていて、スタックのどこにいる誰も「ちょっと待って、私たちはFFmpegに何百万ドルも支払うべきではないのか」と考えないのでしょうか。
これは大企業において非常に大きな問題です。いくつかの企業について話していますが、どこでも同じです。その担当者と話した時、彼はMicrosoft Teamsの一つのプロジェクトのマネージャーに過ぎませんでした。彼はオープンソースコミュニティと議論したことがなく、何も理解していませんでした。
問題は、大企業には通常OSPO（オープンソース・プログラム・オフィス）と呼ばれる部門があり、彼らがオープンソースベンダーと議論することになっているのに、社内でそれを適切に説明していないことが多いということです。
私たちはあなたのサプライヤーではありません。もしサプライヤーになってほしいなら喜んで引き受けます。契約書とSLAを送ります。私はオープンソースプロジェクトを中心にそういったことを行う会社を5つ作りましたから、それは構いません。
キーラン、あなたの辛口なツイートやその騒動が、結果を生み出したとも言っておくべきでしょうね。
はい。
ポジティブな結果を。
寄付は大幅に増加しました。フルタイムの開発者一人をカバーするにはまだ十分ではありませんが、認識レベルでも技術レベルでも、Xや起きたことの結果として、FFmpegの重要性に対する認識が大幅に高まりました。目的は果たしたと言えます。人々はFFmpegの重要性のレベルを理解しました。
VideoLANでも同じです。ごく簡単な例を挙げましょう。AndroidのPlayストアのバグのせいで、1年以上VLCをAndroidでアップデートできませんでした。返事をもらう唯一の方法は、あなたが言うような非常に辛口なツイートをして「Android向けVLCの配布を停止する」と言うことでした。私たちには約1億人のユーザーがいます。そうして初めて、Androidの担当者が来て話し合いに応じたのです。
Microsoftとも同じ問題があり、WindowsストアでのVLCの配布を停止すると言わなければなりませんでした。残念ながら私たちは非常に小さいので、そうした問題を解決するために私たちが持っている唯一の強力な手段は、ソーシャルネットワーク上で非難することなのです。それが雪だるま式に大きくなり、彼らはようやく耳を貸すようになります。大企業はしばしば私たちと話すのが難しいようです。
例えばVLCは、Windowsで使用されているソフトウェアのトップ10に入るでしょう。しかし私はMicrosoftのISVプログラムに参加していません。Microsoftに窓口がないのです。AdobeやSpotifyのような他のソフトウェアには間違いなく窓口があるはずですが、私にはありません。だから意識を高めることは効果があるのです。時に非常に辛口で、多くのドラマを生みますが。XやTwitterはその目的には適していて、効率的です。
ですから、これを聴いている皆さんは、TwitterやXでFFmpegをフォローし、VideoLANをフォローしてください。そしてFFmpegに寄付をしてください。
ありがとう、レックス。何年にもわたって、あなたはXでFFmpegとVideoLANを支持してくれました。感謝の言葉を述べ、私たちの活動を評価してくれました。
FFmpegは一生ものです。
それにティム・スウィーニーやジョン・カーマックなど、非常にハイレベルな人たちも私たちのXアカウントで認知度を高めてくれて、それも大いに助けになりました。
カルパシーもですね。
はい、カルパシーもです。
ええ。多くの人が使っていて世界に大きな影響を与えているという事実以外にも、優れたオープンソースプロジェクトの素晴らしい見本でもあります。アセンブリとCの価値や、現実世界の大規模システムのためにプログラミングを真剣に受け止めることなど。
それだけではありません。（アセンブリについては後で話しますが、それ自体が大きなトピックです）メンテナンスを行っているアンドレアス・ラインハルトのような人々を称賛することでもあります。彼はおそらく無給のボランティアとして、大規模なリファクタリングを行っています。アンドレアス・ラインハルトや、ffmpeg.cをスレッド化で書き直しているアントン・キルノフなどです。
彼らを称賛し、これに注がれた語られない労力を称賛することです。なぜなら、ユーザーの観点からは何も変わらないからです。ファイルは全く同じです。しかし、驚くべきことに、飛行機が空を飛んでいる間に作り直されたようなものなのです。
クリスチャン・ガルシアが「このアカウントを運営しているティーンエイジャーとして」と言及し、あなたは「Googleのエンジニアよりも、ティーンエイジャーの方がFFmpegで多くのアセンブリを書いている」と返信しました。ティーンエイジャーの素晴らしい貢献者がたくさんいることを指摘したのですね。
JBが言ったように、私たちはあなたが誰で、どこから来て、何をしているかは気にしません。これまで何年にもわたって、ティーンエイジャーがFFmpegで何千行ものアセンブリを書いてきました。昔のダニエル・カンに敬意を表します。ルイカイ・ペンのような若者の仕事も強調したいです。彼は16歳でFFmpegへの最初の貢献のいくつかを果たし、いわゆるセキュリティ研究者たちを恥じ入らせるような活躍をしました。実際に問題を見つけて修正したのが16歳だったのです。
障壁はありません。「この人の下で大学で勉強して、これらを理解しなければならない」といった障壁はありません。C言語を学べばいいのです。正直に言って、K&Rの本からC言語を学び、アセンブリを学べば、世界クラスのテクノロジーに貢献できるのです。
VLCで最も古い貢献者の一人であるフェリックスは、MacとiOSのすべてを担当しています。彼がVLCの作業を始めたのは16歳の時でした。Google Summer of Codeの学生で、VideoLANに3年間残ったエドワード・ウォンという人物は14歳でした。学生や高校生がx264やVLC、FFmpegのために大量のアセンブリを書くGoogle Summer of CodeやGoogle Code-inのようなプログラムもありました。誰でも貢献できるのです。
そして彼（ルイカイ・ペン）は素晴らしい仕事もしました。セキュリティのドラマを演じたり、CVEを作成してセキュリティを公に暴露し、赤字で「7.5の高優先度」と脅かしたりしなかったからです。彼はただ3日後にGitで問題を修正しました。大げさなセキュリティのドラマを演じる必要はなかったのです。そして私は「若者たちは大丈夫だ」と投稿したと思います。
すべてとは言いませんが、アレックスが言ったように、セキュリティコミュニティの一部には、ドラマを作ることで自分たちを誇大宣伝したがる人たちがいます。彼らは喜んで「これは高優先度のCVE 8.0だ」と騒ぎ立てるでしょう。実際にはそれはリリース版ではなく開発中のGit上の問題であり、3日後には修正されたにもかかわらずです。
Googleのエンジニアたちにも少し愛と敬意を示しておきたいです。あなたが言ったように、彼らは世界最高のソフトウェアエンジニアの一部であり、セキュリティの面でも多くの貢献をしています。そして私はテオの大ファンでもあります。テオには多くの愛を。彼はこの騒動とドラマに少し関わっていました。人類の歴史の壮大な流れの中で俯瞰してみると、このドラマは関わったすべての人にプラスの貢献をしたと思います。寄付は増えましたし、トピックへの関心が高まり、誰もが言い争いながらも、最終的にFFmpegとは何かを理解するに至りました。
私たちはこれをラップバトルのようなものだと考えています。
ええ、実際そうです。お互いに言いたいことを言い合いますが、
Xは国際的なラップバトルに最適な場所です。私があなたの母親について何か言ったからといって、実際に彼女に個人的な恨みがあるわけではありません。
そのようなものです。テオの状況は、JBが詳しく話せるかもしれませんが、少し行き過ぎた部分がありました。しかし、単なる楽しみです。ラップバトルです。WWEです。誰もがXで楽しんでいるだけで、深刻に受け止める必要はありません。
ティーンエイジャーの件は、Googleの従業員が「オープンソースビジネスを運営する方法は他にもある」と言ったのに対して、「ああ、少し楽しませてくれよ」と返しただけです。それがこのアカウントの目的です。さらに、そうすることでオープンソースプロジェクトのやり方やアセンブリなどを人々に教えることができるなら、提供できるものはたくさんあると思います。
単に非難するためではなく、Xが学んだ物語は、これらが大企業によるオープンソースプロジェクトではないということだと思います。何百人、何千人もの人々が開発のために給料をもらっているKubernetesではありません。地下室で空き時間にやっている普通の人々であり、そのトピックを楽しくエンターテインメント性のある方法で取り上げることができれば、それがXの価値であり、私たちが持つリーチの価値だと思います。
正直なところ、Googleは一つの事業体ですが、様々な人々がいます。私たちが常に一緒に仕事をしているGoogleのエンジニアもたくさんいますし、YouTubeからChrome、Chrome Media、そしてGoogleのその他の部門まで、これらは非常に異なる種類の事業体です。しかし、私たちがやっていることは効率的です。
例えばテオについては、少し行き過ぎました。私は全員を落ち着かせ、彼と電話で話し「よし、これは行き過ぎだ」と伝えました。結果として、ええ、ラップバトルでしたが、プロジェクトにはプラスになりました。オープンソースに対する認識、つまりコミュニティからの真のオープンソースに対する認識はここ2年で劇的に高まりました。それは有用なことです。
これまで話してきた素晴らしい貢献者たちを突き動かしているものは何だと思いますか。原動力は何でしょうか。それを見るのはとても興味深いです。地下室に座って、何が彼らを駆り立てているのでしょうか。
多くの原動力がありますが、奇妙なことに最も大きな理由は、私たちがマルチメディアで行っていること、つまり動画を再生することがクールだということです。例えば、アニメを見るのが好きだったからコミュニティに参加したという人がたくさんいます。
「オープンソースで何に取り組むべきか、どう始めればいいか」と聞かれた時、私の答えはいつも同じです。自分の愛するものに取り組みなさい。
私がVLCに取り組んでいるのは映画が好きだからです。同じ映画を何度も見るのが好きで、妻には嫌がられますが、それは面白いからです。自分が好きなトピックだからです。それが人々がVLCやFFmpegにやってくる最初の理由です。
2つ目の理由は、私たちが技術的に卓越性を追求しているため、ここが史上最高の学校になるということです。プログラミングの最高の学校です。もしあなたがC言語に長けていて、FFmpegでアセンブリの書き方を知っているなら、たとえTypeScriptを書く仕事をしていても、間違いなく史上最高のプログラマーの一人になれると保証します。なぜなら、これはやるべきこととして最も素晴らしいことだからです。
そして、あなたのコードのあらゆる部分を見て、なぜそれが素晴らしくないのかを教えてくれる、経験豊富なプログラマーたちからレビューを受けることになります。私たちは、あなたがこれまでに出会った中で最高のプログラミングの教師のようなものです。
Zigという言語を開発したアンドリュー・ケリーも、FFmpegの開発者であり、FFmpegという学校を卒業した後にZigを始めました。つまり、数十億人に使われている現実世界のものを通じて、プログラミングの非常に多くの側面を学ぶことができる場所なのです。隠れる場所はありません。自分の欠点と、どうすれば学び、より良くなれるかについてオープンで正直でなければなりません。
マルチメディアにおいて興味深いもう一つの点は、フレームを表示するのに16ミリ秒しか与えられていないことです。速度を落としてフレームを待つことができるゲームエンジンとは違います。だから優秀でなければならないのです。他に選択肢はなく、さもなければ動画は再生されません。コーデックの性質上、フレームを一つ逃せば動画の見た目は崩壊します。だからこそ、正しい結果を得るためには完璧でなければならないのです。
しかし同時に、これは純粋に数学的な意味でのプログラミングだけではないということです。多くの人が理解していませんが、オープンソースのマルチメディアコミュニティで正しくプログラミングを行うには、コンピュータがどのように機能するかを理解する必要があります。
アセンブリを書く時は、CPUのパイプライン処理について理解する必要があります。SIMDがどのように機能するか、ALUがどのように機能するかを理解しなければなりません。I/Oがどのように機能するかを理解しなければなりません。これが、今日の多くのエンジニアやソフトウェアエンジニアに欠けていることだと思います。コンピュータアーキテクチャと呼ばれるものを理解することです。
真面目な話、議論のいくつかは「このアセンブリ命令を使うべきか、それともこっちか」といったものです。人々は「いや、このCPUではこっちなら3サイクルになる」と言い合い、それが結果に多大な影響を与えます。
強調しておくべきですが、FFmpegはおそらく世界最大のCPUユーザーの一つです。私たちが話している今この瞬間も、簡単に1億、いや10億オーダーのCPUで実行されているでしょう。だからすべての命令が重要なのです。私たちがやっていることすべてにおいて、少なくともCPUへの影響は甚大です。
ですから、まず面白いテーマだからやって来て、それが卓越したものだから留まり、最終的にはそれがみんなの手の中にあるからこそ非常に誇りに思うのです。例えば「どこかのコンサルティング会社で働いていて、PG&E（電力会社）の請求書をダウンロードするポータルを作っている」という人がたくさんいます。素晴らしい仕事ですが、それをおばあちゃんに自慢することはないでしょう。
でも、おばあちゃんのところに行って「おばあちゃんがノートパソコンで動画を見られるように、これを作っているんだ」と言えば、理解してもらえます。これは非常に重要なことです。VLC、FFmpeg、H.264に取り組むということは、何億人もの人々の手に渡り、影響力を持つということです。だから自分を誇りに思うことができるのです。素晴らしい履歴書を作ることに加えて、こういったことが人々が貢献する理由だと思います。
ええ、それらは副作用ですね。このトピックに関して私のお気に入りの言葉があります。ジョン・コリソンが言った「世界は情熱プロジェクトの博物館だ」という言葉です。世の中にあるものはすべて情熱プロジェクトなのです。
そしてオープンソースのマルチメディア、あるいはオープンソース全般において、それをはるかに速く行うことができます。強力なネットワーク効果があります。私がカフェを開くのが情熱プロジェクトだとしたら、建築基準法をクリアし、建物を建て、場所を見つけ、あらゆることをしなければなりません。
しかしソフトウェアの世界では、その情熱プロジェクトは素早く動き、ネットワーク効果によって増幅され、その増幅は個々の部分の合計以上になります。極めてマイナーなことに興味を持つ人々を見つけ、ネットワーク効果を生み出し、本当に素晴らしいものを作ることができるのです。
情熱プロジェクトという話題に関連して、ティム・スウィーニーがJBを称賛するツイートへの返信で言った言葉があります。「世界中の多くの素晴らしい出来事は、素晴らしい人物がそれをやろうと決心したからこそ起こる。VLCの場合もそうだ」。
これは非常に興味深い点を示唆しています。ソフトウェアの世界では、少数の人々、時にはたった一人が、信じられないようなものを作り出すことができるように思えます。あなたは何度もそう言ってきました。JavaScriptは、最初は一人の人間によって作られた素晴らしいものです。Python、C、Javaといったプログラミング言語のいくつかも、一人の人間がビジョンとデザインを持ち、時には週末の間に最初の火花を散らすことから始まります。
ええ、リーナスはGitを2週間で作りました。
世界を変えましたよね、Gitは。本当に世界を変えました。
リーナスの情熱プロジェクトです。「FTPにこのtarballをアップロードするから、あとは好きにしてくれ」と。
しかし、これはソフトウェアに限った話ではないと私は思っています。私は、世界を変えるような個人を信じています。あなたが言ったように、良いビジョンを持って「これをやりたい。これは役に立つ。役に立つようになる」と信じることです。それが電車であれ、車であれ、ロケットであれ、自分自身を信じ、ビジョンを持つ人々が、人類に多大な影響を与えられると信じています。
バイナリ星系：FFmpegとVLCの共存関係
もう少し深く掘り下げる前に、一度視点を広げてみましょう。これまでVLCとFFmpegについて行ったり来たりしながら話してきました。キーラン、あなたはFFmpegとVideoLAN/VLCは共存しており、中心となる重要なポイントはないと言いましたね。それらを「バイナリ星系（連星系）」と呼んでいました。互いが存在することで成功していると。両者の違いや関わり方を説明してもらえますか。競合相手なのでしょうか。
競合相手ではないと思います。詳細に入る前に簡単に言うと、Linuxに対するAndroidのような関係が、FFmpegに対するVLCだと言えます。互いに依存しつつ、互いの存在によって共存しています。だから私が使った例えは連星系なのです。
ちなみに、最近になって私たちに最も近い星系であるアルファ・ケンタウリが実は三重星系だと知って、ひどくショックを受けました。
物理計算を始めると悪夢になりますからね。
だから三体問題なんですね。ともかく。
FFmpegのパイプラインの多くは、VideoLANのプロジェクトであるx264プロジェクトに関与しています。直感ですが、パイプラインの80パーセント以上がVideoLANのプロジェクトに依存していると思います。そしてVLCは明らかにVideoLANのプロジェクトであり、FFmpegを使用することでリーチを広げ、奇妙なファイルに触れる機会を得てきました。歴史的には寄付金の一部を使ってFFmpegの開発に資金提供したりもしました（リバースエンジニアリングについて後で話すかもしれません）。
つまり、これは連星系なのです。互いに協力し、刺激し合っています。開発者の多くは共通しています。中心となる場所はなく、一緒に機能する好循環なのです。
x264はH.264ビデオ規格のためのエンコーダであると言及しておくべきですね。H.264が規格です。
そしてx264は、誰もがすべてのことに使っている、その規格のオープンソース実装です。これが主要な原動力です。H.264コーデックが含まれるMP4ファイルを見た時、
それがデータセンターなどのソフトウェア環境で作られたものなら、おそらくx264で作られた可能性が高いです。
そしてそれはVideoLANの旗の下にあるのですね。
VideoLANプロジェクトです。VideoLANのグラフィックの中では、VideoLANの世界に位置しています。
VideoLANのウェブサイトに行くと、アイコンがたくさんありますね。
ええ、本当に多くのライブラリがあります。libdvdcss、libdvdnav、libdvdpsi、もちろんlibvlc、vlc-unity、libbluray。他にもまだまだたくさんあります。
最近では、後で話すかもしれませんが、dav1dというプロジェクトがVideoLANからの最新のプロジェクトです。どこででも使われています。また、最近発表したlibspatialaudioや、checkasmというのもあります。これは狂気じみていると同時に素晴らしいプロジェクトです。x264はそうしたVideoLANプロジェクトの一つです。
私の意見では、例えばx264はこれまでに設計された中で最も驚異的なエンコーダであり、これがFFmpegの普及を後押ししました。多くの人々や大企業がx264を使いたくてFFmpegを利用し、x264がFFmpegの人気を高めました。
しかし同時に、VLCもFFmpegによって作られた非常に多くのファイルを再生できたことで人気を得ました。つまり、多くのプロジェクトが絡み合い、一緒に機能しているのです。
ええ。残念なことに、XでVLCが話題になると「実際に裏で仕事をしているのはFFmpegだということを手短にリマインダー」と言う人がいます。しかし私が言ったように、それは事実ではありません。私たちは一緒に働いているのです。
イメージしやすく言うと、私がWindows用にVLCをコンパイルする時、約1600万行のコードをコンパイルします。そのうちVLCのリポジトリ内にあるのは100万行で、FFmpeg全体でおそらく200万行くらいです。つまり、非常に多くの依存関係が外部にあるということです。
そしてFFmpeg自体を見ても、x264やLibOpusなど、サードパーティのライブラリを統合しています。ですから、私たちは皆、互いに依存し合っているのです。
ええ、だからこそ今回のように、FFmpegとVLCの両方を繋ぐようなエピソードにしたかったのです。本当に同じものの二面であり、連星系であり、私たちは皆その周りを回っているだけですから。
開発に携わった一部の人々にスポットライトを当てることはできますか。FFmpegの歴史についてはあまり話していませんね。ファブリスについて、マイケル・ニーダーマイヤーについて、あるいは主要な人物について教えてもらえますか。
FFmpegの各時代について話しましょう。これを可能にした重要な時代と重要な人々がいます。ファブリス・ベラールが言及されたようにそのコンセプトを作り出し、おそらく2000年代はFFmpegの時代（エラ・ツアー）と呼べるでしょう。2000年代はマイケル・ニーダーマイヤーの時代でした。
彼が成し遂げた重要なことは、当時のDivXとXvid、そしてMPEG-4 Part 2として知られるもののあらゆる種類の奇妙な亜種に対する徹底的なサポートでした。これは私たちがよく知っているMPEG-4 Part 10より前のものです。ですから、これは2000年代のビデオコーデックであり、数え切れないほどの奇妙なデコーダーが存在していました。
2000年代当時、異なる種類のファイルフォーマットを再生するたびに新しいプレイヤーが必要でした。Windows Mediaフォーマットを再生するためのWindows Media Player、RealMediaフォーマットを再生するためのRealPlayerなどがありました。当時のFFmpegにおけるもう一つの重要な機能は、それらのネイティブデコーダーでした。私も10代の頃だったと思いますが、別の肥大化したプレイヤーを持たなくても、これらのファイルをデコードできるプレイヤーがあることに気づいたのを覚えています。当時RealPlayerをダウンロードすると、他の不要なものが大量に入っていて、広告やスパイウェアもたくさんありましたが、高速でシンプルなライブラリがあるだけでそれが可能になりました。
そして2008年以降、H.264が成熟期を迎え、大きな変化が起きました。これが高解像度（HD）動画の始まりでした。H.264はそれの主要なデコーダーでした。それを2000年代後半から2010年代と呼ぶとすれば、その時に偉大なリバースエンジニアたちが登場し、本当に驚くべき仕事をしました。最初から、Xvid、DivX、Windows Media、RealPlayerを再生できる単一のプレイヤーがあったこと自体、怪しい広告やスパイウェア付きのコーデックパックをダウンロードすることなくそれを可能にした、大きな成果でした。
VLC 1.0が出たのはその頃、2009年か2010年ですね。そしてそこで爆発的に普及しました。
ええ、コーデックパックなしで、これらすべての異なるフォーマットでただ機能する。
事実上、すべてのコーデックパックはVLC内部のFFmpegにあり、さらにすべての種類のコーデック用の他のモジュールも持っています。
当時は違いました。2000年代には、あちこちから持ってきたDLLが入った怪しいコーデックパックがあり、スパイウェアや得体の知れないものが含まれていました。信頼性がなく、何が入っているかわからない状態でした。だから、オープンソースの単一のプレイヤー、または単一の再生モジュールがそれを可能にしたのは素晴らしいことでした。
強調しておきたいのは、2000年代にマイケルが行ったこの作業はシーシュポスの神話のような徒労にも似た、果てしないものだったということです。エッジケースの数は想像を絶するものでした。例えば、中国のCCTVシステムがMPEG-4 Part 2（MPEG-4 ASPと呼ばれるもの）の奇妙な亜種を使っていて、他のすべてを壊すことなくそれを修正しなければならない、それが100万回も繰り返されるようなものです。
リバースエンジニアリングの途方もない労力
そこで多くのリバースエンジニアリングが行われていたのですね。
2000年代にWindows Mediaの独自フォーマットから始まりました。RealMediaでも、ベンジャミン・ラーソンやコスチャ・シシュコフの時代に始まりました。それが重要な基礎作業でした。
そして2010年代は、ポール・マホルやコスチャの時代となり、最も難しいコーデックのいくつかに取り組みました。JBならGoToMeeting 4や5について話せるかもしれません。
何ですか？GoToMeetingとは。
このコスチャという素晴らしいウクライナ人について話しましょう。彼は当時ドイツに住んでいて、スウェーデンをこよなく愛していました。コミュニティの多くの人が非常に賢いように、彼も天才の域に達している人の一人でした。彼は極めて複雑なコーデックをリバースエンジニアリングすることができました。私たちもキーランと一緒に少しリバースエンジニアリングをやりますが、明らかにこのレベルではありません。
ええ、全く違います。
彼は20MBもあるバイナリの塊（ブロブ）をリバースエンジニアリングしたのです。
参考に言っておくと、1MBのバイナリブロブをリバースエンジニアリングするのにおそらく1ヶ月程度の作業が必要です。しかし彼は20MB、30MBのブロブをやっているのです。その微妙なやり方については後で話すかもしれませんが、彼は非常に難しく、非常にマイナーなコーデックでそれをやってのけました。
それも楽しみのためにやっていたのです。GoToMeetingは当時VLCにとって大きな問題でした。長い間、ナンバーワンの機能リクエストだったため、私は懸賞金（バウンティ）をかけました。
すると彼がある時、「OK、JB、私がやるよ」と言い出しました。そしてわずか2ヶ月でやり遂げ、その方法を説明してくれました。「コードを見てみたんだけど、WMVなどで見たことのあるDCT（離散コサイン変換）に似ていたんだ」と。さらに面白いことに、彼が書いたコードにはたくさんのジョークがちりばめられていました。JB（私）の名前や、ケンプとコスチャのジョークがコードの中にたくさん入っているのです。コードは美しかったですね。
一つコメントしておきたいのですが、私は開発者やアセンブリ言語レベルの人たちと話す機会がありましたが、彼らは皆、何でも簡単に聞こえるように話しますよね。彼らにはある種の謙虚さがあります。おそらく、これを行うために必要なレベルがあまりにも高いため、他のすべてが簡単に思えるのでしょう。それがそこから学べる教訓だと思います。
コミュニティの中で最も印象的なのは、リバースエンジニアリングを行う人々と、アセンブリを限界まで書く人々です。そのどちらも素晴らしい。例えばx264が素晴らしいものになったのは、ローレン・メリットという人物のおかげです。彼は当時ワシントン大学にいたと思いますが、大量のアセンブリを書いてすべてを高速化し、素晴らしいものにしました。
ええ、これが黄金時代だったのでしょう。非常に多くのことが成し遂げられました。
コスチャを見ると、彼は世界をバイナリの仕様書として見ていました。ドキュメントなど必要ありません。「バイナリがあるから、すべて解明できる」というわけです。彼は日常的に「バイナリ仕様書」という言葉を使っていました。「ああ、問題ないよ」と言って立ち去り、戻ってくると面白いことをやってのけるのです。
ブロブ（バイナリの塊）をリバースエンジニアリングする際の詳細や、どんな感じなのかを具体的に教えてもらえますか。
ええ。例えばGoToMeetingは良い例です。GoToMeetingで会議を録画したとして、このGoToMeetingプレイヤーなしでどうやって再生するのか？そもそもプレイヤーが存在しないかもしれません。会議の録画をプレイヤーを持っていない人に送る必要があるかもしれません。
まず第一に、そこには他の多くの要素が含まれています。実際のビデオ会議クライアントがあります。解凍を行っているモジュールを見つけるのは簡単かもしれないし、難しいかもしれません。
そして、そのモジュールからYUVデータを出力する方法を見つける必要があります。多くの場合、ディスアセンブラで開き、そのモジュールを組み込んでサンプルファイルをネイティブにデコードするためのフック（プログラムの実行を横取りする箇所）がどこにあるかを推測する必要があります。このモジュールがデコード処理を行っている場所を見つけ、フックして生のYUVデータを出力する方法を見つけるのです。実際にリバースエンジニアリングを行う際の比較対象としてそれが必要になるからです。ビットレベルで完全に一致するか、それに近い状態にする必要があります。
それからディスアセンブラを開き、多くの直感を使って、DCTがどこにあるか、エントロピーコーディングがどこにあるかを解明していきます。ルールブックのようなものはありませんが、常に何らかのパターンがあります。
例えばGoToMeetingの場合、画面コーデックツールが多く使われていることがわかります。バージョンによっても異なり、GoToMeeting 2、3、4などがありました。
ここでPerplexityで検索してみると、「GoToMeetingは古い録画セッション用に独自のプロプライエタリなコーデックを使用しており、歴史的にWindows上で適切に再生するには特別なデコーダーが必要なWMVファイルに保存されていました。このデコーダーがインストールされていないと、Windows Media Playerや一部のエディタはビデオトラックをデコードできず、音声だけが聞こえたり、黒い画面が表示されたりする可能性があります」とあります。いやあ、よく覚えていますよ。そしてこれをリバースエンジニアリングするわけですね。
これが鍵なのです。GoToMeetingは今ではもう多くの人が知らないものです。今はZoomやTeamsなどを知っていますが。しかし、これから10年後、15年後に「これはWindows 32ビット用のGoToMeeting.exeだ」となっても、「いや、私はAndroidを使っているし、iPadを使っている。RISC-VやArm環境だ」となったらどうやって再生するのでしょうか。それらはブロックされてしまいますが、未来のためにサポートが必要なファイルは山のようにあります。だからこそ、こうした作業は人類にとって極めて有用なのです。
しかし言わせてください。リバースエンジニアリングのプロセスは本当に驚異的です。クレイジーです。私が最近よく読んだりインタビューしたりしている、考古学者たちの仕事に似ています。手がかりとなるシグナルが非常に少ないのです。
ええ。経験を積むにつれて元のコードの構造を理解し、基本を推測し始めることはできます。しかし、小さなブラシで人類の文明全体を再構築しようとする考古学者のようなものです。
キーランは謙虚すぎますが、彼もリバースエンジニアリングを行っています。CineFormなどを手がけました。
ええ、当時その作業がオープンソース化につながりました。バイナリ側の作業と並行して、当然サンプルも必要です。多くの場合、サンプルは少ししかないので、様々な種類（フレーバー）が何であるかを解明しなければなりません。
例えばCineFormは、実際にはコーデック内で様々なアプローチやツールキットが組み合わされたものです。自然発生的に成長していくことが多いからです。難しいのは、10個もの異なるものを実装することなく、作業の出発点となるようなサンプルを見つけることです。そこから始めます。
当時は運良く、平坦なブロックがたくさんあるサンプルを見つけることができました。アニメーションだったので、特に複雑なコーディングツールなどを使用しておらず、ある程度理解を進めてから、「ああ、ここが少し違う」「この分岐処理を見落としていた」と段階的に構築していくのに非常に役立ちました。
サンプルというのはサンプル動画のことですね。サンプルを観察し、このコーデックが何をしているのかを推測しようと追跡するのですね。そして、機械語のレベルで…
「ああ、このバイトが6なら、この分岐に進むのか」と。そして別のサンプルでは「ああ、これは違う」と。
それはクレイジーですね。
ええ、クレイジーですよ。それがGoToMeetingのようなものになると、2桁も複雑さが増すのを想像してみてください。ドイツのどこかで一人の男がそれをやっているのです。
長い間、ブラックボックスの中で作業することになります。デコーダーには、エントロピー復号、イントラ予測、動き補償、逆DCTなど非常に多くのステップがあり、長い間何も視覚的な結果が見えません。つまり、純粋にメモリ内だけでデバッグしているのです。係数が保存されているバッファが完全に間違っているかもしれず、「これが原因だ」と完全に間違った方向へ進んでしまい、「ああ、違った、別のことだった」となることもあります。
そしてそれを、数千万の命令からなる数十メガバイトのバイナリに対して行うのですね。
デバッガーを使って、命令を一つ一つステップ実行しながら、「よし、この命令がこれを変更する。これはこれを行う」と確認していくわけです。
CPUレベルでプログラムを一時停止しながらですね。
ええ、CPUレベルで一時停止して、何が起きているかを観察し、解明しようとします。時にはVM（仮想マシン）内で行う必要もあります。VMを一時停止してメモリをダンプ（書き出し）するのです。コーデックが暗号化されていたり、DRMがかかっていたりする可能性があるためです。その場合、仮想マシンからメモリをダンプする必要があります。
私が2003年にエコール・セントラル・パリに入学した時、ヨン・レック・ヨハンセンがDVDの仕様を打ち破ってDeCSSを作り、AppleのMP4 FairPlayというDRMをどのように破ったかを見せてくれました。当時21歳だった彼が自分のノートパソコンでやったことは、まさに驚異的でした。基本的にはWindowsをVMのような環境でデバッグしていたのです。信じられないほど感動的でした。
あなたの経験やコミュニティで見てきた中で、挫折しそうになることはありますか。
人々が助けてくれます。サンプルを送ってくれたり、熱心に協力してくれます。エンコーダーにアクセスできないこともあり、それはさらに困難になります。その場合はサンプルを求めるしかありません。
以前VideoLANがTwitterで「このマイナーなサンプルが必要です」と呼びかけていたのを覚えています。
私も長い間「このコーデックが必要だ、あのコーデックが必要だ」と言っていました。
運が良ければ見つかりますが、運が悪ければ何も得られないか、1つか2つだけです。しかし時には金脈を見つけることもあります。「私の会社はこのファイルに依存しているから、10万個のファイルがあるよ」といった具合です。そうしたケースは、幅広いコーディングツールにわたってビットレベルの正確性をテストできるため、最高です。
ビットレベルの正確性（bit exactness）について説明していただけますか。
ほとんどの（すべてではありませんが）ビデオコーデック、特に2000年代以降のものは、ビットレベルでの正確な定義を持っています。つまり、すべての実装は、デコーダーから出力されるデータにおいて、一ビットの狂いもなく正確に同じビットを生成しなければなりません。
大量のサンプルに対してもですか。
与えられたサンプルに対してです。レックスの実装、JBの実装、そして私のH.264の実装は、ビットレベルで正確に一致しなければなりません。
90年代のMPEG-2ではそうではありませんでした。おそらく動画業界が犯した最大の過ちの一つと言っていいでしょう。92年にその場にいた人々も（私たち二人はおそらくおむつを履いていましたが）それを認めています。ユーリ・レズニクも、それがその時代の大きな過ちの一つであったと認めています。
エンコーダーはテストを実行でき、ビットレベルの正確性を保証できなければならないのですね。それは保証されると素晴らしいことです。HTMLを解析して表示するウェブブラウザの動作には、異なるエンジン間でビットレベルの正確性がないのとは対照的ですね。
実際、FFmpegは「勝者総取り」のシナリオであったという点でユニークだと思います。ブラウザは良い例えです。なぜなら、ブラウザもデコーダーのように多くの異なるコンテンツを解析し、特定の方法でレンダリングしなければならないからです。しかし、ブラウザエンジンは依然として複数存在します。Firefoxのもの、Chromeのもの、そして日本製の優れたものもあります。
しかし、幅広いコーデックにわたるマルチメディア全般においては、そうではありませんでした。FFmpegがすべてを勝ち取ったようなものです。なぜなら、新しいコーデックが追加されるたびに、全体がより良くなるため、そのコーデック単体の価値以上の価値が生まれるからです。
本当に素晴らしいですね。Perplexityによれば、「ユーリ・レズニクはマルチメディアと信号処理の研究者で、キーウ大学でコンピューターサイエンスの博士号を取得。150以上の論文と80以上の米国特許を持ち、H.264、MPEG-4、AVC-H.265、MPEG-4 ALS、G.718などの主要なマルチメディア規格の貢献者である」と。
G.71は通信系の規格ですね。
ああ、なるほど。彼はより企業と繋がりがあったのですね。
RealAudioやRealVideoなどもですね。当時非常に重要でした。
Zencoder、Brightcove、Contex。いやあ、ユーリとぜひ話してみたいです。彼は本物ですね。
それに彼はこれまでにないほど素晴らしい人ですよ。私が今やっているKyberというスタートアップのために、デンバーで開催されるMile High Video Conferenceで毎年彼に会っています。彼は私に本当に多くの良いアイデアや知見をくれます。本当に素晴らしい人物です。
彼は私たちに、私たちと知り合えたことがどれほど素晴らしいことか語ってくれます。でも私たちは「いやいや、ユーリ、それ逆ですよ」と思っています。
FATE：FFmpegの厳格なテスト環境
FFmpegに組み込まれるすべてをテストするための、異常なまでに厳格なプロセス「FATE」について言及されていましたね。そのテストプロセスについて教えてもらえますか。
はい。FFmpegにはFATE（FFmpeg Automated Testing Environment）というシステムがあります。FFmpegは非常に多くの異なるOSで動作し、非常に多くの異なるコンパイラでコンパイルできるため、設定の組み合わせが狂気じみた数になります。
コンパイラのバリエーション、OSのバリエーション、命令セットのありえないほどの組み合わせを見ることができます。一番上のmacOSだけでも、iOSやtvOSなど多くのバリエーションがあります。
今、fate.ffmpeg.orgのページを見ています。81分前、76分前と、異なるアーキテクチャ、OS、異なるコンパイラ、Apple Clangのバージョン…組み合わせが尋常じゃないですね。RISCもあります。
これらはすべてボランティアによって運営されています。一番上のMacは、例えば私のオフィスでホストしているものです。他の人が別のものをホストしています。
FFmpegはかなり複雑なCコードを書くため、コンパイラの誤コンパイル（ミスコンパイル）が発生することがあります。コンパイラがCコードを誤ってコンパイルしてしまうのです。このテストはそれを防ぐためのものです。
すべてのコンパイルのログがあるのですね。
ええ、すべてのコンパイル、すべてのテストのログです。他のページではすべてのテストがパスしているのを見ることができます。
クリックすると、すべてのテストが成功しているのが見えますね。
ええ、テストのログですべてのテストがパスしているのが見えます。すべての異なるコーデック、すべての異なるフィルター変換など。この規模のレベルは本当にクレイジーです。
本当にクレイジーですね。
すべての組み合わせに対してです。もはやマトリックスというより、異なる組み合わせのピボットテーブルのようです。
ローカルでテストして変更を加えたとしても、実はそれがMac上のGCCバージョン11を壊してしまう可能性があるからです。それに気づいて修正できるようにするための重要なプロセスです。また、Cコンパイラ自体にバグがあって間違った出力を生成することもあり、フレームの依存関係の性質上、それが動画に大きな影響を与えることもあります。出力のわずかな違いが、連鎖的に大きなグリッチ（乱れ）に繋がるのです。
PowerPCやRISC、ARMも見えます。
過去にはPowerPCやRISC、DEC Alphaといった奇妙なものもありました。
Visual Studioや、様々なバージョンのClang、GCCも見えますね。
Visual Studio、Intelコンパイラ、Apple Clang、何でもあります。
苦労する点は何ですか。感情のトリガーになったり、特定のOSやコンテナ、コーデックの組み合わせの悪夢を見たりすることはありますか。
私の場合はとてもシンプルです。本業があるからです。私の立ち上げた会社は、例えばスタジアムとスタジオ間でスポーツ中継を放送するための機材を作っています。そこでは10ビットの動画を扱う必要がありますが、10ビットのデータはCPUでネイティブに処理できません。そのため16ビットに格納することになり、6ビットが無駄になります。
ネットワーク経由で送信する際、帯域幅を節約するために様々なパッキングフォーマットを使用します。例えばPCI Expressでは、それを行うためのバス帯域幅が限られている場合があります。業界標準のものや、私たちが構築するハードウェア内部の独自のものを含め、すべてのフォーマットから他のすべてのフォーマットへの変換について、おそらく5×5か6×6のマトリックスを持っています。
そのうちの一つをあなたにお送りしましたが、それらはすべて手書きのアセンブリで書かれており、異なるCPU世代をすべてサポートしています。この何百万通りもの組み合わせを処理するのは本当にトラウマになります。
ちなみに、あなたの会社というのはOpen Broadcast Systemsのことですね。
はい、無料のストリーミングソフトOBSとは関係ありません。JBと私は大まかに言ってFFmpegやVLCの精神に基づいて会社を立ち上げました。これは本当に低レベルの作業です。多くの企業では、これをアセンブリで書くことはしないでしょう。C言語で十分速いと考えられています。しかし見ての通り、Cは速くありません。
ここに、C言語の62倍速いと書いてありますね。
ええ。低レベルプログラミング、リアルタイムプログラミングの精神を取り入れ、それを商業アプリケーションに使用しています。JBと私はそれを中心に会社を立ち上げ、多くの場合オープンソースコミュニティから開発者を雇い、その精神を活用しています。多くの企業では「Cで書けば速いからそれで終わり」と言うでしょうが、実際にははるかに改善できるという素晴らしい例です。
私にとって頭痛の種の一つは、サポートが難しい一部のOSです。VLCを見ると、FATEとFFmpegのおかげで、最新バージョンのVLCが今でもWindows XPで動き、同時にWindows 11でも動きます。macOSは10.7から最新のmacOSまで動作します。iOSはiOS 9から現在のiOS 26まで動作します。多種多様なLinux、BSD、Solarisもサポートしています。
最新バージョンは今でもOS/2で動作します。世界にOS/2のユーザーは10人くらいしかいないかもしれませんが、そのうちの一人がVLCのメンテナンスをしてくれています。VLCを取り巻くこの非常に小さなチームが、無限の力とリソースを持つMicrosoftやGoogle、Appleよりも多くのOSをサポートしていることに気づくでしょう。
しかし例えば、最悪なのはiOSです。iOS 9向けにビルドするためには、AppleのXcode IDEとSDKのいくつかのバージョンを非常に巧みに組み合わせ、フランケンシュタインのようなバージョンを作る必要があります。そうしないと、Appleのコンパイラでは全くサポートされていないiOS 9上のArm32で動作させることができないからです。FATEでもまだiOS 9をサポートしているのを見ましたね。
ですから私の頭痛の種は、非常に多くのOSのサポートに主に関連しています。しかしそれは重要です。「昔のiPad 2で映画を見るのに今でも使えて感謝しています」というメッセージを多くの人から受け取りますから。iOS 9でもまだ動くのです。これは、適切に最適化すればうまく機能するのに、新しいハードウェアを買うことを強制しないということの表れでもあります。これがアセンブリについての話にも繋がります。もっと最適化できるのに絶えず新しいものを買わなければならないという状況に抗うことであり、これは失われつつある芸術なのです。
アセンブリ言語による究極の最適化
この「失われつつある芸術」について、あるいはアセンブリの炎を受け継ぐ者たちについて教えてください。アセンブリとは何ですか。なぜそれが美しく、なぜ難しいのでしょうか。どのように機能するのですか。
アセンブリ言語でコードを書く時、実際のプロセッサが直接使用する命令を使って書きます。ほとんどの場合、例えばC言語などの言語で書くと、コンパイラがそのCコードを元にアセンブリ言語と機械語の命令を生成してくれます。
FFmpegで私たちが使用しているアセンブリの特定のフレーバーは「SIMD（Single Instruction, Multiple Data）」と呼ばれるものです。例えば、スカラーアセンブリ（個々の要素に対して操作を行うもの）で数値に5を足したいとします。10という数字があって5を足したい時、add命令を使って10に5を足し、15を得ます。
SIMDを使えば、16個の異なる数字のベクトル全体を持つことができます。それぞれが異なる数字であっても構いません。それに5を足したい場合、1つの命令を実行するだけで、その1つの命令が16個の要素すべてを合計してくれます。想像がつくように、これは動画に非常に適しています。動画はピクセルのグリッドなので、複数のピクセルに対して同時に操作を行うことができるからです。
FFmpegで私たちが他と異なるやり方をしている重要な点は、その上に大きな抽象化レイヤーを使用しないことです。世の中の一部では「組み込み関数（イントリンシックス）」と呼ばれるものが使われています。これはC言語の関数ですが、手書きのアセンブリを書くのとは少し違いますが非常に似た振る舞いをします。データが保存されるCPU上のレジスタの割り当ては、コンパイラが自動で行います。
私たちがSIMDを書く時に理解しておくべき重要なことは、10倍から50倍の速度向上が得られるということです。パーセンテージではなく、倍です。この関数は62倍高速になっています。ご存知の通り、FFmpegのアカウントでは「私たちはこういうことをやっているんだ」と伝えるために、これについて何度も投稿しています。
あなたはアセンブリの美しさを理解している人ですが、同時にC言語すらも大きく凌駕するという点で、これらのアプリケーションにとって極めて実用的なのですね。それはクレイジーです。
必要なことなのです。例えば、私たちが話さなければならないプロジェクトの一つにdav1dがあります。dav1dは、Google、Netflix、Amazon、Mozillaなどが参加するAlliance for Open Mediaによって作られたAV1というフォーマットのためのデコーダーです。
ご存知ない方のために補足すると、先ほどH.264について話しましたが、AV1は現在インターネットを席巻しつつあるもう一つの非常に人気のある規格でありコーデックです。
このフォーマットが発表された時、Alliance for Open Mediaの人たちも含め、多くの人が「このフォーマットは複雑すぎるから、デコードはハードウェアで行わなければならない」と言いました。そこで私やロナルド、ヘンリック、マーティンらが参加し、「ハードウェアが普及するまでには時間がかかるから、極めて優れたソフトウェアデコーダーが必要だ」と言ったのです。
そうしてこのプロジェクトを書きました。これは常軌を逸しています。3万行のC言語に対し、24万行もの手書きのアセンブリがあるのですから。
24万行の手書きのアセンブリですか。信じられません。私たちが話している中で、おそらく最大のアセンブリコードベースの一つですね。
キーランが訂正してくれるかもしれませんが、私の記憶ではFFmpeg全体ですべてのコーデックのアセンブリが10万行だと思います。
すべてのコーデックを合わせてですね。ええ。
そしてこの特定のプロジェクトだけで24万行です。もちろんVideoLANのプロジェクトです。極限まで最適化されています。プロジェクト開始時のモットーが「すべてのサイクルが重要だ」だったからです。すべてのサイクルが重要なのです。dav1dはVLCや一部のソフトウェアAV1再生スタックで使用されています。
Netflixの動画の30パーセントがAV1になり、YouTubeでは50パーセントに達しているため、おそらく30億台ものデバイスが休むことなく動画をデコードし続けることになります。しかし、ハードウェアデコーダーを搭載しているデバイスはそれほど多くないため、ソフトウェアで処理しなければなりません。dav1dを使うと、1つか2つのコアで720pの動画を正確にデコードできることがわかりました。これは文字通り驚異的なことです。
ええ、それがdav1dです。
これがdav1dですか。すごいですね。
ええ、これはあなたの別の辛口なツイートですね。「究極のビデオコーデックはこのようになるべきだ。アセンブリが79.9パーセント、C言語が19.6パーセント、その他が0.5パーセント」。
驚くべきことに、これらのツイートは事実に基づくものなのに、人々は激怒するのです。
ここ2年間、彼らは怒り狂っています。「組み込み関数で十分だ、コンパイラがやってくれる」と。
「コンパイラを最適化すればいい、自動ベクトル化ができるはずだ、あなたが理解していないだけだ」と言ってきます。しかし、私たちはそんなことはずっと昔から試してきているのです。
2年間もそう言われ続け、その2年後に手書きのアセンブリ言語の例を何百も示したにもかかわらず、「いやいや、あなたのやり方が間違っている、コンパイラならできるはずだ」とまだ言うのです。
少し明確にしておきましょう。ソフトウェアエンジニアリングの人たちの直感としては、例えばC++のような言語でコードを書くと、コンパイラが多くの最適化を行ってくれますよね。
はい。
そして、コンパイラが十分に優れていれば、あるいはコンパイラを改善し続ければ、最適なパフォーマンスを発揮するコードが生成されるという前提があります。それを人間が上回ることはできないだろう、と。
はい。そうです。
しかしあなたは、手作りのアセンブリがCを文字通り何桁も上回る性能を出せるということで、その考えに絶えず挑戦しているのですね。
彼らが私たちに言うのは、「最新のコンパイラには自動ベクトル化があるじゃないか」ということです。私たちがやっているSIMDはベクトル化だからです。しかし、比較にならないレベルです。5パーセントや10パーセント遅いという話ではなく、何倍も遅いのです。
哲学的な観点から何か言えることはありますか。素晴らしいソフトウェアエンジニアや機械学習の専門家がたくさんいて、カルパシーもこれを聞いて「そこからどんな直感を得るべきなのか」と思うはずです。
カルパシーはあのツイートを見てアセンブリを学んだんですよ。彼は「ああ、これは一つのムーブメントだと思う」と言って、何が起きているのか理解しようとし始めました。
彼は自分が行った作業を文書化していますよね。哲学的に理解しておくべき重要なことは、ハードウェアの進化が劇的に速かった時代は終わったということです。ムーアの法則は限界に達しています。AIにとっても、メモリの制限があります。私たちのCPUパワーやGPUパワーへの要求は爆発的に増大しているのに、ハードウェアの速度向上はそれに追いついていないため、スタックのより低いレベルに降りて最適化し、手持ちのハードウェアからより多くのパワーを引き出す必要があるのです。
人々はコア数を増やすことで対応していますが、最終的には250コアなどに増やすことはできても限界があります。だから私たちはマシンの隅々まで活用するのです。
それだけではありません。私たちはマシンを酷使し、設計者が予期しなかった方法で使います。動画処理とは全く関係のない暗号化命令を使うこともあります。
dav1dで行っている狂気じみたことのもう一つは、OSからの関数呼び出し規約（コーリングコンベンション）を使用しないことです。
それは説明すべきですね。
極めて複雑な話ですが、基本的にコード内で一つの関数から別の関数へ移動する際、CPUの状態であるレジスタを保存してから次の関数に入る方法があります。これが標準的なやり方です。
少し簡単に説明します。dav1dは呼び出し規約を乱用するようなことを行っています。呼び出し規約とは、「関数を書いて別の関数を呼び出したい時、関数間でどのようにデータを共有するか」を定義するものです。規約が存在し、dav1dは最適化のために独自の呼び出し規約を作成することがあります。私がレックス・フリッドマンのライブラリを呼び出したい場合、アセンブリ言語空間でデータを共有できるように規約に合意する必要があります。
アセンブリの課題の一つは、x86上でLinux 32ビット、Windows 32ビット、Windows 64ビット、Linux 64ビットと、それぞれ独自の呼び出し規約を持っていることです。前述のローレン・メリットが行った素晴らしいことの一つは、非常に軽量な抽象化レイヤーを作成し、アセンブリコードを一度書けば、すべての呼び出し規約を処理してくれるようにしたことです。4つの異なるバリアントを管理しなければならなかった問題を解決しました。しかしdav1dは速度のためにこれをさらに推し進め、関数呼び出しのルールをバイパスして「ライブラリ内部だとわかっているからこの方法で関数を呼び出す」と独自の呼び出し規約を使用します。
それはすべてのOSに対して特別に用意しなければならないのですか。
カスタムであればそうではありません。課題は一般的な場合であり、各命令セットごとにも異なります。私たちがこれをすべての命令セットで行っていることも強調しておくべきでしょう。すべての命令セットに独自の手書きのアセンブリがあるのはさらにクレイジーです。RISC-VやARM64、新しいSVE、SMEの登場により、そのマトリックスは近年さらに拡大しています。x86にはAVX-512、AVXがあります。私たちは実行時にプロセッサを検出し、FFmpegやdav1dが実行されているマシンが何を処理できるかを確認します。2008年のノートパソコンで実行されているかもしれないからです。実行時に検出して、それに応じて関数ポインタを設定し、そこから処理を開始します。
あるいはRISC-Vのマシンかもしれません。
はい。そしてそのすべてにおいて、高速化のためにOSの呼び出し規約さえも尊重しません。自分たちのバイナリ内部から呼び出されることがわかっているため、一般的な方法でレジスタをすべて保存することなくデータを共有できるからです。そうしないとL1やL2のCPUレジスタへのロードや保存が発生してしまいますが、独自の規約によってより高速化できるのです。だからこそ、CPUアーキテクチャ、コンピュータアーキテクチャを理解することが重要だと言ったのです。
これが手書きである理由でもあります。dav1d以外にこれをやっているプロジェクトを聞いたことがありません。だからこそキーランはこれを芸術と呼ぶのです。まさに芸術です。
大規模な世界で数十億のデバイスに導入されているものとしては例がないと思います。高頻度取引のような専門的な業界ではこれを非常に真剣に受け止めており、市場からのフィードバックを受けて数マイクロ秒以内で反応しなければならないため、命令が重要になります。しかし、それは数十億のデバイスにある大量生産されたものではなく、超専門的なハードウェアで動く超専門的なものです。私たちはあらゆるハードウェアで動かしていますから。
少し話が長引いて申し訳ないのですが、アセンブリに巨大な価値があるというのは非常に直感に反する、ほとんど革命的なアイデアだと思います。私たちそこから何を学べばいいのでしょうか。これを聞いている多くの人（私自身を含めて）は、C/C++で長年プログラミングし、C++の規格を上がり、メタプログラミングなども大好きでしたが、約15年前から機械学習のためにますますPythonに移行してきました。
今のPythonやJavaScriptの世界では、ジャグジーに浸かりながらお酒を飲み、自然言語を使ってコンピュータに話しかける「バイブコーディング（vibe coding）」が主流です。そんな中でレコードの針が止まったかのように、「なぜそんな低レベルまで戻る価値があるのか？」という直感的な疑問が湧きます。
投資した1ドルあたりのパワーをより多く引き出せるからです。ハードウェアによって制限される問題に直面することがあります。良い例がLLMにおける量子化です。「FP8やFP4でやろう」とか、Microsoft Phiのように「1.5ビットでやろう」といった狂気じみたことをやっているのは、メモリに制約があるからであり、実行できるマシンに制約があるからです。
私たちはリアルタイム処理を行っており、これはAIの推論でも起こることだと信じています。ある時点でより高速化する必要があり、常により強力なハードウェアを手に入れられるわけではありません。そのため、コードを分析し、どこがミッションクリティカルで、どこが絶え間なく呼び出されているのかを見極める必要があります。dav1dは良い例です。毎日数十億時間も実行されるのですから、アセンブリで書く意味があります。FFmpegのCLIの接着剤のような部分をアセンブリで書く意味はありません。
ええ、これは後でも話すと思いますが、あなたの新しい会社Kyberは、「すべてのミリ秒が重要だ」というスローガンで、超低遅延のためにそういったことを行っていますね。特定の次元で極度に制約がある場合…
私たちは多くの素晴らしいことを達成してきましたが、ハードウェアの進化が鈍化し、コストが上昇し、より多くの電力が必要になっているという現実に直面しています。CPU、RAM、ネットワークのいずれかによって制限されるため、最適化が必要であり、そこにこそ価値が生まれるのです。特に、AIがビジネスのプログラミングを支援するようになるため、バイブコーディングできない核心的な部分は、ハードウェアを可能な限り高速化するための最適化になるでしょう。
アセンブリを誰がどうやって学ぶべきかについて話したいのですが、その前に一度トイレ休憩を挟みましょう。スポンサーの皆様に簡単な感謝の言葉を。概要欄からチェックしてください。これがこのポッドキャストをサポートする最高の方法です。lexfridman.com/sponsors にアクセスしてください。それではエピソードに戻ります。
さて、戻りました。アセンブリのレッスンができる素晴らしいリポジトリがありますね。まず、開発者はアセンブリでのプログラミングを学ぶべきだと思いますか。そして、どうやって学べばいいのでしょうか。この「asm-lessons」とは何ですか。
個人的に、本やオンラインでのアセンブリの教え方に不満がありました。文法に重点を置きすぎているからです。言語を学ぶ時、一般的に文法や構造から学ぶことはありません。「あなたの名前は何ですか」と尋ねることから始め、そこから実際のコミュニケーションで直面する問題を解決していきます。文章の構造や疑問詞、副詞などを学ぶことから始めるわけではありません。
しかし、すべてのアセンブリの本は、関連性の低い命令も含めてすべての命令を順に追い、それが何をするのかを説明しているようです。それは実際にはあまり意味がありません。
また、私たちのコミュニティが抱えるもう一つの問題は、アセンブリが鍛冶屋のように一人一人に手取り足取り教えられているということです。それではオンラインでスケールしません。そこで私は、一般的なアセンブリの教え方とは少し異なる、FFmpegのやり方に基づいたアセンブリのレッスンのセットを始めました。他の大きなアセンブリの用途といえば組み込みデバイスや低電力デバイスですが、私たちがやっていることはそれとは全く異なります。
要件が非常にシンプルであることを強調しておきたいです。高校レベルの数学とC言語だけです。実際にはC言語というより、ポインタの知識ですね。これがいかに素晴らしいかを話してきましたが、ダニエル・カンのような高校生がFFmpegでアセンブリを書いていることも強調したいです。これらのレッスンのおかげで貢献があったと思います。
dav1dで驚くべきものを作れることを証明したように、この消えゆく芸術を継続させることが目的です。FFmpegにはまだ部分的にしかアセンブリ最適化されていないコーデックがたくさんあります。
このレッスンは本当に基礎から始まり、多くの専門用語や構文を説明していきます。割り込みハンドラや割り込み命令、あらゆる異なるジャンプのターゲットなどを説明しようとはせず、非常にベクトルに焦点を当てた内容になっています。
汎用レジスタやベクトルレジスタなど、あらゆる種類のレジスタについて説明されています。本当に素晴らしい例ですね。ああ、これはクールです。
FFmpegの古典的な例です。しかし、このアセンブリ言語の一部は本当に美しく、私がそれが美しいと思う理由は、スピットファイア（戦闘機）を操縦するようなものだからです。純粋な意味での航空機操縦でありながら、設計者が可能だと考えた限界を超えて機体を押し進めるようなものです。先ほど言ったように、私たちは特定のことを行うために暗号化命令を乱用することがあり、自分とプロセッサの間に何もないという美しさと芸術のレベルがあります。
コックピットのジョイスティックを握り、それを動かすと物理的に補助翼と繋がっていて、通常できる限界を超えて飛行機を押し進めることができる。そこに美しさと驚きがあります。しかし、一対一でアセンブリを教えるようなやり方は、この特定のフレーバーと私たちのやり方の性質上、長期的には機能しないと思います。
文字通り魔法使いが伝授するようなものですね。この帽子をかぶっていると私が魔法使いに見えることに気づきました。賢者たちが技術を伝承していくような。
LLM（大規模言語モデル）について聞いていいですか。彼らは助けになりますか。
彼らは私が予想していた以上の理解を持っていましたが、私が質問すると、幻覚（ハルシネーション）とまでは言いませんが、勝手に変更を加えてしまいます。私が「これはビットレベルで正確に一致するか？」と聞くと、「いいえ」と答える。「修正しろ」と言うと、また同じことを繰り返します。Stack Overflowのような、学習するための情報のコーパス（蓄積）が存在しないのです。
訓練するのに十分なデータがないのです。これが最大の問題です。私はキャリアのスタートでItanium用のアセンブリを書いていました。ItaniumはIntelとHPが大昔に64ビット化を目指して作ったものの、AMDに敗れてAMD 64（後のx86-64）になった、今では死んだプロセッサです。
しかしItaniumは、浮動小数点演算（FMA）を行うための計算能力が非常に高く、今のLLMに求められているものに似ていて非常に興味深いものでした。ロード可能な1行に3つのオペレーションを詰め込むことができました。基本的には1秒間に60億回のオペレーションを出力できましたが、メモリバスが1.5しか許容しませんでした。CPUが4倍速かったため、メモリへのパッキングやレジスタの再利用など、常軌を逸したことをしなければなりませんでした。
そのようなセマンティクスはどの言語でも不可能でした。Intelは素晴らしいマニュアルを作っていたので私はItaniumのプログラミング本を持っていますが、キーランが言う通り、自分が何をしようとしているのか分からなければ読むのは不可能です。専門用語だらけですから。一方、これらのレッスンは実際の問題に焦点を当てており、自分自身で行うことができるため素晴らしいのです。
そして人々は実際にパッチを送ってきました。「レッスンで学んで、これが初めての変更です」と言って。
それは素晴らしいですね。
レッスンの一部には、ローレンがx264に取り組んでいた時に書いた「x86inc」というフレームワークが含まれており、これを使うことで異なる呼び出し規約をあまり気にせずに多くのことができるようになります。昔、これを使ってx264のコードを提供してくれた学生がたくさんいました。
ですから、これは本当に実行可能なことです。たとえあまり使わなくても、アセンブリ言語を理解することは、コンピュータの内部で何が起きているかを理解するために必要だと信じています。それがあなたをより良いプログラマーにしてくれるでしょう。これを行うことで、レジスタ、L1、L2、L3、RAM、SSD、ディスクなど、コンピュータ内のメモリのアーキテクチャを理解できると保証します。これらは、より良いプログラマーになるための優れたプログラミングの素養を持つために非常に重要です。
Rust言語とメモリ安全性の議論
Rustというプログラミング言語についてどう思いますか。一種のミームになっていますが。
キーランと私で意見が大きく異なります。
概念としてのメモリ安全性に関して彼らがやっていることは価値があると思います。
アセンブリが達成するような速度向上を達成できるのでしょうか。
手書きのアセンブリには及びません。それは確実です。C言語には及ぶかもしれませんが、私はエスペラント語のような雰囲気を感じます。「これで解決するぞ、私たちはこの特定の方法でやっているんだ」というような。
少しユートピア的すぎるということですか。
現実世界の問題を解決することよりも、自己重要性に焦点を当てすぎている気がします。シンクレアC5を思い出します。クライブ・シンクレア卿が車を作り、「みんなこの電気自動車に乗って移動するようになるだろう」と言ったような。Rustはそれを思い出させます。人々に移行してもらうためには、今あるものと同じくらいか、それ以上に良いものを作らなければならないということを、コミュニティは完全に理解していないのだと思います。
ええ、人々はRustでの書き換えを行っていますが、coreutilsのように私たちが必要とする機能セットの85〜90%しか満たしていない場合、最後の1%に99%の時間がかかります。イーロンの有名な言葉を借りれば、「プロトタイプは簡単だ」ということです。この種のことは簡単ですが、本物の電気自動車を作るには、今あるものと同等以上の車を作らなければならず、Rustはまだその段階にはありません。
FFmpegにRustコードが入ること自体に反対する人はいないと思いますが、それは他と同じくらい機能し、同じ単体テストをサポートしなければなりません。完璧でなければならないのです。突然壊れるようなことがあってはなりません。好きな時にABI（アプリケーション・バイナリ・インターフェース）をランダムに壊してはいけません。それに、コンパイラの実装がまだ1つしかないと思います。「これが私のメモリ安全性のユートピアだ」と言うだけでは不十分なのです。それが目標であることには私たちも同意するでしょうが。
私はRustをたくさん書いてきましたし、私が抱えていた主なトピックの2つはVLC内にRustモジュールを追加することでした。VLCが人気を得た理由の一つであり、主要なアーキテクチャの決定事項の一つは、VLCが非常に小さなコアと大量のモジュールで構成されていることです。そのため、C、C++、Objective-C、その他Cと相互運用可能な言語でモジュールを書くことができます。
そこで私たちはRustモジュールをいくつか作成し、私にはその経験がありますし、自分でもいくつか書きました。また、私の新しいスタートアップKyberは主にRustで書かれたオープンソースプロジェクトです。
Rustが極めて優れているのは、メモリを気に掛け、他の言語にはできないメモリの所有権に関する処理を可能にする、より良いC++であるという点です。しかし、ゼロから新しいプロジェクトを始め、すべてをRustで行う場合には素晴らしいのですが、既存のコードと相互運用する場合にはあまり良くありません。
Rustコミュニティの一部には、すべてを書き直す必要があり、Rustですべてがより良くなると信じている人々がいます。しかし答えはノーです。エンジニア、マネージャー、スタートアップのCTOとしての長年の経験から言わせてもらえば、ほとんど常に「書き直すな」が正解です。
それはLLM登場以前にコードベースを見た多くの人の最初の本能ですよね。過去に行われた方法の知恵を理解していないから、「よし、書き直そう」となるわけです。だから何千ものJavaScriptフレームワークが存在するのですね。
その理由は次の通りです。これは理解しておくべき非常に重要なことですが、コードを読むよりも書く方が桁違いに簡単だからです。LLMでも同じことが言えます。彼らはコードを書くことはできますが、分析するのははるかに難しいのです。
非常に複雑なコードに行き当たった時、それが理解できないことがあります。他人のコードを理解するのははるかに労力がかかります。なぜなら、その人の思考プロセスがわからないからです。私はよくPerlのような非常に複雑な構文を持つ言語について冗談を言います。「私がプログラミングにおいて最高の知的効率を発揮し、史上最高のコードを書いたとしよう。半年後には自分でも理解できなくなるだろう」と。
コードを読むのは難しいのです。だから、そのコードに込められた知恵やビジネスロジック、文書化されていないかもしれない背景の理由を理解せずに、「よし、書き直そう」と言ってしまいます。しかし、それはすべきではありません。キーランが言ったように、「coreutilsをRustで書き直そう」となっても、すぐに80%、90%には到達しますが、残りの10%にさらに時間がかかり、最後に残された部分の処理に追われることになるからです。
一方で、新しいプロジェクトにとっては素晴らしい言語です。メモリチェッカーや境界チェッカーのおかげで、ファイルのパースやネットワーキングに関するすべてにおいて驚くべき威力を発揮し、他に比肩するものはありません。
少し異なる視点から答えると、dav1dやx264のような、実行時の多くをアセンブリに依存しているソフトウェアがあると想像してください。C言語の部分をRustで書き直せば、確かにセキュリティは向上します。しかしアセンブリ部分に行き着くと、私たちは手書きのアセンブリでメモリ内のどこにでもジャンプできてしまいます。つまり、C言語の一部をRustで書き直しても、同じパフォーマンスを得るためにインラインアセンブリを使用すれば、セキュリティモデル全体を破壊することになるのです。
ですから私の意見では、セキュアなアセンブリのようなものが必要です。コンパイル時にアセンブリをチェックする仕組みです。これはVideoLANでdav1dやx264に対して行っているcheckasmプロジェクトに似ており、コンパイル時にアセンブリを計装して、メモリ内のどこへでもジャンプしていないかをチェックします。そうしないと、Cの一部をRustで書き直したとしてもインラインアセンブリを使うことになり、セキュリティモデル全体が壊れてしまいます。これがRustについての私の考えです。
個人的なレベルで言えば、私はアセンブリに畏敬の念を抱いています。62倍もの速度向上を見るのは決して飽きることがありません。職場でも個人的に社内のテストスイートを実行し、その劇的な向上にいつも驚嘆しています。
プログラミングには様々な理由で喜びや幸福感の源があります。しかし最も大きな幸福の一つは、コードの最適化にあると思います。そしてお二人はその最前線にいるようですね。
「うわ、これはクールだ」と思いましたよ。
コミュニティの中で、2人のアセンブリの魔法使いについて話したいと思います。2人とも北欧の、スウェーデンとフィンランドに住んで働いています。
ヘンリック・グラムナーはIntelのx86アセンブリについて非常によく知っているので、私たちがIntelに質問すると「なぜ私たちに聞くのですか？あなたたちにはヘンリックがいるじゃないですか。ヘンリックの方がよく知っていますよ」と言われるほどです。彼はすべてのCPU世代におけるほぼすべてのSIMD命令のサイクルを知っています。「ああ、これはP4、これはNehalem、これはCore 2」といった具合です。彼は世界最高のアセンブリ専門家です。しかも彼はお会いした中で最も素晴らしい人物で、彼がそこまで凄い人だとは一見してわかりません。
もう一人はマーティン・ストルショで、彼は主にArm、つまりNeonで同じことをやっています。iPhoneやAndroidなどですね。彼は公園で子供が遊んでいるのを見ながら、スマートフォンのあの使いにくい仮想キーボードを使ってアセンブリをコーディングするのです。まさに魔法使いのレベルです。この二人は本当に素晴らしいです。
その高レベルなアセンブリプログラミングにおいては、プログラミング対象のアーキテクチャを知り尽くしていることが重要なんですね。
ええ、特にArmではそうです。
しかしx86も複雑なアーキテクチャですよね。
ええ。でもArmはもっと複雑な面があります。x86の アウト・オブ・オーダー実行はそれほど悪くありません。Armの場合、各世代のArmプロセッサをすべて理解する必要があります。A72やその他諸々、Appleのバリアントなど、すべて異なります。そのすべてで効率的に動作するコードを書かなければなりません。
x86は、大まかに言えばIntelとAMDがあり、サブバリアントもありますが、一般的にある環境で速いものは他のすべてのバリアントでも速い傾向があります。しかしArmでは全く異なる、はるかに複雑なゲームになります。
オープンソースプロジェクトにおける対立と和解
歴史を非線形に行き来していますが、マイケル・ニーダーマイヤーについて話しましたね。これについて聞きたいのですが、一時期FFmpegとLibavに分裂したことがありました。
はい。オープンソースプロジェクトでは意見が合わないこともあります。
とても丁寧な言い方ですね。
良いところは、ライセンスのおかげで基本的に自分自身のバージョンを作ることが許されていることです。これは普通のことであり、常に起こってきたことです。GCC 2とEGCSがGCC 3になった時もそうです。KHTMLがWebKitになり、Blinkになった時もそうです。同じプロセスです。
私が今日VLCに新機能を実装したい時も、フォークして自分で作業し、その後コミュニティにマージして戻します。FFmpegのオープンソースコミュニティでも分裂があり、LibavとFFmpegになりました。そして数年後、コミュニティは再び統合し、人々は前に進みました。これはオープンソースコミュニティにおける一種のドラマですが、ごく普通のことであり、フォークは重要でもあります。コミュニティの現状を打破するからです。
FFmpegとLibavの話ではありませんが、GCCのフォークはGCCをはるかに良くしました。一部の人々が高速化のためにアーキテクチャを根本的に変更したいと考えたからです。もちろん常に人間関係などの問題はありますが、最終的には今日のFFmpegはフォーク前よりも良くなっています。そして今、私たちは皆一緒に戻ってきています。
私は多くの時間を費やしましたし、キーランもコミュニティで証言できるでしょう。正直なところ、多くの理由が公にされていないため、あまりよく説明されていません。しかしそれは普通のことですし、良いことだと思います。
非常に穏やかに聞こえるように話されていますが、オープンソースプロジェクトの内部では激しい争いがあります。非常に情熱的なコミュニティであり、分散型の方法で方向性を定義しなければならないからです。
ここでPerplexityを見てみると、「FFmpegとLibavは2011年に分裂した。理由は根本的な技術的意見の不一致ではなく、主にプロジェクトのガバナンス、リーダーシップのスタイル、開発プロセスに関するものだった。FFmpegは事実上Libavの成果を吸収し、一方のLibavは衰退し、ほとんどのディストリビューションと開発者はFFmpegに戻った」とあります。
あれは奇妙な経験でした。私はLinuxユーザーなので、Ubuntuなどが突然Libavに切り替えたのを覚えています。
12か14の頃ですね。そのくらいです。
それからFFmpegに戻りました。「一体何が起きているんだ？」と思いましたよ。内部で起きている様々な議論の波紋を感じることができます。
公平のために言うと、Apple環境でGCCとタイプするとClangが立ち上がります。彼らも似たようなことをしましたから。
私にとって、このフォークは激しいドラマのようでしたが、Libavからの開発の大部分はFFmpegにマージして戻されました。事実上、FFmpegはLibavを包摂するスーパーセットとなり、最終的に私たちが奉仕する対象であるユーザーに、より多くの機能と議論された多くの成果を提供することになりました。
例えばレビューやプッシュの方法に関する議論は、現在ではFFmpegで完全に決着し、コミュニティのほぼ全員が同意する方法に従っています。事実上、Libavで活動していた全員がFFmpegに戻ってきて作業しています。意見の不一致が解消され、結果としてFFmpegは以前よりも強固になったからです。人々はドラマを好むことは知っていますが。
私の主な関心事は、その長い歴史を見ればすべて良い方向に向かっていると理解しています。しかし、懸念しているのは、オープンソースプロジェクトの成功に不可欠な人間があまりにも少なく、それが人々に心理的な犠牲を強いて、時には燃え尽き症候群（バーンアウト）に繋がるのを見てきたからです。
オープンソースプロジェクトの中心には、こうした素晴らしい人々がいます。彼らの動機は最終的に、情熱を持っていてそれが幸せだからです。しかしある時、目を覚まして「このドラマの熱気はもうたくさんだ」となる瞬間があります。プロジェクトのレベルでは存続し繁栄し続けることが多いですが、時には個人の人間が「もう十分だ」と離れてしまうことがあります。
しかし、フォークだけの問題ではありません。あなたが言及しているのは、今日のオープンソースにおいて最も挑戦的で興味深い部分の一つである「メンテナの燃え尽き症候群」です。AIもその原因の一つです。
世界で最も優れたオープンソース推進者の一人である、curlのメンテナであるダニエル・ステンバーグは（ちなみに彼は私と同じく欧州オープンソースアカデミーのメンバーであり、彼と同じコミュニティにいることを大変光栄に思います）、彼が「AIスロップ」と呼ぶものに反対しています。
AIが大量の偽のレポートや質の悪いレポート、質の悪いパッチを送りつけてくるため、多くのメンテナがソフトウェアを維持するのに大きな負担を強いられています。これはフォークよりもはるかにオープンソース開発者の心をすり減らしています。
例えばXZの騒動は、一人でメンテナンスしていた彼が、奇妙な夜間の時間に絶え間なく質問を浴びせてくる2人の攻撃者に事実上ハンマーで叩きのめされ、ある時点で嫌気がさして「もう無理だ」とコミットアクセス権（変更権限）を攻撃者に渡してしまったために起きました。
オープンソースコミュニティにおける燃え尽き症候群は存在しますが、それは主にメンテナンスの作業に関連しています。
メンテナの燃え尽き症候群と直面する圧力
ええ、確かに。しかし、どうすれば彼らを助けられるのでしょうか。プロジェクトの核心にいるその人間たちは非常に重要ですから。
例えば現在、私はマルチメディアからそれ以外のライブラリまで、多くのメンテナを務めています。元のメンテナたちが嫌気がさしてしまったからです。VideoLAN関連もあれば、それ以外のものもあります。
時にはタフな精神が必要です。「これが動かない、あれが動かない」といった実際の攻撃ではないような言葉を受け取り、それを個人的なものとして感じてしまうからです。リソースの問題やGoogleの騒動が問題になったのもこのためです。彼らは最終的に、何が起きているのかを理解していません。
あらゆるものを支えているたった一つの無名のオープンソースプロジェクトのグラフのミームをご存知ですか。ネブラスカの人が支えているというあれです。
ネブラスカの件ですね。ええ。
ええ、あのミームです。多くのオープンソースプロジェクトに当てはまりますが、これは最新のデジタルマルチメディアインフラストラクチャ全体であり、そのすべてが依存している底辺にあるのがFFmpegです。それは事実です。そして通常、一握りの人々がそれを維持しています。
FFmpegやVLCには10人、15人のコア開発者のコミュニティがあるので、最悪のオープンソースプロジェクトというわけではありません。XZはさらに多くのシステムにインストールされていますが、担当者は一人です。たった一人なのです。
libxmlもそうですね。
ええ、libxmlもです。大きく停止しました。誰もlibxmlをもうメンテナンスしていません。世界中のXMLを解析できる唯一のパーサーライブラリなのにです。
XMLのありとあらゆるクレイジーなエッジケースに対応しているのに、彼らが考えもしなかったたった一つのクレイジーなエッジケースのせいで、セキュリティ研究者から攻撃を受けるのです。「それを解決するための知識体系は膨大なのに」という状況です。
アメリカのネブラスカかサウスダコタの真ん中にいるたった一人の人物が、世界中のすべてのタイムゾーンをメンテナンスしているという例もあります。
オープンソースメンテナのメンタルヘルスは、大企業が気に留めない、あるいは見ていないものです。彼らは「ああ、ただオープンソースのレポートを作っているだけだ」といった具合にしか考えていません。
ええ。資金的な面もありますが、世界中でオープンソースを資金面でサポートすべきです。しかし、基本的な人間のレベルでの精神的な面もあります。FFmpegやインターネットの大部分が彼らに依存しているというイメージがありながら、人々はプロジェクトを前進させ維持している彼らを見下すように話すことがあるのです。
セキュリティコミュニティは確かにそうでした。あの議論が出た理由の一つは、セキュリティコミュニティの一部に「こいつらはクソみたいなコードを書く。そのクソみたいなコードを直すべきだ」という態度があったからです。私は「いやいや、これはある人の趣味のプロジェクトだ。君たちのセキュリティボットがAIが生成したものを見つけてきただけだ。彼がクソなコードを書いたわけじゃない。99.99999%の確率で考えもしなかったようなエッジケースに過ぎない。スターウォーズのゲームをデコードする彼の趣味のプロジェクトなのだから」と言いました。
趣味のプロジェクトという側面を抜きにしても、それは単なるハードワークであり、美しいものです。そこでの正しいアプローチは、信じられないほど素晴らしい仕事をしている人々を称賛することです。最初は無給で、あるいはおそらく永遠に無給で名乗りを上げ、愛ゆえにそれを行っている人間がいるというのは本当に信じられないことです。人類の文明はそうした人々によって動いているのです。私たちは彼らを称賛する必要があります。
具体的な話をすると、私はVideoLANで殺害予告を受けました。
ええ。お話しされていましたね。その背景には何があるのですか。
あれは2009年か2010年だったと思います。AppleがPowerPCからCore Duoに移行したのが2006年頃で、2009年か2010年までに、私はPowerPC向けVLCの新しいバージョンの開発を中止すると決定しました。
当時のVLCはバージョン1.0のリリースが間近に迫っていました。私たちは4人しかおらず、「これ以上は無理だ」という状況でした。そこで、粉の入った殺害予告を受け取ったのです。当時炭疽菌の脅威があったのを覚えていますか。
私がPowerPC版のメンテナンスを終了するという決定を下したからです。もちろん炭疽菌ではなく、小麦粉か何かでしたが。「このクソ野郎、死ね、PowerPCは永遠だ」といった手紙と一緒に受け取りました。2009年か2010年で、私は若かったので「なぜだ？私が何をしたというのだ？」と思いました。
ええ、それは精神を打ち砕かれますよね。なぜ、と。
母はパニックになり、警察に行かなければなりませんでした。でも今となっては、当時にこれが起きて本当に良かったと言えます。これによって私は大いに鍛えられましたから。今では多くのヘイトを受け流すことができます。気になりません。
それが現実の一部であるというのは残念なことです。VLCを愛するすべての人々、FFmpegを愛するすべての人々、私のように、FFmpegが私を幸せにしてくれたからという理由で、人生で何百回、おそらく何千回も本当に笑顔になった人々がいます。私がそれを伝える機会が何度あったでしょうか。ゼロです。Twitterアカウントがあることに気づくまでは。時々メッセージを送っていますよ。
私に関するRedditのミームについて、多くの理由からあのミームは好きではありませんが、一つ好きな点があります。「JBはRedditにいるぞ」と言われて（実際いますが）、私が「こんにちは」と返すと、非常に多くの人が「VLCをありがとう」と言ってくれることです。私はそのスクリーンショットを撮って、SignalやIRCに共有しています。ええ、私たちはIRCを使っています。
少し脱線しますが、あなたはIRCを「老人向けのSlack」と言っていましたね。今でもIRCを使っているのですか。
もちろんです。
私のスマートフォンにも入っていますよ。
毎日です。
普通に使えるんですよね？
クランクを回して電源を入れないといけないんじゃないですか。
いえいえ、そんなことはありません。
SNSとしてAOLを使っているような。
広告もトラッキングもありません。全く何もないのです。
Slackと比較して正直なところ最大の問題は、スレッドがないことです。それは少し面倒です。リアクション用の絵文字もありません。時々あったらいいなとは思います。
IRCv3にはありますよ。
ええ、v3にはありますが誰も使っていませんし、メッセージの編集もできません。それ以外は永遠に完璧に機能します。
絵文字なしでどうやってコミュニケーションをとるのですか。
だから老人向けだと言ったんですよ。
なるほど。
コロンやダッシュ、括弧を使って顔文字を作ります。
オールドスクールですね。とにかく、IRCでコミュニケーションをとっているのですね。何を話していたんでしたっけ。
殺害予告について話していましたね。
でも、人々から感謝されることもあります。「VLCをありがとう」というメッセージを受け取ることもあります。そして私は必ず返信します。オープンソースコミュニティに感謝すべきだという事実を証明したいからです。
ええ、ぜひ、これを聞いている皆さんは、FFmpegを称賛し、VLCを称賛し、Linuxをはじめとするすべての素晴らしいオープンソースプロジェクトを称賛してください。本当にたくさんあります。オープンソースに限らず、あなたがよく使い、愛しているソフトウェアを作っている企業を称賛してください。
人間の努力を称賛することです。ただそこそこのものを作るのではなく、とてつもなく素晴らしいものを作るための人間の努力を称賛してください。
ええ、これは重要です。私たちが言ったように、私たちは一般の人々のために非常に複雑な技術の仕事をしているからです。私たちの技術における卓越性が、誰にとっても有用であることを望んでいます。
だから私たちは働いているのです。私が朝起きる理由は、人々に私たちの成果物を使ってほしいからです。
それがみんなの生活を簡単にしてくれるからですね。
難しい問題を解決したいのです。面白いことに取り組み、興味深い技術的な課題に取り組みたいのです。
エンジニアとして、私たちは物を作るのが好きです。幼い頃から、私はエンジニアになりたいと思っていました。車を作りたかったのです。いつか車作りに戻るかもしれません。クールで役立つものを作りたいのです。そしてそれは挑戦的でなければなりません。脳を活性化させたいからです。
お二人がプログラミング、物作り、エンジニアリングに初めて恋に落ちたのはいつですか。
初めてプログラミングをしたのはいつですか、キーラン？
Microsoft QBasicです。Windows 3.1やWindows 95の時代に。
へえ、すごいですね。何を作ったのですか。
掛け算のような、10、20、30、40とループを数えるようなものです。
いいですね。
その後、何でもできると思い込みました。QBasicで絵を描くことから飛躍して、サッカーのビデオゲームを作りたいと思ったんです。すべてを描き出して「よし、やるぞ」と。でも実際には、BASICで絵を描くことからビデオゲームを作るまでにどれほど膨大な作業が必要か、全く理解していませんでした。
ええ。私もBASICをやり、小学校の終わりにTurbo Pascalをやりました。しかし、初めて本格的にプログラミングをしたのは、11歳の中学校1年生の時でした。
私は1年間イタリアのフィレンツェに住んでいて、素晴らしい1年でした。数学の先生が、亀が画面上で絵を描くLogoというプログラミング言語を使うように言ったのです。左右に向きを変えたりして、最終的にはそれを使って非常に複雑なプログラミングができました。いろいろなことができましたから。コンピュータやプログラムで何かをしたいと確信した瞬間でした。
H.264と動画圧縮技術の進化
H.264についてまだきちんと話していませんでしたね。dav1dについては話しました。少し戻って、インターネット上の基本すべての動画を支えているこれについて話しましょう。H.264の物語を教えてもらえますか。キーラン、あなたは実際にH.264の貢献者ですよね。
ええ。H.264はH.264ビデオ規格のためのビデオエンコーダです。インターネットの動画を支配していますが、Blu-rayディスクなどの他の分野でも使われています。Blu-rayディスクは面白いですよ。作っている人たちは本当に最高の品質を求めており、放送など様々な分野でエンコードされた非常にクールなハイエンドの映画がいくつかあります。
H.264は大きな飛躍でした。タイミングも良かったのです。開発の多くはHD動画が登場し始めた頃に行われました。Intel Core 2やNehalemといったCPUが高速化し、リアルタイムで動画を処理できるようになっていました。
しかし最も重要だったのは、視覚的な評価指標（メトリクス）への重要な焦点でした。それまでの20年間、産業界や学術界は、ピークS/N比（PSNR）や平均二乗誤差、平均二乗誤差の対数といった数学的な指標に固執していました。これが多くの問題を引き起こしました。平均二乗誤差を最小化しようとすると、大きなエラーを一つ出す代わりに、あらゆる部分に少しずつエラーを追加することになり、結果として大量のぼやけ（ブラー）が生じていたのです。
しかし、趣味の愛好家たちがそのトレンドに逆らいました。主にアニメなど、彼ら個人の動画のためのものでした。彼らは異なるアプローチをとり、コミュニティとの間で大規模な反復的フィードバックループが存在しました。彼らが変えた主なことは2つです。一つは心理視覚的レート歪み最適化（Psychovisual Rate Distortion）で、決定を下す際にブロックのエネルギーを利用し、人間の知覚を補正しようとするものです。
心理視覚的な歪みですね。それが重要なんですね。それはある意味、革命的です。「圧縮」というものを純粋な理論的なものとしてではなく、
人間の目に視覚的に心地よいものにするということですね。
ええ、私たち人間が重視する情報の損失が最も少なくなるような方法で圧縮するのですね。
はい、その通りです。産業界の一部はいまだに、現実には良く見えない数学的な数値に固執していますが。
そしてもう一つの大きな要素が適応的量子化（Adaptive Quantization）でした。これは、複雑な領域へのビット割り当てを減らし、草のようなそれほど複雑でない領域にビットを再分配するものです。草には高い周波数成分が含まれていますが、より複雑なものと比べると全体的にはそれほど複雑ではありません。
これは「ParkJoy」というサンプルによってもたらされました。ParkJoyは基準となるサンプルで、人々が公園を走り回っている映像です。
これですね。
ええ。これはHDの初期にスウェーデンのテレビ局によって制作されたもので、フィルムで撮影され、制作品質には一切の妥協がありませんでした。そして無料で提供されました。このサンプルはまさに真の力試しとなるもので、木々、水、草、動きなど非常に多くの課題を含んでいます。今日でもこれ以上に優れた公開テストシーケンスは存在しないと思います。
音声だけで聞いている方のために説明すると、川沿いをたくさんの人が走っている映像を見ています。水面の反射があり、葉っぱや、葉と光の戯れなど、情報量の多いテクスチャが至る所にあります。
高いPSNRを持つエンコーダーだと、すべてがぼやけてしまうのがはっきりとわかりました。
すべてをぼやけさせてしまうのですね。
ええ。しかし、心理視覚的な機能や適応的量子化をオンにすると、見た目がはるかに良くなるのがわかりました。しかし当時の評価指標は神聖不可侵なものと考えられていました。PSNRが最も重要だったのです。
心理視覚的なものをどのように測定するのか教えていただけますか。圧縮が人間の目にどれほど心地よく見えるかを、どのように数値化するのでしょうか。それは可能ですか。
NetflixがVMAFでやろうとしているのがそれです。彼らは機械学習モデルを使っていると言っています。
それは最近の話ですね。しかしx264が開発されていた当時は、基本的には人間の目で見ていたのですよね。
ええ、目視です。開発者たちが自分のノートパソコンで見ていました。大企業のようにプロ仕様のスクリーンを使っていたわけではありません。それが実は目標の一つでもありました。当時の開発者、特にローレン・メリットは「3万ドルのスクリーンでテストしたくない。家で普通のノートパソコンで見ている人の環境で良く見えるようにしたいんだ」と言っていました。
素晴らしい。
他にも、Planet Earthのキラーサンプルのようなものがあります。私が大好きなサンプルです。なぜだかすぐわかりますよ。
きっと気に入るでしょうね。
たくさんの鳥が飛んでいて、進むにつれて鳥の数が増え、最後には数百万羽の鳥がいるようになります。エンコードするのがこれ以上なく複雑な映像です。YouTubeでそれを見ると、YouTubeのエンコードがいかにひどいかがわかります。固定ビットレートで完璧な品質を最適化して得ることは本当に驚異的です。
特にローレンを中心とした多くの最適化がアニメに対して行われました。長い間、アニメはバンディング（色階調の縞模様）がひどく、エンコードが非常に悪かったのです。そういった問題に対処するために非常に多くのことが行われました。
現在でもx264は、AV1、AV2、VVC、HEVCなど、あらゆる新しいエンコーダーの基準（リファレンス）となっています。誰もが自分たちのエンコーダーをx264と比較します。
私の大好きな映画「ニュー・シネマ・パラダイス」のBlu-rayを作ったエンジニアを知っているのですが、彼はx264と他のエンコーダーの比較を見せてくれました。全く別物でした。Blu-rayの世界の多くの人がx264を使い始めました。ワーナー・ブラザースのクリス・ヘンダーソンも大きな存在で、「フリンジ」のボックスセット全体をそれで処理しました。一般の人が実際に見て、良く見えたいと思うような作品で。
彼らは大企業の中でその決断をするというリスクを負いました。大企業ならどんな高価なものでも買えるのに、「いや、顧客のために最高の品質を作りたいから、この無料でオープンソースのものを使いたい」と言ったのです。今日に至るまで、私個人としては、最も映画的な作品はストリーミングサービスを避け、物理ディスクを買うようにしています。高価なテレビを買わなくてもきれいに見えるからです。それが重要な点だと思います。
そしてx264はオープンソースプロジェクトのもう一つの例です。VLCが生まれたエコール・セントラル・パリにいたローラン・エルサムによって始まりました。その後、ローレン、ジェイソン、モンスなど多くの世代の人々が参加しました。
ヘンリックですね。
ヘンリック、アントン。
これが、現在FFmpegやdav1dなどで使用しているアセンブリ言語による最適化が生まれた場所です。x264は、世界中にいる人々による驚くべきプロジェクトであり、彼らのほとんどは互いに会ったことがないと思います。
AV1、AV2、そして次世代コーデックへの移行
しかし、キーランによれば、彼ら全員、あるいは大部分がアニメを愛しているとのことですね。私がこれまで触れてこなかったものの一つがアニメで、見なきゃいけないなと思っています。
当時、私はアニメを本当によく見ていました。当時は商業的に利用できないアニメコンテンツがたくさんありました。Crunchyroll（アニメ配信サービス）以前の話です。そのため、アニメが好きな人たちは日本でDVDを買い、商業的なサービスがないからとリッピング（吸い出し）していました。
そして、ファンスバー（ファン字幕作成者）と呼ばれる人々が自分たちで翻訳し、字幕を作っていました。当時は違法にダウンロードするしか方法がなかったのです。そのすべてが手作業で行われており、それがオープンソースコミュニティの性質と合致していました。エンコードやファン字幕作成のためのツールが必要だったからです。Aegisubと呼ばれる最も素晴らしいオープンソースの字幕プロジェクトの一つがあります。これは南アジアや日本語など、アニメの字幕のために作られたものです。
アニメには実写のコンテンツにはない独特のテクスチャがあります。通常の方法では制作されないアニメの奇妙なテクスチャを最適化することが重要な課題でした。
ええ。最近では画面上でデジタルで制作されることが多く、色のグラデーションがたくさんあります。デジタルで作り出すのは簡単ですが、実写で再現するのは非常に複雑なものです。
また、日本語を表示し、その上にダイアクリティカルマーク、つまり漢字に対する平仮名や片仮名の「ルビ」を表示しなければならないため、字幕も非常に複雑です。さらに公式の字幕だけでなく、英語やフランス語の字幕も必要とされました。彼らはそれを学びたかったからです。字幕に関するクレイジーな事例やサンプルはあちこちで見られました。これは文化の重要な部分でしたが、公式の提供手段がなかったという背景もありました。
H.264とAV1の違い、そしてx264とdav1dのこの大きな飛躍について説明していただけますか。ストリーミングサイトの一部がAV1の方向へ移行しつつあることを理解する助けになりますか。
正直に言うと、MPEG-2以降のこれらのコーデックはすべて同じ概念に基づいています。逆変換、イントラ予測、動き補償、エントロピー復号といった同じ概念です。しかし、各世代で同じ品質に対して帯域幅を25パーセントから50パーセント削減できるという向上が見られます。
MPEG-2があり、DivXの時代があり、そしてH.264があり、すべてを変えました。H.264は劇的に改善されました。その後、HEVCがあり、HEVCと同じ時期にVP9がありました。VP9は品質圧縮の点でHEVCに似ていますが、ロイヤリティフリー（特許使用料無料）です。
マルチメディアの世界には大量の特許があり、H.264以降、ライセンス料が手に負えなくなりました。年間数億ドルのコストがかかる可能性があり、理にかなっていませんでした。そこでGoogleがこのVP9を作り、Alliance for Open MediaがAV1という新しいコーデックを作りました。
AV1はH.264と比較して、同じ視覚的品質で帯域幅を40パーセントから60パーセント節約できると考えてください。
特定のビットレートにおいて、ですね。
特定のビットレートにおいてです。つまり、ビットレートを固定して品質を上げるか、品質を固定してビットレートを下げるかです。SDからHD、HDから4K、4Kから4K HDRへと移行するにつれ、ファイルサイズは2倍、3倍、4倍と大きくなります。そのため、管理可能な範囲に収めるためにより良い圧縮が必要になるのです。
コーディングツールが増え、ブロックが大きくなり、各ブロックのサブパーティションも増え、複雑さは指数関数的に増しています。
エンコーダがより多くの可能性を探索しなければならないため、より複雑になります。例えば、ある色のブロックを別のブロックから予測する際、方向があります。上下左右に加えて、「北東」「北西」など他の象限にも進めます。最初は8方向ですが、16方向、69方向、128方向へと増やしていくことができます。エンコーダは、どのツールがより良く圧縮できるかを確認するために、毎回より多くの時間を費やさなければなりません。
そのため、AV1のエンコードには、CPUサイクルの点でH.264の2桁ほど多い計算量が必要になると思います。桁違いですね。
ええ。しかも話したように、CPUの速度向上は鈍化しており、単にコア数を増やして対応している状態です。
しかし、一度エンコードすれば何億人ものユーザーに配信できるという事実もあります。例えばYouTubeは良い例です。YouTubeはほぼすべてをH.264でエンコードしますが、人気のある動画はAV1で再エンコードされます。エンコードには当然コストがかかりますが、一度エンコードすれば何百万人にも送信できるからです。
これは、エンコードの時間と複雑さ、サーバー側のCPU使用率とクライアント側のCPU使用率の間のトレードオフです。最終的に何十万もの人々に動画を配信する際、サイズが半分になればその方が良いわけです。バッテリーにも、モデムにも、すべてにおいて良いからです。
では、トップ5のコーデックとコンテナの組み合わせを挙げるとすれば、MP4コンテナ内のH.264、WebMやMP4コンテナ内のAV1、そしてノンリニア編集用のMOVコンテナ内のProResといったところでしょうか。知らない方のために、ProResについて教えてください。
これはAppleが元々Final Cut Proでの編集用に開発したコーデックで、デコードとシークが高速になるよう設計されています。編集者は動画を素早く移動する必要があるため、配信目的とは異なるユースケースです。
時間的圧縮が全くない、あるいは最小限なんですね。
ええ、ProResにはありません。だからカット編集ができるのです。
これが「イントラオンリー（フレーム内のみ）」と呼ばれるコーデックですね。IPBフレームとは何か、簡単に説明しましょう。
はい、お願いします。
Iフレーム、よくキーフレームとも呼ばれますが、これは完全なフレームです。一枚の画像、JPEGのようなものです。そこから始まり、すべてが見えます。次の画像はPフレーム、つまり予測（Predicted）フレームになることがあります。前の画像の一部、「ブロック5と7と42が必要だ」という情報を受け取り、それを置き換えて、追加情報だけを与えます。しかしこれは、このPフレームをデコードするためには、以前のIフレームにアクセスできなければならないことを意味します。
さらに複雑なのがBフレームです。これは双方向予測（Bipredictive）フレームで、過去のフレームだけでなく未来のフレームにも依存することができます。ProResはイントラオンリーのコーデックです。映像が見える方にとっては、これは非常に良い例ですね。Iフレームは完全なフレームです。Pフレームは基本的にIフレームにのみ依存し、Bフレームは前後のフレームに依存します。
そしてこのGOP（Group of Pictures）、H.264におけるFFmpegのデフォルトは250フレームくらいだったと思います。
はい。
私にとってはまさに魔法です。数秒ごとに完全なフレームを予測でき、一連の予測の連鎖を持ちながら、私のような人間がFFmpegを使って何かを圧縮しても、結果がスムーズに再生され、違いに気づかないというのは魔法のようです。
Kyberでも多用している「イントラリフレッシュ」という技術もあります。これにはIフレームが一切存在しません。
最初の一枚だけで、あとはIフレームを送らないのですか。
どのように機能するのですか。
ストリームが続くにつれて、段階的にIフレームを構築していくのです。
ああ、画像の特定の部分を徐々に更新していくのですね。
だからIフレームは決して存在しません。私たちが使っているイントラリフレッシュはそういうものです。
それはさらに賢いですね。
私にとって、始めた時に最も驚いたのはBフレームでした。Bフレームは、未来にやってくるフレームに依存できるというフレームです。つまり、このBフレームをデコードするためには、依存している次のフレームが来るのを待ち、バッファに保存し、それをデコードしてからでないと、Bフレームをデコードできないということです。
デコードの順序が、表示の順序と同じではないのです。エンコーダは非常に賢く、「未来のフレームに依存させよう」と判断しなければなりません。これは本当に信じられないほど驚異的です。
毎日これがこれほどスムーズに機能しているという事実は、ある意味奇跡的です。世界中の異なるメーカーのデコーダーでストリームが再生され、ビットレベルで正確に同じ出力が生成される。これは驚くべきことであり、非常に複雑な処理を行いながら、さらに複雑になってもビットレベルの正確性を保っている。そこには多大な労力が注ぎ込まれています。
このプロセス全体で制御できるパラメータはたくさんありますね。長年かけて私が理解してきた非常に興味深いパラメータがあり、FFmpegではそれらに完全にアクセスできます。いくつかについて話していただけますか。明らかに、解像度を下げたり、フレームレートを下げたり、H.264からAV1まで異なる種類のコーデックを使ったりできます。
ビットレートと品質のトレードオフを調整する方法もありますね。固定ビットレートにしたり、固定品質（RCQやQP）にしたり。前述のGOPを長くしたり短くしたり。そういったあらゆるカスタマイズが可能です。Bフレームの数も。
狂気じみているのは、そうしたパラメータを最適化することが仕事になっている人がたくさんいるということです。YouTubeやNetflix、Metaなどで、彼らはコーデックを書いているわけではなく、ただ手持ちのファイルやフォーマットに合わせて最適なパラメータを探しているのです。
映画用、スマートフォンからのユーザー生成コンテンツ用、画面録画用、動画編集用など、目的によって求めるものは同じではありません。そうしたすべてを最適化することだけを仕事にしている人が何千人もいるのです。
ええ。彼らは魔法使いです。脱帽ですね。YouTubeやすべてのストリーミングサイトは大規模に配信しています。YouTubeが本当に魔法のようなのは、Netflixのように一方向の放送を行うだけでなく、あらゆる場所からアップロードされた動画を処理しなければならないからです。たった5人しか見ないような動画であっても、大規模にエンコードを行っています。
しかも、要求があれば瞬時に配信しなければなりません。遅延なく、ごくわずかなレイテンシで。さらにすべての異なる解像度で提供する。YouTubeは事実上、VLCのウェブ版のようなものです。
ええ。面白いことに、YouTubeを買収する前にGoogleが展開していたGoogleビデオは、ブラウザ内でVLCを実行できるようにVLCのActiveXプラグインを使用していました。Internet Explorerで機能し、実際にブラウザ内でVLCを実行していたのです。
今日ではその逆で、VLCのWebAssembly版があります。VLCとFFmpegのすべてをコンパイルしてデコードし、JavaScriptの仮想マシン内でVLCを実行できるようにしています。
ソフトウェア特許という地雷原
特許について教えていただけますか。
通常、MPEGがフォーマットを作ります。すると皆が集まってきて「私はこのフォーマットに関する特許をたくさん持っている」と言い出し、彼らはMPEG LA（MPEGライセンス協会）と呼ばれる組合を作ります。すべての特許をそこに入れ、このフォーマットを使用する全員に使用料を支払うよう要求するのです。
ちょっと待ってください。コーデックの特許を持つとはどういう意味ですか。なぜそんなに多くの特許があるのですか。
例えば、正方形のブロックの代わりに長方形のブロックを使うというアイデアを思いついたとします。
ああ、あらゆるアイデアを誰かが特許化しているのですね。なんてことだ。一体何人の弁護士が…
多くの弁護士の給料を払うことになりますね。
最大の問題は次のようなことです。H.264の頃は、特許はまだ「まとも」と呼べるレベルでした。しかしそこに多額のお金が絡むようになったため、HEVCの時には、99.9%のケースで役に立たないような機能が仕様に大量に押し込まれました。ただ特許を追加するためだけにです。
その結果、HEVCのライセンスには、MPEG LAに加えてHEVC Advanceと呼ばれる別の特許プールが存在し、さらにNokiaなど一部の企業は特許プールの外にいました。
そのため、ライセンスを取得することは不可能になりました。数ヶ月前、HPがWindowsノートパソコンからHEVCのサポートを削除すると決定したのは、これらの特許コストが上昇していたからだと思います。
そして特許料の上限がない状態にまで至りました。YouTubeやNetflixにとっては、年間数億ドルもの特許ライセンス料がかかる可能性があります。彼らは「年間1億ドルも払うなら、自分たちでコーデックを作れるじゃないか」と考え、実行しました。これが、私たちが参加しているAlliance for Open MediaがAV1を作り、そしてAV2を作っている理由です。音声コーデックも作っています。
ええ。つまり主な違いはそこにあり、特許を回避するか、特許化されていない別の方法を考える必要があるため、多くの点が異なっています。30年前のMPEG-2で行われていた基本的な処理は、当然ながら特許の期限が切れています。しかし、例えば「ゴールデンフレーム」や「Sフレーム」といった異なる種類のフレーム技術などがあります。
これらはすべて特許化されたアイデアなんですね。
ええ。「Bフレームじゃないなんて信じられない」といった具合です。実質的にはBフレームのようなものです。ある意味では…
ああ、Bフレームの異なるバリエーションなんですね。
特許を回避しようとするためです。そういった類のことです。
ですから、二重の創造性が必要になります。より効率的になるための創造性と、既存の特許を侵害しないことを確認するための創造性です。例えばVVCは、HEVCのすべての特許に加えて新しい特許が含まれています。AV2が可能な限りロイヤリティフリーを目指しているのはそのためです。
FFmpegとVLCは、こういったことについてどの程度考慮しなければならないのですか。
私たちは考慮していません。VLCがフランスを拠点としている理由の一つは、フランスがソフトウェア特許を拒否しているからです。それらの特許のほとんどはフランスでは無効です。かつて計算したことがありますが、もしVLCのすべてのライセンス料を支払わなければならないとしたら、ユーザー一人当たり200ユーロ以上を支払う必要がありました。ドルでも同じくらいです。
しかし、これらの特許のほとんどはヨーロッパでは無効です。なぜなら、それらは数学的特許やアイデア特許と呼ばれるものであり、ヨーロッパでは有効ではないからです。
ヨーロッパにおける起業と規制の現実
大まかに純粋な好奇心からお聞きします。オンラインやX（Twitter）、私のヨーロッパの友人たちの間での一般的な認識として、ヨーロッパは起業家精神に優しくないと言われています。規制が厳しすぎ、官僚主義が蔓延していると。技術的な観点から見て、ヨーロッパの起業家精神の未来に希望はありますか。肯定的な側面はありますか。
私たち2人を見てください。動画について語るこのポッドキャストに、ヨーロッパ大陸から2人の人間が参加していることは注目に値します。コミュニティの比重は重いと言えるでしょう。
おそらくまだ目立っていませんが、ヨーロッパ、特にフランスには新しい世代の起業家たちがいます。イギリスはよりアングロサクソン的なビジネス感覚を持っているので昔からそうでしたが。フランスで起きたことは（フレンチテックなどと呼ばれて少し過剰に宣伝されることもありますが）、今日市場に出てくる人々のほとんどがスタートアップを作りたいと考えているということです。
15年前はそうではありませんでした。皆、大企業で働きたいと思っていました。例えばフランスで20年前、15年前に会社を潰した場合（スタートアップでは普通のことですが）、新しい会社を作ることが許されなかったからです。大きな烙印（スティグマ）がありました。今ではそのスティグマは消え去りました。
フランスではAIなど様々な分野で多くのことが起きています。もちろん過剰な規制があることは知っています。私は起業家ですから。しかし、良い面もあるのです。
動きを麻痺させるような側面はありませんか。親しくなったパヴェル・ドゥーロフのケースを見ると、彼は自分の「プラットフォーム」がホストしているコンテンツを理由に、フランス政府から直接非難されました。これと同じようなことが、例えばVLCが再生している動画の種類を理由に非難されるといった形で起こり得るのではないかと思います。
しかし、彼らは試みましたよ。私たちにも問題はありました。
そのプレッシャーこそが人々が心配することです。技術的なことだけに没頭したいのに、そういったことまで考えなければならないとなれば…
いや、考えませんよ。それでいいのです。
でも、もし彼らがやって来たら？
オフィスはありません。VideoLANにオフィスはないのです。
パヴェルの身に起きたのはそういうことでした。彼らはパヴェルを逮捕しました。プラットフォーム上で共有されている特定の動画やコンテンツを理由に逮捕したのです。
ええ。でも私にはプラットフォームはありません。すべてはクライアント側で行われています。
ええ、でも彼らはあなたを逮捕することができます。
何の法的根拠でですか？私は何も共有していません。コンテンツは私のところを通過していません。
確かにそうですが、それでも弁護士費用はかかります。それが問題です。
ええ、それはその通りです。
書類手続きの問題です。もし無限の資金があれば、あなたは正しい側にいるのだから簡単に勝てるでしょう。しかし問題は、彼らが書類手続きやプロセスを通じてあなたを窒息させる程度に追い込むことができるということです。それが官僚主義の弊害です。
フランスやヨーロッパの多くで良いことの一つは、裁判所の命令に応じることで破産するようなことはないということです。アメリカのように実際に破産に追い込まれるようなシステムではないのです。私は毎週弁護士から手紙を受け取りますが、VideoLANの弁護士費用は年間1万ドル未満です。
だから、それほど怖いことではないのです。
VLCのセキュリティとサンドボックス化の挑戦
WikiLeaksが公開したVault 7の文書によって発覚した伝説的な話があります。CIAが、人々のデータを盗むためか何かで、改ざんされたバージョンのVLCを使用していたそうですね。一体何が起きたのか説明してもらえますか。
ええ、これは驚きでした。ある時WikiLeaksがいくつかの文書に言及しました。Blu-rayとVLCに関連するものもいくつかありましたが、最も興味深かったのはCIAのVault 7でした。私の理解が正しければ、CIAは特定のプラグインを備えたカスタムバージョンのVLCを持っていたのです。ええ、まさにその通りです。私たちはこれについてプレスリリースを出さなければなりませんでした。
VideoLANは「VLCメディアプレイヤーを入手する唯一の安全なソースは、公式のVideoLANウェブサイトだけである」というプレスリリースを出しました。しかし、これは実質的にすべてのオープンソースソフトウェアに当てはまるセキュリティの脆弱性だと思います。誰かがあなたを騙して、偽のウェブサイトやターゲット広告からダウンロードさせる可能性があるということです。
特定のファイルを視聴するためには、このカスタムバージョンのVLCが必要だというターゲット広告でした。それはVLCの通常のバイナリでしたが、1つのDLL（おそらくpsapi.dllだったと思います）を追加していました。それが基本的にユーザーのドキュメントフォルダを読み取り、暗号化して送信していたのです。
これは非常に巧妙でした。正直なところ、映画を見る時は2時間ほどコンピュータに触れませんし、HD動画を再生しているためにファンがフル回転してCPU使用率が上がるのは普通のことだからです。ユーザーが気づかないうちに、CIAが使用している特別バージョンのVLCが裏で動いていたのです。
中国のハッカーがインド人をターゲットにした時も全く同じ問題がありました。その結果、私がインド政府を相手に法廷で争って解除を勝ち取るまで、VLCはインドで禁止されていました。彼らはVLC全体を利用したわけではありません。私たちが正しく署名した1つのDLLだけを抜き取り、それを使って別のプログラムを作ったのです。vlc.exeがあり、libVLCを呼び出していますが、それが偽のモジュールを呼び出していました。それを標的型攻撃に使用したのです。
こうした種類のハッキングを防ぐために私たちができることは、実はあまりありません。
ええ。ですから人々はすべてのソフトウェアをダウンロードする際、どこからダウンロードしているかに注意を払うべきです。
ええ。彼らが私たちの公式ウェブサイトからダウンロードしていなかったということですから。
検索エンジンは助けになりませんか。
全くなりません。
念のため確認しますが、SEOを操作してリンクの上位に表示させ、騙そうとする脅威を防ぐための助けには…
全くなりません。私たちは10年以上前から大きな問題を抱えています。ドイツに12年前から報告されているVLCの偽バージョンがあるのですが、Googleは意図的に何もしないことを決定しています。彼らはその中に何が含まれているか知っていますが、バイナリサイズが大きすぎて彼らのウイルス解析ツールで解析できないのです。
ドイツにいる場合、偽のバージョンのVLCを配布しているウェブサイトにアクセスでき、彼らのウェブサイトはドイツ語であるためドイツで非常に人気があります。GoogleはVideoLANよりも先にそれを検索結果の上位に表示していました。
最も奇妙なのは、インストールしてから3週間はユーザーのマシンで何もしないということです。それが彼らの検知回避方法なのです。3週間経つと、同時にインストールされたサービスプログラムが目を覚まし、スパイウェアやアドウェアをダウンロードし始めます。Googleはこれを知っているのに、何もしないことを決めたのです。彼らはある時点でダークSEOを使ってドイツでそれを広めました。これは非常に被害が大きいです。ダウンロードされるものの一つが、マシン内の広告をすり替えるプログラムだからです。
これって驚くほど効果的なんですよね。Twitter（X）で私のアカウントがハッキングされたというメールを受け取ることがありますが、その文面を見ると、クリックしてはいけないとわかっていても、ついクリックしそうになります。「彼らがどんな心理的テクニックを使っているにせよ、人間を騙すのがかなり上手い」と思い知らされます。
VLCのセキュリティアップデートを装う手口もあります。「VLCのセキュリティアップデートがあります。コンピュータがハッキングされる可能性があるので、すぐに更新してください」というメールを受け取り、一見ちゃんとしたウェブサイトを訪れてダウンロードする。新しいバージョンのVLCだと思って安心していると、1ヶ月後にはハッキングされ、知らないうちにボットネットの一部になっているのです。
恐ろしいですね。皆さんもダウンロード元が正規のものか必ず確認してください。ボットネットの一部にならないように。
関連して、VLCのサンドボックス化に取り組んでいるとおっしゃっていましたね。これは非常に挑戦的な課題のようですが、なぜ重要で、なぜ難しいのでしょうか。
VLCはコア部分と約500のプラグインで構成されています。FFmpegもその一つですが、私たちは非常に多くのフォーマット、新しいプロトコル、新しいフィルター、特殊なアーキテクチャをサポートしています。現在のVLCでは、ドライバー、主にIntelやNVIDIA、AMDのハードウェアデコーダーを呼び出すモジュールがあり、それらがさらにFFmpegを呼び出しています。
シェーダーやVLC、FFmpegの中にセキュリティの脆弱性があり、クラッシュを引き起こす可能性があります。問題は、VLCがAdobeなどの他のプログラムと同じようにマシン上で実行され、すべてのドキュメントへのアクセス権を持っていることです。
そこで、自分たち自身から保護するためにサンドボックス化しようとしています。VLCプロセス内部では、私たちのものではないコードが実行されているからです。VLCに統合した他プロジェクトのオープンソースコードであったり、誰かが提供したGPUドライバーであったりします。クラッシュした時に、悪意のある行為を許したくありません。プログラムをクラッシュさせるのはハッキングの一般的な手段だからです。ウェブブラウザやPDFファイルでよく行われますが、マルチメディアでも起こり得ます。クラッシュした際に、ユーザーのマシン上でランサムウェアやボットネットなどが起動してしまうのを防ぎたいのです。
デスクトップアプリケーションのセキュリティは重要です。モバイルの場合は大半のアプリが独自のサンドボックス内で実行されるため少し状況が異なります。VLCを1つのサンドボックス内で実行することは可能ですが、非常に多くの機能へのアクセスが必要なため、結局すべての権限を与えることになり、穴だらけのサンドボックスになって目的を果たせません。
そこで私たちが実際に取り組んでいるのは、VLCを複数のプロセスに分割することです。デコード、デマルチプレクス、フィルターなどをそれぞれ独自のサンドボックス内で実行します。そうすれば、Chromeの一つのタブがクラッシュしてもプログラム全体がクラッシュしないように、VLCの一部がクラッシュしても全体には影響しません。
これが難しい理由は、このサンドボックスが毎秒ギガビット単位のメモリコピーに耐えなければならないからです。5MBや10MBのウェブサイトではありません。数百メガビット/秒のデータを扱うため、非常に挑戦的です。安全なマルチメディアプレイヤーを実現するための研究課題として取り組んでいます。
これは何百万人もの人々が使用する際に考慮しなければならないことですね。VLCのあらゆる機能について、「多くのユーザーがいれば、すべての機能が誰かによって使われ、それについてフィードバックが来る」とどこかでおっしゃっていましたね。
VLCの最高の機能は「パズルフィルター」です。このフィルターをクリックすると、動画がジグソーパズルに変わります。
面白いですね。
クリックしてピースを動かせるんです。退屈なフランス映画や愛憎劇を見ている時なんかにとても便利ですよ。見なさいと言われたから見ているけれど、という時にピースを動かして遊べます。全くもって役に立たない機能ですが。
元々は南フランスの高校の数学教師が、生徒にベジェ曲線を教えるために作ったものでした。コードがきれいだったので2010年にVLCにマージされました。その5年後、「JB、VLCに問題があります。パズルが簡単すぎます」というメールを受け取りました。「えっ？」と思いましたよ。パズルのピース数は最大16×16の256ピースでした。彼は「私はパズルを愛しているのですが、この映画で256ピースは簡単すぎます」と言うのです。それで、私が上限を256×256に変更したコミット履歴がオンラインに残っています。
なるほど。
言いたいのは、使われていないと思われる機能でも少数の人が使っているということです。ユーザーインターフェース（UI）を一切使わずにコマンドラインでVLCの動画を見る方法もあります。アスキーアートで表示するんです。
見ました。アスキーでできるんですよね。
アスキーアートです。役に立つかって？非常に役に立ちます。複雑なマルチキャストネットワークのデバッグをしていると想像してください。数千ものルーターにSSHで接続し、UIなしのVLCを実行して、画面が黒いか黒くないか、すべて緑色かそうでないかを確認できるのです。
すごい。
VLCには人々が気づいていない便利な機能がたくさんあり、実際にユーザーがいます。何億人ものユーザーがいれば、すべての機能を使う人が現れるのです。
ネットワーク上の動画ストリーミングの課題
ファイルをダウンロードしてオフラインで見るのと、ストリーミングで見るのとの違いについてもう少し詳しくお話ししたいと思います。ストリーミングの複雑さや課題について。これまではネットワーク通信を伴わないエンコードやデコードの意味合いが強いコーデックについて話してきましたが、ネットワーク経由での処理に必要なことについて詳しく教えていただけますか。
ええ。しかし、これまでに話してきたことに比べれば、皆さんが思っているほど複雑ではありません。特に最も複雑だったのは、現在のストリーミングサービスの話ではなく、過去に衛星を通じて放送を行うために行われていたことだからです。
現在の最新の放送サービスでは、一時停止したり再開したりできますが、テレビ放送やライブ配信などのライブストリーミングを送信する場合、リアルタイムでエンコードしなければならないため、はるかに困難になります。衛星を使用する場合、リンクのサイズは決まっています。ファイル全体でスペースの余裕がないため、一瞬であっても帯域幅をバースト（急激に超過）させることはできません。
様々な種類の課題がありますが、90年代後半から2000年代初頭の衛星を通じた放送やストリーミングで見られた課題に比べれば、複雑さは低いと思います。
性質が違いますね。前者は制御システム的な課題ですが、後者はより数学的な課題です。その違いだと思います。
ストリーミングの世界では、「アダプティブストリーミング（適応型ストリーミング）」と呼ばれるものがあります。難しさは動画自体の問題というよりCDN（コンテンツ配信ネットワーク）の問題で、同じ時間にあまりにも多くの人が同じコンテンツを視聴するとネットワークが輻輳（混雑）してしまうことです。プレイヤーが再生に間に合う十分な速度でデータをダウンロードできなくなるのです。
そこで何が起きるかというと、プレイヤーはローカルで低解像度のデータを読み込み始めます。これを行うための非常に賢いアルゴリズムもありますが、ほとんどは非常に基本的なものです。
バッファリングの面でもかなり基本的なことですね。
セグメント（データの断片）のダウンロードを開始し、時間を計測します。セグメントのダウンロードに時間の50%以上かかっている場合、解像度を下げます。難しいのは、いつ帯域幅や品質を上げるかという判断です。しかし、これもそれほど複雑ではありません。
エンコードする際、7つの解像度でエンコードし、ビットレートを指定します。難しいのはエンコーダに同じビットレートを維持させることですが、以前ほど厳密ではありません。
YouTubeなどは、人間の心理的な側面を理解しなければならないでしょうね。非常に低いビットレートになった時、視聴者がどれくらいイライラするのか。接続状況が改善しても、ビットレートを上げる前にどれくらい待つべきか。ビットレートの頻繁な変動が心理的な影響を与えるかもしれませんから。
実は動画よりも音声の方が興味深い問題だと思います。
確かに。
フル機能のAACから、SBR（Spectral Band Replication）を使用した圧縮バージョンのAACに移行すると、音が少し金属的（ティンニー）になるのが分かり、その上下の変動は非常に不快に感じます。動画の変動はずっと滑らかで気づきにくいですが、音声プロファイルが変更された時は確実にはっきりと感じ取れます。
不思議なことに、私たちは音声のグリッチ（乱れ）よりも映像の乱れには寛容です。動画エンジニアではない一般の人々が、本来60FPSであるべきスポーツの試合を30FPSで見てもそれほど気にしないことに驚かされます。しかし音声に関しては、人々は非常に敏感で、「あ、何かが変わった」と即座にフィードバックするメカニズムを持っています。
グリッチが聞こえるとすぐに気づきますからね。私もそれを実感します。音声をより注意深く聞くようになると、あらゆる細部に気づくようになり、過剰にこだわりすぎてしまうのではないかと恐れることがあります。一般の人は消費するコンテンツをある程度ぼかして受け止め、不完全さを見過ごすことができるのですが。
しかし、例えばスポーツの試合のようなイベントで、衛星などを経由してエンコード用のセンターに送られ、そこで古い解像度も含めてすべてをリアルタイムでエンコードしなければならない場合を想像してください。QA（品質保証）のテストをしている時間はありません。すぐにCDNにプッシュし、保護のためにDRMを追加し、多種多様なデバイスに配信しなければなりません。それは確かに複雑なプロセスです。
また、エンドツーエンドで制御できるケーブルテレビのセットトップボックスのような特定のデバイスだけでなく、ウェブブラウザや様々なデバイスに対応しなければならないという課題もあります。しかし、10秒や20秒の遅延（レイテンシ）を許容できるのであれば、ネットワーク部分はそれほど難しくないと思います。
Kyber：超低遅延が切り拓くロボティクスの未来
ネットワーキングと低遅延（レイテンシ）に関連して、あなたの新しいプロジェクトである「Kyber」について教えてください。「すべてのミリ秒が重要だ」とおっしゃるように、超低遅延を目標とし、ロボットやドローン、コンピュータなどのリモートコントロールに適用しようとしていますね。
ええ。昔の状況から振り返ってみましょう。かつてはファイルとして保存するためにFFmpegを使ってエンコードしていました。その後、FFmpegとVLCを使ってストリーミングサービスのためのエンコードを行うようになりました。そして、さらに遅延を短くしていく必要がありました。問題は「どこまで低遅延にできるか」ということです。
この問いは非常に重要です。なぜなら、フィードバックを伴うインタラクションが必要なユースケースにおいて、高速性が求められるからです。単に映像を見るだけでなく、実際に機械を操作する場合です。これまでの用途との最大の違いは、ライブで起きている事象に対するフィードバックとして映像が必要になるという点です。ドローンの操縦、遠隔地からのヒューマノイドロボットの操作、クラウドゲーミングなど、ネットワークを限界までプッシュする興味深いテーマです。以前の仕事でクラウドゲーミングのスタートアップのCTOをしていましたが、そこでは映像の品質よりも遅延が重要になります。車を操作するような場合、1ミリ秒が極めて重要だからです。
Waymo（自動運転車）を利用したことがあるならわかると思いますが、自動運転が機能しない場合（たとえそれが1パーセントの確率であっても）、遠隔から誰かが操作することになります。私たちが構築しているのはまさにそのためのものです。機械のエンドツーエンドの制御を行うためのSDKプラットフォームです。
これはロボティクスの様々なコンテキストでよく話題になりますね。機械学習を通じたロボットの訓練などにおいて、テレオペレーション（遠隔操作）の重要性がますます高まっています。
はい。私たちが他と異なるのは、UDPベースのQUICプロトコルという単一の接続（ソケット）を使用している点です。これは低遅延のために設計されており、TCPやHTTPにおける「ヘッド・オブ・ライン・ブロッキング（先頭パケットの遅延が後続すべてを遅延させる問題）」を回避できます。デフォルトで暗号化されており、同じ回線上で音声、動画、そしてマウスやキーボード、ゲームパッドなどの制御コマンドといった複数のストリームを同時に送信します。
そして、それらを「コヒーレンス（同期性）」を保ちながら行います。人々が気づいていないのは、すべての時計（クロック）は実際にはズレていく（ドリフトする）ということです。ロボットを制御する際、ロボットには2つ、5つ、10つといった複数のカメラや、GPSなどの大量のセンサーが搭載されています。ロボットのAIモデルを正しく訓練するためには、それらすべてが同期している必要があります。
私たちがVLCでのリアルタイム放送やMPEG-TS（キーランがよく知っていますが）から学んで実装したのは、クロックドリフトを考慮した仕組みです。Kyberのストリームを録画する際、再生時にそれが予測可能であることを保証します。AIモデルの録画と訓練を行う際、そのデータに基づいて再訓練するたびに、データが同期した一貫性のある状態を保つようにしなければなりません。既存のソリューションは1台のカメラでは機能しますが、5台、6台となるとより複雑になります。
なるほど、視覚的なスナップショットが実際に起きた時間と完全に一致するようにしたいのですね。
その通りです。またロボットを制御する際、自分が行った操作が正確にその時間に実行されていることを確認する必要があります。そこでサーバー（ロボット側）に、クロックドリフトを補正してタイムスタンプを付け直すメカニズムを持たせています。
これがKyberのユースケースの一つ、ロボットの制御です。他にも、遠隔操作のドローン（防衛目的か否かを問わず）、遠隔操作の車や潜水艦、あるいは危険であったり費用がかかりすぎたりして専門家が直接現場に行けない遠隔手術など、多くの産業分野が考えられます。機械を自分のすぐ隣にあるように操作できるようにするのです。
Kyberの目標は、スキルの投影であれ力の投影であれ、距離という概念を消し去ることです。例えばMetaのRay-Banなどのスマートグラスを皆がかけていると想像してください。そこへストリーミングする必要があります。グラス側で重い処理を実行することはできないため、クラウドやスマートフォンのGPUパワーを使ってストリーミングすることになります。
これらのユースケースすべてにおいて、単なる低遅延ではなく、動画におけるリアルタイム性が求められます。そのため、エンコーダーが1フレームを4ミリ秒でエンコードできるように調整しています。キーランの会社もそうした低遅延を実現していますが、ローカルでの遅延（エンコードとデコードの時間）を極限まで最適化する必要があるからです。この時間がネットワークの遅延に加算されることになりますから。
低遅延だけでなく、信頼性も重要です。前方誤り訂正（Forward Error Correction: FEC）のような賢い手法を使います。数パーセントのデータを余分に送信することで、パケットの損失を許容できるようにします。遠隔地とインターネットを介して通信する場合、すべてのパケットの到達を確認しようとすると多大な遅延が発生してしまいます。遅延を避けつつ、データが破損した際にクライアント側で復元できるように、少し多めにデータを送るのです。
数週間前、ラスベガスで開催されたCESでデモを行いました。完全に3Dプリントされたローバー（探査車）で、伸縮式のアームを備えた小さな車です。これをフランスから遠隔操作しました。ウェブカメラの映像と、小さな基板（PCB）で動くサーバーが地球の裏側にいる人にデータを送信しました。
ドローンの群れをAIが制御するといったことも考えられます。技術的には、動画処理、ネットワーキングにおいて卓越している必要があり、エンコード、デコード、ネットワークのあらゆるミリ秒単位の遅延を気に掛け、さらに極めて低いレベルでの統合が必要です。
すべてをうまく同期させるのですね。具体的にどれくらいの遅延を達成できるのですか。ミリ秒単位と言う時、目標はどのくらいですか。
私の目標は、Glass-to-Glass（カメラからディスプレイまで）の遅延で4ミリ秒です。
Glass-to-Glassとはどういう意味ですか。
例えばロボットでビデオゲームを動かしているようなプログラムを実行するコンピュータがあり、ネットワークを介してそれを複製して表示するような場合です。1000ヘルツのカメラで映像を撮影し、それを4ミリ秒で届けたいということです。4ミリ秒というのは240ヘルツに相当します。
すごいですね。
これまでのところ、Windows間、あるいはWindows-Mac間で7ミリ秒を達成しています。内訳を見ると、NVIDIAのハードウェアエンコーダーで約3.5ミリ秒、Intelのデコーダーで約2ミリ秒かかっています。エンコーダーとデコーダーだけで既に約6ミリ秒を消費しているため、さらに短縮するには他の種類のコーデックか、より高速なエンコーダーが必要です。4ミリ秒に到達できれば、まさに聖杯（究極の目標）と言えるでしょう。
狂気じみていますが、素晴らしいですね。これまで誰も達成していないのではないですか。驚異的な速さです。
SDIのような専用のプロ用ハードウェアを使えば達成可能です。しかし、私はそれをインターネット経由で機能させたいのです。Jetson Nanoのような小さなボードを積んだどんなロボットでも機能するようにしたい。車輪で走るロボット、空を飛ぶロボット、泳ぐロボットなど、何百万台ものロボットが登場する未来が来るからです。
それらをテレオペレーション（遠隔操作）するか、完全自律型になった時にはテレオブザーブ（遠隔監視）する必要があります。未来の自動運転車はすべてAIモデルによって遠隔監視され、問題がないかチェックされるようになるでしょう。問題が起きた時だけオペレーターが介入する。これは安全に関わる問題です。
ヒューマノイドが祖母の介護をする時、すべてが順調であることを確認したいですし、ロボットが危険をもたらすような恐ろしいシナリオは避けたいです。自分が運転している時も、止まるべき時に止まってほしいし、必要なら誰かが介入してほしい。リアルタイム性が求められるシナリオは無数にあります。機械のリアルタイム制御において距離という概念をなくすことがKyberの目標です。
信じられないほど素晴らしいですね。私たちが今日話してきた技術やアイデアが、まさにあなたが取り組んでいることに繋がっている。
私にとってこれは驚くほど挑戦的です。動画についてはある程度わかっていますが、ネットワークに関してはまだ学ぶべきことがたくさんあります。輻輳制御プロトコルや、リアルタイムのビットレート適応などです。でもとても楽しいです。
このプロジェクトのためにアメリカで資金調達を行いました。しかし、これはオープンソースです。まだ言っていませんでしたが、これは重要なことです。Kyberのすべてはオープンソースなのです。
どうやって利益を生み出すのですか。
デュアルライセンスモデルです。商用ライセンスとAGPLです。先ほどライセンスについて話したのを覚えていますか。
基本的に、Kyberを製品に組み込む場合、その製品全体をオープンソースにしなければなりません。この素晴らしい技術を使いたいけれどオープンソースにはしたくないという場合は、商用ライセンス料を支払う仕組みです。ですから、趣味で使う個人や小さな開発チームは無料で技術を利用でき、オープンソースでクールなものを作ることができます。
それは素晴らしいですね。
大企業であれば、サポートや知的財産権の保証、適切な修正対応などを受けるために商用ライセンスを選ぶでしょう。私も実際に3Dプリントされたローバーや翼のドローン、ヨットなど、ロボットの製作を楽しんでいます。もちろん私たちはロボットの専門家ではありませんが、誰もがロボットを作れるように支援するためにここにいるのです。
デジタル遺産のアーカイブと保存
キーラン、活発なアーカイブ（保存）コミュニティがあると言っていましたね。非常に興味深いです。予算は限られているものの、1000年後にもマルチメディアが再生できるように、FFmpegをロゼッタストーンのような極めて重要な存在として見ていると書かれていました。FFmpegやVLCを、視覚的知識を保存するためのツールとして捉えるというのは美しい考え方です。
はい、その通りです。オープンソースマルチメディアにおける最もクールなコミュニティの一つで、主にニューヨーク市立大学のデイブ・ライスという人物が率いるアーカイブコミュニティがあります。彼らは多くの素晴らしいことを成し遂げてきました。
彼らがオープンソースを評価する理由は、一つには予算不足もありますが、動画のアーカイブが世界にとって重要であると認識しているためです。そして、それを再生できるようにすることが大きな課題なのです。有名な話として、イギリスの「新ドゥームズデイ・ブック（New Domesday Book）」というプロジェクトがあり、BBCマイクロコンピュータに大量のデータをアーカイブしましたが、10年か15年後にはそれを再生できる適切なソフトウェアが誰の手にもなくなってしまいました。20年後くらいに誰かがそれをリバースエンジニアリングしなければなりませんでした。1000年後を想像してみてください。
FFmpegの素晴らしい点の一つは、C言語で書かれていることだと思います。C言語はおそらく、数学や論理学に最も近い言語です。
1000年後もCコンパイラは存在すると思いますか。
はい。あまり変化していない言語というものは存在します。数学的な表記法も存在し続けています。C言語はラテン語のような存在になるでしょう。過去から学ぶものでありながら、特定の文脈では依然として使用可能なものとして残るはずです。
アーカイブコミュニティの人々は非常に実践的です。限られた資金の中で、FFV1コーデック（ロスレス（無劣化）コーデック）の開発に資金を提供しました。アーカイブコミュニティは、圧縮行為によって情報が失われることを非常に恐れています。これはもっともな懸念です。強く圧縮しすぎると素材の見た目が変わってしまい、わずかな違いが生じる可能性があるからです。
そのため、彼らは単に圧縮率だけでなく、ロスレスであり高速であることを重視しています。彼らはFFmpegと協力し、高速なソフトウェアベースのエンコーディングのために設計された全く新しいコーデックを開発しました。
また、回復力（レジリエンス）にも強い関心を持っています。テープやハードディスクに保存していて一部のビットが失われた場合、素早く復元する必要があります。1ビット失っただけでGOP全体を失うわけにはいきません。
彼らは本当に素晴らしい人々です。FFV1のエンコードを高速化するためにFFmpegのGPUエンコーディングにも資金を提供しました。これは世界中のマルチメディア遺産を使用可能な形で保存することに関する取り組みであり、世界中の多くのアーカイブ機関がアーカイブソリューションとしてFFmpegとFFV1を選択しています。
彼らは私たちに超専門的なアドバイスも提供してくれます。「1950年代のこの特定のテープでは、色彩測量（カラリメトリー）がこういう方法で行われていたから、この特別なケースを処理する必要がある。他では絶対に手に入らない情報だよ」と教えてくれるのです。
私たちが知らない動画に関する知識を彼らは持っています。英国映画協会のデイブなどと話すたびに、私は20年間動画に携わっているのに、常に新しいことを学んでいます。特に色彩測量や色に関して彼らは深い知識を持っています。
保存媒体などについてもですね。彼らはコンテンツそのもの、動画そのものに対して深い敬意を払っています。ロスレスについて考える時、彼らはその作品の「本質的な何か」が失われることを恐れています。そのため、保存されるべき対象について極めて深く理解しようと努めているのです。私たちがエンコーディングなどの技術そのものに夢中になっている時に、見落としがちな視点です。
フィルムスキャナーのウサギの穴（奥深い世界）に入り込むと、それをデジタル化するためのトピックだけでさらに5時間ポッドキャストができるほどです。
フィルムのアーカイブは重要です。フィルムは劣化しており、適切な環境で保存されていないこともあります。また、彼らはオープンソースであるため、アーカイブ機関を持つ資金がない国々にワークフローを無償で提供しています。インドなどで子供たちにFFmpegのコマンドの使い方を教えたりしています。
彼らは私たちが達成しようとしている理念の模範的なコミュニティです。自分たちの行っている作業が1000年後に多くを語ることを理解しているため、より大きな目的に参加することに強い関心を持っています。1000年後、私たちはAIが生成した大量の無価値なデータ（AIスロップ）に溺れているかもしれませんが、これらの記録は「過去の生活がどのようなものだったか」を知るために重要であり、適切にアーカイブされる必要があります。
20世紀と21世紀を記録することは不可欠に感じます。データの希少性から、海のようなAIスロップへと移行する転換点だからです。その転換点をアーカイブしておくことは良いことです。
人々は気づいていませんが、今日私たちは多くのフィルムを失い続けています。30年代、40年代、50年代のフィルムで、修復する価値がないと判断されたものが失われています。
テープもそうです。70年代、80年代のテープをすべて読み取るだけのテープヘッドが世界中に残っていません。そのため、何をアーカイブし、どのテープを捨てるかを決定しなければなりません。人類の歴史のデジタル記録について、そうした決断を下さなければならないことに、道徳的な危うさ（モラルハザード）を感じます。世界中の誰もが再生可能な形でこの情報を持てるようにするための、デジタルスチュワードシップ（適切な管理体制）が必要です。
現実的に言えば、大量の映像をアーカイブすることには干し草の山から針を探すような価値があり、時間が経ってから、そこにあるとは知らなかった宝石を見つけることになるのでしょうね。
「あの隅っこに、今まで気づかなかった何かがあるぞ」というように。
もし圧縮されていたら、些細なこととして消し去られていたかもしれない。「おお、あそこに何かある」と発見できるのです。
ええ。だから彼らはそれがロスレスであることを確認しています。数学的にロスレスであることを証明できるのです。単一のビットが反転した場合でも、特定のフレームの一部だけが失われるようにするトレードオフを実行できます。過去のフレームからエラー回復を行うなど、様々なことができます。
VLCとFFmpegは100年後も存在していると思いますか。
FFmpegはイエスです。VLCは、どうでしょうか。
FFmpegはどこへ向かっているのでしょうか。VLCはどこへ。5年、10年、20年先を考えた時。
5年、10年先は簡単です。問題はその先です。私たちが「ホログラム」と呼ばれるものに到達するのかどうか。
ええ、VLCやFFmpegはマルチメディア全般へと拡張していくのでしょうか。
マルチメディアとは何かという定義に立ち返る必要があります。マルチメディアとは、人間の感覚に向けた複数のストリームのデジタル表現です。私たちはそれに対応していくでしょう。
突飛な飛躍で申し訳ないのですが、Neuralinkのような脳波コンピューターインターフェース（BCI）を考えると、マルチメディアの意味するものが、私たちの脳が直接消費したいと思うようなコーデックやデータになる可能性が非常に高いです。
Neuralink用のVLCができるでしょうね。
ええ。「FFmpeg -i 入力フォーマット:人間の脳」みたいに。
脳のためのコーデックができるでしょう。間違いありません。
今日でも新しいコーデックは誕生しています。例えば点群（ポイントクラウド）やボリュメトリックビデオなどです。RGBD（深度情報付きRGB）に関する多くの研究があり、ロボティクスや3Dに有用な深度コーデックが存在します。
VLCにはすでにVR版やXR版がありますし、KyberでもApple VisionやQuestなど十分な処理能力を持たないグラス向けにXRコンテンツのストリーミングを行っています。3D、XR、インタラクティブ、低遅延のストリーミングには既に取り組んでおり、ボリュメトリックビデオや点群ビデオなど、立ち止まることはありません。いずれVLCやFFmpegの内部で3Dデータを管理するようになるのは明らかです。
コミュニティの誰もがそう見ているわけではありませんが、キーランと私は起業家なので、それがどこへ向かっているかが見えています。
FFmpegの内部には緊張感があるのではないかと推測します。「おいみんな、俺たちは動画と音声で素晴らしい成果を出しているんだから、なぜ拡張するんだ？得意なことに集中しようぜ」というような。
その質問に答えるには、マルチメディアの定義に立ち返らなければなりません。もしマイクの代わりに匂いセンサーと匂いのディフューザーが登場すれば、それはFFmpegに組み込まれるでしょう。
匂いのデマルチプレクサですね。
ええ。デマルチプレクサに「匂い」という新しいトラックタイプが追加されます。音声のようなものです。左右の鼻のトラックがあり、ステレオの匂いになるでしょう。
VLCにはすでにハプティクス（触覚）のためのプラグインがあります。主にテーマパークにあるような、油圧アームで座席が動く「4Dシネマ」用のもので、物理的な動きの情報を転送するための同期されたデータフィードがあります。それは通常バージョンのVLCには入っていませんが。
それに関する標準規格はすでにあるのですか。
多くの標準規格があります。人間の感覚の一つですから、組み込まれることになるでしょう。
とてもエキサイティングな未来ですね。しかし、開発者のコミュニティは小さいのに、どうやってそれを成し遂げるのですか。Twitterを見ていると、FFmpegやVLCの貢献者であることは非常にストレスが多いように感じます。これらすべての異なるOSで機能させるために膨大な労力がかかっていますから。
別の視点から見てください。私たちは貢献者ではありません。メンテナ（維持管理者）なのです。私たちは皆のために維持管理を行っています。例えば、毎年VLCに約150人、FFmpegにおそらく300人が貢献してくれます。私たち小さなチームの目標は、すべての貢献を取り込むことです。使用量が増えれば貢献も増え、その人たちが新しいモジュールやフォーマットを作ってくれます。
私たちはVLCやFFmpegのアーキテクチャ（構造）に気を配っています。最近VLCで空間オーディオのデモを行いました。そのためにはアーキテクチャの変更が必要で、最初の空間オーディオモジュールを作りました。2つ目、3つ目を追加するのは簡単になるでしょう。私たちの目標は、将来の機能を追加できるようにアーキテクチャを整備することです。
マルチメディアフレームワークとして、動画や音声だけでなく、時間を伴って感知できるあらゆるものを表現するフレームワークになっていくでしょう。それが脳波であれば、脳波になります。
マルチメディアの未来と脳波インターフェース
私がこの話をとても気に入っている理由は、FFmpegとVLCが企業や世界を後押しして標準化を進めようとしているからです。例えば脳波を標準化するとか。Neuralinkが脳波コンピュータインターフェースを通じたマルチメディアや、ハプティクスを備えたロボットのための標準規格を作ってくれることを期待します。
経験上、起こることはいつも同じです。新しいトピックが始まり、皆がそれをやり始めるため、5つくらいの異なる標準が乱立します。ハイプ（熱狂）が冷めると、人々は「標準化が必要だ」と言い始めます。通常はリーダー企業ではなく、2つか3つのフォロワー企業が標準を作り、私たちがそれを実装し、そこから落ち着いていきます。
そして、リーダー企業も標準を作る方が良いとプレッシャーを受けるわけですね。
3Dオーディオを例に挙げましょう。6、7年前、すべてが3Dに向かっていました。AndroidのCardboardがあり、2つのオーディオフォーマットがありました。それらはすべて死に絶えました。そして今、実際のユースケースを伴って戻ってきており、私たちは過去の標準の過ちから学んでいます。どこでも同じことが起こるでしょう。
クローズド（閉鎖的）なものを避けるということですね。Dolbyについてあまり良い印象を持っていないとどこかで見ました。
ええ、持っていません。
彼らがどんな悪いことをしてあなたを怒らせたのか教えてもらえますか。
かつては素晴らしいエンジニアを抱え、多くの素晴らしいことを行い、音とは何かを定義した素晴らしい企業でした。しかし今では、主に弁護士とライセンスビジネスの会社になってしまいました。彼らは以前ほど革新していません。残念ながら、HPのようになってしまったと言えます。
VideoLANやFFmpegのTwitterで、お気に入りのツイート、あるいは最も恥ずかしいツイートはありますか。
私のお気に入りの2つは、「口で言うのは簡単だ、パッチを送れ（Talk is cheap, send patches）」です。誰かが実際にやらなければ何も作られないということを体現しています。もう一つは「FFmpeg、私たちの手の届かないものはない」です。米軍の衛星モニタリングシステム全体がリリースされた時のものだと思います。
火星のローバー（探査車）でFFmpegが動いているという話もありましたね。
ええ、FFmpegはMars 2020ローバーで画像の圧縮に使われています。彼らは可能な限り市販の技術（COTS）を使いたいと考えていました。FFmpegは火星でも動いています。私たちは複数惑星にまたがるオープンソースライブラリなのです。
VLCが奇妙な場所で使われているというツイートもよく見かけます。F1のパドックでは皆がライブフィードの再生にVLCを使っています。欧州宇宙機関（ESA）やSpaceXが打ち上げの監視にVLCを使っているのを見ると、喜びに満たされます。
CERN（欧州原子核研究機構）の大型ハドロン衝突型加速器（LHC）にも行きました。27キロメートルのリング上のすべてのセンサーを監視するために、アナログカメラの映像をVLCでマルチキャストネットワークにストリーミングしていたのです。2010年に訪問し、パラメータの設定ミスだった彼らの問題を1時間で解決しました。その後、「今日一日は何を見たい？」と聞かれ、反物質や衝突型加速器などすべてを見学させてもらいました。物理学を学んだ私にとって、人生で最も素晴らしい日の一つでした。
本当にどこでも使われていますね。キーラン、後悔しているツイートはありますか。
フランスの歌にありましたよね。何も後悔していない、と。
何も後悔してはいけません。後悔というのは、自分自身の心への税金のようなものだからです。失敗から学ぶべきですが、後悔してはいけません。タイムマシンがない限り、過去には戻れないのですから。脳に負担をかけるだけです。
「憎しみは非常に高くつく感情だ」というジョニー・デップの言葉を思い出します。
私をジョニー・デップに例える人は初めてですよ。
お二人とより大きなコミュニティがFFmpegとVLCを通じて構築してきたソフトウェアに、私は永遠に感謝しています。辛口なツイートにも感謝しています。決してやめないでください。
今日私と話し、このセクシーな帽子をくれたことに感謝します。魔法使いになったような気分で、特別な気分です。長年にわたって私にこれほどの喜びをもたらしてくれたソフトウェアについて語り、称賛する機会を得られたことを特別に感じています。すべてに感謝します。今日はお話しいただきありがとうございました。
お招きいただきありがとうございました。
本当にありがとうございました。
ジャン＝バティスト・ケンプとキーラン・クンニャとの対談をお聴きいただき、ありがとうございました。このポッドキャストをサポートしていただける方は、概要欄のスポンサーをご確認ください。
それでは最後に、伝説のリーナス・トーバルズの言葉をお送りします。
「ほとんどの優れたプログラマーは、給料をもらうためでも、大衆から称賛されるためでもなく、プログラミングが楽しいからプログラミングをするのである」。
お聴きいただきありがとうございました。また次回お会いしましょう。
コメント