« マウスとキーボードをソフトウェアで共有する | メイン | HDRI »
2007年12月08日
動画再生エンジン開発日誌:: デコードのマルチスレッド化について
Tweet @jin1016をフォローMPEG の動き補償部分のSSE2, SSE3化がスキップフレームを除いて出来たので、プロファイルを取ってみた。
動き補償関係の処理の割合が1/6ぐらいにまで下がったが、その代わりDCT係数のハフマンデコード周りの負荷が目立ってきた。
DCT係数のハフマンデコード + 逆量子化が40%近い割合を占めている。
現状、元のソースのテーブルを使ったデコード方法だが…… ここまでこの処理に取られていると改善した方がいいんだろうと言う気になってくる。
とはいえ、逆量子化部分は少しだけ SIMD 化できるが、他は難しい。
分岐が多いので、それを減らせば少しぐらいは向上するかなぁ。
自分の中での Theora の再生負荷の目標は、Pentium III M 866MHzで640x480の動画が再生できることと、Athlon 64 X2 3800+ でフルHD動画を再生できること。
PenIII の方はギリギリだけれど、再生できるぐらいのはず。
Athlon 64 X2 3800+ のフルHDは全然無理。
Core 2 Duo E6750 で音なしがギリギリ再生できると言うところ。
Core 2 Duo E6750 が Athlon 64 X2 3800+ の倍程度と言うことを考えると、マルチスレッド化は必須だろう。
マルチスレッド化出来そうなのは、動き補償とIDCT部分かな。
IDCTは、係数さえデコードされていれば独立しているし、動き補償は他のフレームを参照して合成コピーするだけ。
最初にブロック情報をまとめてデコードして、そのブロックのキューからIDCTと動き補償を実行するスレッドを走らせればいい。
ブロック情報のデコードも別スレッドの方がいいかな？ まあ、その辺りはパフォーマンスが出るように試行錯誤か。
ブロック情報がまとまっていれば、次のブロックがわかるためプリフェッチしやすいので、メモリアクセスもある程度改善できると踏んでいる。
MPEG も同様の方法でマルチスレッド化できるが…… 必要だろうか？
マルチスレッド化によって高速化されれば、再生時の応答速度が向上するか。
後、機能性を出すためにも速い方がいいといえばいいか。
まあ、やれそうならやるかな。
なんか思っていたよりも時間かかっていると言うかかけているというか。
高速化にはまりすぎだな。
投稿者 Takenori : 2007年12月08日 15:26
comments powered by Disqus