入出力、fpsやスレッドの指定、画質指標などのエンコードに関わる情報表示、およびSARなどのヘッダ情報の指定。
原 文： http://aflux.deltaanime.net/Zero1/MP4/x264.html#input-output
出力ファイル名とパスの指定。出力形式（拡張子）もここで指定する。
.264で raw MPEG-4
ストリーム。.MP4で映像のみのMP4（音声は後からMP4boxでmuxする）。.MKVならMatroska。MKVに慣れているならMKVでも良
いが、このガイドは.264で吐いて他の要素（音声など）は後からMuxする事を前提にしている。プレビューには.MP4が良い。
SAR は Sample Aspect Ratio の略。これを指定するとアナモルフィックビデオ～すなわち、サンプル解像度に関わらず正しいアスペクトレシオ（＊映像の縦横比＊）に引き延ばして再生できるようになる。SARはアスペクトレシオを指定するものではなく、引き延ばす係数の指定である事に注意。
例えばSAR 32:27 は720x480映像をアスペクトレシオ 16:9 で再生するためのものだ。32/27=1.185185... となるので、1.185185...x720 = 853.3くらい。従って再生は853x480となる。
アナモルフィック映像を扱った経験者は多いと思う。NTSC-DVDでは一般的に、ワイドスクリーン映像はNTSC 4:3の 720x480 に押しつぶしてある。
アナモルフィック素材を扱う方法にはいろいろなものがある。
１）640x360 にリサイズ（そして 16 の倍数である 352 にクロップ）。
２）852x480 にリサイズ（同じく 848 にクロップ）。
前者では大量のディテイルを失う事になる。後者では拡大による汚れが出る。アナモルフィックでは 720x480 または 704x480 でエンコードして、再生時に概ね 853x480 に引き延ばすタグをつけておく事ができる（playerによって異なる）。再生サイズは 853x480 でも、実際のデータ量は 720x480 または 704x480 だ。拡大するわけでは無いのでbitの節約になり、縮小では無いのでディテイルは維持できる。再生負荷もエンコード前に拡大するよりは低い。と言うように SARは理論上は良いものだが、AMV（＊アニメ・ミュージック・ビデオ、原文はこれを想定しているが、概ね一般論として通じる＊）を間違ったアスペクトレシオで編集すると、変な形にリサイズされてしまう事を忘れないように。ただし、編集ソフトにそのへんの面倒を見てくれるモードがあれば別です。
一般的な SAR：（＊下表の内容はweb上の他の情報と矛盾します。『疑問点』参照＊）
| Source Resolution | Display Aspect Ratio |
Sample Aspect Ratio | 備考 |
|---|---|---|---|
| 720x480 (NTSC) | 1.33（4:3） | 8:9 | スタンダード |
| 1.77（16:9） | 32:27 | ヨーロッパビスタ（1.66）とアメリカンビスタ（1.85）の中間比 | |
| 1.85 | 100:81 | アメリカンビスタ | |
| 2.35 | 69:44 | シネマスコープ | |
| 704x480 (NTSC Crop) | 1.33 | 10:11 | |
| 1.77 | 40:33 | ||
| 1.85 | 125:99 | ||
| 2.35 | 85:53 | ||
| 720x576 (PAL) | 1.33（4:3） | 16:15 | |
| 1.77（16:9） | 64:45 | ||
| 1.85 | 40:27 | ||
| 2.35 | 32:17 | ||
| 704x576 (PAL Crop) | 1.33（4:3） | 12:11 | |
| 1.77（16:9） | 16:11 | ||
| 1.85 | 50:33 | ||
| 2.35 | 102:53 |
例えば解像度が 704x480（720x480 NTSC の黒帯をクロップしたもの）で、アスペクトが 16:9 の映像なら、 --sar 40:33。
SARは MP4box でも指定できます（推奨）。MP4box ガイドも参照して下さい。
＊原文にMP4box ガイド未発見。
＊ageha MP4Boxの主要コマンド に
-par trackID=PAR というオプションがある。
見れば解る通り、映像のフレームレートを指定する。例えば少数指定なら --fps 23.976、分数指定なら24000/1001。一見にているが、厳密には同じでは無い事に注意。これは後でファイルを結合する際に重要だ。分数の方が正確で、23.976 と 29.97 fps の指定はそれぞれ 24000/1001 と 30000/1001 が正しいとされている。
エンコードの開始フレームを指定。ファイル冒頭に要らない部分があった時に便利。AVIsynth のトリム機能に似ており、--framesと一緒に使うと良いだろう。
エンコードするフレーム数を指定。--seek と一緒に使うとシーク開始点から--framesで指定したフレーム数をエンコードする。
Annex A（＊追加議定書A＊）で定義されたProfile@Level を指定。
ハードウェアプレイヤが再生可能かどうかチェックするのはここで指定するLevel
だ。x264のデフォルトは最も高位のプロファイルで、Profile@Levelを知らない場合、変更は非推奨。レベルとプロファイルの一覧は下記リンク参照。
http://aflux.deltaanime.net/Zero1/MP4/x264_files/h264levels.png
＊PSPやiPodなどでは設定が必要な模様。
各フレームの統計を表示。一般には鈍足化するので不要。切っておく事を推奨。
＊まるも製作所さんの日記に適用時の例アリ
07/07/19（木） x264 [17] --no-b-adapt：http://www.marumo.ne.jp/db2007_7.htm#19
基本的な読み方は、07/06/29（金） x264 [7] ログの読み方 - サマリー編にある。
エンコード中に進行状況を表示。ETA（＊予想終了時間、MASA.Hさんのコメント参照＊）、エンコード済みフレーム数、残りフレーム数、エンコードの速度（fps）を表示するので非常に重要だ。
PSNR算出を停止し、エンコード後にPSNRを表示しない。画質には影響しないので速度が少し早くなる。必要無ければ --no-psnr で切っておこう。
SSIMの計算を停止
スライスを使った併行エンコード。マルチ/マルチコアCPUがあれば速度向上。分散処理の手法と符号化の動作原理からスレッド分散には僅かな画質劣化があるが、少しリッチな設定をしてやれば抑えられる。しかも速度向上分は余る。各CPU/コアあたり１スレッドが適正なので、２コアなら --threads 2、２コア２CPUなら --threads 4。
＊スレッド分散方式はこの記述の後（rev.607）で最大4から16に拡張され、分散処理の手法も変わり、画質劣化はより少なくなり、CPU数以上のスレッドを指定してもよくなった。反面、シーンカット検出がやや精度低下。詳細は下記参照。
ageha：07/01/05 threads=<1-16>：http://agehatype0.blog50.fc2.com/blog-entry-170.html
まるも製作所さん：07/07/21（土） x264 [19] スレッド実装：http://www.marumo.ne.jp/db2007_7.htm#21
１スレッドをエンコードに、１スレッドをAVISynth出力のデコードに割り当てる。双方にとってのベストで、画質劣化抜きの高速化になる（エンコードには１スレッドが割り当てられたままで”スライス”されないから）。しかし、速度向上は --threadsで得られるほどではなく30%ほど。
＊rev.607のスレッド分散方式変更の影響は不詳。手許ではAviSynth 3.0のビルド未着手。
平行処理の効率を僅かに向上、反面、併行精度（？）が下がる。
＊SMP (Symmetric Multiple Processor) - IT用語辞典 http://e-words.jp/w/SMP.html
エンコードしたビデオの上にマクロブロック・タイプとモーションベクトルをオーバーレイ表示。非常に遅く、ほとんどの人にとって意味の無い機能だろう。ほうっておくのがベスト。
＊原文は確かrev.400番台準拠だったので一部改変してあります。
アクセス・ユニット・デリミタを使う。
これはフレームの開始点をマーキングするもので、MPEG-2 Transport streams (.ts) 形式での保存やストリーミングに使う。またどうやらPSP用の公式H.264エンコーダでも使うようだ。PSP用ならともかく、特にこれを使う理由は無い。と言うのは.tsはDVB（Digital TV）の放送向けだからだ。一般的にこれは複数の音声と映像チャンネルを含んでいる。なお、PSPも恐らくaud抜きで再生できると思う。
＊DVBはEU方式だが、日本の地デジもMPEG-2 TSを使っているハズ。
