x265 rev3©2ch.net

**名無しさん＠編集中転載ダメ©2ch.net** · 2016/05/03(火) 19:09:55.21

H.265/HEVCのコマンドラインエンコーダーであるx265について語るスレです。
AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。

[本家]
http://x265.org/index.html
https://bitbucket.org/multicoreware/x265/wiki/Home

[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265

[バイナリ]
http://x265.ru/en/builds
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")

[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/blog-entry-402.html
http://rigaya34589.blog135.fc2.com/blog-entry-540.html

[ドキュメント]
http://x265.readthedocs.org/en/default/index.html

[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。

[前スレ]
x265 rev2
http://echo.2ch.net/test/read.cgi/avi/1418252184/

**名無しさん＠編集中** (ﾜｯﾁｮｲ d517-yTT2) · 2017/06/14(水) 00:18:02.66

今ビルドして手に入る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ぐらいで動いてる

**名無しさん＠編集中** (ﾜｯﾁｮｲ d517-yTT2) · 2017/06/14(水) 00:26:42.28

なお一番画質に影響したのは↓output-depth 8はゴミと言ってもいいレベル

--input-depth 8 --output-depth 10

2017/06/14(水) 22:52:18.78

アニメのcrfってどれくらいがいいのかな？
今は20でやってる

**名無しさん＠編集中** (ﾜｯﾁｮｲ b317-yC+1) · 2017/06/15(木) 00:00:19.64

低ければ低いほどいいと思うけど
元が放送波ならソースのアラを相当うまく補正しないと
下げても有意な差はない（元ソースのアラの再現性・保存性が良くなるだけだと思ってる
ぶっちゃけcrf22でも大して差はわからない

**名無しさん＠編集中** (ﾜｯﾁｮｲ e3b1-yC+1) · 2017/06/15(木) 01:31:05.08

低さにも限度がある
低すぎればソースよりサイズ膨らむだろうし

2017/06/15(木) 13:08:23.61

>>737,738
ありがとうございます。
ノイズ除去等はしないつもりなので、crf22にしてみようと思います。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0144-Qvj1) · 2017/07/05(水) 12:21:10.34

L-SMASHのmuxer.exeって、なんで入力ファイルが見つからないだけでクラッシュするんだろう・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6dd1-CicO) · 2017/07/05(水) 20:41:35.32

入力ファイルが見つからない＝無いのと同じ
エンコーダ「エンコードしなければいけないソースが無いのに何をエンコすればいいの？」

っていうことじゃないの？ｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0144-Qvj1) · 2017/07/05(水) 20:49:26.19

いや、エラーメッセージ出して終了すればいいだけだろ。
なんで「プログラムは動作を停止しました」だかのダイアログを見せられなあかんねんと。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6dd1-CicO) · 2017/07/05(水) 21:54:52.97

そんなの単純じゃん
エラーメッセージなんかまるで見ない（そもそもログすらまともに見ないでエラーのダイアログだけが無駄に気になっちゃうガイジが多いからだろ
うざいなら自分で修正すりゃ良いじゃん
ソースも公開されてんだし

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0144-Qvj1) · 2017/07/05(水) 22:03:04.45

なんだか変な人を呼び出してしまったようだ・・・すまぬ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6dd1-CicO) · 2017/07/05(水) 22:06:50.03

あーダイアログはOSの問題だもんな
OSを修正すりゃ良いんじゃねｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ c2ea-POtP) · 2017/07/05(水) 22:13:06.39

だいぶ前に報告されたバグだけどまだ直ってないの？

VFRmaniac　Vのまにまに　x264gui
http://echo.2ch.net/test/read.cgi/avi/1252765934/
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とは別人だけど
https://github.com/l-smash/l-smash/blob/master/importer/importer.c#L105
ココのif文コメントアウトしたらうちでは正常にエラーメッセージが起こってクラッシュせずに終了するな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0144-Qvj1) · 2017/07/05(水) 22:30:09.63

>>746
rigaya氏ビルドのL-SMASH rev1450でクラッシュするから、まだ直ってないっぽい。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9fea-URZV) · 2017/07/06(木) 01:12:16.18

>>746のとこコメントアウトしたら今度は正常にmuxした後にクラッシュするなあ

