x264 rev26

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

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

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://pc11.2ch.net/test/read.cgi/avi/1247319611/


[本家]
http://www.videolan.org/x264.html
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)
http://doom10.org/index.php (公式フォーラム)

[バイナリ]
Getting the latest x264
http://doom10.org/index.php?topic=3.0

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

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

AviSynthの使い方等は
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/

通報先・便利なリンク一覧

警察庁
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/

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

[バイナリ]
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)

r1376

Open GOPﾏﾀﾞ-

x264_ts_ctrlのパッチについて質問
今までVFRでVBVを設定しても正常に動作していなかったということ？
b-delay/timescale/tcfileはraw出力時でも指定する必要がある？

620低電圧化うま〜！ゆるゆる静音でファン回してもエンコ中最高40℃
だわ。速度は上を見ればきりがないんだろうけど安いし冷えるしうま〜。

>>8
VFRmaniac　Vのまにまに　x264gui
http://pc11.2ch.net/test/read.cgi/avi/1252765934/

ついでに言うとちゃんと説明読めばわかることを聞いてくるな

MainConcept Referenceってどうよ？

>>10
なんでそんなにカリカリしてんの？
答えられないなら余計なレスすんなよ

>>12
なんで説明書読めないの？
読めないなら使うなよ

説明書が付いてないから質問しているのですが？

配布サイト行けよこっちくんな

このスレは昔からID:RPF19UC+みたいな排他的な輩が住みついているよな
質問レスよりお前の糞みたいな無意味なレスの方が鬱陶しいっての

x264_ts_ctrlが何するためのパッチかわからないのに使いたいとか・・・・
VBVは与えられたレートでコントロールするためVFRを考慮していない
29.970で読み込んで実際24fpsならスカスカになるし60fpsなら詰まって与えた数値より高くなってしまうのを調整するパッチ
rawがどうとか聞いてる時点でおかしいことに気づけ

rawがどうのはそのパッチに初期ディレイカットの機能が付いているから聞いているんじゃね？
まあそれでもおかしいが

>>16
同意
スルーすればすむ事にいちいち突っかかってくるな

心・・・狭し
動物よりヒドス

自分はｽﾙｰできてないのに他人にｽﾙｰを要求するなんて（笑）

んで、こういう揚げ足取りのおばかチャンも登場するわけだ

まあ俺が最初に答えてやりゃこんな事には・・・・
個別パッチの話題ってとかく煙たがられるから隔離スレに誘導しただけなんだがまさかそれでこんな展開は予想外だぜ

別に求めているわけじゃないが答えたところで礼の一つもないとかになりゃそういう風潮になるのも仕方がないなと実感

ここは礼とか要求するスレなのか？
それ厚かましくはないか？

厚かましいのは質問者
恩着せがましいのは回答者

そして最後に自己正当化ですね、わかります

MainConcept Referenceってどうよ？
ttp://www.mainconcept.com/site/prosumer-products-4/mainconcept-reference-20373/information-20393.html

最後の書き込み直後にアクセス規制で書き込みできなくなりました
携帯からです
>17
わかりやすい解説有り難うございます
今回このパッチが気になったのはv氏が正式に開発に携わるようなので
そのうち取り込まれるのだろうと思いまして

>>27
x264と比べたら、エンコードは遅いし、品質も劣る。

MainConceptのエンコーダなら、まだこっちの方が使いやすい。
http://developer.divx.com/docs/DivX_Plus_HD/DivX_H264_Encoder/

>>28
libav*/ffms2を使用してる動画入力部分がgitに入ると、その中にKierank氏が
現在頑張ってるVFR対応も入る（VFR氏のアルゴリズムも含めて）

QTの優位性がまた一つ無くなるのか

>>31
クールなストーリーだ、兄貴。

狐耳巫女とキャッキャウフフしたい

誤爆orz

CoreAVC H.264 Video Codec - Version 2.0.0.0 (20091218)
ttp://corecodec.com/products/coreavc/changelog

>ADD: Multi-dupe weightp (+Future x264 changes)

x264を極めしこのスレの住民は480p（baseline）なAVCを作るとしたらcrfは何にしていますか？
自分はAVCをトコトン生かすために20、21、22、です。

うちは480pについては全てダウコンだから26

＞x264を極めし
なにこれ。こういうのいらないから。

＞作るとしたら
個人的には、2pass.
プロファイルに制限付けてるので特定機器向けな気するから、ソレにあった容量で作る。
どうしてもcrf使うなら適当。ソース映像と出来上がりの程度を想像し、決める。
そもそも。トコトン生かす云々なら、個人的にはbaseline使わない。

どうせ釣りだろ
他のオプションでcrfの品質なんて大きく変わってくるのに20〜22が良いとか馬鹿としか言いようが無い

>>36
何その糞みたいな設定
自分ならAVCをトコトン生かすために20、21、22、にするね。

Baselineとか一切使わない
HighProfileでqp12〜24(crf20〜22 qcomp0.8以上)に限る

以下イチャモン合戦開始

携帯機器ならBaselineはあり得るだろ
俺ならcrf30だけどな。画面ちっさいしどうでも良い

一応ドラマやバラエティは23でアニメは20にしてる
ベースラインは使わないなメインプロファイルだ

紙芝居みたいなのは23、動きの多いのは17,18かな
中には14くらい欲しい物もあるけど

>>45
こんなに変えるの？
こんなに変えなければいけないとしたらcrfの意味なくない？qpが自動的にqpmin
からqpmaxの範囲まで変化してくれるのがcrfのメリットだから動きが速かろうが
遅かろうがcrfで指定したqualityになってくれないと意味ないと思うんだが。

その代わり、動きが早いものを食わせたら巨大化して少ないものを食わせたら小さ
く仕上がると。

なんか勘違いしてる？＞オレ

baseline480pなのは某モバイル端末でも運用するため
自分も>>46と同じで動きが激しい激しくないとかでcrfの値をカエルのは意味が分かりません。
激しかろうが激しくなかろうが実写であろうがアニメーションであろうが自動的に同じ画質にしてくれるじゃん

残念ながらcrfはそんな賢くありません。

他のオプションがあってこそのcrfだろ

おまえらなんでそんな知識持ってるの？
ハイパーメディアクリエーターさんですか？
メディア製作会社勤務なんですか？
ただの趣味ですか？

そんな過多書き、ありえません

>>46,>>47
crf変えてエンコード後のログ見てみ、平均qp変わってくるから

crfの挙動は、動きが早く視覚的にごまかせるシーンはqpを上げて容量を節約して、
大して動かず少し汚いだけで気になるシーンはqpを下げて画質を向上させるものだから、
同じcrfで動きの激しいソースとそうでないソースをエンコードすると
動きの激しい方は平均qpが上がってそうでない方に比べて汚くなる

お前らが期待してる挙動はqp(固定量子化量)の方
こっちはその名の通り量子化量が一定だから画質も一定
ちなみにqpmax,qpminが絶対でcrfがその範囲のqpを動くってのは間違ってない

>>50
ただの趣味
出来るだけ綺麗で容量の小さい動画を作ろうとしてたらいつの間にかこうなってた

>>52
Σ( ﾟДﾟ) ｽｯ､ｽｹﾞｰ!!

どうやら知識不足みたいなんで勉強してみるわ

>>52
別に>>46,47はqpが一定とは言ってないと思うけど。視覚上の品質が一定に保たれてるって言いたいんだろっていうか
qpmin,maxがどうこうって言ってるんだからそうだろう。まあ--crfで--qcomp 1.00にして--ipratioや--pbratioも1にして
aqもOFFにすれば--qpとほぼ同じ挙動するけど

　　　　　　　　　　　／／／）
　　　　　　　　　 ／,.=ﾞ''"／
　　　／　　　　 i f　,.r='"-‐'つ＿＿＿_　　　preset使おうぜ！
　　/　　　　　 /　　　_,.-‐'~／⌒　　⌒＼
　　　　／　 　,i　　　,二ﾆ⊃（ ●）.　（●）＼
　　　/　 　　ﾉ　　　 ilﾞフ ::::::⌒（__人__）⌒::::: ＼
　　　　　　,ｲ｢ﾄ､　　,!,!|　　　　　|r┬-|　　　　　|
　　　　　/　iﾄヾヽ_/ｨ"＼ 　　 　 `ー'´ 　 　 ／

>>52
同じソースでcrf変えてエンコードしたら平均qp変わるのは当然ですよね。
同じじゃcrf変えてもquality変わらないし。

＞crfの挙動は、動きが早く視覚的にごまかせるシーンはqpを上げて容量を節約して、
＞大して動かず少し汚いだけで気になるシーンはqpを下げて画質を向上させるものだから、
これ、ホントなら動きが速い動画のほうが容量小さくなるだろ。実際そんな事
はない。

動きが激しく節約した分はより静止している部分に割り振ってるから
結果同じくらいになるんじゃないの？

>>57
それもない。それならcrf指定したら出来上がる動画の平均レートが
だいたい同じぐらいってことになる。そりゃcrfじゃないでしょう。

確かに動きの激しい動画の方が同じ設定でも容量食うんだった
今回のレールガンとかがいい例だな、あと粒子とかが多いと容量食うみたいだ

qpとビットレートをごちゃごちゃにしてないか？

俺も激しい動きの時に多く割り振ってると思ってたんだが、違うのかね。

--crfは--vbv-bufsizeを超えないようにqを割り振ってるんじゃ？
だから--qcomp 0.9とかは意味がない？
--vbv-bufsizeを気にしないなら--qpでaqでも使って画質を調整すれば良いんじゃない

>>54
書き込んでから思った、突っ込まれなければ放置でいいかと思っていたんだがorz

俺は動きが激しいソースで汚くなるのが嫌で>>45みたいにcrfを変えるかqpを設定したがる性質だから、
どんなソースでもcrf一定、ってそりゃねえだろみたいな先入観を持って書いたのがいけなかったっぽい
>>52はエンコード後の動画の品質(視覚的な)よりも「保存」の観点から見た意見なので
別にそんなの気にしないって人は無視して下さい

ただやっぱりcrf一定じゃソースによって見た目の画質も変わる気がするんだけどなぁ
確かに--qcomp 1.0とかにすればcrfでもqp的な挙動するだろうしオプション次第ではあるのだが

>>56-59
経験上crfでも動きが激しい方が容量は大きくなるので間違いは無い
俺は基本アニメのエンコードが主なのだが、qpを一定(18〜20くらい)にしてフレーム1枚1枚の画質を一定にすると
OPなんかはPSP解像度でも1200-2000kbps食うのに対し動かないシーンは20-50kbps程度で十分
つまり動きが激しいシーンのqpを上げてビットレートを抑えたところで動かないシーンとは比べ物にならない

>>62
vbv-bufsizeを指定しなくちゃいけないのは何らかの理由でレベル制限をかけたいときだと思うんだが、
レベル自体が解像度とかの条件を満たさないといけないから(最大)ビットレートがレベル上限に迫ったことはないので何とも
vbv-bufsizeを超えそうならqp上げるだろうけどこのケースは無視していいんじゃないかなぁ

画質を調整するのであれば空間的なaqだけでなく
crfや特にmbtreeも使いたいとか思うのは欲張りなのだろうか……

あと>>63のPSP解像度ってのは480x272です、DVDソースだとPSPでしか見ない関係で
キャプチャしたHDだとqpは使わないが一般的なOPでだいたい10Mbps程度か

読解力がないのか、すげー読み難い

1文1文が長いんですね……
申し訳ないです、何か自分でも読み返して嫌になってきた
あなたの読解力というよりは俺の文章力に問題がありそうorz

>>64
一般的なOPで10Mbpsって、お前どんだけ目がいいんだよ

>>67
OPだけqpでエンコードでもしたんじゃないの？
画質でビットレートがわかったら神だろ

俺はPSPのときも720x480にしてるけどな
そりゃドットバイドットの480x272の方が綺麗だけど縮小補正もノイズ感が無くていい感じ
PCとの共用も出来るしな
mbtreeは使ってるけどPSPでは特に破綻は無いようだ

なんかよく判らんけど要するに、
ファイルサイズ無視して画質追求の場合だと、固定量子化。

画質はそれなりでファイルサイズを縮めたい場合はcrf。
という認識で良いの ?

どっちもcrf。
それをqpminやqpmaxで調整。

>>70
良くない
--qpは特殊な実験目的以外では無価値であると開発者自身が言っている
まあ、それこそファイルサイズを無視してもいいんだったら、--qp 0(lossless)が最強だがね
固定量子化なんてのは糞画質エンコーダー使ってるTMPGEncユーザーの間だけでの話だろ
ファイルサイズ無視して画質追求なんて、そもそも成立しない

画質を追求したいなら2passでビットレートを盛る（SDで2.5Mbpsとか）。
んで、crfはビットレートではなくて内容を基準に
ビットレートを決めるから、ヘタに2passするより綺麗。
それにアニメなんかだと効率的。

固定量子化ってキワモノみたいな気がする

>71 >72 >73
ありがとございます。

私の勝手な思い込みで、h264は固定量子化が万能
みたいに思い込んでたので、助かりました。

なんか>>56はqpとビットレートは比例関係にあるような書き方なんだけど勘違いしてない？
フレーム間予測するんだから前後との差分が大きいほど同一qpでもビットレート上がるだろ。

人間の視覚上速い動きのものに対する認識能力は低下するからそういうシーンの多少の画質劣化を
ある程度許容することでビットレートを節約するってのがcrfの目的だろ。

ずっと1181ばっかり使ってたが最新にして新しいオプション足したら
エンコ時の温度が2〜5℃上がった。新しいバージョンのほうがより
CPU使い切ってるんだね。

Threaded lookaheadか？

