x264 rev14

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

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

[本家]
http://www.videolan.org/x264.html
http://trac.videolan.org/x264/browser/trunk (ソース)

[バイナリ]
http://x264.nl/
http://forum.doom9.org/showthread.php?s=&threadid=89979
http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/
http://oss.netfarm.it/mplayer-win32.php (mencoder)
http://forum.doom9.org/showthread.php?s=&threadid=87567 (MeGUI:mencoderのGUI)
http://tirnanog.fate.jp/mirror/gpac/dev/　(mp4box)
http://yamb.unite-video.com/　(YAMB)

前スレ x264 rev12
http://pc11.2ch.net/test/read.cgi/avi/1207062562/

再生方法、規格、インタレ規格、Avisynthの使用法、コンテナ等、
専用のスレがある話題は各専用スレ>>2-5でおながいします。
スレタイ検索 http://find.2ch.net/

テンプレ続く>>1-5

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

Avisynthの話題は
Avisynthを絶讃ιょぅょ Part25
http://pc11.2ch.net/test/read.cgi/avi/1206362521/

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

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

MeGUIスレッド
http://pc11.2ch.net/test/read.cgi/avi/1164533110/

[FAQ]
Q x264.exeをダブルクリックしてもインストーラーが立ち上がらない。
A コマンドプロンプト用の実行ファイルです、インストーラーでも圧縮ファイルでもありません。

Q 見れないよ
A x264.nlでmatroska splitterとffdshowを入手してインストール汁！ハードウェアでインタレ解除する場合は、
　　ビデオデコーダーの設定→出力→インターレース関連情報を…にチェックを入れること。
　　またはMPlayerやVLCなどのデコードエンジン内蔵のプレーヤーで試す。 これらで見る場合はffdshowは必要なし。

Q AviUtlやVirtualDubとかで読むとエラーでて編集できないんですが・・・
A 諦めろ。編集はエンコード前にするのが常識。

Q Win版QuickTimeで再生できない。
A　QuickTimeはインタレ、ハイプロファイル(-8、--8x8dct、--cqmなど)、--b-pyramidに対応していない。 Bフレ1以下推奨。

Q 携帯機やゲーム機などで再生させるには？
A　それぞれ専用のスレがどこか（他の板も）にあるはずなのでまずは当たってみてください。

Q バージョンアップ早すぎ
A バージョンアップでなくビルドアップです。例えばソースの清書、サイズの収縮などユーザーにとってあんまり意味のない改変でも更新されてます。

Q >>1のどのファイルがいいの？
A 迷う奴はx264.nlのを使え。GUI操作が好きな人は同ページにあるMeGUIやStaxRipも。マイクロソフトから.NETのインストールも忘れずに。

Q　エンコードできない。
A　基本的に色空間がYV12のavsファイル(Avisynth)しか受け付けません。（MeGUI、StaxRipも含む）

Q　MP4のVFRってどうやるの？
A　前知識として、そのまま"MP4 VFR"等で検索して、ISOMPEG-4スレへどぞ。

Q　アスペクトの指定ってどうやるの？
A　704x480を4:3で見る時は--sar 10:11、 720x480を4:3で見る時は8:9。他は各自計算してください。
　　720ｘ480を16：9で見たい時、par(sar)x：yはx：y=480×16：720×9で求められる。

Q　--interlacedで失敗する。
A　入力ソースは縦が32の倍数のトップフィールドファーストで。

その他パラメータの勉強は
ageha
http://agehatype0.blog50.fc2.com/
QPオプションの目安
http://www.wikihouse.com/htumenc/index.php?Man%2FCODEC%B8%C7%CD%AD%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3%2F-x264encopts%2Fqp

aviから移行してきた人への簡易見本。704x480の24pと仮定。
Avisynthの2.5以降のバージョンをインストールする。
mp4boxを用意する。
映像は可逆圧縮コーデックでaviを作成する。
音声は別に作成しておく（C:\hogehoge\test.m4aに存在すると仮定）。

echo AviSource("C:\hogehoge\test.avi") > "%temp%\avi.avs"
echo ConvertToYV12() >> "%temp%\avi.avs"
"C:\hogehoge\x264.exe" --crf 20 --progress -o "%temp%\avi.264" "%temp%\avi.avs"
"C:\hogehoge\mp4box.exe" -fps 23.976 -add "%temp%\avi.264":par=10:11 -add "C:\hogehoge\test.m4a" -new "C:\hogehoge\test.mp4"

↑の4行をコマンドプロンプトに右クリ貼り付けenterで完成

↓batファイルにD&Dするだけ用

set x264="C:\hogehoge\x264.exe"
echo AviSource("%1") > "%temp%\avi.avs"
echo ConvertToYV12() >> "%temp%\avi.avs"
%x264% --crf 20 --progress -o "%1.264" "%temp%\avi.avs"

スレ建て終わり

ごめんなさい>>1の前スレのタイトル直してませんでした。アドレスはあってます。

スレ埋まる目前に加速するもんだからびっくらこいた

