x264 r1867 の crf

なんかcrfの基準が変わったらしいよ…？
という話。

続きを読む

続きを閉じる

r1867の更新では
猫科研究所様の訳
表示時間を考慮した品質管理らしい。で、フレームレート25fpsが基準の中心。x264は25fpsが好きですな。keyintのデフォも25×10の250だし。ヨーロッパ(?)は25fpsなんだっけ。どうでもいいけど。

重要なのはcrfが同じでも、フレームレートによって画質が変わるということなのだが、「じゃあ実際どんくらいよ？」ってのが気になる。あと、そんなことより一番重要なのは、「r1834と同じにするにはどうすりゃいいのよ？」というあたり。この辺を実験してみた。

x264のr1834とr1867で比較。

動画は
800x600
6891frame
30fps

コマンドラインは
--preset medium --ipratio 1.5 --qcomp 0.7 --scenecut 60 --min-keyint 4 --keyint 300 --b-adapt 2 --me umh --no-fast-pskip --no-dct-decimate


これをavisynth + x264でエンコード。x264は例によってx264.nlのもの。

元の動画は30fpsなのだが、
avisynthでAssumeFPS()することで、フレームレート(だけ)をいじる。

・r1834
・r1867 30fps(29.97でもいいけど、今回大した差はないはず)
・r1867 25fps
・r1867 23.976fps
・r1867 15fps

で比較。
crfは0.5刻みで10～30の間をテスト。(この範囲外を使う人はいないっしょ？)

これまで(r1834)なら、フレームレートを変えても、出来上がる動画のサイズ(容量)は同じになる。逆に、r1867からはフレームレートを下げると高画質(低圧縮)になるはず。

で、結果。

これは全体図。
横軸がcrf値、縦軸は動画のサイズ(容量、KB単位)。

--crfは小さいほうが低圧縮(高画質)ですよ～という当たり前の図。
これだと線が重なってよくわからないので拡大。



r1834の線は、r1867 25fpsに隠れてしまっていて、ほぼ同じってことがわかる。
猫科様のところに
『目安として「これまでと同じCRF値で同じフレームあたりの品質が再現される」フレームレートが25fps』
とあるので、当然なのだが。

で、r1867 30fpsは、高圧縮(低画質)寄りになっている。同じcrfだと5%ぐらい縮んでる。むろん縮んだ分画質は悪くなってるはず。

グラフから、同じ圧縮率(画質)=同じ動画サイズにするには、30fpsならばr1834の設定よりもcrfを -0.3 ぐらいしなきゃいかんようだ。

まあ、個人的には「フレームレートによってcrf値と画質の関係が変わるってどうよ？」と思うのだが、どうせ29.97fpsでしかエンコードしない(というか自動フィールドシフト時は29.97fps指定)ので「いままでより-0.3」としておけば問題ない。うん。

もっと言えばcrfの0.3差なんていじる必要もない誤差でしかない。あんま気にしてもしょうがない。こんな実験するまでもなかった…と。

x264, x264gui, x264guiEx 32bit,64bit 速度比較

パイプ方式を作ってみた最大の理由は64bitx264を使ってエンコードを少しでも高速化しようってことなんで、その検証をしてみる。

比較するのは
・Avisynth 64bit + x264 64bit
・Avisynth 32bit + x264 32bit
・Avisynth 32bit + avs2yuv 32bit + パイプ + x264 64bit
・Aviutl + x264guiEx + x264r1804 64bit
・Aviutl + x264guiEx + x264r1804 32bit
・Aviutl + 改造版x264gui r1804+350
もちろん、AvisynthもAviutlもフィルタはなし。

続きを読む

続きを閉じる

予想としては、64bitなら速くなるかなと。

入力データ
解像度 : 1280x720p
fps : 30.000fps
コーデック : UtVideo (ULY0) x86/x64ともにあり
フレーム数 : 3052 frame (約 1分42秒)
音声 : なし
その他 : アニメ絵

AvisynthではAVISourceを使い、pixel_typeにはYV12を指定した。

x264.exe は http://x264.nl/のバイナリを使用
x264のオプション(適当)
--crf 21 --preset slow --qcomp 0.75 -i 4 -I 300 --aq-strength 0 -t 2 --no-fast-pskip --no-dct-decimate

共通
Aviutl0.99i8

今回はいろんな環境で試して、その違いも見てみようかと。

環境1
OS : Win7 64bit
CPU : Xeon W3680 (6C/12T, L3=12MB) @ 4070MHz (Core i系)
RAM : 12GB

環境2
OS : Win7 64bit
CPU : Core2Duo P8600 (2C/2T, L2=3MB) @ 2400MHz
RAM : 4GB

環境3 (64bit系のテストはできない)
OS : WinXP 32bit
CPU : Core2Quad Q6600 (4C/4T, L2=4MB×2) @ 2400MHz
RAM : 2GB

