x264 rev38

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

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

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

[本家]
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

[changelog]
http://x264.nl/x264/changelog.txt
猫科研究所 - x264-changelog-jp
http://up-cat.net/x264%252Dchangelog%252Djp.html

前スレ
x264 rev37
http://toro.2ch.net/test/read.cgi/avi/1338222831/

いちおつ

おつ
バンディング消すのに躍起になってたらぼけぼけ画質になっててワロタ

せいぜいSD->HDのアプコンぐらいだろそういうの使おうと思うのって

1乙
あ…ありのまま今起こった事を話すぜ！
変換精度の話題がいつの間にかバンディング前提に話題が摩り替わってた。
>990のつぶやきで鼻水がでた。

今のx264ならAQ関連をデフォからやたら下げるとかしなければバンディングの新規発生は気にすることないと思うけど

そういやソニー初のDVDプレーヤーDVP-S7000も10ビット処理する事で暗部諧調を保持してたっけ

x264ってYV12でなくRGBでもエンコードできなかったけ？

出来るけど再生環境が余り整ってないi444で良いんじゃね
どうせ動画を停止して拡大しないとわからないプラシーボレベルだろ

i444 10bit fullrange
あれRGBの方が良さそうな気がする

x264って奇数解像度扱える？

やってみればいいじゃん

>>10
ゲームの動画ならRGB取り込みしてRGBエンコの方が良いと思う
ソースがYV12ならRGBは論外
4:4:4も意味不明UVだけアプコンとかするの？

君には必要ないです

論外て
YV12を見ることができるのか

(´･_･`)

CUDAやOpenCL対応のAVSフィルタがYV12かYUY2ぐらいにしか
対応できないから論外とか書いてきそうな空気だな。

RGBは再生環境が整ってないから論外

キャプしないからRGB素材もってないし

なんかいきなりこういう連中増えたけど何かあったん？

x264farm使ってる人いる？

勢い1しかないぞヨブちゃんなんとかして

保守・・・って話題無いから保守にもならんヽ(´▽｀)/

ヨブのくせに生意気だぞ

それで結局haaliaq、mixaq、oreaqはどれが1番俺が求める画質に近づくんだ

永久に求めるものは来ない

aqだけにって＾＾

>>26がなんか言ってるぞ！！！！！

10bit使えボケ

>>26

>>26
これだけは言わせてくれ。




お前が評価される事はaqにない。

前にも聞いたそれー

処刑教室、オン！

>>26
【審議中】　(　´・ω) (´・ω・) (・ω・｀) (ω・｀ )

>>30
【否決】　（　　　´）（　　　）（　　　）（｀　　　）

たくさんエンコしてるのに寒い

[email protected]を2台同時に使ってエンコしまくってるけど寒い

当たり前の事書くなよ
スペック自慢したいだけだろｗｗ

少しでも温まるためにエンコでもするか

ふぇぇ…Pen4でエンコしてるおへやがあったかいよぉ…

そうか・・・今日も冷えるからWillametteでも買ってきてエンコに燃えるか

そこはPenDだろ

今はAMD FXが熱いぞ
往時のPenDを超える熱さだ
しかもエンコもそれなりに速いから実用的
チョーおススメ

10分で終わるカイロよりも3時間持つカイロの方が良いに決まってるじゃないか！

冬の間は、な…
しかしHaswellがなんか凄そうで、AMD頑張れ…マジで頑張れ…

プレスコ系はいいぞ
ぽっかぽかに暖まる

>>43
10分持つエサを3時間分準備すればいいんだろ？余裕だ

Haswell君はAVX2で整数演算が捗りそう

高性能ヒータ(2687w×2+gtx680×4@boinc)

>>47
初期ロットでAVX周りにエラッタがあってBIOS更新すると初期ロットだけ劇的に速度が落ちるんだろ？

ｱｹｵﾒ264

それなんていう屁飲む？

もーいーくつねーるーとー haswellくーるー

Haswellは遅れました

新rev.はよ

猫科はよ

>Fixes:

>Fix crash with x86_64 ICL-compiled libx264.dll.

>Fix crash with newest lavfs: allocate AVFrame correctly.

>Fix thread autodetection on Solaris.

>Fix gpac autodetection with certain compilation options.

>Fix a typo in r2222 that put slightly wrong numbers in the level/VBV table.

>Fix pthread_join emulation to be more correct on win32 and BeOS.

>Fix build on ARM with recent binutils.

>Fix crash if the first frame is forced to a non-keyframe.

>Improvements:

>x86inc abstraction layer: Support stack memory allocation and re-alignment.

>x86inc abstraction layer: Support automatic "rep ret" activation.

>x86inc abstraction layer: Use AVX-coded instructions in AVX functions and improve AVX support.

>AVX2/FMA3 version of mbtree_propagate, plus FMA3/FMA4 x86inc abstraction layer.

>Upcoming:

>AVX2 optimizations are in the pipeline, largely waiting on acquisition of a Haswell for testing.

K4095 r2245確認
nl POP jeeb komisar taro sadamaruはまだみたい

こう見るとビルダー結構一杯いるな

ホームページビルダーなら使っていますが、何か？

それは恥ずかしい

キレっキレっすよアニキぃ！

自ビルドしようぜ！

普通は自ビルドなんてせんでしょ
変にこだわるところがない限りは

taroきてた

x264.nl用ビルドの動作確認＆うｐ完了っと。

jarod氏次第になりますた。

x264.nl
32bit: 2245 (JEEB) - 64bit: 2230 (JEEB)

さすがに報告多すぎだろｗ
twitterのbotもブログのフィードもあるんだしもうええよｗ

twitter見てないからリビジョンアップ報告はありがたい

>>66
そうこう言ってる間に64bitも来たでお

--aq-mode 3を使うためにはどの方のを使えばいいの

訳は、ないのですか？

>>70
http://x264.fushizen.eu/
http://astrataro.wordpress.com/
http://k4095-takuan.blogspot.jp/
好きなのどうぞ

>>72
thx!

画質が上がりそうな更新ある？

コミットログ読んでも理解できないなら何も考えずに最新版使っとくのが幸せだぞ

画質まわりなんもないような気が

komisar r2245

ｘ266 - 8ｋ4ｋ対応ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

>>67
フィードって何処がいいですか、アドレス教えてたもれ(´・ω・｀)

暗いところがやたら潰れるのはdct-decimateのせいなの？

aqじゃね

松崎しげるが潜んでるんだろ

木公山奇しげる

>>80
潰れたところを拡大したら‥

濡れた髪の女が…

髪を乾かしてる…

ネタバレ注意

暗部になるとモニターにこっちを見てるキモオタみたいのが映るんだが何か俺の部屋に居るのかな

それ、マジやばいよ
寺生まれのTさんに相談した方がいい

フィードを購読してるんだが、ひげさんはここ数ヶ月なぜあの人達と会社に挑戦してるの？

QuickSyncがオープンソースのトランスコードアプリケーションに対応する
http://northwood.blog60.fc2.com/blog-entry-6495.html

で、x264と何の関係があるの

開発者が一時興味を持ってたらしいけど・・

x264で使用出来なければ意味無いな

そんなIntel限定な付加価値はどうでもいい。他でやってくれ

なんでやねん
x264はAMD限定の命令セットだろうが何だろうが使えるものは使ってるだろうが

Intel限定とは書いたがぶっちゃけQuickSyncなんて
C2Dや第1世代のi7やxeonとか使ってる連中にもうんざりする話だろ

別に。買い替えとかもありえるし、qcvでx264が走る、処理の一部をオフオードできるといった方向性なら大歓迎。

自分で書いてみろや

速くなるなら何でも使ってくれ
十分に速くなるなら買い替えるから

QSVは依然として、フロントエンドのようなものからしか使えないそうだ。

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

部屋が寒すぎてエンコしてんのにCPU温度30度付近ウロウロ
だれか俺に愛をくれ

>>102
マジレスすると、エアコンをつけた方が部屋を暖める効率は良いよ。
CPUはただ電気エネルギーを熱に変換するだけだが、エアコンは冷蔵庫の逆みたいに外から熱を取り込むので消費電力より格段に効率がいい

maruちゃんがビルドしてくれない

r2245て何かザラッっとした画質にならね？
エンコ時間もr2230と比べて20%くらい長くなってるし

勿論、x264をうpデトした以外は環境、設定、ソースは同一

r2245　avsを通さずにエンコしたら100fps近くでてびびった。
avsを通してガンガンにフィルタかけたらいつも通りの35fps台で安定している。

ソースはアメフト中継

ランジェリーフットボールですね、分かります

少し早くなったな

>>107
SODあたりのネタかと思ったられっきとしたスポーツかよｗ

>>109
見た目と名前はふざけてるけど、見ると結構まともだったりするw

LFLソースにするとx264は硬質な画質になる傾向がある
アメちゃんは線が太いんだよなぁ…

アメ女にはどうしても興奮できないな

ゴリラの雌っぽいのばっかだよね(´・ω・｀)

ゴリラが気を悪くするだろ

翻訳する機械仕事した

猫科乙

ラフロイグ吹いたｗｗ

direct=spatial(default)
direct=temporal
direct=auto

お前等どれにしてる？

ソースや噛ますフィルタに寄るんじゃね？
時間軸フィルタとか使ってるとautoでもほぼspatialにしかならん
そういうのを使ってないならautoでいいと思うがソースによっては残像が発生する事も

www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UQPm5WeJSYR

x265くるで
規格が決まったなら･･･作れるの？　いつできるかな。

x265とH.265の区別もつかんのか

区別ついてるだろ
お前が読解力無いだけ

とりあえずおまえはツッコミが早杉だろ。
もう少し泳がせて楽しんでからでも遅くないのに何を急いでんだ？

x265の公開楽しみだな。圧縮率は当然だが初期のエンコード/デコードがどれだけ重いのかが1番気になる

x265だけが出来上がってデコーダがない状況が発生する予感

どっちが早いか、ただそれだけの話のレベルだと思うけど

265を試そうとプレビューを落したまでは良かったが、なんか
お前のPCは『インテル、入ってる』じゃない。出直しな！！
って、言われたぞ・・　インテルチートとか、、

いまどきアムド使ってる可哀想な子がいるなんて

浮動小数点演算やキャッシュ効率が重視される用途（ゲーム、ベンチマーク等）だとIntel圧勝だが
x264みたいな整数演算主体の用途だとコストパフォーマンスは悪くないと思うけどな
最強じゃなきゃいやだってんなら確かに選択肢には入らないけど

AVX2でまた差を広げられそうだけどな

おまえらはAVX1/2なんてどうせエンコ以外じゃ使い道ないんだろ

主語なんなのさ

ここは何スレだよｗ
他の用途を話したいなら別行け

ｘ264で圧縮されたお前らのチンコを笑うスレ

使用時にはデコードされてマグナムになるから全然おｋさ

モザイクかかってると思ったがブロックノイズだった

それよりh.265の新しい符号化技術ってどんなの？

スレチ

ところで x64のx264を使うときはavisynthもx64にしておいたほうがいいんだっけ？

そんなこたない

PT関連ツールの影響でほとんどx86にそろえてるから混乱してるわ

言い訳かっこわるい

おい、言い訳ってなんだよその扱い。

言い訳だからだよ

どうせ糞CPUじゃ意味ねーよ

>>139
yaa4xm等を使うと、avs(x86)+x264(x64)とできて効率的

>>146
なるほど。やっとまともなレスが返ってきた。そのあたりで試してみるわ。ありがとう。

【2016】 H.265/HEVC Part2 【8192x4096】
http://toro.2ch.net/test/read.cgi/avi/1359375342/

>>147
他に、avs2pipemod, avs4x264mod 等が使いやすい。
速度的にはVapoursynthに移行するのが最強。 少なくともx64Avisynthよりはオススメ。

使い方がわからん

Vapoursynthって音周辺の互換ないんじゃなかったか？
たとえばDelayAudioとかで音と映像のズレを微調整したりとか。
trim()で切り取った部分の音を別のtrim()で切り取った部分にAudioDubさせるとか

VSはインタレの扱いまともになったん？

>>151-152
両方ダメｗ
インタレ処理、編集はavs→ vsでavsインポート、その後のフィルタ群を処理→ x264

かな。 64bit、マルチスレッドネイティブなだけあって、そこそこ効果はある。

使えたらスレあんなに過疎ってねーよ

んまあDVDをQTGMCでbob化→720pにアプコンとか結構な速度でできるから使いどころがないわけじゃない。
d2vをcpu=6で読み込むのも速いぞｗ
tivtc24なんかも、TFMまではvapoursynthでやらせて
TDecimateをavsでやらせればいいんじゃねｗ

H.265対応のx264の後継が出るとしたら次は浮動小数点演算をメインに
GPU処理に特価して欲しいな。エンコは必ずしも整数メインって訳では無いんだろ？

最初から作り直すとか凄く苦労しそうだけど

あのな。なんでもかんでもGPU任せにするのはあまりよくない傾向だぞ。
最近はOSだってGPGPU任せになってきてるしな。

GPUは単純化/並列化されているからスループットが高いだけで、複雑な処理は決して速くないと何度言えば。
フィルタリングのように、単純な計算を大量のピクセルにしなきゃいけないような一本道な処理は爆速だが、
M/Bの分割を考えたり、参照先を考えたり等、分岐や相関がある処理は向いてない。
逆にデコードは、言われたとおり順番に処理するだけだから、GPUが得意なのは自明の理。

今は大人しくHaswellを待つよろし

むしろGPUをメインにした場合の問題は加熱じゃね？
何もかもGPU任せにすると100度なんてあっちゅうまに超えるだろうし
VGAファンがうるさくなるだけでメリット低い。

>>158
ありがとう理解出来た
6月まで楽しみに待つよ

夏くらいにHaswellでPC新調する予定だけど、パーツ値段高騰してるって聞いて戦々恐々。
Win8もアホみたいに値上がりするし。
初代core i7から早く脱却したいお(´･ω･`)

デコードもGPUはUVDとかPureVideoと言ったそれ専用のASICでやっているだけ。

Haswell発売以降にしか買えないのはCPUとマザボだけだから他は今買っとく手はあるな

10bitDepthでエンコした奴をHW再生できるタブやスマホってないかな？
どこで聞いたらいいかわからんかったんでここで聞いてみた

スマホスレ多すぎるんよ・・・

10億色も再現できるディスプレイを搭載したスマホはいまのところありません

まだそんな事言ってるヤツがいるとは

タブやスマホ無理だと思うが
10bitは負荷が大き過ぎる。

問題なく再生を行いつつ、常に一定以上の負荷余裕を確保せにゃならんからの
ハードの基本的なところから底上げが必須になるから、対応し出すのが何時になるか分からんぞ？
重いデカイ熱い上に、直ぐにバッテリーが切れても良いんなら話は別だがｗ

265とか使えないじゃん

ID:ZvHF8osX

10bitカラー対応の環境その物が稀ですし
モニタより業務用のグラボを用意するのが最も大変かな

そもそも映像ソースが8bit

まだそんな事言ってるヤツがいるとは

>>170
2万くらいで売ってるよな

>>171
機器以前の問題か、盲点だった

>>173
安いな

つまり「無い」で終了？

なんともはや…スレチなのにいろいろとありがトン
こういう事聞けるスレとかどっかにある？

無いで終了だね。

余りスレチではないが聞ける場所と言えば
此処を除けば後はスマホ板でしょ

>>175
ポータブルAV板のAndroidタブレットスレとかは?

>>176-177
ありがとう、ちょっといってきま

何処へ行こうがソースが8bitだから無駄だけどな

そのいちゃもんが通用するのはロスレスエンコする時だけ
アホか

今時、再生時にデバンド出来ないのもどうかと思うけどね。

で坂東

バーン ドサッ

デバンカット

そもそもDP対応のビデオカードとDP入力対応の液晶を使わないなら
10bitでエンコしてもそれほど意味があるとは思えない。
10bitでオナニーしたいなら好きにすればいいが、はたから見て気持ち悪いだけ

まだそんな事言ってるバカがいるとは

ssimとpsnrを見てニヨニヨするに決まってんだろ?どうせエンコしても見るのなんてごく一部なんだろ?

メクラやクソガキのPS3厨房に何を言っても無駄

それはデータと出力値が一対一対応する場合に限定した話だな。

後で後悔しない為だよ

DivXとかXvidが今見れないか？

どうせバンディング対策とかつまらない理由で10bitにこだわってるだけなんだろ？

猫に小判
豚に真珠

>>192
臭いからもう引っ込めよ
意味があるとは思えないと言っててエンコ経験もなさそうだし
憶測だけで長々と語られても迷惑

目糞鼻糞

メクラ自慢

>>194
>憶測だけで長々と語られても迷惑

俺のレスに超反応する奴は図星を書かれてイラついてるんだろ
つーかエンコ経験って何さ？それを生かして飯でもくってるのかｗ

>>194
あんたも一緒に消えてください

ID:lNeGNChtだけが消えればいい

x264スレなんだからエンコしない人はスレチだろうに。
長いことエンコしてるなら10bitの長所も短所も理解してるはずだし。

今時madVRで16bit処理で再生して無い人が居るなんて不思議

あほくせーそのままスマホタブレットなんかに入れれる8bit最高れす
PCじゃ二度と再生しないファイル10bitにしてもしょーがねえずらハゲ共

言葉は乱暴だが、その考え方は同じ

目的を考えて使うか決めればいいって事だよ。
全員録って消しするわけでもあるまい。

おまえは何を言っているんだ？いったい何を録って消すって？

この話って突き詰めると、Mpeg2@17Mbpsを再エンコする必要があるのかって話になっちゃうよね･･･。

TVも4Kとかアホなこと言ってないで、その前にH.264@30Mbps〜の放送をすれば良い。　誰もBDの画質には文句つけてないだろｗ

ところで、もうx265があってﾜﾛﾀｗ
http://code.google.com/p/x265/
と思ったら、x264とは何の関係もない、前から迷惑行為をしている輩が一人でやってるプロジェクトらしい^^;

H.264とH.265はかなり構造が異なるから、x264チームでも、コードを移植して簡単にx265を作れるというわけでは無いらしい。
x262みたいに逆行するわけじゃないから、ポッと出てくると思ったのが間違いだった。

どうせなら462xとか作ればいいのにな
過去に誰かがDivXに対抗してXviDを作ったように

誰かっていうか、DivXの方針に反対して出てった開発陣が対抗して作った

取り敢えずパディング対策ならわざわざ10bitエンコする必要はないだろ
再生時にmadVRの16bit処理に任せれば良いだけだし

はあ？

さーさーどんどんボロが出てまいります。

最終的には毎度の事ながらどっちでも好きにしろで終わる訳だが

パディングってなんのじゅもんです？

じわじわと致死に追いやる魔法です

82歳である。

トーニャ・パーディング

パディング【padding】　詰め物、水増し、埋草などの意味を持つ英単語。

偽乳特戦隊

黄色くってぷるん♪とした洋菓子のことじゃないの？

それはヘディング

学校の周り走ったりする有酸素運動のことでは？
何かエンコと関係ありそうじゃん

それはランニング

狩猟と何か関係あんの？

それはハンティング
100kぐらいで飛んでくるボールをバットで打つやつだよ

>>225
それはバンディング。
みんなが言いたいのはあれだろ？　なんだっけ、あの所得隠しのアレ。

ボケきれてない

階調表現不足…じゃなくて会長納税不足のことか？！

うでたまごか

>>227
止まってたんでついorz

>>228
そそ、バンドゥーエージだった。
うん、苦しい。 あんた優しいなｗ

俺が毎晩彼女にしてる奴だろ？
まぁお前らDTには分からなくてもしょうがないだろうな

スパンキｎ（ｫｩｨｪｨ

ズレた間の悪さも、それも君の

君可愛いね。おじさんといいことしない

ふえぇ、知らない人にはついていっちゃいけないんだよぅ

これおっさんが書いていると思うと切ないな

ふえぇ、おっさんじゃないよぅ

最近脂ギッシュで加齢臭もすごいけどアニメキャラと一緒で心は女の子だよぉ
百合ん百合ん

まだ20代前半じゃコラァ


ふえぇ、怖くて一人でトイレに行けないよぅ

援交スレ

ふえぇ、援交はだめだよぅ

密かにヨブたそがこの流れに混ざってると思うと胸熱

ヨブたそは最近はHEVCスレにばっか出没してるような

10-bitとそうじゃないエンコだと1割くらいサイズが変わるのか…
実写の場合利便性をとるかファイルサイズをとるか難しいな

再生環境で選べ

subme8と11比較

x264 [info]: SSIM Mean Y:0.9900488 (20.021db)
x264 [info]: PSNR Mean Y:43.965 U:48.029 V:47.450 Avg:44.834 Global:44.169 kb/s:426.49
--profile main --crf 24 --bframes 0 --me umh --qpmin 20 --subme 8 --ref 4 --scenecut 60 --no-psy --ipratio 1.40 --pbratio 1.30
--aq-mode 1 --aq-strength 0.60 --qcomp 0.70 --no-mixed-ref --deblock 3:3 --no-weightb --colormatrix smpte170m --colorprim smpte170m
--transfer smpte170m --level 3 --vbv-maxrate 1536 --vbv-bufsize 1536 --ssim --psnr
78.7 MB (82,542,808 byte)

x264 [info]: SSIM Mean Y:0.9897132 (19.877db)
x264 [info]: PSNR Mean Y:43.692 U:47.715 V:47.136 Avg:44.554 Global:43.909 kb/s:392.64
--profile main --crf 24 --bframes 0 --me umh --qpmin 20 --subme 11 --ref 4 --scenecut 60 --no-psy --ipratio 1.40 --pbratio 1.30
--aq-mode 1 --aq-strength 0.60 --trellis 2 --qcomp 0.70 --no-mixed-ref --deblock 3:3 --no-weightb --colormatrix smpte170m
--colorprim smpte170m --transfer smpte170m --level 3 --vbv-maxrate 1536 --vbv-bufsize 1536 --ssim --psnr
72.9 MB (76,471,495 byte)

main profileってマトリクス指定できないから俺は嫌いだな。

まあiOS用の480p動画じゃけん
HD以上なら俺もhigh（というか10-bit）使う

別にiOS用とか気にしなくても再生できるよね。
フルHDの60iもいけるし。
10bitは無理だろうけど。

好きなの使え
で終わるんだよなぁ

電池持ちと容量考えると利便性重視するとSDに落ち着くんだよなあ
無限に電池とSSD容量があって熱くならないならFHDでもいいんだけど

そうかぁ、俺は外じゃ見ないから関係ねぇなぁ。
自宅でPS3 Media Server + MLPlayer Liteでウハウハしてるわ。

123 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2013/02/07(木) 00:45:32.51 ID:Z90iabAU0
iPhoneで動画見る場合はPS3 Media Server + MLPlayer Lite使ってるわぁ。
有線PS3にはかなわんけど超便利。

うん、それ俺。
抽出してきた意味がわからんけど。

嘘じゃないんだからブレないよな

割れ厨かい

H.264は手軽なモバイル用途から高画質まで扱えるのがすばらしいね

俺はiOS用途には360pでエンコしてるわ
VHSとかmpeg1の時代からエンコしてるおっさんだから
そこそこ綺麗ならあんま気にしない

ふと
作成できる最小解像度っていくつだろ

おじさんはカーナビ用に512x288でエンコしてるよ

幼女「ふえぇ このスレ同じ名前のおじさんいっぱいだよぉ」

ふえぇ、"幼女"なんて付けない方が粋があるんだよぅ

さくらたんのエロ画像キボンヌ

しまった、ここは昭和のおっさんでいっぱいだ

2chの最南端、南極昭和基地　遊星からの物体x264スレへようこそ

>>264
南へ来すぎとるんじゃよ、南へ

http://www.youtube.com/watch?v=uckr60G5PaU

YUV10bitにすると表現できる色域が広がるってのが一番のメリットかな。
RGBじゃないから、ひとまず画面とかグラボの話持ち出してくるのは間違い。
がいしゅつですがいちようNE

でもソースは大抵 420の8bitじゃね？

劣化させないエンコならその理屈で通るんだけどね

突然何を言い出すんだ

隔離病棟へお帰りください

【洒落】アニメBlu-rayエンコスレ 101【PD】
http://awabi.2ch.net/test/read.cgi/download/1361262313/

バンディングって奴が10bit環境にする事で低減したりはしないの？
ソースの時点でグラデーションが帯状になってたら駄目そうだけどね。

10bit環境ってなんだよ？
10bitのエンコーダでバンディングの低減には有効
ソース由来のバンディングも10bitエンコーダなら高ビット深度フィルタ使って綺麗に消える

サンクスです。
環境って書いたのは、モニターも換えないといけないのかなーと思ってたので。
エンコーダとデコーダだけなら自分にも手を出せそうかな。

>>274
そりゃ10bitに対応したモニタに換えれば言う事ないが、金額的に現実的じゃない
しかし、今のモニタでも十分恩恵は与れる

>>273
実際全然消えなかったけどな。シュタゲとかであれこれ試してみたが

>>273
具体的なフィルタ設定を教えてもらえんだろうか。

>>277
f3kdb(dither_algo=2, output_mode=2, output_depth=10, keep_tv_range=true)

>>273じゃないけど、例えばこうやってみるとか。 この場合x264は、--input-depth 10にする。

最近は10bit対応のモニターもなかなか手の届く価格になってきたよ〜。
俺もまだ買ってないけどｗ

10bitのメリットがわかってない人が多い。

8bitの状態では、ディザが無いとバンディングが発生してしまうが、
エンコや、ましてNRは細部を潰すので、ディザが消えてしまいバンディングが発生する。
エンコする際にディザも保持すればバンディングは発生しないが(fgoとかがそのためのオプション)、
如何せん効率が低下する。

そこで、8bit→10bit変換をし、NRでディザの無いツルツルの状態にしてしまう。
で、そのままエンコ。 再生するときに、10bit→8bit変換をすれば、綺麗なディザが簡単に保持できると言う訳。

でもよく考えるとほとんど使い道がない

>>276-277
お前ら高ビット深度フィルタ使って無いだろ？馬鹿なの？
f3kdbやdither使えよ、10bitエンコーダで素でエンコしたって
ソース由来の階調割れなんて消えるわけないだろ、そう説明してるだろうが・・・

まーた10bitネタかよ

またかよいいかげんにしろよ

10bitじゃしょぼい

今は16bit

>>280
おまえリスクもちゃんと書いておけよ。
色数を増やしディザを再現すればするほど圧縮率が悪くなりデータ量が増えるってな。
データ量が増えるだけならまだしもエンコードに要する時間までかかるから実用範囲を超えている。

実用範囲を超えるってどんなエンコしてんだよ？ｗ

どんな？普通のエンコードだろ。それ以外に何があるんだよ？

動きが激しくベタや暗部の多いアニメソースを使うと
[email protected]の時は40fps前後でているものが
10bit+high10でエンコすると32fps前後ぐらいしか出なくなる。
fgoとnrを有効にして値を付加させればさらにfpsは低下するし
そこまで時間をかけてまでエンコードさせる意味なんて無いだろう。

なかには長時間エンコに時間を費やすぐらいならソースのまま残したほうが
まだマシっていう結論に至る人もいるだろうしな

あぁ、お前基準の実用範囲ね…くだらねぇ　1080ｐソースでfps15までなら十分実用範囲内だと思うぞ
後、fgoやnrなんてほぼ使わない、フィルタで16bit処理して、--input-depth 10で出力するほうが良い

>フィルタで16bit処理して、--input-depth 10で出力するほうが良い
おまえは黙ってaviutil使っとけばいいだろう。

素材の1/10fpsまでなら許容範囲だよね

>>290
発想が貧困すぎだな。なんでaviutilなんだ？ｗ
aviutilが悪いと言う事ではないが、俺はVapourSynthだな
お前必死こいてf3kdbやditherで検索して、aviutilで引っかかった口だろｗ

エンコ時間なんて放置してりゃいいんだから気にしたことないなぁ。
nrもフィルタ・プラグインが使えないさきゅばすとかでしか使わない。

>>286
10bitを支持するって内容では無かったんだけどね…

