世の中がHEVCに移行しつつあるので時代の記録として俺メモを残しておく。
基本ffmpeg。
【目指すところ】
・実時間以下でMPEG2ソースを半分程度のサイズに落とす（4Mbpsの場合→2Mbps）
・実写ソースでブルーレイ1枚に8時間収める（12Mbps）
上記ビットレートは下記設定値＆CRF20での目安。
圧縮率は二の次、むしろ画質向上を伴うデータ量増加はOKのスタンス。
【例】
coder=1
subq=1
refs=2
8x8dct=1
partitions=+parti4x4+parti8x8
me_method=hex
psy=0
trellis=0
fast-pskip=0
bf=5
b-pyramid=0
b_strategy=1
direct-pred=1
weightp=2
weightb=0
g=150
keyint_min=1
sc_threshold=50
mbtree=0
qcomp=0.8
qdiff=8
aq-mode=0
以下メモ
・Mainプロファイル(cabac)
coder=1
cabacをオフにするとBaselineとなるが、圧縮率や画質、汎用性を考えたら
BaselineのH.264なんかよりMPEG4(Xvidなど)をMP4コンテナに入れたほうが
ずっとよいのでこのオプションは必須。H.264規格の沽券にかかわる。
・動き予測方式(me)・探索範囲
me_method=hex
me_range=16
diaとほぼ同じ軽さ、かつumh並みの良好なパフォーマンスのhex。
ちなみに、me_rangeは8に下げても速度は変化ないのでいじらずデフォルトの16ままでよい。
hexではそれ以上の値に指定できない。
ちなみにumhにすると、me_range同値でも速度はそれだけで1割程度下がる。
画質は誤差の範囲内なのでumhにこだわる必要は無い。
・動き探索精度（subme）
subq=1(圧縮優先で3、ただしえらい遅い)
dpredオプションがautoでないと効果を発揮しないオプション。
subme0は問答無用で画質が悪いので非推奨。せめて1から。
で、これを1から2にすると1割程度時間がのびる一方
ファイルサイズも1割無いくらい縮む。
が、なぜかssimも下がる。これじゃ何の意味もない。
2から3にあげると変換速度はさらに1割ないくらい下がる。
ssimもそれなりにあがるが容量もやや太り、subq1と2の間くらいに落ち着く。
4以降は上昇幅は小さく、アニメ画ではほぼ完全に無駄。
バランス志向なら基本1でいいと思う。
2はあまり使いどころがないはず。
・参照フレーム数(ref)
refs=1(画質優先で2)
前後どの範囲のフレームを考慮に入れるかというオプション。
ソースにもよるがこれを1から2にするだけで1割程度速度低下し
1ピクセル程度の全体的な画面の横伸びが解消される。
また、全体的な画質も僅かに上がり、圧縮率も数％上がる。
ちなみに2以上に設定するとmixed-refsを有効化することができるが
mixed-refsは有効にしても速度コストも効果もほぼないので
あまりこだわらなくていい。
サイズにこだわらなければぶっちゃけビットレート盛れば画質は
上がるのでこの値を積極的にあげようという気持ちはない。
・Highプロファイル指定とマクロブロックオプション
partitions=+parti8x8+parti4x4
8x8dct=1
解像度が上がるにつれ、4x4は使用されなくなるとの記述をどっかで
見た気がするが案外そうでもないような。
ただ判定で大きくリソース食われないことからi4x4は画質向上も
速度コストもほぼないんで実際つけてもつけなくてもいいが、一応つけとく。
8x8に関してはi8x8ひとつあれば十分な画質。
p8x8・b8x8足してもSSIM値も圧縮率も大して上がらないが速度コストも
それぞれ5%程度なんで限界目指さないなら入れてもいいっちゃいい。
でも自分は入れない。
要はIフレームに比べて絶対的にデータ量が少ないPフレームやBフレームの
圧縮率を改善するための物なので、そもそも効果は薄い。
一昔前はモバイル向けにはMainプロファイルでエンコする方が安牌だったが
最近じゃ当たり前にフルHDなりそれ以上の解像度に対応しているので
Highプロファイルでも全然問題ない。
・Pフレームへの動き情報埋め込みをスキップするか（どうかを高速判定する）
fast_pskip=0
Pフレームにも動き情報を入れたがるかどうかを決める。
0で動き情報を入れたがり、1で入れたがらなくなる。
動き情報はデータなので、これを含むとサイズは太る。
ビットレートが低い場合、この動き情報に容量が割かれ
トータルの画質が悪くなる場合があるので注意。
一方ビットレートがいくつになってもいいよという場合、
サイズ増加とひきかえに画質の向上がみられる。
ちなみに速度コストは割りと小さい。
1パス品質ベースエンコなら0推奨、ニコ動一般会員など
限られたケースでは1がいいはず。
・最大連続Bフレーム数(bframes)
bf=5 or 7
通常、ゆるい実写ソースでの連続フレーム数は3程度が最大。
30fpsの定点カメラなら5くらいまで伸びるが、手持ちになると
ヘタしたらほとんど使われないというケースもあったり。
アニメは長くても7くらいで頭打ち。
この値を5より大きくしても目立った速度低下も圧縮効果もない。
その一方で再生互換性が低下するらしいのから設定しない。
ちなみに3から2にすると、速度・画質・ファイルサイズすべて悪化する場合があった。
Bピラミッドの構成からすると、偶数は合わなさそうなイメージ。
あまり値を大きくしても却ってSSIM値が下がるので実写なら5、
アニメや60fpsの場合に7くらいを指定しておくといいはず。
ちなみに連続Bフレーム数が稼ぎやすいアニメソースをbf10エンコした時の例。
consecutive B-frames: 10.4% 4.7% 4.1% 12.2% 10.2% 16.4% 6.5% 11.2% 7.7% 2.2% 14.3%
以上のように、3・5・7にヤマがある一方、9フレームは見向きもされない結果に。
またBF9の場合プレーヤーが起動せずハングることもあった。
なので奇数推奨＆最大7という一定の結論。
・進化したBフレーム作成・参照方式
b_pyramid=0(圧縮優先なら2)
低ビットレート状況下において、アニメ画でパンする画のとき、
Bフレームの情報が不正確なために画がぼやけてブラーがかったり、
ひっかかったり、チラチラしたような状態になることがある。
これを軽減できるかもしれないオプション。
0は無効、1は簡易、2はしっかり。速度コストはないので2でいい。
無効よりエンコード速度が出る場合さえある。
ほんのちょびっと2のほうがSSIM値・圧縮率ともに上。
ちなみにこのオプション、有効にすると
・Bフレームを積極的に入れようとする
そのおかげで
・連続Bフレームが増える
・Pフレームが減る
・つまり容量が縮む
という二次効果も発生する。
また、このオプションにより後述の動き予測メソッドのうち
Spatialの割合が大幅上昇する。
実写ソースでは100％張り付きもよく見られる。
Bフレームが増えることから、実写ソースでは「しずる感」が落ちる
傾向にあるので圧縮優先かひらたいアニメ画向きのオプション。
実写でもソースの画質がたいして良くない(DVD程度)のであれば有効でいい。
・連続Bフレーム挿入枚数判定方式(b_adapt)
b_strategy=1
0は無効(必ずbframes値ずつ入れる)、1が簡易、2が完全。
2(完全)はかなり重い。割に合ってない。
速度低下がわずかながら必要十分な効果を発揮するので簡易判定がおすすめ。
・動き予測メソッド
direct-pred=1（おこのみで3）
実際の選択肢は、1(方式1：Spatial)、2(方式2：Temporal)、
3（Auto：1と2を場面ごとに使い分け）の3つ。
理想はAuto。しかし上述よりSpatial固定でも問題ない。
別に「Temporalが適している」ところはSpatialで対処し切れない
ということはまったくなく、そこをあえてTemporalで処理すると
ほんの僅かにビットレートをケチれるよ、ってだけの違いしかない。
が、速度コストも大して大きくないので限界目指さないならautoでもいい。
あとどういうわけかautoにするとSSIM値が下がるケースもあったので
個人的にはSpatial一本で構わないと思ってる。
・重み付けBフレーム
weightb=1
PフレームないしIフレーム間のBフレームの置き方（参照するフレーム）に
重み付けをおこなう。1で有効、0で無効。
たとえば一定の動きを描いた画でBフレームが3つ連続で並ぶのであれば
I B B B P・・・
という感じになる。
このとき最初のBはIフレームを重視、3番目のBは続くPフレームを比較的意識して
保持するデータを構築する。
やっていることはb_pyramidに近いイメージ。
また、このオプションをいれるとさらにBフレームを入れたがるようになり、
総Bフレーム枚数ならびに連続Bフレーム枚数がアップする。
ただしその程度はソースにより異なりむしろ容量が増える場合もあるので
基本的に有効でいいと思う。
・重み付けPフレーム
weightp=2
重み付けBフレームと考え方は同じ。
0で無効、1で簡易判定、2で完全。
有効にすると大きな速度低下なしに1割はビットレートを下げられる。
モード1と2の間に速度差はほぼないので、2でよい。（ただし効果もほぼ差がない）
・キーフレーム(Iフレーム)間隔の最大・最小値
keyint=300（または240）
keyint_min=1
最大30fpsないし24fpsの10倍の値というのが定石。
また、シーンチェンジやよほど品質を必要とする場面では必ず
Iフレームを入れるのが理想なので、最小値は1がよい。
これをわざわざ1以外(特にfps値)に設定する意義がわからない。
シーク精度を高めるならkeyint値を上記の半分にするのもアリ。
その場合サイズ増加は大方の30fpsソースで大きくても3％程度内におさまる。
ただし60fpsの場合はもうちょっと大きくて1割ほど膨らむ。
そのかわり5％程度変換時間が短縮できた。
映画やミュージック・クリップなど、頭から最後まで見るのが前提で
シークなんかせんよという場合はなんぼ増やしても一向にかまわないが、
草サッカーなどの試合を撮影しあとで細かく分析したりする場合には
やはり短めがよい。
展開からして10秒は長いと思う。将棋なら別にいいけど。
keyintをfpsと同値にして1秒単位での頭出しを可能にしてもいいっちゃいいが
Potplayerなどのプレーヤー側がデフォルトで5秒間隔でのキーフレーム頭出しに
なっているので意味がなかったりする。
・シーンカット閾値
scenecut=50（sc_threshold）
※デフォルトは40
上げすぎたり下げすぎたりするとシーンチェンジで誤判定を起こす。
デフォルト値は少し心もとないのでちょい上げ。
60fps時は60くらいに上げたほうが吉。
・ビットレート配分の決定方法とその許容する振れ幅の大きさ
crf=24くらい（マスター品質でCRF20程度）
qcomp=0.8（余裕もってこのくらい、デフォルト値0.6）
ビットレート固定(CBR)、真に品質固定(qp)、人の目(を模したアルゴリズム)
から見た品質固定(crf)、のなかのひとつ。
qpよりもcrfのほうがロスがなくまず決め打ちでOKというフレコミ。
qpはQ値の変動を固定したものであるが、実際は多少振れる。
CRFはQ値変動をフレキシブルにしたもの。その変動幅はqcompで指定可能。
ビットレートに余裕があれば好きなだけCRF値を低く設定すればOK。
多くのソースで、28→24のようにに4段階あがると映像部の容量はおよそ
倍になり、それなりに画質もあがってゆく。
お察しの通り、2ノッチあげるとだいたいルート2倍。
が、以降は画質に比べてビットレートが角度の急な曲線を描いて食いまくるので
せいぜい上限は22～24くらいが無駄が少ない。
（2018Dec更新）
qcomp値を上げるとQ値の上下振れ幅は小さくなり、下げるとその幅は大きくなる。
基本となるのはPフレームの平均Q値で、qcomp=1に近づくほどこの値がCRF値に近づく。
逆にqcomp値を下げるほどBフレームのQ値を下げる＝画質と容量をダイエットする
挙動を見せる。
Bフレームの落ち込みを補うため、Iフレームの品質を多少上げるセッティングに
なっているようであるが、基本的にはBフレーム部分のダイエットが目的になる
(CRF本来の目的とする機能)ため、下げすぎるとバランスを失う。
ちなみにPフレームの値もつられて多少下がる。
要はQ値変動についてどれだけ圧力をかけて抑え込むか（compressするか）
という圧の大きさを指している。
言い換えると、この値の大きさはビットレート変動の大きさでもある。
よってVBR(qp)に近くなる・CBRに近くなるという文脈での説明も多い。
どっこい現実はVBRとかCBRとかいう話ではなく、CRFとの兼ね合いが問題なのである。
CRFは一定の画質以上を「必要ない」と判断するため、解像度が大きいほど
Q値を積極的に上げる(≒Bフレームの画質を落とす)傾向がある。
そのため、この値が小さいほどCRFの言いなりに従ってQ値をあげて
容量と画質を積極的に落としにかかるようになる。
同様に、高画質で常に動きの激しいソースでもまた、人間の目って
追いきれないでしょどうせということでQ値を上げる動きをする。
これを阻止するのがqcompによる圧力である。
そのためCRF値は低く設定しているのに現実には存外にqcomp値制限いっぱいの
高いQ値にしようとするx264をコントロールする方法として、解像度が
上がるにつれ低めのCRF値を設定していたが、問題はここにあるので
本質的な問題解決はこのqcomp値をコントロールすることによって
なされるべきと最近気づいた。
しかしこれを言い出すとそもそもCRFを使う意味がないということにもなるが
実質的なqpmaxのような制限をかける手段として使うイメージ。
くりかえしになるが、だったらもうCRFの勝手なふるまいってむしろ
邪魔じゃねという話になったりもするのでここらへん気にくわないならば
qpベースでいっちゃうのもテと思う。
このあたりはここにまとめた
x264 qcomp値について考える。
https://mu-san.blogspot.com/2019/01/x264-qcomp.html
・MBTREE：一枚絵の中でのビット再配分その1（動きを捨てる）
mbtree=0
これはCRF指定時に選択可能なオプション。qpでは自動で無効になる。
また、後述のip・iqレシオの値を無視しソースを見て判断する。
基本的には有効を推奨というフレコミ。
CRFは細かなシーンや動きのあるシーンについて、人の目で見て
気にならない程度に品質を下げる動きをする。
(先述のqcompが、どれだけ下げていいかのパラメータとなる)
これは極端な場合、シーンチェンジとともに突然、シーン全体の
画質が下がってしまう原因となる。（CBRあるある）
完全なqpの場合は理屈上そういうことは起きないが、CBR寄りの動きをする以上
CBRのような画質低下が引き起こされる可能性がある。
このビット資源がカツカツなシーン全体の中から、動きが速くて
目に追えない（だろう）部分を潰しにかかり、浮いた分を
のこりの動かない部分に振り分けて、全体的な画質の
向上を図る、バランサーの役目を果たすというわけ。
いろんなソースをエンコしてみたが、見た目大きく画質をロスする
こともない(が、効果も？な感じ)なのであってもなくてもいい。
具体的にはBフレームのQ値を本来のものから1ノッチ程度
積極的に上げ(品質を下げ)、浮いた分をI・Pフレームにまわすような
働きをする。
よって、Iフレーム・Pフレームの画質が上がることで動かない部分の
画質は当然それなりにあがる。
当然Bフレームの情報は削ぎ落とされているため、その分動きに弱くなる。
超ざっくりでそういう感じ。
基本的にビットレートが低いほうに最適化されたものに見受けられる
ため、余裕があるならあえてOFFにする戦略はアリと思う。
大差ないけど。
街歩き動画のような、背景＝主役、通行人＝モブであればいいが
MMDや（モーター）スポーツ、ベッドの上で激しく動く肌色のように、
動いているものこそが主役の場合はあえて切るのも手だと思う。
言い方を変えると、60fps動画のように圧倒的にBフレームが多い
イコール必然的にほとんどの時間をBフレームを眺めている場合は
やはりおすすめしにくい。
mbtreeを使う場合はb_pyramidやweightbは切るなど、Bフレームの
発生を抑え込むセッティングが別途必要に思われる。
・AQ：一枚絵の中でのビット再配分その2（細やかさを助ける）
aq-mode=0
（強度設定はaq-strength）
※デフォルトはモード1、強度1.0（範囲は0～3）
一枚画の中で目につく所に注力するメソッドと度合いを設定する。
modeは0(無効)、1(有効：通常)、2(有効：よりラジカルに)、
3(有効：もうちょっとお利口)の4種類。
要は一定以上のっぺりして目につかなさそうな部分を捨てにかかり、
逆に目につきそうな部分(のっぺりしてない、またはエンコでのっぺり
されそうだけどうまくやれば助かりそうな部分)のディテール向上に
まわすような働きをするオプション。
細かいところもそうでないところも一様に端折るのではなく、
その端折り具合を変えましょうというのがポイント。
一般的にはお利口そうなmode3が無難。
ざっくりいえばIフレームの効率を上げるもの。
上手く働けば総合的な(見た目の)画質・圧縮効率が上がり
端折られてのっぺりした部分の立体感が改善する場合がある。
が、逆に人肌がのっぺりされる感じがあるので個人的には
あまり好みでない。
建物の外壁など細かな凹凸のあるものに向いてる印象。
ひらたくいえば、毛糸のセーターを着た人が映っていたならば
顔の肌はのっぺりに、セーターはよりきちんとエンコされる。
うん、そこじゃない。
ちなみにBフレームの画質を削るという挙動はない様子。
mbtreeがBフレーム(≒動き)の画質下げ圧力＆Iフレーム画質上げ圧力
であるのに対しこれは後者のみ、動き品質のペナルティなしと
考えるとイメージしやすい。
有効にしたい場合はモード3＆そこそこ効かせる意味で0.4指定くらいが無難。
特段この数字に厳密な根拠があるわけではないが、SSIMが良い値を出すことが
多かったため。
デフォルトの1はちょいやりすぎに思う。
～以下デフォルトまま/自動設定～
・DCT係数の間引き
(decimate=1)
※FFmpegでは変更できない？
必要以上のデータや計算処理を間引いちゃいましょうというもの。
よほどでない限りOFFにしないほうがいいと開発者が言ってる以上、OFFにしない。
→decimation（デシメーション）
デシリットル、デシベルの「デシ」がついてることから、もとは
10に関連したことば。ローマ時代10人にひとりを死刑にしたことが由来。
転じて「間引く」くらいの意味となり、厳に1/10にするという意味合いはない。
・GOP区切り
open_gop=0
通常は0でよい。むしろほかにしない。
・超軽量ノイズリダクション
nr=0
hqdn3dに比べノイズ低減効果はないに等しい。
数値を上げると、その分順調にディテールをつぶした上で容量の圧縮が図れる。
が、nr=600程度までいくとcrfを1ノッチ下げるくらいのビットレート削減
となってしまう。
（多くのソースで、100あげるごとに約1％ずつ容量が減った）
たとえば手持ちのソースでは
容量 crf25 ≒ crf24 nr600
のとき、
画質 crf25 ＞ crf24 nr600
となってしまい、crf上げずに容量が削減できたね☆と思っていたら
画質が悪くなっただけでござるという結果になってしまう。
高周波成分の除去を目的にほんのりかける程度であれば50、
通常使用で100、強くても200程度がよいように見える。
この点で言えば、100-200のレンジを推奨している人に同じ。
要するに本来の目的であるノイズ低減にはあまり期待しないほうがいい。
基本的にまず使わないオプション。
・映像品質の最大・最小・一度に変動する最高値、
qpmin=0
qpmax=69
qpstep=4（お好みで8くらい）
通常、crf20台指定なら突き抜けてあがることも下がることもないので
そのままでいい。
qpstepは実際せいせい2～3程度しか動かないので、stepを4より大きくしなくては
ならないというほどでもない。
いじっても問題はないが、メリットもない。
・I、P、Bフレーム間の差
ip_ratio=1.40
pb_ratio=1.30
各フレーム間の品質差を決定する。
開発者が苦心の末デフォルトでこの値に設定しているので、このままがいい。
・デブロックフィルタ
deblock=1:0:0
左からオンオフ・効き目・こまやかさの判定しきい値
特に低ビットレート指定時、画質向上に大きく寄与する。
基本必須。ほっといても有効。なのでいじらなくてOK。
フィルタなので鮮明度を落とす効果があるが、試しに効き目を弱くしてみても
見た目・SSIM値もそう変化しなかった。
・Bフレーム入れたがり度
b-bias=0
この値を上げると通常Pフレームが妥当と判断されるところにも
Bフレームを入れたがるようになる。
Youtubeあたりは「画質二の次でとにかく速く」セッティングをしているのか
たぶんこの値を50程度にチューニングしていると見受けられる。
この値は意外と重要で、動画配信など必要最低限見られる画質でありつつ
容量を小さくしたい場合はいじるべきオプション。
通常はいじらない。
・画質の自動微調整
trellis=0
deadzone=21,11
trellisは画質の微調整を0(行わない)、1(簡易的に行う)、2(しっかりやる)
の3段階。
微調整をしっかりやることで画質が目に見えないだけ上がり、エンコード速度が
大幅に遅くなるという割りに合わないオプション。
同様に、その程度の効果なので簡易的に行ったところでたかが知れている。
が、簡易的にやってもかなり速度に影響するので0(無効)を推奨。
deadzoneは微調整しない際、かわりに機械的に計算するためのオプション。
通常いじる必要はない。
・その他
chroma_me=1
chroma_qp_offset=0
cqm=0（ffmpegでは設定不可？）
threads=0（コア数による）
lookahead_threads=1
sliced_threads=0
constrained_intra=0
intra_refresh=0
通常のデュアルコア環境では、パフォーマンスや画質に直結しない。
または、下手にいじるとめんどくさいことになる。
-----
QSV・NVENC(H264)との比較
テスト環境はメイン機とサブ機にわけて実施。CPUが微妙に異なるので注意。
・CPUエンコ/QSVエンコ
Core i5-2400、Zeranoeビルドの3.3.3(64bit)
QSVはHandbrake1.0.7を使用。
・NVENCエンコ
Core i5-2400S(GT710)、Zeranoeビルドの3.3.3(64bit)
変換時間の計測について、HandbrakeではElapsedTimeを見るしかないので秒単位。
コマンドでやれって話だけど面倒くさいのでパス。
変換ソースはrigayaさんとこといっしょ。
ちなみにここで計測した際のプロファイルは上記のもので、
この時とは異なる。
x264のmainプロファイルは上記8x8dctをオフにして計測。
QSVのオプションはmain/highともにbalanced、「tu=1:gop-pic-size=150:ref=16」を付加。
NVENCはお察しの通りいじれるとこは何もないのでプロファイル以外420ｐ指定しか
パラメータいじってない。
■変換時間
QSVが15秒、CPUエンコが17秒台とソフトウェアエンコにしては善戦。
Core2Duo時代には速えーと思っていたNVENCは却って4コアCPUより遅い結果に。
■ファイルサイズ比較
なるべくファイルサイズがあうようにしたかったが、QSVの微調整ができないので
ソフトウェアエンコのアドバンテージも加味してQSVを少し大きめになるほうに
振った結果、264側をCRF24、QSVをQ23指定にした。
また、同様の理由でNVENCも1ノッチ低く、26にqp値を指定した。
■画質比較
なぜかQSVは1コマ飛ぶため(後述)、画質比較はQSVで変換したファイルの1721コマ目、
ソースとffmepg変換後の1722コマ目をチョイス。
ソースとそれぞれ変換したものの左上部分を切り出し、
SR100x100で2倍に
リサイズしたものをJPEG形式で保存。
オリジナルに近いサイズのものがより高画質だろう多分というよくある比較方式。
実際の画像
※blogger側で再圧縮かかってるかもしれないので参考まで
注目点はほたる右側に描かれた尾翼内に「罫線がある感」があるかどうか。
オリジナル
NVENC qp26 mainプロファイル
NVENC qp26 highプロファイル
QSV Q23 mainプロファイル
QSV Q23 highプロファイル
FFmpeg(x264) mainプロファイル
FFmpeg(x264) highプロファイル
■ナマの値一覧
・MP4ファイルサイズ(MB)
nvenc_main 42.3
nvenc_high 40.7
qsv_main 40.1
qsv_high 40.7
x264_main 37.7
x264_high 37.5
・JPEGファイルサイズ(％) JPG(KB)
nvenc_main 92.31 228
nvenc_high 92.71 229
qsv_main 91.90 227
qsv_high 94.33 233
x264_main 93.12 230
x264_high 94.74 234
ORIGINAL 100.00 247
・変換時間(sec)
nvenc_main 18.15
nvenc_high 18.4
qsv_main 15
qsv_high 15
x264_main 17.33
x264_high 17.56
■所感
結論を言えば、JPEGファイルサイズにも出ているとおり、mainプロファイルが
あまりがんばれていない。
QSV・x264・nvencいずれもほたる右側の罫線がだいぶ潰れているのが大きい。
なので使うならHighプロファイル。
nvencは圧縮率・スピードともに完全に使いどころがない。
古いPCにGT710買い足してHWエンコしてみようかなと思ったのなら
潔く中古のi3かi5を買ってきたほうがずっとコスパがいい。
エンコだけならi3+QSVでいいっちゃいい。
nvencがグズグズの一方QSVがなかなかは言い過ぎもそこそこの画質。
ただ、バランス切り詰めたx264設定とQSVが容量差はあれど画質も速度も
ほぼ一緒ならじゃあどっち使えばいいんだみたいな気はしないでもない。
あと、インタレ保持が使えるのもnvencに対してQSVはアドバンテージ。
画質には過度の期待はしないがMPEG2ソースなら「まあ見れる」くらいに落ち着く。
ともあれもうCore2マシンを一生懸命なだめすかしてプリセットいじるくらいなら
もうとっとと買い替えちゃいなって感じである。
欲を言えばもう少しオプションが使えるHaswell使ってみたいがまだ高いので
オカネに余裕があるならいっそ自分で組んだほうがいいっちゃいいかも。
僕は安くなるまでSandyで引っ張るけど。
nvidiaがローエンドでもHEVC解禁してくれりゃそれでいい話なんだけど。
ただまあ、週末特価CD-R10枚1030円(税込)の時代と違ってHDDもBDメディアも
ごっつ安いご時世、エンコとかもう要らないよなという気はしないでもない。
Indeoとかさ、MPG2AVIとかさ、もーなにそれって話ですよ。
消える魔球のプリンコで泣きを見るとかいう時代じゃないわけですよ。
ていうか、時間と電気をかけて画質保ったまま限界まで圧縮なんて
エコじゃない。もうそんな時代じゃない。
必死こいて2Mbpsに落とし込むより素直に3M盛りゃいいと思うよ。
その点で言えばHEVCとかVP9、AV1といった圧縮率優先のコーデックなんか
こっちとしてはどーでもよくって、もっとバランス志向の設計に寄った
ものが出てきてほしいんだけど。
もっとも、もはや時代がCPUでなくNVENCやQSVのようなかたちで
サポートするようなものになっているんだろうな実際。
【ふろく】
■QSV使用時のフレーム喪失についてよくよく調べた
見た限りWMVファイル読み込み時にだけ起きる模様。
プリセットでBalanced（CLIで設定可能なQualityも）を選択した場合に発生する。
これはおそらくwmvを読み込んだ際実際はfps30であるのを何のおせっかいか
29.97と読み替えてエンコに臨むせいなんだと思う。
この判断をHandbrakeで行ってるとしたらQSVに限った話じゃない。
ログより
[16:25:37] scan: 10 previews, 1280x720, 29.970 fps, autocrop = 0/0/0/0, aspect 16:9, PAR 1:1
Speedプリセットではこのおせっかいで得た数値を無視してソースまま変換
することで結果ドロップが起きないのだろう。
なおこれは -r 30 オプションを付加することにより回避できた。
よってこれを回避する方法は
・とりあえずSpeedプリセット(デフォルト)しか使わない
・wmvファイルを変換する際はいちいち真空波動研かなにかで確認の上手動設定する
このふたつ。
■SBにおける最適なTU値は
TU1～TU7で計測。
するとどういうことか
TU1＝TU2
TU3＝TU4
TU5
TU7＝TU6
という結果になったので奇数値で比較。
ソースは上に同じ。
ただしここでは画面全体をJPEG化してファイルサイズ比較している。
（切り出すのが面倒だから）
また、後者のグラフは変換スピードは最も速いTU7を100％において比較し
ファイルサイズ同様75～100％のレンジに等しく比較できるようあわせた。
タイムアタックにあたってはCLIで実行し、
worktimeバッチで計測した。
グラフからはTU1～TU7で画質の差はほぼないといっていい。
一方変換速度と圧縮率がトレードオフの関係である（？）も、タイムの
落ち込みが小さくサイズ縮むTU5がバランスいいことがわかる。
TU1は特におすすめできない。
しかし拡大してみるとTU5とTU3の間にけっこうな違いがある。
TU3(241KB)
TU5(235KB)
TU3は全体的にディテールを残そうとしているが、そのせいで境界線
付近にうっすらモスキートノイズが出ている。
一方TU5は軽くAQかけたような仕上がりでバックがややソフトであるも
まあまあ安定感はある。
サイズを拡大して比較してやっとファイルサイズにして2％強の差が出る
程度なので普通はまあ、気にしなくていいんじゃないかなとも思う。
■この際連続Bframesも見に行く
※ここでは再生互換性を考慮してREF値を16から8に下げた
連続Bフレームが少なくなるに連れ順当に画質も上がる。
Bフレームなしはサイズも大きく、なぜか画質も低下。
BF3に比べBF1は5％程度のサイズ増におさまったがjpegファイルサイズは
2％増えている。
jpegサイズ比較はSSIMとは決定的に別物であるも、元画像に対する
同一性の尺度と見るなら考え方は近い。
SSIM2％の違いはけっこうなものであるので、ファイルサイズ5％増
というのはコストとして割がいいように思う。
あえてBF1(gop-ref-dist=2)はアリと思う。
60fpsソースならもうちょっと増やしてもいいかな。
余談を書くと、REF8とREF4でファイルサイズ・画質・変換速度に
ほぼ違いはなかったのでREF4決め打ちでいいと思う。
ちなみにこの解像度だと規格が以下のようになる。
REF16 レベル5
REF8 レベル4
REF4 レベル3
■というわけでSBにおける現時点での結論
このオプションでいく。
tu=5
gop-pic-size=150（もしくは300）
ref=4
gop-ref-dist=2
