17/01/28 12:07:47.29 rzZP243DM.net
[バイナリ]
・...::: Komisar x264 builds :::... （changelog.txtもここを参照）
URLﾘﾝｸ(komisar.gin.by)
前スレ
x264 rev42
ｽﾚﾘﾝｸ(avi板)
3:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:14:48.59 5vCHjYRZM.net
保守
4:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:15:22.27 5vCHjYRZM.net
保守
5:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:15:45.86 5vCHjYRZM.net
保守
6:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:16:02.64 5vCHjYRZM.net
保守
7:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:16:22.18 5vCHjYRZM.net
保守
8:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:16:40.44 5vCHjYRZM.net
保守
9:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:16:56.24 5vCHjYRZM.net
保守
10:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:17:15.40 5vCHjYRZM.net
保守
11:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:17:30.48 5vCHjYRZM.net
保守
12:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:17:47.10 5vCHjYRZM.net
保守
13:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:18:06.12 5vCHjYRZM.net
保守
14:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:18:23.46 5vCHjYRZM.net
保守
15:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:18:41.26 5vCHjYRZM.net
保守
16:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:19:15.29 5vCHjYRZM.net
保守
17:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:19:32.64 5vCHjYRZM.net
保守
18:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:19:49.04 5vCHjYRZM.net
保守
19:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:20:05.78 5vCHjYRZM.net
保守
20:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/28 12:20:21.42 5vCHjYRZM.net
保守
21:名無しさん＠編集中 (ﾄﾞｺｸﾞﾛ MM83-FuHd)
17/01/29 05:06:35.59 rZUkYjIyM.net
保
22:名無しさん＠編集中 (ﾜｯﾁｮｲ 9a17-Ve17)
17/01/29 11:58:23.73 HRXKy2910.net
CLIで使用できる文字数って上限有りますか？
--zonesで出来ることが増えたからいろいろ試したいんですが、
既に--zonesで1500文字以上消費してるので、不安です
23:名無しさん＠編集中 (ﾜｯﾁｮｲ e37b-AZYz)
17/01/30 01:55:48.47 FYD+LKAF0.net
保守
24:名無しさん＠編集中 (ﾜｯﾁｮｲW f65f-sefe)
17/01/30 07:09:43.17 bq+tM8dk0.net
ググったらvista 以降は32000字と出てきた
25:名無しさん＠編集中 (ﾜｯﾁｮｲ 9a17-Ve17)
17/01/30 18:54:18.65 0ep9ofwb0.net
>>24
ありがとうございます
26:名無しさん＠編集中 (ﾜｯﾁｮｲWW 0b3c-UcZG)
17/02/01 22:01:43.34 NLeHcyku0.net
・echo コマンドで、8192 文字目以降の引数が切り捨てられる。
・Cmd.ex e から、子プロセスを起動する際、渡される引数の一部に抜けが生じる。
URLﾘﾝｸ(support.microsoft.com)
27:名無しさん＠編集中 (ｱﾀﾏｲﾀｲｰ MM25-qPcE)
17/02/02 21:45:36.29 /Vde4AArM0202.net
違法な無反応チューナーやB-CASの規約に違反するTS抜きに関するスレッドを皆で追い出しましょう。
【自治】DTV板自治スレ5©2ch.net
ｽﾚﾘﾝｸ(avi板)
28:名無しさん＠編集中
17/02/05 01:48:22.91 .net
URLﾘﾝｸ(blog-imgs-69.fc2.com)
29:名無しさん＠編集中
17/02/05 01:48:30.10 .net
URLﾘﾝｸ(blog-imgs-69.fc2.com)
30:名無しさん＠編集中 (ﾜｯﾁｮｲ f953-TVOI)
17/02/08 17:06:31.20 Hb1bXVZs0.net
作業用に一時的にHi10PなイントラでCBRエンコしようしてるけど流石に早いな。
31:名無しさん＠編集中 (ﾜｯﾁｮｲ 9336-yene)
17/02/08 21:58:33.98 UXGxZlhJ0.net
komisar氏のr2762こないな
32:名無しさん＠編集中 (ﾜｯﾁｮｲ 8742-CIv3)
17/02/09 17:17:36.57 xBCE3WXq0.net
URLﾘﾝｸ(translate.google.com)
33:名無しさん＠編集中 (ﾜｯﾁｮｲ 8a0b-fh5Q)
17/02/09 17:24:58.14 cYvlgny90.net
残っていたMMX部分SSE2にしたっぽいが速度上がるかな？
34:名無しさん＠編集中 (ﾜｯﾁｮｲ 2f0b-fh5Q)
17/02/10 19:45:44.72 y31+GkOw0.net
2762、若干速くはなっているけど、微々たる物だな
i7辺りだと気にならないレベル、PhenomⅡやCore2でエンコしている人は其れなりに大きいって感じか
35:名無しさん＠編集中 (ﾜｯﾁｮｲW 2764-fPxg)
17/02/10 20:12:09.84 sMazUFU/0.net
Ryzenどうなるかなー
コア数多くてもAVX系弱そう
36:名無しさん＠編集中(ﾜｯﾁｮｲ fad4-jWyY)
17/02/10 22:47:30.72 knMGpv420.net
x264の実行時間の半分はSIMD以外の計算と言う話だから、AVX2が128bitでも、コアが増えるのは有効だろう
37:名無しさん＠編集中 (ﾜｯﾁｮｲ 9361-CIv3)
17/02/10 22:52:31.51 q3hMw7op0.net
現行FXより速くなるだろうから、それだけでもかなり良いと思う。エンコだけなら無難な速度だしてくれるからねｗ
38:名無しさん＠編集中 (ﾜｯﾁｮｲ 8a46-CIv3)
17/02/11 21:07:09.42 tjFEHFwy0.net
ジャップランドからだと落とせないのかｗ
ココでも『日本氏ね!!』だなｗｗ
39:名無しさん＠編集中 (ﾜｯﾁｮｲ 4621-fh5Q)
17/02/12 13:55:54.37 3HO66Hm+0.net
2762駄目じゃね？、少なくともx86版
tmodしか使っていないからtmodが悪いのかもだけど
2台のPCでエンコしていて、両方ほぼ同じ位置で止まった。
タスクマネージャー覗いたらx264 .exeが原因、ハングアップじゃなくループし続けたりするときと同じような状態
40:名無しさん＠編集中 (ﾜｯﾁｮｲ 0e79-ENO3)
17/02/12 15:49:14.05 raHBEb1h0.net
なら何でmodビルドではないplainなビルドで試さないのさ
同じ場所で止まるならソースが悪い可能性はないの？AvisynthやAviutlのフィルタとか
41:名無しさん＠編集中 (中止 8a17-P6gz)
17/02/14 10:32:36.95 Y06BVDvR0St.V.net
crf 0って量子化が可逆なだけで、refとかmeが違うと別物のファイルを吐くんだな
42:名無しさん＠編集中 (中止 8ad8-Tsp1)
17/02/14 16:48:41.04 MMAaxHxI0St.V.net
Iフレームでディザが消えててフレームを進めるとディザが復活してきて
次のIフレームではまたディザが消えるのって何が原因？
設定はcrf20でpresetがMedium
43:名無しさん＠編集中 (ﾜｯﾁｮｲ 753d-iRi1)
17/02/17 13:43:42.85 zOolMlCC0.net
level6て
44:名無しさん＠編集中 (ｽｯﾌﾟ Sd03-RX2g)
17/02/20 08:22:01.82 we6mEaoWd.net
>>42
ちょっとでも動きの激しいGOPの部分でよく見るわ
fgo=1にしてもほぼ改善しなくてバンディングが発生するから私も悩んでる
45:名無しさん＠編集中 (ｽｯﾌﾟ Sd03-RX2g)
17/02/20 08:28:59.06 we6mEaoWd.net
その部分だけをTrimしてエンコするとfgo=0でもディザはきれいに残るから何が悪いのかわからない
46:名無しさん＠編集中 (ﾜｯﾁｮｲ 8500-P9CU)
17/02/20 09:54:07.82 Mj9I5Lxk0.net
元からあるとかいう話じゃなくて？
x264のオプションならipratioのBフレーム版なオプションがあった（今もある？）はずだから探してみては
47:名無しさん＠編集中 (ｽｯｯﾌﾟ Sd43-RX2g)
17/02/20 14:43:33.63 2FqcQwDpd.net
pbratioかな？
でもこれってIフレームには影響しないんじゃない？
48:名無しさん＠編集中 (ﾜｯﾁｮｲ a53c-P9CU)
17/02/20 14:54:31.48 y6mXnjGo0.net
名前の通りPとBだね
Pフレームの品質に対してBフレームの品質をどうするか
みたいなコマンドだったはず
49:名無しさん＠編集中 (ｽｯｯﾌﾟ Sd43-RX2g)
17/02/20 18:09:28.11 cF3iu/KMd.net
Crfエンコでのビットレートで2passのエンコをすると、そっちではディザが保持された
かといって、ソース毎に必要なビットレートが違うから、一度Crfでエンコして必要なビットレートを取得して2passでエンコし直すというのも手間だしどうしたらいいんだろう
50:名無しさん＠編集中 (ﾜｯﾁｮｲ 8500-P9CU)
17/02/20 18:44:26.33 Mj9I5Lxk0.net
ごめん
さらっと読んで階調割れのことかと早ガッテンした
細かいものを残したいならデブロッキングフィルタを下げてみるとかpsy-rdの調整ぐらいしか思い浮かばないけど
今使ってるpresetや個別に指定してるオプションなどを書いてくれたらなんか思いつくかも
51:名無しさん＠編集中 (ｽｯﾌﾟ Sd03-RX2g)
17/02/20 18:53:20.61 bp1Dvjt0d.net
階調割れを防ぐためのディザを残そうとしてる
設定してるのはcrf=18, deblock=-1:-1, psy-rd=1.0:0.2, aq-mode=1, aq-strength=0.9
52:名無しさん＠編集中 (ｽｯﾌﾟ Sd03-RX2g)
17/02/20 19:32:29.04 bp1Dvjt0d.net
psy-rdを1.35:0.4に変更して、fgo=1を追加してもあまり改善はみられなかった
それで>>51の設定で2passエンコをしたらディザが保持できていた
53:名無しさん＠編集中 (ﾜｯﾁｮｲ 8500-P9CU)
17/02/20 20:46:19.40 Mj9I5Lxk0.net
もう画質とかあまり考えずにx265へ移行したから的外れ（記憶違い）かもしれないけおｄ
動きのあるシーンならとりあえずqcomp=80を試してみてるぐらいかな
あとはオプション弄る前にsubme上げるとか（プリセットを）上げる方が先決な気がする
（個人的にはcrf18ならdeblockは-2:-2:にしても大丈夫だと思うけど大した効果はないかな）
54:名無しさん＠編集中 (ｽｯﾌﾟ Sd03-RX2g)
17/02/20 20:58:18.33 bp1Dvjt0d.net
me=umh, subme=9, merange=32, qcomp=0.8, deblock=-2:-2
試してみたけどほとんど変わらないかな
55:名無しさん＠編集中 (ﾜｯﾁｮｲ 8500-P9CU)
17/02/20 22:11:47.21 Mj9I5Lxk0.net
そうか残念・・今、あと思いつくのはsubme=11のno-mbtree だけ
そういえば、むか～しmuken氏の私的エンコード設定晒しなコマンドラインをどっかに保存したはず・・と思って探してみたんだけどないんだよね
muken氏のオプション設定の優秀さを測れると思ったんだけど、それもちょっと残念
56:名無しさん＠編集中 (ﾜｯﾁｮｲ 2317-QocU)
17/02/21 00:14:40.64 d+R5c1Ke0.net
>>55
--no-mbtreeは効きそうですね
--pbratioが有効になるから、1付近に設定すればマシになりそう
57:名無しさん＠編集中 (ﾜｯﾁｮｲ 2317-QocU)
17/02/21 00:16:23.14 d+R5c1Ke0.net
--qpfile とか --cqmfile みたいに、 --zonesfile オプションがほしい
58:名無しさん＠編集中 (ｽﾌﾟｯｯ Sd43-RX2g)
17/02/22 21:29:35.98 IwsRK/Qtd.net
いろいろ試してみたけどやっぱりディザが残らない
qpfileでIフレームのqpを0に設定してもフレームの上端のマクロブロック一列しかほとんどディザが残らない
59:名無しさん＠編集中 (ﾜｯﾁｮｲ 8500-P9CU)
17/02/22 23:25:33.38 WN4yLsjU0.net
そういえばpsy-rd使うとなんとかｑｐ-offsetがマイナスになった気がするからpsy-rdを0：0（効果を分かりやすくするため）でやってみたら？
さらにtune grainでやって残らないならmuken氏にでも聞くしかないと思うな・・
とういうかなんかIで消えてP/Bで残るってなんか出てきそうで出てこないんだよね
60:名無しさん＠編集中 (ｽﾌﾟｯｯ Sd03-RX2g)
17/02/22 23:49:57.04 acFLLeSrd.net
マイナスになるのはchromaじゃなかったかな？
次はtune grainも試してみる
なんでcrfだと消えて、2passだとバンディングが発生しない程度には保持できるのか謎
61:名無しさん＠編集中 (ﾜｯﾁｮｲ 1a17-8Hz2)
17/02/23 04:23:16.41 x/XdQJoH0.net
そもそも無理だからバンディング低減フィルタが生まれたのではないのか
62:名無しさん＠編集中 (ﾜｯﾁｮｲ c679-HyQo)
17/02/23 11:07:57.88 vN+wtlpW0.net
なんで糞忙しそうなmuken氏に聞こうとするんですかね・・・
かつて野良ビルドしてた人だけどx264devじゃないでしょ
>>58
取り敢えず画像上げてみたら？ソースとcrfエンコ後、2passエンコ後の3種類
63:名無しさん＠編集中 (ﾜｯﾁｮｲ fd3b-M7EA)
17/02/27 07:17:53.84 XLbpq8sD0.net
>>34
>PhenomⅡやCore2でエンコしている人は其れなりに大きいって感じか
FXまでのAMDプロセッサを使う場合は、r2345以降は思ったほど速度でないから。
r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。
64:名無しさん＠編集中 (ﾜｯﾁｮｲ 75c1-F6/z)
17/02/27 10:16:14.05 pSxAzVIJ0.net
>>60
ソース見ないと、対策できるものかどうかなんとも
思いつくのは、まずは詳細ログを取って該当箇所のフレームタイプとqp値を調べる事かな
自分なら実験として、10bitやb無しをためしてみる
yを少しいじるだけで、かなりブロックが出てくるソースて結構あって
それをエンコすると俺には階調に見えたりする事もあった
(ffmpgのssim見るとx264のエンコはyが大きく落ちる傾向にある)
それも考慮に入れて見ては
65:名無しさん＠編集中 (ﾜｯﾁｮｲ ae59-zFUC)
17/02/28 17:36:14.00 PHbqDs1E0.net
>>r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。
2346以降、2345最期に削った命令はOSが7以降と言う条件付き
XP(改)や2kexの場合は元々機能しない命令なので最新版の方が速いと蛇足付けておきます
66:名無しさん＠編集中 (ﾜｯﾁｮｲ fd3b-M7EA)
17/02/28 19:19:49.54 YVuNCVGh0.net
そもそもx264でエンコする人がいまだにWin7未満を使い続けてるとは到底考えられないんだが。
Win7未満を使い続けてる層はx264よりくっそ軽いXVIDやDIVXを愛用してんじゃないか。
67:名無しさん＠編集中 (ﾜｯﾁｮｲ 5500-d4M5)
17/02/28 21:04:36.71 nWED9X2x0.net
煽り失敗！
68:名無しさん＠編集中 (ﾜｯﾁｮｲW 1a17-1OkV)
17/03/01 00:04:40.77 3MlnXzcL0.net
OSとCPUの区別がついてないんだな
69:名無しさん＠編集中 (ﾜｯﾁｮｲ 053c-d4M5)
17/03/01 14:25:06.58 MUatPPG40.net
test
70:名無しさん＠編集中 (ﾜｯﾁｮｲ fb76-rrQM)
17/03/02 00:04:11.79 znb1goci0.net
komisarが403なの俺だけ？
71:名無しさん＠編集中 (ﾜｯﾁｮｲ 1317-5Zjm)
17/03/02 00:08:33.38 6vPQ95ES0.net
>>70
日本からのアクセス遮断されてる
72:名無しさん＠編集中 (ﾜｯﾁｮｲ fb76-rrQM)
17/03/02 00:40:05.09 YFE/7OfW0.net
マジか
何があったんだ
73:名無しさん＠編集中 (ﾜｲｴﾃﾞｨ MM63-BJNc)
17/03/02 00:45:17.49 x8Wr5mB9M.net
ライゼンってSSEが十倍の性能らしいからコア数とあいまってエンコはかどるかな？
74:名無しさん＠編集中 (ﾜｯﾁｮｲ 2b79-2BvX)
17/03/02 00:46:10.10 V8vD73Fb0.net
理由は不明
予想するとすればAviUtlのx264GUIExが自動ダウンロードするx264がkomisar氏のもので
それでアクセス数が急増して日本からの接続を拒否ったとかそういうところじゃないのかな？
75:名無しさん＠編集中 (ﾜｯﾁｮｲ 2919-BJNc)
17/03/02 01:47:39.10 EpvM0pt80.net
急増するほど最近の話か？ それ
76:名無しさん＠編集中 (ﾜｯﾁｮｲ 493c-da5B)
17/03/02 07:10:53.26 zo1ua/sp0.net
自動インストーラってAviUtlに必要なん？
README見て必要なものを集めてくんじゃないの？ｗ
>>75
急増騒きは少し前だと思うよ
その時期にYoutubeに手順動画が流れてにわかユーザーが増えたからじゃないかな
理解しないで適当インストールを繰り返してアクセスが増えたのは確かかな
今も増えてるようだけど、安易に変なインストーラ作らないで欲しいと思うよ
77:名無しさん＠編集中 (ﾜｯﾁｮｲ 493c-FnJB)
17/03/02 07:20:14.76 xEj84IP10.net
Readmeを見て自分でファイルを集めてこれない人向けだから…
78:名無しさん＠編集中 (ﾜｯﾁｮｲ 2942-NqFr)
17/03/02 10:39:30.20 xiBnsCVc0.net
久々に来てみたがネ実のクズ共の荒らし行為って沈静化したん？
79:名無しさん＠編集中 (ﾜｯﾁｮｲ 13fd-9OG8)
17/03/02 15:19:05.46 r5tKudVv0.net
自動ダウンロードに拒否がどうのって話デジャヴ
80:名無しさん＠編集中 (ﾜｯﾁｮｲ 7b59-AHnh)
17/03/02 16:47:40.61 NAYKX2H20.net
>>74
それで良いと思うよ
ツール使ってダウンロードしないでくれって書いてあるし
よっぽど行儀の悪いアクセスしていたか、数が半端じゃなかったんだろうよ
81:名無しさん＠編集中 (ﾜｯﾁｮｲ 13a6-BJNc)
17/03/02 21:16:20.34 lBCkdqF50.net
>73
自分は今すぐには買えないので、レポ待ちでワクワクしている
82:名無しさん＠編集中 (ﾜｯﾁｮｲ 293b-TgS+)
17/03/02 21:52:10.99 OQofB6vk0.net
よかったな 速いぞ
URLﾘﾝｸ(cdn.wccftech.com)
83:名無しさん＠編集中 (ﾜｯﾁｮｲWW 3117-RQw6)
17/03/03 01:25:00.72 SoL/p3Zu0.net
エンコ用途なら買いだな
84:名無しさん＠編集中 (ﾋｯﾅｰ 293b-TgS+)
17/03/03 07:52:13.49 JjDE7caL00303.net
Encodage video : x264 et x265 - AMD Ryzen 7 1800X en test, le retour d'AMD ? - HardWare.fr
URLﾘﾝｸ(www.hardware.fr)
URLﾘﾝｸ(pc.watch.impress.co.jp)
AVX2オフにするとパフォーマンス上がる
85:名無しさん＠編集中 (ﾋｯﾅｰ 4160-NqFr)
17/03/03 10:44:24.67 o2enDWaz00303.net
コアあたりの性能はIntelとほぼ同等まで追いついて価格が驚異的に安い
Ryzenコスパやばいな
86:名無しさん＠編集中 (ﾋｯﾅｰ b15b-2BvX)
17/03/03 11:23:50.13 mkOg2Z+q00303.net
まさかx264エンコードでも上行くとは
動画エンコードでIntel上回ったのなんて初じゃね
87:名無しさん＠編集中 (ﾋｯﾅｰ 493c-FnJB)
17/03/03 11:39:33.65 rDE5c83b00303.net
611 名前：名無しさん＠編集中[sage] 投稿日：2016/12/07(水) 21:57:43.12 ID:Ast4Hrma [3/3]
[バイナリ]
■rigayaの日記兼メモ帳 （右下の「x264」から）
URLﾘﾝｸ(rigaya34589.blog135.fc2.com)
■jpsdr/x264 （t_mod版）
URLﾘﾝｸ(github.com)
■...::: Komisar x264 builds :::... （clear版/ｋMod版）
※2016年11月より日本からアクセスできなくなっているのでWebArchiveで。
URLﾘﾝｸ(web.archive.org)
88:名無しさん＠編集中 (ﾜｯﾁｮｲ 0bfd-2BvX)
17/03/05 19:06:24.58 9iE97utn0.net
エンコなら1800X買うしかないねぇ
89:名無しさん＠編集中 (ﾜｯﾁｮｲ 294f-BJNc)
17/03/06 02:26:58.54 2jXgFqW50.net
1700で十分だな
1800X/1700Xの差別化ポイントであるXFRはたった
1コアを100MHzだけOCするガッカリ機能だと判明して
結局は手動で倍率設定するしかない
自作PC板では倍率フリーの1700をクロック上げれば1800Xとほとんど変わらんじゃん
て流れになってる
90:名無しさん＠編集中 (ﾜｯﾁｮｲ 8b5e-BJNc)
17/03/08 21:45:18.31 5f3zjIK/0.net
2ソケットできるNaplesだと1800Xよりさらに上か・・・
買う人は買うだろうなあ
91:名無しさん＠編集中 (ﾌﾞｰｲﾓ MM4d-NIfd)
17/03/08 22:14:26.50 8NMXBv1WM.net
おいくら万円になるんだか
92:名無しさん＠編集中(ﾜｯﾁｮｲ 0bd4-Mt2S)
17/03/08 22:17:12.49 uSeTgtzR0.net
Naples x 2だと合計128スレッドで、現時点でのx264の--threadsの限界に達するな
93:名無しさん＠編集中 (ﾜｯﾁｮｲ 7917-2hGO)
17/03/11 01:16:36.51 xcdpSSTj0.net
確かスレッド増えるとファイルサイズも僅かに大きくなるよね
128スレッドだと、気になるぐらいファイルでかくなるんだろうか
94:名無しさん＠編集中 (ﾜｯﾁｮｲ 5d3c-qe+Q)
17/03/11 01:36:00.94 thFGa3uF0.net
--threads 12で--threads 1よりビットレートが1%ぐらい大きくなってた気がするけど
128/12=10.67%も大きくなる…のかなぁ
95:名無しさん＠編集中 (ｱｳｱｳｶｰ Sa5d-JT/Z)
17/03/11 08:55:13.25 r7DCAib9a.net
ccx内で完結するように2本流して速度稼ぐのが良いのでは？
スレ数増やす設定で処理fps増やすのだから物理スレ数と設定スレ数が同一なのはメリットがイマイチな気がする。
L3キャッシュはccxを跨ぐと効率が落ちるからこの辺りの実装を気にした実装が理想だろうね。
96:名無しさん＠編集中 (ﾜｯﾁｮｲ d64f-2hGO)
17/03/12 06:59:44.38 ev1URYZR0.net
実際にはx264はRyzenが非常に得意な分野だから
コアの割り当て問題は当然のこととしてL3が8MB + 8MB
にパーティショニングされてる問題もほとんど影響ないんだろ
97:名無しさん＠編集中 (ﾜｯﾁｮｲ 2500-csvI)
17/03/12 09:35:06.27 HPWsohqC0.net
SIMD命令にキャッシュはあまり関係ないそうだよ
98:名無しさん＠編集中 (ﾜｯﾁｮｲ cd3d-oGwt)
17/03/12 14:10:09.08 gTBFYAG80.net
AthlonⅡX4はいい塩梅だった
99:名無しさん＠編集中 (ﾜｯﾁｮｲ b1d6-T4Zw)
17/03/12 20:22:19.29 3TierDBr0.net
誰か雷禅でエンコして
100:名無しさん＠編集中 (ﾜｯﾁｮｲ fa17-KHUK)
17/03/12 20:30:17.56 It3queHc0.net
>>99
このスレじゃいかんの？
【x264+Avisynth】実用エンコベンチ Part5.1 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(jisaku板)
101:名無しさん＠編集中 (ﾜｯﾁｮｲ 13d8-3AO9)
17/03/17 23:55:59.76 x2MiC76Z0.net
アドバイスお願いします。
動きのあるシーンで動いた部分のディザーやグレインが保持できないのですが、どうすればよろしいでしょうか？
動きの少ない部分では保持できています。
パラメーターはcrf 18、umh、subme 10、psy-rd 1.0:0.3、aq 3:1.00、bframes 6、b_pyramid 2、b_adapt 2です。
102:名無しさん＠編集中 (ﾜｯﾁｮｲ 0b79-12+v)
17/03/17 23:59:30.84 6/5IqK3Y0.net
--qcompを盛ってみる 0.8とか
--qpstepを盛ってみる 8～16とか あんまり大きくしすぎても良くはならない気がする
--bframesを減らしてみる デフォルトの3とか
103:名無しさん＠編集中 (ﾜｯﾁｮｲ 59fe-tpgq)
17/03/18 13:08:41.33 Mqc7uy8r0.net
deblock -2:-2, psy-rd <unset>:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8
tune grainの中身らしいから、これを軸にいじってみればいいんじゃない
104:名無しさん＠編集中 (ﾜｯﾁｮｲ 1359-F0aS)
17/03/18 14:39:38.21 PgHHxzGe0.net
質問スレとかなくなっちゃったんだね
みんなって、最新のリビジョン使って本番エンコしてる？
さすがに最近はやらかしとかないよね
105:名無しさん＠編集中 (ﾜｯﾁｮｲ 9989-12+v)
17/03/19 21:14:44.14 3yF2GRg50.net
posix versionsって何？
Linux用？
106:名無しさん＠編集中 (ﾜｯﾁｮｲ 91c1-y/cv)
17/03/20 15:27:25.32 BpP4DLbv0.net
わからないなら気にするな
ggrks
107:名無しさん＠編集中 (ﾜｯﾁｮｲ 613b-WisJ)
17/03/20 17:19:36.45 g6ulSQjE0.net
x264で盛り過ぎると再生(デコード)時にやたら負荷のかかるパラメータってなんだっけ？
前にx264でエンコした動画をスマホのVLCで見ようとしたらコマ落ちが酷くてだいぶ厳しかった。
108:名無しさん＠編集中 (ﾜｯﾁｮｲ 0b79-u6wT)
17/03/20 17:20:46.10 mCakdv6o0.net
refとかbframesとか
109:名無しさん＠編集中 (ﾜｯﾁｮｲ 613b-WisJ)
17/03/20 17:50:15.86 g6ulSQjE0.net
x264 core 148 r2744 b97ae06 High10 Lv5.1
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10
psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1
cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2
sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0
bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0
weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60
rc=crf / mbtree=1 / crf=15.5 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
ちなみにこんな設定。
110:名無しさん＠編集中 (ﾜｯﾁｮｲ 013c-fEWq)
17/03/20 17:52:48.16 vVotdsrL0.net
refもbframesもスマホ向きじゃないぐらい大きいね
111:名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MMab-Gg+/)
17/03/20 17:54:11.45 IPbCXG2RM.net
解像度によってはref16はかなりのハイレベルになるよ
112:名無しさん＠編集中 (ﾜｯﾁｮｲ 0b79-u6wT)
17/03/20 17:55:19.32 mCakdv6o0.net
8bitエンコにするなりrefを3~4にするなりbframesを減らしてみるなり手はあると思うんだ
113:名無しさん＠編集中 (ﾜｯﾁｮｲ 613b-WisJ)
17/03/20 18:01:04.11 g6ulSQjE0.net
エンコ環境やノートPCでは何の不都合もなく再生できていたから
スマホでも行けると思って再生してみたら、ほんとやらかした感に満たされた。
画質を選ぶか負荷低減を選ぶか、どこで線引きするか悩むところだね。
114:名無しさん＠編集中 (ﾜｯﾁｮｲ 0b79-u6wT)
17/03/20 18:07:44.17 mCakdv6o0.net
少なくともbframesは盛ったところで縮みはするけど画質が上がるとは限らないと思う
refはどうなんだろうな以前盛ったり減らしたりしたけど特段盛りまくってもエンコ速度とSSIMを比べると効率が悪くなる気がして4ぐらいまでしか使ってないな
115:名無しさん＠編集中 (ﾜｯﾁｮｲ 1317-bHoN)
17/03/20 18:11:42.13 YxhIh3YN0.net
素人で再生互換性とかよくわからないからほぼデフォルトプリセットしか使ってない
116:名無しさん＠編集中 (ﾜｯﾁｮｲ 91d4-tpgq)
17/03/20 18:12:42.05 g0tid5gi0.net
Bフレ8枚って容量節約モードですか
117:名無しさん＠編集中 (ﾜｯﾁｮｲ 914f-tpgq)
17/03/20 18:57:06.45 dyE1cGoC0.net
費用対効果的に
ref 4
bframes 3
以上は微差しかないな
118:名無しさん＠編集中 (ﾜｯﾁｮｲ 0b5b-tpgq)
17/03/20 18:59:35.37 K9LZysiQ0.net
まあBフレ増やして節約した容量分、crf下げれば
画質は良くなるけど再生負荷は高いよね
119:名無しさん＠編集中 (ﾜｯﾁｮｲ 9153-ajdi)
17/03/20 19:15:29.81 DaNUKjFo0.net
veryslowベースの設定なのかもしれんが、「crf=15.5」ってのも結構やばいのでは・・・
Hi10pな上に、ここまでcrf値を下げる人ってあまりいないんじゃないか？
120:名無しさん＠編集中 (ﾜｯﾁｮｲ 313c-u6wT)
17/03/20 20:02:59.60 OH0D6gB50.net
他のコマンドにもよるだろうけど、crf16あたりからが人間の眼では劣化が分からなくなるんじゃなかったっけ？
121:名無しさん＠編集中 (ﾜｯﾁｮｲ 1359-idsh)
17/03/20 20:35:50.01 myC1EGEA0.net
どこが悪いというか、スマホで動かすには悪いところ多すぎてわらたｗ
122:名無しさん＠編集中 (ﾜｯﾁｮｲWW b18e-DTjG)
17/03/21 10:20:59.28 kHNquja20.net
スマフォならHWデコードだから大して差は無いと思うが、そもそも10bitデコードに対応してる機種なの？
123:名無しさん＠編集中 (ｽﾌﾟｯｯ Sd73-urfV)
17/03/21 12:39:29.68 7w2jOxdHd.net
ハードウェアデコードとはいえ、無制限ではないからな。
想定はBDの規格内と思ってたほうが良いと思うぞ。
124:名無しさん＠編集中 (ﾜｯﾁｮｲ 693e-ajdi)
17/03/21 14:53:32.41 aS02+pTx0.net
>>122-123
H.264の10bitのHWデコードに対応してるものなんて無いだろ。10bitはSWデコードのみ。
125:名無しさん＠編集中(ﾜｯﾁｮｲ 6bd4-M7md)
17/03/21 17:39:54.26 ZWjxBEYu0.net
ちゃんとVBVを設定してHigh@4.1までならどのハードでも安心
126:名無しさん＠編集中 (ﾜｯﾁｮｲWW b18e-DTjG)
17/03/21 18:53:41.96 kHNquja20.net
>>123
その制限がプロファイルとレベルだと思うんだが範囲内ならドロップしたことは無いかなぁ
>>124
俺も見たこと無いんだが、スマフォでSWデコードはキツくねって言いたかった
127:名無しさん＠編集中 (ﾜｯﾁｮｲ 51e1-u6wT)
17/03/21 20:42:13.86 gt0UGiJv0.net
>>126
そうでもない
円盤はランダムシークに弱いからBフレも参照距離も3程度がベター
もっとも16とか指定しても使わなければ問題ないわけ（HWデコード全般で）だけど
万が一に備えると厳しめになる
128:名無しさん＠編集中 (ﾜｯﾁｮｲW 51f3-vaS3)
17/03/22 23:19:05.92 vOb72tqI0.net
はあ？
129:名無しさん＠編集中 (ﾆｸｸｴWW ddc8-/tPV)
17/03/29 14:34:57.70 lSlTuvuQ0NIKU.net
--crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした
crf指定無しだと--crf 23と同じ扱いになるんですか？
130:名無しさん＠編集中 (ﾆｸｸｴ 3e79-5sBS)
17/03/29 14:39:19.24 sWlpArUZ0NIKU.net
そもそもデフォルト設定が--crf 23
131:名無しさん＠編集中 (ﾆｸｸｴWW ddc8-/tPV)
17/03/29 23:57:08.08 lSlTuvuQ0NIKU.net
>>130
なるほどありがとうございます
132:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fb6-Qc7F)
17/03/30 14:43:09.54 foKOUbX30.net
>>127
なんか、突っ込む気力が失せるくらい色々痛いな
133:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fe1-jsM4)
17/03/30 15:14:27.49 dO0HQ95e0.net
>>132
つ鏡
134:名無しさん＠編集中 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/02 15:33:06.82 JfirpmU20.net
RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、
ソフトテレシネのままエンコする方法はありますか？
一応プログラムも書けるのですが、libx264は使いたくないのでx264.exe使って
タイムコードみたいに、RFFフラグをファイルから入力させることができればベストだと思ってます
60i混在ソースなので、全部24p化するというのはできなくて
今の所フレーム水増しして60iにしてエンコしてるのですが、
ソフトテレシネのままの方が画質が良くなると思うんです
そんなに気にする必要ありませんかね
135:名無しさん＠編集中 (ﾜｯﾁｮｲ ff79-jsM4)
17/04/02 15:35:31.23 zlbvKLjL0.net
--pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた
136:名無しさん＠編集中 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/02 15:42:07.65 JfirpmU20.net
>>135
それはソフトテレシネなのですが、フレームごとに指定することができない（する方法が分からない）ので、
60i混在ソースだと使えないんです
137:名無しさん＠編集中 (ﾜｯﾁｮｲ ff79-jsM4)
17/04/02 15:50:20.30 zlbvKLjL0.net
zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない？
糞めんどくさいしややこしいから60iに統一してやったほうがいいしそこまで画質に差は出ないと思う
138:名無しさん＠編集中 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/02 16:06:58.66 JfirpmU20.net
なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます
139:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fb9-agmj)
17/04/02 16:15:01.80 UgoQM92X0.net
x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな
140:134 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/02 23:17:47.17 JfirpmU20.net
x264cli改造してRFFフラグをファイルから入力できるようにした
URLﾘﾝｸ(github.com)
これでエンコしたやつ、H264のrawストリームはmpc-hcで再生してちゃんと再生されてるようにみえるんだけど
mp4にmuxするとおかしくなる。
L-SMASHだとfpsを引数で指定してるのになぜか出力がVFRになっちゃって
再生するとフレームレートが半分くらいになっちゃう
MP4boxだとpulldownしてるところがちゃんと認識されないのかL-SMASHとは逆に1.2倍速くらいに速くなっちゃう
エンコはできてもmuxできないというオチorz
x264だとソフトテレシネはプログレッシブでのエンコードになるから、60iとの混在ソースだと
エンコ途中でプログレッシブとインターレースを切り替えるためにx264_encoder_reconfigを呼ぶ必要があって
なんか危なそうだし、やめておいたほうがいいかな
141:名無しさん＠編集中 (ﾜｯﾁｮｲ ff79-jsM4)
17/04/02 23:23:41.04 zlbvKLjL0.net
>>140
うーんどうだろうH.264やmp4(ISOBMFF)の規格に詳しくないから分からない
もう全体的に60iとしてエンコしてしまったほうがいいんじゃないかな x264はインタレェでもそれなりに圧縮率いいし
--stitchableと--sps-idを使って最後に結合する方法は規格上問題ないとは聞いた
muken氏とかH.264とISOBMFFの両方に精通してる人に聞かないと正しい実装に出来ないんじゃないかな
142:名無しさん＠編集中 (ﾜｯﾁｮｲ 9f95-jsM4)
17/04/03 07:37:09.54 TctSlTlK0.net
mukenさんが答えてくれてるね
URLﾘﾝｸ(twitter.com)
URLﾘﾝｸ(twitter.com)
URLﾘﾝｸ(twitter.com)
143:名無しさん＠編集中 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/03 09:31:10.42 fUoHoWI80.net
感激！そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ
144:名無しさん＠編集中 (ﾜｯﾁｮｲ ff79-jsM4)
17/04/03 11:16:11.92 VSUvqQUi0.net
すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな？
145:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fb6-Qc7F)
17/04/03 14:27:48.23 35NLofYn0.net
muken氏語ってるね
残業なくてもイエスマンが出世するようになってるからダメでしょ
そんな人に勉強の成果や能力の良し悪しの判断なんて土台無理な話
で、また、イエスマンが出世する
これじゃ、中卒か高卒で公務員になって趣味に生きるのが最もコスパの人生だからね
シャープ、東芝、かつての日産見ても学習できないんだからどうにもならん
すれちすまん
146:134 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/04 01:08:20.88 NM8tqATA0.net
うぉぉーできたー！timelineeditorでタイムコード入れたらちゃんと再生できるようになった。
mukenさんありがとうございます！
ただちょっと問題が。
PC(mpc-hc)、Xperia Z4 Tablet、PS3でそれぞれ再生してみたら、
PS3だと何の問題もなく再生できたけど、
mpc-hcだとたまにインターレース縞が見えるのと、動きが若干カクカクする。
Xperia Z4 Tabletだと、インターレース縞は全く無いけど、mpc-hcと同じように若干カクカクする。
タブレットだと画面がそんなに大きくないから、カクカクって言っても、よーく見ないと分からない程度だけど、
mpc-hcでちゃんと再生されないのはなぜなのか・・・
PS3だと本当に何の問題もなく再生できて、ブラビアのモーションフロー効かせても問題ないんだよな
再生側の問題なのか、mp4ファイル側に問題があるのか、分からん
147:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fd4-YWlL)
17/04/04 02:00:24.39 htZBUXUD0.net
家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな
pulldownして全部iで出すデコーダと、p部分はpのまま出すデコーダがあったりして
後者の場合にi/pの変わり目で挙動が乱れるレンダラがあったりする
148:名無しさん＠編集中 (ﾜｯﾁｮｲ ffa3-jsM4)
17/04/04 02:19:44.54 NM8tqATA0.net
すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ
直したらmpc-hc、Xperia Z4 Tabletともにカクカクはなくなった
これでXperia Z4 Tablet、PS3では全く問題無く再生できるようになった
ただ、mpc-hcだと、プログレッシブとインターレースの切り替わりで問題があるっぽい
インターレース縞が残ったり、フレームが一瞬戻ったりする
>>147まさにそういう状況だわ
変態ストリームというかPC系がちゃんと実装してないだけなんだよな
mp4のファイル自体は問題なさそうだから、これでソフトテレシネと
60iインターレースの混在ソースをそのままエンコードできるようになった
>>144
今作ってるフロントエンドのプログラムそのうち公開するから待って
149:名無しさん＠編集中 (ﾜｯﾁｮｲ ffb9-agmj)
17/04/04 02:31:19.30 n3r5tOrx0.net
mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい
PAFFインタレだと60i部分が30p再生されたりとか
150:名無しさん＠編集中 (ﾜｯﾁｮｲ c1b6-ntn2)
17/04/06 19:27:08.09 01K8kK0t0.net
ffmpegだとフラッグのみbobすればよかったような
151:名無しさん＠編集中 (ｽﾌﾟｯｯ Sdc1-I/6S)
17/04/08 00:55:21.46 yDtOaJW8d.net
参照しているフレームの情報を利用したいんだけど、どうすればいいかな？
x264_adaptive_quant_frameのところを利用できるのが理想です。
152:134 (ﾜｯﾁｮｲ 7fa3-V7Gz)
17/04/15 18:54:30.25 +/NipqGl0.net
あれから出力されたストリーム詳しく見たりしてたけど、
reconfigじゃインタレとプログレの切り替えはできないことが判明して
プルダウンのときはdelta_poc_bottomがゼロになるように改めて修正した
mpc-hcでフレームが一瞬戻ったりってのもなくなったし、
FFmpegでデコードしてRFFフラグをちゃんと取得できるのを確認したから、
規格上も問題ないストリームになったかな
>>144
pdfile-inはこんな感じ↓
URLﾘﾝｸ(github.com)
153:名無しさん＠編集中 (ﾜｯﾁｮｲ c7e1-RZRQ)
17/04/15 19:27:23.01 eAFMSi9o0.net
>>152
なんか本当に形になるとは思ってなかった
ありがたくウォッチさせてもらうは
154:名無しさん＠編集中 (ﾜｯﾁｮｲ ff79-V7Gz)
17/04/15 23:49:50.26 EpfRbE3V0.net
>>152
おつかれ
覗いてくるわ
155:名無しさん＠編集中 (ﾜｯﾁｮｲ c7b6-XBGH)
17/04/16 08:46:32.41 nhrM+GHT0.net
win専用なのか
残念
156:名無しさん＠編集中 (ﾜｯﾁｮｲW bfaa-ccID)
17/04/19 23:12:51.43 SeBvsYch0.net
5.1ch用に前処理しなくていいのが楽だなあ
157:名無しさん＠編集中
17/05/01 23:07:01.47 42uPSlD30.net
あげ
158:名無しさん＠編集中
17/05/05 03:04:58.69 FdjoRNe60.net
Ryzen 1700環境を手に入れたんだが、どんなに設定を弄ってもCPU使用率100％いかないんだが
同じような現象起きてる人いる？
AviUtl x264GUIからx264(2762)でエンコしてるんだが、どんなに重い設定にしても
aviUtl 8% x264 78%くらいのCPU使用率にしかならない。
aviUtl側はフィルタ全部外して、x264の軽い設定だとaviutl側で20％くらいCPUを使っているので
aviUtlがネックになっているわけでもなさそう。
なんかせっかくの16スレッド環境を無駄にした気がしてならない。
159:名無しさん＠編集中
17/05/05 03:22:17.02 PxrPz4xg0.net
>>158
AviSynth+のMT版に以降して、Prefetch(16)を試してみたら
160:名無しさん＠編集中
17/05/05 03:24:02.13 qcN7u1qj0.net
x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い
161:名無しさん＠編集中
17/05/05 07:53:47.99 YZ3yL0J800505.net
2つ並列にエンコすれば100%行くよ
162:名無しさん＠編集中
17/05/05 08:01:00.68 YZ3yL0J800505.net
Ryzen7ならL3キャッシュが4コアずつに分かれてるから
タスクマネージャーの関係の設定でAviUtlの使用コアを若い方8個と後ろの方8個に分ければいいと思う
163:名無しさん＠編集中
17/05/05 09:24:19.06 nc8W/xjM00505.net
>>158
aviutlスレにも書いたけど1本のエンコードで100%は無理
それでもAviutlと合わせて80%越えてたら十分でしょ
164:名無しさん＠編集中
17/05/05 09:30:26.82 +B6luGJ/00505.net
x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから
80%近く出てるなら十分だと思うけどな
avisynthで複合型のフィルターなんか使うと20%以下もざらにあるぞ
165:名無しさん＠編集中
17/05/05 13:19:52.74 FdjoRNe600505.net
まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。
x264のチューニング入るまでは開いたCPUでBONIACでも回しておくか。
166:名無しさん＠編集中
17/05/05 13:45:24.01 3AEMG+VU00505.net
最適化はもう限界に近いでしょ
アルゴリズム的に並列作業が増やせないものは仕方ないよ
今でも使用率上がってても大半の計算結果は途中で捨ててるくらいだし
167:名無しさん＠編集中
17/05/05 14:10:53.60 +B6luGJ/00505.net
x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから
結局の所は使うフィルター次第という話になってくる
avisynth+にフィルターをMTに対応させる機能もあるけど不具合と限界があるから1本の処理に拘るんじゃなくて
2本3本と処理する本数を増やした方が悩まなくて済むとおもうぞ
168:名無しさん＠編集中
17/05/05 14:17:45.17 3AEMG+VU00505.net
5960X環境だけどUt_videoのavi食わせてるだけなのに100％なんていかないよ
80%くらいをうろつく
169:名無しさん＠編集中
17/05/05 14:22:07.27 I4yKE2ol00505.net
ベンチスレ見てても多コアなやつは100%までいってなかったような
170:名無しさん＠編集中
17/05/05 15:14:52.02 3QEgKuQF00505.net
実際4コアで十分
それよりも動作クロック
171:名無しさん＠編集中
17/05/05 16:51:23.07 7L1WkNvu00505.net
CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。
エンコ速度に注視しろって事も付け加えられていたようん。
172:名無しさん＠編集中
17/05/05 18:42:52.11 /ft2Zb9F00505.net
マルチプロセスでスレッド数を減らすことを意識したほうがいい
173:名無しさん＠編集中
17/05/05 19:47:46.78 IyQHVJhz00505.net
>>168
それぐらいが丁度いいんじゃないの？
80~90%ぐらいが
174:名無しさん＠編集中
17/05/06 10:17:17.95 e0PV2k/30.net
いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが
TS抜きした映像ソースを10bitでエンコする意味ってあるのかな？
TS自体が8bitだった気が・・・
175:名無しさん＠編集中
17/05/06 10:24:24.11 D2u31DZA0.net
なんで10bitエンコがいいのかぐぐればすぐわかること
176:名無しさん＠編集中
17/05/06 10:42:00.24 oUC6MMIta.net
>>174
tsそのままだとあまり意味無いね
なんらかの技術で10bit精度に補間したものを改めて10bitで収録し直すみたいな形ならともかく
177:名無しさん＠編集中
17/05/06 11:14:13.52 39bf1dhz0.net
>>174
なかなか面白い理論だ
178:名無しさん＠編集中
17/05/06 11:42:04.09 e0PV2k/30.net
>>175-177
あっ、なんか意図が伝わってなくてスマソ。アスペなもんで。
8bit深度に大してH.265で採用されている10bit深度の画質的メリットはもちろん理解
しているんですが、ソースが8bit深度の映像を10bitで出力したところで画質向上には
ならないんじゃないかなと思いまして。
いろいろ調べてもTSソースを10bit補間してエンコしたみたいな話は見かけないから
そもそも10bitエンコ自体普及してないのかなぁ・・・
最近閉鎖で騒がれているnyaaとかには10bit精度でエンコされた動画でわざわざ
アップしている職人もいたと聞くが。
179:名無しさん＠編集中
17/05/06 11:43:14.34 BycummCk0.net
hevcかどっちか忘れたけど素のまま10bitエンコするだけでも
多少の良い効果は得られるらしい
だからデメリットはHWデコードが対応してないと重くなるぐらいかな？
180:名無しさん＠編集中
17/05/06 11:49:35.72 BycummCk0.net
onedriveにアドレス残ってた
ｽﾚﾘﾝｸ(avi板)
ここの70番あたりを読むと8bitソースを10bitなモードでエンコードしても効果あるということらしい
181:名無しさん＠編集中
17/05/06 11:51:14.45 oUC6MMIta.net
>>179
それ言う人がいるけど勘違いしてると思うよ
D-A変換されたものがそのまままた10bitにA-D変換されて記録されるだけの事だから
同じD-A変換のアルゴリズムを使ってる限り8bitエンコードも10bitエンコードも変わらないよ
182:名無しさん＠編集中
17/05/06 11:56:52.66 BycummCk0.net
デコードしてもアナログ信号にはならないんじゃ？
183:名無しさん＠編集中
17/05/06 11:58:20.20 zOt9cvyd0.net
jpegをjpegで圧縮するような状態だったのを
jpegをpngで圧縮する程度の効果はあるってことではないの
184:名無しさん＠編集中
17/05/06 12:01:33.55 s7pzBEcM0.net
主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ
なので、バンディングが気にならない人は、やる必要はあまりないかと
理屈はともかくいろんな人が検証した結果効果があると認められてる
まあ、自分で試してみればいい
185:名無しさん＠編集中
17/05/06 12:09:35.26 oUC6MMIta.net
色深度の話は圧縮とは別で
たとえ可逆圧縮だったとして8bitを10bitで記録しても8bitの深度にしかならないよ
>>180で展開されてるのはデコード時のディザの話で
これはつまりデコード時にディザを付加してるのだからデコーダーの補間の話になる
このデコーダーで8bit映像をデコードするのとそれを10bitで縁jコードした映像は変わらない
つまりこのデコーダーを使う限り8bitのソースで充分という事になる
186:名無しさん＠編集中
17/05/06 12:18:26.14 oUC6MMIta.net
>>184
8bitの元ソースを8bitでエンコードしてバンディングが出るのはビットレートが低すぎるからだろう
近似値の平滑化の度が過ぎて目で見て分かるほど差が出てしまったという事だ
10bitでエンコードするよりその分8bitでビットレートを高くした方が良いと思うがな
187:名無しさん＠編集中
17/05/06 12:33:19.85 s7pzBEcM0.net
まあ、そう思うのは自由
188:名無しさん＠編集中
17/05/06 13:57:53.04 mHEFOYoh0.net
flash3kyuuDeband()
dfttest()
smoothgrad()
GradFun3()
このあたり使えば、補間してくれるよ
189:名無しさん＠編集中
17/05/06 14:05:41.78 e0PV2k/30.net
>>188
()がつくということは失笑するレベルなのか。
190:名無しさん＠編集中
17/05/06 14:10:47.29 PeTSKErj0.net
ミーム汚染だ
191:名無しさん＠編集中
17/05/06 14:17:17.40 QiKKyfSe0.net
>>189
マジで言ってるのかAviSynth知らないのか判断に迷う
192:名無しさん＠編集中
17/05/06 14:18:00.36 mHEFOYoh0.net
>>188
関数だからやぞ
avisynthの
193:名無しさん＠編集中
17/05/06 14:19:14.61 2p+oHv330.net
おお…
194:名無しさん＠編集中
17/05/06 14:22:31.95 QiKKyfSe0.net
生tsが
195:名無しさん＠編集中
17/05/06 15:43:21.65 BycummCk0.net
な、懐かしい流れ
数年ぶりな気がする
196:名無しさん＠編集中
17/05/07 17:36:52.55 IeCbXKOD0.net
失笑って発想はなかったわw
197:32
17/05/08 07:50:55.40 6610UigA0.net
>>184
lavつかって再生すると、結局あんまりでないんだよなぁ
198:名無しさん＠編集中
17/05/08 08:34:16.75 gNgcHkdkM.net
バンディングはmadVRでもかなり抑えられるしな
199:名無しさん＠編集中
17/05/08 21:16:52.82 6/2ByMXh0.net
>>186
8bitでバンディングを出なくするにはディザを残す必要があるからBD並みのビットレートが必要
少なくともフルHDで10Mbps以上。x264だとcrf=12程度が限界
だからTSを圧縮するには実質的に使えない
200:名無しさん＠編集中
17/05/08 23:25:36.38 fN8ySGc20.net
ジョーク乙
201:名無しさん＠編集中
17/05/22 11:29:16.71 GZMyMciJ0.net
ｒ2829
x86のAVX-512がらみが多くて殆ど関係ないかな
202:名無しさん＠編集中
17/05/22 17:20:32.96 U7KhlFgq0.net
Xeon Phi用？
203:名無しさん＠編集中
17/05/22 18:26:30.18 +CZlsLvY0.net
commitの内容くらい読んだら
204:名無しさん＠編集中
17/05/22 23:59:56.47 U7KhlFgq0.net
そうだったら面白そうだったのに違うのか。発売まであと1ヶ月ちょっと
205:名無しさん＠編集中
17/05/23 09:39:19.86 Mmk8+JSl0.net
なんかAVX512にもいろいろなバージョンがあるらしい
206:名無しさん＠編集中
17/05/23 11:16:16.33 7zgCm2Fx0.net
AVX-512に対応しても、256bitを2クロックで実行だったらあまり意味がなさそう
207:名無しさん＠編集中
17/05/23 12:39:38.16 GV0woxuQa.net
>>205
今のところ2種類だよね
Phiと、これから出るSkylake(Kabylake)-X
違ったら訂正よろ
208:名無しさん＠編集中
17/05/26 14:50:30.90 Mh7fDvUt0.net
>>174
テレビは8bit
ブルーレイは10bit
これが基本
209:名無しさん＠編集中
17/05/26 20:40:12.96 MHU9y7Qv0.net
メガドライブは16bit
210:名無しさん＠編集中
17/05/26 22:07:25.45 unoKqH810.net
>>208
ブルーレイも8bitだろ
211:名無しさん＠編集中
17/05/26 23:34:59.38 IXEtfAo30.net
一応12bitできるお
URLﾘﾝｸ(www.phileweb.com)
212:名無しさん＠編集中
17/05/27 00:28:02.17 KXKBbCuQ0.net
>>211
マジかw よく見たら俺の持ってるUB90も対応してたわwww
これをデコードできるソフトがあるのか知らんけど
213:名無しさん＠編集中
17/05/27 01:49:30.71 sgij9sLk0.net
ジブリとか
214:名無しさん＠編集中
17/05/27 02:22:49.77 KXKBbCuQ0.net
そういう意味じゃなくて、MGVCのtsをx264でエンコするために12bitデコードできるPC用のプログラムが手に入るのかって話
215:名無しさん＠編集中
17/05/27 02:28:51.98 yOi/kiCt0.net
＞MGVCのサブストリームデータには特別な暗号化が施されており、これをデコードするためには、ハードウェア側にカギを仕込む必要がある。
と書かれているがPCでできるのかな
216:名無しさん＠編集中
17/05/27 02:57:54.84 KXKBbCuQ0.net
まぁパナの一部の機種しかデコードできないようなオレオレコーデックに対応しても旨味がなさすぎるし無理だろう
今ならUHD BDがあるからこんなコーデック使う必要ないし
217:名無しさん＠編集中
17/05/27 03:54:56.54 WaAf4/ND0.net
r2833kMod来てるで
218:名無しさん＠編集中
17/05/27 04:03:02.41 WaAf4/ND0.net
って日本アク禁解除してくれたのね
219:名無しさん＠編集中
17/05/27 07:31:37.05 JFb4SnYO0.net
ほんまや
220:名無しさん＠編集中
17/05/29 01:49:30.77 a0uJfekx0.net
ここで聞くのがいいのか分からんけど、x264の8bitで俺的アニメ最適設定とか実写最適設定的なのを参考までに教えてくれる人いないですか...
221:名無しさん＠編集中
17/05/29 02:13:44.22 2fXE0oZU0.net
わからないならデフォで
222:名無しさん＠編集中
17/05/29 09:32:10.21 t/pwYFLr0.net
>>220
とりあえずプリセットとプロファイルを指定して
そこれプラス --b 3 --ref3 でBフレームとrefの制限だけしとけばおｋ
あとおまじないで --aud --nal-hrd も追加しとけばいい
223:名無しさん＠編集中
17/05/31 10:34:57.77 8JeQCHhC0.net
x264guiEx_2.51v2
224:名無しさん＠編集中 (ﾜｯﾁｮｲ bf32-gQJE)
17/06/28 22:42:51.76 RVxNfKli0.net
R2851きてんな
225:名無しさん＠編集中 (ﾜｯﾁｮｲ 4232-POtP)
17/07/03 17:23:55.63 EoHdrbIh0.net
各ビルドも来ましたな
226:名無しさん＠編集中 (ﾜｯﾁｮｲ 0632-wjSU)
17/07/03 22:21:40.62 oRGsh6jC0.net
そういうのは今期入る前にしてくれｗ
227:名無しさん＠編集中 (ﾜｯﾁｮｲ 0939-WwN4)
17/07/03 22:25:29.32 7K3B3cxp0.net
今ならまだやり直せるぞ
228:名無しさん＠編集中 (ﾜｯﾁｮｲ 0632-wjSU)
17/07/04 02:01:36.14 Zsfek4ze0.net
まあたしかにそうだわ
229:名無しさん＠編集中 (ﾜｯﾁｮｲ c117-CicO)
17/07/04 09:47:04.81 kbRsHYbA0.net
画質的に向上する余地なんてないんだから
気にしなくてもよくね？
230:名無しさん＠編集中 (ﾜｯﾁｮｲ 0632-wjSU)
17/07/04 12:08:01.34 Zsfek4ze0.net
AVX-512関係ばっかりだし
確かに気にしなくて良いんだけどね
日記になってしまうが、
たまたま、今期はバージョンあげようかなとか迷ってたんだよ
ただそれだけさ
231:名無しさん＠編集中 (ﾜｯﾁｮｲ d74f-8cuI)
17/07/08 18:00:56.36 a+acXXxz0.net
x265に乗り換えてからx264の最新ビルドに対する興味が薄くなった。
232:名無しさん＠編集中 (ﾜｯﾁｮｲ 9791-KuRC)
17/07/08 19:47:46.47 6acSBIHO0.net
>>231
嘘つき乙
233:名無しさん＠編集中 (ﾜｯﾁｮｲ f7d0-lfeO)
17/07/09 13:46:24.52 Dm7e95yZ0.net
赤潰れやハイライト削りすぎは改善れれる余地はあるの？
234:名無しさん＠編集中 (ﾜｯﾁｮｲ d739-zXdO)
17/07/09 16:10:15.77 orURU0+Q0.net
赤色が劣化してるように見えるのは色空間の問題が大きいからなぁ・・・
x264だと--chroma-qp-offsetを弄ってみて改善するかどうかじゃないかな
ハイライト削り過ぎってのは分からないけどcrfやaqやpsy-rdの調整でどうにかならない？
235:名無しさん＠編集中 (ﾜｯﾁｮｲ f7d0-lfeO)
17/07/11 10:30:45.47 dCODISON0.net
>>234
赤色の劣化の原因は色空間なの？元画はなんともないのに？
赤の認識は国や地域で大きく違うから、それが反映されて無視されてるのかと思ってた
ハイライト削ると、バンディングもどきが現れたり
236:名無しさん＠編集中 (ﾜｯﾁｮｲW 77ea-Gx3G)
17/07/11 12:04:04.12 IJasOprA0.net
ダウンサンプリングのお話
URLﾘﾝｸ(shinshu.fm)
URLﾘﾝｸ(shinshu.fm)
URLﾘﾝｸ(shinshu.fm)
237:名無しさん＠編集中 (ﾜｯﾁｮｲ b7db-zXdO)
17/07/11 22:11:53.59 Y5S24hR30.net
元画も420だと思うが違うのか？
238:名無しさん＠編集中 (ﾜｯﾁｮｲ 6bd0-w0es)
17/07/15 11:33:03.36 QOPZli+L0.net
--chroma-qp-offsetは効果がなかったですね
赤が強いと鮮やかに感じるからx264は低ビットにしても綺麗に見えるんだろうなと勝手に解釈
赤のライト一色のシーンの破綻はきついものがある
元画がフルレンジのケースのことだったの？
jpegだと確かにYUVでもフルレンジ使うけど
239:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 12:01:33.59 3m6njqCx0.net
サンプルの画像でも貼ってくれないと何のこと言ってるのか分からない
240:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/15 12:09:12.71 D4kjNe6l0.net
有名な話ではあるけど8bit ビデオコーデックの限界でなかろうか
量子化のやつを改変するしかないんじゃね（すごい昔に流行ってた気がする
241:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/15 12:09:31.23 2zI05HpD0.net
>>238
・元画と言ってるのは、どういうソフト（やカメラなど）でどのように作った映像なのか。RGBなのかYUVなのか。
>>237が言ってるように元画がYUV4:2:0の映像なら元画の時点で赤の劣化が起きてると思うのだが。
・「ハイライトを削る」とは具体的にどのような処理を行っているのか。
このあたり、ちゃんと詳しく書いた方がいいと思うよ。
あとフルレンジかどうかは今回の件についてはあまり関係ない。
242:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 13:41:12.57 3m6njqCx0.net
> ハイライト削ると、バンディングもどきが現れたり
読み直したら結局バンディングのことか
エンコしたらディザが消えてバンディングが出てくるから10bitでエンコするっていういつものやつ
243:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 13:56:32.08 3m6njqCx0.net
バンディングのディザによる解決は害悪だよね
10bit、12bitにすれば解決する問題をビットレート特盛りにして力技で解決
エンコしたら劣化が目立つから初心者にはエンコーダのせいにされてしまう
もっと早くから放送もBDも10bit化すべきだったな
244:名無しさん＠編集中 (ﾜｯﾁｮｲ 6bd0-w0es)
17/07/15 14:45:47.73 QOPZli+L0.net
つくづく、地デジもBDも10bith264と思いきればよかったのにと思う。
家電開発者のインタビュー見てると、高画質をうたってるテレビはほぼ10bit対応と言ってるしね。
245:名無しさん＠編集中 (ﾜｲｴﾃﾞｨ MM0a-z+eH)
17/07/15 19:56:53.20 82DwIzbfM.net
BSで新しい衛星を立ち上げて地上波のサイマルをH264使ってやればいいのにな
で、地上波の帯域をスマホとか移動体通信に使う
246:名無しさん＠編集中 (ﾜｯﾁｮｲWW 3a94-kE75)
17/07/15 20:03:20.59 iDHnQGIE0.net
>>245
もし出来たとしても結局版権問題でBSジャパン（テレ東と同時にBSで放送する予定だった）と同じルート辿りそう
247:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 20:09:49.68 3m6njqCx0.net
BSで4KをHEVCでやるんだから今更必要ないだろ
4Kは10bitだよ。8bitは規格にないからな
248:名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-qt4g)
17/07/16 05:48:40.57 oHYcqkkX0.net
ハイライトを削るって結局何だったのか
249:名無しさん＠編集中 (ﾜｯﾁｮｲ 4611-k5cp)
17/07/16 10:43:14.36 M3psfPBz0.net
16 : 宇野壽倫の告発2017/07/11(火) 19:22:00.17 ID:5/TEkUSo
皆さん十分にご注意ください
URLﾘﾝｸ(ameblo.jp)
17 : 宇野壽倫の告発2017/07/11(火) 19:22:46.64 ID:5/TEkUSo
死ね！キモブサ川高志!!
250:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 19:40:58.06 HpejTqPk0.net
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
ｽﾚﾘﾝｸ(jisaku板:796-797番)
251:名無しさん＠編集中 (ﾜｯﾁｮｲ 6bd0-w0es)
17/07/17 20:48:45.94 8laiMmMa0.net
エンコの時にハイライトを捨ててるんだろう
ハイライト自体がわからんなら説明のしようがない
252:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-A9YL)
17/07/17 20:58:05.21 RzYBtVR60.net
>>251
「だろう」って、「ハイライト削りすぎ」という表現を持ち出したのはお前さんなのに、なぜ他人事・・・。
個人的にはカラーグレーディングで高輝度部分をちょっと下げたみたいなことを連想してたけど
「エンコの時にハイライトを捨ててる」ってのが何を指してるのかさっぱりわからん。
253:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/17 23:07:12.77 koURX1Uq0.net
自分の世界しか見えてないから他人に説明できないんだよ。きっと
254:名無しさん＠編集中 (ﾜｯﾁｮｲ 7e32-S4qQ)
17/07/19 11:46:55.18 TJhHh62l0.net
ハイライトは最も明るく目立つ部分だから白付近をごっそりクリップしたんじゃないの
俺にはその処理にデメリットしか感じないけどそいつなりに意味があるんだろうし好きにすればいいよ
255:名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-qt4g)
17/07/19 17:32:07.21 EfL8exLW0.net
> 白付近をごっそりクリップ
ごっそりクリップってなんや・・・
256:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/19 18:38:31.40 82aWZrRs0.net
自演じゃあるまいし
大したことないネタに反応しなさんな
257:名無しさん＠編集中 (ﾜｯﾁｮｲ 6f4f-pmGF)
17/07/19 20:21:16.53 oXVd+d990.net
目玉のおやじの白い部分をごっそりクリップするとグロ映像になるよな
258:名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-qt4g)
17/07/19 20:44:28.35 EfL8exLW0.net
>>257
もともとグロ説
目立つところをおかしくするのって、psy-rdを負側にかけるとかそういうトリッキーなオプションじゃないと出来ないのではなかろうか
259:名無しさん＠編集中 (ﾜｯﾁｮｲ 4a06-z+eH)
17/07/19 22:00:05.01 WJsftwZt0.net
mp4boxで複数音声をmuxする場合、lang=jpnで指定してるんだけど、
複数音声が同じ言語の場合ってどうすればいいかな？
langで同じコードを設定するとPS3でうまく言語が切り替わらなくなる。
オーディオトラック1は英語、2は日本語とか、違うコードでは問題ない。
260:名無しさん＠編集中 (ｱｳｱｳｳｰT Sa08-svru)
17/07/19 22:07:40.23 6NjQsSJPa.net
違う言語で割り当てちゃえばいいよ
あれは1番2番と割り振ってるのと同じでただのフラグでしか無い
261:名無しさん＠編集中 (ﾜｯﾁｮｲ 5f91-E/h9)
17/07/23 01:42:18.96 xY7oCU1a0.net
もの凄いボケボケのブロックノイズ塗れになった
と思ったら--crf 210 とかなってたよ(´･ω･｀)
262:名無しさん＠編集中 (ﾜｯﾁｮｲ 47d1-QK4i)
17/07/23 11:09:40.44 6n3bIMM40.net
210ｗ
263:名無しさん＠編集中 (ｱｳｱｳｶｰ Safb-RwsK)
17/07/23 12:15:26.24 CMOEbANca.net
crf 210って出来たのか…
264:名無しさん＠編集中 (ﾜｯﾁｮｲ 6739-dw5s)
17/07/23 12:17:01.42 keAstF8G0.net
確か51以上を指定すると51に丸め込まれたはず
265:名無しさん＠編集中 (ﾜｯﾁｮｲ dfef-3g0N)
17/07/23 15:31:22.86 R4sZ2XaX0.net
crfmaxパラメータあたりで上限変えれんじゃね。ゴミ画質に劣化するだけだから誰も触れないけどw
266:名無しさん＠編集中 (ﾜｯﾁｮｲ 4744-3EN1)
17/07/23 17:06:06.84 kCVUaSmw0.net
>>265
-crf_maxも--crf-maxもCRF+VBVの時にRF値を制限するためのオプションであって
--crfで指定できるRF値の上限を変えるもんじゃないだろとマジレス。
>>264が言ってるように、--crfは51以上を指定しても51にされるだけだね。
267:名無しさん＠編集中 (ﾜｯﾁｮｲ 47d1-QK4i)
17/07/23 17:10:17.75 6n3bIMM40.net
rc-lookaheadを300にしてるとか言ってる奴も昔どっかで見たけど250に丸め込まれるよね
268:名無しさん＠編集中 (ﾜｯﾁｮｲ a7db-RieY)
17/07/23 18:51:08.05 y76xDWj10.net
丸め込むwww
269:名無しさん＠編集中 (ﾜｯﾁｮｲ 47d1-QK4i)
17/07/23 19:57:08.39 6n3bIMM40.net
響きが良いよな
270:名無しさん＠編集中 (ﾜｯﾁｮｲ 7f9b-t6T/)
17/07/23 23:25:51.62 qmXIkSVi0.net
丸込め味噌
271:名無しさん＠編集中 (ﾜｯﾁｮｲ 7f91-CrqW)
17/07/24 01:02:59.95 5TMClw7W0.net
マルメコムX
272:名無しさん＠編集中 (ﾌﾞｰｲﾓ MM8b-oZ9i)
17/07/24 07:34:49.14 R5b7QqQjM.net
クリッピングの意味で丸め込むってウチでも使うけど、そんなに変か？
273:名無しさん＠編集中 (ｱｳｱｳｳｰT Sa6b-rqTR)
17/07/24 08:10:53.46 iWTL2Muga.net
いｙｓ，別におかしくは無い
274:名無しさん＠編集中 (ﾜｯﾁｮｲ a717-QK4i)
17/07/24 09:55:51.70 j+q0aY7l0.net
草はやされるほどおかしいとは思わないが
クリッピング（切り捨て）を丸め込むとは言わないかな（自分なら
275:名無しさん＠編集中(ﾜｯﾁｮｲ 7f91-dkZs)
17/07/24 10:00:00.79 6pYv2j8E0.net
どちらかと言うとroundingの感じ
276:名無しさん＠編集中 (ﾜｯﾁｮｲ 47d1-QK4i)
17/07/24 17:08:27.73 sOZIAhU50.net
このスレもどんどん丸め込んでいこうぜ
277:名無しさん＠編集中 (ﾜｯﾁｮｲ dfe2-/jiT)
17/07/24 18:29:42.17 snuqTaT40.net
>>267
これ本当？
278:名無しさん＠編集中 (ﾜｯﾁｮｲ 4744-3EN1)
17/07/24 18:47:51.52 0kMaYgwF0.net
>>277
試してログ見れば本当だってすぐにわかるだろ。疑うくらいならさくっと試しなよ・・・。
279:名無しさん＠編集中 (ﾜｯﾁｮｲ 47d1-QK4i)
17/07/24 20:08:14.89 sOZIAhU50.net
>>277
rc-lookaheadはkeyintと同じ数値までか、250までだったと思うよ。
keyintが300だったとして、rc-lookaheadも300にしても250まで丸め込まれちゃうはず。
keyintが120なのにrc-lookaheadを250とかにしても「keyintまで」のはずだから、この場合もrc-lookaheadは120に丸め込まれちゃうはず。
間違えてたらごめンゴ
280:名無しさん＠編集中 (ﾜｯﾁｮｲ dfe2-/jiT)
17/07/24 21:06:26.15 snuqTaT40.net
さくっと試したら>>267、>>279の言う通りだった
どうもです
281:名無しさん＠編集中 (ﾜｯﾁｮｲ bf39-dw5s)
17/07/25 21:52:32.18 v9eI6NJr0.net
x264 sandboxによるとx264が大きく変わるようだ
1つのバイナリで8bit/10bitを切り替えて出力できるらしい
切り替えには--output-depthを使うようだ
この変更でソースの構造が大きく変わってx264 mod版に充てられてるパッチが殆ど使えなくなるんで
mod版ビルダーの更新が遅れるかもしれない
282:名無しさん＠編集中 (ﾜｯﾁｮｲ dfef-3g0N)
17/07/26 14:20:37.34 WcuuDM2d0.net
そういう動画はプレイヤーによっては再生できなくなるんじゃね。
たとえばスマホとかゲーム機とか
283:名無しさん＠編集中 (ﾜｯﾁｮｲWW 6700-RYCd)
17/07/26 14:23:24.71 EsczvBkX0.net
エンコ時間ヤバそう
284:名無しさん＠編集中 (ﾜｯﾁｮｲ dfef-3g0N)
17/07/26 14:28:30.91 WcuuDM2d0.net
スマホやゲーム機は10bit/12bitの動画とかHWデコーダが対応してないからSW再生しかできないんだよな
特にスマホはCPUの性能がカスだから、コマ落ち＆音ズレ＆ブロックノイズだらけで悲惨なことにw
285:名無しさん＠編集中(ﾜｯﾁｮｲ 7f91-dkZs)
17/07/26 17:22:46.73 DLRRNfaO0.net
H.265 Main 10に対応したハードウェアデコーダーは増えてきているけど、H.264 High 10に対応する物は一向に増えないな
286:名無しさん＠編集中 (ﾜｯﾁｮｲ 4744-3EN1)
17/07/26 17:54:08.90 YGph3AEt0.net
>>285
増えるも何もH.264の10bitのHWデコードに対応してる物なんて無いんじゃ？DXVAの規定も無い。
287:名無しさん＠編集中 (ｱｳｱｳｳｰ Sa9f-/uhd)
17/07/27 09:39:48.43 sjopS/xXa.net
ピンク色をエンコードすると
どんなにCRFが高くても色合いが変わって
ピンクの周辺にブラウン管時代の偽色みたいなもんが出るんだけど回避できない？？
動画として見るとチラチラと色が変わって目によろしくない
288:名無しさん＠編集中 (ｱｳｱｳｳｰ Sa9f-/uhd)
17/07/27 09:44:57.70 utTRrNsfa.net
低くても、か
12とか15でやってもピンク色が変になり
2でやっても同じ
289:名無しさん＠編集中 (ｽｯﾌﾟ Sd2a-Lvg/)
17/07/27 10:40:31.42 8W60h2thd.net
ないわ、それ元から単色でピンク色なのか？
290:名無しさん＠編集中 (ﾜｯﾁｮｲ 7b17-ZO1u)
17/07/27 12:03:39.98 nXagFz4P0.net
RGB -> YUVへの減食ミスとかじゃね
自分はそっち方面に詳しくないから的外れ化もしれないけど
291:名無しさん＠編集中 (ﾜｯﾁｮｲWWWWWWW)
17/07/27 12:17:07.60 LQj6bobK0.net
固定品質のQP0(可逆)でもそれがでるのかどうかを確認しよう
あとはYV12なのかYUY2なのかそれ以外なのか
292:名無しさん＠編集中 (ｱｳｱｳｳｰ Sa9f-/uhd)
17/07/27 12:19:34.02 0OZcuULva.net
URLﾘﾝｸ(www.rupan.net)
パスワード abcd
こんな感じ
尼子の文字の隣にある家紋色が違ってしまい
動くとチラチラして見える
ピンクかと思ったら拡大したら群青とオレンジだった
293:名無しさん＠編集中 (ﾜｯﾁｮｲ eaea-AvKj)
17/07/27 12:32:38.83 K7BmCOMY0.net
>>290やな
AviUtl使ってるならUVダウンサンプリングフィルタを使うとマシになるかもしれない
294:名無しさん＠編集中 (ｱｳｱｳｳｰ Sa9f-/uhd)
17/07/27 12:36:17.13 ybI0Iwdva.net
ログを見るとYUY2 -> nv12pになってる
キャプチャソフトはfraps
これの内蔵CODECだと思うけど圧縮録画されているソース
QP 0 にしても違う色になりますな
なんかソースよりクッキリしてるのが妙なんやけども
295:名無しさん＠編集中 (ｱｳｱｳｳｰ Sa9f-/uhd)
17/07/27 12:56:02.21 ybI0Iwdva.net
UVダウンサンプリングフィルタをやってみたところ、
群青色の部分がおかしいもののオレンジ色の部分は遥かにマシになりましたわ
どもどもみんなありがとう
x264でなくまさかaviutlの色変換のほうの話だったとは
ここら自分もあまり詳しくないもんで
296:名無しさん＠編集中 (ﾜｯﾁｮｲ 2a11-VRLg)
17/07/27 18:24:43.14 ApvsFLE00.net
Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
それ調整する為にいつもＹＣ伸張で0-245-13-8補間なしで適当に調整してるわ
フィルターとか使い方よくわかってないから参考にならないだろうけど
これでTSファイルなら元とエンコと色ほぼ同じノイズとか他の要素でじっくり見たら多少違うこともあるだろうけど
比較しても色あせ感はないように思う
他の設定が間違っててこんな調整が必要なのかもしれないけどｗ
最初色調整とかしてたけどそれだとfpsが負荷おおきいからこれにでやってる
スレチでした すみません
なんかオレンジよりみどりが違う気がしたから自分も最初色の違いでみどりとか黒系がちがう気がして
これにしてる
297:名無しさん＠編集中 (ﾜｯﾁｮｲ 7b17-ZO1u)
17/07/27 18:56:12.32 nXagFz4P0.net
>>295
aqもpsyも0.2ぐらいまで下げてもいいはず
298:名無しさん＠編集中 (ｽｯﾌﾟ Sd2a-Lvg/)
17/07/27 20:29:50.61 o8yj8BJid.net
俺も色調整は再生時にする様にしたわ
299:名無しさん＠編集中 (ﾜｯﾁｮｲ ce32-ZO1u)
17/07/28 01:13:43.98 whDN0SiA0.net
読んでると色変換設定ミスの可能性高いな
詳しく知りたきゃaviutlスレ訪ねたほうがいい
300:名無しさん＠編集中 (ﾜｯﾁｮｲ 4f44-2AKC)
17/07/28 02:01:37.70 w5umuGab0.net
>>295 >>299
なんとなく解説画像作ってみた。
FrapsのFPS1コーデックは変に古いものを使ってでもいない限りRGB形式らしい。
AviUtlはRGB→(YC48)→YUY2変換時に左側の色差だけ取るので
RGBソースの場合はUVダウンサンプリングとかで平均色差をとった方がいいよという話。
RGBソースをAviUtlでエンコする場合はUVダウンサンプリングで平均色差とった方がいいよというお話
URLﾘﾝｸ(2sen.dip.jp)
あと、>>292のencoded.bmpが変に明るくなってるのが気になった。
多分再生ソフトか何かで色補正が効いてる状態で撮ったもんだと思うけど、
サンプルとして出すには不適切なので、AviUtlに読み込んで撮ったものとかを出した方がいいと思う。
>>296
>Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
それは無い。どこかしらで何か変なことをしてるだけと思われ。
301:名無しさん＠編集中 (ﾜｯﾁｮｲ 2a11-VRLg)
17/07/28 02:08:12.93 69plILf20.net
自分は分ってる風だけのスレなんて無駄じゃないか
どうせ書くならヒントくらい書くべき
エンコってそもそも圧縮するときに色も変わる(元から劣化）それをかわすのにフィルター使うじゃん
302:名無しさん＠編集中 (ｱｳｱｳｶｰ Safb-Kwif)
17/07/28 02:12:25.95 8K0HBSqoa.net
スレェ…
303:名無しさん＠編集中 (ﾜｯﾁｮｲ eaea-AvKj)
17/07/28 02:16:05.63 mesdGCzp0.net
何もフィルターかけてないのに色が変わるんだったら可逆圧縮なんて成り立たないでしょうに
colormatrixの設定が間違っているとかじゃないの？
304:名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-p5D+)
17/07/28 04:12:38.43 NMMi0SW90.net
ゲームのエンコの時は「拡張色調補正」の「TV -> PC スケール補正」をONにする必要があったと記憶している
それより横に少しだけ引き伸ばしてるのが最高に気持ち悪い
305:名無しさん＠編集中 (ﾜｯﾁｮｲ ce32-ZO1u)
17/07/28 05:13:52.64 whDN0SiA0.net
PCスケール補正ONとかそんな地雷情報誰が流布しているんだろうな
RGB->YUVをストレート変換しているのと同義でたぶん>>292のencoded.bmpみたいに明るさや色が変わる
色変わろうがそれでいいってんなら俺がとやかく言うことじゃないけど
てかスレチすぎる
306:名無しさん＠編集中 (ﾜｯﾁｮｲ 2aea-zURC)
17/07/28 08:38:39.66 KZhqFr090.net
そもそもORIG.bmpが正しいやり方でキャプったのかっていう問題がある
適当なプレイヤーのキャプ機能だとレンダラの影響を受けておかしくなることがある
やけに色褪せて見えるのが怪しい
307:名無しさん＠編集中 (ｽｯﾌﾟ Sd2a-Lvg/)
17/07/28 10:47:57.86 RS92JaZKd.net
もう終わった話を広げるな
308:名無しさん＠編集中 (ﾜｯﾁｮｲ 7b17-ZO1u)
17/07/28 12:46:07.10 tEyRGlbz0.net
>>300
黄色かどうか忘れたけど変わるよ
元ソースと比べないと分からないレベルだけど
>>304
Y/C伸長がいるのはリミテッドな色空間で出力したゲーム動画をRGBで録画したときだけで
PCゲームの内部キャプチャ、フルレンジ出力したものをRBGで録画したときは不要
309:名無しさん＠編集中 (ｱｳｱｳｳｰT Sa9f-Yg6j)
17/07/28 14:16:49.16 grmRJ39fa.net
うーん、h264はYUV420でエンコードするのが殆どだから>>292みたいな元画との差異の追求の話をするには
RGBに比べてYUVは色情報での解像度が低くなるとかの知識は共通認識で持っていた方が良いと思うので
テンプレに追加した方が良いのでは無いか
310:名無しさん＠編集中 (ﾜｯﾁｮｲ af44-2AKC)
17/07/28 15:47:50.94 /FJ+xJQY0.net
>>308
> 黄色かどうか忘れたけど変わるよ
変わらんでしょ。そんな問題があるなら重要情報として広く知られてるはずだし、
・そもそもソースの確認の仕方がおかしい
・入力プラグインの設定がおかしい
・入出力色空間の設定がおかしい
・colormatrixとかの設定がおかしい
・再生環境がおかしい
といったミスをしてるか、過去にあった何かしらのバグの話と混同してるか、
>>300で書いたような色変換時に必然的に起こる変化のことを勘違いしてるといったところでは。
>>309
さすがにテンプレにはいらないと思う。昔は色空間スレってのがあってそのログも色々参考にさせてもらったけど、
過疎スレだったし今更立てても需要は無いだろうし。
311:名無しさん＠編集中 (ﾜｯﾁｮｲ 2a11-VRLg)
17/07/28 16:51:41.77 69plILf20.net
>>310
ミスじゃないでしょ だからただん劣化の比喩表現
自動という素人でもできるエンコでどうやって間違えるんだ
同じモニター同じデコードで比べても色は劣化してるだし
劣化という表現を色がおかしいという言葉で言うのが問題なら訂正する
でもわかりそうなもんだけどな
312:名無しさん＠編集中 (ﾜｯﾁｮｲ af44-2AKC)
17/07/28 18:19:52.44 /FJ+xJQY0.net
>>311
何を言いたいのかよくわからない。「自動という素人でもできるエンコ」というのが
「特に何も考えずにAviUtlに放り込んでエンコ」ってことなら、それこそが問題であって、
「使い方がよくわかってなくて設定が間違ってるかもしれない」という初心者（素人）が
間違えることがある要素が>>310に書いた内容。
劣化の比喩表現と言ってるのもよくわからない。x264のエンコードによって劣化が起きてボケたり
微妙な色変化が起きたりすることはあるだろうけど、それはAviUtlに問題があるからではない。
「同じモニター・同じデコードで比べても～」と言ってるけど、colormatrixを間違えてれば
そこで変わるし、レンダラのバグやDXVA、GPUとの相性等で色が変わってしまうこともある。
そういった要素を極力排除して正しい条件で比較する必要がある。
AvsPmodやAviUtlで適切な入力プラグインで適切な設定で読み込んで比較するといった形が望ましい。
ということで、結論としては一連の設定や確認の中のどこかでミスしてるだけだと思うよ。
AviUtlに問題があるわけじゃない。
313:名無しさん＠編集中 (ｽｯﾌﾟ Sd2a-Lvg/)
17/07/28 18:24:49.11 RS92JaZKd.net
こういう切りない無駄な言い争いになるから辞めろって言ったんだ
314:名無しさん＠編集中 (ﾜｯﾁｮｲ 2639-l5iw)
17/07/28 18:26:57.66 xtqHRxYB0.net
何にせよもう終わった話だしAviUtlはスレチだからこれで終わり
315:名無しさん＠編集中 (ﾜｯﾁｮｲ af44-2AKC)
17/07/28 18:43:20.71 /FJ+xJQY0.net
そだね。何かあればAviUtlスレの方でテンプレの情報出して質問してくれればなるべく対応しま。
316:名無しさん＠編集中 (ﾜｯﾁｮｲ 2a11-VRLg)
17/07/28 18:55:44.95 69plILf20.net
うざ
317:名無しさん＠編集中 (ﾜｯﾁｮｲ 2e91-V1Wy)
17/07/28 20:23:33.33 hRx+DSbV0.net
>>316
お前の脳味噌が劣化、というか頭がおかしい
318:名無しさん＠編集中 (ﾜｯﾁｮｲ)
17/07/28 20:25:43.70 0Ig3GpzJ0.net
構っちゃだめよー
319:名無しさん＠編集中 (ﾜｯﾁｮｲ 7b23-ZO1u)
17/07/29 00:52:28.71 3sBlT6oY0.net
無知蒙昧を相手にするのは疲れる
320:名無しさん＠編集中
17/08/04 03:23:17.34 S1K7a/XdM.net
将来的にTMPGEncあたりがUltra-HD Blu-rayオーサリングに対応しそうだから規格準拠した10bitx265でつくっておきたい
けど、規格書とx265のコマンドライン見比べたらまだ対応してないっぽい
規格書には1080pのH.264も使えるって書いてあるから、ビット深度以外全部従来のBlu-ray準拠設定のx264で多分行けると思うけど
321:名無しさん＠編集中
17/08/04 23:34:32.29 ZTZ+gYb+0.net
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1 aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな＞aq-mode3
322:名無しさん＠編集中
17/08/04 23:34:54.75 ZTZ+gYb+0.net
x265と間違えました
323:名無しさん＠編集中
17/08/04 23:54:02.49 qrQ5Qflc0.net
>>320
録画規格ないのに対応するとは思えん
324:名無しさん＠編集中
17/08/09 15:58:13.85 K4o/tiYa0.net
BDRIPの動画を8bitでエンコするやつの気が知れない。
325:名無しさん＠編集中
17/08/09 16:02:33.01 cIIO/eWe0.net
BDなんかわざわざRIPしてエンコする馬鹿の気が知れない。
326:名無しさん＠編集中
17/08/09 16:03:33.06 B4PTzTTuM.net
ソースが8bitだから再エンコはバンディング低減効果しかない、というかそれが目的でしょ
最初から10bitまで対応でブルレイ規格作っとけばこういうことにはならんかったけども
まあ、どーせBDMV準拠で流さないんだから10bitでエンコして流せとは思う
327:名無しさん＠編集中
17/08/09 16:05:38.31 2AJnt09p0.net
いちいちBDをケースから引っ張り出すの嫌だから
エンコしてHDDに入れてるわ
328:名無しさん＠編集中
17/08/18 03:37:46.14 u9qCreim0.net
x264で解像度の違う２つの動画をエンコしてa.264とb.264を得たとする
これをL-SMASHで連結したいんだけど以下の手順で合ってる？
copy /b a.264 + b264 c.264
muxer -i c.264 -i 音声ファイル -o out.mp4
これで作ったmp4をmpc-hcとps3で再生してみたけど問題なかった
329:名無しさん＠編集中
17/08/19 18:17:22.65 YzeVzrl00.net
うっさい！ハゲ
330:名無しさん＠編集中
17/08/19 21:27:33.98 VsDsEh6v0.net
"問題が無かった"という証明が出来ない
331:名無しさん＠編集中
17/08/19 23:44:49.40 R/l9dL2C0.net
muken氏か聞いたら発狂しそうではある
332:名無しさん＠編集中
17/08/19 23:55:11.53 JW4EweBA0.net
盛大に音がズレそうな構文だなw
333:名無しさん＠編集中
17/08/20 21:20:22.86 iNj0lnL80.net
問題なかったって言うのはウソだった
ps3だと1440x1080と1920x1080の組み合わせなら大丈夫だったけど
1440x1080と1280x720だとダメだったわ
mpc-hcならどっちも大丈夫だった
で、オンラインのmp4parserでmp4ファイル見てみたけど、
Sample Description Boxにサンプルエントリが２つあるのは良いんだけど
どっちもwidhとheightが同じだったorz
AVCコンフィグレーションボックスの方はちゃんと違うデータになってたから、
SPSやPPSは合っててそれを読めばデコードはできるのかも
L-SMASHは途中でSPSやPPSが変わるのは対応してるけど
画面サイズが変わるのには対応してないってことかな
334:名無しさん＠編集中
17/08/20 22:22:34.58 vpjeEVa50.net
>>333
無茶苦茶なことやるなあ
muken氏が血を吹いて死ぬぞ
335:名無しさん＠編集中
17/08/20 23:47:46.91 iNj0lnL80.net
ps3の限界を探ってみた結果、2つのストリームのlevelが同じなら
画面サイズやエンコ設定（mediumとslowerとか）が違くても再生できることが分かった
1440x1080と1280x720はlevel自動にしてたから結果違うlevelになって再生できなかったけど
4.1に統一したら再生できるようになったわ
L-SMASHだとサンプルエントリのwidth,heightがデタラメな値になるけど問題ないっぽい
>>334
発端は分割エンコで--stitchable付けなかったらどうなるんだろうっていうのを確かめたかったんだよね
同じ画面サイズ・エンコ設定でも分割ごとにPPSが変わるが、
L-SMASHは複数のサンプルエントリを置くのに対応してるから
規格上は問題ないMP4が生成されるはずで、
ちゃんと実装されてるプレーヤーなら問題ないっていうのが俺の中での結論
まぁ、win10デフォのプレーヤーだとサンプルエントリが2つ以上あるmp4はどれも再生できなかったが・・・
で、それができるんなら、画面サイズやエンコ設定が違くても、できるんじゃねって思ってやってみた
336:名無しさん＠編集中
17/08/21 20:03:22.75 8aQPMi1C0.net
つーか、MP4ｺﾝﾃﾅにこだわる意味ってあんの？
337:名無しさん＠編集中
17/08/22 00:16:45.60 kQJmpuZI0.net
>>336
他に何かある？
ちなみにmkvは試したけど↓こうなった
>mkvmerge.exe --append-to 1:0:0:0 -o out.mkv a.264 + b.264
mkvmerge v15.0.0 ('Duel with the Devil') 64-bit
'a.264': Using the demultiplexer for the format 'AVC/h.264'.
'b.264': Using the demultiplexer for the format 'AVC/h.264'.
'a.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'b.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
Error: The track number 0 from the file 'b.264' cannot be appended to the track number 0 from the file 'a.264'. The width of the two tracks is different: 1440 and 1280
残念！
338:名無しさん＠編集中
17/08/27 17:47:03.79 LHzl8Vgr0.net
書き込みテスト
339:名無しさん＠編集中
17/08/27 17:53:07.05 5ula7e/yM.net
CPU能力有り余っててsubme=11を常用してたけど、10に変更したら主観的に画質レートエンコ速度が良くなった
11ってまだ実験的レベルなのかね
340:名無しさん＠編集中
17/08/27 20:20:15.47 c4MX+NAU0.net
画質レート速度ってなに？
341:名無しさん＠編集中
17/08/27 20:31:15.94 a38KtlYJM.net
>>340
画質(、ビット)レートって意味ね
342:名無しさん＠編集中
17/08/28 11:02:53.88 pvNM6gxN0.net
俺も意味不明
エスパーすると同じcrfだと、画質が良くなり、エンコ速度も速いてことか？
doomで散々議論されてる
343:名無しさん＠編集中
17/08/28 11:11:13.36 SOh7kOB8d.net
限界まで圧縮高めればノイズも出易い
サイズが縮まるのと画質が良くなるのはイコールじゃないって事
344:名無しさん＠編集中
17/08/28 13:16:42.94 Ub5w0giJ0.net
submeを「限界まで圧縮高める」ものだと思ってるのか
345:名無しさん＠編集中
17/08/28 15:38:17.72 SOh7kOB8d.net
>>344
サブピクセルに対して動き予測を行う精度が高い→圧縮率を高める可能性がある→高圧縮
無能で理解できてない癖に揚げ足取ってる俺カッケーってかwww
346:名無しさん＠編集中
17/08/28 16:28:10.48 qwDzXc8E0.net
それは副次的効果ではなくて？
347:名無しさん＠編集中
17/08/28 16:36:11.28 bWNdGo2i0.net
どうやらsubme上げると圧縮高まってノイズが出やすいらしい
新説だなｗｗ
348:名無しさん＠編集中
17/08/28 16:43:47.58 DgDXaiGa0.net
けど実際にガッツリ削れてブロックノイズが出たた気がする
349:名無しさん＠編集中
17/08/29 19:16:36.73 u78OskKI0NIKU.net
submeなんて「ソースによる」としか・・・。
別に11だけに限らず、「7より8にしたほうがエンコ速度が速くなった」とか過去に自分もあったし・・・。
350:名無しさん＠編集中
17/08/29 22:59:28.55 OU+HHEG/0NIKU.net
自分の目にはsubmeは9が一番画質いいように見える
351:名無しさん＠編集中
17/08/29 23:40:18.88 LXi6ZFDZ0NIKU.net
安定の9か
352:名無しさん＠編集中
17/08/30 21:00:30.31 UfARUKXj0.net
>>349
動き予測妥協してるんだから速度は早くなるだろ
353:名無しさん＠編集中
17/08/30 21:02:48.54 UfARUKXj0.net
ごめんなさい
よく読んでなかったです・・・
354:名無しさん＠編集中
17/08/30 21:11:52.23 0I7zrm7A0.net
疲れてるんだなきっと
355:名無しさん＠編集中
17/09/01 11:28:46.66 6GYB47wg0.net
昨日久々にaviutl一から環境作り直したけど
エンコした動画重い設定じゃないのにシークがクッソ重くて参った、なんでや！
356:名無しさん＠編集中
17/09/01 12:28:10.60 p0ViNu5b0.net
keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな
357:名無しさん＠編集中
17/09/01 12:43:57.42 BcnMjwRed.net
ゴミCPU使ってなきゃGOP300でも気にならんがなぁ
358:名無しさん＠編集中
17/09/01 15:07:10.75 98rXXRkg0.net
デフォだとHEXの7って時点で白けるけどな
359:名無しさん＠編集中
17/09/01 16:48:57.53 PPZk2VfG0.net
>>356
palだかの25fpsの10秒分で250って話らしいね
デフォルトとしては確かに自分も微妙な値だと思うｗ
360:名無しさん＠編集中
17/09/01 16:58:46.84 ArSPPgcm0.net
シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。
361:名無しさん＠編集中
17/09/01 18:31:37.76 1RZ6jwk90.net
keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている
362:名無しさん＠編集中
17/09/01 18:34:08.57 u27Ubveq0.net
BDってOpenGOPなんじゃなかったっけ？
363:名無しさん＠編集中
17/09/01 18:39:12.41 1RZ6jwk90.net
そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない
364:名無しさん＠編集中
17/09/01 19:25:35.51 PPZk2VfG0.net
動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね
ローカル保存のエンコードなら基本的にopengopでいいだろうねー
365:名無しさん＠編集中
17/09/01 20:50:29.66 44WtHh6mM.net
BDだと最大キーフレームは最大2秒でしょ
60p除く
366:名無しさん＠編集中
17/09/02 00:55:46.68 +gf3sPsb0.net
設定値はfps非依存であるべきだと思う
367:名無しさん＠編集中
17/09/02 12:09:42.42 XINNvlDB0.net
釣りか？
368:名無しさん＠編集中
17/09/04 02:11:30.20 DviGTLEu0.net
keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから
ほとんど動かないシーンが長時間続いた場合にどこまでシークしやすくするかを制御するものだろう
>>367
確かに全てがfps非依存であるべきというのは言い過ぎだった(refとかbframesとか)
けどkeyint/min-keyintの用途からいってfps依存にする必要ある？って思うわけよ
369:名無しさん＠編集中
17/09/04 10:16:11.18 r1tNr/2q0.net
単に最大間隔を広げるだけだと思ってる奴が多いが
実際には「必要と判断する」部分で「直前のkeyからの距離のkeyintに対する比」を使うので
keyintをでかくすると必要な部分にも入りづらくなる
370:名無しさん＠編集中
17/09/04 11:31:51.78 lpHpIfZE0.net
というかその必要な部分の判別はどうやってやるの？
それとも思い込み？
371:名無しさん＠編集中
17/09/04 14:08:59.27 ruHSz/Hl0.net
> それとも思い込み？
こういうことを平気で書く輩に対しては、何も答えたくないだろうな
372:名無しさん＠編集中
17/09/04 15:24:27.40 aLxOvhc00.net
x264 [info]: frame I:31 Avg QP:31.14 size: 50769
x264 [info]: frame P:1337 Avg QP:33.32 size: 15607
x264 [info]: frame B:2813 Avg QP:33.49 size: 4962
x264 [info]: consecutive B-frames: 10.3% 13.1% 7.8% 25.2% 12.1% 16.2% 6.2% 4.4% 0.4% 1.4% 0.8% 0.6% 0.0% 0.3% 0.0% 0.8% 0.4%
x264 [info]: frame I:49 Avg QP:30.33 size: 48096
x264 [info]: frame P:1472 Avg QP:33.25 size: 14425
x264 [info]: frame B:4233 Avg QP:32.26 size: 3227
x264 [info]: consecutive B-frames: 7.5% 9.7% 5.7% 20.1% 9.4% 13.2% 5.6% 4.2% 1.1% 2.3% 2.3% 1.9% 0.5% 0.5% 1.8% 2.5% 11.8%
同一ソースを動いていないフレームをタイムコードで引き伸ばしたのと、ループして周波数合わせたやつを同パラでエンコしたのだが、
Keyint狭くした方がいいのかな
373:名無しさん＠編集中
17/09/04 16:16:47.61 5HbHCOKD0.net
>>372
どっちがどっちなのよ
あとx264にわたってるfpsは同じなの？
x264は入力fpsでcrfの品質基準が変わるから注意
374:名無しさん＠編集中
17/09/04 16:53:24.96 U39geqKR0.net
>>369
えっ？
375:名無しさん＠編集中
17/09/04 17:03:06.54 zbSjoI0T0.net
x264ってタイムコード入力できるからfpsって必要ないんじゃないの？
それともタイムコードはレート制御に使われないの？
376:名無しさん＠編集中
17/09/05 01:27:08.59 f5v5/jXG0.net
>>373
フレーム数を見ていただければ分かるように、上がフレームを削ったもの、下がループしたものです
377:名無しさん＠編集中
17/09/05 09:48:18.47 2RbzhNwm0.net
>>375
どこまでインテリジェントに対応してくれるんだろう・・
入力されたファイルのfpsが30fpsだった場合、不明・24fpsの場合と比べて
crfの数字に0.2～0.3ほど内部で増やされるんだけど、その適応もしてくるれるんだろうか
378:名無しさん＠編集中
17/09/05 18:10:54.98 9b8xFzve0.net
>>370
IDRフレームが挿入されるタイミングは、
100 * (1 - (Pフレームのビットサイズ) / (Iフレームのビットサイズ) ) < scenecut * (直前のIDRフレームとの間隔) / keyint
の式で求まるらしい。
IDRフレームってのはH.264/AVCから追加されたフレームで、特定のフラグを持ったIフレームとしても機能するフレームの様だ。
IDRフレームとIフレームしっかり区別して解説しているWEBページは少ないようだ。
ちなみにH.264のGOPの境目はIDRフレームになっている。なのでこれがキーフレームなどと呼ばれる。
さっきの式を計算してもらえば分かると思うが、keyintを大きくすると「直前のIDRフレームとの間隔」が近づきにくくなるので、IDRフレームが挿入されにくくなる。
それを>>369は説明していたのだと思う。
379:名無しさん＠編集中
17/09/05 19:47:38.56 +QVQZVSVM.net
そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ？
380:名無しさん＠編集中
17/09/05 20:21:42.67 PONwnECO0.net
OpenGOPだとIDRフレームは生成されないよ
GOPはあるし、シークできるけどね
381:名無しさん＠編集中
17/09/05 21:19:57.24 9b8xFzve0.net
IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。
382:名無しさん＠編集中
17/09/06 23:29:09.06 KzhpnQIy0.net
誤爆
383:名無しさん＠編集中
17/09/07 00:00:38.11 qIIhwnZ40.net
何でyou等はx265を使わないのかne？
384:名無しさん＠編集中
17/09/07 00:33:21.37 YqTr/s540.net
ほっといてくれ
385:名無しさん＠編集中
17/09/07 01:40:32.76 imulDhe8M.net
BDMV互換重視してるから
UHD-BDにオーサリング出来るようになってx265がUHD-BDのフォーマットに完全互換出来たら乗り換えるわ
まあ、UHD-BDはインターレースをサポート外したから、インタレ素材は実質アプコンしないといけないからH.265にする意味があんまりなさそう
386:名無しさん＠編集中
17/09/07 01:55:19.43 nZ6H3iVe0.net
単純に再生側でh.265が観れないから
387:名無しさん＠編集中
17/09/07 07:09:58.72 kv1lC+de0.net
>>383
使ってるよ
別にこのスレに書いてるからと言ってx265を使っていないことにはならない
388:名無しさん＠編集中
17/09/07 09:54:51.39 +wXPEBFj0.net
youtubeのことかと思ったらyou達（たち）だったのね
389:名無しさん＠編集中
17/09/08 07:40:32.11 ghAOL8080.net
何年も前から使えるなら移行する気満々で環境だけは整えてるけど
使い物にならん、使える環境が激狭いまんまなんでどうにもならん
390:名無しさん＠編集中
17/09/08 07:42:49.16 7Btg921qM.net
できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい
391:名無しさん＠編集中
17/09/08 08:17:45.88 zQgPsbEjM.net
一番の問題はx265の完成度が低すぎる所
規格上はH.264の二倍近い圧縮効率と謳ってるが、
x264とx265で似たようなSSIMになるようにエンコしても、
速度倍かかるのに対して容量3割程度しか削減出来てない
392:名無しさん＠編集中
17/09/08 09:08:45.48 jziT9JUy0.net
H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。
んで、そういう機械評価ではなくて、実際の主観的な評価（眼で見た時）はどうなのかと、圧縮率をH.264の倍にしてテストも、92.5%はテストクリア（半分にしても違いが分からない）という結果が出ている。
URLﾘﾝｸ(www.bbc.co.uk)
393:名無しさん＠編集中
17/09/08 10:35:25.34 YVfOYICF0.net
>>390
8bitでエンコしてあればx265のエンコ動画はスマホでも余裕で再生できるけど？
394:名無しさん＠編集中
17/09/08 13:10:52.31 DRBMiemRa.net
スマホの世代によるんじゃ
395:名無しさん＠編集中
17/09/08 14:57:11.66 6zk3EGtm0.net
馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな
396:名無しさん＠編集中
17/09/08 19:02:26.67 K42HeHEk0.net
x264vfwの最新版が7月で64bit版は15年で止まってるんですが
もう作らないという事でしょうか？自分がよく使っているソフトは64bitなので
最新版は使えないっぽいですが
397:名無しさん＠編集中
17/09/08 19:17:53.60 EqCEryle0.net
>>396
統合されたので、最新版を入れれば32bitと64bitの両方が入るよ。
398:名無しさん＠編集中
17/09/08 19:37:50.44 K42HeHEk0.net
あ、そうなんだ㌧クス 翻訳サイトで読んだけどちょっとよく分かりませんでした
399:名無しさん＠編集中
17/09/09 09:15:24.46 h/Y+Lz1o00909.net
x264guiEx_2.52
400:名無しさん＠編集中
17/09/12 07:10:49.74 AdArdet+M.net
>>392
規格作った所の公式テストの話じゃなくて、x264に比べてx265の最適化が発展途上って話なんだが
401:名無しさん＠編集中
17/09/16 13:32:24.14 zNLVYvN4x.net
>>392
どうせ比較したH.264エンコーダーが糞なんだろうな
x264はmp3でいうLAMEみたいに規格内で極限まで最適化を志向するエンコーダー
402:名無しさん＠編集中
17/09/22 16:10:49.36 cJDJKSFu0.net
規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう
403:名無しさん＠編集中
17/09/27 19:54:24.64 p7Ac+Lfb0.net
1passVBRのcrf指定でエンコする場合、presetはどれに設定しても
crfが同じなら容量は変わっても画質はほぼ同じになるの？
404:名無しさん＠編集中
17/09/27 21:29:43.81 2daxdhqd0.net
>>403
画質という表現だとちょっとあれだが、前にSSIMを調べた時には
fasterより早いプリセットは他に比べて明らかに値が低くなってしまっていた気がする。
405:名無しさん＠編集中
17/09/27 22:14:16.87 Urbs+S3H0.net
>>403
機能的にはそのはずだけど画質はfasterとslowではそれなりに差が出る
使える機能を絞ってるわけだから当然なのかなと思ってる
406:名無しさん＠編集中
17/09/28 05:25:03.14 V45lbue30.net
ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に
振った方が良いのかな、と思ったんだけど微妙だね。
407:名無しさん＠編集中
17/09/30 16:37:33.34 0Ufo816+M.net
ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、
ようやく涼しくなって常用最大の4600MHzまでやっても落ちなくなったわ
408:名無しさん＠編集中
17/10/01 22:59:15.48 q0pgAPRH0.net
電源をずしんと重いやつに変えれば夏でも安定すんじゃね？
409:名無しさん＠編集中
17/10/01 23:01:30.73 kwhdiWHuM.net
>>408
オンボ環境で1000Wの電源積んでる(将来のグラボ追加のための皮算用)んですがね
410:名無しさん＠編集中
17/10/09 02:38:46.73 o0wuNtkj0.net
x265スレが落ちたようだな…
411:名無しさん＠編集中
17/10/09 04:47:35.68 jZhige/X0.net
ヤツは四天王の中でも
412:名無しさん＠編集中
17/10/09 07:59:57.87 LaKQeeR70.net
最強
413:名無しさん＠編集中
17/10/09 10:51:18.58 yu/ITypTM.net
漬け
414:名無しさん＠編集中
17/10/11 00:26:25.49 Q7nPMdd60.net
おお･･･
415:名無しさん＠編集中
17/10/11 00:40:05.42 nHom/Jmt0.net
勇者よ…
416:名無しさん＠編集中
17/10/11 08:59:51.54 98Hacveca.net
死んでしまうとはなさけない
417:名無しさん＠編集中
17/10/11 13:25:53.15 qw5XZR0a0.net
死んでしまうとはふがいない
418:名無しさん＠編集中
17/10/11 17:26:15.90 i0NOrkcf0.net
勇者「うるせー！文句あんなら自分でやれや糞がっ」
419:名無しさん＠編集中
17/10/11 18:01:28.04 p3huYvL50.net
女神様「ぷーくすくすー」
420:名無しさん＠編集中
17/10/11 20:41:15.01 xq6B2EZpx.net
ライゼンはええわ
1700@3.6GHzで地デジソースがveryslow＆お気に入りフィルタの重めの設定でリアルタイムfps出てるわ
6700K@4.6GHzだと実時間の倍掛かるのに
421:名無しさん＠編集中
17/10/11 21:28:00.33 M7bFbdy2M.net
流石にその比較で2倍違うのはおかしい
もちろん実時間の倍かかるというのが1.6倍とかのことなら分かるが
422:名無しさん＠編集中
17/10/11 21:34:32.23 LMrA0Z5Xd.net
無理なOCでコケてるんじゃね
423:名無しさん＠編集中
17/10/13 13:45:16.21 yFIiDpYE0.net
こんな人間いるのかな？って突如疑問に思ったんで質問してみる
BDにはいってるAVCをx264で再エンコしてる人
こんな人いる？
これってもうガッツリと容量削減だけが目的？
424:名無しさん＠編集中
17/10/13 14:12:59.68 klQgg49hM.net
BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む
そもそも深度8bitの時点で知れてるし
425:名無しさん＠編集中
17/10/13 15:01:37.09 yFIiDpYE0.net
>>424
ああ そういう感覚なのか
容量あるから考えなしにビットレート高くしとけっていう事ね
ありがとすっきりした
426:名無しさん＠編集中
17/10/13 20:56:47.91 KJdAkpzt0.net
720p付近で作ってるアニメなら容赦なく720pにしちゃう
427:名無しさん＠編集中
17/10/13 22:51:02.86 zkNYkqBK0.net
>>423
BD-BOXをエンコしてBD-R SL1枚にまとめれたら最高じゃね？
あとは特典だけ手元に残してBD-BOXをオクに流せばいいだけ。
428:名無しさん＠編集中
17/10/13 23:02:17.93 /9liIQr8d.net
>>427
それならH.265にするわ
429:名無しさん＠編集中
17/10/13 23:08:15.02 c69msVZM0.net
一度HDDにエンコして入れとけば見たい時にサクッと見られるからな
毎回blu-rayディスク引っ張り出してディスクセットがめんどい
430:名無しさん＠編集中
17/10/13 23:08:32.23 XO65u8DFa.net
BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ
だから容量削るのに720Pにしちゃうし画質はそこそこで早さ優先にしてる
431:名無しさん＠編集中
17/10/13 23:11:13.45 zkNYkqBK0.net
何でエンコするかは各自の自由な。
俺もエンコはx265(アニメならpreset 8+12bit+crf16)の一択になってしまったが。
BDソースだとavsフィルタとか無理に加える必要もないしエンコもだいぶ省略できる。
432:名無しさん＠編集中
17/10/13 23:26:06.30 zkNYkqBK0.net
x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
24分アニメあたり800～1.3GB前後で収まれば御の字だし
433:名無しさん＠編集中
17/10/14 01:04:33.83 +Cbq7FOAM.net
俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
自分でやるの時間の無駄だし面倒だから
434:名無しさん＠編集中
17/10/14 01:26:53.21 kVkjCh4N0.net
地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
60iテロ処理とか雑に処理しててドン引きした。
435:名無しさん＠編集中
17/10/14 01:46:27.00 p1EsgrIG0.net
テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
静止シーンでコピペして潰せるとかならともかく
436:名無しさん＠編集中
17/10/14 14:10:21.52 kVkjCh4N0.net
いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。
437:名無しさん＠編集中
17/10/14 16:16:50.16 Q0J2c64D0.net
だから地デジはゴミって言ってんだろう
438:名無しさん＠編集中
17/10/14 20:09:42.00 p1EsgrIG0.net
補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
存在してるだけでイラつくゴミが、これ見よがしにヌルヌル動いてたら余計腹立つわ
きったねー縞々で何書いてあるかわからないぐらいの方がざまあみろって感じでいいんだよ
439:名無しさん＠編集中
17/10/14 20:13:49.84 Q0J2c64D0.net
ちょっと理解できない
440:名無しさん＠編集中
17/10/14 20:17:20.64 wt/1RTiS0.net
>>438
テロップに惨敗して負け惜しみ言ってるようにしか見えない
441:名無しさん＠編集中
17/10/14 21:08:10.51 AcLLCDR50.net
AUTOVFRで手抜きしてるわ
442:名無しさん＠編集中
17/10/14 21:50:24.73 qxT45PQV0.net
何度も見る事やないんやけんある程度見れてたらそれでええわ
443:名無しさん＠編集中
17/10/15 01:30:31.64 uf2+tVfwx.net
そんなに気になるならインタレ保持でやれよと
444:名無しさん＠編集中
17/10/15 01:53:30.55 kSF3tACb0.net
横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ？
あとエンコ職人はウォーターマーク消しと提供のテロップ消しを一切しないのもイラつく。
445:名無しさん＠編集中
17/10/15 02:00:59.89 uf2+tVfwx.net
どこの局のソースかが大事だからな
糞低ビットレートのMXじゃないよアピール
446:名無しさん＠編集中
17/10/15 10:31:33.53 yslYpxl4a.net
>>444
そこがそれほどイラつくなら素直にBDを買うか借りるかした方が幸せになれそうだ
447:名無しさん＠編集中
17/10/19 19:52:10.44 vF0uxTaTM.net
x265でアニメエンコしてたけど
暗部の潰れや歪みがどうしても良くならないのでx264に戻ることになりそう
あまり詰めてないけど--crf 20 --qcomp 0.7 --aq-mode 1 --aq-strength 1.0 --psy-rd 0.65:0.20で同ビットレートの265より再現度良好
448:名無しさん＠編集中
17/10/19 20:15:18.80 3Nrwplnu0.net
定期的に現れるけど、単に8bitでエンコしてるだけでは？
449:名無しさん＠編集中
17/10/19 20:35:27.12 RCE2B7Sj0.net
仮にそうだとしても、ソースも8ビットなわけで、
x264にできてx265にできないならその条件ではx265が劣るというだけのこと
450:名無しさん＠編集中
17/10/19 20:41:02.03 cp4WsA9J0.net
aq-mode 3 使えよ
451:名無しさん＠編集中
17/10/19 20:45:39.24 3Nrwplnu0.net
「その条件」ならそうかもしれんが、>>447はその条件にこだわってないだろ
バンディング対策をしたくない理由とは？
452:名無しさん＠編集中
17/10/19 20:49:53.98 cp4WsA9J0.net
暗部といったら aq-mode 3 だろ
なんで 1 使ってんだよ
意味わかんねーよ
453:名無しさん＠編集中
17/10/19 21:08:09.16 BSHlOoYOF.net
詰めてないんじゃなく詰め方を知らないんだろ
454:名無しさん＠編集中
17/10/19 21:11:09.82 RCE2B7Sj0.net
>>451
で、その>>447の対策（バンディングと暗部のディテールは違うと思うが）がx265ではなくx264を使うということだったのでは？
バンディングでいうと、ソースが8ビットならばいくらエンコの設定工夫しても無駄
逆にいえば少なくともx264ならエンコの設定ちゃんとすればスクリーンキャプチャしてソースと差分取ってもほぼ0にはできる