« α動画圧縮の一連の流れ | メイン | 完全透明ブロックの劣化を回避する »
2008年06月19日
吉里吉里 ムービー拡張日誌2:: α動画基本動作OK
Tweet @jin1016をフォローα動画のエンコードとデコード(+再生)ができるようになった。
640x480 80フレーム(2.6秒)の立ち絵動画をクオリティ95で圧縮すると、約 3.1 MBになった。
立ち絵なので、αチャンネルは ZLib で圧縮されている。
クオリティ80だと 1.8 MBになる。
元の無圧縮 AVI ファイルは 96MB。
ちなみに同じ動画を WMV 95% にすると 844KB。
許せる範囲かな？
ただ、640x480 とは言っても、立ち絵は半分くらいの領域を使っているのみ。
α動画では、完全に透明ではないピクセルを含む最小矩形領域のみ保存しているので、占める矩形領域が小さいとかなり小さい動画を圧縮しているのと同じになる。
また、この矩形サイズはデコード時も関係している。
吉里吉里側のα合成の負荷を下げるため、レイヤーサイズもこの大きさに変更し、レイヤーにデコード画像を描いている。
ただ、矩形領域なので、大の字のようなポーズだったりすると無駄が多い。
で、違う立ち絵の動画3つを Core2Duo E6750 で再生すると、CPU 負荷 10% ～ 15% 程度。
まだ、MMX 化までしかしていないので、SSE2 まで対応するともっと下がると思う。
ただ、SSE2 が使えない CPU では意味がない。
1.5 GHz程度のマシンでどの程度の負荷かはまだ確かめていない。
ほかに出来る MMX のみでの更なる高速化は、完全に透明なブロックの処理を省けるようにすることくらいかなぁ。
ただ、あの特許申請中のものがなぁ……
完全に透明かどうかではなく、ブロックが単一色かどうかは IDCT の前段階でわかる。
AC 係数がすべて0であれば、そのブロックは単一色となる。
単一色であれば、色変換は1ピクセルだけ行い、後はその色で塗りつぶせばいい。
αチャンネルを ZLib で圧縮したバージョンのほうは、ブロックのαチャンネルをすべて調べるのと気にせず合成してしまうのでどちらが速いかは微妙。
この方法で単一色ならブロックを塗りつぶすようにすれば、完全に透明などは関係なく、べたで塗られているところは高速化される。
今回作っているα動画は、krmovie.dll とは独立した機構になっている。
元々は、高速化のためにレイヤーのサイズをフレームによって変更する必要があったので、別のプラグインとして作ることにした。
それ以外にも制御の多くを TJS 側に持っていく形にした方が、いろいろと都合が良いだろうということもある。
このプラグインでは、バックグラウンドで動画を順にデコードしてキューにためていくことしかしない。
キューから取り出して描画を指示するのは TJS スクリプト側の仕事。
つまり、再生速度のコントロールは TJS 側で行うことになっている。
このような仕組みのため、プラグインを変更することなく、スクリプト側でより柔軟な制御が出来るようになるはず。
ただ、現在デコード順は順方向のみなので、この辺りの指定をもっといろいろ出来るようにすると、さらにいろいろな再生が出来るようになると思う。
また、ファイル終端までデコードが終了したら、指定した別ファイルを続けてデコードすることを可能にしたので、複数のムービーを滑らかにつなげるようになった。
従来セグメントループなどの形で実現していたことを、別々のファイルで出来るので、動画制作時の取り扱いなどが楽になるはず。
投稿者 Takenori : 2008年06月19日 16:13
comments powered by Disqus