ageha was here

　世の中にはhuffyuv.aviという動画形式がある。らしい。Linux/Winではわりとポピュラーらしい。
　名前からするとたぶん単純にYUV信号にハフマン符号化を積んだものだと思う。映像情報を弄らずに符号記述方式を短く言い換えるみたいな。
　であれば、CAVLC-yuvとかCABAC-yuvとかもあってもよさげだがまだなさげ。QTコンポーネントもあることはあるが、結構Motion JPEGでもQT系とMEncoderで融通効かなかったりするらしいので深入りしてない。

　x264ではH.264/AVCロスレスが作れる。AVC1Decoder大明神のおかげでQT系・Linux系で融通の効く中間生成物として使えるの ではないかと思った。

　まず、Mac OSXで作れる中間生成物をざっと作って見た。ロスレスを標榜していてもほんとにそうとは限らないので比較の為。
　素材はこないだBS2で放送した『劇場版あしたのジョー２』の冒頭部、でかい夕陽のクリップ。6.85sec, 5.9MBのMPEG-2 PS。
　不慣れなため個々の設定が良く解らないが、QTPproでできるだけ高画質、インタレ保持に、なりそうなように心がけました。

	MB	分類	画質スライダ	備考
.mpeg	5.9	DCT	-	素材
Apple intermediate.mov	16.0	DCT	中	実質的にIのみのMPEG-2らしい。 QTPProではなぜか画質スライダが出ないが、他ソフトでは圧縮率を変えられる らしく「圧縮率（中）」みたような表示が出る。 HDVカメラというもので撮影したHD映像編集ソフト（iMovieHDなど）が使う。 左記の通り非常にコンパクトになるが劣化もこの中ではもっとも激しかった。
x264qp0.mp4	40.5	DCT	後述	H.264ロスレス。 x264, interlaced, Iのみ, 量子化抜き。 BがないのでMEncoderでmp4吐き出し。 冒頭の白紙フレームも無いのでQTPProでアスペクト指定後 「そのまま」mp4書き出し。
MJPEG A.mov	47.1	DCT	最高	AとBがあるが良く解らないのでA。 詳細オプションはどちらも同じでインタレ保持絡みの模様。
Pixlet.mov	33.6	DWT	最高	これとJPEG2000とは離散ウェーブレット変換（DWT）という理屈を使う。 マクロブロックを使わないのでブロックノイズが出ないかわり、 同心円上の圧縮ノイズが出るという。圧縮率（中）で出ました。 書き出し速度も再生も他と遜色がない。 PixerとAppleの共同開発だそうで、なにやらスゴそうなものがオマケでついている わけだが、そのわりに使ってますと言う情報が無い。でもかなり優秀。
J2k.mov	63.1	DWT	最高	QT標準搭載のJPEG2000が.movでも使えた。 静止画専用ぢゃなかったのか。 NHK技研もいろいろ研究中っぽい。 書き出しはこのなかでは抜群に遅く、G5, 2Ghzx2では再生もカクカク。

　どれも若干のデノイズっぽい効果を感じた。素材によってはディテイルの潰れであるかも知れない。
　感覚的な画質は：

　J2k　＞　Pixlet　＞＞　x264qp0　＞　MJPEG A　＞＞＞　Apple intermediateといったところ。

　ただし、Apple intermediateを除けば違いは非常に地味（Apple intermediateと他の違いもなかなか地味だけども）。
　あとサイズと画質劣化度と速度を考えると、Pixletはどえりゃあ優秀だがやと思った。これに時間軸圧縮のっけたら一気にクイックタイマーに転向しま すよあたしゃ。

　画質の傾向としては、J2K/MJPEG Aと、Pixlet/x264qp0にグループわけできると思う。
　Pixlet/x264qp0では夕陽外周のグラデーション部分にあった電波ノイズが消え、なめらかになる効果があるが、J2K/MJPEG Aではそうした部分に乗っている電波ノイズもわりあい忠実。
　反面、夕陽の中心部、高輝度部分では、J2K/MJPEG Aともに素材に無い荒れかたをしており、夕陽の輝度が地味に沈む。Pixlet/x264qp0はつるんとデノイズがかかり、素材よりも「真っ赤な夕陽 感」がタカマル。

　-x264encoptsは以下：

-x264encopts \
qp=0:\
bframes=0:\
keyint=0:keyint_min=0:scenecut=100:\
nodeblock:\
cabac:\
cqm=jvt:8x8dct:\
me=umh:me_range=32:subq=7:frameref=1:\
partitions=all:\
trellis=2:\
nofast_pskip:\
nodct_decimate:\
interlaced:\
noglobal_header:\
psnr:ssim:\
threads=1 \
-ofps 30000/1001 \
-of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames \
///
Video stream: 49618.078 kbit/s  (6202259 B/s)  size: 42424490 bytes  6.840 secs  205 frames
x264 [info]: slice I:203   Avg QP: 0.00  size:208908
x264 [info]: mb I  I16..4:  2.6%  0.0% 97.4%
x264 [info]: kb/s:50087.9

　qp=0で量子化そのものをオミットするそうなので他にも無駄なオプションがあるかも知れない。てゆうかtrellisとかcqm=jvtとか要らない よな。8x8dctも効いてないし。てゆうか時間軸圧縮抜いてるんなら少なくとも動き補償系も要らない、、、ぶつぶつぶつ。
　I枚数と総フレーム数が地味にオカシイが、MovieVideoChartで見る限り全てSyncフラグが付いている。
　サイズは映像の内容しだいだが、概算で5MB/secとして、300MB/min, 9GB/30分, 18GB/hr, 36GB/2時間。
　MEncoderでインタレ解除/逆テレシネを掛ければもう少し縮むだろう。

