動画コーデックの比較

品質と圧縮率のバランス

2014.9.21作成 2014.10.6加筆・修正

コーデックの選択

収録から納品までさまざまなコーデックが使用される昨今、求められるクオリティとコストによってコーデックを選択する必要があります。私の職場はMacベースの編集システムなので、テレビ番組などの編集ではProRes 422 HQを基本にしています(制作会社さんの要望があれば、XDCAMやHDVコーデックでの納品もしています)。自主制作映画の完パケにもProRes 422 HQを使用していますが、メイキング映像などクオリティ重視ではない映像はXDCAM HD 422やビットレートを高めに設定したH.264を使用することもあります。

私の周囲もMac環境で編集されているところが多いのですが、コーデックの話題になると「ProRes 422 LTで十分」、「素材はHDCAMだけれども、編集はProRes 422 HQじゃないと画質が厳しい」、「ProRes 422を使っているけど全く問題ない」、「番組をHDVコーデックで完パケしているけど何の問題もない」など、見解はさまざまです。情報番組などの比率が高いところは圧縮率が高めで、博物館の展示映像のような作品を作られているところは圧縮率が低めという印象があります。各社さんとも、コスト(作業時間含む)と品質のバランスをうまくとりながら作業されているのでしょう。

放送局に近いプロダクションさんでは、トラブル防止のためワークフローとともにコーデックも統一されており、番組以外の編集作業もそれに準じていることもあるようです。

ProResコーデックが出たての頃は、Appleのホワイトペーパー(技術白書)をもとにProRes 422で十分な品質であると考えていました。しかし実際に使用してみると、特定のシーンで圧縮による劣化が目立つことがわかりました。特定のシーンというのは森林でのロケ映像で、細かい木々の葉にまとわりつくモスキートノイズ(後述)と、木の幹に発生したブロック歪みが目立つのでした。その後全く別の番組編集時にも、やはり森林のロケテープをデジタイズした素材で圧縮による劣化が見られました。

テレビ放送は送出時のMPEG2圧縮で大幅に劣化するので、放送素材としてはProRes 422でもおおむね問題ないと考えています。しかし、ストレージなどの余裕があるのならば、できるだけ画質は落とさない方が良いだろうという考えのもと、ProRes 422 HQを常用する事にしたのです。

過去に何度かコーデックのテストを実施しましたが、著作権の都合でWEBでの公開はできませんでした。今回、私自身が撮影した映像を使用してテストを行いましたので、本サイトでその一部を公開します。

非可逆圧縮コーデックについて

非可逆、つまり劣化が伴う圧縮方式は、大きく二つの種類に分けられます。一つは1フレーム単位で空間圧縮する「フレーム内圧縮(イントラフレーム圧縮)」、もう一つは時間軸方向に複数のフレームをまとめて時間圧縮する「フレーム間圧縮(ロングGOP圧縮)」です。

イントラフレーム圧縮は、静止画の連続である動画を静止画1枚1枚の単位(フレーム単位)で圧縮します。単調な映像は圧縮しやすく、複雑な映像は圧縮しにくくなるため、ビットレートが制限される場合には複雑な映像ほど圧縮に伴う劣化が多く見られます。1フレーム毎の圧縮なので、ロングGOP圧縮よりも圧縮・伸張処理が軽く、ノンリニア編集に向いてます。先に例を挙げたProResはこちらに該当します。

ロングGOP圧縮は、複数のフレームをグループ化して圧縮します(GOP: Group Of Pictures)。ごく普通の映像では、時間軸方向の変化はそう多くはありません。前のフレームから変化した分(差分)だけを記録すれば、保存容量を節約できるという発想です。実際には、単に差分を保存するのではなく、動き補償など高度な技術が併用されています。また、GOPの中で基準となるフレーム(通称Iフレーム、Intra-coded Frame)の圧縮には、イントラフレーム圧縮が使用されます。動きが激しい映像はフレーム間の相関が弱くなり、破綻が目立つようになります。HDVやAVCHDはこちらに該当します。

一般的にイントラフレーム圧縮よりもロングGOP圧縮の方が圧縮効率が良く、同じ程度の画質を得るために必要なビットレートはロングGOP圧縮の方が少なくて済みます。そのため、インターネットの動画共有サイトやデジタルテレビ放送をはじめ、市販のパッケージメディア、コンシューマー向けビデオカメラなどはロングGOP圧縮が用いられます。反面、1枚のフレームを圧縮・伸張する際に複数のフレームを参照する必要があり、処理は重くなる傾向があります。

ノンリニア編集機の性能があまり高くなかった頃は、ロングGOP圧縮の素材をリアルタイム再生できないこともありました。現在でも性能が高くないノンリニア編集機で20Mbps程度のAVCHD(H.264)素材を編集する場合、画質をほぼ維持できる100Mbps程度のフレーム内圧縮コーデックに変換した方が快適に編集できます。しかしコンピューターの性能は日進月歩であり、処理を軽くするためにイントラフレーム圧縮に変換をする必要性は失われつつあります。

