ageha was here

2007/11/15を以て当ブログは更新を停止しました。記事は全てこのままですが、基本的に内容はOut of dateとお考え下さい。

ホーム > x264

060831-設定篇

　High Profileの為、再生はVLCまたはMPlayerのみ。
　使えそうなオプションは全部使った。書かなくても良い（デフォルト値になる）オプションもデフォルト値で記載。

PowerMac G5 (2Ghz x 2), mem1GB。
MEncoder/x264のビルド日は2006/08/31。
MEncoder dev-SVN-r19595-4.0.1
x264 core:50 svn-558M

※コピペでは動作しない可能性が有ります。円マークとバックスラッシュ混在してるし。

06/08/31 04:26.49 無敵看板娘_07_060818.mpeg
===MENCODER_PASS1===
08/31 04:26.49
/usr/local/bin/mencoder /Users/USERNAME/Movies/無敵看板娘_07_060818.mpeg -nosound -ovc x264 -x264encopts \
threads=2:cabac:bitrate=1024:keyint=240:keyint_min=1:scenecut=55:bframes=2:b_adapt:weight_b:nob_pyramid:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblockalpha=0:deblockbeta=0:cqm=jvt:nofast_pskip:direct_pred=3:psnr:\
pass=1:turbo=1 \
-passlogfile /Users/USERNAME/Movies/無敵看板娘_07_060818.264.log \
-vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup \
-sws 9 -ofps 24000/1001 -of rawvideo -o /dev/null
 
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities Altivec 
x264 [info]: slice I:431 Avg QP:21.50 size: 29156 PSNR Mean Y:44.33 U:48.73 V:49.89 Avg:45.39 Global:44.89
x264 [info]: slice P:15580 Avg QP:23.42 size: 9033 PSNR Mean Y:42.33 U:46.72 V:48.11 Avg:43.43 Global:42.93
x264 [info]: slice B:19937 Avg QP:24.91 size: 2006 PSNR Mean Y:41.93 U:46.50 V:47.97 Avg:43.07 Global:42.71
x264 [info]: mb I I16..4: 41.6% 0.0% 58.4%
x264 [info]: mb P I16..4: 19.0% 0.0% 6.6% P16..4: 48.8% 9.0% 2.4% 0.0% 0.0% skip:14.3%
x264 [info]: mb B I16..4: 0.7% 0.0% 0.5% B16..8: 14.9% 0.0% 0.0% direct: 9.5% skip:74.5%
x264 [info]: final ratefactor: 21.59
x264 [info]: direct mvs spatial:96.8% temporal:3.2%
x264 [info]: SSIM Mean Y:0.9835922
x264 [info]: PSNR Mean Y:42.131 U:46.626 V:48.056 Avg:43.251 Global:42.826 kb/s:1031.35
 
Video stream: 1032.369 kbit/s (129046 B/s) size: 193488208 bytes 1499.373 secs 44937 frames
SEC ; 2969
TIME; 0:49.29

bframes=2:nob_pyramid: これまではbframes=3:b_pyramidを常用していた。アニメや吹き替えの映画では特に問題を感じなかったが、一時間の実写番組でリップシンクに問題を感じたため変更。理由はMEncoderメーリングリストでb_pyramid固有のA/V desync（音ズレ）が議論されていた為。理解は出来なかったが、実写番組での結果はまぁまぁだったので一律に変更した。Bフレーム数もなんとなく2に減らした。
scale=640:480:::4 -sws 9: -sws 9はLanczos。-vf scale=w:h:::Lanczos Filter Length。どうやらこれがDoom9や妖精現実さんが使っているLanczos4やLanczos3に相当するようだ。3 と4の違いはスケーリング時に参照する周辺ピクセルの数らしい。未指定時との画質差は、640x480への縮小ではよくわからない。拡大ではおおいに違うらしい。

===MENCODER_PASS2===
08/31 05:16.18
/usr/local/bin/mencoder /Users/USERNAME/Movies/無敵看板娘_07_060818.mpeg -nosound -ovc x264 -x264encopts \
threads=2:cabac:bitrate=1024:keyint=240:keyint_min=1:scenecut=55:bframes=2:b_adapt:weight_b:nob_pyramid:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblockalpha=0:deblockbeta=0:cqm=jvt:nofast_pskip:direct_pred=3:psnr:\
pass=2:me=3:subq=7:frameref=4:mixed_refs:8x8dct:i8x8:8x8mv:b8x8mv:i4x4:4x4mv:trellis=2:brdo:bime \
-passlogfile /Users/USERNAME/Movies/無敵看板娘_07_060818.264.log \
-vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup \
-sws 9 -ofps 24000/1001 -of rawvideo -o /Users/USERNAME/Movies/無敵看板娘_07_060818.264
 
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities Altivec 
x264 [info]: slice I:431 Avg QP:20.37 size: 29233 PSNR Mean Y:45.50 U:49.10 V:50.24 Avg:46.45 Global:45.90
x264 [info]: slice P:15580 Avg QP:22.18 size: 8822 PSNR Mean Y:43.38 U:46.93 V:48.29 Avg:44.35 Global:43.97
x264 [info]: slice B:19937 Avg QP:23.62 size: 2103 PSNR Mean Y:42.91 U:46.76 V:48.21 Avg:43.95 Global:43.65
x264 [info]: mb I I16..4: 7.5% 69.8% 22.7%
x264 [info]: mb P I16..4: 0.8% 6.7% 1.5% P16..4: 52.9% 12.8% 7.4% 0.3% 0.1% skip:17.4%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 23.6% 1.4% 3.4% direct: 3.4% skip:67.8%
x264 [info]: 8x8 transform intra:72.6% inter:53.8%
x264 [info]: direct mvs spatial:91.1% temporal:8.9%
x264 [info]: ref P 70.5% 14.5% 10.1% 4.8%
x264 [info]: ref B 73.5% 14.8% 7.2% 4.6%
x264 [info]: SSIM Mean Y:0.9847882
x264 [info]: PSNR Mean Y:43.144 U:46.863 V:48.273 Avg:44.155 Global:43.809 kb/s:1024.32
 
Video stream: 1025.342 kbit/s (128167 B/s) size: 192171292 bytes 1499.373 secs 44937 frames
SEC ; 7946
TIME; 2:12.26

　Avg QP(p)=22、Global PSNR=44、数値的にはやや悪い。アニメなら20以下/45は欲しいところだが、他のアニメはぜんぜんその範囲に収まるのでこの素材固有の現象のようだ。実際、動きが多い。
　あれ？なんでref Bに数値が出てるんだ？nob_pyramidつければBは参照フレームにならないハズだが、、、。

===FFMPEG_AUDIO===
/usr/local/bin/ffmpeg -i /Users/USERNAME/Movies/無敵看板娘_07_060818.264 -i /Users/USERNAME/Movies/無敵看板娘_07_060818.mpeg -y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 64 -map 1.1:0.0 /Users/USERNAME/Movies/無敵看板娘_07_060818.aac.mp4

　音声は別途ffmpegで。これはffmpegX版。
　-ab 64で概ね128kbps、音声のみの.mp4ができる。ffmpegはオプションの指定値が異なるものが出回っているようなので要注意。

===MP4BOX_--mux===
/usr/local/bin/mp4box -fps 23.976025 -add /Users/USERNAME/Movies/無敵看板娘_07_060818.264 -add /Users/USERNAME/Movies/無敵看板娘_07_060818.aac.mp4 -new /Users/USERNAME/Movies/無敵看板娘_07_060818.mp4

　これもffmpegX版。
　-fps 23.976025は、電卓で24000/1001を計算した数字と異なるが、浮動小数点（float型）の計算精度いっぱいまでベタで指定するもの。詳細は、Lunatilia（Sylphide 氏）のエントリ「float型」を参照。出来上がりは固定fpsの.mp4になる。

===MP4BOX_--info===
/usr/local/bin/mp4box -info /Users/USERNAME/Movies/無敵看板娘_07_060818.mp4
* Movie Info *
	Timescale 600 - Duration 00:24:59.330
	Fragmented File no - 2 track(s)
	File Brand isom - version 1

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD

Track # 1 Info - TrackID 1 - TimeScale 24000 - Duration 00:24:59.331
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 35948 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 640 x 480
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:24:59.221
Media Info: Language "und" - Type "soun" - Sub Type "mp4a" - 70276 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

　映像と音声の持続時間が0.11sec異なる。1/23.976025=0.04170833155なので、トータルで2.6フレーム程度のズレがある。原因は、冒頭に挿入されるDelay frameの存在と思われる（AVI出力を想定しているMEncoderにはそもそもtimestampの概念が無い。リンク先同様の手法でBフレームに対応していると思われる）。bframes=2だし。
　残りの0.6は以下のような理由と思われる。

ツール間のfps指定値の違い
素材MPEG-2内部の音声delay

　実感としては、24分アニメや30分の落語、一時間程度の実写番組は上記の設定でほぼ気にならない。
　しかしWin界では映像と音声をmuxする際に音声にdelayをかけるのが一般的なようなので、それに相当する手法を見つければ良いと思われる。

スポンサーサイト

