x264 初心者質問スレ part6

1 ：名無しさん＠編集中：2012/09/13(木) 18:10:23.11 ID:k71gBkNl.net

x264 初心者質問スレ part5

こちらはx264.exeを使い始めた初心者のためのスレです。
x264のコマンドライン（CUI）の質問はこちらでどうぞ。

[本家]
http://www.videolan.org/x264.html

[バイナリ]
http://doom10.org/index.php?topic=3.0
http://x264.nl/

[前スレ]
x264 初心者質問スレ part5
http://toro.2ch.net/test/read.cgi/avi/1314616372/

[本スレ]
x264 rev37
http://toro.2ch.net/test/read.cgi/avi/1338222831/

[関連スレ]
MeGUIスレッド
http://hibari.2ch.net/test/read.cgi/avi/1164533110/
x264vfw GUI専用スレ Part8
http://toro.2ch.net/test/read.cgi/avi/1318232220/

201 ：名無しさん＠編集中：2013/02/09(土) 08:33:14.29 ID:8Q7kuGqN.net

エンコードしてるときCPU使用率のメーターが100まで振り切れて
PCに負担かかってるみたいだがこれは仕方ないのかな。
軽減策とかありますか？

202 ：名無しさん＠編集中：2013/02/09(土) 09:01:41.45 ID:vr674lOy.net

使用率が100まで行かないことを普通は嫌がるんだが、何が不満なのだろうか…

使用率下げたいだけならスレッド数減らせば？

203 ：名無しさん＠編集中：2013/02/09(土) 11:03:21.46 ID:p67atsKA.net

ｗ

204 ：名無しさん＠編集中：2013/02/09(土) 11:10:52.72 ID:L4RKnjYv.net

CPU100%を人間の全力疾走とでも思ってるんじゃねぇか
定格100%なんてメーカーっていうマネージャーに指示(制限)されたランニング程度だろうな
OCしてるなら私設マネージャーによる素人のしごきだろうから過度な負担だろうけど

205 ：名無しさん＠編集中：2013/02/09(土) 11:53:44.52 ID:p67atsKA.net

心配ならCPUの温度が表示されるソフトを入れてみたら。
馬鹿みたいに熱くならなければ、問題ない。

個人的には70度超えると嫌かな。俺が今使っているCPUは
3770Kの電圧ちょっと下げで、100％状態で室温＋25度程度。

206 ：名無しさん＠編集中：2013/02/09(土) 19:56:18.96 ID:Ix3uaI09.net

夏場で家に居ない時に自動エンコするときなんかはちょっと考える

207 ：名無しさん＠編集中：2013/02/11(月) 04:24:55.76 ID:QNfUA5JT.net

mp4にass字幕を埋め込む方法って無い？
srtもassもただのテキストファイルなのにコンテナのmp4が選り好みするのは何故だ
拡張子をsrtにしてmp4box叩いてもエラー出しやがる

208 ：名無しさん＠編集中：2013/02/11(月) 04:27:57.46 ID:c5GjHfTL.net

>>207
MPEG-4 Timed Text以外の字幕を入れたいのなら、mkvに入れる。

209 ：名無しさん＠編集中：2013/02/11(月) 04:31:05.08 ID:QNfUA5JT.net

>>208
最低限assの、字幕の表示位置指定機能を使いたいんだけど対応してないじゃん
色太字打ち消し等デザインは基本機能ちゃんと揃ってるのに。

210 ：名無しさん＠編集中：2013/02/12(火) 12:11:16.97 ID:5PIrHRR4.net

プロファイル＞高画質　自動マルチパス　に設定
目標映像ピットレートの数値をどのくらいに設定していいのか
悩んでいます。数値大きくしすぎてエラーになったこともあるし、
高画質を望んでいるので低品質エンコもどうかと・・・
例えば、YouTubeサイズだとどの程度が最適ですか？
算出方法とかあるのでしょうか？ヘルプです。

211 ：名無しさん＠編集中：2013/02/12(火) 16:53:22.41 ID:zFQPnSOF.net

ビットレート計算機でも使いなさい

212 ：名無しさん＠編集中：2013/02/12(火) 18:06:36.99 ID:WnbOZWFK.net

YouTubeなんて2GBまで大丈夫なんだしよっぽど長時間じゃない限り適当にcrfでエンコすりゃいいだろ

213 ：名無しさん＠編集中：2013/02/12(火) 21:53:28.76 ID:5R/o0I6d.net

>>210
http://www.google.com/search?hl=ja&q=BPP+%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AC%E3%83%BC%E3%83%88

214 ：210：2013/02/13(水) 14:46:35.64 ID:TgmLhGan.net

>>213
参考になりました。有難うございます。

215 ：名無しさん＠編集中：2013/02/19(火) 21:39:33.07 ID:y0kEZcwn.net

40Mbps・FullHD・H.264ソースのアニメを10-bitエンコードをしたいと思っています

--preset slow --crf 18 --bframes 9 --b-adapt 2 --b-pyramid normal --qcomp 0.8 --qpstep 16 --subme 9 --aq-mode 1 --aq-strength 0.60 --psy-rd 1.0:0.0
--trellis 2 --deblock -1:-1 --merange 24 --ref 6 --mixed-refs --weightb --colormatrix bt709 --colorprim bt709 --transfer bt709 --bluray-compat --ssim --psnr

