Doc / menc-feat-dvd-mpeg4

14.1. DVD映像を高画質なMPEG-4 ("DivX")にする方法 †

よくある質問に「サイズに上限があるんだけど、その範囲で一番画質をよくするにはどうしたらいいの？」とか「サイズはどうでも構わないから、最高の画質にしたいんだ。」というのがあります。

少なくとも後者は、なんか間違ったスタンスでしょう。本当にサイズを気にしないのなら単にDVDのMPEG2ビデオストリームをコピーすれば良い事ですから。もちろん、そうしたAVIは多少の差はあれ5GBに達するでしょうが、最高画質で、サイズを気にしないならそれがベストです。

実際のところ、DVDをMPEG-4に変換するという事は、あなたがファイルサイズを気にしているという事です。

非常に高画質のDVDリッピングを料理本のように解説する事は難しい事です。考慮すべき要素がいくつかあり、それらの詳細を理解していなければ失望すべき結果が待っています。以下では、これらの要素のうちいくつかを解説し、その後に実例を見ていきます。ここでは映像のエンコードにlibavcodecを使うと仮定しますが、基本的な部分は他のコデックを使う際にも役に立ちます。

もし難しいと感じたら、関連プロジェクトページのMEncoder section(http://mplayerhq.hu/homepage/design7/projects.html#mencoder_frontends) に便利なフロントエンドが沢山ありますので、どれか選んで使ったほうが良いかもしれません。この方法では、あまり深く考えなくても高画質リッピングができます。大半のツールはややこしい部分を適切に判断するように作られています。

14.1.1. エンコードの準備: 素材の種類とフレームレートを見分ける †

エンコードに入る前に、いくつか済ませておくべきステップがあります。

第一に、最も重要な事は、素材のコンテンツがどんな形式かという事です。素材ファイルがDVDか地上波/ケーブル/衛星TVの場合、２種類の形式があり得ます。:北米と日本ではNTSC、欧州その他ではPAL形式です。これは重要です。単にTVに映像を映し出す規格に過ぎないのですが、映画のオリジナルフォーマットと異なる事が多いからです。適切なエンコードの為には、オリジナルのフォーマットを知る必要があります。ここでしくじると、エンコード結果様々な悪影響があります。 例えば、醜い櫛状ノイズ(interlacing)が出たり、フレームを無駄に複製してしまったり、さらには必要なフレームを失ってしまう事もあるでしょう。ビットレートを奮発しても画質が良くないと言う事になりかねません。

＊訳者註：オリジナルのフォーマット＝撮影時の形式。カメラの規格とか構造というほどの理解で良いと思われます。これがTVの画像表示方式と異なっていると、エンコードが面倒になる、と。

14.1.1.1. 素材映像の元々のフレームレート--Identifying source framerate †

素材ファイルで一般的なフレームレートと、その特徴を挙げてみましょう。

• Standard Film: 映画館で上映する為に24fpsで作られています。
• PAL video: PAL ビデオカメラで、毎秒50フィールドで撮影されたものです。フィールドは1フレームのうち偶数か奇数のラインだけで構成されています。TVはこれを交互に表示して、簡単なアナログ圧縮としているわけです。
  人間の目はこれを補完するとされていますが、このインターレースの仕組みを一度知ってしまったら、TVでそれが見分けられるようになり、楽しめなくなってしまうかも知れません。
  2個のフィールドを合成しても、完璧なフレームになる事は有りません。なぜなら、フィールドと次のフィールドの間には 1/50 秒の時間差があり、その間の動きをカメラが捉えてしまうからです。1/50 秒の間、まったく動きの無い場面や部分はキレイになります。
• NTSC Video: NTSC ビデオカメラで撮影されたもの。撮影間隔は３種類。通常は毎秒60000/1001フィールド。白黒時代には毎秒60フィールド。もしくはPALと同様。
• Animation: 通常は24fps（フレーム/秒）で描かれています。しかし、さまざまなフレームレートが混ざっている事もあります。
• Computer Graphics (CG):製作自体はいかなるフレームレートでも可能ですが、一般的なのは、NTSCでは24か30fps、PALでは25fps。
• Old Film: 様々なフレームレートが有ります。上記よりは低いです。*1

14.1.1.2. 素材映像がどうなっているかを意識する--Identifying source material †

フレームで構成された映像をプログレッシブと言います。他方、フィールドで構成された映像はインターレースドと言います。少し紛らわしいのですが、"ビデオ"と呼ばれる事もあります。 さらに複雑な事に、映像の中にはここまでに挙げた様々な形態が混在している事があります。 素材映像を見分ける上で最も重要なのはフレーム構造か、それともフィールド構造かという点です。TVに表示するための映像（DVDを含みます）を作成する時には、映像は必ずフィールド構造に変換されます。変換の方式にはさまざまなものがありますが、それらはまとめて"プルダウン"と総称されます。悪名高いNTSC "3:2 テレシネ"もその一つです。撮影時の素材がフィールド構造で、かつフィールドレートも同じで無い限り、 DVDの中の映像はオリジナルとは異なっていると言う事になります。

一般的な pulldownの方式:

• PAL 2:2 プルダウン: 各種プルダウン方式のうちで最善。1フレームの再生時間が2フィールドの再生時間と同じ。偶数と奇数のラインを交互に表示するとぴったり1フレーム分になるもの。撮影時の素材は24fpsの場合、映像全体は4%ほどスピードアップする。
• PAL 2:2:2:2:2:2:2:2:2:2:2:3 pulldown: 12番目のフレームを3フィールドの再生時間ぶん表示するもの。4％スピードアップの問題がなくなる。しかし、この処理を施された映像から元の映像を再現する作業は複雑になる。4％スピードアップが深刻な問題になる音楽素材でよくみられます。
• NTSC 3:2 telecine: フレームの再生時間が、3フィールドぶんと2フィールドぶんの交互になっているもの。フィールドレートはオリジナルのフレームレートの2.5倍になります。その結果、映像の再生速度は、毎秒60フィールドから60000/1001フィールドの範囲で非常に僅かに遅くなります。これはNTSCのフィールドレートを守るためです。
• NTSC 2:2 pulldown: 30fps素材をNTSCに表示するために使われるもの。2:2 PALプルダウンと同じくらい良い。

この他に、NTSCとPAL間の変換というのがありますが、このガイドでは取り上げません。そうした映画をエンコードしたいなら、最善は元のフォーマットのものを入手する事です。NTSC-PAL変換は非常に破壊的で、奇麗な復元は不可能です。エンコードは困難を極めるでしょう。

DVDにビデオを保存する際には、連続する2フィールドがフレームとしてグルーピングされます。例えその２つのフィールドが、同時に表示されるべきもので無かったとしても、です。DVDやデジタルTVで使われているMPEG-2規格には、オリジナル素材のプログレッシブフレームをそのままエンコードして、フレームのヘッダにこのフレームの再生時間は何フィールドぶんなどと書いておく方式もあります。この方式を"ソフトテレシネ"と呼びます。DVDプレイヤーにプルダウン処理を任せるからです。映像そのものには手を加えられていないので、これは大変望ましい。エンコーダは簡単にもとの映像を復元（実際には何もしない）できますから、望み得る品質が最大限に保てます。しかしながら、多くのDVDや放送プロダクションスタジオはこの方式を採らず、フィールドをMPEG-2の中にそのまま持ち込む"ハードテレシネ"を使っています。

これらを扱う手順は後述します。その前に、素材の見分け方のガイドを

NTSC 地域:

• MPlayerで再生中にフレームレート表示が24000/1001に変わり、その後変化が無ければ、中身はほぼ確実に"ソフトテレシネ"されたプログレッシブです。
• MPlayerで再生中のフレームレート表示が24000/1001と30000/1001の間を行ったり来たりして、時折"コーミング（櫛の歯状のシマシマ）"が見える場合。複数の可能性があります。24000/1001部分の中身はほぼ確実に"ソフトテレシネ"されたプログレッシブです。30000/1001fpsの部分は、ハードテレシネされた24000/1001fpsか、毎秒60000/1001フィールドのNTSCビデオの両方の可能性があります。この部分を判断するには続けて下を読んで下さい。
• MPlayerで再生中のフレームレート表示が一度も変化せず、動きのあるフレーム全てで櫛状ノイズが出たら、毎秒60000/1001フィールドのNTSCビデオです。
• MPlayerで再生中のフレームレート表示が一度も変化せず、5フレーム毎にそのうち2フレームで櫛状ノイズが出たら、中身はハードテレシネされた24000/1001fpsです。

PAL 地域:

• 櫛状ノイズが全く出ない場良い、中身は2:2プルダウンです。
• 櫛状ノイズが0.5秒単位で出たり出なかったりを繰り返す場合、中身は2:2:2:2:2:2:2:2:2:2:2:3 プルダウンです。
• 動きのある箇所すべてで櫛状ノイズが出る場合、中身は毎秒50フィールドのPALビデオです。

ヒント：

MPlayerの再生はスローダウンやコマ送りができます。スロー再生はオプションの -speed 0.2 など。コマ送りは、再生中に" . （ピリオド）"キー。一回押すと1フレーム進みます*2。

14.1.2. 固定quantizer vs. マルチパス †

動画のエンコードでは様々な品質を幅広く狙う事が出来ます。最新のコデックとコデックに渡す前の圧縮（ダウンスケーリングやデノイズなど）を使えば、90〜110分のワイドスクリーン映画を非常に良い品質で700MBに収める事が可能です。さらに、ものすごく長い種類の映画を除けば、1400MBあれば完璧に近い品質になるでしょう。

映像をエンコードするには三つのアプローチがあります。すなわち、コンスタント・ビットレート(CBR), コンスタント・quantizer, そして マルチパス (ABR, または平均ビットレート)。

Note:

ABRエンコードをサポートするコデックの多くは2パスエンコードしかサポートしていません。他方、x264,xvid,libavcodecではマルチパスができます。これはパスを重ねる毎に地味に品質が向上するものです。ただし、4パス程度やれば、それ以上やっても違いは計測も困難ですし、まして目で見て解るというものでもないです。ですので、このセクションでは2パスとマルチパスの区別はしない事にします。

どのモードでも、ビデオコデック（例えばlibavcodec）はビデオフレームを16x16ピクセルのマクロブロックに分割し、各マクロブロックにquantizerをかけます。quantizerが低い程、画質は良くなり、ビットレートは高くなります。マクロブロックに適用するquantizerの決め方は一定ではありません。高度な調整が可能です（むちゃむちゃ単純化した説明ですが、基本的なコンセプトと思って下さい）。

コンスタント・ビットレート(CBR)の場合
ビデオコデックは、指定ビットレート以下に収まるように必要なだけディテイルを破棄します。もし、本当にサイズを気にしないなら、CBRを使ってビットレートを無限大に設定しよう（例えば10000Kbitなど、事実上の無限大）。ビットレートに制限が無い場合、コデックは全てのマクロブロックに最も低いquantizerを使います（libavcodecの場合、"vqmin"で指定した値。デフォルトは2）。もっと低いビットレートを指定するとコデックに高いquantizerの使用を強制することになります。映像の品質はまず確実に劣化する事でしょう。これを避けるには、映像のダウンスケーリング（やりかたは後述）が必要になるかも知れません。一般論としては、品質を求めるならコンスタント・ビットレート(CBR)は避けるべきです。

コンスタント・quantizerの場合
コデックは全てのマクロブロックに同一のquantizerを使います(libavcodecでは"vqscale"で指定した値)。ここで望み得る最高画質は、くどいようですがビットレートを無視するなら、"vqscale=2"を使おう。結果はCBR,vbitrate=無限大,vqmin=2(デフォルト値)と同じです。

コンスタント・quantizerの問題点は、もっと高いquantizerを使っても、見た目に差がでないマクロブロックがあり得ると言う事です。無意味に低いquantizerでビットを無駄にする事はないですよね？CPUサイクルは時間がある限り使えますが、ハードディスクスペースは有限です。

2パスエンコードの場合
1stパスはCBRでエンコードします。だけでなく、各フレームのエンコード結果をログに記録します。2ndパスでは、この記録を参照しながらquantizer値を決めていきます。速いアクションやディテイルの少ない場面では高めに、動きの少ない場面やディテイルの多い場面では低めのquantizerを使います。

vqscale=2はビットの無駄。vqscale=3では最高画質になりません。仮に、DVDをvqscale=3でリップして、結果が1800Kbitだったとしましょう。もしvbitrate=1800で2パスエンコードをすれば、同じビットレートで画質はもっと良くなります。

進むべき道は2パスだ！と思ったアナタ。次の問題はビットレートをいくつにするか？ですが、実はコレ、決まった解答がありません。理想としては画質とファイルサイズのベスとバランスをもたらすビットレートを選びたいところですが、これは素材映像の内容次第です。

もし、サイズを気にせず、高画質リッピングをしたいのであれば、2000Kbit プラマイ200Kbitから始めて見よう。速いアクションや細かいディテイルの素材、もしくはあなたの目が非常にセンシティブ、なら、2400や2600でも良いかと。中には1400Kbitでも違いのわからないDVDもあります。感覚を掴むために短いクリップをビットレートを変えてエンコードしてみる事をお奨めします。

特定のファイルサイズに収めたい場合、ビットレートを計算する必要があります。しかしその前に、音声の為にとっておくスペースの事を忘れないで。先に音声だけリッピングした方が良いです。ビットレートを求める計算式は以下の通り。

bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) * 1024 * 1024 / length_in_secs * 8 / 1000

