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チャンネル） x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
24分アニメあたり800〜1.3GB前後で収まれば御の字だし 俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
自分でやるの時間の無駄だし面倒だから 地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
60iテロ処理とか雑に処理しててドン引きした。 テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
静止シーンでコピペして潰せるとかならともかく いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。 補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
存在してるだけでイラつくゴミが、これ見よがしにヌルヌル動いてたら余計腹立つわ
きったねー縞々で何書いてあるかわからないぐらいの方がざまあみろって感じでいいんだよ >>438
テロップに惨敗して負け惜しみ言ってるようにしか見えない 何度も見る事やないんやけんある程度見れてたらそれでええわ 横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ？
あとエンコ職人はウォーターマーク消しと提供のテロップ消しを一切しないのもイラつく。 どこの局のソースかが大事だからな
糞低ビットレートのMXじゃないよアピール >>444
そこがそれほどイラつくなら素直にBDを買うか借りるかした方が幸せになれそうだ x265でアニメエンコしてたけど
暗部の潰れや歪みがどうしても良くならないのでx264に戻ることになりそう
あまり詰めてないけど--crf 20 --qcomp 0.7 --aq-mode 1 --aq-strength 1.0 --psy-rd 0.65:0.20で同ビットレートの265より再現度良好 定期的に現れるけど、単に8bitでエンコしてるだけでは？ 仮にそうだとしても、ソースも8ビットなわけで、
x264にできてx265にできないならその条件ではx265が劣るというだけのこと 「その条件」ならそうかもしれんが、>>447はその条件にこだわってないだろ
バンディング対策をしたくない理由とは？ 暗部といったら aq-mode 3 だろ
なんで 1 使ってんだよ
意味わかんねーよ >>451
で、その>>447の対策（バンディングと暗部のディテールは違うと思うが）がx265ではなくx264を使うということだったのでは？
バンディングでいうと、ソースが8ビットならばいくらエンコの設定工夫しても無駄
逆にいえば少なくともx264ならエンコの設定ちゃんとすればスクリーンキャプチャしてソースと差分取ってもほぼ0にはできる ソースが10ビットなら知らんが、
アニメで（エンコードできるDRM無しの）10ビットのソースなんでまずないだろうに
8ビットのソースを10ビットでエンコードするのはただのアホ 暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき？
後者いらない？
BSプレミアムで放送された大曲花火大会中継を今さらエンコしようと思うんだ 入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん?
バンディング軽減やらで aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの？
avisynthなんかでYUV420のまま処理したなら要らんだろうけど デバンドは意味あると思うが10bit化は無駄多すぎ
アニメには必要ない
それより x265 にも aq-mode 3 はあるから ソースを加工するならたしかにまあ
普段自分はしないからその発想は抜けてた 8ビット高ビットレートでバンディング低減されてるソース（放送もブルーレイもそう）を
低ビットレートにエンコするんだったら、デバンドした上で10bit化は必須だよ まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、
少なくとも俺の使ってる4Kブラビアじゃ、チラチラしすぎて集中できない ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ
ウルトラHDブルレイなら10bit以外の設定は既存のブルレイに合わせとけば問題ないっぽいけど、
そもそも個人向けオーサリングソフトがない 447だが
単にx265とずっと格闘しててx264は浦島気味だから
とりあえずデフォルトに近い所から挙動見てみるかくらいの気持ちだったんだけど…
怒らせてしまったなら申し訳ない
ちなみにどちらも10bitでx265はAQ1〜3、Psy-rd、rdoqをあらかた上下させまくったけど
暗部の輪郭保持でx264のポン付けに及ばなかったのはガチだよ
スレチになりそうなんで、要求されない限り細かい記述は避けるけど 8bitソース素通しでも10bitでエンコードする理由はあるよ
同じソース・同じavs・同じX265設定（output-dephthだけ変更）を見比べたら
明らかに10bitが優れている
ま、crf20以下じゃ大した差じゃないかもしれないがエンコーダーとしては10bitのほうが優れているのは変わらない
ちなみにx264のほうが処理がシンプルな分、情報量が多くなることは多い バンディングだけは目に見えて効果あるよな10bit化
PCでしか再生しないし一択だわ >>465
ソースくれ、その部分だけでいいから
できれば静止画でなく動画で >>466
x265は知らんが、x264なら素通しなら8ビットでソースと寸分違わないレベルの画は出るんだよ
劣化するにしても動きやディテール部分が溶けるだけで、バンディングなんでひどくもならない
そうならないとしたら設定がおかしいか（画質が目に見えて劣化する低レートは知らん）、素通しのつもりがそうなってないパターン >>469
君が劣化しているところに気づいてないだけだと思うよ
BDでさえバンディングは問題になっているのに、その5分の1以下のビットレートで
問題にならないってありえないだろ 1/5程度のレートなら余裕余裕
アニメのBDなんて無駄に（というかほぼCBRに近い）レート食いまくってるんだから、
動かない静止画に近いところで適切に圧縮するだけでその程度には簡単になる。
もっと低いレート（1/10以下）のこと話してるのかと思ったらそんなレベルのなのか。
〜なわけがないとか想定で話してないで、実際に試してみてから話してくれ アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな
ほぼ規格上限ぎりぎりのCBRよ crfが適切で、aq-mode 3 使って、デバンドかけてれば
8bitでそんな気になるほど見分けつかんよ・・・
10bit使わにゃいかんほどだと、違うパラメータが変なんだよ ソース
https://i.imgur.com/GWNr9Ru.png
フィルタなし 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/ezLaNm5.png
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/SjCSAiu.png
デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff
https://i.imgur.com/ofiKhB3.png
デバンドありの圧縮前
https://i.imgur.com/Z3tRpYN.png
全部AviUtlでrigaya氏の拡張x264で出力
デバンドはrigaya氏のバンディング低減MT SIMD (25/15/15/15/0/0/1/0/off/off)
これで8bitがきれいに見えるならいいんじゃないか。そういう環境ならね・・・ おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・ デバンドするしないでも選択肢変わるだろうし
QP値どれだけ盛るかにもよるけど手軽にやりたいなら10bitのほうが楽っちゃ楽
8bitソースにデバンドも何もしないなら10bit使うだけほぼ無駄ってのはそのとおり なんでアニオタばかりなの？
グクってもみんなアニメかゲームのエンコの話ばかり
実写メインの人っていないの？
自分は実写メインで、地デジソースならデノイズかけてインタレ保持のcrf25ぐらいで5Mbps前後にしてる
SSIMが大体0.978ぐらいになるから糞ソースの地デジならあんまり変わらん気がする デノイズは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きったねぇわろたｗｗｗｗｗｗｗ
こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけｗｗｗｗｗｗｗｗｗｗｗｗ >>480
この違いがわからないなんてよっぽどひどいモニタ使ってるんだね >>495
「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。 >>494
デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方
というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする >>493
意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う 話がややこしくなってきたので改めて整理すると
>>466
に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない
んでもってその観点でいうならば、
>>474にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが >>494のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは（圧縮前の時点で）右上の絵画（？）の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ
そういう部分に目が行かず、
＞8bitきったねぇわろたｗｗｗｗｗｗｗ
＞こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
みたいに草生やしてるだけだからお前はめくらなんだよ 地デジはともかくブルーレイだと>>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の方が少ない
画質の評価は見た人に任せるよｗ >>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が効いてるからだと予想 別に絵画の精細度なんてどうでも良いんだがｗｗｗ
少なくともこのソースで明らかに目につくのはバンディングだしｗｗｗｗｗｗｗｗｗｗ
まじめくらやべぇわｗｗｗｗｗｗｗｗｗｗｗｗ ＿人人人人人人人人人＿
J( 'ｰ`)し ＞ 草刈り中のトラブル ＜
○=｛=｝〇, ￣Y^Y^ Y^Y ^Y^Y Y^Y^Y￣
|:::::::::＼, ', ´ﾁｭｲｰﾝ
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗ
彡 ⌒ ミ
(´・ω・｀) >>498
1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う
>>499
そうね
自分のエンコードの目的は「出力サイズを小さくする」ことだから
10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった
8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね＞大元は >>502を見るとどう考えても10bit＞8bitじゃんｗ
ファイルサイズ8bitの方が小さいならまだ分かるけど
大きくてこれとかイイとこなしｗ 静止画だから分かりづらいけど
動画で見たらさらに目立つからなバンディングは うーん、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主張する人で画像を上げた人が一人もいないんだよね
論より証拠なのに勘ぐってしまう バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ 別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ
無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で
色が変わってると考えるのが理論的思考として妥当でしょ >>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
まあファイルサイズ的には全く同じだし、これらのオプションはフラグを立てるだけでスクショの色が変わるだけで実験には影響ないと思う
実際そのオプションでもやってみたけど画質的には全く同じだし、ファイルサイズも完全に一致
まあ人に色がおかしいと疑いの目を向けた以上、こちらも正確性を期すために弁明を ■ このスレッドは過去ログ倉庫に格納されています
