x264 rev25

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?t=130364 (Current Patches, Where to get them, How they affect speed/output)
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:x264、mencoder、xvid_encrawのGUI)
http://kurtnoise.free.fr/mp4tools/　(mp4box)
http://yamb.unite-video.com/　(YAMB)
http://bunkus.org/videotools/mkvtoolnix/　(MKVToolnix)

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

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

テンプレ続く>>2-4

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

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

インタレ規格の話題は
インタレ解除しないスレの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/

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 -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 -o "%1.264" "%temp%\avi.avs"

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

>>1
カツカレー

前スレの>>5でweightpとStrictDPB待ちと書いた者だけどまだかなまなかな

>>1乙
最新のrevision追っかけるのをやめて静観してる

>>6
strict dpbは1296で入ったじゃないか

r1301

1301＋nal-hrdパッチのバイナリがほひぃ

>>1
乙です

>>10
＞r1301でのnal-hrdで困ってます。何が困ってるかというとi_dtsのリネーム。
＞rev1296でi_dts使うことはなかっただろうに、何故にこの変数名にした。適切な別名が思いつかん。

という問題が発生しているようです。

POP氏はもう
・x264-r1301-nal_hrd-pic_struct-v8.diff
なるパッチをあてているようですね。変数どうなさったんでしょう。

もうすぐ公式に取り込まれるんだからそれを待とうぜ

>>12
別のパッチだからねぇ、失敗してたのはTrahaldのRev16ベースの奴。

>>13
確かに公式を待つのが一番いいんだけど、nal-hrdを使用したい人がたくさんいる
から未だにtrahald氏のrev16なnal-hrdパッチが更新される運命に…

Availから公式にその機能が入ると聞いた時はそれを待って、それまでの間は公式の
64ビット版だけをビルドしようって思ったけど、結局必要性があって今の有様で
ございます OTL。

というか、一番疑問があるところは、nal_hrd-pic_struct-v8ってパッチは今
マスタリングソフトに読み込めるようなストリームを作ってるかっていうところ。
Doom9は「rev16マンセー」って気分だし。あとで聞いてみる…しかないか。

Blu-ray compatibleだと言う、--b-pyramid strictが追加されているな。

MMCOって何？

>>16
ホント使えない
の人。

Memory Management Control Operations

それは何をするものなの？

ググれカス
消えろ

b-pyramidとmbtreeは併用出来ないけど、今回のb-pyramidの更新で、
どっちを使用した方が画質が上がることになるんだろうか。
効能としては別のものだから、向き不向きがあるかもしんないけど。

>>21
そういやどっちも使ってないや。

そして、b-pyramid strictとnal-hrdを併用すると、x264がオチるという罠。
nal-hrd必須な自分的には、mbtreeを使うか、使わないかの選択だなぁ。

　

そろそろ、H.265が出て来てもいい頃かなと思っている今日この頃
もう、H.264の仕様決定から5年ぐらいはたっているだろうし

>>21
b-pyramidは画質が上がっても、mbtreeで得られる画質アップに比べるとかなり
小さいというか、殆どない。

つまり、出来るだけmbtreeを使って、フェードなどで画質が悪化した部分とか
あったらその部分だけをmbtree無しでエンコするのもいいかも。あと、特に
アニメソースの場合は、rc-lookaheadを上げるとmbtreeを管理するエンジンが
もっと遠く前にフレームを検査するようになるんで、画質に関わるポイントでは
ある。現在の上限は250みたい（ソースで固定されてる）だけど、それは--keyint
以上にrc-lookaheadを上げても意味がないという意味なんです（現在のGOP内で
最もいいマクロブロックツリーを検査しているからです）。

>>22
mbtreeは自動で有効になる、--no-mbtreeを使わない限り。

フェードの劣化はいつになったら改善するんすか

>>26
部分的にエンコしてもオプション違ってたら結合できないのでは？

>>27
ドナルドが駅ですっぽんぽんしたら自動的に改善します。

真面目に言うと、weightpが完成になればよくなるはずなんですけどね。
作者のDylanZA氏が自分の大学で論文を書き終わったっぽいし、最近活動再し始めてる
なので、期待しちゃってもいいかも。

>>28
大体大丈夫のはず。特にmbtree/no-mbtreeとだけ変えれば、オッケー。
mkvmergeは一応warningを出すけど、設定がある程度同じであれば、失敗した
結果は見たことがない。

>>25
H.265というよりはNGVCと呼んだほうがいい
または、MPEG系と統合されると予測するならHVC（AVCの次）かな

H.265は全く新規のつもりだったけど計画自体が揺れていて
H.264＋α的なもの(NGVC)にしようかという話になってる
そうするとMPEGのHVCと内容が被るから
H.264/AVCみたいにH.NGVC/HVCにしようかという流れ

NGVCが正式に勧告されたときにはH.265という名になるかもしれないが
とにかく当初の予定からはかなり狂ってる

>>30
おおお暇があったらやってみよう
しかし2〜3秒のフェードのために部分エンコして結合ってのもなあｗ
素朴な疑問なんだが初期ディレイカットはどうすればいいのかな？
b-pyramidやbframes使うと1〜2フレずれるけど
a+b+cという風に分割した場合、bやcのところで更にずれるんだろうか？

>>32
最初に全部エンコードして→悪い部分があるかどうかチェックする→AvsPとかでシーンチェンジの
タイムコードをチェック→タイムコードをmkvmergeguiのカッターのところに入れて
→GOP単位で分けられたMKVをGET→再エンコが必要なところをチェックして、
入力に使ったAVSファイルに必要なところにTrimを入れてそのフレームだけ再エンコ
→悪くなってた部分が終わるまで繰り返す→mkvmergeguiのメインタブのAppend
機能で分けられたストリームのMKVをくっつける→音声をMUX→？？？→完了なのです〜

こっちでこういう方法を使ってたけど、これで普通にGOP単位でカットしてる
から別にそこまで細かく考えなくてもおｋかと。

>>26
b-pyramidとmbtreeの比較に関しては同意だし
rc-lookaheadの定義もその通りではあるけど

rc-lookaheadはとにかく上げるのがいいって思想はなんかなぁ…
まぁplacebo使うような人はどんなに重くなろうとも
1byteでも削りたいのかもしれないけど
開発陣も「そんなに上げてもあまり意味ないのに…」って雰囲気じゃない？

>>28>>30>>32
試してないけど
AQをONにしてればmbtreeがON/OFF混在してても
恐らく原理的にデコードには問題ないと思う

AQもmbtreeもMBごとのQPを変える処理で
内部的にも同じ変数を共用してる
デコードに必要なのはAQやmbtreeが使われたということではなく
せいぜい「MBごとにQPが変わる」という情報だけのはず
そのようなフラグが実際に存在するかは調べてないけど
AQがONになってればそのフラグが書き込まれるだろうから
結合できると思う

>>34
その通り、基本的にそれぐらいに上げるともはやプラシーボにしかすぎないｗ
まぁ、設定を説明してみた、という感じなんですかね。どれぐらい上げるとか、
それはもうユーザー個人の判断で決めなければならないと思ってるんですから。

>>31
その電波は残念ながらイミフすぎて受信できないわｗ

元の>>21の質問にもちょっと答えてみると…

b-pyramidは概ね、Bを1〜2枚増やすかどうか、程度の効果だと
以前にdoom9のどっかで語られてたはず
sharktooth氏はBを1枚増やすほうがいいと言っていて
DS氏はb-pyramidの方が効果があると言っていた気がする
もちろん基準とするBの枚数によって違うけど
3〜5枚くらいでの話だったかと思う

確かb-pyramidは仕様を守ってないとか言う話題で
今回のstrict-dpbに関連することだったと思った
x264ではb-pyramid時のrefの解釈が間違ってるとかなんとか…
お暇な人はdoom9から探してみてくださいな

個人的には、動き補償の関係で基本的にb-pyramidのがよいかと思う
動きの少ないクリップとアニメではB+1も効果高いかもしれないけど
b-pyramidは圧縮しにくいところに効くのが有利
ただこれまでは規格適合性の問題と再生機器を選ぶことから
使う気にはなれなかった

（>>38の続き）
mbtreeの効果は示しにくいけど
SSIMの変化を考えればBを1〜2枚よりはあると見るのが
妥当じゃないかと思う（個人的意見だけどね）

イミフって言われちゃったょ（´・ω・`）

weightpでもいいしaq-mode 3でもいいからとにかくフェードなんとかしてくれ！
8月からずっと待ってるんだが…orz

まあ別の意味だろうけどaq-mode 3はパッチ版の話だな
今はAQ2modだけどな

b-pyramidはPSPでカクカクになるから使ってないよ

x264-p-frames.git
http://repo.or.cz/w/x264/x264-p-frames.git?a=shortlog;h=refs/heads/gsoc

x264_fix_float_point_exception.r1185.diff BugMaster
x264_custom_strtok_r.r1185.diff BugMaster
x264_thread_pool_v2.2.diff BugMaster
x264_AQ2mod.diff BugMaster
x264_k.85_restore_console_title.1259.diff komisar
x264_k.76.k_Cosmetic.03.diff komisar
x264_aq_cssim.3.r1259.diff komisar


x264_r1326+206hMod.7z
Coer2以降用(-march=core2 -msse3)
http://firestorage.jp/download/457dc8db0283084b181623ed4457f2824ac2be03

あれ？
b-pyramidとmbtree同時に使えるようになったんだっけ？

>>43
こっちだとnormalで再生不可能だった。strictで試したら1GOPも再生できずに
エラーが出た。

まぁ、前と同じ情報で、結局対応してないってことになるねぇ。そこまで
いい結果にならないし、mbtreeへ頼った方がいいかと。

>>45
なってない。ショートログ読めば書いてある。

--no-mbtree　うまいです＾＾

>>44のバイナリは一体…と思ったら（一部が待望の）weightpですか

>>48
まだ開発中なので、スタンダード通りエンコされてないH.264ストリームとか
出てきても泣かないように。

色々なハードウェアで試してみてレポーティングするのも使用者の務め

>>44
エンコード開始と同時にエラーorz

>>51
パッチ無しでも落ちるみたいなんで、削除します。

>>50
そもそもCoer2以前なんで以下略

x264-p-frames.git

x264_fix_float_point_exception.r1185.diff BugMaster
x264_custom_strtok_r.r1185.diff BugMaster
x264_thread_pool_v2.2.diff BugMaster
x264_AQ2mod.diff BugMaster
x264_k.85_restore_console_title.1259.diff komisar
x264_k.76.k_Cosmetic.03.diff komisar
x264_aq_cssim.3.r1259.diff komisar
x264_me_prepass.diff Dark Shikari
x264_fgo.diff Dark Shikari

x264_r1326hMod.7z
Coer2以降用(-march=core2 -msse3)
http://firestorage.jp/download/ef42b31ca610e792bd9fa31318fd0846c3b3fa08
今回は落ちない。確認済み。・・・開発途中版なんで何があっても知らない。

k-meansが…
http://repo.or.cz/w/x264/x264-p-frames.git?a=commitdiff;h=baa3fdd9b3c37e0911e8922ae0698d5c56b1ae8e

>>54
落ちずにエンコード始まりました
weightp外されたんですね

何でkmeansなくなったんだろう

k-meansってどんな機能？　これまで一度も使ったことがないんだけども

DylanZA氏がkmeansで色々悩んでたっぽいなので、とりあえず出来るだけ早く
blindとsmartをコミット出来る状態にしたかったんで削除したんでしょう。

その二つがよくなればkmeansの開発に戻るっていう話もあるけどね。クロマ機能
も同じく。

>>58
開発中のweightp機能の検査設定って言えばいいかな？

weightp付きで落ちないもの
x264-p-frames-434cd3bb0c2ee94014c0d096901f16c23e39ed94
↑以降は落ちる

x264-p-frames-434cd3bb0c2ee94014c0d096901f16c23e39ed94.7z
Coer2以降用(-march=core2 -msse3)
http://firestorage.jp/download/586d52ff594991bf543ab0ab1448d7215a37811b

noパッチ

>>60
summary（http://repo.or.cz/w/x264/x264-p-frames.git）の方は
434cd3bb0c2ee94014c0d096901f16c23e39ed94
で止まってますね。やや安定版なのかな。

>>59
コミットは近いの？

>>62
それについては前の経験で何も言えねえぇｗ

ただ、再びDylanZA氏には時間が空いたし、前の停止状態よりマシな方に進むかと。

あとドナルドが駅ですっぽんぽんって何？

バカポ氏 r1301でもPSP-3000再生確認取っているようだけど、どのオプションで問題なく見れているのだろう。。。
--profile main　--level 3　--b-pyramid none -b 3 -r 2 --vbv-maxrate 5000 --vbv-bufsize 5000 --no-mbtree
ひっかりそうな所はクリアしてるつもりだけれど詰めが甘いのだろうか自分のPSP-3000では非対応データになってしまうな
他ビルドも試してみたけどダメだった　むしろ再生できてる方の情報をお聞きしたい　

>>65
--aud

--audはPS3 Xbox360 Blu-rayだった

>>66
--profile main --level 3.0 --preset medium -B xxxx -r 3 --thread-input --stats '.stats' -o 'output' 'input'

thx

>>65
俺のPSP3000では再生できた
http://www1.axfc.net/uploader/Si/so/53635.7z&key=sevenop
ソースはウルトラセブン第1話OP
--preset slow --profile main --tune film --crf 25 --vbv-maxrate 10000 --vbv-bufsize 10000 --ref 3

>>65
POP氏ですよ


…同じPSPでも型番次第で再生対応レベルって違うのかな？

psp
xbox
ps3

で再生させる場合のテンプレはいつくるの？
俺はひそかに待ってるんだが、前前スレから・・

とりあえず、PSPのH.264動画再生機能について一言。

・一般ファームの方はVFRが無理っぽいが、もう数年カスタムファームでやっている
　ので、今の詳しい情報は分かりません（24000/1001, 30000/1001, 25なフレーム
　レートは絶対大丈夫＠一般ファーム）。レゾは640x480, 480x272, 720x480, 720x576
　320x240などでオッケー。
・モデルによって再生対応レベルには違いがないはず。ファームウェアバージョンに
　よってユーザーが作成した動画の色々が変わってたりしてるんですけどね。

基本的なx264のリミットは:
--no-8x8dct --level 30 --ref 3 --bframes 3
これによって、単にエンコしたいって思う人は
x264 --preset <hoge> --tune <hoge> --level 30 --crf XX --bframes 3 --ref 3 --no-8x8dct -o hoge.264
これでオッケーかと(ビットレートエンコードももちろん可能)。

Bフレームは一応もっと高い数度もいけるんですが、一応念のため3にしておくのが
いいかと。vbv設定はPSPの場合だと必要ない。内蔵されてるチップの力はPSPが必要としてた
ものと10倍ぐらい強かったんで、ビットレートがあまりにも上がらない限り
問題はないかと（レゾはどうせSD系までなので、そこまでビットレートが上がる場合は絶対に
近い程ないかと）

チェック用動画一覧:

再生確認＠PSP1000, CFW 5.00M33 & 5.50GEN-D
アスペクトは指定してませんが、PSPの再生ソフトをいじれば（ｒｙ
mp4boxの-pspフラグは一応使用されています。

・ttp://www.mediafire.com/?yzjgjinumtz
　totaleclipse_1301_b16_ref3.mp4
　設定: x264 - 640x480 --fps 30000/1001 --preset placebo --tune animation --level 30 --crf 19 --keyint 500 --bframes 16 --ref 3 --no-8x8dct -o totaleclipse_1301_16b.264
　Bフレームは15個まで使用されています
　・consecutive B-frames: 6.0% 34.9% 32.9% 11.1% 2.9% 2.8% 1.6% 3.7% 1.0% 0.0% 1.3% 0.0% 0.0% 0.0% 0.0% 1.8% 0.0%
　・tc2mp4でタイムコードが入力されている(muxの時29.97fpsに指定)
　・44100Hzな音声

・ttp://www.mediafire.com/?mkmnyymwdlt
　theisland_b16_ref3.mp4
　設定: x264 - 720x480 --fps 24000/1001 --preset placebo --tune film --level 30 --crf 19 --keyint 500 --bframes 16 --ref 3 --no-8x8dct -o theisland_1301_16b.264
　Bフレームは16個まで使用されています
　・consecutive B-frames: 7.4% 33.3% 37.2% 8.5% 5.8% 1.0% 0.6% 0.0% 0.7% 0.4% 0.9% 0.0% 0.0% 0.0% 1.2% 0.0% 2.8%
　・そのままMS社からもらったソースから24000/1001fpsでエンコード＆mux
　・48000Hzな音声

Bフレ16とかまだやってるやついるのか

1時間くらいの動画なら問題ないけど3時間くらいだと再生できないことがあるのがわからん
しょうがないから1時間ごとに分割してやってる

>>75
http://mewiki.project357.com/wiki/X264_Settings#bframes

--b-adapt 2でなければ、--bframes 16が最も速いのだから、別におかしくはない。

>>77
http://forum.doom9.org/showthread.php?t=139827

>>78
>This guide maps most of x264's options to FFmpeg's options along with detailed descriptions by x264 developer Dark_Shikari.

>--bframes <integer> (x264)
>-bf <integer> (FFmpeg)

>Recommended default: 16

http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

>>73-74
thx!

>>79
So, this is a warning to all those who use --bframes 16,
MeGUI and otherwise; the new B-frame decision is coming soon,
and when it does, in the interests of speed you may want to lower
the --bframes value to 3-5 or something otherwise reasonable.

Bフレ16が推奨されてたのはb-adapt2がない頃の話で
今は再生互換の為に3~4が主流だよ

--b-adaptの説明は、"Recommendation: Default, use 2 if you have time to waste."となっているから、
--b-adapt 1 --bframes 16が推奨されているのだろう。

だからそれは古い説明だっての

随時更新されているWikiの内容が古いとは思えない。

Blu-rayとの互換性の為に、--bframesは3までにしましょうと主張するのだったら分かる。
ただ、その場合は、--bframes以外に--keyint、NAL HRDやVBV等も併せて設定する必要があるけど。

好きにすればｗ

16にしたってどうせ・・・

全部Iフレにしようぜ

b 3〜4 ref 3〜5 b-a 2
実用的

LLVM 2.6 Release
http://llvm.org/docs/ReleaseNotes.html

>>85
BDってb3までなの？

>>91
http://spreadsheets.google.com/pub?key=tYGTjNd0dG6P_A9z-YkFzFg&output=html
この表が分かりやすい。

PS3は--b-pyramid stirctの方がいいのかな？

以前のb-pyramidだと正常に再生できなかったのでは？
持ってないから知らないけど
strictはハードウェア互換を強くしたものだから多分おｋになってると思うんだけど誰か試して欲しいなあ

http://forum.doom9.org/showthread.php?p=1337170#post1337170
バグが有るから、修正されるまでは、pyramidはよした方が良い。

起きたら吹いたじゃないかｗ

テスト用動画で「--bframes 16」を使ったのは、一応PSPが再生出来る範囲を
証明するため。

>>92
<Dark_Shikari> JEEB: you should add to the 2ch thread that --b-pyramid strict isn't required for blu-ray, rather that --b-pyramid normal *won't* work
<Dark_Shikari> and --b-pyramid none is just fine
<Dark_Shikari> wrt that spreadsheet
<Dark_Shikari> and the partitions column is redundant, everything will handle partitions all
<Dark_Shikari> and that the blu-ray info is wrong, blu-ray doesn't do 60fps
<Dark_Shikari> and that the ipod restriction of 1 ref is wrong

つまり、「--b-pyramid strict」はBDにとって必要になってない、ただ
「--b-pyramid normal」が動かないということ。
そして、もちろん「--b-pyramid none」も完全に大丈夫です。

partitionsのところも一応必要になってない、他の設定が合ってれば
「--partitions all」はいけるはず。

そして、Blu-rayの情報は間違ってるポイントは、60fpsのところです、はっきり
言って対応してません。iPodの「--ref 1」の制限も一応間違ってるということで。

mbtree+b-pyramid対応まだあああああああああああ

>>96
あと、Max GOP Sizeも空白になっているな。

>>98
もうウザイから黙ってろよ

>>92
この表ってどこで手にいれた？

>>96みる限り、表が修正されるだろうからそれ保存しておきたくて。

>>100
http://forum.doom9.org/showthread.php?p=1327490#post1327490

自分で作ったMP4をMPC-HCのDxVAで再生すると再生後数秒間だけ動画が乱れてしまいます。
環境は
x264.1181.release02
MP4Box-0.4.6-dev_20090226
Media Player Classic Home Cinema - v1.3.1299.0
です。
自分なりにいろいろ検証したところ1440x1080を16：9にすると乱れるようなんです。
比を埋め込むのをx264でしてもMP4Boxでしても乱れてしまいました。
どこが悪いかわかる人がいたら教えてもらえませんか。

頭が悪い

どうしてオプション全部コピペするくらいの手間を惜しむんだ？

聞くにしてもSS貼るなり、もっと詳しく描写するなり、色々あるでしょうに。

すみませんでした、オプションはこれです。

x264.exe --level 4.1 --crf 21.5 --qpmin 18 --qpmax 24 -b 2 -I 250 -i 25 --no-deblock --me "umh" --merange 24 --subme 7 --mixed-refs --trellis 2 --no-fast-pskip --no-dct-decimate --threads 4 --scenecut 60 --cqm jvt -o

>MPC-HCのDxVA

これが腐ってるんじゃねーの

スクリーンショットを撮ると綺麗にとれてしまうのでカメラで撮影したやつです。
ttp://www.dotup.org/uploda/www.dotup.org294410.png

>>107
そうですか。
しかしMPC-HCスレでも報告はありませんし、こちらの操作でなおるのならなおしたいと思いまして。

level指定してるけど本当にそのlevelの規格に収まってるのか？

大体自動でlevel判定するようになってるのに態々指定する意図は何よ？

Lv4.1にするのはP2Pに流すためだろ

>>スクリーンショットを撮ると綺麗にとれてしまう
やはりMPC-HCのDXVAが腐ってるに一票

>>111
level指定したのは4.1だとPS3で再生できるとか聞いたからです。
今level指定はずしてエンコしたらlevel4になりました。
しかしまだ動画が乱れます。

>>113
やっぱりそうですか。
P2Pに流すつもりもない自分用だしCoreAVC入れてみるか。
そのうちよくなるかもしれないし。

ありがとうございました。

一瞬なら我慢するのがいい
PS3で再生するとなんでもないんだから再生ソフト側の問題でしょう

DXVAなんてストリームをグラボに流してるだけなんだから、
グラボがうんこかドライバ更新してないんじゃないの？

>>115
CoreAVCでよくなりました。

>>116
ドライバ更新してみてもやっぱりDxVAを使うと駄目でした。

比スレでも聞いてみます。
ありがとうございました。

猫科研究所死んでる？

猫科研究所の中の人です

サーバーのディスクが死んだとのことで現在復旧中です

自動バックアップしてるから平気だろうと思ったら
これも7月を最後に上手く動作してませんでした…orz

r1185以降の日本語訳は手作業での復旧になります
まともになるまでしばらくかかると思います…orz

頑張ってくだはい

ttp://74.125.155.132/search?q=cache:eRjVM_ZoWMoJ:www.up-cat.net/x264%25252Dchangelog%25252Djp%252Br1200%25252Dr1299.html+x264-changelog-jp+r1200-r1299&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a

ttp://74.125.155.132/search?q=cache:KZTTgyz_JWkJ:www.up-cat.net/x264%25252Dchangelog%25252Djp%252Br1100%25252Dr1199.html+x264-changelog-jp+r1100-r1199&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a

Google先生マジ感謝

>>121-122

わざわざありがとう、それはゲットしてた。
「手作業」と言ったのはwikiフォーマットとr1293以降の訳のことです

数が多いんで単なるフォーマットとは言え面倒なのと
8〜9月ごろに更新した記事を覚えてないことが痛い…

ttp://74.125.155.132/search?q=cache:Fc-4MBimxoAJ:www.up-cat.net/DCT%252Bvs%252BDWT.html+DCT+vs+DWT&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a
ttp://74.125.155.132/search?q=cache:c7Fyml4CqbcJ:www.up-cat.net/H%25252E265.html+H.265+%E7%8C%AB%E7%A7%91&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a
ttp://74.125.155.132/search?q=cache:Cr-V8Fh6l3IJ:www.up-cat.net/x264%252528mbtree%252529.html+mbtree+%E7%8C%AB%E7%A7%91&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a
ttp://74.125.155.132/search?q=cache:ES1zwrXhDqkJ:www.up-cat.net/CBR%2525A4%2525CE%2525B8%2525B8%2525C1%2525DB.html+CBR%E3%81%AE%E5%B9%BB%E6%83%B3&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a
ttp://74.125.155.132/search?q=cache:rPZWTZktzwQJ:www.up-cat.net/x264%252528deadzone%25252Ctrellis%252529.html+x264%28deadzone,trellis%29&cd=1&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a

いっぱい発掘できた。

なんという…これぐらいしかできないですが一応。
http://www.bing.com/search?q=%E7%8C%AB%E7%A7%91%E7%A0%94%E7%A9%B6%E6%89%80+site%3Aup-cat.net%2F&form=QBRE&filt=all&qb=2
ここから１００ページぐらいキャッシュされていましたよ。

いつもありがとうございます。いつも参考にさせていただいています。

猫研の中の人です

とりあえずchangelogはほぼ復旧しました
ご協力ホントにありがとうございました
2chねらーがこんなにやさしいなんて…

個別記事は数日〜1週間ほどお待ちください

ν速クラスの掌返し

>>126
ねらーは自分の損得だけで動くからな。

他人の損でも動きます。

ttp://repo.or.cz/w/x264/x264-p-frames.git?a=shortlog;h=refs/heads/chroma

これ何？weightpとは別のブランチ？こんなのあったっけ？

新しく作ったんしょ。
良く知らないけどlumaだけじゃなくchromaも…って話じゃね?

1302

これって画質には関係ないよね？

せらひーさん、パッチ版のauo最新版って出ませんか？

俺も欲しい

autoVAQ丸投げでいいじゃん面倒くさいし

お前は何を言ってるんだ？馬鹿なのか？
この馬鹿はaq-mode 2の意味を履き違えてるようだ

autoVAQの最新版てなんだ？ｗ

>>129
ﾜﾛﾀ

でも、結局は自分の飯がうまくなるからだから、それも自分の得のうちに入るのでは？

　 _. -‐ " ´￣｀`　丶、
＜<´　　　　　　 , 、　 ヽ、　 　.へ
　　｀` 　　　　 ／'＾._`ヽ、ゝ､／ ^ヽ＼
　　　　　　　〃'´=‐　　 ゞ -´＝ミヽ　ヽ、
　　　　　 　 ﾚ´, ‐ ´　 ,　　　　　 、ﾐ.l 　 ヽ
　　　　　　/／ ／ / /|　 ﾄ　､　ヽ.＼ i　　 l
　　　　　　/ ／/　! l l !　 !i　| i　 |　ヽ|　　 |
　　　　 　 |/ /.! ,r|‐ト! l　 !+┼ｔ-､l　! .|　　 |
　 　 　 　 |　l .|　|',,ｪ,, ! ヽ ! ! ,ェ._ レ| .|　　 !　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 | | vl. l l!|ｆ:ﾊ　　｀ "|ｆ:;;ｊヽ | .|　　 |　　　　x264のrev1309出てるよ、b-pyramid strictがやっと直ったっぽい。
　　　　　　ｌ,! |. l. l、-'┘ 　 　 !二ﾝ’' ﾉ　 i. |　 ∠＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 | ! l`-`-'　 ‘　　 ｰ＝'彡ｲ　 ! /
　　　　 i ｰ ､|l.　|l ｀i　、｀ ´　　,.イ .//　//　　 _.　-‐　ﾌ
　　　　　!　　l|　 |l.　!　｀i. r　´　 ! 〃　//　' ´　　　　/
　　　　　 i 　 l i　| ＼!　,l-|　　　.l//　/´　 　 　 　 ./
　　　　　, ゝ‐ ､ ! |_ .. ゝ/ﾉ　　 .ノ/ ノ　_ .. - 、 　 /
　　　 ／　　　 〃!| 　 /ー- ／ /／〃　　 　 ＼/
　 ___/　　ｒ‐-〃、 !　/　,∠ -‐´､〃　,　　　　　ヽ
　!￣｀`＝{　　 　 >-y'´＿　　　/ｌl ／　 ＿＿＿ヽ__
　 ｌ'ｶ　 　/　´￣/　,i￣ ｀丶　/ ｌｌ=ii .／´￣￣￣ ｀`ラ
　　ﾋ｝　 ｛　　 , ''〉-'ヽ､　　 　ヽ ||　V´　　　　., へ／
　　 ヽ､　 `ｰ'　/　ハ ヽヽ、_.／」|　　　　　　《<／ ヽ
　　　 　 |／　/　 ﾊ.ヽ　　 ヽ／　　　,-┬ ' "´　　　 ヽ
　　　　　|ヽ /　　ハ ヽ　　　 >　　／　 | ` ､　　 　 　 ヽ

