x264プリセットの弄り方 ~ 重くするから軽くするまで その1
プリセットは選ぶだけでなく作り出せるもの、と、
自ら作ってみたいと興味を持たれた方がいるかもしれません。
なるほど、
私が作ったプリセットはあくまでも『私のPC』を前提としているので、
あなたのPCに合った物とは限りません。
性能が良過ぎてプリセットが温く感じる人もいれば、
性能が届かなくてプリセットがキツイと感じる人もいるでしょう。
よって今回お話しするのは、プリセット項目を弄る事についてです。
何、0から作る必要はありません。
誰かのプリセットを編集すれば、自ずとあなたの為のプリセットになるのですから。
変えられない事
受信ビットレート
ニコニコ生放送のサーバー側が受け入れてくれるビットレートは384kbpsです。つまり秒間48Kバイトです。
しかし、2:00 ~ 19:29の間に放送開始をすれば、受け入れビットレートは480kbpsまで広がります。秒間60Kバイトですね。
私がニコ生でNLEを使い続けているのには、ここに理由があります。
NLEには映像のビットレートを指定する項目がありません。
これはつまり、384ないし480kbpsから指定した音声ビットレート値を引いた値を、
自動的に映像ビットレート値として適用してくれる機能だと思っています。
(長らく、480kbpsタイムに放送していないので、間違っていたらごめんなさい)
少なくとも、放送中はNLE下部に『384/384kpbs 0dropped』などと表示があるので、
適切な範囲に自動で丸め込んでくれているのは確かです。
NLE以外を使われる場合、総ビットレートが384kbpsを超えないように気を付けましょう。
x264項目設定
プリセットとは
x264とは、H.264エンコードを行うためのプログラムです。
簡単に言うと『延々と動画を変換し続けるだけの物』です。
ただ『動画を変換し続ける』だけのプログラムなので、
マウスでクリックしたら何かが起こるなどといった小洒落たウィンドウ等はありません。
コンソールアプリケーションなので、本来CUI(コマンドプロンプトとかMS-DOSとか言われる)が表示されるのですが、
動作が単調なのでそれさえ非表示にされるほどです。
さて、x264は設定した数値通りに動画の変換を行います。
操作ウィンドウ等は無いので、人間がアプローチできるのはこの設定を弄る事だけです。
この設定の事をプリセットと言います。
pre(先に)set(設定)の名の通り
『前もって調整しておく』の意味になります。
設定項目が余りにも多いので、
今回は私が重視して弄っている項目についてだけ、軽く触れていきましょう。
最重要な設定項目
keyint – Iフレーム強制挿入間隔
画質の要である『Iフレーム』を強制挿入するフレーム間隔を指定します。
NLEでは『ex:keyint:数値』で指定します。
このフレームのデータ量は莫大であり、だからこそ美しい画質を提供する事が出来ます。
ビットレートの残量に大きく依存します。
- 通常フレームレート*10の数字が推奨されています
その時NLEの場合は『ex:keyint:%FPSx10』と、記述します - ビットレートが有り余っている場合、数字を小さくすればするほど画質が上がります。そしてビットレートは圧迫されます
- ビットレートがカツカツな場合、数字を大きくすれば凄まじく余裕が生まれます。ビットレートは余裕が生まれます
- 弊害として、keyintを指定した数字でしかシークバーを動かせなくなります
(60FPS配信して、keyintが60だったら、1秒(=60フレーム)ごとにしか早送り、巻き戻しが利かなくなる)
bframes – Bフレーム最大連続数
圧縮率とCPU負荷の要である『Bフレーム』を挿入する、最大連続数を指定します。
NLEでは『ex:bframes:数値』で指定します。
究極的に言えば、ほぼ全てBフレームだけで作成された動画の圧縮率と美しさは、現在最強であると言えるでしょう。
最も、そんな事はまずありえないのですが、それほどH.264エンコードの素晴らしい機能の1つです。
Bフレームが連続挿入される可能性について解説されたブログさんによると、3枚連続までが妥当であるとの事。
- デフォルト値は3です
- 仮に10を指定しても、常に10連続Bフレームが使用される訳ではありません。
ただし、CPU負荷は常に10フレームを対象に動き続けるので、相当燃費の悪い設定になります - FCなど、動きの間隔が酷く長いものは10フレーム程度あるとかなり効率的だと思っています
- 現代のHDゲーム等、動きの間隔が短いものは3フレームあれば十分でしょう
ref – フレーム参照距離
Bフレームの参照に使えるフレームの参照距離を指定します。
NLEでは『ex:ref:数値』で指定します。
参照距離が3だとBフレームが2枚しか挿せないけど、
参照距離が4だったらBフレームが3枚挿せたのに!
みたいな問題を解決するための設定です
CPU負荷・メモリ使用量に大きく影響し、エンコードだけでなくデコード(再生)負荷も跳ね上がります。
大きな数字を指定しすぎると、携帯端末やタブレット・ゲーム機などでは再生できなくなるでしょう。
- デフォルト値は3です。6くらいまでが無難とされています
- 数字は『bframes ≦ ref』の関係でなければなりません
- 迷ったらbframesもrefも3を指定しましょう
- 数字を大きくすればするほど、マシンのメモリを消費し、エンコード時間が増えます
よってコマ落ちの発生原因にもなります
me – 動き予測アルゴリズム
現在までのフレームから、先のフレームがどう変化するかを予想する機能です。
NLEでは『ex:me:アルゴリズム』で指定します。
CPUパワーに大きく依存し、エンコード時間が猛烈に増えます(コマ落ちの原因にもなる)
- dia(Diamond Search:高速)
- hex(Hexagonal Search:通常のデフォルト値)
- umh(Uneven Multi-Hexagon Search:中速高品質)
- esa(Exhaustive Search:低速高画質(らしいが気のせい程度))
- tesa(Hadamard Exhaustive Search:ビックリするほど低速高画質(らしいが分からない程度))
- 多くの場合『dia,hex,umh』の3択で問題が解決するでしょう。パワーが有り余っているならesa、tesaも視野に入るでしょう
- hexの画質で満足できないならumhにすると、画質が良くなりますがマシンパワーを大きく食います
- hexでも辛いならdiaにするとマシンパワー問題が大きく改善します
subme – サブピクセル精度
1ピクセルは『R(赤)・G(緑)・B(青)』の3つのサブピクセルが集まって構成されています。
submeはこのサブピクセルに対して動き予測を行う精度を設定します。
NLEでは『ex:subme:数字』で指定します。
- 0 ~ 10までの、全11段階があります
- 7と9を指定する場合、bframesは1以上でなければ機能しません
- 10を指定する場合、aq-modeが1か2、trellisは2でなければ機能しません
よって10を指定すると、他のオプションをオンにする条件が複雑に絡み合い
激烈に重い処理と化します - 数字が小さいほどCPU負荷が軽くなり、画質が悪くなります
- 数字が大きいほどCPU負荷が大きくなり、画質が良くなります
psy-rd – 心理視覚的レート歪最適化
人は動体視力より静体視力の方が良く、動く物を見る事に弱いです。
自動車免許を取る時などに聞いた事があるでしょうし、経験から実感できるでしょう。
よって、動きの激しい所ではビットレートを落として画質をわざと劣化させ、
動きの小さい所ではビットレートを上げてやり、全体の画質を上げる機能です。
subme6以上必須で機能します。
NLEでは『ex:psy-rd:数字:数字』で指定します。
- 1.0:0.0がデフォルトですが、画質と引き換えにビットレートを大きく消費します
- ビットレート的な観点から0.0:0.0が推奨されていますが、私はそう感じません。
1.0 ~ 0.0まで好きに弄くって、納得いく所でやめるべきだと思います - 一般的に0.0 ~ 0.5辺りが良い結果になるようです
- 左辺の数字が小さいほど、ビットレートとマシンパワーが軽くなり、画質は落ちます
- 左辺の数字が大きいほど、ビットレートとマシンパワーが重くなり、画質は上がります
ただし、上げすぎるとノイズを生み出します
trellis – 量子化誤差丸め制御
圧縮率と画質の向上を図るオプションです。
NLEでは『ex:trellis:数字』で指定します。
『10 / 3 * 3 = 10』が真であるのはご理解いただけると思います。
10のデータを送るのに3で割った数字を送って、受け取った先で3倍すれば10に戻る。
そうすればデータ量は3分の1で済むという技術です。
しかし問題は、10を3で割ると3.3333……になります。
受け取った先で3倍すると9.9999……になります。
パッと見ただの誤差に見えますが、
これでは10を直接送った方が桁数が少なく、効率が良くなってしまうので、
自ずと切捨てか切上げをする事になります。
もしも3.333……を切捨てすると、受け取った先は3 * 3 = 9になります。
また、もしも3.3333……を切り上げすると、受け取った先は4 * 3 = 12になります。
これでは完全に別物ですね。
これを限りなく10に近い結果にしつつ、かつデータ量を減らす仕組みがtrellisです。
この説明を聞いて分かる通り、CPUパワーを莫大に消費する、猛烈に重いオプションです。
ただし、その恩恵もまた莫大です。
- 0はこの機能を使用しません
- 1はこの機能をある程度使用します(中速)
- 2はこの機能をフルで使用します(超低速)
mbtree – レート制御
画質とビットレート改善の要の一角。
psy-rdとは逆に、動きが少なく平坦なシーンの品質を下げてビットレートを温存し、
動きがそれなりにあって重要なシーンの品質を上げるためにビットレートを消費する機能です。
軽い処理で強烈に働くのでオンにした方が良いでしょう。
NLEでは『ex:mbtree:0(OFF)か1(ON)』で指定します。
今回はここまででひと段落とします。
参考になりましたでしょうか?
あなたの配信がまた少し良くなる事を応援しています。
関連記事
-
-
スマートフォンからニコニコ生放送を始める方法(iPhone・Android)
iPhone5(iOS)とXperia Z3(AndroidOS)、そしてniconico公式アプリを使ってニコニコ生放送をするための手順のお話
-
-
NLEプリセット ~ BF3をベースにした高画質FPS用ヌルヌルプリセット
またまたNLEプリセットの公開記事です。 毎度おなじみの設定結果から、どうぞ。 PCゲ
-
-
【NLEプリセット導入方法】 ニコ生ビットレート内の限界まで画質を上げてみた
改稿版 まずは結果からどうぞ。 ※Vorcaloidが苦手な方はご遠慮ください。 <a
-
-
全公開 私の放送ツールの設定画面とその理由
2014年7月現在、私が使っている配信ツールの設定画面一覧です。 必要以上の事をしているかもしれませ
-
-
レトロゲー用 NLEプリセットで30FPS対応超画質を目指してみた
まずは相変わらず結果からどうぞ。 <a href=”http://w
-
-
生放送の質を上げる前に知っておきたい、いくつかの予備知識 ~ 画質編
誰でも出来る! 放送の質を必要十分なレベルにするために ~ 前編 雑談ならトークスキル、絵画なら描画
-
-
NLEプリセット ~ レースゲーム用高画質60fps配信プリセットを作ってみた
またも自己満足60コマ配信用のNLEプリセットです。 相変わらず導入後の画質確認動画からどうぞ。 &
-
-
生放送の質を上げる前に知っておきたい、いくつかの予備知識 ~ 音質編
誰でも出来る! 放送の質を必要十分なレベルにするために ~ 中編 お疲れ様です。長くなりますが前回の
-
-
サンプルレートとビット深度について ~ 音を刻む仕組み
音は細切れに刻まれる 何かを参考にしていながら配信の設定をしていると、 44100Hzや48000H
-
-
NLEプリセット ~ DQ6をベースにしたSFC後期・アクションゲーム・よく画面が動くもの用
画面超綺麗と言われたので、NLEプリセットの配布をします。コマ数/秒は30で作っています。 導入方法
Comment
以下の点が事実と異なります。
keyintでの制御対象はIフレームではなくIDRフレームです。Iフレーム挿入数の制御はscenecutが使用されます。なおシーク単位もIDRフレームです。
サブピクセルの意味が異なります。submeことサブピクセル動き予測とは動き予測に使う座標系がピクセル単位ではなくさらにそれを分割したもの(H.264の場合1/4)を用いているというだけです。この際RGBを分割することはありません。そもそも動画においてはサンプリングの手を抜きやすいYUVで扱われることのほうが多く色空間としてRGBを使用することはまれです。そもそもH.264のMainProfileやHighProfileでは扱えません。おそらく液晶でのアンチエイリアス処理でのものと勘違いされたのでしょう。
phy-rdとmbtreeの動作が異なります。
phy-rdでいう視覚心理的複雑性は動きでは判別されていません。そもそも対象はフィルムのグレインノイズなどの細部の複雑さが目立つ箇所です。
またmbtreeはMVの変化が大きなマクロブロック(動きの激しい部分)のQPを上げる(品質を下げる)ことで全体としてビットを節約するものです。
詳しいお話ありがとうございます。
私も独学で勉強していまして、こういう事を相談できる知人が居らず、
理解している方からの解説はとても助かります。
該当箇所をMASA.Hさんのお話を参考に勉強しなおして、
いずれ改稿します。
繰り返しになりますが、詳しいお話ありがとうございました。