x264:
アプリケーションが呼び出すライブラリ。復号(デコード)能力を持たず、符号化(エンコード/コーディング)能力のみなので厳密にはコデックではなく、コーダーと呼ぶ。
x264.a:静的ライブラリ。mencoderやx264cliをビルドする際に取り込まれる。
x264.soなど:動的ライブラリ。必要に応じてアプリケーションが呼び出す。
どちらの場合でも、アプリケーションはx264が備えるAPIを呼び出す。なお、Mac OSX(BSD系も?)では動的ライブラリの拡張子は.dylibなのだが、サポートされていない模様。
x264cli:
x264専用のテストベッド。x264の全APIを呼び出せる。単にx264と呼ぶ人が多い。コンパイルオプションによっては.mp4や.mkvへ直に書き出せる。反面、自力で読み込めるのは raw YUV 4:2:0のみなので、fifo(名前付きパイプ)でMEncoderと繋いだり、AviSynthスクリプトを書いたりする必要がある。
MEncoder:
統合動画エンコーダ。x264のAPIのうち、実用的なものはほぼ呼び出せる。他に各種libavcodecやXvid、vfwコデックも呼び出せるようだ。それぞれの専用APIに素直に対応するので、各コデックの性能を引き出し易い。ffmpegプロジェクトとワンセットのため、デコードの対応幅が広く、プリプロセスフィルタ(デノイズとかインタレ解除とか)も AviSynth と相互に移植し合うレベルのものを備えている。
反面、MPEG-2のデコードでdelayがかかったり(これを迂回するindexファイルを作らない)、Bを使うと.mp4に直吐きできないなどの問題があるのだが、ソースコードが迂闊に手を出せない状態らしい。これは各コデックへの素直な対応と、もともと1-frame-in-1-frame-out制限のあるVfWをモデルとした事から来ているようだ。
ffmpeg:
libavcodec用のテストベッド。自前でH.264デコーダを備える。エンコードはx264を使うが、実用的なAPIでも呼び出せないものが多い。これは各コデックに共通のAPIを要求するためらしい。この成果か、Bを使っても.mp4に直吐きできるなど、なにかとコデック / フォーマットの対応幅が広く、汎用性で突出している。反面、同じオプションがコデックによって挙動が異なったり、特定コデックでしか使えないオプションが区別しにくかったりする。
ffmpegX / MeGUI:
上記いずれかのGUIラッパー。内部的にx264cliや MEncoderを呼び出して使う。
avc1Decoder / Perian / ffdshow:
libavcodec の QuickTime / DirectShow
移植。再生のみ。またavc1DecoderはH.264デコーダのみ。
avc1Encoder:
x264 を libavcodec 経由で QuickTime に移植したエンコーダ。
この中で特に、ffmpeg(libavcodec / libavformat)的な共通インフラは、コンピュータでマルチメディア(様々な形式の動画・音声・字幕・インタラクション、などなどなど)をやるなら当然に必要なものだが、全体への影響を考えないといけないのでそのぶん先進的なコデックへの対応に時間がかかる。程度の差こそあれ、QuickTime / DirectShow / VfW の何れも同じ手間がかかる。
プロジェクトとしてのx264は ffmpeg とは独立して突っ走っているのが特徴で、ノイズリダクションなど、符号化ライブラリが手を出す必要の無い機能にも手を付けている。また、x264vfw のサポートは2006年10月に停止している。
余談ながら、avc1Decoder / avc1Encoder その他 libavcodec の QT 移植を一人でやってしまった MyCometG3 さんはワールドワイド一騎当千だと思います。
スポンサーサイト