« ボタンエッジ検出と長押し判定 | メイン | α動画圧縮の手前まで »
2008年05月13日
吉里吉里 ムービー拡張日誌2:: アルファ付き動画の高速化を考える
Tweet @jin1016をフォロー現在のまま実装すると 1.5 GHz 程度の CPU では、2個同時ぐらいが限界になりそうなので、もう少し高速化する方法を考える。
できれば、3個同時に再生したい。
SIMD 拡張版 IJG JPEG library では、数ラインずつデータを取得していくが、中を見るとそのラインに必要な分だけデコードしているっぽい。
必要な分だけやっているとしたら、キャッシュの効率は良さそうだ。
高速化するのなら他の部分や特性を考えないと難しそう。
IDCT のアセンブリソースを C に書き直していて気付いたけど、どうも一度 char サイズの YCrCb カラーに変換してから、RGB カラーに変換している ( IDCT の係数行列は short 型 )。
YCrCb カラーから RGB カラーに変換する時、また一度 short に戻している。
これは少し無駄に見える。
元の IJG JPEG library の構造からくる制約だろうか？
それか、一度 unsigned char にすることで飽和処理を用いて 255～0 の範囲に丸める必要があるのかもしれない。
この辺りは実験した方が良さそう。
また、YCrCb カラーから RGB カラーに変換する部分でも、精度を重視したような実装になっている。
四捨五入したり、2倍してから計算して半分に戻すなど。
少しの誤差は気にしない方針にしてしまえば、ここも少し速く出来るかもしれない。
これ以上はアルファに注目して、高速化するのが良さそう。
16x16 のブロックで全て透明のものは保持せず、ブロックが完全に透明かそれ以外かでフラグを保存しておけば、完全透明の時は単純にゼロフィルすればいいだけになる。
また、色空間変換時にアルファ値を参照して 0 ならその部分の変換はスキップしてゼロフィルする。
これが出来るだけでも、かなり速くなるのではないかと思う。
画像にもよると思うが半分以上は透明なのではないかと思う。
そうなると、その半分はほとんどの処理を飛ばせるのでかなり速くなるはず。
ただ、完全に透明な領域が少ないと効果は少ない。
そこは動画なのでフレームによって差があると思うので、先読み分である程度処理負荷を平均化出来るのではないかと考えている。
でも、これやるとなると IJG JPEG library にかなり手を入れるか一から作る必要があるのが大変。
と言いつつ、SIMD 拡張版 IJG JPEG library のアセンブリソースを少しずつ C に直しているんだけど。
投稿者 Takenori : 2008年05月13日 23:13
comments powered by Disqus