2017年8月26日土曜日

x264 高速・高画質バランスセッティング

世の中がHEVCに移行しつつあるので時代の記録として俺メモを残しておく。
基本ffmpeg。

【目指すところ】
実時間以下でMPEG2ソースを半分程度のサイズに落とす

【例】
coder=1
subq=1
refs=1
8x8dct=1
partitions=+parti4x4+parti8x8
me_method=hex
psy=0
trellis=0
fast-pskip=0
bf=3
b-pyramid=2
b_strategy=1
direct-pred=1
weightp=2
weightb=1
g=150
keyint_min=1
sc_threshold=50
mbtree=0
qcomp=0.7
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%程度なんで限界目指さないなら入れてもいいっちゃいい。


・Pフレームへの動き情報埋め込みをスキップするか(どうかを高速判定する)
fast_pskip=0

Pフレームにも動き情報を入れたがるかどうかを決める。
0で動き情報を入れたがり、1で入れたがらなくなる。
動き情報はデータなので、これを含むとサイズは太る。
具体的には、1にするとキーフレームから引き継がれた
動き情報をより多くのPフレームが保持するようになる。

ビットレートが低い場合、この動き情報に容量が割かれ
トータルの画質が悪くなる場合があるので注意。
一方ビットレートがいくつになってもいいよという場合、
サイズ増加とひきかえに画質の向上がみられる。
ちなみに速度コストは割りと小さい。
1パス品質ベースエンコなら0推奨、ニコ動一般会員など
限られたケースでは1がいいはず。


・最大連続Bフレーム数(bframes)
bf=3 or 5

通常、ゆるい実写ソースでの連続フレーム数は3程度が最大。
30fpsの定点カメラなら5くらいまで伸びるが、手持ちになると
ヘタしたらほとんど使われないというケースもあったり。
アニメは長くても7くらいで頭打ち。

この値を5より大きくしても目立った速度低下も圧縮効果もない。
その一方で再生互換性が低下するらしいのから設定しない。

ちなみに3から2にすると、速度・画質・ファイルサイズすべて悪化する場合があった。
Bピラミッドの構成からすると、偶数は合わなさそうなイメージ。

あまり値を大きくしても却ってSSIM値が下がるので実写なら3、
アニメや60fpsの場合に5くらいを指定しておくといいはず。


・進化したBフレーム作成・参照方式
b_pyramid=2

低ビットレート状況下において、アニメ画でパンする画のとき、
Bフレームの情報が不正確なために画がぼやけてブラーがかったり、
ひっかかったり、チラチラしたような状態になることがある。
これを軽減できるかもしれないオプション。
基本的に速度コストはないので常に2でよい。
却って無効よりエンコード速度が出る場合さえある。

ちなみにこのオプション、有効にすると
・Bフレームを積極的に入れようとする
そのおかげで
・連続Bフレームが増える
・Pフレームが減る
・つまり容量が縮む
という二次効果も発生する。
また、このオプションにより後述の動き予測メソッドのうち
Spatialの割合が大幅上昇する。
実写ソースでは100%張り付きもよく見られる。


・連続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フレームの置き方(参照するフレーム)に
重み付けをおこなう。
たとえば一定の動きを描いた画でBフレームが3つ連続で並ぶのであれば

I B B B P・・・

という感じになる。
このとき最初のBはIフレームを重視、3番目のBは続くPフレームを比較的意識して
保持するデータを構築する。


・重み付け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くらい
qcomp=0.7(デフォルト値0.6)

ビットレート固定(CBR)、真に品質固定(qp)、人の目(を模したアルゴリズム)
から見た品質固定(crf)、のなかのひとつ。
qpよりもcrfのほうがロスがなくまず決め打ちでOKというフレコミ。
qpはQ値の変動を固定したものであるが、実際は多少振れる。
(それぞれ一定ながらI・P・BフレームでQ値が異なるため)
CRFはQ値変動をフレキシブルにしたもの。その変動幅はqcompで指定可能。