[ 2006/09/01 00:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

060831-結果篇

　High Profileの為、再生はVLCまたはMPlayerのみ。

PowerMac G5 (2Ghz x 2), mem1GB。
MEncoder/x264のビルド日は2006/08/31。
MEncoder dev-SVN-r19595-4.0.1
x264 core:50 svn-558M
映像ビットレート1024kbps, アニメは24000/1001fps,実写は30000/1001fps
その他の設定。

VGA(640x480)

種	タイトル	Hrs	FPS1	FPS2	FPS	I 枚数	I比率	Avg QP (P)	PSNR (Grobal)
R	日本の話芸_へっつい幽霊_060820	4.95	10.37	4.26	3.02	230	0.43%	20.96	45.09
A	ゼーガペイン_21_060824	2.83	15.16	5.77	4.18	441	1.04%	18.74	47.19
A	ゼーガペイン_20_060817	2.82	15.19	5.78	4.19	490	1.15%	19.37	46.79
A	エア・ギア_20_060823	3.00	14.93	5.54	4.04	402	0.92%	20.79	45.55
A	無敵看板娘_08_060825	2.91	15.21	5.92	4.26	431	0.97%	22.47	43.79
A	無敵看板娘_07_060818	3.03	15.14	5.66	4.12	431	0.96%	22.18	43.81
A	まんが日本昔ばなし_34_060816	2.90	15.17	5.86	4.23	294	0.67%	20.81	44.60
A	ケロロ軍曹_123_060818	2.98	15.16	5.69	4.14	361	0.81%	18.19	47.00
	平均	3.18	14.54	5.56	4.02	385	0.87%	20.44	45.48

　数値的にはいずれも問題無い。Avg QP(p)が20を切れば、無駄に高画質と言って良いと思う。唯一、無敵看板娘の値がアニメとしては異常に悪い。シーンカットはゼーガペインの方が多い事から、純粋に動きが多いと言える。この番組は毎週こんなもんだ。一見地味だが丁寧によく動く。

VISTA(640x352)

種	タイトル	Hrs	FPS1	FPS2	FPS	I枚数	I比率	Avg QP(P)	PSNR (Grobal)
A	ガイキング_34_060820	2.38	19.39	7.41	5.36	415	0.90%	18.13	46.02
A	シムーン_21_新天地への扉_060822	2.31	19.24	7.42	5.35	367	0.82%	17.27	46.53
A	NHK_07_モラトリアムにようこそ！	2.37	18.80	6.91	5.05	374	0.87%	18.17	46.24
A	ドットハックルーツ_20_060824	2.29	19.46	7.49	5.41	298	0.67%	16.13	47.33
A	ドットハックルーツ_19_060817	2.27	19.54	7.57	5.45	290	0.65%	15.90	47.22
	平均	2.32	19.29	7.36	5.33	349	0.78%	17.12	46.67

　数値的にはいずれも問題無い。無駄に高画質と言って良いと思う。解像度を上げるか、ビットレート下げるかといったところ。
　15inならともかく、17inでは物足りない気もする。

[ 2006/09/01 00:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

060915-結果篇

　HighProfileの為、再生はVLCまたはMPlayerのみ。

　今回の録画はPowerMacG4 450Mhz(Cube), mem 1.5Gb, CaptyTVF1M、MPEG-2。
　ビデオデッキ経由（S端子）なのでノイズ類は多少減っている筈。３次元YC/DNRとかなんか良く解らない機構が付いてるのでそれも使った。
　映像bitrateは最大の15Mbにしたが、それでもコヨーテラグタイムショーのオープニングなど、多少ブロックノイズが乗ったコマがある。

　Avg QP(P), PSNRともに060831-結果篇よりは良い。厳密な比較ではないし、あくまで数値的な話。
　手許では特に気を使っていないが、やはり画質を気にするならまずチューナーの性能、他にケーブルの質と繋ぎ方、といった基本が大事なようだ。

　エンコードの概要は以下。

PowerMac G5 (2Ghz x 2), mem1GB。
MEncoder/x264のビルド日は2006/09/11。
MEncoder dev-SVN-r19794-4.0.1
x264 core:50 svn-560M
映像ビットレート1024kbps, 2パス, アニメは24000/1001fps, 実写は30000/1001fps, lanczos 3
その他は060831-設定篇に同じ。

VGA(640x480)

種	タイトル	Hrs	FPS1	FPS2	FPS	I枚数	I比率	Avg QP (P)	PSNR (Grobal)
-	平均	5.148	12.66	5.13	3.65	526	0.89%	19.97	45.74
A	無敵看板娘_FW_07	3.60	12.38	5.09	3.60	463	0.99%	19.77	45.36
A	無敵看板娘_FW_08	3.21	12.73	5.55	3.86	439	0.98%	20.36	45.26
A	無敵看板娘_FW_09	3.09	14.05	5.66	4.03	464	1.03%	19.15	46.26
A	無敵看板娘_FW_10	3.16	14.84	5.34	3.92	455	1.02%	20.04	45.36
R	BSアニメ夜話_23_鋼の錬金術師	9.04	10.69	4.24	3.04	783	0.79%	20.48	45.97
R	BSアニメ夜話番外編「アニメの時間よ永遠に」	8.78	11.31	4.89	3.41	553	0.51%	20.02	46.24

　数値的にはいずれも問題無い。AvgQP(p)が20を切れば、数値的には無駄に高画質と言って良いと思う。ビデオデッキ経由のおかげかアニメとしては異常に悪い無敵看板娘も20に収まっている。
　時間的には実時間の9倍程度。映画だったら20時間コースだなぁ。
　関係ないけど岡田斗司夫さんはいつも一人だけ肌の質感が違う。うまく言えないが圧縮耐性が高いと言うかお肌がキレイと言うか。素材と比べた時の劣化度合いが一人だけ違う。経験上、出始めのカラー映画なども圧縮耐性が高く、わりと画質劣化を感じない印象があるので、ドーランべた塗りだと思う。またはあの人がアニメ。
　なお、-fps 29.97でmuxしたBSアニメ夜話の終盤で微妙なリップシンク（音ズレ）を感じたのでmp4boxで-fps 29.970030でmuxし直した。この他に実写の普通番組は30分の落語くらいしか録画しないので大きな問題を感じていなかった。

VISTA(640x352)

種	タイトル	Hrs	FPS1	FPS2	FPS	I枚数	I比率	Avg QP (P)	PSNR (Grobal)
-	平均	2.460	18.69	6.89	5.03	386	0.87%	14.21	49.47
A	コヨーテラグタイムショー_FW_07	2.45	17.87	6.94	5.00	432	0.98%	15.14	48.71
A	コヨーテラグタイムショー_FW_08	2.52	18.18	6.62	4.85	347	0.79%	14.33	49.13
A	コヨーテラグタイムショー_FW_09	2.43	18.60	6.89	5.03	380	0.86%	14.32	49.37
A	コヨーテラグタイムショー_FW_10	2.65	17.63	6.26	4.62	403	0.91%	15.10	48.96
A	コヨーテラグタイムショー_FW_11	2.43	18.75	6.89	5.04	427	0.97%	14.12	49.75
A	ゼロの使い魔_FW_07	2.61	17.88	6.08	4.54	383	0.90%	15.62	48.28
A	ゼロの使い魔_FW_09	2.37	19.51	6.82	5.06	367	0.85%	14.63	48.86
A	ゼロの使い魔_FW_10	2.21	19.74	7.49	5.43	384	0.89%	14.65	49.08
A	僕等がいた_FW_07	2.42	19.06	7.49	5.37	416	0.89%	13.01	50.40
A	僕等がいた_FW_09	2.57	18.75	6.92	5.06	343	0.73%	12.11	51.29
A	僕等がいた_FW_10	2.41	19.59	7.42	5.38	362	0.77%	13.24	50.31

　数値的には無駄に高画質。PSNR50は初めて見たかも。『僕等がいた』は色数も動きも少なく、現在録画してるうちでは最も圧縮しやすい部類。I比率の低さは"カメラの長回し"が多く、Avg QP(p)の低さは動きが少ない事を示している。つまり安上がり。

余談

　安上がりだからつまんないって事もないんだけど、全部は見てらんないので。
　I比率とAvg QP(p)の傾向が特徴的なものは見てます。
　前回、同一条件下のエンコードでI比率が低いのに妙にAvgQP(p)が高かった『無敵看板娘』は動きがミモノなのではないか、とか。
　I比率もAvg QP(p)も高い『ゼーガペイン』は良く動く短いカットが沢山詰まってんじゃないか、とか。
　なんとなく作り手がリキ入れてるところが見えてきそうな気もします。
　まぁ、実時間の9倍もかけるより見るほうが早いんだけど、映像に手のかかってない物が数値で出るのは面白いです。
　逆に、I比率もAvg QP(p)も極端に低い『僕等がいた』はそれはそれでなんか演出上の意図があんぢゃねぇか、と勘ぐってみたりして。

　丁度BSアニメ夜話番外編で、アニメは作り手が「光あれ、とさえ言えば光がでてくる。なんでもできる。だから作るのが面白い」というような事を辻真先さんが言っておられたが、で、あれば、それこそ描かれたもの一木一草に意味があるわけで。

　実際『無敵看板娘』はちょっとミモノだと思う。地味に丁寧で。ちまちまエンコ記録取ってなきゃ見ようとも思わなかったハズだ。「アニメの本質は動きによる演出」と言ったのは大塚康夫さんだったかなぁ、と思ってたらエンディング描いてるのがご本人でやんの。ちょっとびっくり。

[ 2006/09/16 00:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

shellscript；映画・アニメ用

概要

　HighProfileの為、再生はVLCまたはMPlayerのみ。
　拡張子.mpegのMPEG-2 PSから、AVC/H.264 HighProfile の [ x264 + aac ].mp4にエンコードします。
　動作には別途、以下が必要です。

MEncoder with x264（SVNビルド）
ffmpeg（ffmpegX 0.0.9u以降から抽出可）
mp4box （同上）

　使えそうなx264オプションはほとんど使っており、書かなくても良い（デフォルト値になる）オプションもデフォルト値で記載。
　QuickTime Playerでの再生が必要な場合は、OPTSME_VP1/VP2をしかるべく弄る必要があります。その際はmuxmovieでrawvideo.264の冒頭を1フレームカットするとQuickTime Player Proで再加工できるようになります。下記ではmuxmovieは動作しないようにしています。

スクリプト

　※コピペでは動作しない可能性大です。特にSafari。
　※ツールパスは適宜書き換えて下さい。

#!/bin/bash
# Version 060917 charset="UTF-8",LF

#変数指定
##変数_ツールパス、出力拡張子指定
MENCODER=/usr/local/bin/mencoder
FFMPEG=/usr/local/bin/ffmpeg
MP4BOX=/usr/local/bin/mp4box
MUXMOVIE=/usr/local/bin/muxmovie
EXT=mp4

##変数_MEncoder Options --Video
EXTME=264
OPTSME_A="-nosound"
OPTSME_V="-ovc x264 -x264encopts threads=2:cabac:bitrate=1024:keyint=240:keyint_min=1:scenecut=55:bframes=2:b_adapt:weight_b:nob_pyramid:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblockalpha=0:deblockbeta=0:cqm=jvt:nofast_pskip:direct_pred=3:psnr"
#:nodct_decimate
OPTSME_VP1=":pass=1:turbo=1"
OPTSME_VP2=":pass=2:me=3:subq=7:frameref=4:mixed_refs:8x8dct:i8x8:8x8mv:b8x8mv:i4x4:4x4mv:trellis=2:brdo:bime"
OPTSME_VF="-vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup"
OPTSME_OTHER2="-sws 9 -ofps 24000/1001 -of rawvideo"

##変数_ffmpeg Options --Audio
EXTFF=aac.mp4
OPTSFF="-y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 64 -map 1.1:0.0"

##変数_mp4box Options --mux
OPTSMP4BOX="-fps 23.976025"

##変数_muxmovie Options --Cutting Delay Frame
EXTMX=mov
OPTSMX="-startAt 00:00:00.05"

#for loop
for f in "$@"
do
foME="${f%.*}.${EXTME}"
foTEXT="${f%.*}.txt"
foTEXTLOG="${f%.*}.txt.log"
echo `date +%y/%m/%d" "%H:%M.%S` ${f##/*/} | tee ${foTEXT}

## MENCODER_PASS1
echo "===MENCODER_PASS1===" | tee -a ${foTEXT}
START_SEC=`date +%s`;echo `date +%m/%d" "%H:%M.%S` | tee -a ${foTEXT}

echo ${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP1} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER2} -o /dev/null | tee -a ${foTEXT}
${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP1} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER2} -o /dev/null >& ${foTEXTLOG}

### JIkan Keisan
echo " " | tee -a ${foTEXT};grep x264 ${foTEXTLOG} | tee -a ${foTEXT};echo " " | tee -a ${foTEXT};grep stream ${foTEXTLOG} | tee -a ${foTEXT};END_SEC=`date +%s`;TOTAL_SEC=`expr $END_SEC - $START_SEC`;HRS=`expr ${TOTAL_SEC} / 3600`;MIN=`expr ${TOTAL_SEC} % 3600 / 60`;SEC=`expr ${TOTAL_SEC} % 60`;TOTAL_TIME=${HRS}:${MIN}.${SEC};echo "SEC ; ${TOTAL_SEC}" | tee -a ${foTEXT};echo "TIME; ${TOTAL_TIME}" | tee -a ${foTEXT};echo " " | tee -a ${foTEXT}

## MENCODER_PASS2
echo "===MENCODER_PASS2===" | tee -a ${foTEXT}
START_SEC=`date +%s`;echo `date +%m/%d" "%H:%M.%S` | tee -a ${foTEXT}

echo ${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP2} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER2} -o ${foME} | tee -a ${foTEXT}
${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP2} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER2} -o ${foME} >& ${foTEXTLOG}