　x264qp0.mp4自体はffmpegでも作れるようだが（-cqp 0）、どうせならMEncoderでデノイズ、インタレ解除、必要ならcropやスケーリングを済ませてしまえば、その後のワークフローがコンパクトにな る。

　これをffmpegでデコードしてx264cliに繋げばlibmpeg2 decoding delayやDelay Frameの無い.264になるかもしれない。
　QT上でx264Encoderに任せても良い。

　x264 lossles.mp4の設定

qp=0:bframes=0:keyint=0:keyint_min=0:scenecut=100:nodeblock:cabac:cqm=jvt:me=umh:me_range=32:subq=7:frameref=1:8x8dct:partitions=all:trellis=2:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:threads=16

　実験の目標その１：ここから無駄な設定を抜く。
　目標その２：このI枚数はやっぱおかしい。フレームが14枚ロスト？

Video stream: 41240.797 kbit/s  (5155099 B/s)  size: 33197640 bytes  6.440 secs  205 frames
x264 [info]: slice I:191   Avg QP: 0.00  size:173745
x264 [info]: mb I  I16..4: 14.7%  0.0% 85.3%
x264 [info]: kb/s:41657.2

　値がゼロで揃ったものは無くても良い。残すべきものは緑で。薄緑は好みで。赤がフレームロスト緩和。
　秒数以外の値は標準との差。

-	変更値	sec	frames	kb/s	I枚数	I_size	I16	I8	I4	memo
標準	-	24	205	41657.2	191	173745	14.7	0	85.3
qp=0	-	-	-	-	-	-	-	-	-	-
bframes=0	14	24	0	-1005	12	-4191	0.5	0	-0.5	Iが203枚になったがBは無い。冒頭におかしなフレーム無し。 MovieVideoChartで確認してもチェックOK
-	1	25	0	-1005	12	-4191	0.5	0	-0.5	同上
keyint=0	999999999	-	-	-	-	-	-	-	-	Pが入る
-	1	25	0	0	0	0	0	0	0	1か0
keyint_min=0	300	36	0	-5475.9	-189	-12534	0	0	0	Pが入る
-	1	23	0	0	0	0	0	0	0	-
scenecut=100	-1	23	0	0	0	0	0	0	0	-
nodeblock	deblock	23	0	0	0	0	0	0	0	-
cabac	nocabac	16	0	5345.7	0	22296	1.1	0	-1.1	-
cqm=jvt	抜き	23	0	0	0	0	0	0	0	-
me=umh	dia	23	0	0	0	0	0	0	0	-
me_range=32	16(umh)	26	0	0	0	0	0	0	0	-
subq=7	1	16	0	158.7	0	662	5.7	0	-5.7	速度向上
frameref=1	15	24	0	0	0	0	0	0	0	-
8x8dct	抜き	23	0	0	0	0	0	0	0	-
partitions=all	抜き	23	0	0	0	0	0	0	0	-
trellis=2	抜き	24	0	0	0	0	0	0	0	-
nofast_pskip	抜き	26	0	0	0	0	0	0	0	-
nodct_decimate	抜き	23	0	0	0	0	0	0	0	-
nointerlaced	-	-	-	-	-	-	-	-	-	-
noglobal_header	抜き	23	0	0	0	0	0	0	0	-
psnr	抜き	24	0	0	0	0	0	0	0	-
ssim	抜き	24	0	0	0	0	0	0	0	-
threads=16	1	44	0	-1005	12	-4191	0.5	0	-0.5	Iが203枚になった。冒頭におかしなフレーム無し。 MovieVideoChartチェックOK

　フレームが14枚もロストする理由は解らないが、恐らくthreadがピクチャをスライス単位に分割するのが原因だと思う。threads=1でロス数 が2に緩和した。
　また面白い事に、bframes=1以上でも同じ効果があった。これも理由不明だが分散方式になにか影響するのだろう。GOP関連設定で抑止すればBも Pも入らない。
　残る2枚もやっつけたいところだが、むははははは。おれをだれだとおもってるッ！！
　これはlibmpeg2 decoding delayという、mencoderがデフォルトで使うMPEG-2デコードライブラリのバグだ。
　-vfm ffmpegで1枚に抑止できる（偉いのはbondさんとakupenguinさんですすいませんすいません）。

　従って望み得る最速設定はこーだ。

mencoder INFILE.mpeg \
-vfm ffmpeg \
-nosound \
-ovc x264 -x264encopts \
qp=0:\
bframes=1:\
keyint=0:\
keyint_min=0:\
nodeblock:\
nocabac:\
subq=1:\
nointerlaced:\
threads=16 \
-vf yadif,hqdn3d=2:1:2,harddup \
-ofps 30000/1001 \
-of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames \
-o OUTFILE.mp4

　結果は以下。

Video stream: 45796.340 kbit/s  (5724542 B/s)  size: 39156823 bytes  6.840 secs  205 frames
x264 [info]: slice I:204   Avg QP: 0.00  size:191899
x264 [info]: mb I  I16..4: 21.5%  0.0% 78.5%
x264 [info]: kb/s:46009.6
sec 11

　約7sec, 5.9MBのMPEG-2が11secで37.3MBのインタレ解除済みx264ロスレス.mp4になった。但し、末尾1フレームロスト。
　あ、よく考えるとこれベースラインだから、素のQTPでも開けると思う。

	スケーリングしてないので そのままでは720x480表示。
	QTPproの林檎+Jで変える。
	「そのまま」mp4書き出し OKだがここに非Apple製 コデックは出てこない。 これだとアスペクト指定した MP4を書き出せない。