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