x264 rev22

Q ニコニコ・zoome用の動画を作りたい。
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://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)

[バイナリ]
http://x264.nl/
http://forum.doom9.org/showthread.php?s=&threadid=89979
http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/
http://seraphy.fam.cx/~seraphy/index.shtml (ノーマル/afs対応版、patch版、OreAQ版)
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 rev21
http://pc11.2ch.net/test/read.cgi/avi/1237400885/

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

テンプレ続く>>2-4

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

Avisynthを絶讃ιょぅょ Part26
http://pc11.2ch.net/test/read.cgi/avi/1228216385/

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

アスペクト比 part5
http://pc11.2ch.net/test/read.cgi/avi/1240149543/

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。他は各自計算してください。
　　720ｘ480を16:9で見たい時、par(sar)x：yはx：y=480×16：720×9で求められる。
　　1440x1080を16:9で見たい時は同様にPAR4:3

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

その他パラメータの勉強は
Fraternity7
http://ageha909.blog121.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乙ではなくて、わっちの自慢のしっぽじゃから勘違いをするでないぞ！
　　　　　　　　　　　　　 |＼　　　　　　 |＼
　　　　　　　　　　　　　 l lヽ`-‐ '´￣ ｀ヾゝヽ　　つ
　　　　　　 　 　 　 　 　 ｼ~　／" ｀ヽ ヽ　 `､l　　　　　つ
　　　　　　　　　　　　　//, '///|! !‖ ヽﾊ　､_ヽ　　つ
　　　　　　　　　　　　 〃 {_{＼」」 Ｌ|l|／ﾘ ｌ │ |ヽ　　　つ
　　＿＿＿＿.　 　 　 ﾚ!小ｌ●　　　 ● 从　|、|　）
　く　　ﾉ::::::;;;;;;＼. 　 　 ヽ|l⊃　r‐‐v　⊂⊃　|ﾉﾊ´
　　￣￣フ;;;;;／　/⌒ヽ__|ﾍ　　ヽ ノ 　 　j /⌒i !ヽ
　　　 ／;;;;／　　. ＼ /ヽ.|　l＞,､ __,　イァ/　 ///ﾊ
　　／;;;;∠＿＿＿　/ヽ./|　|　ヽヾ、　/,{ﾍ､__∧/ﾊ !
　く:::::::::;'::::::;':::::::;'::::::7ヽ< } / 　 l丶× / ヾ l　l''ﾊ∨

最近のビルドでオススメって、ありますか？
今、seraphy版r1086使ってます

自ビルドオヌヌヌ

http://skystrife.com/x264/
AutoVAQを試してみるのも面白いな。

そういやAutoVAQってどんなものなの？

>>9
AutoVAQは確かに面白い。--b-adapt 2のマルチスレ化パッチは何となくWin上でも
大人しくなったみたいけど、まだまだ一般ビルドに入れるぐらい安定してない
からなぁ… pフレーム用の--b-adapt 2みたいな奴は今年の夏の期待物だけどね。

今日の夜にはまたOreAQあたりを試してみるか…　アレをいつもやろうと思うと
結局ビルドが出来なくて（ｒｙ

　　　　　　　　　　　　　　　　　　　　_＿＿＿＿_
　　　　　　　　　　　　　　　　　　／::::::::::::::::::::::::::＼
　　　　　　　　　　　　　　 　　／:::::::::::::::::::::::::::::::::::::＼
　　　　　　　　　　　　　　 　　|＿|＿|＿|＿|＿|＿|＿|
　　　　　　　　　　　　　　　 　/ 　　　 ＼,, ,,／　　　ヽ
　　　　　　　　　　　　　　（ 6 |　　　─◎─◎─　　|∂)
　　　　　　　　　　　　　　　　（∴∴　 （ o o ）　∵∴）
　　　　　　　　　　　　　　　 　<∵∵　　 ３　　∵∵ >
　　　　　　　　　　　　　　　 　 ゝ　　　　,＿,　　　　 ノ
　　　　　　　　　　　　　　　 ／:::::ゝ_＿＿_＿＿_ ノ:::::＼

>>10
ttp://stashbox.org/502291/x264_AutoVAQ.02.diff
のソースの変化見れば分るけど、可変AQってことで。一応D_S氏はこのAQテクニック
のこと気に入ってるんである程度いい結果出してる。未完成な物という注意だけ
は分ればおｋ。

将来性ありそうだな。期待している

シャナ1期OPをエンコしてみた。　使用したバイナリは、>>9とseraphy氏の1058。 設定はbatch見てください。
ハッキリクッキリアニメもテストしてみたいな。
ttp://kissho4.xii.jp/50/src/5yoshi10531.7z.html (DLkey:vaq)

文削ってたら、何のテストかすら判らなくなってしまっていた＾＾；
OreAQとAutoVAQの比較です。 lowとhighの両方を見てもらえれば嬉しいです。

http://hdimage.org/images/tbzll2u61vjjfl84yz0_autohigh.png
http://hdimage.org/images/lmk0ju54syx32am058eg_autolow.png
http://hdimage.org/images/1hw2qf2tsy8tjnbvzlc1_orehigh.png
http://hdimage.org/images/1jokpgmjq5ja1xrj9bce_orelow.png

同じビットレートの--aq-mode 0もあると、参考になると思う。

>>15
まだテスト自体はダウンロード中だけど、はっきりくっきりならあずまんがの
フラッシュOPとかいつそらのWMVなOPがいいかな(実物のベクター作＆無駄に高い
ビットレートのWMV[もちろんブルーレイなソースも可能])？去年#x264で
いつそらのOP貼ったら結局ソース頼まれて--b-adapt 2が出来た^^;
ttp://forum.doom9.org/showpost.php?p=1164321&postcount=102

いつそらのOP: ttp://www.lumpofsugar.co.jp/product/itsusora/download03.html
あずまんがのOP: ttp://dagobah.biz/flash/Azumanga_OP.swf

あと、一応テストを完成させるため一般AQ版も必要になるのかな？

r1160

いつそらのOP(2)はマトリクス的にもビットレート的にも最適な条件だね

AutoVAQ,OreAQ,AQ無し(OreAQの --aq-mode 0)　で、再度テストしました。
一般AQは、興味が出なかったのでスルーしちゃいました^^;　揃えないと意味無いかなぁ（汗

DLkeyは共通で「vaqtest」です
ttp://2.kissho.org/5000/src/5zen57748.7z.html (いつそらOP 160M)
ttp://kissho5.xii.jp/100II/src/1kichII7588.7z.html (あずまんが大王OP 83.5M)
ttp://kissho5.xii.jp/100II/src/1kichII7589.7z.html (シャナOP 64.6M)

http://hdimage.org/images/ox9yrreyrnjqp6amc7s_normalhigh.png
http://hdimage.org/images/1f5h33dxluszn3lenz7k_normallow.png

http://hdimage.org/images/8y0o361vt3sxj79x1ouh_autohigh.png
http://hdimage.org/images/ovq50n23xgubqypqys4u_normalhigh.png
http://hdimage.org/images/47y0aqi8yvdvs9ygg004_orehigh.png
http://hdimage.org/images/ir3hmz466k75wg07i050_autolow.png
http://hdimage.org/images/haefvvz4ttfehdh1ogq_normallow.png
http://hdimage.org/images/f1ri3cdx5oxrcl7f2mkd_orelow.png
http://hdimage.org/images/0kn0ydvth5axzo90gbs_autoverylow.png
http://hdimage.org/images/tph8972u1c3wm1yv6no_normalverylow.png
http://hdimage.org/images/2frg9ge32aalf0xm4w_oreverylow.png

http://hdimage.org/images/64l42bpc1nzyklqj0xh_autohigh.png
http://hdimage.org/images/qa6ilocav72fxb7gnd0_normalhigh.png
http://hdimage.org/images/ngzysr0bmxibu6us1966_orehigh.png
http://hdimage.org/images/5ixzo7lfkm3qqttybtx_autolow.png
http://hdimage.org/images/7u5g0xgxpq3bid4pb3_normallow.png
http://hdimage.org/images/3pxyvsiwwdcl7blqinj_orelow.png

r1162

一応AutoVAQビルドも追加してみた。
ttp://forum.doom9.org/showpost.php?p=1290539&postcount=1892

>>17-18,20,22
言い忘れていましたが、レスありがとうございます。

ただ、D_S氏によれば「このパッチには、シングルフレームの比較は役に立たない」とのことです。

確かに、動いているのを見て確認するのが一番ではある。

ちょっとスレ違いっぽい話だけど、出力された物を静止画で比較したいときは、Avisynthを使ってる人なら、AvsPが便利なはず。
タブ型のavs作成/編集/プレビューアー(?)なので、DirectShowSource等で比較したい物をそれぞれのタブで読み込めば、
マウスのホイールでタブを切り替えられ、テンキーの上下左右でフレームの移動も楽チンです(全部のタブが同期します)。　スクリーンショットも簡単に撮れる。

seraphy氏のpatch版かOreAQ版でx64なビルド成功した人いる？
ビルド出来たとして、x86と速度的なメリットある？

r1163

ID:PXKsrazG
ID:tvPmCQPi

なんだこのエンコは。人に見せられるレベルじゃないだろう。
初心者スレで勉強してきたまえw

ここのスレのレベルじゃないよ君たちはw

比較だからいいんじゃねーの

>>28
クロスコンパイルしてみた。一応できた。
でもx64環境ないからちゃんとできてるかはわからん。
うｐしようか？CPUの最適化は何がいい？

>>28
WOW64通さなくていい分だけ速くはなりそう。

>>30
このスレのレベルのサンプルをうｐしてくれ

Xvidしか使えないからサンプルなんて出せないよ、こいつ

>>30
かなりうまいエンコだと思うが

この手の下らない煽りは大抵ｗが半角だな。

>>32
速度比較してみたいからうｐ頼むわ。
seraphy氏のpatch版だと嬉しいかも。

CPUはPhenom�UだけどGenericも比較用に一緒にうｐしてくれると嬉しい
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
英語Wikipediaより
Instruction set: MMX, SSE, SSE2, SSE3, SSE4a, x86-64, 3DNow!

ぼかぁ、30さんじゃないけど、なんか云ってみるテストｗ
折角だし全角でｗつけてみちゃうぜｗｗｗｗｗｗｗｗｗ
うはｗｗｗｗｗｗｗｗ「ｗ」つけると、マジうぜーｗｗｗｗｗｗｗｗｗｗｗｗ

ｗゴッコ終わり。
えーと。無理やり苦言を云えば、以下のような感じでしょうか。
…いやね。OreAQって、jvtみたいなマトリクスを使う必要があるんじゃねぇ？
つまり、DC成分小さめ・高周波部大きめなマトリクスを使うと真価を発揮すると思うワケで。
flatにあわせて作ってある+VAQの流れでのAutoAQと、
jvt的なマトリクスが生きる-VAQ風味なOreAQとを、flat比較とかちょいとオカシイ。
悪いとかヒドイとか云う気ないが、上記の意味でOreAQでの練り方が弱い希ガス。

━━━ソレはさて置き。AutoAQ綺麗ですな。＠>>15
マトリクス弄らないでこの絵なワケで、High Profile使えない機器でいい絵出せる可能性とか(ﾟДﾟ )ｳﾏｰ
High Profileにおいても、簡単に綺麗に作れるのであれば便利には違いありません。
なかなかAutoAQ良さそうですね。

　　　　　　　　　　　　　　　　　　　　_＿＿＿＿_
　　　　　　　　　　　　　　　　　　／::::::::::::::::::::::::::＼
　　　　　　　　　　　　　　 　　／:::::::::::::::::::::::::::::::::::::＼
　　　　　　　　　　　　　　 　　|＿|＿|＿|＿|＿|＿|＿|
　　　　　　　　　　　　　　　 　/ 　　　 ＼,, ,,／　　　ヽ
　　　　　　　　　　　　　　（ 6 |　　　─◎─◎─　　|∂)
　　　　　　　　　　　　　　　　（∴∴　 （ o o ）　∵∴）
　　　　　　　　　　　　　　　 　<∵∵　　 ３　　∵∵ >
　　　　　　　　　　　　　　　 　 ゝ　　　　,＿,　　　　 ノ
　　　　　　　　　　　　　　　 ／:::::ゝ_＿＿_＿＿_ ノ:::::＼

凄いのが降臨したな

ttp://www1.axfc.net/uploader/He/so/227970.zip

x64はCore2指定とK10指定と指定なし
x86は比較用に指定なしのみ

動きますように…

thx
今は別のエンコ動かしてるから比較明日になるわ
HDDにコピーしたDVDソースをDGDecode読み込みのみのavsでいいよな
キャッシュとかあるから再起動直後の状態の方がいいのかな？

>>39
流石です。日記まだすか

>>39
OreAQは確かにこのテストだと弱かったなぁって思う。あと、特定のマトリックス
とかを使わないと綺麗にならないとかはちょっと寂しい感じかな？D_S氏があまり
OreAQに興味を持たない理由も一つ分ったような気がしてきた。

AutoVAQは一応アニメだとあまり結果の違いが出ないはずだけど、まぁ悪くない
感じになってるのかな？との一言。

>>43
AVS32/64の間は速度の差があるかもしれないので(avs2yuvで AVS32 -> x264_64
をやるとavs2yuvが少しオーバーヘッドをかかせるし）、一旦avs2yuvでY4Mな
ファイルを作成した方がよさそう。それで両方は読み込みできるし、色んな
他のソフトによる邪魔もなくなるわけだし。

降臨ってｗ　最近のここはすぐアンチアンチで暗くなったもんだ
オレはなるPのマトリクス使わせてもらってるしブログためになったんで応援してるけどな

結局、アニメの様なソースでは、CQMやAQを使わず、flatな量子化をするのが一番無難だと思う。

flatでAQ無しじゃバンディングやブロック化する

多少リンギングが出ても、低周波の劣化がそれ以上に嫌なら、VAQを使うのが良いだろうな。

flatでMixAQを調整するのが良い。
OreAQはどうも良くない。

仕事が忙しくてエンコに触れてなかったけど面白い事になってるな

seraphyおきる。サイトつながらない。

繋がったけど。

>>42動いた？

OreAQはテストしてみりゃわかるけど、見える数字的にはすごく賢いんだけど、
実際の映像みると、だめなんだよな、なぜか。だから使わない。

HCEncに搭載されてるようなAutoMatrixは無理なのかな？

>>55
自動的な可変マトリックスな機能を一応D_S氏が作りはじめたっぽいけど、AQとか
psy-rdの色々に比べてそこまでいい結果でなかったみたい（そういう覚えがある
だけだけどね）。

>>53
>>43

とりあえずx264のOreAQなビルドに今日挑戦してみたらできてしまった（苦笑）
ttp://www.mediafire.com/?nmdz2nqmjti
32bit/64bit(fprofile済み)でHave funっ!

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

すいません、この制限って今のビルドでもありますか？
1080iでもいけてる気がするんだけど、失敗するとどういう風になるんでしょうか？

問題ないんじゃね。厳密にはMBが16x16でインターレースだとフィールドに分けるから
縦は32の倍数じゃないと割り切れないんだけど今はエンコーダーが辻褄合わせてくれてるんだろ

心配なら1088にするとか

なんと丸一日誰もいないとは。週末だってのに。

で>>42誰か試した？

>>62
俺aviutlしか使わないヌルエンコしかできないから試せないんだ。

EVAでも円弧してんだろ

VistaSP2にしたらエンコが遅くなった気がする不思議
MSVCR71.dllとか以前は要求されたっけな

>>42試してみたが動かないわ
crf以外何も指定しなくても
yuv4mpeg: 1280x720@30000/1001fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT

x264 [info]: profile Main, level 3.1
のみで終わる
x86版ならもちろんエンコ始まる
--no-asm付けてもcpu capabilitiesがnoneになるだけ
OSはWin7RCx64
XPx64ならひょっとしたらまた違った結果かもしれんが

当然x264.nlの公式x64なら動いたわ
crf20のみ指定してnullに出力。1280x720だが動き激しすぎなソースだったかも。
x86 encoded 2279 frames, 8.39 fps, 6512.69 kb/s
x64 encoded 2279 frames, 8.76 fps, 6512.36 kb/s
そこそこ有意な差とは思うが微妙に結果違うのが気になる

Doom9で出てたファイルサイズ2G以上ファイル読み込みのバグで嵌ってたっぽい
使ってたtoolchainのバージョンが古かったのかな？
というわけで無事動作。x86より若干速い。最適化での差はあまりなかった。せいぜい0.1fps程度。
しかしavsを読めない、64bit版avisynthは流石にネタに過ぎる、avs2yuvからパイプで流し込むとエンコ終了後のファイルが膨らんだ、
ってので中間ファイル出さないと使えなさそうなのが非常に辛い

crfエンコードでlevel指定をして最大ビットレートを決めるためにvbv-maxrateの使い方調べていたのですが、
説明しているページのいくつかにはvbv-bufsizeも同時に指定しないといけないと書かれているところと、そうでないところがありました。
crfの可変でエンコードしたいのでcbrを有効にするvbv-bufsizeは同時に指定するべきではないと思うのですがvbv-maxrateのみでよいのでしょうか？

例えば、[email protected]に収まる様にしたいのだったら、"--vbv-bufsize 31250 --vbv-maxrate 25000"とすれば良い。
--qpだったら、レートコントロールが出来ないけど、--crfなら大丈夫。

>>70
ありがとうございます。
4.1に収まるようにここの表を参考にしています。ttp://agehatype0.blog50.fc2.com/blog-entry-160.html
ここではlevel4.0の場合最大映像ビットレートが20000で>>70さんと若干違いがあるようですが、
--vbv-bufsizeと--vbv-maxrateの特別な算出方法などあるのでしょうか？

>>71
20000に、それの"表１：Compressed Bit Rate Multipliers for FRExt Profiles"にある1.25を掛けたら25000になる。

http://img199.imageshack.us/img199/1961/levellimits.png

>>72
理解できました、ありがとうございます。

>>70
すみません、各レベルのvbv-bufsizeはどうやって算出するのですか？

>>74
http://agehatype0.blog50.fc2.com/blog-entry-160.html

>>75
すみません、どこに書かれているのでしょうか？

>>76
http://en.wikipedia.org/wiki/H.264
Max video bit rate÷2

>>74
>>72の第6列

x264 [warning]: VBV buffer (78126) > level limit (78125)

まあ、こういう風におかしな数字を指定すれば、x264が教えてくれるから、それで分かるが。

これでいいんじゃない? bufsize
http://rob.opendot.cl/index.php/useful-stuff/h264-profiles-and-levels/

新発想、PCとPS3を繋いで使う
CE-10
ttp://codecsys.fixstars.com/ja/images/products/ce10/ce10_config.jpg
ttp://codecsys.fixstars.com/ja/images/products/ce10/CE-10GUI.png
ttp://codecsys.fixstars.com/ja/images/products/ce10/CE-10Setting.png
・PCのリソースを殆ど喰わない
・FullHDの場合、再生時間の約1.2倍でエンコード可能
・H.264出力

GK乙

年約2万というランニングコストには触れない宣伝乙

あと、個人用とプロ用でビットレートも違う。

なかなか面白い技術とは思うけどな
30nmプロセスとかで更にコア数増やしたcellとか出れば良いのになー

他の技術に使った方がためになりそうな気がする。
PS3いっぱい繋げて演算とか。

ただしエンコの質はお遊び

>>80
それってCellしか使ってないんだから
SpursEngine版とか作ればいいのにな

43 名無しさん＠編集中 2009/06/01(月) 23:30:19 ID:Aasarj5U
720*480 23.976fps 99秒の非圧縮AVIをCE-10含む各種H.264エンコーダでテスト
基本設定はHighProfile/1passVBR/平均1000kbps/Bフレーム3

・ソース非圧縮AVI
ttp://www.dotup.org/uploda/www.dotup.org86065.png
・CE-10 Professional Trial (H.264ES/High/画質優先)
52.7fps ttp://www.dotup.org/uploda/www.dotup.org86073.png
・Badaboom v1.1.1 Trial (GeForce 9600GT）
65.6fps ttp://www.dotup.org/uploda/www.dotup.org86069.png
・Mainconcept (TMPGEnc 4.0 Xpress)
17.2fps ttp://www.dotup.org/uploda/www.dotup.org86077.png
・x264 rev.1148 (AviUtl)
17.3fps ttp://www.dotup.org/uploda/www.dotup.org86155.png

いやもうこれだめだろｗｗｗ
x264より10倍早くてタダで使えっていってもぜってーつかわねー

これはひどい

多分「出資してもらった金は飲み食いには使ってませんよ〜」的なパフォーマンスじゃないのかね。

これだけじゃ判断できないな。
これって入力ファイルや再生環境同じなの？
あと、CE-10以外はエンコーダーの設定とか書いてないし。
CE-10 だけ色空間が違うように見えるし。

>>78
なんか話終わっちゃったてるけど。
その方法で上限確認してみたらこうなった。 これに当てはまる計算方が正しい…のか？
profile Main (YV12)
--level 3.0 --vbv-bufsize 10000 --vbv-maxrate 10000
--level 3.1 --vbv-bufsize 14000 --vbv-maxrate 14000
--level 3.2 --vbv-bufsize 20000 --vbv-maxrate 20000
--level 4.0 --vbv-bufsize 25000 --vbv-maxrate 20000
--level 4.1 --vbv-bufsize 62500 --vbv-maxrate 50000
--level 4.2 --vbv-bufsize 62500 --vbv-maxrate 50000
profile High (YV12)
--level 3.0 --vbv-bufsize 12500 --vbv-maxrate 12500
--level 3.1 --vbv-bufsize 17500 --vbv-maxrate 17500
--level 3.2 --vbv-bufsize 25000 --vbv-maxrate 25000
--level 4.0 --vbv-bufsize 31250 --vbv-maxrate 25000
--level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500
--level 4.2 --vbv-bufsize 78125 --vbv-maxrate 62500

因みに、(--crf 20 --level 4.2) --vbv-bufsize 78125 --vbv-maxrate 62500　の指定あり/なしで試しててみたけど、結果は変わる。　
level指定しただけじゃ守らないってことなの？　どういうことなのか教えて貰えたら嬉しい。

指定有り
avis [info]: 320x240 @ 10.00 fps (167 frames)
x264 [info]: profile High, level 4.2
x264 [info]: slice I:2 Avg QP:21.00 size: 29896 PSNR Mean Y:42.35 U:42.07 V:41.62 Avg:42.17 Global:40.78
x264 [info]: slice P:59 Avg QP:25.27 size: 8196 PSNR Mean Y:37.64 U:39.49 V:38.50 Avg:38.02 Global:37.95
x264 [info]: slice B:106 Avg QP:27.66 size: 5352 PSNR Mean Y:36.43 U:38.44 V:37.08 Avg:36.81 Global:36.67
x264 [info]: PSNR Mean Y:36.930 U:38.852 V:37.633 Avg:37.300 Global:37.118 kb/s:532.05
指定無し
avis [info]: 320x240 @ 10.00 fps (167 frames)
x264 [info]: profile High, level 4.2
x264 [info]: slice I:2 Avg QP:20.50 size: 30729 PSNR Mean Y:42.73 U:42.39 V:42.00 Avg:42.54 Global:41.39
x264 [info]: slice P:60 Avg QP:25.22 size: 8205 PSNR Mean Y:37.72 U:39.52 V:38.55 Avg:38.09 Global:38.02
x264 [info]: slice B:105 Avg QP:27.18 size: 5669 PSNR Mean Y:36.69 U:38.56 V:37.27 Avg:37.03 Global:36.93
x264 [info]: PSNR Mean Y:37.130 U:38.947 V:37.787 Avg:37.480 Global:37.327 kb/s:550.41

クォリティどうのより縞々出てんのがものっそい気になる。
インタレ縞なんだろか。

そりゃ数値によってピークタイムが変わるんだから結果も変わるだろうよ
バッファは再生機器に応じて適正値がいくらなのか異なるが、vbv-bufsizeは許す限り大きな値にしときゃいいんだよ
別に低ビットレートでポンコツPC持った奴に配信したりする訳じゃないんだろ気にすんなよ

やっぱlevel指定だけじゃ、MBrateをチェックしてフラグ立てるだけで、bufsize/maxbitrateは守らないってことだよね。
今のところ不具合は出てないから気にしないけど、DXVA使ったりPS3で見るようなことがこの先あれば心配だな。
…まあいいや。levelも取っちゃえ。

検証乙
ソフト買うよりCPUをQuadに変えた方が良さそうだね…

難しいことを考えずに、"--level 4 --vbv-bufsize 31250 --vbv-maxrate 25000"としておけば、
DXVA等、大抵のデコーダで再生できる。

放送がソースの私の場合、これでビットレートの不足を感じる事は無い。

確かにそうですよね。私も感じません。
ただ、今2passで指定有り無しを試したら、指定有りの方だけちょっと指定bitrateから下がっちゃいました。
あんまり賢いコントロールじゃなくて、その場での切り捨てな感じなのかな？　と思ったのだけ、報告しておきます。

>>91
http://pc11.2ch.net/test/read.cgi/avi/1243826129/53
HDだとギザギザと色空間の問題は直ったみたい。
低ビットレートだと画質の悪さは相変わらずのようだが

HDソースだとCE-10で10.4fps,11.4fpsしか出ないのか・・・いらないな。
x264(CPU E6300)で2.37fps,3.71fpsもでるならQuadかCore i7買った方がよさそう。

>>101
えー
実時間エンコ出来るんじゃなかったの？

速度優先にしないと駄目なんだろう

>>103
またD.S氏に怒られそうだな。
「オプション変えたらx264でも実時間エンコくらいできんだよボケが！」って。
いやホントに出来るのかは知らないけど。

PS3を何台も繋げば早くなるとかないの？

だれかレポ頼む

Win7みたいにCo-processingできたらいいのにね
もちろんAviSynth、AviUtl、VDで使えなきゃ意味ないけど

逆にそれだけの速度しか出ないってことはまともにエンコしてるってことなのかな？
そもそも純粋な演算速度でもCellってi7に対して優位じゃないよね？
だとしたらチューンを重ねてmainconceptにも引けを取らないx264に負けるのは仕方無いような。

何度も出てくる話題だが出来上がっているmp4などからx264のエンコオプション見るソフトってなんだっけ？

何度も話題に上がってるの知ってんなら、過去ログ嫁よ

mediainfo

avinapticかな？

もうテンプレ化でいいべ…
つか自分の確認用（どのオプション、マトリクス使ったかなぁ）ならAvinapticやバイナリ見てる人多いし
どうせ質問してくる奴はﾀﾞｳｿだろ…

自作バッチエンコツールに積んでるわオプション見る機能

NVIDIAがGPUでFlash動画再生支援を提供

http://japanese.engadget.com/2009/06/02/adobe-nvidia-broadcom-flash/

ラデチョンまた死亡

このスレでも工作かｗ

兄ちゃん、ゲフォ厨はなんで必死なん

このスレに限っては_GPU25クローンへの親和性の高さで
RADEON選んでるユーザーが結構いると思うけどな

_GPU25に常用するようなフィルタあるかなぁ
とりあえずSP多いほうがFFT3DGPUとか速そうだからラデ使ってるけど、
最近はDGMPEGDecNVが気になる…デコードとHWデインタレは需要多いと思うんだが

_GPU25は俺も使ってないな
FFT3DGPUは使ってるけど

HWデインタレは使えるようになると嬉しいね
今時のカードならMCBobmodより圧倒的に速くて結果は良いし
綺麗なデインタレースフィルタは遅すぎて正直使い物にならない

デインタレが使えると790GXの俺がついにエンコにまともにGPU使えるようになる・・・
ほんと中途半端なんだよなあ。かといってグラボ必要なゲーム用途もないから買う気にもなれない。

俺も、DGAVCDecNVやCoreAVC CUDAのが気になる

>>122
DGAVCDecNVはNeuron2のエイズが入ってるからダメなものだ。
CoreAVCのCUDAは何となくよくなってるけど、安定してるデコード環境が欲しい
のならCPUだけ使った方がいい。基本的にffms2かDGAVCDecを使ってる。遅いけど
化けたフレームよりマシだ。

>>120
正直NNEDIを使用してるtempgaussmcより綺麗なデインタレはまだ見たことがない。
そのレベルまで上がって、証明できるのならこっちも使うけどね。

ドナルドのエイズってなぁに？

>>123
TempGaussMCは重すぎて使ってなかったんだけど、確かにクオリティは良いね
ただ速度はやっぱり遅いね
個人的にこの速度だとインタレ保持してHWデインタレ使うのが良いように思う

RADEON HD3870 VectorAdaptive
ttp://kita.kitaa.net/10/s/10mai195400.png
TempGaussMC_beta1mod(EdiMode="NNEDI",MT=true)
ttp://kita.kitaa.net/10/s/10mai195401.png
ソースファイル
ttp://www1.axfc.net/uploader/N/so/73114&key=Deint

あれ、なんか抜けた
以前このスレに上がってたファイルで比べてみたを追加して下さい

MTってあるけどTempGaussMCってマルチスレッド対応してたっけ？

TempGaussMC_beta1modがある

あぁすまんよく見てなかった
いつのまにかmodなんて出来てたのな
CPU100%使ってくれればちょっとは速度もましになるか…

スレチだが、BobならTempGaussMCよりMCBobかなあ。 そんなのもあるってことで。
ttp://forum.doom9.org/showthread.php?p=1253486#post1253486

エンコしたデータのcolormatrixをバイナリ弄って変更することってできる？
色域間違えてエンコしてソース消しちまったのがあるんだ。

ざっと--colormatrix指定のファイルをのバイナリ見てみたけど、それらしいのが見つからない…

色々試してみた。
--colormatrix指定してエンコしてれば一カ所変更でできるっぽいけどundefの場合は全く違うバイナリになってた。
その情報自体が省略されてるってことなのかね。

鬱だし脳

undefの場合はフラグ自体がないからね。確認できるツールはあるけど
書き換えるものは知らないな。

あ、そこじゃなかった。もうちょっと弄ってみよう。

>>134
ツールｋｗｓｋ

よく知らないけどh264parseのことかな

undefは全体で数バイト少ない
PV3時代の601と709間違えていたのを指定書き換え用と思って挑戦したけど眠くてあきらめてた

x264_hrd_pulldown.13_interlaceは
前スレで報告されてた2passの問題は解決してるのかな？

>>139
http://forum.doom9.org/showpost.php?p=1288917&postcount=1878

>>140
そのカキコ自体は知ってるけど
2passの問題が解決された、とは明示的に書いてないから確認したかったんだよぅ
どっちにせよクラッシュはしない？みたいなこと書いてあるし

この間、自分でビルドしたバイナリを試した時は2passでも大丈夫だった。

>>142
そうか！ありがとう！

ポケットニュースにCE-10とx264の比較記事きた

PS3高速H.264エンコーダCE-10試してみた: ポケットニュース
http://pocketnews.cocolog-nifty.com/pkns/2009/06/ps3h264ce-10-c4.html

Quad3.6GHzと比べても5倍速いのはかなり凄いな

x264の設定を落としていって同じくらいの画質にしたときにどの位速度差が出るのか興味ある
同じくらいの画質でも倍以上速いなら結構凄いし、速度変わらないなら意味ないし

ループって怖いよね

やっぱフルHD高ビットレートが得意で低ビットレートは不得意か
2pass出来て5Mbpsが使い物になるなら年2万でも買うんだがなぁ

高ビットレートで画質がいいのは「得意」とは言わんだろ

高ビットレートで画質がいいのは当り前だからなｗ

低いでもなく高いでもなく中ビットレートで得意なのを求める

マトリクスの上手い練り方を詳しく説明したところはないだろうか

左上が低周波、右下ほど高周波成分
ぐらいしか俺は知らない（汗

何が低周波で何が高周波なのかわからない俺が退場

>>154
http://upload.wikimedia.org/wikipedia/commons/2/23/Dctjpeg.png

これは8x8の例だが、H.264には4x4も有る。

細かい部分が高周波なの？

そう。

低周波のビットが足りないとブロックやバンディングが出て、細かいところを削りすぎると、
リンギングが出る。

ただし、周波と周波成分は異なるから説明が難しいけどね。

ディテールみたいに細かくても振幅が非常に小さければ低周波成分。
そして、映像各々の部分がマトリクスのどこを判定をしているのか的確に把握するのは難しい。

要するに俺みたいなのはAQ使った方がいいのね。

>>155
なんだか為になったわ、ありがとう

Avisynthにマトリクスをシミュレーションするプラグインがあったはず。

>161
つ AVCMatrices

ttp://www.nnet.ne.jp/~hi6/lab/quantize/index.html
ここは結構参考になるよん

要するにフラット使っとけばいいってことだよ

いい加減その考えは改めた方がいい

Xvid君が本拠地のXvidスレで暴れてるｗ

低ビットレートエンコしないなら、とりあえずフラット使っとくべき

更新ないから退屈だ

追加された機能であれこれ悩まなくていいから楽だ

x264はマトリックスで決まる

私は、VAQが作られてからは、CQMを使っていない。

基本的に開発者の意見を聞くならCQMはVAQと--psy-rdoで何となく無意味っぽい、
分らない人には使わない方がよさそうなものになったみたい。まぁ、オイラだと
最初からあまりCQMには興味がなかったけどねぇ…

HAQﾏﾝｾｰ

>>145
ゴミ画質だな。まだまだ、x264は現役だなｗ

どんな8x8の画像も>>155にある64種類の足し算で再現できるんよ
簡単な例で白ベタ画像だと、一番左上の画像に1.0を掛け、他の画像は全て0.0を掛ける
あとは全部足せば白ベタ画像が出来上がる

なるへそ〜

負け組xvid豚どもがx264を馬鹿にしてるぞ
こりゃキツ〜イお灸をすえてやらんとなｗ
ttp://pc11.2ch.net/test/read.cgi/avi/1229667198/

先導してないで一人で池

Xvidなんてまだ使ってる奴がいるんだな

インタレ保持できるx264が使えて、
3クリックくらいでエンコ出来るソフト教えてー、下さい。
ソースは放送TS。できれば、CMカットとリサイズもできるやつ。
有料でも何でもいいです

ありません
さようなら

ツッコミどころが多すぎて反応できねぇ

>>180
３クリックはムリだろｗ　AvsPでCMカットぐらいしないとｗ
それ以外だと普通にbatファイル作れば簡単。携帯動画変換君のベース使えば
キューっぽいのも出来るし。

Xvid Q=3 VAQ適用　と　x264のcrf22の違いがあまり分からない。
サイズも画質も同じくらいだった。　強いて言うなら Xvidの方がいいような
気がする。　おまえらが言うほど x264は最強じゃねえよ。　SDサイズの動画を
エンコするなら　 1500k〜2000kbpsは当てるだろ。　その位のビットレートに
なったらXvidでも充分きれいなんだよな。　mp3が192kbps以上だとAACとたいして
変わらんというのと似てると思う。　

まぁ自分が好きなの使えってことじゃねーのかな。
漏れはx264とXviD両方使ってるけど。

ageで書かれると説得力も何もないな。

agesageなんてDTV板ではどうでもいい

>>184
そりゃレート上げちまえばどのコーデックでもそこそこ綺麗だろうよ少しは頭使えよアホか

馬鹿は頭使わないのが普通だろ

Xvidがいいと思うなら勝手に使ってろ
別に誰も止めないから

HDならcrfを22より上げてもまだ画質的に「いける」かなと思えるが
SD特にインタレ保持実写は22辺り超えると結構目に見えてボケだすからなあ。
勿論動き予測関連のパラメータやpsy-edやaqの設定次第だが
crf22超えでシャープさも保ちたいならならそれはそれでビットレートも上がるし。
そういう意味では>>184に対する>>188の言い分はどうかな。

アニメなら解像度に関わらず結論は出てると思うが。

http://www.mediafire.com/file/veabjtwiz3m/DivX7_vs_x264_vs_Xvid.zip

例えば、このサンプルでx264が他より酷い部分があるとすれば、それはテロップのリンギングくらいか。
まあ、輪郭の劣化等は、気にならないソースではあるのだが。

Xvid君が珍しくまともな書き込みをしているようです

いまさらxvidと比較することになんの意義も感じられない。
xvidに大きな変化があったなら別だが、この先そういうことはありそうにない。

>>192　貴重な情報ありがとう。　どれも同じやん！　実写はXvidでいいや。
アニメの時だけx264使わせてもらいます。　

1080p未圧縮4:4:4と1080pロスレスAVC4:2:0の比較動画作ってみた。
クロマアップサンプリングの比較に個人的には使っているよ。

http://www1.axfc.net/uploader/File/so/24953
pass:x264

DIGAのクロマの性能が気になるなぁ。誰かレポして欲しい（笑）

相撲自体に興味ないけどテストソースとしてはいいね。

更新ﾏﾀﾞｰ

どうせスポーツでやるなら、サッカーとか大人数で動くシーンが多いソース方が
より適していると思う。

昔バレーをエンコしたらボールが増えたり消えたりして最悪だったわ

魔球みたいだな・・・

現状でスポーツで使い物になるソースなんてあるのか？

このスレでは1Mbps以下の低ビットレートの比較しかしないから
元のソースが破綻しているかどうかよりも動きが多いかの方がより適していると思うけど。

生中継だと画質悪いよね

F1見ているときは、地デジじゃなくてアナログで見ている。
アナログ停波するなら、もっとビットレート増やして欲しいよね。

海外中継とかやたら画質悪い時あるよね

PALからの変換とか二重圧縮とかカメラの品質とかその辺が影響してるんで内科医
ビットレート的には日本のほうがまだいいとかいう話もあるし

デジタル放送のモスキートノイズにうるさく言ってるのって日本人くらいなような

衛星の通信速度

http://www.mediafire.com/file/44tqzgwejzd/lossless_sumo_480i(TFF).7z.001
http://www.mediafire.com/file/nm2gzmmvnzy/lossless_sumo_480i(TFF).7z.002
http://www.mediafire.com/file/t4umumnnyjw/lossless_sumo_480i(TFF).7z.003
http://www.mediafire.com/file/kzm5znnjjzz/lossless_sumo_480i(TFF).7z.004

相撲のソース; x264の--qp 0で、Raw YV12の1/3くらいの容量になった。

Xvid厨の俺だけど　もうエンコやめることにしたわ。
DVDを1500kbps程度にエンコしても容量は3分の1程度にしかならん。
時間をかけて画質を落とす作業に辟易してきた。
HDDの容量増加に期待した方がましだ。　2TBのメモカも将来的には出るだろうし
もうエンコやーめた。　エンコは、youtubeなど配信目的ぐらいでいいのだろう。
保存目的とかに使うのはやめやめ。

おれも保存は地デジのTSのままだぜ

>>196
4:4:4と4:2:0でかなり差があるのと、7ｚの圧縮率のすごさに2度ワロタｗ

>>213
昔ffdshowのスレに張られていたリンクがあって、130kb位7z解答したら700mbくらいになって驚いた
中身は5秒くらいのカラーバーHD解像度とSD解像度ともに一つずつのの無圧縮aviだった。
スレチすまそ。

>>211
　　　　 　 　　 　 　　　　　　　　　　｡:ｏο○.。
　卒業おめでとう　　　　　　 。◆◎｡ｏ.:O☆ο
　　　　　　二度と来んな　／。:゜◎::Oσ★｡∂:o゜
.　　　　￣￣￣Ｖ￣￣ .／　。○。∂γ:☆O◇。σ
.　　　　　　　 ∧∧　／　　　◎:.♭★:ο｡:iσ:★:◎:
　　　　　　　 (,,ﾟДﾟ)´　　　　☆。σ:｡: ｏ α:θｉ:ρ☆
　　　　　 　　 |,つ´　　　　　　　。●..ｉｏ.｡◇.: ★ 。.: ★
.　　＿＿＿ ☆―――――――σ :∂ｉo☆ ゜
.　 ＼ 　　 　　し｀Ｊ￣￣￣＼
　　 ||＼　　　　　　　　　　　　＼
　　 ||＼||￣￣￣￣￣￣￣||￣
　　 ||　 ||￣￣￣￣￣￣￣||
　 　 　 .|| 　 　 　 　 　 　 　||

PS3で再生でき、かつPCではDXVAで再生できる設定さらして。

自分の設定さらすの忘れてました。

-q 20 --stats ".stats" --level 4.1 --fps 23.976 --ref 3 --mixed-refs --bframes 3
--subme 6 --weightb --direct auto --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--vbv-bufsize 9000 --vbv-maxrate 25000 --me umh --merange 12 --threads auto
--thread-input --progress --no-psnr --no-ssim
--output "〜.mp4" "〜.avs"

どうも背景等が汚く感じてしまいます。

逆になんで q 20 --merange 12 かと聞きたい

特定のハードウェアに合わせるのなら、ビットレートが青天井の-qではなく、
--bitrateや--crfを使わないといけない。

http://img31.imageshack.us/img31/2835/ps3360.png

私はゲーム機を持っていないから、自分で確かめられないが、MeGUIのプロファイルが参考になるだろうと思う。

--no-psnrって意味あったっけ

psnrを計算しないから、ほんの少し速くなる

BDMV向け、AVCHD向けのパラメータが解説されているサイトってありますか？

サイトは知らんけどMeGUIやtsMuxerRあたりのパラメ参考にすればいいんじゃないの

x264はマルチスライスに未対応だから、BD-Videoを作るつもりなら、他のエンコーダを使うべきだと聞いた。

MediaCoderってフリーのエンコーダがCUDAエンコードに対応したらしい
ttp://blog.mediacoderhq.com/mediacoder-cuda-accelerated/

MediaCoder - Download Full Pack
ttp://www.mediacoderhq.com/dlfull.htm

>>223-224
どうもです。

>>225
今まで、CUDA否定して来たここの住人がフリーだからって飛びつくわけないだろう。
それじゃ、今までただの貧乏人の僻みだったって事になるじゃん。

>>225
CUDAがどうこう以前にそれ作りが相当荒くて使おうと思ったら一から手直ししないと使えないぞ
以前.pmpコンテナ興味あって試したけど設定保存出来ない、設定したmuxer読めないで散々だった
試したのはWinXPのSP3、Pen43.6GHz メモリ2GBだった

>>225
それ、ウイルス入りだの何だので昨日Doom9で騒いでたやつだろ
開発者がスレたてたけど、あまりにも胡散臭すぎるって叩かれまくって、
さっき見に行ってみたら抹消されてたぞ

ついでにこれでも読んどけ
Question to x264 developers
http://forum.doom9.org/showthread.php?t=147665

フリーのmp3エンコーダが結局Lameで落ち着いたように
H264系エンコーダは最後までx264で落ち着くと思うけどな
mp3の時もそうだったが、商用はたいてい速度を上げるために
品質を犠牲にする糞仕様のものばかりだったし。

AACは？MPEG2は？

mp3は初期は市販品の方が良かったし。
今でもほとんどかわらないでしょ。

>>224
昔のx264のレビジョン見ればマルチスライスは普通に対応されてたらしい。だが、
大体のハードウェアはスライスがなくても再生できてるから一応殺された機能
になりました（あとは、ffmpegが簡単にスライス系のマルチスレ化をしないため）。

公式だとブルーレイなどにはマルチスライスが必要と書いてあるんだけど、
hrdパッチ使えば大体のauthoring系のソフトにはストリームが入れられるでしょう。

>>231
AACは今のところNeroAACencが一番いいみたい、特に2pass設定でいい結果を
出してる。MPEG-2はHCencがおすすめかな？複数のパスでやらないとダメみたい
だけど。

>>228
PMPというコンテナ懐かしいｗｗｗ muxerが確かにH.264-in-AVIをソースとして
使ってたから今はちょっとアレなものだったとは思ってるけど、PSPのH.264を
デコードする機能が解除された頃は熱かったなぁ…

>>225
>>229 が言ってるウィルスっぽいもあるし、複数のライセンスに違反してる
みたい。それに、エンコの時ブラウザを開くとかどんだけぇ…
作者の色んな返事も妙におかしいし、とあるG○m PlayerとかK○Playerを
思い出すぜ。

>>233
スレ違いですがAAC、以前見た結果だとNeroはq指定でAppleの方が良い結果を出している物があったんですが、
2Passで比べた結果とかどこかに載っていますか？

Nero vs Apple AAC encoders at ~90...95 kbits - Hydrogenaudio Forums
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=66949

q指定だとAppleと比べて割り当てが下手になるようです（欲しい所にビットが回らない）。
2Passだとその辺が改善されそうに思えるのですが。

>>233
昔のx264はマルチスレッドでエンコするとマルチスライスになった
だがそのせいでマルチスレッドエンコするとPSP(マルチスライス非対応)で再生できなかったり

DVDをインタレ保持 720*480の解像度を保ったまま　エンコード。
x264 crf22でエンコ　ぜんぜん縮まらない。　そりゃそうだ。　インタレ保持。

日活ロマンポルノ　谷ナオミ主演　花と蛇をソースにして x264でエンコ。
このソースはエンコをする上で非情に興味深い結果を出してくれる。
昔のフィルム特有のノイズ、暗部が多い作品。
x264でcrf20でエンコしても暗部のノイズが目立つ。 Xvidのq=2でも無理だった。
暗部の色がおかしくなり、縦長のブロック筋が多発する。
試しにdvd2Oneで　トランスコードをしてみた。　サイズは５０％になるように設定。
結果　暗部ノイズ、ブロックノイズ全くなし。　元のDVDと区別付かず。

ＡＶやIVなど元々画質の悪いものはトランスコードをすると破綻するが
映画など高ビットレートで収録されたもの、シネスコやビスタなど黒帯の領域が
多いものはx264やXvidでエンコするよりも良い結果が得られる。　
ｘ264やXvidでは日活の暗部はどんなに頑張っても表現できない。

そんなにこだわりがあるものなら、オリジナルを大事にもっておくのが一番だと思うんだが＾＾；

>>236
家庭用のビデオカメラで撮ったやつも暗いと全体的にザラザラして縮まないね。

新キャラ誕生：

　ロマンポルノ君

>>236
そんなあなたにHAQ
メタボエンコードにようこそ！

設定くらい晒せよ＞ポルノ野郎

http://www.mediafire.com/file/imn2jzozjni/DivX7_vs_x264_vs_Xvid-2_incl.source.zip

これは、かなりグレインの多いDVD(The Shining, 1980)をソースにしての比較

更新きたけど48px以下のクラッシュか…

このスレの住人じゃないと思うが、x264でエンコードして
P2Pソフトで違法アップロードしている奴が多いなこのサイト見ると。

http://www.sharedb.info/index.php/q-x264/?range=all

そんな犯罪者はさっさと捕まればいいのに。

自己紹介乙？

>>244
違法アップロードしているバカは迷惑だよな。そんなことにx264を使わんで欲しい。
まあ、いずれ一掃されていなくなると思うが。

自演までしてご苦労様です

>>247
えっ？何か自演と思わないと行けないような理由でもあるのか君には。

x264とAACがなんで併記されてるんだろうね
x264 Neroとかなら分かるけどさ

自演はこのスレ、いや２ｃｈの風物詩的アホ

おいおいｗ

頼むからこのスレで違法アップロードの擁護とかやめてくれよ。
モラルなさ過ぎだから。

見苦しいぜ割れ厨

[DVD] 今までありがとう。それではみなさんごきげんよう。(704x396 x264).txt

笑うしかない。

>>252
えっ？おまえ違法アップロードしている本人か？
犯罪者乙。

スレ違いにもほどがある
専門板でやれ

違法アップロードしている奴叩く流れかと思ったが
自演とか割れ厨が見苦しいとか意味不明なことを言っている基地外しか沸かなかったな。

>>244-251
板違い氏ね

>>242
3Mbpsぐらいになると、どれも変わらないな。

なんかたまに出力ファイルに埋め込まれるエンコ設定が同じ内容を2回繰り返して倍の長さになってることがあるんだけど俺だけ？

時々あるね、それ

r1165

>>261
30 hours ago : configure check for uclinux
30 hours ago : fix a crash on frame width <= 48 pixels

期待しちゃったじゃねーかｗｗ

http://forum.doom9.org/showpost.php?p=1296298&postcount=1920
実験用とのことだが、これはちょっと面白いな。

GPGPUはDirectX11で花開くんだろ。
エンコード高速化対応お待ちしております。

DirectX 11講座（中編）
非ゲーマーのアナタのパソコンも
DirectX 11演算シェーダーでスーパーコンピューターに変身する！
http://game.watch.impress.co.jp/docs/series/3dcg/20090327_79998.html
GPGPUの場合は、組んだGPGPUプログラムがATIかNVIDIAのどちらかでしか動かない、
踏み絵的な「ATI対NVIDIA」なのだ。
これではGPGPUの進化、発展、普及が望めない。
そこでGPGPUの標準化プラットフォームが強く望まれるようになった。
このGPGPU標準プラットフォームを、Windows環境下で提供しようと出てきたのがDirectX 11ということになる。
DirectX 11は、このGPGPUの標準プラットフォームとして「DirectX Copmute Shader」（演算シェーダー）を提供する。

演算シェーダーでなにができるのか
http://game.watch.impress.co.jp/img/gmw/docs/079/998/html/3dd1103.jpg.html

あんまり興味ないから結論だけ3行で頼む

>>265
マ
ル
チ

マルチはしね

やっぱマルチスレッドはダメか

x264的にはこっちの方が重要だろ、常考
http://www.freesoftwaremagazine.com/columns/xorgs_x_window_innovation_its_not_all_about_graphics
>A graphics code compiler: LLVM
>[...]
>Right now, LLVM is being developed, and a front-end made, to become a hardware-agnostic shaders compiler that will be part of Gallium.
>Currently, it works as an advanced prototype, and experiments are being made to support fully programmable shaders on cards that only support fixed
>function shaders without resorting to ‘pure’ software emulation: LLVM compiles shader fragments down to instructions that fixed function cards can render
>in an accelerated manner (it’s VERY experimental for now: it may be a dead end, so don’t bet on your Geforce3 card rendering current games in any usable way tomorrow!).

日本語でおｋ
ついでに三行で頼む

>>270
ライトナウ、エルエルブイエムデベロップド、
アンドアフロントエンドメード、
トゥービカムアハードウェアーアノスティックシェーダーズコンパイラーザッツウィルビーパートオブガリウム。

おーわくわくしてきた

スレチの話題で盛り上がるぐらいなら、そのままスレ落とせよ。

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　
　　｜ ｜　／　　＼｜｜スレチの話題で盛り上がるぐらいなら、そのままスレ落とせよ。
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

GPUを使ったx264エンコードってできないの？
プログラムできないのか、できたとしても性能がでないのかどちらなの？

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　　
　　｜ ｜　／　　＼｜｜　　過去ログ読むかググれ
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

>>275
過去スレにも一応書いたけど、実際にOpenCL/CUDA等はAPIとかがアレだし、
GPUは性能的にはエンコ全般には向いてないので、それに無理矢理何かを書こうと
しても、結果はCPUより低いことになる可能性が大きい。CPUとGPUを一緒に働かせよう
と思うと、その二つの間のバスがスルーパット＆レイテンシーが問題なる。

モーション・エスティメーション(略してme)なら独自プロセスっぽく走らせる
ことが出来るから今年はCUDAなGSoCプロジェクトとして入った。ですが、それを
試そうと思った勇者は全員CUDAのAPIなどを見たら逃げました。

参考になるスレ1号: ttp://forum.doom9.org/showthread.php?t=147665
特にDark Shikari氏とakupenguin氏の発言で現状を理解するようになるんでしょう。

x264 は 整数演算速度が命
GPGPU は 浮動小数点演算速度が命

去年は--b-adapt 2で逃げられ今年はCUDAで逃げられ…
ｘ264チームはいつも学生に逃げられるんだな

ほんとにGPU使ってほしいのはtritical氏のavisynthプラグインなんだが

結局は、今までの様に、使いやすくて高速なCPUをIntelに期待するしかなさそうだ。

GPUエンコ謳ってる製品がいかにインチキかよく分かるな

Win7 RCで試してる人いてますか？
MTではちゃんと動いてるんだけどXP SP3 (x84)ではCPU使い切ってくれてたのに
Win7 RC (x84 Build 7100)だと遊んじゃう。。。テスコ版だから手探り状態ではあるのですが…
使用ソフトはAviSynth 2.5.8 (MT) + x264.exe (r1163 OreAQ)
１つのPCにXP用のHDD(A)とWin7用のHDD(B)を用意してハードウェア環境はHDD以外は同じ
ソースの入ったHDD(C)はまた別のRAID HDD。出力はRamDiskなのでHDDがボトルネックになってるとは考えにくい
もちろん同じオプションを使い基本の--threads autoでやってます

x84 ???
速度的にはどうなん？
そもそもカーネルが一世代違うし裏で動いてるソフトも違うしx264の問題ってのは言い過ぎのような。

結局、x264の開発メンバーはGPGPUのプログラミングのスキルが皆無なんだろう。
だから、GPGPUが主流になるか自分たちがGPGPUの勉強するまではこんなもの使えないって言い続ける。

よくある手だぞｗ

>>279
ホントだな。
EEDI2、nnedi2、dfttestあたりを。

>>282
7RC x64で遊んでるけどCPU使用率（主に表示）がおかしい気がするね。
同じavs同じx264オプションでXPsp3とで処理fpsに誤差程度の違いしかないのに
CPU使用率が7RCのがあからさまに低い。
でも、CPU温度が似たようなところまで上がるから実際は使ってるんじゃないかなぁ。
fps下がってるわけじゃないからRCの問題かなぁと思っている今日この頃。

>>284
モーション・エスティメーション(略してme)"なら"独自プロセスっぽく走らせることが出来るから
って言ってるじゃん。　まあ、スキルが無くて(?)頓挫したわけだけど。

>>285
スレチだが。　前にtritical氏に頼んだけど、断られたｗ

>>287
日本語でおｋ？

>>286 thx
やっぱそうなんかなぁ。当方32bit (x84)ですがせっかくなら今度64bit (x64)も試してみようと思います
軽くスレチでしたが答えてくれてありがとう。（x264側が云々言ってるつもりはありません）

結局、現時点でCUDAを一番有効に活用してるのはドナルドだな
他の開発者はほとんど無視か、あまり利用価値のなさそうなものばかり
これで先行きを期待するほうがおかしい

　　三|三
　　イ `＜　　　　　　　　 　 　 ,.．-──- ､　　　　　　　　　_|＿
　　￣　　　　　　　　　　 　 ／. : : : : : : : : : ＼　　　　　　　　|＿　ヽ
　　　∧　　　　　　　　 　 /.: : : : : : : : : : : : : : ヽ　　　　　　（j　　）
　　 /　 ＼　　　　　　　 ,!::: : : :,-…-…-ミ: : : : :',
　　　　　　　　　　　　　 {:: : : : :i '⌒'　 '⌒' i: : : : :}　　　　　_ヽ＿∠
　　└┼┘　 　 　 　 　 {:: : : : |　ｪｪ　 ｪｪ　|: : : : :}　　 　 　 ｌニl ｌ ｜
. 　 |＿|＿|　　, ､　 　 　 { : : : :|　　　,.、 　 |:: : : :;!　　　　　 l─| l 亅
　　　_＿　　　ヽ ヽ.　　_ .ヾ: :: :i　r‐-ﾆ-┐ | : : :ﾉ　　　　　　　 _
　　　 ／　　　　 }　 >'´.-!、 ゞイ! ヽ 二ﾞノ ｲゞ‐′　　　　　　l　 ｀ヽ
　　　´⌒)　　　 |　　　 −!　　 ＼` ｰ一'´丿 ＼　　　　　　　l/⌒ヽ
　　　　-'　　　 ﾉ　　　 ,二!＼　　 ＼___／　　　/｀丶､　　　　　 _ノ
　　　　　　　 /＼　 ／　　 　＼ 　 /~ﾄ､　　 ／　　　 l ＼
　　　　　　 /　、 ｀ソ!　　　　　 ＼/l::::|ハ／　　　　　l-7 _ヽ
　　　　　　/＼　　,へi　　　　⊂ﾆ''ー-ゝ_`ヽ、　　　 |_厂　_ﾞ:、
　　　　　 ∧　 ￣　,ﾄ｜　　　 >‐-￣｀　　　　＼.　　| .r'´　　ヽ、
　　　　　,ﾍ　＼_,. '　| |　　　　丁二＿　　　　　7＼､|ｲ　_／￣ ＼
　　　　 i 　 ＼　　 ハ��　　　 　　 |::::|`''ｰ-､,_/　 /＼＿　 _／⌒ヽ

GPGPUが主流になるかどうかは置いといても、新技術は否定的な意見が多いからな。
勉強も必要だし使い勝手も違うから。

MMXやSSEも散々昔は叩かれた。時間がたつにつれ、自分が使えるようになってからは
文句を言う奴も少なくなったが。

なんでそんな上から目線なんだよ
そもそもMMXやSSEとCUDAやOpenCLじゃ比較対象としておかしいだろ

つか、どうでもいい。x264よりもいいソフトがあればそれに移行するだけだし。

でも、IntelやAMDも次の将来はGPGPUに行くみたいだし次の流れとしては
確かにGPGPUはあるよ。

次の将来か。　えらい先の話やのう。
ところでMMXやSSEが叩かれてたとは恥ずかしい話初耳なんですが、
どう叩かれていたのでしょう。

>>295
新参乙。

現状クソだから使わないだけで
使いものになるなら何でもいいんだよ

スレチだしどうでもいいことなんだがだれか32bitはx86だとつっこんでやれよｗ

MMXは性能とは別のところでいちゃもん付けられてたな
SSEは初耳だけど

あとAMDはATIの部門があるから当然GPGPUの戦略はあるけど
IntelはGPGPUに批判的でしょLarrabeeなんかを見るかぎりでは
まぁただの屁理屈ともとれなくはないけどさ

>>296
無知乙

頭の悪さは隠しきれないなｗ

>>301
自覚あるならマシじゃね？
イ�`。

ほら、もう沸いて自己紹介してきた>>302

EEDI2がGPGPUで速くなったら
すぐにでもハイエンドグラボ買うぞ

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |
　　｜ ｜　／　　＼｜｜
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

なんか最近変だなここは

流れ切るようなネタがないしな

スレチの話題で盛り上がるぐらいなら、そのままスレ落とせよ。

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　
　　｜ ｜　／　　＼｜｜スレチの話題で盛り上がるぐらいなら、そのままスレ落とせよ。
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

だって最近、更新が遅いんだもん。

今Dark Shikari氏はffmpeg方面で活動中だからな。しばらくは辛抱。
Facebook(世界最大のSNS)のエラーログからバグ報告したり、VC-1デコーダの高速化をしたりしている。

>VC-1デコーダの高速化
誰得・・・
BDとかに使われてるのか。

threaded slicetypeはどうなってんの？
GCC 4以降ならもう問題ないんじゃなかったっけ？

>>312
VC-1≒WMV3

>>314
おい

VC-1はH.264の次に良い規格で、BD等にも使われて結構普及しているから、
フリーウェアの高速なデコーダが大事なのは分かる。

×フリーウェア
○フリーソフトウェア

確かに、GPLのffmpegの利点は、単に無料と言う訳じゃ無いな。

DivXのH.264のデコーダーがffmpegからコードパクってるんじゃないかといわれるくらいだからな

ffdshowとDivXのH.264デコーダ同じところでバグで映像崩壊することがあったな
CoreAVCではちゃんと表示できていた箇所

>>320
むしろそれはCoreAVCが
おや、玄関に誰か

DivXは最初もMSのぱくってんじゃね疑惑があったな

パクリっつーか、DivXは一番最初の3は単にMSMPEG4をクラックしただけだった。
人気が出てきてさすがにヤバいって事で独自開発の4にしてソース公開（OpenDivX）。

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　
　　｜ ｜　／　　＼｜｜　さぁーおめえら、自分語りスレだ
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

IMAGICA、Blu-ray制作に独自のバンディング除去技術を採用
http://av.watch.impress.co.jp/docs/news/20090617_294496.html

オリジナル http://av.watch.impress.co.jp/img/avw/docs/294/496/imag01.jpg
HD-M.A.P.S使用 http://av.watch.impress.co.jp/img/avw/docs/294/496/imag02.jpg

副作用で暗部の輪郭線が見事に消えてます、本当にありｇ

バンディングが消えたけど線も消えましたとさ

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　
　　｜ ｜　／　　＼｜｜スレチの話題で盛り上がるぐらいなら、そのままスレ落とせよ。
　 　| (｜ 　 ・　・ 　 ｜)| バカどもがっ。
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

>>328 おめえが一番うぜえよ、消えろ

「銀河伝承族」とか「さまよえる星人」とかを思い出してしまったよ

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　　
　　｜ ｜　／　　＼｜｜　おめえが一番うぜえよ、消えろ
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

>>324>>328>>331
たのしいですかそ〜ですかそれはよかったですねぇ（棒読み）

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　　
　　｜ ｜　／　　＼｜｜　　（棒読み）
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

>>327
マジで線消えとるｗ
話にならんな

シマコの二の舞になるだけか

更新ﾏﾀﾞｰﾁﾝﾁﾝ

>>325
SONYの方が遙かに良いじゃん

素材のクオリティが違うんだから比較できんだろー

エンコしながら他の作業やりまくってたら熱暴走でブルスク orz
7時間掛かって後1時間だったのに…

7時間ぐらい寝ている間に回復するよ
上には上がいる

たまに24時間以上かかるエンコするけど落ちたことはないなぁ。
てかまだ今の時期で落ちるって真夏はどうすんだ。冷却見直せ。

エンコ・・・やりまくり・・・ブルスク
(;´Д｀)ﾊｧﾊｧ

頭の冷却も忘れるな

GPUプラグイン併用してそっちが100℃近くとかなっててもキケン

Radeonのリファモデルなら笊化しろ
軽く20〜30℃は下がるぞ

ソニーのディザは全部自動判別で全シーンディザをかけて
HD-M.A.P.Sは、人間が確認して人間が手作業で修正するんだよな。

DTV板的には後者の方が安心感がある。全部自動お任せは経験上ろくなことがない。

学習機能があれば便利そうだな

>346
その割りに、325の画像が酷くないか?

On/Offで比較しないと分からないな。
仮に変な粒子感が目についたシーンがあったとしてもそこはメディアには公開しないだろうし。

誰か暇人がエヴァを全シーンキャプ取って検証してくれればいいのだけどｗ

>>349
そんなことやっても、制作〜マスターの段階で発生したノイズって言い出す奴が
必ずくるから結論はうやむやになるだけ。

まさに時間の無駄。

SONYの説明は、　>人間の視覚特性を利用した演算処理により、10ビットから8ビットへの変換処理においても滑らかなグラデーション表現を可能にします
ってなってるから、減色の際に処理する技術なのか、減色された物を処理するかの違いだろうね。
折角マスターを入手できるポジションなんだから、ちゃんとやって欲しいわな。

元々8ビットで作りゃいいのに

ディザの意味わかってる？

>>352
デジタルってどんどん処理していくと、8bitじゃ足りないらしい。
そうなると、いずれにせよビット落ちでバンディングが出る。

rev1169

>>346
アンバンドはディザ付けるだけだから自動で十分でしょ。
デバンドとなると閾値設定したりしないとならないけど。

>>354
フィルタ重ねがけみたいなもんだよね。

っ http://forum.doom9.org/showpost.php?p=1298593&postcount=1924

>>313
threaded slicetypeは現在ちょっと放置っぽいんだよねぇ（開発してた人が最近
更新してないから；だが、メーリングリストはオイラも読んでないから完全そう
だとは言い切れない^^;）。

現在の状態で一応使えるものだけど、Windows環境では変な数字を入れると
アポーンする場合があるんで、様々なビルドには入ってない。GCCのバージョンとは
そんなに関係してなかったりして…

p-adaptやら新しいカラースペースの仕事は普通に進んでる。特にp-adaptを
作ってる人は頑張ってるみたい。

アポーンって何すか

アポイメン

1170

ppcのみ影響

http://pc11.2ch.net/test/read.cgi/avi/1242647783/855
> メインコンセプトのエンコーダが不利なのは低ビットレート時の話であって
> 高ビットレート時はx264よりも綺麗な画像が出てますよ
> と言ってもそんなに沢山のソースを扱ってるわけじゃないけど
> 少なくとも俺の扱ったソースでは目で見て明らかな結果が出てますね

なんですが、

いちいち比べたいなら検証スレでも立ててそっちでやれ

目だけで判断されてもあれだけどね
まあ金払って駄目だったと言いたくないという可能性もあるから

少なくても3Mbps前後の242のソースは俺にはあんま違いが認識できなかったな。

あっ>>242ね。

あのサンプルでは、x264以外の2つはグレインが潰れてブロックになってしまっているが、
違いが良く分からない人もいるだろうと言うのは分かる。

ん？そんな違いなんてあったか？

仮にあったとしてもコマ送りしてようやく確認できるぐらいのレベルなら許容範囲だな。
静止画のコーディックでもあるまいし。

古い映画だと、グレインはどれもあんな感じだし、全編を通してブロックの嵐と言うのは、
私はちょっと嫌だな。

今>>242を見ているんだが具体的にどの辺のシーンがブロックノイズの荒らしなわけ？
再生時間で言うと。

http://hdimage.org/images/bs1odkmby2empkvlkbn_divx7.png

MPEG-2のソース自体も、完璧だと言うわけでは無いが。

やっぱ、分かんないな。>>367で言ったように実際の見る環境のように
動画でランダム再生して100%でこれがx264だって分からないと意味内容ないと思う。

仕事行ってくる。

まあ、私の様に、動いている人物よりも、背景のフラットな部分の劣化が気になる様なタイプの人でなければ、
どうでも良い違いに思えるのは分かる。

また後で、より劣化の明確になった1000kbps位でやってみようと思う。
これだとx264でも完璧にこなすと言う訳にはいかない。

音楽のエンコでもそうだけど、ビットレートを上げていくと結局どのCODECを使っても大差ない
(違い判別し難い)って感じになるのかな。

圧縮技術なんだから低ビットレートでいかにオリジナルに近づけるかってのが、本来の価値なんだろう。

環境どころかプレーヤーで左右されね？
同じ動画をzoomeに上げてzoomeのプレーヤーで見るのと
オフラインで動画プレーヤーで見るのですら画質変わるんだし。
zoomeのは再エンコードされてない前提ね。
ちなみに俺の場合zoomeのが綺麗に見えるんだが、何故なんだろう･･･

ていうかみんなプレーヤーは何使ってる？

>>374
規定のプレイヤーはBOON
エンコの確認にはQonoha

zoome=flash=BT709で再生ってオチじゃないよね？
ウチはPCはcyberｌｉｎｋ+DXVA+MPCでPS3常用

>>374
それわかるわー。zoomeやgavieで綺麗な動画を落としてMPCで見ると色が全体的に褪せて見える
特に彩度100の黄色とか白味がかってしまうのが気になる

http://www.mediafire.com/file/etzdmyinrjw/DivX7_vs_x264_vs_Xvid_at_1000kbps.zip
AQ, QMの両方が無いDivX 7には、このサンプルはちょっとつらいか。

試しにzoomeやgavieで使われてるのがフラッシュプレイヤーだから、
FlavieっていうローカルPCで再生できるフラッシュプレイヤーで.mp4(H.264+aac)再生してみた
結論からいうと、mpc+ffdshow内臓コーデックを使うならフラッシュプレイヤーのが綺麗
MPC+CoreAVCやその他だと不明

一時停止しながら見比べてたら明らかにMPCのがブロックノイズが多い
コーデックを軽くて早いと評判ｗのDivX H.264 Decoderからffdshow内臓のffmpeg-mtにしたら直った
ついでにlibavcodecにしたら更に画質がよくなったんだけど
Flavieのが動画内の文字がくっきりだし、色がしまって見える（mpcだと若干、全体的に白っぽい）
これさー、単純フラッシュプレイヤーのH.264デコーダーが優秀なんじゃない？
当然だけど、Flavieとzoomeやgavieの画質は一時停止などして確認したけど同一と思われる

汎用性なさすぎだけど、H.264の再生はフラッシュプレイヤー最強なんじゃね？ｗ
この辺は流石、長年映像に携わってきたadobe謹製だな、ってとこか

今頃YC伸張の有無で画質がどうのって・・・。
ここエンコ初心者スレじゃないんだよ。

FlashPlayerのデコーダはMainConcept製だ
Adobeはそれを買っただけ

>>374
それ言えてるね。再生のデコード設定があまり無い簡単なプレーヤーほどフィルター処理なんかを自動で
(プレーヤーデフォルトで)やるようになってるんでしょうね。
先日も自分でエンコした画像が汚くておかしいなと思ったら、プレーヤーのループフィルターが全部スキップ設定に
なってた。この設定だとエンコの設定によってはx264が一番汚くなって見れたもんじゃないw

>>379
MPCで使うffdshowってフィルター設定とか多少知識がいる細かい設定が驚くほど沢山ある。
既存の設定項目が少ないプレーヤーは多分そういうフィルターとか色々な設定をプレーヤーが勝手にやってると思うよ。

ちなみにlibavcodecってのがffmpegを使用するって事ね。これを使用してればffdshowをどんどん新しくしていけばきちんと
リビジョンの上がったx264が使われるって事。

初心者と初心者がスレチの再生のしかも全然間違った認識での話とか勘弁してよね('∀`)

YC伸張の有無が原因と思ってるのか？ｗ　ffdshowの設定で変更できるけど、これが原因ではなかった

>>383
じゃあ、どうして　>>374　のようになるのか優しく教えてくれｗ
この板にH264の再生に関するスレはないしなー

単純にデコーダーが違うから、で済む話じゃないの？

>>379
頭痛い… デブロックが必要以上あったら→画質が上ということを言っているのか、
あなたは。BTXXXの違いかフルレンジなレンダリングのせいで色がアレコレ
なってるのも自分のエンコ設定がおかしいせいか、FlashでのMainConcept
のデコーダーが勝手に何かをやってくれるせいで。

VPXXの時もかなりデブロックフィルタかけてたから別に新しいことではないがな。

ということで、Flashでの「画質テスト」はやっても無駄かと思う。

>>382
> これを使用してればffdshowをどんどん新しくしていけばきちんと
> リビジョンの上がったx264が使われるって事。

この人はx264がlibavcodec向けの独自ルールで開発されてるとでも思ってるの？
そちらのものを更新する必要性はバグが見つかった場合のみ、x264はH.264の
スタンダードに従って開発されてるだけです。

あと、ループフィルタを切るってのはH.264のデコードを最速化する最後の
一歩だし、それを切ったらスタンダード通りのデコードにはならないから
そういう状態でそもそも「画質テスト」をやろうとする人間がバカと思うわ。

ループフィルターが切ってあったらx264に限らず、デブロックを使ってる
H.264エンコーダーなら、汚くなります。もちろんビットレートなども
関係してるけど、ループフィルターが利くようになったらそこを切ってる
時点でダメになるわけ。

とりあえず、デコーダーテストをやりたいなら、MP4/MKVなコンテナにストリームを
入れて、ffms2, dss2でテストを行うといいと思うわ（スクリーンショットは
AvsPでとってもおｋ）。DSS2の場合はDirectShowフィルタを使用することに
なるからCoreAVC, Cyberlink, DivX, ffdshowなどを試すことが出来る。もちろん
DSS2でDirectShowフィルタの設定も利くからテストをやる前には変な設定
してたら一応デフォルトにでも戻してもおｋ。ffms2は一応いつもデフォ
設定なので、ffdshowの結果を比べるためにいいんでしょう。

違いのスクリーンショットはAvsPでとれるし、各デコーダーのバージョンも
いつもつけましょうね。

これでデコードの違いがあったら、最初には設定を確認して、libavcodecベース
のデコーダーを出来るだけ更新すればおｋ。これでもまだ違いがあったら
一応ストリームをリファレンスデコーダーでデコードすることになります。
それが出来たら正しいのはどっちってことが分ります。

大体の場合は違いがないってことになるか、ffdshowを更新すれば違いはなく
なる。市場のデコーダーだと差があっても不思議ではないが、リファレンス
のもので試してみれば、どっちが正しいかのは分る。

この長文の意味: スタンダード通り再生することと、どっかの再生ソフトが
勝手に色々フィルタをつけまくって自分の目に合うように再生することは違いますよ。

全く…やれやれだぜ。

>>384
君がYC伸張すらまともに出来ない上にそのことを認めようとしない馬鹿だから。
自分で色が白っぽいって書いてんじゃねえか。

デコーダーそのもので画質が変わることはありえない。なぜならH.264は
規格に沿っていれば１ビットたりとも変わらないデコード結果になるから。
変わるとすればそのデコーダーそのものが規格外であるかデコーダー以降の
処理のせい。最近のrevのffdshowであればデコーダーは正しい結果を吐くことが
確認されてる。と言うことは正しい再生環境になってないことが原因

こっちでやれよ

x264 初心者質問スレ part1
http://pc11.2ch.net/test/read.cgi/avi/1221494912/

>>385-386はmukenさん？

だれでもいいんじゃねーの

難しいことはよくわかんね。zoomeが優秀なのは解った。
Linuxしか使わないんだけどzoomeってLinuxにもあるの?

Linuxしか使わない自慢来ましたー

>>385,386
アップロード目的の人間にとっては、その変にフィルタ重ねてるFlashで画質テストしないと、
むしろ意味がないってことはよくわかりました
今のとこ、スタンダードな環境で見る人のためのエンコをする予定はありません

>>387
バカは自分だろｗ　そもそもffdshow最新版は自動で判別すんだよ　的外れクン

　ffdshow の RGB 色空間変換機能に、BT.601 および BT.709 色域の自動判定機能と、H.264 VUI（Video Usability Info）で指定できる
　YUV のフルスケール（x264の場合は --fullrange）オプションの自動判定によるストレート変換機能が実装されました。

>>392
zoomeで使われてるプレイヤーはFlash　つまり、自エンコ物をうｐる前に画質を確認するならFlavieを使っとき
優秀っつーか正規のものとは、割と違う味付けがされとるっぽい　だからmpcやらで確認しようとしても無理

>>394
ffdshowを使いこなせてないって自慢はいいから、
さっさと巣にお帰り。

>>394
俺はFlashPlayerの画質が大好き　ということですねわかります

DXVA再生絡みでフィルタかかることもあるんじゃね？
MPEG2再生でもwin7内蔵のデコーダで再生するとかなりNRかかって綺麗に再生にされた。
確か画質に絡むDXVAの設定有ったからH.264でもフィルタ掛かる気がする。

その点ffdshowは特別にフィルタ掛けない限り規格に忠実にデコードしたのを流してるってことだろ。
一長一短だが画質比較の場合どっちが良いかは言わずもがな。

まあ単なるYC伸張とか言うオチだったらアレだが。

こういう初心者臭い流れは自作板のネタスレでやろうぜ

このスレで一番役に立つのは>>19、>>23、>>29、>>355、>>360みたいなレス。

967から1163に乗り換えたけど減ったコマンドが多いな

FlashPlayerがなぜか二重YC伸張してたわ。nVidiaのドライバでフルレンジに自動でする設定にしてないんだけど･･･
実際のプレイ画面よりやたら色が濃いやんけｗ

http://pc.watch.impress.co.jp/docs/column/tawada/20090623_295628.html

インターレース保持エンコって，プログレッシブ化したものもエンコより圧縮しづらいの？

符号化効率は多少落ちる。特にx264は適応じゃないMBAFFだから

>>403
その上トータルのエンコ時間も似たり寄ったりになる。

>>399
更新だけならfreenodeというIRC鯖の#x264というチャンネルに入って、CIA-XX
っていうボットの発言で注意するようにすればいいかと。

あと、 ttp://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog のRSSやら
ATOMフィードも一応役に立つかと。

MBAFF(-fmode 1)が使えるのは、x264に対するDivX 7の利点の一つ。

>>404
>適応じゃないMBAFF
って、どういう意味なの?

>>407
x264の--nal-hrd --interlacedと違いがあるの?

revision 1171

Various CABAC optimizations and cleanups
Faster CABAC CBF context calculation for inter blocks.
Add x264_constant_p(), will probably be useful in the future as well.
Simpler subpartition functions.
Clean up and optimize mvd_cpn a bit more.
Various other minor optimizations.

CABACが速くなって、p-adaptのためのx264_constant_p()が参加されて…
様々なマイナーな最速化ってことですな。

>>408
DivX 7のMBAFFは、x264のそれと違って、動きの無いマクロブロックをプログレッシブとして処理できるので、
効率が良い。

>>409
>p-adaptのためのx264_constant_p()が参加されて
全然違うよ。x264_constant_pは__builtin_constant_pのラッパで変数が定数かどうかを返す。それによってインラインアセンブラとかを高速化できる。

>>411
おっと、これは失礼。ソース読んでなかったせいで、pフレーム用のフレームごと
の何らかのconstantかと思ったわ^^；

System.life.end("fail"); の一例ですね、これは。

>>410
ｘ264のMBAFFもそうなってるんじゃないの?

>>413
http://forum.doom9.org/showpost.php?p=1264625&postcount=2

not adaptive = 全部のMBがインターレースとして処理される

ttp://forum.doom9.org/showpost.php?p=1299330&postcount=1929

'AutoVAQ'モードを--aq-mode 2に入れるパッチが出たみたいなので、一応それに
移動しようかと思う。今のところまだ別々にビルドしてますが、バグがなかったら
次のビルドはもう一つにまとめたいと思います。kemuri-_9氏へ感謝。

っ ttp://forum.doom9.org/showpost.php?p=1299309&postcount=1928

>>414
教えてくれてありがとう

flash playerはもうちょっと拡大縮小を綺麗にしてくれると良いんだけどなぁ
まぁ負荷が上がるだろうから難しいのだろうが・・・

>>417
負荷が上がるからそこまで高品質なモードにしてないサイトが多い

伸びてると思ったら
いつからここは初心者スレになったんだ…

>>419
おいここに初心者が居るぞ

>>406
丁寧に有難う。ボットの発言ってのも凄いですね。

今までgitから取った奴のリビジョンってのがよく解らなかったけど、ソースディレクトリのversion.shを実行すれば
良かったとは今気付いた・・

公式のVLCのsnapのftpではまだ1170から更新されてなかったのでgitで取りました。

インターレース保持エンコ厳しいわ…

将来的に適応型のほう実装してくれたらいいな

その代わりエンコ時間が2倍になる特典つきです

全MBインターレースってことは、符号化効率はPAFFと同じってことなのか

PAFFはプログレとインタレをフィールドごとに切り替える
今は全部インタレで処理してるから、PAFFより悪いんじゃない？

そういやMPEG2にもMBAFFみたいな概念があるが、フリーのHCEncは全部プログレモードでエンコしてる
TMPGEncなんかはちゃんと切り替えてるので、インタレをエンコすると差が出る

MPEG2だとPAFFでフラグが頻繁に切り替えると
一部再生機で再生不良になるんだよねぇ。

x264_AutoVAQmod.03.diff
実写によさげだな

Seraphy氏のx264gui icc版に早く入らないかな

ﾈﾓｲのでコンパイル諦めた。おやすみ

おやすみ

>>428
向こうの掲示板に出向いて書き込めば、やってくれるかも･･･　と思ったけど、
パッチ無し/MixAQ/OreAQ　っていうリリースだから、難しいかもね。

いつの空ＯＰで、ブラインドテスト作ってみた。　スレを私物化すんな！　と怒られそうですが･･･
AからEまで5つのファイルが入っているので、良い順に並べて下さい。
ttp://www.mediafire.com/?z3o2zjzmyz1 (43.4MB, 7z)
内容については後日発表するので、オプション見ちゃった人もバラさないでもらえると嬉しいです。

オプション見られたくないならバイナリいじって消しとけば？

なんかオプションを入れないパッチってなかったっけ

>>432
私の主観で言うなら、比較的ブロックの少ないBかCのどちらか。

>>434
たしかVFR maniacビルトには入ってる
でもDoom9でD_S氏が
「こっちはわざとオプション見えるようにしてるんだから、こういうパッチを配布するのはやめて」
って言ってた気もする

そもそも通常用途でオプション隠したがる意味が分からない。

>>432はAQの実験の様だし、仮にオプションを隠してあっても、ずるをするなら、ffdshowのVisualizations等、
いくらでもやりようは有る。

http://img413.imageshack.us/img413/473/artifact.png
どれだとは言わないが、これはあんまりだ。

>>436
それどうやって実行するの？ --longhelp眺めてもそれらしいの無かったような

>>440
そりゃお前がよく読んでないだけだ
見つかるまで読み直せ
ちなみにrev1171のmixAQのlonghelpにはちゃんとのってたぞ

みなさんレスどうもです。
指摘された通り、AQの実験です。　
オプションはスキル不足もあって消していませんが、先入観をなくすのが目的なので、
見れても構わないかな、と思っています。　AQはどれが優れているとも言えないと思うので。

ここに書き込まなくてもいいので、自分なりの順位を付けて貰えれば、役に立てたかなと思います。

>>442
マジレスで申し訳ないけど、おそらくソースが悪すぎる

ブロックノイズが元からある部分とx264のエンコードで発生した部分がわかりにくく、
高周波、低周波成分の再現性も確認しにくい感じ

BDソースかビットレートが十分なTrailerとかオススメ

>>443
ソースはこれです
ttp://www.lumpofsugar.co.jp/product/itsusora/download03.html

CPUがi7なんだけど、
corei7: -march=core2 -mtune=core2 -msse4.2
↑でビルドしたx264(x86) 何処かにないかな？

自ビルドの世界へようこそ

ググったら、ありました

x264_open_gop.3.diff
x264_open_gop_hrd.2.diff
x264_thread_priority_with_pool.02.diff
x264_thread_pool.02.r1074.diff
x264_hrd_pulldown.13_interlace.diff
x264_AutoVAQmod.03.diff
x264_fgo_r1153.diff
x264_win_zone_parse_fix_05.diff

x264_GM_1171(ビルド by guttymo)


open_gop?意味不明？？？

普通の人ならOpenGOPは圧縮率が良い程度の認識でいいと思うよ。

Seraphy 1171_OreAQ_icc
ブロックノイズの嵐やねん

1163に戻したよ

>>450
そんな訳無いやろーと思ってエンコしたら本当にすげーブロックノイズだった。

mjk-とGCCの方はそんな不具合は出てないな

AVCは開発してくれたパナソニックに感謝をこめてビエラ買ってきた。
ありがとう、おかげでx264をいつも楽しく使われてもらっている。

まあ、ただ買い換えの時期だっただけだけどねｗ

は？

ひ？

摩訶不思議ですね。

さて・・・流れ変えるか。俺は、インタレ解除とフィルタ使ってあとはロスレスAVCで保存する
こだわり最高画質派なんだが、家電でロスレスに対応しているプレイヤーやレコはないよなorz

ロスレスAVCってなんだよ

>>459
ググレカス

ｲﾔﾝ、ｲｸﾗﾅﾝﾃﾞﾓﾊｽﾞｶｼｽｷﾞﾙ(〃▽〃)

"ロスレスAVC" に一致する日本語のページ 4 件中 1 - 4 件目 (0.17 秒)

>>462
初心者スレに行ってロスレスのAVC/H.264って何ですかって聞いてこい。
ここはお前みたいなニワカには早い。

>>463
なんでロスレスAVCからロスレスのAVC/H.264に変えてんの？ｗ

なんだ、ただのバカか。時間の無駄だな。

AVCは開発してくれたパナソニックに感謝をこめてビエラ買ってきた。
AVCは開発してくれたパナソニックに感謝をこめてビエラ買ってきた。
AVCは開発してくれたパナソニックに感謝をこめてビエラ買ってきた。

誰かID:SeDAKBVVの低脳の面倒見てやれよｗ

( ﾟДﾟ)y─┛~~

変なのわいてるな

アナログテレビの録画していますが
ウィンブルンドンの芝とかボールとかうまく圧縮できますか？

ウィンブルンドンの芝は圧縮したことないね。刈った後でか？

r1173

x264のロスレスは4:2:0だしなあ。10bit4:2:2に対応してくれたら最高なんだが

8bit/sampleで、4:2:0のMPEG-2 Main Profileが主なソースの私には現状で十分。

つか、色空間とかビット数の違いで、目に見えて品質あがるもんかな？？
自己満じゃね？？

元のソースと色空間を合わせることが目的ってこと分かってる？

>>476
そんなことは解ってるけど、あわせる必要ってあるの？

>>477
えー

ソースが10bit4:2:2ならもちろん目に見えて品質が上がるけど
サイズがやばいことになると思う

芝がジャギジャギニなったりボールが糸ひかないようにうまく圧縮されるという意味でです
ボインボインもしっかり揺れてくれるとなおいいです(〃▽〃)

>>480
そんなことはみんな分かってるから。
エスパーじゃないんだからやってみないと分からない。

わかってるなら教えてくれればいいのに・・・いじわるだ。。。(´Д⊂ｸﾞｽﾝ

だってアニヲタしかいないもん。
スポーツ番組は無圧縮が基本だろ。

そうなんですか？��(￣□￣;)ﾅﾝﾄ!!
初耳です・・・

いいからエンコしてみろよ
9時間も何してたんだ？暇人さんよ。その間に何本エンコできんだよ
やってもないのに教えて下さいだと？DTVに居座るようなタマじゃないな

>>475
ゲームキャプチャする人にとっては、4:2:0だと細部が滲んで嫌って人も居るかもしれん。

個人的な欲を言わせて貰えば、昨今の映像なんてのはPC上でRGBで編集されてるのが大半なんだから、
RGBをサポートしたフォーマットで見てみたいってのはあるねぇ

まあ手に入るソースなんてのはゲームのキャプ以外は4:2:0しかないような

ネット動画とか解像度が低い上にスクリーンキャプチャやテキストが入ってると、
YUV420だと滲んで見にくいってのはあるな（更にFlashは近傍画素法で色差を扱うし）

ttp://www.youtube.com/watch?v=FzL9Zr8sk7g
このコメント欄の8ページ目くらいでコメントしてるDarkShikariって
x264の人と同じ人ですか？

>>489
http://mirror05.x264.nl/Dark/LosslessAzumanga.mkv
http://www.youtube.com/watch?v=-e8P7kIQlbU

こう言うビデオも投稿しているし、x264のDark Shikariその人だろう。

やっぱそうですか、サンクスです。

YouTubeなど動画サイトとかでYUV420がデフォな現状、
赤文字など赤の斜めのギザギザが見るに耐えないのが嫌。
ローカルなら好きに補完とかしたのち
好きにYUV422とかYUV444とかの別フォーマットなりで保存できるけど、
見たい（見たくなる）動画全てを自分で所持できるわけでもないし。

10bitなんかはなくてもいいけれど、
少なくともYUV422はH.264で仕様化（標準化？）されてほしい、
そう思ってる。
確かH.264でYUV422かYUV444は検討か何かされているけど実装に至ってない…
みたいなのを見かけたことがあるけれど、厳しいのかな。

FRExtのHigh-422で標準化されてたはずじゃ?

自分で高性能なカムコーダーで撮影するか、PCゲームの録画でもしない限りは、
YCbCr 4:2:2/4:4:4やRGBのソースは、なかなか手に入らない。

>YUV422はH.264で仕様化
大して画質も変わらないのに、ファイルサイズが無駄に増えるだけ

普通補間されて表示されないかな？
Flashはだめだけど

Flashが一番画質が良いって言ってた奴はどこいった。

10bitのアニメの綺麗な無圧縮ソースでも手に入るなら4:2:2とか実装して欲しいが
現実的じゃないのでいらね。

デジタルビデオカメラの映像なら…
そのままBDとかに焼いて終わりだなぁ

ああ、Flashが赤も補間して表示してくれれば4:2:0でも解決するかもしれないのか。

>>494
4:2:0を入手→（見やすいようにor好みのように）4:2:2に補間アップサンプリング＆エンコ
→補間のないFlashでも綺麗な画
みたいなのを考えてた。

>>495
その意見は何度も目にしてるけどさ…。
インタレと4:2:0なんか相性最悪じゃん。
最悪4:2:2は価値を分かってる動画作成者だけが使えるよう
4:2:2使用は手動設定を強制するとかすればいいんじゃない？
…と思ったけどそんな制限無駄か。

再生側で--chromalocを適切に利用して補完してくれるWeb動画再生環境(Flash,GPU,etc?)が
安価に普及するのを気長に待つことにしますわ。

mpeg2ならまだしも、AVCならサブサンプリングまでして
データ量削減することないよねえ。

VUIを正しく設定できない投稿者が殆どであろう動画サイトに、品質を期待するのは不毛でしかない。

>>502
そうですねorz

＞再生側で--chromalocを適切に利用して補完してくれるWeb動画再生環境(Flash,GPU,etc?)が
↓
再生側で補完してくれるWeb動画再生環境(Flash,GPU,etc?)が



それを考えると4:2:2に傾く…。


インタレという目に悪いアナログの負の遺産を地デジにまで持ち込んだ人間も嫌い。
醜い赤の階段を生む4:2:0も嫌い。それだけ。

PCゲームの録画ばっかりやってるから、RGBのソースばかりなもんであった方が嬉しいな。
255な色が軒並み色変わって悲しい。
昨今のHDD事情ならサイズ増えてもいいからさ。
といっても流石に可逆だと2時間で数百Gとかになるんで、これは辛い。
現状のx264ですれば大体1/100ぐらいになるんだけど、1/50になってもいいからRGB対応もして欲しい所。
数百Gはともかく数G程度ならどうとでもなるし。

そこまで4:2:0が嫌なら、こんな所でぼやかなくても、4:2:2に対応したDiracを使えば良い。
ただし、x264と比べた場合の品質はお粗末でしかないし、デコードの負荷もとても高いので、
YouTube等の動画サイトが対応する事は無いだろうが。

http://diracvideo.org/
http://saintdevelopment.com/media/

>>503
>インタレという目に悪いアナログの負の遺産を地デジにまで持ち込んだ

そうかな？
インタレで放送・録画して、テレビで解除するという今のやり方は、
ビットレートと、フレームレート、解像度のバランスがとてもいいと思うけどね。

どうせプログレに変換して表示しているしね

>>506
だよな

1440x1080を16Mbpsで60fps出そうと思ったら
プログレだとかなり帯域いるし破綻もしやすくなる
インタレはいい技術だよ、ほんとに

…

720x1080p @60fps を縦にリサイズする方が遥かに良いのに気づかないの？

720x1080pを縦に？

縦にリサイズ

>>510
いや、さすがに720を1920に引き延ばしたらボケボケになるだろw

インタレースなら静止画部分は2フィールド待ってフル解像度が得られるんだし、
動き部分も前後のフィールドを用いた動きベクトル適応補間が使えるからな

半分の解像度にしてしまうと静止画部分はいくら待っても半分の解像度しか得られない

でもアニメなんかは1280*720*24pで無駄なスケーリング・テレシネせずそのまま放送してくれればとは思うけどね
納入がHDCAMとかだから1920（1440）*1080*60i固定だから仕方ないんだろうけど

90fps 3フィールドまだー?

H264になればすべて解決

>>504
それは単にエンコ時の色空間の扱いが悪いだけかと。

>>505
普及度の高さから、H.264による4:2:2対応を望むんだよ。

>>506
それこそx264のプログレエンコ結果をみりゃ
ビットレート（帯域幅？）の心配もそれほどしなくていいように思うんだけどね。
一応自分は　1280x720p @ (60 or 30)fps　で充分と思ってる。
そこから1920x1080とかそれ以上に拡大したいTV・PCグラボだけが超解像度技術を搭載してカバー。
1080iから補間を試みるよりは720pから拡大したほうが映像として失う要素が少ないと思うんだけど。
…素人理論ながら。

>>514
インタレースというのは、ブラウン管のようなラスタスキャン方式のデバイスと
相性が良かったけれど、液晶やPDPが主流となった今となってはI/P・P/I変換の
弊害が多い面もある。

あと、インタレースはフリッカを低減するため垂直方向のフィルタを
通さないといけないから、プログレッシブとは単純に解像度で比較できないほど
周波数成分的に垂直解像度が低い。

私は1280x720/60p程度あれば、1440x1080/60iよりも映像としての表現力は高かったと思うけど、
720pって意外と帯域を必要とするから厳しいだろうね。12セグメント使って今の有り様だから。

4:2:0で赤の階段が出るのは補間が掛かっていない環境で見るから
補間掛けても色の滲みが出るのは確かだが、仮に同ビットレートで4:2:2と4:2:0を比べれば、
後者の方が全体的に品質は高くなるのでは。

http://img140.imageshack.us/img140/9673/upconv.png
放送等、インターレースの4:2:0のアップサンプリングはこう言う事になるから、
プログレッシブにするまではやらない方が良いのは確か。

もう今更規格を変えられないだろうから
スーパーハイビジョンの時に期待しましょう

>>522
次は2kデジタルシネマとか4kデジタルシネマな解像度ですか？
そのときにもどうせ今回と同様にインタレの亡霊がワラワラと…あー吐き気がする。
http://furukawablog.spaces.live.com/Blog/cns!156823E649BD3714!4256.entry

>>518
上で既出だが、現状のx264はインタレは効率が悪い方法になってるんだけど。
まともにMBAFFを実装すれば帯域幅の差はより大きくなる。

それと30pじゃ動きがカクカクして話にならないと思うぞ。
24pソースを表現するのも無理だし。

単純なピクセルレートは1920*1080*60i＞1280*720*60p＞1440*1080*60iだから、
BSで1920放送してるところはは720pでも良いが、地デジは720pにすると余計劣化しやすくなる。

>>520
420の方がYに情報を回せて視覚的に良くなる、Yの情報量が同じならトータルで25%削減出来る
ってのがITUでフォーマット策定の時に実験されたりしていたこと。
もちろん映像内容によっては色情報が多い方が良いこともあるだろうし、
レートが高くてYに十分情報が回せていれば422の方が良くなるって事もあるだろうね。

>>519
VFRが基本になって
スポーツが基本60fps、アニメ・映画が基本24fps、
ニュースやバラエティなど普通のが基本30fpsとかにしつつ
携帯のCDMAみたいな感じの変調で全放送局が同周波数帯を共用にしたら帯域節約できない？
（セグメントとかのデジタルTVの周波数帯の扱いはよく知らないんで、既に実施中なこと書いてたらｽﾏｿ）

>>524
＞現状のx264はインタレは効率が悪い方法になってる
？
自分が言いたいのは全放送がプログレになり
そのエンコはx264(並のプログレのエンコ効率・画質のソフト…？)でやればいいんじゃないかってこと。

＞それと30pじゃ動きがカクカクして話にならないと思うぞ。
＞24pソースを表現するのも無理だし。
それについては24pを書き損ねたんで>>525に訂正。

＞単純なピクセルレートは1920*1080*60i＞1280*720*60p＞1440*1080*60iだから、
＞BSで1920放送してるところはは720pでも良いが、地デジは720pにすると余計劣化しやすくなる。
これについても>>525に訂正。

>>525
CDMAはノイズに強いが電波利用効率が悪い（帯域が狭い）、低レートの音声を確実にやりとりする携帯向き。
データ容量の増える4G携帯ではCDMAじゃなくてOFDM（日欧の地デジで採用）が有力になってきている。

impress Direct：OFDM/OFDMA教科書
ttp://direct.ips.co.jp/book/Template/Goods/go_BookstempGR.cfm?GM_ID=2619&SPM_ID=1&CM_ID=004000K60&PM_No=1260&PM_Class=N&HN_NO=00400

>>526
今の放送をH.264に変えてプログレにするって事か。
そりゃ圧縮規格を変えれば1920*1080*60pを実現するのも無理じゃない。
でも今の規格を変えるのは無理、受信機を全部買い換える必要があるし。

それと4K2Kはプログレオンリー（今ある素材は4pのみだが）だし、
NHKが推奨してるスーパーハイビジョン（7680*4320*60p）もプログレオンリー。
H.264もLevel4.2以上はフレームMBしか規定されていない。

完全なVFRを採用するのはノンリニア編集やTVの同期で問題が出るから無理だろう。
今の放送でも60iと24pを混在して送るのは可能、実際に送ってる局もある。
CSなんかは統計多重で複数チャンネルでビットを融通しあってる。

だいぶスレ違いになってきたので、あとは自分で勉強してくれや。

>>519
720pの方が帯域が少なくて済む。
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry?_c11_blogpart_blogpart=blogview&_c=blogpart
＞さらに、映像圧縮に採用されたMPEG2方式においては、
＞1080iは22Mbpsでは最高品質の映像を表示するも、
＞その転送レートを15Mbps以下まで落としてくると映像が破綻する
＞という現象も既知のことでした。720pはMPEG2による映像圧縮でも
＞15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、

他にも書いてあるが。

デジタル放送は規格上720pもある。どこも使ってないけど。

>>528
そこに書いてある1080iは1920x1080/60iの事（22Mbpsでわかるだろjk）。

異なるフレームレートで出力するには、
少なくともデッキは再起動必要だし、
Syncも変えないといけないし、
混在するといろいろ面倒なんだよね・・・。

"MPEG2より10年以上新しい技術であるH.264が、なぜこれほど低画質なのか理解できないと話していた。
もちろん技術的な理由はあるが、あくまでも結果がH.264が映画に不向きであることを語っている」"
http://plusd.itmedia.co.jp/lifestyle/articles/0402/10/news078_4.html

>>531
その問題はFRExtで解決したはず

まあ、変換に8x8を使えないMPで使っても、x264がMPEG-2 Videoに劣ると言うことはなさそうだが。

>>531
何でそんな古い記事を。

本田雅一のAV Trends
http://av.watch.impress.co.jp/docs/20080902/avt029.htm

その柏木氏がMPEG-4 AVC/H.264 Main Profileで圧縮したフルHD映像を見て
「MEPG-2より10年以上新しい最新コーデックなのに、MPEG-2よりも低画質なのはおかしい」
と考え、1年間の期間限定プロジェクトとし、その後、正式にH.264 High Profileとして規格化
される技術を開発したという話は、業界内では特に有名な話である。

→ Main ProfileはMPEG-2よりも高画質にはならない。
→ MPEG-2よりも低ビットレートで画質が良く、同等のレートならばさらに良くなるHigh Profile

5年前かよ

>>530
だよね。
あと、テレビ向けだと入力映像の同期をPLLにかけて表示用同期を生成するように
設計されているから、PCと違って非常に難しい。

アナログのにおいがぷんぷんする

５年前はxvidスゲー！してたなぁ。

マルチに釣られるなよｗ

やられたー！
とくに確認もせず、そろそろ最新版にするかと1171のOreAQ版落としてエンコしてたら
ブロックノイズの嵐だった…。
スレ見たらちゃんと報告あるし、不注意もいいところなんだが俺の丸一日が…。
だれかSeraphy氏に連絡してある？

ICC版だけそうなるね

有識者は、閉口してこのスレを去っていって、今は残りカスしかいない糞スレだなここ。

ID:+R/vOCvjのような自称上級者を見たときは終わったなと実感した。
まぁよく言えばいい感じに枯れてきた、つまり過去ログ見ればたいていのことは分かるってことだろ。

似たような話題がループしてるだけで別に今に始まったことじゃない
つまらんこと言って「新参です」って告白してるようなもんだぞ

上級者に古参、新参とかｗ　一瞬なんかのネトゲスレかと思ったぞ

廃人はいないの？

エンコ廃人

わたしがエンコ（して、うｐ？ｗ）しないとみんな死んじゃう！

>>548
↑いつかつかまるなっ☆ｗ

>>547
エンコしてる間は普通の人なんじゃない？
それとも次のエンコの設定を別のPCでやってるとか？

スレのレベルが下がってきた

颯爽と自称プロフェッショナル登場

更新ﾏﾀﾞｰ

OreAQ1127から久しぶりにバージョンアップしようと思ってのぞいてみたんだが最新は不具合があるのね
ここ数ヶ月で主要オプションの変更あった？

OreAQが細かく指定できるようになった。
今までのでいいならそのままのオプションでおｋ

>>555
レスさんくす

メーリス見たんだがthreaded-slicetypeｸﾙｰ？

x264 defaults changing
http://forum.doom9.org/showthread.php?t=148148

デフォルトそのままで使っている人はあまりいないだろうけど、色々変わるみたいだな。

x264にXviDのグレイスケールオプションみたいなパラメータありますか？

>>558
おおもうすぐ怒濤の更新があるのかね

怒涛の更新がどっとくる

なんてな

　　　　　　　　　　　＿＿___　 ／＼
　　　　　　　　　／　　_＿ ／_＼.　 ＼
　　　 　＿＿／　　　　＿＿__）醤＼,イｌ
　　　　　　　　　　　　　_＿＿_）油／ ┃
　　　　　　　　　　　　　__＿___）／　　┃ 　　　　【審議中】
　　　　　　　　__＿＿_＿＿）／　 　　┃
　　 　　　　　　　　　　 　 　　 　 　 　┃　∴
　　　　　　　　　　　　　 　 　 　 ＿＿┃＿＿　,. -､
　　　　　　　　　　　　＿＿,,. -‐＼￣￣￣ ／/ 　　}
　　　　　　　　　　　　＼　 　　　●＼　 ／　/　　 /
　　　　　　　　　　　　　 ∨　　　　 　.,ｌ |、 ∨　　 'ｰ-　
　　　　　　　　　　　　　　| 　 　 　 　 ⌒′ .|　>>561
　　　　　　　　　　　　　 /　　　　●
　　　　　　　　　　　　／　　　　　　 　　 　 /、　　-----､
　　　　　　　　　　　　￣￣`　..,,＿＿＿_／　＼.＿＿＿ﾉ

>>561

　　　　　　　　　　　　三　　　　|┃┃
　　　　　　　　　　　　　　　　　 |┃┃
　　　　　　　　　　　　　∧∧　..|┃┃
　　　　　　　　　　三　(　　；).　|┃┃ピシャッ！
　　　　　　　　　　　　/　　　⊃.|┃┃

　　　　　　　　　　　　　　　　ｽｯ
　　　　　　　　　　　　i⌒i　ｽｯ
　　　　　　　 　　　　 |　〈|
　　　　　　　　　　 　/ .ﾉ||
　　　　　 ＿（･ω･）/　ii||||　バチーン!!
　　　　／.　　　　 /　iii|||||| 　バチーン!!
　　　/ /＼　　　/￣＼ii|||| 　　　　　.'　　，　．.
　＿|￣￣ ＼　/　 ヽ　＼从/／　・;`.∴　'　　　　　
　＼￣￣￣￣￣￣ ＼＿_）　＜　,：;・,‘　　
　　||＼　　　　　　　＿（･ω･） ’ .'　，　．.
　　||＼||￣￣￣ ／.　　　　 ＼.　　 >>561
　　||　 ||￣￣　/ /＼　　　/￣＼
　　　　.||　　＿|￣￣ ＼　/　 ヽ　＼_　
　　　　　　　＼￣￣￣￣￣￣ ＼＿_）
　　　　　　　　||＼　　　　　　　　　　　　＼
　　　　　　　　||＼||￣￣￣￣￣￣￣||￣
　　　　　　　　||　 ||￣￣￣￣￣￣￣||
　　 　　　　　　　 .||　 　 　 　 　 　 　 ||

　　　　　　　　 　 　／⌒彡　　　 　　 　　　／⌒彡
　　　　　　　 　　 /　冫、）　　　　 　　 　 /　冫、）
　　　　　　　 　　 | 　`　/　　　　　 　　 　| 　`　/
　　　　　　　　 （ ニニニニニニニニニニ_ア　 ／::::::::::::;＼
　　　　　　　　　 |:::::::::::: ｌ | 　　　　 　//´|:::::::::::: ｌ |
　　　　　　　　　 |:::::::::::: | | 　　　 　　| |　|::::卍::: | |
　　　　　　　　　/::::::::::::/| | 　　　　 //　/::::::::::::/| |
　　　　　　　　　|::::::::::/　Uヽ 　　　/Ｕ　|::::::::::/　| |
　　　　　　　　　|::::||:::|　　| |　　　　| |　 |::::||:::|　 Ｕ
　　　　　　　　　|::::||::| 　　| ／⌒彡/　　|::::||::|
　　　　　　　 　 | / | | 　　/　冫、）　　　| / | |
　　　　　　　　 //　| | 　　| 　`　/　>>561　| |
　　　　　　　 //　　| | 　　|　/| |　　　//　　| |
　　　　　　 //　　　| | 　 //　| |　　 //　　　| |
　　　　　　 U　　　 U　　Ｕ　 Ｕ　　 U　　　 U

==========================糞スレ終了==========================

　 　　_,△.
　 （　ﾟ Дﾟ）
　　( つ旦O
　　と＿)_)　

　 　　_,△.
　 （　ﾟ ◎ﾟ） 　　ｽﾞｽﾞ…
　　(　ﾞノ ヾ
　　と＿)_)