速度比較にはログに最後に表示されるfpsを使う。




これだとよくわからんので、Avisynth32bit + x264 32bit を基準にそろえると、



どこでそろえるかで印象が変わるので、今度はx264guiにそろえたもの。



というか、環境2と3ではAviutlの処理がやけに遅い気がする。逆に環境1はAviutlのほうが速い(ぇ
ちょっと変なぐらい。

このことに注意しながら見ると、

・64bitで高速化。ただし、環境2よりも環境1のほうが64bit化による高速化の割合が高い。Avisynthにそろえたグラフでみるとよくわかり、環境1では約15%、環境2では～10%ぐらい。Core2よりもCoreiのほうが64bit最適化が進んでいるといわれているので、そのせいかもしれない。

・パイプ使用による速度低下はあまり見られない。

・改造版x264guiのバイナリはたぶん遅い…orz(x264guiExでパイプした32bitx264のほうが速いし…だけどたぶんそんなはずはないということはバイナリのせい)

あとは実験環境ではメモリがかなり余ってる状態だけど、パイプ処理はメモリの空きがじり貧だと遅くなりそう。バッファ的に。

まあ64bitで速くなることがわかれば十分。

ただ10～15％高速化ってのは結構大きいものの、体感できるかどうかは微妙かな。

それにこれは全くフィルタをかけてないからいいけど、フィルタのほうで詰まってしまって律速になって、x264の速度はあんまり関係なかったりすることもある。もちろん、その場合でも2つ同時にエンコードする場合とかには高速化も意味があるだろうけど。

x264 エンコード実験 --weightp 2

r1788でx264はchroma-weightpに対応…ということで、実際どんくらい効果あんの？ ということで実験してみた。重み付け予測ということはとりあえず、フェードとかに強くなるらしいよ？

続きを読む

続きを閉じる

まず、フェードとか多そうな動画を探してみた。


なんとなく…
sample1 リトバスEx demo の 最初から6400frame 800x600
sample2 はるかぜどりに、とまりぎを2 demo の 最初から 2403frame 800x600
sample3 FORTUNE ARTERIAL 赤い約束 ED 1280x720

どうしてこうなった…ってかんじのチョイスだが気にしない。
アニメ絵ばっか。実写…? 知らん。(おい

3つともフェードが多い動画。ただ、色差成分のみのフェードかどのくらいあるかはよくわからない。

sample1とか2は公式サイトとか、ミラーサイトとかからダウンロードできるやつ。

sample1とsample2は、avs+x264.exeで、sample3はAviutl+改造版x264gui.auoで実験。


比較するのは…
・r1790のweightp0 (weightp off)
・r1772のweightp2 (輝度のみ)
・r1790のweightp2 (輝度+色差)


その他のオプションは…
--preset slow --crf 23 --ipratio 1.5 --qcomp 0.7 --scenecut 60 --min-keyint 4 --keyint 300 --qpstep 12 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0 -t 2 --psnr --ssim


結果


weightp Y, UV … x264の出すログで出てきた値。どのくらいweightpを使ったかじゃないかな？普通、10%を超えることはほとんどない。たいてい1～5%ぐらいなので、選んだ動画がいかにフェードが多いかわかる。

fps … エンコード速度。やはりweightp 0 が速い(当然)。だがweightp 2による速度低下もわずか。

容量 … r1772weightp2のときのビットレートを100%としたときの増減。マイナスなら圧縮率向上。

SSIM, PSNR … 機械的な画質。(あくまで機械的なもので、見た目とは異なることもある。)値が大きいほどきれい。値を見ると、ほとんど変わっていないことがわかる。PSNRのY,U,Vの各値も似たような傾向だった。実際に見てみてもよくわからない。

weightpのオンにすることで、わずかにエンコード速度が落ちるかわりに、少し圧縮率が向上することがわかる。weightpなし->輝度weightpと比べるとそうでもないものの、輝度+色差weightpもそこそこ力を発揮している。そもそもYV12では色差は輝度と比べるともともと情報量が少ないし、フェードは輝度に依るものが多いだろうことを考えると結構すごいのかもしれない。

小さな圧縮率向上だが、細かい圧縮率向上も積み重ねれば大きなものになる。今後もx264に期待！


そういやTMPEGEncにx264が入るらしい。
まあ、今のTMPEGEncのH.264はちょっと残念だから…

x264の更新とかどうするんだろ?
アップデートするのか、放置するのか…

x264afs

x264afs.exeの要望があった気がしたので、ちょっと作ってみた。
まあ、私はavisynthをあまり使わない人間なので、Avisynth wikiを見ながら、afsをavisynthで使う方法を調べるところから始まった。なにが言いたいかというと…検証が不十分かもしれないってこと。…そこそこ検証はしたし、seraphy氏のものから大きく変えてはいないので大丈夫だとは思う。

1pass専用。SSE必須。

1pass専用なのはいかんともしがたい。gui.auo改造版のほうは自動2passはなんとかごまかしてるけど…ちょっとafs.exeは厳しい。

ダウンロード>>

需要そんなにないかもだし、私も使わないと思うんで、たぶんあんま更新とかしませんが。

x264 エンコード実験 dct-decimate fast-pskip

x264 r1724 で 1280x720p 3501frameエンコード実験
r1732がでているが、これまでのことも考えてr1724で実験。
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0 --bframes 3 --subme 5 --ref 5

今回は、--no-dct-decimate --fast-pskipについて。

続きを読む

続きを閉じる

--no-fast-pskip は、まるも氏の解説(->http://www.marumo.ne.jp/db2007_6.htm#21)をまとめれば、ようは飛ばしてもいいかもしれない動き検索を一応きちんとやっておくことで、画質の向上を図るもの。
--no-dct-decimateは、同じくまるも氏の解説(->http://www.marumo.ne.jp/db2007_6.htm#26)をまたざっくりまとめると、量子化の際に小さくなったdct係数を間引くのをやめましょう、というもの。

左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)


クリックして拡大

--no-fast-pskipも--no-dct-decimateも、画質が向上する一方、わずかに圧縮率が低下していることがわかる。エンコード速度の低下は大したことないので、まあ両方ともつけてエンコードしたほうがよいだろう。あまりつけない理由が見当たらない。

x264r1724 エンコード実験 --merange編

x264 r1724 で 1280x720p 3501frameエンコード実験
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

今度は、--bframes 3 --subme 5 の時、--ref 5 にしておいて、--merange を変化させるとどうなるか。

続きを読む

続きを閉じる

--merange は動き検索範囲。値が大きいほど、広い範囲で動きを検索する…らしい。
まあ、なんとなく、値を大きくしたほうがよさそう…だが、はたして。

左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)


クリックで拡大

まあ、結果としては、値を大きくすると、
・圧縮率向上
・画質向上(ほんのわずか)
・ぐんぐん遅くなる

とはいえ、圧縮率は --merange 48 以上ではたいして変わってないし、画質が向上しているといっても、ほんのわずか。やはり16以上32以下ぐらいが妥当?

あとは、この結果は1280x720pのエンコードなので、たとえば1920x1080pとか、大きい解像だとより高いmerangeが威力を発揮する…かもしれない。

面白いのはCPU使用率で24-32あたりをピークにして下がっていること。なにゆえ?

x264r1724 エンコード実験 --ref編

x264 r1724 で 1280x720p 3501frameエンコード実験
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

今度は、--bframes 3 --subme 5 の時、--ref を変化させるとどうなるか。

続きを読む

続きを閉じる

--ref の設定は、拡張x264出力でいうと「参照距離」で、あるフレームが前後何フレームまで参照して画像を構成できるかというもの。より多くのフレームを検索・参照すれば、よりよい参照ができることが期待できる。その結果、画質向上・圧縮率向上するはず。
だが、検索するフレームが増えればエンコード時間はかかりそう。

左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)



クリックで拡大

--ref の値を上げるとともに
・圧縮率が向上
・画質が向上
する。ただし、refをどんどん大きくしてもだんだんあまり変わらなくなる。ただし、それでも少しづつ良くはなっている。

あと、
・どんどん遅くなる。CPU使用率は上昇するので、refにかかわる計算のマルチスレッド効率はよさそう。

--ref 3 ぐらいまでは、けっこう効果があるので --ref 3 ぐらいにはしたいところかな。
あとは、どれだけ時間をかけられるか。

あと、refの設定はH.264のLevelにかかわる。
たとえば、1280x720pでのH.264 Level 4.0/4.1 の最大refは9。1920x1080pだと、Level4.0/4.1は最大で4。
これ以上にすると、DXVA(GPUによる動画再生支援)が働かなかったり、あるいは画像が破たんしたりする(ことがある)。

x264 エンコード実験 --bframes編

x264 r1724 で 1280x720p 3501frameエンコード実験
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

今回はとりあえず、--ref 5 --subme 5 の時、--bframes を変化させるとどうなるか。

続きを読む

続きを閉じる

--bframesは、最大連続Bフレームの設定で、
最大何枚の連続Bフレームを使えるかというもの。

今回の実験では、b-adapt は基本 2。

bframes 0 の時は bframesに関するもろもろのオプション
(b-adapt, weightb, b-pyramid等)がoffになる。
bframes 1 の時は b-pyramid none となる。

まず、実際に使用されたI,P,Bフレームの数


--bframes 0 では当然Bフレームは 0。
--bframesを増やすとともに、Bフレームの枚数が増えていくが、だんだんあまり増えなくなっている。


次に、x264のログの consecutive B-frames からわかる、実際に使用された連続Bフレーム数は、


たとえば、--bframes 6 と設定したとき、実際のエンコードでは連続したBフレームのパターンは
・Bフレームを入れない
・1枚Bフレームを入れる
・2枚連続Bフレームを入れる
・3枚連続Bフレームを入れる
・4枚連続Bフレームを入れる
・5枚連続Bフレームを入れる
・6枚連続Bフレームを入れる

の7通りが考えられるが、
今回は 「6枚連続Bフレームを入れる」が選択されたのは 4.6% だったということ。

--bframesを増やしても、必ずその枚数連続するわけではないとわかる。
そして、6枚連続はなかなか採用されないようだ。
もちろん、これはエンコードする動画にも大きく左右されるだろう。(たとえば、エンコードするものによっては、--bframes 6 としても6連続はおろか5連続、4連続もほとんど採用されないということもあるだろう。)
それに、--b-adapt 2 の時で、--b-adapt 1 の時はまた違った様子になるだろう(たぶん)。


左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)


