H.265/HEVC Part9 【7680x4320】

**名無しさん＠編集中** (ﾜｯﾁｮｲ 57b3-okpm) · 2018/09/19(水) 22:22:11.05

圧縮効率がH.264の2倍な次世代ビデオコーデックH.265/HEVCを語ろうぜ

前スレ
【2018】 H.265/HEVC Part8 【7680x4320】
https://mevius.5ch.net/test/read.cgi/avi/1516109573/

23 (ﾆｸｸｴ f3e7-o90R) · 2018/10/29(月) 22:03:02.34

>>24 レスありがとうございます。
これは一筋縄ではいかなさそうな感じなんですね。

>>25 そうですか？たまたまVLCがあったのでやってみただけで
もっとHEVCに向いた再生ソフトがあれば・・・という思いもあったのですが。
ぐぐれば無料のとかいくつか出てきますよ、でもなんかどれもいかがわしそうで。

**名無しさん＠編集中** (ｽｯﾌﾟ Sd5a-i+Ke) · 2018/11/01(木) 10:20:35.96

730ってHEVCデコード対応してたっけ？
iGPUの方でデコードするとか

**名無しさん＠編集中** (ｽｯﾌﾟ Sd5a-i+Ke) · 2018/11/01(木) 10:26:15.65

https://developer.nvidia.com/video-encode-decode-gpu-support-matrix

750か1030以上じゃないとデコーダ無いっぽい

23 (ﾜｯﾁｮｲ 36e7-QXT6) · 2018/11/02(金) 18:13:25.74

>>27-28
なんだかヒントをいただいたみたいで・・・
ありがとうございます
ファンレスだと1030がかろうじてあるようですので
iGPUも含めて検討してみます

**名無しさん＠編集中** (ﾎﾟｷｯｰ 91e0-hiLZ) · 2018/11/11(日) 12:04:27.36

http://r2.upup.be/wV2qsULdHm

**名無しさん＠編集中** (ﾜｯﾁｮｲ d3e7-ki2E) · 2018/11/14(水) 03:23:55.87

8/10/12bitとある中でビット数以外は同じ条件でエンコしたのだけど
生成ファイルサイズが大きい順に10bit>8bit>12bitだったのだよね。
予想では12bit>10bit>8bitか8bit>10bit>12bitだったのだけど
8bitが間で12bitが小さい（10bitが大きい）理由って分かる人いる？

2018/12/13(木) 22:58:56.25

保

2018/12/13(木) 23:09:06.45

毛

2018/12/15(土) 10:08:22.83

田

**名無しさん＠編集中** (ﾜｯﾁｮｲ 76a7-AIgs) · 2019/01/02(水) 14:30:14.37

ほ

2019/01/17(木) 19:19:45.53

いいグラボほしいな♪
https://i.imgur.com/aK3HZes.jpg

**名無しさん＠編集中** (ﾜｯﾁｮｲ 418e-beQY) · 2019/01/24(木) 02:16:40.67

Version 3.0
Release date - 23/01/2019
https://x265.readthedocs.io/en/stable/releasenotes.html

**名無しさん＠編集中** (ﾜｯﾁｮｲ 417d-h/iE) · 2019/01/26(土) 09:47:42.34

ここのところ目立って画質が変わるようなアップデートしてなさげだね

**名無しさん＠編集中** (ﾜｯﾁｮｲ c216-uJAn) · 2019/01/26(土) 10:43:42.72

hevc-aqが追加された

**名無しさん＠編集中** (ﾜｯﾁｮｲ 417d-h/iE) · 2019/01/27(日) 01:34:32.71

なるほど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6ad2-X3b8) · 2019/02/24(日) 17:16:40.50

保守

2019/02/24(日) 18:10:30.08

案の定過疎ってるな

**名無しさん＠編集中** (ﾜｯﾁｮｲ def2-VfNx) · 2019/03/25(月) 06:06:58.45

hevc-aq もたいしたインパクトなさそうだね

2019/03/25(月) 11:35:50.92

スレ分裂前はあんなにイキってたのに、いざ専用スレが出来ると何も書き込まないH.265民ってなんなの

**名無しさん＠編集中** (ﾜｯﾁｮｲ 678a-8ZX8) · 2019/03/27(水) 17:57:32.55

この頃h265使い始めた初心者です
h265で撮ったアクションカムの動画で再生時の音ズレに困っています
CPU100％に近く跳ね上がるので、CPUの問題なのでしょうか
グラボを良いモノに変えてみたけどまったく変化無かったです
グラボに仕事させるようなソフトで改善できるモノなのかな

**名無しさん＠編集中** (ﾜｯﾁｮｲ df2d-9gjM) · 2019/03/30(土) 15:33:47.19

>>44
政治的な話が好きな人多いんじゃないかしら？
向こうのスレも技術的な話より政治的な話ばかりしてるし

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8d61-k8NZ) · 2019/04/07(日) 22:36:47.81

3.0で-tunes animationが追加されたけど
効果はどんなもんなのかね。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8d70-iMOx) · 2019/04/07(日) 22:51:31.40

--tune animation で設定されるパラメータはこれか

--psy-rd 0.4
--aq-strength 0.4
--deblock 1:1
--bframes Increase by 2

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8d70-iMOx) · 2019/04/07(日) 22:58:05.81

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8d70-iMOx) · 2019/04/07(日) 23:46:46.27

--crf19 --preset medium --aq-mode 3 --aq-strength 0.6 で今までエンコしてたんだけど
--crf19 --preset medium --tune animation って置き換えたら画質落ちたわ。
線がボケてブロックノイズとバンディングが目立っちゃってた。
ファイルサイズは 300MB ちょいのが 250MB ちょいまで落ちてたから色々情報削ってそうｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7e2d-iMOx) · 2019/04/08(月) 01:00:23.02

ファイルサイズ同じになるようにcrf調整しないと意味ないぞ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 01e7-k8NZ) · 2019/04/08(月) 01:04:31.04

>>50
勘違いする人がいそうだから一応言っておくけど、それだけでは--tune animationの効果がよくないってことにはならないぞ。
--crfってのは絶対的な画質指標じゃないんだから、オプションが変われば得られる画質も変わる。
--tune animationの効果を調べるなら、出力ファイルサイズが同じくらいになるように--crfの値を調整して比較しないと。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9970-iMOx) · 2019/04/08(月) 10:48:27.89

>>51,52
ファイルサイズが近くなるように調整するなら crf の値は小さくなっていくので、
そうなるとエンコ速度が低下しちゃうのよね。
ドキュメントにはエンコード速度に影響を与えずエンコード品質を最適化するとあるけど
最終的な画質まで加味して crf を調整するとトータルで速度が低下しちゃうからなんだかなと。

**名無しさん＠編集中** (ｶﾞｯｸｼ 0659-KI0z) · 2019/04/26(金) 10:54:59.36

x264のスレって無いんでしたっけ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8502-KxX0) · 2019/04/26(金) 16:42:52.40

落ちてるね、最後はここかな
x264 rev43©2ch.net
https://mevius.5ch.net/test/read.cgi/avi/1485572817/

54 (ﾜｯﾁｮｲ 237f-KI0z) · 2019/04/26(金) 22:15:53.49

>>55
んー、英語でmailing-listに書き込むしかないのか…
敷居が高い…

54 (ﾜｯﾁｮｲ 237f-KI0z) · 2019/04/30(火) 14:26:02.10

25p入力を60i化するのに、
--pulldown 23232 みたいな事やりたいのだけど、
ハードテレシネ済の動画を入力する以外の方法だと、プログラム自体を書き換えないと
無理ですよね…。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 06f2-UklA) · 2019/05/02(木) 04:43:21.28

CPUコアが余ってるなら
スレッドプールのソースをちょこっと書き換えるだけで
少しだけど速度上がるね
うまくいくと10fpsぐらい上がった

2019/05/04(土) 17:43:51.73

AMDのZen2が出たら、x265でエンコードする速度はIntelを上回るのだろうか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 122d-ahOC) · 2019/05/04(土) 18:12:27.94

無理じゃね、AVX512は結構でかい

**名無しさん＠編集中** (ﾜｯﾁｮｲ f716-Cg3z) · 2019/05/04(土) 18:38:09.64

過去の例をみるにCoreと同程度になるはず
AVX512対応なハイエンドには今以上の多コアをぶつけて
SIMD命令による差はなくなる感じだと思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ 122d-ahOC) · 2019/05/05(日) 01:05:32.76

x265って単純に多コアにすれば比例してエンコ速度伸びるのかな？

2019/05/05(日) 03:24:38.16

>>62
12コアくらいで頭打ちになるらしい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6752-ahOC) · 2019/05/05(日) 04:29:41.98

便乗して質問させていただきたいのですが、
threadの役割というのは主に、
分割された個々のフレームで関数を実行する、というような認識で合っていますか？
実際はもっと複雑なものだと思うのですが、詳しい方がいましたら教えて頂きたいです。

2019/05/07(火) 05:51:40.54

>>60-61
AVX512って汎用性そんなに無いよな

**名無しさん＠編集中** (ｽﾌﾟﾌﾟ Sd02-tBaC) · 2019/05/07(火) 09:08:47.52

この分野の処理速度向上に役立つ機能なら汎用性なんてどうでもいい話だし

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4263-R0y6) · 2019/05/07(火) 09:15:14.06

マイニング用と同じでエンコード用で組むのが一番だしね

**名無しさん＠編集中** (ﾜｯﾁｮｲ a201-siGz) · 2019/05/08(水) 00:33:27.83

ナーシャ・ジベリが機種依存のソースコード書いてFFの飛空艇を8倍速移動させたように、
高速化できれば汎用性なんて関係ない例なんて幾らでもあるよね？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4263-R0y6) · 2019/05/08(水) 02:11:22.15

ナージャは参考にならんぐらい天才プログラマなので例えにするのはアレだけどなｗ
確かビザの関連で帰国した際に開発中のFFにバグが起きて
全部頭にプログラム入ってたナージャは問題箇所を電話で指示して修正したんだっけか
ネットかも無い時代だしな

**名無しさん＠編集中** (ﾜｯﾁｮｲ b792-5AMV) · 2019/05/14(火) 23:29:34.45

>>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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2fb5-bIfI) · 2019/06/02(日) 18:13:26.90

Ver3.0RC+44ってめっちゃ速くなってない？
何が変わったんだろう

**名無しさん＠編集中** (ﾜｯﾁｮｲ da2d-2ZOZ) · 2019/06/02(日) 18:40:14.69

速くってエンコ速度が？
今までデフォで無効だった機能が有効になってるぶん、むしろエンコ速度はちょっとだけ遅くなってるけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4a8c-bIfI) · 2019/06/02(日) 20:31:51.41

AUじゃなくてRCの方？
最新版てAUだと思ったんだが
ところでAUって何の略なんだろう？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b16-bIfI) · 2019/06/02(日) 20:38:50.33

パラメーターの名前的に速度を上げる方向かと思ってた

**名無しさん＠編集中** (ﾜｯﾁｮｲ bbe7-bIfI) · 2019/06/02(日) 20:43:18.46

>>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 ってことらしい。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4a8c-bIfI) · 2019/06/02(日) 22:54:08.64

>>75
ありがとう！ググっても出てこないわけだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3f70-hDDM) · 2019/06/02(日) 23:30:06.94

うちは 3.0_RC+44-a46ded2c1411 ビルドしてエンコすると例外吐いて落ちちゃうわ。
3.0_Au+30 に戻したｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b16-bIfI) · 2019/06/02(日) 23:39:58.78