ビットレートに余裕があれば好きなだけCRF値を低く設定すればOK。
多くのソースで、28→24のようにに4段階あがると映像部の容量はおよそ
倍になり、それなりに画質もあがってゆく。
お察しの通り、2ノッチあげるとだいたいルート2倍。
が、以降は画質に比べてビットレートが角度の急な曲線を描いて食いまくるので
せいぜい上限は22~24くらいが無駄が少ない。

qcomp値を下げるとQ値の上下振れ幅は小さくなり、あげるとその幅は大きくなる。
0だとQPのような感じになるが、qpモードよりももう少し振れる。

高画質で常に動きの激しいソースではqcomp値をあげるほど容量は太り、
逆に動きが緩いソースではこの値をあげるほど容量は落ちる。
緩急のついたソースではその割合でどう動くかは変わり、
緩<急の場合上記前者のような動きに近くなる。
オールマイティにいくならデフォルトの0.6で決め打ちが無難。
容量に制限がないなら余裕もたせる意味で0.7くらいでいいかも。

なおCRF値24は手持ちのソースだと720pでSSIM0.98をだいたい達成。
より大きい解像度だと力不足になるのでたて1080では22かより低い値を
設定しておくといいかも。
あまり画質に拘らないので自分は23くらいで留めてる。


・MBTREE:時間軸の中でのビット再配分
mbtree=0(デフォルトで1)

これはCRF指定時に選択可能なオプション。qpでは自動で無効になる。
考え方的にはValuableなビット資源をより短いスパンで再配分する感じ。

有効にした際、低ビットレート条件下で裏目に出ると、CRFで適切な
最低限のリソースが割り振られたところに、mbtreeのおせっかいで
さらに削られることにより特にBフレームで割当ビット不足を引き起こし
パンがひっかかったりすることがある。

また、そもそもこの基本的な動作自体は時間軸の中でのリソース
再配分なのだが、ビット資源不足状態になると後述のAQにより
こまい部分をよりノッペラボーに端折られることになり悲惨。
首相会見のような、背景に緞帳(微妙なグラデーション・曖昧なエッジ)、
メインに人物というような画の場合、ざっくりと緞帳を端折ってしまい
暗部ノイズのように盛大にブロックノイズが出てしまう事態を
引き起こしてしまう。

このようにAQとの兼ね合いで悪い方向に突き抜ける場合があるので
取り扱いが意外と面倒くさい。

圧縮率優先でCRF値を高くしている場合にこのmbtreeを使いたい場合は、
上記現象を抑えるためにqcompを下げて、まずそのシーン自体のQ値を
落とし過ぎないようにする。
それにつれてこのオプションの効き目もマイルドになる。
まあ、僕は使わないんだけど。


・AQ:一枚画/シーンの中でのビット(厳密には違うけど)再配分
aq-mode=0
(強度設定は aq-strength 小数指定)
※デフォルトはモード1、強度1.0(範囲は0~3)

一枚画の中で目につく所に注力するメソッドと度合いを設定する。
modeは0(無効)、1(有効:通常)、2(有効:よりラジカルに)、
3(有効:もうちょっとお利口)の4種類。

ざっくり言えば目につかなさそうな部分を潰しにかかるものなので、
計算量が増える以上mode0はわずかに変換が遅くかつサイズもけっこう
太ってしまうようになる。(ソースにもよるが)
一般的にはお利口そうなmode3が無難であるが裏目に出ると気になる。

こちらさまで公開されている噴水
http://footage3.openspc2.org/HDTV/footage/HD/30f/water/fountain/index.html

をエンコした際、キーフレーム前後で霧がかった水しぶき部分の
コントラストが異常に異なるようになり、結果霧部分が一コマで
大移動したように見えてしまう、コマ飛びでないのにあたかも
コマ飛びしたような画になってしまう。

