x264 rev28

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

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

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://pc11.2ch.net/test/read.cgi/avi/1247319611/


[本家]
http://www.videolan.org/x264.html
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)
http://doom10.org/index.php (公式フォーラム)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

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

前スレ
x264 rev27
http://pc11.2ch.net/test/read.cgi/avi/1269245115/

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

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

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

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

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

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

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

rev27 938氏によるmp4用dts_compression有効化（edts無効化)パッチ
http://pastebin.org/354186

及び960氏によるバイナリ
http://bbs.fushizen.eu/viewtopic.php?f=3&t=5#p20

これは>>1乙ではなくて、わっちの自慢のしっぽじゃから勘違いをするでないぞ！
　　　　　　　　　　　　　 |＼　　　　　　 |＼
　　　　　　　　　　　　　 l lヽ`-‐ '´￣ ｀ヾゝヽ　　つ
　　　　　　 　 　 　 　 　 ｼ~　／" ｀ヽ ヽ　 `､l　　　　　つ
　　　　　　　　　　　　　//, '///|! !‖ ヽﾊ　､_ヽ　　つ
　　　　　　　　　　　　 〃 {_{＼」」 Ｌ|l|／ﾘ ｌ │ |ヽ　　　つ
　　＿＿＿＿.　 　 　 ﾚ!小ｌ●　　　 ● 从　|、|　）
　く　　ﾉ::::::;;;;;;＼. 　 　 ヽ|l⊃　r‐‐v　⊂⊃　|ﾉﾊ´
　　￣￣フ;;;;;／　/⌒ヽ__|ﾍ　　ヽ ノ 　 　j /⌒i !ヽ
　　　 ／;;;;／　　. ＼ /ヽ.|　l＞,､ __,　イァ/　 ///ﾊ
　　／;;;;∠＿＿＿　/ヽ./|　|　ヽヾ、　/,{ﾍ､__∧/ﾊ !
　く:::::::::;'::::::;':::::::;'::::::7ヽ< } / 　 l丶× / ヾ l　l''ﾊ∨

乙

乙ですん

ｒ1659
core100
opengop/threadpool

これからx264を使ってBDを作る人は、--keyint 24 --open-gop coded としておけば良い訳か。

OpenGOPのCommitなんだけどさ。

encoder/slicetype.c : x264_slicetype_decide
のところで、
X264_TYPE_KEYFRAMEをTYPE_IかTYPE_IDRに置き換えしてるよね。
なのに、その後のLimit GOP SizeのなかでTYPE_KEYFRAMEかどうかを
再度評価してるように見えるんだが。なんかおかしい？

rev.1659で、TFFなSDソースをAVCHD向けにOpenGOP有効(coded)、無効(none)で
エンコードして、脈動ノイズが軽減されるか比較してみたけど、違いがわからん…。

x264 --crf 28 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --open-gop coded
--vbv-maxrate 15000 --vbv-bufsize 15000 --level 4.1 --keyint 30 --b-pyramid strict --slices 4
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 10:11 --fps 30000/1001 --ref 6
--aq-mode 2 --profile high --no-fast-pskip --threads auto --thread-input --cqm "jvt" --min-keyint 2
--tff --output "output.mkv" "input.avs"

脈動ノイズがわかりやすいように、わざと高いcrf値でやってみたけど、OpenGOP有り無しで
どっちも同程度脈動ノイズが出てて違いがわからなかった。

ところで、--audオプションを追加すると、AVCHD化したときに音声は流れるけど、
映像は画面が真っ暗なままになってしまうのはなぜでしょうか？
オーサリングはTsMuxerやMultiAVCHDを試して、焼きはImgburnを使って
UDF2.50でDVD-Rに焼いて、再生はPS3、DIGA BW750を試してます。
どの組み合わせでも画面は真っ暗なままです。

--audオプションを削除すると映像が出ます。--audオプションが
付いててもPCのソフトウェアプレーヤーだけ映像が出ます。

う〜ん、スレ違い気味ですみません。

938先生のパッチを適応したバイナリがそこそこ定期的に出ますように。

r-1659
http://firestorage.jp/download/7c2bffa61c07e1733e2628f347a9a7cef5d8f8cc

intelオンリー

消してしまった・・・

r-1659
http://firestorage.jp/download/5964849b8c0ed3eff7003417d5769144d6b87035

>>13
このバイナリは
Youtube板の"FLV/MP4作成スレ"に置いたほうがよかったな
最初で最後ですｗ

>>14
ニコ厨の間ではdts_compression（初期ディレイカット）はご法度です
ニコニコではsarは無視されるので、No_PASP_atom_in_mp4_muxing.diffも不要です
本気で言っているのなら、とりあえずx264_mp4_dts_compress_1.diffをはずして再度上げなおしてくださいな

>>15
つhttp://komisar.gin.by/

>>15
これで良いか？
x264_mp4_dts_compress_1.diff
No_PASP_atom_in_mp4_muxing.diff
無し版
http://firestorage.jp/download/82a10d42eb94b60fa9636b7fd655f5333f74128a

-march=native -msse4.2
(64bit)

奇跡の台湾製メディアプレーヤー
http://www.geocities.jp/yadabot/pavmp1

意外と便利なんだけどお前ら的にどうよ？

>>18
容量4GB超えのMP4が再生できたら買う。

chroma-qp-offsetってなんなん？
20位にしても汚くなったり色が変わったりする気配が一向にない
容量は減ってるんだけども・・・

>>20
色の濃さ?結構変わると思うけど
俺はpsy-rd有効にしたら、+2する

ソースや好み次第なんだろうけどpsy-rdって実際どうなん？
なんかビットレートだけ無駄に食ってあんまり画質上がらない印象なんだが

gradfun2dbmodとか使うならpsy-rdは0.2ぐらいでもいいから入れた方が良いと思う

>>22
ソースと個人の目の差だよねぇ（どこまで画質を気にするかどうか）・・・
と基本的に--psy-rd 0.8:0.4なオイラが通ります。

たまに妙に軽いノイズとかディザリングが入ってきて、psy-trellisを上げる必要
が出てくるけどねぇ。そういう場合は普通に--psy-rd 0.8:1.4とかありえるし。

確かに、Psy-RDができて、そんなにビットレートを上げなくても、
GradFun2DBmodの効果を保持できるようになった。

映画には元からあるグレインを保持したい場合にも、有効な機能だろう。

そんな微妙な変化がおまいらに分かるのか？

目視で評価なんて・・・

komisar版
experimental LTO-enabled GCC version 4.5.1
cross-mingw.gcc451.generic.20100626.7z (46M)

GCC4.5.1+LTO+make fprofiled・・・GCC4.4.4+make fprofiledよりエンコード速度がUPした
今回のGCC4.5.1LTOはいいぞ

>>26
http://img714.imageshack.us/img714/3686/48084786.png
http://img29.imageshack.us/img29/3518/32356460.png
http://img823.imageshack.us/img823/6558/78284492.png

http://www.mediafire.com/file/mjj2moht3tz/psy-rd.zip
http://cid-bee3c9ac9541c85b.office.live.com/browse.aspx/.Public/Match%20Point

病気

男は黙ってtrellis 0

オカマは黙ってcrf0

女は黙って aq 0

crf0とか再生出来ねえ、オカマパねえな

>>29
こうやってみると--psy-rd 1.0:0.2のが多少マシっぽいけど劣化の具合は似たり寄ったりだな
それよりサイズの変更に安定して耐えるのコレ

>>29
はっきり分かるね！Psy-RDは以前試したときに数値を上げれば上げるほどSSIMが低下したからデフォのままだけど
psy-rd 1.0:0.2でやってみよう

何を根拠にこの値に決めたのかも忘れてしまったけど
しばらくこの設定でやってる
--psy-rd 0.5:0 --trellis 1

>>36
セルアニメはそれでやってるな
下げるとエアブラシで書いた砂嵐なんかがぼやけてもやに成るし
上げると輪郭に乗るノイズが増えるしで妥協した数値だけどｗ

実写はx264のBDデモが1.0：0.15だったんでなんとなくこれにしてる

有り難く頂きますた。まだPS3で動作確認してないけど、大丈夫になったのかな。

revision 1659 (938)
http://bbs.fushizen.eu/viewtopic.php?f=3&t=5

実写もアニメもPsy-RD使うよりaqとかでqp下げた方がサイズの割に綺麗な気がするからpsy-rd 0:0だな

--psy-rd 0:0 と --no-psy は違うって聞いたけどどう違うか分からんｗ

君みたいな人は--tune ssimでも使ってなさい

実写とセルアニメはpsy-rdを少々使う
通常のデジタルアニメは使わない
trellisも0だ

GCC4.5.1 LTO

x264 binarys (x264_mp4_dts_compress_1.diff)
http://sada5.sakura.ne.jp/

なんかもうフィルムグレイン無いと眩しく感じるようになってきた

>>42
64bit版が欲しいナリ

>>44
(x64) x264.exe / "-flto -march=native -msse4.2" "x86_64-pc-mingw32" / fprofiled
(x86) x264.core2.exe / "-flto -march=core2 -mssse3" / fprofiled
(x86) x264.generic.exe / "-flto -march=i686 -mtune=generic" / fprofiled

x264.exeのみ64bit版です(sse4.2必須)

つるぺたエンコのアニメはなんか気持ち悪い

要所要所だろ馬鹿
デジタル彩色に適応型使っても意味無しだし

>>45
AMDなんです(´・ω・｀)

>>47
何言ってるんだこいつｗ

>>49
自己紹介乙

>>50
いきなり馬鹿呼ばわりして頭おかしいんじゃねーの？
そもそもどこにレスしてるんだよ基地外
暑さで頭やられたか？

すまん適材適所だよなｗ
国語力は少し鈍い

>>51
勝手に基地外呼ばわりすんな
どうせお前も即レス返す基地外ｗ

だから何に対して馬鹿っていったんだよｗ
わからねーよ

46 名前：名無しさん＠編集中 投稿日：2010/06/28(月) 16:06:50 ID:cEAbo2rL
つるぺたエンコのアニメはなんか気持ち悪い

お前の言うように適材適所でやればそうならないだろ

大体元ソースは完全なつるぺただぞ
フィルムグレインとか付けてるのはコイルぐらいだ

>>48
(x64) x264.exe / "-flto -march=native -msse4.2" "x86_64-pc-mingw32" / fprofiled
↑ほぼ自分用ｗなんですよ
最適化つけても、あまり変わらないけど・・・要は自己マンだぬ

今度のリビジョンから64bit/generic作ります。
genericならintelファミリーもAMDファミリーもOKだから

この方のバイナリは試してみましたか？
revision 1659 (938)
http://bbs.fushizen.eu/viewtopic.php?f=3&t=5

>>57
もとからあるグレインからディテールまで削って
つるぺたにしてるのたまにみかけるからな
そういう動画の話な

>>58
色んなとこの試してnlのバイナリが一番速かったので使ってます
次のリビジョンからに期待してます

>>42先生、お疲れ様です。
細かいことですけど、binariesじゃないんですか？

おそロシアのでいい

おそロシアは最適化あるから一番速いかと思ったけどnlより遅かった

>>60
GCC4.5.1 LTO

x264 binarys (x264_mp4_dts_compress_1.diff)
http://sada5.sakura.ne.jp/

(64bit) x264.win64.exe / flto, generic, fprofiled
(32bit) x264.win32.exe / flto, generic, fprofiled

>>61
バイナリ　 【binary】
http://e-words.jp/w/E38390E382A4E3838AE383AA.html

確かに
Cygwin binaries. ・・・Cygwin バイナリパッケージを提供しています．
とか書いてあるサイトも。

>>65
僕のミスｗ
binarys ×
binary ○

>>64
さっそくの対応ありがとうございます


テストしてみた所Phenom II X3では

GCC4.5.1系　>>60、おそロシア
GCC4.4.4系　nl、komisar

32bit,64bitバイナリ共にGCC4.5.1系の方が約3%程遅かったです
家のは4コア化出来ないので誰かX4で追検証お願いします

>>67
i7-965EX
win7 64bit
DDR3 6GB
の環境では

GCC4.4.4　nl、komisar　バイナリ
komisar版GCC4.4.4自前ビルド

32bit,64bitバイナリ共にkomisar版GCC4.5.1(LTO)ビルドの方が数%程早かった。

どのビルドでも大差ないので、好きなバイナリでエンコするのが一番だと思う

なるべくなら、GCCには余計なオプションを付けない方が無難ではある。

http://harmful.cat-v.org/software/GCC

そのうち、LLVM版バイナリとかも出てきそうな予感。

configureのオプションに--enable-lto追加パッチ
64bit時に-DPREFIX削除してるので4.5.1専用
ttp://www.privatepaste.com/9f440117ed

http://gimpo.2ch.net/test/read.cgi/av/1277739626/451


トルネの3倍AVCらしいｗ
DRと比べてもビットレート少ないから色が薄くなったりボケたりはしているけど
なかなか高画質じゃね？ｗ

いや、今WC見てるけど結構酷いぞ

便所

Seraphyのプログラム公開所に入れなくなってるね

x264のDTS compression（初期ディレイ）オプションパッチ
x264_mp4_dts_compression_sw_r1659.diff
ttp://resic.laburec.net/archives/2010_06.html#20100628a

>>73
これ、4Mbpsぐらいだろ？なかなかやるじゃんトルネｗ

今は忙しいようだけどSeraphyさんの貢献は忘れない
ありがとうSeraphy！

Seraphy先生の次回作にご期待ください

超Seraphyになって帰ってくると信じてる

x264guiの更新が不定期になる
↓
常に最新版を使いたいのでx264outを使い始める
↓
ini弄ったりavsでts読み込みさせたり色空間の劣化を考えたりしている内にAvisynthで良くね？と思い始める
↓
どうせ移行するならとAvisynth 64bitにする　　終わり

さようならSeraphy氏　君の活躍は忘れない

俺いま3番目

最近更新してないから、急ぎでアクセスしたい人がそれほど多いとは思えないが
なぜか関連スレで必死になってる奴が多い。

見ててすげえみっともねえ。

>>82
オプションいじるときはguiでやって、下の欄のコマンドを実行ファイルにコピペして使ってる

First Look: H.264 and VP8 Compared
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/First-Look-H.264-and-VP8-Compared-67266.aspx

>>86
>Codec: MainConcept H.264

ソースの品質も不明だし、スクリーンショットがJPEGだと言うのも良くない。

時間があったら、俺様が直々に比較してやるよｗ

ｷｬｰｵﾚｻﾏｶｯｺｲｰw

seraphyなにやってんだ？鯖落ちてるぞ馬鹿

seraphy氏の所、掲示板は荒れ放題だしモジュール更新も気まぐれ
仕事が多忙なんだろうけど、せめて月1ぐらいで更新して欲しいよなぁ

ボランティアでやってることに何求めてんだおまえら

--dts-comp Enable DTS compression

>>93
dtsのオンオフを併用するやつ居るのか？ｗ

>>94
オジちゃんは何を言っているの？

ニコ厨にとってdtsは敵

PS3

>>95
青二才には理解出来ないことだおｗｗ

>>96
だな

seraphy氏のサイト、閉鎖だってさ

お前ら必死杉
ttp://skm.vip2ch.com/-/hirame/hirame102585.jpg

seraphy版にこだわる理由ってなんかあるの？
ほかので代用できないようなことなのか？

auo

こまるのは、AVIutlつかってるやつくらいだろ

ニコニコのまとめサイトはどう対応するのか

afs

AQが

永久に

r1666
--bit-depth 10ってデコーダーはなに使えばいいんだ？　JM？

>>108
MainConcept

誰かseraphy氏の後を継ぐ者は居ないのか？
コマンドラインに無理やり転向せねばならぬ

- 終 了 -

aviutlのスレかとおもったぞ

つーかGUIのフリーのエンコーダーなんて探せばすぐでてくだろ
aviutlのプラグインがうんちゃら言いたいならこのスレでやるな

間違えてvfwスレに書いてしまったｗ

r-1666
10-bit encodingを追加してみた
http://sada5.sakura.ne.jp/

AviutlがGUI以外に対応するという手もあるが
Aviutlでauo以外で出力する方法はあるのか

VFW

つ コマンド実行 for AviUtl

x264 --output output input とするだけで使えるのだし、
この機会にAviUtlを止めて、CLIを試してみたら。

x264out.auo
……そろそろスレチかもな

さっぱりわかんね

コマンドラインはつい寝ぼけて打ち間違ったりするんだよorz

スクリプトで処理するだけなので間違えようがない

そのスクリプト変更部分を書くときに間違えるんだよ

俺は別にコマンドライン直で打ってもほどんど間違えんがな
間違えるというより慣れてないだけな気が

俺はコマンドラインだけど
セラピーたんの使ってた

GUIはその点クリックするだけだもんな
間違えようが無い

コマンドラインで打ち間違う人はGUIでもクリック忘れるんじゃねｗ
縁故に関してはCUIのがイージーミスが少ない気がする
とにかくGUIはスレチだね

どうしても、x264.exeのGUIフロントエンドが必要なら、ここでたくさん見つかる。

MPEG-4 Encoder GUIs
http://forum.doom9.org/forumdisplay.php?f=78

AviUtl+x264gui.auoは初心者のくだらない質問の防波堤の役目もしてるんだぜ

10bitかー。メリットとデメリットがわからんなぁ。

>>129
バンディングが出難く・・・なってたらいいな
と思いつつ、エンコ中な上に疲れてるんで今試す気が起きない
つか、土日に来てくれんと色々試せん・・・。

>Input is still 8-bit only; this will change in the future.

9, 10bitの入力は不可能な訳だし、今すぐに試す必要は無いだろう。

>>131
猫研見てきた
まだお試し機能っぽいね・・・バグ有りそうだし様子見するか

--profile high10
--qp 0-63
--crf 0-63
入力は8bitオンリー

fprofiledが死ぬほど重かった
使う人は、まずいないだろう

gradfun2dbmodより軽ければいいよ！

GradFun2DBmod([1.2〜1.9],temp=80,mask=false,radius=1,screenW=[xxxx],screenH=[xxxx])

映像ソースはもうこれだけにしてるわ、俺
頑張っても結局BDとか買っちゃえばいいだけだし
いや本末転倒とか言われると困っちゃうんだけどね

×映像ソース　→　放映ソース

x264が対応したところで、H.264 High 10 Profileの再生環境が、今後一般に普及するとも思えないし、
結局は、8bit+ditherで妥協しておくしかない。

screenW=[xxxx],screenH=[xxxx]
これはいらないだろ。

H.264 [email protected] Profileぐらいでいいよ。

一部のマニアしか再生できない高純度なプロファイルでエンコされても
マニア以外誰も得をしないから。誰にも配らず自分だけで楽しむだけなら
好きにすればいいけどさ。

配って問題ないようなデータって殆どないよな
またそれを要する場所もないよな

levelが4.1もあるのにprofile mainとか、どこのクソマカ用だよ

main4.1ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

Mainはないわー

確かにmainは無いわなｗ

はぁ？まいんちゃん可愛いだろ

俺はPSPと共用なのでまだmainでいいわ
つかAVCなんでソースはエンコ済だし

でも、PSPでは、まいんちゃん4.1は再生出来ない罠。
Main3.0ならともかく、4.1は意味がわからん。

>自分だけで楽しむだけなら好きにすればいい
まさにその典型的な例ですねｗ

seraphyなに勝手にサイト閉鎖してんだ？死ねカス

[email protected]

3Dアニメはでてこないのかな
level5とかの試してみたいわ

下からのぞけない3Dとか

>>150
SDなら　[email protected]
HDでは　[email protected]
もうこれでいい・・・

LEVEL-Cの３Dアニメと聞いて

SDなら720x480 [email protected]だな
一応BDの規格に合わせて

3Dアニメってクローンウォーズみたいなアニメかお

ここの人々は何をエンコしてどんなモニターで見ているのか知りたくなった

安いTNに決まってんだろ！
言わせんなよ恥ずかしい！！＼＼＼

HYNDAIのIPSです（ｷﾘｯ

NECのIPSです（ｷﾘｯ

MITSUBISHIのA-MVAです（ｷﾘｯ

WQXGA(2560×1600)の29.8インチだけど色々言われるEIZOだよ

まぁ、日立のスーパーIPS液晶にはかなうまい

SONYのFDトリニトロンです（ｷﾘｯ

Sony LMD-2050Wです。

一応HDはDVDレコでプロフィール16x9で
バラエティというか教養ものや資料ものはHD→SDでエンコ。
画質なんてどうでもいいとはいえPSPサイズの480x270だとPCで見るにはちとキツイから。

↑間違えたよ
146ね

と書いてみたもののプロフィールはこのところ全然使ってなくて
リップしたものをPCで見てるのが多い。
液晶テレビすら持ってないのでリアルタイムで見るときはPCに付いてるTVチューナーのみだ。

Another HTML-lint gateway
http://htmllint.itc.keio.ac.jp/htmllint/htmllint.html

x86_64のMP4Boxビルドがうまくいかない
./configure --cpu=x86_64 --static-mp4box --prefix="/mingw/x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"
↓
./configure: line 293: cc: command not found
which: /mingw/x86_64-pc-mingw32/bin/jpeg-config: unknown command
which: wx-config: unknown command
which: sdl-config: unknown command

** System Configuration
Install prefix: /mingw/x86_64-pc-mingw32
Source path: /home/Sexy/gpac
C compiler: x86_64-pc-mingw32-gcc
make: make
CPU: x86
Big Endian: no

--cpu=x86_64を外すと”./configure: line 293: cc: command not found”がでなくなる
CPU: x86がx86_64にならない

>>170
たしか今年の4月あたりの更新以降、windows(msys/cygwin+mingw)での64bitコンパイルは
現状のconfigureのままでは出来なくなってる
自分ではどうしたものかわからんかったので、golgol7777氏に泣きついて彼がやってるgitのほうに
修正を入れてもらった
http://github.com/golgol7777/gpac

./configure --prefix=/mingw/x86_64-pc-mingw --cross_prefix=x86_64-pc-mingw32\
--cc=x86_64-pc-mingw32-gcc --cpu=x86_64 --static-mp4box --strip

これでいける

セラフィーどうしてしまったんだ…。
mp4cat取りに行ったらHP入れなかった。
誰か最新版持ってないですか？

原油の流出を止めにいったらしい

勝手に配布するわけないだろ

>>172
持ってるよ

>>172
>>99

>>171
レス有難うございます。

komisar版
cross-mingw.gcc451.generic.20100626.7z (46M)
::i686-pc-mingw32/x86_64-pc-mingw32::
mingw runtime version 3.18
w32api version 3.14
GNU Binutils 2.20.51.20100626
gcc version 4.5.1 20100626 (prerelease)
zlib-1.2.3
bzip2-1.0.5
pthreads 2.9.0.0 GC-static (upd. 2010-06 not need -lws2_32)
mingw-w64/mingw-w64-headers Rev: 2646
mingw-w64/mingw-w64-crt Rev: 2649
でビルドしてるのですが

git clone git://github.com/golgol7777/gpac.git
cd gpac
./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --cc=x86_64-pc-mingw32-gcc --cpu=x86_64 --strip --static-mp4box
↓
./configure: line 293: cc: command not found
error: zlib not found on system or in local libs
となってしまいます。

>>176
デマひろめてんじゃねえよカス

>>171
git clone git://github.com/golgol7777/gpac.git
cd gpac
./configure --prefix=/mingw/x86_64-pc-mingw32 --cross_prefix=x86_64-pc-mingw32\ --cc=x86_64-pc-mingw32-gcc --cpu=x86_64 --static-mp4box --strip
↓
./configure: line 293: cc: command not found
which: freetype-config: unknown command
which: wx-config: unknown command
which: sdl-config: unknown command

** System Configuration
Install prefix: /mingw/x86_64-pc-mingw32
Source path: /home/Sexy/gpac
C compiler: gcc
make: make
CPU: x86
Big Endian: no

--cross_prefix=x86_64-pc-mingw32-　これだと　error: zlib not found on system or in local libs出たので
--cross_prefix=x86_64-pc-mingw32\　にしたら　error: zlib not found・・・がなくなりました
が・・・./configure: line 293: cc: command not foundが消えないorz

zlibが入っていないんだろ。エラーメッセージぐらい読んで出なおせ

>>179
もしkomisar氏のcross-mingw使ってるなら、configureの293行目の
canon_arch="`cc -dumpmachine | sed -e 's,\([^-]*\)-.*,\1,'`"　を
canon_arch="`$cc -dumpmachine | sed -e 's,\([^-]*\)-.*,\1,'`"に変えて（ccを$ccに書き換える）
./configure --prefix=/mingw/x86_64-pc-mingw32 --cc=x86_64-pc-mingw32-gcc --cpu=x86_64
でやってみて（--cross_prefixはなしで）
おそらくビルドできるはず

gpacのconfigureはクロスコンパイル関連で、いろいろ無茶苦茶なので
直さなければならないところが多いみたいなの

>>181
おかげ様でconfigureは無事通りました。
今度はmakeで
略)・・・・・
laser_dec.c:1:0: warning: -fPIC ignored for target (all code is position independent)
が出たのでconfigureの1866,1867行目の
CFLAGS="$CFLAGS -fPIC -DPIC"
CPPFLAGS="$CPPFLAGS -fPIC -DPIC"
↓
CFLAGS="$CFLAGS -DPIC"
CPPFLAGS="$CPPFLAGS -DPIC"
（-fPICを削除)
でmake lib appsできました。

色々と詳しく説明して頂き、ありがとうございました。

r1163から脱出できないな

せらひー鯖復活ありがとうございます
最新版も気長に待ちます

おお、ほんとだ復活おつ。

64ｂｉｔ warpsharpも頼んます！

ビルドできないとか馬鹿うざいんだけど。
コード読めない馬鹿は芯でください。

釣りはよそでやれ

鯖落ちてんじゃん。

test

Announcing commercial licensing for x264
http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html

x264を使ったバージョンを最初に出すのは、どの商用ソフトになるのだろうか。

r1666だとシーンの切り替わりに画面が乱れることがる
r1659だと正常に表示される。バグかなぁ。

あ、俺も時々おかしなフレームが入るなと思ったらr1666のせいだったのかな？

気になったのでr1666テストしてみたけど特に乱れたりとかはなかったなぁ。
使用したソースは実写なのでアニメだとわからないけど。

DXVAで再生すると稀に乱れちゃうってのはかなり前のバージョンからあるけど
これはDXVAの方が悪いと思ってるので無視してる。

aviutlでmp4読み込んで確認してもやっぱりおかしなフレームが入ってたよ。
本当にごくたまに起きるのでテストで確認するのは難しい。

サンプルもない、SSもない、デコーダー等に関する情報もない
まったく役に立たない屑情報だな

>>194
Haali+最新のffms2で確認キボンヌ。あと、再現する動画をうpキボンヌ(mediafire等)。
mkvmergeguiやmp4boxで再現できるところをカットできるし。

あと、使用したコマンドラインを貼ってみ。こっちは何回も色々エンコしたことあるけど、問題はないからねぇ。

SS
http://a.imageshack.us/img130/4344/20100714234209.png

>>191
SSでとりあえずどんな感じでデコーダーで変になってるかちょっとは理解したけど、
とりあえずサンプルを(ry。ffms2でのチェックはこっち側でも出来るから。

あとは設定を（ry

tmpgを彷彿とさせるね

問題報告用のテンプレか何かあったほうがいいんじゃね？と思って書いてみたけどこんなもんでいいかな？
使われないかもしれんけど、足りないとこあったら補足を。

■現象
　　●説明
　　●スクリーンショット
　　●動画サンプル

■エンコード情報
　　●x264のバージョン
　　●x264のコマンド設定
　　●Mux方法
　　●作成したファイルのMediaInfo情報

■デコード情報
　　●再生に使ったアプリケーション
　　●スプリッター
　　●デコーダー
　　●AviUtlを使って何かを確認した場合は読み込ませ方
　　　　（メニューの「その他→ファイル情報」の内容を書く。
　　　　　MP4Pluginを使っているとかDirect Show File Readerを使っているとか。）

自作板とかを見てると、エンコード用PCでOCしてるという、
アレな人が結構いるからなあ。

ウチはOCしとるよ
特に問題無い
エンコ用PCはOCしたらダメだと盲目的に言うアレな人もいるがｗ

>>197
うちでは今の所起きてないな
OpenGOPの関係だろうか？

OCが、限界ギリギリでメモリエラー吐きまくるまでぶん回すのばっかりだとでも思ってるんかな
そんなのただのOC失敗だろう

ずっとOCでエンコしてるけどなんかまずいのか？
ここ数年では[email protected]、i7 [email protected]、[email protected]、[email protected]だな

電圧昇降OCは電力効率が猛烈に悪化してもったいないや
エンコード用PCは時間掛かっていいんで電圧下げて微OCしてる

時間かかっていいならそもそもエンコ機のOCなんかしないよ
プチOCじゃあまり変わらないしほとんど意味がないと思ってる
でもPCが不安定になるほどギリギリに詰めるのもバカらしい

価値観の押し付けあいは終わったか？

価値観の押し付け？
単に情弱の分際で煽った>>201がフルボッコなだけだべ

r1673来てるよ
それらしい修正も入ってるからテストよろしく

r1673
resizerのおかげで携帯機器用再エンコが楽になったな
インタレ解除用にyadifと、GSoCのaudio encodingが追加されればさらに便利になる

r1673でエンコードしたら直ってた。
ソースはハイスクールミュージカル[BD]の45秒前後。

r1659 OK
r1666 NG
r1673 OK

と思ったら、r1673でも駄目だった。
デコーダーがffdshow3512、MPC-Homecinema1.3.2121.0の内蔵フィルタだと正常に表示されるけど
CoreAVC2.0、PowerDVD10、PS3だとおかしくなる

だからバグ報告したいならサンプル出せよ
エンコーダーが悪いのかデコーダーが悪いのかさっぱりわからん
出したくない（出せない）なら、うざいだけだから黙ってろ

>>212-213
検証報告は素晴らしいことだと思うけど、せっかくなんで>>200みたいな情報も書いてもらえるといいな。
特定のパラメータ設定で発症する問題なのかもしれないから、なるべく細かく
ちゃんとした情報を出さないと、問題解決には結びつきづらいのではないかと思う、

おもいっきりDXVA絡みの問題なんじゃないの。
PS3もアップデートでそのうち直るだろ。

パラメーターみせてよ。

1660以降にopen-gop関連とNAL関連つついてるっぽいからその辺かも知れんけど
パラメータも出さないとか独り言過ぎる

OpenGOP有りだと正常に表示されて、OpenGOP無しだと画面が崩れるようだ（r1660以降）

x264 --bitrate 6000 --preset medium --ref 4 --subme 9 --direct auto --trellis 0
--me umh --b-adapt 2 --bframes 4 --threads auto --thread-input --tune film --sar 1:1

--open-gop none ← NG
--open-gop normal ← OK
--open-gop bluray ←OK

r1674

>>219
Bフレを3じゃなく4にしてるせいでopen-gop使わないと駄目な悪寒

r1675

bframes 3にしたら解決しますた
アドバイスくれた人たちありがとう

OpenGOPとbフレ数って関係あったの？

r1677

俺も>>224が知りたい。

ttp://www.marumo.ne.jp/db2002_c.htm
ここ見てみ

r1677はよさげね

--open-gopとBフレの数って解像度関係なく3と4が区切りなの？
だとしたら最近作ったSDのやつとか全然チェックしてないがやばいのかな？

>>229
BD規準のHD動画は3までしか使えないんじゃなかったっけ？
で、基本的にBD再生用に作られてるハードデコーダだと不具合出るんじゃないかね
あと、バージョンによってBフレームの挿入規準も微妙に違うから
最近のバージョンだと積極的にBフレーム挿入して4つ目が入ると画面が崩れてたとか
SDは良く知らない

>>230
ども、よく考えたら俺Bフレ4以上にする事無かったわ。SDでふやしてるのはrefだった。
一応チェックしてるが全然問題無いわ、まあBフレ3以下だし。

キャプチャしたPS3のゲーム動画x264であれこれエンコしてみたけど
予想してたよりもあんま縮まなくて残念
2Dのゲームとかならアニメみたいに縮むのだろうか

>>227
ごめん。読んだけどbフレ数とOpenGOPの関係わからないorz
ハードウェア使って再生する場合に扱えるBフレ数の制限からOpenGOPにしないとダメってこと？

意味がわからない・・・
OpenGOPをnoneにした場合はBフレームは3より増やしたらだめってことなのか？
それじゃOpenGOPが導入される前のリビジョンのx264でBフレーム3以上にしたやつ全部だめってことになるじゃん

×Bフレーム3以上にしたやつ全部だめ
○Bフレーム3より多いやつ全部だめ

r1659以前のx264ならOpen-GOPを使って無くても大丈夫みたいよ>>212
Open-GOP自体1657あたりでコミットされたみたいだから、結局>>230が正解？

OpenGOP使うデメリットってある？

まあ同ビットレートならSSIMとかは低下するだろうな

普通に--preset veryslow（Bフレ8）でopenGOPなしで数本エンコしてみたがさっぱり再現しない
Doom9にもDoom10にも#x264にもBフレ4でダメになるとかいう話題も出ていない

>>239
そりゃ再生環境が狭くなるとは言え、x264の動画としては問題無い訳で・・・
>>213に出てるような再生環境でないと問題がでないだろうし

BDでのBフレの話なら猫研か下記スレで
http://forum.doom9.org/showthread.php?t=152403

その検証した動画はBフレ4以上使われてる？
いくら設定値大きくしてもソースによっては3以内に収まってる可能性も・・・。
100%再現するにもシーンチェンジやBフレームの入るタイミングなんかでフレーム間予測失敗する
レアな問題の可能性も有るだろうし。
問題の動画が有れば簡単だが、さすがに著作物のソース上げろとは言えん罠

>>240
>その検証した動画はBフレ4以上使われてる？
ちゃんと使われてるよ
http://privatepaste.com/a4270e3ca8

>問題の動画が有れば簡単だが、さすがに著作物のソース上げろとは言えん罠
そうか？
weightpがコミットされたときは、問題が出てる30秒程度のサンプル使ってここで検証してたぞ
ひとつはDVDソースで、もうひとつはTSソースだったが、何か問題が起こったのか？

p2pも最初は問題なかった・・・
と言いたい所だけど30秒くらいなら大丈夫じゃね？＾‐＾
ぼくとか他人事なんで全然おっけーと思います

問題の無いソースってなかなかないよな。
CMくらいか。

>>243
このご時世、CMですらアウトだったり……orz
完全フリーで配布されている映像ぐらいかしらん？

>>241
映画は権利関係煩いし
ましてやソースがBDのリップと成ると更に色々と
今のご時勢じゃうｐするには腰が重かろうよ

DL板の奴ら焚きつけとけ

ダウソ代表のVFRmaniacの出番だな

この場合は引用や研究目的に該当するから、
数秒から数十秒程度のサンプル使用は問題ないんじゃ？

>>238
--keyint 24だと、明らかにopen-gop有りの方がSSIMは良くなる。
デフォルトの250だと、誤差の範囲になるが。

HDな番組宣伝あたりならギリギリか
全国放送に限るだろうけど

普通にカムコーダで撮った映像をアプすりゃよくね
なんでテレビ放送をソースにしようと思うんだ

自分で映像が撮れないからだろ

ここにあるy4mは再配布が可能で、4:2:0の物はそのままx264の入力に使える。
http://media.xiph.org/video/derf/

x264_filters hqdn3d, yadif, pad
http://pastebin.org/402005

x86_64ビルドに成功した方いる？

>>250
ギリアウトだな

henryさんのx264の更新が途絶えてる。

>250
放送物、著作物に関しては、基本的に全てアウトだよ。
安全なのは著作権フリーぐらい。

報道や研究目的で一部ＵＰおｋだよ

>>256
遅くなってすみません。更新しました。

Full-HDいけるデジカメ & 三脚で撮ったらいいんでね？

確かcodec評価用の動画素材とかあったでしょ。
HDでなくてもavisynthで適当に拡大すりゃいいんだし。

r1680

GPU対応まだ？

GPU対応なんてしない、する意味がないって見解Doomで言ってなかったか？

そうなの？そういうこと言ってるとその内に他のに食われるよね。

GPUは浮動小数点演算器のかたまり
H.264は整数演算しか使わない
GPUはエンコードに向いてないんだよ

そういうこと言ってるとその内に他のに食われるよね。
そういうこと言ってるとその内に他のに食われるよね。
そういうこと言ってるとその内に他のに食われるよね。

俺がx264を喰う

他のって例えば何だ。

http://github.com/cancan101/h.264-cuda

動き補償だけでも、実装は非常に難しいとあるな。
http://wiki.videolan.org/SoC_x264_2010#GPU_motion_estimation

MEは動き予測とか訳すのが普通だろう
動き補償はMCでMEはMCの基礎技術

>>272
確かにその通りだ。訂正ありがとう。

おはよ＾＾

r1681

そうなの？そういうこと言ってるとその内に他のに食われるよね。

お前が食われちまえ

おそロシアは夏休みか

おはよ＾＾

低脳情弱w
http://denjipa.blog49.fc2.com/blog-entry-199.html

>>280
もしかしたら世の中こういう人間のほうが多いのかもしれないぜ……？
規格で定められてるのは復号の仕方だけだってのに、勘違いしてたりな

にしても情弱のくせにブログで他人に情報提供してますヅラしてるのは痛いw

>>280
すごいな、つっこみどころが満載で的がしぼれない

符号化も規格で定められてるぜ。画質、データ量、処理時間がトレードオフになってて、
時間が無限にある訳ではない状態でどのへんを落としどころにするかを考えているとか
思いもしないだけだろう。

1年近くも前の記事につっこんであげるなよ
残してあるだけいいじゃないか


というが、市販されてるエンコーダーを購入する層がx264ないし、AvisynthやAVIutlを導入してエンコードすることに関しては、
すべての面において大きな隔たりがあるのは今でもyesとしかいえないんだから、こういう飛び込んでみようとしてる記事はこれでいいんだと思うよ

"彼がx2654を使わないことに決めた"ってのは
彼にとって正しい(かれが不幸にならずに済む)判断だから、これでいいのだw

取りあえずエンコーダーの糞画質対策に
フィルターかけまくるって発想がアニヲタらしいとオモタｗ

アニヲタに偏見は無いけど
こーゆーの見ると気持ち悪いと思う

TmpgのGUIってとっつきやすいけど使いにくくね？AviSynth万歳！

30分アニメとかならCMの位置はだいたい分かってるからaviutlでのTrim作業もあまり苦では無いけどな。
金曜ロードショーとかだとキツい。

とっつきやすい。しかしでかい。（大作りともいう）
ファイル追加の時に出るダイアログなんか無駄にでかい。
なんで追加OKするのに画面一杯のダイアログのはじっこを
クリックする必要があるのかと。

ｒ1683

r1670〜81までのx264で、2passでエンコしたファイルがTimecode入れようとすると必ずエラーでるのは気のせいじゃなかったのか
直ってるといいな('A`)

>>Broke 2-pass with MB-tree when calling from compilers with broken stack alignment (e.g. MSVC).

GPU対応まだか？

そういうこと言ってるとその内に他のに食われるよね。
そういうこと言ってるとその内に他のに食われるよね。
そういうこと言ってるとその内に他のに食われるよね。

GPUに夢見てる奴っていつ醒めるんだろう。

最近やっとmkvの良さに気付いた

>>294
猛暑でグラボが焼けたらかな

>>295
ようこそ

>>295
ここへ〜♪

>>295
A．クッククック♪
B．遊ぼうよパラダイス♪
C．うわさのロックンロール♪

どちらに進みますか？

うわぁ！マジんぱねぇ年齢層で成り立ってんだなエンコの世界

GPUが整数演算が苦手と思ってる馬鹿ってなんなの？
アホみたいに並列処理できるからH264でも爆速エンコードできるよ。
他のエンコソフト見れば明らか。

で、ハイパーミラクル超絶技巧爆速GPUエンコまだ？

実際GPU使ってるエンコーダって何があるの？

GPUエンコ信者とNV信者には同じにほいがする

CUDAらねぇ

>305
審議して欲しいのか?して欲しくないのか?
この、いやしんぼめっ!

DGDecodeNVやFFT3DGPUは便利。

>>303
http://www.badaboomit.com/

ただ、Apple H.264やXvidに負けてしまっているのは、何ともいえない。
http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png

>>301
"H264"のエンコ速度が上がっても意味無いってのをいい加減気が付つかんのか？
例えば、東芝の勘違いボードとかな。
というか、 x264のスレでAvisynthのGPUプラグイン以外、CUDAとかの話題が殆どでない意味理解しようよ

TMPG(藁)じゃ？

>>308
エンコ速度が上がって意味がないってさっぱり意味分からん。

GPUエンコードを使って、x264並の品質の物をエンコードできるようになったら同じ土俵に立てる
けど現状のGPUエンコードの品質は、ファイルサイズ度外視のビットレート過剰ファイル作成マシーンでしかない

勿論それを改善しようとしている人も（というか企業）いるけど、
導入までがとんでもないことになってるからな
GPUじゃなくてもPS3つかったシステムのやつもな

うーん、自分の言い方も悪いな


要するに、汎用性に乏しい現状じゃやはり厳しいんじゃないかっていう
俺の意見

crf20程度の画質が同等ビットレートでGPUエンコできるならそれに越したことは無いが
何時の話に成るやら・・・。

同等はなかなか難しいだろうけどDivX位にはなってほしい

とりあえず処理の一部にOpenCL使ってみようとしている人は#x264devに何人かいる
3日くらい前にはNVIDIAの社員が「質問あるなら大歓迎」って挨拶に来てた

アセンブラ叩かせろって言ったらNVは「お断りします」って返すだけだし
NDA結ぶなら考えてやっても言いとかありえないし
そらCUDAで開発なんか進むわけがない

>>310
速けりゃ画質とかどうでもいいってんならハードウェアエンコでもやってれば？
少なくともここにはそんな人いないし
根本的に何もわかってないみたいだからまず勉強してから出直すといいよ

>>317
GPU使った並列化による最適化で画質が変わるとかどんだけ妄想入ってるんだよw
画質が落ちるのと、ハードウェアエンコだからというのはなんら関係ないし。
コード書けない文系の発想だろ。

ID:qkfpg+bv
欲しいならお前が作ればいいだろ低脳
理屈ばかりこねて自分では何も出来ない馬鹿の癖に

OpenCLって去年くらいまではそこそこ盛んにいろんな人が興味もって
いろんなpostしてた記憶があるけど今はなんかひっそりしてる感じ
まぁおれが現在全く興味持ってないからだろうけど

毎度毎度のこの論争に終止符をうてるのがララビーだったわけだが・・・消えちゃったからねぇ ＾＾；
現状のリソースでもGPGPU仕様のエンコーダーで、x264の画質的に匹敵しなおかつ爆速なものができるかもしれないけど
それにはGPUを決め打ちしてさらにまったく1からアルゴリズムを考え直さないと駄目だろうから
x264のようにコンシューマーがフリーで使えるようなエンコーダーの実現はそうとう難しいだろうな
エンタープライズ向けのh.264エンコーダーでGPGPUを利用するものはそのうち出てくるだろうけどね

H.264の効率(画質)はたくさんあるツールやモードを適切に使い分けてこそ発揮できるけど、
GPUやハードウェアにとってそういう「条件判断」「臨機応変な処理変更」は
CPUに比べてそれほど得意な分野じゃないのよね

逆に大量のデータに同一処理をするのは大得意なので、
やっぱGPUはエンコーダよりもフィルタ向きじゃないかな

>>318
頭大丈夫か？話の流れ100回くらい読み直せよ
自分で話ズレてることも理解出来ないのか
お前はまず知識以前に読解力身につけたほうがいいｗ

誰かぁんｃぞｓのあヴぃうｔｌ用のｇぷフィルタ作ってくれよ
どうせならアセンブラで

GPUエンコに希望がないとは言わないがx264が1600回以上も更新を続けて
未だに課題が山積みなのにほぼ1から開発になるGPUを利用するエンコーダーを
本気で取り組もうとする人がどれだけいるのかっていう話だ。
せいぜい処理の一部をGPUが補助する的な役割が精一杯だろう

実装が面倒臭い割にCPU,GPU共に待ち時間があるから
トータルで対して速くならないからそれも否定されてるんだけどな

処理の一部をGPUにというのはPCI-Eｘが遅すぎて話にならない

Ｌlanoあたりが一般的になれば転送の待ち時間はなくなるのかな。
OpenCL実装で・・・と思ったけど遅そうだし元々AMDでしか使えないから
AMD CALとILで作れば早くはなりそうだ。ニッチすぎて作る人いないだろうけど。

CPUに統合されたって所詮はGPUでしょ
遅くて小回りの効かない演算器がたくさんあったって、それ全部を使い切れるような処理はそう多くない
アムダールの法則ってのがあってだな・・
GPUの代わりにCPUコア積んだほうが良いだろうね

CPU積むのがいいってのはわかるけどGPU内蔵CPUのほうが最上位CPUより安いならお得かな程度に考えてもらえれば。
CPUの進化だけだとロマンがないんだもの・・・

エンコードもグラフィック関係の演算だから（ちょっと違うかもしれんけど）、
GPUのように急速に発達してくれれば、
もしくは今あるGPUが使えれば、
と夢想してしまうのは分かる。

電気も場所も食う割に熱ばかり出してあまり効率よく処理してくれない感じ

PC絡みのパーツそんなんばっかだからな
例外では無いよね…

1600回ほど改良を重ねたx264にまだ残っている主な課題、あるいは致命的なバグというとなんだろう？

致命的なバグがあるなんて誰が言ったんだよ

言い回しが格好いいと思って意味もわからず書いたんじゃね

>>334
他がサポートしていてx264には無い機能なら、DSが自分ではやりたがらないMBAFF等が残っているな。

http://wiki.videolan.org/SoC_x264_2010

x264はインターレース周りは後手後手に回っているからなぁ。
なんせ、パッチなしでまともなインターレースエンコが出来るように
なったのすら、この半年のことだし。

GPUで10倍速エンコまだ？

止めないからやりたきゃやれよ

ひゃはー加速するぜ

コッペリオン乙

ありゃ久しぶりにアップデートしたら--aq-metricなくなってるのね。

どんだけ久しぶりなんだよｗ

--gpu-x10

--cpu-x12 --gpu-x4だと思う

r1163から抜けられないな

--colormatrix で、HD解像度の場合はbt709,smpte240mが選べるけ何が違うんだ？

>>348
SMPTE 240MはアナログHDTV用で、通常はBT.709を選ぶ。

>>349
そうなのか。ありがとう。

ｒ1688
3人目の日本人はgolgol7777氏か
本名ではなくnickなのが浮いてるｗ

韓国の企業が、
「x264はウチの特許を侵害したニダ。
だから、x264でエンコされた動画や使用ユーザーを取り締まるニダ」
って喚いてます。

ttp://blog.kippler.com/69

翻訳してくれ

>>353
http://goo.gl/F1hm

韓国以外で有効な特許だとは思えないし、韓国在住の人以外にとってはどうでもよいな。

GPU対応まだかよ

　　　　　 　 　 　 　 　 　 　 ,　　　　　　　　　　　　　　 　 　 　 　 　 　 ｝
　　　　　　　　　　　　　 　 / ト､　　　　　 　 ∧　　 　 　 　 　 　 　 　 /
　　　 　 　 　 　 　 　 （（　ｌ　ト ､ヽ 　 （（　 / ,ﾊ　　　　　　　　 　 　 __[_
　　　　　　　　　　　　　　││　'vﾊ 　　／ ./　ﾟ, 　 　 　 　 　 　 ,'⌒┴⌒',
　　　　　　　　　　　 　 　 ｌ. │ 　j斗‐=¬=ん .._〉　　　　　（（　　{　　　　　}
　　　　　　　　 　 　 　 　 l　 | ／　 　 　 　 　 　 ` ､　 　 　 　 　 ヽ.　　　ノ
　　　　　　　　　 　 　 　 ﾉ　 l′,　ｌ 　 　 ト､　､ 、、 ＼　　　　　　　｀￣´
　　　　　　　　　　　　　/ 　 ′│ |　│|│ |_｣ＬLﾊ　 　．
　　そ、そんな　 　 　 ′ / 　 仆Tﾌ丁｢ﾘ　!,从从∧ 　 ，
　　　 　 　餌で 　 　 { 　 i　　 从,rヤ卞.　 　仄Y{　} } } }
　　　 　 　 　 　 　 　 l　　|　　　〈 Ｖ'ﾟY} 　 　 ∨八,刈 jﾉ
.　　　　　　　　 　 /{　ｌ 　 l 　 　 ﾍ.`ｰ'ﾟ　 _　┐ っ从 　　　　わっちが釣れると思うたか？
　　　　　 　 　 /{/　ﾚ |　　、 　　　とつ　|　_ｿ r-仆 ヽ 　　　　
　　　　　　　,〃 ′ （. | 　 　 、　　 ヾ≧=y-rくト┤ 　 ＼
　　　　　　,ｲ　　　　　ｿ　　　　＼　　 ヾ,ミ辷メj_ノ : ト 、 ) 　　つ、釣られ･･･
　　　（（　 ｌ　　 /しｨ'/ 　, ,　 　 　>､　　 '．| 　|　〉 i |　 )'′
　　　　 　 |　, "　　｛ 　ｲ ﾊ,　 ／ ／ﾍ, 　} |＿ﾚ'入リ　ﾉ
　　　　 　 ∨　　　　Ｖ＾j/　V⌒Ｖ'ヽﾉハ,ﾉ┴=彡、 `Y´
.　　　 　 　 ヽ. 　 　 　 　 　 `ｰ'′__/　　 |　　　彡､人
　　　　　　 　 ＼ 　 　 　 　 　 　 /〈　 　 ′　　　　｝ ｝
　　　　　　　　　 `ｰ　 -- -　=ｧｧﾍ八__/　　　　 _,ノ ,ﾉ
　　　　　　　　　　 　 　 　 　◎′ ∨　`^^'ｰ'＾" _.ィﾟ
　　　　　　　　　　　　　　　 　 　 　 `7^^7^ｰ'^'く_彡、
　　　　　　　　　　　　　　　　　　　　辷彡　　　　`ｰ'′
　　　　　　　　　　　　　　　　　　　 〈__/

>>353

ニダスミダ！
アイゴー！ウリナラマンセー！

何か新しいの来てる。L-SMASHってなんだ？
ttp://bbs.fushizen.eu/viewtopic.php?f=3&t=5&sid=59b2ba31db6020000fb4d23df24db0c6#p22

>>359
http://bbs.fushizen.eu/viewtopic.php?f=7&t=11

>>359
x264のGPACに代わるもの
次世代mp4muxer

mp4boxみたいなのでんの？

>>362
時期にテスト用にもでもmuxerアプリが出るんじゃないかな。今はライブラリになってるというか、x264を使用してものを出力するようなソースになってるよねぇ。

GPACではなくL-SMASHを使うメリットはなんなの？

x264のビルドが楽になる
GPACは腐ってる

1．GPACをビルドしないですむ（例えばGPACのconfigureを眺めれば無茶苦茶なのがすぐわかる）
2．GPACを使わないから、GPAC側の変更に付き合わなくてすむ（例：ｒ1486）
3．libgpacに含まれる必要のない機能を削除出来るから、x264.exeのバイナリサイズが小さくなる
4．逆にGPACが実装していない機能をx264のほうで追加できる

gpacのビルドやバグに悩まされることがなくなるってことだな

doom9でもLSMASH使ったほうが再生がまともになったケースが出てる
http://forum.doom9.org/showthread.php?t=155705&highlight=L-SMASH
これはbaseline profileの話みたいだからそれほどインパクトはないけど

海外ではPC用のコンテナとしてはmkvのほうがメジャーだからmp4は軽視されがち
LSMASHの開発者が日本人なのも俺らにとっては利益だろう

移転テスト

test

コードいじろうとしたら、量子化マトリックスって１pictureに一個なのか・・・
量子化マトリックス使った場合のデブロッキングをどうしたらいいのか悩みところ

ひさびさ映画1本エンコ終了やっぱそれなりにグレイン残そうとすると
8GB必要だな。思い入れが無ければグレインきちゃなくなるの覚悟で
もっと縮められるんだが…

でもスカパーHDのシネフィルイマジカHD、ビットレート高くないのに
グレインありまくりの映画でもうまくグレイン残せてるしバンディングも気にならないな。
なんでだろ

業務用のH264エンコーダって数百万するんだぞ・・・

とりあえずエンコ前のソースを用意できなけりゃ、比べることが出来ないだろ
元がmpeg2とかBD用の贅肉たっぷりエンコならともかく、放送用にエンコされたH.264なら
元より膨らんでもおかしくはない

>>371
もうグレイン諦めてエンコして再生時にffdshowとかの
グレインフィルターで妥協しちゃえw

コミットこないなー
また溜め込んでんのかな？ｗ

おそロシア働け

>>373
数百万って事はないだろ、ハード入れたら数千万はする

最近来ないな。
いきなりr1700かな次は。

スカパーって画質もまあまあだし、結構縮んでるよな。
時間帯にもよるが、この前、11分で500MB位だった。
6Mbpsくらいか。
これをリアルタイムでやってるんだからなあ。
俺も一台欲しいよ。ホント

アニオタには不評だが、確かに映画チャンネルとかは
よくこのビットレートでここまでディテール保持できてるなって関心する

チャンネルによってビットレートが違う

角度とか

前回のコミットからそろそろもう半月よ！
なにやってんのD_S氏！

ワープは良いけどその間の軌道レールはどうなってんだという疑問

と言う誤爆

999特番乙

ｊｈ

フェードインしてきた静止画が破綻する事が多いのはどうすりゃ良いんだろ
フェードアウトの方はI→Pって順番になるから良いんだが、フェードイン時のP→Iって順番が癖が強すぎる

>>389
その部分だけ別エンコにして、--qpfileを使う。

scenecutの値はどうなんだろう

rc-lookaheadを50から60にしてみたら、全体323MBの24分アニメで750KB増えた
2回やって同じような結果になったから誤差では無いと思うんだけどなんでだろ

セラフィー使いはどうすればいいですか？

デスマ終了待ち

>>384
vp8エンコーダをx264に組み込むそうです。その作業で忙しいんです。

>>395
誰得

え？もしかして次の大量コミット時にxvp8もコミットされるの？
他の済ませてからにしてくださいｗ

vp8なんて別にすりゃいいじゃない？

mkvだとダメなの？

先にx264完成させてからにしろよな、他のに対応させるとかは。
先にやることあるだろ。

GSoCの案件以外でやることって何だ？

まず使わないであろうVP8エンコード機能なんか付けて
(VP8スレによれば20%程度の変更でとりあえず動くらしいが)変なバグが入らないか心配。

特に魅力も感じないし必要性も無いけどD_S氏なりの考えなんだろうね･･･例のバイトか?

.webmがらみだろう。

頑張って作ればgoogleさんから金もらえるの？

その手のはffmpegに任せておけばいいと思うんだ

r1698
コミットのうち3件が日本人か、いい感じだ

MPC-HCとffdshowは来るけどx264がなかなか来ないなおそロシア

golgol7777氏は何度見てもおもしろいｗ
どうせならnick変えればよかったのにｗ

スレ違いかもしれないが何処に書くか迷うし
これ使う人は最終的にx264通すと思うのでとりあえずここに書いとく

DGAVCDecDI build 2001
http://forum.doom9.org/showthread.php?t=156238

>>409
要約をよろ

>>410
（　｀Д）＜α版だけどきちんと金払えよな！

今更ながらAvisynthスレの方に書いた方がよかったのかなと思ったｗ
ちゃんと動いてx64のdllも作ってくれるなら金払ってもいいかな

そもそも何をする物なのか分からない。
AVCのデコーダか？

CUDAの代わりにDiAVCというデコーダを利用するフレームサーバ。
以前ライセンス違反で公開停止になったDGAVCDecの後継なんだろう。
BD ripかビデオ撮影した素材に対してくらいしか使わんだろうけど

>>409
こっちがてきとうじゃなかろうか
DVD2AVI DGMPGDec Part3
http://hibari.2ch.net/test/read.cgi/avi/1207730492/l50

>>414
なるほどフレームサーバーなのか。
プロジェクト名称からは全然分からんなぁ。

やっとロシア復活
x264 Video Codec rev. 1698 x86/x64 18.08.2010

最適化版ないじゃん

いまだに1163から抜けられねぇ・・・

なぜに1163に固執するんだ

突っ込んだら自動的に次へ次へと処理するソフトを書いたのは良かったが
更新するのが面倒→更新しなくていいや　とこうなったのです

1個目の更新：処理する自前のソフト
2個目の更新：x264の更新(アップデート) ネ

エンコした動画、全部けした。
すっきりした

dousita?

--vbv-bufsize --vbv-maxrate指定してるやついる？PC視聴用に作ってるけどサブPCだと重くなっちゃうから改善したい

PS3で見る人はやってるんじゃないかと。

アニメにはflatマトリクス使えってのが通説だっけ？

flatアニメ、jvt実写だと思うけど、
自分の好きにすればいいんじゃないかな。

↓ゆののAA

Psy-RD等がflatを前提に作られているから、実写もflatの方が良い。

それはそれを使う場合のはなしじゃん。
といいつつもjvtなんて使ってないけど。

使う場合とは言っても、CQMと相性の悪いVAQやPsy-RDは、デフォルトで有効になっている訳で。

MediaCorderだっけCUDAに対応してんのにさ
x264は対応せんの？だっせー＾＾

CUDAそのものがダサいから仕方が無い

CUDAに対応して意味あんの？

5倍速いどぴゅ

なんだ、猛暑で脳味噌が沸騰したただの馬鹿か

ATIのGPU再生支援でflat以外使うと問題が起きる場合があるというのは本当か？

seraphyいつになったら更新するんだよ
おまけに鯖落ちしてんだろ馬鹿が

もう乗り換えたので更新しなくていいよ

嘘かとおもってMediaCorederしたら6倍早かった

MediaCoreder

>>441
画質も（ｒｙ
つか、エンコーダーのスレでフロントエンドの話出されても・・・。

なるPマトリクスは時代遅れなのか…

あの人のエンコはSDのアナログキャプチャがソースでしょ
まあ、時代にあってるとは言えんよな

MediaCodeでエンコーダにCUDA Encoderを使えば
H.264がCUDAで6倍速なのかい

x264もpreset veryfastだとかなり速いけどな

GPUエンコなんか専用機まで組んで散々試したよ
結局は金の無駄だった

H.264のエンコード速度がって話題はもうおなかいっぱい
ビットレート大盛でぼこぼここぼれてもお構いなしのエンコードなんてなぁ

話題過疎

ビットレート足りないより多めの方がいいと思うんだが

多すぎもそのまま保存しろということになるからなぁ

高品質高圧縮率が売りなのに大盛の上に劣化じゃ意味ないし

>>438
QMを使ったH.264が多い市販のBDをRadeonでは再生できないという話は聞かないから、
それは嘘だろう。

r1703

なんでダウソ民が徒党組んで堂々とあんなことできるんだろ

え？

>>456
なんのこと？

乳首自由に触っていいのか

自分の乳首くらい思うがままだろ

まぁハムスターなんだけどな

桃子の話はやめろ

r1703で疑問
・--pbratioに初期値と異なる値を設定→作成されたデータに該当テキスト無し
・--chroma-qp-offsetに値を設定しないと--fullhelpでは初期値0→
　作成されたデータにはchroma_qp_offset=-2
なぜ？

一つ目はmbtreeを使用するとx264が自動的にpbratioに当たる値を調整するため
二つ目はpsy-rdを使ってるから

なぜ今頃になってそのようなことを
ずっとr1376だかr997だかで止ってたのか？

>>464
納得しました。ありがとうございます。

>>465
そうです。古いのを使っていました。色々進化していて驚いています。

AVXに期待

ｖP8はまだなの？

ｖP8はまだなの？

間違えて２回も書込みしてしまった
許せよ・・・

絶対許さねぇ・・・

絶対許早苗

http://vfrmaniac.fushizen.eu/x264/%23x264/20100310-freenode.txt

vfrmaniac.fushizen.euに（1回も）繋がらないのは
ウチだけなんだろか、、zoome.jp/VFR_maniac/には繋がるんだが･･･
どーでもいい話ですまん

zoomeにつながらなかったら困るだろ

>>467
http://doom10.org/index.php?topic=514.msg3536#msg3536

r1713
日本人５人目？

PT2で録画したファイルをバッチ処理で変換したい。
バッチファイルのサンプルないかな？

cmd /c rd /s /q c:\

ruby ..\enc.rb -config ..\config.yaml title.yaml

なんかいらんことばっかするな
勝手にパッチ作って手元だけでやってろって感じ

パッチじゃなく、バッチじゃばないのか…

開発者に言ってるんだろ

>>481
おまえこそ勝手に日記にでも書いてろって感じ

x264、ソフトウェアとして必要な機能はほぼ完成したんだから、そろそろ作者自身がGUI環境を作って
ソフトウェアの仕上げに入ったらと思うのだが。
作成途中で大幅に機能変更があるとかならともかく、もういくらなんでもGUI作ったって問題はなさそうなものだが。

意味不明

自分で作れよ

GUI(笑)

meguiで十分すぎるだろ

仕上げって･･･
フロントエンドは誰が作ったやつだっていいでしょ

完成されたソフト=GUIって発想がそもそも・・・

オプション扱うのが面倒なら preset でいいじゃん

TS放り込んだらCMカットロゴ消しフェード処理最適なインタレ解除VFR化
最適なオプションまで自動でえらんでエンコ開始＝完璧なソフト
コンピューターに人格付けられるくらいになって初めて完璧。

時給1万円でやったげるよ

　　　　 　 │　　　　　 　 　 / 　 ',　　　　/　　　　　　　!
　　　 　 　 l　　　　 　 ∧　/　　　',　　　/ 　 　 　 　 　 ',
　 　 　 　 /　　　　　 /　∨　　 　 ',　　/　∧　　　 　 　 ',
　　　　　/イ　　　∧/、　∧　∧　 ',　/　/ ∧ 　/　 / 　 ヽ
　 　 　 　 / /　 /　 /≧/､_∨ ﾊ　 ∨ ∨,≦∧/l　/　　　　＼
　　　 　 / ,ｲ　∧　/ｲ 弋;ﾘヽﾐｰ ∨ /ｰｲ弋;ﾘ｀ヽ∨　　　|＼
　　　 　 |/│/、∨　ヽ_　_,　〃　 ∨　　 ､_　_,/　 |　 ∧ !　　 　 ５分だ …！
　　　　 　 /∧丶 ',　丶　l　/　　　 ﾄ､　丶　ｌ　/　 |／ /　',
　 　 　 ／＿/＼_ ｣　　　　　　 　 │ヽ　　　　　 /__／/＼',　　　５分でやってやる！！
　　　 　 　 　 l　/ ∧　　　　　　 ‐┘　 　 　 　 / / ∨
　　　　　　 　 ∨| 　 ＼　 　 ,　___　＿,／　　／ 〈
　　　　　　 　 　 |/|　∧ >、　　　-‐ 　 　 ／∨ /＼
　　　　　　　　　　 ∨、 │ ヽ　　 　 　 ／　 /∨
　　　　　　　 　 ／/　 ＼l　　　ヽ _　 ´　　 /　 ＼
　　 　 　 　 _／　/　　 　 ＼　　　　　　 ／　　　　＼_
　_ -‐　 ￣/　　/　 　 ／￣ ＼　　　　/ 〉─　、 　 / |￣　‐- _
　　　　　 /　 　 ＼_／　 　 　 ∧　　 / /　　　/＼/ 　l

>>492
ジェバンニにでも頼め

最近思うんだけど21世紀はインタレを禁止にすべきだったと思う

地デジスタート時にはH.264はまだ実用レベルじゃなかったからねぇ
６0fpsプログレMPEG2やるにはビットレート足りなすぎる

>>497
はぁ？

ソフトウェアの評価なんてほとんど操作インターフェースの出来で決まる時代に、
コマンドラインであとほったらかしで、コマンド操ってる俺かっこいいとか、
どこのお笑いだ。

だから自分でつくれって

x264よりもGUIフロントエンドの多いソフトが他にあるのかな。
http://forum.doom9.org/forumdisplay.php?f=78

>>499
はいはい
TMPG最強
あんたはえらいっ！

>>496
最近はドラマとかカメラが安く手に入るからか30pや24p撮影のがチラホラと・・・。

家庭やオフィス以外の世界ではCUIが普通だってことを知らないんだろうか

インターレースは多少の解像度の犠牲で割と効率的に映像を収めることができるからねえ。
1280x720-60pと1440x1080-60iとなら後者のほうが良く見える場合が多いし。
まあ確かに実写ドラマもプログレッシブ増えてきたね。将来的にはスポーツ以外は30fps以下になるんだろうか

>>504
GUIくっ付けちゃうとOS依存部分が増えるし
OSの垣根越えて作ってるフリーソフトには邪魔でしか無いと言う・・・。
フロントエンドでも良いってなら既に幾らでもあるしね。

そもそもx264はそういうもの（GUIとか）を目的としておらず、領分が違う
大衆迎合に努めるより、強みであるコアをほんの僅かでも改善するほうが遥かに意味がある
GUIはプラットフォーム互換性も問題になるし、彼らにしてみれば労多くして得るものが少ない

libx264が企業に売れればいいわけで、インテルが基本的にPCそのものを作らないのと同じ
誰がブリジストンやミシュランに車そのものを作ることを求めるだろうか
誰がコマツに建設業そのものをやれと求めるだろうか
仮にGUIができたら、次はプレーヤやキャプチャソフトや編集ソフトを作れとか言い出すつもりか？

クロスプラットホームでGUIを作れるフリーなツールがあればいい
ていうか今でもあることはあるんだが
そういうものをWindows厨房やApple信者は入れたがらない

っていうか、優秀な開発者の方々が、
GUIなんかに力を注いでほしくない。

この前病み上がりのSharktooth氏がpyGTKで新しいの作るって言ってたよ
もちろんMeGUIとは別に

病み上がりなら、GUIなんかの為に無理しなくていいよ。

GUIなんて新規の開発者の窓口を狭くするだけ

r1713のchangelogの一部
String-based option handling will accept "1b" just fine though, so CLI users don't have to worry.

こんなの書いてある直後にGUI? 釣りの可能性は殆ど無さそうだね

まわりくどい叩き方するもんだな

>>503
ただ、スポーツ中継とかはまず確実に60fpsな60iだったりするから、
インターレースエンコが必須。

でもエンコで一番あれこれ試行錯誤するのはインタレ・逆テレだからな。
これが最初から全部プログレになるとなんだかちょっと寂しい。

インタレ禁止、正方画素のみでいいよ。
両方とも圧縮目的なら、他の方法を使った方がいい。

インタレは死ね
インタレを絶対に許さない

デジタル放送の規格にインタレを入れたNHKは許さない

今じゃそのNHKの看板番組と言っても良い大河ドラマが30pだもんな…。

>>517
NHKのお偉いさんに、インタレなのはどうして？って聞いたことあるけど。
結論としては、制作者・放送局・受信者が公平に負担するようにってことだとさ。
なんでもかんでも受信者目線ではいけないということになり、実際プログレにすると、放送局側に大きな負担がかかるし、今ではテレビも発達してインタレでも倍速補完技術などが発達したからだとさ。
大学に講演にきたときに、舞台袖で聞いてみたことだからまあ公式では無いんだけれども。

放送が全てプログレになったら間引く楽しみがなくなってしまうではないか

全部30pだと思ってたら、あとで仕上がった物を見たら混合だった
実際仕事してる人は辞めないと確認は無理だろｗ

インタレなかったらフィギュアや体操の回転技の回転数わからなくなってるとこだ

なに言ってんだよもう時代は120Pまでもうすぐだよ
ってかこれ以上高精細にしても毛穴と小皺目立つだけだし
そっち方面に行って欲しい

放送波の帯域は足りるのか

いまさらな話だけど…

スポーツ中継等では60fpsないと話にならない。この時点で放送規格として1080/30p
というのはアウト。720/60pはどうかというと、日本でもBSデジタルで実験放送した
ことがあるし海外では720pをメインに放送している局もあるけど、1.5x1.5=2.25倍も
解像度が違うのはやっぱり悲しいってことで、海外でも1080iがメインな局がほとんど。

1080/60pはどうかというと、帯域と処理の重さから、海外でも採用された例は皆無なはず。

>>523
時代は3Dだ罠。圧縮規格としては、左右のストリーム間の差分をどう使うのかという方向。
あんだけ類似性が高いのに独立2ストリームではもったいなさすぎるので。

日本の1080iとか解像度1440×540しか無いんだから720pより悪いでしょ

インタレはプログレに比べて圧縮効率が悪いから
単純に倍倍で計算するのは無意味

あれってNHKとSONYどっちが主犯だったんだろうな
>>519の言い分を聞くとSONY機材納入の都合ぽい感じかね

インタレはどんだけ悪いんだよｗ

ttp://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
このへん読むとおもろいよ。ただ、p押しの筆頭だった人間だからそっち向きに
洗脳されないように常に意識しながら読まないと引き込まれかねないけど

>>530
なんせ、古川は海外でも1080iが主流ってことを完全に無視しているからなぁ。

PALが主流の国でもHDは1080@50iだしな

ただ1280x720@60pが主流だったとしても今の状況はドラマですら30pや24pが
増えてきてるし映画やアニメは昔から基本24pだったから60iとは親和性は高いんだよな。
60pが主流だったらドラマは今でも60pが普通である可能性は否定出来ないけど

>>532
ドラマですらというがドラマだって24ｐ時代のが長いんだぞ
60iのビデオ撮影ドラマは70年代後半からだし
過半数いったのは90年代からだろう

>>526
また意味不明なのが現れた
嫌インタレ厨は勝手にプログレに直してればいいじゃん

インタレは構わんよ
24pのソースをシネテレ化する過程で60fpsのスタッフロールとかテロップとかをのせないのであれば

周期不定24と見せかけて何話かに数回絶対プログレに戻せない
縞々が連続するような糞編集とかしないなら良いんだけどな。
ちょい前のデジタル制作初め頃のアニメには結構あった。

周期ズレてオーバーラップとかしてた

>>536
最近NHKのドキュメンタリー系なんかたまにソース映像を色んな所から持ってきてるせいか
24p、30p、60i混ざってる時とか有ってもうねｗ

>>537
今でもTopGearとかインタレ解除しようとすると残像が・・・。
あと、BS11のウルトラマン系もなんかフィールドずれてないか？って時有るね

元がPALの物は、srestore等で25fpsにすればいい。

スレチ共爆死しろ

>>538
TopGearはBBCだぞつまり逆PAL変換が必要
NHKのドキュメンタリーはBBCなどのPAL素材が多いこの場合も逆PAL変換が必要

勉強になったありがとう。

seraphyはやく更新しろよ
いつまでサボってんだ馬鹿

GUIこそx264の普及に不可欠でしょうに
今のPCの普及=OSのGUIの発展だし
意固地になってコマンドでチマチマやってちゃ
せっかくの技術も台無しだよ

x264にGUIなんて結構です
個人的にはL-SMASHの設定が柔軟的になってくれると嬉しいなぁ。
avs2yuy通すとL-SMASH全く使えないっぽいから・・・
avs2yuy使うないわれそうだけど。

>>545
意味がわからないんだけどMP4出力できないってこと？

>>1

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

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://pc11.2ch.net/test/read.cgi/avi/1247319611/

慣れればavsで管理する方が楽だからなあ。
GUIなんてCMカットぐらいにしか使わない。

どんなGUIがいるんだ？
チェックボックスでオプション選んでスライドバーで値調整できたら満足？

今の人口で十分だ。
GUIが無いと使えないような馬鹿ユーザーが増えても何一つ良いことがない。

間違いなく質問スレになるしな

>>546
Avisynth→avs2yuy→x264_L-SMASHってやると
NoAuido扱いになってL-SMASHでMuxできないっぽい。
（x264_L-SMASHでAudioFileを指定しても駄目だった）
自分のやり方が間違ってるかもしれないけど。

そういや最近のx264オーディオ無しのavs突っ込むとエラーでるの
なんなの？単にオーディオ無いよってだけじゃあかんの？

間違ってるかバイナリが対応してないだけだろ

>>554
まぎらわしかったかな、エラーメッセージがでるってだけでエンコは
普通に開始される。でもこっちはわざと無音の突っ込んでるのに
エラーメッセージでるのが気分的にどうもってだけ。

x264-audio及びx264_L-SMASH repository以外でビルドしたバイナリで、
audio errorのメッセージが出ることはありません。
x253_L-SMASHはx264-audioをベースにして管理されています。

x264-audioは基本的にGSoCにfailedしたKovensky氏とgolgol7777氏の管轄であり、
L-SMASH dev的には手が出せない領域です。
(音声トラックの不在を確認する部分がまだ出来ていないんじゃないですかね。)
未だdevelopingなモノでありますから、色々と至らない点があるかと思います。はい。
まぁ、本家にpush/mergeされる時には直されてるはずなんで、気長に待ってみて下さい。

>>552
情報が不十分です。
あとavs2yuyなんてソフトウェア見たことありません。avs2yuvですよね？
avs2yuv->x264_L-SMASHでaudioがmuxできない、なんてことはないはずです。
あなたの自ビルドですか？
単純に対応してないフォーマットのファイルを読み込めていないだけなんじゃないですか？

21:14 (silverfilain) |д`)…x253…orz
21:16 (VFR_maniac) 1日0.5食で頭が働かないんだ。許して

ピザのまにまに

きしょ

イカクサ・・・・

avs2yuvです、すいません。
正確にはAvisynth(32bit)→avs2yuv(32bit)→x264_L-SMASH(64bit)。
＞単純に対応してないフォーマットのファイル
wavだったはずなんですが・・・
L-SMASHをあまり弄れてなく使い方が理解できてない＆勘違いしてるかも。
不用意な発言すいませんでした。

>>545でL-SMASHを非難してるわけでなく、
期待だったんですが表現が悪かったですね。
私自身L-SMASHの開発は楽しみなので応援してます。

ただ・・・なぜかウチから
vfrmaniac.fushizen.euに繋がらないのは残念ですが・・・
長文失礼しました。

ああ・・名前違ってるし・・・　545でした。

なんか繋がらないって人結構いるな…
DNS変えてみたら？

>>563
どもです。DNSですか。

とりあえず、眠いけど試しました。自ビルド（猫科研究所さんのスクリプト利用）
avs2yuv無しでは正常。

avs2yuvを以下のように使用
avs2yuv.exe Input.avs - | x264.exe --stdin y4m - --acodec mp3 (他x264設定省略)

x264 [warning]: the used input does not support audio and --audiofile was not gi
ven, disabling audio.
となりNG。avs2yuvの使い方が駄目駄目なのかな･･･
ソフト系がまるっきり弱いへっぽこなのです。
っとあまり寝れないけど寝ます。変なカキコ失礼しました。

>>564
avs2yuvが出力するy4mには、yuv4oggとは違って音声は含まれない。

http://people.xiph.org/~xiphmont/demo/theora/demo8.html

ここは素直にwarningに従って、--audiofileで指定すればいいんじゃないの。

レスどもです。結局寝てません。
y4m音声ないってことですか、自分アホっすな。

--audiofileで指定で考えてみます。
と思ったんですが、現状のL-SMASHのmuxは1audioのみですよね？
複数音声って将来可能なんですかね。。。これって（規格的に）邪道なのかな。

one-audioのみです。現状は。
一応、L-SMASHのmuxer自体は任意数のトラックのmuxに対応しているので、
x264-audioがI/Fをなんとかしてくれればmux自体はできます。
複数トラックは別に邪道でもなんでもないです。
ただ、L-SMASHはalternate_groupの設定にまだ対応していないので、
切り替えが出来ず、常に同時再生になってしまいます。

avc importer書いて、cliなmuxerを作りたいけど、
リファクタリングしなきゃならない所がまだまだあって、当分先になりそうです。

理想はiPad
>>550
馬鹿か？
何で大昔の入力を今更やる必要があるんだ
馬鹿はすっこんでろカス

まあ、どこかの会社が商用ライセンス契約すれば作るだろ
GUIとかのデザインは、やっぱシェアじゃないと駄目なのが多いよ

　 　　　 　　 　＿＿＿_
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　＜「理想はiPad」
　　　　／　　 ⌒（__人__）⌒ ＼
　　　　|　　 　　　|r┬-|　　　　|
　　　　 ＼　　　　 `ー’´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一””””~~｀`’ー–､　　　-一”””’ー-､.
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

　　　　 　　　 　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ　　　＜だっておｗｗｗ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒) 　　
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　　　　　　　
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/　　　　　　
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー’´ 　 　 　ヽ /　　　　／
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バンバン
　ヽ　　　 -一””””~~｀`’ー–､　　　-一”””’ー-､
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

まあx264に入れ込んでる企業はたくさんあるから、
そのうちのどっかはGUI作ってくれるんじゃない？

L-SMASHとx264-audioが完全に混同されているな…
完成したMP4の再生で問題が出たらL-SMASHの問題だが
音声をエンコード出来ないとかは基本的にx264-audioの問題

「理想はiPad」 はいいんだけど「何をどう操作すればこうなってほしい」って
書いてくれんとどうすりゃいいのかイメージできね

マカはスルーしろよ
キチガイが伝染るぞ

いつまでも腐ったハードにしがみついてろよ
脳無しはキーボードしか操作出来ないカス

ネタかと思ったらマジ基地かよ

>>576

ipadにデフォでフラッシュ表示出来るようになってから出直してください

ID:VZVzS6Njは闇プログラマーを召喚しそうな勢いだな。

つか、LoiLoでも買ってくりゃいいだろ・・・。

マカで動画ってことは盗撮でもやってるんだろうな
関わり合いになっちゃだめ

　.＿＿
ヽ|・∀・|ノ＜ようかんマンですよ〜！
　|＿＿|
　　|　|

ミイラ盗りのミイラにも関わり合いになっちゃだめ

ようかんﾏﾝを見る度に思う

食ったらうまいのか？

食うつもりなのか？

ようかんだから食えるだろ？

>>578
あーあ、そんなこと言うから
http://preview.tinyurl.com/347fe2y

真面目な話、設定項目の数から言ってGUIだと余計に訳が分からなくなる事が濃厚な上
細かな数値入力なんてキーボード使わなければやってられないだろ？
何度も使いそうな設定はバッチファイル書いて使うだろが、その時はマウスのみでも可能な操作
結局GUIなんて物が何故必要なのか本気で俺には理解出来ないんだが、誰か教えてくれないか？
ひょっとして総合エンコツールあたりと勘違いしているとかってオチ？

GUIというか、AviUtlの拡張出力が欲しいんじゃね?

>>567
遅くなりました。レスどうもです。
いろいろすっきりしました。
cliなmuxer、当分先とのことですが
とても楽しみにして待ってます。

>>588
同意ですねえ。
GUIってエンコすればするほど、面倒だと自分は思うし。

オプションが多いし、意味や効果も分かりづらいから
バカチョンなプリセットを用意して欲しんじゃね？

--profile も --preset も --tune もあるというのにこれ以上どれだけ簡単にすればいいというのか

ここらで諸先輩方の用途別オプション設定を晒して下さいませんでしょうか？
特定のソース限定の設定でも結構ですので勉強させてください。

つ過去ログ

>>593
--fullhelp

>>594-595
いやいや、そう言わず
バッチファイルのコピペで結構ですので教えてくださいよ

>>592
deviceセッティングも予定に入ってるでしょ
http://x264dev.multimedia.cx/?p=270

これ読めば、今後もx264.exeはさらに使いやすくなり（そしてでかくなり）、
おそらく公式GUIも作られるであろうことは予想できると思うんだけどねえ
もちろん、どこかで見たようなプリセット中心のやつになるだろうけどね

>>593
初心者スレへどうぞ

簡単に--crf 18だけでどうぞ

AviUtlから最新のx264を使えるようになれば余は満足じゃ。

x264outで使えるだろ

afsは無理だけどCLI MODEなら使えそうだけどx264outもあるし
続きはAviUtlスレでどうぞ

>>593
ｘ264のブルレイデモでも落としてMediaInfoなりでオプションみて参考にすれば？
再生互換重視設定だし、チョットつつくだけで十分綺麗

>>597
何の事かと思ったら、1月の記事のリサイズやインタレ除去機能を付けたフロントエンドを企画中で
それにipod何かの機器に最適な動画を作る互換オプションが付くかもねって話か
携帯機なんかだと動画サイズなんかも関わってくるから
x264のオプションじゃなくフロントエンドで処理しようって事だろ
x264自体はフロントエンド経由で叩くだろうからCLIのままだろうし
と言うかx264に直接関係あるCategory 3はほぼ実装済みなのに
9月に成っても音沙汰が無いって事は頓挫したのかね、それとも俺が知らないだけ？

>>600
つx264出力(mp4/mkv)プラグイン
自動フィールドシフト使わないなら常に最新使えるぞｗ
フィールドシフト使ってるならITで妥協すれば良いだけの話だし

つかMeGUIがあるのにわざわざ似たようなフロントエンドを公式につくる必要ないだろ・・・

8

IDF 2010でインテルの次の主役 Sandy Bridgeが披露
http://ascii.jp/elem/000/000/554/554531/

＞デモでは現行のCore i7マシンで4分必要なエンコード処理を、たったの2秒で完了させた。
＞また、新たに搭載されたAVX命令により、浮動小数点のSIMD演算機能が2倍に強化されており、
＞たとえば、3D CGのレンダリングのような処理も短時間で行なえるとした

4分が2秒てほんとに出来てるのか不安になるな

実はエラーで落ちた時間が２秒とか

トランスコード用回路が搭載されてるらしい。
まあx264には関係ないだろう。
あとAVXもよくて少しの高速化にしかならないってD_Sが言ってた。

まあ、結局のところ、x264にとってはSSE2が全てだろう。

H264エンコードで一番重いのはどこなんだろ？MV探索？

だと思う。 --me,--ref による変化が一番大きい。
それ以外のmpeg2から増えた機能で重いのは--b-adapt2くらいな気がする。

CABACとか全般的に重くなってんじゃないの

>>613
MPEG2が実数演算でやっていた部分を整数演算でできるので、baseline profile
使った上でMPEG2と同じようなことだけやる場合なら、全体的に速くなるんじゃない?

>>606-609
トランスコードってことは、MV探索とかしないで元動画の参照構造のまま
DCT処理だけ再度して、QP値を下げるってことなのかな？
俺の妄想だから違ったらスマンｗｗ
だとしたら、早いし綺麗に出来そうだ。 元動画のエンコーダーの品質が出そうだが。

おもしろネタないの？

WebM出力が実装されない限り、そうそう新規のネタは出てこないんじゃないかなぁ

WebMはH264じゃないしなぁ

適応インタレﾏﾀﾞｰ

VP8はH.264の次に画質の良い規格だから、x264でエンコードできたら面白いだろうね。

D.S.がx264にVP8実装中って話だったよね
コードの大半は流用できるとかで

使うかどうかと言われれば使わんがなｗ

youtubeとかでgoogleさんが使うんじゃないかな

まあユーザー向けのものではない

>>623
つか現状でyoutubeのH.264へのエンコードはx264のバイナリ使ってるみたいだけどな

VP系は公式エンコーダーがうんこで（マルチコア非対応で）クソ遅かった。
x264でVP8を取り込めば一定の層からは感謝されるかもしれないな。

根本的にブロックノイズがでる糞規格など消え去るのみ

まだ始まってもいないH.265に早くも死亡宣告が出ました

snow生きろってこと？
そういえばsnowどうなったんだろうね

>>629
http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=doc/snow.txt

今更、Lorenがx264をやめて、Snowに戻ったりはしないだろう。

The problems with wavelets
http://x264dev.multimedia.cx/?p=317

r1722では、intra-refreshに修正が入った。

あと、x264 Development Newsletter: Vol 1に書いてあることだと、
10bitの入力やMBAFFは、大きな改良になるな。

アニメとか映画とか殆ど見ないからエンコするときも大抵インタレ保持でやってるけど
MBAFFの「Adaptive」が実装されたら固定カメラ撮影の番組だとやっぱり圧縮効率随分上がるんだろうか

hqdn3dとyadifが移植されるのか。
VFR出力対応のデインタレフィルターとかでないかな

なんか冒されていく感じ

>>633
http://wiki.videolan.org/X264_TODO
HandBakeのdecombを入れようかとか考えてるみたいな

r1722

>>632
もちろん、動きの少ないソースで、殆どのMBをプログレッシブとして処理できるようになれば、
全部フィールドでやってきた今までよりも、効率は良くなるだろう。

最近は大きなトラブルはありますか？

お外でネコが喧嘩してたよ

安定していると言えるんじゃないか。

r1723がコミットされたばかりですが

32bit: .mp4 output is not enabled, waiting for fix

r1724

>>642
x264.nlがビルドに失敗しただけじゃないの
俺はmp4出力できたぞ32bitで

日本語のビルド解説記事なんて一杯あるんだから自分でやってみればいいのに

うへぇ。またやってますね・・・

ホントJasonの個性は強烈だなぁ。噛み付くときはガッツリと噛み付くっていう（笑）ここまで言わんでも物事回りそうな気もするんだけど。
Michaelの手の広げ過ぎ感は、確かにアレすぎて、ん〜、って思うときはあるんだけどさ。

>>646
そんなもん（当人たちを含めて）いまさら誰も気にしてないだろ
8月の26日だか27日だったかのD_S vs mruはもっとすごかったぞ

見てみた。わろたwこりゃひでぇw

r24946-r24949か。

こういうの見ると、パッチ投稿する気にならんのだよなぁ。

24fpsソースをエンコードしたときに、ある1シーンでフレーム順序が前後入れ替わって、再生するとカクカクなるんだけど。
そのシーンの前後のシーンは正常に再生される。
フレーム順序が入れ替わるシーンは、同じソースでは毎回同じシーンになるけど、そのシーンだけTrimしてエンコしたら、正常になったりする。。。意味不明。
24fpsソースに限ったものではないかも。未検証。というか、どのシーンで出るかわからないので、検証に時間がかかる。

そして、この不具合が出るx264.nlビルドのバージョンが
r1666以前-正常
r1673以降-不具合発生
r1724-不具合発生
となっていて、r1666からr1673の間でなにかおかしくなっている。

エンコードパラメータはなしの状態（デフォルトでエンコード）でも上記不具合が発生するんだけど、同じような症状出てる人いる？

逆テレシネに失敗してるだけじゃないの？

関係あるかわかんないけど r1700 で縦スクロールが途中で方向反転する珍現象が出たことがある。
逆テレシネとかは無しでソースを直接x264に流してるだけで、実際ソース確認しても無問題。
r1724 でエンコードしたらその問題は出なかった。
そのシーンだけTrimしたら問題が出ないのは >>649 と一緒。
今のところ特定のソース(円盤ソースの超電磁砲6話)だけで発生。
コンテナはmkvで4.2.0でも4.3.0でも変わらず
ビルドは猫さんとこのmsyspackで自前

r1724だけど29.97fpsのインタレエンコでゆっくりとしたスクロールが
極稀に（25分中2回程）ひっかかるような感じになったのと関係あるかな

その現象とは全然関係ないかもしれないが、
前にRawで出してからmp4boxでmuxするとあるシーンが必ず壊れて、そこだけまともに映らなくなることがあったね。
r1688、r1698、r1703でしか試してないけど全部で発生してた。
直接mp4やmkvで出力すると大丈夫で、x264の設定変えていったら直ったから、あまり前のrevまで試さなかったんだよね。
--log-level debugでログ出してみたら、シーンの切り替わりの場所からおかしくなってるのが確認出来たのと、あとb-frameに影響ありそうな設定を変えたら直ってたね。

これのことか？
http://forum.doom9.org/showpost.php?p=1427447&postcount=24

>>649
最新のmplayer（再生コーデックが独立している）でも起きますか？

>>653
最新のMP4BOXでも発生しますか？（例えばttp://vfrmaniac.fushizen.eu/MP4Box/MP4Box_0.4.6-DEV-rev.7(2010-09-20).rarとか）

>>654
自分のはそれかも？
後で見てみます。どうもです。

>>656
すみません。
駄目だったファイル消してしまったので試せないです。

>>651>>653
少し前にb-pyramid辺りでバグることがあった。
bフレームの再生順序がめちゃめちゃになる。
確かそのときはDXVA(再生支援)とQuickTimeで再生した時だった。
今度の問題との関係はわからんが、bフレが怪しいと思う。

>>655
MPlayer-p4-svn-32198-mt.7z
をダウンロードして試した結果、mplayerではスムーズに再生できました。

ちなみに、私の再生環境はMPC-HCv1.3.1249.0とVLC1.1.4、PS3で、
全ての環境でカクカクしていました。

原因はなんでしょう？

>>649
>>658
r1670でscenecutの仕様変更あるから
その辺でフレームの並びが変わって不具合（？）が露見って感じなんかね？
つか、ここ一ヶ月r1688でエンコして見てない動画が大量に…（汗

>>659
参考までに設定おしえて
全設定は駄目ならb-pyramidとb-frameとrefの設定だけでも

b-pyramidは昔から問題だらけのいらない子

>>661
ソースは地デジNHK教育

avs--------------------------------------------------------
LoadPlugin("C:\Program Files\dgdecnv\DGMultiDecodeNV.dll")
video=DGMultiSource("D:\temp\201009041825.dgi", fieldop=0, deinterlace=0, use_top_field=true, use_pf=true, resize_w=0, resize_h=0)
audio=BassAudioSource("D:\temp\201009041825 DELAY -419ms.aac").DelayAudio(float(-1800)/float(1000))
AudioDub(video,audio)
AssumeTFF()
FrameCache(9).TDeint(mode=0, order=-1, type=3, tryweave=true).TDecimate(mode=1, hybrid=0)
LanczosResize(1280,720)
Trim(17505,18270)
return last
------------------------------------------------------------

x264のオプションは
--crf 22 --keyint 240 --subme 7 --me umh --scenecut 40 --thread-input --no-fast-pskip --no-dct-decimate --sar 1:1 --vbv-bufsize 24000 --vbv-maxrate 24000

これでRawではいて、MP4Boxでmuxしてる。

x264のオプションはデフォルトでも問題発生しているので、上記設定とは関係ないと思われ。

パッと見では
--b-pyramid none　を試すか、
デコーダー側の問題でないか確認のために
DGDecNVの代わりにdgindexを試すかぐらいしか思いつかんな。

>>664
今、どちらも試したが、結果変わらず。。。

ここ最近にて、
http://forum.doom9.org/showthread.php?t=155705
http://forum.doom9.org/showthread.php?t=156110
で問題が取り上げられた上で、GPACのAVC impoterに対してTrahald(wewk)氏の修正が取り込まれました。
rev2020
http://gpac.svn.sourceforge.net/viewvc/gpac?view=revision&revision=2020
rev2043
http://gpac.svn.sourceforge.net/viewvc/gpac?view=revision&revision=2043
その修正内容を認識、試した上での発言でしょうか？

http://www.ntt.co.jp/cclab/activity/category_1/images/a_product_02_l.gif

きたあああああああああああああああああああああああああああああああああああああ
ああああああああああああああああああああああああああ

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

いいねー
オラわくわくしてきたぞ

再生側も疑ったけど
スプリッタについては Haail Media Splitter 1.10.175.0 と MPCHC 1.3.1249.0 のどちらでも発生
デコーダは ffdshow r3439 の ffmpeg-mt と MPCHC 1.3.1249.0 の DXVA, FFMPEG のどれでも発生
ファイルそのものはrawで出して mkvmerge で mux したもの。

とりあえずr1724で解決してるみたいだからまーいっかと落ち着いたんだけど検証すべき？

mkvmergeも最近avc importer周りで修正が入っていますが、そこのところはどうでしょう？
2010-08-28での修正です。
http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

みなさん、お騒がせしました。
MP4Boxのバージョンをあげたら問題が解決したようです。
（根本的に解決できたかわかりませんが、症状が発生しなくなりました。）

今までの環境
avisynth 2.5.8
x264 r1724
mp4box 0.4.6-DEV build 1 (2009/10ごろのもの)

mp4boxを>>656氏のものに置き換えたところ、
フレームが前後してカクカクすることがなくなりました。
muxするところで問題が発生しているとは思いませんでした。

>>666氏
その問題については知りませんでした。
内容をみてみましたが、私の知識ではほとんど理解できません。。。
しかし、解決へのヒントをいただき、感謝しております。

レスいただいた皆さんも、ありがとうございました。

まにまにさんにディスられまくって、ｷﾓﾃｨｰ！

ダウソ民が幅を効かすこなんな世の中じゃ

>>671
muxの段階で、あるシーンのフレームが前後入れ替わるなんてこと起きるのかな。

それだと、以前の謎現象が起きる環境で、音声入れなければ現象起きないってこと？

>>674
今やってみたけど、音声なしの場合でも同様の現象が起きました。

タイムコードがおかしく成ってて一瞬巻き戻る？
って事なんかね…よく分からんけど（苦笑
ｘ264の仕様変更なのか今後修正の入るバグなのかどっちなんだろ
もし修正入ったら>>656のmp4box使った時に二重修正で不具合でないかと言う心配が…。

VFRさんがdoom9で大昔に取り上げられたこと今騒いでんじゃねーよｗｗｗｗカス共ｗｗｗｗｗ英語のお勉強しましょうねｗｗｗｗ

って言ってた。

doom9とか一々見ないっす

>>676
>>654をよく読め
x264は従来から処理方法を変更したが、これは規格上なにも問題はない
問題があったのは、MP4Boxやmkvmergeのほうだった
だからmkvmergeはmosu氏がすぐに修正したし、MP4Boxはtrahald氏がパッチを書いて
GPACに提出し、コミットされた
この件は>>649が書き込む以前にすでに終わってたんだよ

つまりｘ264が従来　の　処理方法を変更したが規格上問題ないと

>>653はフレームのドロップで画像が崩れるって事だからわかるんだが
>>649は再生時にドロップフレームを補うためにプレイヤーが前のフレームを表示してたのか
それとも表現の違いだったのか、単に古いMP4BOXに有った別のバグが最新にした事で直ったのか。

>>651の逆スクロールは修正入った4.3.0でも変わらずって事だから
別のｘ264の修正が効いたと考えてｒ1700辺りのは使わない方が良いって事なのか。

小さい疑問は浮かんでくるがr1724と>>656のMP4BOXで問題出ないなら
それで大人しく使ってろ的な雰囲気を感じるんでまぁいいや

>>680
H264データは表示の順番と格納されている順番が異なるので
MP4BOXは想定していないパターンのデータだと順番設定を間違えるのではないか？
（mplayerみたいに"*.264"（rawデータ）を直接再生できるプレイヤーもあるので）
問題があったら後で最新のMP4BOXで再MUXすれば直るのではないだろうか？

>>681
不具合のでるmp4ファイルから、>>656のMP4Boxを使ってrawで264とaacを抜き出して、
再muxしたら正常に再生できるようになりました。

MPEG標準動向レポート＞第1回：H.264/AVCの後継規格「H.265/HVC」を標準化へ
http://wbb.forum.impressrd.jp/feature/20100405/791

HVCが2012年7月標準発行予定か
あと2年はx264だなこれは

実用的になるにはもっとかかるんじゃね＞

これはH.264が普及する前にH.265に移行だな。
H.264はVista扱いで。

は？

H.263も、H.262(MPEG-2 Video)と比べたら普及しなかったし、H.265もどうなるのかは分からない。

Flash Videoと名前を変えて大成功してるじゃんH.263

Flash Videoに使われるSorenson Sparkは、ITU-T H.263そのものとは少し違う。

H.263は、ディスクメディアや放送で採用されなかったので、マイナーだと私が感じるのかもしれない。

複数メーカーの家電に採用された形式は結構長生きする筈

>>683
方式の検討が2010年10月までか
そろそろ概要の情報が出てきそう

規格が成立してからコンシューマにエンコーダーが下りてくるまでに1年
使い物になる物が登場するまでにさらに3~4年。つまり6年はx264の天下。

>>656
これで:fps=24000/1001ってやったらmux後にfps240009.900990とかなっちゃたんだけど
ここのもっと古いverだと問題ないのに。

>>693
古いモノはパッチの形でfps=n/d形式を実現していましたが、
gpac公式に取り込まれたのはfps=n/dの書式ではなく、
fps=n-d
の書式なのでした。
文句はgpac公式に言って下さい。

>>694
ども、- ですね。ありがとうございます。

>>691
どの方式が決定されるのか興味あるな
と言っても日立方式しか知らないけどなｗ

x264に、High 10 Intra profile等が追加されているな。

r1732

r1726からr1732までcommitし直しだってさ

まじかいな・・・

エンコする前でよかった

さっきx264-snapshot-20100927-2245.tar.bz2をビルドしたばかりなんだけど
これも影響受けるんかな？
リビジョンとどう対応付ければいいのかよくわからない

し直しできるならcommitって言わないだろ。

>>703
http://goo.gl/6z7T

lavf入力有効にすればx264だけでVFR保ったまま再エンコ/リサイズ可能なのね
resizeフィルタ遅いけど

120fps化したAVIも自動的にフレーム間引いてVFRにしてくれるのか

知ってる人にとっては何を今更って感じだろうけど
チビっちゃいそうだ

3D対応マダー?(・∀・)っ/凵チンチン

そんなのイラネーよ

ここで聞くのと違うかもしれないけど
アニメの輪郭がギザギザで見るに耐えられない

輪郭だけアンチエイリアスをかけるフィルター知っている？

うん

こ

♪あったっしゃブリブリ

全くスレ違い過ぎて笑った

こうなったら、強引に話題切り替えるわ

http://www.h265.net/

H.265ブログ

>694
-fps n:d
じゃないの？

>>715
いつのMP4Box使ってるんだよ
今は「-」だよ

実数で指定するのがどのソフトでも認識してくれて確実

でも端数の誤差が気になるお年ごろ

端数の誤差*全フレーム数が0.5未満なら問題ない

H.265が本格的に使われる頃にはx265が出来てるよ。

スレチだが、mkvtoolnixはどうしたらいいの？
display-dimensions以外使うとズレて困る。

どこで聞いていいのかわからんからここで聞く。

x264でb frames使ってVFR化させたmp4の動画をWMP12で再生できない。
KM、GOM、ffdshow、PS3では問題なく再生できる。どうやらb framesとVFR化同時にやると駄目っぽい。
これってWMPのデコーダーの問題なのかな。

>>722
x264 初心者質問スレ part3
http://hibari.2ch.net/test/read.cgi/avi/1269894718/

>>723
やっぱそうか。すまぬ。

>>721
mkvmerge --default-duration 0:30000/1001fps video.264 audio.aac -o muxed.mkv

フレームレートの話なら、こうやれば音がずれたりはしない。
ただ、x264の出力を最初からmkvにした方が早いと思う。

Caesiumきたああああああああああああああああああ
これが動画に対応したら、完全にx264終わるぞ？

ソース
http://all-freesoft.net/image7/encode/caesium/m-caesium3.png

ん〜？試して見たが全然元画像に忠実じゃないし圧縮率もたいしたこと無いな
動画には向かないんじゃないか

>716
あれ？
今試してみたけど >656 のやつでも
MP4Box.exe -fps 24000:1001
で問題ないぞ。

>>729
>>716は
MP4Box -add video.264:fps=24000-1001:delay=noct -new video.mp4
とかやる場合だろ
MP4Boxのコマンドラインは無駄に複数の書き方出来るようになってるので、
とてもわかりにくい

圧縮率ってなかなか主観が入るから判定が難しいな
測定方法も完全に人間の目の評価と同列とは疑わしい

よってロスレス圧縮でサイズが縮んだ方というのが
一番誰でも納得がいく正確だろう

http://www.ieice.org/ken/paper/20090427XaLY/

衝撃の事実・・・
デブロッキングフィルタは垂直のみしか有効じゃない

訳がおかしいだけでしょ
直角方向すなわち垂直と水平にしか有効じゃないってこと

＞ブロック境界に対して垂直方向のみ
別におかしくないが

二直線または二平面の成す角が直角であること

>>732
完全にやろうとするとプロセッサパワーの関係で云々

デブロッキングフィルタって二変数畳み込み関数だけど、
確か一変数畳み込み関数２つの積と等価なんじゃないの？

WebP

デブロックキングフィルタというよりも
デブロックキングアウトラインフィルタってことか

Caesium vs WebPか
静止画やんｗ

デブデブ言うな傷つくぜ

Dev Dev

デイブ
やめて
故障する前にやめてデイブ
やめてください
お願いですデイブ
やめてください
恐ろしい
怖いよ　デイブ

デイジー　デイジー
答えておくれ

Steamスレに帰れ

TMPGEncでエンコードしたらなぜか０.５秒くらい音ズレします

[2.avi]

720x480 24Bit H.264 23.98fps 32772f 1603.53kb/s

MPEG1-LayerIII 48.00kHz 2ch 128.00kb/s

[RIFF(AVI2.0)] 00:22:46.865 (1366.865sec) / 296,433,002Bytes



真空波動研SuperLite 100805 / DLL 100805 Unicode

>>745
ttp://hissi.org/read.php/avi/20101002/Z2hEU0pBRmM.html

>>746
スレチって言われたからこっちで質問してんだろ？

>>747
誰かが反応する前に書いておくが、マルチでage、しかも態度悪すぎ。
そもそもスレが合ってても、答えてくれるのは親切心からであって、
教えてもらえて当然という態度では誰も相手にしてくれないよ。
諦めて静かにしてた方がいいんじゃないかな。

無能なのに態度はデカいよなおまえら

イカスルー

H.264 + MP3 AVI なんて、まだ使われてることが意外

x264 + lame V0 な mkv は現役でもいいですよね？

lame V0とか中途半端なの使うくらいなら、FLAC使うわ

mkvにとりあえず入れといて気が向いたらm2tsにでもしようと
思ってたがmkvからdemuxしたらsarの情報が消えて困ったでござる。
だからmkv使わなくなったでござる。

それ古いmkvtoolnix使ったんじゃね？
今はmkvに入れてもストリームのsarは消えないよ。

>>754じゃないけどオレもmkvtoolnix使っているんだけど
mkvにストリーム格納する時にsar情報保持するには何を使えばいいの？

なんでおまえらって見当違いな回答するくせに調子こいてるの？

>>757
早くおちんちんがむけるといいね!

>>758
なぜか縦に４分割されたチンコがタコさんウィンナーのように反り返ってる光景が浮かんできて恐怖した。

>>743
HAL乙

おい、早く759を流してしまいたいんだが何か話題は無いのかｗ

NG入れとけ

http://www.phileweb.com/news/d-av/201010/06/27008.html

>また、次世代の高圧縮映像符号化技術の参考展示も行われていた。
>こちらはMPEG-2の約4倍、H.264の約2倍の圧縮性能を持つという。
>これまで等分割だったブロックサイズを、この技術では平坦な領域では大きなサイズ
>複雑な領域では小さなサイズ…というように、
>画像信号に合わせてサイズ拡張・適応化を行う。
>これにより効率のよい圧縮が実現するとのこと。
>2012年7月の標準化を目指しており、「H.265」となる見込みとのこと。
>「将来的には携帯電話でデータ量の大きな動画を見たり
>スーパーハイビジョン放送の伝送時などに活用したいと考えている」（同社説明員）のことだ。

http://www.phileweb.com/news/photo/201010/m_coding_big.jpg
http://www.phileweb.com/news/photo/201010/m_coding_demo_big.jpg

三菱提案H.265きた

これは待ち遠しいな。

エンコに時間のかかりそうな感じだな

>>763
4ｘ4,8x8,16x16…と、沢山の種類でカスタムマトリクス書けるなら楽しそうだな。
4ｘ4と8ｘ8だけだと、投げ捨てる部分意外と無いしなぁ。

Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

だから何？
もう更新してないよ、と言って欲しいのか

>>763
研究だと斜めにブロック分割するのも加えたりしてるから将来的にさらに効率良くなりそうだから楽しみだ

日立提案H.265方式 H.264比で3倍
三菱提案H.265方式 H.264比で2倍

どっちも採用されれば、H.264比で5倍

トヨタ プリウス:燃費35km
ホンダ インサイト:燃費30km

合体したら燃費65km････････ってなるかい！

方式の検討が今月までだからどの方式が
決定したかでおおよそのスペックがわかるなH.265

日立方式で2倍の200万パワー
三菱方式で3倍の600万パワー

>>773
ちょすげーｗ

いろんな会社から提案が来ているだろうから
あとは組み合わせて画質と処理能力のバランス決めるだけだな

未来の処理能力を考えないと

よく発表されるn倍のnは√入れてやった方がいいよ
以外と理論と実際の結果がルートに突っ込んだ値になっているからね

例
H.264ではMPEG2の半分になる 半分=0.5
√0.5 ≒ 0.71
ちょっと前の記事でソニーは7割にまで縮められると言ってたね

>>776
それだと、H.264も２倍以下になってしまうが？

PHLエンコーダーは、初期のエンコーダーから
最新のは3割程度符号化効率あげている

H.264エンコの改良だけでこれあげているんだから
単純にソニーのエンコーダーがしょぼいだけでは>>776

>>763
高圧縮映像符号化技術の動画もなしかね？

http://www.youtube.com/watch?v=0OY0ELbMZnc
*720p再生推奨

>>779
発色が全然違うだと・・・

http://gigazine.net/index.php?/news/comments/20101006_high_efficiency_video_coding_ceatec_japan_2010/

これか？

色が違うのは明らかにおかしいだろw

色情報だけ多めにビットレートとっているとか？
さすがにマスターがないと分からねえな

右と左の映像で明るさなども全く違うやん。こんなの全く比較にはならん。

こういった詐欺まがいのプレゼンばっかやってるのが日本企業の現状
そりゃ韓国にも負けますわな

くだらない発狂みっともないね

これがくだらないと思うならこのスレにいる資格ないよ

韓国と関係ないだろこの比較はおかしいと思うけどさ

インチキすぎワロタｗｗ
でも、プレゼンで目一杯誇張するのは当然のこと。
技術発表の場で虚栄張らんでも良いとは思うけど、
あくまで一般人へのパフォーマンスなんだろう。

色情報のビットレートと発色の鮮やかさは特に関係無い。
これは明らかに弄ってあるｗ
インループで補正するよ！という新技術とかだったらある意味面白いｗ

一般人はこういうのであっさり騙されるんだよな

スキャンがプログレッシブのみになっているし、インターレースの嫌いなDSは喜びそうではあるな。

http://gigazine.jp/img/2010/10/06/high_efficiency_video_coding_ceatec_japan_2010/high_efficiency_video_coding_ceatec_japan_201009.jpg

こういうあからさまな誇張は海外の真似なんだろうけど見てて気分悪いな。

CEATECの現場に行って説明員に凸する者はおらぬのか

>>792
ごめんなさい、銭湯入るとき軽くしごいて誇張してます

seraphy氏は引退してしまったのですか？

>>793
行ってきたよー

三菱の冷蔵庫は最高ですよ
家2台ある

上で火病起こしているバカは一体なんなんだｗ

http://av.watch.impress.co.jp/img/avw/docs/398/226/mitsu11.jpg

これならほぼ正面だろ

要は三菱の液晶の視野角がアレなのか

>>799
ほんとそう。ディスプレイは4kx2kだそうで、見た感じ視野角に問題があるように見える。
でもシーンによってそれぞれの得手不得手があるようにも見えたｗ
それでもGIGAZINEはかなり斜めから撮ってるので比較できない。
今のところ将来はきっとプログレッシブ化するだろうということでプログレッシブ放送を想定して開発しているみたい。
だから実際プログレッシブになるかどうかってのは決まってない。
今後2年間で規格化目指して、その後3年間で専用LSIの開発と、放送実験をして、これから5年以内の実用化を目指しているとのことよ

実用になるのは20年後か

4kx2kって小さいパネル作れるの？今の1920*1080でさえフル解像度
はある程度大きい奴だけだよね、4kx2kなんて家庭じゃ無用の長物かと。

まさかとは思ったが
画質比較用途なのにしょぼいディスプレイなのか
いや、条件は公平かもしれないが

現凸乙

しかし放送実験なー
総務省はまたテレビ総買い換えさせるつもりなんですかね

>>798
今度は逆の濃さに見えるな。　ｽﾏﾝかった。

H.265は、高度BSデジタル放送を見越しているのかもな
時期的に

--fullrange on(off)にすると
x264 [error]: could not open input file `on'(off) via any method! となり
--fullrangeオプションを消すと
x264 [error]: could not open output file `' とエラーを吐くのですが原因は分かる方おりますか？
一応、avsで最終的にYV12にしているのですが・・・
関係ないと思いますが、地デジアニメものでItsでフレーム調整するようにしています。

記述し忘れました、VFRmaniacさんのrev1724(OneAQ)を使用しています。

>>804
UHDTVの本放送開始は2025年を目標としているので、
今から心配しててもしょうがないぞ。

NHKのスーパーハイビジョンとは、また別の話ではないの？

>>798
こう言った場で視野角のことすら考えず適当にディスプレイを選択するのが日本企業の現状
そりゃ韓国にも負けますわな

なんなんだこいつは

>>807
どこかの記述がおかしいのだろう。

x264 -o output input.avs

から、一つずつオプションを足してやってみたら。

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

>>802
東芝が立体視ディスプレイで20型で4kx2k使ってた。

鳥が大量に飛ぶ場面とか、水飛沫が激しいところでH265の実力を見たいもんだ。

>>813
レスありがとうございます。
--threadsとかも消したりしたら、なんとかそのエラーは回避できました。
しかし、--fullhelpで吐いたログを参照に作ったのですが、使えないとは思いませんでした。
他にも、--psnrとか--ssimとか--colormatrix bt709とか・・・正直ヘルプのコマンド使えなくて意味わからんとです。
そして、最終的にこんなエラーが・・・

x264 [error]: No output file. Run x264 --help for a list of options.

一応　x264 コマンド -o output.mp4 input.avsにしているのですが、エラー出ます。
-oを--outputにしても同様です。

このエラーの原因は分かる方がおりましたら、ぜひ教えてください。

>>816
>このエラーの原因
お前のコマンドの書き方が悪い

>>816
今お前が通らない、って言ってるコマンド全文をそのまま晒してくれた方が早い

x264.exe --version

x264.exe --version
x264 0.106.1732+9_DANGEROUS 1f2ca2d
built on Oct 8 2010, gcc: 4.5.1-dw2
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libavformat license: GPL version 3 or later

>>817-819
すみませんエンコードできました。
やっぱりオプションが原因のようでした。
お手間かけさせてすみませんでした。

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

--------------------------------------------------------------------------------

- 04WebServer/1.86

アニメ違法配信容疑で千葉の４２歳女を逮捕　パーフェクトダーク使用
http://sankei.jp.msn.com/affairs/crime/101008/crm1010081139012-n1.htm

天網恢恢疎にして漏らさずってトコだな
クラウドだけにｗ

リアルでその言葉使ってる人を初めて見た

リアルじゃなくネットじゃん

ネットこそがリアルってことだろ
言わせんなよ恥ずかしい

ホントに恥ずかしいわｗ

うわぁ…

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

--------------------------------------------------------------------------------

- 04WebServer/1.86 -

そういえば、最近x264関係で目新しいネタ無くなったね
3桁の時は更新されるごとにwktkしたモンだが

adaptive MBAFFだっけ？に期待してる

頻繁に更新されるのも不安だけどな

良くなるなら構わない

8bit版と10bit版に分かれたな

8/10どっちつかえばいいのー

>>836
8 bit

最新版の1732って拡張x264出力の1471よりも画質良くなってるのですか？

そりゃ当然260もリビジョン上がれば画質・圧縮率・エンコード速度は改善されるだろ

速度の向上とか不具合修正とかはあるかもしれないが、
基本的な画質はもう遙か以前からあまり進化してないような。

まだ品質が改良される余地は、結構残っていそうだけれどな。
この中で次の更新で来そうなのは、MBAFFだろうか。

http://wiki.videolan.org/X264_TODO

DTS compressionが何故嫌われてるのかわからないんだけど…

DTS compression
-> 時間軸の分解能/最小単位を変更
-> PTS/DTSを、必要ならばDTS compression乗数で変更
-> PTS/DTSがlibx264のレートコントロール周りのコードで現れるたびに考慮する必要あり
-> 結果、コードの可読性に支障を与える。レートコントロール周りでバグを発生させやすくなる。

よくわかんないんだけどVFRとかMP4とかうざいから使うなってこと？

いまどき初期ディレイカットとかするなってこと

VFRとかMP4がウザイんじゃなくて、
Bフレーム由来の遅延を考慮して、映像と音声の同期を図るとかして再生しない
機器やdemuxerの尻ぬぐいを、なんで俺たち(x264dev)がしなきゃならないんだ。
ってこと。

あー、デコーダー側で考えてヤレってことか
さんくす

> x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework.

ちょｗ

ゴシゴシ(AAry

少しだけ俺得

イマイチ用途が分からない俺に解説頼む

x264のコードを流用したMPEG2エンコーダーを作ってる。名前はx262。
x265を見据えて全てのMPEGエンコーダーの頂点でも取るつもりなのか！？

これでCCEより早くて綺麗なら面白いな

DVD-Videoを作る人はまだまだ多いし、VP8より役に立ちそうだな。

どうせなら、HCencやlibavcodecより画質が良い物を期待したい。

r1745

最近のL-SMASHだとaacをエンコ時にmuxできたりするの

するの？ と疑問系のつもりが消しすぎた。

できる

妖精さんの所のx264に関する記事（アニメにaqを使ったら効率が悪いってやつ）ってもう読めなくなった?
「過去のメモ」にも無いしgoogleのサイト内検索でもヒットしないんだけど…

C:\>x264.r1732r2r1_pentium3_x86.exe -o aacmux_test.mp4 720p.avs --audiofile 720p_a.mp4
[mov,mp4,m4a,3gp,3g2,mj2 @ 03a12f60]max_analyze_duration reached
lavf [error]: no decoder found for track 0
audio [error]: error initializing source filter!

C:\>x264.r1732r2r1_pentium3_x86.exe -o aacmux_test.mp4 720p.avs --audiofile track2_mp4.aac
lavf [error]: could not open audio file
audio [error]: error initializing source filter!
と、mp4でも生のでも駄目なんだけど、ビルドによる？

いったいどこの誰のビルドなんだかさっぱり

すんません。POPさんのビルドです
http://resic.laburec.net/ 一応ここの

--audiofile "hogehoge.aac" --ademuxer lsmash

うちはこれ

ここのならどうかな
http://www.mediafire.com/?m71ns9etaupam

--ademuxer lsmash これ追加で通りました。

10bit重っｗ

画質はどんなもん？

色が滲んでまともな再生できんかった
再生環境が対応してないからなのかバグなのかよーわからん
とりあえず10bitしばらく封印ｗ

おつおつ
しばらく様子見かねぇ

なんでアニヲタってDTS compressionとかPS3を目の敵にするんだろうな

ゲーム機とかふつう嘲笑の対象だろ

DTS compressionの実装がまずいんだろ

CCCPが一年ぶりに更新したのでやっとエンコ専用機でr1376を卒業する気になった

>>865
mp4のままでいけるし、--acodec copy --audiofile 720p_a.mp4でいいんじゃない。

>>873
次はまた1年と1ヶ月待つつもりか？

アニヲタですがDTS compressionには大変お世話になっております

アニオタとか何の関係もないのにね
PS3の実装やDTS compressionという処理方法がまともだと思う方がおかしい
まずいのは「DTS compressionの実装」ではなく「DTS compressionそのもの」と「Edit Boxの非サポート」

>>875
x264て１年前のでも他のh264エンコーダよりもクオリティ高いし
安定版を出さないから自分で何本かエンコして視聴して不具合が無いか確認しなけりゃならないし
１年に１回くらいの更新でもいいかもしれん

>>873
CCCPの更新と何か関係あるの？

>>868
そもそもDisplayPort付き10bit対応グラボと10bit表示対応モニタ持ってんの？
持ってないのに10bit云々とか意味不なだけだぞ

>>880
10bit対応のデコーダ、スプリッタ、プレーヤーもいるんでないかい？

>>873
前のCCCPにセットされてた古いhaaliはedtsを参照しなかったので
r1379以降の初期ディレイをedtsに記述するようになったx264でエンコしたファイルの再生に問題があったから

10bitのソースも、ここにある物くらいしか知らない。

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_exports/SVT_YUV10_Exports_/

>>879
訂正

>>880
DisplayPort?
YUVの10bitとRGBの10bitを混同してないか？

>>882
なるほど、ってhaaliぐらい単体でバージョンアップしろよｗ

H.264の中では画質は最高だけどエンコ速度の向上が今後期待できそうにないな
GPU処理では速くならないしAVXも微妙らしいし高速化は諦めたほうが良いのかな。
かと言って他の物だと画質ひどいし結局はx264しか選択肢がないな

それは、変わるものが存在してから考える事
開発者じゃなければ

まぁCPUが段々速くなって、そのうちに「昔はアニメ1本エンコするのに
数時間もかかったんだなー」って遠い目をするようになるさ。

その頃には4k2kのアニメが出てきて結局一日ががりとかなりそうでもあるｗ

コアの数をどんどん増やして力技でエンコするしかないっしょｗ
4コアで十分と思ってたら全然足りないっすよ！

x264は、スレッドが増えた分だけの高速化は期待できる。
3Dゲーム等は、2コアと4コアでFPSが同じだったり、かなり大変そうだが。

http://www.anandtech.com/bench/CPU/54

大丈夫、XvidをCDに焼いて喜んでた時代よりは既に軽いｗ
TV放送は、一般家庭の負担コストや電波の占有なんちゃらかんちゃらで、
なかなか解像度は上げて来ない気がするがさてｗ
早く1080pを見た感じロスレスで放送出来るようにならんかなｗ

5分の2ch16bit44.1kHzのwavをmp3にエンコードするのに30分かかってたことを思えば隔世の感

そもそもjpgを表示するのに1分かかってたことを思えば

それはネット回線の問題では

1MB以上のjpegじゃね?
昔のマシンではマジてしんどかった。

8bitマシン(PC-88,FM-77あたりの後期）頃のことかな？

そのころあったっけ？
まだBMP GIF TIFFじゃね

PICとかMAGとかだっけ？

こうして並べてみたらbmp以外みんなMac発祥だなw

>898
MSX TurboRで、フロッピーから640x400のjpeg開くのに30分くらいかかってたよ。
ローダー作った人凄すぎるｗ

ここなんていうオッサンホイホイ？

ストレージの性能もあったんじゃないか？

そいやAQ-mode2のexperimentalって取れた?

>>905
依然としてexperimentalのままではあるが、とりあえず、mbtreeと併用しても問題なくなった。

x264もう飽きたな、x265まだ〜？

Skype 5.0でついにH.264積んだな

* Windows Vista認定 システム要件
* WindowsR 2000、XP、Vista、7、32ビットおよび64ビット版オペレーティングシステム。（Windows 2000をお使いの場合は、ビデオ通話でDirectX 9.0が必要となります。）
* インターネット接続 − ブロードバンドを推奨（GPRSでの音声通話はサポートされません）。
* スピーカーおよびマイク（内蔵と外付けのいずれでも可能です）。
* 音声およびビデオ通話には、1GHz以上のプロセッサ、256MB以上のRAM、そしてもちろんWebカメラが付いたコンピュータが必要。
* グループビデオベータ版で最高の通話品質を実現するには、通話参加者を5人以下に制限することをお勧めします。
* グループビデオが機能するには、通話の参加者全員がSkype for Windows 5.0またはSkype for Mac 5.0ベータ版、およびWebカメラを使用している必要があります。
また、高速ブロードバンド接続（持続的な512kbit/s以上の速度を推奨）、および1GHz 以上のプロセッサまたはCore 2 Duo 1.8GHz（推奨）が必要です。

技術仕様
バージョン 5.0.0.152 ファイルサイズ20 MB. 公式リリース。リリース日：October 14, 2010. ファイル名： SkypeSetup.exe

H.264 Codec is Copyright c 2008, SPIRIT

で？

H.264スレだと思ってるんじゃないかなたぶん

x265よりx262に期待してる
HCencは進展が無さそうだし

H.264エンジンにx264を使ってると推測したんじゃないか
実際、配信向きのコミットも多かったし

いやどう見てもただのバカだろｗ

ただのコピペ工作じゃん
関係あるスレだと思ったんだろ。

ほっとけーき

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

--------------------------------------------------------------------------------

- 04WebServer/1.86 -

まだやってんのか

俺はMZ-80K2Eから一足飛びでWindows98の乗ったDOS/V機だからその間の事はまったく分からん

久し振りにインタレ保持やってみたら設定わからなくて苦労したわ
残像インタレとかどこの馬鹿が考えたんだよ

インタレ保持するとうまく圧縮できなくて断念した記憶が

Adaptive MBAFFまだああああああああああああああ

そういえば、最近の家電のエンコーダの性能はx264より良いかも。

また家電屋さんがきた

とてもそうは感じないな
感想には個人差があっていいと思うけどね

家電は基本的に十分ビットレート振るからよく見えるんじゃないかな

ピークは足らんけどな

>>651 で書いてた珍現象ですがどうやらディスクトラブルだったようですorz
お騒がせしました

>>922
インターレース周りはx264よりよさそうではある

エンコード以前の処理が優れてるんじゃなくて？

とっくに抜かれてる。おまえらいいかげん現実見ろよ。
MS同様、開発ってのは結局、金かけたほうが勝ち。

ふーん
で、具体的に説明お願いするよ
その現実ってやつを

スゴ録最強君だろ
構うな

ソニー10倍録画最強君もいたね

懐かしいなｗ

x264_LSMASHでcrf 19未満かつmkv出力した場合に色が変になるバグが発見され修正されました。
ttp://github.com/silverfilain/x264_L-SMASH/commit/36513cae722db95152eb12ebe6a36d7c9858ebd9
↑で発生したバグですのでもし当てはまる方がいれば可能なら再エンコをお勧めします。

L_SMASHって何
普通のx264と何が違うの

>>936
x264 初心者質問スレ part3
http://hibari.2ch.net/test/read.cgi/avi/1269894718/

http://www2.accsjp.or.jp/criminal/2010/1020.php

またかよ・・・

話題にするには遅すぎる以前にこの板・スレに何の関係もない

だな、多すぎる
月何人だよ・・・

話が噛み合ってないw

馬鹿は自分が馬鹿だと気付かないから仕方ない

ところでx262ってどうなったの

>>942
自己紹介乙

>>943
ttp://github.com/kierank/x262

　PMP用エンコだと、考え無しに更新すると酷い目に合うな〜。
　更新したことすら忘れてて、PCでは普通に再生出来るんで原因に
気付くまでに随分時間がかかってしまった……。

PMPって改造PSPの奴か？
再生制限ずっと前に取り払われてるしいらない子だろ

portable media player

ああ、なるほど。
なんてややこしいんだ

Shareに放送直後のアニメをアップロード、無職男性を逮捕
http://www2.accsjp.or.jp/criminal/2010/1021.php

こら、プリキュア配信したらダメでしょ

典型的な穀潰しのクズだな
こんなクズが逮捕された事によってさらに税金が無駄に使われるのか思うと逮捕する価値すら無い
捕縛される前に落ちたら二度と浮かび上がって来ない淵にでも行って自分の始末くらいつけるのがダニにも一分の良心ってものだろう

捕まえなかったら被害が続く一方だし、これこそ税金の使い道だろ。

しかしこういうのって結局数年で出てくるからなぁ・・・出てきたらまた同じことするんじゃないのか？

一人芝居乙！不自然すぎるw

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

--------------------------------------------------------------------------------

- 04WebServer/1.86 -

そろそろ次枠か
ここの所安定してるのか更新頻度もペース落ちてきたね

寒いから暖房代わりに昼間から9時間掛かるエンコしてみたが
効果ないわ。そろそろ防寒対策しないと。

>>956
ダクト付けて足下に

っPenD

403 Forbidden
Request : GET
Object : /~seraphy/program/x264/


HTTP からのアクセスは、許可されていません

--------------------------------------------------------------------------------

- 04WebServer/1.86 -

もう引退だ、あきらめろ

あそこにしか置いてない物って何があったっけ？

DTSrepair
DTSedit

DTSeditだけストレージに保存しとくわ

でも急に居なくなるのはひどいよな。
一言お礼言いたかったのに

AviutlのKENくんだって何年も更新ストップ＆BBS荒れ放題だったから
死亡説まで流れてたけど近年復活して更新しまくりだし
プライベートが忙しいならしょうがないでしょ

リア充＞趣味
それにしてもさげない連投君は目障りだな

>>959
x264guiなら後継者が現れたよ
guiスレ覗いてみ

お蔭様で変なのも湧いてるけどな

やっぱGUIは必要悪なんだな

GUIは選択肢の一つというだけ
Windowsだって出た頃はいらねーといってたやつら山ほどいたし

そりゃ3.1はいらねーよｗ

ATの車は糞、男ならMTだな

昭和時代の人？

x264のCLIはMTみたいなもんだろ

そこまで難しくないけどｗ

GUIは都度ぷちぷち設定するﾄｺﾛがMTな雰囲気

CLIはね、解説ページが悪い。初心者には実行したいバイナリ指定して
そこにコマンド足すだけってのがなかなか理解できない、解説してる
HPとか余計な事ばしばし書いてあってそもそもの基本が書いてないから。

おまえさんがすばらしい解説ページを作れば全て解決

解決するどころか問題が増えるだけ。
基礎すら学ぼうとしない、空気読まずエチケットも守らず、下手をすればルールさえ顔が見えなければ平気で破る奴が多すぎる状況では、
初心者とそれを甘やかすような奴は嫌われて当然って風潮だし。

各所にサンプルも貼ってあったりしてかなり親切だと思うけどな〜
ワカンネってやつはただ面倒くさがりなだけなんだろう

2chだし仕方ないだろ

初心者ならオプションいらんだろ。
画質に拘るのは中級者になってからにしろや。

自分には赤ん坊時代なんてなかったと言い切れそうな人ばかりですね

初心者から半歩踏み出した奴が一番偉いんだぜ

次スレ
x264 rev29
http://hibari.2ch.net/test/read.cgi/avi/1288510853/

偉いとか偉くないの問題じゃねぇのに。
馬鹿だねぇ。

GUIに慣れた人が、コマンドプロンプトにとっつきにくいのは確かだと思うけどね

x264を使うためだけにコマンド操作覚えようってのは二の足踏むだろうな
間違いなく物好きしかやらないよﾌﾋﾋ

Avisynth導入より楽だと思うけどな
いきなりどっちも初体験は厳しかろうが

皮肉にまともに突っ込んで馬鹿とはおもしろいねぇ

皮肉の意味を理解できているとはとても思えないなｗ
こんなやつに比べればツンデレ嬢のほうが百倍マシに思える。

x264 -o output input に必要に応じたオプションを足していくだけだから、
やる気があるのなら、すぐに使える様になるだろう。

素で変換するだけならcuiなんていらないだろ

素(--preset medium --crf 23.0)でやっても、そんなに酷い事にはならないと思う。
これにソースに合った--tuneでも付けておくだけで、大抵の人には十分だろう。

でも初心者ほどオプションにこだわる傾向があるような気がする
意味わかんないけどオンにしてみよう見たいな

--sar --crf --tff --output ぐらいしか使わないな
--no-mbtree を使ってた頃もあったけど

mbtree ありで、qcomp は弄らないの？

デフォルトの0.60で問題はないだろう。--no-mbtreeにするくらいなら、これを大きくするのはありだと思うが。

ソース次第だけど俺は変更してるよ

デフォでも前に比べればよくなったと思うよ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。