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にはできる
455:名無しさん＠編集中
17/10/19 21:14:46.32 RCE2B7Sj0.net
ソースが10ビットなら知らんが、
アニメで（エンコードできるDRM無しの）10ビットのソースなんでまずないだろうに
8ビットのソースを10ビットでエンコードするのはただのアホ
456:名無しさん＠編集中
17/10/19 21:16:18.23 WeGA2ymkM.net
暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき？
後者いらない？
BSプレミアムで放送された大曲花火大会中継を今さらエンコしようと思うんだ
457:名無しさん＠編集中
17/10/19 21:18:04.70 P8zWZmTR0.net
入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん?
バンディング軽減やらで
458:名無しさん＠編集中
17/10/19 21:19:04.81 WeGA2ymkM.net
aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの？
avisynthなんかでYUV420のまま処理したなら要らんだろうけど
459:名無しさん＠編集中
17/10/19 21:21:03.54 cp4WsA9J0.net
デバンドは意味あると思うが10bit化は無駄多すぎ
アニメには必要ない
それより x265 にも aq-mode 3 はあるから
460:名無しさん＠編集中
17/10/19 21:22:31.59 RCE2B7Sj0.net
ソースを加工するならたしかにまあ
普段自分はしないからその発想は抜けてた
461:名無しさん＠編集中
17/10/19 21:32:18.18 3Nrwplnu0.net
8ビット高ビットレートでバンディング低減されてるソース（放送もブルーレイもそう）を
低ビットレートにエンコするんだったら、デバンドした上で10bit化は必須だよ
462:名無しさん＠編集中
17/10/19 21:37:16.82 3Nrwplnu0.net
まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、
少なくとも俺の使ってる4Kブラビアじゃ、チラチラしすぎて集中できない
463:名無しさん＠編集中
17/10/19 21:38:05.60 9FIiI0A00.net
アニメで10bit化が必要ないとかマジかよ
464:名無しさん＠編集中
17/10/19 21:54:45.70 WeGA2ymkM.net
ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ
ウルトラHDブルレイなら10bit以外の設定は既存のブルレイに合わせとけば問題ないっぽいけど、
そもそも個人向けオーサリングソフトがない
465:名無しさん＠編集中
17/10/19 21:59:03.66 AVcz4dXd0.net
447だが
単にx265とずっと格闘しててx264は浦島気味だから
とりあえずデフォルトに近い所から挙動見てみるかくらいの気持ちだったんだけど…
怒らせてしまったなら申し訳ない
ちなみにどちらも10bitでx265はAQ1～3、Psy-rd、rdoqをあらかた上下させまくったけど
暗部の輪郭保持でx264のポン付けに及ばなかったのはガチだよ
スレチになりそうなんで、要求されない限り細かい記述は避けるけど
466:名無しさん＠編集中
17/10/19 22:39:10.16 FFa/XIlI0.net
8bitソース素通しでも10bitでエンコードする理由はあるよ
同じソース・同じavs・同じX265設定（output-dephthだけ変更）を見比べたら
明らかに10bitが優れている
ま、crf20以下じゃ大した差じゃないかもしれないがエンコーダーとしては10bitのほうが優れているのは変わらない
ちなみにx264のほうが処理がシンプルな分、情報量が多くなることは多い
467:名無しさん＠編集中
17/10/19 22:40:19.49 Gaf9oyCF0.net
バンディングだけは目に見えて効果あるよな10bit化
PCでしか再生しないし一択だわ
468:名無しさん＠編集中
17/10/19 23:57:53.42 VgKoLcU30.net
>>465
ソースくれ、その部分だけでいいから
できれば静止画でなく動画で
469:名無しさん＠編集中
17/10/20 00:20:43.45 qjJPv/bA0.net
>>466
x265は知らんが、x264なら素通しなら8ビットでソースと寸分違わないレベルの画は出るんだよ
劣化するにしても動きやディテール部分が溶けるだけで、バンディングなんでひどくもならない
そうならないとしたら設定がおかしいか（画質が目に見えて劣化する低レートは知らん）、素通しのつもりがそうなってないパターン
470:名無しさん＠編集中
17/10/20 00:31:01.56 1vtnnLQF0.net
>>469
君が劣化しているところに気づいてないだけだと思うよ
BDでさえバンディングは問題になっているのに、その5分の1以下のビットレートで
問題にならないってありえないだろ
471:名無しさん＠編集中
17/10/20 00:42:37.61 qjJPv/bA0.net
1/5程度のレートなら余裕余裕
アニメのBDなんて無駄に（というかほぼCBRに近い）レート食いまくってるんだから、
動かない静止画に近いところで適切に圧縮するだけでその程度には簡単になる。
もっと低いレート（1/10以下）のこと話してるのかと思ったらそんなレベルのなのか。
～なわけがないとか想定で話してないで、実際に試してみてから話してくれ
472:名無しさん＠編集中
17/10/20 00:45:01.85 qjJPv/bA0.net
アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな
ほぼ規格上限ぎりぎりのCBRよ
473:名無しさん＠編集中
17/10/20 00:51:27.88 meA5JVSG0.net
crfが適切で、aq-mode 3 使って、デバンドかけてれば
8bitでそんな気になるほど見分けつかんよ・・・
10bit使わにゃいかんほどだと、違うパラメータが変なんだよ
474:名無しさん＠編集中
17/10/20 02:12:58.94 1vtnnLQF0.net
ソース
URLﾘﾝｸ(i.imgur.com)
フィルタなし 8bit --crf 20 --aq-mode 3 --tff
URLﾘﾝｸ(i.imgur.com)
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
URLﾘﾝｸ(i.imgur.com)
デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff
URLﾘﾝｸ(i.imgur.com)
デバンドありの圧縮前
URLﾘﾝｸ(i.imgur.com)
全部AviUtlでrigaya氏の拡張x264で出力
デバンドはrigaya氏のバンディング低減MT SIMD (25/15/15/15/0/0/1/0/off/off)
これで8bitがきれいに見えるならいいんじゃないか。そういう環境ならね・・・
475:名無しさん＠編集中
17/10/20 05:31:39.81 meA5JVSG0.net
おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・
476:名無しさん＠編集中
17/10/20 07:45:09.76 Bsl5IeCi0.net
デバンドするしないでも選択肢変わるだろうし
QP値どれだけ盛るかにもよるけど手軽にやりたいなら10bitのほうが楽っちゃ楽
8bitソースにデバンドも何もしないなら10bit使うだけほぼ無駄ってのはそのとおり
477:名無しさん＠編集中
17/10/20 08:33:39.54 ljIvdMqUM.net
なんでアニオタばかりなの？
グクってもみんなアニメかゲームのエンコの話ばかり
実写メインの人っていないの？
自分は実写メインで、地デジソースならデノイズかけてインタレ保持のcrf25ぐらいで5Mbps前後にしてる
SSIMが大体0.978ぐらいになるから糞ソースの地デジならあんまり変わらん気がする
478:名無しさん＠編集中
17/10/20 08:35:38.93 ljIvdMqUM.net
デノイズはNL-Means使ってる
アニメ向きとも言われるが、弱くかければ実写でも10%ぐらい小さくなる
479:名無しさん＠編集中
17/10/20 08:55:47.92 CGJgWOmW0.net
実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね
容量にも拘りなさそうだしエンコ自体してなさそう
480:名無しさん＠編集中
17/10/20 10:10:35.50 qjJPv/bA0.net
>>474
＞ソース
＞URLﾘﾝｸ(i.imgur.com)
と、
＞フィルタなし 8bit --crf 20 --aq-mode 3 --tff
＞URLﾘﾝｸ(i.imgur.com)
はほぼ寸分違わないよな。
ということを言ってるんだよ。
ソースを加工して情報を補完する場合はその限りではないと>>460で言ったとおり
あくまでもソースを忠実に再現するためのエンコードという観点でしか話してなかった
デバンド等でぱっと見は綺麗になったように見えるんだけど、
一方で細部の意図したざわざわなディテールも消失するし（地デジなんかのソースにはそもそもそんな情報ほぼ残ってないだろうが）、
いいことばかりの魔法のフィルターは無いのだ。その辺は好みだね。
あくまでもソース寸分違わないかどうかという観点では10bitエンコードは無駄という話。
481:名無しさん＠編集中
17/10/20 10:17:59.88 qjJPv/bA0.net
んでもって、x264は
＞8bit --crf 20 --aq-mode 3 --tff
みたいなほぼプリセットそのままな設定でソースほぼそのままの忠実なエンコードができるんだが、
>>466のような話は散々出てくるし、
x265は依然としてそのレベルに達してないのだろうか
482:名無しさん＠編集中
17/10/20 10:39:22.89 ljIvdMqUM.net
10bitで書き出すならデバンド要らなくない？
あくまで内部処理が8bitを越えるデノイズやらリサイズフィルター通したのを8bitで出すための処理じゃないの？
483:名無しさん＠編集中
17/10/20 10:55:30.54 l1+4vpOY0.net
>>481
x265はビットレートをつぎ込んでの高画質はまだx264に負ける
っていうかx265は4k向けの高圧縮コーデックだから2kで負けるのは仕方ない
484:名無しさん＠編集中
17/10/20 11:55:38.66 ljIvdMqUM.net
まだx265が開発途上なだけでしょ
H.264と同じく低解像度から満遍なく圧縮率上げる規格だからx265の改良の余地はある
485:名無しさん＠編集中
17/10/20 12:57:27.10 qjJPv/bA0.net
>>482
そういうことでもない
デバンド（も含めソースの加工）をしないならソースと同じビット数でエンコードすればいいだけ
8bitのソースを8bitビットでエンコードして当たり前だがソースからほぼ劣化が無くできるのだから、
それを10bitでエンコードしてもデータを無駄に水増しして互換性を下げているだけ
たしかにフィルターをかけたら元の8bitでは表せない中間の値が出てきてしまうので、
それを10bitで表現するというのはありだし、実際効果はある（>>474）
もちろん再び8bitに落としてもある程度フィルター効果は残ってはいるが完ぺきではない（>>474）
486:名無しさん＠編集中
17/10/20 13:00:23.85 qjJPv/bA0.net
>>483
H264の普及初期段階もH264は低ビットレートでそれなりに見られるようにするコーデックで、
高解像度高ビットレートではMPEG2のほうがきれいだとか言われていたが、
それは単に当時のコーデックの実装が未熟だっただけで、今どきそんな戯言を言うやつはいないのでそれと同じことだろう
487:名無しさん＠編集中
17/10/20 14:00:38.72 l1+4vpOY0.net
>>485
その水増しってのが認識を間違ってる証拠だと思う
なにも水増しはしてないんだから
>>486
なるのかな
h.264がHD画質でmpeg2より高画質になったのは必然だけど・・
488:名無しさん＠編集中
17/10/20 16:47:06.45 qjJPv/bA0.net
>>487
8bit to 8bitでまさにソースそのままにエンコードできるのだから、
そういう場合に10bitでエンコードすることがどう
＞なにも水増しはしてない
なのか詳しく
何度も言うがソースに何らかの加工を施す場合はこの限りではない
489:名無しさん＠編集中
17/10/20 19:18:50.79 93DuW1x10.net
crf 20 出来上がりのファイルサイズめっちゃデカくなりそうだけど
490:名無しさん＠編集中
17/10/20 20:58:55.70 4az+If+XM.net
アニメならそうでもない
さらにフレームレートと解像度によってcrf同じでも品質違ってくる
491:名無しさん＠編集中
17/10/20 21:38:45.04 1vtnnLQF0.net
ソースを忠実に再現って言うと聞こえはいいかもしれないけど、
MPEG2圧縮でできたノイズやアーティファクトまで再現しようとしなくていい
しかも実際は再現できてなくて、バンディングは悪化してる（>>474）
（圧縮で情報量が落ちる分仕方ないのだけれど）
デノイズしてから圧縮したほうが綺麗なることも多いし、
テレビは「高画質化エンジン」で加工しまくって表示してる
そもそも圧縮で情報量落ちる分、ある意味「加工」されちゃう
492:名無しさん＠編集中
17/10/20 22:05:29.43 o4Nz9FwSM.net
まあTVはソースがボロボロだからねぇ
493:名無しさん＠編集中
17/10/20 22:06:27.54 l1+4vpOY0.net
>>488
細分化であって水増しじゃないでしょ
494:名無しさん＠編集中
17/10/20 23:42:25.14 HASgMWlT0.net
8bitきったねぇわろたｗｗｗｗｗｗｗ
こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけｗｗｗｗｗｗｗｗｗｗｗｗ
495:名無しさん＠編集中
17/10/21 00:06:33.17 GU2WsWjF0.net
>>480
この違いがわからないなんてよっぽどひどいモニタ使ってるんだね
496:名無しさん＠編集中
17/10/21 01:08:20.59 150/70DS0.net
>>495
「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。
497:名無しさん＠編集中
17/10/21 01:36:45.74 SivVBkBJ0.net
>>494
デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方
というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする
498:名無しさん＠編集中
17/10/21 01:42:00.04 SivVBkBJ0.net
>>493
意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う
499:名無しさん＠編集中
17/10/21 01:49:58.38 SivVBkBJ0.net
話がややこしくなってきたので改めて整理すると
>>466
に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない
んでもってその観点でいうならば、
>>474にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが
500:名無しさん＠編集中
17/10/21 02:00:41.89 SivVBkBJ0.net
>>494のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは（圧縮前の時点で）右上の絵画（？）の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ
そういう部分に目が行かず、
＞8bitきったねぇわろたｗｗｗｗｗｗｗ
＞こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
みたいに草生やしてるだけだからお前はめくらなんだよ
501:名無しさん＠編集中
17/10/21 02:48:21.65 GOmLStnF0.net
地デジはともかくブルーレイだと>>474のデバンドあり圧縮前のような
色の階調部分のディザを保っているからな～
少し試してみようか
502:名無しさん＠編集中
17/10/21 03:06:40.59 GOmLStnF0.net
これが>>474デバンドあり圧縮前をcrf0で8bit化したavc（の静止画）
URLﾘﾝｸ(dotup.org)
------------------------
これがそのavcをcrf20 8bitエンコしたもの
URLﾘﾝｸ(i.imgur.com)
QP:19.37 size: 31899byte
------------------------
こっちはcrf20 10bitエンコ
URLﾘﾝｸ(i.imgur.com)
QP:31.10 size: 29806byte
QPがとても上がってるせいかサイズは10bitの方が少ない
画質の評価は見た人に任せるよｗ
503:名無しさん＠編集中
17/10/21 03:22:40.83 +8CAoyQn0.net
>>500
そう、これ使えねーなと思ってさ、直したんだよ
バンディング低減MTは、Y,Cb,Crを色別に差を見てるんだけど、
そこ変更して、「全部の色がしきい値未満だったら」にした
対象と判定されたピクセルを表示してみた結果↓
判定表示（改造前）
URLﾘﾝｸ(i.imgur.com)
判定表示（改造後）
URLﾘﾝｸ(i.imgur.com)
デバンドありの圧縮前（改造後）
URLﾘﾝｸ(i.imgur.com)
オレオレバンディング低減
URLﾘﾝｸ(i.imgur.com)
どうよこれ
504:名無しさん＠編集中
17/10/21 04:09:58.65 GOmLStnF0.net
>>503
素直に欲しいレベル
505:名無しさん＠編集中
17/10/21 06:22:51.12 GF3n0jE/M.net
素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想
506:名無しさん＠編集中
17/10/21 09:21:07.43 3Js2SGA+0.net
別に絵画の精細度なんてどうでも良いんだがｗｗｗ
少なくともこのソースで明らかに目につくのはバンディングだしｗｗｗｗｗｗｗｗｗｗ
まじめくらやべぇわｗｗｗｗｗｗｗｗｗｗｗｗ
507:名無しさん＠編集中
17/10/21 09:28:46.77 wM+aM70x0.net
老眼が進むとどうでもいい
508:名無しさん＠編集中
17/10/21 10:08:27.63 /zKw8/Pi0.net
＿人人人人人人人人人＿
J( 'ｰ`)し ＞ 草刈り中のトラブル ＜
○=｛=｝〇, ￣Y^Y^ Y^Y ^Y^Y Y^Y^Y￣
|:::::::::＼, ', ´ﾁｭｲｰﾝ
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗ
彡 ⌒ ミ
(´・ω・｀)
509:名無しさん＠編集中
17/10/21 10:30:00.87 4zl1vzp40.net
>>498
1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う
>>499
そうね
自分のエンコードの目的は「出力サイズを小さくする」ことだから
10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった
8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね＞大元は
510:名無しさん＠編集中
17/10/21 10:39:24.59 NJkYLvTf0.net
>>502を見るとどう考えても10bit＞8bitじゃんｗ
ファイルサイズ8bitの方が小さいならまだ分かるけど
大きくてこれとかイイとこなしｗ
511:名無しさん＠編集中
17/10/21 10:48:03.01 GLwKHK4T0.net
静止画だから分かりづらいけど
動画で見たらさらに目立つからなバンディングは
512:名無しさん＠編集中
17/10/21 10:50:48.21 WCEoAZaz0.net
>>511
うにょんうにょん動いて気持ち悪いよね
513:名無しさん＠編集中
17/10/21 16:10:41.83 s2dz+3eBa.net
うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで
ビット数より圧縮アルゴリズムから来る話で圧縮率の問題だと思うがな
各色8ビットの静止画でバンディングを感じるなんて事はまず無いわけでさ
（モニタのガンマカーブの話はまたややこしいのでカット）
デバンドは近接画素間を圧縮に都合のいい様に加工するから圧縮率高くてもバンディングが解消されるって話でしょ
つまり同容量で8ビット圧縮より10ビット圧縮の方が画質が優れているとしたら「8ビットより10ビットが綺麗」では無く
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」って話だと思うんだが
514:名無しさん＠編集中
17/10/21 16:54:30.19 SivVBkBJ0.net
>>513
＞8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る
っていう分かりやすいサンプル（できれば追試できるようにソースも公開されてるとなおよいが難しいだろう）があればな
単に何らかのミスで素通しになってないか、エンコード設定がおかしいだけじゃないのって気がする
素通しでそんなことになったこと無いもの
x265はほぼ使ったこと無いので知らん
現状のx265なら
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」
ということもあるのかもね
515:名無しさん＠編集中
17/10/21 17:26:01.84 SivVBkBJ0.net
>>502
と
>>474
で全部色が変わってしまっていて何かがおかしい
＞デバンドあり圧縮前をcrf0で8bit化したavc
っていう中間形式の作り方の詳細がよく分からないので何とも言えないけど、
色が変わってしまっているってことはどこかの段階で色空間かレンジの変換がかかってるということはないすか？
ちゃんとやれば、crf0が厳密には可逆圧縮ではないけどほぼ無劣化でエンコードできて
中間形式を経由した影響はほぼないはずで、
>>474
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
URLﾘﾝｸ(i.imgur.com)
と
>>502
これがそのavcをcrf20 8bitエンコしたもの
URLﾘﾝｸ(i.imgur.com)
QP:19.37 size: 31899byte
で色が変わってしまうということは起こらないはず
516:名無しさん＠編集中
17/10/21 17:53:32.26 WCEoAZaz0.net
黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、
暗いところはよく見えんから適当でええやろーみたいな風潮はやめてほしい
no-mbtree指定しても、まだなんかやってんだろって気がする
517:名無しさん＠編集中
17/10/21 17:57:18.23 /ssX+XV10.net
よく見えんところをはしょってごまかすのが圧縮の本質だからなあ
518:名無しさん＠編集中
17/10/21 18:01:35.48 SivVBkBJ0.net
>>517
バランスの問題もあるな
明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね
x264ならその方面のことは設定でなんとかなる柔軟性はあると思う
519:名無しさん＠編集中
17/10/21 19:48:06.19 +m1gFY6w0.net
>>515
おかしいと思うなら自分でやってみたら
1枚の画像から1フレームの動画を作るくらいできるだろう
10bit主張する人は検証画像いろいろ上げてるの、
このスレやググったりして見かけるけど、
8bit主張する人で画像を上げた人が一人もいないんだよね
論より証拠なのに勘ぐってしまう
520:名無しさん＠編集中
17/10/21 19:56:10.42 3Js2SGA+0.net
バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ
521:名無しさん＠編集中
17/10/21 20:00:51.36 s2dz+3eBa.net
別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ
無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で
色が変わってると考えるのが理論的思考として妥当でしょ
522:名無しさん＠編集中
17/10/21 20:00:58.25 SivVBkBJ0.net
>>519
動きのない完全静止の動画でよければ良ければやってみるよ
>>520
完全素通しっていう前提で主張してるのに、色が変わった（のが分からない人はさすがにいないよな）ならもうそれはカバーできない条件だわ
523:名無しさん＠編集中
17/10/21 20:07:55.46 +8CAoyQn0.net
>>514
ソースにディザが残ってるのを圧縮してディザを消しちゃうとバンディングが出る
デバンドあり 8bit --bitrate 20000 --aq-mode 3 --tff
URLﾘﾝｸ(i.imgur.com)
↑8bitだけどビットレート高いからディザが残っててバンディングが出てない
ブルーレイとかはこんな感じ
524:名無しさん＠編集中
17/10/21 20:13:15.41 4zl1vzp40.net
>>514
チューニング次第では？
基本的な技術は同じで違うのは色深度だけなんだから
525:名無しさん＠編集中
17/10/21 20:43:34.22 +m1gFY6w0.net
>>522
それでいいよ
526:名無しさん＠編集中
17/10/21 21:14:07.19 SivVBkBJ0.net
やってみた。
結論から言うと、ソースのディテールを十分再現できる程度（以下の実験ではcrf20）のビットレートがあれば8bitと10bitで差は無いが、
ソースのディテールが再現できずブロックノイズが目に余る領域（以下の実験ではcrf35）になると確かに8bitと10bitに差は出る、
そしてたしかに10bitのほうがブロックノイズのバンディングという面ではマシな結果になる。
（続く）
527:名無しさん＠編集中
17/10/21 21:14:31.54 SivVBkBJ0.net
それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、
きわめてDC成分に近い次元の成分だけが残り、10bitだとなめらかな中間値を表現できるということはあると思う。
ソースを忠実に再現できるレートでエンコードすることを中心に考えていた節があり、
低レートでそういう面があることを失念あるいは意図的に除外していたことは申し訳ない。
ただし、単純にそういう計算になるかは分からないが10bitだと概ね2割増しのデータを保存しないといけないのだから、
同じビットレートにしたときは（バンディングという側面は無視して）ブロックノイズの程度がひどくなる可能性が示唆される。
今回は静止動画なので分かりにくいが、若干文字や図形の輪郭をよく保っているのは8bitの側のような気がするし、
動きが入ればその印象がさらにどうなるか分からない。
また、何より再生の互換性が大きく低下するという重大な欠点はある。
（続く）
528:名無しさん＠編集中
17/10/21 21:16:19.44 SivVBkBJ0.net
実験結果
バンディングがある8bitソース(GWNr9Ru.png 10秒)
[enc1_crf20_8] 8bit crf20 199KB
URLﾘﾝｸ(i.imgur.com)
[enc1_crf20_10] 10bit crf20 178KB
URLﾘﾝｸ(i.imgur.com)
[enc1_crf35_8] 8bit crf35 47.9KB
URLﾘﾝｸ(i.imgur.com)
[enc1_crf35_10] 10bit crf35 48.4KB
URLﾘﾝｸ(i.imgur.com)
ディザでバンディングを軽減した8bitソース(GWNr9Ru.png 10秒)
[enc2_crf20_8] 8bit crf20 275KB
URLﾘﾝｸ(i.imgur.com)
[enc2_crf20_10] 10bit crf20 245KB
URLﾘﾝｸ(i.imgur.com)
[enc2_crf35_8] 8bit crf35 47.5KB
URLﾘﾝｸ(i.imgur.com)
[enc2_crf35_10] 10bit crf35 48.2KB
URLﾘﾝｸ(i.imgur.com)
529:名無しさん＠編集中
17/10/21 21:18:34.53 SivVBkBJ0.net
なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした
一連のコマンドは禁止ワードに引っかかったのでpastebinに貼っておいた
URLﾘﾝｸ(pastebin.com)
530:名無しさん＠編集中
17/10/21 22:04:06.64 +m1gFY6w0.net
imgur使うとある程度のサイズ超えるとjpgになってしまう
urlこそpngだけど↓の2つ以外はjpg変換されてる
[enc1_crf35_8] 8bit crf35 47.9KB
[enc2_crf35_8] 8bit crf35 47.5KB
531:名無しさん＠編集中
17/10/21 22:06:27.05 SivVBkBJ0.net
ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、
色空間の変換はソースのmp4を作るとき一度きりだから特に影響はないだろうと思って何も設定してなかったが、
どうやらちゃんとフラグを設定しないと再生ソフトのスクリーンキャプチャーでで色が変わるので、
そのへんもきっちりやりたければ、ffmpegには
-x264opts colorprim=bt709:transfer=bt709:colormatrix=smpte170m
x264には
--colorprim bt709 --transfer bt709 --colormatrix smpte170m
を付ければOK
まあファイルサイズ的には全く同じだし、これらのオプションはフラグを立てるだけでスクショの色が変わるだけで実験には影響ないと思う
実際そのオプションでもやってみたけど画質的には全く同じだし、ファイルサイズも完全に一致
まあ人に色がおかしいと疑いの目を向けた以上、こちらも正確性を期すために弁明を
532:名無しさん＠編集中
17/10/21 22:08:38.92 SivVBkBJ0.net
>>530
そうなんだ、それは知らなんだ
まあURLから見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う
コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ
533:名無しさん＠編集中
17/10/21 22:17:40.81 +8CAoyQn0.net
>>527
> 10bitだと概ね2割増しのデータを保存しないといけない
この認識は間違ってる
保存するのは量子化した後の値だから量子化ステップの幅（QP値から計算される）に依存する
8bitから10bitに2bit増えても、量子化ステップが4倍になれば理論的にデータ量は変わらない
H264の場合、QP値が6増えると量子化ステップが2倍になるから、
>>502見てもだいたい12増えてデータ量は同じくらいになってるでしょ
534:名無しさん＠編集中
17/10/21 22:43:24.18 SivVBkBJ0.net
>>533
単純計算して2割増しになるってのはおっしゃる通り、
QPを増やさない（＝一切副作用無く画面全体に8bit→10bitの恩恵を受ける）場合のこと
単純にそうはならないしても、同じファイルサイズで考えたとき
どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、
他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない
のっぺりした部分に8bitのときよりも細かい量子化を行う（つまりQPが12ほどは増えない）分、
そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ
（これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために）
実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える
535:名無しさん＠編集中
17/10/21 22:46:21.80 +m1gFY6w0.net
>>531>>532
いあ正にその色に問題出てるのよ
jpgはYUV420だがpngは24bit
IrfanViewだと目視じゃ違いが見当たらないが
Firefoxや古めの画像ビューアでみた時、pngだけ色が違う
ちゃんと正解の画像見れてるのかモヤっとする
536:名無しさん＠編集中
17/10/21 22:57:43.40 SivVBkBJ0.net
>>535
ffmpegでRGB→YUV変換するときにちゃんとどういう色空間のYUVにするかちゃんと指定しないといけない
（何も指定しないとたぶんBT601になる？）
URLﾘﾝｸ(forum.videohelp.com)
とかいうのもあったりするので、もうちょっとちゃんとオプションを精査したうえで追試してPNGのまま上げられるところ探して上げるわ
普段YUVのソースしかエンコードしないので、今回使えるソースがRGBのPNGだったので、
手際が悪くなって申し訳ない
537:名無しさん＠編集中
17/10/21 23:08:19.15 +8CAoyQn0.net
>>534
のっぺりした部分に8bitよりも多くデータ量割かないと
10bitの恩恵が受けられないってのは確かにそう
で、バンディングに関して言うと、8bitでバンディングを回避するには
ディザを残さなくちゃいけないけど、
8bitでディザを保持するためのデータ量に比べれば
のっぺりした10bit分の色を保持するためのデータ量の方が
圧倒的に小さい
だから、バンディングに関しては10bitの方が圧倒的に有利
↓こんな感じ
データ量
(8bitでディザを残す) >>> (のっぺりした10bit) > (のっぺりした8bit)
画質
(8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit)
538:名無しさん＠編集中
17/10/21 23:21:08.68 SivVBkBJ0.net
実験結果
バンディングがある8bitソース(source1 10秒)
URLﾘﾝｸ(light.dotup.org)
生成元
URLﾘﾝｸ(i.imgur.com)
と色も含めほぼ変わらないのを確認※
[enc1_crf20_8] 8bit crf20 185KB
URLﾘﾝｸ(light.dotup.org)
[enc1_crf20_10] 10bit crf20 166KB
URLﾘﾝｸ(light.dotup.org)
[enc1_crf35_8] 8bit crf35 47.9KB
URLﾘﾝｸ(light.dotup.org)
[enc1_crf35_10] 10bit crf35 48.2KB
URLﾘﾝｸ(light.dotup.org)
（続く）
539:名無しさん＠編集中
17/10/21 23:21:35.33 SivVBkBJ0.net
ディザでバンディングを軽減した8bitソース(source2 10秒)
URLﾘﾝｸ(light.dotup.org)
生成元
URLﾘﾝｸ(i.imgur.com)
と色も含めほぼ変わらないのを確認※
[enc2_crf20_8] 8bit crf20 264KB
URLﾘﾝｸ(light.dotup.org)
[enc2_crf20_10] 10bit crf20 234KB
URLﾘﾝｸ(dotup.org)
[enc2_crf35_8] 8bit crf35 47.6KB
URLﾘﾝｸ(light.dotup.org)
[enc2_crf35_10] 10bit crf35 47.1KB
URLﾘﾝｸ(light.dotup.org)
※一部の領域の色が違う（ディザのほうはちょっとだけバンディング出てる）のはおそらくRGB→YUB→RGBと戻ってきたときの誤差
こればかりはソースとして一度RGBになってしまったものを使う以上仕方ない
結論としては特に変わらず
540:名無しさん＠編集中
17/10/21 23:22:47.11 SivVBkBJ0.net
コマンドライン
URLﾘﾝｸ(pastebin.com)
541:名無しさん＠編集中
17/10/21 23:36:03.65 +8CAoyQn0.net
>>539
8bit crf20だとディザが残ってるね。静止画だからビット数多く割けたのかな
動画だと>>474にあるようにディザは消えちゃうんだよ
542:名無しさん＠編集中
17/10/21 23:36:47.08 SivVBkBJ0.net
>>537
のっぺりする＝ソースのディテールを再現できないほどの低レート、なんだから、
＞画質
＞(8bitでディザを残す) ≒ (のっぺりした10bit)
という等号はおかしい
のっぺり度とファイルサイズは無関係な量じゃなくて関数になってるんだからどちらかを固定しないと不等号として意味が無い
正しくは
データ量
A:(10bitでディザ(≒ディテール)を残す) ≒ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) ≒ D:(のっぺりした8bit)
としたとき、
画質
A:(10bitでディザ(≒ディテール)を残す) ≧ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) >> D:(のっぺりした8bit)
ではないの？
・AとBなら再生互換性があってとくにデメリットがないB
・CとDなら互換性は無視できればC、ただし画質の劣化の方向性が違うのでトレードオフ要素あり
じゃないの？
543:名無しさん＠編集中
17/10/21 23:54:34.41 SivVBkBJ0.net
>>541
そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う
単なるCRFの話じゃなくて（動画で単にCRFだけ上げると他の要素の情報量が過剰になる）、
psy-rdとかの出番だと思う、もちろんファイルサイズは（単にCRFを上げるほどではないにしても）増えるけど
まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで
544:名無しさん＠編集中
17/10/21 23:57:00.97 +8CAoyQn0.net
>>542
> のっぺりする＝ソースのディテールを再現できないほどの低レート
まず、想定しているのは>>539のcrf35ほどの低レートではなくて、
>>539のcrf20や>>523のようにディザが残るほどの高レートでもない
その中間
（試してるのが両極端すぎるｗ）
フルHDで２～８Mbpsとかの一般的に使われるレートだよ
そのレートだと、ディザは消えるけど、他のほとんどの目立つディテールは残る
で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
MPC-HCとかオプションにディザのオプションとかあるでしょ
だから、出力される絵は8bitでディザが残ってるのと同じような絵になる
8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま
545:名無しさん＠編集中
17/10/21 23:59:12.57 +8CAoyQn0.net
>>543
動画でディザが残せるのは相当高ビットレートだよ
>>523は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない（8bitでも10bitでも）
546:名無しさん＠編集中
17/10/22 00:04:05.35 TL71NAj40.net
さらに言うと、データ量減らすためにエンコしてるんだから、
ディザを残すのにデータ量食われるくらいなら
のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい
547:名無しさん＠編集中
17/10/22 00:14:47.36 vZIrSnTK0.net
うーん、なんかだいぶcrfに対する感覚が違うなぁ
基本アニメはcrf18～20,qcomp 0.8,psy-rd1:0.5でかなり静動のメリハリ付けてザラザラする成分残すような設定でエンコしてるんだが、
基本ディザというかザラザラしたディテールは残るし、BDソースと並べてもまず見分けつかない画質保ったまま、
10Mbps弱（概ねBDの1/5）にはなるんだがなぁ
もちろんBD素通しなのでBDの時点でバンディングなのはそのまま、ディザを追加したりはしないのでそのせいかもしれんが
たしかに砂嵐みたいなシーンだと平気でBD並みのレートになるので、
ソースを加工してでもバンディングは消す！という場合はひどいレートになってしまうのかもしれんが
548:名無しさん＠編集中
17/10/22 00:30:26.86 TL71NAj40.net
>>547
なるほど、BDだとソースが良いから状況がいいんだと思う
放送だとMPEG2だしビットレートそんなに高くないから、
ディザは残せなくて、それでもバンディングを目立たなくするために
時間軸方向に色をパタパタたさてるんだよ
それを普通に8bitでエンコすると>>512にあるように「うにょんうにょん」になる
時間軸方向にパタパタさせてるもんだから、ディザを追加してもエンコしたら消えちゃう
時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ
549:名無しさん＠編集中
17/10/22 00:34:12.01 TL71NAj40.net
BDだとこの「うにょんうにょん」が出ないんだろうね
550:名無しさん＠編集中
17/10/22 00:40:12.87 vZIrSnTK0.net
>>548
地デジソースもたまにエンコードするけど、
ソースに加工しない（ソース時点で起こっているあらゆるアーティファクトはそのまま）という前提なら
crf20ぐらいでアニメならソースほぼそのままでサイズもいい線（半分程度）にはなるんだがな
さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない
まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる
ソースを加工してでもバンディング消す（＝8bitならディザを残して大幅にエントロピーを増やさざるをえない）かどうかが
この感覚の差なのかな？
551:名無しさん＠編集中
17/10/22 00:41:15.17 vZIrSnTK0.net
そのうにょんうにょんってのが何なのか分からんのだが、
それはソースで出てるやつなの？
それともソースにはないのにエンコードすると出るって話？
後者だとしたらさすがになんかどこかに齟齬がある気がする
552:名無しさん＠編集中
17/10/22 00:59:06.47 TL71NAj40.net
>>551
ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる
放送ソースだとx264との相性が悪いっぽくてビットレート低いと悲惨なことになる
QSVだとビットレート低くてもあまり動かないから目立たない（バンディングは残るけど）
crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない
553:名無しさん＠編集中
17/10/22 01:14:01.45 vZIrSnTK0.net
>>552
なんかその現象はこちらはピンと来ないんだよな。
関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか？
＞エンコするとそのパタパタの周期が落ちて目立つようになってくる
っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。
まずこちらにやり方として、アニメのエンコとして異端なんだとは思うんだけど、
アニメだろうが何だろうが地デジソースは60iを60pに変換して24pは一切考慮しない。
なぜならばテロップは60iで動いてたりするし、一切誤爆のない60p→24p変換ってのもないと思うから。
そもそもエンコードの目的がtsの取り回しを良くするのと
リアルタイムI/P変換の品質が悪いのであらかじめ60p化しておきたいという目的だから。
60Hz以外のモニタ持ってないから60Hz系以外のフレームレートにしても意味ないし。
まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、
むしろデータ量が多少減らせる（60pでもほぼ差分の無いフレームなので大差はない）ぐらいで
悪いことは特に起こらないと思うけど。
554:名無しさん＠編集中
17/10/22 01:16:13.79 vZIrSnTK0.net
ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。
これならばtsを再生するよりもむしろきれいなソースが得られますぜ（所詮再生するためにはリアルタイムのI/P変換である必要があるから）。
ただしエンコードは（I/P変換が律速になるので）2～5fpsを上回るのは無理。
まあここまで行かないにしてもTDeintとか使えば10fps～20fpsぐらいの許容できるfpsでまず間違いない品質になると思うけど。
555:名無しさん＠編集中
17/10/22 01:38:35.79 vZIrSnTK0.net
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも
それなら60Hzソースを24Hzにすることに無理があって、
やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも
（時間軸のNRをするのだから24Hzにしたあとやるのは論外）
556:名無しさん＠編集中
17/10/22 01:42:18.29 TL71NAj40.net
>>553
ごめん、もう説明するの疲れたわ
QTGMCはBob化ベースだから細かい文字とか潰れるんだよね
だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ
SouceMatchやLossless使うよりも効果があって、処理も軽いよ！
URLﾘﾝｸ(i.imgur.com)
どうよこれ
あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて
557:名無しさん＠編集中
17/10/22 02:16:24.06 TL71NAj40.net
やっぱ60p化が失敗とかなくていいよね
558:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 09:09:21.90 lDlFmsvMMVOTE.net
>>503
改造版のaufいただけませんか？
アド晒すので送ってください。
m y o k u 3 5 1 @ n e k o 2 . n e t
559:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 10:09:56.80 gaqeh3U00VOTE.net
>>556
githubのページで公開よろ
560:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 10:43:12.94 tb8EuU+Z0VOTE.net
普段からタブレットやスマホでx264でエンコした動画を再生しているのだが
PC(Windows)で再生するとバンディングだらけの動画でもタブレットやスマホで再生するとクリアに表示されるよな。
ほんとwindowsって動画再生の環境としては糞だよな。
561:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:16:59.94 OGLUR6Q70VOTE.net
>>560
動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが
きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ
562:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:20:42.26 OuXW9nEl0VOTE.net
>>556
KTGMC、試すアル
>>559
もうあったぞ
563:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:42:09.87 TL71NAj40VOTE.net
>>558
これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6～10が適正値だね
>>474はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6～8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ
564:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:47:02.38 iDXae9fs0VOTE.net
>>560
単にタブレットやスマホはコントラスト低いから目立たないだけじゃね
Windowsって言っても動画再生はGPUに依存する
Intelの内蔵GPUはクソ画質
565:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 16:11:54.86 TL71NAj40VOTE.net
>>558
期待させてすまん
566:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 17:35:45.57 vPHZ1rdJMVOTE.net
>>565
判定表示機能も欲しいので下さい
567:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 19:36:05.24 huQNYVlR0VOTE.net
>>544
>で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
>で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
>MPC-HCとかオプションにディザのオプションとかあるでしょ
>だから、出力される絵は8bitでディザが残ってるのと同じような絵になる
LAV Video Decoderのディザリングのことかな？
10bit深度の動画を見るのにデコーダで8bit化して出力してる人なんているんだろうか？
10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー＋EVR-CPとかにして
10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、
LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・？
568:名無しさん＠編集中
17/10/22 20:15:07.70 TL71NAj40.net
>>567
8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない
569:名無しさん＠編集中
17/10/22 20:40:18.12 vZIrSnTK0.net
>>556
QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる
まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う
570:名無しさん＠編集中
17/10/22 20:45:30.50 vZIrSnTK0.net
>>568
というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで
571:名無しさん＠編集中
17/10/22 21:07:13.27 huQNYVlR0.net
>>568
>モニタまで10bitで出力できるような環境ならそれでいいんじゃない
モニタが10bit対応かどうかは関係ないのでは。
１．モニタが10bit未対応
(10bitYUV)→LAV→(10bitYUV)→レンダラが8or10bitRGBサーフェスに描画→(8bitRGB相当の出力)→モニタ
２．モニタが10bit対応
(10bitYUV)→LAV→(10bitYUV)→レンダラが10bitRGBサーフェスに描画→(10bitRGB相当の出力)→モニタ
という違いが出るだけだし、10bitYUV→RGB変換はレンダラに任せるのが一般的だと思う。
一応
３．LAVでディザリングする場合
(10bitYUV)→LAV(ディザリング)→(8or10bitRGB)→レンダラが8or10bitRGBサーフェスに描画
→(8or10bitRGB相当の出力)→モニタ
という方法もあると言えばあるけども、LAVの出力をRGBに絞る必要があるし、使ってる人はほぼいないと思う。
572:名無しさん＠編集中
17/10/22 21:18:42.71 B85gEeQj0.net
で、x2648bitだけでデバンドはどうすりゃいいの？
573:名無しさん＠編集中
17/10/22 21:47:50.35 TL71NAj40.net
>>569
そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556はQTGMCの後に補間するから原理はちょっと違う
確かにデフォルトのNNEDI3と比べてちょっとノイズっぽいのが増えるけど
動画で見ると分からないね
まぁ、ぶっちゃけコマ送りだと動いてるところはTDeint汚いけど
動画で見ると動いてるところは分からないから、TDeintだけでも十分なんだよなｗ
>>570
> RGBの8bitのバンディングなんて見えることはない
AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ
>>571
そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
574:名無しさん＠編集中
17/10/22 22:12:53.38 huQNYVlR0.net
>>573
>AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ
試したことはないけど、高深度であっても、バンディングが発生するようなフィルタ処理をすれば
バンディングが発生するのは当然では・・・
>素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
10bitYUVを受け取ってくれる（渡して意味がある）レンダラは「madVR」と「MPC-BEのEVR-CP」かな。
MPDNあたりも大丈夫そうだと思うけど使ったことないのでわからん。
EVRやMPC-HCのEVR-CPではレンダラ内部のMixerでYUY2化されてしまうので無意味だったと思う。
575:名無しさん＠編集中
17/10/22 23:05:21.80 TL71NAj40.net
>>574
> 10bitYUVを受け取ってくれる（渡して意味がある）レンダラは「madVR」と「MPC-BEのEVR-CP」かな。
なるほど、サンクス
レンダラが10bitに対応してなくても8bitRGBで渡せば問題ないよね
モニタまで10bitで出力したいって場合は別だけど
>>571
世の中の人は「madVR」か「MPC-BEのEVR-CP」を使うのが一般的なのか
mpc-hcとか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・
576:名無しさん＠編集中
17/10/22 23:29:03.38 huQNYVlR0.net
>>575
なんかうまく伝わってないようなので書いとくけど、
・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。
・その場合、採用するのは>>571の１または２がほとんどであり、３(デコーダでRGB化)にしてる人はほぼいないだろう。
・１か２を採用する場合、madVR（多分ほとんどの人がこれかな）や、MPC-BEのEVR-CPを使うしかないだろう。
ということであって、世間一般という話はしてないよ。10bitユーザに関してはそういうものだろうという話。
まあ別に統計調査したわけじゃないけども。
３の方式にこだわる理由って何かあるの？
577:名無しさん＠編集中
17/10/22 23:35:46.02 TL71NAj40.net
>>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる
> ３の方式にこだわる理由って何かあるの？
世の中一般的な人の手を煩わせないこと
578:名無しさん＠編集中
17/10/23 01:29:13.55 CCGuLeMv0.net
>>577
>世の中一般的な人の手を煩わせないこと
LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。
579:名無しさん＠編集中
17/10/23 02:12:14.47 PdPTQ2n50.net
>>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね
拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの？
580:名無しさん＠編集中
17/10/23 02:28:08.64 PdPTQ2n50.net
あと
> ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。
これは違うと思う
再生時は8bitでも、グラデーションがきれいになるから
10bitでエンコしてるって人は多いと思うよ
別に統計調査したわけじゃないけども
581:名無しさん＠編集中
17/10/23 03:22:20.83 GGoO9AOU0.net
265だが、12bitでエンコする人もいる。
582:名無しさん＠編集中
17/10/23 07:14:50.53 VYJgHsTz0.net
デバンド10bitがファイナルアンサーってことでおｋ？
めくらとめんどくさがりはデバンド無し8bitってことだよな？
583:名無しさん＠編集中
17/10/23 09:52:34.86 GWH8jZaN0.net
>>582
１人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・
584:名無しさん＠編集中
17/10/23 10:52:56.78 ArbVx6vZM.net
無理です。こういうのは治りません
585:名無しさん＠編集中
17/10/23 12:22:06.79 GWH8jZaN0.net
>>579-580
> デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの？
暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。