megui起動したらアップデートがあったから更新したんだが、設定が読み込めなくて全部削除するハメに('A`)
AQをDisableにできないし何なんだよ('A`)

meguiの0.3.1.1057は糞っぽいぞ･･･
AQをDisableに出来ないだけじゃなくいろいろとおかしい
AQとかFast P Skipの設定を変更して保存しても、再度表示すると反映されてなかったり(見た目が変わっていないだけで内部ではちゃんと変更されているようだけど)
久しぶりに地雷踏んじまった･･･

バッチ書くよりMeGUI使う利点って何？

GUIが使えること

オプションのつけ忘れが起こりにくくなるくらいかな
VBVやらVUIやら付け忘れて何度やり直したことか…

MeGUIはGUIのお手軽さがあって使ってたけど、最近になってやめたわ。
エンコ中にシャットダウンするかしないか変更できるのは好きだったんだがなぁ。

callで呼び出して使ってればエンコ中にそのバッチの
最後にcall shutdown.batって書き加えればshutdownするよ。
shutdown用のbatはあらかじめ用意しといて。

call hoge.bat
call hoge2.bat
call shutdown.bat ←付け加えて保存

x264 Rev.1310_r1 core2[Yorkfieldコア以降]最適化ver. と Pentium3以降（２バイナリ）
ttp://resic.laburec.net/bin/x264/x264-r1310r1_core2-sse4.1_and_p3.zip

x264_OreAQ_itvfr_r1310.zip
ttp://download756.mediafire.com/ngtc70ze4gig/xn3fzdwlywr/x264_OreAQ_itvfr_r1310.zip

乙々

cosmetics ｗ

ふかわりょう プロデュース ユーザ育成型アイドルユニット COSMETICS

>>147
なるほど。そういう手が・・・ありがとう
元々ソフトに弱くてバッチ作成も検索の真似が大半だったから参考になりました。

>>151
shutdown -s -t 0

shutdown.batと言う名前は使うなよ

風呂入れよ

風呂入って、歯磨いて、もう寝た

しゅ、宿題

tobinakaまたwiki閉鎖したのか
こんなことするくらいなら最初から作るなよ

今年中にr1900位いくかな

D9みた感じ、まだまだBD Compatibleには時間がかかりそうだね。

weightpまだああああああああああああああああああ

過疎だな…

r1318

mbtree+b-pyramidまだあああああああああああああああ

もう自分が使ってるx264のバージョンすら忘れた

r1181で停まってますが

何でやねん

b-pyramidは正直どうでもいい
weightpはそろそろ待ち疲れてきた

今日も更新されてたしその内コミットされるさ…きっと…

今度のAVIVOは使えるぞ！ - 録画人間の末路#comment-list
http://blog.goo.ne.jp/krmmk3/e/cccea068966426c1198d760a122cbc14

x264もこんくらい速くならんかな

>>169
それ、Linux では使えないよね?

そういやLinuxでエンコって何使うんだろう。avisynth使えるの？

ｆｆmpegでデコード&フィルタ->パイプでｘ264へ、ってのが一般的なんじゃないかね
wine使えば完全ではないけどsynthも動くことは動くみたい

>>172
現状 x264 ( ffmpeg 等経由 ) ですね。
LinuxでもAMD(ATI)のGPU使えればいいのですが。

vmware使おうとか思わんの？

>>171
現状ffmpeg/mplayer等のフィルターやら色々に頼れないんで、wineで起動してる
avs2yuvの出力をファイル形式のパイプを使ってネイティブなx264に読み込ませる
風にしてる。Avs2.5は2003年から普通にWineでも動くし。

AvisynthスクリプトのプレビューとかはVirtualDubですることになるけどねぇ
ttp://img39.imageshack.us/img39/9532/mukyu.png

コマンドラインの一例:
mkfifo pipe01.y4m;x264 pipe01.y4m --preset slower --crf 19 -o file01.mkv & wine avs2yuv.exe comp1.avs pipe01.y4m
(最初はパイプ用ファイル作成、それからx264とavs2yuvが起動して、ウマー）

知り合いが現在、Avs2.5のLinuxポートしてるけど、完成されるまで時間がかなり
かかりそう。現在はTrim, ffmpegsource2等ぐらいは動くけどね。なので、Linux
では現在、Avisynth程の協力なフレームサーバーがない上、Wineでこういう
ことを済ませるのが一番いいかと思う。もちろん、ただの再エンコならffmpeg等
では出来るけど、高度な逆テレシネ、tempgaussmcなどNNEDI(2)を使ったデインターレース
とかは残念ながら出来ない。

>>174
そもそもvmware/virtualbox等を使っても利点がないのよ。Wineで普通に動くし、
VMより速度もいいし、*nix系ではパイプ機能も普通にいけるからVM内からネイティブ
なx264へソースを送るのが面倒になる。数少ないGPUフィルタも、そこまで
利点ないし、VMから起動したって意味ないし。

巣窟に戻るかblogでやれ
だいたい素直に窓でやれば丸く収まる話をLinux厨のMS嫌いは病気Lvと俺ﾏﾝｾｰ文が（ry

>>176
そんな外人さんに向かっていきなり罵ることもなかろうに
Doom9眺めてるだけじゃよくわからんようなことも日本語でわかりやすく教えてくれる人なんだし
それにx264はクロスプラットフォームなんだから、winに限定するのはおかしいだろ

>>176
なんでそんな過剰に反応するのかがわからん
話の内容がわからんから僻んでるようにしか見えんぞ

もしもLinuxユーザーのakupenguinがいなかったら、x264の開発はどうなっていたことだろうか。

何か仮定法の例文みたいな文だなｗ英訳したくなるｗ

DANGAEROUSのOreAQのdiff、1314の変更で当たらなくなってる部分をそのまま放置してるように思えるんだが。
diffだけ更新忘れならいいんだけど。

あ、DANGEROUSはまだ1310なのか。失礼しますた。

>>176
荒らしには答えるなという国際的な教えは分かっているはずなんですが、これは
>>171が聞いたこととは違ってるのでしょうか。個人的にはそれに合ってる答え
かと思います。

確かにレス的には長いんですが、今の無意味な書き込みよりはマシかと思います。
（自分のこのレスを指します）

あと、オイラはMS嫌いではない。確かにMSなOSには不満もあるが、一応
必要なところでは必要になってるとは認める。そして、残念ながら、エンコードには
Windows自体が必要になってないし、現時点でパフォーマンス的にもLinuxは
いい評価を出してます。選択肢が見えない人こそ、もう一度鏡で自分を眺めた
方がいいかと思います。

175がすごいことだけは感じた

>>175
やっぱりLinuxでGPUつかうのは無理か。
てか、俺のせいでスレ荒れてすまん。OS限定無かったからLinuxでもいいかと思って。
他のサーバ(Linux)に相乗りさせてるだけで、
24時間起動しているWindowsがあったら、そっちでやってたかもしれん。

「ATI Avivo video Converter」が(操作性はともかく)絶賛されているので、
コマンドラインで使えれば操作性などどうでもいいLinuxで使えればいいんですが。
(最近AMD(ATI)のLinuxドライバが充実してきたし。)

Linuxだと、ffmpeg(w/x264) が事実上唯一の選択肢ですかね。

ffmpegはちゃんとmake uninstallできるようになったのだろうか……

>>184
いや、LinuxでGPUを使うのは無理ではないんですよ。OpenCLドライバも一応
nvidiaから出てるし、VP2チップをH.264のデコードに使うVDPAUというシステムもあります。
(ATiは未だにOpenCL用ドライバーを公式的に出してないはず)

ただ、H.264方式の動画エンコードはGPUみたいなものには「任せづらい」とも言える
かな？x264の経験からすれば、GPUに色々させたがる人は多いのだが、期待はあまりにも
ずれて、結局辞める人が多くなったのです。現在、GPUを使っているエンコーダーは画質的に
も一応アレなものですし。マーケティング部の綺麗な言葉になってしまっている。

まぁ、時代と色々変わるでしょうけど、現時点から見れば、今GPUは使いたいかどうか
と問うのならば、「使いたいが、使い道がない。」という返事になります。
fft3dgpuとか、H.264のデコードには使えるのですが、エンコードの方ではまだまだ…

>>186
確かに、h263->h264の進化が、皮肉にもGPUの進化とすれ違ってる気もする。
ただ、avivo video converter の品質が大きく向上しているという記事を見たので、
やっと使える物が出始めているのかな、と思ってここで聞かせてもらいました。
(Linux板でも同じような話してしまって、結果としてマルチになってしまった。ごめん。)

現状では、core i7 で x264 をぶん回すのがベストなのですね。

DANGEROUSの1318はまだかな？
Seraphyのは出たみたいだけど。

Linuxはもうだめだ
Vistaがあれだけ転けたのに、
世間はLinux（Ubuntu）へ行かず、
XPを使用し続けることを選んでしまった
そこまでWinが良いのかよ、ガッカリだ

おっさん連中はワードとエクセルが入ってないPCを買わないだろ

何の話？

なんか、俺がLinuxの話振ったせいで、変なのを呼んでしまってすまん。
マルチメディア関連はWindowsが得意だが、
いろんな小物を組み合わせてバッチ処理するのはLinuxのほうが便利なんだよな。
それで、Linuxでも、avivo video converter みたいなのが使えると
いいのになぁ、と思ったんだ。

極端に言うと、LinuxでGPUつかう事って、それぐらいしかないし。

Linux
http://pc11.2ch.net/linux/

なんで
x264 -o foo.264 bar.mp2
ってできないの？これ？
avsってやつ噛ます理由が分からん
最新のx264入ったffmpeg使えってことか？

weightpの更新履歴にreviewとかいうのが出てきた。完成間近か？

>>194
>avsってやつ噛ます理由が分からん
なんでエンコーダーがデコーダーを内蔵してなけりゃならんのさ
それにパイプで渡せばいいんだから、ffmpegは別に最新でなくてもデコードさえできれば問題ない
ffmpeg -i bar.m2p -pix_fmt yuv420p -vcodec rawvideo -an -f rawvideo -|x264 -o foo.264 - widthxheight

ところでmp2はm2pの間違いで書き間違いでいいんだよね？

ttp://mailman.videolan.org/pipermail/x264-devel/2009-November/006502.html
>x264 will be adding support for weighted P-frame prediction in a few days.

　　　　　　　　　　　　　　　　 　　　　　,､_　　__,....,＿　＿,...、　　 　　　 　 ■　■
　■　　　　　 ■■■　　　 　　 　　　,} {｀i;:r,;'ﾆ (;;;;､`　,　r'　　　　　 　 　■　■
■■■■　　■　 ■　　　　　 　　　｛i'　 i:.'ー<.･)}:ﾑ　ヾi,　　　　　 　　　■　■
　　■　　　　■ 　■ 　■■■■■ﾉ／/ -r　/:::ミ　('ｰヽ■■■■■　■　■
.■■■■　■■■　　　　　　　　　iﾞ　i:/ /二./ /',=､__ﾉi/　　　 　　　　 ■　■
　　　■　　　　　■　 　　　　　　　　ヽヽ! {:::} //::::''´`'7!/
　　　■　　　 　■　　 　　　　　　　　ヽ､__ヽ!l::i:::::ii;;;;;;;|,ノ　　　 　　　　　　●　●
　　　　　　　　　　　　　　　　 　　　　　　　｀ヽ､`ー""ヽ
　　　　　　　　　　　　　　　　　　　　　　　　　 `'ｰ-'''

ｸﾙ━━━━(ﾟ∀ﾟ)━━━━!!

デンジャラスrev.1318r1のmixAQafs版
TimeScaleが4倍指定じゃなく1倍指定

r1301以降のビルドでｙ4ｍ読ませるとBad header magicってでるんだが

rev1301はレグレッションテストの項目変更で実行ファイルは変わらない

つまり君の勘違いか、なにか別の問題がある
自分でビルドしてるわけじゃないんだろう？

ttp://forum.doom9.org/showthread.php?p=1340492#post1340492

結局まだなのか…？

>>182
２ちゃんにも、クズがいることを忘れずに。

嗚呼いつまで待てばいいんだろう。
もうwaitpと呼ぼう。

いつの間にかmbtreeなんてものが実装されて出力が大きく変わっちゃってるのね
いろいろ試してみたけどアニメには向かない感じかな？
mbtreeONでQPを2下げるよりQPを下げずにno-mbtreeの方がサイズがほぼ同じでもいい感じ
mbtreeONだとエッジ周辺にノイズが出る感じ
まぁ静止画しにて目を凝らして見ないとわからないけどｗ

アニメで　mbtree 使ってないな。

x264はVAQもそうだし実写向けだからな
映画のエンコが主用途、アニメはマイナー

>>207
アニメにも十分向いてるだろ。
使いまくりだよ。

高画質志向には向いてなさそう
レールガン5話でmbtreeONだと180MBでOFFだと250MB
画質はほーーんの少しだけ後者の方がいい
前者だと70Mも縮まるけどよーーーく見るとほーーーんの少しだけ汚い
それに100MB代より200MB代の方がプラシーボ効果が得られるｗ
前者の方が圧倒的に画質対サイズがいいだけに悩むなぁ･･･
しっかしx264は凄いなぁ

http://mirror05.x264.nl/Dark/Flash/lowbitrateanime.html
MBTreeの効果がよくわかるサンプル

2Passで比べなきゃ意味ないだろバカヤローっていういつもの人が出てくんぞバカヤロー

>>210
動いてる部分が劣化しまくりだな

>>211
言おうと思ってたｗ

Blackperlで以前と同じビットレートになるようにセットしたらしいけど違う素材では変わるそうです。

>>210
何より外国人なのにちゃんと著作権問題の出にくい同人アニメの映像を使ってるところが凄いよな

いやただ単に東方ヲタなだけだと思うけどなｗ
前にあったweightpのサンプル動画もこれの一部だったし。

>>212
目につきやすい止まっている部分が劣化するよりは、よほど良いと思うけどね。
動いている部分を、静止画で比較すれば今ひとつだろうが。

劇場の質感”を追求したBD版「崖の上のポニョ」制作秘話
ttp://av.watch.impress.co.jp/docs/series/avt/20091105_326296.html
■ 日本のアニメ向きにエンコーダをカスタマイズ
日本のアニメは、ほとんどの被写体が2コマにつき1回しか動かない(異なる被写体が交互に動く場合はあるが、
ひとつの被写体に限れば2コマに1回)。このため、質感の揃ったピクチャが1コマおきに登場するGOP構造を新たに設計して
エンコーダに入れたのだという。実際にどのようなGOP構造になっているかは秘密というが、MPEGに詳しいエンジニアなら、すぐに思いつくはずだ。

GOP構造を日本のアニメ向きに改造したことで、動きのバタつきがなくなり、映像全体が落ち着いて安定した画質を引き出せるようになった。

分かったような分からないような書き方だね

動きのバタつきって何だろう

>>219
動きのバタつきの事じゃね？

そんなもんエンコーダが自動判定しろって世界じゃねーの。
つーか、30、40Mbpsの世界でそこまでシビアに考える必要あるのか疑問。
ただの宣伝だな。

平均23Mbpsって書いてある

　　　　　　　　　　　　/:::::::::::::::::::::::::::::::/:::::＼
　　　　　　　　　　　 |＼r‐､:::::::::ｨ‐‐ｧ::::::::::::::::＼
　　　　　　　‐=二⌒`　＼　＼/ ／__::::::::::::::::::::::l
　　　　 ＿,,ｨ''⌒　　　　　　　　　　＼＼:::::::::::::::::|
　　　　 ＼／　　　　　 ／　　　　　　 ヽ｀∨⌒｀´　
　r‐-‐=ﾆ/ /　／二／　 ／,ノ￣￣｀ヽ、―ニ 二
　 |::::::::::/　|／｀´　/_,, ｀ヽ／　´｀ヽ _　 三,:三ー二
　 ヽ:::::::７　ﾚ⌒ヽ　　　ｨノヽ--/￣ ,　　　 ｀￣￣￣
　　 ヽ::::ﾚ|ﾉ● 　 }　　ﾐ }　　. .|　 /!　　ぽにょぽにょうるせんだぼけ
　　　 ＼ `| ｀ー''´　　 ^}｀ー‐し'ゝL _
　　　　　｀'l 　　　　　　　ﾍｒ--‐‐'´}　　　 ;ー------
　　　　　　 ＼　　　 ､,＿,｡ヾ:::-‐'ーｒ‐'"＝＝-
　　　　　　　　 ￣￣｀ ｰ ´￣￣

