ffmpegとlibavの背景事情

ffmpegをインストールしようとしたら、なにやらちょうど一年前あたり、大規模なforkが起こったらしい。いまや、ffmpegとlibavに分裂している。forkは自由なソフトウェアではいたって普通の出来事だ。大抵の場合、開発者の間での意見の不一致により起こる自然な現象だ。自由なソフトウェアであれば、fork自体はそれほど悪いことではない。どちらも自由であるので、双方の開発者がIRCやMLで広角泡を飛ばしながら喧嘩しつつ、何事もなかったかのように相手のコードをこちらのコードベースにマージできる。なぜならば、どちらも自由なソフトウェアという共通点を持っているからだ。

しかし、ffmpegは、だいぶ巨大なソフトウェアだ。おそらく、現時点でこれ以上にでかい動画と音声のソフトウェアは、mplayerしかあるまい。mplayerはffmpegを包括しつつ、さらに変態的なことをしている。これについては後ほど述べるとして、まずはffmpegだ。どうやら、一年前に起こった出来事にも関わらず、ffmpegとlibavのforkの背景事情を説明する日本語の文献がないようなので、ここで解説する。

ffmpegは、世界一の規模を誇る動画と音声のエンコーダー、デコーダー集である。ffmpegはこの世に存在した、ありとあらゆる動画のエンコーダーとデコーダーを自由なソフトウェアとして提供する目的で開発されている。中には、大昔のゲーム専用機でしか使われていない、ドキュメントもない動画圧縮形式を、解析して実装することまでしている。ffmpegは、YouTubeを始めとしたあらゆる動画投稿サイトで使われている。なぜならば、このような動画投稿サイトにアップロードされる、それはそれは多数の圧縮形式を一手に引き受けて、正しくデコードし、さらに別の使いやすい圧縮形式にエンコードしてくれるのは、ffmpegをおいてほかにないからだ。ffmpegは、今日の動画サイトの舞台裏を支えているのだ。

そのffmpegがforkするというのだから、穏やかではない。いくら自由なソフトウェアとはいえ、物理的にコードベースが分離して、開発も分断されてしまうと、他方のコードでの変更点をこちらにマージするのは、一手間かかる。バージョン管理ソフトの自動的なマージ機能は、近年大幅に進化しているが、万能ではない。どうしても、人手による作業は避けられない。それでもなお、forkは起こる。

libavが発表されたとき、いち早くlibavに追随すると発表したのは、DebianとUbuntuである。実は、ここに問題の発端がある。問題は年々積もり積もっていたのだが、DebianとUbuntuも一枚噛んでいる。

Debianとその派生のUbuntuは、膨大なコンパイル済みのバイナリパッケージを提供している。パッケージはメンテナーによって、正しくコンパイルされ、適切に設定され、自動的にインストールされるよう調整される。このおかげで、ユーザーはCLIやGUIから、望みのパッケージを簡単にインストールできる。たとえば、ffmpegなら、以下のコマンド一行ですむ。

sudo apt-get install ffmpeg

あるいは、ソフトウェアセンターでffmpegと検索してインストールをクリックすれば良い。

無論、これは今さら言うまでもない。問題は、DebianとUbuntuにおけるffmpegのメンテナーが、バイナリパッケージをメンテする際のffmpegの問題をffmpegのトップの開発者、Michael Niedermayer（Lair Of The Multimedia Guru）にかけあった際、Michaelの対応がおろそかだったのだ。

さて、まずはlibav側の主張だ。

Ubuntu renaming FFmpeg to libav

問題とは、ffmpegがころころAPIやABIを変更することである。これでは長期的なサポートが難しい。だから、常にtrunkというわけではなく、stable版も提供してはくれないかという提案が出された。ところが、Michael Niedermayerはこの提案に否定的だった。さらに、Michaelはバイナリパッケージ自体にも、あまり興味を示さなかった。まるで、「ユーザーは常に最新版を自前でコンパイルして使うべきである」、といわんばかりの姿勢だった。

さらに、Michaelの指導下にあるffmpegは、機能の追加に対して保守的だった。たとえば、マルチスレッドによるデコード、ffmpeg-mtは、いまだにマージされない。しかも、「俺は絶対にffmpeg-mtなんかマージしねーよ」とまで明言した。

