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チャンネル) デノイズはNL-Means使ってる アニメ向きとも言われるが、弱くかければ実写でも10%ぐらい小さくなる 実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね 容量にも拘りなさそうだしエンコ自体してなさそう >>474 >ソース >https://i.imgur.com/GWNr9Ru.png と、 >フィルタなし 8bit --crf 20 --aq-mode 3 --tff >https://i.imgur.com/ezLaNm5.png はほぼ寸分違わないよな。 ということを言ってるんだよ。 ソースを加工して情報を補完する場合はその限りではないと>>460 で言ったとおり あくまでもソースを忠実に再現するためのエンコードという観点でしか話してなかった デバンド等でぱっと見は綺麗になったように見えるんだけど、 一方で細部の意図したざわざわなディテールも消失するし(地デジなんかのソースにはそもそもそんな情報ほぼ残ってないだろうが)、 いいことばかりの魔法のフィルターは無いのだ。その辺は好みだね。 あくまでもソース寸分違わないかどうかという観点では10bitエンコードは無駄という話。 んでもって、x264は >8bit --crf 20 --aq-mode 3 --tff みたいなほぼプリセットそのままな設定でソースほぼそのままの忠実なエンコードができるんだが、 >>466 のような話は散々出てくるし、 x265は依然としてそのレベルに達してないのだろうか 10bitで書き出すならデバンド要らなくない? あくまで内部処理が8bitを越えるデノイズやらリサイズフィルター通したのを8bitで出すための処理じゃないの? >>481 x265はビットレートをつぎ込んでの高画質はまだx264に負ける っていうかx265は4k向けの高圧縮コーデックだから2kで負けるのは仕方ない まだx265が開発途上なだけでしょ H.264と同じく低解像度から満遍なく圧縮率上げる規格だからx265の改良の余地はある >>482 そういうことでもない デバンド(も含めソースの加工)をしないならソースと同じビット数でエンコードすればいいだけ 8bitのソースを8bitビットでエンコードして当たり前だがソースからほぼ劣化が無くできるのだから、 それを10bitでエンコードしてもデータを無駄に水増しして互換性を下げているだけ たしかにフィルターをかけたら元の8bitでは表せない中間の値が出てきてしまうので、 それを10bitで表現するというのはありだし、実際効果はある(>>474 ) もちろん再び8bitに落としてもある程度フィルター効果は残ってはいるが完ぺきではない(>>474 ) >>483 H264の普及初期段階もH264は低ビットレートでそれなりに見られるようにするコーデックで、 高解像度高ビットレートではMPEG2のほうがきれいだとか言われていたが、 それは単に当時のコーデックの実装が未熟だっただけで、今どきそんな戯言を言うやつはいないのでそれと同じことだろう >>485 その水増しってのが認識を間違ってる証拠だと思う なにも水増しはしてないんだから >>486 なるのかな h.264がHD画質でmpeg2より高画質になったのは必然だけど・・ >>487 8bit to 8bitでまさにソースそのままにエンコードできるのだから、 そういう場合に10bitでエンコードすることがどう >なにも水増しはしてない なのか詳しく 何度も言うがソースに何らかの加工を施す場合はこの限りではない crf 20 出来上がりのファイルサイズめっちゃデカくなりそうだけど アニメならそうでもない さらにフレームレートと解像度によってcrf同じでも品質違ってくる ソースを忠実に再現って言うと聞こえはいいかもしれないけど、 MPEG2圧縮でできたノイズやアーティファクトまで再現しようとしなくていい しかも実際は再現できてなくて、バンディングは悪化してる(>>474 ) (圧縮で情報量が落ちる分仕方ないのだけれど) デノイズしてから圧縮したほうが綺麗なることも多いし、 テレビは「高画質化エンジン」で加工しまくって表示してる そもそも圧縮で情報量落ちる分、ある意味「加工」されちゃう 8bitきったねぇわろたwwwwwww こんなんどう見てもデバンド+10bitだろwwwwwwww 「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけwwwwwwwwwwww >>480 この違いがわからないなんてよっぽどひどいモニタ使ってるんだね >>495 「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく 趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。 >>494 デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ 緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう 特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方 というか元から保存用はもちろんTSだわ スレ違いになるのでそれについては深入りはしないが MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする >>493 意味が分からない じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、 もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う 話がややこしくなってきたので改めて整理すると >>466 に対する反論として、 8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば ということを俺言ってるだけ 8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない んでもってその観点でいうならば、 >>474 にはデバンド無し10bitの結果が無いのでその比較にはなっていない ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが >>494 のようなめくらには副作用があるって言っても 具体的な例を示してやらないとわからないだろうから言っておくと、 たとえばデバンドかけたほうは(圧縮前の時点で)右上の絵画(?)の色の境界ソフトになってるよな BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ そういう部分に目が行かず、 >8bitきったねぇわろたwwwwwww >こんなんどう見てもデバンド+10bitだろwwwwwwww みたいに草生やしてるだけだからお前はめくらなんだよ 地デジはともかくブルーレイだと>>474 のデバンドあり圧縮前のような 色の階調部分のディザを保っているからな〜 少し試してみようか これが>>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の方が少ない 画質の評価は見た人に任せるよw >>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 どうよこれ 素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想 別に絵画の精細度なんてどうでも良いんだがwww 少なくともこのソースで明らかに目につくのはバンディングだしwwwwwwwwww まじめくらやべぇわwwwwwwwwwwww _人人人人人人人人人_ J( 'ー`)し > 草刈り中のトラブル < ○={=}〇,  ̄Y^Y^ Y^Y ^Y^Y Y^Y^Y ̄ |:::::::::\, ', ´チュイーン .wwし w`(.@)wwwwwwwwwwww 彡 ⌒ ミ (´・ω・`) >>498 1,000円札を100円玉 x10に換金することをお金の水増しというのなら 「水増し」という言葉使いで正しいと思う >>499 そうね 自分のエンコードの目的は「出力サイズを小さくする」ことだから 10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった 8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね>大元は >>502 を見るとどう考えても10bit>8bitじゃんw ファイルサイズ8bitの方が小さいならまだ分かるけど 大きくてこれとかイイとこなしw 静止画だから分かりづらいけど 動画で見たらさらに目立つからなバンディングは うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで ビット数より圧縮アルゴリズムから来る話で圧縮率の問題だと思うがな 各色8ビットの静止画でバンディングを感じるなんて事はまず無いわけでさ (モニタのガンマカーブの話はまたややこしいのでカット) デバンドは近接画素間を圧縮に都合のいい様に加工するから圧縮率高くてもバンディングが解消されるって話でしょ つまり同容量で8ビット圧縮より10ビット圧縮の方が画質が優れているとしたら「8ビットより10ビットが綺麗」では無く 「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」って話だと思うんだが >>513 >8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る っていう分かりやすいサンプル(できれば追試できるようにソースも公開されてるとなおよいが難しいだろう)があればな 単に何らかのミスで素通しになってないか、エンコード設定がおかしいだけじゃないのって気がする 素通しでそんなことになったこと無いもの x265はほぼ使ったこと無いので知らん 現状のx265なら 「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」 ということもあるのかもね >>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 で色が変わってしまうということは起こらないはず 黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、 暗いところはよく見えんから適当でええやろーみたいな風潮はやめてほしい no-mbtree指定しても、まだなんかやってんだろって気がする よく見えんところをはしょってごまかすのが圧縮の本質だからなあ >>517 バランスの問題もあるな 明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね x264ならその方面のことは設定でなんとかなる柔軟性はあると思う >>515 おかしいと思うなら自分でやってみたら 1枚の画像から1フレームの動画を作るくらいできるだろう 10bit主張する人は検証画像いろいろ上げてるの、 このスレやググったりして見かけるけど、 8bit主張する人で画像を上げた人が一人もいないんだよね 論より証拠なのに勘ぐってしまう バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよww 別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ 理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ 無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で 色が変わってると考えるのが理論的思考として妥当でしょ >>519 動きのない完全静止の動画でよければ良ければやってみるよ >>520 完全素通しっていう前提で主張してるのに、色が変わった(のが分からない人はさすがにいないよな)ならもうそれはカバーできない条件だわ >>514 ソースにディザが残ってるのを圧縮してディザを消しちゃうとバンディングが出る デバンドあり 8bit --bitrate 20000 --aq-mode 3 --tff https://i.imgur.com/fA43LEJ.png ↑8bitだけどビットレート高いからディザが残っててバンディングが出てない ブルーレイとかはこんな感じ >>514 チューニング次第では? 基本的な技術は同じで違うのは色深度だけなんだから やってみた。 結論から言うと、ソースのディテールを十分再現できる程度(以下の実験ではcrf20)のビットレートがあれば8bitと10bitで差は無いが、 ソースのディテールが再現できずブロックノイズが目に余る領域(以下の実験ではcrf35)になると確かに8bitと10bitに差は出る、 そしてたしかに10bitのほうがブロックノイズのバンディングという面ではマシな結果になる。 (続く) それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、 きわめてDC成分に近い次元の成分だけが残り、10bitだとなめらかな中間値を表現できるということはあると思う。 ソースを忠実に再現できるレートでエンコードすることを中心に考えていた節があり、 低レートでそういう面があることを失念あるいは意図的に除外していたことは申し訳ない。 ただし、単純にそういう計算になるかは分からないが10bitだと概ね2割増しのデータを保存しないといけないのだから、 同じビットレートにしたときは(バンディングという側面は無視して)ブロックノイズの程度がひどくなる可能性が示唆される。 今回は静止動画なので分かりにくいが、若干文字や図形の輪郭をよく保っているのは8bitの側のような気がするし、 動きが入ればその印象がさらにどうなるか分からない。 また、何より再生の互換性が大きく低下するという重大な欠点はある。 (続く) 実験結果 バンディングがある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 なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした 一連のコマンドは禁止ワードに引っかかったのでpastebinに貼っておいた https://pastebin.com/b5fBXuRy imgur使うとある程度のサイズ超えるとjpgになってしまう urlこそpngだけど↓の2つ以外はjpg変換されてる [enc1_crf35_8] 8bit crf35 47.9KB [enc2_crf35_8] 8bit crf35 47.5KB ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、 色空間の変換はソースのmp4を作るとき一度きりだから特に影響はないだろうと思って何も設定してなかったが、 どうやらちゃんとフラグを設定しないと再生ソフトのスクリーンキャプチャーでで色が変わるので、 そのへんもきっちりやりたければ、ffmpegには -x264opts colorprim=bt709:transfer=bt709:colormatrix=smpte170m x264には --colorprim bt709 --transfer bt709 --colormatrix smpte170m を付ければOK まあファイルサイズ的には全く同じだし、これらのオプションはフラグを立てるだけでスクショの色が変わるだけで実験には影響ないと思う 実際そのオプションでもやってみたけど画質的には全く同じだし、ファイルサイズも完全に一致 まあ人に色がおかしいと疑いの目を向けた以上、こちらも正確性を期すために弁明を >>530 そうなんだ、それは知らなんだ まあURLから見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ >>527 > 10bitだと概ね2割増しのデータを保存しないといけない この認識は間違ってる 保存するのは量子化した後の値だから量子化ステップの幅(QP値から計算される)に依存する 8bitから10bitに2bit増えても、量子化ステップが4倍になれば理論的にデータ量は変わらない H264の場合、QP値が6増えると量子化ステップが2倍になるから、 >>502 見てもだいたい12増えてデータ量は同じくらいになってるでしょ >>533 単純計算して2割増しになるってのはおっしゃる通り、 QPを増やさない(=一切副作用無く画面全体に8bit→10bitの恩恵を受ける)場合のこと 単純にそうはならないしても、同じファイルサイズで考えたとき どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、 他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない のっぺりした部分に8bitのときよりも細かい量子化を行う(つまりQPが12ほどは増えない)分、 そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ (これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために) 実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える >>531 >>532 いあ正にその色に問題出てるのよ jpgはYUV420だがpngは24bit IrfanViewだと目視じゃ違いが見当たらないが Firefoxや古めの画像ビューアでみた時、pngだけ色が違う ちゃんと正解の画像見れてるのかモヤっとする >>535 ffmpegでRGB→YUV変換するときにちゃんとどういう色空間のYUVにするかちゃんと指定しないといけない (何も指定しないとたぶんBT601になる?) https://forum.videohelp.com/threads/380991-ffmpeg-x264-RGB-to-YUV とかいうのもあったりするので、もうちょっとちゃんとオプションを精査したうえで追試してPNGのまま上げられるところ探して上げるわ 普段YUVのソースしかエンコードしないので、今回使えるソースがRGBのPNGだったので、 手際が悪くなって申し訳ない >>534 のっぺりした部分に8bitよりも多くデータ量割かないと 10bitの恩恵が受けられないってのは確かにそう で、バンディングに関して言うと、8bitでバンディングを回避するには ディザを残さなくちゃいけないけど、 8bitでディザを保持するためのデータ量に比べれば のっぺりした10bit分の色を保持するためのデータ量の方が 圧倒的に小さい だから、バンディングに関しては10bitの方が圧倒的に有利 ↓こんな感じ データ量 (8bitでディザを残す) >>> (のっぺりした10bit) > (のっぺりした8bit) 画質 (8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit) ディザでバンディングを軽減した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になってしまったものを使う以上仕方ない 結論としては特に変わらず >>539 8bit crf20だとディザが残ってるね。静止画だからビット数多く割けたのかな 動画だと>>474 にあるようにディザは消えちゃうんだよ >>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、ただし画質の劣化の方向性が違うのでトレードオフ要素あり じゃないの? >>541 そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う 単なるCRFの話じゃなくて(動画で単にCRFだけ上げると他の要素の情報量が過剰になる)、 psy-rdとかの出番だと思う、もちろんファイルサイズは(単にCRFを上げるほどではないにしても)増えるけど まあ、上の例でいえばABとCDの中間の状態になるわけで、 ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、 っていうときは10bitにも利点はあると思う ある意味フィルターをかけてるとの同じことになるわけで >>542 > のっぺりする=ソースのディテールを再現できないほどの低レート まず、想定しているのは>>539 のcrf35ほどの低レートではなくて、 >>539 のcrf20や>>523 のようにディザが残るほどの高レートでもない その中間 (試してるのが両極端すぎるw) フルHDで2〜8Mbpsとかの一般的に使われるレートだよ そのレートだと、ディザは消えるけど、他のほとんどの目立つディテールは残る で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ MPC-HCとかオプションにディザのオプションとかあるでしょ だから、出力される絵は8bitでディザが残ってるのと同じような絵になる 8bitだとディザが消えてのっぺりしちゃったら、もうそれまで 8bit→8bitでディザを付加したりはしないからバンディングはそのまま >>543 動画でディザが残せるのは相当高ビットレートだよ >>523 は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから 20MbpsってCRFだと相当低い ブルーレイ並のビットレートがないとディザは残せない(8bitでも10bitでも) さらに言うと、データ量減らすためにエンコしてるんだから、 ディザを残すのにデータ量食われるくらいなら のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい うーん、なんかだいぶcrfに対する感覚が違うなぁ 基本アニメはcrf18〜20,qcomp 0.8,psy-rd1:0.5でかなり静動のメリハリ付けてザラザラする成分残すような設定でエンコしてるんだが、 基本ディザというかザラザラしたディテールは残るし、BDソースと並べてもまず見分けつかない画質保ったまま、 10Mbps弱(概ねBDの1/5)にはなるんだがなぁ もちろんBD素通しなのでBDの時点でバンディングなのはそのまま、ディザを追加したりはしないのでそのせいかもしれんが たしかに砂嵐みたいなシーンだと平気でBD並みのレートになるので、 ソースを加工してでもバンディングは消す!という場合はひどいレートになってしまうのかもしれんが >>547 なるほど、BDだとソースが良いから状況がいいんだと思う 放送だとMPEG2だしビットレートそんなに高くないから、 ディザは残せなくて、それでもバンディングを目立たなくするために 時間軸方向に色をパタパタたさてるんだよ それを普通に8bitでエンコすると>>512 にあるように「うにょんうにょん」になる 時間軸方向にパタパタさせてるもんだから、ディザを追加してもエンコしたら消えちゃう 時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、 副作用があったりで難しいんだよ BDだとこの「うにょんうにょん」が出ないんだろうね >>548 地デジソースもたまにエンコードするけど、 ソースに加工しない(ソース時点で起こっているあらゆるアーティファクトはそのまま)という前提なら crf20ぐらいでアニメならソースほぼそのままでサイズもいい線(半分程度)にはなるんだがな さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる ソースを加工してでもバンディング消す(=8bitならディザを残して大幅にエントロピーを増やさざるをえない)かどうかが この感覚の差なのかな? そのうにょんうにょんってのが何なのか分からんのだが、 それはソースで出てるやつなの? それともソースにはないのにエンコードすると出るって話? 後者だとしたらさすがになんかどこかに齟齬がある気がする >>551 ソースでは細かくパタパタしてるだけなんだけど、 エンコするとそのパタパタの周期が落ちて目立つようになってくる ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる 放送ソースだとx264との相性が悪いっぽくてビットレート低いと悲惨なことになる QSVだとビットレート低くてもあまり動かないから目立たない(バンディングは残るけど) crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない >>552 なんかその現象はこちらはピンと来ないんだよな。 関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか? >エンコするとそのパタパタの周期が落ちて目立つようになってくる っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。 まずこちらにやり方として、アニメのエンコとして異端なんだとは思うんだけど、 アニメだろうが何だろうが地デジソースは60iを60pに変換して24pは一切考慮しない。 なぜならばテロップは60iで動いてたりするし、一切誤爆のない60p→24p変換ってのもないと思うから。 そもそもエンコードの目的がtsの取り回しを良くするのと リアルタイムI/P変換の品質が悪いのであらかじめ60p化しておきたいという目的だから。 60Hz以外のモニタ持ってないから60Hz系以外のフレームレートにしても意味ないし。 まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、 むしろデータ量が多少減らせる(60pでもほぼ差分の無いフレームなので大差はない)ぐらいで 悪いことは特に起こらないと思うけど。 ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。 これならばtsを再生するよりもむしろきれいなソースが得られますぜ(所詮再生するためにはリアルタイムのI/P変換である必要があるから)。 ただしエンコードは(I/P変換が律速になるので)2〜5fpsを上回るのは無理。 まあここまで行かないにしてもTDeintとか使えば10fps〜20fpsぐらいの許容できるfpsでまず間違いない品質になると思うけど。 あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを 無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも それなら60Hzソースを24Hzにすることに無理があって、 やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも (時間軸のNRをするのだから24Hzにしたあとやるのは論外) >>553 ごめん、もう説明するの疲れたわ QTGMCはBob化ベースだから細かい文字とか潰れるんだよね だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ SouceMatchやLossless使うよりも効果があって、処理も軽いよ! https://i.imgur.com/bhoxmSQ.png どうよこれ あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて >>503 改造版のaufいただけませんか? アド晒すので送ってください。 m y o k u 3 5 1 @ n e k o 2 . n e t 普段からタブレットやスマホでx264でエンコした動画を再生しているのだが PC(Windows)で再生するとバンディングだらけの動画でもタブレットやスマホで再生するとクリアに表示されるよな。 ほんとwindowsって動画再生の環境としては糞だよな。 >>560 動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ >>556 KTGMC、試すアル >>559 もうあったぞ >>558 これ実装したときはあまり効果がなかったなと思って、 改めて見てみたら、デフォルトのしきい値15は高すぎるんだった 8bitYUVの差1はだいたい5に相当するから、6〜10が適正値だね >>474 はしきい値が高すぎてかなり強く掛かってるから副作用出まくり 普通に使えばこんな副作用でない しきい値6〜8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ >>560 単にタブレットやスマホはコントラスト低いから目立たないだけじゃね Windowsって言っても動画再生はGPUに依存する Intelの内蔵GPUはクソ画質 >>544 >で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ >で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ >MPC-HCとかオプションにディザのオプションとかあるでしょ >だから、出力される絵は8bitでディザが残ってるのと同じような絵になる LAV Video Decoderのディザリングのことかな? 10bit深度の動画を見るのにデコーダで8bit化して出力してる人なんているんだろうか? 10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー+EVR-CPとかにして 10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、 LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・? >>567 8bit出力でも効果があるっていう原理を説明しただけ ほとんどデフォのままでも10bitならきれいになる モニタまで10bitで出力できるような環境ならそれでいいんじゃない >>556 QTGMC(EdiMode="TDeint") で、TDeintと同じように輪郭はボケなくなる 結局TDeintと動作原理は同じなのかもしれないけど、 QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、 コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然 60iで失われてるところをもっとも自然に補完するとこうなるんだと思う >>568 というかYUVの8bitとRGBの8bitが1:1に対応してないから 最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、 RGBにディザをかけるかけないは全く不要だと思う 正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで >>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に絞る必要があるし、使ってる人はほぼいないと思う。 で、x2648bitだけでデバンドはどうすりゃいいの? >>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渡してくれるの? >>573 >AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ 試したことはないけど、高深度であっても、バンディングが発生するようなフィルタ処理をすれば バンディングが発生するのは当然では・・・ >素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの? 10bitYUVを受け取ってくれる(渡して意味がある)レンダラは「madVR」と「MPC-BEのEVR-CP」かな。 MPDNあたりも大丈夫そうだと思うけど使ったことないのでわからん。 EVRやMPC-HCのEVR-CPではレンダラ内部のMixerでYUY2化されてしまうので無意味だったと思う。 >>574 > 10bitYUVを受け取ってくれる(渡して意味がある)レンダラは「madVR」と「MPC-BEのEVR-CP」かな。 なるほど、サンクス レンダラが10bitに対応してなくても8bitRGBで渡せば問題ないよね モニタまで10bitで出力したいって場合は別だけど >>571 世の中の人は「madVR」か「MPC-BEのEVR-CP」を使うのが一般的なのか mpc-hcとか使ってる人は「ほぼいない」のか ちょっと認識にずれがあるようだ・・・ >>575 なんかうまく伝わってないようなので書いとくけど、 ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。 ・その場合、採用するのは>>571 の1または2がほとんどであり、3(デコーダでRGB化)にしてる人はほぼいないだろう。 ・1か2を採用する場合、madVR(多分ほとんどの人がこれかな)や、MPC-BEのEVR-CPを使うしかないだろう。 ということであって、世間一般という話はしてないよ。10bitユーザに関してはそういうものだろうという話。 まあ別に統計調査したわけじゃないけども。 3の方式にこだわる理由って何かあるの? >>576 そういうことね >>568 にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる てか、上の方から見れば分かると思うけど、バンディングの話してる 8bitRGBでもバンディングは十分消せる > 3の方式にこだわる理由って何かあるの? 世の中一般的な人の手を煩わせないこと >>577 >世の中一般的な人の手を煩わせないこと LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、 DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。 まあそれぞれの自由だけど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる