x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
自分でビルドすりゃええんでないかい。つかやらないの? ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて
自前でビルドしたほうがはええだろww
「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ? 有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん
そうしてから新しいバージョンを使っても遅くはない
そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ
そんな噛みつかれることなのか?
どしてほしいの、無能だからビルド出来ないとか言って欲しいの? ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは
専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、
配布バイナリで済ませてる人の方が多いんじゃね。
>>93
俺としては>>89の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。 自分でしようと思いつつ本番エンコードの切れ目に出会えずテストできないんだけど
だれかコンパイラの違いによる速度比較してくれない?
https://mevius.5ch.net/test/read.cgi/avi/1486535501/528 主要部分asmで書いてるからコンパイラ変えてもたいして変わらんだろ 結果は誤差でした
aviutl経由(でのafsでテレシネ解除)でのエンコードだから
x265自体の性能テストとしては使えないけど
_x265-vs2017
yuv [info]: 1440x1080 fps 30000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 2.7+14-d7c26df32fae
x265 [info]: build info [Windows][MSVC 1913][64 bit] 8bit+10bit
encoded 8993 frames in 320.66s (28.05 fps), 640.58 kb/s, Avg QP:32.63
auo [info]: x265エンコード時間 : 0時間 5分20.8秒
-
_x265-vs2015
yuv [info]: 1440x1080 fps 30000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 2.7+14-d7c26df32fae
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit
encoded 8993 frames in 321.85s (27.94 fps), 640.58 kb/s, Avg QP:32.63
auo [info]: x265エンコード時間 : 0時間 5分21.9秒 >>102
また何も情報(入手元や設定や環境や条件)を書かずに速度が変わったとか言ってんのか・・・。 rigaya氏のブログの「x265ビルド VC2017版」の記事に、
x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる
というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。 >>104
追加で少し試したので取り急ぎ100%再現パターンを。
●ソース: sample.avs (ffmpegでy4m化してx265へ)
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)
●x265コマンド(今のところ2passでしか再現できてない)
--pass1 --bitrate 1000
--pass2 --bitrate 1000
●muxerコマンド
muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4
●結果
muxer.exeが固まる。たまにクラッシュすることもある。 >>106
試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、
>>105でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。
2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、
それともL-SMASH側のバグなのか。
自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。 ちなみに2.7+17でも、
ffmpeg-3.4.2.exe -r 30000/1001 -i sample.265 -c:v copy sample.mp4
MP4Box-0.7.2-rev442-g508d7817.exe -add sample.265 -new sample.mp4
ではmuxも再生も特に問題なさそう。コケるのはL-SMASH muxerのみ。 最近h265のこと知ったけど本当にすごいな
容量1/3でひと目じゃ違いがわからないほどの画質だわ
もっと早くに出会っていたかった 本当すごい
h.264でいいじゃんとか思ってたが画質の良さ段違い >>107
折角俺も L-SMASH 常用なんで x265 と L-SMASH 共にさっき pull してビルドしたやつで
エンコから Mux してみたけど異常無しですわ。
x265 2.7+18 (1fb5ee43be2f) x64
muxer rev1466 (50ee6cb)
muxer.exe -i hogehoge.26x?fps=24000/1001 -o hoge.mp4
MP4 muxing mode
[HEVC: Info]: IDR: 1, CRA: 57, BLA: 0, I: 17, P: 1321, B: 3494, Unknown: 0
Track 1: H.265 High Efficiency Video Coding
Muxing completed!
なんて書いておいてあれだが 2pass はしないで crf 使うタイプなんでそのせいかな。 >>111
問題の発生原因がはっきりしてないので、まだなんとも言えないんだよねえ。
例えば>>105で書いた100%再現の2パスエンコでも、sample.avsの末尾に
Spline36Resize(640,360)
をつけて360pにした場合は問題は再現しない。
720pのままでも、x265で --preset slow または --preset fast をつけると問題は起きない。
適当に試した限りでは--crfでは再現してないのだけど、
原因がはっきりするまでは、「crfなら安全」とは言い切れない。
いつコケるかわからないし、知らない間に「一応再生できるけど規格的に異常なファイル」が作られてしまう可能性もある。
とりあえずL-SMASHの方にもIssue出しておいた。
muxer freeze(or crash) when using x265 2.7+17 - Issue #82 - l-smash/l-smash
https://github.com/l-smash/l-smash/issues/82 >>107
多分そこだと思う
ヘッダに16バイト分ゴミが混ざってて、そこを消すと正常になる 確認できたこと
・x265にバグがあって、不正なヘッダが出力される
・L-SMASHで問題が起こらないファイルも怪しい
参考
https://imgur.com/a/haoJR >>113-114
おお、ありがとう。x265側の問題か〜。オプションとかを格納してるSEIuserDataUnregisteredで
バッファ領域を超えて書き込んでるっぽいのかな?
できればそちらでDoom9かx265のIssueに出してきてもらえるとありがたいのだけど、どうだろう?
そちらで無理なようなら、その画像を以下のような出川ばりの英語で
Doom9に貼ってきてもいいんだけど、どうしよう。
---
x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered)
Not only 2pass encoding.
Left side: 2pass encoding
Right side: 1pass encoding
【画像】 >>115
私は不慣れなので、すみませんが連絡をお願いします doom9覗いたらすでに報告されてたから
じきに直るのでは 物事が一気に動き出した感が凄いね
解析人&報告人おつかれ 報告人乙
AVX512よりOpenCLアクセラレーションをだな・・ +22になってたが、
使ってるパラメータは昔から全然変えてないな
少しは見直したほうがいいのか・・・ AVX512のコードをレビュー中みたいだけど
AVX/AVX2のコードも含まれてるのかな MulticoreWare achieves 18% performance boost on the x265 video codec with Intel AVX-512 Instructions for high quality encoding of 4K HDR content
https://multicorewareinc.com/news/multicoreware-achieves-18-performance-boost-x265-video-codec-intel-avx-512-instructions-high-quality-encoding-4k-hdr-content/
AVX-512を使って4K HDRコンテンツのエンコードで最大18%のスピードアップに成功したよという発表。 MulticoreWare Forms OpenX Media Advisory Board (OpenX -MAB) with Industry Experts to Guide Open-source Media Codec Development
https://multicorewareinc.com/news/multicoreware-forms-openx-media-advisory-board-openx-mab-industry-experts-guide-open-source-media-codec-development/
訳:
MulticoreWareがOpenX Media Advisory Board(OpenX -MAB)を設立。
業界の専門家と協力して、オープンソースのメディアコーデック開発を支援。
オープンソースHEVCエンコーダx265の作成者であるMulticoreWareが、
OpenX-Media Advisory Board(OpenX-MAB)の設立を発表しました。
OpenX-MABの焦点は、x265のような現在および将来のオープンソースのビデオエンコーダの
開発ロードマップを主導し、メディア業界における関連性や普及を確実にすることです。
OpenX-MABは当面はHEVCエンコーディングのためのx265のリーダーシップを継続することに
重点を置くが、将来は他のオープンソースコーデックを含むように拡張するかもしれない。
MulticoreWareはOpenX-MAB拡大のため業界のエキスパートに声をかけている。 >>124
18%か
そろそろ最新世代のCPUを検討するか
(AMDは対応してないんだよね?) >>127
マジで?
では対応しているCPUって? >>124
ダイを倍の大きさにして18%は割に合わねぇ・・
SDR/2kだとどうなるんだろか ryzen3000とicelakeの対決が楽しみやね AVX512向けパッチが入ったみたい
なかなか圧巻だけどAVX512だけでつまらない AVX512の大量コミットで一気に x265 2.7+336 になったのか・・・w というか、もう3.0のリリース準備に入ってるのね。
VMAFスコアの計算機能も入った模様。
cmake時に ENABLE_LIBVMAF をつけて、libvmafをリンクする必要あり。
Add VMAF suppport to report per frame and aggregate VMAF score
https://bitbucket.org/multicoreware/x265/commits/8bc1289c7a4b176d77b48e74716aea30e42766e7
参考:
新しい映像の品質評価 libvmaf
http://nico-lab.net/libvmaf_with_ffmpeg/ >>134
それを追加すると、どんなメリットが発生するの? >>135
SSIMやPSNRより参考になる可能性がある ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・?
ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら
--recon(でかいYUVファイルも出力する)をつけないとエンコードできなくなるような・・・?
VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。
おとなしくffmpegで計測したほうがよさそうだ。 rigaya氏の2.7+336のバイナリ、gccでビルドしたものと書かれてるけど、
--versionで見ると
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
とかじゃなく
x265 [info]: build info [Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
になってるのは、MSVCからgccを使ったということなんだろか?
(ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。) rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。
> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。 ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。 aviutlのguiEX経由だけど問題なくエンコードできてるよ うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。 x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から
pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。
その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方の おま環 ということですね。 試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました! >>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。
stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。 +340-stable ビルドした
AVX512は装備してないけど、だいぶ速くなってる感触
まぁ、動画ソースの問題もあるかもしれなくて全然厳密じゃないが Ryzenだと128bit実行のせいか0.5fps程度の違いだった(早くはなってる 「速くなった」って、いつのバイナリと比較してるんだ・・・?
最近ではAVX512以外に高速化要素なんて無いと思うんだけど。 論理コアが多いほど速度向上を体感しやすいのかも
全く根拠はないが 「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。
必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。 >>150
その表現じゃ伝わらん
1.0fpsと1.5fpsなのか100.0fpsと100.5fpsで全然話が違うぞ 別に伝わらなくていいと思ってる(ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ)
カキコした私が誤差程度と判断したから情報としてまとめなかったけども 来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ 先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ とネットでみたのですが
その理由がわかりませんでした
これはどういう意味があるんでしょうか?
また実際につけた方がよいものなのでしょうか? AVX2 を使うと逆にエンコード速度が落ちるからだよ〜
AVX までに制限してやることで数 fps ほど速度あがる。
実際に --asm avx の有無でエンコ比較してみると良いかも。 >>160
ありがとうございます そういう意味があったんですね
これで心置きなく試してこれそうです AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う
x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな >>162
x264はAVX2切った方が速いけどx265はAVX2の効果高い事多いので
on/off両方試して、自分の環境に合ってる方法とるべし h.264とh.265でtune別 crf別にssim値をプロットしたようなグラフを昔に見た記憶がありそれを探してるのですが
わかる人いたら教えてください 過去ログにいくつかあるね
ただ作られたのがかなり前だしプリセットの内容も変わってるから今だと参考にならない
x265 rev2 [転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1418252184/301
301 名前:名無しさん@編集中[sage] 投稿日:2015/03/31(火) 12:12:14.04 ID:9g7lReBC
Fasterは無いけど各プリセットのファイルサイズとSSIMのグラフ
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up1461.jpg
http://i.imgur.com/ZQl3NLq.png
http://i.imgur.com/dTiyhbx.png
x265 rev3©2ch.net
http://mevius.2ch.net/test/read.cgi/avi/1462270195/633
633 名前:名無しさん@編集中 (ワッチョイ 9f3e-YTUC)[sage] 投稿日:2017/04/28(金) 23:26:59.96 ID:eUzMgdEP0
>>632
一応>>631のグラフにx265 veryslowも追加してみたけど、
SSIM/bitrateグラフでのラインとしてはslow,slowerと大して変わりない感じだね。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3406.jpg 2.8 来たな。
VS 2016 Community で普通にビルドして --asm avx 付けてもエラー出なくなってたわ。よかった やっぱり画質が良くなるオプションは重いのね
いつもなら終わってた量のタスクが終わってなかったは
それはそうと新AQモードの実装はまだかな
画質あがって早くなったら嬉しいんだけども 新AQモードというのは>>74のことかな?その後どうなったんだろね。 最近は更新激しくてパラメータよく解らなくなってきてるな
でもAQは影響デカイパラメータだよね
期待 いうほど変わったっけ?
どうしてもx264全盛期と比べて遅く感じてしまう x265のバラメータは不勉強だわ
一回本腰入れて覚えないと --sao-non-deblock
実写は↑+SAOおすすめ
逆にこれ使わないならSAOを使わないほうがいい
(テスト期間2日だけど ryzen環境だけどAVX2のほうが早かった
ブラウザ閉じたり厳密なテスト環境ではないけど
x265 [info]: HEVC encoder version 2.8+40-0106f9f2f867
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 720 frames in 48.33s (14.90 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 48.85s (14.74 fps), 2510.94 kb/s, Avg QP:27.02
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
encoded 720 frames in 45.10s (15.96 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 44.41s (16.21 fps), 2510.94 kb/s, Avg QP:27.02 ほお。
うちも Ryzen 環境だからちょっとビルドして試してみるかー x264はAVX2無しの方が速いけどx265は付けないと駄目だよ >>182
今まではそれが常識的な物だったけど
AVX2 使った方が速かったよってお話しじゃないの?
まぁ今ビルドおわったんでちょっと試してみるわ 俺環での同テスト
あくまで --asm avx 有無のみの差異。
x265 2.8+40-0106f9f2f867
--asm avx 有り
encoded 2000 frames in 64.96s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.35s (30.61 fps), 1828.98 kb/s, Avg QP:23.40
--asm avx 無しの AVX2 使用
encoded 2000 frames in 64.95s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 64.63s (30.94 fps), 1828.98 kb/s, Avg QP:23.40
(参考)
2.8+23-656b5b442f0b で AVX2 使用。
encoded 2000 frames in 65.81s (30.39 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.85s (30.37 fps), 1828.98 kb/s, Avg QP:23.40
ということで現状はまだなんともだけど >>180 氏の言うとおり Ryzen 環境でも
AVX2 を使った方が微妙に速くなるかもしれん。 追試というか x265 に吐かせた csv なログがあるので昨日エンコしてたソースを再度 2.8+40 でエンコしたログの比較。
アニメソース 34523 フレーム
2.8+40-0106f9f2f867, AVX2 使用 = エンコ時間 840.63s, 平均 41.07fps
2.8+23-656b5b442f0b, AVX2 未使用 = エンコ時間 875.67s, 平均 39.42fps
コミットみると AVX2 周り色々良くワカランが弄られてるからなんか良くなったんかね。
家はこれで --asm avx を削れそうですわ Ryzenつってもいくつかあるんだからモデルくらい明記したほうがいいだろうし、
解像度もちゃんと書いたほうがいいと思う・・・。 AVX2を使うか否かでエンコード速度がーーって話にCPU型番と解像度って必要な話なのかなww まぁ、たしかに解像度などで処理の負荷や傾向も変わるからね
ryzen 1700X
実写1440x1080 (Aviutlのafsでテレシネ解除しguiEX出力)
オプションは設定のリセットを忘れて常用ので走らせたので、ログに記載されてるオプションをペタリ
--input-depth 16 --output-depth 10 --input-csp i420 --crf 25 --qcomp 0.72 --rc-lookahead 25 --vbv-bufsize 7000 --vbv-maxrate
7000 --aq-strength 1.2 --psy-rd 1 --deblock -2:0 --no-sao --subme 3 --merange 55 --rect --limit-modes --ref 4 --max-merge 3
--weightb --rd 2 --colormatrix bt709 --colorprim bt709 --transfer bt709 --sar 4:3 --no-opt-qp-pps
--no-opt-ref-list-length-pps --no-strong-intra-smoothing --input-res 1440x1080 --fps 30000/1001 -o >>187
なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。
言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。 ■ このスレッドは過去ログ倉庫に格納されています