x264 rev37

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/

　　　 　 　　 r'ﾆﾆニ二二二ﾆﾆﾆ､ヽ
　　　 　 　 　| | 　　　　.＠　 　 　| | 　　　　　　　 　　　ﾄ､＿＿＿＿, へ
　 　　　 rー┤|　　　　　　　 　　 |├､ 　　　　　　　　　ヽ　　　　　　　　　}
　　　 　 |　 　| | 　 　 　 Π　 　　| |　| 　　　　　　　≡三ーーーーｧ 　 /
　　 　　 l　 　 l l 　 　 lﾆ　 コ　　.| |　| 　　　　　　　　≡　　　　／　 ／
　　　　　|　 　 l l 　 　 　|_|　　 　| |　| 　　　　　　　≡三 　 .／　 ／
　 　 　 　l＿＿l_l＿＿＿＿＿＿|_|__| 　　っ　　　　 .≡　／　 ／
　 　 　　 |　/　　,ｲ,へ 丶､ 　　　 　 ﾍ 　　 　 　≡三.／ 　／ 　　　 　　ﾉ|
　 　 　 　| ,' /　/／ 　＼| ＼ ﾄ､　ヽ　',　　　つ　　≡{　 　丶ーーーー'　 }
　 　　　　!j./l　/　　　　 　　 `　ヽﾄ､ヽ } 　　　 　 　　ゝ､＿＿＿＿＿＿_丿
.　　　　　| | .!/.! 　○　　　　○　l l |ヽ,' 　　 ⊃
　 　 　　 l |　| .l/////////////! | !.|
　 　 　 　.| !　| ﾄ､　　,-ｰ¬ 　 .ｨ| .|　l 　 　 こ、これは>>1乙じゃなくてバギクロスなんだから
　 　 　 　 | l　! l　l`　r --.' <j ,'　|　|　　　 変な勘違いしないでよね！
　 　 　 　 | .l　', l　|ｬ-ミ≡彳ｧﾄｲ ,'!　!
　　　 　　.|　|　ヽ| | l　r´ ）/ハy / |　',

http://itunes.apple.com/jp/app/filmic-pro/id436577167
4S以降なら最大1920x1080/30p〜1pまで撮影できるiPhoneアプリ。ただしVFR
AVCで最大48Mbpsで撮影できるのでソース映像としても使える
アメリカの戦没者追悼記念日関係で期間限定無料提供中

　　　　　　　　　　　　　　＿
　　　　　　　　　　 --／　　 ＼--､
　　　　　 　 　 （-┬/　 　 　 （┬-）
　　　　　　　　　ゝ 人 　 　 　 ゝrく
　　　　　　 　 ／ /　‐＼＿／- ヽ ＼
　 　 　 　 　 〈 　｛⊂⊃　'　 ⊂⊃｝ 　〉
　　　　　　　　＼ ヽ V￣￣￣ﾉ ノ ／
　　　 　 　 　 　 　 ー`ー‐一'─ '´

（＾ω＾）ﾉｼ

いちおつ

2200でエンコしたのをMediaInfoで見たら lookahead_threads=1 とかいう新顔オプション？が
勝手に設定されてたんだけど・・機能は何だろう？

ログのが、なんか処理方法を変えて負荷をどうのこうのと・・・機械翻訳じゃ良く分らんｗ

ここか
Threaded lookahead - Doom9's Forum
ttp://forum.doom9.org/showthread.php?p=1576152

マルチ化意味あんの

ソースの読み込みがボトルネックになる程度に軽い設定なら意味あるよ

それなりに速くなるんじゃないかな。こんなこと書いてるし > 例えば、12コアのi7で、--preset veryfastで、1080pをエンコすれば、100%以上速くなります。

処理軽めにすれば効いてくるわけか

ここで言うlookaheadはソースの読み込みじゃないよ
フレームタイプの決定とかを先読み処理で行ってる
なので、他の処理が軽くなるほど効果が増す。

速さ重視で

洋画BD 1080/24p
--preset veryfast --tune film --vbv-maxrate 40000 --keyint -1 --bframes 2 --b-adapt 0 --b-pyramid none --direct auto --trellis 2 --level 4.1
去年のcorei5環境でBD非互換、速さ重視、テレビ鑑賞、見ながらエンコ完了（24fps以上）するために妥協点見つけたらこんな感じになった

速い安い美味い

>>15
速さ重視でtrellis=2ってアンバランスじゃね?

どうでもいい事だけど、
インタレ保持(MBAFF)でエンコさせるとテロップの縦スクロールがブレるんだな
インタレ解除して60fps化させるとテロップの縦スクロールでも全然ブレないのに・・・。
たとえばMステの高速エンドロールとか、ナイトスクープのオープニングとか。

これさえ解決できれば両方ともインタレ保持で短時間エンコできるのになぁ
最悪プレイヤー側の設定でフォローするしかないのがネック。なんかこれ使え的な方法ない？

すいません。勉強中の身なので教えてください。
以下が自分なりに解釈したことです。間違っているラインありましたら教えて下さい。
--------------------
・Constant QP[固定量子化]というのはJPEGのQ95とかQ90とかと同様にソース映像から指定した一定の率でデータを劣化させ圧縮する方法。
展開が早い、劣化の気づきにくいフレームにもビット振るので"真の"固定品質（品質基準、品質一定）モード。
無駄が多いので推奨はされていない。

・Constant Rate Factor [CRF]というのはCQPを改良したようなもので、展開が早い、劣化の気づきにくいフレームで指定したQPよりも大きくしビットを節約する方法。
逆に劣化の気付きやすいスローな展開のフレームではビットを振る。ただしBPフレームを使う場合はこのとおりではない。
その節約具合がqcompオプション、ハネ具合がqpstepオプション
x264が推奨する"実用的な"固定品質（品質基準、品質一定）モード

よろしくお願いします

>>18
最悪も何も
それってデコーダやプレイヤーの設定によりけりでしょ

使ってるGPUがIntelならば悔い改めろ

我らがGeForceを使ってるなら素直にデインタレースすれば良い
再生時にベクター適応が使えないのにわざわざインターレースでエンコするとか一体何の罰ゲームなのか
圧縮率的にも何もメリットが無いのだから何も悩む必要など無いはずだ
インターレース保持エンコなどと馬鹿な考えは今すぐ捨てよ

RadeonならEVRのプロパティにあるVideo Processor modeを3C5323C1-6FB7-44F5-9081-056BF2EE449Dに設定しておけば、プレイヤーやデコーダ問わずきちんとデインターレースされる
にも関らずスクロールがカクついたり、斜め線のジャギーが低減されていない場合はスプリッタを変更する
プログレッシブ至上主義者が関与する一部のスプリッタには、フィールドオーダーを誤って送るという誤爆トラップが有りや無しや

>>19
合ってます。
捕捉すると、動画の大半はP/Bフレームで、これがqcompによって制御されています。
Pフレームを基準点として、Iフレームの品質を決めるのがipratio、
Bフレームの品質を決めるのがpbratioと言ってしまって良いと思います。

>>22
レスありがとうございます
自信がつきました

質問1
非実用目的でCQPTrueVBR(機械的な)を狙う時
そのIP,BP係数がAviUtlx264guiExプラグインだと値が入っています。
この左上は全て0にするのが正解ですか？(もしくはオプション書かない方がいい？)
そのままにして1.3, 1.4にしておくと当然ながらIBPのQPが3つのQP一定になります

質問2
同様に視覚補正のAQやPSY系、mbtreeも切った方がTrueVBR(機械的な)に近づきますか？

質問3
CQPエンコの際40Mbpsを上限ビットとし、それを超える時は
QPを大きくするのを許可するといったオプションは
1passエンコでは予想がつかないために存在しないのでしょうか？

日本語の意味がわからない
--qp 10で試したけど
x264 [info]: frame I:3 Avg QP: 7.00 size: 42268
x264 [info]: frame P:25 Avg QP:10.00 size: 28729
x264 [info]: frame B:52 Avg QP:11.69 size: 8958

--qp 10 --ipratio 1 --pbratio 1
x264 [info]: frame I:3 Avg QP:10.00 size: 30977
x264 [info]: frame P:25 Avg QP:10.00 size: 28880
x264 [info]: frame B:52 Avg QP:10.00 size: 15670

x264 初心者質問スレ part5
http://toro.2ch.net/test/read.cgi/avi/1314616372/
あと移動してくれ

>>23
１：完全に品質一定な動画が欲しいのであれば、pbratioを1.0にすれば良いと思います。
ipratioを1.0にしても良いですが、これは流石に著しく効率を落とす結果になると思います。

２：AQ,mbtreeはMB毎にQPを制御する仕組みで、
レートコントロールに組み込まれているので関係ありません。
PSYに関しては、正直自分も良くわかってませんが、時間軸での処理はされていないので、
関係無いと言えるかもしれません。
ただ、PSYオンの方がビットレートの変動幅は大きいと思われますので、ある意味VBR度は高いかもしれません。

３：上限ビットレートはプロファイル(Level)で定義されていますので、その関係のオプションが使えます。
この場合はvbv-maxrateになります。
1passでも、実際は前後数フレームを確認しながらエンコードされています。(--lookhead)
何も確認してないのであれば、Bフレームもqcompも実装不可能でしょう。

あ、ついでに、--qpを使わなくても、--crf ** --qcomp 1.0で同等の結果になります。

詳しいところまで教えていただきありがとうございます。

まったく理解できないけど勉強になります

mbtree関係無いとか言ってるけどmbtreeがenableだとpbratioの値は意味を成さないんだが

crf、psy、aq、mbtree
全部人間の視覚特性を考量するアプローチのためのオプションだけど
特にcrfとpsy-rdなんてやってること同じなように思える
そろそろ整理するかそれぞれの役割の解説がほしい

crfとpsy-rdのどこがどう同じなんだよ…

>>30
猫科研かまるもの日記でもGoogleでサイト検索してみろ。

エンコ高速化への近道は無駄な計算をさせないこと？効果の薄い計算をさせないこと？
省ビットへの近道も意外とこれ？
時にはオプションを切る？下げることも必要である？ゴミデータが付加されるだけ？
必ずしも上位プロファイル？上位オプション付け足せば圧縮率が向上するとは限らない？
画質と無関係な計算するゴミデータが付加されるだけ？

エンコ高速化への近道 → --preset ultrafast

目的と目標を設定せずに高速化も何もないだろ

@実写ソース
速くてコンパクトにしてみました。CRFからの強制CQPなのは比較がしやすいための実験目的だからです。CRF=VQPは若干低速化します
QP系をほぼ同条件にした上でいつも使っている設定と比較したのち、できるだけ馬鹿にした罵ったレスをください。

--preset veryfast --tune film --profile main
--crf 23 --ipratio 1 --pbratio 1 --qpmin 23 --qpmax 23 --qpstep 0 --qcomp 1
--no-mbtree --rc-lookahead 0 --aq-mode 0 --aq-strength 0 --psy-rd 0:0 --no-psy --keyint 300
--bframes 1 --b-adapt 0 --b-pyramid none --partitions none --me dia --subme 1 --no-chroma-me --no-mixed-ref
--no-weightb --weightp 0 --colormatrix bt709 --colorprim bt709 --transfer bt709 --sar 1:1 --level 4.1 --ssim
--frames 3600 --input-res 1280x720 --input-csp nv12 --fps 30000/1001 -o "P:\005469.mp4" "-"

　　　　　　　　　＼　　　∩─ｰ､ 　　　====
　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　====
　　　　　　　　　　　 ＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

実写でnombtreeとは挑戦的だな

qcomp 1なので無駄な計算をして低速化するだけでした。
なので切ってあります。


同じQPでサブブロック計算有効のものにくらべブロックノイズがでるかもしれません
これはサブブロックを使ってない故なのでしかたがないこと、トレードオフと割り切り諦めています。

インタレ保持じゃないのに 実写で--fps 30000/1001って誰得？

使ったソース映像にふさわしいフレームレートがそれだからです。他に理由はありません

>>40
ソース次第だろ
アホなのか

ところでソース映像は何故出さないんだ？実写にも色々種類があるだろうに
e2 SDの糞ソースとか、WOWOW FHDの良ソースとかさ

使ったのは実写ミュージックビデオBDのAVC1280x720/60p/30~Mbps収録、実質30pだったので2分の1に間引き、30pです

今やってるバレーボールの試合映像でいいじゃん

なんだH264の再エンコかよ。しかも60pを30pにってどんだけエンコ時間節約したいんだって感じだな
実質30pだったってのは単にデコード環境が30fps前後しか出なかったとかじゃないのかい？
BSデジタルのTSソースでもデコード環境が痛かったら60fpsでるはずの映像で30fps前後しか出ないこともあるし

>>46
ミュージックビデオは普通30pか24pだよ

>>46
BDMVで720/30pは規格外で市販BDに存在しない。プログレなら60pか24p
撮影したカメラが30pだったら同じフレームを繰り返して60pで収録してる。24pカメラならそのまま24p収録だろうけど
無駄だからこれを間引いただけ

素直にウェブからもらったと白状すればいいのに見栄はっちゃってもう。

罵るのはいいですがちゃんと買ってます

>>50
気にスンナ
BDの規格わかってない奴はいるもんだ

＞できるだけ馬鹿にした罵ったレスをください。

最初からこの発言を書かなけりゃもっとまともに相手してもらえたんじゃ？

「的外れなことを言ってくれ」とは書いてないですが

あーだこーだ指摘された方がx264を扱う掲示板として有意義だなと思って。
間違いや効率が悪いのならそれは早いうちに直されるべきでしょ。
俺がどこのドイツか分からない匿名掲示板にプライドとか人格の尊重とかいらないと考えてるから罵って構わない

直されるべきなのは分かるが
たとえ最良な案が提示されたとしても
質問した側がそれに従わなけりゃ元も子もないわな。

理想としては>>38みたいに気楽にもっと指摘してほしいのです。

感想と指摘は別だろう。指摘なら自分が思う改善案ぐらい示すものだしな。

固定ビットレートでいんじゃね

CRF450RでもCBR1100XXでもなんでもいいからお前が好きなようにしろって話だよね。

30pは60ｐではなく2：2プルダウンの60iで収録されてる
だからまともな再生環境があれば再生時にちゃんと検出して元の30fpsで再生されるから
I/P変換誤爆の重複フレームによって動きがぎこちなくなったりしないし
24pと違って間引かなきゃいけないような無駄など最初から存在していない
最初から存在していない無駄を間引くとか言ってる時点で>48は確かにBDの規格をわかってない

つまり…どういうことだってばよ

ようするにくだらないパラメータを貼ってまで用意されたネタに対して
盛大に釣りられてどうするよ。って事だろ。

CRF活用版

QP=Xあれば十分な人間が見るとして。実写の高速圧縮>>60
。
理解してない部分もあるのでIとPのQPは同じにしています。
ご存知だとは思いますがBフレで削るのでQPの変化量=Y-X（最大6）が大きいほど、
Bフレ枚数=Z[1-3推奨]が多いほど高圧縮になる一方、違和感を感じやすくなります。
XYZで適宜要調整。真新しいことはやってませんが宜しくお願いします。括弧内は例です。


--preset veryfast --tune film --crf X(23) --ipratio 2 --pbratio 2 --qpmin X(23) --qpmax Y(25) --qcomp 1
--no-mbtree --rc-lookahead 0 --aq-mode 0 --aq-strength 0 --psy-rd 0:0 --no-psy
--keyint (240) --bframes Z(3) --b-adapt 0 --b-pyramid none --partitions none --no-8x8dct
--me dia --subme 1 --no-chroma-me --no-mixed-ref --no-weightb --weightp 0

>>60
それ1080の話でしょ。俺が書いてるの720だから。

日本で見かけるBDMVはたいてい以下
1080/24p　1080/60i　1080/30i　
720/24p　720/60i　　720/60p←>>44

BDMVの規格上720/30pがないから仕方なしに制作会社が30pソースをAABBCCDDDって2-2ハードプルダウン60pで収録していたから間引いただけ
文句ある？>>60

Dがひとつ多かった。正しくはAA BB CC DD EE FF GG HH II JJ KK

>>64
通常その場合は720/60iで2：2プルダウンだって言ってるんじゃない？
MV集なんかはDVD同発多いからそっちのが正しそうな気もするが
そもそも720/?のBD見たことないからどっちの収録パターンが多いかわからんけど

フィールド処理なんかしてないのに、2：2プルダウンとか変な言葉作って威張ってる人ってなんなの？

BDの規格に720/60iなんて無いよ。

うん、ないかもね。1080/30iも売ってるの見たことない
自分でもなぜ書いたのか思い出せない

>>59
CBR250RR復活しませんかね

>>64-68
インタレスレにでも行ってもらえますか？
向こうは来られても迷惑だと思いますが。

>>63
ｸﾏｰ！(AA略
ってことで、毎度ながら --preset ** --tune ** --crf ** これだけにしとけって話です。

管理人でもないのに自治しようとするヤツ

要約すると俺の話を聞けですね
わかります

スレが伸びてると思ったら
かまってちゃんの降臨か...

BASELINE1.3でSUBME=10、11って使っても大丈夫なんでしょうか？
SUBME=8と比べて2割縮むのと、DAP再生では問題なさそうなんでできれば使いたいと思ってます

>>74
trellisを使えないbaselineだとsubmeは9まで。

>>75
ありがとうございます
ということはSUBME=10、11でサイズが減ってたのは
単純に画質が悪くなってたのかもしれませんね；
SUBME=9使いたいと思います

大文字に違和感を覚える

違和感どころではなく、スイッチとして認識しないだろw

規格としては存在しないけど
x264オリジナルの圧縮率向上のためのオプション、エンコ前チューニング、
同調整、レートコントロール技術、最適化、視覚最適化などってどういうものがありますか？

crf, mbtree, aq, psy, adaptb, weightbp, opengopなどがそれに当たりなすか？

それからhigh4:4:4profileには対応する予定ありますか？

色々ひどいので勉強し直してきて下さい

きっと勉強しても無駄なのでHandbrakeでも使ってなさい。

ある程度知っててボケてるだろ

　　　　 (~)　　　　　　　　 , -ｰ,
　　 γ´⌒｀ヽ　　　　　／ 　　|
　 　 {i:i:i:i:i:i:i:i:} 　 　.／ 　 　　.|
　　 .（´･ω･`）　／ 　　 　 　 .|
　　 （　つつ'@.　　　　 　 　　 |
　　 ゝ,,⌒）⌒）.　　 　 .　　 　 |
￣￣￣し' し'　　 　 　 　 　　 |
　　　　　　　|　　　　　　　　　 |
〜〜〜〜〜〜〜〜〜〜〜〜
　　　〜〜〜　　　　　　　〜
　　　　　　　　　〜〜〜

　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ
　　/　　●　　　● |　クマ──！！
　 |　　　　( _●_)　 ミ
　彡､　　　|∪|　　､｀＼
/　＿＿　 ヽノ　/´>　 )
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　 （　 ＼
　　　　　　 ＼＿)