拡張 x264 出力（GUI）の設定項目とその機能について - ニコニコ動画まとめwiki

ttp://www.logsoku.com/r/avi/1277292200/#29

こちらを拝見して参考にしているのですが
ぐぐって過去ログを見ると0.5:00だと暗部が厳しいとのことで
psy-rdの値をどうしようか悩んでいます

どの程度の値が適正、というのは難しい質問だと思いますので
アニメではどの程度の値を使われることが多いでしょうか。ご指導お願いいたします

psy-rd 0.5:0.0
x264 [info]: SSIM Mean Y:0.9940935 (22.287db)
x264 [info]: PSNR Mean Y:48.988 U:50.791 V:50.189 Avg:49.333 Global:48.314 kb/s:2545.80

psy-rd 1.0:0.0
x264 [info]: SSIM Mean Y:0.9937291 (22.027db)
x264 [info]: PSNR Mean Y:48.853 U:50.746 V:50.146 Avg:49.221 Global:48.218 kb/s:2762.25

216 ：名無しさん＠編集中：2013/02/19(火) 21:48:15.35 ID:2XvqbDeU.net

>>215
そこのリンクにあるのは全部8bitの話で、10bitはまた違うから自分で色々試してみたらいい

217 ：名無しさん＠編集中：2013/02/20(水) 12:27:39.42 ID:NhKyk8zl.net

>>215
俺は--psy-rd 0.7:0.2にしてるけど
基本的にグレインを残すためのものだからアニメだったら0.5:0.0〜1.0:0.0あれば充分だと思うよ

高くするほどSSIMが下がるのは
ノイズを再現再圧縮する副作用で更にノイズが増えてしまうよりも
一面のっぺりの方が元画像に近い比較になるってだけ

□□□　　　 ○△□　
□■□　→　△■△
□□□　　　 □△○

　 ↓

□□□
□□□　　　　かなり極端な例だけどこんな感じ
□□□

暗部や星空でブロックノイズが出るかどうかを判断基準にするといいと思う
--crf 18 --qcomp 0.8 ならよっぽど複雑なシーンじゃない限りは大丈夫だろうけど

218 ：名無しさん＠編集中：2013/02/20(水) 22:34:02.71 ID:RD7AR+E+.net

とりあえず>>215をsubme11にした上で--psy-rd 0.5:0.0 と 1.0:0.0 で720pエンコしたものをキャプチャしてみた
ttp://www1.axfc.net/uploader/so/2801236

avspmodのffmpegsource2でデコードプレビューしてるからたぶん8bitYUVになってしまっていると思うけど
傾向はこんな感じのはず

個人的な価値観としてはほとんどのシーンで0.5の方が綺麗に（グレインのないのっぺりに）見えるけど
001098のロープ、001315のグラデーション、001470の鉄骨や使徒の胴体のギザギザ、
002081の髪の輪郭線なんかは1.0の方が潰れず綺麗に残ってると思う

219 ：218：2013/02/22(金) 14:34:16.01 ID:YsjT3/zV.net

追加
ttp://www1.axfc.net/uploader/so/2803008

--psy-rd 0.5:0.0
--psy-rd 0.5:0.0 --aqmode 2
--psy-rd 0.5:0.0 --crf 16
--psy-rd 1.0:0.0
ソースをSpline36Resizeで縮小しただけのもの

身も蓋もないけど --crf 16 がやっぱり一番綺麗。
特に1325のロゴ周りの線や1471の使徒の使徒の胴体のギザギザのあたり。

ただsubme11でも映像だけでサイズが20％強上がってるので
そこまでこだわるメリットがあるかどうかは人それぞれだと思う

220 ：名無しさん＠編集中：2013/02/22(金) 16:38:04.72 ID:UsCwEn4D.net

ビットレートを一定にしないと意味が無いと思うんだが。
crfを0.1単位で調整して容量を揃えて実験した真面目な人もいたが、
普通に2passで比べれば良い。 crf**で大体のビットレートを算出→それぞれの設定でビットレート指定2pass　という手順で。

221 ：名無しさん＠編集中：2013/02/22(金) 16:44:54.23 ID:UsCwEn4D.net

改行が読みづらくてすまん。

あと、使用した設定も書いておいてくれるとわかりやすい。
また、aq/psyは静止画ではなく動画で比較すべき、と
DarkShikari氏(x264のデベロッパーの一人)は言っている。
そう言う本人も、静止画の比較画像を何個かアップロードしてるから、気にしなくて良いのかもしれないが^^;

222 ：名無しさん＠編集中：2013/02/22(金) 21:16:47.06 ID:YsjT3/zV.net

追加
ttp://www1.axfc.net/uploader/so/2803672

--psy-rd 0.5:0.0 --no-mbtree
--psy-rd 0.5:0.0 --crf 17
--psy-rd 0.5:0.0 --crf 17 --no-mbtree