で、今回は赤くないのか？

>>222
ああ、たしかに。

まあピークで４０もあれば平均それでも十分足りるんじゃないかな。
PHL絡みの記事は毎度毎度誇大な広告臭さを感じちゃうんだよね。
パナが金出して書かせているんじゃないかと。

そもそもエンコ系はヲタの趣味バイナリの方が良さそうだ

高ビットレートで精細に残すのと
低ビットレートでもそれなりに見られるようにするのは
若干技法が違うだろうから微妙だけどな…

あのゴミはなんで真っ赤なんだろな

>>228
色温度9600Kのモニターで見ろJK
って事らしいぞ。

そういやOpenGOPてどうなってんだ。全然聞かないけど。

strict DPBはコミットされたし、open GOPもそのうちにやってくれると信じたい。

3passでmbtree使ったら明らかに画質が落ちたでござるの巻
でももしかしたらちゃんと動きの少ないところではよくなってるのかなぁ･･･
まぁゲーム動画に動きの少ないシーンなんてないが

データも出さずに画質が落ちたとか言うバカは黙ってろ

データとまで言わなくてもqcomp調整したのかくらい書いてほしいよな
mbtreeが悪いって言ったらまず疑うのはそこなんだし

qcompはデフォルトのままの0.6
560bpsで800x450
ニコニコ用になら使えると思ったんだがqcompを調整しないと微妙なのかな

0.7くらい？

DVDよりでかいサイズを560って、脳みそ腐ってるのか？

>>237
解像度落としてボケさせるか、落とさずに少し汚くするかなら俺は少し汚くする
それに等倍で見るならなんら問題ない
お前こういうエンコしたことないのに物言ってるだろ

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

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

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

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

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

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

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

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

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

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

この前のアップデートでビットレート制限無くなったんでしょ？プレミアム会員のみらしいけど
制限無いのにケチケチすんなよ

>>239
mbtreeについてなのにスレ違いかよｗ

5MbpsでFullHD

保守的な俺はmbtreeはもちろん、いまだにAQもpsy-rdも切ってエンコしてる。
実際問題としてアニメだとこの設定でエンコした方が絵が破綻しないし、
容量も程々に収まる気がする。

