17/04/28 23:26:59.96 eUzMgdEP0.net
>>632
一応>>631のグラフにx265 veryslowも追加してみたけど、
SSIM/bitrateグラフでのラインとしてはslow,slowerと大して変わりない感じだね。
URLﾘﾝｸ(2sen.dip.jp)
634:名無しさん＠編集中
17/04/29 06:46:40.71 mJB4Zjya0.net
まだx265は未完成なんだろうなぁ
追加オプションがちゃんと機能してないからほとんど変わってないと思われる
635:名無しさん＠編集中
17/04/29 13:01:31.31 5p3huezy0NIKU.net
12月末にビルドしたバイナリより画質悪くなってるなぁ・・・
636:名無しさん＠編集中
17/04/29 13:06:21.29 dxaAtgLy0NIKU.net
x264より画質上げるのは至難の業だろうね
mpeg4系は圧縮のアラを隠ぺいする方向に進化してるから
シンプルな旧世代コーデックで高画質にできてるならそれ以上は無理
637:名無しさん＠編集中
17/04/29 13:37:34.15 CfE7T/6AMNIKU.net
>>663
同等エンコ速度でx264に比べて10%しか画質向上してないのかよ
veryslow同士でも20%しか向上してない
なにが半分のレートで済むだよ騙されるところだった
今後はx264に戻るわ
638:名無しさん＠編集中
17/04/29 13:50:19.89 waHaI7dF0NIKU.net
速度を求めるならそりゃx264のほうが良いだろうね現状は
そもそもH265は「同じ速度で半分のレートで済む」のではなくて「半分のレートで同等の品質を実現する」ってのが謳い文句なわけで
639:名無しさん＠編集中
17/04/29 14:28:56.05 CfE7T/6AMNIKU.net
その「半分のレートで同等の品質」すらx265は実現できてないじゃん
レート削減効果50%程度になりUHDブルーレイ規格に準拠できるようにオプション追加されたら起こしてくれ
それまでは汎用性重視でx264使う
640:名無しさん＠編集中
17/04/29 14:43:09.49 dxaAtgLy0NIKU.net
「すら」の使い方間違ってるで
641:名無しさん＠編集中
17/04/29 15:23:47.60 7YaV6zKaaNIKU.net
ちなみにX264とX265使って実際にビットレート半分で大差無いか実験した人いるの？
642:名無しさん＠編集中
17/04/29 16:18:28.03 waHaI7dF0NIKU.net
>>641
URLﾘﾝｸ(gigazine.net)
結局のところ見る人や再生する環境にもよる
現状半分まで行かなくてもH.264の6割から7割くらいのデータ量でほぼ同じ品質にはなるんじゃないかな
それも見る人、再生する環境、どういうソースをどういうオプションでエンコしたかとかによる
643:名無しさん＠編集中
17/04/29 23:30:39.55 dvKINc090NIKU.net
>>641
目視では無いけどSSIMとかPSNRでの比較なら過去スレで行われたな
644:名無しさん＠編集中
17/04/29 23:34:25.30 dxaAtgLy0NIKU.net
>>641
アニメなら結構頑張れる
その画質で満足できるかは別問題だけど
645:名無しさん＠編集中
17/04/30 07:48:13.80 48guLabb0.net
アニオタは実写に比べて圧倒的に色数やグラデーション低いのに、無駄に画質にこだわるわな
646:名無しさん＠編集中
17/04/30 08:13:50.20 Ii4RBPus0.net
画面が単純なほど粗が目立ちやすくなるからでしょ
647:名無しさん＠編集中
17/04/30 11:57:03.61 jEPKJ4r80.net
12bitのほうがサイズが小さくなったり、謎が多い
648:名無しさん＠編集中
17/04/30 12:04:52.53 usOzIqXsa.net
今ちょっとx264とx265を使って色々試してみたけど半分のビットレートで同等の画質はやっぱ今のところ無理っぽいね
業務用の高価なハードウェアエンコーダーとかなら出来るんだろうけど
649:名無しさん＠編集中
17/04/30 12:37:20.05 S8IaheQZ0.net
h264に対するh.265のアドバンテージが最も発揮されやすいのは、映像が圧縮向きの内容で、なおかつ比較するレートが低い場合だよ
例えば>>633とかは使ってるテスト素材が圧縮に不向きなこれだし高めのレートでの比較だからアドバンテージが表れにくい
URLﾘﾝｸ(i.ytimg.com)
650:名無しさん＠編集中
17/04/30 12:37:41.41 jEPKJ4r80.net
クリアな画質の実写がすごく得意。だから洋画には向いてると思う
651:名無しさん＠編集中
17/04/30 12:53:49.87 usOzIqXsa.net
>>649
うーん
そういう圧縮に向いてない絵柄をもっと小さく出来てこそアドバンテージになると思うんだけど違うのかな
652:名無しさん＠編集中
17/04/30 13:16:36.03 xXAmTovGa.net
不向きな素材でもx264より縮むんだからアドバンテージになるでしょ
653:名無しさん＠編集中
17/04/30 13:19:01.07 S8IaheQZ0.net
大雑把に言うとコーデックの性能差は映像の中の圧縮可能な特徴・成分をいかに取りこぼさず効率的に圧縮できるかで決まるものだから
そもそも圧縮可能じゃない特徴で満ちてる映像だとどんなコーデックでも大差ない仕事しかできなくなるんだよ
654:名無しさん＠編集中
17/04/30 13:19:28.26 usOzIqXsa.net
でも>>649によるとアドバンテージが表れにくいって話だよ
655:名無しさん＠編集中
17/04/30 13:21:33.50 usOzIqXsa.net
>>653
なるほどねえ
尺を通じてトータルで見ればデータはかなり圧縮される筈で
圧縮しにくいカットだけ抜き出して比較しても無意味って事か
656:名無しさん＠編集中
17/04/30 13:57:24.01 48guLabb0.net
民生用でマトモなH.265エンコーダーはこれしかないんだから、今後の改良に期待するしかない
MPEGが264ほど細かい仕様を公表してないっぽいから厳しいだろうけど
657:名無しさん＠編集中
17/04/30 14:04:48.94 bED0LQ1n0.net
実写ってさ、X264の場合粒子系の画質だと圧縮されにくいし
明るい日本のバラエティ系、ドキメンタリー系も圧縮されにくい
それはｘ265でも変わらないって事か
やっぱりさ、圧縮がいくら効率よくてもさ粒子質の画質にビットレートを抑えると
暗部はブロックノイズになるのも抑えられないって事になるのかな
単純な画像がより圧縮されるだけってことになる？
658:名無しさん＠編集中
17/04/30 14:05:05.01 T3TX6aDP0.net
>>648
業務用の高価なHWでも同じだと思う
だいたいのビデオコーデックの「半分のレートで～」ってのは解像度が一回り大きくなってるのを前提にしてると思う
659:名無しさん＠編集中
17/05/01 01:53:41.72 yJgdhctZa.net
>>657
粒子を荒くした映像って時間軸上も平面上もランダムだから圧縮には最も不向きだよね
ブロックノイズにはならないようある程度考慮はしてあるみたいだけど
ビットレートが上がるか粒子を潰したのっぺりしたグラデーションになるかしか無いような気がする
660:名無しさん＠編集中
17/05/01 08:03:48.97 ZU6/Rrwu0.net
演出上の意図でグレインノイズを載せたやつって一番厄介だな
661:名無しさん＠編集中
17/05/01 09:44:16.92 rHzATc4T0.net
>>641
圧縮具合はものによるがx264で画質に不満が無くなるとされるcrf19以下の品質を
x265で半分のビットレートで表現出来るかというと無理な話
低解像度、低ビットレートの条件なら謳い文句通りになると思う
トラフィックの削減を目指している事もあり、h265はモバイル向けなんだよ
662:名無しさん＠編集中
17/05/03 19:29:12.62 aonBlG3Y0.net
今の地上デジタル放送のビットレート（約14Mbps）で4K放送実現できるってのがH.265の謳い文句じゃない？
663:名無しさん＠編集中
17/05/03 19:34:23.87 oVIawGqt0.net
そんなことどこで言ってるんだ？
664:名無しさん＠編集中
17/05/03 20:00:17.19 slM11u540.net
4k/8kをBDに、ってのが最大のうたい文句
665:名無しさん＠編集中
17/05/03 21:04:29.60 XcGDD2x1M.net
地デジのビットレートとBDのレートは数倍違うが
666:名無しさん＠編集中
17/05/04 09:30:04.71 r2WWJZtz0.net
4k8k放送は、HWエンコーダーが高性能になっても放送用の速度維持する為にかなり低負荷な仕様になると思うのだが
本来の性能発揮できるのかね。下手するとMPEG2よりひどくなりそうな予感しかしない
試験放送の画質ってどんな感じなんでしょう
667:名無しさん＠編集中
17/05/05 16:36:48.23 pA0AuifG00505.net
伸びてると思ったら
また、知ったかがイキってるのか
668:名無しさん＠編集中
17/05/05 16:52:03.26 7L1WkNvu00505.net
知ったかの誰もが黙る完璧なレスを期待してみよう。
669:名無しさん＠編集中
17/05/08 11:47:41.13 fN8ySGc20.net
>>631
いまさらだけどｔｈｘ
どんどん見やすくなってるね
670:名無しさん＠編集中
17/05/09 01:02:59.86 HpXVkdwd0.net
下記オプションで変えた方がいい点などはありますでしょうか？
ソースはアニメのTSです
--crf 23 --vbv-bufsize 12000 --vbv-maxrate 12000 --aq-mode 2 --psy-rd 1 --psy-rdoq 1 --keyint 0 --me umh --subme 7 --sar 1:1
671:名無しさん＠編集中
17/05/09 20:12:34.46 qOc4G1FT0.net
subme森杉？
5以上は非現実的かと・・
672:名無しさん＠編集中
17/05/09 23:45:01.17 4B6cqW170.net
新しいの、また速くなってる・・・
673:名無しさん＠編集中
17/05/09 23:58:57.05 aulyagCI0.net
アニメのTSをAvisynthで960x720にリサイズしてSAR 4:3でエンコしてる異端だけど速度稼げてなかなか良い。
674:名無しさん＠編集中
17/05/10 00:04:22.10 KruT9Evd0.net
AvisynthでCPUをほぼフルに酷使する方法が何となくわかったし、
24分アニメを15分でhevc-720pでエンコできるようになった
もっといいCPU欲しくなってきたな
675:名無しさん＠編集中
17/05/10 09:37:05.08 bEaPVUCw0.net
>>673
1344x896でやってる俺からしたら王道以外の何物でもないな
676:名無しさん＠編集中
17/05/11 00:51:47.54 bhjNCYSh0.net
俺の環境じゃRyzen買ったらエンコ時間半分になるらしいから悩むｗ
677:名無しさん＠編集中
17/05/11 05:22:50.94 G+ZVXWa50.net
俺環だけどi5-6500からRyzen1700にしたけどエンコ時間は
4時間半くらい→3時間半くらい
だったよ…。
678:名無しさん＠編集中
17/05/11 20:41:44.92 Ga7luA0AM.net
アニメは解像度落とさない派
679:名無しさん＠編集中
17/05/11 21:02:50.19 fuulcAsGF.net
実写も解像度落とさない派
680:670
17/05/11 21:27:46.96 zRKYhiEq0.net
>>671
ありがとうございます。
psy-rdを減らすか迷っているのですが、おすすめありますでしょうか？
681:名無しさん＠編集中
17/05/12 00:02:37.69 U8fvP1vm0.net
>>680
自分は0.5でやってる
アニメにグレンは無いしrdoqは無効にしてる（付加されてたら諦めてる
んでAQ-modeは3で強さは0.6がマイブーム
・・ってここまで書いたら私的すぎて役に立たんか
682:名無しさん＠編集中
17/05/12 00:10:07.87 lJM8G7xR0.net
人に見せるわけでもないし自分さえよければそれでいいｗ
でもそれを参考にして自分もパラメータ気に入れば楽しいよね。
683:名無しさん＠編集中
17/05/12 00:53:01.59 EXwmMiWF0.net
しかし、迷うと全てエンコし直したくなる諸刃の剣
684:名無しさん＠編集中
17/05/12 04:56:38.33 UJVJ7S250.net
>>681
俺もAQ-mode 3は使うな
x264の頃から使ってたし
目で見てはっきり違いがわかるものは使う
685:名無しさん＠編集中
17/05/12 10:40:58.85 gtnUa06O0.net
>>677だけどRyzen1700のメモリを2133から2400に変えてみたらCPU使用率が100%に近づいて
エンコ速度上がったわ。
ソース(アニメの話数)が違ってるのであくまで参考程度のデータ。
1.95fps (i5-6500)
2.49fps (Ryzen1700定格 メモリ2133)
3.31fps (Ryzen1700定格 メモリ2400)
安定性重視なんで自分はOCしないけど、CPUメモリOCしたらかなりのエンコ速度になりそうだ。
686:名無しさん＠編集中
17/05/12 16:37:30.30 tfdWSZ5/0.net
さがっとるやないかーい（何か書き間違えてるんだろうけど）
687:名無しさん＠編集中
17/05/12 16:48:26.63 t6nB1T3eM.net
いやそれは1 2 3という順所ではないと思うが
あまりにもきれいに並んでいるから見間違えるが
688:名無しさん＠編集中
17/05/12 16:52:11.49 tfdWSZ5/0.net
>>687
ボケてた俺の勘違いを即座に理解して指摘してくれてありがとう・・・本当にありがとう・・・腹筋してくるわ・・・
689:名無しさん＠編集中
17/05/12 16:55:03.94 O9wwnZLm0.net
>>687
おー、よくわかったね
690:名無しさん＠編集中
17/05/12 20:04:58.86 U8fvP1vm0.net
>>685
ああ・・やっぱり
薄々感じてはいたけどメモリ帯域も影響するのか
691:670
17/05/12 22:23:40.02 PqFGzIh20.net
>>681
>>684
ありがとうございます。大変参考になりました。
692:名無しさん＠編集中
17/05/14 02:33:51.07 2H6mt4/K0.net
アニメで--no-rdoq-levelってどうだろう？
693:名無しさん＠編集中
17/05/14 14:05:04.00 uUJ9cNnK0.net
そこまで無効にする必要はないんじゃないの
694:名無しさん＠編集中
17/05/15 14:53:47.21 2frEPm5C0.net
>>685
アニメで3.31fps なんて、
どんな重い処理かけてるんだよ・・・
プラシーボレベルだろ
695:名無しさん＠編集中
17/05/15 16:55:48.41 APxSp9En0.net
>>694
x265_2.3+40_x64で1920x1080をslowerだよ。
オプションは ―crf 21 ―qpfile hoge.txt ―output-depth 10 で、
avsでフィルタはロゴ消しとインタレ解除だけ。
696:名無しさん＠編集中
17/05/15 17:02:30.21 vDSpvxyLd.net
x265で10bitならそうなるわな
697:名無しさん＠編集中
17/05/15 18:22:53.70 bj8Ua5EV0.net
slowなら10fpsぐらい出るけどね
698:名無しさん＠編集中
17/05/16 01:08:17.27 suUZApBF0.net
今最新のコミット確認したら AVX2 を使ったアセンブラレベルのコードに置き換えられた部分があるぽい。
うちの FX-8350 は AVX2 が無いからなんか悔しい感じだ。早く Ryzen にしてーわｗ
699:名無しさん＠編集中
17/05/16 05:27:59.56 J1UBdiv20.net
>>698
最近、Avisynthとかでもマルチスレッド対応フィルタが多いからね
Ryzen8コアにするとx265含めて軽く倍以上のスピードになったりする
アニメだったら 720p/エンコ速度40fps ぐらい出るエンコしても
かなり高画質のまま
700:名無しさん＠編集中
17/05/16 15:46:32.65 Wy6G+qvk0.net
>>698
Ryzenの場合AVX2を切った方が微妙にエンコ速くなるってベンチスレで書かれてたような。
701:名無しさん＠編集中
17/05/16 16:02:47.40 CN3vjyuk0.net
元がCで、そこからAVX2化で7倍速と書かれてるから
普通に恩恵にあずかれると思う
rigayaさんのコメント欄によればfmaを使わなければ目立ったペナルティーはないらしい
702:名無しさん＠編集中
17/05/18 16:09:41.38 J//hbtSe0.net
Ryzenはたしかに速いけどFXと比べてそんなに体感できるほど速いものなんだろうか？
エンコだけならFXも十分速いよね？ 持ってないから知らんけど
703:名無しさん＠編集中
17/05/18 17:06:05.44 liTjT1V1d.net
なんでも声に出しちゃうアホっているよな
704:名無しさん＠編集中
17/05/18 21:23:46.03 OQSARe0P0.net
>>698 >>701
コミットの文章的に、--me seaで差が出るのかと思って、Haswell環境（AVX2あり）で
rigaya氏ビルドの2.4+2と2.4+22（ともにx64版）で --crf 20 --me seaで
crowd_runをエンコして速度を比較してみたけど、ほぼ差は出なかった。
部分的な変更なので全体のエンコ速度に差が出るほどじゃないのかな。
705:名無しさん＠編集中
17/05/19 00:06:29.20 XSq/RbM90.net
--me sea --no-deblock --no-sao
ぱっと見ただけだけどこれらが必要だと思うよ
706:名無しさん＠編集中
17/05/19 00:17:50.69 XSq/RbM90.net
--wpp も必要だけどこれはデフォルトで使ってるから指定しなくてもいいかな
>>705の３つを明示すればたぶん>>698の効果が出ると思う
あとは、すべてのフレームで高速化するわけではなく被参照フレームに限られるぐらいかな
707:名無しさん＠編集中
17/05/19 15:23:05.73 MmsXEbU70.net
なんだそういう条件が必要だったのね
どうりで速度がほとんど変わらなかったはずだ
708:名無しさん＠編集中
17/05/19 16:05:15.27 BfUmY3M/0.net
>>705-706
>>704＋その条件で試したけど、やっぱり差は出なかった。
709:名無しさん＠編集中
17/05/19 17:32:15.16 ji/YSPqA0.net
ごめん、めっちゃねぼけてた
--me sea --no-wpp だ
--no-deblock --no-sao は必要なかった
710:名無しさん＠編集中
17/05/19 18:23:01.72 MmsXEbU70.net
wpp使えないって
よっぽどの画質狂ででもないと恩恵得られなさそう
711:名無しさん＠編集中
17/05/19 19:07:20.57 BfUmY3M/0.net
>>709
それでも特に差は出ないっぽい。全体に与える影響が小さいんじゃないかと思う。
712:名無しさん＠編集中
17/05/21 21:14:59.62 H9t65OYr0.net
品質指定で上限ビットレートを指定すると
未設定時から総ビットレートが減るのはわかるが逆に増えてしまうことも多いのが気になる
SSIM見るとIフレームのビットが削られてその分P,Bの画質がちょこっと上がってる傾向みたいだが挙動が謎
713:名無しさん＠編集中
17/05/21 22:08:01.45 6CJFiaUN0.net
制限なしよりIフレの画質が相対的に落ちるから
そのIからの画質低下を和らげるためにPとBにビットレを盛ってるんじゃないの
714:名無しさん＠編集中
17/05/29 23:56:22.27 kX0KfHXl0NIKU.net
ひ、卑猥とな？
715:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/05 01:24:27.96 liRH7buv0.net
auo [error]: x265が予期せず途中終了しました。x265に不正なパラメータ(オプション)が渡された可能性があります。
OCしたRyzenでエンコ中にこんなエラー吐き出されて止まるんだが、
これOCが原因なんかな。x265以外の動作は問題ないんだけど
止まるタイミングもエンコ開始から約5分～5時間でまちまち
5時間で止まったときはこんな状態↓
■CPU ： Ryzen7 1700
■動作クロック / 3.750Ghz Vcore ： 1.31250V
■コア温度 ： 約70℃
■メモリクロック 2400 CL15
■温度計測方法 ：HWMonitor
716:名無しさん＠編集中 (ﾜｯﾁｮｲ fd44-GFnO)
17/06/05 02:19:28.24 pT9pn26D0.net
>>715
試しにOCやめてみたらいいのでは。
717:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/05 09:09:41.65 Yb0OI5uO0.net
>>715
電圧低すぎ
1700Xは3.4GHz/1.3500Vだから
718:名無しさん＠編集中 (ﾜｯﾁｮｲ 0911-rLqX)
17/06/05 10:42:45.15 IL3qxMnz0.net
定格で動かして同じエラーが出たら初めて相談するもんだろう。そういう問題って。
719:名無しさん＠編集中 (ｽｯﾌﾟ Sdea-ujBP)
17/06/05 11:07:08.21 8leySFvXd.net
OCが当たり前みたいな風潮だからな
OCは不安定なのが常だとは考えもしないくなっちまったんだろう
720:名無しさん＠編集中 (ﾜｯﾁｮｲ 5e1f-k7rq)
17/06/05 19:49:53.90 OgwTP3Gz0.net
OCによるメリットとデメリットが考えるとアホと思うわ
721:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/06 00:10:11.08 qbv3/zqx0.net
>>717
なんで定格なのに電圧盛ってるん？
722:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/06 00:20:41.61 iCITU6I/0.net
>>721
k17tkのデフォ値が1.3500Vだったという話
723:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/06 01:32:51.46 qbv3/zqx0.net
そうなのか、ちょっと調べてみたけど
1700Xは定格電圧高いね、1800Xと同じ
rigaya氏は1.3750Vで3.85GHz安定させてたし
他の人の報告見ても1.3500Vなら3.8GHz位いけそうだけど
そろそろスレチだから引っ込む
724:名無しさん＠編集中 (ﾃﾄﾘｽ Sa52-pSAu)
17/06/06 08:28:52.54 h1bzwWyFa0606.net
インテル環境とAMD環境の引越し時に編集ソフトとX265(GUI-EX?)を
1から再インストールして(環境設定もやり直し)すると、その不正なパラメータ渡し
エラーが消えて通常エンコ終了出来るって、FX9370を低電圧化して使ってる婆ちゃが言ってた。
725:名無しさん＠編集中 (ﾃﾄﾘｽ 95dd-8/NL)
17/06/06 11:50:19.37 gVOU1y4J00606.net
--pme付けてるとかじゃないの
今はもうx264に戻したから詳しい事は忘れたがこのオプション付けてると途中で落ちる事があった
726:名無しさん＠編集中 (ﾃﾄﾘｽ Sdea-ujBP)
17/06/06 12:30:37.24 GpwQkBZEd0606.net
オプションあるけど、使えないってのたくさんあるみたいだしな
727:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 01:15:39.60 IxJ2ZmVQ0.net
>>723
1700の定格ってどこかで見れますかね？
就寝時用にクロック落すから参考にしたい
728:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 01:18:18.15 IxJ2ZmVQ0.net
>>725
そうそう俺も落ちまくった
ハードを疑ってたけど違ったのね
729:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/07 04:10:02.45 tohYPFhw0.net
>>727
BIOSでOCせずRyzenMaster起動すれば分かるよ
たしか1.18V位だったと思うけどうろ覚え
>>725
pmeは付けてない。pmodeは付けてるけど付ける前も落ちてた
730:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 17:00:33.24 IxJ2ZmVQ0.net
>>729
自分>722の1700X利用者でっせ
731:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/09 14:44:25.57 /2rWhqYD0.net
10bitエンコードって凄いのな
8bitエンコードのまま下手にパラメータいじるより目に見えて効果があった
732:名無しさん＠編集中 (ﾜｯﾁｮｲ 23ea-OlK+)
17/06/09 16:21:24.51 ZdlOYqrc0.net
x264もそうだったね
733:名無しさん＠編集中 (ﾜｯﾁｮｲ 1523-yTT2)
17/06/11 08:47:14.02 93Xf1T3r0.net
>>730
アイドル状態は常時電圧変動してたわ
ただ利用率100%で張り付いてる時は
3.2GHzで1.11250V固定
734:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/14 00:18:02.66 yMJcJmdk0.net
今ビルドして手に入るx265のSAOって前テストした時より良くなってる気がする
数か月ぶりにプリセット見直してこんな感じになった（ちなみにアニメ向け）
--preset slow --crf 21 --input-depth 8 --output-depth 10 --deblock -1:-1 --qcomp 0.7 --vbv-bufsize 10000 --vbv-maxrate 9000
--aq-mode 3 --aq-strength 0.6 --psy-rd 0.5 --psy-rdoq 0 --rdoq-level 2 --max-merge 5 --bframes 4 --ref 3 --weightb
--no-opt-qp-pps --no-opt-ref-list-length-pps --asm AVX2
rdoq-level はx264のtrellisほど効果は分からなかったから
本腰用batでは2、それ以外のは0で
前書いたやつ（一部オプションの感想）が転載されてたので一応、新しいのを全部を書いておく
>>733
うちもそんな感じ
3GHzだと0.984Vぐらいで動いてる
735:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/14 00:26:42.28 yMJcJmdk0.net
なお一番画質に影響したのは↓output-depth 8はゴミと言ってもいいレベル
--input-depth 8 --output-depth 10
736:名無しさん＠編集中 (ﾜｯﾁｮｲWW 854b-sCoW)
17/06/14 22:52:18.78 qF3SGDPB0.net
アニメのcrfってどれくらいがいいのかな？
今は20でやってる
737:名無しさん＠編集中 (ﾜｯﾁｮｲ b317-yC+1)
17/06/15 00:00:19.64 RBCPNwe00.net
低ければ低いほどいいと思うけど
元が放送波ならソースのアラを相当うまく補正しないと
下げても有意な差はない（元ソースのアラの再現性・保存性が良くなるだけだと思ってる
ぶっちゃけcrf22でも大して差はわからない
738:名無しさん＠編集中 (ﾜｯﾁｮｲ e3b1-yC+1)
17/06/15 01:31:05.08 2mkwJ42x0.net
低さにも限度がある
低すぎればソースよりサイズ膨らむだろうし
739:名無しさん＠編集中 (ﾜｯﾁｮｲWW 8b4b-oWh/)
17/06/15 13:08:23.61 h6jgR1Rw0.net
>>737,738
ありがとうございます。
ノイズ除去等はしないつもりなので、crf22にしてみようと思います。
740:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 12:21:10.34 Vm+ma6rU0.net
L-SMASHのmuxer.exeって、なんで入力ファイルが見つからないだけでクラッシュするんだろう・・・
741:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 20:41:35.32 t3li/Qf+0.net
入力ファイルが見つからない＝無いのと同じ
エンコーダ「エンコードしなければいけないソースが無いのに何をエンコすればいいの？」
っていうことじゃないの？ｗ
742:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 20:49:26.19 Vm+ma6rU0.net
いや、エラーメッセージ出して終了すればいいだけだろ。
なんで「プログラムは動作を停止しました」だかのダイアログを見せられなあかんねんと。
743:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 21:54:52.97 t3li/Qf+0.net
そんなの単純じゃん
エラーメッセージなんかまるで見ない（そもそもログすらまともに見ないでエラーのダイアログだけが無駄に気になっちゃうガイジが多いからだろ
うざいなら自分で修正すりゃ良いじゃん
ソースも公開されてんだし
744:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 22:03:04.45 Vm+ma6rU0.net
なんだか変な人を呼び出してしまったようだ・・・すまぬ。
745:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 22:06:50.03 t3li/Qf+0.net
あーダイアログはOSの問題だもんな
OSを修正すりゃ良いんじゃねｗ
746:名無しさん＠編集中 (ﾜｯﾁｮｲ c2ea-POtP)
17/07/05 22:13:06.39 Sreov/SH0.net
だいぶ前に報告されたバグだけどまだ直ってないの？
VFRmaniac Vのまにまに x264gui
ｽﾚﾘﾝｸ(avi板)
558 名前：名無しさん＠編集中[sage] 投稿日：2016/11/15(火) 19:10:12.99 ID:/BSskAhd
x265スレから。既に見てるような気もしますが、当人含めて誰もこっちに貼りに来ないので一応。
r1417で試したら確かにクラッシュしますね。
---
267 名無しさん＠編集中 sage 2016/11/11(金) 17:10:10.87 ID:i1JaPs2C
上にl-smashのmuxerの話が出てたからスレチなんだけど書かせて
muxerで指定したファイルがないと異常終了するの修正して欲しい
remuxerはエラー表示するだけ
結構前からのバグでバッチで流すのに面倒というか初歩の初歩かと
---
559 名前：名無しさん＠編集中[sage] 投稿日：2016/11/15(火) 22:07:37.16 ID:onzLsuks
>>558とは別人だけど
URLﾘﾝｸ(github.com)
ココのif文コメントアウトしたらうちでは正常にエラーメッセージが起こってクラッシュせずに終了するな
747:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 22:30:09.63 Vm+ma6rU0.net
>>746
rigaya氏ビルドのL-SMASH rev1450でクラッシュするから、まだ直ってないっぽい。
748:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fea-URZV)
17/07/06 01:12:16.18 0jVJ3apV0.net
>>746のとこコメントアウトしたら今度は正常にmuxした後にクラッシュするなあ
レジストリいじってエラーダイアログ自体を非表示にした方がいいかもしれないね
他のソフトのエラーダイアログも出なくなるけど
ｘｘｘEXEは動作を停止しました メッセージを表示させない｜きりんの雑記
URLﾘﾝｸ(ameblo.jp)
749:名無しさん＠編集中 (ﾜｯﾁｮｲ d739-zXdO)
17/07/06 12:58:37.37 n3ig2wPi0.net
>>748
その書き込みより後にたくさんcommitはいってるからその書き込みの情報は信用できないと思う
SEGVだからmuken氏に見てもらうしか無いな
750:名無しさん＠編集中 (ﾜｯﾁｮｲ 9717-rvkC)
17/07/06 17:52:34.28 tQGoojMa0.net
rawファイルさえあればエラーがでないんだから問題なくね？
751:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fea-URZV)
17/07/06 18:07:39.90 0jVJ3apV0.net
多分、batに不備があって途中で処理が止まっちゃうだろうね
752:名無しさん＠編集中 (ﾜｯﾁｮｲ d739-zXdO)
17/07/06 22:16:24.61 n3ig2wPi0.net
入力ファイルのチェックをバッチやシェル側でやれば良いんじゃない？
753:名無しさん＠編集中 (ﾜｯﾁｮｲ f744-rfzC)
17/07/06 22:21:59.29 vuDg0qe30.net
運用で対処すればいいじゃんと言われれば確かにその通りではあるけど、
>>746にもあるようにプログラムとしては明らかなバグだから直してもらえると嬉しいねという話ね。
754:名無しさん＠編集中 (ﾜｯﾁｮｲ 2144-A9YL)
17/07/14 00:53:49.06 J1C4bm5a0.net
Version 2.5
Release date - 13th July, 2017.
URLﾘﾝｸ(x265.readthedocs.io)
755:名無しさん＠編集中 (ﾜｯﾁｮｲ 1611-S4qQ)
17/07/14 01:08:56.41 GeLosK/E0.net
を、2.5 きたか!!
ちょっくらビルドしてこよう。
756:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 01:19:26.08 Ljds1+Tg0.net
x265ってVFRのレートコントロールには対応してないよね
24pと60pの混合なVFRをビットレート指定でエンコしたいときって
どうするのが一番いい？
757:名無しさん＠編集中 (ﾜｯﾁｮｲ 354f-PDtw)
17/07/14 12:10:48.70 CTXwjp490.net
x264
758:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/14 12:58:34.64 ZmGhVoRc0.net
低いほうに合わせればいい
759:名無しさん＠編集中 (ﾜｯﾁｮｲ 1611-S4qQ)
17/07/14 14:09:47.56 GeLosK/E0.net
気合いの120fps
760:名無しさん＠編集中 (ﾜｯﾁｮｲWW 634b-I8+U)
17/07/14 14:41:53.92 fEBkwWTr0.net
>>756
無知で申し訳無いのですがレートコントロールとはどのような物なのでしょうか？
761:名無しさん＠編集中 (ﾜｯﾁｮｲ ae9b-JuSQ)
17/07/14 17:58:34.09 eZ+cvx1f0.net
2行目にかいてあることじゃない
知らんけど
762:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/14 18:18:33.22 ZmGhVoRc0.net
>>760
最大ビットレートとかバッファサイズとかが規格から逸脱しないようにすること
763:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-z+eH)
17/07/14 23:07:39.62 4WOGuhaz0.net
質問者
「今のx264やx265だと2Kや4Kエンコでも新しい多コアCPU(16C/32T等)を
100%使い切れないんだけど、なんとかならない？」
RipBot264作者
「RipBot264を使えば１つ（または複数）のマシンで分散エンコーディングできるから
100%使い切れるぜ！」
x265開発陣
「RipBot264ってオープンソースになってないよね？
x264やx265を呼び出してるんだからGPLv2に従ってソース公開しないと駄目だよ？」
RipBot264作者
「(ﾟДﾟ )ヤベッ！(寄付を募ったりもしてるや・・・)」
x265 HEVC Encoder
URLﾘﾝｸ(forum.doom9.org)
RipBot264って古くからあるみたいだけど初めて知った。分散エンコード機能なんてあるんだね。
x264だとmuken氏が
「規格に準じて結合するなら--stitchableをつけたり諸々注意が必要」
みたいなツイートをしてたけど、RipBot264はそのへん考慮して結合してるんだろうか。
あとx265でバラバラにエンコして結合する時の注意って何かあるんだろうか？
764:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 23:30:07.69 Ljds1+Tg0.net
zonesで指定すればいいみたいだね
>>762
どっちかというと俺が気にしてるのはバッファアンダーフローとかじゃなくて、
何も考えずにやると60pの部分に24pの60/24=2.5倍のビットレートが割り当てられちゃうこと
CBRにするわけじゃないからきっかり2.5倍ってわけじゃないだろうけど
x265はフレームレートが違うって分からないからちゃんとビットレート計算できないだろうし
765:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 23:55:06.73 Ljds1+Tg0.net
>>759
同じフレーム重複して入れたら、ちゃんとそれを認識して特別な処理してくれればいいんだけど、
現状のx265はそんなに賢くないっぽくて、エンコ時間長くなるし、圧縮後のデータ量も増えるんだよね
>>760
URLﾘﾝｸ(slhck.info)
> What is “rate control”? It’s what a video encoder does when it decides how many bits to spend for a given frame.
与えられたフレームにどれだけのビットを割り当てるか決めること
1パスとか2パスとか、CBRとかVBRとか、CFRとか
エンコでは基本的なことだよ
766:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 01:21:14.10 3m6njqCx0.net
それにしてもレートコントロールが何かを知らないとは
細かいオプションがどうこう言ってるけど、基本がなってないな
1パスとか2パスとか、何か知らないで使ってたのか
767:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-A9YL)
17/07/15 02:00:41.29 0OYp2Ppe0.net
>>766
>>760は初心者が単純に質問しただけで、細かいオプションとかに言及してた形跡はないような。
768:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 02:10:30.42 3m6njqCx0.net
>>760-762
ここらへんの方たちは初心者だったか。それはすまぬ。勘違いだ
769:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-A9YL)
17/07/15 02:34:10.54 0OYp2Ppe0.net
>>768
俺も言葉の厳密な定義を正しく理解してるか自信はあまりないけど、
>>762が書いてる内容はレート制御の範疇に入るだろうから外していいんじゃないか。
770:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 17:58:35.45 3m6njqCx0.net
>>763
x264やx265のexeを起動してるだけなら、GPLを要求するのは難しいよ
ライブラリバージョン使ってるならGPLにしないとダメだけど
GPL原理主義みたいな人たちは宗教的なとこあるから、GPLを要求したいのは分かるけど
771:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 16:21:37.18 HpejTqPk0.net
2.5のリリースノートに
1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps.
とあったので2.4+2と2.5+3（ともにrigaya氏ビルド）で比較してみたら、
ビットレートもSSIMも完全一致するという結果になったんだけど、なんでだろう？
MediaInfoで見る限り、
URLﾘﾝｸ(bitbucket.org)
にある --const-vbv は有効にされてる模様。
SSIM/ビットレート図 → URLﾘﾝｸ(2sen.dip.jp)
772:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 16:22:28.34 HpejTqPk0.net
Histogram("luma")
オリジナル → URLﾘﾝｸ(2sen.dip.jp)
x264 r2833 medium18 → URLﾘﾝｸ(2sen.dip.jp)
x264 r2833 slower grain24 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.5+3 medium16 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.5+3 slow grain22 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.4+2 slow grain22 → URLﾘﾝｸ(2sen.dip.jp)
773:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 19:42:00.27 HpejTqPk0.net
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
ｽﾚﾘﾝｸ(jisaku板:796-797番)
774:名無しさん＠編集中(ﾜｯﾁｮｲ 354f-PDtw)
17/07/16 20:14:47.61 lE/bCIkh0.net
VBV設定してないってオチ？
775:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 21:36:13.64 HpejTqPk0.net
>>774
よくわかってないのだけど、単に --tune grain を指定しただけでは駄目なのかな？
776:名無しさん＠編集中 (ｽﾌﾟｯｯ Sd7f-RYCd)
17/07/24 11:04:19.38 DAPBP2DDd.net
>>763
これって分散エンコでググっても全く出てこないのな
x265にも対応してるみたいで最近も更新してる様だけど、分散エンコに関するブログ紹介は2012以降ぱたりと無くなる
日本語化で機能しなくなる？のが原因なんだろうか
777:名無しさん＠編集中
17/08/01 21:18:57.52 kTrSsjB50.net
URLﾘﾝｸ(pc.watch.impress.co.jp)
＞Vegaアーキテクチャでは、パックドの8-bit整数演算もサポートされた。
＞しかし、8-bit整数演算は、SAD(Sum of Absolute Difference:差の絶対値和)
＞演算のみサポートとなっている。動画などイメージ処理向けであり、
＞マシンラーニング向けの実装ではない。
x265のエンコに使えると良いな
778:名無しさん＠編集中
17/08/03 15:23:27.98 NWKbjdAs0.net
おすすめのオプションある？
ソースは解像度が720x480のアニメTS
779:名無しさん＠編集中
17/08/03 20:38:03.33 M9rDlJ6g0.net
デフォでOK。エンコ設定より前処理の方が何倍も重要
780:名無しさん＠編集中
17/08/04 23:35:07.10 ZTZ+gYb+0.net
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1 aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな＞aq-mode3
781:名無しさん＠編集中
17/08/05 00:39:17.43 9YOKH1fA0.net
aq-mode 1がオールマイティなのかな
アニメを10bitエンコードするとcrf 20～22でも暗部の輪郭(エッジ)が汚れやすくて少し気になる
なんとかできないものか
782:名無しさん＠編集中
17/08/05 01:26:48.87 YCAHTRys0.net
x264でエンコする
783:名無しさん＠編集中
17/08/05 01:37:12.34 FHp3bZ4Q0.net
エッジを保護したいならaq使わなければいい
当然のっぺりした部分がその分劣化するわけだが
784:名無しさん＠編集中
17/08/05 10:06:55.90 jnUNU58K0.net
>>781
aq-mode3のaq-strength 0.4ぐらいでやればいいじゃ？
785:名無しさん＠編集中
17/08/05 16:43:26.59 YCAHTRys0.net
strength値0.4くらいだとaq3使う利点あまりないからaq on/offどっちでも良いと思うよ
786:名無しさん＠編集中
17/08/05 21:01:05.73 jnUNU58K0.net
そうでもなかった気がする
実写には不向きだったけど
787:名無しさん＠編集中
17/08/12 21:18:45.62 4YeA1asg0.net
新しいオプション --refine-intra と --refine-inter が追加されたらしいから試してみたけど
Analyze level 10が必要って言われた
これって2passのみってこと？
788:名無しさん＠編集中
17/08/16 00:27:26.44 ubdOdQwr0.net
>>787
rigaya氏のx2.5+8 x64で試してみたけど、2パス目に入ってすぐにクラッシュしてしまい、うまく動かなかった。
そもそもこの指定方法であってるのかよくわからんけど・・・。
%avs2pipemod% -y4mp "%~1" | %x265% --y4m - --preset medium --bitrate 1000 --no-cutree --analysis-reuse-mode save --analysis-reuse-level 10 -o test.mp4
%avs2pipemod% -y4mp "%~1" | %x265% --y4m - --preset medium --bitrate 1000 --no-cutree --analysis-reuse-mode load --analysis-reuse-level 10 --scale-factor 2 --refine-intra 1 --refine-inter 1 -o test.mp4
789:名無しさん＠編集中
17/08/16 11:03:56.00 duFXfDfk0.net
>>788
解析ファイルを指定するオプションがあったはず
790:名無しさん＠編集中
17/08/16 14:35:46.41 y9oCilvW0.net
>>789
--analysis-reuse-fileのことだと思うけど、指定しなければx265_analysis.datになるし、指定しても駄目だった。
791:名無しさん＠編集中
17/08/23 11:31:49.09 osg+kKft0.net
x265 HEVC OpenCL or CUDA Encoder
URLﾘﾝｸ(bitbucket.org)
792:名無しさん＠編集中
17/08/23 17:22:10.57 eg+3M5BL0.net
夏休みの自由研究かな
793:名無しさん＠編集中
17/08/23 18:03:50.40 iIBnv5OG0.net
どのくらいパフォーマンス向上するのかな
794:名無しさん＠編集中
17/08/23 18:58:09.00 eg+3M5BL0.net
CPUの半分も出ればいいほうだな
795:名無しさん＠編集中
17/08/23 20:03:47.01 nxBulyrM0.net
>>791 を適当にビルドだけしてエンコしてみたけど別に速くなるとかなんもなかったな。
各ソースのコメントに openacc と付いてる部分で GPU 使ってるんだとは思うが。
796:名無しさん＠編集中
17/08/23 20:29:12.72 iIBnv5OG0.net
オリジナルのx265もopenaccが入って来てる
openacc有効にしてビルドすれば、それなりに高速化するらしい
797:名無しさん＠編集中
17/08/23 21:49:34.43 eg+3M5BL0.net
>>796
妄想が激しいなｗ
798:名無しさん＠編集中
17/09/01 19:12:31.73 ArSPPgcm0.net
>>788-790がそのままだったので、あらためてreuse,refine系を試した結果を連投。
■--analysis-reuse-levelのテスト１（640x360@24、1092frames）
●オプション
・--preset slower --pass 1 --bitrate 500 --no-cutree --analysis-reuse-mode save --analysis-reuse-level %reuseLevel%
・--preset slower --pass 2 --bitrate 500 --no-cutree --analysis-reuse-mode load --analysis-reuse-level %reuseLevel%
●1pass目の結果は省略（8.81～9.03fps）
●reuse無し
125.05s (8.73 fps), 499.16 kb/s, Avg QP:20.38
●reuseLevel=1、reuseファイルのサイズ：123KB
125.87s (8.68 fps), 499.35 kb/s, Avg QP:20.40
●reuseLevel=2、reuseファイルのサイズ：569MB
112.51s (9.71 fps), 498.51 kb/s, Avg QP:20.47
●reuseLevel=5、reuseファイルのサイズ：571MB
109.80s (9.95 fps), 498.51 kb/s, Avg QP:20.46
●reuseLevel=10、reuseファイルのサイズ：28.9MB
4.29s (254.72 fps), 493.20 kb/s, Avg QP:20.52
799:名無しさん＠編集中
17/09/01 19:13:31.68 ArSPPgcm0.net
■--analysis-reuse-levelのテスト２（1920x1080@23.976、2157frames）
●オプション
・テスト１と同様。ビットレート指定のみ9000に。
●1pass目の結果は省略（0.81～0.87fps）
●reuseLevel=1、reuseファイルのサイズ：234KB
2449.91s (0.88 fps), 8953.61 kb/s, Avg QP:18.21
●reuseLevel=2、reuseファイルのサイズ：8.81GB
2177.31s (0.99 fps), 8953.84 kb/s, Avg QP:18.24
●reuseLevel=5、reuseファイルのサイズ：8.85GB
2182.34s (0.99 fps), 8953.38 kb/s, Avg QP:18.23
●reuseLevel=10、reuseファイルのサイズ：595MB
89.42s (24.12 fps), 8921.43 kb/s, Avg QP:18.44
800:名無しさん＠編集中
17/09/01 19:14:31.78 ArSPPgcm0.net
■--refine-intra、--refine-interのテスト（640x360@24,1092frames）
●オプション
・--preset slower --pass 1 --bitrate 500 --no-cutree --analysis-reuse-mode save --analysis-reuse-level 10 --ctu %maxCU1% --min-cu-size %minCU1%
・--preset slower --pass 2 --bitrate 500 --no-cutree --analysis-reuse-mode load --analysis-reuse-level 10 --ctu %maxCU2% --min-cu-size %minCU2% --refine-intra %refine% --refine-inter %refine% --scale-factor 2
●--scale-factorの説明を元に--ctuと--min-cu-sizeを指定。いくつかのソースで試した限りでは
以下の４パターンの組み合わせのみ2pass目がクラッシュせずに動いた。
表記は「CTU-%maxCU1%-%minCU1%-%maxCU2%-%minCU2%」
●CTU-32-32-64-32
p1：29.30s (37.27 fps), 418.33 kb/s, Avg QP:22.78、reuseファイルのサイズ：20.7MB
p2(refine=1)：25.05s (43.60 fps), 540.76 kb/s, Avg QP:29.83
p2(refine=2)：19.11s (57.16 fps), 506.54 kb/s, Avg QP:24.69
p2(refine=3)：40.76s (26.79 fps), 507.85 kb/s, Avg QP:24.13
801:名無しさん＠編集中
17/09/01 19:15:21.46 ArSPPgcm0.net
●CTU-32-16-64-32
p1：49.65s (21.99 fps), 483.44 kb/s, Avg QP:21.72、reuseファイルのサイズ：26.3MB
p2(refine=1)：26.14s (41.78 fps), 521.65 kb/s, Avg QP:28.72
p2(refine=2)：19.01s (57.45 fps), 505.24 kb/s, Avg QP:23.90
p2(refine=3)：45.51s (24.00 fps), 506.25 kb/s, Avg QP:23.32
●CTU-16-16-32-16
p1：32.75s (33.34 fps), 482.39 kb/s, Avg QP:22.39、reuseファイルのサイズ：31.7MB
p2(refine=1)：28.34s (38.53 fps), 527.16 kb/s, Avg QP:28.71
p2(refine=2)：17.68s (61.78 fps), 507.18 kb/s, Avg QP:23.36
p2(refine=3)：51.62s (21.16 fps), 509.31 kb/s, Avg QP:22.73
●CTU-16-8-32-16
p1：81.67s (13.37 fps), 486.43 kb/s, Avg QP:22.25、reuseファイルのサイズ：40.2MB
p2(refine=1)：30.03s (36.36 fps), 524.99 kb/s, Avg QP:27.88
p2(refine=2)：18.08s (60.41 fps), 509.86 kb/s, Avg QP:23.36
p2(refine=3)：52.24s (20.91 fps), 510.78 kb/s, Avg QP:22.68
802:名無しさん＠編集中
17/09/01 19:16:26.42 ArSPPgcm0.net
■参考
1920x1080、2157framesでCTUサイズを指定した場合のreuseファイルのサイズ（ログ取り忘れ）
CTU-32-32-64-32→357MB、CTU-16-8-32-16→760MB
■コメント
１．reuse-levelの5がrectとampの情報を保存するようなので両者が有効になるslowerを使用。
２．reuse-levelの2と5はreuseファイルのサイズが極端にでかくなるが、
より多くの情報を保存するはずの10はなぜか比較的サイズが小さかった。(それでもでかいけど)
３．CTUサイズの指定については「2pass目がクラッシュしない組み合わせ」を総当たりで探しただけ。
４．x265guiEx v3.79で reuse、refine系の設定欄が追加されたが、
--scale-factor と --min-cu-size の設定欄が無いので、これらは追加コマンド欄で指定する必要がある。
また --refine-mv の設定欄も無い模様。
803:名無しさん＠編集中
17/09/01 19:17:41.13 ArSPPgcm0.net
■最後に
--analysis-reuse系のオプションの使いどころやメリットがよくわからないと思って
調べていたら、x265開発陣が以下のようなコメントをしていた。
URLﾘﾝｸ(forum.doom9.org)
概要
> ライバルもいるから詳細はあまり説明したくないんだけど、基本的には
> (UHDkitで)ライブエンコード時の速度アップや、オフラインエンコード時の
> 計算効率アップのソリューションを提供するための仕組み。
> x265を単体で使っている人には特にメリットもないし、高品質になるわけでもない。
なお上のコメントはreuse系オプションのことなので、refine系についてはまた別。
refine系の効果までは検証していないので、オプションの説明以上のことは不明。
804:名無しさん＠編集中
17/09/07 19:56:07.66 HahZrfhH0.net
qpmin=0はコマンドもない気がするけど何か入れないとでてこないタイプですか？
805:名無しさん＠編集中
17/09/07 20:37:21.32 lQ8OTYTC0.net
>>804
x265.exe --help
> Use --log-level full --help for a full listing
806:名無しさん＠編集中
17/09/07 20:59:50.49 HahZrfhH0.net
>>804
ありがとうございます
807:名無しさん＠編集中
17/09/08 18:14:05.76 I9BkB4D70.net
>>806
× >804
○ >805