x264 rev40

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 rev39
http://toro.2ch.net/test/read.cgi/avi/1374779753/

俺ここの264スレ目がきたら田舎の彼女と記念に結婚するんだ

お値段異常ニトリ

ﾊｲｰｷｮ

エンコしてますか？

JC食いまくりよ！

公共広告機構美味しいです

芦田、愛菜がいないのお陰でお腹いっぱいです

taroのr2389きてた

負荷高過ぎてブルースクリーン出るわ

本当に実写は縮まないな…
普段アニメしか録らないけどANIMAX MUSIXで痛感してる

実写はテカテカにすれば縮むよ

GCCを使ってビルドする方法
http://blog.k-tai-douga.com/article/87146386.html

>>11
政見放送えらく縮んだよw

そりゃ動かないからだろｗ

背景もシンプルだしなｗ

奴らはビビる！！ 私もビビる！

オリンピックのジャンプは品質25まで落とした
普段実写ものは23にしてるんだけど、動きまくりの動画だったら25でも十分だなって気がついた

政見放送も縮むけど、放送大学の縮み方もすごいものがある
平均ビットレート2Mbpsでもまったく問題ない

そりゃ、食うほうがおかしいわな

>>18
カーリングは縮むがボーダー連中はあかん
結局オタク<<リア充がまたここでもorz

>>21
qcとRD下げて雪質も糞も無い状態にすれば縮むんじゃなかろうか

実写はMDegrain3でネチネチとエンコするのに慣れてしまったが、
映画一本エンコするのに一晩かかるのは何とかしたい。
だが、今更FFT3DGPUとかじゃ品質的に納得できないから困ったものだ。

ところでJEEB氏はなかなか更新しないけどどうなったの？
どっかでx264は色変換(というかbit変換？)にバグがあるって聞いてからずっとJEEB氏ビルド使ってるんだけれども、とっくに修正されたの？

先月死んだ

wwwww

アニメをCRFにするのは分かるんだけど
実写は1passで十分
アニメは動きの早い場面でも1コマの質は止まってる場面と変わらないが
カメラは動きが早くなると1コマの質が落ちる
そこを無理やり品質保つとビットレートが膨らむ
ブロックノイズだらけの動画に無理やりビットレート振ってるような無駄が
実写のcrfにはあると思うよ
HDDレコとか全部1passだし、放送mpeg2自体も1passだしな

>>27
> 放送mpeg2自体も1passだしな

放送がすべて…後はわかるよな

おお…

しま・・・

ゆう・・・

のすけくん・・・

死去。

1週間前に

再誕

推参

東洋

嘘だと思ったら買わないで下さい。

※あくまで個人の感想です。

自信があるから、電話しません！

※但しダイレクトメールは大量に送付します。

aqmode1から4の違いを教えて下さい

>>42
数字が大きいほど効果にメリハリがつくと思えばいい

プロファイル次第だけどな。

>>43
ありがとう
下手に使うと暗部死ぬかな

L-SMASHって更新しなくなったのか？

先月死んだ

ttp://astrataro.wordpress.com/
ここの--optsオプションが気になって8bitのlite版(32bit)使ってみたのですが、
自分でテストする限りrc-lookaheadの値が29までしかあげられないようです
サイトにはそれっぽい記述は見当たらないと思うのですが仕様？バグ？どちらでしょうか

すみません別のバイナリをいくつか使ってみても29どまりだったので自分の設定の問題だったようです、失礼しました

--keyint 29
にしてるんだろ

guiEXでpsy=1 0:0ってどう指定すればいいんですか？

GUIスレ逝け

x264をFPGA使って早くエンコすることって出来ないの？

それが出来てもせいぜい数十秒程度の差じゃない？
avx2に対応させても思ったほど加速しなかった例もあるし

SSE2の効果が絶大だったからそれ以降のやつが余り目立たないんだよな

なるほど、昔XVDっていうビデオ圧縮形式があって、そのハードウェアのリアルタイムエンコード基盤にXilinxのFPGAが
載ってたからFPGAだったら早いのかと思ったけどそうでもないんですね

>>56
純粋なハードウエア・ロジックとして Intel とその他では速度に圧倒的な差がある。
特に FPGA なんてものは遅い部類。

x264の実行時間の半分はCで書かれた部分だと言う話だし、SIMDだけが速くなってもどうにもならん

>>58
Dark Shikariが昔、"About 60-70% of x264's runtime is spent in integer SIMD functions."と書いてたぞ
http://doom10.org/index.php?PHPSESSID=o4uapcc3l1em0q3ok52pn95o81&topic=514.msg3863#msg3863

>>59
それは多分Nehalemの話で、Sandy Bridgeだと47.5%が非SIMDだと言っているね

http://forum.doom9.org/showpost.php?p=1612060&postcount=1819

Haswellが実際どうだったのかと、KaveriのHSAがx264にどう有効なのかは気になる

http://images.anandtech.com/doci/7677/04%20-%20Heterogeneous%20Compute%20Software.jpg
http://www.anandtech.com/show/7677/amd-kaveri-review-a8-7600-a10-7850k/2

拡張命令とエンコ速度の関係
自作PC板より転載
http://anago.2ch.net/test/read.cgi/jisaku/1352352619/851

【CPU】 i7 4770 定格
---------------
【x264】 r2377 x64@糠床

MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
【.Veryfast.】 61.90 fps

MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
【.Veryfast.】 61.64 fps

MMX2 SSE2Fast SSSE3 SSE4.2 AVX
【.Veryfast.】 60.22 fps

MMX2 SSE2Fast SSSE3 SSE4.2
【.Veryfast.】 59.26 fps

MMX2 SSE2Fast SSSE3
【.Veryfast.】 58.93 fps

MMX2 SSE2Fast
【.Veryfast.】 55.82 fps

MMX2
【.Veryfast.】 34.66 fps

none!
【.Veryfast.】 10.50 fps

二十四時間以上エンコードしてたのに、途中でPC異常終了してゴミファイルが出来上がってﾜﾛﾀw

いえ〜い（斧乃木ちゃん風）

>>61
VeryFastってIフレームのみだから、PフレームBフレームを演算するのに必要な
負荷の高い演算は行われていない

なんでわざわざVeryFastを選んだんだ
せっかくテストしてるのにもったいない

ベンチ眺めるしか能の無い自作板の連中だろ
新しいオモチャ手に入れてみせびらかしたらそれで満足というスネ夫脳だし
全部他の誰かにお膳立てして貰わないと何も出来ないんだから
エンコの設定とか言ってもそんな難しいこと理解できる訳がない

プログレッシブ化と言い、画質やヌルヌルと言いつつ
全フレームに一律同じ処理しているヤツの頭が理解できん。

そういったやつの行動を少し考えてみたが
結果

馬鹿のやることを論理付けして考えた俺が馬鹿だった。

>>65　Doom9からネタをしいれたりソースをビルドしたり
多少の専門知識を吸収しながらオプション弄ってるだけじゃ
趣味でやってる限りどっちも生産性なんてない者同士だろ
結局、お膳立てして貰わないと駄目じゃん

低負荷なエンコのスコアなんてなんの意味もないから。
高fps値が出たからと言ってそんなの重いフィルタを挟めばガクンと落ちるんだしｗ

春近し　心と2chの　荒れ模様

ﾎﾞｯｼｭｰﾄ

>>64-65
http://anago.2ch.net/test/read.cgi/jisaku/1352352619/471

【CPU】 i7 4770 定格
【MEM】 DDR3-1600 4GBx2
【M/B】 ASRock H87M Pro4
【SSD】 RealSSD C400
【GPU】 オンボ
【OS】 Win7 x64

---------------
【x264】 r2334 x64


AVX2有効
【Veryfast】 64.82 fps
【. Medium】 17.46 fps
【　 　Slow】 7.97 fps
【.　Slower】 3.95 fps

AVX2無効　　　　　　　　・・・(AVX2有効との差)
【Veryfast】 62.57 fps　　・・・(3.6％)
【. Medium】 16.71 fps　　・・・(4.5％)
【　 　Slow】 7.72 fps　　　・・・(3.2％)
【.　Slower】 3.84 fps　　　・・・(2.9％)

AVX2がx264はさして効かないって事実を明示されてブチ切れてるだけのアホちんだったってことだな

>>64
で負荷が高くなると拡張命令の効き方の傾向が変わるとでもいいたいのかな？

春って言うか転載議論の下見に嫌儲民が来てるんじゃ無いかってレベルだわな

このスレに自分で開発できるレベルのやつなんていないんだから仕方ない

このスレはCでOS開発ぐらい出来るレベルの奴ばかりだよ

簡単なマイコンの設計くらいできる程度の知識は持ち合わせていることが
このスレに書き込んでいい最低ラインだな

だが、↑の中にJEEBが居る可能性も有るんだよな・・・。

ここに自慰部なんていねぇだろｗ

>>73
すぐそういう皮肉に持って行こうとするのが頭悪いわ。

どの程度拡張命令が効いてるかなんて知らんよ。
知らないからこそ、VeryFastという使用頻度の低いプリセットでテストしてるのが惜しいと思うの。

で、実際にAVX2の有無でやってくれた人が>>71にいるけど、
MediumやSlow以上になると、x264ではAVX2の有無は問題にならない
ということが良くわかった

とりあえず煽りたいだけの新参が居るのはわかった

>>80
なにが良くわかったのか知らんけど
出てる数字だけ見れば誤差の範囲に見えるが実際のエンコ時間で考えると
重い設定に成るほど逆にばかにならんぞ

>>81
> 出てる数字だけ見れば
> 実際のエンコ時間で考えると

61 のだろうと思うが、数値は実際のエンコードのものじゃないのか ?

JEEBより日本が不自由なのが混ざってるな

春休みよの

SSE2の有無ほど劇的な差じゃないとしても差があることは間違いないんだしあとは
各人ごとの価値観でアリかなしか判断すればいいだけ

OpenCLのベンチﾏﾀﾞｰ？

Haswellはx264に関してはAVX2抜きでも対IvyBridge比で15％くらい速くなってるんだよな
他のアプリではデコード速度がボトルネックなって誤差レベルの効果しかなかった
実行パイプライン拡張がx264では効いてるのかも
Haswellの実行パイプライン拡張が生きるのはOPsキャッシュ(旧トレースキャッシュ)にヒットしまくるような状況だけだから

>>83
おまえだろw

>>88
そう来るとは思ってたけど修正レスでスレ汚すのもなんだと思ったんだが結局ﾂﾗﾚｸﾏｰ
がを挿入するつもりがミスタイプして語が消えてた的な
流れが全く読めてないのと違って日本人なら理解出来る範疇だろ

他人の日本語にケチつけてるレスで自分が日本語ミスってた時のバツの悪さは異常

で、読解力の怪しい典型的なアスペに対してやらかすと、そもそも空気も読めないから十中八九>>88の様に突っ込んでくる罠。
つか、春とか以前に前スレの10bitがどうのって辺りから、ﾀﾞｳｿ民だか嫌儲民臭いのが常駐しちゃってるし、まあなんだ…。

くだらねぇ

せやな、地震で眼が覚める事に比べれば何て事は無い

やめてください、世の中には地震で眠りにつく人もいるんですよ！

更新がきているね

猫さん、頑張って

腐った隠語と渇き切った空気を読んでも同所もない仲間の集まりだろココわw

多少なりともAVX2の効果があるってことはHaswellとC2を待ったのは正解だった

ここに常駐してるのは人間の屑ばかりだ

Pen4 から Sandy にシステムを変更した俺としては
AVX→AVX2 程度の向上はシステムを変更する理由にならない。

それでいいんじゃね
判断は各人ごとだしそれを他人にも強要したりしないならば文句言われる筋合いもない

intel信者は叩かれ弱い

>>99
おまえがその筆頭

前スレのvideolanのバイナリが動かなくなるって現象、rev2389以降、スレッドの設定を変更したのが原因みたいだね。
Doom9で取り上げられてた。

すみません、x264exでmp4に圧縮する際に、フレームレートが29.97となっているんですが
アニメや映画の場合２４fps（23.976fps）が正しいんでしょうか、
となると本来のフレームレートに直すには
aviutlの設定のフレームレート30fps>24fpsにしてインターレースを自動24fpsにすればいいんですか？
実際にエンコードしてみるとフレーム数が減っている？ので２４ｆｐｓされていると捉えているんですが

スレチだったらすいません

>>105
AviUtlならこっちがいいかと
h t t p://toro.2ch.net/test/read.cgi/avi/1389430765
あとアニメ＝24pとは限りません

全編30fpsのとか
OPやEDだけ30fpsで本編が24fpsとか
本編も24・30fps混成のやつもあるしな

>>106
スレチでしたかすみません。

>>107
ということはそれらを判断しエンコードしなければですか、
む、難しいですね（＾−＾；

インタレ解除しないという選択肢もある

>>109
フレームレートだけ変えてインタレ解除しなくてもいいものなんですか？

調べもしないなら死ね

スレ違いだし動画に対する基本的な知識が足りてない
初心者スレにいくといい

すみませんエンコードというものに触れて
間もないもので知識不足は質問するなってことですね

チンポマン

質問するなとは誰も言ってないと思う
ここ以外で聞くべきだと言ってる
ただ、この手の問題はいろんな人が取り組んでるので
ネット上に情報がたくさんある
それを調べてから、どうしても分からないというのなら
質問する、とした方が良いと思う

> 知識不足は質問するなってことですね
まぁ、常識人ならこういう発言はしないわな
相手にしないに限るよ

>>113
バカなのにプライドは一人前
他人はおかあさんのように自分中心に動いてくれる
と思ってるような甘ったれ

>>117
自分の自己紹介は他でやれw

>>113
ここはね　映像系のプログラマーの心得がないとダメなんだよw
あと、Doom9から得た知識の発表会をやるには歓迎されると思うけどw

調べても分からない事を質問スレでするのはいいけど
調べればすぐに分かる事を聞くのはマナーとしてどうかって事だよな

スレが過疎っているときや更新が２・３日止まっている時は
保守も兼ねてビギナーのくだらない質問とかしてもいいんじゃね？って思うけどな

どうせ返答を返す側もニワカだったり､よくわかってなかったりするからな

最近お前は何に繋いで2ch見てるんだってのも増えてるからな。
ネットをコミュニケーションツールの接続方法としか思って無い感じで。
そしてお前はどういう経路でここに辿り着いたんだ？って疑問だけが増えて行く。

とりあえず初めてのスレにたどり着いたならまずはテンプレに目を通す癖は付けておくといいと思う
ここに限らずどこのスレでもな

ここのテンプレなんて一部の住人が適当に作っているんだから気にすることはないよ
神経質なプログラマーが体裁をいいだしたら必ず上のような返答しかできないからw

そうそう。テンプレなんて
コーディング規約でいう所のタブ文字を
8文字か4文字か2文字かどれに合わせるの？
っていうぐらい意味のないものだからな

オープン系プログラマーがコーディング規約とはw 守るのかよw

x264はcosmeticsと題された更新は多いから神経質にやっている方

嫌ならPYTHONで書け

最近のアニメはBD前提でほぼ24pに集束した感じなので助かるな

数年前は30/24鬼混合とかあったもんな（遠い目

俺avsとかほぼ捨てずにとっといてあるけど昔のavs見ると
何十分割とかしてあって良くまあこんな事してたなあと
自分にびっくりするわ(´・ω・`)

画面の左右でfpsが違う鬼混合といえばプリ（ｒｙ
30fpsといえば一部のショート系アニメやドリランドなど

>>131
> 画面の左右でfpsが違う

こんなことが可能なの！？

背景とキャラのフレームレートや周期が違うとかよくあったな

それ、もはや作画崩壊レベルだろ

左右で作画監督が違う

クロスフェードでいつも周期がズレるやつとかなあサイコガン野郎め

クロスフェードで周期変更とかよくあったねぇ

そして未だ生き残っているスクロールテロップテロ…
次世代TVはVFR対応にしてほしいもんだ

それは編集がカオスになる予感。。
B-CASやなんかより大きな障壁になりそう

rffでさえ面倒な時が有るのにvfrはちょっと
まあ放送の時点で画質とサイズのバランスがエンコの必要の無い状態でならありっちゃありだが

大正義120fps

VFRというか番組毎にフレーム数変わってもいいと思うんだよね
スポーツは60pなり60iなりで、一般実写は30pで、映画は24pで
みたいに

そうすりゃ送受お互いに24<->30変換みたいな無駄なことしなくて済むし
「放送局側の機材が60i用なんだよ！」ってことは理解してるので
次世代放送規格ではそこら柔軟に対応できるようになってほしいわ

まぁ4Kからはインターレースはなしのようだから、ちょっとはマシに・・・・
2-3変換は残るかorz

いまさらXPから7にしてみたbatの編集しようとお気に入りの
タブで複数開けるエディターにD&Dしてみた、何故か開けない(？ω？)
なんでこんな糞仕様にしたし

インターレースは4kでも無くならないが

>>143
お前の脳が低性能なんだろ
Win7発売されてから何年経ってるんだよ

必要機能だけ適当に実装した自作エディタかもしれない

どうせProgram filesにインスコしてあたふたしてるケースだろ
WinXP老害の典型パターンだ

フォルダのことをディレクトリと言ってしまう老害の典型パターンはよそでやれ

Unix系のOS使ってる人は今でも普通にディレクトリって言っちゃうかもしれない
ここでも自ビルドとかしてる人はディレクトリって使ってそう

フォルダってのは「Folder」のアイコンが表示されるようなGUIでしかつかわなくね?

未だにWin8.1でもコマンドウィンドウでは「dir」コマンドが現役で使えるからねぇ

フォルダw

ー

ビルダーｗｗｗ

モルダー！

>>148-155
疲れてるのよ・・

もうエンコ疲れたお、HDDにそのまま溜め込めば苦労しなくて済むお

>>157
そんな貴男には Handbrake おすすめ。
CLI 版つかってバッチファイル書いてぼんぼんなげとけば良いしｗ

最近処理が追いつかないからx264使うのはお気に入りの数個だけやな
残りはQSVEncCでバッチ処理だわ
セロリンでも使えるようになったから録画マシンだけで処理が完結して便利やし、
実際使ってみると画質も言うほど悪くないし

> 実際使ってみると画質も言うほど悪くないし
個人の主観
いわゆる "お客様個人の感想です" っていうやつだ

容量制限が無いならx264の数倍ビットレートを盛っておけばおｋ

そして元ソース以上の容量に膨れ上がる、と

とりあえず、コスプレで扇子ひらひらさせなければ何でもいい。
挙句にキメポーズするなんて三流大学生の男子は氏ねば良いと思う。。。

誤爆か？恥ずかしいレスだなおいｗ

>>160
あれでも良いって人向けですからね
私は保存用でなくとも使い所がないと
思いますよー

久しぶりにDVDソースで作成したら設定忘れすぎて焦る
720x480だとHigh L3.1 --vbv-maxrate --vbv-bufsizeは17500が上限だったよね？
20000か25000だった記憶があったんだけど
1280x720 mainのLV4と記憶が曖昧に

High4.1でエンコさせstrlingでHigh3.1になるように書き換えればPSPやスマホでもみれる

>>166
Bフレとかrefの枚数にもよる。両方とも3を指定するとLevel3.0の12500が上限になる。
1280x720はLevel3.1でいけたりもする。x264は規格外だとwarning出すからいろいろやってみたら？（ないしググるか

>>168
レスthx！BフレRef3にしてHigh L3.1にしてたら17500で出力されてた
特に問題なさそうだからこれで妥協する

でも久しぶりにDVDソースでエンコすると画質がノイジーぽく見えてダメだなw

そう思ってついぼかし過ぎる悪い癖がある

>>170
そのままが一番良いと割りきるんだ
色とかも好み言い出したらおかしくなってくるし、
当然ぼかしとかシャープもね

最近再生側でぼかす用にしてる>DVDソース
madVRが最近頑張ってる

やっぱデコーダーも大事かあ。
DVDはブロックノイズ出てるとdebandかけてエンコしたくなる。

同じファイルでも再生プレーヤー変えて再生すると色合いも変わるしな
好みの問題としか言えない

貧乳好きか巨乳好きかと比べたら些細な問題だな

おわん型が好きなのはどっち派になるんでしょうか？

微乳派

童貞丸出しやな

大橋巨泉派

なんてったってあんたうっしっしっしっし

x246giuEx

VideoLAN の r2273 では問題なく使えていたが
r2409 ではパラメータでエラーが表示される。

どうすれば良いの ?

ttp://pop.4-bit.jp/

ここのを使う

自分でビルドする

自ビルドは一度環境を整えてしまうとあとはいつでも最新を即ゲットで便利
しかし一度でも俺がビルドしたのって○○のバイナリより遅くね？と思ってしまったら
終わりなき泥沼にはまる・・・かもしれない

ハマる（ｷｯﾊﾟﾘ
そして何日も格闘した挙句、もとのビルド乞食に戻る

冴えない禿親父は必死にビルド oh oh
行けない後家娘は今晩もディルド yeah yeah

つかビルド環境のVHDなりvmdkをみんなで持ち寄るってのはどうだろう
もしくは、クラウドのユーザー提供イメージで置いておけばいいんじゃね？

常時使うわけじゃあるまいし、Amazon/Azure/Googleみたいな
シャットダウンしたら無料のクラウドで即ビルドできる環境用意しておけばいいんじゃね

ほぅ。で、それをどこにアップするつもり？

俺のCPUに最適化したバイナリを吐くビルド環境にしよう
とかいう奴が必ず現れてgdgdになる未来が見える
逆に言うとそこまでやらないなら好意で公開されている各種バイナリの方がたいてい優秀

自分でビルドしたら分かるけど、人間の手で最適化されまくったx264の場合だと、
-mtune=genericと-march=nativeで有意な差は出ない。

MXが超ノイジーで圧縮効きにくくなってるなー

とことんボカしてpsyとaq切ってやる

すみません
10bitってのはプレーヤーも対応する必要があるんですね
対応するプレーヤーって何ですか？
そもそも10bitって8bitと違ってどう違うのでしょうか？

>>193 ないんじゃね？ プレーヤーって再生ソフトのことだろ？
心配せんでも10bitソースを8bitで出力するWindowsの動画再生ソフトなんかないよ

まぁ、ハードの再生機だとあるかもしれんが・・・
（大抵はハードが10bit対応じゃないから関係なさそう）

MXもそうだけど今期圧縮しないのは河合荘
あれは辛い

あの画作りじゃ仕方がない

XAVC rev2.1

>>195
わりかし低crfで圧縮してもあのどぎつい色調のお陰で粗が目立たなかったりもする

Windows の設定が 24bit カラーでもパネルが 6bit でディザ表示では何やってもダメ

>>199 そんな環境の奴が質問するわけ無いだろ・・・

イミフ

http://ringojyuku.blogspot.com/2014/04/iphone-5s-2k-ultrakam.html
iPhone 5sで 2K の映像を撮影できる神アプリ「Ultrakam」を試してみた

384 Mbpsという情報量に唖然

MXのジョジョが全然縮まらないw

おとなしくBS11放送まで待てばいいやん
ブロックノイズだらけのMXをエンコする意味ないで

ＭＸは主に視聴用､見たら消せ。

MXは音声抜きで使うしかないな

最近MXと他局の合成エンコして気づいたが、MXはCM直後に他局で存在するフレームが4枚前後無いな

テレ玉とMXでMUXさせたけどフレーム数合わせるのでテレ玉を前後1フレームづつ切った

もともと画質とかあまり拘ってなかったが、もうどうしようもないなMX
ビットレートを更に下げて、見れればそれで良いやで保存してる

tsだと容量が縮んでるのにエンコすると膨らむってジレンマ

>>210
さすがにTS以上膨れることはないだろw
圧縮しないのはノイズ拾うから仕方ない

>>211

どうしても縮ませたいならx265で時間かけてやろうや

>>211
なぜ「再エンコするとTS以上膨れることはない」と思うのかが不思議だ。
放送で使っているエンコードの条件と
ユーザーが再エンコする条件は全く違うから膨れることも十分に考えられるだろうに。。。

だがスカパープレミアム)のエンコはcrfやqpやビットレを固定するぐらいしか
縮ませる手段は無いんだけどな

エンコの際に発生したノイズなども再エンコで再現しようとするからサイズが増える
第一 元ソース以上のpsnr値は得られないんだからそういう場合はCMカットやインタレ解除、汎用性の増加などの目的が無い場合はやらない方がいい

ウォーターマークを取り除きたいっていう理由で再エンコするのなら仕方なしだろうけどな

MXマルチチャンネル編成に正義の鉄槌を！かつてインタレ帝国の野望に
対抗したDTV板有志諸君ならできるはずだ(´・ω・`)

品っぱんに野球見てる俺は、マルチチャンネル積極利用に大感謝なわけだけど。
試合終了までセカンドチャンネルで完全中継してくれてるからね

MXの劣化で騒いでるのってアニオタだけだろ

嘗て平穏だった状況がみんな闇に閉ざされたからな
俺もBSエンコが増えて、やや苦しい状況だ

BSで放送する番組なら地上波でエンコなんかもともとしないし

でもアナログ放送の頃に比べたらこれでも超高画質のソースと言えるんだろうけどな
どうしても縮ませたいならあの頃みたいに強めにフィルタかけて潰してしまえばいい

帯域が足りてないだろって話

>>223
言えないよ。
アナログはノイジーで画像が甘いだけ

アナログで決定的だったのは、ゴーストと音割れ。
それと郵便配達の赤カブが撒き散らすスパーク・ノイズ。

それを言うなら新聞配達の〜だろ

赤カブ、赤メイトなどは郵便特別仕様

しかしなんで赤の発色の悪さってmpegやH264で未だに改善されないんだろう
mpegができてから二十年以上経つのに

>>229
色空間の仕様があるからしゃーない
H.264ならRGBに(一応)対応してるじゃん

赤にビットレート盛ればいいって単純な問題でもないの？

色情報が端折られてるから

端折られたとこを補完するプレイヤーとしないプレイヤーがあるからね……
後者の代表例がFlash Player

