x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
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 なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。 言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。 俺も環境かいとく流れかな 偶然俺も Ryzen 7 1700X で定格。 映像ソースはアニメで 1440x1080 から AVS で 960x720 にリサイズして SAR 4:3 としてる。 x265 に喰わせてる引数はこれだけ。>>184 でやったテストはこの引数に --asm avx を付けるかどうかってだけの違い。 --crf 19 --preset medium --input-depth 8 --output-depth 10 --aq-mode 3 --aq-strength 0.6 --sar 1:1 -o OUTPUT.265 INPUT.avs AVS ファイルの中身は Trim してロゴ消しからのインタレ解除、ノイズ除去とスムーサー通してリサイズ、アンシャープマスクにデバンドやってる。 で Avisynth+ r2728-MT にやらせてる。 中でどういう処理させてるかでは多少なり変わってくるかもしれないけど、俺環では速くなったので この事を書いてくれた >>180 氏には感謝。気付かなければずっと AVX2 使わないままだったと思うしw 引数間違えてた --sar 1:1 じゃなくて --sar 4:3 だた。 >>189 ハイスペ側だとなにかしらのボトルネックで頭打ちが発生して大差なくなるとかあり得るものね >>192 だよね。 情報書いてくれた方々ありがとう。 ryzenが出た頃に10bit出力ならAVX2ありの方が僅かに早い、ってrigaya氏がすでに言ってたの 意外と知られてなかったんだな >>194 うちの環境ではそれでも AVX2 有りだと遅くなってたのよ。 早いこともあれば遅いこともあったと思うけど ここしばらくはAVX2使わないほうが早かった There's also at least the value of --max-merge being raised in the slower presets which (at least in my opinion) affect by degrading quality. It will smooth things more --> lower bitrate. これってどういう意味? 元URL http://forum.doom9.org/showthread.php?p=1846405#post1846405 >>197 --max-mergeの値を上げると画像がボケる low-bitrate帯でボケる? それとも割り当てられるbitrateが少なくなるからボケるのどっち? crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど 高ビットレートだとボケないのかな?っていうことを聞きたかったんだけど、そこまでは読み取れない? 上から目線であれだけど、英文の記号の使い方とかよー分らん 一度ボケたらいかにビットを割り振ろうと元には戻らないので、ディテールを残したければ--max-mergeを下げるべきだろう ビットレートに余裕があるときにどんな動きをするか聞きたいんじゃない 問答無用でマージしてビットレート下げに行くのか、余裕があるなら働かないのか >>問答無用でマージしてビットレート下げに行く 英文を素直に解釈すればこっち >>202-204 thx 情報の共有と省略、粗のごまかしに心血を注いでるから 副作用なく高圧縮・高画質化ってのは難しいのね 久しぶりにx265のオプション見直そうと思ったけど 色々変わってるからpresetとcrfだけでいいような気もしてきた 質問です。 エンコードするときに設定するビットレートの目安を求めたいのですが、 ttp://web.archive.org/web/20130207145934/http://service.jp.real.com/help/faq/prod/faq_4226.html とか ttps://www.lizardk.net/2011/05/h264.html に書いてある式と、それで求められる値は当てにして良いものですか? コーデックの話であって、エンコーダによって全然違うとかあるなら微妙なんですが・・・。 さらに、ここで求めた値を50%〜60%くらいにすればx265でのビットレートとして使えますか? 固定ビットレートでエンコードするなら、目安になるのでは? 固定品質でエンコードの場合は、全然、目安にならないけど。 >>209 50〜60%は行き過ぎかな H.265は公称ではH.264の半分のビットレートで同等の画質って言ってるが実際は30%減くらいだと思う x264は動画版lame(mp3高性能エンコーダー)みたく規格上のギリギリで高効率に圧縮してるからなぁ x264はほぼ完成してるけどx265はまだ発展途上だからまだ半分は行けないよな >>209 real playerのころとは比べ物にならないぐらい圧縮率は向上してるから半分ぐらいでちょうどいいと思うけど どのみちビットレート指定方式では仕組み的に高画質は無理(6Mbpsぐらいつぎ込めば話は別だけど ま、基本的にcrfモードを使うのが推奨された使い方 x264なら crf=22~23、x265なら crf=24~26 がビットレートと画質のバランスがいい エンコーダ間の比較っていう意味ではこんな資料が https://wyohknott.github.io/video-formats-comparison/ でも最近のエンコーダだと、要求ビットレートが 総画素数/フレームレートに比例するかどうかは怪しい気がするけど… なるほど、みなさんありがとうございます。 >>210 下のURLの方だと、「VBRの最大ビットレートはこの2倍くらいにします」とあるんですが、 Shift+Enterしてしまったごめんなさい VBRの最大ビットレートはこの2倍くらいにします、とあるんですが、 CBRに比べたVBRやCQPのビットレートの振れ幅というのは2倍や0.5倍の範囲内に収まるものなんでしょうか。 詳しい方いましたら教えてください。 x264, x265のビットレート指定エンコードだと2倍もは変動しなかったはず (crfな品質指定エンコードだと3倍ぐらい変動するけど) 最大ビットレートなんて、再生環境が使える上限値にしとくだけだよ これ以上にすると再生できなくなるから超えないようにエンコードしなさいという値なのだから 2倍とか関係ない 例えば地デジtsなら上限10Mbpsで十分だな てか何故かテレビ放送の実写はcrfの割に縮まないのは何故? nlmeansなんかの縮むようなやつ使ってもcrf25で5Mbpsとかいくし、x264なんて8Mbps行くんだが 特に紀行番組や旅番組 Ryzen7 2700Xで--asm AVXの有無を比較してみた x265_2.8+57,ソースは720x480で24000/1001pの5633frameなy4mを5回エンコした平均値 https://imgur.com/qEJ6sUs HDだとまた傾向違うんやろかねぇ・・・ FHDのy4mをHDDから読み出すってのがボトルネックなので台風行ったらSSD買うか >>227 んな金あるかいな・・・ 一定期間スリッパ1とスリッパ2併売するみたいだから、スリッパ1に価格改定入れば… --asm AVXオプション使うと各コア均等に使うけど 使わないと偶数コアを優先的に使って結果ブーストが 効いているようにタスクマネージャからは見える 金があればスリッパ入れたいけど、2700xでも全コア使い切りってまずないんだよなぁ・・・ >>230 AVX2使ってると実行ユニットをロックする(非SMT状態になる)みたいな感じかな? でも使うと遅くなってた頃もあるから x265で最適化が入ったかAVX2のコードの効率性が上がったかのどちらかかな CPUのコア数が多いとどうしても余ってるコアが出てきちゃうから ちゃんとした比較にならないんだよな 実際にエンコードするときは4〜6コア/exeくらいで並列でやるんだから、 ベンチマーク取るときもアフィニティ設定してコア数制限して測って欲しいわ x265は、GPUによるエンコードの分担処理(※GPU内蔵のハードウェアエンコーダーは使わない)とかはできないんだよね? 1から10まで全部CPUでガリガリやるのではなく、部分的にGPUに任せる仕組みを導入してほしい あえて脳筋動き探索アルゴリズムを採用して、GPGPUでゴリゴリ処理できないかのかね >>235 AMDが研究してたりしたんだけど そのAMDの開発方針が変わったりで仕切り直しだと思う x264やx265ならGPGPU移植出来そうだが、マイニングソフトとちがって報酬ないからなぁ 1080tiならRyzenThreadripperを軽く越えるぐらいのエンコ速度出そうだけど gpgpuは木構造苦手みたいな話はもう解消されたの? x264スレが落ちてるからこっちに書くけど、8/6にx264の更新(r2932?)があった模様。 主な内容としては、 ●i400(monochrome)エンコードのサポート (4:0:0 (monochrome) encoding support) ●--avcintra-flavorの追加 (Add Sony XAVC, a flavour of AVC-Intra) といったところかな。 >>240 別に1から10まで全部GPUにやらせようって話ではない Intel「CPUで全部やる、AVXも512bitに拡張だ、まあ最適化したいならICC買ってね?」 AMD「CPU/GPUでリソース配分したほうが開発コストも演算コストも安くね?」 個人的にはAMDが正しいと思うけど、とはいえAVX2くらいは普通に実装してほしかったかなぁ・・・ >>246 条件分岐だけcpuでやって並列単純処理だけgpuに回すなんて都合よくプログラムできるもんなの? そのintelとamdの対比も意味がよくわからないんだけど IntelやAMDがソフトウェアを実装するわけじゃないから、勝手なことをいくらでも言えるわな AMDはGPUも使えって言うんだったらx265をGPU化してみろってんだよ >>247 同じタスクをCPU1:GPU9みたいな具合に割り振るってだけだろ >>249 cpuとgpuで得意なタスクが違うのに同じタスクを割り振って意味あるのか? 多用されてる離散コサイン変換はGPGPUで結構高速化出来るし 動きベクトル探索も良い研究成果が上がってきてるよね 開発環境整ってくれば期待できそう >>250 意味ないね で、CPUの処理の中からGPUに適した処理をアウトそーソングしやすくしよう!って考えたのがAMD(のブラフィックス内蔵SoC) ところが規模の問題などから性能メリットが少なくその方針は下火になったけど GPUへ自動で処理を投げるコンパイラは今も開発継続中(x265開発してる会社へ譲渡して、のはず) そもそもメモリ共有でないとオーバーヘッドが大き過ぎて思ったほど性能が出ないのよね >>248 AMDがx265を正式にGPU対応化とかライセンスの問題で簡単にできないんじゃね? 個人デベロッパーがGPLでAMDでx265のGPU対応化とかさせるのならどうにでもできると思うけど それと同じことを法人が勝手にやると最悪、つまらない訴訟騒ぎに発展するだろうな。 オープンソースなんだから法人でも個人でもできることは変わらないのでは オープンソースな事と改変配布が可能なのは別なんじゃないか オープンソースとは、何をしてもいいということではない つうか、そんなことをリーナス・ドーバルズ氏に言ったら、死ぬほど殴られるぞ オープンソースなのはH.265の特許持ってる所から訴えられないようにするためじゃないの? mp3のlameがそんな感じじゃなかった? >>258 個人がセーフティーに(訴訟リスクなしで)やれる範囲内のことなら 企業も同じくできるでしょってこと GPLは大雑把に言うと、「バイナリ配布したらソース公開は必須」ってライセンス 企業側から見た問題は(個人でも変わらんが)「ソース公開必須」って部分 元々公開する気なら何の問題もない 企業がコミットしてるオープンソースなんて世の中いっぱいあるし、 むしろ、まとまった機能は企業からコミットされることのほうが多い x265だってメインの開発者はMulticoreWareって企業でしょ HEVCのパテントについては、radeonには既にHEVCのエンコーダが乗ってるんだから、 AMDがradeonで動くHEVCのエンコーダをドライバと一緒に配布しても追加コストはあまりないはず 問題があるとすれば、公開されたGPU対応コードが他の企業によって移植されて geforceでも動くようになってしまう確率が高いこと 実際はそれが問題だろうね 自社の製品が売れるようにならなくちゃ企業は動かない あと、MulticoreWare以外の外部が開発したGPLの改変部分は、MulticoreWareが取り込むことはできないから、 オープンコミュニティでメンテする必要があるだろうね MulticoreWareはx265の「ソースを公開する必要がないライセンス」も売ってるから、 他社が作ったGPLコードを取り込むと、それができなくなってしまう 個人の開発者も含めx265にコードを取り込んで欲しい場合は、 コードのライセンスを完全にMulticoreWareに譲渡する契約書を書かされるはず オープンソースと言ってもいろいろある 俺の理解だと、学術研究目的なら著作権問題を回避できるからオープンソースでしか配布できない オープンソースといえどもそのソースに著作権は発生してその形は様々 x264スレが落ちて放置されてるのは、もうH.264にエンコする需要がなくなってるからかね まあ俺もH.264にはBDMV互換でしかエンコしないけどさ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる