x264 rev31

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

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

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


[本家]
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 (公式フォーラム)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

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

前スレ
x264 rev30
http://hibari.2ch.net/test/read.cgi/avi/1296313162/

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

AviSynthの使い方等は
Avisynthを絶讃ιょぅょ Part30
http://hibari.2ch.net/test/read.cgi/avi/1298742587/

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

リサイズやアス比の話題は
アスペクト比 part6
http://hibari.2ch.net/test/read.cgi/avi/1301521076/

MP4コンテナの話題は
【MP4】ISOMPEG-4普及委員会4【M4A】【3GP】
http://hibari.2ch.net/test/read.cgi/avi/1087545021/

Matroskaの話題は
【mkv】MatroskaVideo総合スレ8【mka】
http://hibari.2ch.net/test/read.cgi/avi/1237123715/

PS3の話題は
【H.264】 PS3動画スレッド8 【1080p】
http://hibari.2ch.net/test/read.cgi/avi/1263892716/

おお…　生tsが一番高画質と思ってるのがいるのか

おお…　生tsが一番高画質と思ってるのがいるのか

--sar の問題いつになったら解決するのでしょうか。

Haaliに言えよ、x264の問題じゃねーんだから

生ts荒らしやめろ

前スレ>>995
「b-pyramid　DXVA」で検索かけると不具合が出てるから使うなって内容がわんさか出てくるな。

Bフレの参照の順番が正しくない感じで動きのある部分だけ描画が乱れるのだよね？そういうのなら俺もでたことはあるが。
ちなみにWin 7+HD 5870

>>6
えー。r1913だと--sar 4:3 受け付けないよ

おぉ… 生tｱﾊﾞﾀﾁｮﾙﾌﾞﾀﾞﾐﾍﾞ

>>9
釣りなのか本気なのかよくわからんが
いつになったら直るのとか言っときながらなんでr1924じゃなくてr1913の話を持ち出してんの？
だいたい「受け付けない」の意味がわからん
不具合を指摘するならキチンと日本語使え

頭が可哀想な子は放っておいてあげるのが優しさってもんだ

おお…　生放送が一番高タモリと思ってるのがいるのか

笑っていいニダ

友達はいないんで紹介できませんが、何か？

そもそも紹介もされないだろ

おお…　生tsが一番高画質と思ってるのがいるのか

そろそろ、このｔｓ荒らしは運営に荒らし報告だな

とりあえずなんたらの術で忍法帖やっちゃえば良いんじゃないの
俺は●持ってないから出来ないけど

水遁の術ね

焼いてもすぐ忍術Lv1にできるし、120秒間隔で投稿できるからこのスレに限って言えば無意味かな。
やってる奴がよその板やスレでも連投制限喰らう意味はあるけど。

すいとんされてレベルリセットされても2分間隔でレスできるからな
ここの流れの速さだとあまり変わらん気がする

>>11
本気本気。
r1913が今一番新しいのかと思ってたですよ。

--sar 4:3を受け付けないって言い方はおかしったね。
「反映されない」といみですよん。

r1924で--sar 4:3が反映されるならあまりに俺が無知だったすまん。

そして親切に教えてくれてありがとう。

今r1924でエンコードしてみたけど確かに--sar 4:3反映されますね。

お恥ずかしい。

ええ…　生tsが一番高画質と思ってるのがいるのです

おお…　tsよデコードされてしまうとは情けない

高音質だの高画質だのは価値観のぶつけ合いだから荒れるわな
オーディオマニアの舌戦は見ていてわけわからんが、今の状況も似たようなもんか？

おお…　おお…

んん… あっ

早く春休み終わんねえかな〜

安心なさい
春休みは終わったと桜の花びらがそっと教えてくれたよ

>>27
画質なんて現状フィルタ掛けずにcrf出力が主流なんだから大して荒れる要素も無いだろ
音声エンコだって大して変わらない。cbrかvbrか程度
それが通じない奴が暴れてるだけ

＞画質なんて現状フィルタ掛けずにcrf出力が主流なんだから

そうなの？
検証したの？
したならその分母、分子数は？
検証方法は？

言い切ったんだからその根拠を教えて欲しい

>>32
言わんこっちゃない…

そうなの？
検証したの？
したならその分母、分子数は？
検証方法は？

言い切ったんだからその根拠を教えて欲しい

早く春休み終わんねえかな〜

>>33
俺もこういうコピペしてもらえるような文章を書けるようになりたい。

俺もこういうコピペしてもらえるような文章を書けるようになりたい。

じゃあその生ts君ってずっと一人が張り付いてたの？

まあ少なくともフィルタかけてどうこうってのはこのスレの守備範囲じゃないな
高画質がソースを満点としていかにそれに近づけるかという話ならまだわかりやすいんだが、
好み（←ここが曲者）の画質にするという点で争いになってるからどうにもならん

tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる
サイズはそれなりだが

え
もしかしてこれで成りすませてるつもり・・・なわけないよな

＊ここは釣堀じゃありません

他所でやって下さい

グレインってどう思う？

１、ソースに忠実に残す。
２、ノイズだから除く。
３、圧縮のために除いてから、再生時に疑似グレインをかける。

1に決まってるべ2は古いアニメでつるつるが好きなら良いけど
3は意味ないどころか最悪だべ

>>44
４、スレチだと思う。

無理して答えなくてもいいと思うんだ

--tune grainとかあるんだしスレチってのはあんまりでね？

tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる

次のコミットが来るまでずっとこんな状態なのかなー

適応インタレﾏﾀﾞｰ

ところでh265って相対的な画質が理論上倍程度になる予定らしいな
まだまだ先らしいがx264の開発陣は発表されたらどうするんだろうな

x265ｸﾙｰ？

でも4K2Kで使うかもと思うと、それぐらいじゃないとやってられんと言う・・・。

4K2Kくらいになるとシャギーもなくなるの？

4k2kなんて720p製作が縞々アプコンになる悲劇が起こるだけです

tt

横は怪しいけど720pなら縦は丁度3倍だからボケは少ないかも知れんぞ
つか、縞々アプコンって補間無しかよｗ

2160i放送とか胸熱　pにしてくれｗｗ

>53
H.265の規格策定がまだまだ遠いからそれはないよー。
2013年あたりで策定されるように業界は動いているみたい。

さすがに4k2kになってもインターレースが生き残っていたら嫌すぎるな…

4.2以上はインタレ禁止だから無いんじゃないの？

いずれにせよ、日本の放送は当分の間、今のH.262/MPEG-2 1080iのままだろうから、
x264のMBAFFが完成すれば、非常に便利だろうと思う。

264とばしてHEVC（265）になるんじゃない？時期的に

>>8
b-pyramidとDXVAの問題、うちは関係ないと思ってたら
1920x1080 60iの場合は、--b-pyramid strictかnoneじゃないと
一部がブロック状になってしまうことに今更ながら気づいた。
再生自体は出来るからこういうのだと分かりづらいね。
環境は、Windows7、MPCHCのDXVA、GeForce GT 240。
Win7標準のだと大丈夫だった。

r2000まだー

インターレースのプリセットが欲しい。
オフにしなきゃいけないオプションとか
「使った方が良い」と言われてるオプションが多くて未だによくわからん。

>>67
BD用の設定が参考になる。

http://sites.google.com/site/x264bluray/home/1080i

インタレ保持ってPC鑑賞用途なら--tffか--bffでいいのかと思ってたけどちがうん？
再生互換性向上用の設定ってあんまインタレと関係ないのかと

weightpとかは勝手にオフになるような

再生側ではDXVAでインターレス喰わせると不具合出やすい感じはする。

>>67

自分で学ぶ事を放棄してる奴ってプリセットを欲しがるよね

あんたの人生のプリセットも作ってやろうか？

正直x264の設定だけならプリセットとmeとsubmeさえ覚えてれば十分
vaqやらpsyrdの適正値を見極めるのは難しい

数値弄るとこんなに弄ったんだから綺麗になってるに違いないって満足感が得られる

モスキートノイズまみれのソースを云々・・・

細かい粒子状のノイズのあるエロ動画を縁故すると毛の部分がどうしても
潰れてしまいます。denoiseやaqで調整してもうまくいきません。
なにかいい解放はないですか？

>>76は実写です。

でのいずしたらそりゃ潰れる

エロ動画のエンコなんかこまけぇこたぁいいんだよで済ましてるわ

全部パイパンになったりしない？

>>76
--tune grain

余計なことやらずにレート上げればいいだけじゃね

閾値下げてデノイズ具合を妥協

aqオフってｃrf下げる

psy-rdもりもりで対処すべし

でもね、プリセットを求める人が増えたって事はそれだけ一般に普及したって事だよね

ようするに俺達にとっては「飽きた」ってこった。

なんだこのクソコテ。

黙ってNG入れとけ

水遁食らわせるとかｗ

>>89
そんなに冷たくあたるなよ

>>87
最新リビジョンがいくつかもわからないままx264を非難してたアホコテだよ

r1936
えーと、今回の主な更新は --ssim、--psnr を tune ssim or psnr じゃないときに使うと警告を出すようになったのと、
ブルーレイの互換性を高めるオプションの追加くらいですかね

わざわざどうも

来たか(ｶﾞﾀｯ

BD作りたい奴は --bluray-compatだけ付けてろって事か

levelでのVBV指定とか,bru-lay対応とか全部勝手にやって欲しいよね。　良いパッチだ。

そういえばCQMのテストをできるavisynthプラグインがあったが、
AQとpsyでも同じことが出来たら物凄い楽になるよな

blu-rayか。　かっこわるい名前だぜ･･･

Ichidou-ray
Ayanami-ray
Solty-ray

Ayanami-ray

これが一番しっくりくる

そんな「x264が死んでも代わりが居るもの」なんて言いそうな奴より
「僕が一番x264をうまく使えるんだ！」な奴の方がいいだろ
って事でtem-rayで

bu-rayで

BL-urayで

Amuro-ray

-BL

>>91

いやぁ、あれはホント恥ずかしかったよ。

つかぬことを聞きますが、

ttp://x264.nl/
と
ttp://www.xvidvideo.ru/x264-video-codec/
は、どっちが性能良さげ？

ちなみにファイルが小さいのは下の方っぽい。

つかぬことを聞きますが、どうして性能が違うと思うの？っていうか性能ってのの基準はなに？

nl → GCC4.4.4
ru → GCC4.6.1
CPUによって違うんだし自分で測ればいいじゃない

性能ってのが何を指すかは知らんが、どこも大差はないと思うぞ
俺のL-SMASH(lame, qtenc, faac, lavc)ビルドは7.8MBだし、容量は機能次第で全然違う

自分の環境に最適化したコンパイルを自前で行うのが最強って先人がいってた
でも素人がやると最適化した”つもり”なのに性能が落ちるって俺がいってた

>>110
プロでもよくあるよ。
最適化して意気揚々と計測してみると大して変わってないか、下手すると劣化してるって事。

怖いことを言うな
自ビルドとそうじゃないx264で今テストしたら、一応自ビルドの方が1.7秒早くて安心したぜ
誤差の程度以上には劣化してないってこった

秒じゃなくてfpsで測った方がいいと思うけどｗ

112だが、fpsだと小数第2位すら変わらんかった

r1937
アセンブリを使わないビルドの修正

r1935、1936の修正を読んで、BD-compatibleで書きたくて調べているのですが、
・--pic-structは要るのかどうか
・--weightp 0であるべきか、--weightp 1でよいのか
コレといったリンクが見つからないです。

なにか情報をお持ちでしたら教えてください。

Doom9で既に幾つか質問と回答が出てるだろ
http://forum.doom9.org/showthread.php?p=1492256#post1492256
--open-gop bluray　が　--open-gop（パラメータなし) に変わって、
あとは--bluray-compatを付けるようになっただけ
他は変更なし

調べたって、どこを調べてるんだ？
どこぞの間違いだらけなエンコブログか？

32bit r1397
64bitはまだ

ささいな事で噛みつきすぎワロタ

でも、回答自体はしてるし、なんてツンデレなんでしょw

>>117
どうせasm無効の時ビルドできるようになってるだけなんで、
ビルドしないと思いマッスル。

1936と1937の変更点はそれだけ。

--fps使ったら出力フレームレートは変わらずに
再生速度が倍速とかスローモーションになるんだが、なぜ？

お前は--fpsを何だと思ってるんだ

x264初心者スレでも手に負えないレベル

2レス消費しても何一つ生産性の無い発言しか出来ないのな

なぞなぞはよそでやれカス

エンコ職人の朝は早い

みんなのエンコ屋さん

みんなのテレビ屋さんになると地獄

夏は定期的な停電が起きると思うけど
それによる対処は出来てる？

うん

服を脱ぐかそうでないかの違いだろ？

気化熱を利用した新しい冷房システムを検討中

右手のピストン運動で発電できないか模索中

UPSは数十分しかもてないだろ
やっぱデミオの初代か発電機買うしかないだろ

UPSあればS4にしとけばいいんじゃね？

今売れまくってる家庭用蓄電池が200万円くらいだっけ

このスレでソーラー発電やってる奴居る？

スレタイと自分のレス客観視してアリだと思えなかったらそろそろやめとけ

Hondaのエネポ買ってしまった
カセットボンベで発電出来るようになったとは
時代は進んでるんだな

VBVバッファって再生互換を上げるための物なのかね、よく分からんのだが
画質とかサイズに影響ある？

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

>VBV reduces quality, so you should only use this if you're encoding for a playback scenario that requires it.
（VBVは品質を落とすので再生環境がそれを必要としない限り使うべきではありません）

>>140
そう、再生互換性のため。
瞬間的に滅茶苦茶高いビットレートになったりすると、
高い処理能力を要求されることになるので、
様々なハードウェアで再生できる保証ができない。
そこでビットレートやMB数を一定ライン以下に制限して、
その規格を満たすようにハードウェアを作れば安心ってこと。

PCで再生するならスペックは十二分だから、特に気にする必要は無い。

でも品質を落とすといっても誤差程度だよ。

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
Wikipediaに書いてあるようにもともとH264ではLevelでレートの上限は決まってる
低速トランスポート(光ディスクやネットワークストリーミング)を使用する場合などに
もっとレート上限を下げなければならない場合に使用するものと理解してる

すごく単純に言えば
--vbv-maxrate 500
のような指定はビットレートの上限を500kbpsと指定したことになるので
当たり前だけど低い値を指定すればするほど品質は悪くなる

十分に大きな値（無指定でも到達しないようなビットレート値）を指定したなら
品質の影響は無いと思う
もっともパラメータ乗せる分だけほんの少しペイロード増える
（つまり圧縮率が低下する）かもしらん

>>141
ああ、そうか。
確かにLevelで指定されてるVBVは高すぎるし、デコーダーのことしか考えてないな。
DVDやリアルタイム配信とかでは、転送速度に合わせてVBVを指定する必要があるね。

安価ミスったorz
>>141じゃなくて>>144です

箱丸で再生するときは結構重要だったりするVBV

それはこまるな

わーい

>>137
やりたいが結局、UPSかまさないと
商用電源と切り替えがうまく行かなそうなんだよな...
バッテリーとUPSで無駄な出費が大杉

ソーラー電源は停電しない前提なら節電対策としては有効だな

初期費用回収する前に地震来てあぼ〜んだろ
個人宅でソーラー発電とかアホ

太陽電池で抑えられる二酸化炭素消費量より太陽電池を作るときに出る二酸化炭素の方が多かった問題は改善したのか?
ただ太陽電池はそもそも電気のないところに電気を作る用途の方が現実的なので今回の地震のような場合は非常に効果的でしょ

都市伝説

いつまで続くのこの感じ

えぇっと、このスレは何だっけ？

x264でHDアニメをいい感じにエンコするオプションを語るスレ？

エンコする人間にとっては非常に切実な問題だよな

>>143

いやいや、ブロックノイズがのるほどいっきに落ちるときもあるよ

実写の水面とかな

さすがに実写の水面はソースからして破綻していることもあるんじゃ

>>161
ソース破綻→ノイズ大量発生→更に情報量増加→むりくり圧縮

むりくりっ

おいこら
ソースが〜なんて言ったらまたあいつが来るだろｗ

帰れ荒らし

無理クリトリスって何？
あいつって誰？

tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる
サイズはそれなりだが

PCモニタが腐ってるんじゃね

>>167

それはやりのあれの変形版。

そのまんまコピペだから

おお…

やま…

の…

もぶよ…

をし…

はしたわ…

どけだ…

めっちゃ死ね！

