x264 rev43©2ch.net

Q ニコニコ用の動画を作りたい。
A 板違い。Youtube板の"FLV/MP4エンコードスレ"でどぞ。

Q 圧縮codecありませんか?AviUtlのx264guiEx.auoの使い方は?
A x264 VFW GUI専用スレでどうぞ。
   x264vfw GUI専用スレ Part9
   http://peace.2ch.net/test/read.cgi/avi/1351856057/

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ。
   x264 初心者質問スレ part6
   http://peace.2ch.net/test/read.cgi/avi/1347527423/

[本家]
http://www.videolan.org/developers/x264.html
http://git.videolan.org/?p=x264.git;a=summary (ソース/チェンジログ)
http://web.archive.org/web/20150419065724/http://x264dev.multimedia.cx/ (開発者ブログ跡地)
http://web.archive.org/web/20141203142708/http://doom10.org/index.php (公式フォーラム跡地)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル)
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル)

542名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:36:47.08ID:SivVBkBJ0
>>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名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:54:34.41ID:SivVBkBJ0
>>541
そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う
単なるCRFの話じゃなくて(動画で単にCRFだけ上げると他の要素の情報量が過剰になる)、
psy-rdとかの出番だと思う、もちろんファイルサイズは(単にCRFを上げるほどではないにしても)増えるけど

まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで

544名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:57:00.97ID:+8CAoyQn0
>>542
> のっぺりする=ソースのディテールを再現できないほどの低レート

まず、想定しているのは>>539のcrf35ほどの低レートではなくて、
>>539のcrf20や>>523のようにディザが残るほどの高レートでもない
その中間
(試してるのが両極端すぎるw)

フルHDで2〜8Mbpsとかの一般的に使われるレートだよ
そのレートだと、ディザは消えるけど、他のほとんどの目立つディテールは残る

で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
MPC-HCとかオプションにディザのオプションとかあるでしょ
だから、出力される絵は8bitでディザが残ってるのと同じような絵になる

8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま

545名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:59:12.57ID:+8CAoyQn0
>>543
動画でディザが残せるのは相当高ビットレートだよ
>>523は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない(8bitでも10bitでも)

546名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:04:05.35ID:TL71NAj40
さらに言うと、データ量減らすためにエンコしてるんだから、
ディザを残すのにデータ量食われるくらいなら
のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい

547名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:14:47.36ID:vZIrSnTK0
うーん、なんかだいぶcrfに対する感覚が違うなぁ
基本アニメはcrf18〜20,qcomp 0.8,psy-rd1:0.5でかなり静動のメリハリ付けてザラザラする成分残すような設定でエンコしてるんだが、
基本ディザというかザラザラしたディテールは残るし、BDソースと並べてもまず見分けつかない画質保ったまま、
10Mbps弱(概ねBDの1/5)にはなるんだがなぁ
もちろんBD素通しなのでBDの時点でバンディングなのはそのまま、ディザを追加したりはしないのでそのせいかもしれんが

たしかに砂嵐みたいなシーンだと平気でBD並みのレートになるので、
ソースを加工してでもバンディングは消す!という場合はひどいレートになってしまうのかもしれんが

548名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:30:26.86ID:TL71NAj40
>>547
なるほど、BDだとソースが良いから状況がいいんだと思う

放送だとMPEG2だしビットレートそんなに高くないから、
ディザは残せなくて、それでもバンディングを目立たなくするために
時間軸方向に色をパタパタたさてるんだよ

それを普通に8bitでエンコすると>>512にあるように「うにょんうにょん」になる
時間軸方向にパタパタさせてるもんだから、ディザを追加してもエンコしたら消えちゃう

時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ

549名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:34:12.01ID:TL71NAj40
BDだとこの「うにょんうにょん」が出ないんだろうね

550名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:40:12.87ID:vZIrSnTK0
>>548
地デジソースもたまにエンコードするけど、
ソースに加工しない(ソース時点で起こっているあらゆるアーティファクトはそのまま)という前提なら
crf20ぐらいでアニメならソースほぼそのままでサイズもいい線(半分程度)にはなるんだがな
さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない
まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる

ソースを加工してでもバンディング消す(=8bitならディザを残して大幅にエントロピーを増やさざるをえない)かどうかが
この感覚の差なのかな?

551名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:41:15.17ID:vZIrSnTK0
そのうにょんうにょんってのが何なのか分からんのだが、
それはソースで出てるやつなの?
それともソースにはないのにエンコードすると出るって話?
後者だとしたらさすがになんかどこかに齟齬がある気がする

552名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:59:06.47ID:TL71NAj40
>>551
ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる

放送ソースだとx264との相性が悪いっぽくてビットレート低いと悲惨なことになる
QSVだとビットレート低くてもあまり動かないから目立たない(バンディングは残るけど)

crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない

553名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:14:01.45ID:vZIrSnTK0
>>552
なんかその現象はこちらはピンと来ないんだよな。
関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか?
>エンコするとそのパタパタの周期が落ちて目立つようになってくる
っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。

