x264 rev36

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

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

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://toro.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 rev35
http://toro.2ch.net/test/read.cgi/avi/1327666842/

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

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

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

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

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

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

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

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

スレ違いさんかい、早い、早いよ

>>3
>生tsが一番高画質と思って
俺も思ってる
何をしようとソース以上である筈が無い
加工して一見綺麗になっていたとしてもそれはオリジナルから更に遠い存在になってるだけ
ただ軽くしたいから再エンコードしてるだけ

アホくさ

マジレスすると納品物は制作でエンコされてて、
放送波に載せる時に更に局で再デコエンコされてる(配信局)
CATVなんかだとヘッドエンド等で更に再デコエンコされてる
ソース教の方の神は何処に居るんだろうか

懺悔
随分前だけど系切り替えに失敗して0.5秒ほどブラックアウトさせました
ゴメンナサイ

>>7
俺らが制作のマスターをあたりまえのように入手できるはずもなく
放送波のMPEG2が最もエンコード回数の少ないソースになるのは仕方ないこと

まあこの手ネタはBD買っとけで

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

>>8
とりあえずBD買っとけでFAなのはその通りだな
ただ放送波は(正確にはBDも)ヤッチャッテルのが少なからずあるんで、
そこは手加える余地はあると思うよ
再エンコード＝劣化ってイメージする人多いけれど、
実はそんなことはなくて、適切な処理施せばオリジナルに近い形を復元できる事もある
ばかぽの人とかが時々やってるアレ
当然無理なもんは無理だけど

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

ウザ
荒しネタに荷担すんなや

>>11
そこはたぶん好みの部分だと思うがｗ

余談だけど、マスター以外がヤッチャウ時の話
送出するときってリアルタイムにdemux→映像/音声デコード→テロ挿入とか→映像/音声エンコード→muxしてて、
おまいらがエンコしてるのと同じ作業をリアルタイムでやってるんだ
で、それぞれの機器も当然不調/調整ミスがある
音声同期おかしくなる事もあるし、ブロック喰う事もある
アニメじゃないけど稀によくあるのが音声モードの設定ミスとかな
なので過度にtsに拘っても厳密には「○○放送局のソースを残す」以外の意味はないと思う

コピペに反応すんなやカス

簡単なフィルタ処理だけしてx264可逆が最強ですね。分かります
mpeg2より圧縮率がずっと高いって謳っても放送ソース越えられないってなんかなぁ。もっとBDよりも綺麗なソースをエンコして保存したい

「やっちゃってる」ところ以外いじる意味なしってことでしょ?
色だの線の太さだのオリジナル状態知らないで自分の好みでいじるのは
結局自己満足なんだから否定できる訳も無いけど
やっぱりソースに近いほど良いことになる

スレチ

おい色空間スレが落ちてるぞ

立ってから18日、今回も12レスで終了か。セミのように儚い命だったな。冥福を祈るとしよう・・・。

ここか

次はここか。