ここって基本的に実写エンコは度外視なん？(´･ω･`)

実写なら--nal-hrdでインタレ保持一択だろ

別にそんなことはない
なにをもって度外視と判断してるのかはわからんが

使う言葉を間違えたんだろうぜ

>>77
--rc-lookahead
mbtree
--weightp
とかかな。1181だとプライム95掛けて温度が低めで安定してるくらいと
ほぼ同じだったんだけど最新でプライム95で1番負荷が掛かって温度
高くなってる時と同じくらいになった。

PSPだと最近のFWはインタレ保持は再生出来ない

俺も最新版自ビルドしたい！！

すればいいじゃん

>>75
qp変わらない≒見た目の画質が変わらない
と理解しています。なので「crf変えてqp変わらないなら画質変わらない」という
表現になってます。
見た目の画質が変わらないと言う事は当然動きが速い所がビットレートが高いと。
そう書いているつもりなのですが、そう読めない内容を書いていたとしたらゴメン
なさい。

>>52 でも言われているんだけど動きの速い部分の画質劣化を許容しているのが
crfであるという記述を発見出来なくて困ってます。どこかにその手のドキュメン
トがあれば教えてください。

私は
ttp://htffmpegx.seesaa.net/article/12618757.html
の実験結果等から、crfは（ビットレート指定をしなければ、今は指定しないのが
主流ですよね）平均qpを指定して、qpminからqpmaxの範囲でqpが変化する仕様
だと理解しているんだけど違うの？

>>86
MeWikiの記述じゃ信用できないって言われちゃうのかなぁ

http://mewiki.project357.com/wiki/X264_Settings#crf

CRF achieves this by reducing the quality of 'less important' frames.
In this context, 'less important' means frames in complex or high-motion scenes,
where quality is either more expensive (in terms of bits) or less visible,
will have their quantizer increased.
The bits saved in frames like these are redistributed to frames where they will be more effective.

>>79
60fpsでなく、インタレ保持にする理由は？

1. 再生時にインタレ解除方法を変えられる

2. 今時のVGAのHWデインタレースは中途半端に時間かけて60p化するよりよっぽど綺麗

>>88
60fpsにする理由は?
1280x720にしてBD等規格に合わすならまだいいが、
1080/60pじゃサイズ膨らむわ規格外れるわでいいことないと思う

1280x720@60000/1001fpsはL4.0に収まり、DXVAでも再生できるので結構良い。

まあ、1280x720に縮小するならBobもYadifmodあたりで済むからいいけどね
MCBobやらは使いたくない

基本的に1280x720にリサイズしているので、60pにするのがよさそうですね。
保持リサイズだと処理がややこしそうだし。

2009-12-17 - Version 1.5.1.0

- neroAacEnc:
- Improved encoding of sample rates higher than 48kHz
- Solved compatibility issues with some hardware devices
- Write iTunes compatible gapless data
- Enabled preserving of very quiet high frequencies at high bitrates
- Write the encoder settings to metadata
- Executable size reduction

- neroAacDec:
- Improved error handling
- Speed up

- neroAacTag:
- Support 3GPP tags
- Support Sony Memory Stick tags
- Improved cover art support
- Improved support for files with multiple tags in different formats (ND,iTunes,3GPP,Sony Memory Stick)
- Writes iTunes tags by default, added switch to enable ND tags

おおっ
凄い久しぶりの更新だな

人柱のレポ待ち

短いファイルしか検証してないけど、
取り合えず今迄と同じ使い方は問題無いみたい。

最近更新がないのはx264もクリスマス休暇なのか？

>>99
そういや8日間も更新無いのか
……むしろクリスマスプレゼント的な大きな更新でも来るんじゃないかと思うことにしておく

昔、クリスマスエディションってなかったっけ？

>>95 の最新版にあげて3本ほどエンコしたけど、特に問題なさそうだね

>>87
ありがとう。確かにそう書いてありますね。
そうなると不思議なのはcrf 2passが無いこと。平均qpが概ねCRFで設定した値
になるので、どこでqpを節約するかなどを予め決定しておくために１度passして
おくほうが良い結果が期待出来そうな気がするんだけど、、、

もう少し研究してみます。お騒がせしました。

>>103
crfの場合、本番の前に一度簡易なエンコード処理を回してて、そのデータサイズとcrf値をもとにqpを決める。
つまりそのフレームがどれだけビットを食うかでqpが決まり、動画全体で云々ということはしない。
1passの場合指定ビットレートとそれまでの出力結果を比べて内部的なcrfを変化させるだけで、基本はcrfと同じ。
2passならログをもとに指定ビットレートを（内部）crf値に変換する。

けど2passにするとDirectMBとか細かいところで最適化が入るので、
同じビットレートだと2passのほうが若干品質が高いかもしれない。
crfとpass 1を同時に指定するとログを吐くので、こいつを使って2passすると何か起きるかも。

crfなら前後のフレームとの差異を調べてqcompを元にqpを適用するんじゃないの？

>>104
やってみた
1pass目をcrf（＆ログ出力）して、その時のビットレートを元に2passにしたら

・2pass目の方がビットレートが膨らんだ
・ssimが下がった（psnrは知らん）
・瞬間最大ビットレートが下がった（振れ幅が縮小）

という感じで個人的に利点が全くなかった・・・

>>104
やってみた

１：--pass 1でログ出力
２：１で出たビットレート・ログで --pass 2実行。　結果Ａ
３：１と同じcrfで1pass実行　結果Ｂ
４：１で出たビットレートで2pass実行　結果Ｃ
５：３で出たビットレートで2pass 結果Ｄ

全体の平均値での数値は
B>A>C>D
ちなみに見た目じゃまったくわかんない。
数値的にもほとんど差が出てないけど。
A,C,DはIPBの数が同じだけどBだけ違う。
A,C,DはQPが変動するけどBはIPB各スライスでは同一値。
たぶん微妙な見た目では2passで向上する気もするけど
コストパフォーマンス的には意味がない気がする。

P,Bの使い方が変わるからもっと長い(実験は3998フレーム)と差が出る？

ここ初心者スレか？と目を疑うような低レベルなやり取りだな…。
町のゴミ拾いでも手伝ってこいよ。
暇なんだろ？

NGID:h8B66/wg

NGID:E6yhuXcR

NGID:ID:8qHGUs5J

NGID:ID:bySfH5Cz

いい加減にせい

おあとがよろしくないようで

それにしてもx264の更新来ないな

だね
メンバーがインフル休暇とか？

http://article.gmane.org/gmane.comp.video.ffmpeg.devel/101146
>x264 will soon be committing Periodic Intra Refresh, an extremely
>powerful feature for low-latency, high-resilience streaming.

>>117
よく意味がわからんが、ただ動画を小さい容量で綺麗にエンコード出来ればいい人には
関係なさそうな機能っぽい感じがするな
……英語出来る人教えてorz

俺もよく分からんが、要するにイントラスライスみたいなのを使って、低遅延でエンコード出来、
シーク時なんかもすぐにイントラMBが1画面分溜まって表示されるって事じゃね？

サンプルmkv置いてあるじゃん。

試してみたら、シーク時にいきなり画面が更新されず、
ずずずーって感じで上からしたにゆっくり書き直されていく感じ。

I Frameを置かずに、I Sliceを上からしたにぐるぐるまわしていく
ように見えた。

英文読む限り、Encode/Decodeの遅延を０にするリアルタイム
処理用っていうことらしいよ。基本VideoCam系の技術だけど、
普通の動画にもメリット多い。VBRのレート変動を抑えることが
出来る。

質問

ようつべから落とした7Mbpsぐらいの実写フルHDMP4動画をcrf20で480272に円弧してもこの動画だけ3Mbpsぐらいにしかなりません
他は1.5Mbpsぐらいで収まります
異常だと思うのでアドバイスください

NGID:FD01px9S

また釣りか

更新開始は年明けのようだね

x264 LAVF/FFMS input beta test thread
ttp://doom10.org/index.php?topic=133.0

aq-mode 4
ttp://forum.doom9.org/showthread.php?t=147067&page=6

何が変わるんです？

そういや今もmode 3 があるんだけどどっかに説明ないかな…
mode 2 までは把握してるんだが…

久しぶりにx264更新しようと思ったらSeraphy氏のMixAQx264が更新されてなくて
VFR_Maniac氏のはPentium4じゃ使えないと知り絶望した
……いい加減買い換えろってことか……

自ビルドすればいいじゃない

自ビルドなんて知識ゼロから調べて出来るかなあ
とか思ってたらVFR_Maniac氏が書いてるのね。頑張ってみるわ

俺も知識ゼロからスタートしてできるようになった。頑張れ。

./configure
make
の繰り返しだったな

gcc version 4.4.2 (x86/x64.Komisar)
*ttp://komisar.gin.by/mingw/index.html

Cross-Mingw.GCC 4.5.* - x86/x64
*ttp://www.xvidvideo.ru/2009-10-22-10-49-14/cat_view/28-cross-mingwgcc-x86x64/160-cross-mingwgcc-45-x86x64.html

VFR_Maniac氏説明のGCC4.4.1より↑の方がいいぞ

Komisarはpthreadやgpacも用意してくれているので、非常に楽だな。

Pentium4に突っ込まないお前らの優しさに感動

俺もKomisar氏かTDMから導入する方が楽で事故が少ないからおすすめ
ゼロからスタートするなら尚更

Komisar氏のはクロスコンパイルもできるしね。

ところでmake fprofiledに使うテスト動画って、どのくらいの解像度とフレーム数が必要なんだろ
いっぺん1920x1080x500フレームでやったら、えらく時間食ったんで、1280x720x600に変更したんだ
ひょっとして、SDサイズで300くらいでも問題ないのかな？

fprofiledには何を使っても良いという話だけど、とりあえず私は704x576(100フレーム)のこれを使っている。
http://www.mediafire.com/?03tzjnnwiwo

よくない頭を回してる間に暖かいレスをありがとう
x264.exeの作成まではこぎつけました。
guiとかパッチあてとかが理解できずに今日のところはギブアップしましたが、明日もう少し頑張ってみる。
……よく考えたらコンパイル年越しか……

>>134
違いがわからない大馬鹿者だが使ってみる
ありがとう

>>136
突っ込まれたら泣いてた

最後にVFR_Maniac氏に最大の感謝を。

ロシアの姉さんもMingw.GCC配布してたのか知らなかった

ロシア峰不二子

初心者の俺はMinGW猫科研究所パックを使ってる

大晦日まで変わらずこのスレに書き込んでるなんて皆さん変態ですね
俺はうれしいぞｗ

>>143
むしろバラライカ

VFR maniac氏のとこ読んで進めていったが
x264.gui.auoの4. gpacで躓いてしまった…。
gpac.slnをVC9で開きます。ってとこが開けないんだがわかる人いますか？

>>147
msvc8ディレクトリの "---読み取り専用を解除して--- ", gpac.slnをVC9で開きます。

>>148
もちろん解除しました

ちらっと調べたら、gpac.slnをコンバートして開いて云々というのを見かけた
知識無いから何のことかサッパリ分からないが

VC8用からVC9用にソリューションを変換します。
というのがちょっと気にかかるが…

VC9で変換ウィザードが一瞬出てすぐ消えるな

最悪MinGWでビルドしたライブラリををリンクでいけるよ。
ファイルサイズが多少大きくなるだけ。

複数のmpeg2をx264でエンコしてmp4にするのに一括でできるフロントエンドって何かない？
今はavs経由させてるんだけどフィルタかけるわけでもないから手間かかるだけなんだよね。

MeGUIでいいんじゃね

MeGUIだと結局synth使ってるじゃん

ありがとう、試してみた
スクリプトを自動で作ってくれるようなのだが前段のd2v作成がバッチ処理できないっぽ
bontsdemux並に設定選んでドロップして実行ってのを考えていたからちょと残念

結局最強はCLI＆バッチファイル

あそうか
d2v作成処理がおわらないとエンコ登録できないんだっけか

インタレ保持エンコする時の留意事項として以下があるらしいが、
この内、mustなもの、PS3等特定環境再生時のみ必要なもの、入れた方がよい物、
もう忘れていいものなど分けるとしたらどうなりますか?

(1) B-pyramid不可
(2) direct_pred=temporal必須
(3) 高さが mod32 (実際には height%32==0 || height%32>=18 )
(4) --nal-hrd 必要
(5) vbv-maxrate 10000 --vbv-bufsize 10000

他にもあるかしら。

>>160
--nal-hrdは必須
vbvは指定レベルによって数字が違うので注意。
PS３は4.2Xbox360は4.1のレベルにまで対応してるのでちゃんと調べよう。

あとちゃんとフィールドオーダーも指定してやるべし。tff,bffのどちらかも
それにB-frameは増やし過ぎないように。

フルHDのアニメでインタレ保持したときの設定
--level 4.1 --crf 23 --aq-mode 3 --aq-sensitivity 10 --aq-strength 0.1 --psy-rd 0.1:0.0 --scenecut 54
--cqm flat --colorprim bt709 --transfer bt709 --colormatrix bt709 --videoformat ntsc
--subme 9 --qpmin 22 --qpmax 51 --fullrange on --interlaced --nal-hrd --vbv-bufsize 62500 --vbv-maxrate 40000
--tff --mbtree --weightb --trellis 2 --b-adapt 2 --keyint 300 --ref 2 --mixed-refs --no-fast-pskip --bframes 2 --direct none --nf
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --thread-input --no-deblock --no-dct-decimate

XBOX360ではインタレ用のファイルはここまでCRF落とさなければ再生されなかった。
PS3ではCRF 20位でも再生されたけど

バイナリはVFR氏

まあ4.1のフルHDなので仕方ない気もする。

--level 4 --vbv-bufsize 25000 --vbv-maxrate 20000
VBVはこうしておけば、大抵のハードウェアで再生が可能だろうと思う。

http://developer.divx.com/docs/divx_plus_hd/Creation_with_x264/

うっそ B-pyramid不可？？？

俺が知ってる再生環境（DXVA、libavcodec系、coreavc、DivX、DiAVC、PS3、PSP、flashplayer）で
--b-pyramid normal不可はPSPだけだが

--directにはtemporalではなく、spatialを使うべきだろうな。--b-pyramid normalは問題なく使える。
--weightpは今のところ--interlacedとは併用できないので、それは残念。

http://www.mediafire.com/file/zzn3mwzjqnu/interlaced_pyramid.mkv

自分の記憶では

＞(1) B-pyramid不可
殆どの環境ではもう使用可能だがPSPと古いFWのPS3ではダメかも
安全志向で使わない人もいるがBが多いと効果が大きいので惜しい
でもmbtree+b-pyramidは最近サポートされたものなので潜在バグがないか不安

＞(2) direct_pred=temporal必須
direct_pred=temporal,autoは不可の間違い（spacialしか使えない）
これはx264側が未対応で勝手にdirect=spacialに直されるから気にしなくてもいい

(3) 高さが mod32 (実際には height%32==0 || height%32>=18 )
圧縮率や画質が少し悪くなるだけで気にしなくて良い

(4) --nal-hrd 必要
その通り、巷ではtff/bffを--interlacedと一緒に指定してるけど
tff/bffだけ指定すれば--interlacedがimpliedになったはず

(5) vbv-maxrate 10000 --vbv-bufsize 10000
レベルとプロファイルによる、HighProfileはそれ以外の場合の25%増しまでOKとかある

他にはme=esa不可（umhにされる）、weightp不可(noneにされる)、
slice-max-size/mbs不可（無視される）、他に何かあったかなぁ

誤植→s/spacial/spatial/

あと手元のメモによるとLevel2.1〜4.1は--interlacedにできるけど
Level1〜2と4.2〜5.1は不可（規格破りになる）って話があったはず
ソースがちょっとわからなくなっちゃってるけど
確かdoom9でakupenguin氏がそう言ってたと思う、不確定情報ですまんが…

neroAacEnc 1.5.3.0 (SSE bug fix)

Enc aacPlus (20091230)

>>154
AVIUTL+Seraphy氏のプラグインなら、MPEG2 PSを直接読み込んでmp4をバッチ処理で出力できる。

音声どうすんだよ

>>171
それだと音声が認識できず、無音のファイルが出来るぞ

>>172-173
音声認識できないのはMPEG2 TSでしょ。
PSの音声は認識出来てるよ。TSを事前にTMPGEnc MPEG　EditorなんかでPSに変換、ついでにCMカットしておけば、
AVIUTLに突っ込むだけで音声付きmp4に変換できる。

まるもがmp2以外でも読めるなんて初めて聞いた

いったいどこにまるもが

>>175
音声がAACなら、当然TME3でMP2に変換するんだよw
そりゃ多少劣化はするだろうけど、手軽にっていうんなら、十分成立するトレードオフだと思うけど。

FAWでいいじゃん。分離なんてほとんど手間かからないし。

FAWじゃAACのフレーム単位切り出しだからズレる

たしかにそうだけど、まずわからないじゃん。
音声２重圧縮の劣化よりは良いと思わないかい？

わかるて
わからないってどういう環境だ
アニメオンリーか？

aacedit2でTrimに合わせてカットをしているけど、認知できる様なずれは無い。

ズレても1フレーム以下の10ms程度だから気にしてない

>181
1フレーム以下のズレはわかりませんわ。
2フレームでちょっと違和感があるかな？ないかな？ってくらい。

たまたま最大限ズレれば20msだからなんとかわかるかもね。
まあアニメならほぼ確実に問題ないだろう。

M-ONのHDのtsファイルがBonTsDemuxを通らないんだが
何とかAviutlに渡す方法はないものか
なんとしてもエンコしたい

あきらめろ
違法うｐ反対

>>187

バカだよポップさんの
x264 Rev.1376_r1 core2[Yorkfieldコア以降]最適化ver.
Athlon II x4 620 で動かず orz

Pentium3以降は動いたけど。

そういやAMD用最適化ビルド配布してる人っていないよな
なんで？

エンコはインテルが強いからなぁ

インテルはキャッシュ多めでバスが貧弱(i7除く）だからキャッシュに収まる処理は速い

X5-452ビルド / i7専用 (x264.exe)
http://cid-614aa8f1c8307528.spaces.live.com/

Pen4も、エンコだけは早かったもんなぁ。

インテル入っテル人うらやま〜だわ〜
mixAQとかのビルドAMDだとことごとく落ちるわ〜

OreAQだがPhenomIIで何の問題も無い

最適化については仕方が無い
絶対数じゃIntelが圧倒的に多いし
ネハレムユーザが多いとは思わないが

oreAQは問題ないだろうけど

俺はPhenom使ってたけどIntelビルドが多いから
去年、i7（920）にした

OCしてるのもあるが、エンコ速度には満足している

MixAQでも落ちないぞ…

ただ反論したいだけの奴の相手するの疲れるから
これ以降passするで・・・
エンコだけに
-VAQ+HAQだと落ちないのは落ちないのだが、それは使わないし
自ビルドすりゃきっと落ちないだろうけどな、全然知識ないし
どっちにしてもやっぱインテルCPUにしたいわ・・・

文句言うなら自ビルドしろよｗ

解説してくれてるんだからな。
パッチ当ててconfigureしてmakeするだけだ。

H264エンコーダーのひとつであるJM重すぎｗ

--extra-cflags="-march=k8-sse3" 私が自分で使うパッチ(x264_hrd_pd_interlace)だけ当ててある。

http://www.mediafire.com/file/jmhn2uwmitz/x264-r1376M_Windows_32bit_64bit_k8-sse3.7z

まあ、自ビルドできるならそれに越したこともないわな
俺は今使ってるQ9450買い換えるとすれば、マザーから総とっかえになっちゃうから、
次はAMD選んでも大丈夫なように、最近ビルドの仕方覚えたよ

Phenomの人はこちら。
http://www.mediafire.com/file/5jzjyhyamn4/x264-r1376M_Windows_32bit_64bit_amdfam10.7z

ちょっとお聞きしたいのですがb-frame, b-pyramidありで、特にディレイフレームを
カットしたりせずにmp4boxで音声と結合すると音ズレしたりしますでしょうか？

>>207
スプリッタによって違う。 それぞれの挙動はseraphy氏作のDtsEditに付属のbatを使えば簡単にわかるんじゃないかな。
面倒だったらmp4boxで結合した後に、ディレイカット.batにでも放り込んでおけば安心？

初期ディレイを弄るのではなく、エンコード時に先頭フレームを削って合わせるのは、混乱の元だから止めた方がいい。

MP4はそのあたりがややこしいから、私はMatroskaを使っている。

MP4 Splitter（の初期ディレイ）が仕様通りに実装されてないのは何でなんだ

GPACの中の人が間違ってたのがそもそもの原因かな
そしてGabestもHaaliも基本的にmkvの人だから、mp4に関しては結構いい加減だった
海外の連中は特に事情がない限りみんなmkv使ってるから、誰も仕様違反に気づいてなかった
macユーザーでもないのにmp4を使いたがる珍しい連中（日本人）は、初期ディレイカットなる
奇妙なハックでお茶を濁していた

こんなところじゃないの

不人気な標準規格ほど寂しいものはない・・・

初期ディレイはFlashPlayerでは大丈夫なのかな？

>>213
初期ディレイは普通に反映される。
edtsは知らんが。

>>214
ありがと
MP4Boxでdelay指定してみたけど駄目だったわ
知識不足でこれ以上は手が出せん

アニメ大画面用での　--ipratio　のお勧めはどれくらい？

ソースとI、B、Pフレームの割合を見てお好きにどうぞ

動きの多いOPなんかは若干低めがいいんだろうけど
動きの少ない本編は若干高めの方が良さそうな感じがする
結局デフォルトのまま

>>218
逆じゃね…？

動きの少ないものを若干高めにすると同じ場面の中でも画質の差がはっきりしちゃって駄目

>216
アニメだとIは割合としてはかなり少ないので、
どちらかといえばpbratioの値に注意した方がいいと思う。

mbtree使ってればpbratioはそもそも意味ないけどな

>>222
実際そうみたいなんだけど、なんでそうなるか理論的に理解ができない…

理屈がどうかは知らんが、mbtree考えた本人がそう言ってるんだからそうなんだよ
http://doom10.org/index.php?topic=49.0

って、リンク貼ったあとにもう一度読み返してみたら、そもそもどちらもいじるべきじゃないって
書いてあるね
つまり最適はデフォルトってことだな

ip pb 両方とも 1.2 にしてる

俺は色々やって結局デフォルトに戻ったよ
違うのはqpminとmaxぐらい

ttp://intermezzo.cool.ne.jp/report/Lupin/R3_temp.swf?inputStr=x264+-open+source+MPEG-4+AVC+%2F+H.264+encoder-

もう最後の更新から一ヶ月近く経ってるのか

おぉ、マジだ

一気に来たなｗ

x264のlavf入力、ffmpegでの-sws_flags lanczos -s 512x384 -ss 37 -t 2のようなことは出来なさげ。

Haaliで正常に再生できないので注意

>>233
x264側のバグとも解釈できるような書き込みを修正してやる。

rev1379 lavf/ffms入力サポートに際し,MP4出力においてBフレーム使用時(正確には最初のCTSOffsetが正の時)に
edtsを書き込む仕様に変更しました。(私が)
HaaliMediaSplitterで正常に再生出来ないのはHaali氏がedtsの仕様を勘違いしていたからであり、
x264は規格通りにedtsを書き込んでいるはずです。
そうでなければffmpegを通したmp4も仕様違反を犯していることになってしまいます。
MP4Boxのimport側のdelayは負値に関して仕様違反を犯しており、一方 general側は規格通りの意味不明状態。

Haali氏に 修正したかー と聞いたら, もう修正した と答えた。
次のリリースはいつかー と聞いたら 出来れば来週 と答えた。
Kierank氏が Cassimir666氏にもMPC-HCにedtsをサポートするように働きかけている。
そしてつい最近, Bento4からコードをいくらかインポートした。

muken, the VFR maniac (本人規制中のため代筆）

>MP4Boxのimport側のdelayは負値に関して仕様違反を犯しており、一方 general側は規格通りの意味不明状態。
ってどういうこと？

>>235
ttp://zoome.jp/VFR_maniac/diary/94/

>236
親切な人よ、ありがとう。

今までのx264はmp4出力の時edts書き込んでなかったけど
r1391のlavf/ffms入力サポートにあたってr1391からedts書き込むようにしたよ！って解釈でいいの？

いいよ

edtsがどうしても必要かどうかは音声の有無に依存してる
（映像だけならどのタイミングで表示開始しても問題ない）から
これまでは純粋なH.264エンコーダとしてのx264には不要とみなされてたとも言える

生のYUVを受け取って生のH.264ストリームを吐くのが基本というスタンスから
入出力の利便性を考慮してくれるようになったという意味では大きな方針転換だね

まあ、y4mを入力して、264(raw)を出力する私の様な人間にはあまり関係のない変更だけれど、
今回の更新で、便利になったと思う人も確かにいるだろうと言うのは理解できる。

今までffmpegを改造してlibx264を使ってきたけど
これで音声側もlibavc使ってエンコードできたら
ffmpegはもういらないかも知れない

将来的にはx264.exeをリサイズ、IVTC等のフィルタとか音声エンコも一緒にした総合エンコーダーにするらしいから、
今回のもその布石なんだろう
ただ、D_S氏はどうも巷にあるVFRな動画とかが、どうやって作られてるのかよく知らないみたいなんだよなぁ

edtsやっと対応したのか。MP4boxとSeraphyさんのツールも対応してくれれば
完璧なんだが。VFR作るのにSeraphyさんのDtsEdit通すとedts消えちゃうんだよな。

そういえばlibavformatを使うのにmuxersは廃止しないんだな
まぁmp4, mkv, flv, 264の他に何が必要なんだって話ではあるが
ffmpegのmp4muxerが正しいなら改めてedts対応する必要もなかったような…

Haali Media SplitterとMPC-HCのスプリッタが仕様通りになったら
初期ディレイカットしたやつとかmp4boxのimportで負のdelay値を与えたmp4ファイルなんかは
映像と音がずれちゃうんじゃないの？その辺がよく分からん
delayオプション使わないでmuxしたedtsがないmp4ファイルはスプリッタ側はどう解釈するのかとか

負のdelay値を与えない限りは以前の動作だろ

>>245
ts

>>244
>>246
Vまに版mp4boxの最新はedts対応&初期ディレイカットの修正機能付き

x264: the best low-latency video streaming platform in the world
http://x264dev.multimedia.cx/?p=249

低レイテンシストリーミング用の設定コピペ。※は勝手に補足。
–slice-max-size A –vbv-maxrate B –vbv-bufsize C –crf D –intra-refresh –tune zerolatency

Where
A is your packet size (※TCPだとMSS(MTU - 40, 最大1460)に当たる? UDPやRTPだと比較的自由か?)
B is your connection speed (※プロトコルのヘッダ分を考慮した方が良い?)
C is (B / FPS)
D is a number from 18-30 or so (quality level, lower is better but higher bitrate).

Equally, you can do constant bitrate instead of capped constant quality, by replacing CRF with –bitrate B, where B is the maxrate above.

NAL HRD patch v1.0 beta test thread
http://doom10.org/index.php?topic=157.0

これが正式に採用されたら、コンパイルが少し楽になるな。

今後の開発の展望だって
http://x264dev.multimedia.cx/?p=270

現時点ですでに自ビルドにlavf/ffms2入れるのすら放り出してる俺には、もうわけわかんね
ところでffmpegのaacって使い物になりそうなの？

x64でFFMS2を使えるバイナリもあるけど、avs2yuv + --stdin y4m とした入力の方が楽だな。
http://forum.doom9.org/showpost.php?p=1363860&postcount=2882

GUIのフロントエンドなんてのも考えてるのか

aacはQuickTimeしか使わないから外部CLI使えないと意味ないわ。

r1273辺から3ヵ月間使ってなかったんだが、最新てB-Pyramidや
weightp加えても以前より早い(9fps→13fps)。
お陰で、PCが部屋の暖房に使えなくなったw

GUI化に力入れるのはやめてほしいなぁ。

b-pyramidは早くなるとどっかで見たような

>249
>Vまに版mp4boxの最新はedts対応&初期ディレイカットの修正機能付き

初期ディレイカットはついてなくてedtsの追加らしい。

VFR maniac氏のmp4boxがいろいろバグが直ってていいんだけど
Pentium4-Northwood と WinXP の環境だと使えない（何もせず終了する）
たぶんBuild時のCPUオプションかなんかでP4にない命令とかを使っているからだと
思うんだけど。Kurtnois氏のは普通に使えるし。

どなたかP4でも使えるようなオプションでBuildして頂けないでしょうか。

他人に配布するなら、-mtune=genericでやれば良いのにな。

そうか？
もともと自分用ビルドをついでに配布してるものなんだから、自分の環境に合わせるほうが普通だろ

>>258
POP氏のやつはP4でもいけるんじゃないの

例えばKomisarは、"-march=pentium3 -mtune=generic"と"-march=core2"の両方を配布しているな。
まあ、私も自分用のは-march=nativeでやるけど。

Vmaniはオタ特有の気持ち悪さ

別に自分でビルドすればいいんでないの？
ソースの差分が入ってた気がするけど

久々にオプション最新にしたくて来てみた
seraphyの掲示板荒れまくっててわろたｗ
なんか流れ見てるとseraphy氏の改造版は今はあんま使われてないんかな・・・

Aviutl使いだから重宝してる
デフォルト仕様なのでなくなると非常に困る

俺もAVIUTL使いだ。
自動フィールドシフトVFとの併用が楽ちんなので離れられない。
seraphyの中の人には今後も是非がんばって頂きたい。

ffdshowとseraphyビルドで今日も元気です
ffdshowのフィルタ優秀すぎ

AVIUTLって遅くない？

x264out使ってる俺は少数派なんだろうか

>>268
入力とフィルタを全部ffdshowにやらせると結構速い
でも一番の理由は楽だから^^;

某動画サイトのせいでAviutlでのエンコに厨臭いイメージがついてしまったんだよな
だから何？っていう話ではあるが

使い分ければいいのよ

VFRさんのrev1391M_release2使ってみたけど、x264_AQ_experiments_v4.diffがうまく当たってないのか機能してないね。
aq-mode 3か4にしても2になってしまう。

>>273
試してみたが、ちゃんと3や4になるぞ

>>264
Seraphy氏はパッチ版とOreAQ版の更新をしなくなったから
それらを使っていたのがVまになどに移行したので少しは減ったのかも。

掲示板荒れ杉は単に管理する時間があまりとれないだけだと思う。

>>274
自分とこじゃ駄目ですね。
もう少し試してみます。

違うとこに置いてる違うバイナリ使ってるとかじゃない？

すみません。問題なかったです・・・
単に同名のrarファイルがあって古いほうのを使っていただけでしたorz
申し訳ないです。

r1400

ffmpegについて質問です
１枚の画像(src.jpg)を音楽(src.m4a)の最後まで繰り返す動画を作りたくて
ffmpeg.exe -loop_input -shortest -i src.jpg -i src.m4a -s 320x240 -vcodec libx264 -acodec copy -r 1 get.mp4
とやって昔はできていたはずなんだが今は何故かできなくなった

エラー内容
Error while opening encoder for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height

お助けください

ffmpegとx264のりびじょんによるけど
-vpreを使えって話じゃね

>>280
Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://pc11.2ch.net/test/read.cgi/avi/1247319611/

>>281
回答ありがとう

質問は終了しました

やべえ数ヶ月離れたらもうわけわからん
何も知らんのと一緒だ一緒

>>284
そっか？ここ半年はオプション廃止になったり意味変わったり
してないんじゃ？
細かく詰める必要はあるけど、取り敢えず前のままのバッチ
使えて助かった。

6月頃からで考えてもエラーになりそうなのはb-pyramidくらいか
mbtreeとかweightpがデフォルトで有効だから出力はかなり違うだろな

いましがたrev1000からrev1400に変えた

もうわけわかめｗｗｗｗ最初から勉強しなおします

元ファイルが23.98と中途半端なフレームレートなんだけど、それをAVIでキャプチャした後に
h.264で出力しても、どうしても23.976になってしまうんだが
60fpsでキャプらなきゅ駄目なのか

24000/1001＝ 23.976023976023976023976023976024

うん、そうだよ。

23.976で正しいんですけど。23.98は単に表示が丸められてるか出力時に補正されただけ。
正確には24000/1001

なんかr1400だと、NAL-HRDパッチがまた駄目みたいな感じ
自ビルド、komisar氏のkgit、rack04氏のビルドすべてでインタレエンコが上手くいかん

>>288,289,291
そうなのか
なら24fpsでキャプっても結果はソースと同じなのかな

各ビルダーのr1400を試してたんだが、
techouse氏のpatch入りビルドでmp4出力すると、
エンコオプションがMediaInfoから見えないファイルができる。

mbtree等のオプションを変えてみると見える/見えないの状況がなぜか変わり、
変だなーと思いながらmp4バイナリを直に見たら、オプション自体は書かれてたが
最後の値が正しく書き込まれてなかった(nal_hrd= )ので見えない状態になってた。
（バイナリを1byte書き換えたら表示された）

raw出力なら問題ないみたい。

再生時に判定が自動だとデインタレされず縞々
ffdshow等では指定できるからまだ良いが、MPC Viedo Decoderとかだとやびゃあ

>>292
http://www.esnips.com/doc/68421c82-1326-4b42-89e6-635017f2c21d/68421c82-1326-4b42-89e6-635017f2c21d

とりあえず、これは上手く動いた。

http://www.mediafire.com/file/uzqyjiymtz2/x264-r1400M_Windows_32bit_64bit_generic.7z

64bit版ﾏﾀﾞｰ

いや普通にあるだろ。

どこ？

>>298
この馬鹿はr1400の64bitまだかと聞いてるんじゃないか？

>>299
>>296

x64版は、avs2yuvと組み合わせて使う。

x64版をAviSynth2.5.8MTのSetMTModeで使う場合は、スクリプトの最後にDistributor()をつけなければならんのか
lavf/ffms2使えるビルドなら大丈夫なのかな？

>>302
avs2yuv input.avs - | x264 --stdin y4m - --output output.264

私も2.5.8MTを使っているけど、こうすれば普通に動く。

>>303
動くけど遅くならない？

>>304
それでは、これを参考にpipebufも使ってみたら。
http://forum.doom9.org/showthread.php?t=144140

>>305
んなこたぁ、最初からやってるんだよ

わからずやさんのために、ちょっとしたベンチマーク
ソースは適当にDVDから持ってきた

http://ja.pastebin.ca/1764081

俺の環境はQ9450/8GB/Win7 x64(ultimate)
Distributor()ありだと59.70fpsでて、CPU使用率も100%近くいくけど
なしだと41.67fpsでCPU使用率も50%〜80%をうろうろしてる

最近SetMTMode使ってなかったから気づくのが遅れたが、
http://doom10.org/index.php?topic=55.0
と同じことらしい

ちなみにavs2yuvのかわりにffmpeg使ったら、Distributor()は要らなかった

こちらでは再現しない問題なので何ともいえないが、一応解決策は有る様なので何より。

あと、Convolution3Dにはこれを使えばYV12のままで処理ができる。
http://hellninjacommando.com/con3d/beta/index.html

長文で質問失礼します。
自分は暫くr1319(nl版)を使っていたのですが先ほどr1400でエンコしてみたのですが
映像が動かない(シークしても音声だけ正常で動画部分が動かない)ものが出来て
しまいました。
初めはr1400のバグかと思いr1391でもエンコしてみたのですが変わらずでした。
その前のr1976では問題なくいつも通りの動画が作れました。

自分のエンコード環境はaviutlで編集しavsファイルを作りavsをaviutlに読み込ませて
aviutlとavisynthを使い”x264出力(mp4/mkv)プラグイン”でmp4ファイルを作っています。

オプションは
--crf 20 --profile high --preset medium --level 4.2 --ref 3 --mixed-refs
--bframes 3 --qpstep 8 --weightb --weightp 0 --trellis 0 --direct auto
--subme 7 --no-fast-pskip --no-dct-decimate --partitions p8x8,b8x8,i8x8,i4x4
--8x8dct --scenecut 75 --me umh --merange 32 --aq-mode 0 --psy-rd 0:0 --no-mbtree
--b-adapt 1 --threads auto --thread-input

です。

再生環境はMPCとcoreAVCです。

猫科研究所の更新履歴みてたらr1979での追加オプションが現状のmp4スプリッタ
で対応できていないから不具合が生じるな感じで書いてありましが自分のも
スプリッタの問題なのでしょうか・・・

ご教授よろしくお願い致します。

>>309
マルチ乙

>>309
x264 初心者質問スレ part2
http://pc11.2ch.net/test/read.cgi/avi/1247319611/740

この前のマルチ君かねｗ

YAMBでチャプター(OGM)の誤字を直そうと取り出すと
文字化けは我慢するとして時間表示が狂いませんか？

mp4boxからチャプターをextractするコマンドを教えて

ない

nal-hrdを使う場合の現時点の安定版は、1391+nal-hrdパッチでいいのかな。

俺はｒ1400でもVまに氏のとこの最新パッチで何も問題はないが

>>315
x264_hrd_pd_interlace.20_r1391のこと？

いや、x264_hrd_pd_interlace.21_r1400.diff

あら、まちがえた

NAL_HRD.10bが腐ってる

Vまに氏のｒ1400でインタレ保持エンコードした後、tsMuxeRでmuxしてTMPGEnc 4.0 XPress
で読むとプログレッシブになりませんか？

>>321
x264_hrd_pd_interlace.20_r1391のパッチ版でエンコードしてました。
スレを汚してすいません。

r1400でseraphy氏も初期ディレイカット廃止か

seraphy氏のおまけ版更新されないかなぁ

2年前にseraphy氏が「edts対応は2年後に」と言ってたDtsEditに期待

>>323
なぜ？
その場合Bフレ使ってる場合の対応はどうすればいいんだろう

>>323
なぜ？
その場合Bフレ使ってる場合の対応はどうすればいいんだろう

どうした？

P2が糞重いことの弊害
書き込み失敗したので生で書き込んだら失敗したはずの
P2が後から反映された

ブルーレイってAVC使ってるらしいけど仕事でするプロはエンコーダどんなもの使っているんですか？アップルQTPですか？

>>330
一例
ttp://panasonic.co.jp/blu-ray/story05/

どこの世界にMainProfileのBDが出てるんだ

ブルレイ一応MPEG2とVC-1もサポートしてるのに知ってる範囲で全然見ねえ

>>331
ありがとうございます
こういう資料が見たかったところでした
ということはプロは規格に完全に準拠したとんでもないエンコーダエンジン（しかも爆速）をつかっているんですね
羨ましい

VC-1てBD-Videoで必須コーデック？
DVD-VideoのDTSみたいにオプションだったら採用されてないのもわかるけど

まぁ仮にスタートラインで同じ性能だったとしても
エンコーダの改善が実質MSでしか行われないVC-1よりも
多数が研究してるH.264の方が間違いなく良くなっていくよな

>>333
映画はmpeg-2もvc-1もh264も見るね

>>333
AIRのBDがMPEG2だたよ。

うたわれもMPEG2

MPEG2の方は以外にあるんだ
ていうかなんか怒られそうだから先に謝っておこう
スレチの話題ふってゴメンなさい

初期のBDでMPEG2多いかも
AIRはMPEG2だけどKanonはAVCになってる
M:I3もMPEG2
MPEG2が入っているのはまともなAVCエンコーダが出来るまでの繋ぎの気がする

VC-1作品は手元にはない、ワーナーがよく使ってるらしいけど

>339
知っている範囲が狭かったということですなｗ
ワーナー作品はようやくH.264にシフトしたけど、ダークナイトとか
割と最近の作品までVC-1でやっていたよ。

AVCのノウハウがまだ無かったんだろうな。
とりあえずMPEG2の超高ビットレートでお茶にごしとけーみたいな。

>>340
元々BD陣営は高レートのMPEG-2で十分って考えてたかと。
PHLがAVCの改良するまで、高レートAVC＜高レートMPEG-2だったはずだし。
だから、BD初期の作品はほとんどがMPEG-2だった気がする。

VC-1はHD DVDが主に使ってたんじゃないっけ？
BDより容量が少ないHD DVDは、MPEG-2じゃ
BDと勝負出来ないから。

ワーナーがよく使ってるのは、ワーナーが
元々HD DVD陣営で、ノウハウが有ったからじゃないかと。

ハリポタはVC-1だったな。VC-1はグレインノイズに弱いとかで嫌ってる制作もいるそうだけど

質問です
@最新ハリウッド映画のマスターテープはデジタルに無圧縮変換するとしたら解像度はどれぐらいに相当していますか

@(効率悪いですが)将来的にはマスターテープを無圧縮収録した大容量メディアでの販売はありえますか？

うん、スレ違いです

質問です
空気読めない
場の空気をしらけさせる
ってよく言われませんか？

>>347
質問です
空気読めない
場の空気をしらけさせる
ってよく言われませんか？

DtsEdit_20100126.rar

> □20100126
> 2年が経とうとしています。
> というわけで、edts対応を復活させました。

Haaliもはやく正式ビルド出してくれ

>>345
Digital Cinema System Specification Version 1.2
ttp://www.dcimovies.com/DCIDigitalCinemaSystemSpecv1_2.pdf

みればいいんじゃないかと思うが、スレ違いだな

NGID:ImDM8GFB

>>351
ありがとうございます

今夜はちょっと色々やってみて#x264での数人に大変なお世話になりました。
日本から帰ってきて、４日目になるところで一応64bitなffms2付きなビルドをしてみたテスト。
ttp://x264.fushizen.eu/?p=81
MPEG-4 ASPなMP4ファイルでテストしてみたところ、いい速度出して動いてました。
興味がある人は試したら結果を教えてくれれば嬉しいです。

明日はNal-hrdでも試してみようっと。

r1414

r1414でx264_threads_cosmetics_v2.diffが採用されて、
x264_thread_pool_v2.5.diffが当てられなくなった
どちらもエンコ速度は変わらんかったけど

ｒ1415

>>356
ttp://stashbox.org/782108/x264_thread_pool_v2.6.diff

r1414

>>358
d(ﾟДﾟ )☆ｽﾍﾟｼｬﾙｻﾝｸｽ☆( ﾟДﾟ)b

x264_threads_cosmetics_v2.diffが採用されたせいか、
x264_thread_pool_v2.6.diff入れても、あまり変化が感じられない・・・

しかも、MyPCがi7だから温度によってターボブーストのかかり方が違うから、
毎回、数十kbpsの差がでるｗ

CLI処理すると以下のランタイムエラーが出てしまいます。
すぐ出る時もあれば、しばらく経ってから出たり、正常にエンコード出来る時もあります。

Microsoft Visual C++ Runtime Library
Runtime Error!
Program: x264.exeがある場所のフルパス
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

PC構成
OS：WinXP　Pro　SP3
マザー：ASUS P5K PRO
CPU：Core 2 Quad Q9450　2660 MHz
メモリ：3G
グラボ：LEADTEK WinFast PX8800 GT ZL、Directx9.0c

使用フィルタ等
avisynth2.5.8。warpsharpパッケージ。WarpSharp。UnsharpMask
setMT。Trim。EraseLogo。FFT3dGPUまたはFluxSmoothST。TIVTCまたはits
GradFunkMirror。crop。Spline36Resize

逆テレシネとノイズ除去はMTモード5。それ以外はMTモード2で使用してます
EEDI2も修正されたものに変更しました。
2005SP　2008　2008SPの再配布は全部入れなおし、msvcp71.dllとmsvcr71.dlｌも違うサイトのやつを使用してみましたが
結構な頻度でエラーが出ます。このままでは、同時エンコードできません。
エラーがｘ264.exeと出てるので質問スレではないですが、他にどうすればいいかもわからないので質問しました
どうか助けてください

>>361
一応答えてみるが
問題が出たときはまず切り分けましょう

MTを切るとどうなの？
フィルタを使わなくてもエラーになるの？
x264のバイナリはどこから持ってきたの？他のはためしてみた？

そうやってまず何が原因なのかを絞り込んで下さい

あっｘ264バイナリ忘れてました
最初はseraphyさんのOreAQ1182を使っていましたが、エラーは頻繁に出てました
で、バカポ氏ビルドのx264 r1391に乗り換えたのですが変わらずです
バカポ氏のやつは違うバージョンも試しましたし、他の方のビルドしたバイナリもいくつか試しましたが、同じでした
MTやフィルタを完全に切って試してないので、それをまずはやってみます

>>361
自分も2.5.7から2.5.8にしたら同じエラーが出るようになったから戻した
原因は分からん

>>361
avs2yuv input.avs - | x264 --stdin y4m - --output output.264

こうやってAviSynthとx264を別のプロセスで実行させてみたら。

r1416M generic: http://www.mediafire.com/?mqzogqyxzld
r1416M amdfam10: http://www.mediafire.com/?tzm5ddyjm43

やっとのことでlavf/ffmsつきのx64ビルドに成功した...ついていくのがしんどい

>>313
亀レスだが、mp4boxで-infoで見れば、文字化けもしないし時間表示も狂わないっぽい

>>366
あんがと

seraphy氏のサーバーメンテナンス終了予定がとんでもないことになってるのね...

もう1416なのかいまだに1163だ

どうせ殆どがくだらんバージョンアップだ
r999から殆ど画質は変わらんよ

>>372

ディレイカットがなくなったせいなのかしらないが
1376より後(1400とか)のauoを使うと動画再生開始時にカクッとなるんだが
これって何がどうなると改善されるんだろうか
これが改善されないといつまでも1376から移行できないんだが

それはお前が使ってるスプリッタが仕様違反で腐ってるせい

mkv使えばいいじゃん

>>374
x264 VFW GUI専用スレ Part5
http://pc11.2ch.net/test/read.cgi/avi/1258081149/

　　　　　　 /|
　　　　　　 |/＿＿
　　　　　　 ヽ| l　l│＜ﾊｰｲ
　　　　　　　┷┷┷

　　　 _, ,_ 　パーン
　 （　‘д‘）
　　　⊂彡.☆＝＝＝＝＝＝ /|
　　　　　 　.＿＿　　　　　　　|/
　　　　　 ヽ| l　l│
　　　　　　┷┷┷

>>377
ありがとう、解決した
これでauoをまた最新にできる

http://headlines.yahoo.co.jp/hl?a=20100127-00000123-mai-soci

tmはts職人、アニメ職人ではない

ts職人ワロタ

ZIP圧縮職人とかも居そうだなｗ

新しいx264だめだ使い物にならん

1416のこと？
最初の部分が再生されないよね
Win7にしたばかりだったからWin7のせいかと思ったけど1376に戻したら大丈夫だったから1416のせいなのかな
1416でもWMP12で再生すれば問題ないんだけど・・・

ED60fpsの動画のせいかしらないが
1469.xxxの映像と1469.xxxの音声をMUXしたら
1531.xxxの映像と1469.xxxの音声の動画が出来上がった
わけわからん

TimeCode壊れたな

x264OreAQのミラーってない?
seraphyの鯖メンテで消えちゃったみたい...orz

VFR maniacでググれ

http://www.47news.jp/CN/201002/CN2010020401000240.html
http://www.jiji.com/jc/c?g=soc_30&k=2010020400242

赤がブロック女になります。ならないようにするにはどうすればいいでしょうか？
画質の評判の良いバージョン教えてください

x264使うならあきらめろ

色空間の勉強した方がいい

わかりました。諦めて最近開発されたH.265使うことにします。
ありがとうございました。

誤爆です。

seraphyたん鯖復活したみたいだよ。

>>396
普通に落ちてるが

落ちてるのが普通なんかい！ｗ

seraphy氏の話ついでになんだが、MP4 Pluginもやはりミラーはない?
必要になったので使いたかったんだが鯖が落ちているとは。

今は普通に繋がるね

すぐに見に行ったけど駄目じゃんｗ
俺が書き込んで10分後に直っているわけもないか。

こっちからは繋がるので>>401はネットワークを疑った方が良いぞ

おおー、マジで復活していたｗ

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

HDサイズで＋にするのはあまりお勧めはしない
暗部のブロックノイズが大きなブロックノイズになるだけだからな


デブロックに関して過去スレで↑みたいなレスがあったんだが
この通りなの？

>>404
それはブロックノイズの意味を理解してないからスルーしろ

デブロック使うよりもバンディング低減フィルタとかでノイズを付与する方が効果的

私は、GrainFactory3で暗いところにだけグレインを足して、--deblock -1:-1にしている。

まあビットレート上げろって事ですよ

気が付いたら1173から変えてない浦島状態なんだが、
すんごく高速になったとかすんごく便利なオプションがついたとかあるか？

ないあるよ

比較的安定した版はどれあるか？

最新版

998でも使ってれば？

r1318

つながらないよ？ http://x264.nl/

14xxはまだ様子見が正解

>>416
適当なこと抜かすなよ
根拠も言えない癖に

誰かが「14xxは鉄板」と言えば>>416の様子見は解かれると思う。
大体みんなそうだろう。そういうもんだ。

じゃあ、ほれ

http://doom10.org/index.php?topic=58.0

r1416は鉄板と開発者様直々のお達しだ

早くも無いし綺麗でも無いならr1376で十分だ

interlaceに関してはいつまで経ってもVC1以下
patche無しではそれこそ使いモノにならない
ずっと様子見しておくといいよ

やっぱr1376が最高なのか

まだ1376がいいな

r1416がr1376に劣っている点はひとつもない
現時点で最高なのは間違いなくr1416

まあ最近の更新はlavf/ffms2やらPIRやらで、ここの住人の大部分にとっては
ありがたがるようなものでもないけどね
機能的にみればものすごい向上だけど

まあ画質的にみりゃr999から進歩してないからそうなのだろうね

枯れたのでも最新のでも好きなの使えばおｋ

999に拘るやつは銀河鉄道でも好きなのか？

やはり、x264と比べるとVC-1は劣っている。
http://www.mediafire.com/file/3jt2yknnjny/x264 vs VC-1 (interlaced).zip

URLエンコードくらい・・・

そうね。だから？としか。
インタレ保持なんてしねぇよ・・・何のためにエンコしてるんだと・・・

あぁ実写のこと考えてなかった。
>>430はアニメの話。実写はしらね。エンコしたことないしな・・・。

VC-1がいいならそっち使ってれば？って話
x264マンセースレにVC-1がいいなんて事言われても

P2Pを使った著作権侵害への対応ガイドライン策定
−権利者とISPが協力して策定。対象はWinnyから
http://av.watch.impress.co.jp/docs/news/20100208_347818.html

取りあえず1376入れてサイト参考にオプション設定していくつか出力してみたが
概ねエンコ時間は短く、画質はよくなってるな

>>415
ミラー
http://mirror05.x264.nl/

>>415
中の人が行方不明

>>436
あーそうなんですかorz
最新版バイナリを手早く取得できて助かってたんだけどなぁ。

自分でビルドするべし

428みたいな人をまさに信者というのだろうか
そうやってムキになって何でもかんでも盲目的に擁護する前に
なんでx264_hrd_pd_interlaceパッチあててビルドしている人が多いのか
その辺を少し冷静になって考えてみなよ

うーむ、やっぱb-pyramidだとDXVAで変な動きになるな
OreAQやMixAQだとより顕著になる
しばらく外した方がいいみたいだ…

>>439
率直に言って、x264相手だと画質の悪いVC-1は擁護のしようがない。
プログレッシブのソースだと、Real VideoやVP7に負ける代物だし。

http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png

あと、これがマージされたら、パッチは不要になる。

NAL HRD patch v1.22 beta test thread (updated)
http://forum.doom9.org/showthread.php?t=15212

NAL HRD patch v1.22 beta test thread (updated)
http://forum.doom9.org/showthread.php?t=152127

URLを間違えた。

そのパッチを当てると何がどうなるんですか？

次のコミットで入るとかいう噂

>>443
ビットストリームに、"pict_struct: 3"の様にして書き込む事ができる。
これが無いとフィルードオーダーを区別できない再生環境がある。

つまりインタレ保持じゃなきゃ、影響は無いって事か。

i7 860でx264のthreadsの値は12(スレッド数の1.5倍)のほうがいい?
それとも16(スレッド数の2倍)のほうがいい?

0

まあどうでもいいけど物理コアは4個しかないんだぜ

0ということは、0=8?

x264使っても、CPUの使用率が30%ぐらいまでしか上がらないのだが、どうすれば上げられる?
おかげで、fpsが2.0以下しか出ず、エンコード時間が5・6時間かかるよ。

スレチ(イタチ)ならば失礼します。

連スレ失礼。
実際、i7環境で--theades 16で動かしてる人いるの?

i7-975 でthreads 0だが、8コアで動いてCPU100%だな。

ボトルネックを切り分けてからもう一度。
MPEG2Source("src.d2v")
だけだってHDソースでHDD遅ければ10fps行かずにボトルネックだからな

>>447
HTの稼働率を考えたら８のままでいいんじゃない？
ソースがavsだったりすると、そっちの処理でx264が待たされて、
全然ロードバランシングがとれないこともあるけどｗ

普通にx264以外の問題だろ

4つ同時にエンコすればOK。

普通の4コアHT無しでもCPU半分くらいしか使ってくれないx264はﾀﾞﾒﾀﾞﾒとか
言う人たまにいるけど良く聞くと他にボトルネックあるだけなのに理解してないんだよな。

>>447
12(スレッド数の1.5倍)だけど「--threads auto --thread-input」の記述でO.K.

x264に詳しい人はハンドブレーキ最新版を使って満足している人を見てどう思いますか？

＞どう思いますか？
「はい」,「うん」や期待通りの回答とか欲しいときは、
ツイッターとか適当なSNSをご利用ください。
x264に詳しい人ってなんだよｗｗｗｗ

やふちえあたりが最適

>>458
サンクス。試してみるよ。

>>459
Dark Shikari氏はHandBreakを愛用しているそうですが、あなたはどう思いますか？

>>459
x264もHandbrakeも動画を作るための道具なんだから、それぞれ目的にあったものを使うだけだよ。
iPodとかPSPで見て消しするだけのmp4作るために、
多大な労力を払ってマルチパスの究極の低ビットレート高画質に挑戦とかただの馬鹿だろ？

>>464
ありがとう。こういうレスは素晴らしいです。
実はハンドブレーキという作られた狭い世界だけで満足していいのか疑問に思っていたのです
自分の目的ならハンドブレーキで十分だと思えてきました
ありがとう

※真面目に質問してるのにに冷やかしが多すぎます。

うっぜいわ〜

話の流れがあるならまだしも、いきなり曖昧な投げっぱなしの質問しておいて、
真面目な質問はないわ。

>>465
冷やかされるような質問の仕方するからいけないんだろ
今度から気をつけた方がいい
これは真面目な忠告

>>465
> >>464
> ありがとう。こういうレスは素晴らしいです。
ベストアンサー？

自分の気に入らないレスは全て不要
おまえは2ちゃんではなく教えて系に投稿しろ

http://internet.watch.impress.co.jp/docs/news/20100209_347998.html

店に置いたらアウトだがｗ
まぁここで書くほどのねたでもないだろ

--threads auto --thread-inputにしても、速度が上がらなかった...orz
むしろCore2 Quad時代の方が負荷がかかってた。
i7にしてから負荷がかからないのはおかしいな?
なぜか、メモリの使用率は高い。

どうせavisynthが足引っぱってるだけだろ

>>473
HDDがネックになってるんじゃないの？

HDDに１票

HDDならソースによるだろうな。ソースのフォーマットは何？

i7のハイパースレッティングをあえて切ってみれば良いのでは

可逆圧縮でフィルター無しとかならともかく
X.264を使ったエンコでHDDがネックになるもんだろうか？

ソースと吐き出しが一緒ならネックになるだろ

別にならんよ元ソースがBlu-rayのH.264だろうがHDDなんて分けなくても
速度変わらん。実際試したし。

断片化しまくればあるんじゃね

時間かかると思うなら解像度落として出力しようよ

何も考えず作業ドライブもCaviar Greenにしたバカ(オレ)はHDDがボトルネックになってる
tsソース(d2v)で、同じようなフィルタで地デジはCPU埋まるけどBSは埋まらないとか

せめてAHCIモードで

エンコってランダムアクセスだったのか
てっきりシーケンシャルかと思ってた

ソースと吐き出しが一緒だとランダムアクセスになる
断片化しててもランダムになる

HDDがボトルネックになってると言ってる人は、presetをultrafastにしても、
avsの中身をソース読み込みだけにしても速度が変わらないの？
それで速くなるようなら、Avisynthで詰まってるか、単純にMTの限界か、
ロードバランシングが取れてないか、って所？
スレチだが、SetMTmode(2)を使えばCPU使用率100％になることだってあるよ@i7-920

>>486
Caviar Greenの低速病ですか。 ﾅｶｰﾏorz つ[SSD]

エンコにSSDなんか使えるか
もう懲りたし

バッファに貯まるまでflushしないから入力と出力の二つ程度じゃ
それほど大きな問題にはならないと思うよ。非圧縮AVIがソースだとHDDがボトルネックになるんじゃね？

非圧縮や可逆圧縮だとHDDがボトルネックになるよ
ちゃんとキャプチャして編集している人は注意したほうがいい

非圧縮や可逆圧縮ならキャプチャの時点で遅いHDDアウトだしそういうの
使う人は言われなくてもって感じじゃね。

>>492
書き込みは最悪、ドロップしない速度あれば大丈夫だけど
読み出しだと僅かな差で数十分〜数時間速度がかわる

書き込みがドロップってx264は非同期で書き込んでんのか?w

>>492
例えばキャプチャでフルHDの30fpsをギリギリ書き込めるHDDがあったとする

エンコード時はCPUパワーがあって40fpsくらい出るとしても、
読み出しでHDDのリード速度が追いつかない
こうなるとウエイトが掛かってCPUは時々遊んでしまう

CPUのパワーがあればあるほどこういう事があり得る

最近のCPUならHDをx264の最速設定でリアルタイムキャプできんじゃねえの?

キャプチャの段階でわざわざH.264なんかで圧縮してもなぁ

まったくだ。UtVideoかなやっぱり。

オプション変えながら時間ベンチマークしても面白いかも

次のパッチも一括大量投入らしいね。

不具合さえなければ一括でおｋ

一括のほうがテストが楽だし。

最新を使わないと死んでしまう病の俺にとってはこまめに更新してくれた方がいい…

ここの評判しか見てないので、がんばってテストしてね

>>500
そういうのどこでわかるの？
いつ頃来そうとかわかるとすごく助かるんだけど

IRCとかで聞いてきたら？

ｘ264.nl復活

ping返ってこないぞ

>>507
おーホントだ、助かった(*´▽`)
定期的に最新版を見つけたら自動で取り込むスクリプトがムダにならずに済んだ。

ところでUPXってなあに？
なんかバイナリのファイルサイズを圧縮できるみたいだけど、デメリットはあるの？

wikipediaに長所・短所まとめてある。

>>511
ありがと
試してみたけど、配布する人以外にはあまりいいことないみたいね

New B-pyramid testing thread
http://forum.doom9.org/showthread.php?t=152761

今はピラミッドに対応していない機器を挙げた方が早いのだろうな。

--b-pyramid normalとstrictの違いってなんなの?
BDの場合はstrictを使うとか見たような気がするけど

猫科研究所見てこい

対応以前にx264のb-pyramidは改善されないままなので、効果がほとんど無いのが一番の問題だ

改善って？

x264itvfr-r1416.lzh

>>516
--b-adapt 2 ならb-pyramidを考慮してBフレーム数を決めるようになってるが。

MPCHCはb-pyramidを考慮する気が無いみたいだから
気になるなら使うのやめるかsplitterを変えるか、だな

MP4にしか対応していないハードウェアで再生した人以外は、Matroskaを使えばいい。

Matroskaをサポートしたハードウェアはあるんだろうか…

>>522
http://av.watch.impress.co.jp/docs/news/20100122_344249.html
http://www.jvc-victor.co.jp/bd/xv-bp1/index.html

DivX 7に対応しているのが幾つかリリースされている。

>>522
http://www.baycraft.jp/popcornhour/000116.php
http://www.wdc.com/en/products/products.asp?driveid=735

>>521
m2tsでもいいんじゃない?

>>525
オーバーヘッドが大きいから、ファイルサイズを考えると不利だな。

明日更新らしい。

x

x264 --weightp 0 --crf 23 %sar1% --interlaced --nal-hrd --vbv-maxrate 20000 --vbv-bufsize 25000 --keyint 300 --min-keyint 2 --cqm flat --trellis 2 --scenecut 45 --b-adapt 2 --bframes 3 --ref 3 --deblock -2:-2
--qpmin 10 --qpmax 40 --qpstep 6 --qcomp 0.6 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0:0.0 --partitions p8x8,b8x8,i8x8,i4x4 --me umh --merange 32 --subme 9 --no-fast-pskip --no-dct-decimate
--videoformat ntsc --colorprim bt709 --transfer bt709 --colormatrix bt709 --threads auto --thread-input --ssim --no-mbtree -o "temp_video_%~n1.mp4" "%~1"

x264_DANGEROUS_rev1416-release2
OreAQでもMixAQでもインターレースでnal-hrdを使ったときだけエラーが出て落ちる。
プログレッシブは問題ありません。
Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length ), file encoder/set.c, line 683

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

>>529
こっち行け
http://pc11.2ch.net/test/read.cgi/avi/1252765934/

r1442

今月初めての更新か

随分飛ぶな

mp4の動画にedtsが入ってるかどうかを調べるツールってないでしょうか？

……はい？

mp4box

edtsがあるだろうと思われるmp4とそうでないmp4を
mp4box -info でみてみたのですが、違いがわからず・・・。
もう少し教えていただけませんでしょうか。

ぐぐれカス

ツンデレ乙

mp4muxer(mp4creatorのGUI)使えば簡単
ttp://www.restspace.jp/cgi-bin/orz/img-box/img20100216013405.jpg

24型あたりの大画面でDVDコンテンツみたい場合、
エンコする際のcqは18ぐらいがいいの？

24型って大画面だったのか

これだからゆとりは

24型PCモニタ用とか、42型液晶TV用っていう最適cq値ってのがあるの？
最近はモニタも液晶TVもいろいろ動画再生用の機能（東芝ならWスキャン倍速とか）がついてて、
結局自分の環境と自分の目で確認するしかないんじゃないの？

そもそもcqって何なのか教えてエロい人

komisar氏のx264_NAL-HRD.1.22.r1442.diffあててr1442ビルドしてみたが、
インタレ保持エンコできないみたい
tff指定してるのにMPCHC+DXVAだとbffで再生するわ、ffdshow通すと動きがDXVA以上にガクガクするわで
あきらかに壊れてるっぽい
やっぱTrahardパッチがベースじゃないと駄目だなぁ

x264.nlに「recommended revision: 1441」とか出てるんだけど、もしかして1442は地雷？

1442がでたばかりの時は、もっと番号が若かったから、
なんかを一つ一つ確認でもしてるんじゃね？

Komisarのは、--pic-structが駄目みたいだね。

>>544
デカイ方が差がわかりやすい(transparentには、より高い品質が必要)ってのはある。
PHLはBD用素材のエンコードするときに、
マスモニじゃもうわからなくて、縦10フィートのスクリーン使うって言うし。

wightpの削除されたモードっていつになったら実装されるんだろう

Commitの数はあるけど拡張は大したこと無いみたいだね
SVN1442は安定板っぽい？

>540
SSまでつけて解説していただいてありがとうございます。
無事edtsの有無を確認できました。

recommended revision: 1442+

Iピクチャ最強、PやBを使っている奴は情弱

コストパフォーマンスという言葉を知らんのか

情弱などと他人を煽る人間ほど、実は自分に都合の良い情報だけを取捨選択しているので
自分自身が他者からの情報に惑わされていることに自分では気づけないのだ。

情弱っていうか、テクニカルな知識の問題だな。

>>555
自己紹介乙

>>555は
自分が情弱だとみんなに知って欲しいだけ

とりあえず、インターレースのソースでも、kieranrkの新しいパッチなら、
--tff --nal-hrd vbr --pic-structとしたら動いた。--direct autoも使える。

http://www.mediafire.com/file/mjioumyxofm/x264-r1442M_Windows_32bit_64bit_generic.7z

>>555
H.264ひいては、MPEG全てを全否定かよｗ
節約劣化分身の術を甘く見るなよ

まあバランスだよね
あまり偽者を多くすると絵が温くなる

まあ、少なくとも、H.264のIは、jpegより画質がいいわけだが。

JPEGのIに、x264のP、Bは勝てんのか？って言いたいんだろうな

MotionJPEG最高や！って言いたいんだろ

>>566
AVC Intraだろ、スレ的に

>>566
奴らは、面倒くさい相手だぜ・・・
こっちがBDで採用されているH.264が高画質って言うと
ん？こちらはデジタルシネマの標準規格だがとか言い出すからな

もう無圧縮YUV4:4:4でおｋ

扱いにくすぎるだろ

無圧縮は中間ファイルで使ってるけど、それでも持て余すぜ。
特にFullHDの無圧縮はでかすぎて何の確認もできん。
それで次の工程が終わった後、ﾎﾟｶｰﾝなんてこともしばしば。

ピラミッドB最強！



MPEG系のP,Bはともかく
P,B=画質劣化ではないけどね

たとえ、PやBをつかうことによって画質が劣化しても、
それ以上にビットレートを下げることができれば、
それは、画質が良いということだからな。

Bフレで縮んだ分ビットレートをもりもり

ま、サンプリングの時点で劣化してるんだからどうでもいいや

お前それでいいのか？

　　　　　　　　 l;;llllll||lll从从WWWl||ll,,ﾂ从ﾂﾂﾉlｲノ'彡ヽ
　　　　　　 　 ｲ从､从从从从从ll|| |ﾘ从//／／ノノ彡;j
　　　　　　　 jl从从从从;;;;;;;;;;;;从;;;;;/;;;;;;;;;､､､;;-ｰ､イ彡:}
　　　　　　　（ミﾐ;;ｯ''"ﾞ￣ '､::::ﾞ｀ﾞ''ｰ､／"´:::　　::::　|;;;;;彡|
　　　　　　　 }ﾐミ;;;}　:::　　{:: ﾞ:::::､:::　　　 :::ｨ　,,::::　};;;;イ;;l
　　　　　　　 jミﾐ;;;;}　:::　　ヽ::::ﾐヽ::　 |　 ﾉ　 W::　 |;;;;彡:|
　　　 　 　 　 }ミ;;;;;;} :::　ヾ　{:::::ﾐ ヽ　j　ｲ|从　":::: };;;;;;彡{
　　　　　　 　 iミﾞ;;;ﾉ::::::　　＼'､ }}: l||ｲ /,ｨ;;､､-ｰｰヽﾞ'ｧ;;イ､
　　　　　　　　{;;;;ﾘ:ﾚ彡"三三ミヽ,,ﾘ{{,,ノ;;;;ｨ≦==ミ'"　|;;〉l.|
　　　　　　　 l"';;;l　ﾞ'''＜<~(::) >>::）-ら::ｨ'ｰﾞ-ﾞ,,彡ﾞ　 .:|;l"lﾘ
　　　 　 　 　 |l ';;',　:::　ｰ｀￣:::::::ミ}ﾞ'~}彡ｨ""´　　　.:::lﾘﾉ/
　　　　　　 　 l'､〈;', :::　　　　:::::::t､,j　iﾉ:::､::..　　　 ..::::lｰ'/
　　　,､,,,/|　　ヽヽ,,', ::.､　　　 :::::(ﾞﾞ(　 ),､)､ヽ::.　 ｲ ::::l_ノ
）ヽ"´　　 ''''"ﾚl_ヽ,,,', ヽﾞ'ｰ､:::;r'"｀' ﾞ'';;""　 ﾞl|　 ::j ::: |: l,,,,
　　　　　　　　　ﾞ''（,l ',　l| ﾘ {"ｨr''''' ｰｰ''ijﾂヽ　 l| :" l　 |',｀ヽ,
　　　き　利　　　　(l :'､ ｀',. 'l| |;;ﾞﾞﾞﾞ"""´ｰ､;;|　ﾉ:　 /　/ﾘヽ　＼
.　 　 く　 い　　　　Z::::ヽ　'､ ﾞ't;ヽ　｀ ´　ﾉ;;ﾘ 　　,r'　//　 |
　　　な.　た　　　　 >; :::ヽ　　::ヽﾐニﾆﾆ彡'" 　, '::::://　　|
　　　┃　ふ　　　　 ﾌヽ　::＼　: ﾐｰ―― "ノ , ':::: //:　　 |
　　　┃　う　　　 　 }ヽヽ　:::::＼::（￣￣￣　/::::／/:　 　 |
　　　┃　な　　　　 }|　ヽヽ　:::::｀'-､竺;;ニｨ':::／／　　　 |　 　 l
　　　//　口　　　 （: |　 ヽ ヽ ::::　::::::...　　::／／　　　　 |　 　 |
)　　・・.　 を　　　 (　 |　　ヽ ヽ::　 ::::::...　／／　　　 　 ﾘ.　 　 |
つ､　　　　　　　r､{　　|　　 ヽ　ヽ　　　／／　　　　　 /　　 　 |
　 ヽ　　　　　　'´　　　 |　　　ヽ　 ヽ ／／　　　　　　/　　　　 |

--aq-mode 4は、なかなか興味深いな。

サンプル: http://www.mediafire.com/?umy3zj3mgii
ソース: http://www.megaupload.com/?d=67GCXJRY

なんか次の更新あたりでAutoVAQは4の処理に替わるみたいな感じだね

>>579
だとしたら普段からaq-mode 4常用してた俺としては嬉しいかも
ってかそういう情報ってどこで手に入れられるんだ？

IRC

開発者じゃなくても#x264devは入ってもいいのかな？

ROMいっぱいいるから大丈夫だと思うよ

>>583
とん

久しぶりに使ったらSSE4対応してたんだな。
速くならないから対応しないとか言ってた奴いたのに。

素人はんは、CPU CapabilityにSSE4と表示しとくだけで、納得してくれはるから助かりますわ
pblendwやlzcntをとりあえずつこうてみただけやのにね

1459

もしかして今rev1459くらいになってる？

って既にレスあったわorz

1460

修正早っ
新しいコミット18のうち14がDS氏のとか、頑張りすぎだろ……

kieranrkのHAL-HRDは、まだ入っていないのか。

nal-hrdはまだ時間掛かりそうってどこかで見た気がする

うーん、r1460の64bitビルドでmake fprofiledすると3回目のエンコでクラッシュするぞ...
D_Sも寝てるからすぐには直らない…って、おや？

r1460ビルドしたらヘルプが文字化けした…
デフォルト値がありえん事になってる…ｗ
-I, --keyint <integer> Maximum GOP size [2791512]
--b-pyramid <string> Keep some B-frames as references [???]

BugMaster氏が即効でパッチ書いてくれた
http://pastebin.com/GEGvfb89　　fprofiledのfix
http://pastebin.com/iv7W7mUH　　helpのfix

>>596
おお、わざわざありがとう
正式にコミットされるまでしばらく様子見しますｗ

どうやらメモリリークが見つかったようなので、r1460は結局スルーがいいみたい

情報サンクス

ｒ1461

ヘルプ直ったぜ……
いや、自ビルドしたのは今回が初めてだったもので、>>595-596読むまでは
俺のビルド環境が悪いのかと思ったわ

1462

ｒ1462

r1462

やってしまったあっっっ

あれ、ヘルプ見たらr1463になってる
誤植？

とりあえず、mbtreeと併用しても問題が無い様に改善された--aq-mode 2を試してみたいと思う。

じゃなかった、r1463で正しかった……
半年ROMってますorz

#define X264_VERSION " r1463 8918e83"

とりあえず、今はこうなっているな。
まだ何かあるかも知れないから、コンパイルはもう少ししてからにするか。

r1463

1462でまたビルド中にクラッシュしたと思ったら…
しかも1463でもクラシュするし…現在BugMaster氏がpatch書いてる

ｒ1464

r1463再コミットじゃない？

#define X264_VERSION " r1463 271c877"

r1463のままで、ハッシュが変わっている。Win64での問題は解決された模様。

みたいね、ごめん

これもバグ持ちだったよ...

04:19 (Dark_Shikari) should work fine now guys
04:19 (Dark_Shikari) just reset your tree

>The current latest version is r1462. r1463 will generate corrupt output for some resolutions, like CIF.

x264 0.89.1462M 7fcffde: http://www.mediafire.com/file/ntmddqmtjtc/x264-r1462M_Windows_32bit_64bit_generic.7z

aq-modeが良い感じだね。
暗部の潰れが良くなってる。

>>579の言ってた通り--aq-mode 4のパッチの処理が正式にAutoVAQに採用されたそうで
アニメでもいい感じに働いてくれるから正式コミットを待っておったぜ

結局r1462に落ち着いたのね

ページに上がってるのも、r1462になったのか

旧aq-mode 2はビットレート削れすぎでアニメ・実写でも使えなかった

aq-mode2は論外だったけど4は1よりもいい感じなの？
自分で試せって？うんその通り

実際最終的な判断は個人の裁量が一番でかいから試すほうがいいと思うのだが
というわけで 2行目を実行してたぼれ

でも画質テストって難しいよな
1コマ1コマ止めて確認すると綺麗になってるからと言って
いざ再生してみるとそうでもなかったり

それこそプリセットのplaceboじゃないけど、思い込みによるところも大きく働きそう

>>624
再生する環境によってもだいぶ違う。
動画再生支援の無いノートPCと
動画再生支援のあるデスクトップで、
何故か前者が綺麗に見える場合がある。
（特に実写）
たぶん、にじみ具合？の差なんじゃないかと思ってる。

実際1か4かどっちがベターなのか気にはなるわな
ソースによっても違うし見る人によっても違うんだろうけどね

再生支援もそうだが液晶ディスプレイによっても結構変わってくる

SSIMでも見ればいい

SSIMも一応参考にはするが、0.9935064だの0.9932632だの言われても
「じゃあ0.0003大きい方が綺麗」とはならないと思うんだよな
数値だけじゃなくて実際に見ないと

SSIMは0.001差なんて無意味とか言われてなかったっけ？
特に低ビットレートのエンコはどれだけソースに忠実かというよりも
どれだけきれいにごまかせてるかっていうのが重要だろうから
そういう絶対指標はあんまアテにならんだろうね

x264のSSIMって輝度のみで算出してるらしい(?)から数字が当てにならない場面もあるよね

しかし、YCbCr 4:2:0だったら、他よりも解像度の高いYの画質が重要なのは間違いないだろう。

数字の意味するところを踏まえた上で使うなら良いんだけど、
単なる大小だけが一人歩きしないか不安ではある。
非可逆圧縮音声がそういう状況になって久しいし。

seraphy氏のauo1442でmbtreeが勝手に使われる
deadzone変えても利いてない様な気がする

自己レス>>634
設定ファイル反映されてませんでしたどうもすみません

1471

猫研さんのr1465の訳
「ffmpegより、Port Mans RullgardのNEON版intra予測関数。」
って日本語になってないような
portは移植だよね？

正しくはMans RullgardのNEON intra予測関数をffmpegより移植、ってところか
ただでさえ専門用語含んだ英語の翻訳は難しいだろうに、
辞書に載ってないような半ば省略された動詞とか使われると気付きにくいんかね

interlaceオプション使うと
30pでも60iでも1%ぐらいしかサイズ変わらないんだな…
サイズ優先で30pにしたけどアホだったわ

そりゃ30pにした時の処理が、
圧縮に適しなかったんだろう

30pと60iじゃ同じじゃね？
サイズ優先なら30iにするべき

きっとネタで言ってるんだろｗ

TSアニメをエンコする場合に、自己満足の画質を達成するには10Mbbsいるという・・

掲示板のことか

アニメならエンコなんかしてないでBlu-ray買えよ
お前の自己満足はテロップでててもかまわないのか

>>645
そこは妥協

素人質問ですが、インターレースを解除したファイルでも「multiAVCHD」とかでオーサリングすれば市販のブルーレイプレイヤーで再生して
テレビで見れるって理解で問題ないですか？

市販のブルーレイの規格に則った動画ファイルならそうなるね

>>645
アニメは全部Blu-rayで発売されていると思っている本物の馬鹿発見

解像度・FPSが適切ならってことですね。
ありがとうございました。

>>649
Blu-ray版も出ないゴミアニメなんかエンコする価値も無いだろ
目的と手段がごっちゃになった真性の阿呆発見

底辺の争い

>>651
ここでそんな事いってるお前が一番のゴミだって事に気付け。
俺も真性の阿呆発見したわ。

このスレには、高画質エンコやる人いない？

そこに映像がある限り、価値のない映像などない

>>654
Download板に帰ってください、お願いします。

>>６５６
？なしてDownload板

そういえば、昔、高画質でエンコしてあげるスレってのがあったな。
今もあるのだろうか。

流石に今だと露骨に法に引っ掛かるから無いだろ
いくらザル法と言えど

ﾀﾞｳｿ板は低容量低画質が殆どだしな。

今日の津波警報画面は拷問レベル

>>637-638
どうでも良いかもしれんが、今見たら直ってたわ

今日のはなまるは日本地図出るのか

tesu

おお復活か

更新無い時だったから関係無かったな

せっかくの地デジなんだからテロップとかは
映像とは別レイヤーにして欲しいな。
ついでにi/pやfpsの情報も送信されれば言うことなし。

いや、それに関してはiの29.97fps固定だし……

1080Pで流すのが先だろ

ビットレート足んねーってば
たった16Mbpsで1080Pなんかやったら今以上に画が破綻する

おお、ついにNAL-HRDのコミットが来るか
次はフィルターとデバイスセッティングになるのかな

疑問がふたつ。
fps指定しなくてもRateControlが動くって書いてあるけど、
これは入力ソースのフレームにタイミングの情報が入っている
場合限定ってこと？

CBRの話。TS Muxingに必要なx264_hrd_tってあるけど、これは
映像のみの話だよね。音声のトラックとか増えたり減ったりするだ
けでTSとしてはCBRが崩れちゃうってことにならないんだろうか？
それともCBRにすべきなのは映像のみってことになるのか？

BD向けの改良が続いているけど、BDは--keyint 24とかになる訳だし、次はopen GOPをやってほしい。

>>656-657
ダウソ板なんて、逮捕されまくりのアホばっかりだろｗ
あんなアホと一緒にされてもな

ここは著作権物は個人理由の目的でしかエンコしてないよ

＞あんなアホと一緒にされてもな
＞ここは著作権物は個人理由の目的でしかエンコしてないよ
免罪符になりません
あんなアホと一緒です

スレチ
他所でやれ

Down板にあるエンコード関連のスレはいうなれば、初心者スレ
だからそっち行けっていわれたんだろ

Open GOPﾏﾀﾞｰﾁﾝﾁﾝ

>>675
え 自分で見るのもダメなんか
じゃぁこの板つうかエンコ自体がダメなん？

猫研の人のlibx264の使い方記事が待ちきれない

そんな自演はいりません

いつになったらadaptiveなMBAFFが

>>637-638
単なる勘違いで、大した英語力ではないのでよくあることです
ちなみに一般英文より専門英文の方が普通は訳しやすいはずです

>>662
後々ちょこちょこと直してる部分は結構あったりします

>>680
備忘録レベルの予定なので役に立つか謎で、まだ手もつけてません
お急ぎでしたらffmpegのソースでも見た方が多分早いです

乙、そして休職へ・・・

>>683
いつもありがてぇ
マジ乙

>>683
猫は求職中か？で参考までにスペックは？

ｘ２６４ってのっぺりしるぎる・・・

そうかおれのx264はグレインまでバッチリだ

crf1でおｋ

ロスレスだと、グレインがきれいに表示されるけど、crf1だときちゃない。

あ、劇的に改善されたｗ

>>686
これは私個人の能力を問うてるんでしょうか？
ごく普通の人間ですよ、敢えて言えば器用貧乏です

得意技とか必殺技とか

スリーサイズとか

トランクス派とかブリーフ派とか

実は男の娘だとか

いつもお世話になってますこの場を借りてお礼をば
それはさておきストッキング派かニーソ派か

断然ニーソ。

お前にゃ聞いてない

うっせえよ、俺はガーター派だ。

しねよカスども

どっかで見たツイッターごときスレみたいだな

twitterなんてなかったころからこんな感じですが

やっぱr999が最高だよな

今は画質の向上はあんまりなくてエンコ速度の向上だからそれでもいいんじゃない？

面白そうなオプションがちょこちょこ追加されてて面白いじゃん

r1318の調子良かったからずっと使ってた。
今は昨日いれたr1471。

調子はまだ本格的に動かしてないから解らないw

量子化マトリックスって、一個しか指定できない・・・

規格上そうなの？それともx264がまだ対応してないだけ？

>>708
複数指定したとしてそれがどう使われることを望んでいるの？

ちなみにH.265/HVCの新しいfeatureに
adaptive quantization matrix selectionってのがあるから
これはH.264にはないんだろうと思う
ただ別ストリームとしてエンコードしてTSにでも連続で格納すれば
1ファイル中で切り替えること自体は可能な気もするけれど

MPEG2はGOP毎に変えられるから、それが出来ないかって事じゃないの

そうそうGOPごと変えたい・・・

H.265では、もっと細かく変えれるようになるのかな・・・
ワクテカ

なんだ、使い方が下手糞なだけじゃねーか

PHLの記事とか読んでるとBD用のエンコでシーン毎に行列変えてるって話も出てるから
できるんじゃないの？規格上はPPSにも量子化マトリクスに関するフラグがあるから
その気になればピクチャ単位でマトリクス変えられるんじゃない？あんま良くわからんが

結局新AQ2はどうなったの

自分の目で確かめるのが一番

ていうか1471は鉄板でOK？目立ったバグとかなさげ？

鉄板とか無いから。

おんめぇのせぎ、ねぇがら

次のアップデートででかいの来るから今のは安定版だと思うよ

nal-hrdとか入るのかな？
まあコミットされれば分かる話なんだけどさ

今だけでもついて行けてないのに大きいアップデートかよ…がんばるんば

そうなると、とりあえずは、
1471にして暫く様子見って事になるかなぁ。

x264自体、すっとbetaみたいなもんだから・・・

TMPGEの内蔵エンコよりx264の方が綺麗と聞いたのですが、
内蔵エンコードを使わずにx264のエンコーダーをTMPGEで使うことってできますか？

っAviSynth

AviSynthだけでＣＭカットとか出来るの？

ビデオ編集ソフトウェアっていうんだから出来ると思う

Trim(a,b)+Trim(c,d)+Trim(e,f)

そのフレーム番号をVirtualdub辺りで調べていちいちメモ帳とかに書いとかなきゃいけない
という非人間的作業を強いられる。
何か安楽な方法は無いもんだろか。

AVIUｔｌでTrimエクスポートプラグインを使えば良いんじゃね?
x264guiがなかった頃は、AviSynth+MeGUIでそうやっていた。

>>729
AvsPを使えば楽。
http://www.avisynth.info/?AvsP

Virtualdubでカットして保存したvcfファイル使えばいいじゃん

大人しく無圧縮で中間ファイル出力汁

新AQ2なんか実写で使うとツルツルになる
アニメでは効いてるみたいだが・・・

>>724
http://forum.doom9.org/showthread.php?p=1378661#post1378661

4:4:4 ロスレスの次世代フォーマットはいつ頃リリースされそうですか？

プロがx264なんて使うのか？

4:4:4のソースが手に入らない俺はもちろん素人

げ・・・げーむとか、フィルムをスキャンしてデジタルに起こすときにも使える
ここで大半を占める気持ち悪いアニヲタは色にはこだわるんじゃないのか？

4:4:4の東方か…

贅沢なソースだ

4:4:4やRGBのソースを保存したいのなら、FFV1が圧縮率も高くて便利。

暗部をきれいに圧縮する方法がわからん

中途半端にQPを小さくするなら、高周波をけずりきったほうがいいのかな

トレリス量子化で高周波を無くさないように、やるとbitが増えるわりにきれいにならない・・・

やっぱ高周波を残すように量子化マトリックスを用意しておきたいね

う〜ん、量子化マトリックスを二種類を適応的につかいわけられたらいいのに

暗部のバンディングだったら、これを使えばデフォルトのCQM無し+VAQでグレインは保持できるので大丈夫。

http://www.avisynth.info/?GrainFactory3

>>745
GradFun2DBmod and Grainfactory3
は使ってます。

プリフィルターできれい（？）にした部分をきれいにエンコするのはむずい・・・

結局、量子化マトリックスを用意することで暗部の問題は解消・・・
bitrateが半端ないけどｗ

>>746
難しいとか言うんだったら、当然これくらいは読んでるんだよな？
http://forum.doom9.org/showthread.php?t=152904

ミスターグレイン

fgo使えば暗部は崩壊しないね。

ただ、ざわつきが気になる。

まーモニタ側をTV仕様にするのが楽かと

更新こないな〜

今週中には来るんじゃね？
現在パッチ20個

最近 aqmode 2 が改良されて良くなったんだっけ？
前はブロックノイズがでたりしたんだが。

どうせ使わないからどーでもいい

実写ソースをエンコする際のおすすめマトリクスありますか？
皆さんJVTでやっているのでしょうか？

個人的には素直にflat+VAQがいいと思った

>>754
--aqmode 2 --cqm flat

1471でflat + aqmode 2も試したけど、自分的には1の方が目で見た感じは良かった

じゃあそれでいいじゃん
結局人それぞれ

正直どう違うのか、比較して全くわからず、
とりあえず実装されるなら良いんだろうという事で、実写もそうでなくても、
--aq-mode2 --aq-strength 1.00 --cqm flat です。

原文には You must specify the custom matrix とあるが、絶対使った方が良い、といったところ。
選択肢は flat(16) か jvtの筈だが、前者は使わないのと一緒でBaselineおよび Main Profileまでの機器向け。
iPod, Apple TV, PSPなどが相当。jvtを使うとHigh Profileになる
CQMはカスタム量子化マトリクス（Custom Quantisation Matrix）。
量子化マトリクスは格子状にならんだ数字（＊数学で言う行列＊）で、個々の数字をquantum（＊量子/量子化マトリクスの値＊）として扱う。
この個々の数字が元の映像データをどのくらい破棄するかを決める。個々の数字が大きなマトリクスは映像がソフトになり、小さなマトリクスは映像のディテイル保持率があがる。
x264のデフォルトは "flat 16" マトリクスを使う。これは全ての数字が16で埋まっているもので、デコードの際に特別な扱いが不要なもの（＊Main Profile以下＊）。
カスタム量子化マトリクスはHigh Profileの機能で、実際にはデコード負荷は増えも減りもしないのだが、デコーダ側のサポートが必要となる。XviDのカスタム量子化マトリクスを覚えている人もあるだろう。
大半のケースでデフォルトのH.263量子化で充分だったが[*1]、x264でもflat 16で充分な場合が多いと思われる。しかし中には高周波領域に高い係数が入ったマトリクスを使いたい事があるかもしれない。
細かいディテイルがややスムースになり圧縮しやすくなる（＊ノイズなどの細かい部分を潰せる＊）。
cqmはデフォルトのflatマトリクスか、jvtマトリクスの選択。
flatマトリクスは数字が全て16で埋まっているもので、jvtマトリクスはH.264規格の技術的な作業に当ったJoint Video Teamが作ったもの。このコマンドは外部ファイルを用意する必要が無いので使い易い。


どこかのサイトからの抜粋
古い記事だけどね

ゴミ貼るな

意味を理解できてても、使い方が間違ってたら意味なしｗ

>>760
それはaqもpsy-rdも使わない場合だろ
いつの時代の話だよ

>>760
MeWikiとアゲハの翻訳の記述が混ざってるみたいだけど
とりあえず"You must specify the custom matrix"＝「絶対使った方が良い」はないと思う
これはオプションの解説なんだから
「このオプションでは何を指定しますか？」っていう暗黙の問に対して
「カスタムマトリックスを書きなさい」って言ってるだけの話でしょう

x264の開発陣としても、今はflatで十分て認識だと思う
触るなってほどじゃないにしてもcqm以前に触るべき項目がいっぱいあるから

今じゃjvtも合わなくなってしまったしflat一本だな

貼り。
>ttp://zoome.jp/VFR_maniac/diary/100/

JVTのが滑らか

JVTはグレインを潰してしまうので、アニメ向けと思っていたけど。
３桁のrevisionのころならともかく、今はflatのほうが良いよね。

アーティファクトの中でも、特にリンギングを気にする人には、高周波を削ってしまうCQMは不向きだわな。

なんかいろいろあるんだな…
1181でなるｐ氏のマトリクス使ってるんだけど、そろそろバージョンアップして
flatエンコに切り替えるべき？

>>770
とりあえず、最新版(r1471)で--tuneを試して見たら。

猫科研究所、死亡

404 Not Foundですか……

え、見えるけど・・・

猫科研究所　でぐぐれ。アドレス変わったっぽい。

ググっても出ないんだが

www.を付けたら見られた

ｗｗｗ

　　　　_, ._ 　
　　（　・∀・）
　　○=｛=｝〇,
　 　|:::::::::＼, ', ´
､､､､し ､､､((（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

どうも
放ってたんですが話題にあがったようなので一応お知らせします

なんかサーバに色々不具合が起こってるんですが
全体的に設定が初期化されている・狂っているぽく
中途半端に動作している状態のようです
こちらからはなんの手も打てない状況にあります…

土日はサーバ業者に誰もいないのか、メールしても反応がありません

まぁ大したサイトでもなく、動いてなくても困る人はいないと思いますが
とりあえず撤退等をしたわけではありませんです

>>780
動かないと困る人がここに一人いますのでとっとと直してください＞サーバ業者

サーバの運用管理なんて365日がデフォなのに、土日にいないとかどんな会社よ･･･
個人のサーバレベルだぞ。

安いとこなんじゃね

余はw64版MinGW猫研パックを所望じゃ

安いには確かに安いんですけど、元々はこんな状態じゃなかったんですよ
初めの会社から事業譲渡、事業譲渡、で2〜3回経営主体が変わってるんで
その間になんか色々変わってしまって…

「国内サーバ」が売りだったはずなのに、ある時大規模な障害があって
理由を聞いたら「海外のデータセンターが火災で丸ごと逝きました」とか返ってきたり
当初の条件とほぼ同じと言えるのは料金くらいで、もう別物って感じです

ハードの保守は24時間なんだろうけど
これ、OSレベルなんでしょ？

なら平日しか対応できないんじゃないの

>>784
お畏れながら某は当面32微度に留まる心持ちでおります故
殿のご意向に俄に沿うことは為り難く存じまする

32bitでさえ面倒なのに64bitは心底面倒ってのもあります、基本ものぐさなんで

>>786
いや、OSレベルでもやるところは普通にやってると思いますよ

以前だとサポートのメールは担当者の携帯に転送されてたみたいなんですが
今はもうそれもないのかもしれない…

スレチなんでそろそろ消えますね

レンタル鯖
http://pc11.2ch.net/hosting/

MinGWでやるx64のクロスクンパイルはこれを使えば簡単。
http://komisar.gin.by/mingw/index.html

正式リリースが滞ってるなりぃ

最近一斉コミット多いよな
前はリビジョンが10飛ぶことなんか無かったのに、
今度は1500になりそうな勢いだ

昨年末ぐらいから結構ため込んでリリースってパターンが多くなった気がする

わかっているだけでも20個も溜まっている
どうもNAL-HRDのcommitを記念してx264でエンコしたBDのisoを配布するので
それが出来上がるまではお預けらしい

面倒くさくなっただけだろう。

>>793
捕まらなきゃいいけど

そのりくつはおかしい

[02:19:53] <Dark_Shikari> so apparently I just got an email from google
[02:20:04] <Dark_Shikari> all-but-begging me to apply to work for them this summer
[02:20:50] <kierank> enjoy working on vp8
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/2010-March/000043.html

猫科研究所ふっかつ

>>797
「そういや、さっきgoogleからメールが来たよ」
「今年の夏休みはぜひうちでバイトしてくれ、だってさ」
「vp8を楽しんできなよ」
とりあえず買ってはみたが、あまりにもクソ過ぎて使えないので泣きつかれたか

VP8ってH.264に対して何か利点があるの？
爆死するの見え見えなんだがｗ

On2では、H.264もやっているから、そっちじゃないの。
http://www.on2.com/index.php?474

MKV形式などあらゆるムービーファイルをPS3で再生できる形式に変換するフリーソフト「DivX Plus Player」の新機能「DivX To Go」
http://gigazine.net/index.php?/news/comments/20100316_divx_plus_player/

H.264の特許ゴロどもをぷぎゃ出来るだけで十分利点だ

>>802
画質の良いx264+mkvmergeで、DivX Plus HD互換ファイルを作った方が良い。
http://developer.divx.com/docs/divx_plus_hd/Creation_with_x264/

>>802
DirectShowを読み込みに使ってくれないので可逆が使えない・・・・
無圧縮は読んでくれるけど
無圧縮にしたら読み込みに時間が掛かりすぎて大変

DivXがそう言ったのかは知らないけど"あらゆる"ならDirectShow使えるようにしておこうよ

>>804
放り込むだけで変換できるからライトユーザ向けでしょ

>>806
x264はライトユーザー向けじゃないからスレ違いでしょ

x264のほうが既に読み込める形式が多い

x264とは違って、GPLのFFMSをDivXに組み込むと言う訳にはいかないだろうしな。

r1500 release! Amazing speed!

流れが速くてついていけてない。
1179で止まってるけど、高速化以外で何か面白いオプションとか追加された？

何も無い

古いというのは別にしても1179は・・・

http://hdimage.org/images/0sweno1ujssatdg6oh3.png
http://hdimage.org/images/vutia3kss7p6r074lqaj.png
http://hdimage.org/images/544252gs4tc9679nfqn.png

http://www.mediafire.com/?nz40l4jznyn (ビデオ)
ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/1080p/pedestrian_area.yuv (ソース)

やはりx264を無料で使えるのに、¥1,980を払ってまで欲しいと言う物ではない。

GIGAZINEで無料でシリアル配布してたけどこれはないな
細部潰れすぎだろ

動画で見るとそれほどでもない

キメェｗ

>>811
1179だとmb-treeがまだ入ってなかった気がする。

>>814
エンコ時間は？

>>814
そりゃこまけぇこたぁいいんだよな人向けなんだからそんなもんだろ

>>819
今は期限切れのCLIで-aqo 2をやっていた頃だったら、私の設定で使うx264の方が速かったと言えるのだけれど、
Converterは面倒なので計測する気にならない。

今なら無料のシリアルも取得できるだろうし、他の人に任せる。

ここの住人はそんなの不要でしょ
所詮、初心者向けの簡単ツール

>>814
x264は細かい崩れが多いな
これは、Divxの勝ちだな

DivXの方が奥のぼやけた輪郭の鼻とか潰れまくってるじゃねーか

x264も顔面岩石になっているし似たようなもんだなｗ
というか潰れている方が動画としてはみやすい

潰れてるほうが見やすいとか、あんたの好みなんてどうでもいい
ソースをより忠実に再現できてるのは確実にx264
この比較画像が本物ならDivXは詐欺レベル

ソースをより忠実に再現できてるのは確実にx264という妄想もどうでもいいな
どうみても、ゴミが多すぎる、ノイズと言っても良いx264

何言っても無駄っぽいけど、右奥の47ってプレートの壁とか見ても
x264の再現性が妄想だというならもういいわ
DivXは強烈なNRかけたみたいになってるようにしか見えないが

x264は無理に高周波残していて、それがモスキートノイズに変貌しているからオワタｗ

キチガイ登場！

DivXのブロックノイズの酷さが目立つな。細部もつぶしまくり。
白黒横縞の女性の服とか、奥の壁の模様とか、ぼろぼろだね。

これじゃ100人中100人、x264選ぶだろ。

x264の設定も詰められないようなバカにはDivXがお似合いだ

>>831
100人中99人じゃね
ID:bOS3KieaはDivXがお好きのようで

DivX製H.264はどういうわけかパラメータの細かい指定出来ない仕様だからx264に勝つのは無理

>>832
AviUtlスレでもそんなようなレスがあったわ

978 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2010/03/17(水) 10:15:35 ID:ogwpsyZW0
アホはDivX Plus Proでも使ってなさい
ttp://gigazine.net/index.php?/news/comments/20100317_divx_plus_serial_free/

確かにDivXは細部潰れまくりだけど動画として見たときには全く気にならないんだよな。
簡単だし綺麗だし細かいこと気にしない人にはオススメ。
速度はx264のFasterよりやや速いって感じかな

DivX（ﾟ�听）ｲﾗﾈ

そのうち無料且つ手軽さをうりにしてエロ方面ばっかになってとろい認定
あれそれなんて real

リアルワールド！

細部潰したいんだったら、--tune ssimでも使えばいいだけじゃねえか
DivXより数倍マシな潰れ具合にしてくれるだろうよ

aqかけまくれば消えるよ

x264批判してる人は、psy-rdを批判しているだけだったりする。
x264のpsy-rdを抑えたら、DivXより全てにおいて勝るはず。　速度は知らんがｗ

seraphyのおまけに、x264OreAQ.XXXX.releaseXX.rarとx264patch.XXXX.releaseXX.rarがあるんだけど、これらの違いって何?

さんを付けろよデコ助野郎。

大手メーカー製のエンコと違って
CPUに頼るしかないのがつらい。
画質は落としたくないし。

ハードウェアのエンコーダチップって速度重視で画質はあんま良くないよ。
プロがBDオーサリングで利用するようなエンコーダーはおしなべてソフトウェアだし。
でもそういうのはPC何台もクラスタ接続してリアルタイム以上の速度でエンコ可能みたいだけど。
まあ、とはいえx264で同等の速度でエンコさせるよりかは専用チップのほうが画質はいいか

>>845はGPGPUのこと言ってるんじゃない？

正 seraphy氏
誤 seaphy

>>847
大げさに言えばこういうのとか。
http://www.thomson-canopus.jp/catalog/ewgs/edius_xre_index.php
大げさ過ぎるかもｗ

>>849
残念ながら編集、特に特殊効果をリアルタイムレンダリングするためのシステムだよそれ
エンコードをハードウェアでやるにはFIRECODER Bluがいる
で、FIRECODER Bluの正体は・・・

http://www.thomson-canopus.jp/catalog/firecoder_blu/firecoder_blu_index.php

ちなみに現状GPGPUはもっとひどいから
＞プロがBDオーサリングで利用するようなエンコーダーはおしなべてソフトウェア
DVD時代からずっとそうだけどね

http://www.cinemacraft.com/ja/cchde.html

価格は934万5,000円だとさ・・・・・

GPGPUなんて開発進める気なさげじゃん

http://hdimage.org/images/rj9jb9dsedq18nc6nqf.png
http://hdimage.org/images/lwnlcn7cj1voxfg5wyyb.png
http://hdimage.org/images/j4i10n8l2kdr68d2xzcp.png

http://www.mediafire.com/?y4glwnydgmy (ビデオ)
http://mirror05.x264.nl/Dark/LosslessTouhou.mkv (ソース)

DivXに合わせて、--keyintは120(2秒分)にしてある。
DivX 7 CLIでは、4秒分と言うことになっていたが、さらに短くなった様だ。

結局、>>843はスルー?

>>855
Readmeを読んで理解が出来ないのなら、
使う意味は全く無いから、気にするな。
もうRev300近くも前の奴だし。

>>854
どっちもビットレート足りてない気がする

>>851
時々気になるけどx264はこういうプロ用途のエンコーダーと比べてどの程度の
レベルにあるんだろうか。

>>858
PHLのエンコーダーには絶対に勝てないと思う。

同一時間では負けても、時間掛ければ同等以上にならないの？

あと容量も気にしないなら、-I 1 --qpmax 0 -m 10 -t 2とすれば画質で負けたりはしないと思うｗ

容量も気にしないっておかしいだろｗ

>>860
おいおいPHLのエンコーダは現時点でBDマスター作成で最強なんだぞ
弄れるパラメータが死ぬほどあってPHLのエンコキチガイが
シーン毎にパラメータ変えてるってのに勝てるわけないだろｗ

>>858
あっちはエンコーダーうんぬんより、1フレームごとに
目視で確認してI/P/Bフレームを決めたりする
マンパワーが結構大きいと思う

ごめん、ちょっと被ったね

確かにプロ向けのはパラメータを決定するためのプレビュー機能とか
そっちの方が重要かもしれんねえ。フリーの環境だけじゃセグメントエンコードすら面倒だしな

左上あたりにフレームの種類を表示してくれるプレイヤーとかない？

すまん自己解決

>>857
こう言う比較は、難しいソースを使って、劣化の目立つビットレートでやらないと面白くないからね。

>>854
x264はノイズが多い
と言う事で、NRをかけるとおそらくdivxみたいな絵になる

上のほうでハードウェアエンコーダーには画質には負けないと断言しているが
ソニレコの10倍録画の方がx264よりも全然良いわｗ

DR
http://ascii.jp/elem/000/000/499/499689/010_R_c_800x450.jpg
10倍
http://ascii.jp/elem/000/000/499/499690/011_R_c_800x450.jpg

DR
http://ascii.jp/elem/000/000/499/499691/012_R_c_800x450.jpg
10倍
http://ascii.jp/elem/000/000/499/499692/013_R_c_800x450.jpg

DR
http://ascii.jp/elem/000/000/499/499693/014_R_c_800x450.jpg
10倍
http://ascii.jp/elem/000/000/499/499694/015_R_c_800x451.jpg

>>870
x264との比較画像貼ってから言えよwww

1080pの4Mbpsでx264はあの様
もう結果は見えている

>>871
メクラなアンチはスルーするのが良いよ

そうそう、反論できないなら黙っておくのが賢明

ソニレコwww

また変なのが来たのか

ソニーレコはリザイズしてなかったっけ？
パナはそのままの解像度だけど。

Xperia 1280x720の動画作成出来るみたいだけど
ちゃんとBフレやCABACも使える？

>>870
ビットレートがわからんが劣化と位置ズレひどす
道路右下のブロックノイズ見た感じ、アニメの暗部は酷いことになりそう

解像度ちっさぁ・・・

NGID:qBipIHSG

ttp://x264.nl/
またなんかおかしくね？

おかしいのは俺の頭

いやいや俺だろ

http://wiki.videolan.org/SoC_x264_2010
今年のSoCのお題発表

r1510まで流れてきてるな。
落ち着いたらコンパイルするか。

>>886
本家のgitはしばらく前から止まってるけど
どこで公開してるの

>>870
これ10倍と言う事は、1.5Mbps以下のビットレートだよな
さすがソニー、x264orz

おいお前ら>>870がお手本だ
これレベルでできるようにさっさとスキル上げろ雑魚どもｗ

まあ、10年かかっても無理だろうがなwwwwwwwww

NG　ID:LDLdl279

そうそう、反論できないなら黙っておくのが賢明

NGしている奴にレスするって・・・

x264で自己満足オナニーしたいけど、何も知らない素人のボタン一つの操作にも
負けてしまう現実wwwwwwwwwwwwwwww

何がやりたいのお前ら？
wwwwwwwwwwwww

久しぶりに、ほほえましい感じのが出てきたな

http://www.phileweb.com/review/article/201003/19/112.html

どんでもないテレビが目の前に・・・

目の前ってどういう事?

3D的な何か

>>897
それがこのスレとどういう関係があるの?

AVCの拡張規格であるMPEG-4 MVC的な何か

関係ないって事かｗ

ば・・ばかおめぇｗ

MPEG-4 MVCにx264が対応するだろ確実に

>>900
ID:LDLdl279と同レベルだ

なんだ、この流れ??
再生機器がどのくらい普及するのか、元素材がどのくらい出回るのか

春休みでやることがなくなったクズが来てるんだろ

ちと、タイミングが悪かったな
神経過敏になっている所で登場してしまったわ

パナソニック等が、DSに3D環境や素材をまとめて提供するくらいじゃないと、
今の段階ではどうしようもないだろうな。

DSよりPSPが3Dになった方がいい

DSはDark_Shikariのことだろｗ
任天堂じゃねえよｗ

前から気になってたんだけど・・・
時々エンコすると1時間当たり2、3フレームほど重複が出て、ソースより長くなるのは
どうしたもんでしょorz
そういうソースは、パラメタ変えてエンコし直してもフレーム重複は直らないみたい。
仕方ないので、音ズレ気になる時は重複時点前後で音声を伸ばして対応してます。
コレって既出ですか？

>>909
--tune zerolatency
これでも同じ現象が起きるんだったらフィルタの問題だからスレチね

>>910
そのプリセット、ストリーミング用？と思ってた。
どれも使いたくないオプションだ＿|￣|○　たしかにBフレ0はやってみたこと無かった。
皆さんは全然再現しない？それとも気にしてない？

私はx264.nlのビルドでr1471まで各リビジョン使ってみたんだけど、どれでも起こる・・・
原因切り分けに可逆圧縮のavi使ってるから、AviUtlやAviSynthのフィルタに起因
するものじゃありません。純粋にx264 cliをコマンドラインから走らせてるのみ。

DirectShowSource使ってるとかいうオチはないよな

>>911
Bフレ0ってそんなに悪なのか？

Bフレ使おうが使うまいがビット当たり品質大差ないと思うんだが

ネットでx264関連をググルと、ほぼ9割と言って良いぐらい確実に
そのブログはアニヲタで軽く吐きそうになるんですが、どうすればいいのですか？

吐けばすっきりするよ

>>915
�d

アホはググるのやめてDivX Plus Proでも使ってなさい

>>870
�d

大差ないならBフレなんて実装する意味無いだろ・・・。
ちょっとは頭使えよ。

>>870
http://ascii.jp/elem/000/000/499/499715/index-2.html
＞転送レートはおよそ2.4Mbps
http://www.sony.jp/bd/products/BDZ-RX105/feature_5.html
＞高画質機能

これならx264のソースでもPS3とかで再生すれば同等じゃね？

>>914
実写をやっている人が大半のDoom9を参考にしたらいい。

x264の、encoder/analyse.cの中の関数4・5コを
int i;
for(i = 0; i < hoge; i++)　…
を
for(int i = 0; i < hoge; i++) …
に。

呼ばれた関数の中で、値が偏向されない変数は、constキーワード付けたら
1440x960で、0.5fps程度、速度向上した。

restrictとか付けたら、もっと改善出来そう。

音声がズレるのが嫌いならBフレ0がデフォだな

>>909
MP4スプリッタの不具合じゃないの。Matroska等、他のコンテナを試してみたら。

>922
コンパイラは？

>>925
gcc-4.3.*

constキーワードは、数値が変わらない事を明示したり
restrictはポインタが指す領域が被らないことを保証したりするキーワードだから、
コンパイラに限定されずに、最適化というか構文解析に大きく関わってくるね。

ループカウンタの宣言の場所は、
ループ展開するコンパイラなら、そもそも使用しないからね。

こういうちょっとした事で、コンパイラによっては自動ベクトル化されたりするし。
というか…　なんで誰もやらないんだろ。

>>920
その2.4Mbpsって音声、データ放送、EPGほかも含むだろ

データ放送だけでも2Mbps近く使うんですが

http://www.geocities.jp/ultra_violet_laser/rate.html
地デジの伝送レートは16.85Mbps
映像だけなら13.6Mbps程度

>>912
>>924
今こんなカンジでテスト中・・・

R:\>type con > input.avs
AVISource("input.avi")
ConvertToYV12()
return last
^Z

R:\>x264 --output output.h264 input.avs
avs [info]: 856x480p 0:0 @ 30000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1

- 中略 -

R:\>MP4Box -fps 29.970030 -add output.h264:par=1:1 -add output.m4a -new output.mp4
AVC-H264 import - frame size 856 x 480 at 29.970 FPS
Import results: 1801 samples - Slices: 8 I 1793 P 0 B - 1 SEI - 8 IDR
IsoMedia import - track ID 1 - Audio (SR 48000 - 2 channels)
Saving output.mp4: 0.500 secs Interleaving

R:\>

AviSynth、MP4Boxは最新のにしてるんですが、x264が吐く.264が既にオカシイと考えてます。
多分、重複フレームが出る前の入力画像になんらかのバグ起こすものがあると思うんだけど・・・
えと入力は実写(ドラマ、コンサートライブ、スポーツ関連etc...)で起こるコトがあります。
アニメは使ったこと無いので不明。やっぱアニメしかエンコしない人には遭遇しない障害なのかな？

>>926
x264の開発者達は、C++を毛嫌いしているからだよ。

地デジの伝送レートと録画の転送レートの違いも分からないとはなｗ

>>930
wowowのエンコとか頻繁にやるけど遭遇した事が無い
memtest86+で24時間ぶん回しとかやった？
doom9でもそんな報告見たことが無いからPC環境疑った方がいいよ

>>930
ビデオ: avsをx264で.264で出力
オーディオ: ts2aacで取り出したAAC
多重化: mkvmerge

私は、放送をこうやっているけど、今まで音ずれは起きたことがない。
私もアニメはやらないけど、実写云々は関係ないんじゃないの。

restrictやループ変数のスコープは一応C99だけど:)

>926
構文解析じゃなく、コンパイラの最適化にヒント与えるから
意味あるのでは？
どちらにしろ、コンパイラの種類やオプションで結果変わるから
積極的に誰もやらないんだろうね

>>933
そう、拙い英語で検索してもdoom9では話題にないみたいでしたね・・・
長時間負荷は昔このマシンでスーパーπ半日走らせたことがある位でしょうか。
Q6600を定格で回してるんですが、今までAviUtl(DivXやx264VFW)やTMPGEncで
長時間連続エンコしても全くフレーム数が変わるってコトなかったのにorz

出来たモノをいつも真空波動研で確認するので、x264の吐くものがオカシイと気づいた
んですが、今回テレビドラマ(24-TWENTY FOUR-)を連続7話エンコしたら全部
フレーム数が増えててガッカリしてる次第。

>>934
いまmkvコンテナに入れてみたんですが(当然ながら)フレーム数は増えたままでした。

やっぱり私の環境に起因するものかな＿|￣|○

>>936
AVISource("input.avi")

x264とは関係なく、この段階で既におかしんじゃないの。
MPEG2Source("input.d2v")として、最初からAviSynthでやってみたら。

>>937
おかしい、ってドコがでしょう？AVISourceは地雷か何かなんでしょうか？
ちなみに再現するソースは最初MPEG-2 PSで

DGDecode_MPEG2Source("input.d2v")

ってしてて、今回原因見る為にUt Video ULY0でエンコし直したものを入力にして
AVISourceで読み込ませ直してみて、やっぱりフレーム重複が出てる次第。
なので映像自体にトリガーがあるのかな？と。

AVISourceやMPEG2Sourceがフレーム重複の原因だとは思わない。
私はそれを録画したことはないけれど、元々そういう放送だったんじゃないだろうか。

いずれにせよ、私の環境では、avsよりもx264で出力したビデオのフレーム数の方が多くなった事はない。

残念ながら長時間のソースをエンコしてもそういった重複フレームが湧いてくるなんて状況に
遭遇した事ないからなぁ。俺もそういう話は聞いたことないしそうなるとキミの環境を疑わざるを得ない。
x264のログでencoded xxxx framesってでるけどその時点で増えてんの？
あとはx264のビルド変えてみるとか別の人のやつ使うとかx264.auoの方とかはどうなの？
x264.auoはエンコーダーそのものはcliと全く同じだからこちらで問題が出ないならAvisynthの方に
問題があるとかいう可能性もある。新しいx264はaviとかそのままぶち込めるからavs使わずにエンコしてみるとか

> x264のログでencoded xxxx framesってでるけどその時点で増えてんの？
yes＿|￣|○

> あとはx264のビルド変えてみるとか別の人のやつ使うとかx264.auoの方とかはどうなの？
x264.nlの他にSeraphy氏のとかだれだかワカラン人ｗのとか。全部x86 32bitのヤツです。
自分でもビルドしてみよかとトライしてみたんですが、MSYS+MinGW揃えるトコで断念中。

> Avisynthの方に問題があるとかいう可能性もある。
と思ったので、すっぱりアンインストールして2.58をダウソし直しインストしました。
外部フィルタは一切入れてません。・・・でも再現してるorz
確認はTEを2つ起動し、ソースとエンコ後mp4を開いて交互に見比べるという頭の悪い方法で。

・重複フレームの前の何GOP分からにソースを縮めると再現しない。最小で10分の長さの
後に発生する模様。
・今Bフレ0でやってみたら(予想してたんだが)重複は起きなかった。オプションの組み合わせに
よるのかも知れないけど、Bフレ周りかも。

> 新しいx264はaviとかそのままぶち込めるからavs使わずにエンコしてみると
ええ、今やってみてますがダメぽいなぁ・・・

ttp://apple.mokuren.ne.jp/loader_1/src/apple0191.zip.html

Core2Quadのマシンでエンコするとなんとも無いんだけど、Athlon64 939でエンコ
したときに、この動画の冒頭のようなモワッっとしたノイズが入ることが時たまあるんですが
何か心当たりありませんか？939のマシンもメモリチェックはエラーフリーです。
@r1046 MixAQ(VFR maniac版)

AMDでの使用は検証されてない

http://zasshi.news.yahoo.co.jp/article?a=20100201-00000003-trendy-sci

>パナソニックはBD-ROMの3Dフォーマット策定の中心的存在で、幹部は「3D規格と3D BD規格の95％はうちが作ったんだ」と豪語しています。

事実かもしれないけど、こういうの自慢げにメーカーに語られるとイラっとするのは俺だけ？

別に良いんじゃない？16：9ブラウン管並にはやらないと思うが。

3Ｄは欧米人が騒いでいるだけだモンな
日本は、アバター以外テレビ・雑誌のメディアで取り上げられているぐらいでそんなに祭りってほどでもないしなｗ

バーチャルボーイもAHDも全然駄目だったしな
日本人は兎角ウザイのものが嫌いだ

3D-VHDというのもあったなそういや
あれは液晶シャッター方式の3Dだったよな確か

テキトーにrestrict付けてコンパイルしたら、1割早くなった。

気になったところ多々あるし、変数やループを最適化すれば…
制御構文まで手を入れれば、2/3切れるかも。

あー、目が痛い。

バーチャルボーイってGameBoyに赤色単色のヘッドディスプレイくっつけたゲーム機あったなｗ

>>950
ブランチ作ってコミットしてみては？

暫定ビルド版
http://uproda.2ch-library.com/lib227255.zip.shtml

>>952
そうしたいけど、整形ツールでインデントJavaスタイルにして
部分的にコメントも削除してたりするから、ぬっ殺される。

もとのソースも、2週間くらい前のdiary tarballだし。

ソースくれくれ。できればdiffも。
それと__attribute__((regparam(n)))使うと早くなったりするかも。

>>953
乙です。

(i7用)patched x264 builds for 32bit Windows と (Core2以降用)x264 filter
http://cid-614aa8f1c8307528.spaces.live.com/
↑と比べたのですが↑の方がエンコ速度が早かったです。

(Core2以降用)x264 filter←これ・・・結構面白い

私の環境
Win7 32b
i7(965EX)
DDR3-1600(2G*3)

つ　http://uproda11.2ch-library.com/11232616.zip.shtml

みんなで、ソース弄って、コミットしてみたいね。

ttp://repo.or.cz/regproj.cgi?fork=x264.git
でフォークを作るのも簡単そうだし、
日本からのgit repoについては一応、
ある程度期待してまっする

こういう風に公開すると、#x264でも貼るのが簡単になるし^^;
レビジョンの間の変化やらdiff作成も簡単になる。

anopeの和訳をしてた頃、一応初心者向けにGitの使い方とかを説明する
文がWikiで作られた。Gitについて分からない人にはおすすめ
ttp://wiki.github.com/jeeb/anope-tl-jp/
(日本語での説明へのリンクも付いてるし)
git repoを提供してるサービスが違っても、git自体は変わらないからねぇ
移動も一つのサービスから違うサービスへのも簡単。

あと、簡単に入れられるmsys/mingwな、git付きの環境といえば、やっぱり
ttp://www.cccp-project.net/wiki/index.php?title=Installing_MSYS-MinGW
のNicholi氏の7zアーカイブですよね（etc/fstabでフォルダの場所を指定するだけ）

速度にこだわるならICCでのコンパイル目指した方がいいんじゃないか？

>>958
まぁ、それもそうだけど、実際に高速化が出来たらそれもいいことだし。
正しく作れば、どっちのコンパイラでも速くなるからねぇ。

実際に貼られたパッチは試してないので、何とも言えないけどねｗ

よくプログラム初心者が行う、どっかからソース持ってきて
改造して、喜んでいるいるようだな

俺も初めての頃はそんな感じだった

そうやって経験値稼ぐ

小手先の改良に意味はないってどっかのえらい人が言ってた。
敢えてそれをやるなら複数のコンパイラで比較しないと意味ないよ。
みんながみんなgcc使ってる訳じゃないし。

今時最適化なんてコンパイラの仕事だよな

cflag弄ってるだけの愚者共より良いと思うけどな。
関数化一つ、inline一つの小手先で結構かわるんだし。

>>962
でも、こういうひたすら同じことを繰り返す類のプログラムの場合は、その小手先の改良が結構バカにならないんだよw

だったらgcc以外でもコンパイルして自説を証明してみなよ。
コンパイラ依存の最適化に何の意味があるの？

そもそもこういうオープンソースのプロジェクト物でgcc以外のコンパイラ使ってコンパイルするように
ソースって書かれてるの？

cygwin1.dllが必要というのもどうなんだか

最適化は、普通に歓迎されるんじゃないの。
http://wiki.videolan.org/SoC_x264_2010#Optimization_.28x86_and.2For_ARM.29

>>965
既に>>955で速くないって言われてるんだけどねｗ

>>941
見てみたらうちでも４フレーム増えてた(r1471)
けど、シーンの変わり目ではズレなし
最後の４フレームが余分って感じだった

http://www.marumo.ne.jp/db2005_8.htm#18
これでも読んでまずはまともなバグレポートできるようになってから書き込め

なんでgccが使われるかとかそういう元々の事が解ってないだろうなw
市販されてるコンパイラに比べて最適化は不利なgcc、実際アーキテクチャ決め打ちの様々なコンパイラより
テストするとgccが最も最適化がイマイチで遅くなったり。

でもなんでメインでgcc使ってるか？皆にはそういう大事な事はわからんだろw

良くも悪くも無料で手に入るから。
そもそもconstやrestrict修飾子が、gcc依存の最適化だという誤解をしている人までいるしな。
ベクトル型プロセッサを積んだマシンのC/C++コンパイラや、Intel C++ Compilerでも早くなるんよ。
>>956がしている手法は、そういう環境非依存・コンパイラ非依存の最適化。
逆に#pragma vector alignedや、__attribute__ ((aligned (alignment)))は、コンパイラ依存。
asmに落としたら、環境依存の最適化。

実際に
int i = 0;
　：
for( i = init; i<limit; i++){・・・・・}
　：
for( i = 0; i<limit2; i++){・・・・・}
のコードと
for( int i = init; i<limit; i++){・・・・・}
for( int i = 0; i<limit2; i++){・・・・・}
のコードでは、下の方が最適化される。

gccは、二桁目のバージョンで最適化の効きが大きく変わる。
それに日進月歩のx264で比べるなら、双方の環境とソースを揃えた上で、比べないと意味ない。

未だにフレーム重複検証ちう・・・　もー訳ワカメorz

そいや昔プログラマやってた頃はccにコッソリ -O3 とコンパイル後にstrip付けてたなぁ。
「コードの1割が処理時間の9割を占める」の法則で、現在最適化中じゃないの？
MLはおろかソースもちゃんと読んだことないけど。
ディスクI/O多そうだからthread・semaphoreで多重化するのは効果薄そだね・・・

>>974

そうか
for( int i = init; i<limit; i++){・・・・・}
ってC99で取り込まれたのね。
なんか浦島だわ。

>974
constやrestrictはコンパイラにとっては最適化の情報与えるだけ。
修飾子付けなくても最適化しちゃうんだし、付けてより最適化されるかどうかは
コンパイラ依存だってことをみんな言ってるんだよ

forループで、カウンタ変数のスコープを狭めることもコンパイラにとって
影響範囲が狭くなることで最適化しやすいだけだし、ループスコープ外で
変数i使うことなければ、iccは最適化しちゃうよ
gccはそんなんで早くなるなら、それこそgcc依存の最適化じゃん

x264では、gccの最適化がヘボイとか、gccのバグに対応するだとかいう名目だけのコミットが、かなりあるんだけどな。

>>974
gccでC89よりC99を使った方が速くなると言うから、
そんなことよりiccを使った方が簡単に速くなるという話

商用コンパイラの性能を知らなさすぎ

皆が皆ICC持ってるわけじゃないしGCC使う人の方が圧倒的多数だろ
GCCで最適化しやすいコードならICCでも速くなる可能性は高い

何が気に入らないんだ？

>>980
圧倒的多数は他人のコンパイルした物を使う人で、iccでコンパイルした物が速いならそっち使うだろ。

icc 11.1.060で試してみたが、restrict修飾子有効だよ。
画像処理でもベンチでも、コンパイラの最適化を意識したソースで
#define restrict
#define __restrict
#define const
して試してみなよ。

iccを盲信しすぎじゃない？

>>979
逆だよ、逆。一般的なソースでは、c89の方が速度出る。
ただC99では、単精度浮動小数点の関数が実装されているので早いだけ。

>>981
　 　 　 ｨ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ﾞt,
　　 　 彡;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ヽ
　　 　 ｲ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;r''ｿ~ヾ:;;;;;;ﾞi,
　　 　 t;;;;;;;ﾘ~｀ﾞヾ､;;;;;;;;;;;;;;;;;;;;ノ　　　　i,;;;;;;!
　　 　 ﾞi,;;;;t　　　　ヾ-‐''"~´_,,.ィ"ﾞ　　ヾ;;f^!　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　 　　ﾄ.;;;;;》　　＝ニｰ-彡ﾆ''"~´,,...,,.　 ﾚ')l.　＜　おまえは何を言っているんだ
　　 　　tﾞヾ;l　　 __,, .. ,,_　　　,.ﾃ:ro=r''"ﾞ !.f'l. 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　 　 ヽ.ヽ　ｰ=rtσﾌ= ;　 ('"^'=''′　 ﾘﾉ 　
　 　 ,,.. -‐ゝ.>、　｀ﾞﾞﾞﾞ´　,'　　ヽ　　　. : :! /
　~´ : : : : : ｀ヽ:.　　　 ,rf :. .　:.: j ､　. : : ト､.、
　: : : : : : : : : : ヽ、　 /. .ﾞｰ:､_,.r'ﾞ: :ヽ. : :/　ヽ＼、　
　 :f: r: : : : : : : : !丶　 r-､=一=''ﾁ^　 ,/　　 !:: : :｀丶､_
　 : /: : : : : : : : :!　ヽ、　 ﾞ ''' ''¨´　 ／　　 ,i: : : l!: : : : :｀ヽ､
　〃: :j: : : : : : : ﾞi　　 ｀ヽ､..,,__,, :ィ"::　　　,ﾉ:: : : : : : : : : : : :＼
　ﾉ: : : : : : : : : : :丶　　　: : ::::::::: : : :　　 /: : : : : : : : : : : : : : : :＼

まあここまで>>953で上げられてるバイナリが速いっていうレスが1個も無いんだけどさｗ

環境によって何が速いか変わってくるだろうしな･･･

>>957でOK貰ったんだし、喧嘩してないでドンドン投稿すればいいんじゃ？

で、各コンパイラで試してみて、平均どの位の性能向上かという
定量的なデータ提示はまだなのか。

すげー、外に出て行かない2ちゃんねらみな△

ねらみな△ ってどういう意味？若者の流行？

>>988
そりゃ、外に未だに雪が積もってて、ドアが開けないからねぇ…
といいつつ、たまに大学まで頑張って、そこで寝込んでるオイラがいる。

>>986
パッチするはいいこと、もちろん無意味なものだったら、D_S氏に無視されるか
バカにされるけど、なぜそうなるかと理解さえすれば、よりいいコードになるし。

>>984
別にこの人が何か特別なことをしたとは言わない。ただ、高速化が出来たと
思ったら自分のソースを簡単にいじれるようにしたら、他の分かる人から
コメントも入りやすくなる。それだけのこと。

次スレ立ててくる

ねらみな∴
ってこと

昨日のgitから取ってきたソース。

encorder/me.cのstatic void refine_subpel()内で
int omx, omyが二重に宣言されてる。

x264 rev27
http://pc11.2ch.net/test/read.cgi/avi/1269245115/

>>994
乙　

>>993
3月5日と、今取ってきたソースでは問題ないよ。

もしかしてhttp://git.videolan.org/?p=x264.git;a=summary
これって自動更新されないの！？
ずっとされるものだと思って更新無いのかと思ってた

更新されるよ。実際更新がない。

>>997
ペンギン様がメガパッチをチェック中でござる。

HEADまで更新は未だに届いてない。

大きな更新になると、色々チェックしてからHEADに入れないと厄介なことになるので、
IRCなどの方でテスト用に今のローカルな更新のDiffを貼ってる

1000

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