x265 rev4

2017/11/21(火) 20:18:20.98

前スレ
https://mevius.5ch.net/test/read.cgi/avi/1462270195/

2017/11/21(火) 20:18:37.47

保守

2017/11/21(火) 20:18:54.11

保守速報

2017/11/21(火) 20:19:04.55

保守速報敗訴

2017/11/21(火) 20:19:34.39

保守速報アフィカス

2017/11/21(火) 20:19:50.01

保守速報デマ

2017/11/21(火) 20:20:27.01

保守速報無能

2017/11/21(火) 20:20:42.04

保守速報差別

2017/11/21(火) 20:20:59.53

保守速報朝日新聞

2017/11/21(火) 20:21:15.54

保守速報ニート

2017/11/21(火) 20:21:37.77

保守

2017/11/21(火) 20:22:02.43

保守

2017/11/21(火) 20:22:42.24

保守

2017/11/21(火) 20:22:59.57

保守

2017/11/21(火) 20:23:49.65

保守

2017/11/21(火) 20:24:18.56

保守

2017/11/21(火) 20:24:40.45

保守

2017/11/21(火) 20:25:02.54

保守

2017/11/21(火) 20:25:17.62

保守

2017/11/21(火) 20:25:37.50

保守

2017/11/21(火) 20:26:06.58

保守

**名無しさん＠編集中** (ﾜｯﾁｮｲ 47b3-q5Xz) · 2017/11/24(金) 19:48:33.87

復活してた
[転載k禁止]くらい付けたほうがいいと思うけど

2017/11/24(金) 20:09:16.69

>>22
うるせーよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 47b3-q5Xz) · 2017/11/24(金) 20:21:13.13

**名無しさん＠編集中** (ﾜｯﾁｮｲ 27ec-3a+g) · 2017/11/25(土) 19:05:02.89

H.265/HEVCのコマンドラインエンコーダーであるx265について語るスレです。
AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。

[本家]
http://x265.org
https://bitbucket.org/multicoreware/x265/wiki/Home

[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265

[ドキュメント]
http://x265.readthedocs.org/en/default/index.html

[バイナリ]
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")

[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/?q=x265+ビルド

[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。

[前スレ]
x265 rev3
http://mevius.2ch.net/test/read.cgi/avi/1462270195/

**名無しさん＠編集中** (ﾜｯﾁｮｲ 27ec-3a+g) · 2017/11/25(土) 19:06:25.65

[関連スレ]

・x265 HEVC Encoder (Doom9)
https://forum.doom9.org/showthread.php?t=168814

・H265/HEVC全般の話はこちらへ
【2016】 H.265/HEVC Part7 【7680x4320】
http://mevius.2ch.net/test/read.cgi/avi/1485191956/

・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ
AviUtl総合スレッド86
http://egg.2ch.net/test/read.cgi/software/1500105624/

**名無しさん＠編集中** (ﾜｯﾁｮｲ 27ec-3a+g) · 2017/11/25(土) 19:13:29.21

とりあえず>>25-26にテンプレ貼った。

・バイナリにあった http://x265.ru/en/builds は2.4で止まってるので外した
・AviUtlスレは次スレ移行間近なので新スレ立ったらそっち貼らんとあかん

そろそろ2.6がリリースされるみたいだね。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0711-0CkI) · 2017/11/25(土) 20:20:13.99

乙乙
落ちない程度に話題があるといいんだけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7f06-poFb) · 2017/11/25(土) 23:51:20.34

結局ppsの最適化無効にされてて草

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fe7-ThNz) · 2017/11/26(日) 10:34:14.98

>>24
板の設定でそれを勝手に付け加える時とそうでない時があるので、スレ立て主は付けないのが普通

とりあえず>>1乙

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fec-3a+g) · 2017/11/26(日) 12:48:48.67

>>26
AviUtlスレが新スレに移行

・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ
AviUtl総合スレッド87
http://egg.5ch.net/test/read.cgi/software/1511623060/

**名無しさん＠編集中** (ﾆｸｸｴ 7f06-poFb) · 2017/11/29(水) 14:17:10.24

Version 2.6
Release date - 29th November, 2017.

New features
1. x265 can now refine analysis from a previous HEVC encode (using options --refine-inter, and --refine-intra), or a previous AVC encode (using option --refine-mv-type).
　　The previous encode’s information can be packaged using the x265_analysis_data_t data field available in the x265_picture object.
2. Basic support for segmented (or chunked) encoding added with --vbv-end that can specify the status of CPB at the end of a segment.
　　String this together with --vbv-init to encode a title as chunks while maintaining VBV compliance!
3. --force-flush can be used to trigger a premature flush of the encoder.
　　This option is beneficial when input is known to be bursty, and may be at a rate slower than the encoder.
4. Experimental feature --lowpass-dct that uses truncated DCT for transformation.

**名無しさん＠編集中** (ﾜｯﾁｮｲ 39ec-XOTX) · 2017/11/30(木) 12:38:20.66

New featuresだけじゃないし一応リリースノートも貼っておこう。

http://x265.readthedocs.io/en/default/releasenotes.html#version-2-6

**名無しさん＠編集中** (ﾜｯﾁｮｲ b623-w4Uq) · 2017/11/30(木) 18:02:19.23

dllが認識しねえ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7dec-XOTX) · 2017/12/03(日) 11:18:37.48

AviUtlスレで報告があったんで試してみたんだけど、rigaya氏版の2.6+8はビルドがうまくいっていない模様。
うちだと2.5+3で3.8fps出てた--preset slowが、2.6+8だと0.6fpsしか出ない。
今朝がた2.6+8のバイナリが差し変わったようなんでそちらも試したんだけど、ダメっぽい。

--versionを見ると[noasm]になってるし、Doom9を見るとyasmからnasmに変わったみたいなことが
書いてるから、その影響なのかな？

x265 [info]: HEVC encoder version 2.6+8-fc0570b8d8f9
x265 [info]: build info [Windows][MSVC 1911][64 bit][noasm] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: none!

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7dec-XOTX) · 2017/12/03(日) 16:14:48.92

>>35の件、昼過ぎに対応して下さったようで現在は問題ないようです。感謝。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9a3d-MbHU) · 2017/12/03(日) 16:38:19.21

本家の仕様変更じゃなくてよかった

**名無しさん＠編集中** (ﾜｯﾁｮｲ f1a9-JjO2) · 2017/12/03(日) 20:05:58.24

>>35
x265のスレというのがあったのだな
おつあり

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sd0a-ZXnU) · 2017/12/04(月) 08:16:11.69

>>37
まぁ、本家がビルドツール変えたんだけどな、
yasmから、nasmに。
で、nasmへのパス通し忘れてたって話。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3d9f-GQwd) · 2017/12/05(火) 23:58:55.59

2.6+8エンコおっそいな・・・
veryslow並だと2.5+69の半分以下
変わったオプションといえばgop-lookaheadが
増えたくらいなんだけどな

**名無しさん＠編集中** (ﾜｯﾁｮｲ b7b5-qmOZ) · 2017/12/07(木) 22:56:51.17

環境依存なのか知らんがうちでもくっそ遅い・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 57ec-IpD3) · 2017/12/08(金) 00:02:09.07

>>40-41
>>35-36は読んだ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ bf11-qmOZ) · 2017/12/11(月) 17:19:12.12

doomのスレ読んで、x264はたった3000にも満たないコミット数で
あの性能を実現してるのは凄いと思った

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6f11-buzn) · 2017/12/26(火) 18:53:48.91

ビットレート当たりの画質がかなり上がってるのね
ver2に上がるかどうかのころはcrf22ないと劣化が分かったけど
今はcrf24で目に見える劣化無しでエンコードできるようになってる
あくまで低ビットレート時の話だけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ f3e9-RBuR) · 2017/12/27(水) 13:58:34.76

2018年後半に4K放送対応レコーダーを発売することが決まり、H.265のエンコード・でコードもサポートされるようになるみたいだが、
現段階でx265にて作成できるH.265ファイルはレコーダーやプレーヤーなどとの互換性は取れているのだろうか？
x264が出てもしばらくの間、プレーヤーなどとの互換性、インターレース信号の取り扱い等、結構長く問題を引きずっていたような記憶があるのだが。

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffe7-89OF) · 2017/12/27(水) 19:03:53.09

今の地デジだってモノが出始めてからも互換性の状況は変わったのに、今からそんな事を心配していると禿げると思うよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6f11-buzn) · 2017/12/27(水) 21:12:17.50

x264の頃はメディアプレイヤーの存在自体が小さかったし
ソフトウェアのほうもメディアプレイヤーを前提とした作りしてなかったから問題となったけど
今のx265はオプションにさえ気を付けたらだいじょうぶじゃね

2017/12/28(木) 12:58:51.47

H.265 Main 10準拠で、レベルを5.1までに設定していたら大丈夫だと思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67fa-MiNv) · 2017/12/31(日) 11:43:53.69

誰でも自分ＰＣで稼げる方法など
参考までに、
⇒　『政道のゴウイウセレイイ』というＨＰで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

8RNNMQEE3I

44 (ﾜｯﾁｮｲ c611-Auke) · 2017/12/31(日) 14:00:18.29

ちなみにオプションの--rectと--limited-ref（preset slowで有効になるやつ）は
他オプションを犠牲にしてでも使わないと
あんまりパッとしない感じだった

**名無しさん＠編集中** (ﾜｯﾁｮｲ cbec-O50F) · 2017/12/31(日) 14:32:32.59