エンコード負荷が増えるっていうのはその通りだが、
圧縮率が悪くなりデーター量が増える、というのは、間違っている。
ディザの付いた8bitと、ディザの無い10bit、どっちの方が圧縮率(効率)が良いか、という話。
ちなみに結論を言ってしまうと、10bitの方が圧縮率が良い。
欠点は、指摘の通りエンコード負荷と、再生環境だね。

>>292
> なんでaviutilなんだ？ｗ
あほらしｗ
aviutilの内部は16bitだからにきまってんじゃん。

ぷぷっｗｗ

最近はスマホとPCで延々と自演し続けられるんだよな
IDは変えまくることも変えないことも簡単に選択可能だし

相当精神年齢低そうだな。頭の中は幼稚園児か？

>>297
あ、なるほど
そんな餌で俺様が…ｸﾏｰｯ!!(AA略

ワシのマシンじゃフルHDで5〜12fps程度ですがﾅﾆか？

私のPCはSDで7〜10ですが何か？？

ところでおまえら、10bitと8bitどっちがいいと思う？
忌憚のない意見を聞かせてくれ

何に対してか言ってないのにどっちがいいとかばか？

>>302
汎用性高ければ今すぐにでも10bitに移行したい。
でも現実は無理、8bit一択。
個人的にはそんな感じ。

俺PCでしか見ないから全然問題なし
10bit一択

avisynthから直接x264に渡すのにf3kdbや--input-depth 10ってまだいるの？

自分は10bit一択かな
再生環境で困ったことないし
携帯端末に落とし込んでみる場合は（ほぼないけど）それ用に変換するだけだから

いろいろ試して気づいたんだがパイプ渡しだとITSなどでタイムコードを指定してVFRなエンコをやろうとすると
度々失敗するんだ。x264のエンコード自体は正常終了扱いで処理されるが、仕上がった動画を視聴すると
どうも24fと60fと30fの切り替えがうまくいってない。仕方ないから毎回シーンチェンジごとにavsをtrimで分割して
あとでマージ処理するようにしているが面倒なんだよな。

>>308
ちゃんと--tcfile-in "timecode.txt"と--timebaseを付けてる？
でなければ後でtimecodeを埋め込まないとダメだぞ

>>309
当然パラメータの最後付近に張り付けているよ。

>>310
ふむ、おかしいな
俺の所では正常にVFRになる
EazyVFRだけど

特に多いのがアニメと実写とアニメの縦スタッフロール(60f)の混合ソース。
たとえばトランスフォーマーとか。

関係ない
鬼混合だろうが60のスタッフロールだろうが
avs2pipemodでパイプして先に吐いたTimecodeを正常に読み込むよ

>>306
必要
ffmpegsourse2等で読み込んだH.264もしくはMPEG2-TSの色空間はYV12で
avisynthの内部フォーマットはそのまま8-bit depth color YUVになるので
このまま10-bit x264に渡しても、8ビット深度YUVカラーの粗さの中間ファイルを10-bitでエンコされるだけとなり
エンコしてもディザリングが残ってしまう


　　　ソース(8-bit YV12)
　　　　↓
　　　x264 10-bit


f3kdbやGradFun3を使用すると
avisynthにおける2ピクセル分の情報を使って動画1ピクセル分のYUV色情報を記録した上でx264に渡してやれるので
16-bit YUVカラーの細かさの中間ファイルを10-bitでエンコできるようになる

これでRGB24モニタで表現される (2^8)^3=16,777,216色をすべて表現できる10-bit YUVでエンコできるので
8-bit YUVのようにディザリング（色階調割れ）が発生することもない


　　　ソース(8-bit YV12)
　　　　↓
　　　f3kdb／GradFun3(16-bit YUV)
　　　　↓
　　　x264 10-bit

>>306
8bitYV12ソースを10bitのx264でエンコするだけであればいらないよ、やっても結果は同じ

・10bitx264 --x264_Option -o "2ch.264" "2ch_8bitYV12.avs"
・10bitx264 --x264_Option -o "2ch_f3kdb.264" "2ch_8bitYV12(f3kdbで10bitに変換).avs"
この二つはバイナリレベルで完全に一致する264ファイルになる

10bitへの変換はこう、
f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, output_mode=2, output_depth=10)
これでソースそのままでただ10bitフォーマットに変換するだけになる

10bitのx264に8bitソースを入力すれば、内部で各入力値は256倍して16bitに変換された後、
今度はsierra2-4aでディザをかけつつ10bitに減色される
別にフィルタ無しでも効果は結構あるよ

つかディザをかけている時点でフィルタつけてんじゃん。

ディザさせずに10-bit x264へ
ttp://i.imgur.com/ckCBSjq.png

f3kdb(dither_algo=2, input_mode=0, input_depth=8, output_mode=2, output_depth=10, keep_tv_range=true)
で10-bit変換+ディザをを行ったのち、--input-depth 10 のオプションを付与した10-bit x264へ
ttp://i.imgur.com/EaV9xyB.png

>>318
エンコ前のSSは？

どっちでもいい（嘲笑

>>318
これディザ全く関係ないってことはないけどただデバンド処理しただけやん
このf3kdbの記述そのままならデフォの閾値でデバンド、ならびにグレイン付加処理される
ちなみにデフォの閾値だとアニメのデバンドとしては結構強い、シーンによっては細部かなり潰れるぞ

ディザは背景の輪郭が汚くなってる
却下

8bitで渡したらx264が10bitの720pに縮小してくれたら良いのに

ディザ8bitエンコとmadVRでもほぼ同様の効果にはなるから
各自の環境によって好きなほうを使えばいい世界だな

最初っから最後まで8bitYV12のままでエンコできないものなの

f3kdb(dither_algo=1, input_mode=0, input_depth=8, output_mode=2, output_depth=10, keep_tv_range=true)
で10-bit変換+ディザをを行ったのち、--input-depth 10 のオプションを付与した10-bit x264へ
ttp://i.imgur.com/dsB6gFQ.png

エンコ前（spline36resize使用）
ttp://i.imgur.com/UWgHjBN.png

今までsubme=10でエンコしてると思ったら
trellis=1になってたんで全部subme=9でエンコされてることが明らかになったんやな　悲劇やな

trellis=2にしたら糞遅くなったんやな

>>326
f3kdb の dither_algo=1 ではディザは行われないよ
単にLSB（Least Significant Bit：最下位ビット）を丸め処理するだけ

まあどっちにしろバンディングを消せることに変わりはないんだけど

>>325
8bitYV12のままでエンコするメリットがないような
UVの計算量が減るから早くエンコ出来るぐらい？

dither_algo=2だと若干強めの2DNRが掛かる感じなのか

>>330
dither_algo=2は、Ditherと同じordered ditheringだから、
低いビットレートで圧縮した後にも効果が残りやすいという事らしい。

>>331
フロイド-スタインバーグ・ディザリングとかordered dithering（配列ディザリング）とか色々な方式があるんですね

dither_algo
0: 8-bit processing (Deprecated, will be removed in future)
1: No dithering, LSB is truncated
ディザリングはしない、LSB（Least Significant Bit：最下位ビット）を丸め処理する
2: Ordered dithering
配列ディザリング（ピクセル毎に交互に色が並ぶパターンを生成）
3: Floyd-Steinberg dithering
フロイド-スタインバーグ・ディザリング（誤差拡散パターンを行うディザを生成）

* Visual quality of mode 3 is the best, but the debanded pixels may easily be destroyed by x264,
　you need to carefully tweak the settings to get better result.
一番綺麗なのは3やけど、x264でエンコするときに簡単に破損するから気をつけて調整しんさいよ
* Mode 1 and mode 2 don't look the best, but if you are encoding at low bitrate,
　they may be better choice since the debanded pixels is easier to survive encoding,
　mode 3 may look worse than 1/2 after encoding in this situation. (Thanks sneaker_ger @ doom9 for pointing this out!)
モード1と2はベストではないけど、低ビットレートでエンコするならデバンドしたピクセルも残るしいい選択じゃないッスかね
同じ低ビットレートの場合、3でエンコした方が悪く見えるかもかもしれないし

>>332
>簡単に破損するから
破綻の間違いでは？

単に負荷したディザが消えるのを破綻とは言わないだろ

NLmeansのこだわりの自縛から解放されたい
convolution3D一本に絞りたいなあ

>>335
俺はNL-means使うくらいならpsy-rd 0.5:0.0にしてsubme11 trellis2にするかな


規制の影響で人減りそうだね

NL-meansは色々と試してみたけど副作用のせいで使いどころがなくて・・・

最弱で掛けても細部潰れるから盲専用フィルタだよなｗ

小さい画面で見るなら別にいいだろ

x264とどこか関係あんの？

>>336
>NL-means使うくらいならpsy-rd 0.5:0.0
具体的にどのような効果があるの？
ソースは実写orアニメ？

試してみてはどうだろうか

>>341
初心者スレに比較上げられてるから見てみたら

res thx!

細部を残したい場合に使うんだね
自分でも下記のエンコオプションをベースに試してみたが、0→0.5にすることで、ビットレートの20%の上昇と
モスキートノイズの発生率の僅かな上昇と引き換えに細部の残存率が改善した
--input-depth 16 --profile high10 --crf 17 --qpstep 20 --qcomp 0.8 --rc-lookahead 80 --vbv-bufsize -1 --vbv-maxrate -1
--aq-mode 3 --aq-strength 0.45 --psy-rd 0:0.35　--keyint -1 --min-keyint 4 --bframes 16 --b-adapt 2 --partitions all
--me tesa --subme 11 --merange 24 --direct auto --ref 16 --trellis 2 --colormatrix auto --colorprim auto --transfer auto

ただ、NL-Means Light for GPU(5 3 25 5 3 25 100)を切ると、ソースに含まれる多量のモスキートノイズが残りすぎて残念な結果になった
BD等のまともなソースだと切ってもいいのかもしれないと思った

NL-Means人気だな百害あって一利なしなフィルタだと思うけど。。。
HQDN3D（1or2） これが一番しっくりくるな

古いセルアニメなどには使えると思うが
ディテールや階調を飛ばすほどの価値があるかどうか疑問

>>344
すまんな
--psy-rdはデフォの 1.0:0.0 を基準に0.5に下げれば実質デノイズ効果があるからって意図だった

他人の設定とかこだわりとか見るの勉強になるなあ
俺はずっとconvolution3D(preset="animeHQ")一本だけど（時間軸NRで残像が少なかったので）
CPUとGPUに余裕があったらNL-means使ってたと思う
細部なんてどうでもいいからのっぺりさせたいんだ！ノイズがあるなんて絶対に許せない！っていう欲求はどうしてもあるので

実写だとどこらへんまでがノイズなのかわからんからそれを除去するのは非常にむずい

距離的に
21.5型フルHDPCモニターではCRF20欲しいけど
32型のフルHDテレビではCRF22で十分

最近の実写ハイレートソースはveryfastでいいよもう

x264全然関係無いけど、NL-means使うんだったら、NLmeansCLかDeathray使えば良いと思うよ

デフォルトで付属してるやつで十分です。

>>344
crf17にしてる理由ってなんですか？
自分はアニメでcrf18にしてるんですがblu-rayエンコ例のcrf16設定を見てやっぱり下げた方がいいのかなと思ったんですが
やっぱり17くらいの方が綺麗なんでしょうか

crfは低いほど良いんだ、自分が許容できるサイズまでモリモリ増やせ！

18で十分過ぎる

>>352
crfの値を小さくすることで圧縮時の画質低下の程度が小さくなるけどファイルサイズが大きくなってしまう
17という数字は魔法の数字ではなくただの妥協点だから気にしなくていいですよ

ありがとうございます、勉強になります

HD･FHDなら18で十分だと思う、qpminの値もちゃんと設定しないとcrf下げても意味ないし。
それ以上画質上げたいなら、psy_rdやsubmeの値上げるとかBフレの枚数減らすとか10bitでエンコするとか。
psy_rdもそうだけどx264のオプションぐらいならggれば説明してる所がいくつかある。

BDに焼くなら容量は考えないとな…まあそれならｃｒｆじゃない方が調整しやすいだろって話も有るが

実写はcrf 22ぐらいか？

crfの値だけで語っているが、--qcomp 0.8 とデフォの 0.6では
crf で言うと 2 ぐらいビットレートが変わるぞ。

crf18以下にする場合はまず--no-mbtreeでmbtreeを外してるな
そのぶん容量は増えるが

crf19以下なら
俺はtrellis 1にするな

crf18でSSIMが0.996ぐらい出てるな.
いいんだかわるいんだかわからん.

crf下げるよりpsyとaq調整して細部残しつつサイズに気を付ける
ほうがバランス良くならないか？crf下げて他のオプション妥協
すると細かい部分がう〜んみたいな

>>364
ためしにどんな感じです？

crf下げてもpsy_rdが0だと細部やディザが保存されないからね。
ツルツルなソース以外だとモリモリ容量増えるけど、
ノイズや階調割れ対策の為に細部保持はした方が良いと思う。

まず(サイズが比較的小さいPsy-RDO 0で)サイズが比較的変わりにくいAQとPsy-Trellisを調整する
それで満足できなかったらcrfを下げるPsy-RDOを上げる等をする

細部よりも圧縮優先＼(^o^)／

上の出たようなことを試行錯誤してたらいつの間にかデフォルトに戻ってたのは昔の話さ・・・

crfは19.0固定で、qcocmpを0.7とかにしてるわ。

[x264-devel] x264 Development Newsletter: Vol 35

http://mailman.videolan.org/pipermail/x264-devel/2013-February/009899.html

r2273

今回の更新はいろいろ高速化してるようだけど、どんなもんかな
r2145の時みたいな致命的なバグがあるかもしれないという先入観がｗ

高速化とな
それは楽しみだ

相当劇的な感じがするなー。
AVXが大分活用されるようになったのもポイントかな。

俺のエンコマシンはAVX非対応だけどな。

[email protected]ｚOCだけどもう少し頑張る！

x264でドロップのあるファイルをエンコードすると全ての部位において音声が欠落するなんて事、ありますか？

>>377
x264でできるのは映像のエンコードであって、音声に関しては何も出力されないよ。

音声は別に用意して、muxする必要がある。

FHD,30fpsの動画を可逆で圧縮してみたら圧縮比が5.36もあってﾜﾛﾀ

>>378
なるほど、音声は別のソフトでやって後からくっつけるのですね