ここで、一部の開発者がより集まって相談した結果、forkするべきであるという結論に達した。Michael Niedermayerはこのforkに対して、口汚く罵り、身体上に危害を加えることを示唆するような悪質な冗談を繰り返したという。

FFmpeg
Libav

その後、お互いに相手のコミットを自分のコードベースにマージしたり、libavは名前をAPIをリファクタリングしたり名前を変更し始めたりと、やや不毛な作業も行われていたようだ。これが影響されたのだろう、Michael Niedermayer率いるffmpegはこの事件のあとすぐに、ffmpeg-mtをマージしたりしている。libavの方がバイナリパッケージのメンテナーの声をよく聞き入れる。DebianとUbuntuのlibavへの追随はこのためだ。

と、ここまではlibav側の主張である。Michael Niedermayerの主張は、また少し異なる。

Ubuntu renaming FFmpeg to libav

まず、Michael Niedermayerは、何も自前ビルドの原理主義者ではない。ただ、バイナリパッケージというものが大抵、一年以上も前のバージョンから更新されなかったりすることに不服だという。すでに多くのバグフィクスや改良、新機能の追加が行われているというのに、バイナリパッケージはいまだに大昔のままである。さらに、ffmpegをめぐるソフトウェア特許の問題もある。ソフトウェア特許に対処するためには、ソースコードの形で提供して、ユーザーにコンパイルさせた方がいい。

「ffmpeg-mtなんてマージしねーよ」というのは、単にIRC上でのチャットであり、その文脈上の冗談である。悪口というのも、たんなる冗談を本来の文脈から切り離して不当に評価したものである。

fork後にffmpeg-mtをマージしたのは、別に普通の作業であって、forkとは関係がない。

ABIの変化を気にかけないというのも不当である。というのも、MichaelはABI変化の問題を調査して、GNU ld.soにバグがあることをつきとめている。リンカーのバグ探しがなんで悪いのか。

ましてや、そのforkの方法たる、サーバーの管理者と協力して、MichaelのMLやソースレポジトリへのアクセスを禁止した。このような締め出しは開発者に与えられる正しい処遇ではない。

Lair Of The Multimedia Guru » ld.so GNU linker/loader

さて、プログラム的にみると、このforkの問題は少し厄介だ。まず、プログラム自体は、別の名前に変更されることになった。ただし、ライブラリの名前は変更されない。だから、このままでは、名前が衝突してしまう。両者とも比較的最近に、同じコードベースを共有していたのだから、ライブラリの互換性はあるが、混在はできない。ライブラリの名前を変えない以上、どちらかを選ばないといけない。GCCとEGCSのように、いつか和解して一つに戻る日がくるのだろうか。

DebianとUbuntuはlibav側に追随したし、Gentooも同じ影響を受ける。その他の有名なディストリはどうするのだろう。ffmpeg/libavは非常に有名なライブラリなので、ほぼすべての有名ディストリはパッケージに含んでいる。対応しないわけには行かないのだ。

ちなみに、冒頭の、mplayerはffmpegより巨大であるという話であるが、これはmplayerはffmpegを完全に包括するのみならず、Windowsのバイナリブロブを読み込むための機構を備えている。これは、Wineから拝借してきたコードである。数年前、コードを覗いてみたとき笑ってしまった。mplayerはLoadLibraryを自前実装しているのだ。

ちなみに、mplayerもforkされている。mplayer2という。より綺麗なコードベース（mplayerはffmpegのソースコードをコードベースに包括する。頻繁に更新されるffmpegは、外部に置きたい）、バグフィクスや改良などを含むという。mplayer2では、mencoderは提供されていない。

ちなみに、UbuntuのパッケージにあるChromiumは、ffmpegを使ったプラグインでvideoとaudioの対応形式を大幅に増やせる。このプラグインもlibavに変更されるのだろうか。

Google Summer of Code 2012では、ffmpegとlibavの両方が登録されており、両方とも似たような提案だらけだ。

FFmpeg Summer of Code 2012 - MultimediaWiki
Libav Summer Of Code 2012 - MultimediaWiki