レジストリいじってエラーダイアログ自体を非表示にした方がいいかもしれないね
他のソフトのエラーダイアログも出なくなるけど

ｘｘｘEXEは動作を停止しました　メッセージを表示させない｜きりんの雑記
http://ameblo.jp/kilin/entry-12035280841.html

**名無しさん＠編集中** (ﾜｯﾁｮｲ d739-zXdO) · 2017/07/06(木) 12:58:37.37

>>748
その書き込みより後にたくさんcommitはいってるからその書き込みの情報は信用できないと思う
SEGVだからmuken氏に見てもらうしか無いな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9717-rvkC) · 2017/07/06(木) 17:52:34.28

rawファイルさえあればエラーがでないんだから問題なくね？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9fea-URZV) · 2017/07/06(木) 18:07:39.90

多分、batに不備があって途中で処理が止まっちゃうだろうね

**名無しさん＠編集中** (ﾜｯﾁｮｲ d739-zXdO) · 2017/07/06(木) 22:16:24.61

入力ファイルのチェックをバッチやシェル側でやれば良いんじゃない？

**名無しさん＠編集中** (ﾜｯﾁｮｲ f744-rfzC) · 2017/07/06(木) 22:21:59.29

運用で対処すればいいじゃんと言われれば確かにその通りではあるけど、
>>746にもあるようにプログラムとしては明らかなバグだから直してもらえると嬉しいねという話ね。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2144-A9YL) · 2017/07/14(金) 00:53:49.06

Version 2.5
Release date - 13th July, 2017.
http://x265.readthedocs.io/en/default/releasenotes.html

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1611-S4qQ) · 2017/07/14(金) 01:08:56.41

を、2.5 きたか!!
ちょっくらビルドしてこよう。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/14(金) 01:19:26.08

x265ってVFRのレートコントロールには対応してないよね
24pと60pの混合なVFRをビットレート指定でエンコしたいときって
どうするのが一番いい？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 354f-PDtw) · 2017/07/14(金) 12:10:48.70

x264

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0117-S4qQ) · 2017/07/14(金) 12:58:34.64

低いほうに合わせればいい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1611-S4qQ) · 2017/07/14(金) 14:09:47.56

気合いの120fps

2017/07/14(金) 14:41:53.92

>>756
無知で申し訳無いのですがレートコントロールとはどのような物なのでしょうか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ ae9b-JuSQ) · 2017/07/14(金) 17:58:34.09

2行目にかいてあることじゃない
知らんけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0117-S4qQ) · 2017/07/14(金) 18:18:33.22

>>760
最大ビットレートとかバッファサイズとかが規格から逸脱しないようにすること

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4644-z+eH) · 2017/07/14(金) 23:07:39.62

質問者
　「今のx264やx265だと2Kや4Kエンコでも新しい多コアCPU(16C/32T等)を
　　100%使い切れないんだけど、なんとかならない？」

RipBot264作者
　「RipBot264を使えば１つ（または複数）のマシンで分散エンコーディングできるから
　　100%使い切れるぜ！」

x265開発陣
　「RipBot264ってオープンソースになってないよね？
　　x264やx265を呼び出してるんだからGPLv2に従ってソース公開しないと駄目だよ？」

RipBot264作者
　「(ﾟДﾟ )ヤベッ！(寄付を募ったりもしてるや・・・)」

x265 HEVC Encoder
https://forum.doom9.org/showthread.php?p=1811649#post1811649

RipBot264って古くからあるみたいだけど初めて知った。分散エンコード機能なんてあるんだね。
x264だとmuken氏が
　「規格に準じて結合するなら--stitchableをつけたり諸々注意が必要」
みたいなツイートをしてたけど、RipBot264はそのへん考慮して結合してるんだろうか。
あとx265でバラバラにエンコして結合する時の注意って何かあるんだろうか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/14(金) 23:30:07.69

zonesで指定すればいいみたいだね

>>762
どっちかというと俺が気にしてるのはバッファアンダーフローとかじゃなくて、
何も考えずにやると60pの部分に24pの60/24=2.5倍のビットレートが割り当てられちゃうこと

CBRにするわけじゃないからきっかり2.5倍ってわけじゃないだろうけど
x265はフレームレートが違うって分からないからちゃんとビットレート計算できないだろうし

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/14(金) 23:55:06.73

>>759
同じフレーム重複して入れたら、ちゃんとそれを認識して特別な処理してくれればいいんだけど、
現状のx265はそんなに賢くないっぽくて、エンコ時間長くなるし、圧縮後のデータ量も増えるんだよね

>>760
http://slhck.info/video/2017/03/01/rate-control.html
> 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とか
エンコでは基本的なことだよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/15(土) 01:21:14.10

それにしてもレートコントロールが何かを知らないとは
細かいオプションがどうこう言ってるけど、基本がなってないな
1パスとか2パスとか、何か知らないで使ってたのか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4644-A9YL) · 2017/07/15(土) 02:00:41.29

>>766
>>760は初心者が単純に質問しただけで、細かいオプションとかに言及してた形跡はないような。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/15(土) 02:10:30.42

>>760-762
ここらへんの方たちは初心者だったか。それはすまぬ。勘違いだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4644-A9YL) · 2017/07/15(土) 02:34:10.54

>>768
俺も言葉の厳密な定義を正しく理解してるか自信はあまりないけど、
>>762が書いてる内容はレート制御の範疇に入るだろうから外していいんじゃないか。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 35db-MRQN) · 2017/07/15(土) 17:58:35.45

>>763
x264やx265のexeを起動してるだけなら、GPLを要求するのは難しいよ
ライブラリバージョン使ってるならGPLにしないとダメだけど
GPL原理主義みたいな人たちは宗教的なとこあるから、GPLを要求したいのは分かるけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ f644-A9YL) · 2017/07/16(日) 16:21:37.18

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で見る限り、
　https://bitbucket.org/multicoreware/x265/commits/bce945545c241ce4bb87d56d283ac8226d862ed5
にある --const-vbv は有効にされてる模様。

SSIM/ビットレート図 → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3430.jpg

**名無しさん＠編集中** (ﾜｯﾁｮｲ f644-A9YL) · 2017/07/16(日) 16:22:28.34

Histogram("luma")
　　オリジナル　　　　　　　　　　→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3431.png
　　x264 r2833 medium18　　　→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3432.png
　　x264 r2833 slower grain24 → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3433.png
　　x265 2.5+3 medium16　　　 → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3434.png

　　x265 2.5+3 slow grain22　　→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3436.png

　　x265 2.4+2 slow grain22　　→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3435.png

**名無しさん＠編集中** (ﾜｯﾁｮｲ f644-A9YL) · 2017/07/16(日) 19:42:00.27

ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
　http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797

2017/07/16(日) 20:14:47.61

VBV設定してないってオチ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ f644-A9YL) · 2017/07/16(日) 21:36:13.64

>>774
よくわかってないのだけど、単に --tune grain を指定しただけでは駄目なのかな？

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sd7f-RYCd) · 2017/07/24(月) 11:04:19.38

>>763
これって分散エンコでググっても全く出てこないのな
x265にも対応してるみたいで最近も更新してる様だけど、分散エンコに関するブログ紹介は2012以降ぱたりと無くなる
日本語化で機能しなくなる？のが原因なんだろうか

**名無しさん＠編集中** (ﾜｯﾁｮｲ da91-HJpE) · 2017/08/01(火) 21:18:57.52

http://pc.watch.impress.co.jp/docs/column/kaigai/1073276.html

＞Vegaアーキテクチャでは、パックドの8-bit整数演算もサポートされた。
＞しかし、8-bit整数演算は、SAD(Sum of Absolute Difference:差の絶対値和)
＞演算のみサポートとなっている。動画などイメージ処理向けであり、
＞マシンラーニング向けの実装ではない。

x265のエンコに使えると良いな

2017/08/03(木) 15:23:27.98

おすすめのオプションある？
ソースは解像度が720x480のアニメTS

**名無しさん＠編集中** (ﾜｯﾁｮｲ 85db-/FH4) · 2017/08/03(木) 20:38:03.33

デフォでOK。エンコ設定より前処理の方が何倍も重要

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0d17-/FH4) · 2017/08/04(金) 23:35:07.10

しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1　aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな＞aq-mode3

**名無しさん＠編集中** (ﾜｯﾁｮｲ abe5-V3Ru) · 2017/08/05(土) 00:39:17.43

