スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 雰囲気は掴めた | トップページ | ソースコードが消滅 »

結局は、微変更になりそう

今は、Mac用AGMPlayerの開発フェーズで、とりあえず、AGMtoMP4変換では、AGMデコーダーの処理性能がボトルネックになっていたので、その性能を向上させようとしているのだが、結局は、微変更になりそうだ。まあ、それだけ、現行版は優秀という事になるのだが。

昨日書いた様に、AGMデコーダーの基本処理の中で、ストレージの読み込みとハフマン展開については、現行版のままでも、大したオーバーヘッドにはなっていない。

また、DCTデータの逆変換についても、SSE2命令を使った処理コードを何度も改良してきているので、現行版からの更なる改良は困難だ。

なので、高速化できそうな所としては、.「コード化されたDCTデータのデコード」、と、「YUVデータを出力フォーマットに変換」、になるのだが、今日は、この両者について、色々と試してみていた。

「YUVデータを出力フォーマットに変換」、という処理は、今回、初めてAVFoundation用のフォーマットに変換していたので、とりあえずは、元々あったWindowsのMedia Foundation用に出力したデータを更に変換する格好にしていたのだが、今日は、それをAVFoundation用に最適化した。

具体的には、Media FoundationとAVFoundationでは、UVデータの並びが異なるので、Media Foundation用の変換ルーチンの最終出力部分を変更したモノをAVFoundation用の変換ルーチンにしたのだが、この変更で、それなりに高速化された。

高速化された理由は、元々は、AGM-YUV → MediaFoundation-YUV → AVFoundation-YUVという形になっていたモノが、AGM-YUV → AVFoundation-YUVの形に短縮されたからなのだが、これはつまり、メモリアクセス量が減った事を意味する。

何故なら、MediaFoundation-YUVでは、UVメモリ領域は分離しているので、UVメモリにアクセスする場合には、独立した2回のメモリアクセスが入るのだが、AVFoundation-YUVでは、UVデータはセットで格納されているので、UVデータの格納は1回のメモリアクセスで済む格好になるからだ。

もっとも、実際には、話はもっと複雑で、MediaFoundation用変換の最終書き込み処理では、SSE2命令を使った処理ルーチンの都合から、UVデータは、それぞれ4バイトずつしか生成されないので、メモリ書き込みは一般命令で行っていたのだが、AVFoundation用では、合わせて8バイトになるので、SSE2レジスタでの書き込みが行えた。

なので、その辺による高速化効果もある筈な訳なのだが、いずれにしても、AVFoundation用の出力ルーチンを作成後は、エンコード速度は更に高速化された。

今回の開発で、最初からテスト用に使っているフルHD15分のAGM3-DCT+動画からMP4へのエンコード時間は、RGBモードを使っていた時には、丁度、4分くらいかかっていた。

次に、YUVモードを使う格好にすると、3分20秒くらいまで処理時間は短縮されたのだが、次に、AGM-YUV → MediaFoundaion-YUVの変換処理をマルチスレッド化する事で、処理時間は3分5秒くらいにまで短縮された。

そして、今日のAVFoundation用変換処理に変更するする事で、処理時間は2分55秒くらいにまで短縮された訳だ。

と、いう事で、残すところは、「コード化されたDCTデータのデコード」の最適化になるのだが、こちらについても、処理コード自体については、何度も改良してきたので、弄りようはないかもしれない。

なので、高速化アイテムは、マルチスレッド化になるのだが、何度も書いてきた様に、この処理自体は逐次処理が必須なのでマルチスレッド化は出来ない。

このため、この処理をマルチスレッド化する為には、複数のこの処理を同時に動作させるか、他処理と一緒に動作させる格好にする必要がある訳だ。

具体的には、前者については複数フレームの同時デコードを行わせる必要があり、後者については、DCT逆変換なんかと同時に動作させる必要がある。

もっとも、AGMtoMP4変換処理では、多くのフレームが順次デコードされて行くので、前フレームの後処理と、次フレームの前処理が同時に走る格好にする事でも、前述の処理をマルチスレッド化する事は可能だ。

このため、AGMデコーダーの出力形式をAGM-YUVにして、AVFoundation-YUVへの変換処理をAVFoundationへの書き込み時に行う様に変更してみた。

こういう格好にすると、AGM-YUV → AVFoundation-YUV変換と次フレーム用の「コード化されたDCTデータのデコード」が同時に走る格好になるので、高速化されるか、と、思った訳なのだが、目に見えた高速化は無かった。

これは、全体的に見れば、AGMデコーダーのデコード速度がAVFoundationのエンコード速度よりも遅いのだが、AGMデコーダーは、画面変化が少ない場面のデコードは高速に行われるので、この場合には、AGMデコーダーの処理速度はAVFoundationのエンコード速度よりも高速になっている。

そして、前述の様に、書き込み時にAGM-YUV → AVFoundation-YUV変換を行う格好にすると、実質的には、AVFoundationのエンコード速度がより低速になる格好になるので、折角、AGMデコーダーが高速に処理を終われている場面では、エンコード速度を低下させてしまうから、と、考えられる。

まあ、AGM-YUVでも、UVデータは独立しているので、一旦、AGM-YUV形式で出力させると、その分のメモリアクセスが問題になる、という事もあるのだが、いずれにしても、前述の様な、AGM-YUV → AVFoundation-YUV処理を独立させてマルチスレッド化を図る方式は上手く行かなかった。

なので、残すところは、複数フレームの同時デコードと、DCT逆変換との同時動作になるのだが、DCT逆変換との同時動作については、現行版でも行っている。

つまり、コード出力できた分からDCT逆変換を行っているので、そのDCT逆変換中に次のコード出力が同時に走っている格好になっている。

にも関わらず、この処理のマルチスレッド化に拘っているのは、この同時処理が最適化されていないからなのだが、現行版で、この同時処理をやめたとしても、前述の2分55秒が3分丁度になる程度だ。

これは、AVFoundationもエンコード時にCPUを使っている部分があるので、既に、CPU処理性能ネックで、同時動作を行わせようと思っていても、実際には、行われていない、という可能性もある。

つまり、これ以上、マルチコアCPUを有効利用しようと思っても、出来ない状況かもしれない訳なのだが、もう一日くらいは、色々と試してみる事にする。

« 雰囲気は掴めた | トップページ | ソースコードが消滅 »

トラックバック

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

この記事へのトラックバック一覧です: 結局は、微変更になりそう:

« 雰囲気は掴めた | トップページ | ソースコードが消滅 »

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