>>50
--limited-refなんてオプションは無いし、--limit-refsのことならmediumもslowも値は3で差がない。
slowで有効になるオプションで似た名前のものだとしたら、--limit-modesじゃないの。

**名無しさん＠編集中** (ﾜｯﾁｮｲ c611-Auke) · 2018/01/01(月) 19:52:28.70

>>51
指摘ｔｈｘ
たぶん、それだ
rigayaさんのGuiEX使ってるからオプション名はあやふやで・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5dec-IhuN) · 2018/01/13(土) 01:22:23.81

テンプレ>>26のH.265/HEVCスレPart7から、AV1等も含めた総合スレが派生。

次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
http://mevius.5ch.net/test/read.cgi/avi/1515759816/

H.265/HEVCスレ（他のコーデックの話は禁止になるらしい）の次スレが立つかどうかは不明。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 15ec-wNYY) · 2018/01/18(木) 02:52:53.94

　
2.6+19にバグ。2.6+28(d9fa3c6)で修正。
https://forum.doom9.org/showthread.php?p=1830262#post1830262

**名無しさん＠編集中** (ﾜｯﾁｮｲ 15ec-wNYY) · 2018/01/18(木) 03:19:00.26

　
https://forum.doom9.org/showthread.php?p=1830632#post1830632
---
x265_Project

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start.
But I need to let you know that I've decided to move on, joining Beamr as VP Strategy.
x265 has a strong team, and it's in good hands.
I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom
---

**名無しさん＠編集中** (ﾜｯﾁｮｲ 15ec-wNYY) · 2018/01/18(木) 03:22:02.90

えーと・・・？

>>55は、x265プロジェクトのトップで、当初からMulticoreWareのビデオビジネスのトップだった
Tomさんという人（Tom Vaughanさん？ http://x265.org/author/tom/ ）が、
ライバル社の Beamr ( https://beamr.com ) に転職するってことかな・・・？

去年の9月には
　Beamr compares their HEVC encoder to x265 - x265
　http://x265.org/beamr-hevc-encoder-comparison/
という記事も書いてたんだが・・・。

VPってのがいまいちわからんのだけど、joining Beamr as VP Strategyってどう訳せばいいんだろ？
「戦略担当のVice PresidentとしてBeamrに参加」であってる？

Doom9で使ってたx265_ProjectというアカウントはMulticoreWareチームに移譲するとあるし、
開発体制とかよく知らないんだけど、Tomさんが抜けることでx265にどれくらいの影響が出るんだろう？

結構でかい話だよねこれ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ db7f-x16F) · 2018/01/18(木) 03:22:20.65

俺もそっちのが気になったｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 15ec-wNYY) · 2018/01/18(木) 03:44:10.05

●Tom Vaughan @tmvn

https://twitter.com/tmvn/status/953383728536940544
I'm pleased to announce that I've decided to join Beamr as VP Strategy!
Beamr has an incredible team, and industry-leading video software products.
No company is better positioned to provide efficient, high performance video compression solutions.

●Mark Donnigan @mdonnigan ←Beamrの人

https://twitter.com/mdonnigan/status/953364887131996160
2018 is blasting off in every vector at Beamr.
We will make several industry shaking announcements at #IBC2018 & #NAB2018,
perfectly timed to meet NFV and virtualization Initiatives that are in full swing.
Also, pleased to welcome Tom Vaughan as VP, Video…https://lnkd.in/gHsGS7e

https://twitter.com/mdonnigan/status/953462509217841152
Welcome to the Beamr team Tom Vaughan!

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sd43-iy+0) · 2018/01/18(木) 10:57:17.84

>>56
直訳なら戦略部長だろうね
企業向けエンコーダーの技術戦略部トップとして引き抜かれたのかな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0be8-+0qy) · 2018/01/20(土) 11:09:00.15

今、2.6+31 ?
更新が早くて新規のオプションとか調べてないなぁ・・・
ビルドだけはしてるんだけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 15ec-wNYY) · 2018/01/20(土) 17:49:24.71

>>60
2.6以降ってことなら追加・変更は下の４つくらいかなあ。
　・--fullhelp
　・--gop-lookahead
　・--radl
　・--analysis-reuse-mode が消されて --analysis-save と --analysis-load に。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 97ec-YYog) · 2018/02/06(火) 17:43:05.95

--tune anime が実装予定？

https://forum.doom9.org/showthread.php?p=1832924#post1832924

**名無しさん＠編集中** (ﾜｯﾁｮｲ bf11-wbgk) · 2018/02/06(火) 23:17:58.23

標準プリセットととしてはまあまあ妥当な気がする
オプション見ただけだけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffed-qi38) · 2018/02/15(木) 19:09:13.07

メディアプレイヤーとして大正義のPSがPS4proでも再生に対応してないのがだめだな
GPUが対応してるproだけでもとっととやるべき、ソフト再生でPS3まで対応してくれたら神なんだけどなぁ