　 　　_,△._
　 （　ﾟ Дﾟ） 　　ふぅ……
　　( つ旦O
　　と＿)_)

　　　 _△.
　 （　^ω^) 平和だねぇ。
　　( つ旦O
　　と＿)_)

==========================糞スレSeason2始動==========================

>>559
ないと思います。っていうか、Avisynthでした方が簡単だし。
ttp://avisynth.org/mediawiki/GreyScale

>>558
ちょっと変わりますねぇ…　まぁ、プリセットを使わない限り
ttp://forum.doom9.org/showthread.php?t=148149
で書いてある通り速いファーストパス設定になるだけみたい。そういうファースト
パスを好まない人は --slow-firstpass を入れましょう。

>>557
まぁ、最近そのパッチの開発者もkemuri-_9氏もそのパッチをやっと出したがってる
し。もう殆ど出来てるものだし、Win環境での問題さえ消えれば…

--ref (previousref==1?1:MIN(previousref*2,16))の意味がわからない

>>571
if( previousref == 1 ){
　return 1;
} else {
　return MIN(previousref*2,16);
}
みたいだな。

previousrefとは、チューニング前の--refの設定ですな。

<Dark_Shikari> 1) apply preset
<Dark_Shikari> 2) apply tuning
<Dark_Shikari> 3) apply everything else
<Dark_Shikari> 4) apply profile