クリックで拡大

--bframesを上げるとともに、高圧縮になっていき、またそれに伴って画質も低下している。ただし、あまり--bframesをあげても、たいして圧縮率は上がらない。

また、--b-adapt 2 が登場したときに 「高い--bframesの設定と--b-adapt 2はマルチスレッド効率を下げる」とあったようなきがする(あんまよく覚えてないけど、たしかそんなこと書いてあった気がする)。その通り、--bframesを増やすとCPU使用率が大幅に低下し、そのためかエンコード速度も遅くなってしまっている。

実用的なのは、圧縮率がそれなりにあって、エンコード速度もあまり下がらない --bfrmaes 2,3 あたりだろうか? --bfrmaes 5とか6とかはただ遅くなるだけな気がする。
もちろんこれは--b-adapt 2 の時で、--b-adapt 1 の時はまた違うだろうけど(たぶん)。


--bfrmaes 0 よりも --bframes 1 のほうがエンコードが速いのがおもしろい。なぜかは知らんが。

x264 エンコード実験 --subme編

x264 r1724 で 1280x720p 3501frameエンコード実験
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

このオプションに加えて、--refを 1～9、--bframesを 0～6、--submeを 0～10 まで変化させてエンコードを行い(9*7*11=693回エンコードを行った)、ログを保存するプログラムを適当に作り、あとでエクセルの表にして分析した。

