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チャンネル) >>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる
> 3の方式にこだわる理由って何かあるの?
世の中一般的な人の手を煩わせないこと >>577
>世の中一般的な人の手を煩わせないこと
LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。 >>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね
拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの? あと
> ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。
これは違うと思う
再生時は8bitでも、グラデーションがきれいになるから
10bitでエンコしてるって人は多いと思うよ
別に統計調査したわけじゃないけども デバンド10bitがファイナルアンサーってことでおk?
めくらとめんどくさがりはデバンド無し8bitってことだよな? >>582
1人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・ >>579-580
> デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの?
暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。 >>579-580
>>574の後半は少し間違ってたかも。
1.以前はEVR/EVR-CPにP010を渡してもうまく動かなかった。
2.なので以前のLAVではEVR系にはP010ではなくNV12で渡すようにしていた。
3.Win10CUからEVR系にP010を渡しても大丈夫になったので、LAV 0.70.0からは、
Win10CU環境ではEVR系にもP010を渡すようになった。
4.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でも綺麗に見えたというのは釈然としないけど俺が何か勘違いしてるんだろか。 バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなw
折角低減されたバンディングが少し再発しててワロタw 最小限、VLCでまともに見れれば問題ないんじゃね?っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc >>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で再生してもバンディングは出ない MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな
madVRはH264のノイズがそのまま出てて汚い
少なくともPascal世代のGeForce積んでるマシンなら、
WindowsデフォのEVRが画質は安定してる印象
なんか俺間違えてる? >>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど >>589-592
> 何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない
サンプルがあった方がいいだろうと思って10bitのグラデーション動画(プログレッシブ)を作成して
検証してまとめてみたけど、どうだろうか。
10bitグラデーション映像の視聴時バンディング発生テスト
まとめテキスト: https://pastebin.com/PjXMXesZ
動画やスクショ等: https://www.axfc.net/u/3856752.zip
少なくともうちのIntelHD環境では、LAVでNV12にされたものをEVRで見ると、はっきりしたバンディングが発生する。
(madVRではディザリングでごまかしてそれなりに綺麗には見える)
もしこれがそちらの環境の「NV12→EVR」でバンディングが発生せず綺麗に見えるなら、
Pascalの映像補正処理によって、ごまかされて綺麗に見えているだけだと思う。
なんにせよ少なくともプログレッシブではP010で精細なデータをレンダラに渡す方が良いのは間違いないけど、
P010のインタレ解除対応とかについてはよくわからない。 >>593
おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね >>593
ところで8bitで再生って具体的にどうやるんだ?
プレイヤーとかデコーダにそんな細かな設定項目はないだろ? >>595
無知な上にスレチな話題を無駄に広げるんじゃねーよ >>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ソースを生かせる >>597
俺が元々言ってたのは
「8bitソースを8bitでエンコして8bitで再生」するより
「8bitソースを10bitでエンコして8bitで再生」した方がきれいになるって話
「8bit or 10bitソースを10bitでエンコして10bit再生」した方がきれいだってのは
そりゃそうだけど、そんな話してなかったし、
「10bit動画をいかに綺麗に再生するか」って話はここだとちょっとスレチかも エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める >>599
そちらの話をきっかけに10bit動画の再生検証とまとめをしてみただけなのであまり気にしないでくれ。
>>600
あー、たしかに>>597の書き方は誤解を生んでしまうかも。
そちらの指摘どおり、「10bitソース」とあるのは「10bitエンコされた動画」のことです。 >>601
うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう >>601
じゃあ、もう少し乗っかってみる
>>594で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた
環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ
LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ)
https://i.imgur.com/JUXbiHR.png
>>593とちょっと色の出方が違うけど、バンディングは同じようにも見える
LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ)
https://i.imgur.com/kL0gCho.png
>>593のmadVR-P010-ditherONと同じような表示になった
LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ)
https://i.imgur.com/BqmypsW.png
>>593のmadVR-NV12-ditherONと同じような表示になった Intelグラはディザリングしないんだね
うちのPascalだとレンダラで10bit→8bit変換するときはデフォでディザリングされるっぽい UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る) >>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1:GTX660→DVI接続→IPSパネル
モニタ2:4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える
GPUなのかモニタ原因なのか接続方法なのか…オモシロw 比較するなら何故接続方法とディスプレイを同じにしないのかなぁ
一円にもならない雑音でしかないぞ >>603
どうせ比較するならカラーバーにしてほしかった。
何故黒背景なんだ?違いがわかりにくすぎるわ。 >>603
うーん・・・うちでそれらの画像を>>593(うちのIntel環境の結果)と比べると以下のように全然違って見えるけど・・・。
1番目(NV12+EVR)
少しバンディングの出方が異なるが、「EVRCP-NV12」とほぼ同じくらい。
2番目(P010+EVR)
P010出力なのに、3つの中で画質が最も酷い。細めの汚れたバンディングがはっきり見える。
「madVR-P010-ditherOff」で生じているバンディングを更に悪化させたような感じ。
「EVRCP-P010」や「madVR-P010-ditherON」の方がはるかに綺麗。
3番目(NV12+EVR(10bitサーフェス))
「madVR-NV12-ditherON」と似てはいるが、ざわつきが酷く画質としては劣る。
バンディングがほぼ気にならないレベルになってるのは
10bitサーフェスをデスクトップ(8bitRGB)に統合する時に、もう一度ディザリングしているのかな?
結果的にバンディングが目立たなくなっているとはいえ、無駄な処理をしているとも言えるような。
うちはノートPCでモニタも6bit+FRCなTNというショボ環境だから、他の人の結果や意見も聞いてみたいところ。 >>603
2番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも?
>>604-605
> Intelグラはディザリングしないんだね
ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」(LAVがレンダラに渡しているデータ)と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。
>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー? まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。 スケーラー的には
カスタムEVRのほうが比較対象になりえるかと >>611
こちらは4Kブラビア(KJ-49X8300D)にAVアンプ(AVR-X2100W)経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う >>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ >>614
スケーラーってなんぞ?madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな?
>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・?
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060+そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。 >>617
> EVR-CPのP010処理が何か変
おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた
>>593の画像
https://i.imgur.com/xPCZlun.jpg
>>603の画像
https://i.imgur.com/A5KuEHh.jpg 一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる
ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない >>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず
だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも >>618-619
申し訳ない。こちらがボケてました。
> 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。
もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。
>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。 >>621
プルダウンで簡単に使えるのが利点っちゃ利点>EVRカスタム サンプルは>>516が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな?
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの? >>623
ありがとうございます。参考にさせてもらいます。
>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。 >>626
基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉 MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか? no-info パラメータって x264 にはないんだっけ? >>630
あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう エンコード日とかって
muxし直したら新しく書き換えられるから
x264とはまた別じゃないかな? >>632が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。 わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな 違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。 ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。 >>635
デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね? あとはme dia にしてるのをバレたくないとかw >>639
それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎 >>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。
>>642
「(ファイラーで)作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。 >>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか? >>645
両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか? スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば?
それでもコア数多い7920Xの方が速いだろうけど threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。
Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。 4〜8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた 良いプラグインを選んだり自分で最適化ビルドして
うまいことavsを書けばコア数の多さを
純粋に速度upに繋げることはできる x264のソースで、
参照しているマクロブロックについて
書かれているところが分かる人いないかな? CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね
intel vtune買えるほど、こずかいあったら解析してみたいなー メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか >>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな >>661
Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか? x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる?
公式より、ちょこっと高速かも。 最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。 x264をvtuneで解析する方法
./configure ―extra-cflags=“-g3 -gdwarf-2” 下手に触ったら、弄りすぎて壊れた…
x264の内部
関数内の処理時間順
ttp://iup.2ch-library.com/i/i1868333-1510835655.png
呼び出し回数順
ttp://iup.2ch-library.com/i/i1868332-1510835582.png Intel C compilerで作った x264@0.152.2851
https://dotup.org/uploda/dotup.org1391216.zip.html
ソースは、弄ってないバージョン
バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。
自分でビルドしたい人は、msysのlinkerをmvしたりしないと通らないから要注意 >>667
その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。 俺のjane styleではちゃんと表示できてるぞ
むしろimgurのがdat入れたりせにゃあかん 今、ブラウザでアクセスしたけどリンク切れだったよ
専ブラのキャッシュに残ってるのでは? 結局janeのビューアが改善すればいいだけの話か。
susieプラグインとか2004年頃から更新されてないもんな・・・ r2345
誰か持って無いですか?VLCのはx264guiExに怒られるし
kmodはアーカイブ辿ってもないし >>673
怒られるっつっても
指定されたx264.exeはmp4出力に対応していません。
出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。
muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの?
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。 自ビルドすればいい
たいして、手間はかからないだろ
何をしたいのか理解できないけど ■ このスレッドは過去ログ倉庫に格納されています