スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 動きベクトルの圧縮形式 | トップページ | 音声系の変更は二つ »

隙を生じぬ二段構え

今は、Mirror-DTCの次バージョンを開発中で、今日は昨日書いた新しい動きベクトルの圧縮形式を実装した。その結果、理屈通りの効果が出たので、より完成度を高めるべく、中途半端だった色の扱いを厳密化した所、考えてみれば当然の事なのだが、新しい発見があった。

昨日書いた様に、新しい動きベクトルの圧縮形式というのは、動きベクトルの種類をカウントし、例えば、16種類しかなかった場合には、4ビットで表現できるので、ベクトル値は4ビットで出力する、というモノだ。

この形式だと、例えば、ウインドウ移動時の様に、ウインドウ用の16x16ブロックが同じ移動ベクトルを持ち、他の移動ベクトルが無い場合には、従来方式だと16x16ブロック用のベクトル値が8ビット程度で表されていたモノが、2ビットで表現されるので、4倍の圧縮効率が得られる訳だ。

もっとも、実際にはあるウインドウが移動すれば、そのウインドウに隠れていた部分が見える様になるので、その部分については、普通はベクトル検出に失敗する。

で、この失敗値も、上記のベクトルの種類の1つとしてカウントするし、ランレングス圧縮用にも2種類を割り当てている。

なので、実際には2ビットで表現される事は殆ど無い筈なのだが、3ビットになる事は普通にあるので、ウインドウ移動だとか場面チェンジ時の圧縮率は従来方式と比べて、普通は2倍程度はある訳だ。

もっとも、一般動画を見ている様な場合には、通常は、動きベクトルの種類は数十はカウントされる事になるので、従来方式が8ビット程度だったのに対し、新しい方式でも6ビット程度は必要になるので、効果はそれほどでもない。

しかし、一般動画でも、場面チェンジ等では、多くのブロックで同時にベクトル検出に失敗するので、この様な場合には、新しい動きベクトルの圧縮形式は効果を発揮する。

で、既に書いていた様に、動きベクトルの検出処理では、輝度情報のみからベクトルを検出しているので、輝度が同等で色が異なる領域を移動元と誤検出する事がある。

なので、ストリーミング圧縮(高圧縮)では、基本的には動きベクトルのみで画像を生成する方針にしたのだが、色情報については、DCT変換で補正をかける様にしていた。

しかし、これは誤検出を容認する格好になる訳なので、何度も書いてきた様に、血液型がA型の作者的には、気持ち悪かった訳だ。

このため、今日は、輝度情報から得られたベクトルに対して色情報の差分を計算し、差分が大きかった場合には、ベクトル検出失敗扱いにする処理を追加した。

上記の様なケースは、通常は、あまり多くはないので、上記を追加したからといって圧縮率が低下する事は無かったし、むしろ、関連性がない領域同士の差分DCT変換を行わせるよりは、楽に変換できるので、圧縮率ば微増したくらいだ。

で、上記の処理を追加したので、晴れて、ストリーミング圧縮(高圧縮)から色情報のDCT変換も無くしてみたのだが、最高画質指定時には問題は無かった。

ところが、YV12変換が行われるそれ以外の画質指定時には、問題が発生した。

具体的には、Webブラウザでテキスト主体のページを見ている時に、ウインドウをゆっくりと移動してみると、色情報だけ、移動しなかった訳だ。

なので、作者的には、コーディングをミスったのかなあ、と、思った訳なのだが、考えてみると、輝度情報を元にした動きベクトル検出では、1ピクセルの移動もカウントするのだが、YV12変換された色情報というのは、2ピクセルに一つしか存在しない。

このため、フレーム毎に1ピクセルずつウインドウを移動した場合、輝度情報はベクトルに従って移動できるのだが、その移動量を1/2にせざるを得ない色情報については、移動できない状態が続くので、見ていると、輝度情報だけが移動して色情報は元の位置に残る格好になる訳だ。

問題が上記だけなら、輝度情報の移動量の合計値を持っておいて、それと色情報の移動量を比較して差が2ピクセルを越えたら色情報も移動する、という格好には出来るのだが、輝度が高いピクセルが色情報用の4ピクセルの端にあった場合、1ピクセル移動しただけで、本来なら色情報も移動させないと可笑しな感じになる。

なので、YV12変換が行われている場合には、やはり、ストリーミング圧縮(高圧縮)時にも、色情報のDCT変換での補正は行う格好にしたのだが、YV12変換付きで、テキストを扱っている場合には、前述の色情報の検証で不合格となるケースが極端に増えた訳だ。

これは何故なのか、というと、Windowsのテキストフォントは1ピクセル幅になっているモノが多いので、輝度情報が1ピクセル移動して本来の色情報が移動する場合には、その移動を行わないエンコード結果との差分は大きくなるからだ。

もっとも、通常動画の場合、1ピクセルの移動で色情報がそこまで劇的に変わる事は稀なので、問題はない。

ちなみに、何が、隙を生じぬ二段構えなのか、というと、Mirror-DTCの動きベクトル検出方式だ。

具体的には、YV12変換画面で前述の色情報の検証を行うと、一般動画時にはあまりNG判定は行われないのだが、色付きテキストが多用されている画面だと多くのNG判定が行われる。

NGと判定された場合、通常は、ベクトルによる移動は出来ないので、新しい画面そのものをDCT変換して転送しなければならなくなるので、データ転送量が増える。

しかし、ストリーミング圧縮の場合、通常の動きベクトル検出処理でNG判定が多発した場合、ウインドウ移動検出用のベクトル検出処理が動き出し、この検出処理はRGB値をベースに検出を行うので、YV12変換された画面でのテキスト移動時にも、正しい移動ベクトルが出力できる訳だ。

もっとも、そのベクトルを使っても、色情報の移動量が中途半端になる事は変わらないので、DCT変換での補正は必要になる。

なので、テキスト主体の操作時にストリーミング圧縮を指定する場合には、画質は最高画質にしておいた方がデータ量が少なくて済むケースも多いかもしれない。

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

Mirror-DTC

Mirror-DTC

(2016/05/04追記)

« 動きベクトルの圧縮形式 | トップページ | 音声系の変更は二つ »

トラックバック

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

この記事へのトラックバック一覧です: 隙を生じぬ二段構え:

« 動きベクトルの圧縮形式 | トップページ | 音声系の変更は二つ »

2017年6月
        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  

広告

プライバシーポリシー

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

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

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

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