外人はX264どう発音してんの？エックスツーシックスフォー？
ネイティブ発音聞きたいんだけどyoutubeとかにない？

それを知って何に使う？ボイスチャットで外人相手にどや顔するとか？

クロスツインロクジュウフォー

オレの友達のアメリカ人はエックストゥーシックスティフォーって言ってた

H.264をエイチツーシックスフォーって発音してるのを聞いたことがある

かけにーろくよん

x26

､i｀ヽ　　　　　　　　　　　　　 　　　 　 　 　 ,r‐'ァ
　｀ヽ：：　　　　　　　　　　　　　　　　 　　 　 ：：´
　　 ヽ ヽ　　　　　 　 , -‐--､ 　　　　　 　 /　/
　　 　ヽ　＼　　　 　 I:：：：：：:I_ 　　　 　_ /　/　┌────────────
　　　　 ヽ　 ヽ　　　 i,(;;;ﾉI､;;;)l　　　 ,,／　 , ' 　＜ フォォォオオオオゥゥ！
　　　　 　ヽ 　` ｰ ､.,,ゝ´ヮ｀,ﾉｭ_, - '　　 r' 　　　└────────────
　　　　　 　 ` ､_ ／：:: `山'::::：　　 　／
　　 　　　　　　ヽ：::::::::::|:::::::："",r‐'
　　　　　　　　　 〉::::::::|::::::::::¨/
　　　　　　　　　/;;;;;;;/;;;;;;;;;;/
　　　　　　　　/;;;;;;;/:::::::::::《
　　　　　 　　<;;;;;;;《:::::::::::::ヽ　　　））
　　　　　 ／ 　 ヽI,r''"""^~ヽ
　　　　 /　　　,／　ヽ　　　　ヽ

えっくすつー　ろくよん

あかー　あおー　ぐんじょいろー

アイビーはえーなｗ
E8500@4Ghzからi5-3570K@4Ghzにしたら5倍早くなったｗスーパーパイは11秒が9秒くらいなんだけどね〜

π焼きとエンコに何の関係があるんだよ

>>94
お前みたいな池沼はこんな所に来るんじゃねぇ

3930だったら8倍速かったのにね

againagainで無乳を確認！

誤爆です

おお…

僕の環境だけかもしんないけど、subme10だとマシンガンシークした時に高確率で音ずれが起こっちゃう
9までは問題ないんだけどなー

偶数は地雷
これ豆な

まじっすか

BSシネマをエンコするなら２０ぐらいでいいですか？

>>104
CRFが？
適当な所で数十秒〜数分ぐらい切り出して、
値変えながらテストエンコして納得できる数字決めたらいいと思うよ。

固定品質で６０ぐらい盛れば三分の一ぐらいに縮むよ

60とか明暗ぐらいしか分からなさそう

グレインの多い映画じゃなけりゃCRF24でも1/3ぐらいにはなるだろ…。
固定品質…もしかしてペガシススレの住人か？

シャインだろ

東京プリン

明暗が根暗に見えた

BSの1920*1080で16GB、2時間程度のtsソースを、ts2aac→FAW(1/2サイズ)、aviutlでtsを読み込み、音声にFAWを読み込み、CMカット、x264guiExでエンコード。
aviutlの時点で再生ウィンドで確認する限りは音声も読み込めているようで再生されている。
しかし、生成されたmp4は音声が出ない。
ちなみに、同じ設定、同じ手順で地上波の5分ぐらいのソースをエンコードすると問題なく音声もでる。
かれこれ４回ほどエンコードし直してるんだけど、全て同じ結果。
原因がわからないんだけど、何か心当たりのある方いませんか？
アドバイスください。

x264が問題というわけではないと思う
aviutl関連のスレにいった方がいいんじゃ？

なんでx264スレに来たのかが不思議なレベル。

設定は同じ状態で他のソースだとできるもんだから、てっきりファイルのサイズや特性によりエンコード時に影響が出てるのかと。
aviutlスレ行ってみる。
ありがとう。

一般的な1920X1080 4:2:0ソースを4分の1の960x540にする予定の時
YUVのYは4分の1にリサンプリングして、UVはそのままを維持して960x540 4:4:4を作る方法ありますか？
それはまたメリットありますか？実際にやったことある人いますか？

x264スレで聞くより他にいいところがあると思うんだ

>>116
インターレースソースなら即死だ。
プログレッシブソースならデコーダーの出力をそういうように加工すりゃ出来るだろ。
意味なさそうだけど。

>>116
MPEG2Source("source.d2v")
#deinterlace
src = last
Y = src.BicubicResize(960, 540).ConvertToYV24()
U = src.UToY8()
V = src.VToY8
YToUV(U, V, Y)

アビシンスみたいなスクリプトは逃げてきたので、それがなにを意味してるのか理解できるよう勉強してきます
お二方ありがとうございました。絶賛しようよスレに逝ってきます

アビシンス、とカタカナ表記だと、一瞬？となったｗ

yv12の4:2:0って色差信号を縦横それぞれ2x2px単位で半分ずつの960x540でインターレス収録してるわけだから
4:4:4でエンコするなら普通に縮小してもほとんど変わらないんじゃないかな

■■□□■■□□
■■□□■■□□　　→　　■□■□
□□■■□□■■　　　　　 □■□■
□□■■□□■■

なんで色差しか見ないんだよｗ
輝度情報に比べて色差情報の知覚が鈍いからそこの情報量を減らして圧縮してるんだよ。
そんな縮小の仕方で変わらないってんならBDもDVDも同じ画質ってことになる。

>>123
>>116

>>122
普通に縮小して4:4:4でエンコ　じゃ意味無いでしょ
>>119のようにしないと

アンカーだけして自分の言葉も持てないアホはどうでもいいとして
色差だけ4:4:4にして格納すればどうなるかって話なら4:2:0自体が元々それそのものを行ってる規格なんだから全く意味がないぞ。

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

はいそうです

480i未満の低解像度の生TSだとそれをエンコすると余計に劣化する。
MPEG2は多少引き延ばしてもある程度デコーダ側で補正できるからな

>>128
マジレスつまんねーよ

>>126
色差だけ4:4:4ってなんだよ？ >>116の質問は

1. 4;2;0を4:4:4に変換してから960x540にリサイズする
2. 4:2:0を960x540にリサイズしてから4:4:4に変換する
3. 4:2:0を輝度だけリサイズして960x540の4:4:4にする

以上のうちの「3を実行するための方法」及び「1、2と比較して3にはメリットがあるのか」だろ
3は色差は拡大も縮小もされずそのまま使われるから、一番元の情報が多く残る可能性はある
しかし色差の変化は視覚的に認識しにくいから、めんどくさい割にはメリットはほとんど無い、が答えになるだろう

だが、お前の言ってることは明らかにずれてるぞ
4:2:0自体がそれを行ってるってどういう意味なんだ？

なんだか定期的に色関係の話になるよね

ホワイトとニガーの戦いか。

どうしても960x540の4:4:4にしたいのなら
単純に4:4:4にしてから960x540にリサイズしたほうが綺麗だと思うよ

輝度だけリサイズしてクロマ成分だけ拾うと
Yとの相関がずれて残念なことになる

って、x264と関係ないな

元々ずれてんだから気にしない

>>134
＞どうしても960x540の4:4:4にしたいのなら
＞単純に4:4:4にしてから960x540にリサイズしたほうが綺麗だと思うよ

せやろか

1920ｘ1080ソースを960ｘ540にしている時点で明らかに綺麗からは遠ざかっているのに

dot by dotならそうとは限らないだろう

H264AVCでやらなくてもJPEGで同操作やって比較・結論付ければいいんじゃね？

Aviutlで　
MPEG2入力プラグイン 補間なし
補間なしYUY2アップサンプリングフィルタ
area averageで960x540に縮小

これでUV成分はオリジナルが保持していた数値と同じになるでしょ

見た目あんまり変わらんと思うけど

違ったごめん

960x540にする時に半分混ぜちゃうからダメだった

>>119をやってみればわかることじゃないか
実際やってみたら、640x360→320x180ではかなり違うな
サイズが大きくなると大差が無くなるかもしれんが

High444PPを再生できる民生機器が皆無に等しい

PCで再生してHDMIででも繋げばええやん?汎用性半端無いで

fullrangeって使ったほうがいいの？

素材が444で出回るはずがないから意味ないだろ

キャプチャしたゲームのオナニー動画とか見る時に必要だろｵﾗｱｱｱｱｱ

すげー意味なし

>>146
>>116の言う通りにできれば視覚的にどうかとかは別にして420を元にして444なソースになる

>149
的外れすぎる。いつまで意味のない話を続けてるんだ。

ソースによっては同じ量子化係数で圧縮した際420と444では目に見える違いが現れることがある。

写真を444と420で見比べて見ると違うのがよく分かるよね
特にデジタルで塗られてるアニメ絵のようなものだと顕著

ニコ動サイズの大きさに縮小してエンコすれば444でも420でも殆ど差がなくなる。

444は赤色が顕著

著作権法が改正されるとx264もアウトになるのか？
どうなんだろう…

おまえはなにをいっているんだ

まあ最近は殺人に使われた包丁を売った店や製造したメーカーも一緒に罰しようぜ
みたいな話をする奴も多いからそういう発想をする奴が出てくるのもわからなくもない
まあアウトになるはずもない

ペガシスとかどうなるんだろう・・・

1人殺せば殺人者だが、100人殺せば英雄だ

Veryfast Mainがお買い得だよね
圧縮率/処理fps

x264は脱法ハーブみたく何度でも生き返るよ

これからは

　 ∧＿∧＿　　　　　　　　 ＿＿
　(　・∀|[ﾆ:|ol 　 　　　　 　|　i ＼　＼
　（　つ ∩￣ 　 　　　　　　|　i　　l ＝l
　と＿）＿） 　 　　　　　　　|　|__ノ　 ノ
　　　　　　　　　　　　　　　|￣￣|￣￣|

からエンコードするの話しかできなくなるのか

法律の条文がテキトー過ぎて何ともいえないがその方式も何らかの方式でプロテクトを
回避する手段として認識されたら違法になり得るんだぜ

アナログハイビジョンキャプチャー最強説

よし、PT3の次はいよいよPV5か

いつになったら余計なプロテクト掛けて市場をかえって縮小させてると
気付くのであろうか…

娯楽Aの市場を縮小させれば
娯楽Bの市場に可能性が出るから、
まぁ、戦争だわな

自分で撮影したTSソースとか前置きが必要になる時代か
x264新旧比較などUPしているサイトとか大変になるな

>>168
再配布が可能な素材は色々ある。

http://media.xiph.org/video/derf/

自分のプレイしたオナニーキャプチャー動画をエンコしてるのは俺だけか

>>170
某ネトゲのプレイ動画は自鯖にUPしてたや
そのころはwmvだったけどなー

wmvとか時代を感じるな

divx、wmv3、xvid、wmv9…
なにもかもがなつかしい

divxもバージョンが色々あったよな

>>173
divxってどうなってるんだろう？
一時期は家電にまで対応し始めて主流になる勢いだったのに

>>175
数日前にDivXニュースレターってのがメールで来てたな
もう使ってないから中身は見てないけど…

>>119
これをffdshowのAvisynthのところに書く場合どうすればいいですか？

>>177
再生でやるならRGBにしてから960x540にすればいい

実験するだけならわざわざffdshow使う意味なんてないし、
本気でこれが良い方法だなんて勘違いしてなきゃいいが。

>>175
技術系の優秀な人材がかなり前に逃げて（x264周りでその辺の物語を
語ってくれた人がいくつかいた）
MPEG-4 Part2系はもう完全に利益にならないのが明白だった時にDivX社が
MainConcept社を買収してH.264市場へ移動して自分の価値を上がらせた。
Sonic Solutionsが今度DivX社が持っていたMainConcept社を得るために
DivX社を買収。それで今度Rovi社がSonic Solutions社を買収
(Rovi社の元の名前がMacrovision Solutions Corp.)。

まぁ、こんな感じでDivXというブランドは未だに生きてはいる。今技術的な
事は殆どMainConcept買収で得た人材かそれ以後の人がやってるから
全体的にちょっとマシになったって感じかな。2005前後はかなり酷かったと
聞いたけど。

MainConceptって糞やん？

>>181
人材をなくしたDivX社が仮に独自に作ったものよりはマシな出来。
そんなとこかな。

ttp://compression.ru/video/codec_comparison/h264_2012/
効率的にこんな感じかな。面白いのはベースが同じなのに、
DivXブランドのエンコーダーとMainConceptブランドのエンコーダー
の結果がちょっと違ってるところ。

まぁ、MC/DivXよりx264の方が圧倒的に効率がいいのもMSUのレポートを
見れば分かる。

うちの会社はMainConceptの業務用h.264エンコーダー使っているけどそんなに悪くはないよ
品質試験を手伝ったけどTMPGEncとかについてくるおまけとは別物だった
もちろんx264のほうが綺麗だったけどx264は日本では権利関係がめんどくさいと直接の担当者が言っていたな

>>183
まぁ、MSUのレポートを見れば2･3位だしなぁ、企業向け市場で
あの価格レベルではx264とMainConcept以外の選択肢はないと思ふ。

あと、できれば日本での権利関係問題の事もう少しｋｗｓｋ教えてもらえれば
嬉しい。

個人的にx264となると、企業にとってめんどくさそうなところは：
・機能が足りなかったり
　（Pegasys社もFixstars社も独自に色々実装してパッチを送っている）
　【Pegasys社は主にインタレ関連、Fixstars社はMVC関連】
　（x264の非GPLライセンスは誰にもソースを公開する義務を付けないが、
　　x264エンコーダー自体への独自の変更はx264の開発チームへ提供しないとダメ）
・MPEG-LAのライセンシング関連は自分でやらなければいけない
　（Doom9のneuron2氏の経験から見るとそこまで難しくないけどね）
・MSVSでデバッグしたい時はIntelのコンパイラを使用しないとダメ
　（インテルのコンパイラ等にお金ががが）
・MSVCでそのままコンパイルできない・プロジェクトファイルがない
　（一般的なWindows向け開発者にとっては「アウトー！」な問題）
・「今年このキーワードが熱い！なキーワード」がない（CUDA, OpenCL等）
　（今はもうATi/AMDがらみの連中がOpenCLパッチ開発でかなり進んでるけど（笑））

これぐらいかな

＞今はもうATi/AMDがらみの連中

なにこの態度ｗ

なんの問題ですか

>>184
OpenCL対応って進んでるの？
ぐぐって（doom9を）みたけどそれほど活発ではないきがするんだけど
IRCなんかでは違ってんのか？

実用可能レベルのものが出来上がってるのは十分進んでると思うぞ
今まで誰もできなかったレベルだ

>>187
開発レベルの話はIRCがメインでdoom9にはほとんど出ないよ
ペンギン様がログ公開してるから興味があるなら読んでみ
ttp://akuvian.org/src/x264/freenode-x264dev.log.bz2

>>187
このスレ的にはx264のOpenCLに期待しておけと
それとAPUのメモリアドレス共有化にも期待だな

OpenCL版が444に対応したら本気だす

>>190
444に対応することでどういうメリットを期待しているのかちょっと気になる

赤色が綺麗に表示される

>>192
Haaliを窓から投げ捨ててLAVかMadVRを使うと幸せになれる

関係ない

元々無い色成分を補間したってねぇ

>>193
LAVをMadVRに変えたら赤がめっちゃきれいになった
代わりにめっちゃおも区なったけどアスタロッテのおもちゃのタイトルが見違えたわ…

>>196
確かにMadVRは綺麗だがLAVでも赤色は綺麗に補完されるぞ
MPCHCの設定を間違えてHaaliで見てたんじゃないのか？

>>197の言ってるHaaliって、もしかしてSplitterのほうじゃなくてHaali Rendererのことを言ってるのだろうか・・・。
それにしたって意味不明な感じだが。

LAVで補完wwwわけわからん

VLCPlayerはそう意味でも糞

たぶん>>200もなにもわかってない

intelのは分かんないけどnvidiaやAMDの最近のカードは
DXVA2前提の調整だと思うからEVRcustomでレンダリングするのが
無難なんじゃね？
WindowsXPユーザーはLAV経由でDXVAかな？
madVRはAVIVVO()やPureVideoHD()が使えない気がする。

妹の●●●へ×××を出し入れできる「いもうとランチャー」v1.83
http://www.forest.impress.co.jp/docs/news/20120626_542785.html

>>198
その通り、適当なこと書いてすまんかった

Haali Splitter+Haali Renderer・・・赤色の斜め線ががギザギザ
LAV Splitter+LAV Renderer・・・赤色の斜め線がなめらか
Haali Splitter+MadVR・・・赤色の斜め線がなめらか
LAV Splitter+MadVR・・・赤色の斜め線がなめらか

Haali Rendererが糞だと言いたかったのだが間違ってたら指摘を頼む

＞LAV Renderer
は？

>>205
LAV Video Decoder

>>206
スプリッター、デコーダー、レンダラーがそれぞれどういう働きをしているか勉強してから出直してきて下さい

とりあえずスプリッターは関係ないよなあ。
デコーダーについてはデコーダー内でYUV→RGB変換するかどうかが関係してくるだろうけど。

>>207
ちょっとググったら分かったorz
LAVでデコードした時はレンダラーにEVRを使ってたよ・・・

オレにはmediumとslowで画質の違いがわからない
実際オプション増やしていって画質の差が分かる人ってどれくらいいるんだろう？
サイズとエンコ時間が変わったから高画質になった気になってるだけなのか・・・

1.5倍に時間が増えるなら、サイズにこだわらない限り0.5品質下げればmediumでOKな気がしてきた

mediumとかそんなん使ってねえから知らねんだよ

よくわからんので、ミディアムレアで頼む。あとナマ中のおかわりもな。

Anonymousが日本政府とレコード協会に“宣戦布告”　違法ダウンロード刑事罰化に抗議
http://www.itmedia.co.jp/news/articles/1206/26/news064.html

戦争が始まったな

mediumとslowの違いってmeがhexかumhかくらいじゃなかったっけ
他のパラメータはほぼデフォルトだったような

>>213
そういう人らの主張が通ったためしなんてあるの

>>213
プロレスの間違いだろｗ

>>214
trellisが1だってばよ

同一フレームでブロック別QPの落差を3〜26ぐらいにしたいんだけどどうすればいい？

素人考えなんかせずにx264にまかせろ

>>218
qpminとqpmaxとcrf-maxとcrfを適当に合わせれば？
ただしqpmaxはあまり減らし過ぎるとアンダーフローを起こすから注意な。

ぶっちゃけ色々設定いじった挙げ句、俺のクソ視力じゃ実写なら
フルHD解像度でmediumの7Mbps vbr 2passで十分だけれどもな

実写をフルHD解像度で残すなんてやぼなことはしない。
そこは敢えて3:2か4:3サイズに縮めて、コンテナへ収納時に16:9へ合わせておくわ
エンコ時間の短縮とデータ量の節約にもなるしな。プレイヤーで再生時に
GPUスケーリングで横に少し引き延ばしてもそれほど劣化は目立たん。

残すだけならTSのままでいいわ

マメに全部エンコする人って実際はそれを見返すことほとんど無いよね、不思議と
見返す暇があったらエンコするわ！みたいな・・・

そいつは優秀なエンコマニアだな

r2222

キリ番厨歓喜やん？

【朗報】komisar氏が10bit版をビルド

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

たくわん氏とfushizen氏のお恵みが止まってたから助かった

たくあんさんはブログで記事として書いてないけど各ツール最新リビジョン全部ビルドしてくれてるよ

自ビルドすればいいのに

komisarってmingw作ってる人なの？

ビルドしてるだけ
あとkomisar氏がビルドしてるのはmingw-w64

>>231
live？とかいう場所にアップしてくださってたのか
全然知らなかった…

444ならまだしも10bitは再生環境があれ

10bitが再生できない環境なら444もほぼ再生できないような・・・。
自分の環境にあわせて使えばいいだけなんでどうでもいいけど。

なかなか更新来ないな
どうなってるんだろう？？

出来る事し尽くしたんだろ

Dark Shikari「精神を加速させろ！」

もう年だから勘弁

OpenCLとかもっとやることあるだろ

AVX2が来たら本気出す

X265の開発よろしくお願いします

規格もまだ出来てないのに…

暗黒石狩は何をしてるんだ？
早く更新しようぜ

x264_L-SMASHをビルドしてみようと思うのですがビルドとか初めてでライセンスのことがよくわからないのですが
libavをビルドする時にlibvo-aacencとかlibopencore-amrnb/amrwbとかを有効にする場合--enable-version3を付けないといけないことは分かるのですが--enable-gpl
は必ず付けないといけないのでしょうか？
ググって調べた限りでは三条項BSDライセンスはLGPLv3互換なので必ずしもGPLv3にする必要は無いと思うのですがJEEBさんやPOPさんやたくあんさんの配布してるx264を--versionで調べると
libswscale/libavformat/ffmpegsource license: GPL version 3 or laterとなっていました。
なぜgplにする必要があるのでしょうか？
別に配布するわけではないのでビルドできればどちらでもいいのですが気になってしまったので・・・
分かる方がいらっしゃれば教えて下さい。

うろ覚えだが、--enable-gplをつけるとGPLじゃない何だったかを入れないようになるんだった気がする
faacだっけか？

>>247
今まではapache2はGPLv3のみで使用可能と勝手に思い込んでたわ。
それでとりあえず今はDiego氏と確認してgplの有は無意味と分かった。
ありがとう。

Fraunhofer AAC Encoderのライセンスが完全にGPL互換になると
--enable-gplを付ける理由がまた発生するが、それまではlgplでおｋ。
（FraunhoferのライセンスはGPLとかなり近いが、「無料での配布しかできない」
　という点ではnonfreeと見なされるでしょう）

まぁ、個人のコンパイルならfaacなり、fraunhofer aacなりとビルドしたい
場合は--enable-gpl (&& --enable-nonfree)が必要になるね。


（他に言うとGPLでいくつかのSIMD最速化が有効になるが、
　MPEG-2辺りでしか使用されてないし、殆ど無意味だべ）

>>247
まぁ、最終的にx264はGPLだからリンクされるライブラリもGPLになるけどね。

>>249
SIMD最適化のことなど知りたかったこと以外にもいろいろ教えてくださってありがとうございます！

AVX2でどれほど高速化が出来るか期待が高まるな
OpenCLより伸びなかったら残念だけど

x264TypeDProject始動

なにそのIvy-Eを11000FLOPSまできっちり回せ的なの

これといった話題がないですね

ふぁｄ

rev縛り

CPUが進化しないとソフト屋も特にやることがない
HaswellのAVX2待ちかな？と思ったけどOpenCLどうすんだよ

OpenCL使ってるのは先読み部分だけではないの？

例えばMainConceptはMEにもGPUを使っているし、x264にもまだまだ改良の余地はある。

もしかしてメモリ共有型のAPUを待ってるとか？
あれならプログラム難易度が落ちるらしいが

IntelコンパイラでMKLとOpenMP使うようにしていれば、Xeon Phiでのアクセラレーションが凄そう

あれからOpenCLのアップデート来ないね。
今も頑張ってるのかなぁ？

#x264devでは更新来てるよ

>>264
開発は進んでるんだ！
バイナリが待ち遠しいよ。

たいした進展はないけどね

セルBDはこういうのでオーサリングしてるよ　80万なら良心価格と思う
http://www.comtec.daikin.co.jp/DC/prd/dvd/prd/scenarist_bd/
AVCエンコーダ単品
http://www.comtec.daikin.co.jp/DC/prd/dvd/prd/cinevision/
勉強
http://www.comtec.daikin.co.jp/DC/prd/dvd/bluray_exp/
＞エンコードはマシンの性能によりますが、概ね収録時間の3-4倍かかります。
プロでもクソスペマシン使ってるのかな？
アニプレはこれら使ってると思われ

・オーサリングソフトを作る会社
・オーサリングソフトを使ってオーサリングする会社
・焼く会社
・版権会社
・制作会社
・流通会社
・小売会社

これだけ関わってればBDアニメが高くなるのは頷ける
ハリウッドBDは1500円なのにね。マーケットが世界規模な上に回収済みなのが大きいのかな

http://www.jp.blu-raydisc.com/category/03-standard/

各種ライセンス料さえどうにかなればBDくらいこの板のオタク一人で作れるような

そのヲタクからBDを買うのか？それはちょっと嫌だな。
そんなの作って販売すると嫌儲の連中が大勢攻撃してきそうだ

>>267
セルを焼いてどうする

商売考えないならそんな百万近いエンコーダよりx264の方が遥かに圧縮効率が良いってのもなんだかなぁ
それでどこの誤爆なんすか

2度連続誤爆とか何処をどう間違えたんだろうか

>>267
どこの制作会社がそんなちゃちな物使ってるの？
普通はソフト+ハードのパッケージシステムだけで1000万以上かかる
ちょっと前は定評のある松下の奴が2000万オーバーとかいってたようなきがする

気がするって、適当に言ってるだけかい

松下とかはソフトは自前だろ、シーン毎その一枚絵の中でも部分毎に
パラメータ変えてるとかインタビューで言ってたな。s264じゃとうてい
できないような事やってるのよ

>>275
あはははあんまり覚えてないのよw
うちの会社の別部署の同僚との飲み話で
BD化は外注に出すだけなので外注費減らすためにいっそ自前で揃えたらいくらって話になって
人件費やら教育費やらシステム費やらデザイナーやら何やらで最低初期費用だけで5千万近くかかるって話の中で出てきたんだわ

4分の動画に1時間半かけてエンコしてますが何か

　　ｧ　∧＿∧　ｧ,､
　,､'` （　´∀｀）　,､'`
　 '` 　( ⊃ ⊂)　　'`

10分の動画(SD)を3930kで12時間以上かけてエンコする事あるから全然大丈夫。
-threads 1 -me tesa -ref 16 -subme 11とか付けてればあっという間に…

subme11は微妙だという主張はこれからも続けていく所存

とりあえず偶数は地雷

プラシーボに命を賭けます

>>280
それはアホのやることだろ。
単にCPUへバカみたいに負荷をかけたくて仕方がないだけじゃない？

subme9以降に偶数がどうとか関係あるの？

>>284
数%でも圧縮率が高くなれば同ビットレートでもそれだけ他に割り触れる。
容量比画質さえ良ければタイムパフォーマンス、コストパフォーマンスが2の次3の次って用途もあるのよ
例えば自分の作ったものを映像として多数の人に見せびらかす時とかね…

だから画質が微妙なんだってば

10は11よりもひどいからな

何がどう酷いのか知らんが好きなの使えよバカじゃねえの

とよく思う

そんな君には

QSV

11≫10で11>9>10だろ11は良いぞ
遅いが縮むし9より輪郭周りの破綻がぐっと少ない
2Dソースしかやらんけど

試しに--qpでエンコしてみると11の時はIフレームの値が一定になるね

2Dソースなんて気取った言いかたせず素直にアニメソースと言えよ

ゲームのプレイ動画の可能性も有るぞ

圧縮率が高くなってもアニメなら元々かなり縮むんだからsubme11した所で時間に見合った効果ないだろ
エンコ時間が長ければ長いほど高画質って思い込んでるだけ

>>294
最近のゲームは3Dだもん(´・ω・｀)

--tune touhouなんだろ

ダンプカーの轢き逃げ事件のニュースがソースかもしれないじゃないか

>>295
ssim psnrって知ってる?

subme11、いろんなソースでSSIM落ちる、容量微増って結果になるんだが
subme10と比べて

subme9が最強画質

好きなの使えよバカじゃねえの

そんな君にはQSV

スレチ

コンソールの表示が新しくなった。

7上がっただけかよ

subme10と11は罠なの？

なんで？

>>299
ssimやpsnrは原画との差だから。ロゴ抜きをしていたり、デノイズを施していたり、インタレ解除していたり
色空間を別のものに変えていたり、リサイズで縮小・拡大させていたりすると画質に関わらず大きく変動する。

それにうごきの激しい実写ソースとかでssimが大きく落ちたエンコの画質がかならずしも悪いとは限らないしな
ある程度VBVやcrfなどでビットレや品質を制限した上でのエンコなんだったらssimなんて気休めにしかならんよ

>>309
＞ssimやpsnrは原画との差だから。ロゴ抜きをしていたり、デノイズを施していたり、インタレ解除していたり
＞色空間を別のものに変えていたり、リサイズで縮小・拡大させていたりすると画質に関わらず大きく変動する。

普通に考えるとx264にとっては入力された映像が「原画」であって、
その「原画」はロゴ抜きその他の処理が終わった映像になるわけだが。
何を寝ぼけたことを言っているのか。
わざわざ各種処理前の動画とx264出力後の動画のスクリーンショットを撮って、
そこからSSIMだのPSNRだの計算するようなことしてるなら知らんが。

SSIMは目安の１つでしかないというのはその通りだが、客観的な目安の１つであることに違いはない。

最後の1行だけ同意だな。おまえも蒸し暑い日に熱くなるなよ

皆んなも強気にノイズ除去すれば、SSIMはうなぎ登り。

さあ！

とりあえずSSIMは27dbを超えてから語れ

挙げ足偉そう番長の登場か…
たまに出てくるよね、偉そうに長々と書き込む奴ｗ

事前にソースのグレインノイズ類を片っ端から低減して平坦にしておくと圧縮率が上がって
SSIMもうなぎ登りに上がるんだぜ。ヨルムンガンドとかで試すと面白いかもな。

それはもうヨルムンガンドではないだろ

ヨルムンガンドはCMカットしてfgoを有効にしてエンコさせると
crf20で平均600MB前後、平坦にすると240MB前後ぐらいになる。
どんだけ圧縮できるんだよって話。

r2207

知ってた

ｒ2208

r2209

commitしなおしだから、r2208のままだよ

r2207なんか問題あったん

このくらいの英語は読め

r2207「ヘイみんな！インジケーターかっちょよくしてみたぜ！どーだい！」

r2208「そ、そんなにボロクソ言わなくてもいーでしょーに！はいはい！わかりましたー元に戻しマースどーもーすいませんでしたー」

新しいインジケータが好きならr2207
以前のほうがいいよーって人はr2208使えってことか

同一ソース/設定でエンコ　　32bit-10bit/d
元ソース　mp2 0:22:15 2.95GB
r2184　　7:46:11　1.75GB
r2197　　7:34:47　1.84GB
r2200　　7:09:22　1.52GB
r2207　　6:22:37　1.23GB

これは・・

問題はエンコ後の容量より画質。小さく出来てラッキーって思って再生してみると
圧縮し過ぎてところどころバンディングが発生していたりノイズが混じっていたり・・

crf上げればいいって事なのかな

とりあえずqcompとVBVをちょっと多めに盛っとけ。
crfを上げるのはその後でもいい。

qcomp盛るとcrfじゃ余計に容量節約するんちゃうん

1に近づくんとちゃうか？

いやそれはないだろう。
そもそもqcompは初期値の0.6より下げると圧縮率が無駄に上がって画質もちょっと劣化する。
動きがあまりないソースだと0.8ぐらいでもそんなに変化はしないが、動きの激しいソースだと
qcompの微調整もわりと重要。画質優先なら0.6より下げるなんてもっての外だが

qcompを盛り過ぎると画質というよりエンコ中にビットレを多く消費するんだよ。
それが断続的に続けば結果的にデータ量が増える。

猫科はよ

このスレでの話ではないが qcomp とかビットレートを盛る設定の説明が
1pass/2pass使用者それぞれで微妙にニュアンスが違ってて
ド素人時代は迷った覚えがある
　1pass → 盛れば盛るほど画質が良くなる
　2pass → 盛りすぎると悪影響がでる
みたいな

それって、2pass使用者がニコとかに投稿するのを前提にしてるからでしょ
ニコ厨にとって、ファイルサイズが膨らむのは悪影響以外の何者でもないだろうし

マルチパスに画質は関係ないだろう。1pass目にどんだけ適当なパラメータにしたかで
ビットレなど各種解析される部分が減って結果的に劣化が進むことはあるかもしれないが
そこはずる賢くパラメータを工夫してやれば希望するデータ量の範囲でそれなりの質に
仕上げることは可能。ま、マルチパスでのデータ量はあまり当てにならんのだけど。
すべて同じビットレに合わせたとしても、ソース映像の動き方によって
データ量が小さ過ぎたり、大き過ぎたりバラバラになることも多々あるしな

>>327
2184→2200でも容量比下がってるのか
ssimとかはどうでした？

2200はJEEB版が結構縮む。nl版と比較しての話だけどな。他のビルドは知らん
JEEB版はエンコ開始前に色空間の識別表示をしてくれるのが助かる。
ソースによって使い分けるからさ

720pソース --crf 18でテスト

revision2164 33,527,346 byte Y:0.9959855 (23.964db)
revision2184 33,484,595 byte Y:0.9959939 (23.973db)
revision2200 33,465,112 byte Y:0.9960001 (23.979db)
revision2208 33,599,215 byte Y:0.9959852 (23.963db)

revision2164 33,527,346 byte
x264 [info]: SSIM Mean Y:0.9959855 (23.964db)
x264 [info]: PSNR Mean Y:53.245 U:59.380 V:58.913 Avg:53.677 Global:50.349 kb/s:2255.85
encoded 2856 frames, 16.76 fps, 2255.90 kb/s

revision2184 33,484,595 byte
x264 [info]: SSIM Mean Y:0.9959939 (23.973db)
x264 [info]: PSNR Mean Y:53.314 U:59.424 V:58.956 Avg:53.743 Global:50.355 kb/s:2246.83
encoded 2856 frames, 18.23 fps, 2246.88 kb/s

revision2200 33,465,112 byte
x264 [info]: SSIM Mean Y:0.9960001 (23.979db)
x264 [info]: PSNR Mean Y:53.330 U:59.448 V:58.981 Avg:53.760 Global:50.362 kb/s:2245.52
encoded 2856 frames, 16.95 fps, 2245.57 kb/s

revision2208 33,599,215 byte
x264 [info]: SSIM Mean Y:0.9959852 (23.963db)
x264 [info]: PSNR Mean Y:53.268 U:59.380 V:58.912 Avg:53.698 Global:50.351 kb/s:2254.53
encoded 2856 frames, 17.92 fps, 2254.57 kb/s

数値だけで見るとチューニングの方向性が2164に戻ったように見えるな
2164残留組としては興味が出てきた

crf 18とか余裕あり過ぎで見た目殆ど分からんだろ
20以上にしないと…

そういうエンコードはわざと劣化SDソースを使うのが一番面白いよ。
劣化の殆どない綺麗なHDソースだと違いがあまり無さ過ぎて退屈する。

BDアニメソースcrf 25ぐらいでやろうぜ
ソースの劣化が少なく劣化や色付けも分かりやすかろう

>>327
同一ソース/設定のr2197とr2207で600MB以上の差ってｗ
♪リビジョン違えば2割3割あたりまえ〜♪

ぎぃやぁぁぁぁぁぁぁ
http://x264.nl/のバイナリですらWin2000でうごかなくなってる
r2208 で msvcrt に _aligned_free が無いって言われます、助けてJEEBたん！

>>347
とりあえず未だにエンコ関連に2kたんを使ってた人がいる事自体に驚き
（未だに2kから他のOSへ移動したくない会社とか・・・じゃないよね？）

最近は32bitの方のツールチェインもmingw-w64の方へ移したからそれでなんじゃないかな
x264.nlにある2207もダメだったらほぼ確実にそれが理由。

trunkの方だからあとで手元にあるstable/v2なツールチェインでもやって、
インポート関連をチェックしてみる。trunkは色々変更が入ったりしてるから
Win2000のサポートは切られた可能性も高い、stable/v2の方はまだ残ってるかもしれない。

mingw-w64は元のmingwプロジェクトより色々開発が進んでるからツールチェインの
mingwへの戻しはしない。Win2000はもう２年程無料サポート切れてるし、殆ど眼中
にはない。

あと、_aligned_free()って、普通にWin95から入った機能だとMSDNで書いてある
けどね・・・ ttp://msdn.microsoft.com/en-us/library/17b5h8td%28v=vs.80%29.aspx

2000なんて使う人まだいるんだｗ

ゲイツの陰謀ともしらずに

サポート切れてるようなOSでネット繋ぐな

それはアクトビラのことですね。

地デジを自動エンコしてるんだけど、
ソースの解像度をコマンドで取得できるツールってありますかね？
値に応じてsar値を割り振りたいんだが。

MP4Boxのinfoコマンドからの情報をgrepとawkで取り出すことはできそうだけどシェル環境がいるね

録画ファイル名に局名入れとくかなんかして局を判別して割り振るってのが簡単にできるとは思う
つかスレチだな

>>353
Mediainfo

>>354
>>355
Mediainfoで取得できる事が確認できました。ありがとう。
sar値だったのでこっちにしたんだがスレチ申し訳ない。

>>348
> 最近は32bitの方のツールチェインもmingw-w64の方へ移したからそれでなんじゃないかな
2207もダメでした

> Win2000はもう２年程無料サポート切れてるし、殆ど眼中にはない。
ですよねー

としか言いようがないのでろくな詳細を書かなかったのですが
逆に余計な手間かけさせる事になって申し訳ないです



>>348-349
メイン7で本気エンコ/サブ2000でパラメータ調整テストみたいな事(録画とか雑用)ですね

ま、でもWindowsOSのなかでもっともサクサク動くのは2000だけどな。
あのUIの快適動作だけは2000以前や、2000以降のWindowsでは真似できない。

それは報告しなくてもいいです

そんな事誰も聞いてもいないしな

２ちゃんねるなんて、誰に聞かれなくても自分が書きたいことを
自由に書くことに意味があるんだろうが。なに当たり前の事言わせてんの？
くだらない理由で束縛させんな。元々ほとんど話題性のないスレなのにな

すみません
うちの娘がご迷惑をお掛けしまして

うおおおおおおお猫科まだかーーーーーーーー

　　　　　　　　 ,、,, ,、,, ,,　,, 　　　　　　　
　　　　　　　_,,;' '" '' ゛''" ゛' ';;,,
　　　　　　（rヽ,;''"""''゛゛゛'';, ﾉｒ）
　　　　　　,;'゛ i　　　　、＿ iヽ゛';,
　　　　　 ,;'" ''| ー-　 〈・ノ |ﾞ゛ `';, ん？
　　　　　 ,;''　"|　　 ▼　　 |ﾞ゛　`';,
　　　　　 ,;''　　ヽ＿人＿ /　　,;'_
　　　　 ／ｼ、　 ヽ⌒⌒ /　　 ﾘ　＼
　　　　|　　　"ｒ,,（ ｀"'''ﾞ´_） ,,ﾐ゛　　 |
　　　　|　　 　　 /　　,ｨ_） ,ﾘ　　　　|
　　　　|　　　i　/　　/,ｒ,,ｒ"　i　　　 |
　　　　|　　　Y　　 /　　　　ﾉ　　　 |
　　　　（ヽ　 _＿ /--――´　　　 /
　　　 　（_⌒ ＿＿＿＿＿＿ ,, ィ
　　　　　　丁　　　　　　　　　　 |

スレチと3文字で一蹴されなかっただけ幸せと思えよ
なにキレてんの？

そんな事よりAOにサッカー回があるか議論しようぜ

弄られ役のレントンがでてこないのに無意味だろ

岡持まだ？

2000使いなら
ttp://blog.livedoor.jp/blackwingcat/
ここ行ってみ

ぐおおおおお猫科禁断症状がああぁぁぁぁぁぁ

>>370
お前がやるべきことは少しでも英語の勉強することじゃね？
changelogなんて辞書引きながらなら中学生でも読めるだろ。

小学生女児が書き込んでると思えば腹も立たない

ブサイクは親もまたブサイク
これは動画圧縮の親子関係にも言える
宇宙の真理

r2208 r2204を元に戻した
r2207 i7で50サイクル早くなった
r2206 p4x4がちょい良くなった
r2205 マクロツリーをごにょごにょしてちょい早くなった
r2204 進行状況インジケータをごにょごにょした
r2203 レートコントロール予測をごにょごにょした
r2202 色々ごにょごにょした
r2201 0fpsで爆発するのを直した

バイナリとして出てるのは2200の次2207、2208だったけど
途中のが出ないのはなぜ

単にビルドのタイミングでは？

r2208 r2204を元に戻した
r2207 i7で50サイクル早くなった
r2206 p4x4がちょい良くなった
r2205 マクロツリーをチョメチョメしてちょい早くなった
r2204 進行状況インジケータをクチュクチュした
r2203 レートコントロール予測をピチャピチャした
r2202 色々チュチュした
r2201 0fpsで爆発するのを直した

>>375
手動ですから、herp le derp

MB-Treeについて質問なんですが、動いている被写体に注目するソース（舞台など）の場合はoffにしたほうが良いのでしょうか
アドバイスお願いします

いいえ
静止画部分での圧縮率があがりやすいだけであって
動画部の画質で不利になるわけではないから
再生環境に問題ないなら常にオン

そうなんですか、以後onで使用します。ありがとうございました。

ところでDPBのエラーを検知してパラメータを自動で補正してくれるx264はある？

DPBのエラーの意味がわからん

http://up-cat.net/x264%2528vbv%252Dmaxrate%252Cvbv%252Dbufsize%252Cprofile%252Clevel%2529%252C%2BH%252E264%2528Profile%252FLevel%2529.html#p6
＞DPBに関してはユーザ側で定義することは何もなく、間接的に--refが影響されるだけ

--levelと--refの整合性という意味なら--refを指定しなかった場合自動的に下がる
CPBの間違いならAuto VBV Settingsとかでググれ

1440x1080のソースをリサイズせずに
b4, ref8, [email protected]とかでエンコさせようとしたらDPBのwarninngがでるだろ。
エンコ自体は中断しないしrefは7未満にしろと警告が表示されるだけだが
b4, ref7になんてしたらバランスがおかしくなって画質に影響が及ぶだろ。

及ばないと思うんだが

DXVAで再生したいとかだったら、--ref 4で決め打ちすればいい。

つうか1440x1080でref8, [email protected]なら特に警告なんて出ない。このサイズで[email protected]ならref16でもいけるし。
high@4〜4.2なら5以下という条件になるはずだが。

p4x4を使ったらってやつじゃね

>>388
猫科見直してきたけど、それはまたちょっと違った話じゃないかな。
　http://up-cat.net/x264%2528vbv%252Dmaxrate%252Cvbv%252Dbufsize%252Cprofile%252Clevel%2529%252C%2BH%252E264%2528Profile%252FLevel%2529.html

一応1920x1080で
　　--crf 23 --bframes 4 --partitions all --ref 16 --level 5.1 --frames 30 --input-res 1920x1080 --fps 30/1
でエンコしてみたけど、特に警告出ないし。

これはきっと、

釣りだ

x264ってSSEとかAVXとか結構使うんかね
fx8150かi5 3570Kどっちにしよう...

i5 3570K一択

なんで物理スレッド数半分のほうが一択なのか分からん
少なくともx264に関しちゃFX-8150はi7-2600K同等レベルだぞ
ttp://pc.watch.impress.co.jp/img/pcw/docs/528/691/html/g7.jpg.html

同じエンコ性能でも消費電力が倍違うのは無視か

TCを切って電圧を絞ってさらにOCすればFX-8150でもそこまで膨れんよ。

メーカーが違う製品の比較をするとすぐ宗教戦争になってまともな議論にならなくなる

8150、整数演算するやつは8つ確かにあるけど浮動小数点数演算するやつは4つしかないんよね
x264はどっちの計算の割合が多いんかねって思った

前にDark_Shikari氏に聞いたら殆ど整数演算って言ってたような記憶がある

ありがとう
8150にします

え？

x264エンコード専用機で少々の電気食いが無視できるなら選択肢としてありじゃないか
ゲームとか他用途にも使うならご愁傷様だが

電気代の差より専用機を1台用意する方がずっと金かかるぜ

3930kにしよう(提案)
10kからマザボ買えるようになってきたし石が割高な事を除けばエンコ目的では最良じゃないかなぁ

>>398
整数は整数でも整数SIMDだから仕事するのは浮動小数点演算ユニット。
よってコストパフォーマンスを考えないらIntelの6コアがベスト。
AMD FXは安いから消費電力を考えなければあり。

俺もi7 920のあとは980X、970、3960Xと来てるな
6コア12スレッドCPUを使った18スレッドエンコは安定してていい

i5買おうと思ってたんだけど、4c4tと4c8tってどれくらい違うの?

4T分違う

FXがいわゆる8コアだと信じちゃってる人いるんだなあ(´・ω・｀)

いわゆる

>>406
20〜30％かな

ハードウェアの宗教戦争はよそでやってくれ

>>408
8150/8120は8コアだろ。実質４モジュールだけどな
Intelの数え方では４コアで８スレッドとでも解釈しときゃいいんじゃね？
Intelのスレッドの概念と、ブルのコアの概念は全く別物だが

>>412
他でやってくれませんかね

金が余ってればハイエンドで
普通はミドルレンジで十分だ

Rade7750で3770Kでも１割程度あがってるし
ミドル+それなりなgpuがよさそうな気はする

それはまだない

>>412
エンコ性能だけなら　2600k＝8150＜990x＜＜3930k＜3960x

>>417
CPU+M/Bの価格を考慮してから比較しろよ。
その中じゃ8150が最安値になるんだぜ？

Intelのなんであんなに高いんだろ

>>418
AMDのは12コアや16コアが出れば逆転できるんだろうけどメーカーにやる気があるかどうか

そういのは産業用のマザーにオプテを２個載せてやればいいんだよ。

そうです。ここは「エンコPCの構成を考えようぜ」スレです

おまえらここのスレタイ見えてるかい？ｘ264 rev37だぞ

>>423
じゃぁとりあえず面白そうなx264の話題を出してくれ

じゃぁ俺から


俺はx264の事を
エックストゥーサウザンドシックスティーフォー
と発音している

サウザンド？
サウザンド？？？？？

Pardon?

いや面白いなら笑ってくれよ
なってないなぁ

サウザンドとかみるとモスのバーガー食いたくなってくるから困る。
http://iup.2ch-library.com/i/i0709084-1344155314.jpg

ゴクリ…
近場にないんだよなぁ

x265が見えてるから滞ってるよなぁ半年前の大幅更新からあんまりかわってない

見えてないだろ・・・

まだ始まってもないぞ・・・265のほうはx264と関係ないし

よくわかってないのに俺は先が見えてるんだぜとアピールしたがる奴はどこにでもいるよな・・・

子供って、そんなもんさ
マジレスしてやるな

>>425
つまんねすぎ
死ね

モスって一昔前より不味くね？味が昔と完全に違うと思うんだが

モス味は店によって違う。

かなり古いr996のときの疑問なんだけど、bime/b-rdoがsubmeに統合されたときの説明が

subme6 is RD in I/P frames
subme7 is RD in all frames
subme8 is RD refinement in I/P frames
subme9 is RD refinement in all frames

subme6 == old subme6,
subme7 == old subme6+brdo,
subme8 == old subme7+brdo,
subme9 == no equivalent1

となっていて、brdoは、まるも氏の解説を引用すると「RDO を B スライスで有効にするオプションが --b-rdo になる。」だから
subme7+brdoのsubme8が、RD refinement in I/P framesとなるのは変じゃないか？

俺の頭ではsubme8のときは、Bフレームにはsubme6+brdo相当の処理を行い、I/PフレームのみRD refinementな処理なのかなと解釈したんだけど
これの解釈であってるかどうか、詳しい人教えてください

チェンジログのコピペ↓

commit c89bc900a3bf0d4c4c728ad378703970b4f14e18 r996
Author: Jason Garrett-Glaser <[email protected]>
Date: Tue Sep 30 18:34:56 2008 -0700

Rework subme system, add RD refinement in B-frames
The new system is as follows: subme6 is RD in I/P frames, subme7 is RD in all frames, subme8 is RD refinement in I/P frames, and subme9 is RD refinement in all frames.
subme6 == old subme6, subme7 == old subme6+brdo, subme8 == old subme7+brdo, subme9 == no equivalent
--b-rdo has, accordingly, been removed. --bime has also been removed, and instead enabled automatically at subme >= 5.
RD refinement in B-frames (subme9) includes both qpel-RD and an RD version of bime.

釣れますか？

ところで次世代光ディスクの映像部にAVCが映像会社に提案された際
その提案されたメインプロファイルじゃ画質に不満があるとかでハイプロファイルつくられたみたいだけど
メインプロファイルでたとえ40Mbpsあってもどうやっても表現できない＝画質に不満があるなんてことがあるの？
圧縮率の向上以外にも表現性の向上があるのでしょうか？
経験上有意差を感じられない幸せな目をしています

盲自慢かっけー

1行目から2行目にかけての経緯が合ってるかどうかは知らないけれど
ビットレートだけで画質が決まるわけではない
8x8dctとか量子化マトリックスの有無もあるし許容される最大ビットレートもバッファサイズも違う
特にBDみたいに高解像度になると8x8dctの有無は大きいと思う

>>440
ぼちぼちでんな

--qpfileについて質問させてください
例えば、1001フレーム目をIDRにしたいときに、
1000 I
のように指定すると、1001フレーム目は、指定どおりIDRになるのですが、
動画によっては、999フレーム目や1000フレーム目もIDRになってしまい、
AviUtlのMP4Pluginなどで、うまくデコードできなくなってしまいます
ちなみに、qpfileなしで、1001フレームがIDRになるような場合でも
qpfileで指定することで、こうなることがあります
何か設定方法が悪いのでしょうか？
回避方法があるならば、教えていただけないでしょうか？

これか？
http://2chnull.info/r/avi/1269245115/320-323

>>446
QPの記述は省略していますので、-1としているのと同じです
一応、-1も試しましたが、全く同じ結果でした
QP値を解析したところ、QP値は適正にエンコードされていました
私が困っているのは、qpfileで指定することによって、
必要以上にIDRが挿入されてしまうことです

IDRの前後PなりBなりbなり指定したら？

ttp://www.genkirockets.com/news/
/movie/lux.mp4 (avc+aac)
/movie/lux.webm (vp8+vorbis)
/movie/lux.ogv (theora+vorbis)

--preset slow --crf 22 --qpmin 10 --qpmax 51 --no-mbtree --no-psy

ここのwebmasterから同じ匂いするのは置いといて、謎すぎるパラメータなんだが
意図があるのか、ffmpegのプリセットかなにかか？だれか教えて
最後２つのオプション無ければ1Mbit/sの節約できるのに

低スペ向けでしょ main使えばいい話だけど

mbtreeやno-psyをつけるのが低スペ向け？
どういう理屈でそうなるんだ？

脳が低スペックな人向け

対応してない古いデコーダ向きかもね
mbtree対応してないと画面崩れて見れなくなるし

どうせどこぞのFlashPlayerで再生させるために制約を課しているだけだろ
エンコ環境や私物PCで再生させるんならわざわざそんな制約とか課す必要なんて無いんだから

対応が必要なweightp等とは違って、mbtreeやno-psyはビットストリームが変わるオプションじゃないと思う。

>>455
ビットストリームの使い方合ってるっけ？

ﾋﾞｯﾄｽﾄﾘｰﾑｱｯﾀｸ！

俺を踏み台にしてください

【動画】MP4(H.265)承認ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!　同画質でのファイルサイズがMP4(H.264)比で半分
http://engawa.2ch.net/test/read.cgi/poverty/1345105090/

負荷は倍？

x265はよ

>>460
2倍程度で済むとは思えんが

デコード負荷200%
エンコード負荷プライスレス

カラダ（ファイルサイズ）は子供、頭脳（処理負荷）はオトナってやつか

ほんとに半分も縮められるの？

新しいコーデック出るたびに繰り返される問いである（´・ω・｀）

この業界得意のセールストーク

AVCのときもASPの半分で同画質とか言ってたよな
結局半分は無理だったけど

いくら同画質と謳われてもそれはPSNRやSSIMの数値上の話をしているだけなんだろ？
実際プレイヤーで再生させてみると暗部で縞がでていたり、残してほしかったノイズが消えていたりとか
細かいところに手が届かないっていうか。やっつけし過ぎだろって思える節がチラホラ。

まぁデコーダーにはh264の10bitも入れておいてや

H264だって出始めの頃はDivXやWMVに劣る程度の完成度だったしな
ブラッシュアップされるまではまだまだかかる

しばらくは10ビット264で充分お

GPUで処理しやすいコーデックにしちくり

GPUに余計な負荷かけんなよ

>>469
某サイトにでてたスト4のサンプル画像まさにそうだな。

またコーデックの移り変わりに翻弄されるのか

mpeg2で止められるよりましwww

地デジ（）

x264のコードは流用できるでしょ

GPU用に浮動小数点演算に作り直してくれませんかね

ソース公開されてるんだから自分でやりなさい

ビルドツール一式も同梱してくれれば自分でやる

これが馬鹿さか・・・

ビルドツール同梱か
午後のこ〜だを彷彿とさせた

PGツール同梱でしかもスクリプトで自動コンパイルとか
あれは、ある意味画期的な発想だったと思う

新revはよー

1色ベタ塗りの画像だとやたらと汚くなるんだけど設定あるのかな？

crfの数字下げるかその容量のままある程度綺麗にしたいならaq盛ればいいんじゃね

おいおいベタ塗りの画質を上げようってのにaq盛ったらなおさらq値が上がるだろ　＾＾；

で自分の考えは言わないと

一番嫌なヤツだわ

>>487
とりあえずその汚くなった設定さらしてみれば？

bframesは多すぎるとよくないのですか？

>>492
場合による

>>487
--colormatrix smpte240m --transfer bt709 --colorprim smpte240m
こんな風にしてみるとか。avsなどで(ソース側で)事前に変換してやらにゃあまり効果はないけどな。
一部の再生互換性を殺してでも画質を変えたいならこれが手っ取り早い。

ビルドツールってMinGWだけありゃ十分。
./configureしてmakeすりゃ出来上がる。

ソースに必要ツール一式も同梱してよ

bframesの適正値を教えてください
ソースは動きの多い実写です

ソースに寄ります

>>497
Bフレに限った話じゃないが、自分なりの適正値がわからないなら指定しなくてよい
つまりデフォルトでいい、値を指定しなければデフォルト値になる

>>497
2の倍数か3の倍数でBF:ref比が1:3か1:1になるように合わせとけば問題ないだろ。

>>496
cygwinでもいれとけ。

また更新の停滞期に入ったか

ｘ265ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

nlの64bit 8bit-depth mirror03が壊れてる
これ豆な

10bit-depthだと圧縮率が上がると聞いたのですが本当ですか?

うん、ちょっとだけね
暇なら自分でやってみ

10bit-depthだと彼女ができると聞いたのですが本当ですか?

実際それでなるPが彼女作ってエンコから離れていった

.

r2216

OpenCLの正式版はよ

FlashPlayerで10bitの動画を見ると緑っぽくなるのだが...
横マゼンダより深刻な問題だなこれ

FlashPlayer

>>512
更に10bitのインタレ動画だとクラッシュするぜｗ

merengeの16というのは、何が16なんでしょうか？
ピクセル？ブロック？

>>515
＞merange controls the max range of the motion search in pixels.

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

画像を回転させると
外側のほうは動き検索で捕捉できなくなるの？

画像を鏡像反転させると
動き検索でまったく捕捉できないの？

x264ダウンロードできるサイトの一覧みたいなのって無いですかね？

>>1

ほぼリンク切れ・・・

どれがリンク切れてるの？

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

http://x264.nl/だろ？
mirror5以外生きてるぞ
そっちの経路障害じゃね

nlっていまだにr2208？

むしろnl基準なのでまだ2216など存在していないものと思っている

でも自分でビルドしようと最新ソース取得するとr2216になるんだよな
まあいいけど

数あるビルダーの一つに過ぎないのになんでnlに忠義を尽くしてるんだよ

忠義ではなく信仰、信仰に理由を求めるな。

署名が一番シンプルなのでnl基準

一番手堅いのはkomisar氏あたりですか？

いぇーぶさんを忘れてもらっちゃ困る

たくあん氏 JEEB氏、辺りは?

[日本]
POP氏 http://pop.4-bit.jp/
Sada Maru氏 http://sadamaru.atgj.net/
たくあん氏 http://k4095-takuan.blogspot.jp/

[海外]
JEEB氏 http://x264.fushizen.eu/
komisar氏 http://komisar.gin.by/index.html
XhmikosR氏 http://xhmikosr.1f0.de/
nl（実質JEEB氏） http://x264.nl/
XvidVideo.RU http://www.xvidvideo.ru/component/docman/

他あります？

changelogください｡みつからない

http://git.videolan.org/?p=x264.git;a=log

ありがとうございます

どういたしまして

よきにはからえ

>>534
横からだけどありがとう
こんなに沢山あるなんて知らなかった

トノサマガエル

ついでに最新のリビジョンとか調べてみた。
あと海外はtaro氏（http://astrataro.wordpress.com/）忘れてた。

[日本]
POP氏 r2216/32bit & 64bit/GPAC & L-SMASH/8bit-depth
Sada Maru氏 r2216+688M/32bit & 64bit/L-SMASH & MixAQ & OreAQ/8bit-depth & 10bit-depth
たくあん氏 r2216+689M/32bit & 64bit/L-SMASH/8bit-depth & 10bit-depth

[海外]
taro氏 r2216+688M/32bit & 64bit/L-SMASH & MixAQ & OreAQ/8bit-depth & 10bit-depth
JEEB氏 r2200/32bit & 64bit/L-SMASH/8bit-depth & 10bit-depth
komisar氏 r2216/32bit & 64bit/L-SMASH/8bit-depth & 10bit-depth
XhmikosR氏 r2216/32bit & 64bit/GPAC/8bit-depth & 10bit-depth
nl r2208/32bit & 64bit/GPAC/8bit-depth & 10bit-depth
XvidVideo.RU r2208/32bit & 64bit/GPAC/8bit-depth & 10bit-depth

[備考]
MixAQ & OreAQ は8bit-depthしかない
L-SMASH板の+688MはL-SMASH版オリジナルの更新数かな？
POP氏のは+688Mみたいなのはわからなかった
komisar氏のはL-SMASH版ではあるけどBugMaster氏のL-SMASH版にするpatch当ててるみたいで他のL-SMASH版とは若干違うのかもしれない
XhmikosR氏のはlibavとかffmsとかが入っていない

こんなところかな。

わけがわからないよ

どれが本物なんだ

本物って何だよ

>>543
ビルドなら誰でもできるよ
>542のビルダーはそれを公開してるだけ
別に貴方がx264エンコーダをビルドして公開してもいいんだし

>>543
nl r2208/32bit & 64bit/GPAC/8bit-depth & 10bit-depth
これ以外は偽物と考えて良いぞ

>>543
本家配布のソースからビルドして配ってるだけだから偽者もクソもあるかよ。
多少makeの際にパラメータを組み替えている人もいると思うが
ソース自体を独自に改変するようなやからはそんなに居やしないしな

いつから当たり外れがある様になったんだよｗｗ

やべぇ、俺の使ってるx264偽物かも・・・
変なところから拾っちまった

それウィルス入ってるぞ

ウイルスのせいで綺麗にエンコ出来てしまったぜちくしょうめえ！

ウイルスのせいで処理速度が30％低下して画質が50％向上した

wiる酢の性でパソ婚が物故割れた

x264.nlが更新されて、fushizen.euのパッチ付きのビルドも2216になったなぁ

何が、変わったのですか？

Scan type : Interlaced
↑これはMBAFFのマクロブロック単位のインターレースでエンコしちゃってよいのん？

いいよ

もう猫科しか頼れるものはいない

Haswellが出るまで特に面白いことはないな
あったとしてもOpenGL位だろ

CLな

ミスったｗ　これは恥ずかしい

まだなるPがいるで

OpenCLは一応レビュー中だけど、ATi/AMDの注文はただ実装するだけで、
「完成させる」ではなかったからなぁ・・・　今は前からIRCにいた人
が一人で自由時間に完成させてる。

速度的には「CPUが遅くてGPUが速い」な環境だけで有利になるちょっと
笑える結果。省電力的に考えてる人にはまずありえない選択。

それはAPU（のメモリ共有？）が性能にまったく関与してなくて、CPU部分がivy並みになった場合はCPUオンリーのほうがパフォーマンスが良くなるってとこ？

2216どうなの？

　x264 OpenCL
109.8　i7 3770K + HD7750
104.6　i7 3770K + GT640
100　　i7 3770K

たしかに"「CPUが遅くてGPUが速い」な環境だけで有利になる"って感じだね。

x264に限れば、速いCPUでも、見合ったGPUがついていれば、速くなるよ。
実際980X 4Ghz+RADEON HD7970でCPUのみより1割弱速くなる。

で、自作板のベンチ見てた感じ、GPUの効果はMAXでCPUのみの1割増しってところ。
いくつかの組み合わせ見てても、それ以上は伸びない。
で、これは遅いCPUに速いGPUの組み合わせにも当てはまるので、
CPUエンコで10fpsしか出ない環境ならどんなに良いGPU積んでても、現状11fpsになるのがやっと。
3960xの結果は見たことないから、実際どうなるかわからないけど、
上の組み合わせでもまだGPU側には余裕あるから、恐らく1割弱まで伸びると思う。

結論としては、速いCPUに速いGPUの組み合わせでの効果が一番大きいって事になる。
コストパフォーマンス抜きで考えればね。
そして現状のOpenCLバージョンではエンコ速度を稼ぐためにGPUに投資するのは、ぶっちゃけ無駄かなと。
GPUに金かける位なら、CPUにかけた方が、よっぽど効果が大きい。

1割の速度増加が達成できるなら十分意味あるだろう

>>566
これでどんな感じの設定か気になる。
確かDoom9だと遅めのプリセットで逆効果があったっぽいけどなぁ・・・

あとバイナリにパッチのバージョンが付かないのはなんとなく気に入らない、
どのバージョンを比べてるか分からないからｗ

>>567,568
ちなみに、その言い方は作者から引用したｗ
「22:53 < muggs> yes, with a good GPU or a not-so-good CPU the OpenCL version will be faster」

>>569
確かにlookaheadだけではあるが、設定によって少々画質が悪くなる（SSIM的に）
それでもオッケーならいいかもしれないね。

>>569
＞GPUに金かける位なら、CPUにかけた方が、よっぽど効果が大きい。

これは、最上位のGPUを買って、CPUをi5で妥協するのは割りに合わないということでは？

>>570
その英文だと「良いGPU積んでるか、CPUがヘボいなら意味あるよ」って言ってるだろ

>>572
OTL

完全に「or」を「and」として読んでたよ。オイラの脳内はどうなってるのやら・・・

猫科きたら起こして

お兄ちゃん、起きて！もういつまで寝てるのよー

起きたら7/21に戻ってる気がするから起きない

女子高生「エンコなんてビットレートだけ設定すればいいだけだなのに無駄にこだわってるやつがキモイ」
http://engawa.2ch.net/test/read.cgi/poverty/1348408527/

なにそれ2000年ごろのヤマンバギャルの会話？

破綻した低画質の面を化粧フィルタで数時間おきにエンコしてる女に言われたくない

だが待ってほしい
男の子も化粧をすると可愛いのではないだろうか

ソース次第だな

非婚化が深刻

x264と結婚したい

妹のlibx264ちゃんは私が貰いますね

もしかしてx265ちゃんはまだ幼女なんじゃなかろうか…

熟女好きはどうしたら…

>>586
MPEG4 SPを使う

そこはcinepakだろｗ

さすがにCinepakは熟れてるってレベルじゃないだろ
まだ使われてるMotionJpeg辺りで

猫科きてない…
ｳｯ

エンコ

エンジョイ！コリア！

嫌エンコ！

もうエンコは画質に拘らずやったほうが早いな
画質求めるなら買えってことだし

画質どうでもいいならハードウェアでリアルタイムエンコするわ

数年前に比べれば速度もcpuも良くなったんだから全然遅くねえだろ

CPU早くなったら早くなったでsubmeとかmeとか設定上げちゃうから速度は変わらないと言う・・・。

それは自分がそれを選択するからじゃ

数年前に比べればHDD安くなってんだからエンコしなくていいだろ

大きなお世話

MPEG2は保持したくない。

既に圧縮されたモノを更に再圧縮するとか･･･
画質どうでもいい人間ならではの発想か

>>599
問題点はそこじゃない。
HDDは安くなったが収納できるHDDの台数は限られるしな
とっかえひっかえしても、嵩張るだけ。

最近はデータ量が多くなってバックアップ作るのがどんどん大変に…
だから圧縮は重要

HDDをより容量の多いHDDにバックアップするしか選択肢がなくなってるからね
容量の増加が全然進んでないからこれも難しくなってるが

エンコとバックアップは関係なくね

放送をエンコするとは限らんし。

リッピング違法化したしもう需要は終わりかね

罰則は無いけどな

LDの炎の転校生でもエンコするか・・・

>>609
損害賠償請求クラスの民事責任は発生するけどな

4年前の記事
https://msc.sony.jp/member/mail/mysony/series/20080717_1/index.jsp
悪く言えばエンコオタク
良く言えばエリート

＞職業コンプレッショニスト
＞爆発や1コマ1コマで激しい動きをしているシーンが加わると、もうブロックノイズにしか見えなくなってしまいます。
品質基準の圧縮してないのか？
＞ただコンプレッショニストという仕事があり、それを目指してこの世界に入ってくれる人が増えると嬉しいですね。

なんか昔のx264のほうが綺麗だな

x264の設定を積めれば画質はプラシーボレベルになるよ

後目指すのは速度か？

>>612
読んだらmpeg2の話みたいだからしかたないね


エンコ工程を意識しない自由な絵作りができるというのはある意味羨ましいね
エンコのことを知ったらもう、ビットを浪費するチラチラ編集などできなくなるのだから

x264はもっと商業利用されるべきだな

それはH264のお役目

>>617
お前は規格とエンコーダの区別もつかないのか

言い方が悪かったか。x264以外のH264のお役目。

なんか最近結構商用ライセンス売れてるみたいだけどね

つべとペガシスしか知らない

XSplitのSplitMediaLabsとかPS3用エンコーダ作ってたFixstarsとか
少なくとも40社が契約してるぞ

つべvp8になるぞとかいって結局h264に戻ったのは知ってるがx264使うようになってたのかよしらなかった

つべは最初からx264だったような…
というか、鯖側にエンコーダを置いてるだけならGPLでいいはずだが

つべは元々Skal氏（？）が作ってみたH.264エンコーダーを使ってたよ。
低機能なBaselineプロファイルなエンコーダーだから画質が結構悪くて
結局2008年（？）辺りにx264へ移動した。x264へ移動した最初の頃は
SEIも無変更だったしなぁｗ　すぐにわざわざ変えて色々隠すように
したけどね。

そしてつべは多分MPEG-LA関連でライセンス取ってると思うけど、
GPLのまんまでも使えるから有料ライセンスは取っても取らなくても
同じだと思ふ。

まぁ、低機能で画質が悪くても一人で短期間であのエンコーダーを
作り上げたんで個人的には色々尊敬してるわ、Skal氏の事。

今のx264って、圧縮に力を入れすぎて、ちゃんと調整しないと画質悪いのが嫌い

いまのx264は赤色によわいんだっけか

陰部に弱い

>>626
一人でつーても、xvidからのコードの流用は結構あったんじゃね？

赤色が気になるなら色出力フォーマットでどうにかしな

猫科はよ

ジャイロゼッター、あちこちで赤色つかっててエンコの仕上がりがひどくなってしまう。

古いの使えよ

古いのはCPUの最適化ができてないからどんくさくてね。
古いのはSSIM/PSNRで比較しても数値がぜんぜん出ない
仕上がりは古い方のがまとまってる感じがするんだがなんだかな

Xeon Phiに対応するためにOpenMP周りでの最適化とかはせんのかなぁ。

あれって整数演算性能高いのか？

あれ、ベースはLarrabeeだからそこそこ整数演算もできるよ

あれなら面倒なことせずにもう一つCPU増やしたほうがいい気がする
次のhaswellだっけかあれならメモリ追加してる分gpgpuもましになるだろうしさ

そんなのよりAVX2のほうが効果ある

トリニチィのベンチでブルドザ系はAES速いのわかったけど
x264に役立てることはできませんか
暗号化なんてずっと使わないだろうし

暗号化も動画エンコもやろうとしていることは大して変わらない
ベクトルがちょこっと違うだけ。

専用ハードでしょ？あれ。

ひさしぶりにエンコしてみたがロゴ消しめんどくせー
せめてフェードやめろよー、たのむよー

簡単だろ

>>641
XOPやFMAはx264の役に立つ。

シーンカットを0にしてIフレームを入れないようにしたら
画質がかなり上がった
Iフレームはいらない子だったんだな

keyintごとに強制的に入るよ

そっちも入れない設定にした

ただし、あまりにもIフレームが少ないと
シークしたときにフリーズしたりするから、少しは入れたほうがいいよ

IフレームなんてDVDのチャプターを設定するようなものだから
そんなにたくさんいらないんだよな
DVDのチャプターなんて数分に1回しかないことを思えば

こいつは一体なにを言ってんだ。DVDネタはよそでやれよ

--preset veryfast --crf 22 --keyint 300 --min-keyint 30 --b-adapt 2 --b-pyramid strict --me dia --direct auto --trellis 2 --colormatrix bt709 --sar 1:1
で圧縮するとMediaInfoがRefFremes:3と返してくるのですがどちらが正しいですか？
cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=dia / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 （略

resとかlevelとかわからないからDPBサイズ分からないからあれだけど
b-pyramid 有効なので4になってstrictなので4-1=3
refオプションによる指定が1，b-pyramidによるRefが3，DPBサイズはその情報だけでは分かりかねるけどおそらく3以下（でないとおかしい）
よってRef=3となる
因みにこのrefはDPB制限のrefとは無関係なので気にしなくてよい

ごめん間違えた
b-pyramid 有効なので4
refオプションによる指定が1，b-pyramidによるRefが4，DPBサイズはその情報だけでは分かりかねるけどおそらく4以下（でないとおかしい）
よってRef=4
ここでb-pyramid strictなので4-1=3

すごく詳しく教えてくれてありがとう！よく分かりました

暗いところがモヤッとするのを軽減するオプションはありますか？

--qp 0

VAQ調整とビットレート盛り

--psy-rdの左が暗部に、右がディテールに効くって聞いたけどデマかね

VAQって具体的にどういじったらどうなるってのが分かりにくい

>>660
ffdshowとか使って量子化値を表示させるとどういう動作しているかよく分かるよ

--aq-mode 3　で幸せになれた

　同じ物をインタレのまま60iでエンコするよりbob化して60pでエンコした方が
ビットレートが下がるのが不思議だ……。

そら解除したら片側しか残さないから下がって当然だろ。

たぶん勘違いしたんだろうけど>664が普段どんなbob化をしてるのかが気になる

60iを30ｐにしてるだけだろｗ

つbob化

片側しか残さないって言い方だから誤解を招いてるだけじゃね
Bobってフィールド補完してるだけだし、もちろん補完のやり方によっては情報量が削られてビットレートが下がる

ん？もっと細かく噛み砕いて表現してやらにゃあかんのか。めんどくさｗ

>>668
>Bobってフィールド補完してるだけだし

だけじゃないよな
フレーム数も2倍に増やしてる

気の利いた物なら、動きのない部分はWeaveにしておく。

いちいち全部のことを一から説明しなきゃわからんのかいな

>>670
この流れでそこまで書かなきゃいけなかったか
それはすまんかった

>>673
この流れだからこそだ。
>>664を見ると、664はそこを分かってない可能性があるから指摘したまでだ。

Bobって誰だよ？まずそこからはっきりしろよ！

ヘイ、ボブ！

I have a BOB.

いいえ、私がトムです。

ではこの下駄箱は誰ですか？

>>674
誰も頼んでないのにお節介な上に、性格破綻かよ。

続きはtwitterで

>>680
それじゃお前にとってbobって何を解除してるんだ？

指摘に対して人格否定で反論するのは人としてカッコ悪いぞ

単にオレは>664は「解除したら片側しか残さない」という表現から
「Bobとは片方のフィールドを切り捨てて60iを30pにすること」
と見えたので解釈に誤解が無いかBob化方法を聞きたいだけだよ

倍になる解釈はあっても半分になるというのは
オレの文章解釈か>664の理解かどちらかがおかしいと思う

　えっと、480/60iをそのままインタレ保持オプションを付けてエンコするより、
bob化して480/60pでエンコした方が小さくなる、と言いたかったのです。
　確かに、bobにtdeintを使っているので、単純にbob(0,1)するのとは違って
必ずしも情報量が同等以上に保持されるとは限らないのか。

そりゃそうでしょ
情報量削ってBobすれば当然容量は減る

好きにしろよボブ、

ガッツを見せろよ、ボブ、

シャープ君の次はボブ君か
DTV板は次から次へと飽きなくていいな

bob bober the bobest

情報量削ってBobしたのに、Separateするとなぜか元の情報量と同じに戻るんですね

bobは情報削ることは無く、
フィールドをフレームに引き伸ばすことで、縦に2倍にするだけだ

だからそのフィールド補間のやり方によって情報量が決まるって話でしょ
ようはスレ違い

bobは単純にフィールドをコピーするだけなので補完のやり方など関係ない
情報量としては何ら元から欠けることもない

まぁ話を戻すとインタレのフィールドズレで輪郭等々ギザギザに成ってるよりも
フィールド補完で輪郭なんかも綺麗な線に成ってる方が圧縮する時に有利なのと
CRF設定だとfps増えたらフレーム単位のビットレート減らす仕様に成ってるから
ビットレート下がる時も有るだろとかそんな感じじゃね？

かっこよさを気にするあまりスレタイをガン無視した話題に染まっているようだが
ほんと、どうしようもないスレだなここ。

しょうもないことに難癖つけてくるのが２ちゃんですから

誰か教えて下さい。
keyint値の設定を60としてるのに間隔が59だったり、たまに58だったりする。
デフォルトの250にしてても、酷いときは229とかになったりする。
なぜこんなズレがでるのでしょうか？

esaやtesaでもmerangeは意味あるんでしょうか？

>>693
たとえばavisynthのBobは各フィールドをMitchell-Netravali法で補間する
さらに補間時には各サンプルを上下に4分の1サンプルずつずらす
単純なフィールドコピーとかアホなことするわけ無いだろ

>>697
--scenecut
シーンチェンジを検出した時に新規にGOPを開始して画質向上を狙う。

>>697
keyintはGOPの最大値を指定するオプションなので、当然それ以下にもなり得るから。

どうしても一定にしたいなら--scenecutを0にして--keyintと--min-keyintを
同じ値にすればいいんじゃないかな。どれだけの意味があるか分からないけど。

そんなのただの気休めだろ。

ごめんなさい。keyintのズレはnulフレームのせいでした。nulフレーム無の動画ならシーンチェンジがなければまったくずれなくなりました。自己解決しました。

>>704
画が大きく変わるのにIピクチャにせずにBピクチャにしておくなんて弊害以外の何者でもないと思うよ

いやボブのせいだろ、あいつのせいに違いないわ

俺はウィーブが怪しいと睨んでるぜ

イェーブの兄弟か

てｓ

シーンは変わらないけど意図的にこのタイミングでIフレームを入れたいって時に
なにかいい方法ないですかね？

qpfile

クソ高いIntelのコンパイラを買ってコンパイルしたx264.exeを配布

ってダメなのかね？gccとかMinGWでコンパイルされたやつしかない

>>712
以前やっていた人はいたけど、gccとの速度の違いは誤差でしかなかった。

性能に影響する部分はasm化してるだろうし、
一回しか通らないような部分は最適化されてもうれしくはないかも

猫科どうしちゃったの…

>>715
もともとあんなもんじゃなかったっけ?
ちょっと忙しいんだろう

猫科きてた

エンコめんどくさくなってきたHDD買い増し増し+たまにエンコで
頑張って後数年したら6TBoverのHDD出る頃にはエンコやめそう

普通は自動処理でエンコするから面倒も何も無いと思うんだが

自動でやるとただのトランスコード作業に成り果てる

>>720
トランスコードの使い方間違ってるな

エンコード ： 元データ→デコード→映像を読み取って再圧縮
トランスコード ： 元データ→デジタルデータのまま再圧縮

これであってる？

長くなりそうだからもう止そう

うん、用法の話になると長いからやめとこう

今完成まで進捗度何パーセントですか？

終わりなどはないさ、終わらせることはできるけど

旅人乙

WIN8にしたらどれ位早くなるんだろう？

となりの怪物くんOPをきれいに仕上げる設定どんなのありますか？
45秒付近と57秒付近がどうやってもブロックノイズ出るんです。

そのあたりのQPをqpfileで0にすればいいよ！

>>729
権利者なら自分でエンコしなくても外注に出すから設定なんぞ知らなくても問題ないだろ
犯罪自慢したいならスレ違い

何いってんだこいつ

その付近だけtrimで１フレームだけカットすれば？

http://twitter.com/charound30
なんなんこいつ

右腕疲れそう

>>731

きもいな

誰かNexus7用動画の最適設定教えてけろ

(´・ω・`)知らんがな

>>738
知らんが、携帯動画変換君のスレかブログでもうろついてくれば？

Nexus 7に搭載されるTegra 3はH.264@High,1080p, 40Mbpsまで対応するそうだが。

エンコ設定はPC用と一緒で良いが内蔵ストレージがMAX32GBで
SDカードも使えないことを考慮する必要はあるかも知れない

まあNASからWiFi経由で再生すればどうでも良いけど

画面解像度1280x800なんだから、720pで作ればいいんじゃない？
再生できるからってわざわざ1080pにする必要はないでしょ

そうなんだサンクス
一応1280x720と@Highで作ってみます

levelは？

Nexus7は480pでも割と綺麗に再生されるのがいい
USBメモリの容量も節約できるし

720pならmain profileのがいいんじゃね？

なぜだってばよ

mainはhighにくらべてエンコ速度が2~3fpsぐらい早くなる。
mainはhighにくらべてb/refの制約が軽減される。
mainはhighにくらべて余計な量子化がされないので色滲みが低減される。
Nexus7（tegra3)はどうだか知らないが
これまでのtegra2はmain profileまでしかHW支援してくれない。
ちなみにprofileは720pなら 3.1〜4.1の範囲で微調整すればいい。
720pなのにHigh10+5.xとかやってるのをみるとバカじゃないの？っておもうけどさ

自分の好きなやり方以外認めない攻撃性

>>749
バカじゃないの？

不満があるなら自分でエンコして比較してみりゃいい。
720pでHighにしてエンコしてよくなった試しがないから無意味だとスグ気づく。
720p以上だとま、それなりにマシになると思うがそれでも微妙な差。

プリセットを使用とか標準のパラメータしか使わないとかなら尚更High以上は意味がない。
CPUへの負荷テストもかねてなるべく長時間エンコできるようにパラメータを工夫したいなら
不毛覚悟でLv5.1@high以上でme=tesa、subme=12、ref=16 にあわせりゃ面白いことになる。

ふむ
main profileって720p未満に使うものだと思ってたけど（一応HDなので）
720pでもいいのか

--profile main 挿入しても受け入れてもらえなかったので
--partitions i4x4 --cqm flat を挿入して10-bitエンコ

A) --partitions i4x4 --cqm flat 挿入
x264 [info]: SSIM Mean Y:0.9955319 (23.499db)
x264 [info]: PSNR Mean Y:50.723 U:53.851 V:53.335 Avg:51.440 Global:50.126 kb/s:1534.30

B) いつもの --crf18その他諸々
x264 [info]: SSIM Mean Y:0.9956030 (23.568db)
x264 [info]: PSNR Mean Y:50.796 U:53.888 V:53.365 Avg:51.504 Global:50.192 kb/s:1503.36

A) ttp://www.dotup.org/uploda/www.dotup.org3582205.png
B) ttp://www.dotup.org/uploda/www.dotup.org3582202.png

A) ttp://www.dotup.org/uploda/www.dotup.org3582218.png
B) ttp://www.dotup.org/uploda/www.dotup.org3582214.png

なんか輪郭線ぼやけてない？

というかよく考えてみたら10bitじゃ--profile mainは扱えないのか

--no-8x8dctを付けると(main profileにすると)画質とエンコ速度が上がる代わりに再生負荷が増える（余計な量子化がされないので）
ただしSD解像度(720p程度まで)なら負荷が増えても大したことないのでこちらの方が良い
という認識で合ってる？

highの利点
高解像度時には8x8 dctがおいしい。
最大ビットレートが1.25倍
量子化マトリクスを指定できる
4:0:0を扱える

こんなもんだ。念のため仕様書読み返してみたがこれ以外の違いはないと思う。

mainのつもりでやってたせいで--no-8x8dct付け忘れてたorz

A) --no-8x8dct --partitions i4x4 --cqm flat 挿入
x264 [info]: SSIM Mean Y:0.9953638 (23.338db)
x264 [info]: PSNR Mean Y:50.476 U:53.878 V:53.362 Avg:51.247 Global:49.920 kb/s:1488.52

B) いつもの --crf18その他諸々
x264 [info]: SSIM Mean Y:0.9956030 (23.568db)
x264 [info]: PSNR Mean Y:50.796 U:53.888 V:53.365 Avg:51.504 Global:50.192 kb/s:1503.36

A) ttp://www.dotup.org/uploda/www.dotup.org3582448.png
B) ttp://www.dotup.org/uploda/www.dotup.org3582202.png

A) ttp://www.dotup.org/uploda/www.dotup.org3582449.png
B) ttp://www.dotup.org/uploda/www.dotup.org3582214.png

>>758
つまり少しでもビットレートを抑えたいとかでなく、画質優先で考えるのであればMain Profileのほうがいいってこと？
ただ、カラーバンディング対策とかで10bit使おうとしたらHigh Profile前提になるだろうから、 High Profile設定から会えてあえて8?8 dctを省けばほぼMain Profile相当ベースになるのだろうか？

正直テストエンコのソースがアニメってどうなのよ
テスト用としては偏りすぎだろ
実写使えよ

バンディング対策は8bitのままavsでごにょごにょさせた方が楽。

>>762
ゴニョゴニョって？

フィルタによるバンディング低減と、x264エンコ時に発生するバンディングを抑えるのはまた別の話じゃないの
まあとにかくバンディングを消したいってんなら両方やればいいんだろうけど

>>761
x264でエンコするような奴ってアニオタぐらいだろ

こういう人レイシストって言うんだよね
学校で習ったよ

だってアニメ以外エンコしてもあんま縮まないじゃないですかあ(´・ω・｀)

>>759の違いがよくわからない
というか--no-8x8dct入ってない方が若干ノイズも少なく見えるんだが

基本的にsubme等で手を抜かなければhighでいい、というかmainだと無駄に選択肢を狭めることになるんじゃないの？

各自好きにエンコすればええ

ttp://pop.4-bit.jp/　からダウンロードした x264-r2216_win64_gpac.zip の中の
x264.r2216_win64g.exe でエンコードした動画ならWindows7のWMPでも正常に再生出来たのですが、
ttp://x264.nl/　からダウンロードした x264.exe でエンコードした動画では、MPC-HCやGOMでは正常に再生出来るのに、
WMPでは音しか出ません。何が原因なのでしょうか？

>>771
エスパーがいない事が原因です

http://anago.2ch.net/test/read.cgi/streaming/1333673572/770

L-SMASH muxer使ってるなら
この辺で話題になってたmajor_brandが何なのか話かな

いまだにmp4で出力する人いるのね
テスト用途やL-SMASH込みでビルドしたエンコーダ使うんならまだわかるけどさ

何言ってるの、この子？

自分の事は一切言わずに上から目線で叩きたいだけの哀れな子です

は？

>>774
こいつに言いましたゴメソなさい

上から目線に見えちゃったか
すまんかった、x264エンコーダで直にmp4出力するメリット、意味、必要性がわからないもんで

は？

ｘ264はワシが育てた

>>773
何とか再エンコせずにWMPで再生可能には出来ないのでしょうか？

>>782
何使ってやってるのかくらい言いましょう

そのファイルよこしてくれるなら見て答えてやってもいい

>>782
wmpの正式名称＋コーデック もしくはcodecで検索

>>760
画質でいうならHighが最強にできる。
ただし、意味がわかっている必要があるけども。

H.264は各種アルゴリズムを、大きくはプロファイルで区切って使用できるかできないかを決める。
Baselineでは基本的なセットのみ。
MainではBaselineに対しBピクチャーとインターレースサポート、CABACを追加。
HighではMainに対し8x8 dctを追加、量子化マトリクスの指定を追加した。
大雑把にはそんな感じ。
実際にはBaseline→Mainで削られた機能もあるけど、まあまず使わないのでどうでもよい。

プロファイルの違いで増えるアルゴリズムはエンコード時もそうだけれどもデコード時にも負荷を上げる。
ただ、選択肢が多い方が同一ビットレートにおいてより高画質にしやすいため、制約がないほうが有利になる。
当然、ビットレートを考えないならプロファイルの違いはあまり大きく出てこない。

再生に問題でたらもう一度通せば良いだけだろ

でも結局エンコ本数が増えてくると画質は程ほどで
エンコ速度重視なパラメータに落ち着くんだよ。
丸1日で何本エンコできるでも違ってくるからな

そのへんはCPUの性能に依存かねぇ

>>788
最後に（ｷﾘｯ つけ忘れてるぞ

寝てる間とか外出中なら関係なくね

帰宅までに終わらないぐらい低スペなんだよ、きっと

>>788
つ QSVEnc

6コアインテルを4.5GHｚ以上で回してれば何やっても楽勝

>>794
それでもHD動画をそれなりにフィルタ掛けてtesaとか激重設定で、しかも10bitでエンコだと
毎日何本もってのはきついよ・・・
極端な例だけどさ

フルHDをtesaはアホ過ぎる。まだumhでme rangeを大幅に盛った方が画質も速度も良い
フルHDをtesaでme range 64なんてすれば2687w×2のフィルタ無しでも1fps切るだろうしな

なんでもなかったですはい

>>797
どんまい(´・ω・｀)

aq modeの1-4のやっていることの違いって何？
なんとなく、シャープネスやモスキートノイズの程度に違いがあるってことはわかるんだが

あと、画質の良し悪しを比較するにはどういうシーンを使用するべきなのかな
動いてるシーンか止まっているシーンか

もうインテルは6コア（12スレッド？）なのか
未だに鼻毛鯖の2コア2.8GHzセレロン使ってるわー
photoshopCS6なんかもサクサクなのかね

>>799
＞画質の良し悪しを比較するにはどういうシーンを使用するべきなのかな

同じような色が平坦に広がってるシーンとか、照明や太陽光などで光が放射状に広がるようなシーンとか
そういうところでバンディングが発生しやすいから

動いてるシーンのほうが違いが出やすいにきまっとる

>>793
それじゃスレチだろボケ。

>>803
　　　　∩＿∩　　　　　
　　 ／ ＼ ／＼　　　
　　|　 （ﾟ）=（ﾟ）　|　　　　人人人人人人人人人人人人人人人人人人人人
　　|　　●_●　 |　　 ＜ 　お前の用途がスレチ何だよ二度とこのスレに　＞
　/　　　　　　　　ヽ　 ＜　来るなって言ってるんだよ言わせんな　　　　　　＞
　| 〃 ------ ヾ　|　　　ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ
　＼＿＿二＿＿ノ　
　　　　　　　　　　　　

またおまえか。くだらないAA貼る暇があるならビルドに参加しろよ。

相変わらず棒だなｗ

どうせなら竿にしておけ。

r2226

r2229だった、すまぬ

>>809
弘法にも筆の誤りだってばよ。

空海さんの超人伝説は空海没後に比叡山にぼろ負けした弟子達
の創作だかんな

>>808
ついでに内容も貼ってくれたらうれしいな

>>812
r2220 Fix ALIGNED_ARRAY_EMU macros on ICL
r2221 Fix reconfiguring to crf=0
r2222 Fix crash with no-scenecut + mbtree
r2223 Disable ARM NEON MRC CPU test for Apple devices
r2224 x86inc: only define program_name if the macro is unset.
r2225 x86inc: Rename 3dnow2 to 3dnowext
r2226 Add support for the ffmpeg/vapoursynth high bit depth y4m extensions
r2227 Update level dpb size calculation to match newer H.264 spec
r2228 Improve slice header QP selection
r2229 Attempt to optimize PPS pic_init_qp in 2-pass mode

openclどした

>>813
ｔｈｘ

r2220 Fix ALIGNED_ARRAY_EMU macros on ICL　ICLのマクロ配列を修繕した
r2221 Fix reconfiguring to crf=0　crf=0を再設定した
r2222 Fix crash with no-scenecut + mbtree　no-scenecut + mbtreeでクラッシュするのを修正
r2223 Disable ARM NEON MRC CPU test for Apple devices　アンチアップルなので翻訳放棄
r2224 x86inc: only define program_name if the macro is unset.　日本語でおｋ
r2225 x86inc: Rename 3dnow2 to 3dnowext
r2226 Add support for the ffmpeg/vapoursynth high bit depth y4m extensions　ffmpeg/vapoursynthで深い色深度が扱える拡張を追加したぞー
r2227 Update level dpb size calculation to match newer H.264 spec　新しいH.264に対応できるようDecoded Picture Bufferのレベルを上げた
r2228 Improve slice header QP selection　QPを選ぶときのslice headerがよくなったよ
r2229 Attempt to optimize PPS pic_init_qp in 2-pass mode　2-passのPicture Parameter Setの最適を試みました

nlは2216のままだた

そういえば、x262はどうしたのだろう

>>816
ちょっと気まぐれレビューっと。頑張れよ〜
> r2221 crf=0を再設定した
crf=0への再設定を修正（途中でロスレスには切り替えできないため）
> r2223 アンチアップルなので翻訳放棄
林檎が勝手なようにCPUの仕様を変えたんで、今クラッシュしかしないNEON機能の一つの
のチェックを林檎なCPUで実行されないように変更。
> r2224 日本語でおｋ
x86inc（x264asm）でprogram_nameがまだ指定されてない場合のみデフォ値を指定
> r2225
x86inc (x264asm) で3dnow2を3dnowextにリネーム
> r2226 ffmpeg/vapoursynthで深い色深度が扱える拡張を追加したぞー
ffmpeg/vapoursynthが実装したY4Mでの深い色深度用の拡張に対応した
> r2228 QPを選ぶときのslice headerがよくなったよ
スライスヘッダーのQP選びをよくした。前は前スライスの最後のマクロブロックを
参考していたが、今は現スライスの最初のマクロブロックを参考するように変更。

>>817
なぜか未だにノートパソコンでやってるけど、（多分）壊れはじめてるHDDのせい
でフリーズし始めたんで、未だにビルドしてない。と言っても、丁度BugMasterの
バグフィックスが現れた　＼(^o^)／

ヨブさん？

r2230 Fix possible issues with out-of-spec QP values
これか

popさんの所にr2230確認

ちょっと前にあったMainとHighプロファイルの違いが気になったから
実験してみようと思うんだけど、どういう条件でしたら最適でしょか？
crfは高めがいいとか、オプション○○は切っとけみないなのはある？

そんな感じなら比べても判別出来ないでしょ

x264.nlで更新がようやく入り始めたっぽい。jarod氏の同期システムは
いつも通り時間が妙にかかる。

せっかくネットワーキング付きでx264ビルドしたらx264cliのlibavformatの使用方法が
間違っててクラッシュしやがる。とりあえずkierank氏がパッチを作ったらしいんで、
そこらへんに迷惑かけてパッチの正式な提出をお願いしてみるか・・・

ヨブさんちーっす

あえて超低画質でエンコして
その劣化ぶりを見るのもおもしろいよな

nl r2230
popさんのとこ r2230
たくあんさんのとこ r2230
今のところr2230来てるのはこれくらいかな

JEEB
06_taro

早く2230お願い！

さん忘れてた
もう一回



JEEBさん
06_taroさん

早くr2230お願い！

自分でビルドすればいいのに

git clone git://git.videolan.org/x264.git
cd x264
./configure
make

ね？簡単でしょ？

チョ〜〜わかんね

>>833
マジレスするとそれだけじゃどうしようもない。
それはmakeできる環境が整っている人向けの手段だし

どこのビルド使っても内容同じなん？

当ててるpatchで使えるオプションが違ったりするが設定同じでエンコすれば結果は基本的には同じになる

>>836
もちろん組み込むpatch、ライブラリによって違うけどx264の基本的なところはみんな同じだよ
中にはpatchというレベルを超えて自分でソースコード大幅に弄ってるビルダーもいるかもだけど

06_taroさんのr2230ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!

でも気になることが…
2. <x264> (important!!) (should have) fixed a regression in fgo patch, usually occurs on still or
slowly moving objects with clean background, if anyone using this patch grabbed from rev2085
to rev2216, please replace your patch from here, thanks \Noir/ for reporting and testing

06_taroさんのはenable-nonfreeだからDLしちゃダメよ

>>840
どういうこと？

ライセンス違反
本来配布してはいけないバイナリを配布している

まさか、avs4x264modの作者がライセンス違反をしていたとは…

>>840
もしかして:ライセンス違反のファイルをDLしただけでOUT(法的に)？

GPLのライセンスなんて無視でいいんだよ。

>>843
nonfreeな部分が何処なのかは知らんが、どっかの特許を侵害してるようなのだったら
親告罪なので訴えられない限りOUTじゃないし、訴えるとしても配布した方だろう
（まあお金を取りやすい所を訴えるもんだからお前が大金持ちならわからんが）

全てのGPLに死の鉄槌を！

>>845
ダウンロードした側は違反してるかどうかなんて、わからないから
訴えても勝てない、それを認めると権利者と組んだ罠サイトを仕掛け放題になる
親告罪なんだったらDLしたやつだけを狙い撃ちで訴えれることになるしな。

>>847
まあ言い訳は警察署でゆっくり聞こうか。

となるわな。

>>843
＞avs4x264modの作者がライセンス違反をしていたとは…
実は知らないのよｗ

>>847
＞ダウンロードした側は違反してるかどうかなんて、わからないから
helpも見ない初心者だからだろ
x264_64_tMod-8bit-all-fullhelp.txtにnonfree: yesとｗ
発展途上国だから何でもOKよ

>>840 と言いつつDLしてしまったがなｗ

libfdk-aac: GPL非互換
faac: GPL非互換
qtsdk: GPL非互換

GPL違反は使用者側にも同様に適用されます

いちいち沸くなこういう難癖厨、鬱陶しいから消えろ
書くなら本人のところに書け、こっちは使えればどうでもいい

>>848
日本に善意の第三者が、著作権侵害で刑事事件沙汰になる法律はない
改正著作権法でもプログラムは対象外。

>>851
GPLは日本の法律じゃないから、日本の法律の範囲でしか裁けない。

>>853
は？法律のことなんて一切言及してないけど
自国の法律にさえ違反しなければどんなルールも破っていいっていう倫理観の欠片もない
>>853 みたいな土人は勝手にGPL違反すればいいよ

法律違反がどうこうじゃなくてGPLの元公開されてるOSSを利用する上で最低限守らなければならないルールの話をしているだけ

>>854
親告罪だの警察のって言ってんだら、元が法律の話だろ
ルールの話じゃないだろが、日本語が分からん奴は祖国に帰ってろよ。

>>855
その話してるのは明らか俺じゃない別人だろ
頭大丈夫か？

>>856
俺は大丈夫だが、お前は駄目っぽいな。

>>857
もう勝手にすればいいけどそもそもそこまでGPL違反を擁護する意味がわからない
おそらくそういう価値観や考え方が理解できない原始的思考にのみ則って行動するかわいそうな人なんだろうけど

何も知らんのにDLしたら訴えられるだの警察だの、これは日本の法の範囲で保護されるべきケースだ当たり前だろ気違いか。

本人に言えっつってんだろカス
ここで喚くなボケ、俺らは利用者でしかねえんだよ
逮捕されるわけもねえんだよ阿呆が

ポリってのがいかに適当な組織かを理解してないのは、おこちゃまと言われてもしょうがないな。
岡崎とか大阪とか、何度も繰り返してるだろ？

GPL違反していると分かっていて配布するほうも使うほうどうかとは思うが
これで分かったんだから今後気をつければいいじゃない

MPEG-LAの特許が有効な日本で、H.264やMPEG-2関連のバイナリを配布するのも本当は危険だな。

ルールは無視しても捕まらなければ何でもOKと言っている奴らに言いたい
お前らの思考は己の利益だけを考えて周りの迷惑顧みず金儲けに邁進するシナ人と同じだな
または他人が開発したものに敬意も示さずパクりまくって何が悪いニダと開き直るチョンと同じとも言える

GPLの話題が出るとどのスレでも気持ち悪いのが湧いてくるｗ

何と戦っているのかさっぱりわからん
エンドユーザばかりのここで言っても無意味なのに

そんなの気にしてたらハゲるぞ

アホにかまうな

quicktime最新版でx264_l-smashでqtaac使った時muxの最後で異常終了するようになってしまったんだがうちだけだろうか

quicktimeロールバックしてどうなるか試してもらえません？

>>870
QuickTimeの過去バージョン(7.7.2)落としてきてインストールしてみたけど、異常終了は改善されず
すまん、quicktimeが原因ではなかったようです

ログを見ると、昨日(14日)の朝の日次エンコードバッチまでは正常にエンコードできていて
今日15日の朝から異常終了になっているので、思い当たる節としては、14日のWindows Updateの配信かなぁ…

別PCでも試してみたらこちらも駄目になっている
Windows Updateの更新を削除してみるか、14日以前のバックアップからリストアしてみるか…

あと、音声のみ先にqaacでエンコードして--audiofileで取り込んだ場合は異常終了しない模様

>>871
ん？>>869に書いてる「qtaac使った時mux」ってのは--acodec qtaac使ってるってこと？
自分でビルドしたの？

>>872
うん、猫科のx264_L-SMASH_clone.shで持ってきたソースの自ビルドです
configureは--enable-win32thread --enable-strip --qtsdk=/C:/QTSDK --enable-nonfreeのみで
入力はavs

>>873
手元でも再現したわ

>>874
あちゃーそちらでも同様ですか
14日00:00の時点のバックアップをベアメタルリストアしてみたところ、正常にエンコード出来る事が確認できました
やはり、14日のWindows Updateのどれかの副作用で異常終了するっぽいです

>>875
OSは？うちは7の64bit

>>876
Win7 x64とWin8 x64です（どちらでも15日以降は異常終了）

く、Windows Updateで入った更新を削除して行ったら、管理データベースが壊れたのか、
アンインストールのとこに更新プログラムが表示されなくなって、Windows Updateもインストールの準備をしています...から進まなくなったｗ
こっちのPCもバックアップから戻すしか無いか…
おのれMS

原因判明した

結論から言うと、結局のところ原因は最初の書込みのQuickTimeの最新版(7.7.3)でした

>>871ではQuickTimeのアンインストールファイルを使って削除したものの、インストール時に同時にインストールされていた
Apple Software Support及びApple Software UpdateというApple系の共通コンポーネント？が残ったままになっていました
よって、その後に7.7.2を入れても上記のコンポーネントが7.7.3付属の新しい方のバージョンのままで上書きされず、症状が改善しなかった様子

上記２つのコンポーネントもコンパネからアンインストールし、その後に7.7.2を入れたところ、無事正常にMuxまで終わるようになりました

疑ってごめんよMS

>>879
なるほど。検証おつ
しかし今x264-audioにqtaac組み込んだ人いないから直りそうにないという・・・

QuickTimeなんてインストールするから

いまだにneroとか使ってんの？

おれは avs2wav4g -> neroaac だな。

音楽ソースと会話メインのソースとじゃエンコーダの優劣が違ってくると聞くしまあ好きなの使えばいい

そんなもんAACにエンコするなら殆ど変わらんわ。

というか音声エンコすることってあまりないな

そりゃ、FAWかaaceditもしくは再エンコかくらいだし

ogg一択やろ
スマホ用ならHE-AACv2使うけど

一択じゃなくね

oggとHE-AACv2比較とか、わけわかめな事するなよ

好きなの使えばいいだろ
AACエンコーダについて熱く語り合いたいならAACスレでやってくれ
まああっちは音楽ソースの話メインのようだが

もし音域までを重視するならx264+flac+mkvの1択になるわけだが

動画プレーヤーでflac対応は、まだまだ少なくね？
LPCMでもそんなに容量的に問題ないような

x264+flacとかアホかよそのほとんど認知出来ない数百kbpsでどれだけ画質が上げられるか
10Mbpsとか使う素材なんてまずねえしもったいない

alacは？

自分の方法が至高だと信じて他人のことをアホだのバカだのと言うしか能のない糞どもの溜まり場

無圧縮で用意されてるものを非可逆にしたくねぇ

それ以前に音声エンコーダのことをこのスレで語られても・・・
x264エンコーダにライブラリとして組み込んでビルドって話ならわかるけど

dtsでも使えばいいんじゃない？

>>894
>ほとんど認知出来ない
PCでしか再生しないから問題ない。

>どれだけ画質が上げられるか
flacは音声コーデックな。画質は関係ねーよｗ

>>900の読解力は（アカン）

x264+flacとx264+LPCMとの差が数百kbpsだと言ってるんだろう
まあこれは正しい(LPCMは1500kbpsだから）
それで音声でケチった数百kbpsを画像に回しても
画質がどれだけ上がるか疑問だと言ってるのかと思うが、
それと最後の1行とのつながりはよく分からん

takやったらもうちょっと差が開くし（震え声）

文章の整合性と一般常識に照らし合わせたらこうじゃない？

普通多くても5Mbps程度のエンコで、x264+非可逆音声に比べて差が認知出来ないFLACを使うぐらいなら、その数百kbps分画質に回せばどれだけ画質があげられることか（だいぶ上げられるの意）
10Mbpsぐらい使うエンコならそれぐらい音声に使っても良いけどh264エンコでその場面はあまりない
だからx264でFLAC使うのはもったいない

動画の音声が可逆だと嬉しい場面って、楽曲のPVとかコンサートとかの音源で
別途単体の音声ソースが付属しない場合とか？

科学研究とかでソースの可逆性を求めるなら、音声だけじゃなく映像の方も可逆が必要だよね

めんどくせー、そんなん全部気分の問題だろ。

音楽メインで映像は静止画って動画もあるからねえ

>>904
的外れ。
x264の映像エンコと、flacの音声エンコは個別にエンコードするものだろ？
まさか同時にエンコードさせようとしてるのか？

ID:HN5mVI0oはネタでやってるんじゃなければマジのアスペだなこれｗ

可逆で取っておくってのは一般用途としては原本のままの形でアーカイブとか
コレクションしたいって感じだと思う
そういう人の気持ちは分かるし、技術が進歩して新しいコーデックが流行っても
可逆の原本を持ってさえいれば全く問題ないので気持ちの問題だけでなく
実質的な利点もあるんだけど

スレ的には映像部分はx264で再圧縮しているのだろうから、音声「だけ」可逆って
ことなんだよな？　その気持ちは確かにちょっと良くわからない
聴くだけならFLACの1/3のビットレートでもAACやVorbisならオーバーキルだよ
音楽だろうが関係ない

自分がそうだからって
他人がそうとは限らないだろうに

ネットってなんでこういう人多いんだろう

音声のロスレスは普通にBDとかでも使ってるじゃん
FLACは非圧縮と比べた時のビットレートがおよそ半分程度と聞いた
つまりもとが1411kなら700kくらいだ
たった700k、じゅうぶん実用的な数値だろう

>>911
大抵の人はわかっていると思うぞ

そのうえで自分の意見を発するのは大切
まずいのは他人の意見にまったく耳を傾けないということ

個人的に今のスレの流れはけっこう好きだけどな

ミュージックビデオやコンサートのライブ映像とかなら、
ロスレス・オーディオも選択肢に入るかも。
まぁ、ロスレスで生録したという場合に限られる選択肢ではある。

アナデジ移行の際、同一環境なのに音声が薄っぺらくなってしばらくアナログでも視聴してたな

>>914
収録環境は大抵DSDだからBDの可逆192kHzでも足りてないよ

それだと可逆じゃなくて非可逆だな
じゃないとAACでもソースには足りてないけど可逆だよって言えることに

約1名、読解力に問題のある奴がいるな

>>916
足りていようがなかろうが、それが選びうる最高のフォーマットだから問題ないでしょ。
非可逆よりはましなんだから。
ロスレスかロッシーかの議論をするレベルの中で、
制作レベルの高音質をそのまま無理して持って来いとまでは言わないと思うけど。

読解力に問題がある人を装って煽りまくればあっという間にスレが荒れて
ゴミスレ化するということか
レス乞食愉快犯には便利な手法だな
とりあえずみんなスレタイ100回音読して頭冷やそうぜ

>>919
いや、その場合非可逆よりマシとは言うのは正しくないな
「可逆」と「非可逆」で比べたら、
可逆でも、情報量を削らないと収められない状況では、結局は非可逆圧縮(というか非可逆間引き)になる以上、
同じビットレートを使って聴覚的により良い圧縮が出来る非可逆のほうがマシというのが正しい結論になる

言うなら具体的に、BDで選べる中では可逆にならなかったとしてもDTS-HD High Resolution AudioよりDTS-HD Master Audioの方がマシだから、と言うべき！

＞可逆でも、情報量を削らないと収められない状況では、結局は非可逆圧縮(というか非可逆間引き)になる以上
すいません、日本語でお願いします

スレチ

>>922
ロスレスフォーマットに入れる為にソース削って可逆圧縮するならデコードしてもソースには戻らない（ので不可逆と化す）
動画に例えるとリサイズで縮めた後にエンコードしてたらロスレスだからってソースに戻せねーよ的な

可逆でも、情報量を削らないと収められない状況
にツッコミが入ってるわけだが

俺は面倒な作業をしてる人もいるんだなと関心したが
所詮自己満足に何を噛み付いてんだ？

すまん誤爆

>>925
言葉の綾へのつっこみなら「可逆」→「可逆フォーマット」って事だと思われ

忘れられてそうだけどx264ってqp=0にするとロスレスになるんだっけ

つーか、おまえらロスレスでエンコしたもんを元に戻したことあんの？
ましてや動画用にmuxさせた音声データを元のソースに戻すような基地外が実際いるのか？
ロスレスを元に戻すとか、どう考えても頭おかしいだろ。

ロスレスで保存してるソースはあるよ
UtVideoだけどね
x264で保存し直そうかと思ってる
そうなるともとに戻すことになるね

完全にレアケースだろそれ。普通はエンコ->muxした音声を元になんて戻さないから
それに編集してカットしている時点でたとえロスレスでもソースと同等の状態には戻らん。

勝手にカットされたりフレーム落とされるようなエンコーダの問題による悪影響ならともかく
自分で意図的にカットした部分は元々要らない部分だからそれでいいんじゃないの

いやｗ、だから要る要らないの話じゃないだろ
おかしな方向へ話をズラそうとするなよ。

>>930
ん？毎回視聴する度にデコードしてソースに戻してるだろ？
まぁエンコしたら満足して全く視聴しないこともまれによくありますが

>>934
全編そのままソースに戻す必要があるなら編集せずにエンコするだけでそ？
お前が何をしたいのかわからんｗ

ID:qJzvql71のロスレスの定義が皆とずれた独自定義な気がする

わざわざもとに戻さなくても直接x264エンコーダに渡すだけでいいんじゃ

ていうか上から読んでみるとロスレス以前にもとに戻すの意味もよくわからん

さすがにこんな勘違いをしてる人は居ないとは思うが

ソースに戻す≠ストレージ上にソースファイルとバイナリ完全一致状態で書き戻す

どんどんおかしな方向へ進んでいくんだな。
ちょっと展開が面白そうだからもう少し放置してみるか。

もしかして、昨日の読解力に．．．の人、またやってるの？

と思ったが、これ多分ID:qJzvql71の人の戻すってそういう意味（元のファイルフォーマットに戻す）っぽいなｗ
そういうことなら普通は確かにそれは滅多にしないだろうから安心しろｗ

話題が逸れて言葉の定義争いになったら終了

そんなことよりベンチスレどこいったのよ

>>945
http://anago.2ch.net/test/read.cgi/jisaku/1352352619/

>>946
ありがとう！

で、アナログビデオはどのサイズでキャプチャすれば良いんだ？

1920×1440

VHSとかじゃないの？
NTSCなら720x480でいいんじゃない

>>948
ソースと同じが安定

720x480 あとは好みでクロップとかリサイズ

懐かしいなあ…
クロシコのSAA7130チップのは704x480が最大だったんだよな
今でもたまにふぬああでビデオテープをキャプったりしてるけど

ふぬああとか懐かしすぎるｗ

なつかしいなふぬああ

カノープスは飼い殺されたな

某スレで議論になってるんだが
8bitソースを8bitと10bitのエンコーダでエンコした場合（設定は同じで、フィルタは一切使わない）
出来上がったファイルの画質はどちらも同じで、10bitだからって画質の向上はしないの？

画質をどう定義してるかは知らんけど
エンコード時に生じるバンディングを防ぐ点では8bitは10bitにどうやっても勝てない

なるほど、10bitでエンコする方が8bitよりもソースに忠実な結果になる訳ですね

download板か…　あそこはいつもその話題で荒れているな。
　
8bitだと動きのない暗いシーンとかだと、エンコード時にソースにはなかった
バンディングが発生しやすい。それを防ごうとx264のパラメーターを
調整すると、バンディングは軽減できても他に悪影響が出る。

10bitだと、バンディングはほとんど出ないから、バンディングの出やすい
ソースなら10bitの圧勝。バンディングの出ないシーンなら大差ない。

シュタゲみたいなソースだと分かりやすいと思うよ。

いや暗部の保持に雲泥の差がある

サイズも小さくなるし基本的に8bitでエンコードしないといけない場合を除いて自分用の保存するためのエンコードは
全部10bitでやってるわ

保存用はエンコなんかしないでソースを残すわ

いつエンコするの？
見るだけこそまんまソースでいいと思うが

まぁ俺もお気に入りはソースも残すけど
不思議な日本語だと思って

ソースも残すしエンコもする

わざわざ8ビットでやってるやつなんかいるの

PC以外で見る場合は8bit以外に選択しないだろ

Android端末で普通に再生できるけど

Androidに使われてるSoCで10bitハードデコードできるやつあったっけ
ソフト処理だとバッテリー食い過ぎて使い物にならないぞ

>>964
俺にはお前の言ってることの方が謎だ
保存用ならわざわざエンコしなくてもソースそのままでいい

いつエンコするのか答えてない

ハード支援できるようになったら10bitは考える

h265で一般的になったら考える
それまではなんか怖い

疑問なのは8bitの色数でバンディングが埋められないわけじゃないはずなのに
なぜ普通にバンディングが発生したり暗部がもやっとするのか、なんだ
少なくとも色数が足りないわけでは決してないはず

使用できる色の数に起因していると見たことがある
10bitはエンコしてもほぼすべての色が使えるため諧調割れに強い
対して8bitは使用できる色が1/4くらいまで減るとかなんとか
どこかのサイトでデータあったはずだけど忘れた

8bit→8bitにエンコしたときの話だろ？

>>975
それはRGBに対しての話だったような

>>974
8bitYUVソースなら圧縮時の精度でしか無くて
行き着くところ8bit YUV420でも8bit YUV420で可逆圧縮できる
8bitか10bitかというのは適当でも圧縮しやすいとかそういう違いであって
8bitソースに対して8bitでエンコードすると画質が云々というのは少し違う

同程度のディテールを保持するにはその部分に少しbitを盛らないといけないが
それが面倒なら10bitで適当にエンコードするという選択肢はありだと思う

色成分が違うだけで8bitのRGBも256階調だぞ
>975が4096階調の10bitを8bitでエンコ場合と勘違いしてそこから話がカオスになっトル

>>978
色空間が違うよ
YUVのほうが4倍くらい広さがあって中スカスカ
だからYUV:RGBは1:1じゃない

だからRGBとYCbCrの話、それと8bitと10bitの話がごっちゃになってるってことだってば
YV12がRGBになっても8bitである限り4倍にはならないだろ？

YCbCr -> RGBの精度は、前者を10-bitにすれば良くなる。
諧調でしか分からない違いだろうが。

ファイルを小さくしてバンディングは再生時にフィルタでごまかす

YCbCr8bit -> RGB24bit
YCbCr8bit -> YCbCr10bit -> RGB24bit
よく見ろ、本当に下の方が精度が高いと思うか？

ume

もういいよ

>>983
YCbCr8bit -> YCbCr16bit -> YCbCr10bit -> RGB24bit

こうやってditherやflash3kyuu_debandを使えば、諧調は元よりも綺麗になる。

>>986
途中でフィルタを挟まない限り同じだよ

>>987
バンディングを気にしてHi10pを使う人なら、挟む人の方が多いのでは。

そういうことか納得

馬鹿だ…

>>959
そもそも放送ソースは殆どが8bitだし、DVDソースでも殆どが8bitだろ。
それをむりやり10bitに変換したらソースの風合いが消えてしまうし
自己満足＆オナニープレイ程度の恩恵しか受けれんよ。

10bitにすれば表現可能な色数が増えるからバンディングが軽減されるって論理はわかるが
10bitは殆どの場合デコード（再生）する環境に依存するから、10bitに対応しない環境だと
結局画質なんて殆ど変わらん。それにわざと階層を出しているアニメだってあるんだから
余計なことはしない方が絶対いいんだよ。

それを決めるのはお前じゃない
720pとかの解像度のもの拡大しないのあんた

ソースが8bitだから10bitにしたら風合いが消えるとか馬鹿だろ。

余計なことしないならエンコするなよ

せっかく汎用性の高い元ソースを残さないで
いつ規格が消えるかもわからないx264-10bitで保存用とか言ってるやつが本当の馬鹿
これ豆知識な

>>992
いや俺の言うことが一番正しい。おまえの意見は却下だｗ

DivXのものまだ持ってるんだが今でもバリバリ見れるよ
これ現実な

俺の場合だとBDはエンコしない。放送ソースとDVDはエンコする。
HDキャプはHDDの無駄だからもうやめた。

次スレ立てようと思ったらはじかれちゃった。
だれかお願い

次スレのテンプレはたぶん↓のでいいと思う。

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

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

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

[本家]
http://www.videolan.org/x264.html
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)
http://doom10.org/index.php (公式フォーラム)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

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

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

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

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。