### JIkan Keisan
echo " " | tee -a ${foTEXT};grep x264 ${foTEXTLOG} | tee -a ${foTEXT};echo " " | tee -a ${foTEXT};grep stream ${foTEXTLOG} | tee -a ${foTEXT};END_SEC=`date +%s`;TOTAL_SEC=`expr $END_SEC - $START_SEC`;HRS=`expr ${TOTAL_SEC} / 3600`;MIN=`expr ${TOTAL_SEC} % 3600 / 60`;SEC=`expr ${TOTAL_SEC} % 60`;TOTAL_TIME=${HRS}:${MIN}.${SEC};echo "SEC ; ${TOTAL_SEC}" | tee -a ${foTEXT};echo "TIME; ${TOTAL_TIME}" | tee -a ${foTEXT};echo " " | tee -a ${foTEXT}

## FFMPEG_AUDIO
echo "===FFMPEG_AUDIO===" | tee -a ${foTEXT}
foFF="${f%.*}.${EXTFF}"
echo ${FFMPEG} -i ${foME} -i ${f} ${OPTSFF} ${foFF} | tee -a ${foTEXT}
${FFMPEG} -i ${foME} -i ${f} ${OPTSFF} ${foFF}

## MP4BOX_--mux
echo "===MP4BOX_--mux===" | tee -a ${foTEXT}
echo ${MP4BOX} ${OPTSMP4BOX} -add ${foME} -add ${foFF} -new ${f%.*}.${EXT} | tee -a ${foTEXT}
${MP4BOX} ${OPTSMP4BOX} -add ${foME} -add ${foFF} -new ${f%.*}.${EXT}

## MP4BOX_--info
echo "===MP4BOX_--info===" | tee -a ${foTEXT}
echo ${MP4BOX} -info ${f%.*}.${EXT} | tee -a ${foTEXT}
${MP4BOX} -info ${f%.*}.${EXT} | tee -a ${foTEXT}

## muxmomvie -- Cut Delay frame
#echo "===muxmomvie -- Cut Delay frame ===" | tee -a ${foTEXT}
#echo ${MUXMOVIE} ${OPTSMX} ${f%.*}.${EXT} -o ${f%.*}.${EXTMX} | tee -a ${foTEXT}
#${MUXMOVIE} ${OPTSMX} ${f%.*}.${EXT} -o ${f%.*}.${EXTMX} 2>> ${foTEXT}

## 中間生成物削除
rm ${foME}
rm ${foME}.log
rm ${foFF}
rm ${foTEXTLOG}

done

解説

１）CotEditorで保存。UTF-8。ファイル名は仮に"VGA24"とします。
２）ターミナルで"VGA24"に実行権限を与える。

$ chmod a+x VGA24

３）ターミナルでVGA24、続いて素材ファイルをD&D。複数処理可。リターンで開始。例えば"VGA24"がデスクトップにある場合、

$ /Users/ユーザ名/Desktop/VGA24 ここにXXX.mpegをD＆D リターン

[ 2006/09/17 00:00 ] MEncoder　メモ | TB(0) | CM(0)

SSIMとはなんぞや

最終更新 2005/07/12 -- TheSSIM Index for Image Quality Assessment

TheStructural SIMilarity (SSIM)index is a novel method for measuring the similarity between twoimages. TheSSIM index can be viewed as a quality measure of one of the imagesbeing compared, providedthe other image isregarded as of perfectquality. It is an improved version of the universalimage quality index proposed before. A brief description ofthemethod canbe found here.More details are given in the following paper:

　試訳：

　構造的類似性（Structural SIMilarity）指数は二つのイメージの類似性を計測する新しい指標です（＊原文初出は2003/02＊）。SSIMは片方の画像が完璧な画質と考えた場合、比較対象となる画像の品質を測るモノサシと言う事が出来ます。SSIMは以前に案出された汎用画像品質指標の改善版です。SSIMの簡単な説明はここにあります。ここでは、より詳細な説明をします。

◆◇◆

　で、もちろん簡単な説明すらわかりゃしない。PSNRとは別の指標という事だろう。一応PSNRとは、ピークシグナル toノイズレシオ。高いほど画質が良いとされるが、人間の印象とは必ずしも一致しない。
　x264cliではデフォでSSIMを計測する。

 --no-psnr Disable PSNR computation
 --no-ssim Disable SSIM computation

　MEncoder -x264encoptsではなにもしなくてもログに出る（PSNRは明示的に指定しないと出ない）。
　PSNR・SSIM・VQMによる全CODEC客観的比較（BAL BAL NET - 2004/01/12更新）を見ると、これも高いほど画質が良いっぽい。
　MasaHaseさんのうぇブログのこの記事では、アニメ素材なら、ソースの解像度が720x480のときSSIMにして99～98%が狙える。主観でいえばオリジナルとの差が見分けられない。と表現している。
　手許のログを漁るとほとんどが99%以上だった。設定は1024kbps,2pass,横幅640固定。MasaHaseさんの2000kbps,3pass, 720x480と大差ないワケがないので、SSIMで気にすべきなのは小数点以下3桁目以降かも知れない。
　一応、060915-結果篇に追記したものは以下（その他の設定はおおむね060831-設定篇に同じ）。

VGA(640x480)

種	タイトル	I枚数	I比率	Avg QP (P)	PSNR (Grobal)	SSIM
-	平均	526	0.89%	19.97	45.74	0.9903196
A	無敵看板娘_FW_07	463	0.99%	19.77	45.36	0.9901443
A	無敵看板娘_FW_08	439	0.98%	20.36	45.26	0.9892927
A	無敵看板娘_FW_09	464	1.03%	19.15	46.26	0.9909509
A	無敵看板娘_FW_10	455	1.02%	20.04	45.36	0.9899225
R	BSアニメ夜話_23_鋼の錬金術師	783	0.79%	20.48	45.97	0.9903982
R	BSアニメ夜話番外編「アニメの時間よ永遠に」	553	0.51%	20.02	46.24	0.9912088

VISTA(640x352)

種	タイトル	I枚数	I比率	Avg QP (P)	PSNR (Grobal)	SSIM
-	平均	386	0.87%	14.21	49.47	0.9936473
A	コヨーテラグタイムショー_FW_07	432	0.98%	15.14	48.71	0.9924971
A	コヨーテラグタイムショー_FW_08	347	0.79%	14.33	49.13	0.9929892
A	コヨーテラグタイムショー_FW_09	380	0.86%	14.32	49.37	0.9933534
A	コヨーテラグタイムショー_FW_10	403	0.91%	15.10	48.96	0.9926276
A	コヨーテラグタイムショー_FW_11	427	0.97%	14.12	49.75	0.9934556
A	ゼロの使い魔_FW_07	383	0.90%	15.62	48.28	0.9926050
A	ゼロの使い魔_FW_09	367	0.85%	14.63	48.86	0.9932632
A	ゼロの使い魔_FW_10	384	0.89%	14.65	49.08	0.9936109
A	僕等がいた_FW_07	416	0.89%	13.01	50.40	0.9952227
A	僕等がいた_FW_09	343	0.73%	12.11	51.29	0.9954948
A	僕等がいた_FW_10	362	0.77%	13.24	50.31	0.9950015

疑問

小数点以下7桁も出るので、重要なのは小数点以下３桁目以降と思われる。たぶん99%切ったら論外くらいのイキオイ。私大文系としてはそこを強調する表記方法が欲しいところではある。小数点計算で7桁目の精度は一応用心して切り捨て、VISTA平均99.3647%、VGA平均99.0319%。とか。
手許ではインタレ解除もデノイズもかけてる。MEncoderとx264の関係上、SSIMの比較対象は元画像ではなく、-vfチェインが吐き出した後のデータではないか。winは持ってないが、たぶんAviSynthの出力だろう。

MEncoderのログはY（輝度信号）の平均SSIMを出しているように見える。UVは出ないっぽい。

x264 [info]: SSIM Mean Y:0.9880310
x264 [info]: PSNR Mean Y:44.499 U:48.195 V:49.478 Avg:45.514 Global:45.450 kb/s:1024.56

　主観的な画質はあまりにもいろいろな要素に左右されるので下手に書くのは躊躇われるのだけれど。自分としてはAvg QP(p)が最も肚に落ちる。
　アニメで20以下はbitの無駄。実写の20はもうちょいなんとかなんないかな、といったところ。噺家さんの着物の質感とか、きっといーもの着てるんだろうに潰れちゃってるなって感じ。まぁ言い出すとキリないし、bitrate上げる気もないんだけど。さらにさらに主観的には-x264encoptsより-vf チェインのほうが影響デカイ。

[ 2006/09/19 00:00 ] 動画　動画全般 | TB(0) | CM(0)

無敵看板娘

　2006年の秋口に終わったアニメの中ではゼーガペインの評判がよさそう。自分も結構好き。
　アニメは一応こんだけ録画してる（た）。

NHK
エア・ギア
ガイキング
ケロロ軍曹
シムーン
ゼーガペイン
ドットハックルーツ
まんが日本昔ばなし
無敵看板娘
僕らがいた
コヨーテ・ラグタイムショー

　2ndモニタで一応再生はするんだけど、目線はだいたい他にある。横目であー奇麗だなとか、可愛いなとか、うお、このカットそう繋ぎますかとか、断片的な印象ばかりでお話はまるで把握してない。そんな見方で印象に残るゼーガペインも面白そうなのだが、ここでは『無敵看板娘』の事を。実はこれだけは毎回ちゃんと"見た"。

　ギャグアニメなんで、たぶんネタバレもへったくれもありゃしないと思います。

■エンコードログ：2006/07/20-09/24, 2pass, 640x480, 1024kbps

タイトル	I枚数	I比率	Avg QP (P)
VGAアニメ平均値（無敵看板娘を除く33件）	401	0.92%	20.10
『無敵看板娘』平均（02-12話）	439	0.98%	22.16

　※大体一週間ぶん溜まったらMEncoderとx264をビルドしてエンコ。その際設定も弄る事があるが、変更は番組ごとではなく一回のエンコ単位（参考）。全て同一な条件は録画機材だけ。

　AvgQP(P)はPフレームの量子化値（全P平均）。低いほど画像の"省略"が少ない。深入りを避けるために肚の中では「画質劣化度」と読み替えている。自分の視覚では20あれば充分。毎週ひとつだけ妙に高い印象があったが、やはり『無敵看板娘』は平均的に画質劣化度が高い。そうしないと1024kbpsに収まらないと言う事。

　AvgQP(P)が高いのは、動きが多い、もしくは（and / or）、ディテイルが細かい事を意味する。

　ディテイルは別にCGバリバリでも背景美術が凝ってるわけでも無く、まぁこんな感じで平々凡々。Avg QP(P)はノイズ次第でぐっと上がるが、天気かなにかで日ごとに違うので平均すれば影響は減るし、他の番組も録画条件はおんなじ。

　『無敵看板娘』は動きが多いという事になる。毎週コンスタントに。

■「アニメはエンコしやすい」の例外～（株）テレコム・アニメーションフィルムに気を許すな

　どうもカギはカメラワークらしい。
　例えば、パンチ食らった側のふらつき感を強調するためにカメラをパンさせてる、ように思える場面があった。よろめきにあわせて、しかし人物の移動速度とは少し違う速度でパン、人物は単に移動するだけでなく、肩や手もふらふらさせている。その手が机の上のナニカに当たって床に落ちてがっしゃーん、、、みたいな。たぶんモーションベクトルがスゲェ事になってる。ものっすごい地味なテマヒマ。動きの面白さは確かにあるが、それがbitを喰うなんて数字で出なきゃ絶対に気付かなかった自信がある。

　ところで、一時期、Xvidで2048kbps,2passを常用していた頃。

　これは大概のアニメには過大だったらしく、大きくても1500程度に収まるのが普通で、1800ともなればうわなにこれ"見"なきゃって感じだった（※1）。その中で『無人惑星サヴァイヴ』は唯一、毎週2048kbpsみっちりになる不可解な存在だった。これも一見なんてことのないアニメだが、やはりカメラのパンやズーム、ピントを使った演出などを地味に多用してるようだった。『無敵看板娘』のように毎回ハッキリしたアクションがあるわけでは無いだけに、さらに地味感が強い。

　そこでふと気付く。自分が気付かない/地味に感じるのは実写でこうゆうカメラワークを見慣れているからではないか？
　制作側を想像するに、こういう手は、実写の経験なりセルをコマ撮りした時代なり、つまりいわゆる"カメラマン"のノウハウが無いと思いつかないのではないか？
　アニメがエンコしやすいというのは、制作工程のデジタル化で作り手がそのへんのノウハウを思いつかなくなった、という事情もあるのではないか？
　CADの弊害を克服するために、若手エンジニアに製図台で図面を書く練習をさせてる会社ってのがどっかにあったのを思い出した。モニタだけで作業してるとナニカが見えなくなるらしい。アニメ屋でも、ましてエンジニアでもないんでよくわかんないけど。

　そしてこの二つ、作った会社がおんなじくさい。作品歴には『ルパン三世カリオストロの城』、『死の翼アルバトロス』、『名探偵ホームズ』、、、動きの面白さで客を圧倒した、いにしえのど根性モノが並んでいた。むむむ、どれも一度はエンコしてログを拝んでみたいものだ（※2）。

　アニメはエンコしやすいと言います。実際そういう番組が多いのも、それが役立つノウハウなのも事実ですが、自分としてはそれを書く時には常にタメライがあります。ナニカに対して失礼な気がして。

　そんなわけで、自分的にはこの番組、x264移行後最初の難物素材（候補）にしたいと思います。AvgQP(P)が2違ったところで主観的な画質や実用上の問題があるとは思いませんが、ビットレートを削ったり、解像度を上げたり、特に速度目的でモーションベクトル関連オプションを削る場合は要注意な可能性があります。

　※1）QPの下限＝２で揃ってもその数字と言う事。つまり、Xvidでは過剰ビットレートでの2passは実質的に固定QPと変わらず時間の無駄。他にサイズの不揃いが厭でビットレートを落とした。H.264/AVCの下限=0=（量子化プロセスを切るという意味での）ロスレスで、QP値の変動ももっと小刻み。x264ではこのロスレスも可。
　※2）他にディズニーの『シリーシンフォニー』、『ファンタジア』『白雪姫』など。

■アニメそのものの感想

　最初は「そんなにノイズ酷かったっけ？」と思って"見た"んだけど。

　タメが良い。タイミングが巧い。カメラワークが憎い。ノリが良い。たたた楽しい。単に枚数が多いだけじゃない。目がおいしいとゆっている。

　ヒマと容量が許せばApple-intermediateで吐いてジョグシャトルでくるくるして見たい。

　動きで目を楽しませるてんですか。原作にもキャラにも物語にも声優人気にも頼らねぇ芸。
　棒ひとつ振り回すにも、ここは反動ついてるとおもしろいんぢゃないか？と思ってコマ送りすると、そういう絵が一こまきちんと描いてある。
　たぶん一瞬網膜に叩き込まれる事を狙って。

　人が描いた絵が動く。それがアニメだろ？アニメータなら、一挙一動に意味を込める。べきだ。

　たぶん、そーゆーココロイキが真ん中に居る。

　などと思った。

てな理屈ぬきで面白かったです。
頑張って下さい。

[ 2006/09/30 00:00 ] 動画　圧縮日記264 | TB(0) | CM(3)

QuickTimeとその他の違い。

　自分の理解では、QuickTimeはOSの中の「動画やマルチメディアを扱う枠組み」ではなく、「時間軸を取り扱う仕組み」だ。
　Quick"Time"と命名した以上「時間軸を軸足にデータを取り扱う」という発想が芯。でなければ描画関連のQuickDrawと並べる形で、QuickMovieなどとしたハズだ。プログラミングを知らない自分から見るとほとんど思想に近い。たぶんドキュメントの言い回しや部品のネーミング一つとってもそうなってんだと思う。

　 CPUパワーが足りなければ勝手に映像を間引いて（ほとんど放棄してでも）同期を保つ、だけでなく、指定したtimescaleに合わせて式と数値からCGをレンダリングしてみせるなどの未来予想もあったと思う。QuickTime3DもQuickTimeVRも統合時間軸に貼付けるコンテンツの地ならしという志向を持っていたのかも知れない。今から考えれば、だけど。

　んなブッ飛んだ発想が普通に理解できるハズもなく。当時の雑誌では「よーするに動画が扱えるわけだ！」という事になっていた。おいらもそうとしか思えなかったし、今でもユーザーとしちゃそれで充分だと思っている。脳内を動画に限っていると、Video for Windows/Audio Video Interleaveという名前の方が断然明瞭で、飲み込み易い。恐らくはドキュメントの言い回しや理解が必要な概念などもそうなのだろう。

　MPEG-4がコンテナ形式の土台としてQuickTime.movを採用したという事は、ISOの専門家がこのブッ飛んだ思想をある程度受け入れた事を意味する。
　gpac公式に「シーン記述言語のチュートリアル」というのがあるが、なんのことやらわけわかめ。映像・音声・テキスト以外の部分の規格の幅広さを見ても、それがどこでどんなふうに必要になるのか想像もつかない。いっそ「コンピュータでデータを扱う事」ソレ自体のパラダイムシフトと思ったほうが早いんでねぇのか。とか思う。

　などと知ったかぶってても役にも立たないので徐々に話しを戻すと、

『国産ロケットはなぜ墜ちるのか』151p
　理工系とひとくくりにされがちだが、理と工の差は、通常想像されるよりもはるかに大きい。理学は自然を理解する事を目的とする学問で、その基本には「妥協なき真理の追究」という態度がある。それに対して工学は、理解した自然の力を応用する学問であり、基本にあるのは「いかに高いレベルで妥協するか」という精神だ。

　たぶんQuickTimeは理系。徹底的な理想追求。立派だがちとうんちくが長い。
　vfw/AVIは工学系。現世利益最優先。田舎の温泉旅館みたいに建て増し、建て増しで、迷う、、、ぬお、こんなところに階段が！みたいな。

◆◇◆

　てな事をだらだら考えたのはMyCometG3さんとこにこうゆう記事が出たから。

20061004：MyCometG3　概念の違い
QTの世界では、フレーム自体が表示位置と表示時間長の属性を持つのだけれども、libavcodecのAVFrameには表示位置の属性しかない。pts(Presentation Time Stamp)しかないんだ。
／／
だから、頭から順番に再生している場合はいずれも問題ない。けれど後者の場合、フレームの終了時間という概念がないので、頭だしや切り貼りをする際に考え方が曖昧になる。この仕様上、逆転再生が困難なのも容易に理解できる。

　固定フレームレートが前提のAVIモデルから表示時間長という概念は生まれようが無い。時間軸操作のインフラなら、時間にからむ属性は佃煮にするほどあるハズだ。vfw/AVI由来(*1)とQuickTimeは土台というか、世界観が違う。「CPUのキモチ」になる事をインフラの作り手に求めるか、アプリの作り手に求めるか。みたいな？

　libavcodecでフレームの終了時間が必要な場合は前フレームのPTSと当該フレームのPTSから引き算するなどのシカケをアプリの作り手がいちいち用意する事になる。他にもその場しのぎの弥縫策が佃煮にするほどあるはずだ。

　ちなみに、mencoder.cはPTSはおろかDTS（Decoding TimeStamp）すら一切知らない。メーリングリストで誰かが言ってた。
　デコーダバッファに入って来た順に先入れ先出しする。しかできないらしい。再生はfps指定値命。
　MPEG書き出しはvideo stream内の規則性を逆手に取ってPTS/DTSを推算で書き込んでんだとか。

　だから、mencoderで.mp4を吐くには、-x264encoptsからBを完全に排除して、ちょっとスゲェオプションを使う必要がある。（*2）。
　B付きは一旦rawvideo.264で吐いて、mp4boxで固定fps映像を.mp4に突っ込む方法しか見つからないのはPTS/DTSサポートの欠落が理由だ。これもメーリングリストで誰かが言ってた。
　以下は根拠レスの推測になるが、
　rawvideo.264を直吐きするって事は、mencoder.cに、x264.a（*3）の出力に触れさせないという事だと思う。
　すなわち、rawvideo.264の中にはDTSが残っており、PTSはmp4boxがfps指定値から推算、、、してんだろーなー？コレ。まぁ、そうだったらイイナ！
　建て増しだらけの温泉旅館。

　.mp4の直吐きができるx264cliはもう少しマシに見えるが、AviSynthが吐くのはたぶん固定FPSのrawYUVだからやっぱ決めうちでPTS書いてるだけかな。出力fps指定オプションあるし。いずれにせよAviSynthの無いMacでは実用性に乏しく、また妖精現実さんによれば.mp4直吐きは信頼性が低い。
　そもそもfaacもlameもffmpegもコデックとセット配布のcliは、コデックが吐くraw datastreamのテスト用と思った方が良いらしい。CPUのキモチ的には、rawdataのままで実用になり普及もした.mp3と、最低でも映像と音声を一個のコンテナに詰め込んで同期させなきゃいけない動画とは異なる。

　コンテナの規格適合性ではQuickTimeインフラが最善。なにより.movは.mp4の母体なのだから。コデックとビデオフィルタが致命的に弱い。
　良いコデックとビデオフィルタ、すなわち画質ではMEncoderが最善。これはもう断定しちゃうよオイラ。
　winでどうなのか、つまりAviUtilやAviSynthは知りませんが、" 1 フレームイン・1 フレームアウト "ベースのvfw/AVIインフラを経由するワークフローでは、データ配置が著しく自由なH.264/AVCの真価を発揮する事は困難と推測しますです。つまりコデックは豊富だがプロプライエタリのvfwインフラが足をひっぱる。まぁインタレ解除やデノイズの方が重要ですけど。
　MEncoderに移行して優れたフィルタを移植するとか、MPlayerG2（-vfの構造はそのまま）やgpacやMatroskaの開発に参加するとか、してくれる人が増えると嬉しいなっと。天下万エンコ厨の為にw（*4）。

（*1）libavcodecに限らず、linux全般が目指すのはWindowsへのキャッチアップだ。Ubuntuがスッキリ解り易いといってもやっぱMacのほうがラク。
（*2）つまりBaselineprofile＝iPod向けなら直に作れるハズ。PSPが要求するSPS・PPS回りのオプションも最近出来た。この辺は携帯動画変換君=ffmpegユーザーのフィードバックのおかげだと思う。
（*3）どちらもバイナリ内の相当部分。
（*4）あ～でもCから直にmmx呼ばないでねおいらPPCだから。SPE呼んだら天才。

◆◇◆

　目先の役に立たないもんには苛つくが、車輪が発明された後も、何年もコロの方が実用的で信頼性も高く、広く使われていたハズだ。コンピュータ業界の1年は他の10年に相当すると言うのはまだぜんぜん未成熟とゆう事でもある。Win95登場以前にQuickTimeを考えついたおっさんには、どうやってそういうアイデアに至ったのか一度聞いてみたい気もする。

[ 2006/10/05 00:00 ] 他ツール　QuickTime | TB(0) | CM(0)

僕等がいた第13話

　10月上旬のオプション改訂に従って設定変更。

MEncoder dev-SVN-r20125-4.0.1
x264 core:53 svn-584M
素材：『僕等がいた第13話』。アニメ、少女マンガ？。要所要所でパン、ズーム、マルチ（イントレ？）、背景動画などを巧みに使っているが、全体としては動きもディテイルも非常に少なく、極めて圧縮しやすい。

===MENCODER_PASS1===
/usr/local/bin/mencoder /Users/USERNAME/Movies/1005/僕等がいた_13_060930.mpeg -nosound -ovc x264 -x264encopts threads=2:bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=55:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:turbo=1 -passlogfile /Users/USERNAME/Movies/1005/僕等がいた_13_060930.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /dev/null
===MENCODER_PASS2===
/usr/local/bin/mencoder /Users/USERNAME/Movies/1005/僕等がいた_13_060930.mpeg -nosound -ovc x264 -x264encopts threads=2:bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=55:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:me=umh:subq=7:frameref=4:mixed_refs:8x8dct:partitions=p8x8,b8x8,i8x8,i4x4:trellis=2:brdo:bime -passlogfile /Users/USERNAME/Movies/1005/僕等がいた_13_060930.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /Users/USERNAME/Movies/1005/僕等がいた_13_060930.264

■基本方針

　使えそうなオプションは全部使う。書かなくて良いものもデフォルト値で書く。
　1024kbps・2パス。アニメは時間軸fps混合にかかわらず逆テレシネ。さらにpp=l5で一律に塗り潰して空間軸fps混合を潰す。

■各パス共通

　改訂されたもの太字

	オプション名	default	Profile	メモ
	threads=2	1		CPU数に応じて指定。
	bitrate=1024	off		bitrate 指定
B	bframes=3	0	MP	最大Bフレーム数 ※Baselineにする際は0に。
	b_adapt	on		適応的Bフレーム
	weight_b	？		Bフレームの適応重み補間予測。要bframes=1以上。 b_adaptが強力であまり意味が無い。
	b_pyramid	？		要bframes =2以上。Bの参照フレーム化
I	keyint=240	250		IDRフレーム最大間隔
	keyint_min=1	25		IDRフレーム最小間隔 1にするとやたら増える。
	scenecut=55	40		Iフレーム挿入頻度
レ｜ト制御	qp_min=10	10		最小量子化値
	qp_max=51	51		最大量子化値
	qp_step=4	2		連続したフレームの間でのquantizerの変動幅。画質の急激な変化を抑止。 4はMeGUI2.0ヘルプファイルの推奨値
	qcomp=0.6	0.6		画質や bitrate変動幅の調整
	ratetol=4	1.0		平均ビットレートにおける変動幅の許容値。低い値はビットレート変化抑止。ストリーミング対応度向上、複雑な場面への対応力低下。高い値はビットレート変化促進。複雑な場面への対応力向上、ストリーミング信頼性低下。 4はMeGUI2.0ヘルプファイルの推奨範囲の内、最大。
インラインデブロック	deblock	on		デブロックフィルタの可否
インラインデブロック	deblock=0,0	0,0		デブロックフィルタ強度
小技	cqm=jvt	flat	HP	カスタム量子化マトリクス。切る場合はcqm=flatが安全。
	cabac	on	MP	切る場合はnocabacが安全。
	direct_pred=auto	spatial		Bフレーム中のダイレクト・マクロブロックに使われる動き予測のタイプ決定方式
	nofast_pskip	on		Pフレームにおける速い段階でのスキップ検出。速度向上。切るとディテイルの無いエリア、例えば空などにアーティファクトが出る事がある。
	nodct_decimate	on		Pフレーム中の若干のディテイル除去。アニメ以外の素材を高ビットレートで圧縮する場合は効果あるかも。
他	nointerlaced	？		インタレ保持を切っている。
他	noglobal_header	off		PSPなどで必要。
指標	psnr	off		画質指標の表示
指標	ssim	off		新しい画質指標の表示 ※特に表示変更は見当たらなかった。

　※）『小技』の中には2nd専用にしても良いものがありそう。

■1stパスのみ。

	オプション名	default	Profile	メモ
	pass=1			パス指定
	turbo=1			1st用高速化用のプリセット設定。ログを見ると上記共通項目の中にも効かなくなるものがあるようだ。

　※1stは"CPU-hungry"なオプションを切って高速化しても良い。manを読み込んでそういう設定を組むのもアリ。代償として最終的な PSNRが若干下がる。

■ 2ndパスのみ。

	オプション名	default	Profile	メモ
	pass=2			パス指定
※1	me=umh	hex		フルピクセルの動き補償アルゴリズム選択。最大のesaは鬼のように低速。
※1	subq=7	5		subpel精製品質。7で最大。
※2	frameref=4	1		直前よりも前のフレームを参照フレームに使う。その最大距離。最大15。実写では6程度を境に効果急減。
※2	mixed_refs	？		8x8、16x8 motion partitionが、独自に参照フレームを選べるようにする。
サブマクロブロック	8x8dct	？	HP	切る場合はno8x8dctが安全。
サブマクロブロック	partitions=p8x8,b8x8,i8x8,i4x4	同左	HP	オプショナルなマクロブロック・タイプの指定。 MPの場合、no8x8dctと共にi8x8も削除。
※3	trellis=2	1		レート歪み最適化(RDO)の量子化。意味不明。低速、要subq=6以上。
※3	brdo	？		Bフレームのマクロブロックタイプにレート歪み最適化。要subq=6以上。
	bime	？		双方向（予測）マクロブロックで使われる2つのモーションベクトルの精密化。要Bフレーム。

　※１）meとsubqが速度と画質に最も影響が大きい。
　※２）vfw/AVIのバッファ管理原則と不整合の疑いが濃いもの。 framerefはマルチプルレファレンス、複数参照と言うが、自由距離参照とかでも良いかも。
　※３）手許では説明にRDOとあったら脊髄反射でon。Xvidのvhqで味をしめた。RDOは規格に無いが、JMが実装している。

■2ndの結果

x264 [info]: using SAR=44/45
x264 [info]: using cpu capabilities Altivec 
x264 [info]: slice I:384 Avg QP:16.36 size: 21913 PSNR Mean Y:48.56 U:52.30 V:53.52 Avg:49.55 Global:49.19
x264 [info]: slice P:12378 Avg QP:18.03 size: 9563 PSNR Mean Y:46.15 U:50.67 V:52.13 Avg:47.26 Global:46.90
x264 [info]: slice B:24275 Avg QP:19.60 size: 2923 PSNR Mean Y:45.25 U:50.35 V:51.89 Avg:46.43 Global:46.09
x264 [info]: mb I I16..4: 8.1% 75.4% 16.5%
x264 [info]: mb P I16..4: 0.5% 5.9% 0.8% P16..4: 60.2% 19.0% 8.3% 0.0% 0.0% skip: 5.2%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 26.1% 1.7% 3.9% direct: 5.9% skip:62.4%
x264 [info]: 8x8 transform intra:79.2% inter:44.3%
x264 [info]: direct mvs spatial:95.7% temporal:4.3%
x264 [info]: ref P 57.2% 22.4% 11.8% 8.7%
x264 [info]: ref B 71.6% 18.2% 6.1% 4.1%
x264 [info]: SSIM Mean Y:0.9835919
x264 [info]: PSNR Mean Y:45.584 U:50.475 V:51.990 Avg:46.741 Global:46.367 kb/s:1024.09
 
Video stream: 1025.113 kbit/s (128139 B/s) size: 197948402 bytes 1544.793 secs 46298 frames
SEC ; 7119
TIME; 1:58.39

I関連：Iを増やすには keyint_min=1が最も手っ取り早い。
レート制御関連：主観ではPのAvg QPが20切れば十分。地アナキャプチャでそれ以上あっても電波ノイズの再現性が上がるだけな気が。
サブマクロブロック関連：Main Profireで作ると太字部（75.4%）が0%になることから、これがi8x8の比率。 SDでもHPの効果はデカイと思う。
direct_pred関連：spatial とtemporalの比率は実写では半々近くになる。アニメでも作品によっては7:3程度になる。事もある。
b_pyramid関連：参照に使われたB、x16サイズ、x8、x4の順と思われる。x264ではBはBの参照フレームにしかなれない。depth（最大深度？）３。よって bframes=3。

■問題点

　静止画パンで動きに地味な引っかかりがある。素材への忠実さという点ではNTSCでインタレ保持したほうが、時間軸画質は良いようだ。一般的にはスタッフロールで目立つ程度なので、手許では全体的なインタレ縞潰し（空間軸画質）を優先して逆テレシネのpullupとインタレ解除のyadifを使い分けている。
　この素材は要所要所でパン、ズーム、マルチ（※）、背景動画などを、コストカットのためではなく、演出目的で使っているので本編中のパンの引っかかりはやや残念感が漂う。

　※）セルを複数重ねて違う速度で動かしたり、レンズから距離を置いて配置し、ピントを切り替える、など。実写のカメラワークを持ち込む為の手法。鉄骨で大掛かりな撮影台を組む必要があることからイントレとも言う。

[ 2006/10/11 00:00 ] 動画　圧縮日記264 | TB(0) | CM(2)

SSIMとPSNRとは

PSNR：

長所

シーンカットの無いシークエンスを、設定を変えてエンコードした場合、ほとんど必ず、PSNRの高いほうが画質が良い。
グローバルPSNRで0.2dB違えば通常は充分に目で見て解る違いがあるとされる。
したがってPSNRは、エンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化する上ではまずまず役に立つ。

短所

PSNRの値そのものは無意味。PSNRが同じでも、素材同等になるケースもあれば汚いアーティファクトが出る事もある。これは素材の長さとアルゴリズムのタイプに依存する。従って、違いの大きなアルゴリズムを比べる際には、PSNRは使えない。また、PSNRを元にしてシーンカットをまたがるbit配分を行うのは無意味。
大して見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸の均等スケーリングや、各ピクセルに少量のガウシアンノイズを加えた場合など）。その一方、非常に目に留まり易いにも関わらず、PSNRにほとんど影響しないアーティファクトというものもある（例えばブロックノイズ）。

SSIM：

長所

PSNRの問題を相当程度に緩和する。動画/静止画の画質指標としては*ベストではない*が、高速に算出できるものとしてはベスト。
SSIMの絶対値比較は妥当と言える。

Loren Merritt氏の見解を表にしてみた。

SSIM値	qp設定値（※）
0.98 以上	20	オリジナルと区別がつかない。
0.95	30	見るに耐えない。（＊または辛うじて、そこそこ見られる＊）
0.9	40	非常に醜い。
0.8	51	これ以上は圧縮できない
0.7以下	-	素材に大量のノイズを加え、さらにそのノイズを量子化工程で消し去るほどqpを高くしない限り、達成困難。

※おそらく、qpを使った1パスABRと思はれる。

短所

　詳細不詳。
　x264のSSIMは概算。開発者は多くの場合（普通の長さの動画）では、"ほんとうのSSIM"の数パーセント程度の精度になるとしている。
　厳密に計算すると時間が100倍くらいかかるのだとか。

agehaにオリジナル無し
■原文：[x264-devel] Defining video quality

▼Axel Gunter：06/12/1

x264 と JM (10.2) の画質を比較する際に、自分は PSNR を使っていた。
 自分の理解では、JM は実際の動きやテクスチャのディテイルの再現よりは、PSNRの向上を追求したものに思える。
 x264も同じ方向性だろうか？
 また、画質の定義として、他に産業界で一般的な数値指標はないだろうか？というのは、PSNRはミスリードを起こす事があるからだ。なにかヒントか、コメントが欲しい。

While comparing x264 with JM (10.2) I had been using PSNR for comparing the qualities of the two encoders. I understand JM is an encoder designed to achieve better PSNR rather than track true motion, or increase texture detail. I was wondering if x264 was based on a similar theory? 
 Also, what other metrics are usually being used in the industry to define video quality, since PSNR can be misleading at times. Any pointers/comments? 
       
 Thanks 
 Axel

▼Guillaume POIRIER：06/12/1

x264 はエンコードの SSIM を表示できる。これはより正確とされている：
       http://en.wikipedia.org/wiki/SSIM       
       SSIM（From Wikipedia, the free encyclopedia）
 ※部分試訳         Structural SIMilarity (SSIM) index（＊構造的類似性指標＊）は、二つの画像の類似性を計測する方法です。SSIMは全てを参照する測定基準（＊full reference metric＊）です。別の言い方をすると、画質を元の非圧縮、または歪みの無い画像に基づいて計測するということです。
 SSIMは過去の汎用画質指標よりも改善されています。PSNR や MSE などの広く用いられている方法は、人間の視覚認識とは矛盾している事が証明されています。       
 Guillaume 
       -- 
 喧嘩することの無い人々の協調関係というものは、最大の国家連合からタウンミーティングや教区会に至るまで、これまでに存在した事が無い。
 -- トマス・ジェファーソン
 （MPlayer ML におけるフレーミングについてインタビューを受けた際に）
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

x264 can give the SSIM of the encode, which is supposed to be less 
 missleading: http://en.wikipedia.org/wiki/SSIM       
       
 Guillaume 
       -- 
       An association of men who will not quarrel with one another is a thing 
 which has never yet existed, from the greatest confederacy of nations 
 down to a town meeting or a vestry. 
 -- Thomas Jefferson 
 (when interviewed about MPlayer ML flamewars) 
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

▼Alex Izvorski：06/12/1

こんにちは Axel。

Guilliame が書いた通り、x264は SSIM と PSNRを算出できる。
ほとんどの場合、私はSSIMを使う事を奨める。SSIM は非常に良い指標だ。
そしておそらく、PSNRよりも早く、かつ正確なものとしては唯一だ。

単に非常に良い指標では満足できず、天下無双の指標を求めているならば、そしてまた各種指標の比較を知りたいならば、VQEG FR-TV Phase I および Phase II リポートが役立つかも知れない：

http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseI/COM-80E_final_report.pdf
http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseII/downloads/VQEGII_Final_Report.pdf

上記のテストでは、最強の画質指標は NTIA (ANSI T1.801.03-2003, ITU BT.1683)だ。SSIM はほぼこれに対等。面白い事に、おおくの有名な指標、例えば JND (Tektronix/Sarnoff)や、DVQ (Watson/NASA) 、そして PDM(EPFL) などは、どれもY-PSNRだけを使った場合とほぼ同等か、より悪い（！）。

PSNRについて：
シーンカットの無いシークエンスを、同じアルゴリズム（＊この場合ほぼコデックと同義か＊）で、設定を変えてエンコードした場合、視覚的にはPSNRの~~低いものほど~~高いものほど良い。ほとんど必ず。したがってPSNRはエンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化する上ではまぁまぁ役に立つ。

しかしながら、PSNRにはいくつか欠点がある。
１）PSNRの値そのものにはなんの意味も無い。例えば、PSNRが40のエンコード結果とオリジナル素材が二組あった場合、片方が素材同等に見える一方で、もう片方は汚いアーティファクトが出ている、といった事があり得る。これは素材の長さとアルゴリズムのタイプに依存する。これは、大きな違いのあるアルゴリズムを比べる際には、PSNRは使えないという事だ。また、PSNRを元にシーンカットを跨がるbit配分を行うのは無意味という事でもある。
２）本質的には目に見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸を均等にスケーリングしたり、各ピクセルに少量のガウシアンノイズを加えてみて欲しい）。その一方で、PSNRに非常に低い影響しか持たないが、非常に目に留まり易いアーティファクトというものもある（例えばブロッキング）。

SSIMはこれらの問題を、相当程度に緩和する。SSIMは動画/静止画の画質指標としては*ベストではない*が、高速に算出できるものとしてはベストだ。SSIMの絶対値比較は妥当と言える。非常におおまかなガイドとしては、0.7以下は見るに耐えない。（＊または辛うじて、そこそこ見られる＊）。0.8-0.85は多少の目に見える映像の歪みが出るが、大方の人にとってはOK。0.9以上はオリジナルと区別がつかない。

注意して欲しいのは、x264のSSIMは"ほんとうの"SSIMアルゴリズムのあるべき姿とは別の方式で算出されている事だ。windowingも、 luma maskingも、motion maskingも無い。算出しているのは、sample of all possible positionsだけだ。しかしながら、多くの場合、"ほんとうのSSIM"の数パーセントは表している。そして概ね100倍くらいは早く算出できる。ここで"多くの場合"とは、普通の長さ（＊natural footage＊）という意味だ。

可能性としては(＊不詳＊) があり得る。
しかしそうしたケースに遭遇する事は極めて稀だろう。もし本当のSSIMが欲しければ、私にそういうコードを書くように五月蝿く騒ぎ立ててくれ。;)

Hello Axel,

As Guilliame wrote, x264 can calculate SSIM as well as PSNR. I
recommend using that for most work. SSIM is a very good metric, and
probably the only one that is both fast and better than PSNR.

If you are looking for the absolute best metric as opposed to a merely
very good metric, and also for how to compare metrics, you may wish to
read the VQEG FR-TV Phase I and Phase II reports:

http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseI/COM-80E_final_report.pdf
http://www.its.bldrdoc.gov/vqeg/projects/frtv_phaseII/downloads/VQEGII_Final_Report.pdf

In those tests, the best metric is NTIA (ANSI T1.801.03-2003, ITU
BT.1683). SSIM also does quite well. Interestingly, many well-known
metrics such as JND (Tektronix/Sarnoff), DVQ (Watson/NASA) and PDM
(EPFL) are either about the same, or worse than, using just Y-PSNR (!).

About PSNR: if you encode the same continuous (no scenecuts) sequence
with the same algorithm with several different settings, the version
with the lower PSNR is almost always visually better. Thus PSNR does a
reasonably good job of allowing you to optimise codec parameters that
you can vary during an encode (like RDO or rate control).

However, PSNR fails on several counts:
1) The absolute value of PSNR means nothing. In other words, looking at
two pairs of original/encoded images both with PSNR of 40 (for example),
one pair may look identical and the other may have gross artifacts. It
all depends on the source footage and on the type of algorithm. This
means that PSNR is useless for comparing significantly different
algorithms. It also means that using PSNR to allocate bits accross
scenecuts will result in bad decisions.
2) Some artifacts which are essentially invisible have a huge PSNR
impact (try scaling Y uniformly or adding a small amount of gaussian
noise to each pixel for example). Other things which are extremely
visible have an unreasonably low PSNR impact (like blocking).

SSIM fixes these problems to a significant degree. It is not *the best*
video/image quality metric, but it is the best that can be computed
quickly. SSIM absolute values can be reasonably compared: as a very
rough guide, below 0.7 is barely watchable, 0.8-0.85 has some visible
distortion but ok for most people, and 0.9 and higher are
indistinguishable from the original.

Please note that SSIM in x264 is not calculated the way that the "real"
SSIM algorithm (and papers) say it should be. There is no windowing, no
luma masking, no motion masking, and only a sample of all possible
positions are calculated. However, it is within few percent of the
"real" SSIM in most cases, while being about a hundred times faster to
calculate. "Most cases" here pretty much means any natural footage; it
may be possible to construct synthetic footage so as to defeat the
approximations used, but you are extremely unlikely to ever encounter
such. If you want real SSIM, bug me to release my code for that ;)

Regards,
--Alex

▼Loren Merritt：06/12/1

       PSNRについて：
 シーンカットの無いシークエンスを、同じアルゴリズム（＊この場合ほぼコデックと同義か＊）で、設定を変えてエンコードした場合、視覚的にはPSNRの低 いものほど良い。ほとんど必ず。したがってPSNRは            ^^^^^ 高い程、
       PSNRはエンコードの過程で変化するコデックのパラメータ（RDOやレートコントロール）を最適化す る上では まぁまぁ役に立つ。
         
 しかしながら、PSNRにはいくつか欠点がある。
 １）PSNRの値そのものにはなんの意味も無い。例えば、PSNRが40のエンコード結果とオリジナル素材が二組あった場合、片方が素材同等に見える一方 で、もう片方は汚いアーティファクトが出ている、といった事があり得る。これは素材の長さとアルゴリズムのタイプに依存する。これは、大きな違いのあるア ルゴリズムを比べる際には、PSNRは使えないという事だ。また、PSNRを元にシーンカットを跨がるbit配分を行うのは無意味という事でもある。
 ２） 本質的には目に見える事の無いアーティファクトの中に、PSNRに大きく影響するものがある（例えば、Y軸を均等にスケーリングしたり、各ピクセルに少量 のガウシアンノイズを加えてみて欲しい）。その一方で、PSNRに非常に低い影響しか持たないが、非常に目に留まり易いアーティファクトというものもある （例えばブロッキング）。
         
 SSIMはこれらの問題を、相当程度に緩和する。SSIMは動画/静止画の画質指標としては*ベストではない*が、 高 速に算出できるものとしてはベストだ。SSIMの絶対値比較は妥当と言える。非常におおまかなガイドとしては、0.7以下は見るに耐えない。（＊または辛 うじて、そこそこ見られる＊）。0.8-0.85は多少の目に見える映像の歪みが出るが、大方の人にとってはOK。0.9以上はオリジナルと区別がつかな い。 　本当に？自分の意見では、
 SSIM=0.98+ (qp=20) はオリジナルと区別がつかない。
 SSIM=0.95 (qp=30) は見るに耐えない。（＊または辛うじて、そこそこ見られる＊）
 SSIM=0.9 (qp=40) は非常に醜い。
 そしてこれ以上は圧縮できないレベル (qp=51) ですら SSIM=0.8となる。
 手許では、素材に大量のノイズを付け加え、そのノイズを量子化工程で消し去るほどqpを高くしない限り、SSIMが0.7 以下となる映像は生成出来ていない。
       
 PSNRでもSSIMでも、指標の絶対値は、圧縮後のストリームにどれだけのqualityが残っているかを示すというよりは、素材にあるノイズの量を示 すものだ。
       
 しかしながらおそらく、同じノイズを持っていると想定される場合、映画の中の異なった場面を比較する上ではSSIMの方が上だろう。
       
 --Loren Merritt 

On Thu, 30 Nov 2006, Alex Izvorski wrote: 
       About PSNR: if you encode the same continuous (no scenecuts) sequence 
 with the same algorithm with several different settings, the version 
 with the lower PSNR is almost always visually better.  Thus PSNR does a 
                   ^^^^^ higher 
       reasonably good job of allowing you to optimise codec parameters that 
 you can vary during an encode (like RDO or rate control). 
         
 However, PSNR fails on several counts: 
 1) The absolute value of PSNR means nothing.  In other words, looking at 
 two pairs of original/encoded images both with PSNR of 40 (for example), 
 one pair may look identical and the other may have gross artifacts.  It 
 all depends on the source footage and on the type of algorithm.  This 
 means that PSNR is useless for comparing significantly different 
 algorithms.  It also means that using PSNR to allocate bits accross 
 scenecuts will result in bad decisions. 
 2) Some artifacts which are essentially invisible have a huge PSNR 
 impact (try scaling Y uniformly or adding a small amount of gaussian 
 noise to each pixel for example).  Other things which are extremely 
 visible have an unreasonably low PSNR impact (like blocking). 
         
 SSIM fixes these problems to a significant degree.  It is not *the best* 
 video/image quality metric, but it is the best that can be computed 
 quickly.  SSIM absolute values can be reasonably compared: as a very 
 rough guide, below 0.7 is barely watchable, 0.8-0.85 has some visible 
 distortion but ok for most people, and 0.9 and higher are 
 indistinguishable from the original. 
              
 Really? imo, SSIM=0.98+ (qp=20) is indistinguishable from the original, SSIM=0.95 (qp=30) is barely watchable, SSIM=0.9 (qp=40) is really ugly, and there could be nothing left of the content (qp=51) and still produce SSIM=0.8. I failed to generate any videos with SSIM<0.7 except by adding tons of noise to the source and then setting qp high enough that all the noise is quantized away. 
 With both PSNR and SSIM, the absolute value of the metric is more a measure of how much noise was in the source than it is of how much quality is left in the compressed stream. Though perhaps SSIM does better at comparing difference scenes within one movie, when they can be assumed to have the same noise. 
       
 --Loren Merritt