>>229
色情報のうち赤と青は事実上滲ませたと同様な始末な仕様なので無理。
プロ用では YUV でも RGB でも 4：4：4 が存在するってことで察するがよろしい。

見る方向を変えれば
ある程度、成立する画像が得られる程度で提供はするが
違法コピーはばらまくお前らに、何で元データを提供しなきゃねんねぇんだよ
ってこと。

>>234
>何で元データを提供しなきゃねんねぇんだよ
そもそも元データの式空間もYUVである可能性が高いわけだが
(地デジもBDもRGBじゃないし)

また、わけわかんねぇやつが出現したな

YUVは人間の目の特性に合わせたものだから一見して違いは分からんぞ
色解像度は赤方向で変わるけどね

RGBは1ドットあたり3色の成分がフルで入っているので一般的なRGB8bitは1ドットあたり8×3=24bitのデータ量をもつ
普通の映像ソース(yuv4:2:0)はそれを輝度Yと色差(色だと考えて良い)U,Vの3成分に分けそれを4ドットの塊あたりに輝度を表す成分を4つ、色差を表す成分を1つづつ割り振るようになっている
輝度だけで再生すればそれは白黒映画のようなもので色差はそれに被さる色
RGB→yuv4:2:0にする事でデータ量的には1ドットあたり(8×4+8+8)/4=12bitと同解像度でもかなりデータ量が圧縮出来る
形式的に色差は輝度に対して縦横半分の解像度で上にかぶさっているようなものなので補完しないとジャギみたいなものが出る
RGBで人が敏感に感じる順は緑>赤>青だが緑は輝度に近い為劣化を感じ辛く赤は感じやすい
何故こんな圧縮の仕方をするのかというと輝度は劣化が気になり色差は補完してれば劣化が気になり辛いから

長文で書かなくてもみんな知ってるから

理論はいいんだお。
エンコ時にどうやって実現させるか書いて池

エンコ時に色情報を極力残したければ4:4:4かRGBでエンコードするしかないんじゃないの？
もっとも、放送自体が4:2:0で送ってきてるわけだから、エンコード前にPanasonicのレコーダーみたいに色情報を高精度に復元した上で、復元された 4:4:4データ、もしくはRGBデータを用いてエンコードするとかじゃないと意味がないように思うけど。
PCのソフトでそこまで高精度に色情報の復元を行えるソフトがあるかどうかはしらないが、RADEONのハードウェア再生支援機能を使って再生した画像をデスクトップキャプチャーすれば、そこそこいい状態にはなるかもしれん。
ただしコマ落ちを考えるとかなりPCのスペックは余裕みといた方がいいかと。
4:4:4といえば、HEVCの4:4:4規格はもう定まったんだっけ？

RADEONの再生支援は強力だよね
超解像もX-Reality PROより自然だし最強過ぎるわ

>>241
mpc-hcの「yv12 chorome upsampleng」で再生時補完すればいい

>>243
あれって効果あるんだっけ？

赤の劣化ってレンダラにmadVR使うだけでかなり良くなるよ

人間の特性考えて 色差より輝度 暗色より明色 に重きを置いてんだから
それと同様に敏感な赤系統に重み付けするような事しないのかと常々思う

規格策定した人が悪い

重み付けなら規格というよりx264の中の人では
あとそれぐらいプレイヤーが補完処理するのが普通だろうしこれから先yuv4:2:0なh264で同問題が解決するエンコーダが出るとは思えない

ネガポジエンコで再生時もネガポジですか？
マトモなデコーダ入れるだけで済みそうだけどなｗ

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

画質の基準は人それぞれですし……

