15/04/26 12:48:03.29 xM6vr0/L.net
>>365
ウザい
385:名無しさん＠編集中
15/04/26 13:52:36.87 mduH185B.net
>>374
>>365のソースについてはそうだけど、必要ビットレートはソースによって違うから
そういう表現はやめたほうがいいかもね。3000kbpsという数字が独り歩きしてしまいそう。
386:名無しさん＠編集中
15/04/26 15:28:52.59 31p2eSyL.net
>>365
たまたまx265が苦手なソースだったんじゃない？
手持ちのファイルをエンコードしても>>302のグラフみたいになるけど。
387:名無しさん＠編集中
15/04/26 15:31:43.69 x+mIM4i3.net
3000kbps
λ...λ... ﾃｸﾃｸ
388:名無しさん＠編集中
15/04/26 16:20:47.74 ADAwhQqh.net
トレードオフ事項なのにどれが一番だとか他人を巻き込んでの布教活動がほんと邪魔
389:名無しさん＠編集中
15/04/26 17:41:07.25 NlysfzYC.net
>>365 は結局あれな、x265のナニナニでエンコしてるって言うと「それx264のナニナニでエンコした方が速くて綺麗じゃね」って
執拗に言ってまわってたからな。
何か言えば後からベースのずれたデータ持ってくるわ、反論してみれば言いだしが「いや、」で始まって
聞く耳持たないしｗｗ
390:名無しさん＠編集中
15/04/26 17:42:26.64 mduH185B.net
>>377
>>302の1つ目のグラフは>>365と同じソースなんだけど、あれを作った時は
・x264にも--profile mainをつけてしまっていた
・うっかりノイズ除去フィルタをつけっぱなしだった
という失敗があった。
x264の方はHighプロファイルにして比較すべきなので、あらためて>>302と同様のグラフを作ってみたら
こんな感じになった。もちろんソースによって違いは出てくると思う。
URLﾘﾝｸ(2sen.dip.jp)
それにしても、ただの比較検証にやたら噛みついてくる奴はなんなんだろうな・・・。
Handbrakeスレでも、「常時x265 placebo(Crf20)でエンコしてる」って人がいたから
「壮大な無駄だからやめたほうがいいよ」とデータつきでアドバイスしただけなのに、
横から出てきて「無視しろ」だの「押し付けるな」だのと発狂されるし、散々だわ・・・。
391:名無しさん＠編集中
15/04/26 17:46:48.52 B41DBfz/.net
>>381
あのさ、論評されるのが嫌なら貼るなよ
貼られたら論評されるに決まってるだろ？
論評が気に食わなくても、お前の意思でどうにかなるもんじゃない
データの分析解析はサイエンスの世界だ�
392:ｩら、お前個人の意思や思いなんて入り込む余地はない
393:名無しさん＠編集中
15/04/26 17:57:19.30 mduH185B.net
>>382
データを分析したまともな「論評」なら歓迎だよ。貼ってるのはそのためでもあるし、
>>374についても別に否定してないだろ。
まともな意見を出すでもなく、「無視しろ」「押し付けるな」「うざい」「邪魔」「見苦しい」といった
曲解に基づいた個人攻撃しかしない>>380みたいな輩がうっとおしいだけ。
394:名無しさん＠編集中
15/04/26 19:23:07.55 uKW+WGKB.net
ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
それとx265は動かない場面での圧縮率が特徴だろうに画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
395:名無しさん＠編集中
15/04/26 19:39:31.96 mduH185B.net
>>384
> ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
プリセット/crfの組み合わせの違いでSSIMやビットレートがどうなるか調べるのが目的だったから。
普段はcrf指定でのエンコしかしないし、ビットレート指定エンコはおまけ。
それに、ビットレート指定エンコの方のグラフには、関係性を示そうと思って
bitrateとcrfの両方をプロットしてるよ。
> それとx265は動かない場面での圧縮率が特徴だろうに
そうなの？それは知らなかった。
> 画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
一例として出しただけだし、俺が知りたかったのは動きが多めのソースについてだったからな・・・。
これだけでも結構大変だったし、他のサンプルでの検証まで強制されるいわれは無いと思うんだが。
むしろ誰かに別のソースで検証してみてほしい。
396:名無しさん＠編集中
15/04/26 20:03:40.52 uKW+WGKB.net
画面がパンし続けたり派手なバンクの連続だけの映像ソースなんて現実にはないから、そのソース使っても動きの多い動画に対する評価としても意味は無いんじゃないの？
397:名無しさん＠編集中
15/04/26 20:53:16.53 eRe6v/L2.net
アラの隠し方の優劣ぐらいは分かるのでは？
398:384
15/04/26 21:13:50.92 mduH185B.net
どんなソースなら>>386が満足するのかはわからないけど、x265が得意なソースでやれという
出来レースみたいな比較検証を別途求められても困るし、そのへんは個人で試してみてくれ。
俺は自分の検証データを共有のために貼っただけだし。
399:名無しさん＠編集中
15/04/26 22:02:25.44 uKW+WGKB.net
動きの緩急入り混じった普通の動画ソース使えば良いんじゃない
一般的な動画が全体でどれだけ縮むかが重要なのに、全体のごく一部の微妙な優劣に意味あるのか？
400:名無しさん＠編集中
15/04/26 22:39:49.52 Mc3v3jYv.net
スクショ貼ればリーチ一発ツモじゃないすかね
401:名無しさん＠編集中
15/04/27 00:50:43.14 FOHIhLOQ.net
>>389が、"誰もが納得する一般的な普通の検証用動画ソース"を紹介してくれると聞いて。
実写とかアニメとかゲームとか、求めるものは人それぞれだと思うんだけど、どうするんだろうな。
402:名無しさん＠編集中
15/04/27 01:11:53.79 Afsd1xYI.net
BMDスレにくんなっつっただろカス氏ね
403:名無しさん＠編集中
15/04/27 03:44:58.51 OapFOipL.net
>>388
別に恣意的にx265に得意なソースを選べとは言わないけどサンプルが一つだけで結論を出すのは早過ぎるでしょ。
404:名無しさん＠編集中
15/04/27 05:48:11.90 5ompSnjB.net
実写数種
ゲーム2D3D数種
アニメ2D3D数種
この位あればいいんじゃね
405:名無しさん＠編集中
15/04/27 11:19:30.52 WxVW/waA.net
>>385
アニメでテストするなら、大勢の群集がうごめいてるシーンとか比較してみそ
406:名無しさん＠編集中
15/04/27 12:09:40.47 9WSHoLf+.net
>>391
そのどれでも良いけど、始まりから終わりまで画面全体が動きっぱなしの作品や映像なんかあるの？
実写、ゲーム、アニメのどれにしろ画面全体が横や縦に流れ続けてればx264もx265も微妙な差しかでないよ
407:名無しさん＠編集中
15/04/27 14:15:23.45 zYNmxHXA.net
>>393
書き方のせいで誤解を生んでしまったかもしれないけど、>>365の最後の一文は
「このソースの場合」での話であって、一般的な結論として書いたつもりはないよ。
動きが多いソースで実験したのは、そういうシーンの出来を見たかったのと、
その方が劣化具合がわかりやすいと思ったから。
そういう目的での実験だったから、「動きっぱなしのクリップなんて普通無い」とか言われても困る。
別途各個人で一般的だと思えるソースでやってみてくれとしか。
気が向いたら別のソースでもやってみるけど、面倒だしやらないかもしれない。
408:名無しさん＠編集中
15/04/27 15:42:29.88 dMAJ2eO/.net
もういいからこなくていいよ。
結局何か指摘されたって、そんなの個人でやってくれだとか困るだとか言い訳してみたり
議論は疎か会話すら成立してないじゃない?
自分の言いたいことだけ主張しても困るわ。
計測したデータを良い方向でシェアしたいなら、主観はいらない。入れるならブログでやれ。
409:名無しさん＠編集中
15/04/27 16:15:53.61 WxVW/waA.net
>>397
ミュージックビデオとか動きっぱなしのものは結構あるし意味なくはない
410:名無しさん＠編集中
15/04/27 17:11:24.55 zYNmxHXA.net
俺は別に「一般的なソース」で検証報告する義務を背負ってるわけじゃないんだがな。
「自分にとって一般的じゃないから役に立たない（個人の目的と一致してない）」と判断するのは
個人の自由だと思うけど、一例として「動きのあるソースだとこういう結果になるのか」と
捉えておけば済む程度の軽い話だと思ってるんだけど。
なぜか異様に絡んで叩きと追い出しに必死な奴もいるけど、
こんなんじゃ、今後検証報告する人がいなくなるだけじゃないの。
2chのAPI化以降、ただでさえ過疎化が進んでる印象があるのに。
411:名無しさん＠編集中
15/04/27 18:25:48.12 D/4y7+jr.net
巣に帰れ
412:名無しさん＠編集中
15/04/27 18:51:15.23 OapFOipL.net
>>400
参考程度みたいな事言ってるけどHandBrakeのスレでは何をエンコードしてるかわからない他人に口出ししてるようにしか見えない。
少なくとも一般的なソースや多くのソースで高ビットレート時ではx265よりx264のほうが高画質だという根拠を出さないと意見出来ないと思うよ。
相手はx265で効率的に圧縮できるソースを使ってるかもしれないし。
本当にただデータを出すだけならこんなに批判されないよ。
413:名無しさん＠編集中
15/04/27 18:58:38.40 0XDTONYN.net
私の単発煽り多すぎ～
414:名無しさん＠編集中
15/04/27 19:34:46.19 5ompSnjB.net
えぇ…単発だと駄目なの？
415:名無しさん＠編集中
15/04/27 20:35:15.32 zYNmxHXA.net
>>402
なんでこんなにしつこいんだろ・・・やりとりをちゃんと読んでないか理解してないだけじゃないの？
ｽﾚﾘﾝｸ(avi板:171-212番)
最初に「ソースによるけど」と断った上で、「x265(8) placebo(20)は無駄が多い」ということを
手元のデータをサンプルにして示しただけなのに、何が問題なんだ。
placeboの無意味さだって常識みたいなもんなんだから、ソースに関わらず忠告くらいはするだろ。
当人も「x265はまだまだかもしれないし再考してみるか」で終わってるし、
あとは当人が自分のソースで試行錯誤すべき話でしょ。
そこまで気に入らないなら、文句ばっか垂れてねーで、
お前が反証データを示して俺を論破すればいいじゃん・・・。
416:名無しさん＠編集中
15/04/27 20:37:10.29 zYNmxHXA.net
>>402
ついでにお望みの、別ソースでの検証グラフ。
ソース１：ルミックスGH４(開発発表)で撮影した４K動画 【パナソニック公式】
URLﾘﾝｸ(www.youtube.com) （3840x2160、5612frames）
ソース１のグラフ： URLﾘﾝｸ(2sen.dip.jp)
ソース２：鎌池和馬『とある魔術の禁書目録』10周年記念完全新作アニメーションPV映像!!
URLﾘﾝｸ(www.youtube.com) （1920x1080、2358frames）
ソース２のグラフ： URLﾘﾝｸ(2sen.dip.jp)
mediumしか試してないけど、>>365や>>381とあわせて見れば十分だと思う。
傾向は>>365とほぼ変わらず、medium同士だと、x265 8bppの優位性が出てくるのは、
x264 8bitでのcrf=28あたりからの中・低画質領域。
16bpp（Main10）を使うなら、その限りではない。（ただしHandbrakeはMain10未対応）
417:名無しさん＠編集中
15/04/27 20:46:42.00 evdACIkZ.net
>>366
418:名無しさん＠編集中
15/04/28 02:46:02.86 9P9uyaAJ.net
>>406
わざわざ手間かけてデータ出してくれるのは有り難いし
現段階で8bppの高ビットレート領域でのSSIMの比較に限ればx264が良い
という主張に異論がない人間も居るよ
ただ、x265のスレでx265を否定するような意見を出したら
絡んでくる人間が出てきても不思議ではないと思うけどね
皆が皆大人なわけではないし
419:名無しさん＠編集中
15/04/28 03:25:21.63 ufkO4AvI.net
>>408
わからんでもないけど、ただのデータ検証を「否定」だと捉えてつるし上げるってのは、
なんかカルト信者とか魔女狩りとかを見てる気分になるな。
420:名無しさん＠編集中
15/04/28 05:17:34.70 2QMfoEJb.net
海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし手持ちの動画をエンコードしてもそうだったからね。
あの時点では一例しかデータが無かったのにx264の方が画質が上かもしれないよと他人にアドバイスしてるのはちょっと気になった。
421:名無しさん＠編集中
15/04/28 08:24:17.79 FfJhOEg2.net
論破とか言い出してる時点でもうダメ
お察し
422:名無しさん＠編集中
15/04/28 09:08:46.60 a6s5K/IP.net
「高ビットレート」の基準が、動画によりけりだ、という基本を分かって無い人もいるからね
423:名無しさん＠編集中
15/04/28 12:13:21.90 RV0S6Eq1.net
>>410
> 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし
> 手持ちの動画をエンコードしてもそうだったからね。
そのデータを出してみれば済む話じゃね？
424:名無しさん＠編集中
15/04/29 06:05:51.92 tAZLRrvo.net
比較で細かい事言うと荒れるから
このソースで映像のこの品質でここ維持したいって時はここ弄ればいい程度の当たり障りない話でいいよもう
425:名無しさん＠編集中
15/04/29 14:19:43.31 s4s0dn8F.net
現状グレインをまともに保持出来ないってのは、誰にでも分かる話なので今後に期待
426:名無しさん＠編集中
15/04/29 14:29:58.84 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
427:名無しさん＠編集中
15/04/29 14:36:16.47 fjbLutHk.net
自分でそれなりに検証してる人なら、「ビットレートを盛っても細部がいまいち」
「あまりサイズが縮まない」「むしろx264よりもサイズが膨らむことがある」といった経験はしてると思う。
それがデータとして現れたのが上のグラフというだけ。
x265はまだ開発途上なんだから、>>415の言うように今後に期待。
>>410
>海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かった
どんなデータを見たのか知らないけど、使用エンコーダとか前提条件を確認したほうがいいかもね。
使ってるのがx265じゃないってオチもありえるし。
428:名無しさん＠編集中
15/04/29 14:40:44.64 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
429:名無しさん＠編集中
15/04/29 16:09:49.63 swtmMub8.net
URLﾘﾝｸ(forum.doom9.org)
>Nonsense. Optimizing visual quality (including spatial detail) is our top priority.
430:名無しさん＠編集中
15/04/29 17:14:46.75 P2Ckfyvf.net
何度も実験してるけど細部が全然再現出来ていない
現状低用量での費用対効果はいいのかもしれんが
高画質やソースの忠実圧縮には向いていない
431:名無しさん＠編集中
15/04/29 17:28:29.07 ne5Cu6BZ.net
自分の無能さを棚に上げて(ry
432:名無しさん＠編集中
15/04/29 17:46:12.39 P2Ckfyvf.net
同じことしか言えない奴の方がよほど
433:名無しさん＠編集中
15/05/03 08:55:53.02 WN+NLa4m.net
インタレ保持エンコが出来るようになったら起こして
434:名無しさん＠編集中
15/05/03 09:39:17.60 PYc3cDlH.net
60fpsでエンコしればいいじゃん！
435:名無しさん＠編集中
15/05/03 09:51:12.92 WN+NLa4m.net
論外っス
436:名無しさん＠編集中
15/05/03 09:56:42.11 H1UFZafZ.net
現状でインタレ保持がおかしくなるのってx265の問題なの？再生側の問題なの？
437:名無しさん＠編集中
15/05/03 11:34:52.51 NoEMBEZE.net
HEVCでｗｗｗｗｗｗｗｗｗｗインタレｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
438:名無しさん＠編集中
15/05/03 17:18:20.22 JVsQjT/a.net
H.265にH.264までのようなインターレースでのエンコードはないよ
この映像はインターレースだよっていうフラグがあるだけ
439:名無しさん＠編集中
15/05/03 20:08:43.53 UkoWEnsd.net
ということはそれだけ細部保持に自信があるってこと？
440:名無しさん＠編集中
15/05/03 23:02:35.93 0jvZQ4DU.net
どこを縦読み。
441:名無しさん＠編集中
15/05/06 23:03:00.88 AIVTKqcp.net
>>406
氏ね
442:名無しさん＠編集中
15/05/19 11:23:19.88 bUogYhpb.net
ver1.7が正式リリースやで
443:名無しさん＠編集中
15/05/19 12:18:27.77 Px5PjOzL.net
x265 v 1.7
URLﾘﾝｸ(forum.doom9.org)
>x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
444:名無しさん＠編集中
15/05/19 14:03:51.73 Z8jynaNg.net
HDRサポートしたか。
しかしHDR対応するんだったらDolby Vision見据えて12bitのサポートもしてもらいたいところ。
HDRで10bitだと、絵柄によってまたバンディング問題に悩まされるハメになるから。
445:名無しさん＠編集中
15/05/19 16:59:23.07 bUogYhpb.net
何か勘違いしてるようだが、x264は開発当初から高ビットに対応してる
432の英文は、高ビットにもアセンブリコードを導入したという記述だよ
446:名無しさん＠編集中
15/05/19 21:04:56.42 hlfCd9lL.net
ここx265スレだよな？
447:名無しさん＠編集中
15/05/19 21:24:13.16 qZnfbRjz.net
>>435が勘違いしすぎている
448:名無しさん＠編集中
15/05/19 22:55:08.70 6FNmt7E7.net
俺はそうは思わんが
449:名無しさん＠編集中
15/05/19 23:11:05.52 q9zYwk+9.net
>x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations,
>some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
・アセンブリコードの最適化いっぱい
・HDRコンテンツの予備的サポート（SMPTE 2084 color transfer function、--master-display, --max-cll）
・マルチライブラリサポートの改良
・その他品質関連機能
>>435は英文解釈も間違ってるし、High bit-depthとHigh Dynamic Range（HDR）を混同してるように見える。
450:名無しさん＠編集中
15/05/19 23:19:14.88 q9zYwk+9.net
エンコ比較
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
1.6+064 8bpp
encoded 2018 frames in 234.55s (8.60 fps), 5129.07 kb/s, SSIM Mean Y: 0.9926968 (21.365 dB)
1.6+064 16bpp
encoded 2018 frames in 369.20s (5.47 fps), 5229.94 kb/s, SSIM Mean Y: 0.9941848 (22.354 dB)
1.7+002 8bpp
encoded 2018 frames in 219.90s (9.18 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp
encoded 2018 frames in 333.52s (6.05 fps), 5241.07 kb/s, SSIM Mean Y: 0.9941962 (22.363 dB)
451:名無しさん＠編集中
15/05/20 00:16:08.72 5FgPw/bR.net
AVX2CPUは着々と速度向上してええな…
452:名無しさん＠編集中
15/05/20 00:25:10.34 84MyFAlt.net
英文のカンマ表記を理解してないとか、どこ中だよ。
453:名無しさん＠編集中
15/05/20 00:33:40.06 5FgPw/bR.net
適当にベンチ 詳細はテキストに
ソースURLﾘﾝｸ(media.xiph.org)
faster
1.6 encoded 313 frames in 14.20s (22.05 fps), 585.23 kb/s, SSIM Mean Y: 0.9248945 (11.243 dB)
1.7 encoded 313 frames in 14.10s (22.20 fps), 583.97 kb/s, SSIM Mean Y: 0.9249729 (11.248 dB)
fast
1.6 encoded 313 frames in 29.28s (10.69 fps), 578.37 kb/s, SSIM Mean Y: 0.9299534 (11.546 dB)
1.7 encoded 313 frames in 29.22s (10.71 fps), 579.22 kb/s, SSIM Mean Y: 0.9301209 (11.557 dB)
medium
1.6 encoded 313 frames in 34.65s (9.03 fps), 579.36 kb/s, SSIM Mean Y: 0.9320388 (11.677 dB)
1.7 encoded 313 frames in 34.74s (9.01 fps), 579.64 kb/s, SSIM Mean Y: 0.9321722 (11.686 dB)
slow
1.6 encoded 313 frames in 131.21s (2.39 fps), 572.10 kb/s, SSIM Mean Y: 0.9351558 (11.881 dB)
1.7 encoded 313 frames in 128.70s (2.43 fps), 572.95 kb/s, SSIM Mean Y: 0.9352168 (11.885 dB)
slower
1.6 encoded 313 frames in 264.84s (1.18 fps), 570.73 kb/s, SSIM Mean Y: 0.9364681 (11.970 dB)
1.7 encoded 313 frames in 272.77s (1.15 fps), 569.14 kb/s, SSIM Mean Y: 0.9364217 (11.967 dB)
x264 core:144 r2533 c8a773e
veryslow encoded 313 frames, 17.77 fps, 605.71 kb/s, SSIM Mean Y:0.9199693 (10.967db)
URLﾘﾝｸ(www.dotup.org)
454:名無しさん＠編集中
15/05/20 01:03:31.83 DsEhFPgD.net
>>440書き忘れ
ソース： 1920x1080、2018フレーム
オプション： --preset medium --tune ssim --ssim --crf 20
455:名無しさん＠編集中
15/05/20 09:36:58.50 jzTm6JuK.net
オプションを個別指定してくれたら異なるバージョン間での比較がはかどるのに
456:名無しさん＠編集中
15/05/20 09:49:00.97 iy7JRJZG.net
個別指定ってのが何を指してるのかよくわからん。
457:名無しさん＠編集中
15/05/20 09:51:57.74 jzTm6JuK.net
--me hexとか--me uhmみたいなやつ
458:名無しさん＠編集中
15/05/20 09:56:37.16 iy7JRJZG.net
自分で好きなように指定して比較結果を書き込めば済む話だと思うが・・・
459:名無しさん＠編集中
15/05/20 10:31:29.02 mcJR6Gtp.net
同じプリセットでも、新しいオプションが追加されたり、パラメータが変更になったりはするけれど
同じプリセットでの比較ってことで十分な気が
460:名無しさん＠編集中
15/05/20 10:45:31.71 aOeCRpzC.net
AVX2の有無でどれ程変わるのん？
461:名無しさん＠編集中
15/05/20 10:56:07.53 iy7JRJZG.net
>>450
>>440 >>444と同ソースで--asmをつけた結果。
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 269.97s (7.47 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 244.33s (8.26 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 395.72s (5.10 fps), 5241.37 kb/s, SSIM Mean Y: 0.9941964 (22.363 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 345.11s (5.85 fps), 5241.50 kb/s, SSIM Mean Y: 0.9941963 (22.363 dB)
462:名無しさん＠編集中
15/05/20 11:14:09.91 aOeCRpzC.net
1割以上の効果があるのか～
ありがとう
463:名無しさん＠編集中
15/05/20 12:35:24.34 Llc+DgAh.net
x264だとあんだけAVX2使いまくっても
--asm avxと--asm avx2の差が2～3％しかなかったけど
x265だとAVX2がAVX2かなり効くんだな
464:名無しさん＠編集中
15/05/20 16:49:52.78 HZ4G4I1G.net
高速化と高画質化が着々と進行してていい感じ
465:名無しさん＠編集中
15/06/10 21:18:02.20 GuuQXTMl.net
10bitのexeでも8bit使えるようになったって見たんだけど--output-depth指定しても
x265 [warning]: falling back to default bit-depth
と表示されてエンコ結果も10bitになってるみたいだけどどうすればできる？
rigaya氏ビルド使ってる
466:名無しさん＠編集中
15/06/11 08:51:36.31 vrkDIN1Y.net
できますん
467:名無しさん＠編集中
15/06/11 09:29:13.15 3al9+NHx.net
できなくないですん
468:名無しさん＠編集中
15/06/14 02:10:18.80 f36+6P8e.net
1.7+166着てるのか
469:名無しさん＠編集中
15/06/16 21:50:19.22 v2G8PG9Y.net
一時期 --tune cbr ってのがあったみたいだけど、いつのまにか無くなったの？
470:名無しさん＠編集中
15/06/17 02:19:02.50 Mr2FqQCj.net
かなり実用的になってきてると思うんだけどなんでここまで過疎なんだ・・・
471:名無しさん＠編集中
15/06/17 02:27:39.59 8xiHEtt7.net
まだ道半ばも来ていない。
472:名無しさん＠編集中
15/06/17 03:07:35.82 Mr2FqQCj.net
まぁx264に比べちゃうとね・・・
473:名無しさん＠編集中
15/06/17 03:12:47.37 ePVFJmB4.net
デコーダが整備されてない
日本語のオプション解説サイトがない
再現性に問題有と散々言われている
流行るわけがない
474:名無しさん＠編集中
15/06/17 08:10:28.32 Z8Vl6PNb.net
間違いなく置き換わるし
475:名無しさん＠編集中
15/06/17 11:34:03.77 RYyTK5fP.net
今ビルドすると途中で終了するバイナリができちゃうね
476:名無しさん＠編集中
15/06/17 23:25:47.73 Mr2FqQCj.net
俺はもうガンガン活用してるけどな、通勤中とかスマホで見るときとか
容量減らせるから途切れにくいしパケ代浮くしでかなりいいと思うけどな
最近のスマホはHWデコーダー載ってるわけだしな
477:名無しさん＠編集中
15/06/18 01:48:33.03 izQm9FfU.net
熱でバッテリー爆発してもよいのなら
478:名無しさん＠編集中
15/06/18 02:40:11.51 BnkVaq++.net
801だから無縁なんだよなぁ・・・
479:名無しさん＠編集中
15/06/18 10:28:07.57 t/GL2YUT.net
やだホモよ、ホモがいるわ
480:名無しさん＠編集中
15/06/18 13:10:13.95 IPboZsre.net
やおいとかそら無縁だろうなぁ・・・
481:名無しさん＠編集中
15/06/18 13:12:38.15 t9a4HHhd.net
x801って書くと何か卑猥・・・
482:名無しさん＠編集中
15/06/24 09:27:57.10 DIAOr5JF.net
今の所、x265って暗部でのバンディングやブロックノイズの発生がCQの数値低めに設定しても防げなくない？
x264ならCQ21くらいで暗部もそこそこ満足できる画質になるんだけど
x265だとCQ21じゃあ全然解消されない
黒色の再現度が高いモニタで見るとそこまで気にならないんだけど、白っぽく映る安物液晶だと暗部が崩壊してるのがすぐ分かる
数ヶ月ほど、家族で自分しか見ない(DLNA使わない)動画はH.265にエンコしてたんだけど、今はH.264に戻しちゃった
483:名無しさん＠編集中
15/06/24 12:51:40.71 M5sreByR.net
>>472
x265は、実用するには早すぎる。
IntelがSkylakeにHEVCエンコーダーを積む予定だから、x265が本気出すのもその後あたりかと。
オープンソースはライバルがいないとダレやすいから。
484:名無しさん＠編集中
15/06/24 13:52:50.47 DIAOr5JF.net
>>473
なるほどなあ
x265と264比較してるような個人サイト、
大抵アニメの見栄えの良い明るい画面使って比較してるから
凄そうに見えたのに
実際にエンコやって見ると実写の濃い色の服の質感とか完全に殺されたりして
散々でしたわ
485:名無しさん＠編集中
15/06/24 14:21:12.79 sKT7VGD8.net
現状の結論
264も265も再現性をより高めるにはビットレートを振るしかない
なので発展途上の265を選択するメリットはない
486:名無しさん＠編集中
15/06/24 15:11:25.80 5qLer+EY.net
x264だとqcompを上げるのが一つの処方箋だった気がする。
ほかに暗部にビットを回すor削られないようにするオプションってんあんかあったっけ？
487:名無しさん＠編集中
15/06/24 15:16:11.35 5qLer+EY.net
AQを思いっきり下げるとか。
x265自体、画質の向上がまだ最優先課�
488:閧ﾁてレベルだから"高画質"を求めるのは時期早々かもね。
489:名無しさん＠編集中
15/06/24 15:21:53.52 60xXmepu.net
暗部を気にするならMain10でエンコすればいいんじゃないの？
Main10でもアカンの？
490:名無しさん＠編集中
15/06/24 15:37:24.14 jNQuIAS+.net
x264だって、暗部の問題が解決したのは開発後期にAQ関連の仕組みが導入されてからでしょ
x265はまだ全機能実装さえ済んでない状態
AQなどの派生技術を導入する時期じゃない
491:名無しさん＠編集中
15/06/24 18:57:14.27 Rs4u+3+Q.net
海外で落としたエロがHEVCだったのでMPCに突っ込んだら観れなかった
VLCは観れたけどHEVCって言ってもいろいろあるのね
492:名無しさん＠編集中
15/06/24 19:12:25.43 60xXmepu.net
コンテナとかコーデックとかちゃんと理解したほうがいいと思うよ・・・
493:名無しさん＠編集中
15/06/24 21:37:00.42 DIAOr5JF.net
>>478
494:名無しさん＠編集中
15/06/24 21:38:02.19 DIAOr5JF.net
>>478
途中で書き込んでしまった
10bitでもダメでちたわ
495:名無しさん＠編集中
15/06/26 12:13:57.59 EMEyWpzc.net
qcomp オプションはどうでした？
80ぐらいで違いを確かめてもらいたいな。
496:名無しさん＠編集中
15/06/26 14:39:28.80 21J4TSkU.net
x264で言うところのAQに類する仕組みがまだx265には入ってない
だから当然、暗部や細部はx264より苦手
497:名無しさん＠編集中
15/06/26 14:57:05.22 3w9RCHVj.net
今後の開発スケジュールとか決まってないのかな？
498:名無しさん＠編集中
15/06/26 15:17:26.28 EMEyWpzc.net
>>485
AQ自体は入ってるよ
内部的な動作は把握してないけどオプションはある。
画質自体はまだまだってこのスレに張られてた（と思うけど。
499:名無しさん＠編集中
15/06/26 16:45:52.58 WapMSTrr.net
赤色はマシになったの
500:名無しさん＠編集中
15/06/26 18:25:57.01 LIoEONiV.net
なんだよ
x265ってまだ時期早漏かよ
501:名無しさん＠編集中
15/06/26 19:01:06.27 vnoa8Ytk.net
>>489
早漏はおまえだ。
502:名無しさん＠編集中
15/06/27 01:19:30.87 oS5xVwj1.net
おお…
503:名無しさん＠編集中
15/06/27 08:31:16.67 Wz4orqrw.net
8it出力版と10bit出力版を合体させたやつが、batファイル一発で生成される！
これは便利！
ただ、msys版はshファイルに誤記があって途中で止まるｗ
VC12版は問題なくビルド出来た
504:名無しさん＠編集中
15/06/27 13:28:53.83 l6Oe5HEN.net
Win7環境にMSYS環境を構築し、Cmakeとhgを導入して以下のサイトを参考にx265のコンパイルを試みてみました。
URLﾘﾝｸ(xanadu62.blogspot.jp)
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265/build/msys
cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
すると以下の様なエラーが返されコンパイルに失敗しました。何が原因でコンパイルに失敗したのでしょうか？
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entr
505:y CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. CMake Error at CMakeLists.txt:19 (project): The CMAKE_CXX_COMPILER: x86_64-w64-mingw32-g++ is not a full path and was not found in the PATH. Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. -- Configuring incomplete, errors occurred! See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log". See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
506:名無しさん＠編集中
15/06/27 14:39:38.88 UsG4h7yl.net
PATH が通ってない
507:492
15/06/27 15:41:02.64 l6Oe5HEN.net
>>494
Cmakeを置いてある場所
D:\MSYS\cmake\bin
を環境変数のPATHに登録してみましたがやはりエラー内容は変わりませんでした。
うーん、何が原因でしょうか・・・
半年くらい前にx265をコンパイルしたときは特に問題無く通ったはずなんですが・・・
508:名無しさん＠編集中
15/06/27 15:46:02.47 Wz4orqrw.net
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265/build/msys
ここにあるmultilib.shの中に
-DEXTRA_LIB=x265_main10.a
という記述があるけど、これは間違いじゃない？
509:名無しさん＠編集中
15/06/27 17:06:47.93 sEawlLsz.net
>>495
cd x265/build/msys
./make-Makefiles.sh
make
これじゃダメ？
510:492
15/06/27 21:37:46.86 l6Oe5HEN.net
>>496
すみません、込み入ったことは分かりません(´；ω；｀)
>>497
やってみましたがダメでした(´･ω･｀)
$ ./make-Makefiles.sh
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_CXX_COMPILER:
x86_64-w64-mingw32-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
511: ◆tsGpSwX8mo
15/06/27 22:03:18.49 WqnHBzoK.net
>>498
まずはPATH(gcc)の確認
512:名無しさん＠編集中
15/06/27 22:36:46.62 07ob81ds.net
>>493
はて、斜め読みだから的はずれなこと書いてたらごめんなさい。
>> cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
>> -DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
>>CMake Error at CMakeLists.txt:19 (project):
>>The CMAKE_C_COMPILER:
>>x86_64-w64-mingw32-gcc
>>is not a full path and was not found in the PATH.
PERFIXでi686-w64-mingw32 (32bit用だっけ？)って書いてるのに
エラーメッセージで
x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ここらへんじゃない？
513:名無しさん＠編集中
15/06/27 22:50:23.25 07ob81ds.net
ごめん、ものすごく的はずれなこと書いてたらしい。
忘れて。
514:492
15/06/28 04:27:18.91 kJVbfWHG.net
>>499
生きます(´；ω；｀)！
> まずはPATH(gcc)の確認
>>500
> x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ハッ！今気付きました・・・。MSYS環境でコンパイルするときは単純にコマンドプロンプトを立ち上げるのでは無く
msys.batを実行してシェルを起動しなければならないということに・・・。というわけでmsys.batを実行してシェルを立ち上げ
そこであらためてx265のコンパイルを試みてみました。
結果は・・・また違ったエラーが返されました(´･ω･｀)
$ cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ../../source/
-- cmake version 3.2.1
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe -- broken
CMake Error at D:/MSYS/cmake/share/cmake-3.2/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler "D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe" is not able
to compile a simple test program.
It fails with the following output:
Change Dir: D:/MSYS/x265/build/msys/CMakeFiles/CMakeTmp
(続く）
515:492
15/06/28 04:28:36.90 kJVbfWHG.net
(続き)
Run Build Command:"C:/cygwin/bin/make.exe"
"cmTryCompileExec2492638483/fast"
/usr/bin/make -f
516: CMakeFiles/cmTryCompileExec2492638483.dir/build.make CMakeFiles/cmTryCompileExec2492638483.dir/build make[1]: Entering directory '/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp' /D/MSYS/cmake/bin/cmake.exe -E cmake_progress_report /D/MSYS/x265/build/msys/CMakeFiles/CMakeTmp/CMakeFiles 1 make[1]: /D/MSYS/cmake/bin/cmake.exe: Command not found CMakeFiles/cmTryCompileExec2492638483.dir/build.make:57: recipe for target 'CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj' failed make[1]: *** [CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj] Error 127 make[1]: Leaving directory '/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp' Makefile:117: recipe for target 'cmTryCompileExec2492638483/fast' failed make: *** [cmTryCompileExec2492638483/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:19 (project) -- Configuring incomplete, errors occurred! See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log". See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log". コンパイラーが壊れてるってどういうことでしょうか？MSYSを再インストールしろってことでしょうか？
517: ◆tsGpSwX8mo
15/06/28 06:17:57.29 7ma/nKKp.net
>>503
CygwinをPATHから外すとどうなる(cygwinディレクトリをリネームでもおｋ)？
518:名無しさん＠編集中
15/06/28 07:25:10.29 hIou2o11.net
なんで コンパイラのエラーも読めないヤツが
コンパイルしようとしてんの？
519:名無しさん＠編集中
15/06/28 08:08:48.17 kZOLiJyl.net
というか、普通に環境づくりが失敗してるだけでしょ
全自動で環境作ってくれるスクリプトとか配布してるところあるんだから
そういうの使って１発全自動で環境つくれよ
それで解決だよ
520:名無しさん＠編集中
15/06/28 09:59:08.61 fYmTl1Mq.net
そもそもmake-Makefiles.shがあるのに何でcmakeのコマンドを直接叩いてるんだろうという疑問が・・・
cmake -G "MSYS Makefiles" ../../source
としてMSYS Makefilesを明示しないとcmakeが勝手にコンパイラを選択したはず
いちいち面倒くさいことせず、MSVCでやる方法が一番簡単だと思うな
521:名無しさん＠編集中
15/07/04 00:45:41.40 YGz1q9Lu.net
12bit意外と早く来そうだな
522:名無しさん＠編集中
15/07/04 06:45:29.92 AzJNmnE3.net
Multibitええね
何がいいって、ビルドするときに1コマンドでいいのがｗ
exeはちょっとでかくなるけど気にしない
523:名無しさん＠編集中
15/07/04 11:26:38.48 LaJ5nNJQ.net
そんなに使い分けてるの？
524:名無しさん＠編集中
15/07/04 12:51:35.76 AzJNmnE3.net
使い分けてない
いつも使ってるのは10bit
ただ、最近導入されたmultilib.batがクソ楽ちんなんで絶賛してるだけ
525:名無しさん＠編集中
15/07/14 18:47:52.37 idZm8Phr.net
XP対応でビルドされたやつは配布されていないの？
526:名無しさん＠編集中
15/07/14 19:36:02.32 idZm8Phr.net
とりあえず探してみた結果
XPで作動するやつ
作動可能
x265_0.7+289_x86.exe
x265_0.8+3_x86.exe
作動可能だが、やや作動が怪しい
x265_0.8+61_x86.exe
x265_0.8+149_x86.exe
作動不可
x265_0.8+190_x86.exe
作動不可の原因はVista以降に使われている関数、
SleepConditionVariableCSが原因です
527:名無しさん＠編集中
15/07/14 19:39:39.31 idZm8Phr.net
こののやつのバイナリは最新版もXPで作動するね
URLﾘﾝｸ(x265.ru)
528:名無しさん＠編集中
15/07/14 19:57:17.95 idZm8Phr.net
>>513のは
URLﾘﾝｸ(rigaya34589.blog135.fc2.com)
URLﾘﾝｸ(www.dropbox.com)
529:名無しさん＠編集中
15/07/14 21:43:14.97 0sHf5gOl.net
自分でどうこう出来ないならXP使うなよｗｗ
530:名無しさん＠編集中
15/07/15 14:46:48.25 Dln1hXUc.net
自分でXP対応でビルドすればいいと言ってみる
531:名無しさん＠編集中
15/07/15 15:42:54.53 ENlb271m.net
XPはマルチコア時の性能が低い
貧乏人ならLinux使った方がマシ
532:名無しさん＠編集中
15/07/15 18:18:06.19 DXiTqnAr.net
XP使ってる貧乏人なんだからシングルコアの可能性もあ�
533:驍ｾろ
534:名無しさん＠編集中
15/07/15 19:54:44.34 F6Dht5ea.net
いやさすがにそれは・・・
535:名無しさん＠編集中
15/07/16 00:14:28.25 ZRyn4IRA.net
intel HTT(Hyper Threading Technology)じゃ駄目か？
536:名無しさん＠編集中
15/07/16 08:16:36.84 f1hZBsh9.net
今1.7だよね
何故0.8とかなの？
537:名無しさん＠編集中
15/07/18 14:55:18.41 68ZYLSDZ.net
情弱からの改竄職人 とーる君
メールアドレス：sjfosfoasfo@yahoo.co.jp
携帯番号：08066192913
37o0d5M
538:08066192913
15/07/18 19:12:25.80 bBMzk35F.net
情弱からの改竄職人 とーる君
539:08066192913
15/07/18 19:13:04.85 bBMzk35F.net
メールアドレス：sjfosfoasfo@yahoo.co.jp
540:08066192913
15/07/18 20:16:30.92 IE1b+ET3.net
あ
541:08066192913
15/07/18 20:17:13.58 SoskPJ+N.net
い
542:08066192913
15/07/19 13:05:04.98 RJp4FHa5.net
情弱からの改竄職人 とーる君
88XzdAMl
543:08066192913
15/07/19 18:12:32.22 EX1fxnmk.net
02T9Qhq0
544:08066192913
15/07/19 18:12:54.11 EX1fxnmk.net
34KV3VQ8
545:名無しさん＠編集中
15/07/19 21:40:33.40 1gnsFKQG.net
avi：映像制作［レス削除］
ｽﾚﾘﾝｸ(saku板:43-番)
546:08066192913
15/07/20 03:36:57.20 NeURmLNR.net
bt742CY7
547:08066192913
15/07/20 10:27:00.48 d4VaFPJ9.net
1zzlNflJ
548:08066192913
15/07/20 10:29:46.33 vWDQMbiN.net
情弱からの改竄職人 とーる君
1zzlNflJ
549:名無しさん＠編集中
15/07/24 02:22:33.01 qIPjjeFO.net
Windows2000でH.265をエンコードしてみる
URLﾘﾝｸ(www.nico) video.jp/watch/sm26774171
550:名無しさん＠編集中
15/07/26 17:42:48.79 lSABQG3J.net
12bitのFourCCってないの？
551:名無しさん＠編集中
15/07/26 19:10:11.69 bAcAj12A.net
そんなAVIの遺物をいつまでも引きずるな
552:名無しさん＠編集中
15/07/27 14:01:50.09 WXFY+U6V.net
12bitエンコ出来るようになったのはいいけど、デコーダーがまだ無いな
553:名無しさん＠編集中
15/07/27 14:17:11.84 zmqr9Jt6.net
えっ
554:名無しさん＠編集中
15/07/27 15:06:33.32 RYhN1uKU.net
>>539
12bitをちゃんとデコードできるデコーダーがあるなら挙げてみ？
555:名無しさん＠編集中
15/07/27 18:17:58.85 MoB8fNT9.net
デコーダのないエンコーダって意味あるんですかねそれ
556:名無しさん＠編集中
15/07/27 18:22:12.79 RYhN1uKU.net
experimentalな段階で意味つってもな。
x265 [warning]: Main12 is HIGHLY experimental, do not use!
557:名無しさん＠編集中
15/07/27 18:25:34.41 AhU7j0d9.net
12bitって画質とサイズの費用対効果で言うとどうなん？
10bitだと8bitより効率いいみたいだけど。
558:名無しさん＠編集中
15/07/27 18:44:46.44 XMdjkvfw.net
先にインタレサポートして欲しいよ
559:名無しさん＠編集中
15/07/27 18:46:31.30 X6RbocHm.net
12bitはBT.2020環境下でバンディングノイズを出さないようにすることを前提としたものであって、現時点で一般ユーザーが使わなければならないようなものじゃない。
560:名無しさん＠編集中
15/07/27 19:20:47.97 4GogWDeS.net
自分用に使うに決まってんじゃん
561:名無しさん＠編集中
15/07/27 19:50:36.98 X6RbocHm.net
豚に真珠
562:名無しさん＠編集中
15/07/27 20:40:45.21 RYhN1uKU.net
>>543
デコードできないからとりあえずcrf20でSSIMだけでも調べてみようと思ったらこんな結果になった。
experimentalすぎて何もできない段階かな。
x265 [info]: HEVC encoder version 1.7+373-db59e6d9b85b
--tune ssim --ssim --crf 20
8bit
encoded 2018 frames in 278.43s (7.25 fps), 4988.06 kb/s, SSIM Mean Y: 0.9928450 (21.454 dB)
10bit
encoded 2018 frames in 368.82s (5.47 fps), 4875.11 kb/s, SSIM Mean Y: 0.9941356 (22.318 dB)
12bit
encoded 2018 frames in 676.06s (2.98 fps), 13733.34 kb/s, SSIM Mean Y: 0.6725987 ( 4.849 dB)
563:名無しさん＠編集中
15/07/27 20:57:29.12 Ep+Jd60L.net
そのようで・・
564:名無しさん＠編集中
15/07/27 20:59:25.49 AhU7j0d9.net
>>548
おお、調べてくれてありがと
565:名無しさん＠編集中
15/07/27 21:37:26.63 zmqr9Jt6.net
>>540
ちゃんとって今のデコーダは完全ではないってこと？この動画は表示できてるけど
URLﾘﾝｸ(forum.doom9.org)
LSMASHVideoSource(stacked = true, format = "YUV420P16")
Dither_convert_yuv_to_rgb(matrix = "709", lsb_in = true, output = "rgb24", ampn = 0)
8bit
URLﾘﾝｸ(i.imgur.com)
10bit
URLﾘﾝｸ(i.imgur.com)
12bit
URLﾘﾝｸ(i.imgur.com)
566:名無しさん＠編集中
15/07/27 23:31:34.84 RYhN1uKU.net
>>551
それはちゃんと見れるね・・・。デコードできないというのはどうもこちらの勘違いだった模様。まじごめん。
rigayaさんのとこのx265_1.7+373_x64を使って12bitエンコして
MPC-HC1.7.9(内蔵LAV0.65)やL-SMASH Worksでデコードすると、
URLﾘﾝｸ(www.dotup.org)
のようにおかしくなるんで、12bitはまだ正常にデコードできないものだと思い込んでしまった。
>>548もそのバイナリを使った結果なので、参考にしないほうがいい。
試しに>>551のリンク先にあるx265_1.7+371-24c1ee516d13.GCC492の
Win64\x265_ml.exeで12bitエンコしてみたら普通に見れた。
つうことで、12bitも普通にデコードできるってことでいいのかな・・・。
567:名無しさん＠編集中
15/07/28 00:22:42.61 xs+H8iag.net
許さん。二度と来るな。消えろ。氏ね。
568:名無しさん＠編集中
15/07/28 16:25:43.22 W4i+wzm1.net
ファーｗ
569:名無しさん＠編集中
15/07/30 12:48:57.21 4Dgns5PX.net
12bit出力試してみたけど
TSとかのYV12ソースをDitherで１6bit主力i420での12bitはうまくできたけど
ゲームとか録画したRGBソースを
YUV24化してi444の12bit出力がなんか緑がかった画面になってうまくいかんかった。
Outputdepthを10bitはうまくできたんだけども。
ようわかりません。
570:名無しさん＠編集中
15/07/30 12:51:49.53 4Dgns5PX.net
YUV24じゃなｋったYV24だった。すみません。
Dither_convert_rgb_to_yuv(matrix="601",tv_range=true,lsb=true,mode=-1,output="YV24")
571:名無しさん＠編集中
15/07/30 15:57:29.21 RtKKrWDv.net
>>555-556
1.7+380で12bit i444出力して試してみた。
1. MPC-BE1.4.5でMPC Video Decoder＋EVRの場合は、RGB32出力されて正常に再生される。
2. MPC-HC1.7.9（LAV Filters 0.65）＋EVRの場合は、RGB32出力されて緑になってしまう。
3. MPC-HC1.7.9（LAV Filters 0.65）＋madVRの場合は、Y416出力されて正常に再生される。
そっちの再生環境が書かれてないので2.で再生したのかどうかは知らんけど、
もし2..なのだとしたらLAV Video Decoderの12bitYUV4:4:4→RGB32変換がおかしいんだと思う。
572:名無しさん＠編集中
15/07/30 16:30:29.67 4Dgns5PX.net
>>557
LAV Filters 0.65使ってます。
まさに２の状態でした。
検証いただきありがとうございました。
573:名無しさん＠編集中
15/09/02 10:27:01.07 17+7uTqX.net
tst
574:名無しさん＠編集中
15/09/08 19:34:59.32 6BnL2XmX.net
なんか、今ビルドしたexe使うと、マルチスレッドが全く効いてないようなんだが、
変な変更入った？
575:名無しさん＠編集中
15/09/08 20:14:56.68 IIsd4ht2.net
自前でビルドするなら、コミットログ位自分で確認しろよ。
URLﾘﾝｸ(bitbucket.org)
576:名無しさん＠編集中
15/09/08 20:21:29.94 fH222Kze.net
ﾏﾝﾄﾞｸｾ('A`)･･･
577:名無しさん＠編集中
15/09/08 22:17:30.18 6BnL2XmX.net
>>561
いや、それが機能してないんじゃないか？という指摘なんだが、
ただ読んでるだけのお前より、実際に使ってる人の実体験のほうが重要だろ
578:名無しさん＠編集中
15/09/09 00:25:49.62 ucrN+mFp.net
何の具体的な情報も出さずに、実体験の方が重要だろって言っちゃうって、すごいな。
俺はUFOを見たんだ。実際にこの目で見たんだ。
って言われてもなぁ・・・。
579:名無しさん＠編集中
15/09/09 00:54:51.47 lhJuTuku.net
どうせおま環だろ
580:名無しさん＠編集中
15/09/09 13:49:23.15 16H1IFVw.net
>>563
実体験がなんだ？
スクロールすら出来ない奴がブツブツほざくなよ、雑魚が。
ビルドどころか、PC使うの辞めたほうが良いレベル、
それが世の為人の為。
581:名無しさん＠編集中
15/09/09 14:06:01.69 16H1IFVw.net
ちなみに、ID:IIsd4htは俺だ。
イライラしてて、書き方が乱暴になった。
>>560に対して、>>561で対象の変更と、
そこですでに開発者にバグ報告されて、
開発者も内容理解して、翌日fixすると
やりとりまでされた情報出したにも関わらず、
なんで>>563で、俺が文句言われなきゃならん訳？
お前が質問だけして、出された情報を全く理解出来ない奴って事だけは分かった。
人の話聞く気が無いなら、質問なんてするなよ、低能。
582:名無しさん＠編集中
15/09/09 14:07:33.68 16H1IFVw.net
ID:IIsd4ht2
IDまで書きミスったじゃねーかよ、ボケ。
583:名無しさん＠編集中
15/09/09 16:55:08.06 rTRAxpt2.net
以上、低脳劇場でした。(完)
584:名無しさん＠編集中
15/09/09 17:03:55.87 7U0Uqkc8.net
1.7+478-365f7ed4d896 これで Fix されたね。
585:名無しさん＠編集中
15/09/10 06:24:59.07 IzPmuN2L.net
>>566>>567
実体験は超重要
586:名無しさん＠編集中
15/09/10 08:17:05.65 1Cb4E+Y/.net
質がある程度保証されるフォーラムとかならともかく、
ほとんどが「こちらの勘違いでした」で終わるような掲示板で語られる実体験は微妙じゃないかい？
たまに当たりがあるのは否定しないけれど
587:名無しさん＠編集中
15/09/10 08:35:43.13 YOKNJnul.net
結局誰も試してないっぽいしおま環かも実際にそうなのかもわからんわｗ
588:名無しさん＠編集中
15/09/10 08:40:39.32 WsVHyNvR.net
ちょっと何言ってるか分かんない
589:名無しさん＠編集中
15/09/10 22:32:37.33 KJ0kRu7c.net
なんか良さげな更新があってスレ進んだのかなと思って見に来たのに
なんじゃこりゃ
590:名無しさん＠編集中
15/09/12 00:18:42.15 XaHNf2Ma.net
prepareになってから一か月経ってんのか…
591:名無しさん＠編集中
15/09/17 07:35:56.04 Vin772sA.net
突然x265の開発が停滞しだしたけど、何かあったの？
592:名無しさん＠編集中
15/10/08 21:13:37.20 6W1l538e.net
>>x265 version 1.8 has been released.
>>This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.
593:名無しさん＠編集中
15/10/08 22:51:27.95 uYI8xAvc.net
するの？それともされたの？
594:名無しさん＠編集中
15/10/09 00:50:54.95 exeJoz3M.net
>>579
has been
595:名無しさん＠編集中
15/10/09 01:18:40.45 u8RFIes1.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
faster
1.7 encoded 313 frames in 14.20s (22.05 fps), 600.65 kb/s, SSIM Mean Y: 0.9259115 (11.302 dB)
1.8 encoded 313 frames in 13.99s (22.37 fps), 598.68 kb/s, SSIM Mean Y: 0.9264626 (11.335dB)
fast
1.7 encoded 313 frames in 29.44s (10.63 fps), 593.51 kb/s, SSIM Mean Y: 0.9310887 (11.617 dB)
1.8 encoded 313 frames in 23.90s (13.10 fps), 591.59 kb/s, SSIM Mean Y: 0.9307948 (11.599dB)
medium
1.7 encoded 313 frames in 34.93s (8.96 fps), 592.51 kb/s, SSIM Mean Y: 0.9329568 (11.736 dB)
1.8 encoded 313 frames in 30.54s (10.25 fps), 585.75 kb/s, SSIM Mean Y: 0.9326935 (11.719dB)
slow
1.7 encoded 313 frames in 129.29s (2.42 fps), 587.25 kb/s, SSIM Mean Y: 0.9359766 (11.937 dB)
1.8 encoded 313 frames in 115.54s (2.71 fps), 584.54 kb/s, SSIM Mean Y: 0.9358390 (11.927dB)
slower
1.7 encoded 313 frames in 276.12s (1.13 fps), 584.50 kb/s, SSIM Mean Y: 0.9372324 (12.023 dB)
1.8 encoded 313 frames in 222.83s (1.40 fps), 582.14 kb/s, SSIM Mean Y: 0.9366779 (11.984dB)
x264 core:146 r2555 0c21480
veryslow
encoded 313 frames, 17.80 fps, 622.27 kb/s, SSIM Mean Y:0.9211507 (11.032db)
URLﾘﾝｸ(www.dotup.org)
596:名無しさん＠編集中
15/10/09 07:27:39.06 Q96PdMlI.net
あれま1.8ってあったのね
597:名無しさん＠編集中
15/10/09 09:10:50.86 GV+ZIqNz.net
>>580,580
ｔｈｘ！
598:名無しさん＠編集中
15/10/09 10:18:28.60 FcOiDfHW.net
>>581
CPU何使ってるの？
599:名無しさん＠編集中
15/10/09 23:37:12.17 u8RFIes1.net
AMDのFX-8300定格です
600:名無しさん＠編集中
15/10/10 00:08:51.18 TUv/1SN/.net
さすがエンコ向けなだけあるな
601:名無しさん＠編集中
15/10/11 22:52:22.59 sQ9XJT0L.net
AVX2無しでも結構変わるのかなこりゃ
fastとslowerの伸び率凄いな
602:名無しさん＠編集中
15/10/11 23:35:19.31 1iAxDOqX.net
rigayaさんは今年も年末辺りにx265の速度比較してくれるのかな
603:名無しさん＠編集中
15/10/12 00:46:55.70 WVekvBHO.net
自前ビルドなんでVerがちょっと新しいけど>>581とHEVCだけ同じ事やってみた
x265 [info]: HEVC encoder version 1.8+30-030744551098
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
faster
encoded 313 frames in 4.68s (66.84 fps), 598.41 kb/s, Avg QP:31.37, SSIM Mean Y: 0.9264005 (11.331 dB)
fast
encoded 313 frames in 6.63s (47.25 fps), 588.29 kb/s, Avg QP:35.56, SSIM Mean Y: 0.9305941 (11.586 dB)
medium
encoded 313 frames in 8.02s (39.01 fps), 585.12 kb/s, Avg QP:35.54, SSIM Mean Y: 0.9326401 (11.716 dB)
slow
encoded 313 frames in 28.55s (10.96 fps), 581.17 kb/s, Avg QP:34.81, SSIM Mean Y: 0.9355421 (11.907 dB)
slower
encoded 313 frames in 60.20s (5.20 fps), 579.85 kb/s, Avg QP:35.67, SSIM Mean Y: 0.9365124 (11.973 dB)
CPUは5960X 4.2GHz、
4コアのi7辺りでテスト出来れば、もうちょっと比較になるけど、
AVX2持っててすぐにテスト出来るのがこれだけだったから。
604:名無しさん＠編集中
15/10/12 01:21:47.76 7qlqVooM.net
>>589
おおお！
すごい速度が出てるなあ
5960X恐るべし
605:名無しさん＠編集中
15/10/19 09:30:21.53 yFiWBold.net
midium、SD解像度ならSandy i5でもそこそこ実用的な速度だなぁ
606:名無しさん＠編集中
15/10/19 17:08:24.78 3+3B3ynS.net
ここ数日、ビルド出来なくなってるな
607:名無しさん＠編集中
15/10/20 02:26:43.01 4gF8GZ9l.net
Intra refreshってなんだ
608:名無しさん＠編集中
15/10/21 12:52:02.41 wDWh+p6H.net
ブロードキャスト用でしょ
609:名無しさん＠編集中
15/10/23 10:02:07.23 tigdGsjm.net
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
610:名無しさん＠編集中
15/10/27 21:58:53.54 HfJdvsW+.net
8,10,12bitを出力出来るmultilibなx265.exeのビルドは
Rigaya氏を参考にVS2013で成功、
URLﾘﾝｸ(mylabo.webcrow.jp) さんの環境とスクリプトを応用してGCC5.2で成功しました
しかし、ffmpegにMultilbなx265を組み込むのがうまくできません
どこか参考になるサイトなどあったら教えてください
611:名無しさん＠編集中
15/10/28 17:36:55.29 APLDwghM.net
同じavisynthからの入力で8bitでエンコしたものと
10bitでエンコしたものではアウトプットの色が若干違ってしまいます
オプションは8bitのものをそのまま使ってますが
10bit用に何か設定しないといけないものがあるのでしょうか
ちなみに8bitでエンコしたものは入力と同じ色で出力されています
612:名無しさん＠編集中
15/10/28 19:01:55.48 8El7diMy.net
>>597
特に必要な設定は無いと思うけど、
・使用したx265のバイナリのURLやリビジョン
・エンコードに使ったツールやコマンドライン、x265のエンコードオプション、エンコードログなど
・avsの内容
・色の違いの確認に使ったツールや設定等（再生プレーヤー、デコーダー等）
・色の違いというのが具体的にわかる比較用スクリーンショット
と言った情報をちゃんと出せば答えてくれる人がいるかもね。
613:名無しさん＠編集中
15/10/28 19:16:21.95 +oncCKMQ.net
質問させてください
コマンドプロンプト画面でx264のように
エンコードの終わり予想タイムは出ないのですか
だいたいの目安になるのでもし表示させる方法があったらお願いします
614:名無しさん＠編集中
15/10/28 19:27:19.30 2TscTojl.net
>>599
avs4x26x使ってるけど出てる気がする
615:名無しさん＠編集中
15/10/28 20:08:55.37 s5f82YBj.net
>>596
URLﾘﾝｸ(github.com)
これ使えば全自動
616:名無しさん＠編集中
15/10/28 20:13:55.37 +oncCKMQ.net
>>600
avs2pipemodでは出ないです
avs4x26xを試してみます
ありがとう
617:名無しさん＠編集中
15/10/29 08:57:26.76 2tL2U4Zq.net
>>597
x64のLavだとおかしくなる
x86だと正常に出力される
何だろね
618:595
15/10/29 14:38:45.78 hokEF0fR.net
>>601
うわ！なんか凄いのがあるんですね
色々試してみます
619:名無しさん＠編集中
15/10/29 17:52:52.35 hokEF0fR.net
>>601
早速試してみたところ、最初のfreepypeのビルドであっさりエラーで停止
全自動とは程遠いｗ
スクリプトのx265のところを覗いて見ましたが、
普通にx265のソースをgit cloneした時のMSYSのところにあるmultilib.shと同じことをしているようだけど、、、
12bit版のlibx265.aをビルドし、libx265_main12.aにリネームし、8bit用のフォルダにコピー
10bit版のlibx265.aをビルドし、libx265_main10.aにリネームし、8bit用のフォルダにコピー
8bit版のlibx265.aをビルドし、libx265_main.aにリネームし、
arコマンドを使って上記３個を結合し、libx265.aとする
ここまではmultilib.shと全く同じ
問題は、この後make installをどうやるか。
普通にmake installするとエラーが出て出来ない。そのせいでffmpegに組み込めない。。。
620:名無しさん＠編集中
15/10/29 18:47:45.30 KEjOdrQp.net
rigaya氏のバッチで充分。
621:名無しさん＠編集中
15/10/29 18:49:22.39 hokEF0fR.net
それはexeを作る場合だね
その話はしてないので。
622:名無しさん＠編集中
15/10/29 19:08:17.76 KEjOdrQp.net
ぶっちゃけ流れ読んでかなったからごめんよ!
623:名無しさん＠編集中
15/10/29 19:21:33.49 hokEF0fR.net
うーん、libx265を除いておけばビルド成功する状態なのに、
--enable-libx265を入れると成功しない
「ERROR: x265 not found using pkg-config」
というメッセージが出る
もちろん、multilibではない普通のlibx265を組み込むのは成功してます
624:名無しさん＠編集中
15/10/29 19:50:40.90 GqQK4kTk.net
今ゼロからやってみたがfreetypeは普通にビルドできるな
もう１回やってみたら
625:名無しさん＠編集中
15/11/04 19:24:15.28 bY3Gmjjh.net
ロシアのバイナリを使っているんですけど
GCCとかICCとかVISUA C++とか違いはコンパイルツール？だそうですけど
どれがお勧めなんですか
626:名無しさん＠編集中
15/11/04 19:36:10.00 aZP/zq43.net
どれでも大差なし
627:名無しさん＠編集中
15/11/04 19:51:13.54 bY3Gmjjh.net
そうなんですか
ICC使っときます
ありがとう
628:名無しさん＠編集中
15/11/04 23:15:59.75 e9GNmcr1.net
あえて言えばVSがWinでは速い？のかな
629:名無しさん＠編集中
15/11/05 08:18:36.25 zXSftKub.net
早いところVS2015に対応てほしい
630:名無しさん＠編集中
15/11/05 17:48:42.31 nPPKDmWy.net
sln少し書き換えれば2015でビルド出来るよ
631:名無しさん＠編集中
15/11/05 23:39:10.13 A8+5sKPz.net
対応・・・？
ビルドする人なら対応なんぞ特にいらんだろ
632:名無しさん＠編集中
15/11/06 11:09:19.93 fy2s3Lcb.net
>>616
ん？ソリューションファイルなんて、弄る必要有ったっけ？
cmakeのtargetをVS2015にするだけで良かった気がするけど。
633:名無しさん＠編集中
15/11/06 13:10:44.19 ysZ3FpZt.net
>>618
あ、ごめんそっちだったｗｗ
make-solutions.bat のやつを次の行のようにするだけだな。
cmake -G "Visual Studio 14 Win64" ..\..\source && cmake-gui ..\..\source
634:名無しさん＠編集中
15/11/08 19:01:12.75 LWtfbo8L.net
さっきまで1.8+93（MSCV2013で自ビルド）テストしてたけど、ロシアサイトのインテルコンパイラ版（古いバージョン）
より速くなってた。
着実に進化してますな。
635:名無しさん＠編集中
15/11/28 06:26:26.50 xnQKeIKd.net
しっかし、進展ないと過疎すぎるな・・・
636:名無しさん＠編集中
15/11/28 10:08:11.74 jmEC8E0s.net
いつからの進展なのか知らないが
確実に進歩してるぞ
637:名無しさん＠編集中
15/11/30 23:21:51.00 Dp01uuLv.net
いつの間にかすごい速くなってますね
638:名無しさん＠編集中
15/11/30 23:30:39.00 /6tzZX36.net
日本語でおｋ
639:名無しさん＠編集中
15/12/05 11:39:48.52 HP9A4Irs.net
インドの大雨のせいで今開発が滞っているらしい
エンジニアの大半はインドにいるんだとか
640:名無しさん＠編集中
15/12/05 13:24:08.05 j/JKm4pn.net
道理でカレーとタンドリーチキン動画のエンコだけは早いわけだ
641:名無しさん＠編集中
15/12/05 14:32:20.10 rfE+JCrx.net
_,._
( ﾟДﾟ) ・・・
642:名無しさん＠編集中
15/12/05 22:04:26.39 8cfk2vXJ.net
大雨でインドア中か
643:名無しさん＠編集中
15/12/05 22:22:32.22 OGp3Rmbu.net
自宅が水で浸かってるのにインドアってなんじゃい
644:名無しさん＠編集中
15/12/05 22:30:08.64 1ig9YDeb.net
インド人もびっくり
645:名無しさん＠編集中
15/12/06 11:19:00.57 0gVCYaZ3.net
>>609
それ、もしかすると本家でも問題になってるかもしれない
x265_config.h に「include <stdbool.h>」を書き足したら動くかも。
media-autobuild_suiteを使うならbuild/patchesにパッチを置いてmedia-suite_compile.shを編集してdo_patchする必要がありそう
URLﾘﾝｸ(bitbucket.org)
646:名無しさん＠そうだ選挙に行こう
15/12/14 12:27:21.04 nlnTVFDP.net
rigayaさんのところのx265のverが一気に進んでるけど
開発者は無事に帰れたの？
647:名無しさん＠そうだ選挙に行こう
15/12/14 15:52:12.96 vodPq1d5.net
え？
Rigayaさんはただ自分でビルドしたものを公開してるだけで、
Rigayaさんがx265開発してるわけじゃないんだけど。
x265は時々、しばらく更新停止した後
648:に突然何十個ものアップデートが公開される時がある
649:名無しさん＠そうだ選挙に行こう
15/12/14 16:01:44.81 nlnTVFDP.net
更新が無かったから更新されてなかったのかな、と
650:名無しさん＠そうだ選挙に行こう
15/12/14 16:15:03.73 BMjI76th.net
>>634
リポジトリを確認するようにしたほうがいい。
URLﾘﾝｸ(bitbucket.org)
651:名無しさん＠そうだ選挙に行こう
15/12/14 17:33:04.26 nlnTVFDP.net
>>635
ｔｈｘ
（自分でビルドしないけど）ブクマしといた
652:名無しさん＠編集中
15/12/26 18:10:11.04 PC8RPPww.net
自分用メモ
sandyで、昨日自ビルドしたx265とx264の初エンコテスト比較
x265とx264ともに8bit --preset slower --aq-mode 3 --no-psyで30分の720*480エロ動画
ffmpegでssimの計測
x265
13.38 fps, 263.65 kb/s
SSIM Y:0.885624 (9.416659) U:0.972000 (15.528396) V:0.963594 (14.388307) All:0.913015 (10.605566)
x264
70.87 fps, 604.44 kb/s
SSIM Y:0.979789 (16.944222) U:0.983586 (17.847748) V:0.978977 (16.773040) All:0.980287 (17.052421)
bitbucket見ると最初のコミットが2013-03-07だからがんばってるてことか
Yの落ち込みが大きいからYへのunsharpで多少は補正できそう
653:名無しさん＠編集中
15/12/27 16:03:00.15 QPUC82p+.net
また、「同じオプション指定で比較」するバカが住んでるのか。。。
654:名無しさん＠編集中
15/12/27 16:48:07.26 AP5rfsnS.net
サンプルが小さすぎるのもありそう
SDならxvidのq3ぐらいのほうが綺麗
655:名無しさん＠編集中
15/12/27 18:55:24.77 1UDAOmVw.net
ソースは640x480、41985フレームのアニメ、SSIMはffmpeg調べ。
Xvid q3
エンコ時間3分、1070kbps、SSIM Y:0.986353
x264 r2638kMod --crf 23
エンコ時間3分、532kbps、SSIM Y:0.985826
x264 r2638kMod --crf 21
エンコ時間3分25秒、719kbps、SSIM Y:0.988074
x265 1.8+188 --crf 21
エンコ時間14分23秒、411kbps、SSIM Y:0.985115
>>639
手元のソース１つで試した結果にすぎないし、SSIMだけで画質を語るつもりもないけど、
「SDならXvidの方が綺麗」と主張し続けてる人がどういう基準で「綺麗」だと言ってるのかよくわからん。
656:名無しさん＠編集中
15/12/27 19:38:15.28 JuHwvd0v.net
xvidが綺麗と思えばxvidを使えばいいんじゃない
657:名無しさん＠編集中
15/12/27 21:12:50.41 AP5rfsnS.net
>>640
たびたび書いてるのは自分だけどq値決め打ちじゃなく
画質に満足いくまでq値を下げるのが前提（画質を追求するなら結局q2.6ぐらいまで下げることになる
綺麗の定義は「グレンの潰れなさ具合」
たぶんでブロッキングフィルタとかディテールつぶしが無い分
素直にディテールが綺麗に残るんじゃないかと思ってる
（最後の行を書いてて思いましたけど実写での経験則）
早い話がビットをより多く使うから綺麗ってオチなわけだけど
グレンノイズの少ないソースじゃ違いは分からないかもね
658:名無しさん＠編集中
15/12/28 15:03:35.77 AuSc0FjL.net
ソース、640x480、3分、エロ動画
SSIMはffmpegで測定
x264 デフォ＋no-psy+aq-mode 3
SSIM Y:0.928542 (11.459472) U:0.985500 (18.386333) V:0.981752 (17.387954) All:0.946903 (12.749319)
encoded 5401 frames, 99.91 fps, 1097.19 kb/s
x265 デフォ＋no-psy+aq-mode 3+crf 28
SSIM Y:0.804027 (7.078027) U:0.973071 (15.697855) V:0.959527 (13.928366) All:0.858117 (8.480711)
encoded 5401 frames in 245.51
659:s (22.00 fps), 255.90 kb/s, Avg QP:33.79 x265 デフォ＋no-psy+aq-mode 3+crf 27 SSIM Y:0.803084 (7.057188) U:0.973849 (15.825170) V:0.960736 (14.060104) All:0.857820 (8.471623) encoded 5401 frames in 248.81s (21.71 fps), 374.87 kb/s, Avg QP:31.58 x265 デフォ＋no-psy+aq-mode 3+crf 26 SSIM Y:0.802878 (7.052659) U:0.974114 (15.869358) V:0.961091 (14.099513) All:0.857787 (8.470593) encoded 5401 frames in 253.15s (21.34 fps), 433.19 kb/s, Avg QP:30.47 x265 デフォ＋no-psy+aq-mode 3+crf 25 SSIM Y:0.822244 (7.501752) U:0.976616 (16.310877) V:0.965200 (14.584195) All:0.871799 (8.921072) encoded 5401 frames in 255.54s (21.14 fps), 503.93 kb/s, Avg QP:29.35 x265 デフォ＋no-psy+aq-mode 3+crf 24 SSIM Y:0.821997 (7.495718) U:0.976931 (16.369759) V:0.965568 (14.630388) All:0.871748 (8.919347) encoded 5401 frames in 258.54s (20.89 fps), 589.12 kb/s, Avg QP:28.23
660:名無しさん＠編集中
15/12/28 15:04:48.96 AuSc0FjL.net
x265 デフォ＋no-psy+aq-mode 3+crf 23
SSIM Y:0.821710 (7.488735) U:0.977138 (16.408933) V:0.965787 (14.658129) All:0.871628 (8.915289)
encoded 5401 frames in 261.84s (20.63 fps), 693.45 kb/s, Avg QP:27.10
x265 デフォ＋no-psy+aq-mode 3+crf 22
SSIM Y:0.821424 (7.481768) U:0.977380 (16.454981) V:0.966083 (14.695766) All:0.871526 (8.911859)
encoded 5401 frames in 264.99s (20.38 fps), 819.56 kb/s, Avg QP:25.95
x265 デフォ＋no-psy+aq-mode 3+crf 21
SSIM Y:0.821099 (7.473879) U:0.977621 (16.501670) V:0.966309 (14.724900) All:0.871388 (8.907184)
encoded 5401 frames in 268.56s (20.11 fps), 972.80 kb/s, Avg QP:24.81
x265 デフォ＋no-psy+aq-mode 3+crf 20
SSIM Y:0.820743 (7.465236) U:0.977812 (16.538787) V:0.966536 (14.754276) All:0.871220 (8.901516)
encoded 5401 frames in 272.35s (19.83 fps), 1158.67 kb/s, Avg QP:23.67
x265 デフォ＋no-psy+aq-mode 3+crf 19
SSIM Y:0.820388 (7.456652) U:0.977981 (16.572001) V:0.966702 (14.775778) All:0.871039 (8.895425)
encoded 5401 frames in 276.62s (19.52 fps), 1380.33 kb/s, Avg QP:22.54
x265 デフォ＋no-psy+aq-mode 3+crf 18
SSIM Y:0.850120 (8.242556) U:0.981450 (17.316653) V:0.972696 (15.637714) All:0.892438 (9.683394)
encoded 5401 frames in 281.16s (19.21 fps), 1648.32 kb/s, Avg QP:21.43
661:名無しさん＠編集中
15/12/28 17:19:14.07 AuSc0FjL.net
書き忘れ
636, 642, 643にはtune ssimをつけてある
書き忘れテスト, 2passは動かなかったから1pass
ソースは>>643, 643と同じ
x264 no-psy aq-mode 3 bitrate 300
SSIM Y:0.913324 (10.621006) U:0.980374 (17.071684) V:0.974576 (15.947585) All:0.934708 (11.851377)
encoded 5401 frames, 181.90 fps, 305.19 kb/s
x265 no-psy aq-mode 3 medium bitrate 300
SSIM Y:0.804045 (7.078432) U:0.973717 (15.803202) V:0.960709 (14.057068) All:0.858434 (8.490416)
encoded 5401 frames in 248.80s (21.71 fps), 294.75 kb/s, Avg QP:33.58
x265 no-psy aq-mode 3 slow bitrate 300
SSIM Y:0.804188 (7.081599) U:0.973960 (15.843551) V:0.960968 (14.085785) All:0.858613 (8.495908)
encoded 5401 frames in 381.43s (14.16 fps), 294.42 kb/s, Avg QP:33.35
x265 no-psy aq-mode 3 slower bitrate 300
SSIM Y:0.804009 (7.077635) U:0.974380 (15.914158) V:0.961492 (14.144482) All:0.858651 (8.497078)
encoded 5401 frames in 878.83s (6.15 fps), 293.76 kb/s, Avg QP:33.24
x265 no-psy aq-mode 3 veryslow bitrate 300
SSIM Y:0.804055 (7.078661) U:0.974246 (15.891494) V:0.961360 (14.129654) All:0.858638 (8.496666)
encoded 5401 frames in 1402.14s (3.85 fps), 293.52 kb/s, Avg QP:33.36
662:名無しさん＠編集中
15/12/28 17:53:58.02 lN2S38Mz.net
つまり今のところ
x264＞x265
ってこと？
663:名無しさん＠編集中
15/12/28 18:59:54.42 dW745Ccp.net
>>643-645
x265のSSIM:Yの数値が低すぎる。x265のSSIMを正しく測れてないと思うよ。
*.265のままソースと比較すると正しく測れないので、mp4にmuxしてから測る必要がある。
XvidのAVIもそのままだと正しく計測できないようだったので、
AVISource()で読み込んだavsを作ってそれをソースと比較した。
なんでうまく測れないのかはよくわかってないけど。
664:名無しさん＠編集中
15/12/28 19:36:33.28 AuSc0FjL.net
マジかよ
スクリプト書き直しか
たいした労力じゃないけど
665:名無しさん＠編集中
15/12/28 22:03:14.78 Yj61mlND.net
数値による比較じゃなく実際に目で見て判断しないと・・
それとエロvdvぐらいならx264のcfr22ぐらいでやれば十分で
666:しょ
667:名無しさん＠編集中
15/12/28 23:46:54.12 UvY7E994.net
ffmpegのSSIMフィルタはソースのfpsとエンコしたもののfpsがかなり正確に合ってないと正しく算出出来なかったと思う。
あと確かVP9なんかもAltRefフレーム使ってる関係上か知らないけど普通に読み込むとおかしくなるからAvisynth経由で読み込んでAssumeFPSとかしないと駄目。
668:649
15/12/29 00:37:10.31 8IWJ8AGX.net
VP9云々のやつ今試してみたらAvisynth経由しなくても普通に出来た。
ffmpegのバージョンが上がって修正されたのかも（？）よく分からないけど。
669:名無しさん＠編集中
15/12/29 09:35:31.46 9A7QFVez.net
647
ホントだ
muxしたらssimが上がってた
muxによってはpts、 DTS、timestampで怒られた
ffmpegから直接265をいじるのが一番無難だった
ffmpegはlibのオプションをオバーライドすることあるから、やりたくなかったんだけど
>>649
まぁ、お遊びってことで
670:名無しさん＠編集中
15/12/29 17:30:38.12 9A7QFVez.net
あと、fmpegから直接265をいじったとき
265のpreset mediumだとfps40でた
y4mを直接265に読ませるとfps20
なんで？
671:名無しさん＠編集中
15/12/29 18:41:26.53 wmua3h70.net
所詮ffmpeg、その程度ってことだろ。
672:名無しさん＠編集中
15/12/29 19:40:09.08 hecsvuwY.net
目で見て判断とか
どれだけ自分の目に自信があったら言えるんだ
673:名無しさん＠編集中
15/12/29 19:48:01.97 9A7QFVez.net
>>654
ffmpegのほうが速いんですよ
年末にはまっちまた
674:名無しさん＠編集中
15/12/29 20:01:58.91 wm1Lq+lC.net
目で見ずにどうやって画質評価するのか疑問
675:名無しさん＠編集中
15/12/29 20:40:58.71 R7bcCv7T.net
SSIMだって人間の感覚から乖離してるのにね
画質オタって自分の感覚に自信が持てないからか絶対的に見える数値評価を過信するよな
676:名無しさん＠編集中
15/12/29 21:04:13.88 5PhTB4UX.net
HEVC の利点って心理的効果も含めて、画質が「良く」見える事じゃないの?
SSIM はあくまでソースとの乖離性を数値化した物だから人間の目が判断する画質とは異なる。
最終的な判断は自分の目で見ることに違いないだろ
677:名無しさん＠編集中
15/12/29 21:10:09.82 kA6WO2Bz.net
一番マシな数値指標がSSIMってだけで、参考程度にはするけど過信してる奴は別にいないだろ。
678:名無しさん＠編集中
15/12/29 21:26:30.90 TzjPmFls.net
目も目で主観入ることもあるし数値化もある程度指標にはなるっしょ
散々そこらで書かれている通り過信しなきゃいいだけ
679:名無しさん＠編集中
15/12/30 00:57:27.86 vwvyTCw8.net
SSIMはいちいち画像貼らずに画質の比較が出来るから著作権的に安心なのがいいと思うのよな
あとグラフ書いたりも出来るし
680:名無しさん＠編集中
15/12/30 02:50:29.16 0tUCtX9N.net
エンコーダの性能を語る場において主観的な評価を用いることに意味があるのか？
画質の良さなんて人それぞれなんだから
そりゃどんな設定で使うかは自分で好きにすればいいけどさ
>>645みたいなレビューで主観的に語られてもちっとも参考にならないだろ
681:名無しさん＠編集中
15/12/30 09:18:02.01 rUpbP8pC.net
>>663
支離滅裂
大丈夫か？
682:名無しさん＠編集中
15/12/30 10:05:33.84 0j3mn2aP.net
>>663
頭悪いと大変だな…
683:名無しさん＠編集中
15/12/30 10:41:31.01 iKvrKZHw.net
俺も>>663はいまいちよくわからない文章だと思ったが、
「>>645みたいな比較を行う場合は主観的評価（"これが綺麗な気がする"とか）じゃ
わけわから�
684:ﾋーからSSIM使うしかないだろ」 と言いたいのかなと思った。
685:名無しさん＠編集中
15/12/30 10:48:13.38 IZ86kZ2w.net
綺麗な気がするとかは意味ないしSSIM比較にも賛成なんだが、
どういう感じに画質劣化するとかレビューはあれば読みたい。
ソースの傾向とも関連するだろうし。
686:名無しさん＠編集中
15/12/30 12:23:46.55 0tUCtX9N.net
>>666
その通りだよ
文章を理解しようとしない人ばかりじゃなくて安心した
ここの人たちはとりあえず批判しておきたいんだろうね
ただ俺も伝わりにくい書き方をしたことは詫びておくよ
687:名無しさん＠編集中
15/12/31 11:52:46.61 jlLBbrcv.net
Performance Presets
URLﾘﾝｸ(x265.org)
688:名無しさん＠編集中
15/12/31 13:25:56.61 1x/a9izS.net
ほうlimit-refsをデフォで使うようになった感じ？
720p mediumならリアルタイムでエンコできる環境が増えそうだ
689:名無しさん＠編集中
15/12/31 18:06:45.58 wSkFl2OB.net
グラフ見る限りは魅力的だけど、新プリセットはどこにあるのかな
git見てもそんなのまだなさそうだが
690:名無しさん＠編集中
15/12/31 18:35:10.47 xsxqdEld.net
>>671
既存のプリセットの設定を調整したという話だと思うんだが・・・
691:名無しさん＠編集中
15/12/31 19:04:36.81 pgio0AKr.net
これめちゃ速いな。
--input-csp i420 --preset slow --crf 21 --aq-mode 3 --aq-strength 0.9 --psy-rd 0.5 --psy-rdoq 8 --scenecut 42 --keyint 240
--tu-intra-depth 2 --tu-inter-depth 2 --max-merge 5 --weightb --frames 34096 --input-res 1920x1080 --fps 24000/1001
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 5
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 42
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 4 / 1 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=0.50 rdoq=2 psy-rdoq=8.00
x265 [info]: tools: signhide tmvp strong-intra-smoothing lslices=4 deblock sao
こんな感じで
encoded 34096 frames in 1504.14s (22.67 fps), 1137.26 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 5.82% / x265: 76.88%
全く同じオプションで--pmode付けると
encoded 34096 frames in 2293.68s (14.87 fps), 1122.80 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 3.69% / x265: 87.79%
画質はまだチェックしてないけど、問題無ければ、slowでも余裕でも余裕だな。
(10bitは使う予定無いので、未検証）
692:名無しさん＠編集中
16/01/01 02:18:30.24 WmQnDSNu.net
エラいスピードアップだな。
画質にダメージとかないんかね？
693:名無しさん＠編集中
16/01/01 03:09:19.16 RD6MTGrq.net
1.8+188で適応されてるの？
694:名無しさん＠編集中
16/01/01 05:20:46.74 O3DrfO55.net
SSIMの話してたら公式がグラフに使っててワラタ
695:名無しさん＠編集中
16/01/01 07:49:50.36 jXigYVvB.net
あーpresetの件、�
696:ｽ分、１２月２２日に導入されたこの変更のことだろうな https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce 各プリセットのパラメータを微調整したうえに、最近導入されたlimit-refs、limit-modesも加えたと。 最新ソースを使ってビルドしてるなら、もう１周間前に導入されてたということね。
697:名無しさん＠編集中
16/01/01 09:45:09.31 0amdltZA.net
12/23のx265guiEx 3.66v2でプリセット変更への対処が入ってたしな。
1.8+2と1.8+188とで、手元のソースをプリセット指定だけでエンコした結果を比べてみたら
・エンコード速度は全体的に向上。
・ultrafast～fasterでは従来よりSSIM値が小さくなり、ビットレートも大幅に低くなった。
・fast～slowerではSSIM値は従来と同じくらいだが、ビットレートがやや高くなった。
という結果になった。veryslowとplaceboは時間がかかるので試していない。
詳細→ URLﾘﾝｸ(pastebin.com)
698:名無しさん＠編集中
16/01/01 11:14:31.16 xC692RGG.net
すいません、質問です。
x265のソースコードを自分でビルドして使用しているのですが
バイナリのバージョンが不明なんです。これってコード追記しないといけないのでしょうか？
変な質問だったらスルーしてください。
699:名無しさん＠編集中
16/01/01 15:09:29.20 jXigYVvB.net
x265.exe --version
とコマンド打てば表示されるよ
700:名無しさん＠編集中
16/01/01 15:29:05.52 xC692RGG.net
>>680
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.
C:\Windows\system32>x265.exe --version
x265 [info]: HEVC encoder version unknown
x265 [info]: build info [Windows][MSVC 1800][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
こんな感じです。
701:名無しさん＠編集中
16/01/01 15:29:40.58 nwqCpAdi.net
>>679
ソース下のbuild/README.txtにも書かれてる事(「= Version number considerations =」を参照)だけど、
X265_VERSION はcmake実行時にMercurial(hgコマンド)を使用して設定、ないと"unknown"になる。
Mercurial(hg)のパスを環境変数PATHに追加してからcmakeを実行する。
702:名無しさん＠編集中
16/01/01 15:39:01.12 xC692RGG.net
>>682
ありがとうございます。
703:名無しさん＠編集中
16/01/01 17:27:43.84 jXigYVvB.net
Rigayaさんのとこのx265エンコ速度測定記事、プリセット変更直前に書かれてるのがおしい
704:名無しさん＠編集中
16/01/01 17:32:56.40 xC692RGG.net
なんでおかしいの？
rigaya氏が変更を事前に知っていて、わざと記事にしたとでもいうの？
705:名無しさん＠編集中
16/01/01 17:34:04.38 k8j4Ysr1.net
>>685
落ち着いて>>684を読み直してみろ
706:名無しさん＠編集中
16/01/01 17:39:27.38 jXigYVvB.net
>>685
うん。君はおかしい
はい次の人ー
707:名無しさん＠編集中
16/01/01 17:43:45.36 xC692RGG.net
m(__)m
708:名無しさん＠編集中
16/01/01 20:28:21.76 FNsjlYzw.net
ところでさ、現時点のx265はUltra HD BDの規格に準拠した形でのエンコードはできるんだろうか？
それともまだ何か未対応のオプションがあったりして、規格準拠とまではいかないのだろうか？
x265の進捗状況がよくわからないんだけど。
709:名無しさん＠編集中
16/01/02 21:42:43.73 uM4JuYJD.net
どうしても暗部保持ができなくてバンディングになっちゃう
おもいっきりビットレート上げればなんとかなるけど
一話23分半のアニメで3Gくらいの容量になるからさすがに割りに合わない
710:名無しさん＠編集中
16/01/03 06:14:00.23 TB5sGS/t.net
バンディング消す方法なんていくらでもあるでしょー
基本は10bitエンコだし、
バンディング低減
711:するフィルタだって複数あるよ x264よりも遥かにバンディング出ないx265で悩んでる人はじめて見た
712:名無しさん＠編集中
16/01/03 09:29:55.61 +7iHH5QT.net
バンディングて色調整するとワラワラ出てくることあるね
713:名無しさん＠編集中
16/01/03 12:06:06.62 KftKtXND.net
>>691
x264の10bitの方が明らかにバンディング出ないから悩んでるんだけど
エンコ速度的には十分だと思うし、その問題さえ解消するようならx265に移行するのもいいかなって思ってるけど
>485の頃からまだこういうところは調整されてないのかな？
714:名無しさん＠編集中
16/01/03 12:17:20.68 aIpwUsLj.net
どちらかというとAQで暗部は削られるものだと思うけど・・
715:名無しさん＠編集中
16/01/03 13:57:04.40 CBJBsL1D.net
糞なのはx265のPsyだろうねぇ
716:名無しさん＠編集中
16/01/03 22:11:59.73 V82V0kUc.net
下手くそ
717:名無しさん＠編集中
16/01/05 23:20:08.23 wK8tZoI/.net
ん？またプリセット変わったか
718:名無しさん＠編集中
16/01/06 21:50:42.37 /8vK25uX.net
URLﾘﾝｸ(bitbucket.org)
Merge with default, prep for 1.9
もうすぐ1.9が来そう
719:名無しさん＠編集中
16/01/10 08:23:42.64 Hd4RBeuI.net
x265 1.8+205 -d94f6c2b45f8
URLﾘﾝｸ(www1.axfc.net)
720:名無しさん＠編集中
16/01/10 14:30:01.33 m9YtAxYc.net
x64じゃないのかな
721:名無しさん＠編集中
16/01/10 14:32:48.05 m9YtAxYc.net
なんかエラーで落ちる
722:名無しさん＠編集中
16/01/10 14:47:46.35 Hd4RBeuI.net
>>701
マジすか？
ちょっと調べてみます。
>>700
64bit専用です。
723:名無しさん＠編集中
16/01/10 14:59:37.89 m9YtAxYc.net
普段ここの使ってるんだけど
URLﾘﾝｸ(builds.x265.eu)
ここのも1/8のものからエラーで落ちるようになってる
1/7の1.8+201のものはエラー出ない
自分の環境かもしれないし何が何だか分かってないけど
問題解決されると嬉しい
724:名無しさん＠編集中
16/01/10 15:10:43.28 Hd4RBeuI.net
これはどうでしょうか？
URLﾘﾝｸ(www1.axfc.net)
725:名無しさん＠編集中
16/01/10 15:42:21.06 m9YtAxYc.net
ありがとう
でも同じだった
イベントビューアにはこんな感じで上がってる
障害が発生しているアプリケーション名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
障害が発生しているモジュール名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
例外コード: 0xc0000005
障害オフセット: 0x0000000000790522
726:名無しさん＠編集中
16/01/10 16:05:38.87 Hd4RBeuI.net
うーん・・・
コマンドラインオプション無しでもエラー出ますか？
727:名無しさん＠編集中
16/01/10 16:09:39.28 m9YtAxYc.net
それだと出ないね
俺のオプションがダメっぽいのか…
どのオプションだろ
削りながら試してみるよ
ありがと
728:名無しさん＠編集中
16/01/10 16:12:07.50 Hd4RBeuI.net
メモリーアクセス違反か。
自分の環境では出ないんですよね。
OSはなんですか？
729:名無しさん＠編集中
16/01/10 16:15:17.26 Hd4RBeuI.net
AVX、AVX2、FMA3を潰してみるとか。
730:名無しさん＠編集中
16/01/10 16:16:06.57 m9YtAxYc.net
--no-deblock
このオプション抜いたらエラー出なくなった
これは自分の環境が悪いとかじゃないよね…
731:名無しさん＠編集中
16/01/10 16:23:36.91 Hd4RBeuI.net
ありがとうございます。
そちらの問題ではなく、コードに問題有りかもです。
732:名無しさん＠編集中
16/01/10 16:53:54.29 V/aHiJAl.net
斧に上がったバイナリなんてよく実行できるな・・・
733:名無しさん＠編集中
16/01/10 17:47:40.97 m9YtAxYc.net
どうやってバグの情報としてあげればいいのか分からないや
早く気付いて欲しいなぁ
734:名無しさん＠編集中
16/01/10 20:26:32.56 PlpsG+IN.net
>>713
bitbucketの課題にでも投げれば良いんじゃないの？
URLﾘﾝｸ(bitbucket.org)
735:名無しさん＠編集中
16/01/11 04:08:04.43 NFAme+dx.net
205で更にエンコ速度上がってるな
736:名無しさん＠編集中
16/01/11 18:42:34.02 8MzzuCE7.net
今は209だぜー
737:名無しさん＠編集中
16/01/11 22:48:39.09 iLbQXuHs.net
ここ最近開発が活発化してる
いいねえ
738:名無しさん＠編集中
16/01/12 03:22:31.26 ay8VbQDJ.net
x265-1.8+210_19cfada71621
URLﾘﾝｸ(www1.axfc.net)
739:名無しさん＠編集中
16/01/12 06:40:40.41 FuFhTotB.net
久々にビルドしてみたけど
デフォ設定で1.4と比べたら2倍くらいエンコ速くなってんな
740:名無しさん＠編集中
16/01/12 07:22:48.18 UGxx9q6x.net
密かにpsy-rdのデフォ値も変わったで
741:名無しさん＠編集中
16/01/12 08:45:59.11 FuFhTotB.net
ホントだ
1.0から0.6になっとるな
ちょこちょこ設定変えてんだな
742:名無しさん＠編集中
16/01/12 09:56:13.90 ZF6tU8kF.net
なかなか1.9にならんな
743:名無しさん＠編集中
16/01/12 10:09:53.76 xb1b+Mb+.net
>>721
旧： 値範囲0～2.0 デフォルト値0.3
新： 値範囲0～5.0 デフォルト値2.0
じゃね。
744:名無しさん＠編集中
16/01/12 11:20:34.90 FuFhTotB.net
strengthだった
745:名無しさん＠編集中
16/01/12 14:33:21.76 ckdTaHsh.net
H265 codecs comparison from MSU
URLﾘﾝｸ(x265.ru)
746:名無しさん＠編集中
16/01/12 14:48:48.67 J/v6lK/H.net
URLが怪しすぎる…
747:名無しさん＠編集中
16/01/12 15:14:52.56 UGxx9q6x.net
そこは、ちょっと前までx265バイナリの配布定番サイトだったんだけど、
multicorewareとトラブって配布禁じられたサイト
748:名無しさん＠編集中
16/01/12 15:33:28.98 xb1b+Mb+.net
>>727
トラブったという話の情報源はどこ？
本当ならテンプレからも外さないといかんよね。
749:名無しさん＠編集中
16/01/12 16:02:11.85 ay8VbQDJ.net
multicoreware-x265-6ccd503a4c3a
URLﾘﾝｸ(www1.axfc.net)
750:名無しさん＠編集中
16/01/12 16:07:54.77 ZF6tU8kF.net
ウィルスとかの問題じゃないから問題なし
x264は良かったとか書くあたりライセンスとかそのへんの理由
751:名無しさん＠編集中
16/01/12 21:07:29.03 UGxx9q6x.net
>>728
multicorewareがある日突然、他サイトでのバイナリ配布を禁じたんだよ
URLﾘﾝｸ(x265.ru)はバイナリ配布の最大手だったけど、一夜にして配布停止に追い込まれた
752:名無しさん＠編集中
16/01/12 22:21:22.09 vk6wUU7N.net
>>710
URLﾘﾝｸ(bitbucket.org)
微妙に症状は違うっぽいけど、--no-deblock付けてエラーになる事が解決されてるから、
多分、直ったっぽいよ。
753:名無しさん＠編集中
16/01/13 00:04:51.69 i5ptavi1.net
717のバイナリはバグっているので使わないほうがいい。
728は今のところ大丈夫。
754:名無しさん＠編集中
16/01/13 00:35:17.31 7rxsXKJd.net
そもそも他人ビルドで署名が無い物なんて使うわけ無いですし
755:名無しさん＠編集中
16/01/13 14:58:50.31 wOrVT6++.net
そうですか
756:名無しさん＠編集中
16/01/14 16:51:17.94 AaOlEqVU.net
>>732
1.8+211で試してみたけどまだ直ってないみたい…orz
でも気長に待ってみる
757:名無しさん＠編集中
16/01/15 06:50:52.92 psKZUe1A.net
x265-792f6ead9c50
URLﾘﾝｸ(www1.axfc.net)
758:名無しさん＠編集中
16/01/17 10:34:19.47 M6mbumiP.net
H.265はH.264の半分のビットレートで同等画質を実現するのが実証される - GIGAZINE
URLﾘﾝｸ(gigazine.net)
759:名無しさん＠編集中
16/01/17 10:49:26.43 D60EYyZP.net
>>738
これx264とx265でPSNR調べてもここまで差が出ないんだけど使ってるエンコーダーが違うのかね
760:名無しさん＠編集中
16/01/17 12:09:44.29 Pifl9Opi.net
JVとかいうリファレンスのコーデックでの比較なんじゃね
761:名無しさん＠編集中
16/01/17 12:11:58.73 D60EYyZP.net
JMとHMって書いてあったわ
762:名無しさん＠編集中
16/01/17 13:48:03.23 XmqoO05B.net
>>738
ADSL回線でピアキャスとかで配信するときに重宝する＞H.265
763:名無しさん＠編集中
16/01/17 23:50:56.36 Tbz8Tr7+.net
ADSLはプランによっては1000kbps上限だからねぇ
764:名無しさん＠編集中
16/01/29 2
765:1:07:28.93 ID:DKTs/nc/.net
766:名無しさん＠編集中
16/01/30 01:25:28.25 Wakff49R.net
1.9来たね！
767:名無しさん＠編集中
16/01/30 01:26:18.86 +Hb0depP.net
始まる前から終わってるx265
768:名無しさん＠編集中
16/01/30 01:28:24.65 pHFV68mi.net
今ビルドちゅう
769:名無しさん＠編集中
16/01/31 00:22:07.01 oQyeXKXJ.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
faster
1.8 encoded 313 frames in 14.69s (21.31 fps), 744.68 kb/s, Avg QP:29.82, SSIM Mean Y: 0.9345886 (11.843dB)
1.9 encoded 313 frames in 13.67s (22.90 fps), 728.73 kb/s, Avg QP:33.03, SSIM Mean Y: 0.9343822 (11.830dB)
fast
1.8 encoded 313 frames in 24.91s (12.57 fps), 733.66 kb/s, Avg QP:33.71, SSIM Mean Y: 0.9383575 (12.101dB)
1.9 encoded 313 frames in 26.91s (11.63 fps), 727.01 kb/s, Avg QP:33.73, SSIM Mean Y: 0.9384505 (12.108dB)
medium
1.8 encoded 313 frames in 32.16s (9.73 fps), 734.23 kb/s, Avg QP:33.80, SSIM Mean Y: 0.9399273 (12.213 dB)
1.9 encoded 313 frames in 29.66s (10.55 fps), 727.66 kb/s, Avg QP:33.77, SSIM Mean Y: 0.9395933 (12.189dB)
slow
1.8 encoded 313 frames in 117.56s (2.66 fps), 730.36 kb/s, Avg QP:33.21, SSIM Mean Y: 0.9423414 (12.391dB)
1.9 encoded 313 frames in 69.20s (4.52 fps), 720.24 kb/s, Avg QP:33.22, SSIM Mean Y: 0.9419035 (12.359 dB)
slower
1.8 encoded 313 frames in 239.98s (1.30 fps), 734.70 kb/s, Avg QP:34.08, SSIM Mean Y: 0.9430790 (12.447dB)
1.9 encoded 313 frames in 119.09s (2.63 fps), 703.49 kb/s, Avg QP:34.26, SSIM Mean Y: 0.9408265 (12.279dB)
x264 core:148 r2643 5c65704
veryslow
encoded 313 frames, 16.12 fps, 801.52 kb/s, SIM Mean Y:0.9335760 (11.777db)
URLﾘﾝｸ(www.dotup.org)
770:名無しさん＠編集中
16/01/31 01:35:17.36 cgqklV4a.net
>>748
slow slowerの高速化がすごい
771:名無しさん＠編集中
16/01/31 02:31:21.15 UHx+fRoe.net
ああ、俺もベンチするスクリプトを Ruby で書いてみたりしてたけど
最近やってなかったな。。。で久々にやってみたたら比較対象が 1.6 の medium しかなかったｗ
URLﾘﾝｸ(i.imgur.com)
772:名無しさん＠編集中
16/01/31 13:41:59.34 txIOJs0s.net
>>748
slowerがビットレート下がりすぎてSSIMもそれに引き摺られちゃってるね
でも倍も速度でてる
773:名無しさん＠編集中
16/01/31 16:07:20.48 cFXQSVbu.net
プリセット内容が変わったんじゃなかった？
774:名無しさん＠編集中
16/01/31 18:33:49.97 tisPGxzA.net
>>752
たしかあったな…
775:名無しさん＠編集中
16/01/31 18:53:54.26 TP98Z0n+.net
たしかにプリセット変更で旧プリセットと同じビットレートでのSSIM落ちたけどちょっとしか落ちてないしその分早くなってるからいいや
あとveryfastなんかだと速度も上がってSSIMも上がってたりする。
776:名無しさん＠編集中
16/01/31 20:01:42.34 FzlptxAC.net
x265は今後もCPUのみの演算で貫くのかね？
GPUのメモリーがHBMやHBM2の導入でかなり速くなるし、バス速度や演算能力そのものも上がろうとしているわけだが、
相変わらず一部だけでもGPUに振り分けるよりCPUのみのほうがいいのかね？
777:名無しさん＠編集中
16/01/31 20:07:08.49 cFXQSVbu.net
x265の開発元が新しいコンパイラHCCの開発をするみたいだから
ヘテロジニアス対応は案外、早いかもしれない
778:名無しさん＠編集中
16/01/31 20:24:55.92 o77Jhxsk.net
>>755
P
779:CIeの遅さが何とかなれば、じゃないかな NVIDIAのNVLinkは一般PC環境では期待できないみたいだし AMDもなんか高速バスかなんかやっているみたいだけど普及するかわからない
780:754
16/02/02 13:26:49.31 NCVy8Op8.net
>>756-757
HBM2がメインストリームのCPUやAPUに採用される日
URLﾘﾝｸ(pc.watch.impress.co.jp)
この記事によるとHBM2がコストダウンすれば一般向けのPC環境でも利用できるようになる可能性はあるようだから、あとはコストとバス速度の問題がなんとかなればいいのかも。
いつまでもCPUオンリーって時代でもないだろうし。
781:名無しさん＠編集中
16/02/02 14:53:24.44 oWE9M/3S.net
>>758
HBMは容量と帯域ばかりの記事が多かったけどレイテンシも低いんだな
じゃないとグラボ向けに積まれないか
782:名無しさん＠編集中
16/02/02 19:03:54.47 NCVy8Op8.net
GPUって大抵2スロット専有するんだから、PCI-Exスロットも2スロット挿しにして2倍速いってなわけにはいかないのかなと妄想。
783:名無しさん＠編集中
16/02/03 15:02:46.32 juHubKYm.net
>>760
っ [SLI]
784:名無しさん＠編集中
16/02/03 17:41:33.40 +OWBi5Bj.net
Android版とかiOS版のx265なんて出ないものなのかね？
785:名無しさん＠編集中
16/02/03 18:20:21.38 63ziqI0j.net
バッテリで動く端末との相性は最悪だろ
786:名無しさん＠編集中
16/02/03 18:34:18.04 +OWBi5Bj.net
>>763
なんで？
ちょこっとしたビデオクリップを編集後にエンコードまで出来たら、外出先で重宝しそうなものだが。
USB給電がこれだけ普及し、iPad proみたいなのまで出てくると、エンコードくらい多少時間がかかってもモバイル機器でできたほうが消費電力的にもうれしいわけだが。
787:名無しさん＠編集中
16/02/03 18:36:25.29 xdk3hERs.net
ちょっと何言ってるか分かんない
788:名無しさん＠編集中
16/02/03 18:38:36.07 iehiN48C.net
x265はともかくカメラの画像をエンコードしてるチップにデータ送ってエンコードできたらなどと思うことはあるw
789:名無しさん＠編集中
16/02/03 20:06:23.57 stWNn/Ef.net
最近リリースされたx265どう？
良ければコンパイルし直そうかと思ってる
790:名無しさん＠編集中
16/02/03 20:30:41.98 3wA6RKbD.net
たかがビルドで人に聞かないと動けないって・・・
791:名無しさん＠編集中
16/02/03 21:05:22.98 yXDm8y7+.net
rigaya 氏の multilib ビルドバッチでビルドは楽させて頂いているｗｗ
ありゃ楽だ