remove
powerd by nog twitter


コーデック別画質実験(2004/02/15更新)



  コーデックは「映像」の画質と大きくかかわっています。いかに美しい映像を保存できるかを、
  有名なコーデックで行いました。なお、ある程度誤差が出ることは理解してください。

  注意!実験方法に不備があるかもしれません。100%信用があるデータではありません。
  内容に関しての苦情や質問はジャンパーズホームページの掲示板を利用してください。




今回比較するコーデックの表です

コーデックとそのバージョン特徴と愛称入手場所
MS-MPEG4 V2 (3920バージョン)時代遅れ気味めざせ!あにぺぐ
DivX Pro(5.11)世界のスタンダードDivX.com
WMV9VCMインターレースの友Windows Media 9 Series
XviD-1.0OGGの恋人Koepi's Media Development Homepage
VP6 (6-1-0-2)MPEG4キラーOn2 Technologies

  これら5種類の優れたコーデックを利用して、映像の再現性(画質)を調査します。
  ビットレートや設定が公平にならないですが、普通に考えられる対処はします。



  比較実験の方法

  640×480、30fps、300フレームの無圧縮(24bit)AVI動画をAviUtlによりフィルタ無しでエンコード。
  設定のステータスは公表します。その画質の再現性や特徴を「拡大目視」「ヒストグラム」などで評価します。

  使用する動画の内容

  2秒(60フレーム)毎に、5つの測定基準を作った動画を作りました。

  0〜2秒(1〜60フレーム) → 5ドットスクロール(動き成分と映像)
  仕掛けと解説:左下には砂時計の静止画、右上→左上とボールが動画として描かれています。
  背景は白で圧縮が利くようにノイズなどがありません。動き方向でどのように圧縮が効くか、
  静止画はその動き方向のアルゴリズムの影響を受けないかどうか調べるために作りました。

  2〜4秒(61〜120フレーム) → シーンチェンジ気味の複雑な動き(MPEGの苦手な動き)
  仕掛けと解説:JPEGやMPEGなどは、「8×8」や「16×16」ピクセルの「内部構造」を持っています。
  そのピクセル構造に歯向かうようにマスをずらし黒枠でゴースト(色ズレ)の起こりやすい映像にしています。
  また、予想できないような動きにしてあるため、圧縮がしにくいシーンチェンジのような動画になっています。
  更に、2フレームずつ動くようにして、2フレーム間は静止画であるようにしました。これは、2フレーム間では、
  フレーム間圧縮(時間軸方向圧縮)ができることになります。最後は砂嵐ような複雑な動画にしています。
  これは、VBRの効きを試すために作りました。

  4〜6秒(121〜180フレーム) → 複雑な静止画4枚(15フレームずつ)
  仕掛けと解説:シーンチェンジ検出と、「いきなり複雑で緻密な映像」が映ると、どのようにフレーム処理
  されるかを調べました。GOP構造を持つコーデックでは、脈動する様子を知ることができます。
  また、赤割れしやすい「バラ」つぶれやすい「辞書の文字」を入れて圧縮によるつぶれ具合を観察できるようにしました。

  6〜8秒(181〜240フレーム) → カラーグラデーション静止画2枚(白黒、カラー)
  仕掛けと解説:1枚目は「輝度」の減り方を調べるために、左端はRGB(255、255、255)右端は(0、0、0)になるように、
  Ulead Photo Impactの機能でグラデーション化しました。
  2枚目は、「パステルカラー」レベルで良くデジタルノイズ化する色を選んでカラーバー化しました。
  縦方向より、横方向のほうが圧縮によるグラデーション劣化を知ることが出来るので、バーは横方向というわけです。

  8〜10秒(241〜300フレーム) → 適当なフェードインフェードアウト(周期が短いのでフラッシュに見える)
  仕掛けと解説:10フレーム間隔で「白→黒」「黒→白」となるフェードインフェードアウトを、
  AviUtlのプラグインにより作成しました。コーデックにとっては急激な輝度変化にならない程度に
  設定してあるので、このエフェクトが苦手なコーデックの場合だとキーフレーム挿入による無駄が生じます。

  なお、この動画は公開したいのですがサーバスペースの問題上、圧縮されたものの配布となります。



  最大ビットレートによる比較
コーデックとそのバージョン設定容量
MS-MPEG4 V2 (3920バージョン)6000kbps Crispness100 Key10second4,910,588バイト
DivX Pro(5.11)OnePassQuality100% Slowest MaxKey3008,112,264バイト
WMV9VCMOnePassQ100 Quality100 MaxKey10Second6,867,566バイト
XviD-1.0OnePassQ100 H.263 Motion-6 VHQ-Wide
Max10000kbps MaxIfreamInterval300 BframeON
8,226,104バイト
VP6 (6-1-0-2)OnePassBest(VBR) MaxKeyInterval300 US100 AQ-Max633,777,568バイト

  簡単に設定できる範囲で、最大ビットレートになるようにセットをしました。

  画質の完全な比較ができないのは、「ビットーレート」をどのコーデックも完全一致させることができないからです。
  WMV9VCMの4MByteとDivXの4MByteの時の画質を知りたくても、調整に時間がかかるだけで、
  更にVBRや2-passなどの設定要素が絡み、同じフレームごとの圧縮率を知る事は不可能なので、
  とりあえずそのコーデックが出せる最高画質とは何かを突き止めようとした結果です。

  まずは、コーデックもビットレートも全く違うけど、そのコーデックのポテンシャルの比較になることを、
  知っておいてください。ビットレートが違うから、比較になってないとかではなく、「ポテンシャル」の問題です。

  注意点以下の通りです。
  ○ 全コーデックでMaxKeyFrameを10秒(300フレーム)間隔にしました。自動キーフレーム挿入の性能を知るためです。
  ○ 全てのコーデックで1-passのものを選びました。クオリティベースやビットレート指定がありますが、
  通常以上の高ビットレートを割り当ててあるので、そのコーデックが出せる最大の力だと思います。
  ○ XviDは設定により、画質と圧縮率をコントロールできますが、普通に使う範囲で設定しました。
  XviDは多くの設定が絡み合っているので、最高を選ぶ事が容易ではありません。
  ○ VP6も同じく、設定が複雑で最高のエンコード方法を選ぶのは容易でないので普通の設定で出来る範囲にしました。



  その1、シーンチェンジ61フレーム目の真実

  61フレーム目は、1〜60フレーム目とはまったく別の映像となります。
  この映像の切り替わりを「シーンチェンジ」と呼びます。このフレームでは、前のフレームの情報を
  受け継がないために、大量のビットレートを消費します。VBRの優れたコーデックやシーンチェンジ
  を検出するコーデックでは、シーンチェンジをキーフレームにして映像が崩れる現象に対応します。

  では、早速比較データを見てもらいます。
コーデックとそのバージョンキーフレーム検出容量実際の画質(ビットマップ)
MS-MPEG4 V2(3920バージョン)NG4,910,588DL(485,813バイト)
DivX Pro(5.11)OK8,112,264DL(478,999バイト)
バグ無しDL(540,847バイト)
WMV9VCMOK6,867,566DL(425,718バイト)
XviD-1.0OK8,226,104DL(454,974バイト)
VP6 (6-1-0-2)OK3,777,568DL(476,062バイト)
未圧縮(24bitRGB)ソース全キーフレーム276,491,304DL(187,671バイト)

  解説をします。何度も言いますが、ビットレートや設定が違います。共通点は「One-Pass」ということです。
  下の解説で使っている映像は、「同じ場所周辺を4倍に拡大」しています。この画像のソースは上のビットマップですので、
  疑いを持たれた方はビットマップをダウンロードして比較することをオススメします。

  まず、MS-MPEG4ですが、シーンチェンジにもかかわらずキーフレームではありません。
  
  丸で囲んだように、ベリベリノイズが出ています。画質が良いとは言えません。使い物にならないことは明白です。
  これを回避するために、「m4c」というソフトが生まれましたが今となっては使う意味がないと思います。

  次にDivX5.11ですが、非常に出来が悪いと思います。ぼかしフィルタのような変なノイズがあります。
  
  DivX5.11のOnePassなんて使う人いないでしょうが、問題アリです。
  圧縮率が高いから・・・と言い訳できるものかどうかは、疑問です。

  追記:DivX5.11のベリベリノイズバグは、「VFW」読み込みで起こることが
  確認されました。情報提供ありがとうございます。ffdshow経由で同じフレームを読み込んでみました。
  
  DirectShow(ffdshow)の力を使い、デコードした場合です。わずかに色ズレしています。
  非常に優秀だと思います。

  次に、WMV9VCMについて解説します。
  
  特に問題は無さそうです。非常に良いと思われます。他のコーデックより、高ビットレートが出せるぶん、
  画質に関しては文句がつけられないと思われます。ただし、赤黒いマスの黒線が太くなっています。

  次に、XviDです。
  
  優秀です。特に問題は無く、クリアだと思います。WMV9VCMと互角以上の再現率です。
  WMV9VCMと同じく、赤黒いマスの黒線が太くなっています。

  次に、VP6です。クオリティを100にしても他のコーデックの半分程度の容量です。
  
  バージョン「6.0.7.3」の「vp6dec.ax」を取り出しデコードに使っています。
  バグの粉っぽさも消えモスキートノイズも無くなり、他のコーデックと大差無しです。

  最後にこれがソースです。これに一番近いものが画質が良い(再現性が高い)と言えます
  

  並ばないとわかりにくいと思われるので、比較専用のページを作りました。
  ブラウザクラッシャー並みに重いページですので、能力の高いPCでの閲覧を希望します。よろしくお願いします。
  比較用ページ

  ついでに、今回使用したサンプルイメージ動画を公開します。10秒の動画の内容はこの通りです。
  VP6はすごいと思われます。
  VP6形式です。コーデックを各自用意してください。(4MB弱)
  なお、この動画の著作権をジャンパーは放棄しております。この動画で起こった事故や故障の責任は取れません。
  自由に改変、実験、検証や転載をしてもOKですが、zipファイルに直接リンクはしないで下さい。

  この動画のソースの未圧縮24bitRGB版は270MBあり、ダウンロードできませんのでご注意ください。



  結論と解説

  まず、61フレーム目を圧縮したビットマップファイルの「容量」を見てください。
  映像のクリアな24bit未圧縮ソースは約190kbyteまで圧縮されています。
  逆に、何故かDivXのファイルが一番圧縮されなくなくなりました。
  ZIPでサイズが縮まないということは、それだけ圧縮ノイズが出ていることになります。
  (ZIPアルゴリズムを妨げるような、複雑な映像にするノイズが含まれたビットマップであるということ)
  そう考えると、WMV9VCMは好成績であると言えます。

  次に、MS-MPEG4やDivX5.11は目に見えて盛大なノイズが出ています。
  ふつうに設定できる最大ビットレートを割り振ってもノイズが防げない事を示しています。
  これは、問題アリだと思います。DivXは内部は大丈夫で、デコーダをffdshowに変えることで解決します。
  また、VP6のはデコーダバージョン6-1-0-2のものだと粉っぽくなるようです。
  これは、6-0-7-3に付いているvp6dec.axで多少改善されます。

  WMV9VCMとXviD-1.0とDivX5.11は好成績です。「容量を気にしない」で保存する場合は、
  都合の良い画質が得られると思います。ただし、両者とも黒線が太くなるなどの弊害があることは事実です。
  これは、コーデック内部のピクセルフォーマットがYV12だったりするからですが(汗

  XviD-1.0とWMV9VCMとDivX5.11が高ビットレートを出せて、画質の面では強い。


  最大ビットレートによる比較2へ続く



もどる



Internet Explorer5以上、横解像度800以上でのの閲覧を推奨します
jumper