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 のほうがエンコードが速いのがおもしろい。なぜかは知らんが。