x264 rev41

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チャンネル）

[バイナリ]
　　...::: Komisar x264 builds :::...　　http://komisar.gin.by/
　　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 rev40
http://peace.2ch.net/test/read.cgi/avi/1392029046/

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

私女だけど生が一番気持ちいよ

でも今は胡瓜とか高いし・・・

雨ってゅうのゎ。。

９割以上が水分。。。

そしてきゅうりも、９割以上が水分。。。

そぅ。。これゎもぅ。。。

雨＝きゅうりってゅうコト。。。

空から降る一億のきゅうり。。。

もぅﾏﾁﾞ無理。。。

浅漬けにしょ。。。。

雨は100%では？
90%なのは空気中の水分・・
つまり・・

HDDを買い続けるってバカだろ
ほっとくと直ぐ壊れれるのに
保存ならDVD-Rがベスト
いやベターか

円盤は読み書き遅いし保存してても数年で飛びかねないからHDDより使い勝手悪い気がする

でもリスクは大分低減される

頭大丈夫か？

リスクは分散させるもの

RISCで分散処理とな？！

つRAID

RAIDのモード書かないと逆にリスクが増えるぞ

RAIDにも色々あるからな。
WD緑とかでRAIDなんてしてたら大事なデータがいきなり消えたりするかもしれないぜ。
せめてWD紫かWD赤ぐらいにしておけばなんとかなるだろうけどな。

とりあえずWD緑で温度含めたSMART監視を十秒毎にやってたりすると地獄を見るから注意な
って巡回先のHDD関連スレかと思ったらx264スレじゃないかｗ

そもそもバックアップとっか倉庫目的でRAIDを使うような奴はいないはずだ。
1台はそのうち壊れるだろうけど、並行して2･3台以上HDDが壊れたら再起不能になるしな。

HDDはエンコしたやつをとりあえず保存とかに使ってる
後は頻繁に見たいものを適当に
まあ最近のHDDは特に故障率大きいので保存には絶対使えないけどな

Xbox One MKV対応ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
まあ買わないけどね(´･ω･｀)

やっぱ立場が弱いほうが
アグレッシブに動いていいな。

箱oneってひっそり発売されてたんだな

立場が全く逆になったなー。
ゲームの箱○、メディアプレーヤのPS3だったのに。

どっちも日本が最後発って仕打ちで興味が失せたわ

http://qa.support.sony.jp/solution/S1304160049119/?p=&q=DLNA&rt=qasearch&srcpg=tv
ブラビアの2013年モデル以降は結構対応フォーマット増えたよ
PS3よりも多いんじゃね？

http://i.imgur.com/kK6yKax.jpg
左下PS3のアプコンに比べ右上の4K X-Reality PROはより自然
PS3のアプコンはホント気持ち悪い
まあ俺は左上のオリジナルが自然で好きなんだけどね

じゃぁ等倍で見てればいいじゃん
4kだとそんなの無理だから

だから俺たちはspline36で1280x720にリサイズして等倍で見てんだろ
SDはATiの品のいいアプコン使って見てるけど

どっちもどっちだな
右上は不自然に毛羽立ってる
左下は逆にのっぺり丸まってる

何言ってるかサッパリわかんねぇ

ここまでx264の話題なし。

ここからもx264の話題なし。

未来永劫にx264の話題なし。

x264の話題が無いって話題がでてる

今、日本人ビルダーって居る？

msvcプロジェクト用意してくれれば誰でも簡単にビルドできるのになぁ

gccの他に必要なものと言えばyasmくらいだから、x264のビルドは楽な方

Komisarビルドのclearとkmodの違いって何？
パッチが当てられてるって書いてあるけど具体的にどう違うのか書いてないので

>clear: clean GIT version without any patches
本家のソースコードをベースに一切のパッチを当てずにビルドしたもの

>kMod: many additional patches (may vary).
本家のソースコードをベースに追加で様々なパッチを当ててビルドしたもの

パッチというは本家に無い追加のオプションだったり、便利な機能を追加するもの、機能とは関係ないがログにエンコに費やした総時間を表示したりエンコ時に推定のファイルサイズを表示したりと様々
分からないのならclearでいいんじゃね？
てか定期的に出る質問だよね・・・

x264のビルドってlinuxあった方が便利ですか？

>>39
Windows用のバイナリをビルドするなら、不要

どれだけ重くても時間かかってもいいのでできるだけきれいにできる設定教えてください！！

>>41
--preset placebo

>>41
-q 0

>>43が勝つわ・・・

おぉ・・・

>>42と>>43とi444を選択

エンコしないという選択肢は？
時間掛からない、画質劣化ゼロ、劣化しないのにサイズもqp0でエンコした時よりは小さいままなことが多い

きれいさっぱり削除するというのもあるな

画質劣化というか、TOKYO MX ソースなんかだと Avisynth で適度にフィルタかましてやったほうが
ノイズ取れたりで逆に綺麗になるよ。
何もフィルタ通さないならエンコしない方がマシだけどねｗ

>>41
--crf 18.0 --rc-lookahead 60 --lookahead-threads 1 --aq-mode 1 --psy-rd 3.0:0.0 --min-keyint 4 --bframes 3 --b-adapt 2 --partitions all --me esa --subme 9 --merange 32 --direct auto --ref 4 --weightp 2 --trellis 2 --no-fast-pskip --no-dct-decimate

俺の基本的なおすすめ設定

他の細かいおぷしょんの設定値はソースやエンコ方法に合わせて適当に調整してちょ
これでサイズがでかすぎると思ったらpsyを下げて調整を

眼科逝け

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

もうそのネタ秋田

もうそのネタ山形

じゃあ尾張って事で

>>50
動き予測アルゴリズムはumhで十分

実際umhでもtesaでもdiaでも生成物のデータ量と画質に差異は殆どないからな。
重めのパラメータでエンコさせて良い画質になったわｗって思い込むのは各自の自由だけどな

まさにplacebo

psy3って・・・
nopsyとpsy3で全く区別つかないのにビットレートがアホみたいに差がでるけど
俺だけか？心理的っていわれても全く再生して比較してみても全く変わらんぞ

眼科逝け

--psy-rd 3.0:0.0
これはおかしいわな
ここ数年で俺の知らないなにかが起こってない限りは

>>61
変わるならキャプくれよ
心理的とかいうがそんなんはフィルタでもかければ良い話

自分で撮りなよ
暗めのシーンは分かりやすいよ

>>57
me umhならsubmeは11にしてちょ
まあこれはどっちでもいい

昔のtesaは重い割に意味が少なかったけど今はそれなりに意味があると思うぞ
アニメとかにはほとんど意味がないだろうけどCG系（ゲーム動画とか）には結構効く
支払うコストに見合うだけの意味かどうかはその人の価値観次第としかいえんが

あとrc-lookaheadも増やせば増やしただけ効いてくると思う

merange128おいしいです

俺はもう大分前から動き予測はHexaonalにしてる

屁臭オナる?

tesaにしたら動きのあるシーンで輪郭周りのノイズが発生しにくくなったよ

俺は動いてるシーンにはこだわらなくなった
よほど破綻が酷くない限り動画として見る分には違いがわからないから拘る意味を感じなくなった

逆に静止シーンには気をつかう
ちょっと油断するとすぐx264がビットレート削って細部が破綻する
動いてないシーンの細部破綻は動画として見ても凄く目立つからいやーんなのよね

そんなものme以外のパラメータ次第でいくらもで変わるだろ

ビットレ盛り盛りが正義

つまりはqp0と・・・

違いが分からないのにドヤ顔で語るなよ

ダバダ〜♪ダバダ〜♪ア〜♪

おお…

もう・・・

れつ・・・

あた・・・

ろう・・・

そうです、私が違いの分かる男です

異能バトルの生徒会長がかわいすぎて辛い…なのに話がつまらなくてもっと辛い… [279046568]
http://fox.2ch.net/test/read.cgi/poverty/1413375557/

鳩子ちゃんは僕のだぞ！

x264をインストールし、AG-デスクトップレコーダーで動画キャプをしました。
圧縮効率がよくないです。
632×360ドット、29.97FPS(音声はPCM44.1KHz)、約2分間で、約35〜36MBの、拡張子mp4の動画ファイルができました。
ファイルサイズがデカ過ぎますよね。
Youtubeの動画をダウンロードしてみると、640×360ドット、約25分間の動画でサイズは135MBぐらいです。(と、すると2分間なら11MBくらい?)
[設定(w)]でx264の設定をいろいろいじれますが、よくわからず、デフォルト通りです。
なるべく画質を落さず、音ズレもさせず、Youtubeぐらいのファイルサイズにしたいです。
どうすればよいですか。

それx264関係ないし
サイズが大きいのは音声が非圧縮だからだろ

x264が何かも理解してないくせに
x264に変な言いがかりつけるなよ

ここで聞いても解説そのものが理解できないだろうからまずは初心者スレに行ったほうがいいだろうな
そもそも動画キャプチャでそのままうpされてるものと同等のものを得ようと思わない方がいい気はする
一度可逆圧縮とかで取り込んだ後にじっくりエンコするのがいいかと

>>85
君が使ってるのはx264じゃなくてx264vfwだし、そのx264vfwも2種類あるから、
初心者スレに行くときにはどこから落としたものを使ってるのかも明記したほうがいいよ。

merange過多による誤爆って具体的にどのような事が起こるの？

昔はベクトルの逆方向に変なノイズがポツポツ残ることがあったと思う
rev1000-1500ぐらいの間で改善されたみたいで今はmerange 128とか設定してもまず見ない

>>90
ありがとう
64に設定してるから今更不安になった

popさん、もう更新しないのかな

俺もずっと待ってるんだけど
このままフェードアウトして消えちゃうパターンなんだろうか・・・

いつもアニメ実況してる

なにその評論家ニート状態

FC2＠暇に貼りついているんですねｗ

もう更新は無いのかね

merange盛るより24程度に抑えてref盛った方がいい結果が得られやすいような気がする
解像度にも寄るんだろうけど

PCだとrefもいいが
それ以外の端末で再生することを考えると…

えっ、それ以外の端末？違法うｐでもやってんの？

頭大丈夫か？

引きこもりニートか？

>>100
スマホとかVitaって意味じゃないの？

普通はそう考えるわな…

こりゃ >>100 は違法DLしてるタイプだな。

>>103
それこそ理解の外だな。
スマホやゲーム機みたいなちっこい画面でエンコした動画見て何が楽しいんだ？

>>106
>>101

>>106
>>102

>>106
>>102

エンコしないで見れないからだろ・・・・

>>107-109
自演乙

このスレは更新ペースも緩やかだし元々住民居ない。

>>106
Apple TV、ChromecastやHDMIで直接等
スマホやタブレット等はTVと繋げられるんやで

やで（）笑

ID:z6vTM4Br

想像力が無い・他人の価値観を理解できない・自演と決めつけないと心の平穏を保てない

可哀想に。

>>111
元々住民がいないって言ってるけど専門的なスレに常時何人もいるわけ無いじゃん
何言い訳してるんだよ さっさと謝っとけば荒れなくて済んだのに

最近目ぼしい更新も無く話題が無いだけでROMは大勢いるだろう

今はh265の普及と熟成待ち

まだまだx264の方が上だよね
様子見は来年まで余裕で続く

自身の再生環境さえ問題なければ既に現時点でx265のがいいと思う。

エンコ速度、細部までの画質比べてるけど俺にはまだx264だわ
これを環境の問題と言うのならそれはそれで構わないが

265はまだオプションがまともに機能していない

一番のネック変換速度だな
ほどほどのオプションで50FPSは出るようになってほしい

ここ最近の更新スピードがハンパ無いな
もう1.4になったのか、、、

その数字に何か意味あるの？

カスタムaqとか無いから8bitだと辛いが
10bit以上でエンコしてるならもうh265でいいと思う

暗部にぼろかった印象だけど今はもう大丈夫なんか

だがHEVCはデコーダがなぁ・・・
一番新しいLAVでごり押しさせてHEVC_VLD_Mainを有効にさせても
DXVA2に対応しない古いグラボやXPみたいな古いOSだと支援とかあまり意味ないし
そんなゴミグラボやゴミOSは窓から捨てちまえばいいんだけどｗ

生きた化石ですか？はやくゴミに出してください

物を大事にできない人ですか？それとも貯金できない人ですか？

何か変なのが住み着いたなぁ

CPUも同世代だとしたらエンコにかかる時間と電気代的に買い換えた方がエコな気もしなくはない

よしパパE7の4wayにしちゃうぞーって事ですね1回はやってみたいです

720p/1080pならi3でも余裕だったはず

何の話？

デコードじゃね？
x265はエンコが時間掛かりすぎるから使えない

太平洋側も寒くなりましたね
まさに圧縮日和

デコードなんてスマホでも余裕なのに

それ以下のPCなんだろう
触れたくないわ

OSとGPUだけ買い換えればよくね

スマホやタブレットは指紋だらけになるので却下

脂症でぶ ?

脂性でもデブじゃなくても触りまくっていたら指紋だらけになるだろ
タッチペンと眼鏡拭きでも用意すれば済むけど

普通に拭けばよくね？
指紋は取れやすいし、気にしたことは無いな

なんか変な液が出るんじゃね

溶けちゃうのか？！

溶解人間

>>141
デヴ乙

どう考えても開発者じゃない件

ここ、なんの為のスレだか訳がわからんな。
x264に関する話題殆ど集まらなくなってんじゃねーか。
いくら更新ペースが緩くなってきてるからと言ってこれでいいんか？

>>150
じゃあ君が何か有意義な話を振ってくれ

有意義な話？たとえば何系？

ARM NEON命令を使えばx264エンコ時にどんぐらい速度を稼げるかとかって話とか？
殆どアセンブリコードの話題だからwindowsでしかもx86-64でしか使わない俺らには無意義な話か。
たしか夏頃の更新でｘ264も対応してたからなNEON命令。x86と比較して10%は速くできるらしいけど

昔っからだよ

何でID:Iqe0Pjujは喧嘩腰なの？
話題がないから雑談状態になるのは昔っからじゃん
話題がでたらみんなそれに返すと思うけど？

いったいどの辺が喧嘩腰かわからん。
お前住んでるの方言で語ればいいのか？
少なくともきったない指紋の話よりマシだろう。

最初は別に喧嘩腰とまでは思わなかったけど、
何か話がしたいならもう少し考えて振らないと荒れるだけだから迷惑極まりないぞ。

>>155
なんでそんなに喧嘩腰なの？

この流れはしばらく「喧嘩腰」をテーマに荒らすのか？
前回は「指紋」がテーマだったよな。せっかく話題を振ってもこれじゃ何の意味もないわ。
茶番トークはvipでやればいいのに

変なのが住み着いたな

>>154-159

