x265 rev3
- 1 :名無しさん@編集中:2016/05/03(火) 19:09:55.21 ID:Vh9buT2E.net
- 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/
- 758 :名無しさん@編集中 (ワッチョイ 0117-S4qQ):2017/07/14(金) 12:58:34.64 ID:ZmGhVoRc0.net
- 低いほうに合わせればいい
- 759 :名無しさん@編集中 (ワッチョイ 1611-S4qQ):2017/07/14(金) 14:09:47.56 ID:GeLosK/E0.net
- 気合いの120fps
- 760 :名無しさん@編集中 (ワッチョイWW 634b-I8+U):2017/07/14(金) 14:41:53.92 ID:fEBkwWTr0.net
- >>756
無知で申し訳無いのですがレートコントロールとはどのような物なのでしょうか?
- 761 :名無しさん@編集中 (ワッチョイ ae9b-JuSQ):2017/07/14(金) 17:58:34.09 ID:eZ+cvx1f0.net
- 2行目にかいてあることじゃない
知らんけど
- 762 :名無しさん@編集中 (ワッチョイ 0117-S4qQ):2017/07/14(金) 18:18:33.22 ID:ZmGhVoRc0.net
- >>760
最大ビットレートとかバッファサイズとかが規格から逸脱しないようにすること
- 763 :名無しさん@編集中 (ワッチョイ 4644-z+eH):2017/07/14(金) 23:07:39.62 ID:4WOGuhaz0.net
- 質問者
「今のx264やx265だと2Kや4Kエンコでも新しい多コアCPU(16C/32T等)を
100%使い切れないんだけど、なんとかならない?」
RipBot264作者
「RipBot264を使えば1つ(または複数)のマシンで分散エンコーディングできるから
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でバラバラにエンコして結合する時の注意って何かあるんだろうか?
- 764 :名無しさん@編集中 (ワッチョイ 35db-MRQN):2017/07/14(金) 23:30:07.69 ID:Ljds1+Tg0.net
- zonesで指定すればいいみたいだね
>>762
どっちかというと俺が気にしてるのはバッファアンダーフローとかじゃなくて、
何も考えずにやると60pの部分に24pの60/24=2.5倍のビットレートが割り当てられちゃうこと
CBRにするわけじゃないからきっかり2.5倍ってわけじゃないだろうけど
x265はフレームレートが違うって分からないからちゃんとビットレート計算できないだろうし
- 765 :名無しさん@編集中 (ワッチョイ 35db-MRQN):2017/07/14(金) 23:55:06.73 ID:Ljds1+Tg0.net
- >>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とか
エンコでは基本的なことだよ
- 766 :名無しさん@編集中 (ワッチョイ 35db-MRQN):2017/07/15(土) 01:21:14.10 ID:3m6njqCx0.net
- それにしてもレートコントロールが何かを知らないとは
細かいオプションがどうこう言ってるけど、基本がなってないな
1パスとか2パスとか、何か知らないで使ってたのか
- 767 :名無しさん@編集中 (ワッチョイ 4644-A9YL):2017/07/15(土) 02:00:41.29 ID:0OYp2Ppe0.net
- >>766
>>760は初心者が単純に質問しただけで、細かいオプションとかに言及してた形跡はないような。
- 768 :名無しさん@編集中 (ワッチョイ 35db-MRQN):2017/07/15(土) 02:10:30.42 ID:3m6njqCx0.net
- >>760-762
ここらへんの方たちは初心者だったか。それはすまぬ。勘違いだ
- 769 :名無しさん@編集中 (ワッチョイ 4644-A9YL):2017/07/15(土) 02:34:10.54 ID:0OYp2Ppe0.net
- >>768
俺も言葉の厳密な定義を正しく理解してるか自信はあまりないけど、
>>762が書いてる内容はレート制御の範疇に入るだろうから外していいんじゃないか。
- 770 :名無しさん@編集中 (ワッチョイ 35db-MRQN):2017/07/15(土) 17:58:35.45 ID:3m6njqCx0.net
- >>763
x264やx265のexeを起動してるだけなら、GPLを要求するのは難しいよ
ライブラリバージョン使ってるならGPLにしないとダメだけど
GPL原理主義みたいな人たちは宗教的なとこあるから、GPLを要求したいのは分かるけど
- 771 :名無しさん@編集中 (ワッチョイ f644-A9YL):2017/07/16(日) 16:21:37.18 ID: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で見る限り、
https://bitbucket.org/multicoreware/x265/commits/bce945545c241ce4bb87d56d283ac8226d862ed5
にある --const-vbv は有効にされてる模様。
SSIM/ビットレート図 → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3430.jpg
- 772 :名無しさん@編集中 (ワッチョイ f644-A9YL):2017/07/16(日) 16:22:28.34 ID:HpejTqPk0.net
- 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
- 773 :名無しさん@編集中 (ワッチョイ f644-A9YL):2017/07/16(日) 19:42:00.27 ID:HpejTqPk0.net
- ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797
- 774 :名無しさん@編集中(ワッチョイ 354f-PDtw):2017/07/16(日) 20:14:47.61 ID:lE/bCIkh0.net
- VBV設定してないってオチ?
- 775 :名無しさん@編集中 (ワッチョイ f644-A9YL):2017/07/16(日) 21:36:13.64 ID:HpejTqPk0.net
- >>774
よくわかってないのだけど、単に --tune grain を指定しただけでは駄目なのかな?
- 776 :名無しさん@編集中 (スプッッ Sd7f-RYCd):2017/07/24(月) 11:04:19.38 ID:DAPBP2DDd.net
- >>763
これって分散エンコでググっても全く出てこないのな
x265にも対応してるみたいで最近も更新してる様だけど、分散エンコに関するブログ紹介は2012以降ぱたりと無くなる
日本語化で機能しなくなる?のが原因なんだろうか
- 777 :名無しさん@編集中 :2017/08/01(火) 21:18:57.52 ID:kTrSsjB50.net
- http://pc.watch.impress.co.jp/docs/column/kaigai/1073276.html
>Vegaアーキテクチャでは、パックドの8-bit整数演算もサポートされた。
>しかし、8-bit整数演算は、SAD(Sum of Absolute Difference:差の絶対値和)
>演算のみサポートとなっている。動画などイメージ処理向けであり、
>マシンラーニング向けの実装ではない。
x265のエンコに使えると良いな
- 778 :名無しさん@編集中 :2017/08/03(木) 15:23:27.98 ID:NWKbjdAs0.net
- おすすめのオプションある?
ソースは解像度が720x480のアニメTS
- 779 :名無しさん@編集中 :2017/08/03(木) 20:38:03.33 ID:M9rDlJ6g0.net
- デフォでOK。エンコ設定より前処理の方が何倍も重要
- 780 :名無しさん@編集中 :2017/08/04(金) 23:35:07.10 ID:ZTZ+gYb+0.net
- しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1 aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな>aq-mode3
- 781 :名無しさん@編集中 :2017/08/05(土) 00:39:17.43 ID:9YOKH1fA0.net
- aq-mode 1がオールマイティなのかな
アニメを10bitエンコードするとcrf 20〜22でも暗部の輪郭(エッジ)が汚れやすくて少し気になる
なんとかできないものか
- 782 :名無しさん@編集中 :2017/08/05(土) 01:26:48.87 ID:YCAHTRys0.net
- x264でエンコする
- 783 :名無しさん@編集中 :2017/08/05(土) 01:37:12.34 ID:FHp3bZ4Q0.net
- エッジを保護したいならaq使わなければいい
当然のっぺりした部分がその分劣化するわけだが
- 784 :名無しさん@編集中 :2017/08/05(土) 10:06:55.90 ID:jnUNU58K0.net
- >>781
aq-mode3のaq-strength 0.4ぐらいでやればいいじゃ?
- 785 :名無しさん@編集中 :2017/08/05(土) 16:43:26.59 ID:YCAHTRys0.net
- strength値0.4くらいだとaq3使う利点あまりないからaq on/offどっちでも良いと思うよ
- 786 :名無しさん@編集中 :2017/08/05(土) 21:01:05.73 ID:jnUNU58K0.net
- そうでもなかった気がする
実写には不向きだったけど
- 787 :名無しさん@編集中 :2017/08/12(土) 21:18:45.62 ID:4YeA1asg0.net
- 新しいオプション --refine-intra と --refine-inter が追加されたらしいから試してみたけど
Analyze level 10が必要って言われた
これって2passのみってこと?
- 788 :名無しさん@編集中 :2017/08/16(水) 00:27:26.44 ID: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 :名無しさん@編集中 :2017/08/16(水) 11:03:56.00 ID:duFXfDfk0.net
- >>788
解析ファイルを指定するオプションがあったはず
- 790 :名無しさん@編集中 :2017/08/16(水) 14:35:46.41 ID:y9oCilvW0.net
- >>789
--analysis-reuse-fileのことだと思うけど、指定しなければx265_analysis.datになるし、指定しても駄目だった。
- 791 :名無しさん@編集中 :2017/08/23(水) 11:31:49.09 ID:osg+kKft0.net
- x265 HEVC OpenCL or CUDA Encoder
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder
- 792 :名無しさん@編集中 :2017/08/23(水) 17:22:10.57 ID:eg+3M5BL0.net
- 夏休みの自由研究かな
- 793 :名無しさん@編集中 :2017/08/23(水) 18:03:50.40 ID:iIBnv5OG0.net
- どのくらいパフォーマンス向上するのかな
- 794 :名無しさん@編集中 :2017/08/23(水) 18:58:09.00 ID:eg+3M5BL0.net
- CPUの半分も出ればいいほうだな
- 795 :名無しさん@編集中 :2017/08/23(水) 20:03:47.01 ID:nxBulyrM0.net
- >>791 を適当にビルドだけしてエンコしてみたけど別に速くなるとかなんもなかったな。
各ソースのコメントに openacc と付いてる部分で GPU 使ってるんだとは思うが。
- 796 :名無しさん@編集中 :2017/08/23(水) 20:29:12.72 ID:iIBnv5OG0.net
- オリジナルのx265もopenaccが入って来てる
openacc有効にしてビルドすれば、それなりに高速化するらしい
- 797 :名無しさん@編集中 :2017/08/23(水) 21:49:34.43 ID:eg+3M5BL0.net
- >>796
妄想が激しいなw
- 798 :名無しさん@編集中 :2017/09/01(金) 19:12:31.73 ID:ArSPPgcm0.net
- >>788-790がそのままだったので、あらためてreuse,refine系を試した結果を連投。
■--analysis-reuse-levelのテスト1(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 :名無しさん@編集中 :2017/09/01(金) 19:13:31.68 ID:ArSPPgcm0.net
- ■--analysis-reuse-levelのテスト2(1920x1080@23.976、2157frames)
●オプション
・テスト1と同様。ビットレート指定のみ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 :名無しさん@編集中 :2017/09/01(金) 19:14:31.78 ID: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を指定。いくつかのソースで試した限りでは
以下の4パターンの組み合わせのみ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 :名無しさん@編集中 :2017/09/01(金) 19:15:21.46 ID: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 :名無しさん@編集中 :2017/09/01(金) 19:16:26.42 ID:ArSPPgcm0.net
- ■参考
1920x1080、2157framesでCTUサイズを指定した場合のreuseファイルのサイズ(ログ取り忘れ)
CTU-32-32-64-32→357MB、CTU-16-8-32-16→760MB
■コメント
1.reuse-levelの5がrectとampの情報を保存するようなので両者が有効になるslowerを使用。
2.reuse-levelの2と5はreuseファイルのサイズが極端にでかくなるが、
より多くの情報を保存するはずの10はなぜか比較的サイズが小さかった。(それでもでかいけど)
3.CTUサイズの指定については「2pass目がクラッシュしない組み合わせ」を総当たりで探しただけ。
4.x265guiEx v3.79で reuse、refine系の設定欄が追加されたが、
--scale-factor と --min-cu-size の設定欄が無いので、これらは追加コマンド欄で指定する必要がある。
また --refine-mv の設定欄も無い模様。
- 803 :名無しさん@編集中 :2017/09/01(金) 19:17:41.13 ID:ArSPPgcm0.net
- ■最後に
--analysis-reuse系のオプションの使いどころやメリットがよくわからないと思って
調べていたら、x265開発陣が以下のようなコメントをしていた。
https://forum.doom9.org/showthread.php?p=1810782#post1810782
概要
> ライバルもいるから詳細はあまり説明したくないんだけど、基本的には
> (UHDkitで)ライブエンコード時の速度アップや、オフラインエンコード時の
> 計算効率アップのソリューションを提供するための仕組み。
> x265を単体で使っている人には特にメリットもないし、高品質になるわけでもない。
なお上のコメントはreuse系オプションのことなので、refine系についてはまた別。
refine系の効果までは検証していないので、オプションの説明以上のことは不明。
- 804 :名無しさん@編集中 :2017/09/07(木) 19:56:07.66 ID:HahZrfhH0.net
- qpmin=0はコマンドもない気がするけど何か入れないとでてこないタイプですか?
- 805 :名無しさん@編集中 :2017/09/07(木) 20:37:21.32 ID:lQ8OTYTC0.net
- >>804
x265.exe --help
> Use --log-level full --help for a full listing
- 806 :名無しさん@編集中 :2017/09/07(木) 20:59:50.49 ID:HahZrfhH0.net
- >>804
ありがとうございます
- 807 :名無しさん@編集中 :2017/09/08(金) 18:14:05.76 ID:I9BkB4D70.net
- >>806
× >804
○ >805
488 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★