(#ﾟ･ω･)
　⊂彡#)#)д`)>>178

　 l　 ,|　　　　|/////////////////////////＞＜///ﾊ　　　　ヽ
　 l／:|　　　　|/////＞＜////////////＞ １　! |　｀ ＜}i
／ : :｜　　　 |//＞ﾊ ｜| |｀ ＜////＞ ´｜　| _｣⊥」 ﾊ　|| 　 |
: : ://.|　　　　|'/∧|l_」⊥L|__|　| ｀　´　　|斗}１∧|｜.| ｀l　|| 　 |
: ://　|　　　　〈　「|ｌ　|/　!.l　|　|　 　 　 ｜仏　 斗＝=ミx || 　 |
:/〔_/｜　　　　∨ |! ァ＝=ミｘ /　　　　　|/　ィ　　i_ ｎ}｀ヾ.ﾘ　 .′
:＼　/|　　　　 、V / {ト　 i_r‐'　　 　 　 　 　 {r<　 ｛ r　//　 /
: | ｀´ |　　　　　＼ト　ヾ ､__ﾌ ｉ}　　　　　　　　ゝ 二∠ //　 /
: |　　ｉ|　 r‐ ､ r‐､ ＼　 ＞-- '　　　　　　　　　　　　 /ｲ
: | (⌒ヾ'ハ　 ', ￣￣￣￣￣|　　　　　′　　 　 　 ／ ﾉ
/| ∧ 　 ﾏﾑ　 ﾏニニニニニ|　　　　 _　_　 　 　 　 ／/ 　 　 /　　 .′
: : :r‐ﾄ､　∨ゝ-'　　Ｚ二ニ　 |　　　 　 　 　 　 　 イ　/ 　 　 //　 ./:
:r‐{　l　＼_）　　 　 | |ﾆ|　|　 ト　.　　　　 　 .　 ´ﾊl! /　′　//　 ./: :
:､　ヽ! 　 ‐ト､ヽ　　 ￣￣　　|::＞ ｀.　ｰ　´　 ／::::}/ ./　　//!　 /: : :
: :＼_|　　/ ノ　 　 　 ﾉ　　　 |:{{::;斗ｧァァァｧｧｚﾐ､/／　／|/ |　/: : : :
／／|.　　 　 つ　　 仁_ｌ　　 |／////////////∧/／ !: : : | /- 、: :
／: : |　 -/‐　　　　 |＿|　　 |///////////////∧: :| | : : :|/: :ヽ＼
: : ／|　 /　こ　　　　　 　 　 |////////////////∧:| | : :ト､: : : :＼
／／|　　　　　 　 　 　 　 　 |/////////////////∧ !: : ＼＼: : : :

最終話はっちゃけてて面白かったね

おお…　生tsが一番高画質と思ってるのがいるのか
tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる
サイズはそれなりだが

あのさ。ffmpegとlibavの話してもいい？

ffmpeg側のlibx264.cって、Baptiste Coudurierがばんばん書き換え
してるけど、どう見てもCosmeticsなのと一緒にCommitしたり。
かなり行儀悪い印象があるんだけど、DSはなんか言ってないか？

ffmpeg側のcommitの中身、remote branchマージで一括上書きとか
酷いオレオレCommit連発だよね・・・

このffmpegの状況、他のプロジェクトからは、どう見られているんだろう。

>>183
確かに酷いよな
ffmpeg側のソースはcompile完走しない事が増えた
ffmpeg-mtのAlexander Strangeもlibav派らしいから、ffmpegはcommitしてもらえないソースを機械的にマージするしかない状態だけど、
Michael Niedermayerが必死になり過ぎてて周りが見えてないんだろ
libavかffmpeg-mtを使ったほうがいいかもな

地デジ(SDにリサイズ)ではグレンの多い・少ないぐらいしか違いが分からんのだけど
4で足りないって言ってる人はソースに何使ってるんだ?

すまん、誤爆った

>>186
誤爆先どこ？

TMPGEncと予想

>>187
誤爆先はここだろｗ

>>189
そういやそうだなｗ
誤爆元か

>>183
DSは分裂後のffmpeg/libavとは距離を置いて、メンテナーも降りてるよ

一度FFV1のバグを直させるためにlibavの開発チャンネルに入ってきたけど
http://lists.libav.org/pipermail/libav-devel/2011-April/001029.html
の件でへそ曲げて出ていってそれっきりだな

もう、どっちもグチャグチャだな

ffmpeg/libavでH.264エンコなんてするヤシなんておらんのだし、どうでも…と思ったけど、
意外とあれでH.264エンコするヤシ多いんだよなぁ。

>>193
すいません
この間までしてました
すいません

モバイル用に手元の動画を再エンコする場合とかはlavf入力便利だろ

トラスコでH264にするならそのどちらかを必ず使うだろ。
x264が単体でストリーミングエンコまで対応してくれるなら別だが、
そんな事あり得ないだろ。

だろ。
だろ。

そうだら

だり

ニコはx264止めたんだな
ref8とか変態なことやってたのに

>>220
は？

おうふ
アンカミス

vaapi対応はまだ？
サポートしてればサンディーに買い換えたいんだけど

それはサンディーと何か関係あるのか？

Windows + GeForceなら、ソースのデコードにDGIndexNVを使える。

r1945

r1947じゃないのか

恐ろしくファイルサイズ小さくなったな

ビルドに失敗してんじゃないのか

割とよくあるから困る

今回はエンコ速度と画質に影響ある修正みたいだね。
速度は少しだけ遅くなったかも。

更新履歴見てエイプリルフール向けのジョークバージョンがあっても良いと思った
mbtreet最適化により知覚出来る品質が15%上がったみたいな

トラブルの元で誰得だろそれ

CABACにかなり手が入ってるけど遅くなるような要因はないと思うが・・・
ちょっとだけ早くなってる気がするけど

久々にwktkできそうな、画質や圧縮に影響ありそうな更新だ
ちょっくらサンプル動画でテストしてみるか

結果報告よろー

おそロシアはまだ新バイナリ着てないな
別にこだわってるわけじゃないんだが

自前でビルドは最適化したと思ったら配布バイナリより遅かった何を言ってるかry
ってやっちゃって以来諦めた

俺はkomisarのつこてる

普通にx264.nlの使ってる

俺はパッチビルドが早く手に入れられるから自ビルドしてる
エラー出てもある程度は修正できるし、どっかに頼ってるとしばらく更新されなかったりするし
まあfade-compensationが使いたいだけなんだけど

JEEB氏の使ってる

32bitver1947が1946以前に比べ異常に小さいけど大丈夫なのかこれ…

nlのmirror03がなんかおかしいだけだったすまん

本当だ

lavf/ffms入力周りじゃないの無効にしてビルドしてるけど前と殆どサイズは変わらない

x264.nlいつも64bit版が来るのおせえんだよ
いい加減にしろ

自分でビルドしる

何というお門違い

>>226
嫌なら使わなくて結構

Compiling x264 on 32 & 64 Bit Windows - Guide.
http://doom10.org/index.php?topic=26.0

これを読めば、自分でビルドできるようになる。

サルでもわかる優しいｘ264のビルド方法を英語ではなく、日本語で解説してほしいもちろんx86＆x64両方の・・・

英語も読めない奴ははなから無理だろ。

fack you

昔Vマニさんとこの見させてもらって32bitビルドは一度やったんだけど、64bitがわからない
>>232苦言は受け入れるつもりだけど、ただの煽りならやめてね

>>234
ttp://csbarn.blogspot.com/2010/09/x264l-smash.html
こことかビルド用のスクリプトも組まれててgccの使い方とか知らない初心者にもやさしい希ガス。

64bit関連は最近色々よくなった気がする。

ffmpeg/libavのlibswscaleはパッチが必要なくなったし、GPACも大体（笑）そのまんま
svnからビルドができちゃう事が多くなった。

あとはまぁ・・・　大抵の変な呪文がなくなった。うん。
（自分で色々理解してしまった可能性の方が高かったりするかもしれない）

ディルド？

作者が多忙でavisynth 64bitが放置プレイ食らってる方が余程問題ｗ

>>236の発言はあくまでもmingw32/64上でのx264関連ですたｗ

>>238
あぁ、Avisynth関連だと64bitが安定するまでは長いと思う。
masmなasm・C++なソース、どっちもWin64じゃ問題ありで、元開発者も
忙しすぎて（以下略

Zor氏が夏に時間を空ければある程度Avisynthのasmのx264asm化が進みそう。
といっても、彼は一応Monoの方でGSoCに入ったっぽいので、あまり期待できない
方針でいくしかない。

r1947にしたら久しぶりにクラッシュした。自ﾋﾞﾙﾄﾞするか

その前にクラッシュしたソースとオプションさらせよ

最新のx264にしたら結合した分だけ映像が長くなるんだけどこういう仕様に変わったの？
1800台以前のものでは一回もならなかった現象なんだけど・・・

>>242
あーやっぱり･･･
なんかやたら音ズレするようになったから1日悩んだ末に前の環境に戻したんだけど
guiEXとm2vも一緒に更新したからどれが原因かわからなかったけど、x264か

x264には結合なんて機能はないだろ

>>243
それ真っ先に疑うのaviutlじゃね

最近の買うDVDの基準は、エンコしやすそうか否かになってる。
DVDもエンコしたあとの動画も確認くらいでしか観てないや。なにやってんだろ

つーか、犯罪かこれorz

>>242
avisynth+x264だけど大丈夫みたいだ
1800のいくつか忘れたけど、結合部分が破綻するのが出来たことあったけど
今のは問題ないな、もちろん音ズレも

guiなら向こうで聞けば？

guiだけじゃなくてx264 for AviUtlでも同じだった
AviUtlと現仕様のx264の相性やらに問題があるのかね・・・？

しかし明らかに同じパラメータでエンコしてるのにビットレートが少なくなったな。
crfの値を1個減らすとちょうどいいくらいだ

>>242
これどうゆう意味？
たとえば30分と30分の映像をくっつけたら長さが1時間に増えるのがおかしいってことなのか
俺の読解力では理解できん

言い方が悪かったかな結合した分だけ映像のフレーム数が微妙に増えていくってこと

フレーム数じゃない時間が増える、だった

ああ、ようは1時間+αの長さになるわけね

そうそう、mp4って映像の方が音声より短くなるのが普通だけど
今回のは結合する数が多くなると映像の方が0.200secsとか余裕で超える

>>255
>mp4って映像の方が音声より短くなるのが普通
頭大丈夫？

それってmp4box -catとかで結合してうまく接続されてないってこと？

俺は1時間の動画をエンコしたら、100フレーム以上が平気でぶっ飛ぶことがあるぞ。

結合時の話であってエンコ時の話じゃないだろ
>>256
逆転する場合もあるけど大抵は音声のが長い
いっぺんyambにmp4ぶち込んでみりゃいい

mp3infpとか使って動画の情報見たことなかったら知らないかもね
1/1000 secsで見るとほとんどの動画は音が映像より長くなるはず

それはmp4の仕様でもデジタル動画の特性でもなんでもないんだが

誰もmp4の仕様だとかデジタル動画の特性だなんて言ってないだろ

いきなり何の話してるの？
意味わからないんだが

mp3やaacみたいにブロック単位にエンコードするコーデックなら
エンコーダーディレイをどうにかしたとしてもpaddingがあるので、
まあ音声側が長くなるというのは分かる

>>262
そういう意味で>>256じゃないのか

10秒の映像と9秒の音声をmuxしたら映像の方が長いだろ
9秒の映像と10秒の音声をmuxしたら音声の方が長いだろ
あほか

俺の扱うソースこそ世界の標準（ｷﾘｯ

一度スレタイを見直し、以後はx264の話しようぜ

ﾋﾞﾙﾄﾞするときfprofiledあるとなしじゃやっぱかなり変わるな

--thread-inputってつけない方がいいの？画質優先する場合。

--thread-inputはavisynthの処理を別スレッドで行うことで高速化を狙うもの
そもそもavs入力の場合は現在はデフォルトでつくし、廃止しないのは単なる後方互換性のため

つまりわざわざ付けるやつはただの馬鹿

魔法のおまじない

>>270
>avs入力の場合は現在はデフォルトでつくし
あっそうだったのか…　効果わかんね、と思って外してたわｗ

生tsとエンコしたのってどっちが高画質なの？

ソースより高画質とか基本的に無理。
AviSynthなりAviUtlなりで自分好みの画質にいじる事は可能。

おぉ・・・

さだはる・・・

おお…

ぬきけんじ・・・

またナマティーの流れか

おお…　おお…

デジタル彩色アニメで閾値下げて局部的なノイズ取りだけして可逆圧縮すれば純粋な画質向上と言えるかもしれない
元々ペイントのバケツで塗ったような絵だし。まあ元々のっぺりなものが更にのっぺりするだけだが

マジレスしてるところ悪いけど、スレ違いなんだよ。

お前は背景無しのキャラクターだけが動いてるアニメを見てるのかと小一時間

おまいら東芝42Z1の画質どう思う？
ソニーや三菱よりマシな気がしたが…

他所でやれ

ぶっぶっー
ソースがブロックノイズ酷かったんで除去してソースより綺麗にできたよ
自分で試行錯誤もしないでソースより高画質は絶対無理とか言ってるのはまだまだだね

おお…

き凡人・・・

ソースのブロックノイズを除去（ｷﾘｯ

そもそも放送波はソースではない。

しーっ

生TSがおお…

オタフクソースとブルドッグソースの戦いが始まったな

カープソースがうｐをはじめました

キューピータルタルソースを忘れるたぁ良い度胸だ

中濃ソースなめてんのか

ドレッシングの出番はあるっすか?

>>286
静止画にしてお絵かきソフトで修正したが5枚で挫折した俺は根性無しだったのか？

圧縮したら画質は下がるだろ

ブロックノイズ除去というか、たまに編集中にシーンチェンジ直前直後の
破綻みつけると、前後が同じ映像だと思わずコピペするときあるなｗ
まぁ、全部やる気はサラサラないが、人によってはやってる人いるんかな。

マジレスが湧く辺り、さすがに新参も増えてきたな

新参記念

>>301
おお…

ブレネリ…

あなたのおいどはどこ？

>>300
シーンチェンジ検出して、自動でやる。

r1924からr1947に変えて同じパラメータで60fps物をエンコしたら
サイズが75%ぐらいに縮んだのだけど、また画質設定変わった？

このあたりかな

x264r1943 **STABLE**（速報）
Fix VFR MB-tree to work as intended
Should improve quality with FPSs much larger or smaller than 25.

VFR時のMB-treeが意図したように動くよう修正。
25fpsよりかなり大きな、または小さなFPSでの質を改善するはず。

実際には質ではなくエンコ後のビットレートが激減してる

質を上げるにはビットレートやcrfを自分で上げないといけない

それ質も下がってるってことじゃん

圧縮率up

もしやstableって、バグフィックスがあったrevに振られるの？
ってことは、STABLEの直前のrevは必ず地雷ってことだよね･･･　使わないけどｗ

おまえがそうおもうんなら遭難だろう

>>312
ってことは今のHEADは次のbunch of commitsのSTABLEより前だから使えないね
そして次のbunch of commitsのHEADは其の次の（ｒｙ

>>314
自分は最新版を使う派なんだけどね。
前にrev100個以上またぐ超ロングパスのバグもあったしｗ

ぶっちゃけ生tsってサイズに対する画質の効率が悪すぎるよね

mpegだもの

x264もmpe…

おお…

きなくりのきのしたで…

LivavにHigh-bit-depth AVCデコーダーがコミットされたようだ

x264で10bitエンコした動画をデコード出来るようになる

x264で出力したmp4を再muxしたいんだけど
・FFmpegでvcodec copyでmuxする
・MP4Boxでmuxする
のどっちがいいの？
とりあえず速度的にはFFmpegの方が速いみたいだけど

お好みのほうでどうぞ

生tsよりエンコした方が高画質ってマジ？

またコピペか

>>321
マジで？
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!!

おお…

oh...

ぉぉ

10bit対応モニター高いお

(^ω^)

モニタもそうだがネイティブで10bit出力対応してるのってFireProくらいじゃないの

YUV色空間とRGB色空間は同ビット数だとすると1:1の射影ができない
つまりRGB->YUV->RGBと変換するとスペクトラムがなだらかにならない
そこでYUV色空間を10bitとすると、RGBが8bitでもスペクトラムが適正になり再現性が増す
（上下のクリップは計算式の変更が必要なので話は別だが）

端的に言うとYUVにした時点で失われる情報が保持されて
ディスプレイのようなRGB機器で表示する際の再現性が高まる
RGBが10bitでなければ恩恵がないわけではない

>>333
とはいえ、最低限ディスプレイドライバが10bit対応していないといけないわけだけどね。

生ｔｓってなんかえろくね？

r2000まだかよ

あ、デコーダ段階でYUV->RGB変換すればいいわけか…

こうなってくるとAviUtlのオーバーヘッドだった内部色空間YC48がいきてくる・・・わけでもないか

ffdshowがswscaleをupdateしたぞ
http://forum.doom9.org/showthread.php?p=1500033#post1500033

>>338
生きてくるよ
これまでみたいにプレビューと出来上がりの落差にがっかりすることも少なくなる
guiEｘも10bit対応始めたし

入力がYUV420だと情報落ちした後だからあんまり効果無いよねぇ

dfttestとかでNRすれば意味がある。
ただ、増加する容量を考えるとBD以外の使い道が無い気はする。

BDって10bit対応してたっけ？
10bitでエンコードしたファイルをオーサリングできるソフトあるのかな？

BDは8bitまでだったと思う。

そもそも[email protected]までしかサポートしないBDでhigh10プロファイルの10bitが使えるわけがない

10bitはBDやDXVA等を含めたHWデコードや、ビデオカードのRGB変換を信用せず
バンディング対策のためにcrfを10台前半まで下げるような向こう側に行っちゃった人用
この手の人間にとってはそれまで必要だったcrf値を5〜8は上げられるから、
ファイルサイズは8bitを使うよりも減る
8bitのcrf 18〜23程度で満足できる人間にはメリットはないし、単に互換性を下げるだけ

じゅ、17をデフォにしてる俺は…

おお…　

…きなのっぽのふるどけい

お

ま

ｒ1995
adaptive mbaff

ついに来たか。

遂に来たか
多すぎワロタｗ

ごくり。

凄いcommit量だな

震えるぞハート！

人柱募集！

しばらく様子を見てからにするか

でか！

急にファイルサイズ増えたなおい

今回から--enable-stripつけないと自動でstripしてくれないからな
自ビルドするなら./configure --helpくらい読め

…nlのほうか

64bit版早くしろ

http://www.mediafire.com/file/s67see89vtx8rqa/x264-r1995-Windows.7z

また数字が飛びそうだな

>>363
Windows 7
に一瞬反応した

adaptive mbaff対応したのであればリビジョン2000にすりゃ区切りがよかったのに。
ところで10bitを再生する環境ってのは現状PCのみってこと？

r2000来るー？

日本人はやたらとキリ番とかに拘るな
そんなのなんの価値も無い事なのに

美意識だ　和の心だ　

アメリカ人もキリ番好きじゃん

じゃあr2011で我慢しとく

日本人は〜とか言う人は外国の事あんま知らないし日本の事も
実はよくわかってない、これ豆な

x264 rev7
http://pc8.2ch.net/test/read.cgi/avi/1159847342/902

902 名前：名無しさん＠編集中[sage] 投稿日：2006/11/16(木) 22:23:10 ID:MR8tzN20
rev1000になったら職安行くわ

x264 rev19
http://pc11.2ch.net/test/read.cgi/avi/1228636479/627-628

627 名前：名無しさん＠編集中[sage] 投稿日：2009/01/13(火) 00:57:11 ID:m86C7frX
rev2000から本気出す

628 名前：名無しさん＠編集中[sage] 投稿日：2009/01/13(火) 00:58:55 ID:jUGtpLKJ
5年後くらいか？

>>366
プロ用のハードウェアにはあったと一応聞いたことがあるけど、価格的には
かなり一般人にはムリな感じ。

そんでもって、今は「PC用オンリー」という感じになります。

r1999が7の月に来たら大魔王が降りてくる

北斗神拳がアップを始めましたｗｗｗ

>>372
日本人は世界一棒が堅い民族らしいぞ

ピエール山本です

1000の時は直ぐに次のrevが出ちゃったんだよな

weightp + interlaced をやる予定はあるのかな。

え、何？生ｔｓくるの？

おお…

ムワンクォウ！

なんでも生がええと思ってるんちゃうか？
最近の人は生の怖さようけ知らんらひいな
生はやめたほがええで

ユッケは怖いんで、これからはカルパッチョ食べるよ

肉と土下座は焼きに限る

生ｔしゃぶしゃぶを忘れないで

--crf --tff で 1.7倍速 asmっすげぇ
1か2くらい crf もらわないと まえと画質合わないかんじ

>>388
一番いい日本語を頼む

俺、読解力高いつもりだったんだけど自信なくした

>>386
こうか？

　　　　　 　 ＿＿＿_
　　　　　　　|<三`'ヨ.′ 　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　_/6|ｰ廿┤ 　　　＜　肉 と 土 下 座 は 焼 き に 限 る
　　　 /l￣　ＫL.三.｣￣h　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
.　　 /　|　　 レ兮y′/ l
　　〈　 く　　 ∨ l/　,ｲ　|
　　　＼_,.>、　　　 /,L..｣_
.　0ﾆﾆﾆ)而}ﾆﾆﾆﾆニ),ﾘﾘﾆﾆ)
.　　 Ｌ| |＿＿＿__|＿＿__| |
　 　 l | |.＿＿＿＿＿＿_| |　　,:
　,　　l ＼ヽ　l　　|　　 , '／　　;'
　:, ____l＿|_|_;_|＿|＿__|_|＿＿　　　;
　　|＼ﾞ;三三ﾞ';三三三,;ﾞ三三＼　;'
　　|＼＼三三ﾞ三ｼﾞｼﾞ三三,''三;'＼,;'　　;'
　　|、 ＼＼三ﾞ;三三ｼﾞｼﾞ･'三三三;＼　;
　　0ﾄ､＼＼＼;'三三;'三三三;''三三,;'＼
　　　　＼＼＼| 炎炎炎炎炎炎炎炎炎 |
　　　　　 ＼＼| 二I二二I二二I二二I二 |
　　　　　　　＼ＬI二二I二二I二二I二二｣
　　　　　　　　0｣　　　　　　　　　　　　0｣

r1912 nl

frame I:610 Avg QP:17.55 size:139024 PSNR Mean Y:47.40 U:50.33 V:51.09 Avg:48.22 Global:48.02
frame P:19482 Avg QP:20.31 size: 26243 PSNR Mean Y:44.69 U:47.30 V:48.30 Avg:45.47 Global:45.11
frame B:58870 Avg QP:23.94 size: 5326 PSNR Mean Y:44.26 U:47.24 V:48.27 Avg:45.10 Global:44.67
consecutive B-frames: 1.9% 1.0% 17.8% 25.7% 53.7%
mb I I16..4: 12.1% 63.9% 24.0%
mb P I16..4: 0.8% 2.5% 0.4% P16..4: 41.4% 15.3% 12.1% 0.0% 0.0% skip:27.5%
mb B I16..4: 0.0% 0.1% 0.0% B16..8: 31.8% 4.0% 0.8% direct: 1.6% skip:61.6% L0:37.3% L1:55.3% BI: 7.4%
8x8 transform intra:66.2% inter:60.6%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 74.6% 82.5% 57.7% inter: 8.3% 12.1% 2.0%
i16 v,h,dc,p: 39% 23% 9% 29%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 14% 9% 7% 10% 10% 11% 10% 14%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 21% 6% 6% 10% 9% 11% 8% 12%
i8c dc,h,v,p: 41% 29% 19% 10%
ref P L0: 45.9% 22.6% 15.5% 7.1% 4.0% 3.4% 1.1% 0.4%
ref B L0: 57.1% 35.0% 4.6% 2.3% 0.6% 0.4%
ref B L1: 57.5% 36.9% 3.7% 2.0%
SSIM Mean Y:0.9844427 (18.081db)
PSNR Mean Y:44.390 U:47.280 V:48.301 Avg:45.213 Global:44.793 kb/s:2762.05
encoded 78962 frames, 6.81 fps, 2762.05 kb/s

ソース:ドラマ
--nal-hrd vbr --vbv-maxrate 15000 --vbv-bufsize 25000 --preset slow --crf 20.5 --psy-rd 1:0.1
--qcomp 0.65 --qpstep 12 --keyint 300 --tff --bframes 4 --ref 4 --weightp 0 --trellis 2
--sar 5:3 --colormatrix bt709 --psnr --ssim

r1995 ru

frame I:610 Avg QP:16.99 size:118269 PSNR Mean Y:48.26 U:51.20 V:52.00 Avg:49.08 Global:48.89
frame P:19501 Avg QP:19.80 size: 28377 PSNR Mean Y:45.28 U:47.81 V:48.86 Avg:46.04 Global:45.73
frame B:58851 Avg QP:23.63 size: 5596 PSNR Mean Y:44.66 U:47.72 V:48.79 Avg:45.51 Global:45.11
consecutive B-frames: 1.9% 1.0% 17.8% 25.9% 53.4%
mb I I16..4: 11.8% 77.7% 10.6%
mb P I16..4: 1.2% 3.3% 0.3% P16..4: 46.7% 15.0% 11.1% 0.0% 0.0% skip:22.3%
mb B I16..4: 0.0% 0.1% 0.0% B16..8: 32.4% 3.3% 0.7% direct: 1.9% skip:61.5% L0:39.0% L1:53.8% BI: 7.1%
field mbs: intra: 41.6% inter:20.3% skip:8.8%
8x8 transform intra:71.7% inter:65.7%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 71.8% 80.1% 55.0% inter: 9.5% 14.5% 2.1%
i16 v,h,dc,p: 45% 17% 9% 28%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 12% 11% 6% 9% 11% 9% 10% 12%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 15% 6% 6% 10% 11% 10% 8% 9%
i8c dc,h,v,p: 39% 27% 23% 11%
ref P L0: 59.0% 24.2% 12.5% 2.8% 0.7% 0.6% 0.1% 0.1%
ref B L0: 80.0% 16.8% 2.3% 0.6% 0.2% 0.1%
ref B L1: 83.4% 15.7% 0.6% 0.4%
SSIM Mean Y:0.9859020 (18.508db)
PSNR Mean Y:44.840 U:47.767 V:48.833 Avg:45.671 Global:45.280 kb/s:2899.37
encoded 78962 frames, 7.89 fps, 2899.37 kb/s

おいおい、ここはお前のチラシの裏じゃないんだぞ？
何してるんだよ？

↑順番間違えた
同ソースで比較してみました
MBAFFとかよくわかってません
続いて
ソース:サッカー
--nal-hrd vbr --vbv-maxrate 20000 --vbv-bufsize 25000 --preset slow --crf 21 --qcomp 0.65
--qpstep 12 --min-keyint 2 --keyint 300 --tff --bframes 4 --subme 8 --ref 4 --weightp 0
--trellis 2 --sar 4:3 --colormatrix bt709 --psnr --ssim

r1912 nl

frame I:20 Avg QP:20.24 size:161736 PSNR Mean Y:44.04 U:47.17 V:48.88 Avg:44.98 Global:44.84
frame P:1322 Avg QP:22.62 size: 64425 PSNR Mean Y:41.60 U:45.03 V:46.86 Avg:42.59 Global:42.31
frame B:4054 Avg QP:24.20 size: 25914 PSNR Mean Y:40.23 U:44.54 V:46.27 Avg:41.34 Global:41.01
consecutive B-frames: 1.0% 1.5% 8.8% 49.2% 39.5%
mb I I16..4: 12.8% 70.2% 17.0%
mb P I16..4: 2.3% 6.6% 1.0% P16..4: 47.7% 21.0% 11.9% 0.0% 0.0% skip: 9.6%
mb B I16..4: 0.3% 0.5% 0.1% B16..8: 48.1% 12.0% 2.7% direct: 7.8% skip:28.4% L0:39.7% L1:49.5% BI:10.8%
8x8 transform intra:64.0% inter:64.8%
direct mvs spatial:99.9% temporal:0.1%
coded y,uvDC,uvAC intra: 70.1% 74.9% 46.4% inter: 27.3% 24.7% 3.8%
i16 v,h,dc,p: 8% 63% 5% 24%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 25% 9% 6% 9% 6% 14% 7% 19%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 34% 8% 5% 8% 6% 11% 6% 15%
i8c dc,h,v,p: 33% 45% 12% 10%
ref P L0: 41.9% 26.2% 15.3% 8.6% 4.0% 3.3% 0.4% 0.3%
ref B L0: 58.1% 34.5% 4.1% 2.1% 0.8% 0.4%
ref B L1: 57.4% 38.0% 2.9% 1.7%
SSIM Mean Y:0.9747870 (15.984db)
PSNR Mean Y:40.581 U:44.668 V:46.423 Avg:41.661 Global:41.304 kb/s:8596.00
encoded 5396 frames, 3.80 fps, 8596.04 kb/s

r1995 ru

frame I:20 Avg QP:19.62 size:159762 PSNR Mean Y:44.50 U:47.70 V:49.30 Avg:45.45 Global:45.28
frame P:1322 Avg QP:21.97 size: 70785 PSNR Mean Y:42.04 U:45.65 V:47.27 Avg:43.04 Global:42.76
frame B:4054 Avg QP:23.75 size: 27759 PSNR Mean Y:40.41 U:45.12 V:46.62 Avg:41.56 Global:41.20
consecutive B-frames: 1.0% 1.4% 9.1% 49.0% 39.5%
mb I I16..4: 11.5% 75.3% 13.2%
mb P I16..4: 2.6% 8.2% 1.1% P16..4: 51.4% 19.5% 10.3% 0.0% 0.0% skip: 7.0%
mb B I16..4: 0.4% 0.5% 0.1% B16..8: 47.9% 10.5% 2.5% direct: 8.0% skip:30.1% L0:41.1% L1:47.8% BI:11.1%
field mbs: intra: 65.4% inter:42.9% skip:23.4%
8x8 transform intra:65.4% inter:71.2%
direct mvs spatial:99.9% temporal:0.1%
coded y,uvDC,uvAC intra: 69.3% 73.0% 42.9% inter: 29.4% 28.0% 3.8%
i16 v,h,dc,p: 10% 57% 8% 25%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 24% 9% 6% 9% 7% 13% 7% 18%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 35% 7% 5% 7% 6% 10% 6% 14%
i8c dc,h,v,p: 35% 43% 13% 9%
ref P L0: 53.8% 26.9% 12.3% 3.5% 1.6% 1.4% 0.2% 0.2%
ref B L0: 76.1% 19.9% 2.6% 1.0% 0.3% 0.2%
ref B L1: 77.8% 20.4% 1.1% 0.7%
SSIM Mean Y:0.9769171 (16.367db)
PSNR Mean Y:40.826 U:45.259 V:46.790 Avg:41.937 Global:41.541 kb/s:9300.13
encoded 5396 frames, 4.07 fps, 9300.16 kb/s

ながらエンコなので速度は参考になりません

uzai

荒らしkmMBJKM+ をNGっと

L-SMASHのgitﾚﾎﾟｼﾞﾄﾘからｿｰｽ頂いてﾋﾞﾙﾄﾞしてるんだけど昨晩ﾋﾞﾙﾄﾞしたときはうまくいったけど今ｿｰｽもらい直してﾋﾞﾙﾄﾞしたらlibswscaleライブラリが入らないんだけどわかる人います？

>>401
エラーが出てるならエラーぐらいコピペしろ

良くわかってないヤツの検証（？）ほど無駄な事はないな。

>>402
いやエラーは出ないんだけど--versionで確認したらlibswscaleがない。サイズも小さくなってる。

>>404
明らかにL-SMASHで何かが変わったんだろうな
まずtimelineみてどこが変更されてるか確認する事から始めろ

pkgでbuildしる

extra-ldflagsにLibraryの記入漏れがあるとか？

sh x264_L-SMASH_clone.sh
からやり直せばいいだろう

とりあえず俺は猫科辺りで日本語訳されるまで放置これだけ大きなアプデだとバグも怖い

libavのgitからffmpegを別に持ってきてﾋﾞﾙﾄﾞしたらversionにちゃんと表示されました。スレ汚しすみませんでした。

Libavしか使ってなかったから ffmpeg試したらlibswscaleでエラー出てbuild失敗したｗ
ffmpegオワタ

今のffmpegはろくにコンパイル通らないぞ！
機械的にソースマージし過ぎてカオスになってる

ソースがヤバイのは前からだな

分裂してから更に酷い

やっぱ生ｔｓに限るな

おお…yuv420が一番高画質だと思っているのがいるのか

余程悔しかったんだなあ

RGB48が一番高画質です

おお…

ffmpegは画質キッタネー

>>420
おお…　x264が一番高画質と思ってるのがいるのか

お前が一番高画質だよ

いやいや俺の方が高画質だよ

おまえらはまず自分の顔のブロックノイズをどうにかしろ

それでもdeblock目一杯なんだよ
NRかけ過ぎると目、鼻、口なくなっちゃうし
ソースがダメなんだからどうしようもないだろ

股間のモスキートノイズが消えません

-- paipan

>>425
プリクラ技術導入すればいいじゃん

お前の頭インターレースかかってねえ？

奇数だと毛が無くなるから偶数で解除してくれ

俺の顔はフィルターなしで十分きれい

アス比狂ってるよ

ワロタ

GOMに入れた動画は本当に味気ないな

すまんそろそろ辞める…

おお…

いちごーなな…

なんなんだよこの流れ

ネタが無い

はやくr2000来いよ…

r2000来たらハロワ行く

bframes=16にしたら縮みすぎワラタ

今回の48個のcommitって、結局オプションには変更なし？

>>440さんがアップ始めました

Libav 0.7 beta2に、9bit 10bitのH264デコーダー搭載だそうで

beta2とかの区切りをいちいち気にするのはボンクラLinuxユーザーくらいのもんじゃね
パッケージ配布されてないと何も出来ない連中

常に最新コミットを追いかけるのに疲れた人にもありがたい

bframes=16:me=umh:b-adapt=2:b-pyramid=strictにしたら所要時間倍でワラタ

Bフレどうにかしろ

最近2パス試してみたんだが悪くないな
720pアニメソースなら500kbps固定で何の不満も無い
お前らも従え

さすがにそれは汚いだろ

5000にしようぜ

1995kbpsも捨てがたい

>>449
男はやっぱ自動ってものに憧れちゃうんだぜ
映像に合わせて圧縮率が可変するなんてカッコよくね！？
…まあ実際はビットレート指定の方が難しいのだがｗ

最強の生ｔｓさんで保存かっこよくね？

エンコめんどくさくなると自然にts溜まる

緑キャビアの山が…

エンコする気のないTSなんてただのゴミだ

エンコしてこそお前のオリジナルとして愛着が湧くんだぜ

エンコした方が生ｔｓより高画質になるんだぞ

生ｔｓ氏は正しかったんですね

MBAFFの改善がされたはずなんですけど、体感的に、画質,ファイルサイズに
変化が起きたように見受けられないんですが、どうなんでしょう。

http://review.kakaku.com/review/K0000081190/

42インチが￥52000
今はこんな時代

>>461
同じビットレートで、r1947とr1995をSSIMで比較してみたら。

test

地デジtsは画質悪くて圧縮効率悪いのが難点

そういや地デジって現行だと送信元の圧縮機器の改良とかでブロックノイズ減ったり転送レート上げたりってできないもんなのかね？

出来てもわざわざやらないだろ

エンコーダーの改善ぐらいだな、出来るのは
H264なら14Mbpsくらいあればリアルタイム圧縮でも綺麗なんだが・・・

x262が完成して、放送局など皆がそれを使ってくれたら、今よりも高品質なMPEG-2を期待できるのではないか。

xは永久に完成しない

オープンソースを使ってくれるほど頭の柔らかい人間が日本にいるとは思えないね

商用ライセンスって幾ら位なんだろね
商用ライセンスってだけで無料なのかな？

x264自体を配布するんでなければ商用ライセンス要らないよ

そういうのはソニーの独占市場だから、ソニーがうんこみたいなエンコーダを廃止しないと無理だよ。

>>472
http://www.x264licensing.com/licensing
TMPGEncみたいなのはアプリケーション単位で1USドル
放送用サーバとかは一台につき100USドル

ブラジルとかH.264なのに日本だけMPEG2

>>474
テレビ局のエンコーダーって東芝かNECだよ。

アナログテレビでさえ、白黒からカラー、音声多重、ワイドクリアビジョン、って現行規格でも発展していったのに
デジタル放送ではせいぜいワンセグ潰したりデータ放送削ったりしてビットレートあげるくらいしか出来ないのかな
ハイビジョンは地デジの汚さを隠すためにデータ放送多くして本放送の画質落としてあるとか聞くけど

MPEG2って時点でハイビジョン用としては効率悪いからなぁ
さっさと高圧縮・高画質なコーデックへ意向して欲しいな

H264な放送規格が決まったとしても普及する頃には時代遅れになってるから
また同じ事言ってそうな予感

H.264を使った真のプレミアムなチャンネルをNHKが実験放送目的で設置でもしない限り、
当分はむずかしいんじゃないか？

H.265な3D放送まで待つしかないかと

4次元放送はいつになったら実現しますか？

映像が3次元になったらノイズフィルタは4次元のが必要だな

3次元いいな。
スカートの下どうなってるのかな？

4次元の次は給食次元だな

においが欲しいね
そんな難しい技術でもないでしょ

臭いのはごめんだ

ウボァー

脳内受信で感触を再現だな
頭に電極刺してさ

光は電磁場の振動
音は空気の振動

匂いも味も物質だから上の二つを再現するのとはコストがケタ違い

弾丸が刺さって「いてえええええええええええ！」ですね

死ななきゃ

スカパーHDはH.264だろ

ビットレートが低すぎて逆に低画質

とりあえずH.265の規格が定まってからだろそういうのは｡2012年後半発表予定らしいし今は時期が悪い

Mpeg2はデコード負荷が軽いからあえてそうしてるのかも
今でもアナログ放送に比べて数秒の遅延があるからな

デコードぐらいリアルタイムだろ。

じゃぁどこで遅延してるのだろう
アナログにはなかった遅延なんだけど

アナログ終わるまでその話はなしだぜ！

>>499
エンコードとデコード

>>499
そりゃいきなりPフレームからはまともに再生できないとか
バッファに溜め込んで暗号解読して等々してるからじゃね？

アナログとデジタルで両方飛ばしてる関係で仕方ないんじゃなかったか？

ちょっとまてID被ってる

局から送出する際の多重化、バケット化で遅延
受信端末でパケットからストリームを構成する際に遅延
再生機器のバッファサイズにも依存する
符号化されたデータの送受信にはついて回る問題だろう

自演かよ・・・

自演は勘弁してくれ

>>506-507
いや、>>502と>>504は俺だが>>466と>>479は別人だ

あと30分の仲だ仲良く書き込んでけ

単にGOPが0.5秒単位なのとPATPMT送出間隔が最短0.5秒だから。
両方合わせると最悪絵が出るまでに1秒かかる。

アナログと地デジ比較すると3秒近く遅れる
前のWカップとか、実況はアナログじゃないと話にならなかった

遅延時間はチューナーにもよる

実況板って3秒が命取りになるのか。恐ろしい場所だなｗ

ゴールの直後は数百レス一気とか来るからな、1000余裕
誰が読んでるわけじゃなし、単なる鯖とネット資源の無駄遣いなんだが

x264スレはここですか？

今はDTVスレです

実況以前に3秒も遅れてるとゴールの瞬間を近所にネタバレされる

>>510
いやチューナーはきちんとした区切りから再生するだろ。普通は。
同じTV同士だったら何時ONしようが同じタイミングで表示されると思うよ。

>>512
確かにチューナーによるかも
地デジ同士なんだが、パナのTVの横にカーナビで1セグ放送を同時に見てると1セグの方が2秒は遅れてた

いいえ、生ｔｓスレです

おお…

生の方が気持ちいい・・・

更に中出し
もうマジで最高

ウザ

ウラワザ

r1984に問題がある可能性が高いと聞いたけどvfr関連弄らなければokって認識でいいのかな

まず誰から聞いたか答えてもらおうか

猫科しか見てないけど
ttp://up-cat.net/x264%252Dchangelog%252Djp%2Br1900%252Dr1999.html

r1984はmbaff使用時のレートコントロールに関する変更
インタレエンコ以外は関係ない

ありがとう。もうちょっと勉強する…

ていうかmbaff自体、インタレで1080の場合にしか
関係ないオプションじゃないのか

なんで1080限定？
エロDVDソースのエンコにも活躍してくれるんだが

えっちなのはよくないからです

自慰行為は大切なことです

エンコ自体オナニーみたいなもん

定期的に出さないと静止が古くなって聖職活動に師匠をきたすんだぜ

体内に九州されるんだよ

確かに精子は体内に吸収されるかもしれないが、性欲は収まってくれないんだよなあこれが。

30代超えて精子一度吐き出すとめっきり回復遅くなった
次の日とかだるい

酷いスレだな

すぐ雑談スレ化してしまうのは、もうx264がある程度練り上がっていて話すネタが
少ないから、だと思って流すしかないな

考えるんじゃない。感じるんだ。人はただ生ｔｓの流れに乗ればいい

実際x264はたいぶ枯れてきてると思われ。

枯れてるという表現はおかしくね

枯れてるってのは過去の技術だけどその分安定してたり現在主流になっているものにはない良さがあるって事だしな｡
CRTとかwin2000とかmp3…はまだ現役かな?

生ｔｓなら新鮮採れたてホヤホヤだよ


人はただ生ｔｓの流れに乗ればいい

おお…

明治

製菓

>>540
これは雑談っていうか荒らしだろ

おお…

きく振りかぶって

殴ったー

倒産にも豚れたことないのにー

　　　 ,, ‐' ´　 ´´ 　 ´ー:z.._
　 　 ／'　　　　　　　　　　 　 ｀ヽ_
　 /!'　　　　　　　　　　　　　　　 ｀ゝ
. （　　 　 　 　 　 ,、　,ｲ　 ,、 、　 ｀ヽ
　 ゝ　　　,イ-ト､ﾘ_ヽﾉ V´ ﾚ',.-､ ,　）!
. （/　　 　 ）´､r‐o-＝'　/=c<,ィ ﾙ'
　 !　　r‐､ }　 ,,ー‐'　　（ ｰ-'　!/ 　 　 r───────
　 ヽ　{.fi {（　;;;;;　　　　 _」　　│　　　ﾉ　殴ったね……
.　　ヽ. `ｰ;`' 　 　 r─-､´　　/　 　 '⌒i　　　　　　
　　　_｀ヽ {　　　 └--‐'　 ／┐　　　　`ｰ──────
　 　 | ￣￣￣|┐　 ´,. ‐'´　　｢７

　　　　　　　　 , イナ=--'''´　|ノ　　）ノ_l／_,.へ　 　 ﾄ､ }
　　　　　 　 人{､y=＝＝=､､　　　　　ﾉ,,,ﾞ二ヽ ） ,　 },ﾚ'
　　　　　　く 　 　 　 （cﾄ}　' ;'　　　 /´(rﾟ）`'∠ノ　ﾉ
　　,.-‐､ 　 ﾉ 　 ..`ｰ-─‐'　"　　　 （　ｰ- 'ﾞ　! ,r‐('
　 i　,ゝ（.　（　 :::::::　　 　 　 　 　 　 丶.　 　 .! ,)
　 ! { (　{　 ）´::::::::　　　　　 　 　 　 _,.ﾉ 　 　 |'　　　　もっと殴ってくれ！
　 ヽヽ ）ヽ(_　　　 　　;,,_＿＿＿__`"´　　 　 l
　　 ヽ､__,ﾉ　　　 　 　 |ｰ──----7　　 　 ,'
　　　 　 （_,.　 　 　 　 {　, -─-､　/　　　 /　　500fpsくらいで
　　 　 　 ノ　　　 　 　 `'ー----`'　 　 ／

3fpsぐらいでｸﾞﾜｼ…ｸﾞﾜｼ…ｸﾞﾜｼ…って響くぐらいの方がむしろ気持ちいいんじゃないかな
所で1パスで出す時-qcompどれぐらいにしてる？

0.8

0.6

0.75

デフォ。変えるメリットが良くわからん。

ffmpeg使ってWebM 2pass出力してみたが、少し前のx264みたいにフェードでザラつくな
x264でWebMエンコードサポートするとかいう話もあった気がするがどうなるかね

>>560
フェードにweightp/weightbを使えるH.264と比較するのは酷だ。

>>559
上げると爆発シーンとかで品質が落ちにくくなる反面ビットレート消費量がでかくなる
上げて容量の総和が減る事はまず無い

--weightb、--mｂtreeだけは譲れない

qcomp0.8でmｂtreeオンと、qcomp0.6でmｂtreeオフでエンコ後の大きさが
大体同じぐらいになる場合、前者の方が画質的に良好な気がする。

mbtreetオフってh264使う意味あるの

mbtreeはx264固有の機能だぞ

別に無けりゃ無いでかまわんが

なんかtとか付いてた…あれ無いと圧縮率だだ下がりだろ

>>564は何の話をしたいのか。

画質をある程度維持しつつ圧縮率を上げたい人と、圧縮率はどうでもいいから
画質を上げたい人とじゃ設定が変わってくるのも当然だし、使う意味があるないなんて
ここで話題にするものでもない気がする

cabacさえ生きてればまあいい

インタレ保持な俺は切っているなー。
解除する場合はもちろん入れるけど。
1995でインタレ保持が大分速くなったね。crf時のファイルサイズが小さくなるだけかと思っていたら、
i7 860で64bitな環境で2passエンコの2pass目が43分ぐらいかかっていたものが38分になっていた。

mbtreeは動きが少ない部分の周辺、特に黒縁周辺のディテールが悪くなるから
そういうのが気になるかどうかだよな。

インタレ保持でも切らなくていいんじゃね

そうっすね

>>574
フェードが結構崩れる気がするんだけどなー。
改善されたと言われているリビジョン以降でもそれが見受けられるので切っているよ。
2passで潤沢なレートを当てているからというのもあるので、圧縮率が悪くても構わないし。

>>576
デノイズでもかけてるんじゃないんすか？

>>576
インタレ動画だとweightp無効だから
mbtree on時にフェード対策するならfade-compensateパッチ使うしかないね。

>>578
ありがとうー。
まぁ、ビットレートを10Mbpsくらいに決めうちしたエンコードがメインなんで、これでいいっす。

mbtreeは従来の方式と混在できると良いと思う。
mbtreeの方が理論的には優れているが、ソースがレート固定のMPEG2な以上、
フレーム全体で判定する仕組みもあった方が良い気がする。

動きのあるシーンが荒れ過ぎ
そのくせ動きのあるシーンにビットレート食われる謎仕様

別に謎じゃないじゃんか

なぜだ なぜ 謎だ 謎

MPEGのお勉強をしてきなさい

x262クルー?

おお…

おまいらアニメエンコするとき、--keyint、--min-keyint、--qpmax、--qpminの値はどうしてる?
俺は、--keyint 24 --min-keyint 1
qpmax、qpminはデフォ

keyintは完全に好みなのでお好きにどうぞ

エロい動画とかだとやっぱ -I 短いほうがシークヌルヌルで快適なんかな
-qpmax -qpminとかは弄らんわ俺は

qpmaxはデフォ（ニコwikiとguiEXのプリセットの推奨値）
qpminは15（ニコwikiと某ブログの推奨値）

どうせ期待通りに動いてない気がする

qpminは仕様変わって弄らないほうが良いっしょ

>>592
qpmaxも?
いつから仕様変わったんだ?

パラメーターは仕上がりに問題があったときだけデフォから変更する

満足いかなかった時
じゃね

アニメならkeyintそんなに下げたらもったいない気もする。
Max:240 min:1 scenecut:60 をいつも使ってる。

keyintは通常は240
30フレームだと300にすりゃいいよ
アリアとかは30フレームだったと思う確か

>>597
アリアって緋弾のアリア？
24fpsだぞ。おまけにTBSなら周期一定。

>>596scenecutそんなに高くするなら360ぐらいの方がバランスは良さそう

>>598
ARIAじゃね？本編30らしいし

紛らわしいな、おいｗ

え？

ps3みたいに超高解像度化フィルタかけるとかないの？

アニメのOPで試してみた

qpmaxの値(qpminの値は0)いじっても容量ほぼ変わらなかった。
qpmaxの値を小さくすれば画質はよくなると思ってたけど、違うの?

qpmax0にすれば画質良くなるよ。

そこまででかい数値のqpが元から無かったんじゃないの
それを弄る意味はあんまり無いだろう

x264は、qpを自動調整してるから、qpmin、qpmaxの値はいじらなくていいのかな?
というかいじらないほうがいい?

よくわからないならなおさらいじらない方がいいと思う

qpminを下げる → サイズ半端なく増えるが良いの？
qpmaxを上げる → 元々ゴミみたいなサイズだけど縮めたいの？

qpminはr1700かr1800台でデフォが10から0になったろうが
下げても大して容量はふえねえよ何言ってやがる

>>609
アホなの？

デフォルトはそれぞ0＆69だろ？
そこからどうやって下げる＆上げるんだよ

デフォは10&54のままだと思ってたわ

サイズってのはあくまでそのMB単位の話ね
--qp 1or2 と --qp 53or54 で容量がどう変わるかってこと。

デフォルトが0&69になったんならそっちの方が良いって事なんだろうな
まあどの道ほぼ差は出ないから気にしてないが…

54じゃなくて51だし
色々間違いすぎ

めんどくせえ、こまけぇこたぁいいんだよ！！（AA略
と思ったんだがググれば一件目だった。

まあ色々とすまんかった

・DivX品質保持2.4　→　164M 平均ビットレート 939Kbps
・x264 crf20 Bフレーム無　→　149M Average bitrate 833 kbps - Max Bitrate 4449 kbps
・x264 crf20 --bframes 4　→　100M Average bitrate 556 kbps - Max Bitrate 3033 kbps
・x264 crf20 --bframes 1　→　126M Average bitrate 706 kbps - Max Bitrate 3245 kbps
・x264 crf20 --bframes 16+ →　71.1M Average bitrate 395 kbps - Max Bitrate 2692 kbps

bframes=16

;(；ﾞﾟ'ωﾟ');

>>616
>更にx264 rev10スレの144さんの設定を拝借してscenecutとqpstepの数値を
>いじったものを試してた結果が--bframes 16+の71.1Mです。
07年だし許してやれよｗ
しかし、10スレの144は今もこのスレを見ているんだろうか…ｗ

カリカリしてないで、ちょっとおまんこの臭いでもかいで顔しかめてこいよ。

vbv-maxrateとvbv-bufsizeを指定しなければならないのはどういう時だけ?
AVCHDの場合は、--vbv-maxrate 40000 --vbv-bufsize 30000と指定しなければならないということだけはわかる。

AVCHDだと15000, 15000じゃないの
ttp://forum.doom9.org/showthread.php?t=154533
ここみる限りでは
普通のDVDで9M程度だから15000でも結構無理してるよね

PSでさえCBR15Mが再生できるから
ハードの規格上限が15Mあたりなんじゃない？
MP@MLだっけか
あれの最大が15Mだし

mb-treeオンだとpbrationの指定って無視されるの？

自動になるから当然
確かめたければmb-tree onにして出力してから
MediaInfo見てみれば?
i-p ratioしか表示されなくなるから

スレチで悪いが、PS3でもvbv-maxrateとvbv-bufsizeの値を指定しなければならないの?
--vbv-maxrate 62500 --vbv-bufsize 78125という感じに?
DXVAを使う場合は不明だけど

回転系は基本的に必要
ドライブの回転速度以上の読み出しはできないんだから

>>625
バッファリングしてるという発想は無いんか

>>626
そのバッファにはどうやってデータが入るんだい？

急にどうしたんだい？

>>626
全データバッファリングされなきゃ追いつかれるぞ

VBVはBDの上限に合わせておけば、大抵の環境で再生できる。

バッファリングの半分はやさしさでできています

実際のところどうなん？
PCドライブで等速読み込みしかできないやつなんて無いと思うが・・・
やってみるのはメンドクサイ（

>>626
時々の転送速度超過ならバッファリングで途切れず再生できるでしょ
バッファ以上に超過したり常時転送速度超えてるようなのは全データバッファしないと無理だけど

てかvbvは基本的にはプロファイルとレベルの値に合わせとけばいいんでないの

安価間違えた
>>626×　>>629○

プロファイルとレベルがなんのためにあるのか考えれば自明だろ

間に合わなくなっても知らんぞーーーーーーーーー！！！！

>>632
1倍速のドライブで使うことを気にするならvbv-maxrateは36Mbpsまでにしておくといいんじゃないかな。
vbv-bufsizeは互換性高めるなら、多分低い方がいいだろうね。

微妙にスレチかもしれないけど、このスレの住人が詳しいと思うので、質問。

MPC-HCってedtsに未だに対応してないの？　最新版と思われるv1.5.0.2827を
落としてedtsが付加されているファイルを内蔵スプリッタで再生すると、音が
2-3フレームぐらい早く再生されるのがある（ただし全部ではない気がするが…）

スプリッタを外部のHaaliにすると問題ないし、edtsが付加されていない古い
ファイルだと内蔵スプリッタでも問題ない気がするのだけど。

お前がそう思うならそうなんだろう

ロシアを見に行ったら1.5.2.3136が最新だけど

SourceForgeだと一見すると2827が最新だよね。
SourceForgeでもちょっと探すと2903が見つかる。
まぁ、ロシアでは639の言うとおりだが。

>>639,640
すまん、1.5.2.3136が最新版だったか。が、1.5.2.3136でも同じ状況だった。
それなりに使用者の多そうなmpc-hcで、まさか未だに未対応のはずがないと
思っていたが色々検索してみたら、edts対応は放置されているぽいね。

分かりやすいシーンで神経質な人が見なければ気づかない程度の遅延だし、
分かってる人は別スプリッタを使ってるんでしょう。スレ汚しスマンかった。

ffmpeg的にはAAC自体がどうでもいいと思ってるからな。
edts問題も音声チャンネル切り替え時の問題もずっと改善されることは無いだろう。

>>642
どこをどう見てそんなこと言ってるんだ？
お前はGitチェックしてないだろ？

>>642
おまえが、これはffmpegとはまったく無関係な話題ってことすら理解出来ない程度の
知能の持ち主ってことは理解してあげた

>>644
mpcもmpchcもデコードルーチンのほとんどがffmpeg由来なのにお笑いだな。

仲良くしようぜバカども

>>645
demuxerに関してはLAV Splitter以外にffmpeg使ってるDirectShowFilterは聞いたことないが

ffmpeg（つーかlibav)はaacエンコーダ/デコーダともに開発継続中だし、
そもそもMP4のdemuxに関してlibavformatが一番まとも
gabestやHaaliのsplitterは、基本的にmkvとts以外は余り興味がない人間が
開発してるからmacユーザーが書いてるlavfのmovdecに比べれば信頼性は遥かに下

L-SMASHというMP4 muxerを専門に実装している奴らがいる
その筆頭がx264でのedts対応やdts-compressionをなんとかしたVFR_maniac
そのL-SMASHの開発にhenryが加わった
henryはMPC-HCやLAV Filtersのビルドをしている（つまり使っている

さて

俺は2chの落書きよりは奴らを信じるが、皆は好きにすればいい

>>648
大変だね。コードを読もうとも思わない程度の知能だと。

「〜程度の知能」しか言えないよりはマシだわ。なんつって。

おお…

たどうかん

大田胃酸

王退散

　　　　　　,.ｒ'´;: 　八 　'::..ﾞヽ
　　　 　 ,.'＿＿_ _立_ _＿;;ミﾞ;、　　　　　フT
　 　 　 l厄巳厄　i王i ,.巳厄巳ｌ　　　　 夕 ヒ
　　　,.-'l　i,.:'　　ヽ:.、　;.:'　'　ヽ |,.、　　
　 　/{´ｉY´ヾｰtｯ-ヽ''　ｋｰtr-,'´lri　　　＿l＿
　　 {_i,入::.. ｀￣￣,'i!ヽ;｀￣´ ﾞ::.}rﾘ　 　　ｉ,＿
　　 ヽ_ﾉiヾ ;:. ＿ i': ll!:,ｨ .＿　.: j,ノ
　　ｯｼﾞ::;;|　,r'´;;:＞￣弋´;;::ヽ;r1:ﾞ'ｲｨ 　 ┬‐宀
　 弍::::::::l　i':;r'´ ,.-ｰｰ-､.ヾ;:;i. |:::::::ｽ 　 ﾉ□隹
　　 彡;:::ｌ　l::l　 '　 ---;:, ﾞ　l::l |::;;ｬ`　　　、
　 　,r',广ヽl::l　::.　.: 　　ﾞ:. 　l:lﾉ^i`､　　　三刃
　 ,ｲ（:::j 　 i::iヽ 　:. 　　 .: ／l:l'" l:ヽヽ　 口心

別のシーンに変わるタイミングのフレームでインターレースの縞があるときに
インタレ維持してエンコしたら隣のフィールドの色が滲んだみたいな
状態になるんだけどこれってこういうものなの？それとも自分が何かミスってる？

元のTS
ttp://bbs.pspwiki.to/up/download/1306411057.JPG
フィールド分け
ttp://bbs.pspwiki.to/up/download/1306411167.JPG
ttp://bbs.pspwiki.to/up/download/1306411260.JPG
エンコ後フィールド分け
ttp://bbs.pspwiki.to/up/download/1306411339.JPG
ttp://bbs.pspwiki.to/up/download/1306411413.JPG

フィルターはロゴ消し、r1995でオプションは--crf 20と--tffだけ付けた

同一GOP内だからじゃね？

どういうこと？

元のTSをフィールド分け
http://bbs.pspwiki.to/up/download/1306413486.png

2番目と3番目はどうやったんだ？
なんかフィルタかけてるだろ

>>659
あれ
分離はAviUtlで60fps読み込みかけただけどこの方法まずかったかな

もしくは容量ケチるためにjpgにした方かな
一応pngで元を再
ttp://bbs.pspwiki.to/up/download/1306414902.PNG

>>656
jpegでうｐするなよ

ttp://bbs.pspwiki.to/up/download/1306414902.PNG
をx264 1936
--crf 20--tff
でエンコ

その後、AviUtlの60fps読み込みしたら全く同じ現象が起きた。

YUV420について勉強してみるといいんじゃないかな

http://unkar.org/r/avi/1065094595/620-627

ttp://bbs.pspwiki.to/up/download/1306414902.PNG
AviUtl version 0.99i8 ； 拡張x264出力(GUI)Ex ver 0.32 ； x264 core:115 r1995 c1e60b9
(ds_input.auiは使ってない)
--preset medium --crf 20 --tff --crf 20 --tff --input-res 1440x1080 --input-csp yv12 --frames 1
--fps 30000/1001 -o "F:\Documents and Settings\(username)\デスクトップ\1306414902_＃temp0.mp4" -
うちでは異常なし。

>>664
プレビューの問題ってことなのかな
>>663
時間かかりそうだけどこれから勉強してみる
>>665
やっぱ自分がどっかで間違えてるんだろうね

ありがと

>>663
なるほど解決した。
ありがとう。

4:2:0のソースを4:2:0で圧縮したい場合は、4:2:0のままのYV12として扱えるAviSynthが良い。

>>668
プレビューはどのソフトでもプログレッシブYV12と解釈して表示するんで
インターレースYV12はプレビューで正常（本来）の表示は拝めないということに
注意しとかないとね。

>>669
AvsPmodは、その辺りも調節できる。

http://img705.imageshack.us/img705/3418/avspmod.png

プレビューソフトにYV12インターレース素材を表示させるときは
ConvertToYUY2(interlaced=true)を指定して読み込ませるのが基本
AviUtlでも他のソフトでもね

それだったら、マトリックスも指定できるConvertToRGBの方が良い。

AviUtlもマトリクス指定できるじゃん

WMP等の"他のソフト"を、プレビュー用にavsと関連付けしている人もいるだろうし。

r2000まだー？

pipebuf.exe avs2yuv.exe "src.avs" -raw - : x264.r1995r1_win64light.exe --
profile main --preset medium --keyint 240 --bframes 3 --b-pyramid strict
--open-gop --slices 4 --vbv-maxrate 14000 --vbv-bufsize 14000 --weightp 1
--me tesa --nal-hrd vbr --aud --colorprim "bt709" --transfer "bt709" --c
olormatrix "bt709" --ademuxer lsmash --acodec copy - --input-res 1280x720
--fps 24000/1001 --audiofile "audio.aac" -o "out.mp4" : 2 )
こんな風にエンコした動画がMPCHCでシークすると画が更新されないんだけどどうすれば解決できる？
C:\bin\bin\MP4Box_0.4.6_20101022.exe -fps 24000:1001 -add "out.mp4"#video -add "out.mp4"#audio -new "new.mp4"
とremuxすると問題なくなるようなんだけど。

--opne-gopをやめる

うっわスペルミス

>>676
そういえば、x264でのmp4出力なんてやってらんねェぜってなこと、開発者の誰かが
言ってなかったっけ?

そこを捨てたら今の利用者の9割は使わないだろ

mkvなんて一般的じゃ無いしなぁ
oggや字幕なんかが使えても再生出来なきゃ意味無いし

おお…

>>680
だからMP4Boxなどのmuxerと併用するのが常識なんじゃないの？

raw出力でもいいけどVFRは直タイムコード読ませてmp4出力のほうが便利だな

raw 吐き mkvmerge な自分はどうすれば

>>683
mp4boxがH264 ESのSPSを読み取ってよろしくやってくれるんならいいけど
今の仕様だとデフォルトでfps25決めうちとかなので、CFRでも
ESをmuxすんの微妙にめんどい

>>676
mkvなら、--open-gopとしても問題ない。

Androidは2.3以降WebMに対応したのだから、H.264 on mkvなものも
対応してくれればいいのに。WebM仕様のmkvサブセットでもいいので。

jeebがmkv大好きだよな

後続規格だけあって、字幕やチャプタなどmp4ではきちんと規格化されて
いない所が規格化されているし、Open GOPの問題は起きないしねい。
もちろん、多少必要リソースが増えるというデメリットもあるし、
そのデメリットはPCならともかく携帯端末では結構辛くなるけど。

>>690
えっ

MP4のパーシングよりMKVの方が重いとでも言いたいのかい、君は。
そう言いたいのならば、基本的なアルゴリズムをみて、ベンチマークしろよｗ

携帯端末に全機能を組めば当然色々必要なリソースが増えるんですが、
（ASS字幕のレンダリングやハードウェアデコーダーが対応してないA/V形式
　のデコードをやっちゃうとか）
パーシングのレベルで逆にMatroskaの方が扱いやすいかと。
と、L-SMASHの開発や仕様書を見て思いました。

というか、ISO系はもう少し仕様書を読みやすく書けよ…ネイティブな人にとっても
紛らわしい部分があるし（Matroskaと違って）。プロ系のクヲリティーって奴ですね、
わかります。

そしてスレ違いなので、とりあえず引きこみマッスル。

:.|/ : : : : ／ : : : |: : :|ノ　　　＿＿_ 　 　 '; :､: : : : : : : : : |: : : l
⊥、: :／: : : :.:.:._j: : :|　 ´￣￣￣￣｀　　丶:＼: : : : : : :｜: : :|
ｰ 、ヽ : : : :.:イ´｜: :|　-――- (　　　　　 /＼＼: : : : : : : : : |
（　＼ ヽ:√　　 ｜: :|,ィ伝テ卞、　　　　　'　,ﾆ＼＼: : : : : : : |
　`ｰ ヽ｀ﾐヽ　　 ｜: :|､ Oｭ: :ﾉ,　_　　　　ヽ　!o､ﾉ ＼ヽ: : : : : :|
　 　 〉　ヽ　　 　 |: : |　￣ﾞ｀　´　　　　　　 ',￣ﾞ｀　 |: ヽ: : : : : |　　　
　　く　　 　 　 　 |: : |　　　　　　　　　　　　i　　 　 l: : : ヽ: : : :|
＼　　 　 　 　 　 |: : |　　　　　　　　　　　　|　　　∧: : : : '; : : ﾄ､　　ふざけてるわね
＼ >ｰz-.､　　 　 |: : |　　 　 　 　 　 ､　　／　　 ∧: : : : : :}: : :|: ＼
: : ＼〈 l　 ', 　 　 |: : |　　　　　　　　 　 　 　 　 /: :|: : : : : :|: : :|: : : ＼
､:ヽ: :＼ 　 ',　 　 !: : !　　　 　 　 　 　 　 　 　 /: : :|: : : : : : : :｜: : : : :＼
: ヽ:＼: :＼　＼　.!: : |　 　 ､ ＿　 　 _ , 　 　 /: : : :j: : : : : : : : :|: : : :）ヽ: :ヽ
: : :}: : ヽ: : ヽ　 .>' : ﾉ　 　 　 　 　 　 　 　 ／: : : :/ : : : : : : : : : : ／　 } : : ）
: : :|: : : :}: : : :V : : /　＼　　　　　　　　 ／ : : : ／: ／: : : : : : :／　 　 ｊ_:／
ﾉ: :| : : ﾉ: : : : {: : / 　 　 ＼　　　　　　/ : : : : : : : /: : : : ノ: ／

MP4がアレなのはQuickTimeなんか元にしてるからじゃないの

利権を確保したい奴らがなんでもかんでも突っ込もうとしてメチャクチャになったのが原因
14496-1:2001とか見ればカオス具合がわかる
ISO Base Mediaが14496-12に分割されてからやっと多少落ち着いたけど

チャプタとかはむしろMOVの方がまとも（嬉しくない方式なのは別としても）
ただしQuickTime、テメーは駄目だ

CoreCodecは、Matroskaに関しては、今までちゃんとやってくれている。

ただ、CoreAVCをもうちょっとまともな物にしてくれたら嬉しいのも確かだが。

QuickTimeは1991年1.0登場から大して変わってないからなｗ
Win95より前とかどういう時代だよって話だ

ハードウェアというかレコーダーとかでmkvがサポートされたらいいんだけどなぁ。
レコーダーでもチャプタ打ったりとかでメタデータ管理してるんだから、出来るとは思うんだけどなぁ。
あと、ファイル名なんだが、サブタイトルの管理を別に設けられるといいのだが。
番組名とサブタイトルを一緒にするとファイル名が長すぎて困ることがあるので。

>>697
mkvの話？
ファイル名で管理しなくっても、いろいろな情報を分類して書き込めるだろ？jpgだってOKだし。

jpgでどうやってサブタイトル管理するの？

>>699
jpgファイルを右クリックしてプロパティ→詳細を開いてみろ

>>699
分かってて言ってるとは思うんだが、jpgで管理するんじゃなく
何でも情報を埋めこめられる。jpgのような画像もmkvの一情報として
埋めこめられる（良くあるのがジャケット写真とか）

おお・・・

エッジ周りをきれいにエンコする設定は？

>>703
--aq-strengthを下げる。

mb-tree ONなら、qcompも要チェック

--tune grainでaq-strength 0.5はどうゆう効果を狙ったものなの？

また、stillimageでのpsy-rd 2.0:0.7, aq-strength 1.2もなんでこんな設定に？？？

一様にグレインが載ってるのに高周波のq値を上げるとグレインが潰れて
高周波部分の劣化が目立つからq値の幅があんまり広くならないように

だと妄想してみたり
doom10か9かなんか聞いてみれば良いんでない?

おお…

きな…

くり…

えっちいのは禁止です

りん…

かい…

がっ…

>>714
後だしぬるぽ

ぽるの

大きなクリリン絵画っ

>>706
そのオプションの数値を上げたり下げたりしてテストすれば分かる質問だろうに。
まずは自分でやってみそ。


OCNだがようやく規制解除された。

>>718
このセッティングはけっこう謎

次は３Dなんだな
うーん・・・つまらん

3Dの素材って自前だとどうやって作ればいいんだろｗ

カメラ2つ使って撮影してうんたらかんたら。

実写だと3Dカメラで撮る
CGだとモデリングして計算する
アニメは、アニメは、あに．．．

面白そうだな
やらないけど

>>722,723
敷居が高いｗ見る方のですらまだ環境揃えてないのに
検証する人あんまりいないだろうなあ

>>723
まず輪郭を赤と青に塗ろうぜ！

>>725
3Dカメラは結構出回りつつある。なんせ、外部出力不可とはいえ
3DSにも載ってきているぐらいだし。

ただ、フルHDの3Dカメラでおもちゃレベルではないものとなると
かなり辛くなるけど。

3Dカメラといってもただ単にカメラ同士の同期を取って適切な1つの動画として出力するソフトウェアがあれば個人的にでも解決出来る問題じゃないの?
音声から同期を取り動画のサンプルを取ってその差分からカメラ間の距離を割り出して処理を加えて1つの動画にするみたいな
最後の処理が個人で作るにはものすごく大変そうだな…

x264でcrfエンコード後、mp4やm2tsファイルで格納
仕上がり後のビットレートを波形で表示できるようなソフトってないでしょうか？

>729
ttp://www.winhoros.de/docs/bitrate-viewer/

>>730
有難う！
crfではmaxbitrateは無視なんですね…

>>731
--vbv-maxrate

>>732
それでも正確には守れないけどね。

長文制限うぜぇ

�@大抵の「ビットレート・ビューワー」はvbvなどを全く参考せずに
　よく分からない範囲の平均ビットレートを計算して表示する。

�Aビットレートエンコードの時も、CRFエンコードの時もVBVを作動させるため
　には--vbv-maxrateも、--vbv-bufsizeも必要です。どっちも自動的には
　作動しませんし、リミットもしません。

ちなみに--vbv-bufsizeとは、上に書いた「範囲」みたいなものです。
そして--vbv-maxrateは、指定した範囲で平均ビットレートには絶対
超えちゃいけない壁みたいなものとして理解してもいい。

これで出来上がるのは：
「たとえ一時的なピークがあっても、maxrateの転送・読み込み速度を
　持っているデコーダーはbufsizeぐらいバファーすればデコードに
　追いつかなくなる事はない。」

この他にはバファーがスタート時点でどれぐらいいっぱいになってるとか、
「（CRF+vbvで）crfの数値をこれ以上上げないでくれ」という設定も
ありますが、どちらも基本的にいじる事は必要ないでしょう。

ttp://pastebin.com/E3fv36kw

vbv emergencyて結局どうすれば有効になるんだ

SAR 4:3おかしいと思ったが、Haaliの問題なのか

Haaliはオワコン

>>739
VLCで再生するのが一番。
どうしてもDSF使ってMPC HCなりなんなりで再生ってことなら、
LAV Splitter使うのがいい。

>>741
THX

VLCとかねえべ

VLCはインターフェースが糞過ぎるのが難点だが、フリーソフトで4:2:2や4:4:4の動画を
再生できるという点のみ評価はできる。

が、いい加減インターフェース何とかしろとは言いたい。

VLCは色が正しくならないから使うのやめちゃったな。

BD向けにエンコしたい人はここ診ろ(命令形になってるけど)
ttp://sites.google.com/site/x264bluray/

>>738
vbv使ってて必要なら有効になる

>>744
スキン機能使ってる？
インターフェイスなんぞスキン機能でガラっとかわるんだが

知らないで批判してるとかいう無様なことはないよなァ？

VLCごときで必死になるなよ

VLCはシークした後に数秒間画面がぐちゃぐちゃになるから使ってないなあ

>>750
とりあえず、最新版使ってみてからモノを言え

そもそもVLCなんか使ったことないな

おお…

まい…

テンプラ粉・・・

>>748
スキンうんぬん以前の問題だろあれは。
だいたい初期設定での起動時にそもそもあの中途半端なサイズで表示される時点でもういや。
デスクトップはみ出るとかふざけすぎだろ。
おまけに他のプレーヤーだと問題なく再生できる1080/60pクラスの動画で再生に
支障を来すことしばしばだし。

スレチ

756はたぶんものすごいバカ

ぼくが使ってるVLCをバカにするなってかID:lo8g/6uU

動画に関心のある人でVLC使ってる人なんているんだ

テーマが絞れてる言い合いに自分の関心事の方へ話題変えてるんだから言われて仕方ない。

iso化したdvdを単独で60fpsで再生できるぐらいか＞VLC

むじろ、同じことできるやつが他にあれば乗り換えたいんだが・・・

>>759
どうした負け犬

むきになるなって

>>763
気が狂うってどういう気分?

>>763
ID見て噛みつけよ。（∪＾ω＾）わんわんお！

で、このスレの住人は何を使ってるんだ？

俺様はこれだけ使っている
Qonoha・・・CoreAVCでMP4再生、PT2のTS、主にメイン
MPC・・・AVCREC、主にサブ
VLC・・・Ubuntu使うときはこれ
SM・・・ISO
PowerDVD・・・映画などじっくり見るならコレ

いとおかし

VLCは、MPCとかで使えるような他のレンダラよりも綺麗な点は認めるが、
AVIファイルの再生が上手くいかないので使ってない。

MPCならmadVRがおすすめだお。

VLCって綺麗に見せかける為に色弄るのはいい加減やめたの？

スレチ

>>770
デマ垂れ流すキチガイさんおつ。いい加減消えろ

ここまでx264の話題無し

全部haali+ffdshow+wmp

全部mplayer WW
シーク速度世界1だと思う

ここ↓の480pと576pのそれぞれ2つ目って--fake-interlacedが抜けてる？30pってBluRayでサポートされてないですよね？
ttp://sites.google.com/site/x264bluray/home

知らないがSecondary StreamとあるからBlu-ray 3D？

本編見ながらでも、子画面で再生する映像の方じゃないの

しかし、次がなかなかこないな

なんだろうその昔、lameの新しいのが来るのを待って
来るたびに「ハイハットの鳴りが違うな〜」みたいなテンプレを繰り返す流れを思い出したｗ

昔はこのスレでもバージョンあがるたびに試行錯誤してどうたら
って書き込み多かったけど最近は安定しすぎだからな

10bitも3Dも環境が先進過ぎて試せる人がいないから
話題もないのかも
どう見ても商用ライセンス向けの機能アップしかないからな

なんにせよ実写インタレ保持動画のエンコ性能が向上したのは良いことだ。

32bitエンコと64bitエンコでエンコ時間や画質の差ってどう？
差がないか32bitの方が優秀なら普通のアプリが安定動作する32bitWINDOWS7導入しようと思うんだが

>>784
【x264+AviSynth】実用エンコベンチ【32bit,64bit】
http://hibari.2ch.net/test/read.cgi/jisaku/1282371527/

画質は同じ

ｔｈｘ

>>784
速度は64bit版が1割くらい早い

エンコのために32bitOSを買うだの、安定性のために32bitOSを買うだの、
発想から結論まで純粋生ゴミ

10%くらい稼ぐには64Bitで固めないとだめだけどな

俺は一応[email protected]でメモリは4GBx6本の24GB積んでる

x64でx86版動かせば良いじゃないですか

32bitのavisynth経由だと64bitのx264使ってもあまり意味ない？

>>791
32bitのx264を使った場合よりは速くなる

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

>>787
たった1割？
1時間エンコなら6分だけ？
それなら64bitのx264より安定性がある
32bitのx264の方を使った方がいいな

俺は64bitに切り替えてから大分経ったけど、安定そのものだよ。

1時間エンコの6分はかなりでかいと思うけど人それぞれなのね

シッタカ793のいう「安定性」って一体何のことなんだろう?

メモリ食う量一緒でも10%〜15%くらい64bitの方が速いのに
メモリ8GBなんかにしたら32bitと64bitの差は更に広がるわけで…
つかWin7の64bitで安定動作しないアプリってなんだろう。出会ったことがない

不足してない状態でただメモリが増えただけじゃ速くならないよ

-rc-loockaheadを使い切れるだけでも64bitの価値はある

おお…

さか…

昔の32bitアプリは64bit環境下では動かないの多いって聞いた

64bitなんて都市伝説だろ
32bitソフトがこれだけ繁栄してるのに

>>802-803
気が狂うってどういう気分?

今時32bitなんてwindowsだけ。ゲーム機なんて15年前には64bitになってる
まあ一般人が32bitで満足しない用途はゲームとエンコぐらいだろうけど

32bitx32bitで64bitですよね
ﾋﾟｺｰﾝ x86のマシン2台用意してエンコすれば良いんじゃね！？

>>793
お前の日本語出来なさにびっくりしたわ

64bit級ｗ ﾅﾂｶｼｽ

100メガSHOCK!!!

NEOGEO！
しかし、次がなかなか来ないな
もうすぐ1ヶ月になる

-rc-loockaheadでメモリ食わせまくったとしてそんなに差が出るもん？

次は2000来るでぇ

最終レビュー前がすでに2006まで溜まってるが

1ヶ月待って2000に届かなかったらかなりヤバイだろ

Z68+2600K+Win7　で組んでみた
しかしなんだ、QSVはちょっぱやだな
びっくりしたわ

OCしてエンコとか酷使し過ぎですぐ壊れるだろ

しかし来ない

現在ペンギン様レビュー待ち

>>816
お前の石ってそんなに粗悪品なんだなｗｗｗ

ってか買えなくて僻むのやめたほうがいいぞｗ

んまぁ、QSVがとんでもなく速いのは確かだけど、品質がねい。
リアルタイムエンコを低負荷で求められる、DLNAのトランス
コーディング用途とかならいいんだろうけどさ。

>>819
OCが寿命縮めるのは周知の事実
にわか素人乙

Pen�U450MHｚからずっとOCしてるけどどれもまだ死なないなぁ・・・

アナログモデム繋いでDWANGOのFPSやMMORPGやってた頃が懐かしい

テレホーダイの時間しかネットに繋いでいませんでした

>>822-824
それぽっちの経験でドヤ顔かよｗｗｗｗ
HDDがまだなくFDが高価な時代、音響カプラで通信してた世代からみたらおまえらなんかひよっ子

おお…

データレコーダーが調子悪いとラジカセでセーブロードしてました
RPGなんかだと音を聞くだけでどこのデータかわかるほどでした（実話）

うちで一番古いアップル�U（パーツに真空管使用）と
日立ベーシックマスター レベル3はまだ使えます
でもエンコは出来ません

好きなの使えよ・・・好きに言わせとけよ・・・
それ以上はスレチだからどっかいけ

そういえばずっとスレチな流れ

このスレって、おっさんしかいないの？

画質糞過ぎてQSV使えね
論外だな

10bitって増えた2bit分には何の情報が入るんだ

優しさ

>>833
8bitではバンディングが起きる様なグラデーションが良くなる。

赤、青、緑の光の三原色を、それぞれ8ビット(256階調)、最大で16,777,216色
が10ビットになったんじゃね

まRGBじゃなくってYUVだけどね
4：2：2の合計10ビットだよ

>>828
俺はベーシックマスターJr使ってた。　夏場は熱暴走するので扇風機で冷やしながら。

>>837
違うよ・・・

>>821
常にｏｃ状態で稼動してると思ってるゆとり乙

それOCって言わないんじゃ

おお…

しぃ…

電圧かけなきゃ普通はまず壊れないのにな

今日もx264スレは平常運転だな

>>844
電圧かけないで動作するCPUあるといいネッ！

低電圧で平常運転

電圧下げた上にOC

30レスぐらいついてたからついにr2000が来たかと思ったが、そんな事は無かったぜ

>>848
まあ、それが理想だよねw
よく狙うｗ

QSV（笑）

>>851
QSVも使えない貧乏人ｗ

QSV自体が貧乏人のためのものじゃないの？

QSVって外付け付けてると使用不可は改善されたのかい？

MT処理能力で考えても1155のSandyは仕様的に貧乏人向けだしなぁ

>>854
実際、出力はしなくてもマザボ側の出力に線をつなげておけば、使えるらしいよ。

>>852
QSV使う奴なんて貧乏人しかいない訳だがｗ

QSVに文句言う奴は本当の意味での貧乏人

早くレビュー終えて2000超しちゃえよぉ

>>857
ってかお前QSV使えるCPUとマザボが買えないから悔しいんだろ
わかってるんだよ
おびえなくていいから

安物だし誰でも買えるんじゃね？

>>861
それすら買えない貧乏人が全否定してるんだよ
自分でやれない妬みでな

幼い頃、家庭が貧しかったのかな
そのせいで心までも貧しくなって
ほんと、なんていうかかわいそうだね
>>862

このスレ、いきなりこういうネタ合戦が始まるからついて行けない。

おぉ… 生tｱﾊﾞﾀﾁｮﾙﾌﾞﾀﾞﾐﾍﾞ

>>863
とりあえず使えるのか証拠の画像うｐしてみ

ID:pTRvLOCK
まだかなぁ
見事消えちゃったなぁ

>>864
それだけ現状が安定しててネタがないって事なんだろうな
ネタがないからって意味不明な雑談に走る必要は全くないわけではあるが

みんな2000越えを待っているんだよ。
まぁ、ここのところの雑談は不快だけど。

とりあえず、Bulldozerのエンコードベンチでないかなあ・・・

ニコ動でH.264採用された時と、TVMW5が出てからがこういう流れが多い気がする

>>863
結局お前が貧乏人だったんだろうがｗ

ごめんよ、貧乏でAthlon x4 620なんて使っててマジごめんないさいよ

貧乏ネタやるならお題はせめて980Xか990Xにしろよ

http://akiba-pc.watch.impress.co.jp/hotline/20110604/image/ssevb4.html

かれこれ一ヶ月か・・・
D_Sはなんだかffmpegで10bit直したりしてたから
もう少し時間かかるのか？

QSVみたいな糞画質を妬むとかどんだけｗｗｗｗｗｗねーわｗｗｗｗｗｗ

本気エンコでQSV使う人っているの？

だれがモンキーやねん

そうだなQUDAだな

やっぱり貧乏で最新のPCを組めないヤツが妬んでるんだなｗｗｗ

1155の安物で自慢するとはみっともない

>>882
そんな安物すら組めないお前らってどんだけ貧乏なんだよ

なんというレス乞食。

というより、ただのアホだな

前にハードエンコでこのスレで得意げに話してた人生きてるかなぁ

ABRとCRFをゴッチャにしてる人が居たんだっけ？

一日中ネトゲでもしてるならともかく
幾らエンコが早いだ遅いだ争っても
寝てる間と出かけてる間にエンコ終わってれば何の問題も無い
で、画質が上ならｘ264を使うそれだけの事

x264を選んだぐらいで画質が上がるわけないだろ。
画質を気にするならフィルタの組み合わせを工夫しろ。

そして最後には
エンコードするくらいならソースのまま残せよ
か？ｗ

>>890
それはバカの選択肢
生ソースが一番綺麗なんていってる人は相当な偏屈者だろ。

またこの流れか・・・

一番綺麗ですが

おぉ・・・

生tsが一番高画質と思ってるのがいるのか

>>891
ここって偏屈しかいねーじゃんｗｗ

生は鮮度が命

バカって言う人がバカなんですぅー！

加工前が一番綺麗なんて言われたらフォトショの立場がない

>>900
用途も綺麗の意味も違いすぎるだろｗ

画像の拡縮ならaviutl使うから別に大して違わないな

>>889
QSVのスレで上がってた動画で比べたけど、どう見てもｘ264の方が上だったぞ

>>899
生の方が･･･と良いたいが同意
だが動画で皺や染み消す訳じゃないし･･･フィルタの事か？！
以下>>889から無限ループ

TSは生のままLAV CUVID Decoderで見るのが一番綺麗かと。再生時のダブルフレームレート&逆テレシネ化(もうすぐ実装)

デコーダだったらデインタレもテレシネ検出もDxVA2対応デコーダで出来ちゃうからなあ
たぶん綺麗の意味が皆噛み合っていないｗ

プレイヤーでリアルタイム処理するなら同じような処理をするフィルタ噛ませた方が綺麗だと思うけどなぁただし可逆性があれば｡
今のところ一般に手に入るエンコーダじゃx264より綺麗にエンコ出来る物は無いでしょ

x264だと高品質で高圧縮できる、に尽きる

ウォーターマーク残したまんまのTS
インターレス残したまんまのTS
コンテナのアス比をプレイヤーが検知してくれなきゃSD表示されるようなTS

いくらなんでもTSのままだとゴミ過ぎるだろ。

おお…

きな…

ちん…

この･･･

生T・・・

当る…

そういやGPUエンコの件はどうなったんだろうね？
以前はCPUとGPUとのやりとりのボトルネックが原因で断念したらしいが
今はLlanoが出たし近い将来CPUにPCI-E3.0の
コントローラが載るし以前よりは良い状況と思うが

AMD版AVXが気になるなぁー
AMD独自のSSE5案も追加されるんだよね？

>>914
http://wiki.videolan.org/SoC_x264_2011#GPU_motion_estimation

誰か応募したのだろうか。

>>915
XOPは使えそうだと聞いた。

あと、HaswellのAVX2は、整数を計算できるそうだ。
http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/

>>916
おお！幾らかはGPUを活用する事が出来そう何だね！
明るい未来だ！レスありがとう

r2008
来たな
目新しいのはないな

もう直ぐ西暦超えか

swscaleの為に、色々と新しくしないといけないみたいだな。

>>908-913
わらかすなｗ

r2000・・・

stableだと丁度2000でいいな

あと数日もしくはもう既に2011超えてるのか…あっという間だな

--bluray-compatの導入が04/07だけど、これ以降オプションの
変更は一度もないんだね。

キリ番はスルーする傾向にある

せっかく、新しいの来たのに盛り上がりなしか
まあ…fixが多いから仕方ないのか…

むしろ安定感が出てきたと喜ぶところ

r2000をスルーされた悲しみでもう・・・

r2048がアップを開始しました

x264で複数PCでの分散エンコードをサポートしてくれないかなぁ
6台あってもてあましてるから有効活用したい

そんなの出来るようになってもmuxの作業でもっさりするだけじゃない？

6分割エンコして結合、音声muxじゃダメなのか。
それをすべて自動でってことなら永遠に無理だろうな。

そういうのってマルチパスエンコでなきゃ失敗したとき復旧できないよな。

素朴な疑問なんですが、MBAFFでエンコされたビデオを再生する際、
デコードされたYV12の色差って同じフレーム内でもMBによって
プログレのサンプリングパターンとインタレのサンプリングパターンが
（全てのMBがどちらか一方というフレームじゃなければ）混在していると思うのですが、
それがデインタレーサに回された時デインタレーサはどのMBが
どちらのサンプリングパターンかという情報まで分かるのでしょうか。

>>935
猫科研究所に説明があったはず
読んできたら？

>>936
記憶にないのでどこに書いてあったか教えていただけると助かります

>>935
「デインタレーサはH.264のビットストリーム上のframe/field構造を知るか」
という観点で答えると通常はnoです（デコーダに組み込みでない限りは）

ただしそれ以前に、ビットストリームの符号化方式としてのframe/fieldと
表示時のi/p判断（「デインタレーサ」を含む）は仕組みが別です
つまりframeとして符号化していても表示方法でiと指定することができます(vice versa)
だからこそMBAFFの意味があるわけですが…

HRD以前のMBAFFで、PS3で正常にインタレ解除がなされなかったのは「表示用フラグ」が
含まれていなかったためです
なお、表示用フラグはSEIで一括指定でありMB単位ではありません

>>937
猫科の人…でしょうか、レスありがとう。
そもそもデータがどういうまとまりで格納されてるのかも、
SEIというのが何であるかすら知らない素人なので、
最後の > 表示用フラグはSEIで一括指定でありMB単位ではありません
というのがイマイチどういう意味なのか分からないのですが、
一括というのは各ピクチャ全体に対しiかpのどちらかひとつ、という意味なのでしょうか。

ビットストリーム上にMBやフレームがインターレースであるという情報はなくて、
動画丸々一本がインターレースかプログレッシブであるというフラグで示すだけ。
ということはframeとして符号化されているフレームやMBがあってもデコーダは
インターレースとして処理する。ただ、家電やGPUのデインタレーサは適応で
処理できるからそこの判定でMBレベルに近い領域単位で処理をスキップできる。

ようするにデコーダーはエンコード時のi/p判定は知る由もなくて、デコード時の
i/p判定によってプログレッシブ化処理を行ってる。だからframeで符号化されていても
デインタレース処理をされてしまう可能性があるし、逆もしかり

つまり再生環境によってインタレ解除の品質は大きく異なるわけだね。

pcがfield単位で再生できればいいのに

最近のGPUなら、単純なBobよりも綺麗に再生できる。

http://www.anandtech.com/show/4380/discrete-htpc-gpus-shootout/7

だれかps3のcellでx264エンコードできるプログラム作ってください

>>943
http://blog.cell.sijam.com/

意図はわかるのだけれど…ごめんなさい、情報を正させてください
・picture timing SEIは1 access unitに1つ、つまり一般的に表現すれば1ピクチャに1つ付きます
・picture timing SEIは通常、ビットストリームの一部です（他の手段でconveyすることも可能ですが）
・デコーダはi/pの別を知ることはできますが純粋なデコーダ（デコード処理）そのものには不要なだけです
・「プログレッシブ化処理」は純粋なデコーダの後段の誰か（レンダラとか）がやります
・「デコード時のi/p判定」が何を指すかちょっとわからないのですが
　ピクチャのi/pを示すデータ自体が規格にないのなら >>937 のPS3の話が嘘になってしまいます

T-REC-H.264-200903-Iより
The presence of picture timing SEI message in the bitstream is specified as follows.
– If CpbDpbDelaysPresentFlag is equal to 1 or pic_struct_present_flag is equal to 1,
one picture timing SEI message shall be present in every access unit of the coded video sequence.
– Otherwise (CpbDpbDelaysPresentFlag is equal to 0 and pic_struct_present_flag is equal to 0),
no picture timing SEI messages shall be present in any access unit of the coded video sequence.

>>939
説明ありがとうございます。ただ余計に分からなくなりました。
そもそものインターレースのエンコードの仕組みを十分理解してないから
変なことを質問してるのかもしれませんが、
> frameとして符号化されているフレームやMBがあってもデコーダは
> インターレースとして処理する
となると、偶数ラインと奇数ラインで分離されずにプログレッシブとしてエンコード
された16x32のブロックは、デコード時（デコード後？）にフィールドに分離されたものだと解釈され
（Y成分もU、V成分もどちらも）weaveされてデインタレーサに渡されるという事でしょうか？

うわ、リロードしてませんでした。silverfilainさん、申し訳ないです今から>>945読みます。

その2つのフラッグが両方0なのでなければ各ピクチャにiかpかの情報があるにはあるという事ですか。
デコード処理そのものにはi/pのどちらであるかの情報が不要であっても、やっぱり>>946で書いたのと
同じ疑問（pとしてエンコードされたブロックがデコード時にweaveされてしまうのか）が湧いてきます。
馬鹿ですみません。

>>946
そもそもの >>935 の質問に分かりやすく答えますと
あなたはMBAFFというものを勘違いしています

MBAFFがどう動こうと、エンコーダーの入力である生のピクセルデータの配置は
デコーダの出力の生のピクセルデータの配置と一致します（劣化具合は別として）

frame/fieldの別は「どういう順番で」「どういう組み合わせで」符号化するか
というだけの話です
デコード時にはエンコード時と「同じ順番で」「同じ組み合わせで」デコードします
つまり各ピクセルデータとその色要素は「同じ位置に」復元されます
組み合わされるYとCが対応していなくても、同じ位置に復元されるので、
結果としてデコーダの出力におけるYCの位置はエンコーダの入力と全く同じです

MBAFFがframe/fieldを間違えて問題になるとするなら、
YとCを関連付けてその「劣化させ具合」「精度の落とし具合」を決定するようなことをすれば
間違った情報を元に判断してしまうくらいのものです
ピクセルの色要素の位置がずれてしまうことはありません

>>949
横から質問
デコード要求された色空間が411で無かった場合（例えばYUY2)、
色空間変換でi/p補正はどうなるの？

元からx.264は420なんだから関係ないだろ

YV12の場合全てインターレースとしてYUY2化やデインタされると色情報が劣化するのを気にしているのでしょうか？
例として、プログレッシブ化がフレーム内完結してデインタ前と後で同じ絵
これをアニメを手動でプログレッシブ化してエンコードするのと、MBAFFエンコで比較すると色再現に差が出ます
たとえが悪くてすみません
想像でスマンが、MBAFFでも画面単位インターレースとして扱うもんかと
そうじゃないと、MBAFF判定でデインタレース結果が変わってしまうからです

出先なのでid変わります

>>951
色空間変換は純粋なデコーダの仕事ではありません
それは先の「後段」の仕事です
つまり規格の範囲外です

>>954
俺のはMBAFFがどうのこうのじゃないのでした。（これは圧縮効率の問題だろう）
MPEG規格では色空間変換はデコードじゃないから規格に入ってないことは分かる。
でも現実の実装上、Windowsのフィルタでのデコーダはデコード要求された色空間でデータを返すと思うから
その点どうかなと質問したんだけど、スレ違いの質問になったようです。

>>955
DirectShowでいえば自動的に色空間を変換する
別途のフィルタが挿入されるかもしれませんし

内部で行ってくれるデコーダもあるでしょうが
規格で定められているわけでない以上どのように行われるかは実装次第です
それはもうデコーダとしての仕様は関係なく
単なる色空間変換のみのフィルタと一緒です

ただし…
DirectShowはフィルタ間で渡すデータがインターレースである、
というフラグは持っているようですので、
まともなデコーダならpic_structからそのフラグを適切に設定してくれるでしょうね

>>943
ありましたよ、前はｗ

でもSCE自らが外部アプリを禁止するファームウェアップデートを行い、
そのソフトを作成販売してる会社は撤退しました
寝耳に水だったろうねぇ

ところで、なんでCellに夢見てんの？
未だにそんな事言ってるとはずかしいぞ

PS3のCellでx264エンコできるソフトが販売されたことはないよ。

H.264エンコにCellを使うソフトなら今でもあるが。

>>958

>>944

え？販売もしてたの？

フィックスターズ、PS3を活用したH.264エンコーダー「CodecSys CE-10」を販売開始
http://sourceforge.jp/magazine/09/06/01/0851239

ID:CpkPJOq9の頭の悪さも相当なもんだな

有料だの無料だの販売されてるかどうかだのx264かH264かだの
本質じゃないことにこだわって勝利宣言。

結局本質は、「PS3ではもはやサードのソフトは動かなくされている」ことだろ

>>962
俺にはお前だけが馬鹿に見えるが

このスレではxとhの違いが分からんのは致命的だよ。

くだらない揚げ足とるくらいなら適当に教えてお帰り願ったほうがましだな。
PS3用とか速度でないし

未来日記的自作ポエムはツイッターでやれよ。

というかcellのアーキテクチャ的にエンコードって向いてるのか？

アーキテクチャ的に
アーキテクチャ的に
アーキテクチャ的に

直線番長

アーキテクスチャー

あき竹城がどうしたって？

>>949
お時間割いてくれて本当にありがとう。説明を読んで今日随分考えたのですが、
そもそもエンコードの仕組みをちゃんと理解してなくて漠然としたイメージしかないので
思考が空回りするだけで理解できませんでした。気にしないことにします。
（または一から勉強した後で考え直します。）

mp4box使ってmuxするとc:\av\ero\aegigoe.aacって出来上がったファイルに書き込まれるのは仕様？

なんだよそのフォルダパスはｗ

>>973
仕様も何もどうやったらそんなことになるのか逆に教えてほしいわ。

>>975
分かりやすく書かれているだけで
合成される音声ファイルがある場所が出来上がったファイルに書きこまれているよ

c:\に○○○.aacがあったとすれば
moov-trak-mdia-hdlr　に　c:\○○○.aacと記録されてる

>>973
いつだか忘れたけど結構前にそういう仕様に変わったはず。

C:\Documents and Settings\ユーザー名\My Documents\　とかに結合させるaacファイルを置いていて
ユーザー名が本名だったら・・・

P2Pに流してる職人（失笑）さんが真っ青になってます＾＾

つーかいまだにAVIUTLとか使ってる人って恥ずかしいと思うの

結果が全てだから
何使おうが構わない

mp4boxの仕様だからaviutlは関係ないんじゃないの？

それ一時期なってたけどパス書き込まれるの不評で仕様変わった
んじゃなかったっけ？使ってるmp4box最新にすれば直るよ

moov-trak-mdia-hdlrの確認方法がわからんな。

mediainfoとかmp4infoでみれないんだがどうやるんだ？

yambについてるmp4boxをそのまま使っているんだが

>>984
バイナリエディタで　Imported で検索

Imported with GPACって文字列のすぐ上にファイルがあった場所が書かれてるよ

>>983
〜\test_out.aac - Imported with GPAC 0.4.6-DEV-rev3303

最新にしてこう書かれるんだが・・・
これソース改変するしかやめさせる方法ないのかな・・・

>>973
avの下にeroがあるのはおかしくね？
eroの下にａｖがあるべきだろ

いまつかってるのはこれだけど
importとか%profile%の文字列は見当たらないわ

MP4Box - GPAC version 0.4.6-DEV (internal rev. 7)

ちなみにどのバージョンを使うとそんなイベントに遭遇できる？

cygwinかvc9でビルドできるソースなら有り難いんだけど

後mp4box使うとmp4ファイルの最後に

freeIsoMedia File Produced with GPAC 0.4.6-DEV-rev3303

ってのも書き込まれてる。
削除しても動画は再生できるけど

>>988
freeIsoMedia File Produced with GPAC 0.4.6-DEV (internal rev. 7)
これだと書かれないね

GPAC ISO Audio Handler　って書き込まれるだけの模様

GPAC最新にしてみると・・・

気になるならバイナリエディタで対象の列を0にでも置き換えれば済むんじゃないか

いや、IsoMedia File Produced by Google　と書き込んどけ

>>992
そっちの方が恥ずかしすぎると思うなぁ

で、おｋなバージョンとNGなバージョンは？

○　0.4.6-DEV (internal rev. 7)

○　0.4.6-DEV-rev2735　（MeGUIではここで更新が止まってる）

×　0.4.6-DEV-rev3303

他のもよろ

>>994
https://twitter.com/#!/MP4_maniac/status/82133532725616640
https://twitter.com/#!/MP4_maniac/status/82134114844672001

勝手にパス書き込まれるとか
スパイウェアじゃねえかｗｗｗｗｗｗｗｗｗざけんなｗｗｗｗｗｗｗｗｗｗｗ

GPAC本家のは全部ダメw

次スレ

x264 rev32
http://hibari.2ch.net/test/read.cgi/avi/1308452706/

>>998
乙

あ

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