**名無しさん＠編集中** (ﾜｯﾁｮｲ f7e0-T3WU) · 2018/02/16(金) 19:42:17.97

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffe8-1VRC) · 2018/02/18(日) 16:47:37.06

久々にビルドしたら+42になってた

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9f11-T3WU) · 2018/02/21(水) 00:03:33.19

お、もうそろそろv2.7に上がるっぽい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 127f-MTlB) · 2018/02/23(金) 10:24:59.55

+49になってるな

**名無しさん＠編集中** (ﾜｯﾁｮｲ ecec-je3A) · 2018/02/23(金) 21:02:27.43

stableブランチはv2.7になってるけど、defaultブランチが7219376で止まってるから
マージミスってねえかって話になってるように見える。
　https://forum.doom9.org/showthread.php?t=168814&;page=296

**名無しさん＠編集中** (ﾜｯﾁｮｲ ecec-je3A) · 2018/02/23(金) 21:05:02.63

http://x265.readthedocs.io/en/stable/releasenotes.html#version-2-7

Version 2.7
Release date - 21st Feb, 2018.

New features
1. --gop-lookahead can be used to extend the gop boundary(set by ?keyint). The GOP will be extended, if a scene-cut frame is found within this many number of frames.
2. Support for RADL pictures added in x265. --radl can be used to decide number of RADL pictures preceding the IDR picture.

Encoder enhancements
1. Moved from YASM to NASM assembler. Supports NASM assembler version 2.13 and greater.
2. Enable analysis save and load in a single run. Introduces two new cli options ?analysis-save <filename> and ?analysis-load <filename>.
3. Comply to HDR10+ LLC specification.
4. Reduced x265 build time by more than 50% by re-factoring ipfilter.asm.

Bug fixes
省略

**名無しさん＠編集中** (ﾜｯﾁｮｲ 127f-MTlB) · 2018/02/23(金) 23:09:09.63

リリースした人もなんかいつもと違うしな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7011-x4Or) · 2018/02/23(金) 23:38:24.10

だれか抜けたし・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ ecec-je3A) · 2018/02/24(土) 00:09:46.21

●Tom Vaughan
　x265プロジェクトの元リーダー。
　>>55-59にあるように、2018年1月中旬にライバル社のBeamrに移籍した。

●Pradeep Ramachandran
　最近のバージョンのタグ付けをしたり、Doom9やx265ブログでリリース記事を書いていた人。
　x265ブログでTom Vaughan氏が書いていた過去記事も、今はこの人の名義に変わっている。
　この人がプロジェクトリーダーを引きついだのだろうか？

●Ashok Kumar Mishra
　2.7のタグ付けをした人クマー。
　新たなリリース担当なんだろうか？
　
　
現時点ではDoom9にもx265ブログにもリリースアナウンスは来てないね。

**名無しさん＠編集中** (ﾜｯﾁｮｲ f6ec-je3A) · 2018/02/27(火) 21:07:15.20

https://forum.doom9.org/showthread.php?p=1834893#post1834893
Ashok Kumar Mishra
> We are working on efficient aq mode which gives better compression efficiency, it may come in next release.
　（圧縮率の上がる効果的なaq modeを作ってるとこだよ。次のリリースに入れるかも。）

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7011-x4Or) · 2018/02/27(火) 22:10:42.33

それは期待！

2018/02/27(火) 22:50:45.91

x265は素晴らしいなあ
今後の成熟がx264以上に楽しみだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 127f-MTlB) · 2018/02/28(水) 01:42:44.77

くまさん大好き

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1684-RzsP) · 2018/02/28(水) 14:26:23.44

でも新しい技術で過去のエンコをやり直したくなるので
いつまで経っても作業が終わらないし元のソースも捨てられない

**名無しさん＠編集中** (ﾜｯﾁｮｲ 27f7-nwhI) · 2018/03/06(火) 21:57:21.07

PCでしか見ないからx265オンリーになってしまった

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7fe8-Vmra) · 2018/03/06(火) 21:58:04.12

スマホでも見れるでしょ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 27f7-nwhI) · 2018/03/06(火) 21:59:58.57

俺はPCでしか見ないの
PCでしか見れない　とは書いてないやろｗ

2018/03/07(水) 00:05:15.75

知るかボケ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6ac6-hn8E) · 2018/03/08(木) 09:41:50.94

数日前のバージョン変更で、またエンコ速度が2/3になってんな
夜に放置しても終わってねぇ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b11-N5B0) · 2018/03/08(木) 14:50:23.01

あ、やっぱり？
バッチ実行がやけに停滞してるなとは思ってた
doom9では話題になってないからrigaya氏のビルドミスかな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6a7f-hn8E) · 2018/03/08(木) 14:58:24.26