まずこちらにやり方として、アニメのエンコとして異端なんだとは思うんだけど、
アニメだろうが何だろうが地デジソースは60iを60pに変換して24pは一切考慮しない。
なぜならばテロップは60iで動いてたりするし、一切誤爆のない60p→24p変換ってのもないと思うから。
そもそもエンコードの目的がtsの取り回しを良くするのと
リアルタイムI/P変換の品質が悪いのであらかじめ60p化しておきたいという目的だから。
60Hz以外のモニタ持ってないから60Hz系以外のフレームレートにしても意味ないし。

まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、
むしろデータ量が多少減らせる(60pでもほぼ差分の無いフレームなので大差はない)ぐらいで
悪いことは特に起こらないと思うけど。

554名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:16:13.79ID:vZIrSnTK0
ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。
これならばtsを再生するよりもむしろきれいなソースが得られますぜ(所詮再生するためにはリアルタイムのI/P変換である必要があるから)。
ただしエンコードは(I/P変換が律速になるので)2〜5fpsを上回るのは無理。
まあここまで行かないにしてもTDeintとか使えば10fps〜20fpsぐらいの許容できるfpsでまず間違いない品質になると思うけど。

555名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:38:35.79ID:vZIrSnTK0
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも

それなら60Hzソースを24Hzにすることに無理があって、
やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも
(時間軸のNRをするのだから24Hzにしたあとやるのは論外)

556名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 01:42:18.29ID:TL71NAj40
>>553
ごめん、もう説明するの疲れたわ

QTGMCはBob化ベースだから細かい文字とか潰れるんだよね
だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ
SouceMatchやLossless使うよりも効果があって、処理も軽いよ!
https://i.imgur.com/bhoxmSQ.png

どうよこれ

あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて

557名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 02:16:24.06ID:TL71NAj40
やっぱ60p化が失敗とかなくていいよね

>>503
改造版のaufいただけませんか?
アド晒すので送ってください。

m y o k u 3 5 1 @ n e k o 2 . n e t

>>556
githubのページで公開よろ

普段からタブレットやスマホでx264でエンコした動画を再生しているのだが
PC(Windows)で再生するとバンディングだらけの動画でもタブレットやスマホで再生するとクリアに表示されるよな。
ほんとwindowsって動画再生の環境としては糞だよな。

561名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? fad2-yWqP)2017/10/22(日) 15:16:59.94ID:OGLUR6Q70VOTE
>>560
動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが
きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ

>>556
KTGMC、試すアル

>>559
もうあったぞ

>>558
これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6〜10が適正値だね

>>474はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6〜8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ

>>560
単にタブレットやスマホはコントラスト低いから目立たないだけじゃね
Windowsって言っても動画再生はGPUに依存する
Intelの内蔵GPUはクソ画質

>>558
期待させてすまん

>>565
判定表示機能も欲しいので下さい

>>544
>で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
>で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
>MPC-HCとかオプションにディザのオプションとかあるでしょ
>だから、出力される絵は8bitでディザが残ってるのと同じような絵になる

LAV Video Decoderのディザリングのことかな?
10bit深度の動画を見るのにデコーダで8bit化して出力してる人なんているんだろうか?

10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー+EVR-CPとかにして
10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、
LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・?

568名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 20:15:07.70ID:TL71NAj40
>>567
8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない

569名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 20:40:18.12ID:vZIrSnTK0
>>556
QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる

まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う

570名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 20:45:30.50ID:vZIrSnTK0
>>568
というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで

571名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 21:07:13.27ID:huQNYVlR0
>>568
>モニタまで10bitで出力できるような環境ならそれでいいんじゃない

モニタが10bit対応かどうかは関係ないのでは。

1.モニタが10bit未対応
 (10bitYUV)→LAV→(10bitYUV)→レンダラが8or10bitRGBサーフェスに描画→(8bitRGB相当の出力)→モニタ

2.モニタが10bit対応
 (10bitYUV)→LAV→(10bitYUV)→レンダラが10bitRGBサーフェスに描画→(10bitRGB相当の出力)→モニタ

という違いが出るだけだし、10bitYUV→RGB変換はレンダラに任せるのが一般的だと思う。

一応

3.LAVでディザリングする場合
 (10bitYUV)→LAV(ディザリング)→(8or10bitRGB)→レンダラが8or10bitRGBサーフェスに描画
  →(8or10bitRGB相当の出力)→モニタ

という方法もあると言えばあるけども、LAVの出力をRGBに絞る必要があるし、使ってる人はほぼいないと思う。

572名無しさん@編集中 (ワッチョイ a198-iDVv)2017/10/22(日) 21:18:42.71ID:B85gEeQj0
で、x2648bitだけでデバンドはどうすりゃいいの?

573名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 21:47:50.35ID:TL71NAj40
>>569
そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556はQTGMCの後に補間するから原理はちょっと違う

確かにデフォルトのNNEDI3と比べてちょっとノイズっぽいのが増えるけど
動画で見ると分からないね