Bフレーム→Iフレームならまあ、直前の画質が悪かったんだろうと
あきらめも付くが上記プリセットではqフレーム→Iフレームの
並びだったためはて何が原因だと調べた結果こいつが犯人だった。

で、refを増やしたりmixed-refsをかましたりme増やしたりしても
改善しなかったのでもうこれを切るしか無いという結論に至る。
ただしこれはレアなケースなのでいつもいつでも無効にするのが
おすすめというわけでもない。

ビットレートに制限がある中ではこれを活用するに越したことはないが、
余裕がある場合はこんなトリックはかまさずに映像のすみからすみまで
きれいにエンコしてやったほうがいい※ので、あまりこのオプションを
効かせる運用は個人的に好みでない。

かといって無効にすると容量に制限があるケースではムダも大きいので、
有効にしたい場合はモード3&そこそこ効かせる意味で0.4指定くらいが無難。
特段この数字に厳密な根拠があるわけではないが、SSIMが良い値を出すことが
多かったため。

※GS美神のコマ外にある椎名高志の手書きツッコミもきれいに残す感じ


~以下デフォルトまま/自動設定~

・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はお察しの通りいじれるとこは何もないのでプロファイル以外420p指定しか
パラメータいじってない。


■変換時間


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盛りゃいいと思うよ。


【ふろく】

■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

2017年8月25日金曜日

AHCIモードを有効にできないNEC Mateについて

AHCIモードを有効にできないNEC Mateについて

末尾アルファベットのモデル判別
C 2011年5月
D 2011年10月
E 2012年5月 ※このあたりからは対応っぽい
F 2012年10月
以下略

Sandy Bridgeより前のモデルは買わないので書かない。
ちなみに基本的にDVI-Dは備えてるくさい。


■できない機種

タイプMB
MB-C MB-D

タイプML(PCI-Express x16スロットなし)
ML-C ML-D


■できると思われる機種
(ドライバが存在する)

タイプMB
MB-E MB-F

タイプML(PCI-Express x16スロットなし)
ML-E ML-F ML-G

タイプME(メモリスロットが少ない。全面にオーディオ端子があって地味に便利)
ME-C ME-D ME-E ME-F

2017年8月10日木曜日

Win10でSandy BridgeのQSVが使えない時のTips

Sandy Bridge(Intel HD Graphics2000/3000)でQSVが使えない時のTips。

【できること】
HandbrakeなどでQSVを指定してエンコードする。

【できないこと】
ZeranoeビルドのFFmpegでQSVを指定してエンコードする。
これはビルド時の問題のよう。

ffmpeg 2.8のh264_qsvがSandy Bridgeで動作しない問題の回避策
https://peta.okechan.net/blog/archives/4212

【やりかた】

1.インテルからWindows7/8用のドライバをダウンロードする。

32ビット用:
https://downloadcenter.intel.com/ja/download/24970/Windows-7-8-8-1-32-HD-?product=52207

64ビット用:
https://downloadcenter.intel.com/ja/download/24971/Windows-7-HD-8-64-?product=52207
(↑8月現在最新。今後も更新ないだろう)

2.デバイスマネージャを開き、プロパティからドライバのアンインストールを実施する
※デバイスを削除するのではない。キャプチャは対応後のもの。



3.1のインストーラでドライバをインストールして再起動

4.HandbrakeでQSVが選択可能になっていることを確認する。



【ついでに画質比較】
対象は「この大空に、翼をひろげて」の273フレーム目
の右上部分切り出し

1.ソース


2.QSV 所要時間15sec q24 38.2MB(Handbrake balanced,profile Main)

キーフレームに指定されない割にきれいな画なのね。
ぼろぼろだけど。

3.FFmpeg(x264 自前プリセット) 所要時間21sec cfr24 34.3MB


QSV使わないかなー…。

(追記)
QSVはHighプロファイルだとけっこう改善する