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ならリアルタイムでエンコできる環境が増えそうだ
689:名無しさん＠編集中
15/12/31 18:06:45.58 wSkFl2OB.net
グラフ見る限りは魅力的だけど、新プリセットはどこにあるのかな
git見てもそんなのまだなさそうだが
690:名無しさん＠編集中
15/12/31 18:35:10.47 xsxqdEld.net
>>671
既存のプリセットの設定を調整したという話だと思うんだが・・・
691:名無しさん＠編集中
15/12/31 19:04:36.81 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は使う予定無いので、未検証）
692:名無しさん＠編集中
16/01/01 02:18:30.24 WmQnDSNu.net
エラいスピードアップだな。
画質にダメージとかないんかね？
693:名無しさん＠編集中
16/01/01 03:09:19.16 RD6MTGrq.net
1.8+188で適応されてるの？
694:名無しさん＠編集中
16/01/01 05:20:46.74 O3DrfO55.net
SSIMの話してたら公式がグラフに使っててワラタ
695:名無しさん＠編集中
16/01/01 07:49:50.36 jXigYVvB.net
あーpresetの件、�
696:ｽ分、１２月２２日に導入されたこの変更のことだろうな https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce 各プリセットのパラメータを微調整したうえに、最近導入されたlimit-refs、limit-modesも加えたと。 最新ソースを使ってビルドしてるなら、もう１周間前に導入されてたということね。
697:名無しさん＠編集中
16/01/01 09:45:09.31 0amdltZA.net
12/23のx265guiEx 3.66v2でプリセット変更への対処が入ってたしな。
1.8+2と1.8+188とで、手元のソースをプリセット指定だけでエンコした結果を比べてみたら
・エンコード速度は全体的に向上。
・ultrafast～fasterでは従来よりSSIM値が小さくなり、ビットレートも大幅に低くなった。
・fast～slowerではSSIM値は従来と同じくらいだが、ビットレートがやや高くなった。
という結果になった。veryslowとplaceboは時間がかかるので試していない。
詳細→ URLﾘﾝｸ(pastebin.com)
698:名無しさん＠編集中
16/01/01 11:14:31.16 xC692RGG.net
すいません、質問です。
x265のソースコードを自分でビルドして使用しているのですが
バイナリのバージョンが不明なんです。これってコード追記しないといけないのでしょうか？
変な質問だったらスルーしてください。
699:名無しさん＠編集中
16/01/01 15:09:29.20 jXigYVvB.net
x265.exe --version
とコマンド打てば表示されるよ
700:名無しさん＠編集中
16/01/01 15:29:05.52 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
こんな感じです。
701:名無しさん＠編集中
16/01/01 15:29:40.58 nwqCpAdi.net
>>679
ソース下のbuild/README.txtにも書かれてる事(「= Version number considerations =」を参照)だけど、
X265_VERSION はcmake実行時にMercurial(hgコマンド)を使用して設定、ないと"unknown"になる。
Mercurial(hg)のパスを環境変数PATHに追加してからcmakeを実行する。
702:名無しさん＠編集中
16/01/01 15:39:01.12 xC692RGG.net
>>682
ありがとうございます。
703:名無しさん＠編集中
16/01/01 17:27:43.84 jXigYVvB.net
Rigayaさんのとこのx265エンコ速度測定記事、プリセット変更直前に書かれてるのがおしい
704:名無しさん＠編集中
16/01/01 17:32:56.40 xC692RGG.net
なんでおかしいの？
rigaya氏が変更を事前に知っていて、わざと記事にしたとでもいうの？
705:名無しさん＠編集中
16/01/01 17:34:04.38 k8j4Ysr1.net
>>685
落ち着いて>>684を読み直してみろ
706:名無しさん＠編集中
16/01/01 17:39:27.38 jXigYVvB.net
>>685
うん。君はおかしい
はい次の人ー
707:名無しさん＠編集中
16/01/01 17:43:45.36 xC692RGG.net
m(__)m
708:名無しさん＠編集中
16/01/01 20:28:21.76 FNsjlYzw.net
ところでさ、現時点のx265はUltra HD BDの規格に準拠した形でのエンコードはできるんだろうか？
それともまだ何か未対応のオプションがあったりして、規格準拠とまではいかないのだろうか？
x265の進捗状況がよくわからないんだけど。
709:名無しさん＠編集中
16/01/02 21:42:43.73 uM4JuYJD.net
どうしても暗部保持ができなくてバンディングになっちゃう
おもいっきりビットレート上げればなんとかなるけど
一話23分半のアニメで3Gくらいの容量になるからさすがに割りに合わない
710:名無しさん＠編集中
16/01/03 06:14:00.23 TB5sGS/t.net
バンディング消す方法なんていくらでもあるでしょー
基本は10bitエンコだし、
バンディング低減
711:するフィルタだって複数あるよ x264よりも遥かにバンディング出ないx265で悩んでる人はじめて見た
712:名無しさん＠編集中
16/01/03 09:29:55.61 +7iHH5QT.net
バンディングて色調整するとワラワラ出てくることあるね
713:名無しさん＠編集中
16/01/03 12:06:06.62 KftKtXND.net
>>691
x264の10bitの方が明らかにバンディング出ないから悩んでるんだけど
エンコ速度的には十分だと思うし、その問題さえ解消するようならx265に移行するのもいいかなって思ってるけど
>485の頃からまだこういうところは調整されてないのかな？
714:名無しさん＠編集中
16/01/03 12:17:20.68 aIpwUsLj.net
どちらかというとAQで暗部は削られるものだと思うけど・・
715:名無しさん＠編集中
16/01/03 13:57:04.40 CBJBsL1D.net
糞なのはx265のPsyだろうねぇ
716:名無しさん＠編集中
16/01/03 22:11:59.73 V82V0kUc.net
下手くそ
717:名無しさん＠編集中
16/01/05 23:20:08.23 wK8tZoI/.net
ん？またプリセット変わったか
718:名無しさん＠編集中
16/01/06 21:50:42.37 /8vK25uX.net
URLﾘﾝｸ(bitbucket.org)
Merge with default, prep for 1.9
もうすぐ1.9が来そう
719:名無しさん＠編集中
16/01/10 08:23:42.64 Hd4RBeuI.net
x265 1.8+205 -d94f6c2b45f8
URLﾘﾝｸ(www1.axfc.net)
720:名無しさん＠編集中
16/01/10 14:30:01.33 m9YtAxYc.net
x64じゃないのかな
721:名無しさん＠編集中
16/01/10 14:32:48.05 m9YtAxYc.net
なんかエラーで落ちる
722:名無しさん＠編集中
16/01/10 14:47:46.35 Hd4RBeuI.net
>>701
マジすか？
ちょっと調べてみます。
>>700
64bit専用です。
723:名無しさん＠編集中
16/01/10 14:59:37.89 m9YtAxYc.net
普段ここの使ってるんだけど
URLﾘﾝｸ(builds.x265.eu)
ここのも1/8のものからエラーで落ちるようになってる
1/7の1.8+201のものはエラー出ない
自分の環境かもしれないし何が何だか分かってないけど
問題解決されると嬉しい
724:名無しさん＠編集中
16/01/10 15:10:43.28 Hd4RBeuI.net
これはどうでしょうか？
URLﾘﾝｸ(www1.axfc.net)
725:名無しさん＠編集中
16/01/10 15:42:21.06 m9YtAxYc.net
ありがとう
でも同じだった
イベントビューアにはこんな感じで上がってる
障害が発生しているアプリケーション名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
障害が発生しているモジュール名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
例外コード: 0xc0000005
障害オフセット: 0x0000000000790522
726:名無しさん＠編集中
16/01/10 16:05:38.87 Hd4RBeuI.net
うーん・・・
コマンドラインオプション無しでもエラー出ますか？
727:名無しさん＠編集中
16/01/10 16:09:39.28 m9YtAxYc.net
それだと出ないね
俺のオプションがダメっぽいのか…
どのオプションだろ
削りながら試してみるよ
ありがと
728:名無しさん＠編集中
16/01/10 16:12:07.50 Hd4RBeuI.net
メモリーアクセス違反か。
自分の環境では出ないんですよね。
OSはなんですか？
729:名無しさん＠編集中
16/01/10 16:15:17.26 Hd4RBeuI.net
AVX、AVX2、FMA3を潰してみるとか。
730:名無しさん＠編集中
16/01/10 16:16:06.57 m9YtAxYc.net
--no-deblock
このオプション抜いたらエラー出なくなった
これは自分の環境が悪いとかじゃないよね…
731:名無しさん＠編集中
16/01/10 16:23:36.91 Hd4RBeuI.net
ありがとうございます。
そちらの問題ではなく、コードに問題有りかもです。
732:名無しさん＠編集中
16/01/10 16:53:54.29 V/aHiJAl.net
斧に上がったバイナリなんてよく実行できるな・・・
733:名無しさん＠編集中
16/01/10 17:47:40.97 m9YtAxYc.net
どうやってバグの情報としてあげればいいのか分からないや
早く気付いて欲しいなぁ
734:名無しさん＠編集中
16/01/10 20:26:32.56 PlpsG+IN.net
>>713
bitbucketの課題にでも投げれば良いんじゃないの？
URLﾘﾝｸ(bitbucket.org)
735:名無しさん＠編集中
16/01/11 04:08:04.43 NFAme+dx.net
205で更にエンコ速度上がってるな
736:名無しさん＠編集中
16/01/11 18:42:34.02 8MzzuCE7.net
今は209だぜー
737:名無しさん＠編集中
16/01/11 22:48:39.09 iLbQXuHs.net
ここ最近開発が活発化してる
いいねえ
738:名無しさん＠編集中
16/01/12 03:22:31.26 ay8VbQDJ.net
x265-1.8+210_19cfada71621
URLﾘﾝｸ(www1.axfc.net)
739:名無しさん＠編集中
16/01/12 06:40:40.41 FuFhTotB.net
久々にビルドしてみたけど
デフォ設定で1.4と比べたら2倍くらいエンコ速くなってんな
740:名無しさん＠編集中
16/01/12 07:22:48.18 UGxx9q6x.net
密かにpsy-rdのデフォ値も変わったで
741:名無しさん＠編集中
16/01/12 08:45:59.11 FuFhTotB.net
ホントだ
1.0から0.6になっとるな
ちょこちょこ設定変えてんだな
742:名無しさん＠編集中
16/01/12 09:56:13.90 ZF6tU8kF.net
なかなか1.9にならんな
743:名無しさん＠編集中
16/01/12 10:09:53.76 xb1b+Mb+.net
>>721
旧： 値範囲0～2.0 デフォルト値0.3
新： 値範囲0～5.0 デフォルト値2.0
じゃね。
744:名無しさん＠編集中
16/01/12 11:20:34.90 FuFhTotB.net
strengthだった
745:名無しさん＠編集中
16/01/12 14:33:21.76 ckdTaHsh.net
H265 codecs comparison from MSU
URLﾘﾝｸ(x265.ru)
746:名無しさん＠編集中
16/01/12 14:48:48.67 J/v6lK/H.net
URLが怪しすぎる…
747:名無しさん＠編集中
16/01/12 15:14:52.56 UGxx9q6x.net
そこは、ちょっと前までx265バイナリの配布定番サイトだったんだけど、
multicorewareとトラブって配布禁じられたサイト
748:名無しさん＠編集中
16/01/12 15:33:28.98 xb1b+Mb+.net
>>727
トラブったという話の情報源はどこ？
本当ならテンプレからも外さないといかんよね。
749:名無しさん＠編集中
16/01/12 16:02:11.85 ay8VbQDJ.net
multicoreware-x265-6ccd503a4c3a
URLﾘﾝｸ(www1.axfc.net)
750:名無しさん＠編集中
16/01/12 16:07:54.77 ZF6tU8kF.net
ウィルスとかの問題じゃないから問題なし
x264は良かったとか書くあたりライセンスとかそのへんの理由
751:名無しさん＠編集中
16/01/12 21:07:29.03 UGxx9q6x.net
>>728
multicorewareがある日突然、他サイトでのバイナリ配布を禁じたんだよ
URLﾘﾝｸ(x265.ru)はバイナリ配布の最大手だったけど、一夜にして配布停止に追い込まれた
752:名無しさん＠編集中
16/01/12 22:21:22.09 vk6wUU7N.net
>>710
URLﾘﾝｸ(bitbucket.org)
微妙に症状は違うっぽいけど、--no-deblock付けてエラーになる事が解決されてるから、
多分、直ったっぽいよ。
753:名無しさん＠編集中
16/01/13 00:04:51.69 i5ptavi1.net
717のバイナリはバグっているので使わないほうがいい。
728は今のところ大丈夫。
754:名無しさん＠編集中
16/01/13 00:35:17.31 7rxsXKJd.net
そもそも他人ビルドで署名が無い物なんて使うわけ無いですし
755:名無しさん＠編集中
16/01/13 14:58:50.31 wOrVT6++.net
そうですか
756:名無しさん＠編集中
16/01/14 16:51:17.94 AaOlEqVU.net
>>732
1.8+211で試してみたけどまだ直ってないみたい…orz
でも気長に待ってみる
757:名無しさん＠編集中
16/01/15 06:50:52.92 psKZUe1A.net
x265-792f6ead9c50
URLﾘﾝｸ(www1.axfc.net)
758:名無しさん＠編集中
16/01/17 10:34:19.47 M6mbumiP.net
H.265はH.264の半分のビットレートで同等画質を実現するのが実証される - GIGAZINE
URLﾘﾝｸ(gigazine.net)
759:名無しさん＠編集中
16/01/17 10:49:26.43 D60EYyZP.net
>>738
これx264とx265でPSNR調べてもここまで差が出ないんだけど使ってるエンコーダーが違うのかね
760:名無しさん＠編集中
16/01/17 12:09:44.29 Pifl9Opi.net
JVとかいうリファレンスのコーデックでの比較なんじゃね
761:名無しさん＠編集中
16/01/17 12:11:58.73 D60EYyZP.net
JMとHMって書いてあったわ
762:名無しさん＠編集中
16/01/17 13:48:03.23 XmqoO05B.net
>>738
ADSL回線でピアキャスとかで配信するときに重宝する＞H.265
763:名無しさん＠編集中
16/01/17 23:50:56.36 Tbz8Tr7+.net
ADSLはプランによっては1000kbps上限だからねぇ
764:名無しさん＠編集中
16/01/29 2
765:1:07:28.93 ID:DKTs/nc/.net
766:名無しさん＠編集中
16/01/30 01:25:28.25 Wakff49R.net
1.9来たね！
767:名無しさん＠編集中
16/01/30 01:26:18.86 +Hb0depP.net
始まる前から終わってるx265
768:名無しさん＠編集中
16/01/30 01:28:24.65 pHFV68mi.net
今ビルドちゅう
769:名無しさん＠編集中
16/01/31 00:22:07.01 oQyeXKXJ.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
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)
URLﾘﾝｸ(www.dotup.org)
770:名無しさん＠編集中
16/01/31 01:35:17.36 cgqklV4a.net
>>748
slow slowerの高速化がすごい
771:名無しさん＠編集中
16/01/31 02:31:21.15 UHx+fRoe.net
ああ、俺もベンチするスクリプトを Ruby で書いてみたりしてたけど
最近やってなかったな。。。で久々にやってみたたら比較対象が 1.6 の medium しかなかったｗ
URLﾘﾝｸ(i.imgur.com)
772:名無しさん＠編集中
16/01/31 13:41:59.34 txIOJs0s.net
>>748
slowerがビットレート下がりすぎてSSIMもそれに引き摺られちゃってるね
でも倍も速度でてる
773:名無しさん＠編集中
16/01/31 16:07:20.48 cFXQSVbu.net
プリセット内容が変わったんじゃなかった？
774:名無しさん＠編集中
16/01/31 18:33:49.97 tisPGxzA.net
>>752
たしかあったな…
775:名無しさん＠編集中
16/01/31 18:53:54.26 TP98Z0n+.net
たしかにプリセット変更で旧プリセットと同じビットレートでのSSIM落ちたけどちょっとしか落ちてないしその分早くなってるからいいや
あとveryfastなんかだと速度も上がってSSIMも上がってたりする。
776:名無しさん＠編集中
16/01/31 20:01:42.34 FzlptxAC.net
x265は今後もCPUのみの演算で貫くのかね？
GPUのメモリーがHBMやHBM2の導入でかなり速くなるし、バス速度や演算能力そのものも上がろうとしているわけだが、
相変わらず一部だけでもGPUに振り分けるよりCPUのみのほうがいいのかね？
777:名無しさん＠編集中
16/01/31 20:07:08.49 cFXQSVbu.net
x265の開発元が新しいコンパイラHCCの開発をするみたいだから
ヘテロジニアス対応は案外、早いかもしれない
778:名無しさん＠編集中
16/01/31 20:24:55.92 o77Jhxsk.net
>>755
P
779:CIeの遅さが何とかなれば、じゃないかな NVIDIAのNVLinkは一般PC環境では期待できないみたいだし AMDもなんか高速バスかなんかやっているみたいだけど普及するかわからない
780:754
16/02/02 13:26:49.31 NCVy8Op8.net
>>756-757
HBM2がメインストリームのCPUやAPUに採用される日
URLﾘﾝｸ(pc.watch.impress.co.jp)
この記事によるとHBM2がコストダウンすれば一般向けのPC環境でも利用できるようになる可能性はあるようだから、あとはコストとバス速度の問題がなんとかなればいいのかも。
いつまでもCPUオンリーって時代でもないだろうし。
781:名無しさん＠編集中
16/02/02 14:53:24.44 oWE9M/3S.net
>>758
HBMは容量と帯域ばかりの記事が多かったけどレイテンシも低いんだな
じゃないとグラボ向けに積まれないか
782:名無しさん＠編集中
16/02/02 19:03:54.47 NCVy8Op8.net
GPUって大抵2スロット専有するんだから、PCI-Exスロットも2スロット挿しにして2倍速いってなわけにはいかないのかなと妄想。
783:名無しさん＠編集中
16/02/03 15:02:46.32 juHubKYm.net
>>760
っ [SLI]
784:名無しさん＠編集中
16/02/03 17:41:33.40 +OWBi5Bj.net
Android版とかiOS版のx265なんて出ないものなのかね？
785:名無しさん＠編集中
16/02/03 18:20:21.38 63ziqI0j.net
バッテリで動く端末との相性は最悪だろ
786:名無しさん＠編集中
16/02/03 18:34:18.04 +OWBi5Bj.net
>>763
なんで？
ちょこっとしたビデオクリップを編集後にエンコードまで出来たら、外出先で重宝しそうなものだが。
USB給電がこれだけ普及し、iPad proみたいなのまで出てくると、エンコードくらい多少時間がかかってもモバイル機器でできたほうが消費電力的にもうれしいわけだが。
787:名無しさん＠編集中
16/02/03 18:36:25.29 xdk3hERs.net
ちょっと何言ってるか分かんない
788:名無しさん＠編集中
16/02/03 18:38:36.07 iehiN48C.net
x265はともかくカメラの画像をエンコードしてるチップにデータ送ってエンコードできたらなどと思うことはあるw
789:名無しさん＠編集中
16/02/03 20:06:23.57 stWNn/Ef.net
最近リリースされたx265どう？
良ければコンパイルし直そうかと思ってる
790:名無しさん＠編集中
16/02/03 20:30:41.98 3wA6RKbD.net
たかがビルドで人に聞かないと動けないって・・・
791:名無しさん＠編集中
16/02/03 21:05:22.98 yXDm8y7+.net
rigaya 氏の multilib ビルドバッチでビルドは楽させて頂いているｗｗ
ありゃ楽だ
792:名無しさん＠編集中
16/02/04 09:38:26.30 T7nDHZT/.net
>>764
その時間かかるって何日かかるんだ
モバイル用の非力CPUでのソフトエンコで
専用チップのエンコードならともかく
793:名無しさん＠編集中
16/02/04 11:37:30.45 +3HectuX.net
朝鮮人に句点は難しい。
794:名無しさん＠編集中
16/02/04 14:41:30.65 J/9ovht0.net
実際どのくらい差あるのかな？
i5 6600とsnapdragon801で50倍差くらい？
795:名無しさん＠編集中
16/02/04 14:50:52.72 +3HectuX.net
一部でもハードウェアの支援機能が使えればだいぶと話は変わるだろうね。
こんな記事もあるわけだし。
・ iPad Proは本当に4Kビデオ編集に使えるのか!? ガチ検証
URLﾘﾝｸ(av.watch.impress.co.jp)
796:名無しさん＠編集中
16/02/04 22:37:23.84 M4vC7LHq.net
ffmpegでx265のハードウェアエンコードってもうサポートされてる？
QSVでできるとありがたい＞IvyBridge使いとしては
797:名無しさん＠編集中
16/02/04 22:57:03.08 T7nDHZT/.net
？
798:名無しさん＠編集中
16/02/05 07:51:11.13 NlSCducd.net
x265はソフトエンコのためのソフトだ
ハードウェアエンコなどサポートされるわけがない
h.265(規格名 HEVC)とx265(ソフト名)の区別がついてないんだろうけど
QSVは固定回路
後からHEVC対応などできん
QSVでHEVC対応したのはSkylakeから
QSVでHEVC使いたいならSkylakeに買い換え
799:名無しさん＠編集中
16/02/05 12:12:20.92 35jGb+Wd.net
QSVは完全固定じゃないけどな。
800:名無しさん＠編集中
16/02/05 13:03:43.84 LD2LJSnr.net
コマンドラインからQSV使いたいんだろう。
まあH.265のスレに行くといい。
801:名無しさん＠編集中
16/02/05 13:40:15.88 nrq1jwhr.net
さらにソフトが対応しなきゃならんし
無知のドヤ顔知ったかはほんとどうにもならんといつも思う
802:名無しさん＠編集中
16/02/05 22:18:13.16 cHw5jbd1.net
>>776
Oh。。。そういうことなのね
しらんかったわ
H.264のハードウェアエンコで悦ってくるわﾉｼ
803:名無しさん＠編集中
16/02/17 00:08:44.49 q2blbE92.net
↓こちらの動画配信解説サイトを参考に
URLﾘﾝｸ(pecardy.vanu.jp)
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
804:名無しさん＠編集中
16/02/17 00:24:39.26 ctq6s7UU.net
ffmpeg も HandBrake もそうだけど、libx265 使うとそういう傾向になるみたいだね。
このスレの話しに紐付けるなら x265 で HEVC エンコしてみたらどうだろう。
ffmpeg で demux して動画部分を x265、音声部分を neroaac なりかまして
最後 remuxer 通すなり mp4box で mux すれば良い。
805:名無しさん＠編集中
16/02/17 00:52:00.93 LHOUYy6V.net
>>781
x265のfastとx264のveryslowだしなあ…
もう大分前のデータだしプリセット変更入ったからそこまで参考にはならないけど、
この辺のグラフ見れば必ずしもビットレート半分で同等の画質にはならないのが分かるはず。
>>302
>>365
>>381
>>406
807:名無しさん＠編集中
16/02/17 13:59:46.42 SngcRS/c.net
>>781
-tune zerolatency これやめたらどう？
808:名無しさん＠編集中
16/02/17 14:39:11.08 UvZou3Zff
ビットレート半分で同等の画質っていう謳い文句はx265のエンコード時間を度外視してx264と比較した場合の話でしょ
x265は複雑でx264で出来なかったような処理をする分時間が掛かるけどビットレートは少なくて済むってだけの話
x265の処理を簡単にしてx264と同じような速度でエンコードさせたら縮まないのは当然だと思う
809:名無しさん＠編集中
16/02/17 20:30:34.56 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 -
810:780
16/02/18 00:12:09.35 EKbwhu+3.net
皆さんアドバイスありがとうございますm(_ _)m
presetのfast/veryslowとか結構違いが効いてきそうですね。
slowにしてみたところ画質がだいぶ向上した気がします。
ただ負荷が高いのかエンコ配信中は画面がカクカクしてしまいましたが。
mediumくらいで折り合いを付けようかと思います。
> -tune zerolatency
このオプションは音ずれ防止用に入れました。
画質となにか関係ありますか？
> 主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
SSIM・PSNRは始めて聞きました。
x265から加わったオプションでしょうか。
画質に影響するオプションの用なのでちょっと調べてみようと思います。
あと>>781のx265オプションで配信テストをしていたところ、Windows10付属のWMPでは
画面が灰色になって再生できなかったけどVLC Media Playerでは正常に再生できたという
報告がありました。
811:名無しさん＠編集中
16/02/18 00:21:20.69 bnH8mLRR.net
言っておくけどSSIMやPSNRはあくまで「数字の上での正確性」だから、それだけを鵜呑みにしないように
個人的にはオプションよりビットレートをもっと盛るのを最初にするべきかと
-b:v 518kぐらいでやってみては？
（もっともx264ので画質・容量的に満足できるならx264でいいと思うけど）
812:名無しさん＠編集中
16/02/18 01:05:06.98 hHEKfc2c.net
>>787
>> -tune zerolatency
>このオプションは音ずれ防止用に入れました。
音ズレ防止にはならない。配信のラグを軽減するだけ
>画質となにか関係ありますか？
zerolatency no lookahead, no B frames, no cutree
( URLﾘﾝｸ(x265.readthedocs.org) )
私はすごく関係あると思うんですが。
813:名無しさん＠編集中
16/02/18 09:11:42.49 Z9lL4Edt.net
やっぱ配信用設定はBフレーム削っちゃうんだね
NVENCのHEVCみたいだ
814:名無しさん＠編集中
16/02/18 11:06:46.21 nlO5v3H8L
>>787
配信中カクカクするのは当然
お察しの通り負荷が高いから
要するにそれは配信する映像のフレームレートにエンコードのスピードが追いついていない
例えば30fpsの映像を配信しようとしてもエンコードできる速度が10フレーム/秒とかだったら20フレーム足りないわけで当然止まる(それかどんどん遅れていく)
PSNRもSSIMもx264の時代からある
ようするにエンコード前の元動画と比較してどれくらい差が出たかっていうのを数値化して表現するもの(テストの採点みたいな感じ)
しかし機械的に判断した上での数値だから実際の目で見たときに数値ほど綺麗 or 綺麗じゃないということも起こりうる
Bフレーム由来の音ズレ(確か数フレーム音が遅れる)現象はx264の時代からあるはずだけどぶっちゃけ見てて気になるほどではないはず
しかもBフレームを使わないとなると圧縮率は結構下がるから必要なビットレートは多くなってしまう
長くなったけど正直配信用途なら大人しくx264使って配信したほうが良いと思う
現状x264と比較してx265は遅すぎる上に視聴者側にコーデックの導入してもらわないとそもそも見えない場合もある
x264並みに速くしてしまったら結局x265の旨みである「低ビットレートでも高画質」ってのは実現しにくくなると思う
815:名無しさん＠編集中
16/02/18 17:44:58.53 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を使えば簡単に分かるわけだ
816:名無しさん＠編集中
16/02/18 18:13:49.28 xYEflaB1.net
ちなみにどの数値を見れば良いのかと言うとSSIMはAllの数値、PSNRはaverageの数値を見て比較してくれ
あとテスト用の動画はmp4じゃなくてもmkvでもtsでも何でも良い
817:名無しさん＠編集中
16/02/19 18:44:02.46 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 URLﾘﾝｸ(bitbucket.org)
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 URLﾘﾝｸ(bitbucket.org)
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 URLﾘﾝｸ(bitbucket.org)
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
818:名無しさん＠編集中
16/02/19 18:46:36.53 4YDtVCyu.net
書き忘れ
ffmpegで使うときは、output-depthじゃなく
-pix_fmt yuv420p10le
-pix_fmt yuv420p12le
で指定
819:780
16/02/19 22:23:59.21 pxdW5hFs.net
>>792
ありがとうございます。
早速SSIM/PSNRの数値を調べてみました。
たしかに皆さんがおっしゃるとおりzerolatencyを付けない方が
SSIM/PSNRの数値は上でした。
しかし今まで画質の善し悪しは主観的に判断するしか無いと思っていましたが
こうやって数値で確認する事もできるんですね。
いろいろパラメーターを変えつつSSIM/PSNRの数値を見て最適なポイントを
探してみようと思いますm(_ _)m
820:名無しさん＠編集中
16/02/19 23:27:22.99 9715NWZX.net
指標は便宜上使われてるだけで基本は主観で判断だと思うよ
コンピューターが許容できる違いと人間が許容できる違いは同じではないからね
821:名無しさん＠編集中
16/02/19 23:40:15.58 qSH2klIW.net
あと多分-tune ssim付けて比較しないと意味ない
822:名無しさん＠編集中
16/02/20 10:10:44.80 YhMIaURA.net
主観で判断なんてほぼ無理だろう
これができるならそれで飯が食べられる
まぁ、どこで妥協するかだろう
823:名無しさん＠編集中
16/02/20 11:04:23.50 K6y5yssU.net
あくまで指標
数値で画質が決まるならx264（例として）でpsnrやssimなんてtune作る必要がないからね
824:名無しさん＠編集中
16/02/20 11:37:36.59 k+agU2Eu.net
主観で判断出来ないなんて可哀想な人
825:名無しさん＠編集中
16/02/20 11:49:29.89 YhMIaURA.net
よっぽど悔しかったのかな
公式でも使われて、急にダンマリしちゃった人がいたな
826:名無しさん＠編集中
16/02/20 11:54:48.37 sO+hYrhk.net
自分の場合は最初に目で見て、これビットレート半分で画質同等って大げさじゃね？と思ってSSIM調べたらその通りだったって話だから順序逆なんだよな
827:名無しさん＠編集中
16/02/20 12:06:07.01 SpT3cwNh.net
極端な話見ている人にバレなければ元と全然別物でも問題無い
828:名無しさん＠編集中
16/02/20 12:22:21.53 K6y5yssU.net
基本は、「見てる人=自分だから」好きなようにとしか言いようがない
だけどわざわざ--tune psnrやらssim使って本番エンコする奇特な人もいるんだなと不思議に思ってる
829:名無しさん＠編集中
16/02/20 13:55:57.50 EIhIWuJR.net
本番エンコで使うなんて誰も言ってないような・・・
830:名無しさん＠編集中
16/02/20 14:49:46.80 K6y5yssU.net
たしかに・・
「最後は主観」を否定する人かと思って短絡的に書いたは
831:名無しさん＠編集中
16/02/20 16:02:15.78 BHDZ19yf.net
-tune psnrとssimは心理視覚を向上させるオプションを無効になり主観的な画質が悪くなるので使わない方が良いみたい
心理視覚と言うのは例えば人間の目で見て画質の違いが分かりにくい部分の画質を悪くして違いが分かりやすい部分の画質を良くすることで
同じビットレートでも主観的な画質が良くなるみたい。だけどSSIMとかPSNRは画質の違いが分かるので数値が低くなるようだ。
832:名無しさん＠編集中
16/02/26 10:29:06.48 i7aFZYs7.net
ssimでだいたい当たりを付けて、psy関連で仕上げじゃないのか？
x264もx265もかなり練り上げられてるから、俺にはssim無しの判断は無理だわ
ssimの0.001の違いなんて目で区別できん
シーンごとに同一フレーム拡大確認なんてなおさら
最後は主観で判断と言うより、好み次第じゃない？
833:名無しさん＠編集中
16/02/26 10:59:27.59 iu0kmo+a.net
それを主観で判断すると言うんじゃ
834:名無しさん＠編集中
16/02/26 12:24:00.84 ykLbS11Bg
自分の場合SSIMは0.98あたりにもなると主観で元の動画との区別が付かない画質になるからそれを基準にしてる
835:名無しさん＠編集中
16/02/26 16:24:08.79 i7aFZYs7.net
そうなのか
なら、語る余地無しだな
てっきりssimに頼らず目視でエンコ精度を判断してるのかと思った
12bitの効果はどう？
836:名無しさん＠編集中
16/02/26 16:35:14.80 bHaTV8wK.net
普段10bitでやっとるけど12bitにしてみたところで違いが分からなかったよ。
837:名無しさん＠編集中
16/02/26 17:41:29.90 m+0FG1+N.net
ID:i7aFZYs7
主観の意味分かってないの？
838:名無しさん＠編集中
16/03/09 17:54:53.68 imJr87Pl.net
x265vfwも出てるやん
URLﾘﾝｸ(sourceforge.net)
l
839:名無しさん＠編集中
16/03/09 18:23:15.11 qNQxWU8R.net
今時vfwなんてメリットあんのかね？
エンコ詳しくないニコ厨でもwiki見て簡単にmp4エンコできるのに
840:名無しさん＠編集中
16/03/09 18:29:23.70 9Y8nZSW1.net
関わるな
841:名無しさん＠編集中
16/03/13 09:20:31.95 weseHvkQ.net
rc-grainの効果はどう？
あまり効果を実感できない
842:名無しさん＠編集中
16/03/20 08:39:40.31 7J9mixui.net
最近完走しなくなった。
皆さんどうです？
OS入れ直して駄目ですので、x265疑ってるんですが。
どこのビルドも1.9は駄目な感じです。
843:名無しさん＠編集中
16/03/20 10:04:28.56 KHVZBQe4.net
エスパーさん出番ですよ
844:名無しさん＠編集中
16/03/20 11:38:36.85 dlNvEFCk.net
>>819
ちゃんと完走してるよ
muxerを最新のに変えてみるとか
845:名無しさん＠編集中
16/03/20 15:51:11.82 16IrSqAm.net
>>819
avisynthでMT使ってるとエスパーしてみる
846:名無しさん＠編集中
16/03/20 20:06:27.41 nKj/TuoV.net
MUXではなくエンコード自体が完了しないのです。
avisynthはMT使わずソース読ますだけの最小構成です。
皆さん問題ないんですね。
とりあえず自分の構成をもっと疑ってみます。
止まるのが規則性があったり無かったり意味不明なんですよね。
同じソースで3%数回続いた後、70%で止まったりorz
847:名無しさん＠編集中
16/03/20 20:40:06.24 Fu5UyCAR.net
短いソースで試してみたら
848:名無しさん＠編集中
16/03/20 22:59:05.03 oLphnsNe.net
そういう時はmemtest
自分の環境よりソフトの方を疑うというのが理解できない
849:名無しさん＠編集中
16/03/20 23:51:09.20 mbWz3Yxf.net
aviでエンコードしてからx265でエンコードは？
850:名無しさん＠編集中
16/03/21 09:44:15.65 PdR6lJIR.net
メモリテストはwin付属ので問題なかったのと、
OS入れ直し、avisynth入れ直しくらいはしました。
ソースも変えてます。
30分位のソースだとごくまれに完走します。
11月くらいまで動いてたのでハードはそこまで疑いたくないのですが。
851:名無しさん＠編集中
16/03/21 10:48:22.93 W3zX88FD.net
>>827
そうやって821が言うような定石を守らないから
切り分けができないんだと思うよ
まぁ仮にmemtestで落ちても
原因はメモリとは限らないんだけどね
852:名無しさん＠編集中
16/03/21 10:58:42.48 EJTslGgf.net
完走する事もあるならソースかハードの問題でしょ
頭おかしい
853:名無しさん＠編集中
16/03/21 11:15:49.32 IwyEIcSu.net
フルボッコで可哀想だからレスするけど
aviutl + x265guiでやってみたら？
854:名無しさん＠編集中
16/03/21 15:07:19.74 +Ik+xhI4.net
1.9で中途ファイルが出来たというのはうちでもあったな
以前の構成から変わったのってそこぐらいだから1.9の所為なんだろうなとは思った（リトライしたら通ったけど）
855:名無しさん＠編集中
16/03/21 17:40:19.97 U+Xdgxb4.net
同じ条件で上手くいく時といかない時があるって、ハード側が不安定なだけじゃね？
ソフト側の問題なら再現性はもっと高いと思うが
856:名無しさん＠編集中
16/03/21 18:39:37.32 +Ik+xhI4.net
ログ見たらフレームの入力に失敗してるっぽいな
avs側でYV12に変換してやると多分解決する
857:名無しさん＠編集中
16/03/21 20:18:58.92 3MEwZrZM.net
今は完走しないことについての話なのになんで入力の話してるんだよ
途中で色空間が変わってるとしたら
858:完全にスクリプトの問題じゃねーか
859:名無しさん＠編集中
16/03/21 20:41:01.66 Y85ZQ3tt.net
>>827
handbrakeかffmpegで試してみれ
860:823
16/03/21 21:38:39.05 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
861:823
16/03/21 21:45:05.55 vZIwSY4R.net
>>835
ソース読みをavisynth使わず読み込みをってことですか？
862:名無しさん＠編集中
16/03/21 21:58:07.85 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:
863:名無しさん＠編集中
16/03/21 23:05:25.98 diV0PO6C.net
pmode,pmeを無効にしてみるといいよ
同じような症状出てたけど、無効にしたら落ちなくなった
864:823
16/03/21 23:23:35.03 vZIwSY4R.net
とりあえず、>>838のランタイム入れてやってみてます。
>>839はその後改善がなかったら試してみます。
865:823
16/03/22 07:06:01.47 1A+V4fFh.net
>>838
ありがとうございます。
いきなり長時間物完走しました。
�
866:ｽ回か違うソースで試してみます。
867:823
16/03/31 22:20:13.67 OoJQ2UyX.net
10ソースくらい試してみましたが、
無事完走するようになりました。
皆様ありがとうございました。
868:名無しさん＠編集中
16/04/01 14:07:26.74 vYfELI/A.net
てかどこのビルドも駄目だと書いてるのにMSVCが原因だなんて普通思わねえよ
869:名無しさん＠編集中
16/04/01 16:49:59.34 dTL/+QgY.net
トラブルシューティングとしてビルドに使われたVCランタイムを入れるぐらいはしてもばちは当たらない
870:名無しさん＠編集中
16/04/02 09:22:23.23 CqXSpfM9.net
>>844
お前がはじめにそういえばよかった。
834だったらすまん。
871:名無しさん＠編集中
16/04/02 09:55:23.23 1E+gnV9U.net
>844も>838も同じ人物で私だけど
態度変えすぎだろう
872:名無しさん＠編集中
16/04/04 08:51:12.73 PHD6aaQD.net
YUV420ソースをYUV444にしてエンコするメリットはありますか？
873:名無しさん＠編集中
16/04/04 08:53:20.36 nVqmW/e9.net
どうして無いと思うわけ
874:名無しさん＠編集中
16/04/04 14:52:19.93 Gj1hPCli.net
どうしてあると思うわけ
875:名無しさん＠編集中
16/04/04 19:46:56.63 PHD6aaQD.net
>>848
有るとも無いとも言ってないですよ。
ぜひ、YUV420ソースのYUV444へのエンコを解説してください。
876:名無しさん＠編集中
16/04/04 20:08:35.41 GIgTDtel.net
自分で試せないの？
877:名無しさん＠編集中
16/04/04 20:14:10.84 aOfeiP7X.net
ファイル作って動画を見て、よくなっていたら採用、変わらないor悪くなっていたらやらない、でいいじゃない
エンコの目的なんて、自分が見るための保存用がほとんどだろうし
878:名無しさん＠編集中
16/04/05 02:19:50.59 /L9IqKot.net
目が肥えて後になって後悔するかもしれない
という発想がどうしてないのだろう・・・
879:名無しさん＠編集中
16/04/05 03:10:52.86 VRuHp+46.net
なんでこの流れでそんなズレた発想が出てくるんだろう・・・
880:名無しさん＠編集中
16/04/05 07:24:52.25 23Tspq3D.net
元ファイル(生TS?)も保存しておけばいいんじゃね？
881:名無しさん＠編集中
16/04/05 07:39:04.16 /18GblFb.net
エンコするために勉強する時間よりその時間で稼いでHDD買ったほうがいい
オリジナルのまま保存しとけば将来目が肥えても安心
882:名無しさん＠編集中
16/04/05 08:02:56.95 PkW1ygDm.net
趣味を否定してやるなよ
883:名無しさん＠編集中
16/04/05 15:04:07.31 9JEcOI0a.net
話をそらして質問者の否定ばかりで、誰も解説できない
おまら情けないな
まぁ、俺もだけどな
884:名無しさん＠編集中
16/04/05 15:54:06.00 oIluhigo.net
ソースが8ビットなんだから10ビットでエンコしても無意味って口？
885:名無しさん＠編集中
16/04/05 16:14:30.97 bXKjBZbc.net
>>850
> YUV420ソースのYUV444へのエンコ
・環境やプレーヤーによっては再生できなくなる。再生支援も効かない。
・データ量が増える。
・やるにしてもYUV420→YUV444変換で色差補間をどうすんのかとかちゃんと考えないといかんね。
やるだけアホらしいと思うけど。普通はYUV420のまま再生時にレンダラで補間させるし。
・つうことでメリットなんか無いだろ。
>>858
自演乙
>>859
そんな話は誰もしてねーと思うぜ。
886:名無しさん＠編集中
16/04/05 16:26:50.63 oIluhigo.net
同じこと
887:名無しさん＠編集中
16/04/05 20:35:58.64 9JEcOI0a.net
>>860
妄想乙
888:名無しさん＠編集中
16/04/05 20:44:23.74 +zekPSej.net
>>856
勉強ったってオプション弄ってできたものを評価していくだけじゃん
889:名無しさん＠編集中
16/04/05 22:25:10.00 DXAVhdGx.net
12bit エンコすんのはいいんだけど、どういう環境で見れば軽いとか綺麗とかってだれか試してるんかな
つか、みんなどのプレイヤーで見てんの？
890:名無しさん＠編集中
16/04/06 00:21:04.15 gavek0iz.net
>>864
12bitの
891:HEVCデコードに対応してるデコーダなんてLAVくらいじゃね。 デコーダからP016でレンダラに渡すことを考えるとmadVRかMPDNあたりが必要。 LAVで12bitYUV→RGB24変換してRGBでEVR等のレンダラに渡す方法もあるけど この場合色差補間とかがどうなるのかは知らん。 12bitは再生支援も対応しないだろうし、一般的な1667万色なPC環境では10bitで事足りるはずだし 10bitに比べてなにかメリットはあるのかね？
892:名無しさん＠編集中
16/04/06 06:58:25.58 BZiOzY8Z.net
的はずれな事ばかり
まず試してみなよ
感動するぞ
893:名無しさん＠編集中
16/04/06 09:34:00.56 oAh+1FS4.net
x264では444円個のほうがssimはよかった
なんでかはしらんけど、x265ではそうとは言えなかった
12bitは保存用に使ってるな
894:名無しさん＠編集中
16/04/06 19:13:30.16 LlUg6G6o.net
>>866
もしかして12bitエンコ自体やったことないか、プラシーボで喜んじゃうタイプ？
895:名無しさん＠編集中
16/04/06 20:01:05.75 cKZ87zcu.net
8bitと10itでは結構、良くなるから
10bitから12bitも多少は良くなるんじゃね
896:名無しさん＠編集中
16/04/06 21:36:40.18 TIHK3iW4.net
--aq-strength, --psy-rd, --psy-rdoqは調整次第で
大幅な容量orエンコ時間の増大なしで見た目をよくできると思うんだけど
それぞれ値を増やすとどういったところに変化が表れやすいか
教えてくれないかい
URLﾘﾝｸ(x265.readthedocs.org)
を読んだがpsyは読んでもよくわからんかった
897:名無しさん＠編集中
16/04/06 21:42:52.17 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と大差ないな。
898:名無しさん＠編集中
16/04/06 22:26:08.63 BZiOzY8Z.net
めくら
いや無能ってとこかな
899:名無しさん＠編集中
16/04/06 22:38:06.12 cKZ87zcu.net
>>870
自分はx265では圧縮率を求めて割とどうでもいいソースにしか使ってないからザルなテストしかしてないけど
x264ほど素直に画質に反映されず分かりづらい（まあ、それだけ優秀になってるってことなんだろうけど）
ベースになってるであろうx264の感じでは
AQ 人の肌などのアラ隠しに有用
psy-rd 動くエッジとか高周波部分が削られる
qcomp 何気に重要。大きくするとグレンから動く対象の再現性など画の完成度がとにかく高まる
だからAQはデフォ、psy系は低め、qcompは心なし上げて0.65で使ってる
最初に書いたけど画質は求めてないから期待しないで
900:名無しさん＠編集中
16/04/07 19:37:26.46 5GOclDJK.net
>>873
thx!
自分はqcompを0.75で使ってた
自分でも適当なソースで簡単な比較はしたけど、
AQ：上げると画質は向上したけど容量も増えた（x264ではそれほど増えた印象無）
psy-rd：上げると容量が少しだけ増えた（x264のほうが増加量が大きい印象）
psy-rdoq：上げるとソース由来の細かい部分が残るようになった
くらいしかわからんかった
2passでビットレート固定すると、SSIMは（見る意味があるかは置いといて）
AQとrdoqは極大値があったけど、rdは上げると下がる一方
よくわからんです
901:名無しさん＠編集中
16/04/07 20:14:01.22 xaya07W/.net
G11bitB10bitR11bitなら良いのにね。
902:869
16/04/07 21:37:16.65 kTK9FIEO.net
>>874
「だからAQは～」の行はx265での設定ね
ほぼ固定された動画だと面白いように縮むから使ってるけど
画質評価は本当に難しくなってるよね
903:名無しさん＠編集中
16/04/08 10:10:35.33 Rwrntj3b.net
littlepoxがプリセットを作ってくれてる
実写
slowerベース
URLﾘﾝｸ(forum.doom9.org)
veryslowベース
URLﾘﾝｸ(forum.doom9.org)
アニメ
URLﾘﾝｸ(forum.doom9.org)
904:名無しさん＠編集中
16/04/08 13:54:08.07 uoC7bHcg.net
キチガイ臭がするそいつ
905:名無しさん＠編集中
16/04/09 10:01:22.54 Q4UbIrNX.net
fhd以上、x265の汎用設定詰めることができる時点で普通ではない
時間と手間がハンパじゃない
906:名無しさん＠編集中
16/04/11 21:49:12.30 xwAKbqwo.net
>>877
一応アニメのを試してみた結果、普段使っている設定と同ビットレートで
比較してみたところ、見た目でもSSIMでも大きく画質が下がった
ノイズがひどい
907:名無しさん＠編集中
16/04/11 21:55:16.14 I6vlHsjj.net
「普段使っている設定」を書かずに報告しても意味ないような・・・
908:名無しさん＠編集中
16/04/11 22:25:47.80 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
比較の時はビットレート固定
909:名無しさん＠編集中
16/04/12 14:22:43.11 f5lHfaTk.net
画像サイズとビットレートも必要だよ
910:名無しさん＠編集中
16/04/12 18:33:03.38 BUSmDDzJ.net
>>883
1280x720, 2100 kbps（←深い意味はない）
911:名無しさん＠編集中
16/04/12 19:03:31.00 f5lHfaTk.net
ソースによるけど2Mbps程度ならdeblock 0:0にしてsaoも有効化
aq/psy系も下げたほうがいい結果になりそう＞873のプリセット
あくまでx264での知見も基にした当てずっぽうだけど
912:名無しさん＠編集中
16/04/12 19:29:21.87 BUSmDDzJ.net
同感
>>877で十分な画質（←人によるが）を得るためにはどれくらい高いbitrate
が必要になるのか
高いbitrateならデフォルトに近い設定でも十分な画質が得られるような気がする…
913:名無しさん＠編集中
16/04/12 19:34:16.49 1ATzc72f.net
>>882
・>>877の設定で出力する時にも--output-depth 10は付けたの？
・SSIMはどうやって測ったの？
・>>877のアニメというのは--tune animationを考えてみたという設定だから
refとかbframesとかmeとかその他もろもろは特に指定されてないけど、そのへんはどう設定したの？
そのへんがデフォ値のままなら>>882と比較しても意味がない気がする。
・>>882の設定ってveryslowより重そうな気もするし、--rc-lookahead 250とかになってるけど、
本当に普段この設定で使ってるの？
914:名無しさん＠編集中
16/04/12 19:56:15.84 IeZ3td+Lx
x265ってkeyintの値よりrc-lookaheadの値を大きくできるんだ
x264はkeyintの値までしか設定できなかったからそういうもんだと思ってた
915:名無しさん＠編集中
16/04/12 19:58:52.51 f5lHfaTk.net
与えるビットレートが違えばマッチするオプションも変わるだけじゃないの
916:名無しさん＠編集中
16/04/12 20:08:09.35 BUSmDDzJ.net
>>887
・--output-depth 10は付けた
・--ssim
・書いていないところは>>882と同様
・本当に使っている
1280x720で4fps程度の速さ（仕事から帰ってくるまでに終わればいい）
2600K@4.4GHzでエンコ
917:名無しさん＠編集中
16/04/12 22:07:20.02 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!
という警告が出るので、適切な計測結果にはなってないと思う。
918:名無しさん＠編集中
16/04/12 22:50:43.37 bnbtd3T9.net
つか、ほぼplacebo状態だな。
現状rd4の意味無いし（Currently same as 3 要するにデフォと一緒）、
rd上げるなら5。
で、そうするぐらいならpreset placeboで良いんじゃねーかと（笑
919:名無しさん＠編集中
16/04/13 19:12:35.06 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)
920:名無しさん＠編集中
16/04/14 06:23:31.29 SmTLnnP5.net
検証乙
SSIMを見る限り、>>882はveryslowより画質が良くslowerより早い
>>877を適�
921:pすることでmediumより画質が悪くslowerより遅くなる という認識でいいのかな？
922:名無しさん＠編集中
16/04/14 08:54:23.53 TL0trVBZ.net
ビットレート盛ったら（crf 20以下？）綺麗になると思う
923:名無しさん＠編集中
16/04/14 10:36:09.43 uaVnCBhc.net
ffmpegのssimの0.0001台の違いて見た目どんな違いなんだろう？
誰か解説頼みます。
924:名無しさん＠編集中
16/04/14 23:43:40.37 NwnHdn04.net
気にしたらハゲ
925:名無しさん＠編集中
16/04/14 23:47:05.40 i5ZA7JyZ.net
自分が良いと思ったセッティングでいいじゃない。
アニメなんかは誰に見せるわけでも無いんだし。
926:名無しさん＠編集中
16/04/15 00:44:21.13 +Fs+OHLX.net
--rc-lookahead 250 って怖ろしくメモリ食うんじゃないか？ｗ
40から80に上げただけでも1.4Gから2.4Gに跳ね上がってたのに
927:名無しさん＠編集中
16/04/15 01:48:34.93 KWIKv7Io.net
解像度などにもよるけどかなり食う
928:名無しさん＠編集中
16/04/15 01:58:08.47 Vj0XVi1o.net
ちょっと試してみたけど、>>893のサンプルだと
slower（-rc-lookahead 30） → 600MB
>>882（-rc-lookahead 250） → 2.6GB
だな。
929:名無しさん＠編集中
16/04/15 01:59:21.15 pgwZJlOQ.net
そういえば初期のx265ってメモリバカ食いしてたよね
930:名無しさん＠編集中
16/04/15 03:49:21.78 G5Tu0V3Z.net
メモリ食うだけで画質が上がるんなら数字上げてもいいんじゃないかな
メモリ足りないなら仕方ないけどね
931:名無しさん＠編集中
16/04/15 14:54:39.12 i2BOyiEg.net
>>893
リンク先のスレ読むとcffで使えと書いてあるぞ
932:名無しさん＠編集中
16/04/15 15:51:38.35 R0iR/RQZ.net
>>904
cffってなに？crfのこと？
リンク先というのは>>877のことだと思うけど、crfで使え（biｔrate指定じゃ駄目）なんて書いてないと思う。
933:名無しさん＠編集中
16/04/15 21:13:40.04 v5i5tBse.net
今時CBRなんてナンセンス
934:名無しさん＠編集中
16/04/15 23:16:50.52 xWoGZXDA.net
流れも読まない上にCBRってお前・・・
935:名無しさん＠編集中
16/04/15 23:31:22.66 WL/mTNMT.net
ﾈﾀﾆﾏｼﾞﾚｽ(・∀・)ｶｺﾜﾙｲ!!
936:名無しさん＠編集中
16/04/16 22:50:58.36 FapX/LQs.net
画質/負荷の効率が良いオプションって各preset間で
値が変わったり追加されたりするやつでいいのかな
ただし重いpresetに行くほど変化しているオプションの効率が悪くなるとかあるのかな
937:名無しさん＠編集中
16/04/16 23:15:07.78 RIWYlU/O.net
動き検索の重要度はsubme ＜ meだって猫さんが書いてたから
x265もそうだと思う
それとBフレやrefの枚数も3～4ぐらいでセーブしとくのもエンコ負荷の低減に役立つと思う
938:名無しさん＠編集中
16/04/17 16:13:38.77 E1zy7U5k.net
>>905
過去レスよく読め
939:名無しさん＠編集中
16/04/17 16:34:11.64 SQT/cZ/R.net
>>911
お前さんが>>906と同一人物で「いまどきbitrate指定エンコなんてやる奴いねーよ」とでも思ってるなら
>>893が「同一ビットレートでのSSIM比較」という目的で行われたことを全く理解してないことになるが・・・。
940:名無しさん＠編集中
16/04/18 13:09:32.53 4454Srxg.net
必死感漂ってるな
残念だけど、>>906じゃないし、用途によってはcbrを使う人がいるのは誰でもわかっていること
littleはvbrの設定を晒してるんだから、cbrでssim比較しても無意味
まぁ、妄想と決めつけが激しく頭が悪くても、がんばって行きろ
941:名無しさん＠編集中
16/04/18 14:53:46.23 xvx3IXAG.net
お前ら優位に立とうとする言葉選び好きだよな
942:名無しさん＠編集中
16/04/18 15:38:14.70 ZiaZImZR.net
>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味」
の根拠はなに？
・>>877の上２つのリンクには--crfも含まれてるけど、>>893で使った３つ目のリンクは
--tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
・「CBRの幻想」とかx265のhelpの--bitrateの説明とか読んだほうがいいような気がする。
943:名無しさん＠編集中
16/04/18 16:55:07.97 4454Srxg.net
>>915
>>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味じゃない」
の根拠はなに？
> --tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
思うのは自由だよ。でも、littleの一連のレス読んでから判断してね。
>・「CBRの幻想」とか
そんなこと言ってないよ。しっかり妄想と現実の区別してね。
まずは丁寧に文を理解することを習得しようね。短い文だから難しくないよ。
ｶﾞﾝｶﾞﾚ
944:名無しさん＠編集中
16/04/18 17:09:18.40 ZiaZImZR.net
ああ、やっぱり説明も話もまともに出来ない人だったか・・・お疲れさまでした。
945:名無しさん＠編集中
16/04/18 17:35:42.08 no/AiHFv.net
>>914
お前らと言うけど2レスだけだよ
946:名無しさん＠編集中
16/04/18 18:51:38.96 Sn6HnjyG.net
>>913
cbr≠abr であり、>>893はabrだと思う
abrはvbrで出来上がるものの平均ビットレートを指定してエンコじゃないのかな。。
ちなみにcbrの用途って何があるの？放送局？
947:名無しさん＠編集中
16/04/18 19:06:32.01 ZiaZImZR.net
割と知られてるページだと思ってたからタイトルしか書かなかったけど
>>916には通じなかったみたいだし、「"CBRの幻想"でググれ」と書くべきだったとちょっと反省。
948:名無しさん＠編集中
16/04/19 09:54:12.07 YZY7DcaM.net
>>920
？俺はcbrの善し悪しには何も触れてないぞ。話しのすり替えは止めようね。
短い文なんだからきちんと理解できるようになろうね。
自分の落ち度を認めず他の内容を無視するのも止めようね。
949:名無しさん＠編集中
16/04/19 11:48:28.42 7vkH9RtK.net
好きに使ったら良いのに、自分が良く使う設定に固執しすぎなんだよね。
950:名無しさん＠編集中
16/04/19 11:53:32.50 CfB8B13z.net
近代的なビデオコーデックで真のCBRなんて不可能っていう「CBRの幻想」って解説記事があるの
つまり1パスビットレート指定でも動作はVBRだと揚げ足を取られてるわけ
個人的にはcrf指定でも指定値が大きければ画質は悪くなり
ビットレート指定でもビットレートを大きく盛れば画質は良くなるわけだから
あまり意義のある言い争いじゃないと思う
951:名無しさん＠編集中
16/04/19 16:02:39.82 filiPvCp.net
もう何年前に読んだか忘れたけど、圧縮前に圧縮後予定ファイルサイズから逆算して
正確な圧縮品質を指定することは不可能かつ正確にファイルサイズを合わせることも不可能だから
って奴だよな
952:名無しさん＠編集中
16/04/19 17:28:26.53 YZY7DcaM.net
>>919
cbr≠abrなのはしってるよ
同一ビットレートで、ときてたからcbrといっただけですう
だから、handbrakeはサイズ指定のサポート止めたしね
907=910=918?
953:名無しさん＠編集中
16/04/19 17:40:38.84 ILdf6rCX.net
一応言っておくと俺はSSIMの計測結果を貼っただけであって、>>877や>>882とは別人。
CBRの件は別に揚げ足じゃなくて、helpでもABRという表現が使われてるし、
「CBRの幻想」の記事も踏まえて「CBR」という表現はあまり使わないほうがいいと思っただけ。
>>921にはまったく伝わらなかったみたいだし、なんか変な言い訳してるけど・・・。
よく見ると>>916は
「cbrでのSSIM比較が無意味ではないと主張する根拠はなに？」
と逆に問い返してるんだね。コピペミスかと思ったわ・・・。
俺は単に>>913の
・>>877はvbr（--crf）用の設定だ
・だからcbr（--bitrate）でSSIM比較しても無意味
という２つの主張の根拠がわからなくて知りたかっただけ。
これまで特に気にせずに２パスエンコも利用してSSIMを調べたり貼ったりしてたんだけど、
--bitrateだとうまく働かないオプションとかあるんだっけ・・・？
>>925はこれ以上相手にしても徒労に終わりそうだし、もし誰かわかるなら教えてほしい。
954:名無しさん＠編集中
16/04/19 17:44:29.70 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(
955: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)
956:名無しさん＠編集中
16/04/19 17:58:21.32 CfB8B13z.net
微妙に着眼点と主張がかみ合ってないからお互いにスルーするが吉
957:878
16/04/19 18:00:28.75 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
958:名無しさん＠編集中
16/04/19 18:56:00.56 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)
959:名無しさん＠編集中
16/04/19 19:20:19.87 0e3x1/oL.net
>>930
早速のエンコありがとう。
ちょっと重くなってしまったみたいだね。スマン
でも、画質はそれなりに改善したように見えるね。
960:名無しさん＠編集中
16/04/19 21:31:48.09 CfB8B13z.net
今のx265の場合、デフォのcrf値が大きすぎるんだよな
プリセット作るにしても決めきられない感じ
961:名無しさん＠編集中
16/04/20 10:32:47.35 /W4Johvo.net
プリセットなんてmedium(デフォルト)な時点でx264超えてるんだからどうでもいいよ
後は好きなcrf値を設定すればOK
なんか色んな設定やパラメータいじくり回すx264時代の因習に囚われてる人いるようだけどｗ
962:名無しさん＠編集中
16/04/20 10:52:36.60 O3XwBTuO.net
4K60Pがリファレンスなのにね
963:名無しさん＠編集中
16/04/20 14:21:23.87 9swemZrS.net
プリセットじゃなくプロファイルだった
964:名無しさん＠編集中
16/04/20 19:29:17.58 klJmlwQn.net
>>933
x264でも重ための設定でAQやpsy-rdなどを調整したらx265の
単純なmediumになら画質で勝るよ。
つまり、設定次第だと思う。