▼jtwen：06/12/1

x264 のモード決定や動き予測の過程でSSIMを使う方法はある？
       

Is there a way of using SSIM in the mode decision and ME process of x264?
       
 Thanks,
 Gene

▼Guillaume POIRIER：06/12/1

x264 の土台部分には無い。しかし、
       http://akuvian.org/src/x264/x264_ssim_map.00.diff
 このパッチの名前からすると、smthがなんかしてるんぢゃないかと思う。
       
 Guillaume 
       -- 
 喧嘩することの無い人々の協調関係というものは、最大の国家連合からタウンミーティングや教区会に至るまで、これまでに存在した事が無い。
 -- トマス・ジェファーソン
 （MPlayer ML におけるフレーミングについてインタビューを受けた際に）
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html
       

Not natively with vanilla x264, but the name of this patch 
       http://akuvian.org/src/x264/x264_ssim_map.00.diff makes me think that 
 smth is in the works. 
       
 Guillaume 
       -- 
       An association of men who will not quarrel with one another is a thing 
 which has never yet existed, from the greatest confederacy of nations 
 down to a town meeting or a vestry. 
 -- Thomas Jefferson 
 (when interviewed about MPlayer ML flamewars) 
       http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html

[ 2007/01/19 00:00 ] 動画　動画全般 | TB(0) | CM(0)

MeGUIガイド_x264の設定

2007/11/01追記：x264cli svn-680に準拠した本記事のアップデートがこちらにあります。

原文：Video configurationdialog/X264 Configuration

大きい脂肪質の警告。

原文、『MEWIKI』は整備途上のMeGUIドキュメントです。
原文の解説は初心者むけに非常に簡便です。
試訳した本人はマカーです。
MEncoder, x264cliとも、対応オプションは推測です。
x264cli/MeGUIな方はタグ：x264(r600)コマンド対応も参照願います。

MeGUI概要

　MeGUI（MEncoder GUI）はWindows上で動画エンコードに関わる多数のフリーウェアを統合的に扱う為のGUIフロントエンド。また動画エンコードに役立つ独自の機能も搭載している。インストーラは x264.nlにて配布されており、インストール後、アップデータを起動して動作に必要なファイルを取得する。
　x264cli、MEncoder、mp4boxの他に、音声や字幕などに関連するコマンドラインツールを取得すると思われる。

　事前にインストールしておくべきものは以下。

Microsoft .NET framework 2.0: Windows updateまたは Microsoft websiteから取得。
Avisynth: スクリプトを使って動画編集（インタレ解除やデノイズ、リサイズなど）を行うもの。取得先は avisynth.org。MeGUIのアップデータはavisynth用のプラグインも取得するので、特にMeGUIを動作させるだけなら別途プラグインをダウンロードする必要は無い。

x264の設定項目

Page 1 - General options

MeGUI	x264cli	MEncoder	常用値（MEncoder）
Deblocking: デコード中のインループ・デブロッキング・フィルタを使用。指定範囲は二つとも -6 から 6の範囲。Deblocking strength はデブロック強度、 Deblocking Threshold はデブロックをかける映像の量を指定する。	--no-deblock -f, --deblock <alpha:beta>	(no)deblock deblock=<-6-6>,<-6-6>	deblock(使用) 0,0
Enable PSNR calculation: このボックスをチェックすると、x264 はログに PSNR情報をジョブの終了後に書き出す。若干遅くなる。	--no-psnr	(no)psnr	psnr(使用)
Number of threads: マルチコア・システムを持っている場合に、この値を増やしてそのメリットを活かす。複数のフレームを同時に処理できる。マルチスレッド化に伴う画質劣化は取るに足りない。推奨値は 0。これで x264 はCPUのコア数を検知して最適なスレッド数を使う。このオプションを使うには、MeGUI settingsの Automatically set number of threads をdisableにすること。	--threads <integer>	threads=<1-16>	1st,2 2nd,16 参考
fourCC: AVI などのコンテナがコデック判定に使う4CCの指定。	対応なし	対応なし	非使用
AVC profiles: この設定は、AVCの特定プロファイルに沿った設定をする際の助けとなる。選択されたプロファイルを超えるオプションが指定できなくなる。	対応なし	対応なし	参考
AVC Level: 特定のAVCレベルに沿ったエンコードをしたい場合に使う。選択されたレベルでは使えないオプションを指定出来なくするようにはしないので、ツールメニューの "Validate AVC level" でチェックする事。	--level <string>	level_idc=<10-51>	参考

Page 2 - Zones and custom commands

	MeGUI	x264cli	MEncoder	常用値（MEncoder）
	Zones: Zoneの使い方はこのドキュメントの目的を超えるが、ここでzoneの定義と適用する Quantizer または重み付けを指定する。	--zones	zones	非使用
	Custom Commandline Options: x264(cli)の追加コマンドを使いたい場合はここに入力する。x264(cli)に新しい機能が追加されたが、MeGUI のアップデートがまだの際などに使う。

Page 3 - Rate control, motion estimation and GOP

MeGUI	x264cli	MEncoder	常用値（MEncoder）
VBV Buffer Size: VBV Bufferの最大サイズ	--vbv-bufsize <integer>	vbv_bufsize=<value> (ABR or two pass)	未指定(default)
VBV Maximum Bitrate: Video Buffer Verifierの最大ローカルビットレート	--vbv-maxrate <integer>	vbv_maxrate=<value> (ABR or two pass)	未指定(default)
VBV Initial Size: VBV bufferのイニシャル占有率。 1.0 = full, 0.0 = empty。	--vbv-init <float>	vbv_init=<0.0-1.0> (ABR or two pass)	未指定(default)
Bitrate Variance: ビットレートの変動範囲。 1.0 = pure VBR, 0.0 = pure CBR	--ratetol <float>	ratetol=<0.1-100.0> (ABR or two pass)	4。番組ごとに地味にサイズが変わる。
Quantizer Compression: quantizerの変動範囲。 1.0 = pure CQ, 0.0 = maximum change	--qcomp <float>か？	qcomp=<0-1> か？ (ABR or two pass)	未指定(default)
Temp. Blur of est. Frame complexity: curve compression（＊不詳＊）の前にquantizer curveに適用する時間軸ブラーのレベル。時間軸ブラーは量子化程度の一貫性をもたらす。この値を増やすと、映像は真のCQに近づく。（＊適用量子化値の急激な変動を多少滑らかにするものか＊）	--cplxblur <float>	cplx_blur=<0-999> (two pass only)	未指定(default)
Temp. Blur of Quant after CC: curve compression（＊不詳＊）の後でquantizer curveに適用する時間軸ブラーのレベル。この値を増やすと、映像はCQに近づく。	--qblur <float>	qblur=<0-99> (two pass only)	未指定(default)
Chroma ME: 動き予測の際に、彩度情報も動きの検出に使う	--no-chroma-me	(no)chroma_me	chroma_me(使用) 要、subq>=5
ME Range: 動き予測機構が使う最大捜索範囲（マクロブロックの中で）	--merange <integer>	me_range=<4-64>	1st,16 2nd,32 実用範囲16-32程度
Scene Change Sensitivity: シーンチェンジと看做すフレーム間の変更をパーセンテージで指定。範囲0-100。-1はシーンチェンジ検出なし。	--scenecut <integer>	scenecut=<-1-100>	実写40(default) アニメ65
ME Algorithm: 動き予測に使うサーチアルゴリズムの選択。Exhaustiveはピクセル単位となり、凄まじく遅い。	--me <string>	me=<name>	1st,(turbo) 2nd,umh
Subpixel refinement: サブピクセル予測に使うアルゴリズムとパーティション決定に使う方式の選択。RDO (Rate Distortion Optimisation) を選ぶとBフレームにRDOを使う。	-m, --subme <integer>	subq=<1-7>	1st,(turbo) 2nd,7
Keyframe Interval: I-frames間の最大間隔	I, --keyint <integer>	keyint=<value>	240または300
Min GOP size: I-frames 間の最小間隔	-i, --min-keyint <integer>	keyint_min=<1-keyint/2>	実写,24または30 アニメ1
Noise reduction: プリプロセス・ノイズリダクション。0 = disabled。	--nr <integer>	nr=<0-100000>	非使用

Page 4 - Advanced settings

MeGUI	x264cli	MEncoder	常用値（MEncoder）
Quantizers
Minimum Quantizer: x264が使う最大量子化値	--qpmin <integer>	qp_min=<1-51> (ABR or two pass)	10
Maximum Quantizer: x264が使う最小量子化値	--qpmax <integer>	qp_max=<1-51> (ABR or two pass)	51
Maximum Quantizer Delta: 連続フレーム間における量子化値の最大変動幅	--qpstep <integer>	qp_step=<1-50> (ABR or two pass)	実写4 アニメ8
Credits Quantizer: For use if you set the credit starting point in the preview window.	不詳	不詳	不詳
Factor Between I and P frame Quants: IフレームとPフレームの量子化値換算係数。Iに適用された平均量子化値にここの値を掛けたものがPに適用される。	--ipratio <float>	ip_factor=<value>	未指定(default)
Factor between P and B frame Quants: P フレームとBフレームの量子化値換算係数。Pに適用された平均量子化値にここの値を掛けたものがBに適用される。	--pbratio <float>	pb_factor=<value>	未指定(default)
Chroma QP Offset: 輝度に適用する量子化値と彩度に適用する量子化値のオフセット。	--chroma-qp-offset <integer>	chroma_qp_offset=<-12-12>	未指定(default)
Quant Options
Trellis: Trellis RDO の適用。最終マクロブロックのみか、常時かを選択。要CABAC	-t, --trellis <integer>	trellis=<0-2>	2 要CABAC
Number of Reference Frames: 複数参照フレームの最大数。	-r, --ref <integer>	frameref=<1-16>	1st,(turbo) 2nd,4
Mixed: マクロブロック・パーティション単位で参照フレームを個別に選べるようにする。	--mixed-refs	(no)mixed_refs	mixed_refs (使用)
CABAC: 圧縮効率の高い encoding stream syntaxを使う。	--no-cabac	(no)cabac	cabac(使用)
No DCT Decimation:	--no-dct-decimate	(no)dct_decimate	nodct_decimate (非使用)
No Fast P-Skip: スキップ検出の非使用。画質向上	--no-fast-pskip	(no)fast_pskip	nofast_pskip (非使用)

Quantization matrix: 使用するカスタム量子化マトリクスを指定。You must specify the custom matrix. （＊mustの意味不明＊）	--cqm <string> --cqmfile <string>	cqm=<flat\|jvt\|<filename>>	JVT
Macroblock Options: 各マクロブロックパーティションの使用可否	-A, --partitions <string>	partitions=<list>	1st,(turbo) 2nd,all
B-Frames:
Number of B-Frames: B-Frames (B-VOPs)の最大連続数	-b, --bframes <integer>	bframes=<0-16>	3
Adaptive B-Frames: B-Frames の連続枚数を映像内容に応じて自動調節。	--no-b-adapt	(no)b_adapt	b_adapt (使用)
B-Pyramid: B-Frames も参照フレームに使う	--b-pyramid	(no)b_pyramid	b_pyramid (使用)
RDO for B-Frames: B-Frames にRDOアルゴリズムを使う	--b-rdo	(no)brdo	brdo(使用) 要subq=6以上
Weighted Bi-Prediction: B-frames を参照フレームに使うかどうかの精度が高まる	-w, --weightb	(no)weight_b	weight_b (使用)
Bidirection ME: 動き予測の精度最適化に前後両方向の時間軸を使う。	--bime	bime	bime (使用)
B-Frame Mode: B-Framesのモーションベクトル予測方式。Autoでフレーム毎に最適な方式を選ぶ。	--direct <string>	direct_pred=<name>	auto
B-Frame bias: B-Framesの挿入傾向を調整。高い程Bを使う傾向が増える。低い程減る。	--b-bias <integer>	b_bias=<-100-100>	未指定(default)

