x264 rev34

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

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

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

[本家]
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 rev33
http://hibari.2ch.net/test/read.cgi/avi/1315323936/

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/

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

http://i.imgur.com/dxFau.jpg

ここにいるよ

>>1 乙

http://www.bestgate.net/capture_earthsoft_pt2.html

(ﾟдﾟ ) >>1乙　これは乙じゃなくてポニーテールなんたらかんたら

おお…

おつおつ

2ｃｈの皆様おひさしぶりです
以前　89のくせに「2get」と書き込んでしまい「46億年ＲＯＭってろ！」と言われてしまった者です。
言われた通り46億年間、沢山沢山ＲＯＭりました。
原始生命体の誕生…　多細胞生命体への進化…　カンブリア爆発による生物の多様化と繁栄そして絶滅…
途中、Ｋ−Ｔ境界で直径約10kmの巨大隕石がユカタン半島付近に落下したことにより
地球上の生物の70％が絶滅し、2ｃｈの閉鎖が危ぶまれましたが言いつけを固く守り、唇を結んでＲＯＭに徹しました。
そして生まれては散ってゆく生命。数え切れないほどの大自然の猛威…進化の為の淘汰、繁栄の為の進化。
46億年経った今、晴れて縛め（いましめ）を解かれた私（わたくし）が、2get出切るチャンスに今っ！恵まれました。46億年間もの間付き添って頂いたお月様、ご覧になってますか？
それでは、46億年の歴史の重みと共に、キーを叩き壊すほどの情熱をもって打ち込ませていただきます。

2get!

９９９京年ROMってろ

1げと

ばかもーん！ >>1がルパンだ！ 追え追え〜

可哀想だからアンドロメダ銀河と合体するまでROMってろにしてやる

L-SMASH統合ﾏﾀﾞｰ

X5-452の配布してるバイナリqtaacとfaac入ってるみたいだけど配布してもいいの？

おお・・・

VerUpまだー？

ダウンロードミスったr2106がミスってない奴と同じ設定、結果もほぼ同じビットレートで
いい出力しやがる（暗いシーンが潰れない）
なんだこれ・・・

日本語でおｋ

じゃあ俺も次からダウンロードミスるわー。超ミスるわー。

ダウンロード失敗したのに気づかないで使ってたr2106があるのよ
ファイルサイズで言うとミスしてないのが9815KBでミスしてるのが9788KB
ちょっとファイルサイズ足りてないだけだからか普通に動いてる（だからDLミスになかなか気づかなかった）
で、ミスしてない方と同じ設定でエンコするとビットレートとかほぼ同じファイルを吐き出すんだが
目視で確認するとミスしてない方で潰れてる暗いシーンが潰れてないんだよ
偶然の産物だけどどういうことだよっていうね

なにそのオカルトｗ

ちょっとそのバイナリうｐしてみて

>>17
faacはLGPLとしてライセンスされてるのに、(L)GPLとライセンスできない
仕様書と付いているリファレンスエンコーダーのソースが使用されているため
完全にアウトー。

qtaacは一応ソース的にはBSDなAppleのSDKを使用してるからその辺は大丈夫だけど、
x264とリンクしちゃうとGPLになって、知らないライブラリをリンクするのが一応
ダメになるからアウト・・・のような状態。OS XだとQTのライブラリはシステムの
ライブラリになるからそこは大丈夫かなって感じ。

一応MPC-HCとかは平気でAppleのSDKを入れて使っているような感じだけど、
x264-audio/x264_L-SMASHの場合はなんとなく使用してもいないのにGPLという理由
で文句を言い出した人があったから、念のためnonfreeなコンポーネントに追加された。

うｐした
http://www1.axfc.net/uploader/Li/so/115338
pass r2106

壊れたもん出回らせるの良く無いんじゃね？

>>27
9815KB = 8bit-depth
9788KB =10bit-depth
結果が違って当然。

ファイル名同じだから使用する物を間違える事はあると思うが、
ダウンロード失敗なんて発言はmd5くらいはチェックしてからにせい。
（x264.nlのurl、.exeを.md5に変えれば各ファイルのmd5ファイル有）

新verが出るまでの暇つぶしｗ

ある意味8bit/10bitのブラインドテストか？ｗ

>>31
そういうレスを引き出すための猿芝居だと思う

プレイヤーが対応してないから使い物にならない

PCで見る連中の方が圧倒的に多いだろに

オーサリングに難があるからな

おお・・・

10bitはちょっと重くなるんだよなぁ

LavFilterの再生支援ってRADEONでは使えないんだな。
とはいえCPU再生で10%もいかないから別に困らないんだけど

おれもテストしてみた
30秒の実写ソースをPOP氏のバイナリでインタレ保持エンコ
x264.r2106_win64　4.29 fps 3分30.1秒 11512.59 kb/s
x264.r2085_win64-10bit　2.95 fps 5分5.6秒 11409.68 kb/s

10bit遅いし俺の目じゃ違いがわからんｗ

インタレース動画はDXVAで再生した方がうまくインタレ解除できるから8bitだなー

バンディング低減が全然違うからなぁ・・10bitかな・・
これみて、まさかここまでは変わんねえだろと思ったけど、
ttp://screenshotcomparison.com/comparison/78624
ここのバンディングひどい、サンプルソース（これいいのか？）使って8bitと10bitで色々比較したけど、
ttp://forum.doom9.org/showthread.php?p=1509849#post1509849

全然違ってたよ。8bitでaddGrainしないといけないようなのが
軽くバンディング低減するだけできれいになった。
10bit GradFunkMirror（）のが8bit　GradFun2DBmod()より綺麗になってた。

でも今はflash3kyuu_debandがあるからこっちで軽めにあてて、使ってるけど。
再生環境によりけり、今は使い分けかな。

重くはなるけど、まぁ許容範囲・・・。

avisynth2.6+yaa4xm+x264(JEEB)
8bit 5.8fps
10bit 5.05fps

画質はというと、いつもHDMIで繋いでTVで見てるのであまりわからん。

そういう目になりたい
一回しか見ないであろうとか
割とどうでもいいものだけ8bitでやってる

正直VGAのビデオ関連設定で
フルレンジにしてるかか限定レンジにしてるかで暗部の見え方が全然違う
と言う罠もあるからなんともいえん

バンディングなんてノーガードだぜ、見返す事なんて無いからな

でもシュタゲみたいにソースがわざとバンディングさせてあるものは
バンティング軽減しないままエンコするべきっしょ。

あれは別にワザとじゃなく、BDのスペック的に自然に出てしまったんじゃないの？

消せないヤツのひがみに聞こえる

わざとなのか、結果的にそうなっちゃったのか
それをどうやって処理するかは好き好きですな

新しいリビジョンはマダカー

あのあの10bit深度のyuvでフルレンジ出力した場合それぞれ1024色すべて使えるって認識でいいの?

>>46
放送当時はワザとバンディングさせてると思ったが
BD買ったらバンディングが綺麗に無くなってた

>>51
その色空間ではそうなんじゃね？
色差が1024色ってなんか変な気がするけど

アニメみたいな塗り絵なんかは常時バンディング低減入れてるわ

常時は手抜きともいう

塗り絵をエンコして保存してるのか

バンディング低減は使えるフィルタ

俺みたいにビットレートケチる奴には豚に真珠

と、豚に真珠…

LAV Splitter関連ってここで良いのかな？今気付いたんだけど
mpcでLAV Splitter使ってmp4再生する時にaudio1、2、ってあったら順番関係無
くビットレート高いほうが優先されて再生されるんだけど、これをaudio1を優先
するようにできないかな？言語で優先させる設定はあったんだけど両方日本語
の2ch、5.1ch、コメンタリーとかあると微妙に困る。

LAV Filtersのスレは別の板にあったと思うが

>>61
ごめん、言われて検索したらソフトウェア板にあった。移動します。

我ながらすげえアホな質問だとは思うんだけど何を勘違いしてるのか指摘ください。

　　H.264の勧告
　　http://www.itu.int/rec/T-REC-H.264

これの2010/03版のmatrix_coefficientsのところを見ると、「video_full_range_flag is equal to 1」の場合のYCbCrの計算式が

