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変換をしちゃったらバンディング起きまくりになるよ。
586:名無しさん＠編集中
17/10/23 12:24:02.28 GWH8jZaN0.net
>>579-580
>>574の後半は少し間違ってたかも。
１．以前はEVR/EVR-CPにP010を渡してもうまく動かなかった。
２．なので以前のLAVではEVR系にはP010ではなくNV12で渡すようにしていた。
３．Win10CUからEVR系にP010を渡しても大丈夫になったので、LAV 0.70.0からは、
Win10CU環境ではEVR系にもP010を渡すようになった。
４．Win10CU環境でMPC-BEのEVR-CPにP010を渡してCtrl+Jを見るとMixerはA2R10G10B10になっているが、
MPC-HCのEVR-CPだとMixerはYUY2になっている。
そのため、EVR系で10bitを生かせるのはMPC-BEのEVR-CP(Mixer独自改良？)だけだと思っていた。
ということだったんだけど、昨夜うちのWin10CU環境でMPC-HCのEVR系を試してみたら
P010渡しならそれなりに綺麗に見えた。（寝ぼけてなければだが）
なので、Win10CU環境に限っては、MPC-HCをデフォで使ってもP010＋EVR系で10bitをそれなりに生かせるのかも。
MixerがYUY2でも綺麗に見えたというのは釈然としないけど俺が何か勘違いしてるんだろか。
587:名無しさん＠編集中
17/10/23 14:01:50.39 C3fk7LFm0.net
バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなｗ
折角低減されたバンディングが少し再発しててワロタｗ
588:名無しさん＠編集中
17/10/23 14:03:38.98 GGoO9AOU0.net
最小限、VLCでまともに見れれば問題ないんじゃね？っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc
589:名無しさん＠編集中
17/10/23 17:00:31.81 PdPTQ2n50.net
>>585
> 暗めのグラデーションとかで試してみればわかると思うけど、
> デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。
これが違う。適切にディザリングされてればバンディングは発生しない
>>474の「デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff」を
LAVのデコーダで10bitYUV→8bitYUV変換してEVRで表示したときの画像
URLﾘﾝｸ(i.imgur.com)
これがバンディング出てるように見える？
>>474はAviUtlで読み込んでキャプチャしたから、
ディザリングなしで8bitRGBへの変換が行われてバンディングが出てるけど、
ちゃんとディザリングすれば8bitYUVへの変換でもバンディングは出ない
何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない
590:名無しさん＠編集中
17/10/23 18:01:02.87 PdPTQ2n50.net
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな
madVRはH264のノイズがそのまま出てて汚い
少なくともPascal世代のGeForce積んでるマシンなら、
WindowsデフォのEVRが画質は安定してる印象
なんか俺間違えてる？
591:名無しさん＠編集中
17/10/23 19:37:23.86 QlGXZ1na0.net
情報錯綜系LAVコメ
592:名無しさん＠編集中
17/10/24 02:20:01.25 n9jE2wGA0.net
>>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど
593:名無しさん＠編集中
17/10/25 01:53:37.49 63k5eUdT0.net
>>589-592
> 何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない
サンプルがあった方がいいだろうと思って10bitのグラデーション動画(プログレッシブ)を作成して
検証してまとめてみたけど、どうだろうか。
10bitグラデーション映像の視聴時バンディング発生テスト
まとめテキスト： URLﾘﾝｸ(pastebin.com)
動画やスクショ等： URLﾘﾝｸ(www.axfc.net)
少なくともうちのIntelHD環境では、LAVでNV12にされたものをEVRで見ると、はっきりしたバンディングが発生する。
（madVRではディザリングでごまかしてそれなりに綺麗には見える）
もしこれがそちらの環境の「NV12→EVR」でバンディングが発生せず綺麗に見えるなら、
Pascalの映像補正処理によって、ごまかされて綺麗に見えているだけだと思う。
なんにせよ少なくともプログレッシブではP010で精細なデータをレンダラに渡す方が良いのは間違いないけど、
P010のインタレ解除対応とかについてはよくわからない。
594:名無しさん＠編集中
17/10/25 03:12:22.43 czTfBjnQ0.net
>>593
おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね
595:名無しさん＠編集中
17/10/25 10:09:56.42 8tRowaog0.net
>>593
ところで8bitで再生って具体的にどうやるんだ？
プレイヤーとかデコーダにそんな細かな設定項目はないだろ？
596:名無しさん＠編集中
17/10/25 12:33:28.30 9O9mFGbAd.net
>>595
無知な上にスレチな話題を無駄に広げるんじゃねーよ
597:名無しさん＠編集中
17/10/25 13:08:41.71 BioamKEC0.net
>>595
書いてあるとおり。NV12が8bitのYUV4:2:0。P010が10bitのYUV4:2:0。
以下のように、条件によってデコーダからレンダラへの出力が変わり、10bitを生かせるかどうかも変わるので、
LAV Video Decoderの設定でNV12とP010を切り替えて実験している。
●LAV Video Decoder＋EVR
・Win10CU＋LAV.70.0以上の場合
(10bit4:2:0)→LAV→（P010）→EVR ⇒10bitソースを生かせる
・それ以外の場合
(10bit4:2:0)→LAV→（NV12）→EVR ⇒10bitソースを生かせない
●MPC-BE(r2755)内臓デコーダ＋EVR
少なくともWin10CU環境では
(10bit4:2:0)→MPC-BE(r2755)内臓デコーダ→（P010）→EVR ⇒10bitソースを生かせる
となるが、OS条件などがあるかどうかは知らない。
多分Win10CUあたりじゃないとうまくいかないんじゃないかと思う。
●LAV Video Decoder or MPC-BE(r2755)内臓デコーダ＋madVR
(10bit4:2:0)→デコーダ→（P010）→madVR ⇒10bitソースを生かせる
598:名無しさん＠編集中
17/10/25 15:12:24.15 tWKQzPChM.net
そんなに気にするならソースのまま残せばいいじゃん
599:名無しさん＠編集中
17/10/25 17:42:00.74 czTfBjnQ0.net
>>597
俺が元々言ってたのは
「8bitソースを8bitでエンコして8bitで再生」するより
「8bitソースを10bitでエンコして8bitで再生」した方がきれいになるって話
「8bit or 10bitソースを10bitでエンコして10bit再生」した方がきれいだってのは
そりゃそうだけど、そんな話してなかったし、
「10bit動画をいかに綺麗に再生するか」って話はここだとちょっとスレチかも
600:名無しさん＠編集中
17/10/25 18:05:21.56 jBdK3wWL0.net
エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める
601:名無しさん＠編集中
17/10/25 18:24:39.81 BioamKEC0.net
>>599
そちらの話をきっかけに10bit動画の再生検証とまとめをしてみただけなのであまり気にしないでくれ。
>>600
あー、たしかに>>597の書き方は誤解を生んでしまうかも。
そちらの指摘どおり、「10bitソース」とあるのは「10bitエンコされた動画」のことです。
602:名無しさん＠編集中
17/10/25 19:51:42.65 jBdK3wWL0.net
>>601
うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう
603:名無しさん＠編集中
17/10/26 00:08:06.54 ly9F1jYY0.net
>>601
じゃあ、もう少し乗っかってみる
>>594で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた
環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ
LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ）
URLﾘﾝｸ(i.imgur.com)
>>593とちょっと色の出方が違うけど、バンディングは同じようにも見える
LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ）
URLﾘﾝｸ(i.imgur.com)
>>593のmadVR-P010-ditherONと同じような表示になった
LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ）
URLﾘﾝｸ(i.imgur.com)
>>593のmadVR-NV12-ditherONと同じような表示になった
604:名無しさん＠編集中
17/10/26 00:10:27.95 ly9F1jYY0.net
Intelグラはディザリングしないんだね
うちのPascalだとレンダラで10bit→8bit変換するときはデフォでディザリングされるっぽい
605:名無しさん＠編集中
17/10/26 00:19:52.85 ly9F1jYY0.net
画質にこだわるならグラボ導入をお勧めする
606:名無しさん＠編集中
17/10/26 01:44:20.96 83kz963X0.net
理由を論理的に教えて
607:名無しさん＠編集中
17/10/26 11:37:44.52 Lqu4m2pKM.net
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る)
608:名無しさん＠編集中
17/10/26 12:05:51.59 koiMQ39k0.net
>>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1：GTX660→DVI接続→IPSパネル
モニタ2：4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える
GPUなのかモニタ原因なのか接続方法なのか…オモシロｗ
609:名無しさん＠編集中
17/10/26 12:10:12.06 h1bMYZBgM.net
比較するなら何故接続方法とディスプレイを同じにしないのかなぁ
一円にもならない雑音でしかないぞ
610:名無しさん＠編集中
17/10/26 13:52:56.00 FitUuNIK0.net
>>603
どうせ比較するならカラーバーにしてほしかった。
何故黒背景なんだ？違いがわかりにくすぎるわ。
611:名無しさん＠編集中
17/10/26 17:37:30.49 bZqhxTl+0.net
>>603
うーん・・・うちでそれらの画像を>>593（うちのIntel環境の結果）と比べると以下のように全然違って見えるけど・・・。
１番目（NV12+EVR）
少しバンディングの出方が異なるが、「EVRCP-NV12」とほぼ同じくらい。
２番目（P010+EVR）
P010出力なのに、３つの中で画質が最も酷い。細めの汚れたバンディングがはっきり見える。
「madVR-P010-ditherOff」で生じているバンディングを更に悪化させたような感じ。
「EVRCP-P010」や「madVR-P010-ditherON」の方がはるかに綺麗。
３番目（NV12+EVR(10bitサーフェス)）
「madVR-NV12-ditherON」と似てはいるが、ざわつきが酷く画質としては劣る。
バンディングがほぼ気にならないレベルになってるのは
10bitサーフェスをデスクトップ(8bitRGB)に統合する時に、もう一度ディザリングしているのかな？
結果的にバンディングが目立たなくなっているとはいえ、無駄な処理をしているとも言えるような。
うちはノートPCでモニタも6bit+FRCなTNというショボ環境だから、他の人の結果や意見も聞いてみたいところ。
612:名無しさん＠編集中
17/10/26 17:45:49.30 bZqhxTl+0.net
>>603
２番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも？
>>604-605
> Intelグラはディザリングしないんだね
ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」（LAVがレンダラに渡しているデータ）と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。
>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー？
613:名無しさん＠編集中
17/10/26 17:58:50.33 bZqhxTl+0.net
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。
614:名無しさん＠編集中
17/10/26 19:59:26.61 cJclLwoB0.net
スケーラー的には
カスタムEVRのほうが比較対象になりえるかと
615:名無しさん＠編集中
17/10/26 22:29:15.67 ly9F1jYY0.net
>>611
こちらは4Kブラビア（KJ-49X8300D）にAVアンプ（AVR-X2100W）経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
616:名無しさん＠編集中
17/10/26 23:26:47.90 ly9F1jYY0.net
>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ
617:名無しさん＠編集中
17/10/27 00:05:48.90 lbq/6KPv0.net
>>614
スケーラーってなんぞ？madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな？
>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・？
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060＋そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。
618:名無しさん＠編集中
17/10/27 00:52:10.89 XMw2Db120.net
>>617
> EVR-CPのP010処理が何か変
おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた
>>593の画像
URLﾘﾝｸ(i.imgur.com)
>>603の画像
URLﾘﾝｸ(i.imgur.com)
619:名無しさん＠編集中
17/10/27 01:02:44.22 XMw2Db120.net
一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる
ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない
620:名無しさん＠編集中
17/10/27 09:54:55.94 s36iLAYK0.net
>>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず
だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも
621:名無しさん＠編集中
17/10/27 21:30:55.30 ZmaiasnV0.net
>>618-619
申し訳ない。こちらがボケてました。
> 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。
もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。
>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。
622:名無しさん＠編集中
17/10/27 23:21:04.83 s36iLAYK0.net
>>621
プルダウンで簡単に使えるのが利点っちゃ利点＞EVRカスタム
623:名無しさん＠編集中
17/10/28 12:50:01.41 MkHSDZTa0.net
>>621
白111-P010-EVRCP(8bitサーフェス)
URLﾘﾝｸ(i.imgur.com)
624:618
17/10/28 12:51:23.89 MkHSDZTa0.net
ID変わってた
625:名無しさん＠編集中
17/10/28 14:34:52.13 FG5EURDq0.net
サンプルは>>516が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw
626:名無しさん＠編集中
17/10/28 16:07:06.26 aZTaLCEhM.net
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの？
627:名無しさん＠編集中
17/10/28 22:29:00.96 hchLrIBF0.net
>>623
ありがとうございます。参考にさせてもらいます。
>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。
628:名無しさん＠編集中
17/10/28 23:31:24.66 k7D3xxA+0.net
>>626
基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉
629:名無しさん＠編集中
17/10/29 09:40:11.40 dhWMtRCq0.net
MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか？
630:名無しさん＠編集中
17/10/29 09:43:54.16 BrtN7tba0.net
no-info パラメータって x264 にはないんだっけ？
631:名無しさん＠編集中
17/10/29 09:45:36.07 BrtN7tba0.net
>>630
あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう
632:名無しさん＠編集中
17/10/29 10:25:41.22 KYvLeTqdd.net
エンコード日とかって
muxし直したら新しく書き換えられるから
x264とはまた別じゃないかな？
633:名無しさん＠編集中
17/10/29 12:30:57.98 NansAZRP0NIKU.net
>>632が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。
634:名無しさん＠編集中
17/10/30 09:36:19.37 uLnu7qaJ0.net
muxプログラムを改変する
635:名無しさん＠編集中
17/10/30 15:01:11.04 720xvp1Sx.net
わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな
636:名無しさん＠編集中
17/10/30 15:02:21.57 uLnu7qaJ0.net
P2Pなんでまだあんのか？
637:名無しさん＠編集中
17/10/30 15:49:28.52 3lz3qnqA0.net
違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。
638:名無しさん＠編集中
17/10/30 16:38:40.79 rJwJGDaI0.net
ボクが一番早くエンコしたんだッ！
639:名無しさん＠編集中
17/10/30 20:41:33.46 cDns2kcE0.net
ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。
640:名無しさん＠編集中
17/10/31 11:38:38.08 TbmUAHOn0.net
>>635
デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね？
641:名無しさん＠編集中
17/10/31 11:45:43.27 TbmUAHOn0.net
あとはme dia にしてるのをバレたくないとかw
642:名無しさん＠編集中
17/10/31 12:28:54.81 jvMJnAPgM.net
>>639
それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎
643:名無しさん＠編集中
17/10/31 14:36:40.95 41mjP/K80.net
>>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。
>>642
「（ファイラーで）作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。
644:名無しさん＠編集中
17/10/31 18:31:40.36 IvmGk3l40.net
>>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ
645:名無しさん＠編集中
17/11/05 19:56:26.63 PcnMP+Wd0.net
x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか?
646:名無しさん＠編集中
17/11/05 22:57:38.08 w1/54n9e0.net
悩む必要ないだろ
647:名無しさん＠編集中
17/11/06 09:49:57.89 fjXKV0Z6M.net
>>645
両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが
648:名無しさん＠編集中
17/11/06 12:20:23.32 nWEh0PuI0.net
オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?
649:名無しさん＠編集中
17/11/06 12:45:07.90 PJNEo3fvd.net
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば？
それでもコア数多い7920Xの方が速いだろうけど
650:名無しさん＠編集中
17/11/06 13:05:09.71 AhYKSv2j0.net
threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。
Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。
651:名無しさん＠編集中
17/11/06 13:12:22.24 oJ3dfrAb0.net
4～8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた
652:名無しさん＠編集中
17/11/06 16:34:37.78 X8UDX3Yv0.net
貴重なご意見いろいろと感謝でごわす。
653:名無しさん＠編集中
17/11/07 09:07:41.08 qqxdUWwBa.net
並列でエンコードすればよいのでは？
654:名無しさん＠編集中
17/11/07 09:14:27.30 JI9elUeS0.net
良いプラグインを選んだり自分で最適化ビルドして
うまいことavsを書けばコア数の多さを
純粋に速度upに繋げることはできる
655:名無しさん＠編集中
17/11/08 15:50:54.81 b8akNCrvd.net
x264のソースで、
参照しているマクロブロックについて
書かれているところが分かる人いないかな？
656:名無しさん＠編集中
17/11/08 21:48:17.18 QomPI2yH0.net
CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね
intel vtune買えるほど、こずかいあったら解析してみたいなー
657:名無しさん＠編集中
17/11/08 21:53:09.78 2xU4/lpbM.net
メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない
658:名無しさん＠編集中
17/11/09 03:55:05.26 2lLHGB5mx.net
x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか
659:名無しさん＠編集中
17/11/09 12:08:59.88 dAkiAuRl0.net
>>656
h.264の基本設計が古いのが原因