15/03/22 23:28:33.87 nSHZu9mq.net
暇じゃないからバッチに投げるのにねー(´･ω･｀)
302:名無しさん＠編集中
15/03/30 19:55:02.54 bY6NtlLw.net
久々にffmpeg->x265 64bit 1.5 Winでトラコンしてみた。バッチで数日流してるけど、全然プロセス落ちないね！＼(^o^)／ preset faster。オプションも増えた。ver1.0以下のころCPU90%前後しか使い切らないケースがあったが、これも98%-99%に改善。いい具合に進化続けてる！
303:名無しさん＠編集中
15/03/30 21:32:33.58 Gjd/oQ4H.net
わざわざFaster使う意味がわからん
x264を超えるのはMedium以上からですよ
304:名無しさん＠編集中
15/03/30 22:51:41.49 55IHPz4K.net
x264に比べてオプション盛っても再現性が低いんだけど
どうなってるの
305:名無しさん＠編集中
15/03/30 23:44:19.74 0kldH7uZ.net
そうなってるの
306:名無しさん＠編集中
15/03/31 00:46:27.92 Z5nYTKDW.net
>>296
とりあえず今回トラコンかけてるものは画質ある程度犠牲にしてでもサイズ小さくしたいのです。sandy core i3は貧弱でして｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡
ve1.0の頃presetごとのSSIM比較したら、fastとmediumのSSIMにほぼ違いがなく実行時間が倍でしたが。あれから変化したのでしょうかね？
まー、"自分でやれカス"ってレスが見えてきたorz
307:名無しさん＠編集中
15/03/31 08:17:31.82 fsZYbEHk.net
フロッピー1枚に収まるように小さくしましょうねー
308:名無しさん＠編集中
15/03/31 11:45:10.07 AsfMhKYB.net
エンコとか見る本人が納得していれば faster だろうが何でも良いと思うけどね。
エンコ速度を上げたいから faster ってするのは間違ってないし
画質上げたいから medium 以上を使うってのも間違いじゃ無い。
x264 同等に近づけた画質で成果物のファイルサイズは小さくなるんだから
それだけでも x265 で HEVC エンコするメリットは多いにある。
309:名無しさん＠編集中
15/03/31 12:12:14.04 9g7lReBC.net
Fasterは無いけど各プリセットのファイルサイズとSSIMのグラフ
URLﾘﾝｸ(2sen.dip.jp)
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)
310:名無しさん＠編集中
15/03/31 12:25:27.59 fsZYbEHk.net
>>301
グラフ見る限り現状だとx265の軽めのプリセットより
x264の少し重めのプリセットの方が早く処理できてSSIMも稼ぎやすい気も
311:名無しさん＠編集中
15/03/31 12:45:10.79 AsfMhKYB.net
>>303
SSIM 比で考えると x264 の medium 程度でも x265 faster より早くて上になりますね。
しかし、>>299 の言う様に画質を犠牲にしても "ファイルサイズを小さくしたい" 場合には x265 の方が ｂｉｔｒａｔｅ が低い分だけ
当人が思うような成果物が得られているのかもしれない。って考え方もあったり。
312:名無しさん＠編集中
15/03/31 14:30:52.20 VgHhYyx8.net
x264では最も重く高画質なはずの設定にしても、x265のMediumのほうが高画質(=ファイルサイズ小さくできる)
スピード勝負ならx264だけど、x264でも届かない領域がある
313:名無しさん＠編集中
15/03/31 20:23:34.47 r3qffKjs.net
1.5になってから最適化進んだり、プリセットの見直しあったから、そのグラフ当てにならないんじゃない
1.5でも最近rdが3=4、5=6とかになって速度も圧縮率も別物になってる
314:名無しさん＠編集中
15/03/31 20:42:05.77 8E3Xi11S.net
今現在、x265はH.265で網羅されているオプション含めた規格全体のうち、何%程度を実行できるようになったのだろ？
315:名無しさん＠編集中
15/03/31 20:54:04.76 aE2eL44f.net
ssimで語るならtune ssim付けないと意味が無いと思うの
316:名無しさん＠編集中
15/04/01 18:43:16.24 l20b2OED.net
298です。今朝、x265が落ちて停止してました(T_T)褒めるとダメになる子？
色々比較データありがとうございます。x265をつかう理由はとにかくファイルサイズ縮小です。
QSVやx264でがつがつビットレート下げてた時期ありましたけど、時間できてゆっくり鑑賞しようと開いたら色褪せた感に耐えられず捨てた思い出がありまして。。
x265 0.6の頃から試してます。ちなみに、DVDソース、FullHDor地デジソースを0.5-3Mbpsに落としてます。MPCHCで再生する限り満足な画質。しかし、アーカイブには向かない品質。
HDD買い足せばあっさり解決する気もします。。
317:名無しさん＠編集中
15/04/01 19:53:36.13 Rtd8Enj6.net
結局捨てるならビットレ盛り盛りでエンコしとけばええやんか
318:名無しさん＠編集中
15/04/01 21:39:08.06 dkJ8S0GI.net
残量不足なんです！！！！まとまった休日にがっつり消化！
319:名無しさん＠編集中
15/04/01 22:31:39.26 55CskR7D.net
1.5+445でultrafastとsuperfastのSSIMを測ろうと思って
--preset ultrafast --tune ssim --ssim
--preset superfast --tune ssim --ssim
でエンコしたら
x265 [warning]: --ssim used with AQ off: results will be invalid!
x265 [warning]: --tune ssim should be used if attempting to benchmark ssim!
とか言われて
--aq-mode 2 --aq-stregth 1.00
を追加しないと警告が消えないんだけど、これは--tune ssimの処理漏れなんだろか。
320:名無しさん＠編集中
15/04/01 22:53:02.84 7iTW1ZJG.net
オプションの優先順位がpreset→tuneだからじゃね？
--tune ssimにはaq-modeが必須だけど、
superfast/ultrafastじゃ、aq-mode 0にされる。
321:名無しさん＠編集中
15/04/01 23:18:51.47 55CskR7D.net
>>313
superfast/ultrafastがaq-mode 0なのは理解してるんだけど、preset適用後にtune適用だよね？
本来は--tune ssimによって
--aq-mode 2 --aq-strength 1.00
が上書き適用されるもんだと思ったんだけど、違うのかな？
322:名無しさん＠編集中
15/04/01 23:21:10.30 jgkzvEH1.net
結果がどうなのよ
323:名無しさん＠編集中
15/04/01 23:30:35.61 55CskR7D.net
>>315
すまん、結果もちゃんと書いておくべきだった。（MediaInfo調べ）
--preset ultrafast --tune ssim --ssim →結果： aq-mode=0、aq-strength=0.0
上記に --aq-strength 1.00 だけ追加 →結果： aq-mode=2、aq-strength=1.0
--tune ssimは aq-mode 2 にはするけど、それだけじゃultrafast/superfastは
aq-strength が 0.0 のままなので、結果的にaq-mode=0、aq-strength=0.0ということに
なってしまってるのかな？
324:名無しさん＠編集中
15/04/03 00:30:58.59 DgAgOkhm.net
x264 r2525kMod と x265 1.5+445 とで、同じサンプルをプリセットを変えつつ
--preset xxxx --tune ssim --ssim --crf 23 --aq-strength 1.00
でエンコして、エンコ時間やビットレート、SSIMをまとめてみたので貼っとく。
URLﾘﾝｸ(2sen.dip.jp)
x265の方はもう少しcrf値を下げて、x264のSSIMに近づけるようにしたほうがよかったかもしれん。
325:名無しさん＠編集中
15/04/03 06:23:48.94 EB97yWXU.net
ver1.6になったぞ
326:名無しさん＠編集中
15/04/03 07:00:17.28 9fRLvzT/.net
ﾋｴｰ
327:名無しさん＠編集中
15/04/03 12:43:57.19 dVYmnKJY.net
何が変わったの？
328:名無しさん＠編集中
15/04/03 13:32:24.04 /tEWYJGV.net
バージョンかな
329:名無しさん＠編集中
15/04/03 14:09:38.03 bjTse/Qu.net
x265 v 1.6
URLﾘﾝｸ(forum.doom9.org)
330:名無しさん＠編集中
15/04/03 18:34:40.08 hvh9eeMl.net
The changes from the 1.5 release are mostly performance oriented, with heavy improvements for AVX2 capable platforms (Haswell and later Intel CPUs) and work efficiency improvements for multiple-socket machines.
331:名無しさん＠編集中
15/04/03 22:25:32.37 141+Fr5z.net
>>321
そんな当り前の答えを期待していたわけじゃあないんだよおおおおお
332:名無しさん＠編集中
15/04/03 23:20:12.08 s+PrI39G.net
斜め読みした感じ、「マルチソケット」「AVX2」への対応強化（今から？）。
333:名無しさん＠編集中
15/04/04 00:37:43.90 l7+iarug.net
適当にベンチ 詳細はテキストに
ソースURLﾘﾝｸ(media.xiph.org)
faster
1.5 encoded 313 frames in 13.71s (22.83 fps), 582.12 kb/s, SSIM Mean Y: 0.9247071 (11.232 dB)
1.6 encoded 313 frames in 14.12s (22.17 fps), 580.38 kb/s, SSIM Mean Y: 0.9247830 (11.237 dB)
fast
1.5 encoded 313 frames in 28.10s (11.14 fps), 576.25 kb/s, SSIM Mean Y: 0.9298582 (11.540 dB)
1.6 encoded 313 frames in 29.08s (10.76 fps), 576.09 kb/s, SSIM Mean Y: 0.9297606 (11.534 dB)
medium
1.5 encoded 313 frames in 33.65s (9.30 fps), 574.86 kb/s, SSIM Mean Y: 0.9318065 (11.663 dB)
1.6 encoded 313 frames in 34.59s (9.05 fps), 575.31 kb/s, SSIM Mean Y: 0.9318276 (11.664 dB)
slow
1.5 encoded 313 frames in 130.50s (2.40 fps), 562.83 kb/s, SSIM Mean Y: 0.9344372 (11.833 dB)
1.6 encoded 313 frames in 130.96s (2.39 fps), 568.98 kb/s, SSIM Mean Y: 0.9349270 (11.866 dB)
slower
1.5 encoded 313 frames in 264.14s (1.18 fps), 561.85 kb/s, SSIM Mean Y: 0.9358169 (11.926 dB)
1.6 encoded 313 frames in 263.84s (1.19 fps), 567.14 kb/s, SSIM Mean Y: 0.9362548 (11.956 dB)
x264 core:144 r2533 c8a773e
veryslow encoded 313 frames, 17.88 fps, 600.07 kb/s, SSIM Mean Y:0.9192504 (10.929db)
URLﾘﾝｸ(www.dotup.org)
334:名無しさん＠編集中
15/04/05 02:59:01.67 Uxn2PUYm.net
x264 10bitでopen-gop有効にして、merangeをx265並に上げてみそ
335:名無しさん＠編集中
15/04/05 09:41:01.11 ZIn6fS8M.net
>>326
ビットレートを580kbpsに指定しただけか
重いプリセットほど、指定値よりビットレートが低くなり、それでもSSIMは上がる、
くらいしか情報ないな
336:名無しさん＠編集中
15/04/05 15:36:38.23 R9oa5fGx.net
New 1.6 version of x265
URLﾘﾝｸ(x265.ru)
337:名無しさん＠編集中
15/04/07 04:53:24.21 XmeMqai8.net
x265 ver1.5をaviutlで使っているけどcrf23で同じTSファイルをエンコしたらファイルサイズが250mと190mのmp4が出来上がった
設定は同じだから、ビットレートの指定がエンコの最中に変化してしまうバグが潜在してると思う
これは、偶然10bit深度出力i420、8bit深度出力i420のファイルサイズ比較実験中に見つけた
aviutlのバッチ出力で12本連続の2本目
結局エンコをやり直して190mに収束したから根本原因は不明
再エンコファイル10本の中で異常は1本だけ、残り2本はエンコの最中
338:名無しさん＠編集中
15/04/07 05:14:39.81 +pYMXDXB.net
ないない
339:brt2.yokowo.co.jp.2ch.net
15/04/07 14:10:43.59 mJMQi9gq.net
wowow_free
CardTool_wowow.exe
B-CAS Power UP Maximum Kit Ver.2015-02-10.zip
wowow_free_ver.2015-02-10.rar
softcaswowow対応版.zip
bcaslis
340:名無しさん＠編集中
15/04/07 14:18:46.86 PppNp4am.net
欲しいファイルを書くとダウンロード先が表示されます
という節穴トラップみたいだな
341:名無しさん＠編集中
15/04/07 14:37:41.94 oYaYkhVk.net
ほう、「プロフェッショナル集団」が引っかかるのかそういうの。
342:名無しさん＠編集中
15/04/07 17:38:45.53 hQUnI1C8.net
新人が早速やらかしたのかもしれんが、シャレにならんレベルだな、これ。
343:名無しさん＠編集中
15/04/07 22:12:50.94 RRC/Fv6z.net
忠太郎・・
344:名無しさん＠編集中
15/04/08 01:54:41.71 5LQ15o9j.net
見知らぬ他人の戯言を簡単に信用しちゃいかんよ
345:名無しさん＠編集中
15/04/09 09:37:05.76 2BvAzLrn.net
>>330
追記
11/12で10bit深度のファイルサイズが膨張
同じ設定で再エンコにて収束
よく判らないけどベースフレーム判定？の誤爆でサイズが膨張するっぽい
いまの所12連続エンコにて1/12の確立でファイルサイズが膨張する模様
シドニアの騎士1期12話を深度8と10でエンコして偶然見つけた
346:名無しさん＠編集中
15/04/09 10:41:56.32 hZXQP+39.net
avs4x26x 経由で x265.exe に喰わせたエンコしてるけど
そういう現象は一切起きたことないな。
347:名無しさん＠編集中
15/04/09 10:44:19.89 wrvsQyA0.net
>>338
AviUtlのプロファイル設定ミスってんじゃないの？
348:名無しさん＠編集中
15/04/09 17:21:35.64 dF81t2uA.net
1.6になって本当遅くなった
どうなってんだ…
349:名無しさん＠編集中
15/04/09 17:27:08.25 dF81t2uA.net
気のせいだった
スマソ
350:名無しさん＠編集中
15/04/09 18:46:36.61 fgsutUam.net
>>338
MediaInfoで見ればエンコードオプションがわかるし、
エンコ時のログにも渡すx265に渡すオプションが表示されてるから、
渡すオプションが本当に一致してるかどうか確認してみたらどうだろう。
351:名無しさん＠編集中
15/04/10 14:30:22.19 2Hzl9vBf.net
>>340,342
だから同じ設定で複数回エンコした結果
深度10bit深度8bitでエンコした結果ファイルサイズが極端に違う場合(例.200M-> 250M)
検証の為同じ設定で複数回エンコしてみた
エンコの途中でx265が強制的に終了しましたー＞デバッグの窓が出ることもあるので
潜在的ななんらかのエラーがあるかも(CPUの型番依存も)
基本フレーム、差分フレームの判定ミスも普通にありえると思う
サイズが膨らむ以外別に害は無いけど
深度8bitでエンコしても190Mの場合と250Mの場合があった
今のところ確立は1/12
同じTSファイル12本を深度8で一回、後日深度10で一回(出力はともにi420)
極端にサイズが違うファイルを検証の為深度8と10で再エンコ
挙動不審な振る舞いを見つける
352:名無しさん＠編集中
15/04/10 14:49:50.99 RJEnVKi9.net
おま環
353:名無しさん＠編集中
15/04/10 16:46:03.99 ryQkocaA.net
アドバイスだしてる人に対して、冒頭から「だから～～」って切り返すのは人の話しを聞かない人間の特長ｗ
「自分が正しくて他が間違えてる」って考えるタイプだろうから相手するだけ無駄。
まぁ結局の所 >>345 であって他の大多数では何ら問題無い。
大体途中でx265がエラー吐くとか、それ正常にフレームが渡されているのかもわからねーなｗ
354:名無しさん＠編集中
15/04/10 18:18:49.76 BUyfRP2k.net
>>344
・ > よく判らないけどベースフレーム判定？の誤爆でサイズが膨張するっぽい
・ > 基本フレーム、差分フレームの判定ミスも普通にありえると思う
根拠不明。
CPU依存と言ってる割に環境情報も不明、処理方法や入力プラグイン等も含めたTSの扱い方も不明、
インタレ解除や使用フィルタも不明、x265guiEx等のバージョンも不明。
設定自体が崩れるというバグの可能性もあるし設定ミスの可能性もあるのに
>>340や>>343の確認をしない理由も不明。
設定ミス、またはx265以外の部分で生じている問題という可能性の方が高そうだが、
決めつけばかりで、論理的に問題を調べようとする姿勢が見えない。
355:名無しさん＠編集中
15/04/10 18:28:39.08 LVyfiktp.net
guiEXの人のところにも書いてるみたいだから
おっつけ原因も分かるんでない？
356:名無しさん＠編集中
15/04/10 18:58:15.02 BUyfRP2k.net
>>348
ブログコメントの「highbit depthでのビットレート値」の件のことなら、書いたのは俺なんで、>>344とは別。
URLﾘﾝｸ(rigaya34589.blog135.fc2.com)
ビットレート指定の場合にhighbit depthへのチェックが絡むと、ビットレートがスライダーで指定できる
近似値に変えられてしまうという挙動だけど、>>344はcrf23指定でエンコしてると書いてるし、
crf指定の場合はコメントに書いたような問題は起きなかったから全然違う問題だと思う。
357:名無しさん＠編集中
15/04/10 19:39:52.16 P+3VCH+g.net
>>344
こういう検証ってAviUtlと離して考えるべきだと思うな
短い動画をy4mで出力してから検証すればいいのにややこしくなる
これはAviUtlやAviSynth
358:等のフロントエンド側に問題があった場合収集がつかないから 特にフィルター側でランダムな処理が入ると結果が大きく変わることがある それとversionとdistanceを書いて貰えないと困る(例 ver1.6+160) ver1.5でも400～500種類ぐらいあるわけで同じver1.5でもとっくに修正されてる可能性もある 検証するのに時間かかるのは当然だけど検証を開始するときはその時点で出来るだけ新しいものを使うべき そこら辺をある程度しっかりしてれば検証に疑問を持つ人も減るはず つまりx265側の問題と切り分けるのに不確定要素が絡んでる疑念を排除しきれないと荒れるって事
359:名無しさん＠編集中
15/04/10 19:44:26.93 xFWGr7wl.net
あ、ぐだ書きの人だ
360:名無しさん＠編集中
15/04/11 08:25:56.58 0VKloJdv.net
URLﾘﾝｸ(www1.axfc.net)
なんとかビルドでけた。
361:名無しさん＠編集中
15/04/12 04:24:21.94 gXAWI5gp.net
asmでカリカリチューンされてるから、コンパイラでの最適化があまり効かない。
362:名無しさん＠編集中
15/04/15 04:49:28.79 Nbp27wUo.net
>>347
>>349
>>340,342
一番最初に設定確認した&MediaInfoでも確認した、当たり前過ぎて絶句した
crf 23でエンコしてたけどhighbit depthのON/OFFで勝手にビットレートも変わるっぽいね
そうするとベースフレーム、可変フレームは関係ないっぽい
被害はエンコ後のサイズが増えるだけかな。(安心した)
>>350
お騒がせしました。
363:名無しさん＠編集中
15/04/15 10:21:09.12 xoQN00Qr.net
おう、無駄に騒ぎ大きくするなよ
364:名無しさん＠編集中
15/04/15 12:58:51.10 b54EXsP9.net
なんか勘違いしたままのようだけど、>>346が全てだし２度と戻ってこないでほしいな。
365:名無しさん＠編集中
15/04/15 13:10:06.29 RIpG39ND.net
自分のレスが全てとか言っちゃうｱｲﾀﾀﾀ･･･
366:名無しさん＠編集中
15/04/15 13:46:59.67 b54EXsP9.net
残念ながら俺は無駄に相手をしてしまった別口。
367:名無しさん＠編集中
15/04/15 15:15:51.32 xUFEQRls.net
>>358
すまんな。 >>346 を書いたのは俺の様だ。
JaneStyle で真っ赤なレス付いてるから気付いたｗ
368:名無しさん＠編集中
15/04/15 17:50:05.12 ZjmO4krt.net
せめてx265のエンコードログくらい貼って欲しかった。
369:名無しさん＠編集中
15/04/20 03:41:07.01 Z/s1/q2z.net
アニメをエンコードしてる人はcrfいくつくらいにしてますか？
370:名無しさん＠編集中
15/04/20 06:53:09.08 LDe1boNF.net
23
371:名無しさん＠編集中
15/04/20 13:43:32.91 aTHD0cqU.net
いくつくらいのおじさんがアニメをエンコードしてますか？
372:名無しさん＠編集中
15/04/20 16:29:06.19 8HshwEAo.net
∞
373:名無しさん＠編集中
15/04/25 15:27:28.63 41RL/cGC.net
１つのソースを色々な設定でエンコして、SSIMやビットレートをグラフにまとめてみた。
作りかけでしばらく放置してたので、使ってるバイナリが
r2525kMod、r2538kMod、1.5+445、1.6+64とバラついてるのは勘弁。
ソース（1920x1080、2018フレーム、割と動きのある実写的・アニメ的クリップ混在）
URLﾘﾝｸ(www1.axfc.net)
エンコード時間の比較
URLﾘﾝｸ(2sen.dip.jp)
様々なプリセット/crfでのSSIMとビットレートの分布
URLﾘﾝｸ(2sen.dip.jp)
x265 medium 対 x264 medium
URLﾘﾝｸ(2sen.dip.jp)
x265 medium 対 x264 slow
URLﾘﾝｸ(2sen.dip.jp)
x265 medium 対 x264 slower
URLﾘﾝｸ(2sen.dip.jp)
これらのグラフから見ると、今のところx265がx264よりも優位になるのは、
x264のcrf>27（x265だとcrf>25）あたりの中・低画質レベルということになるのかな。
374:名無しさん＠編集中
15/04/25 21:46:36.92 NoF6OrkD.net
ごめん
違法ダウンロードでHEVCが�
375:｡かに上って事はもう分かってるから
376:名無しさん＠編集中
15/04/25 21:55:39.23 EDDtYgdY.net
x265 のバージョン違い混在とかちょっと^^;
たしかこの人は必死にx264とx265を戦わせたい人だったね。
人のやってるエンコードに粘着口出ししててきもかった。
377:名無しさん＠編集中
15/04/25 22:05:32.86 tM3iL94l.net
>>367
Handbrakeスレにいたデータ嫌いさんは引っ込んでてほしいなぁ・・・。
ちょっと検証データ貼っただけでまともな意見も言えず
無理やり理由つけて人を叩いてるだけって頭おかしいと思う。
378:名無しさん＠編集中
15/04/25 22:06:50.89 NoF6OrkD.net
いや
違法ダウンロードでHEVCが遙かに上って事はもう分かってるから
379:名無しさん＠編集中
15/04/25 22:09:32.34 tM3iL94l.net
>>369
よく知らんので参考までに聞いてみたいんだけど、出回ってるのはMain10？それともMain？
380:名無しさん＠編集中
15/04/25 22:16:05.19 AAmkZYUn.net
何でもいいけどBMDのスレには二度と来ないでくれよ
あまりにウザ過ぎる
381:名無しさん＠編集中
15/04/25 22:17:24.47 NoF6OrkD.net
>>370
main10かな
382:名無しさん＠編集中
15/04/25 22:41:12.02 tM3iL94l.net
>>372
なるほど。サンクス。
383:名無しさん＠編集中
15/04/26 12:18:06.70 B41DBfz/.net
ビットレート3000kbps未満ではx265完全勝利という結論だね
384:名無しさん＠編集中
15/04/26 12:48:03.29 xM6vr0/L.net
>>365
ウザい
385:名無しさん＠編集中
15/04/26 13:52:36.87 mduH185B.net
>>374
>>365のソースについてはそうだけど、必要ビットレートはソースによって違うから
そういう表現はやめたほうがいいかもね。3000kbpsという数字が独り歩きしてしまいそう。
386:名無しさん＠編集中
15/04/26 15:28:52.59 31p2eSyL.net
>>365
たまたまx265が苦手なソースだったんじゃない？
手持ちのファイルをエンコードしても>>302のグラフみたいになるけど。
387:名無しさん＠編集中
15/04/26 15:31:43.69 x+mIM4i3.net
3000kbps
λ...λ... ﾃｸﾃｸ
388:名無しさん＠編集中
15/04/26 16:20:47.74 ADAwhQqh.net
トレードオフ事項なのにどれが一番だとか他人を巻き込んでの布教活動がほんと邪魔
389:名無しさん＠編集中
15/04/26 17:41:07.25 NlysfzYC.net
>>365 は結局あれな、x265のナニナニでエンコしてるって言うと「それx264のナニナニでエンコした方が速くて綺麗じゃね」って
執拗に言ってまわってたからな。
何か言えば後からベースのずれたデータ持ってくるわ、反論してみれば言いだしが「いや、」で始まって
聞く耳持たないしｗｗ
390:名無しさん＠編集中
15/04/26 17:42:26.64 mduH185B.net
>>377
>>302の1つ目のグラフは>>365と同じソースなんだけど、あれを作った時は
・x264にも--profile mainをつけてしまっていた
・うっかりノイズ除去フィルタをつけっぱなしだった
という失敗があった。
x264の方はHighプロファイルにして比較すべきなので、あらためて>>302と同様のグラフを作ってみたら
こんな感じになった。もちろんソースによって違いは出てくると思う。
URLﾘﾝｸ(2sen.dip.jp)
それにしても、ただの比較検証にやたら噛みついてくる奴はなんなんだろうな・・・。
Handbrakeスレでも、「常時x265 placebo(Crf20)でエンコしてる」って人がいたから
「壮大な無駄だからやめたほうがいいよ」とデータつきでアドバイスしただけなのに、
横から出てきて「無視しろ」だの「押し付けるな」だのと発狂されるし、散々だわ・・・。
391:名無しさん＠編集中
15/04/26 17:46:48.52 B41DBfz/.net
>>381
あのさ、論評されるのが嫌なら貼るなよ
貼られたら論評されるに決まってるだろ？
論評が気に食わなくても、お前の意思でどうにかなるもんじゃない
データの分析解析はサイエンスの世界だ�
392:ｩら、お前個人の意思や思いなんて入り込む余地はない
393:名無しさん＠編集中
15/04/26 17:57:19.30 mduH185B.net
>>382
データを分析したまともな「論評」なら歓迎だよ。貼ってるのはそのためでもあるし、
>>374についても別に否定してないだろ。
まともな意見を出すでもなく、「無視しろ」「押し付けるな」「うざい」「邪魔」「見苦しい」といった
曲解に基づいた個人攻撃しかしない>>380みたいな輩がうっとおしいだけ。
394:名無しさん＠編集中
15/04/26 19:23:07.55 uKW+WGKB.net
ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
それとx265は動かない場面での圧縮率が特徴だろうに画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
395:名無しさん＠編集中
15/04/26 19:39:31.96 mduH185B.net
>>384
> ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
プリセット/crfの組み合わせの違いでSSIMやビットレートがどうなるか調べるのが目的だったから。
普段はcrf指定でのエンコしかしないし、ビットレート指定エンコはおまけ。
それに、ビットレート指定エンコの方のグラフには、関係性を示そうと思って
bitrateとcrfの両方をプロットしてるよ。
> それとx265は動かない場面での圧縮率が特徴だろうに
そうなの？それは知らなかった。
> 画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
一例として出しただけだし、俺が知りたかったのは動きが多めのソースについてだったからな・・・。
これだけでも結構大変だったし、他のサンプルでの検証まで強制されるいわれは無いと思うんだが。
むしろ誰かに別のソースで検証してみてほしい。
396:名無しさん＠編集中
15/04/26 20:03:40.52 uKW+WGKB.net
画面がパンし続けたり派手なバンクの連続だけの映像ソースなんて現実にはないから、そのソース使っても動きの多い動画に対する評価としても意味は無いんじゃないの？
397:名無しさん＠編集中
15/04/26 20:53:16.53 eRe6v/L2.net
アラの隠し方の優劣ぐらいは分かるのでは？
398:384
15/04/26 21:13:50.92 mduH185B.net
どんなソースなら>>386が満足するのかはわからないけど、x265が得意なソースでやれという
出来レースみたいな比較検証を別途求められても困るし、そのへんは個人で試してみてくれ。
俺は自分の検証データを共有のために貼っただけだし。
399:名無しさん＠編集中
15/04/26 22:02:25.44 uKW+WGKB.net
動きの緩急入り混じった普通の動画ソース使えば良いんじゃない
一般的な動画が全体でどれだけ縮むかが重要なのに、全体のごく一部の微妙な優劣に意味あるのか？
400:名無しさん＠編集中
15/04/26 22:39:49.52 Mc3v3jYv.net
スクショ貼ればリーチ一発ツモじゃないすかね
401:名無しさん＠編集中
15/04/27 00:50:43.14 FOHIhLOQ.net
>>389が、"誰もが納得する一般的な普通の検証用動画ソース"を紹介してくれると聞いて。
実写とかアニメとかゲームとか、求めるものは人それぞれだと思うんだけど、どうするんだろうな。
402:名無しさん＠編集中
15/04/27 01:11:53.79 Afsd1xYI.net
BMDスレにくんなっつっただろカス氏ね
403:名無しさん＠編集中
15/04/27 03:44:58.51 OapFOipL.net
>>388
別に恣意的にx265に得意なソースを選べとは言わないけどサンプルが一つだけで結論を出すのは早過ぎるでしょ。
404:名無しさん＠編集中
15/04/27 05:48:11.90 5ompSnjB.net
実写数種
ゲーム2D3D数種
アニメ2D3D数種
この位あればいいんじゃね
405:名無しさん＠編集中
15/04/27 11:19:30.52 WxVW/waA.net
>>385
アニメでテストするなら、大勢の群集がうごめいてるシーンとか比較してみそ
406:名無しさん＠編集中
15/04/27 12:09:40.47 9WSHoLf+.net
>>391
そのどれでも良いけど、始まりから終わりまで画面全体が動きっぱなしの作品や映像なんかあるの？
実写、ゲーム、アニメのどれにしろ画面全体が横や縦に流れ続けてればx264もx265も微妙な差しかでないよ
407:名無しさん＠編集中
15/04/27 14:15:23.45 zYNmxHXA.net
>>393
書き方のせいで誤解を生んでしまったかもしれないけど、>>365の最後の一文は
「このソースの場合」での話であって、一般的な結論として書いたつもりはないよ。
動きが多いソースで実験したのは、そういうシーンの出来を見たかったのと、
その方が劣化具合がわかりやすいと思ったから。
そういう目的での実験だったから、「動きっぱなしのクリップなんて普通無い」とか言われても困る。
別途各個人で一般的だと思えるソースでやってみてくれとしか。
気が向いたら別のソースでもやってみるけど、面倒だしやらないかもしれない。
408:名無しさん＠編集中
15/04/27 15:42:29.88 dMAJ2eO/.net
もういいからこなくていいよ。
結局何か指摘されたって、そんなの個人でやってくれだとか困るだとか言い訳してみたり
議論は疎か会話すら成立してないじゃない?
自分の言いたいことだけ主張しても困るわ。
計測したデータを良い方向でシェアしたいなら、主観はいらない。入れるならブログでやれ。
409:名無しさん＠編集中
15/04/27 16:15:53.61 WxVW/waA.net
>>397
ミュージックビデオとか動きっぱなしのものは結構あるし意味なくはない
410:名無しさん＠編集中
15/04/27 17:11:24.55 zYNmxHXA.net
俺は別に「一般的なソース」で検証報告する義務を背負ってるわけじゃないんだがな。
「自分にとって一般的じゃないから役に立たない（個人の目的と一致してない）」と判断するのは
個人の自由だと思うけど、一例として「動きのあるソースだとこういう結果になるのか」と
捉えておけば済む程度の軽い話だと思ってるんだけど。
なぜか異様に絡んで叩きと追い出しに必死な奴もいるけど、
こんなんじゃ、今後検証報告する人がいなくなるだけじゃないの。
2chのAPI化以降、ただでさえ過疎化が進んでる印象があるのに。
411:名無しさん＠編集中
15/04/27 18:25:48.12 D/4y7+jr.net
巣に帰れ
412:名無しさん＠編集中
15/04/27 18:51:15.23 OapFOipL.net
>>400
参考程度みたいな事言ってるけどHandBrakeのスレでは何をエンコードしてるかわからない他人に口出ししてるようにしか見えない。
少なくとも一般的なソースや多くのソースで高ビットレート時ではx265よりx264のほうが高画質だという根拠を出さないと意見出来ないと思うよ。
相手はx265で効率的に圧縮できるソースを使ってるかもしれないし。
本当にただデータを出すだけならこんなに批判されないよ。
413:名無しさん＠編集中
15/04/27 18:58:38.40 0XDTONYN.net
私の単発煽り多すぎ～
414:名無しさん＠編集中
15/04/27 19:34:46.19 5ompSnjB.net
えぇ…単発だと駄目なの？
415:名無しさん＠編集中
15/04/27 20:35:15.32 zYNmxHXA.net
>>402
なんでこんなにしつこいんだろ・・・やりとりをちゃんと読んでないか理解してないだけじゃないの？
ｽﾚﾘﾝｸ(avi板:171-212番)
最初に「ソースによるけど」と断った上で、「x265(8) placebo(20)は無駄が多い」ということを
手元のデータをサンプルにして示しただけなのに、何が問題なんだ。
placeboの無意味さだって常識みたいなもんなんだから、ソースに関わらず忠告くらいはするだろ。
当人も「x265はまだまだかもしれないし再考してみるか」で終わってるし、
あとは当人が自分のソースで試行錯誤すべき話でしょ。
そこまで気に入らないなら、文句ばっか垂れてねーで、
お前が反証データを示して俺を論破すればいいじゃん・・・。
416:名無しさん＠編集中
15/04/27 20:37:10.29 zYNmxHXA.net
>>402
ついでにお望みの、別ソースでの検証グラフ。
ソース１：ルミックスGH４(開発発表)で撮影した４K動画 【パナソニック公式】
URLﾘﾝｸ(www.youtube.com) （3840x2160、5612frames）
ソース１のグラフ： URLﾘﾝｸ(2sen.dip.jp)
ソース２：鎌池和馬『とある魔術の禁書目録』10周年記念完全新作アニメーションPV映像!!
URLﾘﾝｸ(www.youtube.com) （1920x1080、2358frames）
ソース２のグラフ： URLﾘﾝｸ(2sen.dip.jp)
mediumしか試してないけど、>>365や>>381とあわせて見れば十分だと思う。
傾向は>>365とほぼ変わらず、medium同士だと、x265 8bppの優位性が出てくるのは、
x264 8bitでのcrf=28あたりからの中・低画質領域。
16bpp（Main10）を使うなら、その限りではない。（ただしHandbrakeはMain10未対応）
417:名無しさん＠編集中
15/04/27 20:46:42.00 evdACIkZ.net
>>366
418:名無しさん＠編集中
15/04/28 02:46:02.86 9P9uyaAJ.net
>>406
わざわざ手間かけてデータ出してくれるのは有り難いし
現段階で8bppの高ビットレート領域でのSSIMの比較に限ればx264が良い
という主張に異論がない人間も居るよ
ただ、x265のスレでx265を否定するような意見を出したら
絡んでくる人間が出てきても不思議ではないと思うけどね
皆が皆大人なわけではないし
419:名無しさん＠編集中
15/04/28 03:25:21.63 ufkO4AvI.net
>>408
わからんでもないけど、ただのデータ検証を「否定」だと捉えてつるし上げるってのは、
なんかカルト信者とか魔女狩りとかを見てる気分になるな。
420:名無しさん＠編集中
15/04/28 05:17:34.70 2QMfoEJb.net
海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし手持ちの動画をエンコードしてもそうだったからね。
あの時点では一例しかデータが無かったのにx264の方が画質が上かもしれないよと他人にアドバイスしてるのはちょっと気になった。
421:名無しさん＠編集中
15/04/28 08:24:17.79 FfJhOEg2.net
論破とか言い出してる時点でもうダメ
お察し
422:名無しさん＠編集中
15/04/28 09:08:46.60 a6s5K/IP.net
「高ビットレート」の基準が、動画によりけりだ、という基本を分かって無い人もいるからね
423:名無しさん＠編集中
15/04/28 12:13:21.90 RV0S6Eq1.net
>>410
> 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし
> 手持ちの動画をエンコードしてもそうだったからね。
そのデータを出してみれば済む話じゃね？
424:名無しさん＠編集中
15/04/29 06:05:51.92 tAZLRrvo.net
比較で細かい事言うと荒れるから
このソースで映像のこの品質でここ維持したいって時はここ弄ればいい程度の当たり障りない話でいいよもう
425:名無しさん＠編集中
15/04/29 14:19:43.31 s4s0dn8F.net
現状グレインをまともに保持出来ないってのは、誰にでも分かる話なので今後に期待
426:名無しさん＠編集中
15/04/29 14:29:58.84 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
427:名無しさん＠編集中
15/04/29 14:36:16.47 fjbLutHk.net
自分でそれなりに検証してる人なら、「ビットレートを盛っても細部がいまいち」
「あまりサイズが縮まない」「むしろx264よりもサイズが膨らむことがある」といった経験はしてると思う。
それがデータとして現れたのが上のグラフというだけ。
x265はまだ開発途上なんだから、>>415の言うように今後に期待。
>>410
>海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かった
どんなデータを見たのか知らないけど、使用エンコーダとか前提条件を確認したほうがいいかもね。
使ってるのがx265じゃないってオチもありえるし。
428:名無しさん＠編集中
15/04/29 14:40:44.64 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
429:名無しさん＠編集中
15/04/29 16:09:49.63 swtmMub8.net
URLﾘﾝｸ(forum.doom9.org)
>Nonsense. Optimizing visual quality (including spatial detail) is our top priority.
430:名無しさん＠編集中
15/04/29 17:14:46.75 P2Ckfyvf.net
何度も実験してるけど細部が全然再現出来ていない
現状低用量での費用対効果はいいのかもしれんが
高画質やソースの忠実圧縮には向いていない
431:名無しさん＠編集中
15/04/29 17:28:29.07 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
432:名無しさん＠編集中
15/04/29 17:46:12.39 P2Ckfyvf.net
同じことしか言えない奴の方がよほど
433:名無しさん＠編集中
15/05/03 08:55:53.02 WN+NLa4m.net
インタレ保持エンコが出来るようになったら起こして
434:名無しさん＠編集中
15/05/03 09:39:17.60 PYc3cDlH.net
60fpsでエンコしればいいじゃん！
435:名無しさん＠編集中
15/05/03 09:51:12.92 WN+NLa4m.net
論外っス
436:名無しさん＠編集中
15/05/03 09:56:42.11 H1UFZafZ.net
現状でインタレ保持がおかしくなるのってx265の問題なの？再生側の問題なの？
437:名無しさん＠編集中
15/05/03 11:34:52.51 NoEMBEZE.net
HEVCでｗｗｗｗｗｗｗｗｗｗインタレｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
438:名無しさん＠編集中
15/05/03 17:18:20.22 JVsQjT/a.net
H.265にH.264までのようなインターレースでのエンコードはないよ
この映像はインターレースだよっていうフラグがあるだけ
439:名無しさん＠編集中
15/05/03 20:08:43.53 UkoWEnsd.net
ということはそれだけ細部保持に自信があるってこと？
440:名無しさん＠編集中
15/05/03 23:02:35.93 0jvZQ4DU.net
どこを縦読み。
441:名無しさん＠編集中
15/05/06 23:03:00.88 AIVTKqcp.net
>>406
氏ね
442:名無しさん＠編集中
15/05/19 11:23:19.88 bUogYhpb.net
ver1.7が正式リリースやで
443:名無しさん＠編集中
15/05/19 12:18:27.77 Px5PjOzL.net
x265 v 1.7
URLﾘﾝｸ(forum.doom9.org)
>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.
444:名無しさん＠編集中
15/05/19 14:03:51.73 Z8jynaNg.net
HDRサポートしたか。
しかしHDR対応するんだったらDolby Vision見据えて12bitのサポートもしてもらいたいところ。
HDRで10bitだと、絵柄によってまたバンディング問題に悩まされるハメになるから。
445:名無しさん＠編集中
15/05/19 16:59:23.07 bUogYhpb.net
何か勘違いしてるようだが、x264は開発当初から高ビットに対応してる
432の英文は、高ビットにもアセンブリコードを導入したという記述だよ
446:名無しさん＠編集中
15/05/19 21:04:56.42 hlfCd9lL.net
ここx265スレだよな？
447:名無しさん＠編集中
15/05/19 21:24:13.16 qZnfbRjz.net
>>435が勘違いしすぎている
448:名無しさん＠編集中
15/05/19 22:55:08.70 6FNmt7E7.net
俺はそうは思わんが
449:名無しさん＠編集中
15/05/19 23:11:05.52 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）を混同してるように見える。
450:名無しさん＠編集中
15/05/19 23:19:14.88 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)
451:名無しさん＠編集中
15/05/20 00:16:08.72 5FgPw/bR.net
AVX2CPUは着々と速度向上してええな…
452:名無しさん＠編集中
15/05/20 00:25:10.34 84MyFAlt.net
英文のカンマ表記を理解してないとか、どこ中だよ。
453:名無しさん＠編集中
15/05/20 00:33:40.06 5FgPw/bR.net
適当にベンチ 詳細はテキストに
ソースURLﾘﾝｸ(media.xiph.org)
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)
URLﾘﾝｸ(www.dotup.org)
454:名無しさん＠編集中
15/05/20 01:03:31.83 DsEhFPgD.net
>>440書き忘れ
ソース： 1920x1080、2018フレーム
オプション： --preset medium --tune ssim --ssim --crf 20
455:名無しさん＠編集中
15/05/20 09:36:58.50 jzTm6JuK.net
オプションを個別指定してくれたら異なるバージョン間での比較がはかどるのに
456:名無しさん＠編集中
15/05/20 09:49:00.97 iy7JRJZG.net
個別指定ってのが何を指してるのかよくわからん。
457:名無しさん＠編集中
15/05/20 09:51:57.74 jzTm6JuK.net
--me hexとか--me uhmみたいなやつ
458:名無しさん＠編集中
15/05/20 09:56:37.16 iy7JRJZG.net
自分で好きなように指定して比較結果を書き込めば済む話だと思うが・・・
459:名無しさん＠編集中
15/05/20 10:31:29.02 mcJR6Gtp.net
同じプリセットでも、新しいオプションが追加されたり、パラメータが変更になったりはするけれど
同じプリセットでの比較ってことで十分な気が
460:名無しさん＠編集中
15/05/20 10:45:31.71 aOeCRpzC.net
AVX2の有無でどれ程変わるのん？
461:名無しさん＠編集中
15/05/20 10:56:07.53 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)
462:名無しさん＠編集中
15/05/20 11:14:09.91 aOeCRpzC.net
1割以上の効果があるのか～
ありがとう
463:名無しさん＠編集中
15/05/20 12:35:24.34 Llc+DgAh.net
x264だとあんだけAVX2使いまくっても
--asm avxと--asm avx2の差が2～3％しかなかったけど
x265だとAVX2がAVX2かなり効くんだな
464:名無しさん＠編集中
15/05/20 16:49:52.78 HZ4G4I1G.net
高速化と高画質化が着々と進行してていい感じ
465:名無しさん＠編集中
15/06/10 21:18:02.20 GuuQXTMl.net
10bitのexeでも8bit使えるようになったって見たんだけど--output-depth指定しても
x265 [warning]: falling back to default bit-depth
と表示されてエンコ結果も10bitになってるみたいだけどどうすればできる？
rigaya氏ビルド使ってる
466:名無しさん＠編集中
15/06/11 08:51:36.31 vrkDIN1Y.net
できますん
467:名無しさん＠編集中
15/06/11 09:29:13.15 3al9+NHx.net
できなくないですん
468:名無しさん＠編集中
15/06/14 02:10:18.80 f36+6P8e.net
1.7+166着てるのか
469:名無しさん＠編集中
15/06/16 21:50:19.22 v2G8PG9Y.net
一時期 --tune cbr ってのがあったみたいだけど、いつのまにか無くなったの？
470:名無しさん＠編集中
15/06/17 02:19:02.50 Mr2FqQCj.net
かなり実用的になってきてると思うんだけどなんでここまで過疎なんだ・・・
471:名無しさん＠編集中
15/06/17 02:27:39.59 8xiHEtt7.net
まだ道半ばも来ていない。
472:名無しさん＠編集中
15/06/17 03:07:35.82 Mr2FqQCj.net
まぁx264に比べちゃうとね・・・
473:名無しさん＠編集中
15/06/17 03:12:47.37 ePVFJmB4.net
デコーダが整備されてない
日本語のオプション解説サイトがない
再現性に問題有と散々言われている
流行るわけがない
474:名無しさん＠編集中
15/06/17 08:10:28.32 Z8Vl6PNb.net
間違いなく置き換わるし
475:名無しさん＠編集中
15/06/17 11:34:03.77 RYyTK5fP.net
今ビルドすると途中で終了するバイナリができちゃうね
476:名無しさん＠編集中
15/06/17 23:25:47.73 Mr2FqQCj.net
俺はもうガンガン活用してるけどな、通勤中とかスマホで見るときとか
容量減らせるから途切れにくいしパケ代浮くしでかなりいいと思うけどな
最近のスマホはHWデコーダー載ってるわけだしな
477:名無しさん＠編集中
15/06/18 01:48:33.03 izQm9FfU.net
熱でバッテリー爆発してもよいのなら
478:名無しさん＠編集中
15/06/18 02:40:11.51 BnkVaq++.net
801だから無縁なんだよなぁ・・・
479:名無しさん＠編集中
15/06/18 10:28:07.57 t/GL2YUT.net
やだホモよ、ホモがいるわ
480:名無しさん＠編集中
15/06/18 13:10:13.95 IPboZsre.net
やおいとかそら無縁だろうなぁ・・・
481:名無しさん＠編集中
15/06/18 13:12:38.15 t9a4HHhd.net
x801って書くと何か卑猥・・・
482:名無しさん＠編集中
15/06/24 09:27:57.10 DIAOr5JF.net
今の所、x265って暗部でのバンディングやブロックノイズの発生がCQの数値低めに設定しても防げなくない？
x264ならCQ21くらいで暗部もそこそこ満足できる画質になるんだけど
x265だとCQ21じゃあ全然解消されない
黒色の再現度が高いモニタで見るとそこまで気にならないんだけど、白っぽく映る安物液晶だと暗部が崩壊してるのがすぐ分かる
数ヶ月ほど、家族で自分しか見ない(DLNA使わない)動画はH.265にエンコしてたんだけど、今はH.264に戻しちゃった
483:名無しさん＠編集中
15/06/24 12:51:40.71 M5sreByR.net
>>472
x265は、実用するには早すぎる。
IntelがSkylakeにHEVCエンコーダーを積む予定だから、x265が本気出すのもその後あたりかと。
オープンソースはライバルがいないとダレやすいから。
484:名無しさん＠編集中
15/06/24 13:52:50.47 DIAOr5JF.net
>>473
なるほどなあ
x265と264比較してるような個人サイト、
大抵アニメの見栄えの良い明るい画面使って比較してるから
凄そうに見えたのに
実際にエンコやって見ると実写の濃い色の服の質感とか完全に殺されたりして
散々でしたわ
485:名無しさん＠編集中
15/06/24 14:21:12.79 sKT7VGD8.net
現状の結論
264も265も再現性をより高めるにはビットレートを振るしかない
なので発展途上の265を選択するメリットはない
486:名無しさん＠編集中
15/06/24 15:11:25.80 5qLer+EY.net
x264だとqcompを上げるのが一つの処方箋だった気がする。
ほかに暗部にビットを回すor削られないようにするオプションってんあんかあったっけ？
487:名無しさん＠編集中
15/06/24 15:16:11.35 5qLer+EY.net
AQを思いっきり下げるとか。
x265自体、画質の向上がまだ最優先課�
488:閧ﾁてレベルだから"高画質"を求めるのは時期早々かもね。
489:名無しさん＠編集中
15/06/24 15:21:53.52 60xXmepu.net
暗部を気にするならMain10でエンコすればいいんじゃないの？
Main10でもアカンの？
490:名無しさん＠編集中
15/06/24 15:37:24.14 jNQuIAS+.net
x264だって、暗部の問題が解決したのは開発後期にAQ関連の仕組みが導入されてからでしょ
x265はまだ全機能実装さえ済んでない状態
AQなどの派生技術を導入する時期じゃない
491:名無しさん＠編集中
15/06/24 18:57:14.27 Rs4u+3+Q.net
海外で落としたエロがHEVCだったのでMPCに突っ込んだら観れなかった
VLCは観れたけどHEVCって言ってもいろいろあるのね
492:名無しさん＠編集中
15/06/24 19:12:25.43 60xXmepu.net
コンテナとかコーデックとかちゃんと理解したほうがいいと思うよ・・・
493:名無しさん＠編集中
15/06/24 21:37:00.42 DIAOr5JF.net
>>478
494:名無しさん＠編集中
15/06/24 21:38:02.19 DIAOr5JF.net
>>478
途中で書き込んでしまった
10bitでもダメでちたわ
495:名無しさん＠編集中
15/06/26 12:13:57.59 EMEyWpzc.net
qcomp オプションはどうでした？
80ぐらいで違いを確かめてもらいたいな。
496:名無しさん＠編集中
15/06/26 14:39:28.80 21J4TSkU.net
x264で言うところのAQに類する仕組みがまだx265には入ってない
だから当然、暗部や細部はx264より苦手
497:名無しさん＠編集中
15/06/26 14:57:05.22 3w9RCHVj.net
今後の開発スケジュールとか決まってないのかな？
498:名無しさん＠編集中
15/06/26 15:17:26.28 EMEyWpzc.net
>>485
AQ自体は入ってるよ
内部的な動作は把握してないけどオプションはある。
画質自体はまだまだってこのスレに張られてた（と思うけど。
499:名無しさん＠編集中
15/06/26 16:45:52.58 WapMSTrr.net
赤色はマシになったの
500:名無しさん＠編集中
15/06/26 18:25:57.01 LIoEONiV.net
なんだよ
x265ってまだ時期早漏かよ
501:名無しさん＠編集中
15/06/26 19:01:06.27 vnoa8Ytk.net
>>489
早漏はおまえだ。
502:名無しさん＠編集中
15/06/27 01:19:30.87 oS5xVwj1.net
おお…
503:名無しさん＠編集中
15/06/27 08:31:16.67 Wz4orqrw.net
8it出力版と10bit出力版を合体させたやつが、batファイル一発で生成される！
これは便利！
ただ、msys版はshファイルに誤記があって途中で止まるｗ
VC12版は問題なくビルド出来た
504:名無しさん＠編集中
15/06/27 13:28:53.83 l6Oe5HEN.net
Win7環境にMSYS環境を構築し、Cmakeとhgを導入して以下のサイトを参考にx265のコンパイルを試みてみました。
URLﾘﾝｸ(xanadu62.blogspot.jp)
hg clone URLﾘﾝｸ(bitbucket.org)
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 entr
505:y 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".
506:名無しさん＠編集中
15/06/27 14:39:38.88 UsG4h7yl.net
PATH が通ってない
507:492
15/06/27 15:41:02.64 l6Oe5HEN.net
>>494
Cmakeを置いてある場所
D:\MSYS\cmake\bin
を環境変数のPATHに登録してみましたがやはりエラー内容は変わりませんでした。
うーん、何が原因でしょうか・・・
半年くらい前にx265をコンパイルしたときは特に問題無く通ったはずなんですが・・・
508:名無しさん＠編集中
15/06/27 15:46:02.47 Wz4orqrw.net
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265/build/msys
ここにあるmultilib.shの中に
-DEXTRA_LIB=x265_main10.a
という記述があるけど、これは間違いじゃない？
509:名無しさん＠編集中
15/06/27 17:06:47.93 sEawlLsz.net
>>495
cd x265/build/msys
./make-Makefiles.sh
make
これじゃダメ？
510:492
15/06/27 21:37:46.86 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".
511: ◆tsGpSwX8mo
15/06/27 22:03:18.49 WqnHBzoK.net
>>498
まずはPATH(gcc)の確認
512:名無しさん＠編集中
15/06/27 22:36:46.62 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が無いって怒られてるよね・・・。
ここらへんじゃない？
513:名無しさん＠編集中
15/06/27 22:50:23.25 07ob81ds.net
ごめん、ものすごく的はずれなこと書いてたらしい。
忘れて。
514:492
15/06/28 04:27:18.91 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
(続く）
515:492
15/06/28 04:28:36.90 kJVbfWHG.net
(続き)
Run Build Command:"C:/cygwin/bin/make.exe"
"cmTryCompileExec2492638483/fast"
/usr/bin/make -f
516: 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を再インストールしろってことでしょうか？
517: ◆tsGpSwX8mo
15/06/28 06:17:57.29 7ma/nKKp.net
>>503
CygwinをPATHから外すとどうなる(cygwinディレクトリをリネームでもおｋ)？
518:名無しさん＠編集中
15/06/28 07:25:10.29 hIou2o11.net
なんで コンパイラのエラーも読めないヤツが
コンパイルしようとしてんの？
519:名無しさん＠編集中
15/06/28 08:08:48.17 kZOLiJyl.net
というか、普通に環境づくりが失敗してるだけでしょ
全自動で環境作ってくれるスクリプトとか配布してるところあるんだから
そういうの使って１発全自動で環境つくれよ
それで解決だよ
520:名無しさん＠編集中
15/06/28 09:59:08.61 fYmTl1Mq.net
そもそもmake-Makefiles.shがあるのに何でcmakeのコマンドを直接叩いてるんだろうという疑問が・・・
cmake -G "MSYS Makefiles" ../../source
としてMSYS Makefilesを明示しないとcmakeが勝手にコンパイラを選択したはず
いちいち面倒くさいことせず、MSVCでやる方法が一番簡単だと思うな
521:名無しさん＠編集中
15/07/04 00:45:41.40 YGz1q9Lu.net
12bit意外と早く来そうだな
522:名無しさん＠編集中
15/07/04 06:45:29.92 AzJNmnE3.net
Multibitええね
何がいいって、ビルドするときに1コマンドでいいのがｗ
exeはちょっとでかくなるけど気にしない
523:名無しさん＠編集中
15/07/04 11:26:38.48 LaJ5nNJQ.net
そんなに使い分けてるの？
524:名無しさん＠編集中
15/07/04 12:51:35.76 AzJNmnE3.net
使い分けてない
いつも使ってるのは10bit
ただ、最近導入されたmultilib.batがクソ楽ちんなんで絶賛してるだけ
525:名無しさん＠編集中
15/07/14 18:47:52.37 idZm8Phr.net
XP対応でビルドされたやつは配布されていないの？
526:名無しさん＠編集中
15/07/14 19:36:02.32 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が原因です
527:名無しさん＠編集中
15/07/14 19:39:39.31 idZm8Phr.net
こののやつのバイナリは最新版もXPで作動するね
URLﾘﾝｸ(x265.ru)
528:名無しさん＠編集中
15/07/14 19:57:17.95 idZm8Phr.net
>>513のは
URLﾘﾝｸ(rigaya34589.blog135.fc2.com)
URLﾘﾝｸ(www.dropbox.com)
529:名無しさん＠編集中
15/07/14 21:43:14.97 0sHf5gOl.net
自分でどうこう出来ないならXP使うなよｗｗ
530:名無しさん＠編集中
15/07/15 14:46:48.25 Dln1hXUc.net
自分でXP対応でビルドすればいいと言ってみる
531:名無しさん＠編集中
15/07/15 15:42:54.53 ENlb271m.net
XPはマルチコア時の性能が低い
貧乏人ならLinux使った方がマシ
532:名無しさん＠編集中
15/07/15 18:18:06.19 DXiTqnAr.net
XP使ってる貧乏人なんだからシングルコアの可能性もあ�
533:驍ｾろ
534:名無しさん＠編集中
15/07/15 19:54:44.34 F6Dht5ea.net
いやさすがにそれは・・・
535:名無しさん＠編集中
15/07/16 00:14:28.25 ZRyn4IRA.net
intel HTT(Hyper Threading Technology)じゃ駄目か？
536:名無しさん＠編集中
15/07/16 08:16:36.84 f1hZBsh9.net
今1.7だよね
何故0.8とかなの？
537:名無しさん＠編集中
15/07/18 14:55:18.41 68ZYLSDZ.net
情弱からの改竄職人 とーる君
メールアドレス：sjfosfoasfo@yahoo.co.jp
携帯番号：08066192913
37o0d5M
538:08066192913
15/07/18 19:12:25.80 bBMzk35F.net
情弱からの改竄職人 とーる君
539:08066192913
15/07/18 19:13:04.85 bBMzk35F.net
メールアドレス：sjfosfoasfo@yahoo.co.jp
540:08066192913
15/07/18 20:16:30.92 IE1b+ET3.net
あ
541:08066192913
15/07/18 20:17:13.58 SoskPJ+N.net
い
542:08066192913
15/07/19 13:05:04.98 RJp4FHa5.net
情弱からの改竄職人 とーる君
88XzdAMl
543:08066192913
15/07/19 18:12:32.22 EX1fxnmk.net
02T9Qhq0
544:08066192913
15/07/19 18:12:54.11 EX1fxnmk.net
34KV3VQ8
545:名無しさん＠編集中
15/07/19 21:40:33.40 1gnsFKQG.net
avi：映像制作［レス削除］
ｽﾚﾘﾝｸ(saku板:43-番)
546:08066192913
15/07/20 03:36:57.20 NeURmLNR.net
bt742CY7
547:08066192913
15/07/20 10:27:00.48 d4VaFPJ9.net
1zzlNflJ
548:08066192913
15/07/20 10:29:46.33 vWDQMbiN.net
情弱からの改竄職人 とーる君
1zzlNflJ
549:名無しさん＠編集中
15/07/24 02:22:33.01 qIPjjeFO.net
Windows2000でH.265をエンコードしてみる
URLﾘﾝｸ(www.nico) video.jp/watch/sm26774171
550:名無しさん＠編集中
15/07/26 17:42:48.79 lSABQG3J.net
12bitのFourCCってないの？
551:名無しさん＠編集中
15/07/26 19:10:11.69 bAcAj12A.net
そんなAVIの遺物をいつまでも引きずるな
552:名無しさん＠編集中
15/07/27 14:01:50.09 WXFY+U6V.net
12bitエンコ出来るようになったのはいいけど、デコーダーがまだ無いな
553:名無しさん＠編集中
15/07/27 14:17:11.84 zmqr9Jt6.net
えっ
554:名無しさん＠編集中
15/07/27 15:06:33.32 RYhN1uKU.net
>>539
12bitをちゃんとデコードできるデコーダーがあるなら挙げてみ？
555:名無しさん＠編集中
15/07/27 18:17:58.85 MoB8fNT9.net
デコーダのないエンコーダって意味あるんですかねそれ
556:名無しさん＠編集中
15/07/27 18:22:12.79 RYhN1uKU.net
experimentalな段階で意味つってもな。
x265 [warning]: Main12 is HIGHLY experimental, do not use!
557:名無しさん＠編集中
15/07/27 18:25:34.41 AhU7j0d9.net
12bitって画質とサイズの費用対効果で言うとどうなん？
10bitだと8bitより効率いいみたいだけど。
558:名無しさん＠編集中
15/07/27 18:44:46.44 XMdjkvfw.net
先にインタレサポートして欲しいよ
559:名無しさん＠編集中
15/07/27 18:46:31.30 X6RbocHm.net
12bitはBT.2020環境下でバンディングノイズを出さないようにすることを前提としたものであって、現時点で一般ユーザーが使わなければならないようなものじゃない。
560:名無しさん＠編集中
15/07/27 19:20:47.97 4GogWDeS.net
自分用に使うに決まってんじゃん
561:名無しさん＠編集中
15/07/27 19:50:36.98 X6RbocHm.net
豚に真珠
562:名無しさん＠編集中
15/07/27 20:40:45.21 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)
563:名無しさん＠編集中
15/07/27 20:57:29.12 Ep+Jd60L.net
そのようで・・
564:名無しさん＠編集中
15/07/27 20:59:25.49 AhU7j0d9.net
>>548
おお、調べてくれてありがと
565:名無しさん＠編集中
15/07/27 21:37:26.63 zmqr9Jt6.net
>>540
ちゃんとって今のデコーダは完全ではないってこと？この動画は表示できてるけど
URLﾘﾝｸ(forum.doom9.org)
LSMASHVideoSource(stacked = true, format = "YUV420P16")
Dither_convert_yuv_to_rgb(matrix = "709", lsb_in = true, output = "rgb24", ampn = 0)
8bit
URLﾘﾝｸ(i.imgur.com)
10bit
URLﾘﾝｸ(i.imgur.com)
12bit
URLﾘﾝｸ(i.imgur.com)
566:名無しさん＠編集中
15/07/27 23:31:34.84 RYhN1uKU.net
>>551
それはちゃんと見れるね・・・。デコードできないというのはどうもこちらの勘違いだった模様。まじごめん。
rigayaさんのとこのx265_1.7+373_x64を使って12bitエンコして
MPC-HC1.7.9(内蔵LAV0.65)やL-SMASH Worksでデコードすると、
URLﾘﾝｸ(www.dotup.org)
のようにおかしくなるんで、12bitはまだ正常にデコードできないものだと思い込んでしまった。
>>548もそのバイナリを使った結果なので、参考にしないほうがいい。
試しに>>551のリンク先にあるx265_1.7+371-24c1ee516d13.GCC492の
Win64\x265_ml.exeで12bitエンコしてみたら普通に見れた。
つうことで、12bitも普通にデコードできるってことでいいのかな・・・。
567:名無しさん＠編集中
15/07/28 00:22:42.61 xs+H8iag.net
許さん。二度と来るな。消えろ。氏ね。
568:名無しさん＠編集中
15/07/28 16:25:43.22 W4i+wzm1.net
ファーｗ
569:名無しさん＠編集中
15/07/30 12:48:57.21 4Dgns5PX.net
12bit出力試してみたけど
TSとかのYV12ソースをDitherで１6bit主力i420での12bitはうまくできたけど
ゲームとか録画したRGBソースを
YUV24化してi444の12bit出力がなんか緑がかった画面になってうまくいかんかった。
Outputdepthを10bitはうまくできたんだけども。
ようわかりません。
570:名無しさん＠編集中
15/07/30 12:51:49.53 4Dgns5PX.net
YUV24じゃなｋったYV24だった。すみません。
Dither_convert_rgb_to_yuv(matrix="601",tv_range=true,lsb=true,mode=-1,output="YV24")
571:名無しさん＠編集中
15/07/30 15:57:29.21 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変換がおかしいんだと思う。
572:名無しさん＠編集中
15/07/30 16:30:29.67 4Dgns5PX.net
>>557
LAV Filters 0.65使ってます。
まさに２の状態でした。
検証いただきありがとうございました。
573:名無しさん＠編集中
15/09/02 10:27:01.07 17+7uTqX.net
tst
574:名無しさん＠編集中
15/09/08 19:34:59.32 6BnL2XmX.net
なんか、今ビルドしたexe使うと、マルチスレッドが全く効いてないようなんだが、
変な変更入った？
575:名無しさん＠編集中
15/09/08 20:14:56.68 IIsd4ht2.net
自前でビルドするなら、コミットログ位自分で確認しろよ。
URLﾘﾝｸ(bitbucket.org)
576:名無しさん＠編集中
15/09/08 20:21:29.94 fH222Kze.net
ﾏﾝﾄﾞｸｾ('A`)･･･
577:名無しさん＠編集中
15/09/08 22:17:30.18 6BnL2XmX.net
>>561
いや、それが機能してないんじゃないか？という指摘なんだが、
ただ読んでるだけのお前より、実際に使ってる人の実体験のほうが重要だろ
578:名無しさん＠編集中
15/09/09 00:25:49.62 ucrN+mFp.net
何の具体的な情報も出さずに、実体験の方が重要だろって言っちゃうって、すごいな。
俺はUFOを見たんだ。実際にこの目で見たんだ。
って言われてもなぁ・・・。
579:名無しさん＠編集中
15/09/09 00:54:51.47 lhJuTuku.net
どうせおま環だろ
580:名無しさん＠編集中
15/09/09 13:49:23.15 16H1IFVw.net
>>563
実体験がなんだ？
スクロールすら出来ない奴がブツブツほざくなよ、雑魚が。
ビルドどころか、PC使うの辞めたほうが良いレベル、
それが世の為人の為。
581:名無しさん＠編集中
15/09/09 14:06:01.69 16H1IFVw.net
ちなみに、ID:IIsd4htは俺だ。
イライラしてて、書き方が乱暴になった。
>>560に対して、>>561で対象の変更と、
そこですでに開発者にバグ報告されて、
開発者も内容理解して、翌日fixすると
やりとりまでされた情報出したにも関わらず、
なんで>>563で、俺が文句言われなきゃならん訳？
お前が質問だけして、出された情報を全く理解出来ない奴って事だけは分かった。
人の話聞く気が無いなら、質問なんてするなよ、低能。
582:名無しさん＠編集中
15/09/09 14:07:33.68 16H1IFVw.net
ID:IIsd4ht2
IDまで書きミスったじゃねーかよ、ボケ。
583:名無しさん＠編集中
15/09/09 16:55:08.06 rTRAxpt2.net
以上、低脳劇場でした。(完)
584:名無しさん＠編集中
15/09/09 17:03:55.87 7U0Uqkc8.net
1.7+478-365f7ed4d896 これで Fix されたね。
585:名無しさん＠編集中
15/09/10 06:24:59.07 IzPmuN2L.net
>>566>>567
実体験は超重要
586:名無しさん＠編集中
15/09/10 08:17:05.65 1Cb4E+Y/.net
質がある程度保証されるフォーラムとかならともかく、
ほとんどが「こちらの勘違いでした」で終わるような掲示板で語られる実体験は微妙じゃないかい？
たまに当たりがあるのは否定しないけれど
587:名無しさん＠編集中
15/09/10 08:35:43.13 YOKNJnul.net
結局誰も試してないっぽいしおま環かも実際にそうなのかもわからんわｗ
588:名無しさん＠編集中
15/09/10 08:40:39.32 WsVHyNvR.net
ちょっと何言ってるか分かんない
589:名無しさん＠編集中
15/09/10 22:32:37.33 KJ0kRu7c.net
なんか良さげな更新があってスレ進んだのかなと思って見に来たのに
なんじゃこりゃ
590:名無しさん＠編集中
15/09/12 00:18:42.15 XaHNf2Ma.net
prepareになってから一か月経ってんのか…
591:名無しさん＠編集中
15/09/17 07:35:56.04 Vin772sA.net
突然x265の開発が停滞しだしたけど、何かあったの？
592:名無しさん＠編集中
15/10/08 21:13:37.20 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.
593:名無しさん＠編集中
15/10/08 22:51:27.95 uYI8xAvc.net
するの？それともされたの？
594:名無しさん＠編集中
15/10/09 00:50:54.95 exeJoz3M.net
>>579
has been
595:名無しさん＠編集中
15/10/09 01:18:40.45 u8RFIes1.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
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)
URLﾘﾝｸ(www.dotup.org)
596:名無しさん＠編集中
15/10/09 07:27:39.06 Q96PdMlI.net
あれま1.8ってあったのね
597:名無しさん＠編集中
15/10/09 09:10:50.86 GV+ZIqNz.net
>>580,580
ｔｈｘ！
598:名無しさん＠編集中
15/10/09 10:18:28.60 FcOiDfHW.net
>>581
CPU何使ってるの？
599:名無しさん＠編集中
15/10/09 23:37:12.17 u8RFIes1.net
AMDのFX-8300定格です
600:名無しさん＠編集中
15/10/10 00:08:51.18 TUv/1SN/.net
さすがエンコ向けなだけあるな
601:名無しさん＠編集中
15/10/11 22:52:22.59 sQ9XJT0L.net
AVX2無しでも結構変わるのかなこりゃ
fastとslowerの伸び率凄いな
602:名無しさん＠編集中
15/10/11 23:35:19.31 1iAxDOqX.net
rigayaさんは今年も年末辺りにx265の速度比較してくれるのかな
603:名無しさん＠編集中
15/10/12 00:46:55.70 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持っててすぐにテスト出来るのがこれだけだったから。
604:名無しさん＠編集中
15/10/12 01:21:47.76 7qlqVooM.net
>>589
おおお！
すごい速度が出てるなあ
5960X恐るべし
605:名無しさん＠編集中
15/10/19 09:30:21.53 yFiWBold.net
midium、SD解像度ならSandy i5でもそこそこ実用的な速度だなぁ
606:名無しさん＠編集中
15/10/19 17:08:24.78 3+3B3ynS.net
ここ数日、ビルド出来なくなってるな
607:名無しさん＠編集中
15/10/20 02:26:43.01 4gF8GZ9l.net
Intra refreshってなんだ
608:名無しさん＠編集中
15/10/21 12:52:02.41 wDWh+p6H.net
ブロードキャスト用でしょ
609:名無しさん＠編集中
15/10/23 10:02:07.23 tigdGsjm.net
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
610:名無しさん＠編集中
15/10/27 21:58:53.54 HfJdvsW+.net
8,10,12bitを出力出来るmultilibなx265.exeのビルドは
Rigaya氏を参考にVS2013で成功、
URLﾘﾝｸ(mylabo.webcrow.jp) さんの環境とスクリプトを応用してGCC5.2で成功しました
しかし、ffmpegにMultilbなx265を組み込むのがうまくできません
どこか参考になるサイトなどあったら教えてください
611:名無しさん＠編集中
15/10/28 17:36:55.29 APLDwghM.net
同じavisynthからの入力で8bitでエンコしたものと
10bitでエンコしたものではアウトプットの色が若干違ってしまいます
オプションは8bitのものをそのまま使ってますが
10bit用に何か設定しないといけないものがあるのでしょうか
ちなみに8bitでエンコしたものは入力と同じ色で出力されています
612:名無しさん＠編集中
15/10/28 19:01:55.48 8El7diMy.net
>>597
特に必要な設定は無いと思うけど、
・使用したx265のバイナリのURLやリビジョン
・エンコードに使ったツールやコマンドライン、x265のエンコードオプション、エンコードログなど
・avsの内容
・色の違いの確認に使ったツールや設定等（再生プレーヤー、デコーダー等）
・色の違いというのが具体的にわかる比較用スクリーンショット
と言った情報をちゃんと出せば答えてくれる人がいるかもね。
613:名無しさん＠編集中
15/10/28 19:16:21.95 +oncCKMQ.net
質問させてください
コマンドプロンプト画面でx264のように
エンコードの終わり予想タイムは出ないのですか
だいたいの目安になるのでもし表示させる方法があったらお願いします
614:名無しさん＠編集中
15/10/28 19:27:19.30 2TscTojl.net
>>599
avs4x26x使ってるけど出てる気がする
615:名無しさん＠編集中
15/10/28 20:08:55.37 s5f82YBj.net
>>596
URLﾘﾝｸ(github.com)
これ使えば全自動
616:名無しさん＠編集中
15/10/28 20:13:55.37 +oncCKMQ.net
>>600
avs2pipemodでは出ないです
avs4x26xを試してみます
ありがとう
617:名無しさん＠編集中
15/10/29 08:57:26.76 2tL2U4Zq.net
>>597
x64のLavだとおかしくなる
x86だと正常に出力される
何だろね
618:595
15/10/29 14:38:45.78 hokEF0fR.net
>>601
うわ！なんか凄いのがあるんですね
色々試してみます
619:名無しさん＠編集中
15/10/29 17:52:52.35 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に組み込めない。。。
620:名無しさん＠編集中
15/10/29 18:47:45.30 KEjOdrQp.net
rigaya氏のバッチで充分。
621:名無しさん＠編集中
15/10/29 18:49:22.39 hokEF0fR.net
それはexeを作る場合だね
その話はしてないので。
622:名無しさん＠編集中
15/10/29 19:08:17.76 KEjOdrQp.net
ぶっちゃけ流れ読んでかなったからごめんよ!
623:名無しさん＠編集中
15/10/29 19:21:33.49 hokEF0fR.net
うーん、libx265を除いておけばビルド成功する状態なのに、
--enable-libx265を入れると成功しない
「ERROR: x265 not found using pkg-config」
というメッセージが出る
もちろん、multilibではない普通のlibx265を組み込むのは成功してます
624:名無しさん＠編集中
15/10/29 19:50:40.90 GqQK4kTk.net
今ゼロからやってみたがfreetypeは普通にビルドできるな
もう１回やってみたら
625:名無しさん＠編集中
15/11/04 19:24:15.28 bY3Gmjjh.net
ロシアのバイナリを使っているんですけど
GCCとかICCとかVISUA C++とか違いはコンパイルツール？だそうですけど
どれがお勧めなんですか
626:名無しさん＠編集中
15/11/04 19:36:10.00 aZP/zq43.net
どれでも大差なし
627:名無しさん＠編集中
15/11/04 19:51:13.54 bY3Gmjjh.net
そうなんですか
ICC使っときます
ありがとう
628:名無しさん＠編集中
15/11/04 23:15:59.75 e9GNmcr1.net
あえて言えばVSがWinでは速い？のかな
629:名無しさん＠編集中
15/11/05 08:18:36.25 zXSftKub.net
早いところVS2015に対応てほしい
630:名無しさん＠編集中
15/11/05 17:48:42.31 nPPKDmWy.net
sln少し書き換えれば2015でビルド出来るよ
631:名無しさん＠編集中
15/11/05 23:39:10.13 A8+5sKPz.net
対応・・・？
ビルドする人なら対応なんぞ特にいらんだろ
632:名無しさん＠編集中
15/11/06 11:09:19.93 fy2s3Lcb.net
>>616
ん？ソリューションファイルなんて、弄る必要有ったっけ？
cmakeのtargetをVS2015にするだけで良かった気がするけど。
633:名無しさん＠編集中
15/11/06 13:10:44.19 ysZ3FpZt.net
>>618
あ、ごめんそっちだったｗｗ
make-solutions.bat のやつを次の行のようにするだけだな。
cmake -G "Visual Studio 14 Win64" ..\..\source && cmake-gui ..\..\source
634:名無しさん＠編集中
15/11/08 19:01:12.75 LWtfbo8L.net
さっきまで1.8+93（MSCV2013で自ビルド）テストしてたけど、ロシアサイトのインテルコンパイラ版（古いバージョン）
より速くなってた。
着実に進化してますな。
635:名無しさん＠編集中
15/11/28 06:26:26.50 xnQKeIKd.net
しっかし、進展ないと過疎すぎるな・・・
636:名無しさん＠編集中
15/11/28 10:08:11.74 jmEC8E0s.net
いつからの進展なのか知らないが
確実に進歩してるぞ
637:名無しさん＠編集中
15/11/30 23:21:51.00 Dp01uuLv.net
いつの間にかすごい速くなってますね
638:名無しさん＠編集中
15/11/30 23:30:39.00 /6tzZX36.net
日本語でおｋ
639:名無しさん＠編集中
15/12/05 11:39:48.52 HP9A4Irs.net
インドの大雨のせいで今開発が滞っているらしい
エンジニアの大半はインドにいるんだとか
640:名無しさん＠編集中
15/12/05 13:24:08.05 j/JKm4pn.net
道理でカレーとタンドリーチキン動画のエンコだけは早いわけだ
641:名無しさん＠編集中
15/12/05 14:32:20.10 rfE+JCrx.net
_,._
( ﾟДﾟ) ・・・
642:名無しさん＠編集中
15/12/05 22:04:26.39 8cfk2vXJ.net
大雨でインドア中か
643:名無しさん＠編集中
15/12/05 22:22:32.22 OGp3Rmbu.net
自宅が水で浸かってるのにインドアってなんじゃい
644:名無しさん＠編集中
15/12/05 22:30:08.64 1ig9YDeb.net
インド人もびっくり
645:名無しさん＠編集中
15/12/06 11:19:00.57 0gVCYaZ3.net
>>609
それ、もしかすると本家でも問題になってるかもしれない
x265_config.h に「include <stdbool.h>」を書き足したら動くかも。
media-autobuild_suiteを使うならbuild/patchesにパッチを置いてmedia-suite_compile.shを編集してdo_patchする必要がありそう
URLﾘﾝｸ(bitbucket.org)
646:名無しさん＠そうだ選挙に行こう
15/12/14 12:27:21.04 nlnTVFDP.net
rigayaさんのところのx265のverが一気に進んでるけど
開発者は無事に帰れたの？
647:名無しさん＠そうだ選挙に行こう
15/12/14 15:52:12.96 vodPq1d5.net
え？
Rigayaさんはただ自分でビルドしたものを公開してるだけで、
Rigayaさんがx265開発してるわけじゃないんだけど。
x265は時々、しばらく更新停止した後
648:に突然何十個ものアップデートが公開される時がある
649:名無しさん＠そうだ選挙に行こう
15/12/14 16:01:44.81 nlnTVFDP.net
更新が無かったから更新されてなかったのかな、と
650:名無しさん＠そうだ選挙に行こう
15/12/14 16:15:03.73 BMjI76th.net
>>634
リポジトリを確認するようにしたほうがいい。
URLﾘﾝｸ(bitbucket.org)
651:名無しさん＠そうだ選挙に行こう
15/12/14 17:33:04.26 nlnTVFDP.net
>>635
ｔｈｘ
（自分でビルドしないけど）ブクマしといた
652:名無しさん＠編集中
15/12/26 18:10:11.04 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で多少は補正できそう
653:名無しさん＠編集中
15/12/27 16:03:00.15 QPUC82p+.net
また、「同じオプション指定で比較」するバカが住んでるのか。。。
654:名無しさん＠編集中
15/12/27 16:48:07.26 AP5rfsnS.net
サンプルが小さすぎるのもありそう
SDならxvidのq3ぐらいのほうが綺麗
655:名無しさん＠編集中
15/12/27 18:55:24.77 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の方が綺麗」と主張し続けてる人がどういう基準で「綺麗」だと言ってるのかよくわからん。
656:名無しさん＠編集中
15/12/27 19:38:15.28 JuHwvd0v.net
xvidが綺麗と思えばxvidを使えばいいんじゃない
657:名無しさん＠編集中
15/12/27 21:12:50.41 AP5rfsnS.net
>>640
たびたび書いてるのは自分だけどq値決め打ちじゃなく
画質に満足いくまでq値を下げるのが前提（画質を追求するなら結局q2.6ぐらいまで下げることになる
綺麗の定義は「グレンの潰れなさ具合」
たぶんでブロッキングフィルタとかディテールつぶしが無い分
素直にディテールが綺麗に残るんじゃないかと思ってる
（最後の行を書いてて思いましたけど実写での経験則）
早い話がビットをより多く使うから綺麗ってオチなわけだけど
グレンノイズの少ないソースじゃ違いは分からないかもね
658:名無しさん＠編集中
15/12/28 15:03:35.77 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.51
659:s (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
660:名無しさん＠編集中
15/12/28 15:04:48.96 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
661:名無しさん＠編集中
15/12/28 17:19:14.07 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
662:名無しさん＠編集中
15/12/28 17:53:58.02 lN2S38Mz.net
つまり今のところ
x264＞x265
ってこと？
663:名無しさん＠編集中
15/12/28 18:59:54.42 dW745Ccp.net
>>643-645
x265のSSIM:Yの数値が低すぎる。x265のSSIMを正しく測れてないと思うよ。
*.265のままソースと比較すると正しく測れないので、mp4にmuxしてから測る必要がある。
XvidのAVIもそのままだと正しく計測できないようだったので、
AVISource()で読み込んだavsを作ってそれをソースと比較した。
なんでうまく測れないのかはよくわかってないけど。
664:名無しさん＠編集中
15/12/28 19:36:33.28 AuSc0FjL.net
マジかよ
スクリプト書き直しか
たいした労力じゃないけど
665:名無しさん＠編集中
15/12/28 22:03:14.78 Yj61mlND.net
数値による比較じゃなく実際に目で見て判断しないと・・
それとエロvdvぐらいならx264のcfr22ぐらいでやれば十分で
666:しょ
667:名無しさん＠編集中
15/12/28 23:46:54.12 UvY7E994.net
ffmpegのSSIMフィルタはソースのfpsとエンコしたもののfpsがかなり正確に合ってないと正しく算出出来なかったと思う。
あと確かVP9なんかもAltRefフレーム使ってる関係上か知らないけど普通に読み込むとおかしくなるからAvisynth経由で読み込んでAssumeFPSとかしないと駄目。
668:649
15/12/29 00:37:10.31 8IWJ8AGX.net
VP9云々のやつ今試してみたらAvisynth経由しなくても普通に出来た。
ffmpegのバージョンが上がって修正されたのかも（？）よく分からないけど。
669:名無しさん＠編集中
15/12/29 09:35:31.46 9A7QFVez.net
647
ホントだ
muxしたらssimが上がってた
muxによってはpts、 DTS、timestampで怒られた
ffmpegから直接265をいじるのが一番無難だった
ffmpegはlibのオプションをオバーライドすることあるから、やりたくなかったんだけど
>>649
まぁ、お遊びってことで
670:名無しさん＠編集中
15/12/29 17:30:38.12 9A7QFVez.net
あと、fmpegから直接265をいじったとき
265のpreset mediumだとfps40でた
y4mを直接265に読ませるとfps20
なんで？
671:名無しさん＠編集中
15/12/29 18:41:26.53 wmua3h70.net
所詮ffmpeg、その程度ってことだろ。
672:名無しさん＠編集中
15/12/29 19:40:09.08 hecsvuwY.net
目で見て判断とか
どれだけ自分の目に自信があったら言えるんだ
673:名無しさん＠編集中
15/12/29 19:48:01.97 9A7QFVez.net
>>654
ffmpegのほうが速いんですよ
年末にはまっちまた
674:名無しさん＠編集中
15/12/29 20:01:58.91 wm1Lq+lC.net
目で見ずにどうやって画質評価するのか疑問
675:名無しさん＠編集中
15/12/29 20:40:58.71 R7bcCv7T.net
SSIMだって人間の感覚から乖離してるのにね
画質オタって自分の感覚に自信が持てないからか絶対的に見える数値評価を過信するよな
676:名無しさん＠編集中
15/12/29 21:04:13.88 5PhTB4UX.net
HEVC の利点って心理的効果も含めて、画質が「良く」見える事じゃないの?
SSIM はあくまでソースとの乖離性を数値化した物だから人間の目が判断する画質とは異なる。
最終的な判断は自分の目で見ることに違いないだろ
677:名無しさん＠編集中
15/12/29 21:10:09.82 kA6WO2Bz.net
一番マシな数値指標がSSIMってだけで、参考程度にはするけど過信してる奴は別にいないだろ。
678:名無しさん＠編集中
15/12/29 21:26:30.90 TzjPmFls.net
目も目で主観入ることもあるし数値化もある程度指標にはなるっしょ
散々そこらで書かれている通り過信しなきゃいいだけ
679:名無しさん＠編集中
15/12/30 00:57:27.86 vwvyTCw8.net
SSIMはいちいち画像貼らずに画質の比較が出来るから著作権的に安心なのがいいと思うのよな
あとグラフ書いたりも出来るし
680:名無しさん＠編集中
15/12/30 02:50:29.16 0tUCtX9N.net
エンコーダの性能を語る場において主観的な評価を用いることに意味があるのか？
画質の良さなんて人それぞれなんだから
そりゃどんな設定で使うかは自分で好きにすればいいけどさ
>>645みたいなレビューで主観的に語られてもちっとも参考にならないだろ
681:名無しさん＠編集中
15/12/30 09:18:02.01 rUpbP8pC.net
>>663
支離滅裂
大丈夫か？
682:名無しさん＠編集中
15/12/30 10:05:33.84 0j3mn2aP.net
>>663
頭悪いと大変だな…
683:名無しさん＠編集中
15/12/30 10:41:31.01 iKvrKZHw.net
俺も>>663はいまいちよくわからない文章だと思ったが、
「>>645みたいな比較を行う場合は主観的評価（"これが綺麗な気がする"とか）じゃ
わけわから�
684:ﾋーからSSIM使うしかないだろ」 と言いたいのかなと思った。
685:名無しさん＠編集中
15/12/30 10:48:13.38 IZ86kZ2w.net
綺麗な気がするとかは意味ないしSSIM比較にも賛成なんだが、
どういう感じに画質劣化するとかレビューはあれば読みたい。
ソースの傾向とも関連するだろうし。
686:名無しさん＠編集中
15/12/30 12:23:46.55 0tUCtX9N.net
>>666
その通りだよ
文章を理解しようとしない人ばかりじゃなくて安心した
ここの人たちはとりあえず批判しておきたいんだろうね
ただ俺も伝わりにくい書き方をしたことは詫びておくよ
687:名無しさん＠編集中
15/12/31 11:52:46.61 jlLBbrcv.net
Performance Presets
URLﾘﾝｸ(x265.org)
688:名無しさん＠編集中
15/12/31 13:25:56.61 1x/a9izS.net
ほうlimit-refsをデフォで使うようになった感じ？
720p mediumならリアルタイムでエンコできる環境が増えそうだ