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チャンネル）
0494名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/20(金) 23:42:25.14ID:HASgMWlT0
8bitきったねぇわろたｗｗｗｗｗｗｗ
こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ

「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけｗｗｗｗｗｗｗｗｗｗｗｗ
0496名無しさん＠編集中 (ﾜｯﾁｮｲ 81ec-h3yZ)
垢版 |
2017/10/21(土) 01:08:20.59ID:150/70DS0
>>495
「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。
0497名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 01:36:45.74ID:SivVBkBJ0
>>494
デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方

というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする
0498名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 01:42:00.04ID:SivVBkBJ0
>>493
意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う
0499名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 01:49:58.38ID:SivVBkBJ0
話がややこしくなってきたので改めて整理すると
>>466
に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない

んでもってその観点でいうならば、
>>474にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが
0500名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 02:00:41.89ID:SivVBkBJ0
>>494のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは（圧縮前の時点で）右上の絵画（？）の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ

そういう部分に目が行かず、
＞8bitきったねぇわろたｗｗｗｗｗｗｗ
＞こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
みたいに草生やしてるだけだからお前はめくらなんだよ
0502名無しさん＠編集中 (ﾜｯﾁｮｲ a59f-0GSP)
垢版 |
2017/10/21(土) 03:06:40.59ID:GOmLStnF0
これが>>474デバンドあり圧縮前をcrf0で8bit化したavc（の静止画）
https://dotup.org/uploda/dotup.org1367941.png

------------------------
これがそのavcをcrf20 8bitエンコしたもの
https://i.imgur.com/HkBnse4.png
QP:19.37 size: 31899byte

------------------------
こっちはcrf20 10bitエンコ
https://i.imgur.com/1QptJMb.png
QP:31.10 size: 29806byte


QPがとても上がってるせいかサイズは10bitの方が少ない
画質の評価は見た人に任せるよｗ
0503名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/21(土) 03:22:40.83ID:+8CAoyQn0
>>500
そう、これ使えねーなと思ってさ、直したんだよ

バンディング低減MTは、Y,Cb,Crを色別に差を見てるんだけど、
そこ変更して、「全部の色がしきい値未満だったら」にした

対象と判定されたピクセルを表示してみた結果↓
判定表示（改造前）
https://i.imgur.com/JWaCj0O.png
判定表示（改造後）
https://i.imgur.com/ISi0Xnv.png

デバンドありの圧縮前（改造後）
https://i.imgur.com/OBQeZKO.png

オレオレバンディング低減
https://i.imgur.com/dloXldb.png

