序

本記事は分散しているビデオエンコーディング関連の記事のアップデートのためのものである。

本題

H.265 (libx265) vs VP9 (libvpx-vp9)

ビデオカメラで撮ったような動画の場合、高圧縮時(FHD 60FPS 3000-7000kbps程度)の品質は大きく引き離してlibx265が良い。

一方、アニメやゲームなど、色変化がはっきりしていて平坦な映像の場合、そもそもlibx265では高圧縮を狙いにくく、 また比較的高いビットレートでも文字などににじみが発生するため、libvpx-vp9のほうが良い。

処理速度的にはlibx265のほうが圧倒的に高速である。 libvpx-vp9も並列化することで高速化できるが、画面を分割してエンコーディングするため画質劣化がかなり大きい。 一方、libvpx-vp9はシングルスレッドで動作するものと割り切ってしまえば複数の動画の並列エンコーディングを行いやすいが、 Ryzen7 3700XでのトータルFPSは、私がよく行うゲーム動画(FHD)の変換でlibx265が80FPS程度に対し、libvpx-vp9は12FPS程度に留まる。

libx265に関しては完全ではないがかなりしっかりとマルチスレッド化されているため、複数動画の並列エンコーディングは効率にはほとんど貢献しない。

H.264 (libx264) vs H.265 (libx265)

おおよそ説明どおり、libx265のCRF27がlibx264のCRF23相当という感覚で間違いない。

libx265エンコーディングはそこそこ処理が重いため、リニア処理ではH.264が良い場合もあるだろう。 また、H.265のデコーディングもまた重いため、再生支援のない機器向けにH.264でという考えもある。

しかし、そうした処理上の都合が問題なければ、H.265で良いだろう。

VP8 (libvpx) vs VP9 (libvpx-vp9)

GoogleがWebMを打ち出したときはVP8を用いていたが、実のところVP8を使う動機というのはかなり弱い。

libvpxがlibvpx-vp9と比べて軽くない、というのもその大きな理由のひとつだ。 libx264とlibx265だとパフォーマンス上の理由でlibx264を選択する余地があるのだが、 libvpxはlibvpx-vp9より気休め程度の軽いだけであるため、パフォーマンス上の理由では選択しにくい。

また、libvpxの品質があまりよくなく、圧縮を強めるとかなり劣悪な品質になってしまう。

スクリーンキャストにおいて少しでも軽くするためにlibvpxを選択するのはあるかもしれないが、 それでもH.264で低圧縮にしたほうが良く、あまりにも動機に乏しい。

VP9 (libvpx-vp9) vs AV1 (libaom)

libvpx-vp9で2FPS程度出る環境でも、libaomで、「VP9に対するアドバンテージを感じないほど速さ優先」にして0.05FPS程度という遅さであり、この遅さからAV1はとても実用にならない。

CPUだけの問題であればクラウドサーバーなどでパワフルなCPUを使う方法もあるが、AV1はメモリも大量に使うためそれも難しい。

話はハードウェアエンコーディングができるようになってからだろうが、VP9のハードウェアエンコーディングの品質があまり高くないことを考えると、 AV1のハードウェアエンコーディングがVP9のソフトウェアエンコーディングよりも優れた選択肢になるのは難しそうだ。

libx265 vs NVENC HEVC

NVENCはテクスチャ潰れが激しく、高圧縮時は見れたものではない。

だが、NVENCは圧倒的な速さがあるため、リニアレコーディングや中間データなど、 「サイズは大きくてもいいから軽く、速く処理してほしい」という要求に適合する。

NVENC vs AMF (VCE)

品質面ではAMFが多少良い。また、NVENCはエンコーディング可能な条件がかなり縛られるため、柔軟性の点でもAMFが良い。

しかし、速度的には圧倒的にNVENCが速く、AMFに関しては高速なCPUを積んでいると「より高速」とは感じない場合すらある。 安定性の面でもNVENCのほうが圧倒的に安定しており、AMFは使いどころのなさを感じる。

NVENC vs QSV

両者は目的が大きく違う。

QSVは基本的に「CPUの負担を軽くする」ようなものであり、高速性にはあまり寄与しない。 現代のビデオ処理はCPUには重すぎるため、CPU屋であるIntelとしてはCPUの性能を活かすためにビデオ処理を部分的にでもオフロードしたい、という考えなのだろう。

QSVを使うことでCPUの利用率が下がり、その分のCPUを本来の処理に回すことができる。 ビデオ処理でCPUを使い切ってしまうと何もできないのでこれは正しい考え方だ。

NVENCはCPUではとてもできないような処理を行う機能として提供されており、高速性は重要なポイントである。 これはCUDAで動画処理ができることとも関わっているだろう。

NVDEC vs CUDA

CUDAにも動画処理機能があり、再生支援としてNVDECとCUDAが選択可能なため、悩んでしまう人もいるだろう。

これに対する簡単な答えは、NVDECがビデオ再生専用のチップを用いるのに対し、CUDAはグラフィック演算器を活用するものである、ということになるだろう。 適正という意味では、NVDECを使うべきである。

VDPAU vs VA-API

VDPAUはNvidia, デコード専用, フィルタ処理なし、VA-APIはIntel, デコード/エンコード/フィルタ。

NvidiaはVDPAUを事実上投げ捨てており、両方使えるAMDの場合、VA-APIのほうが良い結果を得られるだろう。 Nvidiaに関しては後述のようにNVDEC/NVENCを直接使うのが一般的だ。

VA-APIはフィルタ処理もオフロードできる関係で、使えるフィルタが限定されたりする。 mpvで--vo=vaapiは避けたほうが良いだろう。

また、ラッパーライブラリ(libva-vdpauやlibvdpau-va-gl)は、どうしても必要でなければ使わないほうが良い。

VDPAU vs NVDEC

NvidiaはVDPAUを作ったものの、メンテナンスに積極的でなく、機能が追加されておらず、コーデックサポートですら十分でない。

このため、NvidiaビデオカードにおいてはNVDECを使うほうが良い。