x264 rev32

Q ニコニコ・zoome用の動画を作りたい。
A 板違い、Youtube板の"FLV/MP4作成スレ"でどぞ。

Q 圧縮codecありませんか。AviUtlで使いたい。x264gui.auoの使い方は？
A x264 VFW GUI専用スレでどうぞ。
http://hibari.2ch.net/test/read.cgi/avi/1293421982/

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://hibari.2ch.net/test/read.cgi/avi/1292516529/


[本家]
http://www.videolan.org/x264.html
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)
http://doom10.org/index.php (公式フォーラム)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

[バイナリ]
Getting the latest x264
http://doom10.org/index.php?topic=3.0

前スレ
x264 rev31
http://hibari.2ch.net/test/read.cgi/avi/1301923510/

H.264の再生法や規格などの話題は
MPEG-4 AVC/H.264 総合スレ Part8
http://hibari.2ch.net/test/read.cgi/avi/1263983676/

AviSynthの使い方等は
Avisynthを絶讃ιょぅょ Part30
http://hibari.2ch.net/test/read.cgi/avi/1298742587/

インタレ規格の話題は
インタレ解除しないスレの3っぽいスレ
http://hibari.2ch.net/test/read.cgi/avi/1186448899/

リサイズやアス比の話題は
アスペクト比 part6
http://hibari.2ch.net/test/read.cgi/avi/1301521076/

MP4コンテナの話題は
【MP4】ISOMPEG-4普及委員会4【M4A】【3GP】
http://hibari.2ch.net/test/read.cgi/avi/1087545021/

Matroskaの話題は
【mkv】MatroskaVideo総合スレ8【mka】
http://hibari.2ch.net/test/read.cgi/avi/1237123715/

PS3の話題は
【H.264】 PS3動画スレッド8 【1080p】
http://hibari.2ch.net/test/read.cgi/avi/1263892716/

イチモツ

おお…　生tsが一番高画質と思ってるのがいるのか

はい

よしよし

俺の構成が1番高画質にエンコ出来る
フェニックス１号

CPU:AthlonXP 1400+(25w版)
M/B:A7V266
MEM:512MB
HDD:60GB
VGA:自慰Force2MX400
SOUND:SB Live!

次は、4:4:4とAQらしいね
ffmpegに4:4:4が入ったみたいだから、次が来るのは早いかも

4:4:4とか人間の認識レベル超えるから余剰だろ
色解像度は良くなるから赤系の滲みは減るけど

現状は赤の壊れが怖いもんな
そこが改善されるなら一定の価値と需要はあるだろう

RGBがソースの場合に、4:4:4が必要になる。

YUV4:4:4って色空間が広いだけでRGB4:4:4と1:1対応しないぜ
色の数自体はYUV4:2:0と一緒だし
色解像度があがるだけ

ばんでんぐはかいぜんしますか？

>>12
これで何とかなるのでは。
http://wiki.multimedia.cx/index.php?title=YCoCg

>>14
ならないよ
YUVにある色でRGBにない色があり
RGBにある色でYUVにない色があるから
YUV→RGB→YUVと変換すると色が変わる

>>13
改善しない。

>>15
すまない。YCbCrを絡めた話だったか。

x264で、RGBをそのままにしておける様になるのは確かだが。

4:4:4 + 10bitなら、RGBもほぼ無劣化

こんな規格流行るの？

流行るか流行らないかで言えば、放送波や円盤メディアに採用でもされない限り流行らない
でも実装する事自体に意義があると感じてる開発者は居るんじゃないの

元がRGBの東方のプレイ動画を、x264を使って最高の品質で保存できると言うのは、
DSにとってはとても重要だろう。

東方がデモ取れるようにすればいいんじゃないかと

そもそもSTGのプレイ動画なんてフレームレートと解像度が保持されてれば420と444程度の色の差なんかどうでも良いはずだけどなパターン解析が最重要な訳だし

444→420だと赤弾と中弾の外側に円の書かれた類の弾が酷く潰れるが422→420だと潰れないからそれで困ってるなら試してみろ

東方（）

444に対応することでどの程度ファイルサイズが増えるんだろ？
というか、
444の再生環境ってどのソフト使うといいのかよくわからん。

444対応も良いんだけど
新しいAQでエッジにAQを使わないようにするってのが気になるな
かなり苦戦してるみたいだけど
これが入ったら、アニメエンコは相当楽になるはず

それaq2でやって微妙に失敗しただろ

aq2ってフレーム間でビットを融通するんじゃないのか

constrained-variance AQって言うらしい

おおぉ
http://hibari.2ch.net/test/read.cgi/avi/1296362211/922

Libav見るとD_S氏は444のデコードでfix入れてるから
x264の444って完成してるんじゃないだろうか
なんでリリースしない？

>>30

仕方ない。
自分が正義だと思ってる奴を説得するのはどうやっても無理。

同じDTVだしネタ分かると思っていったんじゃないの叩かれまくってるけど

ここでもネタだと思ってる奴いないぞ、一部の馬鹿がかたくなに
なってるだけで殆どの奴はうざいと思ってるだろ

元よりここにはエンコする人しかいない

生 TSで残して必要になった時エンコするのが1番だとは思うけどね
地デジがm2tsじゃ無かったらエンコする人はもっと少なかったと思う

x264の後継だってそのうちに出るかもしれんし
TSしかないものなら残したほうがいい気はするね

勿論残すこともあるが別に綺麗だからという理由で残してるわけじゃないし
関係ないな

おお…

まい…

がっ…

オーマイゴッドって実は外人使わないんだぜ、もはや不適切な表現
みたいな感覚になってるからなるべくその言い回しは避けるんだぜ
ソースはどっかのブログ

じいざすくらいすと…

ソースはWikipedia並に信用ならないなｗ

おお…　生tsが一番高画質と思ってるのがいるのか

まい…　スパゲティはまずい

陰茎洗って出直してこい

陰茎だけじゃダメよ…
ここもこうやって洗うの

おお…

おお↑

生が一番気持ちいいと思ってるのがいるのか

お前はこんにゃくでも使ってろよ

嫌だ。バナナの皮がいい。

meとtrellisに手が入るのか

ほ〜

>>42
俺実際に使っているのを聞いたことあるけどなー。
いつ頃からそういう流れなの?

>>42
ネトゲやってると、外人は omg!! を連発するんだがｗ

廃人基準でものを語るか…

おーまいぐっどねすだよゴッド使う奴は池沼か狂信者

>>58
俺は実際に聞いたよ。
絶叫マシンに乗ったりすると言わね?
ずいぶん前の話だから今は言わないかもしれないが。

911事件の映像に映ってた野次馬は全員連呼してたよ

前に女性がナイアガラの滝から落ちて亡くなったが、
その流れていく様子をようつべでうｐされてて撮影した人が最後にオーマイゴットって普通に言ってるぞ。

http://www.youtube.com/watch?v=Pg_hLn194ys&feature=player_embedded
一応動画な。

いつまで釣られてるんだろう・・・

O・M・G O・M・G !

HBRN！

>>65
SHINE！

OreAQ MixAQ GoodAQ

そこはGodAQで

神のアンサー・クエッション

asusから6万くらいで10bit表示可能なIPS液晶出てるんだね
ffdshow早く対応して欲しい
10ビットエンコ試してみたい

今使ってるCG303Wでも10Bit対応はしてるようだ
あまり興味はないが

グラボも対応してないとね

このモニタ買う時はFireProもセットで買う

10bit再生のおすすめ環境って何かあるのだろうか？

>>73
FireProって動画再生だけの場合でもメリットあるの？

>>74
Radeonとかは10bit出力できないぞ

>>74
そうなんだ。
とすると、FireProと10bit入力対応モニターと、あとは10bit再生対応ソフトが必要なわけか。
10bit再生できるソフトって現状どんなソフトがあるんだろ？

アンカー間違えました。
>>75さん宛てです。

MPC-HCとか

MPC-HCだけでいいの？
何かと組み合わせないといけないとか、そういうことはないの？

MPC-HCって10bit対応してるの？
何か方法があるのかもしれないけど分からん。
自分は下のところのhigh-bit-depthの使ってるけどMPC-HCで対応できるならそっちがいいな。
http://mplayer2.srsfckn.biz/

MPC-HCの中身はLibavだから、10bitデコーダー標準装備

MPC-HCの中身は分裂のちょっと前から、ずっと更新されてないぞ
最近casimir666がブランチ作って色々やってるが、trunkにmergeできるレベルには
まだなってないみたいだし

そしてその最新ffmpegを入れるブランチの方も-tryoutsのパッチも入り始めてる
からFFDShow-tryoutsの9,10bitを無効にする仕様も入ってくる可能性が高い。

DirectShow系はFFDShowのおかげで色々遅れてるでござるの巻。

mplayer(2)に続いてようやくVLCもhigh bit depthの対応は完成させたみたい。
最新のナイトリーでは再生できてる。

( ﾟдﾟ)ﾊｯ!

エンコって何のためにしてんだろ

愛だ

こんなに苦しいのなら悲しいのなら……愛などいらぬ

ゲームするでもないベンチ動かすわけでもない我が無駄スペックPCの暇つぶし

最近はエンコするために録画するという状況になっている節がある

エンコが楽しくてPC組んだ
何年経っても新しい発見があって楽しいよ

おお…

ブレネリ…

あなたの…

アスホール…

ここにもアナニー愛好家が隠れてたか…

愛ゆえに、人は苦しまねばならぬ！
愛ゆえに、人は悲しまねばならぬ！

エンコゆえに、人は苦しまねばならぬ！
エンコゆえに、人は悲しまねばならぬ！

H.265/HEVC

エンコードやって綺麗に出力できてるおれすげぇえｗｗｗｗｗｗｗ
やっぱおれはほかのやつと”能力”が違うんだなｗｗｗ
選ばれた者、そう絶対的な存在！
って脳内で酔ってるけど、それだけでもエンコに価値はある

よくみたらつるぺただった

つるぺたは正義

ぺったんぺったんつるぺったん

エンコ好きとロリコン好きは相関関係あるから、
ツルペタは正義だろ。

ロリコン好きって変態の上をいく変態じゃね

>>102は熟女のお方かもしれない

俺油絵の才能あるかもしれん

なんだよ、やぶから棒に

>>106
エンコが上手くいかないってことだよ
言わせんな恥ずかしい

x264のパラメータはあくまでおまけ。
ちゃんと組み合わせて作りこむ必要があるのはavsフィルタの方だろjk
才能以前の問題だろ

UTL最高や！64bitやいらんかったんや！

>>108
誰も貴方にマジレスは求めてません

おお…

>>91

確かにつるぺたの方が綺麗に圧縮できるかも。

つるぺたでもいいけどそれに慣れると自分でエンコしたものしか見られなくなるのが問題

ｒ2019

とうとう、RGBサポートがきたな。

でも使い道ほとんどなくね？ｗ
ほとんどのプレイヤーでデコードできないｗ

libavcodecは、もう対応しているそうだから、そのうちffdshow等で再生可能になるだろう。


DSも暇だったら、これみたいなRGBのデモをやってくれないかな。
http://mirror05.x264.nl/Dark/x264vsElecard/

>>117
PC限定ならRGBの方が良くないか。

>>119
でもソースがYUVばっかりだぜ
自作ＣＧアニメとかならいいけど

もっぱらゲームキャプ用になるんじゃない？

とD_S氏も言っているもんなー>ゲーム

4K2Kとかを民生レベルで扱う時代になったら、色差？なにそれ？うまいの？
みたいな状態になるんかねぇ

昔の8ビットカラーのゲームを見ると涙ぐましい（せせこましい）努力してたんだなって思う
そんな感じになる

圧縮率そのものは落ちるのかね？

そりゃ、4:4:4 -> 4:2:0とCbCrを間引いた場合よりは、落ちるのではないか。

4:4:4は、4:2:0と比べてデコードの負荷も40%増えたと言うことだし、
遅いCPUではリアルタイムのデコードができないと言うこともあるだろうね。

赤や黒の破綻や肌ののっぺりは改善されるのか？

>>127
RGBがソースなら改善する。デジタルTVやDVD/BD等、元から4:2:0のソースは改善しない。

改善はするんじゃねぇの？
赤とかのノッペリってx264が圧縮時に色を間引く処理がヘタクソだから
ソースよりノッペリして見えるという話なんだから、色の間引き処理をしない
RGB処理ならばソースと同等程度には保てるようになるんじゃないの？

>>129
>>128

>>130
いやだから…
俺が言いたいのは、もとのソースよりきれいになるという意味で言ってるんじゃなくて、
ソースをx264でエンコするときに4:2:0でやるより、4:4:4やRGBでやったほうが
ソースと比べたときに劣化が少なくて済むだろって意味なんだが。
何か勘違いしていないか？

4:2:0のままでも、--qp 0で完全な品質を実現できる訳だしそれはどうだろう。

いずれにせよ、劣化を伴う4:2:0 -> 4:4:4はやらない方が良いと思う。

>>131
>>128

>>132
なぜ420->444が劣化を従うと決めつけてるんだ？
そもそも一般的な再生環境はレンダラやフィルタが420->444を当たり前のように行なってるが、
これなしでは再生時の品質はジャギりまくりで見れたもんじゃないことすらわかってないわけ？

>>134
再生時に4:2:0 -> RGBをレンダラーがやってくれるのだから、エンコードは4:2:0のままで良いと言っているだけ。

その説明はおかしいだろ？
もともと圧縮されてるソースを再度エンコードするときには嫌でも
いったんベースバンド信号に戻さないといけないのだから。
4:2:0のソースを再度4:2:0でエンコードしようとすれば、当然エンコード作業の
過程で再度、色の間引きが行われるのだし。
この色の間引きが間引きすぎてるから実写などで特に違和感を感じたりするわけで。

いつもの事だがどっちでも個人で好きにすれば良いんじゃないの？
自分はTSエンコする分には無いデータが復活するわけでも無いし
どの道再圧縮処理する訳だし、再生互換性や圧縮率の関連もあるから4:2:0使うけど

間引き気になるなら4:2:0の--qp 0でいいでしょ
なぜエンコード時にRGBにしたいのかよくわからない

qp0にしたって4:2:0でやる以上逃れられんよ

間引きってなんだよ
サブサンプリングなのか量子化誤差なのかはっきりしろよ

何が言いたいのか良く分からんが
mp3で例えるとバッサリ切られた周波数成分が
wave通したら復活する的な考えか？

結論 エンコは悪 カワイイは正義

>>139
可逆圧縮なんだが

>>143
そういう問題じゃないでしょ…
意味わかってないでしょ？

>>144
qp0で劣化するってんなら
ｘ264じゃなくおまいさんの使ってるフロントエンドやデコーダの問題

>>144
ソースと比べたときに劣化が少ないって条件出したのは自分でしょ
だったら非可逆のRGBより可逆の4:2:0　qp0のが無劣化なんだぞ
↓はqp0のとき成立しない

”4:2:0のソースを再度4:2:0でエンコードしようとすれば、当然エンコード作業の
過程で再度、色の間引きが行われるのだし。”

>>144
（「間引き」の）意味わかってないでしょ？

何か平行線を辿ってる感が半端無いんですけど

お前がそう思うんなら(ry、ってことでつまらない言い争いはいい加減にしません？

双方の前提が違うから意志の齟齬が出来ているんだな
ソースが4:2:0ならqp=0で4:2:0の可逆で出力されるから問題ない
ソースがそれ以外だったり途中で変換が入るならその限りではない

x264で4:2:0のソースを処理すると赤が潰れるから、
先に4:2:0から4:4:4に変換してx264に渡せば同程度のファイルサイズでも色が良いかもしれない？
って話じゃないの。qp0で良いならそもそもエンコードしないだろ。

>4:2:0のソースを再度4:2:0でエンコードしようとすれば、当然エンコード作業の
>過程で再度、色の間引きが行われるのだし。
Avisynthで420を420のままエンコードするなら色の間引きなんて起きないわけですが
一体どこが「当然」なんでしょう

なぜイチイチID変えて書き込んでるの？
そんなに自分の意見に自信がないの？

>>150
>x264で4:2:0のソースを処理すると赤が潰れるから、
は？

>>145
qp0で劣化するなんて書いてませんが？
ここでqp0(可逆)の話持ち出してどうすんの？って意味なんだが。
だいたいqp0なんて使わないでしょ、普通。

>>146
>>145と同じになるけど、そもそも可逆なんてほとんど使わない特殊条件の話しても仕方ないでしょ。

なんで >>140 に答えないんだ？
「間引き」の定義もせずに「わかってる」「わかってない」の議論は意味が無い

>>150
たったそれだけの話なのに、なんでこういう展開になったんだろうね？

>>151
Synthは使ったことないから知らない。
でも可逆じゃない限りもとのままってことはないんじゃないの？
Synthのほうでも。

まったく同じことを言いたい
4:2:0ソースをRGBにエンコードするのが特殊条件だと思わない？
同CRFで容量倍近くまでいくわけだが
容量抑えようとすると赤潰れになるのは同じこと
実際には赤が潰れるんじゃなくて人間の目が赤に敏感なだけ

>>157
容量が２倍程度で色の違和感が消えるなら別に構わないと思うけどね。
可逆に比べたら容量はコンパクトに済んでるわけだし。

>>156
>たったそれだけの話なのに、なんでこういう展開になったんだろうね？
じゃあ答えるよ

>x264で4:2:0のソースを処理すると赤が潰れるから、
x264は関係ありません
>先に4:2:0から4:4:4に変換してx264に渡せば同程度のファイルサイズでも色が良いかもしれない？
x264は関係ありません

これで満足か？

>>157
＞同CRFで容量倍近くまでいくわけだが
そんなに違うのか。気が向いたら試してみるよ。

とりあえず、Avisynthはフィルタであってエンコーダじゃねえ。

そもそも誤解してるような気がするんだが、4:2:0だと赤が潰れるのはx264が悪いんじゃなくて
4:2:0っていう色空間そのものにあるってこと
で、4:2:0っていう色空間は4:4:4やRGBよりも色差の情報を間引くことによって、
人間の目に気付きにくい情報を減らして圧縮率を高めるために利用されてるってこと

基本的な知識が足りてないように思える

>>159
x264が関係ないならいったいどこが関係するというの?
代わりの改善方法は何かあるの？

>>162
420のソースをUtVideoなどの可逆圧縮でエンコードしておきゃいいだけだろ
それをAvisynthで読み込めば間引きなんて起きねーよ
おまえが言ってる間引きはAviutlがやってることでx264は関係ない

>>154
>>139
＞qp0にしたって4:2:0でやる以上逃れられんよ

>>163
もっと詳しく。
というかaviutlが何か悪さでもしているの？

>>164
いままでずっと探してたの？
ごくろうさん

>>165
入力にYUY2を必要とするAviUtlでは、4:2:0 -> 4:2:2とした結果、これの右の様になる。

http://img703.imageshack.us/img703/9699/mpeg2decode.png

つまり>>145って事

>>166
残念ながらおまいさんに付きっ切りじゃないからな

>>167
ほぅ…
これっていうのはaviutlの変換方式がマズイだけなの？
それとも変換すると避けられない問題とか？
Panaとかのレコーダーの機能でこういう変換をうまくやる機能があったように
思うのだけど(名前忘れちゃった)

>>169
AviSynthを使えば、YV12として4:2:0をそのままで処理できるのだから、そんなに色差の品質が気になるのならば、
4:2:0のソースに関しては、AviUtlをあきらめるべき。

>>169
いい加減スレ違いだググレ粕以下の屑

>>170
つまりSynthならばソースが4:2:0の場合、それ以上色の劣化は起きないってことなのかな。
これは少し調べて見た方が良さそうだ。

>>171
俺は途中参加なんだけど、確かにスレ違いだね。
ｽﾏﾝｽﾏﾝ

何このぐだぐだ・・・

>>173
はじめから勘違いを認めて冷静に話し合えって見本だな

途中参加もなにも本来なら>>128で終わってるはずの話題を
知識不足のお前が蒸し返したのが原因だろ

>>167
AviutlはどのようにしてYUY2にしているのか？
YUY2とYV12では何が違うのか？

ここら辺わかってないんじゃない

だろうね

>>167
それはソースの読み込ませ方の問題でAviUtlは関係ないだろ

>>178
何か良い方法があるのなら、ID:x1uY7YQv に教えてやってくれ。

AviUtlでAviSynth用ロゴ作る時と同じで二重補間切れで終わり

ただその使い方するならAviUtlは遅いだけでメリットが全くないから
AviSynth使えよで終わる話
そもそも基本的な知識が欠けてる
ここは初心者スレじゃないんだから不適切

それで
420→444
420→422→444(aviutl)
は最終出力が420の場合に比べて綺麗になることはないって事でいいの

綺麗、って言葉を使うとまたややこしくなるぞ
ソースより俺が各種フィルタ処理した物の方が綺麗に決まってる(ｷﾘｯ　みたいな

こういう流れを断ち切るためにおお…があるんじゃないのか

おお…

4月期と違って切るアニメ少ないから大変だなｗｗｗ

クロマアップサンプリング処理が優秀なハードウェアから444で出力して444でキャプって保存することができる場合、
PCのそこそこのクロマ処理を通して再生するよりはいい結果が得られるのではないだろうか。

>>186
それなりのGPUを持っているなら、16bit/sampleのmadVRを使って出力した方が良さそう。

>>186
16bit出力？
なにそれ？

>>188
madVR - high quality video renderer (GPU assisted)
http://forum.doom9.org/showthread.php?t=146228

>>189
これはGeforce使ってる人が8bit制限を突破したいとき用じゃないの？

そこの説明にあるとおり、クロマアップサンプリングやスケーリングを16bitでやっておいて、
ディザも足した上でRGBに変換するから、他よりも良いと言うこと。

>>191
中間処理は16bitでして、最終的には8bitに丸め込んでモニター出力というわけか。
では、丸め込んだ8bitRGBをいったんキャプチャしてRGBでx264保存しておけば、保存したファイルを再生するときは
いつでもmadVRがない環境でもきれいに再生できるのかな。

つまり最初っからRGBでいいんじゃないかって言う…
モニタの画素は結局どうやってもRGBだろうしな

でもフィルタとか画像処理ではYUVも便利だよね！

>>192
多分、--qp 0以外では、ディザが崩れるんじゃないか。

あげちゃっちごめん…

>>194
やっぱり崩れるのかな。
だったらmadVRの出力を10bitとか、もっと高いビットで出力して、10bitでエンコードすれば8bit程度の情報は残るとか無理か？
音楽なんかでも24bitにアップサンプリングしてからAACとかに落としこむと、ニュアンスとか残りやすいらしいし。

これおお…の人だろ

BT.601→709を見て色が変とか言ってた人がいたっけな

我々人間はRGB変換された映像しか見ることができないのに
機械はYV12のまま処理できるってのが混乱を招くんだろうか

ところで、ここで議論してる人で以下の数字やノイズが見えない場合、
まずディスプレイを何とかしろってことになるの？

http://photo.sbcr.jp/sidenote.cr?owner=bd105d9e-a9b2-102a-879e-00114331ed99&sidenoteid=181
http://img3.uploadhouse.com/fileuploads/3477/3477383fd0a6ac46a85211fff3e2a537f2c3d7b.jpg

ググれば分かるのに、理解してないのにそのまま発言する人が多いね。
まともな指摘があっても、流れに埋もれちゃってわかりにくい。

まずYV12=YUV420が、何なのか。
ttp://www.cri-mw.co.jp/product/column/2nt4hm0000001lbn-img/2nt4hm0000001lgl.jpg
モノクロの情報(Y･･･輝度)に対して、カラー情報(U,V･･･色差)を1/4だけ持っているのがYV12。
こうすることによって、情報量を大幅に減らすことが出来る。
画像が大幅に劣化しそうな気がするが、人間の目の特性上、普通は気づく事は無い。
ttp://static.shoeisha.jp/cz/static/images/article/3750/01_s.jpg

1/4の解像度に縮小されてしまった画像を復元する手段は無いので、
エンコード時にYV12→YUV444への変換をするのは、無益。
逆に、元々がRGBなソースを圧縮する時には、YUV444を使うと色差も残せる。
ただし、人間の目が色差に鈍感なのは変わらないので、大抵の場合圧縮率の無駄になる。

ちなみにAviUtlにavsを読み込ませる場合は、avisynthでYUV422に変換しておかなければならない。
これはソフトの仕様上の問題で、フォーマットとは関係無い。

>>196
ディザが潰れるというのは、bit数とは関係が無い。
上手く説明するのは難しいけど、端的に言うと色深度と解像度の違い。
ブロックノイズとバンディングの関係に相当する事で、関係が無い。
結局、再生時に処理できないのであれば、10bitでエンコードするか
従来通りのバンディング対策をするしかない。

猫科さん翻訳はよ

>>167
AviUtl使ってる限りこの画像のような劣化は起きるのかい

もちろん起きない

ん
回避策できるのか

>>205
プログレッシブでやるYV12 -> YUY2は、インターレースでやるそれと比較すれば劣化の程度がましだから、
AviSynthでデインターレースやIVTCをやってから、AviUtlに渡すと言う手はあるな。

なるほど

インターレスって、ソースはmpeg2ファイルだろ？
それなら、MPEG-2 VIDEO VFAPI Plug-Inを入力プラグインとして
使うのが定番じゃないの？
Avisynth＋DGMPGDecよりも遥かに高速だよ

>>210
誰の定番かは知らないが、品質を最優先する人には不向きだと言う話。

あと、速度を優先するのなら、MPEG-2の入力にFFMS2やDGDecodeNVを使ったら、
DGDecodeやm2v.vfpよりも速くできる。

>>211
m2v.vfpとm2v.auiの違いは理解して書き込んでるんだよな？ｗ
色空間変換の仕方が両者で違うんだよ
レフトオリジンとかAviutl使う上での基礎知識も当然知ってるよな？

上で上がってる画像はm2v.vfpだし、お前が言ってるのもm2v.vfp。
俺が言ってるのはm2v.aui

速度に関しては下の記事参照
ttp://pop.4-bit.jp/?p=1660

同じものじゃないの
auiってリネームしただけじゃなかったっけ

リードミーに単なる"リネーム"したものだって書いてあるじゃないですか
>AviUtl 入力プラグインとして使用する場合、m2v.vfp を m2v.aui と
>リネームしてから AviUtl のプラグインフォルダにコピーしてください。

昨日から恥ずかしい人が多いですね

お前が恥ずかしすぎるんだよ

いや恥ずかしいのは俺一人で十分だ

http://www.tenchi.ne.jp/~yoko/aviutl/index.php?%A4%DE%A4%EB%A4%E2%C0%BD%BA%EE%BD%EA

俺より馬鹿な奴を捜しに旅に出る ｷﾘｯ

あ〜ぁお恥ずかしったらありゃしない

>>212
m2v.auiの高速化って、別にデコード自体が速くなったんじゃなくて、単に別スレッド割り当ててるだけでしょ？
それならAviSynthでもThreadRequest使えば同じようなこと出来るし

#trim_op.avs
#trim_op.tsはフレーム数6705
LoadPlugin("DGDecode.dll")
LoadPlugin("ThreadRequest.dll")
MPEG2Source("trim_op.ts", upconv=1).ThreadRequest()
Trim(0,0)

$ time /c/aviutl99i8/aviutl.exe /g/ts-bench/trim_op.ts -op /g/ts-bench/nullout.avi -q
real 1m35.830s
user 0m0.000s
sys 0m0.031s

$ time /c/aviutl99i8/aviutl.exe /g/ts-bench/trim_op.avs -op /g/ts-bench/nullout.avi -q
real 1m26.886s
user 0m0.015s
sys 0m0.015s

AviUｔｌやm2v.auiは良いソフトだけど、それしか知らないんじゃなぁ

ID:JyUF23ZXが消えた件

違うのか違わないのかどっちなんだろ
そこだけが気になる記事やレスだけじゃよくわかんね

おお…m2v.vfpとm2v.auiの違いは理解して書き込んでるんだよな？ｗ

きな…そろそろ該当ソフトスレでやってもらえませんかね

くりの…

ファイル名を判断して内部で動作が変わること知らないのかね？ｗ

恥ずかしげもなく堂々と間違ったことを偉そうに語ってくれる方々のおかげで
今日もまた1つ賢くなれた

226 が正しい。
m2v.vfp/aui は一つのバイナリで VFAPIとAviUtl 入力プラグイン APIに両対応している。
AviUtlは拡張子を見てどのAPIで読むか決めているだけ。

AviUtlしか使わない人には、これでm2v.vfpを読んで、YUY2で揃えた二つのクリップをStackHorizontalとした、
とまで書かないと分からないか。

http://www.avisynth.info/?LoadAviUtlInputPlugin

Readmeより
　AviUtl 入力プラグインとして使用する場合、m2v.vfp を m2v.aui と
　リネームしてから AviUtl のプラグインフォルダにコピーしてください。

　この機能は 2ch avisynth を絶賛ιょぅょPART5 448 さんから提供された
　コードによって実現されています。

で、avisynth を絶賛ιょぅょPART5 より
　MPEG-2 VIDEO VFAPI Plug-In に、Avisynth と AviUtl の
　呼び出し部分をくっつけただけなので同質です。

　ただRGBに変換される前のYUVの状態を出力しているので
　そういう意味では有利です。

流れを見て思ったけど、aviutl使い多いんだな
そっちのスレでまずは勉強してきた方がいいと思う

横やり失礼。x264が不得意とするのは暗部が潰れることだと思ってる。
崩れるのは暗部のY値だから色空間関係なくね？
暗部のY値がノッペリ化やブロック化から改善できるなら教えてください。

>>232
それは、10-bit版のx264を使えば改善できる。

マジで？10bit版を使うとどうして暗部が改善されるかわからん。。
時間があるときに環境作って試してみよう。

金もある時じゃないとな

10bit版使ったからといって暗部やバンディングが低減するわけではないですよ

正直私も改善できるかは疑問に思ってるがそれはそれ。
使っている人少ないから試してみないと。

GradFun2DBmodとAQや--psy-rdで対応しているが駄目なシーンも残っているのが私の現状です。
--zonesで盛るのもやだしなぁ。

10-bit版の方が、8-bit版よりもディザを保持しやすくなるのは間違いない。

http://forum.doom9.org/showpost.php?p=1415099&postcount=10

m2v.vfp/aui の違い理解してない雑魚だらけでワラタｗ

m2v.vfpはVFAPIプラグインとして機能する。
VFAPIはRGBだから、Mpeg2ファイル(YUY2)をRGB変換して読み込むわけ。
そしてそれが更にAviutlの内部色空間であるYUV444に変換される。

リネームしてm2v.auiにして、入力プラグインとして使うと、
VFAPIとしては扱われずに、YUY2のままAviutlに渡され、
Aviutlの内部色空間YUV444に変換される
色空間変換が1ステップ省かれるんだよ

使ってないからそりゃ知らないわなあ
雑魚とか言われても困る

雑魚とか言うくらいなら、AviUtlの内部色空間がYC48なのくらい間違えないで欲しいよな

もうその話は終わってんだよ

>Aviutlの内部色空間であるYUV444
アホすぎ
失せろ

>>243
え？ YC48 は YUV 4:4:4 であってんじゃないの？

YC48はYUV444のY16〜235を0〜4096、UVの16〜240を-2048〜2048に伸長したもので全くの別物
いい加減スレチだし大した正確な知識も無いなら黙ってろ

そろそろスレチー

>>239
>Mpeg2ファイル(YUY2)をRGB変換して読み込む
mpeg2は殆どの場合YUV420ね
422のmpeg2なんてMatroxの中間出力用とかしかないから

>>245
YC48は4:2:2ですが・・・

いちおうAviUtl雑談スレ貼っておきますね
http://hibari.2ch.net/test/read.cgi/avi/1308579804/l50

>>249
YC48はbit深度は特殊だが444だぞ
そうでなけりゃRGBを無劣化で扱えないだろが

間違えた
>>429じゃなくて>>428

>>248
いやいや、4:4:4だろ
YUY2フィルタモードについては扱ったこと無いから分からないけど、一応趣味でAviUtlのフィルタプラグイン
作ったりしてるから、AviUtlの内部色空間についてはそれなりに正確に把握してるつもりなのだが

YUV(正確にはYCbCrか)の情報にそれぞれ2バイトずつ割り当てて、
1ピクセルあたり48bitの情報量だからYC"48"なんじゃないの

スレチ承知だが噛み付かれたものでつい

444とか422とかに色深度は無関係ってのが分かってないのかな？

YUV444なら
「輝度4ピクセルに対して、色差Cb（Cｒ）4ピクセルづつとる」
この中にAviUtlの内部色空間とかが含まれる

YUY422なら
「輝度4ピクセルに対して、色差Cb（Cｒ）2ピクセルづつとる」
この中にYUY2、UYVYとかが含まれる

YUV420なら
「輝度4ピクセルに対して、色差Cb（Cｒ）2ピクセルづつとる
　その一段下のピクセルについては
　　輝度4ピクセルに対して、色差Cb（Cｒ）0ピクセルづつとる」
この中にYV12、NV12とかが含まれる

YUY422 じゃなくて YUV422

それに付け加えるとインターレースとプログレッシブで
YUV420のサブサンプリング方法が違う

YUV420（インタレ）->YUY2(インタレ)ではサブピクセルの補間処理が必要だが
レフトオリジンのようにオリジナルの値を保持することはできない

avisynthでyv12のままでやれで終わる話何回やってんだよ

aviutlはyv12>yuy2,yuy2>yc48で2回補間処理入って劣化する上に
yc48でフィルタ処理するから無駄に遅いだけ

色空間スレでも立てろ。

そんな怒るなって。どうせ話題も無いんだし。
現状、x264にデーターを渡すにはAvisynthかAviUtlしか無いんだし、
x264を使うにあたっての色空間の取り扱いの勉強が出来て良かったじゃない。
･･･何か間違ったことを言っていた人達が理解できたかは疑問だがｗ

ちゃんとYUY2でAviUtlに渡してやれば問題ない、つーか気にするだけ無駄
たとえRGB変換が入っても目が超いい人なら赤の劣化具合で気づくかもしれないというレベルだし

>>258
> ちゃんとYUY2でAviUtlに渡してやれば問題ない、つーか気にするだけ無駄
そういう話ではなくてAvisynthが使えずAviutlしか使えない人が
あたかもx264が劣化させてるがごとく批判してたのが問題なんでしょ
そりゃ叩かれるわい

えっ

>>255
＞aviutlはyv12>yuy2,yuy2>yc48で2回補間処理入って劣化する
こういう平気で嘘書くのもどうかと思うけどなー

まあAviUtlでx264エンコするならm2v.auiかavsinp.auiでYUVデータ渡すようにすれば問題なし、それだけ

おお…

きな・・・

のっぽの・・・

ちんぽっぽ

約130レスのまとめ

原因>>259
Utlオンリー使いの現実的な対処>>258
Synthオンリー使いの現実的な対処>>255の1行目
両方とも使いたい俺みたいなアホ>>知るか

ってことだな

そんな>>267を応援してる

avisynthでyv12のままで扱うと丸め込み誤差がなー
Aviutlと比べて汚い動画になっちゃうんだよなー

早かろう悪かろうなんだよね

入出力の両方が8-bitなら、これの右ほど汚くはならないだろう。

http://img96.imageshack.us/img96/2305/goldenx.png

>>269
> avisynthでyv12のままで扱うと丸め込み誤差がなー
はぁ？

>>271
ちんぽっぽはちんぽでもしごいてろ

つまりutlではm2vconf.exeでYUY2色空間行列の所を
元のYUVデータを維持にしとけばいいん？

おお…丸め込み誤差…

>>271
yv12のまま扱うと早くなるのは4ピクセル（縦2横2）づつ処理するから

では、横2ピクセルづつ処理した場合と比べて精度はどうなるでしょうか？

>>273
それはまた別の話。ソースがBT.601(アナログ放送,DVD)なのか
BT.709(地デジ)なのかって言う話。
本格的にスレチなので、色空間スレへどうぞ

>>275
一旦拡大してフィルタを掛けてから縮小するのと、
そのままフィルタを掛けたのではどっちの方が精度が高いでしょうか。
NRでもシャープでも何でも良いので、試してみれば分かる。
スーパーサンプリングで高精度！　というのは幻想。

bit深度に関しては、8bit以上に拡大された状態で処理をしておけば、
8bitに戻す際にディザを掛けれるので有用。
実際に活用されてる例として、モニターのガンマ補正などがある。
Avisynthにもdfttestとかがあるけど、x264でディザが潰れるので意味がない･･･。

>>277
拡大してフィルタを掛けてから縮小したほうが綺麗でした！

700ppiで原稿を取り込んで350ppiに縮小
とかいう世界なら縮小の意味もあるだろうけど
モニタに収まる程度の解像度なら縮小の効果は誤差かと

縮小で綺麗←この言葉が曲者　に見えたりするのは、縮小のプロセスで画像の
フィルタリングが行われているからだろ
見やすい絵に作り替えられてるともいえる
シンプルに単純間引きで縮小するとたいていはかえって汚くなるしな

>>278
ほんとにやったの？
スレチ過ぎるが、スプリクトかスクショあげてくれ

典型的なプラシーボ・目の錯覚・思い込みだな。

おお…m2v.vfp/aui の違い理解してない雑魚だらけでワラタｗ

いまどきaviutil（）笑

笑ってる所すまないが
aviutlだよ

aviutil()笑が必要なのは透過性ロゴのlgdファイルを作るときだけだな。
それ以外は触れる気も起こらない。tsを開くのもやたら遅いいし

スクショってスクリーンショットのことか
よからぬ想像をしてしまった

ID:VAkibutf
使う使わないは別としてソフトを笑う奴は大抵がスキルの低い低脳

別に低脳で結構だが、x264スレでaviutilについてマンセーされてもなぁ

>>287

分かる
分かるぞぉ

>>289
よう、低脳。低脳はこのスレに来るな

ID:VAkibutfのレス読んでみたら本当に低能だったｗ
自分じゃネタのつもりで言ったんだろうがｗ

aviutil ｗｗｗ

>>261
aviutlでts(yv12)の読み込みは通常
m2v.auiかavs読み込みでupconv=1かConvertToYUY2( interlaced=true)を使うけど
全部yv12>yuy2の変換に補間が入る

更にaviutlのフィルタ処理はyuy2フィルタモードでもない限り
内部でyuy2>yc48に変換してyc48で処理される
この内部変換のyuy2>yc48も補間が入る

本来補間がなければyv12>yuy2>yc48>yv12の変換は完全に可逆だが
aviutlだと2回補間が入って不可逆になる(1回でも不可逆になる)
補間は不可逆になるだけで劣化はしないんじゃないか？と思うだろうが滲んで汚くなる
この辺は検索すれば解説してるところがいくつも出てくる

この2回の補間をせずに処理する方法もあるけど
それだと無駄に色空間変換して重くしてるだけなのでaviutlを使う意味があまりない
avisynth用のロゴ解析をする時は補間を切った状態で作らないと
綺麗に消えるロゴデータが作れないので使う

>>238
10bit版使ったからといってディザを保持しやすくなるわけではないですよ

>>295
Dark Shikari本人がそう言っているのだから、仕方が無い。

ディザを保持しやすくなるじゃなくて、バンディングが出にくくなる、じゃね？

こいつは覚えたての用語を使いたいだけだろ

x264もaviutlのように16bitで処理すればいいのに

H.264は、14-bitまでの規格。

Dark Shikari風に言うと

16 is the internal precision, not the output precision

今更ながらaviutlは16ビットでスゲーなと思う
avisynthは8ビット処理だからな

>>302
AviSynthでも、16-bitでディザリングはできる。

http://forum.doom9.org/showthread.php?p=1386559#post1386559

>>294
Aviutlもavisynthもフィルター使うと不可逆になるんだが・・・

avisynthでフィルター一切使わずにx264にエンコードしてるのか？

>>304
>>294はたぶん不可逆な処理の回数はなるべく減らした方がいいっていう文脈だろ・・・
それくらい読み取れよ・・・
物事極端にしか考えられないのか

>>305
＞不可逆な処理の回数はなるべく減らした方がいい
フィルター使う回数はなるべく減らした方がいいと同義になるから違うんじゃね？

>>306
不可逆な処理の回数＝フィルター使う回数？
あほか？

他所でやれ

>>307
えっ
フィルター使ってもソースと同じYUVの値になるの？

だんだんAviutlとavisynthの空中戦になってきたなｗ
そんな中で悪いのだが、暗部のバンディングとかどっちのが上手に処理できる？
再生環境にもよると思うが、x264は暗部の処理が弱いと思うのよ

>>310
つビットレート上げてエンコードする

aviutilはプレビューしている時だけ暗部の処理はいい仕上がりに見えるが
高ビットレートで動画のエンコードが終わって事後に再度確認してみると
aviutilでプレビューしていた時より鬼劣化して見えるから要注意な。

>>309
えっ
フィルター使わなければ不可逆な処理は行われないとでも思ってんの？

>>312
それこそx264の設定次第じゃないか。
やっとスレタイに沿う話題に戻ってきたな。

>>314
どう考えてもx264じゃなくてプレイヤーの問題だろ

プレイヤーというかデコーダー

確認用に使っているプレイヤーは標準的なWMP11とMPC-HCだけど
aviutilは編集画面とプレビュー画面で綺麗に見えても何の意味もないんだよな
せめてaviutilもavsPmodみたいに外部プレイヤーで確認できるような機能が
付いてあればいいんだが。

>>316
それが正確だね　言いたいことはそれだったけど言葉が間違ってた
修正ありがとう

AviUtlでフィルタ後のプレビューで見える絵に近いエンコデータが欲しいのなら
x264guiExで10bit出力をONにして10bit深度のx264に渡してみたらどうだ？
ビットレートとフィルタ設定次第だが，暗部も改善するかもしれん。

現状，High10プロファイルの動画を再生可能なのはmplayerくらいだが，
http://mplayer2.srsfckn.biz/
CoreAVCがver.3.0でHigh10プロファイルへの対応を予定しているらしいので，
そうすればMPCでも使えるから期待している。

また，Avisynthで8bit深度を超えるデータをx264に渡すには，
>>303のditherを使うという方法もある。例としてはAvisynth側で

dfttest(sigma=1.0, LSB=true)
Dither_convey_yuv4xxp16_on_yvxx()

としたスクリプト"script.avs"を，

avs2yuv -raw "script.avs" -o - | x264.exe --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24 --output "out.mp4"

として渡す。(--input-resと--fpsは素材に応じて適宜変更)
32bitのx264を使うのならavs2yuvのパイプ出力は不要。

誤記訂正。x264側のパイプを受ける - が抜けてた。

avs2yuv -raw "script.avs" -o - | x264.exe --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24 - --output "out.mp4"

なにげに神IDじゃないかｗ

dfttestのLSBオプションはdither同梱のdfttest.dllで拡張された機能。
LSB=trueとすると，解像度W×Hの入力クリップをフィルタし，
W×Hのクリップを縦方向に2枚積んだW×2Hサイズのクリップとして出力する。
このクリップは，上半分のW×Hが16bit色深度のうち上位8bitを，
下半分のW×Hが下位8bitを表している。

そのため，dfttest後にディザリング処理で8bitに戻さなくても，
フィルタ後の完全な画素情報を保持している（と自分の実験結果では見えた。）

Dither_convey_yuv4xxp16_on_yvxx()はこのW×2Hサイズのクリップを
2W×HサイズのRAW画像として出力し，
擬似的に16bit深度のYV12データになるよう整形するスクリプト関数。
詳しくはdither同梱のdither.avsiを見て欲しいが，
以下のような変換をやっているよ。

Function Dither_convey_yuv4xxp16_on_yvxx (clip src, bool "bigendian")
{
bigendian = Default (bigendian, false)

src
msb = Dither_get_msb ()
lsb = Dither_get_lsb ()

(bigendian) ? Interleave (msb, lsb) : Interleave (lsb, msb)
TurnRight ()
AssumeFieldBased ().AssumeTFF ()
Weave ()
TurnLeft ()
}

素材の演出として元々振られているディザを保持するのなら，
x264を--tune grainnなどに設定しないといけないと思うけど，
フィルタ後のバンディング対策のためにディザを振るのは，
以上の機能を使いx264で--tune animationとすれば回避できるのでは？と，今は考えているし，
手元のMplayerでのテスト結果では良好な感触を得ているよ。

目新しい更新もないから，どうせならこの機会にHigh10プロファイルのエンコ設定を
オマイラ各自実験してみないか？
多分，MPEG2→H.264に移行した時に続くインパクトになると何となく思うのよ。
詳しくはditherプラグインのマニュアルを各自読み込んでくれ。それじゃ。

以上　変人の妄想でした

>>319
うちの環境そのままじゃないかｗ
暗部対策で10bitをONしてみたけど大して変化なかった
出力txtみると上に張り付いている割合が多いので
やっぱもう少しビットレートを上げるしかないのか

一人でやってろ

>>328 ビットレートの他には，
モニタの低輝度側のガンマ調整が出来ていないと，不自然な階調飛びが起こるので
もしかするとそれが原因かもしれない。

というより再生環境が変わると極端に階層飛びが発生するような脆いフィルタなら
最初からかけない方がいいと思う。パラメータひとつで改善されるとも思えないし

まだ見ているか分からないけど>>328
High10プロファイルでエンコした動画のサンプルを上げておいたので，
興味があったらこれが問題なく再生できるかテストしてくれ。
ttp://www.mediafire.com/?jaiv2qed8wqaij8

冒頭のレイジングハートさんがフェードインする辺りで
暗部にもしも変なブロックノイズが出ていたら，再生環境に問題があるかも知れない。
うちのモニタはLCD2490をColorMunkiでsRGBのガンマカーブに合わせてあるけど，
それだと特に問題はない。

サンプルはRec.601→Rec.709に色変換した以外は，輝度色差のレンジはいじっていない。
ディザは全く振らないでx264 --tune animationの設定，
但しビットレートもりもりでエンコしてある。

再生に問題がないのなら，単純にビットレートが足りていないか，
もしくは>>331のようにフィルタの設定が素材に合っていないのかも知れない。

長文うぜ

短文で情報少し、後で書き足すと「後だしウゼ」って書くんだろ？

>>332
いろいろありがとう、家帰ったら試してみる
しかし素材が通すぎて職場じゃ開けないｗ

H.264 High 10は、mplayer2の他に、これで再生できる。

http://nightlies.videolan.org/build/win32/last/

http://x264.nl/　の　32bit 10bit-depth　なんかバグあった？

全部404でDLできなくなっているんだけど

>>337
http://www.mediafire.com/?9dpo9ouyhiqut31

>>326
ディザとグレインは違うから注意。

暗部がパネルのせいで目立つってのはあるかもね。
液晶はほとんどが黒浮きするし、TVはダイナミックコントラスト(笑)
とか入ってる場合が多い。

あと、暗部の話をしている人は、暗部の崩れなのか、暗部のバンディングなのかを
はっきりと書いてくれ。

>>339 グレインはシネマフィルム素材にある粒々という認識で
良いのでしょうか？ディザも由来は違うものの小さい粒子の集合なので，
x264で保持する時はtune grainの設定をベースにしてエンコしていました。
そんな事情があったので書き込み内容がごっちゃになっていてすみません。

あと，暗部の話は自分はバンディングやブロックノイズを想定していました。
絵の細部が崩れる話となると，自分の書き込みは見当違いなので
綺麗サッパリ忘れてください。

>>335 自宅PCからすぐに提供できる素材はこんなものしかなかったので
色々とアレで申し訳ないっす。
Phantomなんかは暗いシーンが多かったようなきがするので，
素材としてはこちらのがベターだと思うけど，もうソースがないので。

オイラが頭イタイのはグラデの色階調崩れなのでパディング
素材、Aviutlの画面の段階では綺麗なグラデーションなのに
出力したときに崩れて悩んでいる

>>342
>>320-321 としたビデオを幾つか見せてもらったけど、どれも綺麗なグラデーションになっているね。

--input-res 1280x720 --fps 24

x264パラメータにこれは必須なのか？
avs内やits内で設定された値で処理できなきゃ手動vfrやL字対応のときに面倒なんだけど

>>340
グレインっていうのは、粒々っていう意味。
代表的なのがシネマフィルム素材由来の物で、それはフィルムグレインと呼ぶ。
グレインを付加すればバンディングは誤魔化せるが、ディザとは根本的に異なる。

ディザとは、(自分の言葉で言えば)端数の切り上げか切り下げかを
確立に基づいてランダムに行なうこと。
ttp://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%82%B6
例えば諧調が4〜5に変化しているグラデーションを処理するときに、
普通に四捨五入で処理をすると、4.4=4、 4.5=5、 となって
本当は中間の色(4.1-4.9)があるのに、4と5の間にクッキリ境界線が出来てしまう。
これがバンディングとなる。

そこで、4.4は4と5が6:4で存在, 4.5は4と5が5:5で存在、というように処理をすれば、
(遠めに見れば)色が混じり合って中間の諧調も再現できる。　これがディザ。
だから、ディザは非常に微細で、拡大して見ないと存在がわからないのが普通になる。

コイツをエンコしてみたいッという基準でDVDを買うのをやめたい

>>345-346 明快な解説ありがとうございます。
自分が根本的にディザの意味を履き違えてました。

>>344 >>321を使ってAvisynthから16bit深度で入力する場合
avs2yuvからRAWソース扱いでx264にパイプ入力するので，
--demuxer raw --input-depth 16の指定は勿論として，
--input-resの指定も必須だと思われます。
（指定しないとエンコ後映像がカオスな事になりました。）

--fpsについては，VFRの時は--fpsを省略し，
代わりに--tcfile-inでタイムコードファイルを入力すればいけます。

ところでdfttest用のscript.avsの中身をこんな風にしてみたら

srcPlugin="z:\hoge\"
LoadPlugin(srcPlugin+"mvtools2.dll")
LoadPlugin(srcPlugin+"libfftw3f-3.dll")
LoadPlugin(srcPlugin+"dither.dll")
LoadPlugin(srcPlugin+"dfttest.dll")

dfttest(sigma=1.0, LSB=true)
Dither_convey_yuv4xxp16_on_yvxx()

avs2yuvでlibfftw3f-3.dllをロードできずにコケるんだけど
何か他に足りないdllとかある？readmeは目を通したんだけどいまいち解決しなくてね。
完全にスレチなのでスルーしてくれても構わないけどさ、

>>349
Windowsが32-bitならSystem32に、64-bitならSysWOW64にlibfftw3f-3.dllを入れる。

>>350に補足

�@dfttest.dllとmvtools2.dllはオリジナルではなく
dither同梱のをLoadPluginで読み込む。

�ADither_convey_yuv4xxp16_on_yvxx() はdither同梱のDither.avsiに記述されているので，
Import("〜〜\Dither.avsi")で読み込む。

�Bditherのその他の機能を使いたい場合はdither同梱の
mt_xxpand_multi.avsiもImport

�Cmt_masktools.dllはa48以降を使用すること。（a47以前では動かない。）

俺としてはAviSynthでdfttest、AviUtlでx264guiExどちらも10bitエンコードの
アプローチとしては旬だと思うのだが、10bitだとそれなりにデータも肥大化
すると思うから、そのあたりトレードオフだな・・・

8bitでもdeadzoneをおもいっきり下げてPフレームに対するBフレームの劣化度を抑えると
かなり階調やディザは拾えるが、10bitでどの程度の画質とファイルサイズになるか興味はある

自分は8bit深度のままエンコしていたときは
スムージングで生じたバンディングをエンコ前に
GradFun2dbmod等でグレインを足して誤魔化してから
グレイン保持設定でエンコする，といったことをしていたので，
ファイルサイズが太りまくっていました。
（>>332で上げたサンプルのアニメが
解像度800x600，長さ25分で300MBくらい行っていました。）
今回のサンプルはそれよりも画素数の多い
960x720なのですが，ファイルサイズは270MBくらいになりました。
同じ800x600ならもっと小さくなると思います。

なので，元々グレインもりもりビットレートもりもりでエンコしていた
のならHigh10プロファイルへの移行はとても恩恵があると思うのですが，
元から余計なフィルタをしない，多少のバンディングは上等な
エンコで十分な場合には，
メリットがないか，むしろデメリットになりそうに何となく思います。

10bit版エンコーダを使うメリットない

10bit深度エンコが本当に活きるのは，
10bit深度以上を使って
(AviUtlのプレビューで綺麗に見えるくらい)
スムージングしたのを8bit深度に丸めないまま
エンコーダに渡せる場合などなので，
そういったソースが用意できないのなら
High10プロファイルの存在は綺麗に忘れた方が
精神衛生上ベターなように思います。

エンコデータにどのくらい綺麗な視聴感
または画質容量比を求めるかは人によって千差万別なので
自身の求めるクオリティを一番ローコストで実現してくれる方法を
自身で見つけてください。ただ，選択肢は多いに超したことはないのです。

10bitでエンコした動画って、プレイヤー（デコーダ）以外にディスプレイや
ビデオカードも10bitに対応してないと意味ない？

>>356
ない

>>356

>>332のサンプルを>>336で再生してみると分かるだろうが、ディスプレイが10-bitに対応していなくても、
Y'CbCr -> RGBの精度が良くなるので、恩恵は十分にある。

>>336で8-bitでエンコードした物もアップロードしてくれていたら、比較できて良かったのだろう。

厳密な比較にはならないのですが，
参考として>>332と大体同じフィルタ，エンコ設定の
8bit深度データも上げておきます。
http://www.mediafire.com/?bxpsp1crdugf8zz

>>332 10bit深度 解像度960x720 サイズ32MB
>>359 08bit深度 解像度800x600 サイズ35MB (グレインもりもり)

グラデーションの差が特に顕著なのは，46秒〜48秒頃の背景を
比較してみてください。>>359ではグレインを足しても
バンディングが目立ちますが，>>332のグラデーションは
とても綺麗に自分のモニタでは見えました。

この差を大きいと感じるか，差が無いと見なすは
人によってどちらにもなりうるので，
自分が求めるクオリティに合う方法を探してみてください。

何で上から口調なの

くださいって言ってるから市価から目線じゃねーか

上からとか下からはどうでも良いが、キモイ文体だってことは確か

>>358
精度が良くなる？

>>359
10bit版を使ったからといってグラデーションが綺麗になるというわけではないですよ

8ビットで処理するには無理があるから
家電の製品はみな10ビット以上になってんだろうが

>>364
内部演算精度の話？

http://img30.imageshack.us/img30/549/8bitt.png
http://img585.imageshack.us/img585/6051/10bit.png

解像度が違うので、比較としてはあれだが。

>>365
パイオニアのLDで有名な話だが8ビットから9ビットにしただけで縞々が消えたっていう逸話がある

はやくaviutlの16bit精度に追いつかないかなー

YUV444入力に対応したら神

>>350-351
詳しい説明どうもありがとう。

Aviutlとavisynthのスレよりここのが勉強になるなんてw

tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる
サイズはそれなりだが

もう秋田

psy-rdって効果微妙じゃない？
これ切ってaq-strength上げた方が良くない？

せやな

>>373
psy-rdを切ってaq-strengthを上げるということは
細部が潰れエッジが削られ全体的にボケてもいいってことだわな
どういうソース？

>>375
実写で目的は暗部のブロックノイズを減らすこと
細部の差の違いがわからない割にブロックノイズが大幅に減るから良いと思った

暗部がおかしい人達は
ビデオカードはGeForce？ Radeon？

頭

>>378
頭悪そう

>>377
Intel HD Graphicsも加えてやんなよ

>>376
それpsy-rd切らなくてもaq-strengthだけ上げれば良いやん

POP氏が反応してるな
ttp://pop.4-bit.jp/?p=3129

関係ないけど>>200を実行して初めてPOPさんとこの背景画像の存在に気付いた

>>382
つまりは、>>170としておいたら良いのに、どうしてもAviUtlを使いたい人たちは大変だな。

理解してないのに無理にレスつけなくていいよ

>>382
＞AviUtlであれば4:2:0補間フィルタで縦補間をすれば若干改善できる。
リンク先にあるMPEG2入力プラグイン 補間なしを使ってカラーバーの比較すれば

にしてもAutoYUY2()の精度低いのな・・・

>>383
あの背景が見えないディスプレイって、どんだけヤバイんだよ。
10bitがどうのとか言ってる場合じゃねーだろｗｗ

背景が見えないのというのはかなりおかしい

　　　　　　　　　　　　　　　　　　　　　　　 _＿__
　　　　　　　 　 　 　 　 　 　 　 _,.-:‐:"::￣:::::::::::￣::｀ヽ、
　　　　 　 　 　 　 　 　 　 　 ／:::::::::/::::::::;'::::::::::::::::::｀ヽ::＼ 　このくらいおかしい
　　　　　　 ＿　 __　　　　　/::／:::::/::;'::::/:::::::::::::::::/:::::::::l::::ﾊ　　　　　 　 _　__
　　　　 （(　＼∨,/　)） 　 /::/:::::::::l::/::/'|:::ｉ:::::::::::/::/|:::l:::|::::::}　 　 　 （(　|∨/　)）
──　　　　　(⌒,)　　 　 j;/::::::::::::|;'::/　|:::|::::::::/::/ ,|:::|::|:::::::|　 　 　 　 (⌒,)
　 　 　 　 　 /"￣｀＼　∠::::::::;ｲ:::l::/＼,|::」::::;/|:/／|/|/:::;':::| 　 　 ／￣Υ
────　 | ＜.´￣＼ /::::::/::|:::|/　●　￣　 ´●　/:::/:|i::| 　 ／　__　/
　　　　　　　 ￣｀＼　　 ＼::/::::|::::|　 "　　　　　 　゛/:::/l:::||∧／"￣;| ,/
──────　　 ＼　　 ＼:::|:_:」　　　 ,.‐--. 　 /::;/:::|/::／　　 ／∨
　　　　　　 　 　 　 /::::＼　　 ＼::::ヽ、　〈::＿,ﾉ　 'ﾌ"::::::;／　　 ／
──────　 /:::／/:＼　　"￣ }:;＞‐ｒ:-r＜´/´￣゛　 ,,／:|
　　　　　　　　　　ｊ/´ /::::::::|"　　 　 /　 ＼＿_:|｀＼､　　　/::::::::|
──────　 　 /::::::::::::ｰ─-r'　￣７　＼_,| ＜__Ｙ─':::::::::/
　　　　　　　　　　　/::::::::;ｲ::::::::::::::|　　　 ＼,,/:::|,／　 |:::::::::::::/
─────　＿,ノ:::::／/::::::::::::::::〉:..゛　　　/::/´　　,/:::::;ｲ::/
　　　　　　 ＜´::::::::／ ./::::::::::::::::/::::　　　 /:::/ 　 "/::／/::/

　　　　　　　　　　 ____＿＿ 　 　 　 　 　 　 　／|
　　　　　　　　 ,-''::::;::::::::::::::‘''‐ ., 　　　　　 　|ヘ|
　 　　　　　　/:::::::;:/´ヾﾍ;;::::::::::::::＼　　　　 　|ヘ|
　　　　　　 ,ﾞ:::（（,/　　　　`､::r:::::::::丶　　　　_| __|
　　 　　 　 i::::i　＼　　　／ 　ﾞi::::::::::::',　　　/つ( ）　───
　 < ＼　　|::::l　●　　　●　　|::::::::::::! 　 ／ └┘
　　丶／＼!:::!　　　 　　　 　　!::::::::::::!／ ＼ /　　　　───
　　 丶／　|:::!""　＿_＿_　"" !::::::::／ 　＼/
　　　 丶　 i::ヽ 　 丶 　　,l　　|::::::| 　 　　/　　　────
　　　　 丶　i:::..＼,_　"''''` _,./､l:::::i 　 　 /
　　　　　 丶 ヽ::| 　l,_￣l二/ ／|:::/　　 / 　　　─────
　　　　　　 丶 　 　＼　| /／　 ﾚ'　　 /
　　　　 　 　 丶　i　　‘'' " 　　 　 ＼/ 　　　──────
　　　　　　　　 ＼|　NEVADA　　 　丶
　　　　　　　 　 　|　 　 　 　 　 　 　 　 ＼　　───────

持ってかれた

>>382
やあありがたい、とてもよくわかったわ、サンクス

>>392
＞若干綺麗なプレビューを見られるものの、それはあくまで「YC48上のデータ」を見ているに過ぎず、
＞このあたりはきっちり把握しておく必要があります

カラーバーの比較してプレビュー画面が綺麗とか汚いとか言ってるけど
x264にYV12に変換してから渡すことが考慮されていない

MPEG-2 VIDEO VFAPI Plug-Inの補間が何故あるのか？

http://avisynth.org/mediawiki/Sampling
・YV12 interlaced conversion -> YUY2
・YUY2 -> YV12 interlaced conversion
・YUY2 -> YV12 progressive conversion

avisynth公式のこの辺を読むことをすすめる
（公式でも間違ってることがあるから自分で確かめることもすすめる）

日本語でおk

ところでさ、>>319のmplayer2の件なんだけど、このソフトについて日本語でわかりやすく開設しているサイトって
ないのだろうか？

検索しても>>319のリンク先みたいな最新版が出てこないし、mplayer2とはまた別みたいだし。
俺の環境でいろいろ再生してみたら、10bitとか4:4:4とかの動画で他のソフトだとなんらかの問題が出ていたのが
mplayer2だときれいに再生できるようなので、mplayer2をデフォルトにしようかと思うんだけど、再生と停止
以外の細かい操作方法がほとんどよくわからん。
(早送りと巻き戻しはマウスのホイールで動かせるようだけど、細かい調整がしにくいし)

ただし、mplayer2で再生しようとするとマシン負荷が高いのか、処理に手間のかかるやつだと音と絵がずれる…

>>393
>x264にYV12に変換してから渡すことが考慮されていない
AviUtilではx264にYV12に変換してから渡すことが考慮されていない

こっちに訂正した方がいいんじゃない？
その文章だけ見てると意味が伝わりにくいよ。

中段
×　mplayer2とはまた別みたいだし
○　mplayerとはまた別みたいだし

mplayerというか、これにインターフェースを足したようなSMplayerだと10bitや4:4:4の動画が再生できないようなので。

>>394
YV12に変換するときにMPEG-2 VIDEO VFAPI Plug-Inが補完した処理の真逆が
YUY2をYV12に変換するときに行われる

編集途中のプレビューでは一目汚く見えるだけでこの補完がないと色が滲んだ動画ができる

? YV12に変換するとき
◯ YUY2をYV12に変換するとき

また間違えたーーーーー

◯Yv12をYUY2に変換するときにMPEG-2 VIDEO VFAPI Plug-Inが〜

そんなにあわてて訂正しなくてもここの住民にはたぶん殆ど伝わってないと思われ。

どこの訂正なんだか分かりづらいからそんなに直すなら全文直して再投稿してくれ

不必要な色空間変換なんかやってそれで劣化の具合がどうだとか
全てAviutl側の不出来の問題であってx264と関係無いんだから
Aviutlスレ行って思う存分やればいいのに

>>393
x264にYV12変換して渡すにしてもMPEG-2 VIDEO VFAPI Plug-Inの補間は
やや特殊で完全には元のYV12に戻らないはず

実際やってみるとわかるけどMPEG-2 VIDEO VFAPI Plug-In出力を
YV12に戻したデータとYV12ダイレクトのデータを比べたら違う

しかもリサイズしたりプログレッシブなフィルタを使うなら
MPEG-2 VIDEO VFAPI Plug-InのYUY2変換は問題あると思うな

スレチなんで俺はこれで引く

AviSynthでMPEG-2 VIDEO VFAPI Plug-In使うと一部フィルターでゴミでたり
するから使ってないわ

AviSynth 2.5には、YV12としてMPEG-2をデコードできるDGDecode、FFMS2、DGDecodeNVがあるから、
YUY2なるm2v.vfpは不要。

mplayer2のことを調べていたら、mplayer2のエンジン使って使い勝手をよくしたmplayer WWとかいうのが
見つかって解決しました。
http://sourceforge.net/projects/mplayer-ww/files/MPlayer_Release/

meditor2.exeでデフォルトではオフになっているインタレ解除もオンにできたのでとりあえずこれでよさげ。

MPEG-2 VIDEO VFAPI Plug-InにはYV12変換機能は無いでしょ
変換してるのはx264側。

x264にはAvisynthのConvertToYV12と同じ色空間変換機能がマージされて
るから、AviutilはYUY2でx264に渡し、x264側で色空間変換してるんだよ

昔は、YV12に変換するAviutlフィルタを最後尾に入れないと
x264エンコが出来なかったんだけどね。

>>408
x264guiExとx264は別

>>408
問題にしてるのは
MPEG-2 VIDEO VFAPI Plug-InのYUY2変換じゃね？

>>407
mplayerWWはmplayer2ではなくmplayerベース

>>408
x264cliで使われているのはswsclae(FFmpeg/Libav)であって、avisynthと同じではない
ついでに言えば、x264にYUY2で渡すプラグインも存在しない
それともx264vfw使ってるの？

>>411
mplayerWWはmplayerがベースなんですか。
まぁ、こちらで試した限りでは10bitや4:4:4の動画でも特に問題がないようなので、とりあえず
mplayerWWを使っておきます。
何か問題がるときだけmplayer2を使うことにします。

次はsubme 11か…

石が熱くなるな…

おお…

しま…

なぎさ…

>>413
それくるとなんかいいことあんの？

Add --subme 11, which disables all early terminations in analysis
Necessary for a future trellis mode decision/motion estimation patch.

日本語でおｋ

10とか意味あんのかよｗｗｗって言われてて11とかどうなの

どうなのもクソも
新しい試みは大歓迎だろ

ワシはイヤじゃ！

ワシはオトコじゃ！

よぉ秀吉

今のsubme10って驚くほど高性能だから一度使ってみな

でも遅いんでしょう？

それがなんと！

お値段据え置き

今なら更にBフレームをもう2枚お付けして

たったの0.98fps！

高ぇよー

>>427-432
このスレで初めてワロタｗ

一行レスでリレーしてるの見るとイラッとくる
VIPでやれよ

お前をイラつかせるのが最高の愉悦
これからも苦しんでください

なんだ自演だったのか
スレ住民の程度が低いのかと思ってた
安心したよ

下痢便垂れ流す負け犬の発言でした

>>437
2ch自体そういう場所なんだから多めに見てやれよｗｗ

でもおお・・・だの毎回書き込むのはかなりKYだと思うの

おお…

>>439よ

おお・・・

死んでしまうとは

>>440-443
つまらないからやめて欲しいの。

おお…でもおお・・・だの毎回書き込むのはかなりKYだと思うの

>>444
お前をイラつかせるのが最高の愉悦
これからも苦しんでください

おお・・・

x264のスレもういらないんじゃない？

せやろか？

>>446
既にNGにしてるから苦しくも何ともないよ。

おお・・・

・・・じゃなく…が正しい

もう…

いく…

つ ねると…

30歳

マイナスかよ

おお・・・



>>459
ざけんな



・・・おお

殺伐としてるな。
強いて盛り上がったのが色空間か。
胸が熱くなるな。

おお･･･

あんな流れよりおおのほうがマシだわ

avisynthもMPEG-2 VIDEO VFAPI Plug-InもDGDecode.dllも同じ補間しているという事実

おお…

>>466
DGDecodeをデフォルトのupConv=0として使えば、自分でConvertToYUY2とでも付け加えない限り、
YV12のまま補間はされない。

もうええって

>>459>>461ってjaneで見ると普通なのに携帯やスマートフォンで見ると絵文字なのな

>>466
avisynth の ConvertYUY2(interlaced=true) はちっと特殊だよ。2.5.8 のソース見た限りでは

　dst[4*y+0] = (src[2*y+0]*3 + src[2*y-2]) / 4
　dst[4*y+1] = (src[2*y+1]*3 + src[2*y-1]) / 4
　dst[4*y+2] = (src[2*y+0]*3 + src[2*y+2]) / 4
　dst[4*y+3] = (src[2*y+1]*3 + src[2*y+3]) / 4

で補間してた。カラーバーを (interlaced=true) でアップサンプルしてもラインの食い込みが
目立たないのはその辺が原因。

m2v.vfp/aui や DGMPGDec は

　dst[4*y+0] = (src[2*y+0]*7 + src[2*y-2]) / 8
　dst[4*y+1] = (src[2*y+1]*5 + src[2*y-1]*3) / 8
　dst[4*y+2] = (src[2*y+0]*5 + src[2*y+2]*3) / 8
　dst[4*y+3] = (src[2*y+1]*7 + src[2*y+3]) / 8

での補間だけど。

んで、リサイズも何もしないでトランスコードだけとか、
あるいはインタレース維持リサイズしてインタレースエンコードとか、
YV12 でデインタレースしてプログレッシブにしてからフィルタリングするとか
420 が欲しくて余計なことはしてほしくないという人もいる以上、
現状のアップサンプリング処理を擁護する必要はないんじゃないかな。

oo・・・

>>471
初期のavisynthは下のほうだったんじゃないかな

たぶん規格があるんだと思うけど・・・

おまえら、そんなに語りたいなら色空間スレ立てろよｗ

おお…いつの間にかなくなってるのね、色空間スレ。

いいじゃん統合で
どうせおおしか書くことないんだし

x264と色空間のスレを統合してなんの意味があんだよ

おお…スレを統合しない方が高画質だと思ってるやつがまだいるのか

流れ無視して


暗部の粒状感のバカァ！

subme 11より、9と10の高速化してくれ
バカァ！

PC買い替えロバか

最初ぽかーんだった
でも言ってる事は俺と同じだった

sandy i7だ
バカァ！

PC買い替えロバか

6コアのGulfにするかSandy-Eまで待ってロバか

8コアのZambeziはどうスか旦那
x264も速いらしいですぜ

おお…

かわ…

りゅう・・・

なき反抗

涼しくてエンコ日和だぜよ!!!!!

涼しいからロリコンいらずだな

最近ようやく色空間について理解してきたんだが、
まさか2chに色空間スレがないとは思わなかった。
誰か立ててくれ。

>>493
アナログの頃は色々あったけど、今は4:2:0のソースを4:2:0でエンコードするだけだから、
それ専用のスレは不要じゃないか。

>>494
おいおい、このスレ殆ど色空間の話しかしてねーんだぞ。よくそんなこと言えるなｗ

>>493
>>493
今更新たにやる必要はないかもね

必要なら初代スレの過去ログで十分だし
誰かが次スレを立てたが3日で落ちたし、需要はそんなもんだろｗ

【YUY2 YV12】色空間スレ【RGB24 32】
色空間スレ その2

これをキーワードにしてウンコあたりで読めばいい

>>495
勘違い君が暴れていただけだろｗ
このスレ自体が暇だったから相手にした奴が多かったみたいだが

色空間というか各エンコツールの仕様談義になるからねぇ

最近のbuildでthread=の表示残らなくなった?どうよ

>>499
私が自分でコンパイルしたr2019では残る。

PegasysやCyberlinkなどの商用ツールを使ってx264/h264エンコをすれば
生成されたファイル情報からthread=の詳細とか消えるはずだけど？

なんで残したくないんだよ
嫌ならバイナリエディタでそこの部分を0埋めでもすればいいじゃないか

ペガシスTVMW5でx264エンコしたものもthreads表示はあるぞ。
サイバーリンクはx264使ってたっけ？

サイバーリンクはcu264じゃなかったっけ

thread=もう出ないの？
それは良かった。俺の糞環境がようやくバレないようになったか…。

と思ったら、普通に出てるよ。
微妙に順番変わってるけど。

>>505
知られるのが嫌なら--threads 16にしときゃいいだろ
てかバイナリエディタで書き換えればいくらでも改竄できんのにあほか

自意識過剰もいいとこｗ　誰もあんたの糞エンコの
糞環境なんて気にしないっての。

11きちゃったかー

バイナリ編集するよりmuken氏のpatch当てればええやん

r2037来てんじゃねーか
リビジョン上がってもあんまり話題にならなくなったな

これに登録しておけば、更新がきたらすぐに分かる。

http://mailman.videolan.org/listinfo/x264-devel

大きい改変なら話題になるよ

subme11ってpresetに入るのかstableでビルドしてるから分かんね

って内容に書いてあるな

ちょっと遅くなったな

>515
俺のコンパイルがよくなかっただけだわ
再コンパイルしたら前よかちょっとだけ速くなった

のーみそこねこね

おお…おお…おお………

ｽｽﾞﾒも11匹目ですかい。
いったい何匹まで増えるんですかねぇ、じいさん…
増えた分、いいことあるといいですね。

subme 11、なかなかいいね。
subme 10は気に入らなかったけど、これなら9の代わりに使えそうだ。
かなり重いから多用するのは考え物だが。

比較画像ぷりーず

比較画像なんか無くても自分でエンコしてみりゃ良いだけじゃね？

暗部見てみると10も11も9より良くなってる気がしない

なんでsubmeで暗部を比較する
fullhelp読めよ

thread=2の僕はHyper-ThreadingのP4だということがばれてしまうんやなｗ
喜劇やなｗ

その値はx264.exeの動作に割り振ったCPU全体のスレッド数 x 1.5 の数値だから

マルチプロセスでやってたら分割数はいくらでも減りそうだが

AthXP 2発機の俺をお呼びですか

最近、x264のオプションを変えながら暗部のエンコードテストをやっていたが、
明確に効果があったのはdeadzoneの値の変更だったな。
次点はpsy-rdの変更とディザを加えること。ノイズは増えてしまうが。
後は似たり寄ったりだった。極端にビットレートを上げる、という選択肢は別として。

推奨値ｐｌｚ

それは「ソースによる」としか言えないのでは

6前後ってとこか

deadzoneいじるよりも素直にcrf下げたほうがいい場合も多い

trellis2で使えないのがなあ＞ぞね

subme11にしたら10よりファイルサイズ増えやがった
重すぎるし今のところは10にしとこう

おや
x264.nlで64bit-10bit落とせるようになったんだ

10bitでエンコードしたのは10bit対応してないプレイヤーでは再生できないの？それとも再生できるけど8bitでエンコードしたものと同じ状態で再生されるの？

>>537
H.264 Hi10Pに対応した物が必要。これらの内のいずれかを使えば再生できる。

http://mplayer2.srsfckn.biz/
http://nightlies.videolan.org/build/win32/last/
http://www.cccp-project.net/beta/

わざわざ圧縮率を低くしてまで10bitにこだわるなら8bitでQP10台前半出るぐらいビットレート盛らないと無駄だよな
まだ入出力が限定的過ぎる

今のところ、再生可能な環境が限られているのは事実だが、10-bitの方が8-bitよりも圧縮率は良くなる。

http://x264.nl/x264/10bit_03-422_10_bit_pristine_video_quality.pdf

まあPS3だのBDだのが重要な人たちは無視して8bit使えばいいよ
現時点で10bitだ4:4:4だと言ってる層は、そういう環境が
だんだん揃っていくこと自体を楽しんでいるんだから

>>529
内容を見ると、暗部のバンディングの話って事でおｋ？
trellisは可変deadzoneだし、要はdeadzoneだね。

subme11+新trellisでどうなるのかちょっと楽しみだな。 新AQも。

trellisも新しくなったの？

>>543
まだなってない。 subme11はそれの下準備だってさ。

>>544
ﾍｪﾍｪﾍｪ∩＼(゜。゜)
出たら教えてくんなまし

エンコ半分くらい進んでちょっとコンビニ行って帰ってきたら丁度
セキュリティ関連かなんかで勝手に再起動かますとこだったでござるの巻

エンコとか関係なしに、勝手に何かダウンロードして
勝手に再起動する設定とか、ありえない。

>>547
「再起動しますか？」の選択を迫られたって意味だろ。

その選択を何度も繰り返してると勝手に再起動しやがるけどな
昔、20時間以上のエンコをしてて残り30分ってところで風呂に入って戻ってきたら…
それ以来自動更新は切ってるなｗ

>>548
選択を迫られるなら、「勝手に」とは言わないだろ。

>>549
>その選択を何度も繰り返してると勝手に再起動しやがるけどな
え？そうなの？そんな事あるわけ？

subme11で圧縮したファイルって古めのデコーダでもちゃんと処理されるのかな？
圧縮アルゴリズム？が違うだけなら関係なさそうだけど・・・

>>546
OSが勝手に強制再起動するダイアログが表示されたら
以下を動かして強制再起動を阻止汁。
デスクトップなどにショートカットに作成しておくと捗るよ。

%windir%\system32\shutdown.exe -a

>>552
ただビットレートをどこに割り振るかという重点が変わるだけでしょ
デコーダ側には関係のないはなし

再起動しますか？と聞いてくるくせに
時限装置付きなのが馬鹿げてる、そんなWindowsUpdate

再起動の瞬間
「いい加減にしろ無視すんな死ねよバカ」
とか一瞬表示されない？

通知するだけにしておけば

WindowsUpdateは自動DLまでは良いけど、自動インストールは切った方が良いよ。

更新確認までだな

以下の内容を noautoreboot.reg などの名前で保存して、ダブルクリックしる。
自動インストール後でも、勝手に再起動しなくなる。

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

WindowsUpdateって次の通知時刻をその場で変更できるだろ
この前ちょうどエンコ中に来たんで次の通知は5時間後に変更したおぼえがあるんだが

いつもの事だがホント雑談スレだな、ここ
もう安定しちゃって話す事も少なくなってるのはわかるが

おお…

An unhandled win32 exception occurred in x264.exe [5096].
Just-In-Time debugging this exception failed with the following error: アクセスが拒否されました。
An unhandled win32 exception occurred in x264.exe [3328].
Just-In-Time debugging this exception failed with the following error: アクセスが拒否されました。

こういうエラーならイベントログに残るけどさ

% x264 -V

x264 0.114.x
(libswscale 0.12.0)
(libavformat 52.97.0)
(ffmpegsource 2.14.2.0)
built on Feb 7 2011, gcc: 4.5.2
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Bフレーム16枚まで設定出来るがそんなに使う用途ってあるか実際

AVとかそんなんでもいい気がする

静止画に近いものなら使いそうな気はする

本当にただの静止画だったらIとPしか出ないのかな

むしろ普通の設定だと16枚はいらない

--b-adapt 1では、デフォルトの--bframes 3よりも、--bframes 16とした方が速い。

MPEG2 720x480 1時間51秒
--crf 18 --partitions all --bframes 5 --ref 3 --weightp 2 --me umh --subme 7 --threads 3

i7とやPhenomII6コアみたいな最新鋭のCPU使ってる奴はこのソースを上の設定でエンコした場合おおよそ何分で完了する?

・・・今のCPUだとどれくらい速いか気になったもんで

>>571
【x264+AviSynth】実用エンコベンチ【32bit,64bit】
http://hibari.2ch.net/test/read.cgi/jisaku/1282371527/

>>571
フィルタなしなら5分かからないんじゃね

>>571
--threads 3　・・・。

3指定するとどうなっちゃうわけ？ってかなんで3にしたくなったの？

2スレッドしか無いからじゃね？

ｘ1.5

>>571
--threads 3
何故thread数指定するの？
6コア使ってると3コア余るし、4コアでも余り出るんだけど

だからコア数*1.5だろ

今使ってるCPUがデュアルコアなんだろ

>>578
それはオート指定しても出来たファイルには実際使われた数が表示される

>>570
そんな設定にしたらビットレートがあまり出ず質が落ちるので俺は釣られない。

--threads 0にすれば自動でコア数x1.5してくれるのになんでわざわざ--threads 3にしてるのって意味だろ？ｗ

>>581
>>571はオート指定じゃなくて手動指定してるじゃん

「Bフレーム使ったら画質落ちる」君が久々にやってきました

「使ったら」ではなく「使いすぎたら」だろ。

同じcrfなら落ちるが同じ容量にしたら落ちない

>>581
>>571は
>上の設定でエンコ
って言ってるのになんで「表示された設定」で解釈してるの？

>>571が--threadsが何かわかってないまま書いちゃったんだろ

コアあたりの差を知りたいのかと、という解釈は1スレッドにしてない時点で無理があるか
どうでもいいけど使用スレッド数を変えると出来上がりの微妙なサイズ差が気になる

自炊したﾌｧｲﾙの設定をmediainfとかで吐かせたんだと思う
関係ないけど3ｺｱCPUだとどうなるんだろ？
切り捨てで4になるんかな

こまけぇこたぁいいんだよ

>>590
MediaInfoならスラッシュで区切られたのが表示される
どうみてもコマンドラインだろ
適当なこと言うなｗ

スラッシュかハイフンか以前にMediaInfoだとpartitions allとは表示されないのでは

最近更新間隔が短いな

ここしか見てないから何が変わったか分からん。久々に猫科見て来るか

r2044

subme11と新aqが来たら起こして

11はもう来てるだろ

暇人ども検証よろ

11なんて回している暇はない・・・

subme 11もtesaも使いまくりだな
差はあるとしても微々たるもんだが・・・

現在の最新版でも--aq-mode 2を指定した時--qcompの値には--aq-strengthの値を0.4/0.28倍したものが
加算されるのですか？

この糞暑い中１１どころかエンコする気すら起きない

節電しないといけないしな

7月の電気代1万円でしたごめんなさい

毎年夏になると8万円以上になる

エアコンが6台あって半分くらいつけっぱなのがいけないのだろうか

エアコンなんか使ってないな
部屋の温度は、ドアあけて網戸にして風通しても33〜36度
でも大丈夫

>風通しても33〜36度
どこ？

どうでもいいけど地底人っているのかな

俺が信じるお前を信じろ

お前が信じる奴なんて信用できない

>>608
東京。
俺の部屋、日当たりの良い二階だからいつもこんな温度
今あ涼しいから29度だな

30度以下→涼しい
30-32度 →暑い
33-35度 →汗が止まらん
36度以上→死ぬ

個人的にはこんな感じ。職場が厨房だから死ねる。35-40度位。
熱中症、倒れるだけなら良いけど、死ぬから水はちゃんと飲もうぜ

厨房はどうしても暑くなるからな
水だけじゃなく塩分もとらないとダメだぞ

>>612
いいなあ今でも31度だよ

これは少し気になるな。

[x264-devel] bug: incorrect 8bit -> 10bit conversion
http://mailman.videolan.org/pipermail/x264-devel/2011-July/008685.html

猫科が息してない
どうしちゃったの

twitterで元気にしてるから単に面倒なだけだろ

訳が知りたいんだけど
どうしたらいいの！

普通に読めばいいんじゃね？

>>619
猫科は翻訳機じゃねーよ。この馬鹿

未来の世界からきた猫型ロボットだと聞いたが？

もしかしたら箱の方が本体なのかも

ﾇｺ型ロボットって道具が凄いだけでロボはすげーロースペッコなんじゃないの

暗部がｻﾞﾜｻﾞﾜする場合ってどのパラメーターを弄るのが効果ありますかね
ﾊﾟﾗﾒｰﾀさえ教えていただければ試行錯誤シてみたいと思うのですが
よろしくお願いします

ディスプレイ買い替えが一番効きます

>>626
百も承知でございます

>>625
10-bitのx264を使うのが最も効果的だ。

>>625
みんなわかんないんだよ。つーか質問スレあるんだからそっちで聞けば良いのに。

10bitが効果的なのは知っていますが当方環境がありません。
質問スレよりこちらの常通されている方のほうが詳しいのかな、と思い書かせて頂きました。
ご迷惑をかけもしわけありませんでした。質問スレの方で聞いてみます。

画面の暗い映像は総じてファイルサイズが小さいし
暗部の色数の少なさは如何ともしがたいんじゃないかと

最近リリースされたこれには、hi10pをデコードできるffdshowが入っているな。

http://cccp-project.net/

話題がループしてるな

おお…

ブレネリ…

あなたの…

為だから…

また韓国攻撃始まったのか？
見れない板が出て来た

俺の巡回先はひとつも落ちてないんで気がつかなかった

>>638
モペキチらしいぞ
予告してた韓国もやってんのかな

もうすぐ8月15日のF5攻撃もあるだろうな

o┤*´Д｀*├o ｱｧｰ

あっ、翻訳箱さんだ

いつもご苦労様っす

スイスなのよ〜

mukenくんは誰と戦ってるんだ？

ムキー

ここにまで持ち込むんじゃねーよ

しっ！見ちゃいけません！

Auto-variance AQ modificationのパッチ当ててるビルダーさんいるけど、
これって前に誰かが言ってた輪郭にビットをより多く割り振るAQでいいのかな？

ｒ2057
http://mailman.videolan.org/pipermail/x264-devel/2011-August/008705.html

最適化とコードの整理みたいだね。

新trelis実装されたら起こしてくれ

あきらかに業務用だろうｗ

32bit版のx264使ってたら
３G以上のメモリ使う動画は、もしかしてクラッシュしちゃいますか？

＞３G以上のメモリ使う動画

？

>>655
仮にそれが起きたとしてもディスクスワップするだけじゃね

>>657
なるほど
答えていただき
どうもありがとうございます

>>655
君面白いねセンスあるよ

おお…３G以上のメモリ使う動画は、もしかしてクラッシュしちゃいますか？

いや、もし32bit OSで3GB以上メモリ使えばクラッシュするじゃね？
64bit OSで32bitプロセスなら4GBだが

>>657

通常2GB使いたくても使えない

rc-rookahead盛らなければ大丈夫

Engrish

うぇ…gui使いなんだ見逃してくれ…

>>662
だから扱えるメモリを超えるとソフトがクラッシュするんじゃね？

OS無視かよ

もちろんクラッシュする。
ページングができても1プロセスあたりに割り当てられる仮想メモリの限界は超えられない。

Windowsで仮想メモリ使えるならそこにスワップする、
使わない設定だとメモリが不足してます、みたいなエラーが出てアプリが落ちる

OSにメモリくださいってお願いした時点でダメだよって言われるんで32bitアプリであるかぎり
そもそも獲得できない。獲得できなかったのにその領域にアクセスしたらどうなるかは分かるだろう？

意味がわからん

ば、爆発する・・・？

月末にメモリ代を請求される？

http://ja.wikipedia.org/wiki/Malloc#.E7.A2.BA.E4.BF.9D.E3.82.A8.E3.83.A9.E3.83.BC

プロセス空間は4GBが最大でそれ以上はアクセス方法が無い。
そのうち、カーネルモードに2GB（又は1GB)必要なので、ユーザーモード仮想メモリとしては
2GB(又は3GB）しか無いんだよ。
このプロセス空間はアプリ毎に持つので、複数プロセスを同時に走らせると全体としては
4GBを超えてもいけるわけだが。
なお実メモリ16GBを超えるメモリを載んでるとカーネルモード仮想空間は2GB必要なので
ユーザー空間も2GBまでしか使えない。

まず3GBもメモリ喰う動画を作ってみろよ

1920x1080のソースでTGMC等を使えば、x264と合わせてそれくらいはいくんじゃないか。

x264のプロセスだけで900MBくらい使うからなぁ

>>676
このプログラムは使ってないから関係ないけど
AWEみたいなのがあるから無い訳じゃない

何のアプリを使ってエンコしてるのか知らないが、大容量のメモリを使用するアプリならその辺は十分注意しているよ。
メモリ使用量に無頓着なソフトは小容量のメモリしか使わないんでその危険性が無視できるためだろ。
メモリが獲得できなかったらエラーメッセージを表示して終了するぐらいだけどクラッシュなんてしない。

>>624
自力で状況を判断して適切な道具を選択するというだけで相当ハイスペックだと思う。

rc-rookaheadを盛れば、２GBなんて簡単に使えて、すぐにクラッシュする。

2GB超えるなら、rc-rookaheadを盛りすぎなんじゃないか？

rate control look ahead

珍しくIDが被った。

E n g r i s h

PSVitaがH.264 High Profile対応で最強のポータブルアニメ鑑賞マシンになるぞ

対応コーデック
ミュージック − MP3 MPEG-1/2 Audio Layer 3、MP4 (MPEG-4 AAC)、WAVE (Linear PCM)
ビデオ − MPEG-4 Simple Profile (AAC)、H.264/MPEG-4 AVC High/Main/Baseline Profile (AAC)
フォト − JPEG (Exif 2.2.1), TIFF, BMP, GIF, PNG
http://www.jp.playstation.com/info/release/nr_20110817_psvita.html

ポータブルには見ないなあ

マルチ乙

> ビデオ − MPEG-4 Simple Profile (AAC)、H.264/MPEG-4 AVC High/Main/Baseline Profile (AAC)
AAC・・・？

電車内でみるとかそういう用途か
ヒキコモリの俺には関係ないか・・・

どのスマフォでもHighプロファイル再生できるでしょ

ゲーム機なんか使わなくても今時スマホで見れるよな

( ﾟдﾟ)<ﾎﾟｰﾀﾎﾞｰ

itouchでもとっくにHigh3.1の720pまでならいける、けど音声は160kbpsまでだったか
インタレ解除がラデ並の60i対応とかだったら嬉しいかもネ
むしろPSPがmain@3までしかできないのが残念仕様すぎる

確かに60fpsでヌルヌル再生してくれたら、ありがたいな

iPhone3GS持ちなんだが
AppleのHPにはAAC160kbpsまでって書いてあるけど
AAC320kbpsをmuxしても普通に再生される

まあ音声の話なんでスレチなんだけど

1080iでなけりゃ60i対応したってあんまり意味ないがな。

256kbpsとかになる放送の音声をそのまま使い回しているけど、iPodで再生できるね。

インタレエンコとか、皆してんの？

めんどいからほぼ保持エンコしてる

野球の映像をたまにしてる

TSとDVDはインタレ保持

>695
残念仕様すぎるって言ってもPSPが出た年を考えろよｗ

>700
インタレ保持がほとんど。

インタレ保持ってどういう場合にするの？

ソースが実60iの場合
スポーツ　音楽番組　バラエティ　ニュース　一部のドラマ
つまりＴＶ番組のほとんど

圧縮したい時

>>704
まあね、ただ家電のSONYに期待しちゃいたいというか

>>705
アニメ映画米ドラくらいしか解除しないなぁ。ま、つまり結論は706の言うとおりソースが60iのものは保持

あああとi系の音声のビットレ情報くれた人ありがとう、参考になった

映画や一部のドラマ以外の実写はほとんど保持するね
ていうか解除するケースの方がほとんどないから使ったことないけど

映画以外にも、ヨーロッパで制作された映像等、60iではなく、25pにするべき物がある。

たまにエロDVDエンコする時あるんだけどインタレ保持した方がいい？

実写でも大河ドラマは30pかな。

めんどくせーから全部解除してる

解除する方がめんどくさいような

容量とエンコ時間節約のためにリサイズする時は解除かね

25pってフィールドの並び順はどうなってんの？

>>717
今BS1でやっている世界のドキュメンタリーなんかは、単純にブレンドしている。

なるほど、インターレス保持派の方も多いのね。
現行のx264だと保持エンコだと解除後エンコに比べてかなり膨れるんで
自分は実写系はブレンドして少し小さくリサイズしてしまう。
これだと解像度の劣化もあまり気にならないので。

俺もエロDVDは解除して60pで援交してるよ

ずっと気になってたんだけど、インタレ維持でエンコしてる人って
トップ/ボトム混在ソースはどう対処してるんだ?

そのままだろ

そのままって言ったってTFFかBFFどっちかでエンコするわけじゃん。
そしたら再生する時、判定が逆になってマトモに再生できないんじゃないの？

>>723
アニメの切り貼りと違うんだしそんな心配は不要だろ。

>>721
トップ/ボトム混在ソースが無い

>>692
大抵はHigh対応でもBフレーム数が一定数(非公開)以上だと再生出来ないんだぜ
iphone4だと解像度とfpsがいくら以上だとBフレいくらまで許容して再生とか複雑すぎてたたき割りそうになった事がある｡

>>725
俺もそんなのあったっけ？と感じたが思いつかなかったな
逆にトップ/ボトム混在ソースなんて変態動画はどんなものか聞いてみたい

>>721
トップ/ボトム混在ソースってどんなのがあるの？

WOWOWとBSJは混在あるかも
WOWOWは番組の途中にCM挟まないからいいけど
BSJはCM明けでトップ/ボトム入れ替わりとか普通にあった気がする

それ誤検出だと思う
前に強制トップで読ませないとまともに24ｐ化できなくて悩んだ事が…。

>>729
http://hibari.2ch.net/test/read.cgi/avi/1308579804/320

からまるものレスよく読もう

BSJは経験上だけどトップファーストで入れ替わりは経験ないなぁ、リンク先だとあるみたいね
WOWOWはもう嫌だ

>>732
読み込み時にトップ指定するだけで問題解決なのに嫌もなにも

なるほど、理解できた
結構いろいろな所で書かれてたから
衛星放送ではトップ[/ボトム混在が普通なのかと思ってたよ

入れ替えがあるのは解除もしにくくね？
まぁトップ部分とボトム部分を別々エンコ、合体すればいいんだろうけど

すでに解決済みっぽいけど「トップ/ボトム」混在ソースがあるわけじゃなくて
「24p/60i」混在ソースがあって、それを m2v.vfp/aui で「ソースフレーム維持」
読み込みすると「トップ/ボトム」混在で読み込まれるという話ね。

んで m2v.vfp/aui はレジストリにフィールドオーダー設定が見つからないと
（m2vconf.exe で一度も設定してないと）「ソースフレーム維持」と解釈する
というおまけもあるので注意してね。

本人の説明は説得力があるな

DGIndexでd2vを作る時も、片方のフィールドオーダーだけになるようにしてくれる。

WOWOWとBSJとDVDはDGIndex経由するのが楽

使い方の問題なのか。
たまに混在ソース云々って聞くから、普通にあるもんだと勘違いしてたわ。

放送規格の問題だな
放送規格で明確に規定されて無いから、どちらでも対応できるようにしないといけない

放送規格は単にMPEG2に準拠してるだけだから放送規格というより映像規格の問題。
現実的にはRFFとTFFのフラグの組み合わせだけで24pと60iを混在させることができることは
結構なメリットだと思うけど。再エンコする場合には不便極まりないけど普通は知ったことじゃないしな

トップ/ボトム混在って言葉の意味がさっぱりわからんのだが。。。
インターレースなら常に両フィールド入ってるじゃん？
TFF/BFFが混在って意味？？

>>743
そう

10bitエンコーダてきれいだね

ただ重い

そして汎用性が低い

自分のPCで再生できたらそれで十分と言う人には、比較的低いビットレートで、
綺麗なグラデーションを保持できるHi10Pは、非常に嬉しいだろうけどね。

グラデは微妙に改善するかなぐらいの効果だぞ
容量圧縮目的で10bitエンコードしてたけど
ストリーミングでスマホに飛ばすと再生が重くてやめた

ちゃんと16-bitでディザリングをすれば、結構違う。

http://screenshotcomparison.com/comparison/74479

>>749
おぉっ…
16bitってPhotoshopかなんかでやるの？

>>750
dither packageとかflash3kyuu_debandとかで、8bit->16bitに変換してスムージングをかけて
avs2yuvかavs2pipemodでraw出力してx264にpipeで渡す
もしくは　https://gist.github.com/1117711　をあてたx264.exeを使う

俺16bit表示出来ない液晶なんだけど
そういう事するメリットって何？
いや煽りじゃなくて何かいいことあるのかなーと

やれバンディングだディザだと騒ぐくせに、減色処理の基本すらもろくに知らんのか

俺に言われても

>>754
いいからそこへ座れ

>>752
8-bit YCbCr -> 8-bit RGB よりも 10-bit YCbCr -> 8-bit RGB の方が画質は良くなる。

いくら画質がよくなっても結局自己満足にしかならないんじゃね？
ウェブへ向けて違法アップロードとかやる人以外はｗ

見られたら後は画質を気にしないと言う人には、x264を使わなくとも、Quick Sync Video等がある。

たいていの人は画質とか圧縮率とか作業･視聴の手軽さとか作業時間とかの兼ね合いで
バランスを見てx264使ってるんだと思う

一度やってみたら分かるが、10-bitが8-bitと比べて特に面倒だと言うことはないよ。

ditherが難しい人には、flash3kyuu_deband(precision_mode=5)で、
手軽にx264 10-bitに渡すクリップを作成できる。

x264エンコーダで処理する10bit画像は、8bit画像を2bit左シフトするだけでも良い

精度が高くなっても必ずしも画質が良くなるとは限らないのが面白いところ

エンコなんて基本自己満足だろ
でも自己満足だからこそこだわっちゃうだ

ぶっちゃけこだわるのは音だけでいい。
映像なんてファイルサイズが縮んでさっさとエンコできれば画質は二の次で十分

だったらQSVでも使っとけよ

落ちるところまで落ちてもいいと言っているわけではないような
二の次で十分と言っているだけで

X6なんだが？

ID:WuVCfOEZ

Intelしか使わない奴がしきりにQSVを勧めてくるんだがどうにかしろよ。

ちなみにintel系のCPUのほうが映像にキレがあるね
AMD系でエンコする時は微調整が難しい ｷﾘｯ

二の次でいいのを押し付けてくるなよｗ

>>687

>カメラ　フレームレート : 120fps@320x240(QVGA), 60fps@640x480(VGA)

PSVita、カメラの仕様が↑なんだけど、コーデックも↓ってこと？
ビデオ − MPEG-4 Simple Profile (AAC)、H.264/MPEG-4 AVC High/Main/Baseline Profile (AAC)

というか、120fps@320x240(QVGA) ってどういうことだろう？
ハイスピードムービーってことなのかな？

興味なくはないけど、このスレで聞く事か？

大人の玩具としては面白そうだな

--threads 0でコア数の1.5倍を使ってくれるらしいけど
--threads の最大上限数はいくつなの？

4c/8tの2600で、--threads 16とか
論理コア数を超えるスレッド数を指定して速くなるのでしょうか？

やってみたけど速くならなかった

>>775
>x264 currently has an internal limit on the number of threads set at 128

http://mewiki.project357.com/wiki/X264_Settings#threads

>>772
120fps 明らかに3dを視野に入れてるｗｗｗ

なにげにPS eyeと同じ仕様だな。
ARのモーショントラッキングに使用するんじゃね？

>>778
3D関係ないだろ。

解像度に対してビットレートってどのくらいに設定するもんなの？

ああ、解像度*フレームレートだった。

あんさんの眼で見て満足できる画質になるギリギリのビットレート
を狙えば良いんでないかい？

>>780-781
1920x1080*60iで3000kbpsくらい

ソースにもよるしな

実写のアクション映画と萌えアニメだと、おなじ解像度・フレームレートでもビットレートは大違いだからな。

>>783
俺は5000くらい

俺はBDに1クール(アニメ)入ればいいと思っているから、10Mbps位にしている。

ありがとうございます。
とりあえずq値とかいうのを固定してどのくらいのビットレートになるか
試してみるのが良いのかな？

ソースが同じで解像度を落としてピクセルの数が半分になったら
ビットレートも半分くらいでいいとか、そんな単純な物じゃなかったみたいで。

>>788
試してみてとくに不満がなければそのビットレートに合わせればいい

crf使えよ

せやな

せやろか

おれ100kbpsだな

SSIM 0.98以上になるくらいと思ってたが実写だとどうなん？
TSをインタレ保持エンコするとcrf22で7Mbps割当てても下回ることが多々

実写インタレ保持ならcrf24くらいかな

実写で0.98以上は相当ビットレート盛らないと無理じゃね。tune ssim だと行くかな。

いっそTSのまま残せば？

SSIMの悪化が気になってたんですっきりした

BDに焼けるようにvbvで上限つけたらcrf盛ってもサイズほとんど変わらなかった

それもうただの固定ビットレートじゃん

>>800
どこが？以前としてVBRだが。。。

うわー…

夏なのに香ばしいなんて

凄いいい流れだね。面白いよ

おお…

>>803
夏祭りの焼きもろこしさんに全力で土下座な

香ばしいといったらイカかたこ焼きかお好み焼きだろJK
もろこしは、ただ臭いだけ

全部ソースににおいじゃ無いかｗ
そんなにソースが好きなら一平ちゃんでも食ってろよｗｗｗ

>>807
風の噂だが、マスタークラスのエンコ職人なら焼きもろこしの粒々をピクセルに見立てて
　　「ノイズ減らしてー」
とか高度な楽しみ方もできるらしいぞ。

そんな高度な深読みは思いつかないわ。

3D映画って48FPSなのかね
3Dにするぐらいなら60で制作すればいいのに

お前は何を言って…

8億5000FPSだよ

mpeg4同じ画質なのにデカ過ぎワラタｗ
h264小さ過ぎさらにワラタｗ
ビットレートについて語ってくれた方たちありがとう。

意味分かってねえだろ

mp4ってコンテナなんだがｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

Handbrake使ってるとかじゃね？

MPEG-4 AVC = H.264
H.264もMPEG-4の一種だよ

>>816
それはMPEG-4 Part 14。
>>814が言ってるmpeg4はMPEG-4 Part 2の事だろ。
>>817が推測してるみたいにソフトによってはコデック名にmpeg4と書かれてたりする。

なんにせよ>>814はそんなことはまったくわかっていないであろう・・・

>>811
3D映像は右目用と左目用で別々の信号を交互に出してるから実質2倍のフレーム数がある
それを右の時の信号のみ遮るフィルターと左の時の信号のみ遮るフィルターを通して3Dに見せてる
元々24×2fpsってのなら知らない

バーチャルボーイは時代の最先端を行き過ぎてたな。

うん、videoのコーデックとしてmpeg4とか書いて設定するやつ。

Angel Potion

>Automatic range handling (full vs TV) is in the works.

これはちょっと便利そうだな。

http://mailman.videolan.org/pipermail/x264-devel/2011-August/008768.html

r2074

きたか

TODOに書いてある
Different CPUs take different relative times for some functions. Is this enough (particularly across architectures) to justify different encoding settings for different CPUs?
が来るようだ

新AQまだかえ？

>>825>>828
つまりどういうことですか？

つまり地球は滅亡する

>>829
Komisar氏のkModビルドでも使ってみたら。

>>830
　>>825 自動レンジ調整は機能します。
　>>828 違うCPUは、いくつかの関数に対して相対時間差を持ちます。
　　　　　異なるCPU毎のエンコード設定で十分正しいですか？

さっぱりわからん。

in the worksだった。まだ実装されてないのか。

>>825
自動範囲処理(フルvsTV)は進行中です。

>>828
異なる中央演算装置は、いくつかの関数に対して異なる相対的な時間がかかります。
これは、異なる中央演算装置のために、異なる符号化の設定を正当化するのに十分(具体的にアーキテクチャの全域で)ですか？

自分もよく分からん。自動レンジ取り扱いが実装中と
CPUによってかかる時間が違うけどそのために違うエンコードの設定が必要だと思うか聞いてる？

AMDのCPUで相対的にエンコが遅いのを何とかしようとしてるとかだったり？

そんなことしてる暇があったらSubmeのエンコ速度上げてくれ
AMDなんて始まってもいないCPUだろうに

https://github.com/DarkShikari/x264-devel/commit/be12bfbc33e201203c8ddd95369fbf061e16019e
satd_x9（SSSE3以上が必要）とかいうのが実装されて、
それを使えない環境では速いプリセット使うと解析が早期終了するのに対して
使える環境ではsatd_x9が使用されて早期終了することはない
ということだと思う多分
数字を見ると早期終了しなくても遅くならないコードになってるのかな
正式にコミットされたら猫研でちゃんと翻訳してくれるだろう

要するにCPUによってエンコ結果が変わってくるかもしれない

>>838
ということは、おれのi7はキレが違うとか言う会話が出るようになるんですね？

楽しそうだなｗ

>>838
そう言うのは、GPUにやらせた方がCPUより速くできそうだが、これはなかなか実現しないな。

http://wiki.videolan.org/SoC_x264_2011#GPU_motion_estimation

GPUは融通の利かない職人みたいなもんだからな
相手にあった仕事を投げる分には抜群の働きをしてくれるが、こっちの都合に
合わせて動いてもらおうとするとなかなか噛み合わない

職人なんて言うほどいいもんでもなかろ
CPUを高校生10人とするならGPUは小学生1000人くらい
出来ることだけやらせるなら高校生よりも小学生の方が数の力で押しきれるが
・小学生にできることは高校生でも基本的にできるが、逆は真ではない
・メシ代（電気代）がかかる
・数が増えるほどまとめるのは大変になる

以下、下手な例え合戦がしばらく続きます

例えば、君がいるだ〜けで心が〜強くなれる〜こと
何より〜大切なも〜のを気づかせ〜てくれたね〜

こんな時、どんな顔していいのか・・・

死ねばいいと思うよ

通報しますん

>>838
後でAMDの俺オワタに成りそうで入れ替え出来ねえ（苦笑

RISC CISCの比較の時と同じような例えだな

素直に関心した

4:2:2 encoding support
キタコレ！

ベーコンチーズ♪ダブルバーガー♪

誤爆しました

>>852
マジかutl使いの俺歓喜

utlの話なの？
フィルターの対応も必要なの？

>>852
おぉっ…
ついに来たか。
これと10bitを併用すれば色の再現性はかなりよくなるのだろうか？

>>852,855
どゆこと？

再生のほうはどうなんだろう？
サイズと赤の劣化とか差どのくらいになるか気になる・・・

地デジとかをエンコする場合、yv12→yuy2→yv12だったのがyv12→yuy2で一つ変換が減ったということ？

元から4:1:1や4:2:2のDVをソースにする場合には、4:2:2を有効に使えそうだ。

変換してるなら劣化はするだろ

>>862
やり方次第
yv12→yuy2→yv12でもフィルタ使わなければ入力と出力データを同じにすることは出来る

どうやるの

猫科翻訳所さんまだですか

>>864
変換するときにプログレッシブとして扱うなど
補完をかけなければ同じデータになるけど
それをすることに意味があるとは思えない。
フィルタを掛けないのであれば
そもそも変換する必要さえないのだから。

4:2:2対応なら一部のutl使いは歓喜ですよ
バンディング対応とか確実に楽になる

>>867
バンディングに関係するのは、ビット深度じゃないの。

エンコ時間が伸びてファイルサイズも大きくなる上に
再生互換性下げるぐらいならソースのままで保存すればいいんじゃね
もっと言えば何でyv12ソースをそのまま扱わないの？

例えばTVを1280x720に縮小する場合は4:2:0よりも4:2:2の方が有利なんじゃないの？
リサイズしないのなら、少しの恩恵と引換えにファイルサイズが大きくなるだけかもね

yv12-yuy2-フィルタ-yv12 と yv12-フィルタ-yv12 で結果が違うからな

aviutlのフィルタをavisynthから使う場合
何か変わる事ある？
ないよね？

ぶっちゃけると、多少ひどい画質のエンコで仕上げても
画面から２〜３メートルぐらい離れて鑑賞すればそれほど気にならないから。

>>870
その論法だと、4:2:2ではなく、4:4:4がベストじゃないか。

>>874
うん、そうだね
YV24に対応してこそ神

>>871
リサイズはどうするの

YUVにはガンマ値の概念がないから
サイズ変更するだけで輪郭等色が混ざるところで暗くなるんだけど

LAV splitter を使用して動画を見ると、副音声がある場合、副音声が優先されるんだが
俺だけですかね？

副音声だけ日本語になってるとかないか？

特に片方だけが別の何か、と言うことはない。
よく分からんからHaaliでいいや

エスケイネット、1,920×1,080p/60fps対応PCIe x4 HDMIキャプチャ
http://pc.watch.impress.co.jp/docs/news/20110831_474202.html
非圧縮ブルーレイ1080pキャプチャ可能に。

>>877
俺も最新版にしたら副音声が優先されるようになったな
そのかわり字幕の表示ができるようになったからver戻す気はないけど

猫科翻訳所さん、まだでしょうか

>>880
http://pc.watch.impress.co.jp/img/pcw/docs/474/202/01.jpg

PCIe x4を1個占有するのに、HDMI入力は1系統かよ。貧乏くさいボードだな。

>>883
非圧縮でのデータレート計算してから
言えや糞が

いや同時キャプチャが欲しいってわけじゃないだろｊｋ

>>884
んなもん、適当にx264でエンコしたら同じやろ。

>>886
現在のスペックでリアルタイムエンコなんてさせたら糞画質にしかならんだろが糞が

x264が既に糞が質な件

自分のだした情報が不評でマジギレしとるがｗｗｗｗｗｗｗｗｗｗｗｗ

みっともないなあ

おお…　生tsが一番高画質と思ってるのがいるのか

もう秋田

わたしキレイ？

誰が切痔や！

10bit版でエンコしたものを簡単に再生する環境は？

mpcとかは対応できない？

LAV filtersを使えばどうか

>>895
最新版のMPC-HCかmplayer-ww(mplayer-lite)で再生してみたら？
VLCは再生できるらしいが行儀の悪いソフトだからあまり薦めないけど。

猫さん乙

どっかの企業がx264と契約して専用チップ作らないかなぁ
x86では例え新拡張命令に対応しても劇的な性能アップとか無理だろうし

１０コアぐらいのＣＰＵでフルパワーエンコさせれば？

商売絡んだらx264有料化しちゃうじゃん、今のままでいい

>>899
専用チップにするとなんかいい事あるの？？

>>901
x264を組み込んだTVMWは商用ソフトだが・・・

本家が有料じゃなきゃ別にすきにしてくれ

エンコの為だけに最上位のCPU買う人だって居るから
専用チップ載せたカードが3、4万でもそれなりに売れると思うんだ

ハードウェア処理って後からアップデートできないイメージ
チップが設計された時以上の性能は発揮できない的な
画質なんかどうでもいい速度こそ全てっていう人は今でもGPU使った
トランスコードみたいなのがあるしそれでいいんじゃ？

3、4万するなら俺はいらないな

画質最重視の人しかここに来ないと思うが

>>906
アップデート等を考えるとある程度汎用性をもった専用チップ・・・
あれ昔何処かでSpursEngineの載せたカードとかありましたねｗ

ソフトとハードは勝手が違うからなあ
そのまんま移植つーわけにはいかんしなあ
RTL書いたとしてFPGAで動かすにも結構大きいのがいるしなあ

>>841が実現すれば、それなりのGPUを持っている人なら、tesa相当の物を常用できる様になりそうだが。

ヒント：プラシーボ

GPGPUで処理できるのはあくまでビデオカード１枚につき１コア分だから
CPUより早く処理できるってのは言い過ぎ。

>>913
ん？

>>913
は？w

んほおおおおおお！！

>>913
ｋｗｓｋ

>>913
ｗｗｗｗ

荒れるなよ！
絶対に荒れるなよ！！！

おお…

また何か珍説来たか？

Submeは1が一番高画質
圧縮してないんだから当然！
こんなのどうよ

>>914-921
なにが可笑しいんだ？事実だろ。

最近のCPUでビデオカード１枚の処理性能が
CPU1個分の処理性能を圧倒できるわけないんだから
GPGPUなんて所詮気休めでしかない。

もしかしてCPUでビデオカードを作れば最強じゃね？

>>923
>>850

ごめん俺が大人げなかった。スルーすべきだったな

>>923
俺って読解力なさ過ぎなのかな。。。。日本語でおｋ

> 913 名前：名無しさん＠編集中[sage] 投稿日：2011/09/04(日) 20:36:05.69 ID:FW0oseam [2/3]
> GPGPUで処理できるのはあくまでビデオカード１枚につき１コア分だから
> CPUより早く処理できるってのは言い過ぎ。

これ、ちゃんと理解できているのか？

CPGPUはビデオカード１枚につき、ＧＰＵコア１個分の処理しかできないって言ってんだぞ。
それがCPUよりも早く処理できるならエンコ用途でCPUの存在意義なんてカス以下になるわけだが。

誤 CPGPUは
正 GPGPUは

vipみたいにくだらないレスであおるやつがいるので訂正しておく。

GPUコアってGTX580なら512コア、HD6970なら1536コアありまっせ

は？
ビデオカードのGPUクーラーの下にあるのは１個か２個だろ。
なに適当なこと吹いてんだ？

vipから来ました、記念カキコ

その理論だとハードウェアエンコーダ作っても1チップだとCPU以下になるなｗ

>>930
まずGPUとCPUが根本的に違うアーキテクチャであることを理解してからまたおいで

GPGPUが気休めって言葉にカチんときたわけか。思いのほかちっさい奴らだな

x264エンコでGPGPUのできることなんてせいぜいフィルタぐらいしかないもんな。
CPUをまったく使わずに、GPGPUだけでx264エンコできるのなら面白いが

ID:FW0oseam = ID:skyQ9Jdk

　　　　　　 　 　 　 　 　 　 、､､ , , _
　　 　 ,. -┬i＾i､._　　 　 ｨ`,､,､,､,､,.、'、
.　　 /　 　 | | .|=ゞ=､　__ｌ/＼　v~／!|
　　 l.　　　 ｌ ｌ l　＼＼{f‖ミゞ, ,ｨ≪:lf＾i　　　　　　もういい･･･！
　／ヽ.　　 ﾉ｢,ﾄ､｢.lﾍ‐iヾ|rｰ~r〉〉，こlﾚ'
/　 　 ｀ヽ//| ﾄ､ヽｌｲ| |/|{王王王王}ﾄ､
|　　　 　 ﾚﾆ| lﾆゝ冫! l!L_, , ,ｰ, , , ,_｣ｼ’、　　　　もう･･･
ヽ　　　 __|ーL|┴＾ｰヽ＞'＾ヾ二三シ´＼＼
　,ゝ,／　 .}二二二二二二二二二ｌヽ.　 ヽ ＼　　　休めっ･･･！
l/　|ﾄ､.／´＼　　　　　　　　 　 　 ||.　レ'´￣｀ヽ
　　||　!　 　 ､＼　　　　　 　 　 　 ||. /　　　 　 :|
　　||　|.l lﾞ!.|ｉ |ヽ)　　　　　　　　　 |l/　　 　 　 /　　休めっ･･･！
　　||　`ﾍ)U'J　　　　　　　　　　　/-─　　　,ｲ.|
　　||　　 　 ＿　　　　　　　　 　 /-─　　　/ ヽ|　　　
　　||　 r‐-ﾞ=っ｀ヽ,.--r-─ ''"´￣｀ヽ　　 /　　 }
　　||.　{三二　 　 |　│　　　　　　　　　 /　　 /
　　||.　 ヾ＝--一'`ーゝ　　　　　 　 _,. く 　 ノ|

ほんとガキだな。センスのわるいＡＡなんて貼ってんじゃねーよ

Main Conceptとx264を一緒くたにするのはあれだが、H.264の工程の中でも、
MEはGPUに向いている処理だと言うのは間違いなさそう。

http://pc.watch.impress.co.jp/docs/news/event/20100928_396462.html

>>937
　　　　　　　　　　´: /;二二二二二｀丶
　　　　　 　 /;: : :.:/ : : : : : : : : : : : : : : : ＼
　　　　　　/: : : : :/: :/: :/: : : : ハ: : :ヽ: :＼: ＼
.　　　　　/: : : : :,' : /: : {: : : : :ﾉ:ハ : : }: : : } : : ヽ
　　　　　': : :i: : :{__/ー┘￣￣　　 ￣｀ヽﾉ:j: : : : '
　　　 　 |: : :l: : :|　　　　_ノ~　　　ヽ 　　 �W: : : : |
　∧＿__j: : :| : l:|　＿__..二　　 　 ﾆ..＿　!: : : !:�W
　|　　　 | .: ;ﾚ:.八　 弋::::ﾉ　　　　弋::ﾉ ｀ﾊ: : :N
　｀ー一'| : {　（￣　 　 ¨　　　　 　 ¨ 　 ': :ﾚ'┘　ああそうじゃな。
　　　 　 |: :{＼ﾉ　　　　 　 　 　 '　　　　{: :|　　　悪いのはお主ではないの。
　　　　　|: :＼: ｰﾍ.　　 r､＿＿＿　 　 ,' : |
　　　　　|: : : :Y⌒ﾞﾄ 、　 `ー　-'´　　ｲ: : :|
.　 　 　 ,': : : /|　　|　 >　　__ , イ　 .|l : : |
　　 　 /: : : /│　 |　　　　　 /: : | 　 |: ∧|
.　　　/: : :_/ -|　　|　　 　 　 {rヘ| 　 |:│ |
　　 /ｘ<::::::::::Ｌ___j ＿　 　 　 ＼{＿_ﾄ│ |
　 /;　　ヽ ::::::| : : |　　 ヽ.　 / ￣|: : :|:::}｀＼
. /　 　 　 Y⌒| : : |〜ー─-〜─|: : :|ｰ|　　ヽ

とりあえずお前がGPUに過大な期待をしすぎてるだけだからこれ以上恥の上塗りをするな

>>934
誰もカチンとなんて来てないよｗ　おお…に変わる
新しいオモチャ来たー！ みたいな奴らが多そうだｗ

誰がGPUに期待してるって？
気休めにもならないようなオプションパーツでしかないのにｗ

>>941
ごめん、俺オモチャ来たーの方ですｗ

>>943
ちょっと前にEDCBスレで暴れてた真性と同じ臭いがするんで程ほどにな

>>938
GPUの特性からして大量の画素値の差分を取るのは得意そうだからな
上手いアルゴリズムを思いつけば総当りに近いやり方がそこそこの速度で出来るかもしれないな

>>930
おお・・・

>>930
目からウロコ…

>>930の理屈だとマルチコアCPUはたとえ32コア積んでようと1個ってことになるわけだが。
GPUは超並列動作させるのが前提で、その演算能力を生かせれば現状のCPUよりも高速に処理できるわけだし。
だから>>913はおかしいわけだ。

もっとも、GPUの汎用性はCPUより低いし、効率的な並列動作も難しいわけだからGPGPUが気休めと言われるのも仕方がないか？

そろそろ次スレ。rev33は気休めってワードでもスレタイにいれとく？

おお…？

ブレネリ

ヨーグルト

あな

伸びてるから期待してスレを開き、馬鹿襲撃にがっくりする


何度繰り返したことか……

crfを25に指定したファイルと、crf20に指定しつつzonesで全体をcrf25に指定したファイルでは
ファイルサイズが一致しないんだけど、なんでなんだぜ？

twitterでD_Sにでも聞いてみたら？

数値変えて何度か試したけど、直接指定のcrfとzones指定のcrfの平均値のcrf
に近い結果になるのかなぁといった感じ　質的にもサイズ的にも

LoiLoScope2のCUDAで品質固定なら結構早いらしい。
有料なのとCUDAなのが問題ではあるが・・・

nvidiaなんてCUDAらないわ
男ならradeonでATI Streamだろ。

LoiLoScope2とCUDAで検索すればでてくるけど
品質指定でエンコード出来るらしいんだ>CUDA
ATI Streamも対抗してくれれば万々歳なんだけど

CUDAのエンコって確かに速いけど画質の割に縮まないって聞いた
Intelのアレもそうだけど、確かに○秒でエンコ完了！ 爆速！ って聞くとやはり心が
動かなくもないけど、バランスを考えると最終的にはこっちに戻って来ちゃうんだよね

上記の画質で動画変換を行った場合、9600GTクラスでCore i7 3.3Ghz機よりも1.3〜1.4倍の速度が出てます。
CPUエンコした場合より1.3〜1.4倍高速。
x264と品質固定の数値が同じなら、ファイルサイズもほぼ同じ。
画質の劣化はほんのわずか(コントラストが低くモヤモヤしている箇所のみ)

ぼくんちTVからのコピペか。

>>899
CPUを載せた専用カードがほしいね
スペックはCore i7 2600k 、mem16G、 SSD128G、VGA Geforce GTX 580
こんな感じで

>>964
ふつうにそのスペックのpc買えばいい

Pen3の頃によく出回ってたCPUボードみたいなのを想定しているのかもしれないが
2600Kはそんな使い方はできないんじゃないのかい？

QSVで我慢しろい

スレチ過ぎる

まあでも>>841が実現できれば良いな
画質を落とさずに速度向上が出来るなら
それに越したことはない

それこそSSIMなどの値で比較すればいいのにスクショで比較しても
それはフィルタで誤魔化せるしあまり参考にはならん

H.265では、GPUも使ったエンコが主流になるかもよ

フィルタを設計する必要があるから

なんないでしょうね
GPGPUよりCPUへの内包のほうへ舵取っちゃってるし

世の中省エネ文化進んでるからな
グラボ込みでTDP100Wが基準になる時代だから

GPGPUなんて汎用性が薄いからスキモノだけがやってればいい

定期的にGPUに夢見る初心者があらわれるなこのスレｗ

仮想アドレスが共有になってMSのVS対応してからだから対応したとしても何年後かになりそう

MSのVSがC99に対応しない限りはx264のコンパイルはできないぞ
gccの対応がより重要

REGZA 55ZL2が出たし数年後には4k2kの時代が来るんだろうね
PCのスペックがコンテンツについていけなくなるお

そんな事よりIvyのAVX2は整数演算を強化するらしいがどの程度何だろ

流石に数年後はないだろ。
本格的な普及はUHDTV本放送開始の2025年以降じゃないかな。

PCではその昔動画なんて見れなかったけどな

GPUでのエンコードがダメじゃん、ってのは結局バスボトルネックが
きつくて使いづらいのが要因なのよね？たしか。

MainConceptの様に、GPUにはMEとか向いている事だけをやらせればいい。

バスボトルネックのないAPUに期待

そして今度はメモリ帯域がボトルネックに

それ以前に使用者のボトルネックが・・・

最大のボトルネックは視聴者の視聴時間

4Gamer.net ― 見えてきたAMDの次世代GPUアーキテクチャ。なぜAMDはVLIWを捨てるのか（Southern Islands（開発コードネーム））
http://www.4gamer.net/games/135/G013536/20110711007/
次の上位製品あたりからボトルネックはなくなる感じ
APU使ってるけど別に早いという感じではないかな。拡大縮小もcpuに振ったほうが早いし・・・

とりあえずh265が出てきてからだな。画質や速度のバランスだのはGPUエンコが実用的でない今語っても仕方ない
そもそもxの方がついて来ればだが

GPUエンコなんて性能出ない割に電気食いまくってひどい爆熱じゃないか

電気や爆熱は別にいいけど。性能さえ出れば

つまりそういう話をしてるんだが・・・

少々電気食いでも画質を犠牲にしないでエンコが早く成るならまぁ・・・。

画質を第一に守りつつ速度向上なら良いと思う

ワットパフォーマンスなんて気にしてたらx264はベターじゃない

GPUなんてマザボのおまけ程度のでおｋ

>>994
x264を使うのは大前提での話だよアホ

うめ

て

お

こう

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。