x264 rev17

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

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

[本家]
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 rev16
http://pc11.2ch.net/test/read.cgi/avi/1219480206/

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

テンプレ続く>>2-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"

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"

テンプレ
>>3-5

テンプレ
>>8-1000

>>1
おつ

>>1
彼

>>1
の

>>1
ち

今efエンコしてるんだが、EDで必ず画像が崩壊する。おそらくDeblockが誤作動起こしてるんだと思うんだが、Deblockを切る以外で改善方法とかないかな？
http://www2.imgup.org/iup697132.png.html

>>12
まずはエンコ前の段階で崩壊してないかどうか。
x264のオプションについて問うならオプションを晒す.

すまん。PCでの書き込みが規制されてて、携帯からなんだ。だからオプション書くのはきつい。Deblockはデフォ。exeはSeraphy氏の最新版。

ちなみにエンコ前は崩壊してない。ちゃんとAvsPで確認済み。

>>12,14
デコード

>>15
FFDShow最新版。

ICCが遅いのは--aq-debugのせいで確定っぽい。
--aq-debug切ったらICCが一番速くなった。

ICC
Elapsed Time: 0:18:19.927
Process Time: 0:30:28.703
GCC
Elapsed Time: 0:21:05.821
Process Time: 0:35:10.093
GCC Core2指定
Elapsed Time: 0:19:59.507
Process Time: 0:32:18.125

ffdshow最新といってもいろんなbuildがあるからな
他のデコーダを試すか問題の箇所付近を切り出してアプ

>>16
デコーダオプション
遅延時のH.264ブロック低減スキップ

のチェックボックス

DeblockをOFFにするのはさすがにまずいだろ。てかそのチェックボックスがどこにあるのかわかんね。

デコード側じゃなくて、エンコ時に対策できないか？
てか、これってx264がブロックノイズだと誤認識して、こうなってるんだよな？違うのかな。

あ、そのチェックボックスみっけた。外してみたが変わんなかったわ。

できればそのファイルを見せてくれ。

>>20
エンコ時の対策とかは1PCのために100PCを犠牲にするようなもの
--no-deblockしかない

22の通り

ふむふむ、最小化しても経過がわかるようになったのね

>>17
予想通り--aq-debugでしたか。常用するオプションじゃないから、動く人はICC版の方が良いのかね。
（ICC版でサイズが2MB減るってやつ、SSIMはどうだったかログ残ってたら教えてほしい。）

>>20
ffdshowを使っているようなので。
古い(2008/07以前だっけ？)ffdshowでGIT版の--psy-rdを使った動画を再生すると、まれにブロックがグズグズに
なったような映像になる場合があるよ。
俺も最初はx264の不具合かとおもったけど、ffdshowのバージョン上げたら同じシーンで正常再生されたので、
いまではffdshowのバグだったんだろうと思ってる。

失礼。インストール履歴と手前のメモ見たらバージョン分かった。
ffdshow_rev2026_20080625_clsid.exeで異常な再生結果を確認してる。多分これ以前は全部なんじゃない？
ffdshow_rev2079_20080815_clsid.exeで直っていた。

あの整数電波どうにならないのかよ。

マジでうざい。

>>25
書いてないけどログはAQ以外全部違った。

ICC
x264 [info]: SSIM Mean Y:0.9842201
x264 [info]: PSNR Mean Y:46.127 U:49.478 V:50.208 Avg:46.994 Global:46.474 kb/s:6608.87

GCC
x264 [info]: SSIM Mean Y:0.9840349
x264 [info]: PSNR Mean Y:46.092 U:49.461 V:50.189 Avg:46.963 Global:46.450 kb/s:6780.55

>>27

前スレの整数のこと？
次ぎそう言うのが続いたら>>3のMPEG-4 AVC/H.264 総合スレに
早急に誘導した方が良いね。

本来なら、個人ブログでやってもらうのが一番良いとは思うけど。
お互いに注意してやりましょう。

>>27
ID:WdD/9C6rは他の情報提供もしてるし、ソースからICCの遅さの原因を割り出す事が出来る人だったけど、
ID:Ugi+GhIpは文句言うだけのただのゆとりでした。
ということで決着がついたようです。以後、整数、実数はNG推奨でｗ

そういうのが続いたらって蒸し返しに乗っかって続けようとしてるのは自分自身だろ

>>28
わざわざありがとう。
そっちでも、ICC版の方がサイズは下がるのにSSIMは上がるという謎現象がでてるね。
これが理由で、実写でVAQ使いたい時にGCC版使うのに抵抗があるんだよなぁ

>>27 >>29 >>30
ごめん、反省してる。その話題にはもう触れないよ・・・

>>30

こんだけ、周りから注意されても蒸し返して自画自賛してバカか？
自演もうざいからさっさと消えて下さい。

すまん。いままで我慢してきたがつい言ってしまった。

とりあえず、もうやめて欲しいです。

ID:Ugi+GhIp = ID:ZqwLu92tということは分かった。

まだやっているのかよ・・・・・・・・・

2chだから反対意見が出るのは当たり前だろ。

自分の意見が認められないからっていつまでのスレ違いの話題を
延々と続けられても迷惑なだけなんだよ。

自分の意見を書きたいなら>>29の言うとおり、反対意見のでない
個人ブログでも書き込んでこっちにリンク貼ればいいし。

だいたい、スレの終わりに

991 名前：名無しさん＠編集中[sage] 投稿日：2008/09/27(土) 14:51:06 ID:/WdLNWp1
ID:Ugi+GhIpがカスだということはわかった

みたいに喧嘩売ったら次ぎスレに続くに決まっているだろうが。
少しは冷静に考えてみろよ。

おれがID:Ugi+GhIpだ

>>36
おまえが冷静になれよ。長文ウゼェ

荒らしに構うやつも荒らし

ID変えて自演する小汚いやり方が気に入らないんだよ。

さてと、H.264Divxβ3でも試してみるか。

>>32
x264のSSIMは簡易版だから小数点以下2桁までしか精度ないよ
PSNRで比べる方がいい

--psy-rd切ると差がかなり縮まった。でもやっぱりちょっと違う。

x264patch.988.release01
なんか始まってすぐに落ちる。もう眠いんで987でとりあえずエンコして
寝る。

ありゃ、書いてなかった。
ICC
x264 [info]: SSIM Mean Y:0.9844627
x264 [info]: PSNR Mean Y:46.192 U:49.021 V:49.811 Avg:46.962 Global:46.438 kb/s:5830.56
GCC
x264 [info]: SSIM Mean Y:0.9844629
x264 [info]: PSNR Mean Y:46.193 U:49.021 V:49.811 Avg:46.962 Global:46.438 kb/s:5830.68

俺は全部自分でソースからビルドしているから
他人の作ったビルドの差異なんてよく分からないな。

すごい中途半端で終わっていたから気になって
>>1のソース見てみたけどデータ型は

整数>>倍精度実数>単精度実数の割合だったよ。

実数の割合は全体の10%も無いと思う。殆どが整数。
だから正確には実数だけは間違いで、
実数の割外が多いなら正確じゃないかな^^

参考までに。

間違えちゃった。

だから正確には整数だけは間違いで、
整数の割外が多いなら正確じゃないかな^^

に訂正^^