ID:+T06ldCx
ニコニコ用になら使えると思ったんだが(ｷﾘｯ

>>243
AQはアニメに向いてないって言われてるしな

ID:+T06ldCx
これ頭悪そう

>>238
＞560bps
↑これをもう一度良く見てから>>237にもう一度コメントをどうぞ

kが抜けてたか
まさかkが抜けてただけで本気で560bpsでエンコしてると思った？
なら謝るよ

ニコ厨は空気読まずになりふりかまわず荒らして回るから死ねばいいと思う

どっちものどっち

　　　　　　　　　　　　　　　, -――― - ､
　　　　　　　 　 　 　 　 ／: : : : : : : : : : : : ｀::.､
　　　　　　　　　 　 　 /: : : : : : : : : : : : : : : : : :＼
　 　 　 　 　 　 　 　 /: : 　::::::::::::::::／.::::;ｨ:::ノ}.:.:.::.ヽ
.　　　　　 　 　 　 ／: ::::::::::::::::::::／　.／/ｲ　ﾉ::::ｲ::.ﾊ
　　　　　　　　 ／: : ::::::::::::::::::::/ﾆﾆ,へ､　　 ノｼ' ﾘｉ:: }　　　　　　i
.　 　　　　 　 /: : :::::::::::,--､:::/:=／,=ｧｭ＼　　　 　}　|　　　　　 人
　━━━━/; : .::::::::::::{ :.:ヽｙ :/　{´ i::kﾘ`　　 -‐'ｲ::::|　━━＜ 　 ＞━━━━━━━━━━━━───　─　─
.　 　 　 　 /' {::..::::::::::::ﾊ　 /::/　 ..... 辺' 　 　 /;ｶ/:::::|　　　　　｀Ｙ´
　 　 　 　 　 ！::;ｲ::::i::::::::Ｙ:/　　 ::::　　　 　 ､{ｼ/|::::::| 　 　 　 　 !
　　　　　　　　Ｖ　!ヽﾊ::ｲ/:ﾊ　　 　 　 　 　 　 ::ﾊ|:i::::|　　　　　　　　　呼ばれた気がした
　　　　　　　　　　　　Ｖ ﾚ' ｿ　　　　　　´’　／! .ﾘ|:::|
　　　　　　　　　　　　　___/ 　　　 ヽ.__, . イ:ｲﾉ / |:::!
　　　　　　　　 __, -‐ '´　＼　　　　/ｰ--- ､__　　|::!
　　　　　,ｨ≪´　　　　　: : : ﾍ-　　- }: : 　　　 }}｀7ﾘ
　　　 　 {/＞ミ_ ≪.　　　 　 ﾍ ――ｌ　　　　〃./ i ＼
　　　　　|' ﾊ＼ ｀ヽミ_≪.　 　 ﾍ.　　 ｌ　　　〃 / ﾘ｀　 ｀ｰ ､
　　　　 /:　　　＼　i　 ヽミ_≪　ﾍ　　|　　〃／ /　　　　／＾＞

池田ァ！

まあ要するにここで話するときはどこ向けにエンコしてるかは黙っとけってこった
ニコニコに限らず特定環境向けはすぐ追い出されるから

流石に再生環境の縛り云々ぐらいはおｋじゃね？

linuxでx264は再生することはできますか？

自分で調べられないならlinux使わないで素直にWindows使っておきなよ

>>255
　　　　　　　　　∧＿∧　　まぁ、茶でも飲めや
　　　　　　　　 (´・ω・`)　　　シュッ
　　　　　　　　（つ 　　と彡　./
　　　　　　　　　　　　／　　./
　　　　　　　　　 　／　　　./
　　　　　　　　　／　　　　/
　　　　　　　 ／　　 　 　/
　　　　　　／　///　 　/　ツツー
　　　　 ／　　旦　　　/
　　　／　　　　　　　./

スレ違いすぐる

>>255
MPlayer, VLC, etc.

>>256
では、Windows で x264 を再生することは出来ますか?

>>260
Windows7ならOSに最初からスプリッタとデコーダー入ってるぞ
他に何も入れずにWMP12とメディアセンターでH.264を楽々再生可能

x264はH.264の動画を作るエンコーダーです
WindowsにH.264のデコーダーが備わっていれば再生できます


と釣れてみました

>>261
Win7のWMP12って、--nal-hrd --tffのインタレ保持をデインタレ再生してくれる？
うちだとWeave再生されてしまう…

うちもおなじだ。WMPなんてまったく使わないけど。

せらふぃーさん、パッチ版のアップデートはもうないのでしょうか・・・

掲示板に書いてくれば？

seraphy氏は掲示板見てないだろ、あのざまだし

たまにスパム消えてるぞ

x264 r1181 → r1318　に変えたらい今まで使えたカスタムマトリクスでエラー出るようになりました。
マトリクス関係で何か変更ってありました？

無いと思うけどなぁ。
どんなエラーかくらい書いた方がいいと思うぞ。

すいまんせん。INTRA8X8_LUMAの左上を1から2に変更したら動きました。
原因はよく分かりませんが、もう少し調べてみます。

INTRA8X8_LUMA =
2,14,15,16,17,18,19,20,
14,15,16,17,18,19,20,21,
15,16,17,18,19,20,21,22,
16,17,18,19,20,21,22,25,
17,18,19,20,21,22,25,30,
18,19,20,21,22,25,30,27,
19,20,21,22,25,30,27,14,
20,21,22,25,30,27,14,6

よく知らないけどmatrixって正規化してなくていいの？

weightpﾏﾀﾞｰ

マトリクスを弄って喜んでる奴はプラセボ試薬で病気が治るタイプの人間

>>263
>>264
Win7のメディアセンターが軽くて良いんだが、
デコーダが選べないのでWMP12のデコーダを使われてしまいWeave再生
PowerDVDで再生すればDXVA効くし、デインタレもしてくれる。
純正のデコーダの設定はいじれないものか…

選択出来るツールが出回ってたと思うが

ttp://www.codecguide.com/windows7_preferred_filter_tweaker.htm

>>271
原因はよく分からんが、そのマトリックス酷いな

左上とかちっさすぎるとオプションによってはエラーでるの昔からあるじゃん。

6以下はオーバーフローする恐れがあるからやめたほうがいいとか何とか。
各成分+6にしてQP1だか2下げたほうがいい

>>263
ウチはちゃんとされていて何も問題ないが
まさかCCCの方の設定がweaveとかいうオチじゃないよね

1319

( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp
( ﾟ∀ﾟ)ｱﾊﾊﾊ八八八ﾉ ヽﾉ ヽﾉ ヽ/ ＼/ ＼/ ＼ weightp

どうしたんだ

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=87de2346225721e8ca68a1b59bc87133fc598a42

来た！

今外だから見れないけど来たの？
ちくしょう昨日ならリアルタイムで試せたのに何で月曜日に…って向こうはまだ日曜なのか。

--weightpは今のところYのみに有効で、インターレースには使えない。

k-meansﾏﾀﾞ-ﾁﾝﾁﾝ

変更がとまらないね。
いつ落ち着くんた？

ためしに--weightp 2を付けてエンコしたらブロックノイズだらけになるシーンが何箇所も出たｗ

http://forum.doom9.org/showthread.php?p=1340507#post1340507
まだ使えそうにないね

weightp って weightb のPフレ版って認識でOK？

>>292
確かにCoreAVCを使うとブロックノイズだらけだけど
mpc内臓のH264/AVC (FFmpeg)だと綺麗に再生されるね
根が深くないバグだといいんだが・・・

>All weightp modes may cause minor breakage in non-compliant decoders that take shortcuts in deblocking reference frame checks.

CoreAVCの次のバージョンでは直っているだろうけど、それまではffdshow等を使うのが良いだろう。

flashplayerではどう？

>>296
あの・・
flashplayerでは内部で映像CODEC「AVC(H.264)」、音声CODEC「AAC」に対応してるので
x264とまるで関係ないんです。つまりx264のバージョンがいくつを入れてあってもflashplayerの再生には
全く関係ない。

Core AVCだけでしょ。

>>293
基本的にはそれでOK

>>297
あなたは今何が問題になってるか理解していない、に3000点

>>297
お前はFlashPlayerのAVCデコーダー（MainConcept製）はバグが絶対ないとでも言うのか？
あれはあれで、FlashPlayer9のころには[email protected]対応を謳いながらcqmに関して色化けする
バグがあったというのに

MainConceptは以前からWeightPに対応していたし、CoreAVCとは違って大丈夫だろう。

>>299
OK
ありがとう

　＊　 　　　+　　　　巛 ヽ
　　　　　　　　　　　　〒　!　　　+　　　　。　　　　　+　　　　。　　　　　＊　 　　　。
　 　　　　+　　　　。　 | 　|
　　　＊　 　　　+　　 /　/　　　イヤッッホォォォオオォオウ！
　　　　　　 ∧＿∧ /　/
　　　　　　（´∀｀　/　/　+　　　　。　　　　　+　　　　。　　　＊　 　　　。
　　　　　　,-　　　　　ｆ
　　　　　 / ｭﾍ　　　　| ＊　 　　　+　　　　。　　　　　+　　　。　+
　　　　　〈＿｝ ）　　　|
　　　　　　　 /　　　　! +　　　　。　　　　　+　　　　+　　　　　＊
　　　　　　 ./　　,ﾍ　 |
　ｶﾞﾀﾝ　||| j　　/　|　 | |||
――――――――――――

ps3はどう？

--preset slow --tune animation --crf 22 --qcomp 0.7 --ref 4 --bframes 3 --colormatrix bt709 --thread-input
これだけでハングしちまった。
今までハングったことなんてないのに。

>>305
坊やだからさ

なんかDoom9でもクラッシュが報告されてるな。しばらく様子見か。

r1330

スルーして正解だったか

--mbtree --weightp 1,2を組み合わせてみた。
・mpc-hc DxVA
・PS3
・XBOX 360
全て正常に再生された、と思う。

ちなみに、x264.nl氏のビルドを使ったら、--mbtreeで化けた。
rack04氏のビルドで、正常動作を確認した。

そもそも公式ビルドには--mbtreeなんてオプション存在しないし
--no-mbtreeならあるけどな

1331
win64のみ影響

ttp://mirror05.x264.nl/Dark/force.php?file=./x264.exe
Dark_Shikari氏自身のビルド

An official build was just fixed. Redownload then should be OK, folks.

seraphy氏出張中らしい

1332

は？
> the phase of the moon was right

ttp://www.catb.org/~esr/jargon/html/P/phase-of-the-moon.html

nlのも化けなくなった

何が化けなくなったの？

>>320
物語がさ…

で、結局--weightpはmbtree付きで使い物になるの？

--no-mbtree --weightp 0

複数スレッドを使うとweightpの結果が大きく違ってくる問題がある模様

Open GOPﾏﾀﾞ-ﾁﾝﾁﾝ

そいや、AMDのSSE4aをまともに使ってるアプリってx264くらいしかないんだね
Misaligned SSEはまだしもLZCNT使ってくれてるとは思わなんだ

猫科の人はもう和訳の更新やめちゃったのかな…

思いっきり今日更新してるじゃないか。
どっか違うとこ見てるんじゃないか？

あれってわざとそうしてるのかもしれないけど、1300以降へのリンクを1200-のページにしか貼ってないから、
勘違いする人もいるかもね

Open GOPって結局どういうものなの？
圧縮率上がるの？

あがるよ
MPEG2でさえ実装されてるんだがな

でもOpenGOPって、基本的にBDとかAVCHD用じゃない？

まあPC動画はGOP10秒くらいが多いから余り意味無いだろうね。

H.264でのOpenGOPって、どういうことなのか教えてください。

・単にIDR-Iが最初のフレームにしか入らなくてあとはずっとIフレームのみ？
・IDR-Iフレームを超えて参照フレームを持たせることが可能になる？
・デコーダは頭出しのときどこからリスタートしていくのか？

今見たらリンクがきちんと貼ってあった＜猫科
ありがたやありがたや

http://www.videohelp.com/glossary?O#Open%20GOP

BD用に、--keyintを1秒分に設定している人には嬉しい機能。

NHK教育で動画の圧縮技術やってる

う〜む、1318→1332で、2pass vbv指定のエンコードが途中で止まるようになった…
毎回ではなく、うまくいくこともあるんでスレッド周りの修正が原因かなぁ？
普段はx264.nlのバイナリを使っているけど、今回、techouse氏のバイナリでテストしても同様でした。

追記。
PSP向けのオプションで、こんな感じです。

--profile main --level 30 --ref 3 --vbv-maxrate 10000 --vbv-bufsize 10000 --bitrate 900 --keyint 240 --min-keyint 24 --bframes 3 --b-adapt 2 --rc-lookahead 60 --direct auto --me umh --subme 9 --no-psy --thread-input

みんなもやっぱり実写版の1280ｐの時はだいたい6分の一が目安くらいですか

1280p?}

>>338
>>323

http://pc11.2ch.net/test/read.cgi/avi/1221328142/945-949

1336
2passも修正されたらしい

マルチスレッド時も同じ結果が出るようになった。

あとflv出力がもうすぐ来るようです。

http://repo.or.cz/w/x264/x264-p-frames.gitはもう更新されないのかな？
でもchromaとかあるしなぁ…

＞flv出力
ダイレクトに flv を吐くようになる？

1332 以降のバージョンでエンコードした場合、
CoreAVCでデコードすると化けるようになってしまったのは既知の話？

PowerDVD9だと問題ないんだけど、CoreAVC1.5では正常に再生できない

>>347
ちょっと上も読めんのか藻前は

>>346
そう。てか一旦コミットされたんだが一瞬で撤回された。

>>348
↓あたりの話？
>>292-298
CoreAVC1.5はもう使えなくなるのか・・・。

CoreAVC1.9.5は、インターレースがうまく扱えない欠陥があるし
CoreAVC系はもうダメだな

>>350
2.xで対応予定らしい。

pass nとcrfでは、出力の結果が同じ容量ならcrfの方が断然キレイに仕上がるんだな

ビットレートとCRFの値によるだろ

>>353
同じ動画で同じ容量だから平均ビットレートは同じ

そこで2passの1pass目をcrfにする

1335で「Fix two-pass with slow-firstpass.」って書いてあるけど、本当にslow-firstpass限定？
修正箇所を見た感じ限定されないように思うんだが、エラい人教えてくれないかな?
slow-firstpass使わなかった場合に止まってたんで気になる。

>>352
>you would find that CRF and 2-pass at the same bitrate give roughly equivalent results.

http://forum.doom9.org/showthread.php?p=1343177#post1343177

1pass目は全体解析フェーズ。
Bitrateを内容に合わせて適切に振ること がpass nの意味と理解しているのだが、違うのか？

CRFとpass nが同じ容量になる、なんぞ偶然の産物でしかないだろ

>>358
>CRFとpass nが同じ容量になる、なんぞ偶然の産物でしかないだろ

CRFで作った動画に合わせてbitrateを設定すれば良いんじゃね？

けど2passってcrfほど激しく変動しなかったと思うけど？

ffdshowじゃ重いしCoreAVCに変わるデコーダってナンだろう？

>>361
DXVAを使えるデコーダとか。

CoreAVCの代用品ならffmpeg-mtしかないだろ
他で入手しやすいのはDXVA系ばっかだし

DivX「…」

少し前のCyberlinkのデコーダとか。DxVAは設定呼び出せばON/OFFできるし性能はいいと思う。
最近のはPack化されてて外部から使えないが。

和訳ﾏﾀﾞｰﾁﾝﾁﾝ

k-meansﾏﾀﾞ-ﾁﾝﾁﾝ

CoreAVC 2.XXは数日内でリリースが予定されている。自分は1.8辺りで一応金払って買ったんだけど、
現在のデコーダー状況であまりにも利点がなくて（ｒｙ。つまり、nVidiaのVP2チップを
使用したデコーダーはCoreAVC自体と関係なくて、Weightpを対応してる。

元々CoreAVCを買った一つの理由はffmpegに新H.264ロスレスのデコードが入る前に、
そのエンコード方式を使用することだったんだよねぇ＾＾；…

ffmpeg-mtは現在使用してるデコーダー（CCCPの最新版のビルド）。ハードウェアーデコードは
対応してないが、今のところ一番安定してる。

DivXは前から変なところでバグがありまくってるんで、信用出来ない。
速度だけはある程度出してる。

ATIのDXVAでweightpをデコードできないっぽい？

790GXだけどDXVA効いてる

>>369
デコードはできるけど画面がフラッシュするシーンで破綻することがある

>371

そうだったのかー！
てっきりエンコ時のバグかと思ったよ。
（具体的には「そらのおとしもの」のオープニング）

weightpってマイナーなん？それとも単にx264の不具合なのか

う〜む、1336でも2pass-vbvビルドがたまに止まる…
どうも1pass目で止まるっぽい。
--preset slow --weightp 0 --no-mbtree --no-psy

>>373
単純に一部デコーダーが今まで意識して作ってなかっただけ。

>>374
現時点で知られてる問題の一つです。
プラットフォームによって違う確立でたまにランダムで止まるみたいです。
安定してるビルドが欲しいのなら、revision 1318しかないみたいですね。

つまり、2passもvbvも関係ないと開発者から言われてます。スレッド化でバグが起きて、（ｒｙ

>>376
そうなの？1336でかなりの数エンコしたけど一度もクラッシュしたことないなあ
もちろんmbtreeとweightp使った状態で

>>377
かなりランダムだそうです。
250回のエンコで1回クラッシュするかもしれないし、
2回の1回のうちでもクラッシュする可能性もある。

つまり、こっちもWindows 64bitなビルドで何回もcrfで2000フレームぐらいの動画を
エンコしてるけど、問題ナッシング。なので、IRCで>>374について聞いたら
少々驚き。まぁ、開発チャンネルを見てなかっただけなんだけどねぇ＾＾；…

つまり、掲示板の方でも一応話題にはなっている

ttp://forum.doom9.org/showthread.php?p=1343696#post1343696

うちも止まった。
クラッシュしてエラーでも出してくれればすぐ気づくのに
進捗状態が進まないままで止まるんだよな。
Ctrl+Cで終了できるし。

そういや俺も1回だけ止まったなぁ
やり直したら以後再発しないから気にもとめてなかったけど
こういうのをPhase of the moonつーのか

これは安定版になるまで様子見だな

いまだに999使ってるんだけど現在の安定版っていくつなの？

>>383
<Dark_Shikari> NOTHING IS WORKING
<Dark_Shikari> go back to r1318

1192
早くもなってる。

>>371
確かに再現した
ffmpegだと再生出来るからUpdate待ちだな

PowerDVDのDXVAでもなるからこれってATI側の問題じゃね？
一番怖いのはハードウェアの問題で修正不可って事態だな。

GeForceを使っている人はこれを再生できる?
http://www.mediafire.com/?mjdm1n1mgoy

>>388
Geforceではないが、PS3でも2は駄目で1か0ならおｋ
今からやってみるが、この分だとPSPも駄目だな

ちょｗPS3でもだめなのかよ

実験終了
意外なことにPSPは--weightp 2でもおｋだった

ソースは>>388、エンコ設定は
x264.exe --profile main --sar 40:33 --vbv-maxrate 10000 --vbv-bufsize 10000 --bframes 3 --ref 3 --weightp * -o M4V*****.mp4

>>388
Geforceで確認、2は駄目でした。
QTは問題無し。

>>388
Geforceで0〜2全部再生できた。Linux64Bitでプレイヤーはmplyer使用。
vdpau使用です。

>>393
>プレイヤーはmplyer使用。
それじゃ意味ないだろ
この場合はあくまでもDXVAの検証なんだから、犬はお呼びじゃない

Win7のWMPだと0と1はおｋだったが2はヨーコ登場の閃光で破綻が出た
ボードはHD5870でCata9.10使用

ああ、よく考えたらvdpauだから意味があるのか
失礼しました

>>392
>>393の人が出来た様なので再生環境も記載した方がよさそうですね。
DXVAでMPC-HCとPDVD8で確認。

>>397
カードとドライバは？

>>398
カードはGT220でドライバは191.07です。

--weightp
ffmpeg,ffmpeg-mtでもチャプタ使ってシークすると画が崩れるのを確認。
もちろんすべての動画、チャプターで起きる訳ではなく恐らく散発的なものだが。

>>388
Win7 Ultimate 32bit/GTX 260/driver 191.07
上記環境で
MPC-HC(r1314)内臓 H264/AVC(DXVA)
WMP12
PowerDVD8 (DXVA)
すべてのパターンで問題無し

>>388 試してみた
geforce9400 + 191.07 + vista 32bitの環境で
mpc-hc 1338の内蔵DXVAで3ファイルとも化けることなく再生できた。
*pigと同じシーンを注意深く見たけど問題なし。

間違ったpngだった。
png画像と同じシーンでも化けなし。

1338
flv出力が来たが…使い道ないな…

1339
100lて…ｗ

>>399
>>401-402とGeforce問題無しか。
２人と違うのはXP ProSP3って事だけだな。

ttp://www.mediafire.com/?ymrogz3laq2
これは？

再度しっかり書きます。
GeforceGT220/driver 191.07/WinXP ProSP3
DXVAでMPC-HCとPDVD8で確認。

>>388の2
ttp://a-draw.com/contents/uploader2/src/up3500.jpg

>>407
ttp://a-draw.com/contents/uploader2/src/up3501.jpg

>>407
検証目的なんだから、もうちょっと互換性高そうな設定にしてくれ
とりあえず--ref 3 --vbv-maxrate 24000 --vbv-bufsize 24000とかそのくらいで
あと--weightp 0と1の場合をつけるとか、どこの誰のビルドかもわからないと駄目
もしくは>>388みたいにソース同梱にするとか

とりあえずDXVA(HD3850)やFlashPlayerだと動物の顔が崩れた
http://img39.imageshack.us/img39/560/weightp.png

俺ビルドでエンコしてた。

x264.nlビルドでref 3 vbvなし
ttp://www.mediafire.com/?zqkvkitwmyj
やっぱ崩れる。
ソースは
ttp://www.mediafire.com/?ghgohoywhdx

>>407
402です。
geforce9400 + 191.07 + vista 32bitの環境で
ttp://www16.plala.or.jp/na743/s.html
のmpc-hc 1338の内蔵DXVAで問題なしです。
>>408
が貼ってるスクリーンショットの部分でも化け無し。

ATiにfeedbackするしかないな

ソースの提示ってありなんだろうか

seraphy氏1339来たね。

>>388のソース設定でやってみたけど変化無し。
相変わらず2で崩れる。

RADEON HD3870, ｶﾀ9.10, WinXP SP3
2はMPC-HCとPDVDのDXVA、CoreAVC1.9.5どれも崩れるな。CoreAVCはDXVAとは崩れ方が違うけど。
DXVAのほうはコマ送りで崩れる部分のフレームの順番がおかしくなるね。

今はかみ合わない時期だな。

>>414
CoreAVC1.9.5で崩れるのは書かなくても既にわかってるからいい
元から対応してないのだから再生できる方がおかしい
CoreAVC2.0で対応

問題なのはRADEONのDXVA
ハード的な問題で修復不可という最悪のシナリオだったらどうするんだろう

ATI「新しいの買ってね」だったら嫌だなぁ…
とりあえず日本語サポートに送っておいた。

でもGeForceでも崩れる場合があるんだよね。x264が吐くストリームってほんとに
100%規格に沿ってるものなのだろうか・・・

ffdshowではデコードできるから…
…ひょっとして逆に今のところ100%崩れないのはffdshowだけ？
これはffdshowが優れているのかおかしいのかどっちだろうね。

MPEG2と違って簡易デコードが規格上存在しないのになんでこんなことになるんだろうな。

>>419
いや、ffdshowのlibavcodecでも崩れるから。
前述のチャプターの話だが。

>>418
Dark_Shikari氏にJM使えって言えと言われた。
JMのデコードと--dump-yuvが一致するならx264は規格に沿ってるんだそうだ。
試しに崩れるやつでやってみたが一致した。

とりあえず当分は--weightp 1でいくか
PS3でも駄目だし

>>417
乙です
もし直るなら、それに越したことはない
俺もSonyに送るか…

PS3でOKという報告>>310とOKじゃない？報告>>389があるんだがどっちが本当なのよ？ｗ
PS3の規格通りにエンコードしたものかどうかできればオプションも晒して欲しい

>>424
自分で>>388を試してみれば？

>>424
--profile high --crf 20 --sar 40:33 --weightp 2 --bframes 3 --b-adapt 2 --ref 3
--ipratio 1.1 --pbratio 1.1 --vbv-maxrate 24000 --vbv-bufsize 24000
ソースは>>388のavi、バイナリはｘ264.nlのr1339(x86)
結果は×、フラッシュで崩壊

それともうひとつ
今回のweightpコミットにあたっての事前調査では、開発陣はたくさんの環境でテストしたが、
素材は例の東方同人アニメしか使っててなかったみたいなDS氏の発言がDoom9にある
この発言以降ね
http://forum.doom9.org/showthread.php?p=1343545#post1343545

さらに追加
>>410のソースのy4mをnlの1339でエンコ
http://www.mediafire.com/?zdzgmiynmnu
これ（--crf 20 --weightp 2 --bframes 3 --ref 3 --vbv-maxrate 24000 --vbv-bufsize 24000)だと
MPC-HC（HD3850）でもPS3でも崩れない
シーン的にもあんまり似てないし、>>388と>>410は原因が違うんじゃないの？

>>428
私も確認した。
>>410は崩れないね。

さっきIRCでPS3持ってる人にテストしてもらったんだが>>410が崩れたそうだ。

>>430
オプションを>>428に変えても？

いや
> x264.nlビルドでref 3 vbvなし
> ttp://www.mediafire.com/?zqkvkitwmyj
のやつ。

>>428はうちでも崩れないね。

>>432
なら>>428の人が言ってる様に原因が違うんじゃない？

>>432
原因見えたぞ。
--bframes 16を3に変えたら直った。
後--b-pyramid normalは--no-mbtreeを付けないと意味無いぞ。

色々やってみたが10以上で崩れるな。
だがそれでも崩れるのは問題だろう。10超えたら規格破るとかではないんだから。

あと--b-pyramid normalは将来実装されたときに変更しないですむようにつけてるだけで意味ないのはわかってる。

>>361
Windows7についてるデコーダー。Microsoft DTV-DVD Video Decoder
Vista SP2からもついてくる

>>436
あれはあれでDXVA使えない動画だとffmpeg_mtよりはるかに落ちるぞ

DXVA使えるようにエンコすれば言いだけじゃん。
つか、DXVA使えないパラメータってどんなの？

--ref 16とか

なんだDXVAの制限守ってないだけじゃんか。level4.1までだろ大体

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

とりあえず、DivX Plus HD Profileに合わせておけば、今後発売される機器との互換性は確保できると思う。
VBVは表の通り、--keyintはフレームレート*4、--refは4まで。

>>438
CoreAVCのかわりっつーんだから、DXVAが使えないハードかも知れないよ

DXVA使えない環境ってどういう環境
ffdshowは使えるみたいだがね

ネットブックとか

http://forum.doom9.org/showpost.php?p=1344217&postcount=57
しばらくは、blind offsetの--weightp 1にしておくか。

>>445
Dylanへの通達待ちか
--weightp 1はまだ使ったことないけど安定してるの？

>>446
>>388のweightp_1は、DXVA(HD4650)で大丈夫だった。

weightp 1とweightp 2 ってそこまで結果が違うもんなのか？

>>446
DylanZA氏は現在チェックしてる最中。数時間から数日間までの時間がかかれば
バグフィックスは出るでしょう。まぁ、x264の開発速度を考えれば問題点が見つかったら
数時間以上はかからないでしょう。

r1342
Fix two issues in weightp
If analysis decided on an offset of -128, x264 would create non-compliant streams.
Fix some cases with nearly all intra blocks where analysis could pick very weird weights.
Also add some asserts to check compliancy.

修正がきたみたい

weightptest2.mp4でPS3, DXVA, Xbox
360で発生したトラブルはr1342で直りました。
FlashとCoreAVCは未だにWeightp未対応な んですけどね。

FlashとCoreAVCも近々バージョンアップするから対応するでしょ

>>452
CoreAVCのBetaBoy氏は「数日内に」とか「今週中」とか言ったんで、まだ何となく
いいこととして…　FlashとApple系だけは更新が結構遅れてくるんでしょうねぇ。

特にFlashの更新歴ががががが

>>407だけじゃなくて>>388も直ってる。
結局x264側のバグだったのか。ATIにx264のバグでしたゴメンナサイって言ってこないと…

>>454
非準拠だからバグじゃない。
正規から外れた対応をしただけ。

>>455
と思ったけど色々見てたら自信が無くなったので>>455は取り消します。

K-Meansﾏﾀﾞ-

ｒ1342で>>388
DXVA(ATi)、PS3、FlashPlayer10すべて正常を確認終了
とりあえず自分の環境では--weightp 2でも問題なくなったかな

Sonyにメール送らずに済んでよかった…

同じく1342で>>388を確認。
DXVAでMPC-HCとPDVD8問題無し。
完全にOKかな？

確認ビルドはseraphy氏とnlです。

bフレームをきりたい場合は--bframes 0でええの？

切るメリットがない

>>460
それで大丈夫

>>461
ベースラインで使いたいのかも知れないだろ
世の中にはそういったプレイヤーもある

Main以上でBを切るメリットはない
Baselineだったら --profile baseline でBは勝手に切れる

なので直接 --bframes 0 することはほとんどないです

まあいいじゃないか些細なことを

>>462-463
ありがとう。YouTubeだとbフレームを切らないと、再生時間が倍になってしまうことが
稀にあるって聞いたから。

ttp://forum.doom9.org/showthread.php?p=1344365#post1344365

まだバグが…

1342は無理矢理直したみたいだし問題はまだ内包してるんだろうな。

バグなしで安定しているのってr1318でいいんか

うん。
stable revision marker付けるのはマジでいいアイデアだと思うからやって欲しい。

まあ俺は不具合覚悟で最新を使い続けるんですけどね。

特定のオプションを使わなければいいだけだろ

大きい修正の場合、既存のオプションにも影響がないとは言えないんじゃないかな？
そういや、以前は、x264.nlにrecommended revisionって記述してたけど、なくなっちゃったね。

あ〜　そういえばrecommended revisionってあったような気がする。
最近はこのスレ見たりして自分なりに安定版を選んでるww

Flashは現在のTrunkなバージョンでWeightpを対応してるらしい。しかし、
いつ公開されるんでしょう^＾;

これでCoreAVC 2.Xが出たらApple TVだけが未対応物として残る。

Flash Player10.1　AMD・NVIDIA両社のGPUでFlash動画再生支援に対応
http://tsushima.2ch.net/test/read.cgi/news/1258453899/

weightp対応したみたいブロックノイズ出なくなってる

実はDXVAが使われてるから直ってるように見えるだけってことは…

え？そうなんじゃないの？

>>475
アニメっぽいもの（それか、画像のみのデータ＋フェード）を--bframes 16 --ref 16で
720p以上のレゾで試してみれば？大体のGPU支援はメモリーが限界になる＠そういう設定。

最近のTrunkビルドであれば、普通に対応されてる可能性が高いけどね＠CPU。

pentium3でx264のエンコしています。
みなさんのCPU教えてください

Xeon E3110

スレ違いだろ
ここに行け
http://pc11.2ch.net/test/read.cgi/jisaku/1253462180/

sageようぜ

ところでmbtreeとb-pyramid併用はどうなってんの？

併用をすればどうなるものか、危ぶむなかれ。危ぶめば道はなし。
踏み出せばその一足が道となり、その一足が道となる。
迷わず行けよ。行けばわかるさ。

weightpについて解説お願いしますm(_ _)m

weightbのPフレーム版
後は猫科へでも行って説明を読め。

>Attached is the fixed and updated version of the HRD patch.
>Trahald was right (thanks!), and the VBV fullness routine was really broken.

http://mailman.videolan.org/pipermail/x264-devel/2009-November/006551.html

Doom9の方で一応ビルドしておいたけど、shon3i氏が試したところ、
ちょっとどっかのコードがおかしいと思われｗ。

