« プロファイラ | メイン | MPEG I デコードでもとのソースから変えているところ »
2007年11月19日
動画再生エンジン開発日誌:: なんとか MPEG I の再生が綺麗に
Tweet @jin1016をフォローMPEG I の再生がおかしいのを何とかすることにした。
動き補償周りが怪しいとは思うものの、すぐには問題の箇所を特定出来なかった。
いろいろと OFF にして絞り込もうとしたけど、わからず机上で追うことにした。
そのついでに、その周辺のソースの整理とコメントの日本語化も行った。
JIS のドキュメント見つつ、ソースも追いながら。
で、不具合の原因は極めて単純で、8 回ループすべきところが、4 回になっていたこと。
元のソースはループの展開を行って、少しでも速くしようとしていたようだけど、それほど効果も見込めないし、読みづらいのでその箇所は直していた。どうやらその時にミスっていたようだ。
そのようなループの展開を行っているのは1箇所ではなくて、何箇所もあって書き方も数通りあったので、見つけづらかった。
これで綺麗になったと思いきや、時々おかしなブロックが出る。
そのブロックは、単色だったり縞々だったりするので、IDCT 周りが怪しいと踏んだ。
IDCT のソースはほとんどそのままなので、その前段階のハフマンデコードをまず疑ってソースを追うもわからず。
IDCT の部分を調べることに。
IDCT の中に ORIG_DCT というデバッグオプションがあったので、ON にしてみた。
綺麗になった。
えっ？
中を見ると、前段階のハフマンデコードで最後に書き込んだ DCT 係数の位置によって事前計算したテーブルを参照する位置を変えて IDCT を行うコードに切り替わるかどうかの違い。
どうもこのテーブルを使うバージョンがおかしいようだ。
何がおかしいか中を追うのは面倒なので、テーブルバージョンを通らないようにした。
これで綺麗に再生できるようになった。
ただ、ファイル終端付近の処理がおかしいようで、ファイルによっては最後の方で落ちてしまうことがある。
まあ、これはわかりやすいので簡単に直るはず。
後、現バージョンでは MPEG I デコードがすごく重い。
これは、MMX や SSE2 を使えばかなり改善されるはず。
とりあえず、Intel AP-945 (PDF) の イントリンシック を使った IDCT に切り替えると、処理時間の 28.4% も占めていた IDCT が、0.1% になった。
すごく速い ( ただし、これをそのまま使ってもいいのかどうか不透明なので、最終的には別のものになると思う ) 。
これで、処理時間のトップだった IDCT が圏外に消えて、動き補償がトップに。
動き補償の部分は、単純にブロックをコピーしたり、前後のフレームのある位置のピクセルをピクセルごとに足して2で割って四捨五入したものをコピーしたりするが、SSE や SSE2 には、この足して2で割って四捨五入というこのための命令があったりするので、ここもかなり改善されるはず。
また、Intel の 日本語技術資料のダウンロード ページには、このような処理をどうするかと言った資料があるのでやりやすい。
投稿者 Takenori : 2007年11月19日 17:46
comments powered by Disqus