　　　　　　　fﾍ　　 ,.. -─ ¨z_　　　　　　　　　　　　 fﾍ._　 ,. -‐ ¨￣ﾞk、
　　　　　　　 r"ﾞΥ　　　　　ﾉ:＼　　　　　　　　　　　(¨´Υ　　　　　 ﾉ::＼
　　　　 ＿_　_〉　　 _,.ﾑ、　/i::::::::>　　　　　　　,.-‐‐- }､　　,..ﾝ-､　 ム､:::ｱ､
　　　(´　　 ｀ﾑyﾍ´　　　ヽ"´ ヽ'　:.　　　　　 (　,、　i-<ﾍ¨´　　　`"　　ヽ　ﾞ;
　　　 | ◯　|{_ﾉ: :.:７´ 　 　 　 　 〉 .}　　　　ﾄ､〉┷　ｼ'|"　',　　　　　　　　〉 .}
　　lV＼ /|/: : : : /　　　　　　　/､,/　　　＼ i Уｨ'´ ﾑヽ ﾉ　　　　　　　 {ｰ/
　-=ﾐ､: : : : : : :_ノ　　　　　　　 |_./　　　　__≧＿＿＿メ彡──----.＿{ﾏ＿

　　　　　　　　　　　　　　　　　　　　 ＿＿
　　　　　　　　　　　　　　　　 ,,,＜:.:.:.:.:.:.:.:.:.:.:.:.:7ー.... ＿_　　
.　　　　　　　　　　　　　 ／////|:.:.:.:.:.:.:.:.:.:.:.:.:.|　　　　￣｀ヽ　　
　　　　　　　　　　　　／/////,∧:.:.:.:.:.:.:.:.:.:.:.:.:ト ＿＿_, 　　'.　　　
　　　　　　　　　　 ／/////////|:.:.:.:.:.:.:.:.:.:.:.7　　　　　ﾄ─イl
　　　　　　　　　 f。///////厂￣￣ ヽ:.:.:.:.:/　 　　　　 V//∧
　　　　　,. -.-...　|/|///////　　　　　 |_::／　　　　　　　ヽ//∧
　　　　/: : : :｀:x|}ｲ/⌒ヽ//　　　　　 ＿　　　　　　　　　 　 '//∧
　　　 ,: : : : : ＼j/　　／Y))ー──´_二j　　　　　　　　　　　V/∧ー- ､
　　　从: : : : ＼(　 {|{　 ￣`　... ￣　　　　　　　　　　　　　　　ヒ:///＜＿_
　　　　 ｀ー≧く乂__｀ﾃー　＿ ｀ーュ_　　　　　　　　　　　　　　|////////)
　　　　　　　　　　　　　　　　　`ー-ｰ<＞　　　　　　　　　　　　 ￣￣￣

テンプレが既に終わってた

その他プロのマスタリングエンジニアが使ってそうな高級ソフトウェア
Interra Vega H.264/VC1アナライザ　価格不明 発売年不明
＞ エンコーダ開発者、システムエンジニア、QAエンジニアの方々にとって理想的なツール（らしい）
http://www.itaccess.co.jp/products/interra/index.html
・各種規格に対して適合検査、互換性の検証をしたい
・エンコードされたストリームに含まれる問題点の抽出と解決・修正をしたい
・製品のパフォーマンスを最適化したい
などの用途に最適。

H.264コーデックに対しては

Baseline、Extended、Main Profileの全てのレベル、High、High 10、High 4:2:2、High 4:4:4に対応
CABAC、CAVLC、MBAFF、PAFFをサポート
バッファ解析機能：CPB、DPB
H.264規格に対する構文的、意味的適合性チェック
NAL表示、各フレームのバイナリデータ表示機能
フル画像をデコード可能な内蔵プレイヤー
マクロブロック単位での参照ピクチャの表示機能

なども搭載。

音声も大丈夫。
AACメインとAAC-LCプロファイル、AAC+Ver1、AAC+Ver2の解析機能
AACストリームをフルデコード可能な内蔵プレイバック機能

VideoLAN.org内部ではこういうの使われてるの？

アニメとは異なるけど出先からの生中継だとこんな感じで複数コーデックが入り交じりエンデコ繰り返されてるらしい。
2012年でもこうなのかは不明。アニメや録画制作番組やスタジオ生中継（ニュース、Mステ）はおそらく少ない
http://www.ntt-electronics.com/digital_video/products/hv9100/picture-quality-of-cascaded-video-codec.html

ふたばのグロスレ行ってみなよ
BLOOD-Cの話がちょくちょくやってるから

Mozilla が H.264 をサポートへ、webM 一本化を断念
http://japanese.engadget.com/2012/03/20/mozilla-h-264-webm/

主流は明らかに H.264 である以上、Mozilla の決断はけっきょくユーザにとって一番良い形になったと言えそうです。
そしてMozilla Corporation 最高技術責任者 Brendan Eich 氏が言うとおり「一戦には敗れたが、戦争は続く」。

>>24
主にJMの出力に対して比べてるとか、Elecard Streameyeが使用されてる。
ttp://www.elecard.com/en/products/professional/analysis/streameye.html
（無料体験版もアリ）

音声に対しては分からないけど、多分JMに似たようなインプレメンテーション
の出力に比べてるんじゃないかな。

548 ：名無しさん＠編集中：2012/03/03(土) 16:38:46.54 ID:az66lC9S
立てた

マジでウザいから以降色空間関係はこっちでやって

【YUY2 YV12】色空間スレ【RGB24 33】
http://toro.2ch.net/test/read.cgi/avi/1330760227/

2 ：名無しさん＠編集中：2012/03/04(日) 21:06:03.14 ID:9zYKsEnU
RGB33ってなんだ?
まさかpart33とか？

3 ：名無しさん＠編集中：2012/03/05(月) 07:19:08.35 ID:kto4BhQj
RGB33?
なにそれ

4 ：名無しさん＠編集中：2012/03/05(月) 07:57:31.41 ID:vAVL3m4W
【YUY2 YV12】色空間スレ【RGB24 32】
http://toro.2ch.net/test/read.cgi/avi/1116263327

たぶん、32スレ目だと思ったんだろう。

6 ：名無しさん＠編集中：2012/03/05(月) 11:45:01.91 ID:5ot5CNPU
RGB33www
ないわぁw
やはりその程度の理解力しかなかったかw

>>25
映像伝送の際に使われることの多いAVC/H.264 Highプロファイル（4:2:2には非対応）と比較して、2倍の色情報を持つことが可能なAVC/H.264 High4:2:2プロファイル（4:2:2に対応）に対応する

2倍の色情報…?

YUV4:2:2 → ２ピクセルで色差情報２つ（Cb×1、Cr×1） → １ピクセルあたり１個の色差情報
YUV4:2:0 → ４ピクセルで色差情報２つ（Cb×1、Cr×1） → １ピクセルあたり0.5個の色差情報

間違ってないだろ

YUV4:2:0はYUV4:2:2の色差情報インターレース版だと思えばいい

ヨブさん今回は2164のまま更新されないけど2183でバグがあったから2184も見送りなのかな？

>>34
単に忙しかったりするよ。444p10でエンコしてた時クラッシュバグ発見したし、
アレをデバグしないといけないし(バニラなx264では発生しない)。

444はそんな問題抱えてたのか

バニラって何？

バニラ（アイス）はプレーン（オムレツ）とか素（うどん）とかと同じ意味
ソフトウェア的には、いけないパッチ当てたりけしからん魔改造とかしてない
素顔のままの君ってことです
たぶんね

ひやくしすぎだろ。

クリームパイとストロベリーミルクなx264をお願いします

各パッチが何味か決めようぜ
L-SMASHはチョコチップでどうよ

誰にもフォローされてないtwitterで独りでつぶやいてなさい

バニラさん知らない奴がいるなんて・・・

どうもパッチと聞くとジジ臭いイメージしか出てこないんだが。

ポール牧が浮かんだわ

>>43
知らない
誰だよｗ

馬韮さん？

>>43
ローカル限定の話題か？

ギャラクシーエンジェルじゃないの

山崎

バニラは俺の女

実はレバニラの誤植

で、r2185はまだ来ないの？

もうr2190ぐらいじゃね

chenge.logにはまだそんな報告来てないんだが

changelogの更新はx264.nlでx264.exeが更新されるタイミングじゃなかったっけ

っ ttp://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
(>>1にも書いてあるだろJK)

レバーとか食感キモイし味も不味いしなんで内臓喰う野蛮人がいるのか理解でけへんわ

なるほど・・・縦読みか

食べ物を大事にしろよ
人口爆発と食糧難の時代はいずれくるぞ

>>58
お前は野菜だけ食ってろ

関西圏の奴は小麦粉さえあれば生きていけるからな

関西人は小麦粉にソースかけて食えば満足

前スレ874で少し報告したのですが、--vf resize:csp=i444:16について質問させて下さい。

RGBを10bitYUVでエンコードして結果を見る実験をしているのですが、
　　x264_r2184_10bit.exe --vf resize:csp=i444:16 --qp 0 --output-csp i444 --colormatrix smpte170m -o 10bit-resize-i444-16.mp4 Colorbar.avs
　　x264_r2184_10bit.exe --vf resize:csp=bgr:16 --qp 0 --output-csp i444 --colormatrix smpte170m -o 10bit-resize-bgr-16.mp4 Colorbar.avs
としてvideo filterで、RGB(8bit)から16bitYUVorRGBへの変換をさせてからエンコードしようとしました。
しかし、できたMP4をデコードしてみると、8bitYUV化した時と同じように１２ヶ所で色がわずかに変化してしまいます。
　　http://www1.axfc.net/uploader/Img/so/138749.png

一方、ffmpegで
　　ffmpeg_38996.exe -i Colorbar.avs -f rawvideo -pix_fmt yuv444p16le - |
　　　　x264_r2184_10bit.exe - --demuxer raw --input-csp i444 --input-depth 16 --input-res 640x360 --output-csp i444
　　　　　--frames 10 --fps 1/1 --qp 0 --colormatrix smpte170m -o 10bit-ffmpeg-yuv444p16le.mp4
としてyuv444p16leでraw出力したものをx264(10bit)に直接渡してエンコした場合は、正しく色が保持されます。
　　http://www1.axfc.net/uploader/Img/so/138750.png

質問： --vf resize:csp では、RGBから16bitYUVに高精度で変換することはできないのでしょうか？

使用ツール
　Avisynth 2.6 Alpha3
x264 r2184 32bit 8bit-depth (x264.nl)
　ffmpeg r38996

デコード環境
　MPC-HC v1.6.0.4014
　Haali Media Splitter 1.11.288.0
　ffdshow tryouts rev4399 （※）

　※「YV12からRGBへの高画質変換(High quality YV12 to RGB conversion)」の
　　チェックを外しています。

ソース画像やavs,MP4,詳細メモなどを入れた再現セット
　http://www.mediafire.com/?9a9e7ukvwwkfivv

x264は8bitじゃなくて10bitでしたorz　（詰め合わせの中には一応8bitでエンコしたものも入ってますが。）

以上です、編集長！

うむ、没だっ！

>>64
--vf resizeはx264にリンクされているswscaleをそのまま利用するので、
x264とffmpegの間で違いがあればそれは恐らくx264の中にはlibavがあって、
ffmpegと違うアルゴリズムをswscale内に使用しているという事になる。

avconvとffmpegでも同じ結果が出れば（＝この二つの間に違いが出てくる）、
ttp://bugzilla.libav.org/ でバグレポキボンヌ。

>>64
avs.c見る限りavisynth2.6で--output-csp i444が指定されavsがYV24でなければ入力の段階でConvertToYV24かけてるから
x264の仕様かと

>>69
>>64の ffmpeg_38996.exe を avconv_32956.exe に置き換えて実行してみたところ、
　　●上下反転している
　　●8bitYUV化した時と同様に12箇所で色が変化している
という結果になりました。まさかここまで違う結果になるとは。avconvでは何か別のオプション指定が必要になるんでしょうか。
なんか自分の中で混乱してしまってますが、これは結局Libav側の問題ということになるんでしょうか？

>>70
書き忘れてしまいましたが、avs2pipemodを使ってbgr24をraw入力した場合も8bitYUV化と同じになりました。
ただ、avsの場合にConvertToYV24(8bitYUV化)が入ってしまうようだと、それも色変化の原因になりそうですね・・・。

>>70
x264cliがswscaleをリンクしてる場合は、avisynthの色変換は使用されないよ
http://git.videolan.org/?p=x264.git;a=blob;f=input/avs.c;h=bf4d39ad0baa02f520241eb992f25f6b01c856c2;hb=refs/heads/master#l220

#if !HAVE_SWSCALE ってなってるでしょ

!の意味が通じるのか微妙だが

>>71
上下反転はさておき、libavとffmpegのswscaleの動作の違いみたいっすね。

>>64
x264.cのinit_vid_filters()を見ると、sourceフィルタにresizeフィルタを
"normcsp"というオプションで固定で（無条件で）チェインさせているのが分かる
--vfオプションでリサイズフィルタを異なるパラメタで指定してもそれは
フィルタチェインに追加されるだけなので、デフォのnormcspの時点で劣化してるなら
意味ないでしょ

resizeフィルタの実装はfilters/video/resize.cを見ればわかる
normcspオプションが指定されている場合は、色フォーマットは
pick_closest_supported_csp()によって決定されているみたいだが
見たところ高解像度モードで処理するかどうかは単純にソースの色成分で
8bitを超えるものがあるかどうかで決めているようなので、現時点ではx264の仕様
（というか少なくともそういう実装になっている）ということになるんじゃね

>>75
部分的にしか見れてませんが、へなちょこなりにコードを追ってみました。
init_vid_filters()の最初のほうにあるx264_init_vid_filter( "resize",・・・,"normcsp")は、
コード中のコメントにあるように、ソースの色空間を既知のものに確定させるための処理に見えます。
今回の場合はソースがbgr24なので、pick_closest_supported_csp()まで行かずあっさり確定して返っている気がします。
その後いくつかの処理の後にもう一度、今度は"normcsp"にはせずにx264_init_vid_filter( "resize",・・・)を
呼び出しているので、こちらで実際のresizeフィルタの初期化を行っているのではないかと。
エンコード時のログにも、resizeのinit()の中にある
　　resize [warning]: converting from bgr24 to yuv444p16le
というメッセージが出ていますので、少なくともソースのbgr24から色空間の変換を行おうとしているように見えます。
そんなわけでやはりLibavのlibswscaleを使っているのが原因なのかなあと・・・。
間違っていたらすみません。

>>76
なるほどログにそう出てるんなら正規化走った後で16bit化してるわけでは
ないのかな
じゃあ俺の勘違いか、ごめん

RGBソースは8bitの--output-csp rgbで圧縮すればいいじゃんっていう話は置いておくとして、
RGBソースを10bit-depthのx264でyuv4xx(10bit)にエンコードすることを考えると、

　　・特にresizeを指定しなくても自動的にyuv4xxp16leまたはyuv4xxp10leに変換してエンコードする。
　　　（今はyuv4xxp(8bit)になってしまう）

　　・Libavのlibswscaleの挙動(？)を、FFmpegにあわせ、途中で8bitYUV化が入らないようにする。

となっていたほうが嬉しい気がしますが、そういうふうにはならないのかな。

8(Y) + 9(Cg) + 9(Co)で8-bit RGBを再現できるこれも良さそうだが、
今のx264だと全部一緒くたに9-bitでやるしかないのが残念。

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

ヨブさんまたサイトが・・・

ヨブさんをヨブ

審議拒否

来月から始まるトランスフォーマの新シリーズ。これは特撮CG系の番組だが
こういうのはcrfでエンコしない方がいいんだっけ？動き激しすぎて容量膨れまくるだろうし

意味不明

品質一定にするためのcrfだろ

crfで品質一定に？何の冗談だよ。いいとも増刊号とか60fpsでエンコするときも
毎回シーンチェンジを切り目に20000フレーム毎に分割エンコしてmkvでマージさせている。
crfを指定してエンコしたものは品質(圧縮率とSSIM/PSNRの値）が一定になることは殆どない。
値もバラバラ。一定になるのならdb値の変動幅も小さいはずだろ？

おもしろい

ほんとおもしれーな
ビットレ指定と勘違いしてんじゃねえのか

いいとも〜

>>86
お前もうエンコしなくて良いから

じゃぁcrfが品質一定だという根拠と正しい意味を説明してみせろ。

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=x264+crf&num=50

x264エンコーディングで固定品質(qp,crf)の設定値を比較
x264のオプションの設定 品質基準VBRとは

--crfオプション
こちらのオプションは-qオプションに非常に良く似ています。x264のヘルプを見ると、「Quality-based VBR (nominal QP)」とあります。直訳すると品質ベースのVBR(名目上のQP)です。

だから用語じゃなくてさ。

アカン言葉が通じない

これはファビョりフラグ

いつの間にかPOP氏が2184ビルドしてた

>>91
他のオプションとの兼ね合いでcrfの効果は全然違うし、明確な定義はソースを見れとしか
おおむね人間の感覚で一定の品質になるようなビットレート配分というぐらいの意味合い

・圧縮率は品質とは無関係だから一定にはならない
・PSNRも人間の感覚とは大きな乖離があるから一定はならない

SSIMは人間の感覚にマッチするように考えられた評価関数だけど、
最初にも述べたようにx264で用いられてる品質の定義とは必ずしも一致しないし、
そもそもほかのビットレート配分をコントロールするオプション（qcomp、AQ、trellis等）によっても変わる。

この人一定のサイズに揃えてあると品質も一定だと思ってるのかな？
どんな動画でも一律似たような圧縮率になると思ってるんだろうか？

97のレスを見てもしっくりくるレスがでてこないんだが
結局crfは品質を一定にできるわけじゃないんだろ？

どこかの雑談スレでやれよ

>>99
お前のいう「品質」とは？

ソースと比べての画質・圧縮率・崩壊の加減

とりあえず透過性ロゴは見えなくするし、いらないCMもカットするので
その部分に対する差異は無視するとしてだな。

>>102

>画質
>崩壊の加減

その感じ方は人によってまちまちだろ？
SSIMなり、x264のcrfなり、それぞれの理論がある。必ずしも一致するわけではない。
また、人によって、用途によって、品質の評価を変えたいという場合のために各種オプションがある。
だからcrf以外のオプションの指定の仕方によって結果は変わってくる。

>圧縮率

それは品質をあらわすものではない。
違うソースでも圧縮率が一定なほうが、むしろ品質が一定とは言いがたい。

とりあえず「crfの品質一定」について知りたいのは
↓こいつのレスに対する根拠とその意味なんだけどな。

> 85 名前：名無しさん＠編集中[sage] 投稿日：2012/03/27(火) 13:54:36.87 ID:uAKxVqwy
> 品質一定にするためのcrfだろ

さらに言えば>>83のレスのまともなレスがこないのでさらにしっくりこない。

>>104
なんとなく伝えたいことは伝わってくるが、どんどん話がズレてきてないか？

>>105
crfが品質一定というのは根拠も何もそういうオプションだし。
ググればいくらでも出てくる話だし、x264 --hullhelpでも、「Quality-based VBR」と説明されてる。

http://mewiki.project357.com/wiki/X264_Settings#crf
もっと詳しくはこのあたりとか。

>>83については、動きが激しいなら品質を保つにはたくさんビットレートが必要なんじゃないの、としか言いようが。

>どんどん話がズレてきてないか？
ずれてねーだろ。
品質って概念が食い違ってるから話が平行線なんだろうが。

規定した一定の設定に沿ってビットレート消費を調節するそれがcrf
なので品質はその設定に沿って決められている
ビットが必要なところはその設定に沿って食うし、必要ないところは節約する

それだけだろ品質の認識の違い、誤解が無駄話の原因

ビットレート一定だとどこでも一定のため動くところも動かないところも「ビットレート」が一定
決して品質ではない、ビットが多く必要な部分では破綻する

> >>83については、動きが激しいなら品質を保つにはたくさんビットレートが必要なんじゃないの、としか言いようが。

そりゃビットレを盛ればそれなりに品質も保てると思うがそれをやると容量が膨らむだろ？
実質CMカットして24分番組らしいからデータ量的に250〜300M前後に抑えたいんだよ。
トランスフォーマ系は毎度長いので2・３クールぐらい来そうな気がするし何話まであるのかわからないしな。
動きの多い実写/CGパートの混じるアニメとかだと、crfでエンコすると容量が一気に膨らむし難儀するだろう。

>>108
容量が膨らむのが嫌ならcrf値を上げれば？

しらねえよそんなの
お前はもう品質について語るな

そもそもCRFは一定ファイルサイズでエンコする設定じゃないだろｗ
ビットレート指定のABRの2パスでやれや

だから品質についてなんてどうでもいいだよ。
>>85からレスが帰ってこないからイライラしているだけだ。
なんで他人のあんたらが噛みついてくるんだか。

>>112
2chに書き込みして何戯言いってんだw
噛みつかれて、もともとの話題。

だからIDと顔が真っ赤になっているんだよ

crf指定　画質：できるだけ一定 ビットレート：↑↓
bitrate指定 ビットレート：できるだけ一定 画質：↑↓

ってだけの話だからサイズを制限したいならビットレート指定で決まりじゃね？

>>113
IDが赤いのはレス数が多いのが原因
あと顔は別に赤くないので問題ない。

>>114
そうなんだよな
crfでも--vbv-maxrate指定ある程度までビットレ制限できる。
ま、動きの多いソースだとどのぐらいまで抑えていいものか判断に迷うが

動きの激しい場所で容量が膨れてほしくない人でcrfを使いたい人には
--crf23 --qcomp 0　なんてどうでしょうか？
きっとご期待に沿える動作をしてくれると思います

容量決め打ちしたいのにCRF使うなんてアホだろ

品質一定画質一定にしたいならcbr10000でもしとけよもう

>>118
変なのに絡まれてくっそウザかった気持ちはわかるけど、もうその話は終わって、
ただファイルサイズ抑えたいって言ってるだけなんだから、わざわざ無駄にかき回さないほうがいいと思う。

>>116-118
アホの沙汰、飽きれてマジレスする気も失せる。

>>120
馬鹿は来るなひとりで死んでろカス

>>120
というか小学生の餓鬼じゃないんだから基本くらい自分で勉強し直せ

俺もVBRまわりは実はちょっと疑問
qcomp最大、aq-mode=2にするとVBRっぽくなると理解してるんだけど
何でデフォでそうしないんだろ
--crf指定でもデフォではqcomp 0.6だよね？

たとえば、完全にVBRだと激しく動く部分にレートが割かれ過ぎるが
人の目にはどうせ動きの激しい部分の劣化はあまり認識できないから
デフォはもっと下げといてABR寄りにしよう、とかいう理由なのだとすれば、
レートコントロールが実際には人の認知・感覚に対して
まだ十分最適化されていない、ということになるのでは

>>123
単一画像の最適化と動画全体の最適化を混同しちゃてるね

ID:etmZvqiY
学習能力無いのか。おまえはNGぐらい覚えろ。

やべえこいつ

なーにあと残り1時間半でおまえらのNGも無効になるだけだ。

crfが完璧に俺の望むだけの動作をしてくれない、かゆいところに微妙に手が届かない
っていう話なんだろうけど現行のx264だとそれが限界、後は手作業で工夫しろって事で
納得してもらうしかないよね

キチガイがオプションを理解できてなかっただけ

既に終わった話をいつまでもズルズルひきずってなにやっとんだ？

キレ芸しかできない寒い芸人が静寂に支配された劇場で
満員の観客から冷ややかな視線を浴びせられて、怯えながら芸を続けてるだけ。
そんな感じ。

>>127の子はどこに行っても阿呆扱いされてるな
自分の言ってることがどの位アホかすら気づかない規格外のアホ
春休みはこういうのを嘲笑するのも楽しいな

春休み？学生が混じっているのか。

正直疲れた

83 名前：名無しさん＠編集中[sage] 投稿日：2012/03/27(火) 02:26:09.83 ID:Jok74uSE [1/15]
来月から始まるトランスフォーマの新シリーズ。これは特撮CG系の番組だが
こういうのはcrfでエンコしない方がいいんだっけ？動き激しすぎて容量膨れまくるだろうし

86 名前：名無しさん＠編集中[sage] 投稿日：2012/03/27(火) 15:12:20.15 ID:Jok74uSE [2/15]
crfで品質一定に？何の冗談だよ。いいとも増刊号とか60fpsでエンコするときも
毎回シーンチェンジを切り目に20000フレーム毎に分割エンコしてmkvでマージさせている。
crfを指定してエンコしたものは品質(圧縮率とSSIM/PSNRの値）が一定になることは殆どない。
値もバラバラ。一定になるのならdb値の変動幅も小さいはずだろ？

91 名前：名無しさん＠編集中[sage] 投稿日：2012/03/27(火) 16:01:55.92 ID:Jok74uSE [3/15]
じゃぁcrfが品質一定だという根拠と正しい意味を説明してみせろ。


108 名前：名無しさん＠編集中[sage] 投稿日：2012/03/27(火) 18:15:14.08 ID:Jok74uSE [9/15]
>>83については、動きが激しいなら品質を保つにはたくさんビットレートが必要なんじゃないの、としか言いようが。

そりゃビットレを盛ればそれなりに品質も保てると思うがそれをやると容量が膨らむだろ？
実質CMカットして24分番組らしいからデータ量的に250〜300M前後に抑えたいんだよ。
トランスフォーマ系は毎度長いので2・３クールぐらい来そうな気がするし何話まであるのかわからないしな。
動きの多い実写/CGパートの混じるアニメとかだと、crfでエンコすると容量が一気に膨らむし難儀するだろう。


ｗｗｗ

むしろJok74uSEってのが春休みで湧いてきたんだろ
頭もな

>>Jok74uSE
ジョークなようなウゼェ奴って意味？
これだけバカだとID変わっても一発でわかるな。ID隠してバカ隠せずo(^▽^)o

>>137
お前も黙ってりゃいいものを

でもサルにおまえはサルだと自覚させるのも大事かも

こういう流れは色空間の話と違って2chらしくて微笑ましい

色空間ネタはもう要らないから

いまさらだけど全然動いてないと思ってたキルミーベイベー意外と縮まらない

どしたのわさわさ

おお…crfで品質一定に？何の冗談だよ。

>>142
>>22

気合が足りないんだよ。

　　　 ＿＿_　　　　　　＿＿_
.　 　（　　　 ）　　　　 （　　　 ）
　　 　￣|　 |　 　　　　| 　|￣
　　　　　|　 |　　 　　　|　 |
　　　　　|　 |.　　　　　| 　|
　　　　　＼　＼＿_／　／
　　　　　　 ＼　　　　／
　　　　　　　/|.　 　　|ヽ
　　　　　 ／ ⊃　　 ⊂.＼
　　　　／ ／|　　　 　|＼ ＼
　　　 （　<　 |　　　 　|.　 >　）　ひみつだよ
　　　　＼ ＼|　　　 　|／ ／　
　　＿＿ ＼_＿　　＿__／
　　||＼　　.:;Σ;:| 　|:;て;:. ＼
　　||＼＼　　　"""""　　 　＼
　　||　 ＼||￣￣￣￣￣￣￣||
　 　 　.　 ||￣￣￣￣￣￣￣||
　　 　 　 .||　 　 　 　 　 　 　 ||

　　　　　　　　　　　　＿＿＿＿＿＿
　　　　　　　　　　　　＼　　　　　死　 ＼
　　　　　　　　　　　　 |,.＼　　誰　者　　＼
　　　　　　　　　　　／　　 ＼　 │　は、　 ＼
　　　　　　　　　　/　　　　,. i ＼__？＿＿＿__＼
　　　　　　　　　　|　　　 /.| |＼||＿＿＿＿___||~
　　　　　　　　　　| .| 　 |　| |　 ||　 　 　 　 　 ||
　　_./⌒..───' ｜　/　| |　.||　 　 　 　 　 ||
　　__/⌒ 二二ニニ ノ　　Ｕ　 || 　　　　　　　||

レスが進んでるから更新きたのかと思ったらこれだよ!!!

ここでホットな情報をひとつ
有吉がもっとも嫌いなのはナンチャンらしい

そういやAnother面白かったな

まだ最終話見てないんだからネタバレすんなよ
絶対だぞ

犯人はヤス

Another録画してたけどまだ観てないｗｗｗ
面白いなら一気に観てからエンコするかな

>>148
http://toro.2ch.net/test/read.cgi/avi/1330397335/822

別スレで同じようなこと言ってる奴が居ると思ったが、
暴れてる奴は同じ奴でフイタｗ

場の空気を読まずに「おまえ」「こいつ」という1人称を
平然と使い続ける奴は人格障害だから温かい目でみてやんな

>>148
おまおれｗ

ヨブさんサイト復活したけど10bitのx264が404です

ヨブさん10bit復活ありがとうござる

とりあえずここで
http://k4095-takuan.blogspot.jp/2011/10/avisynth-x264-10bit-depth.html
↑によると、(x264での)16bit -> 10bitのティザリングを行わない方法がいいといっているんだけど、これってどういうことなの?

そんなの書いてないだろ
f3kdb使ったら自分の好きなディザリングアルゴリズム使えるってだけだ

r2184ってなんだか容量小っちゃくなって細部つぶれぎみな気がするな
2164と同じくらいの容量目指しても
海外のユーザーは高圧縮最適化を目指してるのかね

だったらcrfを0.5くらい上げてみればいいだけじゃん

下げるの間違いだった

それを言うならqcompの値を調整すればいいんじゃない？
crfだけじゃあまり変わらんと思う、むしろ余計変になるかもよ。

>>160
ditherのDither_convey_yuv4xxp16_on_yvxx()だとディザリングアルゴリズムが選べないというわけか

>>165
Dither_convey_yuv4xxp16_on_yvxx()は16bit出力しかできないからディザリングそのものがないのでは。

>>164
逆だろw

crfだけ変えてもビットレート食うだけで変わらないことは多々ある

>>159の記事の「f3kdb()で10bit出力してx264(10bit)に渡す」というケースに関しての質問です。記事では、

　・x264(10bit)に10bitを入力すると、内部で一度16bitに変換し、その後10bitにディザリングしてエンコする。
　・skip_depth_filterパッチが当たっているx264(10bit)に10bitを入力すれば、x264内部での
　　「10bit→16bit→(ディザリング)→10bit」の処理が省略される。

とのことで、「個人的にはf3kdb()で10bit出力してskip_depth_filterパッチを当てたx264でエンコがいい」とされています。

一方、depth.cの62行目あたりのコメントを読むと、
　　「ソースがscale_image()と同じ方法でアップコンバートされた場合は、
　　　ディザリングで元のソースと同じビット深度に落としたとしても可逆」
と書かれているように読めます。

だとすると、x264内部での「10bit→(アップコンバート)→16bit→(ディザリング)→10bit」は可逆となるので、
skip_depth_filterの有無による違いは、（無駄に）処理をするかどうかというだけで、
エンコード結果に違いはないように思えるのですが、違うのでしょうか？

補足：
　・depth.c
　　http://git.videolan.org/?p=x264.git;a=blob;f=filters/video/depth.c;h=e01aaae4f46cdebbaedf2cb2cc92aec95764af41;hb=HEAD

　・62行目からのコメント引用
　　The dithering algorithm is based on Sierra-2-4A error diffusion. It has been written in such a way
　　so that if the source has been upconverted using the same algorithm as used in scale_image,
　　dithering down to the source bit depth again is lossless.

あ、失礼、記事を読み違えてた気がする・・・。
skip_depth_filterの有無でエンコード結果が変わると書いてるわけじゃないですね。

>>169の「結果に違いは出ない」という解釈が正しいかどうかだけでも教えていただければ幸いです。

なぜコメに投稿しない

そうしようか迷ったんだけど、ちょうど話題に上がってたし、ここのほうが色々な人の意見が聞けるかなと思って。

http://goldenhige.cocolog-nifty.com/blog/2012/03/rgb24x26410biti.html

これがYV12だとどうなる?

>>174
YV12とYUV444の違いがわかればわかるでしょ

BENIがカバー集リリースしたぐらい意味わからん・・

更新がないと過疎るな…

個人記事の話題をこっちに持ってくる必要はないな

!ninja

!nanya

!oo…

>>169
実際自分で試してみればわかると思うけど、skip_depth_filterの有無だけではエンコ結果に違いはない
8bitソースをそのままでエンコしたのと、bit変換だけして（f3kdb(Y=0, Cb=0, Cr=0, ditherY=0, ditherC=0, output_mode=2, output_depth=10)
skip_depth_filterをパスしてエンコしたのを比較すると動画部分のバイナリは一致するから

当然bit変換のやり方によっては当然エンコ結果は違ってくるだろうけど、
上のやり方だとdepth_filterを通過しようがしまいが同じ動画ができる

>182の4行目、skip_depth_filterをパスしてエンコしたのっておかしいな

正確には「depth_filterをskipしてエンコしたの」だ

skip_depth_filterをパスしたらってdepth_filterをスキップしてないみたいになってしまう。

そろそろr20xxか・・・

は？

ひ？

くたばれ！

おお…

ちんこ生えてきた

--tune futanari

白い弾幕

更新が無い
ただの屍のようだ

2192ｷﾀ？

x264 rev2184+663 tMod (x264_64_tMod-10bit-all)とavs4x264mod v0.6.2 (avs4x264mod-laa)の組み合わせなんだけど、以下のログ (画像参照)の様なものがどんどん表示されていくんだけど、以前バージョンのようにしたい場合はどうしたらいい?
ttp://www.nmm-hd.org/upload/get~3b7V8zx9sYs/ets-opt.png

--fullhelp

コマンドプロンプトの横幅を90文字くらいに増やせばいいんじゃね

>>194

ttp://fsm.vip2ch.com/-/hirame/hira086361.png

こんな感じ？

high_precision_fps が原因？で
一秒間あたり10フレーム以上の処理が行われると、こんな風になったよ。

>>197
そうそう、こんな感じ

ていうかFHDのエンコで10fps前後しかでないのってどうなのさ？

どうも何も、それくらいの環境orそれ以下の人のほうが多数派

HDのエンコで10fps前後しかでない俺の環境バカにしてんのか

それ以上のスピードを出してもしょうがなくね？

1fps しかでない俺のPen4馬鹿にしてるのか

m9(^e^)

>>203
馬鹿乙

2600Kだけど2fpsぐらいしか出ない

オプションを凶悪にすればするほど高まっていくソースのままでいいやと思う気持ち。

そーすね

気に入ったもの以外はデフォ相当の設定で気に入ったものはcrf値下げてumh subme 11

>>209
インタレ保持でcrf18、ついでにqcompも0.8に
…あれ？元のtsとサイズ変わらなくね？
なんて事があるから困る（苦笑

そういうは単なるバカ。

片言で馬鹿にされる>>210ｶﾜｲｿｽｗ
ここ最近HDD高騰のお陰で圧縮率悪そうなのも試しにエンコしたけど
やたら動いたりバックにLEDの巨大スクリーン有る様なライブ物なんてcrf23 qcomp0.7で半分でも御の字だからねぇ…。
そんなのを>>210でやったら下手すると元サイズ超えそうだｗ

ヨルムンガンドのグレインノイズやべーんだけどどうしよう

どうもしなくていいのでは
サイズが増えるのは当たり前だし

グレインノイズ見た瞬間ナニ思うかって言ったら「これは縮まない」だよな
昨夜視聴しながらそんな事ばっか考えてたわ

まぁ演出でつけてるもんを潰そうとは思わなかったからいつも通りやってみたけど
1.55Gになってしまった　これじゃDVD-Rに4話どころか3話も入らん･･･

せめて1.45Gくらいにサイズ減らそうと思ったらこういう場合まずどこを弄るべき？
crf一択かな

サイズ減らすならcrf上げるかqcomp下げるか、その両方でもいいし
細部捨てるならaq下げるのもあり

>>217
ｔｈｘ　その方向でやってみる
あとEDが特に肥大するのでここだけ囲って緩める感じにもしてみる

1280x720 24p化 crf20 dcomp0.6
グレインを極力再現する方向で調整して600M程度なんだが…
1G越える人はやはりソースを再現する方向で
エンコードしているんだろうか

>>219
概ねそんな感じ　1クールがDVD-R2枚に納まればいいと思ってる（安いし）
一応この設定でもソースによっては300M程度まで縮むんだけど

qpmax下げるのもええんちゃうか

ちらちら見にくくてしょうがないのでグレインを潰した

10bit版x264のディザリングってどんな奴?

Sierra-2-4A error diffusion
Floyd-Steinbergの一種 オリジナルのFloyd-Steinbergよりも高品質と言われている（そんなに差はないと思うが）
一般的にFloyd-Steinbergは高品質だけどディザとか残すのにはかなり設定を詰めないといけないので
ディザを残したい or バンディングが激しいソースのエンコにはf3kdbでOrdered ditheringとか使えば良い
あと速度面ではOrdered ditheringの方が優っている
ditherのデフォルトはOrdered dithering

>>217
psy-rdは…アニメなら既にある程度調整してるか。
縮めるなら砂嵐が靄に成るぐらいの妥協は覚悟。

>>224
ありがとう

>>197の回避策って無いのかな

>>216
BD-Rドライブ買っちまえよ、もう1万切ったモデルも出てきてるんだし
容量に余裕ができるとエンコも楽になる。

10bitとかRAWとかやめれば縮むだろ。

>>227
よくわからんけどx264じゃなくてavsの問題の気がするんだが

>>228
BDだと1枚分になるまで溜める必要があって結局圧迫するやん

>>227
[16.8%] 1234/34567 frames... みたいな進捗メッセージは
CR(キャリッジリターン)を使って同じ行に出るようになってる
そういう具合に何行かに分かれてるってことは、そのタイミングで
LF(ラインフィード)が出力されたために行が変わったってことだろう

実際にはLFだけ出力しているとは考えにくいので、たぶん
なんか警告メッセージみたいなものが出力されて、それが次の進捗メッセージに
上書きされてるんじゃないのかな

回避策ではないけど
x264 ほげ 2 >log.txt
みたいに標準エラーをリダイレクトしてlog.txtを見れば、何が実際出力されたか
わかるはず

>>231
んーアニメ1話1GB近辺で2クール分を1枚に入る感じでエンコして焼いてるけど、全く圧迫されない。

2TBのHDDを6800円の時に2台買ったけど、アニメ毎期20本前後エンコしてて
>>233の感じでやってるとHDD1台の半分も使い切れない、すごく余裕がある感じする
2TBのHDDと一番安いパイオニアのBD-Rドライブ、BD-R50枚で2万ちょいくらいだと思うけど
それだけの投資でだいぶ楽になる。

>>232

出たり出なかったり
最初から出る訳でもないので
検証し辛くて
時間取れたら調べてみる

High-precision fps, estimated total size & encoded file sizeのpatch当てて自ビルドして使ってるけど
うちでは出たことないな
64bitバイナリをavs2pipemodでパイプして使ってる

ヨルムンガンド 1280x720 24f/60f vfr crf20 qcomp 0.54で235MB前後。

思ったほど膨らまなかったわ。

そろそろファンの回転数あげなあかんやろか？

3960Xを5GHｚOCしてると冬でもつらい

ほぼ同じ>219が600Mって言ってるのに235Mて
絵凄そうだな

tvkはグレインノイズが潰れてるらしいから、そっちで録画したやつは素直に縮まるんじゃね？

MBと書かないでMで済ませてるの見るとイラっとする

>>241
まじで
エンコーダの差なのか

一応、BS11ソースな

逆に同じ設定でQBリベリオンをエンコしてみたがこっちは350Mまで膨らんだ。

だいたいAACは平均30M前後になるので
実質ヨルムンガンドの映像は200M、QBリベリオンは320Mだな
崩壊や破たんは無いから気にしていないが。

エンコオプション全部見てみないと何とも言えない気がする
crf20 qcomp0.54だけだとよくわからない

グレイン除けば縮まらない画じゃない気もするしpsy-rdも限界まで下げれば縮まるかも知れん
ただ背景がべったり塗りつぶした油絵の様に成りそう

毎回アニメのCMもtrimで後半にまとめて含めるから
そういうベタ塗りになるようなエンコは最初からお断りだが

たとえば銀河キックや、プリティリズムや、へうげものとか
アニメと実写が混ざった番組とかだと油絵みたいなエンコをすると大変なことになるｗ

で、ID:m0vE8+poの設定晒しはまだか？

目暗設定お断り

実写もニコニコの「なにこの高画質ｗ」レベルで問題無いって感覚に成ってて
qcompもrdも下げて何か問題が？ってのいるからねぇ・・・。

パラメータ弄っていい感じになったと思ったら別の箇所が駄目になる・・・っての繰り返して
結局行き着く先はデフォルトという

いつもザラザラ
あなたのエンコに這いよる混沌
グレインノイズでっす

ニャルラトホテプは来るんじゃねぇ

フィルムグレインって味があるとか言われてたけど、エンコに限っては邪魔者でしかないな。

(」・ω・)」うー！(／・ω・)／にゃー！

>>250
だいぶまえにx264スレで晒したから、もっかい晒す気など毛頭ない。
そもそも他人のパラメータを見せられたからと言って何の参考にもならんだろ。

ID変わってからレスですか

それに個人的にはx264のパラメータ云々より
avsフィルタやaviutilフィルタの組み合わせの方が重要と考えているわけだが
avsやaviutilを使わずにx264のみでエンコする奴には何を言っても通じないだろうな

笑える

じゃぁ一生笑ってろｗ

だいぶ前に晒した時に叩かれたんで勘弁してくれって事ですね

わかります

日をまたいでIDが変わったときに自演するのは常識

別に自演なんてしとらんがな
都合が悪いレスが来たとたん態度を変えるのやめろよな

ｱﾆｦﾀうぜぇ

このスレの９５割はアニオタだろ

>>260
まあグレイン消したいだけならそういうフィルタかませばいいんだしな。
逆にフィルタでグレイン付加することもできるし。
x264でもfgoパッチでグレイン付加できるんだっけか、やったことないけど。

グレインと一緒にディテールもさようなら

日本人なんだからグレインなんていわずブツブツって言おうぜ

例　このブツブツすげー　ブツブツ多くてエンコ大変そう　うわ、これブツブツだらけじゃん

日本人ならブツブツの感覚をそれに使う事はないだろうな

(:.;ﾟ;Д;ﾟ;.:)ｸﾚ､ｱﾗｼﾙ!!

ザラザラ

グレインはジリジリかチリチリかなあ

ブツブツいうとあの画像思い出すからやめて

>>269が真実
>>268はディテールに気付かない目くらでグレインだけ消せると思ってるアホｗ

グレインは普通ザラザラじゃね。
ブツブツって感覚はわからん。

ツブツブって言いたかったんじゃないかな
まぁそれでもザラザラだろうけど

ああ、ツブツブならわからんこともない気がする。

ツブツブジュースって美味いよね

俺イクラはダメなんだよね

今のx264ってtrellisとdeadzone-inter・deadzone-intraって同時使用できるようになったの?

できねえよ

trellis=1ならできる

できるって言っても併用してdeadzone下げても細部は残らないぞ
ファイルサイズ微妙に変わったﾜｱ程度しかわからん結果になる

グレインも落ちまくりで全然だめ
使うならcrf10くらいで使う覚悟がいる

そんな覚悟を決め込むなら最初からソースのまま残せよｗ
ソースの演出をある程度までぶち壊してまでで圧縮率重視するのなら
多過ぎるグレインは自分で気に入るまで除去しても問題ないと思うがね

ぶっちゃけアニメはキャラデザとりシナリオと楽曲でよさが決まる。
背景などのグレインノイズとか別に削っても気にするほどでもないわ。
アニメ1本につき600MBも要するとかバカげているしなｗ

次の人どうぞ

ダメだこりゃ！

グレイン削る残すはエンコする当人の自由。
加減も含めて好きにしたらよろしい。

>>268
fgoはグレインの付加なんかしないよ
グレインがつぶれ過ぎないようにするだけだよ

おお…

>>291
fgo使ったことないやつが書きこむなよ。

そもそもfgoの利点って何？

>>294
昔D_S氏が作った「グレインを残そうぜ！」のようなアルゴリズム。
後でpsy-rd/trellisで同じような要望が満たされたのだが、主にアニメなどで
「少々レートは多く使ってもいいから、グレインもラインも綺麗に残してくれ」
という望みに対してfgoの方の動作が気に入られてるみたい。

オイラも詳しくは分からないので、知りたい人には
　ttp://x264dev.multimedia.cx/archives/25
がおすすめって感じかな。tobinaka氏も説明辺りを翻訳してた気がするけど。

>>287細部消える事を知らなかった事から論点ずらし必死だな禿ｗ
恥ずかしい奴

今日は粘着多いな。細部が消えない＝粘着荒らしが消ない。あまり良い事とは思えないが。

>>287
安直なグレインディテール消しと生ｔｓ残ししか考えられないとかどんだけとさか頭なんだよ
にわかはしたり顔で書き込まずに隅っこで小さくなってろ屑

もう単なる揚げ足取りになってる気がする。
グレイン低減したければフィルタでやろうがx264の設定でやろうが好きな方法でやればいい。
グレイン残すのも同じでエンコする当人の自由。

言葉遊び・揚げ足とり・赤ID虐め・スレチで盛り上がり
いつになったら正常に戻るんだか

フィルターにはそれぞれ一長一短があるのに長所しか把握せずドヤ顔で語る知ったか野郎は百害あって一利なし
叩かれて当然やな

せやな

（」・ω・）」うー！（／・ω・）／にゃー！（×3）　＼(・∀・)／レッツにゃー！

グレインノイズを減らしたつもりが微妙な線まで消えてた時の敗北感

そもそも何故にグレインを減らしたいの？
サイズの問題？

NL-means + スムージング

r2200

グレイン残していいのかはソースによるな
未来少年コナンのようなもんは全部消してツルツルにした方が綺麗

そもそも２６４は設定項目が多すぎるんだよ
しかも相互に影響し合ってアホみたい
設定項目を３つに押さえて、あとは全自動でできるコーデックを作るべきなんだよ
２６４なんてごみ

コーデックなんて入ってれば別に設定しなくても再生してくれるだろ。

なんでこのスレにいるの？

>>309
プリセット使ってろ

x264.exe -o test.mp4 test.avs

今思えばwmvとかdivxとか設定する所皆無だったかのように思える
もうあれには戻れないわ

>>309
オプションやパラメータを理解できないバカなら
どこもいじらないでデフォで使えばいいじゃん

つーか、そんなアホがここに来ても時間の無駄

オプションの少ないこれは彼なんかに打って付けだが、
有効期間はまだなのに、リンクが無効になっているのが残念。

http://labs.divx.com/node/11681

無駄にx264のバージョンアップなんか続けてないで
開発者は次世代コーデックの開発に移ったほうがいいんじゃないか

H.265だっけ？
規格もう決まったんだっけ？

H.265は貧弱なH.264より暗部に強くしてくれ

>>318
そう思うならキミが先導して開発を引き継げばいい。
どうせ誰もついてこないと思うが。

>>321
開発者か？
ならコテ付けろ

>>322

>>322
（」・ωΣC=（−"−）そのうーにゃー言うのをやめなさい！

x264のGOPがデフォルトで250なのはPALのせいですか？

>>315
すげーなお前！x264のオプションをずべて理解できているのか？
8**の頃から追いかけており俺だけど、使わないもしくは弄らないオプションの事はあまり理解できてないぞ？
釣りに条件反射で食いつけば馬鹿丸出しになるのは自分だってことに気が付きなよ

す
8
釣

なるほど、スパッツ最高と。

お前ら早く新revの話しろ

nlまだ2184なんですけど

目に見えて画質向上する事のない新revとかもう飽きた

圧縮率向上といってくれ

目に見える画質向上って意味解らんな
画質、圧縮率、処理速度の三つ巴だし、そもそも画質なんて人間の目をいかに上手く騙すか

まあ更新なんてr数上げたいだけの開発者のオナニーだからな
それで構ってもらいたいとかおこがましい

何を言ってるんだお前は

>>330
昔のでエンコして比較すると昔の方がましって事があるからなｗ

今のところZETMANが一番面白いかな

ZETMAN当たりだな
まったく注目してなかったアポロンもダークホース的に面白かった

（」・ω・）」うー！（／・ω・）／にゃー！

ZETMANって何で左手にコンドーム付けてるの？

>>335
俺の場合大きく変わる所使っちゃうと大体はもう戻れない
今2164で止まってるけど

ZETMANは切った。なんか作画がキモち悪い。
usatoraぐらいシャープな作画ならよかったのに

アニメスレでやれ

俺は音楽好きなのでアポロンが好き
さんかれあも捨てがたいが

x264 rev2192+664 tMod (x264_64_tMod-10bit-all)
avs4x264mod v0.6.4

で24p(CFR)の動画をエンコするとVFRになってしまうんですけど…

ソースもどうやってエンコしたんかもわからんのにそれだけ言われても知らんがな

MediaInfoでその動画を調べると、
モード:VFRモード
フレームレート:23.976 fps
最小:7.992 fps
最大:71.928 fps
と表示されます。

>>343
あの耳みたいなふざけた髪形が許せない。なんなのあれ

>>346
だからさあ…

まともに質問もできないのか

質問をするのにも、それに対する回答を理解するのにも最低限の知識は必要だからな
それを下回る馬鹿はどうにもならない

>>344
ためしに24000/1001fpsの動画エンコしてみたら普通にフレームレート23.976fpsのファイルができたっすよ

ああ、でも俺が使ってるのはavs2pipemod、
もちろんx264CLIはx264 rev2192+664 tMod (x264_64_tMod-10bit-all)だけどavs4x264modじゃないから比較にならないか

--timecodeと--timebaseに邪魔なパラメータが残ってるとかじゃねーのか？
それともx264.exe以外のexeがそれに対応する付加価値を自動で施しているとか

MediaInfo以外で調べるとどうなのさ

（」・ω・）」うー！（／・ω・）／にゃー！

（」・ωΣC=（−"−）そのうーにゃー言うのをやめなさい！

(」・ω・)」うー！(／・ω・)／にゃー！←業者の作ったAA貼るのは楽しいか？
http://engawa.2ch.net/test/read.cgi/poverty/1334419188/

　　　ｽﾊﾟﾊﾟﾊﾟｰﾝ
　　　　∩☆))ω´） >>355
（´・ω・）))☆))ω´） >>356
　ｽ⊂彡☆))ω´） >>357

>>ID:xN3ZBt6b
その時の設定、晒してもらえないでしょうか?

やだ

普通は設定なんてほいほいと晒したりしないわな。なんのメリットもないんだから。

>>359
まず自分でログを晒してツッコミ入れてもらったらどうだろう

avs4x264mod v0.6.4になってたのか

>>361
自己顕示欲が満たされる奴もいるだろう
大抵そういう奴はおかしな設定してて叩きのめされてるのしか見たことないが

個人的にはrev2192なんてどこで拾ってきたんだとそっちの方が気になる

>>359
普通に23.976fpsのアニメをエンコしてmp4にしただけっすよ

avs2pipemod.exe -rawvideo "avsファイル" | x264_64_tMod-10bit-all.exe - --crf 20 --demuxer raw --input-depth 8 --input-res 1920x1080 --fps 24000/1001 -o "264ファイル"
MP4Box.exe -brand mp42 -add "264ファイル" -new "mp4ファイル"

>>359はまず自分の設定晒せよ
質問もまともにできないとかアホかと

>>344の組み合わせで最低限のオプションで試してみたけど何も問題なくCFRになるな。
同じソースで>>346みたいなのも簡単に作れるが、まともな説明をしない阿呆に説明する義理はないし終了でいいな。

あと、avs4x264modを使ってもそうだけど、使わずにx264 rev2192+664 tMod (x264_64_tMod-10bit-all) だけで
エンコしてみても、>>194-197にあるように、進捗ログが複数行にわたってずらずらと表示された。バグなのかね、これ。

マジレスしておこうか。

アホにどんな説明をしても
アホな奴は絶対に理解できないから説明するだけ無駄。

パイプツールはavs2pipemod、x264バイナリはx264_64_tMod-10bit-allでエンコしてみたけど
進捗ログが複数行にわたってずらずらなんてことは起こらないな。
発生条件とかはっきりしないんだろうか。

プロンプトのバッファとか？

>>344の原因分かった。
--dts-compressが原因だった。
それをはずしたらCFRモードになった。

--dts-compressなんていらんやろ

パラメータの要る要らないは各自の自由。

x264_rev2192+664_tModで試してみた


x264 [option] -o "outputFile" "inputFile"
32bitバイナリ（x264_32_tMod-10bit-all）で上記のようにエンコすると>197の画像のようにずらずら出てきてしまう

avs2pipemod -rawvideo "inputFile" | x264 - [option] --demuxer raw --input-res 1280x720 -o "outputFile"
avs2pipemodで上記のように64bitバイナリ（x264_64_tMod-10bit-all）に渡してエンコするとそういう現象は起きない、普通にエンコできる


一応試してみた結果だけ

でも>197の画像だとavs2pipemodでエンコしてるんだよなぁ・・・
うちで使ってるのは最新（のはず）のavs2pipemod-0.4.1.7

664_tModって何？
ぐぐったら怪しげな中国語ばかりでてくるんだけど

avs2pipemodの-rawvideoと-x264rawの違いって何?

>>377
よく分からないけど、06_taro氏ビルドのx264のことらしい。
ちなみに06_taro氏は、avs4x264modの作者でもある。

avs4x264modのバグ報告はこちらまで
報告したいけど、どういう文を書けばいいか…
ttps://astrataro.wordpress.com/2012/04/11/avs4x264mod-v0-6-4-fix-my-stupid-fix/

別にavs4x264modのbugじゃないんだが…

>>2にある以下の板は過疎ってるので、少し板違いなことを承知の上で書き込みます
すみません
ttp://toro.2ch.net/test/read.cgi/avi/1087545021/

x264_l-smashでmuxするmp4の音声は.m4a
mp4boxでmuxするmp4の.aac

l-smashでmuxしたものはmp4の規格に沿ったものとかいう書き込みを見かけました
動画部分はmp4boxでもbrand mp42を使えば同じものが出来ますが
音声部分がm4aとaacでそれぞれオーディオコーデックが異なっているのはなぜなんでしょうか？
l-smashのmuxerでaacからm4aに変換すると、元ソースのaacとはファイルサイズも異なっており
言い方が少しよくありませんが、劣化させてまで規格に合わせたmuxしているってことなんでしょうか？

>>380
m4aはmp4と同じでコンテナだからaacとは意味が全く違う。
映像に置き換えるとaacがh264でm4aがmp4ってこと。

あ、h264のhはいらなかったなｗ

サイズが変わるのはraw ADTSなAACをMP4コンテナに格納するから

というか"x264_l-smashでmuxする"って書いてるのに"l-smashのmuxerでaacからm4aに変換すると"って書いてるけど
結局何でmuxしてんだよ
x264_L-SMASHでmuxするならわざわざm4aに格納し直す必要ないしmuxer.exeでmuxするにしてもx264でraw H.264(*.264)出力してraw ADTS AACとmux
すればいいだけでわざわざm4aにする必要ないし書いてること意味わからん

>>378
＞avs2pipemodの-rawvideoと-x264rawの違いって何?

コマンドラインヘルプ読め。あと作者のブログのavspipemod関連の記事全部読め。そしてちゃんと試してみろ。

何も調べず、まともに試さず、意味もわからず、まともな情報も出さずに書き込みして情報だけ得ようとするあたり、
ID:tKl4zwuo はAvisynth初心者スレで暴れてた奴と同じ匂いがするな・・・。

>>380
L-SMASH込みでビルドしたx264でmp4出力するなら、わざわざ別のmuxer使う必要ないよ
optionに--acodec copy --audiofile "*.aac" lsmash付ければ済む
別のmuxer使うならL-SMASH版x264使う意味がない

以下の条件でavs2pipemod-0.4.1も試してみたけど、やっぱり>>197のように進捗ログがずらずら出た。
x264での直接エンコやavs4x264modに比べると出にくい感じ。
x264-tModに原因があるのは間違いないだろうけど、>>197の言うとおり、ある程度速度が出た場合のみ発生するのかな。

ソース：
　　BlankClip(300,320,240,pixel_type="YV12")

使用ツール：
　　avspipemod 0.4.1
　　avs4x264mod 0.6.4
　　x264_32_tMod-10bit-all.exe
　　Avisynth 2.6 Alpha3

x264オプション：入出力ファイルの指定程度。avs2pipemodの場合も指定最低限。

1．mp4boxでmp4+aacをmux
2．L-SMASHのmuxer.exeでaacをm4aに変換後、L-SMASHのmuxer.exeでmp4+m4aをmux
3．x264_L-SMASHで--acodec copyを付けてmp4+aacをmux

上記のようにmuxした3パターンのmp4ファイルをmediainfoで確認すると
オーディオコーデック IDはそれぞれ以下のようになっています
1．67
2．40
3．40

つまりx264_L-SMASHで使用したaacは自動的にm4aに置き換えられた後muxしているのか？
と思い質問しました

>>387
だからm4aってのはコーデックじゃなくてMP4コンテナのことだ
あと2の"L-SMASHのmuxer.exeでmp4+m4aをmux" ←こんなことできません

どこで読んだか忘れて見つけられないが、L-SMASHではMPEG-2 AACはMPEG-4 AACにして格納されるってみたような記憶がある

ごめん進捗ログの件、>>196を見逃してた。
コマンドプロンプトの幅が80だったのを90に増やしたらズラズラ出ることはなくなった。

>>387
久々にx264でmp4出力してみたけど、1の場合でもAudioのCodec IDは40になるけどな
AACエンコーダはクイックタイム
既にスレチな話になってるけどちょっと気になった

>>391
クイックタイムやらneroやらで出力するAACってコンテナ格納状態だからな。
これらで出力したやつはL-SMASHのmuxerだとエラーが出る。
>>387の1の場合ってのはfawを使った生AACなんじゃない？

muxerは日本語文字を文字化けせずに扱えるmkvにしておけ。
mp4だとタグやチャプタなどで日本語文字を使うとプレイヤーで文字化けする。

UTF-8使えよ

>>307でrev2200報告あるけどそこまでのchangelogはどこかで見られるの?それともx264.nlに登録されるrevが出てから更新?

テンプレ読め

>>396
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
かhttp://x264dev.multimedia.cx/ (開発者のブログ)
だと思ったのですが上は現在公開されているrevまでの情報しかありません下は2011年で更新が止まっているように見えます｡
そういうのは無いという事ですか?

嘘を嘘と以下略

multimedia.cxドメインはDDNS鯖用だよな。

Another縮みすぎワロタ、なんか設定間違えたかと思ったわ

動く部分少ないし全体的に暗いからね
俺は135MBだった

呪いフィルタでクラスメイトが間引きされてるからな

12話で700MBに収めたｗ

そんな自慢いらないから

とても自慢には聞こえないけど

CD-Rにでも焼くのか･･･今時なんのメリットが

そのサイズなら3TBHDDに51428話も入るな。日数にすると857日

どうでもいい計算乙

もう4TBHDDでBDDLを常用してるから、アニメなら1ファイルあたり1GB位ないと
いろいろと使いきれん、CDなんて感覚的にはFDと大差ないような錯覚すら覚える。

そなた生tsでは不満と申すか！

おお…(略

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

また変な事言う人来たわ

本文コピペして先生に突っ込んでみようか

近頃大きな改変が続いたせいか本当に次のリビジョンが来ないから欲求不満なんだなぁ

俺はcore 119gで更新しなくなったわ
なんかもういろいろ面倒だし

D_S氏はxvp8の方をやってるからな

　 ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　 　 　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　 　/.:oヽヽ: :|: | :|
　　　 　{　{o:::::::}　　 　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　 　ヾ:::ｿ /|: : |
　！？ ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　 ＞
::∧: : :|: |J　　 ＼　　 ／　　 ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　 ヽ: |::|＼　　　 ￣/ /|　　|: : :|: |

Real timeエンコ用のプリセットきぼんぬ

--preset veryfast --tune zerolatency

やっときたな
r2204だってよ

スレチになるかと思うが
720/24p [email protected]のmp4がPS3で再生できた。
--vbv-maxrateと--vbv-bufsizeの値は共に300,000、--nal-hrd vbrでの結果。

>>421追加
1080p(24p)の動画はダメだった。

PS3のデコードってハードウェアデコードなの？
Cell使ったソフトウェアデコードじゃないの？

やっときたか｡チェンジログ解読はよ！

ってまだ情報も無いじゃないですか…

ってr2245まで来てるのか3レスもｺﾞﾒﾝﾅｻｲ
ttp://www.videolan.org/developers/x264.html

いったいどこをどう見ているのだろう・・・

暗部のざわつき改善がない限り更新なんてどうでもいい

>>421
それ「0」１個多くねぇか？
それだと30Mbpsじゃなく300Mbpsになると思うんだが

>>429
[email protected]の最高値がそれ
こんなに大きく指定しても、720pまでならPS3で再生可能
1080pは無理でした。

High5だとインタレ保持できねえじゃん

>>431
それはそうだけど

>>426
ソースからビルドしているレベルの人はちゃんと追っかけているから、このスレで一々報告は不要
どっかのバイナリが更新されたら言って

　ｄ

久しぶりにPS３で再生してみたらmp4catで結合した部分にノイズ出るようになってるな。
これがPS3の問題なのかmp4catに問題あるのか解らんわ。
PCやiPadなどではまったく問題ないからPS3側の問題かなぁ？

気になって色々と再生環境変えてみたけど、どうやらPS3が最初のキーフレームを
拾えなくなってるっぽい。 どのファイル再生してみても２つめのキーフレームまでは
画面真っ暗なままスタートする。
だからmp4catでつなげた部分も上手く再生できないっぽい。　これは困った。

別のソフト使えばいいだけじゃね

記憶が曖昧なんで信頼性は低いけど
edtsに非対応だからって話だった気がする。

edtsねえと駄目じゃんとか初期から言ってる人ちょっとだけいたけど
みんなガン無視だったなあ

ガン無視だったのはPS3()だからじゃ

x264の設定を晒しているサイトを見ると、--vbv-maxrateと--vbv-bufsizeを指定する意義とは何なの?
PC以外では見ないという場合は、指定しなくてもいいのではないかと思うんだが…

そう思うならお前はそうすれば良い

そのサイトで聞けばいいだろ。

>>441
それで合ってる
PCで再生するならそれらは指定する意味はないだろう

もともとストリーミングで回線しょぼいサイト用のオプションですし

その昔、インタレの再生支援使う為に付け始めて今もそのままなんだが
今は要らんの？

BD規格用途とかもあるでよ

>>441
それを使う意味はビットレの制限だろ。
実写でcrf18とかにしているとぐんぐんビットレを消耗していくので
そのパラメータを調整することである程度まで制限できる
だいたいDVDのビットレぐらいは確保しておいた方がいいけどな

>>438
あー…なんかそんな話あったね。
未だに非対応なままなのか…。


気になって調べてみたら今ネット上に残ってるmp4catって
edts対応前のやつしかないんだな。
対応済みのやつが手元にあるけど必要な人いたりする？

>>449
あるなら欲しいです。

あげていただきたいです

>>450,451

ほい、アップしてきた。

http://www15.atpages.jp/tellus1019/mp4cat_20100307.rar

AviUtl実験室にあるmp4catは相当古いバージョンのだから、
使う場合は上のmp4catを推奨する。
Seraphy氏に頼んでレベル情報が食い違っていても(3.1と3.2みたいに）
レベル高い方の情報に合わせて書きだしてくれるようにしてもらってある。

Seraphy氏、長く愛用してます。　ありがとうございます。

>>452
mp4catはGPLライセンスで配布されているので、ソースコードも下さい。
rarの中にライセンス関係のドキュメントが入っていないのもおかしいです。

Seraphy産はそういうの完全無視してるんじゃなかったっけ？
いっときモメてた気がする。

>>452
俺もソース欲しい

少なくとも自分の手元にあるmp4cat_20100306にはgpl.txtとLicense.txtが同梱されてるけどな。

俺の持ってる奴にも同梱されてるな
どこで拾ってきたのやら

ソースコード1万円で売ってあげるよ

>>452
乙

風呂入ってて思い出したけど
掲示板のやり取りでカスタマイズしてもらったやつじゃないかな。
結構フレンドリーに対応してたし

それはひょっとして左のタマを洗ってる時に思い出したんじゃないかな

>>460
>>452のexe自体は、普通に配布してたmp4cat_20100306と同じものだよ

>>462
ソース

確かにmp4cat_20100306とハッシュも一致するね。

よく理解していない可能性もあるからはっきり言っておくと、
ソースコードの提供ができないのに再配布するのは明らかにライセンス違反。

親切心のつもりなんだろうけど、ソースコードが提供できないのであれば、早く配布をやめないとまずいと思うよ。
特に今回の場合は色々と影響が出かねないということを忠告しておきます。

ソースが欲しい人はseraphyアットマークseraphy.fam.cxにメールすればいいじゃん

GPL厨は氏ねばいいのに

どっちかっつうと本人を気遣ってあげてるんだが・・・。今の状態はもろにバカ発見器にかかってるわけで・・・。

もういい黙れ

>>462
ソース

>>467
同じの持ってるならソース置いてあげればいいじゃん
ライセンス違反を指摘する事は必要だけど、実害の無いようなことで
必要以上に紛糾させたり嫌味言ったりする事に執心するぐらいなら、
さっさとソース公開出来る人間がソース公開した方が円満解決だろGPL思想的に

セラフィーが音信不通だし
この状況でいちゃもんつけるのはただの揚げ足取りにしかみえん

>>470
残念だが俺もソースコードは持ってない。手元にあるのは100306の配布バイナリだけだ。持ってたら上げてるよ。
嫌味ではなく上げた人を心配してるというのは上に書いたとおりなんだがな。

>>472
きちんとGPLとして配布されたなら著作者から入手した時点でソース添付されてない場合、再配布にソースが無くても基本的に問題ないよ
詳しい事はGPL見直してみ

普通にmp4box -catでいいんじゃないかと思うんだが駄目なのかね？

それ音ズレする

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

もうmkvmerge使えよ。色々捗るぞ。

H264+AACしか入っていないmkvだけでも家電やPS3などの各種プレーヤが対応すれば
MP4とかあっという間に滅ぶんだがな。

それはどうだろうか

一般人にとってdivx+mp3などに対応しなければmp4とかわらんやんoggやflacでmixするとも思えんし

mp4catってもともとソース公開されてたっけか？

俺はエンコ元のEIT情報をテキスト化してMKVコンテナの添付領域に保存している
TSに含まれる番組詳細とか消し去るのもったいないしな

ほんとテレビ好きなんだね。古い人間

（ﾄﾞﾔｯ

r2197

>>473
再配布物にソースを含める必要はないけど、要求されたらソースコードを出す義務はあるだろ。
それができないなら配布はアウト。
本来含まれているライセンスドキュメントをわざわざ削除して配布している点も悪質。

いい加減スレ違い

スレ違い、宇宙

Add Level 5.2 support
目新しいのはコレ位か

>>483
テレビ嫌いならTSのエンコなんてしないってか？

Fix disabling of mbtree when using 2pass encoding and zones

これって、「2passやzonesの時はmbtree強制OFFにしてたわ。テヘッ」ってこと？

>>486
ソースコードを出す義務があるのは著作者（セラフィ）

Fix disabling of mbtree when using 2pass encoding and zones
正常にしたよ　使ってない　〜を　mbtree　時　使っている　2pass　エンコード中　そして　zones

>>491

少し違う

正しくは
「2passやzonesの時はmbtree強制OFFにしてたわ。てへぺろ☆(・ω<) 」

x264-develのページが404 Not Foundになっとるですたい。

http://mailman.videolan.org/listinfo/x264-devel

404 Not Found
-----------------
nginx/1.1.19

>>491
これはzonesの部分だけなのかzonesを使ったエンコはすべてmbtreeが無効になるのかどっちなんだろう

>>496
ソースを見ると常に無効にしてたみたいだね

>>497
oh...
あるがとうございます

Ivy BridgeのAVX2対応は次の更新かね
何処まで早くなるのか楽しみだ

早くなるより時間掛かっても綺麗になって欲しいな
CPUの負荷が下がるメリットで他のソフトでQSVと同時エンコしたい

早くなった分、設定詰めて綺麗に出来ると思うけど…
それに、x264以外で綺麗にエンコ出来るアプリあるか？

遅くしてCPUの負荷下げるとか折角高性能PC組んでもつまんな杉

AVX2はHaswellからです

>>503
すまんそうだった

>>495
VLCの方でもめている様子。x264とは無関係＋メーリングリスト自体は動いてる
模様。

gmaneの方では普通に読める ttp://news.gmane.org/gmane.comp.video.x264.devel

subme10&11が使い物になるのはいつのことやら

>>506
処理速度の事ならハイエンドマルチCPUで組めば今すぐにでも

10を使うくらいなら11にする

低解像度ならsubme 11 tesa安定

x264.exe のソースが 2GB を超えると、認識がおかしくなるのって既出ですか？

使ったのは x264.nl にある 32bit 8bit-depth の rev.2184 で、
64bit 環境はないのでそちらは試せません。

あ、日本語が少し変でした。
「入力として指定するソースの長さが〜」です。

10は設定として地雷
11は10よりましレベル

数十GB食わせてるがなんの問題もないぞ

インタレソースをインタレ解除せずにエンコしたい場合、ググってみると、
過去には --tff 等を明示的に指定しないとならなかったようですが、
今は、とくに指定せずとも、インタレソースだと認識すると
フィールドオーダーも自動で妥当なほうを選択しインタレ保持してくれていると思います。

で、色々な映像の５分くらいのテストファイルを作り、
--crf 等をどうするか試している間は問題なかったのですが、
いざ本番ファイルをエンコしようとするとインタレ認識がうまくいかない？
それどころか fps も 569/1001 とか変な値に。
TsSplitter かけたり Murdoc Cutter で先頭を削ったりしても状況変らず。

そもそも適当に切っただけのテストファイルは全部問題なかったのに、
本番ファイルは全部ダメって何事？
違いは長さくらいしかないはず。まさかとは思いつつ、
3GB のソースを前半のみ 1.5GB に切ったら正しく認識されるように！

……という感じなんですが。
明示的に --tff と --fps を指定すれば一応インタレ保持でエンコできるんですが、
先頭 GOP が崩れてしまいます。
ソースを正しく認識できていないのだから、ほかの部分も大丈夫なのかどうか。
使い始めて一週間くらいの初心者なので、とんでもない勘違いだったらすみません。

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

>>514
うろ覚えだが、昔は--interlacedで、現在は--tffか-bffじゃなかったっけ？

>>515
そちらにしようか悩んだのですが、万一本当だったら大問題だと思い、
詳しい方の多そうなこちらにさせていただきました。

>>516
現在は、自動認識し、インタレソースの場合、
「インタレソースだね。tff のようだからそう処理するよ。
　変えたかったら --no-inerlaced か --bff を付けてね」
みたいに出ます。

昔のバージョンは試していないのでググってみた感じですが、
--tff も --bff も付けないと強制ノンインターレースだったんでしょうか。
--interlaced は --tff と同じと書いている人もいますが、
フィールドオーダー自動認識かも？

ここだと、明示的に沢山のオプションを指定している方がほとんどだと思いますが、
時間のある方がいましたら、ちょっと試してみてくれませんか？

--tffか--bff指定してあげなきゃ
自動認識なんてあるのか？

ソフトデコードなら自動認識で上手く行くことも有るが
再生支援使ってると指定せんとだめだった記憶

つか
＞時間のある方がいましたら、ちょっと試してみてくれませんか？
って何様だよ以前に再生環境もまちまちなのに参考になるかよ

>>517
インタレソースで試してみたけど自動認識なんてしないよ
--tff、or --bffつけないと

あ、自動認識だと思った根拠は、BSJ のソースだと bff になることもあるからです。
RFF なソースはどう指定したらいいのか考えているときに気付きまして。

余談になりますが、インタレ解除しないスレでも色々お聞きしたんですけど、
RFF を状態を維持したままエンコするのは無理ということみたいですね。

そもそもx264で自動認識なんてされたら間引くときどうすんのよ

>>520
いえ、再生環境以前の問題だと思います。

オプションを付けずにインタレソースを与えると、
1440x1080i 4:3 @ 3000x/1001 fps
のあと、>>518 で書いたメッセージが出ます。

誤認識している場合は
1440x1080p 4:3 @ 589/100 fps
等です。fps は色々変ります。

>>521
2GB 未満のインタレソースで試しましたか？

>>522
そんなもん強制トップで読ませりゃ済む
長くなりそうだから初心者スレでやってくれ

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


TS初心者勉強会 23頁目
http://toro.2ch.net/test/read.cgi/avi/1326035468/

>>524
もちろん

つうかソースの読ませ方等の手順やエンコオプションも書かずに話を勧めてたらグダグダになると思うんだが。

何が聞きたいのか分かり難いわ
使用リビジョンも書いてない癖にｘ264のせいにするわ
Murdoc Cutterでブツ切りにしたソースで先頭GOP崩れるとか
初心者スレでも手に余るレベル

失礼。
>>517 で書いたメッセージが出ます。
というか、そのままコピーしたほうが早いですね。

x264 [warning]: input appears to be interlaced, enabling tff interlaced mode.
　　　　　　　　　 If you want otherwise, use --no-interlaced or --bff

>>529
うん、だからtff指定するのが適切なように見えるってちゃんと教えてくれてんじゃん
だから--tffつけてエンコすればいいんだよ
もし違ったら--no-interlaced or --bffつける方法もあるよって

>>529
つgoogle翻訳

そういえば去年まで学校英語って文法軽視で教えてたんだっけか・・・。

色気違いがいなくなったかと思えば今度はインタレ気違いか

>>527
本当に単純に
x264 in.ts -o out.mp4
だけです。

>>528
使用リビジョンは >>510 で書きました。

画像崩れに関しては、迂闊でした。
Murdoc Cutter で切ったソースでも、
問題ない場合には MPC-HC での再生でノイズが見えなかったのが、
突然出るようになったもので。
このへんは初心者丸出しで本当に申し訳ありません。

>>530
でも、
enabling tff interlaced mode.
っていうのは -tff を自動で付けたってことですよね？
ならば、何も付けずに任せても勝手にやってくれるので
普通は問題ないということだと思うのですが。

自動にはならないってばさ

>>533
その部分だけ切り取るんじゃなくてちゃんと一文として見てみ

ゆとり教育開始当初ｘ264スレで英文法教える事になると誰が予想しただろうか

>>529
これに関してはID:ZbnvEXLPの解釈で正しいだろ。
「このメッセージが出てるんであれば」--iffが自動的に指定されている
（英文もそう言っている）
MediaInfoあたりで見れば、ちゃんとMBAFFになっていて
interlaced=iffがついてるのも分かるはずだ

適当なインタレ素材を(Avisynth等を使わずに）直接読ませればこのメッセージが
拝めるはず
みなAVSから読ませてるから、--iffや--bffは必須だと思ってるんだろ
AVSの場合はAssumeFieldBasedあたりを使うかなにかしないと、インタレ素材と
判断しないみたいだな

iffじゃないtffだ、しかも三回も間違ってるし……
誰かつっこんでよぅ

みんな優しさにあふれているからな。直しに帰ってくるのを待ってたのさ

ツッコミいれる以前に文字数多過ぎて読む気が失せる。
しかも書いてる内容はhelp読めばわかるだろ的などーでもいい話だし

>>538
どんまい
結論としてはMurdoc Cutterでブツ切りにして
MPEGとしてはぶっ壊れた動画データを直接読ませたのが原因で
そんな物想定されてないからって事でおｋ？
どっちにしろ何かしらフロントエンド使った方が色々楽だから面倒臭がらず導入しんさい。
無いとは思うがMurdoc CutterでCMカット等して元TS消したならカット部分ごとの音ズレ補正頑張れ…。

試しに8GBのTSを直読みさせてみたけど30000/1001 fps (vfr)に成ったと一応報告

ffmsで2GB越えてると自動では無理って話だろ？

TSを直接扱うと色々大変なんだな
Windows環境、Avisynthで264ストリームの出力しかしないからそういうこと考えたこともなかった

ffms入力で12GBのts直接入力したけど問題なく30000/1001 fpsとして認識したぞ
というかffmsにしろlavfにしろtsをそのまま扱うのがアレなのは常識というかねえ
それにもしfpsが正常に認識しなかったとしてもそれはリンクされてるlibav or ffmsの問題であってx264関係ないし

tsをavsと併用するならdgindex経由の方が動作も軽くていいだろ？
ffms経由だとプレビューさせるといきなりフリーズするから困る。

どうでもいいことだけど、avsで使ってたわけじゃなく、x264にリンクされてるffmsでtsを読み込んだという話でしょ。

>>485
r2197来てたんか

ビルドしたらワーニンだらけで怖い

そりゃカンニン

>>545
nlで配ってるx264バイナリってlibav、ffms込みでビルドされたものなんじゃないの？

>>551
そうだがそれがどうした

nlのビルドはなんでも詰め込めばいいと思ってんのかね。
exeのデータ量増えるだけでメリットなんて殆どないだろうに

>>552
ごめん、今もそうなのかとちょっと気になっただけ

>>553
(☞ﾟ∀ﾟ)☞　ＹＯＵ　ＭＡＤ？

昨夜は、レスが沢山付いてテンパり、ぐだぐだになってしまい申し訳ありませんでした。

この fps やインタレ状態の自動判定は、
x264.exe をコマンドラインで使った場合のみ行われるということですね。
判定を見て自動的にオプションを付けたことにする処理自体は、
>>529 のメッセージで頭に x264 とあるので、x264 側でやってるのかな？

フロントエンドを使った場合でも、
最終的には x264.exe にコマンドラインで渡されると勘違いしており、
誤判定されていると明示的にオプションを付けてもエンコ状態に悪影響があったもので、
ほかの方も知らない間におかしくなっているかもと、でしゃばったことをしてしまいました。
やはり初心者スレにするべきでしたね。本当にすみませんでした。

なお、もうどうでもいいことっぽいですが、「2GB を超えると」というのは間違いでした。
1GB 未満でも誤認識されるファイルもあり、さっぱりわかりません。

>>541
フロントエンドは考えたのですが、デュアルステレオや字幕を残したいと思っており、
それをなるべく自動的に行う方法を確立するのが自分には難しそうだったので、
コマンドライン＆バッチファイルに逃げました。

音ズレについては嫌というほど目にしていたのでそのへんは大丈夫です。
元々前後カットしかする気はなく、多少のゴミも気にしないので、ラフにカットしたあと、
ts2aac で音声を抜き出し aacedit でズレを修正、
Caption2Ass_PCR で抜き出した字幕と共に
mp4box で合成というかたちで一応確立してあります。
しかし、肝心の映像エンコに不安要素が出てきてしまったので、また考え直しですね。

>>553
俺もメリット無いと思うしx264のバイナリに色々ライブラリ組み込むのはむしろ気持ち悪い・・・
もちろん必要なライブラリがある人は組み込めばいいけどさ

ていうか--fgo を有効にするとビットレの消耗が増えてfpsでねぇんだな。

エンコって電気代高いの？

エンコ中、ずっとCPUを100%使い切れたなら多少高いだろうな

ハイエンドグラボは負荷かけると下手したらそれだけで400Wとか食うけどな
それでもこたつとかハロゲンヒーターよりは電気食ってないわけだが

瞬間的なワット数よりフルロードの時間じゃね？

>>194
この人みたいなエンコをやってると相当電気代かかりそうだろ。

早くエンコが終わるからそうでもない

r2197は画質変更無しかな。

猫科カモ〜ン

画質変わらんなら2164で行くわ

差を定量的に確かめたくなるのがエンコ中毒者

ビットレート ssim psnrと気になるシーンを2、3ソース抜き出すだけ

せっかく、新しいリビジョンが来ても
そのタイミングで基地外が暴れたんじゃ興醒めだな…

>>568
2184じゃなくて2164？

はい

はいじゃないが

せっかく、新しいリビジョンが来ても
そのタイミングでスグ切れる痛い人が現れるとドン引きやな・・・

同じものをほぼ同じような条件でエンコしても
比較するとざわざわした誤差が出ますが
まったく同じ条件で複数エンコした場合は誤差は出ないのでしょうか？

SSIM値の誤差は軽微だと思うがまったく同じにはならない。多少の誤差は生じる。

vbvとマルチスレッドを併用すると再現性がなくなるんじゃなかったっけ

>>576
今まったく同じ条件で3つエンコしたけど同じファイルが出来たよ
SHA-1:40で3つのファイルの値が一致した
vbvもマルチスレッドも使用

それ偶然だろ

こんなこと嘘ついて何になるの
3つじゃあれだから10個同じ条件でエンコしても全10ファイルのSHA-1:40の値一致したよ

てか同じ条件でエンコすれば結果が同じなのは当たり前では？
もし違ったらx264のプログラムにランダム処理が含まれてることになってそれは大問題なんじゃ…

CPUの負荷やメモリの使用状況で多少並行処理のしかたが変わって
必ずしも一致しない可能性は無きにしも非ず

PSNR・SSIMの数値の違いで判断すれば簡単なのになぜそれをしない？

>>581
検証とかがあると荒らす人が常駐してるんだ、すまんね…

AFS使ったら絶対に一致しない
関係ないだろうけど念の為

>>452
落とせねぇ…何故だ…

馬鹿には無理な仕様です

マジレスすると@pagesの管理者がドメイン更新だかなんだかを忘れてだな

身元を明かしてライセンス違反のアップロード等の行為をしてる奴が同僚にいたら
忠告してやめさせるし、聞き入れないなら上司にも報告して処分も検討するが・・・。
大袈裟だとは思うが意識の低さの表れだし、ゲームだかで業務としてプログラムに関わったことがあるなら尚更。
ちょっとしたことで勤務先や周囲を巻き込んで炎上して損害を与えかねないってことがわかってるんだろうか。
杞憂ならいいけどね。

>>589
お前みたいなやつがSeraphy氏消し去ったと気付こうぜ。
誰ももうそっちの話してないのに一人で語ってて空気読めてない感が漂ってるよ。

コミュニティ潰して更地にしないと理解しないよきっと

更地にして理解してくれるなら、とっくの昔に・・・

>>589
なんでGPLを作ったかストールマンに聞いてこい

>>589
ｵｺﾄﾜﾘ━━━( ﾟωﾟ )━━━!!!!

ライセンスとかアップしたこと自体はわりとどうでもいい。せめてもうちょいうまくやらないと駄目だろっつう忠告だ。

リロードしてなかったんだろう

>>589
会社関係なくね？
お前みたいのを偽善者って言うの知ってるか？

いいぞもっとやれ

確かに空気なんか読む必要は無いよな

>>595
フォローする気がないなら黙ってろカス

ID:KzYZ6hfLみたいな思想の行き着く先は
シーシェパードと同じところだと分かってるのかな

ほんと、どうでもいい。

まあここは雑談スレだし好きに続けてくれ

x264が無くなったら次の餌を求めて彷徨うだけさ

x265はやくきてくれ! そういえばh.265の規格が正式に決定するのって今年のいつなんよ？

すまんググったら簡単に出てきた｡今年の2月時点の予定では来年の1月辺りの予定みたいですはいｻｰｾﾝ

>>593
ソースコードを見せない奴が嫌いだからだろ

規格に関することだが…
BDエンコでlevel4.1の時、vbv-bufsizeの値は何故30000?
vbv-maxrateと同じ40000じゃないの理由とは?

2197

>>609
>>485

パンツの無い桂に存在してる意味があるのか！！

パンツ履いてない桂ならあるかもね

猫科さん毎度お世話になっております
素早い対応感謝いたします

誰か>>608お願いします

>>614
BDの規格を決めた人に聞いてくれ。

http://www.blu-raydisc.com/en/members.aspx

ワロタｗ

BD用エンコならBD-Rの読み込み1倍速に合わせてmaxrateは36000以下にしたほうが良いような気がしないでもない

なにいってんだおまえ

DVDだって等速の10Mに制限されてるわけだし
あながち間違っていはいないでしょ

>等速は36Mbps=4.5MB/s。BD-ROMは1.5倍速の54Mbps=6.75MB/sが標準転送速度である。
らしいが。

http://ja.wikipedia.org/wiki/Blu-ray_Disc#.E8.BB.A2.E9.80.81.E9.80.9F.E5.BA.A6

そのページにはもう少し詳しいのも書いてあるな

読み込み速度
BD-RE/-R : 36Mbps（標準1倍速）
BD-ROM : 54Mbps（標準1.5倍速）
BD-ROM (3D) : 72Mbps（標準2倍速）
読み取り方法
BD-RE/-R : プッシュプル法
BD-ROM : 位相差検出法

確かそのうち-ROMのビデオストリームは40Mbps
3Dビデオだと最大64Mbpsだと思う
-Rだとどの位なんだろ
maxrate 30000位の方がいいのかな?

くそあちーから冬に100円で買ったUSBファン付けてみた
軸音うるせー

maxrateに関しては、元ソースをBitrate Viewerの解析結果次第で指定するけど、bufsizeの値はどうすればいいか困った

つ再生機器のファーム解析

vbv-bufsizeって、何の役割をするんだっけ?

まずはググってみてはどうか

06_taro氏の2197なんだけど、ffmpegとlibavの2つありますが、どちらを使ったほうがいいのでしょうか?

>>627
違いもちゃんと書いてくれてるんだから、それを読んで好きなほう使えばいいんじゃね。

物理ディスクに焼く時代は終わった
ネットワークストリーミングの新時代だよ

>>629
石版だろ

そうでもないぞ例えば10MBのアニメのOPを、石版とyoutube上に残すのなら
ネットワーク上の方が100年後まで保存されてる可能性が高い
youtubeが消えてもどこかの誰かが持ってるかもしれない、世界中にマニアは存在するからな
特に日本のような地震の起きる地域で10MB分の石版を完全な形で残すのは難しい
BD1枚分の動画を石版で残そうとするならその難易度は異常なレベル。

持ってる人間が減っただけで、誰かが物理ディスクに保存してることには変わりないじゃん

とりあえず2xxx年に地球が核の炎に包まれた後でも残る方式で頼む

100年保存なら4年前に開発されてるようだが。
ttp://www.itmedia.co.jp/news/articles/0804/22/news048.html

10年前のリソースすらネット上からは消えてしまったがな

10年近く前freenet上にテストで流したtestって書いたテキストをzipにしたやつまだあるわ、俺がたまに見るからなんだろうけど
何度かfreenet入れ替えたから俺のローカルHDD上とは別の、どっかの誰かが持ち続けてる。

エンコード終了と同時にavs2pipemodが強制終了することがあるんだけど…

　r､r.rヽ.　　／￣￣ヽ､
r |_,|_,|_,|　/　　ー/　￣￣~ヽ　　　　ふむふむ、なるほど　
|_,|_,|_,|_,|/　　　　 ト､.,..　　　　＼
|_,|_,|_人　(^ i　　　　 ＼＼ 　　　ヽ
|　)　　 ヽﾉ　|　　　　　　＼＼　　｜　
|　　`".｀´ 　ﾉ 　　　　/⌒ヽ ヽ　　|
　　　入＿ノ 　　　 ／　　　 | |　 /
　＼＿／　　　　.／　　　　 ヽ|／
　　 ／ 　　　　　l
　 /

だからって感じ

>>627
自信ないけど
1.utvideoのデコードは何でするか
2.celtのデコードに対応してるか
3.input-cspで、rgba64be, rgba64le, bgra64be, bgra64le, 0rgb, rgb0, 0bgr, bgr0, yuva444pをサポートしているか
の違い。

1について
ffmpeg版はlibutvideoでデコードする。libav版はlibacodec内のutvideoデコーダーでデコードする。
後者は、libavcodecがsimd化していないため前者よりも遅い。
libavcodecが正しいフレームのデコードに失敗することがある模様。libutvideoではこの問題は発生しない。

2について
ffmpeg版は対応、libav版は非対応

3について
ffmpeg版はサポートしており、libav版はサポートしていない。

結論
ffmpeg版がおすすめ

>>640
1.avisynthのAVISourceが一番いい
2.celtってスピーチとか向けの低ビットレートコーデックだが、そんなのいるの？
3.そんなソースをどこで手に入れるの？ sintelのトレーラーとか？

結論：どっちもたいして変わらん

そういえばJEEB氏aq mode 3って今はどうなの?最初期に入れて2の方がまだ良いと思ったんだけど上位互換ぐらいにはなってくれた?

言ってる奴の設定を是非晒して欲しいもんだなｗ当然x264のリビジョンも

誤爆

aq=3は別にヨブさんのものではない
BM氏のpatch

漢は黙ってnlの最新rev
patch追っかけてもどうせ見ることもないし、画質なんてどうでも・・・

前はnlのバイナリ使ってたけど、自分でビルドした方がちょっとだけエンコ速度上がったからそれ以降自ビルドで
エンコ速度には関係ないんだろうけど、nlのバイナリは余計なライブラリ詰め込んでて気持ち悪いし

自分に合った-marchとか使えば早くなるかもね

弥生ちゃんを引くなんてとんでもない

今のx264って最大何スレッドまで対応してるの？

確か255

実質無制限状態なのか
XeonE5で2-way構成したくなってきたぜ・・・

やっぱグレインノイズが入ると膨らむなあ

>>652
続きはこちらでどうぞ
ttp://anago.2ch.net/test/read.cgi/jisaku/1335769428/
ttp://anago.2ch.net/test/read.cgi/jisaku/1321723244/

http://toro.2ch.net/test/read.cgi/avi/1252765934/314

ZETMANとヨルムンガンド。この2作品のグレインノイズは異常。
ファイルサイズが縮まないので面倒だからRemoveGrainできれいにしてるわ

http://viploader.net/anime/src/vlanime073236.jpg
http://viploader.net/anime/src/vlanime073237.jpg
http://viploader.net/anime/src/vlanime073238.jpg
http://viploader.net/anime/src/vlanime073239.jpg
http://viploader.net/anime/src/vlanime073240.jpg
http://viploader.net/anime/src/vlanime073242.jpg
http://viploader.net/anime/src/vlanime073243.jpg
http://viploader.net/anime/src/vlanime073232.jpg
http://viploader.net/anime/src/vlanime073233.jpg
http://viploader.net/anime/src/vlanime073212.jpg
http://viploader.net/anime/src/vlanime073213.jpg
http://viploader.net/anime/src/vlanime073214.jpg
http://viploader.net/anime/src/vlanime073215.jpg
http://viploader.net/anime/src/vlanime073216.jpg
http://viploader.net/anime/src/vlanime073217.jpg
http://viploader.net/anime/src/vlanime073218.jpg
http://viploader.net/anime/src/vlanime073219.jpg
http://viploader.net/anime/src/vlanime073220.jpg
http://viploader.net/anime/src/vlanime073221.jpg
http://viploader.net/anime/src/vlanime073222.jpg
http://viploader.net/anime/src/vlanime073205.jpg
http://viploader.net/anime/src/vlanime073206.jpg
http://viploader.net/anime/src/vlanime073207.jpg
http://viploader.net/anime/src/vlanime073223.jpg
http://viploader.net/anime/src/vlanime073224.jpg
http://viploader.net/anime/src/vlanime073225.jpg
http://viploader.net/anime/src/vlanime073226.jpg

>>656
ZETMAN＠MXはNR無しでもめちゃめちゃ縮むけど…
あっちこっちとほとんどサイズ変わらない

スタイリッシュな新プレイヤー導入でアニオタ勢力の一掃を図らんとするニコニコ

ニコニコはもうプレミア・アカウント消したし見ないわ。
もともとあそこは色々と質が悪いからなぁ

ニコニコ始まった頃はよく見てたなぁ
サービス始まって1年くらい経つ頃から質の悪い動画増えすぎで殆ど見なくなったけど

ニコニコプレ代をpaypalで払うと勝手に定期支払い作成しやがる
で、知らずにそのままほっとくと毎月勝手に引き落とされる
ほぼ詐欺やん

2525スレでやれ

>>659-662はJEEB氏の自演 あそこの辞典みたいなのに自分の記事書いてるぐらいだしなｗ

何でもいいよ
ヨブさんいつもx264の供給あざす

>>664
JEEB氏に失礼だろ速やかに土下座しろ。

Fake Aac Wav使ってるとオーディオコーデック情報が40にならん。
ここだけ書き換えるようなツールないもんかな。

なるが

　　　　　　　-‐''''"´￣｀`ヽ､　　　 　 　 　 　 　 ＿＿＿_
　　 　 　 /　　　　 ＿　 　 　ヽ　　　　　　　 ／／´ 　 __,,＞､
　　　　 /　　　　 　 ￣￣　　 {　　　　　 　 /::/　／￣:::::::::::::::＼
　 　 　 l　_ｨﾆﾆｱ二二二ﾆヽ､j._　　　　　 /::::l／::::::::::::::::::::::::::::::::l
　　　　 | 0Lj／-‐-ﾚノ ﾉ＿ヽ:::｀ヽ　　 　 l:::::::::::／l／lノノ/_イ:::::l
　　　　 ﾚ:r､/　ｲﾟﾃ　　　ﾋﾟﾄ｀|::|　　　　　 l:::::::::/ rtﾃ､ 　.ｨtq l::::::|
　　　 　 l:lﾍ　　'"　　　,j 　'"/ﾉ　　　　　 |::lﾍ!j　　´　　,j　　 !;:::/
　　　　　ヽヽ､　　　r‐-, 　 /'　　 　 　 　 ﾚﾘｰ ､　 　 ,....,　　lﾉ/
　　　　　　　　lヽ､　￣　／　　　　　　　　　｀ヽ､lヽ ､ ￣　／´
　　　　　＿,r┴‐-｀v´-‐j-､＿＿　　　, -‐-､_r┴─'ｰ‐ﾁﾄ　　　　　　　バルス！！
　 ／￣/:.:.:.:|￣￣｀T￣´|:.:.:.:l´　｀ヽ /　　　　ヽ￣`ー-‐'´`''''⌒ヽ
／　　 ,':.:.:.:.:.l　　　　l　　 l:.:.:.l　　　　＼　　＿r‐､-､-､ｒ,　 　 ､　　 ',
　　 　 |:.:.:.:.:.:.!　　 　 !　　 !:.:.l　　　,. -‐ゝ/// 〉 〉 〉 〉 〉　　　 !　　 ',
　　　　l:.:.:.:.:.:.ｌ　　 　 |　　 l:.:.:l　 ／　　人〈〈〈〈 '　'　' /っ　　　l　 　 l
　　　　l:.:.:.:.:.:.!　　 　 !　　 l:.:.:.ﾄ/　　 /　　```´-ｧ‐'''"　　　　 /　　　l
､＿＿/:.:.:.:.:.:ｌ　　 　 |　 　 |:.:.:ヽﾍ　 l　　　　/／　　 　 　 　 /　_ ｨノ
　 　 /:.:.:.:.:.:.:!　　　　l　　　|:.:.:.:.:l `ｰヽ､＿ノ´l､＿＿＿＿__/lﾆ二」
＿___l:.:.:.:.:.:.:.|　 　 　 l　　　|:.:.:.:.:!　　　　　 　 |＿　 （ ( ) ）_〕|　　 l
　　　l`ー‐‐'匸二l￣￣l二フｰｲ　　　　　　 /　　￣ `‐‐'´　ヽ　　|

40じゃないと何か困るんだろうか

>>668
え？ まじで？
mp4box使ってるんだけど.aac読みこませるとならんよ…。

>>670
MACやiPhone、iPadなどで音が鳴らないのよ…40じゃないと…。

ts2aac.txt
4. FAW or aacedit でaacもカット (＋ 必要に応じてAACPatchとか)

>>672
そうなのか、初めて知った
mp4boxかl-smashでaacをm4aに変換してからmuxするのはどう？やったことないけど

>>672
FAWでカット後にL-SMASHのmuxer使ってm4aにしてからmp4に格納すればいい
x264_L-SMASHならダイレクトに格納できるがな

皆の優しで溢れている…。
いつもバイナリエディタで直接書き換えてたよ…。
早速試してきます。

mpg2aacをmpg4aacに変換なら
"mp4creator.exe" -aac-profile 4 "%~1" "hoge:\hoge\%~n1.m4a"

mp4boxとかゴミ使うなよ

何がお薦めなんですか？

俺はmp4boxしか使わんな
Windows環境しか使わないからかもしれないけど他の使うメリットがよくわからんし

>>677をmp4boxでやるなら
mp4box.exe -mpeg4 -add hoge.aac -new hoge.m4a

>>679
L-SMASH

>>679
L-SMASH

ID変えるのに少し時間が掛かったか？

>>684
そう思うならそう思っておけばいいけどもう少し楽に生きたらいいと思う

よくわからんけど、L-SMASHでトラック取り出したり削除したりカットや連結したり
MPEG-4 ASP扱ったりできるんだっけ

最近のビルドでは確認していないけどL-SMASHが字幕やttxtのチャプターに対応したらmp4boxから移行できる

LAVSplitterを使うならmp4box使え
L-SMASHでは正常に再生できない
詳細は総合質問スレを見てくれ

俺も字幕まわりの実装次第ではl-smashに移行するのもいいと思ってるけど今のところはパス
まあ素直にmkv使えよって話かもしれんが

L-SMASHを使うのは物好き・・・というよりものぐさな連中だけ

L-SMASHってコンテナにフォント埋め込んで字幕表示とかできる？

>>684
残念ながら別人ですw

字幕は面倒臭いとか言いつついつか対応してくれると信じて気長に待っています

オープンソースなんだから誰か暇なやつやればいいのに

字幕が使えなきゃ使い物にならん

mp4boxだけど
-add "hoge-adts.aac":mpeg4
とやってiOSデバイスできちんと再生できてるよ

mp4boxも色んなリビジョン有るからねぇ…。

気がつけばHDD内に3つ4つあって、どれがどれやら

MP4BoxはよくわからんからPOP@4bitさんとこの0.4.6 2010/10/22ってやつをずっと使ってるわ

　　　　　　　-‐''''"´￣｀`ヽ､　　　 　 　 　 　 　 ＿＿＿_
　　 　 　 /　　　　 ＿　 　 　ヽ　　　　　　　 ／／´ 　 __,,＞､
　　　　 /　　　　 　 ￣￣　　 {　　　　　 　 /::/　／￣:::::::::::::::＼
　 　 　 l　_ｨﾆﾆｱ二二二ﾆヽ､j._　　　　　 /::::l／::::::::::::::::::::::::::::::::l
　　　　 | 0Lj／-‐-ﾚノ ﾉ＿ヽ:::｀ヽ　　 　 l:::::::::::／l／lノノ/_イ:::::l
　　　　 ﾚ:r､/　ｲﾟﾃ　　　ﾋﾟﾄ｀|::|　　　　　 l:::::::::/ rtﾃ､ 　.ｨtq l::::::|
　　　 　 l:lﾍ　　'"　　　,j 　'"/ﾉ　　　　　 |::lﾍ!j　　´　　,j　　 !;:::/
　　　　　ヽヽ､　　　r‐-, 　 /'　　 　 　 　 ﾚﾘｰ ､　 　 ,....,　　lﾉ/
　　　　　　　　lヽ､　￣　／　　　　　　　　　｀ヽ､lヽ ､ ￣　／´
　　　　　＿,r┴‐-｀v´-‐j-､＿＿　　　, -‐-､_r┴─'ｰ‐ﾁﾄ　　　　　　　おお…
　 ／￣/:.:.:.:|￣￣｀T￣´|:.:.:.:l´　｀ヽ /　　　　ヽ￣`ー-‐'´`''''⌒ヽ
／　　 ,':.:.:.:.:.l　　　　l　　 l:.:.:.l　　　　＼　　＿r‐､-､-､ｒ,　 　 ､　　 ',
　　 　 |:.:.:.:.:.:.!　　 　 !　　 !:.:.l　　　,. -‐ゝ/// 〉 〉 〉 〉 〉　　　 !　　 ',
　　　　l:.:.:.:.:.:.ｌ　　 　 |　　 l:.:.:l　 ／　　人〈〈〈〈 '　'　' /っ　　　l　 　 l
　　　　l:.:.:.:.:.:.!　　 　 !　　 l:.:.:.ﾄ/　　 /　　```´-ｧ‐'''"　　　　 /　　　l
､＿＿/:.:.:.:.:.:ｌ　　 　 |　 　 |:.:.:ヽﾍ　 l　　　　/／　　 　 　 　 /　_ ｨノ
　 　 /:.:.:.:.:.:.:!　　　　l　　　|:.:.:.:.:l `ｰヽ､＿ノ´l､＿＿＿＿__/lﾆ二」
＿___l:.:.:.:.:.:.:.|　 　 　 l　　　|:.:.:.:.:!　　　　　 　 |＿　 （ ( ) ）_〕|　　 l
　　　l`ー‐‐'匸二l￣￣l二フｰｲ　　　　　　 /　　￣ `‐‐'´　ヽ　　|

>>696
サンクス　ipadでいけた
今まではmp4creatorでmpeg4aacにしてからMUXしてた

ヨブさん今回なかなかHPトップのx264が更新されないけど
TOPが2184から差し替わるまで待った方がいいのか
Index of builds に並べば持って行っていいのかどっちなんでしょ

どうしてもその人がビルドしたものがいいなら待つしかないんじゃないの
待ちきれないなら自分でビルドすればいいんだし

自分でビルドしても自分で中身を改造しなけりゃ殆ど意味がないんじゃ？

詳しいことは知らないけど、その人しか知りえないブラックボックス的なpatchか何か当ててるならその人のを待つしかないね

少し本筋とは外れますが、MP4規格的には副音声をどうやって格納するのが正しいのでしょうか？
いろいろとググったら音声をgroup=1でまとめ、副音声側にdisableを指定するのか、今現在、もっとも確実なようですが、これでいのでしょうか

初心者質問スレで質問するつｍりでしたが誤爆してしまいました。
ここでもいいですか？

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

【H.264】iPod videoの動画スレッド★8【MP4】
http://toro.2ch.net/test/read.cgi/avi/1235567895/257

何かと思ったらこれか

>>708
ありがとうございます。そちらで聞いてみます

ハードウエアとの互換性を犠牲にせずにMP4に副音声を格納するには、
音声をgroup=1でまとめ、副音声側にdisableを指定するのが一番確実でしょうか

ごめんなさい

なんだなんだ？？

小清水は

1440ｘ1080i放送の旧作の再放送アニメはさらに上下左右に余分な枠がはいるんだが
おまえらこういうのってcropして除去してる？それともオリジナルのまま残してる？

最新のにしたら予想ファイルサイズも出るようになった
地味に便利

　　　　　　　　　ナ ゝ　　　ナ ゝ　/　 　 十＿"　 　 ー;=‐　　　　　　　　　|! |!
　　　　　　　　　　cト　　　　cト　/＾､_ﾉ　 | ､.__　つ　 （.__ 　 ￣￣￣￣ 　 ・ ・
ﾐ::::;/　　￣ﾞ`ｰ-.､　　　　　u　　;,,;　　　j　　 ヾk'!　' l　/ 'ﾚ ^ヽﾍ＼　　 ,rﾞゞﾞ-"､ノ /　l!　!ヽ ､､　|
ミ/　　　　J　　　ﾞ`ｰ､　　　"　;, ;;;　,;;　ﾞ　　u ヾi　　　 ,,./　,　,､ヾヾ　　 | '-- ､..,,ヽ　 j　 !　| Nヾ|
'"　　　　　　　_,,.. -─ゝ.､　　　;, "　;;　　　_,,..._ゞｲ__／/〃 i.! ilヾゞヽ　 | ､　 .r．　ヾ-､;;ﾉ,.:-一'"i
　　j　　　　／　　 ,.- ､　 ヾヽ、　;; ;;　_,-＜　　/／_,,＼' "' !|　:l ﾞi !_,,ヽ.l　`ー─--　 ｴｨ' (． 7 /
　　　　　　:　　　　' ・丿　　￣≠Ξｲ´,-､　ヽ /ｲ´ r．　`ー-'ﾒ ,.-´､　　i　　　　 u　　ヾ｀`ー' ｲ__＿＿
　　　　　　 ＼_　　　 _,,......::　　　´ﾞi､　`¨　/　i　ヽ.__,,... '　 u ﾞl´.i･j.冫,ｲﾞl　 ／ ｀`-､..-　ノ　:u l ,− ,−＼ ／￣￣￣￣＼
　　　u　　　　　￣￣　　彡"　　　、ヾ￣｀`ﾐ::.l　　u　　　j　　i､｀ー'　.i /　/､._　　　　｀'y　　 /, |･　 |・　|　ヽ＿＿＿＿＿ヽ
　　　　　　　　　　　　　　u　　　　　　｀ヽ　　ﾞ:l　　 ,.::- ､,,　,.　ノ　ﾞ u　!　/_　　￣　ー/　u　/ 　｀−●-'　＼ヽ , ─ ､ , ─ |
　　　　　　　　　　　_,,..,,_　　　　,.ｨ､　 ／　　　|　 /__　　 ｀`- ､_　　　 l　l　 ｀`ｰt､_　/　　／ ──　 |　──ヽ|･　　 |・　　 |
　　ﾞ　　　u　　,.／´　"　 ｀`- ､_Ｊ　r'´　 u　丿　.l,...　｀ー一''/　　　ノ　 ﾄ ､,,_____　ﾞ/　／..　　──　|　──　.|`─ 'っ - ´|
　　　　　　　 ./＿_　　　　　　　　ｰ７　　　　/、　l　　 'ﾞ　ヽ/　 ,. '"　　＼｀ｰ--- ",.::く､ |　 　 ──　|　──　|._＿＿＿) /
　　　　　　　/;;;''"　￣￣ ───/　　ﾞ　 ,::'　 ＼ヾﾆ==＝'"／ ｀- ､　　　ﾞー┬ '´　/　＼.＿＿＿＿|＿＿） / ＿＿＿／
、　　　　　 .i:⌒`─-､_,....　　　　l　　　／　　　　 ｀ー┬一'　　　　　 ヽ　　　 :l　 ／　 , '　｀ソヽ　　　　　　／l ＼／＼| ＼
ヾヽ　　　　 l　　　　　 `　 ｀ヽ、 l　 .／　　ヽ　　　　　 l　　　　　　　　　）　　,; ／　　　,'　　　　'^i━（ｔ）━━l |　　　　　 |　|

あ、ごめん
L-SMASHの方だった

　　　　 　　ヽ(･ω･)/
　　　　 　＼(.＼ ノ
　　　　､ﾊ,,､　￣
　　　　￣

>>718
komisar氏のパッチっす。

taro氏だろ

patchでそういうことができるのか
ファイルサイズを予想したい時は本番のエンコオプションから--meを下げるとかしてエンコ速度上げて一通りエンコしてる
ちょっと時間はかかるけど予測結果は当たらずとも遠からずってところになるし

%出るからそれまでのエンコ済みサイズ元に大体を予想しながらしてたけど地味に便利

>>722
それなら2passで似たような事を自動でやってくれ…うわなにをｓｔｗいぇお＠

crfの決定はオークションの入札に似ている。
上げるべきか上げないべきか　予算＜容量＞次第

あれは単に現在の平均ビトレを再生秒倍してるだけで、予想とかはしてないぞ
でもって一行の文字数が80文字(端末の標準)超えるもんだから改行入っちゃって、
キャリッジリターンしても上書きが効かなくなり、>>194みたいに騒いだりする

iOS 5.1.1 will come soon

そろそろエンコシコシコしないと溜まりすぎて駄目になるう

電話番号8264のオレ歓喜

>>727
coming soonだと思うが…

えっ

おしりｽｰﾝ

subme10からsubme11にしたらサイズが1〜2%増えてしまった、なぜだ・・・・

ファイルサイズを減らすオプションじゃねーから

-ssim -psnr

フォーマット : AVC
フォーマット/情報 : Advanced Video Codec
プロファイル : [email protected]
CABAC : いいえ　←←←←←←←←←←←←←←←←←←←←←
RefFrames : 1 フレーム
Format_Settings_GOP : M=1, N=33
コーデック ID : avc1
コーデック ID/情報 : Advanced Video Coding
ながさ : 2時 58分
Source_Duration/String : 2時 58分
ビットレートモード : CBR モード
ビットレート : 1 045 Kbps
ノミナル : 1 100 Kbps
幅 : 720 ピクセル
高さ : 396 ピクセル
解像度 : 16:9
モード : CFR モード
フレームレート : 29.970 fps
標準 : NTSC
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 ビット
スキャンの種類 : プログレシッブ(PPF)
ビット/(ピクセル*フレーム) : 0.122
ストリームサイズ : 1.30 GiB (85%)
Source_StreamSize/String : 1.37 GiB (89%)


Torrentサイトで出回ってるAVが軒並みCABAC無効でエンコされてんだが
外人がただの情弱なのかアホなのか理由がわからん

割れ厨は死んどけ

>>736
ACCSに通報してやんよ。

正規品買ってねって事だよ

いや、Torrentで動画を拾っている時点でもうアウトだろ。
しかもAVってことは10割無許可複製＆違法動画だぜ。
余計な最後の2行を書かなけりゃ殆どの人は騒がなかったろうに

どうせ--tune fastdecodeだろ

携帯中華動画プレイヤーはパワー無いからな

【2013】 H.265/HEVC 【7680x4320】
126：名無しさん＠編集中[]：2012/05/15(火) 16:05:34.89 ID:CMQhxqPe
H.265が世界に普及した頃には日本の次世代地デジ（？）はH.264やなｗ
現に今MPEG2な時点からして悲劇が容易に予想されるんやなｗ

--tuneオプション自体廃止した方がいいと思うんだ
よくわからないまま適当にtune何たらでいいかって感じでとんでもエンコ量産・・・こんなオプション今となってはデメリットしかない

他人がどうエンコしようが別に関係ないだろ
そんなん気にするのは割れ厨くらいだ

--tuneはパラメ調整のベースにはちょっと便利

ないない

ただし初心者向け

ベースはデフォルトだよ
デフォルトでエンコして要件満たさないところがあるなら各オプションを調整すればいいのであって
初心者が--tune使うなんて危険極まりない

そっすか・・まあ俺も必要ないから使ってないけど

危険って、爆発でもするのかよ。
>>745だな。

--tuneを遣う用になったら彼女ができました(´・ω・｀)b

俺はお通じがよくなったわ
--tune サイコー

>>749
別に危険な事は無いが、パラメータを調整してあれこれ試す楽しみが無くなるだけ。
エンコを雑用ぐらいにしか考えてない人は--tuneとか積極的に使えば捗るんじゃないの？
エンコを趣味と保存用ぐらいに考えている人は完全フルカスタマイズでパラメータも吟味するだろう

tune+細かいパラ指定で結局tuneの設定が効いてるのはdeblockぐらいだな

tune tune train

--tune film --crf 18 --keyint 240 --b-adapt 2 --direct auto --colormatrix bt709 --colorprim bt709 --transfer bt709 --sar 1:1 --level 4.1

1080p -> 540pHigh@41のとき、これ何点ですか？ブルドッグソースは洋画BDです

俺なら540だったらbt601に変換する

SDのPALでも高さ576有る訳だし、>>758に同意

720pとは何か

えっそうなんですか！？

最終出力としては縦719ドットまでがBT.601、縦720ドット以上がBT.709

>>757
level 3.1で収まるかと

俺はｺｺで教わった通りにﾃﾞﾌｫで始めて
失敗する度に設定を教えてもらってﾊﾟﾗﾒﾀ決めたけど
最初に--tuneで始めても結果は同じだったかも？

しかしﾃﾞﾌｫ設定だったから初質にresが付きやすかった気もする
他の初心者の人がﾊﾟﾗﾒﾀ晒して--tune使ってると
先ず"--tuneﾔﾒﾚ"って言われてたし

preset否定派はたいてい経験1年未満の初心者

>>575
BT.709->BT.601変換はしてないんでしょ？
ならBT.709のままでいいよ
colorprimとかtransferは要らないと思うけど

>>575　×
>>757　○

7Mレベルかよｗ

BT.709のままだと再生環境によっては色が変わっちゃうけどな。
前提条件とか全然書いてないから知らんけど。

再生は専らiOSです。たしかにiPhoneがどちらを優先してるのか未検証です。話題のVITAはもってません。
皆さんが仰ることはつまり縦540という719以下の場合
・プレイヤーが表示する色空間を縦の長さで判断するプレイヤーだと709なのに601で誤って表示される可能性、リスクがある
・プレイヤーがAVCエレメントの宣言？を参照しているのなら構わない
いずれにせよ540の場合は色の誤表示される可能性をゼロにするには601に変換して圧縮、601宣言しとくことが正解ということでいいですか？

自分の環境で見れれば充分だろ？一体エンコした動画を誰に見せる気だよ？？

>>762が書いてる
　　＞最終出力としては縦719ドットまでがBT.601、縦720ドット以上がBT.709
というのは目安の一例にすぎないよ。
例えばffdshowの場合は
　　(width > 1024) or (height >= 600)
ならBT.709と判定してるし。
解像度もフラグも無視して全部BT.601だと解釈するものもあるし。

まあ縦540ならBT.601にしとくのが無難じゃないかね。

なぜにffdshow？
YUV>RGB変換てレンダラの仕事だと思うんだが
あ、ffdshowでRGB変換させているのかな？

>>772
うん。判定例の１つとして挙げただけね。

IRC用だったのかopencl x264まだ不安定なようだけど
anand以外ベンチないのかな

http://images.anandtech.com/graphs/graph5835/46687.png
CPUはオワコン

>>775
CPUをまったく使わないでやって見せてくれたら信じるわ

>>776
>GPU acceleration in Handbrake comes via three avenues: DXVA support for GPU accelerated video decode,
>OpenCL/GPU acceleration for video scaling and color space conversion,
>and OpenCL/GPU acceleration of the lookahead function of the x264 encoding process.

http://images.anandtech.com/reviews/cpu/amd/trinity/handbrake/trinityhandbrake.jpg


開発が進めば、--me esaに相当する物をGPUで常用できる様になるのかな。

A10にわざわざハードエンコチップも積む時点でAMDはぶれまくりであてにならん

>>778
http://images.anandtech.com/graphs/graph5831/46685.png

まあ、こうしてQSやCUDAと比較されるのだから、ASICを用意するのも仕方無いと思う。

MediaEspressoはH264だろ。x264とは別枠だしスレチだろ。

GPUパッチについての情報。
これは現時点の、自分の環境（2500K+Radeon HD 7770）での話。

大方完成していて、正常に動く。その記事ではGPUのオンオフできないと書いてあるが、x264ではできる。
品質については、実写に強くアニメに弱い。
また、720pより1080pが得意。
速度については、速いプリセットほど効果がある。遅いプリセットだとCPUの方が速い。

だからアニメを時間かかってもいいから高画質エンコするという用途には向かないと思う。

>実写に強くアニメに弱い
出力ビットレート同程度にしてssimとpsnrをx264と比べたら壊滅的な事になりそうだな

> 実写に強くアニメに弱い

使い道ねーな

エンコード速度はおいておいて画質が変わるということは
やっぱりGPGPU向けにアルゴリズムも変わっているのかな？

>>782
それをやったときの結果が、実写に強くアニメに弱い
実写で--preset veryfastなら速度とpsnrともにOpenCLが勝つこともある

>>784
うん

ちょっと信じられんな。設定とソースplz

数値もなしSSもなしだと信憑性はあれ
そのうちブログにゃのるかもしれんけど

自分でやってみれば良いんじゃないの

mp4boxでedtsに対応してる最新のものってどこにある？

mp4box関係ない

あれ？ 音声と結合するときとか対応するやつじゃないとダメだったんじゃなかったっけ？
俺の記憶違い？？？？

スレ違いって意味だろ

スレ違いではないかもしれんが
mp4boxは関係ない

パッチはDoom10にあるからOpenCL試したい人はやってみたら？
ドライバは最新使った方がいいよ、特にAMDは古いのだとバグがあるっぽいから。
まあ今の12.4もGCNだとちょっとおかしいらしくてworkaroundがあったりするけど。

>>794
このパッチってAMDがAPU用に作ったパッチだよね？
だとするとディスクリートじゃなくて内蔵GPU（2500kならHD3000だっけ）だとまた違った傾向にならないかな？

違った傾向も何もベンチは全部内蔵だよ
外部だと転送コストがーとか色々言われてたけど
大体内蔵よきゃ外付けのほうが効果高い
x264はわからんけど

handbreakでならわかるけどx264でdxvaデコードはどうなってるんだろとふと思った

> x264でdxvaデコードは

そんな機能付いてないだろ。いったい何と勘違いしてんだ？

>>777
ついてないんならやっぱhandbreak版待ちだよな
クラッシュして試せないのがもどかしい

handbrake

手を壊してどうする

>手を壊してどうする　

えっ、自転車でよくみる「ハンドブレーキ」だろ。
どこをどう読むと手を壊すことになるんだ？

>>801
>>799
> ついてないんならやっぱhandbreak版待ちだよな

>>801
>>797, >>799

お前はcoffee brakeでコーヒー壊さないのかよ。

お前ら暇ならopencl版試せよw
06_taroで検索か自作板のほうにリンクあるし

DGDecNV用のGT520しか無いし

>>802-803
ああ、そろそろ赤くなる奴の勘違いか。

>>799
クラッシュするならそれを報告しろよ

CPU: Phenom II 1090T 3.2GHz (stock)
GPU: GeForce GTX 460 765MHz
ソース: ftp://vqeg.its.bldrdoc.gov/HDTV/NTIA_source/TouchdownPass_8bit.avi (YV12にリサンプル)
x264のオプションは入出力以外無し

この条件でx264_64_tMod+MixAQ+OpenCL-8bit-420と、パッチ無しx264 r2197 (x64 8-bit, 自ビルド)を比較したけど、
OpenCL版17.9071 fpsに対して、通常版16.50 fpsと8%程、CLの方が確かに速い。

CL: 6953.08 kb/s, SSIM Mean Y:0.9356487 (11.914db)
通常: 7000.94 kb/s, SSIM Mean Y:0.9358953 (11.931db)

ビットレートの違いを考えると、SSIMは妥当か。

>>806
俺も同じだw NVよ早くGK106だせよ！！

速いプリセットほど効果があると書いたが、今やってみたらslowerでもGPUの方が速かった。
記憶違いかも。

ソース動画とどれだけ画質の差異が起きているんだよ？
SSIMが11.914dbってなんでそこまで低い数値に？

--bitrate 8000 --preset slower --tune psnr --psnr

OpenCL、1pass目と2pass目の順番
x264 [info]: PSNR Mean Y:26.611 U:31.180 V:35.840 Avg:27.879 Global:27.719 kb/s:8189.48
encoded 500 frames, 42.96 fps, 8189.48 kb/s
x264 [info]: PSNR Mean Y:28.000 U:31.179 V:36.158 Avg:29.108 Global:28.990 kb/s:8108.58
encoded 500 frames, 6.99 fps, 8109.17 kb/s

--no-opencl付加、同上
x264 [info]: PSNR Mean Y:26.560 U:31.178 V:35.845 Avg:27.833 Global:27.669 kb/s:8238.63
encoded 500 frames, 30.93 fps, 8238.63 kb/s
x264 [info]: PSNR Mean Y:28.011 U:31.190 V:36.166 Avg:29.118 Global:28.995 kb/s:8098.54
encoded 500 frames, 6.91 fps, 8099.13 kb/s

ちなみにD_S氏曰く、2pass目はlookaheadの結果は使われないから1pass目に着目しろとのことだが、
1pass目のみの比較ならビットレートは低いのにPSNRは勝ってるな。しかも速い。

あと、1080pの方が得意というのは速度面の話っぽい、ごめんなさい。
フレームサイズが小さいとCPUのキャッシュのパフォーマンスが優勢になるとか。

ということは4k2kとかでやったらもっと顕著な差がつくんだろうか？

VIDEOLAN全部かX264プロジェクトをユーロ安の今買収したいんだけどいくらぐらい必要かなぁ？
30万ユーロで足りる？

そんな買収になんのメリットがあるんだ？

http://vr-zone.com/articles/from-gtc-2012-amd-r7970-preferred-over-nvidia-kepler-in-real-gpgpu-deployments-/15903.html
これ見るとgeforceダメじゃね？今世代で退化してしまったし

だからAMDが気合い入れてパッチ書いたんじゃない？

Kepler世代のGPGPUはGK110に任せてGK104(＝GTX680)はグラフィックに特化したってことじゃない？
GK110はモンスターチップみたいだし(500mm2くらい)
ベンチはまだ出てないからなんとも言えないけどね

ハリポタ7-1 [email protected] 1920x802/24p　[10434f-11654f]

[SF23]--preset superfast --tune film --crf 23 --keyint 240
x264 [info]: SSIM Mean Y:0.9771213 (16.406db)
encoded 1221 frames, 50.85 fps, 2677.27 kb/s

[M18]--preset medium --tune film --crf 18 --keyint 240
x264 [info]: SSIM Mean Y:0.9790207 (16.782db)
encoded 1221 frames, 13.78 fps, 5047.93 kb/s

プリセットの中じゃ一番VeryFastが圧縮時間対圧縮率がいい！？

実写はいつもveryfastとfilmでやってる
映画の尺の半分程度の時間でエンコードできてる
ちなみにエンコードした映画はまだ一度も実際に視聴したことがない

次の方どうぞ

> ちなみにエンコードした映画はまだ一度も実際に視聴したことがない

この人、アホですね。視聴しないなら消せばいいのに

世間では割りに普通の事だぞ
だいたい、エンコが無事に終わったのならそれで十分だろ
視聴する理由がない

じゃあエンコする必要もねえだろ
エンコするだけして見ないとか電気代の無駄だ

いや、だからなんでエンコしてまで残そうと思うんだ？
しかもエンコしても視聴さえもしないなんてｗ
そういうレスを見るとどこぞの違法動画配信者みたいなオーラが漂ってくる。
自分は視聴しないがエンコだけは誰よりも先に済ませておくみたいな。

キレイにエンコできたらそれで満足だろ？
それ以上の理由なんて無いよ

エンコしない方が綺麗ですが

誰にも迷惑かけなければ趣味は何しようが勝手

でもまぁわざわざ書き込む必要はないわな
誰かに知って欲しいのだろうけど

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

http://toro.2ch.net/test/read.cgi/avi/1329221725/
こちらへどうぞ

そして単発ID

俺は放送時にリアルで見て録画もしてエンコもしてるけど
エンコした分を見直すのは10回に1回もないなぁ。
友人からは電気代の無駄と言われるｗ

IntelでもAMDでも良いけどx264からHWエンコ出来るようにしてくれ
遅くて敵わん

えっ

ｘ264からHWエンコ？

ｘ264スレにまでν速民が来始めたか…。

>>826-827
服買ってもほとんど着ずに増えるだけな人とかいっぱいいるだろ？
あれと同じで録画するだけとかエンコ後放置とかもごく普通に(かなりの人数)居るってだけの話だ
ゲームで不毛に消費するとか食べ歩きで外食三昧とかと同じで単なる趣味だな

そんなのと一緒にされたら何万もかけて環境を構築している録画廃人達が暴動を起こしかねないぞ。

？

x264ってAVX命令使ってる？

使ってる
あんまり効果は無いけど

>>842
AVXはWin7以降限定だけどな

当然WIN7です
オプションとかしないでも勝手に使ってくれるのかな？

勝手に使う
逆に使いたくないなら--asm

おおx264賢い
あざす

>>840
録画廃人は大抵貯めるかエンコまでだぞ。

AVX使うといってもほぼ128bitの3オペランドだけだろ

x264のopenclってradeon専用なん？
radeonとgforceどっち買うか迷ってるんだけど

迷ってるのならgforceにしておけ。CUDAも使い道豊富だが
High10より上の動画再生時に使うLAV Filterとかでも役立つしさ
ただし電気馬鹿喰いなのもあるからそこは注意な。

再生支援とかいらねえｗ
cuda欲しいのってフォトショ使う人ぐらいなんじゃないの

この板的にはTMPGEncやDGDecNV使いでしょ

TMPGEncこそイラネ。ロゴ抜きひとつできないゴミツールだろう。

そんなこと言ったらx264だってできないだろｗ

High10より上って言われても16bitの動画とか再生しないしなあ
LAV Filterとかは好みの問題な気がする

>>855
x264はAVSと組み合わせればロゴ抜きできるよ。
delogo.dllでぐぐれ

>>855
TMPGEncのH.264エンコは、x264を利用しているんだし、同列に並べても
http://www.videolan.org/developers/x264.html

>>857
TMPGEncもavs食えるよ
だからその突っ込みはおかしい

>>858
それは>>854へどうぞ

わざわざTMPG使う意味がない有料ベンチソフトだろあれ?

>>859
なんかもう必死だね。ぶっちゃけると有料のツールなんて不要と言いたいわけだが。
x264対応のTMPGEncは有料版しかないんだし、無料版はH264だろうから
どうしてもTMPGEncを勧めたいのならスレチなので↓でやってくれ。
http://toro.2ch.net/test/read.cgi/avi/1319451871/

>>861
お前の「CUDAも使い道豊富」のフォローしてやったんだろｗ
ヘンなやつだな

何がだよ。そもそも>>851は>>850に対して書いたわけだが？
TMPGでCUDAが使えるからフォローしてやったとか言われても余計なお世話だ
相手が望んでないフォローほどウザったいものはないだろ？

>>850
迷ってるならGeforceでいいんじゃねーの
cuda関連のアプリがx264エンコで役に立つかもしれないし

GCNなrade7xxx系買っとくのが無難
メモリアドレス共有化でopencl系強いし>>817

TMPGEncは5を使っても、WOW64動作の32bitだし内臓のx264も32bitだから、64bitのx264をAviSynth64などで使う方が結局は速い
AviUtlだとx264outやExで64bitが使えるから、TMPGEncは使いにくいTMPG MPEG Editorはカットに便利だけどなwww

http://anago.2ch.net/test/read.cgi/jisaku/1321723244/
x264Mod-openclは、GeForce GTX570やGT520は成績が落ちてそうHD7970は使ってないときと変わらない程度？
Llanoも出てるのはほとんど誤差の範囲
CPU自体がロースペックで無いと今現在は意味が無いかもしれん

糞スレじゃなくてdoomのほう見てくることをすすめる

要するにsandy以降のCPU持ってるなら、わざわざグラボ買ってx264でopencl使ってもエンコは速くならない、
もしくはopencl使わない時より画質が劣化するって事？

The source file is 4000 frames out of a 720p H.264 file. The source filter is FFVideoSource. No crashes during the test.
Preset was --crf 21 preset "slower". That's it.
Speed wise:
OpenCL: 17.83 fps
Normal: 11.12 fps
The OpenCL version did produce a slightly bigger file, as Anandtech noted. The OpenCL file was 61.6MB and the normal file 60.8MB.
My system:
i7-2600K
16GB RAM
Radeon 7850

最近は情報源のURLを貼らないのが流行ってるんだろうか・・・。

>>1でも自作板のほうに見に行ってもgoogle検索でもお好きな方法でどうぞ

>>866
TMPG MPEG EditorはCMカットに使ってるよ
エンコの方はAviUtlかAviSynth
フィルタの好みでどちらかによる

>>872
CMカットだけに使うなんて二度手間じゃん

>>869
同サイズだと画質劣化するって事か・・・使えねーｗ

>>873
PSNRやSSIMを書いていないからそれは分からない。
ファイルサイズが増加した分は向上しているかもしれないし。

>>809

>>873
エンコをバッチ処理にしてるなら二度手間にはならんな


H264エンコにTMPGを使う気は全然起きないけど
mpeg2をmpeg2のままいじれるTMEが優秀なのはその通り、別の工程の話だ。スレ違いだがな

なんだ。CMカットしかできないおこちゃまエンコか

すんません、編集面倒なのでバッチでまるごと放り込んでます
ほんとすんません

>>878
それが普通じゃね？
意味もなくわざわざ面倒なことをする人はあまりいないと思う

>>879
それ言ったらエンコなんて全てそうだろ
金もらえるわけでもないのにわざわざバッチ書くとか、めんどくさいこと甚だしい

いや、そういうことじゃなくて意味もなく余計なコスト（労力、時間）かけることは普通しないってこと

画質、編集の追求が無意味なら何でお前このスレいんの？

追求は好きなだけすればいいんだけど結果が同じならバッチでまるごと一括処理が一番楽でしょ
わざわざ別処理したり手動で編集して余計な労力、時間かける必要あるのかね

>>883
CMカットしてからエンコしないと、再生時にCM飛ばしを指定したりで結局は余計な手間が出る件
CMも保存していつも見るって人なら別だけど、そういうのが不要な人もいるから「必要」を語るなら必要と返されて終わるぞ
エンコ前の1回で済ませるか、エンコ後に何回も作業するかの2択やん

>>884
CMカットするしないは自由だがそんなもんTrimだけで終了じゃねーの？

TMPGEncでやろうとすると相当厄介なこと

1. 特定のシーンをいくつもカットして、カットした特定のシーンを動画の末尾にペーストしたい。
2. 特定のシーンを24fpsでエンコさせ、別のシーンを60fpsでエンコさせたい。
3. 異なるTSから部分的に必要なシーンだけチョイスして、1ファイルにまとめてエンコさせたい。
4. 特定のシーンだけ範囲選択して、範囲選択したシーンの彩度だけを変化させたい。
　　それ以外のシーンはフィルタをかけずにまとめてエンコしたい
5. フェード処理される透過性ロゴの除去を消したい。
6. アニメーション動作するＬ時逆コ字を綺麗にcropしたい

x264+AVS+AvsPmodでならこれらすべてあっけなく対処できる
そしてすべてプライスレス。

>>883
バッチで一括じゃ不十分だから手動でやるんだろ
結果が同じなわけ無いじゃん
馬鹿か？

>>887
うん、手動でやるってのはもうそうせざるをえない時だろうから
それはそれでいいんじゃないかしら

>>885
Trimをする作業でトリム位置を調べる方法と「切り取り時の音ズレ対策」はどうするの？
TME3XPはそのあたりの処理が多少軽くて、バッチ処理が出来て、音ズレの調整が個人的にやりやすいんだが

>>886
それの音声はどうやって編集しているのか、そのままなら音ズレなどの問題はどの程度発生しているのかなど
俺ならAvsPmodだと音ズレと動作が微妙に遅いのが嫌だからTME3を使って楽するわ
昔に比べればFAACなどはるかに使いやすくなったとはいえ、まだまだカットだけならTMPG MPEG Editor3が便利
TME3で必要シーンだけ.m2v+wavで切り抜き => AVSで順番にエンコする設定を作成 => .batで結合まで指定して寝て待つだけ
さすがにTVMW5でひとまとめに処理しようとは思わない

手動で編集して、それをあとでまとめてバッチ処理させればいいだけだろう。
CMカットとかは手動でやったほうが綺麗に仕上がるし。
CMは自動でカットすることもできるけど完成度低いし不備があるからな

ここでやる話か？

x264のスレなのにそれ以前の編集の話で盛り上がる意味がわからん
該当スレでやってくれ

DTV板にはTMPGEncの名前が出るとスレに関係なく文句を言わないといられない人がいる

>>889
音がズレるなんてことはそうめったに遭遇しないんだけど。
とりあえずDelayAudio()で微調整すればいいんじゃない？

おおまかな手順として、ソースを読み込む -> trim()などでカット・ペーストする
-> ロゴ抜き & ITSチャプタ編集 -> フィルタを噛ませずにプレビュー再生して音を確認
-> 問題が無ければ 各フィルタを噛ませて AVSとDEFを保存

ここまでの手順でだいたい30分番組のTsなら10分程度。
ま、あらかじめテンプレートみたいなものを自動生成するようにしているから編集も楽ちんだし
だらだらと長文を書いてるけど、地デジソースのTSをエンコさせる場合は以下の工程だけでいい

1. explorerでTSファイルを選択、右ｸﾘで解析処理用のバッチを走らせる
　(内訳)geteit->tssplitter->dgindex->vobsub..etc [所要時間は30分のTSだと2・3分程度]
2. 1)の処理が終わるとavsとdefとd2vとaacとEIT.txt等が生成されるので
　avsとdefを冒頭の手順に従い編集　[ここの所要時間は平均10分程度]
3. 2)で編集したavsを一括処理用のバッチファイルにパラメータとしてコピペ。
　同時にIDTAGS情報やコメント欄のメッセージなども設定 [所要時間は1･2分]
　ここで動画の内容に合わせてx264パラメータも環境変数等に入れて調整もできる
4. 一括処理用のバッチファイルを保存して、エンコ開始。あとは寝て待つだけ。
[所要時間は・・・ってしつこいよなｗ]

ちなみに30分番組のアニメ(1440x1080i -> 1280x720p@VFR)だと
エンコが終わるのは15〜20分程度かな。

ま、x264を使うにせよバッチファイルを作ってまとめてやらせた方が気が楽なのは確かだよ。
GUIフロントエンドとかでマウス操作してパラメータ渡しでx264エンコさせるのも邪魔くさいし。

>>893
文句も何も、わざわざTMPGEnc使ってるって言うから
どんなすごい処理してんだと聞いて見たらCMカットだけだったってオチだろ

CMカットってSUGEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE！！１１よね

めんどくせースレだな

ここはx264のスレ
編集の話題はスレチ

こんな簡単な事も理解できないアニヲタ

>>894
その１から４までのバッチ暮れ！

x264エンコするにしてもそれ以外で何か編集するとしても
とりあえず自分でバッチ作ってみなよ。
作るのは面倒だろうけど一度バッチが完成しちゃえばその後の作業が格段に楽になる

時間を短縮するための自動バッチいじってる時間が100時間超えて本末転倒な人とか多いはずだ
基本何も無ければ完全放置なんだけど、新しいオプションやツールが出る度に自分のバッチに取り入れたくなるので
いつまで経っても弄り続けているのであった

新しいオプションやツールもそうなんだけど
むしろ知らない既存のものを取り入れる機会の方が多いよ。
こんなのあるならもっと早くバッチに組み込んどけば良かった・・・と

>>899
別にアップするのは構わないけど、動作環境揃える自信あるの？相当あれこれEXE使うよ。
もちろんレジストリも弄るし、OS依存もあるだろう。扱うファイルはEXEとかPerlとか
cygwinとかdｌｌとか全部ひっくるめて、RARの最高圧縮で200MB前後は行く。

ま、でも各ライブラリやフィルタやEXEなどの再配布許諾の問題もあるから
安易にRARに固めて配布していいものでもないと思うんだけどな。
バッチファイルだけもらってもほとんど使えないと思うぞ。
殆どがPerlやEXEありきで動作させているしな。

--preset veryfast --tune film --crf 23 --qpstep 81 --qcomp 1
ツッコミおながいします

質問書き直します。いつもの自分は、
--preset veryfast --tune film --crf 18
なのですが、以下のようにやったらほぼ同じ画質とほぼ同じビットレートになります
--preset veryfast --tune film --crf 23 --qpstep 81 --qcomp 1

crfを小さくするのと、crfをデフォ23のままで --qpstep 81 --qcomp 1のように自由自在にしてあげるのとどちらがいいと思いますか？

>>905
画質ってのがPSNRやらSSIMのことを言っているなら、後者のような極端な設定はお勧めできない。
qcompの意味を調べて考えれば理由は分かるはず。

>>905
前者の方が後者より結構サイズ膨らむけど、しかし画質も良くなる
というわけでサイズ重視なら後者、画質重視なら前者でいいんでないの

>>905
その間を取るような感じで"--crf 20"だけでいいんでないの？
エンコ時間は少し増えるけど前者と同等かそれよりサイズは抑えられるし、尚且つ画質も良い。
presetとか全部要らないよ。

>>903
どんと来いです！
何とかなるでしょ！

>>908
・無指定(=medium) film crf 20
・veryfast film crf 20
前者の実写の場合エンコ時間が長すぎると思うのです。
同じcrfなのにveryfastのほうがSSIMよくてビット少ないという逆転現象起きる場合もありますし
エンコ時間も数倍早いので無指定はちょっと

2つ質問があります
１、固定品質・固定ビットについてはわかりますが固定量子化の量子化とはどういうことですか？
２、適応的Bフレームの挿入「簡易」の挙動についてです。ビット量が　完全＜無効＜簡易　の順になっていて変なのですが・・・
原因を探るためログを見ると簡易のときだけBフレームとPフレームの数が逆になっています・・・以下ログおいておきます
https://www.dropbox.com/sh/osvb6m0hnw6ndkf/CCKwtkgcxZ
EXGUIv142とnlの最新64bit8bitを使用しています。

>>910
2の件は確かにあれ？って思うけど慣れたなぁ

b-adapt 2は
エンコード後にソースと見比べて「うぁー汚ねぇ」って
思うような事が無い限り(見比べる事すらしないなら)使った方がいいんじゃないかな
相性の悪いソースでちょっと酷い事になるけど、ほとんどのケースで綺麗に仕上げてくれる

b-adapt 1は無理にb frame使おうとしないから特定(b frameが不得意)ケースでサイズがバカでかくなる

BとPが逆転してるって事は今回は b-adapt 1 の方がソース忠実になるが
ビットレート比だと無駄と判定されたソースだと思う

GPUエンコはまだ始まったばかりか

打ち切りフラグ立てるなｗ

しかし開発速度によってはdark_shikari氏の次回作(x265)にご期待ください！になることも十二分にありえるな。
h265が主流になれば互換性以外の問題以外でh264は使われないだろうしそっちだけ頑張ってくれればいい

未だにflvやらmp3やらが残ってる現状見るとなぁ・・・新しい規格はライセンスの問題もあるし

粗悪なエンコーダーだとh265の癖にx264より画質悪いって状況もあり得るなｗ
h264の画質もピンキリだしな。x264の画質は1世代分位進んでる気がする

>>916
おまえの脳中ではx264という規格が存在するのか？

>>917
？

はらたいら『　「規格なんて文言はどこにも含まれていない」などと反論がくる。に、1000点』

三拓にしておくれよw
「x264は、規格かエンコーダーか両方か」
女王あけましょう、ドン！

H264の規格に沿ったフリーのエンコードソフトがx264と理解している

規格が良くてもエンコーダが糞なんて良くあること最近だとWebMとか

ssimでは確かx264のデフォ抜いたんだっけ?-tune ssimでは知らんが

>>923
ここから改善されたとは思えない。

http://www.compression.ru/video/codec_comparison/h264_2010/appendixes.html#Appendix_8

DS氏やら協力してるし今月だったかアップデートされてる
DaalaのほうじゃDS氏の名前見たけど265は何も決まってないんじゃね
opencl化かアセンブラで最適化しなきゃ遅くてまともに使えんだろうし

snowを忘れてもらっては困る

鬱だsnow

x264.nl の2197にうｐデトしたら
同一ソース/設定で300MB超もサイズが大きくなったでござる。ｗ

BD-XL4層用に100GBの動画つくったら2197で300MB超もサイズが大きくなったでござる
なら誤差範囲内だな

そんな動画作っても中身がつまらなかったらすぐ捨てるのがオチ

なんで>>928みたいな奴は、いつもファイルサイズの絶対値を併記しないんだろうな。
同じようなパターンで、「〜にしたらエンコ時間が20分伸びたｗ」とかいう奴も居るな。
馬鹿じゃないかと思う。

怪しい通販のうたい文句かよと（ｒｙ

r2200

おお…2200

2200にしたら宝くじ当たったわ

r2200来たのに盛り上がらないな…
まあ、盛り上がるほどの変更じゃないしな…

画質が前以上にならない限り1964で逝く

2164だった

完成と言える日は来るの？

君が完成だと思ったときが完成なんだよ

（円盤焼いてまで民生機で検証しようと思わないのからここに書く）
--bluray-compat 使うとき解像度が不適切な定形外の場合、事前警告がでないのだけれど
これは、クロップした1920x800とか1920x802なAVCエレメントは仕様から外れるけど-
BDMV/BDAV/AVCHDフォーマットにつっこんでも実際問題構わないから警告なしと楽観解釈していいのかしら？
あらゆるBD認証機器での再生の保証・互換保持のための1920x1080とか仕様上定められた定形サイズだとは思うけれど。
実際問題クロップして定形外だったり変態解像度だとうまく再生できない民生BDプレイヤーってあるの？
なかったとしてもこの邪道がまかり通っていいとは思わないのですが・・
・・・検証済みだよというレスがなかったら明日一度実際に焼いてみることにする

--bluray-compatが解像度のチェックをするとか初めて聞いた
そういうのはもともと--deviceで設定し、フィルタと連携させる予定だったからな

--bluray-compat は MiniGOP 制約。

IBBPBBPBBPBBP とした場合、Ref=3だとしても間のBは直前直後のIP*しか*参照できない。
Pは前3枚の参照ができるんだけどBはそれが許されないという謎仕様。
あと、Iを超える参照もダメ。

もうそれならIPPPPPPPPにしようぜ

そうだったのか
ブルーレイでも観れるようにbluray-compat入れてたけどそんな謎仕様だったとは

再生能力検証用BDMVに収めるAVC作成中なんだけど日米WikipediaのBD項読む限りBDMVは1920x1080/30Pをサポートすると明確に書かかれておらず
寧ろ逆に1080Pは24Pまで、1080Iは60Iまでと書かれている。　http://en.wikipedia.org/wiki/Blu-ray_Disc#Video
今さらながら振り返ると市販BDの裏はネイティブ24Pか、どう考えても無駄に30Pソースをインタレ化した60Iかネイティブ60Iしか見たことなかった。
規格外というか明確にサポートすることになってないから再生できない糞プレーヤ引いたとしても文句いえないのか・・・？（市販では存在し得ないのだけど）
原理的には60Iの60フィールドが再生できるのなら30Pは再生できると思うんだけど。

話はそれるがAVC1920X1080/24P,30P,60Pで撮影できるビデオカメラあるけど60pは当然無理だとして、
30PまでもがBDMV/AVCHDにそのままつっこめないなんて・・・それなら24P,60Pだけでいいと思う



http://www.avchd-info.org/format/index.html
これはAVCHD版の詳細ドキュメントなんだけどBDMV版誰かしりませんか？
姉妹規格のAVCHDにも30Pは無視され嫌われている・・・720/50P,60Pは書かれているのに
http://sites.google.com/site/x264bluray/には一応30Pのテンプレ載ってるんだけど・・・どうしたものか

質問は良いけどもうちょっとチラ裏と自論削って文章纏められ無い物か…。

読む気にならん
スルー

>>946
これで妥協するしかない。

http://mewiki.project357.com/wiki/X264_Settings#fake-interlaced

さんきゅう
インタレ偽装ねやってみる

バンディング関連の改善が今回も無かった。
MPEG2 10bitで保存の日々が続く...

釣りなんだろうけど、Mpeg2ならTS保存で良いよね

Mインポ３ BD: MPEG2 　　　　　> x264CLI veryfast film 23 > 1920x818 AVC > テレビで鑑賞→いい画質だなぁ遜色ない！（AVG5.0Mbps）SSIM0.94←え
ハリポタ死の秘宝P1 BD: AVC > x264CLI veryfast film 23 > 1920x802 AVC > テレビで鑑賞→残念画質（AVG1.2Mbps）SSIM0.97←え
後者にビット振らなさすぎる。なんだこれ

SSIMが高いってのは、ボケた画質ってことがほとんど
せめてPSNRで語りましょう

逆じゃね？

いや、合ってるのでは？

SSIM→デブロック有利。ってだけで、大体妥当な数字が出る。 細かな比較には役に立たない。
PSNR→高いなら良い。だが、低くても見た目は良い場合がある。デブロック不利。

SSIMとPSNRとは : ageha was here
ttp://agehatype0.blog50.fc2.com/blog-entry-181.html
PSNRの値そのものは無意味。
SSIMの絶対値比較は妥当とか大体SSIMのほうがいいように感じるけれど

ｒ22222にしたらBIGで六億円当たりました

２のぞろ目だと確変じゃないからダメだな。
どうせなら３か７のぞろ目で頼む。

>>952
Aviutlでロゴ消し→vfp→TMPGEnc→MPEG2 10bit
・バンディングなし
・再生互換性問題なし

x264の場合、MPEG2と同じ程度まで圧縮率を落とさないとバンディング消えないし
圧縮率低いなら後々扱いやすいMPEG2の方がマシという結論

フェードありのロゴはそれではうまく消えないんじゃない？

>>960
x262 is under development: a best-in-class MPEG-2 encoder built using
the x264 framework.
http://mailman.videolan.org/pipermail/x264-devel/2012-May/009355.html

x262 MPEG-2 encoder

>>962
なにこれ？
Google関連もやるしMPEG2もやるしVP8？もやるってこと？

あほすぎ

よく知らないのだけど、MPEG2では10bit-depthも一般的で、再生互換性も特に問題ないものなの？
GPU再生支援（必要かどうかはともかくとして）も普通に効くの？

>>966
彼が本気で言ってるのかどうかは知らないけど、相手にしないほうが良いよ。
H.264はMPEG2の上位互換。 一部を抜き出してx262を作れるぐらいに。
第一、バンディングなんてポストプロセスで簡単に消せるんだから、こだわるのが無駄。

利くとしてもCUDA2かUVD3ぐらいからじゃないのかい？

>>966
再生環境は、PC / テレビ（DLNA経由）/ PS3 （MPEG2 10bitは何れも問題ない）

いまどきのPCでMPEG2の再生に支援が必要かどうかわからないけどnVidia系では
再生支援が有効。
というより、Vista以降のOSに標準装備のMicrosoft MPEG2 Video Decoderで普通に再生できる。

>>967
再生側の補正でx264で出力したH.264ストリームのバンディングは確かに消せるけど
再生側の特質や性能で結果が変わるし、結局再生側に依存することになるから
拘らざるを得ない。

＃x264でのバンディング関連の改善に期待

こんなに経っても暗部もバンディングも改善されないんだから
今更改善する気なんて毛頭ないだろ
そんな事にも気付けずにポカーンと口あけて待ってるとかアホ杉

じゃあ報告頼むわ

暗部もバンディングも前処理と設定次第

糞ディスプレイでバンディングが〜云々言ってたら笑うな

fushizenにあるJEEB氏のx264とx264.nlにあるx264は何が違うんだろう

fushizenのほうは更新遅かったよ2200になるの

2200不具合あるな

不具合？またDxVAで崩壊するんか？

DXVAだろう。なんでDxVA？

なにが「また」なんだろうな。盛大に勘違いしてる気がするけど。

ｒ２２００の翻訳お願いします

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

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

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://toro.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

[changelog]

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

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

psy-trellisの適正値がよくわかんないんです＞＜
デフォだと強すぎるときいたのですが＞＜

rdoの適正値がよくわかんないんです＞＜
デフォだと強すぎるときいたのですが＞＜

全てに通用する適正値など無い
自分の好みでいい

実写→1以下 アニメ→0.5以下か0 でおk