まぁ、いい進歩だけどね。前のパッチより綺麗だし、少しチェックされれば
そのうちはやっと完成されるんでしょう。

公式パッチはいつ来るんだよ…

最近話題にもなってないし、もしかしてD_S氏がむかついてそういう
ブルーレイ用の機能の開発ををやめたとか、Avail Mediaはそのパッチを社内用のみにしたとか…

「ブルーレイ用の設定」って言葉の意味を間違った奴が今年結構IRCに入って
きてるんで、むかついてもその理由は分かるｗ

分からないなぁ…あとで聞いてみるか。

そのうち --target BD とか --target PSP みたいなオプション制限用のプリセットが付きそな予感

--profile ○○でええやん

>>490
FFmpegのtargetやMEncoderのformatでやってくれたら良さそうではある。

それなら設定を外部のテキストファイルから読み込めるようにしたほうが

レスポンスファイルか。

>>493
CLI版はバッチファイルで処理するのにそんな機能は無駄だし必要ない

サブマシンの一台で長いコマンドをうまく処理できなくって(cmd.exeのバグか?)、
地味に困ってるんだけど。395byte超えると、空のrawファイル吐いて終了しやがる。

それは日記ですか？なんですか？

うち400byte超えてるけど動いてる

>>497
レスポンスファイル欲しいなって話。

>>498
複雑な自動変換バッチをサブマシンで実行した時だけ狂いやがるのさ。

x264もweightpに対応したことで、フェードの多いソースでも、DivX 7との違いはいよいよ大きくなってきた。

http://rapidshare.com/files/309364928/DivX7_vs_x264_at_4000kbps.zip
ソース: http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Match%20Point

え、DivX7なんて使ってるやついるの？

x264もって、他に使ってるのはなに？

>>502
MainConcept

>>503
DivXが買ったエンコーダーってMainConceptじゃなかったっけ？それでその二つは
バージョン違い以外同じもののはずなんですけど^^;

DivX 7もweightpは使っているはず。Streameyeとかで確認すれば良いのだろうけど。

>>500
"this file can only be downloaded by becoming a premium member"

ダメになってないファイルホストを使おうよねぇ〜
例: mediafire.com (mp4 / mkvのままでもオッケー、100MB以内に入らなかったら
　　別々でうｐして（ｒｙ) mediafireはユーザーフォルダを対応してるし。

とりあえず、weighted_pred_flagは1になっているな。

>>503
あぁ、D_S氏に聞いたらMainConcept自体の方がもっと設定が出てて、いじれるっぽい。
DivXはMainConceptの制限したバージョンって感じ。
なので、>>504 はすまぬ。

>>506
それじゃ、MediaFireに上げ直すわ。

http://www.mediafire.com/file/vyjvryq2ttg/MatchPoint_DivX7_4000kbps.mkv
http://www.mediafire.com/file/myzfkdmzjzu/MatchPoint_x264_4000kbps.mkv

x264のVBVはDivXに合わせて、これよりもっと下げるべきだった。
まあ、平均4000kbpsだし、実際には問題ないだろうけど。

Trahald氏によると、最新のnal-hrdパッチはただ、自動的に15%ぐらい「パニック用」に
VBV設定を上げていたみたい。欧州か米国の時間で今夜辺りで直されてるバージョンが
出るでしょう。

やっとnal-hrdバージョン16を切り離すことが出来そう。

>>510
1080pか・・・
720pにして欲しかった。。

1080pって逆にみにくくない？
というか、でかいディスプレー使ってるやつもあんまいないと思う。



まあ、思う。

. ... ....:: ::: ::::;;;*。+ _、_ﾟ ＋　･
　　 Λ＿Λ＿・.（<_,` ）_ﾟ ･
　　/,'≡ヽ::）m)V _ n 　 ｌ 　*
￣ﾞ-'￣`--´￣￣E_ ）.ノ￣￣

>>512
http://www.mediafire.com/file/jzndqycnwza/MatchPoint_720p.zip

>>514
thx

でも、Divxのほう壊れてた・・
jpgあたりでって、なんかとりあえず、DivXでも高ビットレートなら関係ないみたいなレスあったから
それ信じるよ。ありがとう。

50KB/sとか糞ロダだな・・

>>510
>>まあ、平均4000kbpsだし、実際には問題ないだろうけど。
2kくらいからってことでいい？　x264の恩恵感じられるのは。

nal-hrdﾏﾀﾞ-ﾁﾝﾁﾝ

>>515
すまなかった。今度は一度落として確認したから、大丈夫だと思う。

http://www.mediafire.com/file/5ztttkdmycm/DivX7_1997kbps.mkv
SHA-1: 401cb74920533869f666419eb0f31ae856c81b69
http://www.mediafire.com/file/mketyngy2oz/x264_1992kbps.mkv
SHA-1: 3f1cf645a084dbb51c5ba16437ec07f015b7afb0

1080pのソース(>>500)を720pにするのにこれだけした。

AVISource("Match Point LAGS YV12.avi")
Spline36Resize(1280, 720)

>>517
どうせ、VBVの上限までビットレートが上がる事はないだろうから、
VBVの低いDivXに対して不公平な比較にはならないだろうと言いたかった。

恩恵云々だったら、あらゆるビットレートで、x264の品質は他よりも優れていると思う。
制限されたオプションしかないdivx264の方が、互換性の高いファイルを作るのは楽だろうけど。

結局 >>466 の weightp まだバグあるんじゃね？はどうなったの？

>>520
それはそもそもweightpのバグじゃなくて、オイラのバイナリで
出るバグっぽいものだったけど、そいつを再現出来るソースはうｐされなかった。
ttp://forum.doom9.org/showpost.php?p=1344443&postcount=1083
念のため複数のソースで再現しようとしたら再現されなかったんで、
バグとしては不合格･･･かな？

まぁ、再現出来るソースが出ればGCCとか色々変えるけどね。丁度環境作り用の
シェルスクリプト書き終わったし。

>>521
nal-hrdはどうだったの？

　　　　　　　　　　　　　　　　　　　　,.'⌒ヽ 　
　　　 　　　　　　　　　　　　　　〃＾⌒＾ヽ 　　
　　 　　　　　　　　　　　　　　 〈〈（ﾉ）ﾉ）〉〉　　
　　　　　　　　　　　　　　,ヽ,、<ヽﾊﾟ ヮﾟﾉﾉ> 、＜gitのレビジョンが回って1347 da ze! 　　 　
　　　　　　　　　　　　 丶｀``、、∪、、∪ 、 ヽ、 　　　　　　　　　　　
　　　　　　　　　　　　,/｀　 ｀ヾ、、、、、、、、、ヾ、
　　　　　　　　　　　｀/　　　　ヽ、、、、、、、、、ヽ、
　　　　　　　　　　 ｀.//｀￣ヽ、ヾ、、、、、、、、、ヽ　　　 　　, - ' ヽ、
　/'~``-、　　　　　 | |　/｀ヽ　|　 |、、、、、、、、、 |、　　　 /｀　　　 |
（、　　　｀￣￣￣￣￣￣|　.|　|　 |、、、、、、、、、 |￣￣￣　　　 ,‐'
　`‐、　　　　　　　　　　　|　.|　|　 |、、、、、、、、、 .|　　　　　　　　`ヽ、
　,､‐'　　　　＿＿＿＿＿|　.|　|　 |、、、、、、、、、 .|＿＿＿　　　　　,｀
！　　　　,-'　　　　　| |ヽ、./ ./　 |、、、、、、、、、 |　　　　 ヽ、__、ノ
　｀ - ､_丿　　　　　　| ヽ、__丿　/、、、、、、、、、/
　　　　　　　　　　　　丶　　　　/、、、、、、、、、/
　　　　　　　　　　　　　ヽ、、／、、、、、、、、 ／
　　　　　　　　　　　　　　　｀｀ """"""""""""

>>522
喜べ、どんどんよくなっているらしい
ttp://forum.doom9.org/showthread.php?p=1346675#post1346675

なので、まぁ…　必要として人にとってはいいことじゃないかな？

>>521
なるほど
あれはそういうやりとりだったんですね。

>>524
いや公式に入るとかいう話だったじゃない

>>526
スローで行くと思うよ。○vail社はパッチを持っても出さないみたいだし、
まぁ、もう２度目のパッチ、これからは開発者がクオリティーチェックを行い
始めるんじゃないかな？

x264_hrd_pd_interlace_zmgorynych_20091123_irc.diffは-bff無いけどいいの？

weightpは1342で安定したとみていいの？ 一応自分の環境では再生できてるんだけど。
みんな使ってる？

weightp 2使ってるよ
今のところ問題のあるソースは自分は見つけてない
もし見つけたら、また騒げばいいさ

それに、そもそも1ならCoreAVC以外全部大丈夫だったじゃない

weightpは普通に使うべき。

nal-hrdはとりあえずパッチチェックフェーズには入った。
バグとか作者の忘れ物があるみたいだけど,ようやくゴールまで
たどり着くんでしょうねぇ。

今までに何度かBFFのソースを扱う機会があったから、やはり--bffは必要だと思う。

>>532
現在のバージョンでなくなってただけだし、普通にDoom9で書いてある通り、
その機能が付いてるパッチは恐らく近日に出てくるでしょう。

weightp1でも2でも現行のFlashPlayerで再生するとブロックノイズ乗るね
BETAの10.1待ちなのかな？

今後のx264高速化について

CPU編
・このまま、何もしない
　一番手間がかからないがコア数に対してリニアに性能が上がるわけじゃないので限界はある

・CPUの新命令に対応させる
　Intel AVXは、2011年Sandy Bridgeで対応、移植に手間がかかるし新しいCPUを購入する必要がある
　かつ対応に最低でも２〜3年かかる

GPGPU編
・OpenCL、DirectX、CUDA、ATI Stream、Larrabeeに対応させる
　今すぐ対応できて、もっとも性能が高いが移植に手間がかかるし新しいGPUを購入する必要がある
　それに、現状は覇権争い中で対応した規格が標準にならない場合は無駄になる危険性を含んでいる

>>534
サンプルうｐしてみてよ
うちは１だったら大丈夫だったぞ？

>>535
GPGPU対応は可能性低い。
GPGPU上でCPUより高速なx264用コードを書くのは難しい。

>>536
元ソース消してしまいました・・・
1342でNGだったので1347に上げても再現すればうｐします。

エンコードデコードはCPUでいいんだよフィルタリングをGPUに任せればいいんだそれがスマートだ多分

フィルタだけGPGPU対応だと、某エンコソフトみたいに効果が薄い
エンコード・デコード部分も全てGPGPUに対応させると10倍〜20倍は軽くいくな

軽けりゃいいってもんでもないだろ
CPUパワーも上がって並列化も進んでるし、
あと数年もしたらGPUでフィルタリング→CPUでエンコードが主流になると思うけどな

CPUは、もうコア単位で性能を上げるのは限界なわけ
あとは、　２年後のIntel AVXに対応させるかマルチコアのみ

しかし、Intel AVXに対応させてもSSEの２倍にしかならないから
手間の割には効果は薄い、だったらGPGPUに対応させた方が開発者/ユーザにとってもメリットがあるね

それに、２年の期間があればGPUはさらに進化している

GPGPUに夢見すぎ
x264開発者達の意見は>>537の通り

GPGPUは、夢じゃなくて現実なんだけどね

じゃないと、わざわざインテルがLarrabeeを投入する必要もないし
メニーコアとして、最終的にはIntel AVXの後継として
LarrabeeをCPUに統合する計画を立案する理由もない

x264の開発者が周りの変化に逆行するような変人でもなければ
自然の成り行きで対応するよ

NGID:tt7hwAi4

Dark_Shikari「同時に複数エンコすれ。AVX対応に2〜3年もかからんよ。まさか。
DirectXはGPGPUのAPIじゃない。そしてGPGPUは最も性能が高いわけじゃない」

アムダールの法則って知ってる？

>>547 は tt7hwAi4 宛て。

>>546 見てネットワークがじゃぶじゃぶになってソースの転送時間が充分
に短くなればレンダリングファームみたいにエンコーディングファームって
サービスも出てくるんだろうな思た。

手間に見合ったリターンが得られないからGPUは対応しないって言ってたろ
エンコは色んな計算の塊だからなんでもそれなりの速度でこなせるCPUが一番コストパフォーマンスがいいんだよ
GPUなんて一部の計算だけが速くてそれ以外は致命的に遅くて現実的じゃないんだよ

GPUエンコーダーが糞なのはそこを簡略化して糞画質になってるから
じゃあGPUのその部分を強化すればいいかっていうと
エンコ以外に使いもしないの乗っけたって値段が馬鹿高くなるだけ
苦手な部分をCPUに投げるようにするってのは
開発が死ぬほど大変な割にCPU、GPU双方に待ち時間ができて
トータルで大して速くならないという、骨折り損のくたびれ儲け仕様

こんなとっくの昔に結論が出てることまた書かせるんじゃないよ俄野郎が

理屈が通じない人間が一番やっかいだな

右を左、1+1=3と言われたらどうしようもない
残念な人だなと思うしかな(苦笑)

妄想に凝り固まった奴のほうがもっとやっかいだなｗ
開発者の言すら無視して理屈どころか脳内俺様理論垂れ流されても猿に数学教えるようなもの

ユーザーとしてはCPUに金かけたほうがエンコードは速くすむし
汎用性や安定性やエンコーダなどの管理面でも楽
それこそ>>546のように複数同時に処理すればいい

>>ID:tt7hwAi4
こんなところでキャンキャン吠えるよりも
OpenCL、DirectX、CUDA、ATI Stream、Larrabeeでも何でもいいから
今すぐ対応させて効果を実証してくれ。
そしたらギャフンといいつつ有り難く使わせてもらうから。
>>535によれば「手間はかかるが今すぐ」できるんだろ?

情報与えても判断する知性がないと全く意味ないから、これで最後にする

>>549
今のGPUエンコの画質が今ひとつなのは
画質よりも10倍〜20倍などのマーケティングの速度を優先しているから
倍精度もCPUとは比べものにならないほど速い

じゃなくて、スパコン用途や科学技術計算でGPU使えないだろ
これぐらい、分かるだろ(苦笑)

情報？妄想の間違いだろｗ
何一つ正確なもの提示してないくせに情報とか片腹痛い
(苦笑) とか無理矢理上から目線で自分を上に見せようとしても負け犬の遠吠えにしかなってないｗ

んなもん開発者に任せろ
だれかiccビルドの説明ブログ立ち上げてくれ

ID:tt7hwAi4はアク禁食らってなお代行スレつかって荒らし続ける
アスペル君と呼ばれている基地外。
マジしつこいからまともに相手してはダメだよ。
by代行スレ住人

既に数年間CPUの最適化のみを進めてきたx264がGPGPUに手を出すわけないだろ。
そんなものにリソース割くくらいならバグつぶしと新オプション追加と画質向上に力入れるのがよっぽど生産性ある。
ま誰かさんがあるrevのバイナリを元にGPU用に1からコード書いてくれるなら話は別かも知れんけど

>>554
単純計算の繰り返しにはGPGPUが有効なのは正しい。
しかし、動画圧縮のように分岐の多い計算にはCPUの方が適している。
h264では全てが整数演算なので、倍精度とか関係ない。
もうちょい勉強しろ。

-●○●
が来たのかとおもた

GPUに期待して先見性のある自分を演出(笑)

インタレ解除くらいかなGPUでやって今より速度改善できるの。
フィルタはクロップとランチョスとロゴ除去以外かけないし。

>>559 の言うことが正しい、だが今年のGSoCプロジェクト表に書いてあったように、
x264のME部分をCUDA/OpenCLに移動してみるって言うことには一応価値がありそう。

ttp://sites.google.com/site/x264cuda/
一応誰かが大学用に作ったところなんですが、めっちゃ遅いピラミッドインプレメンテーション
は完成してあるっぽい。まぁ、興味がある人はソースを覗けば色々分かるかも。

去年までレス代行をやっていたけど、このスレで代行スレの人を
見掛けるとは思わなかった。

基本ＣＰＵで、得意なとこだけＧＰＵにやらせるのがセオリーってことかな。

>>538
>>410にあるソースをr1347でエンコしてみたけど(今更だが)
weightp 1でもweightp 2でもFlashPlayer(WIN 10,0,32,18)できちんでデコードできたよ

40レスくらいついてるから何か大きな変更かと思ったら、馬鹿が1人湧いただけか
がっくり

OreAQってどうなったの？
最近全然見ないけど。

>>568
VFR氏が続けてるよ
seraphy氏は続ける気があまりないらしい

>>559
現実と君の妄想は違うんだよ
現実は、GPGPUでエンコ処理した方がCPUよりも速い
なぜなら、並列のコードが多いから
ちょっと、君の頭で理解できるかどうか難しいかも知れないが
演算には、スカラ演算とベクター演算の２種類がある、CPUが得意なのは並列化されていないスカラ演算のみ
で君の妄想と現実は逆でエンコードは並列化が可能
ネットで調べることができる知能レベルなら、理解できるはずだが(笑)H.264と並列化で調べてみると良い
君はまず妄想壁があるようだから、ちゃんとそれを直して、そして猛勉強してからネットに書き込んだ方が良いね
俺みたいにわざわざ指摘して上げるほどみんなお人好しじゃないからねネットは基本バカはスルー
ちなみに君が正しいのはH.264は整数変換というネットで調べれは細かい意味を知らなくても言える単純な知識
分岐云々はさすがバカとしか言いようがない、ちゃんと勉強した方がいい

NGID:n7Z3mjPA

NG余裕でしたｗ

>>570
>>559
言葉より行動
GPGPUでもCPUのみでもいいから今より早いx264作って鯉

言葉だけだったら
俺なんか宇宙を折り曲げて特異点をつくり、そこを抜けてワープするぞｗ
光の速さは追い越せないが、A点,B点を折り曲げれば距離は0

>>570
doom9に英語で書いてきなさいｗ

この妄想キチガイこれで最後とか言っといて日付変わってID変われば再登場かｗ
自分の無知を棚に上げてみんなに突っ込まれて引っ込みがつかなくなったのか
どれだけ自分が恥じ晒してるのかすら自覚出来なくなってるようだな

>>574
馬鹿は間に受けて本当に要らぬ行動するから、へんな煽りをしちゃならんよ。
作者に言えとか必要なら自分でwiki書けとか、余計な事言って後悔した実績が過去に有りますね。
記憶に新しいですねー。いやな思いしましたねー。
ウンコの投げ合いは、2chまでで止めておくのが良いですぞー

書き込んだ後に何気におすすめ2ちゃんねる見るとx264ベンチスレなるものがあったので見てみたら
この妄想キチガイここにも登場してて同じような妄想垂れ流して馬鹿にされてたｗ

307 ：Socket774：2009/11/25(水) 20:07:45 ID:/o7UhrYV
>>305が間違った知識をネットに垂れ流しているようなので、正しい情報を書くね

>Aviutl、他のソフトどれにしても
>GPUにエンコ支援させる機能はまだないよ

現在、GPUでエンコード処理を行っているのは
・SpursEngine
・PS3(CodecSys CE-10)
・Power Director7/8
・Super LoiloScope
・Badaboom

まだ、他にもあるかも知れないが、とにかく>>305は今後無駄で無意味な長文で妄想結論出すよりも
ネットで調べる癖をつけた方が良いな、いくらネットでも間違った情報を垂れ流すのは迷惑そのもの(しかも、自作PC板で)

しかもこいつよく見たら昨日ラデスレ(http://pc11.2ch.net/test/read.cgi/jisaku/1258778305/)荒らしてたNV厨じゃんｗ
どっかで見た文体だと思ったらしょっちゅうラデスレ関係でCUDA持ち出してはゲロ持ち上げてラデ叩きしてる有名常習犯
馬鹿すぎる

とにかく有無を言わさずCPUを良いのにした方が今は幸せになるかもしれない
そんな気がする

エアCUDA野郎は適当にスルー

CUDAらねぇ

両方NG余裕でした

CUDAとかATIなんとかより、FPGA載せてそこにx264移植出来れば

移植にこだわらなくても･･

そうだ！ 普及価格で、専用エンコードチップ載ったPCIeボードがあれば。
...USBでなんかあったな、そういえば。

ソフトウェアエンコーダがハードウェアエンコーダに速度で勝ることは無いし
ハードウェアエンコーダがソフトウェアエンコーダに画質で勝ることは無い
同じ世代なら今後も崩れることは無いと思うよ

x264並の画質でHW Encorder出れば買う（もちろんスマレンソフト付で）

>>585
それは、ハードウエアエンコーダが、リアルタイムエンコード用途だったからじゃない?

CPUとGPUの連携がこのまま進めば、ソフトウエアエンコーダの速度向上はかなり期待できるけど、
まだ当分さきになりそうだ。

民生用で専用HWだと例えばカノプのがあるよね。
ttp://www.thomson-canopus.jp/catalog/firecoder_blu/firecoder_blu_index.php

触ったことはないのでよくわからんが、
カノプのリニア編集系で利用する物っぽいのでリアルタイムエンコ用でもなかろ。

リニアじゃねぇ、ノンリニアだな。

画質についてはやっぱりよくわからんが、
x264ほど豊富にオプションつけて好き勝手なファイル作ったりはできなさそう。
行列いじったりとか。

>>588
それ、基本的にはこれと同じものだよw
http://www.leadtek.co.jp/multimedia/winfast_pxvc1100_1.htm

そっちも念頭にあったので「例えば」と枕を置いたのよ。
記憶によればTMPGEncとセット販売もしてた様な…。

ま、非リアルタイムでも画質追求ならx264がオプション沢山つけられる分有利。
オプション同条件でも、速度はHW,画質はSWじゃないのかな。
つまり>>585に同意って事。

>>576
つまり、今のCPU使うよりより速いGPU版x264を作ってから来いと言い続ければ、彼はきっと作ってくれるに違いない。

K-Meansどうなってるんだろう。待ってるんだが。

1352

VFR氏のビルド、r1347以降でHAQ使うとすぐ落ちる。
CPUは対象外のAthlonX4 620だが。

OreAQ使ってるが落ちないけど

PhenomII X4 955BEだが

>>595
こっち
http://pc11.2ch.net/test/read.cgi/avi/1252765934/
ちなみに俺は落ちない（Q9450)

HAQでAMDにない命令使ってるんじゃね？

>>595
俺も落ちる
-VAQ+HAQするとおちないけど

Q9450では3回テスコで落ちなかったけどE7200では昨日仕掛けたのが今朝落ちてた@x264.exe(OreAQ) --no-mbtree --weightp 0 もちっと検証が必要か

だからVまにビルドだけの話なら専用スレ行けって

そいつはすまなかった
が何だかんだ使ってる人多いっていうね

Vまに乙

Doom9のIPが変わってそれがDNSに反映されてないらしいから書いておく。
ttp://85.230.118.136/

>>604
OpenDNSではまだ繋がらないから、助かった。

>>604
ありがとー

ttp://www.doom9.org/
の方にもニュースに書いてあったんだよねぇ･･･　一時期本当にただ落ちてたって時
があった＾＾；　管理人が６週間ぐらいいないんで、その間はDNSが更新されないでしょうね。

日曜なのに誰もいない…

ttp://forum.fushizen.eu を復活させてみた。名無しで書き込むのも可能で、日本語
も英語もオッケーということで（CAPTCHA代わりにエンコード関連の質問が出てくる）。
（DNSがまだ更新されなかったら x264.fushizen.eu と同一IPになってます）

とりあえず、BugMaster氏が実験的に作った新AQモードのバイナリを
ttp://forum.fushizen.eu/index.php?topic=2.0
に置いといた。後で、最新のMsys/mingwの組み込みなどについても色々書く予定です。

ブルアーっ

hostsに
85.230.118.136 forum.doom9.org
64.34.199.14 forum.fushizen.eu
を追加だ！

>>609
ICCビルドについても宜しく

>>611
了解。自分も未だに試してない環境なんですけどね、Intel社のコンパイラは。

フリーだったらいいのにねぇ…

icc使っても劇的にx264早くならないと思うな
前Linuxで試した時そう感じた。かなり前の話だけど
x264最適化かなりしてあるから、gccでオプション弄ってもそう変わらないと思う。
てっか変わらなかったような。これも昔でrevが3桁のときの話だけど
アセンブリも多いし、むしろiccでAviSynthのフィルターを最適化したほうが、速度上がるかもしれない

Core i7だと40%くらいがアセンブラ化されてないってDoom9で見たな。
前実験したときは-march=core2で結構変わった記憶があるが…その内また実験してみるか。

>>614の意見とは同感です。

だけど、まぁ…　最近Cygwinをおすすめしてる人が多いし、一応Msysと違った
環境をたまに試すためICCを設置しようかと思った。

>>614
俺もLinuxだけど、少し早くなるだけ。
i7は試してないけど。
逆に、ATOMのようなインオーダーCPUだと違いが出やすかったりするかな。

スレチだろうけど

XPからwin7(64bit)にしたらエンコ速度落ちたorz
誤差ってレベルじゃない・・・

俺は変わらんけど

>>618
CPU、メモリはどうなってるのか
使ってるx264は何ビルドなのか
フィルタ類はなにを使ってるのか
そういう情報もなんもなしにエンコ速度がどうこう言うもんじゃないよ

俺も変わらん。
こういう頭の悪いネガキャンしてる人ってまだいるんだね。

64bitのWindowsを使っている人は、これを使えば、32bitの頃よりも数%速くエンコードできる。

http://dl.dropbox.com/u/3191920/x264%20Launcher/x264_x64.2009-11-28.7z

フェードが目に見えて綺麗になるからweightp 2を試してみたが
crf 28で出力したものは問題無いのに、ほぼ同じサイズになるように2passエンコで出力したファイルを
現行FlashPlayer10を使ったプレーヤーで再生するとシーンチェンジ直後のフレームを中心にブロックノイズが入る
QTやAviUtlのmp4プラグインでは問題無いんだが・・・Flash側の問題なのか

過去レス読めよ

そんなことより更新きてる
1353
Avisynthがらみ

Automatically construct input scripts for almost any input file.
Tries ffmpegsource2, DSS2, directshowsource, and many other sourcing methods, based on the input file extension.
Automatically converts to YV12.

こりゃ便利だ。

どんなときに便利だとおもったの？

DLしたファイルエンコする時だろｗ

中間ファイルのAVIをスクリプト書かずにぶっこめるじゃないか。

TMEで編集済のMPEG2をインタレエンコとか
いろいろ手間が省けることは確かだ
そういやこれのConvertToYV12ってインタレ判定どうしてるのかな？

中間ファイルには、avs2yuvを使ってy4mを出力するのが楽。
今回追加された機能も、何かと便利だと思うが。

音声はどうするのさ

TSから取り出したAACを、aaceditでカットだけしてそのまま使う。

さっそくx264.nlの1353で1000フレームで試してみた
mkvとflvは大丈夫だけど、mp4出力はなんかおかしい
MPCHCだと再生できないし、smplayerだと再生時間が表示されない
どのみちmp4box通すから実害はない？けど

原因分かった
拡張子がmp4になってるだけで、出力はrawになってるわ、これ

な、なんだってー

x264.nlのビルドってGPAC無しじゃなかったっけ？
Bobor/Jarod氏は前からGPACのこと嫌がってるし。

うちの公式へ転送される64bitなビルドは普通にGPAC付きだけど。

>>633
うちはmkvmergeでカットしてるわ。
TheFluff氏はそのためのPerlスクリプト書いたし
ttp://www.mod16.org/hurfdurf/?p=33

でもhelpみたらGPAC support (yes)になってるよ
techouse版でも同様だし、そもそもavs自分で書いても駄目みたい

と、もう原因見つかったか
Vまに氏はえーな

10Lだったなぁ
再ビルド（ｒｙ

core7i買った
　　　↓
重いオプションで、5pass以上のエンコードができるようになった
　　　↓
SD解像度なら、映像ビットレートで150kbps前後でSSIM0.995以上が出るようになった
　　　↓
これ以上、やることがなくなった　←いまここ

設定晒せとかいう輩もいそうだが、教えてやる気はないw
自分で頑張れ

どこの誤爆？

7iって新型でたのか

たまにはPhenom�Uも思い出してあげてください
主にSSE5のことです

SSE5ってBulldozerの命令セットじゃね？

>>641
誤爆 ｸｽｸｽ

初心者が多そうなスレに書き込んで優越感を得ようとしたら
よりにもよってここに誤爆とはいい度胸だな

5pass　ｗｗｗｗｗｗ

PCの処理速度が上がったからって重い処理させていればあまり意味ないような

まあ、corei7持っているからベンチも兼ねてエンコ初めて1ヶ月で>>641は達成できたからな
君らみたいに、ひとつのアプリに何年も情報共有する必要性は感じられないね

この程度の知識は、休日だけの1ヶ月もあれば誰でもマスターできるね

引っ込みつかなくなるパターンか

　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

黙ってればいいものを

恥の上塗りってやつね・・・

日が変わる前にぜひコテつけてほしいなｗ

i7なんて2万で買えるじゃん
そんなもんで自慢されてもｗ

r1354
10L in r1353
Broke mp4 output.

test

だれか、atom で x264 使ってる人いる?

実写でサッカーとかの長編用の設定
参考になるサイトとかない？

>>660
デフォルト値でインタレエンコすればおｋ
少しでも容量減らしたいなら--preset veryslow --level 4.1とかでいいでしょ

--sar 4:3 --interlaced --nal-hrd --vbv-bufsize 31250 --vbv-maxrate 25000
ソースが1440*1080(TFF)だとすれば、こうしておけば良いわな。

インタレ保持するメリットって何？

>>663
MCBobやらTGMCやら使わんで済むし、ファイルサイズも60pよりは遥かに小さい

>>663
スポーツ物は動きが大事だろうから。
Bob+リサイズをして、1280x720@60000/1001fpsにしても良いだろうけど。

x264で60iをインタレ保持したのはインタレ解除しながら再生すると、
ソースによってはE8500でも不足するからなぁ。
仕方がないから30pで妥協。

エロも動きは大事だぜ、特にきじょｒｙ

>>666
フルHDヌルヌルのはずのAtom＋IONなPCでも、60iは全然だめだったw

BDと同じような設定ならIONでいけない筈がないんじゃね？

DXVAを使える環境なら、1080iのこれを正常に再生できるはず。
http://www.mediafire.com/?ooimmwjdjve

IONならDXVAでインターレースもぬるぬるデコードできるはずだが

>>668
60i?
なんだそりゃ

1920x1080の60p（59.94fpsプログレッシブ）のことか？

それならアムでもインでもクアッドレベルにして、
DxVAは切ってCPUのみで再生にしないと再生できんぞ
このスレの趣旨からしてH264なんだろうから

1440x1080にした60pならDxVAでもぎりぎり再生できるが
今のDxVAチップはとにかくBD再生に間に合えばいいってんで
1920x1080なら30p+αのところに限界がある

>>669,671
そのはずなんだけど、やっぱり設定が悪いのか。
再生側の負担になる項目というと、デブロックフィルタとか？

>>672
いやいや日本のテレビ番組の基本の60iの話です

？？

>>62
BDの規格には1920x1080@60iもあるんですが

>>674
なんか全然分かってない厨かｗ
日本のテレビはね、30iなんだよ
要するに1/2フレーム（インターレース）を1秒間に59.94回送ってる
だから、1/2フレームｘ59.94/秒＝インターレースによる29.97fps＝30iな

高精細度テレビジョン放送 - Wikipedia
http://ja.wikipedia.org/wiki/%E9%AB%98%E7%B2%BE%E7%B4%B0%E5%BA%A6%E3%83%86%E3%83%AC%E3%83%93%E3%82%B8%E3%83%A7%E3%83%B3%E6%94%BE%E9%80%81

30iｗｗｗｗｗｗｗ

>>677
これ以上恥上塗りする前に寝とけ

>>677
なんか全然分かってない厨かｗ

これは恥ずかしい

>>69->>61

日本のテレビが29.97i（30i）ってことすら分かってない馬鹿か
おまけにID変えて連投かよｗ

世も末だな
つーか、オマエ、x264に手を出すのは100年早いぞｗｗｗｗｗ

>>680->>682

日本のテレビが29.97i（30i）ってことすら分かってない馬鹿か
おまけにID変えて連投かよｗ

世も末だな
つーか、オマエ、x264に手を出すのは100年早いぞｗｗｗｗｗ

ID:7zcG0+JI
なんで、基地外につきあうの？

>>684
試しに30iでググってみろよ
そして二度とここにくんな

二日続けて変なの沸くとは。
ID:zCWZmkxr=ID:7zcG0+JIだったりしないよな・・・

30i(昔の人の言い方) = 60i(現代人の言い方)

しかし天は何のために半獣なんてものを導入したんだろうねぇ

誤爆orz

十二国記乙

テンプレ見直さないか？
Enhanced Avisynth input supportが入ったことだし。

いいだしっぺの法則

http://hideyoshi.2ch.net/test/read.cgi/download/1258644452/278

278 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2009/12/02(水) 00:54:11 ID:PBE7NZHdO
>>277
解像度を上げる点で劣化するのは否定しないが、SDソースを1200x900に引き延ばすのと、
アプコンでエンコした物を1200に引き延ばすのとではキレイに出るのは当然後者
お前の考えてるアプコンっていうのは出力サイズ数値をいじってエンコすることじゃねえの？単純にはそうじゃないよ
正しいアプコン処理をすれば、例えば曲の文字(ltwとか)がギザつかない。
動画自体時系順列だから、後半の方が汚くなるのは仕様
インターレスも完璧にしてるし、丁寧だろ。それにペグ4ってなに？H.264なのになんでいじるわけ
そっちの方がよっぽど馬鹿らしいわ。ノーマライズもチャプターも出来てるからこれ以上編集するとこないだろ
しいて言うならシクシクを抽出とかだが、そんなのは勝手に無劣化でやってくれ。QTProとか使えば簡単だわ

ttp://long.2chan.tv/jlab-long/10/s/long63342.jpg
ttp://long.2chan.tv/jlab-long/10/s/long63343.jpg
ttp://long.2chan.tv/jlab-long/10/s/long63344.jpg

279 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2009/12/02(水) 00:58:34 ID:YVt0vmfTP
>>278
DFやチョコのエンコ殺しのとこで一時停止すりゃ動画のクオリティが分かるよね

えーと、二重化？
こんなもん貼られてもどう反応すればよいやら…
ところでエンコ殺しって何？　グレインたっぷりの回想シーンとかのこと？

リンク先のやりとり見るとなかなか面白いｗ

15時間かけてこれほどの動画を作り上げるとはｗ

やっぱ映画の粒子は潰れちゃうのか・・・
いろいろ思考錯誤してたけど無駄だったのね・・・

アニメもペッタペタにしてる奴いるしな

--tune grainを試してみたら。

ぺったんぺったんつるぺったん

>>700
アドバイスありがとう

>>688
NTSCのテレビ放送が30iから60iになったと聞いて飛んできますた
いつからそんなお馬鹿が湧いてるんだ？
つーか、どこかのアホが書いたウィキの嘘八百を鵜呑みにしてる脳タリンか？ ｗ
60pと60iでは数字の意味が違うなんて
そんなデタラメが技術用語にありうるるわけ無いだろ、JK　ｗｗｗ

もういいよ飽きた

ところでなんで、SDソースだと左右合計8ドット削ってsarでアスペクト比
調整するのに、HDだと、クリッピングしてから、リサイズするのがよいの？

スレ違い？

今は30iなんて言い方しないのにね
http://www.avchd-info.org/format/index.html

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

ちなみにBDの規格でも60i(59.94i)表記だよ (pdf注意)
>>703の30i(笑)の規格は知らないけど
http://www.blu-raydisc.com/Assets/Downloadablefile/2b_bdrom_audiovisualapplication_0305-12955-15269.pdf#page=17

30iかぁ、おかしいなぁ、うちのアナログは60iだよ

おかしいねぇ

規格書もどこかのアホが書いた嘘八百なのか、それとも「日本のテレビ」は違うとでも言い張るのか

今も昔もねーよ
1フレーム2フィールドでどっちの数字にインターレースを示すiを付けたかってだけだろアホか

60iというのは、そもそも60Hzの垂直同期でインターレース走査という意味だから、
30iは今も昔も誤用

>>703
いいかげん自分の間違いを認めたら？

これからも1日1回書き込んでくるに1ペソ

フィールド単位で数えればよい　っと

ARIB STD-B32にも60iはあっても30i(笑)なんてものはないね
http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v2_2.pdf

　　　　　　　　　＼　　　∩─ｰ､ 　　　====
　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　====
　　　　　　　　　　　 ＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

r1354で作ったmkvをmplayerで再生するとシークできない

MKVToolnix通せば？
前はおｋだったの？

30i厨哀れｗ

はい、これで終わりにしよう。

x264 って、icc でコンパイルしてもあんま効果ないんだな。
コア部分がアセンブラで書かれてるからかな。

>>718
こっちでやってみたが、そもそもｒ1016でもだめじゃん(smplayer使用)
mkvmerge通せば大丈夫だけど

つ　x264_icc_r1342.diff

mplayerもSMplayerもmkv mp4 x264の再生にえらく弱かった気がする
だいぶ前の話だが

今日も30i厨くんは来るのかな
彼はとてもおもしろい

まぁスレチだから来ない方がいいんだろうが

荒らしには
　レスをするなと
　　いいながら
一言多くて
　またスレ荒れる

B pyramidを使うのに、必要なのってデフォルトから変更するのは
--b-pyramid
--no-mbtree
--b-adapt 0/2・・・デフォルトの1はダメ
くらいでいいのかな。昔Single Threadでないとだめだったとか
あったけど、今は大丈夫みたい。

B pyramid と MB tree ってどっちが強いの？

mbtree

併用できるようになるのはまだか

b-pyramid使う利点が全然わからん
画質がよくなった試しが無い

b-pyramidは圧縮効率に関わってくるんじゃないの？
使ったことないけど

mbtreeは見た目変わるけどpyramidは見てもわからん
SSIMなんかは上がってんだろうけど。

ttp://doom10.org/

ｗ

最大70%もSSIMが良くなるmbtreeと比べたら利点は小さいだろうけど、pyramidで数%は良くなるはずだから、
早くそれらを併用できる様になってほしい。

もう1年くらい更新してないけど新しくしても使える自信ないわぁ

1173から更新してないわ

>>733
DS氏は本気でDoom9に戻る気はないみたいね
VideoLANの公式フォーラムも変更されてるし

他のソフトが追随するかどうか…
下手したらx264専用フォーラムになっちまう。

mbtreeはYoutubeなどの低ﾚｰﾄで効果があるだけなのであまり興味はないな
俺もr1271から更新してない

weightp使えるから更新した方がいいよ

まだ1163だわ

weightpも一長一短
ハードウェア互換がシビアになってちゃんと値を設定しないと再生できなくなるし

>>742
えっ、現在ちゃんとH.264の色々守ってるデコーダーだと対応してるし、
PS3, Xbox360, PSPなどは普通に対応してるし。一体何が問題なんでしょうかね。

ちゃんとルールを守ってないメーカーの製品を買ったらバグレポを送って（ｒｙ
自業自得って奴だね。

x264側のバグは殆どつぶされてるはず。それでもバグがあるって言うのなら、
ちゃんとしたバグレポくれたまへ。

だからそういうんじゃなくて今までなーなーで再生できてたのに
weightpを入れたばかりに規格外になって再生できなくなるって話だよ
そうやってすぐムキになる人って何なの

>>744
具体例はあるの？

ところで本当にシビアになったか？

別になってないな
CoreCodecがラデユーザーをないがしろにしてることが改めて確認されただけだ

>>744
規格外な処理をしてるのはむしろデコーダ側だろ
まあ俺もweightpは使ってないけどね

