1 :
名無しさん@編集中 :
2012/03/20(火) 15:07:07.17 ID:Jo7M507N
2 :
名無しさん@編集中 :2012/03/20(火) 15:07:22.87 ID:Jo7M507N
3 :
名無しさん@編集中 :2012/03/20(火) 20:15:37.87 ID:ad9XLWDP
おお… 生tsが一番高画質と思ってるのがいるのか
4 :
名無しさん@編集中 :2012/03/20(火) 21:49:45.65 ID:atkhloaZ
スレ違いさんかい、早い、早いよ
5 :
名無しさん@編集中 :2012/03/21(水) 01:03:49.94 ID:Wg6N2nMF
>>3 >生tsが一番高画質と思って
俺も思ってる
何をしようとソース以上である筈が無い
加工して一見綺麗になっていたとしてもそれはオリジナルから更に遠い存在になってるだけ
ただ軽くしたいから再エンコードしてるだけ
6 :
名無しさん@編集中 :2012/03/21(水) 01:42:14.60 ID:D3As0Prx
アホくさ
7 :
名無しさん@編集中 :2012/03/21(水) 03:08:29.23 ID:SX21kgsW
マジレスすると納品物は制作でエンコされてて、 放送波に載せる時に更に局で再デコエンコされてる(配信局) CATVなんかだとヘッドエンド等で更に再デコエンコされてる ソース教の方の神は何処に居るんだろうか 懺悔 随分前だけど系切り替えに失敗して0.5秒ほどブラックアウトさせました ゴメンナサイ
8 :
名無しさん@編集中 :2012/03/21(水) 03:22:13.48 ID:Krs69iCM
>>7 俺らが制作のマスターをあたりまえのように入手できるはずもなく
放送波のMPEG2が最もエンコード回数の少ないソースになるのは仕方ないこと
まあこの手ネタはBD買っとけで
9 :
名無しさん@編集中 :2012/03/21(水) 03:23:48.48 ID:ihCJv+6S
おお… 生tsが一番高画質と思ってるのがいるのか
>>8 とりあえずBD買っとけでFAなのはその通りだな
ただ放送波は(正確にはBDも)ヤッチャッテルのが少なからずあるんで、
そこは手加える余地はあると思うよ
再エンコード=劣化ってイメージする人多いけれど、
実はそんなことはなくて、適切な処理施せばオリジナルに近い形を復元できる事もある
ばかぽの人とかが時々やってるアレ
当然無理なもんは無理だけど
tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる サイズはそれなりだが
ウザ 荒しネタに荷担すんなや
>>11 そこはたぶん好みの部分だと思うがw
余談だけど、マスター以外がヤッチャウ時の話
送出するときってリアルタイムにdemux→映像/音声デコード→テロ挿入とか→映像/音声エンコード→muxしてて、
おまいらがエンコしてるのと同じ作業をリアルタイムでやってるんだ
で、それぞれの機器も当然不調/調整ミスがある
音声同期おかしくなる事もあるし、ブロック喰う事もある
アニメじゃないけど稀によくあるのが音声モードの設定ミスとかな
なので過度にtsに拘っても厳密には「○○放送局のソースを残す」以外の意味はないと思う
コピペに反応すんなやカス
簡単なフィルタ処理だけしてx264可逆が最強ですね。分かります mpeg2より圧縮率がずっと高いって謳っても放送ソース越えられないってなんかなぁ。もっとBDよりも綺麗なソースをエンコして保存したい
「やっちゃってる」ところ以外いじる意味なしってことでしょ? 色だの線の太さだのオリジナル状態知らないで自分の好みでいじるのは 結局自己満足なんだから否定できる訳も無いけど やっぱりソースに近いほど良いことになる
スレチ
おい色空間スレが落ちてるぞ
立ってから18日、今回も12レスで終了か。セミのように儚い命だったな。冥福を祈るとしよう・・・。
ここか
次はここか。
fヘ ,.. -─ ¨z_ fヘ._ ,. -‐ ¨ ゙̄k、 r"゙Υ ノ:\ (¨´Υ ノ::\ __ _〉 _,.ム、 /i::::::::> ,.-‐‐- }、 ,..ン-、 ム、:::ア、 (´ `ムyヘ´ ヽ"´ ヽ' :. ( ,、 i-<ヘ¨´ `" ヽ ゙; | ◯ |{_ノ: :.:7´ 〉 .} ト、〉┷ シ'|" ', 〉 .} 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内部ではこういうの使われてるの?
26 :
名無しさん@編集中 :2012/03/21(水) 20:25:10.88 ID:yxhJAbDe
ふたばのグロスレ行ってみなよ BLOOD-Cの話がちょくちょくやってるから
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 → 2ピクセルで色差情報2つ(Cb×1、Cr×1) → 1ピクセルあたり1個の色差情報 YUV4:2:0 → 4ピクセルで色差情報2つ(Cb×1、Cr×1) → 1ピクセルあたり0.5個の色差情報
間違ってないだろ
YUV4:2:0はYUV4:2:2の色差情報インターレース版だと思えばいい
ヨブさん今回は2164のまま更新されないけど2183でバグがあったから2184も見送りなのかな?
>>34 単に忙しかったりするよ。444p10でエンコしてた時クラッシュバグ発見したし、
アレをデバグしないといけないし(バニラなx264では発生しない)。
444はそんな問題抱えてたのか
バニラって何?
38 :
名無しさん@編集中 :2012/03/22(木) 14:00:30.84 ID:YJWWdoxo
バニラ(アイス)はプレーン(オムレツ)とか素(うどん)とかと同じ意味 ソフトウェア的には、いけないパッチ当てたりけしからん魔改造とかしてない 素顔のままの君ってことです たぶんね
ひやくしすぎだろ。
クリームパイとストロベリーミルクなx264をお願いします
各パッチが何味か決めようぜ L-SMASHはチョコチップでどうよ
誰にもフォローされてないtwitterで独りでつぶやいてなさい
バニラさん知らない奴がいるなんて・・・
どうもパッチと聞くとジジ臭いイメージしか出てこないんだが。
ポール牧が浮かんだわ
46 :
名無しさん@編集中 :2012/03/23(金) 00:07:33.26 ID:70cK8I+n
馬韮さん?
ギャラクシーエンジェルじゃないの
山崎
バニラは俺の女
実はレバニラの誤植
で、r2185はまだ来ないの?
もうr2190ぐらいじゃね
chenge.logにはまだそんな報告来てないんだが
changelogの更新はx264.nlでx264.exeが更新されるタイミングじゃなかったっけ
レバーとか食感キモイし味も不味いしなんで内臓喰う野蛮人がいるのか理解でけへんわ
なるほど・・・縦読みか
食べ物を大事にしろよ 人口爆発と食糧難の時代はいずれくるぞ
関西圏の奴は小麦粉さえあれば生きていけるからな
関西人は小麦粉にソースかけて食えば満足
前スレ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化した時と同じように12ヶ所で色がわずかに変化してしまいます。
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
66 :
65 :2012/03/24(土) 03:59:05.10 ID:nEXenV/W
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の仕様かと
71 :
64,65 :2012/03/24(土) 13:41:21.73 ID:aoWDXxl2
>>69 >>64 の ffmpeg_38996.exe を avconv_32956.exe に置き換えて実行してみたところ、
●上下反転している
●8bitYUV化した時と同様に12箇所で色が変化している
という結果になりました。まさかここまで違う結果になるとは。avconvでは何か別のオプション指定が必要になるんでしょうか。
なんか自分の中で混乱してしまってますが、これは結局Libav側の問題ということになるんでしょうか?
>>70 書き忘れてしまいましたが、avs2pipemodを使ってbgr24をraw入力した場合も8bitYUV化と同じになりました。
ただ、avsの場合にConvertToYV24(8bitYUV化)が入ってしまうようだと、それも色変化の原因になりそうですね・・・。
!の意味が通じるのか微妙だが
>>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化が入らないようにする。 となっていたほうが嬉しい気がしますが、そういうふうにはならないのかな。
ヨブさんまたサイトが・・・
ヨブさんをヨブ
審議拒否
来月から始まるトランスフォーマの新シリーズ。これは特撮CG系の番組だが こういうのはcrfでエンコしない方がいいんだっけ?動き激しすぎて容量膨れまくるだろうし
意味不明
品質一定にするためのcrfだろ
crfで品質一定に?何の冗談だよ。いいとも増刊号とか60fpsでエンコするときも 毎回シーンチェンジを切り目に20000フレーム毎に分割エンコしてmkvでマージさせている。 crfを指定してエンコしたものは品質(圧縮率とSSIM/PSNRの値)が一定になることは殆どない。 値もバラバラ。一定になるのならdb値の変動幅も小さいはずだろ?
おもしろい
ほんとおもしれーな ビットレ指定と勘違いしてんじゃねえのか
いいとも〜
じゃぁcrfが品質一定だという根拠と正しい意味を説明してみせろ。
だから用語じゃなくてさ。
アカン言葉が通じない
これはファビョりフラグ
いつの間にかPOP氏が2184ビルドしてた
>>91 他のオプションとの兼ね合いでcrfの効果は全然違うし、明確な定義はソースを見れとしか
おおむね人間の感覚で一定の品質になるようなビットレート配分というぐらいの意味合い
・圧縮率は品質とは無関係だから一定にはならない
・PSNRも人間の感覚とは大きな乖離があるから一定はならない
SSIMは人間の感覚にマッチするように考えられた評価関数だけど、
最初にも述べたようにx264で用いられてる品質の定義とは必ずしも一致しないし、
そもそもほかのビットレート配分をコントロールするオプション(qcomp、AQ、trellis等)によっても変わる。
この人一定のサイズに揃えてあると品質も一定だと思ってるのかな? どんな動画でも一律似たような圧縮率になると思ってるんだろうか?
97のレスを見てもしっくりくるレスがでてこないんだが 結局crfは品質を一定にできるわけじゃないんだろ?
どこかの雑談スレでやれよ
ソースと比べての画質・圧縮率・崩壊の加減
とりあえず透過性ロゴは見えなくするし、いらないCMもカットするので その部分に対する差異は無視するとしてだな。
>>102 >画質
>崩壊の加減
その感じ方は人によってまちまちだろ?
SSIMなり、x264のcrfなり、それぞれの理論がある。必ずしも一致するわけではない。
また、人によって、用途によって、品質の評価を変えたいという場合のために各種オプションがある。
だからcrf以外のオプションの指定の仕方によって結果は変わってくる。
>圧縮率
それは品質をあらわすものではない。
違うソースでも圧縮率が一定なほうが、むしろ品質が一定とは言いがたい。
とりあえず「crfの品質一定」について知りたいのは
↓こいつのレスに対する根拠とその意味なんだけどな。
> 85 名前:名無しさん@編集中[sage] 投稿日:2012/03/27(火) 13:54:36.87 ID:uAKxVqwy
> 品質一定にするためのcrfだろ
さらに言えば
>>83 のレスのまともなレスがこないのでさらにしっくりこない。
>>104 なんとなく伝えたいことは伝わってくるが、どんどん話がズレてきてないか?
規定した一定の設定に沿ってビットレート消費を調節するそれがcrf なので品質はその設定に沿って決められている ビットが必要なところはその設定に沿って食うし、必要ないところは節約する それだけだろ品質の認識の違い、誤解が無駄話の原因 ビットレート一定だとどこでも一定のため動くところも動かないところも「ビットレート」が一定 決して品質ではない、ビットが多く必要な部分では破綻する
>
>>83 については、動きが激しいなら品質を保つにはたくさんビットレートが必要なんじゃないの、としか言いようが。
そりゃビットレを盛ればそれなりに品質も保てると思うがそれをやると容量が膨らむだろ?
実質CMカットして24分番組らしいからデータ量的に250〜300M前後に抑えたいんだよ。
トランスフォーマ系は毎度長いので2・3クールぐらい来そうな気がするし何話まであるのかわからないしな。
動きの多い実写/CGパートの混じるアニメとかだと、crfでエンコすると容量が一気に膨らむし難儀するだろう。
>>108 容量が膨らむのが嫌ならcrf値を上げれば?
しらねえよそんなの お前はもう品質について語るな
そもそもCRFは一定ファイルサイズでエンコする設定じゃないだろw ビットレート指定のABRの2パスでやれや
だから品質についてなんてどうでもいいだよ。
>>85 からレスが帰ってこないからイライラしているだけだ。
なんで他人のあんたらが噛みついてくるんだか。
>>112 2chに書き込みして何戯言いってんだw
噛みつかれて、もともとの話題。
だからIDと顔が真っ赤になっているんだよ
crf指定 画質:できるだけ一定 ビットレート:↑↓ bitrate指定 ビットレート:できるだけ一定 画質:↑↓ ってだけの話だからサイズを制限したいならビットレート指定で決まりじゃね?
>>113 IDが赤いのはレス数が多いのが原因
あと顔は別に赤くないので問題ない。
>>114 そうなんだよな
crfでも--vbv-maxrate指定ある程度までビットレ制限できる。
ま、動きの多いソースだとどのぐらいまで抑えていいものか判断に迷うが
動きの激しい場所で容量が膨れてほしくない人でcrfを使いたい人には --crf23 --qcomp 0 なんてどうでしょうか? きっとご期待に沿える動作をしてくれると思います
容量決め打ちしたいのにCRF使うなんてアホだろ
品質一定画質一定にしたいならcbr10000でもしとけよもう
>>118 変なのに絡まれてくっそウザかった気持ちはわかるけど、もうその話は終わって、
ただファイルサイズ抑えたいって言ってるだけなんだから、わざわざ無駄にかき回さないほうがいいと思う。
>>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・3クールぐらい来そうな気がするし何話まであるのかわからないしな。
動きの多い実写/CGパートの混じるアニメとかだと、crfでエンコすると容量が一気に膨らむし難儀するだろう。
www
むしろJok74uSEってのが春休みで湧いてきたんだろ 頭もな
>>Jok74uSE ジョークなようなウゼェ奴って意味? これだけバカだとID変わっても一発でわかるな。ID隠してバカ隠せずo(^▽^)o
でもサルにおまえはサルだと自覚させるのも大事かも
こういう流れは色空間の話と違って2chらしくて微笑ましい
色空間ネタはもう要らないから
いまさらだけど全然動いてないと思ってたキルミーベイベー意外と縮まらない
どしたのわさわさ
144 :
名無しさん@編集中 :2012/03/28(水) 06:33:56.09 ID:G8XQBT36
おお…crfで品質一定に?何の冗談だよ。
___ ___ . ( ) ( )  ̄| | | | ̄ | | | | | |. | | \ \__/ / \ / /|. |ヽ / ⊃ ⊂.\ / /| |\ \ ( < | |. > ) ひみつだよ \ \| |/ / __ \__ ___/ ||\ .:;Σ;:| |:;て;:. \ ||\\ """"" \ || \|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| . || ̄ ̄ ̄ ̄ ̄ ̄ ̄|| .|| ||
______ \ 死 \ |,.\ 誰 者 \ / \ │ は、 \ / ,. i \__?_____\ | /.| |\||_______||~ | .| | | | || || _./⌒..───' | / | | .|| || __/⌒ 二二ニニ ノ U || ||
レスが進んでるから更新きたのかと思ったらこれだよ!!!
ここでホットな情報をひとつ 有吉がもっとも嫌いなのはナンチャンらしい
そういやAnother面白かったな
まだ最終話見てないんだからネタバレすんなよ 絶対だぞ
犯人はヤス
Another録画してたけどまだ観てないwww 面白いなら一気に観てからエンコするかな
場の空気を読まずに「おまえ」「こいつ」という1人称を 平然と使い続ける奴は人格障害だから温かい目でみてやんな
ヨブさんサイト復活したけど10bitのx264が404です
ヨブさん10bit復活ありがとうござる
そんなの書いてないだろ f3kdb使ったら自分の好きなディザリングアルゴリズム使えるってだけだ
r2184ってなんだか容量小っちゃくなって細部つぶれぎみな気がするな 2164と同じくらいの容量目指しても 海外のユーザーは高圧縮最適化を目指してるのかね
だったらcrfを0.5くらい上げてみればいいだけじゃん
下げるの間違いだった
それを言うならqcompの値を調整すればいいんじゃない? crfだけじゃあまり変わらんと思う、むしろ余計変になるかもよ。
>>160 ditherのDither_convey_yuv4xxp16_on_yvxx()だとディザリングアルゴリズムが選べないというわけか
>>165 Dither_convey_yuv4xxp16_on_yvxx()は16bit出力しかできないからディザリングそのものがないのでは。
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の有無による違いは、(無駄に)処理をするかどうかというだけで、
エンコード結果に違いはないように思えるのですが、違うのでしょうか?
あ、失礼、記事を読み違えてた気がする・・・。
skip_depth_filterの有無でエンコード結果が変わると書いてるわけじゃないですね。
>>169 の「結果に違いは出ない」という解釈が正しいかどうかだけでも教えていただければ幸いです。
なぜコメに投稿しない
そうしようか迷ったんだけど、ちょうど話題に上がってたし、ここのほうが色々な人の意見が聞けるかなと思って。
174 :
名無しさん@編集中 :2012/03/31(土) 02:59:41.35 ID:Un/4Ti2F
>>174 YV12とYUV444の違いがわかればわかるでしょ
BENIがカバー集リリースしたぐらい意味わからん・・
更新がないと過疎るな…
個人記事の話題をこっちに持ってくる必要はないな
179 :
忍法帖【Lv=40,xxxPT】 :2012/04/01(日) 21:20:09.38 ID:/vzcbgJt
!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キタ?
--fullhelp
コマンドプロンプトの横幅を90文字くらいに増やせばいいんじゃね
ていうかFHDのエンコで10fps前後しかでないのってどうなのさ?
どうも何も、それくらいの環境orそれ以下の人のほうが多数派
HDのエンコで10fps前後しかでない俺の環境バカにしてんのか
それ以上のスピードを出してもしょうがなくね?
1fps しかでない俺のPen4馬鹿にしてるのか
m9(^e^)
2600Kだけど2fpsぐらいしか出ない
オプションを凶悪にすればするほど高まっていくソースのままでいいやと思う気持ち。
そーすね
気に入ったもの以外はデフォ相当の設定で気に入ったものはcrf値下げてumh subme 11
>>209 インタレ保持でcrf18、ついでにqcompも0.8に
…あれ?元のtsとサイズ変わらなくね?
なんて事があるから困る(苦笑
そういうは単なるバカ。
片言で馬鹿にされる
>>210 カワイソスw
ここ最近HDD高騰のお陰で圧縮率悪そうなのも試しにエンコしたけど
やたら動いたりバックにLEDの巨大スクリーン有る様なライブ物なんてcrf23 qcomp0.7で半分でも御の字だからねぇ…。
そんなのを
>>210 でやったら下手すると元サイズ超えそうだw
ヨルムンガンドのグレインノイズやべーんだけどどうしよう
どうもしなくていいのでは サイズが増えるのは当たり前だし
グレインノイズ見た瞬間ナニ思うかって言ったら「これは縮まない」だよな 昨夜視聴しながらそんな事ばっか考えてたわ
まぁ演出でつけてるもんを潰そうとは思わなかったからいつも通りやってみたけど 1.55Gになってしまった これじゃDVD-Rに4話どころか3話も入らん・・・ せめて1.45Gくらいにサイズ減らそうと思ったらこういう場合まずどこを弄るべき? crf一択かな
サイズ減らすならcrf上げるかqcomp下げるか、その両方でもいいし 細部捨てるならaq下げるのもあり
>>217 thx その方向でやってみる
あと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は…アニメなら既にある程度調整してるか。
縮めるなら砂嵐が靄に成るぐらいの妥協は覚悟。
>>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を5GHzOCしてると冬でもつらい
ほぼ同じ>219が600Mって言ってるのに235Mて 絵凄そうだな
tvkはグレインノイズが潰れてるらしいから、そっちで録画したやつは素直に縮まるんじゃね?
MBと書かないでMで済ませてるの見るとイラっとする
一応、BS11ソースな
逆に同じ設定でQBリベリオンをエンコしてみたがこっちは350Mまで膨らんだ。
だいたいAACは平均30M前後になるので 実質ヨルムンガンドの映像は200M、QBリベリオンは320Mだな 崩壊や破たんは無いから気にしていないが。
エンコオプション全部見てみないと何とも言えない気がする crf20 qcomp0.54だけだとよくわからない
グレイン除けば縮まらない画じゃない気もするしpsy-rdも限界まで下げれば縮まるかも知れん ただ背景がべったり塗りつぶした油絵の様に成りそう
毎回アニメのCMもtrimで後半にまとめて含めるから そういうベタ塗りになるようなエンコは最初からお断りだが たとえば銀河キックや、プリティリズムや、へうげものとか アニメと実写が混ざった番組とかだと油絵みたいなエンコをすると大変なことになるw
で、ID:m0vE8+poの設定晒しはまだか?
目暗設定お断り
実写もニコニコの「なにこの高画質w」レベルで問題無いって感覚に成ってて qcompもrdも下げて何か問題が?ってのいるからねぇ・・・。
パラメータ弄っていい感じになったと思ったら別の箇所が駄目になる・・・っての繰り返して 結局行き着く先はデフォルトという
いつもザラザラ あなたのエンコに這いよる混沌 グレインノイズでっす
ニャルラトホテプは来るんじゃねぇ
フィルムグレインって味があるとか言われてたけど、エンコに限っては邪魔者でしかないな。
(」・ω・)」うー!(/・ω・)/にゃー!
>>250 だいぶまえにx264スレで晒したから、もっかい晒す気など毛頭ない。
そもそも他人のパラメータを見せられたからと言って何の参考にもならんだろ。
ID変わってからレスですか
それに個人的にはx264のパラメータ云々より avsフィルタやaviutilフィルタの組み合わせの方が重要と考えているわけだが avsやaviutilを使わずにx264のみでエンコする奴には何を言っても通じないだろうな
笑える
じゃぁ一生笑ってろw
だいぶ前に晒した時に叩かれたんで勘弁してくれって事ですね わかります
日をまたいでIDが変わったときに自演するのは常識
別に自演なんてしとらんがな 都合が悪いレスが来たとたん態度を変えるのやめろよな
アニヲタうぜぇ
このスレの95割はアニオタだろ
>>260 まあグレイン消したいだけならそういうフィルタかませばいいんだしな。
逆にフィルタでグレイン付加することもできるし。
x264でもfgoパッチでグレイン付加できるんだっけか、やったことないけど。
グレインと一緒にディテールもさようなら
日本人なんだからグレインなんていわずブツブツって言おうぜ 例 このブツブツすげー ブツブツ多くてエンコ大変そう うわ、これブツブツだらけじゃん
日本人ならブツブツの感覚をそれに使う事はないだろうな
(:.;゚;Д;゚;.:)クレ、アラシル!!
ザラザラ
グレインはジリジリかチリチリかなあ
ブツブツいうとあの画像思い出すからやめて
グレインは普通ザラザラじゃね。 ブツブツって感覚はわからん。
ツブツブって言いたかったんじゃないかな まぁそれでもザラザラだろうけど
ああ、ツブツブならわからんこともない気がする。
ツブツブジュースって美味いよね
俺イクラはダメなんだよね
今のx264ってtrellisとdeadzone-inter・deadzone-intraって同時使用できるようになったの?
できねえよ
trellis=1ならできる
できるって言っても併用してdeadzone下げても細部は残らないぞ ファイルサイズ微妙に変わったワア程度しかわからん結果になる
グレインも落ちまくりで全然だめ 使うならcrf10くらいで使う覚悟がいる
そんな覚悟を決め込むなら最初からソースのまま残せよw ソースの演出をある程度までぶち壊してまでで圧縮率重視するのなら 多過ぎるグレインは自分で気に入るまで除去しても問題ないと思うがね ぶっちゃけアニメはキャラデザとりシナリオと楽曲でよさが決まる。 背景などのグレインノイズとか別に削っても気にするほどでもないわ。 アニメ1本につき600MBも要するとかバカげているしなw
次の人どうぞ
ダメだこりゃ!
グレイン削る残すはエンコする当人の自由。 加減も含めて好きにしたらよろしい。
>>268 fgoはグレインの付加なんかしないよ
グレインがつぶれ過ぎないようにするだけだよ
おお…
>>291 fgo使ったことないやつが書きこむなよ。
そもそもfgoの利点って何?
>>294 昔D_S氏が作った「グレインを残そうぜ!」のようなアルゴリズム。
後でpsy-rd/trellisで同じような要望が満たされたのだが、主にアニメなどで
「少々レートは多く使ってもいいから、グレインもラインも綺麗に残してくれ」
という望みに対してfgoの方の動作が気に入られてるみたい。
オイラも詳しくは分からないので、知りたい人には
ttp://x264dev.multimedia.cx/archives/25 がおすすめって感じかな。tobinaka氏も説明辺りを翻訳してた気がするけど。
>>287 細部消える事を知らなかった事から論点ずらし必死だな禿w
恥ずかしい奴
今日は粘着多いな。細部が消えない=粘着荒らしが消ない。あまり良い事とは思えないが。
>>287 安直なグレインディテール消しと生ts残ししか考えられないとかどんだけとさか頭なんだよ
にわかはしたり顔で書き込まずに隅っこで小さくなってろ屑
もう単なる揚げ足取りになってる気がする。 グレイン低減したければフィルタでやろうがx264の設定でやろうが好きな方法でやればいい。 グレイン残すのも同じでエンコする当人の自由。
言葉遊び・揚げ足とり・赤ID虐め・スレチで盛り上がり いつになったら正常に戻るんだか
フィルターにはそれぞれ一長一短があるのに長所しか把握せずドヤ顔で語る知ったか野郎は百害あって一利なし 叩かれて当然やな
せやな
(」・ω・)」うー!(/・ω・)/にゃー!(×3) \(・∀・)/レッツにゃー!
グレインノイズを減らしたつもりが微妙な線まで消えてた時の敗北感
そもそも何故にグレインを減らしたいの? サイズの問題?
NL-means + スムージング
307 :
名無しさん@編集中 :2012/04/13(金) 23:50:10.30 ID:g3A1ArnM
r2200
グレイン残していいのかはソースによるな 未来少年コナンのようなもんは全部消してツルツルにした方が綺麗
そもそも264は設定項目が多すぎるんだよ しかも相互に影響し合ってアホみたい 設定項目を3つに押さえて、あとは全自動でできるコーデックを作るべきなんだよ 264なんてごみ
コーデックなんて入ってれば別に設定しなくても再生してくれるだろ。
なんでこのスレにいるの?
x264.exe -o test.mp4 test.avs
今思えばwmvとかdivxとか設定する所皆無だったかのように思える もうあれには戻れないわ
>>309 オプションやパラメータを理解できないバカなら
どこもいじらないでデフォで使えばいいじゃん
つーか、そんなアホがここに来ても時間の無駄
無駄にx264のバージョンアップなんか続けてないで 開発者は次世代コーデックの開発に移ったほうがいいんじゃないか
H.265だっけ? 規格もう決まったんだっけ?
H.265は貧弱なH.264より暗部に強くしてくれ
>>318 そう思うならキミが先導して開発を引き継げばいい。
どうせ誰もついてこないと思うが。
323 :
名無しさん@編集中 :2012/04/14(土) 03:06:04.21 ID:O7tN1c6O
>>322 (」・ωΣC=(−"−)そのうーにゃー言うのをやめなさい!
x264のGOPがデフォルトで250なのはPALのせいですか?
>>315 すげーなお前!x264のオプションをずべて理解できているのか?
8**の頃から追いかけており俺だけど、使わないもしくは弄らないオプションの事はあまり理解できてないぞ?
釣りに条件反射で食いつけば馬鹿丸出しになるのは自分だってことに気が付きなよ
す 8 釣 なるほど、スパッツ最高と。
お前ら早く新revの話しろ
nlまだ2184なんですけど
目に見えて画質向上する事のない新revとかもう飽きた
圧縮率向上といってくれ
目に見える画質向上って意味解らんな 画質、圧縮率、処理速度の三つ巴だし、そもそも画質なんて人間の目をいかに上手く騙すか
まあ更新なんてr数上げたいだけの開発者のオナニーだからな それで構ってもらいたいとかおこがましい
何を言ってるんだお前は
>>330 昔のでエンコして比較すると昔の方がましって事があるからなw
今のところ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 あの耳みたいなふざけた髪形が許せない。なんなのあれ
まともに質問もできないのか
質問をするのにも、それに対する回答を理解するのにも最低限の知識は必要だからな それを下回る馬鹿はどうにもならない
>>344 ためしに24000/1001fpsの動画エンコしてみたら普通にフレームレート23.976fpsのファイルができたっすよ
ああ、でも俺が使ってるのはavs2pipemod、 もちろんx264CLIはx264 rev2192+664 tMod (x264_64_tMod-10bit-all)だけどavs4x264modじゃないから比較にならないか
--timecodeと--timebaseに邪魔なパラメータが残ってるとかじゃねーのか? それともx264.exe以外のexeがそれに対応する付加価値を自動で施しているとか
MediaInfo以外で調べるとどうなのさ
(」・ω・)」うー!(/・ω・)/にゃー!
(」・ωΣC=(−"−)そのうーにゃー言うのをやめなさい!
>>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って何? ぐぐったら怪しげな中国語ばかりでてくるんだけど
別に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はいらなかったなw
サイズが変わるのは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が出てから更新?
テンプレ読め
嘘を嘘と以下略
multimedia.cxドメインはDDNS鯖用だよな。
Another縮みすぎワロタ、なんか設定間違えたかと思ったわ
動く部分少ないし全体的に暗いからね 俺は135MBだった
呪いフィルタでクラスメイトが間引きされてるからな
12話で700MBに収めたw
そんな自慢いらないから
とても自慢には聞こえないけど
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使ったソフトウェアデコードじゃないの?
やっときたか。チェンジログ解読はよ!
ってまだ情報も無いじゃないですか…
いったいどこをどう見ているのだろう・・・
暗部のざわつき改善がない限り更新なんてどうでもいい
>>421 それ「0」1個多くねぇか?
それだと30Mbpsじゃなく300Mbpsになると思うんだが
High5だとインタレ保持できねえじゃん
>>426 ソースからビルドしているレベルの人はちゃんと追っかけているから、このスレで一々報告は不要
どっかのバイナリが更新されたら言って
d
久しぶりにPS3で再生してみたらmp4catで結合した部分にノイズ出るようになってるな。 これがPS3の問題なのかmp4catに問題あるのか解らんわ。 PCやiPadなどではまったく問題ないからPS3側の問題かなぁ?
気になって色々と再生環境変えてみたけど、どうやらPS3が最初のキーフレームを 拾えなくなってるっぽい。 どのファイル再生してみても2つめのキーフレームまでは 画面真っ暗なままスタートする。 だからmp4catでつなげた部分も上手く再生できないっぽい。 これは困った。
別のソフト使えばいいだけじゃね
記憶が曖昧なんで信頼性は低いけど edtsに非対応だからって話だった気がする。
edtsねえと駄目じゃんとか初期から言ってる人ちょっとだけいたけど みんなガン無視だったなあ
ガン無視だったのはPS3()だからじゃ
x264の設定を晒しているサイトを見ると、--vbv-maxrateと--vbv-bufsizeを指定する意義とは何なの? PC以外では見ないという場合は、指定しなくてもいいのではないかと思うんだが…
そう思うならお前はそうすれば良い
そのサイトで聞けばいいだろ。
>>441 それで合ってる
PCで再生するならそれらは指定する意味はないだろう
もともとストリーミングで回線しょぼいサイト用のオプションですし
その昔、インタレの再生支援使う為に付け始めて今もそのままなんだが 今は要らんの?
BD規格用途とかもあるでよ
>>441 それを使う意味はビットレの制限だろ。
実写でcrf18とかにしているとぐんぐんビットレを消耗していくので
そのパラメータを調整することである程度まで制限できる
だいたいDVDのビットレぐらいは確保しておいた方がいいけどな
>>438 あー…なんかそんな話あったね。
未だに非対応なままなのか…。
気になって調べてみたら今ネット上に残ってるmp4catって
edts対応前のやつしかないんだな。
対応済みのやつが手元にあるけど必要な人いたりする?
あげていただきたいです
>>452 mp4catはGPLライセンスで配布されているので、ソースコードも下さい。
rarの中にライセンス関係のドキュメントが入っていないのもおかしいです。
Seraphy産はそういうの完全無視してるんじゃなかったっけ? いっときモメてた気がする。
少なくとも自分の手元にあるmp4cat_20100306にはgpl.txtとLicense.txtが同梱されてるけどな。
俺の持ってる奴にも同梱されてるな どこで拾ってきたのやら
ソースコード1万円で売ってあげるよ
風呂入ってて思い出したけど 掲示板のやり取りでカスタマイズしてもらったやつじゃないかな。 結構フレンドリーに対応してたし
それはひょっとして左のタマを洗ってる時に思い出したんじゃないかな
確かにmp4cat_20100306とハッシュも一致するね。 よく理解していない可能性もあるからはっきり言っておくと、 ソースコードの提供ができないのに再配布するのは明らかにライセンス違反。 親切心のつもりなんだろうけど、ソースコードが提供できないのであれば、早く配布をやめないとまずいと思うよ。 特に今回の場合は色々と影響が出かねないということを忠告しておきます。
ソースが欲しい人はseraphyアットマークseraphy.fam.cxにメールすればいいじゃん
GPL厨は氏ねばいいのに
どっちかっつうと本人を気遣ってあげてるんだが・・・。今の状態はもろにバカ発見器にかかってるわけで・・・。
もういい黙れ
>>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にしてたわ。てへぺろ☆(・ω<) 」
>>491 これはzonesの部分だけなのかzonesを使ったエンコはすべてmbtreeが無効になるのかどっちなんだろう
>>496 ソースを見ると常に無効にしてたみたいだね
Ivy BridgeのAVX2対応は次の更新かね 何処まで早くなるのか楽しみだ
早くなるより時間掛かっても綺麗になって欲しいな CPUの負荷が下がるメリットで他のソフトでQSVと同時エンコしたい
早くなった分、設定詰めて綺麗に出来ると思うけど… それに、x264以外で綺麗にエンコ出来るアプリあるか?
遅くしてCPUの負荷下げるとか折角高性能PC組んでもつまんな杉
AVX2はHaswellからです
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 等を明示的に指定しないとならなかったようですが、 今は、とくに指定せずとも、インタレソースだと認識すると フィールドオーダーも自動で妥当なほうを選択しインタレ保持してくれていると思います。 で、色々な映像の5分くらいのテストファイルを作り、 --crf 等をどうするか試している間は問題なかったのですが、 いざ本番ファイルをエンコしようとするとインタレ認識がうまくいかない? それどころか fps も 569/1001 とか変な値に。 TsSplitter かけたり Murdoc Cutter で先頭を削ったりしても状況変らず。 そもそも適当に切っただけのテストファイルは全部問題なかったのに、 本番ファイルは全部ダメって何事? 違いは長さくらいしかないはず。まさかとは思いつつ、 3GB のソースを前半のみ 1.5GB に切ったら正しく認識されるように! ……という感じなんですが。 明示的に --tff と --fps を指定すれば一応インタレ保持でエンコできるんですが、 先頭 GOP が崩れてしまいます。 ソースを正しく認識できていないのだから、ほかの部分も大丈夫なのかどうか。 使い始めて一週間くらいの初心者なので、とんでもない勘違いだったらすみません。
>>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 未満のインタレソースで試しましたか?
つうかソースの読ませ方等の手順やエンコオプションも書かずに話を勧めてたらグダグダになると思うんだが。
何が聞きたいのか分かり難いわ 使用リビジョンも書いてない癖にx264のせいにするわ 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 その部分だけ切り取るんじゃなくてちゃんと一文として見てみ
ゆとり教育開始当初x264スレで英文法教える事になると誰が予想しただろうか
>>529 これに関してはID:ZbnvEXLPの解釈で正しいだろ。
「このメッセージが出てるんであれば」--iffが自動的に指定されている
(英文もそう言っている)
MediaInfoあたりで見れば、ちゃんとMBAFFになっていて
interlaced=iffがついてるのも分かるはずだ
適当なインタレ素材を(Avisynth等を使わずに)直接読ませればこのメッセージが
拝めるはず
みなAVSから読ませてるから、--iffや--bffは必須だと思ってるんだろ
AVSの場合はAssumeFieldBasedあたりを使うかなにかしないと、インタレ素材と
判断しないみたいだな
iffじゃないtffだ、しかも三回も間違ってるし…… 誰かつっこんでよぅ
みんな優しさにあふれているからな。直しに帰ってくるのを待ってたのさ
ツッコミいれる以前に文字数多過ぎて読む気が失せる。 しかも書いてる内容はhelp読めばわかるだろ的などーでもいい話だし
>>538 どんまい
結論としてはMurdoc Cutterでブツ切りにして
MPEGとしてはぶっ壊れた動画データを直接読ませたのが原因で
そんな物想定されてないからって事でおk?
どっちにしろ何かしらフロントエンド使った方が色々楽だから面倒臭がらず導入しんさい。
無いとは思うが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を読み込んだという話でしょ。
ビルドしたらワーニンだらけで怖い
そりゃカンニン
>>545 nlで配ってるx264バイナリってlibav、ffms込みでビルドされたものなんじゃないの?
nlのビルドはなんでも詰め込めばいいと思ってんのかね。 exeのデータ量増えるだけでメリットなんて殆どないだろうに
>>552 ごめん、今もそうなのかとちょっと気になっただけ
556 :
514 :2012/04/26(木) 06:25:40.43 ID:dIelpp6F
昨夜は、レスが沢山付いてテンパり、ぐだぐだになってしまい申し訳ありませんでした。
この fps やインタレ状態の自動判定は、
x264.exe をコマンドラインで使った場合のみ行われるということですね。
判定を見て自動的にオプションを付けたことにする処理自体は、
>>529 のメッセージで頭に x264 とあるので、x264 側でやってるのかな?
フロントエンドを使った場合でも、
最終的には x264.exe にコマンドラインで渡されると勘違いしており、
誤判定されていると明示的にオプションを付けてもエンコ状態に悪影響があったもので、
ほかの方も知らない間におかしくなっているかもと、でしゃばったことをしてしまいました。
やはり初心者スレにするべきでしたね。本当にすみませんでした。
なお、もうどうでもいいことっぽいですが、「2GB を超えると」というのは間違いでした。
1GB 未満でも誤認識されるファイルもあり、さっぱりわかりません。
557 :
514 :2012/04/26(木) 06:26:10.41 ID:dIelpp6F
>>541 フロントエンドは考えたのですが、デュアルステレオや字幕を残したいと思っており、
それをなるべく自動的に行う方法を確立するのが自分には難しそうだったので、
コマンドライン&バッチファイルに逃げました。
音ズレについては嫌というほど目にしていたのでそのへんは大丈夫です。
元々前後カットしかする気はなく、多少のゴミも気にしないので、ラフにカットしたあと、
ts2aac で音声を抜き出し aacedit でズレを修正、
Caption2Ass_PCR で抜き出した字幕と共に
mp4box で合成というかたちで一応確立してあります。
しかし、肝心の映像エンコに不安要素が出てきてしまったので、また考え直しですね。
>>553 俺もメリット無いと思うしx264のバイナリに色々ライブラリ組み込むのはむしろ気持ち悪い・・・
もちろん必要なライブラリがある人は組み込めばいいけどさ
ていうか--fgo を有効にするとビットレの消耗が増えてfpsでねぇんだな。
エンコって電気代高いの?
エンコ中、ずっとCPUを100%使い切れたなら多少高いだろうな
ハイエンドグラボは負荷かけると下手したらそれだけで400Wとか食うけどな それでもこたつとかハロゲンヒーターよりは電気食ってないわけだが
瞬間的なワット数よりフルロードの時間じゃね?
>>194 この人みたいなエンコをやってると相当電気代かかりそうだろ。
早くエンコが終わるからそうでもない
r2197は画質変更無しかな。
猫科カモ〜ン
画質変わらんなら2164で行くわ
差を定量的に確かめたくなるのがエンコ中毒者
ビットレート ssim psnrと気になるシーンを2、3ソース抜き出すだけ
571 :
名無しさん@編集中 :2012/04/27(金) 02:30:52.79 ID:WpCW775U
せっかく、新しいリビジョンが来ても そのタイミングで基地外が暴れたんじゃ興醒めだな…
はい
はいじゃないが
せっかく、新しいリビジョンが来ても そのタイミングでスグ切れる痛い人が現れるとドン引きやな・・・
同じものをほぼ同じような条件でエンコしても 比較するとざわざわした誤差が出ますが まったく同じ条件で複数エンコした場合は誤差は出ないのでしょうか?
SSIM値の誤差は軽微だと思うがまったく同じにはならない。多少の誤差は生じる。
vbvとマルチスレッドを併用すると再現性がなくなるんじゃなかったっけ
>>576 今まったく同じ条件で3つエンコしたけど同じファイルが出来たよ
SHA-1:40で3つのファイルの値が一致した
vbvもマルチスレッドも使用
それ偶然だろ
こんなこと嘘ついて何になるの 3つじゃあれだから10個同じ条件でエンコしても全10ファイルのSHA-1:40の値一致したよ てか同じ条件でエンコすれば結果が同じなのは当たり前では? もし違ったらx264のプログラムにランダム処理が含まれてることになってそれは大問題なんじゃ…
CPUの負荷やメモリの使用状況で多少並行処理のしかたが変わって 必ずしも一致しない可能性は無きにしも非ず
PSNR・SSIMの数値の違いで判断すれば簡単なのになぜそれをしない?
>>581 検証とかがあると荒らす人が常駐してるんだ、すまんね…
AFS使ったら絶対に一致しない 関係ないだろうけど念の為
586 :
名無しさん@編集中 :2012/04/27(金) 18:49:56.86 ID:D1tv2gkr
馬鹿には無理な仕様です
マジレスすると@pagesの管理者がドメイン更新だかなんだかを忘れてだな
身元を明かしてライセンス違反のアップロード等の行為をしてる奴が同僚にいたら 忠告してやめさせるし、聞き入れないなら上司にも報告して処分も検討するが・・・。 大袈裟だとは思うが意識の低さの表れだし、ゲームだかで業務としてプログラムに関わったことがあるなら尚更。 ちょっとしたことで勤務先や周囲を巻き込んで炎上して損害を与えかねないってことがわかってるんだろうか。 杞憂ならいいけどね。
>>589 お前みたいなやつがSeraphy氏消し去ったと気付こうぜ。
誰ももうそっちの話してないのに一人で語ってて空気読めてない感が漂ってるよ。
コミュニティ潰して更地にしないと理解しないよきっと
更地にして理解してくれるなら、とっくの昔に・・・
>>589 なんでGPLを作ったかストールマンに聞いてこい
>>589 オコトワリ━━━( ゚ω゚ )━━━!!!!
ライセンスとかアップしたこと自体はわりとどうでもいい。せめてもうちょいうまくやらないと駄目だろっつう忠告だ。
リロードしてなかったんだろう
597 :
名無しさん@編集中 :2012/04/27(金) 23:05:37.81 ID:YW5lSIj7
>>589 会社関係なくね?
お前みたいのを偽善者って言うの知ってるか?
いいぞもっとやれ
確かに空気なんか読む必要は無いよな
ID:KzYZ6hfLみたいな思想の行き着く先は シーシェパードと同じところだと分かってるのかな
ほんと、どうでもいい。
まあここは雑談スレだし好きに続けてくれ
x264が無くなったら次の餌を求めて彷徨うだけさ
x265はやくきてくれ! そういえばh.265の規格が正式に決定するのって今年のいつなんよ?
すまんググったら簡単に出てきた。今年の2月時点の予定では来年の1月辺りの予定みたいですはいサーセン
>>593 ソースコードを見せない奴が嫌いだからだろ
規格に関することだが… BDエンコでlevel4.1の時、vbv-bufsizeの値は何故30000? vbv-maxrateと同じ40000じゃないの理由とは?
2197
パンツの無い桂に存在してる意味があるのか!!
パンツ履いてない桂ならあるかもね
猫科さん毎度お世話になっております 素早い対応感謝いたします
ワロタw
BD用エンコならBD-Rの読み込み1倍速に合わせてmaxrateは36000以下にしたほうが良いような気がしないでもない
なにいってんだおまえ
DVDだって等速の10Mに制限されてるわけだし あながち間違っていはいないでしょ
そのページにはもう少し詳しいのも書いてあるな 読み込み速度 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 違いもちゃんと書いてくれてるんだから、それを読んで好きなほう使えばいいんじゃね。
物理ディスクに焼く時代は終わった ネットワークストリーミングの新時代だよ
そうでもないぞ例えば10MBのアニメのOPを、石版とyoutube上に残すのなら ネットワーク上の方が100年後まで保存されてる可能性が高い youtubeが消えてもどこかの誰かが持ってるかもしれない、世界中にマニアは存在するからな 特に日本のような地震の起きる地域で10MB分の石版を完全な形で残すのは難しい BD1枚分の動画を石版で残そうとするならその難易度は異常なレベル。
持ってる人間が減っただけで、誰かが物理ディスクに保存してることには変わりないじゃん
とりあえず2xxx年に地球が核の炎に包まれた後でも残る方式で頼む
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の方がまだ良いと思ったんだけど上位互換ぐらいにはなってくれた?
言ってる奴の設定を是非晒して欲しいもんだなw当然x264のリビジョンも
誤爆
aq=3は別にヨブさんのものではない BM氏のpatch
漢は黙ってnlの最新rev patch追っかけてもどうせ見ることもないし、画質なんてどうでも・・・
前はnlのバイナリ使ってたけど、自分でビルドした方がちょっとだけエンコ速度上がったからそれ以降自ビルドで エンコ速度には関係ないんだろうけど、nlのバイナリは余計なライブラリ詰め込んでて気持ち悪いし
自分に合った-marchとか使えば早くなるかもね
弥生ちゃんを引くなんてとんでもない
今のx264って最大何スレッドまで対応してるの?
確か255
実質無制限状態なのか XeonE5で2-way構成したくなってきたぜ・・・
やっぱグレインノイズが入ると膨らむなあ
ZETMANとヨルムンガンド。この2作品のグレインノイズは異常。 ファイルサイズが縮まないので面倒だからRemoveGrainできれいにしてるわ
>>656 ZETMAN@MXはNR無しでもめちゃめちゃ縮むけど…
あっちこっちとほとんどサイズ変わらない
スタイリッシュな新プレイヤー導入でアニオタ勢力の一掃を図らんとするニコニコ
ニコニコはもうプレミア・アカウント消したし見ないわ。 もともとあそこは色々と質が悪いからなぁ
ニコニコ始まった頃はよく見てたなぁ サービス始まって1年くらい経つ頃から質の悪い動画増えすぎで殆ど見なくなったけど
ニコニコプレ代をpaypalで払うと勝手に定期支払い作成しやがる で、知らずにそのままほっとくと毎月勝手に引き落とされる ほぼ詐欺やん
2525スレでやれ
>>659-662 はJEEB氏の自演 あそこの辞典みたいなのに自分の記事書いてるぐらいだしなw
何でもいいよ ヨブさんいつも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‐、-、-、r, 、 ', |:.:.:.:.:.:.! ! !:.:.l ,. -‐ゝ/// 〉 〉 〉 〉 〉 ! ', l:.:.:.:.:.:.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
ID変えるのに少し時間が掛かったか?
>>684 そう思うならそう思っておけばいいけどもう少し楽に生きたらいいと思う
よくわからんけど、L-SMASHでトラック取り出したり削除したりカットや連結したり MPEG-4 ASP扱ったりできるんだっけ
最近のビルドでは確認していないけどL-SMASHが字幕やttxtのチャプターに対応したらmp4boxから移行できる
LAVSplitterを使うならmp4box使え L-SMASHでは正常に再生できない 詳細は総合質問スレを見てくれ
俺も字幕まわりの実装次第ではl-smashに移行するのもいいと思ってるけど今のところはパス まあ素直にmkv使えよって話かもしれんが
L-SMASHを使うのは物好き・・・というよりものぐさな連中だけ
L-SMASHってコンテナにフォント埋め込んで字幕表示とかできる?
字幕は面倒臭いとか言いつついつか対応してくれると信じて気長に待っています
オープンソースなんだから誰か暇なやつやればいいのに
字幕が使えなきゃ使い物にならん
mp4boxだけど -add "hoge-adts.aac":mpeg4 とやってiOSデバイスできちんと再生できてるよ
mp4boxも色んなリビジョン有るからねぇ…。
気がつけばHDD内に3つ4つあって、どれがどれやら
MP4BoxはよくわからんからPOP@4bitさんとこの0.4.6 2010/10/22ってやつをずっと使ってるわ
700 :
名無しさん@編集中 :2012/05/05(土) 01:26:26.76 ID:Z7ceWBIJ
-‐''''"´ ̄``ヽ、 ____ / _ ヽ //´ __,,>、 /  ̄ ̄ { /::/ / ̄:::::::::::::::\ 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‐、-、-、r, 、 ', |:.:.:.:.:.:.! ! !:.:.l ,. -‐ゝ/// 〉 〉 〉 〉 〉 ! ', l:.:.:.:.:.:.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を指定するのか、今現在、もっとも確実なようですが、これでいのでしょうか
初心者質問スレで質問するつmりでしたが誤爆してしまいました。 ここでもいいですか?
>>708 ありがとうございます。そちらで聞いてみます
ハードウエアとの互換性を犠牲にせずにMP4に副音声を格納するには、 音声をgroup=1でまとめ、副音声側にdisableを指定するのが一番確実でしょうか
ごめんなさい
なんだなんだ??
小清水は
1440x1080i放送の旧作の再放送アニメはさらに上下左右に余分な枠がはいるんだが おまえらこういうのってcropして除去してる?それともオリジナルのまま残してる?
最新のにしたら予想ファイルサイズも出るようになった 地味に便利
717 :
名無しさん@編集中 :2012/05/07(月) 22:34:40.80 ID:b/GuBx3A
ナ ゝ ナ ゝ / 十_" ー;=‐ |! |! 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 ,./´ " ``- 、_J r'´ u 丿 .l,... `ー一''/ ノ ト 、,,_____ ゙/ /.. ── | ── .|`─ 'っ - ´| ./__ ー7 /、 l '゙ ヽ/ ,. '" \`ー--- ",.::く、 | ── | ── |.____) / /;;;''"  ̄ ̄ ───/ ゙ ,::' \ヾニ==='"/ `- 、 ゙ー┬ '´ / \.____|__) / ___/ 、 .i:⌒`─-、_,.... l / `ー┬一' ヽ :l / , ' `ソヽ /l \/\| \ ヾヽ l ` `ヽ、 l ./ ヽ l ) ,; / ,' '^i━(t)━━l | | |
あ、ごめん L-SMASHの方だった
ヽ(・ω・)/ \(.\ ノ 、ハ,,、  ̄  ̄
taro氏だろ
patchでそういうことができるのか ファイルサイズを予想したい時は本番のエンコオプションから--meを下げるとかしてエンコ速度上げて一通りエンコしてる ちょっと時間はかかるけど予測結果は当たらずとも遠からずってところになるし
%出るからそれまでのエンコ済みサイズ元に大体を予想しながらしてたけど地味に便利
>>722 それなら2passで似たような事を自動でやってくれ…うわなにをstwいぇお@
crfの決定はオークションの入札に似ている。 上げるべきか上げないべきか 予算<容量>次第
あれは単に現在の平均ビトレを再生秒倍してるだけで、予想とかはしてないぞ
でもって一行の文字数が80文字(端末の標準)超えるもんだから改行入っちゃって、
キャリッジリターンしても上書きが効かなくなり、
>>194 みたいに騒いだりする
iOS 5.1.1 will come soon
そろそろエンコシコシコしないと溜まりすぎて駄目になるう
電話番号8264のオレ歓喜
えっ
おしりスーン
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無効でエンコされてんだが
外人がただの情弱なのかアホなのか理由がわからん
割れ厨は死んどけ
正規品買ってねって事だよ
いや、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やなw 現に今MPEG2な時点からして悲劇が容易に予想されるんやなw
--tuneオプション自体廃止した方がいいと思うんだ よくわからないまま適当にtune何たらでいいかって感じでとんでもエンコ量産・・・こんなオプション今となってはデメリットしかない
他人がどうエンコしようが別に関係ないだろ そんなん気にするのは割れ厨くらいだ
--tuneはパラメ調整のベースにはちょっと便利
ないない
ただし初心者向け
ベースはデフォルトだよ デフォルトでエンコして要件満たさないところがあるなら各オプションを調整すればいいのであって 初心者が--tune使うなんて危険極まりない
そっすか・・まあ俺も必要ないから使ってないけど
--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
俺はココで教わった通りにデフォで始めて 失敗する度に設定を教えてもらってパラメタ決めたけど 最初に--tuneで始めても結果は同じだったかも? しかしデフォ設定だったから初質にresが付きやすかった気もする 他の初心者の人がパラメタ晒して--tune使ってると 先ず"--tuneヤメレ"って言われてたし
preset否定派はたいてい経験1年未満の初心者
>>575 BT.709->BT.601変換はしてないんでしょ?
ならBT.709のままでいいよ
colorprimとかtransferは要らないと思うけど
7Mレベルかよw
BT.709のままだと再生環境によっては色が変わっちゃうけどな。 前提条件とか全然書いてないから知らんけど。
769 :
757 :2012/05/17(木) 00:08:18.19 ID:7Qyk71nz
再生は専ら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 うん。判定例の1つとして挙げただけね。
IRC用だったのかopencl x264まだ不安定なようだけど anand以外ベンチないのかな
>>775 CPUをまったく使わないでやって見せてくれたら信じるわ
A10にわざわざハードエンコチップも積む時点でAMDはぶれまくりであてにならん
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 手を壊してどうする
>手を壊してどうする えっ、自転車でよくみる「ハンドブレーキ」だろ。 どこをどう読むと手を壊すことになるんだ?
お前はcoffee brakeでコーヒー壊さないのかよ。
お前ら暇ならopencl版試せよw 06_taroで検索か自作板のほうにリンクあるし
DGDecNV用のGT520しか無いし
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万ユーロで足りる?
そんな買収になんのメリットがあるんだ?
だから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でやってる 映画の尺の半分程度の時間でエンコードできてる ちなみにエンコードした映画はまだ一度も実際に視聴したことがない
次の方どうぞ
> ちなみにエンコードした映画はまだ一度も実際に視聴したことがない この人、アホですね。視聴しないなら消せばいいのに
世間では割りに普通の事だぞ だいたい、エンコが無事に終わったのならそれで十分だろ 視聴する理由がない
じゃあエンコする必要もねえだろ エンコするだけして見ないとか電気代の無駄だ
いや、だからなんでエンコしてまで残そうと思うんだ? しかもエンコしても視聴さえもしないなんてw そういうレスを見るとどこぞの違法動画配信者みたいなオーラが漂ってくる。 自分は視聴しないがエンコだけは誰よりも先に済ませておくみたいな。
キレイにエンコできたらそれで満足だろ? それ以上の理由なんて無いよ
エンコしない方が綺麗ですが
誰にも迷惑かけなければ趣味は何しようが勝手 でもまぁわざわざ書き込む必要はないわな 誰かに知って欲しいのだろうけど
831 :
名無しさん@編集中 :2012/05/19(土) 13:40:31.61 ID:kh3hhPV3
おお… 生tsが一番高画質と思ってるのがいるのか
そして単発ID
俺は放送時にリアルで見て録画もしてエンコもしてるけど エンコした分を見直すのは10回に1回もないなぁ。 友人からは電気代の無駄と言われるw
IntelでもAMDでも良いけどx264からHWエンコ出来るようにしてくれ 遅くて敵わん
えっ
x264からHWエンコ?
x264スレにまでν速民が来始めたか…。
>>826-827 服買ってもほとんど着ずに増えるだけな人とかいっぱいいるだろ?
あれと同じで録画するだけとかエンコ後放置とかもごく普通に(かなりの人数)居るってだけの話だ
ゲームで不毛に消費するとか食べ歩きで外食三昧とかと同じで単なる趣味だな
そんなのと一緒にされたら何万もかけて環境を構築している録画廃人達が暴動を起こしかねないぞ。
?
842 :
名無しさん@編集中 :2012/05/19(土) 17:49:44.53 ID:BuW4P+Bv
x264ってAVX命令使ってる?
使ってる あんまり効果は無いけど
845 :
名無しさん@編集中 :2012/05/19(土) 18:10:57.19 ID:BuW4P+Bv
当然WIN7です オプションとかしないでも勝手に使ってくれるのかな?
勝手に使う 逆に使いたくないなら--asm
847 :
名無しさん@編集中 :2012/05/19(土) 18:15:04.92 ID:BuW4P+Bv
おおx264賢い あざす
>>840 録画廃人は大抵貯めるかエンコまでだぞ。
AVX使うといってもほぼ128bitの3オペランドだけだろ
x264のopenclってradeon専用なん? radeonとgforceどっち買うか迷ってるんだけど
迷ってるのならgforceにしておけ。CUDAも使い道豊富だが High10より上の動画再生時に使うLAV Filterとかでも役立つしさ ただし電気馬鹿喰いなのもあるからそこは注意な。
再生支援とかいらねえw cuda欲しいのってフォトショ使う人ぐらいなんじゃないの
この板的にはTMPGEncやDGDecNV使いでしょ
TMPGEncこそイラネ。ロゴ抜きひとつできないゴミツールだろう。
そんなこと言ったらx264だってできないだろw
High10より上って言われても16bitの動画とか再生しないしなあ LAV Filterとかは好みの問題な気がする
>>855 x264はAVSと組み合わせればロゴ抜きできるよ。
delogo.dllでぐぐれ
わざわざTMPG使う意味がない有料ベンチソフトだろあれ?
>>861 お前の「CUDAも使い道豊富」のフォローしてやったんだろw
ヘンなやつだな
何がだよ。そもそも
>>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のほう見てくることをすすめる
868 :
名無しさん@編集中 :2012/05/20(日) 13:54:06.13 ID:5sFiboSR
要するに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 同サイズだと画質劣化するって事か・・・使えねーw
>>873 PSNRやSSIMを書いていないからそれは分からない。
ファイルサイズが増加した分は向上しているかもしれないし。
>>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. アニメーション動作するL時逆コ字を綺麗に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. 一括処理用のバッチファイルを保存して、エンコ開始。あとは寝て待つだけ。
[所要時間は・・・ってしつこいよなw]
ちなみに30分番組のアニメ(1440x1080i -> 1280x720p@VFR)だと
エンコが終わるのは15〜20分程度かな。
ま、x264を使うにせよバッチファイルを作ってまとめてやらせた方が気が楽なのは確かだよ。
GUIフロントエンドとかでマウス操作してパラメータ渡しでx264エンコさせるのも邪魔くさいし。
>>893 文句も何も、わざわざTMPGEnc使ってるって言うから
どんなすごい処理してんだと聞いて見たらCMカットだけだったってオチだろ
CMカットってSUGEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!11よね
めんどくせースレだな
ここはx264のスレ 編集の話題はスレチ こんな簡単な事も理解できないアニヲタ
x264エンコするにしてもそれ以外で何か編集するとしても とりあえず自分でバッチ作ってみなよ。 作るのは面倒だろうけど一度バッチが完成しちゃえばその後の作業が格段に楽になる
時間を短縮するための自動バッチいじってる時間が100時間超えて本末転倒な人とか多いはずだ 基本何も無ければ完全放置なんだけど、新しいオプションやツールが出る度に自分のバッチに取り入れたくなるので いつまで経っても弄り続けているのであった
新しいオプションやツールもそうなんだけど むしろ知らない既存のものを取り入れる機会の方が多いよ。 こんなのあるならもっと早くバッチに組み込んどけば良かった・・・と
>>899 別にアップするのは構わないけど、動作環境揃える自信あるの?相当あれこれEXE使うよ。
もちろんレジストリも弄るし、OS依存もあるだろう。扱うファイルはEXEとかPerlとか
cygwinとかdllとか全部ひっくるめて、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とか全部要らないよ。
>>908 ・無指定(=medium) film crf 20
・veryfast film crf 20
前者の実写の場合エンコ時間が長すぎると思うのです。
同じcrfなのにveryfastのほうがSSIMよくてビット少ないという逆転現象起きる場合もありますし
エンコ時間も数倍早いので無指定はちょっと
2つ質問があります
1、固定品質・固定ビットについてはわかりますが固定量子化の量子化とはどういうことですか?
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エンコはまだ始まったばかりか
打ち切りフラグ立てるなw
しかし開発速度によってはdark_shikari氏の次回作(x265)にご期待ください!になることも十二分にありえるな。 h265が主流になれば互換性以外の問題以外でh264は使われないだろうしそっちだけ頑張ってくれればいい
未だにflvやらmp3やらが残ってる現状見るとなぁ・・・新しい規格はライセンスの問題もあるし
粗悪なエンコーダーだとh265の癖にx264より画質悪いって状況もあり得るなw h264の画質もピンキリだしな。x264の画質は1世代分位進んでる気がする
>>916 おまえの脳中ではx264という規格が存在するのか?
はらたいら『 「規格なんて文言はどこにも含まれていない」などと反論がくる。に、1000点』
三拓にしておくれよw 「x264は、規格かエンコーダーか両方か」 女王あけましょう、ドン!
H264の規格に沿ったフリーのエンコードソフトがx264と理解している
規格が良くてもエンコーダが糞なんて良くあること最近だとWebMとか
ssimでは確かx264のデフォ抜いたんだっけ?-tune ssimでは知らんが
DS氏やら協力してるし今月だったかアップデートされてる DaalaのほうじゃDS氏の名前見たけど265は何も決まってないんじゃね opencl化かアセンブラで最適化しなきゃ遅くてまともに使えんだろうし
snowを忘れてもらっては困る
鬱だsnow
x264.nl の2197にうpデトしたら 同一ソース/設定で300MB超もサイズが大きくなったでござる。w
BD-XL4層用に100GBの動画つくったら2197で300MB超もサイズが大きくなったでござる なら誤差範囲内だな
そんな動画作っても中身がつまらなかったらすぐ捨てるのがオチ
なんで
>>928 みたいな奴は、いつもファイルサイズの絶対値を併記しないんだろうな。
同じようなパターンで、「〜にしたらエンコ時間が20分伸びたw」とかいう奴も居るな。
馬鹿じゃないかと思う。
怪しい通販のうたい文句かよと(ry
r2200
934 :
名無しさん@編集中 :2012/05/23(水) 19:17:36.60 ID:HdvvwifR
おお…2200
2200にしたら宝くじ当たったわ
936 :
名無しさん@編集中 :2012/05/23(水) 23:39:53.33 ID:W8RT8kfY
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入れてたけどそんな謎仕様だったとは
質問は良いけどもうちょっとチラ裏と自論削って文章纏められ無い物か…。
読む気にならん スルー
さんきゅう インタレ偽装ねやってみる
バンディング関連の改善が今回も無かった。 MPEG2 10bitで保存の日々が続く...
釣りなんだろうけど、Mpeg2ならTS保存で良いよね
Mインポ3 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→高いなら良い。だが、低くても見た目は良い場合がある。デブロック不利。
r22222にしたらBIGで六億円当たりました
2のぞろ目だと確変じゃないからダメだな。 どうせなら3か7のぞろ目で頼む。
>>952 Aviutlでロゴ消し→vfp→TMPGEnc→MPEG2 10bit
・バンディングなし
・再生互換性問題なし
x264の場合、MPEG2と同じ程度まで圧縮率を落とさないとバンディング消えないし
圧縮率低いなら後々扱いやすいMPEG2の方がマシという結論
フェードありのロゴはそれではうまく消えないんじゃない?
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でのバンディング関連の改善に期待
970 :
名無しさん@編集中 :2012/05/26(土) 21:13:21.39 ID:DTkuuK0T
こんなに経っても暗部もバンディングも改善されないんだから 今更改善する気なんて毛頭ないだろ そんな事にも気付けずにポカーンと口あけて待ってるとかアホ杉
じゃあ報告頼むわ
暗部もバンディングも前処理と設定次第
糞ディスプレイでバンディングが〜云々言ってたら笑うな
fushizenにあるJEEB氏のx264とx264.nlにあるx264は何が違うんだろう
fushizenのほうは更新遅かったよ2200になるの
2200不具合あるな
不具合?またDxVAで崩壊するんか?
DXVAだろう。なんでDxVA?
なにが「また」なんだろうな。盛大に勘違いしてる気がするけど。
r2200の翻訳お願いします
psy-trellisの適正値がよくわかんないんです>< デフォだと強すぎるときいたのですが><
983 :
訂正>< :2012/05/28(月) 04:35:01.96 ID:Cm8M5ZhT
rdoの適正値がよくわかんないんです>< デフォだと強すぎるときいたのですが><
全てに通用する適正値など無い 自分の好みでいい
実写→1以下 アニメ→0.5以下か0 でおk