どうよこれ
0506名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/21(土) 09:21:07.43ID:3Js2SGA+0
別に絵画の精細度なんてどうでも良いんだがｗｗｗ
少なくともこのソースで明らかに目につくのはバンディングだしｗｗｗｗｗｗｗｗｗｗ
まじめくらやべぇわｗｗｗｗｗｗｗｗｗｗｗｗ
0508名無しさん＠編集中 (ﾜｯﾁｮｲ c5eb-bcII)
垢版 |
2017/10/21(土) 10:08:27.63ID:/zKw8/Pi0
　　　　　　　　　　　　　＿人人人人人人人人人＿
　　J( 'ｰ`)し　　　　　＞　草刈り中のトラブル　＜
　　○=｛=｝〇,　　　　　￣Y^Y^ Y^Y ^Y^Y Y^Y^Y￣
　 　|:::::::::＼, ', ´ﾁｭｲｰﾝ
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗ
　　　　　彡 ⌒ ミ
　　　　　(´・ω・｀)
0509名無しさん＠編集中 (ﾜｯﾁｮｲ a511-/wYC)
垢版 |
2017/10/21(土) 10:30:00.87ID:4zl1vzp40
>>498
1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う

>>499
そうね
自分のエンコードの目的は「出力サイズを小さくする」ことだから
10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった

8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね＞大元は
0512名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/21(土) 10:50:48.21ID:WCEoAZaz0
>>511
うにょんうにょん動いて気持ち悪いよね
0513名無しさん＠編集中 (ｱｳｱｳｳｰT Sa89-dU7J)
垢版 |
2017/10/21(土) 16:10:41.83ID:s2dz+3eBa
うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで
ビット数より圧縮アルゴリズムから来る話で圧縮率の問題だと思うがな
各色8ビットの静止画でバンディングを感じるなんて事はまず無いわけでさ
（モニタのガンマカーブの話はまたややこしいのでカット）
デバンドは近接画素間を圧縮に都合のいい様に加工するから圧縮率高くてもバンディングが解消されるって話でしょ
つまり同容量で8ビット圧縮より10ビット圧縮の方が画質が優れているとしたら「8ビットより10ビットが綺麗」では無く
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」って話だと思うんだが
0514名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 16:54:30.19ID:SivVBkBJ0
>>513
＞8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る

っていう分かりやすいサンプル（できれば追試できるようにソースも公開されてるとなおよいが難しいだろう）があればな
単に何らかのミスで素通しになってないか、エンコード設定がおかしいだけじゃないのって気がする
素通しでそんなことになったこと無いもの

x265はほぼ使ったこと無いので知らん
現状のx265なら
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」
ということもあるのかもね
0515名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 17:26:01.84ID:SivVBkBJ0
>>502
と
>>474
で全部色が変わってしまっていて何かがおかしい
＞デバンドあり圧縮前をcrf0で8bit化したavc
っていう中間形式の作り方の詳細がよく分からないので何とも言えないけど、
色が変わってしまっているってことはどこかの段階で色空間かレンジの変換がかかってるということはないすか？

ちゃんとやれば、crf0が厳密には可逆圧縮ではないけどほぼ無劣化でエンコードできて
中間形式を経由した影響はほぼないはずで、

>>474
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/SjCSAiu.png

と

>>502
これがそのavcをcrf20 8bitエンコしたもの
https://i.imgur.com/HkBnse4.png
QP:19.37 size: 31899byte

で色が変わってしまうということは起こらないはず
0516名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/21(土) 17:53:32.26ID:WCEoAZaz0
黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、
暗いところはよく見えんから適当でええやろーみたいな風潮はやめてほしい
no-mbtree指定しても、まだなんかやってんだろって気がする
0518名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 18:01:35.48ID:SivVBkBJ0
>>517
バランスの問題もあるな
明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね
x264ならその方面のことは設定でなんとかなる柔軟性はあると思う
0519名無しさん＠編集中 (ﾜｯﾁｮｲ 1a74-0GSP)
垢版 |
2017/10/21(土) 19:48:06.19ID:+m1gFY6w0
>>515
おかしいと思うなら自分でやってみたら
1枚の画像から1フレームの動画を作るくらいできるだろう

10bit主張する人は検証画像いろいろ上げてるの、
このスレやググったりして見かけるけど、
8bit主張する人で画像を上げた人が一人もいないんだよね
論より証拠なのに勘ぐってしまう
0520名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/21(土) 19:56:10.42ID:3Js2SGA+0
バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ
0521名無しさん＠編集中 (ｱｳｱｳｳｰT Sa89-dU7J)
垢版 |
2017/10/21(土) 20:00:51.36ID:s2dz+3eBa
別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ
無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で
色が変わってると考えるのが理論的思考として妥当でしょ
0522名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 20:00:58.25ID:SivVBkBJ0
>>519
動きのない完全静止の動画でよければ良ければやってみるよ

>>520
完全素通しっていう前提で主張してるのに、色が変わった（のが分からない人はさすがにいないよな）ならもうそれはカバーできない条件だわ
0526名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 21:14:07.19ID:SivVBkBJ0
やってみた。
結論から言うと、ソースのディテールを十分再現できる程度（以下の実験ではcrf20）のビットレートがあれば8bitと10bitで差は無いが、
ソースのディテールが再現できずブロックノイズが目に余る領域（以下の実験ではcrf35）になると確かに8bitと10bitに差は出る、
そしてたしかに10bitのほうがブロックノイズのバンディングという面ではマシな結果になる。

（続く）
0527名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 21:14:31.54ID:SivVBkBJ0
それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、
きわめてDC成分に近い次元の成分だけが残り、10bitだとなめらかな中間値を表現できるということはあると思う。
ソースを忠実に再現できるレートでエンコードすることを中心に考えていた節があり、
低レートでそういう面があることを失念あるいは意図的に除外していたことは申し訳ない。

ただし、単純にそういう計算になるかは分からないが10bitだと概ね2割増しのデータを保存しないといけないのだから、
同じビットレートにしたときは（バンディングという側面は無視して）ブロックノイズの程度がひどくなる可能性が示唆される。
今回は静止動画なので分かりにくいが、若干文字や図形の輪郭をよく保っているのは8bitの側のような気がするし、
動きが入ればその印象がさらにどうなるか分からない。
また、何より再生の互換性が大きく低下するという重大な欠点はある。

（続く）
0528名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 21:16:19.44ID:SivVBkBJ0
実験結果

バンディングがある8bitソース(GWNr9Ru.png 10秒)

[enc1_crf20_8] 8bit crf20 199KB
https://i.imgur.com/UCaT1tA.png

[enc1_crf20_10] 10bit crf20 178KB
https://i.imgur.com/ezvIeKW.png

[enc1_crf35_8] 8bit crf35 47.9KB
https://i.imgur.com/gil6CHK.png

[enc1_crf35_10] 10bit crf35 48.4KB
https://i.imgur.com/6oLeO8V.jpg


ディザでバンディングを軽減した8bitソース(GWNr9Ru.png 10秒)

[enc2_crf20_8] 8bit crf20 275KB
https://i.imgur.com/mfzemcd.png

[enc2_crf20_10] 10bit crf20 245KB
https://i.imgur.com/B6IT06k.png

[enc2_crf35_8] 8bit crf35 47.5KB
https://i.imgur.com/BCUfJB5.png

[enc2_crf35_10] 10bit crf35 48.2KB
https://i.imgur.com/IKlVQcS.png
0530名無しさん＠編集中 (ﾜｯﾁｮｲ 1a74-0GSP)
垢版 |
2017/10/21(土) 22:04:06.64ID:+m1gFY6w0
imgur使うとある程度のサイズ超えるとjpgになってしまう
urlこそpngだけど↓の2つ以外はjpg変換されてる

[enc1_crf35_8] 8bit crf35 47.9KB
[enc2_crf35_8] 8bit crf35 47.5KB
0531名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 22:06:27.05ID:SivVBkBJ0
ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、
色空間の変換はソースのmp4を作るとき一度きりだから特に影響はないだろうと思って何も設定してなかったが、
どうやらちゃんとフラグを設定しないと再生ソフトのスクリーンキャプチャーでで色が変わるので、
そのへんもきっちりやりたければ、ffmpegには
-x264opts colorprim=bt709:transfer=bt709:colormatrix=smpte170m
x264には
--colorprim bt709 --transfer bt709 --colormatrix smpte170m
を付ければOK

まあファイルサイズ的には全く同じだし、これらのオプションはフラグを立てるだけでスクショの色が変わるだけで実験には影響ないと思う
実際そのオプションでもやってみたけど画質的には全く同じだし、ファイルサイズも完全に一致

まあ人に色がおかしいと疑いの目を向けた以上、こちらも正確性を期すために弁明を
0532名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 22:08:38.92ID:SivVBkBJ0
>>530
そうなんだ、それは知らなんだ
まあURLから見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う

コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ
0533名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/21(土) 22:17:40.81ID:+8CAoyQn0
>>527
> 10bitだと概ね2割増しのデータを保存しないといけない

この認識は間違ってる

保存するのは量子化した後の値だから量子化ステップの幅（QP値から計算される）に依存する
8bitから10bitに2bit増えても、量子化ステップが4倍になれば理論的にデータ量は変わらない

H264の場合、QP値が6増えると量子化ステップが2倍になるから、
>>502見てもだいたい12増えてデータ量は同じくらいになってるでしょ
0534名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 22:43:24.18ID:SivVBkBJ0
>>533
単純計算して2割増しになるってのはおっしゃる通り、
QPを増やさない（＝一切副作用無く画面全体に8bit→10bitの恩恵を受ける）場合のこと
単純にそうはならないしても、同じファイルサイズで考えたとき
どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、
他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない

のっぺりした部分に8bitのときよりも細かい量子化を行う（つまりQPが12ほどは増えない）分、
そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ
（これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために）
実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える
0535名無しさん＠編集中 (ﾜｯﾁｮｲ 1a74-0GSP)
垢版 |
2017/10/21(土) 22:46:21.80ID:+m1gFY6w0
>>531>>532
いあ正にその色に問題出てるのよ
jpgはYUV420だがpngは24bit

IrfanViewだと目視じゃ違いが見当たらないが
Firefoxや古めの画像ビューアでみた時、pngだけ色が違う
ちゃんと正解の画像見れてるのかモヤっとする
0536名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 22:57:43.40ID:SivVBkBJ0
>>535
ffmpegでRGB→YUV変換するときにちゃんとどういう色空間のYUVにするかちゃんと指定しないといけない
（何も指定しないとたぶんBT601になる？）
https://forum.videohelp.com/threads/380991-ffmpeg-x264-RGB-to-YUV
とかいうのもあったりするので、もうちょっとちゃんとオプションを精査したうえで追試してPNGのまま上げられるところ探して上げるわ

普段YUVのソースしかエンコードしないので、今回使えるソースがRGBのPNGだったので、
手際が悪くなって申し訳ない
0537名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/21(土) 23:08:19.15ID:+8CAoyQn0
>>534
のっぺりした部分に8bitよりも多くデータ量割かないと
10bitの恩恵が受けられないってのは確かにそう

で、バンディングに関して言うと、8bitでバンディングを回避するには
ディザを残さなくちゃいけないけど、
8bitでディザを保持するためのデータ量に比べれば
のっぺりした10bit分の色を保持するためのデータ量の方が
圧倒的に小さい

だから、バンディングに関しては10bitの方が圧倒的に有利

↓こんな感じ

データ量
(8bitでディザを残す) >>> (のっぺりした10bit) > (のっぺりした8bit)

画質
(8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit)
0538名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 23:21:08.68ID:SivVBkBJ0
実験結果

バンディングがある8bitソース(source1 10秒)
https://light.dotup.org/uploda/light.dotup.org487830.png

生成元
https://i.imgur.com/GWNr9Ru.png
と色も含めほぼ変わらないのを確認※


[enc1_crf20_8] 8bit crf20 185KB
https://light.dotup.org/uploda/light.dotup.org487831.png

[enc1_crf20_10] 10bit crf20 166KB
https://light.dotup.org/uploda/light.dotup.org487832.png

[enc1_crf35_8] 8bit crf35 47.9KB
https://light.dotup.org/uploda/light.dotup.org487833.png

[enc1_crf35_10] 10bit crf35 48.2KB
https://light.dotup.org/uploda/light.dotup.org487834.png

（続く）
0539名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 23:21:35.33ID:SivVBkBJ0
ディザでバンディングを軽減した8bitソース(source2 10秒)
https://light.dotup.org/uploda/light.dotup.org487838.png

生成元
https://i.imgur.com/fA43LEJ.png
と色も含めほぼ変わらないのを確認※

[enc2_crf20_8] 8bit crf20 264KB
https://light.dotup.org/uploda/light.dotup.org487835.png

[enc2_crf20_10] 10bit crf20 234KB
https://dotup.org/uploda/dotup.org1368691.png

[enc2_crf35_8] 8bit crf35 47.6KB
https://light.dotup.org/uploda/light.dotup.org487836.png

[enc2_crf35_10] 10bit crf35 47.1KB
https://light.dotup.org/uploda/light.dotup.org487837.png

※一部の領域の色が違う（ディザのほうはちょっとだけバンディング出てる）のはおそらくRGB→YUB→RGBと戻ってきたときの誤差
こればかりはソースとして一度RGBになってしまったものを使う以上仕方ない

結論としては特に変わらず
0542名無しさん＠編集中 (ﾜｯﾁｮｲ 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、ただし画質の劣化の方向性が違うのでトレードオフ要素あり

じゃないの？
0543名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 23:54:34.41ID:SivVBkBJ0
>>541
そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う
単なるCRFの話じゃなくて（動画で単にCRFだけ上げると他の要素の情報量が過剰になる）、
psy-rdとかの出番だと思う、もちろんファイルサイズは（単にCRFを上げるほどではないにしても）増えるけど

まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで
0544名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/21(土) 23:57:00.97ID:+8CAoyQn0
>>542
> のっぺりする＝ソースのディテールを再現できないほどの低レート

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

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

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

8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま
0545名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/21(土) 23:59:12.57ID:+8CAoyQn0
>>543
動画でディザが残せるのは相当高ビットレートだよ
>>523は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない（8bitでも10bitでも）
0546名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 00:04:05.35ID:TL71NAj40
さらに言うと、データ量減らすためにエンコしてるんだから、
ディザを残すのにデータ量食われるくらいなら
のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい
0547名無しさん＠編集中 (ﾜｯﾁｮｲ 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並みのレートになるので、
ソースを加工してでもバンディングは消す！という場合はひどいレートになってしまうのかもしれんが
0548名無しさん＠編集中 (ﾜｯﾁｮｲ 19a5-0GSP)
垢版 |
2017/10/22(日) 00:30:26.86ID:TL71NAj40
>>547
なるほど、BDだとソースが良いから状況がいいんだと思う

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

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

時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ
0550名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/22(日) 00:40:12.87ID:vZIrSnTK0
>>548
地デジソースもたまにエンコードするけど、
ソースに加工しない（ソース時点で起こっているあらゆるアーティファクトはそのまま）という前提なら
crf20ぐらいでアニメならソースほぼそのままでサイズもいい線（半分程度）にはなるんだがな
さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない
まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる

ソースを加工してでもバンディング消す（＝8bitならディザを残して大幅にエントロピーを増やさざるをえない）かどうかが
この感覚の差なのかな？
0551名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/22(日) 00:41:15.17ID:vZIrSnTK0
そのうにょんうにょんってのが何なのか分からんのだが、
それはソースで出てるやつなの？
それともソースにはないのにエンコードすると出るって話？
後者だとしたらさすがになんかどこかに齟齬がある気がする
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の環境は知らないけど
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況