[ 2007/01/21 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

x264とは（MEncoder ドキュメント）

原文：http://www.mplayerhq.hu/DOCS/HTML/en/video-codecs.html#codec-x264）

7.1.3. x264

7.1.3.1. x264とは

　x264はH.264 映像ストリームを作成する為のライブラリです。100%完成してはいませんが、少なくともH.264の機能のうち品質に影響する機能はほとんど、なんらかの形でサポートしています。H.264規格には、先進的ではあっても、本質的に映像の品質とは全く無関係な機能が数多く定義されています。そうしたものの大半はまだx264には実装されていません。

エンコーダの機能

CAVLC/CABAC　→　(no)cabac
複数参照フレーム　→　frameref
Intra: フレーム内部では全てのマクロブロックタイプを利用可能(16x16、8x8、4x4、並びに全ての予測方式)。　→　partitions, (no)8x8dct
Inter P: Pフレームでは全てのパーティションが使える(最大 16x16 から最小 4x4まで)　→　partitions
Inter B: Bフレームでは16x16～8x8のマクロブロックが使える。スキップやダイレクトを含む。　→　partitions
レートコントロール:固定量子化（qp）、固定ビットレート、シングルパス・複数パスでのABR（平均ビットレート(crf, bitrate, pass)）、オプションでVBV( vbv_maxrate, vbv_bufsize, vbv_init)
シーンカット検出　→　scenecut
適応的Bフレーム配置　→　 (no)b_adapt
B フレームの参照フレーム化/任意のフレーム並べ替え　→　(no)b_pyramid, / 不詳
8x8 と 4x4サイズの適応空間軸変換　→　partitions
ロスレス・モード　→　qp=0
カスタム量子化マトリクス　→　cqm
スライス単位の平行エンコード　→　threads
インターレース保持　→　(no)interlaced

※補足

x264：アプリケーションが呼び出すライブラリ。x264.a（静的ライブラリ）など。複合化（デコード）能力を持たず、符号化（エンコード/コーディング）能力のみなので、コデックと言わすにコーダーと呼ぶ事もある。以下のアプリケーションはx264のAPIを呼び出す。
x264cli：x264専用のテスト用コマンドライン・アプリケーション。単にx264と言う事も多い。
ffmpeg：libavcodecのテスト用コマンドライン・アプリケーション。x264を呼び出せる。 H.264のデコーダはlibavcodecシリーズの中にある。
MEncoder：統合動画エンコード用コマンドライン・アプリケーション。x264, libavcodecを呼び出せる。
ffmpegX/MeGUI：統合動画エンコード用コマンドライン・アプリケーションのGUIラッパー。内部的にx264cliやMEncoderを呼び出して使う。

7.1.3.2. H.264とは

　H.264はITU と MPEGが共同で開発した新しいデジタルビデオコデックの名称です。正式名称は、～大変ややこしいのですが～、"ISO/IEC 14496-10" または "MPEG-4 Part 10"です。より一般的には"MPEG-4 AVC" とか、単に"AVC"とも呼ばれます。

　ま、なんと呼ぼうとH.264 は試す価値アリです。というのは、MPEG-4 ASPの品質を、5%～30%低いビットレートで実現できるからです。実際の結果は素材映像の内容とエンコーダの性能によります。しかしH.264はメリットだけではありません。: H.264のデコードは非常に高速なCPUと大量のメモリを要求するようです。実例を挙げると、1733 MHz Athlonで、DVD解像度の1500kbps H.264 ビデオの再生はCPUの約35% を使います。これに対し、DVD-解像度の1500kbps MPEG-4 ASP ビデオはCPUの10%です。これは、大半のユーザーにとってHD解像度の再生はほとんど問題外だという事です。また同時に、そこそこのDVD ripですら、2.0 GHz程度以下のプロセッサではぎくしゃくし得ると言う事です。

　少なくとも x264では、エンコードに必要な性能はMPEG-4 ASPと比べてそこまで酷くありません。例えば、1733 MHz Athlonでは一般的な DVD エンコードは 5-15fps程度で走ります。

　この文書ではH.264の詳細は説明しませんが、おおまかな概略はこちらのpdfにあります：The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions（pdf直リン。当ブログ内で一部試訳中、Doom9 -AVC情報の試訳も参照）。

7.1.3.3. H.264 videoをMPlayerで再生するには?

　MPlayer は libavcodecのH.264デコーダを使います。2004年7月以降、libavcodec は少なくとも最小限の H.264 デコードはできるようになっていて、それ以後も、サポートする機能と、CPU利用効率の両面で大きく進歩しています。常に最近のSVN checkoutを使うよう心がけて下さい。

　libavcodecの H.264デコード機能が最近進化したかどうかを手っ取り早く確かめるには、FFmpeg Subversion repository's web interface. をまめに見ておくと良いでしょう。

7.1.3.4. MEncoderとx264でvideoをエンコードするには?

　subversion クライアント（＊SVN＊）をインストールしてあれば、以下のコマンドで最新の x264 ソースコードがダウンロードできます。:

 svn co svn://svn.videolan.org/x264/trunk x264

　x264 のAPIに変更があれば、MPlayerのソースコードも変更されます。ですからMPlayerも常にSVN版を使うのが良いでしょう。おそらくこの状況は x264が「リリース」されたら変わると思います。それまでの間、x264は極めて「unstable」と考えるべきでしょう。というのは、プログラミング・インタフェイスが変更の対象になっているからです（＊参考記事：MEncoderの-x264encopts、大規模改訂＊）。

　x264のビルドとインストールはスタンダードな方法で出来ます。:

 ./configure && make && sudo make install

　これで libx264.a が /usr/local/lib に、そして x264.h が /usr/local/includeにインストールされます。
　（＊マルチスレッド・エンコードをするには./configure --enable-pthread。事前に./configure --helpでオプションを確認する事＊）
　x264 のライブラリとヘッダがスタンダードな場所にあれば、x264 サポート付きMPlayerのビルドは簡単です。通常通りに、

./configure && make && sudo make install

　これでMEncoderのconfigure スクリプトがx264を自動検出するハズです。

[ 2007/02/18 00:00 ] ごみ箱　MEncoder-Doc | TB(0) | CM(0)

x264-rev620～645

　07年03月中旬からx264の動きが激しい。
　動向はSylphide氏のLunatiliaに詳しいが、ここでは620以降の主なものとPPC Macに関係しそうな変更を拾ってみた。

PPC Mac関連

高速化

rev	date	投稿者	概要	メモ
620	01/21	pengvado	tweak block_residual_write_cavlc. up to 1% faster lossless, no difference at normal bitrates. trunk/encoder/cavlc.c (modified) (6 diffs)	最大1%高速化。一般的なbitrateでは差はない。＊cavlcだしな。
621	01/25	gpoirier	Fix build issues on Linux. Only gcc-4.x is supported, as on OSX. Cleans up a few inconsistencies in the code too. trunk/common/ppc/dct.c (modified) (4 diffs) trunk/common/ppc/quant.c (modified) (6 diffs) trunk/common/ppc/quant.h (modified) (2 diffs)	Linux/OS Xのビルド上の問題を改善。 gcc-4.xしかサポートしない。
623	02/22	pengvado	ooops, scenecut detection failed to activate when using threads and not using B-frames trunk/encoder/encoder.c (modified) (3 diffs) trunk/encoder/slicetype.c (modified) (3 diffs)	ありゃ、 threadを使うとシーンカット検出にしくじってた。Bも使えなくなってた。
624	02/28	aizvorski	add ability to generate doxygen documentation; make dox trunk/Doxyfile (added) trunk/Makefile (modified) (2 diffs)	doxygenドキュメントを生成できるようにした。＊少しアプリケーションとしての体裁が整った？
627	03/03	gpoirier	compile fix for GCC-3.3 on OSX, based on a patch by Patrice Bensoussan % patrice P bensoussan A free P fr% Note: regression test still do not pass with GCC-3.3, but they never did as far as I can remember. trunk/common/ppc/dct.c (modified) (3 diffs) trunk/common/ppc/ppccommon.h (modified) (2 diffs)	OSXのGCC -3.3でのビルド上の問題を改善。＊regression testってなんだろうな。文法エラーかなんかか。
629	03/14	sam	common/cpu.c: runtime AltiVec autodetection on Linux. configure, Makefile: do not build the whole project with -maltivec because it generates AltiVec code in weird places.	AltiVec最適化関連？？？
630	03/14	sam	Use -maltivec when building dependencies, or <altivec.h> cannot be used. Do not declare vectors in non-AltiVec files.	AltiVec最適化関連？？？
632	03/14	sam	check x264_cpu_detect() before calling AltiVec functions.	AltiVec最適化関連？？？
633	03/14	sam	Made -DNEED_ALTIVEC unnecessary, thanks to Guillaume Poirier.	AltiVec最適化関連？？？
637	04/02	xtophe	Compile fix trunk/common/ppc/mc.c (modified) (1 diff)	PPC の動き補償関連のビルド修正
638	04/03	pengvado	in hpel search, merge two 16x16 mc calls into one 16x17. 15% faster hpel, .3% overall. trunk/common/mc.h (modified) (1 diff) trunk/common/ppc/mc.c (modified) (1 diff) trunk/encoder/me.c (modified) (2 diffs)	1/2ピクセル精度動き補償を15% 高速化、全体としては3%。＊確かハーフペル精度ってsubq=3でしか使ってなかったような。
641	04/04	pengvado	when encoding with a cqm, probe_skip now also uses the cqm, instead of the flat matrix trunk/encoder/macroblock.c (modified) (4 diffs)	cqm 使用時にprobe_skipもcqmを使うようにした。これまではflatだった。＊フレーム単位でぱたぱたと動く闇階調ブロックノイズに効果があるかも。
642	04/04	pengvado	2x faster quant. 2% overall. side effects: not bit-identical to the previous algorithm. while the new algorithm covers a wider range of cqms than the previous one did, I couldn't find a good way to fallback to a general version for the extreme cqms. so now it refuses to encode extreme cqms instead of just being slower. lays a framework for custom deadzone matrices, though I didn't add an api. trunk/common/quant.c (modified) (2 diffs) trunk/common/quant.h (modified) (1 diff) trunk/common/set.c (modified) (7 diffs) trunk/common/set.h (modified) (1 diff) trunk/encoder/encoder.c (modified) (3 diffs) trunk/encoder/macroblock.c (modified) (15 diffs) trunk/encoder/rdo.c (modified) (5 diffs) trunk/tools/checkasm.c (modified) (5 diffs)	量子化を2倍に高速化。全体としては2%。過去のアルゴリズムにくらべるとbitレベルで等価では無いが、より幅広いcqmをカバー。ぶっとんだcqmをどう扱うのが良いか解らなかったので、そういうものは低速化する代わりに拒絶するようにした。 APIはつけてないが、カスタムデッドゾーンマトリクスのフレームワークを内蔵している。＊cqmをお使いの方はご注意を。
645	04/05	pengvado	x264 H.264/AVC encoder Rev.645参照。 x86 上でのビルド絡みと推測。