X
x264 rev43©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠編集中 転載ダメ©2ch.net (ﾄﾞｺｸﾞﾛ MM83-FuHd)
垢版 |
2017/01/28(土) 12:06:57.70ID:rzZP243DM
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チャンネル）
0552名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 00:59:06.47ID:TL71NAj40
>>551
ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる

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

crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない
0553名無しさん＠編集中 (ﾜｯﾁｮｲ 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でもほぼ差分の無いフレームなので大差はない）ぐらいで
悪いことは特に起こらないと思うけど。
0554名無しさん＠編集中 (ﾜｯﾁｮｲ 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でまず間違いない品質になると思うけど。
0555名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/22(日) 01:38:35.79ID:vZIrSnTK0
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも

それなら60Hzソースを24Hzにすることに無理があって、
やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも
（時間軸のNRをするのだから24Hzにしたあとやるのは論外）
0556名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 01:42:18.29ID:TL71NAj40
>>553
ごめん、もう説明するの疲れたわ

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

どうよこれ

あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて
0561名無しさん＠そうだ選挙に行こう！ Go to vote! (選挙行ったか？ fad2-yWqP)
垢版 |
2017/10/22(日) 15:16:59.94ID:OGLUR6Q70VOTE
>>560
動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが
きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ
0563名無しさん＠そうだ選挙に行こう！ Go to vote! (選挙行ったか？ 19a5-0GSP)
垢版 |
2017/10/22(日) 15:42:09.87ID:TL71NAj40VOTE
>>558
これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6〜10が適正値だね

>>474はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6〜8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ
0567名無しさん＠そうだ選挙に行こう！ Go to vote! (選挙行ったか？ c5ec-h3yZ)
垢版 |
2017/10/22(日) 19:36:05.24ID:huQNYVlR0VOTE
>>544
>で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
>で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
>MPC-HCとかオプションにディザのオプションとかあるでしょ
>だから、出力される絵は8bitでディザが残ってるのと同じような絵になる

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

10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー＋EVR-CPとかにして
10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、
LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・？
0568名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 20:15:07.70ID:TL71NAj40
>>567
8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない
0569名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/22(日) 20:40:18.12ID:vZIrSnTK0
>>556
QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる

まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う
0570名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/22(日) 20:45:30.50ID:vZIrSnTK0
>>568
というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで
0571名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/22(日) 21:07:13.27ID:huQNYVlR0
>>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に絞る必要があるし、使ってる人はほぼいないと思う。
0573名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 21:47:50.35ID:TL71NAj40
>>569
そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556はQTGMCの後に補間するから原理はちょっと違う

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

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

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

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

>>571
そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
0574名無しさん＠編集中 (ﾜｯﾁｮｲ 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化されてしまうので無意味だったと思う。
0575名無しさん＠編集中 (ﾜｯﾁｮｲ 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とか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・
0576名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/22(日) 23:29:03.38ID:huQNYVlR0
>>575
なんかうまく伝わってないようなので書いとくけど、

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

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

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

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

３の方式にこだわる理由って何かあるの？
0577名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 23:35:46.02ID:TL71NAj40
>>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる

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

世の中一般的な人の手を煩わせないこと
0578名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/23(月) 01:29:13.55ID:CCGuLeMv0
>>577
>世の中一般的な人の手を煩わせないこと

LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。
0579名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/23(月) 02:12:14.47ID:PdPTQ2n50
>>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね

拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの？
0580名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/23(月) 02:28:08.64ID:PdPTQ2n50
あと

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

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

別に統計調査したわけじゃないけども
0582名無しさん＠編集中 (ﾜｯﾁｮｲ a550-0GSP)
垢版 |
2017/10/23(月) 07:14:50.53ID:VYJgHsTz0
デバンド10bitがファイナルアンサーってことでおｋ？
めくらとめんどくさがりはデバンド無し8bitってことだよな？
0585名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/23(月) 12:22:06.79ID:GWH8jZaN0
>>579-580

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

暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。
0586名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/23(月) 12:24:02.28ID:GWH8jZaN0
>>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でも綺麗に見えたというのは釈然としないけど俺が何か勘違いしてるんだろか。
0587名無しさん＠編集中 (ﾜｯﾁｮｲ 5568-6XL8)
垢版 |
2017/10/23(月) 14:01:50.39ID:C3fk7LFm0
バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなｗ
折角低減されたバンディングが少し再発しててワロタｗ
0588名無しさん＠編集中 (ﾜｯﾁｮｲ da60-FRG4)
垢版 |
2017/10/23(月) 14:03:38.98ID:GGoO9AOU0
最小限、VLCでまともに見れれば問題ないんじゃね？っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc
0589名無しさん＠編集中 (ﾜｯﾁｮｲ 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で再生してもバンディングは出ない
0590名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/23(月) 18:01:02.87ID:PdPTQ2n50
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな

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

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

なんか俺間違えてる？
0592名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/24(火) 02:20:01.25ID:n9jE2wGA0
>>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど
0593名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/25(水) 01:53:37.49ID:63k5eUdT0
>>589-592
> 何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない

サンプルがあった方がいいだろうと思って10bitのグラデーション動画(プログレッシブ)を作成して
検証してまとめてみたけど、どうだろうか。

　10bitグラデーション映像の視聴時バンディング発生テスト
　　まとめテキスト： https://pastebin.com/PjXMXesZ
　　動画やスクショ等： https://www.axfc.net/u/3856752.zip

少なくともうちのIntelHD環境では、LAVでNV12にされたものをEVRで見ると、はっきりしたバンディングが発生する。
（madVRではディザリングでごまかしてそれなりに綺麗には見える）

もしこれがそちらの環境の「NV12→EVR」でバンディングが発生せず綺麗に見えるなら、
Pascalの映像補正処理によって、ごまかされて綺麗に見えているだけだと思う。

なんにせよ少なくともプログレッシブではP010で精細なデータをレンダラに渡す方が良いのは間違いないけど、
P010のインタレ解除対応とかについてはよくわからない。
0594名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/25(水) 03:12:22.43ID:czTfBjnQ0
>>593
おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね
0597名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/25(水) 13:08:41.71ID:BioamKEC0
>>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ソースを生かせる
0599名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/25(水) 17:42:00.74ID:czTfBjnQ0
>>597
俺が元々言ってたのは
「8bitソースを8bitでエンコして8bitで再生」するより
「8bitソースを10bitでエンコして8bitで再生」した方がきれいになるって話

「8bit or 10bitソースを10bitでエンコして10bit再生」した方がきれいだってのは
そりゃそうだけど、そんな話してなかったし、
「10bit動画をいかに綺麗に再生するか」って話はここだとちょっとスレチかも
0600名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/25(水) 18:05:21.56ID:jBdK3wWL0
エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める
0601名無しさん＠編集中 (ﾜｯﾁｮｲ c5ec-h3yZ)
垢版 |
2017/10/25(水) 18:24:39.81ID:BioamKEC0
>>599
そちらの話をきっかけに10bit動画の再生検証とまとめをしてみただけなのであまり気にしないでくれ。

>>600
あー、たしかに>>597の書き方は誤解を生んでしまうかも。
そちらの指摘どおり、「10bitソース」とあるのは「10bitエンコされた動画」のことです。
0602名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/25(水) 19:51:42.65ID:jBdK3wWL0
>>601
うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう
0603名無しさん＠編集中 (ﾜｯﾁｮｲ d9a5-20SA)
垢版 |
2017/10/26(木) 00:08:06.54ID:ly9F1jYY0
>>601
じゃあ、もう少し乗っかってみる
>>594で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた

環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ

LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/JUXbiHR.png
>>593とちょっと色の出方が違うけど、バンディングは同じようにも見える

LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/kL0gCho.png
>>593のmadVR-P010-ditherONと同じような表示になった

LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/BqmypsW.png
>>593のmadVR-NV12-ditherONと同じような表示になった
0607名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MMab-7n1W)
垢版 |
2017/10/26(木) 11:37:44.52ID:Lqu4m2pKM
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る)
0608名無しさん＠編集中 (ﾜｯﾁｮｲ 9390-w9fV)
垢版 |
2017/10/26(木) 12:05:51.59ID:koiMQ39k0
>>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1：GTX660→DVI接続→IPSパネル
モニタ2：4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える

GPUなのかモニタ原因なのか接続方法なのか…オモシロｗ
0611名無しさん＠編集中 (ﾜｯﾁｮｲ a9ec-DRuk)
垢版 |
2017/10/26(木) 17:37:30.49ID:bZqhxTl+0
>>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というショボ環境だから、他の人の結果や意見も聞いてみたいところ。
0612名無しさん＠編集中 (ﾜｯﾁｮｲ a9ec-DRuk)
垢版 |
2017/10/26(木) 17:45:49.30ID:bZqhxTl+0
>>603
２番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも？

>>604-605
> Intelグラはディザリングしないんだね

ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」（LAVがレンダラに渡しているデータ）と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。

>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー？
0613名無しさん＠編集中 (ﾜｯﾁｮｲ a9ec-DRuk)
垢版 |
2017/10/26(木) 17:58:50.33ID:bZqhxTl+0
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。
0615名無しさん＠編集中 (ﾜｯﾁｮｲ d9a5-20SA)
垢版 |
2017/10/26(木) 22:29:15.67ID:ly9F1jYY0
>>611
こちらは4Kブラビア（KJ-49X8300D）にAVアンプ（AVR-X2100W）経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
0616名無しさん＠編集中 (ﾜｯﾁｮｲ d9a5-20SA)
垢版 |
2017/10/26(木) 23:26:47.90ID:ly9F1jYY0
>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ
0617名無しさん＠編集中 (ﾜｯﾁｮｲ a9ec-DRuk)
垢版 |
2017/10/27(金) 00:05:48.90ID:lbq/6KPv0
>>614
スケーラーってなんぞ？madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな？

>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・？
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060＋そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。
0619名無しさん＠編集中 (ﾜｯﾁｮｲ d9a5-20SA)
垢版 |
2017/10/27(金) 01:02:44.22ID:XMw2Db120
一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる

ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない
0621名無しさん＠編集中 (ﾜｯﾁｮｲ 13ec-DRuk)
垢版 |
2017/10/27(金) 21:30:55.30ID:ZmaiasnV0
>>618-619
申し訳ない。こちらがボケてました。
　> 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。

もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。

>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。
0626名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MMab-PCft)
垢版 |
2017/10/28(土) 16:07:06.26ID:aZTaLCEhM
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの？
0639名無しさん＠編集中 (ﾜｯﾁｮｲ 1334-aAnL)
垢版 |
2017/10/30(月) 20:41:33.46ID:cDns2kcE0
ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。
0643名無しさん＠編集中 (ﾜｯﾁｮｲ a9ec-DRuk)
垢版 |
2017/10/31(火) 14:36:40.95ID:41mjP/K80
>>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。

>>642
「（ファイラーで）作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。
0644名無しさん＠編集中 (ﾜｯﾁｮｲ 13d2-kgpv)
垢版 |
2017/10/31(火) 18:31:40.36ID:IvmGk3l40
>>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ
0648名無しさん＠編集中 (ﾜｯﾁｮｲWW e15c-YD3/)
垢版 |
2017/11/06(月) 12:20:23.32ID:nWEh0PuI0
オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?
0649名無しさん＠編集中 (ｽｯｯﾌﾟ Sd62-2eRG)
垢版 |
2017/11/06(月) 12:45:07.90ID:PJNEo3fvd
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば？
それでもコア数多い7920Xの方が速いだろうけど
0650名無しさん＠編集中 (ﾜｯﾁｮｲ 2260-apvC)
垢版 |
2017/11/06(月) 13:05:09.71ID:AhYKSv2j0
threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。

Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況