■ このスレッドは過去ログ倉庫に格納されています
x265 rev2
- 345 ：名無しさん＠編集中：2015/04/10(金) 14:49:50.99 ID:RJEnVKi9.net
- おま環
- 346 ：名無しさん＠編集中：2015/04/10(金) 16:46:03.99 ID:ryQkocaA.net
- アドバイスだしてる人に対して、冒頭から「だから～～」って切り返すのは人の話しを聞かない人間の特長ｗ
「自分が正しくて他が間違えてる」って考えるタイプだろうから相手するだけ無駄。
まぁ結局の所 >>345 であって他の大多数では何ら問題無い。
大体途中でx265がエラー吐くとか、それ正常にフレームが渡されているのかもわからねーなｗ
- 347 ：名無しさん＠編集中：2015/04/10(金) 18:18:49.76 ID:BUyfRP2k.net
- >>344
・ > よく判らないけどベースフレーム判定？の誤爆でサイズが膨張するっぽい
・ > 基本フレーム、差分フレームの判定ミスも普通にありえると思う
根拠不明。
CPU依存と言ってる割に環境情報も不明、処理方法や入力プラグイン等も含めたTSの扱い方も不明、
インタレ解除や使用フィルタも不明、x265guiEx等のバージョンも不明。
設定自体が崩れるというバグの可能性もあるし設定ミスの可能性もあるのに
>>340や>>343の確認をしない理由も不明。
設定ミス、またはx265以外の部分で生じている問題という可能性の方が高そうだが、
決めつけばかりで、論理的に問題を調べようとする姿勢が見えない。
- 348 ：名無しさん＠編集中：2015/04/10(金) 18:28:39.08 ID:LVyfiktp.net
- guiEXの人のところにも書いてるみたいだから
おっつけ原因も分かるんでない？
- 349 ：名無しさん＠編集中：2015/04/10(金) 18:58:15.02 ID:BUyfRP2k.net
- >>348
ブログコメントの「highbit depthでのビットレート値」の件のことなら、書いたのは俺なんで、>>344とは別。
ttp://rigaya34589.blog135.fc2.com/blog-entry-599.html#comment2807
ビットレート指定の場合にhighbit depthへのチェックが絡むと、ビットレートがスライダーで指定できる
近似値に変えられてしまうという挙動だけど、>>344はcrf23指定でエンコしてると書いてるし、
crf指定の場合はコメントに書いたような問題は起きなかったから全然違う問題だと思う。
- 350 ：名無しさん＠編集中：2015/04/10(金) 19:39:52.16 ID:P+3VCH+g.net
- >>344
こういう検証ってAviUtlと離して考えるべきだと思うな
短い動画をy4mで出力してから検証すればいいのにややこしくなる
これはAviUtlやAviSynth等のフロントエンド側に問題があった場合収集がつかないから
特にフィルター側でランダムな処理が入ると結果が大きく変わることがある
それとversionとdistanceを書いて貰えないと困る(例 ver1.6+160)
ver1.5でも400～500種類ぐらいあるわけで同じver1.5でもとっくに修正されてる可能性もある
検証するのに時間かかるのは当然だけど検証を開始するときはその時点で出来るだけ新しいものを使うべき
そこら辺をある程度しっかりしてれば検証に疑問を持つ人も減るはず
つまりx265側の問題と切り分けるのに不確定要素が絡んでる疑念を排除しきれないと荒れるって事
- 351 ：名無しさん＠編集中：2015/04/10(金) 19:44:26.93 ID:xFWGr7wl.net
- あ、ぐだ書きの人だ
- 352 ：名無しさん＠編集中：2015/04/11(土) 08:25:56.58 ID:0VKloJdv.net
- ttp://www1.axfc.net/u/3447575
なんとかビルドでけた。
- 353 ：名無しさん＠編集中：2015/04/12(日) 04:24:21.94 ID:gXAWI5gp.net
- asmでカリカリチューンされてるから、コンパイラでの最適化があまり効かない。
- 354 ：名無しさん＠編集中：2015/04/15(水) 04:49:28.79 ID:Nbp27wUo.net
- >>347
>>349
>>340,342
一番最初に設定確認した&MediaInfoでも確認した、当たり前過ぎて絶句した
crf 23でエンコしてたけどhighbit depthのON/OFFで勝手にビットレートも変わるっぽいね
そうするとベースフレーム、可変フレームは関係ないっぽい
被害はエンコ後のサイズが増えるだけかな。(安心した)
>>350
お騒がせしました。
- 355 ：名無しさん＠編集中：2015/04/15(水) 10:21:09.12 ID:xoQN00Qr.net
- おう、無駄に騒ぎ大きくするなよ
- 356 ：名無しさん＠編集中：2015/04/15(水) 12:58:51.10 ID:b54EXsP9.net
- なんか勘違いしたままのようだけど、>>346が全てだし２度と戻ってこないでほしいな。
- 357 ：名無しさん＠編集中：2015/04/15(水) 13:10:06.29 ID:RIpG39ND.net
- 自分のレスが全てとか言っちゃうｱｲﾀﾀﾀ･･･
- 358 ：名無しさん＠編集中：2015/04/15(水) 13:46:59.67 ID:b54EXsP9.net
- 残念ながら俺は無駄に相手をしてしまった別口。
- 359 ：名無しさん＠編集中：2015/04/15(水) 15:15:51.32 ID:xUFEQRls.net
- >>358
すまんな。 >>346 を書いたのは俺の様だ。
JaneStyle で真っ赤なレス付いてるから気付いたｗ
- 360 ：名無しさん＠編集中：2015/04/15(水) 17:50:05.12 ID:ZjmO4krt.net
- せめてx265のエンコードログくらい貼って欲しかった。
- 361 ：名無しさん＠編集中：2015/04/20(月) 03:41:07.01 ID:Z/s1/q2z.net
- アニメをエンコードしてる人はcrfいくつくらいにしてますか？
- 362 ：名無しさん＠編集中：2015/04/20(月) 06:53:09.08 ID:LDe1boNF.net
- 23
- 363 ：名無しさん＠編集中：2015/04/20(月) 13:43:32.91 ID:aTHD0cqU.net
- いくつくらいのおじさんがアニメをエンコードしてますか？
- 364 ：名無しさん＠編集中：2015/04/20(月) 16:29:06.19 ID:8HshwEAo.net
- ∞
- 365 ：名無しさん＠編集中：2015/04/25(土) 15:27:28.63 ID:41RL/cGC.net
- １つのソースを色々な設定でエンコして、SSIMやビットレートをグラフにまとめてみた。
作りかけでしばらく放置してたので、使ってるバイナリが
r2525kMod、r2538kMod、1.5+445、1.6+64とバラついてるのは勘弁。
ソース（1920x1080、2018フレーム、割と動きのある実写的・アニメ的クリップ混在）
ttp://www1.axfc.net/u/3455339/x26x
エンコード時間の比較
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1868.jpg
様々なプリセット/crfでのSSIMとビットレートの分布
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1869.jpg
x265 medium 対 x264 medium
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1870.jpg
x265 medium 対 x264 slow
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1871.jpg
x265 medium 対 x264 slower
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1872.jpg
これらのグラフから見ると、今のところx265がx264よりも優位になるのは、
x264のcrf>27（x265だとcrf>25）あたりの中・低画質レベルということになるのかな。
- 366 ：名無しさん＠編集中：2015/04/25(土) 21:46:36.92 ID:NoF6OrkD.net
- ごめん
違法ダウンロードでHEVCが遙かに上って事はもう分かってるから
- 367 ：名無しさん＠編集中：2015/04/25(土) 21:55:39.23 ID:EDDtYgdY.net
- x265 のバージョン違い混在とかちょっと^^;
たしかこの人は必死にx264とx265を戦わせたい人だったね。
人のやってるエンコードに粘着口出ししててきもかった。
- 368 ：名無しさん＠編集中：2015/04/25(土) 22:05:32.86 ID:tM3iL94l.net
- >>367
Handbrakeスレにいたデータ嫌いさんは引っ込んでてほしいなぁ・・・。
ちょっと検証データ貼っただけでまともな意見も言えず
無理やり理由つけて人を叩いてるだけって頭おかしいと思う。
- 369 ：名無しさん＠編集中：2015/04/25(土) 22:06:50.89 ID:NoF6OrkD.net
- いや
違法ダウンロードでHEVCが遙かに上って事はもう分かってるから
- 370 ：名無しさん＠編集中：2015/04/25(土) 22:09:32.34 ID:tM3iL94l.net
- >>369
よく知らんので参考までに聞いてみたいんだけど、出回ってるのはMain10？それともMain？
- 371 ：名無しさん＠編集中：2015/04/25(土) 22:16:05.19 ID:AAmkZYUn.net
- 何でもいいけどBMDのスレには二度と来ないでくれよ
あまりにウザ過ぎる
- 372 ：名無しさん＠編集中：2015/04/25(土) 22:17:24.47 ID:NoF6OrkD.net
- >>370
main10かな
- 373 ：名無しさん＠編集中：2015/04/25(土) 22:41:12.02 ID:tM3iL94l.net
- >>372
なるほど。サンクス。
- 374 ：名無しさん＠編集中：2015/04/26(日) 12:18:06.70 ID:B41DBfz/.net
- ビットレート3000kbps未満ではx265完全勝利という結論だね
- 375 ：名無しさん＠編集中：2015/04/26(日) 12:48:03.29 ID:xM6vr0/L.net
- >>365
ウザい
- 376 ：名無しさん＠編集中：2015/04/26(日) 13:52:36.87 ID:mduH185B.net
- >>374
>>365のソースについてはそうだけど、必要ビットレートはソースによって違うから
そういう表現はやめたほうがいいかもね。3000kbpsという数字が独り歩きしてしまいそう。
- 377 ：名無しさん＠編集中：2015/04/26(日) 15:28:52.59 ID:31p2eSyL.net
- >>365
たまたまx265が苦手なソースだったんじゃない？
手持ちのファイルをエンコードしても>>302のグラフみたいになるけど。
- 378 ：名無しさん＠編集中：2015/04/26(日) 15:31:43.69 ID:x+mIM4i3.net
- 3000kbps
λ...λ... ﾃｸﾃｸ
- 379 ：名無しさん＠編集中：2015/04/26(日) 16:20:47.74 ID:ADAwhQqh.net
- トレードオフ事項なのにどれが一番だとか他人を巻き込んでの布教活動がほんと邪魔
- 380 ：名無しさん＠編集中：2015/04/26(日) 17:41:07.25 ID:NlysfzYC.net
- >>365 は結局あれな、x265のナニナニでエンコしてるって言うと「それx264のナニナニでエンコした方が速くて綺麗じゃね」って
執拗に言ってまわってたからな。
何か言えば後からベースのずれたデータ持ってくるわ、反論してみれば言いだしが「いや、」で始まって
聞く耳持たないしｗｗ
- 381 ：名無しさん＠編集中：2015/04/26(日) 17:42:26.64 ID:mduH185B.net
- >>377
>>302の1つ目のグラフは>>365と同じソースなんだけど、あれを作った時は
・x264にも--profile mainをつけてしまっていた
・うっかりノイズ除去フィルタをつけっぱなしだった
という失敗があった。
x264の方はHighプロファイルにして比較すべきなので、あらためて>>302と同様のグラフを作ってみたら
こんな感じになった。もちろんソースによって違いは出てくると思う。
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1882.jpg
それにしても、ただの比較検証にやたら噛みついてくる奴はなんなんだろうな・・・。
Handbrakeスレでも、「常時x265 placebo(Crf20)でエンコしてる」って人がいたから
「壮大な無駄だからやめたほうがいいよ」とデータつきでアドバイスしただけなのに、
横から出てきて「無視しろ」だの「押し付けるな」だのと発狂されるし、散々だわ・・・。
- 382 ：名無しさん＠編集中：2015/04/26(日) 17:46:48.52 ID:B41DBfz/.net
- >>381
あのさ、論評されるのが嫌なら貼るなよ
貼られたら論評されるに決まってるだろ？
論評が気に食わなくても、お前の意思でどうにかなるもんじゃない
データの分析解析はサイエンスの世界だから、お前個人の意思や思いなんて入り込む余地はない
- 383 ：名無しさん＠編集中：2015/04/26(日) 17:57:19.30 ID:mduH185B.net
- >>382
データを分析したまともな「論評」なら歓迎だよ。貼ってるのはそのためでもあるし、
>>374についても別に否定してないだろ。
まともな意見を出すでもなく、「無視しろ」「押し付けるな」「うざい」「邪魔」「見苦しい」といった
曲解に基づいた個人攻撃しかしない>>380みたいな輩がうっとおしいだけ。
- 384 ：名無しさん＠編集中：2015/04/26(日) 19:23:07.55 ID:uKW+WGKB.net
- ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
それとx265は動かない場面での圧縮率が特徴だろうに画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
- 385 ：名無しさん＠編集中：2015/04/26(日) 19:39:31.96 ID:mduH185B.net
- >>384
> ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
プリセット/crfの組み合わせの違いでSSIMやビットレートがどうなるか調べるのが目的だったから。
普段はcrf指定でのエンコしかしないし、ビットレート指定エンコはおまけ。
それに、ビットレート指定エンコの方のグラフには、関係性を示そうと思って
bitrateとcrfの両方をプロットしてるよ。
> それとx265は動かない場面での圧縮率が特徴だろうに
そうなの？それは知らなかった。
> 画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
一例として出しただけだし、俺が知りたかったのは動きが多めのソースについてだったからな・・・。
これだけでも結構大変だったし、他のサンプルでの検証まで強制されるいわれは無いと思うんだが。
むしろ誰かに別のソースで検証してみてほしい。
- 386 ：名無しさん＠編集中：2015/04/26(日) 20:03:40.52 ID:uKW+WGKB.net
- 画面がパンし続けたり派手なバンクの連続だけの映像ソースなんて現実にはないから、そのソース使っても動きの多い動画に対する評価としても意味は無いんじゃないの？
- 387 ：名無しさん＠編集中：2015/04/26(日) 20:53:16.53 ID:eRe6v/L2.net
- アラの隠し方の優劣ぐらいは分かるのでは？
- 388 ：384：2015/04/26(日) 21:13:50.92 ID:mduH185B.net
- どんなソースなら>>386が満足するのかはわからないけど、x265が得意なソースでやれという
出来レースみたいな比較検証を別途求められても困るし、そのへんは個人で試してみてくれ。
俺は自分の検証データを共有のために貼っただけだし。
- 389 ：名無しさん＠編集中：2015/04/26(日) 22:02:25.44 ID:uKW+WGKB.net
- 動きの緩急入り混じった普通の動画ソース使えば良いんじゃない
一般的な動画が全体でどれだけ縮むかが重要なのに、全体のごく一部の微妙な優劣に意味あるのか？
- 390 ：名無しさん＠編集中：2015/04/26(日) 22:39:49.52 ID:Mc3v3jYv.net
- スクショ貼ればリーチ一発ツモじゃないすかね
- 391 ：名無しさん＠編集中：2015/04/27(月) 00:50:43.14 ID:FOHIhLOQ.net
- >>389が、"誰もが納得する一般的な普通の検証用動画ソース"を紹介してくれると聞いて。
実写とかアニメとかゲームとか、求めるものは人それぞれだと思うんだけど、どうするんだろうな。
- 392 ：名無しさん＠編集中：2015/04/27(月) 01:11:53.79 ID:Afsd1xYI.net
- BMDスレにくんなっつっただろカス氏ね
- 393 ：名無しさん＠編集中：2015/04/27(月) 03:44:58.51 ID:OapFOipL.net
- >>388
別に恣意的にx265に得意なソースを選べとは言わないけどサンプルが一つだけで結論を出すのは早過ぎるでしょ。
- 394 ：名無しさん＠編集中：2015/04/27(月) 05:48:11.90 ID:5ompSnjB.net
- 実写数種
ゲーム2D3D数種
アニメ2D3D数種
この位あればいいんじゃね
- 395 ：名無しさん＠編集中：2015/04/27(月) 11:19:30.52 ID:WxVW/waA.net
- >>385
アニメでテストするなら、大勢の群集がうごめいてるシーンとか比較してみそ
- 396 ：名無しさん＠編集中：2015/04/27(月) 12:09:40.47 ID:9WSHoLf+.net
- >>391
そのどれでも良いけど、始まりから終わりまで画面全体が動きっぱなしの作品や映像なんかあるの？
実写、ゲーム、アニメのどれにしろ画面全体が横や縦に流れ続けてればx264もx265も微妙な差しかでないよ
- 397 ：名無しさん＠編集中：2015/04/27(月) 14:15:23.45 ID:zYNmxHXA.net
- >>393
書き方のせいで誤解を生んでしまったかもしれないけど、>>365の最後の一文は
「このソースの場合」での話であって、一般的な結論として書いたつもりはないよ。
動きが多いソースで実験したのは、そういうシーンの出来を見たかったのと、
その方が劣化具合がわかりやすいと思ったから。
そういう目的での実験だったから、「動きっぱなしのクリップなんて普通無い」とか言われても困る。
別途各個人で一般的だと思えるソースでやってみてくれとしか。
気が向いたら別のソースでもやってみるけど、面倒だしやらないかもしれない。
- 398 ：名無しさん＠編集中：2015/04/27(月) 15:42:29.88 ID:dMAJ2eO/.net
- もういいからこなくていいよ。
結局何か指摘されたって、そんなの個人でやってくれだとか困るだとか言い訳してみたり
議論は疎か会話すら成立してないじゃない?
自分の言いたいことだけ主張しても困るわ。
計測したデータを良い方向でシェアしたいなら、主観はいらない。入れるならブログでやれ。
- 399 ：名無しさん＠編集中：2015/04/27(月) 16:15:53.61 ID:WxVW/waA.net
- >>397
ミュージックビデオとか動きっぱなしのものは結構あるし意味なくはない
- 400 ：名無しさん＠編集中：2015/04/27(月) 17:11:24.55 ID:zYNmxHXA.net
- 俺は別に「一般的なソース」で検証報告する義務を背負ってるわけじゃないんだがな。
「自分にとって一般的じゃないから役に立たない（個人の目的と一致してない）」と判断するのは
個人の自由だと思うけど、一例として「動きのあるソースだとこういう結果になるのか」と
捉えておけば済む程度の軽い話だと思ってるんだけど。
なぜか異様に絡んで叩きと追い出しに必死な奴もいるけど、
こんなんじゃ、今後検証報告する人がいなくなるだけじゃないの。
2chのAPI化以降、ただでさえ過疎化が進んでる印象があるのに。
- 401 ：名無しさん＠編集中：2015/04/27(月) 18:25:48.12 ID:D/4y7+jr.net
- 巣に帰れ
- 402 ：名無しさん＠編集中：2015/04/27(月) 18:51:15.23 ID:OapFOipL.net
- >>400
参考程度みたいな事言ってるけどHandBrakeのスレでは何をエンコードしてるかわからない他人に口出ししてるようにしか見えない。
少なくとも一般的なソースや多くのソースで高ビットレート時ではx265よりx264のほうが高画質だという根拠を出さないと意見出来ないと思うよ。
相手はx265で効率的に圧縮できるソースを使ってるかもしれないし。
本当にただデータを出すだけならこんなに批判されないよ。
- 403 ：名無しさん＠編集中：2015/04/27(月) 18:58:38.40 ID:0XDTONYN.net
- 私の単発煽り多すぎ～
- 404 ：名無しさん＠編集中：2015/04/27(月) 19:34:46.19 ID:5ompSnjB.net
- えぇ…単発だと駄目なの？
- 405 ：名無しさん＠編集中：2015/04/27(月) 20:35:15.32 ID:zYNmxHXA.net
- >>402
なんでこんなにしつこいんだろ・・・やりとりをちゃんと読んでないか理解してないだけじゃないの？
ttp://peace.2ch.net/test/read.cgi/avi/1424205107/171-212
最初に「ソースによるけど」と断った上で、「x265(8) placebo(20)は無駄が多い」ということを
手元のデータをサンプルにして示しただけなのに、何が問題なんだ。
placeboの無意味さだって常識みたいなもんなんだから、ソースに関わらず忠告くらいはするだろ。
当人も「x265はまだまだかもしれないし再考してみるか」で終わってるし、
あとは当人が自分のソースで試行錯誤すべき話でしょ。
そこまで気に入らないなら、文句ばっか垂れてねーで、
お前が反証データを示して俺を論破すればいいじゃん・・・。
- 406 ：名無しさん＠編集中：2015/04/27(月) 20:37:10.29 ID:zYNmxHXA.net
- >>402
ついでにお望みの、別ソースでの検証グラフ。
ソース１：ルミックスGH４(開発発表)で撮影した４K動画 【パナソニック公式】
ttps://www.youtube.com/watch?v=ptjUFr16i3M （3840x2160、5612frames）
ソース１のグラフ： ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1885.jpg
ソース２：鎌池和馬『とある魔術の禁書目録』10周年記念完全新作アニメーションPV映像!!
ttps://www.youtube.com/watch?v=Y8ZCp7FnD3w （1920x1080、2358frames）
ソース２のグラフ： ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1886.jpg
mediumしか試してないけど、>>365や>>381とあわせて見れば十分だと思う。
傾向は>>365とほぼ変わらず、medium同士だと、x265 8bppの優位性が出てくるのは、
x264 8bitでのcrf=28あたりからの中・低画質領域。
16bpp（Main10）を使うなら、その限りではない。（ただしHandbrakeはMain10未対応）
- 407 ：名無しさん＠編集中：2015/04/27(月) 20:46:42.00 ID:evdACIkZ.net
- >>366
- 408 ：名無しさん＠編集中：2015/04/28(火) 02:46:02.86 ID:9P9uyaAJ.net
- >>406
わざわざ手間かけてデータ出してくれるのは有り難いし
現段階で8bppの高ビットレート領域でのSSIMの比較に限ればx264が良い
という主張に異論がない人間も居るよ
ただ、x265のスレでx265を否定するような意見を出したら
絡んでくる人間が出てきても不思議ではないと思うけどね
皆が皆大人なわけではないし
- 409 ：名無しさん＠編集中：2015/04/28(火) 03:25:21.63 ID:ufkO4AvI.net
- >>408
わからんでもないけど、ただのデータ検証を「否定」だと捉えてつるし上げるってのは、
なんかカルト信者とか魔女狩りとかを見てる気分になるな。
- 410 ：名無しさん＠編集中：2015/04/28(火) 05:17:34.70 ID:2QMfoEJb.net
- 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし手持ちの動画をエンコードしてもそうだったからね。
あの時点では一例しかデータが無かったのにx264の方が画質が上かもしれないよと他人にアドバイスしてるのはちょっと気になった。
- 411 ：名無しさん＠編集中：2015/04/28(火) 08:24:17.79 ID:FfJhOEg2.net
- 論破とか言い出してる時点でもうダメ
お察し
- 412 ：名無しさん＠編集中：2015/04/28(火) 09:08:46.60 ID:a6s5K/IP.net
- 「高ビットレート」の基準が、動画によりけりだ、という基本を分かって無い人もいるからね
- 413 ：名無しさん＠編集中：2015/04/28(火) 12:13:21.90 ID:RV0S6Eq1.net
- >>410
> 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし
> 手持ちの動画をエンコードしてもそうだったからね。
そのデータを出してみれば済む話じゃね？
- 414 ：名無しさん＠編集中：2015/04/29(水) 06:05:51.92 ID:tAZLRrvo.net
- 比較で細かい事言うと荒れるから
このソースで映像のこの品質でここ維持したいって時はここ弄ればいい程度の当たり障りない話でいいよもう
- 415 ：名無しさん＠編集中：2015/04/29(水) 14:19:43.31 ID:s4s0dn8F.net
- 現状グレインをまともに保持出来ないってのは、誰にでも分かる話なので今後に期待
- 416 ：名無しさん＠編集中：2015/04/29(水) 14:29:58.84 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 417 ：名無しさん＠編集中：2015/04/29(水) 14:36:16.47 ID:fjbLutHk.net
- 自分でそれなりに検証してる人なら、「ビットレートを盛っても細部がいまいち」
「あまりサイズが縮まない」「むしろx264よりもサイズが膨らむことがある」といった経験はしてると思う。
それがデータとして現れたのが上のグラフというだけ。
x265はまだ開発途上なんだから、>>415の言うように今後に期待。
>>410
>海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かった
どんなデータを見たのか知らないけど、使用エンコーダとか前提条件を確認したほうがいいかもね。
使ってるのがx265じゃないってオチもありえるし。
- 418 ：名無しさん＠編集中：2015/04/29(水) 14:40:44.64 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 419 ：名無しさん＠編集中：2015/04/29(水) 16:09:49.63 ID:swtmMub8.net
- ttp://forum.doom9.org/showpost.php?p=1714340&postcount=1935
>Nonsense. Optimizing visual quality (including spatial detail) is our top priority.
- 420 ：名無しさん＠編集中：2015/04/29(水) 17:14:46.75 ID:P2Ckfyvf.net
- 何度も実験してるけど細部が全然再現出来ていない
現状低用量での費用対効果はいいのかもしれんが
高画質やソースの忠実圧縮には向いていない
- 421 ：名無しさん＠編集中：2015/04/29(水) 17:28:29.07 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 422 ：名無しさん＠編集中：2015/04/29(水) 17:46:12.39 ID:P2Ckfyvf.net
- 同じことしか言えない奴の方がよほど
- 423 ：名無しさん＠編集中：2015/05/03(日) 08:55:53.02 ID:WN+NLa4m.net
- インタレ保持エンコが出来るようになったら起こして
- 424 ：名無しさん＠編集中：2015/05/03(日) 09:39:17.60 ID:PYc3cDlH.net
- 60fpsでエンコしればいいじゃん！
- 425 ：名無しさん＠編集中：2015/05/03(日) 09:51:12.92 ID:WN+NLa4m.net
- 論外っス
- 426 ：名無しさん＠編集中：2015/05/03(日) 09:56:42.11 ID:H1UFZafZ.net
- 現状でインタレ保持がおかしくなるのってx265の問題なの？再生側の問題なの？
- 427 ：名無しさん＠編集中：2015/05/03(日) 11:34:52.51 ID:NoEMBEZE.net
- HEVCでｗｗｗｗｗｗｗｗｗｗインタレｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
- 428 ：名無しさん＠編集中：2015/05/03(日) 17:18:20.22 ID:JVsQjT/a.net
- H.265にH.264までのようなインターレースでのエンコードはないよ
この映像はインターレースだよっていうフラグがあるだけ
- 429 ：名無しさん＠編集中：2015/05/03(日) 20:08:43.53 ID:UkoWEnsd.net
- ということはそれだけ細部保持に自信があるってこと？
- 430 ：名無しさん＠編集中：2015/05/03(日) 23:02:35.93 ID:0jvZQ4DU.net
- どこを縦読み。
- 431 ：名無しさん＠編集中：2015/05/06(水) 23:03:00.88 ID:AIVTKqcp.net
- >>406
氏ね
- 432 ：名無しさん＠編集中：2015/05/19(火) 11:23:19.88 ID:bUogYhpb.net
- ver1.7が正式リリースやで
- 433 ：名無しさん＠編集中：2015/05/19(火) 12:18:27.77 ID:Px5PjOzL.net
- x265 v 1.7
ttp://forum.doom9.org/showpost.php?p=1722825&postcount=2336
>x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
- 434 ：名無しさん＠編集中：2015/05/19(火) 14:03:51.73 ID:Z8jynaNg.net
- HDRサポートしたか。
しかしHDR対応するんだったらDolby Vision見据えて12bitのサポートもしてもらいたいところ。
HDRで10bitだと、絵柄によってまたバンディング問題に悩まされるハメになるから。
- 435 ：名無しさん＠編集中：2015/05/19(火) 16:59:23.07 ID:bUogYhpb.net
- 何か勘違いしてるようだが、x264は開発当初から高ビットに対応してる
432の英文は、高ビットにもアセンブリコードを導入したという記述だよ
- 436 ：名無しさん＠編集中：2015/05/19(火) 21:04:56.42 ID:hlfCd9lL.net
- ここx265スレだよな？
- 437 ：名無しさん＠編集中：2015/05/19(火) 21:24:13.16 ID:qZnfbRjz.net
- >>435が勘違いしすぎている
- 438 ：名無しさん＠編集中：2015/05/19(火) 22:55:08.70 ID:6FNmt7E7.net
- 俺はそうは思わんが
- 439 ：名無しさん＠編集中：2015/05/19(火) 23:11:05.52 ID:q9zYwk+9.net
- >x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations,
>some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
・アセンブリコードの最適化いっぱい
・HDRコンテンツの予備的サポート（SMPTE 2084 color transfer function、--master-display, --max-cll）
・マルチライブラリサポートの改良
・その他品質関連機能
>>435は英文解釈も間違ってるし、High bit-depthとHigh Dynamic Range（HDR）を混同してるように見える。
- 440 ：名無しさん＠編集中：2015/05/19(火) 23:19:14.88 ID:q9zYwk+9.net
- エンコ比較
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
1.6+064 8bpp
encoded 2018 frames in 234.55s (8.60 fps), 5129.07 kb/s, SSIM Mean Y: 0.9926968 (21.365 dB)
1.6+064 16bpp
encoded 2018 frames in 369.20s (5.47 fps), 5229.94 kb/s, SSIM Mean Y: 0.9941848 (22.354 dB)
1.7+002 8bpp
encoded 2018 frames in 219.90s (9.18 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp
encoded 2018 frames in 333.52s (6.05 fps), 5241.07 kb/s, SSIM Mean Y: 0.9941962 (22.363 dB)
- 441 ：名無しさん＠編集中：2015/05/20(水) 00:16:08.72 ID:5FgPw/bR.net
- AVX2CPUは着々と速度向上してええな…
- 442 ：名無しさん＠編集中：2015/05/20(水) 00:25:10.34 ID:84MyFAlt.net
- 英文のカンマ表記を理解してないとか、どこ中だよ。
- 443 ：名無しさん＠編集中：2015/05/20(水) 00:33:40.06 ID:5FgPw/bR.net
- 適当にベンチ 詳細はテキストに
ソースhttps://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.6 encoded 313 frames in 14.20s (22.05 fps), 585.23 kb/s, SSIM Mean Y: 0.9248945 (11.243 dB)
1.7 encoded 313 frames in 14.10s (22.20 fps), 583.97 kb/s, SSIM Mean Y: 0.9249729 (11.248 dB)
fast
1.6 encoded 313 frames in 29.28s (10.69 fps), 578.37 kb/s, SSIM Mean Y: 0.9299534 (11.546 dB)
1.7 encoded 313 frames in 29.22s (10.71 fps), 579.22 kb/s, SSIM Mean Y: 0.9301209 (11.557 dB)
medium
1.6 encoded 313 frames in 34.65s (9.03 fps), 579.36 kb/s, SSIM Mean Y: 0.9320388 (11.677 dB)
1.7 encoded 313 frames in 34.74s (9.01 fps), 579.64 kb/s, SSIM Mean Y: 0.9321722 (11.686 dB)
slow
1.6 encoded 313 frames in 131.21s (2.39 fps), 572.10 kb/s, SSIM Mean Y: 0.9351558 (11.881 dB)
1.7 encoded 313 frames in 128.70s (2.43 fps), 572.95 kb/s, SSIM Mean Y: 0.9352168 (11.885 dB)
slower
1.6 encoded 313 frames in 264.84s (1.18 fps), 570.73 kb/s, SSIM Mean Y: 0.9364681 (11.970 dB)
1.7 encoded 313 frames in 272.77s (1.15 fps), 569.14 kb/s, SSIM Mean Y: 0.9364217 (11.967 dB)
x264 core:144 r2533 c8a773e
veryslow encoded 313 frames, 17.77 fps, 605.71 kb/s, SSIM Mean Y:0.9199693 (10.967db)
http://www.dotup.org/uploda/www.dotup.org323981.txt
- 444 ：名無しさん＠編集中：2015/05/20(水) 01:03:31.83 ID:DsEhFPgD.net
- >>440書き忘れ
ソース： 1920x1080、2018フレーム
オプション： --preset medium --tune ssim --ssim --crf 20
- 445 ：名無しさん＠編集中：2015/05/20(水) 09:36:58.50 ID:jzTm6JuK.net
- オプションを個別指定してくれたら異なるバージョン間での比較がはかどるのに
- 446 ：名無しさん＠編集中：2015/05/20(水) 09:49:00.97 ID:iy7JRJZG.net
- 個別指定ってのが何を指してるのかよくわからん。
- 447 ：名無しさん＠編集中：2015/05/20(水) 09:51:57.74 ID:jzTm6JuK.net
- --me hexとか--me uhmみたいなやつ
- 448 ：名無しさん＠編集中：2015/05/20(水) 09:56:37.16 ID:iy7JRJZG.net
- 自分で好きなように指定して比較結果を書き込めば済む話だと思うが・・・
- 449 ：名無しさん＠編集中：2015/05/20(水) 10:31:29.02 ID:mcJR6Gtp.net
- 同じプリセットでも、新しいオプションが追加されたり、パラメータが変更になったりはするけれど
同じプリセットでの比較ってことで十分な気が
- 450 ：名無しさん＠編集中：2015/05/20(水) 10:45:31.71 ID:aOeCRpzC.net
- AVX2の有無でどれ程変わるのん？
- 451 ：名無しさん＠編集中：2015/05/20(水) 10:56:07.53 ID:iy7JRJZG.net
- >>450
>>440 >>444と同ソースで--asmをつけた結果。
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 269.97s (7.47 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 244.33s (8.26 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 395.72s (5.10 fps), 5241.37 kb/s, SSIM Mean Y: 0.9941964 (22.363 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 345.11s (5.85 fps), 5241.50 kb/s, SSIM Mean Y: 0.9941963 (22.363 dB)
- 452 ：名無しさん＠編集中：2015/05/20(水) 11:14:09.91 ID:aOeCRpzC.net
- 1割以上の効果があるのか～
ありがとう
- 453 ：名無しさん＠編集中：2015/05/20(水) 12:35:24.34 ID:Llc+DgAh.net
- x264だとあんだけAVX2使いまくっても
--asm avxと--asm avx2の差が2～3％しかなかったけど
x265だとAVX2がAVX2かなり効くんだな
- 454 ：名無しさん＠編集中：2015/05/20(水) 16:49:52.78 ID:HZ4G4I1G.net
- 高速化と高画質化が着々と進行してていい感じ
- 455 ：名無しさん＠編集中：2015/06/10(水) 21:18:02.20 ID:GuuQXTMl.net
- 10bitのexeでも8bit使えるようになったって見たんだけど--output-depth指定しても
x265 [warning]: falling back to default bit-depth
と表示されてエンコ結果も10bitになってるみたいだけどどうすればできる？
rigaya氏ビルド使ってる
- 456 ：名無しさん＠編集中：2015/06/11(木) 08:51:36.31 ID:vrkDIN1Y.net
- できますん
- 457 ：名無しさん＠編集中：2015/06/11(木) 09:29:13.15 ID:3al9+NHx.net
- できなくないですん
- 458 ：名無しさん＠編集中：2015/06/14(日) 02:10:18.80 ID:f36+6P8e.net
- 1.7+166着てるのか
- 459 ：名無しさん＠編集中：2015/06/16(火) 21:50:19.22 ID:v2G8PG9Y.net
- 一時期 --tune cbr ってのがあったみたいだけど、いつのまにか無くなったの？
- 460 ：名無しさん＠編集中：2015/06/17(水) 02:19:02.50 ID:Mr2FqQCj.net
- かなり実用的になってきてると思うんだけどなんでここまで過疎なんだ・・・
- 461 ：名無しさん＠編集中：2015/06/17(水) 02:27:39.59 ID:8xiHEtt7.net
- まだ道半ばも来ていない。
- 462 ：名無しさん＠編集中：2015/06/17(水) 03:07:35.82 ID:Mr2FqQCj.net
- まぁx264に比べちゃうとね・・・
- 463 ：名無しさん＠編集中：2015/06/17(水) 03:12:47.37 ID:ePVFJmB4.net
- デコーダが整備されてない
日本語のオプション解説サイトがない
再現性に問題有と散々言われている
流行るわけがない
- 464 ：名無しさん＠編集中：2015/06/17(水) 08:10:28.32 ID:Z8Vl6PNb.net
- 間違いなく置き換わるし
- 465 ：名無しさん＠編集中：2015/06/17(水) 11:34:03.77 ID:RYyTK5fP.net
- 今ビルドすると途中で終了するバイナリができちゃうね
- 466 ：名無しさん＠編集中：2015/06/17(水) 23:25:47.73 ID:Mr2FqQCj.net
- 俺はもうガンガン活用してるけどな、通勤中とかスマホで見るときとか
容量減らせるから途切れにくいしパケ代浮くしでかなりいいと思うけどな
最近のスマホはHWデコーダー載ってるわけだしな
- 467 ：名無しさん＠編集中：2015/06/18(木) 01:48:33.03 ID:izQm9FfU.net
- 熱でバッテリー爆発してもよいのなら
- 468 ：名無しさん＠編集中：2015/06/18(木) 02:40:11.51 ID:BnkVaq++.net
- 801だから無縁なんだよなぁ・・・
- 469 ：名無しさん＠編集中：2015/06/18(木) 10:28:07.57 ID:t/GL2YUT.net
- やだホモよ、ホモがいるわ
- 470 ：名無しさん＠編集中：2015/06/18(木) 13:10:13.95 ID:IPboZsre.net
- やおいとかそら無縁だろうなぁ・・・
- 471 ：名無しさん＠編集中：2015/06/18(木) 13:12:38.15 ID:t9a4HHhd.net
- x801って書くと何か卑猥・・・
- 472 ：名無しさん＠編集中：2015/06/24(水) 09:27:57.10 ID:DIAOr5JF.net
- 今の所、x265って暗部でのバンディングやブロックノイズの発生がCQの数値低めに設定しても防げなくない？
x264ならCQ21くらいで暗部もそこそこ満足できる画質になるんだけど
x265だとCQ21じゃあ全然解消されない
黒色の再現度が高いモニタで見るとそこまで気にならないんだけど、白っぽく映る安物液晶だと暗部が崩壊してるのがすぐ分かる
数ヶ月ほど、家族で自分しか見ない(DLNA使わない)動画はH.265にエンコしてたんだけど、今はH.264に戻しちゃった
- 473 ：名無しさん＠編集中：2015/06/24(水) 12:51:40.71 ID:M5sreByR.net
- >>472
x265は、実用するには早すぎる。
IntelがSkylakeにHEVCエンコーダーを積む予定だから、x265が本気出すのもその後あたりかと。
オープンソースはライバルがいないとダレやすいから。
- 474 ：名無しさん＠編集中：2015/06/24(水) 13:52:50.47 ID:DIAOr5JF.net
- >>473
なるほどなあ
x265と264比較してるような個人サイト、
大抵アニメの見栄えの良い明るい画面使って比較してるから
凄そうに見えたのに
実際にエンコやって見ると実写の濃い色の服の質感とか完全に殺されたりして
散々でしたわ
- 475 ：名無しさん＠編集中：2015/06/24(水) 14:21:12.79 ID:sKT7VGD8.net
- 現状の結論
264も265も再現性をより高めるにはビットレートを振るしかない
なので発展途上の265を選択するメリットはない
- 476 ：名無しさん＠編集中：2015/06/24(水) 15:11:25.80 ID:5qLer+EY.net
- x264だとqcompを上げるのが一つの処方箋だった気がする。
ほかに暗部にビットを回すor削られないようにするオプションってんあんかあったっけ？
- 477 ：名無しさん＠編集中：2015/06/24(水) 15:16:11.35 ID:5qLer+EY.net
- AQを思いっきり下げるとか。
x265自体、画質の向上がまだ最優先課題ってレベルだから"高画質"を求めるのは時期早々かもね。
- 478 ：名無しさん＠編集中：2015/06/24(水) 15:21:53.52 ID:60xXmepu.net
- 暗部を気にするならMain10でエンコすればいいんじゃないの？
Main10でもアカンの？
- 479 ：名無しさん＠編集中：2015/06/24(水) 15:37:24.14 ID:jNQuIAS+.net
- x264だって、暗部の問題が解決したのは開発後期にAQ関連の仕組みが導入されてからでしょ
x265はまだ全機能実装さえ済んでない状態
AQなどの派生技術を導入する時期じゃない
- 480 ：名無しさん＠編集中：2015/06/24(水) 18:57:14.27 ID:Rs4u+3+Q.net
- 海外で落としたエロがHEVCだったのでMPCに突っ込んだら観れなかった
VLCは観れたけどHEVCって言ってもいろいろあるのね
- 481 ：名無しさん＠編集中：2015/06/24(水) 19:12:25.43 ID:60xXmepu.net
- コンテナとかコーデックとかちゃんと理解したほうがいいと思うよ・・・
- 482 ：名無しさん＠編集中：2015/06/24(水) 21:37:00.42 ID:DIAOr5JF.net
- >>478
- 483 ：名無しさん＠編集中：2015/06/24(水) 21:38:02.19 ID:DIAOr5JF.net
- >>478
途中で書き込んでしまった
10bitでもダメでちたわ
- 484 ：名無しさん＠編集中：2015/06/26(金) 12:13:57.59 ID:EMEyWpzc.net
- qcomp オプションはどうでした？
80ぐらいで違いを確かめてもらいたいな。
- 485 ：名無しさん＠編集中：2015/06/26(金) 14:39:28.80 ID:21J4TSkU.net
- x264で言うところのAQに類する仕組みがまだx265には入ってない
だから当然、暗部や細部はx264より苦手
- 486 ：名無しさん＠編集中：2015/06/26(金) 14:57:05.22 ID:3w9RCHVj.net
- 今後の開発スケジュールとか決まってないのかな？
- 487 ：名無しさん＠編集中：2015/06/26(金) 15:17:26.28 ID:EMEyWpzc.net
- >>485
AQ自体は入ってるよ
内部的な動作は把握してないけどオプションはある。
画質自体はまだまだってこのスレに張られてた（と思うけど。
- 488 ：名無しさん＠編集中：2015/06/26(金) 16:45:52.58 ID:WapMSTrr.net
- 赤色はマシになったの
- 489 ：名無しさん＠編集中：2015/06/26(金) 18:25:57.01 ID:LIoEONiV.net
- なんだよ
x265ってまだ時期早漏かよ
- 490 ：名無しさん＠編集中：2015/06/26(金) 19:01:06.27 ID:vnoa8Ytk.net
- >>489
早漏はおまえだ。
- 491 ：名無しさん＠編集中：2015/06/27(土) 01:19:30.87 ID:oS5xVwj1.net
- おお…
- 492 ：名無しさん＠編集中：2015/06/27(土) 08:31:16.67 ID:Wz4orqrw.net
- 8it出力版と10bit出力版を合体させたやつが、batファイル一発で生成される！
これは便利！
ただ、msys版はshファイルに誤記があって途中で止まるｗ
VC12版は問題なくビルド出来た
- 493 ：名無しさん＠編集中：2015/06/27(土) 13:28:53.83 ID:l6Oe5HEN.net
- Win7環境にMSYS環境を構築し、Cmakeとhgを導入して以下のサイトを参考にx265のコンパイルを試みてみました。
http://xanadu62.blogspot.jp/2013/10/ffmpeg.html
hg clone https://bitbucket.org/multicoreware/x265
cd x265/build/msys
cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
すると以下の様なエラーが返されコンパイルに失敗しました。何が原因でコンパイルに失敗したのでしょうか？
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_CXX_COMPILER:
x86_64-w64-mingw32-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
- 494 ：名無しさん＠編集中：2015/06/27(土) 14:39:38.88 ID:UsG4h7yl.net
- PATH が通ってない
- 495 ：492：2015/06/27(土) 15:41:02.64 ID:l6Oe5HEN.net
- >>494
Cmakeを置いてある場所
D:\MSYS\cmake\bin
を環境変数のPATHに登録してみましたがやはりエラー内容は変わりませんでした。
うーん、何が原因でしょうか・・・
半年くらい前にx265をコンパイルしたときは特に問題無く通ったはずなんですが・・・
- 496 ：名無しさん＠編集中：2015/06/27(土) 15:46:02.47 ID:Wz4orqrw.net
- hg clone https://bitbucket.org/multicoreware/x265
cd x265/build/msys
ここにあるmultilib.shの中に
-DEXTRA_LIB=x265_main10.a
という記述があるけど、これは間違いじゃない？
- 497 ：名無しさん＠編集中：2015/06/27(土) 17:06:47.93 ID:sEawlLsz.net
- >>495
cd x265/build/msys
./make-Makefiles.sh
make
これじゃダメ？
- 498 ：492：2015/06/27(土) 21:37:46.86 ID:l6Oe5HEN.net
- >>496
すみません、込み入ったことは分かりません(´；ω；｀)
>>497
やってみましたがダメでした(´･ω･｀)
$ ./make-Makefiles.sh
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_CXX_COMPILER:
x86_64-w64-mingw32-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
- 499 ： ◆tsGpSwX8mo ：2015/06/27(土) 22:03:18.49 ID:WqnHBzoK.net
- >>498
まずはPATH(gcc)の確認
- 500 ：名無しさん＠編集中：2015/06/27(土) 22:36:46.62 ID:07ob81ds.net
- >>493
はて、斜め読みだから的はずれなこと書いてたらごめんなさい。
>> cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
>> -DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
>>CMake Error at CMakeLists.txt:19 (project):
>>The CMAKE_C_COMPILER:
>>x86_64-w64-mingw32-gcc
>>is not a full path and was not found in the PATH.
PERFIXでi686-w64-mingw32 (32bit用だっけ？)って書いてるのに
エラーメッセージで
x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ここらへんじゃない？
- 501 ：名無しさん＠編集中：2015/06/27(土) 22:50:23.25 ID:07ob81ds.net
- ごめん、ものすごく的はずれなこと書いてたらしい。
忘れて。
- 502 ：492：2015/06/28(日) 04:27:18.91 ID:kJVbfWHG.net
- >>499
生きます(´；ω；｀)！
> まずはPATH(gcc)の確認
>>500
> x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ハッ！今気付きました・・・。MSYS環境でコンパイルするときは単純にコマンドプロンプトを立ち上げるのでは無く
msys.batを実行してシェルを起動しなければならないということに・・・。というわけでmsys.batを実行してシェルを立ち上げ
そこであらためてx265のコンパイルを試みてみました。
結果は・・・また違ったエラーが返されました(´･ω･｀)
$ cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ../../source/
-- cmake version 3.2.1
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe -- broken
CMake Error at D:/MSYS/cmake/share/cmake-3.2/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler "D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe" is not able
to compile a simple test program.
It fails with the following output:
Change Dir: D:/MSYS/x265/build/msys/CMakeFiles/CMakeTmp
(続く）
- 503 ：492：2015/06/28(日) 04:28:36.90 ID:kJVbfWHG.net
- (続き)
Run Build Command:"C:/cygwin/bin/make.exe"
"cmTryCompileExec2492638483/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec2492638483.dir/build.make
CMakeFiles/cmTryCompileExec2492638483.dir/build
make[1]: Entering directory
'/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp'
/D/MSYS/cmake/bin/cmake.exe -E cmake_progress_report
/D/MSYS/x265/build/msys/CMakeFiles/CMakeTmp/CMakeFiles 1
make[1]: /D/MSYS/cmake/bin/cmake.exe: Command not found
CMakeFiles/cmTryCompileExec2492638483.dir/build.make:57: recipe for target
'CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj' failed
make[1]: ***
[CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj] Error 127
make[1]: Leaving directory
'/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp'
Makefile:117: recipe for target 'cmTryCompileExec2492638483/fast' failed
make: *** [cmTryCompileExec2492638483/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:19 (project)
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
コンパイラーが壊れてるってどういうことでしょうか？MSYSを再インストールしろってことでしょうか？
- 504 ： ◆tsGpSwX8mo ：2015/06/28(日) 06:17:57.29 ID:7ma/nKKp.net
- >>503
CygwinをPATHから外すとどうなる(cygwinディレクトリをリネームでもおｋ)？
- 505 ：名無しさん＠編集中：2015/06/28(日) 07:25:10.29 ID:hIou2o11.net
- なんで コンパイラのエラーも読めないヤツが
コンパイルしようとしてんの？
- 506 ：名無しさん＠編集中：2015/06/28(日) 08:08:48.17 ID:kZOLiJyl.net
- というか、普通に環境づくりが失敗してるだけでしょ
全自動で環境作ってくれるスクリプトとか配布してるところあるんだから
そういうの使って１発全自動で環境つくれよ
それで解決だよ
- 507 ：名無しさん＠編集中：2015/06/28(日) 09:59:08.61 ID:fYmTl1Mq.net
- そもそもmake-Makefiles.shがあるのに何でcmakeのコマンドを直接叩いてるんだろうという疑問が・・・
cmake -G "MSYS Makefiles" ../../source
としてMSYS Makefilesを明示しないとcmakeが勝手にコンパイラを選択したはず
いちいち面倒くさいことせず、MSVCでやる方法が一番簡単だと思うな
- 508 ：名無しさん＠編集中：2015/07/04(土) 00:45:41.40 ID:YGz1q9Lu.net
- 12bit意外と早く来そうだな
- 509 ：名無しさん＠編集中：2015/07/04(土) 06:45:29.92 ID:AzJNmnE3.net
- Multibitええね
何がいいって、ビルドするときに1コマンドでいいのがｗ
exeはちょっとでかくなるけど気にしない
- 510 ：名無しさん＠編集中：2015/07/04(土) 11:26:38.48 ID:LaJ5nNJQ.net
- そんなに使い分けてるの？
- 511 ：名無しさん＠編集中：2015/07/04(土) 12:51:35.76 ID:AzJNmnE3.net
- 使い分けてない
いつも使ってるのは10bit
ただ、最近導入されたmultilib.batがクソ楽ちんなんで絶賛してるだけ
- 512 ：名無しさん＠編集中：2015/07/14(火) 18:47:52.37 ID:idZm8Phr.net
- XP対応でビルドされたやつは配布されていないの？
- 513 ：名無しさん＠編集中：2015/07/14(火) 19:36:02.32 ID:idZm8Phr.net
- とりあえず探してみた結果
XPで作動するやつ
作動可能
x265_0.7+289_x86.exe
x265_0.8+3_x86.exe
作動可能だが、やや作動が怪しい
x265_0.8+61_x86.exe
x265_0.8+149_x86.exe
作動不可
x265_0.8+190_x86.exe
作動不可の原因はVista以降に使われている関数、
SleepConditionVariableCSが原因です
- 514 ：名無しさん＠編集中：2015/07/14(火) 19:39:39.31 ID:idZm8Phr.net
- こののやつのバイナリは最新版もXPで作動するね
http://x265.ru/en/builds
- 515 ：名無しさん＠編集中：2015/07/14(火) 19:57:17.95 ID:idZm8Phr.net
- >>513のは
ttp://rigaya34589.blog135.fc2.com/
ttps://www.dropbox.com/sh/lolsllkm6zxvsn2/AADSh5bFuZnN1Nq78vmDhu1ga/old?dl=0
- 516 ：名無しさん＠編集中：2015/07/14(火) 21:43:14.97 ID:0sHf5gOl.net
- 自分でどうこう出来ないならXP使うなよｗｗ
- 517 ：名無しさん＠編集中：2015/07/15(水) 14:46:48.25 ID:Dln1hXUc.net
- 自分でXP対応でビルドすればいいと言ってみる
- 518 ：名無しさん＠編集中：2015/07/15(水) 15:42:54.53 ID:ENlb271m.net
- XPはマルチコア時の性能が低い
貧乏人ならLinux使った方がマシ
- 519 ：名無しさん＠編集中：2015/07/15(水) 18:18:06.19 ID:DXiTqnAr.net
- XP使ってる貧乏人なんだからシングルコアの可能性もあるだろ
- 520 ：名無しさん＠編集中：2015/07/15(水) 19:54:44.34 ID:F6Dht5ea.net
- いやさすがにそれは・・・
- 521 ：名無しさん＠編集中：2015/07/16(木) 00:14:28.25 ID:ZRyn4IRA.net
- intel HTT(Hyper Threading Technology)じゃ駄目か？
- 522 ：名無しさん＠編集中：2015/07/16(木) 08:16:36.84 ID:f1hZBsh9.net
- 今1.7だよね
何故0.8とかなの？
- 523 ：名無しさん＠編集中：2015/07/18(土) 14:55:18.41 ID:68ZYLSDZ.net
- 情弱からの改竄職人 とーる君
メールアドレス：sjfosfoasfo@yahoo.co.jp
携帯番号：08066192913
37o0d5M
- 524 ：08066192913：2015/07/18(土) 19:12:25.80 ID:bBMzk35F.net
- 情弱からの改竄職人 とーる君
- 525 ：08066192913：2015/07/18(土) 19:13:04.85 ID:bBMzk35F.net
- メールアドレス：sjfosfoasfo@yahoo.co.jp
- 526 ：08066192913：2015/07/18(土) 20:16:30.92 ID:IE1b+ET3.net
- あ
- 527 ：08066192913：2015/07/18(土) 20:17:13.58 ID:SoskPJ+N.net
- い
- 528 ：08066192913：2015/07/19(日) 13:05:04.98 ID:RJp4FHa5.net
- 情弱からの改竄職人 とーる君
88XzdAMl
- 529 ：08066192913：2015/07/19(日) 18:12:32.22 ID:EX1fxnmk.net
- 02T9Qhq0
- 530 ：08066192913：2015/07/19(日) 18:12:54.11 ID:EX1fxnmk.net
- 34KV3VQ8
- 531 ：名無しさん＠編集中：2015/07/19(日) 21:40:33.40 ID:1gnsFKQG.net
- avi：映像制作［レス削除］
http://qb5.2ch.net/test/read.cgi/saku/1310326982/43-
- 532 ：08066192913：2015/07/20(月) 03:36:57.20 ID:NeURmLNR.net
- bt742CY7
- 533 ：08066192913：2015/07/20(月) 10:27:00.48 ID:d4VaFPJ9.net
- 1zzlNflJ
- 534 ：08066192913：2015/07/20(月) 10:29:46.33 ID:vWDQMbiN.net
- 情弱からの改竄職人 とーる君
1zzlNflJ
- 535 ：名無しさん＠編集中：2015/07/24(金) 02:22:33.01 ID:qIPjjeFO.net
- Windows2000でH.265をエンコードしてみる
http://www.nico video.jp/watch/sm26774171
- 536 ：名無しさん＠編集中：2015/07/26(日) 17:42:48.79 ID:lSABQG3J.net
- 12bitのFourCCってないの？
- 537 ：名無しさん＠編集中：2015/07/26(日) 19:10:11.69 ID:bAcAj12A.net
- そんなAVIの遺物をいつまでも引きずるな
- 538 ：名無しさん＠編集中：2015/07/27(月) 14:01:50.09 ID:WXFY+U6V.net
- 12bitエンコ出来るようになったのはいいけど、デコーダーがまだ無いな
- 539 ：名無しさん＠編集中：2015/07/27(月) 14:17:11.84 ID:zmqr9Jt6.net
- えっ
- 540 ：名無しさん＠編集中：2015/07/27(月) 15:06:33.32 ID:RYhN1uKU.net
- >>539
12bitをちゃんとデコードできるデコーダーがあるなら挙げてみ？
- 541 ：名無しさん＠編集中：2015/07/27(月) 18:17:58.85 ID:MoB8fNT9.net
- デコーダのないエンコーダって意味あるんですかねそれ
- 542 ：名無しさん＠編集中：2015/07/27(月) 18:22:12.79 ID:RYhN1uKU.net
- experimentalな段階で意味つってもな。
x265 [warning]: Main12 is HIGHLY experimental, do not use!
- 543 ：名無しさん＠編集中：2015/07/27(月) 18:25:34.41 ID:AhU7j0d9.net
- 12bitって画質とサイズの費用対効果で言うとどうなん？
10bitだと8bitより効率いいみたいだけど。
- 544 ：名無しさん＠編集中：2015/07/27(月) 18:44:46.44 ID:XMdjkvfw.net
- 先にインタレサポートして欲しいよ
- 545 ：名無しさん＠編集中：2015/07/27(月) 18:46:31.30 ID:X6RbocHm.net
- 12bitはBT.2020環境下でバンディングノイズを出さないようにすることを前提としたものであって、現時点で一般ユーザーが使わなければならないようなものじゃない。
- 546 ：名無しさん＠編集中：2015/07/27(月) 19:20:47.97 ID:4GogWDeS.net
- 自分用に使うに決まってんじゃん
- 547 ：名無しさん＠編集中：2015/07/27(月) 19:50:36.98 ID:X6RbocHm.net
- 豚に真珠
- 548 ：名無しさん＠編集中：2015/07/27(月) 20:40:45.21 ID:RYhN1uKU.net
- >>543
デコードできないからとりあえずcrf20でSSIMだけでも調べてみようと思ったらこんな結果になった。
experimentalすぎて何もできない段階かな。
x265 [info]: HEVC encoder version 1.7+373-db59e6d9b85b
--tune ssim --ssim --crf 20
8bit
encoded 2018 frames in 278.43s (7.25 fps), 4988.06 kb/s, SSIM Mean Y: 0.9928450 (21.454 dB)
10bit
encoded 2018 frames in 368.82s (5.47 fps), 4875.11 kb/s, SSIM Mean Y: 0.9941356 (22.318 dB)
12bit
encoded 2018 frames in 676.06s (2.98 fps), 13733.34 kb/s, SSIM Mean Y: 0.6725987 ( 4.849 dB)
- 549 ：名無しさん＠編集中：2015/07/27(月) 20:57:29.12 ID:Ep+Jd60L.net
- そのようで・・
- 550 ：名無しさん＠編集中：2015/07/27(月) 20:59:25.49 ID:AhU7j0d9.net
- >>548
おお、調べてくれてありがと
- 551 ：名無しさん＠編集中：2015/07/27(月) 21:37:26.63 ID:zmqr9Jt6.net
- >>540
ちゃんとって今のデコーダは完全ではないってこと？この動画は表示できてるけど
ttp://forum.doom9.org/showthread.php?p=1731344#post1731344
LSMASHVideoSource(stacked = true, format = "YUV420P16")
Dither_convert_yuv_to_rgb(matrix = "709", lsb_in = true, output = "rgb24", ampn = 0)
8bit
http://i.imgur.com/eung4u9.png
10bit
http://i.imgur.com/0Ucr1NP.png
12bit
http://i.imgur.com/EGc887U.png
- 552 ：名無しさん＠編集中：2015/07/27(月) 23:31:34.84 ID:RYhN1uKU.net
- >>551
それはちゃんと見れるね・・・。デコードできないというのはどうもこちらの勘違いだった模様。まじごめん。
rigayaさんのとこのx265_1.7+373_x64を使って12bitエンコして
MPC-HC1.7.9(内蔵LAV0.65)やL-SMASH Worksでデコードすると、
ttp://www.dotup.org/uploda/www.dotup.org436826.jpg.html
のようにおかしくなるんで、12bitはまだ正常にデコードできないものだと思い込んでしまった。
>>548もそのバイナリを使った結果なので、参考にしないほうがいい。
試しに>>551のリンク先にあるx265_1.7+371-24c1ee516d13.GCC492の
Win64\x265_ml.exeで12bitエンコしてみたら普通に見れた。
つうことで、12bitも普通にデコードできるってことでいいのかな・・・。
- 553 ：名無しさん＠編集中：2015/07/28(火) 00:22:42.61 ID:xs+H8iag.net
- 許さん。二度と来るな。消えろ。氏ね。
- 554 ：名無しさん＠編集中：2015/07/28(火) 16:25:43.22 ID:W4i+wzm1.net
- ファーｗ
- 555 ：名無しさん＠編集中：2015/07/30(木) 12:48:57.21 ID:4Dgns5PX.net
- 12bit出力試してみたけど
TSとかのYV12ソースをDitherで１6bit主力i420での12bitはうまくできたけど
ゲームとか録画したRGBソースを
YUV24化してi444の12bit出力がなんか緑がかった画面になってうまくいかんかった。
Outputdepthを10bitはうまくできたんだけども。
ようわかりません。
- 556 ：名無しさん＠編集中：2015/07/30(木) 12:51:49.53 ID:4Dgns5PX.net
- YUV24じゃなｋったYV24だった。すみません。
Dither_convert_rgb_to_yuv(matrix="601",tv_range=true,lsb=true,mode=-1,output="YV24")
- 557 ：名無しさん＠編集中：2015/07/30(木) 15:57:29.21 ID:RtKKrWDv.net
- >>555-556
1.7+380で12bit i444出力して試してみた。
1. MPC-BE1.4.5でMPC Video Decoder＋EVRの場合は、RGB32出力されて正常に再生される。
2. MPC-HC1.7.9（LAV Filters 0.65）＋EVRの場合は、RGB32出力されて緑になってしまう。
3. MPC-HC1.7.9（LAV Filters 0.65）＋madVRの場合は、Y416出力されて正常に再生される。
そっちの再生環境が書かれてないので2.で再生したのかどうかは知らんけど、
もし2..なのだとしたらLAV Video Decoderの12bitYUV4:4:4→RGB32変換がおかしいんだと思う。
- 558 ：名無しさん＠編集中：2015/07/30(木) 16:30:29.67 ID:4Dgns5PX.net
- >>557
LAV Filters 0.65使ってます。
まさに２の状態でした。
検証いただきありがとうございました。
- 559 ：名無しさん＠編集中：2015/09/02(水) 10:27:01.07 ID:17+7uTqX.net
- tst
- 560 ：名無しさん＠編集中：2015/09/08(火) 19:34:59.32 ID:6BnL2XmX.net
- なんか、今ビルドしたexe使うと、マルチスレッドが全く効いてないようなんだが、
変な変更入った？
- 561 ：名無しさん＠編集中：2015/09/08(火) 20:14:56.68 ID:IIsd4ht2.net
- 自前でビルドするなら、コミットログ位自分で確認しろよ。
https://bitbucket.org/multicoreware/x265/commits/e1adac00dce8e5641cbe9aec3d50a72261c308d9
- 562 ：名無しさん＠編集中：2015/09/08(火) 20:21:29.94 ID:fH222Kze.net
- ﾏﾝﾄﾞｸｾ('A`)･･･
- 563 ：名無しさん＠編集中：2015/09/08(火) 22:17:30.18 ID:6BnL2XmX.net
- >>561
いや、それが機能してないんじゃないか？という指摘なんだが、
ただ読んでるだけのお前より、実際に使ってる人の実体験のほうが重要だろ
- 564 ：名無しさん＠編集中：2015/09/09(水) 00:25:49.62 ID:ucrN+mFp.net
- 何の具体的な情報も出さずに、実体験の方が重要だろって言っちゃうって、すごいな。
俺はUFOを見たんだ。実際にこの目で見たんだ。
って言われてもなぁ・・・。
- 565 ：名無しさん＠編集中：2015/09/09(水) 00:54:51.47 ID:lhJuTuku.net
- どうせおま環だろ
- 566 ：名無しさん＠編集中：2015/09/09(水) 13:49:23.15 ID:16H1IFVw.net
- >>563
実体験がなんだ？
スクロールすら出来ない奴がブツブツほざくなよ、雑魚が。
ビルドどころか、PC使うの辞めたほうが良いレベル、
それが世の為人の為。
- 567 ：名無しさん＠編集中：2015/09/09(水) 14:06:01.69 ID:16H1IFVw.net
- ちなみに、ID:IIsd4htは俺だ。
イライラしてて、書き方が乱暴になった。
>>560に対して、>>561で対象の変更と、
そこですでに開発者にバグ報告されて、
開発者も内容理解して、翌日fixすると
やりとりまでされた情報出したにも関わらず、
なんで>>563で、俺が文句言われなきゃならん訳？
お前が質問だけして、出された情報を全く理解出来ない奴って事だけは分かった。
人の話聞く気が無いなら、質問なんてするなよ、低能。
- 568 ：名無しさん＠編集中：2015/09/09(水) 14:07:33.68 ID:16H1IFVw.net
- ID:IIsd4ht2
IDまで書きミスったじゃねーかよ、ボケ。
- 569 ：名無しさん＠編集中：2015/09/09(水) 16:55:08.06 ID:rTRAxpt2.net
- 以上、低脳劇場でした。(完)
- 570 ：名無しさん＠編集中：2015/09/09(水) 17:03:55.87 ID:7U0Uqkc8.net
- 1.7+478-365f7ed4d896 これで Fix されたね。
- 571 ：名無しさん＠編集中：2015/09/10(木) 06:24:59.07 ID:IzPmuN2L.net
- >>566>>567
実体験は超重要
- 572 ：名無しさん＠編集中：2015/09/10(木) 08:17:05.65 ID:1Cb4E+Y/.net
- 質がある程度保証されるフォーラムとかならともかく、
ほとんどが「こちらの勘違いでした」で終わるような掲示板で語られる実体験は微妙じゃないかい？
たまに当たりがあるのは否定しないけれど
- 573 ：名無しさん＠編集中：2015/09/10(木) 08:35:43.13 ID:YOKNJnul.net
- 結局誰も試してないっぽいしおま環かも実際にそうなのかもわからんわｗ
- 574 ：名無しさん＠編集中：2015/09/10(木) 08:40:39.32 ID:WsVHyNvR.net
- ちょっと何言ってるか分かんない
- 575 ：名無しさん＠編集中：2015/09/10(木) 22:32:37.33 ID:KJ0kRu7c.net
- なんか良さげな更新があってスレ進んだのかなと思って見に来たのに
なんじゃこりゃ
- 576 ：名無しさん＠編集中：2015/09/12(土) 00:18:42.15 ID:XaHNf2Ma.net
- prepareになってから一か月経ってんのか…
- 577 ：名無しさん＠編集中：2015/09/17(木) 07:35:56.04 ID:Vin772sA.net
- 突然x265の開発が停滞しだしたけど、何かあったの？
- 578 ：名無しさん＠編集中：2015/10/08(木) 21:13:37.20 ID:6W1l538e.net
- >>x265 version 1.8 has been released.
>>This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.
- 579 ：名無しさん＠編集中：2015/10/08(木) 22:51:27.95 ID:uYI8xAvc.net
- するの？それともされたの？
- 580 ：名無しさん＠編集中：2015/10/09(金) 00:50:54.95 ID:exeJoz3M.net
- >>579
has been
- 581 ：名無しさん＠編集中：2015/10/09(金) 01:18:40.45 ID:u8RFIes1.net
- 適当にベンチ 詳細はテキストに
ソース https://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.7 encoded 313 frames in 14.20s (22.05 fps), 600.65 kb/s, SSIM Mean Y: 0.9259115 (11.302 dB)
1.8 encoded 313 frames in 13.99s (22.37 fps), 598.68 kb/s, SSIM Mean Y: 0.9264626 (11.335dB)
fast
1.7 encoded 313 frames in 29.44s (10.63 fps), 593.51 kb/s, SSIM Mean Y: 0.9310887 (11.617 dB)
1.8 encoded 313 frames in 23.90s (13.10 fps), 591.59 kb/s, SSIM Mean Y: 0.9307948 (11.599dB)
medium
1.7 encoded 313 frames in 34.93s (8.96 fps), 592.51 kb/s, SSIM Mean Y: 0.9329568 (11.736 dB)
1.8 encoded 313 frames in 30.54s (10.25 fps), 585.75 kb/s, SSIM Mean Y: 0.9326935 (11.719dB)
slow
1.7 encoded 313 frames in 129.29s (2.42 fps), 587.25 kb/s, SSIM Mean Y: 0.9359766 (11.937 dB)
1.8 encoded 313 frames in 115.54s (2.71 fps), 584.54 kb/s, SSIM Mean Y: 0.9358390 (11.927dB)
slower
1.7 encoded 313 frames in 276.12s (1.13 fps), 584.50 kb/s, SSIM Mean Y: 0.9372324 (12.023 dB)
1.8 encoded 313 frames in 222.83s (1.40 fps), 582.14 kb/s, SSIM Mean Y: 0.9366779 (11.984dB)
x264 core:146 r2555 0c21480
veryslow
encoded 313 frames, 17.80 fps, 622.27 kb/s, SSIM Mean Y:0.9211507 (11.032db)
http://www.dotup.org/uploda/www.dotup.org551550.txt
- 582 ：名無しさん＠編集中：2015/10/09(金) 07:27:39.06 ID:Q96PdMlI.net
- あれま1.8ってあったのね
- 583 ：名無しさん＠編集中：2015/10/09(金) 09:10:50.86 ID:GV+ZIqNz.net
- >>580,580
ｔｈｘ！
- 584 ：名無しさん＠編集中：2015/10/09(金) 10:18:28.60 ID:FcOiDfHW.net
- >>581
CPU何使ってるの？
- 585 ：名無しさん＠編集中：2015/10/09(金) 23:37:12.17 ID:u8RFIes1.net
- AMDのFX-8300定格です
- 586 ：名無しさん＠編集中：2015/10/10(土) 00:08:51.18 ID:TUv/1SN/.net
- さすがエンコ向けなだけあるな
- 587 ：名無しさん＠編集中：2015/10/11(日) 22:52:22.59 ID:sQ9XJT0L.net
- AVX2無しでも結構変わるのかなこりゃ
fastとslowerの伸び率凄いな
- 588 ：名無しさん＠編集中：2015/10/11(日) 23:35:19.31 ID:1iAxDOqX.net
- rigayaさんは今年も年末辺りにx265の速度比較してくれるのかな
- 589 ：名無しさん＠編集中：2015/10/12(月) 00:46:55.70 ID:WVekvBHO.net
- 自前ビルドなんでVerがちょっと新しいけど>>581とHEVCだけ同じ事やってみた
x265 [info]: HEVC encoder version 1.8+30-030744551098
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
faster
encoded 313 frames in 4.68s (66.84 fps), 598.41 kb/s, Avg QP:31.37, SSIM Mean Y: 0.9264005 (11.331 dB)
fast
encoded 313 frames in 6.63s (47.25 fps), 588.29 kb/s, Avg QP:35.56, SSIM Mean Y: 0.9305941 (11.586 dB)
medium
encoded 313 frames in 8.02s (39.01 fps), 585.12 kb/s, Avg QP:35.54, SSIM Mean Y: 0.9326401 (11.716 dB)
slow
encoded 313 frames in 28.55s (10.96 fps), 581.17 kb/s, Avg QP:34.81, SSIM Mean Y: 0.9355421 (11.907 dB)
slower
encoded 313 frames in 60.20s (5.20 fps), 579.85 kb/s, Avg QP:35.67, SSIM Mean Y: 0.9365124 (11.973 dB)
CPUは5960X 4.2GHz、
4コアのi7辺りでテスト出来れば、もうちょっと比較になるけど、
AVX2持っててすぐにテスト出来るのがこれだけだったから。
- 590 ：名無しさん＠編集中：2015/10/12(月) 01:21:47.76 ID:7qlqVooM.net
- >>589
おおお！
すごい速度が出てるなあ
5960X恐るべし
- 591 ：名無しさん＠編集中：2015/10/19(月) 09:30:21.53 ID:yFiWBold.net
- midium、SD解像度ならSandy i5でもそこそこ実用的な速度だなぁ
- 592 ：名無しさん＠編集中：2015/10/19(月) 17:08:24.78 ID:3+3B3ynS.net
- ここ数日、ビルド出来なくなってるな
- 593 ：名無しさん＠編集中：2015/10/20(火) 02:26:43.01 ID:4gF8GZ9l.net
- Intra refreshってなんだ
- 594 ：名無しさん＠編集中：2015/10/21(水) 12:52:02.41 ID:wDWh+p6H.net
- ブロードキャスト用でしょ
- 595 ：名無しさん＠編集中：2015/10/23(金) 10:02:07.23 ID:tigdGsjm.net
- ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
- 596 ：名無しさん＠編集中：2015/10/27(火) 21:58:53.54 ID:HfJdvsW+.net
- 8,10,12bitを出力出来るmultilibなx265.exeのビルドは
Rigaya氏を参考にVS2013で成功、
http://mylabo.webcrow.jp/ さんの環境とスクリプトを応用してGCC5.2で成功しました
しかし、ffmpegにMultilbなx265を組み込むのがうまくできません
どこか参考になるサイトなどあったら教えてください
- 597 ：名無しさん＠編集中：2015/10/28(水) 17:36:55.29 ID:APLDwghM.net
- 同じavisynthからの入力で8bitでエンコしたものと
10bitでエンコしたものではアウトプットの色が若干違ってしまいます
オプションは8bitのものをそのまま使ってますが
10bit用に何か設定しないといけないものがあるのでしょうか
ちなみに8bitでエンコしたものは入力と同じ色で出力されています
- 598 ：名無しさん＠編集中：2015/10/28(水) 19:01:55.48 ID:8El7diMy.net
- >>597
特に必要な設定は無いと思うけど、
・使用したx265のバイナリのURLやリビジョン
・エンコードに使ったツールやコマンドライン、x265のエンコードオプション、エンコードログなど
・avsの内容
・色の違いの確認に使ったツールや設定等（再生プレーヤー、デコーダー等）
・色の違いというのが具体的にわかる比較用スクリーンショット
と言った情報をちゃんと出せば答えてくれる人がいるかもね。
- 599 ：名無しさん＠編集中：2015/10/28(水) 19:16:21.95 ID:+oncCKMQ.net
- 質問させてください
コマンドプロンプト画面でx264のように
エンコードの終わり予想タイムは出ないのですか
だいたいの目安になるのでもし表示させる方法があったらお願いします
- 600 ：名無しさん＠編集中：2015/10/28(水) 19:27:19.30 ID:2TscTojl.net
- >>599
avs4x26x使ってるけど出てる気がする
- 601 ：名無しさん＠編集中：2015/10/28(水) 20:08:55.37 ID:s5f82YBj.net
- >>596
https://github.com/jb-alvarado/media-autobuild_suite
これ使えば全自動
- 602 ：名無しさん＠編集中：2015/10/28(水) 20:13:55.37 ID:+oncCKMQ.net
- >>600
avs2pipemodでは出ないです
avs4x26xを試してみます
ありがとう
- 603 ：名無しさん＠編集中：2015/10/29(木) 08:57:26.76 ID:2tL2U4Zq.net
- >>597
x64のLavだとおかしくなる
x86だと正常に出力される
何だろね
- 604 ：595：2015/10/29(木) 14:38:45.78 ID:hokEF0fR.net
- >>601
うわ！なんか凄いのがあるんですね
色々試してみます
- 605 ：名無しさん＠編集中：2015/10/29(木) 17:52:52.35 ID:hokEF0fR.net
- >>601
早速試してみたところ、最初のfreepypeのビルドであっさりエラーで停止
全自動とは程遠いｗ
スクリプトのx265のところを覗いて見ましたが、
普通にx265のソースをgit cloneした時のMSYSのところにあるmultilib.shと同じことをしているようだけど、、、
12bit版のlibx265.aをビルドし、libx265_main12.aにリネームし、8bit用のフォルダにコピー
10bit版のlibx265.aをビルドし、libx265_main10.aにリネームし、8bit用のフォルダにコピー
8bit版のlibx265.aをビルドし、libx265_main.aにリネームし、
arコマンドを使って上記３個を結合し、libx265.aとする
ここまではmultilib.shと全く同じ
問題は、この後make installをどうやるか。
普通にmake installするとエラーが出て出来ない。そのせいでffmpegに組み込めない。。。
- 606 ：名無しさん＠編集中：2015/10/29(木) 18:47:45.30 ID:KEjOdrQp.net
- rigaya氏のバッチで充分。
- 607 ：名無しさん＠編集中：2015/10/29(木) 18:49:22.39 ID:hokEF0fR.net
- それはexeを作る場合だね
その話はしてないので。
- 608 ：名無しさん＠編集中：2015/10/29(木) 19:08:17.76 ID:KEjOdrQp.net
- ぶっちゃけ流れ読んでかなったからごめんよ!
- 609 ：名無しさん＠編集中：2015/10/29(木) 19:21:33.49 ID:hokEF0fR.net
- うーん、libx265を除いておけばビルド成功する状態なのに、
--enable-libx265を入れると成功しない
「ERROR: x265 not found using pkg-config」
というメッセージが出る
もちろん、multilibではない普通のlibx265を組み込むのは成功してます
- 610 ：名無しさん＠編集中：2015/10/29(木) 19:50:40.90 ID:GqQK4kTk.net
- 今ゼロからやってみたがfreetypeは普通にビルドできるな
もう１回やってみたら
- 611 ：名無しさん＠編集中：2015/11/04(水) 19:24:15.28 ID:bY3Gmjjh.net
- ロシアのバイナリを使っているんですけど
GCCとかICCとかVISUA C++とか違いはコンパイルツール？だそうですけど
どれがお勧めなんですか
- 612 ：名無しさん＠編集中：2015/11/04(水) 19:36:10.00 ID:aZP/zq43.net
- どれでも大差なし
- 613 ：名無しさん＠編集中：2015/11/04(水) 19:51:13.54 ID:bY3Gmjjh.net
- そうなんですか
ICC使っときます
ありがとう
- 614 ：名無しさん＠編集中：2015/11/04(水) 23:15:59.75 ID:e9GNmcr1.net
- あえて言えばVSがWinでは速い？のかな
- 615 ：名無しさん＠編集中：2015/11/05(木) 08:18:36.25 ID:zXSftKub.net
- 早いところVS2015に対応てほしい
- 616 ：名無しさん＠編集中：2015/11/05(木) 17:48:42.31 ID:nPPKDmWy.net
- sln少し書き換えれば2015でビルド出来るよ
- 617 ：名無しさん＠編集中：2015/11/05(木) 23:39:10.13 ID:A8+5sKPz.net
- 対応・・・？
ビルドする人なら対応なんぞ特にいらんだろ
- 618 ：名無しさん＠編集中：2015/11/06(金) 11:09:19.93 ID:fy2s3Lcb.net
- >>616
ん？ソリューションファイルなんて、弄る必要有ったっけ？
cmakeのtargetをVS2015にするだけで良かった気がするけど。
- 619 ：名無しさん＠編集中：2015/11/06(金) 13:10:44.19 ID:ysZ3FpZt.net
- >>618
あ、ごめんそっちだったｗｗ
make-solutions.bat のやつを次の行のようにするだけだな。
cmake -G "Visual Studio 14 Win64" ..\..\source && cmake-gui ..\..\source
- 620 ：名無しさん＠編集中：2015/11/08(日) 19:01:12.75 ID:LWtfbo8L.net
- さっきまで1.8+93（MSCV2013で自ビルド）テストしてたけど、ロシアサイトのインテルコンパイラ版（古いバージョン）
より速くなってた。
着実に進化してますな。
- 621 ：名無しさん＠編集中：2015/11/28(土) 06:26:26.50 ID:xnQKeIKd.net
- しっかし、進展ないと過疎すぎるな・・・
- 622 ：名無しさん＠編集中：2015/11/28(土) 10:08:11.74 ID:jmEC8E0s.net
- いつからの進展なのか知らないが
確実に進歩してるぞ
- 623 ：名無しさん＠編集中：2015/11/30(月) 23:21:51.00 ID:Dp01uuLv.net
- いつの間にかすごい速くなってますね
- 624 ：名無しさん＠編集中：2015/11/30(月) 23:30:39.00 ID:/6tzZX36.net
- 日本語でおｋ
- 625 ：名無しさん＠編集中：2015/12/05(土) 11:39:48.52 ID:HP9A4Irs.net
- インドの大雨のせいで今開発が滞っているらしい
エンジニアの大半はインドにいるんだとか
- 626 ：名無しさん＠編集中：2015/12/05(土) 13:24:08.05 ID:j/JKm4pn.net
- 道理でカレーとタンドリーチキン動画のエンコだけは早いわけだ
- 627 ：名無しさん＠編集中：2015/12/05(土) 14:32:20.10 ID:rfE+JCrx.net
- _,._
( ﾟДﾟ) ・・・
- 628 ：名無しさん＠編集中：2015/12/05(土) 22:04:26.39 ID:8cfk2vXJ.net
- 大雨でインドア中か
- 629 ：名無しさん＠編集中：2015/12/05(土) 22:22:32.22 ID:OGp3Rmbu.net
- 自宅が水で浸かってるのにインドアってなんじゃい
- 630 ：名無しさん＠編集中：2015/12/05(土) 22:30:08.64 ID:1ig9YDeb.net
- インド人もびっくり
- 631 ：名無しさん＠編集中：2015/12/06(日) 11:19:00.57 ID:0gVCYaZ3.net
- >>609
それ、もしかすると本家でも問題になってるかもしれない
x265_config.h に「include <stdbool.h>」を書き足したら動くかも。
media-autobuild_suiteを使うならbuild/patchesにパッチを置いてmedia-suite_compile.shを編集してdo_patchする必要がありそう
https://bitbucket.org/multicoreware/x265/issues/125/x265-not-found-using-pkg-config#comment-23734777
- 632 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 12:27:21.04 ID:nlnTVFDP.net
- rigayaさんのところのx265のverが一気に進んでるけど
開発者は無事に帰れたの？
- 633 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 15:52:12.96 ID:vodPq1d5.net
- え？
Rigayaさんはただ自分でビルドしたものを公開してるだけで、
Rigayaさんがx265開発してるわけじゃないんだけど。
x265は時々、しばらく更新停止した後に突然何十個ものアップデートが公開される時がある
- 634 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 16:01:44.81 ID:nlnTVFDP.net
- 更新が無かったから更新されてなかったのかな、と
- 635 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 16:15:03.73 ID:BMjI76th.net
- >>634
リポジトリを確認するようにしたほうがいい。
https://bitbucket.org/multicoreware/x265/commits/all
- 636 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 17:33:04.26 ID:nlnTVFDP.net
- >>635
ｔｈｘ
（自分でビルドしないけど）ブクマしといた
- 637 ：名無しさん＠編集中：2015/12/26(土) 18:10:11.04 ID:PC8RPPww.net
- 自分用メモ
sandyで、昨日自ビルドしたx265とx264の初エンコテスト比較
x265とx264ともに8bit --preset slower --aq-mode 3 --no-psyで30分の720*480エロ動画
ffmpegでssimの計測
x265
13.38 fps, 263.65 kb/s
SSIM Y:0.885624 (9.416659) U:0.972000 (15.528396) V:0.963594 (14.388307) All:0.913015 (10.605566)
x264
70.87 fps, 604.44 kb/s
SSIM Y:0.979789 (16.944222) U:0.983586 (17.847748) V:0.978977 (16.773040) All:0.980287 (17.052421)
bitbucket見ると最初のコミットが2013-03-07だからがんばってるてことか
Yの落ち込みが大きいからYへのunsharpで多少は補正できそう
- 638 ：名無しさん＠編集中：2015/12/27(日) 16:03:00.15 ID:QPUC82p+.net
- また、「同じオプション指定で比較」するバカが住んでるのか。。。
- 639 ：名無しさん＠編集中：2015/12/27(日) 16:48:07.26 ID:AP5rfsnS.net
- サンプルが小さすぎるのもありそう
SDならxvidのq3ぐらいのほうが綺麗
- 640 ：名無しさん＠編集中：2015/12/27(日) 18:55:24.77 ID:1UDAOmVw.net
- ソースは640x480、41985フレームのアニメ、SSIMはffmpeg調べ。
Xvid q3
エンコ時間3分、1070kbps、SSIM Y:0.986353
x264 r2638kMod --crf 23
エンコ時間3分、532kbps、SSIM Y:0.985826
x264 r2638kMod --crf 21
エンコ時間3分25秒、719kbps、SSIM Y:0.988074
x265 1.8+188 --crf 21
エンコ時間14分23秒、411kbps、SSIM Y:0.985115
>>639
手元のソース１つで試した結果にすぎないし、SSIMだけで画質を語るつもりもないけど、
「SDならXvidの方が綺麗」と主張し続けてる人がどういう基準で「綺麗」だと言ってるのかよくわからん。
- 641 ：名無しさん＠編集中：2015/12/27(日) 19:38:15.28 ID:JuHwvd0v.net
- xvidが綺麗と思えばxvidを使えばいいんじゃない
- 642 ：名無しさん＠編集中：2015/12/27(日) 21:12:50.41 ID:AP5rfsnS.net
- >>640
たびたび書いてるのは自分だけどq値決め打ちじゃなく
画質に満足いくまでq値を下げるのが前提（画質を追求するなら結局q2.6ぐらいまで下げることになる
綺麗の定義は「グレンの潰れなさ具合」
たぶんでブロッキングフィルタとかディテールつぶしが無い分
素直にディテールが綺麗に残るんじゃないかと思ってる
（最後の行を書いてて思いましたけど実写での経験則）
早い話がビットをより多く使うから綺麗ってオチなわけだけど
グレンノイズの少ないソースじゃ違いは分からないかもね
- 643 ：名無しさん＠編集中：2015/12/28(月) 15:03:35.77 ID:AuSc0FjL.net
- ソース、640x480、3分、エロ動画
SSIMはffmpegで測定
x264 デフォ＋no-psy+aq-mode 3
SSIM Y:0.928542 (11.459472) U:0.985500 (18.386333) V:0.981752 (17.387954) All:0.946903 (12.749319)
encoded 5401 frames, 99.91 fps, 1097.19 kb/s
x265 デフォ＋no-psy+aq-mode 3+crf 28
SSIM Y:0.804027 (7.078027) U:0.973071 (15.697855) V:0.959527 (13.928366) All:0.858117 (8.480711)
encoded 5401 frames in 245.51s (22.00 fps), 255.90 kb/s, Avg QP:33.79
x265 デフォ＋no-psy+aq-mode 3+crf 27
SSIM Y:0.803084 (7.057188) U:0.973849 (15.825170) V:0.960736 (14.060104) All:0.857820 (8.471623)
encoded 5401 frames in 248.81s (21.71 fps), 374.87 kb/s, Avg QP:31.58
x265 デフォ＋no-psy+aq-mode 3+crf 26
SSIM Y:0.802878 (7.052659) U:0.974114 (15.869358) V:0.961091 (14.099513) All:0.857787 (8.470593)
encoded 5401 frames in 253.15s (21.34 fps), 433.19 kb/s, Avg QP:30.47
x265 デフォ＋no-psy+aq-mode 3+crf 25
SSIM Y:0.822244 (7.501752) U:0.976616 (16.310877) V:0.965200 (14.584195) All:0.871799 (8.921072)
encoded 5401 frames in 255.54s (21.14 fps), 503.93 kb/s, Avg QP:29.35
x265 デフォ＋no-psy+aq-mode 3+crf 24
SSIM Y:0.821997 (7.495718) U:0.976931 (16.369759) V:0.965568 (14.630388) All:0.871748 (8.919347)
encoded 5401 frames in 258.54s (20.89 fps), 589.12 kb/s, Avg QP:28.23
- 644 ：名無しさん＠編集中：2015/12/28(月) 15:04:48.96 ID:AuSc0FjL.net
- x265 デフォ＋no-psy+aq-mode 3+crf 23
SSIM Y:0.821710 (7.488735) U:0.977138 (16.408933) V:0.965787 (14.658129) All:0.871628 (8.915289)
encoded 5401 frames in 261.84s (20.63 fps), 693.45 kb/s, Avg QP:27.10
x265 デフォ＋no-psy+aq-mode 3+crf 22
SSIM Y:0.821424 (7.481768) U:0.977380 (16.454981) V:0.966083 (14.695766) All:0.871526 (8.911859)
encoded 5401 frames in 264.99s (20.38 fps), 819.56 kb/s, Avg QP:25.95
x265 デフォ＋no-psy+aq-mode 3+crf 21
SSIM Y:0.821099 (7.473879) U:0.977621 (16.501670) V:0.966309 (14.724900) All:0.871388 (8.907184)
encoded 5401 frames in 268.56s (20.11 fps), 972.80 kb/s, Avg QP:24.81
x265 デフォ＋no-psy+aq-mode 3+crf 20
SSIM Y:0.820743 (7.465236) U:0.977812 (16.538787) V:0.966536 (14.754276) All:0.871220 (8.901516)
encoded 5401 frames in 272.35s (19.83 fps), 1158.67 kb/s, Avg QP:23.67
x265 デフォ＋no-psy+aq-mode 3+crf 19
SSIM Y:0.820388 (7.456652) U:0.977981 (16.572001) V:0.966702 (14.775778) All:0.871039 (8.895425)
encoded 5401 frames in 276.62s (19.52 fps), 1380.33 kb/s, Avg QP:22.54
x265 デフォ＋no-psy+aq-mode 3+crf 18
SSIM Y:0.850120 (8.242556) U:0.981450 (17.316653) V:0.972696 (15.637714) All:0.892438 (9.683394)
encoded 5401 frames in 281.16s (19.21 fps), 1648.32 kb/s, Avg QP:21.43
- 645 ：名無しさん＠編集中：2015/12/28(月) 17:19:14.07 ID:AuSc0FjL.net
- 書き忘れ
636, 642, 643にはtune ssimをつけてある
書き忘れテスト, 2passは動かなかったから1pass
ソースは>>643, 643と同じ
x264 no-psy aq-mode 3 bitrate 300
SSIM Y:0.913324 (10.621006) U:0.980374 (17.071684) V:0.974576 (15.947585) All:0.934708 (11.851377)
encoded 5401 frames, 181.90 fps, 305.19 kb/s
x265 no-psy aq-mode 3 medium bitrate 300
SSIM Y:0.804045 (7.078432) U:0.973717 (15.803202) V:0.960709 (14.057068) All:0.858434 (8.490416)
encoded 5401 frames in 248.80s (21.71 fps), 294.75 kb/s, Avg QP:33.58
x265 no-psy aq-mode 3 slow bitrate 300
SSIM Y:0.804188 (7.081599) U:0.973960 (15.843551) V:0.960968 (14.085785) All:0.858613 (8.495908)
encoded 5401 frames in 381.43s (14.16 fps), 294.42 kb/s, Avg QP:33.35
x265 no-psy aq-mode 3 slower bitrate 300
SSIM Y:0.804009 (7.077635) U:0.974380 (15.914158) V:0.961492 (14.144482) All:0.858651 (8.497078)
encoded 5401 frames in 878.83s (6.15 fps), 293.76 kb/s, Avg QP:33.24
x265 no-psy aq-mode 3 veryslow bitrate 300
SSIM Y:0.804055 (7.078661) U:0.974246 (15.891494) V:0.961360 (14.129654) All:0.858638 (8.496666)
encoded 5401 frames in 1402.14s (3.85 fps), 293.52 kb/s, Avg QP:33.36
- 646 ：名無しさん＠編集中：2015/12/28(月) 17:53:58.02 ID:lN2S38Mz.net
- つまり今のところ
x264＞x265
ってこと？
- 647 ：名無しさん＠編集中：2015/12/28(月) 18:59:54.42 ID:dW745Ccp.net
- >>643-645
x265のSSIM:Yの数値が低すぎる。x265のSSIMを正しく測れてないと思うよ。
*.265のままソースと比較すると正しく測れないので、mp4にmuxしてから測る必要がある。
XvidのAVIもそのままだと正しく計測できないようだったので、
AVISource()で読み込んだavsを作ってそれをソースと比較した。
なんでうまく測れないのかはよくわかってないけど。
- 648 ：名無しさん＠編集中：2015/12/28(月) 19:36:33.28 ID:AuSc0FjL.net
- マジかよ
スクリプト書き直しか
たいした労力じゃないけど
- 649 ：名無しさん＠編集中：2015/12/28(月) 22:03:14.78 ID:Yj61mlND.net
- 数値による比較じゃなく実際に目で見て判断しないと・・
それとエロvdvぐらいならx264のcfr22ぐらいでやれば十分でしょ
- 650 ：名無しさん＠編集中：2015/12/28(月) 23:46:54.12 ID:UvY7E994.net
- ffmpegのSSIMフィルタはソースのfpsとエンコしたもののfpsがかなり正確に合ってないと正しく算出出来なかったと思う。
あと確かVP9なんかもAltRefフレーム使ってる関係上か知らないけど普通に読み込むとおかしくなるからAvisynth経由で読み込んでAssumeFPSとかしないと駄目。
- 651 ：649：2015/12/29(火) 00:37:10.31 ID:8IWJ8AGX.net
- VP9云々のやつ今試してみたらAvisynth経由しなくても普通に出来た。
ffmpegのバージョンが上がって修正されたのかも（？）よく分からないけど。
- 652 ：名無しさん＠編集中：2015/12/29(火) 09:35:31.46 ID:9A7QFVez.net
- 647
ホントだ
muxしたらssimが上がってた
muxによってはpts、 DTS、timestampで怒られた
ffmpegから直接265をいじるのが一番無難だった
ffmpegはlibのオプションをオバーライドすることあるから、やりたくなかったんだけど
>>649
まぁ、お遊びってことで
- 653 ：名無しさん＠編集中：2015/12/29(火) 17:30:38.12 ID:9A7QFVez.net
- あと、fmpegから直接265をいじったとき
265のpreset mediumだとfps40でた
y4mを直接265に読ませるとfps20
なんで？
- 654 ：名無しさん＠編集中：2015/12/29(火) 18:41:26.53 ID:wmua3h70.net
- 所詮ffmpeg、その程度ってことだろ。
- 655 ：名無しさん＠編集中：2015/12/29(火) 19:40:09.08 ID:hecsvuwY.net
- 目で見て判断とか
どれだけ自分の目に自信があったら言えるんだ
- 656 ：名無しさん＠編集中：2015/12/29(火) 19:48:01.97 ID:9A7QFVez.net
- >>654
ffmpegのほうが速いんですよ
年末にはまっちまた
- 657 ：名無しさん＠編集中：2015/12/29(火) 20:01:58.91 ID:wm1Lq+lC.net
- 目で見ずにどうやって画質評価するのか疑問
- 658 ：名無しさん＠編集中：2015/12/29(火) 20:40:58.71 ID:R7bcCv7T.net
- SSIMだって人間の感覚から乖離してるのにね
画質オタって自分の感覚に自信が持てないからか絶対的に見える数値評価を過信するよな
- 659 ：名無しさん＠編集中：2015/12/29(火) 21:04:13.88 ID:5PhTB4UX.net
- HEVC の利点って心理的効果も含めて、画質が「良く」見える事じゃないの?
SSIM はあくまでソースとの乖離性を数値化した物だから人間の目が判断する画質とは異なる。
最終的な判断は自分の目で見ることに違いないだろ
- 660 ：名無しさん＠編集中：2015/12/29(火) 21:10:09.82 ID:kA6WO2Bz.net
- 一番マシな数値指標がSSIMってだけで、参考程度にはするけど過信してる奴は別にいないだろ。
- 661 ：名無しさん＠編集中：2015/12/29(火) 21:26:30.90 ID:TzjPmFls.net
- 目も目で主観入ることもあるし数値化もある程度指標にはなるっしょ
散々そこらで書かれている通り過信しなきゃいいだけ
- 662 ：名無しさん＠編集中：2015/12/30(水) 00:57:27.86 ID:vwvyTCw8.net
- SSIMはいちいち画像貼らずに画質の比較が出来るから著作権的に安心なのがいいと思うのよな
あとグラフ書いたりも出来るし
- 663 ：名無しさん＠編集中：2015/12/30(水) 02:50:29.16 ID:0tUCtX9N.net
- エンコーダの性能を語る場において主観的な評価を用いることに意味があるのか？
画質の良さなんて人それぞれなんだから
そりゃどんな設定で使うかは自分で好きにすればいいけどさ
>>645みたいなレビューで主観的に語られてもちっとも参考にならないだろ
- 664 ：名無しさん＠編集中：2015/12/30(水) 09:18:02.01 ID:rUpbP8pC.net
- >>663
支離滅裂
大丈夫か？
- 665 ：名無しさん＠編集中：2015/12/30(水) 10:05:33.84 ID:0j3mn2aP.net
- >>663
頭悪いと大変だな…
- 666 ：名無しさん＠編集中：2015/12/30(水) 10:41:31.01 ID:iKvrKZHw.net
- 俺も>>663はいまいちよくわからない文章だと思ったが、
「>>645みたいな比較を行う場合は主観的評価（"これが綺麗な気がする"とか）じゃ
わけわからねーからSSIM使うしかないだろ」
と言いたいのかなと思った。
- 667 ：名無しさん＠編集中：2015/12/30(水) 10:48:13.38 ID:IZ86kZ2w.net
- 綺麗な気がするとかは意味ないしSSIM比較にも賛成なんだが、
どういう感じに画質劣化するとかレビューはあれば読みたい。
ソースの傾向とも関連するだろうし。
- 668 ：名無しさん＠編集中：2015/12/30(水) 12:23:46.55 ID:0tUCtX9N.net
- >>666
その通りだよ
文章を理解しようとしない人ばかりじゃなくて安心した
ここの人たちはとりあえず批判しておきたいんだろうね
ただ俺も伝わりにくい書き方をしたことは詫びておくよ
- 669 ：名無しさん＠編集中：2015/12/31(木) 11:52:46.61 ID:jlLBbrcv.net
- Performance Presets
http://x265.org/performance-presets/
- 670 ：名無しさん＠編集中：2015/12/31(木) 13:25:56.61 ID:1x/a9izS.net
- ほうlimit-refsをデフォで使うようになった感じ？
720p mediumならリアルタイムでエンコできる環境が増えそうだ
- 671 ：名無しさん＠編集中：2015/12/31(木) 18:06:45.58 ID:wSkFl2OB.net
- グラフ見る限りは魅力的だけど、新プリセットはどこにあるのかな
git見てもそんなのまだなさそうだが
- 672 ：名無しさん＠編集中：2015/12/31(木) 18:35:10.47 ID:xsxqdEld.net
- >>671
既存のプリセットの設定を調整したという話だと思うんだが・・・
- 673 ：名無しさん＠編集中：2015/12/31(木) 19:04:36.81 ID:pgio0AKr.net
- これめちゃ速いな。
--input-csp i420 --preset slow --crf 21 --aq-mode 3 --aq-strength 0.9 --psy-rd 0.5 --psy-rdoq 8 --scenecut 42 --keyint 240
--tu-intra-depth 2 --tu-inter-depth 2 --max-merge 5 --weightb --frames 34096 --input-res 1920x1080 --fps 24000/1001
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 5
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 42
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 4 / 1 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=0.50 rdoq=2 psy-rdoq=8.00
x265 [info]: tools: signhide tmvp strong-intra-smoothing lslices=4 deblock sao
こんな感じで
encoded 34096 frames in 1504.14s (22.67 fps), 1137.26 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 5.82% / x265: 76.88%
全く同じオプションで--pmode付けると
encoded 34096 frames in 2293.68s (14.87 fps), 1122.80 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 3.69% / x265: 87.79%
画質はまだチェックしてないけど、問題無ければ、slowでも余裕でも余裕だな。
(10bitは使う予定無いので、未検証）
- 674 ：名無しさん＠編集中：2016/01/01(金) 02:18:30.24 ID:WmQnDSNu.net
- エラいスピードアップだな。
画質にダメージとかないんかね？
- 675 ：名無しさん＠編集中：2016/01/01(金) 03:09:19.16 ID:RD6MTGrq.net
- 1.8+188で適応されてるの？
- 676 ：名無しさん＠編集中：2016/01/01(金) 05:20:46.74 ID:O3DrfO55.net
- SSIMの話してたら公式がグラフに使っててワラタ
- 677 ：名無しさん＠編集中：2016/01/01(金) 07:49:50.36 ID:jXigYVvB.net
- あーpresetの件、多分、１２月２２日に導入されたこの変更のことだろうな
https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce
各プリセットのパラメータを微調整したうえに、最近導入されたlimit-refs、limit-modesも加えたと。
最新ソースを使ってビルドしてるなら、もう１周間前に導入されてたということね。
- 678 ：名無しさん＠編集中：2016/01/01(金) 09:45:09.31 ID:0amdltZA.net
- 12/23のx265guiEx 3.66v2でプリセット変更への対処が入ってたしな。
1.8+2と1.8+188とで、手元のソースをプリセット指定だけでエンコした結果を比べてみたら
・エンコード速度は全体的に向上。
・ultrafast～fasterでは従来よりSSIM値が小さくなり、ビットレートも大幅に低くなった。
・fast～slowerではSSIM値は従来と同じくらいだが、ビットレートがやや高くなった。
という結果になった。veryslowとplaceboは時間がかかるので試していない。
詳細→ http://pastebin.com/qTfmuANu
- 679 ：名無しさん＠編集中：2016/01/01(金) 11:14:31.16 ID:xC692RGG.net
- すいません、質問です。
x265のソースコードを自分でビルドして使用しているのですが
バイナリのバージョンが不明なんです。これってコード追記しないといけないのでしょうか？
変な質問だったらスルーしてください。
- 680 ：名無しさん＠編集中：2016/01/01(金) 15:09:29.20 ID:jXigYVvB.net
- x265.exe --version
とコマンド打てば表示されるよ
- 681 ：名無しさん＠編集中：2016/01/01(金) 15:29:05.52 ID:xC692RGG.net
- >>680
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.
C:\Windows\system32>x265.exe --version
x265 [info]: HEVC encoder version unknown
x265 [info]: build info [Windows][MSVC 1800][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
こんな感じです。
- 682 ：名無しさん＠編集中：2016/01/01(金) 15:29:40.58 ID:nwqCpAdi.net
- >>679
ソース下のbuild/README.txtにも書かれてる事(「= Version number considerations =」を参照)だけど、
X265_VERSION はcmake実行時にMercurial(hgコマンド)を使用して設定、ないと"unknown"になる。
Mercurial(hg)のパスを環境変数PATHに追加してからcmakeを実行する。
- 683 ：名無しさん＠編集中：2016/01/01(金) 15:39:01.12 ID:xC692RGG.net
- >>682
ありがとうございます。
- 684 ：名無しさん＠編集中：2016/01/01(金) 17:27:43.84 ID:jXigYVvB.net
- Rigayaさんのとこのx265エンコ速度測定記事、プリセット変更直前に書かれてるのがおしい
- 685 ：名無しさん＠編集中：2016/01/01(金) 17:32:56.40 ID:xC692RGG.net
- なんでおかしいの？
rigaya氏が変更を事前に知っていて、わざと記事にしたとでもいうの？
- 686 ：名無しさん＠編集中：2016/01/01(金) 17:34:04.38 ID:k8j4Ysr1.net
- >>685
落ち着いて>>684を読み直してみろ
- 687 ：名無しさん＠編集中：2016/01/01(金) 17:39:27.38 ID:jXigYVvB.net
- >>685
うん。君はおかしい
はい次の人ー
- 688 ：名無しさん＠編集中：2016/01/01(金) 17:43:45.36 ID:xC692RGG.net
- m(__)m
- 689 ：名無しさん＠編集中：2016/01/01(金) 20:28:21.76 ID:FNsjlYzw.net
- ところでさ、現時点のx265はUltra HD BDの規格に準拠した形でのエンコードはできるんだろうか？
それともまだ何か未対応のオプションがあったりして、規格準拠とまではいかないのだろうか？
x265の進捗状況がよくわからないんだけど。
- 690 ：名無しさん＠編集中：2016/01/02(土) 21:42:43.73 ID:uM4JuYJD.net
- どうしても暗部保持ができなくてバンディングになっちゃう
おもいっきりビットレート上げればなんとかなるけど
一話23分半のアニメで3Gくらいの容量になるからさすがに割りに合わない
- 691 ：名無しさん＠編集中：2016/01/03(日) 06:14:00.23 ID:TB5sGS/t.net
- バンディング消す方法なんていくらでもあるでしょー
基本は10bitエンコだし、
バンディング低減するフィルタだって複数あるよ
x264よりも遥かにバンディング出ないx265で悩んでる人はじめて見た
- 692 ：名無しさん＠編集中：2016/01/03(日) 09:29:55.61 ID:+7iHH5QT.net
- バンディングて色調整するとワラワラ出てくることあるね
- 693 ：名無しさん＠編集中：2016/01/03(日) 12:06:06.62 ID:KftKtXND.net
- >>691
x264の10bitの方が明らかにバンディング出ないから悩んでるんだけど
エンコ速度的には十分だと思うし、その問題さえ解消するようならx265に移行するのもいいかなって思ってるけど
>485の頃からまだこういうところは調整されてないのかな？
- 694 ：名無しさん＠編集中：2016/01/03(日) 12:17:20.68 ID:aIpwUsLj.net
- どちらかというとAQで暗部は削られるものだと思うけど・・
- 695 ：名無しさん＠編集中：2016/01/03(日) 13:57:04.40 ID:CBJBsL1D.net
- 糞なのはx265のPsyだろうねぇ
- 696 ：名無しさん＠編集中：2016/01/03(日) 22:11:59.73 ID:V82V0kUc.net
- 下手くそ
- 697 ：名無しさん＠編集中：2016/01/05(火) 23:20:08.23 ID:wK8tZoI/.net
- ん？またプリセット変わったか
- 698 ：名無しさん＠編集中：2016/01/06(水) 21:50:42.37 ID:/8vK25uX.net
- https://bitbucket.org/multicoreware/x265/commits/a6577bee0b71768fcd5c3262b597411d17037afc
Merge with default, prep for 1.9
もうすぐ1.9が来そう
- 699 ：名無しさん＠編集中：2016/01/10(日) 08:23:42.64 ID:Hd4RBeuI.net
- x265 1.8+205 -d94f6c2b45f8
ttp://www1.axfc.net/u/3597706
- 700 ：名無しさん＠編集中：2016/01/10(日) 14:30:01.33 ID:m9YtAxYc.net
- x64じゃないのかな
- 701 ：名無しさん＠編集中：2016/01/10(日) 14:32:48.05 ID:m9YtAxYc.net
- なんかエラーで落ちる
- 702 ：名無しさん＠編集中：2016/01/10(日) 14:47:46.35 ID:Hd4RBeuI.net
- >>701
マジすか？
ちょっと調べてみます。
>>700
64bit専用です。
- 703 ：名無しさん＠編集中：2016/01/10(日) 14:59:37.89 ID:m9YtAxYc.net
- 普段ここの使ってるんだけど
https://builds.x265.eu/
ここのも1/8のものからエラーで落ちるようになってる
1/7の1.8+201のものはエラー出ない
自分の環境かもしれないし何が何だか分かってないけど
問題解決されると嬉しい
- 704 ：名無しさん＠編集中：2016/01/10(日) 15:10:43.28 ID:Hd4RBeuI.net
- これはどうでしょうか？
ttp://www1.axfc.net/u/3597860
- 705 ：名無しさん＠編集中：2016/01/10(日) 15:42:21.06 ID:m9YtAxYc.net
- ありがとう
でも同じだった
イベントビューアにはこんな感じで上がってる
障害が発生しているアプリケーション名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
障害が発生しているモジュール名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
例外コード: 0xc0000005
障害オフセット: 0x0000000000790522
- 706 ：名無しさん＠編集中：2016/01/10(日) 16:05:38.87 ID:Hd4RBeuI.net
- うーん・・・
コマンドラインオプション無しでもエラー出ますか？
- 707 ：名無しさん＠編集中：2016/01/10(日) 16:09:39.28 ID:m9YtAxYc.net
- それだと出ないね
俺のオプションがダメっぽいのか…
どのオプションだろ
削りながら試してみるよ
ありがと
- 708 ：名無しさん＠編集中：2016/01/10(日) 16:12:07.50 ID:Hd4RBeuI.net
- メモリーアクセス違反か。
自分の環境では出ないんですよね。
OSはなんですか？
- 709 ：名無しさん＠編集中：2016/01/10(日) 16:15:17.26 ID:Hd4RBeuI.net
- AVX、AVX2、FMA3を潰してみるとか。
- 710 ：名無しさん＠編集中：2016/01/10(日) 16:16:06.57 ID:m9YtAxYc.net
- --no-deblock
このオプション抜いたらエラー出なくなった
これは自分の環境が悪いとかじゃないよね…
- 711 ：名無しさん＠編集中：2016/01/10(日) 16:23:36.91 ID:Hd4RBeuI.net
- ありがとうございます。
そちらの問題ではなく、コードに問題有りかもです。
- 712 ：名無しさん＠編集中：2016/01/10(日) 16:53:54.29 ID:V/aHiJAl.net
- 斧に上がったバイナリなんてよく実行できるな・・・
- 713 ：名無しさん＠編集中：2016/01/10(日) 17:47:40.97 ID:m9YtAxYc.net
- どうやってバグの情報としてあげればいいのか分からないや
早く気付いて欲しいなぁ
- 714 ：名無しさん＠編集中：2016/01/10(日) 20:26:32.56 ID:PlpsG+IN.net
- >>713
bitbucketの課題にでも投げれば良いんじゃないの？
https://bitbucket.org/multicoreware/x265/issues
- 715 ：名無しさん＠編集中：2016/01/11(月) 04:08:04.43 ID:NFAme+dx.net
- 205で更にエンコ速度上がってるな
- 716 ：名無しさん＠編集中：2016/01/11(月) 18:42:34.02 ID:8MzzuCE7.net
- 今は209だぜー
- 717 ：名無しさん＠編集中：2016/01/11(月) 22:48:39.09 ID:iLbQXuHs.net
- ここ最近開発が活発化してる
いいねえ
- 718 ：名無しさん＠編集中：2016/01/12(火) 03:22:31.26 ID:ay8VbQDJ.net
- x265-1.8+210_19cfada71621
ttp://www1.axfc.net/u/3599204
- 719 ：名無しさん＠編集中：2016/01/12(火) 06:40:40.41 ID:FuFhTotB.net
- 久々にビルドしてみたけど
デフォ設定で1.4と比べたら2倍くらいエンコ速くなってんな
- 720 ：名無しさん＠編集中：2016/01/12(火) 07:22:48.18 ID:UGxx9q6x.net
- 密かにpsy-rdのデフォ値も変わったで
- 721 ：名無しさん＠編集中：2016/01/12(火) 08:45:59.11 ID:FuFhTotB.net
- ホントだ
1.0から0.6になっとるな
ちょこちょこ設定変えてんだな
- 722 ：名無しさん＠編集中：2016/01/12(火) 09:56:13.90 ID:ZF6tU8kF.net
- なかなか1.9にならんな
- 723 ：名無しさん＠編集中：2016/01/12(火) 10:09:53.76 ID:xb1b+Mb+.net
- >>721
旧： 値範囲0～2.0 デフォルト値0.3
新： 値範囲0～5.0 デフォルト値2.0
じゃね。
- 724 ：名無しさん＠編集中：2016/01/12(火) 11:20:34.90 ID:FuFhTotB.net
- strengthだった
- 725 ：名無しさん＠編集中：2016/01/12(火) 14:33:21.76 ID:ckdTaHsh.net
- H265 codecs comparison from MSU
http://x265.ru/en/bolshoe-sravnenie-kodekov-h265-ot-mgu/
- 726 ：名無しさん＠編集中：2016/01/12(火) 14:48:48.67 ID:J/v6lK/H.net
- URLが怪しすぎる…
- 727 ：名無しさん＠編集中：2016/01/12(火) 15:14:52.56 ID:UGxx9q6x.net
- そこは、ちょっと前までx265バイナリの配布定番サイトだったんだけど、
multicorewareとトラブって配布禁じられたサイト
- 728 ：名無しさん＠編集中：2016/01/12(火) 15:33:28.98 ID:xb1b+Mb+.net
- >>727
トラブったという話の情報源はどこ？
本当ならテンプレからも外さないといかんよね。
- 729 ：名無しさん＠編集中：2016/01/12(火) 16:02:11.85 ID:ay8VbQDJ.net
- multicoreware-x265-6ccd503a4c3a
ttp://www1.axfc.net/u/3599390
- 730 ：名無しさん＠編集中：2016/01/12(火) 16:07:54.77 ID:ZF6tU8kF.net
- ウィルスとかの問題じゃないから問題なし
x264は良かったとか書くあたりライセンスとかそのへんの理由
- 731 ：名無しさん＠編集中：2016/01/12(火) 21:07:29.03 ID:UGxx9q6x.net
- >>728
multicorewareがある日突然、他サイトでのバイナリ配布を禁じたんだよ
http://x265.ru/enはバイナリ配布の最大手だったけど、一夜にして配布停止に追い込まれた
- 732 ：名無しさん＠編集中：2016/01/12(火) 22:21:22.09 ID:vk6wUU7N.net
- >>710
https://bitbucket.org/multicoreware/x265/issues/225/outputs-are-inconsistent-with-sao-caused
微妙に症状は違うっぽいけど、--no-deblock付けてエラーになる事が解決されてるから、
多分、直ったっぽいよ。
- 733 ：名無しさん＠編集中：2016/01/13(水) 00:04:51.69 ID:i5ptavi1.net
- 717のバイナリはバグっているので使わないほうがいい。
728は今のところ大丈夫。
- 734 ：名無しさん＠編集中：2016/01/13(水) 00:35:17.31 ID:7rxsXKJd.net
- そもそも他人ビルドで署名が無い物なんて使うわけ無いですし
- 735 ：名無しさん＠編集中：2016/01/13(水) 14:58:50.31 ID:wOrVT6++.net
- そうですか
- 736 ：名無しさん＠編集中：2016/01/14(木) 16:51:17.94 ID:AaOlEqVU.net
- >>732
1.8+211で試してみたけどまだ直ってないみたい…orz
でも気長に待ってみる
- 737 ：名無しさん＠編集中：2016/01/15(金) 06:50:52.92 ID:psKZUe1A.net
- x265-792f6ead9c50
ttp://www1.axfc.net/u/3601075
- 738 ：名無しさん＠編集中：2016/01/17(日) 10:34:19.47 ID:M6mbumiP.net
- H.265はH.264の半分のビットレートで同等画質を実現するのが実証される - GIGAZINE
http://gigazine.net/news/20160117-h265-quality-testing/
- 739 ：名無しさん＠編集中：2016/01/17(日) 10:49:26.43 ID:D60EYyZP.net
- >>738
これx264とx265でPSNR調べてもここまで差が出ないんだけど使ってるエンコーダーが違うのかね
- 740 ：名無しさん＠編集中：2016/01/17(日) 12:09:44.29 ID:Pifl9Opi.net
- JVとかいうリファレンスのコーデックでの比較なんじゃね
- 741 ：名無しさん＠編集中：2016/01/17(日) 12:11:58.73 ID:D60EYyZP.net
- JMとHMって書いてあったわ
- 742 ：名無しさん＠編集中：2016/01/17(日) 13:48:03.23 ID:XmqoO05B.net
- >>738
ADSL回線でピアキャスとかで配信するときに重宝する＞H.265
- 743 ：名無しさん＠編集中：2016/01/17(日) 23:50:56.36 ID:Tbz8Tr7+.net
- ADSLはプランによっては1000kbps上限だからねぇ
- 744 ：名無しさん＠編集中：2016/01/29(金) 21:07:28.93 ID:DKTs/nc/.net
- New 1.9 version of x265
http://x265.ru/en/x265-v-1-9/
x265 version 1.9 has now been released.
This release supports many new features as well as additional assembly optimizations for Main12, intra prediction and SAO.
Recently added features lookahead-slices, limit-refs and limit-modes have been enabled by default in the supported presets.
- 745 ：名無しさん＠編集中：2016/01/30(土) 01:25:28.25 ID:Wakff49R.net
- 1.9来たね！
- 746 ：名無しさん＠編集中：2016/01/30(土) 01:26:18.86 ID:+Hb0depP.net
- 始まる前から終わってるx265
- 747 ：名無しさん＠編集中：2016/01/30(土) 01:28:24.65 ID:pHFV68mi.net
- 今ビルドちゅう
- 748 ：名無しさん＠編集中：2016/01/31(日) 00:22:07.01 ID:oQyeXKXJ.net
- 適当にベンチ 詳細はテキストに
ソース https://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.8 encoded 313 frames in 14.69s (21.31 fps), 744.68 kb/s, Avg QP:29.82, SSIM Mean Y: 0.9345886 (11.843dB)
1.9 encoded 313 frames in 13.67s (22.90 fps), 728.73 kb/s, Avg QP:33.03, SSIM Mean Y: 0.9343822 (11.830dB)
fast
1.8 encoded 313 frames in 24.91s (12.57 fps), 733.66 kb/s, Avg QP:33.71, SSIM Mean Y: 0.9383575 (12.101dB)
1.9 encoded 313 frames in 26.91s (11.63 fps), 727.01 kb/s, Avg QP:33.73, SSIM Mean Y: 0.9384505 (12.108dB)
medium
1.8 encoded 313 frames in 32.16s (9.73 fps), 734.23 kb/s, Avg QP:33.80, SSIM Mean Y: 0.9399273 (12.213 dB)
1.9 encoded 313 frames in 29.66s (10.55 fps), 727.66 kb/s, Avg QP:33.77, SSIM Mean Y: 0.9395933 (12.189dB)
slow
1.8 encoded 313 frames in 117.56s (2.66 fps), 730.36 kb/s, Avg QP:33.21, SSIM Mean Y: 0.9423414 (12.391dB)
1.9 encoded 313 frames in 69.20s (4.52 fps), 720.24 kb/s, Avg QP:33.22, SSIM Mean Y: 0.9419035 (12.359 dB)
slower
1.8 encoded 313 frames in 239.98s (1.30 fps), 734.70 kb/s, Avg QP:34.08, SSIM Mean Y: 0.9430790 (12.447dB)
1.9 encoded 313 frames in 119.09s (2.63 fps), 703.49 kb/s, Avg QP:34.26, SSIM Mean Y: 0.9408265 (12.279dB)
x264 core:148 r2643 5c65704
veryslow
encoded 313 frames, 16.12 fps, 801.52 kb/s, SIM Mean Y:0.9335760 (11.777db)
http://www.dotup.org/uploda/www.dotup.org718947.txt
- 749 ：名無しさん＠編集中：2016/01/31(日) 01:35:17.36 ID:cgqklV4a.net
- >>748
slow slowerの高速化がすごい
- 750 ：名無しさん＠編集中：2016/01/31(日) 02:31:21.15 ID:UHx+fRoe.net
- ああ、俺もベンチするスクリプトを Ruby で書いてみたりしてたけど
最近やってなかったな。。。で久々にやってみたたら比較対象が 1.6 の medium しかなかったｗ
http://i.imgur.com/WiicPsw.png
- 751 ：名無しさん＠編集中：2016/01/31(日) 13:41:59.34 ID:txIOJs0s.net
- >>748
slowerがビットレート下がりすぎてSSIMもそれに引き摺られちゃってるね
でも倍も速度でてる
- 752 ：名無しさん＠編集中：2016/01/31(日) 16:07:20.48 ID:cFXQSVbu.net
- プリセット内容が変わったんじゃなかった？
- 753 ：名無しさん＠編集中：2016/01/31(日) 18:33:49.97 ID:tisPGxzA.net
- >>752
たしかあったな…
- 754 ：名無しさん＠編集中：2016/01/31(日) 18:53:54.26 ID:TP98Z0n+.net
- たしかにプリセット変更で旧プリセットと同じビットレートでのSSIM落ちたけどちょっとしか落ちてないしその分早くなってるからいいや
あとveryfastなんかだと速度も上がってSSIMも上がってたりする。
- 755 ：名無しさん＠編集中：2016/01/31(日) 20:01:42.34 ID:FzlptxAC.net
- x265は今後もCPUのみの演算で貫くのかね？
GPUのメモリーがHBMやHBM2の導入でかなり速くなるし、バス速度や演算能力そのものも上がろうとしているわけだが、
相変わらず一部だけでもGPUに振り分けるよりCPUのみのほうがいいのかね？
- 756 ：名無しさん＠編集中：2016/01/31(日) 20:07:08.49 ID:cFXQSVbu.net
- x265の開発元が新しいコンパイラHCCの開発をするみたいだから
ヘテロジニアス対応は案外、早いかもしれない
- 757 ：名無しさん＠編集中：2016/01/31(日) 20:24:55.92 ID:o77Jhxsk.net
- >>755
PCIeの遅さが何とかなれば、じゃないかな
NVIDIAのNVLinkは一般PC環境では期待できないみたいだし
AMDもなんか高速バスかなんかやっているみたいだけど普及するかわからない
- 758 ：754：2016/02/02(火) 13:26:49.31 ID:NCVy8Op8.net
- >>756-757
HBM2がメインストリームのCPUやAPUに採用される日
http://pc.watch.impress.co.jp/docs/column/kaigai/20160202_741748.html
この記事によるとHBM2がコストダウンすれば一般向けのPC環境でも利用できるようになる可能性はあるようだから、あとはコストとバス速度の問題がなんとかなればいいのかも。
いつまでもCPUオンリーって時代でもないだろうし。
- 759 ：名無しさん＠編集中：2016/02/02(火) 14:53:24.44 ID:oWE9M/3S.net
- >>758
HBMは容量と帯域ばかりの記事が多かったけどレイテンシも低いんだな
じゃないとグラボ向けに積まれないか
- 760 ：名無しさん＠編集中：2016/02/02(火) 19:03:54.47 ID:NCVy8Op8.net
- GPUって大抵2スロット専有するんだから、PCI-Exスロットも2スロット挿しにして2倍速いってなわけにはいかないのかなと妄想。
- 761 ：名無しさん＠編集中：2016/02/03(水) 15:02:46.32 ID:juHubKYm.net
- >>760
っ [SLI]
- 762 ：名無しさん＠編集中：2016/02/03(水) 17:41:33.40 ID:+OWBi5Bj.net
- Android版とかiOS版のx265なんて出ないものなのかね？
- 763 ：名無しさん＠編集中：2016/02/03(水) 18:20:21.38 ID:63ziqI0j.net
- バッテリで動く端末との相性は最悪だろ
- 764 ：名無しさん＠編集中：2016/02/03(水) 18:34:18.04 ID:+OWBi5Bj.net
- >>763
なんで？
ちょこっとしたビデオクリップを編集後にエンコードまで出来たら、外出先で重宝しそうなものだが。
USB給電がこれだけ普及し、iPad proみたいなのまで出てくると、エンコードくらい多少時間がかかってもモバイル機器でできたほうが消費電力的にもうれしいわけだが。
- 765 ：名無しさん＠編集中：2016/02/03(水) 18:36:25.29 ID:xdk3hERs.net
- ちょっと何言ってるか分かんない
- 766 ：名無しさん＠編集中：2016/02/03(水) 18:38:36.07 ID:iehiN48C.net
- x265はともかくカメラの画像をエンコードしてるチップにデータ送ってエンコードできたらなどと思うことはあるw
- 767 ：名無しさん＠編集中：2016/02/03(水) 20:06:23.57 ID:stWNn/Ef.net
- 最近リリースされたx265どう？
良ければコンパイルし直そうかと思ってる
- 768 ：名無しさん＠編集中：2016/02/03(水) 20:30:41.98 ID:3wA6RKbD.net
- たかがビルドで人に聞かないと動けないって・・・
- 769 ：名無しさん＠編集中：2016/02/03(水) 21:05:22.98 ID:yXDm8y7+.net
- rigaya 氏の multilib ビルドバッチでビルドは楽させて頂いているｗｗ
ありゃ楽だ
- 770 ：名無しさん＠編集中：2016/02/04(木) 09:38:26.30 ID:T7nDHZT/.net
- >>764
その時間かかるって何日かかるんだ
モバイル用の非力CPUでのソフトエンコで
専用チップのエンコードならともかく
- 771 ：名無しさん＠編集中：2016/02/04(木) 11:37:30.45 ID:+3HectuX.net
- 朝鮮人に句点は難しい。
- 772 ：名無しさん＠編集中：2016/02/04(木) 14:41:30.65 ID:J/9ovht0.net
- 実際どのくらい差あるのかな？
i5 6600とsnapdragon801で50倍差くらい？
- 773 ：名無しさん＠編集中：2016/02/04(木) 14:50:52.72 ID:+3HectuX.net
- 一部でもハードウェアの支援機能が使えればだいぶと話は変わるだろうね。
こんな記事もあるわけだし。
・ iPad Proは本当に4Kビデオ編集に使えるのか!? ガチ検証
http://av.watch.impress.co.jp/docs/series/zooma/20160203_741889.html
- 774 ：名無しさん＠編集中：2016/02/04(木) 22:37:23.84 ID:M4vC7LHq.net
- ffmpegでx265のハードウェアエンコードってもうサポートされてる？
QSVでできるとありがたい＞IvyBridge使いとしては
- 775 ：名無しさん＠編集中：2016/02/04(木) 22:57:03.08 ID:T7nDHZT/.net
- ？
- 776 ：名無しさん＠編集中：2016/02/05(金) 07:51:11.13 ID:NlSCducd.net
- x265はソフトエンコのためのソフトだ
ハードウェアエンコなどサポートされるわけがない
h.265(規格名 HEVC)とx265(ソフト名)の区別がついてないんだろうけど
QSVは固定回路
後からHEVC対応などできん
QSVでHEVC対応したのはSkylakeから
QSVでHEVC使いたいならSkylakeに買い換え
- 777 ：名無しさん＠編集中：2016/02/05(金) 12:12:20.92 ID:35jGb+Wd.net
- QSVは完全固定じゃないけどな。
- 778 ：名無しさん＠編集中：2016/02/05(金) 13:03:43.84 ID:LD2LJSnr.net
- コマンドラインからQSV使いたいんだろう。
まあH.265のスレに行くといい。
- 779 ：名無しさん＠編集中：2016/02/05(金) 13:40:15.88 ID:nrq1jwhr.net
- さらにソフトが対応しなきゃならんし
無知のドヤ顔知ったかはほんとどうにもならんといつも思う
- 780 ：名無しさん＠編集中：2016/02/05(金) 22:18:13.16 ID:cHw5jbd1.net
- >>776
Oh。。。そういうことなのね
しらんかったわ
H.264のハードウェアエンコで悦ってくるわﾉｼ
- 781 ：名無しさん＠編集中：2016/02/17(水) 00:08:44.49 ID:q2blbE92.net
- ↓こちらの動画配信解説サイトを参考に
http://pecardy.vanu.jp/?%C0%DF%C4%EA%2FMKV%C7%DB%BF%AE
ffmpeg.exe -re -rtbufsize 256MB -flags +global_header -r 30 -s 1708x960
-f dshow -i video="SCFF DirectShow Filter":audio="ライン入力 (Realtek High Definition "
-threads 0 -r 30 -s 854x480 -vcodec libx265 -tune zerolatency -preset fast -b:v 318k
-af aresample=async=1 -acodec libfdk_aac -ar 48000 -b:a 32k -ac 2 -vol 450
-profile:a aac_he_v2 -f matroska
というエンコードをしていますがどうも画質がx264よりも若干劣る気がして仕方がありません。
本来ならx265はx264の半分のビットレートで同等の画質を実現できるはずなのですが・・・
オプションの指定方法とかで改善すべき箇所とかありますか？
ちなみにPCスペックにはまだ余裕があるのでもう少し負荷がかかる
オプションでも問題無いと思います。
ちなみにx264は以下の様なオプションでエンコードしていました：
ffmpeg.exe -rtbufsize 256MB -r 30 -s 1708x960 -f dshow
-i video="SCFF DirectShow Filter":audio="ライン入力 (Realtek High Definition "
-threads 0 -r 30 -s 854x480 -sws_flags lanczos -pix_fmt yuv420p -vf "unsharp=3:3:0.5"
-b:v 636k -maxrate 636k -bufsize 636k -vcodec libx264 -preset veryslow -profile:v high
-x264opts "me=umh:ref=5:bframes=3:trellis=1:subme=8:keyint=250:qpmin=0:qpmax=69:rc-lookahead=50:min-keyint=25"
-async 100 -acodec libfdk_aac -profile:a aac_he -signaling implicit -afterburner 1
-ar 48000 -ab 64k -ac 2 -vol 450 -f flv
- 782 ：名無しさん＠編集中：2016/02/17(水) 00:24:39.26 ID:ctq6s7UU.net
- ffmpeg も HandBrake もそうだけど、libx265 使うとそういう傾向になるみたいだね。
このスレの話しに紐付けるなら x265 で HEVC エンコしてみたらどうだろう。
ffmpeg で demux して動画部分を x265、音声部分を neroaac なりかまして
最後 remuxer 通すなり mp4box で mux すれば良い。
- 783 ：名無しさん＠編集中：2016/02/17(水) 00:52:00.93 ID:LHOUYy6V.net
- >>781
x265のfastとx264のveryslowだしなあ…
もう大分前のデータだしプリセット変更入ったからそこまで参考にはならないけど、
この辺のグラフ見れば必ずしもビットレート半分で同等の画質にはならないのが分かるはず。
>>302
>>365
>>381
>>406
- 784 ：名無しさん＠編集中：2016/02/17(水) 13:59:46.42 ID:SngcRS/c.net
- >>781
-tune zerolatency これやめたらどう？
- 785 ：名無しさん＠編集中：2016/02/17(水) 14:39:11.08 ID:UvZou3Zff
- ビットレート半分で同等の画質っていう謳い文句はx265のエンコード時間を度外視してx264と比較した場合の話でしょ
x265は複雑でx264で出来なかったような処理をする分時間が掛かるけどビットレートは少なくて済むってだけの話
x265の処理を簡単にしてx264と同じような速度でエンコードさせたら縮まないのは当然だと思う
- 786 ：名無しさん＠編集中：2016/02/17(水) 20:30:34.56 ID:5I7ClG3n.net
- >>781
主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
やり方はテスト動画を用意してそれをx264とx265でエンコする
エンコ前の動画とエンコ後の動画を比較してSSIMとPSNRを出力する
そのデータを参考にしてffmpegのオプションを組み立てていく
SSIMとPSNRを出力するffmpegのコマンドはこんな感じ
ffmpeg -i エンコ前の動画 -i エンコ後の動画 -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
- 787 ：780：2016/02/18(木) 00:12:09.35 ID:EKbwhu+3.net
- 皆さんアドバイスありがとうございますm(_ _)m
presetのfast/veryslowとか結構違いが効いてきそうですね。
slowにしてみたところ画質がだいぶ向上した気がします。
ただ負荷が高いのかエンコ配信中は画面がカクカクしてしまいましたが。
mediumくらいで折り合いを付けようかと思います。
> -tune zerolatency
このオプションは音ずれ防止用に入れました。
画質となにか関係ありますか？
> 主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
SSIM・PSNRは始めて聞きました。
x265から加わったオプションでしょうか。
画質に影響するオプションの用なのでちょっと調べてみようと思います。
あと>>781のx265オプションで配信テストをしていたところ、Windows10付属のWMPでは
画面が灰色になって再生できなかったけどVLC Media Playerでは正常に再生できたという
報告がありました。
- 788 ：名無しさん＠編集中：2016/02/18(木) 00:21:20.69 ID:bnH8mLRR.net
- 言っておくけどSSIMやPSNRはあくまで「数字の上での正確性」だから、それだけを鵜呑みにしないように
個人的にはオプションよりビットレートをもっと盛るのを最初にするべきかと
-b:v 518kぐらいでやってみては？
（もっともx264ので画質・容量的に満足できるならx264でいいと思うけど）
- 789 ：名無しさん＠編集中：2016/02/18(木) 01:05:06.98 ID:hHEKfc2c.net
- >>787
>> -tune zerolatency
>このオプションは音ずれ防止用に入れました。
音ズレ防止にはならない。配信のラグを軽減するだけ
>画質となにか関係ありますか？
zerolatency no lookahead, no B frames, no cutree
( http://x265.readthedocs.org/en/default/presets.html )
私はすごく関係あると思うんですが。
- 790 ：名無しさん＠編集中：2016/02/18(木) 09:11:42.49 ID:Z9lL4Edt.net
- やっぱ配信用設定はBフレーム削っちゃうんだね
NVENCのHEVCみたいだ
- 791 ：名無しさん＠編集中：2016/02/18(木) 11:06:46.21 ID:nlO5v3H8L
- >>787
配信中カクカクするのは当然
お察しの通り負荷が高いから
要するにそれは配信する映像のフレームレートにエンコードのスピードが追いついていない
例えば30fpsの映像を配信しようとしてもエンコードできる速度が10フレーム/秒とかだったら20フレーム足りないわけで当然止まる(それかどんどん遅れていく)
PSNRもSSIMもx264の時代からある
ようするにエンコード前の元動画と比較してどれくらい差が出たかっていうのを数値化して表現するもの(テストの採点みたいな感じ)
しかし機械的に判断した上での数値だから実際の目で見たときに数値ほど綺麗 or 綺麗じゃないということも起こりうる
Bフレーム由来の音ズレ(確か数フレーム音が遅れる)現象はx264の時代からあるはずだけどぶっちゃけ見てて気になるほどではないはず
しかもBフレームを使わないとなると圧縮率は結構下がるから必要なビットレートは多くなってしまう
長くなったけど正直配信用途なら大人しくx264使って配信したほうが良いと思う
現状x264と比較してx265は遅すぎる上に視聴者側にコーデックの導入してもらわないとそもそも見えない場合もある
x264並みに速くしてしまったら結局x265の旨みである「低ビットレートでも高画質」ってのは実現しにくくなると思う
- 792 ：名無しさん＠編集中：2016/02/18(木) 17:44:58.53 ID:xYEflaB1.net
- >>787
テスト用の動画を用意してinput.mp4ってファイル名にして下のコマンドをbatファイルに入れて実行してみ
ffmpeg -i input.mp4 -c:v libx265 -b:v 1000k -preset fast -an -f matroska output.mkv
ffmpeg -i input.mp4 -i output.mkv -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
pause
ffmpeg -i input.mp4 -c:v libx265 -b:v 1000k -preset fast -tune zerolatency -an -f matroska output.mkv
ffmpeg -i input.mp4 -i output.mkv -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
pause
pauseの所で止まるからSSIMとPSNRを確認できる
-tune zerolatency無しのコマンドのSSIMとPSNR
[Parsed_ssim_0 @ 056f7ee0] SSIM Y:0.973342 (15.741661) U:0.987857 (19.156803) V:0.987214 (18.932536) All:0.978073 (16.590190)
[Parsed_psnr_1 @ 050a8dc0] PSNR y:36.989533 u:46.248371 v:45.899587 average:38.421691 min:24.789515 max:inf
-tune zerolatency有りのコマンドのSSIMとPSNR
[Parsed_ssim_0 @ 05947f40] SSIM Y:0.971439 (15.442303) U:0.987953 (19.191359) V:0.987271 (18.951983) All:0.976830 (16.350782)
[Parsed_psnr_1 @ 052f7d80] PSNR y:36.171702 u:46.200393 v:45.728706 average:37.641917 min:22.273266 max:inf
SSIMもPSNRも数値が大きい方が画質が良いので
-tune zerolatencyは付けない方が画質が良いという事がSSIMとPSNRを使えば簡単に分かるわけだ
- 793 ：名無しさん＠編集中：2016/02/18(木) 18:13:49.28 ID:xYEflaB1.net
- ちなみにどの数値を見れば良いのかと言うとSSIMはAllの数値、PSNRはaverageの数値を見て比較してくれ
あとテスト用の動画はmp4じゃなくてもmkvでもtsでも何でも良い
- 794 ：名無しさん＠編集中：2016/02/19(金) 18:44:02.46 ID:4YDtVCyu.net
- mac用multibitビルド
自分用メモ
TARGET="/sw"
CMPL="/Volumes/Ramdisk/compile"
mkdir -p ${TARGET}
mkdir -p ${CMPL}
#x264 8bit 10bit 12bit混合バイナリーbuild
cd ${CMPL}
mkdir -p 8bit
mkdir -p 10bit
mkdir -p 12bit
#12bit build
cd ${CMPL}/12bit
hg clone https://bitbucket.org/multicoreware/x265
cd x265
cd source
cmake -DHIGH_BIT_DEPTH=ON -DMAIN12=ON -DEXPORT_C_API=OFF -DENABLE_CLI=OFF -DENABLE_SHARED=OFF && make -j 8
#10bit build
cd ${CMPL}/10bit
hg clone https://bitbucket.org/multicoreware/x265
cd x265
cd source
cmake -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_CLI=OFF -DENABLE_SHARED=OFF && make -j 8
#8bit build
cd ${CMPL}/8bit
hg clone https://bitbucket.org/multicoreware/x265
cd x265
cd source
#12bit 10bit staticを8bitで読めるように移動
mv ${CMPL}/12bit/x265/source/libx265.a ${CMPL}/8bit/x265/source/libx265_main12.a
mv ${CMPL}/10bit/x265/source/libx265.a ${CMPL}/8bit/x265/source/libx265_main10.a
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DHIGH_BIT_DEPTH=OFF -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DENABLE_SHARED=OFF && make -j 8
mv libx265.a libx265_main.a
#12bit 10bit 8bitstaticを混合
libtool -static -o libx265.a libx265_main.a libx265_main10.a libx265_main12.a 2>/dev/null
make install
- 795 ：名無しさん＠編集中：2016/02/19(金) 18:46:36.53 ID:4YDtVCyu.net
- 書き忘れ
ffmpegで使うときは、output-depthじゃなく
-pix_fmt yuv420p10le
-pix_fmt yuv420p12le
で指定
- 796 ：780：2016/02/19(金) 22:23:59.21 ID:pxdW5hFs.net
- >>792
ありがとうございます。
早速SSIM/PSNRの数値を調べてみました。
たしかに皆さんがおっしゃるとおりzerolatencyを付けない方が
SSIM/PSNRの数値は上でした。
しかし今まで画質の善し悪しは主観的に判断するしか無いと思っていましたが
こうやって数値で確認する事もできるんですね。
いろいろパラメーターを変えつつSSIM/PSNRの数値を見て最適なポイントを
探してみようと思いますm(_ _)m
- 797 ：名無しさん＠編集中：2016/02/19(金) 23:27:22.99 ID:9715NWZX.net
- 指標は便宜上使われてるだけで基本は主観で判断だと思うよ
コンピューターが許容できる違いと人間が許容できる違いは同じではないからね
- 798 ：名無しさん＠編集中：2016/02/19(金) 23:40:15.58 ID:qSH2klIW.net
- あと多分-tune ssim付けて比較しないと意味ない
- 799 ：名無しさん＠編集中：2016/02/20(土) 10:10:44.80 ID:YhMIaURA.net
- 主観で判断なんてほぼ無理だろう
これができるならそれで飯が食べられる
まぁ、どこで妥協するかだろう
- 800 ：名無しさん＠編集中：2016/02/20(土) 11:04:23.50 ID:K6y5yssU.net
- あくまで指標
数値で画質が決まるならx264（例として）でpsnrやssimなんてtune作る必要がないからね
- 801 ：名無しさん＠編集中：2016/02/20(土) 11:37:36.59 ID:k+agU2Eu.net
- 主観で判断出来ないなんて可哀想な人
- 802 ：名無しさん＠編集中：2016/02/20(土) 11:49:29.89 ID:YhMIaURA.net
- よっぽど悔しかったのかな
公式でも使われて、急にダンマリしちゃった人がいたな
- 803 ：名無しさん＠編集中：2016/02/20(土) 11:54:48.37 ID:sO+hYrhk.net
- 自分の場合は最初に目で見て、これビットレート半分で画質同等って大げさじゃね？と思ってSSIM調べたらその通りだったって話だから順序逆なんだよな
- 804 ：名無しさん＠編集中：2016/02/20(土) 12:06:07.01 ID:SpT3cwNh.net
- 極端な話見ている人にバレなければ元と全然別物でも問題無い
- 805 ：名無しさん＠編集中：2016/02/20(土) 12:22:21.53 ID:K6y5yssU.net
- 基本は、「見てる人=自分だから」好きなようにとしか言いようがない
だけどわざわざ--tune psnrやらssim使って本番エンコする奇特な人もいるんだなと不思議に思ってる
- 806 ：名無しさん＠編集中：2016/02/20(土) 13:55:57.50 ID:EIhIWuJR.net
- 本番エンコで使うなんて誰も言ってないような・・・
- 807 ：名無しさん＠編集中：2016/02/20(土) 14:49:46.80 ID:K6y5yssU.net
- たしかに・・
「最後は主観」を否定する人かと思って短絡的に書いたは
- 808 ：名無しさん＠編集中：2016/02/20(土) 16:02:15.78 ID:BHDZ19yf.net
- -tune psnrとssimは心理視覚を向上させるオプションを無効になり主観的な画質が悪くなるので使わない方が良いみたい
心理視覚と言うのは例えば人間の目で見て画質の違いが分かりにくい部分の画質を悪くして違いが分かりやすい部分の画質を良くすることで
同じビットレートでも主観的な画質が良くなるみたい。だけどSSIMとかPSNRは画質の違いが分かるので数値が低くなるようだ。
- 809 ：名無しさん＠編集中：2016/02/26(金) 10:29:06.48 ID:i7aFZYs7.net
- ssimでだいたい当たりを付けて、psy関連で仕上げじゃないのか？
x264もx265もかなり練り上げられてるから、俺にはssim無しの判断は無理だわ
ssimの0.001の違いなんて目で区別できん
シーンごとに同一フレーム拡大確認なんてなおさら
最後は主観で判断と言うより、好み次第じゃない？
- 810 ：名無しさん＠編集中：2016/02/26(金) 10:59:27.59 ID:iu0kmo+a.net
- それを主観で判断すると言うんじゃ
- 811 ：名無しさん＠編集中：2016/02/26(金) 12:24:00.84 ID:ykLbS11Bg
- 自分の場合SSIMは0.98あたりにもなると主観で元の動画との区別が付かない画質になるからそれを基準にしてる
- 812 ：名無しさん＠編集中：2016/02/26(金) 16:24:08.79 ID:i7aFZYs7.net
- そうなのか
なら、語る余地無しだな
てっきりssimに頼らず目視でエンコ精度を判断してるのかと思った
12bitの効果はどう？
- 813 ：名無しさん＠編集中：2016/02/26(金) 16:35:14.80 ID:bHaTV8wK.net
- 普段10bitでやっとるけど12bitにしてみたところで違いが分からなかったよ。
- 814 ：名無しさん＠編集中：2016/02/26(金) 17:41:29.90 ID:m+0FG1+N.net
- ID:i7aFZYs7
主観の意味分かってないの？
- 815 ：名無しさん＠編集中：2016/03/09(水) 17:54:53.68 ID:imJr87Pl.net
- x265vfwも出てるやん
https://sourceforge.net/p/x264vfw/discussion/770224/thread/3e07f7b5/
l
- 816 ：名無しさん＠編集中：2016/03/09(水) 18:23:15.11 ID:qNQxWU8R.net
- 今時vfwなんてメリットあんのかね？
エンコ詳しくないニコ厨でもwiki見て簡単にmp4エンコできるのに
- 817 ：名無しさん＠編集中：2016/03/09(水) 18:29:23.70 ID:9Y8nZSW1.net
- 関わるな
- 818 ：名無しさん＠編集中：2016/03/13(日) 09:20:31.95 ID:weseHvkQ.net
- rc-grainの効果はどう？
あまり効果を実感できない
- 819 ：名無しさん＠編集中：2016/03/20(日) 08:39:40.31 ID:7J9mixui.net
- 最近完走しなくなった。
皆さんどうです？
OS入れ直して駄目ですので、x265疑ってるんですが。
どこのビルドも1.9は駄目な感じです。
- 820 ：名無しさん＠編集中：2016/03/20(日) 10:04:28.56 ID:KHVZBQe4.net
- エスパーさん出番ですよ
- 821 ：名無しさん＠編集中：2016/03/20(日) 11:38:36.85 ID:dlNvEFCk.net
- >>819
ちゃんと完走してるよ
muxerを最新のに変えてみるとか
- 822 ：名無しさん＠編集中：2016/03/20(日) 15:51:11.82 ID:16IrSqAm.net
- >>819
avisynthでMT使ってるとエスパーしてみる
- 823 ：名無しさん＠編集中：2016/03/20(日) 20:06:27.41 ID:nKj/TuoV.net
- MUXではなくエンコード自体が完了しないのです。
avisynthはMT使わずソース読ますだけの最小構成です。
皆さん問題ないんですね。
とりあえず自分の構成をもっと疑ってみます。
止まるのが規則性があったり無かったり意味不明なんですよね。
同じソースで3%数回続いた後、70%で止まったりorz
- 824 ：名無しさん＠編集中：2016/03/20(日) 20:40:06.24 ID:Fu5UyCAR.net
- 短いソースで試してみたら
- 825 ：名無しさん＠編集中：2016/03/20(日) 22:59:05.03 ID:oLphnsNe.net
- そういう時はmemtest
自分の環境よりソフトの方を疑うというのが理解できない
- 826 ：名無しさん＠編集中：2016/03/20(日) 23:51:09.20 ID:mbWz3Yxf.net
- aviでエンコードしてからx265でエンコードは？
- 827 ：名無しさん＠編集中：2016/03/21(月) 09:44:15.65 ID:PdR6lJIR.net
- メモリテストはwin付属ので問題なかったのと、
OS入れ直し、avisynth入れ直しくらいはしました。
ソースも変えてます。
30分位のソースだとごくまれに完走します。
11月くらいまで動いてたのでハードはそこまで疑いたくないのですが。
- 828 ：名無しさん＠編集中：2016/03/21(月) 10:48:22.93 ID:W3zX88FD.net
- >>827
そうやって821が言うような定石を守らないから
切り分けができないんだと思うよ
まぁ仮にmemtestで落ちても
原因はメモリとは限らないんだけどね
- 829 ：名無しさん＠編集中：2016/03/21(月) 10:58:42.48 ID:EJTslGgf.net
- 完走する事もあるならソースかハードの問題でしょ
頭おかしい
- 830 ：名無しさん＠編集中：2016/03/21(月) 11:15:49.32 ID:IwyEIcSu.net
- フルボッコで可哀想だからレスするけど
aviutl + x265guiでやってみたら？
- 831 ：名無しさん＠編集中：2016/03/21(月) 15:07:19.74 ID:+Ik+xhI4.net
- 1.9で中途ファイルが出来たというのはうちでもあったな
以前の構成から変わったのってそこぐらいだから1.9の所為なんだろうなとは思った（リトライしたら通ったけど）
- 832 ：名無しさん＠編集中：2016/03/21(月) 17:40:19.97 ID:U+Xdgxb4.net
- 同じ条件で上手くいく時といかない時があるって、ハード側が不安定なだけじゃね？
ソフト側の問題なら再現性はもっと高いと思うが
- 833 ：名無しさん＠編集中：2016/03/21(月) 18:39:37.32 ID:+Ik+xhI4.net
- ログ見たらフレームの入力に失敗してるっぽいな
avs側でYV12に変換してやると多分解決する
- 834 ：名無しさん＠編集中：2016/03/21(月) 20:18:58.92 ID:3MEwZrZM.net
- 今は完走しないことについての話なのになんで入力の話してるんだよ
途中で色空間が変わってるとしたら完全にスクリプトの問題じゃねーか
- 835 ：名無しさん＠編集中：2016/03/21(月) 20:41:01.66 ID:Y85ZQ3tt.net
- >>827
handbrakeかffmpegで試してみれ
- 836 ：823：2016/03/21(月) 21:38:39.05 ID:vZIwSY4R.net
- とりあえず、OS再インストールしてみた。
AVISYNTH+にしてみてもおちたorz
memtestは明日出勤の間してみる。
ここらで構成とログ（一部)さらし
Win10 1511
CPU i7 5820k 定格3.3Ghz
MEM DDR4 32gb 定格2133mhz
以下で止まる。
avs [info]: AviSynth+ 0.1 (r1576, x86)
avs [info]: Video colorspace: YV12
yuv [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.9+73-6d06de58c3163c19
x265 [info]: build info [Windows][MSVC 1800][64 bit] 10bit
x265 [info]: Compiling by KG7x [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)+pmode+pme
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 23 / 300 / 40
x265 [info]: Lookahead / bframes / badapt : 30 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb : 0 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.50
x265 [info]: VBV/HRD buffer / max-rate / init : 8000 / 7770 / 0.900
x265 [info]: tools: rect limit-modes rd=4 rdoq=2 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
[1.0%] 1873/187296 frames, 5.52 fps, 1540.73 kb/s, eta 9:19:48
- 837 ：823：2016/03/21(月) 21:45:05.55 ID:vZIwSY4R.net
- >>835
ソース読みをavisynth使わず読み込みをってことですか？
- 838 ：名無しさん＠編集中：2016/03/21(月) 21:58:07.85 ID:IwyEIcSu.net
- >>836
とりあえずビルドに使われてるVisual Studio 2013のランタイム入れてみたら？
配布元に↓とも書かれてるし（意味わからんけど）
Turbo on Monday February 10th, 2014 at 06:16 PM said:
Сборки сделаны на Visual C++ 2013. Для корректной работы может потребоваться библиотека Visual C++ Redistributable Packages for Visual Studio 2013:
- 839 ：名無しさん＠編集中：2016/03/21(月) 23:05:25.98 ID:diV0PO6C.net
- pmode,pmeを無効にしてみるといいよ
同じような症状出てたけど、無効にしたら落ちなくなった
- 840 ：823：2016/03/21(月) 23:23:35.03 ID:vZIwSY4R.net
- とりあえず、>>838のランタイム入れてやってみてます。
>>839はその後改善がなかったら試してみます。
- 841 ：823：2016/03/22(火) 07:06:01.47 ID:1A+V4fFh.net
- >>838
ありがとうございます。
いきなり長時間物完走しました。
何回か違うソースで試してみます。
- 842 ：823：2016/03/31(木) 22:20:13.67 ID:OoJQ2UyX.net
- 10ソースくらい試してみましたが、
無事完走するようになりました。
皆様ありがとうございました。
- 843 ：名無しさん＠編集中：2016/04/01(金) 14:07:26.74 ID:vYfELI/A.net
- てかどこのビルドも駄目だと書いてるのにMSVCが原因だなんて普通思わねえよ
- 844 ：名無しさん＠編集中：2016/04/01(金) 16:49:59.34 ID:dTL/+QgY.net
- トラブルシューティングとしてビルドに使われたVCランタイムを入れるぐらいはしてもばちは当たらない
- 845 ：名無しさん＠編集中：2016/04/02(土) 09:22:23.23 ID:CqXSpfM9.net
- >>844
お前がはじめにそういえばよかった。
834だったらすまん。
- 846 ：名無しさん＠編集中：2016/04/02(土) 09:55:23.23 ID:1E+gnV9U.net
- >844も>838も同じ人物で私だけど
態度変えすぎだろう
- 847 ：名無しさん＠編集中：2016/04/04(月) 08:51:12.73 ID:PHD6aaQD.net
- YUV420ソースをYUV444にしてエンコするメリットはありますか？
- 848 ：名無しさん＠編集中：2016/04/04(月) 08:53:20.36 ID:nVqmW/e9.net
- どうして無いと思うわけ
- 849 ：名無しさん＠編集中：2016/04/04(月) 14:52:19.93 ID:Gj1hPCli.net
- どうしてあると思うわけ
- 850 ：名無しさん＠編集中：2016/04/04(月) 19:46:56.63 ID:PHD6aaQD.net
- >>848
有るとも無いとも言ってないですよ。
ぜひ、YUV420ソースのYUV444へのエンコを解説してください。
- 851 ：名無しさん＠編集中：2016/04/04(月) 20:08:35.41 ID:GIgTDtel.net
- 自分で試せないの？
- 852 ：名無しさん＠編集中：2016/04/04(月) 20:14:10.84 ID:aOfeiP7X.net
- ファイル作って動画を見て、よくなっていたら採用、変わらないor悪くなっていたらやらない、でいいじゃない
エンコの目的なんて、自分が見るための保存用がほとんどだろうし
- 853 ：名無しさん＠編集中：2016/04/05(火) 02:19:50.59 ID:/L9IqKot.net
- 目が肥えて後になって後悔するかもしれない
という発想がどうしてないのだろう・・・
- 854 ：名無しさん＠編集中：2016/04/05(火) 03:10:52.86 ID:VRuHp+46.net
- なんでこの流れでそんなズレた発想が出てくるんだろう・・・
- 855 ：名無しさん＠編集中：2016/04/05(火) 07:24:52.25 ID:23Tspq3D.net
- 元ファイル(生TS?)も保存しておけばいいんじゃね？
- 856 ：名無しさん＠編集中：2016/04/05(火) 07:39:04.16 ID:/18GblFb.net
- エンコするために勉強する時間よりその時間で稼いでHDD買ったほうがいい
オリジナルのまま保存しとけば将来目が肥えても安心
- 857 ：名無しさん＠編集中：2016/04/05(火) 08:02:56.95 ID:PkW1ygDm.net
- 趣味を否定してやるなよ
- 858 ：名無しさん＠編集中：2016/04/05(火) 15:04:07.31 ID:9JEcOI0a.net
- 話をそらして質問者の否定ばかりで、誰も解説できない
おまら情けないな
まぁ、俺もだけどな
- 859 ：名無しさん＠編集中：2016/04/05(火) 15:54:06.00 ID:oIluhigo.net
- ソースが8ビットなんだから10ビットでエンコしても無意味って口？
- 860 ：名無しさん＠編集中：2016/04/05(火) 16:14:30.97 ID:bXKjBZbc.net
- >>850
> YUV420ソースのYUV444へのエンコ
・環境やプレーヤーによっては再生できなくなる。再生支援も効かない。
・データ量が増える。
・やるにしてもYUV420→YUV444変換で色差補間をどうすんのかとかちゃんと考えないといかんね。
やるだけアホらしいと思うけど。普通はYUV420のまま再生時にレンダラで補間させるし。
・つうことでメリットなんか無いだろ。
>>858
自演乙
>>859
そんな話は誰もしてねーと思うぜ。
- 861 ：名無しさん＠編集中：2016/04/05(火) 16:26:50.63 ID:oIluhigo.net
- 同じこと
- 862 ：名無しさん＠編集中：2016/04/05(火) 20:35:58.64 ID:9JEcOI0a.net
- >>860
妄想乙
- 863 ：名無しさん＠編集中：2016/04/05(火) 20:44:23.74 ID:+zekPSej.net
- >>856
勉強ったってオプション弄ってできたものを評価していくだけじゃん
- 864 ：名無しさん＠編集中：2016/04/05(火) 22:25:10.00 ID:DXAVhdGx.net
- 12bit エンコすんのはいいんだけど、どういう環境で見れば軽いとか綺麗とかってだれか試してるんかな
つか、みんなどのプレイヤーで見てんの？
- 865 ：名無しさん＠編集中：2016/04/06(水) 00:21:04.15 ID:gavek0iz.net
- >>864
12bitのHEVCデコードに対応してるデコーダなんてLAVくらいじゃね。
デコーダからP016でレンダラに渡すことを考えるとmadVRかMPDNあたりが必要。
LAVで12bitYUV→RGB24変換してRGBでEVR等のレンダラに渡す方法もあるけど
この場合色差補間とかがどうなるのかは知らん。
12bitは再生支援も対応しないだろうし、一般的な1667万色なPC環境では10bitで事足りるはずだし
10bitに比べてなにかメリットはあるのかね？
- 866 ：名無しさん＠編集中：2016/04/06(水) 06:58:25.58 ID:BZiOzY8Z.net
- 的はずれな事ばかり
まず試してみなよ
感動するぞ
- 867 ：名無しさん＠編集中：2016/04/06(水) 09:34:00.56 ID:oAh+1FS4.net
- x264では444円個のほうがssimはよかった
なんでかはしらんけど、x265ではそうとは言えなかった
12bitは保存用に使ってるな
- 868 ：名無しさん＠編集中：2016/04/06(水) 19:13:30.16 ID:LlUg6G6o.net
- >>866
もしかして12bitエンコ自体やったことないか、プラシーボで喜んじゃうタイプ？
- 869 ：名無しさん＠編集中：2016/04/06(水) 20:01:05.75 ID:cKZ87zcu.net
- 8bitと10itでは結構、良くなるから
10bitから12bitも多少は良くなるんじゃね
- 870 ：名無しさん＠編集中：2016/04/06(水) 21:36:40.18 ID:TIHK3iW4.net
- --aq-strength, --psy-rd, --psy-rdoqは調整次第で
大幅な容量orエンコ時間の増大なしで見た目をよくできると思うんだけど
それぞれ値を増やすとどういったところに変化が表れやすいか
教えてくれないかい
http://x265.readthedocs.org/en/default/cli.html
を読んだがpsyは読んでもよくわからんかった
- 871 ：名無しさん＠編集中：2016/04/06(水) 21:42:52.17 ID:CpSN4L84.net
- ソース： 1280x720、3501frames、8bitソースをAvisynthのf3kdbで16bitYV12化したもの
x265(1.9+88 x64)で2パスビットレート指定エンコ
--input-csp i420 --input-depth 16 --input-res 1280x720 --frames 3501 --fps 30/1
--preset medium --tune ssim --ssim --output-depth xx --pass x --bitrate xxx
300kbps
8bit： 300.77 kb/s, SSIM Mean Y: 0.9570205 (13.667 dB)
10bit： 300.30 kb/s, SSIM Mean Y: 0.9585213 (13.822 dB)
12bit： 299.67 kb/s, SSIM Mean Y: 0.9569896 (13.664 dB)
600kbps
8bit： 598.95 kb/s, SSIM Mean Y: 0.9736639 (15.794 dB)
10bit： 598.72 kb/s, SSIM Mean Y: 0.9751736 (16.051 dB)
12bit： 599.01 kb/s, SSIM Mean Y: 0.9747219 (15.973 dB)
1000kbps
8bit： 995.32 kb/s, SSIM Mean Y: 0.9803979 (17.077 dB)
10bit： 994.48 kb/s, SSIM Mean Y: 0.9815939 (17.350 dB)
12bit： 995.49 kb/s, SSIM Mean Y: 0.9818127 (17.402 dB)
2000kbps
8bit： 1982.79 kb/s, SSIM Mean Y: 0.9854730 (18.378 dB)
10bit： 1985.28 kb/s, SSIM Mean Y: 0.9870154 (18.866 dB)
12bit： 1984.48 kb/s, SSIM Mean Y: 0.9870380 (18.873 dB)
3000kps
8bit： 2974.32 kb/s, SSIM Mean Y: 0.9874125 (19.001 dB)
10bit： 2970.46 kb/s, SSIM Mean Y: 0.9888551 (19.529 dB)
12bit： 2972.63 kb/s, SSIM Mean Y: 0.9889059 (19.549 dB)
SSIMで見る限りでは、12bitは低ビットレートでは10bitに劣り、高ビットレートでも10bitと大差ないな。
- 872 ：名無しさん＠編集中：2016/04/06(水) 22:26:08.63 ID:BZiOzY8Z.net
- めくら
いや無能ってとこかな
- 873 ：名無しさん＠編集中：2016/04/06(水) 22:38:06.12 ID:cKZ87zcu.net
- >>870
自分はx265では圧縮率を求めて割とどうでもいいソースにしか使ってないからザルなテストしかしてないけど
x264ほど素直に画質に反映されず分かりづらい（まあ、それだけ優秀になってるってことなんだろうけど）
ベースになってるであろうx264の感じでは
AQ 人の肌などのアラ隠しに有用
psy-rd 動くエッジとか高周波部分が削られる
qcomp 何気に重要。大きくするとグレンから動く対象の再現性など画の完成度がとにかく高まる
だからAQはデフォ、psy系は低め、qcompは心なし上げて0.65で使ってる
最初に書いたけど画質は求めてないから期待しないで
- 874 ：名無しさん＠編集中：2016/04/07(木) 19:37:26.46 ID:5GOclDJK.net
- >>873
thx!
自分はqcompを0.75で使ってた
自分でも適当なソースで簡単な比較はしたけど、
AQ：上げると画質は向上したけど容量も増えた（x264ではそれほど増えた印象無）
psy-rd：上げると容量が少しだけ増えた（x264のほうが増加量が大きい印象）
psy-rdoq：上げるとソース由来の細かい部分が残るようになった
くらいしかわからんかった
2passでビットレート固定すると、SSIMは（見る意味があるかは置いといて）
AQとrdoqは極大値があったけど、rdは上げると下がる一方
よくわからんです
- 875 ：名無しさん＠編集中：2016/04/07(木) 20:14:01.22 ID:xaya07W/.net
- G11bitB10bitR11bitなら良いのにね。
- 876 ：869：2016/04/07(木) 21:37:16.65 ID:kTK9FIEO.net
- >>874
「だからAQは～」の行はx265での設定ね
ほぼ固定された動画だと面白いように縮むから使ってるけど
画質評価は本当に難しくなってるよね
- 877 ：名無しさん＠編集中：2016/04/08(金) 10:10:35.33 ID:Rwrntj3b.net
- littlepoxがプリセットを作ってくれてる
実写
slowerベース
http://forum.doom9.org/showpost.php?p=1760309&postcount=3402
veryslowベース
http://forum.doom9.org/showpost.php?p=1760344&postcount=3406
アニメ
http://forum.doom9.org/showpost.php?p=1760708&postcount=3442
- 878 ：名無しさん＠編集中：2016/04/08(金) 13:54:08.07 ID:uoC7bHcg.net
- キチガイ臭がするそいつ
- 879 ：名無しさん＠編集中：2016/04/09(土) 10:01:22.54 ID:Q4UbIrNX.net
- fhd以上、x265の汎用設定詰めることができる時点で普通ではない
時間と手間がハンパじゃない
- 880 ：名無しさん＠編集中：2016/04/11(月) 21:49:12.30 ID:xwAKbqwo.net
- >>877
一応アニメのを試してみた結果、普段使っている設定と同ビットレートで
比較してみたところ、見た目でもSSIMでも大きく画質が下がった
ノイズがひどい
- 881 ：名無しさん＠編集中：2016/04/11(月) 21:55:16.14 ID:I6vlHsjj.net
- 「普段使っている設定」を書かずに報告しても意味ないような・・・
- 882 ：名無しさん＠編集中：2016/04/11(月) 22:25:47.80 ID:xwAKbqwo.net
- >>881
スマン
--input-depth 16 --output-depth 10 --crf 16 --qcomp 0.75 --rc-lookahead 250
--aq-mode 3 --aq-strength 0.75 --psy-rd 1 --psy-rdoq 1.1 --rdoq-level 2
--keyint 240 --min-keyint 1 --bframes 8 --tu-intra-depth 4 --tu-inter-depth 4
--me star --subme 7 --merange 64 --rect --amp --ref 6 --max-merge 5 --weightb
--rd 4 --colormatrix auto --colorprim auto --transfer auto --qg-size 64
--lookahead-slices 0 --sao-non-deblock --no-fast-intra
比較の時はビットレート固定
- 883 ：名無しさん＠編集中：2016/04/12(火) 14:22:43.11 ID:f5lHfaTk.net
- 画像サイズとビットレートも必要だよ
- 884 ：名無しさん＠編集中：2016/04/12(火) 18:33:03.38 ID:BUSmDDzJ.net
- >>883
1280x720, 2100 kbps（←深い意味はない）
- 885 ：名無しさん＠編集中：2016/04/12(火) 19:03:31.00 ID:f5lHfaTk.net
- ソースによるけど2Mbps程度ならdeblock 0:0にしてsaoも有効化
aq/psy系も下げたほうがいい結果になりそう＞873のプリセット
あくまでx264での知見も基にした当てずっぽうだけど
- 886 ：名無しさん＠編集中：2016/04/12(火) 19:29:21.87 ID:BUSmDDzJ.net
- 同感
>>877で十分な画質（←人によるが）を得るためにはどれくらい高いbitrate
が必要になるのか
高いbitrateならデフォルトに近い設定でも十分な画質が得られるような気がする…
- 887 ：名無しさん＠編集中：2016/04/12(火) 19:34:16.49 ID:1ATzc72f.net
- >>882
・>>877の設定で出力する時にも--output-depth 10は付けたの？
・SSIMはどうやって測ったの？
・>>877のアニメというのは--tune animationを考えてみたという設定だから
refとかbframesとかmeとかその他もろもろは特に指定されてないけど、そのへんはどう設定したの？
そのへんがデフォ値のままなら>>882と比較しても意味がない気がする。
・>>882の設定ってveryslowより重そうな気もするし、--rc-lookahead 250とかになってるけど、
本当に普段この設定で使ってるの？
- 888 ：名無しさん＠編集中：2016/04/12(火) 19:56:15.84 ID:IeZ3td+Lx
- x265ってkeyintの値よりrc-lookaheadの値を大きくできるんだ
x264はkeyintの値までしか設定できなかったからそういうもんだと思ってた
- 889 ：名無しさん＠編集中：2016/04/12(火) 19:58:52.51 ID:f5lHfaTk.net
- 与えるビットレートが違えばマッチするオプションも変わるだけじゃないの
- 890 ：名無しさん＠編集中：2016/04/12(火) 20:08:09.35 ID:BUSmDDzJ.net
- >>887
・--output-depth 10は付けた
・--ssim
・書いていないところは>>882と同様
・本当に使っている
1280x720で4fps程度の速さ（仕事から帰ってくるまでに終わればいい）
2600K@4.4GHzでエンコ
- 891 ：名無しさん＠編集中：2016/04/12(火) 22:07:20.02 ID:1ATzc72f.net
- >>890
なるほど。ただ、--ssimについては、psy系を0にせずに使うと
x265 [warning]: --ssim used with psy on: results will be invalid!
x265 [warning]: --tune ssim should be used if attempting to benchmark ssim!
という警告が出るので、適切な計測結果にはなってないと思う。
- 892 ：名無しさん＠編集中：2016/04/12(火) 22:50:43.37 ID:bnbtd3T9.net
- つか、ほぼplacebo状態だな。
現状rd4の意味無いし（Currently same as 3 要するにデフォと一緒）、
rd上げるなら5。
で、そうするぐらいならpreset placeboで良いんじゃねーかと（笑
- 893 ：名無しさん＠編集中：2016/04/13(水) 19:12:35.06 ID:L8JMc4g/.net
- 手元のソースで試してみたらこんな結果だった。
ソース：1280x720@23.976fps、2152フレームのアニメOPをf3kdb(デフォ設定)で16bit化したもの
x265 1.9+88、10bit出力で2パス2000kbpsエンコ
・medium（1行目は2パス目のログ、2行目はffmpegで求めたSSIM）
encoded 2152 frames in 102.34s (21.03 fps), 2005.55 kb/s, Avg QP:22.04
SSIM Y:0.987640 U:0.986022 V:0.986031 All:0.987102 (18.894759)
・slow
encoded 2152 frames in 286.04s (7.52 fps), 2004.33 kb/s, Avg QP:22.20
SSIM Y:0.988205 U:0.985980 V:0.985995 All:0.987466 (19.019040)
・slower
encoded 2152 frames in 904.10s (2.38 fps), 2010.01 kb/s, Avg QP:22.20
SSIM Y:0.988307 U:0.986136 V:0.986171 All:0.987590 (19.062166)
・veryslow
encoded 2152 frames in 1348.27s (1.60 fps), 2006.79 kb/s, Avg QP:22.52
SSIM Y:0.988313 U:0.986247 V:0.986282 All:0.987630 (19.076316)
・>>882
encoded 2152 frames in 721.53s (2.98 fps), 2005.88 kb/s, Avg QP:22.44
SSIM Y:0.988380 U:0.986515 V:0.986619 All:0.987776 (19.127808)
・>>882に>>877のアニメ設定を上書き
encoded 2152 frames in 953.88s (2.26 fps), 2006.71 kb/s, Avg QP:23.01
SSIM Y:0.986061 U:0.984168 V:0.984164 All:0.985429 (18.365247)
- 894 ：名無しさん＠編集中：2016/04/14(木) 06:23:31.29 ID:SmTLnnP5.net
- 検証乙
SSIMを見る限り、>>882はveryslowより画質が良くslowerより早い
>>877を適用することでmediumより画質が悪くslowerより遅くなる
という認識でいいのかな？
- 895 ：名無しさん＠編集中：2016/04/14(木) 08:54:23.53 ID:TL0trVBZ.net
- ビットレート盛ったら（crf 20以下？）綺麗になると思う
- 896 ：名無しさん＠編集中：2016/04/14(木) 10:36:09.43 ID:uaVnCBhc.net
- ffmpegのssimの0.0001台の違いて見た目どんな違いなんだろう？
誰か解説頼みます。
- 897 ：名無しさん＠編集中：2016/04/14(木) 23:43:40.37 ID:NwnHdn04.net
- 気にしたらハゲ
- 898 ：名無しさん＠編集中：2016/04/14(木) 23:47:05.40 ID:i5ZA7JyZ.net
- 自分が良いと思ったセッティングでいいじゃない。
アニメなんかは誰に見せるわけでも無いんだし。
- 899 ：名無しさん＠編集中：2016/04/15(金) 00:44:21.13 ID:+Fs+OHLX.net
- --rc-lookahead 250 って怖ろしくメモリ食うんじゃないか？ｗ
40から80に上げただけでも1.4Gから2.4Gに跳ね上がってたのに
- 900 ：名無しさん＠編集中：2016/04/15(金) 01:48:34.93 ID:KWIKv7Io.net
- 解像度などにもよるけどかなり食う
- 901 ：名無しさん＠編集中：2016/04/15(金) 01:58:08.47 ID:Vj0XVi1o.net
- ちょっと試してみたけど、>>893のサンプルだと
slower（-rc-lookahead 30） → 600MB
>>882（-rc-lookahead 250） → 2.6GB
だな。
- 902 ：名無しさん＠編集中：2016/04/15(金) 01:59:21.15 ID:pgwZJlOQ.net
- そういえば初期のx265ってメモリバカ食いしてたよね
- 903 ：名無しさん＠編集中：2016/04/15(金) 03:49:21.78 ID:G5Tu0V3Z.net
- メモリ食うだけで画質が上がるんなら数字上げてもいいんじゃないかな
メモリ足りないなら仕方ないけどね
- 904 ：名無しさん＠編集中：2016/04/15(金) 14:54:39.12 ID:i2BOyiEg.net
- >>893
リンク先のスレ読むとcffで使えと書いてあるぞ
- 905 ：名無しさん＠編集中：2016/04/15(金) 15:51:38.35 ID:R0iR/RQZ.net
- >>904
cffってなに？crfのこと？
リンク先というのは>>877のことだと思うけど、crfで使え（biｔrate指定じゃ駄目）なんて書いてないと思う。
- 906 ：名無しさん＠編集中：2016/04/15(金) 21:13:40.04 ID:v5i5tBse.net
- 今時CBRなんてナンセンス
- 907 ：名無しさん＠編集中：2016/04/15(金) 23:16:50.52 ID:xWoGZXDA.net
- 流れも読まない上にCBRってお前・・・
- 908 ：名無しさん＠編集中：2016/04/15(金) 23:31:22.66 ID:WL/mTNMT.net
- ﾈﾀﾆﾏｼﾞﾚｽ(・∀・)ｶｺﾜﾙｲ!!
- 909 ：名無しさん＠編集中：2016/04/16(土) 22:50:58.36 ID:FapX/LQs.net
- 画質/負荷の効率が良いオプションって各preset間で
値が変わったり追加されたりするやつでいいのかな
ただし重いpresetに行くほど変化しているオプションの効率が悪くなるとかあるのかな
- 910 ：名無しさん＠編集中：2016/04/16(土) 23:15:07.78 ID:RIWYlU/O.net
- 動き検索の重要度はsubme ＜ meだって猫さんが書いてたから
x265もそうだと思う
それとBフレやrefの枚数も3～4ぐらいでセーブしとくのもエンコ負荷の低減に役立つと思う
- 911 ：名無しさん＠編集中：2016/04/17(日) 16:13:38.77 ID:E1zy7U5k.net
- >>905
過去レスよく読め
- 912 ：名無しさん＠編集中：2016/04/17(日) 16:34:11.64 ID:SQT/cZ/R.net
- >>911
お前さんが>>906と同一人物で「いまどきbitrate指定エンコなんてやる奴いねーよ」とでも思ってるなら
>>893が「同一ビットレートでのSSIM比較」という目的で行われたことを全く理解してないことになるが・・・。
- 913 ：名無しさん＠編集中：2016/04/18(月) 13:09:32.53 ID:4454Srxg.net
- 必死感漂ってるな
残念だけど、>>906じゃないし、用途によってはcbrを使う人がいるのは誰でもわかっていること
littleはvbrの設定を晒してるんだから、cbrでssim比較しても無意味
まぁ、妄想と決めつけが激しく頭が悪くても、がんばって行きろ
- 914 ：名無しさん＠編集中：2016/04/18(月) 14:53:46.23 ID:xvx3IXAG.net
- お前ら優位に立とうとする言葉選び好きだよな
- 915 ：名無しさん＠編集中：2016/04/18(月) 15:38:14.70 ID:ZiaZImZR.net
- >>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味」
の根拠はなに？
・>>877の上２つのリンクには--crfも含まれてるけど、>>893で使った３つ目のリンクは
--tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
・「CBRの幻想」とかx265のhelpの--bitrateの説明とか読んだほうがいいような気がする。
- 916 ：名無しさん＠編集中：2016/04/18(月) 16:55:07.97 ID:4454Srxg.net
- >>915
>>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味じゃない」
の根拠はなに？
> --tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
思うのは自由だよ。でも、littleの一連のレス読んでから判断してね。
>・「CBRの幻想」とか
そんなこと言ってないよ。しっかり妄想と現実の区別してね。
まずは丁寧に文を理解することを習得しようね。短い文だから難しくないよ。
ｶﾞﾝｶﾞﾚ
- 917 ：名無しさん＠編集中：2016/04/18(月) 17:09:18.40 ID:ZiaZImZR.net
- ああ、やっぱり説明も話もまともに出来ない人だったか・・・お疲れさまでした。
- 918 ：名無しさん＠編集中：2016/04/18(月) 17:35:42.08 ID:no/AiHFv.net
- >>914
お前らと言うけど2レスだけだよ
- 919 ：名無しさん＠編集中：2016/04/18(月) 18:51:38.96 ID:Sn6HnjyG.net
- >>913
cbr≠abr であり、>>893はabrだと思う
abrはvbrで出来上がるものの平均ビットレートを指定してエンコじゃないのかな。。
ちなみにcbrの用途って何があるの？放送局？
- 920 ：名無しさん＠編集中：2016/04/18(月) 19:06:32.01 ID:ZiaZImZR.net
- 割と知られてるページだと思ってたからタイトルしか書かなかったけど
>>916には通じなかったみたいだし、「"CBRの幻想"でググれ」と書くべきだったとちょっと反省。
- 921 ：名無しさん＠編集中：2016/04/19(火) 09:54:12.07 ID:YZY7DcaM.net
- >>920
？俺はcbrの善し悪しには何も触れてないぞ。話しのすり替えは止めようね。
短い文なんだからきちんと理解できるようになろうね。
自分の落ち度を認めず他の内容を無視するのも止めようね。
- 922 ：名無しさん＠編集中：2016/04/19(火) 11:48:28.42 ID:7vkH9RtK.net
- 好きに使ったら良いのに、自分が良く使う設定に固執しすぎなんだよね。
- 923 ：名無しさん＠編集中：2016/04/19(火) 11:53:32.50 ID:CfB8B13z.net
- 近代的なビデオコーデックで真のCBRなんて不可能っていう「CBRの幻想」って解説記事があるの
つまり1パスビットレート指定でも動作はVBRだと揚げ足を取られてるわけ
個人的にはcrf指定でも指定値が大きければ画質は悪くなり
ビットレート指定でもビットレートを大きく盛れば画質は良くなるわけだから
あまり意義のある言い争いじゃないと思う
- 924 ：名無しさん＠編集中：2016/04/19(火) 16:02:39.82 ID:filiPvCp.net
- もう何年前に読んだか忘れたけど、圧縮前に圧縮後予定ファイルサイズから逆算して
正確な圧縮品質を指定することは不可能かつ正確にファイルサイズを合わせることも不可能だから
って奴だよな
- 925 ：名無しさん＠編集中：2016/04/19(火) 17:28:26.53 ID:YZY7DcaM.net
- >>919
cbr≠abrなのはしってるよ
同一ビットレートで、ときてたからcbrといっただけですう
だから、handbrakeはサイズ指定のサポート止めたしね
907=910=918?
- 926 ：名無しさん＠編集中：2016/04/19(火) 17:40:38.84 ID:ILdf6rCX.net
- 一応言っておくと俺はSSIMの計測結果を貼っただけであって、>>877や>>882とは別人。
CBRの件は別に揚げ足じゃなくて、helpでもABRという表現が使われてるし、
「CBRの幻想」の記事も踏まえて「CBR」という表現はあまり使わないほうがいいと思っただけ。
>>921にはまったく伝わらなかったみたいだし、なんか変な言い訳してるけど・・・。
よく見ると>>916は
「cbrでのSSIM比較が無意味ではないと主張する根拠はなに？」
と逆に問い返してるんだね。コピペミスかと思ったわ・・・。
俺は単に>>913の
・>>877はvbr（--crf）用の設定だ
・だからcbr（--bitrate）でSSIM比較しても無意味
という２つの主張の根拠がわからなくて知りたかっただけ。
これまで特に気にせずに２パスエンコも利用してSSIMを調べたり貼ったりしてたんだけど、
--bitrateだとうまく働かないオプションとかあるんだっけ・・・？
>>925はこれ以上相手にしても徒労に終わりそうだし、もし誰かわかるなら教えてほしい。
- 927 ：名無しさん＠編集中：2016/04/19(火) 17:44:29.70 ID:ILdf6rCX.net
- ついでに参考までに>>893と同じソースでの--crfでのSSIM計測結果
medium(--crf 20)
encoded 2152 frames in 110.22s (19.53 fps), 1547.26 kb/s, Avg QP:24.17
SSIM Y:0.986408 U:0.984554 V:0.984501 All:0.985781 (18.471442)
>>877(Doom9)のアニメ設定(--crf 20)
encoded 2152 frames in 389.29s (5.53 fps), 2371.26 kb/s, Avg QP:21.66
SSIM Y:0.986468 U:0.984746 V:0.984787 All:0.985901 (18.508171)
>>882(--crf 20)
encoded 2152 frames in 791.84s (2.72 fps), 1989.61 kb/s, Avg QP:22.51
SSIM Y:0.988334 U:0.986457 V:0.986566 All:0.987727 (19.110332)
>>882に>>877のアニメ設定を上書き(--crf 20)
encoded 2152 frames in 1106.11s (1.95 fps), 2281.76 kb/s, Avg QP:21.80
SSIM Y:0.986605 U:0.984842 V:0.984886 All:0.986025 (18.546500)
---
medium(--crf 27)
encoded 2152 frames in 96.01s (22.42 fps), 705.81 kb/s, Avg QP:31.89
SSIM Y:0.978727 U:0.976208 V:0.975609 All:0.977788 (16.534075)
>>877(Doom9)のアニメ設定(--crf 28)
encoded 2152 frames in 248.13s (8.67 fps), 857.42 kb/s, Avg QP:30.47
SSIM Y:0.978540 U:0.975270 V:0.974700 All:0.977355 (16.450309)
medium(--crf 28)
encoded 2152 frames in 98.21s (21.91 fps), 636.98 kb/s, Avg QP:32.96
SSIM Y:0.976924 U:0.974559 V:0.973803 All:0.976010 (16.199657)
- 928 ：名無しさん＠編集中：2016/04/19(火) 17:58:21.32 ID:CfB8B13z.net
- 微妙に着眼点と主張がかみ合ってないからお互いにスルーするが吉
- 929 ：878：2016/04/19(火) 18:00:28.75 ID:0e3x1/oL.net
- >>927
rdを4→6にするだけで画質が格段に良くなった。
だけどかなり重くなったので>>882と同等のエンコ速度を維持できるよう
画質/負荷の悪いものを削ってったら結果的にpreset slowerに近くなった。（下記はslowerで書き直し）
もしまたエンコする機会があったら下記への変更をよろしくです。
--input-depth 16 --output-depth 10 --preset slower --crf 16 --qcomp 0.75
--rc-lookahead 250 --aq-mode 3 --aq-strength 0.75 --psy-rd 1
--psy-rdoq 1.1 --keyint 240 --min-keyint 1 --no-amp --colormatrix auto
--colorprim auto --transfer auto --qg-size 64 --lookahead-slices 0
--sao-non-deblock --limit-refs 3
- 930 ：名無しさん＠編集中：2016/04/19(火) 18:56:00.56 ID:ILdf6rCX.net
- >>929
・>>893と同条件（2pass2000kbps）
encoded 2152 frames in 844.63s (2.55 fps), 2005.71 kb/s, Avg QP:21.93
SSIM Y:0.988783 U:0.986883 V:0.986995 All:0.988168 (19.269524)
・>>927と同条件（--crf 20）
encoded 2152 frames in 865.28s (2.49 fps), 1945.21 kb/s, Avg QP:22.13
SSIM Y:0.988679 U:0.986731 V:0.986839 All:0.988048 (19.225614)
- 931 ：名無しさん＠編集中：2016/04/19(火) 19:20:19.87 ID:0e3x1/oL.net
- >>930
早速のエンコありがとう。
ちょっと重くなってしまったみたいだね。スマン
でも、画質はそれなりに改善したように見えるね。
- 932 ：名無しさん＠編集中：2016/04/19(火) 21:31:48.09 ID:CfB8B13z.net
- 今のx265の場合、デフォのcrf値が大きすぎるんだよな
プリセット作るにしても決めきられない感じ
- 933 ：名無しさん＠編集中：2016/04/20(水) 10:32:47.35 ID:/W4Johvo.net
- プリセットなんてmedium(デフォルト)な時点でx264超えてるんだからどうでもいいよ
後は好きなcrf値を設定すればOK
なんか色んな設定やパラメータいじくり回すx264時代の因習に囚われてる人いるようだけどｗ
- 934 ：名無しさん＠編集中：2016/04/20(水) 10:52:36.60 ID:O3XwBTuO.net
- 4K60Pがリファレンスなのにね
- 935 ：名無しさん＠編集中：2016/04/20(水) 14:21:23.87 ID:9swemZrS.net
- プリセットじゃなくプロファイルだった
- 936 ：名無しさん＠編集中：2016/04/20(水) 19:29:17.58 ID:klJmlwQn.net
- >>933
x264でも重ための設定でAQやpsy-rdなどを調整したらx265の
単純なmediumになら画質で勝るよ。
つまり、設定次第だと思う。
- 937 ：名無しさん＠編集中：2016/04/20(水) 20:09:39.34 ID:GUTooAcL.net
- さわらないほうが良いタイプだと思うよ
- 938 ：名無しさん＠編集中：2016/04/20(水) 21:34:42.31 ID:/W4Johvo.net
- >>936
x265のプリセットを１段階上げればいいだけでしょｗ
- 939 ：名無しさん＠編集中：2016/04/21(木) 01:14:11.61 ID:GimnWLrM.net
- レベルを上げて物理で殴ればいい
- 940 ：名無しさん＠編集中：2016/04/21(木) 03:00:03.58 ID:LQaBaBJx.net
- レベルといえばお前らレベル指定とかしないん？
- 941 ：名無しさん＠編集中：2016/04/21(木) 08:48:25.19 ID:s5ZQAH1b.net
- 携帯視聴やゲーム機家電視聴などを弾きたい時に
- 942 ：名無しさん＠編集中：2016/04/21(木) 22:30:46.71 ID:43CTREQW.net
- 最大ビットレートは規格に合わせて指定してる
他のオプションまでは把握してないからデフォのまま
- 943 ：名無しさん＠編集中：2016/04/23(土) 19:00:20.96 ID:p08WM9kP.net
- ABRのSSIMを貼った人は何が言いたかったのだろう
- 944 ：名無しさん＠編集中：2016/04/23(土) 19:41:54.17 ID:GVwq/FMD.net
- 結論を言うと荒れるから何も言わないのかな
数字だけで判断するなとか言うやつが出てくるかもしれないし
- 945 ：名無しさん＠編集中：2016/04/23(土) 20:22:56.70 ID:1ED72ZaJ.net
- >>943
ただの参考値として貼っただけだよ。
>>926でも書いたけど、なんで「ABR（2pass --bitrate）のSSIMは無意味」だと思うの？
ちゃんとした根拠があるなら知りたいんだけど。
- 946 ：名無しさん＠編集中：2016/04/23(土) 20:50:47.52 ID:VX0ubDbv.net
- 少なくとも俺は --cfr でサクッとやってしまうから abs でビットレート固定されても参考にはしないかな。
逆に abs でエンコしてる人になら参考になると思う。
要は自分で取捨選択を適切にしていればいいだけであって、人に文句を言うのはお門違いだと思うよ。
- 947 ：名無しさん＠編集中：2016/04/23(土) 21:03:52.97 ID:GVwq/FMD.net
- cfrやabsはネタかな
オプション検討しているときにcrfを使うとビットレートが
大幅に変わってしまい、オプションの良し悪しが分からなくなる。
最終的にcrfでエンコするにしてもオプション検討においては
ABRでの比較は十分に参考になると個人的には思う。
- 948 ：名無しさん＠編集中：2016/04/24(日) 12:02:05.68 ID:ou5067T+.net
- >>945
「ABR（2pass --bitrate）のSSIMは無意味じゃない」ちゃんとした根拠があるなら知りたいんだけど。
- 949 ：名無しさん＠編集中：2016/04/24(日) 12:06:44.59 ID:h82NYOq7.net
- 指定ビットレートが低すぎなのはあると思う
- 950 ：名無しさん＠編集中：2016/04/24(日) 12:25:41.70 ID:szqA3nvc.net
- 指定ビットレートの適正値はソース、解像度、好みによって変わりそう
- 951 ：名無しさん＠編集中：2016/04/25(月) 16:45:47.07 ID:OGPz4ITg.net
- ABRの人、doomのレスを理解できてないと思った
ここのレスの理解も怪しい
オプションの理解も
- 952 ：名無しさん＠編集中：2016/04/25(月) 19:28:56.39 ID:nvGgjPd+.net
- >>951
ABRでのSSIM計測が無意味だと言ってる人にその言葉をほぼそのまま返したい。
こっちはABRでのSSIM計測が無意味と言われた根拠が全くわからないから
教えてくれと質問してるのに、返ってくるのは山彦質問返しや根拠不明でかみ合わない主張や嘲弄だけ。
「お前は理解してないお前は理解してない」と念仏みたいにブツブツ呟き続けられても気味が悪いだけで
こっちは何が理解できてないのかさっぱりわからないし、進展がなくてスレにとっても迷惑だと思うよ。
スルーできてない俺も迷惑だろうけど。
・SSIMは画質（というかソースとの類似度）指標数値の１つだがあくまでも参考値であり
最終的には自分の目で見て決めたほうがよいというのは大前提。
・ABR（2pass --bitrate）でSSIMを計測するのは設定の違いによる
圧縮効率（画質・容量比）や速度を比較するため。
（数値的には、同一ビットレートでSSIMが大きいほうが圧縮効率が高いと評価できる）
・VBR(--crf)でSSIM計測してもいいけど、ビットレートもSSIMもばらけるので
パッと見てどちらが良いのか評価するのが難しい。
ビットレートやSSIMが同じくらいになるcrf値を探すのは面倒。
・720pで試したのは単にあまり時間をかけたくなかったから。
・2000kbpsで計測したのは、元ファイルが重め設定のx264 --crf20で約2500kbpsだったから。
ビットレート高めだと差がわかりにくくなるので、やや低めのビットレートで比較して
差をわかりやすくすることを意識した。
・>>893や>>927の結果だけ見ると、Doom9の設定（>>877のアニメ）は有効性が感じられない。
・ABRでのSSIM計測が無意味だという主張の根拠は全くわからないので教えてほしい。
・Doom9の設定が--crf向けだという主張の根拠も全くわからないので教えてほしい。
・Doom9のレスを理解できてないという主張の根拠も全くわからないので教えてほしい。
・俺個人のオプションに関する理解が浅いのは事実だから解説があると喜ぶよ。
これがこちらの現状なので、理解がおかしいというなら具体的な指摘を頼む。
スルーできてなくてごめん。> スレ住人
具体的な説明がされない限り、以後スルーするね。
- 953 ：名無しさん＠編集中：2016/04/25(月) 20:44:32.37 ID:cQiwXoCT.net
- >>951
私も>>952と同程度の理解なので、何がどう理解できていないのかを教えてほしい。
根拠を示すことができず否定するだけの無知な人ではないことを祈りつつ。
- 954 ：名無しさん＠編集中：2016/04/25(月) 20:59:50.91 ID:QMvVZfm8.net
- 過去には、crfでSSIM比較するなビットレート指定しろ、って人もいたしどうしろと
- 955 ：名無しさん＠編集中：2016/04/25(月) 21:01:33.14 ID:QZda0fQA.net
- 否定だけってのは反応に困るよね
品質指定だと瞬間的なビットレートはかなり高くなるから品質にはかなり有利
自分の経験でXvid ビットレート指定で350MBと、品質指定の250MBのファイルで後者の方が綺麗（前者は動きの激しい箇所でブロックノイズ多発）で
品質指定はそれぐらい画質に有利だと思う
でx264でも画質を求めたらcrf下げてデブロックフィルタも弱めてpsyを強めたりして（自分は）
そのcrf値が小さいとき用のオプションをcrfが大きいときに使うとやっぱりアラが出る
なので高画質向けオプションを評価するときは、コーデックの性能をもっと引き出せる好条件でやって欲しいなとは思う
（ネタだと思われそうだけど自分も教えて欲しいな>>951）
- 956 ：名無しさん＠編集中：2016/04/25(月) 21:08:01.55 ID:mYE/Sg/n.net
- 一人で何やってんスか
- 957 ：名無しさん＠編集中：2016/04/25(月) 23:17:22.98 ID:xf7dz0xUo
- は？
- 958 ：名無しさん＠編集中：2016/04/26(火) 00:17:01.11 ID:yVx5x6Ll.net
- いまだに勘違いがはびこってるようだけど
2passってのは一回エンコしてみてその結果から目標ビットレートに近づくように自動でcrfを調整してもう一度エンコしてるだけのことだろ
最終的なビットレートが同じなら手動でcrfを指定しようが2passでやろうが画質に違いは出ないよ
- 959 ：名無しさん＠編集中：2016/04/26(火) 03:30:54.19 ID:P6dH9VcC.net
- CRFならlevelが許す限りの範囲でビットレートを変動できる
ビットレートを指定するが故の過剰品質も抑制できる、って理解だが
どっちにしろVBVでレート制御が入るからそっちの設定だけ詰めればCRFで良いような気がする
- 960 ：名無しさん＠編集中：2016/04/26(火) 18:29:14.73 ID:H6GEQXQr.net
- >>958
HEVCではそうなのか？
書いてないけど>955の「Xvid ビットレート指定で350MB」は「Xvid ビットレート指定2Passで350MB」
- 961 ：名無しさん＠編集中：2016/04/26(火) 20:45:29.80 ID:xOye6Bx8.net
- ABRの人、自演がんばれ
- 962 ：名無しさん＠編集中：2016/04/27(水) 01:45:52.17 ID:ccoJ1QZy.net
- Xvidとか古すぎて話についていけないわ
Xvidとx26Xとじゃレートコントロールの方式が違うんだよ
- 963 ：名無しさん＠編集中：2016/04/27(水) 06:21:06.02 ID:SeExodLv.net
- x265の更新がピタっと止まっているんだけど、何かあったのかな
- 964 ：名無しさん＠編集中：2016/04/27(水) 08:04:29.24 ID:rBBpLPal.net
- 春休みは終わったんだよ、ヒキコモリ君
- 965 ：名無しさん＠編集中：2016/04/27(水) 09:32:20.93 ID:7jGMhriN.net
- x265の更新していたのは、日本の学生だったか…
- 966 ：名無しさん＠編集中：2016/04/27(水) 09:34:20.09 ID:4Bx6XeNC.net
- また一気に更新くるんじゃないの
- 967 ：名無しさん＠編集中：2016/04/27(水) 12:17:51.54 ID:q1CqmRwh.net
- >>952
>具体的な説明がされない限り、以後スルーするね。
実行しろ
わかってないことがわかってないのにわかった気になってゴリ押しする奴に誰が説明するかよ
他人が自分のために1から10まで手取り足取り説明してくれるのが当然という発想かよ、ゆとりか？
自覚のないうぬぼれの激しいばか
レス見てるだけでイライラした，蹴り入れたくなる
もう、ここに来るな
- 968 ：名無しさん＠編集中：2016/04/27(水) 12:56:15.58 ID:ccoJ1QZy.net
- こっそり教えてあげるけどお前の方が迷惑だよ
- 969 ：名無しさん＠編集中：2016/04/27(水) 18:04:47.37 ID:9yLxz2J0.net
- >>967
邪魔だからもう来ないで
- 970 ：名無しさん＠編集中：2016/04/27(水) 19:33:10.69 ID:MXOYRBVo.net
- 一部の動画の最初の数秒だけノイズだらけになるのって、エンコするときの設定で回避できますか？
- 971 ：名無しさん＠編集中：2016/04/27(水) 20:11:42.22 ID:U6riuRT4M
- キーフレームでカットせずに編集された動画とか？
- 972 ：名無しさん＠編集中：2016/04/27(水) 19:59:53.45 ID:O1aRnOt/.net
- 一部動画って何を差すのか知らないけど最初だけならそこをカットすりゃいいんでないかい
- 973 ：名無しさん＠編集中：2016/04/27(水) 20:47:20.64 ID:vYGeTekE.net
- >>970
それはx265は関係なく、元動画がおかしいか、エンコード前のデコード処理に問題があるか、
エンコード後の再生に使うデコーダに問題があるだけじゃね？
- 974 ：名無しさん＠編集中：2016/04/28(木) 11:56:00.94 ID:VAWFmSIl.net
- >具体的な説明がされない限り、以後スルーするね。
実行できないね
やっぱり、みんなが思ったであろう口先番長
- 975 ：名無しさん＠編集中：2016/04/29(金) 22:22:26.51 ID:Qjv/odTt.net
- x264 r2692(8/10bit)、x265 1.9+138(8/10/12bit)で各プリセットの計測テストしたので置いとく。
プリセットのみ（一部のデータは--tune等の調整つき）
・エンコード時間： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3305.jpg
・SSIM/bitrate相関図： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3306.jpg
・SSIM/bitrate相関図(medium以上)： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3307.jpg
--tune ssim付き
・エンコード時間： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3308.jpg
・SSIM/bitrate相関図： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3309.jpg
- 976 ：名無しさん＠編集中：2016/04/29(金) 23:06:35.59 ID:hM8i6t7l.net
- >>975
乙乙
x265の8bitと10bitの差って凄いのね
- 977 ：名無しさん＠編集中：2016/04/30(土) 03:24:21.10 ID:icRfs4QB.net
- 力作ですごいけど相関図が見づらい・・・
- 978 ：名無しさん＠編集中：2016/04/30(土) 08:19:14.01 ID:iwbiPODt.net
- tab使いは頭悪いから
- 979 ：名無しさん＠編集中：2016/04/30(土) 10:36:27.87 ID:/y9WItAV.net
- わがまま言えば実写が欲しかった
- 980 ：名無しさん＠編集中：2016/04/30(土) 14:19:43.42 ID:JnFxQH0Q.net
- >>958
前にTSからcrfでエンコして結果、２０００kbsくらいで仕上がったんだけど
その後に同じTSを２passで２０００kbsでエンコしたら残り１分くらいから最後までブロックノイズが乗ったんだ
たまたまかと思ってもう一回２passでやったらやっぱり同じようにブロックノイズが乗った
なんでやろう？
それ以来２passは信用してないんだけど
- 981 ：名無しさん＠編集中：2016/05/01(日) 01:06:55.28 ID:OwT/pRKY.net
- >>980
crf エンコして 2,000kbps ってそれ平均じゃないかな? vbr だからシーンによってビットレートは変わるよ。
2pass 2,000kbps でノイズでるんならそれ、ビットレート足りなかったんだろ。
- 982 ：名無しさん＠編集中：2016/05/02(月) 13:48:49.91 ID:3M7zOLf9.net
- >>981
2passが>>958の主張する挙動の通りなら>>980の現象は説明つかない
ってことを言いたいんじゃないの
- 983 ：名無しさん＠編集中：2016/05/02(月) 17:17:48.15 ID:IVu6sEQK.net
- >>958は基本的には正しいから可能性は4つだな
① x265のコードにミスがある／あった
② >>980の比較方法にミスがあった
③ x265の2nd-passの自動crf調整アルゴリズムの性質上、実際にそういったことが稀に起こり得る
④ >>980の話は嘘か誇張である
でも決め手となる詳細な情報が何一つないからあんまリアクションできないわな
- 984 ：名無しさん＠編集中：2016/05/02(月) 17:20:24.76 ID:NFZmJHH5.net
- １パス目の解析ファイルが正常に作れてなかったとか？
- 985 ：973：2016/05/02(月) 20:19:49.45 ID:GTGVqrYC.net
- >>983
冷静な分析だと思います
嘘か誇張は絶対ないです
1パス目の解析ファイルの作り方がまずかったのか？
x264と同じやり方で2passでやってたんだけど・・・
元のTSはインターレースのなかにPV映像の30pが混じった映像で
それをQTGMCで60pにしてました
ブロックノイズはその30pの部分に載ってました（微妙じゃなくて明らかなやつです）
- 986 ：名無しさん＠編集中：2016/05/02(月) 20:43:03.56 ID:MFklek4b.net
- 自分の言ったことくらい実行しろ
- 987 ：名無しさん＠編集中：2016/05/02(月) 23:18:21.04 ID:3M7zOLf9.net
- bitrateを指定する以上2passもCBR≒ABRの発展型でしかないと思うんだがな
crfオプションを指定しない以上エンコーダは品質目標を知りえないわけで
アグレッシブに圧縮できるシーンに出くわしたときCRFほどの働きはできないだろう
- 988 ：名無しさん＠編集中：2016/05/03(火) 11:08:09.34 ID:IEaoSNtT.net
- なんだ？この自演臭い2pass議論モドキ
- 989 ：名無しさん＠編集中：2016/05/03(火) 16:25:11.30 ID:Vh9buT2E.net
- BitrateViewerで違いを見てみようかと思ったら、H.265には対応してないんだった。
古いソフトだから当たり前だけど、H.265に対応してる同様のソフトってないのかな。
- 990 ：名無しさん＠編集中：2016/05/03(火) 17:53:45.39 ID:fYHQmMJu.net
- MPC-hcｆｒで代用できるんじゃないか？
- 991 ：名無しさん＠編集中：2016/05/03(火) 19:04:14.23 ID:Vh9buT2E.net
- >>990
ググってみたけどなんのことかわからなかった
- 992 ：名無しさん＠編集中：2016/05/03(火) 19:07:46.37 ID:Vh9buT2E.net
- とりあえず980過ぎてるので次スレ立ててくる
- 993 ：名無しさん＠編集中：2016/05/03(火) 19:11:22.18 ID:Vh9buT2E.net
- 次スレ
x265 rev3
http://echo.2ch.net/test/read.cgi/avi/1462270195/
- 994 ：名無しさん＠編集中：2016/05/03(火) 19:40:13.42 ID:fYHQmMJu.net
- >>991
ごめん
mpc-hcって書こうとしてたんだけど変になってた
>>993
乙
- 995 ：名無しさん＠編集中：2016/05/03(火) 20:06:53.73 ID:IGe9RuRo.net
- >>993
おつ
- 996 ：名無しさん＠編集中：2016/05/03(火) 20:11:50.14 ID:fYHQmMJu.net
- 昼にエンコードしたものをmpc-hcで比較（左の数字は平均/現在）
ソースはavisynthで"FreezeFrame(9000,30000,9000)"で作った静止動画11分と、
トリムだけした1分の動画をaviutlで連結読みしてguiEXでエンコード
frozenは頭だし状態で再生開始20秒目
moveは11m50sから10秒間再生した12:00地点
crf 23
frozen 119/20
move 1203/1435
230kbps 2pass
frozen 160/21
move 897/1047
結果は、frozenでは平均に近づいて2passのほうが高め、moveでも平均に近づき低め
12m過ぎたあたり（スクロールしてる）のビットレートは、crfモードでは1400kbpsを出すこともあるのにたいし
2passでは1100kbpsを超えることは無かった
- 997 ：名無しさん＠編集中：2016/05/03(火) 23:36:26.14 ID:umRZY+Hf.net
- だってファイルサイズが違うんでしょ？
- 998 ：名無しさん＠編集中：2016/05/04(水) 00:07:59.51 ID:2HnXwOPY.net
- 四捨五入してオマケしたから同じではないが
crf23が32.4MB
2passのが36.6MB
- 999 ：名無しさん＠編集中：2016/05/04(水) 00:26:46.45 ID:2HnXwOPY.net
- ちなみにちゃんとcrf23でエンコ後プロパティでビットレート調べて
2passエンコ登録時にそのビットレートでエンコしてる
- 1000 ：名無しさん＠編集中：2016/05/04(水) 01:38:01.15 ID:I2MMBFA3.net
- 実際問題サイズをぜんぜん揃えられてない状態で「ちゃんと」と言われましても・・・
とりあえず言えるのは、実際の平均ビットレートはx265出力(GUI)Exのログで調べるようにした方がいいってことと
ABRには多かれ少なかれ仕上がりサイズのズレは付き物なんだから、ズレたなら--bitrateの値を微調整してってこと
- 1001 ：名無しさん＠編集中：2016/05/04(水) 05:47:44.59 ID:JEe8vmea.net
- >>993
乙
- 1002 ：名無しさん＠編集中：2016/05/04(水) 09:30:32.92 ID:RFD4/mYP.net
- >>996
そういう結果になるのはみんなわかってることだけど・・・
>>998
1割以上サイズが違うもの比較しても意味ない
自覚の無いバカ、張り切ったバカほど迷惑邪魔なものは無いとは良く言ったものだ
- 1003 ：989：2016/05/04(水) 10:14:48.56 ID:2HnXwOPY.net
- 言っとくけど自分は2passが自動crf調整だと言った人ではない
実験結果から何が分かるかぐらい言われなくても分かるだろうに・・
- 1004 ：名無しさん＠編集中：2016/05/04(水) 14:09:38.05 ID:I2MMBFA3.net
- うむ、俺も似たような実験をしてある程度は現象を再現できた
>>1002
そういう結果とは具体的にどういう結果のこと？それが起きるのはなんでなのか教えて
- 1005 ：名無しさん＠編集中：2016/05/04(水) 16:12:16.98 ID:2HnXwOPY.net
- ビットレート指定はcrfよりビットレートのふり幅が小さく
HEVCの2Passも既存コーデックの2passと同じ動作だった
- 1006 ：名無しさん＠編集中：2016/05/04(水) 16:41:13.54 ID:pfZ/a3PA.net
- エンコードログに出る平均ビットレートの遷移をグラフ化するとこんな感じになった。
静止画＋動画： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3313.png
動画： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3314.png
やっぱり>>958は間違いで、crfと2passのレートコントロール手法は別物なのでは。
- 1007 ：名無しさん＠編集中：2016/05/04(水) 17:11:10.81 ID:RFD4/mYP.net
- マジレスすると、答えはこのレスに出てるのにそれすらわからず騒いでるだけ
こんなの誰が相手にする？
明らかに初歩的なことすらわかってないのにわかった気になって
わかりきってることを謎解きをやってるだけ
次スレでは、もうその話しは止めろ
- 1008 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
- 1009 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1009
274 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200