保存のためのコーデック: H.265 vs VP9 私見

先日、ふと「そういえばVP9てのもあったな」と思い出しました。
Googleが頑張ってるみたいで、H.265(HEVC)に迫る画質だそうな。
どんなもんかな、とYouTubeのVP9の4K映像サンプルを見に行ってみましたが、確かにきれいです。

そこで、現在利用しているエンコーダをVP9に単純に置き換えた場合どうなるのかを調べてみました。
端的に言えばタモリ倶楽部の飲み企画をエンコードしておいて酒のツマミにするために保存するためのエンコード形式への一管見です。

エンコーダのフロントエンドは今回はHandBrakeをgithubからクローン(63e20c1-master)してビルドしたものを使います。
ffmpegでもいいんですが、コマンドラインが煩瑣なのと(VP9でもH.265でも設定を追い込むならffmpegのほうがいいと思います)、最近Handbrake1.0.7で利用されているlibx265の2.1と最新の2.4の比較のためにビルドした環境があったHandbrakeを使用します。
CPUはIntel(R) Celeron(R) CPU G1820 @ 2.70GHzを使用します。
OSはCentOS7です。
libx264のﾊﾞｰｼﾞｮﾝ: 2.4
libvpxのﾊﾞｰｼﾞｮﾝ: 1.6.1

ソースファイルはMPEG2-TS(そらそうだ)30分の先週のタモリ倶楽部です。

ファイルサイズは3.06 GB (3,288,296,156 バイト)。

・・・で計測するつもりだったんですが、後述しますようにエンコード速度がぶっちぎりで遲いのがあった(VP9+Vorbis: MKV)ので900秒目からの30秒間のエンコードを行うことにしました。
(投球されたボールを追いかけるカメラワークもあって割と動きがあるあたりです)

その結果は以下となりました。

	H.265+AAC: MP4	VP9+Vorbis: MKV	VP9+AAC: MKV
オプション	--decomb=Default --crop 0:0:0:0 -e x265 --h265-profile main -q 28 --cfr --aencoder copy --format av_mp4 --start-at duration:900 --stop-at duration:30	--decomb=Default --crop 0:0:0:0 -e VP9 --modulus 2 -q 28 --cfr --aencoder vorbis --start-at duration:900 --stop-at duration:30	--decomb=Default --crop 0:0:0:0 -e VP9 --modulus 2 --vb 1691 --cfr --aencoder copy --start-at duration:900 --stop-at duration:30
エンコード後サイズ	6.75 MB (7,084,380 バイト)	187 MB (196,485,180 バイト)	6.81 MB (7,143,742 バイト)
ビットレート	1689.46 kbps	52195.44 kbps	1708.25 kbps
平均処理速度	4.947090 fps	1.433700 fps	4.908809 fps
Windows10での視聴
VLC media player	問題なし	問題なし	問題なし
Windows Media Player	問題なし	不良※1	不良※1a
映画&テレビ(ストア)	問題なし	不良※1	不良※1a
Android(5.1.1)での視聴
VLC media player	問題なし	不可※2	不可※2
MX Player	問題なし	不可※2	問題なし

※1: 音声が再生されない(これはcodecがないんだろうから入れればいいので問題ないとして)、16:9で再生されなければならないのにdisplay dimension(1920 x 1080)を無視して再生時アスペクト比が4:3となる(Windows Media Player側の実装の問題でしょうね。なぜなら、H.265の場合はちゃんと1440x1080を16:9に引き伸ばして再生できているのですし、VLC media playerでは両者ともに正しく4:3で格納されたデータを16:9で再生しているわけですので)。
※1a: 音声の再生はOKだが映像は※1と同じく4:3で描画されました

※2: アスペクト比は正しいものの、最初の1フレーム目しか表示されない(ビットレートが高すぎる、またはハードウェアによる再生支援機能がないので再生できないものと思われる)。音声の再生は行われる。

ご注意: VP9+Vorbis: MKVの場合ですが、ビットレートが異常に高いため、エンコード速度もファイルサイズも格段に悪くなっています。--qualityオプションではなく、H.265と同じようになるようにビットレートを直接指定したのがVP9+AAC: MKVの結果欄となります(HandBrakeのオプションを単純に置き換えたらどうなるかという趣旨でやったらビットレートが桁違いに高くなってしまったので仕切り直しました)。
また、折角仕切りなおすので、音声コーデックもOpusだとWMPではそもそも映像も含めて再生不可でしたのでAACをMPEG2-TSからコピーしてエンコードしました。

結論:

ビットレートがほぼ同じならサイズもエンコード速度もほぼ同じ。
まさしく互角です。音ズレもなく良好です。
ただし、ちょっとだけVP9のほうがビットレートが高いのですが、それでも動きのあるｼｰﾝではHEVCより少々粗さが目立ちます(大人の事情でお見せできませんので個人的官能評価です)。

HandBrakeを使ったから悪いのかも知れませんが、ffmpegもHandBrakeもライブラリはlibx265とlibvpxを使ってるわけで、ソースも全く同一なんだから大した違いはないだろうと勝手に決めてffmpegではテストしません。

なお、H.265でRF=28.0にしてあるのはテストのためではなく、私が普段のタモリ倶楽部のエンコード時に指定している値で、個人的に1920x1080での鑑賞に堪える数値と思っている点にご注意ください。
HandBrakeでVP9でエンコードする際のオプションで-q(--quality)を使うとビットレートが高くなりすぎてしまうのは前述のとおりです。

いやあ、噂には聞いてましたがH.264のパテント料を払いたくないってだけでここまでやるんだから、やっぱりgoogleスゲぇっす。

まあ、H.264では結局MPEG-LAと契約しなくちゃいけなくなったみたいですが、すごいことには変わりません。

H.264のみならず、打倒H.265を目指していたと聞いていましたが、なるほどと納得です。確かに互角、しかもパテントフリー。ｽﾊﾞﾗｼｲ。

ただ・・・些末な点で言えば、現時点では再生するアプリやハードウェアを選んでしまうのが瑕瑾でしょうか。
もっとも、映像配信事業者としてのYouTubeの存在感が薄まらない限り、近い将来には再生できない環境はないところまで普及するものと思われます。最新のCPU/GPU/SoCではVP9をサポートしているようで、HEVCのアドバンテージは薄れてきているのかもしれません。

むしろ、特許関係でがんじがらめなHEVCは不利かもしれませんねえ。
まあ、特許関係ではAppleはライセンスホルダなのですし、MicrosoftのWindows10は標準ｻﾎﾟｰﾄを謳っている上、最悪でもlibx265はGPLv2として公開・配布されてますので見られなくなることは考えられないし、方やライセンス的にフリーだといっても、現状だけ見るとVP9支援対応ハードウェアは最新のものに限られていたり、推進元がGoogleなのでAppleと反目しそうだし・・・と、事態は混沌を極めているようにも見えます。

だったら、同様なビットレートだとちょっとだけきれいに見えるH.265を使っとくか。という程度ですかねえ。

月並みな感想で終わって申し訳ございませんが、現時点では以上です。