誠に勝手ながら8月中、記事の日付と現実の投稿日は一致しません。基本的に7月以前の記事はOut of Dateとお考え下さい。
２日：MEncoder -x264encopts遅くてたまらん！と言う方は WebRunner だと多少速いです。使い方はopentechpressのこの記事を。
Mac OSXの場合、CotEditor 0.9.2などで下記を「ageha0-0708.webapp」 などの名前で保存、「このアプリケーションで開く」でWebRunner.appを指定します。これで「ageha0-0708.webapp」を開けば2007/8/1に直行します。
[Parameters] uri=http://agehatype0.blog50.fc2.com/blog-date-20070801.html icon=webrunner showstatus=yes showlocation=no enablenavigation=yes
可能な限り妥当な情報を書くよう努めますが、内容の保証は致しかねます。ご指摘等ありましたらコメント欄にてお願いします。
x264：
どちらの場合でも、アプリケーションはx264が備えるAPIを呼び出す。なお、Mac OSX（BSD系も？）では動的ライブラリの拡張子は.dylibなのだが、サポートされていない模様。
x264cli：
MEncoder：
ffmpeg：
ffmpegX / MeGUI：
avc1Decoder / Perian / ffdshow：
avc1Encoder：
この中で特に、ffmpeg（libavcodec / libavformat）的な共通インフラは、コンピュータでマルチメディア（様々な形式の動画・音声・字幕・インタラクション、などなどなど）をやるなら当然に必要なものだが、全体への影響を考えないといけないのでそのぶん先進的なコデックへの対応に時間がかかる。程度の差こそあれ、QuickTime / DirectShow / VfW の何れも同じ手間がかかる。
プロジェクトとしてのx264は ffmpeg とは独立して突っ走っているのが特徴で、ノイズリダクションなど、符号化ライブラリが手を出す必要の無い機能にも手を付けている。また、x264vfw のサポートは2006年10月に停止している。
余談ながら、avc1Decoder / avc1Encoder その他 libavcodec の QT 移植を一人でやってしまった MyCometG3 さんはワールドワイド一騎当千だと思います。
MPlayer 公式ドキュメント：http://www.mplayerhq.hu/DOCS/HTML/en/index.html
libcaca
– Color ASCII Art library
libavcodec codec familyXvid codecx264 codecVideo For Windows codec
family
此方より彼方まで... ：http://www4.pf-x.net/~fennel/
フェル（？）さんによるAviSynth/x264cliの解説。Win。コンパクトにまとまっておりとっつき易い。
此方より彼方まで... ：http://felmina.blog61.fc2.com/なかのひとのブログ。
アニメエンコで役に立つかもしれない覚書：http://www.geocities.jp/encmemo5whf6jvag8/index2.html
なるP氏による解説。
ずっといっしょにいたいから… ：http://narup-.hp.infoseek.co.jp/top.htmlなかの人の日記。
日本語で読めるx264cliの本陣。
Encoding H.264 using the x264 Command Line Interface：http://aflux.deltaanime.net/Zero1/MP4/x264.html
Zero1氏による解説。
A&E's Technical Guides to All Things Audio and Video： http://www.animemusicvideos.org/guides/avtech/index.html
その上位ページと思しきもの。
Timeline - x264 - Trac： https://trac.videolan.org/x264/timeline
Revの進捗と変更点
まるも製作所バックナンバー（07夏）：http://www.marumo.ne.jp/db2007_6.htm
Codec comparisons： http://www.doom9.org/codec-comparisons.htm
2005：How to Use ffmpegXメモ: Doom9 2005 コデックコンテスト -- 目次 （試訳）
2006：未開催。
2005の優賞はx264。僅差でAteme。
AVCコデックの全てについて「連続するP/Bフレームが切り替わる際にぱたぱたとフレーム単位で変化するブロックノイズ」を指摘しており、2006年はこの対策が開発の軸のひとつとなった感があった。例えば--no-fast-pskipなど。
2005：Second Annual MSU MPEG-4 AVC/H.264 Video Codec
Comparison（リンク先に英文PDF有）
2006：Third Annual MSU MPEG-4 AVC/H.264 Video Codec
Comparison（同上）
2007：Call for MPEG4-AVC/H.264 codecs （8/26日まで参加コデック募集中）
2006版のx264の成績は総合２位。
Video conferences で２位（僅差）、Moviesで１位、HDTVで２位。総合１位はMainConcept 。
なお、Apple-H.264については時間計測が不能な事、独自のブライトネス・シフト（ガンマ補正を指すと思われる）により同一条件での比較が困難としている。このブライトネスシフトの影響を排した独自の画質評価手法を用いた実験では他のコデックとの競争力が無いわけではないとしているが、x264とMainConceptの優位は変わらないとしている。
ffmpegのAppleScriptラッパー、MPEG Exporter TNGの作者さん。iTunes / iPod / Apple TV向けffmpeg設定はこちらで。
Winの携帯動画変換君向けiniファイルまで公開されている。
雲の流れるままに：http://blog.so-net.ne.jp/kumosuke/
絵に描いたような模範的なPS3&PSPファン。とことん使い倒しておられます。
※2007/8/2で抽出すると全件を1ページに読み込みます。
x264cliの--longhelpに比べると、MEncoderのman pageはいくぶんユーザー寄りで、いちど順番に読めばそれなりに使えるようになると思います。x264cliに比べると利用できるオプションが少ないの ですが、省かれているものの大半は実験目的で実用性が薄いもののようです。特に面倒な --sar が自動計算なのは便利です。いや目的次第では困るのかな？
記事タイトルの見方：
オプション名=指定値 [デフォルト値,使用条件] (備考)
＊指定値の種類備考：
平均ビットレートの指定。単位kbit/sec (default:off)。
ローカルビットレートは変動するため、非常に短いムービーでは指定値とかけ離れた値になる事がある(ratetol参照)。
このオプションとvbv_maxrateを同時に使うと固定ビットレートになるが、画質は著しく劣化する。
Pフレームに適用するquantizerの指定。
IフレームとBフレームに適用するquantizerはこの値を元に ip_factor と pb_factor が少しずらして決める。
低い数値ほどビットレートは高く、素材画質に忠実。0でロスレス。
H.264の量子化はMPEG-1/2/4とは異なる事に注意：
H.264の量子化パラメータ (QP)は対数尺を用いる。 換算すると概ねH264QP = 12 + 6*log2(MPEGQP)。例えば、MPEGのQP=2 は概ね H.264 の QP=18となる。
固定画質モードのenable。値は画質を指定するもので、概ねQPに近い。
ビットレートベースのモード同様、各フレームごとに複雑さに応じて異なるQPを使う。
2または 3パスモードの指定。
最適なビットレート配分と全体の画質向上の為には2か3パスエンコードを推奨。
1 1st パス
2 2nd パス (または2パスエンコード)
3 Nth パス (3pass エンコードの 2nd と 3rd パス)
1st pass(pass=1)は映像の統計を取ってファイルに書き込む。CPU負荷の高いオプションは使わなくて良いが、デフォルトでonのものは使う事。
2nd pass(pass=2)はstats（統計）ファイルを読み込み、これを基にビットレート配分をコントロールする。
3passモードでの2nd("pass=3"と指定する。タイプミスではない。)は両方を行う。最初に統計を読み込み、上書きする。CPU負荷の高いオプションを除き全てのエンコードオプションが使える。
3rd pass(pass=3)は2nd passと同じだが、2nd passの統計を使用する。CPU負荷の高いオプションを含めて、全てのエンコードオプションが使える。 1st pass はABRでも固定quantizerでも良いが、quantizerを推測する必要がないので、ABRの方が望ましい。
後続のパスはビットレートを指定するABRでなければならない。
高速1st passモード。
2（以上）パスエンコードの１stパスは、取るに足りない、あるいは、最終出力品質に影響しないオプションを切って高速化できる。
Level 1 の1stパス速度は最大2倍。最終出力のグローバルPSNRは等速1stパスと同じ。
Level 2 は最大4倍速。最終出力のグローバルPSNRは概ね +/- 0.05dB。
IDRフレームの最大間隔。
大きい値の方がbitが節約できるので品質が向上するが、シークの精密さと引き換えになる。
MPEG-1/2/4とは違って、H.264はkeyintを大きくしてもDCT driftで苦しむ事が無い。
IDRフレームの最小間隔を指定。
この最小間隔の中にシーンチェンジが含まれた場合、エンコードはIフレームとして行うが、新しいGOPを開始しない。
H.264では、Iフレームは必ずしもclosed GOPに束縛されない。
なぜなら、Pフレームを直前より前のフレームを基に予測しても良いからだ (framerefも参照)。この為に、Iフレームは必ずしもシーク可能では無くなった。
IDRフレームは、後続のPフレームに、自分より前にある全フレームを参照禁止にする。
Iフレーム挿入を決断する際の積極性。
scenecutの値が低いと、このコデックはしばしばkeyint間隔よりも大きな間隔でIフレームを入れてしまう。
scenecutの値が適切なら Iフレームはもっと良い位置に挿入される。
大きすぎる値を使うとIフレームを必要以上に入れてしまい、bitが無駄になる。
-1 は自動シーンカット検出を無効にする。従ってIフレームは、たとえ場面転換があろうとも、keyint frame間隔毎にしか挿入されない。これはオススメできない。なぜなら、この場合に場面転換地点で生成されるPフレームはIフレーム同然にサイズが大きくなるのでビットレートの無駄だし、その上"keyint counter"にもリセットがかからないからだ。
P／Bフレームは予測の際に自分より前のフレームを参照フレームに使う。
H264/AVCでは直前よりも前のフレームを参照フレームに使う事ができる。
このオプションはその際、最大でどのくらい前のフレームを参照フレームとして使えるかを指定するもの。
アニメには効果的だが、実写では6程度を境に効果が急激に低下する。
デコードの速度には影響しないが、必要メモリ量が増える。
デコーダによっては最大15までしか受け付けない。
IとPフレーム間でのBフレームの最大連続数。
bframes=<0-16>で指定された最大Bフレーム数の範囲で、いつ、どれだけの数のBフレームを使うか自動的に決断する。nob_adaptの場合、前述の bframes（デフォルト0）の最大Bフレーム数を使用する。
＊このオプションがBは不適切と判断した場合、Pになる。
b_adaptの「決断力」の強さを設定する。高い程沢山のBフレームを使う。
Bフレームを参照フレーム～他のフレームが予測に使う～に使うことを許可する。
例えば、連続したBフレームが3個あるとしよう。
I0 B1 B2 B3 P4
b_pyramidオプション抜きの場合、 BフレームはMPEG-1/2/4と同じパターンに従う。つまりこれらは
I0 P4 B1 B2 B3
の順番で符号化され、全てのBフレームは I0 とP4 をベースに予測される。
b_pyramidオプション有りの場合、これらは
I0 P4 B2 B1 B3
の順番で符号化される。B2は上記と同じだが、B1は I0 と B2 を、B3 は B2 と P4 をベースに予測される。
この結果、速度低下抜きで圧縮率が僅かに向上する。
しかしながら、このオプションはまだ実験段階だ。：チューニングは未熟で必ずしも効果があるとは限らない。
オプションのbframesは2以上でなければならない。
デメリット：increases decoding delay to 2 frames.
第一のパラメータは AlphaC0 (default: 0)。これはH.264のイン-ループ・デブロッキング・フィルタの閾値。
まず、このパラメータの値に従ってデブロックを使うか否かを決める。次に、このパラメータはフィルタを適用するエッジ部分の差の閾値に影響する。プラスの値にする事でブロックノイズが減るが、スミアが増える。
第二のパラメータはBeta (default: 0)。これはディテイルの閾値に影響する。
非常にディテイルの細かいブロックにはフィルタを掛けない。というのはこのフィルタが使うスムージングはブロックノイズよりも目立つからだ。
このフィルタはデフォルト値でほとんど常に最良の結果になるので、そのまま弄らないか微調整にとどめるのがベストだ。しかし素材になんとかしたいほどのブロックノイズやノイズがあるなら、少し強めにしても良いだろう。
＊スミア：絵をこすったような滲み。細かいディテイルが潰れる。
エンコード、デコードとも多少遅くなるが、ビットレートは10～15%下がる。
デコードの速度を求めるので無い限り、オフにしない方が良い。
＊Context-Adaptive Binary Arithmetic Coding = 適応２進法算術符号化
quantizerの最小値。10-30が適正範囲のようだ。