やっぱり暗部の再現は --no-mbtree が一番有効かな
1325のロゴ周りの線にそれほど大きな変化はないけど
1471の使徒の胴体のギザギザのあたりは線がハッキリ見えるようになってる（同じcrf18のpsy-rd1.0:0.0よりもハッキリしてる）

ただどうしてもsubme11でもcrfを1下げる位の容量増加（10％強）はあるので
そこまでこだわるメリットがあるかどうかはやっぱり人それぞれだと思う

ただ、元々psy-rd1.0:0.0でやってたなら
0.5に落としてその分mbtreeを切るという選択肢は有りだと思う
それなら容量増加は1〜2％程度で済むから

>>220-221
設定は>>215をsubme11にした上で psy-rd crf それぞれ弄ってます
x264のバージョンはx264.nlのr2245 x64 10-bit

223 ：名無しさん＠編集中：2013/02/22(金) 21:50:30.02 ID:UsCwEn4D.net

>>222
画質比較をするならば、crfじゃなくて2passでやるべきだという指摘なのだが、なぜにcrf？

224 ：名無しさん＠編集中：2013/02/22(金) 22:22:58.28 ID:YsjT3/zV.net

>>223
パラメーターの特性を厳密に検証したいわけではないし（実用範囲で充分）
趣味でやっている以上あなたに従う義務もないので
2-passで検証したい人がいればその人がそうすればいいんじゃないでしょうか

あと1-pass CBRでやるならわかるけど2-passにする必要性もよくわからないし

ご指摘はありがたく頂戴した上で今度の検討材料とさせていただきます
どうもありがとうございましたm()m

225 ：名無しさん＠編集中：2013/02/22(金) 22:26:52.12 ID://rErz5C.net

厳密に検証しないならblogかどっかでやってくれ
誰の得にも何の参考にもならない

226 ：名無しさん＠編集中：2013/02/22(金) 23:48:20.15 ID:eAaxBiS5.net

>>222
215です
わざわざ検証までしていただいてありがとうございます！
すごくわかりやすくて勉強になりました
--psy-rd 0.5:0.0 --no-mbtreeでcrf17か18でどっちがいいか試してみることにします

227 ：名無しさん＠編集中：2013/02/22(金) 23:50:41.50 ID:UsCwEn4D.net

>>226
おいこら>>224、どう責任取るんだｗ

228 ：名無しさん＠編集中：2013/02/24(日) 14:32:21.07 ID:d+aZ726C.net

avs4x264かまして64bit版のx264使い始めたのですが、
コンソールには x264 [info] の出力は出ますが、
リダイレクトやパイプで取れません
とれるのはavs4x264のログだけになってしまいました。
どうやったら x264 のログ取れますか

229 ：名無しさん＠編集中：2013/02/24(日) 14:38:40.90 ID:d+aZ726C.net

自己解決--log-file おぷそんあった

230 ：名無しさん＠編集中：2013/02/26(火) 00:27:33.49 ID:SiPZOEyx.net

オプション自体の効果を調べてるんじゃなくて
絶対にcrfを使うという前提での比較をしてるだけだと思えば
>>222でも別にどうでもいい

「検証」なんてものとはほど遠いとは思うが
crfしか使わない俺には参考になった

231 ：名無しさん＠編集中：2013/02/26(火) 12:40:51.34 ID:BGpE+m/O.net

>>230
言いたい事はわかるが、それでもそれは間違っている。

ともかく、大前提として容量を揃えないと、比較する意味が全くない。
オプション弄りました→ 容量増えました→ 画質上がりました
これでは、オプションが効果的だったのか、それとも普通にcrfを落としたほうが有益だったのか、さっぱりわからない。

容量を揃えれば、オプションを変える前と後とで、どちらの画質が良いのかを比べることが出来る。
その後、crfに戻して、どの画質や容量ならば納得できるのか、crf値を決めるのが正しいやり方。

232 ：名無しさん＠編集中：2013/02/26(火) 15:25:51.47 ID:XEpTdBiG.net

>>231
なんかもういちゃもんレベルだなあ…
no-mbtreeはともかくpsy-rd下げるのは容量増加になり得ないし
no-mbtreeだって複雑な部分や暗部にビットレート割り振るオプションなんだから考え方としてはcrf下げるのと近い
それでも納得いかなければ自分がエンコするときにcrf下げればいいだけの話じゃん

はっきり言うけど他人の検証に延々とケチ付けてるだけの人より
実際に比較上げてくれてる人の方がずっと参考になるよ

233 ：名無しさん＠編集中：2013/02/26(火) 15:33:29.58 ID:ZACkhuOX.net

素晴らしい検証結果だけど参考にしないほうがいいよ

234 ：名無しさん＠編集中：2013/02/26(火) 16:12:37.35 ID:BGpE+m/O.net

>no-mbtreeはともかくpsy-rd下げるのは容量増加になり得ないし
いや、減少増加でも同じことなんだが…

>no-mbtreeだって複雑な部分や暗部にビットレート割り振るオプション
ん？

>他人の検証に延々とケチ付けてるだけ
有益な検証ならそんな事はしない。
間違った検証で、間違った結論に達しているから反論している。

比較を上げるのは構わない。
ソースに合わせるためのオプションを、他の素材で試してどうするんだという思いはあるので面倒だが。
それより、比較動画生成用のbatでもアップしたほうが有益そうだが、どうする？
正直、そんなものは一々保存していないので今から作るのだがｗ

235 ：名無しさん＠編集中：2013/02/26(火) 16:13:27.33 ID:BGpE+m/O.net

減少増加でも　×
減少でも増加でも　○

236 ：名無しさん＠編集中：2013/02/26(火) 17:38:46.06 ID:XEpTdBiG.net

>>234
bat上げるとかそういった方向での建設的でいいと思う
他人の検証にケチ付けてるだけで具体性もなく反論にすらなってない粘着を延々とやられてもしつこいだけだし

237 ：名無しさん＠編集中：2013/02/26(火) 18:47:33.73 ID:hHx0ztPC.net

ID:UsCwEn4Dは検証した人間に絡むんじゃなくて質問者に応対すべきだったな

238 ：名無しさん＠編集中：2013/02/27(水) 20:33:18.94 ID:cHNvZTFM.net

このまま逃亡する　に一票
横槍入れるしか能の無い奴が検証用スクリプトはおろか設定だって晒す訳がｗ

239 ：名無しさん＠編集中：2013/02/28(木) 14:38:40.66 ID:NLJpMEsz.net

初心者スレだからか、自演だからか知らないが、本気で言っているのか？
subme11だと膨らむだとか、no-mbtreeが複雑な部分や暗部にビットレート割り振るだとか。

psy-rd, AQ検討用バッチ(?)
http://www1.axfc.net/uploader/so/2811078.zip

あと、presetが有用なのかどうなのか気になったから試してみた。
2シート目にsubmeの検証も入っている。
LibreOfficeで作ったから、MS-officeで開いたらどうなるかは知らない。

暗部については、avisynth10bitハック+x264 10bit使え で終わる話だし、
8bitで行くにしても、avisynthも絡んでくるのでスルーした。

240 ：名無しさん＠編集中：2013/02/28(木) 16:17:22.28 ID:Gv+Xdvug.net

>>239
乙です
odsファイルはttp://www.henkan-muryo.com/spreadsheet-converter.phpこれで変換して読みました
txt形式で上げてもOKなら編集する（というかここに書き込む）よ

241 ：名無しさん＠編集中：2013/03/01(金) 00:26:46.76 ID:iGDD5IdE.net

>>239
subme11だと膨らむなんて誰も言ってないと思うんだけど…

242 ：名無しさん＠編集中：2013/03/01(金) 00:46:01.02 ID:OUWm4cR6.net

239じゃないが>>222だろ。

> ただどうしてもsubme11でもcrfを1下げる位の容量増加（10％強）はあるので

243 ：名無しさん＠編集中：2013/03/01(金) 00:53:38.08 ID:iGDD5IdE.net

>>242
それは--no-mbtreeにした場合、subme11でもcrfを1下げる位の容量増加（10％強）はあるってことじゃないの？
subme同士の比較してるならわかるけど>>222は--no-mbtreeと--mbtreeの比較みたいだし

244 ：名無しさん＠編集中：2013/03/01(金) 11:11:26.74 ID:jOgJH0wz.net

mbtreeはビット節約のための手抜き度を指定するもの
デフォだと手を抜いているのが見えすぎるが、上げるほど全体の効率は落ちていく

245 ：名無しさん＠編集中：2013/03/01(金) 12:05:55.35 ID:VWWUy+dD.net

つまりno-mbtree最強伝説

246 ：名無しさん＠編集中：2013/03/01(金) 13:17:55.59 ID:0ezkzB8r.net

それは違う
短時間で消える部分や、あまりにも複雑なフレームをまじめに再現するのはビットの無駄
サイズがいくら大きくなってもいいのでなければ、mbtreeを使うのは基本

247 ：名無しさん＠編集中：2013/03/01(金) 13:40:04.20 ID:cwveWsnx.net

>>243
普通に読み違えてたorz

>>244
手抜き度を指定するのはqcomp。
mbtree→ 手抜き度をマクロブロック毎に設定
no-mbtree→ 手抜き度を一枚の絵全体で一括指定。

mbtreeをonにすると、"手抜き"が的確に効くようになるため、
no-mbtree時代に設定されたままのqcompを使用すると、効きが強すぎることになる。

どうしてもmbtreeが嫌いな人がいるなら、qcompを検証した上で、その問題の箇所を指摘してもらいたい。

248 ：名無しさん＠編集中：2013/03/01(金) 15:48:01.10 ID:qR+6qhog.net

トータルとして考えれば、no-mbtreeで画質が向上するというのは
あながち間違いでも無い訳か

249 ：名無しさん＠編集中：2013/03/01(金) 15:52:26.30 ID:VWWUy+dD.net

つまりno-mbtree最強伝説

250 ：名無しさん＠編集中：2013/03/01(金) 16:17:53.04 ID:cwveWsnx.net

どうしてそうなるんだよｗｗ
もういっそcrfやめてqp使った方が良いんじゃない？　って話になるぞ