今更その話を蒸し返すなよ
それにx264のソースなんかどうでもよくて整数だけでH264のデコードができるのかで揉めてたのに
バカ丸出しだぞ
ソース読むだけなら誰でもできるんだよ

だから整数だけではエンコードもデコードもできないってｗ

作って見せて欲しいよ。>>1のソース見てごらんよ。

整数だけではエンコードもデコードできるってそもそもどこから来た情報なの？

だから話がループするからやめれ
俺は当事者ではないからどうでもいいんだよ
噛みついてくるな

できるできないで言えばできるが正解
しかしそんな面倒臭いことを全ての計算式に入れる奴はいないので、
その辺で両者が対立してたんだよ
論理的思考と現実的思考の違い

>>52

とりあえず、個人的な考えだったということでおｋなわけね。

まあ、いいやせっかく調べたのにバカ呼ばわりさせたしもう寝るか。

>>50
>>52

831 名前： ◆47o/marumo [sage] 投稿日：2007/08/30(木) 00:34:33 [深夜] ID:nBwr0KCS
>>818
H.264 のデコード結果は YUV ではバイナリ一致するよ。規格に適合してるデコーダなら。
まず実数演算は排除されてて、整数演算しかなくて、そのうえ '+', '-', '*', '>>', '<<'
だけでデコードできるようになってるから。
デコードだけなら 16 bit 精度の整数演算だけで実装できるようになってるのもホント。
ついでにいうと JM とデコード結果が YUV でバイナリ一致しない場合、規格に不適合な
デコーダ呼ばわりされる。
規格書いっぺん読んでみることを勧めておく。

実際馬鹿だしなぁ。
マツダの車一台調べて、世のエンジンはすべてロータリーだって発表する様なもんだ。

ID:Q5UDR8xS が超弩級のバカ野郎だということだけは理解できたよ

>>55はx264 rev9からのコピー
同じ事を>>25は前スレの最初の書き込みで言ってる。

950 名前：名無しさん＠編集中[sage] 投稿日：2008/09/27(土) 00:23:29 [深夜] ID:WdD/9C6r
>>944
H.264で整数演算だから誤差が発生しない云々は復号（デコード）でしょ？
デコード方法が数式まで厳密に定義されていて、+,-,*とビットシフトだけで出来るように規格化されているから、
デコーダによる差は映像面では発生しない。速度面は別だけど。

どっちが正解か、ここの住人はとっくに知ってるからスルーしてたんだ。もういい加減にしてくれ。

>15

ffdshowは最新版でもlibavcodecのバグで映像が崩れる場合がある。
（ひどいブロックノイズみたいな）

今のところCoreAVCかPDVD使うしかない。

http://i38.tinypic.com/2wp0bde.png

psyrd使うよりcrf1落としたほうが画質的にも速度的にも良さそう

988で始まってすぐ落ちる問題だけど、ちょっと試したところ
--aq2-strength --aq2-sensitivity
を削ればちゃんと動くみたい。他に同じような症状の人いない？

使ってるbuildがどれなのかぐらい書けよ
r988での変更はエンコには直接関係ない部分だからパッチで不具合が出てるんじゃないの？

r988
Make x264 progress indicator more concise
Now the % indicator should be readable on the header of a minimized window on Windows systems.

aq2なんてもうないでしょ・・・

>>61
それを言ったらcrf1落としてpsy-rdも入れたら更にいいだろ

いつのまにかrev992になっている件について

seraphy GUI ノーマル版
rev987 動く
rev988 動かない
rev922 動く

なんだったんだろう…、988だけ何かバグってたのかしら？

r992 OreAQ itvfr
ttp://www1.axfc.net/uploader/File/so/11732.zip
x264itvfr.exe…CPU指定なし、SSE2まで有効
x264itvfrcore2.exe…Core2指定
x264itvfrk8-sse3.exe…k8-sse3指定
x264itvfrk10.exe…K10指定

もう994が出てるよ。
typoの修正とロスレスの変更だけだから次でいいか…

1000まで待つか

K10指定をseraphyﾀﾝも取り込んでください＞＜

YOUビルドしちゃいなYO!
VFR maniac氏が解説してくれてる。
zoome動画: x264gui.auoのビルド - VFR Studio Returns(仮)
ttp://zoome.jp/VFR_maniac/diary/9

結局994もビルドしますた。
ttp://www1.axfc.net/uploader/File/so/11741.zip

>>72
超乙

CUDAに対応しないかな〜

CUDAでx264使えるようになるかもしれないけど、普通はデコード、フィルタ処理をGPUに任せたほうがいい気がするう

H.264は並列化が難しいからな

まあ普通は2スレッド以上は非常用だから問題ない
エンコ専用機でも電気効率考えると1スレのほうがいいだろうし
よほどエンコ量が多いなら仕方ないけどね

逆に何本もエンコするなら2本同時に走らせればいいだけだもんな

そういやCUDAでH.264を再生するのがあったな

MP4Plugin 20080928

CUDA使うとDGAVCDecみたいに金取ったりして

r995
Fix potential miscompilation of some inline asm
Caused problems under some gcc 4.x versions with predictive lossless

あと5！

??-??-08: 1000: revision 1000 party at pengvado's villa
??-??-08: 1000: donate 1 million euro to make revision 1000 version 1.0

r1000でversion 1.0になるのか
pengvado氏の別荘でお祭りが開かれるようで

俺、招待されたヽ(´ー｀)ノ

100万€！？

そしてうｐするのを忘れてた。
r995 OreAQ itvfr
ttp://www1.axfc.net/uploader/File/so/11766.zip

�@r953 AQmode2 (qcomp1.0)
�Ar995 AQmode1 qcomp1.0指定 psy-rd0.0:0.0
他共通で設定同じだと思うんだけど

アニメ１本エンコしてみたら
�@が230MB
�Aが328MB

AQか何か変わってた・・・？

ちょっとパーティー行ってくる

一発芸でコーラ一気飲み披露したいけど外人にうけるかな？

メントスと一緒にならウケると思う

飲み慣れてる外人に普通じゃね？って言われたりしたら嫌だな。

キュウリ味のペプシ持ってくと驚くぞ

>>86
っ --longhelp
っ readme.txt

qcomp 1.0 とaqの併用って効果あるの？

一日中設定弄ってたら頭おかしくなってきた

vFR乙

OreAQのICC版ってr988から廃止になったの？

普通に最新版にも入ってるじゃん

設定変えたら100MB以上縮んだ(^o^)

>>97
すまん、忘れてくれ
寝ぼけてパッチ版をダウンロードしてたorz

>>92
やっぱAQの違いみたい�d

そろそろインタレの改良とかやらないかなぁ・・・

x264って静止画をエンコードするにも異様な時間がかかるよな
何を計算してるんだろう

角度とか

>>102
それは単に無駄なオプションつけてるだけなんじゃないのか？

静止画なのにモーションサーチを無駄にがんばっているとかいうオチ。

>>100
--aq-sensitivityのデフォルトが変わった。

いつの間にやら--aq-sensitivity 10がデフォになったね

967最強伝説

>>107
馬っ鹿、お前ぇ！
最強は798って相場が決まってんだ若造！

