x264 rev25

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/

無意味な通報乙

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。