251 ：名無しさん＠編集中：2013/03/01(金) 16:29:50.98 ID:ooG+NUiU.net

mbtree切るのってどんなにサイズが膨らんでもいいから少しでも画質を良くしたいって人だけじゃない？
別にエンコなんて趣味だから好きにすりゃいいけど
俺はmbtree切るは割に合わないというかサイズと画質のバランスは良くないと思うな〜

252 ：名無しさん＠編集中：2013/03/01(金) 16:30:44.77 ID:ooG+NUiU.net

>>250
だよね

253 ：名無しさん＠編集中：2013/03/01(金) 16:35:03.81 ID:7RQJhlwX.net

2passでnombtreeってどうなの

254 ：名無しさん＠編集中：2013/03/01(金) 17:33:28.98 ID:cwveWsnx.net

>>251
いや、だから容量を揃えて比較しろと言っているのだが…；
mbtreeで容量が縮むのなら、no-mbtreeと同じ容量になるまで、
crfを下げれば良い話だ。　同じ容量になれば、mbtree onの方が画質は良い

255 ：名無しさん＠編集中：2013/03/01(金) 17:48:59.45 ID:ooG+NUiU.net

>>254
まあそりゃそーだ

256 ：名無しさん＠編集中：2013/03/01(金) 18:11:35.88 ID:bL72RaV5.net

>>254
その理屈はおかしいだろ？ｗ
それだと2passでmbtreeするよりno-mbtreeの方が複雑な場面の画質が良いって話になっちゃう
全体の画質とmbtreeで対象にされる複雑な場面の画質を混同しちゃあかん

257 ：名無しさん＠編集中：2013/03/01(金) 18:22:37.42 ID:iGDD5IdE.net

>>254
静的なシーンの品質をこれ以上求めているのか
静的な部分は現状でいいから複雑なシーンの品質を求めるのかで評価は変わるから
一概に「〜の方が画質は良い」とは言えないだろうね
メリットデメリットの比較ではなく単純に優劣として一元単純化してしまうのは
「つまりno-mbtree最強伝説」の人と同じドツボにはまってると思う

=>>247
だから>>239の内容がsubme比較だったのか
言葉のドッヂボールは相手の意見の確認を行わないからシャドーボクシングになりやすいよね
外野としてはsubmeの比較データ見られて得だったけどｗ
odsファイルtextになおして再掲してもいいかな？

258 ：名無しさん＠編集中：2013/03/01(金) 18:23:27.86 ID:VWWUy+dD.net

まあ俺のレスは半分冗談なわけだが半分は本気だ

259 ：名無しさん＠編集中：2013/03/01(金) 18:25:43.51 ID:bL72RaV5.net

>>257
上げた本人じゃないんだが、見やすい形で掲載してくれるとスレ的には財産になる

260 ：名無しさん＠編集中：2013/03/01(金) 19:45:45.63 ID:cwveWsnx.net

>>257
>>240の人かな？　レス忘れてすまなかった。　大丈夫です。

mbtreeのon/offは、単純な優劣の問題。　メリットデメリットを言うなら、qcompの問題だな。
no-mbtreeで考えるなら、crfとqpのメリットデメリット。 まぁ、実際にはqpなんぞデメリットしかないのだが。
mbtreeは、crfの機能拡張だと考えれば良い。 mixed-refsに似てるといえば似てるか…？

261 ：名無しさん＠編集中：2013/03/01(金) 21:00:52.92 ID:cwveWsnx.net

多分、口で言ってても仕方ないから動画で。
http://www1.axfc.net/uploader/so/2812666.zip

2passだと容量が一定にならなかったから3pass。
1000kbpsの0.1が、効果を一番把握しやすいと思うから、それから見て欲しい。
正直、ソース選択は間違ったかもしれない。 　アニメ本編とか最大限効果的だろうね。

262 ：名無しさん＠編集中：2013/03/01(金) 21:35:48.11 ID:bL72RaV5.net

>>261
いや、静止部分と複雑な部分の対比としては良いソースだと思う

面白いね、かなり明快に差が出るのな
mbtree=1と0を比べると1は右の静止画部分が、0は時機周辺の弾やエフェクト部分が高精細
どちらが良いのかは俺には判断つかんが…

263 ：名無しさん＠編集中：2013/03/01(金) 21:51:28.18 ID:DcaVNPEM.net

良い悪いは個人で決めればいいという前置きをしつつ
人間の目は動くものを追いかけ動かないものは見えなくなる(色味を失いぼける)性質がある

264 ：名無しさん＠編集中：2013/03/01(金) 22:03:04.08 ID:LB0Pei31.net

no-mbtreeは設定内のビットレートになら強い
が、ひとたびその枠を超える部分が来ると劣化が目立つようになる

265 ：名無しさん＠編集中：2013/03/01(金) 22:45:15.86 ID:iGDD5IdE.net

>>260-261
240の人とはちがうけどありがとう
>>239内[preset,subme検証.ods]のtxtファイル版
ttp://www1.axfc.net/uploader/so/2812809.txt

>>261
検証乙です
静的なシーンの品質をこれ以上求めているのか
静的な部分は現状でいいから複雑なシーンの品質を求めるのかを比較するのにいいソースだと思う
ビットレート指定とちがってcrf指定だとサイズが増減するからね