aq-mode 1がオールマイティなのかな
アニメを10bitエンコードするとcrf 20～22でも暗部の輪郭(エッジ)が汚れやすくて少し気になる
なんとかできないものか

**名無しさん＠編集中** (ﾜｯﾁｮｲ bbea-gAma) · 2017/08/05(土) 01:26:48.87

x264でエンコする

**名無しさん＠編集中** (ﾜｯﾁｮｲ ebf9-/FH4) · 2017/08/05(土) 01:37:12.34

エッジを保護したいならaq使わなければいい
当然のっぺりした部分がその分劣化するわけだが

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0d17-/FH4) · 2017/08/05(土) 10:06:55.90

>>781
aq-mode3のaq-strength 0.4ぐらいでやればいいじゃ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ bbea-gAma) · 2017/08/05(土) 16:43:26.59

strength値0.4くらいだとaq3使う利点あまりないからaq on/offどっちでも良いと思うよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0d17-/FH4) · 2017/08/05(土) 21:01:05.73

そうでもなかった気がする
実写には不向きだったけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ a317-aEKd) · 2017/08/12(土) 21:18:45.62

新しいオプション --refine-intra と --refine-inter が追加されたらしいから試してみたけど
Analyze level 10が必要って言われた

これって2passのみってこと？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0344-UyPk) · 2017/08/16(水) 00:27:26.44

>>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

**名無しさん＠編集中** (ﾜｯﾁｮｲ a317-aEKd) · 2017/08/16(水) 11:03:56.00

>>788
解析ファイルを指定するオプションがあったはず

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9a44-UyPk) · 2017/08/16(水) 14:35:46.41

>>789
--analysis-reuse-fileのことだと思うけど、指定しなければx265_analysis.datになるし、指定しても駄目だった。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 094f-xMhe) · 2017/08/23(水) 11:31:49.09

x265 HEVC OpenCL or CUDA Encoder
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder

**名無しさん＠編集中** (ﾜｯﾁｮｲ 09db-oL0b) · 2017/08/23(水) 17:22:10.57

夏休みの自由研究かな

2017/08/23(水) 18:03:50.40

どのくらいパフォーマンス向上するのかな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 09db-oL0b) · 2017/08/23(水) 18:58:09.00

CPUの半分も出ればいいほうだな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3911-oL0b) · 2017/08/23(水) 20:03:47.01

>>791 を適当にビルドだけしてエンコしてみたけど別に速くなるとかなんもなかったな。
各ソースのコメントに openacc と付いてる部分で GPU 使ってるんだとは思うが。

2017/08/23(水) 20:29:12.72

オリジナルのx265もopenaccが入って来てる
openacc有効にしてビルドすれば、それなりに高速化するらしい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 09db-oL0b) · 2017/08/23(水) 21:49:34.43

>>796
妄想が激しいなｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:12:31.73

>>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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:13:31.68

■--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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:14:31.78

■--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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:15:21.46

●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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:16:26.42

■参考
　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 の設定欄も無い模様。
　

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3344-O4z1) · 2017/09/01(金) 19:17:41.13

■最後に
--analysis-reuse系のオプションの使いどころやメリットがよくわからないと思って
調べていたら、x265開発陣が以下のようなコメントをしていた。

　https://forum.doom9.org/showthread.php?p=1810782#post1810782
　概要
　> ライバルもいるから詳細はあまり説明したくないんだけど、基本的には
　> (UHDkitで)ライブエンコード時の速度アップや、オフラインエンコード時の
　> 計算効率アップのソリューションを提供するための仕組み。
　> x265を単体で使っている人には特にメリットもないし、高品質になるわけでもない。

なお上のコメントはreuse系オプションのことなので、refine系についてはまた別。
refine系の効果までは検証していないので、オプションの説明以上のことは不明。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0b11-NEns) · 2017/09/07(木) 19:56:07.66

qpmin=0はコマンドもない気がするけど何か入れないとでてこないタイプですか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8344-152M) · 2017/09/07(木) 20:37:21.32

>>804
x265.exe --help
> Use --log-level full --help for a full listing

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0b11-NEns) · 2017/09/07(木) 20:59:50.49

>>804
ありがとうございます

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0b11-NEns) · 2017/09/08(金) 18:14:05.76

>>806
× >804
○ >805