これまで x264 で行ってきたエンコード作業を、
x265化すると予想以上に捗ったのでまとめました。
他記事で紹介しているように、
私は Mirakurun + Chinachu でテレビサーバーを運用していますが、
気に入った番組はピックアップして、エンコード・圧縮したものを保存しています。
これまでは x264 を利用していて、利用開始時はその圧縮率と綺麗さに驚きました。
設定もそれなりに追い込んでいたと自負していたのですが、
今回、今更ながら x265 と 10bit化 を真面目に試して驚愕したので記事にしようと思います。
Contents
背景
x265 自体は結構前から気にはなっていて、2015年の時点で試した記録がありました。
しかし２つの要因によって、x265化は私の中でなかなか進みませんでした。
- x265 の処理速度
- mencoder から直接 x265化できない
x265 の処理速度
2015年に試した記録によると、
x264/x265 で同じ preset(medium) と crf を指定して計算負荷を調べていました。
（今思うと同じ crf値にどれくらいの意味があるのかという気もしますが）
当時のrev, 環境では x264 に対して
CPU負荷、実処理時間共に４倍以上掛かっていました。
当時、私はx264自体を medium より重い設定で使っていたので、
さらに４倍時間が掛かるというのはちょっと受け入れ難かったのです。
或いは設定のいくつかを緩めて x265化するという手も考えられますが、
それは結局画質を設定で追い込むか、x265で稼ぐかだけの違いで、
それなら現行のままでいいかなと当時は思ってしまいました。
mencoder から直接 x265化できない
これまで x264化は、mencoder から "-ovc x264 -x264encopts ..." で処理していました。
振り返ると、x264化自体は少なくとも 2005年頃には
Windows の VfW + AviUtil で行なってたようです（その前は WMV9...)。
2007年頃には macOS/Linux上 で mencoder を script 処理する、今の原型がありました。
この頃、"エンコード x264" とかでググると、ffmpeg と同じくらい、
或いはそれ以上に mencoder を使った方法が引っかかっていたのではないかと思います。
そして 2010年頃に ts録画ファイルの x264化が始まり、
既存の mencoder ベースの script を改変して処理するようにしました。
この時に、Linux における ts の処理において、
音ズレなど画質以外の点で、かなり苦労しました。
なので、この ts処理script をゼロから作り直す（含・mencoder以外をベースにする）のは、
なるべく避けたいと思っていました。
x265 を試した2015年当時、x265は当然次のスタンダードになると考えていたので、
その際はまだでも、すぐに mencoder に組み入れられると思っていました。
ところがいつまで経っても mencoder から -ovc x265 とできるようにはならず、
x265化は長く pending した状態になってしまいました。
途中、mpv や ffmpeg を用いて試してみたものの、
mencoder で煮詰めた video filter (-vf) の(一部?) がそのまま使えなかったこともあり、
何度か発起しては、やはり mencoder に x265が組み入れられるのを願う形になりました。
x265化への契機
x265化の主な契機は、PC環境の変化でした。
x264でも当然マルチスレッドで処理をしていて、
6C12T環境程度ではそれなりに資源を使いこなして処理できていました。
ところがこれが 10C20T とかそれ以上になってくると話が変わってきて、
mencoder+x264 では資源を使い切れず、CPUが遊ぶようになってきました。
そうなってくると、その遊んでいるCPUパワーを使って
画質を上げたり、圧縮率をあげたくなってきたりするものです。
あとは x265を含む H265/HEVC の動画が、
様々な環境でハードウェアデコードで気軽に見れるようになったというのも大きいです。
また、以前は録画して一度見てから選別して録画していたものが、
録画してはいるものの、見れずにそのままディスクを逼迫し始めて、
とりあえずエンコード・圧縮して小さくしたいという動機もあるかもしれません。
x265+10bit の衝撃
そんな環境の変化もあり、重い腰を上げて、
下処理 を ffmpeg, yuvmpeg4化してパイプで x265 へ渡すシーケンスを作り直しました。
さらには前から気になっていた 10bit化も試してみました。
画質とサイズ（ビットレート）
いきなり結果から行きましょう。
下のプロットはとある(実写系の)動画に対して x264/x265 を試した結果で、
横軸がサイズ [kB], 縦軸が SSIM値 [dB] です。
x265 は x264 と比べ、同画質でサイズは半分などとよく言われますが、
SSIM 17 あたりを見比べると、強ち大げさな表現ではないことがわかります。
もう１点特筆すべきは、10bit化の威力です。
私も以前は10bit化すると画質は上がるるかもしれないけど、
圧縮という観点では膨れてしまうのでは？と思っていました。
ところが、図中の x265 と x265+10bit を見比べると、
x265 のオプションを煮詰める云々よりも、圧倒的に 10bit化が、
画質/ビットレート 比を改善していることがわかりました。
次のプロットはアニメ系の比較的単調な動画に対しての結果です。
同様に横軸がサイズ [kB], 縦軸が SSIM値 [dB] です。
（サンプルが異なるので横軸のサイズは先ほどとは直接的に比べられません。）
こちらも傾向は同様で、x265化, 10bit化それぞれが、
対x264比で半分とまでは行かないまでも、
画質/ビットレート 比を大きく改善していることがわかります。
SSIM を画質として用いる点ですが、
例えば 次のプロットは SSIM と PSNR の相関で、
横軸が SSIM, 縦軸が PSNR です。
それぞれのセットアップについて、ほぼ同じ傾きの直線に乗っており、
また x265系 と x264系の線では、x265系の方が同じSSIMに対して
PSNR が大きい傾向（直線相関でPSNRが大きい方へ直接がシフトしている）なので、
SSIM で評価することは、x265には有利にはなっていないようです。
一方、x265 と x265+10bit の比較では、
10bit系 のラインの方が PSNR でやや下に来るので、
PSNRで評価すると、10bit化の改善量は少し控えめになるかもしれません。
処理時間は？
x264, x265 で同程度の画質（SSIM）の時に、
（CRF等で画質を上げると処理時間はやや伸びます）
CPU負荷で x265 が対x264比で x３倍程度、
実処理時間で x265 が対x264比で x1.5倍程度でした。
ここがどうやらポイントで、
多コア化が進むと コア数を増やした時の linearity がx265の方が良いのか、
CPU負荷は３倍あるにも関わらず、実処理時間は 1.5倍にしかなりません。
電気代やPCの寿命という問題はあるかもしれませんが、
ことエンコードという点だけに関していえば、
+50%の処理時間という比較的限定的なデメリットで、
サイズが半分程度, 或いはその分画質を上げることができるわけです。
これはなかなか実用的と言っても良いのではないでしょうか。
少なくとも私はこの結果をみて、x265 に乗り換えました。
現状、ts下処理, CMカット, video filter, 音声処理, 結合など全て含めて、
実写系は実録画時間と同じ〜２倍程度の時間、SSIM: 16~19、
アニメ系は実録画時間と同程度の時間、SSIM: 20~22dB 程度のファイルができています。
（実写系の方が処理時間、画質共に振れ幅が大きい印象）