riyaga氏のビルドは数日じゃない前(2.6+49)のものだから
自前か違う人のつかってんじゃないの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ cfec-Osi7) · 2018/03/08(木) 16:11:42.24

【バイナリの入手元】 rigaya氏
【バージョンとx64/x86】 x265_2.6+49_x64
【コマンドオプション】 --preset slow/medium/veryfast --crf 18

これくらいの情報はちゃんと書いてほしいもんだよな・・・。
少なくとも上の条件では特に遅くなったりはしてないよ。

**sage** (ﾜｯﾁｮｲ 5b11-N5B0) · 2018/03/08(木) 17:21:53.79

すんまそん
エンコード中だったから差し替えての実験は後じゃ後、と思って細かい情報を調べずに書いちゃった
さらに数日前に差し替えたから2.7かと・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b11-uQtz) · 2018/03/08(木) 23:47:27.45

改めて調べた結果x265じゃなく
フロントエンドでの処理が遅い物になってるせいっぽい
x265は濡れ衣みたい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6a7f-hn8E) · 2018/03/10(土) 17:08:27.99

2.7+12のビルドきてるな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8f16-uQtz) · 2018/03/10(土) 20:05:08.36

自分でビルドすりゃええんでないかい。つかやらないの?

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6a7f-hn8E) · 2018/03/11(日) 00:30:35.91

誰も早くビルドしろなんぞいってないので

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0b68-eXi2) · 2018/03/11(日) 03:28:34.13

ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて
自前でビルドしたほうがはええだろｗｗ
「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ?

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6a7f-hn8E) · 2018/03/11(日) 03:52:49.72

有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん
そうしてから新しいバージョンを使っても遅くはない
そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ

そんな噛みつかれることなのか？
どしてほしいの、無能だからビルド出来ないとか言って欲しいの？

2018/03/11(日) 04:00:12.62

ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは
専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ

2018/03/11(日) 09:36:43.86

PC関連の板はコミュ障が多い

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b11-uQtz) · 2018/03/11(日) 10:01:35.40

多いいうても一人でっせ＞ここで噛みついてるのは

**名無しさん＠編集中** (ﾜｯﾁｮｲ bbec-Osi7) · 2018/03/11(日) 11:44:38.24

ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、
配布バイナリで済ませてる人の方が多いんじゃね。

>>93
俺としては>>89の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6a7f-hn8E) · 2018/03/11(日) 12:20:59.26

みんな優しいな
ありがとう

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b11-uQtz) · 2018/03/14(水) 23:26:50.13

自分でしようと思いつつ本番エンコードの切れ目に出会えずテストできないんだけど
だれかコンパイラの違いによる速度比較してくれない？

https://mevius.5ch.net/test/read.cgi/avi/1486535501/528

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4d9f-FkxM) · 2018/03/15(木) 16:56:46.86

主要部分asmで書いてるからコンパイラ変えてもたいして変わらんだろ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2b11-hKdO) · 2018/03/16(金) 20:53:41.13

結果は誤差でした
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秒

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9bc6-MOYc) · 2018/03/17(土) 04:18:51.99

2.7+14はいいね。元の速度がでるわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7bec-Ue6H) · 2018/03/17(土) 04:50:33.96

>>102
また何も情報（入手元や設定や環境や条件）を書かずに速度が変わったとか言ってんのか・・・。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9aec-h0dl) · 2018/03/26(月) 01:10:10.16

rigaya氏のブログの「x265ビルド VC2017版」の記事に、

　x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる

というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 03ec-h0dl) · 2018/03/26(月) 19:29:12.01

>>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が固まる。たまにクラッシュすることもある。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9716-zkh5) · 2018/03/27(火) 14:22:05.18

L-SMASH 側でなんかコミットあったようだけど無関係?
https://github.com/l-smash/l-smash/commits/master

**名無しさん＠編集中** (ﾜｯﾁｮｲ 37ec-h0dl) · 2018/03/27(火) 15:23:43.35

>>106
試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、
>>105でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。

2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、
それともL-SMASH側のバグなのか。

自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 37ec-h0dl) · 2018/03/27(火) 15:28:23.56

ちなみに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のみ。

2018/03/27(火) 15:36:01.63

最近h265のこと知ったけど本当にすごいな
容量1/3でひと目じゃ違いがわからないほどの画質だわ
もっと早くに出会っていたかった

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sdba-st2U) · 2018/03/27(火) 15:40:51.57

本当すごい
h.264でいいじゃんとか思ってたが画質の良さ段違い

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9716-zkh5) · 2018/03/27(火) 18:34:20.56

>>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 使うタイプなんでそのせいかな。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 03ec-h0dl) · 2018/03/27(火) 19:35:05.90

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

2018/03/27(火) 20:02:39.73

>>107
多分そこだと思う
ヘッダに16バイト分ゴミが混ざってて、そこを消すと正常になる

2018/03/28(水) 02:43:02.76

確認できたこと
・x265にバグがあって、不正なヘッダが出力される
・L-SMASHで問題が起こらないファイルも怪しい

参考
https://imgur.com/a/haoJR

**名無しさん＠編集中** (ﾜｯﾁｮｲ 63ec-h0dl) · 2018/03/28(水) 14:01:27.08

>>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
【画像】

2018/03/28(水) 14:18:38.25

>>115
私は不慣れなので、すみませんが連絡をお願いします

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0311-zkh5) · 2018/03/28(水) 15:17:15.09

doom9覗いたらすでに報告されてたから
じきに直るのでは

**名無しさん＠編集中** (ﾜｯﾁｮｲ 63ec-h0dl) · 2018/03/28(水) 16:20:16.71

>>116
報告しておきました。感謝。
　https://forum.doom9.org/showthread.php?p=1837693#post1837693

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0311-zkh5) · 2018/03/28(水) 21:48:16.17

物事が一気に動き出した感が凄いね
解析人＆報告人おつかれ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 93ec-2GNe) · 2018/03/30(金) 21:44:43.67

　
2.7+15～2.7+19で発生していた>>104-118のSEIバグは、2.7+20で修正されたようです。

　　https://bitbucket.org/multicoreware/x265/commits/3440a56acc7865dcdea725b8ce7755450209a8ee

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8111-kUw7) · 2018/03/31(土) 13:09:26.20

報告人乙
AVX512よりOpenCLアクセラレーションをだな・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2be8-DIJP) · 2018/04/02(月) 21:59:54.29

+22になってたが、
使ってるパラメータは昔から全然変えてないな
少しは見直したほうがいいのか・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4d11-vJpg) · 2018/04/09(月) 21:13:37.30

AVX512のコードをレビュー中みたいだけど
AVX/AVX2のコードも含まれてるのかな

**名無しさん＠編集中** (ﾜｯﾁｮｲ caec-vJpg) · 2018/04/10(火) 12:59:16.94

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%のスピードアップに成功したよという発表。

**名無しさん＠編集中** (ﾜｯﾁｮｲ caec-vJpg) · 2018/04/10(火) 13:16:00.32

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拡大のため業界のエキスパートに声をかけている。

2018/04/10(火) 13:20:34.68

>>124
18%か
そろそろ最新世代のCPUを検討するか
（AMDは対応してないんだよね？）

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4df1-fmdo) · 2018/04/10(火) 13:52:51.85

CoffeelakeはAVX512非対応だよ

2018/04/10(火) 14:32:56.31

>>127
マジで？
では対応しているCPUって？

**名無しさん＠編集中** (ﾜｯﾁｮｲ caec-vJpg) · 2018/04/10(火) 14:41:37.90

>>128
聞く前にググろうぜ。

AVX-512 - Wikipedia
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4d11-vJpg) · 2018/04/10(火) 18:05:05.59

>>124
ダイを倍の大きさにして18%は割に合わねぇ・・
SDR/2kだとどうなるんだろか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1506-PkBH) · 2018/04/10(火) 20:39:06.61

ryzen3000とicelakeの対決が楽しみやね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2311-ycE0) · 2018/04/12(木) 15:38:59.01

AVX512向けパッチが入ったみたい
なかなか圧巻だけどAVX512だけでつまらない

**名無しさん＠編集中** (ﾜｯﾁｮｲ 23ec-ycE0) · 2018/04/13(金) 02:01:43.85

AVX512の大量コミットで一気に x265 2.7+336 になったのか・・・ｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 23ec-ycE0) · 2018/04/13(金) 02:22:20.69

というか、もう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/

2018/04/13(金) 08:19:53.51

>>134
それを追加すると、どんなメリットが発生するの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffd2-sSYP) · 2018/04/13(金) 08:37:04.29

>>135
SSIMやPSNRより参考になる可能性がある

2018/04/13(金) 09:09:50.94

>>136
そういうことか
Thx

**名無しさん＠編集中** (ﾜｯﾁｮｲ a3ec-ycE0) · 2018/04/13(金) 11:58:14.00

ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・？
ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら
--recon（でかいYUVファイルも出力する）をつけないとエンコードできなくなるような・・・？
VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。
おとなしくffmpegで計測したほうがよさそうだ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffec-ycE0) · 2018/04/13(金) 18:45:37.92

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を使ったということなんだろか？
（ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。）

**名無しさん＠編集中** (ﾜｯﾁｮｲ 73ec-ycE0) · 2018/04/15(日) 02:04:37.98

rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。

> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e38a-sFMX) · 2018/04/15(日) 08:24:32.12

340で修正されたね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7f16-ycE0) · 2018/04/18(水) 15:36:59.22

ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2311-ycE0) · 2018/04/18(水) 16:34:27.96

aviutlのguiEX経由だけど問題なくエンコードできてるよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 73ec-ycE0) · 2018/04/18(水) 17:18:59.94

うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7f16-ycE0) · 2018/04/18(水) 17:52:15.27

x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から
pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。
その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方のおま環ということですね。

2018/04/18(水) 18:08:23.54

https://msdn.microsoft.com/ja-jp/library/abx4dbyh.aspx

スタティックリンクしたら、大丈夫なのかな(未検証

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7f16-ycE0) · 2018/04/18(水) 18:15:27.44

試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!

**名無しさん＠編集中** (ｽｯﾌﾟ Sd5a-Jb0y) · 2018/04/19(木) 12:02:15.65

>>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。

stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4ee8-B8Oq) · 2018/04/20(金) 03:43:40.27

+340-stable ビルドした
AVX512は装備してないけど、だいぶ速くなってる感触
まぁ、動画ソースの問題もあるかもしれなくて全然厳密じゃないが

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8311-9jjH) · 2018/04/20(金) 10:30:35.72

Ryzenだと128bit実行のせいか0.5fps程度の違いだった（早くはなってる

**名無しさん＠編集中** (ﾜｯﾁｮｲ 57ec-9jjH) · 2018/04/20(金) 13:58:16.07

「速くなった」って、いつのバイナリと比較してるんだ・・・？
最近ではAVX512以外に高速化要素なんて無いと思うんだけど。

2018/04/20(金) 14:11:15.36

漏れも全然感じない

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4ee8-Mp6C) · 2018/04/20(金) 17:08:18.30

論理コアが多いほど速度向上を体感しやすいのかも
全く根拠はないが

**名無しさん＠編集中** (ﾜｯﾁｮｲ 57ec-9jjH) · 2018/04/20(金) 17:32:44.04

「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。
必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 83f1-KdMq) · 2018/04/20(金) 18:10:17.26

>>150
その表現じゃ伝わらん
1.0fpsと1.5fpsなのか100.0fpsと100.5fpsで全然話が違うぞ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8311-9jjH) · 2018/04/20(金) 18:47:30.17

別に伝わらなくていいと思ってる（ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ）
カキコした私が誤差程度と判断したから情報としてまとめなかったけども

**名無しさん＠編集中** (ﾜｯﾁｮｲ b38a-/vGA) · 2018/04/20(金) 18:50:30.44

Ryzenなら、メモリ回り詰めれば速くなる。

2018/04/20(金) 20:18:13.59

来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ

**名無しさん＠編集中** (ﾜｯﾁｮｲ b67f-GiJP) · 2018/04/23(月) 11:28:44.66

先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ　とネットでみたのですが
その理由がわかりませんでした
これはどういう意味があるんでしょうか？
また実際につけた方がよいものなのでしょうか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4b16-9jjH) · 2018/04/23(月) 12:19:03.19

AVX2 を使うと逆にエンコード速度が落ちるからだよ～
AVX までに制限してやることで数 fps ほど速度あがる。
実際に --asm avx の有無でエンコ比較してみると良いかも。

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sdba-cf8K) · 2018/04/23(月) 12:32:40.97

本当、何の為に実装したんだか

**名無しさん＠編集中** (ﾜｯﾁｮｲ b67f-GiJP) · 2018/04/23(月) 13:04:20.60

>>160
ありがとうございます　そういう意味があったんですね
これで心置きなく試してこれそうです

**名無しさん＠編集中** (ﾜｯﾁｮｲ b7b5-9jjH) · 2018/04/23(月) 15:47:10.80

AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う
x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1ad2-Mp6C) · 2018/04/23(月) 18:56:54.20

>>162
x264はAVX2切った方が速いけどx265はAVX2の効果高い事多いので
on/off両方試して、自分の環境に合ってる方法とるべし

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5b7f-jMXy) · 2018/04/27(金) 18:15:06.70

h.264とh.265でtune別　crf別にssim値をプロットしたようなグラフを昔に見た記憶がありそれを探してるのですが
わかる人いたら教えてください

**名無しさん＠編集中** (ﾜｯﾁｮｲ 93d2-2tE1) · 2018/04/27(金) 20:48:13.46

過去ログにいくつかあるね
ただ作られたのがかなり前だしプリセットの内容も変わってるから今だと参考にならない

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6d16-HRP5) · 2018/05/21(月) 23:30:48.36

2.8 来たな。
VS 2016 Community で普通にビルドして --asm avx 付けてもエラー出なくなってたわ。よかった

**名無しさん＠編集中** (ﾜｯﾁｮｲ 95ec-NEzo) · 2018/05/22(火) 00:30:38.73

Release Notes
Version 2.8 - 21/05/2018
http://x265.readthedocs.io/en/default/releasenotes.html#version-2-8

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7d06-75LW) · 2018/05/22(火) 00:42:27.48

3.0じゃないんだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ d610-/vbK) · 2018/06/02(土) 07:58:01.86

