H.265/HEVC Part9 【7680x4320】
■ このスレッドは過去ログ倉庫に格納されています
圧縮効率がH.264の2倍な次世代ビデオコーデックH.265/HEVCを語ろうぜ 前スレ 【2018】 H.265/HEVC Part8 【7680x4320】 https://mevius.5ch.net/test/read.cgi/avi/1516109573/ 8/10/12bitとある中でビット数以外は同じ条件でエンコしたのだけど 生成ファイルサイズが大きい順に10bit>8bit>12bitだったのだよね。 予想では12bit>10bit>8bitか8bit>10bit>12bitだったのだけど 8bitが間で12bitが小さい(10bitが大きい)理由って分かる人いる? ここのところ目立って画質が変わるようなアップデートしてなさげだね スレ分裂前はあんなにイキってたのに、いざ専用スレが出来ると何も書き込まないH.265民ってなんなの この頃h265使い始めた初心者です h265で撮ったアクションカムの動画で再生時の音ズレに困っています CPU100%に近く跳ね上がるので、CPUの問題なのでしょうか グラボを良いモノに変えてみたけどまったく変化無かったです グラボに仕事させるようなソフトで改善できるモノなのかな >>44 政治的な話が好きな人多いんじゃないかしら? 向こうのスレも技術的な話より政治的な話ばかりしてるし 3.0で-tunes animationが追加されたけど 効果はどんなもんなのかね。 --tune animation で設定されるパラメータはこれか --psy-rd 0.4 --aq-strength 0.4 --deblock 1:1 --bframes Increase by 2 x265 の引数で主要なとこだけ書くとこれで --crf 19 --preset medium --output-depth 8 --tune animation --sar 4:3 --colorprim bt709 --transfer bt709 --colormatrix bt709 info で表示されたのがこれ。 Slices : 1 frame threads / pool features : 4 / wpp(17 rows) Coding QT: max CU size, min CU size : 64 / 8 Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra ME / range / subpel / merge : hex / 57 / 2 / 2 Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00 Lookahead / bframes / badapt : 20 / 6 / 2 b-pyramid / weightp / weightb : 1 / 1 / 0 References / ref-limit cu / depth : 3 / on / on AQ: mode / str / qg-size / cu-tree : 2 / 0.4 / 32 / 1 Rate Control / qCompress : CRF-19.0 / 0.60 tools: rd=3 psy-rd=0.40 rskip signhide tmvp strong-intra-smoothing tools: lslices=6 deblock(tC=1:B=1) sao --crf19 --preset medium --aq-mode 3 --aq-strength 0.6 で今までエンコしてたんだけど --crf19 --preset medium --tune animation って置き換えたら画質落ちたわ。 線がボケてブロックノイズとバンディングが目立っちゃってた。 ファイルサイズは 300MB ちょいのが 250MB ちょいまで落ちてたから色々情報削ってそうw ファイルサイズ同じになるようにcrf調整しないと意味ないぞ >>50 勘違いする人がいそうだから一応言っておくけど、それだけでは--tune animationの効果がよくないってことにはならないぞ。 --crfってのは絶対的な画質指標じゃないんだから、オプションが変われば得られる画質も変わる。 --tune animationの効果を調べるなら、出力ファイルサイズが同じくらいになるように--crfの値を調整して比較しないと。 >>51 ,52 ファイルサイズが近くなるように調整するなら crf の値は小さくなっていくので、 そうなるとエンコ速度が低下しちゃうのよね。 ドキュメントにはエンコード速度に影響を与えずエンコード品質を最適化するとあるけど 最終的な画質まで加味して crf を調整するとトータルで速度が低下しちゃうからなんだかなと。 >>55 んー、英語でmailing-listに書き込むしかないのか… 敷居が高い… 25p入力を60i化するのに、 --pulldown 23232 みたいな事やりたいのだけど、 ハードテレシネ済の動画を入力する以外の方法だと、プログラム自体を書き換えないと 無理ですよね…。 CPUコアが余ってるなら スレッドプールのソースをちょこっと書き換えるだけで 少しだけど速度上がるね うまくいくと10fpsぐらい上がった AMDのZen2が出たら、x265でエンコードする速度はIntelを上回るのだろうか? 過去の例をみるにCoreと同程度になるはず AVX512対応なハイエンドには今以上の多コアをぶつけて SIMD命令による差はなくなる感じだと思う x265って単純に多コアにすれば比例してエンコ速度伸びるのかな? 便乗して質問させていただきたいのですが、 threadの役割というのは主に、 分割された個々のフレームで関数を実行する、というような認識で合っていますか? 実際はもっと複雑なものだと思うのですが、詳しい方がいましたら教えて頂きたいです。 >>60-61 AVX512って汎用性そんなに無いよな この分野の処理速度向上に役立つ機能なら汎用性なんてどうでもいい話だし マイニング用と同じでエンコード用で組むのが一番だしね ナーシャ・ジベリが機種依存のソースコード書いてFFの飛空艇を8倍速移動させたように、 高速化できれば汎用性なんて関係ない例なんて幾らでもあるよね? ナージャは参考にならんぐらい天才プログラマなので例えにするのはアレだけどなw 確かビザの関連で帰国した際に開発中のFFにバグが起きて 全部頭にプログラム入ってたナージャは問題箇所を電話で指示して修正したんだっけか ネットかも無い時代だしな >>62 解像度が高いほどマルチスレッド化(タイル分割)しやすいから条件によるだろうね 低解像度だと6〜8コアぐらいでもCPU性能引き出せないこともある 320x180だとこんな感じかな、フルHDでもスリッパみたいなコア数の多いCPUだと使い切れないことがあるみたいだけど。 並列x2 https://imgur.com/L90TLmY.png 並列x5 https://imgur.com/BPfpEdD.png 並列x10 https://imgur.com/69llRRx.png Ver3.0RC+44ってめっちゃ速くなってない? 何が変わったんだろう 速くってエンコ速度が? 今までデフォで無効だった機能が有効になってるぶん、むしろエンコ速度はちょっとだけ遅くなってるけど AUじゃなくてRCの方? 最新版てAUだと思ったんだが ところでAUって何の略なんだろう? パラメーターの名前的に速度を上げる方向かと思ってた >>73 x265 HEVC Encoder - Page 336 - Doom9's Forum https://forum.doom9.org/showthread.php?p=1864949& ;highlight=3.0_Au#post1864949 > We are starting to use 3.0_Au (Gold) to signal that the default branch has moved to gold state. > We are just trying to avoid merging back from stable to default as it is good practice to avoid merges. > Hope this isn't too confusing! よくわからんが金(Gold)の元素記号である Au ってことらしい。 うちは 3.0_RC+44-a46ded2c1411 ビルドしてエンコすると例外吐いて落ちちゃうわ。 3.0_Au+30 に戻したw 2時間くらい前にソース取得してビルドしたバージョンだと3.0_RC+44だったけど >>77 このビルドでバッチ組んでしもうた… 全滅か x265は高画質なのはいいんだけど遅すぎだな 最低でも今の3倍は速くしてもらわないと x265\build\vc15-x86_64\multilib.bat を VSC2019 でビルド出来る様に手探りで弄っておいた https://pastebin.com/TvjwSFNf ビルド完了して x265.exe が生成されるまで確認出来た >>80 あ、ごめん rigaya 氏のビルドバッチ使ってビルドしたやつでエンコすると確実に例外吐いておちてたけど >>82 に貼った x265 同梱の multilib.bat だと大丈夫だった 3.0_Au+30 でエンコした avs 残ってたからそのまま RC+44 でエンコしたら ログを見る限り 1.4fps ほど速くなってた。 元々が何fpsでエンコ出来てたのかも書かないと 100.0→101.4と1.0→2.4じゃ全然違う >>84 それもそうだw 失礼した 34,524 フレーム 24:00 ソースをエンコした速度 3.0_Au+30 = 21.53fps, 1736.76kbps 3.0_RC+44 = 22.91fps, 1687.1kbps 共にフィルタに変更無し、マシンも手を触れずに放って置いた時のもの。 ビットレート落ちてるけど静止画として同一フレーム見ても 画質的な違いが良くワカランので問題は無かったけど気にする人は一応確認しておくと良いかも。 静止画だけで画質を判断する物じゃないけどねw >>83 rigaya氏のスクリプトはいじって使ってるけど 特にエラー出てない様子・・・ SVT_HEVC_REV、BUILD_CCFLAGS だけいじってる。後者は早くなるように いいなぁ各自いじれて・・ 一昨日ぐらいにrigayaさんが公開してくれてるやつでビルドしようとしたら AU 3.0+2だったからrigayaさんの3.0+27のままだ x265のaq4を使ってみたら凄い縮んだけど実写向けじゃないみたいね Edgeがどうこうとなってるから期待はしてなかったけど 説明文が違うと思うんだけどなんで同じものだと思うの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる