x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
0055名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:19:00.26ID:COlz2Rab0
　
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
---
0056名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:22:02.90ID:COlz2Rab0
えーと・・・？

>>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にどれくらいの影響が出るんだろう？

結構でかい話だよねこれ？
0058名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:44:10.05ID:COlz2Rab0
●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!
0061名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/20(土) 17:49:24.71ID:XIH6s3g30
>>60
2.6以降ってことなら追加・変更は下の４つくらいかなあ。
　・--fullhelp
　・--gop-lookahead
　・--radl
　・--analysis-reuse-mode が消されて --analysis-save と --analysis-load に。
0064名無しさん＠編集中 (ﾜｯﾁｮｲ ffed-qi38)
垢版 |
2018/02/15(木) 19:09:13.07ID:kjnv49rj0
メディアプレイヤーとして大正義のPSがPS4proでも再生に対応してないのがだめだな
GPUが対応してるproだけでもとっととやるべき、ソフト再生でPS3まで対応してくれたら神なんだけどなぁ
0065名無しさん＠編集中 (ﾜｯﾁｮｲ f7e0-T3WU)
垢版 |
2018/02/16(金) 19:42:17.97ID:Ohttwh5c0
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
0070名無しさん＠編集中 (ﾜｯﾁｮｲ ecec-je3A)
垢版 |
2018/02/23(金) 21:05:02.63ID:pufaCppw0
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
省略
0073名無しさん＠編集中 (ﾜｯﾁｮｲ ecec-je3A)
垢版 |
2018/02/24(土) 00:09:46.21ID:IJ/q997/0
●Tom Vaughan
　x265プロジェクトの元リーダー。
　>>55-59にあるように、2018年1月中旬にライバル社のBeamrに移籍した。

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

●Ashok Kumar Mishra
　2.7のタグ付けをした人クマー。
　新たなリリース担当なんだろうか？
　
　
現時点ではDoom9にもx265ブログにもリリースアナウンスは来てないね。
0084名無しさん＠編集中 (ﾜｯﾁｮｲ 5b11-N5B0)
垢版 |
2018/03/08(木) 14:50:23.01ID:WnQT6+5V0
あ、やっぱり？
バッチ実行がやけに停滞してるなとは思ってた
doom9では話題になってないからrigaya氏のビルドミスかな
0086名無しさん＠編集中 (ﾜｯﾁｮｲ cfec-Osi7)
垢版 |
2018/03/08(木) 16:11:42.24ID:wHUMYfkz0
【バイナリの入手元】 rigaya氏
【バージョンとx64/x86】 x265_2.6+49_x64
【コマンドオプション】 --preset slow/medium/veryfast --crf 18

これくらいの情報はちゃんと書いてほしいもんだよな・・・。
少なくとも上の条件では特に遅くなったりはしてないよ。
0087sage (ﾜｯﾁｮｲ 5b11-N5B0)
垢版 |
2018/03/08(木) 17:21:53.79ID:WnQT6+5V0
すんまそん
エンコード中だったから差し替えての実験は後じゃ後、と思って細かい情報を調べずに書いちゃった
さらに数日前に差し替えたから2.7かと・・
0092名無しさん＠編集中 (ﾜｯﾁｮｲ 0b68-eXi2)
垢版 |
2018/03/11(日) 03:28:34.13ID:KKe7Ux5L0
ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて
自前でビルドしたほうがはええだろｗｗ
「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ?
0093名無しさん＠編集中 (ﾜｯﾁｮｲ 6a7f-hn8E)
垢版 |
2018/03/11(日) 03:52:49.72ID:xNuwG3/a0
有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん
そうしてから新しいバージョンを使っても遅くはない
そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ

そんな噛みつかれることなのか？
どしてほしいの、無能だからビルド出来ないとか言って欲しいの？
0094名無しさん＠編集中 (ﾜｯﾁｮｲWW 6af7-WxpO)
垢版 |
2018/03/11(日) 04:00:12.62ID:+k5ziIx80
ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは
専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ
0097名無しさん＠編集中 (ﾜｯﾁｮｲ bbec-Osi7)
垢版 |
2018/03/11(日) 11:44:38.24ID:SslWpV+I0
ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、
配布バイナリで済ませてる人の方が多いんじゃね。

>>93
俺としては>>89の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。
0101名無しさん＠編集中 (ﾜｯﾁｮｲ 2b11-hKdO)
垢版 |
2018/03/16(金) 20:53:41.13ID:bn2kqBbr0
結果は誤差でした
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秒
0104名無しさん＠編集中 (ﾜｯﾁｮｲ 9aec-h0dl)
垢版 |
2018/03/26(月) 01:10:10.16ID:xaZyoL940
rigaya氏のブログの「x265ビルド VC2017版」の記事に、

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

というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。
0105名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
2018/03/26(月) 19:29:12.01ID:KAWe9XE/0
>>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が固まる。たまにクラッシュすることもある。
0107名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
2018/03/27(火) 15:23:43.35ID:lGCQMxzy0
>>106
試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、
>>105でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。

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

自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。
0108名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
2018/03/27(火) 15:28:23.56ID:lGCQMxzy0
ちなみに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のみ。
0111名無しさん＠編集中 (ﾜｯﾁｮｲ 9716-zkh5)
垢版 |
2018/03/27(火) 18:34:20.56ID:hAwfzym80
>>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 使うタイプなんでそのせいかな。
0112名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
2018/03/27(火) 19:35:05.90ID:zm8guuOZ0
>>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
0115名無しさん＠編集中 (ﾜｯﾁｮｲ 63ec-h0dl)
垢版 |
2018/03/28(水) 14:01:27.08ID:bOMavOh+0
>>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
【画像】
0124名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
2018/04/10(火) 12:59:16.94ID:mvAZrsZe0
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%のスピードアップに成功したよという発表。
0125名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
2018/04/10(火) 13:16:00.32ID:mvAZrsZe0
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拡大のため業界のエキスパートに声をかけている。
0134名無しさん＠編集中 (ﾜｯﾁｮｲ 23ec-ycE0)
垢版 |
2018/04/13(金) 02:22:20.69ID:NWyIYo2t0
というか、もう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/
0138名無しさん＠編集中 (ﾜｯﾁｮｲ a3ec-ycE0)
垢版 |
2018/04/13(金) 11:58:14.00ID:+CW60tiR0
ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・？
ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら
--recon（でかいYUVファイルも出力する）をつけないとエンコードできなくなるような・・・？
VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。
おとなしくffmpegで計測したほうがよさそうだ。
0139名無しさん＠編集中 (ﾜｯﾁｮｲ ffec-ycE0)
垢版 |
2018/04/13(金) 18:45:37.92ID:qCymtqNK0
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を使ったということなんだろか？
（ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。）
0140名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/15(日) 02:04:37.98ID:3zo9kCKG0
rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。

> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。
0142名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 15:36:59.22ID:YRWrQNWv0
ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。
0144名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/18(水) 17:18:59.94ID:HTI1sHZw0
うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。
0145名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 17:52:15.27ID:YRWrQNWv0
x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から
pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。
その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方の おま環 ということですね。
0147名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 18:15:27.44ID:YRWrQNWv0
試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!
0148名無しさん＠編集中 (ｽｯﾌﾟ Sd5a-Jb0y)
垢版 |
2018/04/19(木) 12:02:15.65ID:CAIRBG+rd
>>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。

stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況