AVX非対応CPUの俺に隙は無かったぜ

nlまだ更新されない

crfよりもqp派な僕

今からDTVやるならAVX対応だけは買っとけ

>>382
jarod氏のスクリプトが死んでるみたい。何回呼びかけても返事してくれないし。
ttp://x264.fushizen.eu/builds/revision2273/
もう朝からビルドをいつもの場所で置いてるけど

アニメを1280x720⇒PSP(480x270)に再エンコするのが平均65fpsだったのが70fpsになったわ
きちんと検証してないからあれだけど、少し早くなった感じ

>>385
�d

2273来てたのか
高速化楽しみだ

2パスの1パス目がかなり速くなっているみたいなんだよね。
SandyBridgeでというのが気になるがｗ

2パスはよく使うので期待している。

むしろ現用してるがAVX未対応機なら、6月のhaswellを待つべきではなかろうか

haswellのAVX2もSSE2の時みたいに出始めは遅かったりして

AVXの時点で256bit演算器入ってるから大丈夫だよ。きっと

で、結局どのバージョンがいいんだ？

拡張命令って何で使うと微小ながらサイズ増えんの？
マルチスレッドのスレッド数による弊害と似たようなもの？

自作板のエンコベンチスレに2230と2273の比較が出てたけど
まったく変わってないのですが・・・・・

いまはJEEB氏の2245で頑張ってる。これといって不満がないから困る

OpenCL版使ってみたけど高速化の効果がほぼねーな

SSIM Mean Y:0.9987260 (28.948db)

film crf10 で遊びエンコしてたらこんな数値でてきて焦った。

猫科たのしみです

にゃ〜ん

CUDA対応でシーンチェンジにはキーフレームをぶっこんでくれるx264.exeまだぁ？

あんま興味わかないなぁ

CUDAらないな

おなかCUDAしてろ

CUDAらん流れだな

お前たちの話は本当にCUDAらん

こんなところでCUDA巻いてないで仕事しろ

いい加減スレ違いはやめてCUDAさい

もうやだこのCUDAり

おら東京さいCUDA

