スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« その効果は絶大 | トップページ | ここでちょっとコード整理 »

高圧縮モードも部分適用

今は、Mirror-DTCの次バージョンを開発中で、昨日はウインドウ移動とスクロールに対応する専用の動き検出処理を追加したのだが、今日は、AGM3コーデックにある「高圧縮モード」も部分適用した。何れも圧縮率向上には貢献するのだが、ジワジワ重くなるのが気がかりだ。

まず、昨日実装したウインドウ移動とスクロールに対応する専用の動き検出処理というのは、普通の動き検出処理とは少し異なる。

具体的には、普通の動き検出処理というのは、16x16ピクセルくらいの領域の全ピクセルについて、近傍の16x16ピクセルと比較し、その差分が最も少なかった近傍領域を移動元の領域と判定する。

これに対して、昨日実装した動き検出処理は、まず、近傍の領域との比較は完全一致するかどうかで行うので、1ピクセルの値が1でも異なれば、移動元とは判定しない。

この違いにより、比較対象が移動元ではなかった場合には、殆どの場合、16x16ピクセルの全てを比較しなくてもNG判定が行えるので、処理が軽量化できるメリットがある。

もっとも、上記だけでも、かなりのメリットにはなるのだが、上記のみをメリットとする新しい動き検出処理を試してみた所では、現在の環境で60FPS転送できるサーバーで、30FPS転送も苦しい状況になってしまった。

なので、より処理を軽くする工夫をした訳なのだが、その工夫というのは、比較対象を16x16ではなく、128x128にした事だ。

そうする事で、移動元が存在しない場合には、比較処理のオーバーヘッドは、大体のケースで、128 / 16 * 128 / 16 = 64倍程度、軽量化できた。

一般動画の場合、これだけ大きな領域が移動する事は想定できないのだが、昨日実装した動きベクトル検出処理の検出対象はデスクトップ上のウインドウとウインドウ内のコンテンツになるので、この大きさでも、普通は移動検出が行える訳だ。

ただし新しい動き検出処理と一般的な動き検出処理との違いの二つ目として、新しい動き検出処理では、検出された移動元を素直には使わない。

これは何故なのか、というと、対象領域サイズが128x128では、移動検出が行えたとしても、ある意味、ザル、になるので、同様に移動している周辺領域は移動対象として扱えないからだ。

なので、新しい動き検出処理では、上記で得られた移動ベクトルのみを使用し、次のステップとして、通常の16x16ピクセル領域について、この登録されたベクトルでのチェックを行うという二段階の動き検出方式にしている。

こうする事で、128x128の動き検出で、普通は、ウインドウ移動とスクロールが発生していて、その移動量が特定でき、動き検出自体については、16x16ピクセル単位で正しく行えるので、取りこぼしもなくなる訳だ。

もっとも、上記の様な対策を行ったとしても、全画面動画再生時なんかには、移動ベクトルが検出される筈がないのに、上記の処理が動作してしまう。なので、60FPS再生可能だった環境でも50FPS程度にフレームレートが低下してしまったので、更なる対策を行った。

具体的には、新しい動き検出処理は、一般動画用の動き検出処理でベクトルが検出できなかった割合が一定値を越えた場合にのみ、動作する様にした訳だ。

こうする事で、通常の動画再生時には、一般動画用の動き検出処理で大体のベクトルは検出されるので、新しい動き検出処理は動作せず、オーバーヘッドも増えず、ウインドウ移動だとかスクロール時の様に、一般動画用の動き検出処理では動きが追いきれない様なケースでのみ、新しい動き検出処理を動作させる事が出来る様になった。

この方式は一粒で二度おいしい感じになっているのだが、その理由は、新しい動き検出処理では、移動元を検出できた時点で検出処理は終了できるので、移動元が存在する場合の方がオーバーヘッドも少なくできるからだ。

つまり、大半の場合、新しい動き検出処理が動作するのは移動元がある場合なので、オーバーヘッドも少なくて済む訳だ。

もっとも、デスクトップ上に新しいウインドウが表示された場合や、動画で場面チェンジがあった場合には、一般動画用の動き検出では移動ベクトルが検出されないので、新しい動き検出処理が動作するのだが、この様な場合には、新しい動き検出処理でも移動ベクトルは検出されないので、最大オーバーヘッドが発生する事になる。

なので、この様な場合には、若干、新しい動き検出処理を追加した事によるオーバーヘッドが発生するのだが、この様なケースは時間的に継続するモノでもないので、電力効率的には、大した問題にはならない筈だ。

ちなみに、表題にした様に、今日はAGM3コーデックの高圧縮モードの符号化方式をストリーミング圧縮時に適用する様にした。

この符号化方式では、主に、場面チェンジ時の様に、動きベクトルが使えず、新しい画像をそのまま出力する場合の圧縮率が3割程度は向上するのだが、若干、処理が重くなる。

なので、この方式はAmuseGraphics系ではAGM-DCTにも適用できるのだが、Mirror-DTCでは、AGM-DCT相当の映像圧縮には適用しない事にした。

何故なら、次バージョンのMirror-DTCでの映像圧縮の位置づけは、ストリーミング圧縮との比較で、圧縮率は低いものの処理は軽い、というモノになる筈なので、その特長を際立たせる事にした訳だ。

もっとも、だからといって、ネットワーク帯域が足りている場合に、ストリーミング圧縮でフルHD-60FPS再生が出来なくなるのは困りものなので、処理性能については、もう少し、なんとかならないモノかと検討中だ。

= この記事に関連する公開中ソフト =

Mirror-DTC

Mirror-DTC

(2016/05/04追記)

« その効果は絶大 | トップページ | ここでちょっとコード整理 »

トラックバック

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

この記事へのトラックバック一覧です: 高圧縮モードも部分適用:

« その効果は絶大 | トップページ | ここでちょっとコード整理 »

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