これは>>1乙ではなくて、わっちの自慢のしっぽじゃから勘違いをしないでくりゃれ！
　　　　　　　　　　　　　 |＼　　　　　　 |＼
　　　　　　　　　　　　　 l lヽ`-‐ '´￣ ｀ヾゝヽ　　つ
　　　　　　 　 　 　 　 　 ｼ~　／" ｀ヽ ヽ　 `､l　　　　　つ
　　　　　　　　　　　　　//, '///|! !‖ ヽﾊ　､_ヽ　　つ
　　　　　　　　　　　　 〃 {_{＼」」 Ｌ|l|／ﾘ ｌ │ |ヽ　　　つ
　　＿＿＿＿.　 　 　 ﾚ!小ｌ●　　　 ● 从　|、|　）
　く　　ﾉ::::::;;;;;;＼. 　 　 ヽ|l⊃　r‐‐v　⊂⊃　|ﾉﾊ´
　　￣￣フ;;;;;／　/⌒ヽ__|ﾍ　　ヽ ノ 　 　j /⌒i !ヽ
　　　 ／;;;;／　　. ＼ /ヽ.|　l＞,､ __,　イァ/　 ///ﾊ
　　／;;;;∠＿＿＿　/ヽ./|　|　ヽヾ、　/,{ﾍ､__∧/ﾊ !
　く:::::::::;'::::::;':::::::;'::::::7ヽ< } / 　 l丶× / ヾ l　l''ﾊ∨

>>1
いっちょつ

俺も前スレ>>1000と一緒だな

DVDフィルタ無しか、3D輝度少量のみ　地デジFaeryのみ　アナログはﾁｮﾒﾁｮﾒする
インタレ解除間引きはそれぞれ適材適所　リサイズして終わりな感じ　
TMPGで手動最強と思ってたけど、禿げそうだからもうやってない

デジタルならノイズ除去など不要になる
そう思っていた時期もありました･･･（AA略

最近はノイズとか気にならんけどなー

アニメだと気になるのか？

>>8
俺はそれじゃ絶対納得しないわ
昔のアニメのDVDは大抵色が煤けてるから色や輝度調整するし
ノンテロップが色調整されてる事が多いから、それにあわせて左右並べて調整する
フィルムのゴミもアニメなら取ってしまうし（グレイン残す必要ないし）
最近のエヴァ見たいなのはグレイン消して、色をグレイン乗っけてないのとつき合わせて調整した
大体CMと同じ色合いとテカテカ感になったから満足。まぁオナニーに近いが

え〜、むしろノンテロップ版のほうがなにも修正されてないフィルムじゃなくてVHSあたりから
取ってきたろ的なのが多いじゃん。

前スレエヴァの大バカですorz

ひとまずNRを止めたところ改善兆候が出ました。
ただ前スレのようなきれいな画質にはならずorz

あれってやっぱりオリジナルマトリクス…ですよねぇ。
あのあとjvtやらflatやってみましたが余計悪化しただけでした。

メモリアルボックスは大抵ノンテロップだけ色補正されてる。他はもとのまんま

>>10
地デジだと元はこんな状態になってるからな
ttp://www.vipper.org/vip835209.png

>>15
うわっ、なんじゃこれ・・・ひでぇなｗ

紅のそこひどいよね。　今期は図書館も似たような感じだった

>>1乙

つPsy RDO patch version 0.22
http://forum.doom9.org/showthread.php?t=138293

つ　←これをでかいほうで書くとTsuPsyと読んでしまうなぁ

っにしてくれ

前スレでAviUtlの伸張について載っているっていうスレ見たらMakki氏光臨してんのなｗ
AviUtl使わなくなってあのスレまったく見てなかったから、素直に生きてた事がうれしいわ。
一言言わせてくれConvertAviUtlYCFix最高!超最高!いつも感謝して使わせてもらってます!

空の境界のドアのシーンは俺もひどかったけど
脳内フィルタが優秀すぎた

縦解像度720制作のアニメって1080から720にリサイズした方が
同一ビットレートなら画質よくなったりするんだろうか。

前スレでjvtよりflatが良いって言われてたのでやってみたら、ずっと良かったわ。
アニメは常にflatが良いのかな。

--crf 22 --level 3.1 --keyint 240 --min-keyint 1 --ref 13 --mixed-refs --no-fast-pskip　--no-dct-decimate --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto
--subme 7 --me umh --merange 32 --trellis 2 --scenecut 65 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 14 --qpmax 35 --qpstep 8 --qcomp 0.7

・jvt --aq-mode 0
SSIM Mean Y:0.9934087
PSNR Mean Y:48.329 U:52.807 V:52.520 Avg:49.303 Global:48.773 kb/s:658.33

・flat --aq-mode 0（SSIMも改善されてサイズもダウン）
SSIM Mean Y:0.9934833
PSNR Mean Y:48.482 U:52.176 V:51.886 Avg:49.326 Global:48.799 kb/s:546.67

・jvt-VAQ+HAQ（かなり改善されているが、サイズ大きすぎ）
--aq-mode 2 --aq-metric 3 --aq-strength -0.4 --aq-sensitivity 7.625 --aq2-strength 0.3 --aq2-sensitivity 15
SSIM Mean Y:0.9939496
PSNR Mean Y:49.190 U:53.232 V:52.971 Avg:50.106 Global:49.634 kb/s:852.65

・flat-VAQ+HAQ（かなり改善されているが、サイズ大きい）
--aq-mode 2 --aq-metric 3 --aq-strength -0.4 --aq-sensitivity 7.625 --aq2-strength 0.3 --aq2-sensitivity 15
SSIM Mean Y:0.9940184
PSNR Mean Y:49.349 U:52.663 V:52.417 Avg:50.132 Global:49.670 kb/s:727.78

・flat+VAQ
--aq-mode 2 --aq-metric 3 --aq-strength 0.4 --aq-sensitivity 7.625
SSIM Mean Y:0.9931157
PSNR Mean Y:47.720 U:51.765 V:51.500 Avg:48.613 Global:47.933 kb/s:502.94

自分もそれ試して見たけど、フィルタでノイズ取っちゃった場合jvt-VAQだとｻﾞﾗｻﾞﾗ感が増した気がしましたね　flatだと若干ﾏｼ見えました
逆にフィルタが無い場合あくまで自分の感覚ですがjvt-VAQの方が綺麗に見えましたね〜

アニメは輪郭等、他のソースと比べて高周波が目に付きやすいから、
それを削るVAQやCQM(JVT含む)は余り向かない。

なるほど、それで輪郭周りが綺麗に見えたのですね。　今日代休で暇だから色々試してみよう。

なにその魔法の呪文AQ mode0のSSIMっぷり
それで暗部がﾏｼならflat mode0使うけど、ましにならねーからflat −VAQ＋HAQ使うんでねーのかな
それにflat選ぶなら-VAQだけでいいような気もする
逆にjvt選ぶなら-VAQの数値を下げて使えばいいだけの気もする
しかしAQって色々パターンあるから設定だすの楽しいよねっ

あ〜知られちゃったか、まあいいや

859→861にしたら同じ設定で100M近く膨らむ！

うぞんまじで
ちょっとテストエンコの泥沼にはまってみるか

泥沼どころか大してかわらなくて終了した
良かったらちょっとオプション晒してくれねーか

--qnsってどんな動作するの？
前スレでもチラっと話出てたけど、結局何の効果かは誰も書いてない気が。

quantizer noise shaping

顔がシャープになって元画質に近づこうとがんばってる感を受ける　実写だけど。

qnsって今のところ-8と一緒に使うと落ちるとか、
他のオプションと競合して悪さをするような話しか聞かないな

なるほど。
現状使わないほうが良さそうだね。

ところでオリジナルマトリクスって皆どうしてる？
自分はなるｐのマトリクスをベースにちらちら弄ってる。
crf20設定で1600kbpsレートぐらいに落ち着くベストを探してるんだけど
NR掛けた画像とかじゃ前スレのエヴァみたいにボロクソになるｗ

>>32
--crf 17.0 --level 4 --keyint 240 --min-keyint 1 --ref 8 --mixed-refs --bframes 2 --b-rdo --bime --weightb
--direct temporal --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 8 --qpmax 40 --qpstep 8
--scenecut 72 --me umh --merange 32 --threads auto --cqmfile "hoge.cfg" --progress --no-dct-decimate
--no-fast-pskip --trellis 0 --aq-mode 2 --aq-strength -0.1 --aq-sensitivity 6 --aq-metric 0 --aq2-strength 0.4
--aq2-sensitivity 12 --qcomp 0.64 --fps 24000/1001 --sar 40:33

r859 359,382kb
r861 448,179kb

他アニメ2話分も同じように膨らむ。

>>24
( ﾟдﾟ) --ref 13…。エンコ時間凄そうだ

Psy RDOが有効になっているんだろう。

>>40
ごめん、今--longhelpで見てみたが
--rdcmp Metric used for RD mode decision ["psy"]
- ssd: normal (maximum PSNR)
- psy: psychovisual (sharper)

これのせいか… これはまたちょっと実験しなおしかぁ、ﾏﾝﾄﾞｸｻくなってきた。

結局画質上げるとサイズ増えるのかよ
もうVC-1でいいや

女じゃあるまいしここで愚痴るなよそ行ってやれや
画質あがりゃサイズ増えるなんてエンコしてりゃ当たり前の事だろに

そんなのねぇぞって思ったらパッチの方かでもpsyの方がデフォルトになる理由はなんだろ

バンディング対策これってどんな感じ？
http://www.avisynth.info/?niiyan%2F2008-06-01#kef9658b

自分で試せばいいだろ。x264と関係ないし

>>1
zomeってなに？

>>47
http://en.wikipedia.org/wiki/Zome

前スレよりコピペ
わざと避けたとしか思えない


5 名無しさん＠編集中 [sage] Date:2008/04/02(水) 00:13:04  ID:inofjYwy Be:
    QuickTime 7.4がB-Pyramid対応の模様
    ttp://ageha909.blog121.fc2.com/blog-entry-563.html

    QuickTime 7.4のApple H.264デコーダ、きちんとB-Pyramidをサポートしたんだね。
    ttp://mycometg3.blog.so-net.ne.jp/2008-02-02

6 名無しさん＠編集中 [sage] Date:2008/04/02(水) 00:45:09  ID:cPMGTrRN Be:
    978 名無しさん＠編集中 [sage] Date:2008/04/01(火) 15:01:46  ID:u/zFKeNa Be:
        zome → zoome
        avsの %1 → %~1

    985 名無しさん＠編集中 [sage] Date:2008/04/01(火) 19:59:38  ID:ZSx6RoRs Be:
        語りだすとそれこそスレ1つ埋まってしまう

        >>969にこれ追加する程度で良いんじゃね？
        アスペクト比 part3
        http://pc11.2ch.net/test/read.cgi/avi/1174473555/

これマジ？

【DivX/XviD】最強コーデック決定戦【H.264/WMV9】
http://pc11.2ch.net/test/read.cgi/avi/1191294731/
520 名前：名無しさん＠編集中 [sage] 投稿日：2008/06/04(水) 19:28:27 ID:WkTtjxux
>>506

>アニメはWMV、実写はH.264　速度重視ならDIVXかXVID

きれいさをいうなら実写もWMVがいいよ。
ただしエンコ時間は
WMV >> H264
だけど

521 名前：名無しさん＠編集中 [sage] 投稿日：2008/06/04(水) 19:31:30 ID:WkTtjxux
H.264ってXvitと比較するならともかく、
wmvと比較するとビットレート上げても全然歯がたたんのな。
特にインタレ解除とかするとまったく勝負にならん

ご迷惑お掛けしてます。

どうも自分のはマトリクスの作り方に問題があるっぽいです。
psy使用を行えば改善し、解決するのですがサイズ調整が難しいため
マトリクスの組み直しからすることにしました。
精進します。

ちなみに暗部問題が出たマトリクスは↓
http://www2.uploda.org/uporg1462644.cfg.html

改善点などありましたらレスして頂けると助かります。
※暗部に弱い変わりに明るい画面じゃ綺麗になると思いますがどうでしょう？

エンコ時間WMV >> H.264とか言ってる時点で適当オプションなんだろ。
WMV信者にはそう思わせとけ。ってまあH.264信者が言っても堂々巡りか。

>>61
値が小さすぎる

あ、書き忘れましたがターゲットビットレートはcrf20で1600kbps程度です。

>>51
おとなしくjvt使えよ
いいぞjvtは

>>55
jvt試してみました。
昨日と同じフレーム抜き出しています。

jvt
http://uproda11.2ch-library.com/src/1191584.png.shtml

オリジナルマトリクス
http://uproda11.2ch-library.com/src/1191463.png.shtml

高周波が気になるけどチョビッと改善された気がします！！

ここはお前のブログか

>>51
＞思いますがどうでしょう？
Middleの16番目マトリクスは、更新日が2006年12月14日ぐらいだ。多分。
なので練って作ったのは、それよりも遥か前の日付だったりする。
ソノ当時美味く絵が作れたと判断したx264と、現在のx264では違い過ぎる。
自分で云うのも変だが。合うかどうかは、━━━疑問だね。
それに。古いマトリクスは、練り方が甘い傾向が強いッス。
熟れとか目とか今と違って弱いから、シャア無い。

＞jvt試してみました。
jvtは、バランスがいい。
自分で作った奴は、大抵の場合バランスが悪い。
ちなみに。バンディング改善にはバランスが、モノ利かすワケYO
ゆえに、jvt優秀です。
どうしてもオリジナルマトリクスでエンコしたいなら、
表計算ソフトとかでグラフ見ながら値を決めると、感じ良くなる気がします。
ちなみに。Middleの16番マトリクスは、そんな事して作ってないので、荒いです。

ところでなるP、覚書のindex3.htmlが死んでいるようなのだが？

音声をAACにエンコしておいてmkvに入れる漢が来た･･･

よんだ？

ぱんだ？

たらばがに？

チャーハンまだぁ？

＞覚書のindex3.html
index3.htmlは、リンク書いておきながら、作ってない罠。orz
書いてないよーって内容のファイル置いた方が、いいのかな。
…氏んでるのは、漏れ。(ぇー

ID:UTwa9pU+
なるPﾀｿ（・∀・）ﾊｹｰﾝ




　　　　　　　　　　　　　　丼だけ又寸だヾ[`Д´;]ﾉ

>>51
そもそもマトリクスをわかってないっぽい
明暗でなくて周波数分布による量子化コントロールをするもの
基本的にソースに合わせて設定しないと駄目だよ

rdcmp psy細部暗部すごいな
画質自体は初めてwmv9やdivxとx264比較した時くらい違ってた

でもサイズ増もとんでもないな
xxxHOLiC継 #09 音込み
なし　161MB
あり　272MB

--crf 20 --ref 5 --keyint 480 --min-keyint 12 --level 4.1 --mixed-refs
--no-fast-pskip --no-dct-decimate --bframes 2 --b-rdo --bime --weightb
--no-deblock --subme 7 --trellis 2 --8x8dct --qpstep 8 --scenecut 75 --me umh

暗かったり淡かったりしてノッペリしがちな所がソースに近くなった
でもレート食いすぎなんでまだ使う気はしないす

とりあえず2passでやるか1passでも容量近づけて画質比較しないと意味ないだろ
容量増えて画質が良くなるのは当たり前なんだから

それもそうだね

しかしオプションひとつで100MBは増えすぎだろ

デフォルトで使うようになってるのがマゾいな

容量＋100MBでデフォルトは確かにﾏｿﾞいね
アニメだと太るのかもだけど、実写だと髪の毛の表現とか好みになったなあ

25分アニメcrf18 flat −VAQ HAQ無し他67のとほぼ一緒のOP
フィルタFaery(1)のみ
psy無し　278M
psyあり　343M
確かに綺麗だけどビット喰いすぎだね、今同じ容量になるようにcrf調整してるけど2上げても同じ容量にならず再チャレンジ中

原因全く分かんないけどr861→r869でエンコできなかった

-I 240 -i 1 --scenecut 75 -b 3 -r 3
--crf 18 --qpmin 8 --qpmax 30 --qpstep 8 --aq-mode 0
--direct auto -w --me umh --merange 32 -m 6 --b-rdo --mixed-refs --bime -8 -t 2 --no-fast-pskip --no-dct-decimate --cqm jvt

--level 4.1 --crf 16 --qpmin 10 --qpmax 38 --qpstep 8 --scenecut 75 --deadzone-intra 8 --min-keyint 1 --keyint 240
--8x8dct --bframes 3 --bime --b-rdo --weightb --me-prepass --direct auto --subme 7 --me umh --merange 32
--ref 5 --mixed-refs --trellis 2 --deblock -3:-3 --cqm flat --no-fast-pskip --no-dct-decimat --progress --aq-mode 0 --qcomp 0.8

859→869これでまったく問題無し
crf3以上下げないとげないとpsy無し同サイズにならねー
暗部細部はすごい好みな感じだから、AQ設定色々お試し中('A`)　

正直なところpsyとssdの違いが分からない。
同一crfだとSSIMもPSNRもpsyの方が下がったので、少なくともソースからは外れていってる。
シャープフィルタかけると画質が良くなったような気がするのと同じじゃないのかな。
綺麗になったって人は2passで同一ビットレートにして試したほうがいい気がするよ。

歪んでいないが完全にぼけているブロックよりも、多少歪んでいてもディテールのあるブロックの方が
人間の目には好ましく見えると言うのがPsy RDOの考え方だから、PSNRやSSIMが下がるのはしょうがない。

上の設定で手持ちの河童のクゥと夏休みエンコしたら2G越える('A`)

h.264で録画できるHDDレコーダーほしい

スレ違い

今までアニメをjvtでエンコしてた俺脂肪…orz

いやjvtでいいんだよ

出来上がったアニメを比べてみりゃ分かるけど同じサイズなら明らかにflatのほうが綺麗だよ

150kbpsの2passで比べても？

>>85
草臭いから巣に帰れ

ふと思ったんだけどあれこれパッチ適用した264のオプションはハードデコード出来るの？

>>86
つまり同じサイズでも変わることがあるってことだよな？
そこんとこわかってないのに>>84みたいなこと言い出すやつがいるからなぁ。

やっぱ突っ込まれたか
この話すると長くなるからこの辺でやめとくか…

>>87
ビットストリームは同じだから、今までのデコーダで大丈夫。

なるほどthx。

どっちでも好きな方使やいいだろがｗｗｗ
人の好みにまでケチつけんなや

SDの実写でcrfでやってみたが、AQの有無にかかわらず
jvtよりflatの方がサイズも小さくてSSIMも良くなった…
と言っても>24ほどサイズの差は出てないけど

ぶっちゃけjvtって意味あるのか？

それはWAVを波形だけで比較して
どっちが音がいいとか言ってるのと同じレベルの発言

もはや映像を鑑賞してるんだかSSIMを鑑賞してるんだか分からない人がいるな

ぶっちゃけcrf20くらいだとオプション変えても俺の目には違いがわからん。

>>96
ffdshowで量子化平均値を眺めているといいかも

量子化数値見てるとOreAQって変動するMBってほんのわずかなんだよな。
通常のAQが盛大に変動してるからこれってほんとに効果あるのか('A｀)？と思ってしまう。
SSIMはOreAQのがはるかにいいんだけど肉眼では例のごとくよくわからん(:D)rz

SSIMはあくまで指標でしかないだろ。
自分の目で綺麗と思えればどうでも良いよ、数値なんて。
AQやらPSYやら全部自分の目で判断することを前提に作られてるんだし。

SSIMで計るならPSY使うとガクッと落ちるからな

>>98
その顔やめいｗ

AQとPSY組み合わせるとけっこー膨らむね
AQん時みたいに本家のエロい人達がサイズ爆発させないいい感じにバランスとってくれると期待

HDサイズのアニメソースでAQとPSYって相性悪いのかな？
俺の目にはPSYだけで使った方が全体的に見栄えがいいんだけど。

--crf 20 --aq-mode 0 --aq-strength -0.2 --aq-sensitivity 8
--aq-metric 0 --aq2-strength 0.6 --aq2-sensitivity 12 --qn
s --qcomp 0.6 --qpmin 16 --qpmax 34 --qpstep 8 --scenec
ut 60 --min-keyint 1 --keyint 300 --8x8dct --partitions "p8
x8,b8x8,i8x8,i4x4" --bframes 3 --b-pyramid --bime --weigh
tb --b-rdo --direct "auto" --subme 7 --me "umh" --me-pr
epass --merange 32 --ref 8 --mixed-refs --sar 4:3 --threa
ds "auto" --trellis 2 --no-deblock --cqm "jvt" --no-fast-p
skip --no-dct-decimate --progress --rdcmp psy

AQをオンにするときは--aq-mode 2にして使ってる。
まぁ俺の目がクソで、設定もクソっていう可能性の方が高いかもしれないけどｗ

当然SSIMはAQオンの時の方が高いわけだが、大事なのは見た目(印象)なので
そんなことは気にしない。

＞--no-deblock --cqm "jvt"

これが原因だな

それは--no-deblockに--cqm "jvt" の相性が悪いってことかな？
デブロックフィルタ切ったほうが全体的に鮮明感が出て個人的には好きな画質だったんだが。

--no-deblock(笑)

俺が最初に言ったことからハズレてる気がするんだが…。
--no-deblockをつけるのがよくないとして
それがAQとPSYの相性がよくないって感じた理由になるの？
それがわかるなら説明してほしいわけだが

好みとか言い出したらキリが無い。
ソースに忠実かどうかで判断するのが一番妥当で、そのためにSSIMがある。
味付けはポストフィルタでやればいいじゃない。

>>107
PSYなしでAQ使った場合は画質どうなの？

>>108
SSIMは忠実性の一つの尺度にしか過ぎないわけで

デブロックは見てわかるくらいボケたから切ったままだわ

PSYなしでAQ使うと暗部ノイズも割と軽減されるし、
全体的に精彩感が増してる印象を受けるからしっかり効いてるかと。
PSY＋AQとPSYを比べると、別に暗部ノイズが増えるとかそういったことは無いと思うんだけど
PSYだけの方がハッキリ(?)とした絵になるような印象を受けた。
PSYだけでも十分暗部ノイズとかも軽減してくれるし、AQと合わせて使う必要ないんじゃないかな、と。

適当なこと言うと、どっちか片方がもう片方の作用を撹乱してんのかもね

AQはあくまでレートコントロールだからな

ｽﾏｿ、誰か前スレのログ持ってたら恵んでください。
巡回を忘れたときに限って落ちるなんて・・・

2コアのCPUで--threads-inputを使ってるエンコするとコア2の方が40%位で遊んでる感じなんだけど、
これってエンコ処理に比べてAvisynthのフィルタ処理の負荷が重くて、エンコ側のコアが遊んでるってこと？
それとも逆で、エンコ待ちでフィルタ側のコアが遊んでると考えていいの？

使ってるフィルタはIT、Convolution3D、WarpSharp、Lanczos4Resize
エンコのオプションは
--crf 20 --ref 6 --mixed-refs --cqm jvt --keyint 240 --min-keyint 1 --scenecut 65
--bframes 4 --bime --b-pyramid --direct auto --8x8dct --trellis 1 --qpstep 8
--ipratio 1.60 --threads auto --thread-input --no-dct-decimate --no-fast-pskip

>>114 http://www.vipper.org/vip836421.dat.html

>>116
ありがとう

ん〜…PSYのみとAQ+PSYとAQのみと何も無しを比べてみたんだけど
個人的主観で言うとPSYのみ>AQのみ>何も無し>PSY+AQかなぁ…。

ビットレートでは
PSYのみ 1645kbps
AQのみ　 1429kbps
何も無し 1220kbps
PSY+AQ 1742kbps

PSYもAQも双方がマクロブロック単位のレイトコントロールしてて
総じて同時使用の時は悪い結果導いてるような気がする。

サンプル画像要るならうｐるけど、いらんよね？

aq設定固定でflat jvt ssd psyの全組み合わせをテストエンコし、
見比べても、静止画切り出してじっっっくり眺めても
誤差範囲内としか思えないような差しか無くて泣きそう

そう？俺はテロップとかでpsyの方がはっきりくっきりすると思う。

まぁ主観になるからな。psy入れたら
実写はfgo使ってるけど。こっちの方が俺好み

>>118
何も無しでcrf値落としてみ
あ〜ら不思議ｗ

>>122
言われると思ったよｗ
そっちも試してるけど俺の主観だと暗い処ではPSYで明るい処だと何も無しの低crfかなぁ？
特に夕日とか赤く、ぼやけが強めのところで差が出る。
つっても再生されてるとあんま解らんがｗ

>>123
結局同一ビットレートじゃ小細工しない方が主観評価も上でした、ってこと？

明10暗10・・・明に10もいらねーよ！（ﾟ�听）
明7暗13くらいでいい！(｀･ω･´)


つまり、俺は小細工した方が上だと思う。

OreAQ11に期待。　他力本願万歳！（殴

前にも書いたがflat以外のマトリックスやVAQはアニメには向かない。
--filterも-3,0とかにすればそんなにぼけたりはしない。

でもよく見たら--aq-strengthの数値がマイナスだな。

そりゃx264に渡す前にどういったNR処理するかでdeblock値は人それぞれでしょう
わたしは3DNRしか掛けない人だから -2,-1で使ってる

AQ設定がメンドクサイおれにとっては暗部細部をある程度綺麗にしてくれるpsyは楽でいいと感じる
まあ素材がアニメならｽﾞﾎﾞﾗｰなｵﾚには--aq-mode 0 --psy --cqm flat 　楽でｲｲ('A`)

psy精細感保ってるように見えるがよく見比べたら元ソース以上に粉っぽくなってた
まあ綺麗なんだけどサイズ爆発するしもう暫くはaqデフォpsyなしで様子見

あ、「粉っぽく」はssdで普通にエンコするとのっぺりしちゃうような淡いところの話ね
輪郭周りとかじゃなくて

>>131
ほんとにその症状出てるわ
輪郭周りばっかり見てて気がつかんかったけど、jvt→flatで大分ﾏｼに見えるようになった
上で言ってるようにAQ設定しなくていいから楽なのだけど-VAQ＋HAQよりSSIM下がるからなんか損した気分になるね

x264.870.release01.rar

git-r871
latest changes:
- Cosmetic: fix C99-ism

Psy RD0とFGOは同居していますが、両方同時に利用した場合に意図しない結果を生み出すかもしれません。
最近更新早すぎて新しいOP練ってる間に次が('A`)

bm_x264_patch_collection.r870.zip
http://stashbox.org/132452/bm_x264_patch_collection.r870.zip

by MasterNobody
http://forum.doom9.org/showthread.php?p=1146269#post1146269

SSD, Psy RDO, FGO(NSSD)は同時には使えない。

--b-rdo --rdcmp ssd --fgo 5

これならok？fgoってまだ試してないからちょっとやってみるかな…

r869から1フレーム目が一瞬早送りみたいになっておかしくね？
r859に戻したお。

>>139　=（VFRmaniac氏のビルド）

seraphyのビルドはr861〜r871でエンコしたけど正常だったお
seraphyのビルドに乗り換えたお

俺の中でPSY+HAQが最上級だという結論が出た。

てかPSY単品って何してんだ？
ただQ値を下げた場合と何が違うのか解らん。
マクロブロック単位でレートコントロールしてるわけでもないし。

PSYはPsychologicalという名の通り顔とか見に行きやすい所を丁寧にして
パッと見の高画質感を上げてるんだろ
聞こえないところはどんどん省略するmp3も同じ思想

SSD, Psy RDO, FGO(NSSD)ってどのrevから使える？

>>141

実写ならそれでいいかもだけどアニメだとそれじゃ駄目なんじゃね

世界的にみたら日本のようなマットなアニメは少数派だろう？
普通に考えれば実写に合わせて調整するのは当然かと。

日本アニメはAQなしかOreAQか気持ち-VAQ掛けるくらいで十分な気がしてきた。
crf20の時点でQPは十分ぽいし。

十分と言えなくも無いが弱点の暗部とか微妙な階調とかに上手い事ビットを割り振る
にはどうすんべ？ってみんな頑張ってるんだろ…

ffdshowで見てみると分かるけど、適応処理あんま出来てない気がするので俺はAQ無しだな

>>148
マトリクスとAQの設定次第じゃない？


今PSYと-VAQ+HAQでエンコしたら何かフレーム融合（二重化）されたみたいな映像が
出来上がってへこんだよ。
PSY+HAQとかPSYだけとかAQだけなら発生しないので一緒に使うと問題出るのかなぁ？
俺だけかもしれないので、誰か検証してみてくれない？

jvtちょっと変えて--aq-strengthを少しプラスでいいわ

VFRmaniac氏、修正お疲れ様です
r871-1頂きますm(_ _)m

>>136
UpDate? diff

List of independent patches:
x264_32x32samples_crash.r870.diff
x264_cosmetic.r870.diff
x264_debug_defines.r870.diff
x264_fix_stats_file_work.r870.diff
x264_frames_memoryleak.r870.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff
x264_psy_rdo.r870.diff
x264_thread_pool.r870.diff
x264_vaq2mod.03.r870.diff

Patches that depends of others:
bm_x264_thread_pool.r870.diff depends of x264_fix_stats_file_work.r870.diff, x264_frames_memoryleak.r870.diff, x264_multithreading_Nth_pass_ratecontrol.r870.diff
bm_x264_vfw2cli.r870.diff depends of x264_fix_stats_file_work.r870.diff

All in one patches:
bm_x264_cli_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_exp_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_normal_fixed.r870.diff

--aq-strengthプラスは地雷だろ
高ビットレートなら良いかもしれんけど

実写にはとても有効

実写エンコしてる俺にとって重宝してます

今日中に実写はこれって言う設定教えろ
>4のバッチでやる奴な
待ってるぞ

--crf 2 --trellis 2 --me tesa --subme 7 --merange 64 --ref 16 --bframes 0 --no-cabac --nr 50000 --min-keyint 3000 --qcomp 0 --qns

crf 2かよ

ものすごい地雷設定ですね、わかります

>>157
確かに綺麗だけれど5MBのmpegが12MBとかになったぜ？
ありえねぇよ

つ --no-asm

拡張子はaviよりmp4の方が安定するのでしょうか？

>>161
ちょ、--no-asmってCPU拡張命令を無効化しますってあるけど
これやったらなんか知らんけどものすご遅くなるんですけど？
ついでに>157の--qnsっての使えねよっていわれたょ？

>>157 >>161
ｸｿﾜﾛﾀｗｗｗｗｗ

だ、騙したな！！
だから大人なんか、うぅ・・

俺も最近x264使い出したのでまだ全部覚えてない。
>>161
確かCPUモードがなくなったのでめちゃくちゃ遅くなるんだったっけか？
使ったことないのでよー分からん。

ここはもはや使い慣れたやつらが初心者を小バカにするスレざます

まともに教えなさいよ！

longhelp見ようぜ

教えて君と初心者を一緒にするなよ

そもそも初心者ってLogHelpの見方がﾜｶﾗﾝから質問多いだけかもしれんな
次からテンプレに入れればいいんでねーの

>>173が書いて次から「>>173見ろ」でいいじゃん

>>156
>>173見ろ

　　　　　　　　　　　　　　　　　　　　　　　　　　 　γ⌒)　))
　　　　　　　　＿＿＿（⌒ヽ　 　　　　　　　　　　 /　⊃＿＿
　 　　　　　／ 　　 　　⊂_　ヽヾ 　 　 　 　 　〃/　/ 　 　 　＼　　
（⌒ヽ∩／　　　　　　　　|(⌒ヽ　　　　　　 γ⌒)/　 　　 　 　 ＼ ∩⌒)　
　ヽ 　ﾉ| :::⌒ （_,ヽ　⌒　:::| ⊂ `､三　 三 ／ _ノ :::　⌒ r､_）⌒ 〃/　ノ
　　＼ ＼ 　　`ﾆﾆ´ 　　 /　/>　） ）） ( （　 <|　 |　　　`ﾆﾆ' 　　 /　/　））
(( （⌒ )､ ヽ＿ 　　　 ,／ ／　／　三　( ＼　ヽ　＼ ＿　　　　／（ ⌒）
　　＼ ＼ / 　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 /　/

--trellis 2 --no-cabac --qns

こいつらを一緒にはできんなぁ

tellisとno-ccabacは同居できないけど
trellisとqnsって同居できなかったっけ？

× --trellis 1or2 --no-cabac --qns
○ --trellis 1or2 --qns
× --trellis 0 --qns
× --trellis 1or2 --no-cabac
○ --trellis 1or2

こうと記憶しているけど

>>175の解釈を自分尺度で解釈してたかも
すまんですたい。

PSYとFGOは解るがRDOって何だ？？？

READ OR DIE

>>179
What's the point of RDO?
http://forum.doom9.org/showthread.php?t=127552

>>180
それどんな読子

>>181
なんとなく把握できました。　ありがとう！！

ところで暗部調整がうまくいかず、PSYを使うのも負けな気がしてtrellisを試しに切ってみたら
暗部でもクッキリハッキリなんだが、これって歪最適化が無くなったから？

trellis2にはノッペリ効果があるから
trellis1はそうでもない

通常のSSDがのっぺりして嫌だという人の為にあるのがPsy RDO
--subme 7 --trellis 2と一緒に使う

--b-rdoを忘れていた

http://forum.doom9.org/showthread.php?p=1144270#post1144270

>To use it, enable RDO. --subme 6? Good. --b-rdo too? Better. --subme 7? Even better.

>Trellis 1 probably is not the best idea with this because that means the quantization that x264 chooses
>is not the quantization that psy RDO looked at in mode decision. Therefore, unless its demonstrated
>that this isn't a real issue, deadzones or trellis 2 are probably a better idea

RDOが有効になるsubme6以上が必須、bフレにもRDOを適用するb-rdoを併用すれば尚良し
psy使用時にはtrellis1を使うよりdeadzone指定かtrellis2を使ったほうが今のところ無難
と設計者のDarkShikari氏は言ってる

オプション試す時NRフィルタは外すべきだよね
でも実際NRと併用した時を目で見て判断するべきでもあるよね

trellis 1 + ssd、trellis 2 + psyで良いわけだな。

r-877
latest changes:
- Partially inline trellis quantization
Inlining trellis into the 4x4/8x8 trellis wrappers increases trellis speed by about 5-10% through constant propagation.

r-877
最新の変化:
- 部分的にインラインのトレリス量子化
4×4/8×8のトレリス包装紙にトレリスをInliningすると、トレリス速度は一定の伝播でおよそ5-10%上がります。


・・・意味が分からん('A｀)

SSIM Mean Y:0.9949079
満足

また最適化かな
この間のアセンブラの時みたいにぶっ壊れてなけりゃいいんだがｗ

>>191
ｺﾏﾝﾄﾞﾗｲﾝうｐ

>>193
avis [info]: 1440x1080 @ 23.98 fps (34354 frames)
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 1001 (scale 24000)
x264 [info]: slice I:415 Avg QP:16.75 size: 964290:00:00
x264 [info]: slice P:11792 Avg QP:17.94 size: 41824
x264 [info]: slice B:22147 Avg QP:19.09 size: 9001
x264 [info]: mb I I16..4: 40.4% 41.0% 18.6%
x264 [info]: mb P I16..4: 12.3% 8.5% 1.8% P16..4: 44.7% 8.3% 5.1% 0.0% 0.0% skip:19.3%
x264 [info]: mb B I16..4: 0.2% 0.1% 0.1% B16..8: 22.7% 0.7% 1.2% direct: 3.0% skip:72.1%
x264 [info]: 8x8 transform intra:37.8% inter:58.2%
x264 [info]: direct mvs spatial:93.0% temporal:7.0%
x264 [info]: ref P 69.5% 14.6% 8.6% 4.0% 3.3%
x264 [info]: ref B 84.5% 9.2% 4.3% 2.0%
x264 [info]: SSIM Mean Y:0.9949079
x264 [info]: kb/s:4090.1

encoded 34354 frames, 5.98 fps, 4090.16 kb/s

>>193
俺の方が凄い。
SSIM Mean Y:0.9998749
--qp 1 --aq-strength 0.0 --keyint 240 --min-keyint 1 --scenecut 70 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me dia --subme 1 --threads auto --thread-queue 2 --rdcmp psy --progress

リロードしてから書き込めば良かったorz

ﾂﾏﾝﾈ

すばらしいな。　ぜひオプション内容知りたいぜ、、

ｺﾏﾝﾄﾞﾗｲﾝとﾊﾞｯﾁ内容勘違いしてｱﾎかと･･･
半年ROMりま('A'

いやいや普通はオプション内容を記したコマンドラインを貼るもんだろ
>>194みたいの貼られても邪魔くさいだけだし

>>200
俺も普段>>194みたいの貼られてるの見て、邪魔くせーと思ってた
コマンドラインっていうからこっちかと思った
気が合うな

>>201

気が合うのはわかったからオプション張ってくれ、、、！

SSIMなんてソースしだいでいくらでも変わるからオプション貼ったとこでたいして意味無いだろ…

さすがに二番煎じはつまらんな

━━━━━━━　　　　　　　━━━━━━━　
━━━━━━━　　　　　　　━━━━━━━　　
　 ///////////　　　 　　　　 /////////////　　●

　　　　　　　　　　　 （__人__）

trellisってもしかして、もしかしたら、切った方がいい…？
アニメ2本エンコしてサイズ的には (大)1>2>0(小) こうなって
2と0で見比べてみたら2の方が線とかボケ気味で荒れ気味に見えた
(r869 AQあり SSD)

trellis 2にしたらここがこう良くなった的な話を聞きたい…

ここもすっかり初心者スレになっちゃいましたね

玄人ぶって情報出し惜しみするくらいなら、初心者同士で情報出しあった方が有意義だ

俺はサイズが0>1>2と予想通りの結果になった。
画質的には0>1=2みたいな感じ。
まぁ最適化されないから当たり前か。
deadzoneをソースに合わせて設定する必要あるかも。

とりあえずtrellis0では暗部とかでレートが下がらずディティールが
結構残る感じになった。　これはびっくり。

まぁな、でも生意気な初心者に教えるほど
物好きもそんなにおらんと思うよ

情報出し合うならおまえから出せよ情報
搾りつくすの間違いじゃねーの？

おまえら性格悪すぎだろ

この流れを作った>>207が一番悪いってことですね。わかります。

つか、自分の目で確かめれば済む話。
出し合うとか以前の問題です。

x264_EXPERIMENTAL_rev877-release1.rar

Removed three committings (at r852, r866, r875) for avoiding to crash on MSVC builds. 　 Modified x264_fgo.diff and x264_fix_stats_file_work.diff.
By VFR maniac

何だこの糞な流れは。
ここで問題解決とか話合わずに何するんだよ。
自分自身で確認するのは当たり前だが、それだけで終わってたらココ要らんだろ。
荒らすぐらいなら出て行けって。

所詮はアニヲタの巣なんだから
人格的なものを期待する方が間違ってるよ

期待なんぞしてないさ
単に某ニュー速や某毒男板の感覚で書き込まれても困るって話さ

教えて君の自己正当化ウザス

>>215
それどこにあるの？

＞By VFR maniac

>>221
あ、発見。�d。

これでx264guiの延命できるのかな。

>>222
MSVCでビルドできないパッチを外したということだけど、今後も高速化のパッチが当たるたびに
同じことが起きるだろうから、この方法にも限界があると思う。
それに、高速化されていないんじゃ、リビジョン上げる意味ないことない？

MSVC無視は今だけってことはないのかなぁ…

てかx264.exeのseeraphyビルドは続くんだろうか。

お、CLI版だけ出てる。

x264.877.release01.rar
> □x264.877.release01
> ・アライメント問題が深刻なので、GCCに戻りました。
> GCCならばと、WIN用にアライメント関係の修正を施し、しばらくはずしていた
> DEBLOCK_LUMA / DEBLOCK_LUMA_INTRAのSSE2コードを復活させました。
> これでCLI版は本家に追いつきました。あとはGUI版ですね。…頭が痛いです。
> ・コンパイラがGCCに移行したことにより、pthreadGC2.dllが必要になります。
> パスの通った所においてください。

これで困るのってAviUtlなお方だけじゃねーの？

あれ？エンコ始まらない。

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4 Cache64
って出て止まるな。なんだこれ。

>>226に書いてあるじゃん

dllは入れてる。
--no-asmつけるとエンコが始まった。

重い重すぎるクアッドにしないともうダメだ

--threads指定するとだめぽ

あれ？何も変えてないのに動き出した。
スレ汚しスミマセン。何だったんだろう？

AviUtlでx264使えないとへこむなぁ。

別に使えん訳じゃ無いだろ
現行Verを使い続ければ問題ない

x264.auoみたいな簡素なインターフェイスで十分だからAviutl用のを作り続けてほしい＞＜
俺無知だから無茶なお願いしてるのかもしれないけど、x264.auoやx264gui.auoが大好きだったから

ま、まぁそうなんだが…

昔のx264.auoのインターフェースでx264afs.exeにデータ渡してくれる
プラグインっていう形も無理なのだろうか？
x264out.auoってitvfrしかダメじゃん？
しかもそれだとハイブリッドAQとかOreAQ使えないし、パッチ版を取ると
今度は自動フレームレート機能が死んじゃうっていう。

Seraphy氏なんとかしてくれないかなぁ。

うぁあぁあぁっ（＞＜）
#pthreadsはCVS持ってきてmake GC-staticでスタティックリンクのlibができるです。

ぽむ様ﾃﾞﾀ━(ﾟ∀ﾟ)━ !!!!!

guiはdll分離して続くみたいですね、ほ。

pthreadsってまだ更新してたんだ
2-8-0が二年前だから終わったのかと思ってた
って言っても、ここ数日更新あって、その前の更新が半年前とかだけどね

Dvixとかからx264に以降してからsynthしか使わなくなった人は結構居ると思う。

こないだはメモリアライメントで、今回はスタックアライメントの問題か。まったく。


と分かったような事を書き込む俺に、誰か何の問題が起きているのか分かり易く
解説してください。お願いします。
せめて、エンコ完走したら問題ないのか、動くけどファイルに問題がでるのかだけでも。

Seraphyさんありがとう！x264gui.877.zipで今まで通りAviutlからgui使ってエンコできました
x264patch.870で作ったセッティングファイル開こうとしたらフォーマット不一致で弾かれたけど、それ以外は大丈夫だった

おおおおぅ！！
まさかのβ！！
これは参加せざるを得ない！！！！


ところでaq-modeなんだけど、2を指定してフレーム間でのビットレートのやりとりも
OKにすると、暗部とかでブロックノイズや残像残らない？
aq-mode1にした場合はまったく出ないんだけど。
皆どうしてる？

βに参加するノリがあるならパッチ版に乗り換えてaq-mode3を試してみればいいじゃん？

VFWスレと化してしまった

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

【x264gui.auoテスト比較】

[PC環境] XP Pro SP2 / Core2 Quad Q9450 (3.2 GHz) / DDR2-800 2GBx2
[本体] AviUtl99d3
[使用フィルタ] Lanczos 3 -lobed (SSE整数 1280x720) / 自動フィールドシフト (映画/アニメ)
[ソース] 適当なアニメのオープニングから1000フレーム抜粋 (33.299 secs)
[テスト用オプション]
--progress --crf 20 --aq-mode 0 --qcomp 0.6 --qpmin 8 --qpmax 24 --qpstep 8 --scenecut 75 --min-keyint 1 --keyint 240
--8x8dct --partitions "all" --bframes 3 --b-pyramid --bime --weightb --direct "auto" --subme 6 --b-rdo
--me "umh" --merange 32 --ref 5 --mixed-refs --sar 1:1 --threads "auto" --trellis 2 --no-deblock --cqm "flat"
--no-fast-pskip --no-dct-decimate --level 4.1

「Seraphy氏ビルド」
(x264gui.877) エンコ終了時間 [03:31]
SSIM Mean Y:0.9943675
PSNR Mean Y:48.608 U:50.849 V:50.392 Avg:49.033 Global:45.352 kb/s:8234.48
encoded 803 frames, 5.18 fps, 8234.85 kb/s
28,410,720 バイト

(x264.871.GUI最終版) エンコ終了時間 [02:57]
SSIM Mean Y:0.9943825
PSNR Mean Y:48.648 U:50.868 V:50.424 Avg:49.067 Global:45.350 kb/s:8223.77
encoded 803 frames, 5.65 fps, 8224.13 kb/s
28,374,877 バイト

「VFR maniac氏ビルド」
(x264_EXPERIMENTAL_rev877-release1/Psy RDO) エンコ終了時間 [02:50]
SSIM Mean Y:0.9939543
PSNR Mean Y:48.458 U:50.715 V:50.285 Avg:48.884 Global:45.210 kb/s:8679.08
encoded 803 frames, 5.87 fps, 8680.63 kb/s
29,903,754 バイト

※あくまでテスト結果です。私はOreAQ派なので
(Seraphy氏のx264OreAQ.871.release01)で様子見。
OreAQ.877のGUI版が出たらまたテストするかもしれません。

>>250->>252
AviUtl総合スレッド46
http://pc11.2ch.net/test/read.cgi/software/1212669676/

877になってusing cpu capabilitiesにSSE4とか出るようになったけど
SSE4使われてるの？

>>253
せっかくテストしてくれてるのに、そう邪険にするなよｗ
まぁSeraphyさんとこのBBSに書いた方がよかったのかもな

ここでテスト結果書いても意味ないだろう…。
まだオプション内容どうしようとかならわかるが。

　　　　　　　　　　　　　＿＿＿＿
　　　　　　　　　 ,....:::´::::::::::::::::::::::￣｀::ヽ、
　　　　　　　 ,..::´::::::::::::::::::::::::::::::::::::::::::::::::｀:.、
　　　　　　／:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ﾍ
　　　　　/ /::::::::::;＿t､i､;メﾚ'ﾚ-､::::::::::::::::::::::::ﾍ
　　　　/　ﾚi:::::::/　　　　　 l　　　｀i:::::::::::::::::::::::ﾍ
　　　 /ｨ　/:::::/　　　　　　 ':,　　　レ‐‐､:::::::::::::::l
　　　l::::ﾚi l::::/　　　　　　、　ヽ_　 {l　 ,.｣::::::::::::::::l
.　　 l:::::::::!:::/__,..ｫ'　　　　 ￣　ヽ、!t'´:::::::::::::::::::::}
.　　l::::::::::::::l　　　　　　　　　　 　 ゝ|:::::::::::::::::::::::::}
　　l::::::::::::::l ､＿_,　　　　 =r==､‐'　|::::::::::::::i'~Y::::l
　　|:::::::::::::|　l:ミ}　　　 　　lミﾐﾘ　　|:::::::::::::::|/）}:::l
　　|:::::::::::::|　ﾏｿ　　　　　　ゞ‐' 　 .|::::::::::::::l}ﾉ.,:'::l
　　l:::li::::::::|　 ~　　　　　　　　 　　 |::::::::::::::レ:::::l
.　　l::l.i::::::ﾊ　　　　 　　　　　　　　l::::::::::::::::::::::::l
　　 l:| ';:::::::へ、　　(⌒　　　　　　l:::::::::::::;::::/ﾚ'
.　　 !　ヽ:::::::/.＞.､_.｀てﾉ＿　　 ,ｲ:i:::::::／ﾚ'
　　　　　｀ヾ!　　 　 二=7ヽ/ ,.ｨ' ﾚj::／ ＼

しかし同じオプションで3分が3分半になるってのはちょっと考えものだな

数値だけなら871がまともだな
VFRのはファイルサイズが大きくて低画質とか駄目だろ・・・

>>259
VFRのはパッチ当てまくりな上に、それで追加されたオプションがデフォルトで有効になってたりする。
--fast-ref-searchとか。

そんなわけで同じオプションを与えても同じ動作にならない。

--rdcomp-psyってすげーサイズが膨らむんだな。
crf下げた方がいい気がしてきた。

--no-psy で無効化になるのかな

>>262
無効化は--rdcmp ssdな。

連レスすまん。

--aq-mode2ってさcrf環境で意味あるのかなぁ？
2pass環境なら効果が有効的なのは理解できるけど
各フレームに必要だろうビットレートを割り振っていくcrfで
フレーム間のビットレート割り振りってどうなん？

暗部ソース抜き出してエンコしてみたんだけどビットレートが
下がるだけで画質低下まねいただけなんだが。

>>264
ｔｈｘ　

>>264
まずはAQがどんな事をしているのか勉強しろ、な？
話はそれからだ。

>>264
うっせー、おまえはﾁﾝﾁﾝｼｭｯｼｭしてりゃいいんだ

　　　　　　　　　　　　　　 ＿
　　　　　　　　　　　　　 /　　＼―。
　　　　　　　　　　　　（　　　　/　　＼＿
　　　　　　　　　　　　 /　　　　　　　/　　ヽ　　　／￣￣￣￣￣
　　　　　　　　 ...―/　　　　　　　　　　＿）　　＜　ちんちん シュッ！シュッ！シュッ！
　　　　　　　　ノ:::へ＿　＿＿　　　　/　　　　　 ＼＿＿＿＿＿
　　　　　　　　|／-=o=-　　　　　＼/_
　　　　　　　/::::::ヽ―ヽ　-=o=-＿（::::::::.ヽ
　　　　　　｜○/　。　　/:::::::::　　（:::::::::::::）
　　　　　　｜::::人＿＿人:::::○　　　　ヽ/
　　　　　　ヽ　　　＿＿　＼　　　　　　/
　　　　　　　＼　 |　.::::/.|　　　　　　　/
　　　　　　　　＼lヽ::::ﾉ丿　　　　　 ／
　　　　　　　　　　しｗ/ﾉ＿＿_-イ
　　　　　　　　　　　∪

　　　　　　　　　　　　　　 ＿
　　　　　　　　　　　　　 /　　＼―。
　　　　　　　　　　　　（　　　　/　　＼＿
　　　　　　　　　　　　 /　　　　　　　/　　ヽ　　　／￣￣￣￣￣
　　　　　　　　 ...―/　　　　　　　　　　＿）　　＜　ちんちん シュッ！シュッ！シュッ！
　　　　　　　　ノ:::へ＿　＿＿　　　　/　　　　　 ＼＿＿＿＿＿
　　　　　　　　|／-=o=-　　　　　＼/_
　　　　　　　/::::::ヽ―ヽ　-=o=-＿（::::::::.ヽ
　　　　　　｜○/　。　　/:::::::::　　（:::::::::::::）
　　　　　　｜::::人＿＿人:::::○　　　　ヽ/
　　　　　　ヽ　　　＿＿　＼　　　　　　/
　　　　　　　＼　 |　.::::/.|　　　　　　　/
　　　　　　　　＼lヽ::::ﾉ丿　　　　　 ／
　　　　　　　　　　しｗ/ﾉ＿＿_-イ
　　　　　　　　　　　∪

Fix regression in r850
Bug resulted in rare incorrect chroma encoding

なんで>>264が叩かれてるのか理解できんｗｗｗ
AQの動き理解した上でmode3がcrfで効果的なのかどうかの
話題ふっただけだろうに。

ここでのﾁﾝﾁﾝｼｭｯｼｭは半角が正しいしきたり

大誤爆orz
mode3じゃなくてmode2だったorz

そういやmode1ってstrength0相当なんだよね？
これってVAQ2.0modだとどういうことなんだ？
昔みたいに自動でstrength値を算出していくってことで良いのかね？

>>271
空気読まずにキリ番ゲットするからじゃね？

1024x576 24Bit AVC1 29.41fps 43676f 2410.41kb/s
MP4A 48.00kHz 16Bit 2ch 193.56kb/s

普通はフレームレートが29.97fpsになるはずなのに29.41fpsになってしまいます。
どこかの設定がおかしいのでしょうか？
初歩的な事ですがお願いします。

>>275
http://pc11.2ch.net/test/read.cgi/avi/1199434632/

「afsを使っている」とか？

>>276
そこで質問したら追い返されました…
>>277
使っています。使わない方がいいのでしょうか？

xx264に1�rも関係無いと思うが。

AFSの意味分かってんのか？
そうでなかったら出直して来い。

>>280
自動フィールドシフトの事ですよね。
初歩的で場違いな質問かもしれませんが教えてください。

★逆テレシネプラグイン
　●可変フレームレート出力 for AviUtl
　　ttp://www.tenchi.ne.jp/~yoko/aviutl/
　●自動フィールドシフト インタレース解除プラグイン
　　ttp://www.geocities.jp/aji_0/


　＊プラグインに関しての質問や論議はスレ違いですのでコチラへ↓
　【ガタガタ】逆テレシネ化研究スレ【言わせない】
　http://pc11.2ch.net/test/read.cgi/avi/1069838918/


★対極スレ
　インタレ解除しないスレの3っぽいスレ
　http://pc11.2ch.net/test/read.cgi/avi/1186448899/

　【至高】 インタレ保持vsプログレVFR 【究極】
　http://pc11.2ch.net/test/read.cgi/avi/1090377667/


★まとめサイト
　アニメのフレームレートまとめwiki
　http://anime-framerate.sakura.ne.jp/

とりあえず、ここは場違いってLvじゃ無いから、上記のどこかで質問してください。

psyRDOが公式に組み込まれそうな雰囲気だな

psyってアニメ限定だといらなそうな感じ。実写は知らない。

>>281
29.41fpsは平均値だよ

ひょっとして120fpsはほんとに秒間120コマだと思っていたクチか。

x264の話しよ？ｗ

x264でもaviコンテナでは表示上120fps
mp4コンテナでは29.41等の平均値

afs使用結果、平均29.41fpsになるようなソースって、ほぼ全体が60iで少しだけ
低フレームレートのプルダウンってafsに判定されたという事かな？
するとそれって実は100％60iのソースでafsが少し判定ミスしたってことかな？

FPS混在のコンテンツなんて山ほどあるぞ。
アニメなんて本編24のCG部分30（29.97)やOPEDだけ、なんてことも。

山ほどってｗ
VFRにするべきソースなんてアニメくらいしかなくね？

確かにそうですな汗

音楽PVもVFRのが結構あるよ
30pの中に、24pの映画のワンシーンを挿入とか、よくあるパターン

ドキュメンタリーもそういうの多いよ

アニメに限って言えば24や30混合って確実に減っているけどね
セルからCGへの過渡期は18とか20とか想像を絶する酷さだった
それに比べれば今は楽で幸せ

どっちだよｗ

>>293>>294
なるほど、そういうのはエンコした事ないから知らんかった。

>>295
今でも通常のアニメーション部分は実質20fpsもないけどな。
むしろCGの部分がぬるぬる過ぎて逆に違和感あったりｗ

勿論>>290は俺>>289宛じゃないよな？

いつまでこのスレ違いの話を引っ張るんだよ

アニヲタは隔離した方がよくね？

アニヲタを隔離したらこっちが隔離状態になるんじゃね？

>>298がどこまでわかってんのかわからん。

ソースいったいなんなんだよ？

>>298は>>290の俺に何かしらむっとすることがあったから
そう返してるんだろうけど、それ以前の書き込みから
ｆｐｓやａｆｓやVFRのこと何も知らないんじゃないのか？と
思えるからそう答えたんだ。

自分の力量棚にあげて
バカにしやがって、と腹たてるんなら他いってくんねえかな。

おまえが消えろ

はいはいｗやなこったｗ

>>304はID:3kUYUuHvに対して満足のいく答えを用意できるんだろ？
それもできないのにただ消えろって言ってるだけ？ｗ
ワケもなくイライラして掲示板むいてないんじゃな〜いｗ

>>297
いや、そーいった平均fpsで20ではなくオフライン編集とかで
強引に時間を合わせるために24を伸ばして18とか20になって
フィールド分解もできなく涙目になるタイプ
ここ数年はさすがに見かけない

ごめん、アニヲタだから引っ込むｗ

　　　　！
　　　∧∧
　　（　･ω･）
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／
￣￣￣￣￣￣￣


　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／

俺宛だったのか>>290は。
>>302>>303
俺は>>289と>>298以外現行スレでは書き込んでないが。
なぜ俺が>>275の奴のソースの中身を知ってないといけないんだ？

もう一度言うけど、平均29.41fpsっていう数値について考察してるんであって、
24.78fpsとか25.19fpsとかじゃないんだよ。

スレ違いだバカヤロウども

補足というかレスし忘れた：
確かに>>293>>294の可能性もあるね。
でもテレシネシーンの全体に占める割合ががかなり多くないと
平均が29.41まで下がらないんじゃないかな。

スレ違いは謝るよ
俺のIDでもNG指定してくれ

こういう流れになるから、初心者にレスしなくなったんだよな

自分のせいでスレが荒れてすみません。

ソースはアニメではなくて普通のバラエティー番組です。

以降スルーでよろしく

KMPlayerで再生すると終盤部分で再生がストップしてしまう。。。

More tweaks to me.c
Added inline MMX version of UMH's predictor difference test
Various cosmetics throughout me.c
Removed a C99-ism introduced in r878.

Fix regression in r736
r736 added intra RD refinement to B-frames; however, it is possible for subme=7 to be used without b-rdo.
This means intra RD isn't run, and therefore it is possible for intra chroma analysis to not have been run, since update_cache was never called for an intra block, and chroma ME is not required even at subme=7.
r801, which removed a memset, made this worse because previously the chroma prediction mode was at least initialized to zero; now it was not initialized at all.
Therefore, --no-chroma-me, --subme 7, and no --b-rdo had the potential to crash.
This change restricts intra RD refinement to only be run when --b-rdo is enabled (sensible to begin with), thus preventing a crash in this case.

(･c_･`)ｿｯｶｰ

だから取り合うなと。
ここでフレームレートの話してるやつらも初心者と一緒だろ
24,30,60f混合なんて見ればすぐ分かるだろうに

自己紹介が続きます

- Fix regression in 64-bit in r882
i_mvc needs to be 64-bit when used with a 64-bit memory pointer

馬鹿なレスの多さにDarkShikariさんが苛立っててｶﾜｲｿｽ

英語赤点だけど、ｒ878は実験バージョンってこと？

実験バージョンじゃないrevなんてあるの？

無いな。ロールバックだってするし
しょっちゅうバグフィックスしてる

自分はmodifiedがリリースされたrev.を一応のstableってことにしてある

http://forum.doom9.org/showthread.php?p=1148754#post1148754

>Quote:
>Originally Posted by MasterNobody
>>Probably deadzones are used even with trellis=2 because trellis is used only for luma plane compression, and not used for chroma planes.

>This is correct.

>Also note that deadzones are used for RDO when trellis=1, and even in trellis=2, deadzones are used for B-frames unless b-rdo is enabled.
>Finally, even if RDO is on all frametypes, deadzones are still used for fast P-skip decision.

おっと間違って書き込みボタン押しちゃった
>>327はタメになる情報だと思ったので転載してみた

いつの間にか --subme 7b なんてのが出来てたのか。

作ってる連中も少しはオプションを整理して軽量化する方向性に目を向けてくれ

よく分かんないけどcore60で使える演算命令が減ってて(939 Athlon64
これは完全にintelユーザー向けにシフトしたってこと？

SSE2が遅いと使わなくなったんじゃなかったっけ？

AMDだと、PhenomのSSE2は速いそうだ。

Help x264 development: x264 assembly test part 2
http://forum.doom9.org/showthread.php?t=138508

>>331-332
少し前にK8でもSSE2の方が速いから
ある部分(忘れた)のMMXのasmを消したというのがあったのは覚えてるが。

AMD Athlon64 X2 4800+

x264 core:59 r859 ce13bb6
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
encoded 2706 frames, 5.71 fps, 2140.51 kb/s

x264 core:60 r880 2389de2
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
encoded 2706 frames, 5.61 fps, 2130.94 kb/s

たった5回ずつのテストなので正確じゃありませんが手前の環境ではこうなりました
何か重要な更新があればcore60に乗り換えればいいのかな自分の場合

>>335
俺の場合Phenom9850ではr883の方が速かったよ。少しだけどｗ

r859
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
encoded 1000 frames, 8.61 fps, 2483.09 kb/s
encoded 1000 frames, 8.64 fps, 2483.09 kb/s
encoded 1000 frames, 8.69 fps, 2483.09 kb/s
encoded 1000 frames, 8.64 fps, 2483.09 kb/s
encoded 1000 frames, 8.68 fps, 2483.09 kb/s

r883
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
encoded 1000 frames, 8.81 fps, 2464.79 kb/s
encoded 1000 frames, 8.77 fps, 2464.79 kb/s
encoded 1000 frames, 8.78 fps, 2464.79 kb/s
encoded 1000 frames, 8.78 fps, 2464.79 kb/s
encoded 1000 frames, 8.87 fps, 2464.79 kb/s

FastとSlow・・

>>337
>>333のLink参照
Athlon 64: SSE2Slow
Pentium-M: SSE2
Core 1: SSE2
Phenom: SSE2Fast

ほんの僅かだけど容量も違うね。これの差と思えばいいかな

Cosmetics and loop unrolling
GCC is not very good at loop unrolling in cases where it can perform constant propagation, so the unrolling unfortunately has to be done manually.

Use aligned memcpy for x264_me_t struct and cosmetics

- Add more inline asm and a runtime check for MMXEXT support
x264 will now terminate gracefully rather than SIGILL when run on a machine with no MMXEXT support.
A configure option is now available to build x264 without assembly support for support on such old CPUs as the Pentium 2, K6, etc.

r886はまた何かAQまわりが変わったんだろうか。
r883に比べて成績が若干悪くなった。

うむ俺は880でいいやって感じ

r889
- mc_chroma_sse2/ssse3
- checkasm --bench=function_name
- interleave psnr/ssim computation with reference frame filtering, to improve cache coherency
sse2/ssse3復活？？？

浮動小数点のSSE3使っても意味ねーだろ

>>344
浮動小数点の意味は？？？

更新履歴ってどこで見れるんだ？gitになってからよくわからんprz

>>346
ここ
http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog

おーｻﾝｸｽ

>>344
SSE3じゃなくてSSSE3だよ。
そんでSSSE3は整数演算だよ

x264.871.GUI(ver0.2)
がデフォルトでpsy有効なんだっけ？

つ--longhelp

cmpドロップして調べてみたけどrev850〜871間で調べてみあたらなかったからlonghelpでは調べられないかと思ってた。
検索しても引っかからなかったんだがなぜだろう

通常版だからじゃないか？　psyが乗っているのはpatchかoreaq

x264.889.release01.rar

もうバグフィックスや挙動改善だけにして機能追加は勘弁して欲しい

たとえバグがあっても、常に進化し続ける。
それが永遠のベータ版たる、x264の宿命。

いんや、PAFF対応するまでは死んでも死に切れん

インタレ保持はバカのすることだ。

アニヲタ乙

インタレ最高じゃん
マシンパワアが低くても手軽に60fpsを楽しめる
動くことこそが動画の本懐なんだから・・・
まあプログレ60fpsに全てが移行すれば一番いいんだが

なんか急にエンコ速度が倍近くかかるようになった
毎週録画してるアニメだし、かけてるフィルターも同じだから変わらないと思うんだけどなぁ
変わったことと言えば、CPU使用率が70%前後だったのが、90〜100%前後に上がった事くらい
原因がわからん

速度が倍近くなったのか
時間が倍近くかかるようになったのか
どっちだ！

いつもエンコ開始した直後にリビジョンアップが行われるのは何故なんだぜ。

>>362
すまん
時間が倍かかるようになりました＞＜

>>363
よくあること

r880から様子見してたけど、そろそろ切り替え時期なのかしら

SSIMは上がってるけどエンコ時間が長くなってしまった

>>366
r883までは保証する。r886は何か怪しい。r889はまだ試してない。

機能このままでいいから、CUDA実装してくれないかな
容量よりも時間の方が気になってきた

おれもあと望むのはまともなインタレ対応だけかな
期待するだけ無駄だとは分かってはいるけど

>>369 あちこち記事があるけど、癖がある上にCよりもアセンブラに近い書き方しないとたいした性能が出ないらしい
演算性能が汎用CPUの10倍って言ってるから、それでも早いんだろうけど・・・

r777からの乗換えでr888 狙っていたのにｽﾙｰされた


r999出たら呼んでくれ

うちの環境だとr889エンコ時間多少早くなった

軽く報告

SSIM比較用ソース用意しておこうかな、アニメのOPとかで
もしかしたらお前らは当然のようにそうしてるかもしれないけど
暗いシーンと激しいシーンが多いやつがいい

ハルヒとシャナ二期
どっちもソースからしてビットレート足りてないが。

x264でCPUのベンチしてるレビュー記事とかってある？

何が知りたいのか知らんが、45,65mmの違いならほとんどないべ
Q9450 Q6600両3,2Gでエンコやってるけど、cliでならそこまでの差は感じない

45mmプロセスルールっていつの時代だよ

知り合いの工場では今現在進行中。

45mmか･･･見てみたい気もする

ダイサイズは長安ぐらいか。

実写だとSSIM Mean Y:0.9829541程度が限界だ…orz

数値を上げたいだけなら -q 0 でそうぞ

訂正：ど

妖精の声が聞こえてる

>>377
Phenom(半)対応マザーでAthlonX2使ってて、Phenom行くかC2Q行くか悩んでる。
デュアル同士ではE8300が6400+に多少勝ったからコアの性能ではCMAの勝ち。
けれどマザーとセットで入れ替えると値が落ちてきたQ6600でもずいぶん掛かるんで、
CPUだけで入れ替えられるPhenom9750がC2Qだとどの程度に相当するかと思ってね。
他のアプリでのベンチ参考に探してみる。65nmと45nmの差が大きくないと聞けてありがたい。

このジャンルに限ってはPhenomよりC2Q
L2キャッシュの容量差が大きい

なぁ、VAQ2.0mod時のaq-mode1ってどんな処理になるんだ？
mod前はsensitivity0.0扱いだったと思うんだけど、modもこの動作でOK？

2回エンコードすればわかるでしょ

コーデック最新にしてエンコ無事終わって　
携帯に入れるために変換君で再エンコしたら

映像がコピーガードみたいに乱れた。おかげでいろいろ直している内に
元のコマンドに上書きしちゃって貴重な貴重な前の安定してたコマンド
がわからなくなってパニックになってパソコン破壊しそうになった。
なんとか復旧したけど不完全。

ｼﾈﾔ。
俺のメモ

　　　　　！　　！　「　　「　　8　　　5　　　1　　」　　」　　で　　安　定　　！　！

コーデック？

それx264安定どうこうより、お前のバックアップ能力云々だから。

x264全然関係ねえじゃんｗ

>>390
この人いきなりどうしちゃったの？病気なの？

パソコン破壊してここから居なくなってくれればよかったのに

かわいそう・・・

あれ・・・ギアスなんでか48fpsになる

ギアスは普通の速度で作った戦闘シーンを尺に合わせて早回ししてるみたいだからな
たとえば昨日の蜃気楼がサクラダイト弾からビームをたくさん出すシーンでは
光線の動きをスリリングにするため60fps回し

マジかよ、どうしたらいいんだ

セル版買えよ、っつー嫌がらせだな。徹底しているなぁ（棒

1期は周期一定24fで楽だったのにな

>>399
つVFR

>>402
60fpsに対応したVFRなんてあるのか

へ？24fps〜60fpsのVFRできてるけど？

mp4 or mkvだけどな。

最近は嘔吐の意味でVFRって言うのですか？

ごめん、手動でやれってことか。でもそれは勘弁。

-wって重いオプションだって聞いたがありとなしで比べると
-wのあるほうがエンコ速くなるのって俺だけなのか？

>>408
俺は重くなったぞ。

>>408
んなわけねーよｗｗｗｗｗｗｗｗｗｗ

Pen4-3.4G orz　(using cpu capabilities: MMX2 SSE2 SSE3 Cache64)
--bframes 16　→　27.01 fps, 1071.13 kb/s　SSIM Mean Y:0.9950049
--bframes 16 --weightb　→　27.10 fps, 1031.00 kb/s　SSIM Mean Y:0.9949421

あ…れ…？　
b-rdo、bime も入れてみたが、超軽量設定のこれでは、同じ結果になった。

ところで、話題がなければ、ipratioとpbratioについて語ってもらいたいです。
自分で試せと言われたらおしまいですがorz

b-frame16とかだと、私はpbratio 1.1ぐらいにしたくなりますが、みなさんどうしてますか？
qcompと合わせて考えた方がいいのかな…。

b-adapt入れてればデフォルトで問題ない。
変化が大きければ勝手にPフレームが入るから。
アニメとかなら8割以上Bフレームはスキップフレーム（前のPフレームから変更無し）だし。

最新パッチ当ててみたけど、幸せなほどサイズが増えたのは俺だけですか

小出し過ぎて答えようが無い件

>>414
幸せなら良いじゃないか

安価ミス
>>413だった

psyのせいだとエスパー

869からのうｐだったのだけど、アニメSDサイズ一話で400Mって('A`)

別に400Mくらい普通じゃん。

オプション付けまくって今３０分に８時間かかるんだがまじめに-wとると３０分伸びる

君らアレだろ、ろくに更新履歴も--longhelpも見てないだろ。
一生同じリビジョン使ってろ

stableなrevとdevなrev分けて欲しい

x264にstableなrevなど存在しない

>>423
まぁ確かに

# recommended revision
って書かれてるのだけ使う、のはだめ？

- Convert NNZ to raster order and other optimizations
Converting NNZ to raster order simplifies a lot of the load/store code and allows more use of write-combining.
More use of write-combining throughout load/save code in common/macroblock.c
GCC has aliasing issues in the case of stores to 8-bit heap-allocated arrays; dereferencing the pointer once avoids this problem and significantly increases performance.
More manual loop unrolling and such.
Move all packXtoY functions to macroblock.h so any function can use them.
Add pack8to32.
Minor optimizations to encoder/macroblock.c

久しぶりに来てみたが・・・そんなに変わってないみたいだな〜
むしろﾏｽﾞｰなほうこ

まもなく900番台か
800番台はなんかアレだったな

安定しているかは別として高速化とビットレ最適化は進んでるんじゃない
AMDの自分にはあまり関係無い話だけども

>>412
レスありです。　デフォのまま行こうと思います。

結局、気の向いたときに新ver試すしかないと思うんだが。
なんか事件があればこのスレで騒がれるだろうし。

最新パッチあてたけど、なんか圧縮率あがってる気がしないでもない

891の更新はジャギを出にくくしつつ圧縮効率を良くしたって書いてあるっぽいとおもうのだが
英語苦手なので間違ってるかもしれないけど

890の間違いだった

□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

↓どうぞ

(ﾟДﾟ)ｳﾒｰ

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