生tsが一番高画質と思ってるのがいるのか(ｷﾘｯ

リアルタイム補正が一番だお(´・ω・`)

今の地上波のビットレート17MbpsでもH264放送でソースが綺麗だったら
リアルタイムエンコードでも相当綺麗だろうな

生TSと、x264で生TSを再エンコしたものと比較するなら
画質が良いのは誰が見ても生TSの方だけどな。

リアルタイムではキチンとip変換されてない事がある

インタレ解除はRADEONの最新版(UVD4搭載モデル)で、さらに強化されたが

もうこのネタも通じなくなってるのか

おお…　生ﾁﾝｺが一番気持ちいいと思ってるのがいるのか

>>258
いつ頃どんな流れからの発言だったとかは忘れたわ、どんなだったっけ？

2-3スレもしくは4-5スレ、あるいは6-7スレ前に確か…なんだっけ

30スレにあった

757 ：名無しさん＠編集中 ：2011/03/27(日) 14:41:57.21 ID:Rb0sPheT
そこまで気になるなら、きっと画質の劣化にも敏感だろうから、
エンコしないでTS保存することを薦めるよ☆

758 ：名無しさん＠編集中 ：2011/03/27(日) 14:47:44.44 ID:TE3mO5sP
実際に5px引き伸ばしてみて自分がどう思うか試すのが一番早いぞ

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

759 ：名無しさん＠編集中 ：2011/03/27(日) 14:54:51.90 ID:Evstm5+0
tsのままだとくすんでるｗｗ
エンコして綺麗にｗｗｗｗ

760 ：名無しさん＠編集中 ：2011/03/27(日) 15:01:19.20 ID:DxgaAZEY
TSがくすんでるとか言うやつは安い液晶TVの見過ぎ

761 ：名無しさん＠編集中 ：2011/03/27(日) 15:05:39.58 ID:TE3mO5sP
おお…　生tsが一番高画質と思ってるのがいるのか

また懐かしいネタをｗ

crf20程度なら8bitエンコでも動画として普通に視聴する分には劣化なんざ気付かない。

AvsPで静止画プレビューした、MDegrain3でノイズ除去後の絵がソースと比較して甘くなってても
動画として見たら甘くなってるのに気付く目の良さを持った人なんてそうそういない。

要は程度問題。

>>264
画自体は22でも十分だが、パディングとかは20以下でも発生する。
そういうのを諦めきれない人が10bit信者になる。

BDなんかだと元々のってるグレインが8bitだとどれだけcrf盛っても潰れちゃうからなぁ

>>264
同意
22ぐらいにすると余裕だけどあんまり恩恵を感じない

>>266
デフォだと残さないような設定だから仕方ない
ま、残すような設定にすると思ったよりも縮まないけどな

実写ソースはcrf20､アニメソースはcrf16でいけ。

実写crf20はほとんど縮まなさそう

実写はソースの1/5ぐらいの圧縮で十分だろう。
細部崩壊を無視してまで高圧縮にこだわるのも何か違う気がするしな。

この前実写を間違えてcrf18にしちまった
あんまり容量増えなかったから良かったものの

ハゲにしてやる!!

　　　　ﾌﾞﾁ ﾌﾞﾁｯ
　　　　　 _,,_　彡
ﾌﾞﾁｨ　　 ( ﾟдﾟ)∩
ﾊﾞﾘﾊﾞﾘ　Ｃﾐ　彡⌒ ミ
　　　　 /　 (　 ♯)
　　　　(ノ￣と､　 |
　　　　　　　しーＪ
　　　　 ぎゃー

最近いたるところでハゲがネタにされてるけどヤメロ

>>270
2000年代以降の、グレインの少ない実写映画なら、
crf20でオプションそんな盛らなくても8000kbpsぐらいには縮む。
今のNHK大河なんかだと、fft3dgpuをごく軽くかけてバンディング低減フィルター入れて
--crf 21 --me umh --subme 7
とかで5500〜7000kbpsぐらいか。

昔の実写映画だと、フィルターがっつりかけても12000kbpsとか、嘗めてんのかと思うようなことになるが。

>>274
　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
　|頭髪が薄くなっています　　　　　　　　　　　　　　　　　　　　　[×]|
　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　| 彡 ⌒ ミ　頭髪が薄くなっています。　　　　　　　 　 　 　 　 　 　 |
　| (´･ω･`)　ハゲ・ズラ板に移動しますか？　　　　　　　　　 　 　 ｜
　|　───　http://uni.2ch.net/hage/　　　　　　　　　　　　　　 　 ｜
　|　　＿＿＿＿＿＿ 　 ＿＿＿＿＿＿ 　＿＿＿＿＿＿ 　 　 　 　 |
　|　 ｜　は　げ（H）｜｜　ハ　ゲ（H） ｜｜　HAGE（H）　| 　 　 　 　|
　|　　￣￣￣￣￣￣ 　 ￣￣￣￣￣￣ 　￣￣￣￣￣￣ 　 　 　 　 |
　 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

縮まなきゃ意味がない＆DVDより良ければいいが信条なんで
45分ソースは1024x720にリサイズしてcrf26で300MB前後、crf24.6で400MBぐらいに収まる(psy-rdは0.5)

psy-rd実写は1だけどアニメはほんの少しかけるだけでいいな
寧ろここでは何もかけない人が多そうだ

psy-rdは0.5だな

アニメはno-psy良いね

0だとデバンディングが全然かからない
最低0.3は欲しい

バンディングの意味をちゃんとわかっているのでしょうか

>>262
こんなに前なのね、つい最近な気がしてたわ

3年前のネタなんじゃ通じない人が増えてても仕方ないわな

ブルーレイの映画は別にいいんだけど
ブルーレイのAVは家庭向け市販ビデオカメラで撮ったHD映像をそのまま突っ込んでることがほとんど
レベル補正やら明度コントラスト彩度その他いろんな視覚補正を施し好きな肌色にして圧縮してますなあ

>>285
解かります。
相手が最悪逮捕覚悟でエロをやってるやつらなので多くは望めませんが
せめてホワイトバランスを自動のままで撮り続けるのだけは勘弁してほしいです。

>>262
時間の流れに驚愕したわ

>>285>>286は素人もののAV好きだって事だなｗｗ
そりゃ、スタジオモノのAVなら照明もあるしホワイトバランス取りやすいだろうけど
屋外で撮影してどっかのラブホやシティーホテルで撮影なら照明もないだろうし暗くてホワイトバランスの調整なんて出来ないだろｗｗｗ

エロはRMVBでいいんじゃね。よく縮むし古いながらもサラウンド対応でVBRだし

エロビデオの画質にこだわってエンコするのと
アニメの以下略、どっちがキモいだろうか(´・ω・`)

>>288
調整しろって事ではない、調整するなって事だよ。
一律であれば補正が簡単だが、場面々で色調を変えられたり…
一番やっかいなのがWB自動。
ズームした時や引いた時で平均輝度が変わるだけでなく色調まで変わる。

>>290
アニメという意見がグローバルスタンダード(俺調べ)

>>291
じゃあ、お前がカメラマンになれｗｗ

>>293
マジな話、足代と弁当代払ってくれて身元明かさずとも良いって条件ならカメラマンしてやるよ。
テスト段階で不満があれば断ってくれて良い。
そっちからあしのつかない連絡手段を提示してくれ。

>>290
キモさで言うなら、エロやアニメなんぞよりアイドルヲタの方が酷いんだぜ。

アイドルオタクの人たちはキモイというか無知で哀れという感じだな
バックにいる詐欺師やその取り巻きの黒い連中に搾取されている
人質商法だと知っているにもかかわらず抜け出せないというのは
何かの依存症と同じような状態でリハビリが必要な可哀想な人たち
まさにカルト信者
一方でアニメオタクはいつまでも成熟した人間になりきれていないその幼稚性と
特有の神経質さにその妄執的な攻撃性とのギャップが得体の知れない気持ち悪さを増長させている

同族嫌悪

同族嫌悪というけどアルゴリズムに価値を見出す人と特定のモノや人物に価値を見出す人は流石に違うと思うんだ

目糞鼻糞を笑う

チューリング「どっちも落ち着け」

相変わらずスレタイ見なかったことにして雑談したいという欲望を抑えきれない奴が多いんだな

ネタ切れだからね。

zonesでdeadzoneって指定できますか？

mp4を連結するソフトをご存知ないですか？
前にどこかで落としたんですけど捨ててしまって
GUIにドロップして連結点にchapterを自動で付けてくれる mp4 join とかの名前だったような

連結ならL-SMASH Works使ってAviUtlでもできるでしょう
連結部にチャプター打ち込みたいたいなら連結部の秒数をtxtに書いてmp4chap.exeでもyambでもいいから打ち込めばいい

全部Iフレームだとシークに時間かかるのなんで？

HDDの転送速度を通常の3倍に上げるんだ！

シャア専用ザクの出力はノーマルの1.2倍しかないんだぜ。

その代わり装甲が薄い

それだけじゃ、3倍にはならないけどね。

シャアにとっては脚は飾りではなかった…

モビルスーツを自在に操るのは並大抵じゃないんだよ
シャアの才能を認めろよ

大抵のパイロットは、弾が来ても避ける事すらできずにやられていくんだよ
サイコミュもないザクであれだけの俊敏精密な動作ができるシャアの操縦センスは並外れている

マニュアルを斜め読みしただけでガンダムを動かした安室の方がすごいけどな。

動かすだけなら素人のセイラさんでもできたし汎用兵器としてのガンダムの方が凄いのかも・・・
ってスレチどころか何板だよここｗ

シャア板開いてるのかと思って確認してしまった

久しぶりにDVDソースをエンコしたらアス比を32:27でエンコしてたwww
左右16クロップの40:33するのをすっかり忘れてた
DVDエンコするのって地デジに変わってからやってなかったから5年以上ぶりか

ここはお前の日記帳です
秘密にしてる事とかバンバン書いちゃえです

たまに本当にメモ帳代わりに使ってる奴が居る
栞とか挟む奴もいるし

俺は左右黒ぶち入れてからそれに合わせたSAR値入れてるけどな
そうしないとPSPでスクイーズ再生した時左右が切れる

地デジの1時間実写ドラマ（CMカットすると45分）を1280ｘ720にリサイズしてエンコするとしたらおまえらcrfいくつにする？
おいちゃんサイズ重視なのcrf=26でいこうと思うのだが

ドラマではないけど、ナショジオHDのメーデー(CMカットで45〜47分)を1280x720にリサイズしてcrf=24でやってる

俺はなぞの転校生をcrf20でやってる
この前間違えて18にしちまったが

18〜24の間で考える

極端に大きくなったり小さくなったりしないように
まず5分くらいで終わる高速設定で仮エンコしてみて
そのサイズの大きさによっておおざっぱに値を決めてる。

更新してんじゃん

1280×720ならcrf19にするかな

俺は1440ｘ810で揃えてるわ。

変態解像度…

1440x1080ソースを1440x810にするだけでなんでリサイズ時の負荷もだいぶ違ってくる。

8の倍数じゃないじゃん

リサイズせずにsar値埋め込めば良い

変態解像度にリサイズするぐらいならsar埋め込めってのはもっともだ

キルラキルとかはまだ960x560だ
普通は1280x720でいいだろう

デフォ設定に1280x720入れてHDソースはリサイズsar0:0
CSのSDソースは780x480の解像度維持でsar32:27でやってるわ

SDは左右に黒帯入ってる時は704x480にクロップしてSARは40:33
デジタル制作で720x480フルに映像入ってるような奴は
D1の720x486の上下がクロップされたものと見なして、720x480のままでSARは6:5
HDはほとんど720p

実写ドラマはしばらくエンコしてない
映画は24pだから問題ないし、ドラマやCM系も30pの奴ならいいんだが
60iのは萎える
まあやるとしたら720x1080に横だけリサイズしてインタレ維持かな……

SDソースは左右に黒縁を付け加えてSAR32：27な
ここら辺間違えやすい

最近のアニメソースは16:9のままエンコさせた方がいいと思うが
実写ソースの場合､HDは1056x792サイズに縮小エンコさせ
SD/DVDからのアプコンは992x744に拡大エンコさせている。

これをコンテナ側(mkv)で16:9表示になるようにMuxさせている。
これだけでもだいぶデータ量とエンコ時間を削れる。
ただし、プレイヤーが対応してなきゃ4:3表示のまんまになる欠点付きだがｗ
（MPCBEやWMPやVLCは対応してるから特に気にしていない）

x264やAVSってPS3アプコンみたいに高画質にできるわけじゃないからなぁ

上で地デジの1時間実写ドラマエンコしてる奴らはインターレースの有無（保持/解除）どうしてる？

解除してプログレ化すればサイズは縮むが29.970fpsになってしまってなめらかさが減るし
保持すればプログレ60fpsと同等のなめらかさになるがサイズが増える

aviutlのafs使ってる。60iテロには非対応だけど、かなりの精度でテレシネ解除してくれる。
60iならTdeint+nnedi3でちゃっちゃと済ませてる。

>>338
縦x720でよくね？と思ったのは私だけではないはず

総フレーム数が2倍になる60fps化の非効率具合は
エンコ速度的にも容量的にも問題外

デジイチで撮影した1080/60p動画を真面目にエンコしたら平均ビットレートが30Mbpsとかになってワロタ。

なぞの転校生の場合は60i→24pでいいよ

x264のインターレースはMBAFFだから
情報的にはフレーム総数2倍になったりしなくね？

720x480はHD制作問わずに左右8クロップしてファイル作ってるな

AT-Xは左右に4 cropだけどな

ワンランク上の画質ﾏﾀﾞ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

AT-X(e2)は標準画質の中ではそこそこのビットレだろ。
NECO(e2)や衛星劇場(e2)みたいな残念画質とは大違い

http://www.dotup.org/uploda/www.dotup.org5017305.png
AT-Xはノゲラだけはダントツで画質が良いよ

なぁ、なんでKBSとSunTVとMXを同時に視聴できるんだ？
MXは完全な関東ローカル局だろ。

俺は京都に連絡取り合ってる奴いるからなんも不思議には思わないな
SS用にtsぐらい放送直後ならもらえる、むしろMXのSSを送りつけてたぐらい

お前らそろそろスレタイ思いだせ

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

>>351
>SS用にtsぐらい放送直後ならもらえる

それ違法だからとりあえずACCSに通報しておこうか。

>>350
別地域の実家などに録画鯖置いてるやつもいる

くだらない通報受けたACCSも大変だね

早朝にインターフォンごしに私服の警官がぞろぞろあつまってくるんだね。

警察って暇なんだね

刑事訴訟でか？ 民事訴訟でか？
検察が裁判所に家宅捜索の令状申請して許可取るんすか？

TSの受け渡しもメールでなら問題ないんじゃなかったっけ？
動画共有ソフトとかサイトにアップロードは当然アウトだけど

tsからH264+AACへのエンコード手順だる杉ワラタ

不特定多数に公開しなければ問題ない

番組の権利者の許可なくWebを通じて誰かに配布している時点でアウトだろ。
Webを通さずブルーレイやUSBメモリにでも記録させて手渡しするのなら。

ts貰いましたって糞みたいな2chの落書きを元に
逮捕頑張ってくださいね応援してます

>>361
慣れると楽だぞ
CMカットぐらいだし

先生!! 100円盗まれたとしても犯罪ですけど、検察が事件として
扱ってくれるんすか？

著作権法違反絡みの話題性のある事件なら何の躊躇もなく扱うだろう。
まず権利者や警察が負ける事は無いからな。

ちょっと見てきたが
ttp://www.bunka.go.jp/chosakuken/24_houkaisei.html

問7-6　友人から送信されたメールに添付されていた違法複製の音楽や映像ファイルをダウンロードしたのですが，刑罰の対象になるのでしょうか。

（答）
　違法ではなく，刑罰の対象とはなりません。
　違法ダウンロードでいう「ダウンロード」は，著作権又は著作隣接権を侵害する「自動公衆送信」を受信して行うダウンロードが対象となります。著作権法上，
「自動公衆送信」とは，公衆送信（公衆によって直接受信されることを目的として送信を行うこと）のうち，公衆からの求めに応じ自動的に行うものをいい，友人が送信したメールはこれに該当しません。
（ただし，音楽や映像をメールに添付して送信する場合，送信者が，「家庭内その他これに準ずる限られた範囲内」を超えてメールを送ると，音楽や映像のメールへの添付は原則として違法となります。）



だからメール送信した方はアウトで　DLは問題ないって事か
とスレチすぎたな

>>367
おぉー、きっと金をかけて凄腕の弁護士を雇ってるんでしょうね

ネットに強い弁護士が居るんじゃない？

公安の犬はスレからでていけ

送る送らない以前に技術的保護手段のかかったものを複製するのはやばいから
こういうところで堂々と書くのだけはやめとけ

一部の人が調子に乗って法がどんどん厳しくなるのはご免だ

まさかこのスレの住民に違法な用途のためにx264を使っている人は居ないよな？
放送された番組をx264でエンコしてコメント付きのflashとかで再生させてドヤ顔するとかｗ

　　　　 , -'~￣￣￣~`ｰ､
.　　 　/　ID:W0xDQofH ヽ
　　　 |　 三 ＝　　oヾ､　・・
　　　l|.　 ,-―'､　>ー--　　l;
　　 ｄ| ---◎ |　| ◎---　b　
.　　　.| ¨∵　)(oo)( ・Uu。 |　　
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　:::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::
　　 :::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::
　　　　 :::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　　　　　∧＿∧
　　　　　　::::::::::::::::::::::::::::　　　　　　 （　::;;;;;;;;:）　　春だなぁ・・・
　　　　　　　　::::::::::::　　　　　　　 /⌒｀'''''''''''＾ヽ
　　　　　　　　　　　　　　　/⌒ヾ/　/　.,;;;;;;:／.:;|
-―'――ー'''‐'ー'''―‐'―''''＼,./　/ .::;;;;;;:/‐'| :;|'''ー'-''――'｀'
　,,　''''　　｀、　｀´'､､,　　　'''＿ｿ　/　｀:;;::::ﾉ,,, | :;|　'''　　､､,
　　　　,,,　　　''　　,,　　 ''''' ξ＿ノ丶ー'ｰ＜　,ゝ__＞　''''' 　,,,,
　,,　　　　　,,,,　　　　　'''　,　　　::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　　,,
　　　　　　　　　　　　,,,,,,,　　　　　:::::::::::::::::;;;;;;;;;;;;:::::::::　　　　　　''
,,　'''''''　　　　　　,,,,　　　　　　　,,　　　　:::::::::::::;;;;;;;;::::::

GWだよ

だれもx264ビルドしてない・・・

たろとこみさー

インターレース保持でエンコしたらすげー容量増えるな
解除してプログレ化した時の三倍になったわ

人間の目が糞なせいでインタレースという舐めた方式が広く使われたのだ

インターレースにしろ4:2:0にしろ、「人間の目には」という枕詞をつけたものの大半が、実は大いに弊害があったわけで、我々は騙されまくってきていたわけだな。

>>380
それは今のように恵まれた環境だから言える話

2kの4:4:4と4kの4:2:0は色差成分量同じでピクセル数は4倍になるのにデータ量は2倍で済むやん合理的やろ?
しかもx265やと2k→4kは3倍程度のビットレートで同程度の品質になると言われとるし

で、また4:2:0のくすんだ色に泣かされると

ディスプレイのドットピッチ狭くなるから気にならなくなるんやろ今後

視野角も一緒に狭くなるのは勘弁してください

そういう問題じゃないから

マルチ化してるのを一旦なくしてしまうからね

今のディスプレイに合わせると、プログレッシブのRGBが究極だろうけど、動画がこれに移行するのはいつの事だろう

まあ昔から言われてた人間の目にはこれで十分とかいうの
ただのごまかしだよね、もっと良い環境が普通になれば全然
十分じゃなかったっていう

当時なら充分やったやろ。目が肥えたんや
20年後には色度図飛び出しとるかもしれんで

まず人間の目には十分の範囲が
データ転送時は帯域
圧縮ならリアルタイムデコード
円盤なら記録媒体のキャパ
この辺の制限と融通しあっての人間の目には十分なんだよね
現状に合ってない規格を引きずっちゃってるのは確かだけど

何を今更ｗｗ

>目が肥えたんや
ほんとこれ

数年後は一体どれぐらい進化するんだろうな

たぶん、10年後→8bit(笑)、15年後→インターレースとかありえねー！、20年後→4:2:0w、30年後→色差(笑)

今→インターレースとかあり得ない
2年後→高解像度なら4:2:0のがええな
3年後→8bit()
5年後→高深度ならYUVのがええわ
10年後→有機EL最高や！
こんな感じがいい

ハリウッドブルーレイ
1920x1080/60p 4:4:4 8bit 100Mbpsで文句言わない

ホビットって映画48fps撮影なんだっけ。
24pだと半分だし60pだと余計なモン挟まるしどうすりゃいいんだ？

240fps

最小公倍数の120pでいいやん

だよなｗ

2-3プルダウンで中途半端にｶﾞｸｶﾞｸにならんかね？

バックドピクセルの範囲32bit(3*8=24bit)を(輝度12赤10青10か輝度12赤11青9)にしたらどうかな？
もしくは緑8青8赤8黄8の32bit、プリズム7色+色間の補間用6色計13を9bit変換(プリズム7色のみ10bit緑青赤黄色のみ11bit)計128bit
7680*4320の120fps
506.25MB/f≒59.326GB/sec
フロント3chサイド2.1chバック2.1chスーパーウーハー1chの96000Hz*360deg@(1/9deg)24bit
で96kHzはナイキスト周波数を考慮すると48kH
相当となり1波は360度の9倍(歪みの有度を持たせる)CDの場合44100サンプリング/sec(ナイキスト周波数を無視すれば122.5Hz@1度サンプリング)

日本語でおk
16bitカラーが緑のみ6bitで他が5bitという割振になってた事はあるけど8bit以上のカラーを見てくれがほんの少しよくなるぐらいの理由で均等でない割り当てにはせんやろ
ましてやYUVとRGBの信号を同時に送り出すとかあり得ない 何のためのYUVや、高深度にした方が良い

うるせー、さっさと飛び出す3Dホログラム実用化しろよ

電話ぐらいなら人物を3Dモデリング化すればすげー圧縮出来そうだな

おめーら実写AVエンコする時はcrf=いくつにしてる？

若干NRかけてmixaqで23

20でやってるわ

力入れ過ぎだろ…

アニメなら16とか言うくせに…

それだけアニメが単純な画で縮む代わりにノイズや破綻が目立ちやすいってだけの話だろう
ディテールが複雑な実写でcrf16とかしたら凄い容量になる
ソースのままでいいんじゃね？ ってレベル

輪郭線の無いCGアニメならcrf24でもそれなりに

普通は18〜24の間だと思う

アニメは20
実写は18だな

すまん実写は23の間違いだった

エンコするならはででを買え

いつだったか、お気に入りのエロDVDを、
QTGMC(Preset="Very Slow", edimode="eedi3+nnedi3")
というアホなセッティングでBob化して、一旦可逆AVI出力、
自作のアプコン超解像関数やらMDegrain2やらを駆使して720pにして
10bit出力してcrf18でエンコしたことあるわ。
4000kbpsちょいぐらいにはなったが、意味があるかとかは聞かないでくれ。

いいんだよ
全ては自己満足だから

>>407
22でやってる

音声はOpus 64kbpsでいいやと思うようになりました
コンテナがmkvに変わった僕です

実写ってアニメと違ってCRF上げてもそれほど画質悪くなったきしないな
アニメだと細部の破綻目立つけど

と思ってよく見たら背景が油絵に…

動きの多い実写はcrf値を小さくすると容量縮小するどころか元より増えるという有り様で
エンコする意味が全く無い
かといってcrf値を少し大きくするとブロックは出るわ肌は失敗塗装の磨耗したゴム皮の様に哀れで
艶やかな黒髪はもう何ヶ月も風呂に入っていないかの様なベッタリと汚れた気持ち悪い質感になって見るも無残
細部どころかほとんど全てが劣化しそのディテールは破壊される
一方で静止画+レベルの日本の低予算で動きの少ない単調なアニメは驚くほどよく縮む
x264利用者にアニメオタクが多いのではないかという話も納得の性質

実写20 アニメ20〜23　だな

>>424
crf=26, qcomp=55

むしろアニメは18で実写は20〜26あたりで探る

実写はcrf24で縮まない＆グレイン多い様ならqcomp下げてる

ジョジョとか弱虫ペダルとか、派手な色が多すぎ坂道動きすぎなのは
crf=25で適当エンコして済ませてるわもう
蟲師はどんなにcrf上げても縮みまくるけどな！

蟲師はECMとEMMとCMを省いて無劣化カットしても1.5GB程度で収まるしエンコなんてしないわ。
BS11みたいにあれこれ削っても3.7GBぐらい膨れてしまうならさっさとエンコするけどな。

トルネみたいに解像度半分に折りたたんでるやついないの？

　実写ものの見て消し用自動エンコは960x540 60pにしてる。

>>431
720x1080とかの変態解像度だっけか？

局によっては480x480とか544x480とかの解像度があったな

>>434
そういうのもあるんですね
使いたくはないですがｗ
基本、1280x720か
リサイズなしの1920x1080で
Q19か20です。

東映チャンネルがちょっと前まで480ｘ480だったな

猫もなー

ちゃんねるぬこ

720ｘ480なのにレタボとか視聴者を舐めてる
http://i.imgur.com/J2h3Z6t.jpg

猫だけに

>>439
上下にないだけマシじゃん
昔のfox movieかどっかは上下左右黒枠だったよ（映画だからワイド表示のためのやつな）

>>439
720x480なDVDソースでもよくあるだろ。

>>440
超額縁状態のアレか。
もはやマスター自体が超額縁しか残ってないとかいう悲惨なやつは救うのが難しい。
(意図的にやってる貧乏ビスタはもっと話にならんが)

大昔のテレビは寅さんとか４：３のブラウン管テレビで横方向に圧縮したスクイーズ状態で放送してたな

それオープニングだけ

えっ、そうだっけ
子供の頃だからよく覚えてない

テレビジョン（放送）受像機（これが一応正式名称w）で額縁を出さないのが基本だったから
オープニングやエンディングで文字があって両端を切り取れない場合にスクィーズ画面だった
シネマスコープサイズの映画の場合なんて結構悲惨だったよねw

アナログ放送でHDマスターをスクィーズで放送しちゃった事故もあったけど

事故？仕様だろ。これだから平成生まれは・・・

>>446
今は無きはねるのトびらでフジTVがやらかした事が有ったなｗ

>>446
TBSの "世界遺産" （ "The 世界遺産" の前番組）でも、オープニングからCMまで10分位スクイーズで放送しちゃったことがあった。
当時はクリアハイビジョン（死語）で基本の放送はレターボックスだったんだけど、コンバーターの切り替えを忘れていたらしい。
たまたま見てて、慌ててワイドテレビ（これも死語かな）をフルモードにしたら、やはり綺麗だったよ。
結局 "事故" 扱いで、後日コンバートしたものが再放送された。

>>447
仕様って・・・

触るな危険

勝手に動く機械 は無くて 人間が命令を出すから動く機械 しかないんだから
人間がミスをするのは仕様だよ

レタボ検出→ワイド切り替えは自動だったよね

>>449
ワイドクリアビジョンだなw

Xvid 1.3.3ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
https://www.xvid.com/

SD解像度な4:3な旧作アニメぐらいだなXvid+2passでもいいやって思えるのは

鯖マシントラブル中でありながらも
Lスマやx264を置いてくださるpop様に感謝

http://i.gzn.jp/img/2014/05/30/%20135-million-image-sensor/03.png

YouTubeのAVCoderってx264だっけ？

つべはシネパックのAVCトランスコーダだろ。

x264やろ

ｘ264ならつべの動画をDLしてプロパティをみたらビルドverが見れるはずだが?
手元にあるつべのPV動画のプロパティをみてもx264でエンコしたような形跡は微塵も見られない。
自分で調べればわかるはずだぜ。

今は知らんけど使われてたことはあったみたいよ
http://ja.wikipedia.org/wiki/X264

できたファイルのバイナリ書き換えてエンコオプション隠す奴も居るくらいだし
ファイル情報にx264って書いてあるかどうかなんて全くアテにならんだろ

は？

書いてないからと言って、使ってないとは限らないのはその通りだが
特に隠さなきゃいけない理由もない気がするな

隠すことでセキュリティが向上するわけではないし、ライセンス関係を誤魔化す必要もないのだから

>>465
その通り

一昔前に携帯動画とかでOreAQやMixAQを
使って設定を隠す人が居たな
AQの強弱を知られたくない人とかね

設定を隠す人の大半は違法用途向けにエンコしてるんだよな。
何も恐れる必要はない一般人は設定を隠すどころか晒したりもするし。

＞設定を隠す人の大半は違法用途向けにエンコしてるんだよな。

何でそういうこと知ってるの？

わざわざ設定を隠すってところがいかにもジャップらしい発想

>>468
ん?図星だった?

>>468
結構基礎知識

つーか、質問系のスレを覗けば、そういう話いっぱい出てくるから。
　質問者「動画が再生できません」
　→いろいろ話聞くと、違法DL系の珍妙設定でエンコした動画だった
　質問者「エンコしてみたんですけど、画質が悪いです」
　→いろいろ話聞くと、違法に動画をupしたい人だった
こんな系統の。

>>470
俺の知らない世界を知ってるんだなぁと思って

あ、それって違法な事だったんだっけ
あぁなるほど

>>472
ま、それが君の限界だってことさ

逆に朝鮮人だとveryfast設定を書き換えてplacebo設定に偽装するとでも言うのだろうか

>>473
うん、そんな限界越えたくないし

で、貴殿がどこまで越えたんですか？
興味ある…かな

エンコで限界に挑戦か。

BS11のアニメを1440x810にリサイズし
音声も合わせて70MBぐらいに収まるように2passエンコさせて
DVD-R1枚に４クール分まとめて焼いてたりしてたことならあったな。

なんだ確証のない思い込みだったんですね

ID:46hxmBWh
ID:46hxmBWh
ID:46hxmBWh

こいつ明らかに犯罪者だな
ちょっと当局に通報しといた

どうぞどうぞ。PT2で録画したBS11のアニメをエンコして
DVDRに焼くだけでどんな罪に問われるのか逆に聞きたいわ。

興味ある…かな

>>479
やってもいいか権利者に問い合わせてみな

他力本願かよ。478のレスは明らかな脅迫行為だから逆に通報しておくぞ。

どうせ何にもならない煽りあい辞めたら

そもそも通報ってどの作品の権利を侵害してるって言うつもりだろうな…ｗｗ
今は親告罪なんだから権利者でもない一般人が通報した所で何の確証も無く
どの作品かも言わずに通報してたら悪戯として処理されて終わりだろ

>>479をはじめとしてアニヲタって本当にバカばっかだな
早く死ね

とりあえず匿名で証拠も何も無いのに
通報だのそれ犯罪だのって騒ぐなよ無駄だから

>>485
グダグダ言わずに通報すりゃいいだろｗ
馬鹿なの？ｗ

>>487
通報するって行ってるのは俺じゃないよバカカス氏ね

バカばっかり

--no-optsってコマンドで設定隠せたんだけど
これってこれをビルドした人が付けたオプションなの？

ダウソ民のmuken君謹製だしね

脅迫や脅しのたぐいは親告罪ではないよね。

興味ある…かな

x265が怒涛の更新してるｗ

そのわりにx265スレが停滞しているようだが・・・

>>496
あっちはいつもあんな感じ

OpenCLへの対応って進んでるの？
rc-lookahead以来、音沙汰なし？

Open○Ｌは結構種類が増えたからなぁ

そもそもOpenCLへの対応なんて謳ってないし
x264は規格の仕様上、GPU利用は不適だし

エンコードが不適となるとGPGPUって一般人には本当に不必要だな

x264にとっては不要なだけ

HEVCはGPUを活用することを前提にして規格が作られているから。

おお。そうなんだ。それならHEVC期待できるな。
でも、何十億トランジスタ集積されてるが知らんが、ミドルレンジクラスのグラボでGPGPUでエンコしても、
いずれCPUに内蔵されるちょこっとした専用ハードウェアにGPGPUは速度負けちゃうんでしょ？
品質の違いがあるかもしれんけど。

ものすごい演算ユニット数搭載しても、ちっちゃな専用ハードウェアに負けるって、仕方ないか・・

専用ハードに負けるのはCPUも一緒。
GPUを追加するだけで（x264エンコが）1〜2割ぐらい早くなれば万々歳なんだけどな・・。

だからー
GPUとx264はさっさと脳内で切り離しなさいって
夢見すぎだよ

GPU利用はx265。
x264は無関係

「マルチコアに対応しないかな〜」のノリで「GPGPUに対応しないかな〜」って書いても別にいいじゃん

ノリノリに書かれるとイラっとする人も居るだろう。

>>505
ダメだね

テメーが書けや

そろそろ溜まったのエンコするかと思ったが途中から変わった
MXのロゴデータ取らなきゃ、めんどくせええええええええええ

ああ、そういやKIDSのロゴも20thが追加されるとかして一時期変わってたんだっけか。
Utlのロゴ解析は放置していると、ときどきフリーズするからめんどくさいよな。

D_S氏に何が起こったの？
性転換かなにか？

フォーマット/情報 : Advanced Video Codec
プロファイル : [email protected]
CABAC : いいえ　←←←←←←←←←←←←←←←←
RefFrames : 1 フレーム
コーデック ID : avc1
コーデック ID/情報 : Advanced Video Coding
ながさ : 2時 3分
Source_Duration/String : 2時 3分
ビットレートモード : CBR モード
ビットレート : 1 045 Kbps
ノミナル : 1 100 Kbps
幅 : 720 ピクセル
高さ : 404 ピクセル
解像度 : 16:9
モード : CFR モード
フレームレート : 30.000 fps
標準 : NTSC
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 ビット
スキャンの種類 : プログレシッブ(PPF)



AVってなんでCABAC無効でエンコードされてんの？H.264の意味ないやん

プロファイルがBaselineじゃCABACは選択できん

>>512
何かしらの携帯機器で再生できるようにするためとかかな？
Baselineしか受け付けない携帯機器ってあるからなぁ。
それぐらいしか思いつかん。

>>505
でもこれは、ちょっと思うよな
cで書いた非MMXなフィルタをそのままopenCLに持ってって動かしてみると大体砂橋Pentium非MMXぐらいな速度で動くから
GPUをそのままCPUコアのひとつ位に扱ってくれればそこそこ高速化につながるんじゃないかと妄想するよなあ

AVを携帯機器で見ても抜く時どうすんの？

タブレットをベッドにアームで固定してるわ
エルゴトロンで繋いでるディスプレイもあるがちょっとでかすぎる
両手が自由っていいね！

ベッドに固定は便利そうだけど、人としてどうなのよと思い踏み切れない

どんな体勢でもずっとそのまま固定するというのは楽ではないからそこまで廃人っぽくなる訳でもないで

抱き枕や空気嫁に固定して顔のアップ動画を流すってのが一瞬頭に浮かんだ
が同時にキョウダインと言う単語が頭に浮かんだ
つかこんな話はPinkでやれｗ

x264.exeの進捗メッセージさ
フレーム数で言われても残りどのぐらいか解らんねん

残り時間でるだろ

y4mでpipe通してるんじゃね

buildによっては出ないのも有るな

pipeなどで--framesが渡っていない場合進捗は出ない

全部書けてなかった。
pipe使っても残り時間出す方法はたくあん氏のGoogleDriveにbatのサンプルがあったはず。
今手元にそのサンプルないから詳しいやり方は忘れた。

わざわざ有り難う
たくあん市のブログがみつからへん

ブログの方は見つかったけど、GoogleDriveの方が見つからない
でも、原因と対処法は別んとこで見つけた
みなさん、手がかりをくれてありがとう

kmodのバイナリ使えば表示されるで

そういう話ではない

エンコなんて実時間の1/2か1/3程度で終るだろ。
進捗状況なんて気にするだけ無意味じゃね？
常に最小化にさせて放置させてりゃそのうち終わるしな

ずいぶん軽い設定使ってるんですね

MX以外の地デジとかBDとかそんなに劣化ソースじゃないからね。
不必要なフィルタをハブって最小限のパラメータだけ追加すれば4M8Cでも十分速度は出るよ

はいはい、エラいでちゅね。皆お前のやり方に従うべきですよ

エンコベンチスレから拾ってきた数字だと、FX-9370@5Gで veryfast 62.88fpsだそうだが
super ultra 使ってんの？
勇者だな

おまえらの態度にイラッとくるから答える気になれん。

糞設定晒して恥かくのはお前だしな

常識的にエンコで重要なのはx264パラメータよりAVS類の組み合わせだしな。
あとはGPU支援をいかに効率よく使いまわせるかで速度がおおきくかわる。
x264パラメータなんて別にこだわる必要ないだろうって思うけどな。
圧縮率を高めた所で大してデータ量を縮めれるわけでもないし

複数機器での再生互換性重視だから
圧縮率や圧縮効率よりも

そんなの人によりけりだろアホか

複数機器での再生互換性重視だから
圧縮率や圧縮効率よりも 俺は

そう
最初からそう言えばいいんだよ
俺は違うから

トレードオフだからね人それぞれ

だからお前のやり方が絶対。進捗表示を気にするなんて間違ってる
そう言ってるわけだよな

違うと思うよ

じゃあこうか

俺すごい？俺凄いでしょ？

違うと思うよ

じゃあなんで、わざわざ人の求めるものを否定しにｋぅるの？
人それぞれなのにさ

ただの頓珍漢じゃん

坊やだからさ

通り過ぎる犬も笑う。

（∪＾ω＾）わんわんお！

伸びてる時とは馬鹿が湧いた時である

もぅーみんな淋しがり屋さんだなぁー（笑）

ようつべが60fps対応で、ようやく1080/60pが日の目を(ry

でも60fps対応って再生(Player)だけじゃね？
動画自体は60fpsではトランスコーダされてない気がするんだが。

>>555
今のところゲームの公式プロモだけみたいよ

60fps対応と言っても、ビットレート不足でブロックノイズ凄いな

10bit版のx264でOpenCLがサポートされる予定はありますか？

ない

10bitはもうなかったことになってる

グラデーション表現考えたら10bit版以外使えませんけどｗ

x264自体がもう終わったんだよ
全く更新されてない。

頭大丈夫か？

現実を受け入れろよ
x264の開発ペースはくっそ遅くなってる

10Bitなんて昔懐かしS-VHSみたいなもん

そりゃ、規格も仕様も無視して、性能向上するのなら
次世代規格や技術なんて要らんわな

10bitはHEVCでやるほうがいいだろうね。
エンコーダーがまたまだ未完成だが。

テレ東プレイのx264設定
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 7
Duration : 7mn 27s
Nominal bit rate : 1 672 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.061
Writing library : x264 core 118 r2085 8a62835
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113
/ me=umh / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16
/ chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1
/ chroma_qp_offset=-2 / threads=48 / sliced_threads=0 / nr=0 / decimate=1
/ interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2
/ b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=60
/ keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr
/ mbtree=1 / bitrate=1672 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51
/ qpstep=4 / ip_ratio=1.40 / aq=1:1.00

実写をABRの1passでもRTMPでストリーム再生する用途特に不都合はないんだな。

誤：実写をABRの1passでもRTMPでストリーム再生する用途特に不都合はないんだな。
正：実写をABRの1passでRTMPでストリーム再生する用途でも特に不都合はないんだな。

DTV板の32行制限めんどくさいな

俺ならコンテンツの保護を盾に
SAR1:1以外で圧縮するね

>>565
10bitはHigh 10 Profileが策定されているから、H.264での規格や仕様はしっかりとある。

ただ、ハードウェア実装が非常に少ないので、PCで対応プレイヤー使うとき
ぐらいしか意味が無いってだけ。

仕様だけの話なら 10bit は MPEG-2 の時点で存在している。
TMPGEnc でもエンコードはできるようだが、何せ VLC でも再生できない。

D_S氏のレポジトリを見ると一応チマチマ更新はされてるけど本家は来ないね。
今ビルドしたらr2447になった。

更新こねーな
誰か自己Buildおすそ分けしてくれ

x264_rev2447.7z
ttp://kie.nu/1_Ft

DLパスはrev2447
問題があれば削除

殆どの人がAvisynthかAviutlで使うだろうからLavfは入れてない。
最適化オプションは当たり障りないやつに。
実行できなくても知らない。

>>574
マジ乙

変更点は、なんじゃろ

https://github.com/DarkShikari/x264-devel

>>574
繋がらない

ttp://www1.axfc.net/u/3270164?key=rev2447
昨日はここにうｐしたらエラー出たけど今は繋がったのでこっちに上げ直し

いただきました

容量無くなってきたからエンコしまくって500GBくらい空けた
ぞおおおおおおおおおおおおおおおおおおおおおおおおお
まだ後1TB分くらいのこってるけどな(´･ω･｀)

500GBだったらBD-R SL(焼ける容量は実質23.6GB/枚)を22枚分焼けば済むな
50枚組の空メディアは台湾産が1200円前後、国産が2000円程度だし
冬ならともかくこの蒸し暑い真夏にエンコなんてやってられんよ。

実際一般的なBDRWで焼けば1枚あたり12〜15分弱ぐらいで焼けるしなぁ
4倍書き込みって書いてあるものは大抵10倍書き込みできるし
6倍書き込みって書いてあるものは大抵12倍書き込みできる。
だからといってまちがってもLTHやREは買うべきじゃないが。

BDにするぐらいならドライブ買うし

容量だけの事では少々お馬鹿と感じるきょうこのごろ。

むしろうちはエアコンが稼動する夏が、冬に次いでエンコに適する季節だわ

家の断熱がいいんでエアコンの能力が過剰気味
能力を下限ギリギリまで絞ると除湿の効きが悪くなったりして不快
そこでPC2台ぐらいフルパワーで動かしておくと、ちょうどいい冷房負荷になって快適

なにその糞エアコン

昔のは冷房能力あんまり絞れないから、能力過剰なときは微風強冷で乾燥していくか
もしくは断続運転になるかだが
近頃のは最小50Wとかバカみたいに絞れるようになってて
しかしその下限付近では除湿能力が貧弱で湿ってくるのよ

10年以上買い換えてないエアコン？

ここ何スレ？

エンコスレ

エンアコンヌレ

エルカンターレ

申し訳ないが胡散臭い新興宗教の話はNG

宗教に胡散臭いとはウンコに無臭を望むに等しい。

>>594
ぶ、仏教・・

エンコにも宗教あるよね
MP4BOXかL-SMASHかとか、AviutlかAvisynthかとか・・・

エアコン全開でエンコも全開か。電気代が怖すぎるわ。嫁や親と喧嘩にならなきゃいいが。

エンコする程度なら液晶TVより電気代かからないよ

液晶TV と PCモニターの消費電力があまり変わらない件

40v以上の大型液晶テレビなんじゃね

>>596
mp4boxだと少しボケる気がするんだよな
L-SMASHだとくっきりはっきり映像

まぁ、オカルトだと思ってくれていい

さすがにそれはオカルトだろう

コンテナの違い程度で映像のボケ感とか変わるわけなかろう

自分はL-SHMASH教信者だよ。理由は至って簡単、シンタックスが分かりやすい。それとダメ文字がないこと。唯一の難点はdemuxができないこと。これさえできればMP4BOXを捨てられる。

そういやL-SMASH worksでデコードすると高音の伸びが悪くなるって書いてた人がいたな

L-SHMASHとか．．．．俺疲れてんのかな

MP4のことだよね？　普通にdemuxできね？

ああ　L-SMASHができないって事ね　スマソ

>>603
普通そう思うでしょ
ちなみにffmpegでcodec copyしても画質には差が出る
まぁ、こっちはvfr動画通しただけで119.880なんていう変な事になっちゃうけどね

夏の到来ということでようかんマンさんから一言。

　.＿＿
ヽ|・∀・|ノ 　SMASHにしまっしゅ！
　|＿＿|
　　|　|

>>609
画質が安定しないのはきっとデコーダー側の問題じゃね。

デコーダーか・・・
使ってるのはMPC+LAV0.58.2で
x264＋L-SMASHでmp4で吐いて
remuxer -i tcin.mp4 -i audio.mp4 -o mux.mp4

mp4boxも、同じ手順で
mp4box -new mux.mp4 -add "tcin.mp4" -add "audio.mp4"

詳しくはわからんのでオカルトで処理してる

ID:YdeBYT+9　夏休みだなぁ。低脳が涌いてる。

> LAV0.58.2
なんでそんな中途半端に古い奴を…

古いのか・・・MPCに内蔵されてる奴だから単体ではチェックしてなかったよ

MPC を気軽に推奨するやつは所詮こんな話なんだよな。
一つ々確認しながら構築なんて事は少しも頭に無い。
そういうのがいわゆる "糞環境乙" って事だ。

まぁ、changelog見たけど、オカルトが解決しそうな内容は無かったよ
実際LAVFilters-0.60.1を入れてみたけど、>>601でした

まぁ、自分がバカでしたって事でごめんなさい
これ以上はスレチ＆荒れそうなので終わります

>>609が言ってることが気になったのでテスト

ffmpeg、MP4Box、Source.mp4(検証に使うmp4ファイル)の3つをC:/workに置く。
Source.mp4は「muxer.exe -i video.264 -i audio.aac?encoder-delay=2112 -o Source.mp4」で作成したもの。

コマンド
cd C:/work
ffmpeg.exe -i Source.mp4 -vcodec copy -acodec copy Copy.mp4
MP4Box.exe -raw 1 Source.mp4
MP4Box.exe -raw 1 Copy.mp4

後は出力されたH264のストリームのハッシュ値を調べるだけ
結果・・・

Name MD5 Bytes
------------------ -------------------------------- -----------
Source_track1.h264 9903BAB9DFF8D5F22CB84A35EB8943E7 425,437,030
Copy_track1.h264 9903BAB9DFF8D5F22CB84A35EB8943E7 425,437,030
-----------------------------------------------------------------
Total 2 Files 850,874,060 Bytes

ど・・・どういうことですか・・・(困惑)
てか-vcodec copyなのにコピーされなかったら重大なバグじゃね？(適当)

映像自体に変わりはないからやっぱりオカルトってことでオネシャス
VFRの動画だとどうなるか知らん

ちゃんとしたデコーダーなら一致するんだよね、凄い昔のPOWERDVD7
あたりとかでも実験したら一致してたもん

見て解るレベルでボケるとかBob再生されてるとか？

>>616
まあだからってGOMだけはない

話を聞く限りほんとにオカルトで信じがたいんだけど、
とりあえずmp4box、L-SMASH、ffmpeg、MPCはどこのどのバージョンを使っているのか
気になるな。
LAVが古かったんで、他のも古いんじゃ・・・と思っていたりする。

>>618
埋め込まれてるタイムスタンプが異なるんだから、ハッシュ値が変わってもおかしくないでしょう。

わりい、>>623は忘れといて。

>>612
EVR+LAVをHaali Video Renderer+ffdshowに変えてみれば?
LAVは全体的にボケたような映像になるからな。

執念を感じるな

mp4boxでmuxしてからDTSEditとかtc2mp4でタイムコード埋め込んだらどうなるんだろう

ffdshow

ffdshowはavsをそのまま取り込めるし便利なんだぜ?
エンコしなくても透過性ロゴを消したりできるしな

すまんID:GkBFzxvrだ
帰宅してから>>618を書き込んで爆睡してた。

>>622
取り敢えずうちは・・・
ffmpegはZeranoe氏の20140708の64bit版
L-SMASHはrev966
MP4Boxはsada_maru氏の0.5.1-DEV-rev4868+50-git-7b8f8c3

スレチの一端を担った私自ら後始末をつけよう
ネタがないから雑談ばかり捗るってのもまた一興だけど

x264_rev2451.7z
ttp://www1.axfc.net/u/3273552?key=rev2451

D_S氏のレポにまたいくつか更新があったので・・・・

基本的な事柄は>>574をみるべし

そろそろ本家更新してくれ(´；ω；｀)

おしエロください。

x246 って、コマンド・ライン・スイッチで
特定の CPU 拡張命令を使わないって出来ますか ?

まつがえました x264 ですね。

出来ますん

>>632
だいぶ古いリソースだが。
つ ttp://rigaya34589.blog135.fc2.com/blog-entry-182.html

--asmパラメータの個別指定はカンマ区切りで指定するといいらしいが。

>>631
さんきゅー

>>635
ありがとうございます。

>>630
どうもです。
こちらでもちょっと検証してみました。

631のエンコーダと630のツール(L-SMASHは何処のを使っているか分からなかったので、POP氏のもの)を使い、

1. 自前のソースを631のエンコーダで8bitエンコード。mp4で出力。
2. 1のmp4ファイルを、ffmpegで"-vcodec copy"でmp4出力
3. 1のmp4ファイルを、L-SMASHのremuxerで612記載のコマンドでmp4出力
4. 1のmp4ファイルを、MP4Boxで612記載のコマンドでmp4出力
5. 1〜4のmp4ファイルを、それぞれMP4Boxで618記載のコマンドでraw出力

とやってみて、計4つのmp4ファイルと4つのrawファイルを作成しました。

その後、mp4ファイル同士、rawファイル同士でバイナリ比較をしてみた結果、

・mp4ファイルは「4つとも不一致」
・rawファイルは「4つとも一致」

となりました。
つまり、ffmpeg、L-SMASH、MP4Boxのどれを通しても、映像データに影響は与えていない、ということになりました。
ずっとエンコードして来ている方にとっては、思っていた通りの結果だと思います。

そして、mp4ファイルの不一致については、単に埋め込まれたコンテナ情報が変わっただけと
考えていますが、601氏は「muxerの違いで画質が変わった」と言っているので、
もう一つ別の検証をしてみました。

(つづく)

(つづき)　※ID変わってますが、D0cLHibTです。

自分の使っているMPC-HC 1.7.3(EVRカスタム) + 外部のLAVfilters 0.61.1(splitterもLAV)という再生環境で、

1. LAVfiltersの「Output formats 8bit」を、"YV12"のみチェックが入っている状態にする。
2. 4つのmp4ファイルを、それぞれ上記の環境で再生し、
　 「ある目的のシーンの直前までジャンプ　→　その直前からコマ送り　→　目的のシーンでMPCの機能で画像保存」を行う(画像はbmp)。
3. 4つの画像をバイナリ比較する。

という手順で、4つのデコード結果の一致・不一致を確認しました。

その結果、「4つとも一致」しました。
mp4コンテナに違いがあっても、デコード結果は同じ、ということになりました。


以上により、人によって動画作成環境、再生環境が異なるので、みんなこの結果になるとは言えませんし、確認方法にも不備があるかもしれませんが、
こちらの環境では、オカルト現象は確認できませんでした。

正直「そんなことがあり得るのか？」というのが本音ですが、それでは元も子もないので、

・ぼやけるmp4ファイルとくっきりmp4ファイルの、キャプチャー画像を比較し、本当に違いがあるか
・再生時に使用されているスプリッタやデコーダが、どちらのmp4ファイルを再生しても同じになっているか
　(MPC-HC日本語化済なら、メニュー「再生」→「フィルタ」で確認可能)
・いっそ動画自体、一から作り直してみても同じになるか

等をしてみてはどうでしょうか？　何か分かるかも知れません。
と、アドバイスになっているか分かりませんが、付け加えておきます。
(すでに確認済みならすいません)


長文失礼しました。

muxで画質が変わるとかオカルトはそろそろ止めにしよう
それを言い出した『USBケーブルで劇的に音が変わる』と一緒できりがないｗ
変わると信じたら理屈はいくらでもつけられるから

>>640
まぁ俺が言うのも何だけどネタがない・・・orz

>>638
L-SMASHは自ビルドだから誰のものでもないよ
>>640も言ってるようにオカルトは突き詰めるとキリがないので結論は「変わらないはず」ってことにしよう


てことで俺が言うのもおかしいけどこの話題しゅうりょーーー

>>641
そんな不満たらたらみたいな言い方で終わらせるくらいならスクショでも上げろ

>>638
MP4コンテナにはタイム・スタンプが存在するだろ。
キチガイ

タイムコードじゃね？タイムスタンプってなんだよ。

タイムスタンプ知らんのか

>>644
>>644
>>644

知らんな。知ってたら何か得することでもあるのか？
いや、まさかMP4ファイルのタイムスタンプの事を言っているとか？

>>647
>>647
>>647

ID:gRwahM54

そうやって上から煽ればなにか面白い結果でも出てくるとでも？小物過ぎてしらけるわ。

>>643
>>638もそれはわかってると思うぞ、
それを踏まえて「ファイルのバイナリが多少違っても中身は同じだから画質が変わるわけがない」
っていう主張をしてるんじゃないのか？

この話、続ける意味あんのか。ねえだろ。

エンコ関係のスレはこの数日どこもこんな感じ

夏だなぁで済ませておけ

muxで画質が変わるとか言ってる奴は、どこのスレから来た荒しだよｗ
raw一致で満足出来ないなら、Avisynthにクリップ2つ読み込んでCompareしてみりゃ良いだろ

くだらね

数GBあるDL物のハイビジョンAVはSDサイズの500kbps程度の画質でいいと思う僕です

mp4吹き荒れるスレに颯爽とmkvユーザな俺惨状

久しぶりに昔の動画漁ったらrev1300台の奴があった
時代の流れを感じた

おれはr286（勝ったぜｗ
Pentium3で丸一日かけた覚えがある。

アナログ時代の時は、XVDでハードウェアリアルタイムエンコードしてたな

>>658
兄貴と呼ばせてもらいやす！
この頃は半日とか当たり前だったけど今は等速以上の速度が普通に出るとは・・・デフォ設定だと1.5倍速は余裕で出る(FHD 24pソースで)
時代の流れを感じた(2回目)

gyao!の動画がx264を使っているようでなにより。
見るだけならあれぐらいの質で十分なんだよな。
綺麗に保存したいなら自分でエンコすれば確実だが色々面倒過ぎる。

r1376なら今だに使ってるよ
コレ以降は音声遅延問題があって使えない

たかだか音声の1〜2フレームの為にまだ古臭いの使ってるのか
エンコ速度全然違うぞ
後々どうなるかわからんから、けっこうどうでもいい軽めに作りたいのには--dts-compress
保存しとく動画には--b-pyramid "none"で1フレームズレ
にしてるぞ
2フレームズレるとSEで違和感感じる事もあるが1フレームならわからん

1300未満になると問題が多いが好きなの使えばおｋ

最高に頭悪そう

ここまで堂々と書いてあったら自分の知ってる知識が正しいのか不安になってきた。
恥を晒す覚悟で聞いてみる。

1.音声遅延とx264は無関係である。(音声にはエンコーダーディレイがあるがx264とは無関係)
2.x264にはBフレームの遅延問題がある。それは--bframes 1以上で1フレームの遅延、--b-pyramidの使用で更にもう一枚。最大で2枚の遅延である。
3.このBフレームの遅延はmp4のedtsで補正される(べき)ものである。x264のmp4出力ではそのedtsがコンテナに書き込まれる。
4.しかし世の中にはedtsが読めない機器が多い。そのような機器の為に--dts-compressでedtsを用いずにディレイを補正することが出来る。
5.x264とは関係ないが、例え映像の遅延を打ち消したとしても音声の遅延が発生したままなので結局のところ映像と音声はズレたままである。よって音声も遅延の打ち消しが必要である。

こういう認識何だけどこれで大丈夫なの？長文でごめん。
間違ってたらビシッと指摘して欲しい。間違った知識をそのままにしておきたくない。

avsで修正すればいいんじゃね？

>>666
その通り
少なくとも俺の認識とは一致してるよ

上で誤解してる人らは恐らく携帯機で視聴してる層じゃないか？

Haali愛用してる人かもよ

愛人とﾊｧﾊｧするのか

ここより抜粋

ごめんミスって書き込んじまった
ttp://shion17.blog.fc2.com/blog-entry-2.html
ここより抜粋

QuickTime: 2112
Nero: LC = 2624, HE = 2336, HEv2 = 2808
faac: 1024
ffaac (libavcodec's aac): 1024
libvo-aacenc: 1600

てことは
muxer.exe -i audio.aac?encoder-delay=xxxx -o out.m4a
これで大丈夫だよね？

いつもこんな風に記述してる。
L-SMASHAudioSource()で読み込んでWAV出力すると元ソースと波形位置が一致したからこれで正しいのだと思う。

edtsの件は大分前に知っていたけど何か主流にはならなそうだし無視してた
特定の条件でしか補正されないってのは無いわ

playerが同様に重要

ごめん重要なこと書き忘れてた連投スマン

いつものエンコ方法

avs4x264mod.exe --x264-binary x264x64.exe -o video.264 input.avs

wavi.exe input.avs - | qaac.exe --adts - -o audio.aac

muxer.exe -i video.264?fps=24000/1001 -i audio.aac?encoder-delay=2112 -o movie.mp4

>>675
muxerは使ってないからあれだが、多分合ってると思うよ
ただ、音声側のedtsはスプリッタによっては対応が怪しいんで、俺はqaacのオプションでディレイカットしちゃってるけどね
aviutl使いも今は拡張x264で自動で必要分音声カット出来てるはず

この際だから疑問は全部質問しておこうと思う。

--dts-compressについての質問。
このオプションはedtsを用いずに遅延を補正する方法だよね？
boxdumper.exeを使って調べた結果だけど

遅延フレームが1枚の時は、1-2フレーム目を2倍速で再生して3フレーム目以降の遅延を打ち消す。尺を合わせるために最後のフレームを1/2倍速で再生する。

遅延フレームが2枚の時は、1-3フレーム目を3倍速で再生して4フレーム目以降の遅延を打ち消す。尺を合わせるために最後のフレームを1/3倍速で再生する。

これによりedtsを使わずに遅延を打ち消せると結論付けたけどあってるかな？

>>677
書いてる本人も自信ないらしいし、俺も細かくはわかってねーけど。

　　x264の初期ディレイカット機能の概要（あってるか自信なし）
　　ttp://goldenhige.cocolog-nifty.com/blog/2010/04/x264-c7a9.html

タイムスケールを本来の4倍にして、最初の1フレームが表示されてる間に
ディレイの原因となる分のフレームをデコードできるようにする。
後はデコードしたものを時間通りに表示していくだけ。
という感じかと。

>>677
>>678であってるらしい。

　　https://twitter.com/Paranoialmaniac/status/487884363049095168
　　「>>677間違ってる。>>678合ってる。」

　　https://twitter.com/Paranoialmaniac/status/487884630788304897
　　「まぁ、別に一律に4倍する必要無いのですが。 (delay + 1)倍すれば十分。」

>>679
有難う　じっくり読んでみるわ

>>681
「>>678が合ってる」というのは、多分>>678のレスだけ見ての言葉だと思う。
リンク先の記事の内容までは保証してないと思うから注意な。

>>681
りょーかい
読んでみたけど、つまりはデコード待ちの為に遅延を発生させるなら、タイムスケールを大きくして最初の部分だけ一気にデコードするってことかな。
フレームレート自体は変えないのか。

初期ディレイはともかく、音とズレるってのはどういうことなの？
遅延がどんだけあろうが表示・再生はPTSで揃うもんじゃないの？

dts-compress使用しないで
edts非対応プレイヤーで再生するとズレてるように聞こえるよ

zerolatencyでも使えば

mp4コンテナ固有の問題なのかね

444だとインタレ保持出来ないバグはいつになったら修正されるのか

444のインタレってどういう状況で必要になるんだ

Blu-rayRipは違法だぞ

インタレソースを444でエンコしたい時だよ
他に何があるんだよ逆に聞きたいわ

なんでわざわざ4:4:4にする必要があるんだ？

ソースが420なのに、とかバカな事言ってるんじゃないよな

>>692
今テストで500フレームだけエンコしたら出来たけど？

444のインタレソースってどこから発生するんだ

>>694
俺に聞いてる？
ConvertToYV24(interlaced=true)で無理やりやった。
間違ってるかな？普段使わないから自信がない。
komisar氏のr2431 clear x86をavs直接読み込んで、明示的に--input-csp i444 --output-csp i444 --tff --frames 500を付けてエンコした。

いや、彼に

作ろうとすれば作れることはもちろんわかる
しかしそんなものがどこで使われてるのか、どこに使おうとしてるのかが見当もつかない

ああ、勘違いしちまった　スマン

俺も検討も付かないけど、4:4:4にするぐらいなら4:2:0のまま10bitじゃダメなのかな？
10bit否定派の互換性ガーとか速度ガーとかは4:4:4な時点で同じなんだし

>>692がよくわからんのだけど、「ソースが420なのに」ってバカな意見なのかな？
すまんけど誰か解説してくれると助かる。

逆に言えば444のインタレソースが有るのか？って事なんだろうが有るんじゃね？としか

この世からケチくせえインタレースを滅ぼすほうが賢明

当時は苦肉の策だったんだよ・・・
ところで4kもインタレなの？

>>700
一理どころか千理ある

>>701
なんか試験放送はHEVC 60pだったよ
確か10bitだったけどこれは記憶が曖昧。

いまあるテレシネ解除プラグインが使えなくなるからプログレ化は嫌だな

ちょっと追加。
プログレフレームの重複なんて絶対に間引き失敗する

失敗しない

無理矢理weaveして一旦インタレにすれば、従来通りの方法で周期調べられる。

>>706
その発想はなかった
いや間違ってないっぽいけどそれを思いつかなかった
なるほどこんな考え方もあるのか

地上波もRFF使えばおｋ、と思ったがBSJみたいに扱いが面倒に成るからインタレのままで良い
次世代放送？エンコどうこう以前に抜けなきゃどうしようもないしな…。

おまえら4kになってもエンコするの？その頃ははでで一台で
8TBとかになってるんちゃう？エンコする必要あるの？

>>695
一見出来てるように見えるけど再生すると縞々
422とか420だときちんと再生出来る

容量とか関係なくマジでそろそろエンコ止めたいんだよね
BDたけぇしダウソは違法になったしってズルズル続けてきたが、潮時かもしれないと最近思わんでもないｗ

>>710
インタレなんだから縞あって当たり前だろ
どう考えても再生側の問題

>>710
もしかして>>712が言うように再生側の問題のことを言ってない？YUV4:4:4自体互換性が決して高いとは言えないよ。

>>713
そのテストで作ったもの再生すると縞出るよね？

Aviutlに読み込ませるとちゃんと縞が出てる
MPCで再生すると縞が出ない(インタレ解除するようにしてるので当然と言える)

レンダラ何使ってんだ？

なるほど分かった　スマン縞出てるわ
レンダラのMadVrが縞消してたっぽい

え
>>713もわかってなかったの？

インタレなんだから当然縞があって再生する時にレンダラでデインタレする
当たり前じゃない
現状high bit-depthの422/444のデインタレに対応しているのはmadVRのみ

いや　一応8bit何だけど・・・レンダラの設定確認してなかったわ　俺のミス スマン

>>718
＞現状high bit-depthの422/444のデインタレに対応しているのはmadVRのみ
こういう事知りたかった
ありがと

>>718
俺も知らなかったわ
赤色の補完だけを目的に使ってたから

最後に確認してもいい？
エンコは正常にできてるんだよね？つまり再生時のインタレ解除のみMadVr以外不可能ってことでおｋ？

講釈吐いてるわりにろくに確証もしない糞だと確証を得られた。

検証にAviutlを使っちゃう時点で何も分かってない事確定だろ

utlは透過性ロゴを解析する時以外使わないな。

そう言えばみんなAvisynth + バッチで使ってるの
それとも別にシェルとか使ってるの

バッチ書いてタイトル部分だけ書き換えて使い回せるようにしてるよー
動画毎に細かく設定なんてここ3年めんどくさくてやってねーよー

Avisynth + バッチの方が倍ぐらい早いのは分かってるけどAviUtlの方が精度が高く綺麗に出来るのでやめられない

うちはテンプレ設定を予めバッチファイルに書いてて、投げ込んでファイル名とCrfの値を入力するとダブルクリックでエンコが始まるようなバッチを出力出来る用にしてる。
sarの関係で1:1と4:3の2種類を作ってる。内部で分岐も考えたけど面倒だったのでやめた。

ttp://putin999.blog.fc2.com/blog-entry-52.html
出力したバッチはこれを使って順次実行してる。

>>727
Avisynthは16bit精度のフィルタなんかもあったような。

>>727

俺も昔はAvisynthのほうが早いと思っていたけどぜんぜんそうじゃありませんでした。
今の俺の考えは高速、お手軽エンコならAviUtl、綺麗にやるならAvisynthってなっているな。

Avisynthでの16bitフィルタ使用の綺麗さおよび圧縮率増加、AviUtlの色空間による赤劣化問題など
綺麗に作りたいならAvisynthの方がお勧めだよ。

>>730
>AviUtlの色空間による赤劣化問題

赤の劣化は4:4:4を4:2:0にする際に発生するものであってAviUtlは関係ないんじゃね。

Avisynthが速いってのは間違いだと思うよ
正確には無駄な処理(色空間変換など)をする他のツールが遅いって考えが近いと思うけど

AviUtlでCMカットしてavs_export使ってavisynth用テンプレファイル読み込んで書き出し、作ったavs読み込んで
マニュアル24fpsでテキトーに周期合わせしながらテロの前後にもCCTP付けて最後にテキストに変換、元avsファイルにコピペ、
avsPmodとかで編集を詰めていってx264でコマンドラインエンコ、と言う使い方してる。

CM を抜き出して保存している。
何年も経過して再放送なんて無いだろうからな。

vapoursynth

tsエンコなら
tsファイル(同時に複数可)をバッチファイルに投げ込んでテンプレのavs及びLWLibavVideoSourceのインデックスファイルを作成する。
AvspmodでCMカット&必要なら24p化等をする。
で最後に>>728の方法で出力
Aviutlは普段は使わないな 動画を「エンコする」だと不要。動画を「作る」だと100%必要になるけど

avs読み込んでCMカット、そのままバッチ登録してる。
Trimのコピーとかメンドクセ

AviutlとAvisynthどっちが速いとか綺麗ってときどき話題にあがるけど、
mkvとmp4どっちが綺麗って言うのと大差ないような気が。

保存用は DGindex で分離さしてから Faw 通して AvsPmod で CM カットしてエンコ。
ディスク節約の為にどうでもいいやつは Handbrake

AviUtlの仕様でYUV420ソースでもYUV422で読み込んで処理してるから
基本YUV420のまま処理するAvisynthより遅くなるってだけでしょ
AvisynthだってYUV422で処理すれば当然遅くなる

>>740
デフォでは内部処理は独自フォーマット

>>731

俺が聞いた話だと>740が書いている感じで
AviUtlの内部処理がYUY2(YUV422)でたとえばTSエンコMP4出力の場合

AviUtlだと YV12(YUV420)→YUY2(YUV422)→YV12(YUV420)
Avisynthは YV12(YUV420)→YV12(YUV420)→YV12(YUV420)

で、1工程余分な色空間の変換が入って赤がさらに劣化するって話だった。

いろいろ語るわりには誰も画像を持ち出さない
お前ら、人の理屈で納得して自分では違いなんてわかってないだろ

>>742
変な補間処理入れなければ
YV12→YUY2→YV12で完全に元に戻せる。

正確に言うとYV12→YUY2→YC48→YUY2→YV12じゃないかな？

>>745
そうだね。
情報量はYC48>YUY2>YV12なので
然るべき変換すれば元のYV12に戻せるはず。
Avisynthの場合はConvertToYUY2ではなくYV12toYUY2を使った方がいい。

avisynth用の

>>742
劣化しないよ
諧調部分もバンディングが出やすいのは後者

http://officiallist.videotopics.yahoo.co.jp/brand/video/?bid=2014fifaworldcupim

字幕焼かれ再圧縮されたやつ

Writing library : x264 core 142
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x3 / me=dia / subme=1 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 /
threads=1 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 /
bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=1 /
scenecut=0 / intra_refresh=0 / rc_lookahead=0 / rc=abr / mbtree=0 / bitrate=4872 / ratetol=1.0 / qcomp=0.60 / qpmin=0 /
qpmax=69 / qpstep=4 / vbv_maxrate=9744 / vbv_bufsize=19488 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

だった

>>744
放送とかインターレースの4:2:0だと無理

とりあえずAutoYUY2で変換したほうがよくない？

AutoYUY2も、mode=1にすればわかるけどデフォルトのthreshold=7だと縞を見逃す事が多いので、
シビアな調節がいる

あれよりまだこうした方がいい

#interlaced yv12 to yuy2
function yv12toyuy2_laced(clip i, int "th", bool "matchfields")
{ th=default(th,8)
matchfields=default(matchfields,false)
i.converttoyuy2().mergechroma(
\ i.tdeint(mode=1,type=1,mthreshc=th,tryweave=matchfields,full=(matchfields==false)).converttoyuy2().separatefields().selectevery(4,0,3).weave()
\)
}

いずれにせよ、プログレッシブにするところまではYV12でやっておく方が無難

かなり前に、h264parse.exeというバイナリをどこかから拾って
H.264ストリームの解析内容を出力して見てみたことがあるのですが、
これの正規（？）の最新版の置き場と使い方をご存じの方がいたら教えていただけないでしょうか。

調べてみたところ、h264parse自体はgstreamerのgst-plugins-badの中にあって、
videoparsersbadというプラグインに組み込まれているっぽいことまではわかったのですが、
試しにgstreamer-1.0-x86-1.3.91.msiをインストールしてみたものの、何だかよくわかりません。
gst-launch-1.0.exeにパイプライン表現とやらを食わせればいいような気もするのですが、
H.264ストリームの解析情報を出力するためのパイプライン表現をどう書けばよいのかわかりません。
というかその方法であってるのかすらよくわかりません。
h264parse.exeは、誰かが書いたWrapperみたいなものだったんでしょうか？

解析って何がしたいんだろ
オプションでも探りたいのかな

>>754
解析といっても大したことはやったことがなく、以前Haaliでsar=4:3,3:2,2:1が反映されないという
話が出た際にsarの値の格納方法を確認するのに使った程度なのですが、
今のgstreamerにはh265parseというのも含まれているようなので、
今後のためにも使い方を知っておきたいと思った次第です。

>>753,755です。とある方のツイッターのおかげで自分の勘違いに気付きました。
ありがとうございます。
探していたのはmpeg4iptoolsに含まれているh264_parse.exeでした。
ミラーしか残ってないし多分バグもあって不安定とのことなので自己責任ですが、とりあえず。
　　http://d.hatena.ne.jp/juria-no/20070917/1190001364

gstreamerのh264parseは全く別物だったんですね・・・。
ググった最初の時点で思いっきり見当違いの方向を向いてしまったようです。
そういうものもあるということを知れたということで１つ勉強になりました。
お騒がせしてすみませんでした。

>>756
githubにも同名のバイナリ置いてあるようだけど。。

>>757
自分も昔どこかで適当にバイナリ拾った記憶しかないんで、
どれが真っ当なmpeg4iptools(h264_parse.exe)なのか、さっぱりわからないです・・・。
>>756のサイトも適当にググって見つかったのを載せただけなので・・・。
そもそも何でh264_parse.exeの存在を知ったのかすら、よく覚えてない・・・。

ﾊｧｧ俺が本読んでる間に勝手にエンコしてくれる妖精さん
とかいないかなー(´･ω･｀)

逆に考えるんだ　自分でしなくてはいけないと
(もし見つけたら教えてね)

PCが貴様のために何をなしうるかを問うのではなく貴様がPCに何をなしうるかを考えよ。

>>759
　　　　(　　　ﾟ)
　　　　/　　つ
　　　 (_(＿ヽ
　　　　し し′
　　ノ|
　（￣￣）
（￣￣￣）
　￣￣￣

>>759
ハ〜イ 私妖精よ
今日はどのエロアニメをエンコすればいいのかしら？

えっちぃシーンだけTrimしてQP0でエンコして下さい
(´・ω・｀)

>>764
エンコをおながいするより
妖精さんに援交を要請するほうが良いんじゃないのか ?

それはんざいですからー

>>763
CMカットだけ済ませたファイルのフォルダ全部消化しといてください

>>767
それもうバッチに投げ込むだけじゃね？

r2453

popさんまだ復旧してない

たくあんさんからダウンのリンク消えてるし
どうすれば

popさんもビルド古いしなぁ

POPさん復活はよ

videolanのバイナリはVer不揃いか、Verごとにフォルダ分けしてるから面倒だな

ttp://www1.axfc.net/u/3281022?key=rev2453

問題があれば削除
rev2453

>>574の注意を必読のこと
komisar clearが出るまでの繋ぎだと思ってね

いらね
videolanので十分

いただいたでござる

>>752
そんなガチガチなつなげ方しておいて
tryweaveをなぜパラメータ可変にしているのかさっぱりわからん。

>>778
テレシネソースにはtryweave使ったほうが高画質。
それぞれ同じ縞解除でもやることが全然違うらしい

x264 Development Newsletter: Vol. 44のFiona Glaserって誰だろう

D_S氏じゃなかった？
muken氏がそれっぽいこと書いてた気がする

確かに苗字の後半は一致するけど、性転換でもしたのかと思った

性転換したんよ

それで東方の女装とかしていたのかと思うと合点はいくけど、やはり少し驚く

性転換ってネタじゃなくてマジなの？
ちょっと信じられないんだけど・・・・

オシャウスキー兄弟の弟も性転換したからマジでしょ

ここ何のスレだっけ

ジェンダー論考察スレだろ

おまえらもエンコばっかしてないでたまには性転換でもしろよ

エンコして動画作らずマンコ作ったんか

よく目にするTSはTransSexualの略だろ。

オカマはどっかいけよ。

POP氏のところのr2409を使わせてもらってるのだけど、--colormatrixのデフォルト値が
"undef"じゃなくて"bt709"になってるのは、POP氏があえてそうやってビルドしてるということなのかな？
テスト用にcolormatrix付けずにエンコしたつもりが全部bt709になってて焦った。
Komisar氏や06_taro氏のとこは"undef"だし、デフォルト値が変わったわけじゃないよね？

細かいことだけどKomisar版とかのfullhelpで、colormatrixのデフォルト値が
"undef"じゃなくて"???"と表示されるのも少し気になった。

>>793
それはPOPさんが、わざとやってる