まぁ、ぶっちゃけコマ送りだと動いてるところはTDeint汚いけど
動画で見ると動いてるところは分からないから、TDeintだけでも十分なんだよなw

>>570
> RGBの8bitのバンディングなんて見えることはない

AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ

>>571
そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの?

574名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 22:12:53.38ID:huQNYVlR0
>>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名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 23:05:21.80ID:TL71NAj40
>>574
> 10bitYUVを受け取ってくれる(渡して意味がある)レンダラは「madVR」と「MPC-BEのEVR-CP」かな。

なるほど、サンクス
レンダラが10bitに対応してなくても8bitRGBで渡せば問題ないよね
モニタまで10bitで出力したいって場合は別だけど

>>571
世の中の人は「madVR」か「MPC-BEのEVR-CP」を使うのが一般的なのか
mpc-hcとか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・

576名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 23:29:03.38ID:huQNYVlR0
>>575
なんかうまく伝わってないようなので書いとくけど、

 ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。

 ・その場合、採用するのは>>571の1または2がほとんどであり、3(デコーダでRGB化)にしてる人はほぼいないだろう。

 ・1か2を採用する場合、madVR(多分ほとんどの人がこれかな)や、MPC-BEのEVR-CPを使うしかないだろう。

ということであって、世間一般という話はしてないよ。10bitユーザに関してはそういうものだろうという話。
まあ別に統計調査したわけじゃないけども。

3の方式にこだわる理由って何かあるの?

577名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 23:35:46.02ID:TL71NAj40
>>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる

> 3の方式にこだわる理由って何かあるの?

世の中一般的な人の手を煩わせないこと

578名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 01:29:13.55ID:CCGuLeMv0
>>577
>世の中一般的な人の手を煩わせないこと

LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。

579名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 02:12:14.47ID:PdPTQ2n50
>>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね

拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの?

580名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 02:28:08.64ID:PdPTQ2n50
あと

> ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。

これは違うと思う
再生時は8bitでも、グラデーションがきれいになるから
10bitでエンコしてるって人は多いと思うよ

別に統計調査したわけじゃないけども

581名無しさん@編集中 (ワッチョイ da60-FRG4)2017/10/23(月) 03:22:20.83ID:GGoO9AOU0
265だが、12bitでエンコする人もいる。

582名無しさん@編集中 (ワッチョイ a550-0GSP)2017/10/23(月) 07:14:50.53ID:VYJgHsTz0
デバンド10bitがファイナルアンサーってことでおk?
めくらとめんどくさがりはデバンド無し8bitってことだよな?

583名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 09:52:34.86ID:GWH8jZaN0
>>582
1人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・

584名無しさん@編集中 (ブーイモ MM71-dNV6)2017/10/23(月) 10:52:56.78ID:ArbVx6vZM
無理です。こういうのは治りません

585名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 12:22:06.79ID:GWH8jZaN0
>>579-580

> デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの?

暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。

586名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 12:24:02.28ID:GWH8jZaN0
>>579-580

>>574の後半は少し間違ってたかも。

 1.以前はEVR/EVR-CPにP010を渡してもうまく動かなかった。
 2.なので以前のLAVではEVR系にはP010ではなくNV12で渡すようにしていた。
 3.Win10CUからEVR系にP010を渡しても大丈夫になったので、LAV 0.70.0からは、
   Win10CU環境ではEVR系にもP010を渡すようになった。
 4.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名無しさん@編集中 (ワッチョイ 5568-6XL8)2017/10/23(月) 14:01:50.39ID:C3fk7LFm0
バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなw
折角低減されたバンディングが少し再発しててワロタw

588名無しさん@編集中 (ワッチョイ da60-FRG4)2017/10/23(月) 14:03:38.98ID:GGoO9AOU0
最小限、VLCでまともに見れれば問題ないんじゃね?っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc

589名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 17:00:31.81ID:PdPTQ2n50
>>585
> 暗めのグラデーションとかで試してみればわかると思うけど、
> デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。

これが違う。適切にディザリングされてればバンディングは発生しない

>>474の「デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff」を
LAVのデコーダで10bitYUV→8bitYUV変換してEVRで表示したときの画像
https://i.imgur.com/FDzP7Hu.png

これがバンディング出てるように見える?

>>474はAviUtlで読み込んでキャプチャしたから、
ディザリングなしで8bitRGBへの変換が行われてバンディングが出てるけど、
ちゃんとディザリングすれば8bitYUVへの変換でもバンディングは出ない

何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない

590名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 18:01:02.87ID:PdPTQ2n50
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな

madVRはH264のノイズがそのまま出てて汚い

少なくともPascal世代のGeForce積んでるマシンなら、
WindowsデフォのEVRが画質は安定してる印象

なんか俺間違えてる?

591名無しさん@編集中 (ワッチョイW a161-rgn4)2017/10/23(月) 19:37:23.86ID:QlGXZ1na0
情報錯綜系LAVコメ

592名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/24(火) 02:20:01.25ID:n9jE2wGA0
>>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど

新着レスの表示
レスを投稿する