16/05/03 19:10:43.97 Vh9buT2E.net
[関連スレ]
・H265/HEVC全般の話はこちらへ
【2016】 H.265/HEVC Part5 【7680x4320】
ｽﾚﾘﾝｸ(avi板)
・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ
x264vfw GUI専用スレ Part9
ｽﾚﾘﾝｸ(avi板)
3:名無しさん＠編集中
16/05/03 20:23:59.76 bTK5aBdk.net
∧＿∧
ﾊｧﾊｧ （´Д｀ ;）>>1乙
（=====）
(⌒(⌒ )＠
／＼￣し'￣＼
／ ＼＿＿＿＼
＼ ／ ／
＿＿＼∠＿＿＿／
／ ／＼ ＼ ￣￣＼
／ ／ ＼ ＼ ＼
￣￣￣￣￣￣￣ ￣￣￣￣￣￣
4:名無しさん＠編集中
16/05/03 21:41:30.94 WDjgaW0U.net
乙
最近更新少なくて開発停滞気味だねえ
5:名無しさん＠編集中
16/05/04 16:38:52.56 Gk7Q3/B8.net
前スレで話してるcrfと2passの違いほんと？
自分でクソ適当にエンコしてもSSIM値に殆ど差が出ないし目視しても分からないんだけど。
URLﾘﾝｸ(media.xiph.org)
差が出る結果出せる人、時間あるなら↑ここの映像使って画像出して欲しい。
著作権的に多分問題は無いはず。
6:名無しさん＠編集中
16/05/04 18:34:33.11 2HnXwOPY.net
書いてあることが信用できないなら自分でするしかないような・・
動きの少ない動画x3と動きの多い動画x1（差が激しいほうがビットレート推移が分かりやすい）でエンコしてmpc-hcで観測
7:名無しさん＠編集中
16/05/05 01:38:28.42 SRphJZVx.net
前スレのグラフかっこいいね
8:名無しさん＠編集中
16/05/05 18:56:44.96 pGng/79C.net
全然更新ないね
次の安定版に向けて色々やっていると思いたい
9:名無しさん＠編集中
16/05/11 21:22:57.44 51QxUfSp.net
一定レスに達してないと落ちる仕様ってまだあるの？
10:名無しさん＠編集中
16/05/11 21:53:43.36 MRfjNqwe.net
10レス未満で1週間近く落ちてないんだからここは大丈夫だろ
11:名無しさん＠編集中
16/05/11 21:59:14.65 51QxUfSp.net
それはよかった
12:名無しさん＠編集中
16/05/13 21:56:26.68 eAq7OMMS.net
ふと思い立って実験してみたけど
実写をmediumでエンコ―ドするならSAO無効にしたほうがいいね
psy-rdoqとか使うなら違う結果になるかもしれないけど
13:名無しさん＠編集中
16/05/13 22:20:16.72 eAq7OMMS.net
今見たらx265のほうにも更新入ってるし完全パクったみたいじゃん
14:名無しさん＠編集中
16/05/13 23:16:00.67 4lCWvgTE.net
ちょっと何言ってるか分かんない
15:名無しさん＠編集中
16/05/13 23:48:30.70 gHAhlQkj.net
presetのgrainの設定がSAO=オフに変更されたってことでしょ
少し前にgrainを試してみたときは全然ダメでプリセットは信用ならねえと思ったわ
16: 【滑っちゃったぁ】
16/05/13 23:54:55.72 EkD2DdY2.net
自動的にを信用してはならない
17:名無しさん＠編集中
16/05/14 08:34:27.99 8gnvi4lw.net
littlepoxはdoomで--no-saoを推奨してたね
18:名無しさん＠編集中
16/05/14 08:48:54.99 8gnvi4lw.net
新しいオプションが追加されてた
doomじゃブレイクスルーになるかもと評判がいいみたい
19:名無しさん＠編集中
16/05/14 08:52:55.08 d21HSoRD.net
なんていうオプション？
20:名無しさん＠編集中
16/05/14 10:05:38.08 e94Mt9vg.net
デフォで有効になってるみたいだよ
> --[no-]recursion-skip Enable early exit from recursion. Default enabled
21:名無しさん＠編集中
16/05/14 21:50:05.71 e94Mt9vg.net
デフォの有効（--no-recursion-skip未指定）だと立体感はあるけど
無効よりディテールは少し減ってるような気がする
22:名無しさん＠編集中
16/05/15 18:37:14.69 lPi8YxFr.net
1.9+165と--no-recursion-skipのテスト(mediumだけ)
ソース： アニメOP、1920x1080、23.976fps、2157frames、YUV420p16
基本設定： --preset medium --crf 18
8bit
1.9+138
encoded 2157 frames in 252.86s (8.53 fps), 7440.15 kb/s, Avg QP:20.9
ffmpeg SSIM Y:0.983983
1.9+165
encoded 2157 frames in 265.05s (8.14 fps), 7384.20 kb/s, Avg QP:20.94
ffmpeg SSIM Y:0.984170
1.9+165 --no-recursion-skip
encoded 2157 frames in 384.93s (5.60 fps), 7464.76 kb/s, Avg QP:21.06
ffmpeg SSIM Y:0.984530
10bit
1.9+138
encoded 2157 frames in 315.03s (6.85 fps), 7325.48 kb/s, Avg QP:20.68
ffmpeg SSIM Y:0.984679
1.9+165
encoded 2157 frames in 355.95s (6.06 fps), 7252.08 kb/s, Avg QP:20.70
ffmpeg SSIM Y:0.984862
1.9+165 --no-recursion-skip
encoded 2157 frames in 482.43s (4.47 fps), 7267.19 kb/s, Avg QP:20.85
ffmpeg SSIM Y:0.985176
12bit
1.9+138
encoded 2157 frames in 349.10s (6.18 fps), 7306.18 kb/s, Avg QP:20.69
ffmpeg SSIM Y:0.984382
1.9+165
encoded 2157 frames in 387.51s (5.57 fps), 7226.26 kb/s, Avg QP:20.69
ffmpeg SSIM Y:0.984573
1.9+165 --no-recursion-skip
encoded 2157 frames in 516.39s (4.18 fps), 7235.56 kb/s, Avg QP:20.86
ffmpeg SSIM Y:0.984899
1.9+138→1.9+165の比較
エンコード速度ちょい低下、ビットレートちょい減少、SSIM微増
1.9+165でのrecursion-skip有効→無効の比較
エンコード速度かなり低下、ビットレートちょい増加、SSIM微増
23:名無しさん＠編集中
16/05/15 20:54:37.80 NBal+CGh.net
doomじゃ実写が評価されてるね
実写の追試リク
24:名無しさん＠編集中
16/05/15 21:19:55.40 lPi8YxFr.net
実写云々は、--tune grainの設定が変わったからじゃないかな？
--no-recursion-skipも追加されてるけど。
URLﾘﾝｸ(bitbucket.org)
誰かがわかりやすいサンプルで検証してくれることに期待。
25:名無しさん＠編集中
16/05/15 21:31:44.00 CC2svkXX.net
recursion-skipをOFFにすると速度が大幅低下ってことは
今までスイッチが無かっただけでrecursion-skip自体は前からやってたということかな
26:名無しさん＠編集中
16/05/15 22:38:41.49 kHdYS2X1.net
1.9+165 --preset medium --tune grain --crf 18
encoded 604 frames in 143.60s (4.21 fps), 28527.60 kb/s, Avg QP:24.04
URLﾘﾝｸ(2sen.dip.jp)
1.9+3 --preset medium --tune grain --crf 18
encoded 604 frames in 168.37s (3.59 fps), 42470.48 kb/s, Avg QP:22.61
URLﾘﾝｸ(2sen.dip.jp)
27:名無しさん＠編集中
16/05/15 22:51:49.51 lPi8YxFr.net
>>26
新しい --tune grain には --psy-rdoq 10.0 （--rdoq-level（デフォ0）が1or2の時だけ有効）も
入ってるので、一応 --rdoq-level 2 になる --preset slow で検証する方が良いかも？
28:名無しさん＠編集中
16/05/16 22:21:26.21 V6mFfwXt.net
>>26
サンプルはxigh.orgのDerf's Test Media Collectionにあるstockholmだと思うけど、
その白黒映像はどうやって作ったものなのか教えてほしいっす。
29:名無しさん＠編集中
16/05/16 23:05:36.75 iKr1aOW6.net
>>28
Histogram("Luma")
30:名無しさん＠編集中
16/05/17 02:27:35.36 5kaZma1C.net
>>29
ありがとっす！
31:名無しさん＠編集中
16/05/17 19:28:18.77 P+t3Az+o.net
>>26
なぜに、よりによって白黒
32:名無しさん＠編集中
16/05/17 19:40:23.92 41k99tkB.net
は？グレインのテストだからじゃないの？
33:名無しさん＠編集中
16/05/17 20:11:48.52 9rbfng+f.net
>>31
上の流れ見りゃわかると思うけど、元ソースはカラーだし、
グレインの残り具合をわかりやすく見せるために>>29で処理しただけでしょ。
34:名無しさん＠編集中
16/05/18 10:47:53.21 BSv9a6MO.net
doom9見るとno-recursion-skipはゴースト、ボケに威力発揮してるよう
35:名無しさん＠編集中
16/05/18 14:29:10.87 bp1dZZZ8.net
--no-なしのrecursion-skipが160以前の動作と同じで
--no-recursion-skipが新オプションで確定か
36:名無しさん＠編集中
16/05/18 18:29:06.11 BSv9a6MO.net
追記
ソースコード見るとrecursion-skipが常にonから切り替えできるようになってるぽいね。cu解析のオプション化みたい。まだ、改善する模様。
ゴースト、ボケを改善したければcu切れて言われてたし、littlepoxのpresetもcu下げてたから、かなりのcu改善みたい。
160とは同じではないみたい。earlyskipの進化なよう。recursion-skipの動作は最近入ったよう。
grainはno-recursion-skip、psyrd 4.0、psyRdoq 10.0、no-saoが追加されてるから、>>26ではno-recursion-skipの効果はわからなくなるね。
それにx265はx264と違ってyとuv切り離してないし、そもそもgrainをyだけで検証と言うのは、無理がある。
また、知ったかが暴れだしたか？
37:名無しさん＠編集中
16/05/18 20:42:10.24 EPVcrXvK.net
うん鏡
38:名無しさん＠編集中
16/05/18 20:56:28.11 8EQ39Kn/.net
>>36
> >>26ではno-recursion-skipの効果はわからなくなる
>>26は --no-recursion-skip のテストじゃなく、
1.9+3と1.9+165の --tune grain の違いを示したものだろ。
> grainをyだけで検証と言うのは、無理がある
別にyだけで検証してるわけじゃなく、Lumaだけでもこれだけ違いが出てるよというのが
示されてるんだから十分じゃね。uvについて知りたければ自分で試せばいいじゃん。
39:名無しさん＠編集中
16/05/18 21:28:29.97 3/Qcbi7C.net
ｽﾚﾘﾝｸ(avi板:99番)
まあ、昔はグレイン保持できねーってなってたのがtune grainでいい感じに保持出来るようになった（？）のはいい傾向だ
40:名無しさん＠編集中
16/05/18 22:28:10.75 bp1dZZZ8.net
けどビットレート倍はちょっと・・
>>38
いつもの噛みつくだけの人だよ
相手しないのが一番
41:名無しさん＠編集中
16/05/19 00:16:13.77 3ies0/GF.net
littlepoxって何者？
前スレを見てると、極端にSSIMが低くなるpresetを作る人程度しかわからなくて
42:名無しさん＠編集中
16/05/19 00:40:40.63 2ZkSxIJn.net
艦豚キチガイ
43:名無しさん＠編集中
16/05/19 14:50:19.52 +s1i053P.net
自演にしか見えない
44:名無しさん＠編集中
16/05/19 21:37:50.02 3ies0/GF.net
やっぱ>>36は自演か
45:名無しさん＠編集中
16/05/20 20:26:14.57 iL3PK3fI.net
>>44
よう，ネット番長
46:名無しさん＠編集中
16/05/20 20:45:44.13 ZImqmNIT.net
，
47:名無しさん＠編集中
16/05/22 14:56:52.13 jG0khJWr.net
2passでー、grainでーと暴れて押し切ろうとしてる人
x265 teamがfeedbackを求めてるから、feedbackしてあげてください
x264の--b-adapt 1のレポートもきっとみんな待ってますよ
48:名無しさん＠編集中
16/05/22 22:50:45.95 p3a1qJJi.net
揉めてるのは品質の評価方法であってオプションの効果じゃないだろ
49:名無しさん＠編集中
16/05/23 09:54:24.15 NTt96Vxp.net
揉めてるんじゃなくて周知のことすら理解できずにドヤ顔したら突っ込まれただけ
50:名無しさん＠編集中
16/05/23 12:49:26.33 tSeOZFOA.net
2passの件、誰も説明できなかったし初めて知った人もいたようだったからあなたが説明してくださる？
51:名無しさん＠編集中
16/05/23 17:21:22.39 pxNWWAWq.net
2passのどの話よ
2passは自動crfの話？
それとも2pass ABRによる画質比較のこと？
52:名無しさん＠編集中
16/05/23 17:59:18.97 NTt96Vxp.net
>>50
・・・
説明できないんじゃなくて、当然すぎて説明する気にもならない
2passゴリ押ししてた人頭悪そうだし、説明する気も失せる
挑発して説明してもらおうなんて幼稚だし
53:名無しさん＠編集中
16/05/23 18:10:47.10 5IwdnjI2.net
どうでもいいや今のところ2passする必要もないし
54:名無しさん＠編集中
16/05/23 18:13:51.23 pxNWWAWq.net
逆に相手を否定してバカにするだけで自分の意見を理解してもらえると考える方が幼稚
55:名無しさん＠編集中
16/05/23 18:27:18.06 qZ5tqY4d.net
他所でやって
ウザい
56:名無しさん＠編集中
16/05/23 18:27:25.08 9LZer2px.net
一度説明すれば同じ過ち（かどうかはまだわからんが）でスレを消費せずに済むと思うんだがどうだろうか
解説サイトのURLと該当箇所を示すくらいなら簡単なんじゃないかな
説明せずにケチつけるだけなのは非効率だと思う
57:名無しさん＠編集中
16/05/23 18:30:01.20 Q+pylUq3.net
結論は２Passはcrfに勝てず
58:名無しさん＠編集中
16/05/23 18:56:13.54 NTt96Vxp.net
>>54
>自分の意見を理解してもらえると考える方が幼稚
当然なことを2passや白黒の人に理解してもらおうなんて気はさらさらない、きっと他の人も
もう、ここに来ないでほしいだけ
>>56
貼って上げてください
59:名無しさん＠編集中
16/05/23 19:19:08.56 5IwdnjI2.net
次スレはワッチョイにでもしてかかわらないほうが建設的だよ
60:名無しさん＠編集中
16/05/23 19:29:29.90 56gQo93t.net
littlepoxでググってみたら、アニメ放流厨の中華だったでござる
61:名無しさん＠編集中
16/05/23 21:12:40.31 tSeOZFOA.net
>>52
みっともない逃げ方だこと（笑）
恥をお知りなさい
62:名無しさん＠編集中
16/05/24 18:15:21.97 qKsD06em.net
>>61
みっともない自演だこと（笑）
恥をお知りなさい
63:名無しさん＠編集中
16/05/24 18:43:14.98 z2edfvMr.net
>>58
>もう、ここに来ないでほしいだけ
よくわかってるじゃないですか
後は実行するだけですね、期待しています
64:名無しさん＠編集中
16/05/24 18:44:59.24 XfzCb1de.net
お兄様、何故あからさまな荒らしにカマうのかしら？
65:名無しさん＠編集中
16/05/24 21:43:48.79 NXE4pkzn.net
目糞が鼻糞を笑うスレはここですか？
ここはティッシュの上ではないのでよそでやってくださいね
66:名無しさん＠編集中
16/05/24 22:42:48.17 AqFm3GXC.net
日本神話では、目くそも鼻くそも美味しい食べ物なんだけどね
67:名無しさん＠編集中
16/05/25 12:03:20.20 yzOIEvHL.net
2Pass推し、前スレの>>867から暴走してるんだね。で、ここにきて白黒推し。
自演してみたり、余裕ぶってみたり、知った風なこと言ったり、もうレスしないと宣言してみたり。
何かを言い返し続ければ負けてないと思ってるんだろうか。
相手にされなくなったのを言い負かしたと勝ち誇った気分でいるんだろうか。
頭の不自由な人は大変だな。
68:名無しさん＠編集中
16/05/26 11:13:58.10 9YvZlgTO.net
>>63
大丈夫か？主語と述語が無茶苦茶で支離滅裂になってるよ。
添削すると
>もう、ここに来ないでほしいだけ
よくわかってるじゃないですか
後は実行するだけですね、期待して「ください」
だよ。
君が来る場所はここじゃないような。
69:名無しさん＠編集中
16/05/26 18:29:47.47 E5ZWfcS6.net
だからマジで他所でやれって
70:名無しさん＠編集中
16/05/28 14:25:39.62 wX7ej9h3.net
退治中は静観が吉
そのつもりはないだろうけど、こういう奴は理解不能な脳内変換で自分への援護射撃と思ってしまう
そして、再びドヤ顔知ったかと自演でスレを消費してしまう
71:名無しさん＠編集中
16/05/28 15:05:48.34 5w6R1K/s.net
veryslowとplaceboが--no-recursion-skipに変わったみたいなので
veryslowだけ以前との違いを測ってみたら、エンコ時間が1.3倍になってた。
8bit出力になってるのは計測をさくっと終わらせたかっただけなので気にせんといて。
ソース： アニメOP、1920x1080、23.976fps、2157frames、YUV420p16
1.9+165 --preset veryslow --crf 18 --output-depth 8
encoded 2157 frames in 3369.86s (0.64 fps), 7255.07 kb/s, Avg QP:21.54
ffmpeg SSIM Y:0.984817 U:0.984910 V:0.985182 All:0.984894 (18.208423)
1.9+183 --preset veryslow --crf 18 --output-depth 8
encoded 2157 frames in 4452.04s (0.48 fps), 7472.80 kb/s, Avg QP:21.41
ffmpeg SSIM Y:0.984948 U:0.984927 V:0.985203 All:0.984987 (18.235429)
72:名無しさん＠編集中
16/05/28 21:10:31.68 O4zL/40b.net
no-recursion-skipにするとSSIM上がるが、ビットレートも上がってるから当然っちゃ当然なんだよな
recursion-skipにしてその分crfとか下げるのとどっちがマシなんだか
73:名無しさん＠編集中
16/05/29 02:06:40.59 uVP1Rdvo.net
両方試してSSIM/ビットレートの割合がいい方を選べばよい
74:名無しさん＠編集中
16/05/29 10:12:00.52 3rVS0N3w.net
>>71
そのテストも意味がない
75:名無しさん＠編集中
16/05/30 19:26:46.08 FcXI9lBz.net
>>70
大方、>>69も自分が逃げるための自演
x264スレで前科有り
76:名無しさん＠編集中
16/05/31 02:53:58.02 bybNbgVC.net
だから他所でやれ
77:名無しさん＠編集中
16/05/31 19:49:04.49 zaN4NYl0.net
おまえがな
78:名無しさん＠編集中
16/06/01 22:28:45.85 7ZTwmhIo.net
TEST
79:名無しさん＠編集中
16/06/09 16:57:50.49 CpOR038T.net
rigaya氏のx265のskydriveを見てたら x265_1.9 204-f90_x64.zip というのがあったんだけど、
この「f90」というのは何のことを指してるんだろう？
80:名無しさん＠編集中
16/06/09 17:21:48.30 P9dtDg0X.net
コミットのハッシュ値上 3 桁だろ。普通に考えて。
81:名無しさん＠編集中
16/06/09 17:26:29.43 CpOR038T.net
>>80
なるほど！ありがとう。
82:名無しさん＠編集中
16/06/09 17:40:13.19 ZzEOVbr4.net
初心者スレあったほうがいいじゃ？
ずっと、レベルが低く過ぎる
83:名無しさん＠編集中
16/06/09 18:17:41.18 skb/ns3L.net
あってもこっちが過疎るだけ
84:名無しさん＠編集中
16/06/10 23:31:52.84 CH/r1Tms.net
>>82
お前の日本語レベルも低すぎるけどな
85:名無しさん＠編集中
16/06/11 13:02:53.75 2Uk5T/NT.net
また、よほど悔しかったんだな
86:名無しさん＠編集中
16/06/11 18:09:55.93 IKkdcckN.net
>>85
日本語不自由なチョンは祖国へ帰れ
87:名無しさん＠編集中
16/06/12 08:17:45.54 DkPJGnwz.net
>>86
自分のことじゃんか
88:名無しさん＠編集中
16/06/12 12:08:44.51 Xuc49pYS.net
じゃんかじゃんか
89:名無しさん＠編集中
16/06/22 08:08:27.12 oXYmzCDC.net
ビルドサイトでの更新が205でずっと止まってる
90:名無しさん＠編集中
16/06/22 16:35:35.01 N8XjEL/U.net
ソースのほうは今、r217だよ
91:名無しさん＠編集中
16/06/22 22:49:07.67 GFY/pI8f.net
x265ってx264と同じSSIMでも見た目的には綺麗になったりする？(視覚心理的にって言うのかな？)
92:名無しさん＠編集中
16/07/01 02:34:06.36 eXmGHmS/.net
Merge with default; prep for 2.0
URLﾘﾝｸ(bitbucket.org)
今月中に2.0がリリースされそうだね
93:名無しさん＠編集中
16/07/01 08:57:02.58 QtD2x3zN.net
1.9から長かったな
94:名無しさん＠編集中
16/07/01 09:06:07.28 P9sL5UFf.net
AVX512対応ﾏﾀﾞｰ?
95:名無しさん＠編集中
16/07/13 23:49:18.20 nFgUz4zS.net
2.0
96:名無しさん＠編集中
16/07/14 00:29:42.28 P5bGJwY8.net
2.0きた
97:名無しさん＠編集中
16/07/14 01:28:33.00 sVP86fo6.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
faster
1.9 encoded 313 frames in 13.84s (22.61 fps), 728.73 kb/s, Avg QP:33.03, SSIM Mean Y: 0.9343822 (11.830dB)
2.0 encoded 313 frames in 12.83s (24.40 fps), 726.28 kb/s, Avg QP:33.22, SSIM Mean Y: 0.9348542 (11.861dB)
fast
1.9 encoded 313 frames in 27.09s (11.55 fps), 727.01 kb/s, Avg QP:33.73, SSIM Mean Y: 0.9384505 (12.108dB)
2.0 encoded 313 frames in 24.64s (12.70 fps), 724.47 kb/s, Avg QP:33.77, SSIM Mean Y: 0.9400338 (12.221dB)
medium
1.9 encoded 313 frames in 29.67s (10.55 fps), 727.66 kb/s, Avg QP:33.77, SSIM Mean Y: 0.9395933 (12.189dB)
2.0 encoded 313 frames in 27.89s (11.22 fps), 731.57 kb/s, Avg QP:33.71, SSIM Mean Y: 0.9426946 (12.418dB)
slow
1.9 encoded 313 frames in 69.36s (4.51 fps), 720.24 kb/s, Avg QP:33.22, SSIM Mean Y: 0.9419035 (12.359 dB)
2.0 encoded 313 frames in 63.44s (4.93 fps), 728.52 kb/s, Avg QP:33.12, SSIM Mean Y: 0.9452176 (12.614 dB)
slower
1.9 encoded 313 frames in 119.42s (2.62 fps), 703.49 kb/s, Avg QP:34.26, SSIM Mean Y: 0.9408265 (12.279dB)
2.0 encoded 313 frames in 149.25s (2.10 fps), 726.79 kb/s, Avg QP:34.07, SSIM Mean Y: 0.9451561 (12.609dB)
x264 core:148 r2699 a5e06b9
veryslow
encoded 313 frames, 15.21 fps, 754.73 kb/s, SSIM Mean Y:0.9323419 (11.697db)
URLﾘﾝｸ(www.dotup.org)
98:名無しさん＠編集中
16/07/14 06:17:08.42 uwPTeTlV.net
>>97
なんかSlowerだけ異質な数値出てるな
エンコ速度も前バージョンより遅いし、そもそもSSIMがSlowより悪化してる
99:名無しさん＠編集中
16/07/14 08:08:03.27 ArwXuOa+.net
r-skipが入ってるんじゃ
100:名無しさん＠編集中
16/07/14 11:37:45.18 PR62YpKr.net
CBRかい
101:名無しさん＠編集中
16/07/14 16:03:22.94 Pf/qVR+4.net
>>100
x265.exe --help
--bitrate <integer> Target bitrate (kbps) for 【ABR】 (implied). Default 0
猫科研究所 - CBRの幻想
URLﾘﾝｸ(www.up-cat.net)
102:名無しさん＠編集中
16/07/14 16:34:13.57 da4zdf2/.net
そういう話じゃないと思うよ
103:名無しさん＠編集中
16/07/14 22:16:36.76 8bpVy04V.net
その話題飽きたから次からテンプレ入れとけ
104:名無しさん＠編集中
16/07/15 00:29:05.26 gFNFEBfb.net
URLﾘﾝｸ(forum.doom9.org)
x265 version 2.0 has been released.
This release supports many new features as well as support for ARM assembly optimizations for most basic pixel and ME operations, as well as SAO cleanups and a fully tested reconfigure functionality.
105:名無しさん＠編集中
16/07/18 23:08:15.32 U29u9sDT.net
2.0+2を試したけど、--(no-)recursion-skip が --(no-)rskip に変わったのね。
ドキュメント見ると、--no-rskip になるプリセットはveryslowとplaceboになってるけど、
エンコログを見ると、veryslowでは --rskip になってる。
106:名無しさん＠編集中
16/07/20 13:41:58.96 d0W2UZ5d.net
> 3. AQ enabled with auto-variance and bias to dark scenes. This is
> recommended for 8-bit encodes or low-bitrate 10-bit encodes, to
> prevent color banding/blocking.
ドキュメントが更新されてaq3の説明が↑となってるけど
low-bitrate 10-bitエンコードってどのぐらいのcrf値なんだろ？
107:名無しさん＠編集中
16/07/20 22:15:54.39 WmnuQ1x4.net
定性的なことを語っている文章に、定量的なことを求められても困るだろｗ
低ビットレートほど暗部でバンディングが出やすくなる(一般論)
AQは自動で暗部にビットレートを配分してバンディングが出にくくなる機能(一般論)
どこかに線引があるような話はしてない
108:名無しさん＠編集中
16/07/20 23:03:48.89 d0W2UZ5d.net
ドキュメントは触れていないけど
私がそっちに話を振ったのよ
それに品質基準なんだからある程度の線引きは可能では？
109:名無しさん＠編集中
16/07/20 23:11:51.70 pSPbXRvy.net
そんなオレオレ線引きはいらない
110:名無しさん＠編集中
16/07/20 23:56:59.59 d0W2UZ5d.net
分からないなら書かなくていい
111:名無しさん＠編集中
16/07/21 00:56:53.53 JB7+LDU0.net
>>108
>>107の説明が的確だと思うんで、そんなダダこねられても。
112:名無しさん＠編集中
16/07/21 13:08:20.04 lSlFGcCZ.net
なんか話が通じてないなと思ったら引用が中途半端だったせい？
> 0. disabled
> 1. AQ enabled **(default)**
> 2. AQ enabled with auto-variance
> 3. AQ enabled with auto-variance and bias to dark scenes. This is
> recommended for 8-bit encodes or low-bitrate 10-bit encodes, to
> prevent color banding/blocking.
AQ3は8-bit encodes or low-bitrate 10-bit encodes時に推奨って訳じゃないの？
んで利用が推奨されてる「low-bitrate 10-bit encodes」とはどの程度のビットレート（＝crf値）のことなんだろうって疑問なんだけど
考え方が間違ってる？
113:名無しさん＠編集中
16/07/21 13:42:51.28 gKWdYT+n.net
>>112
うん、間違ってる
114:名無しさん＠編集中
16/07/21 14:24:45.33 lSlFGcCZ.net
どう違うんです？
115:名無しさん＠編集中
16/07/21 14:35:15.76 9rogZMmq.net
とりあえずバンディングが問題になる素材を使って、ビットレートを揃えてAQ各種を比較するのが一番
116:名無しさん＠編集中
16/07/21 19:02:51.75 lSlFGcCZ.net
単純にAQ3でエンコしてお、良くねと思ったけど
容量が3割ほど増えてたから使わないのはそうそうに決めた
117:名無しさん＠編集中
16/07/21 19:10:18.45 KldPAn+J.net
低くないビットレートでmode3がダメなんて書いてないのなら、mode3を使ったらいいんじゃないかな
それで納得いかないのなら比較すればいい
118:名無しさん＠編集中
16/07/21 23:02:14.90 9rogZMmq.net
テストをするにしても、Doom9を参考にして、
--aq-mode 2 --aq-strength 1.2で、--aq-mode 3 --aq-strength 0.8くらいにすれば良いのかな
URLﾘﾝｸ(forum.doom9.org)
119:名無しさん＠編集中
16/07/21 23:30:16.73 lSlFGcCZ.net
ありがとう
参考にして様子見てる
120:名無しさん＠編集中
16/07/24 01:35:57.58 r/f2FrA3.net
今日環境見直してて気付いたけどなんかこれだけ色とか微妙におかしいような…
前からこんなだっけ
元(普段使ってるフィルタかけた後)
URLﾘﾝｸ(i.imgur.com)
x265 2.0+9-2737c6ff5f80 8bit(--preset medium --crf 20)
URLﾘﾝｸ(i.imgur.com)
x264 r2391(x64) 8bit(--preset medium --crf 20)
URLﾘﾝｸ(i.imgur.com)
おまけ
kvazaar 330ce53(x64) (--preset medium -q 20)
URLﾘﾝｸ(i.imgur.com)
libvpx-vp9(ffmpeg経由 N-81045-g450cf40) (-crf 20 -speed 1 -b:v 0)
URLﾘﾝｸ(i.imgur.com)
121:名無しさん＠編集中
16/07/24 01:47:27.02 lStqAKnf.net
>>120
どこがおかしいのかわからんのだが・・・
122:名無しさん＠編集中
16/07/24 01:55:03.71 r/f2FrA3.net
>>121
原稿用紙の部分で偽色が結構出ているのが気になって
まあ無視出来るレベルと言われればそうなんですが
123:名無しさん＠編集中
16/07/24 03:04:26.16 lStqAKnf.net
>>122
>>120の各結果画像のSSIMの値。
■x265
SSIM R:0.966924 G:0.975154 B:0.965303 All:0.969127 (15.104195)
■x264
SSIM R:0.975504 G:0.982286 B:0.972478 All:0.976756 (16.336831)
■kvazaar
SSIM R:0.977713 G:0.987817 B:0.978392 All:0.981307 (17.283314)
■vp9
SSIM R:0.977138 G:0.983460 B:0.975003 All:0.978534 (16.682425)
見てもわかるとおり、x265だけ画質が低い。
--crf 18くらいにすれば他と揃うんじゃないかな。
124:名無しさん＠編集中
16/07/24 04:22:35.44 r/f2FrA3.net
>>123
ありがとうございます
試してみたところ、crf 16でそこまで気にならない程度に収まりました(SSIMはx264のcrf20と同程度)
まあ、容量の関係から言うとメリットが薄れている感もありますが…。
125:名無しさん＠編集中
16/07/24 08:17:51.34 n41mNuCD.net
まだアレを信じてる人がいるとは
126:名無しさん＠編集中
16/07/24 09:38:58.54 hWE79xL6.net
>>120
この感じなんだろう・・
なんかで見たような・・
とりあえずSAO切ったりpsy下げたりしてみてほしいな
127:名無しさん＠編集中
16/07/24 11:25:27.79 3XVR1sc9.net
伸びてると思ったら2pass自演がまた暴れてたのか
128:名無しさん＠編集中
16/07/24 11:30:23.26 hWE79xL6.net
2pass？？
129:名無しさん＠編集中
16/07/24 19:20:51.73 LJfAk177.net
>>127は前スレから発狂し続けてる念仏君だからスルーしとけばいいよ。
130:名無しさん＠編集中
16/07/25 14:09:09.17 0wviLTfe.net
>>129
まんまお前のこと
131:129
16/07/25 16:46:40.05 7wyRO4LN.net
>>127 >>130
>>129は取り消す。
「2pass推し」とか「白黒推し」といった捻じ曲げられた呼称で粘着されてるのは俺だと思うけど
>>38を書いたのを除いて前スレ947の宣言からスルーし続けてたのに、
3か月たっても粘着され続けてるのでついイラッとして書いてしまった。反省してる。
信じないだろうけど、こちらは自演もしてないし、これまで君に構ってもいなかったので、
具体的な指摘無しで自演呼ばわりして粘着だけ続けるのはやめてほしい。そろそろリセットしようよ。
俺メンタル弱いんで正直気色悪いし、関係ないけど胃炎になって初めて胃カメラ飲んだし、
>>128のようにわけがわからず混乱してしまう人もいてスレに迷惑だし。頼むよ。
前も言ったけど、ケチつけるだけじゃなく具体的で有用なやりとりを心がけるべきだと思う。
132:名無しさん＠編集中
16/07/25 22:10:51.39 oeJRUVsa0.net
おお…
133:名無しさん＠編集中
16/07/26 14:10:48.58 xXwggsqP.net
アレコレ考えるのが面倒になってきたので
--crf 19 --preset medium --input-depth 8 --output-depth 10 --aq-mode 2 --aq-strength 0.6
これだけでずっとエンコしてるけど「俺の目には」これで充分だよ。小さくなるしなｗ
しかし、面倒だからとなあなあにしてると怠惰になるデス
134:名無しさん＠編集中
16/07/26 14:31:10.88 ZRl2Pp9T.net
>>131
>粘着だけ続ける
粘着してるのは自分では？
>俺メンタル弱いんで正直気色悪いし、関係ないけど胃炎になって初めて胃カメラ飲んだし、
メンタル弱いのにレスし続けてると
>>>128のようにわけがわからず混乱してしまう人もいてスレに迷惑だし。頼むよ。
>>129をみるとそう思えないけど。言っておいて取り消すと逃げる。本当にそう思ってる？
>前も言ったけど、ケチつけるだけじゃなく具体的で有用なやりとりを心がけるべきだと思う。
そう思うなら自分が具体的根拠を示せばいいだけでは？
主張の根拠を示すのは発言者なのはネット以前に常識
自分で種をまいて、火に油を注いで、メンタル弱いから、胃カメラのだからはどうなんだろうか？
みんなに迷惑と本気で思って言ってるなら、きちんと根拠を示せばいいだけ。
とんちんかなこといって、言い訳や逃げ口上ばかりじゃぁね。
135:131
16/07/26 22:20:42.77 Cu1ef78E.net
>>134
まず確認したいんだけど、x265に関する君の主張（根拠を示す気はゼロ）って以下の２つであってる？
他の人の意見と混ざってる可能性もあるし一応確認しておきたいんで、
違うなら修正してちゃんと示してほしいんだけど。
1. 2passABR（--bitrate --pass 2）について
1-1 同程度のビットレートでの画質や圧縮効率の違いを参考程度に調べるために
設定ごとに2passABRでSSIM等を調べて比較報告することは意味が無い。
1-2 2passABRではなく、VBR（--crf）でSSIM等を調べて比較報告するなら意味がある。
1-3 特にlittlepoxがDoom9で提案してる--tune animationの設定案は
VBR用の設定なので2passABRで調べても意味が無い。
2. Histogram("Luma")について
2-1 グレインの残り具合をわかりやすく比べて示すために
AvisynthのHistogram("Luma")で作った白黒画像を使ってはいけない。
一応こちらのこれまでの主張は以下ね。
ｽﾚﾘﾝｸ(avi板:947番)
ｽﾚﾘﾝｸ(avi板:162番)
136:名無しさん＠編集中
16/07/26 22:57:16.22 1jZzHbN0.net
まあ、なんというか噛みついたのは一人だけだから
そこまで気にしなくていいんじゃない？
137:名無しさん＠編集中
16/07/26 23:00:52.14 1jZzHbN0.net
レス消費してまで書くことじゃないけど
× 噛みついたのは一人
○ 噛みついてるのは一人
138:名無しさん＠編集中
16/07/27 09:49:01.58 39MhpLLI.net
>>136
>まあ、なんというか噛みついたのは一人だけだから
えっ？
139:名無しさん＠編集中
16/07/27 10:10:51.90 xltjvJiO.net
なんか微妙にかみ合わなくて困るが
2passでのSIMMなどの計測に噛みついたのが一人
>136は>135へのレス
140:名無しさん＠編集中
16/07/27 10:16:09.27 39MhpLLI.net
>>135
あと、なんていえばいいのか
オプションや画像について、初歩的なことから勉強したほうがいい
少なくとも俺は手取り足取り1から10まで、>>135が理解できるように説明するのは不可能と判断してるし、そんな気力も起きない
誰も説明してくれない時点で、自分で現実の自分を察せないと
141:135
16/07/28 19:33:12.32 VEHqQnFB.net
>>140
まあ説明は最初から全く期待してないから別にいいんだけど、
>>131に書いたとおり俺は君に触ってなかったので、
なんでもかんでも俺の仕業だ自演だと思い込むのだけはやめてほしいね。
142:名無しさん＠編集中
16/07/29 18:53:28.29 mYe7b9uo.net
>>141が最強の粘着に見える
143:141
16/07/29 19:51:06.19 H6YAKWZH.net
つい反応してしまった上に書いても無駄なことをだらだら書いてしまったことは反省してます。
すみませんでした。以後気を付けます。
144:名無しさん＠編集中
16/07/29 20:19:57.19 Q7JyuPn1.net
他所でやれ
145:名無しさん＠編集中
16/07/30 22:29:18.17 L+h4JH5U.net
>>120
暇潰しにネットを彷徨っていたらTrellisの検証記事で同じようなのを見つけた(結果はデフォが一番というオチだったはず
いざ張ろうと検索しても出てこないので記憶を頼りに報告だけ
だいぶ前に見たx265はスムージングがかかってるってカキコがずっと気になって
調べてたら「--no-strong-intra-smoothing」というオプションを発見
このオプションを偽色対策に使ってる人もいるみたいだから使って見ては？
146:名無しさん＠編集中
16/07/31 03:43:32.28 dZ7oPMUl.net
2.0+11を試してみたんだけど、--qpの範囲が0-51なのにqpmin/qpmaxが0/69なのは何故？
147:名無しさん＠編集中
16/08/08 20:22:00.67 J7N5kUNj.net
更新ないなぁ
148:名無しさん＠編集中
16/08/12 12:03:06.96 WxsCs4+s.net
自演君て、粘着されてると言うけど、レスしてないなら粘着されるはずもないのに。
粘着されてるのはそのレスをした人でしょ。あれれ。
粘着と言っていかにも自分はまとも感を出してるけど、チンプンカンプンなことを言ってるのは自分なことの自覚がなさ過ぎる。
それに対して、ツッコミが入ってる自覚もなさ過ぎる。
自分以外の人は、オマエのお母さんでも、幼稚園や保育園の先生でもない。
149:名無しさん＠編集中
16/08/13 02:23:38.39 8Q7RGPlH.net
更新とまってんな～
150:名無しさん＠編集中
16/08/13 16:01:15.80 ePZvheAq.net
>>146
52以降ってvbv-emargencyとかいう処理の時にしか使われないんじゃなかった？
151:名無しさん＠編集中
16/08/24 21:06:43.53 /dY6B0M/.net
更新再開したっぽいかな？
152:名無しさん＠編集中
16/09/03 14:13:04.34 xCzYHYPb.net
x265って拡張命令のせいか何なのかCPUがめちゃくちゃ熱くなるのな
153:名無しさん＠編集中
16/09/03 14:35:10.40 0drSjMFx.net
x264だと熱くならないの？
154:名無しさん＠編集中
16/09/03 15:19:26.70 VM6FlRtt.net
より効率的に使ってる感はあるな
x265エンコ中は外付けHDDへの転送が凄く遅くなる
（x264はそれより2～3割ぐらい早い
155:名無しさん＠編集中
16/09/03 16:54:50.98 xCzYHYPb.net
80℃超えるCPUでx264の時よりも5℃ぐらい熱くなる
156:名無しさん＠編集中
16/09/05 15:42:55.28 T+uZFTmJ.net
低解像度向けのチューニングオプション追加するんだね
157:名無しさん＠編集中
16/09/05 16:39:35.74 LbS7geGc.net
>>156
これ？
URLﾘﾝｸ(forum.doom9.org)
VideoLAN Dev Days 2016: Update on x265
URLﾘﾝｸ(youtu.be)
>Where Are we Headed ?
> (略)
> Several optimizations focusing on low bit-rate
> - Special 'tune low-res', tuning with smaller QG-size, etc.
> (略)
158:名無しさん＠編集中
16/09/06 21:25:03.00 WG9rPIk2.net
>155
温度高くなる方がCPUを使い切れている、って事はないか
159:名無しさん＠編集中
16/09/07 11:01:17.33 tjHl1Y/S.net
温度が高いのは単にAVX/AVX2命令使いまくってるからじゃなくて？
160:名無しさん＠編集中
16/09/10 16:18:58.82 3KXtFfuG.net
そうそう
タスクマネージャ上のCPU使用率が同じでもAVX2とかが使用されると実際の酷使度合いが全然違うみたいで
うちのi7 4770は定格より0.1V近く下げても時々99℃を超えてthermal throttlingが起きる・・・
ちなみにこの問題に関係するような話がこの記事の後半のAVXについての箇所に載ってた
URLﾘﾝｸ(pc.watch.impress.co.jp)
161:名無しさん＠編集中
16/09/11 10:20:30.23 M5WB8rMu.net
x264だと新命令でまだ伸びしろがあるか、もしくは相性が悪くて使いどころが少ない、といった感じか
まぁ、温度上がりすぎてクロック落とされるのでは問題ありだな
162:名無しさん＠編集中
16/09/11 11:02:31.58 +edLNe7y.net
再来年にはAVX512が使えるCPU出そうだけどどうなるんだろうな
163:名無しさん＠編集中
16/09/21 22:31:27.74 Qkyw4C7/.net
ずいぶん早いなスライスだけで終わりか
164:名無しさん＠編集中
16/09/21 23:50:36.79 hXlYwXOa.net
Merge with default; prep for 2.1
それほど開発進んでいるようには思えなかったけどもう近いうちに2.1出るんだね
165:名無しさん＠編集中
16/09/28 00:28:50.54 LSEBKFqM.net
2.1きたぞ
166:名無しさん＠編集中
16/09/28 12:50:43.95 VxvbltEW.net
Version 2.1
Release date - 27th September, 2016
Encoder enhancements
Support for qg-size of 8
Support for inserting non-IDR I-frames at scenecuts and when running with settings for fixed-GOP (min-keyint = max-keyint)
Experimental support for slice-parallelism.
API changes
Encode user-define SEI messages passed in through x265_picture object.
Disable SEI and VUI messages from the bitstream
Specify qpmin and qpmax
Control number of bits to encode POC.
Bug fixes
QP fluctuation fix for first B-frame in mini-GOP for 2-pass encoding with tune-grain.
Assembly fix for crashes in 32-bit from dct_sse4.
Threadpool creation fix in windows platform.
167:名無しさん＠編集中
16/10/01 08:36:48.35 ykahFpBD.net
なんでx265のqcompって0.5より下げられないんだろう？
もっと低い値で使いたいのに
168:名無しさん＠編集中
16/10/01 23:17:06.87 DyNihzpz.net
qcomp下げたら線が歪まなないか？
169:名無しさん＠編集中
16/10/02 02:19:12.84 t1a4GZR7.net
どういう線？
170:名無しさん＠編集中
16/10/02 09:00:33.52 YYEozq1W.net
線が歪むかどうかは完全にケースバイケースで
qcompを下げた結果むしろ大人しい場面の線が綺麗になることも普通にあるよ
現状の下限の0.5だと、騒がしい場面を基準にcrfを設定すると大人しい場面での画質がいまいちに感じてしまうんだよな
逆に大人しい場面を基準にcrfを設定すると騒がしい場面までやたら忠実にエンコされてサイズが肥大化しちゃって困る
171:名無しさん＠編集中
16/10/02 09:44:16.52 E9ldDBU0.net
俺は上限ビットレートを制限する派
元ソースより多く割り振っても意味ないし
デブロックフィルタ付きコーデックだからx264は12Mbps、x265は10Mbpsにしてる
172:名無しさん＠編集中
16/10/03 13:00:32.32 56jcz+S0.net
6Mbpsで試したらそこそこ目的を達成できたから、qcomp < 0.5が実装されるまではそのテクを使わせてもらって生きていくわ
173:名無しさん＠編集中
16/10/06 20:13:57.00 UxlWfRHg.net
つかぬ事をお聞きしますが、
x265はインタレ保持は出来るようになったのですか？
174:名無しさん＠編集中
16/10/06 20:25:12.91 W2tMKGUy.net
HEVCの規格に存在しなかったと思うので㍉
175:名無しさん＠編集中
16/10/06 22:23:17.21 UxlWfRHg.net
>>174
そうですか
ありがとうございます
176:名無しさん＠編集中
16/10/06 22:30:31.75 /fDcpTf9.net
>>174
H.265の規格にgeneral_interlaced_source_flagとかsource_scan_typeというのがあったり
x265にも--interlaceオプションがあるけど、それは関係ないの？
177:名無しさん＠編集中
16/10/06 22:36:33.78 0IgfUIeH.net
一旦フィールド分離してinterlaceオプションでエンコードすればよかったような
ただ正常に再生できる環境があるのかは謎
178:名無しさん＠編集中
16/10/07 06:07:20.90 bFnowcIA.net
>>177
フィールド分離方法kwsk
俺はインターレースソースをそのままx265の --interlace tff /bff オプション付けただけでエンコードして、
少し縞がでた状態になってるんだけど
179:名無しさん＠編集中
16/10/07 07:25:22.16 k7Mjdk2R.net
ぐぐれよそれくらい…
180:名無しさん＠編集中
16/10/07 12:45:09.69 /2zEQK8F.net
>>178
AvisynthのSeparateFieldsかな
フィールド分離しててもAviUtlのx265guiExじゃ多分うまくいかないから注意ね
181:名無しさん＠編集中
16/10/08 22:46:06.42 acB1Oyjg.net
HEVC使うんならインタレ解除してからエンコードする前提で考えるべきだ。
インタレ解除の品質とCPのバランスがいいPS4(PS3よりきれいに解除される)か最新のRadeonで解除してキャプチャーすべし。
182:名無しさん＠編集中
16/10/08 23:04:38.26 EHJ5enlD.net
PS4ってHEVC再生出来るの？
183:名無しさん＠編集中
16/10/08 23:24:23.51 ubLA7grF.net
ps4でインタレ解除したのをhevcエンコするって事じゃない
184:名無しさん＠編集中
16/10/08 23:57:06.64 pY2xbwxp.net
インタレ解除のためにキャプチャ・・・？そんな面倒なことする人っているもんなのか？
185:名無しさん＠編集中
16/10/09 00:31:19.00 GqZcZg6U.net
横から興味本位でSeparateFields()やって--interlace 1でエンコしてみたけど
出来た動画はmpc-hcでもvlcでもSeparateFields()でぺしゃんこになった映像がそのまま流れるだけだった
>>177の言うように再生環境が整ってないってことか
186:名無しさん＠編集中
16/10/09 00:47:23.90 zdE5+A6z.net
そもそも規格上正しいインターレース動画見かけたことないからよく分からないのよね
フィールド分離するっていうのも多分これで正しいだろうって程度だし
187:名無しさん＠編集中
16/10/09 01:59:16.04 GqZcZg6U.net
URLﾘﾝｸ(trac.mpc-hc.org)
ここに添付されてる動画（黄色い枠の下のAttachmentsのとこ）はベルリンの放送局が流したインタレHEVC動画を切り取ったものらしい
スレ主は「LAV filtersを使う別のソフトではちゃんと表示できたのにmpc-hcだと縦半分になっちゃう」って言ってるけど
ってことはインタレHEVC動画をちゃんと再生できるソフトが２年以上前から有るってことだな
188:名無しさん＠編集中
16/10/09 02:11:19.92 zdE5+A6z.net
URLﾘﾝｸ(trac.ffmpeg.org)
HEVCのリファレンス実装のhmなら正しくデコード出来るらしい
189:名無しさん＠編集中
16/10/09 02:19:35.95 zdE5+A6z.net
作り方が間違っている訳じゃなさそうだな
190:名無しさん＠編集中
16/10/09 11:04:21.51 1a6sgUco.net
rigayaさんのところを参考に自ビルドしようとしてるんだけど、Mercurialでのクローンでコケる
二回目の実行だと復元先 ''x265 は空ではありません」と注意されて中止
このMercurialはデフォルトではどこにディレクトリを作るんです？
191:名無しさん＠編集中
16/10/09 11:33:52.22 vheEQyvD.net
>>190
cd x265
hg pull
hg update
cd ../
192:名無しさん＠編集中
16/10/09 12:20:14.96 1a6sgUco.net
>>191
ｔｈｘ
ドライブを跨いだディレクトリ移動時は /d をつける超初歩的な事を忘れてたのが原因でした
193:名無しさん＠編集中
16/10/09 17:06:11.97 rgbkaPmJ.net
URLﾘﾝｸ(builds.x265.eu)
とうとうここ消えてしまった…
便利だったのに残念
っつか困った…
194:名無しさん＠編集中
16/10/09 22:27:18.19 dxlv3MaK.net
>>193
メンテとかじゃなくて消えたのかなあ
昼にはもう繋がらなかったわ
195:名無しさん＠編集中
16/10/10 00:53:58.93 xgHs9gIA.net
>>193-194
こっちだと見れる
URLﾘﾝｸ(open.lolicon.eu)
196:名無しさん＠編集中
16/10/10 06:04:45.32 dLZ1/K2w.net
マルウェアサイトだな
197:名無しさん＠編集中
16/10/10 06:35:41.27 BhzSUR9V.net
マルウェアの警告とは違うような
他サイト用(おそらくbuilds.x265.eu用？)に発行されたセキュリティ証明書を使用してるって警告じゃない？
198:名無しさん＠編集中
16/10/10 09:43:29.66 XYI2imEj.net
open.lolicon.eu は不正なセキュリティ証明書を使用しています。
この証明書は builds.x265.eu にだけ有効なものです。
エラーコード: SSL_ERROR_BAD_CERT_DOMAIN
199:名無しさん＠編集中
16/10/10 10:44:49.25 F6sI260l.net
URLﾘﾝｸ(msystem.waw.pl)
結局ここ使わせてもらうことにした
200:名無しさん＠編集中
16/10/13 16:25:16.83 eYTpGBOz.net
--scenecut ってまったく機能してないよねぇ？
preset medium で--scenecutの値を40→100→900と変えてエンコしてみたんだけど出力結果が全部同じになった
テストに使った動画には人の目に分かるシーンチェンジが19箇所あるんだが、それを察知してキーフレを挿入してくれた箇所は1箇所のみで
それ以外はシーンチェンジを無視してkeyintのデフォ値の250フレームごとに盲目的にキーフレが挿入されてるだけだったわ
Version 2.1のチェンジログにSupport for inserting non-IDR I-frames at scenecutsって書いてあったから改善に期待したんだが最新版でもダメ
ちなみにx264の方はちゃんと--scenecutの値に応じてフレーム構成が変化してくれた
201:名無しさん＠編集中
16/10/13 18:08:10.48 BvafylIQ.net
なんか前にもそんなバグがあったな
202:名無しさん＠編集中
16/10/15 00:16:40.11 rXcDhk32.net
>>200
それ、ちょっと気になってたから0 (たぶん無効)と50でやってみたらサイズが変わった
だからIフレーム自体は適切な箇所に挿入されてると思う
（x264みたく挿入しまくりはしない感じ）
203:名無しさん＠編集中
16/10/15 08:54:18.17 1fX3du3l.net
>>200
メーリングリストで挙動を質問してみたら
204:名無しさん＠編集中
16/10/16 00:23:34.99 9IsJK5rz.net
それはちょっとハードルが高すぎる
205:名無しさん＠編集中
16/10/17 09:20:22.13 mCoEoNET.net
cpuが100%行かないんだけどそんなもん？
i7 3770 メモリは16GB
pmodeとpmeは入れても自分のCPUじゃ効果無いかと思って使ってないんだけど入れたほうが良いかな
206:名無しさん＠編集中
16/10/17 15:43:02.58 rTFfP7wa.net
>>205
CPUが100%行けばいいってもんじゃないと開発者側の言葉がどこかにあったと思う。
CPU使用率じゃなくて純粋にエンコード速度だけみてりゃOK的な事だったような。
207:名無しさん＠編集中
16/10/17 15:59:11.90 mkOviUGi.net
そういうものなのか！ありがとう！
x264使ってた時は100%が当たり前だったからそういうものと勘違いしていた
エンコ速度は・・・すごく遅いｗｗｗ
だから一生懸命仕事してくれているのだろうと思うことにする
208:名無しさん＠編集中
16/10/17 16:11:04.38 mkOviUGi.net
pmode入れてみたら80%位までは行くようになった
余裕があるっていう感じではないからpmeはちょっと迷うな
機会が有ったらpmeも付けてみて速度比較してみようと思います
ありがとうございました
209:名無しさん＠編集中
16/10/17 20:17:27.74 mkX7gmVh.net
CPU100%行かない場合はどこがボトルネックになってるんだ？
210:名無しさん＠編集中
16/10/17 20:18:31.60 XndnkurR.net
メモリアクセスとか
211:名無しさん＠編集中
16/10/17 20:24:22.54 DICNZjN0.net
無圧縮の映像で読み込みが間に合わないとか
エンコード前のフィルタ処理とか
212:名無しさん＠編集中
16/10/18 09:17:06.90 1fXUbBxK.net
メモリアクセスはCPU使用率にカウントされる。
読み込みが間に合わないのもあるかもしれないけど、
フィルターかけないで転送も間に合ってる場合でもそうなるのは
おそらくスレッド間同期待ちでしょうな。
短い同期待ちはビジーループでCPUを使用するけど、
ある程度待ちが長くなるとCPUを使用しないモードに移行してOSのスケジューラーに制御を任せる。
マルチスレッドアプリってのはスレッドがてんでバラバラに動けばいいというものではなく、
同期して協調しながら動くものだ。
213:名無しさん＠編集中
16/10/18 09:26:18.88 iXokjJQD.net
>>212
マルチスレッド化で、なんとかの法則（忘れた）の壁にぶち当たってると開発者が言ってた気が
214:名無しさん＠編集中
16/10/18 09:57:55.47 T3u81CcT.net
マルチスレッド化じゃなくSIMDが占める時間がどうこうって
215:名無しさん＠編集中
16/10/18 09:58:28.67 T3u81CcT.net
いうアムダールの法則？
216:名無しさん＠編集中
16/10/18 12:40:00.08 vdr0U0/n.net
分割できるタイルの数には限りがあるんだから余るようなら2つ同時に走らせればいいでしょ
217:名無しさん＠編集中
16/10/18 20:16:28.32 usHrv1K0.net
x265のcrfでエンコした動画をBitrate Viewerに放り込んでもCodec not foundで見れないのですが何か他に良いツールはありますか？
218:名無しさん＠編集中
16/10/18 20:20:57.27 mwW3uiyu.net
>>217
rigayaの日記兼メモ帳 CheckBitrate
URLﾘﾝｸ(rigaya34589.blog135.fc2.com)
219:名無しさん＠編集中
16/10/18 21:04:14.20 usHrv1K0.net
>>218
助かりましたありがとうございます！
220:名無しさん＠編集中
16/10/18 21:22:12.77 usHrv1K0.net
本当にx264の半分のビットレートで同等の画質だとびっくりしました（自分の眼で見た限り）
221:名無しさん＠編集中
16/10/19 01:14:12.55 YFXzqss9.net
目眩にも程があんだろ
222:名無しさん＠編集中
16/10/19 01:28:25.67 PxXlpT/K.net
そういう眼なのでまぁ仕方ないですね
静止してコマ送りでもしながら見比べないと分からないので
もっともそんな鑑賞の仕方は普段絶対しないですがｗ
223:名無しさん＠編集中
16/10/19 01:43:07.59 mOH8YNRk.net
うちも病的に録画しまくる親のためにx265で640x360にしてエンコードしてるが
x264からビットレート半分ほどにしても全く問題なく見ていて助かってる
224:名無しさん＠編集中
16/10/19 08:54:42.83 PW9lC18s.net
実際近い画質にしたいならビットレート抑えるにしても半分じゃなくて7割程度までに留めた方が
でも5割でも気にならない人も多そうだな
225:名無しさん＠編集中
16/10/19 09:12:12.96 GcIL4Guh.net
求める画質にも人それぞれだからね
226:名無しさん＠編集中
16/10/19 18:14:11.67 JmGvqfPq.net
動きの激しい映像はx264よりあんまり減らないよね
227:名無しさん＠編集中
16/10/24 13:06:20.83 uq8ctnJu.net
軽い設定にするとリンギングというかゴーストというかエッジ周辺にそんな模様が浮き上がりやすいような
228:名無しさん＠編集中
16/10/30 20:19:33.98 LXD3bx3c.net
グレインが消えるのは何とかなりませんか？
psy-rdoqを盛れば消えませんか？
229:名無しさん＠編集中
16/10/30 21:31:12.51 Htbc8Yyh.net
tuneのgrainを使うとか
バカみたいに膨れるけど
230:名無しさん＠編集中
16/10/30 21:56:56.06 w9pmDIzm.net
こんな感じだな
x265 2.1+028
Xiph.orgのStockholm
--preset slow --crf 18
encoded 604 frames in 54.59s (11.06 fps), 8841.46 kb/s, Avg QP:27.62
SSIM Y:0.924460 U:0.957868 V:0.955896 All:0.935268 (11.888781)
--preset slow --tune grain --crf 18
encoded 604 frames in 148.53s (4.07 fps), 【34693.46】 kb/s, Avg QP:24.04
SSIM Y:0.947751 U:0.956224 V:0.954316 All:0.950258 (13.032736)
--preset slow --crf 13.4
encoded 604 frames in 113.93s (5.30 fps), 【34638.59】 kb/s, Avg QP:23.18
SSIM Y:0.955600 U:0.972801 V:0.967569 All:0.960461 (14.029775)
231:名無しさん＠編集中
16/10/31 08:59:25.98 aVd7HkkT.net
本物グレインを取り去ったあと、
圧縮の効く擬似グレインのようなものを
付ける機能はないものか
232:名無しさん＠編集中
16/10/31 18:09:29.71 BddUJOgx.net
一口にグレインといっても主に空間的にザラザラなやつと時間的にも非常にザラザラしてるやつとでは扱いが違ってくる
233:名無しさん＠編集中
16/11/02 18:21:51.31 sg5G6GHh.net
>>228
グレインのボケや消失を防止したい場合は真っ先にSAOをオフるといいよ
で、平坦部のザラザラが維持されるようにaq-strengthを1.2や1.3にしてpsy-rdを3や4まで上げる
こうすると処理量やレートを激変させずにとりあえず空間的なザラザラが保持されるようになってコスパがとてもいい
rdoqが出番になるのはこれに加えてグレインのさらさら流れるような時間的性質も保持したいという場合
そういう時はrdoq-level=2、psy-rdoq=50とかにしてみて、物足りなかったらaq-strengthとpsy-rdを更に盛るといい
psy-rdoqは50が最大値だけど10とかに下げても大差ないから弱めたい時は4とか2とかその辺の値に
これでもまだグレインが保持できない場合、その原因はレートの絶対的な不足だから、
あとはcrfを下げるなりして目指すグレイン感が得られるまでレートを盛っていくようにする
ちなみにpresetやtuneの類は基本的にあんまり当てにしないほうがいいよ
234:名無しさん＠編集中
16/11/02 18:52:56.39 +gFPmWC5.net
昔はx265でグレイン保持は無理って言われてたけど今は色々やりようがあるのかな
235:名無しさん＠編集中
16/11/02 20:39:07.24 Io06CM0X.net
>>233
なるほど aq-strengthを上げてsaoをoffですね。
以前psy-rdoqは10以上まで盛ったことが有るのですが変化をあまり感じなかったので戻していました。
psy-rdを3や4にしても処理量やレートがあまり変わらないのであればちょっと盛って様子を見てみたいと思います。
psy-rdoqに関してはソース次第ということでしょうか。これも様子を見たいと思います。
このページ（URLﾘﾝｸ(x265.readthedocs.io)）の"Film Grain"を見ると--sao 0 psy-rd 4.0 psy-rdoq 10(と+α)になっていますね。
aqやcutreeを切る勇気は無いのでそのあたりは切らずに、機会が有ったら --sao 0 と psy-rd 4 を試してみたいと思います。
ありがとうございます。
236:名無しさん＠編集中
16/11/03 19:52:24.95 1TzsPPOa.net
RC-grain「そんな…」
237:名無しさん＠編集中
16/11/05 14:14:28.54 O/P24WqT.net
報告された元々のバグは修正されたみたいだけど、知見を得たとのことなので転載
URLﾘﾝｸ(twitter.com)
muken@黄前久美子猥褻妄想Bot ?@OumaeKumikoBot 11月2日
x265で
--no-opt-qp-pps
--no-opt-ref-list-length-pps
しないとMP4にした時、面倒くさいことになるという知見を得た。
x264での結合する時は--stitchableを指定しないといけないやつみたいなの。
238:名無しさん＠編集中
16/11/05 15:24:50.73 Qlzasom9.net
面倒くさいって具体的にはどうなるの？
239:名無しさん＠編集中
16/11/05 15:30:37.15 ONNX8TRZ.net
何も困ってないけどなあ
240:名無しさん＠編集中
16/11/05 17:52:14.03 cNENgTT4.net
全く意味が分からん
241:名無しさん＠編集中
16/11/05 18:01:51.59 1wza3xPH.net
事の発端はL-SMASHでh265をmuxしたらLAVFiltersで再生出来ないmp4が出来たってバグ報告ね
オプション付けたほうが安全なストリームが出来るんだろう多分
242:名無しさん＠編集中
16/11/05 18:19:11.94 H0Re9Vmy.net
L-SMASHとLAVFilters、どっちの問題なの？
243:名無しさん＠編集中
16/11/05 18:21:30.62 H0Re9Vmy.net
それかx265の問題かもしれんし、その事象の話だけ聞くとどのプロジェクトの問題なのかわからん
244:名無しさん＠編集中
16/11/05 18:39:01.91 OHNoCusZ.net
L-SMASH使ってるが一度もそんなファイル出来たことないわ
245:名無しさん＠編集中
16/11/05 18:48:02.33 1wza3xPH.net
URLﾘﾝｸ(twitter.com)
echo.2ch.net/test/read.cgi/avi/1462270195/237- …
L-SMASH, ffmpeg両方に問題があった。前者は修正済み。
一般向けに説明すると、キーフレームごとにコーデックのパラメータがIDが同じまま変わる。これをMP4に入れたものには対応していない実装があるので、途中で映像が壊れる。
URLﾘﾝｸ(twitter.com)
x265でエンコードする時に--no-opt-qp-pps --no-opt-ref-list-length-ppsをつけるとキーフレームごとにコーデックのパラメータが変わることが無くなるので、
MP4に入れても多くの実装で再生できる。これらはオーバーヘッド抑制の無効化オプション。
246:名無しさん＠編集中
16/11/05 19:03:17.71 +zlnPhqR.net
一般人はL-SMASHを最新のにすればいいの？
最新のにした上で --no-opt-qp-pps --no-opt-ref-list-length-pps をつければいいの？
247:名無しさん＠編集中
16/11/05 19:05:09.45 Qlzasom9.net
最新にするならそのオプションは要らないって意味かと思った
248:名無しさん＠編集中
16/11/05 19:05:47.67 1wza3xPH.net
URLﾘﾝｸ(twitter.com)
なんか、最近になってx265側で実装されたものらしく(私はもうx265追ってません。メーリングリストは見てますが)、
以前は大丈夫だったけど、x265のオーバーヘッド最適化実装によって、いつからか壊れるようになったということです。
URLﾘﾝｸ(twitter.com)
x265で--no-opt-qp-pps --no-opt-ref-list-length-ppsを付けないのであれば、L-SMASHのmuxerはrev1416以降をお使い下さい。
それより前はmux時に3種類目以降のコーデックパラメータでデータが壊れます。
249:名無しさん＠編集中
16/11/05 19:19:10.83 OHNoCusZ.net
1384使ってるけど何の問題もなく再生出来るんだが
だから何言ってるかサッパリだわ
250:名無しさん＠編集中
16/11/05 19:27:38.23 1wza3xPH.net
>>249
毎回必ずおかしくなるんじゃなくて稀におかしくなるんじゃろ
251:名無しさん＠編集中
16/11/05 19:33:52.49 OHNoCusZ.net
もう何千とファイルあるけど1つもないなぁ
なんじゃそりゃと
252:名無しさん＠編集中
16/11/05 19:37:31.80 1wza3xPH.net
>>251
問題が発生する可能性があるのは9/28以降のx265らしい
253:名無しさん＠編集中
16/11/05 19:46:18.18 OHNoCusZ.net
2.1+11くらいかな
2、300ファイルが対象だけど問題ないなぁ
問題あったら最新のmuxer使ってみるよ
ありがと
254:名無しさん＠編集中
16/11/05 19:52:13.05 +zlnPhqR.net
まさにその2.1+11使ってたわ…。
10個くらいだからエンコし直すかな。
さっきはsage忘れスマヌ。
255:名無しさん＠編集中
16/11/05 20:46:36.02 3ox3b5pw.net
うわ・・・最近動画再生中に映像だけ止まって狂ってたやつあったけどこいつが原因だったんか...
L-SMASH ビルドしてくるか。MUX 前なんて消しちゃってるしエンコし直しだるいな
256:名無しさん＠編集中
16/11/05 20:50:08.89 wwCJHwe3.net
16^2
257:名無しさん＠編集中
16/11/05 20:53:33.03 3ox3b5pw.net
速効ビルドしてきたがこれなら大丈夫か。
muxer.exe --version
L-SMASH isom/mov multiplexer rev1417 bd95444
Built on Nov 5 2016 20:48:21
Copyright (C) 2010-2015 L-SMASH project
258:名無しさん＠編集中
16/11/05 21:31:58.34 O/P24WqT.net
>>255
ffmpegに修正が取り込まれたら再生できるようになるんじゃない？
スマホかとPC以外では怪しいかもしれないけど
259:名無しさん＠編集中
16/11/05 21:54:07.79 3ox3b5pw.net
>>258
俺環では mux は L-SMASH でプレイヤー側のデコーダーは LAV。
これで発生しますた。FFMpeg は全くからんでないんで、今回ビルドした r1417 で解決しているらしいから
またちょっと時間出来たらエンコして試さないとです。
260:名無しさん＠編集中
16/11/05 21:59:55.69 O/P24WqT.net
>>259
LAVFilterはffmpegをエンジンとして使ってるそうだよ
元ソースがあるなら推奨コマンドラインつけて再エンコが確実だろうね
261:名無しさん＠編集中
16/11/05 22:16:33.48 Qlzasom9.net
バイナリエディタでも修正できるのか
262:名無しさん＠編集中
16/11/06 00:00:24.51 Fw8ZOVy1.net
>>260
Oh... まじですか!
って初耳過ぎてわらってしまったｗ
「LAV Filters - ffmpeg based DirectShow Splitter and Decoders」
確かに書いてあった…
ちょっと恥ずかしいレスをしてしまったようだ。情報thx
263:名無しさん＠編集中
16/11/06 00:03:18.74 Ieu4V1LX.net
オーバーヘッド最適化とやらがどのくらいファイルサイズに影響が出るのか確認しようと思って
2.1+45で--no-opt-qp-pps --no-opt-ref-list-length-pps付けた場合と付けなかった場合とで
ファイルサイズ比較してみたんだけど、サイズどころかMD5も一緒のファイルが出来てしまって意味不明だわ。
最近のリビジョンだと標準でオーバーヘッド最適化するのやめたのかな。
それともオーバーヘッド最適化は毎回起きる訳じゃないのか？よく分からん。
264:名無しさん＠編集中
16/11/06 09:59:31.72 zSBWy7Ib.net
バイナリをほんの一か所修正するだけで問題回避できるらしいし
再生不可ファイルが量産されてるわけでもないから
常に作動するものではないんだと思う
265:名無しさん＠編集中
16/11/06 16:38:19.27 D3UB232k.net
自分もバイナリエディタで2.1+45でエンコした動画を開いてみたけど、--no-opt-qp-pps --no-opt-ref-list-length-ppsは付けていないのに"0C"ではなく"0F"だった。
元々付けておくに越したことは無いだろうけど、付けないからといって必ずしも有効になるものでは無いのかも。
266:名無しさん＠編集中
16/11/07 09:54:40.59 ELUcnBTe.net
琵琶
267:名無しさん＠編集中
16/11/11 17:10:10.87 i1JaPs2C.net
上にl-smashのmuxerの話が出てたからスレチなんだけど書かせて
muxerで指定したファイルがないと異常終了するの修正して欲しい
remuxerはエラー表示するだけ
結構前からのバグでバッチで流すのに面倒というか初歩の初歩かと
268:名無しさん＠編集中
16/11/11 17:46:06.94 WC7Eweo0.net
>>267
バッチならif not exist ファイル名 echo ファイルねーぞ
みたいなこと出来るでしょ
事実上の専用スレと化してるところあるからそこで報告すると良い
269:名無しさん＠編集中
16/11/11 17:51:43.75 tVtUYmUR.net
専用スレここね
VFRmaniac Vのまにまに x264gui
ｽﾚﾘﾝｸ(avi板)
270:名無しさん＠編集中
16/11/11 18:05:14.53 0PzYxV7m.net
ファイル名決め打ちでやってるから止まってくれた方がありがたい
271:名無しさん＠編集中
16/11/12 10:29:05.00 fV9ve7RR.net
>>267
それが正常動作じゃ？
272:名無しさん＠編集中
16/11/12 11:03:11.25 POYJ6b0e.net
頭大丈夫か？
273:名無しさん＠編集中
16/11/12 13:16:38.53 TbCKB4iv.net
異常終了ってのが、リターンコードが0以外の時という意味なのか、クラッシュするという意味なのかが重要だしな
今回は後者の方だからまとめてVまにスレへ報告案件かな 俺は面倒だからしないが
274:名無しさん＠編集中
16/11/13 14:12:09.99 /Gws/ehs.net
通常、異常終了はリターンコード0以外を意味する
275:名無しさん＠編集中
16/11/13 14:22:36.39 1jrwOjNm.net
余程悔しかったとみえる
276:名無しさん＠編集中
16/11/13 16:35:27.68 E2JJ5gPa.net
>>274
OSから見りゃそれは正常終了でしょ
277:名無しさん＠編集中
16/11/14 20:33:06.96 ghstPO5Z.net
なんか、必死だな
また、変なのが居座り始めたか
278:名無しさん＠編集中
16/11/15 02:46:48.83 dwzry2bh.net
頭に異常がありそうだな
279:名無しさん＠編集中
16/11/15 07:16:16.05 WN0Kqz+9.net
クラッシュする動きが正常とか久々笑った気がする
280:名無しさん＠編集中
16/11/15 07:23:15.84 9eO0nhwn.net
2.1+45で ―no-opt-qp-pps --no-opt-ref-list-length-pps を付けてエンコした動画
(L-SMASHは1417)をiPhone6のvlcで再生したら、シークした時なんかに画像が
乱れるのは件の問題？
それとも別に何かの原因があるのかな。
時間と体力が無いのでオプション有無・x265の他のバージョンは試してないのですまん。
最新のバージョンにこだわる必要はないのだけど、どのみちこれからのバージョンで
問題が出ないようにできないと意味無いので…。
281:名無しさん＠編集中
16/11/15 09:49:48.54 DYmHGSPu.net
Bフレームから再生するようになって
再生できないだけじゃね
282:名無しさん＠編集中
16/11/15 10:19:18.26 W4gBca1U.net
>>279
えーとっ、・・・
まぁ、がんばれや
283:名無しさん＠編集中
16/11/20 15:37:24.86 6HNeGOdZ.net
オプション残しすぎ
バカじゃねえの
284:名無しさん＠編集中
16/11/23 21:47:44.60 9wBskvPB.net
2.1+55あたりからMediaInfoで見るとエンコードライブラリの設定が異様に増えてる
この中のcpuidって世界中どのCPUでエンコしたかって特定できるような値なんだろうか？
285:名無しさん＠編集中
16/11/23 22:11:20.50 IEPfvm01.net
>>284
へ？そうなの？まぁ、時流には合っている気がしないでもない。
カスペルスキーも何か録画やエンコに干渉している気がするし、
もうエンコ趣味も下火なのかもな・・・
286:名無しさん＠編集中
16/11/23 22:36:46.62 P3O2s+zt.net
>>284
>>285
CPUが使用できる拡張命令を取得してそれをHEVCストリームに書き込んでるんじゃないのか？
大量に書き込まれる情報がウザいなら--no-infoで消えるはず
287:名無しさん＠編集中
16/11/24 01:46:34.66 31EXJrXJ.net
確かにえらい増えたな。このコミットか・・・？
URLﾘﾝｸ(bitbucket.org)
■2.1+28（増える前）
wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 /
merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 /
no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra /
no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=1 / scenecut=40 /
bias-for-scenecut=0.05 / rc-lookahead=20 / lookahead-slices=0 / bframes=4 / bframe-bias=0 / b-adapt=2 /
ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 /
cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / log2-max-poc-lsb=8 / limit-tu=0 /
no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh /
rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
288:名無しさん＠編集中
16/11/24 01:48:14.93 31EXJrXJ.net
■2.1+55（増えた後）
cpuid=******* / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 /
input-csp=1 / input-res=640x360 / interlace=0 / total-frames=11 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 /
no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers /
open-gop / min-keyint=1 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 /
lookahead-slices=0 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp /
max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / signhide / no-tskip /
nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 /
no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb /
no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra /
no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine /
analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 /
stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree /
zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 /
videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 /
max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 /
opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05
デフォ値エンコだと上のような感じだけど、--master-displayとか指定したら更に増える。
289:名無しさん＠編集中
16/11/27 13:23:12.40 4QhCpSQH.net
前スレ556で出てたLAVの12bitYUV4:4:4→RGB変換の問題が修正されてた。
ｽﾚﾘﾝｸ(avi板:556番)
URLﾘﾝｸ(forum.doom9.org)
URLﾘﾝｸ(forum.doom9.org)
290:名無しさん＠編集中
16/12/01 21:51:12.63 q0+CbGOi.net
SEA motion search Implementation
URLﾘﾝｸ(bitbucket.org)
> SEA is similar to FULL search; a three step motion search adopted from x264:
> DC calculation followed by ADS calculation followed by SAD of the passed motion vector candidates,
> hence faster than Full search.
291:名無しさん＠編集中
16/12/03 03:39:40.76 wNivIf5F.net
starからseaに変更したらSSIM若干アップ、容量若干ダウン、エンコ時間約1.9倍、
エンコ中のメモリ使用量が1.6倍になった
エンコ時間さえ気にしなければメリットしかなさそうだが、詳しい計測は他の人に頼む
292:名無しさん＠編集中
16/12/03 09:23:17.48 f4+EyPSe.net
猫さん曰くmeはsubmeより重要とのこと
293:名無しさん＠編集中
16/12/03 09:34:26.31 sgVyHdAt.net
どっちも重要だわ
俺のへっぽこpcで現実的なのはumh
新しいのも重い
294:名無しさん＠編集中
16/12/03 10:03:46.35 f4+EyPSe.net
star結構いいで
295:名無しさん＠編集中
16/12/03 10:54:48.61 y96N7nOo.net
そういえばumhってプリセットには使われてないんだな・・・
296:名無しさん＠編集中
16/12/03 20:00:26.83 EduarGk9.net
x264だとsubmeは5と7以上を低めのビットレートで揃えて試したときは
ssimがほんの少しだけしか良くならなかったけど
実際に見て比べたときは、映像上で移動しているものの後方に残る嫌な感じの残像が簡単に気付けるぐらいには減った
x265はあまり試してないから断言はできないけどどちらも重要なものだと思う
297:名無しさん＠編集中
16/12/03 20:13:26.09 f4+EyPSe.net
勘違いさせたかもだけど
submeはあくまでmeのsub（sub）なのでmeを犠牲にしてsubmeを上げるのはよろしくないってことで
submeの意味がないとかじゃないからね
*ちなみにx264での解説ね
298:名無しさん＠編集中
16/12/04 22:17:43.95 KCxOpwfA.net
rigayaさん今年もz265速度レビューに取り掛かってるころかな・・
今年終盤ごろから開発スピードが落ちたけど、もう画質・速度的に煮詰まりつつあるんだろうか
299:名無しさん＠編集中
16/12/05 21:58:13.33 GP5OuD+v.net
開発チームが変わったのもあるんじゃないかと思ってる
2.0を境に変わってないか？
300:名無しさん＠編集中
16/12/05 22:26:19.92 4Gofrz16.net
そうなの？
そういう内部状況はまったく把握できてないんだよね
（画質などが）良くなるならwelcomeなんだけど、どうなんだろう
301:名無しさん＠編集中
16/12/06 06:11:18.47 Ibls3FNn.net
x265とx264とVLCって作っている団体が同じという認識で合ってる？
302:名無しさん＠編集中
16/12/06 09:55:40.26 MdXhFAyu.net
それは違うんでなかろうか
x265はmultiwareとかく企業の開発だし（過去形？）
303:名無しさん＠編集中
16/12/08 22:47:00.08 mFOhFTsA.net
Forumの方も更新をただ伝えるだけのクッソつまらない書き込みしかないな
304:名無しさん＠編集中
16/12/09 09:12:06.56 MFFXt1i2.net
x264とx265、どうして差がついたのか…慢心、環境の違い
305:名無しさん＠編集中
16/12/09 10:00:47.02 qFHbu3MZ.net
x264のときはHD環境で使える唯一無二のコーデックだったからね
4kならまだしもHDならx264もまだまだ現役だし
306:名無しさん＠編集中
16/12/09 11:11:48.01 XOto06Rc.net
GPU内のHEVCハードエンコ機能もGPGPUのエンコもx265もWebMも全然パッとしないよね
Webブラウザで再生対応すれば普及率とか変わるかもしれないけどさ
307:名無しさん＠編集中
16/12/09 11:25:05.07 n+teo9zV.net
どういうのがパッとしてるって思うの？
308:名無しさん＠編集中
16/12/09 11:35:24.54 2WSelBGc.net
パッとエンコが終わるとか？
309:名無しさん＠編集中
16/12/09 12:07:04.64 I56VyL4x.net
x265とVP9どっちが普及するかって事でしょ
310:名無しさん＠編集中
16/12/09 12:24:49.88 2WSelBGc.net
H.264フルHDは今じゃどのソフトどの機器でも対応してる感じだけど
H.265とVP9はまだまだって感じはするね
311:名無しさん＠編集中
16/12/09 17:13:09.69 mA0vsZME.net
パッとするも何もx265自体ができてそんなに経ってないんだから無理もない
h264もどれくらい時間がかかってると思うんだ
h264の高速化は無理という判断で地デジはMPEG2になったというのに
312:名無しさん＠編集中
16/12/09 17:29:20.57 qFHbu3MZ.net
これはまた盛大に的外れなカキコしましたな
313:名無しさん＠編集中
16/12/09 17:50:04.87 oVcYYDQj.net
お前も何でここにいるの？
314:名無しさん＠編集中
16/12/09 18:32:01.23 XOto06Rc.net
争えー争えー
315:名無しさん＠編集中
16/12/09 18:32:18.83 6ERm07FD.net
あ？
316:名無しさん＠編集中
16/12/09 22:05:28.55 PsVkxrT9.net
もう俺の画質や圧縮率の需要はx264で満たされがちだなぁ 興味あるから情報は仕入れてるけど
他にもそんな人はいるんじゃない？
317:名無しさん＠編集中
16/12/10 01:52:12.27 ZOpFP1/6.net
俺は264には二度と戻る気がしないわ
265は圧縮再生負荷にまだ難があるけどそれを補って余りあるほど画質的なアドバンテージが大きい
318:名無しさん＠編集中
16/12/10 02:34:31.96 o26KpScA.net
画質はそんな変わらんよ
少なくともh264の半分のrateで同画質は嘘っぱち
次世代放送総BSフジ可不可避マジかよって感じ
319:名無しさん＠編集中
16/12/10 04:44:28.62 ZOpFP1/6.net
＞半分のrateで同画質
画質がボロボロになりだす低レート領域ではあながち嘘でもないでしょ
HDサイズに対して数Mbpsぐらいの中レートだと265の方が格段に高周波成分が残りやすくてキリッとした画質を得やすいから好き
単純比較はできないけど同程度の画質なら264に比して2/3ぐらいの容量に抑えられるし
320:名無しさん＠編集中
16/12/10 05:56:04.96 o26KpScA.net
VP9にしろx265にしろアドバンテージあるの高周波だけじゃんよ
そこは流石に進化を実感できますよ
しかし低周波成分がボロボロなのは無視できない
321:名無しさん＠編集中
16/12/10 06:51:56.48 okv09ezu.net
まぁ好きな方使えばいいじゃん
俺はx265の情報は追ってるけど、画質圧縮率エンコ速度のバランスが個人的に優れていると思っているx264を普段使ってるし
322:名無しさん＠編集中
16/12/10 10:42:37.68 mqT9Ckpn.net
本人が求めるレート、サイズによる
エンコでサイズを極力減らしたい、でもある程度画質を維持したいならx265がいい
逆にある程度サイズ大きくても劣化を全く感じないくらい画質を維持したいならx264がいい
323:名無しさん＠編集中
16/12/10 10:46:45.60 mqT9Ckpn.net
>>319
だーね
低レートならx265の圧勝
324:名無しさん＠編集中
16/12/10 10:58:02.12 oIFwMMIh.net
>>320
それを触るのがAQでしょ
325:名無しさん＠編集中
16/12/10 10:58:05.39 CP4JH5wZ.net
低レートてどのくらいのこと言ってる？SD以下用?
326:名無しさん＠編集中
16/12/10 11:23:06.28 oIFwMMIh.net
>>325
素で聞いているのか？それは
327:名無しさん＠編集中
16/12/10 11:24:30.95 hfDMjhMi.net
使いこなせない人の集まりにしか
328:名無しさん＠編集中
16/12/10 11:54:28.61 mqT9Ckpn.net
>>325
俺の感覚だとサイズが元動画の十分の一より下だったら低レート
329:名無しさん＠編集中
16/12/10 12:50:40.72 oIFwMMIh.net
それ円盤ソースにしか当てはまらないんじゃ・・
330:名無しさん＠編集中
16/12/10 15:22:19.58 0Hw2hWvG.net
>>329
お前ビデオカメラとか使ったことないの？俺はないけど
331:名無しさん＠編集中
16/12/10 15:28:22.65 vR972O2D.net
x264でエンコしたよりファイルサイズ小さくなっても俺の眼では品質的な違いは分からんしx265にしてる
x264の半分まで行かないにしても60%位で見分けなんてつかないし一々見比べようとも思わない
332:名無しさん＠編集中
16/12/10 15:46:04.52 wOCjATgv.net
膵臓やられてるかもしれないから病院行ってこいよ
333:名無しさん＠編集中
16/12/10 16:02:45.36 3pKg9iYN.net
それお前だろｗ
334:名無しさん＠編集中
16/12/10 16:04:05.76 CP4JH5wZ.net
>>326
そうだよ。定義によってレートは変わる。
335:名無しさん＠編集中
16/12/10 16:15:29.76 oIFwMMIh.net
>>330
ああ、なるほどビデオカメラとかスマホだと結構ビットレート増やせるね
自分は動画とか写真の品質指定を真っ先に下げるから思い浮かばなかったは
336:名無しさん＠編集中
16/12/10 16:23:48.12 IfuKTrbx.net
crf30くらいの低ビットレートだとx265が優位
でもcrf20くらいだと期待より差が出ない感
337:名無しさん＠編集中
16/12/10 17:30:52.55 oIFwMMIh.net
フォーラムや過去の2chでの感じではx264だと22～24、x265だと22～23で低ビットレート扱い
それほど高画質を求めなければ十分なレベルだとは思うんだけどね
個人的な経験則ではx264 crf24とx265 crf 22.5で同じような画質でファイルサイズはx265が一回り小さくなる感じ
ちなみにx265でvrf22以上だとqcompを0.7ぐらいに上げないと副作用が強く出た（テスしたのはver.1.9の終わりぐらい）
338:名無しさん＠編集中
16/12/10 17:47:47.39 JDYP2xGK.net
スカイレイクのハードエンコは速い？
339:名無しさん＠編集中
16/12/10 18:28:03.87 Wi2nebjz.net
x264はcrf20くらいでやってるなぁ
アニメTSだけど
340:名無しさん＠編集中
16/12/10 21:29:45.79 nHscE/t2.net
--aq-mode 0 にしてもコマンドライン上でもMediaInfoでもaq-mode=1になるんだけど
どうなってるの？
341:名無しさん＠編集中
16/12/10 21:40:42.04 PDVwwQYw.net
使ってるバイナリとか、指定してるコマンドくらい書けよ
342:名無しさん＠編集中
16/12/10 22:11:52.03 tbmWmw27.net
aq-mode=0 にしたいなら --no-cutree をつけましょう
343:名無しさん＠編集中
16/12/11 20:56:10.10 hJSFtDSO.net
x265でタイムコードを扱うにはどうしたらよろしいのでしょうか？
344:名無しさん＠編集中
16/12/11 21:36:05.12 Ej/1KQE1.net
タイムコードを埋める
345:名無しさん＠編集中
16/12/11 22:15:21.16 5pxvee38.net
>>343
今、ちょうどやってるところだった
自分が使ってるAutoVFRを前提に話をするけど、2pass目avsの
its(def="F:\movie\_AutoVfr111\temp\AutoVfr.def", fps=-1, output="F:\movie\_AutoVfr111\temp\encode_time.tmc")
を
its(def="F:\movie\_AutoVfr111\temp\AutoVfr.def", fps=-1, output="F:\movie\_AutoVfr111\temp\encode_time.txt")
と変えてtimecodeをtmcじゃなくtxtで出力するようにして
それをx265でエンコード、L-SMASHでmp4にmux→mp4fpsmodでタイムコードを埋め込み→映像と音声の結合、で出来るっぽい
まだ10秒のクリップでエンコードしただけで（とりあえず上手くできてる）、今は10分のテストクリップでエンコード中
x265にはまだコンテナへのmux機能がないからこうするしかないと思うんだけど、合ってるのかな・・
346:名無しさん＠編集中
16/12/11 22:30:18.10 Ej/1KQE1.net
結構手間かかるのね
AviUtlなら拡張x265GUIexeのセットにツール含まれてるから
それ使ってmux後にtmc埋める
347:名無しさん＠編集中
16/12/11 22:36:44.37 2KAqxMaZ.net
x264とは違ってエンコードがVBVを考慮したVFRでないのは残念だな。
348:名無しさん＠編集中
16/12/11 22:50:54.41 d00fDOn9.net
ちょっと何言ってるか分かんない
349:名無しさん＠編集中
16/12/11 22:57:45.35 5pxvee38.net
>>346
行程的には3行ぐらい増やすだけだよ？
bat使ってればの話だけどさ
350:名無しさん＠編集中
16/12/12 00:27:53.28 gD/mE7aI.net
timelineediterでも出来た気がする
351:名無しさん＠編集中
16/12/12 00:45:38.61 85+/l636.net
>>349
ふむ、そうなのか
Avisynth使ってないからわからなかった
352:名無しさん＠編集中
16/12/12 18:08:06.43 S4yR6OZa.net
プリセットのslowerを使ってて
BフレームのAvg QPがI・PフレームのAvg QPより3～4ぐらい高くなるんだけどこういうもの？
353:名無しさん＠編集中
16/12/13 16:24:14.60 hnc+ud0/.net
grain使ったらエッジがずれた！
-----_----
↑
こんな感じ
354:名無しさん＠編集中
16/12/13 20:25:08.25 TjyNescZ.net
インタレ素材というオチじゃなくて？
355:名無しさん＠編集中
16/12/13 20:34:46.44 hnc+ud0/.net
プログレにしたあとのものです
実際には縦のエッジがずれてる
356:名無しさん＠編集中
16/12/14 16:59:20.03 RjxgomDO.net
説明書に書いてあるこれじゃないの？
If the bitrate is too low for the psycho-visual settings, you will begin to see temporal artifacts (motion judder).
This is caused when the encoder is forced to code skip blocks (no residual) in areas of difficult motion because
it is the best option psycho-visually (they have great amounts of energy and no residual cost).
心理視覚設定に対してビットレートが低すぎる場合、時間的なアーテイファクト（ブルブルした動き）が目に付きはじめるだろう。
これは、エンコーダが動きの複雑な領域でスキップブロック（残差なし）をコーディングするよう仕向けられた場合に発生する。
心理視覚的にはそれが最良の選択（スキップブロックは非常に高エネルギーで残差コストはゼロ）だからである。
357:名無しさん＠編集中
16/12/14 17:04:49.39 0U3OFDSM.net
グレインを残したいと思って>>233を参考にしたんだけど、
少し動きの激しいところで前後のフレームの残像(?)のようなノイズが現われたのも
それなのかな？
358:名無しさん＠編集中
16/12/14 17:58:09.38 RjxgomDO.net
あーaqを上げるとエッジに使うビットをケチるからエッジでは尚更そういう現象が起きやすくなるだろうね
tune grainではデフォルトでaqとcutreeとrecursion-skipを無効にする設定になっていて、
いずれも無効にするとブルブルの発生を抑制する効果があるけど、それぞれ大きな代償を伴うのが厄介なところ
ブルブルが気になるなら他にも--rect --amp --tu-inter-depth --ctuとかを弄って実験してみるといいかも
359:名無しさん＠編集中
16/12/15 12:40:24.98 b/JEIPWc.net
Merge with default; prep for 2.2
URLﾘﾝｸ(bitbucket.org)
もうすぐ2.2が出る模様
360:名無しさん＠編集中
16/12/15 14:30:23.03 qGsbTbvN.net
seaとlimit tuぐらい？
361:名無しさん＠編集中
16/12/16 19:23:46.85 r57tmTax.net
ビットレートが足りない(?)ブロック(ユニット)は
ブロック内の一部が破綻するんじゃなくてそのブロック全体がノイズまみれになるのね
ビットレートを上げるしかないのかな？
362:名無しさん＠編集中
16/12/16 21:04:38.18 gVeYNIsG.net
Transform Unitの階層深く取っても？
363:名無しさん＠編集中
16/12/21 02:16:26.02 9/TCvOhv.net
自作PC板でx265ベンチ始まりました
【x264+Avisynth】実用エンコベンチ Part5.1 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(jisaku板:101-番)
364:名無しさん＠編集中
16/12/21 14:22:12.31 L+Kxgheu.net
AVX2ってこんなに効果高かったんだな
365:名無しさん＠編集中
16/12/21 15:51:44.74 qF5Vf0hs.net
今じゃx264もx265も開発者の優先順位がAVX2だろうからな
x264に関しては過去に長いことSSE2とMMX2に最適化してきた
積み重ねがあるからSSE2とMMX2だけでも結構速度出せるけど
x265は今更SSSE3以前しか使えないような環境に最適化させるような開発リソース避けないだろうしな
366:名無しさん＠編集中
16/12/21 20:38:11.04 NDPNvhcH.net
x265は結構、x264から使える部分持ってきてるんで
x264時代の最適化がそのまま受けうがれてる部分も多い
367:名無しさん＠編集中
16/12/21 21:15:06.27 /iGrFqF/.net
結構を置く位置がおかしいからx265を拒絶した話の流れかと思ったｗ
368:名無しさん＠編集中
16/12/26 20:33:25.02 KBsiKcsO.net
2.2リリース
369:名無しさん＠編集中
16/12/26 21:10:11.47 uElJ6TyM.net
Version 2.2
Release date - 26th December, 2016.
Encoder enhancements
1.Enhancements to TU selection algorithm with early-outs for improved speed; use --limit-tu to exercise.
2.New motion search method SEA (Successive Elimination Algorithm) supported now as :option: ?me 4
3.Bit-stream optimizations to improve fields in PPS and SPS for bit-rate savings through --[no-]opt-qp-pps, --[no-]opt-ref-list-length-pps, and --[no-]multi-pass-opt-rps.
4.Enabled using VBV constraints when encoding without WPP.
5.All param options dumped in SEI packet in bitstream when info selected.
6.x265 now supports POWERPC-based systems. Several key functions also have optimized ALTIVEC kernels.
API changes
1.Options to disable SEI and optional-VUI messages from bitstream made more descriptive.
2.New option --scenecut-bias to enable controlling bias to mark scene-cuts via cli.
3.Support mono and mono16 color spaces for y4m input.
4.--min-cu-size of 64 no-longer supported for reasons of visual quality (was crashing earlier anyways.)
5.API for CSV now expects version string for better integration of x265 into other applications.
Bug fixes
1.Several fixes to slice-based encoding.
2.--log2-max-poc-lsb‘s range limited according to HEVC spec.
3.Restrict MVs to within legal boundaries when encoding.
370:名無しさん＠編集中
16/12/26 21:22:07.56 BqO4N2BJ.net
2.2のリリースノート、Doom9でも引用で貼られてたけど、
URLﾘﾝｸ(forum.doom9.org)
これのオリジナルのPradeepって人の書き込みってどこにあるんだろ？
371:名無しさん＠編集中
16/12/26 21:30:22.67 JP0kPcCb.net
URLﾘﾝｸ(bitbucket.org)
これ？
372:名無しさん＠編集中
16/12/26 22:01:15.17 BqO4N2BJ.net
>>371
なるほど、ありがとう。ドキュメントセットにリリースノートがあることを今更知ったよ・・・。
URLﾘﾝｸ(x265.readthedocs.io)
373:名無しさん＠編集中
16/12/27 18:21:57.06 Wogbf/iw.net
--scenecut-bias でキーフレ入れてくれない問題が解決するといいな
374:名無しさん＠編集中
16/12/29 19:17:55.33 fYAzDhfL.net
前フレームのブロックを(ほぼ？)そのまま使われて映像が乱れるのは
どうにかならないでしょうか？
その部分だけ四角く縁取られているような感じです。
>>356さんが指摘されていることが起きているのかと思いましたが
AvgQPが15以下に収まっているのでビットレート不足ではないと考えています。
375:名無しさん＠編集中
16/12/29 19:33:20.22 kl96PD55.net
エンコ設定とその前後のコマ見せてもらわんとなんとも
376:名無しさん＠編集中
16/12/29 19:38:28.20 OGUKq/vo.net
r-skipどうたらじゃね
377:名無しさん＠編集中
16/12/31 01:37:01.93 i6+ASlhP.net
>>374
提示されてる情報が少なすぎてレスしづらいんだけど
試しに --no-cutree と --no-rskip を付けてみれば？と当てずっぽうでアドバイスしとく
378:名無しさん＠編集中
16/12/31 18:49:22.26 DbDQ4u50.net
今年は2passがー、白黒でグレインガー、ておかしなバカが暴れてたな
バカってどうしてしたかでイキるんだろう
来年はまともなスレになりますように
379:名無しさん＠編集中
16/12/31 18:52:08.49 kkjB8t4J.net
あんたが書かなきゃ誰も覚えてなかったのに
当事者の記憶力（と執着心）は凄いね
380:名無しさん＠編集中
16/12/31 19:19:39.21 KCJwTdLm.net
したかでイキるとかいう言葉遣いがとてもバカっぽいｗ
381: 【馬】 【174円】
17/01/01 10:36:37.48 ZqwPoE19.net
>>379, >>380
まんまお前のこと
382:名無しさん＠編集中
17/01/01 10:43:36.36 fbyin3gO.net
今年最初のレスが馬のレスとか終わってんな
383:名無しさん＠編集中
17/01/01 16:00:07.39 14q4cpKx.net
頭が終わってる奴だししゃあない
384:名無しさん＠編集中
17/01/02 08:18:08.38 Y9pPOZTJ.net
Bitbucketの課題の所に上がってないけれど
--scenecut のバグってx265作ってるチームも把握してないのかな？
385:名無しさん＠編集中
17/01/03 17:11:56.82 sUotrbgP.net
また、変な奴が粘着してるな
色んなオプションいじるより、ipratioとpbratioをいじった方がいい事に今頃気がついた
386:名無しさん＠編集中
17/01/03 18:04:34.23 /Y6uaZhR.net
新年一発目のレスが耐性0だしね
しかし結局seaはどのプリセットにも組み込まれないのか
387:名無しさん＠編集中
17/01/09 11:27:13.96 Wrx8tLcO.net
ssimでいうと、速度画質のバランスはumhがいいし
starやesaはumhに画質で勝てないし、速度のメリットもあまりない
とんちんかんな事言い張ってる粘着は初心者スレに隔離した方がいいと思う
388:名無しさん＠編集中
17/01/09 12:50:00.89 Mt02Tt8p.net
>>384
scenecutに関心持ってる人が少なそうだしね・・・
その後いろいろ弄って分かったんだけど、x265に無視されやすいシーンチェンジって
その前後を跨いでタイトル文字やワイプみたいな輪郭の強いものが画面に居座ってる場合が多いみたい
これは新しく加わった --scenecut bias の仕組みについての説明とも符合するからバグとは言えないのかも
--scenecut と bias の両方を60ぐらいまで上げてみたらそういう動画でもx265の反応がだいぶマシになったよ
ただ、--scenecut をデフォの40にしたまま bias を80まで上げてみたら、なぜか期待とは逆にむしろ反応が
悪くなってしまったりして、相変わらず挙動が意味不明な部分はある
389:名無しさん＠編集中
17/01/09 13:24:50.61 Wrx8tLcO.net
メーリングリストで報告をなぜしない？
390:名無しさん＠編集中
17/01/09 13:43:48.34 t6YEm76/.net
starとseaの比較を2.1+70でやってたので面倒くさかったのでそれにumhを
追加したらこんな感じ。
FPS Bitrate SSIM
2.1+70 crf-23 slower -me umh 2.1 1716.13 0.98774
2.1+70 crf-23 slower -me sea 0.99 1713.67 0.987733
2.1+70 crf-23 slower 2.23 1717.42 0.987735
2.2だと変わってるの？
個人的には好きなの使えって感じだが、何が良いって言うのならデータが
ほしいな。
391:名無しさん＠編集中
17/01/09 13:51:04.80 Fcw2QpvI.net
x264の解説ではかなり重要とされてるから、バグもしくは意図しない動作なら大問題になってると思う
自分も気になって調べたけど前後でまったく別物に変わるシーンにはちゃんと入ってるし
逆に画面が切り替わっても半分ぐらい同じ感じなら入らなかったりで、x265では問題なくカバーできるという判断なんだと思う
ところで自分はaviult&L-SMASH Worksで読み込んで「キーフレームを表示」で確認しただけで
フレームタイプ自体は不明
392:名無しさん＠編集中
17/01/09 14:58:57.68 swVVIBW8.net
XMediaのプレビューでフレームタイプは確認できるよ
非常に操作しづらいが
393:名無しさん＠編集中
17/01/10 13:20:38.92 EPT/IMhL.net
>>390
それなら、黙っていればいいのに
何が言いたいのか意味不明
粘着自演の人？
394:名無しさん＠編集中
17/01/11 15:14:31.73 B/MVjbxn.net
検証データも上がってない時に
seaはumhに画質で勝てないとか言い出してた時点で
意味不明だったんだが
395:名無しさん＠編集中
17/01/11 15:43:14.41 q9SqfLzL.net
好きなの使えよバカじゃねえの
396:名無しさん＠編集中
17/01/11 15:49:27.02 yT93hhiQ.net
いつもの頭おかしい人だからスルーしていこう
そんなことより--aq-motionって前からあったっけ？
397:名無しさん＠編集中
17/01/11 16:11:23.51 hOIgNXWY.net
>>394
> seaはumhに画質で勝てないとか言い出してた時点で
390をどう斜め読みしたらそうなる？
398:名無しさん＠編集中
17/01/11 16:35:45.08 7B+qiWKK.net
--scenecut、0～17まではIフレームの数増えるな
とりあえず怪しい英語で報告はしたけど中の人理解してくれるかな？
宛先 : x265-devel@videolan.org
件名 : The bug in --scenecut option.
本文 :
--scenecut option setting are not reflected correctly after 17.
(NG出るからここには載せられないけれど--scenecut 16,17,40,100でのエンコード結果も記載)
399:名無しさん＠編集中
17/01/11 16:41:33.88 HYQVzojg.net
>>397
390じゃなくて>>387でしょ
"starやesaはumhに画質で勝てないし、速度のメリットもあまりない"
400:名無しさん＠編集中
17/01/11 17:03:55.15 hOIgNXWY.net
ああ、なる
画面が見切れてたは
>>398
何かしらの回答が得られるといいな
401:名無しさん＠編集中
17/01/11 18:09:37.03 yT93hhiQ.net
>>398
すごく有難いです
402:名無しさん＠編集中
17/01/12 19:14:44.15 20m6XFgc.net
>>394,>>396,>>399が同一人物に見える
403:名無しさん＠編集中
17/01/12 19:18:11.97 UnTyUCru.net
これが例の頭おかしい奴か
404:名無しさん＠編集中
17/01/12 20:13:59.39 tlO/QlT4.net
399は「やさしい第三者」の線が濃厚
いつもの人にこういう書き方は不可能のはず
405:名無しさん＠編集中
17/01/12 21:54:58.01 kzFzTSjr.net
>>378 >>381 >>387 >>393 >>402
406:名無しさん＠編集中
17/01/13 09:47:44.47 OH6T1OD1.net
>>405
自分宛のレスは同じ人と思ってるんですね
自演の自白同然ですね
407:名無しさん＠編集中
17/01/13 18:08:50.55 gLErScSi.net
久々に中の人がdoomへ書き込んでる
安定版は2ヶ月に1度リリースするように努めてるんだと
408:名無しさん＠編集中
17/01/14 14:56:53.93 jSrYX2GF.net
rdoqって重すぎだよな
409:名無しさん＠編集中
17/01/18 04:16:43.22 SfAff/ne.net
ochimasenyoni
410:名無しさん＠編集中
17/01/18 19:04:06.91 Eko41ntr.net
設定をこねくり回しすぎて疲れた
411:名無しさん＠編集中
17/01/19 02:34:13.69 +Ff0xeAf.net
はあ
412:名無しさん＠編集中
17/01/19 05:46:11.07 p3QxbdR2.net
ほ
413:名無しさん＠編集中
17/01/19 11:26:36.03 3g9bGjy1.net
かれこれ半月更新無しか…
414:名無しさん＠編集中
17/01/19 15:43:19.59 .net
a
415:名無しさん＠編集中
17/01/19 15:44:24.88 .net
a
416:名無しさん＠編集中
17/01/19 15:49:32.97 .net
a
417:名無しさん＠編集中
17/01/19 21:44:07.81 CL3XmwKb.net
ほ
418:名無しさん＠編集中
17/01/19 23:55:20.22 pRW6LZtz.net
ほ
419:名無しさん＠編集中
17/01/20 04:03:08.41 w+lzr/Jt.net
肉
420:名無しさん＠編集中
17/01/20 12:12:45.61 LWOYm+Em.net
ほしゅ
421:名無しさん＠編集中
17/01/20 17:50:15.10 xRstSMrX.net
ほ
422:名無しさん＠編集中
17/01/20 19:40:41.62 lYnNo7W50.net
も
423:名無しさん＠編集中
17/01/21 04:52:42.08 F8PDPyQ7.net
x265ってイントラブロック手抜きしすぎだよな
424:名無しさん＠編集中
17/01/21 14:00:29.76 PtNcmXSx.net
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)
425:名無しさん＠編集中
17/01/21 20:08:33.15 0VwuK7BN.net
アイコンから音ゲー板と勘違いした
426:名無しさん＠編集中
17/01/21 20:09:29.28 IaGHsGWK.net
/ﾆＹﾆヽ
/（ ﾟ )( ﾟ ）ヽ
／::::⌒｀´⌒::::＼
| ,-）＿＿＿（-、| ・・・・・・・・・・・・・・・ｗ
| l |-┬-| l |
＼､ `ー'´ ノ
. _＿＿ ノ トー-ー イ
. ／ ｀ヽr--､ー､,, └-‐―- ､
/ /ﾆﾆ＼ ＼
. { , ｀⌒｀ ＜＼ ,ｨ―'⌒ヽ.｀ｰ ､
', / ｀Ｙ´ ./⌒ヽ ﾍ.
ヽ、 / ＼}
. | {＞ 、 ｀ー-- / ヽ|
. | Ｖ ｀＞ 、＿＿＿_ , く ｀ー' ﾉ
. | Ｖ ｀ー ' ｀７ー―'
| ＼ /|
| | ／.｜
. ｜ /― ' ￣￣￣｀ー/ |
. | /￣￣￣￣￣￣￣｀ヽ ｜
. | ./ ﾊ |
427:名無しさん＠編集中
17/01/21 22:10:15.72 .net
DTVﾂ氾つづ�ﾂづ個姪｢ﾂ妥ｨﾂづｰﾂ氾ｰﾂつｯﾂづｩﾂつｽﾂづ淞、ﾂδ債ーﾂカﾂδ仰δ仰ーﾂδ仰づ｢ﾂ氾つ静敖津ｨﾂづ可甘鳴つｷﾂづｩﾂ議ﾂ論ﾂづｰﾂ行ﾂつ｢ﾂづ慊つｷ
ﾂ荒ﾂづｧﾂつｵﾂづ個防ﾂ止ﾂづ個つｽﾂづ淞外ﾂ閉板掲ﾂ篠ｦﾂ氾つづ�ﾂ行ﾂつ｢ﾂづ慊つｷﾂづ個づ�ﾂづｦﾂづｫﾂつｵﾂつｭﾂつｨﾂ甘ｨﾂつ｢ﾂつｵﾂづ慊つｷ
ﾂ【ﾂ篠ｩﾂ篠｡ﾂ】DTVﾂ氾つ篠ｩﾂ篠｡ﾂスﾂδ個氾ｰﾂ禿ｯﾂ渉
URLﾘﾝｸ(n2ch.ml)
428:名無しさん＠編集中
17/01/21 22:16:56.13 .net
sﾂつ
429:名無しさん＠編集中
17/01/23 14:52:31.41 DhCRAfNd.net
/ﾆＹﾆヽ ＿ ) (_
/ （0)(0）ヽ （⊂ﾆﾆ⊃) AAはどうしたごムイ共
／ ⌒｀´⌒ ＼ ｀二⊃ﾉ 許されたと考えてよろしいか？
| ,-） 川川 （-、.| （( ￣
| l ヽ＿＿ ノー┼￢Ｕ
＼ ｀ ⌒´ ／
／ ヽ
/ ヽ
| | |
ヽ_| |丿
| |