x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
復活してた [転載k禁止]くらい付けたほうがいいと思うけど とりあえず>>25-26 にテンプレ貼った。 ・バイナリにあった http://x265.ru/en/builds は2.4で止まってるので外した ・AviUtlスレは次スレ移行間近なので新スレ立ったらそっち貼らんとあかん そろそろ2.6がリリースされるみたいだね。 >>24 板の設定でそれを勝手に付け加える時とそうでない時があるので、スレ立て主は付けないのが普通 とりあえず>>1 乙 >>26 AviUtlスレが新スレに移行 ・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ AviUtl総合スレッド87 http://egg.5ch.net/test/read.cgi/software/1511623060/ 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. 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! >>35 の件、昼過ぎに対応して下さったようで現在は問題ないようです。感謝。 >>35 x265のスレというのがあったのだな おつあり >>37 まぁ、本家がビルドツール変えたんだけどな、 yasmから、nasmに。 で、nasmへのパス通し忘れてたって話。 2.6+8エンコおっそいな・・・ veryslow並だと2.5+69の半分以下 変わったオプションといえばgop-lookaheadが 増えたくらいなんだけどな doomのスレ読んで、x264はたった3000にも満たないコミット数で あの性能を実現してるのは凄いと思った ビットレート当たりの画質がかなり上がってるのね ver2に上がるかどうかのころはcrf22ないと劣化が分かったけど 今はcrf24で目に見える劣化無しでエンコードできるようになってる あくまで低ビットレート時の話だけど 2018年後半に4K放送対応レコーダーを発売することが決まり、H.265のエンコード・でコードもサポートされるようになるみたいだが、 現段階でx265にて作成できるH.265ファイルはレコーダーやプレーヤーなどとの互換性は取れているのだろうか? x264が出てもしばらくの間、プレーヤーなどとの互換性、インターレース信号の取り扱い等、結構長く問題を引きずっていたような記憶があるのだが。 今の地デジだってモノが出始めてからも互換性の状況は変わったのに、今からそんな事を心配していると禿げると思うよ x264の頃はメディアプレイヤーの存在自体が小さかったし ソフトウェアのほうもメディアプレイヤーを前提とした作りしてなかったから問題となったけど 今のx265はオプションにさえ気を付けたらだいじょうぶじゃね H.265 Main 10準拠で、レベルを5.1までに設定していたら大丈夫だと思う 誰でも自分PCで稼げる方法など 参考までに、 ⇒ 『政道のゴウイウセレイイ』 というHPで見ることができます。 グーグルで検索⇒『政道のゴウイウセレイイ』 8RNNMQEE3I ちなみにオプションの--rectと--limited-ref(preset slowで有効になるやつ)は 他オプションを犠牲にしてでも使わないと あんまりパッとしない感じだった >>50 --limited-refなんてオプションは無いし、--limit-refsのことならmediumもslowも値は3で差がない。 slowで有効になるオプションで似た名前のものだとしたら、--limit-modesじゃないの。 >>51 指摘thx たぶん、それだ rigayaさんのGuiEX使ってるからオプション名はあやふやで・・ テンプレ>>26 のH.265/HEVCスレPart7から、AV1等も含めた総合スレが派生。 次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】 http://mevius.5ch.net/test/read.cgi/avi/1515759816/ H.265/HEVCスレ(他のコーデックの話は禁止になるらしい)の次スレが立つかどうかは不明。 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 --- えーと・・・? >>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にどれくらいの影響が出るんだろう? 結構でかい話だよねこれ? ●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! >>56 直訳なら戦略部長だろうね 企業向けエンコーダーの技術戦略部トップとして引き抜かれたのかな 今、2.6+31 ? 更新が早くて新規のオプションとか調べてないなぁ・・・ ビルドだけはしてるんだけど >>60 2.6以降ってことなら追加・変更は下の4つくらいかなあ。 ・--fullhelp ・--gop-lookahead ・--radl ・--analysis-reuse-mode が消されて --analysis-save と --analysis-load に。 標準プリセットととしてはまあまあ妥当な気がする オプション見ただけだけど メディアプレイヤーとして大正義のPSがPS4proでも再生に対応してないのがだめだな GPUが対応してるproだけでもとっととやるべき、ソフト再生でPS3まで対応してくれたら神なんだけどなぁ ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ stableブランチはv2.7になってるけど、defaultブランチが7219376で止まってるから マージミスってねえかって話になってるように見える。 https://forum.doom9.org/showthread.php?t=168814& ;page=296 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 省略 ●Tom Vaughan x265プロジェクトの元リーダー。 >>55-59 にあるように、2018年1月中旬にライバル社のBeamrに移籍した。 ●Pradeep Ramachandran 最近のバージョンのタグ付けをしたり、Doom9やx265ブログでリリース記事を書いていた人。 x265ブログでTom Vaughan氏が書いていた過去記事も、今はこの人の名義に変わっている。 この人がプロジェクトリーダーを引きついだのだろうか? ●Ashok Kumar Mishra 2.7のタグ付けをした人クマー。 新たなリリース担当なんだろうか? 現時点ではDoom9にもx265ブログにもリリースアナウンスは来てないね。 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を作ってるとこだよ。次のリリースに入れるかも。) x265は素晴らしいなあ 今後の成熟がx264以上に楽しみだ でも新しい技術で過去のエンコをやり直したくなるので いつまで経っても作業が終わらないし元のソースも捨てられない PCでしか見ないからx265オンリーになってしまった 俺はPCでしか見ないの PCでしか見れない とは書いてないやろw 数日前のバージョン変更で、またエンコ速度が2/3になってんな 夜に放置しても終わってねぇ あ、やっぱり? バッチ実行がやけに停滞してるなとは思ってた doom9では話題になってないからrigaya氏のビルドミスかな riyaga氏のビルドは数日じゃない前(2.6+49)のものだから 自前か違う人のつかってんじゃないの? 【バイナリの入手元】 rigaya氏 【バージョンとx64/x86】 x265_2.6+49_x64 【コマンドオプション】 --preset slow/medium/veryfast --crf 18 これくらいの情報はちゃんと書いてほしいもんだよな・・・。 少なくとも上の条件では特に遅くなったりはしてないよ。 すんまそん エンコード中だったから差し替えての実験は後じゃ後、と思って細かい情報を調べずに書いちゃった さらに数日前に差し替えたから2.7かと・・ 改めて調べた結果x265じゃなく フロントエンドでの処理が遅い物になってるせいっぽい x265は濡れ衣みたい 自分でビルドすりゃええんでないかい。つかやらないの? ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて 自前でビルドしたほうがはええだろww 「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ? 有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん そうしてから新しいバージョンを使っても遅くはない そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ そんな噛みつかれることなのか? どしてほしいの、無能だからビルド出来ないとか言って欲しいの? ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは 専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、 配布バイナリで済ませてる人の方が多いんじゃね。 >>93 俺としては>>89 の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。 自分でしようと思いつつ本番エンコードの切れ目に出会えずテストできないんだけど だれかコンパイラの違いによる速度比較してくれない? https://mevius.5ch.net/test/read.cgi/avi/1486535501/528 主要部分asmで書いてるからコンパイラ変えてもたいして変わらんだろ 結果は誤差でした 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秒 >>102 また何も情報(入手元や設定や環境や条件)を書かずに速度が変わったとか言ってんのか・・・。 rigaya氏のブログの「x265ビルド VC2017版」の記事に、 x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる というコメントがあった。試してみたら、うちでも再現した。 2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。 >>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が固まる。たまにクラッシュすることもある。 >>106 試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、 >>105 でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。 2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、 それともL-SMASH側のバグなのか。 自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。 ちなみに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のみ。 最近h265のこと知ったけど本当にすごいな 容量1/3でひと目じゃ違いがわからないほどの画質だわ もっと早くに出会っていたかった 本当すごい h.264でいいじゃんとか思ってたが画質の良さ段違い >>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 使うタイプなんでそのせいかな。 >>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 >>107 多分そこだと思う ヘッダに16バイト分ゴミが混ざってて、そこを消すと正常になる 確認できたこと ・x265にバグがあって、不正なヘッダが出力される ・L-SMASHで問題が起こらないファイルも怪しい 参考 https://imgur.com/a/haoJR >>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 【画像】 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる