スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« まずはデータ読み込み | トップページ | 結局は、微変更になりそう »

雰囲気は掴めた

今は、Mac用AGMPlayerの開発フェーズで、とりあえず、AGMtoMP4変換では、AGMデコーダーの処理性能がボトルネックになっていたので、その性能を向上させようとしているのだが、今日の時点で、大体の雰囲気は掴めた。なので、何をやるのかも大体決まった。

AGMデコーダーの処理は、大体に分けると、以下の様になる。

1.ストレージデータの読み込み

2.ハフマン圧縮の展開

3.コード化されたDCTデータのデコード

4.DCTデータをYUVデータに変換

5.YUVデータを出力フォーマットに変換

で、1.については、昨日の時点で、次フレームの読み込みを確実に行える様な構造の別ルーチンを作成したので、今日は、それが動作する様にした。

その結果としては、全然、高速化されなかったので、やはり、データのプリフェッチについては、OSの処理ルーチンに任せても問題ないかもしれない。

2.については、テーブル参照の高速化ルーチンを使用しているので、特に圧縮率が高いDCT/DCT+モードでは、大したオーバーヘッドになっていない。具体的には、ハフマン圧縮の展開処理を2回行う様にしてみても、全処理で3分かかる場合に、増加する処理時間は、2,3秒程度だ。

なので、この処理を前倒しでマルチスレッド動作させたとしても、全処理で3分かかる場合には、短縮できる処理時間は1秒程度しかないかもしれない。

3.についても、元々は、相対的には大して重い処理でもなかったのだが、4.の逆DCT変換をSSE2命令を使って高速化してきた結果、相対的には、4.と同じくらいの重い処理になっている。

そして、3.については、基本的にはシングルスレッド動作なので、この処理をマルチスレッド化できれば、それなりの処理時間短縮は可能かもしれない。

4.については、前述の様に、元々は重かったのだが、SSE2命令を使った処理ルーチンを何度も改良してきた結果、今では、相対的には大して重い処理ではなくなっていて、現時点でも、単体処理でマルチスレッド化されている。

5については、RGBA出力の場合には、YV12toRGB変換を行っているのだが、この処理は、結構、重い。また、YUV出力時にも、Media FoundationやAVFoundationが使っているRGB⇔YUVの変換式とAGM形式が使っているソレは異なるので、Media FoundationやAVFoundationに対してYUV出力する場合には、AGM-YUV→RGBA→YUV変換を行っている。

なので、AGMデコーダー的には、一般エンコーダー向けには、RGBA出力した方が高速化されそうなモノなのだが、実際には、YUV出力させた方がずっと高速だ。

これは何故なのか、というと、まず、前述の変換では、SSE2レジスタ内で全ての処理が行えているので、RGBAデータがメモリに書き込まれる事がない。

つまり、今時のCPUは内部処理速度に対してメモリアクセス速度が遅いので、YUVデータの2倍のデータ量になるRGBAデータをメモリを介してデコーダーからエンコーダーに渡すというのは、処理性能的に問題がある訳だ。

また、総合的にYUV出力させた方が高速になるのは、エンコーダー側でも、ネイティブなデータ形式はYUV形式なので、RGBA形式でデータを渡すと、エンコーダー側でRGBAからYUVへの変換が行われるのだが、アクティビティモニターのCPU使用率を見ていると、少なくとも、Mac mini Late2014では、AVFoundationは、この処理をCPUで行っている感じだ。

なので、折角、エンコード自体にはQSVが使われるとしても、エンコーダーも、CPU性能を、結構、消費する事になるので、CPUを使って処理を行っているAGMデコーダー側の処理も、CPU性能が足りなくなって遅くなってしまう訳だ。

と、いう事で、5.について、長々と書いてきたのだが、これは、もし、AGM形式のYUV変換式がMedia Foundation/AVFoundationと同じだったら、5.については行う必要がなかったので、作者的にも悔しい思いをしているからだ。

もっとも、3分丁度かかるエンコード処理で、この処理を省いた場合には、どの程度の処理時間短縮があるのか、というと、10秒程度だ。つまり、この処理のオーバーヘッドは全体処理の5%程度でしかないので、それほど目くじらを立てる事も無いかもしれない。

ただし、現行のAGMデコーダーでは、この処理をマルチスレッド化していなかったので、全体時間に占める、この処理の処理時間は20秒程度あった。つまり、今日は、この処理をマルチスレッド化したので、前述の結果になっているのだが、現行版では、シングルスレッド動作なので、エンコード処理の処理時間を遅延させている可能性もある。

可能性、と、書いているのは、Media FoundationのMP4エンコーダーは、そこまで速くないかもしれないので、AGMデコーダーの処理時間が、それよりも速ければ、問題は無いからだ。

と、いう事で、雰囲気は掴めたのだが、前述の様に、ストレージのプリフェッチ・ハフマンデコードのマルチスレッド化による高速化は望み薄で、DCT逆変換については、これ以上の高速化は無理かもしれない。

となると、残すところは、前記の3.と5.になるのだが、5.については、前述の様に、既にマルチスレッド化する事で、オーバーヘッドは全体の5%程度にまで落とせているので、これ以上高速化しても、大した効果は無いかもしれない。

なので、高速化アイテムは3.の改良になるのだが、その方法は幾つかあって、CPUが非力なAndroid版AGMPlayerでは、既に、改良したルーチンを使っているので、同じ方式にする手もある。

ただ、プリフェッチ時に、3.までは、一気に行っておく事も可能なので、そういう方式もアリかもしれない。

と、いう事なので、作業は明日も続ける事になる。

« まずはデータ読み込み | トップページ | 結局は、微変更になりそう »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/64465233

この記事へのトラックバック一覧です: 雰囲気は掴めた:

« まずはデータ読み込み | トップページ | 結局は、微変更になりそう »

2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google