今回はとりあえず、--ref 5 --bframes 3 の時、--subme を変化させるとどうなるかをグラフと表にしてみる。

続きを読む

続きを閉じる

左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)

CPU使用率やfpsはその時のパソコンの状態による。たとえば、OSのバックグラウンドタスクとか。
また、CPU使用率の取得方法が割と適当なので…参考程度に。6コア/12スレッドはさすがになかなか使い切ってくれない。

あと、SSIMは画質をあらわすが、SSIMの値と人間から見た動画の見た目は必ずしも一致しない。
だが、画質を数値としてあらわすにはSSIM(やPSNR)しかないので、とりあえずSSIMを使う。


クリックで拡大

ただし、subme 0 の時は --direct auto が許されないので、自動的に --direct spatial に変更されている。

まあ、submeの値を上げるにしたがって、
・高画質化
・遅くなる
・subme 3 ぐらいまでは容量もちぢむ。

とりあえず subme 0,1あたりは使わないでしょ…
それにしても、subme 2 以降
CPU使用率は(ほぼ)上がり続けるのに、
速度は下がり続ける…

subme 9 と 10 がなにも変わらんのは--aq-strength を 0 にしたせいかな。
なんか subme 10 って AQ を使うらしいので。

CPUパワーと時間があれば subme はどんどんあげればいいかな。
だいたい順調に高画質化するので。
時間に対するパフォーマンスがいいのは subme 3-5 かな。

x264 エンコード実験

普段、アニメのエンコードをよくやるのだが、
エンコーダのx264にはオプションが大量にある。
そこで、ちょっと実験をしてみる。

まず、基本となる設定・環境を記録しておく。

続きを読む

続きを閉じる

基本的なオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

環境
OS : Win7 x64
CPU : Xeon W3680 (6C/12T, L3=12MB) @ 4014MHz
RAM : 12GB

x264 x86 core105 r1724
http://x264.nl/のバイナリ

入力
解像度 : 1280x720p
fps : 30.000fps
コーデック : UtVideo 8.2.0 YUV420 (ULY0) 「デコード速度優先」
読み込み : avisynth AVISource() pixel_type="YV12"
フレーム数 : 3051 frame (約 1分42秒)
その他 : アニメ絵
aviは RamDisk上に配置
(ディスク I/O によるボトルネックを避けるため)

出力
mp4ファイル
RamDisk