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チャンネル)
0607名無しさん@編集中 (オイコラミネオ MMab-7n1W)2017/10/26(木) 11:37:44.52ID:Lqu4m2pKM
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る)
0608名無しさん@編集中 (ワッチョイ 9390-w9fV)2017/10/26(木) 12:05:51.59ID:koiMQ39k0
>>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1:GTX660→DVI接続→IPSパネル
モニタ2:4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える

GPUなのかモニタ原因なのか接続方法なのか…オモシロw
0611名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:37:30.49ID:bZqhxTl+0
>>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というショボ環境だから、他の人の結果や意見も聞いてみたいところ。
0612名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:45:49.30ID:bZqhxTl+0
>>603
2番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも?

>>604-605
> Intelグラはディザリングしないんだね

ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」(LAVがレンダラに渡しているデータ)と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。

>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー?
0613名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:58:50.33ID:bZqhxTl+0
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。
0615名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 22:29:15.67ID:ly9F1jYY0
>>611
こちらは4Kブラビア(KJ-49X8300D)にAVアンプ(AVR-X2100W)経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
0616名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 23:26:47.90ID:ly9F1jYY0
>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ
0617名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/27(金) 00:05:48.90ID:lbq/6KPv0
>>614
スケーラーってなんぞ?madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな?

>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・?
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060+そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。
0619名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/27(金) 01:02:44.22ID:XMw2Db120
一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる

ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない
0620名無しさん@編集中 (ワッチョイ 9111-Akqv)2017/10/27(金) 09:54:55.94ID:s36iLAYK0
>>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず

だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも
0621名無しさん@編集中 (ワッチョイ 13ec-DRuk)2017/10/27(金) 21:30:55.30ID:ZmaiasnV0
>>618-619
申し訳ない。こちらがボケてました。
 > 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。

もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。

>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。
0626名無しさん@編集中 (オイコラミネオ MMab-PCft)2017/10/28(土) 16:07:06.26ID:aZTaLCEhM
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな?
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの?
0627名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/28(土) 22:29:00.96ID:hchLrIBF0
>>623
ありがとうございます。参考にさせてもらいます。

>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。
0639名無しさん@編集中 (ワッチョイ 1334-aAnL)2017/10/30(月) 20:41:33.46ID:cDns2kcE0
ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。
0643名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/31(火) 14:36:40.95ID:41mjP/K80
>>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。

>>642
「(ファイラーで)作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。
0644名無しさん@編集中 (ワッチョイ 13d2-kgpv)2017/10/31(火) 18:31:40.36ID:IvmGk3l40
>>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ
0648名無しさん@編集中 (ワッチョイWW e15c-YD3/)2017/11/06(月) 12:20:23.32ID:nWEh0PuI0
オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?
0649名無しさん@編集中 (スッップ Sd62-2eRG)2017/11/06(月) 12:45:07.90ID:PJNEo3fvd
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば?
それでもコア数多い7920Xの方が速いだろうけど
0650名無しさん@編集中 (ワッチョイ 2260-apvC)2017/11/06(月) 13:05:09.71ID:AhYKSv2j0
threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。

Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。
0658名無しさん@編集中 (アークセー Sx33-WtbZ)2017/11/09(木) 03:55:05.26ID:2lLHGB5mx
x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか
0661名無しさん@編集中 (ワッチョイ 7feb-lB0v)2017/11/09(木) 23:26:26.85ID:8skGIZpd0
>>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな
0665名無しさん@編集中 (ワッチョイ 5fc6-Ud84)2017/11/14(火) 23:54:34.74ID:OmCERatJ0
最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。
0667名無しさん@編集中 (ワッチョイ 419f-CT75)2017/11/16(木) 21:39:08.85ID:Lok3SOLr0
下手に触ったら、弄りすぎて壊れた…

x264の内部

関数内の処理時間順
ttp://iup.2ch-library.com/i/i1868333-1510835655.png
呼び出し回数順
ttp://iup.2ch-library.com/i/i1868332-1510835582.png
0668名無しさん@編集中 (ワッチョイ 419f-CT75)2017/11/18(土) 15:36:47.29ID:mg/31u3f0
Intel C compilerで作った x264@0.152.2851
https://dotup.org/uploda/dotup.org1391216.zip.html
ソースは、弄ってないバージョン

バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。


自分でビルドしたい人は、msysのlinkerをmvしたりしないと通らないから要注意
0674名無しさん@編集中 (ワッチョイ a3ec-615/)2017/12/23(土) 21:21:11.03ID:VSoAQ8Gh0
>>673
怒られるっつっても
  指定されたx264.exeはmp4出力に対応していません。
  出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
  mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。

muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの?
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。
0678名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 00:12:41.45ID:3pbDkQUJ0XMAS
基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
でないともれなくウザいジャンクマルウェアがブラウザをフリーズさせようとするからw
0679名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 00:40:15.29ID:3pbDkQUJ0XMAS
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でのみ使用され、その利得は非常に小さい。
0680名無しさん@編集中 (中止 73b5-buzn)2017/12/25(月) 12:34:34.96ID:64mfmyLL0XMAS
ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
買い換えるという選択肢がないかもしれないけどRyzenはマジで優秀だからな
それなりにエンコする機会があるなら買って損はないと思う
性能がそこそこ優秀な割に異常に安価な1500Xあたりで組めばそれなりの価格で収まるし電気代も優しい
0683名無しさん@編集中 (中止 Sx87-/Td7)2017/12/25(月) 18:01:10.84ID:leIDQpx9xXMAS
>>680
ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい
0684名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 19:28:13.40ID:3pbDkQUJ0XMAS
余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
APUはVCEでハードエンコできるからまだいいが、FXは限界までOCしてゴリ押しするしか無いんだよな。
0691名無しさん@編集中 (ワッチョイ ffb5-Auke)2017/12/28(木) 02:17:54.51ID:gCKZ0KCj0
電熱による暖房は効率が悪いからな
電気暖房で効率重視なら現状ヒートポンプ一択
とはいえコスト度外視ならハイエンドPCを2台もフル回転させれば多分ちょっとしたセラミックヒーターくらいの発熱はあるはず
ただ熱を垂れ流すしか能がないヒーターよりは何らかの仕事をさせられる分だけ建設的なのかも知れん
0693名無しさん@編集中 (ワッチョイ cbec-O50F)2017/12/28(木) 13:39:09.46ID:afSjZm/R0
なんとなくr2893メモ

・8bitと10bitのバイナリを統合
 →1つのバイナリで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統合対応が地味に面倒そうではある。
0696名無しさん@編集中 (ワッチョイ f316-Auke)2017/12/28(木) 15:30:50.89ID:7aUzwO6o0
自分の好きなようにしたらエエ。
俺は PC で再生するだけだから 10bit 派。
そのくせ BlueskyFRC を挟んでFluid Motion してるから余り意味が無いという。
0700名無しさん@編集中 (ワッチョイ 67fa-MiNv)2017/12/31(日) 11:38:00.81ID:90rtTOjH0
誰でも自分PCで稼げる方法など
参考までに、
⇒ 『政道のゴウイウセレイイ』 というHPで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

A6L4JIAVLJ
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況