例えば、2時間の映画を702MBのCD1枚に、60MBのオーディオ・トラックと一緒に入れるなら、映像ビットレートは以下の通り。

(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps

14.1.3. 効果的にエンコードするための制限事項 †

最高画質を追求する場合、MPEG系圧縮の特徴からくるいくつかの制限事項を守る必要があります。MPEGは映像をマクロブロックと呼ばれる16x16の正方形に分割します。各マクロブロックは、輝度（強度）情報を表す4個の8x8ブロックと、2個のハーフ・レゾリューション8x8ブロック（red-cyan 軸とblue-yellow軸）で構成されます。手許の動画の横幅と高さが16の倍数でない場合でも、エンコーダは映像全体をカバーできるだけの16x16マクロブロックを使うので、余聞な無駄が出ます。
ですので、目標ファイルサイズの範囲で最高画質を求める場合は、16の倍数以外の縦横は使わないようにしよう*3。

多くのDVDには端の所に黒帯があります。これをそのままにしておくと画質に複数の悪影響が出ます。

1. MPEG-type圧縮は、周波数領域変換への依存度が高い。中でも離散コサイン変換(DCT,Discrete Cosine Transform)。これはフーリエ変換に似たもの*4。この手のエンコードはパターンの描写とスムースなトランジションに強いが、シャープなエッジに弱い。シャープなエッジをエンコードするには大量のビットが必要で、不足する場合は「リンギング」として知られるアーティファクト*5が現れる。

周波数変換(DCT)は各マクロブロック単位で行われる（実際には各ブロック単位）。従って問題は、ブロックの中にシャープなエッジがある場合にだけ発生する。黒帯がきっちり16ピクセルの倍数の位置で始まっていれば、問題は無い。しかし、DVDの中の黒帯がそうした位置で始まっている事は滅多に無いので、実用上は常にcropが必要になります。

周波数領域変換に関する補足。MPEG-type圧縮は、モーションベクトルを使ってフレーム間の差異を把握します。モーションベクトルは、その性質上、映像のエッジから新たにフレームインしてくるものに弱い。というのは、それは以前のフレームには存在しないものだから。エンコードする対象範囲が映像で埋め尽くされている場合、映像のエッジから出て行くものについては問題ありませんが、黒帯があると問題が生じます。

2. MPEG-type圧縮は、ベクトルを保存します。ベクトルとは、直前フレームのうち、次のフレームを生成するために次のマクロブロックにコピーすべき部分を示すものです。マクロブロックの中に黒帯が有る場合、他のマクロブロックから入って来たモーションベクトルが黒帯を上書きします。これは、上書きされた黒帯を元通りに塗りつぶしたり、もっと多くの場合、モーションベクトルを使わずにマクロブロック内の変化を１から符号化し直すといった事になるので、大量のビット消費の発生を意味します。どちらが発生するにせよ、エンコードの効率は非常に悪化します。

この場合も、黒帯がきっちり16ピクセルの倍数の位置で始まっていれば、問題はありません。

最後に、映像の中程にあるマクロブロックに、映像のエッジからオブジェクトが進入してくる場合を考えてみましょう。MPEG-type圧縮は「映像だけをコピーして、黒帯は除外しろ！」といった事ができません。ですから黒帯も中程のマクロブロックにコピーされる事になります。ここでも映像をしかるべき内容に書き戻す為に大量のビット消費が必要になります。

映像がエンコード対象範囲のエッジに向かって走っているような場合（＊パン？＊）、MPEGには特別な最適化*6があります。エンコード対象範囲の外から来るモーションベクトルに対して、連続的にエッジのピクセルをコピーするというものです。この機能は、黒帯がある場合は無意味です。前述の問題1や2とは異なり、黒帯がきっちり16ピクセルの倍数の位置で始まっていてもこの問題は発生します。

4. 黒帯が完全に真っ黒でなんの変化が無かったとしても*7、それをカバーするマクロブロックを扱う必要があるので、少なくとも多少のオーバーヘッドが生じます。

これらの理由から、黒帯は全てクロップで取り除く事を推奨します。さらに、映像のエッジにノイズ/歪みがある場合は、これも取り除くほうが符号化効率は良くなります。可能な限りオリジナル映像を残したいビデオ愛好家はこの意見に反対するかも知れません。しかし、コンスタント・quantizer出ない限り、クロッピングで得られるメリットは映像の端っこを切り落とすデメリットよりも明らかに大きいです。

14.1.4. CropとScale †

前章に従ってエンコード前の映像サイズは縦横とも16の倍数にすべきです。これをするには、クロップ、スケール、またはその両方を使います。

クロッピングでは、画像にダメージを与えない為のガイドラインがいくつかあります。通常のYUVフォーマット,4:2:0は、彩度（色度）情報を、サブサンプリングされた形で保存しています。これは、彩度情報は輝度（強度）情報の半分しかサンプリングされて無いという事です。次の図を見て下さい。Lはluma(輝度)、Cはchroma(彩度)です。

ご覧のように、映像の横行と縦列はペアになっています。ですから、クロップする際には開始位置と縦横の数値は、偶数でなければなりません。もし奇数にした場合は彩度情報がきちんと輝度情報にマッチしなくなってしまいます。理論上は、クロップの開始位置を奇数値にする事は可能ですが、この場合、輝度情報のリサンプリングが必要になるので潜在的に画質劣化の危険があります。また、cropフィルタはこれをサポートしていません。

次に、インターレースド映像は下図のようにサンプリングされています。

ご覧のように、パターンは４行単位です。ですからインターレースド映像をクロップする場合、y-offsetとクロップ範囲の高さは4の倍数でなければなりません。

DVD映像の解像度はNTSCでは720x480、PALでは720x576です。ここに、映像がフルスクリーン (4:3) か ワイドスクリーン (16:9)かを示すフラグ、アスペクト・フラグというものが書き込まれています。大半とは言いませんが、多くのワイドスクリーンDVDは、厳密には16：9ではなく、1.85:1 か 2.35:1 (シネスコープ*8)。これは、映像の中にクロップすべき黒帯が含まれていると言う事になります。

MPlayerにはクロップ範囲を検出するためのフィルタがあります("-vf cropdetect")。MPlayerでの再生時に"-vf cropdetect"を使うと、クロップすべき範囲を自動検出し、ターミナルにお奨めのクロップ値を表示します。正確な値を出すには、端っこまで映像がみっちりつまっている場面になるまで再生して下さい。

次に、このcropdetectが出した値をテストして、クロップ範囲を微調整します。rectangleフィルタを使うと、映像にクロップ範囲を重ねて表示するので微調整がやり易いです。

スケーリングすべきでないケースというのがあります。インターレースド映像では、縦方向のスケーリングは困難ですので、インターレースを残す積もりなら、通常、スケーリングに手を出すべきではありません。スケーリング抜きで縦横を16の倍数に揃えたい場合は、映像の端っこも切り捨てて下さい。黒帯はエンコードでは悪影響が大きいので残すべきではありません。

MPEG-4は16x16のマクロブロックを使うので、エンコードする映像の縦横は16の倍数が良いでしょう。それ以外では、低ビットレートでは特に、画質が劣化します。ですからクロップ範囲は、黒帯ギリギリではなく、16の倍数になるように幅と高さを切り捨てましょう。前述のように、クロップ値のY-オフセットを切り捨てる高さの半分にすると映像の高さの真ん中からクロップできます。さらにDVDのサンプリング方式に合わせてオフセットを偶数にする事を忘れないように（実際、クロップやスケールで奇数禁止は鉄則です）。映像の僅かな部分といえど切り捨てたくない場合は、スケーリングで代用しよう。詳しいやり方は後述の事例の中で書きます。cropdetectフィルタは、デフォルトでパラメータを16の倍数に丸めるようになっていますから、これらを全て自動でやらせる事もできます。

映像部分の端っこにある"half black"ピクセルにも注意して下さい。これもクロップできっちり切り捨てるように。灰色ピクセルにビットを使うよりは、実の映像に回すほうが良いですから。

ここまでが全部終わった段階で、映像の縦横比がきちんと1.85:1 や 2.35:1になっている事は少ないでしょう。まぁ、似たような比にはなってると思いますが。手動で新しいアスペクト比を計算する事もできますが、MEncoderでlibavcodecを使う場合は、autoaspect(lavc用 ,xvid用)というオプションが使えます。これは自動で新しいアスペクト比を計算するものです。ピクセルを正方形にする目的では、決してスケールアップをしては行けません。ビットの無駄です。スケーリングは再生時にすべきものです。正しい解像度で表示するには、aviの中のアスペクト・フラグ*9を読めるプレイヤを使えば済みます。残念な事に、プレイヤの中にはaviの中のアスペクト・フラグに非対応のものもありますから、そうした場合はスケーリングせざるを得ないでしょう*10。

14.1.5. 解像度とビットレートの選択 †

固定quantizer以外でエンコードする場合、ビットレートを指定する必要があります。ビットレートの概念は非常に簡単なもので、「１秒ぶんのムービー保存に必要なビットの(平均)数」です。通常、単位はキロビット(1000ビット)/秒(＊kbps。大文字はキロバイトになるので注意＊）です。ディスク上のムービーのサイズは、

ビットレート × 映像の長さ(秒) + 若干の"オーバーヘッド"

になります（オーバーヘッドについてはAVIコンテナ?の項などを参照して下さい）。その他のパラメータ、スケーリングやクロップなどを変更しても、ファイルサイズが変わる事はありません。*11

ビットレートと解像度は比例しません。つまり、 200 kbit/sec ,320x240のファイルと、800 kbit/sec ,640x480では画質が異なるという事です!。理由は以下の通り:

1.知覚上の理由:

映像をスケーリングで拡大した場合、MPEGアーティファクトが目に見える大きさになります。アーティファクトはブロックの大きさ(8x8)単位で発生します*12。フルスクリーンで見た場合、4800の小さなブロック（＊640x480時の8x8ブロックの数＊）では目に見えないエラーも、1200の大きなブロックでは目立ちます。

2.理論上の理由:

映像をスケーリングで縮小し、かつ同じサイズのブロック(8x8)を周波数領域変換に使う場合、高周波数帯に移動するデータ量が増えます。ざっくり言って、各ピクセルに詰め込まれるディテイルが増えます。ですから、縮小した映像の空間軸の情報量は1/4になるにかかわらず、周波数領域の情報量は大きいままになります（オリジナルの640x480映像が高周波数帯をあまり使わない映像だった場合）
(＊この段落、わけわかめ＊)

過去のガイドでは、適切なビットレートと解像度を決めるには"bits per pixel"を推奨していました。しかし上記の理由により、これは通常、不適切です。より良い手段として、ビットレートスケールが解像度の平方根に比例する事（＊bitrates scale proportional to the square root of resolution＊）、が考えられます。この考え方では、320x240 ,400 kbit/secは概ね640x480, 800 kbit/secに相当します。しかし、このやりかたはまだ理論上も経験則も厳密な裏付けがとれていません。さらに、素材映像の条件は、ノイズ、ディテイル、動きの量などなど、非常にバラエティに富みますから、bits per length-of-diagonal(平方根を使ったbits per pixelの類似物)のための一般的な推奨値を決めるのは無意味な事でしょう。

ここまでは、適切なビットレートと解像度を選ぶのは難しいというお話でした。

＊訳注：管理人の知る限り、以前はここにはbpp（"bits per pixel"）の計算式が記載されていた。記憶の範囲では2005/春先から2005/夏頃まで。

14.1.5.1. 解像度の計算 †

まず、エンコード後のアスペクト比を計算します。

ARc = (Wc x (ARa / PRdvd )) / Hc

where:

• Wc, Hc はクロップ後の映像の幅と高さ。
• ARa は表示用のアスペクト比。普通は 4/3 か 16/9。
• PRdvd はDVDのピクセルレシオ。PAL DVDは 1.25=(720/576) NTSC DVDでは 1.5=(720/480)。

これで、Compression Quality (CQ) 換算係数を使って、XとYの解像度の計算ができます。

ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16
ResX = INT( ResY * ARc / 16) * 16

さて、CQとはなんでしょうか？
CQとはエンコードのピクセルあたりのビット数と、フレームあたりのビット数を示すものです。ざっくり言って、CQが大きい程、エンコード後にアーティファクトを見る確率が低いです。しかし、目標とするサイズが決まっている場合（CD1枚とか2枚とか）、使えるビット数には上限があります。ですから、圧縮率と画質のバランスの良いところを見つけなければなりません。

CQはビットレートと解像度の両方に影響されます。CQを上げるには、映像の解像度を縮小するのが一般的です。目標サイズと映像の長さは固定ですから、そこからビットレートを計算するわけです。
CQが0.18以下の場合、非常にブロックノイズが多くなるのが普通です。というのは、各マクロブロックの情報を符号化するにはビット数が不足するからです（MPEG4は他のコデック同様に、複数ピクセルをブロックにグループ化して圧縮します。ビット数が不十分だとこのブロックのエッジが見えてしまいます）。ですから、CQは1CDなら0.20〜0.22,2CDなら0.26〜0.28程度が賢いでしょう。

CQは単なる指標に過ぎない事に注意して下さい。素材映像の内容次第です。Bergman*13などはCQ0.18で充分でしょうが、反対に非常に動きの多いマトリックスなどでは足りません。一方、CQ3.0以上はビットの無駄で、特に画質向上は無いでしょう。

＊訳注: CQ ( Compression Quality ) = bpp = vbitrate * 1000 / (width * height * fps)

14.1.6. フィルタリング †

MEncoderのビデオフィルタは良いエンコードをするには、不可欠です。ビデオプロセッシングは全て、フィルタ経由で行われます。--ほんのちょっと例を挙げると、クロップ、スケーリング、色調整、ノイズ除去、シャープニング、デインターレース、テレシネ、逆テレシネ、デブロッキング。 大量の入力フォーマットと共に、使えるフィルタが多岐にわたる事が、他の同種のプログラムと比べた場合のMEncoderの主な利点です。

フィルタを使うにはチェインの中で-vf オプションを使います。

-vf filter1=options,filter2=options,...

大半のオプションは子オプションで数値をいくつか、コロン（:）で区切って指定しますが、書式はオプションによって異なります。詳細は使いたいオプションのman pageを読んで下さい。

フィルタは書いた順番に適用されます。例えば以下のように書いた場合、

-vf crop=688:464:12:4,scale=640:464

最初にcropで左上起点の(12,4)の位置から688x464ピクセルをくり抜き、そのくり抜いた映像を640x464にスケーリングします。

フィルタの中には、フィルタチェインの先頭か、少なくとも前のほうに置く必要があるものがあります。他のフィルタが加工してしまう前に、ビデオデコーダが吐いた情報を読む必要があるフィルタです。
代表例はpp（postprocessing, この内 deblock か dering のみ）,spp （mpegアーティファクト除去用のもう一つのポストプロセッサ）,pullup (逆テレシネ), softpulldown (ソフトテレシネとハードテレシネの変換)。

一般論としては、オリジナルのDVD素材になるたけ近い映像にするには、フィルタはできるだけ少ない方が良いです。クロッピングは前述のように必要な事が多いですが、スケーリングは避けましょう。もちろん、スケーリングをする方がもっと高いquantizerを使えるのですが、ここでは回避したいと思います。このドキュメントのテーマは「画質の為にビットを使う」ですから。

また、ガンマ,コントラスト,ブライトネスなどの調整もヤメましょう。あなたのディスプレイで奇麗に見えるものが他でもそうとは限りません。そうした調整は再生時に限るべきです。

フィルタは少ない方が良いとはいえ、非常に軽いデノイズフィルタは掛けたいと思う人が居るかもしれません。たとえば-vf hqdn3d=2:1:2。繰り返しますが、ここでのテーマはビットの有効活用です。ノイズの為にビットを使う事はありませんよね？ノイズは再生時に付加できるものですし。hqdn3dのパラメータを増やすと圧縮効率はさらに向上します。しかし増やしすぎると映像が劣化します。ここで提案した(2:1:2)は非常に保守的なものです。いろいろ弄って結果を試してみて下さい。

＊訳注：デフォルトはhqdn3d=4:3:6。$ mplayer XXX.mpg -vf hqdn3d=4:3:6 などで試す。mplayerOSXなら環境設定で -vf hqdn3d=4:3:6 など

14.1.7. インターレースとテレシネ †

ほとんど全ての映画は24fpsで撮影されています。NTSCは30000/1001 fpsですから、映画の24fpsの映像をNTSCのフレームレートで正しく再生するにはちょっとした加工をしなければなりません。このプロセスを3:2 プルダウンと言います。一般的にはテレシネと呼ばれます（プルダウンはテレシネ変換の一工程として行われる事が多いので）。ざっくり言うと映画フィルムの再生速度を24000/1001 fpsにスローダウンし、4フレーム毎に同じフレームをリピートします。

しかし、PAL DVDの映像はこの加工はされていません（技術的にはPALテレシネも存在します。2:2プルダウンと言いますが、実際上ここでは問題になりません）。24fpsのフィルム映像をそのままPALの25fpsで再生します。映画は地味に早回しになりますが、宇宙人でもない限り違いは解らないでしょう。オーディオトラックの再生時間はNTSC DVDより4%短くなるのですが、PAL DVDはほとんど、オーディオにピッチ補正がかかっているので、25fpsで再生しても大丈夫です。

PAL DVDでは素材映像自体はテレシネ処理されていないので、フレームレートはさほど問題になりません。素材は25fpsですからリッピングも25fpsで済みます。
しかしながら、NTSC DVDのリッピングでは、逆テレシネ変換が必要な事があります。

24fps撮影の映画をNTSC DVDに入れる場合、映像はテレシネ処理された30000/1001fpsか、24000/1001fpsのプログレッシブ（DVDプレイヤが再生時にテレシネ処理）かのどちらかです。
これとは別に、TVシリーズはインターレースされています（バッフィ・ザ・ヴァンパイアキラーとか）中にはプログレッシブとインターレースが混ざったものもあります（エンジェルとか24とか）。

様々なケースを巧く捌くにはHow to deal with telecine and interlacing within NTSC DVDs?を読む事を推奨します。

でも、ほとんど映画しかリッピングしないなら24fpsプログレッシブかテレシネ処理された映像がほとんどでしょう。この場合はpullup " -vf pullup,softskip " フィルタが使えます。

14.1.8. インターレースド映像のエンコード †

エンコード素材がインターレースド（NTSCまたはPAL video）だった場合、デインターレースをするかどうか、決める必要があります。デインターレースをすれば映像はコンピュータのモニタやプロジェクタなどのプログレッシブ・スキャン機器で見やすくなります。一方、難点もあります。毎秒50、または60000/1001フィールドの再生速度が、毎秒25または30000/1001フレームに半減するということです。これはざっくり言って動きの激しい場面で情報量が半減すると言う事です。

ですから、高画質エンコードを目指すなら、インターレース解除はしないのがおすすめです。デインターレース映像をプログレッシブ・スキャン機器で見る際には再生機器/ソフト側でインターレース解除ができますし、将来の再生機器はインターレース映像から50 または 60000/1001フレームを生成するフル・フィールドレートのデインターレースができるようにもなるでしょう。

インターレースド映像を扱うには特別な注意が必要です。

1. Cropの高さとy-offsetは4の倍数でなければならない。
2. 縦方向のスケーリングは全て、インターレースドモードの中でしなければならない。
3. ポストプロセスとデノイズフィルタは、フィールド単位で適用するように特に注意しない限り、期待通りに動かない可能性がある。さもないと画質劣化の恐れが有る。

これらの事に注意して、手始めの例を見て下さい：

 mencoder capture.avi -mc 0 -oac lavc -ovc lavc -lavcopts \
 vcodec=mpeg2video:vbitrate=6000:ilmv:ildct:acodec=mp2:abitrate=224

ilmv と ildct　オプションに注意して下さい。

14.1.9. Notes on Audio/Video synchronization †

MEncoder's audio/video synchronization algorithms were designed with the intention of recovering files with broken sync. However, in some cases they can cause unnecessary skipping and duplication of frames, and possibly slight A/V desync, when used with proper input (of course, A/V sync issues apply only if you process or copy the audio track while transcoding the video, which is strongly encouraged). Therefore, you may have to switch to basic A/V sync with the -mc 0 option, or put this in your ~/.mplayer/mencoder config file, as long as you are only working with good sources (DVD, TV capture, high quality MPEG-4 rips, etc) and not broken ASF/RM/MOV files.

If you want to further guard against strange frame skips and duplication, you can use both -mc 0 and -noskip. This will prevent all A/V sync, and copy frames one-to-one, so you cannot use it if you will be using any filters that unpredictably add or drop frames, or if your input file has variable framerate! Therefore, using -noskip is not in general recommended.

The so-called "three-pass" audio encoding which MEncoder supports has been reported to cause A/V desync. This will definitely happen if it is used in conjunction with certain filters, therefore, it is now recommended not to use three-pass audio mode. This feature is only left for compatibility purposes and for expert users who understand when it is safe to use and when it is not. If you have never heard of three-pass mode before, forget that we even mentioned it!

There have also been reports of A/V desync when encoding from stdin with MEncoder. Do not do this! Always use a file or CD/DVD/etc device as input.

14.1.10. Choosing the video codec †

Which video codec is best to choose depends on several factors, like size, quality, streamability, usability and popularity, some of which widely depend on personal taste and technical constraints.

• Compression efficiency: It is quite easy to understand that most newer-generation codecs are made to increase quality and compression. Therefore, the authors of this guide and many other people suggest that you cannot go wrong [1] when choosing MPEG-4 AVC codecs like x264 instead of MPEG-4 ASP codecs such as libavcodec MPEG-4 or XviD. (Advanced codec developers may be interested in reading Michael Niedermayer's opinion on "why MPEG4-ASP sucks".) Likewise, you should get better quality using MPEG-4 ASP than you would with MPEG-2 codecs.
  
  However, newer codecs which are in heavy development can suffer from bugs which have not yet been noticed and which can ruin an encode. This is simply the tradeoff for using bleeding-edge technology.
  
  What is more, beginning to use a new codec requires that you spend some time becoming familiar with its options, so that you know what to adjust to achieve a desired picture quality.

• Hardware compatibility: It usually takes a long time for standalone video players to begin to include support for the latest video codecs. As a result, most only support MPEG-1 (like VCD, XVCD and KVCD), MPEG-2 (like DVD, SVCD and KVCD) and MPEG-4 ASP (like DivX, libavcodec's LMP4 and XviD) (Beware: Usually, not all MPEG-4 ASP features are supported). Please refer to the technical specs of your player (if they are available), or google around for more information.
  

• Best quality per encoding time: Codecs that have been around for some time (such as libavcodec MPEG-4 and XviD) are usually heavily optimized with all kinds of smart algorithms and SIMD assembly code. That is why they tend to yield the best quality per encoding time ratio. However, they may have some very advanced options that, if enabled, will make the encode really slow for marginal gains.
  
  If you are after blazing speed you should stick around the default settings of the video codec (although you should still try the other options which are mentioned in other sections of this guide).
  
  You may also consider choosing a codec which can do multi-threaded processing, though this is only useful for users of machines with several CPUs. libavcodec MPEG-4 does allow that, but speed gains are limited, and there is a slight negative effect on picture quality. XviD's multi-threaded encoding, activated by the threads option, can be used to boost encoding speed ― by about 40-60% in typical cases ― with little if any picture degradation. x264 also allows multi-threaded encoding, which currently speeds up encoding by 15-30% (depending on the encoding settings) while lowering PSNR by about 0.05dB.

• Personal taste: This is where it gets almost irrational: For the same reason that some hung on to DivX 3 for years when newer codecs were already doing wonders, some folks will prefer XviD or libavcodec MPEG-4 over x264.
  
  You should make your own judgement; do not take advice from people who swear by one codec. Take a few sample clips from raw sources and compare different encoding options and codecs to find one that suits you best. The best codec is the one you master, and the one that looks best to your eyes on your display [2]!

Please refer to the section selecting codecs and container formats to get a list of supported codecs.

14.1.11. Audio †

Audioの問題はずっと簡単です。：品質を気にかけるなら、単にそのまま。エンコードしない。 AC3 5.1ストリームですら大半は448kbit/sです。その中には1ビットも無駄がありません。あるいは高品質なVorbisに音声をトランスコードしたいかもしれませんが、今、AC3 をpass-throughできるA/Vレシーバが無いからと言って、明日もそうであるとは限りません。将来的にはAC3ストリームをそのまま残すDVDリップが可能になるでしょう。AC3をそのまま残すにはエンコードの過程でビデオストリームにそのままコピーします。または、後でNUTやMatroskaのようなコンテナにmuxするために、AC3ストリームを抽出しておく事も出来ます。

mplayer source_file.vob -aid 129 -dumpaudio -dumpfile sound.ac3

上記で、source_file.vob の中のaudio track number 129をsound.ac3へダンプできます。（注意：DVDファイルは通常異なったオーディオ・ナンバリングを使う。ここではVOB audio track 129 はファイル中の 2nd audio track）。

とはいえ、映像にビットレートを割り振る為に音声をエンコードせざるを得ない場合もあるでしょう。多くの人はMP3 か Vorbisを選択します。後者は特に効率の良いモノですが、MP3の方がサポートするハードウェア再生機が多いです。ただし、状況は変わりつつ有ります。

まずはじめに、DVDの音声をオーディオコデックに入力できるWAVに変換します。例えば：

mplayer source_file.vob -ao pcm:file=destination_sound.wav -vc dummy -aid 1 -vo null

上記でsource_file.vobのsecond audio trackをdestination_sound.wavにダンプします。DVD音声はボリュームが低い事が多いのでエンコード前にノーマライズした方が良いかもしれません。その為のツール、例えばnormalizeは大半のディストリビューションで使う事が出来ます。WindowsユーザはBeSweetのようなツールで同じ事が出来ます。Vorbis か MP3、どちらでもお好きに。例えば：

oggenc -q1 destination_sound.wav

will encode destination_sound.wav with the encoding quality 1, which is roughly equivalent to 80Kb/s, and is the minimum quality at which you should encode if you care about quality. Please note that MEncoder currently cannot mux Vorbis audio tracks into the output file because it only supports AVI and MPEG containers as an output, each of which may lead to audio/video playback synchronization problems with some players when the AVI file contain VBR audio streams such as Vorbis. Do not worry, this document will show you how you can do that with third party programs.

14.1.12. Muxing †

Now that you have encoded your video, you will most likely want to mux it with one or more audio tracks into a movie container, such as AVI, MPEG, Matroska or NUT. MEncoder is currently only able to output audio and video into MPEG and AVI container formats. for example:

mencoder -oac copy -ovc copy  -o output_movie.avi -audiofile input_audio.mp2 input_video.avi

This would merge the video file input_video.avi and the audio file input_audio.mp2 into the AVI file output_movie.avi. This command works with MPEG-1 layer I, II and III (more commonly known as MP3) audio, WAV and a few other audio formats too.

MEncoder features experimental support for libavformat, which is a library from the FFmpeg project that supports muxing and demuxing a variety of containers. For example:

mencoder -oac copy -ovc copy  -o output_movie.asf -audiofile input_audio.mp2 input_video.avi -of lavf -lavfopts format=asf

This will do the same thing as the previous example, except that the output container will be ASF. Please note that this support is highly experimental (but getting better every day), and will only work if you compiled MPlayer with the support for libavformat enabled (which means that a pre-packaged binary version will not work in most cases).

14.1.12.1. Improving muxing and A/V sync reliability †

You may experience some serious A/V sync problems while trying to mux your video and some audio tracks, where no matter how you adjust the audio delay, you will never get proper sync. That may happen when you use some video filters that will drop or duplicate some frames, like the inverse telecine filters. It is strongly encouraged to append the harddup video filter at the end of the filter chain to avoid this kind of problem.

Without harddup, if MEncoder wants to duplicate a frame, it relies on the muxer to put a mark on the container so that the last frame will be displayed again to maintain sync while writing no actual frame. With harddup, MEncoder will instead just push the last frame displayed again into the filter chain. This means that the encoder receives the exact same frame twice, and compresses it. This will result in a slightly bigger file, but will not cause problems when demuxing or remuxing into other container formats.

You may also have no choice but to use harddup with container formats that are not too tightly linked with MEncoder such as the ones supported through libavformat, which may not support frame duplication at the container level.

8.1.10.1. Limitations of the AVI container †

Although it is the most widely-supported container format after MPEG-1, AVI also has some major drawbacks. Perhaps the most obvious is the overhead. For each chunk of the AVI file, 24 bytes are wasted on headers and index. This translates into a little over 5 MB per hour, or 1-2.5% overhead for a 700 MB movie. This may not seem like much, but it could mean the difference between being able to use 700 kbit/sec video or 714 kbit/sec, and every bit of quality counts.

In addition this gross inefficiency, AVI also has the following major limitations:

1.Only fixed-fps content can be stored. This is particularly limiting if the original material you want to encode is mixed content, for example a mix of NTSC video and film material. Actually there are hacks that can be used to store mixed-framerate content in AVI, but they increase the (already huge) overhead fivefold or more and so are not practical.

2.Audio in AVI files must be either constant-bitrate (CBR) or constant-framesize (i.e. all frames decode to the same number of samples). Unfortunately, the most efficient codec, Vorbis, does not meet either of these requirements. Therefore, if you plan to store your movie in AVI, you will have to use a less efficient codec such as MP3 or AC3.

Having said all that, MEncoder does not currently support variable-fps output or Vorbis encoding. Therefore, you may not see these as limitations if MEncoder is the only tool you will be using to produce your encodes. However, it is possible to use MEncoder only for video encoding, and then use external tools to encode audio and mux it into another container format.

8.1.10.2. Muxing into the Matroska container †

Matroska is a free, open standard container format, aiming to offer a lot of advanced features, which older containers like AVI cannot handle. For example, Matroska supports variable bitrate audio content (VBR), variable framerates (VFR), chapters, file attachments, error detection code (EDC) and modern A/V Codecs like "Advanced Audio Coding" (AAC), "Vorbis" or "MPEG-4 AVC" (H.264), next to nothing handled by AVI.

The tools required to create Matroska files are collectively called mkvtoolnix, and are available for most Unix platforms as well as Windows. Because Matroska is an open standard you may find other tools that suit you better, but since mkvtoolnix is the most common, and is supported by the Matroska team itself, we will only cover its usage.

Probably the easiest way to get started with Matroska is to use MMG, the graphical frontend shipped with mkvtoolnix, and follow the guide to mkvmerge GUI (mmg)

You may also mux audio and video files using the command line:

mkvmerge -o output.mkv input_video.avi input_audio1.mp3 input_audio2.ac3

This would merge the video file input_video.avi and the two audio files input_audio1.mp3 and input_audio2.ac3 into the Matroska file output.mkv. Matroska, as mentioned earlier, is able to do much more than that, like multiple audio tracks (including fine-tuning of audio/video synchronization), chapters, subtitles, splitting, etc... Please refer to the documentation of those applications for more details.