>>744
別に>>743はムキになってないと思うが
もしweightpが再生できなかったのなら、そんなデコーダは捨てるべき

規格外ってｗ
何か勘違いしてるね〜

噂によると有料のくせに規格外でしかも半年以上更新がないデコーダーがあるらしい

weightp実装直後は確かに規格上問題のないプレーヤの一部で再生がおかしくなる問題があったけど今は解決してるはずだが

それはx264側のバグで規格外のストリーム吐いてただけの話だな
今のは問題ない(規格内)

>>733,737

>ttp://roundup.ffmpeg.org/roundup/ffmpeg/issue1451

やっちゃったな。neuron2は痛い人ですね。

>I took the code from ffdhsow. I was not even aware of any #if
>CONFIG_GPL lines or even that there was the possibility to
>compile for GPL or LGPL. The license file in ffdshow
>continues to show LGPL. So you need to put those guys in the
>Hall of Shame too.

下手に出て相手に要求する時に、この言い回しじゃ逆撫でだろ。

/.でやれ

次スレ用>>1
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://doom10.org/index.php?topic=3.0 (Getting the latest x264)
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:x264、mencoder、xvid_encrawのGUI)
http://kurtnoise.free.fr/mp4tools/　(mp4box)
http://yamb.unite-video.com/　(YAMB)
http://bunkus.org/videotools/mkvtoolnix/　(MKVToolnix)

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

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

テンプレ続く>>2-4

guiスレ新しくなってた
http://pc11.2ch.net/test/read.cgi/avi/1258081149/

>>756
これも追加しないか？

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://pc11.2ch.net/test/read.cgi/avi/1247319611/

あとバイナリからseraphy氏以下は外していいんじゃないの？
seraphy氏は最近afs対応以外やめちゃったし、Vまに氏は本人が嫌がるし、
そもそもitvfr版をずっと続けてるぽむ氏はのせてないんだし
meguiは更新止まっちゃったし、mencoder、mp4box、mkvtoolnixはスレ違いになるし
それとFAQもvfwが流石に廃れた現在では、いいかげん要らんような気がする

Getting the latest x264
http://doom10.org/index.php?topic=3.0

バイナリを探すにしても、ごちゃごちゃしたDoom9より、こっちの方が分かりやすいな。

doom9やら10やらLGPLやらいったい世界でなにが起きてるの？

neuron2、DGAVCDEC引っ込めたんだね。

DLLを他所からもらってきて同梱してるのに、
　必須のライセンス文書を同梱しないとか、
　ライセンスをきちんと確認しないとか。
　GPLコードとリンクしているのにソース公開を拒否したりとか。
そういうライセンス無視がいくつか見つかったって話。

Doom9のほうはよく知らん。forum ruleの変更に反発とか？

法律や条約でもないのにGPLなんか知った事かって気はする。

2chだってローカルルールを守るのは必要なんや！

>>761みたいな子供はGPLを理解出来ないから契約は無効って気もする
子供にはGPLのソフトを使う権利が無いと言えるかもしれない

ごめん>>761じゃなくて>>762ね、子供は
子供可愛いよ子供

子供に2chとネットゲーは触れさせちゃいけない
これは躾と言うか親の責任だな

2chとネトゲを触れると子供になるんだよ。

GPL訴訟の判例はすでにあるよ。
まもらにゃならん。

GPLは契約なんだから違反すれば訴訟もあるだろ。

うむ

Doom10のfaviconが11ｗ
なんぞｗ

>>771
"It's one louder."
ttp://en.wikipedia.org/wiki/Up_to_eleven

1359

1360 w

話ぶったぎるがLarrabee開発中止らしい
俺含めてGPGPUに少しでも期待してたやつマジ涙目だな

ソースは？

あぁ、ごめん、はり忘れたわ
ttp://www.semiaccurate.com/2009/12/04/intel-kills-consumer-larrabee-focuses-future-variants/
ttp://www.geocities.jp/andosprocinfo/wadai09/20091205.htm
ttp://www.internetnews.com/hardware/article.php/3851421
あと正確に言うと開発中止じゃなくて商品化の中止か

最初に引っ張ってた人はもうIntelにいないし多少の路線変更は仕方ないってところか
まぁ理論的に他ががんばってるからそれでいいと思う

これまでずっとmkvで出力してきたからわからなかったんだけど、mp4で出力すると
initial delayの数値で初期delayを調整して出力してくれてるんだよね？
MP4Boxを使ってこのmp4ファイルと音声を再MUXすると、delayはちゃんと引き継がれてるのかな？

インタレ出力の再生互換性の問題はいつ解決するの？

>>780
IRCで聞いてくれば？

vfr氏のサイトを参考にしてmsys環境構築し直したらpthreadsが動的リンクされるようになった
pthreadGC2.dllが見つからないとかエラーが出ちゃう
誰か助けて

pthreadのMakefile見たらGC-staticが無くなってる？
変わりにVC-staticがありやがるんですがこの辺が原因？

>>782
http://www.dll-files.com/dllindex/dll-files.shtml?pthreadgc2
これ落としてx264.exeと同じフォルダに入れればおk

>>784
それはわかるんだけど静的リンクさせたいのです
>>783はGNUmakefileがあるので関係なかった

>>785
msysとかを入れなおすときにTDMのGCC入れたんだったら、
lib に入ってる libpthread.a を削除してないとかじゃない？
あと自分でGC-staticでビルドしたptw32もpthreadGC2.dllじゃなくて
libpthreadGC2.aって名前で/mingw/libにコピーした方がいいよ。

>>786
ビンゴです！ありがとうございます
元からあったlib/libpthread.a,libpthreadGC2-static.aを削除してコンパイルしたlibpthreadGC2.aをコピー
usr/local/libにもpthreadGC2.dllをコピーでいけました

>>787
スレ違いかもしれんが MinGW でビルドしたライブラリとかは C:\MinGW (/mingw) 以下に
おく方がいいと思うよ。TDM も mingw 本家も gcc は --prefix=/mingw でビルドしてるから、
/usr/include や /usr/local/include とかがデフォルトのサーチパスに入ってない
(ld の方は /mingw/lib の後に入ってるけど) とか、その辺がLinuxとかと違うので。

Vまに氏のHPどこ？？？

VFR Maniacでググれ

--preset(+カスタム)でパラメータ指定した時、出来上がった動画のEncoding settingsにpresetの値を記載する方法はバイナリで文字列いじるしか無い？

>>791
それを記載するのに一体何の意味があるんだ…？

便乗して質問してみるんけどmake fprofiledでコンパイルした方がいいの？
fprofiledって何？

>>793
アルゴリズムを実行して、どこがどうなってるかをチェックしてから再ビルドする
という方法ですよ。つまり、そういう風にテストされる後、どの部分がどれぐらい
使用されるとか色々で高速化ができる。

少し最終的なバイナリを高速化するという意味。AVSスクリプトやらY4Mファイルが
あれば出来ます。

>>794
速レスどうも
可能であれば適当な動画を用意してfprofiledでコンパイルした方が高速なバイナリができるんだね
速いにこしたことはないし試してみよう

最近このスレ難しくて理解できない

自ビルドの世界へようこそ
ttp://zoome.jp/VFR_maniac/diary/89

あとJEEB氏？
テストされ「た」後の方がいいと思いマッスル

ｼｬｰｸさん何処行った…

>>777
Larrabeeが1TFlopsでAMDのが5TFloｐsっていうのがすごいな。
AMDのが2000個あれば京速になるわけでしょ？
今は１つのマザボに２つのVGAを積めるから１億円くらいでマジで作れちゃうのか。

延々と意味のないループを回し続けるだけの「京速」なら作れちゃうんだけどな

プロセッサは何でも良いけど、
結局性能の良いコンピュータ作るとなるとネットワークとかで金かかるんだよな

まあプロセッサも単精度は速いけど倍精度は1/5以下になりますなんてRadeonみたいなヤツだと、
倍精度必要な用途には無理だけど

通信だってパソコンに複数のポートを用意して隣接するやつは直結してやったら速いんじゃないかと思ったんだけど
隣接だったらスイッチングハブ経由したらよかったんだよね。

でも、スイッチングハブでも上位のハブを経由するときに詰まるから、
ハブでは横方向に、直結で縦方向に繋げば、それだけで１６ポートなら３０倍速くなるんじゃないかな。
そして横方向で端っこのやつはハブ越えの隣接と接続すれば、空間移動は全て直結の通信で移動できることになる。
ま、プログラミングと設定がめんどくさいけど。

俺らが考えるようなことはｴﾝｼﾞﾆｱが既にやってるって…

「素人の柔軟な発想」って実際にはまるで役に立たないんだよな
仕分け見てればわかるだろ

技術の垣根を越えた発想の中にはヒントとなるものがあるかもしれない

b-pyramid+mbtreeクルー？

>>805
他のジャンルの専門家の意見は貴重だけど、
素人や文系はまるで役立たず

1361ってエンコ関係ない？さっぱり理解できない

画質には何ら影響はない。

俺らみたいなパンピーはバグを見つけて
報告してあげることくらいしか役に立たない

もうここしばらく更新してない
helpでバージョン見てみたら今使ってるのは1137だった

専門家でも理系でも役立たずは多いがな

スケキヨ！

なんだい母さん

経験上、役立たずが多いとか言っちゃう人自体が、役立たずであることが多い。

それ再帰的に自分に降りかかってるがな。

mbtreeを使うならAdaptive Quantizationは必須って知らんかった
ずっと無効にしていた･･･俺バカだｗ

某所のmbtree記述からすると、
無効にしてても自動で強度0のAQONになるらしいけど？

--aq-mode 0でエンコしても
ヘッダ見るとaq=1:0.00になってるな

r1260に更新したら最後にちゃんとConvertToYV12()してるのに
[waning]: converting input clip to YV12
と出るのだが、こういう仕様になったの？

( ﾟ ヮﾟ) r1369

Add support for MB-tree + B-pyramid

!!!

あれ？vfr氏fgoの改造パッチの公開止めたのかな？

単体パッチは別ページに移ったのね
fgoはr1369用の修正簡単だったけどthread_poolは修正あり過ぎて俺には無理だ・・
Komisar待ち

>>824
thread poolは#x264devの方で話題になってたから、Gitに入ることを期待してる。
kemuri氏も一応バージョン作ってたらしいし。

thread poolって何するパッチなの？

>>820
Avisynth2.6使ってない？2.6だとそうなるみたい
どっちのバグかは知らんが試してみたらConvertToYV12()したあとにYV12専用フィルタが正常に動作しているようなので
少なくともその直後はYV12になっていて出力時におかしくなってるのかも

>>820, 827
仕様らしいです。
AVS2.6では新しいカラー空間がいくつか追加されてて、その全部がYV12として
確認されるのだ。そのせいで、強制的に最後にはConvertToYV12が入ります
（YV16/YV24などの可能性がありますので）。

もちろん、AVS2.6のみの場合ですよ。

JEEB氏の1369をDLしてみたんだけど、fullhelpにいくつかtypoあるみたいな
こういうのって開発者的には気にするもんなのかしら？

>>829
一応コードより気にならないものなんだけど、例えばここに書いておけば開発者
に伝えておきますよ。タイポってのはやっぱり書きミスだし、出来るだけ直したい
という思いは開発者にもあると思いますよ。

では、presetのところで
ultrafastのところで --no-b-adapt -> --b-adapt 0、あとこれにはno-weightbはのってないけど、
入れたほうがいいのかも（bframes 0でもno-b-adaptは入れてるわけだから）

veryfastのところで--partitions i8x8i4x4 -> --partitions i8x8,i4x4
実はカンマは要らないとか？かも知れない

--tune animationのaq-strengthは0になってるけど、これは0.6からの変更された？
まだエンコはしてないので未確認

ぱっと見ではこんなもんですね

>>831
とりあえず、#x264の方で発言しておいた。サンクス。

>>831
そして開発者のローカルレポではコミットされた。次のレビジョンには表示が
直る。

>>802
SCSI黎明期を思い出すな。

Add support for MB-tree + B-pyramid

mbtree+b-pyramidはすごいな
b-pyramidなしに比べて、エンコスピードが少し上がってssim、psnrともに向上し（つーても見た目の違いはないんだけど）、
さらににデコードが思いきり速くなってるような
これが俺の勘違いじゃなければいいんだけど

>>836
b-pyramid使ってデコード軽くなるわけねえじゃん

Bフレ増えるらしいから…
あれBフレ増えたら速くなるのか遅くなるのかどっちだろう？

これを使って、デコード速度を調べてみたら。
http://haali.cs.msu.ru/mkv/timeCodec.exe

>>828
AVS2.5xに戻さなくても大丈夫ってこと？

/* always call ConvertToYV12 to convert non YV12 planar colorspaces to YV12 when user's AVS supports them,
as all planar colorspaces are flagged as YV12. If it is already YV12 in this case, the call does nothing */

ってあるから大丈夫だろう。

>>827-828
サンクス。AVS2.6使ってます
今のところ特に問題もないので気にしないようにしときます

更新きてるぅー

b-pyramidは画質落ちるだけで対して良い事無いんじゃなかったっけ？

>>844
ソースによる。自分で試せばいい。とあるニコニコ向けにエンコしてる人の場合は
SSIM等が上がったけどね（実際に出力されたファイルは見てないので、そこまで
役に立たない情報なんですけどね）。自分で試した場合は、普通に画質が落ちた
ようには見えなかったし。

mbtreeと一緒に使えるようになったし、最新のレビジョンに更新して、試せばいい。
画質はもし落ちても、そこまで落ちないと思うし（画質アップも開発者によると、
0-4%ぐらいに限るし）。

ソースによって画質が若干落ちても容量縮めたいときに使うオプション
と俺は認識してる＞b-pyramid

同じ容量での画質は上がる。

自分も846と同じ認識だったけど、その分をビットレートに振ってやれば画質が上がるって事か
mbtree + b-pyramidでも十分意味があると

意味がないのにわざわざサポートすると思ってるの？バカなの？

よーしパパ b-pyramid 入れて crf17 にしちゃうぞー

b-pyramid はPS3で再生する場合、よろしくない。

>>850
通報されたやつ思い出した

>>851
それは昔の話だよ
今はハード互換が高くなったから大丈夫だよ
--b-pyramid strict

>>853
それでも、
そんなおまじないするぐらいなら、
crfをひとつ下げた方がいい。

そもそもPSPでは使えないからな＞Bﾋﾟﾗﾐｯﾄﾞ
同ﾋﾞｯﾄﾚｰﾄでも画質は変わらない
同様にBﾌﾚｰﾑも3より2の方が画質がいい塩梅

昔から頑なにb-pyramidを否定する人がいるけど否定するなら数値出せよ
pspとか笑わせるなよｗｗ

>>854
crfひとつ下げてb-pyramidも入れれば更に良くなるだろ
バカなのか？

>>854
同じビットレートでの画質の話をしてるのに何言ってるの？
crf一つ下げたら画質が良くなるのは当たり前の話じゃないか

>>857 >>858
ハード互換を考えて、リスクをとらないというだけ。
b-pyramid切った時にcrf下げるのは代替的な気休め

別に否定はしちゃいない。
サポートしている特定ハードで再生する前提なら使えばいいじゃん。

b-pyramidはアニメ向きかなって思ってたんだけど、実写でも試してみるかなぁ

2passでエンコするときはb-pyramidを入れればいい
crfでエンコするときは入れても大して恩恵がない（容量減らしたかったら使えばいい）

なんで皆そんなにカリカリしてんの？

容量減らした分画質が落ちるなら別に使う必要ないんだけど
その辺どうなってるのかが気になる
画質劣化が極小で容量低下が顕著ならやる価値あるな

b-pyramidは容量を抑えつつ画質向上を図るオプション
画質が悪くなるわけではない

>>863
ほんとに？場合によっては画質が低下するとかどこかで見たけど
同サイズあたりの画質が向上するなら使わない手はないな

以前のx264の--b-pyramidは、DPBの計算がおかしかったけど、
今は直っているから、normalでも互換性には問題ない。

特別制限の多いBlu-rayにはstrictが必要だけれど。

ほんとにー？とか、どうなんだろうとか言っている余裕があったら比較エンコすればいいのにと、いつも思う

比較しても質の違いがわからないんだろ。


まぁ俺の事なんだが。

よう俺

動きのあるアニメ動画(2000フレーム)でテスト
--b-pyramidを使用した方が良い結果になる

x264 core:80 r1373 4322f63
x264 --tune ssim --ssim --bitrate 1000 --b-pyramid none|strict|normal
x264 [info]: SSIM Mean Y:0.9846375 [none]
x264 [info]: SSIM Mean Y:0.9846779 [strict]
x264 [info]: SSIM Mean Y:0.9847130 [normal]

x264 --tune psnr --psnr --bitrate 1000 --b-pyramid none|strict|normal
x264 [info]: PSNR Mean Y:44.143 U:46.017 V:45.545 Avg:44.528 Global:43.684 kb/s:997.33 [none]
x264 [info]: PSNR Mean Y:44.164 U:46.026 V:45.537 Avg:44.544 Global:43.693 kb/s:997.73 [strict]
x264 [info]: PSNR Mean Y:44.180 U:46.006 V:45.535 Avg:44.555 Global:43.701 kb/s:997.63 [normal]

>>869
一概に良いとは言えない感じもする
Yだけは良い結果だけどUVは劣化しているから映像の傾向によりけりだな

ssimやpsnrの数値なんて見ても画質なんてわからんよ
画質って、要は「見た目」でしょ？
--tune psnrとか--tune ssimとかつけて数値上げて喜ぶのは
自分の目に自信がない人のやることだと俺は思ってる
まあ「画質」の定義にもよるだろうけどね

動きのある実写動画(2000フレーム)でテスト

x264 core:80 r1373 4322f63
x264 --tune ssim --ssim --bitrate 1000 --b-pyramid none|strict|normal
x264 [info]: SSIM Mean Y:0.9830621 [none]
x264 [info]: SSIM Mean Y:0.9834859 [strict]
x264 [info]: SSIM Mean Y:0.9837914 [normal]


x264 --tune psnr --psnr --bitrate 1000 --b-pyramid none|strict|normal
x264 [info]: PSNR Mean Y:43.648 U:48.863 V:48.772 Avg:44.596 Global:43.741 kb/s:1046.47 [none]
x264 [info]: PSNR Mean Y:43.629 U:48.882 V:48.800 Avg:44.704 Global:43.869 kb/s:1049.09 [strict]
x264 [info]: PSNR Mean Y:43.759 U:48.934 V:48.829 Avg:44.807 Global:43.955 kb/s:1050.34 [normal]

やはり全体的に見ると向上している
まあ気になるならエンコする前にサンプルを取って確認してから使う方がいいかもしれんね

>>871
目に見えない細かい積み重ねが大切
その指標であるssimやpsnrを計るのは目に自信があるないの問題ではない

その程度の差で不具合の出るBﾋﾟﾗﾐｯﾄﾞ使うなんて馬鹿じゃねーの
勝手に地雷作ってろ馬鹿

>>869　>>872
デフォルトだとb-adapt 1だよね。
b-adapt 2ならもっと差が出たりしないかな。

毎回SSIMやPSNRの数値が出ると意味ないとかいう馬鹿が沸くけど開発者をディスってんのか？

ID:/5GjgP32
↑
いまだにb-pyramidで不具合が出ると思ってる低脳がいるようだなｗｗ

見えないところを削って見えるところを綺麗にするのが動画圧縮だろう
なに言ってんだか…

>>876
むしろ数値にこだわる馬鹿にうんざりしてるのは開発者の方じゃないの？
ssimとpsnr表示しなくなったし

そもそもPSPみたいな低解像度で見る場合はそれ用にエンコするんだから互換性もへったくれもないしね

>>878
あることないこと妄想で書くのやめれ
ssimとpsnrを表示しなくなったのは処理速度が落ちるからであって
開発者がうんざりとか関係ないし馬鹿じゃねーの？

NG登録
ID:KVue0o5f
ID:/5GjgP32

互換性無視して後で泣くのはお前等
つか友達居ないだろ？