　　ｶﾞﾀ ＿＿＿＿_ 　　　　
　　　／　／／ ／| 　　　　
（（　 |￣.|￣|￣|　.|　））　ｺﾞﾀ
　 　 |　. |　 |　 |／　　 　　
　 　　ヽ('A` )ﾉ ＜ おまえらまとめて携帯動画変換君にぶち込んでやる。
　 　　へ(　) 　　　　少し頭冷やして黙ってろ。
　　　 　　く

>>160
動作を停止しました
問題が発生したため終了します

おお…

本当に変なのが住み着いた

> 131 名前：名無しさん＠編集中[sage] 投稿日：2014/11/03(月) 03:13:03.09 ID:FkpwdpBq
> 何か変なのが住み着いたなぁ
>
> 159 名前：名無しさん＠編集中[sage] 投稿日：2014/11/05(水) 19:07:52.53 ID:7ubmpuze
> 変なのが住み着いたな
>
> 163 名前：名無しさん＠編集中[sage] 投稿日：2014/11/05(水) 22:39:39.66 ID:cRSZhbLl
> 本当に変なのが住み着いた

>>164
自演扱いしたいのかもしれないが
163意外は俺じゃないぞ

変なのが住み着いたな

>>158
本当になんでそんな喧嘩腰なんだ？

単発イチャモン野郎と、コピペ荒らしに反応さえしなければいいだけ
そいつら全員空気扱いにしてスルーすると面白いかもしれない
先日エンコしたばかりのスクールってドラマがそんな感じで面白かったしな

変なのが住み着いたぞい

変なのが住み着いたと聞いてやって来ました

そうです、私が

やりました

やってやるぜ

X264は西村(ひろゆき)のアナグラムである

エニックス64

>>175
なんでそんなに喧嘩腰なの？

よほど必要がないかぎり
slowerでやったらいかんね・・・
エンコ遅い遅い('A`)

x265使ったあとだとx264のveryslowでも十分許容範囲だと感じてしまう
10fpsも速度あれば行ける行ける

最近気づいた事。アニメソースを diaでエンコしても、tesaでエンコしても
プレイヤー再生時の画質は大して変わらなかった。
エンコ後のSSIM/PSNR値はtesaの方が若干高いけど誤差の範囲だ。

2passでデータ量を40Mに抑えてエンコさせたのでデータ量は均一だったし

いつも slower でやってたけど
--preset は何がオススメなの？

mediumベースにコスパの高いオプションだけ盛っていけばいいんじゃない

--crfXX --preset medium --tune ssim --ssim --aq-mode Y --aq-strength Z

X = 20〜24
Y = 1 or 2
Z = 0.6〜1.0

これでSSIMとファイルサイズ見ながら自分好みに調整したわ。
presetはmediumかslowで充分だろうね。

ああ、x265のスレと間違えたわｗ すまｎ

ちょっと質問！
以前はなんとなく設定して・・・もしかすると設定せずに
フルハイのMPEG-TSファイルのエンコをしてたときは
せいぜい実時間の3倍ぐらいかなあ、たぶんそんな辺りでエンコできてたのに
この数日初めてちょっといじってみたら
なんと終了予想が実時間の10倍に・・・いくらなんでも遅すぎる＞＜
例えば編集後30分のものに300分＝5時間もエンコしてなかったです
どこか「やっちまった」気がしないでもないんで
初心者が陥りやすい設定ミスってなにかありますかね？
速度はmediumで品質は23とか25の普通ぐらいなんですけどねえ・・・
それとも以前は品質を逆に21とかにしてfastだったのかなあと
設定を記憶してなくて・・・画質はまあまあ良ければいいんです

>>184
なにを聞きたいのか分からないけど
mpc-hcとかmediainfoでオプションを確認したらいいと思うよ

TSのまま再生してりゃ万事OKよ

品質21のfastでやっても全然遅い・・・おかしいなあ('A`)
品質までも落とすのか？

>>184
エンコパラメータを少々軽めにしたところで品質はそんなに変わらないから。
変わるのは圧縮率と、ほんの少しのSSIM/PSNR値と、エンコ速度の改善。

もしかして・・・「GUIにロード」を押さなきゃならなかったのか・・・＿|￣|○
今押してからエンコ再挑戦したら早くなった・・・
参考にしたサイトにこのボタンのこと書かれてなかった記憶が・・・
寝れる｡･ﾟ･(ﾉД`)･ﾟ･｡

GUIとか
さすがテンプレ読まないだけのことはある

http://peace.2ch.net/test/read.cgi/avi/1347527423/770
同一人物にしかみえない。

x264 r2491北

masterだけ更新か

>>192
どこ？
DarkShikari氏のx264-develはまだだった

>>1 はみたか?
Komisar x264 builds ここにあったぞ

tMod待ちです

>>195
了解

ttp://pc.watch.impress.co.jp/docs/news/20141118_676334.html

比較的快適なインターネット環境が手に入ったのだが、どうやって活用するかが目下の問題である

最近過疎ってるけど今更ながら質問させてください
実写の女性の顎と首の影の部分がチラチラと汚くなっちゃう
アップは大丈夫なんですが引きの画のときに目立っちゃう
オプションはプリセットMediumしかつけてません
同じような経験をしてきて対策された方がいたらアドバイスください
ちなみにですがx265を試したらスッキリ仕上がりましたがまだまだx264に頑張って欲しい

＞ちなみにですがx265を試したらスッキリ仕上がりましたが

それボケてるだけだろｗ

ボケてても綺麗ならイイんですｗ

うわぁ

つまり「被写体の女優がちょっとアレなのでボカしたほうが綺麗（マシ）」と・・・

っ モザイク

現revのt-mod欲しい…

>>200
10bitでエンコ

>>207
そしてスマホで再生

そして眼科に通う。

>>206
今やってるっぽい

tMod版を愛用してる人は具体的にどういう目的でどの機能を重視して使ってるんだろ。

AQ3

AQ3ってそんなにいい？

なんてったってロトシリーズ3部作の完結編だからな

ttps://twitter.com/K4095/status/541159703087026176

10bitとaq3の相性は抜群

>>210
マジかよ最近lavフィルタの更新しかなかったからもう完全に冷めちゃったのかと思ってたわマジ嬉しい

どういうソースの時に使うものなん？

ディザ残したいアニメとかaq1より綺麗に保持する気がする
効き目が強すぎるのと、膨らみやすくもなるから数値探らなあかんけど

ということは実写にも使える感じ？

実写は8bitでやっちゃうから分からないけど使えるんじゃないか
ただ強めの数値にするとめっさ膨らむ

10bit使うくらいならx265で使った方がよくね？

使ってみた？
あれでいいならそうしたら？ｗ

あたまわるそう

>>219
だよな　パッと見は変わらないけどサイズは増える
よく見ると細かいところで差がでてるっていう高画質向け？

>>222
それはないな
今のx265はディテールが死にまくりだからな
同一ビットレートで・・・・ならまだしも少なくとも俺は10bitを使おうと思うのはサイズよりも画質優先だからx264 10bit使うな
x265の10bitもまだ安定しないし遅いしハゲるし

HEVC今のままだと本当つまらん規格だわ

黎明期を楽しめ

高解像度にするより色深度をちゃんとして欲しいわ
フルHDで色をちゃんとしてビットレートをちゃんと盛れよ

>>228
x265の話？よくわからないのだけど、色深度がちゃんとしてないとか
ビットレートをちゃんと盛れってのは、具体的にどういうことを指してるのか気になる。

最初の一行は規格に対する文句だと思う。

x264でも盛りたいとこに盛れるようになったの大夫経って
からだよなあ、最初は綺麗にしたいとこ基準にしちゃうと
いらないとこにも盛り盛りだった

>>225
一昔前じゃないか？それ
今は10bit x264なんてあまり勧められない感じになってきてる

大きなお世話ですはい。

別に他人に配布するためにエンコするわけじゃないんだから好きなの使えばいいべ
やたらこだわるのは割れ業界の人たちの可能性高し

割れだとx264+10bit主流だよな

BD規格で焼けないじゃないか

焼く必要がない

>>232
これどういうこと？最近変わったの？x265の話か？

ただの世論操作の一環

何度もいうが自分に都合のあった好きなものを使えばいい

不特定多数に配布するのが目的なら話は別だがこうなるともうほぼ違法割れだろう

x265スレで暴れてた8ビット君か

>>238
最近10bitの圧縮率が大分改善されたらしい
265の話ね。26410bitだと互換性ないし、
265なら10bitでも互換性高いしって圧縮率も良いしって意味だと思う
まあx265スレで暴れてた8ビット糞糞行ってたキチガイだと思うよ

頭大丈夫か？

x264とx265のユーザーに派閥争いがあるのか
それとも単に「俺のほうが詳しいぞ」の知識ひけらかしたいだけか
カス同士仲良くしたらいいよ

自分のやり方が正しいと思い込みたいんだろう
逆にそれは自信の無さの表れなんだけど

派閥争いってｗ

互換性なんて気にするのは割れ厨だけだろ
その中でもとくに性質の悪いモンスター乞食

>>242は別におかしなことは言ってなくね？
「互換性」ってのは言葉が変だとは思うが、例えばH.264の10bitはGPU再生支援が普及しなかったけど
H.265のほうは今後10bitもGPU再生支援が効くようになっていくんじゃねとかそういう話だと捉えたけど。

>>248
モバイル端末で再生するなら8bitと使い分けてる人いそうなんだけど、未だにPCだけでしか再生しないって考えの人がいるからね

モバイル端末でわざわざHD動画見るのか？
俺にはよくわからん世界だな

>>249
ああ、俺もその基本的なとこが抜けてらぁ・・・(ノ∀`)

>>238
x265が現在開発中の為まだまだ未実装の部分が多く
H.265の性能をまだ引き出せていない事すら知らないニワカの戯言
doom眺めてるだけでも分かる話なんだが見てないんだろ

俺はまだ本気を出していない
俺は悪くない
俺の本当の力を知らない社会が悪い
俺はまだ本気を出していないだけだ


本気出したら話題にしてくれｗ
スレチも甚だしい

PCのみならx265-10bit
家電/モバイルならx264-8bit
もうこれで良いでしょ
自分で判断できる奴は好きなの使うって事で

頭大丈夫か？

253 名前：名無しさん＠そうだ選挙に行こう[sage] 投稿日：2014/12/14(日) 19:08:01.34 ID:ESlh99fv (1/2)
俺はまだ本気を出していない
俺は悪くない
俺の本当の力を知らない社会が悪い
俺はまだ本気を出していないだけだ


本気出したら話題にしてくれｗ
スレチも甚だしい

255 名前：名無しさん＠そうだ選挙に行こう[sage] 投稿日：2014/12/14(日) 19:41:47.82 ID:ESlh99fv (2/2)
頭大丈夫か？

おまいう

頭大丈夫か？

>>256
x264との比較という意味でx265の話を出すのが必ずしもスレチとは思わないが
スレチ気味な話になりがちだとは思うし、「自分で判断できない人」に対して
　　>PCのみならx265-10bit
なんて書いちゃうのは正直「頭大丈夫か？」と言われても仕方ない気がする。

だが具体的な内容も書かずに「頭大丈夫か？」とだけ返し続けるのも「頭大丈夫か？」と思う。

>>256
んじゃあx264-8bitでいいよ
これなら判断できない奴が後で困ることもないかな

>>252
x265ってビルドもすぐ終わるよね

しかしここはx264のスレだ

>>258
趣味なんだからそれぞれ環境も違えば楽しみ方も違うのは当然

それを一方的な押し付けするから「頭大丈夫か？」となるのは当たり前だろう

x265-10bitが画質面でx264-10bitに劣ると指摘された事に気付けよ

圧縮技術は如何にごまかして縮めるかであって
綺麗にみせる技術じゃねぇからな
情報削られ誤魔化されて喜んでんじゃねぇよ

H264の10bitは結局普及しなかったからな・・
HEVC時代は放送ソースの時点で10/12bitになると言うし、
今から10bitでやるならx264よりx265じゃないか？
現時点では画質が劣るとしても。

自分以外の人がお前の真似しないと困る理由でもあるのか？

>>265
ノーサンキューだわ
っつかアホだろ

x264-8bitでいいだろ
いつまでつづけんの？

頭大丈夫か？

だからさ他のやつも言ってるけど通常はx264 8bitを使えばいい
メリット・デメリットが分かる奴は10bitを使ってもいい
わからない人はつべこべ言わずにx264 8bitを使ってれば後々被害が少ない
それだけのことだろ

俺はモバイル用途でもx264 10bit使ってるけどな
多重音声でも特に問題ないし

>>271
iOS系では再生出来ないだろ

iOSなんてゴミ。

何言ってんだこいつｗ
Androidの方がゴミだろｗ
Javaで作られたゴミｗｗ

>>272
iOSのnPlayerなら i420 i422 i444 10bit再生できるよ
コンテナもmkv(H.264+FLAC) mp4(H.264+ALAC)対応してる

>>275
そんなもんがあるのか
でも俺は8bitでいいかな
他にもテレビのプレーヤーとかで汎用性高いし

泥のタブやらスマホやらで再生するなら8bitかな
10bitは再生できないわけじゃないけどソフトウェアデコードでバッテリーの消費がやばいから

>>274
タブレットやスマホで動画再生で喜んでるのはせいぜい最近の小中学生ぐらいだろｗ
スマホやタブレットなんて音声出力能力もしょっぱいしな。ゴミ過ぎるわ。

PC→スマホ経由でAppleTVに飛ばしてる
適当に見るならエンコしなくていいから楽

>>276
10bit再生できても制限多くて実用的じゃあないよ
モバイルや家電で観るなら8bit一択かと思う
家電が265に移行する頃には10-12bitが主流になってるだろうけどね
モバイルは265でも8bitっぽい

モバイルや家電で観ないからｗ

ホテルでテレビにスマホ繋いで見るよ(・∀・)

最近のTVだとPS3とか繋げなくても単独でPC内のファイル再生出来たりするし

>>280
頭大丈夫か？

>>284
お前いつもいるなｗ

>>280
お前の頭ん中ではなｗ

訂正
>>280→>>281

そりゃそうだろ
俺もPCでしか見ないし

H.264はモバイル端末での再生からPC等の大型再生機器での再生まで幅広く利用されてるのにPCでしか見ないって意見を押し通しすのはどうかと
俺もほとんどPCでしか見ないけど、たまにモバイル向けでエンコすることあるよ
今のスマホなんかはhighプロファイル余裕だから8bitならばさほど気にしなくてもハードウェアデコードで再生できる
10bitも再生できるけど手元の端末では全てソフトウェアデコードだから本体がカイロになるしバッテリーの消費が大きい

>>280はモバイルや家電なら8bit一択って断言しちゃってるけど、実際にモバイル向けにエンコすると分かるよ
10bitは何かと制限が大きいから8bitが現実的かなと思う
俺は10bitで見たいんだって人は自由にすればいい

>>280の265の話は調べてないし、まだまだ移行すら本格的に始まってるように見えないから発言は控える

なんとなく書いてたら長文・駄文になってたな　失礼

10bitでエンコする奴全員死ねや

放送が10bitになっても8bitでエンコしてろ

またヘンなのが涌いてるな。
8bitや10bitに拘ってる時点でどうかしてしまってる。
「自分のやりたいことに合わせてエンコードする」
「自分が納得できる設定でやる」
これでいいだろ。
エンコードは手段であって、目的じゃない。

本当に8ビット君はキチガイだな
PCでしか見ないって言ってんだから見ないんだろ
それをいつまでもあーだこーだ
気持ち悪いわマジで

10bit君ホントマジキチ

他人のエンコのことでそこまでキチガイになれるお前らは全員凄いと思うよ。

的外れ

>>293
また素人がなにほざいてるんだよ、エンコする事そのものが
目的だろが、ここはそういう廃人以外お断りですから！

8/10bitを柔軟に切り替える俺、高みの見物

DP対応のグラボ・DP対応の液晶を使っているのに10bitでエンコしないなんてほんとどうかしてる。
8bitでしかダメな奴ってゲーム機やFlashplayerで動画を再生させたい層ぐらいじゃね？
自撮りした映像をエンコしてvimeoとかにうｐするとか。

8bitで良い10bitで良い議論は意味ないから終わった方が良いよ

子供の頃優秀だったけど今は底辺ですみたいな人は承認欲求がとても強いらしい
お前のやり方がベストだ！っていってもらわないと我慢できないんよ

>>300
>DP対応のグラボ・DP対応の液晶を使っているのに10bitでエンコしないなんてほんとどうかしてる。

10bit出力（入力）対応ってことを言いたいんだろうけど、その場合レンダラってどう働くの？
madVRを使ってもデコードで得た10bitYUVを8bitRGBの1677万色に描画するだけであって、
グラボはそれを10bitにして出力してるだけなんじゃないの？
そのへんがいまいちよくわからん。

なんか変な書き方になった気もするけど、いいグラボやモニタを使うに越したことは無いというのはいいとして、
10bit出力環境でのレンダラの働きがよくわからず気になってるってだけね。
なんかググると10bit出力環境を生かすには対応グラボとモニタだけじゃなく
Photoshopみたいな10bit対応ソフトが必要とか書いてある記事ばかりだし、
動画再生の場合どうなるのかなと思って。

馬鹿が数名湧いてるな

>>303,304
10bit出力は対応ソフトを全画面にして使う
DirectXやOpenGLの排他モードと一緒だよ
mpc-hcなら出力のオプションにDirect3D フルスクリーンのチェックがある
mpc-hcはこのモードで全画面にしてるとguiが表示されないからマウス操作できないんだけどね

>>306
>DirectXやOpenGLの排他モードと一緒だよ

ごめん、そこの基本がよくわかってないや。
MPC-HCでDirect3Dのフルスクリーンにしたとして、デコードされたデータは
どのようにレンダリングされて、どのように出力されるんだろう？
10bitYUV4:2:0から直接10bitRGBにレンダリングされて出力されるということ？？？

>>300
10bitのソースは持ってるの？

TSも残しておくのが通

色々と調べてたら「Media Player .NET」ってのを見つけた。
独自の組み込みレンダラを持つプレーヤーらしい。

　　Media Player .NET - MPDN - Direct3D HQ GPU video renderer [v2.14.1 - 17 Dec 2014] - Doom9's Forum
　　ttp://forum.doom9.org/showthread.php?t=171120

これなら10bit出力対応環境で10bit(RGB？)での映像出力ができるように読める。

madVRやEVR、EVR-CPなどでは10biit出力は無理な気がするのだけど、どうなんだろう。
誰か詳しい人いたら、処理の流れも含めて解説してほしい・・・。

>>307
フルスクリーンと言っても単に画面全体の大きさのウィンドウで表示するものではなく
解像度とか色深度のモードを変更して動作するもののほうね
この排他モードだと画面出力を独占的に使えるから30bitにもできる

どうせキャリブレーションしてないディスプレイで見るんだろ

>>311
MPC-HCの「表示→オプション」から「再生→出力」でEVR(カスタム プレゼンタ)を選んで
下の方にある「Direct3D フルスクリーン」のことであってる？
Direct3D自体の仕組みとしては10bit深度（30bit）にできるみたいだけど、
MPC-HCのこのチェックは
　　「ティアリングを減らしますがツールバーを表示できません」
とあるだけで、10bit対応環境でチェックを入れたとしても
EVR-CPが10bit深度でレンダリングしてくれるわけではないような気が。
そもそもEVR-CPは10bit入力も受け付けないし。

そうではなく、>>310みたいなソフトでは排他モードを使って10bit深度出力してるということなのかな？

>>289
放送が265は10bit予定なのよ

日本語で

いや分かれよｗ

ソースが8bitで10bit使うなんて愚の骨頂

お前がそう思うんならそうなんだろう お前ん中ではな

ワザとぼけてるとしか思えなくなってきた昨今。

と言うか先天的に流れを読めない上に直近のレスしか頭に残らない体質なんじゃないかと
しかも拘りが強い、一言で言えばアスペ。

>>317
それが通用するのはロスレスエンコだけ

>>321
何故ロスレスにしないのかを考えればそうでもない

出たよ8ビット君

気が触れてるみたいだよなんか…

>>313
ctrl+Jでレンダラの統計情報を表示すると、FormatsのBackbufferやDisplayの
フォーマットがA2R10G10B10に変わるので10bitになってるはず
入力として10bitフォーマットを受け付けているのかどうか検証してはいないけど、
レンダラの10bitをプレゼンテーションに「強制的に 10bit RGB入力」にするオプションもあるので、
10bitを受け付けるのは画面のモードが10bit RGBの時だけなんだと思う
途中でフォーマット変更させるために、オプションで「表示変更時に再初期化」を
設定する必要もあるかもしれない

流れを読む以前に、不毛なツッコミしか書き込まない連中は何がやりたいんだ？

パイパンツッコミ

10bit君は恥ずかしいからもう書き込まなくていいよ

8bit君も10bit君も恥ずかしいよ
その時々で最適と判断したものを使えばそれでいいのにいつまで争ってるの？

なぜ蒸し返すのか

>>325
とても参考になりました。ありがとう。
「表示→オプション」のとこばかり見てて、「表示→レンダラの設定→プレゼンテーション」は
全然見てなかったアホな俺・・・。
　　ttps://trac.mpc-hc.org/wiki/New_Renderer_Settings
普通の8bit出力環境だけど、試してみると
　　・「10ビットRGB出力」にチェック
　　　　　→SurfaceだけがX8R8G8B8からA2R10B10G10に変わる
　　・更に「Direct3Dフルスクリーンモード」にチェック
　　　　　→フルスクリーン時のみBackBuffer、DisplayもA2R10B10G10に変わる
　　・更に「強制的に10ビットRGB入力」にチェック
　　　　　→Mixer outputがYUY2からRGB32(X8R8G8B8)に変わる（10bitRGBにはならない）
ということになるんだね。つまり、EVR-CPでは、
　　・「デコーダ→EVR-CP」の受け渡しは8bitYUV/RGBでしかできない。
　　・EVR-CP内部の「ミキサー→プレゼンタ」の受け渡しも
　　　10bitRGBにはできず、8bitRGBかYUY2になる。
　　・ミキサーから受け取った8bitRGBやYUY2を10bitRGBとして描画することはできる。
ということになるのかな？

そうなると、トータルで10bitYUV→10bitRGBの直接変換はできないから、
10bitエンコした動画を10bit出力対応環境でEVR-CPを使って見る場合も、
デコーダで10bitYUV→8bitRGB変換をしてEVR-CPに渡すのが一番良いということになるのかな。
（一応書いておくと10bitエンコの恩恵を受けるのに10bit出力環境は別に必要ないというのは理解済み）

8ビットの次は16ビットだろがあああああ

時代が求めた16-BIT

64bit級

rev2525
aq3追加

ここ最近では一番大きな変更だよな
新しいオプションの追加という意味で

バグで適切な割り当てが上手くいってなかったとかありそうだからしばらく待つわ

あだ名に君が付いている時点でハズイわｗ

D_S氏のgithubのレポが404何だけど,,,

Takuan@K4095
DS氏が#x264devからいなくなったからsandboxの方が出来た
多分しばらく（というかずっと？）は開発から離れる
https://twitter.com/K4095/status/546455616663744512

新revで追加された「auto-variance AQ with bias to dark scenes」って
かなり昔に話題になったやつ？

>>1
> [本家]
> http://www.videolan.org/x264.html

だいぶ前からソースコード落とせなくなってる？
404 NotFoundって返される

ttp://www.videolan.org/developers/x264.html

トップページくらい見れれ

>>343
そこの"Download x264"クリックしたけど

　正常に接続できませんでした

　ftp.videolan.org のサーバへの接続を確立できませんでした。

このサイトが一時的に利用できなくなっていたり、サーバの負荷が高すぎて接続できなくなっている可能性があります。しばらくしてから再度試してください。
他のサイトも表示できない場合、コンピュータのネットワーク接続を確認してください。
ファイアーウォールやプロキシでネットワークが保護されている場合、Firefox による Web アクセスが許可されているか確認してください。

って言われるわ。
うむむ(´ω｀)・・・

俺も繋がらなかったけど
リンクが死んでたのか

gitからcloneは出来たよ
それに
ttp://git.videolan.org/?p=x264.git;a=summary
ここからsnapshotもとれる

>>344
すまん。見てなかったのは私だった・・・。

ping で見ると、サーバーとしては生きているっぽいね。

ページのアドレス変わったの気付かなかったんだけど、
ｆｔｐサーバの下を移行中なんではなかろうか。

ちなみに、git clone git://git.videolan.org/x264.git
では落とせるよ

あ、ftpサーバも復活してるね

aq1とかmixaqと比べてどうなのよ
英語は読めない

英語が読めないならパラメータを少し変えて軽めのエンコをして自分で比較してみるといいんじゃね。
結局パラメータの良しあしなんて自分で確認するまで殆どアテにならないからな。

>>350
>パラメータを少し変えて

英語が解らない、用語の意味が解らないのであれば
値を極端に振って、違いを観るのが適当なやりかたなんじゃないのかい ?

>>351
それ同じことじゃないか。質問の意図がわからんわ

>>352

質問 ?
質問なんかしとらんぞ
"お前、馬鹿じゃねぇのか ?" ってのは質問ではないだろ。

"パラメータ少し変えて" …
例えば、ビットレートを1bit/s変えて変化がわかるか ?

つまらない揚げ足とって何が楽しいんだろうな。お前馬鹿じゃねぇのか？

変なのが来た

世の中には先天的に文脈読めないとか型通りにしか読めないのが一定数存在するからな…。

>>353
質問じゃないなら文末に「？」をつけるなよ

動作をイメージして
それぞれ適切な処理すりゃいいだけだ

参考になるか分からんけど、aq1〜3,subme 9〜10で試してみた。
submeを変えてみたのは、10がaq必須なので、影響有るのかなーと。
ソースは、音楽ライブ番組の1920x1080i。基本的に暗め。

ref=4 analyse=0x3:0x133 me=umh psy=1 me_range=24 trellis=2 8x8dct=1
cqm=0 interlaced=tff bluray_compat=1 bframes=3 b_pyramid=1 b_adapt=2
direct=3 weightb=1 open_gop=0 weightp=0 keyint=60 keyint_min=1 mbtree=1
主にいじった部分。Blu-ray,AVCHD用。

subme 9,aq1
fps kb/s elapsed
7.87 12432.52 0:03:48
SSIM Mean Y:0.9763899 (16.269db)
PSNR Mean Y:39.858 U:44.846 V:44.868 Avg:40.946 Global:39.255 kb/s:12432.41

subme 9,aq2
fps kb/s elapsed
7.96 12376.78 0:03:46
SSIM Mean Y:0.9773662 (16.452db)
PSNR Mean Y:40.134 U:44.944 V:44.985 Avg:41.194 Global:39.256 kb/s:12376.67

subme 9,aq3
fps kb/s elapsed
7.68 13017.89 0:03:54
SSIM Mean Y:0.9776999 (16.517db)
PSNR Mean Y:40.006 U:44.974 V:45.004 Avg:41.088 Global:39.129 kb/s:13017.78

subme 10,aq1
fps kb/s elapsed
6.16 11911.56 0:04:52
SSIM Mean Y:0.9758017 (16.162db)
PSNR Mean Y:39.681 U:44.678 V:44.716 Avg:40.772 Global:39.168 kb/s:11911.44

subme 10,aq2
fps kb/s elapsed
6.29 11859.59 0:04:46
SSIM Mean Y:0.9767303 (16.332db)
PSNR Mean Y:39.938 U:44.759 V:44.815 Avg:41.002 Global:39.178 kb/s:11859.47

subme 10,aq3
fps kb/s elapsed
5.78 12525.09 0:05:11
SSIM Mean Y:0.9772816 (16.436db)
PSNR Mean Y:39.854 U:44.827 V:44.870 Avg:40.939 Global:39.069 kb/s:12524.98

bluray_compat有効時の制約がうろ覚えで
パラメータに加えてもx264に虫されるかもしれないが
ref値はBフレ値の倍数とかにした方がいいと思われ。

bframeの倍数にしないといけないのは、keyintだった気がする。
で、keyintは、bitrate 15M(≒AVCHD)までなら2秒分まで許されるので、60に。
http://forum.doom9.org/showthread.php?t=154533

>>360
ビットレートはいかほど？

>364

vbv-muxrate,buffer=15000で、crf22です。
ライブなんで、暗いしサイリウムでチカチカするし、画質とファイルサイズのバランスが。。

>>365
今更だけど6Mbpsか8Mbpsの2Passでやってみたら？
劣化は意外と気にならないことが多いと思う

>>357
>356
>>356
それ、ここにいるサイコパスプログラマーのことだろw

明日から休みや やっとaq3が試せる…

映像しかエンコードしないエンコーダがコンテナ入りで出力するって馬鹿っぽい。

コンテナの意味がわかってないな
圧縮動画でRAWなんてないぞ

>>369
あんたおそらく精神的に幼いって周りに思われてるぞ
それか視野が狭すぎるか

つ　*.264

.264もコンテナだよ
もっとわかりやすいのは.wavだってコンテナ

H.264もMPEG2もコンテナじゃないよ？

ナンテナ

>>373
ストリーム直書きが*.264で実質（mp4等の汎用的なコンテナじゃない）rawと言っても差し付かえないでしょ。

規格の話に差し支えないもなにもないよ
コンテナはコンテナ
生データは生データ

これだけ反応があれば書いた本人も満足だろう

面倒臭ぇやつらが多いな
要するに x264 が吐き出すものを一旦何がしかの分離をせずに
AAC などの音声と mux できれば良いんだよ。

x264 の馬鹿は MP4 という拡張子で吐き出してるだろ。

面倒臭いID:nKP2+urBには伝家の宝刀たる「頭大丈夫か？」という言葉を贈りたい。

ちょっと乱暴に言うと、TSに映像・音声ストリームとして入ってるものは「コンテナ」じゃない。
どこでぶった切ってもデコード可能だから。

だからなんで.mp4に拘るんだ
.264で出力すれば直にmuxできるじゃねえか

知らないだけなんじゃ

というか普通に分離なんかせずにMUXできるだろ

mp4で吐いてもlsmashのmuxerならそのまま格納できるようになったってのは言ってもいいこと？

つまり rigaya が馬鹿って事 ?

>>386
ここはCLIのスレで、GUIは他にある

>>ID:nKP2+urB
x264をビルドする時にGPACかL-SMASHを選択する方式だという事が分かっていれば
コンテナの知識が無くても、オマエが馬鹿だという事だけは分かるぞ

x264が吐いたものを音声とmuxしてたけど
なんか分離する事あったっけ？

>>389
「(mp4なりmkvなりのコンテナ名) 分離」とか「(mp4なりmkvなりのコンテナ名) 抽出」でググれ

GPACもL-SMASHもビルドしていないバイナリ―で出力する*.264ってどうなんだ

正直スレ違いだと思うがどこで聞いていいかわからんので書く

mpeg-dash形式のH.264とAACをmuxしたい(mp4でもmkvでもコンテナはmuxさえ出来れば何でもいい)のだが
mp4boxもmkvtoolnixも対応してない形式として弾かれてしまう

mpeg-dash形式に対応してるmuxツールあれば誰か教えて下さい

ID:nKP2+urB

>>392
L-SMASHとかffmpegとかは？

mp4で出力するのは汎用性があるからに尽きるな
PSPからスマホからAV家電まで
殆どの機器で再生出来る

>>395
だよね
カッコつけてmkv使ってたら後悔した

汎用性がある代わりに拡張性が無いMP4
汎用性が無い代わりに拡張性があるMKV

好きなの使えばいいんじゃけえ

字幕をソフトサブで入れたいとか音声を2つ以上格納したいとかじゃないと
mdvを使う必要はナッシング
映像h.264＋音声aacならmp4で事足りる

どっちもmp4でできるよね

たしかにｗ

チャプターもmp4でセットできるしな

そんな事よりVFRの存在を忘れてた

この流れにVFRって何か関係あるっけ。

なんでもあり的なのよりルールに縛られたコンテナの方が日本人の性格に合ってる
mp4の各種ツールが規格通りに実装されているかどうかは別問題として

mkvを無理して使ってたのってflacが扱えるからってだけだし
alacが登場した今となっては使う理由もないな

字幕ぐらいかな...mkv

2桁refみたいな無茶やってるとmp4でも再生できなくなったりするけどな

映像複数入れられるのってTSくらい？

入れようと思えば、mp4だってmkvだって入ると思う。

複数映像入れる利点が無い

地上波の後、BSでおもいっきり修正入ってるのとか入れられないかなとか妄想して
結局実行には移してないけど

>>410
一応デジタルテレビの仕様にマルチアングルも定義されてたような記憶がある。
放送されてたことはないはずだけど、もし放送されたらmp4にする時も同じように
したくなるよね。

立体視用に複数映像が使われてる
3DSなんかAVIでやってる

利点と言うか、願望なんだろうね。
こういうのがあったら、面白そうとか、楽しそうとか。。
実際にやってみて面白いとはそういうのは別の話だとは思うけど。

>>414
アナログ時代に（確かTBSとフジだったと思うけど）同じドラマを同じ時間にマルチアングルで放送するっていう
実験ドラマやったことがあって、これを一局でやれることになる。まあ、失敗したからそれ以降やったことはな
いはずだけどｗ
ゴルフとか野球とかで優勝争いの場面をマルチで流すとかアイデア自体は普通に考え付くんだけどね。コス
トとかも含めていろいろと現場が追いつかないんだろうな。

個人でっていうなら別ファイルにして同時視聴したほうが良くね

放送局のマスタ送出システムは解像度変更するだけでリブートしないといけないとかいうへっぽこだから
規格にあれやこれや定義されてても絵に描いた餅ですわ

>>415
その程度ならWOWOWとかNHKでマルチ編成してちょと前にもやってた記憶
あとAVでもDVD出た頃にチャプター利用したマルチアングル物が…いやなんでもない

3840x2160@60Hz で不都合が出る。
何故かは、見当もつかん。
同じファイルを 1920x1200@60Hz で再生すると何事も起こらん。

>>419
こっちはお前が何を言いたいのかさっぱり見当もつかんよ。

きっと誤爆

デコーダや再生支援が4kに伸張再生できないとかって話じゃね？
誤爆じゃ無いにしてもスレチ

GPUが遅くて、描画がおっつかないのかも

俺みたいな貧乏人は枯れた技術にならないと
機器揃えられないから関係無い話だわ

同人物でH.264+AACのmp4エロ動画をdmmでダウンロード販売してるけどあれってライセンス料どうなの？
H.264の動画配信は無料だけどAACって金かかるよな確か

スレにDMMの社員が居れば明確な答えも返ってくるだろうけど、そもそもスレチ。

>>425
コンテンツにライセンス料はかからない。

Q AAC には使用料がかかりますか?
A いいえ、使用手数料はありません。エンコーダまたはデコーダの販売に対してのみ、ライセンス料金をお支払いただきます。
AAC でエンコードされたビットストリームの配信に関しては、特許ライセンス料金は不要です。放送、ネットワークでのストリー
ミング、物理的メディアでの提供など、配信形式は問いません。

>>392
mkvtoolnix対応したっぽい

popさん復活して…

>>429
Komisar版で何か困ることでもあんの？

L-SMASH関連の更新は欲しい

L-SMASHなら公式に入っただろ
x264-audioのこと言ってるならもう誰もメンテしてないしはっきり言ってレガシーすぎる

Handbrakeスレにあったx264、x265のエンコード例のグラフ。
各プリセットごとにcrf=20〜30でエンコして、ビットレート（ファイルサイズ）とSSIMの関連を表したもの。

　　ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1461.jpg
　　ttp://i.imgur.com/ZQl3NLq.png
　　ttp://i.imgur.com/dTiyhbx.png

１つ気になったんだけど、x264 veryfastの場合だけ、他と比べてSSIM値が妙に低い。
他がcrf=aで実現できているSSIM値が、x264 veryfastだとcrf=a-2にしないと実現できてない。
例えばx264 veryfastのcrf=24は他のプリセットのcrf=26に相当するとかそんな感じ。
SSIMだけで見るもんじゃないってのはあるかもしれないけど、これはなんでこうなるんだろう？

>>430
popさんのlight版の方が速いのさ

>>433
たんに処理が簡単になり過ぎるんじゃなかろうか。
CABACが使えるxvidみたいなイメージ。

x264の結果もおかしいけど、むしろx265の品質が揃ってるのがびっくりだな
ちょっと前はfast以上と未満で、crf換算2どころじゃなく狂ってたはずだけど
これは改善されたのか、それとも--tune ssimだから？

>>436
x265はpsy系がまだEXPERIMENTALで、どのプリセットでもOFFになってるから
--tune ssimの影響は低いと思ってるんだけど、どうなんだろう。

>>435
処理が簡単になりすぎても、レート制御はそれも見込んで行われるもんだと思ってたんだけど、どうなんだろね。

> どうなんだろね。

じゃぁ、そうなんだろね。

映像だと曖昧で説明しづらいけど
mp3で言えば聞こえないからバッサリ切ってる様な所も残しとこう的な
オプションが有るか無いかの違いじゃね？

>>439 >>435
不快にさせてしまったようでごめん。
>>438は「レート制御のバグとかじゃなきゃいいんだけど。」と続けたつもりだったんだがミスってたみたいだ。

「--tune ssim」をつけない場合の傾向も気になったので、全プリセットでエンコしてから、
AvisynthでSSIMを計算して>>433と同じようにグラフ化してみた。
SSIMがそのまま画質を表すわけじゃないというのは大前提として、参考までに。
　　ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1482.jpg

>>433と同様にやっぱりveryfastがちょっと低めなのが気になるけど、
ultrafastも我が道を行くみたいな感じだったし、まあこういうものなのかな。

SSIMやPSNRって要はx264に読まれたソースの状態と、x264でエンコした成果物の差異を数値化するだけだろう？
圧縮率が高くなりビットレと容量が抑えられたら自然とSSIMやPSNRは高い値を示すってだけで
それは画質向上につながるとは言い切れない。エンコードされた動画ファイルや音声ファイルの類は
プレイヤーが再生(デコード)するたびに元のデータに近づけようとするからより高圧縮な物ほど再生に負荷がかかるし
x264は可逆でないからプレイヤーで再生する際も高画質を維持できるとも言い切れない。

(*´з`)まぁ、エンコしてああデータ量が小さくなってよかったわ。
っていうぐらいの価値しかないんだよな。

>>443
書いたとおり、SSIMが同一性を表す数値の１つであって、「SSIM≠画質」ってことは理解してるよ。
ただ、crf指定の場合はどのpresetでも大体同じくらいのとこに収束すると思いこんでたんで、
veryfastやultrafastでのズレは少し意外だった。

>圧縮率が高くなりビットレと容量が抑えられたら自然とSSIMやPSNRは高い値を示す

前半と後半のつながりがなくね？
「高い品質を指定したら自然とSSIMやPSNRは高い値を示す」ならわかるけど。

>x264は可逆でない

細かいツッコミだがqp=0で可逆圧縮もできるで。

>>444
>圧縮率が高くなりビットレと容量が抑えられたら自然とSSIMやPSNRは高い値を示す
2パスなら圧縮率が高い＝同ビットレートではSSIM,PSNR向上なら分かるんだけど
確かにCrfなら前半と後半が繋がらんな

低精度な設定で余りにも動きが複雑なソースならいくらビットレート盛っても動き予測でミスが起きるだろうし、そこら辺が関係してるんじゃないの？
特にveryfastやultrafastはmeやsubmeが悲惨だし

>>445
>低精度な設定で余りにも動きが複雑なソースならいくらビットレート盛っても
>動き予測でミスが起きるだろうし、そこら辺が関係してるんじゃないの？
>特にveryfastやultrafastはmeやsubmeが悲惨だし

>>435とかにもあるけど、やっぱりそのあたりの話なんだろうね。
>>442の例ではsuperfastが踏ん張ってるけど、基本的にはveryfast以下のプリセットでは
あまりレート制御は当てにならない感じなのか。

>>446
同一crfならプリセットによらずSSIM値はほぼ一定になるはず
superfastが踏ん張ってるというより
ultrafastとveryfastだけ品質目標を無視気味に突っ走ってる感じがする

パラメーター弄っても同一crfなら圧縮率が違うだけで画質にはほぼ影響しない
と言われた気がした。

>>448
そのためのcrfだと思うけど、なんか文句あるの？

ここ数日の流れの違和感は品質と画質をいっしょくたにされてるからだと気がついた

１回戦目も2回戦目も硬さは同じだけど出る量が違う

硬さが大事。大きさはあまり重要じゃない。

硬さとか大きさ?むしろ重要なのはオッキした時の長さじゃね?

太さなんだよなあ

>>450
要は同じじゃないの？

量子化の＜品質＞とあれやこれやした後に出来上がった物の＜画質＞は
解説サイトなんかでも意図的に分けて書いてると思うんだがなぁ・・・。

はででがやばいんでまたエンコ始めました。目標は一日80GB分の圧縮ｯｽ(´･ω･｀)

80GB・・・ああ、1日分の平均録画容量か。

ようつべを四時間ぐらい７２０Pで見てると６GBぐらい行くな

x264 が出力する raw を GOP 解析できるツールって無いかな ?

なんのため？
x264自体がログ出すのにそれ以上どうしたいんだ？
グラフとかか？？

>>461
x264 が出力するログは I B P の総数や割合の表示だと思うのだが
自分が調べたいのは、まるもの mmc@MPEG-2 で表示確認できるフレーム単位で
実際にどのタイプになっているかという情報。

言い遅れたが 4k モニター環境での再生を検証中の者だが
x264GuiEx の設定にある IDR の出力間隔がデフォルトで 300
自動で fps x100 ってのに少々疑問を感じてね。

MPEG-2 と比較するのはナンセンスかもしれないが
TMPEnc は v2 でも v5 でも GOP内は 18 フレームで IBP を振り分け
BS放送などでは 15 フレーム

ちょっと実験してみた結果
x264 の IDR 間隔の最大を 30 程度に絞ってみたら
抱えていた不具合が一挙解決されたので
もう少し具体的に調べたくなった。

>>462
ttp://higitune.blog106.fc2.com/blog-entry-109.html
で紹介されているAvidemuxとかどうだろう。

(10)のFrame Typeのところに表示されるみたい

raw出力が扱えるかは知らないけど。

>>462
> x264GuiEx の設定にある IDR の出力間隔がデフォルトで 300
> 自動で fps x100 ってのに少々疑問を感じてね。

一応書いておくとデフォルトは300じゃなくて250で、これはx264のデフォルト値にあわせてるだけ。
あと、ただの書き間違いだと思うけど、自動はfps×10。こちらはx264guExがそうしているだけ。
放送やBlu-ray等ではGOP長とかが決まってるけど、そうじゃなければキーフレームでのシークを考えて、
最長でも10秒くらいでシークできたほうがいいよねという程度の理由じゃなかったっけ。

> x264 の IDR 間隔の最大を 30 程度に絞ってみたら
> 抱えていた不具合が一挙解決されたので

抱えていた不具合ってのが何なのか気になるし、そっちを具体的に書いたほうがいいんじゃないか？

抱えていた不具合

以下時系列

・ x264GuiEx の初期値で MP4 (POP) を作成
・ WUXGA で再生の時点では特に問題なし

・ 3840x2160@[email protected] (Haswell-iGPU) (以下UHD) 導入
・ 放送TS 再生時では問題なし
・ MP4 の場合 1920x1080@30p 以下なら問題なし
・ 1920x1080@60i または 1920x1080@60p を全画面再生すると不特定箇所で画面破綻 (マクロ・ブロックのような)

・ 上記の MP4 からエレメンタリを抜き出し TS、MTS、MKV に詰め替える (MP4以外は症状が同じ)
・ 再生直後六秒程度、音声は出るが、絵が出ない。
・ シークすると一、二画面破綻 (マクロ・ブロックのような)

・ I ピクチャと IDR は、厳密に同じではないが、TMPEGEnc では GOP周期は 18 だったなと思い出す。
・ x264 の IDR 間隔最大を一律 30 (根拠：30fps、初期値の1/10) としてみる。
・ 結果、コンテナに関係なく無問題と思われるファイルが出来上がるようになった。

考察
・ たぶん UHD 未満では問題はないのかもしれない。
・ MP4Box (POP) だけが何か個性を持っている (気がする)。
・ やっている事が適当に突っつきまわしているだけで論理性にとぼしい。

現時点での対策
・ 永久保存だなってのは元を残す (エンコしないという意味ではない)
・ IDR の間隔最大を 30 に固定。

俺4kモニタだけど何の不具合もないなぁ

>>465
プレーヤーとスプリッタ、デコーダーの名前とバージョン、それとデコーダーのDXVA設定は？

グラボ変えればいいだけの気がする

ｒ2525とｒ2491を試してみたが
AMD環境だとr2334の方が何故か早くエンコが終わる
もうほんとなんだこれ状態。2525なんて2fpsぐらい遅くなるから話にならん。

>>467
常用基本部分は Windows7SP1 と WMP
再生系に食い込む物としては Haali Media Splitter ver1.11.96.14
実験的に VLC Player ver2.1.3

Windows7 のアップデートで動画再生に関係しそうな物は KB2670838 (プラットフォーム更新) のみ

MKV の再生以外では、基本的に Windows7 のそれで再生されているはず(と思う)。
先に述べた不具合は WMP でも VLC でも同様に発生する。

何かの設定を変更…
iGPU のコントロール・パネルで余計な処理と思われる部分を OFF にしたくらい
だが、それを変更したところで不具合が発生するのは変わらない。
それ以外は何もしていない (はず)。

>>468
せっかくだが、そのやりかたは自分にとっては無意味

無意味ってどういう意味？

普通に考えれば、GPUを買い足さずになんとかしたいってことだろ・・・

おまけ

AviUtl + x264 で 3840x2160 が作成可能
30p と 60p を作成してみた。
AviUtl の先読みバッファを 16 程度にしないと途中でエラーが出る。
素材は 640x480@60p (UtVideo)
拡張編集で24画面を合成した。
尺は7分程度だが書き出しに7時間程度要した。
x264 のエンコード速度は 7〜8 fps 程度。
CPU は 4790K (プチOC全コア4.4GHz)

30p は素の Windows7SP1 で再生できるが
60p は絵がでなかった。

VLC では再生できる。

AVI コンテナを利用する UtVideo の中間ファイル利用では
256GBで頭打ちがあるので 3840x2160 の場合一挙に処理できるのは 60p で 15分程度。

ほぅ、Utって256制限あったんだ。
これから先、4Kが普及しだすと面倒だな。

無意味ってどういう意味？

>>474
Ut に制限があるのではないみたい
Lagarith でも Huffyuv でも "無圧縮" でも 256GB 以上の
AVI は正常なファイルにならない。

なーロベルト
無意味ってどういう意味？

元の話もx264の問題ってわけじゃなさそうだけど、ずいぶん変な基地外呼んじまったもんだな。

>>476
そうなんだ。
何かしら解決方法がないと、この先面倒だな。

>>470
こうしたらどうかって聞かれてるのに対して無意味って何様？
後からグラボが腐ってましたすいませんとか間違っても絶対言うなよ

>>478
基地外はどっちだと思う？

自己解決しました

intel gpu 動画再生 不具合
でググるといろいろ出てくるが最終的には「ハードウェアアクセラレーションを切る」になってんだから
GPU買えって答えはすごい正しいんだけどな
原因不明でIntelだけが引き起こす現象が多いんだから

>>483
それなら「LAV入れてDXVA切れ」で済む話じゃね。一足飛びに「GPU買え」は間違ってはいないがアホだろ。

まあ「抱えてい"た"不具合」だからな
もう解決したことを書いてるんだから、「GPU買え」は適切じゃない

要は前レス読めって話だ

>>463
遅れたが良いソフトを紹介してくれてありがとう。
32bit版と64bit版を両方使ってみた(10file程度)。
だが、32bit版は何事もないが64bit版ではビルド・エラーなるものを吐くファイルがあった。
何度やっても、エラーを吐く。
264 のピクチャー解析には、当面利用させていただくよ。

今更だが--openclをパラメータに追加するだけで2Kを越えるエンコ速度が僅かだけ加速するのな。

どゆこと

avsを通さずに1920ｘ1080iソースを1920x1080pでエンコさせるときに 僅かだけ早くなる
avsを通して1920ｘ1080iソースを1280x720pでエンコさせるときに だいぶ早くなる
avsを通して1440ｘ1080iソースを1280x720pにエンコさせるときに もっと早くなる
avsを通して720ｘ480iソースを1280x720pにエンコさせるときに すげー早くなる

source codeを見たわけじゃないからどのぐらいまで影響するかは分からないが
avsのGPUフィルタとの併用も特に問題ないっぽいし何か良さげ
どのぐらい早くなるかはグラボの性能やグラボのOC設定に依存するっぽい
ただしグラボのFANがいつも以上に超回転するから今の季節にはちょうどいいかも
Aviutl+VCEで拡張264出力させるよりはパラメータ制約もすくなくて手頃かもな

ちなみにAMD環境+ﾗﾃﾞｵﾝHDではこんな風になる

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. ＊＊＊＊
x264 [info]: Compiling OpenCL kernels...

＊＊＊＊にはグラボのコードネームが表示

良さそうなのか

＞2Kを越える
これってどういうこと？

openclはゲームPC等のグラボの性能が高いもののCPUはグラボほど性能高くないって場面で生きると思う
何気にCPU使用率が上がるからCPU使用率が上がらない場合が最も速度が上昇しやすいと思う

Win8.1 64bit、i7-4702MQ、IntelHD4600（ドライバ3960）、AviUtl+x264guiEx＋x264.2525kMod.x86_64.exeで
　　--crf 23 --opencl
だけでエンコしてみたら、エラーログも出ないままドライバが落ちて固まったでござる。

OpenCL acceleration って lookahead だけしか効かないんじゃないん？

最初に--openclが導入された時はそうだったから1割も変わらんかったが
今は随分早くなってるからいろいろ変わってるんじゃない
x264開発は使えるものは使おうってコンセプトだし

8bitでしか使えないってのは

>>494
そんなバカなと思って試した。
うん、変わってねぇ。
だって、opencl周り変更入ってねーもん。
ラデの方が、もうちょい効果あるかもしれんが、Veryfastの結果見る限り
効果1割ってのは、変わらんと思う。

【CPU】i7 [email protected]
【MEM】DDR4-2400 4GB x 4
【M/B】ASUS X99-DELUX
【GPU】ASUS STRIX GTX980
【OS】 Win8.1 x64
---------------
【x264】rev2525 (x64)

【Veryfast】 131.16 fps, 34694.32 kb/s
【. Medium】 33.97 fps, 35376.91 kb/s
【　 　Slow】 15.39 fps, 34119.11 kb/s
【.　Slower】 7.79 fps, 33903.79 kb/s

--opencl
【Veryfast】 145.55 fps, 34540.61 kb/s
【. Medium】 34.78 fps, 35216.79 kb/s
【　 　Slow】 15.86 fps, 34082.54 kb/s
【.　Slower】 7.74 fps, 33852.09 kb/s

lookaheadの数値変えたり
PCIEの帯域何とかできない限り大して変わらないんじゃないの

>>497
帯域を何とかできたとしても程度問題。
現在のアーキテクチャではお仕事の大半は何ら処理の伴わない単なるデータ移動。

r2525って何がいいのかさっぱりわからんとです。
ｴﾝｺ速度も遅くなったし､EXEのﾌｧｲﾙｻｲｽﾞが激減したぐらいで
メリットが見当たらない。

アップデートはエンコ速度を上げる為じゃないから・・・

そんなこと誰も聞いてないんだが、メリットについて教えてくれ。

最近のアップデートはARMにたいする最適化がほとんどだった気がする。
一件か二件ぐらいbugfixもあったきがするけど、好きなのを使えばいいと思う

>>501
そもそも誰も何も質問してない思うけど違うの？
何か教えて欲しいならそれを書けばいいと思うし、VideoLANのログを見ればいいと思う
ttp://git.videolan.org/?p=x264.git;a=log

書き込んだら>>502と被った
それと
VideoLANのログを→今回の場合はVideoLANのログを
に訂正

そんなこと言ってるとガチでスレの存在意味が薄れるな。

まぁ自治し過ぎると話す内容無くなる罠

>>501 >>503
Komisar氏のとこにあるChangelogだとrevisionがわかりやすくていいかもね。
　　ttp://komisar.gin.by/old/2525/x264_changelog.txt

あれ？EVRってH.264のfullrangeフラグ（--range pc）を解釈してくれないんでしたっけ？
madVRだとちゃんと解釈してくれてるのですが、以前はEVRもちゃんと解釈してくれてたような？
私の記憶違い？

r2525とr2491とでどちらがエンコ速度が速いですか？
それともどっちも遅くてエンコ最速のrevが別に存在してますですか？

>>509
自分で試せばわかることではありませんか？

上の方を読み返すべき。

わかりました。ありがとうございます。

>>509
解析を途中切り上げするバグ持ちで妙に速いrevがあったが
それをどうぞって言われたら使う？

最近r○○が遅いみたいなレスが目立つけど同一人物なの？
常に最新のrevを使えとは言わないけど速度だけ見て判断するのはやめたほうがいいと思う

>>513
r2150ぐらいだったっけ？懐かしいな

>>509
AMD環境なら迷わずr2334のが早い。
AMDでしか使わない拡張命令がひとつr2346でハブられてしまったし
r2334以降は蓮とARM向けの拡張ばかりだし恩恵はない。

>>513
それひどいおｗ

>>513
あった、あったｗ
でもr2150ぐらいなんか、もっと前かと思ってたが・・。

Jason Garrett-Glaserっておっさんが性同一性障害だかゲイだって噂が合ったがあれ本当だったんだな
Fiona Glaserに改名しとる

x264の開発員の中に何人か日本人が混じってるけど
x264関連ブログで名が広まってる人の名前は現れないのな。

>>515
Phenom�U x4だと25の方が早かったよ

>>519
自分の解釈だと開発できる程度では無いやつ。

r2525試してみましたです。Ivy Bridgeですが、十分エンコ速かったです。
なので、これを使っていくことにしました。

プリセットのロードの枠について
速度の違いによる画質差の全体的な評価ってあるんですかね
それともありがちな人によって全然違うという感じですか
ただあくまでも全体的な平均しての評価でいいんですけど

例えば「fastとfasterのところで結構違いが出る線引き」とか
「動きがある番組ではmedium以上でないとダメ」とか

１つのソースでのプリセットごとのテストでよければ>>433とか>>442とか。
SSIMがそのまま画質を表してるわけじゃないというのは大前提だけど。

品質って言わないと画質警察が来るぞ

画質警察の職質とか胸熱

SSIM値が21dbを越えるようなエンコになっても
実際プレイヤーでエンコした動画をみてみると
そんなにソースの画質を再現しているようにはみえないよな

SSIM値って圧縮前と圧縮後の画質・品質の差なんだろ?
差が少ないほどdb値は高い値がでるけど、そもそも圧縮前の画質が酷かったら
元も子もないから結局SSIM値なんて気にしなくていいって事なんだろうけどさ。

>>527
SSIMは画像の同一性を示す指標の１つ。
ソース映像との同一性を示す数値的・客観的指標としては
人間の感じ方を踏まえると一番マシ（？）だから使われてる。

「圧縮前の画質が酷かったら元も子もない」というのは全く別の話なので、
それをもって「結局SSIM値なんて気にしなくていい」という結論につなげるのは何か違うと思う。

まぁ人に伝えるときはSSIMの数値で充分よ。
それ以上の心理効果は見る人によって受け取り方は変わるわけだし。

Default の IDR最大間隔が 250
世間はあまりシークさせないんか
それとも俺(環境含)がポンコツなのか

>>530
お前はポンコツ以前

>>530
初心者スレに行けよ

>>530
何処のフレームに飛ぶかわからんシーク・バー使うよりチャプター使えよ。

>>530
馬鹿だから全部 IDR にするのがお前にとっての正解だろ

新手の自演？

DivXのプロファイルだと、keyintは最大でも4秒分

あれはハードの認証向けに制限してるだけ。
x264もBDに焼くときとかはBlu-ray向けのコマンド追加しないとダメだし

>>530
そんなにシークが重要なら、エンコードする前に編集しとけよ。
ダイジェスト版でも見とけボケッ

keyintは24か30だな
サクサクシークしたいもん

俺はfps*5にすることが多いかな。それぞれ好きにすればいい。デフォ値にケチつけてどうすんだ。

ああ、そういや俺はあらゆるパラメータを3の倍数で合わせてるな
QPとかkeyIntとかbframeとrefetcとかetc

3と3の倍数のときにアホになる

必死に 3820x2160@60p の動画を作ったが
Windows 7 の H264-Decoder は 30p までって事だった。
チキショーッ

>>536
何もわからない初心者がそのまま使うデフォ値はまともな値であるべきだ

>>540
こんなとこでピーピー騒いでも無意味だと思うけど、君の考えるまともな値っていくつなの？

今の時代250というのは充分まともだろう
DVD時代は初めて家電にキャッシュするという概念が導入されたばかりだったから
closed-gopや1秒位以内のGOP周期なんていう圧縮に不利な規格になってたに過ぎない

>>540
何もわからない初心者は内容を理解しないで--preset、--tuneを使うからむしろデフォ値関係ないｗ

とくにアニメだから--tune animationでいいだろう、って最初はやりがちだけど
馬鹿としか言いようがない、俺も最初やったけど

自分の環境と使い方では
シーク時に I ピクチャがくるまで絵がグズグズなので
keyint が fps x 10 なんて事では我慢できない。

>>543-544
話に出てるのは--keyintのデフォ値であって、--preset、--tuneとは何も関係ないんだが大丈夫か。

漢は黙って--qpfile。

ノイズ乗せる系のデバンド処理した場合にkeyint値で見た目がガラッと変わったり

ひさびさにがっつりエンコしてるが昔2コアのマシンで一晩掛けて
やっと2〜3話分やってたの思い出したら今は天国やね(´･ω･｀)

x264 に直接関係する事ではないが
動画エンコードなら SSD 不要っては言いきれないのね。

SD (640x480) をタイル状に 24個並べるってのを 7min 程度作るのを
HDD だけでやったら 7時間以上かかった。

凄い作業してるなｗ

>>551
あいがとう
凄いが、どのような意味でつかわれるか大雑把み二つ考えるが
この場では善意に受け止めさせていただく。
24の動画を最終位置で１フレーム単位で同時終了を小細工で
終わらせることがやらない編集はえらく大変だったよ。

触るな危険

>>552
それをしょっちゅうやるなら有料だがtmpgenc video mastering worksやvegas proみたいな
レイター並べてタイムライン編集できるソフトあると楽
おれはtmpgencでフレームタイミング合わせてそのデータを元にAvisynthスクリプト組んでx264に食わせてる
最大で31動画だったけどそんな重くなかった
ただしDGindex経由では重いのでUtvideoの中間ファイル使ってる
こういうのでしょ↓

＊注：違法動画です。30秒過ぎ辺りから1２ファイルパターン

ttp://www1.axfc.net/u/3420368.mp4

>>554
動画は違法との事なので触れずにおきます。

しょうかいしてくれて、ありがとう。
まだまだ勉強中なので簡単にできる物ではなく
遠まわりしてみます。

動画の紹介よりAVSとx264パラメータの紹介を優先してほしかった。

avsなんて見ても意味ないと思うが

org=Avisource("D:\avi\anjyu_taiki\org.avi")#オリジナルＭＶ
wada=Avisource("D:\avi\anjyu_taiki\wada.avi")#和田ソロ
wada=wada.plusclip(plusf=744,minosf=0)#元とのフレーム調整
fukuda=Avisource("D:\avi\anjyu_taiki\fukuda.avi")
fukuda=fukuda.plusclip(plusf=735,minosf=0)
中略
video1=StackHorizontal(StackHorizontal(wada,fukuda),StackHorizontal(nakanishi,takeuchi))#一段目
video1=video1.addborders(0,480,0,0)#Stackなんちゃらは同じ画面サイズですか合成できないので調整。全段いったん(704x4,480x2)にする
videox=Stackvertical(StackHorizontal(katuta,katuta),StackHorizontal(new,new))#中段は真ん中に大きなオリジナルＭＶを置くため、左端ブロックを(704x2,480x2)
videoy=org.nnedi3_resize16(1408,960)#中段中央ブロックの大きなオリジナルＭＶ
videoz=Stackvertical(StackHorizontal(tamura,tamura),StackHorizontal(dance,dance))＃中段右端ブロックを(704x4,480x2)に
videow=StackHorizontal(StackHorizontal(videox,videoy),StackHorizontal(videoz,videoz))#左端中央連結で中段
video2=videow.crop(704,0,-2112,0)#中段連結のため仮に足した部分を削る
video3=StackHorizontal(StackHorizontal(murota.addborders(176,0,0,0),aikawa.addborders(176,0,0,0)),StackHorizontal(sasaki.addborders(176,0,0,0),sasaki.addborders(176,0,0,0)))
video3=video3.crop(0,0,-704,0)＃最下段は一段目と動画の数が違うためaddbordedersで調整
video=Stackvertical(Stackvertical(video1,video2),Stackvertical(video3,video3))#三段連結。ただし三つ連結はできないからいったん四つ連結
video=video.crop(0,480,0,-480)#連結のための仮の不要部分を削る
video=video.nnedi3_resize16(1280,720)#リサイズ
org2=org.nnedi3_resize16(1280,720)#元MVだけのシーンのため元MVリサイズ
video=org2.trim(0,722)+video.trim(723,7388)+org2.trim(7389,0)#元MVOP+連結+元ＭＶエンディング
audiodub(video,audio)

めちゃくちゃスレ違いだけどAviUtlの拡張編集使ったほうが簡単じゃないか？

拡張編集が導入される前からこれでやってるんだわおれ
もう10年以上こんな動画組んでる



function plusclip(clip clip , int "plusf",int "minosf") {

blankc=BlankClip(clip,length=plusf)
clip=UnalignedSplice(blankc,clip)
final_frame = 0#clip.FrameCount() - 1
clip=clip.trim(minosf,final_frame)
clip=clip+BlankClip(clip,length=1)



return clip
}

x264.exe --crf 1

切れちゃった
以上

x264.exe --crf 16 --preset veryslow --tune film --opencl --weightp 1 --me "umh" --subme 10 --aq-mode 3 --trellis 2 --psy-rd 0.5:0.15
--bframes 3 --ref 4 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --qcomp 0.7 --qpmin 15 --qpstep 16
--min-keyint 2 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --output "%~dp1%~n1.video.264" "%~1"

10年以上やってたのね。それは失礼しました。

新しいものに対応できないだけだったりｗ
一応試したことはあるんだけど
/

新しいものに対応できないだけだったりｗ
一応拡張編集は試したんだけど
・Utvideoの読み込みがなぜか遅い
・Bt.609と701混合連結をどうしたらいいかよくわからない（TMPEncのタイムライン出力使わないのもこの理由）
・スタジオライブや公式tubeソースなどAvisynthのフィルタ使いたい時もある
解決策はあるのかもしれないが
それを探るより手慣れた手法続けたほうが楽

書き込みも満足にできてないｗ

ヲタってキモい

かなり前からハロプロ系でそのような動画あったけどもしかして作ってた人？

スレチなんだから放っておけよ・・・。

>>557,559,560
�d

AVSのコメント文はいらなかったけどaudio周りはいじらないのな。

贈・取捨選択

avisynth 使わずx264.exe だけで色空間のコンバートできる？

input-cspとoutput-cspが違ったらlavfで色空間変換されたはずだけど、colormatixとか考えるとavisynthでやった方が確実な気がする

ありがとうございます
やってみます

エンコしたもの置き場にしてるミラーリングしたHDD3TB*2が
満杯になってきた4TB*2にでもしたいが今HDD高いんだよな
ぎりぎりまで粘るしかないか…

エンコした古い動画をBDRに焼くなりして消せばいいんじゃね?

エンコした古い動画を他のHDDに移動するなりしてけせばいいなじゃね

ミラーリングをストライピングにすればいいんじゃね

http://www.stereosound.co.jp/column/from_inside/article/2014/03/07/28580.html

会員制の海外エロサイトで動画を落としたらthreads=36になってたんだが
HT有効で36Threadだとして無効だと18Thread

18コアのCPUなんてあるのか？Xeonとかだろうか

>>578
x264は実スレッド数に1.5xするから、12コア相当のXeonか何か

知らなかったサンクス

多分これやね
http://ark.intel.com/ja/products/81061/Intel-Xeon-Processor-E5-2699-v3-45M-Cache-2_30-GHz

コアの数 18
スレッド数 36

Xeon E5 v2, v3 シリーズで
2プロセッサ、HT構成なら
論理コア40以上余裕で行くんだよな
個人でも70万ぐらいあれば手が出るんじゃないか？

threadsは多スレッドCPUならデフォルトより少し高くした方が速くなるから俺は上げてる。
エロサイトがそんな設定やってるわけは無いと思うが。

だがそういう設定にするとCPUを使い切ろうとするのでエンコ処理時の消費電力が大変なことになる。
スレッド数 * 1.5ではCPUが持て余すから消費電力が跳ね上がるなんてことはないけどさ。

x264の処理の場合、必要以上にthread増やすと、
圧縮効率が微妙に悪くなるのと、SSIMへの影響もあるって
誰か言ってた気がする。

ま、でもAVSを取り込んでエンコすれば1.5倍でも全然CPUを使い切っちゃう事もあるけどな。
GPUフィルタである程度は負荷低減できるとはいえ、重いフィルタは山ほどあるし

オーバーヘッドが増えるだけだからデフォより増やすやつはただのアホ

微々たる画質の悪化と速度の天秤なんだから
好きにしたらいいと思う。
自作板のベンチスレでも実験してる人いたし。

threadsを増やすことで設定をわざわざ確認するような画質に拘るユーザーにこのメーカーは
すごい性能の機器を活用して高度なエンコをしていると勘違いさせ、ならば高画質に違いない
という誤った信頼感を植え付けるための巧妙な罠
金もかからんしな

threads盛るのは素人
プロはthreads控えめにして複数ジョブで使う

高速化には8スレッドを超えると増やした効果があまりない気がする
それ以上は動作クロックを上げた方がいい気がする

>>587
オーバーヘッド増えるから
速度面での伸びしろ少ないならむやみに増やす必要はないよね
HTTとかあるなら増やしても多少は許容範囲じゃないかって感じ

>>591
4コアあたりならそんなもんじゃないの

俺は6コアばかり使ってるからまぁ詳しいことはわからんな

Celeron2コアの僕は動画の再生時間x5倍がエンコードにかかる時間です

例
20分の動画x5=100分=1時間40分

エロアニメです

どんな設定でそのエンコ時間なのか詳細がわからないと参考にならんよ

わかっても参考にすらならないだろ

エンコードの進捗状況にムラムラくる体質という可能性も・・

CPUのコア数増やして分散処理するのもいいけど
コアあたりの動作クロックも上げてもらわないと効率悪いんだよなぁ

プレスコットちゃんの出番か

>>599
アイツは知恵熱上げるだけのクズ