x264 rev20

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 rev19
http://pc11.2ch.net/test/read.cgi/avi/1228636479/

再生方法、規格、インタレ規格、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の話題は
Avisynthを絶讃ιょぅょ Part25
http://pc11.2ch.net/test/read.cgi/avi/1206362521/

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

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

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の倍数のトップフィールドファーストで。

その他パラメータの勉強は
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''ﾊ∨

>>1が乙でなんたらかんたら

>>1 乙

　　　　　　俺が>>1乙を言うクマー！
　　　　　　　　　　　　　　　　r -､,, -　､　
　　　　　　　　　　　 __ 　　　ヽ／　　　　ヽ__　　　
俺が先だクマー！ ,"- `ヽ,　/　●　　　　 l　）　 自分だけずるいクマー
　　　　　　　　　／　　●　＼__　(●　●　i"　　
　　　　 　　　__/　　　●） 　 　 ￣ ）"__　"`;
　　　　　　.（_i　 ● 　 　' __, '" ￣`'（__＿／.i⌒i　　
　　　　　　　　丶_ ,i⌒i,,_（_/　　　　● i￣￣ ）_|__ 　
　　　　　　__, '"　　￣　ヽ!　●　●)　 ミ~￣_● ヽ）
　　　　 　（_/　　　　　● i　　　 ∪　　/ ⊂{●　 |　そうはいかんクマー 　
　　　　　　 l　●( _●)　（ ￣）-　 　　/　　　-' 　i　
　　　　　／ヽ､ 　 |∪l　　 T　　　 　　i 　 　 ● '"）

x264gui.auo使いですが、引き続きこのスレにいますね

（　‘д‘）y-~~＜H264に比べたらX264なんてゴミやな　綺麗さが10倍違うわ

たしかにただのプログラムのエンコーダー見たって綺麗とは思わないな

H.264の規格書（ｒｙ

gui.auo、CLI併用者だけどあっちがvfwを切り離さない限り
ニコ厨くさいのとかコンテナAVIに入れるには(ryとか堪忍
なので自分も引き続きこのスレにいますわ

H.264のAVIを馬鹿にしてはいかん
NVIDIA公式でも配布されてる

ttp://www.nvidia.co.jp/object/games_nurien_jp.html

>>14
皆がそれの様に、Bフレームを使っていないのなら、VfWでも大きな問題は無いだろうけどね。

H.264 in AVIを馬鹿にしてるんじゃなく、その使用者の多くが無能、若しくは質問をしてくる奴の無能さを馬鹿にしてるんじゃね

CLIのユーザーには関係がない、GUI版特有の問題は向こうのスレでやってほしい。

x264gui.auoでCLI使用の場合はここでいいのか？

オプションとかならGUIでもここでいいんじゃね？
てかGUI使ってますって言わないとわからないような場合は。

エラーが出て落ちるんですとかならあっちだろう。

>>14
だっさーｗ
もう金輪際ゲフォ買わねー

統合グラフィック厨乙です

1099が駄目と前スレで書き込みがあったがどうなの？

駄目なん？　って聞かれたから、駄目ですって言ってあげただけでしょ

さぁ試すべr1099
個人的にはr1086がサイズと画質が安定してる気がするんだが
こう更新が早いと十分なテストができないな。。。

http://app.blog.livedoor.jp/livenowon/tb.cgi/688669
1086がいいってさ

もっと高速化してくれ

何となく数字の感じが良いのは分かった

>>25
宣伝か？としか言いようが無いくらいどうでもいい文だしてくるな・・・
まあおれも1086だな、それ以降は膨らむし、aq-sensitivityで落ちるからなあ・・・

>>28
しかし確かに1086が良いのは事実なんだよな

1086がイイって言ってる人はSeraphyさんの使ってるの？たしかにSeraphyさんのは
1090以降なんか変だけどそれ以外のビルダーのは1086〜1099まで画質もサイズも
大差ないよ。

( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼
1096で大量にエンコしちゃったしこのまま最新版使うとするか

1086 エンコード"いまやろ"

1086が正常で1090がおかしいって何でだろう？
ちょっと実験して本当かどうか調べてみるか。

>>33
今まさに1096で大量エンコ中だから助かるわ。
ついでに、折角なら1099でお願いしたい。

未だr999使ってるわ

ひょっとしてseraphy氏のがおかしいってICC版だったりする？
ICC版は前から出力結果違ってたけど。

GCC版でもおかしいよ。

1090以降駄目だったのか…
なんか変だな〜、とは思っていたのだが

Seraphy版使ってないから関係ねー

Phenomな俺はもうseraphy版は使えねえしなぁ

とりあえず俺ビルドとseraphyビルドのOreAQ版x264guiを比較したんだが結構違った。AQは同じだったので省略。
俺ビルド
slice I:54 Avg QP:17.74 size: 44072 PSNR Mean Y:49.17 U:51.33 V:51.12 Avg:49.73 Global:49.66
slice P:1614 Avg QP:19.81 size: 13724 PSNR Mean Y:46.96 U:49.45 V:49.16 Avg:47.59 Global:47.37
slice B:2096 Avg QP:20.72 size: 2879 PSNR Mean Y:46.79 U:49.16 V:48.91 Avg:47.40 Global:47.15
consecutive B-frames: 11.9% 32.0% 27.3% 18.0% 5.7% 3.7% 1.3%
mb I I16..4: 16.2% 50.0% 33.8%
mb P I16..4: 3.1% 4.7% 2.0% P16..4: 47.0% 10.6% 12.1% 0.0% 0.0% skip:20.6%
mb B I16..4: 0.4% 0.5% 0.2% B16..8: 21.5% 2.0% 2.2% direct: 2.7% skip:70.5% L0:38.3% L1:50.3% BI:11.4%
8x8 transform intra:48.1% inter:58.3%
direct mvs spatial:96.9% temporal:3.1%
ref P L0 71.0% 11.5% 8.2% 3.4% 3.0% 2.8%
ref B L0 76.1% 11.4% 6.2% 4.0% 2.2%
ref B L1 93.4% 6.6%
SSIM Mean Y:0.9928001
PSNR Mean Y:46.900 U:49.316 V:49.047 Avg:47.513 Global:47.274 kb/s:1557.52

sepraphyビルド
slice I:52 Avg QP:18.53 size: 40634 PSNR Mean Y:48.71 U:50.96 V:50.75 Avg:49.29 Global:49.22
slice P:1341 Avg QP:20.48 size: 15742 PSNR Mean Y:46.64 U:49.19 V:48.88 Avg:47.28 Global:47.07
slice B:2371 Avg QP:21.51 size: 3078 PSNR Mean Y:46.41 U:48.83 V:48.56 Avg:47.02 Global:46.83
consecutive B-frames: 7.3% 24.4% 24.3% 15.2% 8.1% 6.8% 14.0%
mb I I16..4: 17.9% 49.8% 32.3%
mb P I16..4: 7.2% 5.8% 2.5% P16..4: 62.7% 14.4% 5.9% 0.0% 0.0% skip: 1.5%
mb B I16..4: 0.3% 0.3% 0.2% B16..8: 14.1% 2.4% 1.6% direct: 3.9% skip:77.2% L0:43.4% L1:39.2% BI:17.4%
8x8 transform intra:40.2% inter:61.9%
direct mvs spatial:99.9% temporal:0.1%
ref P L0 55.0% 15.3% 12.8% 5.9% 5.6% 5.4%
ref B L0 66.3% 14.8% 9.2% 6.1% 3.6%
ref B L1 91.5% 8.5%
SSIM Mean Y:0.9924908
PSNR Mean Y:46.522 U:48.985 V:48.706 Avg:47.145 Global:46.940 kb/s:1555.28

seraphy氏はもうやる気なくしてる感じ？

1063使ってます

結構エンコ待ち溜まってるのでとりあえず1086に上げてみます

結果報告
一言でいうとseraphyビルドはおかしい。
コンパイラの違いとか最適化が影響するかもしれないし俺ビルドの方がおかしい可能性も考えてx264.nlも加えて比較した。
俺ビルドはGCC 4.3.2でYorkfield向け最適化、x264.nlはGCC 3.4.6、seraphyビルドはGCC 4.2.1。
結果は
パッチ無し通常版は俺ビルド＝x264.nlビルド≠seraphyビルド
OreAQ版も俺ビルド≠seraphyビルド
詳しいログは↓
ttp://www1.axfc.net/uploader/File/so/17990.zip

Web Diff使うとどこが違うのか一目瞭然で便利
ttp://labs.ceek.jp/diff/

おにーさん版ビルドOreAQステキですね

俺ビルドください。

俺ビルド
ttp://www1.axfc.net/uploader/File/so/17992.zip

GUIはめんどくさいので…今日は寝る

>>48
VFR_maniac氏ビルドの方が1.3〜1.4倍速くコンパクトになる結果に・・・
i7(965Ex)オートOC*3.442Ghz

920でも3.8GHｚ常用できるのに965にしてはOC率低いな

検証ありり
refが妙に高いなー　とは思ってたんだが…

>>45
そして一応親切心からsar32:27でいいのかと突っ込んでみる

>>50
有り金はたいて50万で買ったから強制OCはしてない。
今度のメニーコアまでもたせなきゃ

どんだけぼられてるんだよ

安い920か940で気兼ねなくOCするのとどちらがいいか悩みどころだな
俺も920と965両方とも3.8GHｚまでしか上げてないしなぁ
CPU単体で見れば処理速度は変わらないし

>>54
HDを買いすぎたんだお
1.5TBの衝動買い

ご愁傷様です

どんだけぼられてるんだよ

>>56
10台くらい買ったのか

>>49
>>48は最適化外してるからかな。
Core2指定
ttp://www1.axfc.net/uploader/File/so/17993.zip
コンパクトになるって出力違うってこと？リビジョンが違うせいじゃなかろうか。

>>52
40:33？どっちがいいのかいまいちわからん。
ソースはTSでそれは16:9のアス比だからエンコ後も16:9になるように指定したんだけど。
40:33だとソースよりも横長になるし。それともソースのTSもそのままだとアス比おかしいの？

私がHD->SDをやるなら、704x480にリサイズして--sar 40:33にするけど、別にそれでもおかしくない。

BT.709->BT.601もやらないと、再生した時の色がおかしくなるけど。

確かにseraphy氏版はr1086以降がおかしい
r1086までだと25分動画で350MB〜400MBぐらいに収まってたのに、
r1090,r1093,r1096だと450MB〜550MBぐらいで約100MBぐらい差が出てる
まだ同じソースで試してないけど暫く様子見した方がよさげ
書く言う自分は10本以上エンコしてしまったわけだけど、
画質の差はなさそうだからエンコしてしまった分はそのままにして今はr1086使ってる

何となく数字の感じが良いからな r1086なんだよ

他人のバイナリで悩むのは不毛だから、自分でビルドできるなら、黙ってそれを使った方が良いわな。

seraphy氏の掲示板で回答きてた
これで直るかなあ

俺patch版のほう使ってるけど膨らむなんて感じないけどな。
だからいちいち同じ動画でテストとかしてないし感覚の問題だけど。

seraphy氏ビルドの1090以降2passで落ちるのって俺だけ？

VFR氏とseraphy氏のr1096を同ソース同オプションで比べてみたけど、若干seraphy氏の方が膨らんで、若干VFR氏の方がSSIMがよかった
aq関係は変化無し
100Mも膨らむってのはどうなんだろ・・・

Seraphy氏が1099r2出してくれたよ
どうもコンパイラのバグだったようで、直ったっぽい

なんだかんだと修正してくれるseraphy乙であります

いまだにr1057使ってる俺だけどseraphyさんいつもありがとう
じゃあそろそろ最新版に移行させていただこうかしら

いまだにr683つかってるけどSeraphy氏乙であります

この板って他の板より一昔前の2ちゃんねるの表現が多いな
電車男に具現化されたような典型的な

専門板ってそんなもんだよ

というか専門板が"2ch"である必要がないよな

そりゃあニュー速やらVIPやらと一緒くたにされちゃあかなわんな。
話題が決まってるんだから2chの文化が入る込む余地はない。

　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　´∀｀）＜　
　（　　　　） 　＼＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

Seraphy氏の1099r2で治ったー！良かった良かった。

本当に直ったのか？
直ったのなら移行したいところだが今1086試してみてちょっとだけエンコスピードが増えてしまった。
うーん1072に戻したほうが良いんだろうか？

分からないならきにするな

ハハハ
r1100… 10l: fix compilation with GCC 4.3+

これで直ったのかな？
seraphy氏は1090からGCC 4.2.1-sjljを使ってたそうな
GCC 4.3.2-tdm2　で正常だったみたいだけど、どういうことだろ

どっちみち1099r2はnlと同じGCC-3.4.6だから問題なさそうだけどね

以前、色のにじみとかバンディングが気になるって人は
ffdshowのRGB変換がアップデートしたみたいだから使ってみれば？

高品質クロマ処理や10bit精度の入力/出力は使えそう。
ffdshow使っている人はいるのかな？

2646 01.02.2009

1.New color space converters
Supported color spaces
input: progressive YV12, progressive NV12, YV16, YUY2
output: RGB32,RGB24
High quality chroma upscaling: 75:25 averaging vertically and horizontally
Support for color primary parameters, such as ITU-R BT.601/709, input and output levels
10bit or more calculations
SSE2 required (other converters are used on old computers)
faster than former high quality conversion on 45nm Core2 (YV12->RGB). Depends on the speed of the execution of SSE2 instructions.
Make sure "High quality YV12 to RGB conversion" checked

2.RGB conversion: New options
Output levels ("Computer monitor" or "TV / Projector")
YCbCr specification "Auto" (use H.264's VUI or width >= 1024: BT 709, width < 1024: BT 601)

3.H.264 use VUI information about color space
video_full_range_flag: Select "Auto" at Input levels/RGB conversion (This is not default)
matrix_coefficients: Select "Auto" at YCbCr specification/RGB conversion (This is new default)

4.Fixed handling of YV16
YV16 = FF_CSP_422P|FF_CSP_FLAGS_YUV_ADJ (in TvideoCodecUncompressed.cpp)

http://www.xvidvideo.ru/content/view/9/17/

RGB出力とかありえん

テレビをPCモニタとして使う場合とかならありえるし
なにかしらの問題の対策のためffdshow入れてる人も居る
まぁ極端な例だけどねｗ

どこでRGB変換入れるかの違いだろ。
ゲフォならソフトウェアで変換したほうが1000倍くらいいいとか聞いた。
てかffdshowのアップサンプリングは前から性能は悪くないぞ

どのみちRGBにしなければモニタに表示できないのだから、
ビデオカード側で行うかソフトで処理してRGBで渡すかの違いだけだからな。

ラデならビデオカード側で、ゲフォならffdshowとかソフト側で色空間変換(RGBへ)というのが無難だったと思う。

seraphy氏のはPhenomで動くようになったの？

1101

>>88
無理
対応するつもりないと言ってるし

で結局なんでだめなの？

seraphy氏はPhenomの環境が無いからだろ？

でも普通にコンパイルしてるだけなら普通動くと思うんだけど。

>>93
Phenomでも別に普通に動くだろ
シングルスレッドで動かせばな

--no-asm でも駄目なの？

http://forum.doom9.org/showpost.php?p=1243003&postcount=1571

-march=pentium2でやっている人のバイナリなら、どのCPUでも問題なく動くだろう。

Phenom買う予定だから動かないのは困る

自分でビルドすれば問題なしなんだろ？
Phenom2買うつもりだから気になる。しかしAMDめ延期って・・・orz

何買おうが知ったこっちゃないが
エンコするような奴がPhenom買うとか金の無駄過ぎる

エンコだけじゃないからPhenomなんだろ

なにを買えば無駄じゃないんだああああ

Nehalem-EX

BD初回限定BOX

レグザ

東芝のテレビは糞だろｗ
PCマニアだったらSONY一拓

TS再生したいからじゃないの？
家電のことはよく知らないけど。

東芝でもSONYでもどんどん買ってとにかく消費しろ。

>>105
PCマニアには韓国パネルの東芝やSONYは評価されていない。

やるならハードウェアかAV板言行ってやれよ

AdultVideo

TSの汚さに落胆した後なら、どこのメーカーだろうが大抵のHDTV、BDレコに不満なんか無い

暗い部分はAQで調整して階層割れ防げるけど、赤黒い（赤暗い）部分が何やっても階層割れ起こしてしまうんだが
ここの人たちはそういう部分どのように処理してるんすかね？

どういうところ？画像で示してもらえるとわかるんだが

バンディングのこと？あれはどうしようもない。再生側が補完してくれればひどくはならないはずだが

PCマニア(笑)

>>88
> seraphy氏のはPhenomで動くようになったの？

Aviutlの出力プラグイン版@GCCをPhenomII 940でエンコしてる

ソースの時点で階調割れしてて、フィルター処理でさらに悪化してたりしてな

>>113
アップローダーあまり使ったことがないので適当なとこですみません
http://uproda.2ch-library.com/src/lib101188.png

静止画ではわかりにくいですが赤暗いとはこのような所を指していました
NRは時間軸に軽くかけています、ソースは地デジですがもう手元にソースがないので圧縮後のものをキャプしました

このほかの暗部はGradFunkMirrorなどを弱くかけAQやdeadzone、あとはfgoなどでそれを拾うようにして対処していたのですが
この部分だけはどうしてもうまくいきませんでした

GradFun2DBmod
http://forum.doom9.org/showthread.php?t=144537

GradFunkMirrorの代わりにこれを使って、グレインを保持できる設定にするとか。

バンディングノイズはｆｆdshowのフィルタで
バンディングノイズ除去があるからこれで完璧に消える。

ffdshowのエンコード時にもフィルタ使えるからx264でも連携してくれないかな。。。

あと、AviUtlのプラグインでバンディング低減MTプラグインというのもあるから
これでもいいかも。

使ったことないけど。

ef2の第1話に見える

>>120
バンディングノイズ除去っておかしくないか？
バンディング除去で行う処理（ディザリング）は、いわばノイズ付加処理だろ

>>120
あとエンコ時にディザ付加しても量子化でつぶされるからほとんど効果ないよ。
つーかffdshowのDebandってまさにGrandFunのことだし。

あらためて読み直すと>>123もおかしいな
バンディングは低減はできても除去はできない
訂正しますよ

x264で実写をエンコするときはcrf=24〜26で高画質と紹介されてるのですが
汚いとしか思えません。　crf=22ぐらいで何とか許容できる感じです。
素人の私でも気づくぐらいなのでエンコ厨の方なら一笑に付すところでしょう。
SDサイズの動画だと1300kから1500kbpsは欲しいところです。　高画質を狙う
のならH.264でも2000kは必要と思います。　ソースにもよりますが・・・

画質を高望みすると高ビットレートにならざるを得ません。　低ビットレートでは
x264はXvidなどに圧勝してると思いましたが　640*480サイズで1500〜2000kbps
ぐらいの割り振りならXvidとそれほど大差がないように思いました。
subme7とかの設定で低速でエンコしても時間がかかるばかりです。
結局 Xvidに戻ることにしました　quantizer=3 VHQ=4 VAQ適用で画質、サイズ
共に妥協できる範囲に落ち着きました。　

はい、さようなら

だめだ、思惑通りに笑ってしまった

1093以降エラーが出てエンコ出来なかったけどr2で直って良かった

>>118
事前のディザかけと--fullrangeと--colormatrixを
うまく使えばどうにかなるんじゃ？
FlashPlayerとffdshow最新版は対応してるみたいだし。
http://x264.tobinaka.com/index.php?--fullrange
http://x264.tobinaka.com/index.php?--colormatrix

でた。tobinaka☆

(ﾉ∀`) ｱﾁｬｰ

tobinakaさんは神だと思っている。
（略）
あの時は本当にびっくりした。

過剰反応してバカじゃないの

>>126
build 66以降はcrfのデフォ値が22になったんじゃなかったっけ?

Xvidは実写だと絵が眠くなりすぎるから、個人的にはもう戻ることはないなぁ。

crf 22で実写だと容量的に変換する意味がなくなる(MPEG-2のままでいいやということに)
x264は設定を煮詰めないと

TSならそうかもしれないけど、DVDやBDならかなり縮むよ。
別にデフォで使ってるわけでもないけど。

118です
思った以上に沢山のアドバイスをいただけて感謝しております
>>119と>>130を試してみてみようとおもいます
ありがとうございました。

http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/
http://x264.tobinaka.com/

tobinakaのwiki相変わらずコピペだらけで何の役にもたたねえｗ

fullrangeとかやめとけ
規格外なうえにソース処理や格納方法を間違えると大変なことになる

いちいちtobinakaに過剰反応してるやつって嫉妬に狂った腐女子みたい

>>124
やってみて言ったほうがいいぞ。

>>125
ffdshowの日本語がバンディング除去になっているんだ。
後は分かるな。

単発の煽りに過剰反応してるやつってtobinakaみたい

>>126
同じぐらいの時間でエンコする場合はXvidが手っ取り早くていいね。
ディジタル放送なんかのSNの良いソースなどでは軽く3DNRするだけでいいから短時間でエンコ出来てしまう。
ゴッホ絵になりやすいH.264系よりすっきりした描写だから俺も使ってるよ。

使いこなせないならXvidでいいと思うよ。画質下がるし。
使いこなせないなら

オプションいじるだけでプロ気取り（笑）

定期的にXvid厨が沸くな

スルーすればいいものをお前みたいに反応する奴がいるからな

でも普通にオプションいじれるだけで、
エンコ神（笑）ぐらいにはなれるだろ。

seraphy.fam.cxに繋がらない

じゃあオナニーでもして暇つぶすか

sarで指定したアスペクト比レートを
エンコ後修正って出来ます？

>>154
mp4boxで可能

>>155
即レスthx！
調べてみますありがとう〜

-PAR 1=?:?

>>146
ディジタル(笑)
お前PT1荒らしてた馬鹿な奴かｗ

ディジタルって普通に言わね?
ディズニーとデズニーの違いくらいのことと思うけど

技術文書で書くことはあるけど
他者とコミュニケーションする場では使わんな
馬鹿に見えるから

>>159
電気電子系の学部、研究科出に
デジタルじゃない！ディジタルだ！
ってよく注意されるわ。
まぁ、確かにディジタルが正しそうだ。

ディジタル
古めの書体で右から書くと雰囲気でそう。

ディヅィトゥ！

>>162
ルタヂィデ

最早英語と言うよりカタカナ語なんだからデジタルでいいと思うけど
デスクトップをディスクトップと言うのはなんとかして欲しいと思うが
お前の机は回転するのかと小一時間（ｒｙ

diは昔の人は「ディ」が発音できなかったから「デ」になっちゃっただけで、
deを「ディ」と発音する人は根本的に頭が悪いと思う。

ウチのじっちゃんは

ディスク -> ですく
メロディー -> めろでー

という発声しかできない

最近はMSも表記変えてきたが
メモリ、モニタ、プロセッサなど語尾の
「ー」を省略するのも独特だよな

独特っつーか英単語をカタカナ表記にした時点で正しいものなんてないんだよ
つか、スレ違いだから失せろ

>>165
ﾜﾛﾀ
めちゃくちゃわかるｗ

>>166
debugみたいに表記上は「de」でも発音記号では「di:」になる
ケースもあるから、ひとくくりには判断できないけどね。

ま、カタカナ英語で定着してることもなく、ネイティブの発音にも
合ってないような言い方はやめて欲しいということだな。

いいじゃんネイテブなんてケアーしないで。

安定してきたからオプションの話題無いのかな。

別に表記なんて分かればいいと思うけどなあ。どうせそのまま発音しても通じないし。

>>154
>>155
mp4boxじゃsarは変更できないんじゃないかな〜
par優先のplayerならいいけど sarしか見ないplayerなら効果ないかも

h264infoだっけ何かあったな

>>173
一度demuxして、h264_parseで調べたら分かるけど、aspect_ratio_idcが変更されるよ。

そもそもsarとparの区別無いんでしょ？

多分>>173はmp4boxで設定するとコンテナでしか反映されないと思ってるんだと思う。
つか俺もつい最近までそう思ってたけど実験したらどうやら直接ストリームヘッダを書き換えるみたいね。
あとTSからDemuxしたMPEG2-AACもmp4boxでMuxしてDemuxするとMPEG4に書き換わる

deskはOEだとdeskeで、これはdishやdiskの意味もあった語

カメラをキャメラっていうカマクラ頭のおばはんいるよね。

rev.1000出た時予定されてたｲﾝﾀﾚ対応の
強化ってどうなったんだろう。
予定では10〜15％の符号化効率アップで
wktkしてたんだが。

>>Speaking of MBAFF, i remember seeing a posting of yours saying "MBAFF, coming to a x264 revision near you".
>>Can you update us on the progress of this addition ?

>Delayed indefinitely due to the discovery that the original patch, supposedly working but written by retarded monkeys, was in fact the latter, but not the former.

http://forum.doom9.org/showpost.php?p=1241950&postcount=4

MainConceptのエンコーダは、x264の様に全部のMBをインターレースとして扱うのではなく、
ちゃんとmacroblock-adaptiveで処理をするそうだが。

厳密なMBAFFを行うとインタレMB判定に時間がかかるからやんないんだよ。
だから全部インタレ扱いにするならPAFFを実装してほしいってのが大部分の希望

x264は旧世代コーデック以上に効率が悪いから15%どころかもっと改善される余地がある

CABACとかはまだまだ最適化で符号化効率あがりそう。
デブロックも検出精度向上とかで。

>>184

>>185
反論どうぞ。

速度も圧縮効率も一年前と比べると随分改善されてる気がするが
まだ改善の余地があるんだな
どんどん昔エンコしたファイルとの格差が広がる

>>184

自動応答？

こういうオープンソースプロジェクトって多数の人がコード書くから
数年更新続けてるとごみとかたくさんたまる印象がある。あくまで俺の印象だけど。

>>184
CABACの処理弄ったらデコードできなくなりますが。

とマジレスしてみる

>>191
無知は邪魔だから消えれば？

最近ようやく地アナキャプから地デジTSに変えたんだけど、そのせいでエンコがかなり重くなったなぁ
前は大して気にしなかったが、処理速度はほんの少しでも向上してくれたらありがたいわ

私は地アナの時の方が処理が大変だったなぁ。

>>192
自己紹介乙

今年一年で言うとサイズ・画質比の改善はAQが大きかったな
後半で言えばb-adapt=2も効いた
あまり使われてないけどロスレスのHigh 4:4:4 Predictive実装も大きな話だよな

subme 9も地味に容量圧縮に貢献してると思うぜ

>>190
そうでもない。x264とかffmpegとかこういうタイプのソースは比較的綺麗だよ。
vlcやmplayerなどのソースは綺麗とは言い難い面もあるけど。

>>196
お前のうちのカレンダーは1ヶ月半も遅れてるのか

>>196
お前、タイムリープしてね？

1102求む人柱

Speed-up mc_chroma_altivecとあるから、PPCの為の更新だろう。

＞ロスレスのHigh 4:4:4 Predictive
こんなん実装されたっけ？

http://git.videolan.org/?p=x264.git;a=commit;h=b35a044b95c7eab2c91f55a3ac4100ca26a29d92

1106

これってありだっけ？
>Much faster CABAC residual context selection

+#define block_residual_write_cabac( h, cb, i_ctxBlockCat, i_idx, l, i_count ) ¥
+{ ¥
+ int ctxidxinc = x264_cabac_mb_cbf_ctxidxinc( h, i_ctxBlockCat, i_idx); ¥
+ block_residual_write_cabac( h, cb, i_ctxBlockCat, i_idx, l, i_count, ctxidxinc ); ¥
+}

同じ名前の関数を別の引数で定義してる。gccでエラー言ってくるんだけど・・・
c++ならともかく、cでオーバーロードって禁止だったような・・・

>>206
ただの置き換えマクロ・・

いや、こういう意味。
encoder/cabac.c: In function 'x264_macroblock_size_cabac':
encoder/cabac.c:995: warning: control may reach end of non-void function 'x264_cabac_mb_cbf_ctxidxinc' being inlined

>>208
それはx264_cabac_mb_cbf_ctxidxincって関数の終わりにreturn 整数;がないからだよ。
たぶんx264_cabac_mb_cbf_ctxidxincのswitch()文の中で必ずreturnされるんだろう。
だから>>206のdefineとは無関係だよ。

繰り返すが、>>206はx264_cabac_mb_cbf_ctxidxinc()を呼んでる所をその下の4行に置き換えるだけの
単純なマクロの定義だよ。

seraphy氏ビルドのやつでAviutlから吐いたmp4なんだけど、mediainfoで見ると
フレームレート固定で出力したやつでも、レートが可変っぽく記述されてるけど正常？
普通固定なら、24fpsならば23.976fpsとかだと思うけど、最小と最大とオリジナルって項目が出てくるから
気になった・・・

ほかのビルド試してないから何ともいえないんだけど、仕様？

>>211
GUI版？

>拡張設定の「初期Delay カット」「TimeScale 4倍精度」のチェックをOFF
>これチェックしてると出力がCFRでなくVFRになる

mp4にフレームレートなんてものはありません。

>>212
レス�d。GUIです。
そういうことだったんですね・・・
情報ありがとうです。
けど拡張設定せずに出力しても問題ないんかな？

>>213
レス�d。
ですね。AVIの感覚から抜けれない・・・すまそ。

seraphy版もきたな

てかseraphy版1106、なんかエラーでてエンコできないｗ

>>216
うちでは全く問題ないが？gui.auoでいつものオプションだけど
オプションでログ表示できるんだからエラーログ見ればいいじゃない
フィルタが競合してるならIでもエラーログ吐くでしょ
で最近、強制デフォルトするように変更されたけど今回反映されてなかったとかで
デフォルト化してないのが原因だったらもうこれ>>1化した方がいいと思う

× Iでもエラーログ
○AviUtlでもエラーログ　※216がGUIなのかCLIなのか知ったことではありませんけれど
あと1化じゃなくて>>2の[FAQ]ですたね。今後もSerahy氏が強制デフォ化するように作るなら必要ありませんが

gui版でデフォルト押してもエンコできないんだよねー
1101r02までまったく問題なかったのに。まあいいや、寝る

ああ>>3か…つーかGUIスレだったか…疲れてるな…スレ汚しｽﾏｿ
r1106の比較エンコでも仕込んで寝よう。。。

今回はpredict-a.asmとquant-a.asmに手が入っているから、またAMD系で動かないとかいう可能性もある。
すくなくともデフォルト押しと--no-asmで動作を確認すべき。

1109

>>220
なんかアセンブラでミスがあったらしい。これが原因かどうかは知らんが。

Fix 10L in intra pred

Forgetting a %define resulted in SIGILL on 32-bit systems without SSE (e.g. Athlon XP).

AQもVAQも量子化パラメータの設定を変えてごまかしただけ。
b-adapt=2はもともとクソだったBフレームを修正しただけ。

全部、H.264の範囲内。

範囲外だったらだめじゃん。

>>223
220です。まさにそれが原因だったみたいです。

http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ&gid=3
最近、PPCへの最適化が続いているとは言え、これを見る限り、Intelと比べるとG5でも遅いな。

seraphy版は最近999に戻したよ
やっぱこっちの方が画質が（・∀・）ｲｲ!!

えー

>>228
どんなオプションだよそれ…

>>230
AQの類はオフ、あとはテキトー

画質が違うと言うならその原因まで探ってくれれば皆の役に立つのに

seraphyノーマル版1109guiでﾏﾙﾁﾊﾟｽ出力しようとしたらエラー吐く場合と吐かない場合がある
大体2回に一度は失敗するなｗ　原因なんじゃらほい

俺はｒ1063のまま落ち着くの待ち

俺はｒ1028→r1086に昨日入れ替えたところ、ほんのりファイルサイズ小さくなったきがす

最新版にしたらエンコ速度が爆速になってて吹いた

>>236
どれから変えたのかは知らんが
1106から1109にしても爆速にならねーよ

1102だか1103以降でかなりコードに手が入ったらしいから
それ以前からの更新だと爆速になるかもな

>>237
すまん800台からなんでな。FPSで2.5倍くらいかな。

またえらい過去からようこそ

手元だと1101から1110で5.7%も速度が上がった

　 ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　 　 　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　 　/.:oヽヽ: :|: | :|
　　　 　{　{o:::::::}　　 　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　 　ヾ:::ｿ /|: : |
　！？ ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　 ＞
::∧: : :|: |J　　 ＼　　 ／　　 ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　 ヽ: |::|＼　　　 ￣/ /|　　|: : :|: |

高速化した分tesaとmerage64にでもするか

宝くじに当たっても一ヶ月でパーにする典型

999使いです
r1086でやたら時間かかってたけどr1109でやっとr999を超えられるようになったな

>>233
うちも
イベントには.NET Runtime 2.0 Errorって出る

x264 VFW GUI専用スレ Part4
http://pc11.2ch.net/test/read.cgi/avi/1221328142/

最近のverは圧縮率が結構上がってる気がする
704ｘ396でエンコするとソースによってはcrf20で音声込みでも100MBくらいになる

へーすごいすごい

>>233
>>246
うち場合は
r1090あたり？から
NTDLLエラーが出てマルチパスが駄目になったけど
（ウイルスにかかってたせいかもしれないけど
micro soft office IMEを消したり、違うリビジョンのを使ってるうちに直ってた

ところでi16x16使って検証した人いる？
普段使ってるオプション類に追加してみたけど変化がよくわからなかた

追加？
i16x16に何かするオプションなんかあったか？

説明下手ですまぬ
普段は
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
とやってたんだがi16x16があることを知り
--partitions p8x8,b8x8,i4x4,i8x8,i16x16 --8x8dct
とやってみたんだが変化を感じられなかったといいたかった

あのね…16x16は常に使われるのだよ
ヘルプのpartitionsのどこにもi16x16って書いてないでしょ？
そうじゃなきゃpartitions noneってしたときに一切のエンコードができなくなっちゃうじゃん

>>254
そういうことでしたか了解しました。
ご丁寧な説明ありがとうございます

>>253

> Add decimation in i16x16 blocks
> Up to +0.04db with CAVLC, generally a lot less with CABAC.

のことだったら、"Add decimation" であって partitions に i16x16 が
増えるわけじゃない。

seraphy版x264.1110.release01で何かが直ったらしい

x264.1110.release01
・rev1105にてCABACの処理に発生したメモリリークバグの修正

エンコ済みファイルの素性（エンコーダやパラメータ）を解析する
mp3でいうところのEncSpotみたいなソフトはありませんか？

MediaInfo
avinaptic
ここらへん

>>260
即レス感謝です

1112
Windows 64-bit support

さっそくWin7で試してみるか

何か半分（それか完全に）オフトピになるんだけど、Cygwin系のスレしかない
のでこっちで書こうと思った。

今日はWin7の64ビット版でMsys/Mingwでx264をビルドしようと思ったけど、
msys.batはshell(sh)を起動して0xc0000142というエラーを吹いて死ぬ。

Win7-64でビルドしようとしたエロイ人、相談にのってくれないかな？

Cygwinで試そうと思ったけど、msysに慣れすぎて苦労することになりそう。
OTZ

32bitだがgitでリポジトリ取ってこようとしたらPermission Deniedでできなかった。

エンコするだけなら↓にバイナリあるけど。
ttp://forum.doom9.org/showthread.php?t=130364&page=81

>>265
Doom9や#x264/#x264devの公式チャンネルでいつもLurkしてるんで、ビルドが
出る瞬間はリアルタイムで見れる。
だけど、今回は一応習うために64ビット版まで手を出そうと思った
（丁度Win7-64を入れたところだし）。

まぁ、ありがトン。時間がかかってもダメだとしたらXPの64ビット版を入れよう
かと思う。Cygwinでリポを取ることができたんだけど、いろいろパッケージが
足りてなくて./configureがダメみたい。

公式チャンネルでいつもLurkしてる=tobinaka

なんか最近ビットレート割り当てるのに
1024だとか2048だとか所謂バイト単位でキリのいい数字割り当ててるの見る事増えたんだが、これ別に意味無いよな？
1000と2000でいいと思うんだけど。
別に昔からそんな事してなかったし。
それとも最近その方が画質がよくなるとか無駄がなくなるとかそんな仕様にでもなったの？

よくわかりもしないのに、解像度とかが1024とか8の倍数の方がいいってのを
ビットレートもそうだろって思って勘違いしてる奴なのかな。
それとも実は俺が知識不足で知らない何かがあるのかな。

無い。

出来上がりのファイルサイズを意識していると、10の倍数よりも2の倍数の計算になるってだけ。
逆にニコ厨などが10の倍数の方をよく使うので見分けがつくという話もある。

>>268
そんなファイルを一体どこで見かけるというのか…

　　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　P　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 P ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 2　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 2　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 P 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 P　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ

>>270
小容量なニコの方が半端なレートになるだろ

単純に10進<->2進の習慣がある人かどうかだけのような気が

1024の方がキリがよく見える職業病みたいな人だっているだろたぶんｗ

crfだから関係ないや

でも1024kbpsとかアホらしいよな。
それって1024000bpsじゃんｗ

1.44MBフロッピーみたいですね。

--vbv-bufsizeと--vbv-maxrateがちゃんと設定できていたら、後はどうでも良い。

1048576bpsでないとな

どうせそんな厳密にレートコントロールしてくれないし

>>275
プロ雀士だな

x264の場合はキリがいい数を当ててやると意外にエンコスピードが速くなることがあるよ。
色々試してて気づいた。

そんな単純なもんじゃないだろ

>>283
マジか！

1024Kibps と書けば 1024*10^3bpsと間違えられることはないな

>>283
それって 2のべき乗ではなく、指定ビットレートが処理都合に合って早くなった んじゃね？

＝＝２８３
詳しくやりかた教えてくださいｲm（・＿・）m

しばらく離れてたんだが
experimentalの作者ってまだ公開してる？

これのことか？　
　ttp://www.esnips.com/web/VFRmaniac-Softwares

Doom9で32bitでクロスコンパイルが話題になってるな。ちょっとやってみよう。
64bit持ってないけどな。

x86_64-pc-mingw32-gccをビルドして、x264をクロスコンパイルできたよ。
gccはmingw-w64の手順通りで大丈夫だけど、
gpacのconfigureがネイティブコンパイラを前提にしてるから
いじらないといけないね。

うん、まさにそこで躓いてる。ｋｗｓｋ

>>293
FreeBSD/i386で確認したので、他の環境では他にも問題があるかも。

まず、zlibをビルドして、インストールする。
configureの前に、環境変数 CC、AR、RANLIB をクロス環境に合わせて
設定するのを忘れないこと。
特に、ARには引数 rcも指定する必要があるので注意。
インストール後、設定した環境変数は消しておく。

次に、gpacのファイルを修正する。
configureにおいて、targetos変数を uname -sの結果によって設定しているが、
クロスコンパイルでは問題があるので、"MINGW32"等、決め打ちにする。
また、システム中のzlibを認識する部分で、コンパイラオプションに-Iと-Lを
追加して、インストールしたzlibを使うようにする。
include/gpac/setup.hにおいて、
#include <gpac/internal/config.h>
という部分があるが、これは間違いだと思われるので、
#include "config.h"
に修正する。
また、src/Makefileにarとranlibを決め打ちで使用している部分があるので、
それぞれ$(AR)と$(RANLIB)に修正する。

以上の修正を行ったら、ビルド用ディレクトリを作成し、
configureを実行する。
--cross-prefixをクロス環境に合わせること、
--cpuをターゲットに合わせて設定すること(x64ならx86_64)、
--extra-cflagsや--extra-ldflagsに-Iや-Lを追加し、
インストールしたzlibを使うようにすることが必要。

あとは、make libでgpacのライブラリをビルドできるはず。

bフレーム関連のオプションは
--bframes 3 --b-pyramid --weightb --b-adapt 2
でエンコしてるんだけど --b-pyramid はやはり何かまずいのかい？

>>295
PCで再生するなら、気にする必要は無いが、x264の--b-pyramidを使うとDPBが増えるから、
ハードウェアとの互換性が落ちる。

あまり詳しくは分からんが、DXVAと相性が悪いらしくて
MPCHCのデコーダで再生すると良くないとかなんとか

MainConcept等、他のエンコーダはpyramid含めてDPBの計算をするから、積極的に使った方が良い。

b-pyramid使うなら他のエンコーダにしろってこと？

厳密な互換性を気にする人は、x264のpyramidを使うべきではない、と言いたかった。

mingw32、gcc4でpthreads-win32を使うと、
--8x8dctを指定しないときに落ちるなあ。

encoder/analyse.c の x264_mb_analyse_load_costs() 関数内、
x264_emms() の呼び出しをforループの前に移動すると落ちなくなるようだけど、
いまいちよくわからない。

>>295
既に書かれてるけど互換性がね。9600GT使ってるけどDxVAでの再生に問題は出たこと
ないけど、PSP、PS3、あと環境特定出来てないけどQuickTimeで再生出来ないこと多し。
x264で何度か --b-pyramid に手を入れてたみたいだけど、未だに問題ありそで使ってない・・・

b-pyramidの諸問題は昔ばなしじゃないの？

>Note: in older x264 revisions this increased DPB size, but this is now constant based on ref.
http://mewiki.project357.com/wiki/X264_Settings

ここにはこうあるし、今はもう直っているのかも知れないな。

>>304
DPBサイズが一定になったって話は知ってるんだが・・・
最近の(r1000以降)でも --b-pyramid 使うと緑のブロックノイズがめちゃくちゃに出るんで
まだどっか問題あるんじゃないかと思ってた。PS3も試してみよかな・・・

>This setting is generally beneficial, but it increases the DPB (decoding picture buffer) size required for playback,
>so when encoding for hardware, disabling it may help compatibility.
http://ffmpeg.x264.googlepages.com/mapping

ただこっちはこうだし、gitのshortlogにもそれらしき記述が見あたらないので、やはりまだ直っていないのだと思う。

>>305
> 緑のブロックノイズがめちゃくちゃに出る
あ、PSPのコトね。QTは全然再生できず。1年前から対応できたって話もあるんだが・・・
ttp://mycometg3.blog.so-net.ne.jp/2008-02-02
やっぱソースに拠るのかなぁ。

>>306
うーん、やっぱなんかヘンな気がするよね。互換性気にしない人には今の実装で十分だろうけど。

現状使用しているBの枚数が多ければ多いほど、それ以上Bを増やすより
pyramidの方が効果高いから、修正してないなら早く修正して欲しいところだ

たしかBが4〜5枚程度でもBを+1するよりpyramidの方がRD改善度がよかったはず

>>308
Bを+1って、Bフレ5でも相当互換性犠牲にしてる気がするｗ
たしかにBフレ参照は符号化効率上がるハズだけど(なぜか--b-pyramid入れるとファイルサイズ
大きくなること多いorz)、Bフレの量子化係数が良くないと意味無いんじゃないかな、とも思う・・・

Bフレって言うと光ファイバーのほうが真っ先に思い浮かぶ

互換性で問題になるのは、本来Bの枚数じゃなくてrefじゃないのかな
DPBに格納する枚数はrefで示されるべきなわけで
規格(Level)でBの枚数制限って決まってないでしょ？決まってるんだっけ？

まぁ実際にBの枚数で制限するデコーダはいくらでもあるんだろうけどさ

通りすがりだがこのスレ外国人の集まりですか？

はい、私は日本から接続しています

Bフレ5って笑うところですか？

Bフレ0は笑うところ

x264って映像がやたらとプルプルするよね

しないよ

>>316
多分眼球痙攣だぉ　眼科をおすすめするぉ

自動フィールドシフトとか?

>>311
その通りなんだけど、Bフレームは"双方向予測"だから、ここでPフレームよりDPBが増える。
で、BフレームをBフレームから参照できるようにすると(要するにb-pyramid)、
参照元のBフレームも取っておく必要になるから、更にDPBが増える。

…って事だと思う（怪　　initial delay が1増えるのと関係がある

How to calculating max ref for level,....
http://forum.doom9.org/showthread.php?t=142758

詳しく書いてあるのは、このスレ辺り。

めんどくさそうなオプションは切っとけってばっちゃが言ってた

crfの値ってどう使われてるの？映像の最初の方でcrfの値よりqpを下げてたら最後の方ではqpあげようとするの？
まあ何が聞きたいかって言うと、qpminを下げると、動きが激しいところでqpがあがりやすくなるのか？って話

変動の幅いじるならqpstepの方だろ

>>323
動きとQP値の関係ならqcomp
qp(品質基準VBR)だと、理論的には良いけど動きが激しい所でﾋﾞｯﾄ食いすぎ。勿体無い。
→よし、動きに応じてQP値上げてごまかしちゃおう。
これがcrf。　で、どれくらいQPを変動させるかがqcomp
qcomp= 0.0(CBR,ﾋﾞｯﾄﾚｰﾄ固定)〜1.0(VBR,QP値固定＝qp)

>映像の最初の方でcrfの値よりqpを下げてたら最後の方ではqpあげようとするの？
1passｴﾝｺｰﾄﾞなので行き当たりばったり。 動きが無ければ結果のQPは設定より低くなるし、多ければ高くなる。

>qpminを下げると、動きが激しいところでqpがあがりやすくなるのか？
わかんない。　やってみればわかる。

crfで水があるやつなんかをやると桁外れのサイズになって驚くことがある

＞映像の最初の方でcrfの値よりqpを下げてたら最後の方ではqpあげようとする
1passの--bitrateモードがたしかそんな感じ

俺ってば見当違いですね、忘れてください

crfとzonesを愛用しているわ

>>325
> >映像の最初の方でcrfの値よりqpを下げてたら最後の方ではqpあげようとするの？
> 1passｴﾝｺｰﾄﾞなので行き当たりばったり。
正確には1パスじゃなくて、--vbv-bufsize のバッファサイズ間でquantizする。
その区間の最大ビットレートが --vbv-maxrate。

x264でプロファイルを明示的に指定する方法ってある？
Baselineでエンコしたいんだけど

>>331
MeGUIを使って、AVC ProfileにBaselineを選べば、使えるオプションがどれだか分かりやすい。

>>294
ありがとう。それらしいのがビルドできた。
--extra-cflagsと--extra-ldflagsに何も追加しなくても--cross-prefixだけで
configureに-I/mingw/x86_64-pc-mingw32/includeとか出たからそのままmake lib appsしてみたら通った。
勝手にやってくれてるんだろうか。32bitの方のlibz.aは削除してからやったから大丈夫かな？

とりあえずWin 7の64bit版でも入れてテストしてみるか。
RCの期限切れたら64bit版をイヤッッホォォォオオォオウ？

自作板以外でIYHerを初めて見た

crfは、そのフレームをエンコした結果どんなサイズになるか予測してqpを決める仕組み
なので、その前にどんなビットレートになってようが関係ない。

>>335
まったくイミフなカキコだけど、どれに対するレスなん？

>>323

人間、謙虚さを忘れたらダメですよ。

またや
今度はVFR maniac氏のrev1112(OreAQ)で破損が…
今までVFR maniac氏のビルドで問題が起こったことなかったのに
再生環境：MPC+Haali+CoreAVC
http://sakuratan.ddo.jp/uploader/source/date104778.jpg

やっぱり原因はデブロックスルーってやつなのですか？

その状態は参照元フレームがバッファに読み込まれていないだけ。
デコーダの不具合の可能性が高いが、当然ffdshowの最新とCoreAVCの両方を試してから聞いてるんだよな？

スキップのこと？
スキップデブロッキングじゃこんな綺麗なモザイク状にはならないと思うよ
--no-deblockでエンコしてみても似た症状が出たらdeblock関係は無罪

ffdshowだと問題なかった
ということはCoreAVCの不具合ですか
じゃあ仕方ないか

こんな場合はCoreAVCのバージョンも書いときなよ

みんな一時間の実写番組エンコするとき容量どのくらいに収めてる？

1.9.0.0じゃね、スレが不具合で盛り上がってたし

>>344
さっさとンコして寝ろ

静止画のムービー作る→ビットレート落としたいからFPS下げる
→シークに問題が出るためにIDR間隔を縮める→ビットレートが増える

うむむ・・・

みんな、３０分ぐらいの物、エンコ時間どんなもん？最近疲れてきた。。。

>>342
CUDA支援の不具合ならそれを切れば〜

>>348
1080p@24000/1001で35時間ぐらいかな？まぁ、ソースはロスレスじゃなくて、
ちょっとフィルターされたAVSだけどね(ffms2でH.264)。

「encoded 34237 frames, 0.27 fps, 5511.23 kb/s」

>>348
邪道だが 960x540 で 15〜20分で済ますよ
モノによっては10分程度で終わる場合がある
もう今はレコがメインだしな

>>348
X2で頑張ってる俺の場合は30分モノで2.5〜3.6時間位かかってる。

とりあえずrefは3までmeはumh以下でmerangeは16までtrellisはオフでbadaptは1にしておきなさい

>>352
俺もX2、というかOp165で頑張っているが9時間以上かかるぞ。
1920x1080になると12時間を超えるな。
meをumhからesaにすると24時間を超える。

Q6600で1080pで5時間弱 だな
あまりフィルタ使わない主義

PSP用でほぼ等速

1080pって60fpsだから30分ものだと60000フレーム越えるよな・・・
これは俺のPCでも時間かかるかも

Q6600で
PSP用に480x272 crf20で４分の３くらい
PS3用に480p,2passでソースの３倍くらいかかる
PSP用に作った動画のビットレートを参考にPS3用のビットレート決めてる

x264-Dev MLに、
　Moscow Univでの第５回H.264 Codec Comparisonのアナウンス
が投稿されたんだが

早速Dark Shikari氏が評価基準とか環境とかで噛み付いてる（笑）

／／

ここだけ。
> x264 can optimize for PSNR (AQ off, psy-RD off), SSIM
> (AQ on, psy-RD off), or visual quality (AQ on, psy-RD on).
ここでいうpsy-RDはRDOとpsy-Trellisの両方？それともRDOのみか？

MainConcept won the “Third Annual MSU MPEG-4 AVC/H.264 Video Codecs Comparison” of the MSU Video Group
http://www.mainconcept.com/site/news-9/2006-21671/mc-won-msu-comparison-19239.html

まあ、この手の宣伝にも使われるMSUのテストは、私としても興味は無い。

それより、今となっては古いが、Doom9本人が、PSNRやSSIMではなく主観でやる比較の方がまだ参考になる。
http://www.doom9.org/codec-comparisons.htm

そういやseraphy氏のCABACのパッチってどうなってんの？開発者は誰もバグに気づいてないの？

俺はPSPとPC兼用なので720x480のcrf20で大体1時間半ぐらいかな。
どうせアプコンアニメだから丁度いい。
ハイビジョンはそのままレコでエンコはしない。
偶にバラエティものや資料もの（CGTVや大改造ビフォーアフターなど）はXvidで実時間ぐらいかな。

>>354
俺はavisynth使ってる。フィルタはaviutlのも使って、5個くらい。
解像度は1280のみだし、環境によるでしょ。
てかtrellis入れると暗いシーンの時、キャラクターの顔にノイズ入る･･･
俺の設定がダメなんだろうけどｗ

>>363
俺はaviutl使ってる。
しかも今時2passエンコですよ・・・AQの使い方と設定わからんorz　つか試す暇が
1pass目はフィルタ全部切ったりmeをdiaにしたりで5fps
2pass目はwarpsharpやバンディング低減MTやらを入れてmeをumhで1.5fps
Iフレームのサイズが6桁いくけど画質に不満はないからまぁいいか

>>364
avisynthに移行できるようになると結構早くなるよ。
移行したての時は1.8fps→2.8fpsになって、フィルタ見直して今では3.5〜4.5fpsくらい。
って、スレチすまん。
AQ使わない方が暗部の細部が潰れなかったりしたから、切ろうかどうかちょっと悩む･･･

>>361
できたファイルは正常なんだから、普通気づかないんじゃね？
一回目のエンコのときはメモリーを連続して確保するからはみ出した先のメモリーも
確保済みで問題ないんでしょ？
x264gui.auoみたいに起動したまま何度もエンコするなら危険だろうけど、x264.exeを
使っていればソフトは再起動されているから大丈夫と。
気分的にいいもんじゃないが。

>>366を書いた後gitを確認してみたらr1114がきてた。r1105で入ったCABACの問題が修正されたようだ。


Optimize neighbor CBP calculation and fix related regression
r1105 introduced array overflow in cbp handling

fgoを外してseraphy氏のrev1113(OreAQ)でエンコしてみると問題なかった

>>343
1.8.5と1.9で確認して両方で破損が起こった
一応、破損箇所のサンプルをあげておきます
http://www1.axfc.net/uploader/Li/so/28015

ＤＬさせる気ないだろ

sample

>>361 >>366
【修正履歴】
□x264.1110.release01
・rev1105にてCABACの処理に発生したメモリリークバグの修正

更新よく見てみろよ。節穴か？公開されたのは2009/02/12だぜ
高速でr1114もビルドしてるSeraphy氏に感謝

>>371
seraphy氏がx264の開発者達に不具合報告を出していないことが前提での話しな。
報告を出したとは掲示板に書かれていなかったから、出していない事を前提にした場合、
本家の開発者は今回の不具合は気づきにくいだろうと書いたんだ。

本家の修正が早かったから、不具合報告を出してたのかもな。

>>372 理解
しかしCABACのバグは直ったがmetric 1が使えなくなったのはオレだけだろうか

報告したのはVFR氏かt[禁則事項]じゃね？

あのバグの報告は、XhmikosR氏によって（.grからの接続）日本時間の午後
９時あたりにIRCの方であった。なので、Seraphy氏とかは関係が
ないかと思います。１時間半後、Dark_Shikari氏がバグフィックスを出して
日本時間の午後１１時あたりに
「<Dark_Shikari> I'm committing now due to the bugfix」という発言
があって、rev1114が出ました。

日本人が元の開発者達の周りに来てくれないのは非常に残念なこと。

難解な動画関連の話を、ネットスラングな英語でリアルタイムでチャットできたら凄いよなぁ。
Doom9を読むのも四苦八苦ですよ。

>>376
やってみなきゃわからんでしょ？

Freenodeの#x264では、日本人が２人ぐらいいます。英語が喋れなくても、
とりあえずチャンネルに入って会話の流れをチェックしましょう
（東方やTYPE/MOONなお話はたまに出ます）。あと、バグ報告に関しては、
「Hello. I think I have found a bug.」ぐらいから初めてもおｋ。
英語が完全にダメなら#x264に入ってJEEB/JEEBczというユーザーにに
プライベートメッセージを送ってもおｋ。外人だけど、日本語は理解できる
(それか、その時にもしかしてINしてる他の日本人にでもおｋ)。Freenodeの
基本文字エンコードは色んな日本の鯖と違ってUTF-8なので、そこは注意
しましょう(日本語の場合)。

Seraphy氏自身を一応#x264に誘っておきたいんだけど、サイトだとメールは
ないし、掲示板に書くしかないよねぇ…

猛烈にt(ry臭がするのだが気のせいか？

急に出てきたコテがこんな感じだとそう思わざるを得ないな

皆思う事は一緒でワロスｗ

なんちゅーか、seraphyさんもVFR maniacさんもやりたきゃ自分でやるわけで
余計なお世話な事この上ないよな

>>381
まぁ、無理やりは言わないけどね。確かに「誘う」とかは余計なお世話かも
しれないが、Dark_Shikari氏も一応そう望んでるし（日本人開発者も
増えれば（ｒｙ）。

日本国内で開発されたパッチなどバグフィックスがあまり外に出ていないのも
事実だしなぁ…

>>379
コテハンで悪かったな。

まぁ、そういったところで、#x264は一般会話のチャンネルで、開発関係が
深くなる話は#x264devで（とD_S氏からの宣伝）

なんだ、前に来た外人の人かと思ったｗ

そういうのは暇な奴が報告すればいいだけで参加したけりゃ参加するだろうしその時間がないだけでしょ。

みんな閉鎖的だねー。
bug fixに出来るだけ協力すうのは使用者として当然じゃない？

シャイなんだよ

tobinakaもそこまで叩かれる謂われはないよねぇ。
Wikiを勝手に作って勝手に閉じてまたすぐ再開したのはどうかとは思うが。

>>387
あるだろ
無断で紹介とか断ってるのにseraphyにでてこいとか

え？無断なの？

b-frame 2以上は暗がりに弱いとかもう昔の話ですよな？
てか今も2でおｋ？

自分でやってみればいいじゃん

>>391
そりゃそうすね、ゴメソね

暗部ノイズとBフレームの枚数指定ってどんな因果関係があるんだよ
ビットレート指定で枚数を増やしたら改善するっていうなら理解はできるが

ちょっと前のリビジョンで、暗いシーンでBを使う時の画質が上がったってどこかに書いてあった気がする
1091だと思うけどどこで読んだのかは忘れた
いずれにせよ枚数の問題じゃないけど

TMPGEncのAVCでレートを25000まで上げても取れなかった暗い場面でのノイズが
ちょこちょこっと設定の内容をググってaviutl+x264でエンコードしたらあっさり解決・・・。
もっと下調べしておけばよかったよ。
Quadマシン購入に浮かれて大して考えずにソフト買ってしまった。
まあこれからも使うことはあるだろうけど。

残念だがもう無いな。MPEGEditorのほうなら使い道たくさんあったのに｡･ﾟ･(ﾉД`)･ﾟ･｡

ちょいとスレチで悪いんだがAC3inMP4に対応したmp4splitterって公開停止になってるの？

>>397
ttp://www1.axfc.net/uploader/He/so/197152/MP4
寝るぜ

>>397
自分はここで拾ったよ。
ttp://codecs.ex-sounds.net/misc/ac3-in-mp4_splitter/

>>398-399
横からサンクス

今OreAQ使おうといろいろ調べてるんだけどaq-strengthとqcompについてちょっと教えてください
いろいろなところで依存について書いてあるんだけどqcompに0.7倍を足すって解説してるところがあれば
1.43倍を足すって解説してるところもある
たぶんバージョンによって変わってくるのかなとまではわかったんだけど
現状ではどういう風に計算すればいいのでしょうか？

書き忘れごめんなさい・・・
・OreAQで--aq-mode 2を使う
・〜倍はaq-strengthの〜倍
というのが抜けてました

最新のを落としてreadmeの履歴をよく読め

>>403
申し訳ありませんorz
レスありがとうございます
とりあえず--aq-modeが現在は０か１しか引数として受け付けないことはわかりました
ただ、readmeの履歴を見てもqcompとaq-strengthの依存については書いていないようなのですが
もしかして今はもう依存なくなったということでしょうか？

ですね。現在のビルドでHDエンコなら--qcomp 0.7 --aq-strength 10で十分と思われ

>>403さん>>405さん、ありがとうございました

>--aq-strength 10
？
これは--aq-sensitivityのことでしょうか？

x264 --help

あ…ごめん
--qcomp 0.7 --aq-strength 0.5:0:5 --aq-sensitivity 10
ですね

>>407
ありがとうございます
x264 --longhelpの方も参考にしながら勉強していきます

>>408
いえいえ　わざわざありがとうございます
DVDエンコなのでstrengthとsensitivityの方は自分で絵を見ながら調整していきますね

皆さんありがとうございました

x264じゃないがseraphyさんとこにカナダ人が来てるｗ

>>409
AQdebug使ってみろ
数値化して判断できるからOreAQのクセもよく分かるし、調整もしやすい

Canadianのフリをしたtobinaka☆

　 ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　 　 　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　 　/.:oヽヽ: :|: | :|
　　　 　{　{o:::::::}　　 　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　 　ヾ:::ｿ /|: : |
　！？ ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　 ＞
::∧: : :|: |J　　 ＼　　 ／　　 ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　 ヽ: |::|＼　　　 ￣/ /|　　|: : :|: |

完全に行き詰ってしまったので可能性がある問題が何かありましたら教えてください・・

@echo off

C:\te\x264.exe --crf 22.0 --level 4.1 --keyint 240 --qcomp 0.75 --min-keyint 1 --ref 4
--mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --subme 7 --trellis 2
--psy-rd 1.0:0.0 --deblock 0:0 --analyse all --8x8dct --scenecut 70 --me umh --merange 32
--threads auto --thread-input --cqm flat --progress --no-psnr --no-ssim --output "C:\te\test.mp4" "C:\te\test.avs"

pause
exit

test.avsの内容はaviファイルを入力させて物です（VirtualDubMod表示確認済み)

x264[error]: could not open input file 'C:\te\test.avs'

とエラーが出てしまいx264にエンコード出来ないです。
x264のバージョンは1113 64bit版です。
OS windows xp x64 SP2
avisynth 2.5.7

初心者質問スレに書き込みしたつもりがｽﾏﾝｿ

>>411
レスありがとうございます
debugモードは少し敷居が高そうだなと思って敬遠してたんですが
seraphyさんの掲示板にあったサンプルを見たら便利そうですね
使ってみることにします

>>414
でそれはYV12なのか？
avsにConverttoYV12って書いてみろ。

YV12じゃなかったらYV12じゃないってエラーが出てくるから違う

>>414
そんなにごちゃごちゃおぷちょんつけてないで、最小限にしてエンコードしてみれば？
なにで、アウト食らってるのかそれじゃ永遠にわからないとおもうよん。

avsも晒してくれんとなんともいえんな

>>419
エラーよく見ろよ
avsが開けないってエラーなのにx264のオプション云々は変だろ

てか初心者スレのほうでやってるし別にいいんじゃないの

>>414
.avsをAVIUTLに読ませると、エラー行が分かると思うが。

avsfilter.dllがAviSynthのプラグインフォルダに入ってないとエスパー

>>414のはそれ初心者スレで進んでるからこっちでやっても仕方ないぞｗ
結局の所、32bitで正常に行く環境で、単純にx264だけを64bit版にするとあのエラーになるようだ。

>>421
エラーメッセージは常に正常と考えるのはおかしい

OreAQを使ってる奴に聞きたいんだけど、qpstepの値はどうしてる？
AQでqp値が大きく動くからqpstepの値は16とか20くらいにした方がいいの？

おぷぷん

>>427
俺は8か10にしてる。

>>421
もうちょっと経験つめ
全部optionはずしてそれでもavsが開けなければavsの記述だけど
>>426さんが言ってるように常にエラーメッセージが正しいとは限らない

>>427
ほぼ無制限的な意味で16辺りにしてるけど、なんかマズイのかな〜・・・

デブロックはアニメだと-1:-1（うろ覚え）がいいとか聞くが俺は0:0でいいと思うんだが
そのあたりはどうしてる？

>>432
-1ってr999以前の話じゃね？

PSPだけど-2:-1にしてる

場合によるとしか言いようがないだろ
そのほかのオプション設定やソースの性質や好みによって話は違ってくる

現ビルドだとオレも0:0が多いな
作品によっては1:1にする時もある

デブロックなんてソース毎に調節しろよ
なるべくかけない方がいいんだからさ
デブロックかけすぎるとボケボケになるぞ

>>437
そんなんみんなわかってるだろ

それならアニメだと-1:-1がいいとか言うなと

>>439
標準値の話だろ？
そこから必要に応じて調整するんじゃね？

デブってプラス側にかける意味あるんだ？無いかと思ってた

プラス側にかけると細部潰れるぞ

0か-1っすね

-2〜0あたりじゃないと効果が薄いし、細部が保持されない

0だなアニメにはこれが一番バランスがいいしエンコスピードも若干早くなる

>>445
エンコ速度の差は私の手元では見受けられませんでした

ちょっとx264をWin32でビルドするチュートリアル書いてみた
ttp://forum.fushizen.eu/index.php?topic=4.0
眠い間書いてたんで、意味不明な日本語もあるかもしれないが、一応テスト済み
ということで。コメントがあったらどうぞゆっくりとしていってね。

俺用チラ裏
Doom9のx64スレで出てたkomisarさんのGCC 4.3.3でx264GUIをビルドしようとしたら↓のエラーが出た。
libmingwex.lib(mbrtowc.o) : error LNK2001: 外部シンボル "__imp____lc_codepage" は未解決です。
で、ttp://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=891が参考になった。
まあ__imp____lc_codepageでググれば一番最初に書いてあるんだけどね。

Visual Studio 2008 コマンド プロンプトでlibmingwex.aがあるディレクトリに移動して
lib -remove:mbrtowc.o libmingwex.a
lib -remove:wcrtomb.o libmingwex.lib
できたlibmingwex.libを使う

なんならフィルタoffでもいいぞ

Topic: 最新ビルド: 1114 (x86一般 & x64テストビルド@4.4.0)
http://forum.fushizen.eu/index.php?topic=2.0

次スレからは、>>1の[バイナリ]に、ここを加えるのが良いだろうな。
更新の途絶えたこれらのサイトは削るとして。

http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/

>>450
#x264で更新RSSを頼まれたんで、一応Wordpressでログを作りました。
ttp://x264.fushizen.eu/
現在DaKaZ氏のx264_threaded_slicetype_avail_1114.diffの安定版を
ｗｋｔｋしながら待機中。

最近更新ないねぇ

2Dや3Dゲームの動画をエンコする僕はぼけるのがやなんでデブロック切ってます　これをやるとくっきりなんです

僕もぼけるのは嫌なんで動画をエンコードしてる時はデブロック踊ってます　これをやるとぐったりするんです

デジタル放送の動画をエンコする僕はブロックノイズやなんでデブロック0,0入れてます　これをやるとソースのブロックノイズまで綺麗になるんです

デブが映っている動画をエンコする時は、僕はデブがいやなのでデブロック6.6を入れてます
これをやるとデブが気にならなくなります

デジタル放送の動画をエンコする私はディテールがつぶれるのが嫌なんでデブロック-2,-2入れてます　これをやるとソースのブロックノイズは残るが、ひげがに残るんです。

なんかDoom9に興味深いことが書いてあるな
Even with threaded slicetype (coming soon), x264 will probably cap out before 32 logical threads in most cases.
So just run two encodes at once.

なるほど

0.5秒で理解できた

avisynthでMT使うのやめて複数エンコしてみようか

>>450
うい

>>459>>460
この一文に関して、私は真に驚くべき翻訳を見つけたが、このスレはそれを書くには狭すぎる

ほんとだってば。誰か代わりに書いておいてｗ

Phenom-Owners! Want 11,7% faster x264-encodes for free?

http://forum.doom9.org/showthread.php?t=145106

Phenomなら、--threads 12でやった方が速くなるとか、マルチスライスではない今でも色々あるわな。

>>463
分かったから、さっさと寝ろ。

>>458

x264はロジカルなスレッドが多い環境に設定されてないので、一つの仕事で
CPUを完全に使用できない可能性もあるってことで。普段の環境だと
ボトルネックはフィルターやらデコードなんだけどね。

>>464

その下にD_S氏が「CPUに関わらずに、b-adapt 2を使うならスレッド数を上げる
とパフォーマンスが上がるみたい。だが、MT化されたlookaheadがもうすぐ出る
ので、デフォのスレッド数は今のままにします。」（ちょっと勝手な翻訳）

なかなかthread-safeでCPU効率高いプログラミングは難しいね。
セマフォ使いまくると利用効率上がらんし(x264にクリティカルセッションがどんだけあるのか知らんが)。
それに*nix系と違ってWinはコンテキストスイッチにコスト掛かってるようだし・・・

--threads auto付けてCUP負荷100%だから良しとしてるがｗ

x264_vaqmod_ext.01.r1114.diff
http://stashbox.org/v/409677/x264_vaqmod_ext.01.r1114.diff

--aq-ifactor
--aq-pfactor
--aq-bfactor
↑新コマンドか？

--aq-ifactor <float> AQ strength factor of I-frames
--aq-pfactor <float> AQ strength factor of P-frames
--aq-bfactor <float> AQ strength factor of B-frames

つまりフレームタイプごとに--aq-strengthを指定できるということか？

http://www.mediafire.com/file/g4zmcntmagy/x264_vaqmod.7z
実験用バイナリ

Dquant Option
Dquant applied to I and P frames only usually produces the best results.

VAQは使って無いからどうでもいい
それよりOreAQのABCD区分それぞれの効きにバイアスを掛けられるオプションが欲しい

掲示板に書いてこい

横からだけど書いてきた

--aq-ifactor
--aq-pfactor
--aq-bfactor
デフォルト1.0となってるけど、いくつ〜いくつまでOKなんだろ？
デフみたけどサッパリ

-10.0 〜 +10.0かな？
+1.0 〜 +16.0かな？

おお、掲示板に神が降臨した。

こいつは革命的だな。ここ最近大きな変化なかったから遊んでみよう

OreAQいらね
MIXプリーズ

だから掲示板に(ry

SpursEngine?とCUDAの連携で超高速なTMPGEnc 4.0 XPress。
しかも、超解像度とフィルタでさらにx264を画質を超えた。

>>480
今すぐ眼科へGO！

今まで2時間かかっていたエンコが10分で終わる・・・
笑うしかないwww

そりゃウンコCPU使ってるからだ

画質重視ならx264一択ですな

>>483
バカだろお前wwCore2 QX6700だっつーの。

GTX295＋SpursEngineで1.5Tflops超えているぞマジで演算能力。

たった50GFlops前後のCPUじゃかなわねーなこりゃww

画質重視ならx264一択ですなorz

↑

どうした？ｗ
しょんぼりしすぎだろwww立ち直れよww

ワロタw

NG登録　ID:LK+ZzNpT

気になるからエンコした結果を見せてくれ

TMPってM.Cっしょ
DivX264と同Lv画質かぁ〜金払うLvじゃないっすね

彩度上げて「画質が上がった！」とか言ってる馬鹿と同レベル。

オープンソースのうpデート乞食がなんか言っているが聞こえないww

なんか楽しい事でもあったん？

>>480と>>482見ろよwww

これでx264用済みだわ。じゃあな。

>>493
多分双極性障害の躁状態なんじゃね。

統失

躁でも統失でもなく、ただの宣伝

というか池沼

何か変なの沸いてた？
気のせいか・・・

Doom9落ちてる？

QXってウンコじゃねーかｗ

SpursEngineスレはお通夜状態なのになｗ

10分でエンコが完了するハードもあれば、地味にx264で数時間待っている人もいる。
これが格差社会か・・・

CUDAって夢の技術とか期待されてたけど、
実際ふたを開けてみるとあまり評価は芳しくないね
GPUがCPUに取って代わるってのはまだまだ難しいんだなぁと思わされる。

AMDが頑張ってコンパイラ開発すればいいのに

時代はロスレスかもな。もう設定で悩まなくていいぞ。

そもそも地デジがH.264で放送してくれれば悩むことはなかった

地デジってMpeg2なのか。なんか勝手にH264だと思ってた・・・

>>504
ナンでクダ話になってる？て思ったら、ヘンな人が来てたのね。

summary見るにneighbor CBPの計算最適化の1114からマスタ変更ないね。
一時期日刊かと思う位に更新激しかったのに。

最近seraphy更新ないね

要はx264がCUDAなりSpursEngineに対応すれば最高

>>511
馬鹿？

他人の揚げ足取りしかしない奴もどうかと思うけどな

ID:nnv6fddm

NG登録　ID:xGvTiqYk

スレチかもだけどエンコしたあとの動画ってどんな環境で見てる？
色温度とかガンマ値とか

>>510
本家更新がないから当たり前。
まあOreAQの更新があるみたいだが来週になるそうだ。

OreAQってビットレートを節約する目的で使うんじゃないんだな。
節約のためなら無印？ＡＱの方が綺麗に仕上がるんだなー
難しい

OreAQで高画質にする方が難しい

固定ＩＤ制になったのか

スマン誤爆；

>>515
色温度は白が9300度それ以外は6500度のダイナミックカラー
ガンマは1.0

h.264ってデコーダによって画質に差ないってどっかで見た気がするけど
ffdshow,coreAVC,flashplayerで見比べると明らかに色が違う気がする
ffdshow>coreAVC>flashplayerの順に白っぽくて
flashplayerが1番綺麗に見える.なんでだろ

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

>>523
ほんとスンマセン
ttp://www.esnips.com/web/VFRmaniac-Softwares　の h264_samp2.rar

>>522
ffdshow・CoreAVCとAdobeFlashは再生方法が違うのよ
前者はオーバーレイ・VMR扱える、後者はGDI描写
オーバーレイのときにGeForce7とかだとなぜか汚く表示される(YV12に限る、ラデ等は問題ない)
それかな

普通にYC伸張の具合の違いだけでしょ

2pass目って1pass目より速い？
何か残り時間の表示が1pass目に比べるとえらい少ないんだが。

b-adapt2 かな。 1pass目だけ遅くなる

そうなのか。�d

ｗｋｔｋしながら待ってたx264_threaded_slicetype_avail_1114.diffがMSUの
テストには間に合わないみたい（一番最初の速いバージョンがWin32でlockして
進まない、その後sleepなどをWin32対応にしたら速度がかなり遅くなって、
現在Win32でも普通にいけるパッチが作成中）。

あと、MSUのテスト用にはholger氏のパッチや、--subme 11が作られたん
だけど、その他にholger氏は現在P4やらK8なCPUで遊んでるんで、PhenomやP4
が少し速くなりそう。

<holger> k. unsure what to do about sse2 sa8d. what i did made p4
faster and k8 slower (same for satd and hadamard, but there k8 just
uses mmx which is faster anyway). it should help phenom, though.

x264の他のH.264エンコーダで、私が興味を持てるのはMainConcept Referenceくらいかな。

ところで更新が全然無いのはどうなってんだ。
みんなthreaded_slicetypeにかかりっきりなのか？

x264 can optimize for PSNR (AQ off, psy-RD off), SSIM
(AQ on, psy-RD off), or visual quality (AQ on, psy-RD on)

SSIMもAQ offの方がいいんだと思ってた…

フィックスターズ、Cell利用の業務向け高速AVCエンコーダ
−ソフトエンコーダをCellに最適化、リアルタイム変換可能に
http://av.watch.impress.co.jp/docs/news/20090224_42935.html

>こういった処理性能の向上により、フルHD(1080/60i)で16.7秒の映像をエンコードした場合では、エンコード時間が14.28秒と実時間以下まで高速化。
>なお、比較としてIntel Core 2 Duo(2.53GHz)PCとMainConcept H.264エンコーダで圧縮した場合は139.55秒だったという。

CUDA、SpursEngineに続いてPowerXCell8iもその先の領域に行きました。

>>532
更新がないのはMSU用のパッチやthreaded_slicetypeのせいだね。
Dark_Shikari氏も早く完成させたいだと言っているし…
DaKaZ氏の作品だけどね（Availで作られたらしい）。

>>533
AQは複雑だからねぇｗ

>>534
<Dark_Shikari> remind them that x264 can do 1080i60 in realtime :/

>>534のCodecSys CE　サンプルきた。

すごい高画質。さすが業務用。
http://www.fixstars.com/products/codecsys/sample.html

>>534 >>536
スレ違い
ここはx264のスレであってH.264のスレじゃないんだが

>>537
とか言いつつ>>536ダウンロードしてんだろ。
まったく無関心を装ってさ。

KY AHO

自作PC板に業務用鯖の話題貼るようなもんだろボケ

なんだ昨日の躁鬱病患者か。

どんどん沸いてきたな。蛆虫が。

まあ、お前らには糞x264がお似合いだよwwwwwwwwwww

せいぜい、数時間PC占領されていろよwww
電気代高そうだなおいwwwww

また昨日の残念な人が湧いたのか

今日のあぼんワード：GHI/RftN

かわいそうな子が沸いてるね・・・
いや、湧いてる、か。ウジ虫だもの。

http://img21.imageshack.us/img21/2387/fixstars.png
こう言ったCGアニメにはflatでいいけど、実写にはちゃんとAQを使えるのかな。

マトリックスwwww

>>546

>>536を早速ダウンロードして実験かよww
お前かわいいやつだなおいww

>>GHI/RftN
言っとくけど、20mbpsだと、綺麗じゃないはずはない、少しでもまともな
エンコーダーなら。CUDAならDoom9でチェックすればいいし、中々使い物に
ならないし、PRの人の妄想にしかすぎない。

いいハードウェアエンコーダー欲しいならElecardにでもしなさいねっ♪。

まぁ、どうせお前は荒らししたくきたんだろうし、これ以上は言わない。

言っとくけどとかwww

誰も頼んでないからwww

負け惜しみ言い出したら終わりだなおいwwwwww

価格だけググって来て初売が高価だったQX6700が
今でも高性能だと勘違いしてるセロリン工房か

VIPでやればもっと相手してもらえるのにね

x264の何がそんなに気に入らないんだろう・・・

ID:GHI/RftN
ID:GHI/RftN
ID:GHI/RftN
ID:GHI/RftN
ID:GHI/RftN
ID:GHI/RftN
ID:GHI/RftN

ﾚｽ番飛びすぎﾜﾛｽｗ

>>534

これさ、ちなみにソフトウェアでリアルタイムはあと何年でできるの？
100倍も処理時間が違うとはね。

http://pc11.2ch.net/test/read.cgi/avi/1172031737/
どうせそこから来たのだろうけどそちらへお帰りください

あっ10倍の誤字かｗ

やばい、バカに突っ込まれる前に訂正。ってバカだから気づかないかｗｗ

はいはい坊や、おうちにお帰り。

話題が無いとすぐ湧いちゃうね。

>>557
ソフトでH264リアルタイムエンコードができる頃には、もっと重いエンコード
方法が出てきてるのでいたちごっこ。

昔の固定機能ハードエンコのせいで機能が悪い、画質が悪い
アップデートができないってイメージがついてしまっているからな。

今のCUDAやらCELLやらはソフトエンコができるというのに。

いまのハイエンドCPUを50% 程度OCしたら
H264リアルタイムエンコードできるんじゃないか

CPUの性能向上が鈍化しなければ2011年前後には普及価格帯のCPUで普通にそれくらい出来るハズだった

CUDAのようなGPU専用のアプリが登場して
専用設計したら今よりも高画質なエンコもできそうだし期待している。

GPUの高演算専用の圧縮規格もできるかもしれないし。

そしたら、x264も対応するはずだし対応しなくても
別のオープンソースプロジェクトができるだろう。

GPUは元々映像処理用に作られているんだから、CPUとは演算装置としての性格も違うし、
エンコード（符号化）処理とはあまり相性は良くない。
GPUへの対応が進んで恩恵が大きいのはx264よりも同じ映像処理分野のavisynthやaviutlの方で
x264も含めてエンコーダ一般が対応を進めてより恩恵が大きくなるのは
GPGPUよりもSSE3やMTといったCPU技術への最適化だな

ここってあんまりハードウェアの知識ある人いないんだな。
どおりでCPU、CPU言うわけだ。

知らない物はどうしようもないもんな・・・

そういう寝言はx264並の画質・圧縮率になってから言ってくれよ。

これだから貧乏人は・・・

自分が買える範囲になるまで自分が使っている骨董品が
一番高画質って言い続けるわけですね分かります。

ブラウン管厨と同じでみじめだな。

中学生？

300万もするワークステーション使って高画質とか言われてもなぁ。

どうせ、一番処理負荷が軽い設定で1passとかでやっているんだろ。

そんなゴミ設定よりも早くて高画質なんだよゴミどもｗｗwwwwwwwwww

こっちは一番処理負荷が高い設定でも圧倒的にはやいんだからなwww
蛆虫反論してみろよwww

くやしかったらx264最高設定でこれからエンコするんだな何日もかけてなwwwwww

スネ夫かよｗ

ID変えてまでご苦労様です

・本日のあぼんID
GHI/RftN
I+j4vhqj

いやー、いいんじゃないかなー
古米を”新米”と偽装して高値で売って「やっぱ新米は美味しいよナ！」と嬉しそうに
食べてくれる消費者様がいてくれないと儲かりません

ID:I+j4vhqj
自分の主張を語るのは構わないが、それを他人に押しつけたり他の主張を馬鹿にするべきではないと思う
上から目線で発言しても反発をくらうだけで、支持してくれる人も現れない

一緒に宣伝してやるから一台分恵んでくれ

2048x1536で可逆圧縮に対応してるんなら
検討する人もいそうな気がするけど。

どうせまともなPCは持ってないだろうし
Avisynthも使えないアホだろうから
構ってやるのもつまらないと思えてきた

> 構ってやるのもつまらないと思えてきた

これ構ってることにならないの？ｗ

>>580
いちいちこまけーな

>>581
指摘は謙虚に受け止めるべき。

ｲﾂﾓﾉﾅｶﾞﾚﾀﾞﾅｰ

>>573
言っていることはもっともなのに、そんなアホみたいにwwwwつけていたら
説得力ないよ。

デジカメ板に住み着いている12bit厨と同じぐらい痛い奴だな

誰も指摘しないからあえて言うけど、
誰とは言わないが自演みえみえの奴がいるね

はいはい自演自演。

つか都合が悪くなったらマルチするのがこのスレの特徴なんじゃね？
今までもこれからも。

自分の主張が通るまで粘着するからなw

更新なくて暇そうだなお前ら

>どうせ、一番処理負荷が軽い設定で1passとかでやっているんだろ。
おお、まさに俺だ
まあ、abr 15000 だからいいわ

都合が悪いとか、主張が通るまで粘着とか、
誰をさして言ってるのかまるで分からない

何が言いたいのか分からないけど、ただの荒らし目的だったら
邪魔だから消えた方がいいんじゃね？

それとも、何かいいたいことでもあるのかな？x264関連で。

荒らしがx264を余裕で越える高画質動画を挙げてくれるらしいよ
論より証拠よろしく

>>544,575
かかわったらまけです、おとなはだまってやるべき
しかし楽しそうな話をしているな

>x264を余裕で越える高画質動画を挙げてくれるらしいよ
可逆でいいなら

もちろん可逆でもいいよー
ただし、x264並の圧縮率があればだけどねw

同じ規格同士でのエンコーダー比較ってあんまり意味ないんじゃね？

目くそ鼻くそ。

2014年には周波数100Ghz超えてるからエンコードも一瞬だよ。

ttp://www.geocities.jp/elisy/u/uporg1937643.jpg

Nvidiaってグラフィックカードの会社じゃないか。
なんでCPU？

>>597
かなり変わる。
画質面でどうにもならなくてTE4XPから乗り換えた俺が言うんだから間違いない。

なんかr1000の時並に更新されなくなったな
もう9 days agoですよ
やっぱりthreaded slicetype待ち？
もう少しのところまできてはいるみたいだけど

nl-means(aviutlﾌﾟﾗｸﾞｲﾝ in avisynth)と--threads 2以上 を併用すると落ちるんだが俺だけ？ @OreAQ1114
何故かwin7βではaviutl動かないから、そっちでは調べれてない。
ただ、同じavsが、avs2aviやVirtualDubでは正常に動くから問題だよね？

thread-queue は他のavsでも落ちたことあるし、効果が疑問だったから切った。

>>600

版権フリーの素材でTE4XPとx264比較動画頼むわ。

MainConceptエンジンの残念画質は常識でしょ

>>604でもいいよ。その常識の比較動画頼むよ。

TE4XPは体験版があるから、興味があるなら自分でやればいいのに

おうｗ

今やっているx264しか使ったことないから違うエンコも興味ある。
無料はx264ぐらいしかないからなぁ。

3Dゲームで芝のテクスチャ上を歩く動画をエンコードしているのですがうまくいきません。
どうしても地面がぼやけて、うねうね動いているようにエンコードされてしまいます。

芝のようなちらちらするノイズ的な物がよく動く動画を鮮明にエンコードしたい場合は、
どのオプションをどう設定すると効果的なのでしょうか・・・。

または、「こういう映像にはこのオプションをこうするといい」みたいなことを
まとめてあるサイトはあるのでしょうか？

とりあえず、容量的にも手ごろなニコニコ動画使用くらいの
512x384 24fpsで550kbpsあたりの圧縮率で保存したいと思っています。

明らかにビットレート足りないだろそれ

1080pのソースで500kbpsで比較してみたが初め初期値では動きの多いところでは
ブロックノイズでまくりでx264圧勝と思ったが

動き検索範囲やGDP長、参照フレーム数やらいじったら
x264と同等かそれ以上になったわ。

エンコード速度は圧倒的にMainConceptの方がはやいから
設定もいろいろできるな。

つかx264はエンコ激おそだな。異論は認める。

何言ってんだこいつｗ

まだこいついるのか。一昨日からの粘着恐れ入るよ。
放っておいてもボロが出まくって面白いから生温かい目で見てるけどさ。

お前らも試してみろ。

ちなみに、x264は拡張x264でバランス設定だ。

もうさすがに興味なくなってきたからx264にはこれまでにするわ。
画質もたいした事ないしな。

オプション貼れよ

そもそも1080Pで500kbpsとかｗ
MCのはビットレート指定するとGOP以外の設定無視するから
弄ってもファイルサイズ変わらないぞｗ

>>615
妄想はいいから。ちゃんと変わったし。

>>614
拡張x264でバランス設定って言ってんだろうが。

ここの住人はアホばかりなのか？

バランス設定（笑）

>>ID:f0r0PmTy
どっちが良いとは言わないから、比較するなら両方のパラメータを極めてから出直しなよ
ちょっと弄ってどっちが綺麗だとか言われても全く参考にならない

ここの住人はプリセットなんて使わないからバランス設定と言われてもわからないんだよ

確かにx264はエンコーダーの速度はあれだな。

例えば、処理時間2時間って決めて一番画質がいいエンコは一体どれなのかな。
案外Divx6の最高オプションだったりして。

x264だけなら遅くは無いと思うが。
結局一番時間がかかってるのはフィルター処理じゃない?

せめてインタレ解除はGPUに投げたい。

CoreAVCもCUDAに対応したしな。

エンコードもそろそろ・・・

そしたら、最高オプションでエンコ毎回できるのに。

春先になるとあちらこちらのスレに変なのが湧くな

やっぱり、パナDIGAが一番高画質で速いと言ってみたりw

>>609
1000kbpsにしたらあっさり改善されました。
2000kbpsではWMV Pro圧縮と大差なくなってしまいますが、
これくらいならまだh.264がよさそうです。　ありがとうございました。

というかx264はcrfで使うでしょ
ファイルサイズにはこだわってないみたいだから

>>624

Doom9のCUDA関連のスレも見ればわかる話なんだけど、今のところCUDAが
あまりにも役に立たない＠エンコ。

x264のところにはこの1年で多くの人が「CUDA版が作りたい」とか言ってた
けど、CUDAは A) コード書きが面倒 B) ある場面でしかCPUに勝たない、
速度的に。これを見るとハードウェアーチップの方がマシに見える、今CUDA
で遊ぶより。まぁ、遊べば色々出ると思うけど（今まで一人も何も出してない
けどね）。

デコードだとNeuron2氏のCUDAなH.264デコーダーはある
ttp://neuron2.net/dgavcdecnv/dgavcdecnv.html
CoreAVCもDirectShowSource2ならCUDAが使えそうかも（まだ自分で182.Xな
ドライバーを試してないから（ｒｙ）。
速度的にCoreAVCのCUDAの方が遅かったけど、まぁCPUから荷物をとるためには
ありかと。Neuron2氏の奴の方が色々完成してるみたいだけど。

5年ぐらい待てば、CPUでもリアルタイムできるかもね。ハイエンドなら。
しかし、その頃には新しい規格が出来てx264自体が必要なくなるかもw

MPEG-2 Video(H.262) -> H.264と来て、次に続く規格はまだ無い。

古くて多少効率が見劣りするようになった規格でも、
普及率が高いものは案外長生きしたりするもんだ
mp3とかPCIとか

まあ、HDDが安い時間にそもそもエンコするかどうかと言うのはあるよな。
1TBで一万以下。

エンコの時間の電気代を考えると割りあわないな。

安い時代だわ。

エンコなんて趣味みたいなもんだから時給とか
現実的な物で換算するとアホらしくなる

エンコが趣味ならロスレスとか一生流行りそうにないなw
あれは設定いらずだから趣味にならない。

俺もそろそろ8コア環境揃えるかな。

x264でエンコすると
字幕とかのテロップが、かすれたような感じになるんだけど
これ何が原因でしょうか？
設定は、こんな感じです

program --pass 2 --bitrate 1200 --stats ".stats"
--level 4.1 --ref 3 --bframes 2 --direct auto
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto
--thread-input --progress --no-psnr --no-ssim --output "output" "input"

>>627
前に初心者スレの方で低ビットレートの話題あったから参考になるかもよ

>>638
VAQを使うと高周波を削るので、リンギングが出る。
--aq-strengthをデフォルトの1.0より小さな数字にするか、-aq-mode 0で無効になる。

でもAQを使って細部がつぶれるとしたら、AQって何のために使うんだよ

ごめん、誤爆

>>640
今度その設定試してみます
ついでに、比較画像を作ってみました
いつもこんな感じ

ttp://nagamochi.info/src/up28466.jpg

まあ、ソースがそれなら、テロップ以外の部分の画質はVAQを使った方が良くなるから、
--aq-mode 0は止めた方が良い。

動画は動かしてかつ最適視聴距離で確かめた方がいいよ
近くだとノイズなのが離れると細部を表していたとかあるから。（特に放送波）

「高画質」じゃなくて「バランス」を選んでるにもかかわらず
何も考えずにエンコードする分にはTE4XPのH.264よりx264の方が画質いいなー。
設定を追い込めばまた変わるのかもしれないけど。

どんなオプションよりも脳内フィルタとプラシーボが最強だからそっちを鍛えるのがいいのかもしれないな

r1115
何かバグがあったらしい。

partitions=allは使わないから大きな影響はないかな

>>646
その分速度が糞遅いけどな。

TE4XPの最高設定>>バランス

バランス(笑)遅すぎｗ

>>650
なんだよクソじゃねーか
最近まるで使ってないバッキャローのPC-MV9H/U2で
H.264リアルタイムエンコした方がまだマシだった

どんなに言ってこっちは実験済みだからな。

TE4XPと同じ速度にまでオプション軽くするとx264はくそ画質で見れたものじゃない。
と言って実用的な画質にしようとすると糞遅い。

こんな物使えません。５時間エンコとか廃人専用。

またこのキチガイか

あのキチガイは毎朝来てるな
己の無能さを恥じずにソフト批判とか

そもそもMainConceptエンジンで高画質とか言ってるあたりに無理がある。

画質とかここの住人は本当はどうでもいいんだよ。
それよりもオプションが多いのが楽しみなんだから。

エンコは趣味なんだぜい。画質重視ならそもそもエンコしない方がいいわけだし。

H.264エンコーダー比較スレッドでも建てることをお勧めする
1000ぐらいなら行くだろｗ

バランス設定って何？

Ａｖｉｕｔｌの拡張なんとか出力っての使うとあるらしいな、いわゆる初心者モード。

このスレにもニコ厨が押し寄せてきてるってことか・・・

有料ソフトで満足してるなら良かったじゃないか
使いたくないものを使う必要はないし満足いかないならもうここに来る必要もない
専用スレ比較して優れていることをこれからはそっちでカキコしてあげれば喜ばれるんでないか
ということでさようなら

TMPGEnc本スレですらそんなこと言ってる奴が居ないのが哀れだな。

てか荒らしに構うな。スルーが一番の対抗策。

フロントエンドとして中途半端なTMPGEncより、MainConceptを使ったエンコーダなら、
VFAPIを使わずにavsを読めるElecard Converter Studioが良い。

http://www.elecard.com/products/products-pc/consumer/converter-studio/

誰かこのバカにavisynthの使い方教えてやれよ

バカには無理ｗ

>>659
へー、最近Aviutl使ってなかったから知らんかった。
>>617で自信満々に罵ってるから、
拡張x264って何？ﾊﾞﾗﾝｽ設定？といった感じで困惑したわ

>>667
そもそもseraphy氏も自分では使ってなくて、オマケで更新してくれてるGUIだしね。
使ってない人のが多い。

>>665
その前に脳に空き容量があるかどうか疑問
>>1に書いてある文章が理解出来ないのだから

くやしいのうwwwwくやしいのうwwww

ふるｗ

久々にx264が更新きたな

話題のバランス設定。使ったことねぇや…。
http://nicowiki.com/%E6%8B%A1%E5%BC%B5%20x264%20%E5%87%BA%E5%8A%9B%EF%BC%88GUI%EF%BC%89%E3%81%AE%E8%A8%AD%E5%AE%9A%E9%A0%85%E7%9B%AE%E3%81%A8%E3%81%9D%E3%81%AE%E6%A9%9F%E8%83%BD%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.html#qed0f367
--crf 21 --threads auto --aq-mode 0 --bframes 16 --psy-rd 0.5:0.0 --b-pyramid --qpmin 1 --qpmax 51 --qpstep 16 --keyint 300 --min-keyint 1 --scenecut 54 --partitions p8x8,b8x8,i4x4,i8x8
--8x8dct --direct auto --me umh --merange 32 --cqm flat --subme 7 --trellis 1 --deblock -1:-1 --ref 3 --mixed-refs --weightb --no-fast-pskip --no-dct-decimate
残りのオプションはデフォなんじゃないかな？

--bframes 16…そんなに使いたくないな…。

俺GUI使ってるけどBフレ16はちょっと…

これは酷い・・・・
どう「バランス」なのかわからない設定だな
速度的にも画質的にも

--crf 22 --aq-mode 0 --psy-rd 0.5:0 --qpstep 12 --scenecut 60 --min-keyint 1 --keyint 300 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4"
--ref 3 --bframes 2 --weightb --b-adapt 2 --mixed-refs --direct "auto" --subme 7 --me "umh" --merange 32 --no-chroma-me --threads "auto"
--trellis 2 --deblock -1:-1 --level 4.1 --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim
PS3用バランス設定ｆｏｒ実写

高画質だと--ref 5 --bframe 3で逆なんだね。

--ref a --bframe b
のときに
a <= b
が必須だと思っていた。orz。

>>673
超画質のオプションﾜﾛﾀ

というか普通x264使うんなら画質重視するの当たり前だろう

この「プリセット」って同梱の「x264gui.ini」をいじくりゃ変えられるんだよね。
んでつくづく思ってるのが、このスレ住人とかでプリセットを直したり新規に作ったりして、
それをこの作者に取り込んでもらったほうがいいんじゃないかってこと。
>>676の書いた実写向けPS3用とか新規のいい例。

そもそも>>673が叩かれてる理由が理解できん
bframesってのはあくまで最大値を指定してるだけだから、
16が指定してあってもエンコが終わった後の結果を見てみれば、
結局b-biasやb-adaptの指定相応にしか使われてないことが分かるし、
>>673の設定だって、（アニメ用途としては）scenecutが少し控えめに感じる程度で
それ以外はなんてことのない、そこそこ速度も出てアニメにも実写にも無難に対応できるよう
調整された（というかほとんどデフォだが）、文字通りの「バランス」型設定だろ。

--b-pyramid はなくてもいいと思うけど別にそこまで変ではないと思う
な

>>679

> Q x264gui.auoの使い方は？
> A x264 VFW GUI専用スレでどうぞ。
> http://pc11.2ch.net/test/read.cgi/avi/1221328142/

--b-adapt 2がない時点でどうでもいい

てか古いバージョンのオプションだろ。
作者も更新する気無いだろうし。

確かにいくつかオプション作って作者に取り込んで貰うのもありと思う。
GUI版の需要は有るわけだしオプション弄る程にはエンコ自体に興味がない人が
一般的により良いとされるオプションを使う権利が無い訳では無いと思うから。

guiイラネ

別にいらんな
使う時もCLIモードで使うから必要性なし

CLIモード用の作ってiniに登録してる

だが勝手に音声の処理とかしてくれるのは便利だ。いちいちスクリプト書かなくてすむし。

--qpmax 51の時点でウンコだろ

でも実際そもまでqp上がらないだろ

--qpmax 51に設定してるがqp30越えたことねーな

>>685
単にGUI付けるくらいなら、ディフォルトプリセットの充実や
カスタムプリセットの作成を簡単にするGUIを作るべきだとは思うが
GUI要らないというのも一般的な意見としては極端すぎるな

デフォルトとしてはあんなもんで十分だろ
調整したい奴は自分で勝手にiniを書き換えればいいよ

そもそもaviutl自体が重いから、
どうしてもGUIが欲しい場合でも、avsとYV12をサポートした他のGUIソフトで
（そういうのがあるかどうかは知らんが）
cui版をコマンドライン指定で走らせた方がいいと思うけどな。

AviUtlは初心者でも手軽に使えるのが売りだからそんなもんでいいんじゃね

>>693
> どうしてもGUIが欲しい場合でも、avsとYV12をサポートした他のGUIソフト
俺は携帯動画変換君のaviのavsテンプレに ConvertToYV12() を入れて使ってる。
アレをGUIてゆーのか分からんがｗ

>avsとYV12をサポートした他のGUIソフト
avidemuxのことですね、分かります。

荒らしが巣に戻ったようでよかった
VFR氏のABCD処理AQパッチ版のテスト情報はあまりないみたいね〜
寝る前にバッチ処理してこよう

>>697
普段はカスタムマトリクスだけ弄ってaqは使ってないが、
おもしろそうだから試しに--aq-strength 0.5:0.5:1.0:0.3:0.3:1.0:0.5:0.5 --aq-sensitivity 10
こんな感じでやってみたら、
理論的にはデフォ（str0.5 sen10）よりも暗部重視で、かつ縮むような気がするのに、
サイズは縮んだが、暗部の画質がデフォより悪くなった気がした。
aqはよく分からん。

AQ-debugを待つんだ

>>673
ぜんぜん関係ないが高画質プリセットなら比較的マシな設定になってるから
初心者でも動画サイトに高画質な動画ＵＰ出来てる気がする
こんなかんじ
↓
--crf 21 --aq-mode 0 --psy-rd 0.5:0 --qpmin 1 --qpstep 16 --scenecut 54 --min-keyint 1 --keyint 300
--8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --bframes 3 --b-pyramid --weightb --b-adapt 2 --ref 5 --mixed-refs
--direct "auto" --me "umh" --subme 9 --merange 64 --threads "auto" --trellis 2 --deblock -2:-2 --cqm "flat"
--no-fast-pskip --no-dct-decimate

そんなにAviUtlって重いかな？
lanczosもwarpsharpもアンシャープマスクもマルチスレッド化やSIMD最適化が進んでいるのに。

x264はプロファイル計測してみたけど、もう簡単に最適化できるような箇所は残ってないね。

>>700
flatよりjvtがいいけどな

>>702

Adaptive chroma upsampling
http://forum.doom9.org/showthread.php?p=618364

速度云々を別にしても、完全なYV12<->YUY2の変換は無理だから、
やはりソースがYV12なら、そのままでやりたい。

http://forum.doom9.org/showthread.php?t=97987

リンクを間違えた。

>>702
アニメはflatのほうがいいよ

jvt推奨とか大昔の話だろ

何故アニメ前提なのか、話はそれからだ

実写にはVAQがあるから、やはりflatで良い。

オプションでflatもjvtもあんまり変わんなくなる

実写はjvt,アニメはflat.何となく設定。今はVAQあるのに使っている。

ソースと目標サイズ次第

実写はOreAQでflat、アニメはMixAQでflat

>>713
逆じゃね？俺はだけど

OreAQをうまく使いこなせない俺はどちらもMixAQ

容量に余裕があればflatで問題ないな

>>714
同意

アニメじゃなくても、psy-rdを使うならflat。
カスタムマトリクス練る人ならわかると思うけど、flatじゃないとマズイ。

>>701
AviUtlはYV12→YUV444 するから、速度はどうしても落ちる。 大した差じゃないとも言うｗ
ただ、がらくたハウスさん始め優秀なプラグインが沢山ある…。

重いフィルタほど差が出やすくなるぞ。つーか単純に輝度も色差も同様に処理を行うフィルタは
4:2:0と4:4:4と比較すれば計算量は2倍の差がある。さらにSIMDを使えばAviutlは16bitで演算するから
8bitで処理するソフトに比べるとさらに差が開く。大抵はエンコで最も時間食うだろうから
さほど違いが出ないと思うけどフィルタ処理の割合が増えるほど差がはっきり出る。

>>719
極限まで最適化されているならそうだろうね。
でもWarpsharpみたいにAviUtlの方が最適化が進んでいるフィルタもある。
AviUtlのWarpsharpMT 1.33ex6は1280x720の２スレッドで約0.01秒。
30分番組で44000フレームだとエンコード３時間中の８分しか使っていない。
やっぱりx264が大半の時間を喰っているだろうね。

BS氏avisynth版で作ってくれないかなorz

>>718
>flatじゃないとマズイ。
kwsk

>>722
psy-rd入れてないときに、自作>>flat でも、入れた途端逆転する。
というか、自作マトリクスの時はpsy-rdを入れない方が良かった。記憶があやふやだけど。
比べるなら、自作マトリクス vs flat+psy-rd と思った記憶がある。
以来面倒になってflat派ｗ

他のオプションの値次第だよそんなの

AviUtlは、内部的にはYUV444以上で処理していて、RGBとYUY2出力のみ対応？
らしいから、x264guiを使ったエンコード時には
YUV444→YUV422→x264guiでYUV420→x264
じゃなかったっけ

で、AviUtlのYUV422圧縮はアルゴリズムが変わっていて劣化が目立つから、
間にダウンサンプリングフィルタをはさまないと綺麗にならなくて
画質にこだわると更に時間がかかる

ってことは、AviUtlがAvisynth同等のYV12出力に対応すれば、
x264guiでの変換も早くなるし綺麗になるんじゃないか・・・？

昔は頑張ってマトリクス作れば自作＞jvt＞flatになったのに
最近じゃ自作≒flat＞jvtという具合にflat使用時の画質がすごく向上したのは俺も感じた
ちなみにソースは地アナの実写

>>725
入力でもYV12->YUY2とやるから、Synthと同じ訳にはならない。

>>725
(YV12→)YUY444→YV12　とYUV2を挟まなければ速いし綺麗って事か。
問題はYUY444にする事と、フィルタがYUY444用に作られてることなんだけどねorz
そろそろスレ違いかも

スレチだけど間違えちゃってたものは訂正しておく
×YUY444 ○YC48 ttp://mksoft.hp.infoseek.co.jp/doc/aviutlyc.html

それは本来は問題なんじゃなくて、
YUY2の16bit精度のソースに24bit精度でフィルタリングできる優秀な仕様と言える訳で
（もちろん精度が上がる分時間は掛かるが）
要するにx264の仕様が大雑把過ぎてaviutlに釣り合ってないだけなんだけどな

>>725
その情報は間違っていると思うよ。
AviUtlはYV12->YC48->YV12と入出力しても、元のYV12とまったく
同じ画素データが出力されるので、まったく劣化はしない。これはYUY2でも同じ。
劣化というか異なるデータになるとしたらRGBモードでYUV系のデータを処理しちゃうとか。

要点としては、YC48の16bit処理（12bit±2bitマージンかな？）が、
今どきの映像だとオーバースペックであまり真価が発揮されないということだろうね。
速度面ではYC48で処理している量が全体の（エンコードを含む）数パーセント程度だろうから、
速くしたいだけならx264側を弄ったほうが効果的だと思う。

http://neuron2.net/autoyuy2/interlaced.bmp
http://neuron2.net/autoyuy2/progressive.bmp
http://neuron2.net/autoyuy2/autoyuy2.bmp

http://neuron2.net/autoyuy2/autoyuy2.html

インターレースのソースの変換だと、少しややこしい。

まるもはそこらへん自動でやってくれなかったっけ？

つーかUtlの話はUtlスレかGUIスレのほうでやれよ

>>723
そうなんだ。ありがとう
psyを入れるとビットレートが食うからかなり弱めにしているのでそういう場合にはjvt使っても大丈夫かも

>>734
psy-rdなものは心理的に画質を上げようとして別にPSNRやらSSIMを気にして
いないんで、crfで使う時にはビットレートを上げる（crfは一般的に画質
（レート）をチェックしているから)。

あと、やっと昨日の宴会から帰ってきて、1115のビルドができたｗ
丁度BugMaster氏がDark_Shikari氏やらPengvado氏に話しをかけようとした
時にでかけたからなぁ… orz

>>734
気になったからやってみたよ
ソースはニモ。 なぜってアニメ以外のソースがそれしか…
crf25程度のﾋﾞｯﾄﾚｰﾄで3pass subme9+trellis2
ttp://kissho1.xii.jp/7/src/7jyou19630.png (flat)
ttp://kissho1.xii.jp/7/src/7jyou19631.png (flat+psy1.0)
ttp://kissho1.xii.jp/7/src/7jyou19632.png (jvt)
ttp://kissho1.xii.jp/7/src/7jyou19633.png (jvt+psy1.0)

動画 ttp://kissho1.xii.jp/7/src/7jyou19634.zip.html (DLkey:123456)
flat,jvt それぞれpsy0.0,0.4,1.0の三種類入れておきました

>>736
crf24,psy 0.5:0.0
ttp://www1.axfc.net/uploader/P/so/48305&key=123456
さっきまでやっていた実写。ノイズ除去などは一切なし。インタレ維持
どっちでもいい気がしてきた。flatの方が細部が残る=ノイズが強調されるという感じかな？

aqやカスタムマトリクス、psy-rdを使って細部が潰れるという奴は、
ここを読んで細部が破綻する理由をまず理解してから、deblockを調整してみろ
ttp://www.marumo.ne.jp/db2007_7.htm#24

psy-rdで細部が潰れたとは思わないし、むしろﾉｲｼﾞｰになると思うけど。
見た目の割りに全体のQ値上昇→不必要にﾃﾞﾌﾞﾛｯｸ　ということなのかな。

AQは、Q値そのものを変化させるだけだから弄る必要ないよね？

>>736
AQの設定はどうなってる？

あ、zip解凍したら中身mp4だった。
すまん。

>>738
flatのほうが好みの画質だけどなぁ

ｊｖｔが叩かれるほど悪くもないし、flatもそれほど画質がいいわけではない、ということか
つまりは好み

--aqや--psy、--crf、--trellisあたりしか弄らない人はflatの方がいいかも
糞画質になるのはその人次第

オプション設定の見本出して
比較画像とかで
解説してるサイトとかないっすか？
実写とアニメの両方あるとうれしい

アニメ専だと、えびふニャイ（どれが平仮名でどれがカタカナか忘れた）
昔は参考にしてたけど最新rev追い掛けないから今参考になるかわからん

>>743
実写だしね。 でもやっぱアニメではやめた方が…

>>744
jvt用に調整ってどこを弄ればいいん？ デブロック？

>>745
文字で説明と効果を確認したら、実際に出力するのが一番いいかも

アニメにjvtが良くないってよく聞くけど、具体的にどうダメなの？

jvtは高周波を削るからアニメにはあまりよろしくないとのこと

つまり輪郭が必要以上にボケるつーことだろ

アニメには、CQMを使うよりも、flat + trellis(もしくはデッドゾーンを6くらいまで下げる)とした方が無難。

実写で比較画像はあまり意味ないよね

あるだろ

CQMはAQ設定やソース映像次第だろ
ぶっちゃけソース毎に書くのは面倒だし難しい

まぁなんも考えなくても、flatは無難な絵にしてくれるから楽なだけ。

>>746
想像するにネーミングの方法としてエビフライの「ラ」を「にゃ」に変えたんじゃないのかな。この人。

ｈ264ってmpgみたいに全体的にノイズになるんじゃなくて
輪郭の周囲がブロッキングになる独特のノイズの出方するよねぇ
だからなんだという訳じゃないが

そら君だけ

更新無いねぇ…

>>757
ブロッキングになるかはわからんが輪郭周りにノイズが出ることがある
psyちょっと入れるだけで回避できることもある

>>758
アニメなんかでは顕著だけど、
ビットレートを落としていくと輪郭の周囲に真っ先にモスキートノイズみたいなのが出始めて
凄い見苦しくなる。だから何ってわけでもないんだが。
ttp://www.geocities.jp/elisy/u/noiz.jpg

>>760
ふむふむ

よっぽど低レートでやってるとかじゃないの？

アニメオタって画質にはこだわりがあると思っていたが
意外とそうでもないんだな。

また圧縮して劣化させるなんて。TSのままの方が綺麗だろ。

>>763
アニメが好きなんであって画質が好きなんじゃない
前にTVで見たヲタクの部屋は14型のテレビにビデオテープだった

でもここの住人は画質ヲタ多いんじゃない？

単純に「綺麗」というだけなら、TSソースに適切なNRを掛けて
ロスレスで圧縮してやったら、確実に元ソースより綺麗な映像になるな。
もちろんソースの再現性という意味では劣化してることになるが。

>>763
tsはノイズが多すぎてどうにもならん

>>766
まあ、そう言うことだろうな。エンコじゃなくて再生側に任せるという手もあるし。

まぁ再エンコードなんてしないのが一番だよ
最近ではAVアンプ自体に高度な画質調整回路を積んだものがあるので手軽に高画質を手に入れられる

ＴＳ録画しないでそのまま見た方が綺麗

TS録画の意味が分かってないだろ
地デジはmpeg2ファイルを電波で飛ばしてるようなもので、
TS録画というのは、そのmpeg2ファイルをそのままHDDに保存してるだけだから、
レコ側で変なフィルタ処理をせずに、同じデコーダを通して見るのであれば、
基本的に生放送とTS録画の映像は全く同じものになる。

TSの抜き方に依るんじゃないか？

抜くときは左手は添えるだけ

PCで何もせずに見るより、レコやTVのNRが掛かったほうがまともに見える
俺はPCで何かをして保存する派だけど

>>761
高周波成分切ると出やすいよ。　ttp://www.nnet.ne.jp/~hi6/lab/quantize/index.html

>>763
実写は再エンコ＝のっぺり　だけど、アニメは不自然でなければそれでいいから

>>771
ならないよ

777

たしかにx264はテロップ周りとかのモスキートノイズが目立つよな
全体的にはXvid使ってた頃より満足してるけど輪郭周囲のモスキートに関してはXvidより退化してる気がしてならない

x264でも、--aq-mode 0 --cqm "flat" とすれば、リンギングの出にくいフラットな量子化が出来る。

> --cqm "flat"
cqmのデフォルトはflatだろ？ナンで明記する必要が・・・？

>>780
強いて言えば、念押しの為か。

ASPでも、ここに在るようなCQMを低いビットレートで使えば悲惨な事になるだろう。

New Quantization Matrices - EQM V3 series (last update: 04/02/2005 - V3ULR)
http://forum.doom9.org/showthread.php?s=&threadid=83125

デフォ設定書いとかないと仕様変更されたときに困る

モスキートノイズはよほど圧縮率を上げない限り、目立つレベルで出てくることは
ほとんどないけど、crfを2や3下げた程度では全然消えないバンディングを出なくするには
どう対処したらいい？　AQとマトリクス、psy-rdあたりをうまく使えば出なくなるの？

http://www.megaupload.com/?d=GM7IZQR2

このサンプルを見たら分かるが、30Mbps超のBDリップのビデオでも酷いバンディングは出る。
結局、ディザだけでは不十分で、GradFun2DBmod等を使ってグレインも足してやらないといけないと思う。

BDもDVDと同じ8bitだしね。その辺は次世代規格に期待。
まあ、エンコの時点で修正してくれるか再生側で対応してくれてもいいけど。

x264も内部にデブロックとノイズリダクションを持ってるし、
同じようにバンディング除去の機能を追加してもいいよな
VRFかSeraphyがパッチ作ってやってくれないかな

バンディングを除去っていうのは本当は正しくない。
あれは実際はランダムノイズ付加してディザリングを行ってるだけ。
H.264にそういう仕様はない。フィルムグレインを制御する
オプションはあるけど目的が違うから普通はデコード時にフィルタリングさせる

psy-rdみたいにディザやグレインを残そうとするならともかく、
わざとノイズ増やしてファイルサイズを肥大させるってのは、エンコーダーとしてはおかしいよね

レグザはバンディングは階調を増やして対処しているみたいだけど
これはディザリングとは別の方法？

http://www.toshiba.co.jp/regza/function/08b/func12.html

自己解決したわ。

それもポストプロセスの一種だろ
元々のGradFun2DBと同じ方向性だと思う

ここが参考になる。まあ、他にも探したらあるかも知れんが。

http://www.adobe.com/jp/support/kb/cs/5/cs_5862_ja-jp.html

結局、現状で考えられるエンコ時のバンディング対策（再生環境は考えない前提で）としては
・フィルタリング時にGradFun2DBmod等でディザ・グレインを付加する
・psy-rdを少し強めに掛けてディザやグレインを残す（そういう作用があるの？）

くらいしか無いってこと？

deadzoneの特にintraの数値を下げるとか、deblockを弱めるとかも
当然nrは0で

次世代もYV12(YUV4:2:0)なのかね

バンディング低減は再生時にかければ問題なし

普通バンディング除去はエンコ時の前段階でやっとくべきだろ

エンコでディザが消えるから問題になるんだろ。
俺が試した範囲では暗い部分でディザかけると逆効果になった。

俺は元からバンディング除去はノイズ付加と思ってるから最初からやらないから知らんかった
すまんな

h264でバンディングが出るのって、色数が減ってるせい？
それともそのほかの要因のせいなのかね

前者なら根本的な解決はできないよな

何時の日にか、10ビット/サンプルをサポートするH.264 High 10/High 4:2:2/High 4:4:4が普及するまでは、
ディザ+グレインでごまかしておくしかない。

何に対して8ビットだっけ
YUVそれぞれだっけ？そうするとYV12であることを除いて1ピクセルあたり24ビットなような気もするけど

xv color対応したビデオカメラぐらいしかソースないもんな現状。

>>802
Y, Cb, Crそれぞれ8ビット。

>>793に加えて、
Avisynthで　ColorYUY2(level="TV=>PC",interpolation="411->422r")　と　ConvertToYV12（matrix="PC.601/709"）　を使用
x264では--fullrange on --colormatrix bt470bg/bt709　を追加

これで理論的には、多少バンディングを減らせる気がする。
実際にやってみるとあんまり変わらんかったけど。

SmoothLevels
http://forum.doom9.org/showthread.php?t=137479

私は基本的にはTVスケールのままでしかやらないが、もし、TVスケール->PCスケールをするのなら、
グラデーションの事を考えるとこっちの方が良いだろう。

>>805
それでは再生時にGPUがやってる処理の劣化版でしかないから改善されないだろうね

TSのままでもバンディングはよく見るな

そうだから、メーカーはバンディング対策をしている。>>789みたいな。

SONYだとクリアスとかそんな名前だったっけ

>>789の「魔方陣アルゴリズム」というのはパターンディザのことらしいな
http://www.toshiba.co.jp/regza/ctv/face/product/popup/d_pct/d_pct03.htm

REGZAのTS映像リアルタイム処理のチップをPCIExpressで売り出せば
一部には売れるんじゃないかとか妄想してる。

どう考えてもGENESSAの方が売れるだろ

画像ソフトでも256色に減色するときはディザかけないと
バンディングは出る。

放送もBDも大元のマスターから8bitに落とし込む時に
ディザかければいいのにな。

減色したあとのバンディング出たソースをディザかけてもほとんど効果ないしな。

減色後のバンディングが出たソースに
再生時にディザを掛けてるのが>>789やffdshowのDebandじゃん

クリアス
http://www.sony.co.jp/SonyInfo/technology/technology/theme/creas_01.html

映像にノイズシェーピングをかけられる時代になったんだな
ディザよりも高度っぽい

こういうフィルタ欲しいな

rev1119ｋｔｋｒ

<JEEBcz> http://jeeb.fiveforty.jp/x264/1119/x264.exe
<JEEBcz> there you go :)
<Dark_Shikari> you beat x264.nl

PenrynやPPCを使っている人以外は、今回の更新はスルーしても良さそうだ。

>rev1117 で core67 に更新 !
core67ってなに？

x264のコアエンジン67番目ってことじゃないの？

>>821
http://forum.doom9.org/showpost.php?p=1255146&postcount=1

なんか話題になってるから色々見てみたが、日本の家電メーカーって瀕死のクセに生意気だな
海外での競争力も低くその内大半はあぼーんするだろと全く興味無かったが、このスレのせいでちょっと欲しくなったｗ

アニオタの俺はTSからクリアス+PV3に戻ったしな、家電はバカにできん。

たしかに家のDIGAのクロマ処理もやめられない。

俺も永久保存コンテンツはX95+HDRECSになった。
て言ってもHDRECSは圧縮かかるからあまり意味ないかもしれんが・・・。

>>825
クリアスはどんなのかしらんけど、滑らかになるとバンディングが目立つんじゃないの？
エンコ前はグラデは綺麗だけどエンコするとバンディングが・・・て感じで。
家電が綺麗って話の流れは再生時に補完するから綺麗って意味でしょ？
レコからの補完された出力をキャプしてエンコしても解決しないんじゃない？
例えばBD(BDMV)に焼いたとして、PCで見ると汚い、家電では補完処理で綺麗って感じじゃないの？

>>825じゃないけど、つまり、レコ出力⇒キャプはできないかって事？

糞ニー機種を持ち上げてる時点で程度が知れてるさ

クリアスは再生時の表示前に最高のパフォーマンスを発揮する処理であって
この出力を再度キャプチャしても効果は薄いと思うよ　全く無意味ではない無いにしても

http://forum.doom9.org/showpost.php?p=1257673&postcount=1726
x264_hrd_pulldown.10_interlace.diff.txt

TSのままよりはいいとおもう。手間と時間は当然かかるけど。

x264の仕組みが変わらないとどうしようもないねぇ
265では、yuv4:4:4もサポートして欲しいのう・・・

PCだけの再生ならいいけど、互換性も考えると4:4:4はどうなんだろう。圧縮率とかすごく下がりそうだし

放送、DVD, BDと全部4:2:0だから、当分の間は、それで我慢する他無い。

要はバランスだな。4:4:4でプログレ対応なら
今のビットレートでの画質は望めない。ブロックノイズだらけの糞画質になっている。

いくらバンディング対策してもソースの問題等で限界を感じたので、
ガンマコレクションを使って暗部を目立たなくするようにしてる自分は少数派だろうな・・。
PCで視聴するのが前提になってしまうかと思ったけれど、
TVに出してみてもそれなりにちゃんと見れてるし、自分しか見ないのでまぁいいかなと。

たまたま見つけた資料
http://panasonic.co.jp/ptj/v5403/pdf/p0103.pdf

DIGAのAVCエンコーダは動き予測に16ｘ16 8x16 16x8しか使ってないとか
なかなか面白いことがかいてあったりなかったり。

8x8を削るのは理解に苦しむ。

flatからjvtにしたら画質が向上したということか。

jvtの方が画質いいしな

8x8は携帯サイズ用だろ

すまん携帯サイズは4x4だったorz

iPod touch/iPhone用の設定について教えて欲しいモナ。

>>845
http://img300.imageshack.us/img300/8063/ipodiphone.png

【H.264】iPod videoの動画スレッド★8【MP4】
http://pc11.2ch.net/test/read.cgi/avi/1235567895/

>>846
教えてくれてありがとう。

>>814
BDは大抵のエンコーダならディザや誤差拡散は付いてるので、
バンディングの原因の大半はマスターにある。
>>816
正確には、広範囲でぼかした上でディザをかけてる。
>>817
ノイズシェーピングって誤差拡散みたいなもんでしょ？
>>825
HDMIでD5じゃないとDRC使えないのが悲しい。

>>784を、GradFun2DBmod+GrainFactory3で、多少ましにしたサンプル。

http://www.mediafire.com/file/hyowonawgnw/Banding_fixed.zip

あ

>>848

> BDは大抵のエンコーダならディザや誤差拡散は付いてるので、
> バンディングの原因の大半はマスターにある

そうとも言い切れない。マスターが10bitとかをDVDやBDで8bitに圧縮・減色するから
バンディングが出るんだよ。

だいたい減色のときにバンディングが出る。

補足するとコンピュータで10bit制作した物を8bitマスターに落とし込んだら
バンディングでるかも知れんが。

>>851
エンコーダの入力〜フィルタ処理は10bitで、
内部の処理でディザつけて8bitにしてエンジンに渡してる。
例えばCCEがそう。
まあ、CCEの場合デフォルトだとディザOFFだけど。

AEとかは8bitの処理しかできないプラグインがまだ残ってるので、
処理の間にそういうのが入るとすぐ階調飛んでしまうのだけど、
現場では時間に追われて気にしてられないんだろうなあ。
合成系で、出力にディザが乗っかるのは知ってる限りじゃeQぐらい。

編集卓が若干古いとDVEが8bit精度だったりするし、
階調落とす要因がパッケージ化するまでの工程上に山とあるんだよねえ。

>>848
マッハバンド除去サービスはあるがあくまでオプションで別料金みたいだ。

http://www.imagica.com/work/package/note.html

BDオーサリングで全てマッハバンド除去をやっているわけではないよ。

>>853
その結論出すにはDLP上映の映画と比較するしかないな。
素人がマスター見る機会なんてないから。

DLP上映でバンディング出てんならしょうがないが、出てないならBDのオーサリングでの可能性も出てくる。

>>854
入力段でのディザ、誤差拡散の話ね。
http://www.cinemacraft.com/file/cchde/pdf/2008.11/hde_cat0811_ja.pdf
フィルタ設定の画像を拡大するとわかると思うけど、
DitherとErrorDiffusionってあるでしょ。

あと、バンド除去系はAEやAvidでふつーにプラグインとして売ってる。

>>856
すまんどういう結論に持ってきたいんだ？BDとDVDは悪くないマスターが全部悪いって言いたいのかな？
それは、>>855で言ったとおりマスターの確認は素人では確認できないからDLP上映で見るしかない。

TVに映すとき、HDMIとD5は4:2:2出力になるの？

>>855
アニメに関して言えば、元からしっかりディザかけてる作品もあれば、
ノイズレスでもバンディング出まくりなものもあったりで、割と極端。

カメラやフィルムで撮影すると、その時点でランダムノイズが混じるから、
十分なディザになっちゃう。
ので、極端な色補正や合成しない限り問題にならないかな。

>>857
うーん、単なる与太話。
マスターは沢山見てきたよ。

まあ、何にせよマスターが10bit階調ならエンコードする時に
必ず>>854のサービス？を行わないとマッハバンドが出るってことだな。

r1123
何か高速化したらしい

>>861
そじゃないよー。
>>854は出てしまったバンディングを低減する為の処理。
ディザや誤差拡散と言うのは、階調落とすときに
バンディングが出ないようにするための処理。
正確には、ディザは前処理で、誤差拡散は減色処理そのものだけど。

で、最初の段階で十分なディザを乗せてしまえば、
よっぽど極端な処理をしない限り、
お茶の間のテレビに映るまで階調は維持される。

>>862

holger氏の高速化パッチだね。大体10%ぐらい速度アップかな？
(公式で「Overall performance boost is up to ~15% on 64-bit Conroe.」
って書いてあるけど）

Overall performance boost is up to ~15% on 64-bit Conroe.
って神アップデート？

32bit時は上がり幅少ないみたい

b-pyramidって使わないほうがいいの？
p4x4って使わないほうがいいの？

>>867
ハードウェアとの互換性を重視するなら、それら両方とも、使わない方が良い。

エンコ後のレポートで、

x264 [info]: mb I I16..4: 33.8% 53.7% 12.5%
x264 [info]: mb P I16..4: 10.6% 11.3% 1.1% P16..4: 46.1% 5.1% 6.2% 0.0% 0
.0% skip:19.7%
x264 [info]: mb B I16..4: 0.7% 0.9% 0.1% B16..8: 21.8% 0.4% 0.4% direct:
1.5% skip:74.1% L0:38.8% L1:58.0% BI: 3.2%

Bフレーム内訳の最後に出てくる　L0:38.8% L1:58.0% BI: 3.2%　この部分はどういう意味なの？

L0=表示順で過去のフレームを参照している/L1=表示順で未来のフレームを参照している

だったと思う。BIについては分からない。

Bピクチャにおける予測方式でL0が前方向予測、L1が後方向予測、BIが画面内予測。
たぶん双予測やダイレクトモードを除いたMBに対しての割合なんだろうな

ffdshowのx264でDeblock使ったときのバグって解消されてたっけ？
以前、一部のブロックが歪んでしまってたことがあって以来使ってないんだけれど。

前VFR氏がffdshowでH.264のデコードでハッシュが一致しない件を
報告して修正されたと聞くが。

>873
なるほど・・ｔｈｘ！

今見返したらまだ別のバグがあるらしいｗ
まともに使えるのがCoreAVCProだけですか。

>875
orz
情報ありがとうございます。

TSは60iらしいが、x264でインタレ解除すると30fpsになるんだけど。
60iでインタレ解除したら30pになるって言う認識でおK？

>>877
x264でインタレ解除したんだ。すごいな
別にTSに限ったことじゃないけど
30fpsになるか60fpsになるかインタレ解除の方法にもよるね
それに思いっきりスレ違いだし
ttp://e-words.jp/w/60i.html

インターレースのソースは、>>832のパッチで、--vbv-bufsize 31250 --vbv-maxrate 25000 --nal-hrd --tff
としておくのが楽。

>>877
あっているよ。

>>875
デコードでの検証方法が間違っていました。謝罪。
しかし、ffdshow, DivXとCoreAVC, CyberLinkのデコード結果に違いがあるのは間違いないです。
報告時の検証方法は出力色空間が統一されていなかったので, (すっかり忘れてた)
デコーダの補間方法とは無縁なYV12に統一させて出力させたところ
ffdshow(ffmpeg)=DivX
MPCHC(DxVA)=CyberLink(DxVA)=CyberLink(software)=CoreAVC
となりました。(徐々に破綻していくのは前者です)
もちろん、デブロッキングフィルタを再生時に意図的に切っているわけでもなく、
ffdshowのレジストリがオカシクなっているのか？と一度全部削除したり、
SIMD命令を切ったりしてみましたが、結果は変わらず。

エンコードあってのデコードなので
もしかしたらx264が何かしらバグを持っていて、後者らが上手くエラー耐性ツールで補正(隠蔽)しているのかもしれませんが、
現状、ソース・オプション次第ではキーフレーム間隔を短くしても十分に大きく破綻しうるので、結構大きな問題と認識しております。
もっとも、自分の用意したソースで破綻するから前者が間違っている！というのは私の勝手な感想であり、実際は逆なのかもしれません。
なお、エンコード時にno-deblockしたソースに対しては全てのデコーダでMD5が一致しているので、デブロッキングフィルタ周りのバグだと思います。

>>881
ffdshowの遅延時のH.264ブロック低減スキップは切った？

>>881
x264以外のエンコーダ(DivX 7, Nero等)でも試してみたら。

>>881
暗めで動かないシーンとか長く続くと徐々に破綻していって
keyint間隔過ぎると急に綺麗になって違和感バリバリなことがあるんだけど
それのこと？

それのことだな。これ結構前から問題なってるけどなかなか改善されないな。

暗部のざわざわして破綻するのはAVCの弱点であってデコードのせいではないはずでは？

r1125

>>886
AVCの弱点ではなくx264の弱点だろ

>>886
それと>>884のは違う気が

>886
884の現象は
映像の一部分等に徐々におかしなブロックノイズ(アーティファクト？)が現れてきては消える
ってやつですので、ざわつきとはまた別の問題です。

>>889-890
確認したいのでソースがあれば提供してくだされ。

>>881

非常に気になったので、rev1123とCoreAVC 1.9, ffdshow-tryouts rev2653と
もう少し古くなっているffmpegsource2で試してみた(前者はDSS2()を使用して
後者はffvideosource()で。スクショはAvsPのPNG出力を使って作りました)。
ソースは http://zoome.jp/jeeb/diary/7/ で、ビットレートを強制的に
zoomeの制限に合わせてるからデブロック機能も動いてるかと思います
（違ったら（ｒｙ）。DxVAはバグが多いし、使用していません。

結果は次の通りでした:

http://fushizen.eu/a/tayutama/decodertest/

1277_coreavc19.png cce2afd3ceda37645abe369752a535d4
1277_ffdshow.png cce2afd3ceda37645abe369752a535d4
1277_ffms2.png cce2afd3ceda37645abe369752a535d4
229_coreavc19.png cda90458e736d3ac4a612b4c464a8f2d
229_ffdshow.png cda90458e736d3ac4a612b4c464a8f2d
229_ffms2.png cda90458e736d3ac4a612b4c464a8f2d
2337_coreavc.png 4fb517ef8406499381b508e72763d32d
2337_ffdshow.png 4fb517ef8406499381b508e72763d32d
2337_ffms2.png 4fb517ef8406499381b508e72763d32d

ご覧の通り一つになっています。全フレームではないが、まぁテスト
したければソースは置いてあるし、ご自由にどうぞ。

結論: デコーダーが古かったか、ソースをエンコードしたx264が古かったか
（少し前にDeblock関連のバグがBug_Master氏の報告によって直された）、
比べることに使用されたソフトが悪かったか、オイラのソースかオイラが
選んだフレームの方がダメだったか。

>>892
そんなんだよな。
x264のデブロック不具合はBug_Master氏の報告により
rev1115でフィックスされているから恐らくこの問題は発生しないと思う。

俺が試した範囲でも同一フレームのハッシュで同じ事を確認した＞CoreAVC1.9pro、ffdshow rev2737
# DxVAは自分も信用していないのでチェックはVMR

>>884
キーフレーム間隔が異様に長く、かつIピクチャのブースト値が高くBピクチャの
劣化度も高いとそうなるよ。
BフレームサポートのMPEG系なら少々違いがあれど似たような傾向が出る。

石田晴久氏が死去、日本のコンピュータ・ネット研究の第一人者
ttp://internet.watch.impress.co.jp/cda/news/2009/03/09/22718.html

この人の本でプログラミング勉強したわ。お悔やみ申し上げる。

K&Rを訳したひとか。あの本でＣの勉強したっけ。

VFRmaniac氏のページが面白い事になってるが・・・

>>896
　　∧＿∧
　 (´･ω･｀)　　 　　n
￣　　 　 ＼　 　 （ E）
ﾌ アフィ /ヽ ヽ_／／


こうですか？

このサイトはコンピュータに損害を与える可能性があります。

攻撃サイトとして報告されています！

この Web サイト (www.esnips.com) は攻撃サイトであると報告されており、セキュリティ設
定に従いブロックされました。

攻撃サイトはあなたの個人情報を盗んだり、コンピュータを乗っ取って他のコンピュータへの攻撃に利
用したり、あなたのシステムを破壊するためのプログラムをインストールしようとします。

一部の攻撃サイトでは意図的に有害なソフトウェアを配布していますが、多くのサイトでは運営者が
知らずにまたは許可なく有害なソフトウェアの配布に不正利用されています。

そんな危険なところには見えないけどなｗ

どうしても突撃したいならクッキーやJavaScript全OFFで突っ込め

用心に越したことはない

うちのカスペルさんは何も言わないけどな

それより>>881はVFR氏だった罠
俺は氏の質問に氏のBlogの情報を使って答えてしまったのかorz

俺もあとで実験してみよう

例えば、無圧縮の静止画を

無圧縮の静止画、ロスレスAVC(4：2：0)にエンコ、BD相当40Mbps(4：2：0)にエンコ

で比較するとやっぱり違いがあるなと実感。

r1027

そういや俺の通ってる高校の生徒会のサイトが
googleに怒られたことがあったw
無論危険そうには見えない。数日で直ったけど。

r1127
ふ…nlsharpenとprefilterのネイティブMTプラグインを１年以上待ち続けてるぜ…

ｽﾏﾝごば

OreAQ使うとなんか動画のコントラストが高くなってる気がする・・・

ねーよｗ

ところで、PC再生用にTV⇒PCスケール補正しているのかい？
それとも、TVで表示することも考慮して補正なしとか。

補正するなら再生時にプレイヤー側でやればいいじゃん

そのプレイヤーのスケール補正がしょぼくて困っているんだよな。

video_full_range_flagを読めるCoreAVCやffdshowを使って、RGBで出力すればいい。

使ってるグラボがRADEON系ならCoreAVCでYV12出力→GPUでRGB変換がセオリーだろ。
（MTデコード→HWによる10bit精度での色空間変換で、早くて綺麗で低負荷）
ゲフォだったらCoreAVCで同じようにYV12出力したものを、
ffdshow raw videoを挟んでRGB32変換（SWによる10bit精度の変換）してから出力する方法がいい。

ただ俺としてはRADEONよりffdshowの色空間変換の方がなんとなく丁寧な気がしてるから、
RADEONを使ってても結局、ffdshow側でRGB32変換をしてたりする。

Radeonでyv12とかありえないだろ

CoreAVCのNV12はちょっと？うちだとrawでffdshowのフィルター挟もうとすると
フレームがやたら飛ぶようになるしYV12より良いように見えない。
ffdshowだけでやるならNV12だけど。

>>915
ラデのYV12 to RGB はいいぞ
新しめのGPUでオーバーレイでないと10bit処理にならないけどな

Radeonの伸張や拡大処理は綺麗だよ。
ただSD解像度だと色伸張してくれないのは勘弁してほしい。

レジストリ弄れ

RADEONだったらYV12よりはNV12のほうが相性いいらしいよ

地デジ実写をフルでx264エンコードしています。
1080iを1080pしていますが、途中動きのないCGのアップで、チラツキが残っています
妥協して、1080Pで残すのと、インタレースを保持したままの1080iで残すのは
どちらが適当でしょうか

画面にチラシキになっております。

ちらつくのが嫌なら、MCBobやMVBobが良い。

上のほうでH.264デコーダーのデコード比較やってて俺もやってみようと思ったのだが
MPCHCのDxVAとかCyberlinkのデコーダーでどうやってYV12出力するの？
どうやってもYUY2でしか出てこない･･･

DXVAだからじゃないの

>>921
動画はソースから極力いじらないのが基本なのでインタレ保持に1票
（もちろん好みの画質に追い込むのを否定するわけじゃないよ、エンコは個人の趣味だから)

>>918
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{YOUR GUID}\0000
に文字列エントリ"UseBT601CSC"を新規作成して値を1にして再起動してみそ

>>921
インタレ保持の方こそ妥協だと思うよ
事前に確認することは何も無いし
余計なフィルタ処理が無いからエンコは速く終わるし
事後もいちいち解除漏れや動きのカクツキ具合を確かめる必要も無いし
何も考えずにvector adaptiveで再生すりゃ、同じ60fps再生でも60pより容量は少なくて済むし
しかも静止部分がちらついたり、斜め線がギザギザになったりしないし
楽をしたい人間がやるのにうってつけで、エンコするのが趣味という変人の風上にも置けない無気力行為

俺は妥協ではなく最適解だからインタレ保持をする。手間をかければ
何でもいいわけじゃない。インタレ保持が手抜きできるとは思わないし。
プログレッシブのときと設定は変わるし地デジソースだと画質改善にフィルタ使うけど
そのかけ方も気遣うし。容量節約のためってのは当然それもあるけどわざわざ60p化して
エンコする理由も無い。インタレエンコしたらそれをどうやってプログレッシブ化してみるかという
楽しみが一つ増える。プログレッシブ化してしまったらあとで別の方法が試せなくなってしまうではないか。
当然だけどテレシネ素材は24p化するけどな。

プログレ化がエンコを趣味とする人の楽しみの一つではないか。
オリジナルのままがいいならエンコしなければいいわけだしｗ

インタレ云々はインタレスレ池よ
ttp://pc11.2ch.net/test/read.cgi/avi/1186448899/

プログレ化はマゾってことでFA

目に悪くて携帯機器にやさしくない、
TV利権おいしいですな連中がディジタルにまで持ち込んだ
アナログ時代の遺産に引きずられるってのは空しいもので。
http://furukawablog.spaces.live.com/Blog/cns!156823E649BD3714!4256.entry


それはいいとして（よくないけど）本題。

その1。ゲーム素材でkeyint=fps×10、keyint_min=1で
新しいscenecutを色々試した結果、
-1よりも0よりも100から20までよりも、
1がSSIMもPSNRもよくなった件。
今まで無駄にIDR入れてたってことですか。それとも数字だけが全てじゃない？

その2。特にオプションは変えてないのに、
手元で確認できた範囲ではr1101までは問題ないけど
r1120以降でエンコした動画が
おかしなフレーム順（1→2→4→3→5→7→6→8→…）で再生される件。
AviUtl拡張x264(GUI)プラグインでエンコ、高負荷なFlashPlayer上で再生時。

>>929
再生時のリアルタイム処理がどこまで高度になるのか、
それにかけてみるのも男のロマンだと思うｗ

エンコ前のプログレ化にロマンが無いって意味じゃないけど。

放送のソース映像が60iならインタレ保持だが
24pソースなら逆テレシネするのが普通じゃね？
混合してたら適当にどっちかに合わせることになるが。

おもちゃに普通とか常識はないよ。
みんな好きに弄くっているだけ。

scenecut変わってるのに気付いてなかった orz...
誰か解説して下さい。

Remove pre-scenecut from fprofile commands as well
Also add psy-trellis to fprofile

>>937
自分でコンパイルをしないのなら、別にそれらは気にしなくても良い。

>>937
そのx264r1120は開発者用らしい。
x264r1117での変更点を気にするならまだわかる。

自分はこちらの翻訳頼み。本当に感謝。
http://up-cat.net/cgi-bin/wiki/x264%252Dchangelog%252Djp%2Br1000%252Dr1999.html

あぅ、tarball取ってきてdiffしなくても、それなりに解説してくれるページがあったんだ・・・

俺は、だいたい3行ぐらいなので流し読みしているな。
分からない単語もたまにあるのでその時は辞書みるけど。

あと、確認の為に一応翻訳サイトの訳も見てみるｗ

これ滅茶苦茶すげーですね

なにがすげーんだよ

リビジョンの更新速度かな？
毎回使い始める前に、changelogをチェックするクセ付いた。自buildはとうに諦めｗ

最近更新ないねぇ…

と思ったら更新された

きてねえよ

ttp://git.videolan.org/gitweb.cgi?p=x264.git;a=summary

r-1128になるのか？

i7でかなり早い
オヌヌメ
x264 Rev.1128 core2[Yorkfieldコア]最適化ver.
HTTP://resic.laburec.net/

x264ってyuv4:4:4には対応してないんだっけ？

ffdshowやflashのような再生側は対応してるんだよね？
色のにじみとか地味に気になるから、4:4:4には対応して欲しいなー・・

4:4:4はLosslessだけ

そうなのか・・・
レスサンクス

>>952
Losslessなら4:4:4なの？　どのx264でも？
Losslessでも4:2:0になるとばかり思ってたんだけど。

losslessにしても結局入力はYV12なんだけどな

AviUtlでもPixelYC出力プラグイン見つけたから
もしかしたらって希望を持ちかけたけど。
>>955
そこが固定かorz
thx

赤とかの斜線→4:2:0で階段化はどうにもなぁ…。

4:2:0だからファイルサイズも小さくてすんでいるっていうことも忘れてはならないよ

たまにYUV4:4:4が欲しいって人が出るけどソースをどこから入手するんだ？
放送もディスクも民生録画機器も今のデジタル映像媒体はほとんどがYUV4:2:2以下、
MPEG系フォーマットを使う媒体じゃYUV4:2:0じゃないかと思うけど

Aviutlでバンディング低減を掛けたプレビュー画面そのものが欲しいんだろ

>>958
ゲームの映像・キャプチャ
こればかりはRGBフルカラーかYUV444でないと悲しいことになる

今年もx264のGSOCに色んな色空間に対応させるようなプロジェクトあるんだね

必要であれば、参加してもよくない？って思う。CやらASMできるなら。

自分は未だにCだと初心者なので絶対ムリｗ　そして、ようやく大学から帰って
rev1128を（ｒｙ。

PCだとクロマアップサンプリングもしょぼいよね…

早めに次スレ立てる

p2不便ですね
> ＥＲＲＯＲ - 593 30 sec たたないと書けません。(1回目、28 sec しかたってない)
10秒規制どこ行ったんだ、わけわからん

x264 rev21
http://pc11.2ch.net/test/read.cgi/avi/1237400885/

(´・ω・`)

前スレage

r1129

mp4コンテナにmp3が使えないのが残念だなぁ
低いビットレートにおいてはAACの方が音質は良いんだけども
高ビットレートではmp3に軍配が上がるんだよねぇ

そこでmkvですよ。
もっと普及すればいいのにねぇmkv。
PS3のサポートとかも簡単だと思うんだけど…

mp4コンテナにmp3使えるはずだが? FOURCCは".mp3"。

どうせカットしたAACをそのまま使い回すから、MP3はもういい。

いまだにMP3のほうが高ビットレートに強いなんていってるやついるのか
情報弱者にもほどがある

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

とありますが、編集できるフリーソフトやらaviutlプラグインとか出てますよね。
やっぱりここの猛者達のお眼鏡にかなうソフトは
まだ無いってことですかね？

既存のツールでも十分に満足してます
たしかに手間はかかるけど、それでも色々なツールを作ってくれた方々には感謝しまくりです

>>973
スレ埋乙。テンプレに文句があるなら、そゆカキコにしたら？「お眼鏡」とか書いてないで。
Yamb等MP4Box関連についてならテンプレにURLあるし、AviUtlのプラグインてSeraphyさんトコの
事いってるなら、それもテンプレにURLがある。
つまり、
> 編集はエンコード前にするのが常識。
ってのに食いついてるんだろ？

>>968
耳おかしいんじゃないの。

>>974 私も感謝してます

>>975
単純な疑問だったのですが、怒らせてしまったようですね。

スコティッシュフォールドな>>968がいると聞いて

>>977
そもそもそういう需要が一番多いのはダウソですから
ソースは消しちゃっただの、友人に頼まれただの、ゲロ以下の臭いがプンプンする言い訳しながら
しつこく聞いてくるのが多いのですな

>>979
日本語でおｋ

mp3は普通にmp4に格納できるだろ
mkvはDivXが採用してきたからPS3でも対応しそうだけどなー

mkvｺﾝﾃﾅはPC向けだよ。家電で対応するには自由度が高すぎる。

http://www.baycraft.jp/popcornhour/
http://westerndigital.com/en/products/products.asp?driveid=572
mkv対応家電

mkvをmo4に詰め直すのって結構めんどくさいな。
mp4→mkvは簡単なのに。

> mo4
って・・・ナニ？

typoだそれくらいわかってよ。IYHスレでもないんだし。

>>983
　家電って単語が言葉足らずだったな。要はそれが一般に普及するの？ってこと。
ｵﾀｸならまだしも、一般人はmkvが再生できるという時点で、中のｺｰﾃﾞｯｸとﾌﾟﾛﾌｧｲﾙがどうとか頭にあるわけない。
周囲の人間にたまに言われるけど、「動画が視れない」ってそういうﾚﾍﾞﾙ。
拡張子は？って訊いて答えられれば良い方。
　あと、mkvで保存している人がどれだけいるのかという事はさておき、
mkvを選択する人は個人的に現状考えられる最高のｺｰﾃﾞｯｸと設定を組み合わせて保存するみたいなところがあるから、
ﾊｰﾄﾞの制限がどうしても出てきやすい家電が入り込む余地があるのか疑問。
それに合わせるくらいならmkv選択する意味がなくてPCで良いじゃんとなるしね。
　正直、WDのやつ知らなくて一瞬欲しいと思ったけどmkvは再生できないものが結構あるからいらない。

ISOで正式認証されたMP4コンテナともともと独自規格のmkvじゃ
家電メーカーとしてはサポートに消極的でも仕方ない。

リファレンス実装がLGPLだったはずだし、色々難しいだろうな>mkv

牛のネットワークメディアプレイヤーは割とがんばってると思うけどね
まぁ牛品質ではあるけど
やっぱ再生用にPC一台が妥当なとこだと思うけど

MP3はほとんどのプレイヤーで再生できるから使い勝手がいいだけだよな

特にニュースもなく、情報共有する事柄もなく、雑談には反応するのは
かなりこのスレも末期だな。

1000近くなんてこんなもんさ

ということで埋め

昆布

うめ

次スレ
x264 rev21
http://pc11.2ch.net/test/read.cgi/avi/1237400885/

＿,,__
　`ー'-`==､､,,　　　　　　　　　　　　　　　　　　　　　　　　　　　　　木毎
　　　　　　　　 `''=-;,,,;=;,,,　　　　　　 ,--､　, -､
　　　 , -, --､,,=''"　 〉ﾊヽ=-___　　　（　　Y　　ﾉ　　　
　　　 `ｰ(i--;ヽ__）　/(⌒ Ｙ~　　)=,(⌒ヽ>=ヽノ
　　　　　'''''ン)､）　/（　　 ﾉ!!! ⌒)､,,, -=--,,,,-､ヽ ,__
　　　　　　　　,ﾉー,(､`ヽノ''''' ）､_ﾉ　 　　／ヽ／ｰ､(⌒ヽ､,-'⌒)
　　　　　　　 (~　!!!!`ヽ^ヽ,､ﾉ　 　(⌒i／)　　(__,,ノ!!!`ｰ,-',, __ﾉ⌒）-､
　　　　　　　　`-' `ー'　　　 　 (⌒''ｰ'､/-,, 　（　　;'' `-/　　）ミ::<'''__,）
　　　　　　　　　　　　　　　　　 `ｰ::彡) ヽ＼　`ｰ'（）　`'`~（　　）､）ﾆヽ__
　　　　　　　　　　　　　　　　　 　 `ー'ー'`ｰ'　　　　　　　　`'`'　 　　~ー`==ﾆ

うめ

うめ

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