SSIMはPSNRはあんまり信用しないな、俺
Psy-RD使うと下がる時点で

>>883
SSIMやPSNRねｗ
誤字すまんｗ

Psy-RD使うと下がるのは当然でしょ
よりソースに近づけるためのオプションではなく人の知覚を考慮した調整を行うのがPsy-RDなのだから
B-pyramidはより高圧縮にするためのオプション
高圧縮とは画質の向上を意味するわけだけども高圧縮低画質という言い方はおかしいんだよ
その辺を混同して語る人がいるから話がややこしくなる

不可逆圧縮なんだから画質が向上する訳ないだろ

ソースに近づけるという意味ですが？

>>887
ソースに近づけるってのと人の知覚を考慮するってのが両立するのか？

それは両立するでしょ
普通に考えればソースにより近い状態から知覚最適化を行う場合と
劣化したものから知覚最適化を行う場合では違うでしょ？
両立しないというのならビットレート値をいくらに設定しても知覚最適化を行うと意味がないということになりますよ？

＞よ？
で。最後を疑問で閉じるの止めてもらえませんかネェ。

psnr、ssimの使い始めは妄信しちゃうんだよな
誰もが通る道
しかし、エンコやってけばのちのち自分の目で分かるだろう

うわぁ。どうせ規制中だと思って書いたら、書きこめてしまった。
これは、酷い　orz

今エンコ終わったんだがmbtree + b-pyramidだと劇的に小さくなった
で別に画質が劣化したわけじゃない

全部ソースはアニメだけど

ＢＰＩＲＡＭＩＤＥの時代キタな

PSNRとSSIMというものは、テストされた変化にはサイコビジュアルな結果がなければ
画質を比べるに相応しいと思ってもよろしい。

大体の場合この条件が通り、普通にフェアな比較になりますので、
こちら側では普段PSNRを使っています。

>>893
どれくらい？

b-pyramidってDivXとかVLCとかだとどうやったら利用できます？無理？

>>895
本人なのか偽者なのか判断に迷うな
エイプリルフールのときの悪ふざけのこともあったし、本当にトリップ解析やりかねないんだよなぁ

>>896
暇だからb-pyramidだけ抜いてもう一周させるわ
22時くらいまで待ってね

>>897
divx264(DivX 7 CLI)だったら、-pyramidとする。
http://developer.divx.com/docs/divx_plus_hd/DivX_AAC_Encoder_Beta

>>895は本物のDark_Shikariだったりするんだな、これが。
詳しくは、irc.freenode.netの#x264にくれば分かる。

別に日本語でもいいよ。utf8ならね。

その内JEEB氏が証明してくれるんじゃないかと思う。

　　　　　　　　 　 　 . ｨ
.._ .......､._　　　 _　／:/l!
　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　_
ﾞ､'､::::::ﾉ:::::::_,.-=.　 _〜:、 　 　 　 　 ／_.}'':,
　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._　／_ﾞ''iﾞﾉ､ﾉ　またまたご冗談を
　,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､　,:'　　ﾉﾞﾉﾌﾞ　　　　　　　You kidding?
"　　 .!-'",／　 `'-‐'') /＼　`/　てﾞノ-〈
　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.,'　　 ~　／　
　　 ／/:::::　　　　 　 ',　 　 /　　　 ,:'ﾞ

>>896
アニメじゃないけど、某CGのトレーラー
1280x720x23.976fps
--crf 21 --preset veryslow --tune film --vbv-maxrate 24000 --vbv-bufsize 31250 --level 4.1で5148kbps
これに--b-pyramid normalを追加すると5130kbpsになった
SSIMとかPSNRの変動は>>872と似たような感じ
見た目の違いは…わかるやついるのかなぁ？

>>901
へー、ちょっと覗いてみるかな…

>>904
同じcrfで容量が減った増えた、画質が変わったとかも全く意味がない
crfとはcrf以外のオプションを総合した上での品質をどうするかというものなので
同一crfで容量が変わるのは当たり前の話
最後に調整すべきオプションがcrf

だから見た目に劣化してなくてサイズが小さい方がいいって話でしょ。

>>900
ありがとう。
DivX Authorとかじゃ無理なんですね。

DivX AuthorみたいにGUIで簡単なオプション指定しただけでx264オプションを作ってくれるのがあれば使ってみたい。
と思ったらGUIスレあるんですね。
試してみます。

http://komisar.gin.by/のデザインが変わったｗ
前の方が見やすかったのにｗ

【Share】アニメ職人画質音質比較スレッド 12【PD】
http://hideyoshi.2ch.net/test/read.cgi/download/1256926852/

画質もそうだけど再生負荷も考えないとな
Bﾋﾟﾗﾐｯﾄﾞ使ってる奴は大抵Bﾌﾚ3以上使ってる馬鹿

ここ数日頭悪そうなのが居ついたようだな

再生負荷（笑）

この馬鹿はどこから沸いてきたの？

855 名前：名無しさん＠編集中[sage] 投稿日：2009/12/11(金) 13:00:05 ID:/5GjgP32
そもそもPSPでは使えないからな＞Bﾋﾟﾗﾐｯﾄﾞ
同ﾋﾞｯﾄﾚｰﾄでも画質は変わらない
同様にBﾌﾚｰﾑも3より2の方が画質がいい塩梅

874 名前：名無しさん＠編集中[age] 投稿日：2009/12/11(金) 15:38:39 ID:/5GjgP32
その程度の差で不具合の出るBﾋﾟﾗﾐｯﾄﾞ使うなんて馬鹿じゃねーの
勝手に地雷作ってろ馬鹿

910 名前：名無しさん＠編集中[sage] 投稿日：2009/12/12(土) 17:23:19 ID:U+ykUYI/
画質もそうだけど再生負荷も考えないとな
Bﾋﾟﾗﾐｯﾄﾞ使ってる奴は大抵Bﾌﾚ3以上使ってる馬鹿

Bフレで負荷とか3より2の方が画質がいいとかB-pyramidが互換性がどうとか
ご自分の環境が世の中の基準なんだろう

BフレームはともかくBピラミッドONってPSP再生がおかしくなるのですか？
それはちょっと問題だな・・・

ttp://www.204504byse.info/nico/index.html
>--bframesを1以上に設定した場合、映像が1フレーム分遅れます。また、--b-pyramidを使用した場合は映像が2フレーム分遅れます。
>mp4boxの仕様に起因する現象です。

これってほんと？
初めて知った・・・。

サイズを気にしないのなら、
いくらでも逆行すればいい。

>>915
PSPで見る動画とPCで見る動画を同じ設定でエンコしてんのか？
>>916
DtsEditを通して初期ディレイを付与して調整する

>>915
b-pyramidは以前とは違い基準通りの値になっているので再生できないPSP側に問題がある
現状PSP以外では全く問題ない
どうしてもPSPで見たい場合だけb-pyramidを外せばいいだろ

>>911-914
こいつらいつ見ても笑える
今日の晩飯の佃煮にするわww

ID:U+ykUYI/

誰かこの馬鹿なんとかしてくれ　→　ID:Vm6Pf5LD

>>918
PC用で作ったものをPSP用に再エンコとかじゃないかな
詳しくは知りません

ID:U+ykUYI/

>>923
再エンコ云々はおいといてそれ用にエンコする時にb-pyramid付けずにエンコすればいいだけ

人をバカバカ言うのは感心しない
b-pyramidを使うとデコード速度落ちるのは事実
気にするレベルではないけど

今の--b-pyramidは、DXVAでも問題なく再生できるから、負荷云々は気にならない。

PSPが悪い

まあ人に見せるわけではないしな
自分の環境でストレスなく再生できて画質が良ければいい
負荷とか言い出すと自分の環境が貧弱なんですと言ってるようでみっともない

PSPは専用オプションでエンコードするだろ

こいつら居付くととんでもないからここらでギャフンと言わせないとな
あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ

あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ
あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ
あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ
あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ
あと圧縮も1/5〜1/6ぐらいで妥協した方が後々効率の面から見ても都合がイイ

自分は省電力マシン使っていて、パワーが貧弱だから、
再生負荷は気にしているけどね。

再生環境とか大事だよ。
CoreAVCとかも金出して試してるし。

オプション一つでそんなに熱くなれるお前らって幸せそうだなｗ
b-pyramidによるデコード負荷なんて気にするレベルではないけどな
mbtreeの時もそうだったけど新しいものに拒否反応おこす人多いよな
そんなに嫌なら古いオプションのまま使い続ければいいしこのスレに来る意味もないだろｗ

大体圧縮厨は貧乏人の考えだよね
元ｿｰｽを置いておく事が出来ないから極端に圧縮したがるwww

>>933
そんな貧弱なマシンでエンコードするとか根本的な部分が間違ってるようなｗ

3000円そこらのビデオカードでブルーレイのフルHDも余裕で再生できるんだから
デコード負荷を気にするのもバカバカしいな

>>935
間違ってるぞ、「圧縮厨」は圧縮する事が目的だからソースは永遠に維持される。
容量と時間を無駄にして同じ事を何度でも繰り返す不毛な連中だ。

mpc-hc使ってるけど、DXVAでインタレ解除出来るなら、
それでもいいんだけどなー。

>>939
出来るけど
デコーダーなに使ってるの？

mpc-hc内蔵ので出来たっけ？

できるよ

ID:U+ykUYI/

本日の可哀相な人
ID:U+ykUYI/

昨日だけどな

また馬鹿な圧縮厨が自演してるのかwww

今日も熱くb-pyramidで語り合ってくれよ

>>941
それはデコーダーじゃなくてVGAの問題だろ

これの様にDXVAに合わせたビデオを作っておいたら、インターレースも正常に再生できる。
http://www.mediafire.com/?ooimmwjdjve

b-pyramid + mb-treeでエンコしてFlash player 10で再生したら木の枝がふよふよした。

warpsharp状態か

テンプレ変更は>>1のバイナリうｐスレをDoom10に変更、>>3のQuickTimeの記述削除でいいかな？

あと>>4に
X264 Settings - MeWiki
http://mewiki.project357.com/wiki/X264_Settings
を追加したらどうだろう？

MeGUI自体は放置されているが、MeWikiは未だに更新されているな。
ただ、Doom10でもオプションの解説はやってほしいと思うが。

誰かgcc version 4.4.2 (x86.Core2.Komisar)使ってる方いる？
msysGit、MSYS、msysDTKを入れたんだけど使えない・・・
エロイ人、助けて

>>952のページ
b-adapt
Recommendation: Default, use 2 if you have time to waste.

ひどい言われようだｗ

>>954
使ってるけど。
どう使えないのさ？

>>956
msysGit、MSYS、msysDTKをインストール。
C:\msys

gcc version 4.4.2 (x86.Core2.Komisar)を解凍。
解凍してできたcross-mingw.gcc442.core2.20091019の中身をC:\msys\mingwに入れた。
で、msysを起動しgpacやpthreadsやyasm-0.8.0をビルド・インストールしようとしたけどエラーに終わった。

ホルダ名やmingw32-gcc-4.4.2.exeの"i686-pc-"を消してもダメだった。

「x264.exeのビルド - GCC … from: VFR mania」を参考にGCC4.4.1の環境は成功してます。
できれば4.4.2がいいなと思いKomisar板にチャレンジした次第です。

エラーってどんなエラーなのよ

gccの自動ベクトル化ってどう？
あんまりこのオプション付けてる人いないけど
x264には最適化はあまり効果ないだろうけど気になる

>>958
エラーって言うか、gpac等のビルド・インストールができない状態。
そもそも「解凍してできたcross-mingw.gcc442.core2.20091019の中身をC:\msys\mingwに入れた。」
↑この手順で合ってるのかな？？

それがどんな状態なのか想像できんな。
binやらlibやらを/mingwに解凍すればいい。
gcc -vで何が出る？
fstabの記述は合ってる？

>>961
解凍してできたcross-mingw.gcc442.core2.20091019の中身をC:\msys\mingwに、そのまま入れてOK?

ホルダ名やmingw32-gcc-4.4.2.exeの"i686-pc-"を消さなくてOKなのかな？

fstabの記述は
#Win32_Path Mount_Point
c:/msys/mingw /mingw
c:/ActiveState/perl /perl
です。

>>962
どんなエラーが出るのか知らないけど

mingwフォルダをmingw_gcc42にコピー
cross-mingw.gcc442.core2.20091019の中身をそのまま全てmingw_gcc42にコピー
fstabのmingwを
c:/msys/mingw_gcc42 /mingw
に変更

gcc4.4.1を入れた後のアップデートだけどこれだけでいけたよ

$ gcc -v
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/mingw_new --build=i686-pc-mingw32 --
target=i686-pc-mingw32 --with-sysroot=/mingw_new --with-build-sysroot=/mingw_new
--with-mpfr=/mingw_new/i686-pc-mingw32 --with-gmp=/mingw_new/i686-pc-mingw32 --
with-ppl=/mingw_new/i686-pc-mingw32 --with-cloog=/mingw_new/i686-pc-mingw32 --wi
th-mpc=/mingw_new/i686-pc-mingw32 --with-host-libstdcxx='-lstdc++ -lsupc++' --di
sable-shared --enable-static --enable-threads=win32 --enable-languages=c,c++ --d
isable-rpath --disable-win32-registry --enable-version-specific-runtime-libs --w
ith-system-zlib --disable-werror --disable-nls --disable-bootstrap --disable-deb
ug
Thread model: win32
gcc version 4.4.2 (x86.core2.Komisar) (GCC)

>>963
できました。
fstabのpassが通ってなかったみたい。

ご親切に付き合っていただいて、有り難う御座いました。

weightp って特にオプション書かなくても自動で --weightp 2 を指定した
のと同じようになる？

なるというかなぜ--fullhelpを読もうとしないの？
デフォ値は2

--weightp　Weighted prediction for P-frames [2]
- 0: Disabled
- 1: Blind offset
- 2: Smart analysis

>>965
--fullhelp

--pass 1 --bitrate 1024 --level 3.0 --keyint 300 --min-keyint 25 --deadzone-inter 21
--deadzone-intra 11 --ref 1 --no-cabac --direct none --no-b-adapt --no-fast-pskip
--no-dct-decimate --analyse none --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3
--vbv-bufsize 10000 --vbv-maxrate 1500 --vbv-init 0.9 --ratetol 4.0 --qcomp 0.7
--subme 1 --cplxblur 20 --qblur 0.5 --scenecut 40 --me dia --merange 16 --threads auto
--thread-input --progress --no-psnr --no-ssim

--pass 2 --bitrate 1024 --level 3.0 --keyint 300 --min-keyint 25 --deadzone-inter 21
--deadzone-intra 11 --ref 3 --no-cabac --mixed-refs --direct none --no-b-adapt
--no-fast-pskip --no-dct-decimate --analyse p8x8,b8x8,i4x4 --qpmax 51 --qpstep 4
--ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --vbv-bufsize 10000 --vbv-maxrate 1500
--vbv-init 0.9 --ratetol 4.0 --qcomp 0.7 --subme 6 --cplxblur 20 --qblur 0.5 --scenecut 40
--me umh --merange 16 --threads auto --thread-input --progress --no-psnr --no-ssim

すんません・・・昔iPhone用で用意したやつなんですが、どこを弄ればいいのかすっかり忘れてしまいましたorz
元ファイルの解像度のまま（リサイズ無し）でエンコしたいんですが、どこを弄るんでしたでしょうか。
先輩方、どうぞ宜しく御願いします。

リサイズはフィルタじゃ

たしかBasiline 480x240は再生できたので、うろ覚えで回答。
--profileや--preset、--tuneを使えば考えずにOK。
たとえば： --profile "baseline" --preset "veryslow" --tune "film" --ref 2
解像度やプロファイル、レベルはiPhoneの仕様に従うしかないので調べてください。

iPhoneはたしか[email protected]だったような

最近のバイナリを使っているなら>>970の言うとおり＆--progress --no-psnr --no-ssim は通らないので削除かな

うお、皆さんレスありがとうございます！

ダメだ・・・完全に置いてかれてます。orz

iPhoneは640x480までいけるんで、704x396あたりでも全然OKです。
なので、元ファイルが704x396ならそのまま704x396、640x480なら
同じくそのままで、リサイズはしないほうがエンコ速度も画質面でも
いいのかなあと思った次第です。リサイズはフィルタでしたっけ？
むか〜しの記憶で、オプションの何かを書けば元の解像度のままだった
ような気がしたので質問してみました。

おいてかれるっていうか、そもそも…

【H.264】iPod videoの動画スレッド★8【MP4】
http://pc11.2ch.net/test/read.cgi/avi/1235567895/

専用スレでどうぞ

面倒だから>>980立ててね

＞元ファイルが704x396

ダウン厨乙としか言いようがない

704x396ｗｗｗ

704x396

704x396

x264でエンコードするとソースが何であれ彩度がかなり落ちるんだけど、こればっかりはエンコの宿命ですかね？

別に落ちないけど。
色空間の扱いを間違ってるだけじゃないの？

>>982
HandBrake使ってるんですが、ｘ.264エンコしても赤系は特に顕著に色褪せちゃいます。
プリセット設定なんで色空間の扱いってよくわかりませんが、コマンドラインで指定するんですか。

自炊を始めた乞食が
ロクに調べもせず糞な質問投げ始めたか。

>>984
オマエ何様だよ？
知ったかぶりするまえに教えてやれ

自炊ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

にわか埋め
さっさとこの流れ切りたい

Adaptive QuantizationとPsy-RDについて助言を頼みます
AQはVAQで0.3〜0.7程度で試して値を上げる程サイズが縮む
Psy-RDは値を上げる程サイズが大きくなる（0.0:0.0・0.3:0.0・0.5:0.0で比較）

比較したのですが画質の違いは分からず、サイズの変動のみ分かりました
両者とも画質UP系の設定なので使った方が良いと考えているのですが、どうなんでしょうか？

今の所mb-treeを使っているので、VAQは少しでも使った方が良いのかなと思っているのですが、
画質の違いが分からないので使うべきか数値をどうするか迷っています

違いが分からないので小さめにアニメでAQ0.3・実写で0.7、Psy-RDも0.3:0.0で隠し味的な値にしておこうと考えているのですが、
他の人の意見も参考に教えて頂けないでしょうか？
よろしくお願いします

704x396を笑うなよ当時はSAR指定が出来なかったからワイド画面ではこれがベストだった
今でも昔の4:3放送などは528x470という変則サイズ使うときがあるぞ

自己解決しました。

>>977
ダウン厨だけど何か？
ここらをウロウロしてる時点でオレと大して変わらんだろ。
ここ2ちゃんだけどｗｗ

しかしなんだな。しっかり返答してくれてる先輩方が有難いです。
答えに窮すると叩きだすバカは死んでくれ。

UME

大きな声では言えないが他人のエンコは参考になるとは思う。

おまえが一番きれいだよ梅

>>988
--tune filmやanimationを参考にして、自分の好みで調節すればいい。
私はバンディング対策にGradFun2DBmodで足したディザやグレインが残せる様にしている。

>>989
以前Xvidを使っていた時は、xvid_encrawで-par 5として、DAR 16:9になる様にしていた。

次スレ立てた
x264 rev26
http://pc11.2ch.net/test/read.cgi/avi/1260857362/

乙うめ

FAQはもうなしでいいと思う
初心者スレもあるし、avsのこともあるし

>>990
マジで通報しました。

通報先・便利なリンク一覧

警察庁
http://www.npa.go.jp/
都道府県警察本部ハイテク犯罪相談窓口等一覧
http://www.npa.go.jp/cyber/soudan.htm
警察総合相談電話番号
http://www.npa.go.jp/safetylife/soudan/madoguchi.htm
　※携帯電話・ＰＨＳからは全国共通 ＃９１１０
　※緊急性を要するものは １１０
警視庁匿名通報フォーム
http://www.keishicho.metro.tokyo.jp/anket/other.htm
警視庁
http://www.keishicho.metro.tokyo.jp/
@police
http://www.cyberpolice.go.jp/

無意味な通報乙

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