x264 rev16

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

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

[本家]
http://www.videolan.org/x264.html
http://trac.videolan.org/x264/browser/trunk (ソース)

[バイナリ]
http://x264.nl/
http://forum.doom9.org/showthread.php?s=&threadid=89979
http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/
http://oss.netfarm.it/mplayer-win32.php (mencoder)
http://forum.doom9.org/showthread.php?s=&threadid=87567 (MeGUI:mencoderのGUI)
http://tirnanog.fate.jp/mirror/gpac/dev/　(mp4box)
http://yamb.unite-video.com/　(YAMB)

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

再生方法、規格、インタレ規格、Avisynthの使用法、コンテナ等、
専用のスレがある話題は各専用スレ>>2-4でおながいします。
スレタイ検索 http://find.2ch.net/

テンプレ続く>>2-4

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

Avisynthの話題は
Avisynthを絶讃ιょぅょ Part25
http://pc11.2ch.net/test/read.cgi/avi/1206362521/

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

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

MeGUIスレッド
http://pc11.2ch.net/test/read.cgi/avi/1164533110/

[FAQ]
Q x264.exeをダブルクリックしてもインストーラーが立ち上がらない。
A コマンドプロンプト用の実行ファイルです、インストーラーでも圧縮ファイルでもありません。

Q 見れないよ
A x264.nlでmatroska splitterとffdshowを入手してインストール汁！ハードウェアでインタレ解除する場合は、
　　ビデオデコーダーの設定→出力→インターレース関連情報を…にチェックを入れること。
　　またはMPlayerやVLCなどのデコードエンジン内蔵のプレーヤーで試す。 これらで見る場合はffdshowは必要なし。

Q AviUtlやVirtualDubとかで読むとエラーでて編集できないんですが・・・
A 諦めろ。編集はエンコード前にするのが常識。

Q Win版QuickTimeで再生できない。
A　QuickTimeはインタレ、ハイプロファイル(-8、--8x8dct、--cqmなど)、--b-pyramidに対応していない。 Bフレ1以下推奨。

Q 携帯機やゲーム機などで再生させるには？
A　それぞれ専用のスレがどこか（他の板も）にあるはずなのでまずは当たってみてください。

Q バージョンアップ早すぎ
A バージョンアップでなくビルドアップです。例えばソースの清書、サイズの収縮などユーザーにとってあんまり意味のない改変でも更新されてます。

Q >>‎1のどのファイルがいいの？
A 迷う奴はx264.nlのを使え。GUI操作が好きな人は同ページにあるMeGUIやStaxRipも。マイクロソフトから.NETのインストールも忘れずに。

Q　エンコードできない。
A　基本的に色空間がYV12のavsファイル(Avisynth)しか受け付けません。（MeGUI、StaxRipも含む）

Q　MP4のVFRってどうやるの？
A　前知識として、そのまま"MP4 VFR"等で検索して、ISOMPEG-4スレへどぞ。

Q　アスペクトの指定ってどうやるの？
A　704x480を4:3で見る時は--sar 10:11、 720x480を4:3で見る時は8:9。他は各自計算してください。
　　720ｘ480を16：9で見たい時、par(sar)x：yはx：y=480×16：720×9で求められる。

Q　--interlacedで失敗する。
A　入力ソースは縦が32の倍数のトップフィールドファーストで。

その他パラメータの勉強は
ageha
http://agehatype0.blog50.fc2.com/
QPオプションの目安
http://www.wikihouse.com/htumenc/index.php?Man%2FCODEC%B8%C7%CD%AD%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3%2F-x264encopts%2Fqp

aviから移行してきた人への簡易見本。704x480の24pと仮定。
Avisynthの2.5以降のバージョンをインストールする。
mp4boxを用意する。
映像は可逆圧縮コーデックでaviを作成する。
音声は別に作成しておく（C:\hogehoge\test.m4aに存在すると仮定）。

echo AviSource("C:\hogehoge\test.avi") > "%temp%\avi.avs"
echo ConvertToYV12() >> "%temp%\avi.avs"
"C:\hogehoge\x264.exe" --crf 20 --progress -o "%temp%\avi.264" "%temp%\avi.avs"
"C:\hogehoge\mp4box.exe" -fps 23.976 -add "%temp%\avi.264":par=10:11 -add "C:\hogehoge\test.m4a" -new "C:\hogehoge\test.mp4"

↑の4行をコマンドプロンプトに右クリ貼り付けenterで完成

↓batファイルにD&Dするだけ用

set x264="C:\hogehoge\x264.exe"
echo AviSource("%1") > "%temp%\avi.avs"
echo ConvertToYV12() >> "%temp%\avi.avs"
%x264% --crf 20 --progress -o "%1.264" "%temp%\avi.avs"

　　 _,,....,,_
-''"::::::::::::::::＼　　　　　 　新スレだってさ
ヽ::::::::::::::::::::::::::::＼　　　　　　　　　　　　　　　　　　　おお、>>1乙>>1乙
　|::::::;ノ´￣＼:::::::::::＼_,. -‐ｧ　　　　　＿_　　 _____　　 ＿_____　
　|::::ﾉ　　　ヽ､ヽr-r'"´　　（.__　　　　,´　_,, '-´￣￣｀-ゝ 、_ イ、
_,.!イ_　　_,.ﾍｰｧ'二ﾊ二ヽ､へ,_7　　　'r ´　　　　　　　　　　ヽ、ﾝ、
::::::rｰ''7ｺ-‐'"´　 　 ;　 ',　｀ヽ/｀7　,'＝=─-　　　 　 -─=＝',　i
r-'ｧ'"´/　 /!　ﾊ 　ハ　 !　　iヾ_ﾉ　i　ｲ　iゝ、ｲ人レ／_ルヽｲ i　|
!イ´ ,' |　/__,.!/　V　､!__ﾊ　 ,'　,ゝ　ﾚﾘｲi rr=-,　　 r=;ｧ 　.| .|、i .||
　`! 　!/ﾚi'　rr=-,　　 r=;ｧ ﾚ'i　ﾉ　　　!Y!　￣　　　￣　　 「 !ﾉ i　|
　,'　 ﾉ 　 ! 　￣　　　 ￣　 i .ﾚ' 　　　 L.',.　　'ｰ=-'　　　　L」 ﾉ| .|
　　（　　,ﾊ　　 　'ｰ=-' 　 人! 　　 　　 | ||ヽ、　　　　　　 ,ｲ| ||ｲ| /
　,.ﾍ,）､　　）＞,､ _____,.イ　ハ 　　　 　レ ル｀ ー--─ ´ルﾚ　ﾚ

おっおっお（ ^ω^）

989 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:05:44 ID:8v7RmilU
tobinakaってここで少々叩かれたぐらいでwiki閉じたやつだよな？
今度はseraphy氏に絡んでるようだが、メールに何書いたんだ？
最前線とかの単語がでるって、代わりにwiki作れとか言ってるんじゃないだろうな。
seraphy氏のレスから迷惑そうな空気を感じるんだが。

990 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:22:54 ID:TDP5cuby
なに、最前線君がどうした？

991 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:35:13 ID:aNa3nuYd
wiki作れはないだろｗ
Doom9のフォーラムに来てくれって事じゃないの？OreAQとかMixAQの説明してくれって感じで
んでseraphyさんはそんなに空き時間もないし細々とやっていくんで遠慮しておくって話なんじゃないかな

992 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 15:10:08 ID:8v7RmilU
tobinakaってやつのブログ見てきた。
プログラム読めないからOreAQやMixAQの説明ができないと言ってるから、>>991が正解のようだ。
なんだこいつ。勝手に向こうで紹介しておいて、説明できないからって作者に説明しろ言ってるのか。

ペガシス、「TMPGEnc 4.0 XPress」にNVIDIA GPUエンコードを実装へ
http://pc.watch.impress.co.jp/docs/2008/0826/pegasys.htm

NVIDIA(笑)

最低でもATIですわ

最高だと？

前スレ埋まった。
>>1　乙

前スレの994ってマジで言ってないよな？

GPUエンコードか…オラ、なんだかクワクワしてきたぞ

ｘ264でも採用して欲しい

TMPGEnc 4.0 XPress買っているけど、x264に移行してから一切使わなくなったから、
x264のフロントエンドとしての機能を充実させてくれないかなぁw

そんななら夢のvfw版を作ってTmpgで簡単に使えるようにして欲しい
ちょい変なバイナリ吐き出して専用ツールで多重化するとちゃんと問題ないmp4になるようなのｗ

私が扱うソースはYV12だから、RGBで処理するTMPGよりYV12のままSynthでやった方が速い。

TMPGがRGBで処理とかいつの時代の話だよ

今はRGB24のVFAPIの代わりになる物があるの?

A Full Test of Elemental's GPU Accelerated H.264 Transcoder
http://www.anandtech.com/video/showdoc.aspx?i=3374&p=5

TMPGEnc 4.0 XPress のGPU対応はﾌｨﾙﾀ部分らしいよ。
CPUとGPUどっちも遊ばせたら勿体無いから、CPUでｴﾝｺ＋GPUでﾌｨﾙﾀﾘﾝｸﾞでいいんじゃないかな。　逆でもいいけど。

950
Activate trellis in p8x8 qpel RD
Also clean up macroblock.c with some refactoring
Note that this change significantly reduces subme7+trellis2 performance, but improves quality.

> significantly reduces subme7+trellis2 performance
え〜

but improves quality

submeが6でtrellisが1な俺にはどうでもいい。で、おｋ？

奇遇だなおれもだ・・・

>>VFRmaniac氏へ

Experimental Patch: Psy RD 0.6 (updated for r950)
http://forum.doom9.org/showthread.php?t=138293

950きたな

次スレの季節か

早っ

もうちょいで夏が終わるな

>>20
そういやこれって使い物になるの?
どっかにエンコ時間かいてねーかな・・・

951

951は--b-adapt 2　の処理方法変わった？

951OreAQ版異様に遅いのは俺だけか

俺もfps半分以下になった

--bframe 3 しか入れてないから--b-adapt 1で通してきた。。。
それでも効果あるなら2にしようかと思ったけど新リリース待ちかな

Doom9で b-framesの数について討論されてるね。
Dark Shikari : bframes 3 to 6 give almost no benefit for the vast majority of sources, while ref 3 to 6 is guaranteed to help at least a bit.
だそうだ。

以前から言われている様に、--bframes 3くらいが無難か。

ちょっと tobinakaさん!?　何を勝手に海外からリンク貼ってるんですか。
http://72.14.235.104/search?q=cache:gBDg4DwjeSoJ:zoome.jp/VFR_maniac/diary/17+tobinaka&hl=ja&ct=clnk&cd=5&gl=jp

http://forum.doom9.org/showthread.php?p=1172141#post1172141
seraphy氏には断っておいて、私には断りなしであることに著しい差別を感じる... (笑)
世の中には差別は必要ですけどぉ。
いや、まぁそれ(断りを入れる)だけのためにeSnipsにアカウント作るというのはどうかというもので、そう考えると理解できます。

Doom9's ForumからリンクされちゃったのはeSnipsの方ね。
http://www.esnips.com/web/VFRmaniac-Softwares
tc2mp4Mod とか実験色の強い x264_EXPERIMENTAL はこちらに置いてあるのです。

今回の件で海外でもOreAQやMixAQが浸透するのだろうか。
現行x264メイン開発者はｱﾆｦﾀだしな。(笑 -> akupengvado)
Dark Shikari氏は東方ｦﾀみたいだし。

>>40
そんなにここを荒らしたいのかｗ
もっと有益なことを話そうぜ('A'

やっと俺もエンコ再開しましたよ

断りなしで張られるワロタｗ VFR maniac氏乙いな・・・

リンクを貼られたくらいでいちいちファビョってたら、サイト運営なんてできないぞ

そんな広い世界じゃねーよ

webで広いも狭いもないだろｗ

ネットはﾋﾛ大だわ･･･

うーん確かに適当ではなかったか
いずれにせよ匿名でもないのに(匿名だからいいという訳ではないが)
こういうことを平気でやるってのはやっぱアレだろ

tobinaka、軽いキチガイに感じるのは俺だけだろうか。

まあ余計なお世話感はするわな。

別にリンク貼られたくらいではなんとも思わないかもしれないけど
2箇所紹介して片方は断り入れてるのに片方はスルーなのがどうかと思ったんだろ

行為そのものは我々にとっていいことになるかもしれないけど余計なお世話にならんようにな。

機械翻訳(笑)

Emerging Companies Summit編その2Elementalの超高速H.264エンコーダは9月登場ほか
http://pc.watch.impress.co.jp/docs/2008/0828/nvision05.htm

Pro版が100ドルもするんじゃあなあ・・・しかもx264はフリーの中でもとりわけ優秀らしいから
それに匹敵する位じゃないと速度と価格のバランスが取れないなあ、俺的に。

tobinaka叩きしてるのってwikiできたとき叩いてたやつと同一人物だよね？
ついにx264もアンチがつくくらいのところまできたわけかｗ

wikiは叩かれる理由はなかったと思うがあえていうなら宣伝場所が悪かった。
今回は陰口叩かれても仕方ないと思うがなあ。
>>54
正直デモ版使った限りじゃ買いたくはないな・・・

r02きてるけどどーっすか

速度戻ったみたい

どの辺まで戻ったのか知りたい
今889R2で止まってるから

950までは特に問題なかったと思うけど

>>58
935から951r2に変えてテストしてみた

x264OreAQ.935.release01 0.59fps
x264OreAQ.951.release02 0.58fps

r1はやってないからわからないけど問題ないみたいだよ

うちの環境じゃSD動画のエンコでは1~2fpsほど落ちてる気がする
シングルコアだけど

r2で2.8fpsでるようになった…
r1で0.6fpsとか出た時はどうなったのかと思ったよ…

アニメのエンコで --cqm "flat"にするか --cqm "jvt"にするかでいつも悩む

>>65
比較画像を張りまくるんだ。

俺はjvtよりちょっとサイズ膨らむようにしたの使ってる。
セル画いがいのアニメはそれでほぼ満足。

x264OreAQ.935.release01
--crf 18 --sar "1:1" --level "4.1" --aq-strength 1.0 --psy-rd 0 --aq-metric 0 --aq-sensitivity 10
--scenecut 54 --min-keyint 1 --keyint 300 --8x8dct --partitions "p8x8,b8x8,i4x4" --b-adapt 2 --bframes 6
--b-pyramid --bime --weightb --direct "auto" --b-rdo --subme 7 --me "umh" --merange 64 --ref 5
--mixed-refs --threads "auto" --trellis 2 --deblock -2:-2 --cqm "flat" --no-fast-pskip
--no-dct-decimate --progress

sample1: --cqm "flat"
ttp://uproda.2ch-library.com/src/lib049545.png
sample1: --cqm "jvt"
ttp://uproda.2ch-library.com/src/lib049546.png

sample2: --cqm "flat"
ttp://uproda.2ch-library.com/src/lib049547.png
sample2: --cqm "jvt"
ttp://uproda.2ch-library.com/src/lib049548.png

flatだとブロックが目立つ感じになるけど一長一短なんだよなあ

全然違いがわからんorz
とりあえずわっちがかわいいことはわかった。

flat行列の左上周辺だけjvtと同じにしたら

ソースが悪いな・・

>>69
動いているところの方がわかりやすいんだけど、
１枚目だと真ん中のおっさんの背中の辺
グラデーションがゴツゴツした感じに見えるのがflat
>>70
すまない、もう少し詳しく教えて下さい
>>71
ソースはDVDでNRは一切やってない状態
そういう意味ではなくてシーンが悪いという意味？

bitrate固定でやらんと

DVDのアプコンはソースのブロックやリンギングが目立つだけだな。

>>72
>>70は字面どおりだと思うが。低周波の量子化ステップを下げればブロックは減るだろ。
あと>>73も言ってるけど固定ビットレートにしないと意味ないだろ

tobinakaが叩かれてるのは少し中傷されたくらいでサイト管理放棄したことと
海外サイトに図々しく宣伝した行動などが原因

x264の開発と関係のない個人の話はどうでもいいからもう放っておけよ

>>68
最近アニメのエンコやってないのであまり役立たないかもしれないから、独り言のつもりで聞いてくれや。

flatやjvtでdeblock -2:-2は弱すぎてブロックが目立つと思う、状態を比較するために設定したなら良いけど。
flatならpsy trellisを使うと良くなるかもしれない、1だと強いので弱めにした方が良いと思うけど。
それとsub MBのi8x8は入れた方がいい気がする、アニメだと逆効果だったらごめん。

ソースがDVDだと・・

>>68
sample1はどちらもいい感じだけど個人的にはflatが好き。jvtはなにかブロックがゴチャゴチャしてるような感じ
sample2はjvtの方がきれいに見えるけど、鼻の先っちょのブロックが気になった

俺はflatでブロックが気にならなくなるぐらいにQ値下げてるよ
jvtよりサイズ的にはまだまだ余裕があるぐらいだ

ビットレート指定でやってみた。
ttp://uproda11.2ch-library.com/src/11114160.7z.shtml (DLｷｰ:dtv)

こういうときってpsyどうするの？

いつも使ってる設定からbitrateにだけ変更してやってみた。
NRはあんな重いの使ってないけど＾＾；

なんか突っ込みあれば、もう一度やりますね。

暗部と明部はブロックの出方が違うから必ずアニメは+3、+3のデブロックフィルタをかけること。

>>68
なんだこのブロック目立ちまくり、バンディング目立ちまくりの
クソ画質キャプチャーは…。
trellis抑えるか、psy-rdを弱めに入れておけ。
これPS3とかで液晶テレビに移したら最悪なことになるぞ。

ありがとう、凄く参考になったよ
>>86
これは特に目立つシーンを探して抜き出してみたんだけど、
暗部のグラデーション部分がどうしてもあんな感じバンディングが目立ちまくる・・・

バンディング目立つのは自分の安ディスプレイやキャブレのせいな事もあるので
批判は伸張にｗ

環境はすげーあるね。俺はこのほうが見やすいんだ！とかいう人の
ディスプレイ設定はまじで危険。泣きそうになる。

TNで批判とか持っての他だよな

でも高い液晶でも広域色パネルとかでは色めちゃくちゃだよな
安くてもNTSC72%のsRGBが一番だよ

ディスプレイ特性以外にも、見る環境の光源とか
見る人の視力とか様々な要素があるから本当の評価って難しいよな

ソースに無いアーティファクトを見分けられたら、とりあえずは十分だと思う。

色々意見ありがとう
それなりにソースに近い感じになってきたと思います
NRかけろとかはスレチだと怒られそうなので置いといてｗ

ソースとエンコした物とエンコ用のバッチファイル
ttp://www2.age2.tv/rd10/src/age0576.zip.html pass=dtv

※グラボのドライバを変えたので>>68とは違います

僕がおまんまんの洗い方を教えてやる！

1.指を添える
2.V字に開く
3.開帳の儀
4.本番

誤爆

【審議中】
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

最近のTNはともかく2，3年前のモデルはちょっとアレだな

デカイ電気屋の店頭のパソコンやTV眺めるとどれもコントラストも色合いも輪郭も
見事にバラバラなんで細かい色や画質のこと言うのなんてアホくさくなってくるよね・・・ｗ

古い環境とかだとYC伸張されなかったりして全く変わって見えるから・・・
YC伸張しなかったらそれほどバンディングも目立たない
最初の頃はエンコーダに渡すオプションなんてcrfやビットレート上げれば綺麗になるんでしょ
って感じの認識しかなかったのに、最近になってエンコーダのオプションが画質を大きく左右することに気付いたよ
というかこのアニメは俺には無理だorz

そういえばOreAQのICC版ってC2D互換CPU用って書いてあったけどPentium4 Prescottでも動くんだね

>>94
全角でパス指定とか最後まで迷惑なやつめ！

>>102
ほんとだorz
ごめんなさい、ごめんなさい、>>94のパスは全角で「ｄｔｖ」です

>>94
全角パスだとはｗ

人のソース丸ごとはめずらしいので、勉強になります。

>>72
こんな感じじゃないのか？
まあ、DOOM9 の書き込みを適当に弄っただけだからろいろミスってるかもしれんが。

エンコテストはしてないし、どんな感じになるのか分からんから自己責任でよろ
http://www.age2.tv/rd05/src/up1312.zip.html
PASS : x264Matrix

>>105
凄く参考になりました！
ありがとうございます
>>68の設定でflat+jvt(Top right corner).cfgで試したらかなり改善されました

>>106
あー、普通に名前付け間違えた・・・
flat+jvt(Top right corner).cfg になってるしorz

けどマトリクス自体は正しく左上を置換してますので、
Top left と思っておいてくださいな。宜しく〜

>>106
ttp://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-03E (ｶｽﾀﾑﾏﾄﾘｸｽについて)

誰も相手にしてくれなくて寂しかったんで、ソース追加して再うｐ。
ttp://up.mgdbbs.net/src/0177.zip.html (DLkey:dtv)

(OreAQr951_02)"x264.exe" -p 2 --bitrate **** --stats ***.x264 --level 4.1 --keyint 240 --min-keyint 1 --scenecut 70
--b-adapt 2 --bframes 3 --b-pyramid --b-rdo --bime --ref 6 --mixed-refs --qpmin 10 --qpmax 30 --qpstep 12
--ipratio 1.4 --pbratio 1.3 --aq-mode 2 --aq-metric 0 --aq-strength 0.5:0.5 --aq-sensitivity 10 --qcomp 0.7
--partitions p8x8,b8x8,i8x8,i4x4 --8x8dct --direct auto --me umh --merange 32 --subme 7 --trellis 2 --psy-rd 0.0:0.0
--no-fast-pskip --no-dct-decimate --cqm *** --deblock 0:0 --threads auto --sar 40:33

source.avi、jvt.mp4、flat.mp4のみで静止画は入ってないので、AviUtlのmp4input辺りで見てやってください。

BDソースとか無いのかなあ

秒速5ｾﾝﾁならあるが･･･

>>108
激しく乙。参考になった

青い円盤のソース上げてみた。ちょいでかいです
ttp://muahome.ddo.jp/~Uploader/
のFileNumber 6083001803302
x264

x264OreAQ.953.r1
--bitrate 8000 --pass 3 --stats ".\test1.stats" --aq-mode 2 --aq-sensitivity 9.5 --aq-strength 0.5:0.5 --ipratio 1.4 --pbratio 1.3
--qcomp 0.7 --qpmin 1 --qpstep 16　--scenecut 60 --min-keyint 1 --keyint 240 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4"
--bframes 4 --b-pyramid --bime --weightb --b-adapt 2 --direct "auto" --direct-8x8 -1 --b-rdo --subme 7 --me "umh" --merange 32
--ref 6 --mixed-refs --threads "auto" --trellis 2 --no-fast-pskip --no-dct-decimate --cqm "flat" --psy-rd 0:0
HDエンコとかほとんどやんないんでオプションなんでも突っ込んでくれ

8Mbps-ABRだとディザっぽいノイズは全部つぶれちゃうな

>>112
ノイズ演出は下のサイトが参考になるかも。
あとpsy-rdoを1以上でかけると良いかも。

グレインノイズを残すには | x264 @ Charlie's volatile short
ttp://blog.mura.com/blogs/index.php/charlie/2008/08/03/x264_zone_quality_control

2008/08/30 AviUtl version0.99f を公開

もう30分前に知ってる情報をいまさら・・

30分だとさすがに「もう」とは呼べなくないか
ニュー速とか見てるやつならまだしも普通はそんなにすぐ気づけないって

ｳﾌﾌ（✿◜◡‾）（‾◡◝✿）ﾔｰﾈｰ

>>113
今まで試す時間なかったから敬遠してたけどpsy-rdは高周波強調されて結構いい感じだね。
ただソースにはない粒が一部見られるのがアレだけど

p4x4 が使えるようになったという記事があった。
上がp8x8,b8x8,i8x8,i4x4、下がp8x8,b8x8,i8x8,i4x4,p4x4。
ｿｰｽは>>108。 同じOPから4箇所だからあんまり意味無かったかもしれん。

x264 [info]: SSIM Mean Y:0.9966588
x264 [info]: PSNR Mean Y:51.336 U:53.572 V:53.983 Avg:52.004 Global:51.960 kb/s:1778.54
encoded 50 frames, 3.35 fps, 1781.16 kb/s
x264 [info]: SSIM Mean Y:0.9966834
x264 [info]: PSNR Mean Y:51.327 U:53.560 V:53.974 Avg:51.995 Global:51.951 kb/s:1771.44
encoded 50 frames, 3.41 fps, 1774.05 kb/s

x264 [info]: SSIM Mean Y:0.9904920
x264 [info]: PSNR Mean Y:47.248 U:50.846 V:51.181 Avg:48.170 Global:48.053 kb/s:3164.83
encoded 50 frames, 2.03 fps, 3167.42 kb/s
x264 [info]: SSIM Mean Y:0.9904528
x264 [info]: PSNR Mean Y:47.217 U:50.830 V:51.146 Avg:48.139 Global:48.020 kb/s:3160.23
encoded 50 frames, 1.97 fps, 3162.83 kb/s

x264 [info]: SSIM Mean Y:0.9934620
x264 [info]: PSNR Mean Y:49.689 U:51.967 V:52.253 Avg:50.352 Global:50.184 kb/s:3385.46
encoded 50 frames, 2.12 fps, 3388.50 kb/s
x264 [info]: SSIM Mean Y:0.9934672
x264 [info]: PSNR Mean Y:49.681 U:51.961 V:52.240 Avg:50.343 Global:50.176 kb/s:3394.67
encoded 50 frames, 2.10 fps, 3397.72 kb/s

x264 [info]: SSIM Mean Y:0.9925639
x264 [info]: PSNR Mean Y:47.743 U:51.068 V:51.731 Avg:48.636 Global:47.884 kb/s:3848.73
encoded 68 frames, 2.12 fps, 3850.97 kb/s
x264 [info]: SSIM Mean Y:0.9925629
x264 [info]: PSNR Mean Y:47.697 U:51.015 V:51.672 Avg:48.589 Global:47.838 kb/s:3841.53
encoded 68 frames, 2.09 fps, 3843.77 kb/s

p4x4が逆効果だっていう話は結構前に解決してるけどほとんどよくならないし若干重くなるしでほとんど使われてないね

個人的にはやっぱり逆効果に見えるｗ
拡大縮小してみた。

320x240
x264 [info]: SSIM Mean Y:0.9918784
x264 [info]: PSNR Mean Y:47.134 U:49.719 V:50.102 Avg:47.870 Global:47.620 kb/s:1200.12
encoded 50 frames, 7.53 fps, 1203.17 kb/s
x264 [info]: SSIM Mean Y:0.9919035
x264 [info]: PSNR Mean Y:47.126 U:49.707 V:50.091 Avg:47.862 Global:47.612 kb/s:1200.59
encoded 50 frames, 7.42 fps, 1203.63 kb/s

1440x1080
x264 [info]: SSIM Mean Y:0.9956070
x264 [info]: PSNR Mean Y:52.497 U:54.428 V:54.618 Avg:53.068 Global:52.929 kb/s:11555.14
encoded 50 frames, 0.52 fps, 11558.39 kb/s
x264 [info]: SSIM Mean Y:0.9956051
x264 [info]: PSNR Mean Y:52.494 U:54.420 V:54.606 Avg:53.064 Global:52.925 kb/s:11562.62
encoded 50 frames, 0.51 fps, 11565.87 kb/s

従来通りの認識でいいんじゃないかと思った。

で、お前らcore i7買うの？

--b-adapt 2にすると3倍くらい遅くなる…
1にしようかしら…

ねーよｗ
2試してみると1はなんちゃって実装だったんだなとわかる

>>123
--bframes 16 とかにしてるなら減らすと幸せになれる。

b-adapt 2は実写ならあまりfpsは下がらないな
Bフレ5くらいまでなら十分使えるような気がする

俺は--no b adaptにしてる、つか意味ねー

すまん折れは1パスだった

>俺は--no b adaptにしてる、つか意味ねー

逆に--no b adapt指定って、何の意味があってやってるの？
可変だと再生に問題が出るデバイスがあるとか？
Bの枚数固定にしたら、速度的な恩恵0で画質が落ちるだけだと思うが。

b-adapt 2 と b-pyramid って併用してよかったっけ？

>>127
--no-b-adapt つかうくらいなら --b-adapt 1 のが万倍まし

>>130
うちは問題ないように見える

すまん俺は何か勘違いしてたようだ
H264はテストエンコ中だから助かった

今検証してみたがありなしではサイズも時間もSSIMも殆ど変わらなかった
テストエンコに使ってるのがマクロスF7話のAパート冒頭30秒ぐらいだから
動きの無いシーンでは差が出るのかもしれない

サイズと時間とSSIMだけ気にしてエンコするのか・・・

他はもう煮詰めてるからな、今のところそんだけ

>批判は伸張にｗ

根っからのDTVマンだな

>>112
これAviUtlに読み込むにはどうすれば・・・

>>137
いい機会だからavisynth使ってみな

readmeにある通りsynthで読めれば経由してaviutlで開けるようになるから

--b-adapt 0 にしてもフレームは --b-adapt 1 と同じになるな。なんでだろ･･･
no b adapt のときに切らなくちゃいけないオプションってあったっけ？

同じじゃなかった。けど --bframes 4 にしても4枚連続使ってくれない

--b-biasとかなんだっけ

>>142
Bフレームを挿入すべきか判定するときの閾値

Doom9のb-framesスレを斜め読みしてて、weightbに関して勘違いをしてたので、抽出して貼っとく。(俺だけか；)
ttp://forum.doom9.org/showthread.php?p=1164258#post1164258(Dark shikari「weightbを入れて下さい」)
ttp://forum.doom9.org/showthread.php?p=1164829#post1164829(weightbって非推奨では？→改善されました)
ttp://forum.doom9.org/showthread.php?p=1165318#post1165318(ｱﾆﾒでも害にはならないので、安心して入れていいです）

b-pyramidは、私は有用なオプションじゃないかと思ってます。(現在b-frames 3使用中)

b-pyramid付けたいけど音声のディレイうんたらが面倒そうで抜いたまま

>145

音ずれのこと？
特に問題が起こったことは今までないな。

b-pyramidはGPU再生支援に問題あったようだから使っていなかった
今では直ったんだっけか

大丈夫

再生支援とかPS3に関しては大丈夫になったけど
b-pyramidは見捨てられてる感がある開発から

でもBピクチャの参照フレーム化はH.264で標準の機能だからきちんと動作しないとね

889r2→953r2に変更した
若干時間とサイズが小さくなったけど案の定SSIM値が低くなった
何が変わったのか分からんが

DXVAはまだ若いから全部のオプションで問題なくなるには
もうちょっとかかるだろうな

現状でCoreAVCで1080pが何の問題もないけどなｗ
DXVAで全てのオプションカバーするようになるころには
その頃のローエンドCPUで1080pでも処理落ちしないだろうけどなｗ

GPUも糞だったら処理落ちするだろうね

>>145
VFR Maniac氏のビルドで --no-b-adapt を入れれば問題ない。
あと、Haali Media Splitterが動画デコード用のディレイを無視するので
動画の方をずらして音ずれを相殺すると環境次第でかえっておかしくなる。

＞あと、Haali Media Splitterが動画デコード用のディレイを無視する

まじかー　っとはおもてたが・・　まじか・・

>>155
他の多くのデコーダー
Gabest PowerDVD 他… デコーダーではないがニコニコ動画も
はちゃんと動画デコード用のディレイを反映する。

MPCのスプリッタでええやん

初期ディレイカットすればとりあえず問題ないけどな。
ニコニコ蹴られるとかいう話は知らん

>>154
--no-b-adaptも--b-adapt 0 も同じだ。
どうせ--threads 2以上を指定しているだけだろ。

あ…
>>154
× no-b-adapt
○ no-b-delay

だった。
何やってるんだ…

>>155
まじでorz
と思ったら、ディレイカットとか余分な事しなくても、Haaliではちゃんと再生してくれるってことか。
"動画デコード時のディレイを相殺する"　だよね？

で、>>158の言うとおり初期ディレイカットしとけば、Haaliも含め全てのスプリッタでちゃんと再生可。(再生出来ればｗ)
でも、ディレイカットじゃなくてズラしての修正は、Haali等ディレイを相殺するスプリッタではズレてしまうと。


ってことだよね？　間違ってたらすまんorz

>>157
MPC(mpc2kxp116040_jpn_r5_lite.zip)のスプリッタ試したら、とりあえずx264のsarは無視されたｗ

>>158
蹴られるなんてあるのか
実験で普段通りのcrf(1pass)でちょっとゴニョゴニョしてやってみたが普通にいけたなあ

>>163
smileでMP4サポートした初期は初期ディレイカット設定してると蹴られることがあったみたい。
何度か仕様変更してるから今はどうなるかは試してないからわからない。

Avisynthの人は初期ディレイカットどうやるんだ

っDTSEdit

>>122
もちろん買うよ。
OSをxpかvistaにするか悩む。

Windows7まで待った方が良い っていうのはスレチだから言わないでおく

>>166
どうも。身近にありすぎて気がつかなかった

エンコした動画の確認用Codec何使ってる？CoreAVC？
CoreAVCならDeblocking=Standardの状態で確認派？それともSkip always？

なんでSkipする必要があるの？

どのデコーダー使っても同じレンダリング結果になるんだから何でもいいんじゃねーの。
インループフィルタ強制的に切ると下手したら破綻しないか？

するにきまってるじゃん

SD解像度を500kbでも充分に見れるがデブロック入れないと酷いことに

＞どのデコーダー使っても同じレンダリング結果
PowerDVDとか独自の高画質化処理が好きだぞｗ

>>175
それは後処理の問題でデコーダ関係ないやん

>>85
デブロックは＋にしていいのか？

HDサイズで＋にするのはあまりお勧めはしない
暗部のブロックノイズが大きなブロックノイズになるだけだからな
宇宙空間とか余計に目立つようになるぞ

「Sharktoothによればアニメは3:3が良いとの事。」
て、Fraternity7書いてあったね。だからか。
暗部の多いソースは−にしときゃいいのか。

Sharktooth氏はflat派じゃなかったっけ？だったらデブロック強くかけるのもありだと思うけど
AQとかマトリクスとかきちんとかかってれば強くかける必要もないんじゃないかな

むこうの国の適当なアニメなら+3:+3でいいんだろうけど
こっちのように繊細な描写なアニメは-じゃないとのっぺりしちゃうんじゃないかなあ

ちなみにHDサイズになるとブロックのサイズが小さくなるだけで無くなるわけじゃないぞ
俺は2:2に落ち着いたがな

PHLにおけるMPEG-4 AVC/H.264エンコーダ開発の今
日本のアニメ最適化にも取り組みたい
http://av.watch.impress.co.jp/docs/20080902/avt029.htm

>>183
＞たとえばX-MENなどは、画面に近づいてみると驚くほど細かい粒がランダムに流れるような映像になっていることがわかる。
＞こうした粒子の固まりは、映像圧縮時に多くの情報を必要とし、圧縮率を高めていくと情報の不足がブロックノイズとなって画面を著しく汚す。
＞
＞このため、ほとんどエンコーダでは、こうした粒子をフィルタで潰してからエンコードする。シネマクラフト製エンコーダなどは、
＞あらかじめフィルタを通すのがデフォルトになっているほどだ。その方が圧縮は圧倒的に楽になり、ブロックノイズも少なくなる。
＞しかし、同時に細やかなディテールや立体感は失われ、素材の描き分けは浅く、全体にノッペリとして精細感のない絵になってしまう。
＞
＞「我々のエンコーダはプリフィルタを一切使わず、それでいてブロック歪みの少ない映像になるよう開発している。
＞マスター映像の雰囲気を損なわずに家庭に届けるのが目的と考えるからだ。フィルタをかけた映像は、一見、特に小さい画面では"見やすい"映像になるが、
＞しかし、明らかに情報は減ってしまう。せっかくフルHDの時代になり、DVDの6倍もの画素を獲得しているのに情報を減らすのでは、フルHDの意味がない(柏木氏)」

さすが宗主様は違うねえ。
しかしJVTは全くアニメを考慮していないのか。
x264の--cqm "jvt"がアニメで良い結果が出ないのは当然なんだな。

安物の糞ディスプレイでもVC-1のハリポタとPHL-H.264のﾊﾟｲﾚｰﾂｵﾌﾞ〜の画質の違いがわかる(様な気がした)。
少なくともVC-1はグレインの圧縮は一番苦手でほとんどつぶれてた印象があるな。

PHLのエンコーダーはフィルムグレインまで残すように符号化するけど最適化しないとゴワゴワした絵になるらしい。
JVTの標準マトリクスは高周波を完全に捨ててるからな。輪郭線がかなりぼけるね

盲目的にNaruPのマトリクス使ってるなぁ
やっぱりflatの方が幸せなのかね

試して判断すればいいじゃん。差がわからないならどっちでもいいってことだし。
ちなみに俺の試した感じだと輪郭は高周波には属さない。
高周波はいわゆる細部とノイズだと思う。
フィルムグレインばりばりのソースを扱ったことはないけどあれもたぶん高周波。

高周波はエッジのシャープさだろ
丸くなってるか角になってるかで全然違ってくる

>>188
ダウト

falt使うと縮まないんだよなぁ
jvtは汚いって言うけどそんな気にならない感じ

NaruPのHighは膨らみまくるからちょっとご遠慮したい…

>>188
矩形波をサイン波の重ね合わせで表すとどうなる。
高周波まで伸びるだろうが、低周波の方がずっと多い。

>>191
そりゃそうだ
俺の言いたいのは輪郭を無視しちゃいけないってこと

だから、マトリクスで高周波を捨てて、AQで輪郭だけ拾いなおすんじゃないか？

だったらマトリックスを書き直せばいいだけだしなぁ

つまりdigaでエンコして抜けって事？

なるｐの昔のマトリクスが個人的ツボ。
本人がダメダメ言ってても感性は人それぞれだしね。
新しいやつは高周波の劣化が気になって仕方ない。

>>194
マトリックスは全体に掛けるしかないけど、AQで視覚的な物に基づいて拾うんじゃないの？

ttp://narup-.hp.infoseek.co.jp/2008_04.html#MinusVAQExp_03 (-VAQ&ﾏﾄﾘｯｸｽについて)
言いたい事書いてくれてた。
高周波を削らないワケにはいかない。削っても気にならないはず → いや、気になるんですけど → 気になる所だけ無理やり戻すぜ！　みたいな。
ってことで、圧縮原理に基づいてﾏﾄﾘｸｽで削って、その後、絵的に欲しいかいらないかを考慮して、調整するのがAQだと思う。

沢山突っ込んでくれ。

OreAQまんせー

情報が錯綜してるな・・・
各オプションの特性を細かく画像付き比較サンプルみたいなのが欲しいなあ
x264の場合、多種のバージョンが存在している上に発展途上なのでなかなか難しいのだろうけど
やはりwikiは必要だと思うよ

んで出来たらまた叩くと

>>197
視覚的な部分を狙っているのはpsyRDでAQはマトリックスを
大雑把にした簡易的な補助機能だと思っている。
8x8マトリックスほど繊細な周波数成分の分割や判定・量子化コントロールができない

>>198
俺は逆の考えで、AQで高周波成分を過剰に削られた部分を
マトリックスで補うやりかたが今のベターなかたち
つまりAQは万能じゃないから8x8マトリックスとの相乗効果で
最終的な狙う画に調整する感じかなぁ

PHLの中の人もいっているけど、ソースに合わせてマトリックスを組まないと
ビシッと狙った画にならないのが実状なんだよな・・・

最近 0.3fps ぐらいしか出ないんだが皆どのぐらい出る設定でエンコしてる？

>>202
x264のAQとマトリックスはまったく違うものだし、両者を同列には語れない。

マトリックスというのは周波数成分毎の量子化傾向を制御するもの。
AQをどんなに弄ったところで変化するのはQ値であり、それはマトリックスの各係数に一律作用するものなので、
周波数特性は変わらない。
極論をいえば、AQというのは1ピクチャに対して従来の--qpではなく--crfを使っていると考えればよい。

それから、量子化ツールなんて昔から何もかわっていない。
> PHLの中の人もいっているけど、ソースに合わせてマトリックスを組まないと
> ビシッと狙った画にならないのが実状なんだよな・・・
というのも仕組み上当然のことだし、そんなのは十数年前から一緒。
量子化ツールを扱う以上未来永劫一緒。嫌ならsnowでも使っていればいい。

PsyRDについてはもうなんとコメントしたものやら。モード判定用のコスト計算を弄っているだけなんだが、
視覚的な部分を狙っているとは？

シングルパス 品質基準VBR　って
crf数値によって大体ビトレどれくらいになるかっていう計算式とかないのかな
エンコする物によるから無理なのか

Pirates of the Caribbean - DEAD MAN'S CHEST
ttp://rokiss.net/up/src/rokiss0042.png
ttp://rokiss.net/up/src/rokiss0043.png
ttp://rokiss.net/up/src/rokiss0044.png
ttp://rokiss.net/up/src/rokiss0045.png

シーンごとにぜんぜん違う設定でエンコードしてる印象。まあPHLのインタビュー
でも言ってるしプロの仕事はやっぱ格が違うな。
絵の細かい部分はQP上げつつオブジェクトの境目とか紐みたいな細い部分は
下がってるんだよな。あとビットレート食いそうなシーンもあまりQPは変化してない
(大体20〜24)からマトリクスもシーンごとにかなり違いそうだな。
あとフレームタイプの構成だけどIDRフレームは1秒間隔で適応挿入、Bフレームも一応
適応挿入みたいだけどほとんどすべて IBBPBBP... だった。
まあx264のエンコ癖というかそういうのとはまったく違うみたいだからあまり参考には
ならなさそうだけど今までこういうのなかった気がするからとりあえず載せとこう。

マトリクスはフリーのツールでは調べようがないのかな。

>>204
表現に誤解を招く書き方をしたかもしれない

マトリックスとAQの違いはわかっているし、AQがq値しか
変化させられないのもわかっている
けど、量子化行列を書かなくても大雑把に高周波部のqを上げて
端折る作用は期待できるから、マトリックスを真面目に書かなくても
なんちゃってコントロールできるという意味ではAQの恩恵ってあると思う

psyRDはサイコビジュアルでしょ？
人の目が色や輝度等に対してもつ特性を考慮したモード判定をするのだろうから、
視覚的な作用を狙ったものだと思うのだけど

PSYRDOの0.5では0.12345を指定していたのだが
新しい0.6では指定方式変わっててどの強さを指定すれば良いか解らん…
誰かおしえてーーー！

--psy-rd 0.0:0.0

seraphy氏が、まんま「AQとマトリックスについて」ていうタイトルで書いてた。（なぜ前に貼らなかった
ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1505&type=1477&space=75&no=0

ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1493&type=1477&space=75&no=0 (ACエネルギーって何？

均一なマトリクスの裂け目の向こう側

ゴーストがそう囁くのよ云々

>>209
それRDO使ってなくね？

　　　　　 ○ ○　
　 (>=◎( ﾟ(ｪ)ﾟ )　
　 /_./ 〉⊂_ノ｀　　(´⌒(´≡　
　〈/ ）/__,ミ　≡≡≡(´⌒;;;≡≡
　（_/^´　　(´⌒(´⌒ キーキキキｨｨｨ―――

OreAQはJVTを使えとな？

seraphy氏のサイトが・・・

HTTP/1.1 404 Not found

よくあることですね

wikiと同じ運命か・・・

　　 _,,....,,_　 ＿人人人人人人人人人人人人人人人＿
-''":::::::::::::｀''＞　　　ご冥福をお祈りします！！！　　＜
ヽ:::::::::::::::::::::￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^￣
　|::::::;ノ´￣＼:::::::::::＼_,. -‐ｧ　　　　　＿_　　 _____　　 ＿_____
　|::::ﾉ　　　ヽ､ヽr-r'"´　　（.__　　　　,´　_,, '-´￣￣｀-ゝ 、_ イ、
_,.!イ_　　_,.ﾍｰｧ'二ﾊ二ヽ､へ,_7　　　'r ´　　　　　　　　　　ヽ、ﾝ、
::::::rｰ''7ｺ-‐'"´　 　 ;　 ',　｀ヽ/｀7　,'＝=─-　　　 　 -─=＝',　i
r-'ｧ'"´/　 /!　ﾊ 　ハ　 !　　iヾ_ﾉ　i　ｲ　iゝ、ｲ人レ／_ルヽｲ i　|
!イ´ ,' |　/__,.!/　V　､!__ﾊ　 ,'　,ゝ　ﾚﾘｲi ／・＼ 　／・＼.| .|、i .||
`! 　!/ﾚi'　／・＼ 　／・＼ ﾚ'i　ﾉ　　　!Y!￣￣　　 ￣￣　「 !ﾉ i　|
,'　 ﾉ 　 !　￣￣　　 ￣￣　i .ﾚ'　　　 L.',.　 （＿人＿）　　L」 ﾉ| .|
　（　　,ﾊ　　　（＿人＿）　人! 　　　　| ||ヽ、　　＼＿|　 ,ｲ| ||ｲ| /
,.ﾍ,）､　　）＞,､ _____,　,.イ　 ハ　　　　レ ル｀ ー--─ ´ルﾚ　ﾚ´

957

x264_progress.indication_r957.diff
http://forum.doom9.org/showthread.php?p=1178745#post1178745

掲示板でちょっと叩かれたくらいで消す奴って何なの？

989 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:05:44 ID:8v7RmilU
tobinakaってここで少々叩かれたぐらいでwiki閉じたやつだよな？
今度はseraphy氏に絡んでるようだが、メールに何書いたんだ？
最前線とかの単語がでるって、代わりにwiki作れとか言ってるんじゃないだろうな。
seraphy氏のレスから迷惑そうな空気を感じるんだが。

990 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:22:54 ID:TDP5cuby
なに、最前線君がどうした？

991 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 14:35:13 ID:aNa3nuYd
wiki作れはないだろｗ
Doom9のフォーラムに来てくれって事じゃないの？OreAQとかMixAQの説明してくれって感じで
んでseraphyさんはそんなに空き時間もないし細々とやっていくんで遠慮しておくって話なんじゃないかな

992 名前：名無しさん＠編集中[sage] 投稿日：2008/08/26(火) 15:10:08 ID:8v7RmilU
tobinakaってやつのブログ見てきた。
プログラム読めないからOreAQやMixAQの説明ができないと言ってるから、>>991が正解のようだ。
なんだこいつ。勝手に向こうで紹介しておいて、説明できないからって作者に説明しろ言ってるのか。

もう夏休み終わったはずだろ？

それがまだ続いてる連中もいるんだよ
むしろ夏休みが終わらないのもいるようだが

俺たちの夏休みはこれからだ！

またいつもの荒らしか

チラ裏
最近変なとこでブロックノイズでると思ったら--me-prepassのせいくさい、
ここのところこれ加えてエンコしてたorz 外したら酷いのは減った。
あと--psy-rd 使うなら --trellis 1 が以外と良さ気。--trellis 2より膨らむけど
見た目は良い感じ。

me-prepassは意味ないと思う、見比べてみても視覚的に悪くなる場合が多い。
最近SSIMやPSNRが役に立たないから、イチイチ見比べるようで面倒だ（それが本来かも）。

psy-rdが無効の状態で、trellis2使うと詳細が潰れるらしいな。
レート制限があるときはいいのかもしれないけど。

me-prepassが効果あったのはvaqやpsyrdが出る前までだったな
昔は効果あったけど今となっては時間コストの割にたいしたことなくなってしまった

>>231
2pass等できちっと指定したんだよね？

r957 OreAQ11
--crf 21〜22 --threads auto --bframes 3 --b-pyramid --qcomp 0.7 --qpmin 8 --qpmax 24 --qpstep 8 --keyint 240 --min-keyint 1 --cqm "flat"
--scenecut 70 --partitions p8x8,i4x4,b8x8,i8x8 --8x8dct --direct auto --me umh --merange 32 --subme 7 --b-rdo --trellis 1 --b-adapt 2
--deblock 0:0 --ref 3 --mixed-refs --weightb --bime --no-fast-pskip --no-dct-decimate --psy-rd 0:0 --aq-mode 2 --aq-strength 0.5:0.5
--aq-sensitivity 10 --aq-metric 0
上の情報を参考にこんなんでやってみてる。指摘があれば何でも

GOM Encorder
http://www.gomplayer.jp/encoder/

GOM PLAYERで再生できる動画を カンタンに高速でファイル変換できる
h.264への変換はx264を使ってるらしい

ゴムきたああああああああああああああ

法則発動ktkr
x264ｦﾜﾀ・・・

こうして変なMP4が量産されていくわけか・・・。

無料トライアルって有料の製品版を出すって事かよ。
x264のライセンスって商用利用不可じゃなかったっけ？

ニコ動の次はGOMかな？
また質問スレになったりしたらどうするかね

>>238
GPLだから商用利用は問題ないでしょ。
ただ、GPLの解釈によってはGOM本体のソースコード公開しなきゃならなくなったりするのかも?
って、GOMが「K国発で基本的に何でも再生できるプレーヤー」とだけしか知らないのだけど。

K国は潰れるから消えるんじゃね

バイナリとして分離されていればGPL汚染は防げるという解釈もあるらしいけど、
これといった明確な基準がないよね。

GPLハザード

バイナリ分離が許されるなら何でもDLLにしちゃえば公開せずに使い放題じゃねｗ

>>242
ねーよ、そんな解釈
何のためにLGPLを別に作ったと思ってるんだ

--b-adapt 2にした途端CPUが糞詰まりして100%きっちり使わなくなる
重すぎだろこれ

むしろ--b-adapt 1が何もしてなかったってこと

--b-adapt 2はマルチスレッド効率が悪いのでコア数が多いほど遅くなる。

>>233
--b-adapt 2 --bframes 6 の方がいいかな
--cqm "flat"はOreAQの作者によると--cqm "jvt"の方がおすすめらしい
その辺は暗部の多いシーンを実際に見てみて好きな方を選ぶといいよ
--deblockは数値が大きければ大きいほどぼける傾向にあるのでそれも見て調整した方がいい
ブロックが目立たない程度に-1:-1や-2:-2のようになるべく小さくすると全体的により鮮明になる

改善の余地はあんのかな？　なんでスレッド使い切れないんだろ

処理の中で並列化の難しいのがあるんじゃね

>249
>--cqm "flat"はOreAQの作者によると--cqm "jvt"の方がおすすめらしい
「理論的には」みたいなこと書いてなかったっけ？

>>252
これだね
ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1505&type=1477&space=75&no=0

AQを強めにかける人用だから、aq-strength を -1.0以下で使用している人のことでしょ。
OreAQのデフォは0.5だから、そのままでjvtだと高周波をちょっと捨てすぎな感じ。
DCを10、ACの右下を26ぐらいにするのがいい感じジャマイカ

「flat使ったら最悪」ていうのが理論上だったかｗ

>>254
OreAQってマイナス値はあまりよくないんじゃなかったっけ？

>>256
VAQのこと。つか、上のリンク先の話はVAQが主体。

>>255
VAQのマイナスでflatを使ったら最悪なのは、ノイズを強調するから。
VAQのプラスでjvtを使ったら最悪なのは、ノイズをぼかしすぎるから。

NRをゴリゴリかけてのっぺりさせたソースをエンコしている奴には関係のない話だし、
記事が書かれたのが一般にHDソースが手に入りにくく、SDアナログキャプしてる奴が主流だった頃。
誰でも気楽にHDソースが手に入る今、鵜呑みにするのはイクナイ。

OmankoAQ

>>257
「十分にノイズが減ったアニメを対象に」(2008/02/11)
これがアナログキャプのことなのか地デジなのかはわからん。
ただ、NRでのっぺりな人は関係ない　というのは違うと思う。 確かにflatを使う弊害はかなり減りますけど。

jvtに+VAQって非推奨なの？ jvtの補助の為のものじゃなかったのか。
ボケすぎるとしたら、マトリクスよりAQの設定が問題あるんじゃないかと思う。 本末転倒というか。

ま、とにかく他人の話を鵜呑みにするのはイクナイ。
作者のコメントだろうと、テストして納得できなければ反発してみればいい（ぇー
自分の発言に責任を感じているのであれば、なんでもガンガン言うのがみんなの為になると思います

958
Add sad_aligned for faster subme=1 mbcmp
Distinguish between unaligned and aligned uses of mbcmp
SAD_aligned, for MMX SADs, uses non-cacheline SADs.

959
Add merged SAD for i16x16 analysis
Roughly 30% faster i16x16 analysis under subme=1

960
Faster H asm intra prediction functions
Take advantage of the H prediction method invented for merged intra SAD and apply it to regular prediction, too.

961
Faster avg_weight assembly
Unrolling the loop a bit improves performance

962
CAVLC cleanup and optimizations
Also move some small functions in macroblock.c to a .h file so they can be inlined.

963
Faster NAL unit encoding and remove unused nal_decode
Small speedup at very high bitrates

964
Predict 4x4_DC asm
Also remove 5-year-old unnecessary #define that reduced speed unnecessarily under MSVC-compiled builds

はやくadapt2を最適化するんだ

マジでそう思う

>>259
その部分はOreAQにかかっている。OreAQはノイズで誤爆するよってことでしょ。
つーか、そこまで詳しく書いてあるのに、日本語が理解できない奴いるんだなｗ

要約すると、VAQのマイナスを強め（どのくらいかは知らんけど、デフォ値の1.0のマイナスが基準なんじゃ？）にしている
人はflat使ったらダメ。jvtのように高周波を落とすようにしなさい。
⇒マイナスVAQを強めに使う奴はjvtかそれ以上に高周波を落とせ。
⇒逆にマイナスVAQを弱めに使っている人はflatやそれに近いマトリックスでいいわけだし、ノイズがのっていないなら尚更。

OreAQはノイズで誤爆するからNRはちゃんとかけろよ。それでもjvtの方がいいがなー。
⇒といってもOreAQはデフォ値が弱めだし、変化するqpもVAQに比べて少ないから、flatに近いマトリックスでよい。

こういう考えで>>254を書いたわけだが。
> 自分の発言に責任を感じているのであれば、なんでもガンガン言うのがみんなの為になると思います
俺の発言って一貫しているはずだけど、他の奴と勘違いしてる？

flatマトリクスの良いところは高周波残してる割に容量少な目なところ

およ、最新版でブロックの乱れが出たので掲示板覗いたら不具合あるっぽい？

>265

うちもひどいことになった。

>>265
俺だけじゃなかったんか

> 自分の発言に責任を感じているのであれば、なんでもガンガン言うのがみんなの為になると思います
tobinaka臭がぷんぷんする

>>265-267
公式版の最新(965)の話？

>>268
端から見たらお前の執着っぷりの方がよほど気持ち悪いんだが

ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1505&type=1477&space=75&no=0
【追記(2008/09/06)】
この記事に結構リンクが張られているので、ちょっと現時点での報告でも。
上のマトリックス云々の話は、当時のエンコード事情を考慮しての記事ですから注意してくださいね。
私のところではエンコソースがSD→アナログHD(PV3)→TSと変わって、この辺の事情がだいぶ変わりました。
今トレンドなのは、こんな設定です。（OreAQ11です）
--aq-mode 2 --aq-strength 0.5 --aq-sensitivity 10 --aq-metric 0 --psy-rd 0.5:0 --deblock -2:-2 --cqm "flat"
SDサイズとHDサイズでは、16x16のMB内に現れる画素情報密度が違いすぎるんですよね。
ご参考までに。

>269

ついさっきまでの964の話。
最新版ではFixされた。

--aq-sensitivity 10

aq-sensitivityを下げると、保護する閾がより低周波よりに狭まるって事でおｋ？

--psy-rd 0.5:0

この設定は、MCにpsy-rdoを使いつつ、アニメに関係ない高周波ノイズを復活させるpsy-trellisを使用しないというという事？

>>273
お前、もう少し勉強し直してきた方が恥かかなくて済むよ。
つまりそういうことだ。

>>273
疑問に思ったときのAQ Debug
psy-rdは片方だけ切るのはよくないって話だけどな。

>>265-267
x264patch.964.release01は直ってないみたいなんだが

x264patch.965.release01でてたから少しエンコしてみたけど問題なさげ

>>276-277
r965
Revert part of r963
In some rare (but significant) cases, the optimized nal_encode algorithm gave incorrect results.

seraphy氏のHP落ちてる？

pingも帰って来ないな。
停電とかだったりして。

落ちてるな

猫がリセットボタン押したらしい

ぎりぎり965落とせたｗ

すぐ復旧したしマジで豪雨で停電だったんだろうか

x264patch.964.release01
地雷だった。。。。
x264patch.965.release01はいいみたい。

>>285
同じ話ループさせるな

最近バージョン進みすぎｗ

⊂⌒⊂(； _, ,_)⊃　ﾊｧﾊｧﾊｧ......

>>287
バージョンアップが早いのはいいことです
反面、悪いこともあります
逆よりはいいと思います


どうも今日はイライラしてるようで、落ち着かないと。

--progress --crf 2 --qpmin 1 --qpstep 16 --scenecut 54 --min-keyint 1
--keyint 300 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --bframes 8 --weightb
--direct "auto" --b-rdo --subme 7 --me "umh" --merange 64 --ref 5 --mixed-refs
--threads 4 --trellis 2 --deblock -2:-2 --cqm "flat" --no-dct-decimate
--b-adapt 2 --aq-sensitivity 10 --psy-rd 0.5:0.5


上記の設定でTSソースのアニメをエンコしてるとブロックノイズが目立つ…
jvtにすると目立たなくなるけどやたら膨らむんだよなぁ…
無駄な設定、もしくは足りない設定とかある？

--qpmax 3 を足してあげてください

速レスさんくす

って--qpmax 3じゃ糞なくらい膨らむじゃん
--qpmax はデフォの51でやっとります…

--qpmin 1 はなぜその値にしてるのでしょうか？

それと--crf 2もね

>>292
crf 2とかいってる奴がなにぬかしてんだよ、このすっとこどっこい

釣りと思われても仕方ない

--crf 2 --qpmin 1 --deblock -2:-2 --threads 4
--crf 21 --qpmin 10 --deblock 3:3 --threads 1

ごめん、--crf 21だった
コピペミスったorz

個人的には--crf 21でいくなら
--crf21 --qpmin 12〜18 --qpmax 24〜30 でいいかなと思うけどね
H.264のQPの変化の仕方をMPEGの変化に変換すれば12は1、18は2、24は4、30は8なので

>>298
--qpmax 21足してあげよう (上のやつでいうMPEGの3くらい)

>>299
ほんとにすまない
やっぱり-qpmin 1とかやり過ぎだったんだね
--qpmin 12　--qpmax 21あたりでやってみるよ

結果は6-7時間後ぐらいに…

--b-adapt 2はほんとに時間掛かる…
QuadコアだけどCPU使用率が30-40％くらいをうろちょろ…
もうちょっとがんばってくれれば…

>>300
--b-adapt 2の件なら上に書いてあるよ
--b-adapt 1で十分だろうけど、”個人的”には

--b-adapt 2なら--bframes 8もいらないし、2〜4で十分だろ。

Pen4-HTonだが、b-adapt2が頭にきて、--threads 8にしてやったらCPU使用率100％に張り付いたｗ
threads4まで下げても100%だったな。 3(auto?)では90％程度。(b-adapt1なら100%)
で、threads4の状態でbframesを3→16にしたら、70%まで落ちた。thread 8にしても更に僅かに落ちただけorz

何の意味も無いレポートだが、bframes3程度なら使いきれるんじゃないのか？ 解像度や他のオプションとどういう関係になるか判らんけど。

それは単に余計な仕事が増えただけじゃないのか

シングルプロセッサは基本的にthreads1にすべきだと思う
HTはシングルでやってるプロセスの空きを他のプロセスにあてがうものだから
エンコとかはかち合う事になる

--b-adapt 1と同じ感覚で--b-adapt 2の--bframesにでかい数字設定しちゃいかんよ
--b-adapt 1なんか頭すっからかんの馬鹿だから--bframes増やしても時間変わらないし結果も変わらない
--b-adapt 2は--bframes増やすと重くなるけどそれだけの結果を出す

--b-adapt 2 --bframes 3ぐらいで最初は様子見て許容できるところまで徐々に増やしていけばいい

>>304
--threads 3
x264 [info]: SSIM Mean Y:0.9936264
x264 [info]: PSNR Mean Y:49.708 U:51.280 V:51.698 Avg:50.207 Global:49.627 kb/s:2564.68
encoded 218 frames, 2.41 fps, 2565.68 kb/s

--threads 4
x264 [info]: SSIM Mean Y:0.9936632
x264 [info]: PSNR Mean Y:49.724 U:51.292 V:51.708 Avg:50.222 Global:49.646 kb/s:2596.40
encoded 218 frames, 2.53 fps, 2597.41 kb/s

約5%の速度向上。 CPU使用率の上昇と一致していると思います。
ｺｱ数=>ｽﾚｯﾄﾞ数は正しいとは限らない。 何故か、上手く使い切れない事が多い。
圧縮品質に僅かな悪影響があるそうなので、thread数は出来るだけ少ない方が良いのは間違いないのですけど。
autoに任せないで、自分の環境に合わせて設定するべきだと思います。 ﾌﾚｰﾑｻｰﾊﾞｰの動作とも合わせて考えなければなりませんがorz

>>307
http://www.marumo.ne.jp/db2007_7.htm#21
今のx264のマルチスレッドでは画質低下は起きない。

>>290
>ブロックノイズが目立つ
--deblockの数値を少しずつ増やしていけ
まずは極端に
--deblock -2:-2 と --deblock 3:3 を比較してみればいい

あと再生環境は完璧か？
二重伸張とかしてないよな？二重伸張してたらブロックノイズ目立ちまくるぞ

>>308
いつのまにか改善されてたんだ

じゃあスレッド増やしまくればいいのか？

フレーム内スライスをやめたのはかなり以前だったよな、たしか
PSP用の動画もエンコするから歓喜した記憶がある

実際は画質が全く低下しないのではなくて
気にならない程度まで改善されたって事だろうね

リードテック、東芝のメディアプロセッサ
「SpursEngine」搭載PCIe拡張カード
http://pc.watch.impress.co.jp/docs/2008/0910/leadtek.htm

画質は変わらなくても圧縮効率は悪くなるよ＜マルチスレッド
--mvrange-thread　512とかやればそれも無くなるはずだけど、ほぼシリアルになる

音声無しで映像だけのmp4コンテナだとFlashplayerで読みこみ開始と同時にストリーミング再生出来ないんだがなんでなん？
全部読みこみ終わらないと再生はじまらねえ

>>315 スレ違いにもほどがある

多分内部クラスの実装に問題があるんだろうが、スレ違いだしFlexのソースでも眺めて自分でパッチ当てたら？

>>315 は264関連のスレに爆撃マルチしてるアホ

最近の進捗状況表示の変更あってから
コマンドプロンプトが応答なしになったままx264は動いてる状況によく陥るんだけど
他にも同じような症状出てる人いない？
コマンドプロンプト閉じたらx264も終了するから困ってる

r953だが問題ない

PS3の「Cell」プロセッサを応用した高性能拡張カードが登場、ハイビジョン映像をガンガン楽しめるように
ttp://gigazine.net/index.php?/news/comments/20080910_winfast_pxvc1100/


こんなのきたけどどうせMainProfileだろうな

これってバンドルソフトじゃないと意味無いの？
これ対応版のx264とかでて1080P実時間でエンコとかできたら神だが。

>>321
>>313

デジタルソースをトランスコードするだけならアナログ時代のようにやれ画質の癖がどうだ、
フィルタかけられないじゃ意味無いって事もないからイイ製品に思えるなあ
汎用エンコードもアクセラレートしてくれるようアプリからも対応してくれればいいんだが

アクセラレートしたいとか考えてるんならXvidでも使っときなよ
画質なんてどうでもいいって思ってんでしょ？十分。

画質より高速化優先してるx264スレでそれはないだろ

画質ヲタはJMでもコンパイルしてろ

すみません質問です
FPS動画にてカスタムマトリクスを使用して動画を作成したいのですが、
この手のゲームのお勧めマトリクスみたいな物はあるのでしょうか(ソースによって
違うとは思いますが、ビットレート1000付近、2000付近双方で何かお勧めがあればと。)
また、カスタムマトリクスの作成を一からやる場合参考になるページなどは
あるのでしょうか。

ソースを見ないと何も言えない
特にビットレートが指定されていては

>>327
カスタムマトリクスを使う意味すら分かってない奴にお勧めできるようなページなんか
あるわけないだろ

>>326
どこをどう読んだら高速化優先になるのか
コードの最適化もやってるが、基本的にx264は常に重くなり続けてきた

つーかJMが画質良いとか相当アホだろ

>>328
あ、すみませんビットレートは指定ってよりLow/Hiビットレートどっち用の
なのよ？と聞かれた時の事考えて、この付近でのNpassエンコを考えて
書きました。
ソースは3Dゲーム対人、人数結構ごちゃごちゃ多い代物です。
>>329
flat/jvt両方試したんですがビットレートが足りてなくてlowビットレート用
の物を探すか作りたい具合です。

>>331
ビットレート最適なんを決めるの難しいからcrfで良いと思うよ
うちはゲーム動画(FPS含めて)でも何でもそうしてる

>>331
Low？Hi？
何の話だ？　プロファイルのことか？
ニコニコアップ用か？
どちらにせよスレ違いだし、お前さんのやりたいことは
マトリクス調整じゃなくてQ値変更で十分だろ。

>>331
おすすめのマトリクスなどない。
まずは他のオプションを考えろ。

>>331
おっしゃる通りcrfも考えてみます。
>>332
Lowビットレートって書き方で間違っているのでしょうか・・・？
ニコニコ用とかではなく自分での保存＆公開用です。
動画の平均QPを上昇させたいので色々試す→次に弄るのはマトリクスかな
と思ってカスタムマトリクス作成を勉強しているのですが、他にその話題
扱えるスレあるんでしょうか？

>>335
とりあえずなるP氏のサイト見て数字の意味を理解した後は
試行錯誤しか無いと思うが。少しずつ数値を変えてみて確認して、好みの画質になるまで煮詰める

ただし、君が思うような結果にはならんと思うがね。ビットレート足りないのは何をやっても足りないから
つまりあんまり大きくは変わらんという事。諦めてビットレート増やすほうが速いかも知れん

>>335
Q値上昇？　画質悪くしてサイズ抑えたいってことか？
たぶんQ値小さくして画質良くしつつサイズ抑えたいってことで話すすめるが
マトリクス弄ってQ値小さいままサイズ抑えても画質は悪くなる一方だぞ？
まずマトリクスが何なのかを調べた方がいいんじゃないのか？

で、サイズ小さくしたいなら--crf 35でjvtとか使っとけ。

>>334
過去スレから遡って見ていて結局ソース次第だとは思っているのですが、
自作するには無知識だと左上と右下以外数値何を入れていけば良いのか
さっぱりだったので聞いた次第です。
>>336
了解です。
マトリクスを作り変える事でビットがあまる状況を作り出せる→ブロックノイズが
減少するのかな？と浅く考えておりました。
自分で色々手動で数値入れていってみます。

>>337
あがががががQ値減少のミスです。
確かにマトリクスの部分勉強不足ですので、勉強しなおしてきます。
(その為のサイトに悩んでおりました。)

>>all
拙い質問に返信有難うございます。

>>338
参考になると思う
ttp://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-03E

>>240
有難うございます。
少しずつ自作していってみますー。

なぁ、x264のインターレースって何かおかしくない？
CoreAVCでも、ffdshowでも、PS3でも解除できないんだけど。
フィールド融合してるのか？と思ってAviUtlで60fps読み込みしたら
ちゃんとインタレになってるし。
誰かアドバイスプリーズ。

>>342
CoreAVCはバージョンによってインタレ解除に不具合がある

　┌───┐
　｜　.967　 |
　└─┬─┘
　　 (；ﾟ∀ﾟ )　ﾆｺｯ!!
　　 し　　 J


Fix crash when using b-adapt at resolutions 32x32 or below.
Original patch by BugMaster, but was mostly rewritten in order to make b-adapt actually *work* at such resolutions, not merely stop crashing.

Add title-bar progress indicator under WIN32
Also add bitrate-so-far output when piping data to x264 (total frames not known)
Patch mostly by recover from Doom9.

あんたこっちにも来たのか。

てかat resolutions 32x32 or belowってｗ

こっちでもやんのかよｗ

こっちではageるのなｗ

.CA_ってのは初見だ

もうこれでいいよｗ

>>348
むかしな、圧縮すると拡張子の最後をアンダースコアにリネームするソフトがあってだな。
win95のセットアップCDもこの形式で圧縮されていたのだよ。

expand x264.967.release01.CA_ x264.967.release01.CAB
開けたｗ

expand /r %1

よっしゃ解凍できた

やっと解凍できたよｗ

>>344って有名な人なの？
ただの基地外にしか見えないけど

Media Player Classicスレの更新チェッカです。

x264_vaqmod.02.r965.diff
http://stashbox.org/browse.php?q=x264&x=12&y=13

さっそく一人つられてたｗ

>>342
x264はBFFしか作れないんじゃなかった？

俺もいつもインタレエンコがうまく再生できなくて困ってたよ。

>359
BFFだったとしてもデコーダが自動判定してくれないんだろうか。

ffdshowは論外としてもKOREAvcとか使ってるデコーダが糞なのか、エンコ時のオプションがオカシイかどっちか。
トップフィールドファーストでちゃんと再生出来るし、何も問題は無い。PS3はシラネ。

>>361
そりゃ韓国製じゃ良くないだろう

Core製じゃないとな。

h.264も韓国起源なんですねわかります

>361

オプションって--interlacedを指定するだけじゃないの？

VLCは0.8.6d以降x264のインタレがBobでうまく解除出来ない。
0.8.6cまでは出来てた。

KOREAvcはﾜﾛﾀ

もう許してやれよ

ttp://6.dtiblog.com/n/nukisen/file/juno_37.jpg

qpmaxの値を小さくすると2pass curve failed to convergeと出てしまうのですが
これはやはり元動画のソースにノイズが乗りすぎておりqpの値を小さくすることが
出来ないのでしょうか。
ソースはアマレココというキャプチャーソフト(YUY2高圧縮)を使って撮影したゲーム動画なのですがエンコードの際に参考しているSSIMの値が0.8すら越えなくて。
x264のオプションはこんな感じです。
--pass 3 --aq-mode 0 --bitrate 1300 --progress --ref 4 --deblock 0:0 --me "umh" --subme 6 --mixed-ref 1 --merange 16 --trellis 0 --8x8dct --cmq jvt
--chroma-qp-offset 1 --threads 0 --nr 0 --no-dct-decimate --bframes 16 --b-bias 0 --direct auto --bime 1 --weightb --keyint 300 --min-keyint 30
--pre-scenecut 74 --ratetol 1.0 --qcomp 0.60 --qpmin 5 --qpmax 35 --qpstep 8 --cplxblur 20.0 -- qblur 0.5 --ipratio 1.40 --pbratio 1.30 --aq 0
--deadzone-inter 21 --deadzone-intra 11

何か指摘等あればよろしくお願いします。

ビットレートが足りないならビットレートを上げるしかない
上げられないなら画質を我慢するしかない

一緒に推奨ビットレートが表示されてるのでそれ以上に変更

>>370
アマレコってあたりFEZやMOE辺りをzoome用にと推測するけど、パラメータ色々
変すぎじゃない？言ってる事も変だけど。
どっかのバッチでも引っ張ってきたのか分からんが最小構成か簡単設定出来る物の
方が良いと思う

>>370
お前の指定したqpmaxじゃどうやっても指定したビットレートは守れん　と怒ってるんだよ

MPEG1/2/4やH.263とかの感覚のままでMPEG4-AVC(x264)を扱うからこうなる

今更溜まりに溜まったアニメをエンコしてるんだが電脳コイルが全然縮まらん
常に画面がざらついてる演出がビットレート食ってると思って良いのかね、これは

素直に外付けHDD買え

お年玉3年分でぐっと縮むよ！

電脳コイルはDivXとかビットレート低めに設定すると
フィルムエフェクト（？）がさっぱり消えちゃって大変だよね

でも正直あんなエフェクト要らなかったよね。
常時だし。

字幕みたいにスーパーインポーズでグレイン切り替えられりゃよかったんだよ。

DivXはレート上げてもフィルムグレインが消えやすいから、
一応デコーダにフィルムグレインを付加する機能が付いてるよｗ
のっぺりさせて圧縮して、再生時に付加してくださいって話
正直役に立たないけどｗ

guiスレ落ちた？

落ちたらたてればいいだろ

>>383
x264 VFW GUI専用スレ Part4
http://pc11.2ch.net/test/read.cgi/avi/1221328142/

バージョンアップの度にパラメーター調整を繰り返すのも柄じゃないから
ベストじゃなくてそれなりに見られるオプションで妥協しようと思うんだけど
これどうかな。つっこむデータは1280x720の30fps。

x264 --keyint 300 --min-keyint 1 --bframes 5 --weightb --b-pyramid --ref 5 --crf 20 --qcomp 0.8 --partitions all --8x8dct
--me "umh" --merange 32 --subme 7 --trellis 2 --threads auto --thread-input --progress

--partitions all は　p4x4を含むからやばいんじゃなかったっけ？昔のことだが

--partitions "p8x8,b8x8,i8x8,i4x4" 自分はこう

--mixed-refs　は無いとマズイんじゃ･･･。 速度が気になるならrefを落としてでも入れるべき。
--no-dct-decimate　も入れるべき。--bime も良い。
他に--b-rbo、--direct auto、--no-fast-pskip　を入れれば画質が上がる。
これは公式ではないが、--b-adapt 2 をなぜ抜いたし。
あとqpstepは4でいいの？scenecutも40。(psy-rdもデフォルトだと1.0:1.0)

こんな感じでオプション全部入れて、費用対効果の良さげな重さにしてみたら、俺的基礎部分はこんな感じ。 いや、結局最重量級なんだがorz
(--level ***) --crf ** --keyint *** --min-keyint 1 --scenecut ** --qpstep * --qcomp 0.7 --b-adapt 2 --bframes 3
--b-pyramid --weightb --bime --partitions p8x8,b8x8,i8x8,i4x4 --8x8dct --ref 3 --mixed-refs --me umh --merange 16
--subme 7 --b-rdo --trellis 2 --direct auto --no-fast-pskip --no-dct-decimate --progress

あとはrefやmerange増やしたり、tesa使ったり(莫迦
とりあえず、この辺りは自分設定決めておけばver変わってもそんなに弄る必要ないと思う。

そこまで圧縮効率良くして再生機器で不具合出ても知らんぞＷ

いろいろ悶えた結果、最近はこんな感じ。
ソースはDVDからのアニメオンリー704x(396+4)。見るのはPC上のみ。エンコーダはOreAQ.953.r3

--crf 18 --keyint 240 --min-keyint 1 --scenecut 75 --ipratio 1.2 --pbratio 1.2 --8x8dct
--bframes 3 --b-pyramid --b-rdo --b-adapt 2 --weightb --direct auto --ref 3 --mixed-refs --subme 6 --me umh --merange 32
--no-fast-pskip --no-dct-decimate --threads auto --thread-input --progress --cqmfile narup-MiddleQuality-rev030R.cfg --transfer smpte240m

多少太ってもいいから、きれいだといいなーの方向で。
オプションいじっても差がわからんことがほとんどだけどorz

>>390
重要なオプションを省き過ぎ
--aq-strength 0.5〜1.0
--aq-sensitivity 10 (SDの場合は11〜15ぐらい)
--psy-rd 0:0
--aq-metric 0
--deblock -2:-2〜0:0
--partitions p8x8,b8x8,i8x8,i4x4

省いたってデフォルトになるだけだ

つか多少太ってもってOreAQなら勝手に
--trellis 1 --psy-rd 1:1
になってる（だよね？）から太ってるだけじゃないの？
満足してるならどうでも良いんだけど…

Move adaptive quantization to before ratecontrol, eliminate qcomp bias
This change improves VBV accuracy and improves bit distribution in CRF and 2pass.
Instead of being applied after ratecontrol, AQ becomes part of the complexity measure that ratecontrol uses.
This allows for modularity for changes to AQ; a new AQ algorithm can be introduced simply by introducing a new aq_mode and a corresponding if in adaptive_quant_frame.
This also allows quantizer field smoothing, since quantizers are calculated beofrehand rather during encoding.
Since there is no more reason for it, aq_mode 1 is removed. The new mode 1 is in a sense a merger of the old modes 1 and 2.
WARNING: This change redefines CRF when using AQ, so output bitrate for a given CRF may be significantly different from before this change!

>>391-393
ありがとう。
正直AQ周りはググりきれてないのとスレ追い切れてないのでデフォで流してた。
教えてくれた分を突っ込んで試してみる

ただ、--partitions はデフォルトで p8x8,b8x8,i8x8,i4x4 のハズだからはしょってます。

x264エンコードオプション関連のサイトが大抵ニコ厨で萎える

国内のサイトで探しても、ニコとアニメエンコの情報しか出てこないよな。

ニコ厨の存在はいろんな意味で影響でまくりだな

逆にニコニコ普及する前は詳しいサイトなんてほとんどなかったから自分で試行錯誤したり
Doom9がんばって読んだりしたぞ。
ニコ厨のサイトなんて参考にしたくねーとか思ってるなら自分で努力しろよ。
俺もニコニコでいけ好かない奴は多いとは思ってるが参考になるサイトがあるのは
それはそれでありがたい。

まるっきり嘘書いてる訳じゃないだろ。叩いてる自分カッコイイってやつ？

嘘じゃないんだがあれはニコニコの仕様にあわせた解説になってるのは事実

別にニコニコに限らないが、ソースや解像度に合わせて適切に設定することが必要。

seraphy氏引っ越すらしいぞ。いつになるか知らんが今の内に落としとけ。

.CAってのは何なの？

>>404
Cabin Attendant

c:\windows\system32\expand.exe hoge.ca_ hoge.cab

詳しいサイトあるだろ。　ageha was here とか、まるも氏2007年6月〜とか。
パッチに関してはDoom9スレ読むのが一番。　というか、読まないって、readmeを読んでないようなもの。　作者が質疑応答してくれてるし。

wiki誰も作らないから作ってみたんだけど、今のところゴミ。
まだ使い方すらわからんｗ　一日で面倒になって放り投げました＼(＾o＾)／
骨組みすら作らないうちに丸投げはアレなんで、もう少し弄ったら晒そうと思います。
MPlayer and MEncoder on MacOSX　のコピー+αにしかなりそうにありませんけど。

捕捉出来るのか気になって「x264 frontpage」でググってみたら、凄いものを掘り起こしてしまったｗ
火種まいておいてアレだが、もう叩きは止めような？

同じpukiwikiなようなので、私のは放棄することにします。

！！

tobinaka

彼どうしても目立ちたいみたいね

なんでみんなで編集するwikiに個人名入れちゃうかなぁ
なーんかずれてるよね

基本自己主張したがるニコ厨だからしょうがない


>>408
まだ見てたらそれ公開してくんないかね？そっちなら編集するが

ヤバイね。敬体と常体が混在しているあたりが
特にヤバさを強調しているね。

なんだおまいら分かっててスルーしてたのかと思った出来たの大分前だぜ

あると便利なのは確かだから
生暖かく見守ろうぜ。

ニコ厨嫌悪を主張しまくる奴も十分うざいがな

意見は何でも言ってくれって本人言ってるのに外野で騒いでもみっともないだけだろ。
あのwikiは中身だけはニコニコ一切関係ないのにどこが問題なんだ？

x264 frontpageで検索した
ものすごい悪寒がはしったぜ

また粘着荒らしかよ
こいつID変えての自演を混ぜつつ定期的に来るのなｗ

おもちゃ見つけて歓喜って感じだな

バンディング解消されました？

>>408
今までの経緯を考えると、正直tobinakaのはいつ消えるかもわからん
お前もWiki晒すのがいいと思う

OreAQのrev.967使っているんだが、
PSPでrev.964みたいにブロックが乱れるのは自分だけか？

>>423
b-pyramid使うと映像乱れるよ

それって赤にでているとエスパーしてみる

うちはOreAQ967でb-pyramid使ってるけど全く乱れてないよ
PSP用ではないけどPSPで再生したら乱れるのかな？
423はPCでは問題ないけどPSPで再生したら乱れるって意味？

PSPで再生できないってことはビットレート上げすぎじゃないの？

pukiwikiです。 frontpageやmenuの作り方すらわからずかなりゴミ。中身もまだ書いていないので本気で意味無い。
ttp://www.wikihouse.com/x264/index.php
tobinaka氏のwikiは優れているし十分だと思うのですが、二つあっても良いというのであれば。

PAFF対応ﾏﾀﾞｰ

>>428
お前馬鹿だろ

また例の馬鹿がwikiどうのこうので騒いでるのか？

wiki嫌いの頭おかしい奴はなんなの？
他人が楽して情報を得ることがそんなに許せないの？

アフィ(笑)が許せないらしい

スレで初心者をばかにする機会が減ってしまうんはいやどす

「MPlayer and MEncoder on MacOSX」-x264encoptsを更新して欲しかったかな。
ただ、元々が、Mac用MEncoderの解説用途だから、最近のx264に追従してくことが
しづらいかもしれないけど。

初心者は良くできているMeGUIのプロファイルを参考に設定したら良い。

PSPが補完しないだけ

wikiたたいてるやつって
「俺様が苦労して得た情報を初心者が簡単に得られるのが気にくわない」
ってこと？なんて寂寥な・・・。

例え不具合があってもたたき台を作っただけでも価値があるし、直しゃいーだろ。
気に入らなきゃみなきゃいいし。

違うだろ
tobinakaはうざいから叩かれてる
>>428は設置しただけの馬鹿だから叩かれてる

>438
寂寥->狭量

>>439
おまえも煽るだけの馬鹿だな

設置なんぞ誰でもできんだよ

ちょうど叩きやすそうなのがあったから叩いてるだけの愉快犯でしょ。

復活したのかー。
また突然消えたりしませんように。

俺はtobinakaのWikiについては、ドメインやサイト名からtobinakaっていう個人名外せば他は問題無いと思う
他人に書いてもらうべきサイトに自分の名前を付けるのは、他人の成果を自分の物にしているように見えてしまうからな。
そういうつもりが無いのなら個人名は外した方が良いよ
実際俺が知る限り、ソフトウェア関連のまとめWikiに個人名が入ってる所なんて無い
叩き煽りだとかそういうの抜きで

また粘着荒らしか

スレチくさいしそろそろこの話題終わろうぜ

b-pyramid無くしたらちゃんとなった〜
>>424サンクス

>>426
PCでは問題なかったんだゼ

まあ、wikiっぽいのがあると助かるわ
アフィだろうが何だろうがこっちが金払うわけでもないからどうでもいい
今度は続けて欲しい

てか本人に金入るの？

wiki少し編集してみた。
オプション説明に関しては、こんな感じで作っていこうと思う。（左側と右側にメニュー作ると便利かな）
訂正やアドバイスがあればガンガン言って欲しいので、よろしくお願いします。

>>450
本人ってどこまでが本人なのか難しい所だが
アフィを張った本人にはいくばくかの金が入るかもしれない

難しいことをそうでない様に解説したら金を貰ってもそれはそれで問題ないとおもうがな
俺が出来ないのに小銭稼ぎやがって浦山氏というレベルで怒ってる奴はしらん

>>439
だったらてめえが設置しろハゲ
誰でも設置できるから叩くってお前は何様のつもりだ？

wikihouseは2chでは広く使われてるしアフィとか騒ぐ奴は頭沸いてるのか？

>>453
アフィで以前もめたのにまたアフィ付きの所でたてたから馬鹿だつってんだよ

--b-adapt 2 の正式採用きたな

r969
　　Add optional more optimal B-frame decision method
　　This method (--b-adapt 2) uses a Viterbi algorithm somewhat similar to that used in trellis quantization.
　　Note that it is not fully optimized and is very slow with large --bframes values.
　　It also takes into account weightb, which should improve fade detection.
　　Additionally, changes were made to cache lowres intra results for each frame to avoid recalculating them.
　　This should improve performance in both B-frame decision methods.
　　This can also be done for motion vectors, which will dramatically improve b-adapt 2 performance when it is complete.
　　This patch also reads b_adapt and scenecut settings from the first pass so that the x264 header information in the output file will have correct information
　　(since frametype decision is only done on the first pass).

--bframes 2か3で使うのなら、--b-adapt 2も十分実用的だ。

http://www.wikihouse.com/pukiwiki/index.php?%CD%F8%CD%D1%B5%AC%CC%F3#w6d09cdf
>禁止事項
>下記内容を含む Wiki の利用は禁止とする。下記内容が掲載された場合、メンバーは速やかにこれを削除しなければならない。
>
>広告を表示すること

アフィとか言ってるやつは日本語読めないの？そんなんでエンコなんかできんの？

まったりいこうぜえ

>>457
wikihouseの奴がたてた可能性は否定できないだろ

アフィは張ってませんよ
pukiwikiに不満があるって、AviSynthWikiすら気に入らないんでしょうか。

流れていってしまう議論の結果を残していける、また見つけた情報をメモってもらえるようなwikiになったらいいなと思ってます。

と思ったら、アレには広告ありませんね。

WikiHouseが勝手に広告入れてるのか。　アホな書き込みすみませんでしたorz

wikiを提供するならアフィなしでできる人がすればいい
それ以外は荒れるだけ

>>463
確かにそうですね。
このスレの人に利用はしてもらいたいけど、管理は独自に行っていくことにします。
とりあえずページの作成は続けますが別に管理をしたい訳ではないので、どなたか建てる方がいればデータを譲って畳もうと思います。

またこの流れかよ
いい加減あきらめろよ

tobinaka氏のと統合できるといいかなと個人的には思う。

forumも作ってあって上で話題になった--b-pyramidについても
詳しく書いてある。

うざい人と思われてるのかもしれないけど、１人でここまで作ってるのは
正直すごいと思う。

wikiについての話し合いならwikiに掲示板機能つけてそこでやれば？

ウザイ独り言をこれ以上続けられても迷惑だ
wiki作る奴はどいつも場を読めない独りよがりのクズだってことは理解できたよ

>>468
作りたい人が作っただけなのに
なぜそれで468が迷惑を被るのか？

>>469
じゃあこのスレにだらだらとつまらない日記を書き込んでもＯＫってことだね

フォーラムあるんだからそっちでやれ

>>468
おめーも同じだ

>>471
おめーも同じだ

>>472
おめーも同じだ

>>468
場を読めてないのはおまえだハゲ

NG登録推奨　wiki

>>474
場を読めてないのはおまえだハゲ

なんだなんだどうした

足の引っ張り合いだお

>477

え？え？
「神 ID:」
ってなに？

例によって足を引っ張る事しか出来ない人格障害が
手を動かしてる人に粘着して嫌がらせしてるだけ

アフィうぜぇ

急に単発IDだらけになったねｗ

荒れると判っててネタフリする釣り師がいるからこんなことになる。

ちなみに人格障害を患ってるのは>>481だから

>>483
回線を切ってIPを変える度に病状がどんどん悪化するｗ

wikiは荒れる

なんか揉めてるうちに公式凄いことになってるなｗ
--b-adapt 2に続いて--psy-rdが正式採用。

r970
Psychovisually optimized rate-distortion optimization and trellis
The latter, psy-trellis, is disabled by default and is reserved as experimental; your mileage may vary.
Default subme is raised to 6 so that psy RD is on by default.

r971
hadamard_ac for psy-rd
c version is 1.7x faster than satd+sa8d+sad
ssse3 version is 2.3x faster than satd+sa8d+sad

tobinakaが事の発端であることにはかわりはない

もう、なんでtobinakaのwiki気にするのかな？そんなもん勝手にやらせときゃいいじゃん。

wikiなんか気にしないでもっとこのスレを中身のある話題しよーよー。

>>489
いやあいつから、っていうかお前から絡んでくるからだろ
ばれてないと思ってるのか？

頼むからこれ以上やりたきゃヲチ板にでも行ってくれないか

＞490
ばれてないとか、俺演じたりしてねーんすけど…

wikiなんかよかこっちの板に俺は期待してるから純粋な気持ちを言っただけなんだけどね。

>>492
そのむかつく口調やめろ死ね
2度と書き込むな

wikiに対する感想、私見、私怨はチラシの裏にでも書いてろよ
嫌なら見なければいいだけの話だろ
叩いてるカスは消えろ　ID:lWEkafOc=ID:/2WOr/lrとあともう一人
スレの内容や最新だけを常に追ってる奴ばかりじゃないんだよ
中にはx264を使いたいけどオプションが難しいと思っている新参だって大勢いるだろう
より判りやすい情報の共有が自分の利益になることが何故理解できないのか

新参の人の為に「x264 初心者質問スレ」を立てれば良いじゃない

>>493
ちょっと病院行ってこい・・・やばいぞお前

490 名前：名無しさん＠編集中[sage] 投稿日：2008/09/15(月) 23:18:22 ID:7SbDlRUG
>>489
いやあいつから、っていうかお前から絡んでくるからだろ
ばれてないと思ってるのか？

思い込み激しすぎ

実写の設定で、（mixAQ)
--crf 21 --level 4 --keyint 300 --min-keyint 1 --scenecut 45 --bframes 3 --bime --b-rdo --weightb
--direct auto --analyse p8x8,b8x8,i4x4 --8x8dct --trellis 1 --cqm "jvt" --aq-mode 2 --aq-metric 0
--aq-strength 0.5 --aq-sensitivity 10 --aq2-strength 0.3 --aq2-sensitivity 15 --qcomp 0.7 --psy-rd 0
--merange 32 --qpmin 14 --qpmax 32 --qpstep 8 --ref 3 --mixed-refs --ipratio 1.6 --pbratio 1.5
--subme 6 --deblock 2:2 --no-fast-pskip --threads auto --thread-input --progress --sar 1:1
--no-dct-decimate --no-psnr --no-ssim
こんな感じでやってんだが、jvtでおｋかな？あと「この設定はないだろ」って部分があれば言ってくれないか。

なんでi8x8切ってんだ？
理由ないなら--analyseは要らんと思うが

俺も切ってる理由は互換性確保だろ

wikiとかいらねーんだよボケ

--------------------
書込み中・・・
--------------------
ＥＲＲＯＲ！
ＥＲＲＯＲ：新このホストでは、しばらくスレッドが立てられません。
またの機会にどうぞ。。。

x264 初心者質問スレ part1

こちらはニコニコ動画でx264を使い始めた 等の初心者のためのスレです。
wikiを作成中。。。作成中のwikiの話題もこちらでどうぞ。

[本家]
http://www.videolan.org/x264.html
http://trac.videolan.org/x264/browser/trunk (ソース)

[バイナリ]
http://x264.nl/
http://forum.doom9.org/showthread.php?s=&threadid=89979
http://celticdruid.no-ip.com/xvid/
http://uk.geocities.com/h264x264/
http://oss.netfarm.it/mplayer-win32.php (mencoder)
http://forum.doom9.org/showthread.php?s=&threadid=87567 (MeGUI:mencoderのGUI)
http://tirnanog.fate.jp/mirror/gpac/dev/　(mp4box)
http://yamb.unite-video.com/　(YAMB)

[本スレ]
x264 rev16
http://pc11.2ch.net/test/read.cgi/avi/1219480206/

[前スレ]
なし

誰か代わりに頼む

ほい

x264 初心者質問スレ part1
http://pc11.2ch.net/test/read.cgi/avi/1221494912/

質問スレって質問者に突っ込んだり、叩いたりするスレだよね？
たまーに奇特な人が教えてあげる事もあるようだが・・

初心者隔離スレです

今じゃWiki作っても誰も編集しないし
そもそも他人まかせでWiki作ろうとするのが間違い
俺のWikiなんか俺しか編集しないし

>>506
wiki隔離スレだろ
>>507は>>504行ってこい

そんなにWIKI作りたければローカルでシコシコやってればいいのに

ひとり用wikiソフト
http://pc11.2ch.net/test/read.cgi/software/1144955224/

久々にスレ見てみたら…なんだコレ。
つーかtobinaka書き込みすぎだろ。
名前入りで擁護してる466とか確定だろ。

971落としてみたけどAQ以外はパッチ版そのままって感じですね

61から64ってワープ進化しすぎだろ

だれか まとめ たのむ

公式最強すぎﾜﾛﾀｗｗ
r973
This vastly speeds up b-adapt 2, especially at large bframes values.
This changes output because now MV prediction in lookahead only uses L0/L1 MVs, not bidir. This isn't a problem, since the bidir prediction wasn't really correct to begin with, so the change in output is neither positive nor negative.
This also allowed the removal of some unnecessary memsets, which should also give a small speed boost.
Finally, this allows the use of the lowres motion vectors for predictors in some future patch.

な、なんだってー

>>514
英語が分からない上に翻訳サイトが役に立たないので誰か要約お願い orz

T
T
w
T
F

>>516
要約

英語も読めない馬鹿はエンコなんかしなくてもいいよ

nl版落としてやってみた。　ソースはOPのタイトル部分337フレーム(かなりエフェクトあり)　もうちょっと動かないの探せばよかったorz
1
x264 [info]: slice P:186 Avg QP:20.08 size: 9779
x264 [info]: slice B:142 Avg QP:22.18 size: 2607
x264 [info]: consecutive B-frames: 13.4% 86.6%
x264 [info]: SSIM Mean Y:0.9924095
x264 [info]: PSNR Mean Y:48.433 U:50.650 V:49.432 Avg:48.852 Global:48.142 kb/s:1335.54
encoded 337 frames, 4.24 fps, 1335.98 kb/s
3
x264 [info]: slice P:141 Avg QP:20.61 size: 10850
x264 [info]: slice B:187 Avg QP:22.01 size: 2507
x264 [info]: consecutive B-frames: 9.5% 30.5% 39.3% 20.7%
x264 [info]: SSIM Mean Y:0.9923547
x264 [info]: PSNR Mean Y:48.191 U:50.423 V:49.115 Avg:48.599 Global:47.981 kb/s:1226.47
encoded 337 frames, 4.03 fps, 1226.91 kb/s
6
x264 [info]: slice P:135 Avg QP:20.68 size: 11084
x264 [info]: slice B:193 Avg QP:22.09 size: 2472
x264 [info]: consecutive B-frames: 9.1% 31.7% 31.1% 11.0% 7.6% 7.3% 2.1%
x264 [info]: SSIM Mean Y:0.9923446
x264 [info]: PSNR Mean Y:48.149 U:50.385 V:49.046 Avg:48.553 Global:47.949 kb/s:1212.15
encoded 337 frames, 3.29 fps, 1212.59 kb/s
12
x264 [info]: slice P:135 Avg QP:20.68 size: 11087
x264 [info]: slice B:193 Avg QP:22.09 size: 2475
x264 [info]: consecutive B-frames: 9.1% 31.7% 30.2% 13.4% 6.1% 7.3% 2.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9923417
x264 [info]: PSNR Mean Y:48.149 U:50.392 V:49.045 Avg:48.553 Global:47.949 kb/s:1212.64
encoded 337 frames, 2.08 fps, 1213.08 kb/s
16
encoded 337 frames, 1.57 fps, 1213.08 kb/s

>>519
3〜6の間のbframe数に対してのfpsの変化がしりたいな
6〜12だとほとんど変化ないから、3〜6の間でどう変化してるかが肝だとおもふ

>>518
他の人の迷惑だから いちいち自己紹介はしなくていいよｗ

いや迷惑ってことはないんだが。ちょい上のくだらない論争より遥かに有意義。

要は地球に優しくしようって事かな

奇怪翻訳してきた

r973
b-adapt 2 がかなり高速化。特に bframes が大きい場合に有効。

動きベクトルの予測に双方向ではなくL0/L1の動きベクトル予測のみを
使用することに変更。
双方向予測はそもそも完全に正しいわけではなかったので、
この変更は進歩でも退化でもない。
この変更で不要なメモリ消費を減らし、やや高速化したはず。

動き予測にlow-res動きベクトルを利用

3の結果が変わっちゃったｗ（ぇー
3
x264 [info]: slice P:141 Avg QP:20.61 size: 10852
x264 [info]: slice B:187 Avg QP:22.01 size: 2502
x264 [info]: consecutive B-frames: 9.5% 30.5% 39.3% 20.7%
x264 [info]: SSIM Mean Y:0.9923593
x264 [info]: PSNR Mean Y:48.194 U:50.425 V:49.115 Avg:48.602 Global:47.983 kb/s:1226.22
encoded 337 frames, 4.03 fps, 1226.66 kb/s
4
x264 [info]: slice P:134 Avg QP:20.70
x264 [info]: slice B:194 Avg QP:22.07
x264 [info]: consecutive B-frames: 8.8% 30.5% 31.1% 9.8% 19.8%
x264 [info]: SSIM Mean Y:0.9923472
x264 [info]: PSNR Mean Y:48.146 U:50.387 V:49.047 Avg:48.551 Global:47.950 kb/s:1210.16
encoded 337 frames, 3.79 fps, 1210.60 kb/s
5
x264 [info]: slice P:135 Avg QP:20.70
x264 [info]: slice B:193 Avg QP:22.11
x264 [info]: consecutive B-frames: 8.8% 31.7% 32.0% 11.0% 9.1% 7.3%
x264 [info]: SSIM Mean Y:0.9923455
x264 [info]: PSNR Mean Y:48.145 U:50.373 V:49.042 Avg:48.548 Global:47.945 kb/s:1210.91
encoded 337 frames, 3.55 fps, 1211.35 kb/s
6
x264 [info]: slice P:135 Avg QP:20.68
x264 [info]: slice B:193 Avg QP:22.09
x264 [info]: consecutive B-frames: 9.1% 31.7% 31.1% 11.0% 7.6% 7.3% 2.1%
x264 [info]: SSIM Mean Y:0.9923446
x264 [info]: PSNR Mean Y:48.149 U:50.385 V:49.046 Avg:48.553 Global:47.949 kb/s:1212.15
encoded 337 frames, 3.29 fps, 1212.59 kb/s

b-adapt 2の速度が大幅にあがりました
特にbframesが大きな値の時
単語が難しいのを除けば中学生レベルの文法なんだが

L0/L1 MVが何なのかよくわからん

>>525
テストエンコ乙
4あたりで十分そうだね

seraphy's build(OreAQ)r967
x264 [info]: slice P:141 Avg QP:20.61 size: 10894 PSNR Mean Y:48.52 U:50.70 V:49.48 Avg:48.92 Global:48.24
x264 [info]: slice B:187 Avg QP:22.01 size: 2494 PSNR Mean Y:47.88 U:50.21 V:48.79 Avg:48.31 Global:47.75
x264 [info]: consecutive B-frames: 9.5% 30.5% 39.3% 20.7%
x264 [info]: SSIM Mean Y:0.9923689
x264 [info]: PSNR Mean Y:48.200 U:50.439 V:49.120 Avg:48.608 Global:47.989 kb/s:1228.75
encoded 337 frames, 3.62 fps, 1229.20 kb/s

consecutive B-framesは変わってないから、コメントの通り退化を心配する必要はあまりないかも。

seraphy氏のbuildまだかなぁ
エンコしようと思ってたDVDあるから全裸待機

クソ、俺はいつになったら手持ちのDVDをエンコすればいいんだい？
これじゃ埒があかないぜ

俺はもう十年近く前？Lame4.0が出たら全CD再エンコするんだという
妙な誓いを建ててたことを思い出したｗ

b-adapt 2高速化くるか！

>>531
ぶっちゃけDVD程度ならエンコいらなくね？
1万ほどで1TBのHDD買えば何枚分入るんだよって感じだ

DVDはそのままDVD-Rに焼けばいい

もたもたしてるとBlu-ray版が出るぞ

俺もそうだがDVDエンコしてる人は見ることではなくエンコ自体が目的なんじゃないかと
綺麗なHDソースもいいがSDソースをなんとかして見られるレベルにするのもおもしろい

>>534
エンコートがしたいんだぜ
分かってくれこの気持ち

>>537
まさにその通りだ
あとエンコしてフォルダに納めるとコレクションしてる感じがあって楽しいのよね

エンコしておくと見たいときに手軽に見られるしね
DVDはケースから出すのが面倒臭い

俺はアニメや映画のプログ化ってだけだな

>>527
L0予測: （時間的に）前方向で利用する予測
L1予測: （時間的に）後方向で利用する予測
同時に使うのが双予測
MV: 動きベクトル

たぶんBスライスにおける時間ダイレクトモードでの話だろう

>>538
気持ちはわかるが、じゃあエンコすればいいじゃんｗ
ソース確保して、その時々のリビジョンで設定追い込むのは楽しいぜ

>>530
seraphy氏リアルで忙しいみたいだしb-adaptやpsy-rdをguiに組み込もうとしたら手間がかかるかもだから
当分来ないと確信

VFR氏がこっそりやってくれたりして

つーかb-adapt2軽量化つってもそんなに変わらんだろ。
フィルター無しでエンコしてる場合、そんなに速度変わらんぞアレ。
劇的に変化してるならエンコ専用マシン作れば良いと思うのだが。

公式で以下のデフォルト値変わったんだな、いつからだろ。
たまには全文見ないといかんな。

--aq-mode <integer> AQ method [1]
- 0: Disabled
- 1: Variance AQ (complexity mask)

--subme <integer> Subpixel motion estimation and partition
decision quality: 1=fast, 7=best. [6]

--psy-rd Strength of psychovisual optimization ["1.0:0.0"]
#1: RDO (requires subme>=6)
#2: Trellis (requires trellis, experimental)

--aq-mode 2がなくなってたのか・・・
2つかったままエンコしてた

>>547
>>487
ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1862&type=1477&space=60&no=0
AQに関しては見逃したんだけど、なんか公式からのアナウンスあったっけ？
patch版とかでは親切にもreadmeで触れてくれてるから大丈夫だったけど。

VAQってVariance AQの略だったのか。
てっきり Variable AQ だと思ってた。

r968で旧aq-modeの変更きてたよ

r968
　　（前略）
　　Since there is no more reason for it, aq_mode 1 is removed.
　　The new mode 1 is in a sense a merger of the old modes 1 and 2.
　　（後略）

--aq-metric の機能削減と --fgo の削除予定だって＞ patch と OreAQ

デフォ設定のVariance AQ のハイブリッド　半日格闘した
m2ts muxでNG　使えねえ

>>553
もう少し詳細に書いてくれ。
具体的にどこが駄目だったのかとか、m2ts自体にまるで使えないのかとか
肝心な情報が欠落してんだぜ。

海外サイトの979試しに使ってみたけどb-adapt2、bdrame16で1パス目fps4割り増しって感じですた

itvfr+OreAQ使いたいんだけど何か方法ない？

その質問飽きた。

>>556
ないよ

4割増はすごいな。

seraphyｷﾀと思ったらCLI版だけだった

ゆっくり待ってるね！

>>560
貴方は居場所を間違えている

>>562
いや、普通にcliでエンコするよ
だがgui版がどう変わるかも見てみたいじゃないか

さっそくcli版を使ってテストエンコしてみたけど、
sse3マシン(P4 Prescott)でicc版が動かなくなっちゃった
まあ、今まで動いてたのがおかしかったのだろうけどｗ

ICC版ってほんとに速いの？

どうでもいいが、地味にreadme内のverがrelease02になってるなｗ
別にaviutlのフィルタを使うから、cliで記述して使う人が居てもいいと思うんだぜ

>>554
すまん。誤爆だ忘れてくれ
別のcpuだと事象がまたちがうので
よくよく考えるとMP4コンテナのmuxは全く問題ないので
m2ts のmuxer側の問題だと思う。。m2ts化は難儀だな

E8600 + XP ICC版の2パス目でエラー報告ダイアログ出たｗ
AQ以外同じオプションのpatch版は重いけど問題なし

seraphy氏の掲示板でtobinakaというキチガイが無理難題を押しつけてる

モード切替にしてOreAQ版とpatch版が統合されるのはアリとは思うが・・・

でも忙しいって言ってる人にやりたくないって言われた事ぐちぐち言うのは
いい加減にしろと…

>>570
英語圏のフォーラムへ出向いて開発に参加しろって要求してる件じゃないの？

tobinaka死ね
1人でオナニーwikiでも買いてろ屑が

どうみても最初の3行以外全部余計だよな…、あれ。

今日も自演ですか

tobinakaのwikiは初心者達には有用で便利な物だろうがtobinaka自体はウザイな
だまってwikiだけ書いて情報発信してればよかったものを・・・

OreAQを自分でビルドしてみようとしたけどdff当てると
外部参照compress2が未解決ってなる…

>>577
詳しく見てないけどzlibをちゃんと設定してる？

いつの間にかRODがデフォルトになってるんだな
CPU新しくしないとまずいな

>>578
それだった。ありがとう。

tobinakaはブログがあるんだからそこでやってればいいのに

あぁいう馬鹿は放置しとけよ。
Seraphy氏のところに書き込み行ってもSeraphy氏も放置すれば
勝手に自滅すると思うよ。

このスレ見てると、本来

x264開発者=>Seraphy>>越えられない壁>>お前ら

なのに

Seraphy(神)>>お前ら(信者)>>チンカス>>x264開発者(技術泥棒ｗ)

になってるのが笑えるｗ
開発者の意向無視しといて技術力(笑)エンコ知識(笑)

>>583
若干違うと思う。

Serapy氏（神） => x264開発者（尊敬） >> 越えられない壁 >> 俺たち > チンカス

こんな感じだと思われる。
チンカスに属する奴は人の為に人の為にと吹聴しつつ、結局は自分の為にしか
行動してない人（某人含む）な。

不等号にtobinakaが入ってないんだけど。

正直、Seraphy版を使ったことがない。akupenguinやDark Shikariは神だと思うが。

OreAQいいよOreAQ

>>585
たぶんブラウザで表示できないくらいの彼方の番外なんだよ

どうでもいい。けなしてるだけの奴も十分沈下巣だ。
そもそもここで話すネタじゃないだろ。seraphyんとこで援護するか
tobinakaのフォーラムに突撃しろよ

>>584が
Seraphy(神)>>お前ら(信者)>>チンカス>>x264開発者(技術泥棒ｗ)
の「お前ら(信者)」の典型な
実に良い例だ
そして>>585>>588が「チンカス」
これも実に良い例

ID:Jg/SNEwH = tobinaka

全員チンカスでいいじゃん

>>591
おまえはまだニコ厨なんかと戦ってるのかｗ

tobinakaはもうだめだろこれ・・・

一体誰と戦っているんだ

tobinakaに言えよめんどくせー奴だな

かかってこいよベネット

x264OreAQ.979.release02.rar
ｷﾀﾜｱ・・

・ぐい

ぐい・・・？

ぐいｗ

普通にguiをローマ字読みしただけだろ

解説すんなよつまらん

r2になってICC版が以前のようにsse3で動くようになった
これで979に移行できるぜ！

まぁSSE2なセロリンMでも動くんだよな

な、なんだってー

x264gui.iniの高画質設定はi8x8使ってないけど何でだろう？

好みの問題だとおもうが…。

高速化されたという--b-adapt 2を試したかったのだが
--psy-rdも--b-adaptも今までの俺のオプションに追加すると
unknown optionと出て動かないのだが

longhelpになちゃんと2つのオプ書いてある

使ったrevは本家の最新から2つのオプが公式化されたrev全部試した

自分のオプは↓です

--crf 20 --level 4.2 --ref 2 --mixed-refs --bframes 3 --b-rdo --bime
--qpstep 8 --weightb --direct auto --subme 6 --no-fast-pskip --no-dct-decimate
--partitions p8x8,b8x8,i8x8,i4x4 --8x8dct --direct-8x8 -1 --scenecut 75
--me umh --merange 16 --aq-mode 0 --sar %PAR% --threads auto --thread-input
--progress --no-psnr --no-ssim

これに--psy-rd、--b-adapt追加するとunknown optionになる

コピペなんでスペルミスは無いはず

誰かご指摘をorz

>>608