　　Y = Clip1Y( Round( ( ( 1 << BitDepthY ) - 1 ) * E'Y ) )
　　Cb = Clip1C( Round( ( ( 1 << BitDepthC ) - 1 ) * E'PB + ( 1 << ( BitDepthC - 1 ) ) ) )
　　Cr = Clip1C( Round( ( ( 1 << BitDepthC ) - 1 ) * E'PR + ( 1 << ( BitDepthC - 1 ) ) ) )

で、E'Y：0.0〜1.0、E'PB,E'PR：-0.5〜0.5ってなってるんですけど、これってそのまま計算すると

　　BitDepthC=8、E'PB=-0.5の場合
　　Cb = Clip1C( Round( 255 * (-0.5) + 128 ) )
　　　　= Clip1C( Round( 0.5 ) )
　　　　= 1

　　BitDepthC=8、E'PB=0.5の場合
　　Cb = Clip1C( Round( 255 * (0.5) + 128 ) )
　　　　= Clip1C( Round( 255.5 ) )
　　　　= 255 （Clip1C()で0-255の範囲に飽和するので）

となって、色差の範囲が0〜255じゃなく1〜255になりません？
実際には0〜255で合ってますよね？どう解釈すればいいのでしょ？
（最新の2011/06版は有料っぽいので見てませんが・・・）

詳しく計算したことはないが、0と255は同期信号用で、使ったらいけないとか読んだような

うん、手元にあるBT.709-5には
Quantization level assignment　　8- bit coding
? Video data　　　　　　　　　　　　1 through 254
? Timing references　　　　　　　　0 and 255

って書いてある
ホントにアホな質問だな

>>64-65
BT.709は主に信号伝送の規格ですよね？
量子化の規定も8bitなら[R,G,B：16〜235]、[Y：16〜235、Cb,Cr：16〜240]ですし、
信号伝送で0と255が使えないというのはエンコード時の色変換で関係してくるのですっけ？
Avisynthにしてもffdshowにしても、フルレンジのYCbCrといったら[Y,Cb,Cr：0〜255]ですよね。
ディスプレイ等に信号を送るときに0や255がどう扱われるのかはよくわかりませんが・・・。

また、>>63の計算だと0が範囲外になるにしても、255は使われることになってしまいますので
BT.709が根拠というのはちょっと違和感があるのですが、どうなのでしょう。

なんか発想が逆だな
元はアナログデジタル変換のためのbt.601規格が先
「信号伝送の規格」というわけじゃない
一般の動画コーデックのYCbCr<>RGBの変換式自体両BT.XXX規格を元にしてるんだから

なにがなにやらさっぱり(^p^)

>>67
失礼。信号伝送じゃなくデジタルアナログ変換ですね。

ただ、BT.601もBT.709も、
　　E'r,E'g,E'b： 0.0〜1.0の値をとるガンマ補正済みのアナログRGB信号（黒が0、白が1）
　　E'Y： 0.0〜1.0の値をとるガンマ補正済みのアナログ輝度信号。E'r,E'g,E'bに特定の係数をかけて求める。
　　　　　　　BT.601の場合　E'Y = 0.299*E'r + 0.587*E'g + 0.114*E'b
　　　　　　　BT.709の場合　E'Y = 0.2126*E'r + 0.7152*E'g + 0.0722*E'b
　　E'Cb,E'Cr： (E'b-E'Y)と(E'r-E'Y)に特定の係数をかけて、-0.5〜0.5の範囲に正規化した、
　　　　　　　　　ガンマ補正済みのアナログ色差信号
というアナログ値の規定があって、それを[R,G,B：16〜235]、[Y：16〜235、Cb,Cr：16〜240]に量子化しているものだと認識してます。
[R,G,B：0〜255]や[Y,Cb,Cr：0〜255]への変換式の規定は両規格には無いですよね。

で、H.264のmatrix_coefficientsの規定は、
　　・アナログ数値の値範囲はBT.601等と同じくE'r,E'g,E'b,E'Y： 0.0〜1.0、　E'Cb,E'Cr：-0.5〜0.5 。
　　・E'Y,E'Cb,E'Crを求める係数はmatrix_coefficientsの値によって変わる（BT.601やBT.709以外にSMPTE240Mなどがある）
という規定があって、その上で、「フルレンジOFF用の量子化式」と「フルレンジON用の量子化式」が定義されています。
「フルレンジOFF用の量子化式」は、ほぼBT.601やBT.709の量子化式と同じ。

最初に疑問だったのは>>63に書いた「フルレンジON用の量子化式」で、そのまま計算すると8bitの場合
　　Y： 0〜255
　　Cb,Cr： 1〜255
になっちゃう気がするんだけど、Cb,Crの最小値はゼロじゃないの？というところです。
AvisynthでConvertToYUY2(matrix="PC.709")としてやれば、普通にCb,Cr=0も使われると思うのですけど、
そのへんどうなっているのかなあと。

あともう１つ、
　　「BT.709などでは0と255は同期信号として使われることになってるけど、
　　　これってRGBやYCbCrをフルレンジで扱う場合にどう影響するの？」
という疑問も出てきましたが・・・。

>>69
範囲外の数値の取り扱いは
・１〜１５などは存在してもよいが変換式の結果が保証されない
・0は画像データ内に存在してはいけない
あくまでも変換式自体が有効範囲内だけってことだ
http://www.marumo.ne.jp/bt601/

長文

>>70
それは、16-235/16-240 の場合の話でしょ？

avs2pipemodはtffなどインターレースの指定ができますがavs2yuvやavs4x264modはできませんよね？
これらの指定できないものでインタレ保持エンコのパイプをした場合何か問題はあるのでしょうか？

>>73
x264側のコマンドに--tff/--bffをつけていれば結果に変わりはない

うぅん、前スレの2085と2106で速度が違う件を試してみたら
手元の環境で速度はおろか結果すら違った、目視確認面倒だし2085使うか

::2085
x264 [info]: frame I:83    Avg QP:16.39  size:101099
x264 [info]: frame P:1215  Avg QP:23.13  size: 22269
x264 [info]: frame B:858   Avg QP:24.87  size:  3485
encoded 2156 frames, 1.29 fps, 3419.62 kb/s
--tune ssim
　x264 [info]: SSIM Mean Y:0.9921083 (21.028db)

::2106
x264 [info]: frame I:83    Avg QP:16.40  size:101094
x264 [info]: frame P:1223  Avg QP:23.14  size: 22274
x264 [info]: frame B:850   Avg QP:24.88  size:  3366
encoded 2156 frames, 1.26 fps, 3424.48 kb/s
--tune ssim
　x264 [info]: SSIM Mean Y:0.9921072 (21.028db)

>>74
それではavs2pipemodのインタレフラグってなんの意味があるんですか？

>>75
結果が同じで速度が違うなら問題だけど
結果が違って速度も違うなら何も問題ないじゃん

>>77
初心者スレで書き込みあった時は--ssimの数値までは出て無かったが
ファイルの大きさが全く一緒で時間だけ変わってるって書いてあったしな
ただ複数の人がテストして時間の伸びを指摘してる

>>76
avs2pipemodはx264専用パイプツールではなく、avsから
YUV4MPEG2/RawVideo/PCM in WAV/RawPCMAudio/avsのクリップ情報/ベンチマークの結果
（おまけでBDエンコ用のx264コマンドライン）
を標準出力に出力するためのツール

例えばリダイレクトでy4mをファイルとして保存する場合を考えれば
インタレフラグやSARを付けられるほうがいいに決まってるし、
特に中の人はそういう使い方をすることが多いから無いと困るんだよ

>>78
電力不足で日本の電圧が100Vよりも下がってPCのパワーも堕ちてるんだろ。

>>79
なるほど。
ありがとうございます。

0.03fpsの差って誤差の範囲だろ

俺もテストしたら0.03fps程度の違いじゃ済まないな
もう何本か走らせてみるが

>>72
YUVの有効範囲は変わらない

>>70 >>84
勧告を読み直したりしてみましたが、
　　「BT.601やBT.709のデジタル・アナログ変換の量子化規定では範囲外の値があってもいいけど0と255が使えない」
というのはわかるのだけど、それとコーデック等のエンコード規定とは関係ないと思うのですよね。
BT.709の量子化規定をそのまま引用するなら8bitの場合は輝度も色差も1-254、
10bitの場合は輝度も色差も4-1019までしか使えないことになりますけど、
H.264でもAvisynthなどでもそんな計算は一切行なっていませんし。
BT.601やBT.709と言った場合、単に輝度を求める係数を引用してるだけです。

というか単にフルレンジの場合の色差の値範囲が
　　0〜255
なのか
　　1〜255
なのかがよくわからなくて質問したのですが、変にややこしくなってしまってすみません・・・。

データとして存在しうる値範囲はフルレンジ、限定レンジどちらも0-255。

レスがブログでやれって感じになってしまった、主観だらけなので飛ばして下さい、もう書きません


>>77
変化無しに遅くなるって件は環境に因るんだなーって結論でこっちも終わってたんだけど
こっちの環境の「単一ソースの数値のみで結果」を見ると
「早くなる事もない」「サイズでかい」「QP悪い」「SSIM悪い」という結果だったわー
って意味で貼ってみた

あとで血眼になって視聴比較したら違うところを見つけたけども
あくまでも個人的な好みで言えば、増えた容量ほどの明確な印象の向上があった感じもなかった
(2085+調整による容量増しの方が明確な印象の向上が得られる)

そこまでやってくれたなら、リビジョンごとにビルドしてためしてみようぜ。

BT.601とBT.709は人間の色認識に準じた方式だけど
微妙に色マトリクス値が違うんで相互変換は気をつけたい
間違った入力すると色が変になるよ

>>75
自分の使ってる設定だと同じ結果で、デフォルト設定だと違ったから
どのオプションが原因なのか、設定変えていったら --b-adaptのようだ。
--b-adapt 1だと2085と2106で結果が違って、--b-adapt 2だと同じになった。

いぇーい！イェーブたん見てるー？＾＾

ジーブ様と呼べゴミ虫

mp4プレーヤーで動画持ち歩くのって何が楽しいんだろか？

スレチ

PCで動画見て何が楽しいのに近いぞそれ

>>94
持ち歩くのが楽しいんじゃなくて、mp4プレイヤの中に入ってる動画を見るのが楽しい。
「テレビおもしれー」っていってブラウン管ペロペロしてるシーン想像する人は居ないだろ、普通は。

通勤中にipod touchに入れた動画見てるわ
たまに見入ってガードレールとごっつんこしそうになるわ

>>98
運転中はやめとけｗ
しかし、2106の次がなかなか来ないね。

おぉ・・・

更新されても正直違いがわからないのに更新を心待ちにする俺

次の更新ではfullrangeオプション変更になるよ

--fullrange on/off が --range auto/tv/pc になって、--input-range auto/tv/pc ってのも追加されるのかな。

デフォをoffでいいよ

--rangeはデフォルトでtv --input-rangeはデフォルトはautoで通常設定する必要はないけど判定にミスるときに強制するためのオプション

しかしfullrangeって使ってる人どれくらいいるんだろう。

fullrangeっていじった事も無いし効果もわからない無知な私に
簡単にご教示してください

>>107
入力がPCスケールの場合は、--fullrange onにしないと、RGBにした時の色がおかしくなる。

ゲームのキャプチャとかで使う
TV録画のtsをエンコードするのがメインの人にはほぼ関係ないな

ID変わってしまいましたが
ご教示ありがとうございます
ゲームキャプはもうしないので関係なさそうですね

--range と--input-rangeってどう違うん？
--input-rangeで指定した入力レンジと--rangeで指定した出力レンジが違うとx264がrange変換してエンコードするって事？

r2119

更新内容は、>>102-105 にあるように
--fullrange　の廃止がメインか
あとはビルド関係の修正とか

貼り忘れ
http://mailman.videolan.org/pipermail/x264-devel/2011-December/008934.html

早速試そうと思ったがhttp://x264.nl/にはまだ来てないか

今まで一応--fullrange off付けてエンコしてたけど
今後同じようにする場合は--rangeと--input-rangeは
指定無しのデフォのままでおｋかな？

ok
というか--fullrange自体デフォルトはoff
なにかつけるとしたら--range tvをつければいい

>>92

JEEBはやくしろ

x264_L-SMASHのコミットがまだだからな
というかaudioブランチの方がまだだから

コミット終わってから言えよ。>>112氏ね

他のスレで言ってた速度問題って結局どうだったの？
2106だと2085より遅いってやつ、特定のCPU絡み？

>>121
本家の方は終わってる

r2106→r2119で6.70fps→7.08fps
XP32bit i3 530

r2119がr2106より早くなった
自分の環境だとr2119>r2085>r2106って感じだった

Win7 64pro i7 2600k
Win XP x86Home i7 950

2台共r2085>r2106で共にデフォルトで出力

とりあえずr2119で当分テストかな
0.60fps早くなっただけでもかなり嬉しい

すまん上げてしまった (´･ω･`)　
釣ってくる

猫科さん翻訳待ってます

サイズが微妙に増えてない？

サイズが増えてるのはr2085からr2106に変わった時も増えてるぽい
r2106の時指摘されてたのは容量よりも速度の遅延が多かったし
とりあえずr2085=r2106=r2119の3つでテスト中だけど

FX-8120でいくつか試したが俺の環境で2106比で最低でも15％は速くなってるな
ビットレートは上がったり下がったりだけどどれも気にするレベルじゃない
約3000kbpsで小数点以下の差しか出ないとかだ
この調子でもっと速くなってほしい

fix出てるな

いぇーい！POP氏見てるー？＾＾

32bitがr2120で64bitがr2119ってどゆ事？

Fix regression in r2118 Broke trellis with i16x16 macroblocks

16x16マクロブロックなんてx264にあったんだ・・・知らんかった。
ip4x4,ipb8x8しかないと思ってた

あ、64bitもr2120になった。
JEEBさんお疲れ様です

>>133
x264.nlのミラースクリプトが色々とおかしい。
３０分に一回チェックする上に各ミラーへの転送も遅いみたい。

イェーブさんチーッス

ジーブ様と呼べよチンカス

おまえらヨブさんを困らすんじゃねぇよ

>>139
19:46 (Chikuzen) ヨブさん
19:46 (JEEB) その読み方で呼ぶなｗｗｗｗｗ

怒られたぞ、こら

YET ANOTHER X264 BUILDER
略してYOBU

x264.2120kMod.x86_64.exeで--fullhelpしたら途中で止まらない？

エラー出て途中で止まるね。

dos窓の設定でもっと多数行表示できるようにしなさいな

バグってるね

ヨブさんr2120がバグってハニー
安定はr2085ぽい

>>146
kwsk

バグってるのはkModだろ

てか、KomisarのはclearもkModもみんな止まるのか

使ってるgccがバグってんのかね

ヨブさんペロペロ

いちいちビルダーに呼びかける奴らはなんかキモいけど
>>146のようにまともな情報も書かずに迷惑かけるようなアホウに比べればまだマシかな・・・

お前らが16bit hackつけろって言うからヨブさんつけようとしてくれてるじゃん

まさにあらしをヨブ。だな。

おまいら前スレでイェーブって呼ばれるのが一番しっくりくるって本人が言ってたの忘れたのか？

お前はヨブヨブ言ってるヤツらがそのことを忘れてると思ってるのか？

good-jeeb

komisar氏ビルド直った

そういえば10bit-depthは直ったのかな？

r2120になって高速化して素直に嬉しい
私はx264開発チームに言いたい
ありがとう！本当にありがとう！

　　　　　 　　　　　　 ┃
　　　　　　　　　　　ノ┃
　　　　　　　　　　/＿日＿
　ミ＼　　　　　/　━━━ ヽ　　　　　　／彡
　´／ ＼　　「⌒　　━━━|　　　 ／＼ヽ　
　＼　　 ＼　 ヽ |　━━━/　　／　　　ヽ
　　 ＼　／＼＝|￣| |　　| |＝／ヽ　／
　　　　「 ＼　恭　|━━━）恭　／┐
　　　　　　　ヽ　　|　　　　　|　ノ

>Google Code-In is ongoing, with lots of new assembly code incoming.

今後の更新で、今よりももっと速くなりそうだ。

x264チームの彼等には新しい何かを感じさせてくれる
私は彼等に言いたい！
ありがとう！そしてありがとう！っと

\宣/<ありがとう！そしてありがとう！

GoogleってWebM推進派じゃなかったのか？ x264に手を貸すという事はもう諦めたの？

Ｖ８手伝ってくれたから向こうの成果返してくれたりって話なんかな。
なんにせよ高速化するのはいいことだ

Google Code-InはGoogleがやってるオープンソース支援プロジェクト"Google Summer of Code"の中高生版だ
GSOCみたいに一つの大きな課題に取り組むのではなく、各プロジェクトが出してくるちいさな課題を
期間内に幾つクリアしたかで競うゲーム形式になってる
昨年はDaniel Kangがｘ264のhighbit-depth関連の最適化で得点を荒稼ぎして、2位になった
r1800以降のchangelogを見ればわかる

中高生!
数学系って早咲きというか、若いのに半端ないのがいるよな

問題領域限定すると必要な前提知識も少なく済むから若くても活躍できるね

中高生なんて金もないし暇だからな

一番暇なの大学生じゃね？日本で見ると

それは日本だけだな
あっちの大学生はバイトがメイン日本よりリア充
こっちの大学生があっちだと中高生の生活スタイルだからな
だから日本人は世界中から子供扱いされる

10bitまだ直らないの？

10ビット使ってるけど関係ない所だからどーでもいい

そんなこと聞いてない

>>168
数学は若いうちに芽が出る典型的な分野
功績のほとんどが若いころだもんな

hfg

chroma-qp-offsetに小数点使いたい

ザオリク

x264_L-SMASHまだー？

俺も待ってる

L-SMASHみたいな中途半端な物使うなよ

使いこなせない人ですね？わかります。帰ってくださいも

x264_L-SMASHってなにがメリットなん？

x264だけで音声もmuxできる
GPACのバグの影響を受けない
ビルドが少し楽
後これ自体はベースにしてるx264-audioの機能だけど音声もエンコードできる

規格に忠実ってのもある
というかこれがそもそもの趣旨

これでないと出来ない、とか他と比べて圧倒的な○○みたいなものが
あるわけでもないのか
とりあえずは好みかねthx

x264_L-SMASHだけが使えるオプションとかあるの？

中の人はHBスレで大暴れしてコード晒させて盗もうとしたり
HB本家で大暴れしてライセンス違反から逃げようと人になすりつけたりしていたからな

腹ボテスレかマニアだな

>>188
L-SMASHがどういう役割果たしてるかわかってる？
オプションもなにもGPACの代わり
audio関連のオプションがあるけどあれはx264-audioの機能だし
強いてあげるなら--audio copy と--ademuxer lsmashになるけど

tsから音声分離せずに直接h264+aacなmp4にエンコード出来る？

HBスレでの暴れっぷりは鬼気迫る者があったな
鬼気迫ると言うよりは、気狂いそのものだった
援護射撃にやって来た、L-SMASHメンバーも同類だったし
そんな気狂いソースを取り込んでほしくないわ

いきなり荒れそうな話題を振るなボケ

ダウソ民とそれに群がる人間の集まりだぞ期待する方がおかしい

>>194
すまんすまん、悲しいかな事実なんだよね

ハンブレスレはGPLどうの違反以前に
どう見てもグレーな市販DVDのリップエンコの話を何とかしろよと

検索しても見つからないんだけど、ハンブレスレってどこのこと？

探す気もないがたぶんHandBrakeのことだろう

ﾊﾝﾄﾞﾌﾞﾚｰｷか別にどうでも良いわ

L-SMASHを使ってみたいのですが
詳しく解説してるところないですか？
音声muxとかどうやるのかな

>>201
Help読めばわかる
英語アレルギーでも読みきれるほどの短いHelpしかない

L-SMASHって思ってるほど良くないよな
ここで宣伝してるのは中の人か？
宣伝したいなら名無しじゃなくて名乗って宣伝しろよ

中の人いるなら直すだろうしどう良くないのか書けよ

それを言い出すとお前も名乗れって事になる

匿名で要望くらいしてもいいじゃない

で、何がお望みなの？

パッチ当ててくれてて重宝してる
ずっと使ってる

おお…まずなんちゃらマニアックってのがキモい

そういうのはこっちでな
http://toro.2ch.net/test/read.cgi/avi/1252765934/

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

物の良し悪しとは別次元のところで敷居が高いわな
解説もPOPさんとこぐらいで、いわゆる馬鹿でもわかる一から解説みたいなのは皆無だし
remuxerのhelp見たところでalternate-groupとは何ぞや、で結構な人間が躓くと思う

たとえば
mp4box -add "映像.mp4" -add "音1.m4a:lang=jpn:name=main" -add "音2.m4a:lang=jpn:name=sub" -new "MUX.mp4"
みたいな事を今までやってたとして、同じ事をできるのかできないのか、できるならどうすればいいのか、
使い方の疑問に対する答えが、検索してもさっぱり引っかからないのはまあ厳しかろうて

もともと使い方分かる奴だけ使えよみたいなあれな物でしょ
自己満用なんだから

今更だがr1800-32bitあたりからr2106-64bitに変えてみた
処理速度が15%ぐらい向上？速くなっていたのね・・・

32bitから64bitに変えたからじゃないの
試しに2120の32bitと64bitで比較してみて

自分で試せよ。

2120は更に速いよ

専ブラをメモ帳にしながらWin7-64bit環境で2120を試してみた
x86-8bit --- 232.5秒
x64-8bit --- 213.0秒

ついでに10bit depthも試してみた
x86-10bit --- 317.8秒
x64-10bit --- 275.7秒
10bitだと411が420に拡がってしまうのだが何か設定ミスっている？

>>217
＞10bitだと411が420に拡がってしまうのだが何か設定ミスっている？

よくわからんがYUV 4:1:1のソースがYUV4:2:0になるってこと？
普通にエンコすりゃYUV4:2:0になるのは当たり前だが・・・。
ソースの渡し方や設定やどうやって確認したのかなど、情報を一切晒さずに
ミスってるかどうかを聞かれてもどうしようもないと思うが。

x264は未だに暗部の欠陥改善できてないのかよ
開発者は無能だな

10bitで大概改善されてると思うけど

10bitを前提にもちだす馬鹿発見ｗ

10bitは大概改善されてると思うけど

>>218
設定ミスはここの話じゃなかったな
8と10でログの出方が違ったので焦ったが
修正して狙った動画は作れるようになった

Windowsは未だにメインメモリ上限3GBの欠陥改善できてないのかよ
開発者は無能だな

64Bit使えばいいと思うけど

64Bitを前提にもちだす馬鹿発見ｗ

そもそも暗部を破綻させたくなければ
必要なだけCRFを盛ればいい話だしな、x264が暗部のビットレートを積極的に削るのは
そういう特性になるようセッティングをされてるだけであって、欠陥でもなんでもない。

iPhoneとPC兼用のファイルだから10bit使えないんだよな
あと俺には10bitの恩恵が無かった

>>225
その特性が問題だって言われてるだけでしょ
一定のクオリティを要求したのに「視覚的」に目立って劣るシーンが混入するのはどうなの？と。

音声圧縮分野でも聴覚心理を考慮した間引きがされてるわけで
映像も「理論的に最適でも視覚的に最適ではない」なら改善を求められても仕方ない

ditherのGradFun3やf3kdb(precision_mode=2)は、8-bitでも、
比較的に低ビットレートでも、ディザリングが崩れにくい感じだ。

これ以上となると、GrainFactory3で暗部にグレインを盛るしかなくなる。

マクロブロックの明るさを見て暗いところに超盛るぜ〜〜ってパッチが昔あったような

>>224
ハードの制約とソフトの仕様を同列に思ってる池沼発見ｗｗｗｗ
晒し上げ

一人で釣られる低脳発見

後釣り宣言ほど恥ずかしいものはないな

いや、俺無関係だし

>>229
HAQみたいなん？

いや、俺無関係だし（キリッ

　　　　　　　 　　　　　　　　　　　　　　　　　　 ／ ヽ
　　　　　 　　　　　　　　　　　　　　 　 　 　 ,／　 　 ヽ
　　　　　　　　　　　　　 　.　∧＿∧　　 ,／　　　　 　 ヽ
　　　　 　　　　　 　　　　 　（　´∀｀） ,／　 　　　　 　　 ヽ
　　　　　　　　　　　　　　　（>>230 つ@　 　　　　 　　　　 ヽ
　 　　.＿＿　 　 　 　　　　｜ ｜　|　　　 　　　 　　　　 　　 ヽ
　 　　|――|　　　　　　　　（_＿）＿）　　　　 　　 　　　　　 　 ヽ
　　￣￣￣￣￣￣￣￣￣￣￣￣|　　　　　　　　 　　　 　　　　ヽ
　　／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ　゜~ ~。゜　~ ~　~ ~~　~ ~~　~ ~~　~~　~~
　　⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡　〜　〜〜　〜〜　〜〜　〜　〜
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　　 　　│
　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　　 　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　 　　　　│
　　　　　　　　　　　　　　　　　　　　人人人人人人人 　　　　　　∧Ｊ∧
　　　　　　　　　　　　　　　　　　 ＜ 　　　　　　　　　 ＞　　　　　（ / ⌒ヽ
　　　　　　　　　　　　　　　　　　 ＜ 吊られちゃった ＞　　　　 　| | 　　| >>231
　　　　　　　　　　　　　　　　　　 ＜ 　　　　　　　　　 ＞　　　　 　∪ / ノ
　　　　　　　　　　　　　　　　　　　　∨∨∨∨∨∨∨　　　　 　　 | ｜|
　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　 　∪∪

ハードの制約…

地デジソースをx264でエンコしてるとcrf20くらいでも16MbpsのMPEG2より動きには強いのに
暗部はだいぶ劣る
そういう方針で設計してるんだろうか

>>238
まさかとは思うが、ソースと比較してるんじゃないよな。
MPEG2で再エンコしたのか？

>>238
設定が悪いだけです

おぉ・・・

ソース超えが基本です

ハイエンドオーディオ（）の世界だな

ディスプレイから１ｍ離れるだけで高画質になっちゃうよー＾＾

視力を落とすといい感じでブラーがかかるよね

ディスプレイにサンドブラストぶっかけたらいいと思う

かなり古めの応答速度が遅い、しかし解像度だけ高めの液晶を使うと
実写は良い感じにぼかしがかかって、高画質に見える。
てか、多少のことは気にならない。

L-SMASH r2120

エンコ止めて待ってたよ…

>>249
L-SMASH版って、どういうところが優れてるの？

10ビット使ってて
自分でビルド出来ないから

>>251
むむ？
>>248が言ってるのはPOPさんのビルドのことだと思うけど、POPさんのは8bit-depthだけだよね？

ゴメン違う所
でもずっと更新チェックしてたんだけど
見たらそこもちゃんと更新されてた

なるほど了解。

>>250
規格準拠の安心感、muxerいらずで楽チン

10bit派って今増えてるんだな
スマホで再生できれば10bitで仕上げるだけどな

実際に10bit派が増えてるかどうかというと、そうでもないと思うけどな。

対応プレイヤーがさっぱり増えないからね

x264を使ってるような人間は大体MPC-HCだと思ってた。
で、MPC-HCを使ってるような人間はmadVRも使ってるｗ
見せてって言われた時は困るけどね。vlcを付けてハイどうぞとはいかなくなるorz

保存目的じゃないスマホとPCの兼用ファイルだから再生できれば10bit移行するけど...
まぁー8bitソースでしかエンコしないから
10bit環境までは揃えるつもりないが

>>259
それはあるなw
知り合いに簡単にあげれないw

あげる友達がいないから安心して10bitでエンコードしてる

>>262
某アニメの主人公みたいにリア充なんだろう？リア充は市ね

僕はエンコした動画をあげる友達がいない

言ってる意味が分からん

>>262
僕と契約して友達になってよ！

某アニメのヒロインみたいにエアー友達作ればいいじゃない
友達はいいぞー

左遷はいいぞー

ワロタ
前向きだな

エア友達はいいぞー
CMカット中の作業とかしてる苦痛の時励ましてくれたりとか
エンコしたの確認で観てもらってアドバイスしてくれたりとか

俺も友達どころかエア友達も居ないけど
由緒正き付喪神が宿ってるストラップが喋りかけてくれるから寂しく無いんだぜ

僕はこのスレのみんなが友達だと思ってるよ

お歳暮・お中元・年賀状・暑中見舞いを送り合う仲の友人は居るが
顔も名前も知らないウェブの友達はいないな。作りたいとも思わない。

みんな自分語り好きなんだな

男子高校生だから

顔も名前も知ってるweb友達居たけど共通の趣味無くなったらすぐ消えちゃうよ
顔も名前も知らないweb友達も同じ

アーアー聞こえなーい

大丈夫だ。
人類皆兄弟。
(;∀;)

俺たち友達だろ！

人類皆近親相姦

このスレの住人にはなにかを感じさせてくれる。だから私は君らに言いたい！
ありがとう！そしてありがとう！っと

くたばれハゲ！

Vita用の最適な設定はなんだろ・

出たばっかりでバグ多そうだし
今何も言えないだろ

>>283
まず、作るなら960x540だなぁ。
iPhoneやiPodでも再生できる方が便利だし。

つまりハイプロはいらねぇ。外部出力もないし。

そのサイズなら3.2までで十分だな

>>285
Vitaだけで十分だろ
解像度はVitaでドットバイドットで表示できるようにリサイズ、
もちろんHighProfile

293 名前：名無しさん＠編集中[sage] 投稿日：2011/12/17(土) 23:47:12.95 ID:SRWnEPXK
PS VITA初期不良まとめ

・強制終了かけれるフリーズ
・強制終了かけれないフリーズ
・フリーズしたら「電池切れまで待たないと電源が切れない」（http://jp-playstation.custhelp.com/app/answers/detail/a_id/12187）
・ボタンが小さくて押しづらい
・アナログパッド干渉問題
・３ＧモデルでＳＩＭ認識しない問題
・指でスピーカーをふさいでしまう問題
・Vitaカード認識しない
・画面シマシマ問題
・充電できない、ＰＣに接続できない←NEW
http://umetaiko072.blog.fc2.com/blog-entry-970.html
・タッチパネルが反応しない
・アナログスティックが極端に硬い

これは酷い

vfw Guiスレでテストしてる奴居るが10bitでも再生報告あるぞ

iPhoneで10bitを視聴出来ればよいのだが
クラウドから引っ張る系のアプリだとストリーミングになり再生に支障がない
エンコスピードとか利便性考えると8bitで、画質が気になるなら盛っとけばよい

携帯端末用には兼用とか考えずに別にエンコする俺最強って事で

Vita、普通にPC用のファイルが再生できそうでいいな

8bitソースを10bit で出力してMPC-HC + LAV Filters + madVRで再生
同一ソースの同設定で8bitでも出力
圧縮率は確か上がってるが
やっぱり色合いが綺麗って思えないんだよな
色合いの変換が違い過ぎてどうも違和感
鮮やかになってるって言うのか微妙に思えてきた

>>291
1番の理想型だな
俺は面倒だからPC兼用

>>293
10bitソースじゃ無いなら素直に8bitで出しとけとしか言えん

LAV Filtersって最近よく聞くけどいいのそれ？

個人的には気に入ってる
LAV Filters + madVRは低スペックPCやXPユーザーにはいいんじゃねかな
低スペックだとゲフォ限定？だが再生支援もできるみたいだし

ほうほう
古いノートPCでもひっぱり出してきて試すか、今度メインPCをクリーンインスコする機会があったときに
クリーンインスコ前に試してみるかな

最近はMPC-HC内蔵でいいやってなった

LAVはともかくmadVRは重いほうだろ、低スペ向けとしては。

>>299
俺も。トラブルも面倒もない。あれもダメこれもダメって試してたのが阿呆らしくなった。

低スペックはLAVとmadVRはやめたほうがいいと思う。
LAV Splitterだと再生でCPU負荷が上がった場合、音がブツブツになる。Haaliなら平気。
madVRのほうは
　　- graphics card with full D3D9 / PS3.0 hardware support
　　- at least 128MB of dedicated graphics card memory
　　- Windows XP or newer
が必要条件だけど、５年前のノートでPixelShader2.0、ビデオメモリ64MBのうちだとそもそも使えねー。

>>293
10bit出力は実装したばかりの時綺麗とか鮮やかとか思ってたが、冷静に考えて観なおしたり
8bit出力と比較したら微妙と段々思えてきて10bit出力しなくなった
やっぱりソースは維持するのが無難だね...

ビットシフトや再生環境がまずいだけじゃないのそれ

俺もそう思う
それか単に下手なのか
あるいは弱視になってるのか

そいつ同一人物だろ

>>299
スプリッタだけはmpc-hc内蔵だとまずいんじゃ。
mp4だと音ズレするよね。

10bitってパッチ当てたのじゃないと色がおかしいって話は結局どうなったんだっけ

LAVはスプリッターだけ使わせてもらってる

>>308
16-bitで入力すれば、パッチ無しでも目で見て分かる誤差にはならない。

別に16bitである必要はなく8bit->10bitがまずいだけ

だよな10bitはゲームプレイ動画用って外人も言ってるし

>>311
これを使っていないx264では、たとえ10-bitの入力でも、一旦16-bitにアップサンプリングされるので、
16-bit以外を入力に使うのは無駄だと思う。

http://pastebin.com/iHqenZtb

fullrange（現在だと--input-rangeと--rangeか）がゲームプレイ動画に活用できるというのは
どこかで聞いた気もするけど、10bitがゲームプレイ動画用ってのは初めて聞いたな。

fullrangeがゲームプレイ動画に有効だというのも理由がよくわからないが
スーパーホワイトで出力したものをキャプチャして使うということなんだろうか？

スーパーホワイトでという表現がアレな気がするけど察してくれ。

バカバカしい話だが
外人が死ねと言ったら死ぬのだろうか

>>314
DSが、ゲームがソースの場合に、4:4:4を使えると言っていたから、それと勘違いしたのでは。

すまんそれだわ

>>313
あくまでも入力というのはx264に渡される時の状態でx264でどういう処理してるかは関係ないものとして答えただけ
自分はそれ使ってビルドしてる

確か初期のLDでパイオニアのLD-X1ってのがあったけどこれが9bit処理だった
あとソニーが初のDVD S7000が12bit処理
多くなれば丸め誤差が無くなるらしい

>>319
taroのパッチを使っている人なら、10-bitをそのままと言うのがベストなのは確かだね。
素のx264(10-bit)だと、入力は16-bitとするべきだろうけど。

>>317-318
なるほど。そのDS氏の発言は知らないけど、もしかしたらfullrangeがゲーム動画用に有効ってのも
自分の記憶違いかもしれないや。なんでそんな記憶があるのかさっぱり思い出せないｗ

>>322
有効というかゲームのキャプチャ方法によってはフルレンジ素材のものもあるからその時はフルレンジ使えよってことじゃないのか？

ゲームとかしないからそんなものがあるか知らんけど

>>307
L-SMASHでmuxしたmp4はGabestだと1フレ遅れてLAVFSplitterで問題なかったんだけど、
GPACだと問題なかったりする？HaaliはL-SMASHでSARが反映されないから今は使ってない

LAVでcook音声を再生させるとブツブツノイズが大量産される

PS3やXBOX360はフルレンジ出力できるけど、4:4:4でキャプチャーできるカードなんかあったっけ？

PCゲーのキャプはPGBとちゃうの？

何だよこの流れは…RGBでは表現出来るが通常のYUVでは表現出来ない範囲の色をRGBと同じ範囲まで使えるようにするってのがフルレンジYUVだろ

>>328
違うぞ・・・

>>328
違うだろｗ ネタで書いたのかもしれんがこれ以上カオスにするなよｗ
RGBとYCbCrを変換する時に、それぞれの値をどの範囲にするかということで圧縮レンジとフルレンジがあるってだけ。

　　RGB[R,G,B： 0〜255]　⇔　YCbCr[Y：16〜235、Cb,Cr：16〜240]　圧縮レンジ（TVレンジ、TVスケール、リミテッドレンジ）

　　RGB[R,G,B： 0〜255]　⇔　YCbCr[Y,Cb,Cr：0〜255]　フルレンジ（フルスケール）

フルレンジのほうがきめ細かく値を保持できるので階調を保ちやすい。
YCbCrとRGBではカバーできる色範囲も異なるので
　　「通常のYUVでは表現出来ない範囲の色をRGBと同じ範囲まで使えるようにする」
ってのは間違い。
テレビとかだとRGBのほうも16〜235だったりするけどそれは省略。

>>326
フルレンジと4:4:4の話は全然別の話で、
　　・フルレンジ出力（4:4:4というわけではなく4:2:2とか）でキャプチャしたものをエンコする場合に--input-range pcが利用できる
　　・PCゲームなどをRGBやYUV4:4:4でキャプチャしたものは--output-csp i444でエンコすれば
　　　420化による劣化を防げる（ただしDS氏の発言というのがこういうことを言ったのかどうかは知らん）
ということじゃないかな？

4:4:4か。
YCbCrでいいからx264vfwが対応してくれたら使ってみたいな。

YUV4:4:4は--profile high444じゃないの
i444ってインターレースぽいけど

>>324
＞L-SMASHでmuxしたmp4はGabestだと1フレ遅れてLAVFSplitterで問題なかったんだけど、
＞GPACだと問題なかったりする？HaaliはL-SMASHでSARが反映されないから今は使ってない

Bフレーム由来の初期ディレイというのは、Bフレームのデコードの仕組みによるデコードと表示の遅れのことで、
bframes>0で１フレーム分の遅れが生じ、b_pyramidをnone以外にすることで更にもう１フレーム分の遅れが生じる。
つまり合計で最大２フレーム分の遅れが生じてしまうため、L-SMASHもGPACもx264内蔵のMuxerも、
この遅れを解消するための情報として、MP4コンテナにedts（Edit Box）というBox情報をつけるようになっている。
例えば
　　--bframes 3 --b-pyramid normal
でエンコードした場合２フレーム分の初期ディレイが発生するけど、Mux時に
　　「映像は２フレーム分進んだ時間から再生を始めてくれよな」
という情報がedtsとして書き込まれる。
再生時にこのedtsを解釈するのはスプリッターの役目なのだけど、edtsをちゃんと解釈してくれるのは
Haali Media Splitter、LAV Splitterと、あとはQuickTimeくらい。

要するにMuxerはどれもedtsをつけてくれるようになっているので、初期ディレイについてはどれを使っても変わらない。
再生時にedtsに対応したスプリッタを使えばよい。

ちなみにL-SMASHに含まれているboxdumper.exeを使って以下のように実行するとMP4のBOX情報をダンプできる。
　　boxdumper.exe --box test.mp4 > testBox.txt
edtsにどういう情報が書かれているかもわかるので興味があるなら試してみるとよいかも。
ただし、でっかいMP4をダンプするとえらいことになるのでテスト用に短いMP4を作って見たほうがいい。

>>332
--output-csp <string> Specify output colorspace ["i420"]
- i420, i422, i444, rgb

--profileはプロファイルにあわせたオプション制限をかけたりするだけなので
--profile high444としても、出力色空間がYUV4:4:4になるわけじゃない。

色域を人の目の帯域に合わせたのがテレビレンジ
少ない放送電波で効率よく範囲を狭めたんだな
エンコでは赤系統で解像度の劣化が見られると思う
ドットみたいなもやもやがそう

赤系統が低解像になるのはyuv420とかの色差信号が間引かれてるせいでしょ。

>>336
いや、違うだろ・・・。なんか色々混ざってないか。

＞色域を人の目の帯域に合わせたのがテレビレンジ
＞少ない放送電波で効率よく範囲を狭めたんだな

色域はフルレンジ・テレビレンジとは関係ないでしょ。
「人の目の帯域に合わせた」とか「少ない電波で効率よく」というのは、
人の感覚にあわせてYUVの変換パラメータを決めたこととか、
輝度には敏感だけど色にはやや鈍感という人の目の特徴にあわせて
色信号(色差)の帯域やサンプリング数を削減しているという件と混同してないか。

＞エンコでは赤系統で解像度の劣化が見られると思う
＞ドットみたいなもやもやがそう

これは>>337も書いているとおり、4:2:2とか4:2:0といったサンプリングでは色差信号が間引かれているためでしょ。
YUV4:4:4であれば各ピクセルでRGB⇔YUV変換による誤差が生じる程度であり、色解像度の低下は起きない。


アナログの信号を8bitのデジタル(整数)に量子化する際に、同期信号などの関係もあって
R,G,B,Yで黒を16、白を235と決め、Cb,Crを16〜240と決めたのがテレビレンジ（圧縮レンジ）。

信号はともかくとしてデジタルデータとしての扱いでは0-255をフルに使ってもいいんじゃねえのということで
0-255で扱うのがフルレンジ。

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

おぉ・・・

VitaとVistaが似てるせいでたまに？ってなる。

>>339
BDのm2ts だと、２時間もので35GBとかあるから
確かにtsの３倍くらいきれい

まあチャンネルによって、かなり圧縮率も違う

>>340
IDがPOP

今時mpeg2を採用したデジタル放送はオワコン

オワコン

これ使ってて恥ずかしくない？
ちなみに見てる俺はすげー恥ずかしい

オワコンにトラウマがある理由は自分が使ってたから？
素直にNGにすりゃいいのに

これ使ってて恥ずかしくない？

って言うのって恥ずかしくない？

今日のおワンコ！東京都葛飾区の柴犬タロちゃんです

オワコンはともかくとして>>348は見ててちょっと恥ずかしい

それほどでもない

オワコンは今でも普通に使うけどな
やっぱり恥ずかしいって言う奴が恥ずかしい

おお…わこん

オウンコ

オ○ンコ

デジタル放送はそもそもコンテンツではない、という突っ込みはないのかよｗ

MPEG2-TSは終わったコンテナと言いたかったんだと思ってた

まさか、コンテナとしてならAVCHDとかBDとかでバリバリ現役ですよ。

ほんと、どうでもいい話だな。x264と何の関係があるんだよｗ

ここまでいつものx264スレ
↓ジーブ氏

ここから先もいつものx264スレ
↓ヨブ氏

めんどくせえからJEEPに改名しろ

GEEK氏

いぇ〜い！イェーブたん見てるー？＾＾

　　　　|┃三　　　 ,ｲ,,i､ﾘ,,リ,,ﾉﾉ,,;;;;;;;;ヽ
　　　　|┃　　　　.i;}'　　　　　　　"ﾐ;;;;:}
　　　　|┃　　　　|} ,,..､_､　 , _,,,..､ 　|;;;:|
　　　　|┃　≡ 　|} ,_tｭ,〈 　ﾋ''tｭ_　 i;;;;|
　　　　|┃　　　　|　 ｰ'　|　｀ - 　 　 ﾄ'{
　　　　|┃　　　.｢|　　 ｲ_i _ >､ 　 　 }〉}　　　　　＿＿＿＿＿＿＿＿＿
　　　　|┃三　　｀{|　_;;iill|||;|||llii;;,>､　.!-'　　　／
　　　　|┃　　　　 |　　 　＝'" 　 　 | 　　　＜　　　話は全部聞かせて貰ったぞ！
　　　　|┃　　　 　 iﾞ ､_　　ﾞ,,,　 ,,　' {　　　　　＼　 おまいら全員シベリア送りだ！
　　　　|┃　　　　丿＼　￣￣　 _,,-"ヽ　　　　　＼
　　　　|┃　≡'"~ヽ　　＼､_;;,..-" ＿　,i`ー-　　 　￣￣￣￣￣￣￣￣￣
　　　　|┃　　　　 ヽ､oヽ/ ＼　 /o/　 | 　　 ガラッ

ジェイダブルイーベーダ卿

あいかわらず安定の民度だなここはｗ

猫科さん2120の翻訳と解説はようたのんます

お前がやれ

これの翻訳と解説って何を期待してるんだ・・・

commit 0c7dab9c2a106ce3ee5d6ad7282afb49e1cc3954 r2120
Author: Jason Garrett-Glaser <[email protected]>
Date: Tue Dec 6 14:39:21 2011 -0800

Fix regression in r2118
Broke trellis with i16x16 macroblocks.

r2118のバグを直した。
16x16イントラ予測のマクロブロックで、trellis が正常に動作していなかった。

にすら日本語訳が必要な辺りに絶望しちゃうね。

一般人的に2120の前って2106だっけ
http://x264.nl/に出るのは安定版てことでOK?

安定版など存在しない。

質問しといて言うのもなんだけどテキトーなこと言ってない?
んじゃリンク先のページのmasterとかstableってのは何なの

masterは"従来通りの最新"で、stableはバグフィックスを主とした最新であり、
"特別に"安定版が必要な場合に利用できる。

http://www.up-cat.net/x264%252Dchangelog%252Djp.html

べ、別に知ってたし！

>>369,370
trellis が正常に動作していなかったから、速かったのか？

>>366
I can raws aunty no mean do to now cocoa.
うん、意味不明

最近はやり始めてるHi10pってのは10bit-depthのx264.exeを使うだけで
あとは何も変えないでエンコしてでOKなの？

>>378
やめとけｗ

>>378
>Change the bit depth conversion algorithms to follow BT.709 Part 2 for limited range.

x264で8-bit -> 10-bitとするのだったら、このパッチを使ったx264が良いだろうね。

http://x264.fushizen.eu/?p=393

このサイトの解説も、最近の事情に関して上手に書けている。

http://k4095-takuan.blogspot.com/2011/10/avisynth-x264-10bit-depth.html

10bitなんて余計にデータ量とエンコ時間がかさむだけだろ。
nv以外再生支援もまともに機能しないし邪魔なだけだ。

この人何言ってるんだろう

とりあえず10bitはグラデーションが綺麗になる（バンディングが軽減する）ぐらいの認識でいいのか？

10bit使うつもりなし

>>383
20%程、PSNRも改善する。

http://3.imgland.net/DDvSI.png

>>374 ありがとう

10bitだと妙にクリアな感じがするのはNRの軽減なのか

でも、お高いんでしょ？（ビットレート的な意味で）

安いだろ。

お高いです(再生環境のハードル的な意味で)

まだそんな事言ってる人がこんな所にいるなんて

まだPC以外の機器で使い回しにくいのがな

Androidなら普通に再生できる

8bit環境の俺の素朴な質問。

10bitエンコって、.264に10bitで保存している、再生環境を選ぶぜ、ってこと？
それとも、filter/エンコ処理は10bit、.264出力は8bitで出てる、ってこと？

内部は16ビットのdctなんだと思ってた

>>387
PSNRはNR(ノイズリダクション)じゃないｗ

>>394
8bitっていうのは、色の諧調(濃淡)が256段階って意味。
10bitは1024段階、16bitだと65536段階。
つまりバンディングに効果がある。

エンコードする素材は8bitだから、10bitに変換(フィルタリング)して、10bitで保存する。
x264は8bit→10bitの変換をする機能は付いてないので、flash3kyuu_debandでその処理をする必要がある。
保存されてるデーターは当然10bitなので、10bitデーターに対応した再生環境が必要となる。

> NR(ノイズ比(率))の軽減
って勝手解釈してたわ

＞x264は8bit→10bitの変換をする機能は付いてないので、

いやついてるだろ。パッチ当ててないとおかしくなることもあるが。

パッチあてないとまともに使えないものなど触らない方が言いに決まってるだろ。
DXVAでまともに再生できない10bitなんてゴミとしか思えないが。
エンコ機と再生機は大抵わけて使っているだろ？

毎度毎度
10ビットの何かにいじめでもあってるのか？

自分が使えない→あれは酸っぱいに違いない

再生支援使えなくて全く困らないし

わかったからゴミの戯れはその辺にしとけ。

俺は10bit使う気はないなぁ

プレイヤーが全然対応してない
これがすべて

あのGOM（）笑ですら10bit対応になったとか見かけたけど

利点欠点あるわけだし、自分に合う方選べばそれでいいだろ
自分が選ばなかった方を叩くのは単なるストレス解消以上の意味がない
過渡期の電気自動車みたいなもんだ
いずれは完全に移行するかもしれんがインフラが整ってない地域も多く
現時点では利便性に差がある
どっちがえらいわけでもない

BDがhi10pで出ることはないだろうし普及はHEVC待ちじゃね？

iPhone持ちだが10bit再生をあれこれ調べてみた
iTunes→iPhone　再生できず
AirVideo→iPhone　再生可能
SkyDrive→iPhone　再生可能
AirVideoとか経由すると8bit変換されるのかな？

個人的に画質は8bitに盛っとけばOKと考えている

盛ってもどうしようもないから10bitエンコするんだよ

夢がもりもり

マルマルモリモリ 暗部ムラるよ

ツルツルペタペタNL-means

カーン！
残念、鐘1つです

>>385
PCでしか見ないならば、個人的に充分使う価値があるな。
ありがとう。

>>409
緑再生ならAirvideoでいけてるんでないの

JEEB　r2120

サブタイｗ

さやかちゃんって誰？

さやかちゃんｷﾀｰ!!

10bit使うならnlじゃない方がいいの？

さやかちゃんwww
ヨブさんまどかとか観るのかw

>>421
>Change the bit depth conversion algorithms to follow BT.709 Part 2 for limited range.

8-bitをソースにするつもりなら、このパッチは必須になる。

必須ではないが

>>424
見比べて分かる違いとして、少し明るくなる。

http://mailman.videolan.org/pipermail/x264-devel/2011-July/008685.html

>>425
avsで>9bit-depthにすればいらないという意味なのだが

>>426
それはそうだが、バンディングが気にならないソースは、8-bitをそのままと言う人も多いとは思うので。

avsで>9bit-depthにする際にバンディング低減処理を必ずしないといけないわけではないぞ
高ビット深度への変換だけを行うことが可能

BDのH.264は何？
多分8bit AVCだと思うけどバンディング出てないよな

それはマル・マル・モリ・モリだから

ずっと前からおかしな変換してることがわかってるのに、
なんで>>423のパッチはx264に正式に取り込まれないのだろう？

taroがパッチを送らないからだろ
MLなりIRCなりでパッチを出さない限りcommitはない
出せば必ずcommitされるとも限らないけどな

なんでtaro氏が出てくるんだ？
ヨブさんだろ
あとbm氏はこのこと把握してるぞ

ああ、勘違いしてた
入力時10bitは16bitにしないやつかと思ってたわ

あれnlって今ヨブさんがビルドしてるんじゃなかったっけ？
それでも10bitやaq3使えるのヨブさんのサイトのやつだけ？

>>435
.nlのは元々パッチあてない方針なんじゃなかったっけ？
JEEB氏のサイトでもUnpachedは.nlでみたいに書いてあるし

aq-mode 3使ってみたいから
JEEB氏の使ってみようかな

>>436
それがよくわからないんだよねえ。
使い勝手を上げるためのパッチならともかく、>>423の件は根本的なバグだと思うんだけど・・・。

.nlはリファレンスビルド的な位置なんじゃ
これがないと異常(あえてバグとは言わない)があっても
ソースが悪いのかビルドの仕方がおかしいのか
各々が当てたパッチとの相性なのかすら判断がつかない

>>437
aq 3ってaq 1やaq 2に比べ同一の設定、ビットレートで画質かなり悪くなる気がする。2Dでも3Dでも
まあ最後に使ったのはJEEB氏の初めて公開されたバージョンだけども

aq2がそもそもひでぇからな
輪郭に与えるダメージパネェっす

aq 2の改良が3じゃないのか？
どっかせaq 3が良くなったみたいな書き込み見て俺も興味はあった

平坦なソース（アニメとか）でなければaq2で特に問題無いと思う

でも利用者は9割以上アニメなのは確定的に明らか

Mステとかのスタジオライブだけのオレはマイノリティでつか

世界の車窓からと世界遺産をエンコする俺は異端児

毎週、ドライブGo!Go!と温泉女子とロケみつを欠かさずエンコしている俺も忘れるな

おいおい
地井武男のちい散歩を週5エンコしてる俺に謝れ

もっと温泉に行こうをNEXT ONE BSスカパーを巡回してエンコしてる俺がきますた

世界でアニメ以外をエンコしてる5人全員がここに集うとは。

ナショジオHDとアメドラを持ち出し用で

明けテレやら声優系のはエンコしてるな

ナイトスクープ

たけしのみんなの家庭の医学とTVタックルは毎週エンコしてる

例外ばっかり集まることは稀によくある




うん、俺が悪かった

TopGearとNHKスペシャル、ETV特集をほぼ毎週エンコしている俺も
混ざっていいよな？

レス読んでキーボードに茶吹いてしまった

そういえばニトリにラバー製のキーボード売ってたな
プラスチック部分はUSBコネクタだけという変なキーボード
アレを使えばavs編集とかコーディングとかさぞ捗るんだろうな

アニメしかエンコしない俺は普通の人だったんだな、安心した

まぁ、アニメが一番きれいに縮むし、やる意味感じられるわな
実写も縮小するなら意味あるかな。

>>423のパッチなんですが

depth [info]: skipped depth filter

って出てれば無駄な変換挟まれてないって認識でおｋですか？

>>461
違う奴か。なんか寝ぼけてた関係なさそうです。スルーしてください。

誰かの名前とよく似たJason Garrettも活躍するNFLは、x264でエンコードをしないと、
一つの試合が、一層のBD一枚には焼けない容量になってしまう。

http://www.dallascowboys.com/team/team_biosCoachExec.cfm?newName=Jason_Garrett

アニメなんてQSVで十分だろ。どうせ平坦なソースそろいなんだし

>>464

>>465

どうせ
どうせ
どうせ

アニメと言ってもOP/ED専もおるでよ
最近はCG処理やらエフェクトやら多いし、実写ほど複雑じゃないから手を抜くと劣化が目立って困る

複雑なの？
複雑じゃないの？

輪郭線はベクタ形式使う仕様のコーデックならアニメ最強なんじゃね
汎用性皆無で普及しないだろうけど

まんがはCUDA程度で良いでしょ
携帯とかで画面を録画するだけでも良いような？

>>471
目の悪いお前のレベルならそれでいいんじゃね

流石にそれはねえよ

>>460
全然縮まないよｗ
一昨日のＭステのAKB出演部分エンコしたら15Mb/sでソースよりでかくなったわｗ

そんなの設定とかソースの出来次第では

AKBとかキモい単語書かないでくれるかな？

一昨日のＭステのKGB出演部分エンコしたら15Mb/sでソースよりでかくなったわｗ

アーカーベー

KGBとかコワい単語書かないでくれるかな？

>>475
--crf 23 --rc-lookahead 40 --min-keyint 1 --keyint 300 --tff --deblock -1:-1 --b-adapt 2 --direct "auto" --me umh --subme 9 --merange 24 --weightp 0 --b-adapt 2 --ref 3 --trellis 2
--no-fast-pskip --no-dct-decimate --8x8dct --level 4.1 --cqm flat --colormatrix bt709 --colorprim bt709 --transfer bt709 --vbv-maxrate -1 --vbv-bufsize -1 --fps 30000/1001 --sar 4:3
設定はこれ。ﾌｨﾙﾀｰはロゴ消しとNL-meansを軽く。ソースは動きまくりでノイズだらけｗ

>>480
GUIスレでも逝けやチンカス

実写にNRするとかキチガイか？

酷い言い方だなあ

実写をエンコするとかキチガイか？

この軍事施設の外に居るなんてキチガイか？

つまんねーよ俺

そんなエンコで大丈夫か？

>>482
もやもや・ざらざらの除去と、細部のつぶれの妥協できる設定にしてるよ
NL-meansの低周波保護使うと実写でもイイ感じだよ

--min-keyint 1ってどうなの？

実写はカーグラフィックTVとビフォーアフターをエンコしている

実写はホワイトレーベルをエンコしてる

エンコ初心者だけど、
アニメは低レートだとダメってのは、ベタ絵を高圧縮のJPEGで保存するとひどい画質になるのと同じようなものなのかな

初心者っていうからにはこのスレを活用してくれ

x264 初心者質問スレ part5
http://toro.2ch.net/test/read.cgi/avi/1314616372/

>>492
どもども
今度からそっちで聞いてみる

10bitエンコやってみたんだけど再生するとJEEBのr2120_64bit版でエンコしたものだけ色が若干薄くなってしまう・・・

nlの方のr2120だと8bitでも10bitでも色はソースを比べても変化なかったんだけど何かやり方間違ってるんだろうか？

エンコ方法はavs2pipemodで

＊＊＊\avs2pipemod.exe -y4mp=1:1 "＊＊＊.avs" | ＊＊＊\x264.exe - --input-depth 10 --crf 20 --colormatrix bt709 --colorprim bt709 --transfer bt709 --profile high10 --demuxer y4m -o "＊＊＊.mp4"

AVSの中身は
LoadPlugin("＊＊＊\DGAVCDecode.dll")
AVCSource("＊＊＊.dga")
のみ、dgaはとあるブルーレイ映画の8bitHDソース

10bit使ったことないから知らんがな

>>494 >>492

10bitなんてflashがまともに対応してない現状ではただのゴミ

違法うｐ厨乙

flash

おぉ・・・

生TSが一番綺麗です
おわり

一番ではないだろ

生TSはまな板に載せる前の魚みたいなもんだからな。

おお…無圧縮aviが一番高画質だと思ってるのがいるのか
crf23程度でソース超える程元が糞画質の動画なら適当にnlかけた方がまず綺麗に見えるな

TSはしょせん20Mbps前後のMPEG2エンコ
エンコ前のソースより遙かに汚い

20Mbpsなら1時間あたり9GBにもなるぞｗそんなに出してる局ってあるのか?

え？

>>506
衛星放送

俺が世間知らずなだけだったごめんなさい

おお…生BDソースが高画質だと思ってるのがいるのか
エンコした方がずっと綺麗になる

縞々BDとかはそうかもしれんがな

しまったそれがあったかｗ

真実の涙

乃絵はてんす

あぶらむしー

転倒、炎上するスクーター

前スレでr2120をお勧めされて使っているが
速いし不具合ないしこりゃいいものを教えてもらった

チンコの皮がmuken

この意気地なし

ちんこ生えてきた

返せよ

どこへw

まんこへ

このスレ異界だわ

LAVでデコードさして、ffdshowのバンディングノイズ低減をかける
っていう事は出来ますかね？

できる

山ちゃんはなんでバンディングノイズなんて訳したんだろう

-WARNING-
以下のことは適当に調べて推測しただけの代物ですので、戯言と受け取って欲しいです。


・まずは、10bitについて

光の三原色(R(赤)・G(緑)・B(青))が、デジタル色を構成する物です。

少し前のPC(5bit) 画面の色 16bit(R(5bit)G(5bit)B(5bit)) 32階調 32,768色

現在のPC(8bit) 画面の色 24bit(R(8bit)G(8bit)B(8bit)) 256階調 16,777,216色(約1,670万色)

今回の話(10bit)　画面の色 30bit(R(10bit)G(10bit)B(10bit)) 1024階調 1,073,741,824色(約10億色)

分かり難いとは思いますが、8bit・10bitとは、RGBの一色の表現できる種類を指しています。
8bitは、2(進法)の8乗で256(階調)、それが3色あるので、16,777,216色を表現できるという意味。
つまり、bit数が多いほど、画面1ドットで表現できる色数が増えると考えていいです。
色数が増えると、グラデーションが綺麗に再現できる。

しかし、普通の人間に認識できるのは8bit(フルカラー)までみたいです。
10bitの存在意義が無いみたいだけど、人間に認識できなくてもデジタル的に高画質には変わりません。
そこで、映像を編集・圧縮する過程でのソース劣化を最小限に抑える効果が生まれるわけです。

・x264の10bitについて

10bitエンコードの意味は、ソース再現性に尽きると思います。
編集・圧縮する過程でのソース劣化を最小限に抑える効果ってのが、エンコードにも期待できる。

ソース再現性が高い＝ノイズ系劣化が発生しにくい＝8bitより同じ画質で容量が小さい
階調数が多い＝グラデーションが綺麗＝バンディングが出難い＝暗部に強い

となるのでしょうけど、
バンディングについてですが、対策の一つとしては、
crfなどの直接画質に影響のあるものを再現性重視に設定する。(高画質エンコード

つまり、再現性の観点で考えると、10bitエンコードと高画質エンコードは似ている要素が多いので、
効果が出難い恐れがあるということです。
ソース再現性といっても、ソースが客観的低画質だったり、ソース自体にバンディングがあると
フィルタで対応するので、10bitの影響力は弱まります。(それでも8bitよりは効果が出ますが

別に10bitエンコードを否定しているわけじゃありません。
最も効果的に10bitを活用するには、容量重視エンコードをしている方だろうと考えます。
今までの画質でより小さくなり、crf数値を高くした場合のバンディングを抑えられるからです。
そう考えると、例えば「ニコニコ動画」などの容量制限された投稿動画などは、
(デコードの問題は置いとくとして)有利に働くでしょう。

また、実写は容量が増えやすいので、crf数値を高くした容量重視エンコード、
暗部の多いライブ映像などは効果が期待できる分野かもしれません。
アニメよりむしろ低容量実写エンコード向きのような気がします。

商業的には再生機の互換性の問題があるので、
個人で楽しむぐらいしか使い道がないと思います。

お触り禁止

>>528-529
http://dokoaa.com/ores.html

自身満々に間違いを書くと誰かが正しい答えを書いてくれるメソッド

なんか根本的なところから間違ってるなw

ちょっとお腹痛いｗ

間違ってるって言ってる奴は基本的には答えは絶対出さないからな

いや、でもこれ本当に釣りかってレベルで全体的に間違ってるでしょ
XAwA12/hが理解できるように一から丁寧に説明して言ったら、相当な長文になるよw

ほら、結局何がどう間違ってるのか絶対に答えださないからなｗ

お触り厳禁

まずウンコ液晶の色再現力をどうにかしたいｗDLPプロジェクターの方がグラデーション綺麗

よくわからんが三原色を持ちだした時点で既に雲行きが怪しくなってた。

>>528の部分は別に変なことは言ってないと思う。
>>529は俺の知識だとボロが出そうなのでうまくつっこめないｗ

ただ、再生に必要なYCbCr -> RGB(8-bit)も、YCbCrが10-bitである方が良いのは確か。

hi444ppの10bit RGBなんていつの間に対応してたんだ

詳しくは知らないが，人間の目は
赤の分解能についてはに8birでは不足で
10bitくらいないと足りないとする研究結果もあるらしい。
http://ja.wikipedia.org/wiki/%E8%A7%A3%E5%83%8F%E5%BA%A6#.E4.BA.BA.E9.96.93.E3.81.AE.E7.9B.AE

typoすまん。8bir→8bitっす。

だが待って欲しい俺が赤色と言ってるこの色ははたしておまえさんにも
同じような赤色として見えているのだろうか？

なおソースはWikipedia

灰色に見えてるんじゃないか？って感じのヤツいるしな

白人って目が青いけど俺らと同じ色に見えてるんだろうか
ディスプレイの色で日本人は青が、白人は赤が強めな方が綺麗に見えるとか聞いた事がある

元データがRGBならYUV変換の係数の関係で赤や青の色が減るので
10bitのエンコードは意味があるよね
適当に作ったWRGBのランプを8bitで表示させた場合のキャプチャ
RGB8bit
http://uploader.sakura.ne.jp/src/up74840.png
YUV8bit
http://uploader.sakura.ne.jp/src/up74843.png
YUV10bit
http://uploader.sakura.ne.jp/src/up74844.png

色覚異常者は赤の弁別能力が普通の人より低くて
青に関しては普通の人より弁別能力が高いらしい
健常者には同じ緑色に見えても色覚異常者の高い弁別能力によって細かな違いを見分けられるらしい

日本人は蛍光灯の使い過ぎで青白いのが白だと思い込んでしまった

日本人の青白好きは異常だよね
やや青白いディスプレイまで尿液晶とか馬鹿ぬかしやがる
もう┐(´д｀)┌ﾔﾚﾔﾚ

>>549
瞳の色で色の識別感覚は確実に違うようで、絵画なんかでそんな話をたまに耳にする
また、男女でも色の認識は違い、男よりも女の方が知覚している諧調は多い

相棒に至っちゃ真っ青だからなｗ

おまいらの好きな色温度って何度くらい？
俺は8000〜9000℃かな
10000以上はもう青って認識になる

>>543
8bitは--output-csp rgbで出力できるけど、10bitのほうは対応してないでしょ。
少なくともr2120の10bitで--output-csp rgbを指定してもエラーになるよ。
ついでに言うと、8bitでrgb出力したものも、ちゃんと再生できるデコーダーは無いような気が。
CoreAVCとかの有料系がどうなってるかは知らないけどffdshowもLAVも無理だよね？

Yシャツは青白いぐらいが丁度いいんだよ。
んで、>>528>>529はYUVについて何もわかってないからさよなら。
>>550が全て。

>>556
℃じゃなくてK（ケルビン）
ちなみにアメリカと日本だと、NTSCの白の色温度も違う。

Wikipediaが出てきたついでに詳しそうなスレ住人に聞きたいんですが、
色空間のページに書かれてるYCbCr・YPbPrについての記述って間違ってますよね？

　　色空間 - Wikipedia
　　http://ja.wikipedia.org/wiki/%E8%89%B2%E7%A9%BA%E9%96%93

　　＞なお、Cb,CrとPb,Prの使い分けについて、
　　＞　　1.（B-Y）,（R-Y）に特定の定数を掛けたアナログ信号にCb,Crを用い、デジタル化された数値にはPb,Prを使う。
　　＞　　2.アナログ、デジタルを問わず、SD映像用の色差コンポーネント成分にはCb,Crを、
　　＞　　　HD映像用の色差コンポーネント成分にはPb,Prを使う。
　　＞の2説があり、明確には統一されていない。 一般的なビデオ機器には後者が採用されているようである。
　　＞GBR成分からのカラーマトリックスがSD用とHD用で異なることを考慮すると、後者の使い方が望ましいと考えられる。

正しく書くとしたら

　　１．（B'-Y'）,（R'-Y'）に特定の定数を掛けたアナログ表現ではPb,Prを使い、
　　　　それを基に量子化したデジタル表現ではCb,Crを使う。

　　２．アナログコンポーネント信号においては、480iの信号への対応を示す際はCbCrと表記し、
　　　　それ以上の信号(720pや1080iなど)への対応を示す際はPbPrと表記する。

だと思うのですが、合ってますでしょうか。

調べてみて見つかった根拠を挙げてみますが、不十分であれば指摘下さい。
スレチ気味ですみませんがWikiを修正するにしても詳しい人に聞いてからのほうがいいかなと・・・。

○ARIBのHDTV規格（BTA-S-00?）などで当初PbPrという表記が使われていたのも混乱の一因だったと思いますが
　　　　○BTA-S-002 B版(1998年)の審議経過より
　　　　　　また、本規格においては色差信号の呼称を全て“PB、PR”と表記しているが、
　　　　　　一方SMPTE やITU-R 文書では、アナログ信号はPB、PR、デジタル信号はCB、CR と
　　　　　　使い分けられていることから、これらに整合させるべきとの意見があった。
　　　　　　しかし、本規格は既に策定後6年を経過し、製品機器や付属資料などに
　　　　　　広くPB、PR の呼称が適用されていることから、
　　　　　　従来通り専らPB、PR の表記を使用することとした。
　　　　○BTA-S-001 C1.0版（2009年）
　　　　　　1.5 表記法
　　　　　　色差信号の呼称として、本規格では従来「PB, PR」を用いていたが、
　　　　　　ITU-R およびSMPTEでは現在「CB, CR」を使うようになっているため、
　　　　　　本規格でも「CB, CR」に統一した。
　　とあるように、「デジタルだからCbCrにするぜ」と変更されている。
○SMPTE 274MやSMPTE 296Mの概要説明でも「PbPrはアナログ、CbCrはデジタル」と書かれている。
○その他参考資料
　　・SD/HD デジタル・ビデオ信号測定入門 > アプリケーション・ノート／技術資料 : Tektronix
　　　　http://www2.tek.com/cmswpt/tidetails.lotr?ct=TI&cs=pri&ci=2210&lc=JA
　　・HDアナログ・コンポーネント・ビデオ信号測定 > アプリケーション・ノート／技術資料 : Tektronix
　　　　http://www2.tek.com/cmswpt/tidetails.lotr?ct=TI&cs=apn&ci=5578&lc=JA
　　・英語Wiki等（こちらも微妙に混沌としてますが）

ITU等他団体でも統一されたのでしょうか？

>>562
>>561にあるように
　　「SMPTE やITU-R 文書では」
とは書かれていますが、その他にどんな団体があるかとか、そこではどうなってるかとかはさっぱりです。
私はググって調べただけの素人なので専門的な知識を持ってる人がいたら教えてもらいたいなあと・・・。

他にはISO/IECでも、MPEG-1の頃から、「PbPrはアナログ、CbCrはデジタル」となっているね。

>>556
眼科へGO!

>>565
お前がなー

ここでログを見て10bitのことがわかってきたが、教えて欲しい
10bit再生環境について詳しいところはありませんか？
ビデオカードは比較的新しいRADEONでHDMIでレグザでいける？

>>567
日本語でおｋでダメでおｋ

>>567
比較的新しいRADEONってのがわからん
うちのはRADEONできる

Radeonネイティブで10bitサポートしてんの？

初耳だけど

「RADEONできる」を翻訳することから始めなければならないだろう

>>567
P010(YCbCr 4:2:0 10-bit) -> RGB(8-bit)でも十分な効果があるから、
madVRを扱えるGPUなら、何でも良い。

おちんちんできる

色空間スレってのがあったんだけどな・・・

10bitが出たから需要が再びあるかもしれんね
誰か立ててくれ

たまにこのスレ色空間の話になるよね。
スレチスレチとアレルギー反応起こす奴もいるから立てたほうがいいかもしれんな。

!ninja

>>571
5000あたりからDirect3Dフルスクリーン限定

●＿＿＿　 んでっ！んでっ！んでっ！　(にゃあ)にゃ〜んでっ！　かまって かまって 欲しいの〜
┃　　｡｡　∫　イイ子じゃない時のワタシ〜　カワイイとかって ありえな〜い
┃ 　○ﾟ　∫　　ソレ！ソレ！ソレ！(にゃお)LOVE！　もらって もらって ください〜
┠〜〜〜┘　　　非常事態が にっちじょうです〜　好きって言ったらっ ジ・エンドにゃん！
┃　　　　　　　　　　わがまま、そのまま、 ねこまんま〜　上から目っ線のてんこ盛り〜
┃　　　　　　　　　　　三毛ブチ〜　トラシロ〜(早くしろ！)　ウェルカム 猫招き〜
┃　　　　　　　　　　　　調子にのっちゃだめ〜　にゃんたら優しすぎるの、ダ・イ・キ・ラ・イ〜(みゃ〜ん)
┃　　　　　　　　　　　　　はっぴぃ にゅう にゃあ〜　は〜じめまして〜
┃　　　　　　　　　　　　　　キミにっ　あげるっ　さっいしょの　オーバーラーーン！
┃　　　　　　　　　　　　　　　逃げるから〜 追い掛けて〜 まぁるいせか〜い〜
┃　　　　　　　　　　　　　　　　ラ〜〜ッキー ニュ〜 フェ〜イス
┃　　　　　　　　　　　　　　　　　ち〜〜っかづいてる〜 わたしだけ見つけなさい〜
┃　　　　　　　　　　　　　　　　　　拾いたいなら 拾えば〜〜〜〜〜〜いーじゃん！

せやな

!ninja

　

保守

ところでさ、x264は3Dに対応する予定はあるのかな？
ソニーのヘッドマウントディスプレイで3Dが盛り上がりそうなので、対応してくれるとありがたいのだけど。

そんなゴミ機能なんて実装しなくていい。
エンコーダーが対応するよりプレイヤーやコーデック側で再現すればいいだけなんだから

3D専用のエンコードって左目用をベースに右目のを差分で作るとか
フレーム間取得と別のアルゴリズムがで圧縮率稼ぐから欲しい機能だ
まぁmp4に3Dコンテンツを載せる方法が決まって入ればだけどさ
サイドバイサイドでいいのかな？

３D対応家電の売れ行きを見ても需要なんてほとんどないだろ。
一部の３Dマニアだけが喜ぶ機能じゃねーの？sourceforgeとかで派生版ビルドでも作ってろ。

そんなんにリソース割くくらいならgpu対応なりほかに力入れてくれたほうがいい

DSはFixstarsがMVCのサポートを完成させたと言っているけど、試した人はいるのかな。

http://pastebin.com/qZ1xSmuc

ファミコンでも液晶シャッター式3Dがあったけどすぐにオワタな

つべはmp4に3D格納してるな

3Dはミラー法がコスパ最強
疲れるけど

半年〜1年ぐらい前に実装してなかったっけ猫科で見た記憶がある

fullhelp見れば--frame-packingでいろいろ書いてあるだろ

YouTube形式

コンテナは、*.FLV、*.MP4。
動画コーデックは、H.264/MPEG-4 AVC←映像コーデックはこれと覚えておいて間違いない。
旧形式では、H.263だったが、56.comなどのその他の動画共有サイトは未だにH.263形式が使われていることもある。

音声コーデックは、主にAACだが、MP3、WMA、FLAC、Ogg Vorbisを埋め込むことも可能。

FLVやMP4にWMA/FLAC/Vorbisが使える？
Matroskaだろそれは、このボンクラが

このコテ誰なの？

気にすんな

ちんこかゆい

!ninja

>>596
ここぞとばかりに披露した自分の知識が間違ってるってどんな気持ち？

http://www.google.co.jp/search?q=%22NERVpDWGM%22

ろくなカキコしてねえな

うｍ

【初心者歓迎】　録画したテレビを　DVDに
http://toro.2ch.net/test/read.cgi/cdr/1042013918/484

エンコ中のファイルって途中で見る方法ないのかな
wmvだと普通にコピーしたファイル見れたけど
なんというかクローズ処理みたいなものが必要な感じで

途中で確認出来ると結構助かるんだけど

生で出した場合できる

赤ちゃん？

JEEBaby機能搭載しる(＊´Д｀)

こういうところで意味もなくコテハン付けてるのはキモイ奴しかいない

--sarみたいに、最低限これだけは設定しとけ！なオプションてある？

sarて設定いらないような
デフォルトで0:0でしょ

>>610
VUIだと、自分で--colormatrixや--rangeにも正しい物を指定しておくと安心かも。

>>610
自分は、再生互換のためにBフレとrefを3に縛ってる

またGPUエンコの話何だ、定期的に済まない(´・ω・｀)

DMAエンジンによりGPUとCPUとのメモリ共有が可能になったらしい
PCI-E3.0に関しても帯域不足を多少補えるようにはなってるとは思うんだが
GPUエンコとしては将来性はまだ無いのかな？
ttp://www.4gamer.net/games/135/G013536/20120106063/

スレチ

>>613
--level指定じゃダメなんですか

そりゃダメだろう

>>610
自分は下のページを見て目的のprofileとlevelに合うようにrefとかvbvとか設定してる．
http://up-cat.net/x264%2528vbv%252Dmaxrate%252Cvbv%252Dbufsize%252Cprofile%252Clevel%2529%252C%2BH%252E264%2528Profile%252FLevel%2529.html

レス�d
オプション見直してくる

僕は童貞！君は？

俺はアナル処女だぜ

lick my ass! X-)

fack you

おお…

まい…

らぶ…

oh
miss spell
Fuck you
の流れじゃないのかよ！！！

commit http://toro.2ch.net/test/read.cgi/avi/1322304761/620-627
Author: neet long-vacation <[email protected]>
Date: Sat Jan 07 21:22:18 2012 +0000

Fix typo in your brain

>>628
ビルドしてみたけどエラーが出る

--nal-hrd vbrと--audって、10bitの場合でも付ける意味あるの？

いまのところはない

保険程度の意味合いしかないね

L-SMASHはReadmeとかUsageないのかよ
さっぱり使い方がわからんぞ

作者に聞けばーtwitterやってるんだしー

お断りします

L-SMASH オプション入れなければUsage出てこない？

>>633
日本語がおかしいから、Readmeなんか書いたら馬鹿なのバレるだろｗ

L-SMASH使ってるが悩んだことないわ

>>633
在日だから日本語おかしいんだろｗ

なんでこんな所にネトウヨが湧くかねえ

やっぱ朝鮮人多いな。

ほんとゴキブリみたくどこにでもでるなｗ

単発IDの嵐

へー

--fullhelp

フェニックス１号

CPU:AthlonXP 1400+(25w版)
M/B:A7V266
MEM:512MB
HDD:60GB
VGA:自慰Force2MX400
SOUND:SB Live!

フェニックス1号バカにしてるだろ
うちのPT2録画鯖は似たようなスペックだ

60Gだと録画鯖の意味ないだろ

似たようなって言ってんじゃん

つーか、更新のないときは見るだけ時間のムダとしか言い様のないスレだな。

もうすぐ更新だよ

LSMASHって放送tsのAACには非対応なんだな
道理で何度やってもエラーが出るわけだ

対応しとるが

素材をどういう手順で扱ってどういうリビジョンでどういうオプション使って
どういうエラーが出たのかちゃんと書かないとね。

出来ないって言ってるのに、出来るって言ってるって何なの？
出来てないだろ

2chで教えて下さいなんて言ってもなかなか教えてもらえないが自信満々に嘘を書いたり
煽ったりすると怒濤の突っ込みで正しい情報を得られるとかなんとか

>>654
にほんごでおけ

LSMASHは264のhi4:4:4半分だけ対応なのか
左側半分が2枚でて暫く悩んだ

LSMASHは何だかんだでホント使えないな
作っつる奴どうにかしろよ馬鹿

gpacよりはるかに使えるが

オープンソースなんだから気に食わなければ自分で直したって良いんだぜ

俺はずっとLSMASH使ってる

>>657
適当にやってみたが再現しない。デマじゃないならちゃんと再現手順書いてみてくれ。

8bitのhi4:4:4で試してみな

またあの方がムキムキしちゃうぞｗ

おお・・・

LSMASH使えないでしょ
中途半端なくせに大々的宣伝し過ぎ

どんだけ立派なエンコしてるんだろう

>>666
お前が使えるように直しといてくれ。それが出来ないならお前も使えない。

mp4boxと同じコマンドで使えるように変えてほしい

LSMASHはHi10読めるし凄いと思ったぞ

「L-SMASH（muxer.exeなど）」と、「L-SMASH Works（lsmashinput.auiなどのAviUtlプラグイン）」とはちゃんと区別しようぜ・・・。

とりあえずPOP氏とJEEB氏のx264 r2120 L-SMASH 8bit-depth x86で
　　x264.exe --preset ultrafast --crf 23 --output-csp i444 --colormatrix smpte170m -o test.mp4 test.avs
として、i444をL-SMASHでMuxしてみたけど何も問題ないな。再生はLAV Filters 0.44を使用。
>>657、>>663は何が言いたいんだろう。
特に>>657は意味不明っつうか単に再生環境おかしいだけじゃねって気がするが。

L-SMASHって本当に使えない、どうなってるんだ？

>>672
じゃあ普通のx264も使えないんじゃねえの馬鹿が

使い方が判りません、教えてください……って言えば親切な人は誰かいると思うぞ

スレで自分の知りたい事を得るにはテクニックが必要だよな
ほんの少し間違った事を言ってみるとすかさず訂正が入る
この方法を使え！

L-SMASHって最初は凄いコードというか良いコード書いてるなという印象合ったけど、いつからか残念な実装ばかり･･･。
開発者が足りないらしいけど、オープンソースなんてそんなもんか？

具体的に何が残念なのか書いてみたら？漠然と悪印象を植え付けたいだけのつまらんアンチにしか見えんぞ。

まぁ煽ると面白いよね、あの方はｗ

別に面白くはないだろ、基本真面目だから語り継がれるネタを生み出すわけでもなし。

>>679
在日のキチガイだって聞いたけど

聞いたけどって、知らないのに書きこむなよって思うわけだが。

まだダウソ民の話してたのか

独り言でしょ

隔離スレでやれ

海外サイトに流してるのってこいつだろ

スレチだから隔離スレいけよ

伸びてるから更新かと思ったら…

更新といえば次また結構高速化するみたいだね

おお、それはすげー楽しみ
AMDでも速くなるといいな

次も速いってなんかベンチとかあるん？

隔離スレって何処だよ？

>>675
オプション系をこんな風にしてるんだぜーの体で書くと物凄い勢いで突っ込みを頂ける
よくわからなかった自分にはありがたかったわー

悔しかった感がもの凄く

>>689-690
ttp://k4095-takuan.blogspot.com/2012/01/blog-post_3187.html
このへんとか?

>>694
そんな変わるのか。期待

ところで隔離板ってどこのこと

この板で「まにまに」でスレタイ検索すりゃいいんじゃねえの。

ちんこふくらんできた

隔離しなきゃならないほどのいかれた輩なのかよｗ
隔離するのは伝染病患者と基地外患者だけだろ普通ｗ

生活保護受給者とかニートとかも是非お願い

無意味に難癖つけて論破されて発狂したクレクレ厨の隔離が目的だったと思うが・・・。まあ隔離できてねえけど。

後だしで難癖付ければ簡単に論破出来るわな

そうだよな、後からなら何とでも言えるｗ

>>694
すげえなそのレベルの速度増加がもう2,3回あれば2106の倍ぐらいの早さになるじゃねえか

64ばっかり・・・

r2150来たな

どこにだよ

来てるだろ

24 時間以内
r2150 x264 に一致する情報は見つかりませんでした。
うーうー

rev2145を拾えるサイトはあるけど俺はおとなしくx264.nlを待つことにするぜ。

俺もx264.nlのしか使ってないや

ビットシフト修正したって言ってるような内容見つからないな

きてる？？

これのことじゃないかな。

@darkshikari
https://twitter.com/#!/darkshikari/status/158718744917577729
　x264 r2145 is out: tons of GCI asm code, double-speed trellis, and more! Newsletter at
　ttp://mailman.videolan.org/pipermail/x264-devel/2012-January/009012.html

x264.nlにr2145きた

まじではええ

ほんまや！メチャはよなっとる
いままでよりもうちょい高画質してもいいかも

速いなら速いで不安になるんだが
実はどっかおかしいとかいうオチじゃないよな？

r2145早過ぎるｗ
何か別の意味で心配になって来たｗ

r2145圧倒的大勝利！！！！！

masterがバグ抱えてるのはいつものことじゃん

４０％位早くなってるね〜何があったんだろ？ｗｗｗ

速い速いって、具体的な数値で提示してもらいたいものだ

【x264+Avisynth】実用エンコベンチ Part2
http://anago.2ch.net/test/read.cgi/jisaku/1321723244/

2パス目かと思ってたら3パス目だったｗｗｗｗ４０％じゃなくて８０％はやくなってたｗｗｗｗｗ

うおお速攻使いたい
LSMASH待ちはこういう時辛い

r2145めちゃヤバイほど早いなｗ

試しにつくってみたけどとりあえづ問題なさそうｗ
ttp://www.nicovideo.jp/watch/sm16713351

10bitで相当重いエンコ設定でもr2120よりは一割程度エンコ速くなってることは確認できた>r2145
なお8bitソースをエンコした時の色変換バグはそのままだった、つかもうこれは仕様といっていいのか

64bitで速いリサイザ無いのかなあ・・・

可愛いおんにゃのこだと思った?残念!r2145でした
ってJEEB氏が

r2145のおかげで一皮むけた！！！






まだテストしてないけど

・・・AMDのCPUでも速くなってますか？

AMDってなんですか

QSVとは何だったのかと問える程に最近x264が高速化続けてるね

設定軽くしてさらに高速化しようと試行するも結局元の設定に落ち着いたでござるの巻

返して4時間X-(

自分のせいでしかないじゃん

そんなに速くなってるのか
じゃあ俺のAtom機でも…

俺のE3300でも…

俺のぴゅう太で

おっぱいとか重要だよな

おお…

かわ…

こう・・・

>>735
コストパフォーマンスはどうなの？
幾ら早くっても値段と釣りあいがとれてないと駄目だし

現在普通に触れられる中で容量比画質がx264を超えるエンコーダなんて無いだろ
圧倒的と言って良い

ベンチとか見てるとかなり早くなってるな…
画質とか作成されるファイル容量に変化があったのか気になる。
俺もためしてみるかな

容量は微増かな（１％未満

2145ってバグ持ちなの？

なんで？

これか
ttp://k4095-takuan.blogspot.com/2012/01/x264r2145.html

10bitだけの問題か？

ここで報告されてるのも10bit x64だし、そうかもしれない
ttp://mailman.videolan.org/pipermail/x264-devel/2012-January/009016.html

とはいえ8bitでもバグってるかもしれないのを使う気は起きないわ

8ビットの使ってるけど今のところ破綻とか
関係ないなぁ

じゃあ9bitで我慢するか

個人ブログ貼りすぎだろ。ステマかよ

>>756
お前はステマ言いたいだけにしか見えない

覚えたての言葉だから使いたくてしょうがないんじゃないの

ステルスマ　コ

デンター　システマ

はいはい
効いてる効いてる

僕の初代Athlon64ちゃんでも速度を体感できるでしょうか？

某ベンチスレ見たらｒ2145だとFX-8150とi7 2600ｋが
同じぐらいの速度に成ってるっぽいけどどうなん？

もとからどっこいか海外のベンチマークなら上だった気もするが

あんなｺﾞﾐCPUでもエンコだと使い道あるんだねぇ

しっかり最適化できれば遅くはないんだよ
問題は2番手の企業なのに最適化しないと性能がでないCPUにしたことだ

二番手だから搦め手を使うしか無いんだろ。

バグで画像破綻なんてよくあることよ

どうせ見ることないから、新revでたら速攻でバッチ書き換えてる

その意気やよし！

r2146

Fix trellis 2 + subme >= 8
Trellis didn't return a boolean value as it was supposed to.
Regression in r2143-5.

バグ直ったってこと？

r2145 x64 8bit-depthで映像破綻したって報告がtakuanさんのブログのコメント欄にあるけど
他に自分のx64 8bit-depthエンコも破綻したって人いるのかな？

HWA有効でのみ破綻したとあるので今回のバグとは関係ないのではと思います。
そのうち.nlの方も更新されると思いますのでr2146を素直に使えばいいかと（もう更新されてるかな？）

あと今回のバグはtrellis=2+subme>=8でしか怒らないのでこれを使っていなければ10bitでも問題ないです

既に昨日r2145 x64 8bit-depthでエンコしてソース消しちゃったもんで…。
akupenguinさんのコメントからして昨日trellis 2 + subme 7 でエンコした1080iクリップは多分問題ないとして、
もうひとつtrellis 2 + subme 9 でエンコしちゃった480pクリップを最初の10分だけ今確認したけど
一応破綻は無かった(ffdshow)。
とりあえずtakuanさんの所のr2146使ってみる。今度はソースも捨てないでおこう。

あ、775リロードしてなかったので被りました。

あほなタイポしてる…

まあ見た感じ破綻してなければいいんでないかな
x64 8bitでtrellis=2+subme=11でしたやつも特に破綻はなかったし

ソースにもよるがdeadzone指定してtrellisは無効にする方がいいんじゃね？

今のtrellis=2+subme=10/11はかなりおりこうさんだと思う
subme<=9ならそれでもいいだろうけど

subme10とかめっちゃ汚れるだろ
嘘つくんじゃねえよ

やり方によるだろ…
trellis=1でdeadzone下げるとか正直過去のもんだ

てかtrellisとdeadzoneは共存できない仕様だろ？
trellisが有効になっているとdeadzoneをどれだけ調整しても無視される。

無視されるのはtrellis=2のときであり1の時は共存可能

参考までにおまえの共存させたバージョンのx264パラメータを晒してみろ。

deadzoneは確かにtrellis1ならできるみたいだが
trellis2でいいんじゃね？って結論に至るに違いない

>>785
いやだから俺はtrellis=2+subme=10/11がいいっていってるじゃん

猫科研究所から

x264の議論が開発者も含め活発に行われているDoom9でも、「trellis使用時はdeadzoneは不使用じゃないの？」
という質問が出ていて、これにDark_Shikari氏が「trellis=1でもMBのモード決定に影響する」と答えている。

ふむ。

　猫科研究所 - x264(deadzone,trellis)
　http://up-cat.net/x264%2528deadzone%252Ctrellis%2529.html

最新版だとどうなってるんだろ。

それじゃ参考にもならんな。

１箇所「deadzonne」というtypoがあって、思わず「デッドゾンヌ」と読んでしまった。

　　　 ／￣￣￣￣＼
　　／　　　　 ●　　●､ 　　呼んだ？
　　|Y　　Y　　　　　　　 ＼
　　| |　　 | 　　　　　　 ▼ |
　　| ＼／　　　　　　＿人.|
　　|　　　　　　 ＿＿＿ノ
　　＼　　　 .／
　　　｜ ｜　|
　　　（_＿）＿）

trellis=2はモード決定に毎回trellis処理をする
trellis=1は最終出力にのみtrellis処理をする
だから、trellis=1の場合モード判定処理に対してdeadzoneは有効

彼には何言っても参考にならないと思う

自分で検証しない奴は駄目
>>781 は正しい

アニメソースとかじゃなければsubme 10もありだと思ったが

同じソースでもsubme 11より10の方が縮む事あるけどあれは何なの

同じおっぱいでも日によって違うだろ？

>>797
subme10ってボケない？
その分、縮むんじゃないの

速度が　って人もいるだろ

x264.nl に r2146 が来てる。

10は地雷

>>801
ｔｈｘ

結局r2145の
　　trellis 2 + subme >= 8
のバグの影響範囲はどこまでだったんだろう？
64bitの10bit-depthのみ？8bit-depthも？
32bitは問題なし？

x264も64bitで最適化されてきたし
AviSynthもフィルタなんとかしてパイプなしの64bit環境にしたいな
ワープシャープパックに入ってるのとITs関係のが止まっちゃってるんだよね

スーパー行って安売りの惣菜買ってきますね

高速フーリエ変換の新アルゴリズムをMITが開発　従来の１０倍の速度で携帯動画もHD化か
http://awabi.2ch.net/test/read.cgi/poverty/1327051425/

haswellにh265にこれか未来は明るいな

これは非可逆変換
切り捨てを最適化できれば面白い事ができそう

さすがマサチューセッチュ

丸めちゃうけどすごく早いよ！みたいなのか。
戻す必要のない分野には有効そうなのかな？

FFTWがそれを使えば、CPUでやるFFT3DFilterが、FFT3DGPU並に速くなるのかもしれない。

r2146でr2145のバグは治ったのかな？
速すぎて感動している

サンディブリッジに買い替えた事だしr2146に乗り換えるかね

r2016→r2146にしたら18分動画エンコに等速の18分かかってたのが15分に縮まった

おいなんで2ちゃんあちこち落ちてるのよ？

ttp://www.maido3.cc/server/release/2012/201201211444.html
現状はこんな感じらしいな
原因はわかんね

JEEBのTwitterの発言かわいいな
(♯ﾟДﾟ)＜「風邪を引いてもおもちうにょーん♪」
にキュンキュンするわ

r2146にしたら20%くらい遅くなったな

>>818
さんをつけろよデコ助野郎

>>819
俺は逆に少し早くなった。

>>820
ごめん

(♯ﾟДﾟ)＜「風邪を引いてもおもちさんうにょーん♪」

sandyだけど2145→2146は早くも遅くもならなかったよ

映像が壊れる問題のバグフィックスなんだから当然だろ

バグの部分、巻き戻ったんじゃないの？

それだとrevertだ
今回のはfixなので速度はr2145と変わらない

JEEB様版10bit2146待ち

もうヨブ版きてるだろ

>>828
ヨブ様はヨブって読みで呼ばれるの嫌らしいからヨブ様をヨブ様ってヨブのはやめろ

可愛いおんにゃのこかと思った？
残念！ヨブ様でした

もう寝ますね

2085以降は画質を犠牲に速度を上げてるから糞。

むしろファイルサイズは増加傾向にあったと思うが

同品質でファイルサイズ増えているならのなら、ファイルサイズあたりの
画質は悪くなっているんじゃ…

2085で品質1速度1だったのが2146で品質0.9995速度1.2程度になってる｡最高設定まで詰めに詰める奴以外は良い傾向

速度が爆上げになって多少容量が増えるくらいなら
結果的に大きいプラスだと思うけど

糞だと思うのなら使わなければいいだけの話

どのみちqcompを減らせば簡単に小さくできるんだしな

次でようやくbit-depthの変換に修正入るようだね。

ええい10bitなぞどうでも良い8bitを更新しろｵﾗｱｱｱ

明順応(鈍くない)
暗順応(鈍い)
明場面中の暗部(鈍い)
暗場面中の暗部(鈍くない)
ここら辺加味するパッチとか無いものか

>>841
期待してるから頑張れ

10ビットで満足してるわ俺
8ビットの壁を易々と越えてくれる

10bitは綺麗なのだがiOSで見れないのが痛い

汎用性大事だよな

そのうち対応するだろ

画質で言えばr2085が一番って事なのか

たいした違いはないだろ
画質云々なら1スレッドエンコしたらいいじゃん

数％の画質落ちと数十％スピードアップを天秤に掛けるとだな

>>849
0.9995が数パーセントになるのかは疑問だがね
>>835
君の好きにすれば良いと思うぞ

逆に考えれば高速化された時間の分だけプロファイルを上げれば画質が向上するってことか

画質をとるか生成後のデータ量をとるか、俺なら確実に後者を優先するけどな
画質にこだわるならエンコードなんてしなくていいから

便利だからエンコする
同じエンコするなら画質がいい方がいい

でも上の例の違いくらいは糞くらえ
ｒ2146を選ぶわ

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1
/ me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 /
b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=30 /
scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=25.0 / qcomp=0.60 / qpmin=3 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

15分のSDサイズエロアニメをエンコしたら274kbpsの50.7MBになった　縮みすぎワラタ
300kbpsいかないレベルなのに普通に綺麗

突っ込みいれるのめんどくせえなぁ

プレイヤーで再生時の縮尺が100%(1:1)なら
へたくそエンコとかしない限り綺麗だと思うが
全画面再生とかで引き伸ばしたときに劣化の違いが明らかになる。

綺麗な動画は引き伸ばしても綺麗だから

>>855

>>856
＞綺麗な動画は引き伸ばしても綺麗だから

流石にそれはねぇよｗ

crf25はちょっとワタクシ的には・・・・

ref　subme　psyrd　merange　bframes rc-lookahead　crf qp値
突っ込みたかった

「きれいな動画」じゃ言葉足らずだな

「ソースがきれいでエンコ時に画質優先のちゃんとした設定してビット(+)またはcrf(-)を十分盛った動画」
なら再生で拡大二倍くらいならいける
つっても実例としては720→360とかのダウンコンバートの場合だけど

ふつうならそんなことせずにはじめから解像度確保するからな

>>855
突っ込むアニメだからボケ待ちしているよ^^

r2146乗り換えてみたが全く問題ないな

>>860
具体的に突っ込んでみてくれYO

>>860
SDサイズならそのへんのパラメータ弄る必要ほとんどないと思うんだが

SDサイズのままで見るなら別にいいんじゃね

>>854
2コアの糞PC乙

俺のE3300の悪口はそこまでだ

対象がアニメエンコなら
keyint=300 / keyint_min=30 / scenecut=40 / qpmin=3 / qpmax=69
これはさすがに無いだろう

>>868
そこはあまり関係無いだろ それよりも>>860の方がずっと的を得ている
ref→アニメなら効果がデカいのに低すぎる,subme→同じく低いmeの前にこっち上げろ,merangeは分からんなぁ他と比べると解像度に比べちょっと高いぐらいか,rc-lookahead→リアルタイム配信でもするんですか?crf qp→好みだが流石にノイズがきになるだろ

どうでもいい、パラメータ談義
refはlevel考えれば3でもいいし、rc-はマシンパワーとの兼合いもあるんじゃね。
なんでもかんでも否定するアホばっか。

keyint、keyint_minは240、24にするべきなんじゃないの

15分のSDサイズエロアニメてことはあれか

突っ込んだら負け

ぶっちゃけx264 --helpで出てくるオプション以外滅多に使う機会がない
--tuneと--preset任せですよ

>>868
何故qpmin=0じゃなくて3なんだろ？ってのはあるけどそのパラメータ自体はまあ普通じゃね
つか下手に弄らないでデフォ設定が基本よ、
アニメだからって--tune animationなんてやっちゃったら暗部とかでバンディングでまくるし
かなり極端な設定も含まれてるから。各オプションの感触を自分なりに把握できるようになるまでは
--tune、--presetは使わない方がいい

基本はデフォルト、指定するのはcrfだけでいい、後のパラメータはx264が勝手にデフォに設定してくれるから
デフォルトを基本にして各オプションパラメータの感触を一つ一つ確かめながら
調整していけばいい、最初から複数のパラメータを同時に弄ってるとわけわからなくなる可能性大

--crf、--qpstep、--qcomp、--keyint、--min-keyint、--b-adapt、--me、--subme、--merange、--direct、--trellis、--level

ここらへん弄って終わり
psyrdとかaqとか弄らなくなったわ

cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=11 / psy=1 /
psy_rd=0.30:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1
/ cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6
/ sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0
/ constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0
/ direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=1
/ scenecut=60 / intra_refresh=0 / rc=crf / mbtree=0 / crf=20.5 / qcomp=0.60
/ qpmin=0 / qpmax=51 / qpstep=10 / ip_ratio=1.43 / pb_ratio=1.28 / aq=1:0.40

もう最近のアニメは適当にエンコしとるわ

適当なわりにはオプション結構弄ってるじゃないかｗ

tesaいいよtesa
時間効率的にはあり得ないけどエンコなんて寝てる間にやっちゃうから
時間なんて気にしないっていう人なら試してみてもいいかと

圧縮率が従来の10倍になる魔法のエンコーダと
速度が10倍になる魔法のエンコーダがあったらどっちを選ぶ？

前者に決まってる

ていうかnrは有効にしておいて損は無いと思うがね。
アニメソースではあまり意味は無いかもしれないが
実写ソースだとavsでノイズ処理するよりも快適に処理される。

CUDAかx264どっちとれって？
このスレで聞くことじゃねえ

x264+avsでCUDAフィルタ使えばいいのに

速度が10倍じゃｲﾗﾈ

速度10倍だって充分すごいことだが、圧縮率10倍ってののすごさが異次元過ぎる。

>>879
tesaもいいんだけど、個人的にはumhとtesaのちょうど中間くらいのがあってもいいと思ってる
esaがあるけどumhと速度差が激し過ぎて、とてもじゃないけどumhとtesaの中間とは言えない性能だし

tesaはmerange広げてたり解像度が高いと重すぎるよなぁVGA以下なら積極的に使っても良いけどソースによってはumhの方が良さそうな出力結果になるし…
一昔前のゲームとかアニメなら悪くないと思う

ペガシススレから引用

58 名前:名無しさん＠編集中 [sage] :2012/01/25(水) 13:32:46.82 ID:PNhy6MSE
そこでキモヲタ専のsubme-11（笑）ですよ
常識的な5とかの倍以上の時間がかかるけど、なんと1割程度(笑）もサイズを縮められる

なお、画質にはほとんど影響なし(笑）

笑わせてもらったwww

cabac=1 / ref=4 / deblock=0:0:0 / analyse=0x3:0x113 / me=umh / subme=6 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00
/ mixed_ref=0 / me_range=24 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2
/ threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / fgo=0 / bframes=0
/ weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0000
/ qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Core2 Quad Q9550 /4c 2800MHｚの貧乏スペックなのでSDもHDもこれで
crfさえ上げときゃ何となるってばっちゃがゆってた

Bフレ=0でRef=4
なんの冗談だよ

4コアの貧乏スペックだからrefは4程度で充分
これ以上上げても遅くなるだけだし、大してサイズも縮まない＆画質が向上するわけでもない

cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=0.40:0.00
/ mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2
/ threads=6 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=6
/ b_pyramid=2/ b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=1 / scenecut=75
/ intra_refresh=0 / rc_lookahead=40 / rc=crf /mbtree=1 / crf=18.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.20 / aq=2:0.60

変態自慢と聞いて
r2146 level4.1縛りアニメ用
SDもHDもこの設定。ほとんどpresetな設定なはず。

>>892
Bフレ使わんの？

vfrなアニメならこの程度で十分だと思うが。

cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x3:0x112 / me=hex / subme=9 / psy=1
/ fade_compensate=0.00 / psy_rd=0.03:0.23 / mixed_ref=1 / me_range=16 / chroma_me=1
/ trellis=1 / 8x8dct=1 / cqm=2 / deadzone=6,4 / fast_pskip=1 / chroma_qp_offset=-2
/ threads=6 / sliced_threads=0 / nr=128 / decimate=1 / interlaced=0 / bluray_compat=0
/ constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0
/ direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=1
/ scenecut=75 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.4
/ qcomp=0.54 / qpmin=2 / qpmax=66 / qpstep=4 / vbv_maxrate=3500 / vbv_bufsize=8500
/ crf_max=40.0 / nal_hrd=vbr / ip_ratio=2.10 / aq=1:1.17

細かな画質改善はavsでやればいいわけだしな

x264の設定とpc構成を晒すスレとかあったら面白そう

スペック：http://anago.2ch.net/test/read.cgi/jisaku/1321723244/267
用途：TS実写をインタレ保持 crf23
cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / fade_compensate=0.00
/ psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11
/ fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=tff
/ bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3
/ weightb=1 / open_gop=0 / weightp=0 / keyint=300 / keyint_min=4 / scenecut=40 / intra_refresh=0 / rc_lookahead=40
/ rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

>>896
こんな感じでどう？

たまには晒し大会するものいいが、
mediainfo読みよりx264に渡すコマンドラインオプションで書いてくれたほうが読みやすい

>>898
今まさに書こうと思ったことを先に言われたｗ

>>898
>>893
x264.ownbuild.mcore2msse4.1.2146.r1.exe --keyint 240 --min-keyint 1 --scenecut 75 --bframes 6 --b-adapt 2 --b-pyramid normal --ref 6 --deblock 1:1
--crf 18 --ipratio 1.2 --pbratio 1.2 --aq-mode 2 --aq-strength 0.6 --qcomp 0.8 --partitions all --direct auto --weightb --me umh --merange 32
--subme 9 --psy-rd 0.4: --mixed-refs --8x8dct --trellis 2 --no-fast-pskip --no-dct-decimate --cqm flat --threads auto --thread-input --sar 8:9 "1.avs" -o "1.264"

エンコードログもmuxしてる俺に抜かりはなかった(ｷﾘｯ

興味あるのはkeyint keyint_min rc_lookahead

自分用の設定は細かくあれこれ弄ってるけど
他人にオススメ聞かれたらプリセットで十分綺麗だよと答えてる

>>900
突っ込んだら負けかなと思ったが突っ込んでみる
--sar 8:9 って出力画面いくつで出してるんだ

--sar 1:1〜40:33〜10:11
--tune film〜animation --fps 24000/1001〜30000/1001 --keyint 24 --min-keyint 2
--profile high --level 4.1
--bitrate 3040〜10000 --vbv-maxrate 24000 --vbv-bufsize 30000
--preset slow --bframes 3 --ref 3
--aq-mode 2 --weightp 1 --b-pyramid strict --slices 4 --no-fast-pskip --no-mbtree
--threads auto --nal-hrd vbr --aud --colorprim bt709 --transfer bt709 --colormatrix bt709

Blu-ray/AVCHD/MKV共通で使ってるんだが、SEEKのためにkeyint=24って無駄なのか？

なんかおかしいの？

--min-keyintの設定って、いろんなサイト見てると
1 or 2 or 4 or デフォルト
にしてる人が多い。
1(IDRのみ)、2(なんとなくBDの規格にしとこう)、デフォルト(考えるの面倒)はわかるが、
>>897のような--min-keyint 4って何を意図してるの？

>>903
720x480をそのまま4:3表示じゃね？

min-keyintを1とか2にする意味（メリット）が知りたい

>>907
そう思ったが--merange 32 は少し大きい気がしてね
SDなら24くらいでもかわりないぞ

>>>906 >>908
画の移り変わるところをすべてシークポイントにするため
--min-keyint 1 だと I=IDR になる
キーフレーム送りのときに便利

ただしごくまれに、「ごく少ないフレーム単位で交互に同じような画が出るところ」では
(日本のアニメじゃ規制でなくなったがフラッシュのシーンなど)
そこだけ異常にキーフレームが増えるので
それを回避するために --min-keyint 4 とかにしてるんだと思う

--min-keyint 1は画質優先仕様だな
Iフレームはその設定の最高画質になる
--scenecuと密接に関係してるからセットで考えないと駄目

>>903 SDな同人アニメDVD(仮)がソースだから>>907の通り
もちろんHDの時は変えるよ

>>910
なるほど、--min-keyint 4にはそういう意味があったのか。勉強になった。

あと個人的に興味があるのは--qpstep
8とか12とか、デフォルトの4より上げてる人よく見るけど、
そうすると画質が大きく変動して心理的画質が下がるんじゃないのかと思ったり。

--tune animationの設定を踏襲してる人がちらほらと・・・
x264開発陣はアニメならaq-strength 0.6、psy 0.4まで下げてもいいだろう、みたいに思ってるんだろうけど
いくらなんでもこんなに下げたら暗部、細部でバンディング出まくって死んじゃうよ

min-keyint ってIDRフレームの設定だと思うんだけど、
min-keyint 1にしてIDR使いまくるより、同じ所に通常のIフレームが置かれた方がRD性能は上がるような気がする
例えば、連続した映像の中で稀に1フレームだけ全く違う画面が挿入される映像(サブリミナルのような)とか

http://mycometg3.blog.so-net.ne.jp/2011-04-29

min-keyint 4はQuickTime関係らしいよ

min-keyintは関係ないか、勘違いした

>>915
それよくわからんのよな実際にどれほど違うのか
猫さんとこで解説してるのかな誰かご存知

>>913
アニメでは大きくした方がいいよ
画質変動がいい感じに作用する

>>914
どのくらいの数値までなら大丈夫なの
Psy-Trellisとかも知りたいkwsk

>>920
デフォルトでOK、Psy-Trellisは余計汚くなるから俺は切ってる
この設定に限らず、自分が何をしているかわからない内はデフォルトから弄るべきではない

me_rangeを64にしている人は居ないんだ、これは高い数値だとだめなの？

偽のEDテーマエンコしたら
10bitでBがPよりも平均サイズでかくなった QPはBがでかかった
skipもあるんだろうけど GOPわからん いろいろ教えてください

tune grainでいいじゃん

検証はしてないけどgrainでは問題ありだろ
ipratio 1.1, pbratio 1.1では動きに対して追随できるのか疑問

実際どのフレームになっているか調べるのはどうするの

--preset、--tuneは各オプションの意味、効果を完璧に把握している超上級者向けのオプションだよ・・・
参考にするのはいいけど基本的に使わない方がいい、つか使っちゃ駄目だ

フルHD&1440*1080のSAR4:3でのエンコ

cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / fade_compensate=1.00 /
psy_rd=0.30:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
fast_pskip=0 /chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 /　fgo=0 / bframes=2 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 /
weightp=2 / keyint=240 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 /
crf=20.0000 / qcomp=0.80 / qpmin=12 / qpmax=35 / qpstep=8 / ip_ratio=1.40 / aq=3:0.60

色々と突っ込まれそうだ。

デフォのx264パラメータを弄ってない項目は外して晒せばいいのに。

>>889に誘われてTMPGのスレを見てきた
爆笑

>>926
どういう情報が欲しいのか分からないけど、エンコ時にログをdebugで出してみるとか。

爆笑するほどのネタでもないような
本人が満足してるんなら外野がどうこう言っても仕方がないし
実際一日に何本もエンコするような人は時間と品質のバランスを重視してsubme 5とかに
落ち着くこともあるだろう
アニメソースならそんなに極端には破綻しないみたいだしな
俺はsubme 11&me tesaとかアホ設定愛用だけど他人に強要する気は全くないし
実際アニメソースだとme tesaとかあんまり意味ない・・・

TVMWスレひでぇ・・・

このスレで推奨設定とかてんぷらにしない理由の一つが
【縁故の設定なんて本人が納得出来ればなんでも桶】で俺もそう思う

TMPGも同じx264エンコーダーのスレなのに
上から他人の設定を全否定してるヤツが居るのが面白いのと
そいつがここで大暴れして最後は相手にされなくなった人に文体とか似てたからさｗ

基本はデフォでおｋ

迷ったりよくわからないならデフォルトでOK
何が正解なんてないけど、オプションパラメータいじくるならそのオプションの効果を理解した上で

同一ソースをエンコードしても皆望むものが違うからね
結局本人が満足してるなら何でもありでいいよ

だがアニメ用のパラメータとフィルタ設定で実写ソースを
エンコードした時の劣化具合はなかなか。

アニメ

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 /
chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 /
weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf /
mbtree=1 / crf=20.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=8 / ip_ratio=1.40 / aq=1:1.00

アニメと実写でパラメータ変えてるところといったら--crfしかないなぁ
アニメは低め、実写は高めに

>>939のrefとbframesを6くらいに上げてcrf19にしたら結構良い感じになる

こういう時にエンコ速度＆ファイルサイズ重視設定が全く出てこないのは何故か
TSでとっとくのもばからしいけどもしかしたら後でチェックするかも的なドキュメンタリ用とかの画質なんて顔と文字さえ判別出来れば十分的な奴

>>942
それは二律背反だぞ
スピードを重視すると画質が落ちるし
サイズと画質を追うと時間がかかる

エンコ速度は--me、--subme 、--merangeなどを調整すればいいし
サイズは--crf、--qcompとか調整すればいいだけじゃね

つかどんどん早くなってきてるし--me umh、--subme 8-9、--merange 16-24でも速度的に十分な気がする

--crf 19、--me tesa、--subme 11、--merange 32
はどう？

最高だよ

みんな画質拘ってんだなぁ
俺はfps30000/1001のソースを60000/1001指定でエンコしてアホン用の倍速動画とかやる位だわ

>>946
時間に余裕あるならいいんじゃね

ここのみんなはsubmeは上げても9までみたいだね。
>>781も言ってるけど、subme 10は残念な子なの？

俺はsubme 11でやってる
10でも9でも8でもしたいようにすればいいじゃない

>>950
ソースと設定にもよる
自分がよければそれでもいいんじゃない
俺なら10使うくらいなら11使うけどね

ぶっちゃけ、--crfと--sar位しか使ってないんだが・・・
正直いろいろやっても違いわからないんだよねぇ。
だいぶ前は不具合対策で--no-mbtreeとか使ったくらかなぁ。

>>939あたりのが要所を抑えつつあとはデフォって感じか

俺もsubme 10は使わないな
SDで9か11
HDは5か7

10は欠番みたいなもん

そうそう
10に合わせて設定作ると奇数設定になってしまうとゆーｗ
でも11が出る前は9で決め打ちだったな

>>950
単に[email protected]ぐらいまでしか使わないとかじゃねーのか？
これ以上のプロファイルにあわせてエンコするとUVDとかで再生できなくなるしな

そのうちNAS+Buffあたりのネットワークメディアプレイヤーって環境を夢見てるので
lv4.1に押さえてるのよね。
ほぼアニ専だからbframeは増やしたいのだが、プレイヤーのカタログみるにlv5対応してないという
ぐぬぬ

>>959
汎用性考えると安全パイでBD互換にしとけば安心じゃね？
自分はｘ264のBDオーサリングデモの設定をほぼそのままcrfで使ってる
音声AC3にしてm2tsにすればそのままレグザ（Z1)でLAN越しに再生できて便利
まぁ再変換されても良いならDLNA鯖使って何とでも成るけどね

凡用性云々ならエンコなんてしないでオリジナル保管が一番だろ

NGID:6ol1wPgj

>960
設定plz

BDオーサリングってスライス入れるだけだろ

たぶんデモisoの設定なんじゃないかと

面白そうだね
>960
設定plz

BD用設定ならぐぐればすぐ出る
ttp://www.x264bluray.com/home/1080i-p

いや知りたいのはBDの設定値ではなくHmYSf6vJの設定値

--profile high --level 4.1 --preset veryslow --tune film --threads 0
--bframes 3 --ref 4 --me umh --merange 24 --rc-lookahead 48 --scenecut 50
--deblock -1:-1 --min-keyint 1 --keyint 48 --slices 4 --direct auto
--b-pyramid 1 --b-adapt 2 --weightp 0 --trellis 2 --aq-mode 1
--no-fast-pskip --no-dct-decimate --non-deterministic
--colormatrix bt709 --colorprim bt709 --transfer bt709 --bluray-compat
--vbv-maxrate 40000 --vbv-bufsize 30000 --aud --nal-hrd vbr --no-interlaced
--crf 24 --subme 9 --qcomp 0.7 --psy-rd 1:0.15 --aq-strength 1.0

映画用だけど御呪い＆無駄が多いのは勘弁。
ソースによって最後の行を多少変えつつ使ってる
後、ビットレート高くなるようなら --keyint 24にしないと駄目かも…。
これでエンコしたの+AC3音声をtsMuxeRでm2tsにMUXすれば多分Regza Z1のLAN越し再生は行けるはず。
正直パラメーター的には何の面白みも無いと思う。

おつです
BDプレイヤーってveryslowプリセットでも再生できるんだ

ものによるとしか言えないんじゃないか
Wipeoutだって今ではDXVAで再生できるし

乙です

>>969
>--vbv-maxrate 40000 --vbv-bufsize 30000

これだと破綻するぞ。
bufsizeはmaxrateより高い数値か同じ数値にするのがセオリー

じゃあ>>967じゃ破綻するってこと？

>>974
破綻するってのはエンコ中にビットレートが30Mb/sを超えた時に崩壊が起こるってことだよ。
どのバージョンのx264を使うかにも寄るけどデフォのqpmax上限が低いバージョンを使っていれば
underflow乱発とかフリーズとかいろいろ楽しい現象に遭遇する。

動きの激しいFHDの実写ソースで試してみればいいよ。

そういえばBD関連のオプション入れたあたりでqpmaxが69になったりしてた様な気が

くわしい解説サンクス
これならr1881での修正が必要になるのも無理ないわ

やべえよ、蜜柑の皮がすげーむきづらくて手が汁でベトベトになったわ

そういう蜜柑の方が美味いんだよ

そろそろ次スレ

次スレおつおつ

980が立てるんでしょ

x264 rev35
http://toro.2ch.net/test/read.cgi/avi/1327666842/

立てた

>>975
エンコ中に飛んだ事無いから大丈夫なんかね
まぁ実写はｃｒｆ24でやってるからインタレのフルHDでもそこまで行ってないだろうし
大丈夫だろうけど…さて。

ありゃ、キリ番ルールだっけここ？

>>984
誰が立てても同じだから気にするな

>>983
おつです

iPhoneでも再生可能な720p用設定（実写の場合は--tune filmに変更）
--preset slow --tune animation --crf 21 -b 6 -r 4 --trellis 2 --fade-compensate 0.4

--fade-compensate
インタレ保持はweightpが使えないので代わりにコレを付けろみたいなのを見たことあるんだけど
有り無しでもサイズ殆ど変わらないので効果があるのかわからん。これどうなの？

1000!

>>988
サイズよりも自分の目を信じたらどうだろう？
効果ないと思ったら使わなきゃいいだけだろ。
俺は効果あると思うな…シーンに依るけど。

>>988
フェード部の崩壊が改善されたわ。ゆるゆり冒頭とか

昔色々と試してみたけど自分には違い分からなかった
十分なビットレート盛ってると関係ないんだろうなと思って
今では使ってない

暇だったからテレビと同じGOP(M=3, N=15)になる設定でエンコしてみた
--scenecut 0 --keyint 15 --min-keyint 1 --bframes 2 --b-adapt 0

やってみてわかったこと：
PC上だと容量食いなだけでメリットが殆ど無い
やっぱりシーンチェンジごとにGOPが始まるほうがいい

テレビと同じ？

--open-gopも必要だな。その場合、コンテナはMP4だと駄目だが。

そういやMediaInfoで
Format Settings ReFramesのところの表示が狂うことがあるけど
Format Settings GOPの表示もおかしことが多いよな

次スレ
x264 rev35
http://toro.2ch.net/test/read.cgi/avi/1327666842/

>>996
＞Format Settings ReFramesのところの表示が狂うことがあるけど

b_pyramidがnone以外だと指定したref値より１増えるんじゃないっけ。

そんなこたあない

おわり

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