http://satch.tv/members/honeybee909/?mref=787

**名無しさん＠編集中** (ﾜｯﾁｮｲ 65d2-byqv) · 2018/06/02(土) 09:21:02.21

http://satch.tv/?mref=115

**名無しさん＠編集中** (ﾜｯﾁｮｲ 65d2-byqv) · 2018/06/02(土) 09:21:06.60

http://satch.tv/?mref=115

**名無しさん＠編集中** (ﾜｯﾁｮｲ e111-Bw3Y) · 2018/06/19(火) 18:25:04.97

やっぱり画質が良くなるオプションは重いのね
いつもなら終わってた量のタスクが終わってなかったは

それはそうと新AQモードの実装はまだかな
画質あがって早くなったら嬉しいんだけども

**名無しさん＠編集中** (ｱｳｰｲﾓ MMa5-UMTX) · 2018/06/19(火) 19:44:41.68

なんのこっちゃ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 42ec-Bw3Y) · 2018/06/19(火) 20:43:16.16

新AQモードというのは>>74のことかな？その後どうなったんだろね。

2018/06/20(水) 07:29:13.09

最近は更新激しくてパラメータよく解らなくなってきてるな
でもAQは影響デカイパラメータだよね
期待

**名無しさん＠編集中** (ﾜｯﾁｮｲ e111-Bw3Y) · 2018/06/20(水) 23:03:45.23

いうほど変わったっけ？
どうしてもx264全盛期と比べて遅く感じてしまう

2018/06/21(木) 20:45:03.70

x265のバラメータは不勉強だわ
一回本腰入れて覚えないと

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1f11-GwbS) · 2018/06/21(木) 23:07:50.33

--sao-non-deblock

実写は↑+SAOおすすめ
逆にこれ使わないならSAOを使わないほうがいい
（テスト期間2日だけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4711-UVFs) · 2018/07/08(日) 11:05:54.93

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 11:15:03.97

ほお。
うちも Ryzen 環境だからちょっとビルドして試してみるかー

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fd2-sule) · 2018/07/08(日) 11:26:02.65

x264はAVX2無しの方が速いけどx265は付けないと駄目だよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 11:34:12.01

>>182
今まではそれが常識的な物だったけど
AVX2 使った方が速かったよってお話しじゃないの?

まぁ今ビルドおわったんでちょっと試してみるわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 12:01:26.32

俺環での同テスト
あくまで --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 を使った方が微妙に速くなるかもしれん。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 12:28:09.63

追試というか 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 を削れそうですわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67ec-UVFs) · 2018/07/08(日) 13:08:36.86

Ryzenつってもいくつかあるんだからモデルくらい明記したほうがいいだろうし、
解像度もちゃんと書いたほうがいいと思う・・・。

**名無しさん＠編集中** (ﾜｯﾁｮｲ c768-CJRd) · 2018/07/08(日) 13:42:40.94

AVX2を使うか否かでエンコード速度がーーって話にCPU型番と解像度って必要な話なのかなww

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4711-UVFs) · 2018/07/08(日) 14:17:34.19

まぁ、たしかに解像度などで処理の負荷や傾向も変わるからね

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67ec-UVFs) · 2018/07/08(日) 14:21:18.43

>>187
なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。
言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 14:32:40.17

俺も環境かいとく流れかな

偶然俺も 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 使わないままだったと思うしｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e716-UVFs) · 2018/07/08(日) 14:33:57.66

引数間違えてた --sar 1:1 じゃなくて --sar 4:3 だた。

2018/07/08(日) 14:43:02.06

>>189
ハイスペ側だとなにかしらのボトルネックで頭打ちが発生して大差なくなるとかあり得るものね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67ec-UVFs) · 2018/07/08(日) 14:47:32.78

>>192
だよね。

情報書いてくれた方々ありがとう。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67dd-rubz) · 2018/07/08(日) 16:25:53.01

ryzenが出た頃に10bit出力ならAVX2ありの方が僅かに早い、ってrigaya氏がすでに言ってたの
意外と知られてなかったんだな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8716-UVFs) · 2018/07/08(日) 17:16:20.30

>>194
うちの環境ではそれでも AVX2 有りだと遅くなってたのよ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4711-UVFs) · 2018/07/08(日) 18:41:50.71

早いこともあれば遅いこともあったと思うけど
ここしばらくはAVX2使わないほうが早かった

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5d11-LQig) · 2018/07/13(金) 19:06:48.35

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

2018/07/13(金) 19:32:00.19

>>197
--max-mergeの値を上げると画像がボケる

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5d11-LQig) · 2018/07/13(金) 20:09:01.25

low-bitrate帯でボケる？それとも割り当てられるbitrateが少なくなるからボケるのどっち？

crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど

2018/07/14(土) 20:04:30.79

ボケる結果ビットレートが低くなる