プラシーボって名前に噴いたｗ　tesa merange32 やめようかなorz
しかし、結構みんな遠慮せずに突っ込むんだな。 deblock 1:1とか。

>>573
3Dゲーム動画エンコしてるけどumhとtesaじゃ全然違う

>>573
ソースによって結果が違う。それに、小さくても、結果は一応ある。ただ
「速度VSクオリティーの変化」というレベルでは普段あまり変わらないから
#x264ではもはや「--placebo入れようぜ」という単位のジョークになってました。

つまり、ニコニコとかzoome向けにエンコするとオイラも一応--me tesaです。

merangeは32から64にしたら画質が落ちると言うことはないんだよね？

ここって初心者スレだっけ？

むしろ16で

>>571
三項条件演算子でググってみなよ

javaでもcでも使えるけど、読みにくくなるから滅多に使わないな。

#x264を覗いてみたいんだが自分の技術力と英語力の無さじゃ書くのは恐い
ROM専でログインしても大丈夫なのかな？

>>580
そんなチャンネルがあるのか・・・
俺も英語あんまできないしあんま知識もないけど、ちょっとのぞいてみたいな

>>580
普通に大半の人がROMってるから大丈夫ｗ
東方ネタ、うみねこネタとx264ネタの混ざりではあるが、たまには役立つ情報が
出るし、普通に開発者がいるチャンネルだから役目は果たしてる。

AutoVAQ 03きたー！
rev1173に取り込みました。
とはいえ、検証する時間が十分に取れていないのが実情です。
by seraphy氏

「ICC版は配布中止」か

>>580
入ってみたけど誰もしゃべってねえ。
すげえまったりしてるな

時間によるでしょう。アメリカだったら今は朝の4時だし

どんな高尚なチャットかと思ったら
ゆっくりAAのwikiがおもしろいとかそういう話だったでござる。

ゆっくり虐殺おもしれーじゃないだけマシだと思っておこうぜ

>>583

1173のguiを試そとしたけど
これデフォルトだと普通のＡＱ(--aq-mode 1)？
明示的にコマンドタブで--aq-mode 2としたら
例外エラーで出力失敗します

patch版、Ore版ともに

exeしか対応してないんじゃない？
GUI使わないから知らんけど

>>589
Seraphy氏忙しいから、こっちまでは見てないと思うよ。

seraphy のパッチ版--aq-metric 0が通らなくなった

お前らrevどれがお気に入りよ

rev1

>>592
ReadMe読めや

>>595
だから
seraphy のパッチ版--aq-metric 0が通らなくなった
だろ

設定詰めるの面倒臭くなって1163に戻しちゃった。

>>596
それじゃバグみたいな書き方だろ
--aq-metricのオプション自体を廃止したんだから、別に０とか関係ないじゃん

