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の基本設計が古いのが原因
660:名無しさん＠編集中
17/11/09 21:23:04.94 4E6+DEQl0.net
>>659
は？
661:名無しさん＠編集中
17/11/09 23:26:26.85 8skGIZpd0.net
>>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな
662:名無しさん＠編集中
17/11/10 01:06:53.06 6Gf3GwUMd.net
>>661
Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか？
663:名無しさん＠編集中
17/11/14 22:36:13.81 QgQDG7qe0.net
x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる？
公式より、ちょこっと高速かも。
664:名無しさん＠編集中
17/11/14 23:31:21.00 Y7L7Tzex0.net
バイナリよりもソースコードが欲しい
665:名無しさん＠編集中
17/11/14 23:54:34.74 OmCERatJ0.net
最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。
666:名無しさん＠編集中
17/11/16 12:20:04.93 Lok3SOLr0.net
x264をvtuneで解析する方法
./configure ―extra-cflags=“-g3 -gdwarf-2”
667:名無しさん＠編集中
17/11/16 21:39:08.85 Lok3SOLr0.net
下手に触ったら、弄りすぎて壊れた…
x264の内部
関数内の処理時間順
URLﾘﾝｸ(iup.2ch-library.com)
呼び出し回数順
URLﾘﾝｸ(iup.2ch-library.com)
668:名無しさん＠編集中
17/11/18 15:36:47.29 mg/31u3f0.net
Intel C compilerで作った x264@0.152.2851
URLﾘﾝｸ(dotup.org)
ソースは、弄ってないバージョン
バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。
自分でビルドしたい人は、ｍｓｙｓのlinkerをmvしたりしないと通らないから要注意
669:名無しさん＠編集中
17/12/03 22:51:56.93 MUdUJt2U0.net
>>667
その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。
670:名無しさん＠編集中
17/12/03 23:17:58.10 N46X2NJO0.net
俺のjane styleではちゃんと表示できてるぞ
むしろimgurのがdat入れたりせにゃあかん
671:名無しさん＠編集中
17/12/03 23:48:24.68 EBQZzVDS0.net
今、ブラウザでアクセスしたけどリンク切れだったよ
専ブラのキャッシュに残ってるのでは？
672:名無しさん＠編集中
17/12/03 23:55:28.12 MUdUJt2U0.net
結局janeのビューアが改善すればいいだけの話か。
susieプラグインとか2004年頃から更新されてないもんな・・・
673:名無しさん＠編集中
17/12/23 15:27:24.06 a6JnGRMU0.net
r2345
誰か持って無いですか？VLCのはx264guiExに怒られるし
kmodはアーカイブ辿ってもないし
674:名無しさん＠編集中
17/12/23 21:21:11.03 VSoAQ8Gh0.net
>>673
怒られるっつっても
指定されたx264.exeはmp4出力に対応していません。
出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。
muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの？
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。
675:名無しさん＠編集中
17/12/24 13:25:40.34 3pc8lJGL0EVE.net
自ビルドすればいい
たいして、手間はかからないだろ
何をしたいのか理解できないけど
676:名無しさん＠編集中
17/12/24 13:47:04.26 PblLLtX90EVE.net
ソースもみつからないんだろうよ
677:名無しさん＠編集中
17/12/25 00:09:20.14 3pbDkQUJ0XMAS.net
>>673
つ URLﾘﾝｸ(www.solidfiles.com)
678:名無しさん＠編集中
17/12/25 00:12:41.45 3pbDkQUJ0XMAS.net
基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
でないともれなくウザいジャンクマルウェアがブラウザをフリーズさせようとするからw
679:名無しさん＠編集中
17/12/25 00:40:15.29 3pbDkQUJ0XMAS.net
r2345にこだわる理由はおそらくこれじゃないか。
AMD環境でエンコするときは、r2345以降だと拡張命令が一つ無効にされるから
若干エンコが遅くなる。そこはryzenで改善されたけど
r2346
commit 0c738e30ec025f0effdb62802685fce40cf20057
Author: Henrik Gramner
Date: Fri Jul 5 21:15:43 2013 +0200
x86: Remove X264_CPU_SSE_MISALIGN functions
Prevents a crash if the misaligned exception mask bit is cleared for some reason.
Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is miniscule.
---
x86: X264_CPU_SSE_MISALIGN関数を削除。
何がしかの理由でmisaligned exception mask bitがクリアされていた場合のクラッシュを防ぐ。
Misaligned SSE関数はAMD Phenom CPUでのみ使用され、その利得は非常に小さい。
680:名無しさん＠編集中
17/12/25 12:34:34.96 64mfmyLL0XMAS.net
ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
買い換えるという選択肢がないかもしれないけどRyzenはマジで優秀だからな
それなりにエンコする機会があるなら買って損はないと思う
性能がそこそこ優秀な割に異常に安価な1500Xあたりで組めばそれなりの価格で収まるし電気代も優しい
681:名無しさん＠編集中
17/12/25 16:35:53.17 YUlv4pKh0XMAS.net
>>677
ありがとうございます。理由は>>679氏の指摘です
本当に助かりました
682:名無しさん＠編集中
17/12/25 17:43:40.36 hZyUPP7q0XMAS.net
たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ？＞XOPとか
683:名無しさん＠編集中
17/12/25 18:01:10.84 leIDQpx9xXMAS.net
>>680
ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい
684:名無しさん＠編集中
17/12/25 19:28:13.40 3pbDkQUJ0XMAS.net
余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
APUはVCEでハードエンコできるからまだいいが、FXは限界までOCしてゴリ押しするしか無いんだよな。
685:名無しさん＠編集中
17/12/26 11:10:32.20 MqszZ9OX0.net
r2893
686:名無しさん＠編集中
17/12/27 21:16:05.28 zQsT06DJ0.net
暖房用にx264を全力で走らせてるんだが中々部屋が暖まらない寒いよー
冬季向けりヴぃじょんとかありますか？
687:名無しさん＠編集中
17/12/27 21:32:58.33 A7c/BO+S0.net
フィルタ処理をGPUにやらせて、PC台数も増やせば結構暖まるよ
688:名無しさん＠編集中
17/12/27 23:48:27.66 7YvG+X4m0.net
PCの排熱を使用した暖房機器で電気代タダってのが外国でやってなかったっけ
689:名無しさん＠編集中
17/12/28 01:23:11.91 Hdam5um00.net
マイニング
690:名無しさん＠編集中
17/12/28 01:42:45.33 AFh2AJRd0.net
副次的に温まるのは仕方がないが暖房に使おうという発想はおかしい
691:名無しさん＠編集中
17/12/28 02:17:54.51 gCKZ0KCj0.net
電熱による暖房は効率が悪いからな
電気暖房で効率重視なら現状ヒートポンプ一択
とはいえコスト度外視ならハイエンドPCを2台もフル回転させれば多分ちょっとしたセラミックヒーターくらいの発熱はあるはず
ただ熱を垂れ流すしか能がないヒーターよりは何らかの仕事をさせられる分だけ建設的なのかも知れん
692:名無しさん＠編集中
17/12/28 02:31:54.29 O4ji26IE0.net
いや～ん
693:名無しさん＠編集中
17/12/28 13:39:09.46 afSjZm/R0.net
なんとなくr2893メモ
・8bitと10bitのバイナリを統合
→１つのバイナリで8bitも10bitも出力できる。
→出力ビット深度は、追加された --output-depth で指定。デフォルトは8bit。
・--transferに arib-std-b67 を追加。(HLG：Hybrid Log Gamma)
・--colormatrixに chroma-derived-nc / chroma-derived-c / ICtCp を追加。
→2017年4月のH.264規格書で追加されたもの。
・--alternative-transferを追加
→2017年4月のH.264規格書で追加されたもの。
・その他の細かいコミットは割愛
・--fullhelpでのqpmaxのデフォルト値表示がおかしい。
--qpmax <integer> Set max QP [2147483647]
・x264guiExの8/10bit統合対応が地味に面倒そうではある。
694:名無しさん＠編集中
17/12/28 14:26:10.04 k6Qd+NbI0.net
10bitでエンコしてると8bitでエンコする機会なんて格段に減ると思うのだが。
695:名無しさん＠編集中
17/12/28 14:28:57.26 oE/hHUIQx.net
放送物はBDMV準拠で保存してるから、逆に10bitでエンコする機会がない
696:名無しさん＠編集中
17/12/28 15:30:50.89 7aUzwO6o0.net
自分の好きなようにしたらエエ。
俺は PC で再生するだけだから 10bit 派。
そのくせ BlueskyFRC を挟んでFluid Motion してるから余り意味が無いという。
697:名無しさん＠編集中
17/12/28 16:45:46.07 k6Qd+NbI0.net
x264.exeにフィルタ機能とかリサイズ機能とか正直いらないんだよな。
そういうのはAVSでやらせりゃいいんだし。
698:名無しさん＠編集中
17/12/28 17:58:21.58 PElpFoJXM.net
linuxでもWindowsでも同じようにフィルタかけられて便利
699:名無しさん＠編集中
17/12/29 21:05:04.38 dM0UDBZS0NIKU.net
x264guiEx 2.53、r2893バイナリ対応
700:名無しさん＠編集中
17/12/31 11:38:00.81 90rtTOjH0.net
誰でも自分ＰＣで稼げる方法など
参考までに、
⇒ 『政道のゴウイウセレイイ』 というＨＰで見ることができます。
グーグルで検索⇒『政道のゴウイウセレイイ』
A6L4JIAVLJ
701:名無しさん＠編集中
17/12/31 12:00:58.03 u4+XlIJ20.net
Komiser更新されないなあ
702:名無しさん＠編集中
17/12/31 13:19:58.29 dk79hbO30.net
× Komiser
〇 Komisar
tmodもまだだね。
703:名無しさん＠編集中
18/01/01 14:51:32.47 RHbXXe2Q0.net
今回modは判別ルーチン入れる必要あるしテストも含めて時間掛かるんじゃ
704:名無しさん＠編集中
18/01/01 21:35:23.29 dlGBebkV0.net
10bit版のパッチがなかったら移植の手間がかかるのでは
705:名無しさん＠編集中
18/01/05 12:33:57.79 Pcgh0yt50.net
tmodのr2893が来てた。
パッチとの互換性を考えてffmpegは2.8.xのままとか、新しいブランチ作ったとかのWARNINGあり。URLﾘﾝｸ(github.com)
kmodはまだ来てない。
706:名無しさん＠編集中
18/01/07 00:59:09.06 mh9JPq/j0.net
help見るとr2867になってるね
707:名無しさん＠編集中
18/01/07 04:48:21.14 8MeYYXbe0.net
>>706
ホントだ
708:名無しさん＠編集中
18/01/07 15:36:59.83 uxim0//O0.net
>>705-707
WARNINGに少し書かれてるけどjpsdr版tmodのr2893(実際にはr2867+74)について。
・バージョン表記→ x264 core:155 r2867+74 66b5600 t_mod_Custom_2
・tmod用の各種パッチの互換性確保を優先して公式コミットを省いたりしているので、
公式のr2893とは大きく異なるものになっている。
8/10bit統合もしておらず、別バイナリのまま。ffmpegも古いv2.8.13のまま。
・r2867までは公式masterと同じなのだが、その後はr2893までの26個のコミットのうち、
8/10bit統合のr2868を始めとした13個の公式コミットが省かれている。
(x264_Customブランチ。コミット数2880(2867+13)(2893-13))
・x264_Customブランチをベースに各種パッチを当てていった
t_mod_Custom_2ブランチ(コミット数2941)を元にバイナリがリリースされている。
r2867+公式13＋パッチ61ということで、r2867+74。
709:名無しさん＠編集中
18/01/07 19:43:34.12 WmxR42qr0.net
3行で頼む
710:名無しさん＠編集中
18/01/07 19:48:26.48 8MeYYXbe0.net
>>708
説明お疲れ様です
>>709
公式とは別物
コアな機能改善が省かれてるかどうかはわからない
.
711:名無しさん＠編集中
18/01/08 00:29:53.77 nnJbUV+b0.net
個人的に分割してくれたほうがいい気がする(1つに集約＝その分重くなる？)
x265.exeでも感じたけど･･･
712:名無しさん＠編集中
18/01/08 02:01:12.14 sREVb2Z30.net
うちでr2851kModとr2893(rigaya版)を一発比較した限りじゃ特に変わらんようだけど。
■8bit
【x264】x264 0.152.2851kMod ba24899 (8bit)
【オプション】--crf 20
【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
【. Slower】 10.73 fps, 3954.37 kb/s, duration 0:01:45.11
【 Slow】 21.50 fps, 4047.44 kb/s, duration 0:00:52.47
【. Medium】 28.53 fps, 4094.00 kb/s, duration 0:00:39.54
【Veryfast】 62.89 fps, 4100.91 kb/s, duration 0:00:17.93
【x264】x264 0.155.2893 b00bcaf
【オプション】--crf 20
【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
【. Slower】 10.88 fps, 3954.36 kb/s
【 Slow】 21.07 fps, 4047.44 kb/s
【. Medium】 28.93 fps, 4094.00 kb/s
【Veryfast】 62.15 fps, 4018.47 kb/s
713:名無しさん＠編集中
18/01/08 02:02:25.09 sREVb2Z30.net
■10bit
【x264】x264 0.152.2851kMod ba24899 (10bit)
【オプション】--crf 20
【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
【. Slower】 6.77 fps, 3923.71 kb/s, duration 0:02:46.73
【 Slow】 15.43 fps, 4072.16 kb/s, duration 0:01:13.09
【. Medium】 20.43 fps, 4141.27 kb/s, duration 0:00:55.21
【Veryfast】 40.21 fps, 4171.15 kb/s, duration 0:00:28.05
【x264】x264 0.155.2893 b00bcaf
【オプション】--crf 20 --output-depth 10
【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
【. Slower】 6.59 fps, 3923.71 kb/s
【 Slow】 14.98 fps, 4072.15 kb/s
【. Medium】 20.74 fps, 4141.26 kb/s
【Veryfast】 41.27 fps, 4115.07 kb/s
714:名無しさん＠編集中
18/01/09 00:08:32.01 JJKYVbAG0.net
普通に考えて8bitか10bitか毎フレーム判断するわけないわな
715:名無しさん＠編集中
18/01/09 00:54:02.42 Hfl6BYFl0.net
Komisar何やっとるんだ？
716:名無しさん＠編集中
18/01/09 01:05:42.16 R6ucHgby0.net
別に仕事でやってるわけじゃないんやで
717:名無しさん＠編集中
18/01/09 02:00:22.72 qOe0KmCS0.net
60000/1001で同じようにエンコしてどのぐらい出るか知りたい。
動きの多いアニメや殆どの実写映像も60fpsでエンコさせるとヌルヌル動いて気持ちいいし
718:名無しさん＠編集中
18/01/09 05:08:35.40 88bv/YTOx.net
crf20でそんなに縮むのはアニメだからだな
実写でcrf20なんてやったら12Mbpsなんて軽く越える
719:名無しさん＠編集中
18/01/09 12:12:39.70 dbYDA8uS0.net
>>717
アニメで60fpsとかよそで言うと恥ずかしいから気をつけろよ
720:名無しさん＠編集中
18/01/09 12:51:44.97 qOe0KmCS0.net
何がだよ。SAOの映画とか60fpsでエンコしてみろ、動きがヌルヌル過ぎてすげー気持ちいいから
721:名無しさん＠編集中
18/01/09 13:04:15.79 BobtuyPM0.net
映像自体が60のアニメもまったく無いわけではないがごく一部だけだな
722:名無しさん＠編集中
18/01/09 13:12:14.00 qOe0KmCS0.net
特にエンディングのスタッフロールとかは60fpsでエンコすると
テロップ類の動きがヌルヌル過ぎてすげー気持ちいい。
RPGとかのエンディングみたいに最後まで飛ばさず見よう！って気になるw
723:名無しさん＠編集中
18/01/09 16:24:41.33 cLDLIUCj0.net
>>717 >>722
フレーム補間という手法を覚えたばかりではしゃぎたくなるのはわかるけど、スレ違いなので他でやっとくれ。
何を使ってフレーム補間してるのか知らないけど、逆テレシネしてないアニメをソースにしたり
いまどきMBlockFPS()を使ってるなんてオチがなければいいけど。
>60000/1001で同じようにエンコしてどのぐらい出るか知りたい
エンコード速度(fps)は毎秒どれだけのフレームを処理できるかを表すので、元動画のフレームレートは関係ない。
フレーム数が増えれば必要時間は増えるし、フレーム補間してるならその負荷がかかるけど
それはx264とは別の話なのでこのスレでは関係ない。
>>718
>>712-713のtest-1080p.mkvは、x264/x265ベンチマークスレで使ってる実写映画の予告動画だよ。
724:名無しさん＠編集中
18/01/10 02:37:24.51 OxVNvmBN0.net
病院行け
725:名無しさん＠編集中
18/01/10 09:21:00.19 CFbPtkjP0.net
>>722
このスレでも無知を晒し続けるのマジで恥ずかしいからそれ以上やめろ
俺の共感性羞恥に効く
726:名無しさん＠編集中
18/01/10 09:25:38.85 OIe9TqRjM.net
一時期あった30/24混合のアニメは面倒だからインタレ保持でやってる
727:名無しさん＠編集中
18/01/10 11:21:20.18 7k1pcodv0.net
>>724
なんの病名だよエンコード病とかか？w
728:名無しさん＠編集中
18/01/10 12:55:19.73 lXjmbGhD0.net
むしろ動いてないところは削りまくってタイムコードで引き伸ばしてるわ
729:名無しさん＠編集中
18/01/10 15:08:45.13 W8NHXz/H0.net
60iを60pにしたというオチじゃないよな
テレビ放送をテレビで見ると60fpsで見てることすら知らなさそう
こんなことで喜べるんだから、無知っていいな
羨ましすぎる
730:名無しさん＠編集中
18/01/10 16:45:54.81 AJNxVRak0.net
昔からドラマのOPをヌルヌル綺麗にエンコしたいとか散々見たような
731:名無しさん＠編集中
18/01/10 20:59:31.15 7k1pcodv0.net
>>729
上から目線で他人のエンコ趣味をコケにしてそんなに楽しいかね？
732:名無しさん＠編集中
18/01/10 22:06:14.43 gCKQuqGL0.net
フレーム補間の60fps化だろ
実はわざわざエンコ時じゃなくて再生時にできるって知ったら発狂しそう
733:名無しさん＠編集中
18/01/10 22:15:29.99 U2nTnab9d.net
エンコ時にフレーム補間出来るツールがあるのか？
734:名無しさん＠編集中
18/01/10 22:19:27.15 7eoFLGYg0.net
>>733
A's Video Encoder なら Fluid Motion でフレーム補完したエンコがでける。
735:名無しさん＠編集中
18/01/10 23:03:33.31 kE+0C3NMM.net
インタレ解除だって再生時に出来るしな
736:名無しさん＠編集中
18/01/11 03:55:38.37 1cbDHyJ90.net
俺のブラビアで再生すれば240fpsで超ヌルヌルだぜ
737:名無しさん＠編集中
18/01/11 07:50:46.84 cPxsWcsS0.net
毎回、再生環境を選ぶようなエンコとかめんどくさ。
738:名無しさん＠編集中
18/01/11 11:27:28.15 xHT3Dywqx.net
男は黙ってBDMV準拠
739:名無しさん＠編集中
18/01/12 18:26:26.13 zF3Z/D7L0.net
エンコ日が動画埋め込まれるのを消したり変更したりはできないの？
740:名無しさん＠編集中
18/01/12 18:27:02.12 zF3Z/D7L0.net
すまぬ、訂正
エンコ日が動画に埋め込まれるのを消したり変更したりはできないの？
741:名無しさん＠編集中
18/01/12 18:39:36.95 ecpKvVhK0.net
>>740
>>629-633
742:名無しさん＠編集中
18/01/12 18:40:29.51 64eEZn7/0.net
>>739-740
>>629あたりからの流れを見てね
743:名無しさん＠編集中
18/01/12 19:26:29.27 zF3Z/D7L0.net
>>741-742
ありがとう
参考にしたいと思います
ちと使ったことのないソフトを使うようで俺には難しいかな
744:名無しさん＠編集中
18/01/14 20:53:17.63 VO/9yTd80.net
>>731
すまんね
ドヤ顔でキリッの相手は、幼稚園の先生かママにお願いしてください
745:名無しさん＠編集中
18/01/15 12:25:23.13 aaz1ubzE0.net
エンコ日やmux日を偽装や隠蔽して一体なにがしたいのやら。
746:名無しさん＠編集中
18/01/15 16:22:32.60 7iqz1FsLM.net
違法アップロードのエンコでこんなに低いcrfなのに低ビットレートってスゲー、って思われたいんだろ
747:名無しさん＠編集中
18/01/15 16:24:08.26 wQe3Tfq50.net
それにエンコ日やmux日が関係あるの？
748:名無しさん＠編集中
18/01/15 17:40:39.06 aaz1ubzE0.net
旧作アニメのエンコをして、当時の放送日時に合わせて日付を設定しちゃおう！っていうのなら
まぁわからなくもないが、それはさすがに深読みし過ぎかw
749:名無しさん＠編集中
18/01/15 18:18:31.54 AsEH1LJl0.net
検察が証拠ファイルを書き換えて事件のあった日に
750:名無しさん＠編集中
18/01/15 19:06:47.18 1aBtJVCr0.net
エンコ日時フィールドにエンコ日時以外を入れたいとは思わないな
さっきエンコしたものを放送当時にエンコしたかのように装うなんて気持ち悪いわ
起源捏造民族じゃあるまいし
751:名無しさん＠編集中
18/01/15 19:19:05.16 aaz1ubzE0.net
俺のエンコは、mkvでmuxするときにTSから拝借したEIT情報を埋め込むぐらいだな。
キャストとか諸情報とか放送当時のデータをそのまま残せてコレクション冥利に尽きるという感じ。
752:名無しさん＠編集中
18/01/15 20:22:15.47 lxTvgHNw0.net
エンコ日を偽装したいとは思わんが、
隠蔽したいと思うことはあるかな。
unixタイム0（1970/01/01,00:00:00）にすることになるだろうけど。
753:名無しさん＠編集中
18/01/16 01:36:32.03 6W/mSrv50.net
URLﾘﾝｸ(i.imgur.com)
グループポリシーで自動更新関連を全て無効、サービスでも自動更新関連を無効にしているにもかかわらず
動画エンコード開始して寝て起きたら、なんと1時間ごとに再起動されていた
当然ファイルは破損していた
もうやだこのゴミOS
Windows10 16299.192
754:名無しさん＠編集中
18/01/16 10:06:44.86 H8ZVNNZc0.net
気がついたら同じような動画を何回も拾ってる
そんなとき、拾い重複エロ動画整理のために、エンコ日やmux日はよく使うな
ファイルが壊れてるときなんか、remux時にエンコ日はそのままにしたいと思うけど
そこまでやるのはめんどくさい
755:名無しさん＠編集中
18/01/16 11:02:02.43 Q83gu4jz0.net
>>753
WindowsUpdateサービスを無効にすれば解決するぞ。ただし、長期間そのままにしてあると
定期的なライセンス認証の確認作業に不具合が生じてバルーンヘルプが出始めるかもしれないが
756:名無しさん＠編集中
18/01/31 21:16:35.20 rZJ4njBN0.net
1/19 に r2901 が来てたのね。今まで気づかなかった・・・。
あとsandboxの方には 1/22 に 「4:0:0 (monochrome) encoding support」 が来てた。
なおKomisar氏は r2851 から動き無し。
757:名無しさん＠編集中
18/02/01 13:24:21.57 AtL2er/I0.net
>>753
寝ている時間をアクティブ時間にすればいいのでは？
１度も勝手に再起動された事はないな。
758:名無しさん＠編集中
18/02/03 22:27:02.72 iiAEegYF0.net
>>753
RS2までロールバックしてみたら？
Win10は一度ロールバックするかクローンHDDから復旧させてCBBのWU確認期限を１年間にしておけば
重要なアップデートが見つかっても検知されないまま放置される。
759:名無しさん＠編集中
18/02/23 17:46:51.10 bNdCDf+U0.net
x264guiExで実写を品質基準VBR (crf)でエンコしてるのですが
この品質基準とは何を基準にしているとかあるのでしょうか？
エンコ結果をSIMM0.985に付近にしたいと思い
複数ソースを同じcrfでエンコしているのですが
SIMMの結果がまちまちで疑問に思った次第です。
また希望するSSIMになるような指標などあるのでしょうか？
760:名無しさん＠編集中
18/02/23 18:17:05.20 pufaCppw0.net
ソースによって変わるからソースにあわせてcrf値を調整するしかない。
761:名無しさん＠編集中
18/02/23 21:59:48.11 +xd/hbhx0.net
>>759
-tune ssim
762:名無しさん＠編集中
18/02/24 00:27:53.06 IJ/q997/0.net
内容的に --tune ssim は関係ないやろ。
763:名無しさん＠編集中
18/02/24 07:11:27.09 YQ1clbGi0.net
>>760
やっぱそういう感じなんですね。
ありがとうございます。
764:名無しさん＠編集中
18/02/24 07:16:05.16 EpoY8uasr.net
ちなみに、その0.985っていう値はどこから出てきたの？
765:名無しさん＠編集中
18/02/24 13:50:41.80 uGOS9fa+0.net
x264はデフォで表示されなかったっけ？
766:名無しさん＠編集中
18/02/24 18:26:20.89 9nHgYv4k0.net
SSIMの表示には --ssim が必要だけど、>>764が言いたいのは値の取得方法ではなく
・SSIM=0.985を基準にしてるのはなぜ？（なんでその数値を選んだの？）
・そもそもSSIMを基準にしたエンコードをしたいという理由は何？
（ただのテストならいいけど、実用なら主観での品質を大事にしたほうがいいよ？）
とかそういうことじゃないだろうか。
767:名無しさん＠編集中
18/02/24 22:21:49.99 EpoY8uasr.net
そういうこと
768:名無しさん＠編集中
18/02/25 19:53:52.29 HN40liws0.net
0.985についてはここで言及があるね(ソース不明だけど)
URLﾘﾝｸ(bucci.bp7.org)
他に「0.98以上」てのも
URLﾘﾝｸ(www.wikihouse.com)
769:名無しさん＠編集中
18/02/26 14:19:18.80 LKAw40ZUM.net
psy入れてたらSSIMも糞もないだろうな
lameで言う心理音響みたいなもんだから機械的指標だとうんこになる
770:名無しさん＠編集中
18/03/08 17:21:34.62 ncjlH8cj0.net
地デジ、実写、爆発シーンがあるアクション映画がソースで
爆発シーンはすでにノイズが出ているような場合
qcompをデフォの0.6から0.7に上げても
ノイズを一生懸命再現しようとビットレートを割り振ってしまって
上げる意味はないのかね？
771:名無しさん＠編集中
18/03/10 20:59:39.09 5Kkuf6wr0.net
crfで綺麗にエンコできる設定だからって
2passでビットレートを制限した場合でも
綺麗になるかってと、そうでもないんだな。
772:名無しさん＠編集中
18/03/10 23:18:51.35 IzcCyuvd0.net
crfこそがきれいにエンコオードできる設定だからね
773:名無しさん＠編集中
18/03/11 00:57:08.76 5VWGzzVFx.net
>>770
上限ビットレートを12Mbpsぐらいにしとけばいいんじゃね？
774:名無しさん＠編集中
18/03/11 09:59:37.31 jHzQQm8J0.net
上限じゃなく平均レートに6~10Mbpsを指定する必要がある
775:名無しさん＠編集中
18/03/11 11:55:25.12 wjpTvoIe0.net
いや無駄な再現なら上限を設ければってことだろJK
776:名無しさん＠編集中
18/03/11 12:37:47.82 vOQxZ3fe0.net
ノイズかどうかって人間の目ならだいたいわかるんだから
いずれAIが進化したら再エンコ専用のエンコーダで
ノイズ部分無視とか補完とかやってくれるようにならんかな
777:名無しさん＠編集中
18/03/11 12:44:41.34 H0CinTr9a.net
googleがビッグデータを使ってディテールを予測して補完するエンコーダーの研究してるよな
778:名無しさん＠編集中
18/03/11 13:43:34.74 jHzQQm8J0.net
>>775
めんご
>771からの話かと思った
779:名無しさん＠編集中
18/03/11 14:28:13.12 SslWpV+I0.net
771からの話だとして、なぜ平均レート6～10Mbpsと言い出したのかよくわからんのだが・・・
780:名無しさん＠編集中
18/03/11 19:05:37.90 jHzQQm8J0.net
crfやめて2passで高画質を狙うなら
高い平均ビットレートを指定する必要があるってこと
781:名無しさん＠編集中
18/03/12 01:58:27.24 dFyvws7u0.net
crfとか2passとか設定出さずに爆破シーンのエンコとか
言って混乱させてしまってすまん。
爆破シーンのは2passでエンコしました。
また疑問でvbv-maxrateでビットレートを指定すると、
指定した値を極端には超えないファイルが出来上がるて
認識なんだけど合ってるよね。
あとｘ264出力(GUI)Exでエンコしてんだけどマルチパスとか
サイズ確認付き品質基準の「上限ファイルビットレート」項目の
設定もビットレートのピークを制限するものだよね？
初心者とかguiスレがなくてココにこんなこと書き込んですまん。
782:名無しさん＠編集中
18/03/12 02:24:58.51 8qoNk2AH0.net
>>781
> あとｘ264出力(GUI)Exでエンコしてんだけどマルチパスとか
> サイズ確認付き品質基準の「上限ファイルビットレート」項目の
> 設定もビットレートのピークを制限するものだよね？
全然違う。
あれはできあがったファイルサイズ(ビット単位)を秒数で割った数値がそれ以下になるようにするというもの。
昔のニコ動のエコノミー回避や一般会員のビットレート制限のために作られた。
ニコ動の仕様が変わったので、もう使われることはないだろう・・・多分。
783:名無しさん＠編集中
18/03/12 02:57:46.67 M0RpU/HJ0.net
意味もわからず2pass使うバカが多いよな
784:名無しさん＠編集中
18/03/12 03:41:09.56 dFyvws7u0.net
>>782
ありがとう。
品質基準の「上限ファイルビットレート」は
目的が全く違うんだね。
>>783
いるよなｗ
CCEの影響か
785:名無しさん＠編集中
18/03/12 06:06:48.95 ijK6n5Xa0.net
マルチパスは画質を捨てて、エンコ後のデータ量を揃えたい人限定じゃね？
786:名無しさん＠編集中
18/03/12 15:20:07.23 1e6aJ3tW0.net
crf使ってるのに何度もエンコしてファイルサイズ揃えようとする馬鹿も笑えるよな
787:名無しさん＠編集中
18/03/12 15:45:56.62 4KK2qyCVM.net
psy入れてるのに毎回ログでSSIM解析値残してる俺
無駄だとわかってるけど何となくね
788:名無しさん＠編集中
18/03/13 07:25:55.28 pSIurGuv0.net
>>786
VBVでビットレ制限すればcrfでもデータ量を揃えることは可能だが
アニメ以外だと高いSSIM値になっていても糞画質な映像に仕上がってることが多い。
789:名無しさん＠編集中
18/03/13 22:09:04.65 NrXyemjW0.net
それはcrfというよりcbrになってるだろ
790:名無しさん＠編集中
18/03/17 20:33:57.41 41kAdC9fx.net
ロスレスは劣化が無いと信じて使ってたけど
なんか線が細ってるなーと思って減算して元画像と重ねたら
見事に淵のピクセルが飛んでた
このスレ読んでやっと真実が分かった
791:名無しさん＠編集中
18/03/17 20:43:54.27 UvukF0qw0.net
RGBソースをYUV4:2:0の可逆で保存してたってことかな。
そのあたりをちゃんと理解してない初心者は結構いると思う。
792:名無しさん＠編集中
18/03/18 18:52:37.64 lqrsXf4E0.net
フチっつーからエンコーダがサイズ間違えたとか？