(57)【要約】  圧縮プロセスによって動き予測を低減または回避する方法でワイヤレス送信のためのビデオデータを処理することによってデルタ圧縮が達成され得る。ビデオデータおよび対応するメタデータがコンポジションエンジンにおいてキャプチャされ得る。そのデータおよびメタデータからフレームバッファ更新が生成され得る。フレームバッファ更新は、ピクセルデータとヘッダ情報とを含むビデオマクロブロックに関係するデータを含み得る。フレームバッファ更新は、ビデオ画像を再現するために、ピクセル参照データと、動きベクトルと、マクロブロックタイプと、他のデータとを含み得る。マクロブロックデータおよびヘッダ情報は、（ＭＰＥＧ−２などの）圧縮アルゴリズムにとって認識可能なフォーマットに変換され、次いで符号化され、ワイヤレス送信され得る。【選択図】      図２
2013521717.tif 000002
【特許請求の範囲】
【請求項１】
フレームバッファ更新を符号化するための方法であって、前記方法が、
フレームバッファ更新を記憶することと、
前記フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換することと
を備える方法。
【請求項２】
前記フレームバッファ更新がピクセル情報とメタデータとを備える、請求項１に記載の方法。
【請求項３】
前記メタデータがプロセッサ命令を備える、請求項２に記載の方法。
【請求項４】
前記ハイブリッド圧縮フォーマットがブロックベースである、請求項１に記載の方法。
【請求項５】
前記フレームバッファ更新がマクロブロックヘッダとマクロブロックデータとを含む、請求項４に記載の方法。
【請求項６】
前記マクロブロックヘッダが、マクロブロックＩＤ、マクロブロックタイプ、動きベクトル、および参照ピクチャのうちの少なくとも１つを備える、請求項５に記載の方法。
【請求項７】
前記マクロブロックタイプがマクロブロックモードを含み、前記マクロブロックモードが静的マクロブロック（スキップ）、イントラ（Ｉ）、および予測（ＰまたはＢ）のうちの１つである、請求項６に記載の方法。
【請求項８】
前記マクロブロックヘッダおよびマクロブロックデータがＭＰＥＧ−２認識可能フォーマットである、請求項５に記載の方法。
【請求項９】
前記マクロブロックデータがピクセル差分データと絶対ピクセルデータとを含む、請求項５に記載の方法。
【請求項１０】
前記マクロブロックヘッダが周期性およびタイミングデータを含む、請求項５に記載の方法。
【請求項１１】
フレームバッファ更新を符号化するための装置であって、前記装置が、
フレームバッファ更新を記憶するための手段と、
前記フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換するための手段であって、それによって動き予測をバイパスする、変換するための手段と
を備える装置。
【請求項１２】
フレームバッファ更新を符号化するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品が、
プログラムコードを記録したコンピュータ可読媒体であって、前記プログラムコードが、
フレームバッファ更新を記憶するためのプログラムコードと、
前記フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換するためのプログラムコードと
を備えるコンピュータ可読媒体
を備えるコンピュータプログラム製品。
【請求項１３】
フレームバッファ更新を符号化するように動作可能な装置であって、前記装置が、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合されたメモリであって、前記少なくとも１つのプロセッサが、
フレームバッファ更新を記憶することと、
前記フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換することと
を行うように構成されている、メモリと
を備える装置。
【請求項１４】
前記フレームバッファ更新がピクセル情報とメタデータとを備える、請求項１３に記載の装置。
【請求項１５】
前記メタデータがプロセッサ命令を備える、請求項１４に記載の装置。
【請求項１６】
前記ハイブリッド圧縮フォーマットがブロックベースである、請求項１３に記載の装置。
【請求項１７】
前記フレームバッファ更新がマクロブロックヘッダとマクロブロックデータとを含む、請求項１６に記載の装置。
【請求項１８】
前記マクロブロックヘッダが、マクロブロックＩＤ、マクロブロックタイプ、動きベクトル、および参照ピクチャのうちの少なくとも１つを備える、請求項１７に記載の装置。
【請求項１９】
前記マクロブロックタイプがマクロブロックモードを含み、前記マクロブロックモードが、静的マクロブロック（スキップ）、イントラ（Ｉ）、および予測（ＰまたはＢ）のうちの１つである、請求項１８に記載の装置。
【請求項２０】
前記マクロブロックヘッダおよびマクロブロックデータがＭＰＥＧ−２認識可能フォーマットである、請求項１７に記載の装置。
【請求項２１】
前記マクロブロックデータがピクセル差分データと絶対ピクセルデータとを含む、請求項１７に記載の装置。
【請求項２２】
前記マクロブロックヘッダが周期性およびタイミングデータを含む、請求項１７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、その全体が参照により本明細書に明確に組み込まれる、Ｖ．ＲＡＶＥＥＮＤＲＡＮという名称で、２０１０年３月２日に出願された米国仮特許出願第６１／３０９，７６５号の利益を主張する。
【０００２】
本開示は、一般にデータ圧縮に関する。より詳細には、本開示は、ビデオ信号のワイヤレス送信より前に実行されるデータ圧縮中に動き予測（motion estimation）を低減することに関する。
【背景技術】
【０００３】
テレビジョン（ＴＶ）および他のモニタにコンテンツをワイヤレス配信することが望ましい。一例として、いくつかの事例では、ＴＶデバイス上に出力するためにユーザデバイスからコンテンツを配信させることが望ましいことがある。たとえば、多くのＴＶデバイス出力能力と比較して、携帯電話、個人情報端末（ＰＤＡ）、メディアプレーヤデバイス（たとえば、Ａｐｐｌｅ（登録商標）  ｉＰＯＤ（登録商標）デバイス、他のＭＰ３プレーヤデバイスなど）、ラップトップコンピュータ、ノートブックコンピュータなど、多くのポータブルユーザデバイスは、小さいディスプレイサイズなど、出力能力が限定／制約されている。たとえば、ポータブルユーザデバイス上でビデオを閲覧することを望んでいるユーザは、ビデオコンテンツがＴＶデバイス上に出力するために配信された場合、改善されたオーディオビジュアルエクスペリエンスを得ることがある。したがって、いくつかの事例では、ユーザは、コンテンツを受信（閲覧および／または聴取）する際の改善されたオーディオビジュアルエクスペリエンスを求めて、テレビジョンデバイス（たとえば、ＨＤＴＶデバイス）上に出力するために、ユーザデバイスからコンテンツを配信することを望むことがある。
【発明の概要】
【０００４】
フレームバッファ更新（frame buffer updates）を符号化するための方法が提供される。本方法は、フレームバッファ更新を記憶することを含む。本方法はまた、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換することを含む。
【０００５】
フレームバッファ更新を符号化するための装置が提供される。本装置は、フレームバッファ更新を記憶するための手段を備える。本装置はまた、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換するための手段であって、それによって動き予測をバイパスする、変換するための手段を備える。
【０００６】
フレームバッファ更新を符号化するためのコンピュータプログラム製品が提供される。本コンピュータプログラム製品は、プログラムコードを記録したコンピュータ可読媒体を含む。プログラムコードは、フレームバッファ更新を記憶するためのプログラムコードを含む。プログラムコードはまた、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換するためのプログラムコードを含む。
【０００７】
フレームバッファ更新を符号化するように動作可能な装置が提供される。本装置は、（１つまたは複数の）プロセッサと（１つまたは複数の）プロセッサに結合されたメモリとを含む。（１つまたは複数の）プロセッサは、フレームバッファ更新を記憶するように構成される。（１つまたは複数の）プロセッサはまた、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換することであって、それによって動き予測をバイパスする、変換することを行うように構成される。
【０００８】
本開示のより完全な理解のために、次に添付の図面とともに行われる以下の説明を参照する。
【図面の簡単な説明】
【０００９】
【図１】マルチメディアデータを処理し、送信するために使用される構成要素を示すブロック図。
【図２】本開示の一態様によるデルタ圧縮を示すブロック図。
【図３】ワイヤレス送信のために準備されたマクロブロックデータとヘッダ情報とを示すブロック図。
【図４】静的マクロブロックのための例示的なマクロブロックヘッダを示す図。
【図５】本開示の一態様によるデルタ圧縮を示す図。
【発明を実施するための形態】
【００１０】
「例示的」という単語は、本明細書では、「例、事例、または例示の働きをすること」を意味するために使用する。「例示的」として本明細書で説明するいかなる態様も、必ずしも他の態様よりも好適または有利なものと解釈すべきではない。
【００１１】
ビデオデータをワイヤレスに送信するためにいくつかの方法が利用され得る。１つのそのような方法は、図１に示すエクスプレスカードインターフェースを介してコンテンツホストに接続するワイヤレス通信デバイスを利用し得る。図示のように、ホスト１００は、エクスプレスカードインターフェースを介してエクスプレスカード１５０に接続する。ホスト１００は、いくつかの処理構成要素を利用して１次ディスプレイ１０２およびオーディオ出力１０４への出力のためにマルチメディアデータを処理し得るか、またはホストは、バッファを通した（エクスプレスカード１５０などの外部デバイスとして図１に示された）送信機への出力のためにマルチメディアデータを処理し得、送信機は、アンテナ１５２を介した最終的なワイヤレス送信のためにそのデータをさらに処理し得る。図１に示した論理およびハードウェアは説明のためのものにすぎない。ホスト、外部デバイスなどの他の構成は、以下で説明する方法および教示を実装するために採用され得る。
【００１２】
通常、ビデオデータを処理するとき、画像データは、ディスプレイプロセッサ１０６によってレンダリングされ、コンポーズされ（composed）、一般にピクセルデータの形態でフレームバッファ１０８に送られる。そのデータは、次いで１次ディスプレイ１０２に出力される。（ムービーを閲覧することなど）いくつかの状況では、出力されるビデオデータは単一のソースからであり得、（ビデオゲームをプレイすることまたは複数のアプリケーションでデバイスを動作させることなど）他の状況では、グラフィカルオーバーレイオブジェクトまたはアナンシエータ（enunciator）を含む複数のグラフィカル入力は、最終的にディスプレイ上に示されるコンポジットビデオフレームを生成するためにビデオ画像に組み合わせられ、および／またはオーバーレイされ得る。複数のビデオ構成要素が組み合わせられる場合、そのようなビデオ構成要素を生成することを担当する各メディアプロセッサは、様々な入力／メディアプロセッサからのデータを組み合わせるために使用されるコンポジションエンジンにフレーム更新情報などのビデオ情報を通信するために、それ自体の出力言語を有し得る。コンポジションエンジンは、様々なプロセッサから（ビデオデータ、グラフィカルオブジェクトなどを含む）入力の組合せを取り出し、必要に応じてそれらをオーバーレイし、組み合わせ、それらを単一の画像にコンポーズし（適切なカラーコンポジションなどの追加の処理を含み得る）、それらを組み合わせて、最終的にディスプレイに表示される画像にする。
【００１３】
様々なプロセッサからの入力は、異なる言語、異なるフォーマットであり得、異なるプロパティを有し得る。たとえば、あるデバイスからの入力は、別のデバイスとは異なるフレーム更新レートでビデオデータを与え得る。別の例として、あるデバイスが新たなピクセル情報を繰り返し与え得、別のデバイスが、（１つまたは複数の）特定の参照ピクセルからの変更を示すピクセル更新の形態でビデオデータのみを与え得る。また、いくつかのプロセッサは、フレームを生成するために互いにコンポーズされる、フレームの異なる領域または異なるタイプのデータに対してのみ動作していることがある。異なるプロセッサからの様々な入力は、コンポジションエンジンによってモード情報に変換され、様々なプロセッサからの入力は、フレームを生成するためにピクセルデータに変換される。コンポジションエンジンによる処理の後、フレーム情報が最終的な表示のためにフレームバッファ１０８に送られる。
【００１４】
ビデオデータのワイヤレス送信のための一般的な方法は、単にフレームバッファ１０８からの表示の準備ができたデータをキャプチャし、送信が容易なようにビデオデータを符号化／圧縮し、次いでビデオデータを送る。そのような動作は、ディスプレイリンクドライバ１１０などの構成要素によって行われ得る。
【００１５】
ビデオデータ圧縮の１つの一般的な方法は、例示のために本明細書で説明するＭＰＥＧ−２であるが、ＭＰＥＧ−４などの他の圧縮規格も採用され得る。データ圧縮の使用は、追加のプロセッサとメモリ能力とを採用し得、より時間がかかり、電力を消費し得、最終的な送信の遅延につながり得る。遅延は、圧縮プロセスが第１のフレームを完全に復号し、その後、第１のフレームを参照として使用する次のフレームが復号され得ることから生じ得る。
【００１６】
そのような遅延を低減するための１つの方法は、参照フレームからの増分変更として複数の後のフレームのビデオデータを処理することである。そのような方法では、（デルタ（Δ）情報またはディスプレイフレーム更新と呼ばれる）更新または変更情報が、最終的なディスプレイ上に（参照フレームに対して）レンダリングするためにディスプレイプロセッサに送られる。このデルタ情報は、（たとえば、動きベクトルを含む）動き予測または他のデータの形態であり得る。圧縮中にそのようなデルタ情報を計算する際に、追加の処理能力が採用され得る。
【００１７】
本開示の一態様では、圧縮中のデルタ情報の判断が回避され、および／またはそのような判断に専用の処理能力が低減または回避され得る。（コンポジションエンジンに情報を出力する上記で説明したメディアプロセッサなどの）様々なメディアプロセッサは、デルタ情報がキャプチャされ、圧縮中に再計算される必要がないように、デルタ情報をすでに計算し得る。コンポジションエンジンに入る入力を見ることによって、各ピクセルに起こっていることに関するより多くの未加工情報が利用可能である。その情報は、エンコーダがマクロブロックまたはＭＢと呼ばれるピクセルのグループごとに出力するであろうモード情報に変換され得る。次いで、圧縮技法（たとえば、ＭＰＥＧ−２）によって理解可能なフォーマットのマクロブロックのデータ、および（動き情報を含み得る）マクロブロックのヘッダ情報が符号化され、組み合わせられて、ワイヤレス送信のために圧縮ビットストリームにされ得る。このようにして、従来の圧縮中の動き予測のプロセスおよびデルタ情報の計算は低減され得る。
【００１８】
図２に、本開示の一態様によるデルタ圧縮を示すブロック図を示す。（１つまたは複数の）ビデオソース２０６からのビデオデータは、デコーダ２０８によって復号され、ディスプレイプロセッサ２１２に送られ得る。ディスプレイプロセッサ２１２から、ビデオデータは、オンデバイス埋込みディスプレイ２１６または異なるディスプレイ（図示せず）への最終的な配信のためにフレームバッファ２１４に出力される。オーディオプロセッサ２１８からのデータは、スピーカー２２４への最終的な配信のためにオーディオバッファ２２０に出力される。ディスプレイプロセッサ２１２はまた、ＧＰＵ２１０からの画像データを受信し得る。ＧＰＵ２１０は、ビデオデータと組み合わせられるかまたはその上にオーバーレイされ得る様々なグラフィックス、アイコン、画像、または他のグラフィカルデータを生成し得る。
【００１９】
アプリケーション２０２はコンポジションエンジン／ディスプレイドライバ２０４と通信し得る。一例では、エンジン／ディスプレイドライバ２０４は、図１に示したディスプレイリンクドライバ１１０であり得る。エンジン２０４は、組合せおよびフレームバッファ２１４への出力のためにＧＰＵ２１０、デコーダ２０８、および／または他のソースからの情報を受信するようにディスプレイプロセッサ２１２に指令する。上記で説明したように、典型的なワイヤレス送信システムでは、フレームバッファ中に含まれているものは、Ａ／Ｖエンコーダに出力され、送信より前に多重化される最終画像である。
【００２０】
ただし、本開示では、ワイヤレス出力ストリームを生成するために、フレームバッファ中のデータではなくエンジン２０４からの情報が使用される。エンジンは、（１つまたは複数の）ビデオソース２０６、ＧＰＵ２１０などからのデータを知っている。エンジンはまた、フレームバッファに対する更新の生成に関連するディスプレイプロセッサ２１２に行くコマンドに気づいている。それらのコマンドは、ビデオディスプレイデータの部分的な更新に関する情報を含む。それらのコマンドはまた、ＧＰＵ２１０からのグラフィカルオーバーレイ情報を含む。エンジン２０４は、従来、それに知られている様々なデータを使用して、フレームバッファに送られるフレームバッファ更新を生成する。
【００２１】
本開示の一態様によれば、エンジン２０４またはエンジン２０４への拡張２５０などのデバイス構成要素は、本明細書で説明するフレームバッファ更新を符号化し得る。フレームバッファ更新は、メモリ２５２に記憶され得、メタデータを備え得る。メタデータはプロセッサ命令を含み得る。フレームバッファ更新はピクセル情報を含み得る。フレームバッファ更新はフレームレートおよび／またはリフレッシュ速度のためのものであり得る。フレームバッファ更新は、絶対ピクセル、ピクセル差分、周期性、および／またはタイミングに関するデータを含み得る。構成要素は、動き予測メタデータおよびメモリ管理機能の修正を含むハイブリッド圧縮を実行し得る。ハイブリッド圧縮はブロックベースであり得る。フレームバッファ更新はＭＢデータとＭＢヘッダとに分割され得る。
【００２２】
エンジン２０４から、１次ピクセル情報２２６およびデルタ／周期タイミング情報２２８がキャプチャされる。メタデータもキャプチャされ得る。いくつかのマクロブロック（ＭＢ）についての情報が収集され得る。ピクセルデータ２２６は、データが表されるピクセルのロケーションを示すインデックス（たとえば、（１，１））を含み得る。（（１，１）などの）参照ピクセルから、後のピクセル（たとえば（１，２））のデータは、後のピクセルと前の参照ピクセルとの間の差を示すデルタ情報のみを含み得る。
【００２３】
エンジン２０４からキャプチャされたデータは、メインディスプレイに行くように意図されたデータであり得るか、または２次ディスプレイに行くように意図され得る（たとえば、リモートディスプレイのみに向けられるビデオデータ）。説明した技法を使用して、所望のピクセルデータが任意のメディアプロセッサからキャプチャされ得、次いで圧縮情報に変換され得、圧縮中に実行される従来の動き予測なしに送られ得る。
【００２４】
いくつかの状況では、１つのマクロブロックから次のマクロブロックへの変更がないことがある。マクロブロックがそれらのそれぞれの参照マクロブロックから変化しないとき、それらは静的マクロブロックと呼ばれる。マクロブロックが静的であるという指示は、ブロック２３０に示されるようにエンジン２０４によってキャプチャされ得る。ＭＢデータは、圧縮フォーマット（たとえば、ＭＰＥＧ−２）によって認識されるフォーマットに変換され、送信のためにＭＢデータ２３４として出力され得る。タイミングデータ、タイプ（静的マクロブロック（スキップ）、イントラ（Ｉ）、予測（ＰまたはＢ）など）、デルタ情報などを含むマクロブロック２３２に関するさらなる情報が、圧縮フォーマット（たとえば、ＭＰＥＧ−２）によって認識されるフォーマットに変換され、送信のためにＭＢヘッダ情報２３６として含まれ得る。ヘッダ情報は、事実上、動き情報であり、動きベクトル２３８、ＭＢモード２４０（たとえば、予測モード（Ｐ、Ｂ）など）、またはＭＢタイプ２４２（たとえば、新たなフレーム）を含み得る。
【００２５】
図３に、送信のために準備されているＭＢ情報を示す。（ピクセルデータを備える）ＭＢデータ２３４は、変換され、ワイヤレス送信のための発信ＭＰＥＧ−２ビットストリーム中に含まれる前に符号化される。ＭＢヘッダ２３６は、ＭＰＥＧ−２ビットストリーム中に含まれるより前にエントロピーコーディングを通して処理される。
【００２６】
図４に、静的ブロックのための例示的なＭＢヘッダを示す。図４では、ＭＢ１，１はフレーム中の第１のマクロブロックである。図示のヘッダは、ＭＢ  ＩＤ（１，１）、ＭＢタイプ（スキップ）、（ＭＢが静的であるとき、（０，０）として図示される）動きベクトルを含み、参照ピクチャを０として示す。
【００２７】
図２および図３に関して上記で説明したプロセスでは、送信より前の従来の圧縮中に実行される動き予測は減らされるかまたはなくされる。ディスプレイプロセッサ２１２において利用可能なデルタ情報は、一般に圧縮されない。上記のように送信のためにディスプレイプロセッサ２１２からの動きデータが所望される場合、デルタ情報は、圧縮技法（たとえば、ＭＰＥＧ−２）によって理解可能なフォーマットに変換／符号化されるか、または他の方法で処理され得る。変換されると、デルタ情報は、上記で説明したように参照フレームと組み合わせて使用され得る。
【００２８】
動き予測は、従来の圧縮の総複雑性の５０％〜８０％の間にあり得るので、動き予測を除去すると、ビデオデータをワイヤレス送信するときに、効率が改善し、電力消費量が低減し、レイテンシが低減する。
【００２９】
たとえば、（特定用途向け集積回路（ＡＳＩＣ）などの）カスタマイズされたハードウェアにおけるＭＰＥＧ−２符号化は、７２０ｐの解像度でのＨＤ符号化の場合は１００ｍＷ（または１０８０ｐの場合はより一層高い）を消費し得る。デルタＭＰＥＧ−２圧縮のための本明細書で説明する技法は、入力ビデオにおけるエントロピーに比例する圧縮サイクル／複雑性を低減することによってこの数値を著しく減少させ得る。特に、本明細書で説明する技法は、更新を必要としない多数のビデオフレームを利用する。
【００３０】
以下で説明するように、従来、移動が多いと見なされるビデオの場合でも、フレームごとに（コロケートマクロブロック（collocated macroblock）、ゼロ残差（zero residuals）、参照としての前のピクチャの場合のように無移動ベクトル（no movement vector）として定義される）静的である十分に大きい割合のＭＢがある。
【表１】
2013521717.tif 000003
【００３１】
表１に、衛星を介してデジタルＴＶからキャプチャされた、３０個を超える異なる１０分間のシーケンスのサンプリングから生じるデータを示す。サンプリングされたプログラミングから、平均してビデオの６０％が、ディスプレイ上で更新される必要がない静的マクロブロックを含んでいる。また、表１の第３の列に、ニュースおよびアニメーションタイプビデオでは、フレームの８０％以上が時間の８０％以上更新される必要がないことを示す。エンコーダが、更新だけ、またはフレーム全体ではなくフレームの一部分を処理することを可能にすることにより、著しい電力節約が生じ得る。これは、（たとえば、フレームの８０％以上が静的ＭＢを含んでいるとき）初めに一部の時間行われ得る。
【００３２】
かなりの割合のビデオコンテンツがニュースまたはアニメーションのカテゴリー（すなわち、低動き、低テクスチャ）に入る。
【表２】
2013521717.tif 000004
【００３３】
ビデオ処理負荷を最適化（または低減）するためにビデオにおいて適切な冗長性を適用すること、および機構の識別（たとえば、スキップまたは静的情報を使用すること）は、低電力または集積アプリケーションプラットフォームを支援する。
【００３４】
従来の動き予測および補償中に、差分メトリック（絶対値差分和（ＳＡＤ：sum of absolute difference）または２乗差分和（ＳＳＤ：sum of squared difference））が計算される前に、大量のデータがフェッチされ、処理され、精度を改善するために一般に補間される。このプロセスは、所望の一致（最も低い差分またはＳＡＤ）が得られるまで、所与のブロックまたはＭＢのための予測子であり得るすべての候補について繰り返される。参照ピクチャからこのデータをフェッチするプロセスは、時間がかかり、処理遅延および計算能力の主な要因となる。一般に、差分を計算する算術は、消費されるプロセッササイクルの数を低減するためにハンドコードされる。ただし、フェッチされるデータはロケーションが大幅に異なる（複数参照ピクチャ予測が使用される場合、複数のフレームにわたってフレーム中の最も遠いＭＢに最も近い）ことがあり、ＭＢ境界と整合されないことがあるので、メモリアドレス指定が追加のオーバーヘッドを追加する。また、前のＭＢのためにフェッチされたデータは、データフェッチおよびメモリ転送帯域幅のための最適化を制限する現在のＭＢに好適でないことがある。
【００３５】
図５に、本開示の一態様によるデルタ圧縮を示す。ブロック５０２に示すように、フレームバッファ更新を記憶する。ブロック５０４に示すように、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換し、それによって動き予測をバイパスする。
【００３６】
一態様では、装置が、フレームバッファ更新を記憶するための手段と、フレームバッファ更新をハイブリッド圧縮フォーマットの動き情報に変換するための手段とを含む。本デバイスはまた、ユーザ入力コマンドのためのタイムスタンプをキャプチャするための手段と、ユーザ入力コマンドから生じる対応するディスプレイデータをキャプチャするための手段とを含み得る。一態様では、上述の手段は、ディスプレイドライバ１１０、エンジン２０４、フレームバッファ１０８または２１４、メモリ２５２、エンジン拡張２５０、デコーダ２０８、ＧＰＵ２１０、あるいはディスプレイプロセッサ１０６または２１２であり得る。
【００３７】
本開示およびその利点について詳細に説明したが、添付の特許請求の範囲によって規定される本開示の技術から逸脱することなく様々な変更、置換および改変を本明細書で行うことができることを理解されたい。さらに、本出願の範囲は、本明細書で説明するプロセス、機械、製造、組成物、手段、方法およびステップの特定の態様に限定されるものではない。当業者が容易に諒解するように、本明細書で説明する対応する態様と実質的に同じ機能を実行するか、または実質的に同じ結果を達成する、現存するかまたは後で展開される、プロセス、機械、製造、組成物、手段、方法、またはステップは本開示に従って利用され得る。したがって、添付の特許請求の範囲は、それらの範囲内にそのようなプロセス、機械、製造、組成物、手段、方法、またはステップを含むものとする。
【図１】
2013521717.tif 000005
【図２】
2013521717.tif 000006
【図３】
2013521717.tif 000007
【図４】
2013521717.tif 000008
【図５】
2013521717.tif 000009
【国際調査報告】
2013521717.tif 000010
2013521717.tif 000011
2013521717.tif 000012