CUDA…　管直人

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／　 　 　 　 ＼
　　　　　　　　　　　　　　　　　　　　　　　　＿　　 　 /　 　 　 　 　 　 ヽ
　　　　　　　　　　　　　　　　　　 _.メ'￣￣＼　｀ﾞイ⌒ ＜｀ヽ、　　　 　 .}
　　　　　　　　　　　　　　　　ィ‐ﾍ　 ＼　　　 ｌ　　 ｀ゝ､ノ　　/　　 　 　 ﾘ
　　　　　　　　　　　　　　　/　.|　ﾍ　　 ＼　 .|　　　　　ﾍ　 /　　　　　 /
　　　　　　　　 　 　 　 　 /　　{､＼＼､　　ｌ　|　　　　　 ﾊ　| 　 　 　 /、
　　　　　　　　　　　　　　{　　|/ ＼_､ァ≠N∨､　　 ト、　l　|　　 　 /.ハ
　　　　　　　　　　　　　　|＼ |ｲ､　　ｲ灯〉l}　　ヽ　/ ﾉ　 .| ﾍ　　　 ｀　 .|
　　　　　　　　　　　　 　 圦 |f示　　 ゝ-'　　 　 |　| l　　 !　 ゝ､　　 _／
　　 　 　 　 　 　 　 　 　 ﾍＮ弋ﾘ　　　""　　 　 !,/./　 ./　　　　￣
　　　　　　　　 　 　 　　 　ヽV"　_.ノ　 　 　 　 　 /　／'ア　CUDAぽよ〜
　　　　　　　　　　　　　　　　 }ゝ-　 ＿_, -､_.ﾊ=＜-､_／ｱ
　　　／⌒ヽ　 ／ｱァ　　 /ｽﾉ 　 {､_　 ≧◎≦　| ＿}／
　　_{／ニﾞヽ!ｲ＿／ 　 　 ヽ、__／｀゛{__乂 乂　 .}´‐‐l′
／斗ｲｰ'　l__| ／ ﾍﾌ､＿＿__／_／　| 　 爻　￣/ .／
!_{ =＝＜.> ◎ ≠ｰ'ー─-ﾆ.〉　 .／￣≠─／ /
　　　／ｼ"￣ゝ"　　 　 　 　 　 ／⌒ヽ, _＿_｀¨ﾍ
　　　￣　　　　　　　　　　　 ／⌒ヽ＿＿　　￣｀丶
　　　　　　　　　　　 　 　 　 ＞ー-r ..__　 ｀ﾞヽv'⌒ﾞヽ
　　　　　　　　　 　 　 　 　 　 　 　 |　　|￣f─‐r‐一’
　　　　　　　　　 　 　 　 　 　 　 　 }─‐l 　ﾍ 　 ヽ,
　　　　　　　　　 　 　 　 　 　 　 　 〉 　 {　　 ﾄ─''{
　　　　　　　　　　　　　　 　 　 　 　｀ー"　 　 ｀ー'

まさかここでgdgdが来るとは思わなかった、予想外

Haswell来るまで当分こんな流れだろ

その頃には話題はx265(仮称)になってるだろ〜
あと今のメインが3930kだからAVX2があんまり良いとエンコ性能+単コア性能か拡張性+多コア性能か迷わなきゃいけないから困る
haswellの後にivy-Eが出るとか誰が考えたんだよホント…

[email protected]ｚがメインなのですごく悩みます

x264でエンコしたと思われる動画でも、エンコードパラメータが記されてない動画があったんだが隠す事ってできんの？

ダウソ厨のビルドだろ

そんなんあんの？

できるし、やり方どっかで見かけたけど忘れた。
別に設定隠す必要ないしね。

昔このスレで上がってたよね確かyoutubeの再エンコ形式がwebmからx264になってたみたいな話題の時
探す気にはなれんが

というか、バイナリエディタで開いて、エンコパラメータの文字列を好きに改変すればいいだけ

>>415
ivy-Eはスキップされるかも？ って憶測もあるけどね。まだ噂の域にすらなってないが

>>422
とある連中が\0で埋めてたのを思い出したわ。（ヒント：規格違反）

そんなに設定等を書き込みたくないならx264をパッチした方が全然いい。

だがマジでそうする理由が見えないんっすけど。

エンコード開始と終了時刻、スレッド数とオプションで
使ってる糞PCのスペックが類推されて恥ずかしい

どっかの動画にコメントを書きこんで喜んでる連中とかが
その動画のx264パラメータの特徴をみて誰がアップしたか判断するから隠したいとかじゃないかね？
自分用にエンコするだけならパラメータなんて隠す必要は1%も無いわけで。

Iフレームから無劣化切り抜きしたら.264ファイルからパラメータは消されたな

パラメータはこれで消せる
https://github.com/VFR-maniac/x264_DANGEROUS/commit/fc645fa1881f70b6b8bbc59c0232fc99d56dbf79

URIが触れてはいけない空気を漂わせているな

晒していこうよ！

Thread=2の僕は隠したい派

1Coreでも気持ちとエンコはThread=18でいたい

>>431
マルチスレッドによる画質低下を嫌ってThread=1でエンコする輩もいるんだぜｗ

AMDだけどi7みたいな高性能貴族CPU使ってるって思われたい

AMDにはぺヤング超大盛りみたいな笑える多コアCPUがあるだろ

16coreや12coreのオプテのことを言っているのかね？

オプテは32coreイけんだろ
もういっちょイくー

>>433
お薬が必要なレベルだな

HT切って6並列でエンコしてるわ
2回で1クール

使用したライブラリ : x264 core 47 svn-532
エンコードライブラリの設定 : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=5 / brdo=0 / mixed_ref=0 / me_range=16 / chroma_me=1
/ trellis=0 / 8x8dct=0 / cqm=0 / chroma_qp_offset=0 / slices=4 / nr=0 / decimate=1 / bframes=2 / b_pyramid=0 / b_adapt=0 / b_bias=0 / direct=1 / wpredb=0 / bime=0 / keyint=250
/ keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1085 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

古い頃のコマンドラインを見てると感慨深い物があるんやなｗ

L-SMASHが更新されない

あんたがフォークしてもいいのよ？

r2273きてたのかAVXじゃないCPUでも高速化されてるのかな？

最近、どんなパッチ当てバージョンがあるのか整理できなくなってきた
MixAQ以外に革新的なものってなんだろう

2パス試してみたけど、2273になったら2245比で24分くらいのアニメで3分ぐらい速くなった。
fpsでは7fpsぐらい向上した（1pass目）。
設定はanimationでfastのプリセットに、スマートレンダリングのままTMSR4で食える程度に
いじったぐらいだったと思う。

OS:Win7 Home 64bit
CPU：i7 860（定格）
RAM:16GB

2パス使いの人にとっては結構大きいと思う。

%ではどれくらい？

3fps→10fpsなのと80fps→87fpsなのではだいぶ違う
…計算できなくもないがかなりめんどくさいので

POP氏のL-SMASHって10bitはやってないのかな

コメで要望出してみるとか
10bitならたくあん氏のを使うって手も

ありがと
探してみる
いつもお世話になってる所が
全然更新されなくて

POP氏がr2273ではなくr2274なのは、前者に致命的なバグがあるということ？

>>450
ARMに対するバグFIXの違いだから
x86系だとどちらを使っても問題ないはず

r2230から画質的な改善はあったの？

速度が改善する→同じ時間でより重いオプションが使える→画質改善

重い設定を試す
容量が増える
以前の設定で近い容量まで盛る
あれ、こっちの方がいいかも
戻す

>>446
確認したけど、ソースによって結構変わっているね。
5〜13fpsぐらいの変化があった。
まぁ、同じ番組の違う回なので定性的な話に留めてもらえれば。

割合としては最大で22％くらい向上したかな。（58→71fps）
ちなみに、2パス目はほとんど変化ないです。1パス目の
演算を簡略化したということかな?

r2245からr2273にしたら速くなったような気がする

ちゃんと時間はかってみると実際少し速くなってるよ

実写dvdの消化作業のときは
veryfast none 23をベースにすることにした

スマホでアニメを消化するときは360pでcrf23かな。

流石にもうちょっと頑張ってやれよ

720pで

古いスマホなんだろ、そっとしといてやれ

スマホ変えたら強制的に4Gにさせられるじゃないですかｰ(´・ω・｀)
3Gで十分なんですよー迷惑ですよー通信料下げろよー(´・ω・｀)

銀河IIIだよ！！

さだまるってx264のビルド辞めたの？
なんかニコ厨になったみたいだけど

>>463simフリー+イオンsim+willcomにしよう(提案)
俺はmixaqさえ当たってればどこのでもいいかなぁ。目ぼしいのが無いなら自分でmakeしようぜ

>>463
3GスマホでもHD解像度のはあるだろ

>>464
チョンかよ

ドコモはぎゃらくち〜ぐらいしか良い端末が無いからな。
最近はアンドロイドもマシになってきたけど。

>>468
林檎信者は情弱

鋭の吉幾三電話が電池餅いいと効いたが

>>469
別に林檎信者じゃないよｗ
iTunes大嫌いだし。
どっちかって言うとシャープ信者。
シャープ頑張れ。

SHARPはもう死んだ

それはそうと実写エンコする時ってどういう設定にしてるんだ皆は

>>472
--crf 22 --vbv-maxrate 16000 --vbv-bufsize 16000 --min-keyint 4 --keyint 300 --tff --deblock -1:-1 --direct "auto" --qcomp 0.7
--me umh --subme 9 --merange 24 --weightp 0 --b-adapt 2 --trellis 2 --fade-compensate 0.7 --no-dct-decimate --8x8dct --level 4.1
容量がソースとほぼ同じになることもある誰にもおススメできない設定（ｗ

実写なんか--crf 26でええやん

ディテールが単純な事が多いアニメと違って実写でcrf欲張るとどうしても太るからな
どこまで我慢できるかはその人次第だが

20〜24

実写はcrf24固定で物によってqcomp0.7にしたり0.6にしたりで調整してる

>>463
っ acro HD祭り

実写でもエンコするならインタレ解除する派
ノイズフィルタ強くかけて圧縮されやすいようにしたいから
のっぺりでもええやん
crfは25

俺も同じような感じ、実写は画質こだわらないし
アニメではありえないってくらい強めにノイズ除去フィルタかけてcrf25であとはほぼデフォ

アニメも画質にこだわってないじゃん

勘違いしてない？
アニメだとノイズ除去フィルタは細部が潰れないよう注意して強さ調整してるしcrfも16〜18くらいにしてるよ
実写だとフィルタの調整なんて適当、大体bobして強めにノイズ除去して終わり

日本語難しすぎﾜﾛﾀｗ

勘違いなんてしてないけど

×アニメでは、ありえないってくらい強めにノイズ除去フィルタ
○アニメではありえないってくらい、強めにノイズ除去フィルタ

どっちでもいいよ
見たくないエンコだし

アニメとは違って、ありえないってくらい強めにノイズ除去フィルタ

どっちでもいいよ
見たくないエンコだし

実写は縮ませないとエンコする意味ないし、
いかに圧縮されやすいようにするか、しか考えてない

強度なノイズフィルタどころか、960x540 ぐらいに
しちゃってもいイイじゃんな感覚
風景を楽しむ番組はエンコしない

x264は煮詰めないで速く終わるプリセットしか使わない
再生環境に合うように微調整するだけ

便利なプリセット増えないかな

誰の参考にもならない俺的やり方披露する意味がわからない

いいぞお前らｗｗｗ もっと暴れてこんな糞スレ二度と使い物にならないようにしてやれｗｗｗｗｗｗｗ

アニメでmbtreeをonにすると一定以上暗いシーンや、明るいシーンでも薄い線を盛大に潰してくれるのは困る
nombtreeでqを2つほど上げるか(容量変化を抑えて明るいシーンをやや犠牲にして暗いシーンの質を上げる）
シーン別で分けてエンコするのがいい

誰の参考にもならない俺的やり方披露する意味がわからない

>>490
坊やだからさ

アニメ脳キモい

お前はどうなんだよ

>>493
お前以外のエンコの参考になってるんだよ

まぁ確かに他人が何を基準に設定を
決めてるか参考にはなるな。

アニメはありがたいもの
神聖に取り扱わなければならない

クッサイ流れ

まったくだ

自称アニオタのJEEB氏かもしれないから丁寧に誘導して差し上げろ

実写はノイズリダクションよりぼかしかけたほうが縮むぞ

実写でもインタレ解除というが普通は素材にかかわらずインタレは常に解除するもんなんじゃ
そもそもプログレ素材ならインタレ解除なんて概念は関係無いし

俺的やり方は参考になるが、個人で楽しむ物を横から困ると言われても困る。

>>504
手っ取り早さ優先でそれなりに縮めばいい場合とかは保持するかな。

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 争　　も　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　争　　 ＿
＿ 　え　　っ　　＿ 　 　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、 ヽ| : i : : :,　　 　 ＿　　　 え　　 ＿
＿ 　 ：　.　と 　 ＿ 　 ／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　 ：　 　＿
＿　　：　　　 　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　 ＿　　　：　 　 ＿
　　　 　　　　　　 　 〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ¬ト､: :| : : ! : : : : :,
／　　　 　 　 　 ＼　　 /.: :/.: : : : /ｌ : |/Гト､　　 　 　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　 　 　 　 ＼
　／　 |　　|　　＼　 　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　 　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　 　 　 ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　 い、: :＼/ 　￣￣　　　　 　 　 　 　 　 　 ', : : i : : : : : : : : ,　　　　 _, -‐'　 　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣ フ 　 　 　 　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　 　 くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　 　 　 　 　 　 ／| : : :i : : : : :_, -‐'　 　 |　 ／
　 　ｒ―'　　　ヽ、 　 　 　 　 　 　 | : : : ＼　　　　　　　　 　 　 　 イ: : :| : : :i_,. -‐　　　　　　 |／
　 　 ｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　 　 .:〔: : :|: : :r┬'

60ｐがもっと当間の世界になると良いと思います。

ソースが480/60iなら維持でやるかなあ
HDなら解除して720pにリサイズする
といっても実際には純粋にインタレースの実写ソースエンコする機会俺はほとんどねーな
実写はほぼ映画や洋ドラとかなので、単に逆テレシネだわ

音楽ライブやスポーツものは頑なに60p化してたけど、
もはや再生側のインタレ解除に任せておけばいいと気付いてしまった俺。

>>510
アプコンもそうだけど、補間系のものはやるだけ損だなｗ
環境依存が回避できるだけで、特にメリットはない

ポケモンとかルパンとかの古いDVDがソースだと思うように縮まんのがつらい

H.265とか基本的にはプログレッシブだけの規格に備えるのもあり

無駄とわかりつつQTGMCのbob化した映像に萌え

QTGMCならGPUでやるより高精度だから良いけど、時間が恐ろしいな
yadifなら速いけどGPUより精度低いから微妙

Haswellでどれだけ加速するか楽しみでしかたないんだけど、このwktkをどうしよう

IYH力に変換するんだ

右手の加速に変換するんだ

猫科キターーーーーーーーー

temp.avs-x264->temp.264-mp4box->out.mp4
だと一部で映像が破綻するのに、
temp.avs-x264->temp.mp4-mp4box->out.mp4
だと映像が破綻しないのってどういう理由なの？

大自然の摂理

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

また古いネタを･･･

さわんなカス

最近更新もスローペースになってきたな

エンコってもうオワコンだよね

だよなー
偽女子高生物ばっかりだ

androidタブレット用に60fpsで新規にエンコするようなった
まだまだおわらんよ

60p化に手を出すと、qtgmcのクオリティに心を奪われて泥沼にはまるわな

録画運用もだいぶ最適化されて
落ち着いちゃってるんだろうな

最近は10bit化が進んでるようんだな
エンコ処理が2重になるから(ソースがそもそも無圧縮じゃない)10bit必要なんだけど
出力環境が整ってないんだよなあ(´；ω；｀)ﾌﾞﾜｯ

日本語で頼む

上の方でディザかければいいとか言ってるけどディザはそもそもノイズなんだよな
昔の16bitカラーのディザ使った壁紙やCDプレーヤー(SONYのスコアデジフィルやTEACのZDフィル)でもその弊害が認められてたし
諸刃の剣だった
10bit化は丸め込み誤差も含め損得勘定でメリットが多いのでやるべきなんだが…(´Д`;

フーリエ変換の圧縮技術見れば分かると思うけど
2重変換では今まで出なかった階調部分のbit深度が足りなくなってくる
8bitだから変わらないというのは嘘だ

フーリエ変換って、CTとかMRIにも使われてるんだよね

まあそういう弊害も含めATiのディザ技術で出来た動画画質は昔から好みだった訳だがｗ

いずれにせよ、Y'CbCr 10-bitの方が、Y'CbCr 8-bitよりもRGB 8-bitの再現性はよくなるから、
今の出力環境でも十二分に利点はある。

8bitが8bitの色域すべて有効に使ってくれれば何ら問題はないはずなんだがな

ロスレスエンコならいけるんじゃね

>>538
RGBのままエンコードするのでないかぎり、色空間の変換を間に挟むとどうしても限界はある

http://csbarn.blogspot.jp/2012/01/converttorgb.html

総天然ショック

4096色

大滝詠一 - 君は2^24色

i420よりi444の方が縮むんだね

でもカーナビで再生出来ないんだ・・・

それと8bitより10bitの方が縮むのね
bit数増えるのに
でも10bitでi444となるとエンコ重いなぁ

rawデータとして見れば10bitのほうがデータ量多いけど
より圧縮しやすい形態になるんで結果的に出力データが縮むって感じ

>>546
分解能が上がった方が視覚的品質を維持して圧縮するのに都合が良い値を取りやすいって事かしらね。

利き酒 利き米 利き水 利き炊飯器

10bit+i444綺麗だなぁ
特に階調が綺麗でBDソース以上だわ
時間軸NRだけかけててこれがディザの役割を少ししたっぽいけど
二倍重くなるしスマホで再生できなくなるから採用は見送りだけど…
i444だけでも十分綺麗だったけどAndroidじゃこれすら再生できんかった…

BDソース以上（）

元ソースは一体何なんだろうね

おお…　BDソースが一番高画質と思ってるのがいるのか

一般人がアクセスできるソースでそれ以上のものがあったっけ。
まあそれも違法になっちゃったけど。

タブレット買ったから久しぶりにエンコするようになったんだが
crfを16まで下げて出力するようにしたら元ファイルとそこまで変わらないことに気づく (´･ω･`)
久しぶりにやると何故か下げたくなるから不思議
CMが無いチャプター付きファイルと割り切るしかないと思ってきた

タブレットでエンコする、まで読んだ。

ウォシュレットでウンコする、まで読んだ。

>>555
タブレットは画素小さいから画質悪くてもノイズ気になりにくいからcrfは高めで良くない？
crf22でも十分だったけどcrf20aq0.5でしてるや

地デジなんかソースが粗いのにcrf16なんかで出す意味がわからない
BDならまだわからんでもないがそれでも16はやり過ぎ

既に圧縮工程を経てノイズまみれになってるんだから
その時の圧縮よりも丁寧な圧縮にしないと品質維持はできんし、本人が納得するならいくつでも構わんだろ
さすがに元サイズを超えるようだと再エンコードする意義がかなり薄くなるのは間違いないが

うん。さすがに俺も16はやりすぎだと思った (´･ω･`)
圧縮メインじゃなくPC兼用の保存用として作成してたからつい下げてしまった
さすがに24分のアニメで1GB超えて出てきた時はワロタ

古いアニメや動きの激しいのはcrf18でも1G超えゴロゴロしてるけど

というかcrf20でビットレート変動率80くらいにして出したら画質的にはもう十分だと思うんだが

十分っていうか、結局どのレベルで妥協するかだと思うわ
フィルムのグレイン維持したいとかだとかなり厳しいんじゃね

ノイズエフェクト乗っけてきてる作品はできあがりサイズがうはーｗってなることが多いね

バイオハザード4の自撮りシーンは知事マン

crf16ってやりすぎか？アニメだと毎回17ぐらいで出力してるな

出来上がりの分あたりの容量いくつなのさ
モノによっちゃcrf20でも30分で1.3GBくらい行くぞ
例を挙げるとなのはMOVIE 2nd本編が映像のみで5GBくらいになったからな

地上波のアニメの話をしてるのにBDソースの劇場版の話をするなんて...
比較対象にならないと思うのでお帰りください

地上波ならなおのことcrfの数値下げる必要性無くね？

それを言ったらBDをわざわざリップしてまでエンコする理由がわからんけどって言ってるのと一緒

容量抑えてHDDに収めて気軽に再生できるようにするっていう目的がある
ただ取り込んだだけだとHDDの転送速度が間に合わなくてスムーズに再生出来ないから単純にエンコでビットレート落とした方が見るだけでも楽だし

>>572
BDのレートが出せないHDDって、何時のHDDだよ・・・

WDのGREENだよ回転数可変のやつ
MPCHCでそのまま読み込ませると時々カクつくし読み込み遅いんだよ

フラグメント化起こしてるんじゃないの

SSD以外は全ドライブOSが暇見て勝手にデフラグやってるからそれは無い

地上波 23
円盤 18
にしてる

>>576
デフラグしすぎて、クラッシュしかかっているんじゃないの?

>>574
Crystal DiskInfoとかでSMART見てみ。たぶん壊れかけてる。

SMARTも異常見つけたら勝手に通知するようになってるっつーの

ていうか通知機能ちゃんと動作しなくても普段からI-Oのガジェット使ってるから異常あったら目に入ってくるわ

後出し満載

回転数可変なんて言ってる時点で自作板だったら釣り確定してる

>>583
なんで？
倉庫用ドライブなんて大容量で安価な可変ドライブで十分だろ

そもそもがHDDが正常なの前提で話してるのに後出しもクソも無いだろ

可変なんてまだ売ってるのか？とっくに寿命切れてるだろ
あとリップしたのをエンコしてるのに
何故消さずに残してるんだ？
割れ厨？

>>586
「取り込んでそのままだとスムーズに再生されないからエンコしてる」
がどうして
「エンコしたのにソースを消さずに残してるんだ？」
になるのか説明してくれ

俺もGreen持ってるけど転送が間に合わないことはないし再生はスムーズだよ
SMARTに問題がなくても低速病が起きてると遅くなるからそれだったらちょっとまずい
あとはCPUのスペック不足かもしれんがね

因みに俺はBDはタブレット用にエンコしてる
暗部とかのザラザラしてるのを保持しようとするとかなり膨らむから除去して300MB程度にしてるわ
除去のせいでブロックノイズ出るけど時間軸NRでチラつき押さえるからPCで見てもかなり綺麗
7GBから300MBにしてもかなり綺麗なんだから凄いよなぁx264

もしかするMPCHCのBDMV再生機能が未熟って可能性もあるけど市販のBD再生ソフトは持ってないし買う気も無いし
CPUは確かに化石だけど流石にスペック不足というのは考えたくない。QX6850
実写ソースとかだと暗部ノイズ残ったままのBDとかあるし結局はエンコするから別にいいっちゃいいんだけどな

いまどきCore2世代のCPUとかゴミじゃないですか。
ハードウェア支援なきゃ下手すりゃBDのビットレートのH264の再生すら危ういレベルだぞ、それ。

BDってせいぜい40Mbpsくらいだろ？
つまり5MB/sだ
シーケンシャルリードがそれ以下ってのはいくらなんでもないわ

PIO病みたいなのじゃなくて？

DXVA完全に切ってMPCHCで読ませてもCPU使用率は一番残念なコアが60％ぐらいまで上がる程度だけどこれでも再生危うい状態なのか

3.2GHzの2コアあれば再生出来るから4コア3GHzなら問題無い

光学ドライブより遅いHDDっておかしいと思わないのかな

どうもMPCHCのLPCMフィルタがおかしいだけだったわスマン
問題なく生のBD再生できてる人らは何使ってんだろうか。fffdshowのLPCMもちゃんと仕事しないし困った

BDドライブにバンドルされてたの使ってる

WDが好きでいつもGREEN指名買いしてるけど、ID:0xv2cPJnみたいなことにはなったことないなぁと思ったら
やっぱり別に原因があったか。

>>593
うん、危ういね

ここx264スレだよな・・・？

BDドライブバンドルのやつは使いづらいしMPCHCで再生できるならいらねーかって消したらまさかのLPCMフィルタが使いものにならないとかマジで勘弁してくれ
ディスクももうどこやったかわかんねーよ

やけに伸びてると思ってきてみたら。

Blu-rayソースの最近のアニメならもうcrf23で十分だわって思うようになったわ。

>>599
intelの6コア以外はゴミだよな

E5,E7「…」

Haswell待機

周波数は上がらないしコア数も増えないしインテルはジリ貧だな
AMDも大赤字らしいし
グラフィックスを強化している場合やないで！

うるせえムーアの法則の方が大事なんだよ！

>>606
元々半導体の限界だからIntelに限らず全体に影響するよ
マジでどうにかしないと進歩が止まる

大体1GHzだと1クロックで光が30cmしか進めない時間なんだぞ
その間に命令幾つ実行されてんだって思ったら凄いと思うと同時に
もうそれ程余地が残されてないだろうってのも思う

世界中の平均的な家庭で動かせるように作ろうと思ったら
これ以上電力馬鹿喰いさせるわけにも行かないので、いろいろと難しい
日本でもネトゲの最中にブレーカー落ちたって言う、アホがたくさんいるくらいだからな。

>>609
数十〜百GHzになると電子の個数が少なく なりすぎて、
バラツキで不安定になるって話が出てる

早稲田大学、「半導体LSIの高速化限界は 流れる電子の数によって決定される」
PC Watch http://pc.watch.impress.co.jp/docs/news/20121210_578010.html

デジカメで暗い所を撮影するとノイズが載 るのと似たような理由だな
暗いと光子が少ないのでバラツキが相対的 に目立つ（光ショットノイズ）

>>611
100GHzだと、電子（光）が1クロックで3mm進む時間となるが
チップ内回路だけでもオーバーするんでないの？
まして基板の回路（BUS)まで含めると大事になりそうだが

100GHzで駆動出来るほど微細化が進んだ場合の話でしょ。
いくら微細化しても電子の影響で動かなくなると。

AVX2絡みの更新がたくさん来ているな

クロックはもうこれ以上上がらないと考えた方がいいし、微細化も物理限界に
そろそろ達しそう。

なので、今後はダイサイズを大きくしてでも並列度を稼ぐ方向に行きそう。
ちなみに、Xeon Phiに載っているCPUは、クロックが1.1GHzしかないけど60コア。

H264ももう時代遅れか〜

なんだ、ID:IB8Y92UAは知恵遅れか〜

perlを入れていないから試していないけど、今回のr2309からはopenclも有効になっている

mukenって逮捕されんの？

なんで？

.nlにr2309来てるよ
チェンジログ読んでてweightpはインタレに対応してないことを思い出しますた。

.nlからDLするのは何か理由があるんですか？

半公式だから
そして自ビルドは億劫

>platform: X86
>bit depth: 8

これ以外の条件でもOpenCLは使えるようになるのかな

>>624
一応64bitでも使えるけど、SDKを検出するスクリプトはなぜかこけて（ｒｙ
>8bitの事はワカラン。

どうも 今後の更新に期待します

>621
一瞬、weightpがインタレ対応になったかと思っちゃったじゃないか(深読みしすぎ

opencl、あんま早くならないような。むしろ、遅くなる気が。
CPUとGPUの組み合わせにもよるのかねえ。

64bitでOpenCLが使えないのはconfigureがおかしいせいだった
1128-1137行目のelifをコメントアウトすれば64bitでもOpenCLが有効化できる

>>627
前々から言われてるけど、x264のOpenCLでGPUにオフロードされるのは、
lookahead部分の処理だけで、エンコードそのものはCPUでしか処理してないからな。

MAXで1割位しか、速くならんよ。
その1割を大きいとみるか、小さいとみるかは人によるけど、
OpenCL爆速Yeah!を期待しても無駄だよ。

マクロブロック単位で並列化とできないの？

ありがとう、それで上手くいった

>>627
確か、速いプロファイルほどOpenCLの効果は大きかったと思うから--preset veryfastとかやってみれば？

×プロファイル
○プリセット

openclのconfigureがおかしいのはおそらくたくあん氏と思われる人がgithubに修正patch
当てたの公開してるのを見つけた

日本語で頼む

コメントアウトしたelifの意味とか聞いて、今パッチ書き上げたところなのに…
とりあえずURLくれ
見つけられない

CUDA Toolkitを使ったバイナリだと、GPUはGeForceなのに何故か--openclが動かない
APPは大丈夫

今まで何故か頑なに2passビットレート指定でエンコしてたが
結局画質なんてビットレート次第で、1passだろうが2passだろうが
品質なんて微塵も変わらないことに今更気付いて1pass品質指定でエンコしてみた。
実写でも、映画なんか--crf 23辺りで平均6Mbps前後でエンコしてくれるが、
ボクシングの試合をエンコしたら平気で20Mbpsもビットレート消費してくれてなんかワロタ。

根本的に間違ってる

意味も使い方も間違えてる

ん？すまん、どうせ真面目にエンコし出したのもここ3ヶ月くらいなんで
別に無知を指摘されんのはちいとも気にならないんだが、
具体的に何がどう間違ってるの？
そもそも使い方を間違えていたらエンコすらできんでしょう、と思うのですが？

2passの使い道を間違えている
2passは指定サイズぴったりに収めたいときに使うもので、画質を向上させるものではない

もの凄く気にしてるようにしか見えない

>>642
んー、なんつーか、昔ちょっとだけmpeg2エンコしてた時に
2passは1pass目で動画情報を解析して2pass目で解析結果に基づいて最適なビットレートを割り振るから
同ビットレートの1passよりも画質が良いなんて言われてたような気がするから
x264もそうなのかななんて勝手に思ってた、ということです。
というか、そもそもの2passの考え方自体が間違ってただけかもしれんですが。

>>644
Mpeg2時代を経験してたらだれもが一度は通る道

他所でやってくれ

ビットレート指定の1passでやるならその理屈であってるけど品質指定は根本的に違う

初心者スレでどうぞ

最終出力サイズをピッタリ固定したい
↓
固定ビットレートでエンコするしかない
↓
固定ビットレートエンコならnpassで画質向上できるから足掻こう

だと思ってたけどちゃうん？
ちなみに俺は638ではない

MPEG2時代から品質固定あったけど、
基本はDVDに入れるからビットレート指定だけしか使ってなかった人がほとんどか

つーかプライドだけ高いただの馬鹿だろID:aw7Q3f6E

>>641での必死じゃないアピールに必死なのがすごく良い味出してる

知らないことを教えてくれって言うのはバカじゃないだろ

>>641の最後の
>そもそも使い方を間違えていたらエンコすらできんでしょう、と思うのですが？
って一文あるからそういう印象与えるんだよな

だな

ほんまマルチパスは新参チェッカーやなｗ

BOKKI

実写ならロゴ消しして720pに縮小してcrf25でtune filmで適当にやってるわ。ドラマだけど。

しかし、3ヶ月ならエンコ初心者なのかな………
まぁ自分も5年ぐらいだらだらしてるから人のこと言えないけど。

npassは割れずかニコニコで生まれた習慣

VIDEO CDとかの頃からの遺物でしょ

deblockをかけるタイミングっていつがいいの？
avsの中のリサイズの前後、x254で指定、再生時にプレーヤー
併用したりとかするの？
ジャギーノイズを出来るだけ軽減したいけど、映像がボケるのは嫌だし

それってdeblockというかフィールド処理、アンチエイリアスの問題じゃね？

普通はリサイズ前、ソース主義ならプレイヤー
x264のdeblockは範囲と強度決めるだけの簡易的なカスタムフィルタみたいな使い方してる人が多いと思う

ありがとう
なんとなく方針は解ったから、色々詰めてみる！

ソースのブロックにはDeblock_QEDとかを使わないといけない

x264のdeblockは、H.264のDCTそれ自体で発生するブロックを軽減するもの

x264を使うとタイル状の模様とか勝手にデブロックされるんやで(´・ω・｀)

deblockマイナス調整、psy-rdで模様ぐらいどうにでもなるだろ

昔のrevと違って今のじゃデフォのままでいじくるところほぼないじゃん

拡縮はaviutlにupsampleっていうやつ入れてやってる
輪郭部分とそうでない部分を検出してそれぞれ別のアルゴリズムで拡縮処理をさせることができるプラグインな
基本的にビットレートがカツカツで節約しまくるエンコはしないからx264オプションのdeblockに関して俺は知識無いわ
アンチエイリアスの問題じゃね？というレスがあったので俺からも何かアドバイスできたらと思ってな

>>665
オレ今まで間違った認識しててこれずっとoffにしてた
画質にかなり影響力ある項目なんだな
超感謝！

FX-8350をOCしまくれば4770に対抗できるのだろうか

Ivy比 期待値が20%前後で実質10%ともそれ以下とも言われてるし
今と大して変化無いんじゃない

AVX2・FME「・・・」

2310

2274から上げたけどそこそこ速い。微妙にssim psnr下がってる気がするけど

SSSE3以降が搭載されていない我が家のPCには関係ない話ですわ

さすがにそれは買い換えようよ

>>676
>x86-64: cabac_block_residual assembly code, ~1-2% faster overall.

CPUが32bitだというのなら別だが、この辺りは関係ある

いまはじきがわるい
8月頃まで我慢してHaswell待つほうがAVX2も使えて2倍幸せ

AVX2によるエンコ速度アップは実際はそれほどでもないって結論らしいがな

そうなん？

とりあえず6コアが最強

6コアって悪名高きAMDのアレのことか？

今6コアCPUって言ったらSandy-Eとかじゃね？

683から漂うニワカ臭

>>681
x264の個々の関数におけるHaswell AVX2によるパフォーマンスゲイン
http://www.scribd.com/doc/137419114/Introduction-to-AVX2-optimizations-in-x264

x264をHaswellで実行し、AVX2を使った場合と使わない場合を比較した場合
現在のx264はコード実行時間の半分は非SIMDコードが走ってるので、もしも最適化が完全にうまくいって
全てのSSE2(128bit SIMD)アセンブラコードがAVX2(256bit SIMD)アセンブラコードで2倍速になったとしても
速度的にはクロックあたりで最大で33％ほどの向上(処理時間が4分の3)が限界になる
つまり非SIMDアセンブラコードがボトルネックになってしまう

ということで完璧に性能出し切って33％増。実際には10％程度アップで御の字ではという感じ。

1155なら買い換えるだろうが

>>676 の before SSSE3 なら Pen4 か PenM 世代だから、そこから Haswell に飛ぶと
2倍速は軽いんじゃなかろうか。
3倍超でるかも。

AMDかもよ

>>684-685
なるほど。2011とか普段全く検討対象に入らん貧乏人なんで、スマソ

最初のレスからするとAMDのこともよくわかってなさそうだし貧乏なら余計にAMDも検討すべきだと思うんだがな
どうせそこいらに溢れる評判を鵜呑みにしてるだけみたいだし。
ランニングコストと買い換えサイクルによってはAMDということになるかもしれんぞ

折角のご提案ありがたいけど、今のところ無印SandyとIvyで事足りてるし、
x264以外に普段からQSVも使ってるから、当面AMDは選択肢に入らないかな。

2011はメモリいっぱい載せれるから男の浪漫

>>691
ブルはSandy、Ivyに比べると電気代がアレで結局・・・って状況は変わった？

どんだけ貧乏なんだろう

っつか好きなものにすればいいじゃん

>>694
ヒント：電気代は親持ち

>>694
だから電気代で差額が埋まるのにかかる時間は使い方や各々の電気代によって変わるだろ
その期間が長ければその前に買い換える場合だってあるだろう
自称貧乏といちいちアピールするくらいならそこまで考えたらどうだって話

>>697
ここx264スレだから電気代はそれなりに考えた方が良いと思うぞ
エンコする量にもよるだろうけどｗ

1Whが大体0.02円位らしいから
1万円分差を生むためには、仮にフルロード時の消費電力が20W違ったとしても25000時間≒1042日≒3年弱 必要

みんな好きなの使えばええべ

むしろ皆には節電に努めてほしい
油土人がのさばるのがウザイいから
俺個人は気にしない

>>699
Ivyとブルの比較でフルロード時100W近く違うってのを見た気が

遅いとエンコ数が稼げないからintel6コアを数台使ってる

x264ベンチスレ見てきたらmidium基準で3570の4Ghzと8350の3.5Ghzが同程度の速度だった
この辺りを基準にすると消費電力差は50-70Wぐらいか。1年買い替えなら全然有りだがhaswellが控えてる今買うのはどうかな

>>686 ってAVX2だけの話だよね? 周波数とIPCによっては結局sandy-Eを脅かしそうで怖い
メイン機に全部積み込みたいんだよぉインテルさん…

サンプルに合わせて比較したベンチがどっかにあったが
IPCは概ねIvy+10%前後だったな

リスク分散のためにも高性能機は最低2台は欲しい

>>699
いつの時代の話してんの
今は東電なら0.0291円/Whだぞ
20W差でも2年弱で1万円の差が付く
50W差なら9.5ヶ月

新電力料金目安単価・22円/kWhも遠い昔になってしまったな

そのうち最新電力料金目安単価・30円/kWhが登場するだろう

エンコを毎日欠かさず4時間やったとして
20W差なら12年弱
50W差なら5年弱で1万円の差か

どーでも良いレベルだなｗ

毎日500W強の電力でエンコしまくってるけど
月に電気代が二万七千円かかる・・・

さすがに1日4時間しかエンコしない人は電気代とか気にしないと思う

普通に昼間家にいなくてエンコ量がそこそこの人は深夜に電気代安くなるプランがないか調べてみろ
朝夕は同じで深夜1/3とかだから深夜8時間程度ならFXやSandy-EをOCしまくっても余裕だぞ
朝夕の通常と同じ値段の時間も9時間くらいあるからエンコ時間合計17時間までならエンコでの損は全くない
休日の昼間の高い時間よほど電力使わない限り得の方が大きい

x264_L-SMASHってx264のrivisionが2245から進んでないんだけどどうして？
http://up-cat.net/wiki.cgi?action=ATTACH&page=L-SMASH&file=x264_L-SMASH_clone.sh
から取得してる

エンコして電気代かけるより新しいHDDを買ってそのまま保存した方が安くならないか？

>>714
条件によってはそうなる場合もある
エンコに時間が掛かる割に大して縮まない実写系なんかはHDD保存が良い
アニメはエンコの方が安いけど、手間を考えたらHDD保存も有りかも

>>710
500W強てｗ　電子レンジかよ

>>716
電子レンジは出力が500Wであって、消費電力は1000Wくらいだよ
効率1/2程度なので、お湯を沸かすなら電気ポットとかケトル使った方が良い

あ、インバーターだと出力1000W、消費電力1450Wとかだから効率は良い

中華レンジはすごく効率が悪い上に壊れやすい
マグネトロンが糞

>>713
俺もそうなる
popとかr2310のL-SMASH版公開してるビルダーはどうやってビルドしてるんだろ？

>>713 >>720
https://code.google.com/p/l-smash/source/checkout
から、gitでcheckoutしているんじゃないの？

>>713
作者はL-SMASH本家やL-SMASH Worksの作業で忙しい。

>>720
x264本家のコミットをマージして、自分のパッチをその上にリベースしてる人は数人いる。
オイラはtaro氏辺りとかのマージをベースしてビルドしてる。自分でマージするのは
面倒くさいし（ぇ

>>721
今のはx264_L-SMASHの話で、L-SMASH本家の話ではないと思ふ。

>>722
ああ、URL間違えた。

Popさんのzipのtext\src.txt には
https://github.com/silverfilain/x264_L-SMASH
から取ったって、書いてあるよ

>>722
元はそこから取ってるなら手動でマージしてる人の一人になるな。
x264_L-SMASH本家は4ヶ月前のまんまですから。

Kovensky氏のせいでx264_L-SMASHがベースしてるx264-audioが死んで、
結局その辺はffmpegかavconvでやった方がいいって感じになってきた。
そして開発者も本家やL-SMASH Worksの方をプライオリティーにしてる。

L-SMASHのムクサーをx264にくっつけるパッチの方が未だになんとなく止まってる
感じがするけど、x264.nlに入るビルドのGPACを更新しようと思う時いつも
L-SMASHに切り替えたい気持ちでいっぱいになるわ。

本家ってどこ？

あー最新rivisionのx264をL-SMASH版にするには自分でソースからマージしないといけないのか…
GPAC版じゃremuxerで取り扱うのに不都合で結局はL-SMASH版x264とセットじゃないといけないからほっとかれても困るな
L-SMASH Works最優先もいいんだけど…

これじゃだめなの？
ttps://github.com/nak5124/x264_L-SMASH

blame Kovy

>>727
jeeb氏、taro氏、pop氏、takuan氏いろんなビルダーのパッチ入れまくりワロタ

いろんなビルダーも何もそれたくあん氏

ついでに言っておくとtaro氏の方がpatch入れまくり度ではものすんごいことなってる
taro氏のgithubなんかバグっててwebで見れないけど
ブログとか見てる限り
POP氏 必要最小限
taro氏 盛りだくさん
takuan氏 takuan氏が必要な分だけ
jeeb氏 最近はtaro氏のベース？
って感じだと思う

サッカーの試合エンコしてて、画面全体が動く場面で
かなりボケてしまうのをどうにかしたいんだけど
レートを上げる以外でどういう方法があるのかおせーて

>>732
10bitだと動き補償の精度が良くなるから、ビットレートが同じでも多少ましになるかと

なるほど
動き補償ってそういうとこに関連してくるのね
10bit試してみます

猫さんガンバッテル
ありが�d

taro氏のgithubが404になってるけど、消したんかな

いんや
>>731も書いてるけどgithubのバグ？だと思う
普通にcloneできるし更新情報自体は配信されてるしAndroidのアプリでも見れる
webだけおかしくなってる

>737
ほんとだgitから取得できたわ

gitだけに回復するまでじっと待とうぜ

　　　　　　　　　　　　　　　　　　 　 　 　 ／＼
　　　　　　　, @　　　　 　 　 　 　 　 　 / .※　> )）
　　　　 ﾉ）　　　 　 　 　 　 ∧..∧　　ゞ ＼__／
　　　 ﾉﾍY!ヽ　　　　　　/ iつ＞＜)　　 ＊　　　ミ
　　　 〃 ｀　,.・　 　 彡〈 丿ｙ⊂}__）　　@､　　　　o
　　　　　　　　　　　　　（___,,_,,___,,_）　　 　 ∬
　　　　　　　　　　　　彡※※※※ミ　!匹 ミ
　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　＼　ぶぅ〜！！ 　／　　　＼　何それ！　／ ボケー
　　　 　　　＼　　　　　／バカヤロー　＼　　#ひっこめー#
　　　l||||||||||||||　∩,,∩　∩,,∩　　∩,,∩　ﾐ∩ハ∩彡
　　　（,#　 　）（,,#　　 ） 　#　,,）　（#　　　）（#　　　）

gitは「じっと」じゃなくて「ぎっと」でFA出てるんだぜ と空気読まないレスを書いてみる

git〜gitくるー

すごく基本的な質問なんだけど最近よく聞く10bitって奴は何が10bitなの？
俺の理解ではYCbCrの各データが10bitという認識なんだけど合ってるかな？

そしてHi10Pでは4:2:0なのでCbCrは4ピクセルで共有なので１ピクセルあたりの
データ量は実質10+(10/4)*2=15bitという考え方で合ってる？

そしてもっと基本的な話なんだけどH.264って色をRGBで扱う事はないんだっけ？
最終段の出力の所を除いたら必ずYCbCr(YUV)で処理するで合ってる？

>>743
大体合っているけど、x264は--output-csp rgbも可能

>>744
サンクス。RGBもどこかでみた気がしたけどやはりあるのか。
でもこれを使うとプロファイルから外れちゃうしハードデコード無理だよね？

>>745
hi10pもhi444ppもDXVAや民生機でのハードデコードは無理じゃね？

>>746
ああ、ごめん。俺が書いたのはmainとかbaselineとかのポピュラーなプロファイルに則ったツールだけを使っていても色空間としてRGBを使うとプロファイルの範疇から外れてしまうのでは？という話。

Hi10Pとかビット数多い奴は今までずっと8bitでやってきていてバッファとかもそれ前提で最適化しているだろうからH/W的な対応は難しいであろう事はなんとなく想像出来る。タイミング的にもメジャーにはなり辛いだろうしねぇ。当面はCPUで頑張るしかないかと。

10bitがメジャーになるか否かはH.265での話になるだろうなぁ。

H.265は今のところMain/Main 10と4:2:0のプロファイルしかないし、4:4:4相当のRGBを扱うのは無理だろう。

>>749
もしかして、そのMain 10というのは10bit？

>>749
RGBや444がメジャーになることはありえないでそ。解像度が上がる&インターレースが
排除されるのなら420のほうが明らかに効率がいいのだから。

>>750
はい

>>751
それには個人的には同意するけど、ゲームを録画した物とか、
元からRGBのソースをそのまま圧縮できたら便利だろうと言うのは確か

シーンチェンジを検出してキーフレームを挿入ってできますか？
出来るならオプションを教えて下さい。

--scenecut

自動でやってくれる
精度は--scenecut、--min-keyint、--keyintオプション弄って調整する

scenecutだけでは？

>>754-756
thx 試してみます。

HandBrakeのリリース版が0.9.9になった模様
x264 core 130 r2273 b3065e6だが

r2334

今回もAVX2対応が多いな

stableが移動しなくてﾜﾛﾀ、ﾜﾛﾀ…

ハスウェル6コア以上が出るまで買う予定無いからな。
果たしていつ活用できるのか。

3970X、3960X、980X、970と6コア機が4台もあるから
次は8コア以上じゃないと買わない

自慢話はよそでやれ

>>763
その流れでIvy-E買わないとか嘘だろ

6コアに限界を感じたのだろう

つか、ふつうにCore i7 3770kとかをデュアルで使えるようにしてくれりゃ
低投資で一気に速度アップ出来るのに。インテルもケチくせーな。

Haswell-Eなんて2015年とかじゃねーか。
結局、円高時代に2687Wx2で組んどくのが一番正解だったか。ちくしょーめ

予算に応じて好きなの使えばいいだけじゃね

8bit の頃はね、ディスクまで揃えると 100万ってのはあたりまえだったのだよ。
とりあえず 100万準備しろ
後は好きに選びほうだいだろwwwwww

このスレみて久々にPCパーツの値段チェックしてみたらメモリが糞上がっててﾜﾛｴなかった

nlのサイトが変わってしまってどこからDLするのかわからなく...
ヨーブ兄さんのとこでお世話になるか

マスターヨーブ

あれ？ほんとだ

Yes, Master

少なくとも、この2つは生きている模様
http://mirror03.x264.nl/
http://mirror04.x264.nl/
01は人によって、繋がったり繋がらなかったり

猫科さんキテルーーーーーーーーーーーー

>>772
jarod氏が#x264でめちゃくちゃな政治的な話を持ち込んで（「9/11は米国が自分で
やったっ！」など）、何回か注意されたらチャンネルから追い出された。

まぁ、それでむかついてx264.nlをリダイレクトに変えたんじゃないかな（笑）。

いつになったらnlは直るんだろうか・・・

これを機に自ビルドすればよい

無理

自分でビルドする意味って何？

むしろ逆に聞きたい
義務でもなく単に好意でビルドしたものを提供してくれてるのをさも当然のように
口を開けてただ待ってる意味ってなんなの？

？

とりあえずVideoLAN関連は未だにワカランだが、mirror1のホスターがx264.nlの
中身を別のドメインで公開中。

ttp://x264.x265.net/

>>783
何言い出してんのこいつ

Haswellさんx264なかなか速いすね
http://www.vortez.net/index.php?ct=articles&action=file&id=21589

俺の見てるスレ見てるスレに貼りやがってくそう…メインストリームに逝く気は無いぜ

使ってるベンチが参考にならなすぎる

2500Kしょぼすぎ泣いたヽ(`Д´)ﾉｳﾜｧｧｧﾝ

>>787
新型CPUが出るといつもよさげなデータが出てくるけど
実際使ってみるとがっかりなことの方が多いよね

Haswellは実行ユニットの整数パイプが4本になったから妥当な速度だな
Ivyまで3本だったので、ちょうど4/3倍くらいになってるし
http://pc.watch.impress.co.jp/img/pcw/docs/596/202/05.png

あ、i5ね＞4/3倍＝1.33倍
一方i7は1.2倍にもなってない

実際もほぼこの通りだったとして、
i5買ってた人は恩恵大きいけど、
i7買ってた人はそれほどでもないね
i5とi7の差が縮まったとも言える

俺は3970Xだからスルーしとくわ

北森瓦版 - 最高周波数5GHzでTDP220WのFX-9000が登場する・・・らしい
http://northwood.blog60.fc2.com/blog-entry-6842.html
FX-9000は定格4.80GHz / TC 5.00GHzとなる。この高い周波数も特徴的であるが、
TDPの数字も220Wと記録的に高く、コンシューマ向けCPUとしては最高値である。


Haswellもいいが、こっちに突撃する勇者居る？

どうやって冷やすんだよ・・・液冷必須か

油にマザボごと沈めるのか

Haswellでx264おもっきりパフォーマンスアップしてるやん
まあ、メディアのエンコ設定がどんな設定か知らんが

4コアじゃあなぁ。
せめてXeonブランドで出ないかな。2個乗っけて8コアにできるのに。

ああ、Xeonは出てるのか。
でもDualマザーが無いな・・

http://www.extremetech.com/wp-content/uploads/2013/06/x264.png

>>799 >>800
XeonはSandy-EとこんどでるIvy-Eで、Haswell-Eはまだ先じゃね？

http://anago.2ch.net/test/read.cgi/jisaku/1370084667/772
2600K 4770K 二世代差 クロック差 AVX2の有無
【NO.6 x32 x64】 25.46 fps 32.31 fps
【NO.6 x32 x64】 28.17 fps 35.21 fps
うーむ

HT無しi5は良さげだが、既にi7使ってる人はあまり効果無さそうだな

>>787
2500kは定格なセコさ

>>802
Xeonと名の付くHaswell自体は出てるみたい
http://akiba-pc.watch.impress.co.jp/hotline/20130601/ni_c1285lv3.html

Sandy世代使ってるならもう一世代ぐらい飛ばしても問題無さそうだな

>>806
それUPじゃん。
>>800はDPって言ってんで。
Xeonって名がつきゃ何でも良いって訳じゃねぇ。

Celeron DPとかi5 DP作ってくれないかな
AMDがスーパーCPU出せば作ってくれるかも
まあTDP220Wとかやってるようじゃ望み薄か…

Haswellの4770K買って早速組んでr2334で出力
同ソースでの定格2600Kと比べて約10fps位アップかな
Haswell-Eに期待したい

おー・・・すごいのかどうかよくわかんねえｗ

AVX2の恩恵は多少ありそうだな
ベンチスレでの結果待ち

AVX2の影響を排除するには、--asmオプション使え

やはり、MB、CPUをセットで入れ替えるに値するほどでは無かったか・・。

1fpsが11fpsになるのと100fpsが110fpsになるのじゃ全然違うのだが

intel6コア使ってるならスルーでおｋ

どうせまたHaswellの4コアとIvyの2コアを比較してるんだろ？

どうせ早くなってもその分重い設定にするんだろ？みんな

3時間ものとかでQVGAサイズエンコfpsすごいことになって楽しいよ

>>818
ファイルサイズが小さく高画質なものを
作ることこそが先達の原動力だからな

関係ないし

--preset veryfat --crf 0

ベンチスレ来たな。
AVX2の恩恵は予想通り5%程度だが、Ivyと比べると20%up位になってる。

x264開発者は、かつてはデータシート見ながらAVX2対応してたのを、
今後は実CPUでAVX2開発できるから、
AVX2最適化がすすめばもうちょっと性能向上するでしょう

rigaya氏の詳細なのも来た。
ttp://rigaya34589.blog135.fc2.com/blog-entry-362.html

i5はどのくらい差が出るんだろ？
貧乏人なんでi5しか買えないから、
上の方に出てるi5がかなり速くなってるって話の詳細が欲しい

貧乏なら無理して買うな

貧乏なら中古で2600kか8120買うのがいいんじゃねーの

シーケンシャルな処理の影響はコア単位になるから
複数のストリームを同時に変換する時は差が出るんじゃないの？

エンコした264のIDRフレームを確認できるツールある？
AVIDemuxとかフレーム単位でI・P・Bまではわかるんだけど、できればIなのかIDRなのかまで確認したい。

>>830
h264_parse

>>828
電気代考えればIvyの中古の方が良いと思う

エンコは電気代よりOC耐性と性能だろ

3930kは…って調べたらこんなに値上がりしてるのか
今1155じゃないなら蓮i5行ってもいいんじゃね。というか行って色々報告してくれ

>>824
今回は二人くらい実機にアクセスできてた。ただしNDAされてて、詳しい情報を
全く公開できなかった（ベンチマーク等）。IntelとAMDのデータシートが使用可能な
ファンクションの一覧以外としてあまり役に立たないのはかなり前から知られてる事。

x264本家に最適化が入ったらかならずアクセスできてテストできる機は
一個でもあるという事になる。

何も知らずにnl開いたら変な動画再生されて吹いたｗ

まあ、事前の予想通り
無理して入れ替えるようなもんでもないな

AVX2は噂段階の頃は今まで同様の柔軟性でGPUエンコ並みのスピード出るとかいわれてたけど
半年前ぐらいにはだいたい今ぐらいの評判だったよね

>>831
即答さんくす！あるんだな！！
ファイル放り込むとそれっぽいデータがダーッと流れるけど
logの吐かせ方とかオプションあるのかとかよくわからないから動体視力を鍛えることにする。

>>839
いや、動体視力鍛えるってｗｗｗ
噴いたコーヒー返してｗｗ


普通にリダイレクトすりゃ、テキストファイル書き出せるんじゃないの？
h264_parse.exe "ファイル名" > hogehoge.txt
とかやってみ。

>>840
普通にログ出てきたor2
おぉnon-IDRとかan IDRとか書いてある。
ひとつの段落が1フレームってことなのかな。ちょっと読んでみる！さんくす！！

動体視力ｗｗｗｗｗ

http://x264.nl/
どうしちゃったの？

>>843
同時多発テロがどうたらこうたら...

www.x264.nl/x264_main.php
ここの上にIRCのログがある

池沼だったの？

>>846
普段はただのスティーヴン・セガールを愛する陽気なバカなんだけど、
酒だか大麻(オランダだから合法ね)だかが入るとキチガイ発言やらかしてはIRCから蹴られるのを
数年に渡って繰り返してた

そっか、そういえば.nlってオランダのドメインだったな

ミラーサイトも・・・

まさか二ヵ月遅れのエイプリルフールって事はあるまいが…

旧暦でやってるんだろ

x264はもう入手不可能になったの？

はい
x265への移行をお願いいたします

探せば変なミラーサイトに転がってるからVirusTotalでチェックしてから使え

儀保氏はもうx264ビルドしないの？

変なミラーサイトを使うぐらいならKomisar氏とかPOP氏とかたくあん氏とかのビルドを使う方がマシだと思うが

http://www.videolan.org/developers/x264.html

そのサイトは糞の役にも立ちません

ふ〜ん

x264が入手不可能になったのにみな平然としていますね？

だって他に入手先があるもんね

だって、自分でビルドするもん

とりあえずヨブさんがいれば困らんだろう

ぼくはTaroちゃん！

世武さん最近ビルドしてないじゃん

>>865
ヨブさんのビルドをミラーしてたのがnl

POP@4bitでもらえばいいじゃない
米糠の中に含まれる枯草菌の産出物によって、ダイコンは徐々に芯まで黄色から褐色に染まる。ってところでもいいし

もう長いから、
こめぬか！
でいいよ

>>866
patched buildの話

教えて下さい

ヨブさんのビルドはどこでダウンロードできますか？

オプションの隠し方教えて下さい
なんで隠す必要あるの？とかはナシで

割れうpか？　バイナリで加工しろ

IntelといいNVIDIAといいなんで嘘つきまくるんだろう
最初から「これを使えば3%程度の性能向上が見込まれる」程度にしておけばいいのに

>>871
--no-opts

>>873
もう嘘をつくことが当たり前になってるせいだろ
「いくらか割り引いたのが実際のところなんだろう」という暗黙の了解がある
それを本当に、実際のところを言ってしまったら、そこから更に割り引いて考えられる

>>867
たくあんでおk

※効果には個人差が有ります

過疎age

ttp://www.x264.nl/x264_main.php

mirror06生きてたよかった

今日基本テストが終わって、VideoLANがこれからx264を自動ビルドする
ようになるんで、多分次のプッシュでx264.nlが用済みになるな。

なにそれこわい

ttp://x264.nl/x264/

>>881
mot kwsk

>>884
単純にVideoLAN側が自動的に主なプラットフォーム向けにビルドするようになるだけです。
公式ではないが、名状しがたい公式のようなものにはなる。

x264.nlのビルドを利用してる人にはいい代わりになるかと思う。自動ビルド
だからコミットがプッシュされてから短い期間で公開されるはずだし。

良かったnl殆のリンク復活してる

地味な更新がきているね

funman氏が起き始めたっぽい
ttp://download.videolan.org/x264/binaries/

8bitのみでGPACなしか

>>888
使えない。

nlたんオワタ　誰か代わりくれ

いつのまにかr2348までいってたのね

nlのリンクのバイナリはstable版でok?

komisarんとこのclearに乗り換えよ

POPさんx264更新しないな・・・

見やすいチェンジログない？
x264.nlのチェンジログみたいなの所望

猫研でも見とけ

>>896
http://git.videolan.org/?p=x264.git;a=log

>>898
revisionが分からないのはネックだけど>1のチェンジロクより見やすくなった
ｔｈｘ

subme7にしたら実時間エンコできるようになった

7使うぐらいなら5か9の方が良いと思うけどね

思わないけどね

かもねかもねそーかもね

>>900
だったら me hex subme 9でok
画質とPSNR/SSIM値の向上の方はavsでどうにでもなるから触れない。

>>904
meを下げてsubmeを上げるのは非効率的だって猫さんが言ってたお

CPUやGPU類を変えずにエンコ時間を短くする目的なら多少セオリーを無視してもいいんだよ。
この組み合わせでしかダメみたいな型にはめるようなエンコはアレンジもできずに退屈する。

下手な考え、休むに似たり

個人的にthreadsは3に合わせてDualCore向け用に割り振って2coreづつに割り振って並列エンコさせている
4M8Cと1M2Cの時間差はせいぜい５・６分程度の差だし、大量にある場合はまとめてやった方がはよ終わる。
x264はそれでもなくてもCPUを最大活用してくれないわけだしなぁ

下手の、だろ

OreAQとMixAQの10bit版はありませんでしょうか

taro氏のは10bitもMixAQじゃなかったかな

>>911
ありがとうございます！

24fpsで撮影したAVCHDをx264でHLS用にエンコードしたい時は、
--min-keyint と --keyint　を共に48にすれば間違いなく2秒毎にIDRフレームが入ると思っていいんだよね？
あとは適当なセグメンタ拾ってきて10秒で切ればおｋ？

ほかに注意しないとHLSに失敗するオプションってあるのかな--qp周りとか--refとか--bframesあたりとか。
切るの10秒毎ならIDRフレーム間隔は10秒じゃダメなんかね。
なんかズレたり不確定要素があるのかしら。

HLSを受け取るデバイスによるとしか
例えばiPhone 3GSはBaseline Profileしかサポートしない
解像度とかはここらでも見てくれ
ttps://developer.apple.com/library/ios/#technotes/tn2224/_index.html

あと別にIDR間隔が短い分には構わないから--min-keyintはいらんよ

コーデックは画質を別にすりゃ制限すればいいだけの話だけど、
むしろsegmenterの方が不安定なもの多くて難しい気がする
segmenterを安定させるためにもIDRは細かく入ったほうがいいし
Open-GOPはやめといたほうが無難

ベンチスレみてきたけど蓮はx264なら良い感じで使えてるし
openclも軽オプションなら十分に効果あるんだな

単にAVX2で一部最適化されてるからじゃね
でも最適化されるということはそれだけコアを使い切るようになるわけだから
より高い冷却能力を求められるわけで貧乏自作で頑張る人にはきつかろうに

蓮はAVX2がONでもOFFでもそんなにエンコ速度に差がない
基本アーキレベルでエンコ速くなってるみたい

AVX2に過剰な期待は出来ないけど、本領発揮するにはもう少しかかるんじゃないかな？
現物のCPUでテスト出来るようになってまだ１ヶ月くらいしか経ってないし

IntelからコッソリES品提供されてたりしないのかな

してたみたいよ

H.264だと128-bitのSSE2で十分だからAVX2はほとんど効果ないよって話

【x264+Avisynth】実用エンコベンチ Part3
http://anago.2ch.net/test/read.cgi/jisaku/1352352619/417

【CPU】 i7 4770 定格
【MEM】 DDR3-1600 4GBx2
【M/B】 ASRock H87M Pro4
【SSD】 RealSSD C400
【GPU】 オンボ
【OS】 Win7 x64

---------------
【x264】 r2334 x64


AVX2有効
【Veryfast】 64.82 fps
【. Medium】 17.46 fps
【　 　Slow】 7.97 fps
【.　Slower】 3.95 fps


AVX2無効　　　　　　　　・・・(AVX2有効との差)
【Veryfast】 62.57 fps　　・・・(3.6％)
【. Medium】 16.71 fps　　・・・(4.5％)
【　 　Slow】 7.72 fps　　　・・・(3.2％)
【.　Slower】 3.84 fps　　　・・・(2.9％)

3970Xでもうしばらく我慢するわ

C2Dからは乗り換える価値があるとみた

いままでC2Dで済ませてきたなら、むしろ次のイスラエルまで待つべきでは
SSE2だって本領発揮はConroeあたりからだったし

今までアニメしかエンコしてなかったが実写だと全然違うな
最終的にインタレ保持でcrf18にしたけど今までアニメで有効だったオプションが
悉く細部潰れののっぺりにしかならん事に驚愕した

あと実写を細部保持してエンコするとインタレ保持のが有利なのと
そうするとあんまり縮まないという事も学習した

BDってなんであんなに大容量なんだよｗｗｗ容量無駄ｗｗｗとか思ってた俺がアホでした

実写は時間掛かって縮まないからTS保存一択

実写は油絵にして圧縮してしまえ

時間かかって劣化させたのに半分にもならないという
地デジがMPG2な理由が理解できた一週間でした
TS保存ていう手もありすなあ

実写をどうしても圧縮したいなら
油絵＋540p以下にしてんな

不可逆圧縮で生じる、ノイズっていうやつの多くは、モスキートやブロックだろ ?
それらは、元の画像が持つ情報量に加算される方向で影響するわけだ。
画像が「潰れる」のであれば減算されるかもしれんがな。

馬鹿は不可逆を再エンコードするんだよ

アニメだって強いNRかけて縮んだｗとか喜んでるやついるけど
かなりディテール削ってるんだよ

ソースが1920x1080な実写は1408x792p@60fps/crf18でエンコさせ
ソースが1440x1080な実写は1056x792p@60fps/crf18でエンコしてmux時に16:9か1:1を割り振ってるわ。
ソースが720x480な実写は992x744p@60fps/crf16でエンコしてmux時に16:9か1:1を割り振ってるわ。

あれこれ試してみたが縦を288px減らすだけでだいぶ時間短縮と圧縮率向上になる
アス非さえあってれば映像が破たんしたりしないしボケたりしないし
PCでしか再生しない上に、どうせ他人には見せない自分用だから細かいことまで気にしない

>>932
細部がツルツルになってるのおおいよね

×アス非　○アス比
おっとなんか文章が破たんしてるなｗ

お前らの頭ですね

俺実写エンコだとアニメだとありえないってくらい強さで3Dノイズ除去、グレイン除去フィルタかけて縮めてる。
もちろん細部が潰れるのは承知のうえで
アニメだと細部保持にも結構気を使うけど実写なら細かいことなんてどうでもいいやって感じで

実写をアニメ塗り化してるんですね

ビルドしたらr2345の後にMがついてたんだけどこのMの意味って？

Mハゲ

>>939
modifiedの意味
公式ソースを一文字でもいじったらそれが付く

>>941
ありがと、そういうことか
GPACからL-SMASHに変更するpatchあてたからMがついたのね。

ディテール君こっちにも出没してたのかｗ

>>943
ツルペタ君オッスオッス

アニメセッティングを使わず、デフォに戻せばまともになるだろ実写は
そしたらcrf18もいらねーよ21くらいでいいわ

インタレ保持crf28でF1とかエンコしてるが全然気にならないぞ

チャレンジングな基準で語られても困りますぅ

チャレンジングの意味を考えてから書きこもうね♪
無理なら日本語を使おうね♪カタカナばっかり使ってるとＮＨＫや政治家みたいになるよｗ

ごめんねー すぐ気付いたんだけど訂正するほど重要なレスじゃなかったから
正しくはチャレンジドだよー

エクストリーム

実写でcrf28とかないわｗ
それにinterlacedフラグつけるなら
crfは最低20ぐらいでないとF1映像とかだと
コーナーごとに出てくるフェンスの網目などの細部がのっぺりするぞ

そもそも地デジは元がノイズまみれだし・・・

F1は地デジではやらなくなった

GTRレースとかはたまに深夜放送とかでやってるよな

本戦も今は地デジでやってないのか・・・
しばらく見てないから知らなかった

動きの多い60i実写はエンコする気がそがれるな
映画はわりとする、グレインはどうせ保てないし潰す

実写はMCbobしてcrf25くらいでエンコしてる
とてつもなく時間かかるけどそんなに数はこなさないんで何とか回ってる

ミルキィみたいに前半実写、後半アニメはどうしようか迷う
分割しようかな

えっ
普通に実写とアニメが切り替わるフレームでプロファイル変えてやればいいだけじゃん

zonesで実写部分だけcrf25にしてる

>>958
AVSも実写とアニメで使い分けているなら分割エンコをお勧めする。
ちなみに分割エンコ後のマージ処理はmkvmergeでやった方が音ズレが起こらないからいい

>>961
音ズレって、分割するのは画像だけじゃなくって音声も分割してるのか？

ふつうはそうだろ。aviutilユーザはどうやってるのかは知らんがな

分割したとこで一瞬音声が途切れるぞ
60テロップとかエンディング60でイントロが本編に被ってるVFRはどうするんだ？

ナーバスだなー HDDレコーダーで録って見て即消す
粗筋という圧縮をして自分の海馬に永久保存だろJK

「選択範囲を新しいプロファイルにする」「選択範囲を新しい圧縮の設定にする」「選択範囲のインターレース解除を指定」
これらを使えば読み込んだファイルを分割せずに違う処理をさせられるけどaviutlは

CMカットしてから音声だけ出力してそのあと映像だけ分割エンコ

普通はそうするな

VFRエンコって--tcfile-in、--timebase使うのが普通だと思ってたけどそうでもない？

x264にはrawで吐かせてmkvmergeにIts産のtimecode食わせてる

>>969
VBVを指定したいし、そうする

>>951
tsの時点でのっぺりしてるからどうしようもないｗ
crf20でエンコしても数倍の時間掛かって縮まないファイルが出来るだけ。何のためのエンコだよ

気持ちよくなるために決まってんだろ！

実写は映画以外は60iが基本だからインタレ保持エンコだな
この前のウインブルドン男子決勝は4時間近かったから
960x1080i/SAR2:1で縮めたわｗ
スポーツは解像度より動きが命なので　

仮にプログレッシブ走査映像でそういうセコイ節約するとき(するつもりないが)
1920x540や1920x720のSAR指定で垂直方向に引き伸ばし再生でもいいんですか？

人間の目は横より縦に敏感なので、縦はそのままで横を削った方が良いらしい

なるほどありがとうございました
勉強になります

お助け料一億万円いただきます

そ、そんな〜

救いのヒーロー現る

つ● 赤いドロップを進呈しよう

本仮屋ユイカちゃんがいいな

ふむ。ユイカちゃんはいまデリヘルで貸し出し中だから無理だな。

正直、本仮屋ユイカって偏差値でいったら53くらいの顔レベルだと思う