限定的な動画だけど、AutoVAQやっぱ凄いな。 OreAQがかなり残念な結果だけど
ttp://www.mediafire.com/download.php?bxn2oviyj2m (aq-mode 0/1/2)

>>589
.ini直接書き換えて--aq-mode 2にしたらエラー出なかったよ。
AutoVAQ効いてるのかわからんけど。

seraphy氏がreademeにおいおい実装って書いてたから
次のバージョンアップでguiからも選べるようになるだろ
正座して待っとけ

AviUtl使いでいち早く使いたいならx264out.auoで使用できますしね

更新ﾏﾀﾞｰ

>>603
GUIを作ってるところが更新を完成させるまで待ってるらしい。MeGUIとか。

AutoVAQに期待。久々にワクワクしてきた。

x264OreAQ.1173.release02.rar
x264patch.1173.release02.rar

きたーよ

patchのrev1173でHAQだけの動作ができないのだが...
aq-mode 0 : ×
aq-mode 1 & aq-strength 0 : ×
aq-mode 2 : もちろん×
どう指定すればいい？

x264.exe --longhelp

1173で更新されたOreAQのパッチを使ってOreAQ+itvfrのビルドしたんだが
OreAQのパッチが1カ所当たらなくなっちまって困った困った…

と思ったんだが中身見てみると
@@ -830,7 +841,10 @@ static int Encode( x264_param_t *param, cli_opt_t *opt )
if( p_read_frame( &pic, opt->hin, i_frame + opt->i_seek ) )
break;

- pic.i_pts = (int64_t)i_frame * param->i_fps_den;
+ //if( !h->sps->vui.i_pulldown_type )
+ pic.i_pts = (int64_t)i_frame * param->i_fps_den;
+ //else
+ // pic.i_pts = (int64_t)((double)i_frame * (double)param->i_fps_den * ((((i_frame)+1)&1) ? 1.5 : 1.0 ) );

if( opt->qpfile )
parse_qpfile( opt, &pic, i_frame + opt->i_seek );
ってなってるのがitvfrと被って当たらないんだがこれ結局コメントアウトしてるから意味ないよね？
ビルドできるし適当にテストしたけど動いてるみたいだし無視しておｋ？

折角なので、599の最後までも上げてみた。 aqmode 0/2のみ。 40M。
ttp://www.mediafire.com/download.php?xttmm5g2mjt

>>610
よく分からないが2の方がいいのか？

AutoVAQはJEEB氏など早い段階で取り込んでたから実写に使ってたが
アニメ常用にOreAQを常用してるので自分も比較用にAutoVAQで作ってみたら結構イイ

 --aq-mode 2
ってコマンドから設定しても消え去るんだけどそういうもんなの？
0だとちゃんと表示されるのに。

AutoVAQってguiからは使えないのか

やっぱ+VAQなんだな。。。暗部がざわつく
-AutoVAQ試してみるか

え？ -方向のAutoVAQて使えるのか

-使えるの？
俺も駄目だなって思って-VAQ+HAQに戻ってた。

オートバックス使ったらcrfを20にしてもぼけたから-VAQ+HAQに戻した

AutoVAQは盛ると容量減るよ
あくまで個人的意見だけど、bitrate指定ではいい結果出してるから、crf上げればいいはず。
それと線を削ってビット廻すから、(ビットレートに応じて)問題無い程度に調整するといいと思う。qp35で0.2-qp20で0.6辺り とか。

現在AutoVAQでCRFするとAQ無しっぽい結果になるので、一応数字を合わせる必要性
はある。そこを理解すればおｋ。

AutoVAQにすると容量減ったからPsy強くした

psyってどんなアルゴリズム？

ttp://forum.doom9.org/showthread.php?p=1144270#post1144270 (DS氏の説明 "How it works (simply)")
具体的な仕組みとしては、間違ってるかもしれんがこんな感じ。
普通はPSNRが最良になるようにビット配分してるので、アーティファクトの無いツルツルボケボケな画像が良いということになる。
そこで敢えてPSNRの計算式に介入して、多少無理が出ても残す所はしっかり残そう　というものだったはず。

まぁ、オイラだとアニメも --psy-rd 0.5:0.2ぐらいでエンコしてるようになった
けどね。実写の方がもっと役に立つが所がいそうだけど、アニメのgradientとか
マッハバンドを出さないようにしたい時とかおすすめです。もちろん、実写みたいに
強い設定をしようとするとちょっと危ないかと（特にpsy-trellisの方で）。

実写なら余計なオプション使わずにビットレート与えたほうがいいような気がする

x264は、VAQやPsyRDがデフォルトで有効になっていたり、基本的に実写向け。

ゲームのキャプ画面とかはどっち寄りになるの？
アニメ？実写？
ずっと止まってればアニメに近いとは思うけど、エフェクトとか出まくりで結構変化が大きい場合は
アニメと違って1ドット単位で目まぐるしく変わるから実写寄りになるのかな。

リンギングが気にならないソースなら、実写の様に扱えば良い。

>>625
いつもCRFが世話になってるからそこらへんは問題ないかと。

>>627
ゲームのキャプはとりあえずビットレートが命かな？あとは大体デフォからAQ
とかPsyを変えなくてもおｋな気がする。

>>627
自分ならこんな感じpatch.r1173.release03
--crf 18 (19) --aq-mode 2 --aq-strength 0.2 (0.3) --psy-rd 1.0:0.0 --cqm "jvt"
(以下自己満)
-I 300 -i 1 --scenecut 60 -b 3 --b-adapt 2 -r 3 -f 0.0:0.0 --vbv-maxrate 20000 --vbv-bufsize 25000
--qpmin 12 --qpmax 28 --qpstep 8 --ratetol 1.3 --qcomp 0.7 -A p8x8,b8x8,i8x8,i4x4 --direct auto
-w --me esa --merange 32 -m 9 --mixed-refs -8 -t 1 --no-fast-pskip --no-dct-decimate

アニメソースには専らOreAQ + cqmfile使ってたけどHAQのみの動作も可能という事で久々に比較テスコ中

　　/: ;.r' ´ 　 !: : l: ､: / l: :./ l: : /　　.V
　　' ´　　　　l: : ｲ: :./` l:､/　!:./　　　 l　　　じ　　い
　　　　　　　 l: /,l: /＿_ﾚ_｀_ ﾚｭ、　　 l　　　ご　　い
.　　　　　　 /j'‐､l'´.l　 l::::i_ ｊ:::!　l.　　 l 　 　 く　　わ
　　　　　　 l　 f_j __ヽ、ゝ:::::ノ　/　　 .l　　　で　　け
　　　　　　 ヽ/, -- ､ゞ, ｰ- ‐ '　　 　 l　　　　　　 は
　 　 　 　 　 l l　◎ .} ll　　　　　　　　l 　 　 き
　 　 　 　 　,.! ゝ....ノ　ll　　 　 　 　 　 l.　 　 く
　　　 　 ／: :!　　　　 !l　　　　,　---　 l
　　　／: : : : '､ ､__ ,.r'ﾘ.、　　 { ＿＿__ ）､
.　　　￣/: : : :.ヽ --ｨ l　｀ ‐ ,. _　　　　　, ゝ、
　　　 　'' ´｀l: __ﾄ===!ll` ｰ.､ﾉ　　￣￣　!　　 ｿ ‐--...- '
　　　　　　 ｨ´　 l　 ﾄ､l　/　ヽ　　　　　 ヾ:..､　　　＼/`'
　　 　 　 /r' =､､!　 ! .）{　　/､　　　　　 ﾘ::::::＼
　　　　　l.ｆ､　　 .l　 l｀ 'ヽｰ' ､::::` ー‐‐ '　ｧ､::::::ヽ
　　　　　 ll ｀ ｰ- ニ ...イ／　 ｀　ｰ - ‐ '´　 ヽ::::::ヽ

誤爆しますた

>>632
>>631

>>630
以前自分が3Dゲームを試した時は、jvt + psy-rdは悲惨になったんだけど、flatより良いの？　ゲームって実写と違って、文字があるからかなりやりにくいよね＾＾；
チラ裏だけど、アニメは　--psy-rd 0.4 --aq-mode 2 --aq-strength 0.6 でとりあえず落ち着いた。

落ち着いたとか言いつつテスト続行。　我ながら暇人ｗ
aq-strengthを0.0-1.0まで0.2刻みで変えて、同じビットレートになるようにcrf値を調整。 DS氏曰く、恐らくbitrate指定よりも更に良いとのこと。
ソースはゼロ魔1期OP(SD。　いい加減ソース変えろと)で、通常の用途を想定ということで、普段使っているNRをしてあります。 ･･･まだシャナ1期OPのが良かったか（ぇ
ttp://www.mediafire.com/download.php?zzmfozzzdmz (81.8MB)

>>635
三回ダウンローダし直してもやっぱり書庫が壊れてるんだって

http://hdimage.org/images/ilqca5j8ll9vh19x096l.png
0.0と0.2の二つは大丈夫みたいだが。

一万円の超低価格サーバー専用機に5000円のゲフォ9500GTいれて
MediaCoderのCUDA変換で30分番組が20分ぐらいでエンコード出来ちゃうんだが
もっとアドバンテージがほしい

>>636>>637
ごめんなさい。上げなおしました。　4回上げてやっとまともに解凍出来たorz
ttp://www.mediafire.com/download.php?izyzdgfjyaz

>>638
H.264でなら俺も待ち時間無しのリアルタイムエンコードしてるよ
でも綺麗にコンパクト化したいから気に入ったものはx264使ってる

速いだけのエンコーダとかどうでもいいから

>>637
今度は大丈夫だった。

せっかくだから主観を書かせてもらうと、グラデーションになっている所は1.0が良いけど、
0.0でも目立ったアーティファクトは見られなかった。

新しいパッチを出しました。一番人々に関する奴についてちょびっとのレポートなのです。

r1175:
Early termination for chroma encoding
Faster chroma encoding by terminating early if heuristics indicate that the block will be DC-only.
This works because the vast majority of inter chroma blocks have no coefficients at all, and those that do are almost always DC-only.
Add two new helper DSP functions for this: dct_dc_8x8 and var2_8x8. mmx/sse2/ssse3 versions of each.
Early termination is disabled at very low QPs due to it not being useful there.
Performance increase is ~1-2% without trellis, up to 5-6% with trellis=2.
Increase is greater with lower bitrates.

r1177:
Totally new preset system for x264.c (not libx264), new defaults
Other new features include "tune" and "profile" settings; see --help for more details.
Unlike most other settings, "preset" and "tune" act before all other options.
However, "profile" acts afterwards, overriding all other options.
Our defaults have also changed: <long setting string omitted>
Users will hopefully find these changes to greatly improve usability.

新しいプリーセット・プロファイル・チューニングシステムの基本的な要約。

プロファイル。設定された場合、プロファイルは全てのユーザー設定をオーバーライドします。
「high」,「main」, 「baseline」と三つの選択になります。今後のx264のデフォルト設定は
High Profileになりますので、プロファイルを設定した場合、設定されたプロファイルに届くため
に必要な限り設定を落とすことになります。例えば、「--profile high --no-8x8dct」の場合だと、
勝手に8x8dctが使用されません。そして「--profile baseline --8x8dct」の場合も、8x8dctが使用されません。

プリーセット。プリーセットは速度と画質のどちらかの方に設定をまわして、
x264のデフォルトを変えます。ユーザーが何らかな設定を自分で設定した場合、
オーバーライドにはなりません。逆にユーザーの設定がプリーセットをオーバーライドします。
注意：この下に書かれてる通り、x264のデフォルト設定は変更されることになりました。
今後のデフォルト設定:「--subme 7 --bframes 3 --weightb --8x8dct --ref 3 --mixed-refs --trellis 1 --crf 23 --threads auto --no-psnr --no-ssim」

プリーセット一覧（上に書いてあるデフォルトに対して）

ultrafast: --ref 1 --scenecut 0 --nf --no-cabac --bframes 0 --partitions none --no-8x8dct --me dia --subme 0 --aq-mode 0 --no-mixed-refs --trellis 0
veryfast: --partitions i8x8,i4x4 --me dia --subme 1 --ref 1 --no-mixed-refs --trellis 0
fast: --no-mixed-refs --ref 2 --subme 4
medium: デフォルトのまま
slow: --me umh --subme 8 --ref 5 --b-adapt 2 --direct auto
slower: --me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2
placebo: --me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

チューニング。チューニングとはソースか使用目的に合わせて選択された細かい設定を
使用します。プリーセットみたく、ユーザーの設定の方が上になって、
デフォルトではチューニングが一切使用されません。

film: --deblock -1:-1 --psy-rd 1.0:0.15
animation: --ref [presetref>1?presetref*2:1] --deblock 1:1 --psy-rd 0.4:0.0 --aq-strength 0.6 --bframe presetbframe+2
grain: --deblock -2:-2 --psy-rd 1.0:0.25 --no-dct-decimate --pbratio 1.1 --ipratio 1.1 --aq-strength 0.5 --deadzone-intra 6 --deadzone-inter 6 --qcomp 0.8
psnr: --psy-rd 0:0 --aq-mode 0
ssim: --psy-rd 0:0

ゆっくりたのしんでいってねっ！

grain: --deblock -2:-2 --psy-rd 1.0:0.25 --no-dct-decimate --pbratio 1.1 --ipratio 1.1 --aq-strength 0.5 --deadzone-intra 6 --deadzone-inter 6 --qcomp 0.8

これとかなんだかな〜。逆にそんな設定にしないとgrainは保持できないのかって感じ。

psnrとかssimとかは、やっぱMSUへのあてつけかね？

>>644
原文どこ？

>>648
D_S氏に翻訳を頼まれて、そっちの方がIP制限にかかっているため、オイラが
結局レスすることに。元々他のところでは公開されてない文なので、これは
２ちゃんねるでの文が原文になるということに。

英語で読みたいのなら、
ttp://pastebin.com/d2da0adb
が元の英文である。

�d

ゆっくりってｗ

とりあえず：
　・fprofileのコマンドが壊れてる
　・nal-hrd使いたいなら
　　ttp://forum.doom9.org/showthread.php?p=1303203#post1303203
　　にちょっとだけ変えたパッチがある。他のパッチは大丈夫みたい
　　＠ x264_win_zone_parse_fix_05.diff , x264_AutoVAQ.03.diff

>            else if( !strcasecmp( optarg, "touhou" ) )
ちょwww

東方厨DS乙だわぁ

パッチが当たらなくなってビルドできない。更新ﾏﾀﾞｰ

>>639
ぶっちゃけ、いっていい。

全部、大差なし。反論は認める。

komisarのパッチを使っても、fprofileでエラーが出るな。

>>656
revision 1179でfprofileもようやく直された。
やっと落ち着いたってことか…
っ ttp://forum.doom9.org/showpost.php?p=1303344&postcount=1959

--progressがデフォになったのか

seraphyﾀｿ更新お願いします

ちょｗ --tune touhouとかあるのかよｗ

ピンポイント過ぎるなｗ
同じ労力を別の無修正動画摘発に生かせば良かったのに

ごめん、誤爆。

>>631

>>660
強ち間違ったレスではないかもなw

誤爆？

と思ったらニュースかｗ

x264-r1179-threaded-slicetype-v16.diff

http://gigazine.net/index.php?/news/comments/20090709_zerocodec/

>>660
一行目何の違和感も感じなかった

>>666
losslessYUY2でいいじゃん別に。

今のところx264のロスレスの勝ち。Pengvado氏がFFV2を完成させればそっちが
勝つんでしょうけどねぇ…

まぁ、x264の今のところのロスレスはYV12カラー空間のみだけどね。

seraphyビルドｷﾀｰ

ひ・・・東方・・・

クレイジーダイヤモンド？

プロファイル > ユーザー設定 > プリセット
こういう優先順位でオプションが働くと思えばおｋ？

x264_OreAQ_itvfr_r1179の中の人見てるかな？いつも乙です
hrd_pulldownはitvfrで解除するから必要無の方向でいいと思います

オプションの変更が多くて大変

>>674
じゃあその方向で。
何かあったらここに書いて貰えれば見てますので。

いきなり細かくなってわからなくなった
地デジのHDの最適なのはどれ？

追加されたのは、コレだ。
--profile Force H.264 profile [high]
Overrides all settings
- baseline,main,high
--preset Use a preset to select encoding settings [medium]
Overridden by user settings
- ultrafast,veryfast,fast,medium
- slow,slower,placebo
--tune Tune the settings for a particular type of source
Overridden by user settings
- film,animation,grain,psnr,ssim,touhou

3つが何を意味しているかというと、profileは名前のまんまH264のprofile、presetは速度と品質のトレードオフ、tuneは素材に合わせた最適なセッティング だ。
よって、ソースに合わせて替える必要があるのはtuneということになる。
項目を見ていくと、film(映画,ドラマ),animation(アニメ),grain(粒子保持),psnr&ssim&touhou(ネタ?)。
この中から当てはまる者を選べばいい。

選べばいいっつーか、こんなもん使わんで今までどおりの長いやつ書けばいいんじゃね？
まあ、設定の参考にはなるけどさ

ffmpegのオプションを解説しているサイトはありませんか？

help見てもどのオプションがどのコーデックで有効なのか書いて無くてさっぱりわかりません…

>>678
thx
自分のやろうとしてるのが非常に光り変化の多い
また細かいLED照明のある音楽番組なんだけど
明らかにドラマとかの定点カメラ撮影とは違った種類の映像なんだわ

grainかな・・・

教えて君状態で申し訳ない

>>680
http://mobilehackerz.jp/archive/wiki/

ここのFFMPEG　USAGEと最新FFmpeg読めば、大体はわかる

>>680
コーデック毎のオプションの問題は最近ffmpeg-socで議論されてMichaelさんが実装することになってる。

しばらく細かいところはソース嫁状態が続くのかなあ
こういうときこそx264wiki活用してあげようぜ。
管理人がアレでも場を作ってくれたのは事実だし。

>>681
tuneを決めるときは、動きを考慮する必要は無くて、静止画としてどれに当てはまるかでいい。
(grainは映画等の細かい粒子を全部残すための、容量無視のかなり無茶なオプション)
filmを選んで、更に、動きが激しいということなので--qcompを上げてあげればいい。

･･･結論としては、679氏の言うとおり、ちゃんとtuneで弄られるオプションの効果については
一つ一つ実験して把握してた方が良いということになる^^;

r1177で追加されたpresetやtuneは初心者に扱い易いだけの話だよね？
試してないけどこんな感じで使えるんじゃね
x264 --crf 21 --sar 1:1 --level 4.1 --profile high --preset slower --tune animation --progress --output out.mp4 inp.avs

--progressはもうないぞ

>>685
どの時代のどんなエンコーダーもそうだけど
作りながら作りながら少しずつセッティングを完成ですね
アドバイスありがとう

そうなんだなー --longhelpを見たら --progressがないんだなー
試してみたら --weightbなどが標準になったみたいなので
切るには --no-weightbにしないとダメなんだなー

ちゃっちゃと新しいのにしないと浦島状態になってオプション理解できなくなるんだろうな〜
でもﾏﾝﾄﾞｸｻｲ('∀`)んだな〜

--mixed-refsもか

さすがにr967使い続けるのは厳しそうだな

100以上もリビジョン開いてると速度的にかなり変わりそう

っていうか、r967はHolger氏の激速パッチも入ってないように感じるんだけどねぇ^^;
っていうか、--b-adapt 2が出る前のレビジョンではないか…　速度だけじゃなくて
画質に関するアップデートも出てるから早く更新した方がいいかと…

たまに、--longhelpと睨めっこしながら一から書きなおせば、あらスッキリｗ

なんかバカにされそうなこと言うんだけど、umh(merange 16,32,64)とtesa で俺式ブラインドテスト(笑)したんだけど、
tesa>>umh16>umh32>umh64 な結果になってしまった。もちろん2pass。　　どなたか暇な方はやって貰えたら嬉しい。

因みにやり方は、出来上がったファイルを、キーボードごちゃ押しの意味不明な名前で書き換え続けると、
どれだか解らなくなるので、その状態で見比べて、最後にAVInapticでオプションを調べる、というもの。

aviutlでせこせこエンコしてるんだが、もしかしてニコエンコの
設定をいじればニコ動用以外のファイルも普通にエンコできる？

>>696
スレチ

--merangeはx264 初心者質問スレを検索してみれば？

placebo: --me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

"--merange 24" なんで24？ 8の倍数てことなのか

だんだんLameみたいになってくな

まあ.mp3と違って停止画面で10倍以上拡大も出来るしサイズ筆頭に指針になる数値も無数にあるがな
止めて一枚ずつチェック出来るのは音楽との明確な違いの一つだな

>>699
俺もそう思った
--preset fast medium --vbr 800とかになるんじゃねｗ

x264の"AUTHORS"に、LAME開発者のGabrielが居たりする。

>>701
そのうちに
--vbr-new 800だけでおｋ
ってなるんですね わかります

それはそれでいい思うのは俺だけ？

もうここ数ヶ月は設定弄ってないから別にどうでもいい

>>705
r1177より前のビルドのままにしとくの？じゃこのスレ来る必要ないんじゃ？

特別な不具合でもない限り
最新追いかけない奴はこのスレに何の用があるの？

1181

久しぶりにエンコする必要が出来たので北。

オプション考えるのめんどいなーって思ってたんだけど、ProfileやらTuneでいいのかしら。

--nal-hrdのパッチってどうして公式にマージされないの？
何か副作用とかある？

再生機互換かね

>>710
おそらくパッチが完全にテスト・チェックされてないからかな？
一応--nal-hrdとかコマンドラインに入れない限り普通のエンコするし。

まぁ、x264の開発者は無駄なパッチを入れたくないとも仰ったんだけどねぇ…

地デジのアニメ向けでx264エンコ前にほしい画質改善フィルターある？
具体的にどうぞ

スレチ

>>713
ほしいってのは、こんなのあったらいいなあってことか？
もしそうなら、今の10倍速いRemoveGrainとMDegrainとDfttest

>>713
あるけど、作ってくれるって話?

スレチな上に、素直に教えてと言えない人にレスをしないで下さい。

失礼しました

>>715
速度改善は難しいっす

>>718
これ実装してほしい
http://www.cs.tut.fi/~foi/SA-DCT/Present_2006/

あれ･･･ プラグイン作者の方でしたか。　こちらこそ失礼したようでorz
でも、なぜAvisynthスレかAviutlスレでやった方が良かったと思います。
･･･スレチでも我慢しきれないんで言ってしまうと、tritical氏のNRﾌｨﾙﾀやNNEDI2辺りのGPU化が需要あるんじゃないでしょうか。

NL-Meansを高速化して欲しい

GPU変えろよ

r1179ってマルチスレッド効いてないんじゃないかな。
かなり遅くなったし、CPUが軽くなった気がするんだけど。

どこビルドよ
俺ビルドは普通だが

NL-Meansって一見ノイズは除去できるが、人間の目に見えない高周波でディザみたいなのが
付加されるから、その不要なデータのせいで結局エンコするとサイズが増えるんだよな。

んでAQ使えばちょうどよくなる

Degrain/noise filter
http://forum.doom9.org/showthread.php?t=145831

静止画はともかく、動画ならMVDegrain3で良さそうではある。

>TNLMeans is based on a gaussian-weight, zero-mean assumption.
>Now, strong Film Grain compressed by Mpeg-2 at DVD-ish bitrates does not really fit that model.
と言ってるから、あからさまなグレインの除去での話じゃないかな。 MVDegrain3全力プッシュではあるんだけど。

>A filter that can cope with strong noise can always be adapted to act weaker, if needed.
とも言ってるけど、微弱なノイズの(徹底的な)除去にはTNLMeansが適してると思うんだよな。
ただ、自分がDidée氏より正しいとは到底思えません。はい。

最近の変更で --no-
が頭に付いたのはそのオプション使いたければナニも足さなくてOKって事ですか？
なんか今まで通りのオプション突っ込んでもコマンド通るみたいだけど。
このオプション使うって自分で指定するほうが精神安定的に良いなぁ('∀`)

そう。　デフォルト値が変わっただけの話だから、今までの記述通りでも大丈夫。
精神安定的にも、revの変更にも振り回されないためにも、書いておくと安心ｗ

>>730
ども、サンクス。

AutoVAQはいい感じに容量減るなあ
seraphy氏版x264OreAQ.1179で色々試してみたが--preset placeboにするととんでもなく遅いんだな
今まで通り個別に設定した方が好きだな

>>724
みんな普通に使えてるのか。信じられないな。
エンコ時間とエンコスピード、出来たファイルサイズを比較してみたよ。

r1173
　profie Main ,level 4.0
　14分24秒
　45fpsくらい
　266MB


r1179
　profie High ,level 3.2
　29分34秒
　22fpsくらい
　209MB

ソース：テレビ録画のアニメ720×480（24分）
オプション：--crf 20 --threads 0 --interlaced --nal-hrd --vbv-maxrate 20000 --vbv-bufsize 25000

ほぼ２倍の時間かかってるから、マルチスレッド関係かインタレ関係と思うんだけど。
levelも違うし、ファイルサイズもかなり小さくなってる。
画質は良く分からないけどほぼ一緒かなぁ。

>>732
あれがあそこまで遅い原因は--bframes 16 --b-adapt 2だから
--preset placebo --b-frames 3とでもすれば、そこまで遅くはないと思う

ところでultrafastを1280ｘ720のy4mソースで試したら、190fpsでた（Q9450定格）
--preset ultrafast --bframes 2 --b-adapt 1でも100fpsくらい
なるほど、このスピードなら、糞画質でよければフルHDもリアルタイムエンコ可能ですな
ｘ264速過ぎｗ

>>733
Linux@x86_64 での話だけど、r1173 で --threads 0 だと single thread で動くようになった(core 数に認識をミスってる?)ので、明示的に thread 数を指定するように option 指定を変えたことはあるけど…

コア数の自動認識（コア*1.5）が --threads auto 指定な俺は女子高生

>>733
>>643-645
Defaultのオプション変わってるんだからあなたの書いたオプションしか記述してない
ならそれでしごく当然じゃないか。

>>737
ありがとうございます。なんかデフォルトがすごい変わったんですね。
確かに綺麗に縮むけど、エンコ時間２倍はちょっときついのでr1173で我慢します＞＜

--ref autoとかいうパッチが出てるな。便利かもしれん

1179のプリセット機能いらないから廃止してくれ。邪魔くさい

必要ないと思うならお前が使わなければいいだけの話だから

>713

アニメSD->HDにアプコンされてるソースによくあるアプコン縞を解消するための
Avisynth用のダウンコンバートフィルタがあったら嬉しいです。
要するに
http://www.geocities.jp/flash3kyuu/
の「インタレース維持リサイズ」ってことなんですけど、これAvisynthで使おうと
すると最新版は、位相を９以上にするとハングして使えず、旧版はリサイズを
縦720にするとやっぱりハングしてしまって・・・。
他の選択子としては「あに瓶」さんのところにあるスクリプトですが、これも副作用や
速度の面からちょっと難しいところがあります。

みんなアプコン縞って気にしてないのかな？
ソースによってはかなりブレブレになってしまうと思うのですが・・・。

muken氏のところに関数書いてなかったっけ

2MT,位相は-を使う、1MT,720以上は位相を使わない

位相は32周期だから+15と-17は上下の位置以外は同じになるはず

前から気になってたんだけど、位相って何の波形の位相なの？
小数点以下の縦位置調整にしか見えないんだけど。

確かに変だよな。32分の1ピクセル精度で重み付けしてるだけだと思う

>745

前から思っていたのですが、+15にするなら+16の方がぴったり合うような・・・。
ソースがYV12なら縦は２の倍数になるかな、とか・・・。
屁理屈ですし、ソースによって違うというのは当然なのですが。
+15が作者の例という以外なにか根拠があったりしますでしょうか。

スレチなのになんで答えてんの君ら。

>>748
32分の1刻みでずらしてんのに偶数だの奇数だのいうのはナンセンス。
君の屁理屈を返すならフィールドリサイズで目立つのは輪郭の違和感であって
輪郭は普通黒でということはY成分しか持たないんだから奇数でもおかしくないと言える。
これだって大間違いだけどな

>>739
それ、refを自動でlevelの上限に合わせるんじゃなくて、
levelの上限を超えてる場合に、収まるrefまで警告と共に落としてくれるパッチなら便利だと思う。
--profileも数字まで指定できる(しなくてもok)ようにして、vbvの設定もやってくれれば便利。

>750

なるほど。勉強になりました。

>>751
まぁ普通それくらい把握してオプション練るけどね
今回のビギナー向けオプションと合わせて考えればビギナーにはいだろうね

>>746
モニタのクロック位相調整と同じで、
映像信号自体が波形だから、位置調整は位相調整になるかなと。
位置の微調整というより、
サンプルを取る開始点を変えるのが目的ですし・・・。

>>748
根拠なしで、見た目です。

遅ればせながら俺もAutoVAQ試したが、確かに容量けずれるな。こりゃいい。
ところでAutoVAQ 03ってのは、それまでのとどう違うの。

>>755
--aq-mode 2に入るだけ。それ以外の変化はあまりなかったかと。ビルドしてる
人として色々楽になったなぁ…って感じ。あと、ちょっとソースが綺麗になった
って感じかな？
ttp://forum.doom9.org/showthread.php?p=1299510#post1299510

�d、中の人向けということか

二つのビルド（一般 & AutoVAQ)しないで済むので、そういうことで便利。
Seraphy氏のパッチも--aq-mode の1以上の数字を使ってるかもしれないので、
そっちは問題があるかもしれないけどね（そのまま使おうとしたら）。

思ったんだがOreAQとMixAQも--aq-modeで使い分けるようにできないのかな。
そしたら配布するバイナリも1つにまとめられるのに。

>>759
番号の制限がなかったら
{0,1} - defaultの奴
{2} - AutoVAQ
{3..} - OreAQ,MixAQなど
って出来るような感じがしなくもない…　確かに一つのバイナリの魅力は
結構感じるものですね。

>754

もしかして中の人ですか？！
Avisynthへの移植が可能でしたら是非にも・・・。YV12が使えれば高速になりますし。
位相も+方向が使えないと下が切れてしまうソースなどもありまして。

ここはx264のスレなんだが
いい加減Avisynthのスレでやれよ
http://pc11.2ch.net/test/read.cgi/avi/1246414384/

>>760
是非それやって欲しい。
x264guiで同時にOreAQとMixAQをバッチ登録できるようになるし。
現状でそれやろうと思ったらguiのソース変更して2つauo入れとかないといけないからハードルが高い。

すっぴんのバイナリでも、--interlacedっていうのはあるけれど、
フィールドオーダーを指定するオプションというのは見当たりません。
この理由、ないし解説しているサイトをご存知でしたら教えてください。

x264自体にフィールドオーダーは無用ということなのでしょうか・・・？

patch版には--tffと --bffがある

--interlaced = --tff

>>764
http://komisar.gin.by/x.patch/x264_hrd_pulldown.13_interlace.1178.diff

このパッチを当てたバイナリで、"--nal-hrd --tff(--bff) --vbv-bufsize 31250 --vbv-maxrate 25000"として使う。
VBVの数字は、想定する再生環境に合わせて変えたら良い。

>>759
これ、おまえらが以前に「tobinaka余計なことすんな」って言ってた内容だぞ。

余計なことすんなって皆が言ってたのは、嫌がるseraphyをｘ264のIRCに引っ張り出そうとしてたことだろ

VFR Studio Returns(仮)見たけど遅くなるんなら結合しないでほしいわ
muken氏ビルド使いとしてはね

遅くなるのか。マジで？何かイメージしにくいんだが。
2つから1つを選ぶのも4つから1つを選ぶのも時間変わらないんじゃないかと素人からすれば思うんだが。

>>771
ttp://zoome.jp/VFR_maniac/diary/69/
じゃぁここに書かれているのを音読して、そう思わなかったら思ったことビルダーに言えばいいんじゃね

これで遅くなるならAQmode on/offでも遅くなるんじゃないのか？
（つまり選択肢をつけなければますます早くなるって事になるが・・・）

１ループごとにif文を呼び出すような非効率なソースになってるとは思えないし・・どうなんだ？

tobinakaがOreAQをDS氏に紹介して、AQ切り換え用にと--aq-mode実装の一端を担っていただろ。

>>773
だよねぇ。
AQが実装された時にAQ使わないエンコが遅くなるなんて話はちっとも出なかったけど。

>>774
tobinaka乙

>>768
　<checkers> can you gently suggest that we don't need inf. AQ algorithms?
　まぁ、こう言われてるけど、一つにまとめられるならそれでおｋ。
　(オイラみたいに、外の人はOreAQ/MixAQのいいところ・悪いところ分らない
　からねぇｗ）

　ずっとテストしようと思ってたけど、今までやってないしｗ

>>769
　黒船って呼ばれて、出来るだけ人を出そうと思ってた時はそこまで
　彼を嫌がらせたとは知らなかったなぁｗ

>>777
tobinaka乙

最悪の被害は最良の意図によってもたらされると心得よ

＞知らなかったなぁｗ
うわぁ

>>778
　そもそもTobinaka氏はIRCにはいないという件がありましてね…
　確かにDoom9でSeraphy氏のパッチを少し紹介したのは彼ですがね。
　(スレ名が「AviUtlでのAQのビジュアライズ」になってますけどね）

>>779
　そして、--aq-modeの「2」にAutoVAQが入るという証拠もないし、正式的には
　完全に違うものが結局入るかもしれないし。そういうところから見れば、
　「2,3,4...」も全部使えないわけになります。まぁ、OreAQとMixAQはパッチ
　的に嫌いなので、一緒にしても、しなくてもどうでもいいと思います。

　まぁ、DS氏の前に聞いた意見は「とある理由で（そういう事のために）その
　オプションを残しましたよ」だと。
　ttp://forum.doom9.org/showthread.php?p=1299332#post1299332

>>780
　そのレス意外、何もやってないからね。実際にDS氏も２ちゃんねるでレスったし。

とりあえずtobinakaはうざい

外の人の正体はkemuri-9氏だったか

>783

それはない。

俺も別にtobinakaをうざいとは思わんな

ただ、やたらなんでもかんでもwikiにしたがるのはどうかと思うが

ああいう目立とうとしてる輩がそのうち自滅するの何度も見てきた

自分の意見がみんなの意見だと思い込み、よかれと思って
先頭切って走り出したは良いが誰も付いてきてくれないばかりか馬鹿だのウザイだのと揶揄される
まぁ、よくある事だ

>788

ただ文句言うのが好きな人もいるからね。
悲しい現実だぁね。

とにかく、x264の開発とは無関係な個人の話でスレを埋めるのは不毛だ。

今一番軽くて良いバージョンって970か999かな

何でやねん

黙って最新版にしろや、高速化は常に行われてるんだよ。

900'sワロチ

>>791
>>707

616 ：[名無し]さん(bin+cue).rar ：2009/07/13(月) 22:26:07 ID:FVKrHI2V0 sage
PT2発売予定だそうです
ttp://earthsoft.jp/PT/specification-PT2.html
PT1のときと同数の2万枚分の材料を確保してるそうです

Seraphyさんとこの掲示板に何かあったのでビルドして遅くなるってのがマジなのかやってみた。

通常MixAQ
Elapsed Time: 0:08:27.593
Process Time: 0:13:31.875

統合MixAQ
Elapsed Time: 0:08:17.140
Process Time: 0:13:33.015

確かに遅くなった。

気持ち悪いやつがなんか見えた気がした

>>797
そもそも最後までエンコして計ってない時点で(ry

1181でプリセットの挙動を見ていたんだが
ultrafastだとガンマが変わるのか黒っぽくなった。
fast以上は色が浅めになる。俺だけだろうか。

結局プリセットなんか作ってもオプション１つ１つの意味が分からなくてこういう書き込み増えるだけだよな

プリセットがあんまり実用的とは言い難い気がする
これは動画の質をそろえるとき位にしか利用価値がないんじゃないかなぁ

今のところ1173が速度面で鉄板か

ttp://sakurawind.hp.infoseek.co.jp/x264_cm.jpg

x264と厳密に関係ないけど、flashプレイヤーって色空間の指定をしてやらないと、BT.601の動画をBT.709で伸張してしまうんだな。
ネットで動画を公開する人は、意識的に--colormatrixのオプションつけた方がいいかもしれんね。

つけてますがな。

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

あっちにいきなよ
まあ、とっくの昔にそれは常識になってんだけどね

>806

そうとばかりも言えない。
普通でもデコーダを変えることがあるし、その場合におかしく影響がありえる話だから
いずれにしても--colormatrixの設定は推奨すべき。

>おかしく影響

影響

付けてエンコ遅くなるなるようなオプションじゃないし普通付けるでしょ
ちゃんと読み取るデコーダー環境で再生してる人なら

>>807
だからあっちじゃ指定するのが常識だっつーの

>>807
http://nicowiki.com/aviutl_h264.html#c702bd6f
の表の終盤とか見ていただければ。

そこ追加されたの何ヶ月前だったかな？

BT.709でRGBにデコードするべきソースも、SMPTE 170MだとVUIが付いてエンコードされていそうだな。

ColorMatrixでBT.709→BT.601に変換しても--colorprimeは変わらないんだよね。
--transferはHDソースでもSDソースでもbt709=smpte170mではなくて
bt470m（γ2.2：カメラやディスプレイの標準値）が使われてるって記述もあるし。
よくわからん…。

色域やガンマまで読んで補正するプレーヤーはないんじゃない？
まともにやろうとすると3次元ルックアップテーブルが必要だし。
とりあえずマトリクスだけ指定しておけばいいかと。

>>814
普通のテーブルルックアップで良くね?
libswscaleのソース読んでみ?

そういや角川がようつべで流してるハルヒをPS3で再生したら
カラーマトリックス誤爆してるっぽかったな

BT709で伸張って一体なんだよｗ
YC伸張みたいに使うなよ。

r1179以降preset選ばないとgui使えなくなっちゃったな。
いい加減CLIにしなさいってことか。

ユーザー設定のオプションが優先されるから別に問題はないだろ

overrideするためにユーザー設定に全パラメータ書くことになって、
結局gui使ってる意味ない。

readmeにpresetとtuneはデフォルト値を変更すると書いてなかったか？
どうせ読まずに思い込みで書いてるんだろうが、こんなんばかりだと作者も大変だな。
ま、たとえ読んでいなくとも、設定変更したときのオプションの変化具合をみれば分かりそうなもんだがね。

r1179以前のデフォルトは腐りすぎてたと思うよ。
presetも妥当な内容で並んでるし、tuneもできたから、
誰でもソースに適したきちんとした設定が出来るようになった。
それ以上の調整は、出来上がったものを見て判断出来ないと駄目だしね。

ツンデレなエンコツール「つんでれんこ」
配布先 http://loda.jp/tsun_dere_enc/
広告動画 http://www.nicovideo.jp/watch/sm7634361

以下を含むDQNパッケージで大好評！

再配布禁止だけど同梱！
neroAacEnc

GPL？ライセンス？何それ状態「欲しいファイルだけ詰め合わせ」
AviSynth http://www.avisynth.org/ GPL
FFmpegSource http://ivtc.org/new/ GPL
swfextract http://www.swftools.org/ GPL
TDeint http://bengal.missouri.edu/~kes25c/ GPL
WAVI http://sourceforge.net/projects/wavi-avi2wav/ GPL
x264 http://www.videolan.org/developers/x264.html GPL
FFmpeg http://ffmpeg.org/ LGPL
MediaInfo http://mediainfo.sourceforge.net/ja GPL/LGPL

作者がツンデレ

なんだこれ、ロダ落ちてて見れないが勝手にツールまとめちゃってるのか？
これだからニコ厨は（ｒｙ

アンインストールbatの中身見て吹いたわw
そういえばMeGUIはライセンス関係どうしてるの？直接落としてる？
GPLはソース一緒に入れてたら再頒布出来るんだっけ？

http://megui.svn.sourceforge.net/viewvc/megui/
MeGUIはGPL

アンインストール.bat起動したら画面殴りたくなるなこれｗ

>>823
これマルチしてんの作者じゃねーの？

x264.1181.release02

ニコニコ隔離スレが機能してないのか

>>826
MeGUIは出来るソフトを自動更新システムに入れてるけど、neroaacencっぽい
ものは自分で落とさないとダメ。ユーザーにとっては面倒かもしれんが、
一応ライセンスってものがあるからねぇｗ

>>829
26threads 様子見

AutoVAQ(TEST)に--aq-mode 3 --aq-power (0.5,1,2,3)?が付いた

http://forum.doom9.org/showpost.php?p=1306087&postcount=93

なんと！

r1183

ttp://git.videolan.org/?p=x264.git;a=commit;h=f21daff3dc11cf5881f1727c3c9d505f0810d20b
ttp://x264dev.multimedia.cx/?p=96

結局、どういう素材またはどういう目的の場合にpsy-rd x:y のyを正の値にすると効果的なんでしょうか？

>>834
IRCでそのパッチがビルドには必要じゃないと話して「他の意見な〜い？」って言ったら
「テストだけのために作ったし、もちろん必要ないんです。」
と本人に怒られたｗ。

>>837
結局、アニメだと --psy-rd 0.5:0.2 にしてるなぁ。結果が小さいけど、アニメは
だと悪い反応も一部の人に出てるんで、これ以上上げてないんです。

基本的にpsy-rdの最後の奴はpsy-trellisと言って、安全的な範囲は0.2...0.4
だそうです。実写で0.8も使ってる人もいるけどねｗ

trellisって、deadzone指定とどっちかを選択ってことで効果はなんとなくわかると思うけど、
割に合わない部分を捨てて、全体的な画質を上げよう　ってオプション。
psy-rdはそれ(RDによる最適化)に文句を付ける仕組みだから、基本的にpsy-trellisは危険ｗ

ttp://www.marumo.ne.jp/db2007_7.htm#7 (まるも製作所 - trellisについて)

PSNRやSSIMが悪くなる様な歪みが出ても、何らかのディテールが有った方が、
人間の視覚には好ましいと言う事だから、ややこしいわな。

>>841
PSNRやSSIM目的だけでエンコしてるなら、AQ, psy全部消せよ。そうじゃないと
比べにならないからねぇ。

まぁ、開発者たちも何度も言ってるけど、
「数字だけじゃなくて、出た画像自体を見ろよ、この変態どもめっ！そして、
数字だけを見てれば、ちゃんとその数字が当てになってる設定にしろっ！」と
です。

個人的にはCRFでエンコしてるけど、Psy-trellisは0.2あってもあまり画質が
落ちないし、問題ない。問題があればソースごとに消すか設定を見直す。

そして、D_S氏からまた新しいエンコーダーテスト用の動画だ
ttp://mirror05.x264.nl/Dark/force.php?file=./LosslessTouhou2.mkv

大事なのは、同一ビットレートでの画質だからね。
仕組み上、psy-trellisはpsy-rdより更にデリケート(二律背反?)で、
効果を上げ難いということを言いたかった。　使いどころということだったので。

>>841氏が言いたかったのは、「エンコーダーが最適化するためにあるPSNRが
絶対じゃないんじゃ、その先のコントロールって難しいよな」　ということじゃないかな。

x264は実写向きだからアニメは辛い

海外では映画のエンコードが主用途だからな

PSYもVAQもみんな実写向き

>>844
x264が実写向きだったとは始めて知ったよ

>>844
そう言いながらDaiz氏のテストではPSYもいい結果出してたしな。
あと、動画関連のソフトってのは意外とアニメをエンコしてる人と関わってるん
だよ。別に辛くないと思うよ。ソースによってAQの強ささえ変えればエロゲーの
OPでも色々いける。b-adapt 2も完全にエロゲーのOPで作られたし。

アニメをエンコしてるのは日本だけじゃないしｗ
ttp://www.animereactor.dk/aegisub/uppcon-party.jpg

まぁ、そんな釣りにマジになってどうする…ってことで（ｒｙ

いずれにせよ、VAQやPsy-RDを使うことで、グレインが保持できる様になったのは、とても嬉しい。

次に出る東方の映像が今までよりもっと複雑だったなら、DSもさらなる改良をしてくれるのだろうか。

そもそもAvery LeeがVirtualDub作ったきっかけがうる星やつらだからなぁ

>>842
＞そして、D_S氏からまた新しいエンコーダーテスト用の動画だ
それをMediaInfo 0.7.18で見ると
＞Format profile : High 4:4:4 [email protected]
と出てYUV444なのか？と思いきや
＞Colorimetry : 4:2:0
と出て…。

Colorimetryって何？

間違えた
セーラームーンだった…

>>849
プロファイルの名前が: High 4:4:4 [email protected]
だけど、Colorimetryは実際のカラー空間。つまりYV12だ。
x264のロスレスでエンコされたものですから。

H.264のロスレスはHigh 4:4:4っていうプロファイル名なんですわ。
名前からもわかるとおりこいつはYUVやYCoCg（RGB）の4:4:4を収録することはできるけど
x264は4:2:0でエンコしてる

>>851
どうも。

てっきり非公式(という表現でいいのかな？)な
「444でエンコしてみた」動画なのかとｗｋｔｋしたのに…。

1920*1200の動画をエンコすると動画の下の方が緑色の帯状になって
おかしくなるんですけど、なんか回避方法あるんでしょうか？
リサイズしたりして1920*1200より解像度落とすと問題なくエンコされます。

環境は、Aviult＋x264拡張GUI（x264.1181.release02) です。

スレチです。x264の問題ではありません。こちらへどうぞ
ttp://pc11.2ch.net/test/read.cgi/avi/1246696904/

1920x1080のまちがいじゃないのか？

映像下部端が緑になるのはエンコード時ではなくて
再生時にデコーダとフィルタとレンダラの組み合わせが悪いせい
再生環境を見直せ

ゲームのキャプチャじゃね？
まっスレチなのは変わらんがｗ

x264itvfr.exeはもう更新されないのか

ソース修正するのがめんどいとか

crfを2pass VBRの1pass目に出来たらなぁ、とか思ったり。

crf 20とかにしても、ノイズが見え隠れするので、出力されたファイルの
平均ビットレートで2pass VBRしたら、ノイズが消えることが結構あったり。

logを見ると、crfは、directMVが、ほぼspatialのみで、2passにすると、
temporalを2〜30%ぐらい入れて、圧縮効率が上がってる模様。
本体に実装されなくても、MeGUI辺りに実装されないかなぁ。

いわゆる2pass版crfですね

バッチファイルでcrfでやるときに-p 1と--stats付けてやって、
エンコしたファイルのビットレート取得して変数に入れて、
-p 2 --stats -B %rate%ってやれば？

Losslessはぇぇ。。。Full HDでも20fpsとか出るもんなんだな
当たり前だけど容量的にほとんどエンコする意味が（ｒｙ

>>863
それってデコードとHDDの書き込みがボトルネックになってて、大幅にスピードダウンしてると思う

4:4:4のロスレスはBDの次の規格で対応だろうな。

基本的にHigh10以上のプロファイルはスタジオ向けだから
民生規格で採用されるかなあ？

4:2:0のままで、4k2kとかになりそう。

最低でも4:2:2だな

エンコ設定入れてたHDDぶっ壊しちゃったお
明日からどーやってエンコしていけばいいんだお・・・

>>869
バックアップも取ってない奴が悪い

と思って自分のPCを見たらSMARTから警告がきてるお・・・

RAID10、毎日にバックアップドライブにバックアップ、1週間毎に外部ドライブバックアップ取ってる俺に隙はなかった

PC4台にコピーしてる俺に隙はなかった

設定くらいの小さいサイズのファイルならエロ画像共々zipでうｐろだやP2Pネットワークにあげておけば安心じゃね

Gmailあたりにアカウント作ってそこにメールに添付でzip保管。最悪人に見られても
困らないけどなくすと困るのはそうしてる。

やっぱエンコやってる人達って全然エコじゃないよねw

MSが25GBのネットストレージを無料で提供してくれてるじゃん

他ブログの引用だけど、RGB4:4:4とYV4:2:0ではRGBの境界線での滲みが違うな。

RGB
http://blog.99ravens.net/yc/colorbar_rgb_prev.png

YV12
http://blog.99ravens.net/yc/colorbar_ok.png

前にクロマのサンプル動画を上げてくれた人いたけどあれは凄く分かりやすかったな。

2Dゲームとかキャプチャすると輪郭のにじみが顕著に見れる。

一般的にRGBコンポーネントのロスレスで拾えるのは
ゲームの映像しか無いからね

1184
New AQ algorithm option
Generates significantly better SSIM
Available as --aq-mode 2.

Auto VAQ取り込まれたのか

>Whether it generates visually better quality is still up for debate.

人間が見た場合の画質が良くなるかどうかはまだよく分からないが、SSIMは良くなるそうだ。

グレインとか消しちゃいそうだな

x264_VAQpow2.diff
http://stashbox.org/v/573732/x264_VAQpow2.diff

名前がいいなｗ

輝度も4:2:0でいいから、ロスレス低ビットレートコーデック出ないかな。
そういう大胆な発想が欲しい。

>>885
4:2:0って何の意味か分かってんの？
しかもロスレスなのに低ビットレートて・・・

>>886
意味が分からないなら、教えてくださいだろｗ

まじで意味が分からないんで教えてください

　＿＿＿
/　||￣￣||　∧＿∧
|.....||＿＿|| （ ＾ω＾ ）　　
|￣￣＼三⊂/￣￣￣/
|　　　　|　( ./　　　　 /

漫画単行本と同じでスレの寿命って一桁程度だな。
それから、夏休み最高だぜ

＞大胆な発想
すっげ、マジすっげ
ほんと、大胆だぜ

　　　　／￣　　￣＼
　　　/　　　　　　　　 ヽ
　　 /　/V V V V V V |　　
　　｜ ｜　／　　＼｜｜　　そういう大胆な発想が欲しい。
　 　| (｜ 　 ・　・ 　 ｜)|
　　 ￣　､ 　 ∀ 　 ﾉ￣
　　　　　 ー――

420って時点で劣化しているのにロスレス（=444）とはこれいかに。

>>885
輝度まで2x2で共有するってこと？
それやるくらいなら、そのままcrf 15あたりでエンコするほうがよっぽど情報量多く残って縮むんじゃないの？

普通ロスレスって言うとエンコしてもデコードすれば100%元の情報を維持してると思ってたんだが、
x264のロスレスってのは違うのか?

>>894
x264のロスレスは完全にロスレスだよ
ただし入力がYV12限定だから、YUV420以外のYUY2やRGBは入力前に劣化させなければならないけど

h264の規格上は4：4：4も定義されてんだよなー

x264_hrd_pulldown.14_interlace.diff
http://forum.doom9.org/showpost.php?p=1307319&postcount=2012

確か今の規格は、輝度が4:4:4のフルで色が4:2:0だったな。
確かに、輝度の情報を減らせばその分ビットレートは稼げるがそういうエンコを見たことがないので
なんともいえんな。

輝度4:2:2にしたいなら横方向1/2にしてSAR2:1
輝度4:2:0にしたいなら50%縮小しろ、ってことか

しかし余計色が減っちゃう、それと何のための解像度なのか

x264 crf24とXvid q=4.0が概ね同じ画質と紹介されてるけど後者のXvidの方が
いいぞ。　おまえの設定が糞だからと言われそうだけど、そうなのかな？

--crf 24.0 --level 4 --keyint 300 --min-keyint 30 --no-fast-pskip
--bframes 2 --b-adapt 2 --weightb --direct auto --deblock -1:-1
--subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--vbv-maxrate 17500 --me umh --threads auto --thread-input
--progress --no-dct-decimate --no-psnr --no-ssim --interlaced
--output "output" "input" --fullrange on --sar 1:1

実写はこんぐらいの設定が理想なんだけどとてつもなくエンコが遅い。
subme=5ぐらいに落としたりtrellisを2から1にするなどすれば速くなるん
だろうけどそしたら君たちに糞設定と馬鹿にされそうなんだよね。
なんかXvidで最高画質設定でエンコした方が気持ちいいや。 VHQ=4にしても
そんなに遅くならないしね。　x264はcrfの値を小さくするほど速度が落ちるし
ああめんどくせえよ。　そんなにH.264は画質がいいのか。
Xvidのq=4でいいじゃん。　サイズも小さいし破綻もほとんどない。

なんだこのウンコな設定は

やはりウンコ設定ですか？　x264は設定が難しいです。
DivXの264にも期待したのですが　これまた糞エンコーダーなので
敬遠しています。　ああ

>>900
そう思うならそれでいいじゃないの？
誰もあんたにx264使ってくださいなんて頼んでないし。

>>898
そう。YV12は色情報を4ピクセルが共有。 YUY2は横2ピクセルが共有。
因みに"輝度が4:4:4"というのは、おかしい。
適当にググって説明を探した。　885に反応した人は全員音読なｗ
ttp://vision.kuee.kyoto-u.ac.jp/~hiroaki/firewire/yuv.html

>>900
そんな餌で俺様が釣られ･･･クマーーーッ！
trellisは1でいいや。weightbは外す。no-dct-decimateはヤメレ。
directはcrfで速度ならspatial。　b-adaptもいらなくね？　で、bframesは3。
level 4でvbv-maxrate 17500はだめ。
･･･結論。デフォルト、presetを使う。　中間が欲しいときだけ、自分で弄る。

>>904
今、ググったレベルのド素人がおかしいとか頭大丈夫か？

>>905
マジレスすると、説明すると長くなるから説明してるサイトをひっぱってきてくれたんだろ

つーか実写だったらVAQ使うか、VAQ使わないならjvt使うかしたほうがいいだろ
>>900はxvidでエンコするとき、マトリクスをmpegにするとか、H.263でVAQ使うとかはしないのか？

ってよく考えたらVAQはデフォルトでは1.0で有効か

フレーム内のマッチング取って拡大処理するプラグイン作ったんだけど
240x120で一枚三分もかかる

>>905
煽る前に「輝度が4:2:0」という珍妙な単語の解説してみなよ。

まぁなんだかんだでxvidもいいんだけどね

885 名前：名無しさん＠編集中[sage] 投稿日：2009/07/20(月) 23:14:27 ID:iOgPe2eu
輝度も4:2:0でいいから、ロスレス低ビットレートコーデック出ないかな。
そういう大胆な発想が欲しい。

887 名前：名無しさん＠編集中[sage] 投稿日：2009/07/21(火) 00:36:49 ID:mFWc2IjR
>>886
意味が分からないなら、教えてくださいだろｗ

898 名前：名無しさん＠編集中[sage] 投稿日：2009/07/22(水) 09:58:17 ID:9mOKsPdt
確か今の規格は、輝度が4:4:4のフルで色が4:2:0だったな。
確かに、輝度の情報を減らせばその分ビットレートは稼げるがそういうエンコを見たことがないので
なんともいえんな。

905 名前：名無しさん＠編集中[sage] 投稿日：2009/07/22(水) 11:01:30 ID:9mOKsPdt
>>904
今、ググったレベルのド素人がおかしいとか頭大丈夫か？

よく解らんが、昔から実写などの動画はxvidの方が気持ちいい感じの絵になってる。
x264はアニメ向きなんじゃないか?

x264はどんなにVAQで細部浮き出しても暗部はどんよりして汚いよね
そういう点ではサラサラとして爽快なXvidのほうがいい
大面積ではモスキートが目立つのでアニメには向かないが。

まあ、結局ビットレートを思いっきり上げていくと俺の安物液晶モニターと曇った瞳には差が解らなく
なってくるのが現実なんだがw

アホばっかだ・・・orz

http://www.mediafire.com/?imn2jzozjni
http://www.mediafire.com/?etzdmyinrjw

x264と比べると、Xvidでは厳しいな。

>>904
>>no-dct-decimateはヤメレ。
とあるけど何で？つけてると不味いの？

画質気にするならdct使えって意見じゃね

x264はアニメ向きだから実車は辛い

デブロックとかやってるからノッペリしちゃう

細部を削るからな

滅茶苦茶ケチって低ビットレートの時の話？
ttp://www.marumo.ne.jp/db2007_6.htm#26

普通は付けた方が画質上じゃないの？

dct-decimateはdctを使う使わないじゃなくdct+量子化後の省略処理のことだから
residualを符号化ビットコストを考えて極小のresidualは無視する処理
つまり適用された場合はdirect状態になる
no-dct-decimateは無視しない素直な処理

weightbはアニメなら付けても良くね？

weightbは今デフォで有効でしょ

>>921
個人的には、そこそこのRD性能向上があると思う。　一応flat時は全否定ではないし。
AQに似た感じで、マジックではないけれど、無難にちょっと画質を引き上げてくれてる感じ･･･かな？
ちょっとスレ一石投じて、効果を確かめて貰いたかったんだけど、言い切る程ではなかったと思う。　スマン。
ttp://www.mediafire.com/download.php?zyjmmzu0yxx (dct-decimate on/off 17.32Mb)

>>923
逆で、アニメでは危険じゃないかと言われてたはず。@doom9
DS氏が、「通常問題は起こさないし、フェード時に有用」と言ったからアニメでも主流になった。
ソースが実写だということを忘れてましたorz
デフォルトということは、アニメでも十分な費用対効果があるのかもしれません。

weightbってﾃﾞﾌｫで有効になってたのか、知らんかったわ

デフォからちょこちょこ設定いじって実写でほぼソース画質にできたことあるけど
なにがどう作用してそうなったかいまいちわからんのよね

よく分からんでオプション弄ってるなら初心者スレでどうぞ

参考までに上級者の設定をご教授願います

--preset slower

--tune touhou

--preset ﾌﾟﾗｾﾎﾞ

つ --no-asm

結局偉そうな904も907より900のがましだったって事かね

はいはいXviD君はいい加減面白くないから
別に適材適所でいいだろ。好みや環境の問題だし
巣から出てきて荒らすなよ

プラセボの意味が分からんがアレはslowerより画質が良くなる（かもよ）って事なのかね
ってこんなのヘルプ見ろよって事なんですが。

プラセボで身長が伸びました

>>936
画質は良くなるが、時間がかかり過ぎるので
そこまでする価値無いかなという感じ

つーか見た目に違いは判らないんだけど、エンコした本人は
「これだけ時間がかかったんだから、画質は向上してるに違いない」と思い込んで、
実際（本人にだけは）よく見える（かもしれない）ってことだろ

文字通りプラセボレベルの改善だからな。無駄に時間かけても対数みたいな比率でしかよくならんだろう

x264-r1179-threaded-slicetype-v16-fix.diff
これって　どんな役割があるんだ？

そういうのは初心者スレで聞かないと上級者さんに怒られますよ

>>941
マルチスライス
BD等には必要だが、通常は圧縮率が低くなるだけで、不要な機能

BDでも必須ではないよね？
あとはffdshowでマルチスレッドデコードができようになる、くらいかなｗ

>>944
1920x1080だと必須だと聞いた。
実際には、仕様から外れたシングルスライスだとしても、再生できるプレイヤーは多い様だけど。

　　　　　　　　　　　　　　　｀ﾞ''‐､_＼　| / ／
　　　　　　　　　　　　　　──‐‐‐‐　。 ←>> 943 のDQNめっ！
　　　　　　　　　 　　　　　　　　　／/ | ＼
　　　　　　　　　,　￣｀ヽ　 　 ／　/　 |　　＼
　　　　　　 　　 l　　　lllﾙゝ　 　 /.;∴.|
　＿＿_　　　　 ﾙﾘlljﾚﾘﾉ　　　　,：∵';
（　　　　二==と,ζ　　 ）
　 ￣￣　　　 （くんﾍ_ゝ
　　　　　　　　　 `（_ﾉ

>>946 が言ってる通り、BDには必要ない。
ただのマルチスレ化されたスライスタイプを決めるコード。実際に言うと、
--b-adapt 2が速くなるっつーこと。

マルチスライスはBDに必要だったはずだけど
そのパッチの内容はマルチスライス対応ではなく>>947ということ

一応、業務用のAVCコーディックでは4:4:4規格も予定があるんだな。

http://av.watch.impress.co.jp/img/avw/docs/153/779/ez9068.jpg

と思ったが、この話すると知ったかぶりの厨が沸いてくるから>>949はなしの方向で。

コーディック

もしかして: コーデック

co-dick = partner penis

便秘の時の飲む薬だろ

なに！コーティカルテだと！

カメラとかフィルムの会社か

細かいこたあ木にすんな

ワカチ(ry

いつのまにか-8じゃなくて--8x8dctって書かないとエンコ始まらなくなってるな

便秘にはコーｒｙ

いつのまにかデフォ値が変わったことも知らないバカだらけに

subme10 ww

久しぶりにバージョンアップしたら色々変わっててびっくりした



良く分からないから元に戻した

戻すなｗ

♪サブミー テンダー

subme 10についてエロい人解説お願いします

subme 10でモザイク消えるんだろ

1185

x264itvfr.exeの更新が止まって一ヶ月
掲示板も閉鎖されたっぽいし
このまま終了か

>>969
562 名前： ぽむ ◆0POoRnBOR. [sage] 投稿日： 2009/07/26(日) 17:31:36 ID:tB+Qtpqp
鯖の再インストールちう…

>>969
マジで。
afs版が合わなくてitvfr版でずっと使ってたのでショックだ。
ぽむ氏復活してくれー。

>>970
な、なんだそうなのか。
焦ってしまった。

x264-r1189

r1189>>--subme 10 NEW!!

trellisが2でAQが0より大きくないと使えないのか…

seraphyビルドﾏﾀﾞｰ

AutoVAQが統合されたから修正に時間がかかってるのかな？
subme 10は楽しみだな

subme 10 (QPRD) 効果あるね、圧縮率がだいぶ上がる。
エンコ時間も効果抜群！　５割増し

seraphyー！早く来てくれー！

AutoVAQが良かったからoreAQと-VAQ版とはさよならだな

AutoVAQは実写には良いけど、アニメだと+方向だから駄目だったな
-方向も出来ればいいのに

輪郭の劣化が気になる様なソースには、--aq-mode 0 --cqm "flat" としておけば、高周波は十分に残る。

ヒント：ニコニコ

ちょっとまて5割増しってなんだ！増えすぎじゃないか時間ｗ

みんなsubmeはいくつにしてるの？

ボクはsubme 9

麿もsubme 9でおじゃる

サイズ重視ならsubme9だけど、んな100M200M増えたっていいよって場合はどうでもいいかも。

SDのエンコはsubme 9でHDはsubme 7あたりか

>>978
容量は減るけど細部が劣化するから微妙な感じ。
薄い模様とか結構消えちゃうし輪郭もいまいちになるかな。
クオリティならまだsubme 9の方がいいと感じた。
あとエンコード時間はそんなに9と変わる気はしないね。
まあ設定によるのかな。

それよりもdeadzoneとtrelisの共存エンコが早く実用化されてホスィ

>>990
意味分かってる？

テンプレ変更は>>4の--progressを外すだけ？

r1190

Fix two bugs in QPRD
fprofile settings now actually fprofile QPRD.
Don't use i_mbrd before initializing it.

もうしばらく様子見た方がいいかな

>>992
間違いとしてはそれぐらいかなぁ…
あと、MeGUIはMencoderじゃなくて、MPEG-4 Encoder GUIだったような…
今Doom9の本家スレに届かないので、スタートメニューの「Modern Media Encoder」
のところしか確認できない。
あと、配達されてないバイナリのサイトのURLはやめて、その代わりに
ttp://forum.doom9.org/showthread.php?t=130364
の最新パッチのスレへリンクした方がいいかと（非公式ビルドを発表する
スレになってますから）。
あと、QPの話はやめて、CRFに進みたい。一応QPは実験用にしか使用されないように
って開発してる人から言われてるし。ここで今のところQPの実験をする人あまり
いないと思うし、テンプレから消しても問題ないかと。

思ってることはこれぐらいだな。

http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/
はもう外すか
itvfrとか入れる？

x264 rev23
http://pc11.2ch.net/test/read.cgi/avi/1248750814/

x264_hrd_pulldown.15_interlace.diff
http://forum.doom9.org/showpost.php?p=1309191&postcount=2040

　　　 　 ＿ ／ ＼　＿
　　　　/ ／　　　 ｛┳ ｝
　　　　>{、　　　　 ,>-<
　　 ／/ -＼＿_／ -ヽ ＼
.　 ｛　 |⊂⊃　i　 ⊂⊃|　 ｝
　　 ＼ヽ　「￣￣ ﾌ　 /　/
　　r─＼　ゝ ─ ' 　厶二⊃
　　 ￣｀| ￣￣￣￣　 ｀ーｧ
　　　 　 ＼　　　　　　　／
　　　　　　 >、＿＿_ イ
　　　　　　 し′　　し′

＿＿＿＿＿＿＿＿＿＿
　　　　＜○√
　　　　　‖　
　　　　 くく
しまった！俺が999getだ！
オレが喜んでるうちに1000を取れ！
早く！早く！オレに構わず取れ！

1000だったらいまさら夏のボーナスが出る

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