"百聞は一見に如かず" ですが……

画質の善し悪しは動画を見なければ判断できません。とはいえ、高圧縮率で再エンコードされる動画共有サイトで公開しても判断できるわけがありません。また、検証に使用した100GB以上の動画素材をサーバに置くのも非現実的です。今回は雰囲気だけでも伝わるよう、動画から切り出した静止画にコメントをつけて掲載します。

圧縮コーデックの評価をする際、非圧縮映像との差分をとってコントラストを上げる方法があり、普通に映像を見ても視認しにくい僅かな劣化もはっきり分かるようになります。今回は実用上気になるレベルの劣化を確認するのが目的ですので、差分の画像は掲載しておりません。

素材の準備

圧縮コーデックの画質を比較するためには、圧縮されていない映像を用意する必要があります。以前はこの点がネックだったのですが、今はBlackmagic DesignのBlackmagic Pocket Cinema Cameraが手元にありますので、このカメラで収録したRAWデータ(1080p23.98)を使うことにしました。

素材はすべて、近場の河川敷周辺で撮影しました。RAWデータをDaVinci Resolve Lite 11に読み込み、X-Rite社のカラーチャートを接写した映像を基準として現像・色補正を行い、10bit非圧縮4:2:2コーデックで書き出しました。その素材をAdobe Premiere Pro CC 2014で編集し、後述するグラフィックを挿入後10bit非圧縮4:2:2コーデックで書き出しました。これを、コーデック比較に使用する非圧縮のマスター素材としました。

この映像は、YouTubeにて公開しております。

動画1-1 検証に使用した映像(YouTube)

使用したコーデック

今回の実験では、HDCAM(HDW-1800)、Apple ProRes(各種)、Avid DNxHD(各種)、XDCAM HD(各種)、AVC Intra(各種)、DVCPRO HD、H.264(Blu-ray向け設定)、MPEG2(Blu-ray向け設定)など、様々なコーデックを使用しました。

HDCAMは、非圧縮の元データをHD-SDI経由でテープに録画(1080psf23.98)し、再生信号をHD-SDIから10bit非圧縮4:2:2でキャプチャーしています。それ以外のコーデックはすべて、Adobe Media Encoder(AME) CC 2014でエンコードしました。AVC IntraやDVCPRO HD、XDCAMは、それぞれPanasonic、SONYのレコーダーで録画・再生して検証するべきですが、残念ながら機材を用意できませんでした。

すべての結果を掲載すると煩雑になりますので、比較的使用頻度の高いものから、HDCAM、Apple ProRes(3種類)、XDCAM HD 422、XDCAM EX 35Mの計6種類の結果を抜粋して掲載します。

本ページで使用している静止画は、Premiere Pro CC 2014のタイムラインから書き出しました。掲載のためのトリミング・リサイズなどは、Photoshop CC 2014を使用してます。圧縮による劣化を見やすくするために200%に拡大している画像は、一番単純な補完方法である「ニアレストネイバー法」を使用しています。また、画質比較に使用する画像は、可逆圧縮のPNGフォーマットを使用しています。

グラフィック部分について

この検証では、同一コーデックで映像の複雑さが異なる場合の劣化の違いも比較したいと考えました。しかし、自然画の動画から1フレームを切り出してトリミングした静止画では、映像の内容が異なるので圧縮に伴う劣化が比較しにくくなります。そこで、劣化具合を比較しやすいように映像の全編に画像1-1のようなグラフィックを挿入しました。

アンチエイリアスを使用していない文字と、縦横3ピクセル、6ピクセルの格子模様などの要素で構成されています。

画像1-1 映像に挿入したグラフィック部分(200%拡大)

RGBとYUVについて

今回使用する非圧縮のマスターは、前述のようにYUV4:2:2です。RGB4:4:4と比較すると、輝度信号はそのまま、2つの色差信号は1/2に間引かれており、トータルでは2/3に圧縮されているとも言えます。そのため、非圧縮ではありますが、画像1-2のように色のにじみが発生しています。

画像1-2 RGB4:4:4とYUV4:2:2の比較

圧縮に伴う劣化について

今回扱うコーデックは、すべてDCT(離散コサイン変換)によって空間領域を周波数領域に変換して圧縮処理を行っています。直流成分のビット数が不足すると「ブロック歪み(ぶろっくひずみ)」が発生し、高い周波数成分のビット数が不足すると「モスキートノイズ」(蚊の大群がまとわりついているように見える)が発生します。

画像1-3 JPEG圧縮におけるブロック歪みの例

画像1-4 JPEG圧縮におけるモスキートノイズの例

次のページ>>