266 ：名無しさん＠編集中：2013/03/02(土) 00:21:08.61 ID:RrNZyQCg.net

>>263
だが、動いている状態でどれくらい識別できるのか？　という問題がある。
もし、速い動きもバッチリ見えてしまうなら、アニメの中割りなどは成立しない。

逆に、人物が良く動くにつれて、背景も急に手抜きになるアニメがあったら、どう思う？
え、そこ手を抜いちゃうの？ 別に手を抜かなくてもよくね？ てかまずくない　って思わない？
背景まで手を抜いちゃうのがno-mbtree。

あくまで、動きの速い部分はバレないから手を抜く。 バレるところ(動かない所Iは手を抜かない。
比較に作ったqcomp 0.1は論外、デフォルトの0.6でも強いから、目の良さに応じて、0.7〜に設定すべきだろう。

267 ：名無しさん＠編集中：2013/03/02(土) 00:33:18.70 ID:RrNZyQCg.net

>>265
未だにビットレート指定で検証している意味を理解してもらえてない気もするが…。

crfでこそ、mbtreeは生きるとも言えるけどね。
crfでなら、qp値の指定は動きがどれだけあるか(別問題としてAQとpsyの介入はあるが)によって決定される。
つまり、常に見た目には一定の品質が保証されるということだ。
(そのためにはqcompの設定を適切にしないといけない。)

no-mbtreeだとそうは行かない。
no-mbtreeの制御では、ビットレートを大量に消費するシーンではクオリティを下げ、そうでないシーンではクオリティを維持する。
結果、"VBRだが、固定ビットレートっぽい"挙動を示す事になる。
そもそも、qcomp 1.0は完全なVBRを意味し、qcomp 0.0はCBR(固定ビットレート)を意味する。
CBRは論外だけど、qpも合理的でない…というジレンマがno-mbtreeにはあるという話でした。

268 ：名無しさん＠編集中：2013/03/02(土) 01:11:48.63 ID:6e1hko6m.net

>背景まで手を抜いちゃうのがno-mbtree。
それは1pass固定レートの話で、CRFで用いれば背景の劣化ではなく容量の増大に繋がるのでは？
2passであれば全体の品質低下は起こるが、背景がある1区間でのみ崩壊する様な不都合は無いかと

269 ：名無しさん＠編集中：2013/03/02(土) 01:18:57.72 ID:RrNZyQCg.net

>>268
劣化と容量の増大が共に起こる。
qcomp 0.0だと、容量は変化しないが劣化が起こり、
qcomp 1.0だと、劣化は起こらないが容量が増大する。

つまり、その間のqcompであれば、容量が増えはするが劣化が生じることになる。
もちろん、バレない範囲での劣化ということではあるのだが、動かない部分も混じっている以上、バレてしまう。

270 ：名無しさん＠編集中：2013/03/02(土) 01:22:12.74 ID:RrNZyQCg.net

2passについて言及し忘れてた。
2passでも、やはり激しい動きの部分のみ、背景が劣化することになる。
"固定ビットレートっぽい挙動"と呼んだのはコレのことを言いたかった。
いい加減しつこいが、これはqcomp 1.0にすれば起こらない。

271 ：名無しさん＠編集中：2013/03/02(土) 01:40:42.62 ID:6e1hko6m.net

>>270
うーん、上げて貰えた動画を見返してみたんだけど
例えば実用範囲オプションの1000kbps-0.7mbtree/0.7no-mbtreeでは
画面右の静止部分での「急な手抜き」って4秒・8秒・12秒の各ポイントで双方で起こってるよな？
no-mbtreeオプションが原因とも思えないんだけど、それは程度問題という認識で良いんだろうか

272 ：名無しさん＠編集中：2013/03/02(土) 01:44:54.86 ID:3CuC2ad9.net

1000kbps程度でno-mbtreeとか言ってたのｗ

273 ：名無しさん＠編集中：2013/03/02(土) 01:45:49.03 ID:L7c/Wcsf.net

ビットレートが足りてないもので比較しても意味ねーだろ
どちらかといえばmbtreeのが有利だが

274 ：名無しさん＠編集中：2013/03/02(土) 01:46:47.40 ID:hO73C7tA.net

--no-mbtreeと--qcomp 1.0 安定か

275 ：名無しさん＠編集中：2013/03/02(土) 02:09:13.60 ID:Jzvl5VgP.net

解像度にもよるけど1000kbps程度（しかもビットレート固定）ならmbtree使った方がいい

276 ：名無しさん＠編集中：2013/03/02(土) 02:17:32.98 ID:RrNZyQCg.net

>>271
それはkeyintによる、Iフレームの挿入。　手抜きどころか、真逆でテコ入れ。
これはno-mbtreeオプションは関係無い。 弄るとならipratio,pbratio,scenecut辺りかな？

>>274
qcomp1.0ならどっちでも同じなんだがなｗ　好きに汁

>>275
>（しかもビットレート固定）
いつになったらこの考え方から抜け出せるんだ？　全く理解できない。

SDソースで済まないが、もう一本グレラガンOPでやってみた。
やっぱりmbtreeの方が、qcompの数字を大きくしないと圧縮しすぎるね。
mbtreeの方は前半微妙に思えるかもしれないが、後半に均一にビットをとっておいているからそうなっている。
http://www1.axfc.net/uploader/so/2813178.zip

277 ：名無しさん＠編集中：2013/03/02(土) 02:27:29.51 ID:RrNZyQCg.net

>>271>>276
ごめん、ちょっと飛ばして読んでた。画面→か。

たしかにmbtreeでも、変わらないはずの静止部分の画質も少し変化しているね。
これは恐らくレートコントロールのため。
毎回全く同じqp値のIフレームを挿入するわけではないから、(pフレームを基準に考えるため)
今回のように全く動かない(=全てスキップMB)場合は、一旦Iフレームで決定された画質が修正されることがないため、こんなことになる。

278 ：名無しさん＠編集中：2013/03/02(土) 02:44:13.41 ID:RrNZyQCg.net

いや、なんか違う気がしてきた。 qpでAQもpsyもoffにしたら、ipbとqp値が綺麗に揃ったような気もする。
やっぱり理屈上では、静止部分は画質変わらないはずだと思う。
no-mbtreeのように、状況に引きづられて大幅に変化してるって事も無いけどね。

コード読めるわけでもないし、正直よくわからん。
一人でID真っ赤になるのって疲れるね！ ってことでいい加減寝ます。

279 ：名無しさん＠編集中：2013/03/03(日) 01:25:58.26 ID:93NweMmP.net

--no-mbtree --qcomp 0.8 より --qcomp 1.0 (--mbtree無効)の方がファイルサイズは小さいんだな

--no-mbtree --qcomp 0.8
x264 [info]: SSIM Mean Y:0.9903576 (20.158db)
x264 [info]: PSNR Mean Y:47.604 U:49.591 V:49.541 Avg:48.148 Global:47.917 kb/s:1259.11

--qcomp 1.0
x264 [info]: SSIM Mean Y:0.9895724 (19.818db)
x264 [info]: PSNR Mean Y:47.062 U:49.200 V:49.138 Avg:47.637 Global:47.435 kb/s:1147.32

しかしSSIMも1.0の方が下がってるのか

280 ：名無しさん＠編集中：2013/03/03(日) 02:46:18.01 ID:93NweMmP.net

と思ったけど別のソースでは順当に上がって行ってる
↑の場合はノイズが入るのが原因かな？

--mbtree --qcomp 0.8
x264 [info]: SSIM Mean Y:0.9931172 (21.622db)
x264 [info]: PSNR Mean Y:50.473 U:50.575 V:50.368 Avg:50.395 Global:49.392 kb/s:2301.50

--no-mbtree --qcomp 0.8　サイズ 1.0943倍
x264 [info]: SSIM Mean Y:0.9932227 (21.689db)
x264 [info]: PSNR Mean Y:51.087 U:51.410 V:51.240 Avg:51.111 Global:49.667 kb/s:2518.45

--qcomp 1.0　サイズ 1.133倍
x264 [info]: SSIM Mean Y:0.9933264 (21.756db)
x264 [info]: PSNR Mean Y:50.516 U:50.159 V:49.985 Avg:50.246 Global:49.482 kb/s:2604.97

281 ：名無しさん＠編集中：2013/03/03(日) 10:58:46.14 ID:7vqIJ5fg.net

subme7以上では、 SSIMやPSNRは意味はないと開発者が言っていたような

282 ：名無しさん＠編集中：2013/03/05(火) 00:13:10.78 ID:8Zj5AoeH.net

ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9897690　　1.107378625
--qcomp 0.8 --metree　　　0.9896832

咲-saki- 阿知賀編 ED2
0.9878268　　1.214733073
0.9876413

氷菓 OP1
0.9868882　　1.088022595
0.9871018

氷菓 ED2
0.9898708　　1.066129357
0.9901036

氷菓 OP2
0.9876465　　1.101488254
0.9876512

ノイズが入ったりエフェクトが入ったりして
ビットレートが一気に跳ね上がったり--vbv-maxrateまで行っちゃうようなソースだとSSIMが下がるのかな

283 ：名無しさん＠編集中：2013/03/05(火) 00:24:52.60 ID:8Zj5AoeH.net

ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9897690　　1.107378625
--qcomp 0.9 --metree　　　0.9899077　　1.134244208
--qcomp 0.8 --metree　　　0.9896832

氷菓 OP1
0.9868882　　1.088022595
0.9875023　　1.112881632
0.9871018

氷菓 ED2
0.9898708　　1.066129357
0.9901788　　1.101478751
0.9901036

--qcomp 0.8→1.0でSSIMが上がったケース・下がったケースの両方で
0.9＞1.0という結果

284 ：名無しさん＠編集中：2013/03/05(火) 04:58:24.74 ID:8Zj5AoeH.net

訂正

ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9899287　　　1.148040305
--qcomp 0.9 --metree　　　0.9899077　　　1.131674585
--qcomp 0.8 --metree　　　0.9896947

285 ：名無しさん＠編集中：2013/03/05(火) 10:21:50.70 ID:cu1PYHeO.net

metree ってオプションが最近出来たのかと思って
検索しちまったじゃねーかよ！

286 ：名無しさん＠編集中：2013/03/05(火) 14:00:22.74 ID:1CQeSiW3.net

ビットレートかSSIMのどちらかを揃えた方が分かりやすい比較になる

287 ：名無しさん＠編集中：2013/03/05(火) 17:12:15.67 ID:DCayajaU.net

SSIMの素の値って見づらいから対数表記(dB) に統一されるといいのにな
-10 * log10( 1 - ssim )
で計算されているそうで

288 ：名無しさん＠編集中：2013/03/05(火) 23:50:35.80 ID:cRudJu0H.net

--qcomp 0.9 --metreeが今のところ一番無難なのか

289 ：名無しさん＠編集中：2013/03/05(火) 23:58:04.16 ID:gb92noNh.net

エラー出ないの？

290 ：名無しさん＠編集中：2013/03/06(水) 01:09:51.02 ID:a8RdaoJD.net

>>288
それマルチパスでエンコする場合の話？
そんな極端にqcomp上げたらcrfでエンコする意味無いんじゃないの
x264のパラメータって基本極端な値指定するとろくなことにならない気がする

291 ：名無しさん＠編集中：2013/03/06(水) 01:45:16.07 ID:A9oVztpB.net

>>290
1ならともかく0.9で意味ないってことはないと思うけど
まあcrfの値次第かな

292 ：名無しさん＠編集中：2013/03/06(水) 13:10:05.65 ID:+xj+qmwt.net

qcompを0.8より高くするならcrf指定よりqp指定した方がエンコの目的に沿うと思う。
x264の画質は結局のところ色んなパラメータのバランスで成り立つものだから
一つのパラメータを極端に上げたり、あるいは下げたりするとバランスが崩れて目的を見失うんじゃないか。

293 ：名無しさん＠編集中：2013/03/06(水) 16:26:34.09 ID:z6ylvJxh.net

ぱっと見を保ちつつサイズを抑えるなら0.8でも高すぎる
SSIM的には0.6あたりが最大のようだから

294 ：名無しさん＠編集中：2013/03/06(水) 19:26:33.50 ID:eDY1CJf9.net

変化の大きいアニメなんかだと0.8もアリかと思うけど、
同時にqpminとqpmaxの調整とかzonesによる対応の検討もしたいねえ
mbtreeも素材によってはBフレームの劣化とサイズの増加を招くし、
結局一番無難な回答は「ソースによるから試行を重ねて好みに合うパラを探しましょう」に尽きる

295 ：名無しさん＠編集中：2013/03/06(水) 21:44:22.72 ID:dNoIHJr+.net

結局どれだけビットレート確保できるかって話だからなあ
qcomp0.9指定でもcrf16とcrf23じゃ全然違うし

296 ：名無しさん＠編集中：2013/03/07(木) 00:44:40.08 ID:nd8caNCR.net

俺がテストした場合、他のパラメーターは同じで、
qcomp0.8、crf20 と qcomp0.6、crf18 で大体同じぐらいの
ビットレートになり、画質は前者の方がわずかに良いかなーって感じだった。

297 ：名無しさん＠編集中：2013/03/07(木) 14:49:55.80 ID:yDZBWqjf.net

>>295
いや、「画質劣化がわからないようにどこまで縮められるか」だと思うけどね。

最も縮む設定を探るには、ビットレート指定での比較をせざるを得ないという話。

最も縮む設定で、劣化をどこまで許容できるのかcrf値で指定、というアプローチが一番良いと思うよ。
目安の目標ファイルサイズを決めて、crfを検討するのも良いとは思うけどね。

ただし、QP値によって最適なオプションが変わるケースもあるから、
あまり目標画質と離れすぎた状態でオプションを比較するのはやめたほうが良いと思う。

298 ：名無しさん＠編集中：2013/03/07(木) 21:36:10.33 ID:IHdd+ZjY.net

>>297
＞「画質劣化がわからないようにどこまで縮められるか」
これに重点を置くのならこっちのスレの方がふさわしいと思う

【目指せ】高画質アニメエンコスレPart18【軽量】
http://toro.2ch.net/test/read.cgi/avi/1313047835/

299 ：名無しさん＠編集中：2013/03/07(木) 21:49:36.98 ID:IHdd+ZjY.net

誘導先はここじゃない
>>4

300 ：名無しさん＠編集中：2013/03/07(木) 21:50:40.40 ID:IHdd+ZjY.net

誤爆したorz

301 ：名無しさん＠編集中：2013/03/08(金) 00:34:26.05 ID:D2PJ5+Sx.net

crf=21程度の実写ソースで随分と綺麗なエンコされてる動画を見つけたので
設定参考にしようとMediaInfoで覗いてみたところ「cqm」が2になっていた
この値の意味は0=flat 1=jvt 2=カスタムマトリックス で合ってるよね？

やはり、極めてる人はカスタムマトリックスを指定するのが基本なの？
アニメや実写、こんなソースにはこれがお勧めってのがあれば教えて欲しい