19/04/07 23:46:46.27 CVTI9voW0.net
--crf19 --preset medium --aq-mode 3 --aq-strength 0.6 で今までエンコしてたんだけど
--crf19 --preset medium --tune animation って置き換えたら画質落ちたわ。
線がボケてブロックノイズとバンディングが目立っちゃってた。
ファイルサイズは 300MB ちょいのが 250MB ちょいまで落ちてたから色々情報削ってそうｗ
51:名無しさん＠編集中
19/04/08 01:00:23.02 M0ztyptJ0.net
ファイルサイズ同じになるようにcrf調整しないと意味ないぞ
52:名無しさん＠編集中
19/04/08 01:04:31.04 ePuriIh90.net
>>50
勘違いする人がいそうだから一応言っておくけど、それだけでは--tune animationの効果がよくないってことにはならないぞ。
--crfってのは絶対的な画質指標じゃないんだから、オプションが変われば得られる画質も変わる。
--tune animationの効果を調べるなら、出力ファイルサイズが同じくらいになるように--crfの値を調整して比較しないと。
53:名無しさん＠編集中
19/04/08 10:48:27.89 RJpWkz+40.net
>>51,52
ファイルサイズが近くなるように調整するなら crf の値は小さくなっていくので、
そうなるとエンコ速度が低下しちゃうのよね。
ドキュメントにはエンコード速度に影響を与えずエンコード品質を最適化するとあるけど
最終的な画質まで加味して crf を調整するとトータルで速度が低下しちゃうからなんだかなと。
54:名無しさん＠編集中
19/04/26 10:54:59.36 iSECzt2j6.net
x264のスレって無いんでしたっけ？
55:名無しさん＠編集中
19/04/26 16:42:52.40 u6Ld9Wz60.net
落ちてるね、最後はここかな
x264 rev43©2ch.net
ｽﾚﾘﾝｸ(avi板)
56:54
19/04/26 22:15:53.49 0m8tEGFK0.net
>>55
んー、英語でmailing-listに書き込むしかないのか…
敷居が高い…
57:54
19/04/30 14:26:02.10 9LL/DGwj0.net
25p入力を60i化するのに、
--pulldown 23232 みたいな事やりたいのだけど、
ハードテレシネ済の動画を入力する以外の方法だと、プログラム自体を書き換えないと
無理ですよね…。
58:名無しさん＠編集中
19/05/02 04:43:21.28 ELIrvtOF0.net
CPUコアが余ってるなら
スレッドプールのソースをちょこっと書き換えるだけで
少しだけど速度上がるね
うまくいくと10fpsぐらい上がった
59:名無しさん＠編集中
19/05/04 17:43:51.73 Fhv+W5+dM.net
AMDのZen2が出たら、x265でエンコードする速度はIntelを上回るのだろうか？
60:名無しさん＠編集中
19/05/04 18:12:27.94 dJmdvL1R0.net
無理じゃね、AVX512は結構でかい
61:名無しさん＠編集中
19/05/04 18:38:09.64 Ot+yMcUe0.net
過去の例をみるにCoreと同程度になるはず
AVX512対応なハイエンドには今以上の多コアをぶつけて
SIMD命令による差はなくなる感じだと思う
62:名無しさん＠編集中
19/05/05 01:05:32.76 IgzCcnEA0.net
x265って単純に多コアにすれば比例してエンコ速度伸びるのかな？
63:名無しさん＠編集中
19/05/05 03:24:38.16 jooVwcw70.net
>>62
12コアくらいで頭打ちになるらしい
64:名無しさん＠編集中
19/05/05 04:29:41.98 AIvLPrI70.net
便乗して質問させていただきたいのですが、
threadの役割というのは主に、
分割された個々のフレームで関数を実行する、というような認識で合っていますか？
実際はもっと複雑なものだと思うのですが、詳しい方がいましたら教えて頂きたいです。
65:名無しさん＠編集中
19/05/07 05:51:40.54 OrkrjN730.net
>>60-61
AVX512って汎用性そんなに無いよな
66:名無しさん＠編集中
19/05/07 09:08:47.52 ZkXFQTsZd.net
この分野の処理速度向上に役立つ機能なら汎用性なんてどうでもいい話だし
67:名無しさん＠編集中
19/05/07 09:15:14.06 OEYXYdUu0.net
マイニング用と同じでエンコード用で組むのが一番だしね
68:名無しさん＠編集中
19/05/08 00:33:27.83 hqLwUoiL0.net
ナーシャ・ジベリが機種依存のソースコード書いてFFの飛空艇を8倍速移動させたように、
高速化できれば汎用性なんて関係ない例なんて幾らでもあるよね？
69:名無しさん＠編集中
19/05/08 02:11:22.15 oXs9xS8q0.net
ナージャは参考にならんぐらい天才プログラマなので例えにするのはアレだけどなｗ
確かビザの関連で帰国した際に開発中のFFにバグが起きて
全部頭にプログラム入ってたナージャは問題箇所を電話で指示して修正したんだっけか
ネットかも無い時代だしな
70:名無しさん＠編集中
19/05/14 23:29:34.45 7At3OZ0w0.net
>>62
解像度が高いほどマルチスレッド化(タイル分割)しやすいから条件によるだろうね
低解像度だと6～8コアぐらいでもCPU性能引き出せないこともある
320x180だとこんな感じかな、フルHDでもスリッパみたいなコア数の多いCPUだと使い切れないことがあるみたいだけど。
並列x2 URLﾘﾝｸ(imgur.com)
並列x5 URLﾘﾝｸ(imgur.com)
並列x10 URLﾘﾝｸ(imgur.com)
71:名無しさん＠編集中
19/06/02 18:13:26.90 7FMlgYPC0.net
Ver3.0RC+44ってめっちゃ速くなってない？
何が変わったんだろう
72:名無しさん＠編集中
19/06/02 18:40:14.69 DDlZnQ080.net
速くってエンコ速度が？
今までデフォで無効だった機能が有効になってるぶん、むしろエンコ速度はちょっとだけ遅くなってるけど
73:名無しさん＠編集中
19/06/02 20:31:51.41 mIdsUNKZ0.net
AUじゃなくてRCの方？
最新版てAUだと思ったんだが
ところでAUって何の略なんだろう？
74:名無しさん＠編集中
19/06/02 20:38:50.33 CPr8GJoa0.net
パラメーターの名前的に速度を上げる方向かと思ってた
75:名無しさん＠編集中
19/06/02 20:43:18.46 +GwKPdan0.net
>>73
x265 HEVC Encoder - Page 336 - Doom9's Forum
URLﾘﾝｸ(forum.doom9.org)
> 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 ってことらしい。
76:名無しさん＠編集中
19/06/02 22:54:08.64 mIdsUNKZ0.net
>>75
ありがとう！ググっても出てこないわけだ
77:名無しさん＠編集中
19/06/02 23:30:06.94 pjHQKyrG0.net
うちは 3.0_RC+44-a46ded2c1411 ビルドしてエンコすると例外吐いて落ちちゃうわ。
3.0_Au+30 に戻したｗ
78:名無しさん＠編集中
19/06/02 23:39:58.78 CPr8GJoa0.net
RCってAUになる前のバージョンなんじゃないの?
79:名無しさん＠編集中
19/06/03 00:16:22.26 1ZS+saWA0.net
2時間くらい前にソース取得してビルドしたバージョンだと3.0_RC+44だったけど
80:名無しさん＠編集中
19/06/03 07:43:15.21 cLP4ra+va.net
>>77
このビルドでバッチ組んでしもうた…
全滅か
81:名無しさん＠編集中
19/06/03 09:14:16.57 hSHgv0jad.net
x265は高画質なのはいいんだけど遅すぎだな
最低でも今の3倍は速くしてもらわないと
82:名無しさん＠編集中
19/06/03 09:38:40.50 4Mmrvfys0.net
x265\build\vc15-x86_64\multilib.bat を VSC2019 でビルド出来る様に手探りで弄っておいた
URLﾘﾝｸ(pastebin.com)
ビルド完了して x265.exe が生成されるまで確認出来た
83:名無しさん＠編集中
19/06/03 16:53:33.16 e18q2nlD0.net
>>80
あ、ごめん
rigaya 氏のビルドバッチ使ってビルドしたやつでエンコすると確実に例外吐いておちてたけど
>>82 に貼った x265 同梱の multilib.bat だと大丈夫だった
3.0_Au+30 でエンコした avs 残ってたからそのまま RC+44 でエンコしたら
ログを見る限り 1.4fps ほど速くなってた。
84:名無しさん＠編集中
19/06/03 17:07:46.16 fO8zG3N/0.net
元々が何fpsでエンコ出来てたのかも書かないと
100.0→101.4と1.0→2.4じゃ全然違う
85:名無しさん＠編集中
19/06/03 17:19:49.65 e18q2nlD0.net
>>84
それもそうだｗ 失礼した
34,524 フレーム 24:00 ソースをエンコした速度
3.0_Au+30 = 21.53fps, 1736.76kbps
3.0_RC+44 = 22.91fps, 1687.1kbps
共にフィルタに変更無し、マシンも手を触れずに放って置いた時のもの。
ビットレート落ちてるけど静止画として同一フレーム見ても
画質的な違いが良くワカランので問題は無かったけど気にする人は一応確認しておくと良いかも。
静止画だけで画質を判断する物じゃないけどねｗ
86:名無しさん＠編集中
19/06/03 18:00:51.84 STrk0Y4D0.net
>>83
rigaya氏のスクリプトはいじって使ってるけど
特にエラー出てない様子・・・
SVT_HEVC_REV、BUILD_CCFLAGS
だけいじってる。後者は早くなるように
87:名無しさん＠編集中
19/06/03 23:37:36.05 ZdrU2xp10.net
いいなぁ各自いじれて・・
一昨日ぐらいにrigayaさんが公開してくれてるやつでビルドしようとしたら
AU 3.0+2だったからrigayaさんの3.0+27のままだ
88:名無しさん＠編集中
19/06/04 02:40:57.92 /h2BbEjv0.net
3.1で特に問題なさそう
89:名無しさん＠編集中
19/06/09 02:40:22.66 2GsU/Ght0.net
3.1良さそうね
90:名無しさん＠編集中
19/06/09 07:11:42.54 hQw8wv8O0.net
3.1 がええのんか
91:名無しさん＠編集中
19/06/25 21:49:18.92 mS8GccR0a.net
Raspberry Pi 4
使えそう？
92:名無しさん＠編集中
19/07/19 15:43:39.86 6oFVzMFe0.net
x265のaq4を使ってみたら凄い縮んだけど実写向けじゃないみたいね
Edgeがどうこうとなってるから期待はしてなかったけど
93:名無しさん＠編集中
19/07/29 23:41:02.87 37OeMVP40NIKU.net
aq4ってhevc-aqと同じもの？
94:名無しさん＠編集中
19/07/30 10:15:32.72 C+YQ+loG0.net
説明文が違うと思うんだけどなんで同じものだと思うの?
95:名無しさん＠編集中
19/07/31 07:17:29.64 tqJYOKcMa.net
違う