967だと、r987のﾃﾞﾌﾞﾛｯｸﾊﾞｸﾞﾌｨｯｸｽとr976のﾚｰﾄｺﾝﾄﾛｰﾙ改善が気になるｗ
色々と速度は改良されてるわけだし。

ﾃﾞﾌｫ設定使ってるｵﾌﾟｼｮﾝも記述しといた方がいいと思う。 存在を忘れ去らないためにも。

アドバイスを貰っておきながら、そういえばレス返してなかったことに気づいたorz
ありがとう。

aq-mode2とb-adapt2で縮めまくれればpsyでのレート増加分も気にならなかったかも

なぜ過去形・・・
昔のaq-mode 2が、いまのaq-mode 1になったんだから、aq-mode 1とb-adapt 2で出来るでしょ。

今のaqめちゃ膨らまない？
strength下げて使うことにしたけど

デブロッキング　オフにした方が自分の好みに合うみたい。
固定品質モードでエンコしてるんだけど、オフにしたら　ちょっとサイズが
膨らむ。

のっぺりした感じになるのが嫌いだからデブロックいらね

デブロック使わないなんてx264を使うメリット半減な気が

デブロック無しのDCTは、DWTに負ける。

CRF,bframes2で使ってるけどb-adapt2ってすっごい強力なのな
しばらくx264追うのやめてて損してたわ…

俺みたいなイージーユーザにはb-adapt2使えば
無理にsubme上げなくてもいいな

rdo廃止してsubmeに統合ってなんかVFWみたいなインターフェースだな

>>199
個人的にはそれでいいんじゃないかと思う

>>199に期待

>>199
ノーベル賞決定

なんかエラい変更ですな

ビットレートがんがん使うような設定ならデブロック無くても別に良い

デブロッキングフィルタの制御SEIに対応してたら最強なんだが

Rework subme system, add RD refinement in B-frames

The new system is as follows: subme6 is RD in I/P frames, subme7 is RD in all frames, subme8 is RD refinement in I/P frames, and subme9 is RD refinement in all frames.
subme6 == old subme6, subme7 == old subme6+brdo, subme8 == old subme7+brdo, subme9 == no equivalent
--b-rdo has, accordingly, been removed. --bime has also been removed, and instead enabled automatically at subme >= 5.
RD refinement in B-frames (subme9) includes both qpel-RD and an RD version of bime.

二桁にいきそうな勢い

seraphyビルドﾏﾀﾞｰ

>>126
--subme 7 --b-rdo --bime
↓
--subme 8

とりあえずr996からこうしておけばいいのかな

>>128
漢なら--subme 9と比較して結果をここに貼るべきだろ！
っていうかお願いします。

--crf 20 --threads 3 --sar 4:3 --aq-strength 0 --bframes 6 --psy-rd 0:0
--qcomp 0.7 --qpmin 1 --qpmax 51 --qpstep 16 --min-keyint 1 --keyint 240 --scenecut 70
--8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --b-pyramid --weightb --b-adapt 2 --direct "auto"
--me "umh" --merange 64 --ref 6 --mixed-refs --trellis 2 --cqm "flat" --no-fast-pskip --no-dct-decimate

--subme 8
Elapsed Time: 0:12:03.484
Process Time: 0:19:04.203
x264 [info]: SSIM Mean Y:0.9838314
x264 [info]: PSNR Mean Y:45.769 U:48.443 V:49.302 Avg:46.516 Global:45.943 kb/s:3971.71

--subme 9
Elapsed Time: 0:12:47.331
Process Time: 0:21:09.531
x264 [info]: SSIM Mean Y:0.9838349
x264 [info]: PSNR Mean Y:45.772 U:48.447 V:49.307 Avg:46.520 Global:45.948 kb/s:3952.52

PSYRDOが吸収されたってこと？

ごめん、素で読み間違えてたよ。

--b-rdo と --bime が吸収されたってことか

ま、俺は問答無用でsubme9一択のバカですから

俺は今まで通りsubme7でいくわ

>>134
今まで通りsubme7ということは前はsubme6+brdoでやってたんだよな？

996ktkr!

おろろ･･･ もっとズバッと行くかと思いきや微妙。速度上がってるし^^;　psyとdeblockを0にするの忘れたし、996同士でやれという話も。
無茶苦茶だが、とりあえずやってみたので晒し。
--crf 20 --keyint 240 --min-keyint 24 --scenecut 70 --qpstep 12 --qcomp 0.7 --ipratio 1.4 --pbratio 1.3
--b-adapt 2 --bframes 4 --b-pyramid --weightb --partitions p8x8,b8x8,i8x8,i4x4 --8x8dct --ref 6 --mixed-refs
--me umh --merange 16 --trellis 2 --direct auto --aq-mode 1 --aq-metric 0 --aq-strength 0.5:0.5 --aq-sensitivity 11
--psy-rd 0.5:0.0 --no-fast-pskip --no-dct-decimate --cqm flat --deblock -2:-2 --sar 40:33

995 + --bime --subme 7 --b-rdo
x264 [info]: slice I:89 Avg QP:19.00 size: 21843 PSNR Mean Y:50.72 U:52.76 V:52.85 Avg:51.22 Global:50.62
x264 [info]: slice P:1097 Avg QP:19.94 size: 12762 PSNR Mean Y:48.59 U:50.85 V:50.81 Avg:49.17 Global:48.61
x264 [info]: slice B:1152 Avg QP:20.72 size: 3273 PSNR Mean Y:47.90 U:50.30 V:50.03 Avg:48.48 Global:47.89　
x264 [info]: SSIM Mean Y:0.9929018
x264 [info]: PSNR Mean Y:48.327 U:50.650 V:50.503 Avg:48.909 Global:48.298 kb/s:1617.04
encoded 2338 frames, 2.45 fps, 1617.26 kb/s

996 + --subme 9
x264 [info]: slice I:89 Avg QP:19.00 size: 21843 PSNR Mean Y:50.72 U:52.76 V:52.85 Avg:51.22 Global:50.62
x264 [info]: slice P:1097 Avg QP:19.95 size: 12911 PSNR Mean Y:48.59 U:50.86 V:50.83 Avg:49.18 Global:48.62
x264 [info]: slice B:1152 Avg QP:20.71 size: 3274 PSNR Mean Y:47.92 U:50.31 V:50.06 Avg:48.50 Global:47.91
x264 [info]: SSIM Mean Y:0.9929073
x264 [info]: PSNR Mean Y:48.340 U:50.662 V:50.527 Avg:48.922 Global:48.315 kb/s:1630.50
encoded 2338 frames, 2.58 fps, 1630.72 kb/s

997
Fix minor memory leak accidentally added with the addition of b-adapt 2

>>137
追記：画質はかなり改善されてた。subme 9個人的にかなりオススメ。

>>137
PSNRはそこまで大きく変化していないようだけど>>130の結果を見ると処理時間は増えてるんだよね
crf20では見た目の差はそんなに出ないと思うんだけど
まだ試してないけど--subme 8でいいや

ごめん　デブロック　オフにしたらH.264使う意味なかったよ。
オフにしたら同一ビットでXvidに負けてて落ち込みました。
アニメはデブロックと相性がいいからx264でいけるし、クリア感がアップ
するように見える。　実写で使うのはあきらめた。　Xvidで充分。
H.264は家電や放送で採用されてるから現時点で最高の選択と思ったんだが
必ずしも業界標準に追従することが最良の選択になるとは限らないと感じた。
さようなら

