x264 rev14

□rev891.release02
・Psy RDOにBugMaster氏の修正分を適用。手元でShikari氏と最終計算結果を比較して見ましたが、
Shikari氏の懸念するケースはモード確定時点のRD_COSTが収束した段階でしか現れなかったので、
影響はないのではと思います。むしろdc_coefsの計算の方が数値的には影響度が大きいですが、
実際のエンコード結果は僅かしか変わらず…。
Psy RDOは、RD Cost( = SSD+λ*bits)の計算時に劣化度合（SSD）にMB画素の輝度の複雑さを加味する
ことで、画質劣化よりも符号化の効率性を重視する動きに抑制をかけるものです。（大雑把に解説すると）
言い換えると、映像が複雑でちょっと圧縮しすぎて他より劣化している部分にパッチをして、
画質を回復します。その分ファイルサイズが肥大化するわけです。

このとき、パッチをする量に固定値 5を掛けていましたが、各所でサイズが膨れすぎという話が
出ていたようですので、指定可能にしてみました。
--rdcmp の値に、ssd, psy以外に数値を指定可能にしています。（自然数のみ）
--rdcmp 5 がデフォルトとなり、Shikari氏のPsy RDOが動作します。1だとssdにほんの少しpsyの
効果を加える形になります。
この掛ける値（psy rate）については、ファイルのパラメータ部にも出力されます。


面白そうだ。

>>434
またテストエンコ漬けの休日になりそうだ

実はseraphy氏はオプションの自由度をあげて俺たちをテストエンコ漬けに
して喜ぶﾄﾞSなんだな！？

☆-(ノﾟДﾟ)八(ﾟДﾟ　)ノｲｴｰｲ

それを言うならseraphy氏じゃなくShikari氏じゃ

数値指定できるようにしたのはseraphy氏じゃないか？

とりあえず1から順に00のOPでテスト開始

OreAQ metic0 + psy1　が良い感じに思えた。

↑pacth判は使ってないからわからない。 OreAQ+psy5も実はやってない（ぉぃ

ー俺的眉唾チラシ裏ー
psy → ﾃﾞｨﾃｲﾙが保持される。　でも、ｿｰｽから離れる。(QP低いと)ｺﾞﾐ多し。
OreAQ → ｿｰｽに忠実。　でも、ﾃﾞｨﾃｲﾙはpsyの方が優秀。
OreAQ+psy→OreAQの傾向+ﾃﾞｨﾃｲﾙ保持。
　OreAQで拾えないﾃﾞｨﾃｲﾙ→psyで補完 psyで乱れる所→OreAQが先に拾っててくれてｲｲ(妄想

容量は ssd＜OreAQ＜psy5＜OreAQ+psy1　なんだが、RD性能的にも良いかと思う。
って、みんな自分で試すだろうから、こんな事書いても無駄だったかもしれん。

>>441
乙乙
様子見の人もここに居るのでありがたやし

おお、psyの強度指定いいね。
個人的には3を推奨かなぁ。　（patch版）
あまりノイジーじゃないソースなら１か２でもいいだろうけど、
映画とかフィルムグレインが強いソースなら３ぐらいが一番良かった。
ナイスパッチ！！

ほぼアニメしかエンコしない俺は
--aq-strength -0.2 --aq-sensitivity 8 --aq2-strength 0.3 --aq2-sensitivity 15
--qcomp 0.414 --rdcmp ssd
このままでいきそうです。
hybridAQ + psy で焙煎してる人っているのかな。

未だにr859で頑張ってるわ
r891で試したら、なぜか容量膨らんで謎
↓はDLNA経由でPS3再生用の設定（意味わからず適当）
--crf 20 --qpmin 15 --qpmax 35 --qpstep 6 --level 4.2 --scenecut 65
--min-keyint 1 --keyint 240 --bframes 2 --b-pyramid --no-b-adapt
--ipratio 1.70 --pbratio 1.50 --analyse p8x8,b8x8,i4x4 --weightb --trellis 2
--direct auto --ref 1 --mixed-refs --subme 7 --b-rdo --no-fast-pskip
--no-dct-decimate --no-chroma-me --deblock -3:-3 --8x8dct --me umh
--merange 32 --no-psnr --no-ssim --bim --threads auto --direct spatial
--me hex --no-cabac --nr 200 --cqm "flat" --filter 3:3 --progress --sar 4:3
--aq-mode 2 --qcomp 0.414 --aq-strength 0.2 --aq-sensitivity 8
--aq2-strength 0.3 --aq2-sensitivity 15 --aq-metric 3

--qpmin 15 --qpmax 35 --qpstep 6とか
--bframes 2 --b-pyramid --no-b-adaptとか
あほかと

じゃあどうすりゃいいんだよ？自称先生教えてください＞＜

>>445
ログ読もうな
--rdcmp　指定しない場合
--rdcmp 5状態だから増えるのは当たり前

--bframes 2 --no-b-adaptというGOP固定や、--deblock -3:-3 --filter 3:3 と意味不明なオプションを
指定している次点で、彼にはx264よりもXvidを勧めてあげるべき

ID:aa1HrQIq
いろいろと突っ込んでもらってよかったじゃあないか

>>448
んーr859では--help見てもないんだけど
もうオプションありすぎて着いていけないよ
２ちゃんお得意のまとめサイトもないし

>>449
ググってあちこちのサイトにあったの寄せ集めなんで

>>451
更新履歴とか-h見るのは当たり前として
このページでも何度かr889以降サイズでかくなったって
書いてあるんだからまずは確かめろいってる

>ググってあちこちのサイトにあったの寄せ集めなんで
羞恥心、ちょっと調べればopの意味分かるでしょーよ・・・
どうなるか理解すらしてないop付けてどうしたいんだよ('A`)

おい、seraphy氏のサイトハッキングされてるぞ…
ttp://seraphy.fam.cx/index.html

--qcomp 0.414
これreadmeに書いてある昔のまんまだな。その後の更新のとこ見ればその数値変えないと
駄目なのわかるだろうに…

>>454
huita ｗｗｗｗｗｗｗｗｗｗｗｗ

どんだけ脆弱なシステムなんだｗ
まあプログラミング以外は詳しい人ではなさそうだけど・・・南無

04WebServerステキとか書いてるから狙いやすかったのか？

Fukdome

日本製のhttpdなら、外人には脆弱性とか知られにくいからクラックされずらいのかと思ってたわ。
それとも、PHPとかPerlのほうを狙われたんかな。

何このオセロットｗｗｗｗｗｗ

一番安定してるのは何？

やっぱ最新？

r798

r798

r798に一票

r798

psy必要ないならr798一択

じゃぁ俺も798が良い

それじゃ俺もr798

僕はr798ちゃん！

わ、私もr798かな
あなたたちの真似をしたんじゃないんだからね！　ち、違うんだからね！

俺は826から使い出したから798は知らんが
とりあえず889で落ち着いている

漢なら黙って最新版！エンコした後で不具合に気付こうがそのまま押し通す位の覇気がなきゃね。

>>473
同意
そんなに安定言ってたらx264の楽しみなくなっちゃうじゃん

798から851へ
その後は最新についていっていたけど
886が気にくわなくて現在は883

--rdcmp 1が結構いい感じなので最新版が好み

何か890はPSY使っててもサイズあんまり膨らまないな。

890あたりからサイズが膨らむとか聞くけど膨らまないのはどのバージョンなんだ？
更新が早くて全てを試している暇が無い　orz
そんな訳でどいつが安定していてあまり膨らまないのだろう。
798がいいようなことを皆様書いているようですがいかがなものだろうか？

798がいいのは仕様が安定してbugfixしてたrevの最後だからね

889、890はやけに縮むけどなぁ・・・。

前のほうにも書いてあるがr889以降サイズ膨らむのは
434に書いてあるような機能が追加されたためであって
--rdcmp ssdで無効にするとサイズはむしろ縮んでる
ように感じた

常に最新版でいいよ
どうせまたbugfix連発になって安定版でてから移行して
オプションがわかりません＞＜とか言う屑ばっか湧くんだろ

デコードで難有りとかいつ報告されるかと思うと・・

最新版を試さずにはいられない
根っからのテスター気質

ﾋﾄﾊﾞｼﾗｰの報告一通り見てから最新版入れる俺ある意味乞食ヽ(ﾟ∀ﾟ)ﾉ

ガンダムOOのEDをPSYオンでエンコしたら
再生不可が高すぎてコマ落ち再生頻発。

・・・PS3なら再生できたよ。
まさかQ6600+GT8800で処理まにあわんとは・・・

ときどき再生できないって言ってCPUと一緒にGPUを書く人がいるけどそれってGPUの再生支援を使えるプレイヤーじゃないと意味ないよね

Q6600でffdshowとか言うなよ・・

スプリッタとデコーダとプレイヤー書いてない時点で釣りだと判る

Q6600なら、変な環境でなけりゃPS3より再生能力あると思うよ

PSY onでガンダム00EDエンコしてたの今見たけどCPU使用率10~15%だったよ
MPC＋CoreAVC1,65＋FFDSHOWフィルタ数種　[email protected]

同じビットレートならpsyの有無はデコードには影響しない。

psyオンにしたらビットレート上がるからね

>>494
ループしてるぞｗ

してねえだろ
>>493の前提が間違ってると指摘しただけ

ビットストリームは同じなのに負荷が変わったりするの?

>>496
いや、このスレの20日ぐらい前とループしてるｗ

>>497
お前以外は誰も同じビットレートとは言ってないからね。
理解しろよｗ

まとめサイトって無いのかな…
正直、把握しきれん…

この板にはx264を2passで使う人は少ないみたいね。

2passの質問してくるやつは草動画厨だしな

せめて3pass以上しないなら普通にcrf使ったほうがいいんじゃないの？

QBは時代遅れか…

>>503
3passよりは2passのほうが良いぞ。10以上やれば変わるんだろうけど必要十分な
ビットレート指定してれば2＞＞＞＞＞＞3だな。

同じ時間かけるなら適当なオプションでエンコした10passよりきちんとオプション練った2passのほうが
はるかにいい。それこそ今日の草動画ランクに200passやったとかいうのがあったがオプション見て唖然とした

回数たくさんすればするほど綺麗には確かになる
けど元ソースからはかなり違った意味で綺麗って感じするから
違和感感じる

3passするくらいなら2passのままで
--merangeとか--ref増やしたほうが効率良いよ
もっとも、わざわざビットレートを指定する理由が見当たらんがね
オプションの実験するんでもなけりゃ。

>>508
ニコニコ動画ならビットレート制限ぎりぎりにするために2passは使える。
…と言ってる自分がニコニコ動画用でも2passを使ってないが。

画質にこだわるほどじゃないけど一応とっておきたいアニメ1クールをDVD1枚におさめるのに2passは便利
まぁそうなるとx.264である必要もないのだが

マルチパスはレートコントロールを賢くするため使うけど
俺も２〜３passが限界だと思う
それ以上は掛ける時間と画質のコストが見合わないんだよね

>>506
お前さんの書き込みを見て私も見てみたが唖然とした。ﾉﾘで晒しておく

--bitrate 700 --pass 3 --stats ".\x264.stats" --qpstep 20 --8x8dct --partitions "p8x8,b8x8,i4x4" --bframes 2 --direct "auto" --subme 5 --me "hex" --merange 16 --ref 1 --no-chroma-me --threads 4 --cqm "flat" --no-fast-pskip

工エｴェｪ（´д｀）ｪェｴエ工工

自分で「高画質」とか入れる奴に限ってアホという法則

2pass以上使うと無理やりビットレートに収めようとオリジナルからかけ離れているように思う。
てか使う機会あんまり無いよな。たまにどうしても容量内に収めたいときぐらいだわさ

>>512
頭の悪さがにじみ出ているオプションだな。

このスレ口先だけの奴らばかりでワロタｗ

本当に知識があるならもっと綺麗な動画を上げてみろよｗ

まあたしかにそうなんだけど素人の自分がみてもこれはひどいってオプションだけどな・・・

せっかくpsyが使えるようになったのだから、--subme 7を使えばいいのに。
2pass以上ならビットレートがふくれると言うこともないし。

>>517
で、お前はいつきれいな動画を上げてくれるの？ｗ

高画質のプリセットをそのまま使ってればいいんじゃねぇの？
で気に入らないオプション削れば問題ないっしょ

x264guiの話しね

x264guiならデフォルトがこなれてていいぞ

HD解像度をデフォルトでエンコすると凄いボケボケになるよ

どんだけー

なんか891にしてからDXVAで再生できないな…

別に

すんまんせん、オプションミスってただけでしたorz

ギアスR2のエンディングが驚くほど縮まない。
OPが100MBぐらいになる設定でエンコしたら
EDだと200MB近くまで膨れ上がってビックリだ。

ベタ塗りじゃないから

輪郭もあるだろうな。

r892
msvc/iccのビルド問題が解決したのかな？

単にgcc依存のスタックが常に16バイトアラインされているという前提の関数だけ、MSVCで呼ばなくしただけ。
根本的な解決じゃねぇよ。

seraphy.fam.cxのドメイン死んでないか？

家鯖落ちてるっぽいな。

ttp://seraphy.luna.ddns.vc/~seraphy/index.shtml

>>532
それはVFR_maniac氏の修正。
seraphy氏のは、16バイトアライメントを要求する関数が呼ばれる前に、
アライメントを強制的に16バイトにしてしまう関数を追加している。
aligned.asmってアセンブラがそれ。

seraphy死んじゃヤダ

復活したみたいだ

チッ

2passで常に満足。

>>539
ワロタｗ

保存用にBフレームは使わないほうがいいの？

H.264のMain/High ProfileはBフレームを使うことを前提に作られた規格

でもやりすぎるとプレーヤーによってはブレるぞ

BDMV、BDAVのH.264規格でBフレームは何個までだろう。
どっかに載ってない？

MeGUIのSA-Blu-rayでは--bframes 3となっているが自分で試したことはない。

PS3での再生も考慮に入れつつ
Bフレーム3にしてる

ttp://www.watch.impress.co.jp/av/docs/20080701/sce.htm
いつかは来ると思ってたけど、以外に早かったね。

PS3はBフレームの枚数もだけどrefもネックになる事が多いよね

これなんてAV機器？

http://agehatype0.blog50.fc2.com/blog-entry-160.html
参照フレーム数やBフレーム数はこのあたりが参考になるかと。

--level指定して--refが多すぎるとDPBサイズ越えてるって警告出るよ

無難にb 3 r2でいいんでないの。

Level4.2 High profileのh264に準拠した設定してればPS3で再生できないことはないよカス

それは流石に無い

↑ミス

PS3だったら、720pならb3r4、1080pだったらb3r3くらいいけないかな

容量をけちりたいモバイル向けエンコが多いので2パスはよく使っている
ネタで100パス回したことはあるが画質の変化は微妙だった
多パスはレート制限のある中で本当に画質を妥協できない時専用だな
ニコ動はそれにばっちり当てはまるわけだが

それにしても、なんでニコ動の264はたかが512x384動画をHigh L5.1でエンコする奴ばかりなのか
MainとHighのビット効率はほとんど変わらないはず
(マトリクスを動画に合わせて気合い入れて練れば別だけど)

しかし512はおもしろいオプションチョイスだな
--no-chroma-me とかレアもんだろ

>>556
Highは8x8dctが使えるのでマトリクス使わなくてもMainよりは良くなるよ。
むしろマトリクスはニコニコくらいの解像度だと実写でもjvtよりflatが良い。
L5.1なのは単にレベル指定してないだけでしょう。

>>557
8x8dctって高解像度対応のためのものだと思ってたけど
ビット効率にも寄与するのか

ってDCTのマスが大きくなるんだからビット効率上がって当然か
俺ってバカ

>>558
HDに比べて使用率はだいぶ低下するけど、使ってる方がSSIMやPSNRが向上するよ。

まあニコニコにlevelやProfile制限ないしその程度で再生がもたつく
PCは少ないだろうからHighを避ける必要性はないな。

8x8マトリクスは周波数成分による量子化を
細分化できるから高解像度で威力を発揮するしな

http://ijiry.net/?engine=cda9c3fa33feec9fdffa1b7fbd0ca199&url=http://plusd.itmedia.co.jp/pcuser/articles/0806/30/news036.html
AVTだってさ。H264とは一言も書いてないが

変な転送アドレスなんか貼るなよ。ｷﾓﾁﾜﾙｲな

ttp://plusd.itmedia.co.jp/pcuser/articles/0806/30/news036.html

このAVTっていうAPIをx264コミュニティに公開はしてくれんだろうなぁ
公開されたって今まで培ってきたアルゴリズムとか色々すりあわせが難しいのかもだけどね

てか普及させたいなら全世界に公開すればいいのに何でしないんだ？

atiはやる気ない。まだnvidiaというかCUDAのほうが望みはあると思うけど
それもどうかわからないってところじゃないかなあ
PowerDirectorも対応してもおそらくPSP程度にしか使えないレベルだと思うし・・・

ソフトメーカーとの連携を教化しようとしてるんじゃね
うまくすれば業界標準取れるし
あとホイホイ公開すると野良プログラマー作の方が
市販品より速いなんてことが起こるからカッコワルイｗ

NVIDIAもCUDAじゃなくてDirectXだったら好感持てるんだけどな
汎用性無さ杉

野良プログラマーかっこよす

ageちまった・・・しにまorz

>564
ミスった。すまん

CUDA対応したっていうフォトショCS4には期待している。


だがスレ違い

RADEONにも対応してるけどね

でもスレ違い

シェーダーに直接流せるのが一番汎用的なんだけどね

スレ違いでもx.264のエンコ速度がいきなり20倍になったりするんだから凄いよなあ・・・

いやならないしx.264って何すか

おいおいPS3の新ファームすげえぞ、SDサイズでもやたらシャープに拡大して輪郭のジャギが無くなっていう事ないわ

あああの波表示マシンね

そういやインタレエンコできんだっけ

波?
最近PS3での再生も考えてlevel4.2でエンコしてる(まあ見るのはほとんどPCでだけど)

波？波っぽいものは何も出ないけど、モニタかPS3の設定ミスってるんじゃね？

PS3で再生するにはBフレーム数に制限とかあるみたいね
ってか4.2も再生出来るの？
4.1までかと思ってた

箱箱@4,1まで　PS3@4,2まで
PS3再生はref 3 b 3 で今のところ問題ない。
以前試した時はref8 b16までは再生できたけど、b16とかだとたまに映像が引っかかるような事がたまにあった

レスTHX、4.2は1920でref4までだから、規格より余裕がありそうだね
規格内でエンコする分には特に制限とかなしか

>>585
いや、誤解しないでくれよ　あくまで再生出来るのがref8b16だったってだけ。
画像が止まったりする事もあるらしいから、私は上記のr3,b3でやってるからね

無難に規格内に抑えてた方がいいと思うよ。　誤解させる書き方してごめんね。

>>580
できない

PS3が波表示マシーンってのはこのことだと思われ

PS3 v2.40アップデートで本体起動不能の報告相次ぐ、提供中止
ttp://japanese.engadget.com/2008/07/02/ps3-v2-40-defect/

>>588
ﾜﾛﾀｗ

HD48**シリーズでb-pyramidは問題なく再生出来るようになったんでしょうか？　Level幾つまで対応出来るんでしょうか。
スレ違いだったらスマソ

2600で-b-pyramidは再生できた。
4.1までじゃね？

>>589
UVDの問題より、PowerDVDのデコーダーの問題っぽい。
PowerDVD8の最新パッチを当てたらb-pyramidも正常に再生できた。
パッチは英語版のサイトのものじゃないとだめ(日本語版のサイトのパッチは古すぎ)

b-pyramidはデコーダ間の互換性を損なう元凶だから
使わないほうがいいけどな

-b-pyramid？


使うだけ無駄って結論出なかったっけ？

俺もいつからか外しっぽなｓ

seraphy氏版r897きたぜー

>>593
使った方がSSIMやPSNRは微妙に上がる。
でも互換性重視した方が後々良さそう。

BDプレーヤで再生できることを基準にしたい。

b-pyramidが問題になるのはaviの時だけじゃないの?

デコーダがｳﾝｺな場合も。
オプション自体は別に規格に沿ってないわけではないんだけど・・

>>598
それは遅延が発生する問題だから、muxするときに音声側に適切なディレイをかければ回避できるけど、
ここでいう互換性はコンテナに関係ない再生上の支障

そうなのか、もうちょいべんきょしてくる

http://cowscorpion.com/dl/x264.htmlのx264-569-install.exeを実行して、出てきたx264.exeを使って２パスエンコードしたらエラーログを吐かないで１パス目で停止した。
１パスエンコードは普通にできた。
手元にあった別のx264.exeを上書きしたら２パスもちゃんと通った。

これって２次配布元のデータが壊れてるってことでいいの？

そんな古いの使うなよ…

>>602
ネタ?

結構な化石rev

>>602
>>1を読め。

インストーラー付きのx264なんてあったんだ・・・はじめて知ったわw
ところで、x264.exeの本体以外にインストールが必要なものってあるん？

cowscorpionって信用できるのかね。
作者の意向とか無視して転載しているような気がするんだけど。

cowscorpion.comは漢だな

MPEG LA等のソフトウェア特許が有効な日本でああいうサイトをやるのは凄い度胸だ。

x264vfw系は大抵インストーラー付きだったとおもう
とりあえず818まではvfwあったのしってるけど
コマンド追加とかできないからあんまり使えないかなと

x264初心者ですまんがオプションの解説を日本語でしているサイトはありませんか？
なるべく詳しく書かれてる所を、探しても英語で書かれてるサイトはあるんだけど・・・

初心者を免罪符にすんな
ググれかす

>>612
longhelpの中の英語が読めないとこの日本では生きていけないなあ

>>612
テンプレ嫁

x264どころかＰＣの初心者って感じするがな
普通に探せばいくらでもでてくるし

俺と同じでおつむが悪すぎて
単語が思いつかないだけだよきっとｗ

x264 --crf 18 -o output.mp4 input.avsと言った単純なオプションでもそこそこの画質にはなるが
オプションの意味を理解して使いこなそうと思ったら--longhelpをよく読むしかないな。

もう全部のオプション憶えたし使いこなせるから

今のDTV板はこんな奴らしかいねーのかよ
探しても見つからなかったから聞いてるっつーのに

>>616
情報量が少ない
>>617
お前と一緒にしないでください

いきがっても英語もわからないって言う情けなさ大爆発

ほとんどのオプションは解説されてるサイトはある
だから見つからないのは探しかたが下手なだけ

そもそも情報量少なくとも多少なら見つけたのならあとは
わからないオプションをサンプル作って試して使うかどうか
決めればいい

それがいやならオプションが少ないDivXとかWMV9 VCM使えばいい

> 探しても見つからなかった

>>4

パッチで追加されたopなら
日本語で説明してる所がない、かもしれんな
まぁ、>>622の真ん中が一番良いと思う。

質問する
拒絶される
キレる←今ここ
荒らす

あー　書き忘れたがvfwな気がするからそれなら専用板いったほうがいいぞ？

某プラグイン開発者氏のパラメータの実験・解説日記はすっげー勉強になったな

x264は今のところガキ向けのコーデックだろ
PCを基準にすれば汎用性は恐ろしく低い

すまん誤爆

化石PCでダウソ乙

MPEG-2 Video以来となるISO/IECとITU-Tの共同規格よりも普及が見込める物が
他にあるのならそれは凄いな。

x264はコーデックじゃないと何度言えば(ry

ダウン厨なのかな
バカだからしょうがない

すまんH264な
ちなみにこんなファイル使ってるとみんなから嫌われてしまいますｗ
ここは屑どもの溜まり場だから仕方ないか
>>633
馬鹿って言う奴が馬鹿な

511 名前：名無しさん＠編集中 [sage] 投稿日：2008/07/02(水) 00:22:56 ID:XoKUJxJD
今日実写でもx264導入したがやっぱXviDに比べのっぺりになるな。
もしかしてx264ってアニメ専用？

515 名前：名無しさん＠編集中 [sage] 投稿日：2008/07/02(水) 10:12:00 ID:XytVsrIV
調整にかかる労力を考えると素直に実写は
XviD使った方が楽で満足できる画質になる。
それに実写に合わせて調整すると、せっかくの圧縮率も
霞むし。

522 名前：名無しさん＠編集中 [sage] 投稿日：2008/07/04(金) 16:12:46 ID:fXeQUIh5
出先の暇な時間にノートパソコンで見る機会が多い俺にはx264ｲﾗﾈ。
PCのスペックがどうとかじゃなくXviDと比べたらエンコも再生も話にならんほどオモ杉
その割に画質はたいしたことﾈｰのな。

なんていきがってみました。終わり。

低脳が増えたなｗ
x264歯、XviD歯、それでいいじゃね＾の
俺は納豆が好きだからお前も好きになれと言ってるよーに聞こえるぞｗｗ

因みにおれは無圧縮AVI歯た
なんせHDが4EBあるからな
EB=Exa Byte

>>625
下に行ってもすぐ対応するから大丈夫

>>PCを基準にすれば汎用性は恐ろしく低い
どういう意味か分からないな
むしろこれからの流れだとMP4,h.264,aacが主流になるだろうし
特にx264はオプションの自由度高いから、汎用性高いぞ

安い餌に食いつくなって

>>622
探し方が下手って言われてもニコニコとかZoome系の解説サイトならいくらでも見つかるんだけど
AviUtl実験室以外で詳しく書かれてるところが見当たらない（しかも英語）
今まではAviUtlでx264使ってたから自分でパラーメータ書いてエンコしたいと思っていたんだが

やれやれだぜ

>>641
このスレの住人は出し惜しみしかしないので期待しない方がいい

>>641
http://ageha909.blog121.fc2.com/blog-category-50.html
とりあえずオプション1個ずつの解説ページ。
aqとか新しいのは載ってないのが難だが。

>>641
そもそも↑のほうにも何度も書かれてるが4のリンク先だけでも大抵のオプションは
調べられるしちゃんと日本語でかいてあるよな　なのに一体何が知りたいというんだ？
新しいオプションがない？そんなのみんな試行錯誤して試してるんだから当たり前だって感じだしな

失礼した、4のリンク先よく見てなかった
これからそこをよく読んで勉強するわ
わざわざ教えてくれてありがとう

で、俺もその載っていないAQがよくわからんのだけど…

>>647
ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=all&namber=1477&space=0&type=0&no=0#1505

英語できないということは中学生以下か。でも辞書の引き方ぐらい知ってると思うが。

r899
　　Author: Eric Petit <[email protected]>
Update my email address

これだけでもrev upするんだな

ﾜﾛﾀw

工エｴェｪ（´д｀）ｪェｴエ工工

rev900に乗る前に1発ギャグをかましたなｗ

rev408は、引越しだったのかな

commit be6cce52d13fc6424e6244bfce03f67894c15d1e r408
Author: Mans Rullgard <[email protected]>
Date: Thu Jan 19 00:05:42 2006 +0000

I've moved

まあソース変更したらrevアップって言うが･･･

時代はx294だよ

>>656
期待してます

まあ今からだけど会社の連中で使ってる奴居ないな

900来てくれー！

なんかrev799(seraphy版)重くない？

ごめんrev899の間違い。

むしろメアド変更だけで使う必要はないだろｗ

変更点がメールアドレスで重くなるとか･･･

seraphy版の話なんでreadme見れば分かるけど、
> □rev899.release01
> ・BugMaster氏のvaq2mod.04を取り込み。
> 取り込み中のDiffを見て気づいたのですが、h->mb.i_chroma_qp は x264_mb_analyse_initで設定しているので、
> x264_adaptive_quantの中では不要ですね。

テストエンコしてログみたところ、crf25を指定してるにも関わらず、
QP12固定で動いてる。そのせいで重いように感じられるっぽい。

□rev899.release02
・inline展開にやられてemmsの発行前にfloatに値を入れる状態になっていました。
release01はAQを利用すると浮動小数点レジスタが正常動作しないため、公開を取りやめます。

seraphy氏のr899パッチ版のヘルプにaq-metric4の説明が載ってないな
追加し忘れなのだろうか？

metric4ってどんな効果なんだ？

某所からの転載で申し訳ないけど、
0. VAQ1.0相当。MB（マクロブロック）全体の輝度の分散を使う。
1. ブロックの中の1/4のピクセルに対して8x8ウィンドウ探索。VAQ1.0の12倍くらい遅い。
2. ブロックの中の1/4のピクセルに対して7x7ガウシアンウィンドウ探索。VAQ1.0の30倍くらい遅い。
3. ブロックの中の全ピクセルに対して7x7ガウシアンウィンドウ探索。VAQ1.0の120倍くらい遅い。

で、aq-metric 4は「aq-metric 0と同等の速度とaq-metric 3に近いSSIM品質を有する」らしい。
ただしseraphy版はAQが色々弄られてるので、この説明が合ってるかは自信なし。

もしそれホントならaq-metricは4だけでよさ気な気がするがｗ

deffみたら一応4追加はされてるみたい
ヘルプには確かに出ないんだが

>>668
弄ってあるのはOreAQの方。
diff見たけど、x264patchの--aq〜はVAQ2.0 modと同じ。
--aq2〜は単純に足し算している訳ではないので、aq2使うなら自分でdiff調べて。

>>670
差し替えきたよ。ヘルプ表示だけの修正らしいけど。

vaq2mod.04て、bug修正前のじゃない？

mod05
http://stashbox.org/150320/x264_vaq2mod.05.r892.diff

>>672
http://forum.doom9.org/showpost.php?p=1154712&postcount=4
Here is patch http://stashbox.org/150320/x264_vaq2mod.05.r892.diff (don't use. it has overflow bug) which calculates metric 4 as metric 0
(results will be slightly different from previous metric 4) with above described fix (so it has same speed as metric 0)

mod05にoverflowのバグがあるってことじゃ？

あー、わりぃ。Diffの中身ちゃんと見てなかった。
mod05はrev895の修正の元ネタになったやつで、MasterNobody氏がMetric4でそのロジックを実装して、
Shikari氏にレポートした奴だね。　rev985移行のMetric0と同じ実装になってる。
Fix bug in adaptive quantization
In some cases adaptive quantization did not correctly calculate the variance.
Bug reported by MasterNobody

mod04のMetric4はSADの結果をMacroblock要素としてSSDをとっているから別物でしょ。

>>672
バグ修正って、mod04に何かバグがあったの？

rev899.release02でも、--aq2-strengthや--aq2-sensitivityを指定すると
QPがqpmin値固定になるみたい。
--aq-strengthと--aq-sensitivityは指定しても問題なかった。
--aq-mode 0にしても治らないのでバグっぽいんだけど、他の人はどう？

>>674
05って書いてあったのでDiff内容も確認しないで早とちりしてしまったorz
・・・Diffも読めない(--;)申し訳ない

>他の人はどう？
お前さんの検証が終わるまでは899にしないことにします(;´Д`)ﾊｧﾊｧ

>>677
( ﾟдﾟ )

>>678
サンプルをください。　消せるロダでね

675の件はrelease03で治ったみたい。
> □rev899.release03
> ・MixAQの修正。
> Haali AQの関数の戻り値を変えたのに、途中で処理を抜ける場合を全然考えていなかったとか
> もうね。ダメだなぁ…orz

4000kbps 2passで、aq-metricの指定を変化させた時のPSNRとSSIM
ソースはテレパシー少女蘭のOP冒頭5秒(1280x720@24fps)
手元にソースこれしかなかったんで勘弁
--ipratio 1.7 --pbratio 1.5 --qpmin 12 --qpstep 8 --scenecut 70
--min-keyint 1 --keyint 240 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4"
--bframes 3 --b-pyramid --bime --weightb --direct "auto" --b-rdo --subme 7
--me "umh" --merange 32 --ref 3 --mixed-refs --threads "auto" --trellis 2
--cqm "flat" --no-fast-pskip --no-dct-decimate
--aq-strength -0.2 --aq-sensitivity 8 --aq2-strength 0.3 --aq2-sensitivity 15 --rdcmp ssd

[指定なし]
final AQ sensitivity: 7.9114
SSIM Mean Y:0.9820085
PSNR Mean Y:45.373 U:48.711 V:48.886 Avg:46.233 Global:45.929 kb/s:4140.21
encoded 120 frames, 2.89 fps, 4141.52 kb/s

[aq-metric 0]
final AQ sensitivity: 10.3074
SSIM Mean Y:0.9819008
PSNR Mean Y:45.362 U:48.696 V:48.871 Avg:46.221 Global:45.914 kb/s:4155.90
encoded 120 frames, 3.10 fps, 4157.21 kb/s

[aq-metric 1]
final AQ sensitivity: 8.0337
SSIM Mean Y:0.9819920
PSNR Mean Y:45.371 U:48.712 V:48.881 Avg:46.231 Global:45.928 kb/s:4140.96
encoded 120 frames, 3.06 fps, 4142.27 kb/s

[aq-metric 2]
final AQ sensitivity: 7.9064
SSIM Mean Y:0.9819919
PSNR Mean Y:45.370 U:48.708 V:48.879 Avg:46.230 Global:45.927 kb/s:4140.33
encoded 120 frames, 2.98 fps, 4141.64 kb/s

[aq-metric 3]
final AQ sensitivity: 7.9114
SSIM Mean Y:0.9820085
PSNR Mean Y:45.373 U:48.711 V:48.886 Avg:46.233 Global:45.929 kb/s:4140.21
encoded 120 frames, 2.90 fps, 4141.52 kb/s

[aq-metric 4]
final AQ sensitivity: 8.4580
SSIM Mean Y:0.9819953
PSNR Mean Y:45.367 U:48.706 V:48.886 Avg:46.228 Global:45.926 kb/s:4134.94
encoded 120 frames, 3.11 fps, 4136.25 kb/s

指定なしはaq-metric 3扱いになるのが公式と違う点。
patch版rev899使うならaq-metric 4を指定しといて損はなさそう。
OreAQ版だとまた違うかもしれないので、暇な人試してみて。

アニオタは氏んだほうが人類の為だよ

VAQは実写向けのオプションだと思う。

VAQは実写がターゲットだろ。

なんか設定晒ししてる人見てると
--ratetolを指定する人って見ないが
使わないものなのか？
３か４くらいに指定するといい感じなのだが

GPUエンコに対応してくれないかなー。

エンコ中に雷で停電しやがった.....地獄の季節だ

>>684みたいな事言ったから天罰でも食らったんじゃね？

>>689
http://tmp7.2ch.net/test/read.cgi/download/1215238218/687

>>689
自分とみてるところが同じとな！

>>687
--ratetolは1passビットレート指定と2pass以上のエンコードにしか対応してない。
--crfや--qpと同時に使用しても無意味なので、その場合は指定しないのは当然。

まじれすしてもなにももらえないよ

自己満足が得られます。他人からの感謝よりよっぽど素敵なんです。

>>693
返答多謝
1passビットレートにも対応してたのな
2PASSでも使ってないっぽい書き込みばかりだったから
使わないものなのか気になってたんだ

もう頭悪い書き込みはやめよーぜ

>>697
お前もな

捻くれすぎててﾜﾛﾀ

お勧めのインターレース解除フィルタ教えてください

BobかTDeint

afsも結構いい

けどそれってスレ違いだとおもうが

aviutlのインタレ解除って汚くね？

>>703
>>697

なんだそりゃ

ｒ900 Resolve floating point exception with frame_init_lowres mmx

坦々と900ktkr、べ、別に大きな期待をしてたわけじゃないんだからねっ

べ、別に日本語訳を期待してたわけじゃないんだからねっ

k.27.x264_vaq2mod.05.r892_and_old_4.diff (VAQ2mod by BugMaster/MasterNobody)

Code:
--aq-metric 0: Slightly differ 4-metric from BugMaster. Current in GIT
--aq-metric 1: Partial overlapped block variance.
--aq-metric 2: Partial overlapped gaussian variance.
--aq-metric 3: Full overlapped gaussian variance (slowest)
--aq-metric 4: New whole-macroblock variance (fast). Original last metric from BugMaster (default for this build)
--aq-metric 5: Old whole-macroblock variance (fast). Original old metric from BugMasterCode:
あまりaq-metric 5の意味なさげ

↑リンク：
http://forum.doom9.org/showthread.php?p=1156424#post1156424

x264patch.897.release01
--aq-metric 0
x264 [info]: SSIM Mean Y:0.9945008
x264 [info]: PSNR Mean Y:50.119 U:52.846 V:52.517 Avg:50.770 Global:50.093 kb/s:1276.45

encoded 34766 frames, 7.47 fps, 1276.66 kb/s


x264patch.901.release01
--aq-metric 0
x264 [info]: SSIM Mean Y:0.9957985
x264 [info]: PSNR Mean Y:51.707 U:53.959 V:53.726 Avg:52.267 Global:51.665 kb/s:2983.40

encoded 34766 frames, 6.80 fps, 2983.60 kb/s

--aq-metric 4
x264 [info]: SSIM Mean Y:0.9957995
x264 [info]: PSNR Mean Y:51.708 U:53.958 V:53.727 Avg:52.268 Global:51.666 kb/s:2984.98

encoded 34766 frames, 6.78 fps, 2985.19 kb/s

なんでこんな増えるの？crf17で--aq-metric以外は全部同じオプションなんだけど('∀`)

psy辺りが怪しい

>>710
両方ssdｯｽ。longhelpぱっと見では変なオプション増えてないと思うし（ちゃんと
みてないけど）なぜなんでしょう('∀`)

俺は891に上げたとたんにファイルサイズが増大したぞ。
PSY使ってようがSSDだろうが、891のがサイズ圧倒的に大きかった。

r901の更新って早く綺麗になるように計算方法変えたみたいな内容じゃなかったか？

でも>>709を見てみると、速度はともかく綺麗になったというよりも
qpを下げて平均レートが上がったのと同様という情けない結果に見える
これだとcrfオプションの意味がないような・・・

いいなぁ、6fpsも出るとか羨ましい…
所詮、3-4fpsしか出ないPhenomはダメな子ですか…

もう出勤と就寝エンコだけにしぼって9350eでも買うか…

エンコだけに絞るなら一番上のグレード買わないと！
エンコ時間が延びればCPUのワット効率以上に他のシステム電力が無駄にかかる。

クロック下げた省エネCPUで長時間エンコなんて間違った趣味に走ってる自作マニアが多い現実の悲しさ
P2P専用マシンにファン付VGAカード挿すような無駄

VFR maniac氏のx264_EXPERIMENTAL_rev901-release1を使用。
適当にアニメのOP(SD解像度)で検証してみたが、やはり不具合がある予感。
crfは24と30で検証。
↓使用したオプション 変態でｽﾏｿ
x264 --keyint 1200 --min-keyint 30 --scenecut 55 --bframes 8 --b-bias 50 --b-pyramid
--no-b-delay --ref 6 --fast-ref-search 0 --crf ** --qpmin 18 --ipratio 1.50 --pbratio 1.50
--aq-metric 4 --aq-strength -0.6 --aq2-strength 0.3 --aq2-sensitivity 10 --me imh --merange 32
--subme 7 --mixed-refs --bime --b-rdo --weightb --direct auto --8x8dct --trellis 2
--no-fast-pskip --no-dct-decimate --cqm jvt --level 3.1 --sar 40:33 --threads auto
--thread-input --progress

↓ --crf 24
x264 [info]: slice I:22 Avg QP:19.58 size: 35507 PSNR Mean Y:49.88 U:53.19V:52.51 Avg:50.59 Global:47.24
x264 [info]: slice P:925 Avg QP:19.88 size: 24555 PSNR Mean Y:44.53 U:47.87V:47.40 Avg:45.32 Global:44.60
x264 [info]: slice B:1240 Avg QP:19.68 size: 9463 PSNR Mean Y:44.70 U:48.11V:47.71 Avg:45.50 Global:44.08
x264 [info]: mb I I16..4: 20.6% 64.9% 14.5%
x264 [info]: mb P I16..4: 3.4% 9.8% 2.5% P16..4: 41.7% 12.2% 19.8% 0.0% 0.0% skip:10.5%
x264 [info]: mb B I16..4: 0.2% 0.6% 0.3% B16..8: 28.9% 2.2% 7.2% direct: 9.0% skip:51.6%
x264 [info]: final AQ sensitivity: 10.0448
x264 [info]: 8x8 transform intra:62.4% inter:43.2%
x264 [info]: direct mvs spatial:99.2% temporal:0.8%
x264 [info]: ref P 70.3% 12.7% 7.4% 3.6% 3.0% 3.0%
x264 [info]: ref B 78.0% 12.0% 5.0% 3.1% 1.9%
x264 [info]: SSIM Mean Y:0.9893653
x264 [info]: PSNR Mean Y:44.679 U:48.058 V:47.627 Avg:45.476 Global:44.317 kb/s:3089.71
encoded 2187 frames, 3.88 fps, 3090.80 kb/s

まぁゲームかエンコかで金かけるとこ違うからな
エンコマシンも安いVGAでおｋ
その分クーラーとかに金かけてOC時間短縮ｳﾏ

↓ --crf 30
x264 [info]: slice I:22 Avg QP:21.00 size: 33113 PSNR Mean Y:48.65 U:52.54
V:51.91 Avg:49.46 Global:45.58
x264 [info]: slice P:925 Avg QP:21.08 size: 22868 PSNR Mean Y:42.76 U:46.97
V:46.58 Avg:43.71 Global:42.73
x264 [info]: slice B:1240 Avg QP:20.00 size: 9149 PSNR Mean Y:43.01 U:47.26
V:46.98 Avg:43.97 Global:42.27
x264 [info]: mb I I16..4: 22.0% 64.7% 13.3%
x264 [info]: mb P I16..4: 3.2% 9.8% 2.3% P16..4: 40.3% 11.2% 18.2% 0.0% 0
.0% skip:15.1%
x264 [info]: mb B I16..4: 0.2% 0.6% 0.2% B16..8: 26.4% 2.0% 6.8% direct:
8.7% skip:55.0%
x264 [info]: final AQ sensitivity: 10.0448
x264 [info]: 8x8 transform intra:63.7% inter:42.7%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: ref P 70.4% 12.8% 7.3% 3.5% 3.0% 3.0%
x264 [info]: ref B 78.0% 12.1% 4.9% 3.2% 1.9%
x264 [info]: SSIM Mean Y:0.9851369
x264 [info]: PSNR Mean Y:42.961 U:47.188 V:46.859 Avg:43.913 Global:42.484 kb/s:
2914.08
encoded 2187 frames, 3.83 fps, 2915.18 kb/s

VFR maniac氏のr899でも同様の問題が発生。
r897では問題なし(ほぼ同じ設定でファイルサイズは半分以下,平均QP値は高い)

…しばらくr897で様子見することにする。
本家は大丈夫なのかな。

>>718
ところが最近エンコにもGPUパワーを使う動きが活発化してきているのだが
CPUとろくてもハイエンドVGA積んだ方がエンコ速度上がる時代がくるかもこないかも

まぁあまり安物のVGA付けると変な伸張してみる時見づらいけどな

昔ヌビディアとATIで恐ろしいほど明度とか色合いとか違ったが今でもそうなのかな
「あーこれヌビディアのカードでエンコしたろ！」みたいな差が付いたりしてｗ

投売りHD3xxxでウマウマ(´^ω^)

問題の箇所について、あまりemmsを何回も呼びたくなかったので、こんな感じで
修正してみました。

07.MixAQ.901.diff/12KB

seraphy氏　仕事が早い

>>721
どうだろうねぇAVIVOは使ってみたけど酷かったｗ
期待はしてるけど、まだまだ遠い気がする

エンコに使用するならCPUよりGPUの方が優れている面もあるからな
でもエンコードに使用するコーデックが糞ならどうしようもないな

r901すげーよおい

綺麗でしかも速くてうまいぞー

rev899(release03)とかわらん。

ヒント：オプションの値

どういじってもバンディングひどいの直らない・・・・
それさえなければ最高なのに

バンディング バンディング バンディング バンディング
あわててるぅ〜♪

x264patch.901.release02

x264 [info]: SSIM Mean Y:0.9967851
x264 [info]: PSNR Mean Y:53.044 U:54.819 V:54.608 Avg:53.498 Global:53.131 kb/s:4201.67

encoded 34766 frames, 6.72 fps, 4201.87 kb/s

しばらく897でいいや⊂(ﾟДﾟ⊂⌒｀つ

もうバンディングは諦めてGradFunkMirror()を常に使ってるわ
再生時に取るのがいいかもしれないけど、PS3や携帯機器でも見るからエンコ時に取っておいた方が都合がいいんだよなぁ

今まで2pass使ってたが、x264にはcrf＋ビットレート指定って手があったんだな
エンコ速くていいわ

>>735
それcrfをビットレート指定で上書きしたただの1passビットレート指定だから…

boy meets girl 出会いこそ 人生の宝探しだネ♪

ジャスラックの方からｷﾏｽﾀ

boy meets girl 恋してる瞬間きっとあなたも感じてる〜♪

すいません、質問させてください。
『b-framesの使用で1フレーム、b-pyramidの使用で2フレームの音ズレが出る』という記述を目にしたので
自分で何通りか試してみたのですが、実感できませんでした。
現在のバージョンではズレは解消されているのでしょうか？

>>740
VfWを使わなければ問題ない。

>>741
どうもです。
ということはx264gui.auoの最新ならcliしか含まれていないので関係のない話です・・・よね。

>>742
私はAviUtlは使わないけれど、MP4で出力出来るみたいだからそれで何も問題はないと思う。

x264 VFW gui専用スレ Part3
http://pc11.2ch.net/test/read.cgi/avi/1206102125/

>>740
Initial Delayのことか。
Haali Media Splitterだと無視されるから音ずれは発生しない。
Gabestのスプリッターやニコニコ動画のプレイヤーなどだと影響が出る。

音ずれでたらネラー得意の脳内補正しろよｗ

>>744
最終的な使用目的がニコニコなんで、試しにアップするなりして確認してみます。

1fpsの動画で試せば確実にディレイはわかる


某なんたら動画は板的に禁句だから出さん方が身のためだ

ディレイが入るとか、ゴミじゃん。

なんでそんなの使ってんの？

ちゃんと対策してれば全然問題ないからに決まってるじゃん

もう少し質問させてください。すみません。
5fpsの動画で試したところ、やはりディレイが発生していました。

いろいろ検索してみて、
ffmpegでヘッダを再構築する方法（白紙フレーム問題を解消？）を試してみたのですが、
ffmpeg（rev.14094 windows）のコマンドは通りmp4ファイルの出力もされたものの、改善はしていませんでした。

ディレイを取り除くにはどういった方法がよいのでしょうか？

>>750
ディレイを相殺する→エンコード前の動画「だけ」1フレーム(--bframesのみの場合)
または2フレーム(--b-pyramidを使っている場合)削る

これだけでいい。

MP4コンテナ側でディレイを消す→VFR maniac氏のx264cliで --no-b-delay

…というか>>750が読んだのは
http://www.204504byse.info/nico/index.html
これか？

--bframesを1以上に設定した場合、映像が1フレーム分遅れます。
また、--b-pyramidを使用した場合は映像が2フレーム分遅れます。

エンコードする前に、映像の遅れを相殺するようにavsファイル側で調整してください。

ここにも書いてあるが。

ズレた分だけ音もずらすって方法もあるよね

>>751 >>752
読んだのはまさにそれです。
やはり映像を少し削るか、音声を少し遅らせるかするのが楽なのでしょうかね。
対処療法的なところが少し気になっていました。

後者の方法も試してみます。

後者の方法というのは
> MP4コンテナ側でディレイを消す→VFR maniac氏のx264cliで --no-b-delay
こちらの方です。分かりづらくなりました。

勉強になりそうなので、この際いろいろ試してみようと思います。

あとはx264gui.auoで初期ディレイカット。VFR氏のやつと同じかわからんけど
某サイトのアップロードで弾かれることあり。

VFR氏の--no-b-delayとx264gui.auoの初期ディレイカットは同じ物。
guiの方は4倍精度が必須だったと思うんで、DTSの数値は違ったはず。
というか、VFR氏の--no-b-delayは同じく氏のtc2mp4Modからの派生で、
さらに元をたどればseraphy氏のx264afs.exeのハックを真似たものだから。
どっちにしても某サイトから弾かれるから音を遅らせるでFAだろ。

某サイトってﾆｺﾆｺのことか？
ﾆｺﾆｺって書けよ。

ニコニコ

ﾆｺﾆｺ

ﾌﾟﾝ

じゃじゃまるー

ぴっころー

ﾌﾞﾗ　ぽーろりー

ﾊﾟﾊﾟｯﾊﾟ ﾊﾟｼﾞｬﾏ

映像が遅れるとかゴミじゃん

音を遅らせたらニコニコ以外で逆に遅れるわけでしょ

なんでこんな重大な不都合が放置されたままなの？

実写にcrf20とかやるとえらい事になるのか
7GB→4GBって…

そりゃ物によるが、バラエティなら24辺りじゃないか？
スポーツは・・・('∀`)

実写ならSDはcrf20、HDはcrf25でやってる。
psyとかやると膨らむんでssd。
どうしてもpsyやりたいならpatch版のrdcmp 1にしといたらいいかも。

おれはcfr1しかつかわん

cfr1って新しいオプションですか？ ＞＜

初めてなのに釣れたー＾＾；

いやっほー

あ

い

＾＾

　　　　　　 　=＝=､
　　　　　／　,　―┴‐　､
　 　 　 　 ／／　￣　＼ ＼
　　　　　/ / .／　 　 ﾄ､ ヽ∧
　　　 　 ｌ ｌ /‐／/／/--! l　 ,
　　　　　ｌ ｌ |,ｨそkl／ｒうﾄﾚ| 　l　　　水樹奈々が>>777をゲットする時
　　　　　| lN. ヒｿ　　ﾋ:ｿ l ｌ 　ヽ　　 表の顔に隠された萌香のバンパイアの
　　　　　|人 ﾄ､　(　)　 ｲl/　　　＼　血が覚醒するのだ！かぷっちゅ〜　
　　　　　| 　 |　/<l+l>＼/l　　∧l　}
　　　　　l l　.lノ l<∀> l､＼　/　ﾘリ
　　　　　l/ (l／ﾉ　Y　 |. ＼l)
　　　　　 　 ヽ<＿_|＿_>／
　　　　　　　〈士士士士〉
　　　　　　 　 　|　_l. __l
　　　　　　　　 弋_ハ_ﾉ

>>766
ニコがごみファイルしか受け付けないだけ。

デコードディレイが発生するのは前方参照符号化を行う上で仕様。
MP4に準拠しているプレーヤーならEditBox(edts)を設定すればいいし、
非準拠のプレーヤーにも対応させるなら初期ディレイカットを使えばいい。
初期ディレイカットはDtsEditで簡単に付け外しができるし、互換性は高い
ので困らない。

ニコ厨は困ってるって？　知ったことじゃねぇ

このAA初めて見た

糞スレ化した時だけ加速するのは何とかなんないのかなｗ

OreAQを試してみたけど、アニメならデフォルトで十分なのかしら
OreAQって話題に上がらないからpsy含めた設定値よくﾜｯｶﾗﾈｰ

つ [可視化]

スレが伸びてると思ったら・・・

SSE4.1ありなしでエンコ時間結構違いますか？

そもそもSSEは2まで

16bit整数で実装できるH.264は画期的な規格

そうだったのか。意味無いのか。

ＳＳＥ３じゃないのか？
using cpu capabilities: MMX2 SSE2 SSE3 Cache64
ってあるし

SSE5はいつごろ搭載されるんだか

SSE999999999999999999まだー？

899以降、サイズが巨大化してるのって結局バグ？
それとも897とかで縮み過ぎてるのがバグ？？？

>>791
899以降がおかしい。
897まではほとんどサイズが変わらない。
原因が明らかにされてないから何とも言えないが。

899以降は指定したqpより遙かに低い値で量子化してサイズが膨らむから、
この数値でこれくらいの画質が出る・・・と解っている人には使いにくいんじゃないかな
crfとかで指定する数値がまったくあてにならないから
修正されるまで俺はスルーするつもり

ヒント：設定

901がおかしいのはEMMSの呼ぶタイミングが問題で、
SIMDからFPUへの復帰が出来てなくて小数点がマイナスになってたからでしょ。
それが原因でAQ後のQPが全部マイナスされて--qpminになってしまう。
x264patch.901.relase02で修正されてるけどね。

899以降膨らむという人は、--aqのデフォ値が変わったことに気づいてないだけ
なんじゃなかろうかと。
それか、修正履歴にはこうあるので--aq2だけ使っている人かな。
□rev901.release02
・MixAQの修正。（HAQ単独動作時のみ不具合）

うへぇ、そうなのか。
サイズ増えたつっても個人的には誤差の範囲だったから
901でエンコしなおしちゃったよ（´・ω・｀）
暗部にビット割く感じの修正だと思ってたorz

>>796
aqの強さ・闘値が増えるんだから結局はaqデフォで使うのなら
それと同じことになるとおもうのだが

>>797
ごめん、どういうことか分かりません。
もうちょっと詳しくお願いできませんか？

OreAQには関係ない？

作者の掲示板じゃなくて2chに不具合報告をしちゃうお馬鹿さんだからなぁ。
仕組みとか理解せずに、起きた現象をそのまま愚痴っているだけが大半。
>>709とか>>733なんかは設定すら書いてないから、オプションが悪いのかバグなのか判別つかねーし、
糞の役にもたたない便所の落書きと思うしかない。
そんなの参考にせず、自分で内容を理解して確かめた方がまし。

>>799
ない。つか、vfr_maniac氏がサイトでコメントしてるぞ。
seraphy氏共々OreAQがメインだからMixAQのバグはきちんと報告受けないと対処できんそうな。
逆に言えばOreAQの方は確実にバグ対応されるってことか。

>>800
�d
いつもエンコしてる番組（700〜800MBくらい）が急に900MB越えたもんだからこれかと思った。
単に圧縮しにくい映像だったのかね。

バグにあたっているかどうかは、ffdshowで可視化したら確認できるよ。
QPが全部指定した--qpminと等しくなっていたら大当たり。
そうでなければ圧縮しにくい（AQ結果が膨らみやすい）映像だったというだけ。

本家版しか使ってない俺には関係ないようだな
897も901もサイズ変わらなかった

何か変更があってもいいように使わない設定でもデフォルト値を指定しておけばいいじゃない

>>804
あ〜、俺それやってる
管理しにくいけど、何故か知らぬ間にそうしてた。

・seraphyさんのは、元に対して何かのパッチ(主に画像に関する)を当ててる。
・大抵、元x264の方がエンコが速い。
調べたり、比較した上で、大枠はこの認識で合ってる？

速度変わるの？
ICCは早いらしいけど。

patch.901.release02使ってみたけどバグは解消されててるけど
なんか897以前より暗部のブロックノイズ同じ設定でも多い気がする

crf値いくらにしてるの？

20

1.0

だから気がする･･･じゃなくてさ、同じソース使って同じ設定にして可視化してQP比較した上で
劣化してるって言ってくれないとただのチラシの裏だぞ。

同じソース使って設定も同じなのに暗部だけノイズ増えてるように
感じるといってる

OreAQ　rev897で今日もﾊﾞﾘﾊﾞﾘ安定安定
OreAQはデフォで結構いい効果だしてくれるからﾎﾝﾄ助かるわ

>>813
それは暗部の階調を保護しようとしてるんじゃないの？
ブロックノイズのことかな？使ってないのにごめんorz

>>812
俺も815と同じ意見。
階調保護が働いてるとザラついた印象を受ける場合がある。
PS3とかで拡大される場合にきれいになってるのを実感できるけど、
100%サイズでの再生だと汚くなった？と勘違いした箇所もあった。

とりあえず比較したいから画像うｐってくれ。

おまんこ画像ですよ

MixAQ

seraphy氏＆204504bySE氏、乙です。
CPU(AMD=SSE2Slow)に限るBUGだたようです。

インテルには関係ないけど・・x264patch.901.release03北〜！

>>818
AMDでがんばってる人もいるんだな。
なんにせよ解決おめ。

久しぶりに海外ドラマをエンコしてみたけど、crf15とcrf20でテストして悩んだ挙句、
ビットレート倍になっても画質差がそこまで無かった。
アニメとかだと分かりやすいけど実写だと分かりづらいね。

Seraphy氏ってE6600だっけ？

r905きたけど高速化だけなのな

>>821

>>708 ←k.27.x264_vaq2mod.05.r892_and_old_4.diff (VAQ2mod by BugMaster/MasterNobody)
付けてもらえば？

>>822
そのdiff意味ないよ。　そのdiffにのってるmetric4と現在のAQ1.0=metric0の主要箇所を比較するとね、
static NOINLINE int aq_metric_4( x264_t *h, int mb_x, int mb_y, int *satd ){
DECLARE_ALIGNED_16( static uint8_t zero[17] ) = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1};
for( i=0; i<3; i++ ){
sad = h->pixf.sad[pix]( zero, 0, h->fenc->plane[i]+offset, stride );
ssd = h->pixf.ssd[pix]( zero, 0, h->fenc->plane[i]+offset, stride );
var += ssd - (sad * sad >> (i?6:8));
}
return var;
}
static NOINLINE int ac_energy_mb( x264_t *h, int mb_x, int mb_y, int *satd ){
DECLARE_ALIGNED_16( static uint8_t zero[17] ) = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1};
for( i=0; i<3; i++ ){
sad = h->pixf.sad[pix]( zero, 0, h->fenc->plane[i]+offset, stride );
ssd = h->pixf.ssd[pix]( zero, 0, h->fenc->plane[i]+offset, stride );
var += ssd - (sad * sad >> (i?6:8));
}
return var;
}
こんな風に同じなの。>>674で既に説明されてるけど。
向こうでパッチを集めてビルドしている人たちって、案外微妙なのかな…
seraphy版には、ここでのMetric5がMetric4として実装されてる。

で、どれがいいんだ？

お好きなのをどうぞ

rev906@seraphyキター

なんでpatch版はoldに行ってないんだ？

どこみてんだ？
おまけにあるoldにちゃんとあるだろ

897〜901がpatch版だけoldに行ってない

> どうやらSSE2Slowと表示される環境下で、特定のロジックパスで問題があったようです。
> 問題のファンクションはHAQですので、VAQのみを使われている方は大丈夫ですが、
> ちょっと影響を受ける利用者が多いのではと思い、問題のある過去のバージョンは
> 公開停止しました。

これのせいじゃない？

906ずいぶんちっちゃいなぁ
Slow_mod4_stackが増えたな

amdで不具合出るだけでしょ？897〜901
今897のOreAQ使ってるけどなんか不安になってきたわｗ

OreAQにHAQはないんだから問題ないだろｗ

AMD環境で使ってるけれど、Phenom世代ならばSSE2Fastを使ってくれるようなので問題ないよ。

seraphy氏のMixAQビルドの最新リリースで、セキレイのOPエンコしたら
映像が壊れた…
rev889では以下のオプションで全く問題無いんだが、最新revで相当変わったの？

x264.exe --threads auto --level 4.1 --crf 21 --keyint 300 --min-keyint 1 --bframes 3 --b-rdo --ipratio 1.20 --pbratio 1.50 --aq-mode 2 --aq-strength -0.6
--aq-sensitivity 8.257 --aq-metric 0 --aq2-strength 0.3 --aq2-sensitivity 15 --qcomp 0.75 --deblock 0:0 --trellis 1 --analyse p8x8,i4x4,i8x8,b8x8 --8x8dct
--qpmin 10 --qpmax 38 --qpstep 10 --scenecut 55 --me umh --thread-input --cqm "jvt" --subme 7 --direct "auto" --merange 16 --progress --ref 3
--mixed-refs --weightb --bime --no-fast-pskip --no-dct-decimate --output "%~dpn1.264" "%~dpn1.avs"

>>835
ここでグダグダ言っても何も解決しないぞ
提出しろ 又は 諦めろ

ここがサポート掲示板だと思ってるようなやつには使いこなせないだろ・・・

>>835
--rdcmp ssdを追加してみな

seraphy氏に突撃する前にここに提出するのは良いと思うが。
質問の内容はアレだけど＾＾；

最近厳しい人多いな、昔はまったりしたスレだったが人が増えたからしょうがないか。

それはギャグで（ｒｙ

>>835
俺も889に戻したよ
それ以降は全部地雷だから安定するまで待つ

俺はチャレンジャー
どっかれでもかかってきやがれってんだ

--me esa　って無駄？

me esa/tesaやno_fast_pskipあたりは、ほとんどプラシボに近い。

それはキミが消費する時間に対する画質の向上が有用なものだと考えるなら無駄じゃないだろう

無駄といえば無駄　おれには違いがワカランかった
どうせやるならtesa merange64とか徹底すりゃ効果見えやすいのかもね

まぁx.264なんて時代遅れのものはもうどうでもいいや
今はSNOWだぜ

鬱だSNOW

VC-1はもちろん、SnowやDiracでもH.264に取って代わるのは厳しい様だ。

Most interesting open source
http://forum.doom9.org/showthread.php?t=139343

Question for codec developper about VC1, H264 and MPEG2 ratio
http://forum.doom9.org/showthread.php?t=139304

tesa merange64もやったけど、やっぱumh merange32で十分だった。

おまんげ32？

とって変わるのはまだ無理だろうな。
実験段階のコーデックで、将来的に圧縮方法変わる可能性もあるし。

そのうえ相対するのが世界標準規格とありゃ…数年は無理だな。

おまえら一度でもsnowやdiracを使ってみたことがあるのか。
圧縮率最悪だし、H.264なんて目じゃないほどデコードが糞遅い。

MEncoderやEncodeDiracで試した事はあるけど、ITU-TやMPEGが
DCT+デブロッキングフィルターで満足するのも分かる気がした。

画質はともかく容量変化は結構わかりやすいよ

最新は問題ありみたいな書き込みが多いんだがそうなの？

DiracとH.264は次世代のSHV放送で使われる予定
Diracは高解像度でようやくその力を発揮できるようになるとか

seraphy氏のパッチ版でＨＡＱに問題あったらしいけど問題あったのは大体削除されたらしいな
OreAQのmode1にすると俺の環境だと動作おかしいがまあ使わないしいいかなと

OreAQの906から絵が崩れるようになってしもうた

>859
kwsk

スレイヤーズをエンコしたんだがサイズが縮まない。
他のアニメだと200〜300MBに収まる設定でエンコしたら550MBになった。
解像度とかもそろえてるのに何でだろう？

塗りはビビットながら平坦で縮むと思ってたんだけど。

550MBになったと言われても設定も晒さないんでは分からんよ
家はSDだけどcrf20で219MBになった

psyってみんな否定するけどアニメに向いてる気がするのだが
-vaqとやりかたは違うが期待する効果は大体一緒だとおもうし

スレイヤーズ俺はＳＤのcrf２０で２５０Ｍになったな
-vaq+HAQ+pay3使ってるから結構膨む設定なのだが

このスレにいるのは人間じゃないからな。
奴らはPSNRやSSIMを盲目的に信奉する邪教に入信している。
PSYを使うと、PSNRやSSIMが下がるので嫌ってるわけだ。
人間の目はPSNRやSSIMで画質を見ているわけじゃないのに。

PSNR普通に0.996平均なのだけどね　それつかってても

実際の見た目より、PSNRやSSIMを重視する人には--rdcmp psyは向かない。

SSIMの間違いだった

□x264OreAQ.912.release01
・Psy RD 0.5を取り込みましたので、一部オプションが変更されています。
Helpを参照してください。
[--help]
--psy-rd　Strength of mode decision psychovisual optimization ["1.000000"]

名前が変わって、ﾃﾞﾌｫ値が1になったって事なのかな？

連レスすまん。　掲示板の方に詳細が貼ってあった。

誤情報流してしまったので、そこだけ訂正。

1. Much faster, by caching half the SATDs that need to be done.
2. Warn the user if trellis 1 is enabled--and disable trellis--if psy RD is on.
3. Psy RD strength is now a decimal value with default 1.0. Don't touch it unless you have good reason.
4. Psy RD strength now automatically scales based on quantizer. This is done internally--the "strength" is a multiplier to this internal value.

trellis切れってことか

2にしろ

psyで綺麗になったと言う人は、シャープフィルタかけて綺麗になったと言う人と同じ。
ただの心理的な問題で好みによる。

ソースに忠実＝綺麗ってわけでもないことを自覚しろよｗ

アナログボケソースにシャープフィルタは必須に近い

AVIUTL標準NR2種を強めにかけるとSSIM下がるとおもったら
0.008も上がったりとかフシギなことだらけ

そりゃあ細部が潰れていた方がフィルタ後の再現には有利だろ。

>>876
そりゃあフィルタ後をソースとした比較だからに決まってるだろ

>>870
trellis1派の俺涙目ｗ
ところで--psy-rdをデフォの1.0で指定している場合、
PSY効果は発生するのだろうか？

なぜ試さない

ID:ruDgYDYb

スミアやディテール消してツルテカ画質にしたいんですけど
オプションは何を変更したらいいですか？
NRやDenoise・Deblockをいじったんですけど決まった感じにならないんですけど

スレ違い

エンコードオプションじゃなくてフィルタで行うべし

なるほど。

--deadzone-intra 32 --deadzone-inter 32

あれ、31までだっけ？

trellisはちゃんとキットカットな

日本語でおｋ

夏はエンコ休業
今はひたすらカルビーとTMEでソース作り

俺･･･夏休みなったら、新オプションためしまくるんだ･･･

俺はカルピスの種つくりするか

--psy-rdは0でいくことにしたお

913北

meguiでアスペクト比を指定しても有効になってなくね？

少なくとも901では有効になってるよ
例えば、1.333で640x480とか

1:1にして480x480になったときは泣いた

夏が近づきオプションなど試す時間ができてスレが一気に進みそうなのは
いいけどガキが沸きそうでちょっと憂鬱だ

夏がくるとキャプしたものに幽霊の声とか混じったりすんね

そういや援交動画でリアルに霊が映ってんのあったな

--ghost 1

>>899

あー顔色の悪い霊がソファに転がってるのが見える奴だっけ

見てみたいな、それ。
アドレスうｐ。

霊奈は人間だってのｗ

3DNR強く掛ければ心霊動画のできあがりヽ(^｡^)ノ

すごく疑問なんだが、HD解像度で無修正の
えちぃ動画ってなんで見かけないんだろう？

どこかにHDエンコに情熱をかけてるエロいエロ〜い人は居ないかな・・・

あるじゃん

AV BDでぐぐれ

ぐぐったら(´･ω･｀)ｼｮﾎﾞｰﾝてなった
個人撮影がHDの時代へと昇華することを願う(-ω-)

だめだこりゃ

だめだこりゃ

x264_hrd_pulldown.06_interlace.diff

http://forum.doom9.org/showthread.php?p=1159737#post1159737

久しぶりにverアップしたらmeguiでアスヒ指定しても有効にならなくなったんだけど
Current positionで指定してもだめでcustom command lineのところに--sar 40:33って入れてもダメで
avsに
global MeGUI_darx = 16
global MeGUI_dary = 9
って書いてもダメだったんだけど
前まではCurrent positionのところで指定したら有効になってたのに・・・
どうやってアスヒ指定するの？

mp4box -add video.mp4#par=40:33 -add audio.mp4 muxed.mp4

もう一度やってみたら--sar 40:33で出来たよ
mp4boxでもできた(:parだったけど
でもmeguiは卒業した方がいいような気がした・・・
皆コマンドラインでやってるのかな

>>914
初心者の頃はmeguiで土台を作って
それに手を加えてました、俺は。

うはっｗ上級者ﾊｯｹｿｗ

1440*1080を16：9にするなら--sar 40:33で行けたな

たぶん

>>915
やっぱ何事も徐々にレベルを上げていくべきだよね

>>917
--sar 4:3じゃね？

ttp://www.wikihouse.com/htumenc/index.php?x264cli
ここ見て、画質上がりそうなｵﾌﾟｼｮﾝをひたすらﾓﾘﾓﾘ積んだな。　数値を選ぶｵﾌﾟｼｮﾝはとりあえずﾃﾞﾌｫを入力しておいて、後でいじる。
後は、まるも氏(2007/6-)やageha氏、なるP氏の所が相当参考になったかな。

何事もテストと確認の繰り返しだな
実際に映像を見て比較するのがポイント
PSYだのSSIMが役に立たない物が増えてるからね

1440に40/33を掛けたら、1745になる。

1440x1080を16:9にするなら4/3だっけか

うは…本当に1745になるな…
計算めんどくせー

1440 * 4/3(16:9), 704 * 10/11(4:3), 704 * 40/33(16:9)

PALやSECAMを扱わないのならこれだけ覚えておけば良い。

実験計画法とか使って最適パラメーター追求してる人居ない？

imasarakan

>>920
指摘の通り、一つづつ足して効果を確かめる事が必要。

>>925
追加しとくと、無効領域をcropしない時でも、720*10/11(DAR15:11),720*40/33(DAR20:11)。　スレ違いだけどorz

比率ってa×bって画像度をc：dに直すには
a×d：b×Cであとは最小公約数求めるだけ
例720×480→16:9にするには720×9:480×16
で240で両方割り切れるから27:32になると
そういうのを覚えておけば困ることはない

いいかげんアス比スレでやれよ
r914きてんぞ

更新内容の通知してくれるあの人、めっきり見なくなったよね。
さっぱり淋しいよ。

>>931
r-914
fix bs_write_ue_big for values >= 0x10000.
(no immediate effect, since nothing writes such values yet)

別に一人って訳じゃないし最近糞スレ化してたからじゃない

912に変えたら　--rdcmp　が無くなってるみたいなんだけど、
psyをOFFにしたい時の指定は　--psy-rd 0　でいいんだよな？

Strength of mode decision psychovisual optimization ["1.000000"]
ってあるしpsyの強さ設定ってことだから0にすれば切れるんじゃない？
それに聞いてるのならサイズ大きくなるんだから試せばわかるし
にしても0多いのってそこまで細かく数値設定できるってことなのかな・・・・

>>929
比の左と右が逆

psyって870見る限り-tと一緒に使えない上に
-hを見る限り-mの6以上も使えないんだよな
制約他にもありそうだし面倒そうだな

--rdcmp psyは--b-rdo --subme 7 --trellis 2と一緒に使えばいいだけだから、あまり難しくはない。

912以降の--psy-rdがってことね

>>939
すまん。--psy-rdと--rdcmpは、計算式が多少変わったものの、目的や作用する部分は同じなんだが。
そもそもRD Costの計算に手を加えるものだから、RDOが有効なsubme 6 以上じゃないと使えないって
だけだろ？ Bフレにも使いたければ--b-rdoを指定してBフレにもRDOを有効化してやればいい。
trellisは、RDOの量子化を行うものだから、使用する／しないの2択しか選べないってだけ。
最終モード判定時のみだけ使われたら、RD Costを弄ってしまっているから結果がおかしくなるだけだろ。
だから--trellis 0 または 2 のみ有効。
それだけじゃん。

しかしPsy RDは0.5でずいぶん使いやすくなったな。
デフォでエンコしても906以前のようにバカみたいなビットレートにならなくなってる。
理由はよくわからんが、906の--rdcmp ssdより912無指定（デフォ）の方がサイズが縮む気がする。

--rdcmp 1と--psy-rdを同じ強さにするにはどのくらいにすればいいの？

>>941
確かに散々考えたあげくに無指定だと妙にサイズが縮んで
何となく良い感じに仕上がったりした。

ああ、梅雨明けだなぁ。

>>942
--psy-rd 1.0
--psy-rd 0にすれば--rdcmp ssd と同じ

>>944
ん?
--psy-rd 0.2 ぐらいじゃないのか?
--rdcmp は 5 がMaxだったわけだし。

>>945
--rdcmp 5より--psy-rd 1のほうがサイズは小さくなるから
デフォルト自体が変わってるとおもう
にしても勘違いしてた　-m 6以上じゃないと使えないって意味だったね
-m 6以上で無効になるって誤訳してた

--rdcmpは駄目だなって思ったけど、--psy-rdは細かく設定できて結構使えると思う。

以下はともに704x480 24fps をOreAQ版 --crf 20
で--psy-rdだけを変化させたんだけど、

某エンディング
0.00 SSIM Mean Y:0.9933479 5.27 fps, 1527.60 kb/s
0.10 SSIM Mean Y:0.9933488 5.04 fps, 1529.77 kb/s
0.20 SSIM Mean Y:0.9933511 4.91 fps, 1534.79 kb/s *
0.30 SSIM Mean Y:0.9933480 4.88 fps, 1541.02 kb/s
0.40 SSIM Mean Y:0.9933349 4.92 fps, 1547.84 kb/s

実写混じりのアニメオープニング
0.00 SSIM Mean Y:0.9812308 2.30 fps, 3752.60 kb/s
0.20 SSIM Mean Y:0.9813650 2.24 fps, 3766.88 kb/s
0.30 SSIM Mean Y:0.9813991 2.24 fps, 3782.09 kb/s
0.40 SSIM Mean Y:0.9814119 2.15 fps, 3796.46 kb/s *
0.50 SSIM Mean Y:0.9814019 2.21 fps, 3810.67 kb/s
0.60 SSIM Mean Y:0.9813919 2.18 fps, 3828.21 kb/s
0.80 SSIM Mean Y:0.9813427 2.21 fps, 3856.62 kb/s
1.00 SSIM Mean Y:0.9812923 2.16 fps, 3888.83 kb/s

セピア調のアニメオープニング
0.00 SSIM Mean Y:0.9781302 4.39 fps, 1061.18 kb/s
0.05 SSIM Mean Y:0.9781328 4.11 fps, 1059.60 kb/s *
0.10 SSIM Mean Y:0.9781107 4.09 fps, 1059.24 kb/s
0.15 SSIM Mean Y:0.9780912 4.19 fps, 1060.86 kb/s
0.20 SSIM Mean Y:0.9780691 4.08 fps, 1062.88 kb/s

psy-rdを上げればサイズがでかくなるし重くなる。
全体をエンコするなら--psy-rdは0.1ぐらいでいいかなぁ。

psy-rd 0 派です。

SSIMで比較したら、Psy RDOはぼけているが歪みの少ないSSDに負ける。

いくら時間をかけても劇的な変化はない
鬱だSNOW最高！

>>948
fpsを見ると結局PSY RDは無しでいいじゃんって気になるな
seraphy氏も掲示板だか何かのreadmeだかで、
Psy RD作ってる人がcqm flat以外は認めてない人だとか書いてたし、
薄く掛ける程度のPSY RDなんて競合リスクを犯してまで導入する必要性は感じない。

どうせ自分か身内しか見ないファイルなんだし、自分の好きなようにしたら？でFA

とこで、
> seraphy氏も掲示板だか何かのreadmeだかで、
> Psy RD作ってる人がcqm flat以外は認めてない人だとか書いてたし、
こんなことは書いてなかったし、Psy RDとマトリックスは関係ないっと。
というか、readmeにわざわざPsy RDの仕組みを書いてくれた氏がうかばれない…

>>952
> Psy RD作ってる人がcqm flat以外は認めてない人だとか書いてたし、

そうなんだ。そんならOreAQでcqmがjvtな俺もpsy-rdは0でいいなw。

とりあえず自身が無くなってきたので、さくっと試してみた
使ったx264はseraphy氏の自動フィールドシフト対応版（おまけのやつ）

901r3 --rdcmp ssd
SSIM Mean Y:0.9898778
PSNR Mean Y:47.865 U:51.782 V:51.758 Avg:48.777 Global:48.161 kb/s:12751.80

913r1 --psy-rd 0
SSIM Mean Y:0.9898778
PSNR Mean Y:47.865 U:51.782 V:51.758 Avg:48.777 Global:48.161 kb/s:12751.80

901r3 --rdcmp 1
SSIM Mean Y:0.9895693
PSNR Mean Y:47.762 U:51.628 V:51.609 Avg:48.667 Global:48.060 kb/s:13090.73

913r1 -psy-rd 1.0
SSIM Mean Y:0.9895530
PSNR Mean Y:47.757 U:51.621 V:51.603 Avg:48.661 Global:48.049 kb/s:13094.54

901r3 --rdcmp 5
SSIM Mean Y:0.9894432
PSNR Mean Y:47.696 U:51.571 V:51.557 Avg:48.604 Global:47.986 kb/s:13716.98

913r1 -psy-rd 5.0
SSIM Mean Y:0.9894326
PSNR Mean Y:47.692 U:51.573 V:51.557 Avg:48.600 Global:47.980 kb/s:13739.74

あぁ、俺は--psy-rdのMaxが1.0だと勘違いしていた。
>>944氏すまんこ。

seraphy氏のreadmeを補足するのも気が引けるが…

　　　　　　　　┌圧縮の前後を比較して、劣化した度合い
RD_Cost = SSD + (lambda * bits)
　　　　　　　　　　　　　　　　　　└圧縮した時のデータ量

こういう計算をした結果のRD_Costが最も小さい圧縮モードを選択するのがRDO。
SSDは圧縮率が高ければ高いほど数値は大きく、(lambda * bits)は圧縮すればするほど小さくなる。
ただ、SSDよりbitsの方が数字の桁、変化量ともに大きいから、この計算を行うと画質が少々劣化してもデータ量が
少なくなるモードを選んでしまう。
そして、これと似た計算をPSNR算出でも行っているから、RDOってのはPSNRが最もよくなるモードを選択している、
と置き換えることもできる。

Psy RDってのは、RD_Cost = (SSD + psy_cost) + (lambda * bits) という計算をして、SSDを大きくすることで画質が
劣化するのを防ぐ仕組みなの。
psy_costの計算方法がver0.3とver0.5で違うから、同じにすることは出来ない。

一番重要な物が抜けてた
ソースはPV3 1440*1080でガンダム00の予告部分に
自動フィールドシフト・FaeryDust・YPbPrゲイン・ColorYUVを使ってPS3用に調整した物

--crf 20 --level 4.1 --bframes 2 --ref 2 --mixed-refs --b-pyramid --subme 6 --aq-mode 2 --aq-metric 3
--aq-strength -0.4 --aq-sensitivity 7.625 --aq2-strength 0.3 --aq2-sensitivity 15 --qcomp 0.7 --cqm "jvt"
--qpmin 12 --qpmax 26 --no-fast-pskip --8x8dct --partitions p8x8,b8x8,i4x4 --me umh --no-dct-decimate
--threads auto --thread-input --progress -o

>>956
Doom9のPsyスレを見るきっかけになったので、問題なしっす
別物だという事も、はっきり解りましたし

>>957
そのRD_costの計算の際にcqm flatとそれ以外を指定した場合で何らかの差異が生じることをさして、
Dark Shikari氏は「カスタムマトリクスはRD最適化を混乱させる」って考えてるんじゃないのか？
cqm指定によってRD最適化を判断する計算結果自体が変わってくるのであれば、
Psy RDがカスタムマトリクスと全く無関係とも言えない気がする。

VAQの作者としてflat以外のcqmは必要無いと言っているのだろう。

前皇走査質かとおもた

ん〜、世の中には、高周波（マトリックスの右下）の数値を255とか馬鹿な設定する人がいるんだよ。
そうやって高周波のデータを削り捨ててしまうから、その後にPsy RDで回復しようとしてもどうにも出来ない。
そういう可哀想な人にわかりやすく説明するには、cqmを使うなっていうのが一番なんじゃないかな。

>>959
カスタムマトリックスも影響するし、qpだってPsy RDに影響するよ。
でも、それで基本動作が逆になることはないから。
（Psy RDの効果が150%になったり50%になったりブレはするけど、マイナスにはならないって事。）

jvtよりflatのがいい場合もあったのか・・・

アニメに関してはflatの方が良い。
実写でもSDだとflatの方が良い場合も多い。

そもそもx264のSSIMは間引きされて計算されてるから細かい数字比べるのは微妙なんだよね

アニメでもガンダム00の宇宙空間とかはjvtでないとブロックでるよ

主とするのがSDの実写だわ・・・
ここんとこ全部jvtだったから今度比較してみるか

flat、jvt、+VAQ、-VAQ+HAQ、内容によってどれが最適かは異なる
だから実際に見比べてみるしかない

SSIMは端折ってるので0.01未満の精度は確定されていない
.980と.970なら前者が上だが、.980と.975なら前者が上とは言い切れない

未満の意味が分かってない人がそんなこと言っても・・・

バンディング無くなったら教えてくれ

設定しだいだろ…。

バンディングはどういじってもx264の設定ではなくなりはしないとおもうけど

なぁにソースからグラデーションをなくしてしまうフィルタをかけてしまえば良いさ

そろそｒ次スレ立てるか

じすれ：

x264 rev15
http://pc11.2ch.net/test/read.cgi/avi/1216472408/

とりあえず--psy-rd使うのなら-m 6以上使えってことだったので
5から6に変えたら動画が崩壊するようになってしまった

夏だねぇ

一般的に、今日から夏休みらしいからな。

工学部的にはこれからテストだけど

バンディングは単に帯域不足かソース自体に既にあることがほとんど。

クラッシュバンディング〜

つまりデジタル放送、特に地デジが帯域不足ってことか

とりあえず新スレのサイト紹介とかは乗せる前にリンク切れになってないか
調べるべきだなとおもった
バイナリとか半分くらいしか表示できないし

↓以下お前がやれよ禁止

埋め

う

そろそろ

埋めですねぇ

梅

うめ

生き埋め

x264 rev15
http://pc11.2ch.net/test/read.cgi/avi/1216472408/

うめ

死に埋め

ume

ume

ume

↓どうぞ

(ﾟДﾟ)ｳﾒｰ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。