RCってAUになる前のバージョンなんじゃないの?

**名無しさん＠編集中** (ﾜｯﾁｮｲ 731a-bUoT) · 2019/06/03(月) 00:16:22.26

2時間くらい前にソース取得してビルドしたバージョンだと3.0_RC+44だったけど

2019/06/03(月) 07:43:15.21

>>77
このビルドでバッチ組んでしもうた…
全滅か

**名無しさん＠編集中** (ｽﾌﾟﾌﾟ Sd8a-CpxY) · 2019/06/03(月) 09:14:16.57

x265は高画質なのはいいんだけど遅すぎだな
最低でも今の3倍は速くしてもらわないと

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3f70-hDDM) · 2019/06/03(月) 09:38:40.50

x265\build\vc15-x86_64\multilib.bat を VSC2019 でビルド出来る様に手探りで弄っておいた
https://pastebin.com/TvjwSFNf

ビルド完了して x265.exe が生成されるまで確認出来た

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6370-hDDM) · 2019/06/03(月) 16:53:33.16

>>80
あ、ごめん
rigaya 氏のビルドバッチ使ってビルドしたやつでエンコすると確実に例外吐いておちてたけど
>>82 に貼った x265 同梱の multilib.bat だと大丈夫だった

3.0_Au+30 でエンコした avs 残ってたからそのまま RC+44 でエンコしたら
ログを見る限り 1.4fps ほど速くなってた。

2019/06/03(月) 17:07:46.16

元々が何fpsでエンコ出来てたのかも書かないと
100.0→101.4と1.0→2.4じゃ全然違う

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6370-hDDM) · 2019/06/03(月) 17:19:49.65

>>84
それもそうだｗ失礼した

34,524 フレーム 24:00 ソースをエンコした速度
3.0_Au+30 = 21.53fps, 1736.76kbps
3.0_RC+44 = 22.91fps, 1687.1kbps

共にフィルタに変更無し、マシンも手を触れずに放って置いた時のもの。
ビットレート落ちてるけど静止画として同一フレーム見ても
画質的な違いが良くワカランので問題は無かったけど気にする人は一応確認しておくと良いかも。
静止画だけで画質を判断する物じゃないけどねｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ bef2-pVhm) · 2019/06/03(月) 18:00:51.84

>>83
rigaya氏のスクリプトはいじって使ってるけど
特にエラー出てない様子・・・

SVT_HEVC_REV、BUILD_CCFLAGS
だけいじってる。後者は早くなるように

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b16-bIfI) · 2019/06/03(月) 23:37:36.05

いいなぁ各自いじれて・・
一昨日ぐらいにrigayaさんが公開してくれてるやつでビルドしようとしたら
AU 3.0+2だったからrigayaさんの3.0+27のままだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4a8c-bIfI) · 2019/06/04(火) 02:40:57.92

3.1で特に問題なさそう

**名無しさん＠編集中** (ﾜｯﾁｮｲ 472d-to8s) · 2019/06/09(日) 02:40:22.66

3.1良さそうね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8170-FAmt) · 2019/06/09(日) 07:11:42.54

3.1 がええのんか

2019/06/25(火) 21:49:18.92

Raspberry Pi 4
使えそう？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3f16-k+pP) · 2019/07/19(金) 15:43:39.86

x265のaq4を使ってみたら凄い縮んだけど実写向けじゃないみたいね
Edgeがどうこうとなってるから期待はしてなかったけど

**名無しさん＠編集中** (ﾆｸｸｴ 1fb5-/0C9) · 2019/07/29(月) 23:41:02.87

aq4ってhevc-aqと同じもの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0a16-wm0+) · 2019/07/30(火) 10:15:32.72

説明文が違うと思うんだけどなんで同じものだと思うの?

2019/07/31(水) 07:17:29.64

違う