x265 rev4
1 :名無しさん@編集中 :2017/11/21(火) 20:18:20.98 ID:rz2nbV+s0.net 前スレ https://mevius.5ch.net/test/read.cgi/avi/1462270195/
2 :名無しさん@編集中 :2017/11/21(火) 20:18:37.47 ID:rz2nbV+s0.net 保守
3 :名無しさん@編集中 :2017/11/21(火) 20:18:54.11 ID:rz2nbV+s0.net 保守速報
4 :名無しさん@編集中 :2017/11/21(火) 20:19:04.55 ID:rz2nbV+s0.net 保守速報 敗訴
5 :名無しさん@編集中 :2017/11/21(火) 20:19:34.39 ID:rz2nbV+s0.net 保守速報 アフィカス
6 :名無しさん@編集中 :2017/11/21(火) 20:19:50.01 ID:rz2nbV+s0.net 保守速報 デマ
7 :名無しさん@編集中 :2017/11/21(火) 20:20:27.01 ID:rz2nbV+s0.net 保守速報 無能
8 :名無しさん@編集中 :2017/11/21(火) 20:20:42.04 ID:rz2nbV+s0.net 保守速報 差別
9 :名無しさん@編集中 :2017/11/21(火) 20:20:59.53 ID:rz2nbV+s0.net 保守速報 朝日新聞
10 :名無しさん@編集中 :2017/11/21(火) 20:21:15.54 ID:rz2nbV+s0.net 保守速報 ニート
11 :名無しさん@編集中 :2017/11/21(火) 20:21:37.77 ID:rz2nbV+s0.net 保守
12 :名無しさん@編集中 :2017/11/21(火) 20:22:02.43 ID:rz2nbV+s0.net 保守
13 :名無しさん@編集中 :2017/11/21(火) 20:22:42.24 ID:rz2nbV+s0.net 保守
14 :名無しさん@編集中 :2017/11/21(火) 20:22:59.57 ID:rz2nbV+s0.net 保守
15 :名無しさん@編集中 :2017/11/21(火) 20:23:49.65 ID:rz2nbV+s0.net 保守
16 :名無しさん@編集中 :2017/11/21(火) 20:24:18.56 ID:rz2nbV+s0.net 保守
17 :名無しさん@編集中 :2017/11/21(火) 20:24:40.45 ID:rz2nbV+s0.net 保守
18 :名無しさん@編集中 :2017/11/21(火) 20:25:02.54 ID:rz2nbV+s0.net 保守
19 :名無しさん@編集中 :2017/11/21(火) 20:25:17.62 ID:rz2nbV+s0.net 保守
20 :名無しさん@編集中 :2017/11/21(火) 20:25:37.50 ID:rz2nbV+s0.net 保守
21 :名無しさん@編集中 :2017/11/21(火) 20:26:06.58 ID:rz2nbV+s0.net 保守
22 :名無しさん@編集中 :2017/11/24(金) 19:48:33.87 ID:KEXFAbKU0.net 復活してた [転載k禁止]くらい付けたほうがいいと思うけど
23 :名無しさん@編集中 :2017/11/24(金) 20:09:16.69 ID:XHi7aZ3P0.net >>22 うるせーよ
24 :名無しさん@編集中 :2017/11/24(金) 20:21:13.13 ID:KEXFAbKU0.net [無断転載禁止]の間違いだった
25 :名無しさん@編集中 :2017/11/25(土) 19:05:02.89 ID:wxxEbk1K0.net 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/
26 :名無しさん@編集中 :2017/11/25(土) 19:06:25.65 ID:wxxEbk1K0.net [関連スレ] ・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/
27 :名無しさん@編集中 :2017/11/25(土) 19:13:29.21 ID:wxxEbk1K0.net とりあえず>>25-26 にテンプレ貼った。 ・バイナリにあった http://x265.ru/en/builds は2.4で止まってるので外した ・AviUtlスレは次スレ移行間近なので新スレ立ったらそっち貼らんとあかん そろそろ2.6がリリースされるみたいだね。
28 :名無しさん@編集中 :2017/11/25(土) 20:20:13.99 ID:mcEkRSHP0.net 乙乙 落ちない程度に話題があるといいんだけど
29 :名無しさん@編集中 :2017/11/25(土) 23:51:20.34 ID:pUfKTqBI0.net 結局ppsの最適化無効にされてて草
30 :名無しさん@編集中 :2017/11/26(日) 10:34:14.98 ID:5Fxd1ZK/0.net >>24 板の設定でそれを勝手に付け加える時とそうでない時があるので、スレ立て主は付けないのが普通 とりあえず>>1 乙
31 :名無しさん@編集中 :2017/11/26(日) 12:48:48.67 ID:csRAcU610.net >>26 AviUtlスレが新スレに移行 ・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ AviUtl総合スレッド87 http://egg.5ch.net/test/read.cgi/software/1511623060/
32 :名無しさん@編集中 :2017/11/29(水) 14:17:10.24 ID:PQuyMEHN0NIKU.net 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.
33 :名無しさん@編集中 :2017/11/30(木) 12:38:20.66 ID:qInbiEtX0.net New featuresだけじゃないし一応リリースノートも貼っておこう。 http://x265.readthedocs.io/en/default/releasenotes.html#version-2-6
34 :名無しさん@編集中 :2017/11/30(木) 18:02:19.23 ID:iTtzk9/60.net dllが認識しねえ
35 :名無しさん@編集中 :2017/12/03(日) 11:18:37.48 ID:TnTebv4Q0.net 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!
36 :名無しさん@編集中 :2017/12/03(日) 16:14:48.92 ID:TnTebv4Q0.net >>35 の件、昼過ぎに対応して下さったようで現在は問題ないようです。感謝。
37 :名無しさん@編集中 :2017/12/03(日) 16:38:19.21 ID:Gk5hLJk70.net 本家の仕様変更じゃなくてよかった
38 :名無しさん@編集中 :2017/12/03(日) 20:05:58.24 ID:QvRRd/ha0.net >>35 x265のスレというのがあったのだな おつあり
39 :名無しさん@編集中 :2017/12/04(月) 08:16:11.69 ID:vBDSisdnd.net >>37 まぁ、本家がビルドツール変えたんだけどな、 yasmから、nasmに。 で、nasmへのパス通し忘れてたって話。
40 :名無しさん@編集中 :2017/12/05(火) 23:58:55.59 ID:kofMPjsm0.net 2.6+8エンコおっそいな・・・ veryslow並だと2.5+69の半分以下 変わったオプションといえばgop-lookaheadが 増えたくらいなんだけどな
41 :名無しさん@編集中 :2017/12/07(木) 22:56:51.17 ID:X2cdoqOB0.net 環境依存なのか知らんがうちでもくっそ遅い・・・
42 :名無しさん@編集中 :2017/12/08(金) 00:02:09.07 ID:SacpmT240.net >>40-41 >>35-36 は読んだ?
43 :名無しさん@編集中 :2017/12/11(月) 17:19:12.12 ID:YxussJCL0.net doomのスレ読んで、x264はたった3000にも満たないコミット数で あの性能を実現してるのは凄いと思った
44 :名無しさん@編集中 :2017/12/26(火) 18:53:48.91 ID:STljgCt10.net ビットレート当たりの画質がかなり上がってるのね ver2に上がるかどうかのころはcrf22ないと劣化が分かったけど 今はcrf24で目に見える劣化無しでエンコードできるようになってる あくまで低ビットレート時の話だけど
45 :名無しさん@編集中 :2017/12/27(水) 13:58:34.76 ID:/ZZrfSta0.net 2018年後半に4K放送対応レコーダーを発売することが決まり、H.265のエンコード・でコードもサポートされるようになるみたいだが、 現段階でx265にて作成できるH.265ファイルはレコーダーやプレーヤーなどとの互換性は取れているのだろうか? x264が出てもしばらくの間、プレーヤーなどとの互換性、インターレース信号の取り扱い等、結構長く問題を引きずっていたような記憶があるのだが。
46 :名無しさん@編集中 :2017/12/27(水) 19:03:53.09 ID:XseWlzhm0.net 今の地デジだってモノが出始めてからも互換性の状況は変わったのに、今からそんな事を心配していると禿げると思うよ
47 :名無しさん@編集中 :2017/12/27(水) 21:12:17.50 ID:Ecy8Wi210.net x264の頃はメディアプレイヤーの存在自体が小さかったし ソフトウェアのほうもメディアプレイヤーを前提とした作りしてなかったから問題となったけど 今のx265はオプションにさえ気を付けたらだいじょうぶじゃね
48 :名無しさん@編集中 :2017/12/28(木) 12:58:51.47 ID:Uj3xk5410.net H.265 Main 10準拠で、レベルを5.1までに設定していたら大丈夫だと思う
49 :名無しさん@編集中 :2017/12/31(日) 11:43:53.69 ID:90rtTOjH0.net 誰でも自分PCで稼げる方法など 参考までに、 ⇒ 『政道のゴウイウセレイイ』 というHPで見ることができます。 グーグルで検索⇒『政道のゴウイウセレイイ』 8RNNMQEE3I
50 :44 :2017/12/31(日) 14:00:18.29 ID:yaotpISH0.net ちなみにオプションの--rectと--limited-ref(preset slowで有効になるやつ)は 他オプションを犠牲にしてでも使わないと あんまりパッとしない感じだった
51 :名無しさん@編集中 :2017/12/31(日) 14:32:32.59 ID:dk79hbO30.net >>50 --limited-refなんてオプションは無いし、--limit-refsのことならmediumもslowも値は3で差がない。 slowで有効になるオプションで似た名前のものだとしたら、--limit-modesじゃないの。
52 :名無しさん@編集中 :2018/01/01(月) 19:52:28.70 ID:dlGBebkV0.net >>51 指摘thx たぶん、それだ rigayaさんのGuiEX使ってるからオプション名はあやふやで・・
53 :名無しさん@編集中 :2018/01/13(土) 01:22:23.81 ID:exMofL5M0.net テンプレ>>26 のH.265/HEVCスレPart7から、AV1等も含めた総合スレが派生。 次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】 http://mevius.5ch.net/test/read.cgi/avi/1515759816/ H.265/HEVCスレ(他のコーデックの話は禁止になるらしい)の次スレが立つかどうかは不明。
54 :名無しさん@編集中 :2018/01/18(木) 02:52:53.94 ID:COlz2Rab0.net 2.6+19にバグ。2.6+28(d9fa3c6)で修正。 https://forum.doom9.org/showthread.php?p=1830262#post1830262
55 :名無しさん@編集中 :2018/01/18(木) 03:19:00.26 ID:COlz2Rab0.net 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 ---
56 :名無しさん@編集中 :2018/01/18(木) 03:22:02.90 ID:COlz2Rab0.net えーと・・・? >>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にどれくらいの影響が出るんだろう? 結構でかい話だよねこれ?
57 :名無しさん@編集中 :2018/01/18(木) 03:22:20.65 ID:spZBbxZ30.net 俺もそっちのが気になったw
58 :名無しさん@編集中 :2018/01/18(木) 03:44:10.05 ID:COlz2Rab0.net ●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!
59 :名無しさん@編集中 :2018/01/18(木) 10:57:17.84 ID:9hkEcJF1d.net >>56 直訳なら戦略部長だろうね 企業向けエンコーダーの技術戦略部トップとして引き抜かれたのかな
60 :名無しさん@編集中 :2018/01/20(土) 11:09:00.15 ID:J55Co1cK0.net 今、2.6+31 ? 更新が早くて新規のオプションとか調べてないなぁ・・・ ビルドだけはしてるんだけど
61 :名無しさん@編集中 :2018/01/20(土) 17:49:24.71 ID:XIH6s3g30.net >>60 2.6以降ってことなら追加・変更は下の4つくらいかなあ。 ・--fullhelp ・--gop-lookahead ・--radl ・--analysis-reuse-mode が消されて --analysis-save と --analysis-load に。
62 :名無しさん@編集中 :2018/02/06(火) 17:43:05.95 ID:fykcdiAe0.net --tune anime が実装予定? https://forum.doom9.org/showthread.php?p=1832924#post1832924
63 :名無しさん@編集中 :2018/02/06(火) 23:17:58.23 ID:dGWrYNQA0.net 標準プリセットととしてはまあまあ妥当な気がする オプション見ただけだけど
64 :名無しさん@編集中 :2018/02/15(木) 19:09:13.07 ID:kjnv49rj0.net メディアプレイヤーとして大正義のPSがPS4proでも再生に対応してないのがだめだな GPUが対応してるproだけでもとっととやるべき、ソフト再生でPS3まで対応してくれたら神なんだけどなぁ
65 :名無しさん@編集中 :2018/02/16(金) 19:42:17.97 ID:Ohttwh5c0.net ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
66 :名無しさん@編集中 :2018/02/18(日) 16:47:37.06 ID:cT206ufy0.net 久々にビルドしたら+42になってた
67 :名無しさん@編集中 :2018/02/21(水) 00:03:33.19 ID:mEU+3qSI0.net お、もうそろそろv2.7に上がるっぽい
68 :名無しさん@編集中 :2018/02/23(金) 10:24:59.55 ID:B6bO8Kex0.net +49になってるな
69 :名無しさん@編集中 :2018/02/23(金) 21:02:27.43 ID:pufaCppw0.net stableブランチはv2.7になってるけど、defaultブランチが7219376で止まってるから マージミスってねえかって話になってるように見える。 https://forum.doom9.org/showthread.php?t=168814&page=296
70 :名無しさん@編集中 :2018/02/23(金) 21:05:02.63 ID:pufaCppw0.net 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 省略
71 :名無しさん@編集中 :2018/02/23(金) 23:09:09.63 ID:B6bO8Kex0.net リリースした人もなんかいつもと違うしな
72 :名無しさん@編集中 :2018/02/23(金) 23:38:24.10 ID:A98HmW5S0.net だれか抜けたし・・
73 :名無しさん@編集中 :2018/02/24(土) 00:09:46.21 ID:IJ/q997/0.net ●Tom Vaughan x265プロジェクトの元リーダー。 >>55-59 にあるように、2018年1月中旬にライバル社のBeamrに移籍した。 ●Pradeep Ramachandran 最近のバージョンのタグ付けをしたり、Doom9やx265ブログでリリース記事を書いていた人。 x265ブログでTom Vaughan氏が書いていた過去記事も、今はこの人の名義に変わっている。 この人がプロジェクトリーダーを引きついだのだろうか? ●Ashok Kumar Mishra 2.7のタグ付けをした人クマー。 新たなリリース担当なんだろうか? 現時点ではDoom9にもx265ブログにもリリースアナウンスは来てないね。
74 :名無しさん@編集中 :2018/02/27(火) 21:07:15.20 ID:RF6Dt5VJ0.net 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を作ってるとこだよ。次のリリースに入れるかも。)
75 :名無しさん@編集中 :2018/02/27(火) 22:10:42.33 ID:m66yW5CS0.net それは期待!
76 :名無しさん@編集中 :2018/02/27(火) 22:50:45.91 ID:PWIp0qlu0.net x265は素晴らしいなあ 今後の成熟がx264以上に楽しみだ
77 :名無しさん@編集中 :2018/02/28(水) 01:42:44.77 ID:1rtY1VNW0.net くまさん大好き
78 :名無しさん@編集中 :2018/02/28(水) 14:26:23.44 ID:jKvBP87o0.net でも新しい技術で過去のエンコをやり直したくなるので いつまで経っても作業が終わらないし元のソースも捨てられない
79 :名無しさん@編集中 :2018/03/06(火) 21:57:21.07 ID:UEIWdPbv0.net PCでしか見ないからx265オンリーになってしまった
80 :名無しさん@編集中 :2018/03/06(火) 21:58:04.12 ID:oJoD7N5N0.net スマホでも見れるでしょ
81 :名無しさん@編集中 :2018/03/06(火) 21:59:58.57 ID:UEIWdPbv0.net 俺はPCでしか見ないの PCでしか見れない とは書いてないやろw
82 :名無しさん@編集中 :2018/03/07(水) 00:05:15.75 ID:SCUiNxq00.net 知るかボケ
83 :名無しさん@編集中 :2018/03/08(木) 09:41:50.94 ID:Th3QT3qE0.net 数日前のバージョン変更で、またエンコ速度が2/3になってんな 夜に放置しても終わってねぇ
84 :名無しさん@編集中 :2018/03/08(木) 14:50:23.01 ID:WnQT6+5V0.net あ、やっぱり? バッチ実行がやけに停滞してるなとは思ってた doom9では話題になってないからrigaya氏のビルドミスかな
85 :名無しさん@編集中 :2018/03/08(木) 14:58:24.26 ID:3gXZSWSZ0.net riyaga氏のビルドは数日じゃない前(2.6+49)のものだから 自前か違う人のつかってんじゃないの?
86 :名無しさん@編集中 :2018/03/08(木) 16:11:42.24 ID:wHUMYfkz0.net 【バイナリの入手元】 rigaya氏 【バージョンとx64/x86】 x265_2.6+49_x64 【コマンドオプション】 --preset slow/medium/veryfast --crf 18 これくらいの情報はちゃんと書いてほしいもんだよな・・・。 少なくとも上の条件では特に遅くなったりはしてないよ。
87 :sage :2018/03/08(木) 17:21:53.79 ID:WnQT6+5V0.net すんまそん エンコード中だったから差し替えての実験は後じゃ後、と思って細かい情報を調べずに書いちゃった さらに数日前に差し替えたから2.7かと・・
88 :名無しさん@編集中 :2018/03/08(木) 23:47:27.45 ID:WnQT6+5V0.net 改めて調べた結果x265じゃなく フロントエンドでの処理が遅い物になってるせいっぽい x265は濡れ衣みたい
89 :名無しさん@編集中 :2018/03/10(土) 17:08:27.99 ID:zQVq4EBV0.net 2.7+12のビルドきてるな
90 :名無しさん@編集中 :2018/03/10(土) 20:05:08.36 ID:DTbkPk/u0.net 自分でビルドすりゃええんでないかい。つかやらないの?
91 :名無しさん@編集中 :2018/03/11(日) 00:30:35.91 ID:xNuwG3/a0.net 誰も早くビルドしろなんぞいってないので
92 :名無しさん@編集中 :2018/03/11(日) 03:28:34.13 ID:KKe7Ux5L0.net ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて 自前でビルドしたほうがはええだろww 「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ?
93 :名無しさん@編集中 :2018/03/11(日) 03:52:49.72 ID:xNuwG3/a0.net 有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん そうしてから新しいバージョンを使っても遅くはない そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ そんな噛みつかれることなのか? どしてほしいの、無能だからビルド出来ないとか言って欲しいの?
94 :名無しさん@編集中 :2018/03/11(日) 04:00:12.62 ID:+k5ziIx80.net ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは 専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ
95 :名無しさん@編集中 :2018/03/11(日) 09:36:43.86 ID:adjJPCXV0.net PC関連の板はコミュ障が多い
96 :名無しさん@編集中 :2018/03/11(日) 10:01:35.40 ID:jHzQQm8J0.net 多いいうても一人でっせ>ここで噛みついてるのは
97 :名無しさん@編集中 :2018/03/11(日) 11:44:38.24 ID:SslWpV+I0.net ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、 配布バイナリで済ませてる人の方が多いんじゃね。 >>93 俺としては>>89 の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。
98 :名無しさん@編集中 :2018/03/11(日) 12:20:59.26 ID:xNuwG3/a0.net みんな優しいな ありがとう
99 :名無しさん@編集中 :2018/03/14(水) 23:26:50.13 ID:y6ohaLHf0.net 自分でしようと思いつつ本番エンコードの切れ目に出会えずテストできないんだけど だれかコンパイラの違いによる速度比較してくれない? https://mevius.5ch.net/test/read.cgi/avi/1486535501/528
100 :名無しさん@編集中 :2018/03/15(木) 16:56:46.86 ID:wxEaCQFy0.net 主要部分asmで書いてるからコンパイラ変えてもたいして変わらんだろ
101 :名無しさん@編集中 :2018/03/16(金) 20:53:41.13 ID:bn2kqBbr0.net 結果は誤差でした 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 :名無しさん@編集中 :2018/03/17(土) 04:18:51.99 ID:w5F0KcJ/0.net 2.7+14はいいね。元の速度がでるわ
103 :名無しさん@編集中 :2018/03/17(土) 04:50:33.96 ID:l+K3ScE80.net >>102 また何も情報(入手元や設定や環境や条件)を書かずに速度が変わったとか言ってんのか・・・。
104 :名無しさん@編集中 :2018/03/26(月) 01:10:10.16 ID:xaZyoL940.net rigaya氏のブログの「x265ビルド VC2017版」の記事に、 x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる というコメントがあった。試してみたら、うちでも再現した。 2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。
105 :名無しさん@編集中 :2018/03/26(月) 19:29:12.01 ID:KAWe9XE/0.net >>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 :名無しさん@編集中 :2018/03/27(火) 14:22:05.18 ID:hAwfzym80.net L-SMASH 側でなんかコミットあったようだけど無関係? https://github.com/l-smash/l-smash/commits/master
107 :名無しさん@編集中 :2018/03/27(火) 15:23:43.35 ID:lGCQMxzy0.net >>106 試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、 >>105 でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。 2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、 それともL-SMASH側のバグなのか。 自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。
108 :名無しさん@編集中 :2018/03/27(火) 15:28:23.56 ID:lGCQMxzy0.net ちなみに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のみ。
109 :名無しさん@編集中 :2018/03/27(火) 15:36:01.63 ID:G0IAA57sM.net 最近h265のこと知ったけど本当にすごいな 容量1/3でひと目じゃ違いがわからないほどの画質だわ もっと早くに出会っていたかった
110 :名無しさん@編集中 :2018/03/27(火) 15:40:51.57 ID:g+k3xdKBd.net 本当すごい h.264でいいじゃんとか思ってたが画質の良さ段違い
111 :名無しさん@編集中 :2018/03/27(火) 18:34:20.56 ID:hAwfzym80.net >>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 使うタイプなんでそのせいかな。
112 :名無しさん@編集中 :2018/03/27(火) 19:35:05.90 ID:zm8guuOZ0.net >>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
113 :名無しさん@編集中 :2018/03/27(火) 20:02:39.73 ID:wDAUP5Ia0.net >>107 多分そこだと思う ヘッダに16バイト分ゴミが混ざってて、そこを消すと正常になる
114 :名無しさん@編集中 :2018/03/28(水) 02:43:02.76 ID:g/KUYe660.net 確認できたこと ・x265にバグがあって、不正なヘッダが出力される ・L-SMASHで問題が起こらないファイルも怪しい 参考 https://imgur.com/a/haoJR
115 :名無しさん@編集中 :2018/03/28(水) 14:01:27.08 ID:bOMavOh+0.net >>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 【画像】
116 :名無しさん@編集中 :2018/03/28(水) 14:18:38.25 ID:g/KUYe660.net >>115 私は不慣れなので、すみませんが連絡をお願いします
117 :名無しさん@編集中 :2018/03/28(水) 15:17:15.09 ID:wZNcV2S/0.net doom9覗いたらすでに報告されてたから じきに直るのでは
118 :名無しさん@編集中 :2018/03/28(水) 16:20:16.71 ID:bOMavOh+0.net >>116 報告しておきました。感謝。 https://forum.doom9.org/showthread.php?p=1837693#post1837693
119 :名無しさん@編集中 :2018/03/28(水) 21:48:16.17 ID:wZNcV2S/0.net 物事が一気に動き出した感が凄いね 解析人&報告人おつかれ
120 :名無しさん@編集中 :2018/03/30(金) 21:44:43.67 ID:MI5GTo4n0.net 2.7+15〜2.7+19で発生していた>>104-118 のSEIバグは、2.7+20で修正されたようです。 https://bitbucket.org/multicoreware/x265/commits/3440a56acc7865dcdea725b8ce7755450209a8ee
121 :名無しさん@編集中 :2018/03/31(土) 13:09:26.20 ID:ZmwRNZhu0.net 報告人乙 AVX512よりOpenCLアクセラレーションをだな・・
122 :名無しさん@編集中 :2018/04/02(月) 21:59:54.29 ID:f5J0o+Po0.net +22になってたが、 使ってるパラメータは昔から全然変えてないな 少しは見直したほうがいいのか・・・
123 :名無しさん@編集中 :2018/04/09(月) 21:13:37.30 ID:LTQ45mIz0.net AVX512のコードをレビュー中みたいだけど AVX/AVX2のコードも含まれてるのかな
124 :名無しさん@編集中 :2018/04/10(火) 12:59:16.94 ID:mvAZrsZe0.net 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%のスピードアップに成功したよという発表。
125 :名無しさん@編集中 :2018/04/10(火) 13:16:00.32 ID:mvAZrsZe0.net 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拡大のため業界のエキスパートに声をかけている。
126 :名無しさん@編集中 :2018/04/10(火) 13:20:34.68 ID:xP4Na1DRa.net >>124 18%か そろそろ最新世代のCPUを検討するか (AMDは対応してないんだよね?)
127 :名無しさん@編集中 :2018/04/10(火) 13:52:51.85 ID:IB8fQ2qt0.net CoffeelakeはAVX512非対応だよ
128 :名無しさん@編集中 :2018/04/10(火) 14:32:56.31 ID:xP4Na1DRa.net >>127 マジで? では対応しているCPUって?
129 :名無しさん@編集中 :2018/04/10(火) 14:41:37.90 ID:mvAZrsZe0.net >>128 聞く前にググろうぜ。 AVX-512 - Wikipedia https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
130 :名無しさん@編集中 :2018/04/10(火) 18:05:05.59 ID:HFQoF9+f0.net >>124 ダイを倍の大きさにして18%は割に合わねぇ・・ SDR/2kだとどうなるんだろか
131 :名無しさん@編集中 :2018/04/10(火) 20:39:06.61 ID:sYlLCMQI0.net ryzen3000とicelakeの対決が楽しみやね
132 :名無しさん@編集中 :2018/04/12(木) 15:38:59.01 ID:n+ScPlN90.net AVX512向けパッチが入ったみたい なかなか圧巻だけどAVX512だけでつまらない
133 :名無しさん@編集中 :2018/04/13(金) 02:01:43.85 ID:NWyIYo2t0.net AVX512の大量コミットで一気に x265 2.7+336 になったのか・・・w
134 :名無しさん@編集中 :2018/04/13(金) 02:22:20.69 ID:NWyIYo2t0.net というか、もう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/
135 :名無しさん@編集中 :2018/04/13(金) 08:19:53.51 ID:9wcAjWee0.net >>134 それを追加すると、どんなメリットが発生するの?
136 :名無しさん@編集中 :2018/04/13(金) 08:37:04.29 ID:5x5KpZpr0.net >>135 SSIMやPSNRより参考になる可能性がある
137 :名無しさん@編集中 :2018/04/13(金) 09:09:50.94 ID:9wcAjWee0.net >>136 そういうことか Thx
138 :名無しさん@編集中 :2018/04/13(金) 11:58:14.00 ID:+CW60tiR0.net ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・? ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら --recon(でかいYUVファイルも出力する)をつけないとエンコードできなくなるような・・・? VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。 おとなしくffmpegで計測したほうがよさそうだ。
139 :名無しさん@編集中 :2018/04/13(金) 18:45:37.92 ID:qCymtqNK0.net 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を使ったということなんだろか? (ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。)
140 :名無しさん@編集中 :2018/04/15(日) 02:04:37.98 ID:3zo9kCKG0.net rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。 > 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで > プロファイルによる最適化を実施した実行ファイルに差し替えました。
141 :名無しさん@編集中 :2018/04/15(日) 08:24:32.12 ID:aTNvjuUP0.net 340で修正されたね
142 :名無しさん@編集中 :2018/04/18(水) 15:36:59.22 ID:YRWrQNWv0.net ちょっと質問。 2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環? ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。 --asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。
143 :名無しさん@編集中 :2018/04/18(水) 16:34:27.96 ID:cXV5p2iF0.net aviutlのguiEX経由だけど問題なくエンコードできてるよ
144 :名無しさん@編集中 :2018/04/18(水) 17:18:59.94 ID:HTI1sHZw0.net うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。 ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。 どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。
145 :名無しさん@編集中 :2018/04/18(水) 17:52:15.27 ID:YRWrQNWv0.net x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。 その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。 他の人が問題無いなら当方の おま環 ということですね。
146 :名無しさん@編集中 :2018/04/18(水) 18:08:23.54 ID:m5UZEJ3o0.net https://msdn.microsoft.com/ja-jp/library/abx4dbyh.aspx スタティックリンクしたら、大丈夫なのかな(未検証
147 :名無しさん@編集中 :2018/04/18(水) 18:15:27.44 ID:YRWrQNWv0.net 試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・ 自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!
148 :名無しさん@編集中 :2018/04/19(木) 12:02:15.65 ID:CAIRBG+rd.net >>145 VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。 stable持ってきてビルドすれば動くよ。 まぁ、そのうちdefaultにも入るだろうけど。
149 :名無しさん@編集中 :2018/04/20(金) 03:43:40.27 ID:p8ollzQJ0.net +340-stable ビルドした AVX512は装備してないけど、だいぶ速くなってる感触 まぁ、動画ソースの問題もあるかもしれなくて全然厳密じゃないが
150 :名無しさん@編集中 :2018/04/20(金) 10:30:35.72 ID:+I7QsHZu0.net Ryzenだと128bit実行のせいか0.5fps程度の違いだった(早くはなってる
151 :名無しさん@編集中 :2018/04/20(金) 13:58:16.07 ID:PbP8t3sj0.net 「速くなった」って、いつのバイナリと比較してるんだ・・・? 最近ではAVX512以外に高速化要素なんて無いと思うんだけど。
152 :名無しさん@編集中 :2018/04/20(金) 14:11:15.36 ID:hscY5VHv0.net 漏れも全然感じない
153 :名無しさん@編集中 :2018/04/20(金) 17:08:18.30 ID:p8ollzQJ0.net 論理コアが多いほど速度向上を体感しやすいのかも 全く根拠はないが
154 :名無しさん@編集中 :2018/04/20(金) 17:32:44.04 ID:PbP8t3sj0.net 「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。 必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。
155 :名無しさん@編集中 :2018/04/20(金) 18:10:17.26 ID:CCChLuwY0.net >>150 その表現じゃ伝わらん 1.0fpsと1.5fpsなのか100.0fpsと100.5fpsで全然話が違うぞ
156 :名無しさん@編集中 :2018/04/20(金) 18:47:30.17 ID:+I7QsHZu0.net 別に伝わらなくていいと思ってる(ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ) カキコした私が誤差程度と判断したから情報としてまとめなかったけども
157 :名無しさん@編集中 :2018/04/20(金) 18:50:30.44 ID:hscY5VHv0.net Ryzenなら、メモリ回り詰めれば速くなる。
158 :名無しさん@編集中 :2018/04/20(金) 20:18:13.59 ID:5wKx8vum0.net 来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ
159 :名無しさん@編集中 :2018/04/23(月) 11:28:44.66 ID:BRPMKJ720.net 先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ とネットでみたのですが その理由がわかりませんでした これはどういう意味があるんでしょうか? また実際につけた方がよいものなのでしょうか?
160 :名無しさん@編集中 :2018/04/23(月) 12:19:03.19 ID:p76LCKVz0.net AVX2 を使うと逆にエンコード速度が落ちるからだよ〜 AVX までに制限してやることで数 fps ほど速度あがる。 実際に --asm avx の有無でエンコ比較してみると良いかも。
161 :名無しさん@編集中 :2018/04/23(月) 12:32:40.97 ID:diM3xT4md.net 本当、何の為に実装したんだか
162 :名無しさん@編集中 :2018/04/23(月) 13:04:20.60 ID:BRPMKJ720.net >>160 ありがとうございます そういう意味があったんですね これで心置きなく試してこれそうです
163 :名無しさん@編集中 :2018/04/23(月) 15:47:10.80 ID:QffvhQ240.net AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな
164 :名無しさん@編集中 :2018/04/23(月) 18:56:54.20 ID:ov3R+Oo10.net >>162 x264はAVX2切った方が速いけどx265はAVX2の効果高い事多いので on/off両方試して、自分の環境に合ってる方法とるべし
165 :名無しさん@編集中 :2018/04/27(金) 18:15:06.70 ID:PLvUpLvx0.net h.264とh.265でtune別 crf別にssim値をプロットしたようなグラフを昔に見た記憶がありそれを探してるのですが わかる人いたら教えてください
166 :名無しさん@編集中 :2018/04/27(金) 20:48:13.46 ID:1O42is100.net 過去ログにいくつかあるね ただ作られたのがかなり前だしプリセットの内容も変わってるから今だと参考にならない 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
167 :名無しさん@編集中 :2018/05/21(月) 23:30:48.36 ID:bTBIMDBb0.net 2.8 来たな。 VS 2016 Community で普通にビルドして --asm avx 付けてもエラー出なくなってたわ。よかった
168 :名無しさん@編集中 :2018/05/22(火) 00:30:38.73 ID:6Qanf6ox0.net Release Notes Version 2.8 - 21/05/2018 http://x265.readthedocs.io/en/default/releasenotes.html#version-2-8
169 :名無しさん@編集中 :2018/05/22(火) 00:42:27.48 ID:Q29sG+kB0.net 3.0じゃないんだ
170 :名無しさん@編集中 :2018/06/02(土) 07:58:01.86 ID:ZfXg0V8T0.net http://satch.tv/members/honeybee909/?mref=787
171 :名無しさん@編集中 :2018/06/02(土) 09:21:02.21 ID:rOXpoqpp0.net http://satch.tv/?mref=115
172 :名無しさん@編集中 :2018/06/02(土) 09:21:06.60 ID:rOXpoqpp0.net http://satch.tv/?mref=115
173 :名無しさん@編集中 :2018/06/19(火) 18:25:04.97 ID:uDXUEk/b0.net やっぱり画質が良くなるオプションは重いのね いつもなら終わってた量のタスクが終わってなかったは それはそうと新AQモードの実装はまだかな 画質あがって早くなったら嬉しいんだけども
174 :名無しさん@編集中 :2018/06/19(火) 19:44:41.68 ID:E9MLTUx7M.net なんのこっちゃ?
175 :名無しさん@編集中 :2018/06/19(火) 20:43:16.16 ID:Xfn02oug0.net 新AQモードというのは>>74 のことかな?その後どうなったんだろね。
176 :名無しさん@編集中 :2018/06/20(水) 07:29:13.09 ID:vvaAAzN50.net 最近は更新激しくてパラメータよく解らなくなってきてるな でもAQは影響デカイパラメータだよね 期待
177 :名無しさん@編集中 :2018/06/20(水) 23:03:45.23 ID:GbvFn6Ss0.net いうほど変わったっけ? どうしてもx264全盛期と比べて遅く感じてしまう
178 :名無しさん@編集中 :2018/06/21(木) 20:45:03.70 ID:rlr2EKZD0.net x265のバラメータは不勉強だわ 一回本腰入れて覚えないと
179 :名無しさん@編集中 :2018/06/21(木) 23:07:50.33 ID:xqqnzSI30.net --sao-non-deblock 実写は↑+SAOおすすめ 逆にこれ使わないならSAOを使わないほうがいい (テスト期間2日だけど
180 :名無しさん@編集中 :2018/07/08(日) 11:05:54.93 ID:qBHDX1Nu0.net 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
181 :名無しさん@編集中 :2018/07/08(日) 11:15:03.97 ID:a2fe6VVL0.net ほお。 うちも Ryzen 環境だからちょっとビルドして試してみるかー
182 :名無しさん@編集中 :2018/07/08(日) 11:26:02.65 ID:CHv2DBnH0.net x264はAVX2無しの方が速いけどx265は付けないと駄目だよ
183 :名無しさん@編集中 :2018/07/08(日) 11:34:12.01 ID:a2fe6VVL0.net >>182 今まではそれが常識的な物だったけど AVX2 使った方が速かったよってお話しじゃないの? まぁ今ビルドおわったんでちょっと試してみるわ
184 :名無しさん@編集中 :2018/07/08(日) 12:01:26.32 ID:a2fe6VVL0.net 俺環での同テスト あくまで --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 を使った方が微妙に速くなるかもしれん。
185 :名無しさん@編集中 :2018/07/08(日) 12:28:09.63 ID:a2fe6VVL0.net 追試というか 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 を削れそうですわ
186 :名無しさん@編集中 :2018/07/08(日) 13:08:36.86 ID:HkL359170.net Ryzenつってもいくつかあるんだからモデルくらい明記したほうがいいだろうし、 解像度もちゃんと書いたほうがいいと思う・・・。
187 :名無しさん@編集中 :2018/07/08(日) 13:42:40.94 ID:xXdNGq9Q0.net AVX2を使うか否かでエンコード速度がーーって話にCPU型番と解像度って必要な話なのかなww
188 :名無しさん@編集中 :2018/07/08(日) 14:17:34.19 ID:qBHDX1Nu0.net まぁ、たしかに解像度などで処理の負荷や傾向も変わるからね 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
189 :名無しさん@編集中 :2018/07/08(日) 14:21:18.43 ID:HkL359170.net >>187 なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。 言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。
190 :名無しさん@編集中 :2018/07/08(日) 14:32:40.17 ID:a2fe6VVL0.net 俺も環境かいとく流れかな 偶然俺も 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 使わないままだったと思うしw
191 :名無しさん@編集中 :2018/07/08(日) 14:33:57.66 ID:a2fe6VVL0.net 引数間違えてた --sar 1:1 じゃなくて --sar 4:3 だた。
192 :名無しさん@編集中 :2018/07/08(日) 14:43:02.06 ID:+0goipd80.net >>189 ハイスペ側だとなにかしらのボトルネックで頭打ちが発生して大差なくなるとかあり得るものね
193 :名無しさん@編集中 :2018/07/08(日) 14:47:32.78 ID:HkL359170.net >>192 だよね。 情報書いてくれた方々ありがとう。
194 :名無しさん@編集中 :2018/07/08(日) 16:25:53.01 ID:R57rVJt10.net ryzenが出た頃に10bit出力ならAVX2ありの方が僅かに早い、ってrigaya氏がすでに言ってたの 意外と知られてなかったんだな
195 :名無しさん@編集中 :2018/07/08(日) 17:16:20.30 ID:igBBszGI0.net >>194 うちの環境ではそれでも AVX2 有りだと遅くなってたのよ。
196 :名無しさん@編集中 :2018/07/08(日) 18:41:50.71 ID:qBHDX1Nu0.net 早いこともあれば遅いこともあったと思うけど ここしばらくはAVX2使わないほうが早かった
197 :名無しさん@編集中 :2018/07/13(金) 19:06:48.35 ID:phGGD7kZ0.net 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
198 :名無しさん@編集中 :2018/07/13(金) 19:32:00.19 ID:ev3/ZGri0.net >>197 --max-mergeの値を上げると画像がボケる
199 :名無しさん@編集中 :2018/07/13(金) 20:09:01.25 ID:phGGD7kZ0.net low-bitrate帯でボケる? それとも割り当てられるbitrateが少なくなるからボケるのどっち? crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど
200 :名無しさん@編集中 :2018/07/14(土) 20:04:30.79 ID:ahvHITJu0.net ボケる結果ビットレートが低くなる
201 :名無しさん@編集中 :2018/07/14(土) 22:41:08.93 ID:YCb4PdI30.net 高ビットレートだとボケないのかな?っていうことを聞きたかったんだけど、そこまでは読み取れない? 上から目線であれだけど、英文の記号の使い方とかよー分らん
202 :名無しさん@編集中 :2018/07/15(日) 14:05:01.45 ID:nLoHgNZz0.net 一度ボケたらいかにビットを割り振ろうと元には戻らないので、ディテールを残したければ--max-mergeを下げるべきだろう
203 :名無しさん@編集中 :2018/07/15(日) 14:13:15.85 ID:jCJzclqYa.net ビットレートに余裕があるときにどんな動きをするか聞きたいんじゃない 問答無用でマージしてビットレート下げに行くのか、余裕があるなら働かないのか
204 :名無しさん@編集中 :2018/07/15(日) 14:32:55.47 ID:nLoHgNZz0.net >>問答無用でマージしてビットレート下げに行く 英文を素直に解釈すればこっち
205 :名無しさん@編集中 :2018/07/15(日) 14:50:01.74 ID:er4i/YnR0.net >>202-204 thx 情報の共有と省略、粗のごまかしに心血を注いでるから 副作用なく高圧縮・高画質化ってのは難しいのね
206 :名無しさん@編集中 :2018/07/19(木) 01:21:23.72 ID:VQByvLN90.net 久しぶりにx265のオプション見直そうと思ったけど 色々変わってるからpresetとcrfだけでいいような気もしてきた
207 :名無しさん@編集中 :2018/07/19(木) 23:38:19.76 ID:WdSoljMy0.net >>206 >179のオプションいいぞ
208 :名無しさん@編集中 :2018/07/23(月) 11:15:48.83 ID:k8tyZ7ag0.net http://forum.doom9.org/showthread.php?p=1846852#post1846852 これデブロッキング・フィルタを無効にしてるせいだと思うんだけどどうよ
209 :名無しさん@編集中 :2018/07/29(日) 03:19:48.57 ID:ofEesbc00.net 質問です。 エンコードするときに設定するビットレートの目安を求めたいのですが、 ttp://web.archive.org/web/20130207145934/http://service.jp.real.com/help/faq/prod/faq_4226.html とか ttps://www.lizardk.net/2011/05/h264.html に書いてある式と、それで求められる値は当てにして良いものですか? コーデックの話であって、エンコーダによって全然違うとかあるなら微妙なんですが・・・。 さらに、ここで求めた値を50%〜60%くらいにすればx265でのビットレートとして使えますか?
210 :名無しさん@編集中 :2018/07/29(日) 08:38:34.01 ID:EBUxRnOm0.net 固定ビットレートでエンコードするなら、目安になるのでは? 固定品質でエンコードの場合は、全然、目安にならないけど。
211 :名無しさん@編集中 :2018/07/29(日) 08:51:34.14 ID:8BfhzM290.net >>209 50〜60%は行き過ぎかな H.265は公称ではH.264の半分のビットレートで同等の画質って言ってるが実際は30%減くらいだと思う
212 :名無しさん@編集中 :2018/07/29(日) 09:00:12.20 ID:WkF14PaEM.net x264は動画版lame(mp3高性能エンコーダー)みたく規格上のギリギリで高効率に圧縮してるからなぁ x264はほぼ完成してるけどx265はまだ発展途上だからまだ半分は行けないよな
213 :名無しさん@編集中 :2018/07/29(日) 09:41:12.17 ID:p8xSZ0wf0.net >>209 real playerのころとは比べ物にならないぐらい圧縮率は向上してるから半分ぐらいでちょうどいいと思うけど どのみちビットレート指定方式では仕組み的に高画質は無理(6Mbpsぐらいつぎ込めば話は別だけど ま、基本的にcrfモードを使うのが推奨された使い方 x264なら crf=22~23、x265なら crf=24~26 がビットレートと画質のバランスがいい
214 :名無しさん@編集中 :2018/07/29(日) 11:42:11.98 ID:UxujymIy0.net エンコーダ間の比較っていう意味ではこんな資料が https://wyohknott.github.io/video-formats-comparison/ でも最近のエンコーダだと、要求ビットレートが 総画素数/フレームレートに比例するかどうかは怪しい気がするけど…
215 :名無しさん@編集中 :2018/07/29(日) 13:45:21.35 ID:ofEesbc00NIKU.net なるほど、みなさんありがとうございます。 >>210 下のURLの方だと、「VBRの最大ビットレートはこの2倍くらいにします」とあるんですが、
216 :名無しさん@編集中 :2018/07/29(日) 13:46:57.15 ID:ofEesbc00NIKU.net Shift+Enterしてしまったごめんなさい VBRの最大ビットレートはこの2倍くらいにします、とあるんですが、 CBRに比べたVBRやCQPのビットレートの振れ幅というのは2倍や0.5倍の範囲内に収まるものなんでしょうか。 詳しい方いましたら教えてください。
217 :名無しさん@編集中 :2018/07/29(日) 14:05:38.85 ID:qungLzDW0NIKU.net 最大ビットレートは入力ソースの最大でいいよ。
218 :名無しさん@編集中 :2018/07/29(日) 14:06:19.56 ID:p8xSZ0wf0NIKU.net x264, x265のビットレート指定エンコードだと2倍もは変動しなかったはず (crfな品質指定エンコードだと3倍ぐらい変動するけど)
219 :名無しさん@編集中 :2018/07/29(日) 14:11:12.64 ID:MNacyzm00NIKU.net ソースによる
220 :名無しさん@編集中 :2018/07/29(日) 14:40:29.28 ID:nivXCK+nMNIKU.net 最大ビットレートなんて、再生環境が使える上限値にしとくだけだよ これ以上にすると再生できなくなるから超えないようにエンコードしなさいという値なのだから 2倍とか関係ない
221 :名無しさん@編集中 :2018/07/29(日) 15:27:57.92 ID:wdaToWzEMNIKU.net 例えば地デジtsなら上限10Mbpsで十分だな てか何故かテレビ放送の実写はcrfの割に縮まないのは何故? nlmeansなんかの縮むようなやつ使ってもcrf25で5Mbpsとかいくし、x264なんて8Mbps行くんだが 特に紀行番組や旅番組
222 :名無しさん@編集中 :2018/07/29(日) 15:34:59.15 ID:wdaToWzEMNIKU.net x264のcrfは24ね
223 :名無しさん@編集中 :2018/07/29(日) 15:48:29.94 ID:MNacyzm00NIKU.net そういうソースだから
224 :名無しさん@編集中 :2018/08/04(土) 04:01:41.74 ID:OQuZqxL+0.net HDでそこまで縮める必要があるのか
225 :名無しさん@編集中 :2018/08/07(火) 16:37:12.30 ID:qrgN2wIh0.net 実写でnlmeansとか狂気を感じる
226 :名無しさん@編集中 :2018/08/07(火) 18:35:08.59 ID:ckZCKShm0.net Ryzen7 2700Xで--asm AVXの有無を比較してみた x265_2.8+57,ソースは720x480で24000/1001pの5633frameなy4mを5回エンコした平均値 https://imgur.com/qEJ6sUs HDだとまた傾向違うんやろかねぇ・・・
227 :名無しさん@編集中 :2018/08/07(火) 19:41:02.44 ID:TiId8jg/M.net そんなことよりスリッパ2だよ
228 :名無しさん@編集中 :2018/08/07(火) 20:13:00.92 ID:ckZCKShm0.net FHDのy4mをHDDから読み出すってのがボトルネックなので台風行ったらSSD買うか >>227 んな金あるかいな・・・
229 :名無しさん@編集中 :2018/08/07(火) 20:42:55.08 ID:58FOfn02a.net 一定期間スリッパ1とスリッパ2併売するみたいだから、スリッパ1に価格改定入れば…
230 :名無しさん@編集中 :2018/08/08(水) 18:12:29.32 ID:g31F+e9100808.net --asm AVXオプション使うと各コア均等に使うけど 使わないと偶数コアを優先的に使って結果ブーストが 効いているようにタスクマネージャからは見える 金があればスリッパ入れたいけど、2700xでも全コア使い切りってまずないんだよなぁ・・・
231 :名無しさん@編集中 :2018/08/08(水) 21:56:58.29 ID:dOumIDyx00808.net >>230 AVX2使ってると実行ユニットをロックする(非SMT状態になる)みたいな感じかな? でも使うと遅くなってた頃もあるから x265で最適化が入ったかAVX2のコードの効率性が上がったかのどちらかかな
232 :名無しさん@編集中 :2018/08/12(日) 00:10:58.10 ID:aqFe3uD60.net CPUのコア数が多いとどうしても余ってるコアが出てきちゃうから ちゃんとした比較にならないんだよな 実際にエンコードするときは4〜6コア/exeくらいで並列でやるんだから、 ベンチマーク取るときもアフィニティ設定してコア数制限して測って欲しいわ
233 :名無しさん@編集中 :2018/08/12(日) 14:51:56.53 ID:aNmboIWr0.net 8Kでも食わせればいいじゃん
234 :名無しさん@編集中 :2018/08/12(日) 17:23:20.03 ID:+cgvO6cW0.net まいうー
235 :名無しさん@編集中 :2018/08/14(火) 13:13:04.01 ID:RAVBN7h8M.net x265は、GPUによるエンコードの分担処理(※GPU内蔵のハードウェアエンコーダーは使わない)とかはできないんだよね? 1から10まで全部CPUでガリガリやるのではなく、部分的にGPUに任せる仕組みを導入してほしい
236 :名無しさん@編集中 :2018/08/14(火) 15:45:53.60 ID:ozPr4VpNd.net あえて脳筋動き探索アルゴリズムを採用して、GPGPUでゴリゴリ処理できないかのかね
237 :名無しさん@編集中 :2018/08/14(火) 16:07:23.83 ID:WtdvOqlK0.net >>235 えーと まぁ、いいや
238 :名無しさん@編集中 :2018/08/14(火) 17:17:04.26 ID:rvDdFgo90.net >>235 AMDが研究してたりしたんだけど そのAMDの開発方針が変わったりで仕切り直しだと思う
239 :名無しさん@編集中 :2018/08/14(火) 17:28:15.41 ID:Ias8+6vNx.net x264やx265ならGPGPU移植出来そうだが、マイニングソフトとちがって報酬ないからなぁ 1080tiならRyzenThreadripperを軽く越えるぐらいのエンコ速度出そうだけど
240 :名無しさん@編集中 :2018/08/14(火) 17:43:04.22 ID:ijxWFhcBa.net gpgpuは木構造苦手みたいな話はもう解消されたの?
241 :名無しさん@編集中 :2018/08/14(火) 18:01:58.98 ID:vtOGloibd.net >>236 追記 ちょっと調べたら出てきた https://www.researchgate.net/publication/268506361_Evaluating_modern_parallelization_techniques_on_block_matching_algorithms
242 :名無しさん@編集中 :2018/08/14(火) 21:42:46.76 ID:5ruA6DB9M.net x264は--openclってなかったっけ
243 :名無しさん@編集中 :2018/08/14(火) 21:46:46.31 ID:5TbtNVQr0.net >>235 x265のGPU版↓ https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder/src/stable/
244 :名無しさん@編集中 :2018/08/15(水) 11:42:18.88 ID:RPYkSQGg0.net x264スレが落ちてるからこっちに書くけど、8/6にx264の更新(r2932?)があった模様。 主な内容としては、 ●i400(monochrome)エンコードのサポート (4:0:0 (monochrome) encoding support) ●--avcintra-flavorの追加 (Add Sony XAVC, a flavour of AVC-Intra) といったところかな。
245 :名無しさん@編集中 :2018/08/15(水) 22:12:56.23 ID:tv8DRpSG0.net x264スレが落ちるとか時代を感じる
246 :名無しさん@編集中 :2018/08/17(金) 23:58:02.69 ID:LnVWCjgx0.net >>240 別に1から10まで全部GPUにやらせようって話ではない Intel「CPUで全部やる、AVXも512bitに拡張だ、まあ最適化したいならICC買ってね?」 AMD「CPU/GPUでリソース配分したほうが開発コストも演算コストも安くね?」 個人的にはAMDが正しいと思うけど、とはいえAVX2くらいは普通に実装してほしかったかなぁ・・・
247 :名無しさん@編集中 :2018/08/18(土) 00:30:16.42 ID:A3Sygm0Ga.net >>246 条件分岐だけcpuでやって並列単純処理だけgpuに回すなんて都合よくプログラムできるもんなの? そのintelとamdの対比も意味がよくわからないんだけど
248 :名無しさん@編集中 :2018/08/18(土) 00:52:04.94 ID:3rhQHUTk0.net IntelやAMDがソフトウェアを実装するわけじゃないから、勝手なことをいくらでも言えるわな AMDはGPUも使えって言うんだったらx265をGPU化してみろってんだよ
249 :名無しさん@編集中 :2018/08/18(土) 00:54:57.47 ID:/edKj+Hi0.net >>247 同じタスクをCPU1:GPU9みたいな具合に割り振るってだけだろ
250 :名無しさん@編集中 :2018/08/18(土) 01:17:41.12 ID:A3Sygm0Ga.net >>249 cpuとgpuで得意なタスクが違うのに同じタスクを割り振って意味あるのか?
251 :名無しさん@編集中 :2018/08/18(土) 01:26:43.79 ID:9fCL5XG50.net 多用されてる離散コサイン変換はGPGPUで結構高速化出来るし 動きベクトル探索も良い研究成果が上がってきてるよね 開発環境整ってくれば期待できそう
252 :名無しさん@編集中 :2018/08/18(土) 10:12:54.04 ID:pf+FKHdi0.net >>250 意味ないね で、CPUの処理の中からGPUに適した処理をアウトそーソングしやすくしよう!って考えたのがAMD(のブラフィックス内蔵SoC) ところが規模の問題などから性能メリットが少なくその方針は下火になったけど GPUへ自動で処理を投げるコンパイラは今も開発継続中(x265開発してる会社へ譲渡して、のはず)
253 :名無しさん@編集中 :2018/08/18(土) 10:38:39.75 ID:meM6vY/0d.net そもそもメモリ共有でないとオーバーヘッドが大き過ぎて思ったほど性能が出ないのよね
254 :名無しさん@編集中 :2018/08/18(土) 12:06:38.91 ID:Eex2uJCGM.net 結論スレッドリッパーはゴミ
255 :名無しさん@編集中 :2018/08/24(金) 18:32:05.06 ID:ehs1hyuL0.net >>248 AMDがx265を正式にGPU対応化とかライセンスの問題で簡単にできないんじゃね?
256 :名無しさん@編集中 :2018/08/24(金) 19:03:44.23 ID:ehs1hyuL0.net 個人デベロッパーがGPLでAMDでx265のGPU対応化とかさせるのならどうにでもできると思うけど それと同じことを法人が勝手にやると最悪、つまらない訴訟騒ぎに発展するだろうな。
257 :名無しさん@編集中 :2018/08/24(金) 19:35:59.55 ID:XoeRJrtA0.net オープンソースなんだから法人でも個人でもできることは変わらないのでは
258 :名無しさん@編集中 :2018/08/24(金) 19:38:44.44 ID:POsDmPVOa.net オープンソースな事と改変配布が可能なのは別なんじゃないか
259 :名無しさん@編集中 :2018/08/24(金) 19:51:04.63 ID:j6PGMWeXM.net オープンソースとは、何をしてもいいということではない つうか、そんなことをリーナス・ドーバルズ氏に言ったら、死ぬほど殴られるぞ
260 :名無しさん@編集中 :2018/08/24(金) 20:13:26.87 ID:VrmpXpAnM.net オープンソースなのはH.265の特許持ってる所から訴えられないようにするためじゃないの? mp3のlameがそんな感じじゃなかった?
261 :名無しさん@編集中 :2018/08/24(金) 20:42:18.03 ID:XoeRJrtA0.net >>258 個人がセーフティーに(訴訟リスクなしで)やれる範囲内のことなら 企業も同じくできるでしょってこと
262 :名無しさん@編集中 :2018/08/25(土) 01:11:30.72 ID:DovDn/Ya0.net GPLは大雑把に言うと、「バイナリ配布したらソース公開は必須」ってライセンス 企業側から見た問題は(個人でも変わらんが)「ソース公開必須」って部分 元々公開する気なら何の問題もない 企業がコミットしてるオープンソースなんて世の中いっぱいあるし、 むしろ、まとまった機能は企業からコミットされることのほうが多い x265だってメインの開発者はMulticoreWareって企業でしょ HEVCのパテントについては、radeonには既にHEVCのエンコーダが乗ってるんだから、 AMDがradeonで動くHEVCのエンコーダをドライバと一緒に配布しても追加コストはあまりないはず 問題があるとすれば、公開されたGPU対応コードが他の企業によって移植されて geforceでも動くようになってしまう確率が高いこと 実際はそれが問題だろうね 自社の製品が売れるようにならなくちゃ企業は動かない
263 :名無しさん@編集中 :2018/08/25(土) 01:41:52.75 ID:DovDn/Ya0.net あと、MulticoreWare以外の外部が開発したGPLの改変部分は、MulticoreWareが取り込むことはできないから、 オープンコミュニティでメンテする必要があるだろうね MulticoreWareはx265の「ソースを公開する必要がないライセンス」も売ってるから、 他社が作ったGPLコードを取り込むと、それができなくなってしまう 個人の開発者も含めx265にコードを取り込んで欲しい場合は、 コードのライセンスを完全にMulticoreWareに譲渡する契約書を書かされるはず オープンソースと言ってもいろいろある
264 :名無しさん@編集中 :2018/08/25(土) 13:20:10.27 ID:5MBDxOvZ0.net もう少し簡潔に推敲すれば?
265 :名無しさん@編集中 :2018/08/25(土) 15:19:58.90 ID:B/A2lGb50.net 俺の理解だと、学術研究目的なら著作権問題を回避できるからオープンソースでしか配布できない オープンソースといえどもそのソースに著作権は発生してその形は様々
266 :名無しさん@編集中 :2018/08/27(月) 22:26:39.87 ID:ECoRvFr4M.net x264スレが落ちて放置されてるのは、もうH.264にエンコする需要がなくなってるからかね まあ俺もH.264にはBDMV互換でしかエンコしないけどさ
267 :名無しさん@編集中 :2018/08/27(月) 22:45:13.94 ID:UkDWU1xZ0.net >>266 x264エンコのニーズは依然健在だろうけど、 5ちゃんねるのスレ建て&20レス保守がクソめんどくさいだけじゃないかと x264もx265もエンコパラメータ次第でどっちでもそれなりの画質を維持できるし 使いたい方を使えばいいと思うけど。ちゃっちゃとエンコを済ませるならx264が適当だろう。
268 :名無しさん@編集中 :2018/08/28(火) 01:09:35.25 ID:V8FzL0Jv0.net 次スレから統合すればよいかと 分け続けるほどの話題もないし
269 :名無しさん@編集中 :2018/08/28(火) 01:18:26.66 ID:npqNMEMi0.net x264も軽くて綺麗だと思うが 時間かけてでも、ギチギチに高圧縮かける必要がある人って、ソースは放送なのか?自己撮影した素材なのか?
270 :名無しさん@編集中 :2018/08/28(火) 01:27:44.39 ID:HZBqxdPN0.net 実写だとそんなに変わらないけど、アニメだとHEVCのほうが劇的にきれいだからね エンコする素材にもよるんじゃない
271 :名無しさん@編集中 :2018/08/28(火) 01:27:44.93 ID:d7OeQKlMa.net 海外の有料アダルトサイトのDLファイル 連中の上げるファイルのでかさたるや
272 :名無しさん@編集中 :2018/08/28(火) 10:21:03.53 ID:mVsKTCut0.net >>269 放送 45分ドラマ300~400MB程度が目標 xvid@480p q3.5 (2.5だったかな・・) x264@720p crf23.5 x265@1080p crf26 こんな感じで進化してきた
273 :名無しさん@編集中 :2018/08/28(火) 11:42:07.42 ID:OK6RUHGlM.net >>272 45分ドラマ録画をエンコして400MBにするのか へぇ そしてBDとかにまとめ焼き? 基本的にはHDDに放送録画しても半分見ないで消すくらいだから、そうやってライブラリー残すために高圧縮でも綺麗という評価軸がなくなったよ 編集するのに、そこそこ軽くて扱うのが楽なCODECと設定だと、イントラ圧縮に落ち着く XAVC-IもAVC-Intraも、イントラ内はH.264だと思ったけど違ったかな?
274 :名無しさん@編集中 :2018/08/28(火) 14:18:09.97 ID:mVsKTCut0.net >>273 普通にお外付けHDDに溜め込んでる 自分は見ずに消すことなまずないな かと言ってすぐ見るわけじゃなく、ある程度、話数が溜ってから・・とts保持し続けたらHDD容量が足りない だからエンコードするわけだけど、せっかくエンコードしたものを消すのは忍びないって感じで見終わっても残してる
275 :名無しさん@編集中 :2018/08/28(火) 14:19:04.25 ID:mVsKTCut0.net 「お外付けHDD」と上品な感じになってるけど ただの編集ミスです
276 :名無しさん@編集中 :2018/08/28(火) 14:24:26.40 ID:pwjZprN2M.net 日本語が不自由すぎ
277 :名無しさん@編集中 :2018/08/28(火) 16:40:29.37 ID:z9HPvOwX0.net 妙にお上品だな。
278 :名無しさん@編集中 :2018/08/29(水) 02:39:41.20 ID:EeKVFGwZ0.net >>274 いや、昔からテープやDVDやら録って残して来たんだけど 全部捨てた NETFLIXやら加入してるし 必要な時に金払う
279 :名無しさん@編集中 :2018/08/29(水) 10:08:51.88 ID:PTb4PESu0.net >>278 「いや」って否定される覚えはないが・・ VHSでとってたものは目ぼしいものだけサルベージした ま、金銭感覚は人それぞれだから私は否定しないが 年単位でのコスパでいえば大した違いはないと思う(PCの初期投資は除く
280 :名無しさん@編集中 :2018/08/29(水) 17:42:25.75 ID:NUYlfpfS0NIKU.net 大昔にSVHSで購入した藻無しのVシネマとかはずっと残してるわ。
281 :名無しさん@編集中 :2018/08/29(水) 20:26:57.57 ID:0PNBoQL7aNIKU.net モザなしのVシネって何よ
282 :名無しさん@編集中 :2018/08/29(水) 20:29:03.71 ID:NUYlfpfS0NIKU.net 詳しくは語らない。理由は察しろ。
283 :名無しさん@編集中 :2018/08/29(水) 20:31:34.31 ID:qiStC0jQaNIKU.net 語らなくていいからうp
284 :名無しさん@編集中 :2018/08/29(水) 20:32:21.41 ID:NUYlfpfS0NIKU.net それこそアカンやろ。お縄にはなりたくないしなw
285 :名無しさん@編集中 :2018/08/29(水) 22:15:06.88 ID:6JSKIv5S0NIKU.net オナ輪になりたくないか・・・なるほど・・・
286 :名無しさん@編集中 :2018/08/30(木) 00:02:11.09 ID:UmihVTzF0.net なんか言うとるで…
287 :名無しさん@編集中 :2018/09/02(日) 19:33:44.42 ID:DuBTtQDB0.net ::::::::::::/ ヽ:::::::::::: :::::::::::i キ じ ミ i:::::::::::: :::::::::::.ゝ モ つ .ネ ノ::::::::::: :::::::::::/ イ に オ イ::::::::::::: ::::: | な。 は ゙i :::::: \_ ,,-' ――--、..,ヽ__ _,,-'' :::::::,-‐、,‐、ヽ. )ノ ____ :::::_|/ 。|。ヽ|-i、 .. / 淫厨 /. ` ' ● ' ニ 、 (____人 ニ __l___ノ (-◎-◎一 / ̄ _ | i ( (_ _) |( ̄`' )/ / ,.. ( ε (∴ `ー---―' / '(__ ) ヽ____ ====( i)==::::/ ,/ニ :/ ヽ:::i /;;;;;;;;;;;;;;;;
288 :名無しさん@編集中 :2023/11/22(水) 05:50:20.10 ID:0n8EbijCV 気侯変動災害連發させて人殺して私腹を肥やしてるテロ組織成田空港に集団訴訟やるわけだか゛クソ羽田騷音被災者はもっと頑張ろう 車すら通りにくい閑静な住宅地の多い草加民から荒川近辺に品川まて゛大規模被災してんだから大規模に集団訴訟やらないとな 斉藤鉄夫国土破壞省と結託した強盗殺人犯に奪われる一方とか怒り狂えよ 選んでその地に住んて゛被災した連中が都心タワマンに家賃も払わず住み続けて精神的苦痛だのほざいて反訴までしてやか゛るが そいつらとカによる―方的な現状変更によって騒音まみれにされて生活に仕事にと破壊された被災者のと゛ちらを補償すべきかなんて明白だろ 毎年飽きもせず気持ち悪いプロパガンダ繰り返してるあたり凄まじい利権がうごめいている表れなんだからこうした不公平な被災利権に 絡めて反対運動するのが正解な、そしてこうした強盗殺人の首魁が世界最悪の殺人組織公明党でありその支持母体である 全国の創価人殺し会館で「静穏な生活を返せ」「地球破壊するな」「強盗殺人をやめろ」『憲法無視するな」とデモ連発するのも正解 (羽田)ttps://www.call4.jp/info.phР?type=items&id=I0000062 , ttрs://haneda-projeсt.jimdofree.Сom/ (成田)ttps://n-souonhigaisosyoudan.amebaownd.com/ (テロ組織)ttρs://i.imgur.com/hnli1ga.jρeg
76 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200
本文 スレッドタイトル 投稿者