rev979(Jarod氏のbuild ttp://x264.nl/)に
>>608のオプション＋ --psy-rd 0.2:0 --b-adapt 2 --output a.mp4 a.avs
を追加してやってみたけど問題なかったよ
バッチファイルの記述が間違ってるんじゃないの？

＞--direct-8x8 -1 --scenecut 75
-1 って何？

>>610
x264 --longhelp

どうでも良い事だろうけど、scenecut 75って高杉じゃね？
ipratio上げてるならともかく。

cartoonじゃねぇの

初心者スレとかにも多いけど、質問に答えずに
突っ込むだけの奴っているよな

質問になってないからだろ
？つければいいってもんじゃない

シーンカット７５は普通じゃね？
特にアニメとか７０以上じゃないと反応しない場合が多いぞ。

とりあえず --level 外してみるとか
最近のなら自動で付くし

trellis入れてないとか？

3Dゲーム動画のシーンカットって悩むなぁ
エンコしている人いたら聞いてみたい
後、psy-rdってビットレートが不足気味な軽くブロックノイズ出ている
奴だったらデフォより0:0にした方が良いと思っているんだけど、
これで正しいのかな

scenecutを使いたくない場合は0指定だっけ？
昔どこかに-1とか書いてたけどどうなの？

>>619
psy-rdは見て比較するしかないから何とも。

>>620
0で合ってる。
-1は内部でクリップされて0にされてると思う。

>>619
ｐｓｙはゲームによっても変わってくる。のっぺりとしたものからやたら細かいのまであるからね。
ちょっとだけ入れるとノイズ多くなるけど元素材には近くなる。offにすると元を見ていないなら綺麗だと思う。

psyの設定がどうにも煮詰まらん
この際は0指定しておくのも手かと思い出した

>>621 622
有難うございます
今は0でやってるんですけど、0.1でも入れるべきなのか悩みますね

ゲームが違うと見栄えも違ってくるから短いサンプル作って見比べるといいよ。

>>621
0と-1じゃ結果違うよ。
--keyintを巨大にして試せば分かる

OreAQ公式に組み込まれないかなぁ。
ITVFRでOreAQ使いたくてもSeraphy氏の対応は期待できないだろうし
それならいっそ公式に組み込まれればいいのに…。

seraphy氏にForumに出て行ってもらわないことには厳しいような気もする。
aq-modeの2以降に追加すればいいだけだから組み込み自体は簡単だろう。

てかソースあるならビルドすればいけんじゃね？

アニメにはVAQ無しで十分と考えられているのに、採用されるのかな。

パッチをあてるだけでできそうだね
itvfr側にtimecodeを出力する機能があればいいのにね

--submeは6と7じゃ圧縮後のファイルサイズは7の方が小さくていいんだよね？
release967やそれ以前の適当なバージョンだと7の方が縮みました
でも今回のrelease979では6の方がファイルサイズが小さくなる
なにか変わったのかしら

>>628
seraphy氏はﾉｰﾀｯﾁですよ、と宣言したOreAQ用の新スレ建ててみるとか。 みんなaviutl使えれば、自分で試せｺﾞﾙｧで済ませれないかな。
むしろ、最初のAQ-debugの使用に戻せば重宝される気もする。ﾉｰﾏﾙAQの方でも。
向こうで好き勝手に弄られたdiffを逆輸入するくらいなら、無視するのも良しで、あんまり負担にならないかと思うのだけど。

適当にitfvrOreAQをビルドしたら動いたけど画像が一部グチャったorz

仕組みとか良くわからんから見た目の印象だがアニメエンコの場合r967以降って改良より悪化した部分の方が多くない？
--aq-mode 2を削除→容量肥大化
--psy-rd→0：0でかなりマシになるが暗部のラインが潰れまくり
--aq-mode 2→確かに良いんだが時間がかかりまくり

そんな貴方にOreAQ

--aq-mode 0 --psy-rd 0.5:0

rev967にしたら途中で止まる・・・

979のまちがい。

オプションくらい書け

>>638
同じくx264OreAQ.979.release02で

---------------------------
AviUtl : Application Exception
---------------------------
アドレス"0x67604682"で例外"0xc0000005"が発生しました

発生モジュール : MSVCR90.dll
オフセットアドレス : 0x00024682
備考 : OUTPUT_PLUGIN_TABLE::func_output() [拡張 x264 出力(GUI)]

正常な動作が出来ない可能性がありますが処理を継続しますか？
---------------------------
はい(Y) いいえ(N)
---------------------------

の同じ箇所で必ず発生する再現度の高いエラー。

オプションは

--crf 26 --psy-rd 0.5:0 --qcomp 0.7 --qpmin 1 --qpstep 16 --scenecut 54 --min-keyint 1 --keyint 300 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --bframes 4
--b-pyramid --bime --weightb --b-adapt 2 --direct "auto" --b-rdo --subme 6 --me "hex" --merange 16 --ref 3 --mixed-refs --threads 2 --trellis 1
--no-deblock --cqm "flat" --no-fast-pskip --no-dct-decimate

--b-adapt 2を --b-adapt 1にすると起きなくなったorz

>>640と同じエラー。
--b-adapt 1でもエラー出てる。同じとこで止まるんで戻してしまったよ。

x264 VFW GUI専用スレ Part4
http://pc11.2ch.net/test/read.cgi/avi/1221328142/

>>640
そのエラー、俺もでた。
調べるの面倒なので、ソースの破損だと思い込むことにして
無視してたよｗ

あれまぁ。何かあるのかね。

俺何もないのは何でだろう？10回くらいエンコしたんだが…

>>609

608です

動作検証して頂きありがとうございます。
記述はオプション晒してる人のpsyとb-adaptの部分だけ
コピペしたのでミスはないはずなのですがもう一度一から
検証しなおしてみます。

他にもご指摘して頂いた方々ありがとうございました。

OreAQ版itvfrビルドしてうまくいかないって書いたけど、
公開されてるx264itvfr-r979.lzhでもだめだったから原因は別かも？
itvfr使ったことないからよくわからん…

とりあえず置いとく。
ttp://www1.axfc.net/uploader/File/so/11299.zip

r03きてるな
修正か？

【修正履歴】
□x264.979.release03
[x264gui]
・追加コマンド／CLIモード時のパラメータ解析ロジックの更新を忘れていました。

>>634
俺も979はなんかダメだと思う。だから967に落ち着くことにした。

953r2から979r3にして
ほぼ同じ設定で試してみたが全然駄目だね
画質ダウン、容量アップ、時間大幅アップ
おまいらの言うとおり967あたりを今度試してみるよ

まだ同じ動画で試してないが、
OreAQ967r1(aq-mode=2)→OreAQ979r2(aq-mode=1)と変えて
特に容量アップということはないようだが？
エンコ時間は短縮してると思うよ(0.4fps→0.55fpsぐらい)
設定にもよるんじゃね？

967r1試してみた
画質ややダウン、容量ダウン、時間大幅ダウン

やっぱ俺もこれにするわ

でっていう

979が悪いって言ってる人は比較に使ったオプションを晒して欲しいな
あと本家なのかOreAQ版なのか？

俺は結構良いと思うけな@patch版

--level 4.1 -p 2 --bitrate 2500 --stats ***.x264 --keyint 240 --min-keyint 24
--scenecut 70 --qpstep 12 --qcomp 0.7 --ipratio 1.4 --pbratio 1.3 --aq-strength 0.5
--b-adapt 2 --bframes 4 -b-pyramid --weightb --bime --partitions p8x8,b8x8,i8x8,i4x4 --8x8dct
--ref 6 --mixed-refs --me umh --merange 32 --subme 7 --b-rdo --trellis 2 --direct auto
--psy-rd 0.5:0.0 --no-fast-pskip --no-dct-decimate --cqm flat --deblock -2:-2

979 aq-mode1 aq-metric0
avis [info]: 720x480 @ 23.97 fps (100 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
mp4 [info]: initial delay 8762 (scale 105000)
x264 [info]: slice I:2 Avg QP:15.49 size: 49506 PSNR Mean Y:50.46 U:51.26 V:52.06 Avg:50.81 Global:50.81
x264 [info]: slice P:44 Avg QP:17.13 size: 22792 PSNR Mean Y:48.53 U:49.35 V:49.80 Avg:48.84 Global:48.64
x264 [info]: slice B:54 Avg QP:17.20 size: 7467 PSNR Mean Y:48.42 U:49.32 V:49.54 Avg:48.73 Global:48.50
x264 [info]: consecutive B-frames: 13.3% 36.7% 21.4% 8.2% 20.4%
x264 [info]: mb I I16..4: 26.3% 57.8% 16.0%
x264 [info]: mb P I16..4: 5.3% 8.1% 3.4% P16..4: 48.0% 12.1% 13.8% 0.0% 0.0% skip: 9.4%
x264 [info]: mb B I16..4: 0.3% 0.7% 0.6% B16..8: 32.6% 3.0% 3.0% direct: 2.9% skip:57.0% L0:40.3% L1:45.7% BI:14.0%
x264 [info]: 8x8 transform intra:49.8% inter:52.5%
x264 [info]: direct mvs spatial:85.2% temporal:14.8%
x264 [info]: ref P L0 56.8% 17.9% 10.7% 4.2% 4.7% 5.8%
x264 [info]: ref B L0 77.2% 13.8% 5.1% 2.6% 1.3%
x264 [info]: ref B L1 92.8% 7.2%
x264 [info]: AQ Result Bright MB: 1.48% QP Up: 8.24% Down:33.46%
x264 [info]: AQ Result Middle MB:79.18% QP Up: 0.43% Down:34.31%
x264 [info]: AQ Result Dark MB:19.01% QP Up: 0.00% Down:58.48%
x264 [info]: AQ Result M.Dark MB: 0.32% QP Up:23.56% Down: 0.00%
x264 [info]: AQ change value 3:0.01% 2:0.04% 1:0.49% 0:60.68% -1:12.05% -2:8.24% -3:10.19% -4:8.23% -5:0.06%
x264 [info]: SSIM Mean Y:0.9911506
x264 [info]: PSNR Mean Y:48.507 U:49.369 V:49.703 Avg:48.819 Global:48.599 kb/s:2885.73
encoded 100 frames, 2.64 fps, 2887.09 kb/s

979 aq-mode1 aq-metric1
avis [info]: 720x480 @ 23.97 fps (100 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
mp4 [info]: initial delay 8762 (scale 105000)
x264 [info]: slice I:2 Avg QP:15.46 size: 49551 PSNR Mean Y:50.46 U:51.26 V:52.08 Avg:50.82 Global:50.81
x264 [info]: slice P:44 Avg QP:17.07 size: 22890 PSNR Mean Y:48.54 U:49.36 V:49.82 Avg:48.86 Global:48.64
x264 [info]: slice B:54 Avg QP:17.18 size: 7481 PSNR Mean Y:48.41 U:49.34 V:49.56 Avg:48.73 Global:48.49
x264 [info]: consecutive B-frames: 13.3% 36.7% 21.4% 8.2% 20.4%
x264 [info]: mb I I16..4: 25.9% 58.5% 15.6%
x264 [info]: mb P I16..4: 5.3% 8.1% 3.5% P16..4: 47.9% 12.4% 14.1% 0.0% 0.0% skip: 8.8%
x264 [info]: mb B I16..4: 0.3% 0.6% 0.6% B16..8: 32.6% 3.0% 3.1% direct: 3.1% skip:56.7% L0:39.8% L1:46.0% BI:14.2%
x264 [info]: 8x8 transform intra:49.8% inter:52.5%
x264 [info]: direct mvs spatial:85.2% temporal:14.8%
x264 [info]: ref P L0 57.9% 17.3% 10.4% 4.0% 4.6% 5.8%
x264 [info]: ref B L0 77.6% 12.9% 5.9% 2.4% 1.2%
x264 [info]: ref B L1 92.6% 7.4%
x264 [info]: AQ Result Bright MB: 1.48% QP Up: 3.50% Down:34.08%
x264 [info]: AQ Result Middle MB:79.18% QP Up: 0.06% Down:34.39%
x264 [info]: AQ Result Dark MB:19.01% QP Up: 0.00% Down:58.88%
x264 [info]: AQ Result M.Dark MB: 0.32% QP Up:10.34% Down: 0.00%
x264 [info]: AQ change value 3:0.01% 2:0.01% 1:0.11% 0:60.94% -1:12.12% -2:8.25% -3:10.26% -4:8.24% -5:0.06%
x264 [info]: SSIM Mean Y:0.9911193
x264 [info]: PSNR Mean Y:48.510 U:49.391 V:49.721 Avg:48.826 Global:48.592 kb/s:2895.72
encoded 100 frames, 2.62 fps, 2897.09 kb/s

seraphy版 x264 rev.967r1
--crf 20 --level 4.1 --b-adapt 2 --bframes 3 --ref 3 --mixed-refs --weightb --subme 7
--aq-mode 2 --aq-metric 3 --aq-strength -0.4 --aq-sensitivity 7.625 --aq2-strength 0.3
--aq2-sensitivity 15 --qcomp 0.7 --cqm "jvt" --psy-rd 0:0 --b-rdo --qpmin 12 --qpmax 26
--no-fast-pskip --8x8dct --partitions p8x8,b8x8,i4x4,i8x8 --me umh --no-dct-decimate
--threads auto --thread-input --progress
x264 [info]: SSIM Mean Y:0.9906217
x264 [info]: PSNR Mean Y:48.411 U:52.141 V:50.960 Avg:49.150 Global:48.592 kb/s:8276.55
encoded 711 frames, 3.17 fps, 6575.39 kb/s

seraphy版 x264 rev.979r3
--crf 20 --level 4.1 --b-adapt 2 --bframes 3 --ref 3 --mixed-refs --weightb --subme 7
--aq-mode 1 --aq-metric 0 --aq-strength -0.4 --aq-sensitivity 7.625 --aq2-strength 0.3
--aq2-sensitivity 15 --qcomp 0.7 --cqm "jvt" --psy-rd 0:0 --b-rdo --qpmin 12 --qpmax 26
--no-fast-pskip --8x8dct --partitions p8x8,b8x8,i4x4,i8x8 --me umh --no-dct-decimate
--threads auto --thread-input --progress
x264 [info]: SSIM Mean Y:0.9908518
x264 [info]: PSNR Mean Y:48.556 U:52.242 V:51.069 Avg:49.287 Global:48.729 kb/s:8561.91
encoded 711 frames, 3.54 fps, 6802.08 kb/s

aq-modeとaq-metricの変更のみ

967 aq-mode2 aq-metric0
avis [info]: 720x480 @ 23.97 fps (100 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
mp4 [info]: initial delay 8762 (scale 105000)
x264 [info]: slice I:2 Avg QP:15.68 size: 48982 PSNR Mean Y:50.41 U:51.20 V:52.00 Avg:50.76 Global:50.76
x264 [info]: slice P:42 Avg QP:16.98 size: 24202 PSNR Mean Y:48.67 U:49.48 V:49.89 Avg:48.98 Global:48.77
x264 [info]: slice B:56 Avg QP:17.38 size: 7146 PSNR Mean Y:48.34 U:49.25 V:49.48 Avg:48.65 Global:48.41
x264 [info]: consecutive B-frames: 10.2% 34.7% 27.6% 12.2% 15.3%
x264 [info]: mb I I16..4: 26.1% 58.1% 15.7%
x264 [info]: mb P I16..4: 5.6% 8.5% 3.6% P16..4: 47.3% 11.9% 14.1% 0.0% 0.0% skip: 9.0%
x264 [info]: mb B I16..4: 0.2% 0.6% 0.5% B16..8: 33.3% 2.9% 2.8% direct: 2.9% skip:56.7% L0:42.4% L1:43.9% BI:13.7%
x264 [info]: 8x8 transform intra:49.9% inter:53.2%
x264 [info]: direct mvs spatial:89.3% temporal:10.7%
x264 [info]: ref P L0 56.0% 18.2% 10.6% 4.2% 4.5% 6.5%
x264 [info]: ref B L0 78.8% 12.8% 4.9% 2.3% 1.2%
x264 [info]: ref B L1 92.8% 7.2%
x264 [info]: AQ Result Bright MB: 2.30% QP Up:14.36% Down:26.97%
x264 [info]: AQ Result Middle MB:78.32% QP Up: 1.09% Down:33.51%
x264 [info]: AQ Result Dark MB:18.87% QP Up: 0.00% Down:49.88%
x264 [info]: AQ Result M.Dark MB: 0.52% QP Up:34.81% Down: 0.00%
x264 [info]: AQ change value 3:0.01% 2:0.07% 1:1.30% 0:62.36% -1:9.23% -2:8.47% -3:14.01% -4:4.57% -5:0.00%
x264 [info]: SSIM Mean Y:0.9911224
x264 [info]: PSNR Mean Y:48.518 U:49.385 V:49.705 Avg:48.830 Global:48.594 kb/s:2904.14
encoded 100 frames, 2.59 fps, 2905.52 kb/s

とりあえず ID:vTruwbJp が適当なこと言ってるのがよくわかった

aq-modeも変更

>>662
そりゃ設定もSSIMもPSNRも晒さないアホの言うことなんか
真に受けちゃだめだって

>>647
激しく乙。
定期的にうｐってくれると助かる。

>>665
動いた？

>>666
ちょっとまだテストできてない。スマソ。
山ほどバッチ組んだ後で見つけたから流れる前に落とした。
明日には報告するよ。

多分pthreadGC2.dllがないと動かないと思う。スタティックリンクにしてなかった。

あ、ちゃんと動いた。itvfrの使い方間違ってたorz
--aq-debugも動いたからこれでできてると思う。

r982。pthreadもスタティックリンクにした。
ttp://www1.axfc.net/uploader/File/so/11328.zip

質問。
99fでプロファイルを分けてSeraphy氏のx264(OreAQ)でエンコすると
音声処理がかなり遅くなることない？
映像エンコと同じぐらい時間掛ってるんだけど謎なんだよね。

GUI版は別スレで

ttp://x264.nl/ のバイナリを使用しています。939の4400+とXPproSP3の組み合わせです。

r979 で、エンコ中に落ちるようになりました。今までこんな現象は無かったのですが。
今の最新r982でも異常終了しました。希にSDの物が完走したりしますが、基本的に
何時間も掛けないとどこで落ちるか把握出来ていないので再現性が有るかどうかは
まだ判断出来ていません。

avsはこんな感じ
LoadAviUtlInputPlugin("C:\Program Files\EARTH SOFT\PV3 3.x\AviUtl\EARTH SOFT DV.aui", "EARTHSOFTDV")
EARTHSOFTDV("D:\aaa.dv")
AssumeFPS(30000,1001)
AssumeFrameBased().ComplementParity()
TomsMoComp(1, 5, 0)
IT(fps = 24, ref = "TOP", blend = false, diMode = 2)
Trim(135,3969) ++ Trim(5409,17995) ++ Trim(20154,40412)
Crop(2, 6, 1912, 1070)
LanczosResize(1280,720)
UnsharpMask(64, 3, 8)
WarpSharp(128, 5, 144, -0.6)
swapuv()
ConvertToYV12()
return last

オプションはこんな感じです。
x264.exe --level=4 -I 240 -i 1 --scenecut 75 -b 1 -r 3 --analyse all
-8 --direct auto --qp 11 --ratetol 8.0 --me umh -m 6 --b-rdo
--no-fast-pskip --no-dct-decimate --cqm=flat --progress -o
"d:\aaa.264" "d:\aaa.avs" --threads auto --thread-input

とりあえず、少し前のリビジョンまで戻ってみます。

--level= だったっけ

982ｷﾀ

>>673
--levelを使うような再生環境が無いので、その辺りは大いに間違ってる
可能性が有ります。だた、rev.up前は特に怒られていないので、上手く
行っているのか、スルーされているかだと思います。

むしろいままでそのオプションで出来てた事が不思議だな。

最近のはlevel指定しなくても勝手に決まるよ

全然間違ってるとかそんなんじゃないんだけど
最近はTrimを逆テレシネのあとに持ってくるのが普通なのかい？

いつの間にやらseraphyの982がきてるな

あんましイジメてやんなよ

>>676
はい。自分でもそう思うのですが、取りあえず再生出来ているので
詰めていません。

>>677
levelにデフォルト値が有るということでしょうか。

>>678
trim以外を作って、VDMで読み込み、VDM上でCMカットしてVDM上の
エディタでtrimを入れています。逆テレシネ前で実行すると、変な周期
で切ってしまったりしないものでしょうか。これも自信は全く無く、動いた
からそのままにしているって感じで・・・。

根拠もない書き込みは無視されるのを分かっていて一言
r979で画質おかしかったけどr982で改善した！
ちなみにseraphyのノーマル版な

とりあえず大丈夫っぽいね

>>681
間にCMがあるのにそれも逆テレシネしといて周期が狂うとかあまり笑わせるなよ
お前はx264よりももっと先に学ぶことがありすぎる
つか、初心者隔離スレがあるんだからそっち使えよ

r983
r980 borked weighted bime

なんかおかしかったのか？

ttp://www1.axfc.net/uploader/File/so/11343.zip
r983 OreAQ itvfr

psyデフォになったと聞いて縮むようになったのかと思ったら普通に1.5倍くらいに膨らむとは

>>687
967から新しいのに変えるとすごく膨らむね
同じ設定にすれば変わらないんだろうけど
何がデフォであるために膨らんでるのか分からない

--longhelpすら見ないの？

x246とかｗｗｗｗｗｗｗｗｗｗｗ
ニコ厨しか使わんだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
しかもニコが廃れてるしｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>690
お前が毎日お世話になってるWinnyとかShareとか

1.5倍ってpsy 1.5:1.5とかアホな設定でもしてんの？

勘違いしている人がおおいけど、psy関係（psy-rdやaq）はx264エンコーダがそれまで
不用意に切り捨ててしまっていたデータを補うものなので、容量だけでみたら増えるよ。

つっても分からないんだろうから分かりやすく言うと、--crf 21 でエンコしてんのに、
実は他のエンコーダでQ24程度の画質しかなかったのが今までで、それで容量が縮んだ
と喜んでいただけ。
最近になって、ようやくQ21程度の画質になったしそれに見合う容量になった。
容量だけしか見ていない人は、--crfの値をもう2〜3上げると前と同じになる。
（それか、psy系のオプションを切る）

ちなみに、H.264はQ26位が標準画質なんだってね。

今までノーマルしか使わんかったんで分からんかったけど
アニメ、flat、VAQ無しの俺の場合psy-rdは0.2ぐらいでいいのかな？

r965 までrev.donwしたら、全く異常終了しなくなりました。
とりあえず報告まで。

r985 が来てる。レアなcrashが多分なおってるらしい。
差し替えてみようかな。

すまん過去ログで見つけた
アニメの場合psy-rdは0か0.1がいいみたいね

>>697
それ情報古い。　たぶんPSYRDO0.5のやつ。
今なら0.2:0.2とか0.4：0.0ぐらいがアニメのオススメ。

サンクス
とりあえず3パターンぐらいでSSIMとPSNRの値比較してみるか

SSIMとPSNR比較しても意味無いよ。下がるから…
あくまで見た目で判断しないと。

とりあえず、落ち着くまでは967で様子見がベストだな

立ち止まるやつはこのスレには必要ありません

皆が967 967っていうから自分どれだろう？って調べてみたら967だった

俺なんか 953 で停まってるぜ

--b-adapt 2 が高速化した今、最新使って失敗してもたいして痛くないしな

っつかおまえらはOPくらいで試してみてるんじゃないの？

>>700
そりゃそうだったな
psy-rdの効果はmp3のような視覚的に分からないところの情報を省いて目立つところへ分配するものだから
見た目で判断するのが正解だった

>>704
確かにSSIMとPSNRではベストな選択だね

>>704
いや、選択じゃなくて単に追いつけないだけｗ
買いかぶらないでくれよｗ

まあ、何十話もあるシリーズを毎日エンコしてたりすると、途中でコーデックの極端な変更あったりすると困るしな

>>698
psy-rd 0:0 と 0.2:0.2 と 0.4：0.0 見比べたけど違いが分からん＼(^o^)／
幸せなのか不幸なのかｗ
crf 18 でやってるせいだろうか？

どうやら、最近はjvtよりflatが流行ってるらしいね
いまだにjvtな俺は異端なのか・・・

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

くっ

個人的には実写にはjvtが合っていると思う
アニメはflat

>>709
フェードイン・アウトで見比べるとよく分かるはず

現在それで検証中

>>709
crf18ならpsy無くてもいいかもね。
ただフェードやらグレイン系に弱くなるのは諦めないとダメかも。
psyは輝度：色差の設定でデフォが1.0:0.0のはず。
色差ノイズが少ないソースは0.4：0.0、逆は0.2：0.2が良いよ。

輝度:色差ではないしデフォは1.0:1.0だよ。

>>716
○　輝度：色差ではない
×　デフォは1.0:1.0だよ

> common.c/L119
> param->analyse.f_psy_rd = 1.0;

> param->analyse.f_psy_trellis = 0;

正しくは何なんだ？

--psy-rd Strength of psychovisual optimization ["1.0:0.0"]
#1: RDO (requires subme>=6)
#2: Trellis (requires trellis, experimental)

RDO＝Rate Distortion Optimisation(レート歪最適化）
Trellis＝一つ前に送り出したデータからどういう「経路」でデータが変換されてきているかを推定する

下段はテキトー

なんかちがうような。
psy_trellisが利用されているのはquant_trellis_cabac関数内だから、DCT後の量子化(quant) -> 逆量子化(dequant)に細工してる。
コメントも鑑みると、再構築されたフレームの高域AC成分（DCT後の右下の要素）を維持する為のバイアス値として機能している
みたい。
これを簡単に表現しろってのは難しいなぁ・・・

r984
Merging Holger's GSOC branch part 1: hpel_filter speedups

r985
Fix rare crash issue in b-adapt
Regression *probably* in r979

なにやらb-adaptでクラッシュするバグが修正されたらしい
まだテストしてないけどseraphy氏版もきてた

r985 OreAQ itvfr
ttp://www1.axfc.net/uploader/File/so/11364.zip

3Dゲームでpsy-rd入れて画質upしたって情報無いのかなぁ
ビットレートギリで今は切ってる

キミが情報を発信すればいいじゃないか

Dark ShikariはPsy RDOをWorld in Conflictや東方等、動きが激しいゲームの映像で調整しているみたいだから、
敢えて切ることは無いと思う。

低ビットレートではH.264よりもDivxの方が良いな個人的には。

H.264はデブロックフィルタ切ると画質がひどすぎる。
かといって入れておくとぼけた眠い絵になるけどね。

逆に高ビットレートではH.264の方が良いな。
デブロックフィルタ切ってもノイズが目立たない絵ならH.264の方が高画質と思う。

デプロックフィルタ切るとかお前が何にもわかってない馬鹿だということが
とりあえずはわかったｗ

具体的に書けよｗ

じゃないとタダのネタｗ

AppleのQTの方が綺麗だな
x264を完全に超えた画質だわ

ネタはお前の方

つまらない釣りだわ。

>>728
同じビットレートでエンコしてdivxもデブロック切ってみろよ

まあ個人的に感想に基づく事実だからな。

事実を受け入れたくないならＮＧにでもしてくれ。

>>732

とっにやっている。じゃないとわざわざ>>726は感想かかないだろｗ

まあまて ID:ucpVEYXY が言っているのは DivX （H.263） と H.264 （DivX） の比較のことかもしれんぞ

On2が新しく出すVP8がx264よりPSNR値が高いと言っている件。
http://www.on2.com/index.php?603

そんなことよりエンコしようぜ！
985でやってるけど安定っぽい？

VP8もいいがVP6マルチスレッドにしてくれんかね

>>735
じゃあ「スレ違いだ」の一言で終わり

>>736
設定わからんしねぇ…r915って古くね？

VP8か・・・・・・

ちと試してみるか。

Divx7になったら色々な人が乗り込んでくるかと思うと鬱だな。
ただcliのみなんだっけ？そうなら大丈夫そうだけど…

心配しなくてもフロントエンドが…

実際に自分で試すのが一番早い。

俺フィルタでごまかすのは嫌いだな。

事実だと立証したいならｻﾝﾌﾟﾙうｐだなｗ　
俺としては、元々低ﾋﾞｯﾄﾚｰﾄ向けにｽﾀｰﾄしたH.264が負けるのは信じがたい。
ただ、細部を潰しまくるのが特徴なのも事実だと思うのでなんとも･･･。
ﾃﾞﾌﾞﾛｯｸも切るか入れるかの二択じゃないんだけどね。 x264と言わずにH.264といったのも何か意味があるの？

VP8は酷い評判しか聞かないけど･･･ これも誰かやってくれｗ

加速しすぎﾜﾛﾀｗｗ

>>743

自分でやれよ。

VC-1より効率の悪い、DivX 6等のMPEG-4 ASPをH.264と比較するには2倍のビットレートが必要。

頭でっかちばっかりだなw

ID:ucpVEYXY = ID:kRO5ih0s

またdeblock切るとか頭のおかしな子が沸いてるのか

「俺フィルタでごまかすのは嫌いだな。」

名言だなｗｗ

デブロックフィルターが嫌いなら、それを必要としないウェーブレット変換のDiracがおすすめ。

まあ、どの規格も一長一短だからな。

どんなビットレートでも
x264が一番発色は良いと思うし。

デコーダーでデブロッキングフィルタを切ると
確かにやばいけどね・・・・・

h.264でデブロック切るのはインタレ動画を解除なしで見るようなもの

>>747
俺は怒っていいんだよな？ｗ
ttp://up.mgdbbs.net/src/0211.zip.html (pass=dtv)

デブロックONでエンコしてOFFにして再生してるとか言うオチ

以下デブロックループと命名しよう。

でぶロックは滅茶苦茶重いんだよな
デブロックなしMain ProfileのH.264だと気分悪い画質になるし、その場合だと他のコーデック使った方が良くなる

>>757
でぶは動きに切れが無くてビジュアル系のバンドは無理だって言いたいんですね ＞＜

デコード速度優先なら、--nfよりも--no-cabacを付けた方がいい。

ガチンコシャープで再現性を競ってこそのh.264だろ
デブロックは趣味の範疇だから再生側にまかせとけ

エンコ　 マイスタークラス　

エンコ・デコード時でもフィルタを一切使わず、
それでいてブロックノイズのないエンコができるおｗ

エンコ　 プロクラス

エンコ時にフィルタを通すお。ブロックノイズも少なくなお。
その代わり、全体にノッペリするけどデコード時でもフィルタ使わなくても綺麗だお。

エンコ　エントリークラス

エンコ・デコード時でもフィルタ使いまくりだお。
流石H.264クオリティだおｗ
X264万歳ｗ

986出てるな

r986 OreAQ itvfr
ttp://www1.axfc.net/uploader/File/so/11397.zip

ところで動いてる？

紛らわしいかもしれんので--helpでバージョンとか出してみた。
ttp://www1.axfc.net/uploader/File/so/11399.zip

>>763
更新が速すぎてついていけてないんだぜ！！
だが激しく乙。

H.264のデブロックフィルターは、DivXなどのデブロックフィルターとは違って
デブロック後の画像をその後の参照フレームとして使用する。
デブロックの方法も厳密に規格化されている。

http://www.ednjapan.com/content/issue/2004/03/feature/feature02.html
＞一般にループ・フィルターは、コンテント適応型非線形フィルターを利用して、
＞境界の両側に存在する2つの画素の一方を修正する機能を果たす。
＞この結果、表示品質を改善できるだけでなく、符号化効率も高められる。
＞なぜならば、動き補償においてデブロッキング・フィルターを通した復号化フレームを
＞利用できるからだ。

ノイズとディテールをデコードの段階で切り分けてくれるともいえる。

そんなわけで、エンコード時にデブロックフィルターを入れているのに
デコード時にデブロックフィルターを切ってしまうと
デブロックフィルターの有無による誤差が蓄積してどんどん絵が乱れる。

H.264のデブロックフィルターとffdshowなどのポストプロセッシングは無関係。

865にしてからMPCのDXVAが効かなくなった…
難しいのぉ…

967はおｋだが、それ以降は全然ダメダメだな
986も糞すぎ

>>768
ダメダメ言ってないで駄目な根拠を示せるデータを晒せよ無能

>>769
使ってみればわかるだろ？使ってみてもどこが糞なのかサッパリわからないのか？無能

>>770
はいはい、釣りですね
>>657-661のデータを見てから言えよ無能

>>771
はいはい、釣りですね
実際に使ってみてから言えよ無能

使ってみてから言ってるんだが？
データも晒せない無能に何を言っても無駄か

無能だから使ってみても糞さ加減がさっぱりわからないんだろ？ｗ
お前自身も何のデータも示してないだろ無能

>>657-661

ID:BQZda6re

こいつ967以降糞とかいってるいつものだろ
相手にするな

http://www.google.co.jp/search?hl=ja&q=%E4%BB%96%E4%BA%BA%E3%81%8C%E6%99%92%E3%81%97%E3%81%9F%E3%83%87%E3%83%BC%E3%82%BF%E3%81%A7%E9%9A%8F%E5%88%86%E3%81%A8%E3%81%88%E3%82%89%E3%81%9D%E3%81%86%E3%81%A0%E3%81%AA&btnG=%E6%A4%9C%E7%B4%A2&lr=lang_ja

>>776
実際糞だろ
池沼は黙ってろ

反論できなくなったのかワロス

負け惜しみ乙ｗ

ID:BQZda6re
ID:BQZda6re
ID:BQZda6re
ID:BQZda6re
ID:BQZda6re

事実を書いただけで基地外二人に絡まれたなぁ・・・

なんというツンデレｗ
相手して欲しかった癖にｗ

ID:KZBJBOMq
ID:BQZda6re
どっちもうぜえよ

事実というだけの証拠がないという話しなのに

人の話聞かねぇな。ゆとり？

967よりは985のが自分のテストの結果ではよくなってますよ。
あくまで自分が普段使うオプションだけかませただけなので、いちいち貼りませんが。

エラーで落ちるって人は985・986では問題ない？

979はエラーありましたが、985はいまのとこ問題ないです。

俺も979のr01でエラー出たけど986は異常なし

rev1000はまだなの？

>>790
焦ってこんなコミットログついたらどうすんだ

r1000
Nothing changed, but I got a 1000!!

全世界から死ねって言われるな

まぁ1000記念で何か特別なことなんてないだろうな

すぐに1001が出て落ち込むことになります

rev1000はtobinakaプロデュースだ

確かにseraphy氏の1000が出ない可能性は大いにあるね

r986
Resolve possible crash in bime, improve the fix in r985

seraphyってミスばっかしてるけど馬鹿なの？
readme読むと○○を忘れてたとかそんなのばっか・・・

プログラマなんてそんなもんだ
うっかりミスでバグがでて1日悩むとかよくある話

>>798
おｋ
あとはお前がやれ

ミスの大半が本人もこのスレ住民にも関係無いGUI関連だからいいじゃないか
あれだけ頻繁に更新するのなんて感謝の気持ちしか湧き上がってこないよ
Doom9なんて週に数えるだけしか読まない俺には絶対無理

>>798
自分でできないくせに他人を貶めるとか馬鹿なの？
コメントを読むと馬鹿らしいというかそんなのバッカ…

seraphy氏が悪いわけじゃないが、x264自体の更新頻度をもう少しゆっくりにしてほしいよな
何日かPCから離れた生活してたら新しいのがどっさりとある
そうなるとどれが安定したバージョンやら…

安定バージョン(笑)とかいう馬鹿はこのスレに来んなよ
明らかな不具合でもなけりゃ最新追っかけるのが当たり前

ttp://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
とりあえずチェンジログを適当見れば大体見当が付く。 オプション変更はまずここ見れば安心だし。
後、nl版のHPに一応適当なrecommended revisionは書いてあったりする。

あまりにもクソスレだったので遊んでみたｗ

rev598 06/10/31
x264 [info]: SSIM Mean Y:0.9889732
x264 [info]: PSNR Mean Y:46.304 U:48.041 V:47.833 Avg:46.739 Global:46.244 kb/s:1352.50
encoded 2338 frames, 3.70 fps, 1354.63 kb/s

rev711 07/12/10
x264 [info]: SSIM Mean Y:0.9893431
x264 [info]: PSNR Mean Y:46.534 U:48.239 V:48.046 Avg:46.966 Global:46.482 kb/s:1391.88
encoded 2338 frames, 4.07 fps, 1392.10 kb/s

rev798 08/03/25
x264 [info]: SSIM Mean Y:0.9893415
x264 [info]: PSNR Mean Y:46.537 U:48.241 V:48.046 Avg:46.968 Global:46.479 kb/s:1391.17
encoded 2338 frames, 4.64 fps, 1391.38 kb/s

rev899 08/07/04
x264 [info]: SSIM Mean Y:0.9894070
x264 [info]: PSNR Mean Y:46.588 U:48.258 V:48.065 Avg:47.011 Global:46.526 kb/s:1398.37
encoded 2338 frames, 4.60 fps, 1398.58 kb/s

rev986 08/09/12
x264 [info]: SSIM Mean Y:0.9891396
x264 [info]: PSNR Mean Y:46.387 U:48.080 V:47.879 Avg:46.813 Global:46.274 kb/s:1292.26
encoded 2338 frames, 4.33 fps, 1292.47 kb/s

rev986 は21日のミスorz
かなり進歩してるのはわかるが、微妙だから2passでやってみよっとｗ

今日はやたらと馬鹿だの無能だの煽る奴が居るな

>>803
自分が更新についていくのをやめた日からそれが安定バージョンさ！

>>806
縮むようになったって認識でよろしいか？

デブロック使わずにPHLみたいなエンコードするのはどうしたらいいんだろうな。
やっぱビットレートを上げるしか方法はないのかな。

987
Fix deblocking + threads + AQ bug

Revision in which this bug was introduced is unknown; it may be as old as b_variable_qp in x264 itself.
　 　　_, ._
　 （　ﾟ Дﾟ）
　　( つ旦O
　　と＿)_)
　 　　_, ._
　 （　ﾟ Дﾟ） 　　ｶﾞｼｬ
　　( つ　O. __
　　と＿)_) （__(）､;.o：。
　　　　　　　　　　ﾟ*･:.｡
r987 OreAQ itvfr
ttp://www1.axfc.net/uploader/File/so/11412.zip

さすがに更新多すぎだろ

やっぱ1000が近いからなのか

>>812-813
乙
凄く前からバグが潜んでたわけか・・・
これで987以前は使えなくなったな

seraphy氏のHP落ちてる？
pingは通るみたいだけど

逆だ
967使ってなさいってこった

>>818
英語が読めないの？

>>816
987以前のやつでも普通にエンコできてただろ
大げさすぎなんだよ

987以前のでエンコしたブツは全部捨てろってか？

また変なのが噛み付き出したな

毎晩のことだ

機械翻訳＋α
デブロッキング+thread+AQバグ　を訂正しました
低いQPsでは、threadとデブロッキングが進行中なら、デブロッキングは不適切に無効にされるかもしれません。
このバグが持ち出されたrevは、知られていません;それは、x264自体のb_variable_qpと同じくらい古いかもしれません。

2pass出来たｗ　987はb-adapt2のせいで少し速度がﾁｰﾄですが。

598 06/10/31
x264 [info]: SSIM Mean Y:0.9892174
x264 [info]: PSNR Mean Y:46.491 U:48.166 V:47.952 Avg:46.911 Global:46.410 kb/s:1351.11
encoded 2338 frames, 3.75 fps, 1353.24 kb/s

711 07/12/10
x264 [info]: SSIM Mean Y:0.9893836
x264 [info]: PSNR Mean Y:46.578 U:48.255 V:48.051 Avg:47.001 Global:46.520 kb/s:1352.12
encoded 2338 frames, 4.00 fps, 1352.33 kb/s

798 08/03/25
x264 [info]: SSIM Mean Y:0.9893974
x264 [info]: PSNR Mean Y:46.585 U:48.263 V:48.052 Avg:47.008 Global:46.525 kb/s:1352.16
encoded 2338 frames, 4.56 fps, 1352.37 kb/s

899 08/07/04
x264 [info]: SSIM Mean Y:0.9894124
x264 [info]: PSNR Mean Y:46.598 U:48.270 V:48.065 Avg:47.021 Global:46.529 kb/s:1351.97
encoded 2338 frames, 4.83 fps, 1352.18 kb/s

987 08/09/22
x264 [info]: SSIM Mean Y:0.9895168
x264 [info]: PSNR Mean Y:46.683 U:48.331 V:48.129 Avg:47.099 Global:46.584 kb/s:1350.79
encoded 2338 frames, 4.89 fps, 1351.00 kb/s

すまん。 >>823は thread じゃなくて threads だった。　ﾏﾙﾁｽﾚｯﾄﾞの時って意味なんか？

>>824

2年で0.2ポイントぐらいしか上がってないのか。

VP8の数値が本当だったら凄いことになるな。

SSIM鑑賞してる奴が多いな……

ttp://www.on2.com/index.php?595
このｸﾞﾗﾌを見ると怪しい気がしてきた。　少なくても低ﾋﾞｯﾄﾚｰﾄ限定なんじゃ？
r915なら、AQも使ってるだろうからPSNR落ちてるはず。　今ならPsy-rd使って印象画質上げれるのもある。

ところでVP8のコーデックってどこで手に入るん？

復活そして更新

--threadsバグ直ったんなら
--thread-queueいらなくなるな

いや関係ないだろ

彼は、今必死になってqueueの意味をググってるところだから、突っ込みはまってあげて！

最近は更新速すぎるわ。そういえば夏の初めくらいだったかに
「おれr1000がでたら結婚するんだ」とか言っていた奴がいた気がする
もう目の前だな

ちょっと離れてると20くらいr上がってるから困る

>>828
自己ﾚｽ。　書き込みすぎ。ﾗｽﾄにしますorz
vp8x264_720p　ってサンプル映像見て、「左の方が全然良いジャン。すげーじゃん」
って思ってたら、左がx264だとさｗｗ　　x264はもっと綺麗だと思ってたから騙されたぜHAHAHA.
ttp://forum.doom9.org/showthread.php?p=1183053 (Doom9 On2VP8)

どうせ987入れてもまたすぐ問題があって明日の朝起きたら988以降がきてるんだろうなｗ

>>835

どう見ても右の方が綺麗だと思うが。左は旗のゆれている部分とかブロックノイズがひどくないか？

>>828
RD曲線は--qpをつかうはず。だからAQは関係ないよ。
まあどっちにせよVP6の頃からH.264をライバル視してたからな、
そこのテストだから信用に足るデータかはなんともいえないな。

>>835
そこのスレッドの書き込みﾜﾛｽｗ
Dark Shikari
＞Indeed, a good joke.

>>835
ビットレートが低いから何とも言えんな

VP8の画質も気になるがエンコとデコードの速度も気になるな。

H.264よりもさらに重かったら当分使い物にならないし。

>>837
ﾌﾞﾛｯｸは酷いね。 更に、Iﾌﾚｰﾑの挿入の方がもっと凄いｗ　その辺には明確な悪意を感じるんだぜ。

VP8はどこかの標準規格にでもならないと、H.264と同じ土俵にすら上がっていない。

なんか左の方のはH.264らしくない映像だな
あんな細かいブロックノイズは出るとは思わないし、もっとボヤけると思うんだが

映像みてみたけど、H.264はどこのエンコーダつかったのか謎だね。
動きの追従がダメすぎ。フリーのx264ですらもっとマシな結果だせるし。
形式からしてQTなんかな？

って、いま本家読んでたらこれr915のx264か。meとかpartitionとか何設定したらこんななるんだろ・・・

>>845
比較対象はx264らしいよ
ttp://www.on2.com/index.php?599
>x.264 video is on the left, On2 VP8 is on the right

ってかx.264って・・・・。
とりあえずオプションを晒してほしいな

もう２年たつから画質面で負けるのはいいとしても、問題は速度なんだよな。

>>835
今ちょろっとテストしてみたんだけど同じ標準画像使って同じrev.のバイナリ使ってるはずなのに
PSNR-Yが1dBも低い結果しか出ない。つまりその結果は俺の結果よりもはるかにいいってことなんだけど
普通オプションの違いだけで1dBも変わらないよなあ？ただJVTの共通実験条件どおりにやると
こんなグラフには絶対ならないから独自の条件でやってるっぽいな

急激に伸びてるなこのスレ

bフレーム数増やすとエラーになる場合があるな
俺だけと思いたい

>835
普通は右の方が綺麗に見えると思うけどねｗ
x264の方はオプションの設定に問題あると思うんだが

H..264を他の規格と比べるのなら、VP8より遙かに見込みがあるDiracとの方が面白いな。

ただ、このスレにある比較画像はx264ではなくASPのffmpeg4だが。
http://forum.doom9.org/showthread.php?t=141195

左も酷いが右のノッペリ感が更に酷いｗ

>>853

いまそこ見たけど、DiracがVC-2で採用されるってマジかよｗ

>>855
>The Dirac Pro specification describes a sub-set of the main Dirac Specification, and is aimed at high bitrate I-Frame only applications for studio and professional use.
>This specification is being considered for approval as SMPTE VC-2.
http://diracvideo.org/specifications

正式にVC-2になっても、一般ユーザーには余り関係無いだろう。
もっとも、私はIntra-onlyのH.264の方がDirac Proよりも効率が良いのではと思っているが。

VC-2を次のゲーム機のコーディックとして使うつもりなのかな。
用途が今のところ不明だな。

WMV 9がVC-1に採用されたと言うだけで、SMPTEはMicrosoftとは関係のない団体だし、
ゲーム機云々は関係無いだろうな。VC-2はスタジオ用だと書いてあるし。

スタジオ用か、なるほどね。

ということはHDCAM-SRのMPEG-4 スタジオプロファイルの対抗コーディックに
なるわけだな。

映画関係を力入れている訳か。

http://kissho4.xii.jp/50/src/5yoshi6953.mp4.html
DLKey:x264

M$のHDサンプルを2048kbpsで2passエンコしてみたけど、やっぱこの位の画質は維持できるよなーと
改めて感じた。1080pWMVをソースにしてフィルタはリサイズのみ。
Dark Shikari氏の反応もうなずける。

デフォ設定だったとか？

デブロックオフだったとか。

>>271
seraphy氏はRDOを少し強めに設定してるんだね
基本的にビットレートが足りていれば切っても問題ないような
--crf 26 --psy-rd 1.0:0.0 とかやると切るよりも綺麗になるのかな
試してみるか

x264 info using cpu capabilities のところでSSE2までしか表示されません
CPUはアスロン64x2なのですがなぜでそう

SSE3じゃなくてSSSE3が使われているからです。多分。
ttp://seraphy.fam.cx/~seraphy/cgi-bin/srch.cgi?no=0&word=SSE3&andor=and&logs=.%2Fcbbs.dat&PAGE=20

そのリンク古すぎｗ
CPU命令の表示については、SSE2をFast/Slow SSE2に分ける仕様変更がはいって、
そのとき実際に使っていないCPU命令は表示上削除された。
削除されたのが、MMXとSSE3だっけかな。
Phenomなら、MMX2 SSE2Fast SSSE3 と表示されるはずだけど。
Athlon64 X2だと、MMX2 SSE2Slow の表示かな。

>>849
俺もやってみたいんだけど、標準画像ってどこで手に入るの？
VQEGの720x486,260ﾌﾚの奴しか持ってない。

まだ落とせてないんだけど、HDのもあった。
ftp://vqeg.its.bldrdoc.gov/HDTV/NTIA_source/

>>865>>866　丁寧な説明ありがとうございました。CPU氏にかけてるのかとガクブルしてました。

ざっと何回かテストしてみましたが987は問題なくエンコできてますね

>>867
ここでみっけた
ttp://forum.doom9.org/archive/index.php/t-135034.html

987にしたらまたb-adapt2の効率落ちた…

>>761

俺いつの間にかプロだったんだなｗ

ニコニコ投稿を目的とした低ビットレート（580kbpsの2pass）についてエンコテストを
r976とr986（各seraphyノーマル版）でオプションの組み合わせを各100パターン程度実施してみたところ
r976の方が良い結果を出した。少しスレ違いだが何かの参考に

↑r967の間違いです

そんな報告はどうでもいい

今日のr967厨は ID:lmEk4f6Y か
もしかしてtobinaka か？

結果もはらずに、ましてや何が良かったのか基準の説明もない・・・
いや、SSIMだっていうならもうご愁傷様としか・・・

psyのせいだな。多分。

エスパーだけに

x264とは関係ないけど使ってる奴も多いだろうから
一応張っておく

Nero AAC Codec 1.3.3.0
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=66050

お、ついに来たのか。近々アップデートされると聞いてたが。

-2passperiod入れて2パスしてみたけど違いがわからん

密かにseraphy氏の-q値総当り調査xlsファイルの更新期待してる
自分でやるの面倒なもんで・・・

>>881
ダウンロードサイトには
Download the latest version of Nero AAC Codec 1.1.34.2
って書いてあったけど、実際落としたら1.3.3.0だった。

そのためのリンク先だな

>>885
> Note that the version numbers and release notes have not been updated yet. This will happen soon, when translation into all languages is done.

まだバージョン番号とリリースノートをアップデートしていないことに注意してください。 すべての言語への翻訳が完了していると、これはすぐ、起こるでしょう。

スレチ便乗。
現状 x264+lame なんだけど、AACってmp3よりいいの？

自分の耳で確かめれば?

んだんだ

>>881
こいつtobinakaじゃね？

>>889
そもそもx264はAVIに入れるものじゃない
それすらわからない馬鹿はここにくるべきじゃない

mkvにmp3入れてるかもしれないじゃないか。

>>893
mp3はaviでないとmuxできないとでも？？
それすらわからない馬鹿はここにくるべきじゃない

>>895
Bフレだよ
何トンチンカンなレスしてんだｗ
アホだろ

>>896=893か？ｗ
誰もaviだなんて言っていないのに（その可能性大だが）
悦に浸ったﾚｽしているから指摘されてるんだよ

>>897
何トンチンカンなレスしてんだ
アホだろ

>>896はageてるしただの荒らしだろ
相手しない方がいい

>>899
今だにagesageいうやついるんだｗ

いつもの人か

>>894
揚げ足とるなよ馬鹿
mkvなんてもっと少ないだろ

mp3ってmp4コンテナに突っ込めるんだけど、それさえ知らないヤツばっかなの？

突っ込めても突っ込まないで欲しい・・・

>>903
そんな我侭なやつは女の子に嫌われるぞ

盛り上がってるところスマン。

　x264+lame → (264+mp3).mkv

なんだわ。
そっか、mkvは少数派なのか。
AACは、>>890がごもっともなのでまた試してみることにするわー

音声はロスレスが一番。非圧縮も除いて。

異論は認めない。

>>906
俺もmkvだ(・∀・)人(・∀・)

>>907
非圧縮ソースならいいかもしれんけどそんなのないしねぇ…

DVDなんかのエンコで音声がAC3の時はそのままmkvに突っ込む。

>>906
皆がmp4でAAC使ってるのは、mp4ではH.264+AACが
ほぼ標準の組み合わせで再生できる環境が多いから

そもそもmkvとか使ってるなら我が道いけばいいと思うよ

AC3もflacも突っ込めるmkvが保存用
サイズ削減してAACを突っ込んだmp4は布教用

>>910が全てだな
mkvは一時期音沙汰がなくなったりで信用できないから使ってないけど
PCという限られた環境では有用かな

LPCM扱えるもんないのかな？

>>913

BDパッケージは普通にあるからね、どうなんだろう・・・・・・・・・

新しいneroaacencがマルチスレッドじゃなくなった件

ちなみに中程度の圧縮率（128）とかだとAACの方がmp3より
音質的には良い、ということになっているようだ。

結局は主観だけどね。

主観もあるけど実装の違いが大きい

DivXとH.264比べるようなものだ。

AVCとAACって名前からして組み合わせたくなるじゃん？

Advanced Video Coding と Advanced Audio Coding ですね。分かります。

まあどっちもISO標準規格だしな

PSPの一番の動画再生が、MP4コンテナでH.264/AVC + AACのみ、と関係あるのでは？

MP3音声のMP4はHaali Media Splitterだと音が出ないからね。
規格では認められてるけど。
そもそも、わざわざMP3音声を使う理由がないのもあるが。

replaygainやユニコードでのタグ付けがmp3だとちょっとあれなのでmp4に容れてるよ。
動画というより音楽再生向けには一定の需要があります。foobar2000なら再生も問題ないし。

ここまで壮大にスレ違い。

ここはスレ違い多すぎだろ

怒濤のような更新が終わってしばらく何も無いな…

gccでcore2最適化オプション付けたら何も無しに比べて15%くらい速くなったｗ
条件にもよるんだろうがなんじゃこりゃｗ

>>928
うｐ

インテルのコンパイラならgccよりももっと高速になりそうだな。

まあでもソースのコンパイラ次第によっては精度が必要な部分が
切り捨てられる場合があるから無難にバイナリの方が良いと思うな。

例えば、自動的にSSEオプションついているなど。

OreAQitvfrのビルドしててやってみた。
そんなに厳密に測ったわけじゃないが、これは誤差では収まらんと思う。
無し…9.27 fps
mmx,sse…9.37 fps
mmx,sse,sse2…9.37 fps
mmx,sse,sse2,sse3…9.34 fps
core2指定、mmx,sse,sse2,sse3,ssse3…10.70 fps
core2指定、mmx,sse,sse2,sse3,ssse3,sse4.1…10.77 fps

どれが欲しい？

>>932
core2指定、mmx,sse,sse2,sse3,ssse3…10.70 fps
クレ

全部ファイルサイズは一致したから
ttp://www1.axfc.net/uploader/File/so/11624.zip
itvfr用。動かなくても知らん。

途中で書き込んじゃった。
全部ファイルサイズは一致したからオプションで結果は変わらないんじゃないかと思う。

H.264は誤差が出ないように整数しか使わないしな。

>>936

本気で言っているのか？

>>934
あんがと

エンコードコアのソースをみればわかるよ＜整数

全部intで書いているのかよｗ

そういう分かりやすい嘘はつかない方が良いぞ。

936は"H.264"と言っているから間違いではない

単発IDでH.264は整数しか使わないと主張するスレはここですか？

ここ、いろんな奴が沸くから楽しいなｗ

逆に俺は符号化の過程のどこで実数演算が使われているのか非常に気になる。
H.264はどのようなデコーダーを使おうとそれがH.264規格に適合している限り
復号画像はバイナリレベルで一致する。それはH.264が符号化(復号時もだが)に
おいて実数での処理が含まれていないからに他ならない。
それ以外の部分において実数演算は多分に使用されてるだろ。

最適化を調べてたらGCC 3の方が速いとかいう実験結果を見つけたのでやってみた。
ちなみに朝のはGCC4.3.2。以下は3.4.5。
最適化無し…10.14fps
SSE3まで有効…10.37fps
Prescott指定、SSE3まで有効…10.40fps
CPU指定無しはこっちの方が速かった。何でやねん。

ちなみに
配布されてるx264itvfr…11.12fps
Prescott指定、SSE3まで有効（OreAQ無し）…11.15fps

>>945
俺itvfrは使わないからテストできなかったけどseraphy氏のICCbuildと比べるとどうなん？
使うプラグインが違うから単純比較できないだろうけど

itvfrを使わずにx264out.auoで出力してみた。

9.57fps

…え？

>>947
itvfrによって間引かれるフレームの分だけエンコが速くなるんだから、その結果でOK

同じ条件でGCC 4.3.2でCore2指定、SSSE3まで有効

12.51fps

！？

>>944
H.264で整数演算だから誤差が発生しない云々は復号（デコード）でしょ？
デコード方法が数式まで厳密に定義されていて、+,-,*とビットシフトだけで出来るように規格化されているから、
デコーダによる差は映像面では発生しない。速度面は別だけど。

だから、符号化（エンコード）については、DCT <---> iDCT間は同じ計算をする必要があるから整数演算になるけど、
その周りの演算（レートコントロールだったり、動き予測だったり）は実数でも問題ない。
でも、SADやSSDを遅い実数でやる意味なんて無いから自ずと整数演算になっているだけでしょ。
x264ではレートコントロールなんかが実数演算かな。

連投失礼

何回か試したけど明らかにGCCビルドの方が速いんですが…
誤差ってレベルじゃねーぞ。

てかseraphy氏のGCCビルド試したら11.16fpsでこれもICCビルドより速いんですけど…

cli版しか使ったことないが以前試した時はICCの方が速かったような
テストしてる人はハード、ソフトの詳細、x264のオプションも書いてくれると嬉しいな
fpsだけ書かれてもへーとしか

実行環境とか細かなコンパイラオプションのデフォルト状態とか
原因はいろいろ考えられるからなんとも言えないな

>>950
わかってるよ。だから符号化の過程のみ整数演算だといった。
H.264において符号化で関係するものといえばDCT・アダマール変換、各種予測、
デブロックフィルタ、あとなんだっけ、そのくらいでレートコントロールや
その他の判定は符号化以前の処理であって復号化時の演算誤差の原因となるものではない。

H.264は確かにデコード方法しか規定されてないけどそもそも誤差が出ない前提で
規格化されてるから結局エンコードも符号化部分は整数で書かないとおかしなことになるよ。
つーかわざわざ重い実数演算で実装する馬鹿はいない。

>>954
理屈が変なんだって。
デコード誤差が出ないように整数演算の規格　⇒　エンコード時も当然整数演算という証明方法は成り立たないよってこと。
H.264エンコーダは結果を良くするために符号化−復号化を繰り返して、参照関係やモード選択の精度をあげているから整数演算を
行っているわけで。（デブロック後のピクチャを参照するから、デブロックの実装はデコーダとおなじ整数式じゃないとダメなようにね。）

乱暴な話、IDRのみの出力でよければ符号化だけ行えば良いので、エンコード時に復号化をする必要が無い。
そうなると、必要外で実数演算を行ったとしてもデコードに影響を与えないから何の問題もない。
つまり、デコードの規格がエンコード処理を定義する必要十分条件にはならないってこと。

それに、実数演算は重いけど、それ相応の利点がある。
レートコントロールを例に挙げたのはまさにその利点を利用した演算だから。
x264でもそれは同じだし、それを馬鹿と呼ぶのはとても残念だ。

俺も試してみた
ソースはいつも使ってる激重設定
マシンスペックはPentium4 3.0GHz (Prescott)
OSはWindowsXP SP2
ソフトは切れるものは全て切って何も起動してない状態

x264OreAQ.987.release01

- x264オプション
--crf "21" --sar "40:33" --aq-mode 1 --aq-strength 0.7 --aq-sensitivity 10
--psy-rd 0.5:0 --aq-metric 0 --scenecut 54 --min-keyint 1 --keyint 300 --8x8dct
--partitions "p8x8,b8x8,i8x8,i4x4" --b-adapt 2 --bframes 6 --b-pyramid --bime --weightb
--direct "auto" --b-rdo --subme 7 --me "umh" --merange 64 --ref 5 --mixed-refs
--threads "auto" --trellis 2 --deblock -2:-2 --cqmfile "custom.cfg"
--no-fast-pskip --no-dct-decimate --progress --output test.mp4 test.avs

- GCC
x264 [info]: SSIM Mean Y:0.9947186
x264 [info]: PSNR Mean Y:52.586 U:55.527 V:56.403 Avg:53.241 Global:49.619 kb/s:1970.96
encoded 400 frames, 0.73 fps, 1971.90 kb/s
filesize 4,117,194 byte

- ICC
x264 [info]: SSIM Mean Y:0.9948823
x264 [info]: PSNR Mean Y:52.614 U:55.551 V:56.414 Avg:53.271 Global:49.625 kb/s:1939.60
encoded 400 frames, 0.76 fps, 1940.55 kb/s
filesize 4,051,811 byte

おや？まあ、C2Dで試さないと意味ないかもしれないがｗ

整数だけでエンコーダー・デコーダー作ってみろよって話だな。

>>957
いや、それは普通に可能・・・とくにH.264の規格なら。
単に、小数で計算した方がもっとエンコード結果がよくなるだろうって処理がいくつかあるだけ。

>>958

プログラムしたことないだろ？もういいからｗ

円周率は3ですね

ゆとり教育どうにかしてくれよ・・・・・・・

えーっと、絶対に実数値を使わないといけないエンコード／デコード処理があるなら書いてみて。(円周率はつかわんでしょｗ）
俺の場合は、精度がある程度ほしいところでも x<<8 して (x+128)>>8 とか、普通に整数で計算しちゃうなー。

浮動小数点数・・

>>962

x264のソースコード全部見てみろよ。マヌケ。

整数だけで書いてあるか？見たことないだろうｗ

H.264の技術情報に整数変換があるから
全部整数でできていると、ゆとりが勘違いしたんだろうな。

>>964
さすがに絶句だわ。
x264で小数を使っているのは事実だが、それが「エンコーダは整数のみで実装できない」という証になると思い込んでるんだな。
どんなところに小数が使われているか、までソースが読めたらそんな無茶な考え方を持つこともなかったのにな。

そうそう、--psy-rdは小数で指定するよな？　あれ、実際に計算している箇所を見てみるといいよ。
昔はFPUが遅かったから、こういう手法で無理やり整数演算に変換して処理したりしたんだよ。

話を横から割り込むようで悪いけど、実数を使わなくてもそりゃ可能だろうけど、
現実的に考えてそんなコーディングはしないでしょｗ
部分的に実数の計算で速度が出ないとかそういう部分はあるかもしれないけど
端から見てると子供の喧嘩みたいだよ、どっちもどっち

もう一生喚いていろ。だれも認めないがな。

プログラミング板で同じ事いったら失笑もんなんだがな。

ここはそこまでみんな詳しくないから寛容だけど。

ゆとりに触った俺が悪かったんだろうな。
>>967
いや、皆さんの大好きなMMXやSSE3で実装するときはそういうコーディングを行う必要があるんだけどね。（SSE2で諦めるのも手だけど）
ただ、MMXやSSE3のコーディング自体がこのスレじゃ「現実的」じゃないかもしれないから、この辺で。

>>970

お前が整数でできるということを証明すれば良いんだよ。
妄想以外で。

次スレ
x264 rev17
http://pc11.2ch.net/test/read.cgi/avi/1222456649/

優待がないとたたんかった

埋め

ID:Ugi+GhIpは本当にPGか？
小数を整数で表現する方法を知らないならマ板に帰って聞いて来い。

うめ

>>974

ID変えなくて良いからさっさと証明して見せよｗ

こっちはお前の妄想でイライラしてんだから。

あらら、他人様まで勘違い攻撃とは。俺のIDは変わってませんよー。もう寝るけどねｗ

>>976

携帯からマルチしているだけだろ。
早く証明しろよ。

もう、小・中学生は規制して欲しいよ。まったくｗ

>>978
それは自殺行為だろwww

ぼくちゃん、

1 + 1+ 1 = 0.1 + 0.1 + 0.1

ですかーーーーｗ

エンコする上で技術情報なんて役に立たない罠梅

昔の8ビット時代はオールアセンブラで書いたりしてビット演算が大変だったんだよ埋め

ひさびさに低レベルの争いを見たよ。

そんなに電波が気に入らないならNGしとけばいいのに。

プログラミングのことはわからないけど
冷静さを欠くと酷いことになるのはゆとりの俺でも勉強になった梅

timeitコマンドで計測してみた。
素材はわっちOP、CPUはCore2 [email protected]、UtVideoで出力したソースをsynthで読み込み。
--crf 20 --threads 3 --sar 4:3 --aq-strength 0.55 --aq-sensitivity 10 --bframes 6 --psy-rd 0.5:0.1
--qcomp 0.7 --qpmin 1 --qpmax 51 --qpstep 16 --min-keyint 1 --keyint 240 --scenecut 70
--8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --b-pyramid --bime --weightb --b-adapt 2 --direct "auto"
--subme 7 --b-rdo --me "umh" --merange 64 --ref 5 --mixed-refs --trellis 2 --cqm "flat" --no-fast-pskip --no-dct-decimate
seraphy氏のICCビルド
Elapsed Time: 0:15:54.393
Process Time: 0:26:59.484
同GCCビルド
Elapsed Time: 0:18:51.473
Process Time: 0:31:30.921
GCC Core2指定（自ビルド）
Elapsed Time: 0:17:13.508
Process Time: 0:28:51.234

--crf 20 --threads 3 --sar 4:3 --aq-strength 0.55 --aq-sensitivity 11 --bframes 6 --psy-rd 0.5:0.1
--qcomp 0.7 --qpmin 1 --qpmax 51 --qpstep 16 --min-keyint 1 --keyint 240 --scenecut 70
--8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --b-pyramid --bime --weightb --b-adapt 2 --direct "auto"
--subme 7 --b-rdo --me "umh" --merange 64 --ref 6 --mixed-refs --trellis 2
--cqmfile "○○\flat+jvt(Top left corner).cfg" --no-fast-pskip --no-dct-decimate --aq-debug "test"
seraphy氏のICCビルド
Elapsed Time: 0:27:07.453
Process Time: 0:38:59.359
同GCCビルド
Elapsed Time: 0:21:43.884
Process Time: 0:37:45.000
GCC Core2指定（自ビルド）
Elapsed Time: 0:19:49.116
Process Time: 0:34:52.828

上は順当だが、下は完全に逆転。ちなみにICCだけファイルサイズが2MB小さかった。これって最適化で出力変わってるってことじゃ…

>>955
誤解出るような書き方をしてしまったようだ。H.264では復号化に
整数の演算しか必要としていないから符号化時も整数でやったほうが
一般的に考えれば都合がいいといいたかっただけ。符号化処理を
実数で実装できなくはないことはわかりきってることだけどH.264以外の
規格で規定されてるような誤差を修正するイントラMBの挿入は必須ではないから
実数で実装すると場合によっては復号時に徐々に破綻していく可能性も否定できない。
規格書読めばわかるけど計算式もきちんと指定されているのにわざわざ
誤差出すリスクと処理の複雑化をしてまで実数計算を考えることはない。
繰り返すけどあくまで主張したいのは符号/復号処理のときの話だけですから。
レートコントロールはデコードには関係ないし性質上実数のほうがやりやすいのだから
そこまで整数にこだわる必要はない。

なんか俺が火種作ってしまったみたいだし長文うぜーだろうから引っ込むよ

うん、どうでもいいこと長々と引っ張ってうざいから消えて

そろそろ次ヌレの季節ですな

x264 の出力ログのslice I/P/Bのglobal値について、お聞きしたいのですが
I/P/Bの順に51 50 49と滑らかに値が揃うのと、全て50に揃えるのと
どちらが良いのでしょうか？

どうでもいい
好きにしろ

ID:Ugi+GhIpがカスだということはわかった

r988

>>985
ぱっと見た感じだと--aq-debugが遅くなる原因かな？
ソースを見るとファイル書き込み時に他のスレッドを待機させているから、スレッドのスケジューリングによる差の予感。

ICCはfloating-pointの高速化をするから、GCCと比べると精度が僅かに悪くなるはず。
その影響で出力結果が変わっている可能性はありかな。
俺も比較したことあるけど、問題はなのはICC版の方がサイズが下がるくせにSSIMが高くなるって事なんだよな…

r988は特に画質や速度に関係ない更新だね埋め

r1000がでたらいろいろエンコしなおす梅

r1001がすぐ出るというのに

r999の次はb1r1だったりしてね梅

ｒ998

r999

r1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。