エンコードの行程でH.264がMPEG-4 ASPのそれよりも、効率で劣る部分はあるのかな。

またかよ、いちいちオプション変えるのﾏﾝﾄﾞｸｻ('∀`)
とか思ったが --subme 9 って画質良いな(;´Д`)ﾊｧﾊｧ

どうでも良いけど画質比較したいなら2passにしたほうがいいぞ

・・と書いておかないとまた画質悪いとか言い出すアホが出てきそうだ。

r998
r996で一行抜けてました。テヘッ♪

>>141
気づくの遅い

Fraternity7に一発で分かる訳載った

何か斧が全然繋がらん。死んでるのか？
r998 OreAQ itvfr
ttp://upload.jpn.ph/10/bin/bin0025.zip.html

commit cc510478de710f86ab400f610b6e075304d902cb r999
Date: Thu Oct 2 20:57:08 2008 -0600

rm gtk, avc2avi.
I don't remember why I allowed a gui into the repository in the first place. There's nothing that makes this one special relative to all the other x264 guis.
avc2avi doesn't compile since we removed the bitstream reader. And avc doesn't belong in avi.

９９９キタァ！祭りが始まるっ！

r999
要らんもん削除だからエンコには影響なさげ

あと一つ！

ver1.0になるんだろ？
そう書くと積み上げたものが薄っぺらくみえるな

999a

ﾀﾀﾞﾉﾘﾋﾞｼﾞｮﾝﾅﾝﾊﾞｰﾆｲﾐｦﾐｲﾀﾞｿｳﾄｽﾙﾁｷｭｳｼﾞﾝﾉｼｺｳﾊﾘｶｲｺﾝﾅﾝ

aviutlみたいに永遠に999で行って欲しいぜ

>>144
それは画質良くなったとか言ってるやつも同じだな
>>137=>>139とか絶対わかってないｗ
適当なこと書くやつが多過ぎる
subme8と9の違いなんて人間の目で見たって殆ど違いがわかるはずないのにｗ
ほんの少しの違いを積み重ねていって初めて人間の目でわかるレベルになるというのに

submeは画質の違いというよりファイルのサイズの違いだな

それにしても大学から帰ってきたら999になっていてびっくりしたわ
1000は来て欲しいような、来て欲しくないような...

俺も半年ぶりに大学行って帰ってきたら
submeが9もあってびっくりしたわ。
いつのまに2つも増えたんだろ・・・

どこで聞くのが一番いいのかわからんのでここで聞いてみようと思うんだが
SDサイズで60iな動画をエンコしてるんだがx264でmp4作成するならフィールドオーダーは
どっちにすべきなんだろうか？

というのもvlcで再生する時やffdshowでHWデインターレースする場合はBFFで再生されるんだが
PSPだとTFFで再生されるんだよなぁ

なにかエンコード時やMux時にオプションで指定できたりするんだろうか

x264のインタレは互換性つーか解除時の動作に問題が出るから
今は使うのはやめておいた方が無難。
とくにPC以外で再生する場合ね。

rev1000でver1になるんだろ。その次はどうなるんだ？
ver1.001なのか、ver1rev1とかになるんだろうか

ならねーよｗ

rev999.1がきます

普通にrev9991だろうな

rev.999α

Profile High @ Level 5.1を4.1に変更したいんだけど、
バイナリエディタでどこを変更すればいいの？
詳しく書いたサイトとかあれば教えてください。

>>166
ggrks

>>155
2passではやってくれてる人がいたし、subme6→7ではサイズ縮んで画質も落ちたとかいうことも聞いたので、crfでやってみた。
積み重ねて~人間の目ではわからん、というのは同感だけど、自分的にはssimを比較した印象より良く見えた、と言いたかった。
勝手にオススメ宣言したのはスマンorz　　なかなかの費用対効果(?)だと思ったので。

2passで比較って言うけどさ、普段crfしか使わないしその中で
特定のオプションを変えるとどう変わるかって言う自分指標なら
いちいち2passする必要なくね？絶対的評価求めてるわけでも
ないでしょ？

そう思うなら、チラ裏にでも書いとけよ
ここに書いても混乱を招くだけ

>>170
ここになに書いてあったって結局は自分で試すだろ？
混乱なんかしないよ。それとも鵜呑みにしてなにもしない人？

>>159
x264でフィールドオーダなんて指定できたっけ？

できたとしても結局ソースに合わせるのが一番なんじゃ…？
再生環境によって動作が違うならそれは再生側の問題かと思うんだが

また変なのが食いついてくるな
自分でも試すし有益なデータがあれば参考にもするだろ
ただ自身満々に画質がうｐしました！とか書かれてもバカだなあと思うがな

ええい、1000はまだか

開発陣による壮絶な1000獲り合戦が繰り広げられてるんだな

変なの＝tobinaka

それはもう持ち上げなくて良いから。

実写のdeblockはどのくらいがいいんだろ

--filter -1:-1くらい

--deblock から --filterになってたのか...
俺もいい加減バージョンうｐしないとな。

志村っ！　逆、逆！

>>169
RDOとかTrellisってのは、1%の画質低下があったとしても、2%の符号量削減があるならそれを取る　という理論
だから、submeの5と6を-q指定で比較すると、ソースによって画質が悪化するものと向上するものに分かれたりする
ビットレートがずれるからそう見える

ようは、その時見えた画質の向上は「たまたま」そうなっただけで、
実質的な効果が見えたわけじゃないかもしれない　ということだよ。
ま、submeの数値上げて2passで画質が悪化するなんてあり得ないはずだけどね。

うちqpstep ずーっとデフォ（4）なんだけど、いじるのが常識なんだろうか

>>183
8くらいにしてる

>>183
うちのqpstepさんもずっとずーーーっとデフォのまんま弄ったことない

俺は --qpmin 1 --qpmax 51 --qpstep 16 なんだが

ttp://x264.nl/
x264.nl supports danceradio992.cz both online and on air! Commercial Free!
Dance Radio 99.2 FM Amsterdam True Free Uncensored Pirate Radio. Soulful Dance!
とか太字で書いてるけど前までこんなの書いてたっけ？

>>184-186
レスさんくす。みんなバラバラなのね・・・

--qpmin 1 --qpmax 51 でいいよ実際おかしな数値になるほど暴れないから

qpmax30で使っててやっぱ小さすぎかなと思って40にしたら
何も変わらなかった

まあ余裕をみて10-40ぐらいが妥当だろう

>>184
同じく

r1000こないな。何かでかいの準備してたりするのかな。

CUDA対応

>>190
qpstepを上げておかないと影響出る場合もあるよ
crf20 min10 max30 step10にしてる　実際はQP15〜25位で変動してるんだろうな

はっきりQPを制限したい場合以外は広くとってもまったく問題ない。
むしろ動静の激しい動画に対してはqpstepはデフォじゃ小さすぎると思う

AQってqpstepの範囲中でしか働けない？
そしたら、平坦な中を移動する輪郭線とか、QP下げ損ないそうで心配。

捕捉：マクロブロック毎に掛かるのか、それともフレーム平均QPに掛かるのか　という事でした。

>>199
YES ﾁﾝﾁﾝｼｭｯｼｭ

>>197-198
フレームの基準QPに対してどのくらい上げ下げって感じでかかる。
なのでqpstepはAQの動作に直接は関係ない。
間接的にはqpstepによってフレーム間のQP変動が変わるから関係するだろう。

r1000来ないね…

きっとPAFF対応のために、大幅にコード書き換えてる最中なんだお！！


>>264YES ﾁﾝﾁﾝｼｭｯｼｭ !!!

>>202
んなことになったらxvidの立つ瀬がなくなってまうがなｗ

明日は月曜日、平日だからきっと1000がリリースされるさ！

>>200
レスthx。　それなら、そこまで大きくしなくても良さそうですね。

>>202
PAFFはずっと期待してるけど、みんな大した物が無いからr1000踏めないだけだったりして＾＾；
出来上がった奴を、間違いないように総員で念入りにチェックしてるとかなら、嬉しいけど。
それにしても900番台は良かったな。

ここでまさかにロールバック

蟹？

>>203
絵作りの質が違うし、好きな人はいつまでもXviDにいると思うぞｗ

PAFF欲しいなぁ…
MBAFFが結局adaptiveじゃないならPAFFの方が効率が良いと思うんだが

たぶんPAFFが実装されても結局は非adaptiveだろうけど

adaptiveにするには現ピクチャと披参照ピクチャのFrame/Fieldが異なる場合に
大部分の処理で参照先ピクセルを切り替える処理が必要になるからなぁ

でも…非adaptiveでもいいから欲しいっ
再生互換性重要だよ…

RD == RD mode decision; use RD to pick which macroblock mode to use.

RD refinement == do the above, and after deciding which mode to use, refine the mode:

1) For intra, do RD optimization for selection of intra prediction modes.
2) For inter, do RD qpel motion search.
3) For bidir, do RD bidirectional motion search.

だってさ。

ほう

更新ないせいか過疎だな

嵐の前の静けさってやつだろうな

interlaced処理をadaptiveにして符号化効率が5％よくなる代わりにエンコ時間が倍です
とかだとためらうな。ていうか判定処理が必要になるからエンコ時間延びるのはほぼ不可避だけど。

私はBobでいいや。

>>215
MBAFFをadaptiveにしたら倍どころじゃすまない悪寒…
全てのMBでFrame/Field判定するんだぜ？

インタレ保持はRDとかエンコ速度の問題じゃなくて
インタレ保持自体が目的だと思うんだが…

つか、今更だがなんでPAFFでなくMBAFFにしたんだろうなぁ

今まで実写素材のインタレ保持のためにx264を使ってたつもりだったのに
xvidでもできると知ってショックを受けた俺
さらにxvidが実写向きと知ってショックを受けた俺

そして必死にxvidに挑戦したは良いが
同程度の画質で3割ほどは増えてしまうのにショックを受けた俺

実・写・は♪　xvidとか〜　最初に言ったのは〜♪　誰じゃああああああ！！

駆け抜けて逝く〜　　漏れらの　CABAC



おっさん乙

それってDivX5の時代の話だっけ

俺も実写でインタレ保持してるが、もう随分前にXvidからH.264に移行したぞ

俺はいまだに両方作ってるなw

アップデート来ないね
リビジョンナンバー付けに迷ってるんですね。

2時間ものとかはさすがにXvid使ってる

いや、パーティーの準備してるんだろｗ

そしてPS3でxvidのASPは再生できないと知ってショックを受けた俺…
こんなことならVC-1に挑戦したほうがまだよかった…

必死こいてxvidのインタレ指定可能に改造したffmpegを
一体どうすればいいんだぉ(´・ω・｀)

>>225
x264.nlにこんなの書いてあるしなぁ

＞??-??-08: 1000: revision 1000 party at pengvado's villa
＞??-??-08: 1000: donate 1 million euro to make revision 1000 version 1.0

ひょっとしてアレか、100万ユーロ工面できないのか。

100万ユーロ寄付が集まるまでリビジョン上げません

>>218
まあ落ちつけよ。　実際はそんなもんだ。
ちなみにx264のインタレは汎用性が低く、PS3とかじゃまともに解除できないから。

やっぱテキトーに最新版してるとダメだな
r967 → --aq-mode 2 --subme 7 --b-rdo --bime
r999 → --b-adapt 2 --aq-mode 1 --psy-rd 0.0:0.0 --subme 9
この設定でアニメをエンコ比較したんだがほとんどの場合後者の方が100MBほどサイズが膨らむ
でもOP単体とか、本編込みでもガンダムマクロスぐらい動とr999の方が小さくなる時もあるんだがなんでだろ？

r967に戻してゆっくりr999の設定を煮詰めるわ

アニメなら --aq-mode 0 でいいやとか思ってる俺。

Doom9ではVAQができた当時から、アニメやcartoonにはVAQ無し+CQM flatが推奨。

つかVAQはアニメには逆効果、動作自体が実写用に作られてるから
JVTマトリクスも同じ

アニメならOreAQじゃないの？

デジャヴ

>>231
968で大分変わった。
概要 (ttp://forum.doom9.org/showthread.php?p=1183537#post1183537)
DarkShikari氏のコメント (ttp://forum.doom9.org/showthread.php?p=1183629#post1183629)
それとb-adapt1→2のせい。 Bフレを使って画質を落としちゃってた場所に、きちんとPが入るようになった。
他のに関しては、AQとPSYは何も変化していないし、submeはそこまで大きな差にはならないはず。

とにかく、容量が大幅に変わったときは、2passしてみて基本的な圧縮の出来を比較しないとダメだと思う。
まあ、より縮んで実際差がわからないなら、それでいい気もする。（自分みたいなクソ目だと静止画鑑賞だし
ただ、それなら999でcrfの値を上げた方が賢いと思われる。

>>233-234
それは+VAQの話でしょ？　ｱﾆﾒに逆効果になる特性を逆手に取って-VAQ(OreAQ/MixAQ)を使う。
jvt/flatの話ならともかく、ちょっと酷すぎないかｗ

向こうではDS作のオリジナルのVAQ以外は誰も使わないのだから、しょうがない。
私も普通の発想とは逆に低周波を削る事には、何か抵抗がある。

私も94x→98x→OreAQ999で設定苦労した
94xの頃はパクリ設定で良く縮んだのに、verUPで容量増加地獄になり
オプションの詳細を調べまくった
最終的にはssimが以前の設定に近づけるようにcrf値を上げたら、前より縮んだ
知らなかったオプションをテンコ盛りにして、速度は落ちたが・・・

撮っておくべきは967か

798,958,967あたりかな

aq-strengthとpsy-rdはデフォ値が高すぎるんだと思う
思いたい

AQ-debugが異常に便利になったよな。 シミュレーション出来るとかびびったｗ　　これならpatch版も試してみるか･･･（ぉぃ
psy-rdが強いのは、実写向けのﾃﾞﾌｫだから仕方ない気がする。 psy-trellisは早く"実験的"外れないかなｗ

ところで、r987でﾃﾞﾌﾞﾛｯｸが変わったと思うんだけど、--deblock 変えた人いる？
俺は -1:-1 と 0:0 で迷ったんだが、SDでは-1か0、HDでは0で決着した。（@ｱﾆﾒ

700番台からいきなり900番台にバージョンアップしてみたけど試行錯誤してようやく設定が決まった
100M近くも縮んで最高

967と999で同じ動画同じ設定でエンコしたが999の方容量増えるな　しかも無駄なオプション増えすぎワラタ

PSNRで比較してみろよ

また967厨が暴れてるのか
オプションは徐々に整理されつつあると思うが
容量を気にするならcrf30ぐらいで使っとけよ

つか、単純に967以降の設定の最適化ができないから967マンセーしてるようにしか見えん
967以降のchangelogを見ればわかるが、けっこう重要なバグfixもあるというのに

開発途上なものに恒常性を求めてどうすんだ。同じオプションで結果が変わることなんて当たり前なのに

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　 　 ,,..､､ri':'ﾞ/~ 　 ﾚ　　 　 '　 ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　 　 　 ＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　 　 '､
/ .） .l::::::::::!　　　　　　　　　　　 　 　 　 　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　 　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　 　 　 　 　 　 ,'
　 ﾞ　 　 ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　 　 ,.r,,iilll鬚髯ｦ 　　　そんなに何も見えてないんじゃ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　
￣￣￣￣￣￣~"''､' ‐ ､ 　 　 　 ー‐ノ 　　　　　生きてても面白くないでしょう
　　　　　　　　 　 　 ',　 ヽ　　　　 　 l
　　　　 　 　 　 　 　 ｌ　　 l　　 　 　 l
　　　　　　　 　 　 　 l　 　 l　　　　 ﾉ

というか、テンプレにchangelog入れようぜｗ ttp://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
revの番号がわかんなくなったら、このサイトが便利 ttp://kar1h3inz.blogspot.com/2008/07/x264-revision-memo-9xx.html

>>251
次の1000からはttp://kar1h3inz.blogspot.com/2008/10/x264-revision-memo-10xx.html

>>251
個人サイトの宣伝にしか見えない

俺は自分でビルドしてるからこっちのが便利だな
rev付きファイル名でtar.gzがダウソできる
http://up-cat.net/cgi-bin/wiki/x264+git+snapshot+proxy.html
CGI直ならこっち
http://up-cat.net/cgi-bin/x264_proxy/x264_proxy.cgi

>>254
おお、便利だな
thx

テンプレに入れるなら公式がいいんじゃない？

>>254は便利には便利なんだが…changelogの取得がx264.nlからなんだよなぁ
なんでgitから直で取ってくれないんだろ

だから俺もテンプレには公式のが良いと思う

鯨を食って何が悪い！

野菜も食ってください

r1000はいつ来るんだ

カンガルー轢き殺しまくってるのに鯨守るとかどうなんだろうねとか思うのは変？ｗ

--crf 22.5 --level 4.1 --keyint 300 --min-keyint 1 --scenecut 70 --bframes 3
--weight b-adapt 2 --direct auto --analyse p8x8,b8x8,i4x4 --8x8dct
--trellis 0 --cqm "flat" --aq-mode 1 --aq-metric 0 --aq-strength 0.5:0.5
--aq-sensitivity 10 --qcomp 0.7 --psy-rd 0 --merange 32 --qpmin 14 --qpmax 30
--qpstep 10 --ref 3 --mixed-refs --ipratio 1.4 --pbratio 1.3 --subme 7
--deblock 1:1 --no-fast-pskip --threads auto --thread-input --progress --sar 1:1
--no-dct-decimate --no-psnr --no-ssim

999でこの設定で絶チルをエンコしてるんだが、音込みで450MB位行っちゃうんだけど
もっと縮めるにはcrf大きくするしかないかね...？

Bフレ増やせば？

サイズ気にしてcrf大きくするくらいなら、bitrateとvbv-maxrateを設定してNpassの方がよくない？

解像度どれぐらいなのか知らんけど1280x720なら500Mまで
1440ｘ1080なら650Mぐらい丁度いい
それ以上だとちょっと大きいかなと思うけど

1280x720なら150から450M
1440ｘ1080なら250から600M

>>261
--merange 32 ならその前に --me umh 使うべきだと思う。
あと、--weight b-adapt 2 これって動くのか。 --weightb --b-adapt2 と同じ結果になるの？
i8x8外す人多いけどなんでだろ。 ﾋﾞｯﾄﾚｰﾄとPSNR/SSIMしか見てないから断言は出来ないけど、入れた方がいいと思う。

ここまで時間と速度の取引だったけど、後はtrellisを切るなら--deadzone-intra/interを調整しないと微妙かも。
crfを変える前に、aqの強さの調節とか。
--chroma-qp-offset とか、qcompやpbratio弄って無理やり削るとかいう方法もある。

あと、サイズを気にせず画質の為に2passするくらいなら、esa/tesa使おうぜ！　（そんな奴いない？
SSE4だと速くなったとか聞いたので前に検証頼んだんだけど、使わわねーって却下されたorz　使わないって意見には同意ですが＾＾；
また低脳が沸いたとか言わないでｗ

umh --crf 20
x264 [info]: SSIM Mean Y:0.9928715
x264 [info]: PSNR Mean Y:49.496 U:52.066 V:52.028 Avg:50.142 Global:49.634 kb/s:4914.79
encoded 2338 frames, 0.66 fps, 4915.12 kb/s

umh --bitrate 4915 --pass 2
x264 [info]: SSIM Mean Y:0.9929131
x264 [info]: PSNR Mean Y:49.497 U:52.086 V:51.988 Avg:50.147 Global:49.662 kb/s:4926.76
encoded 2338 frames, 0.75 fps, 4927.09 kb/s

tesa --crf 20
x264 [info]: SSIM Mean Y:0.9929276
x264 [info]: PSNR Mean Y:49.619 U:52.082 V:52.047 Avg:50.194 Global:49.663 kb/s:4919.18
encoded 2338 frames, 0.49 fps, 4919.52 kb/s

>>262-266　thx!!
あとごめん、解像度言ってなかったね。1280ｘ720です。

>あと、--weight b-adapt 2 これって動くのか。 --weightb --b-adapt2 と同じ結果になるの？
オプション書き間違えてることに今気づいた('A`)でも、これで特にエラー無く動いたんだけど…
後で書き直してもう一回やってみる。

p4x4はともかくi8x8を切る意味は全く無いだろ

--b-adapt2→--b-adapt 2にしないと使えなかったｗ

>>269
デコードエンコードともに遅くなる
画質はほとんど変わらん

ipratioを1.2位にすればどうだろう？IとPのPSNRが逆転しない所まで切り詰める

あとqpminの下げ過ぎって良くないみたい
>>261とほぼ同じ設定使ってるけど
殆ど口パクだけのシーンでPのAvg QPだけ飛びぬけて低くなった
1280x720TSエンコ用設定でcrf21　qpmin17は高すぎかな？
qpmin10 qpstep10で短時間エンコだけど、PのAvg QPが13になったから
今上げる方向で実験中

1280x720なら３０分で700MB、
1440x1080なら３０分で1GBだな。
1920x1080の場合は３０分で1.5GBを目安にしてる。

小ささなんてどうでもいいし、保存は外付けHDDかBDにやけばOK。

とりあえずOPだけやってみて、旧設定→69MB、新設定→60MBで中々縮んだ。
ただやっぱり新の方が遅くなったから、もう一回i8x8切ってやってみる。
意見くれた方thx!

>>271
そーいうのの積み重ねで画質が上がってくもんだと思うけど。
ま人それぞれで良いけどさ

>>272
crfって動きの少ないシーンのqpを下げる制御だもん
気になるならqcompを上げたほうが。

今までイージーユーザだったんだが、のっぺり感が気になってきた
deblock -1:-1に手を出すか悩むけど、cqm/AQも触るべきだとすると大変そう…
実写SDソースならAQはそのままでもjvtなのかなぁ

r02でてるな、なんだろ

掲示板で出てた--8x8dctのオプションが残ってしまうバグの修正かと

自分がかなり異端だということが分かった。
アニメ25分で、1280x720 は2GB、1920x1080は3GB程度を目安にしてた。
実写は更に大きく・・・

TSソースとかわらねーじゃん。

1話2Gとか、BS-iやら超額縁やらじゃない限りCM切ったTS保存した方が幸せになれる気がする

>>279
それってエンコする必要あるの？ｗ

TSよりサイズ大きくなったりしてな

釣りに反応すんなよ

PCの性能が低くてTSを再生しながらデブロックフィルタとかかけられないので、エンコ時に非リアルタイムで処理しておくとか？

まあグレインの多い映画とかだと、ちゃんとグレインを残そうとするとTS並のサイズになっちゃうことがあるけどね。

>>279
それの半分ならアリだと思う。fps24としてね。

色々ご意見ありがとうございます。

もう少しサイズを見なおしてみようと思います。
TSは扱ったことが無いので分からないのですが、
TSと同じサイズなのであれば、MPEG2と同じサイズに
圧縮していたことになるので、やはり大きすぎですね。

地上波15M、BS20Mを目安に、ビットレートをそれに近い
値にしようとしていました。

PV3を使っているので、これでもサイズは1/10になって
いて、麻痺してました。

1080p24をlevel4.1でエンコしたら最大ビットレートが50Mbpsを超えてしまったんだけど
これだと規定以上の数値だからDXVA関係でおかしくなったりするの？

Radeonは40Mbpsまでだから無理だと思う。
GeForceは非公開でコアごとに違うらしいから上位ならいけるかも。

最大50Mbpsの時点でHigh 4.1の規格外だからなぁ
--vbv-maxrate　40000とか追加しとけば大丈夫じゃない？

瞬間的になら少々越えたって問題ない。

>>289-291
自分はGeForceなので規格どうり50000以内にして再エンコしようと思います。
VGAによって対応が違うと知らなかったので参考になりました。

〜通(どお)り

どうりで変換できないわけだ

88GT（G92）だけど
1080p 30fpsだと大体70Mbps辺りからコマ落ちが始まるみたい
家じゃCPUの方が限界高いな

ちなみにDivX 7 alpha 1でエンコードされるはHigh@Level 4だから、最高25Mbit/sまでになる。
これでも、--ref 4になるけど1920x1080 29.970fpsには十分だし、将来リリースされるであろう
DivX 7対応機器やDXVA等との互換性を重視するなら、--level 4を付けるのもいいかも知れない。

>>261 からの流れを参考にしばらく999でやってみるお

i8x8を切っても入れても殆ど速度変わらなかった...
というわけで入れておくことにした。
あとサイズが450MB→385MBくらいまで縮まったのでここには感謝(　´∀｀)

trellisは入れたの？

trellisは入れてない。
暗部でごま塩みたいに疎らにブロックノイズ入ったりすることあるから。
それが凄い気になって、試行錯誤でtrellis切ったらノイズ乗らなくなった。
バンディングがきついシーンもあるけど、ごま塩みたいなノイズより良いかなと。

>>297
>>261のようにオプション書いてほしい。参考にしたい

参考じゃなくそのまま使うんだろｗ

コピペしてバッチに突っ込むだけに５パーティー券

>>261
qpmaxを36くらいまであげろ
qpminを20くらいまであげろ

まぁまずは真似てみることから始まるからね。
でも>>301は少しは自分で考えな。

真似から初めて、良いのに巡り合えたから、そのまま使用。
数ヵ月後verUPして大混乱。ようやく自分設定構築w

>>304
今の設定で十二分に満足だから。あんがとね。

>>306
凄くわかるｗ数ヶ月ﾊﾞｰｼﾞｮﾝupしてないとオプションの理解きついな(´Д`；)

>>306
俺もそんなもん
というかオプションってのはそういうもんだと思っている。最初は真似でいいよね

ということで今の俺のを書いておく

x264.exe --crf 24 --me "umh" --psy-rd 1.0:1.0 --keyint 300 --threads 1 --qcomp 0.8 --qpstep 16
--min-keyint 1 --scenecut 60 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --bframes 3 --b-adapt 2
--b-pyramid --weightb --direct "auto" --direct-8x8 1 --subme 9 --merange 32 --ref 6 --mixed-refs
--trellis 2 --deblock -1:-1 --no-dct-decimate --no-fast-pskip --thread-input --progress
--no-psnr --no-ssim "***.avs" -o "***"

実写です

バージョン変わったらDVDのOPとかで何十回エンコして設定決めるのは基本だろ
最初はパクリでも自分に合う速度と画質と容量に勝手に決まる物なんだよ

つうことで>>301はさっさとパクリ設定でエンコする作業に戻るんだ

rev967 ソースはアニメDVDのみ

--keyint 240 --min-keyint 1 --scenecut 75 --bframes 3 --b-adapt 2 --b-pyramid
--ref 3 --deblock 0:0 --crf 20 --ipratio 1.2 --pbratio 1.2
--aq-metric 0 --aq-strength 0.5 --aq-sensitivity 12
--direct auto --weightb --me umh --merange 32
--subme 6 --b-rdo --psy-rd 0.2:0.2 --mixed-refs --8x8dct --trellis 2
--no-fast-pskip --no-dct-decimate --progress --threads auto --thread-input

ノイズが乗るなぁと思ってたら元々色ノイズが乗ってたってオチがよくあります。
シャナIIのOPとか

俺も貼ろうかと思ったが他のと比べるとそれほど大差ないことに気づいた

ちょｗ
ソースもよく見ずにエンコおっぱじめてる訳？ｗ

似たような設定で安心した・・・

スレチな質問だけど
DVDエンコは前処理のNRどうしてます？（ベタ塗りのザラつき）
x264が重いので、AviUtlの標準NR軽く掛けてるだけなんだけど
x264側の設定を試行錯誤しても、ブロックノイズが気になる
ソースがセルアニメのリマスター版で元からノイズ多い訳だが

低ビットレートのMPEG-2がソースなら、DGDecodeのcpu=6

アニメは知らない。

>>309
なぜ上から口調？

なんかオプション晒し大会になってるけど、結局みんな似たようなもんだよな。違いなんて微妙な好みの差くらいでしょ。

そいえばx264のnrオプションってのもそこそこ使えるんだよな
エンコ後にしか効果が分らんのが厄介だが速度低下がほとんど無いし、劣悪なソースのエンコ時にはビットレートが20%近く落ちてPSNRが0.8上がった

rev999 ソースはタイタニア(アニメ25分)
--crf 23 --aq-strength 0.3 --ipratio 1.7 --pbratio 1.5 --level 4
--qpmin 1 --qpstep 6 --scenecut 65 --min-keyint 1 --keyint 240
--8x8dct --partitions "p8x8,b8x8,i4x4" --bframes 4 --b-pyramid
--weightb --direct "auto" --subme 9 --psy-rd 0
--me "umh" --merange 32 --ref 6 --mixed-refs --threads "auto"
--trellis 2 --deblock 2:2 --cqm "flat" --no-fast-pskip --no-dct-decimate

サイズ：278MB　平均ビトレ：1387　MAX：8398 Kbps
ココの人たちから見れば、お話にならないレベルだと思うんだけど.
>>296　結構縮むものなんですね。

>>301
上に書いてる人と同じようなもん　--crf 20、--me umh
今のところ　--psy-rd と --b-pyramid は使ってない
--deblock は目視でブロック出た時に3:3で使う

ところで自分はDVD-Rにきっちり12話ないし24話収めるためビットレート指定もするんだが
（704が24話で--b 700から800指定）これって変ですかね？

＞〜変ですかね？
そういう感じでの各種設定などを教えあうスレが過去に有ったのですよ。
フィルタの話からコーダの感触など、幅広く書き込みがあった。
別にビットレートが主目的範囲から外れても、とやかく言わずに意見を求め発言をした。
ま、その、なんだ。　ちょっとだけ前の話ですけどね。
もしそう云う話をするのであれば、スレは残っているので盛り上げてみるのも良いかと思います。

【目指せ】高画質アニメエンコスレPart17【軽量】
http://pc11.2ch.net/test/read.cgi/avi/1176620882/

サイズ縮めることに躍起になってるけど何でだ？？
SDなら３０分で350MBぐらいに収まれば１クールがDVDに入るんだぜ？

画質を維持したままサイズを削るところにロマンがあるんじゃないか

DVDになんか入れるの？

>>321
なんとなく理解した。
目標サイズに向けていかに画質高めるかってことか。
目標サイズが違うだけで。

>>322
入れるけど？

DVDにいれてPS3で再生ウマー

>画質を維持したままサイズを削るところにロマンがあるんじゃないか
うむ

ソースごとに悩んでしまう
crfを22にするか21にするか
21という中途半端な数字が気に食わんのぉ(;´Д｀)
でもサイズ的には21もありなのよね

>>325
crfは小数も指定できるからな。
半端な数字を気にすることはない。

SD解像度でアニメならcrf18でエンコしても200MB程度に収まるんじゃないか？
動きが激しいの以外なら。

21で気にしてたら19.5の俺が変態みたいじゃないか

あんま細かいこと気にしてるとマジで禿げるお

主に実写SD解像度だけどcrf24で
　あまり動きのないもの→5分39秒で約38MB(808Kbps)
　激しく動くもの→3分52秒で約96MB(3261Kbps)
4倍以上も違うとかﾜﾛﾀ

そんな当たり前なことを言われても

元のサイズの1/5ぐらいが相場だよね
小さくしすぎると時間ばかりかかってコストパフォーマンスは逆に悪くなる

そうだな1/5が理想だろ。
2.5GB→0.5GB こんな感じがよい

元のサイズって何だ

>>332-333
なんかフワフワした会話だな。
PV4ソースだったら1/5はどうかと思うけど。20GB→4GBとかなるでしょ。
あとコスパは人それぞれ。

当たり前なのはわかってるけどさ…
「ウチのTVパソとどのくらい違うの？」って言われて説明しにくいんだよなぁ
>>332-333みたいにお気楽に言えないところが。

でもまぁSD実写ならCRF24で3.5Mbps以下、CRF20で5.5Mbps以下くらいとか
やっとだんだんわかってきた

とらドラ！が恐ろしくサイズ縮むｗ
1280ｘ720、音160kbpsで140MB弱( ﾟдﾟ)
さすが手乗りタイガーや。

ソースもフィルタもx264設定も違うから何とも言えないが
crf20で250MBいったぞ

一番縮んだのは黒執事で1440x1080のcrf22で300MB切った

>>337
同じなのに200MB弱
まだまだ甘いんだなぁと自覚した

実写でcrf22で500〜600弱なんだが

crfだけでサイズ語っても仕方ないと思うが・・・

サンレッドなら物凄く縮むんじゃないか？
縮まないようなら、まだまだ設定が甘いと言う事

>>340
解像度と尺を書いて欲しかったっす
subme2ってこのスレ的にはカスでうんこですかね？
ソースがMPEG2なのにQPEL処理はあまり意味ないんじゃないかと…

黒執事はこんな感じ r999
--sar 4:3 --crf 22 --ref 4 --level 4.1 --b-adapt 2 --bframes 3 --b-pyramid
--qcomp 0.8 --aq-strength 0.5 --psy-rd 0.5:0.0 --keyint 480 --min-keyint 12
--mixed-refs --no-fast-pskip --no-dct-decimate --weightb --subme 9
--trellis 2 --8x8dct --qpstep 8 --scenecut 65 --me umh

設定は上の流れの通り。
俺はcrf22だから>>338は妥当なサイズじゃないですか？

サンレッドもやってみたいな…でもケーブルTVで映らないんだよなtvk orz

色々なオプションを試しながら残していったら、バッチが20個オーバー
になって収集付かなくなってきた。連続エンコを投入して会社から帰って
来たら、2本目くらいで--b-rdoなんてねーよとか怒られて止まってたorz

bframes 3ぐらいでやってる人多いんだな
アニメならもっと増やしても効果ありそうな気がするんだけど

8使ってる

>>345
r996でb-rdoとbimeはsubmeに吸収されたからな

スペックがクソなので、自分の場合は3辺りが丁度いい。

divx264は-ref 4 -bf 3までしか使えない。

>>348
アナログだったり、地デジだったり、BSだったり、音楽ライブ、アニメ、
SARの違い、それぞれバッチを分けていたら、b-rdoの削除を忘れてた
バッチが有ったようで・・・最低限のオプションを付けて、バッチは一本
にした方が管理が楽なのかな。x264のバッチ沢山と、aacのバッチ2本
と、mp4boxのバッチ2本とで、3本1組のエンコを10組程並べて、一度に
投入してる。

何この流れ…

Bピクチャ8枚連続してる部分を3枚までにしても
PBBBBBBBBPBB・・・　が
PBBBPBBBPBBB・・・　になるくらいだからそこまでこだわる必要あるんかな。
特に--b-adapt 2にしたら予測精度あがるしエンコ時間の伸び考えたら
せいぜい4で十分じゃないかと思う俺がいる。まあ、好みの問題か。俺も前は
--bframes 16とか普通にやってたからｗ

アニメなら俺も--b-adapt 2が出るまで--bframes 16ってやってた。
今でも--bframes 8 --ref 16でやってるけどね(`・ω・´)

ref16って…すげーな。
俺はLevel4に収まる程度のref

お前等今すぐテレビ埼玉見ろ、エロゲーのパイズリシーンが放送されてる
http://tvde.web.infoseek.co.jp/cgi-bin/jlab-dat/s/307228.jpg
http://tvde.web.infoseek.co.jp/cgi-bin/jlab-dat/s/307227.jpg

ところでrev1000ﾏﾀﾞｰ？