JP2010051004A - 調和されたリソースの割当てを有するビデオ信号を適応的に復号化するシステムおよび方法 - Google Patents

Abstract

【課題】ビデオを適応的に復号化するシステムおよび方法を提供する。
【解決手段】ビデオを適応的に復号化する方法は、リソースが制限されたモードを開始するべきであるかを決定する工程と、リソースが制限されたモードを開始するべきであるという決定に応答して、受信された映像入力の一部分の復号化に先行する工程を含み、リソースが制限されたモードを開始する工程とを含む。例えば、ビデオの適応的な復号化は、メモリおよび／またはバスバンド幅のリソースの需要が高い期間に、選択されたビデオフレームの復元および再構成に先行する工程を含み得る。
【選択図】図５

Description

（関連出願との相互参照）
本願は、１９９９年１２月１４日に出願された米国仮出願第６０／１７０，９９５号の利益を主張する。同文献全体を本明細書において参考として援用する。

（発明の分野）
本発明は、概してリソースを管理することに関し、具体的には、制限されたリソース下での圧縮されたデジタル映像のデコーディングに関する。

（発明の背景）
デジタル伝送技術が最近発達したことにより、今やケーブルテレビシステムは従来のアナログ放送の映像より相当多くを提供することが可能である。向上したプログラミングを実現する際に、ホーム通信ターミナル（「ＨＣＴ」）（またはセットトップボックスとして公知である）は、映像サービスにアクセスし、利用可能なサービスの迷路にわたって購読者またはユーザをナビゲートする重要なコンピューティングデバイスになった。従来のアナログ放送の映像機能をサポートすることに加え、デジタルＨＣＴ（すなわち「ＤＨＣＴ」）は今、数が増加してゆくビデオオンデマンドなどの双方向デジタルサービスもサポートする。

通常、ＤＨＣＴは、ケーブルテレビネットワークまたは衛星テレビネットワークに接続され、そして、クライアントの場所においてデジタルテレビシステムの機能を提供するために必要なハードウェアおよびソフトウェアを含む。好適には、ＤＨＣＴによって実行される所定のソフトウェアは、ケーブルテレビネットワークを介してダウンロードおよび／または更新される。各ＤＨＣＴは、通常、プロセッサ、通信コンポーネントおよびメモリも含み、テレビまたはパーソナルコンピュータなどの他の表示デバイスに接続される。多くの従来のＤＨＣＴはテレビに外付けされたスタンドアローンのデバイスであるが、当業者であれば理解するように、ＤＨＣＴおよび／またはその機能は、テレビまたはパーソナルコンピュータ内に組み込まれ得る。ＤＨＣＴは、通常、圧縮されたデジタル音声および映像データを受信して、次いで、これをユーザに提示する前に解凍する。

映像圧縮方法は、高精細度テレビ、ビデオオンデマンドおよびマルチメディア通信などのアプリケーション内のデジタル映像信号の帯域幅および格納要件を減少させる。さらに、多重に圧縮されたデジタル映像チャンネルが、ただ一つのアナログ映像チャンネルではなく、一つのトランスポンダーを介して伝送され得る衛星のアップリンク技術において明らかなように、映像圧縮は、放送、衛星およびケーブルテレビ信号の伝送に有用である。

デジタル映像の圧縮方法は、映像シーケンス（すなわち、デジタル化された画像シーケンス）内のデータの冗長を利用することによって行われる。既存の映像符号化規格の場合と同じく、映像シーケンスで利用される冗長には二つの種類、すなわち、空間的冗長および一時的冗長がある。これらの規格の説明は、以下の出版物において見受けられ得、これらの出版物を本明細書において参考として援用する。これらの出版物は、（１）ＩＳＯ／ＩＥＣ国際基準ＩＳ１１１７２−２、「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｆｏｒ ｄｉｇｉｔａｌ ｓｔｏｒａｇｅ ｍｅｄｉａ ａｔ ｕｐ ｔｏ ａｂｏｕｔ １．５Ｍｂｉｔｓ／ｓ−Ｐａｒｔ２：ｖｉｄｅｏ」（１９９３年）、（２）ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６２（１９９５年）「Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ：ｖｉｄｅｏ」（ＩＳＯ／ＩＥＣ１３８１８−２）、（３）ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６１（１９９３年）「Ｖｉｄｅｏ ｃｏｄｅｃ ｆｏｒ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ ａｔ ｐｘ６４ｋｂｉｔｓ／ｓ」、（４）Ｄｒａｆｔ ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６３（１９９５年）「Ｖｉｄｅｏ ｃｏｄｅｃ ｆｏｒ ｌｏｗ ｂｉｔｒａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ」である。

動画専門家グループ（ＭＰＥＧ）によって開発された最も重要な規格のうちの一つはＭＰＥＧ−２規格である。ＭＰＥＧ−２の映像仕様は三つの主な画像の種類：イントラフレーム（Ｉフレーム）、予測フレーム（Ｐフレーム）および双方向フレーム（Ｂフレーム）を用いる。Ｉフレームは、基準画像とは無関係に各マクロブロックの内部の空間的冗長を利用することによって圧縮される。連続した画像のうちの第一の画像がＩフレームである。Ｐフレームは、マクロブロックが過去の基準画像からその値を予測することによって圧縮され得る画像である。過去の基準画像は、現在の画像の前に再構築されて表示されるＩフレームまたは別のＰフレームのいずれかの画像である。

過去の基準画像内の情報を用いて、ＰフレームまたはＢフレーム内のマクロブロックが予測される。Ｐフレーム内の各マクロブロックは、場合によっては、再構築された過去の基準画像内の１６×１６ピクセル領域を示す。したがって、Ｐフレームは、Ｉフレームより解凍するためにより広いバス帯域幅を必要とする。なぜならば、映像デコーダは、場合によっては、メモリ内に保存された基準画像から、１６×１６ピクセル領域または二つの１６×８ピクセル領域に対応するデータにアクセスする必要があるからである。Ｐフレームは、Ｉフレームより解凍するためにより多くのメモリを消費する。なぜならば、過去の基準画像はメモリ内の解凍の間に保存される必要があるからである。

７２０×４８０のＰフレーム内の各マクロブロックに関して、動き補償が用いられ、メモリ内の各ピクセルが平均１．５バイトで格納された場合、一秒あたり３０画像で、１６×１６の予測子のブロックを取り出すバス帯域幅の要件は一秒あたり１５，５２０，０００バイトである。しかし、各マクロブロックがメモリ内のデータの組織に応じて二つの１６×８のブロックの予測子を用いてエンコーディングされる場合、消費されるバス帯域幅は、場合によっては、一秒あたり３１，１４０，０００バイトと二倍にされる。ＰＡＬで圧縮された画像に関して、画像の解像度が７２０×５７６であるため、より広いバス帯域幅が消費される。

Ｂフレーム内のマクロブロックは、過去の基準画像および未来の基準画像の両方を参照して圧縮が可能である。未来の基準画像は、現在の画像の後に表示されるＩフレームまたはＰフレームのいずれかの画像である。ＩフレームおよびＰフレームは、Ｂフレーム内の動き補償に対する基準画像として機能する。基準画像のうちの一つは過去の基準画像であり、もう一方は未来の基準画像である。未来の基準画像は、中間のＢフレームが映像デコーダによって解凍されて表示され得る前に伝送される。この情報がＢフレームの解凍用の映像デコーダに利用可能となるように、未来の基準画像が目標とされた表示時間の前に解凍されて再構築される。この結果、ＭＰＥＧ−２の映像での画像が、画像が表示される順序ではなく解凍されて再構築されなければならない順序で、圧縮された映像ストリーム内で指定される。解凍および表示デバイスの機能のうちの一つは、適切な表示の順序で画像を表示することである。

Ｂフレームは、Ｐフレームよりも解凍するためにより多くのメモリを消費する。なぜならば、過去の基準画像および未来の基準画像が解凍の間にメディアメモリ内に格納されるからである。Ｂフレーム内の各マクロブロックは、場合によっては、再構築された二つの１６×１６のピクセル領域および四つの１６×８のピクセル領域を基準とする。したがって、Ｂフレームは、ＰフレームおよびＩフレームよりも解凍するためにより広いバス帯域幅を必要とする。なぜならば、映像デコーダが、場合によっては、メディアメモリ内に格納された基準画像から二つの１６×１６のピクセル領域または四つの１６×８のピクセル領域に対応するデータにアクセスする必要があるからである。Ｂフレームは基準画像として機能しない。したがって、Ｂフレームが映像デコーダによって解凍されず再構築されない場合、連続した画像のデコーディングは影響を受けない。

７２０×４８０のＢフレーム内の各マクロブロックが、動きが補償された場合、二つの１６×１６の予測子ブロックを取り出すバス帯域幅の要件は一秒あたり３１，１４０，０００バイトである。各マクロブロックが四つの１６×８のブロック予測子を用いてエンコーディングされた場合、消費されるバス帯域幅は、場合によっては、一秒あたり６２，２８０，０００バイトと二倍にされる。しかし、ＭＰＥＧ−２ストリーム内のすべての画像がＢフレームであるわけではない。ＰＡＬで圧縮された画像に関して、画像の解像度が７２０×５７６であるため、より広いバス帯域幅が消費される。映像デコーダによって解凍された各画像は、メディアメモリ内の画像バッファに書き込まれる。したがって、各解凍された画像の再構築をメモリに書き込むと、一秒あたり１５，５２０，０００バイトのバス帯域幅を消費する。

映像の解凍は、比較的大量のメモリおよび他のリソースの使用を必要とし、そしてこれらのリソースへの多量のアクセスが割り当てられる必要がある。したがって、例えば、限られたメモリおよび限られたバス帯域幅を特徴とするＤＨＣＴなどの消費デバイスは、特にＤＨＣＴ内のメディアの処理が映像処理に必要な限られたメモリ量および／または割り当てられたバス帯域幅の問題に直面する場合、例えば、他のメディアにレンダリングする機能（映像と同時に高解像度のグラフィクスを生成および表示する機能など）を有し得ない。結果として、メディアのグラフィクスの生成および表示が妥協される場合が多い。例えば、減少した映像スクリーンと共に提示される電子番組ガイドは、生成されて、より少ない空間的解像度および／またはより少ない色ビット深さでメモリ内に格納される必要がある場合がある。なぜならば、映像の解凍および高解像度のグラフィクスの提示を収納するだけに十分なメモリおよび／またはバス帯域幅のリソースがない場合があるからである。結果として、より効率的および／または効果的な様態で制限されたリソースを管理するシステムおよび方法が必要である。

（発明の要旨）
本発明の一実施形態は、適応される映像デコーディングのシステムおよび方法を提供する。適応される映像デコーディングの方法は、リソースの制限されたモードが開始されるべきか否かを判定し、受信された映像入力の部分のデコーディングに先行する工程を含め、リソースの制限されたモードが開始されるべきであるという判定に応答してリソースの制限されたモードを開始することを含む。

図１は、本発明の好適な一実施形態によるケーブルテレビシステムのブロック図である。 図２は、図１に示す本発明の好適な一実施形態によるＤＨＣＴおよび関連機器のブロック図である。 図３は、図２に示すＤＨＣＴのシステムメモリコンテンツを示すブロック図である。 図４は、本発明の一実施形態による、データフローおよび相互接続を含む、図２に示すＤＨＣＴのメディアエンジンのブロック図である。 図５は、図２に示すＤＨＣＴのメディアメモリコンテンツを示すブロック図である。 図５Ａは、本発明の一実施形態による、図５に示すメディアメモリの画像バッファのコンテンツを示すブロック図である。 図５Ｂは、本発明の別の実施形態による、図５Ａに示すメディアメモリの画像バッファのコンテンツを示すブロック図である。 図５Ｃは、本発明の別の実施形態による、図５Ｂに示すメディアメモリの画像バッファのコンテンツを示すブロック図である。 図５Ｄは、本発明の別の実施形態による、図５Ｃに示すメディアメモリの画像バッファのコンテンツを示すブロック図である。 図６は、本発明の別の実施形態による、図４に示すメディアエンジンを介した映像データのフローを示すブロック図である。

（好適な実施形態の詳細な説明）
本発明の実施形態は以下の図面を参照するとよりよく理解され得る。図面におけるコンポーネントは、尺度調整して示されず、代わりに本発明の原理を明瞭に示すことに重点が置かれる。図面において、同様の参照符号はいくつかある全図面にわたって対応する部分を示す。

ここで、本発明を、添付の図面を参照しながら以下において完全に説明する。
図面において、本発明の好適な実施形態を図示する。しかし、本発明は、多くの異なる形態で実現され得、そして、本明細書において記載される実施形態に限定されるようには解釈されるべきではない。むしろ、これらの実施形態が提供され、これにより、本開示が、包括的で完全となり、そして、本発明の範囲を当業者に完全に伝える。

本発明は、通常、ケーブルテレビシステム（ＣＴＳ）の部分として実現される。したがって、例示的なＣＴＳ１０およびその動作を最初に説明する。図１は、通常、ＤＨＣＴユーザへの映像、音声、ボイスおよびデータサービスを特徴とする（ｆｅａｔｕｒｅ）高品質で、信頼性があり、統合されたネットワークシステムであるＣＴＳ１０のブロック図を示す。図１がＣＴＳ１０のハイレベルの図を示すが、ＤＨＣＴユーザが世界中のあらゆるところから提供されるコンテンツを受信できるように、複数のケーブルテレビシステムが複数の地域ネットワークと提携して一つの統合されたグローバルネットワークとなり得ることが理解されるべきである。

ＣＴＳ１０は、従来の放送アナログ映像信号を送達することに加え、デジタルにフォーマットされた信号として放送映像信号を送達する。さらに、システムは、一方向の放送サービスと共に、一方向のデータサービスならびに双方向のメディアおよびデータサービスの両方をサポートし得る。双方向のネットワーク動作により、いくつかの公知のＮＶＯＤ実現方法によるペーパービュープログラミング、ニアービデオオンデマンド（ＮＶＯＤ）プログラミング、（いくつかの公知のＶＯＤ実現方法による）ビューオンデマンド（ＶＯＤ）プログラミング、および双方向アプリケーション（例えば、インターネット接続および双方向メディアガイド（ＩＭＧ）アプリケーション）などのサービスとユーザが双方向通信を行うことが可能になる。

ＣＴＳ１０は、インターフェース、ネットワークコントロール、転送制御、セッション制御、ならびにコンテンツおよびサービスにアクセスするサーバも提供し、そして、コンテンツおよびサービスをＤＨＣＴユーザに配信する。図１に示すように、典型的なＣＴＳ１０は、ヘッドエンド１１、ハブ１２、ＨＦＣアクセスネットワーク１７およびユーザのデジタルホーム通信ターミナル（ＤＨＣＴ）１６を含む。一つのコンポーネント（例えば、ヘッドエンド）を図１に示すが、ＣＴＳ１０は例示したコンポーネントのうちのいずれかの複数のコンポーネントを特徴とし得、または個々のコンポーネントのうちのいずれか一つの別の実施形態で構成され得るが、他の追加のコンポーネントは上に列挙されていないことが理解されるべきである。コンテンツプロバイダ（図示せず）は、ネットワーク内のダウンストリームでユーザにさらなる伝送を行うために、メディアコンテンツをヘッドエンドに伝送する。

コンテンツプロバイダによって提供されるコンテンツは、コンテンツプロバイダによって一つ以上のヘッドエンド１１に通信される。次いで、コンテンツは、これらのヘッドエンドから複数のＨＦＣアクセスネットワーク１７（一つのＨＦＣアクセスネットワーク１７のみを示す）を含む通信ネットワーク１８を介して通信される。ＨＦＣアクセスネットワーク１７は、通常、それぞれがローカルな地理的エリアにサービスを提供し得る、複数のＨＦＣノード１３を含む。ハブ１２は、ＨＦＣアクセスネットワーク１７のファイバ部分を介してＨＦＣノード１３に接続する。ＨＦＣノード１３は、ＤＨＣＴ１６に接続されたネットワークインターフェースユニット（ＮＩＵ）１５に接続されたタップ１４に接続される。ＮＩＵ１５は、通常、ユーザのプロパティ（ｐｒｏｐｅｒｔｙ）に設けられ、そして、ＨＦＣノード１３とユーザの内部ワイヤリングとの間で透明なインターフェースを提供する。通常、同軸ケーブルを用いて、ノード１３、タップ１４およびＮＩＵ１５を結合する。なぜならば、電気信号が無線周波数（ＲＦ）増幅器を用いて容易に繰返され得るからである。

ＣＴＳ１０の機能の多くの高レベルの動作は当業者に周知であるため、図１の全体的なＣＴＳ１０のさらなる説明は本明細書において含まない。しかし、図１に示すＣＴＳ１０は単なる例示であると理解されるべきであり、本発明の範囲に対するいかなる限定も意図するものとは解釈されるべきではない。

図２は、ヘッドエンド１１およびテレビ４１に結合されたＤＨＣＴ１６を示すブロック図である。本発明の実施形態をＤＨＣＴの文脈において説明するが、本発明の原理は、例えば、手持ち式のマルチメディアデバイスなどの他の文脈における映像の解凍に適用される。ＤＨＣＴ１６（例えば、メディアオンデマンド（ＭＯＤ）のクライアントアプリケーション７３など）内で実行されるアプリケーションによって実行される所定の機能は、代わりにヘッドエンド１１において実行され得、そして、ヘッドエンド１１において実行されるアプリケーションによって実行される所定の機能は、ＤＨＣＴ１６内で実行され得る。ＤＨＣＴ１６は、通常、ユーザの住宅または仕事場に設けられ、そして、スタンドアローンのユニットであってもよいし、または例えばテレビセットまたはパーソナルコンピュータなどの別のデバイス内に組み込まれてもよい。ＤＨＣＴ１６は、好適には、ヘッドエンド１１からネットワーク１８を介して信号（映像、音声および／または他のデータ）を受信し、ネットワーク１８を介してヘッドエンド１１に任意の逆の情報を提供する通信インターフェース４２、ＱＡＭ復調用の機能を含むデマルチプレクスシステム４３、前方誤り訂正（ＦＥＣ）、転送デマルチプレクスおよびパーサー、および解読器（必要な場合）を含む。ＤＨＣＴ１６は、ＤＨＣＴ１６の動作を制御する少なくとも一つのプロセッサ４４、テレビディスプレイ４８を駆動するメディアエンジン８０、および特定のテレビチャンネルが表示されるように合わせて、かつ、ヘッドエンド１１から種々の種類のデータまたはメディアを送信および受信するチューナーシステム４５をさらに含む。チューナーシステム４５は、一実現において、双方向の四位相偏移変調（ＱＰＳＫ）データ通信用の帯域外チューナーおよびテレビ信号を受信する直交振幅変調（ＱＡＭ）チューナーを含む。さらに、受信機４６は、他のデバイスからのユーザ入力またはコマンドなどの外部で生成された情報を受信する。

ＤＨＣＴ１６は、他のデバイスからデータを受信しおよび／または他のデバイスにデータを伝送する一つ以上の無線インターフェースまたは有線インターフェース（ポートとも呼ばれる）も含み得る。例えば、ＤＨＣＴ１６は、ＵＳＢ（ユニバーサルシリアルバス）、イーサネット（登録商標）（コンピュータへの接続用）、ＩＥＥＥ−１３９４（娯楽センターにおけるメディアデバイスへの接続用）、シリアルポートおよび／またはパラレルポートを特徴とし得る。ユーザ入力は、例えば、ボタンまたはキーが、ターミナルの外部上、またはユーザによって作動されるボタンを含む手持ち式のリモートコントロールデバイスまたはキーボードに設けられたコンピュータまたはトランスミッタによって提供され得る。

図３は、システムメモリ４９内に格納された、選択されたコンポーネントを示すブロック図である。一実現において、システムメモリ４９は、フラッシュメモリ５１および種々のアプリケーションを格納するダイナミックランダムアクセスメモリ（ＤＲＡＭ）５２、プロセッサ４４による実行および使用用のモジュールおよびデータを含む。ＤＨＣＴ１６の基本機能は、主にフラッシュメモリ５１内に保存されたオペレーティングシステム５３によって提供される。中でも、オペレーティングシステム５３は、インターフェースおよび例えばコンピューティングリソースなど、ＤＨＣＴ１６のリソースの協調を提供する少なくとも一つのリソースマネージャー７７を含む。

一つ以上のプログラミングされたソフトウェアアプリケーション（本明細書においてアプリケーションと呼ぶ）は、ＤＨＣＴ１６内のコンピューティングリソースを利用することによって実行される。フラッシュメモリ５１またはＤＲＡＭ５２内に保存されたアプリケーションは、オペレーティングシステム５３の援助の下、プロセッサ４４（例えば、中央処理装置またはデジタル信号プロセッサ）によって実行される。アプリケーションによる入力の際に必要なデータは、ＤＲＡＭ５２またはフラッシュメモリ５１内に保存されて、そして、アプリケーションの実行過程の間に必要に応じてプロセッサ４４によって読み出される。入力データは、二次アプリケーションまたは他のソース（ＤＨＣＴ１６に内蔵または外付けのいずれかである）によってＤＲＡＭ５２内に保存されたデータであり得るか、あるいは、場合によってはアプリケーションによって予期され、したがって、フラッシュメモリ５１内に保存されるアプリケーションがソフトウェアアプリケーションとして生成された時にアプリケーションによって生成されるデータであり得る。アプリケーションによって生成されたデータは、アプリケーションの実行過程の間にプロセッサ４４によってＤＲＡＭ５２内に保存される。ＤＲＡＭ５２は、種々のアプリケーションがデータを保存および／または取り出すための用い得るアプリケーションメモリ７０も含む。

ナビゲータ５５と呼ばれるアプリケーションは、フラッシュメモリ５１内にも常駐して、ＤＨＣＴ１６によって提供されるサービスに対してナビゲーションフレームワークを提供する。ナビゲータ５５は、チャンネルの増減、最後のチャンネル、お気に入りのチャンネルなどのナビゲーショナルキーに関する特定のユーザ入力を登録して、所定の場合には保有する。クライアントアプリケーションは、フラッシュメモリ５１内に常駐してもよいし、ＤＲＡＭ５２内にダウンロードされてもよい。ナビゲータ５５は、ＤＨＣＴ機能（例えば、双方向番組ガイドを提供する機能、チャンネルまたはチャンネルグループがチャンネルメニュー内に表示されるのを阻止する機能、そしてビデオオンデマンド購入リストを表示する機能など）に対応するテレビ関連メニューオプションもユーザに提供する。

フラッシュメモリ５１は、プラットフォームライブラリ５６も含む。プラットフォームライブラリ５６は、アプリケーションに有用なユーティリティー（例えば、タイマーマネージャー、圧縮マネージャー、構成マネージャー、ＨＴＭＬ構文解析、データベースマネージャー、ウィジェットツールキット、ストリングマネージャーおよび他のユーティリティー（図示せず））の集合である。各アプリケーションがこれらのユーティリティーを含む必要がないように、これらのユーティリティーが、必要に応じてアプリケーションによってアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセスされる。図３に示すプラットフォームライブラリ５６の二つのコンポーネントは、ウィンドウマネージャー５９およびサービスアプリケーションマネージャークライアント（ＳＡＭ）５７Ａである。

ウィンドウマネージャー５９は、スクリーン領域およびユーザ入力の共有を実現するメカニズムを提供する。ウィンドウマネージャー５９は、一つ以上のアプリケーションによって関連付けられるように、限られたＤＨＣＴ１６のスクリーンリソースの生成、表示および割り当ての実現にも責任を有する。ウィンドウマネージャー５９により、複数のアプリケーションがスクリーンを共有することがスクリーン領域またはウィンドウの所有権を割り当てることによって可能になる。ウィンドウマネージャー５９はリソースマネージャー７７と通信して、異なるリソース−消費プロセス間で利用可能なリソース（例えば、ディスプレイメモリ）を調整する。このようなプロセスは、一つ以上のアプリケーションによって、直接的または間接的に呼び出され得る。ウィンドウマネージャー５９は、中でも、ＤＲＡＭ５２内のユーザ入力レジストリ５０も維持し、これにより、ユーザがリモートコントロールデバイス８０またはキーボードまたはマウスなどの別の入力デバイスを介してキーまたはコマンドを入力した場合、ユーザ入力レジストリ５０がアクセスされて、ＤＨＣＴ１６上で実行している種々のアプリケーションのうちのどれが入力キーに対応するデータを受信すべきか、およびどの順序でデータを受信すべきかを判定する。アプリケーションが実行される際、アプリケーションは、特定のユーザ入力キーまたはコマンドを受信するリクエストを登録する。ユーザがリモートコントロールデバイス８０上のコマンドのうちの一つに対応するキーを押した場合、コマンドは受信機４６によって受信され、プロセッサ４４に中継される。プロセッサ４４はオペレーティングシステム５３にイベントをディスパッチする。イベントは、最終的には、ユーザ入力レジストリ５０にアクセスし、入力コマンドに対応するデータを適切なアプリケーションにルーティングするウィンドウマネージャー５９に転送される。

ＳＡＭクライアント５７Ａは、クライアント−サーバの対のコンポーネントのうちのクライアントコンポーネントであり、サーバコンポーネントはヘッドエンド１１上に設けられている。ＤＲＡＭ５２内のＳＡＭデータベース５７Ｂは、ヘッドエンド１１によって生成されて更新されるサービスのデータ構造およびチャンネルのデータ構造を含む。多くのサービスは、異なるパラメータによって同じアプリケーションコンポーネントを用いて規定され得る。サービスの例は、本発明を限定せず一実現によって、テレビ番組（ＷａｔｃｈＴＶアプリケーション７２を介して利用可能）を提示するサービス、ペイパービューイベント（ＰＰＶアプリケーション７４を介して利用可能）、デジタル音楽（図示せず）、メディアオンデマンド（ＭＯＤアプリケーション７３を介して利用可能）、双方向番組ガイドを含む。概して、サービスの識別は、サービスが提供されることをアプリケーションに示す一組のアプリケーション依存パラメータと共にサービスを提供する実行可能なアプリケーションの識別を含む。本発明を限定しない例として、テレビ番組を提示するサービスは、ＨＢＯを視聴するための一組のパラメータを用いて実行され得たり、またはＣＮＮを視聴するためのそれぞれの組のパラメータを用いて実行され得る。アプリケーションコンポーネント（映像にチューニングさせるコンポーネント）の各関連および一つのパラメータコンポーネント（ＨＢＯまたはＣＮＮ）は、一意的なサービスＩＤを有する特定のサービスを示す。以下に説明するように、ＳＡＭクライアント５７Ａは、リソースマネージャー７７との間にもインターフェースをつけて、ＤＨＣＴ１６のリソースを制御する。

アプリケーションクライアントは、ＳＡＭクライアント５７Ａのリクエストで（通常、ユーザによるリクエストに応答して、またはヘッドエンドからのメッセージに応答して）ＤＲＡＭ５２内にもダウンロードされ得る。この本発明を限定しない例において、ＤＲＡＭ５２は、種々のアプリケーション（図示せず）の中に、メディアオンデマンドアプリケーション（ＭＯＤ）７３、電子メールアプリケーション７５およびウェブブラウザアプリケーション７６を含む。これらのアプリケーションは本発明を限定せず、本発明のこの現在の実施形態の単なる例として役に立つことが当業者に明らかであるべきである。さらに、一つ以上のＤＲＡＭベースのアプリケーションは、別の実施形態として、フラッシュメモリ５１内に常駐し得る。これらのアプリケーション、およびケーブルシステムオペレータによって提供される他のアプリケーションは、サービスをユーザに提供するネットワーク上のトップレベルのソフトウェアエンティティである。

一実現において、ＤＨＣＴ１６上で実行するアプリケーションは、いくつかのガイドラインに従うことによってナビゲータ５５と協働する。第一に、アプリケーションは、サービスの提供、作動および停止用にＳＡＭクライアント５７Ａを利用する。第二に、アプリケーションは他のアプリケーションとＤＨＣＴ１６のリソースを共有し、そして、ＳＡＭクライアント５７Ａ、オペレーティングシステム５３およびＤＨＣＴ１６のリソース管理政策に従う。第三に、アプリケーションは、リソースがナビゲータ５５の介入によってのみ利用可能な状況を処理する。第四に、アプリケーションがサービスを提供しながらサービスの認可を失う場合に、アプリケーションはＳＡＭ（ナビゲータ５５は後に認可された場合に個々のサービスアプリケーションを再度作動させる）を介してサービスを停止する。最後に、アプリケーションクライアントは、ナビゲータ（すなわち、電力、チャンネル＋／−、音量＋／−など）によって保有された特定のユーザ入力キーへのアクセスを有さないように設計される。

オペレーティングシステム（ＯＳ）コンポーネントまたはクライアントプラットフォームコンポーネントまたはクライアントアプリケーションまたはこれらの各部分に対応する実行可能なプログラムまたはアルゴリズムは、ＤＲＡＭ５２および／またはフラッシュメモリ５１内に常駐するかＤＲＡＭ５２および／またはフラッシュメモリ５１から実行され得る。同様に、任意の実行可能なプログラム内に入力されるデータまたは任意の実行可能なプログラムから出力されるデータはＤＲＡＭ５２またはフラッシュメモリ５１内に常駐し得る。さらに、ＯＳコンポーネントまたはクライアントプラットフォームコンポーネントまたはクライアントアプリケーションまたはこれらの各部分に対応する実行可能なプログラムまたはアルゴリズムは、フラッシュメモリ５１またはＤＨＣＴ１６に接続されたローカルの格納デバイス内に常駐し得、そして実行用にＤＲＡＭ５２内に伝送され得る。同様に、実行可能なプログラムに入力されたデータはフラッシュメモリ５１または格納デバイス内に常駐し得、そして実行可能なプログラムまたはアルゴリズムによる使用用にＤＲＡＭ５２内に伝送され得る。さらに、実行可能なプログラムによって出力されたデータは、実行可能なプログラムまたはアルゴリズムによってＤＲＡＭ５２内に書き込まれ得、そして、格納を目的としてフラッシュメモリ５１または格納デバイス内に転送され得る。本発明は、データおよび／またはアプリケーションがどこでまたはいかに保存または取り出されるかによって制限されない。

上述のアプリケーションのそれぞれは、論理機能を実現するための実行可能な指示を含み、そして、コンピュータベースのシステム、プロセッサを含むシステムまたは指示を取り出して実行し得る他のシステムなどの指示実行システム、装置またはデバイスによって使用されるかまたはこれらと接続した任意のコンピュータ可読メディアで実現され得る。本明細書の文脈において、「コンピュータ可読メディア」は、指示実行システム、装置またはデバイスによって使用されるかまたはこれらと関連したプログラムを含み、保存し、通信し、伝搬しまたは転送し得る任意の手段であり得る。コンピュータ可読メディアは、例えば、電子、磁気、光、電磁、赤外線または半導体のシステム、装置、デバイスまたは伝播メディアであり得る（但し、これらに限定されない）。コンピュータ可読メディアのより具体的な例（包括的なリストではない）は、以下：一本以上のワイヤーを有する電気接続（電子）、携帯のコンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（電子）、リードオンリーメモリ（ＲＯＭ）（電子）、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（電子）、光ファイバ（光）および携帯のコンパクトディスクリードオンリーメモリ（ＣＤＲＯＭ）（光）を含む。プログラムが、例えば、紙または他のメディアを光学走査することによって電子的に取り込まれ、次いで、コンパイル、解釈、またはそうでない場合には適切な様態で処理され、次いで、コンピュータメモリ内に格納され得るため、コンピュータ可読メディアは、紙であってもよく、またはプログラムが印刷される別の適切なメディアであってもよいことに留意されたい。

図４は、本発明の一実施形態によってメディアエンジン８０の選択されたコンポーネントのブロック図を示す。一実施形態において、メディアエンジン８０は、特定用途集積回路（ＡＳＩＣ）である。メディアエンジン８０は、圧縮されたデジタル映像をデコーディングする映像デコーダ８１、およびデジタル映像と関連付けられた圧縮されたデジタル音声をデコーディングする音声デコーダ８２を含む。メディアエンジン８０は、システムメモリ４９からメディアメモリ６０にグラフィカルデータおよびテキストデータを伝送するブロック伝送エンジン（図示せず）（本明細書においてブリッター（ｂｌｉｔｔｅｒ）と呼ぶ）、映像画像のサイズ変更を行う映像取り込みスケーラー８３、およびメディアメモリ６０へのアクセスを制御するプログラム可能なメモリコントローラ（図示せず）（メディアコントローラとも呼ぶ）も含む。一実施形態において、組み込まれたＲＩＳＣプロセッサ（図示せず）または類似の回路部は、メディアエンジン８０内に収納され、そしてメモリコントローラに結合される。組み込まれたＲＩＳＣプロセッサは、メディアエンジン８０内のプログラム可能性の部分を特徴とし、メディアエンジン８０内の種々のコンポーネントを制御し、そして例えば、サービス提供および中断を生成することによって、プロセッサ４４を用いて調整された通信および制御に影響を及ぼすことに役立つ。

メモリコントローラは、メディアメモリ６０にアクセスする各機能コンポーネントまたはプロセスに優先順位を割り当て、したがって、各メディア生成動作またはメディア消費動作に対するバス帯域幅の権利を間接的に制御する事前に割り当てられた優先順位付け方式を満たすようにプログラミングされる。より高い優先度の動作によるリクエストを満たすために、メモリコントローラは、ゆとりのある延期および再開を可能にするより低い優先度のデータ伝送動作を一定間隔で事前に空にする。

一実施形態において、メディアメモリ６０へのアクセスおよび権利などのすべての機能に影響を与える際に、メディアエンジン８０内のメモリコントローラは、メディアエンジン８０内に事前決定されてプログラミングされたような固定の優先度方式の下で動作する。メディアメモリのバス帯域幅を消費する機能コンポーネントのいくつかは、異なって割り当てられた優先度を有し得る一つ以上の種類の動作を実行することが可能である。例えば、ブリッターは、メディアメモリ６０の一つのセクションからメディアメモリ６０の別のセクション、またはメディアメモリ６０からシステムメモリ４９にデータを伝送することが可能である。ブリッター動作のこれらの二つの種類は、例えば、システムメモリ４９からメディアメモリ６０へのブリッターデータ伝送動作より事前に割り当てられた優先度が低い場合がある。

好適には、実行される動作に依存して、メディアエンジン（ｍｅｄｉａ ｅｎｇｉｎｅ）８０は複数の異なった状態、すなわち制約された状態（ｃｏｎｓｔｒａｉｎｅｄ ｓｔａｔｅ）か、または可能な制約された状態のセットからの１状態で動作する。いくつかの実施形態において、メディアメモリ６０へのアクセスおよびエンタイトルメント等のすべての機能が有効な状態で、メディアエンジン８０におけるメモリ制御器は、この特定の状態のためのメディアエンジン８０内に予め決定され、プログラムされたプログラム優先順位スキーマ（ｐｒｏｇｒａｍｍｅｄ ｐｒｉｏｒｉｔｙ ｓｃｈｅｍｅ）を用いて動作する。

好適な実施形態において、メディアメモリバス帯域幅を消費する機能コンポーネントは、映像デコータ８１、音声デコーダ８２、ブリッタ、ビデオ取り込みスケーラ（ｖｉｄｅｏ ｃａｐｔｕｒｅｒ−ｓｃａｌｅｒ）８３、映像デジタル符号器（ｖｉｄｅｏ ｄｉｇｉｔａｌ ｅｎｃｏｄｅｒ）８４（ＤＥＮＣ）、１つ以上のコンポーネントの映像デジタル−アナログ変換器（ＤＡＣ、図示せず）、１つ以上の音声ＤＡＣ（図示せず）、プロセッサ４４、埋込みＲＩＳＣプロセッサ、またはメディアエンジン８０に内蔵された同様の回路、およびメディア制御器を含む。メディア制御器およびＲＩＳＣプロセッサは、通常、ごくわずかなバス帯域幅を使用するが、メディアエンジン８０内で先入れ先出しバッファ（ＦＩＦＯ）９１〜９７を作動させることにより、メモリ−ツー−メモリデータ転送動作を間接的に果たす。ＦＩＦＯ９１〜９７は、データ転送、バーストデータ転送を容易にすること、およびバスアクセスタイミングの調整をするための中間リポジトリとして利用される。

ＤＥＮＣ８４は、ＤＥＮＣの入力において受取られた再構築された映像データをＴＶディスプレイ４８を駆動するアナログ映像信号に転換する。再構築された画像データをメディアメモリ６０からＤＥＮＣ８４に供給するプロセスは、メディア消費動作（ｍｅｄｉａ−ｃｏｎｓｕｍｉｎｇ ｏｐｅｒａｔｉｏｎ）であり、これには、通常、メディアメモリ６０への高（最優先でない場合）優先アクセスが割当てられ、ＴＶディスプレイ４８上のフリッカーを回避する。同様に、音声ＤＡＣ（デジタル−ツー−アナログ変換器）およびすべてのメディア消費動作には、通常、高優先順位が割当てられる。

メディアエンジン８０は、データをメディアメモリ６０からＤＥＮＣ８４に供給し、ＤＨＣＴ１６に接続されたテレビのタイプと一致した、表示ピクセルのラスター走査を生成する。ＮＴＳＣディスプレイについては、ＤＥＮＣ８４は毎秒６０個のフィールドを受取る。各フィールドは、各画像における交流線（ａｌｔｅｒｎａｔｉｎｇ ｌｉｎｅ）の２つのセットのうちの１つを表す。ＭＰＥＧ−２標準の「メイン プロファイル／メイン レベル」により、ＤＥＮＣ８４は、毎秒３０個までのフィールドを受取ることができる。各画像は７２０×４８０ピクセルに匹敵する空間解像度を有し、各ピクセルは平均１．５バイトを必要とする。従って、リフレッシュされたＴＶディスプレイ４８を維持すると、毎秒１５，５２０，０００のバス帯域幅を消費することになる。

図５は、メディアメモリのブロック図である。これは、限定された大きさ（従って、格納容量の拘束を受ける）を有する計算処理リソースであり、異なったデータ成分のリポジトリとして利用される。圧縮されたＭＰＥＧ−２映像ストリームは、圧縮映像バッファ６２として割当てられたメディアメモリ６０のセクションに保管される。同様に、圧縮デジタル音声ストリームは、各圧縮音声バッファ（ＣＡＢ）６１に保管される。音声バッファ（ＡＢ）６９は、音声ＤＡＣに供給される解凍された音声を格納する。画像バッファ３０は、メディアメモリ６０の３つのセクション６３〜６５を含み、各セクションは再構築されたＭＰＥＧ−２画像におけるバイト数と等しい容量を有する。１つのセクションは（Ｉフレーム等の）過去の基準画像を格納し、第２のセクションは（Ｐフレーム等の）未来の基準画像を格納し、第３のセクションは（Ｂフレーム等の）解凍された現在の画像を格納する。

ディスプレイバッファ６６は、プロセッサ４４によって生成されたグラフィックオブジェクト、テキストオブジェクトおよび縮小されたデジタルビデオ画像のリポジトリとして利用される。（グラフィックオーバレイとも呼ばれる）ディスプレイバッファ６６の内容は、活性化されるとビデオ画像の上にオーバレイされる。アルファブレンド面（ａｌｐｈａ−ｂｌｅｎｄ−ｐｌａｎｅ）におけるピクセル値は、（アルファ値によると）ディスプレイバッファ６６における可視ピクセルが不透明になる範囲を示す。換言すると、アルファブレンド面における値は、グラフィックオーバレイが半透明になる範囲を決定する。例えば、アルファブレンド面は、放送会社のロゴを含むグラフィックオーバレイに対応する値を含み得、高いアルファ値は、ロゴを不透明な状態で現わし、中間のアルファ値は、ロゴを半透明な状態で現わす。

ＤＥＮＣの供給中に、メディアエンジンは、ディスプレイバッファ６６およびアルファブレンド面６７に保持される情報により、メディアメモリのディスプレイバッファ６６および画像バッファ３０からの入力データを処理する。ディスプレイバッファ６６からのデータ、および画像バッファ３０からのデータの両方は、メディアエンジン８０内のラインバッファ（図示せず）またはＦＩＦＯ（図示せず）等の一時保管メモリに格納され、３方向出力スイッチ８９において、ディスプレイのために必要とされるクロックドピクセルレートでデータをすぐに利用できるようにする。アルファブレンド面６７は同様に読出され、メディアエンジン８０内の一時的な保管メモリにおいて格納されるので、すぐに利用できる。ディスプレイバッファ６６におけるピクセル値が透明のグラフィックピクセルを表す場合、３方向出力スイッチ８９がセットされ、従って、ビデオピクセルに対応して第１の入力をスイッチの出力に伝搬し、表示されたピクセルはバッファ３０から読出された純粋な映像である。他に、グラフィックピクセルは、３方向出力スイッチ８９を通って伝搬され、アルファブレンド面における対応する空間値によって示される。アルファブレンド面におけるピクセルが不透明グラフィックに関する値を表示す場合、３方向出力スイッチ８９がセットされ、従って、グラフィックピクセルに対応する第２の入力をその出力に伝搬し、表示されたピクセルはディスプレイバッファから読出されたとおりである。他に、半透明ピクセル値は、ディスプレイパイプライン８５における３方向出力スイッチ８９の第３の入力に到着する直前に計算される。このような計算は、アルファブレンド面の対応する位置において格納されたアルファ値に基づく、空間的に対応するグラフィックおよびビデオピクセルの値の重みつき平均である。グラフィックをオーバレイするために用いられる色の深さおよび空間解像度は、ディスプレイバッファおよびアルファブレンド面によって消費されるバイの数およびバス帯域幅に影響を及ぼす。

代替的な実施形態において、アルファブレンド面６７は独立エンティティとしては存在しないが、グラフィック情報における各ピクセルのフォーマットされた仕様の部分である。従って、グラフィックを含むピクセルは、画面外バッファ６８においてオーバレイし、ディスプレイバッファ６６はこれらの各アルファブレンド値を含む。

代替的実施形態において、ビデオＤＥＮＣ８４または音声ＤＡＣ、あるいはこの両方は、メディアエンジン８０の「外部」にあり得るか、またはメディアエンジンに「内蔵され」得る。他の実施形態において、ビデオＤＥＮＣ８４および音声ＤＡＣの複数のセットが存在し、異なったＭＰＥＧ−２プログラムに対応して、各セットには再構築されたデジタルメディアが供給される。さらに、上述の機能成分のいずれも、メディアエンジン８０内またはメディアエンジンの外部に配置され得る。

映像デコータ８１には、システムメモリ４９からメディアメモリ６０への任意の転送動作よりも、メディアメモリ６０への高い優先順位アクセスが割当てられる。従って、プロセッサ４４により生成されたグラフィックオブジェクトおよびテキストオブジェクトは、バス帯域幅が狭くメモリの割当てが制限されるという条件のもとで、メディアメモリ６０への制限されたバス帯域幅に影響を受ける。さらに、ＤＨＣＴ１６のメモリが制限されることにより、グラフィックオーバレイの色の深さおよび空間解像度は制約される。空間解像度は、ビデオ画像解像度の水平方向および垂直方向の寸法の比例関係に制約される。従って、本発明の映像デコータ８１は、２つの状態、すなわち非制約リソース状態および制約リソース状態のうちの１つにおいて動作する。１実施形態において、メディアエンジン８０におけるメモリ制御器は、リソース状態に関係なく予め規定され、メディアエンジン８０内にプログラムされたとおりに固定された優先順位スキーマのもとで動作する。非制約リソース状態において、映像デコータ８１に割当てられるリソースへの高優先順位アクセスは、非妥協（ｎｏｎ−ｃｏｍｐｒｏｍｉｓｅｄ）画質、実寸大ビデオ画像および完全画像レート（ｆｕｌｌ ｐｉｃｔｕｒｅ ｒａｔｅ）をもたらすが、グラフィックオーバレイは潜在的に妥協される。グラフィックオーバレイは、制限された空間解像度および／または色の深さによって維持されるが、メディアエンジン８０におけるディスプレイパイプライン８５回路内のＤＥＮＣ８４への途中でビデオ画像解像度に展開される。これは、ディスプレイバッファ６６およびアルファブレンド面にアクセスする動作によって消費されるバイトの数およびバス帯域幅が低減される結果になる。グラフィックオーバレイの解像度の展開は、水平画像スケーリング回路（ＨＰＳＣ）８７および垂直画像スケーリング回路（ＶＰＳＣ）８６によって達成され、この両方はディスプレイパイプライン８５内に配置される。ディスプレイパイプライン８５内部またはメディアエンジン内の他の場所におけるラインバッファは、一時的なリポジトリメモリとしてスケーリング動作をさせるのに利用される。

制約されたリソースの複数のレベルが存在する。いくつかのシナリオがメモリおよびバス帯域幅に関する制限を抑制し、他のシナリオはメモリの制限を抑制するに過ぎず、さらに他のシナリオはバス帯域幅の制限を抑制するに過ぎない。

「メモリ」制約リソース状態は、映像デコータ８１がより少ないメモリを消費する結果になる。圧縮されたＭＰＷＧ−２ビデオの解凍については、メモリの低減は、Ｂフレームの解凍および再構築を完全に削除することから起こる。これは、メディアメモリ６０において３つのセクションではなく２つのセクションを有する画像バッファを維持することを容易にする。１つのセクションは過去の基準画像を格納するのに用いられ、第２のセクションは復号化された画像を構築するのに用いられる。従って、映像デコータが基準画像のすべてを格納するのに十分なメモリを有しないとき、映像デコータ８１はＩフレームおよびＰフレームのみを解凍する。解凍フレームシーケンスは、潜在的にＦ_１，Ｆ_４，Ｆ_７，Ｆ_１０、Ｆ_１３．．．Ｆ_ｋであり得る。分散型の圧縮されたＢフレームは、基準画像として利用されないので、スキップされる。前の参照フレームは、表示されたフレームシーケンスがＦ_１，Ｆ_１，Ｆ_１，Ｆ_４，Ｆ_４，Ｆ_４，Ｆ_７，Ｆ_７，Ｆ_７，Ｆ_１０，Ｆ_１０．．．Ｆ_ｋであり得るように、スキップされたＢフレームの代わりに表示され得る。Ｂフレームを解凍せずに利用可能にされたメモリリソースは、その後、図４Ｂにおいて示されるように、グラフィックデータまたはテキストデータ等の他のデータを格納するために割当てられ得る。

（例えば、プロセッサ４４による）外部動作は、圧縮ＭＰＥＧ−２映像ストリームおよび圧縮音声ストリームを、メディアメモリ６０に配置された圧縮ビデオバッファ６２（ＣＶＢ）および圧縮音声バッファ６１（ＣＡＢ）に保管する。ＣＶＢ６２およびＣＡＢ６１は、外部動作により満たされ、映像デコータ８１および音声デコーダ８２の各々により消費されるサーキュラーバッファエンティティである。ＣＶＢ６２内の圧縮されたＭＰＥＧ−２ビデオ画像は、ＭＰＥＧ−２ビデオシンタクスおよび記号論規則に準拠して指定される。各圧縮画像の画像レベルにおけるＭＰＥＧ−２映像ストリームシンタクスによって指定された情報は、画像の解凍がスキップされるべきときであっても、映像デコータ８１によって読出される。例えば、画像ヘッダおよび画像コード拡張内（ｐｉｃｔｕｒｅ ｃｏｄｉｎｇ ｅｘｔｅｎｓｉｔｏｎ）に指定された情報は各画像ごとに解釈される。このようにして、映像デコータ８１はバイトの数を決定し、ＣＶＢ６２内に移り、次の圧縮ビデオ画像の開始部分を見つける。各画像の画像レベルの仕様における他の適切な情報も、映像デコータ８１の動作中に必要に応じて解釈される。

「メモリおよびバス帯域幅」制約リソース状態および「メモリ」制約リソース状態において、映像デコータ８１は、より低いレートでビデオ画像を生成するので、グラフィックオーバレイは、より高い空間解像度および／または色の深さによって維持され、バイトおよびバス帯域幅の数がより多く消費される（すなわち、４倍多い）という結果になる。映像デコータ８１は、Ｂフレームの解凍および再構築を差し控える。映像デコータ８１は、Ｂフレームを保持するために用いられる画像バッファのセクションを放棄し、その後、図４Ｂにおいて示されるように、グラフィックオーバレイおよびアルファブレンド面のために、全体または部分的に割当てられる。結果として、グラフィックオーバレイまたはアルファブレンド面、あるいはこの両方は、より高い空間解像度および／または色の深さを有するメモリで表される。さらに、Ｂフレームを解凍および再構築することで消費されるバス帯域幅は、グラフィックオブジェクトおよびテキストオブジェクトを生成または消費する動作のために集められる。

これらのタイプの制約されたリソース状態の両方において、画像はそのもとの空間解像度で表示され得るが、リソース制約状態を起こす最も一般的な原因は、グラフィックカラー画面に埋込まれた画像として現れる縮小されたビデオ画像を表示するアプリケーションである。基本的に、ビュアーの相互通信は、ディスプレイをコンピュータのようなメディアの提示（ｐｒｅｓｅｎｔａｔｉｏｎ）のような状態にさせる。制約されたリソース状態が読出されると、映像デコータ８１はメモリおよびバス帯域幅に関して制約し、グラフィックオブジェクトおよびテキストオブジェクトを同時に表示する必要性によって果たされるような消費を必要に応じて低減する。適応は固定されず、動的に調整される。本明細書中で明らかになるように、新しいシステムは、映像デコータ８１のメモリの必要性を低減して、圧縮デジタルビデオを復号化することによって、および／または他のメディア生成動作のバス帯域幅の必要量によって圧縮デジタルビデオ画像を復号化することによって適応する。好適な実施形態において、映像デコータ８１は、ＭＰＥＧ−２ビデオ符号器によって圧縮されたＭＰＥＧ−２映像ストリームを解凍する。このビデオ符号器は、ストリームをストリームにおける映像の画像レートおよび／または空間解像度を後から低減する可能性を考慮することなくストリームをコード化する。

費用効果的なマルチメディアシステムは制限されたリソースを有するので、好適な発明のシステムは、２つのリソース割当て状態が交互に動作することによって、ビデオ画質と、グラフィックオブジェクトの質およびテキストオブジェクトとの間に均衡を提供する。潜在的に（すなわち、必ずしもそうでない）妥協されたグラフィックの質を有するフルスケール、フルレートの画像再生は、受動的なテレビ視聴の間に提供される。従って、受動的なテレビ中心視聴期間（ｔｅｌｅｖｉｓｉｏｎ−ｃｅｎｔｒｉｃ ｖｉｅｗｉｎｇ ｐｅｒｉｏｄｓ）の間、ビデオ画像は劣化されない。しかしながら、ビュアーがＤＨＣＴ１６との双方向通信を開始すると、ＤＨＣＴ１６はグラフィックオブジェクトおよびテキストオブジェクトを有する縮小された画像解像度の組成の表示を要求し、ビュアーは、よりコンピュータ中心（ｃｏｍｐｕｔｅｒ−ｃｅｎｔｒｉｃ）の双方向通信を経験させられ、この経験において画像の劣化は容認可能であり、習慣的になることが多い。

注目すべきは、新しい方法が人の視覚系の能力と一貫してマッピングされることである。制約されたリソース状態において、縮小されたビデオ画像は動画として表示され続け、表示されたグラフィックオブジェクトおよびテキストオブジェクトは、より長い期間の間、静止した状態で残る傾向がある。それ故、グラフィックオブジェクトおよびテキストオブジェクトに関するアーティファクトは、違いを識別することがより可能な傾向がある。さらに、人の視覚系は、縮小されたビデオに対しては、もとの画像解像度に対してよりも鋭敏でなくなるので、人の視覚系は画像アーティファクトを識別し難い傾向がある。人の視覚系は、さらに、動画における映像アーティファクトを識別し難い傾向がある。なぜなら、網膜において感知された情報は、有限タイムインターバルで統合され、動画レートに従って新しい情報で再び満たされるからである。

メディアエンジン８０におけるホストインターフェースは、プロセッサ４４のインターフェースとして利用される。メディアエンジン８０とプロセッサ４４との間で行なわれる通信および調整はホストインターフェースによる。プロセッサ４４、メディアエンジン８０およびシステムメモリ４９を接続する典型的なデータバスおよびアドレスバスに加えて、ホストインターフェースは、物理割込みライン（ｉｎｔｅｒｒｕｐｔ ｌｉｎｅ）および／または内部番地付け可能レジスタを含む。物理割込みライン（ｉｎｔｅｒｒｕｐｔ ｌｉｎｅ）および／または内部番地付け可能レジスタは周期的に埋込まれたＲＩＳＣプロセッサ、またはメディアエンジン８０に内蔵された同様の回路によってポーリングされる。プロセッサ４４には、さらに、メディアエンジン８０によって、物理割込みラインおよび／または読出し−書込みメッセージレジスタを通って信号が送られる。

プロセッサ４４は、グラフィックオブジェクトおよびテキストオブジェクトを生成し、これらをシステムメモリ４９に格納する。テキストオブジェクトおよびグラフィックオブジェクトは、例えば、ユーザにＥＰＧウィンドを提供する目的の、電子プログラムガイド（ＥＰＧ）アプリケーションの実行によって生成され得る。プロセッサ４４は、その後、ペンディングデータがホストインターフェースによってメディアメモリ６０に転送されることをメディアエンジン８０に通知する。本発明の１実施形態において、プロセッサ４４は、ＤＭＡ（直接記憶アクセス）チャネルを用いて、メディアエンジン８０のメモリ制御器によってアクセスエンタイトルメントが与えられると、オブジェクトをメディアメモリ６０に転送する。

プロセッサ４４は、マルチタスクスキーマ、タスクスケジューリングおよびタスクスイッチングが可能なオペレーティングシステムを実行する。好適な実施形態において、プロセッサ４４は、プリエンプティブリアルタイムオペレーティングシステムを動作する。プロセッサ４４のメディアメモリ６０へのアクセスがエンタイトルメントされると、レジスタへの割込みまたは書込まれたメッセージを介して、メディアエンジン８０によってプロセッサ４４に通知され得る。バックグラウンドタスクが実行され、メッセージを定期的にポーリングする。プロセッサ４４がメディアメモリ６０に送信される用意ができたオブジェクトを生成した場合、このプロセッサがアクセスエンタイトルメントを受取ると、プロセッサ４４はリアルタイムオペレーティングシステムに支援されて、現在のタスクを延期してオブジェクトをシステムメモリ４９からメディアメモリ６０に転送する。連続メモリの小さいセットの位置は、システムメモリ４９から迅速に読出され、メディアエンジン８０における先入れ先出しのメモリ（ＦＩＦＯ）９２および９５内に格納される。メディアエンジン８０は、ＦＩＦＯの内容をメディアメモリ６０におけるディスプレイバッファ６６の指定された領域に転送する。ＦＩＦＯに書込まれたデータがＦＩＦＯ９５からメディアメモリ６０に転送されると、プロセッサ４４は、ＦＩＦＯ９２への次のバースト転送を開始する。プロセスは、オブジェクトに対応するすべてのデータが転送されるまで繰返される。この転送プロセスによって、メディアエンジン８０およびプロセッサ４４は、システムメモリ４９から、メディアメモリ６０におけるディスプレイバッファ６６へのオブジェクトの転送を調整し得るので、必要ならば、データ転送は映像デコータ８１がＢフレームの復号をしない時間中に行なわれる。

ＦＩＦＯ９２および９５は、ストレージの２層（ｄｏｕｂｌｅ ｂａｎｋ）リポジトリとして動作し、システムメモリデータバスおよびメディアメモリデータバスが２つの異なるクロックを動作させる（ｒｕｎ ｏｆｆ）と、透過データ転送を行なう。代替的な１実施形態において、ＦＩＦＯ９２および９５は、システムメモリバスおよびメディアメモリバスの両方が同じクロックを動作させる単一の連続物理ＦＩＦＯを含み得る。

本発明の別の実施形態において、プロセッサ４４は、割込みまたはメッセージを介して、オブジェクトがシステムメモリ４９からメディアメモリ６０への転送の準備ができたことをメディアエンジン８０に通知する。メディアエンジン８０は、ブリッタを使用してオブジェクトを転送する。データ転送動作を開始する直前に、メディアエンジン８０は、ブリッタ動作が実行中であることをプロセッサ４４に通知する。プロセッサ４４のシステムメモリ４９へのアクセスは、ブリッタの転送中により低い優先順位が与えられる。あるいは、プロセッサ４４は、メディアエンジン８０からの未来の通信が、データ転送が完了したことを示すまで、システムメモリ４９にアクセスすることをやめる。注目すべきは、システムメモリ４９へのアクセスの優先順位付と、メディアメモリ６０にアクセスするためのメディアエンジン８０におけるメモリ制御器によって実行されるプログラムされた固定優先順位スキーマとは混同されるべきでない。従って、メディアエンジン８０は、ブリッタデータがシステムメモリ４９からメディアメモリ６０に転送される間、システムメモリ４９アクセスを介して、より高い優先順位を得る。ブリッタは、連続システムメモリ４９の小さいセットの位置を迅速に読出し、これらをメディアエンジン８０のＦＩＦＯ９２および９５に格納する。ＦＩＦＯの内容は、メディアメモリ６０におけるディスプレイバッファ６６の指定された領域に書込まれ、ＦＩＦＯはシステムメモリ４９から読出されたデータで再び満たされる。オブジェクトに対応するすべてのデータが転送されるまで、この動作は継続する。ブリッタの動作が終了すると、メディアエンジン８０は、システムメモリ４９へのそのより高い優先順位アクセスを再構築するようにプロセッサ４４に通知する。

メモリ制御器は、ＴＶディスプレイ４８上でテア（ｔｅａｒ）アーティファクトを生成することから保護するような時宜に適した方法で、メディアメモリ６０におけるシステムメモリ４９からディスプレイバッファ６６へのデータ転送のためのアクセスを認める。データ転送は、ディスプレイバッファ６６からＤＥＮＣ８４にすでに供給されたデータを順序付けした（ｏｒｄｅｒｅｄ）ラスター走査に対応するディスプレイバッファ６６内の位置に行なわれる。換言すると、ディスプレイバッファ６６に書込まれたデータは、常に、読出され、ＤＥＮＣ８４に供給されたディスプレイバッファ６６位置の後ろ（ラスター走査順に）に常に存在する。あるいは、データは、第２のディスプレイバッファ６６に書込まれ得、しばしば画面外バッファ６８と呼ばれる。しかしながら、このアプローチは、さらなるメディアメモリ６０を消費し、さらに、映像デコータ８１のリソースを制限する。画面外バッファ６８、またはその部分は、その後、適切な時間において（例えば、垂直帰線消去ビデオインターバルにおいて）ブリッタを用いてディスプレイバッファ６６に転送される。画面外バッファ６８およびディスプレイバッファ６６は、プログラムを制御しながら交互に作用し得、これによってバス帯域幅を保存する。従って、画面外バッファ６８が、ディスプレイバッファ６６アップデートを含む、すべてのデータおよびオブジェクトで書込まれた場合、画面外バッファはディスプレイバッファになり、ディスプレイバッファは画面外バッファになる。メモリ制御器は、ディスプレイバッファ６６の開始を指すポインタを用い、別のポインタは、画面外バッファ６８の開始を指す。両方のポインタは、メモリまたはメディアエンジン８０内の特定のレジスタに格納される。従って、ディスプレイバッファ６６および画面外バッファ６８を交互に機能させるには、２つのポインタレポジトリの内容がプログラムが制御される状態でスワップされる。

グラフィックオブジェクトおよびテキストオブジェクトは、映像デコータ８１がビデオ画像を復号していないインターバル中に、システムメモリ４９からメディアメモリ６０に転送される。ビデオ画像を復号しない期間は、メディアメモリ６０における圧縮されたビデオバッファ６２内で圧縮されたフォーマットに常駐する１つ以上の圧縮ビデオ画像の解凍を差し控えることを含み得る。従って、メディアエンジン８０とプロセッサ４４との間の通信および調整は、画像がスキップされる期間中にバス帯域幅がより良好に使用されることを可能にする。

システムメモリ４９からメディアメモリ６０にデータを転送することを目的とする通信は、転送されるべきデータを指定することを必要とし、転送されるべきデータオブジェクトの数およびバイトの総数Ｇ_Ｔを含むことを必要とする。各オブジェクトは長方形の領域を占め、メディアメモリ６０におけるディスプレイバッファ６６の範囲内で複写される。従って、オブジェクト仕様は、グラフィックオーバレイの左上ピクセル、長方形の各横方向の線におけるバイトの数および長方形における線の数と関係する長方形の左上ピクセルの位置を含む。

図５Ａは、Ｂフレームの解凍および再構築の停止によって放棄されたメモリ空間６５Ａを表すブロック図である。Ｂフレームの解凍をスキップすることは、ＥＰＧ画面に対応するグラフィックデータまたはテキストデータ等の他のデータを格納するためにメモリ空間６５Ａを利用可能にする。Ｂフレームのスキップは、バス帯域幅、さらなるメモリまたはこれらの両方が必要なために行なわれる。メディアエンジン８０は、Ｂフレームの数を決定し、映像デコータ８１は以下のファクタに基づいてスキップ（すなわち、解凍および再構築ではない）する。すなわち、システムメモリ４９からメディアメモリ６０への転送を達成するように指定されるバイトの数Ｇ_Ｔ、映像デコータ８１によって、空間解像度Ｂ_ＳＩＺＥのＭＰＥＧ−２フレームを解凍および再構築することを必要とされるバス帯域幅ＢＢ_ＲＥＱである。Ｂフレームを解凍するために必要とされる推定されたバス帯域幅は、解凍の複雑さ（例えば、Ｂフレームにおける各マクロブロックは、双方向動き補償を必要とする）の最悪の場合の推定に基づき得るか、または現実的であるが保守的な、従って、経験的に予定された特定の画像の大きさに関する確実な評価に基づき得る。

好適な実施形態において、スキップするＢフレームの数Ｎ_ＳＫＩＰは、先験的
に計算され、Ｇ_ＴおよびＢＢ_ＲＥＱステップ値の異なった組み合わせに関するル
ックアップテーブル（ＬＵＴ）に格納される。ほぼすべてのＭＰＥＧ−２映像ストリームにおいて、基準画像間に分散された連続Ｂフレームの数は２または３であるので、２個のＬＵＴが各々使用される。中間Ｇ_Ｔ値およびＢＢ_ＲＥＱ値は、
Ｎ_ＳＫＩＰ値が、オブジェクトをメディアメモリ６０に転送するのに十分なバス
帯域幅を提供するように、ＬＵＴにインデクスを付けるための最も確実なステップ値に切上げられる。異なったＢ_ＳＩＺＥ値は、ＬＵＴの異なったセットをもた
らし得る。例えば、ＬＵＴまたはＬＵＴのセットは、ＮＴＳＣ圧縮ＭＰＥＧ−２ストリームのために仮編成され得、別のＬＵＴまたはＬＵＴのセットはＰＡＬ圧縮ビデオのためにカスタマイズされ得る。

さらなる実施形態において、ＢＢ_ＲＥＱはＢフレームが解凍される間、映像デ
コータ８１のバス帯域幅消費履歴に基づいて頻繁に計算および更新される。あるいは、バス帯域幅消費は、異なった時間における各テレビチャネルに対する予定されたプログラム内容に基づいて先験的に推定され得る（このアプローチは、定期的放送テレビ番組にとって有用である）。別の代替的実施形態は、ＭＰＥＧ−２トランスポートストリームにおいて、ＭＰＥＧ−２映像ストリームシンタクスに応じて、必要とされるバス帯域幅情報をプライベートデータとして定期的に伝送する。さらに別の実施形態は、必要とされるバス帯域幅情報をＭＰＥＧ−２映像ストリームシンタクスに応じて、各Ｂフレーム内のユーザデータとして定期的に伝送する。例えば、Ｂフレーム（すなわち確実な値）を復号するのに必要とされるバス帯域幅の量、または各Ｂフレームを復号するのに必要なバス帯域幅を指定するテーブルが伝送される。

Ｂフレームに加えて、映像デコータ８１は、Ｐフレームの解凍をスキップすることを必要とし得る。図５ｂは、Ｐフレームの解凍および再構築の停止によって放棄されるメモリ空間６４Ｂを表すブロック図である。ＢフレームおよびＰフレームの解凍をスキップすることは、ＥＰＧ画面に対応するグラフィックデータまたはテキストデータ等の他のデータを格納するのにメモリ空間６５Ａおよび６４Ｂを利用可能にする。しかしながら、このアプローチは画像レートをより劣化させる。Ｐフレームをスキップすることは、バス帯域幅、さらなるメモリ、またはこれらの両方を必要とする原因になり得る。未来の基準画像を保持するために用いられる画像バッファのセクションを放棄することに加えて、過去の基準画像を格納するために用いられるセクションは、必要ならば（例えば、グラフィックオーバレイおよびアルファブレンド面のために）期間の間、放棄され得る。Ｐフレームがスキップされると、再構築に依存するすべての画像は、著しいアーティファクトを用いてスキップされるか、または再構築される。さらに、Ｐフレームは、スキップされた過去の基準画像に依存し、さらに可視の劣化を示す。このために、追加的なリソースを特に必要としない場合、またはＰフレームがＢフレームを含まない映像ストリームの部分であるというのでない場合、Ｐフレームはスキップされない。

一定の条件のもとで、十分なメモリリソースであるが、（高品質のグラフィック映像およびビデオ映像を同時に提供すること等）特定のＤＨＣＴ１６機能を同時に実行するには不十分なバス帯域幅があり得る。バス帯域幅制約リソース状態において、受信されたすべての画像を復号し、それらを低レートで表示するために提供するというよりも、映像デコータ８１は画像をスキップし、ＤＥＮＣ８４は接続されたディスプレイをリフレッシュするのに必要とされる画像（またはフィールド）レートでメディアメモリ６０からの画像を引き続き供給する。それ故、映像デコータ８１は、圧縮ビデオバッファ６２において格納された圧縮映像ストリームにおいて受信されたよりも少ない画像を解凍する。映像デコータ８１による一時的な画像スケーラビリティ（すなわち、画像のスキップ）は、利用可能なバス帯域幅リソースによってリアルタイムで適応される。従って、バス帯域幅制約リソース状態の間、潜在的に、画像は決して劣化され得ない。

プロセッサ４４において実行するいくつかのソフトウェアアプリケーションは、グラフィックオブジェクトおよびテキストオブジェクトを他のソフトウェアよりも少なく生成することが少なく、これによりシステムメモリ４４からメディアメモリ６０にオブジェクトを転送するバス帯域が少なくなる。他のソフトウェアアプリケーションは、時間の全体にわたって、生成されたメディアを異なった量で生成する。その結果、スキップされたＢフレームの数に対する復号されたＢフレームの数は、バス帯域幅への要求により、リアルタイムに適応し得る。表示された画像の実際のセットは、どの画像が映像デコータ８１をスキップするかに依存して、画像間の差は異なり得る。例えば、表示された画像シーケンスは、以下のようであり得る。Ｆ_１，Ｆ_３，Ｆ_４，Ｆ_７，Ｆ_１０，Ｆ_１１，Ｆ_１３，．．．Ｆ_ｋ。本発明の１実施形態において、映像デコータ８１は、ディスプレイバッファ６６およびアルファブレンド面を書込みおよび読出しするための適切なバス帯域幅を提供する手段として、制約されたバス帯域幅モードの間、制限ＭＰＥＧ−２映像ストリームにおいてエンカウンタされる（ｅｎｃｏｕｎｔｅｒｅｄ）ごとにＢフレームを解凍するようにプログラムされる。別の実施形態において、映像デコータ８１は、エンカウンタされた連続するＢフレームをスキップすることと、スキップされたＢフレームの後、連続するＢフレームの予め指定された２次的な数を解凍することが交互になるようにプログラムされ得る。さらに他の実施形態において、切換えは、ディスプレイ順の基準画像間で分散される連続するＢフレームのセット内に限定され得る。さらに別の実施形態において、連続Ｂフレームのセットは、基準画像にわたって広がり得る。

一定の条件のもとで、十分なバス帯域幅であるが（高品質のグラフィック映像およびビデオ映像を同時に提供すること等）特定のＤＨＣＴ１６機能を同時に実行するには不十分なメモリリソースが存在し得る。図５Ｃは、グラフィックデータまたはテキストデータ等の他のデータを格納するためのメモリ空間６５Ｄを利用可能にするためのＢフレームの断片部６５Ｃのストレージを示すブロック図である。

このメモリ制約リソース状態にあるとき、映像デコータ８１はマクロブロックラスター走査順にＢフレームを復号し、メモリにおける縮小された再構築されたデータを格納する（例えば、断片的な水平方向の寸法および／または断片的な垂直方向の寸法が縮小される）。Ｂフレームが各寸法において半分に縮小された場合、バス帯域幅の７５パーセント、およびＢフレームを格納するのに必要とされるメモリの７５パーセントが保存される。（例えば、画像バッファにおける第３の画像の５０パーセントを格納するのに十分なメモリがあるとき）垂直方向の寸応は縮小される必要はあり得ない。解像度が高いほど、およびグラフィックオーバレイのために色の深さが必要とされるほど、リソース制限状態における映像デコータ８１により多くのメモリの制約が課される。

画像バッファにおける低減された空間解像度で維持されるＢフレームは、メディアエンジン８０のビデオ取り込みスケーラ８３におけるＤＥＮＣ８４への途中でもとの画像解像度に拡大される。図６は、ビデオ取り込みスケーラ８３の内部の部分を表す。Ｂフレームの解像度の展開は、水平画像スケーリング回路（Ｈｏｒｉｚｏｎｔａｌ Ｐｉｃｔｕｒｅ Ｓｃａｌｉｎｇ Ｃｉｒｃｕｉｔ）（ＨＰＳＣ８７）および垂直スケーリング画像回路（Ｖｅｒｔｉｃａｌ Ｓｃａｌｉｎｇ Ｐｉｃｔｕｒｅ Ｃｉｒｃｕｉｔ）（ＶＰＳＣ８６）によって達成され、これらの両方はビデオ取り込みスケーラ８３内に配置される。ビデオ取り込みスケーラ８３の出力は出力スイッチ９０に移動され、出力スイッチ９０から入力スイッチ９８に移動される。ビデオ取り込みスケーラ８３（従って、ＨＰＳＣ８７およびＶＰＳＣ８６）は、ＩフレームおよびＰフレームをＤＥＮＣ８４に転送する間、バイパスされるが、低減された空間解像度を用いてＢフレームを展開するために用いられる。

図５Ｄは、メモリ制約状態を示すブロック図であり、Ｐフレームの断片部分６４Ｄはメモリに格納され、Ｂフレームはグラフィックデータまたはテキストデータ等の他のデータを格納するためのメモリ空間６４Ｅおよび６５Ａの各々を利用可能にするためにスキップされる。Ｐフレームは縮小された再構築フォーマットでメモリに格納される。（例えば、画像バッファにおける第３の画像の５０パーセントを格納するのに十分なメモリがある場合）垂直方向の寸法は、縮小される必要はあり得ない。グラフィックオーバレイのために必要とされる解像度および色の深さが大きいほど、リソース制約状態における映像デコータ８１に課せられるメモリの制限はより多い。画像バッファにおいて低減された空間解像度で維持されるＰフレームは、メディアエンジン８０のビデオ取り込みスケーラ８３におけるＤＥＮＣ８４への途中でそれらのもとの画像解像度に展開される。ＨＳＰＣおよびＶＳＰＣは、ＩフレームのＤＥＮＣ８４への転送の間バイパスされるが、低減された空間解像度を有するＰフレームを展開するために用いられる。

好適な実施形態において、映像デコータ８１は、メディアメモリ６０内に２つの基準画像を格納する。この２つの基準画像に関して、一方は、動画像の意図するディスプレイオーダにおいて現在の画像に対する過去の画像であり、他方は、未来の画像である。しかし、当業者は、本発明が、両方の基準画像が過去基準画像である、または、両方が未来基準画像である変形例に適用可能であることを理解する。当業者は、本発明が、１つの基準画像（過去または未来のいずれかの基準画像）しかない変形例に適用可能であることを理解する。当業者は、本発明が、２より多くの基準画像を有する変形例に適用可能であり、過去基準画像および未来基準画像の全ての可能な組み合わせに適用可能であることを理解する。

好適な実施形態において、映像デコータ８１は、リソースが制限されたモードで画像をドロップし得るが、メディアエンジン８０内の音声デコーダ８２による音声復元と音声再生とは、割込みも劣化もなく続けられる。画像速度に関わりなく、表示されるビデオ画像は、それぞれの意図される提示時間（ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅ）（音声と同期する）に対応し続ける。画像を省くプロセスは、消費されるリソースによって動的であるため、新しい方法は、低コストのマルチメディア消費者デバイスの範囲内のエミュレートされた等時性（ｉｓｏｃｈｒｏｎｏｕｓ）メディアチャネルをもたらす。

デジタル音声のクオリティーオブサービス（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）と、グラフィックおよびテキストのオブジェクトの質とは、リソースが制限されたモードで、ビデオ画像速度および／または画像解像度の劣化を犠牲にして維持される。注目すべきは、ビデオフレームが繰り返される間にグラフィックスオーバーレイ内の情報の変化が視聴者に提示され得ること、または、新しいビデオフレームと共に提示され得ることである。

ディスプレイバッファ６６内への規模縮小されたデジタルビデオ画像の挿入は、典型的には、取り込みビデオと呼ばれる。規模縮小されたデジタルビデオ画像は、再構成されたＭＰＥＧ−２ビデオ画像として画像バッファ内に生成され、従って、別のバス帯域幅を消費して、所定の規模縮小された画像速度でディスプレイバッファ６６内へと格納する。

リソースが制限されていないモードで、規模縮小されたデジタルビデオ画像は、メディアエンジン８０によってディスプレイバッファ６６内へと転送される。同期ビデオタイミングおよび内部ＦＩＦＯの使用のもとで、メディアエンジン８０は、ラスタ走査オーダにおいて、再構成されたＭＰＥＧ−２ビデオ画像を画像バッファから読み込み、そのビデオ取り込み器−スケーラー（ｖｉｄｅｏ ｃａｐｔｕｒｅｒ−ｓｃａｌｅｒ）８３の回路を介して画像データを送り込んで規模縮小を実行し、ディスプレイバッファ６６の指定されたセクション内に規模縮小された画像データを格納する。ビデオ取り込み器−スケーラー８３は、おそらく、いくつかのラインバッファ８８に対応する内蔵メモリと共に、水平画像スケーリング回路（ＨＰＳＣ８７）および垂直画像スケーリング回路（ＶＰＳＣ８６）を含み、その結果、規模縮小操作を実行する。

上記のように、リソースが制限された状況を引き起こす最も一般的な原因は、
規模縮小されたビデオ画像を表示するアプリケーションであり、この規模縮小されたビデオ画像は、グラフィックカラー画面内に埋め込まれた画像として現れる。図６は、メディアメモリ６０の画像バッファ内に格納されている再構成された画像を、ＤＥＮＣ８４内へと送り込み、送信中の画像の空間的解像度を規模縮小する様子を示すブロック図である。データの送り込みは、メディアエンジン８０内のスイッチ（図６に示さず）によって引き起こされる。図４に示されるように、ビデオ取り込み器−スケーラー８３の出力は、出力スイッチ９０にルーティングされ、出力スイッチ９０から入力スイッチ９８へとルーティングされ、３方向出力スイッチ８９を通過して、ＤＥＮＣ８４へとルーティングされる。このアプローチは、リソースが制限されたモードにおけるデータバス帯域幅の消費を減少させ、上記の実施形態と組み合わせて使用され得るか、または、別個に使用され得る。指定された提示時間に表示される準備ができている、復号化された画像は、１ラインずつメディアメモリ６０から読み込まれ、ビデオ取り込み器−スケーラー８３内の水平画像スケーリング回路（ＨＰＳＣ８７）に転送され、ここで、スケーリングされ、ＤＥＮＣ８４を駆動させるビデオクロックのタイミングによってＤＥＮＣ８４内へと出力される。

垂直スケーリングは、選択されたビデオ画像ラインの読み込みおよび表示を無視することにより都合よく実施され得る。このアプローチはさらに、メディアメモリのバス帯域幅の消費を減少させる。あるいは、いくつかのラインバッファ８８に対応する内蔵メモリを有する垂直画像スケーリング回路（ＶＰＳＣ８６）は、ＨＰＳＣ８７の出力の結合されて、垂直画像スケーリングを実行する。本発明の一実施形態において、ＨＰＳＣ８７およびＶＰＳＣ８６は、ビデオ取り込み器−スケーラー８３内に常駐する。ビデオ取り込み器−スケーラー８３の出力に結合されたスイッチは、規模縮小された画像が、メディアメモリ６０に書き込み返されるか、または、ＤＥＮＣ８４へと送り込まれるかを制御する。

メディアメモリ６０内に格納されている復号化された画像から直接出力することにより、別のバス帯域幅が節約される。この画像は、他の表示されているオブジェクトと合成されるためにメディアメモリ６０内のディスプレイバッファ６６へと転送されることを回避する。新しい方法は、十分に速い速度で、メディアメモリ６０内の復号化された画像バッファから画像を読み込み、元のビデオ信号クロックと共にＤＥＮＣ８４を駆動させ続けるが、元の空間的な画像解像度内の所望のプログラム可能な位置に、規模縮小されたビデオ画像を配置する。復号化された画像は、ビデオの水平同期信号と同期するタイミングでメディアメモリ６０から読み出され、トランスペアレントなピクセル値は、矩形ビデオディスプレイウィンドウに対応するグラフィックスオーバーレイの各ピクセルロケーションにおいて特定される。グラフィックスオーバーレイ内の矩形ウィンドウの大きさおよび位置は、それぞれ、ＤＥＮＣ８４内へと送り込まれて配置される規模縮小されたビデオ画像の２−Ｄの空間的な大きさおよび位置と一致する。グラフィックスオーバーレイおよびアルファブレンド平面内の他の位置において、全てのピクセルロケーションは、不透明な値を示す。

メディアエンジン８０は、グラフィックスオーバーレイの不透明な部分が、スケーリングされていないビデオ画像の上にあるかのように、ビデオ画像の処理と無関係かつ気づかず（ｏｂｌｉｖｉｏｕｓ）に機能する。しかし、実際には、グラフィックオーバーレイ内に、規模縮小されたビデオ画像の位置と一致する穴が生成される。新しい方法は、メディアメモリ６０への規模縮小されたビデオ画像の取り込み（すなわち、転送）を削除し、その結果、ディスプレイバッファ６６内に規模縮小された画像を格納するためにバス帯域幅が削除され、ビデオが取りこまれる場合はＤＥＮＣ８４へと転送させるトランスペアレントなピクセルをディスプレイバッファ６６から読み込まないことにより、さらなるバス帯域幅が削除される。

（２４Ｈｚ圧縮ビデオへの適応）
一実施形態において、本発明のシステムおよび方法は、ＭＰＥＧ−２ビデオシンタックスによって、ディスプレイフィールドオーダに透明に適応し、圧縮プログレッシブ画像（ｃｏｍｐｒｅｓｓｅｄ ｐｒｏｇｒｅｓｓｉｖｅ ｐｉｃｔｕｒｅ）内のフィールド仕様を繰り返すことが可能である。この特性は、結合されたディスプレイを１秒当たり６０フィールド（すなわち、ＮＴＳＣ）で駆動させると同時に、例えば、２４ヘルツの圧縮デジタル映像ストリームに使用され、上記の実施形態と組み合わせて、または、別個に使用され得る。２４フレームビデオを６０フィールド速度へと変換することは、「３：２プルダウン」と呼ばれる周知のプロセスを介して簡単に行われ得る。このプロセスは、２４ヘルツのプログレッシブ画像から３つのフィールドを「引っ張る」工程と、その後、次の２４ヘルツの画像から２つのフィールドを引っ張る工程との間を交互することを含む。

上記のように、映像デコータ８１は、画像の復元が省かれる場合も、圧縮ビデオバッファ６２内の各画像の画像レベルで全ての該当する特定情報を分析する。ＭＰＥＧ−２ビデオシンタックスの規定は、プログレッシブ画像から抽出された下部フィールドの上部が最初に表示されるべきか、および、画像からの２つまたは３つのフィールドが表示のために引っ張られるべきかを特定する。３つのフィールドの表示が特定される場合、最初に表示されるフィールドが２回表示され、２回目は第３のフィールドとしてＤＥＮＣ８４に送り込まれる。

２４ヘルツの圧縮ビデオにおいて、１秒当たりに圧縮される画像が６枚少ない必要があるため、映像デコータ８１は、バス帯域幅のみのリソースが制限される状態（すなわち、ユーザに高品質のビデオおよびグラフィックスを提示するのに十分なメモリがある場合）において、画像の復元を省く必要はない可能性がある。

メモリが制限される場合、メディアエンジン８０は、ディスプレイフィールドオーダに応じ、フィールド仕様を繰り返すが、画像が省かれる場合を除いて、省かれた画像よりむしろ最後に圧縮された画像から、繰り返されたフィールドが生成される。例えば、２４ヘルツの映像ストリームを復元する際、画像は、ディスプレイオーダ内の次の画像が省かれる場合、ディスプレイのために２つまたは３つのフィールドよりむしろ５つのフィールドに寄与し得る。ＤＥＮＣ８４には、依然として、上記のようなフィールドまたはフレームの必要な画像速度が送り込まれている。

上記の方法は、結合されたプログレッシブディスプレイ（すなわち、フィールドよりむしろプログレッシブ画像が送り込まれるディスプレイ）を駆動させる場合は作動しない。異なるプログレッシブ画像から生成された２つのフィールドから構成される画像は、特に、フィールドに寄与する２つの画像の間に散在する画像の復元を省く場合、可視アーティファクトをもたらす。従って、新しい方法は、プログレッシブディスプレイに結合されている場合、ＤＥＮＣ８４へとプログレッシブビデオ画像を送り込む。

（低−遅延−モードおよび繰り返し−フレーム−ディスプレイへの適応）
ＭＰＥＧ−２ビデオシンタックスの規定は、プログレッシブ画像が１回、２回、または３回表示されるべきかを特定する。このモードは、典型的には、ＭＰＥＧの低遅延モードを実行する際に使用され、ＭＰＥＧの低遅延モードは、例えば、ビデオ−オン−デマンドなどのアプリケーションまたはより低いビットレートのビデオアプリケーションに、高速の早送り操作または高速の巻き戻し操作をもたらす。この仕様が、デコーダに余分なバス帯域幅を実際にもたらすことは明白である。画像を複数回表示するための仕様が、Ｂフレームに対して省かれている場合、映像デコータ８１は、最後に圧縮された画像を繰り返すことによりそれに応じる。

（動きジッターおよび空間的不連続性アーティファクトの削除）
一実施形態において、本発明のシステムおよび方法は、圧縮されたインターレースビデオ画像を復元かつ再構成する際に、アーティファクトを削除することが可能である。画像内の全てのラインは、プログレッシブビデオカメラによって時間的に同じインスタンスで取りこまれるが、画像を構成する２つのフィールドの交互のラインは、インターレースビデオカメラによって異なる時間間隔で取り込まれる。フィールドは、インターレースまたはプログレッシブディスプレイへと繰り返されかつ送り込まれるが、画像を生成するカメラによって表現されるように、画像内の動きの意図される時制進行を変更しないように注意しなければならない。

インターレースビデオ画像の動きは、画像シーケンス内の各フィールドと共に進行するこを意図する。各フィールドは、異なる時制画像を表示する。動きジッターアーティファクトは、圧縮画像の復元および再構成を省くと同時に、画像の交互のフィールドを幾度も表示することにより引き起こされる。ビデオ画像内の動きが早いほど、あるフィールドと次のフィールドとの間のオブジェクトの空間的分離はより大きくなる。第２のフィールドによって表現される動きは、オブジェクトを時間的に前進させるが、第１のフィールドが再び表示されると、ビデオ画像内のオブジェクトをその前の空間的ロケーションへと後退させる。この前後のサイクリングによって引き起こされるジッターアーティファクトは、時間が長くなると知覚的に厄介になる（すなわち、より多くの画像が省かれる）。

この動きジッター問題を回避するために、新しい技術が導入される。この新しい技術は、上記の実施形態と共に使用され得るか、または、別個に使用され得る。復元されたインターレース画像内の第１のフィールドは、画像の第１および第のフィールドの両方として、ＤＥＮＣ８４内へと送り込まれる。あるいは、最初に復元される場合、第２のフィールドは複写かつ表示され得る。さらに別の方法として、２つのフィールドの各対応するラインの平均が計算され、平均化されたフィールドが画像の第１および第２のフィールドの両方としてＤＥＮＣ８４内へと送り込まれる。

ＤＥＮＣ８４には、依然として、上記のようなフィールドまたはフレームの必要な画像速度が送り込まれている。プログレッシブディスプレイが駆動させられる場合も、この方法は依然として使用される。なぜならば、ジッターアーティファクトが明示的でないかもしれないが、２つのフィールドをフレーム内へと繋ぎ合わせることによって示される空間的不連続性が可視アーティファクトになるからである。

（アルファブレンド平面からリソースを得る）
本発明の一実施形態において、メモリが制限されたモードおいて必要な場合、
アルファブレンド平面は、打切り、順序ディザー（ｏｒｄｅｒｅｄ−ｄｉｔｈｅｒ）による打切り、または空間的エラー拡散による打切りによって、１ピクセル当たりのビット数がより少ないアルファ−フィールド−深さ（ａｌｐｈａ−ｆｉｅｌｄ−ｄｅｐｔｈ）に変換される。あるいは、アルファ−フィールドは、メモリ内に格納されている小さなルックアップテーブル（ＬＵＴ）にアクセスするインデックスに変換され、ここで、ＬＵＴの各入力は、元の数のビットを含む。従って、フィールドの深さは損なわれないが、支持されるアルファ値はより少なくなる。この代替案は、全体のメモリ消費が少なくなるという結果をもたらすにも関わらず、バス帯域幅の消費が追加されるという結果はもたらし、上記の実施形態と共に使用され得るか、または、別個に使用され得る。

最も制限されている場合において、アルファブレンド平面は、グラフィックスオーバーレイと等しい解像度を有するビットマップに変換される。従って、ビットマップ内のビットの数は、グラフィックスオーバーレイ内のピクセルの数と等しい。各ビットマップのビットは、グラフィックスオーバーレイ内の空間的に対応するピクセルが可視である場合、不透明または半透明のいずれであるかを表す。アルファ−値は、メディアエンジン８０の内部にある単一のレジスタ内に格納され、半透明性の量を決定する。あるいは、２−ビット−マップが使用され、メディアエンジン８０の内部にある３つのレジスタが、２−ビットフィールドによって表される半透明性の３つの状態が示され得る。第４の状態は、不透明性を特定し、レジスタを示すことを必要としない。３つのレジスタは、所望のそれぞれの半透明性のレベルに関して、異なる所定のアルファ−値によってロードされる。

内部のレジスタがアルファ−値を格納する場合、アルファ−値は、メディアメモリ６０から検索されない。従って、アルファブレンド平面がより少ないバス帯域幅によって読み込まれ得るため、この方法は、メモリが制限されたモードおよびバス帯域幅が制限されたモードの両方に適している。

本発明の別の実施形態において、リソースが制限されたモードでアルファブレンド平面を変換するよりもむしろ、アルファブレンド平面は、前述のアルファブレンド平面削減方法のうちの任意の方法によって（すなわち、制限および非制限の両方の状態において）継続的に特定される。

（優先順位付け方式モード）
種々の優先順位割当て方式が、上記の実施形態と共に使用され得る。このような方式のそれぞれは、上記の実施形態と共に使用され得るか、または、別個に使用され得る。本発明の一実施形態において、メディアメモリ６０にアクセスする動きのためにメモリコントローラによって使用される優先順位割当てマップは、時間全体において所定かつ一定である。本発明の別の実施形態において、１セットの状態にわたる各動きサイクルの優先順位の割当ては、ビデオ信号の間隔およびＤＥＮＣ８４を駆動させるクロックの間隔と関連する時間間隔としてはっきり区別される。各サイクル内の間隔の数、すなわち状態の数は、所定かつ一定であり、サイクル自体は固定されている。状態内の優先順位の割当ては、所定かつ一定である。いくつかの動きは、それぞれの優先順位レベルを最も低い優先順位に低下させることにより、状態内で無効にされ得るか、または、効果的に無効にされ得る。サイクルは、垂直帰線間隔（ＶＢＩ）に対応する状態を含み得る、次いで、ライン−リフレッシュ状態、ビデオ信号のそれぞれの間隔に対応する水平−同期状態、ライン−リフレッシュ状態、および画像内の各ラインに関する水平−同期状態を含み得る。

さらに、本発明の一実施形態において、定常優先順位方式または周期的優先順位方式のいずれによって動きする場合も、メモリコントローラは、リソースが制限されていないモードにおいて第１の優先順位割当てマップを実行し、リソースが制限されたモードにおいて第２の優先順位割当てマップを実行する。各優先順位割当てマップは、それぞれの状態の最適化性能のために調整される。本発明の別の実施形態において、メモリコントローラは、リソースが制限されていないモードにおいて定常優先順位方式である第１の優先順位割当てマップを実行し、リソースが制限されたモードにおいて周期的優先順位方式である第２の優先順位割当てマップを実行する。本発明のさらに別の実施形態において、メモリコントローラは、リソースが制限されていないモードにおいて周期的優先順位方式である第１の優先順位割当てマップを実行し、リソースが制限されたモードにおいて定常優先順位方式である第２の優先順位割当てマップを実行する。

上記の機能、プロセス、またはアプリケーションのそれぞれは、論理機能を実施するために実行可能な命令を含み、任意のコンピュータ読み取り可能メディア内に組み入れられ得、命令実行システム、装置、またはデバイス（例えば、コンピュータベースのシステム、プロセッサを含むシステム、または命令を実行し得る別のシステム）によって、あるいは、それらと共に使用される。本出願の中で、「コンピュータ読み取り可能メディア」は、命令実行システム、装置、またはデバイスによって、あるいは、それらと共に使用されるプログラムの包含、格納、通信、伝播、または転送を行い得る任意の手段であり得る。コンピュータ読み取り可能メディアは、例えば、電子、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、デバイス、または伝播メディアであり得るが、これらに限定されない。コンピュータ読み取り可能メディアのより具体的な例（非網羅的なリスト）は以下を含む。１つ以上のワイヤを有する電気接続（電子）、携帯型コンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（電子）、読み取り専用メモリ（ＲＯＭ）（電子）、消去可能プログラム可能な読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）（電子）、光ファイバー（光学）、携帯型コンパクトディスクの読み取り専用メモリ（ＣＤＲＯＭ）（光学）。コンピュータ読み取り可能メディアは、紙または別の適切なメディアでさえもあり得、その上にプログラムが印刷されることに留意されたい。これは、プログラムが、例えば、紙または他のメディアの光学走査によって電子的に取り込まれ、コンパイルされるか、解釈されるか、または適切な様態で処理されて、コンピュータメモリ内に格納され得るからである。

本発明の上記の実施形態、特に任意の「好適な実施形態」は、実施形態の可能な例に過ぎず、本発明の原理の明白な理解を示しているに過ぎないことを強調する必要がある。本発明の原理の精神から実質的に逸脱することなく、本発明の上記の実施形態に多くの変形および修正が行われ得る。このような修正および変形例の全ては、本明細書中の開示の範囲および本発明の範囲内に含まれ、本明細書の特許請求の範囲によって保護されることを意図する。

Claims (24)

1. デジタルホーム通信端末（ＤＨＣＴ）のリソース制限に適応する方法であって、該方法は、
   デジタルホーム通信端末（ＤＨＣＴ)を提供する工程であって、該ＤＨＣＴは、リソース非制限モードおよび複数のリソース制限モードにおいて動作するように構成されている、工程と、
   該複数のリソース制限モードのうちの１つまたは該リソース非制限モードが開始されるべきであるか否かを決定する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであると決定したことに応答して、該決定されたリソース制限モードにおいて該ＤＨＣＴを動作させる工程と
   を含み、
   該決定されたリソース制限モードにおいて該ＤＨＣＴを動作させる工程は、
   メモリコンポーネントの第１の部分から、圧縮を解除され再構成された１組のビデオフレームを取り出す工程であって、該メモリコンポーネントは、圧縮されたビデオフレームを異なる第２の部分に格納し、該１組のビデオフレームは、ビデオピクチャに対応する、工程と、
   表示デバイスへの転送の途中に、該ビデオピクチャをダウンスケーリングしながら、該圧縮を解除され再構成され取り出された１組のビデオフレームを該表示デバイスに転送する工程と
   を含む、方法。
2. デジタルホーム通信端末（ＤＨＣＴ）のリソース制限に適応する方法であって、該方法は、
   デジタルホーム通信端末（ＤＨＣＴ)を提供する工程であって、該ＤＨＣＴは、リソース非制限モードおよび複数のリソース制限モードにおいて動作するように構成されている、工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであるか否かを決定する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであると決定したことに応答して、該リソース制限モードを開始する工程と
   を含み、
   該リソース制限モードを開始する工程は、
   メモリコンポーネントの第１の部分から、圧縮された１組のフレームを取り出す工程と、
   該メモリコンポーネントの第２の異なる部分に、該圧縮された１組のフレームに対応するデコードされた１組のフレームを格納する工程であって、該デコードされた１組のフレームの各々は、第１の空間的解像度である、工程と、
   該メモリコンポーネントの該第２の異なる部分から、該デコードされた１組のフレームを取り出す工程と、
   表示デバイスへの転送の途中に、該デコードされ取り出された１組のフレームを第２の空間的解像度にスケーリングしながら、該デコードされ取り出された１組のフレームを該メモリコンポーネントに格納することなく、該デコードされ取り出された１組のフレームを該表示デバイスに転送する工程であって、該第２の空間的解像度は、該第１の空間的解像度よりも小さい、工程と
   を含む、方法。
3. デジタルホーム通信端末（ＤＨＣＴ）であって、
   リソース非制限モードおよび複数のリソース制限モードにおいて該ＤＨＣＴを動作させるように構成されている論理と、
   該複数のリソース制限モードのうちの１つが開始されるべきであるか否かを決定するように構成されている論理と、
   該複数のリソース制限モードのうちの１つが開始されるべきであると決定したことに応答して、該リソース制限モードを開始するように構成されている論理と
   を含み、
   該リソース制限モードを開始するように構成されている論理は、
   メモリコンポーネントの第１の部分から、圧縮された１組のフレームを取り出すように構成されている論理と、
   該メモリコンポーネントの第２の異なる部分に、該圧縮された１組のフレームに対応するデコードされた１組のフレームを格納するように構成されている論理であって、該デコードされた１組のフレームの各々は、第１の空間的解像度である、論理と、
   該メモリコンポーネントから、該デコードされた１組のフレームを取り出すように構成されている論理と、
   表示デバイスへの転送の途中に、該デコードされた１組のフレームを第２の空間的解像度にスケーリングしながら、該デコードされた１組のフレームを該メモリコンポーネントに格納することなく、該デコードされた１組のフレームを該表示デバイスに転送するように構成されている論理であって、該第２の空間解像度は、該第１の空間解像度よりも小さい、論理と
   を含む、ＤＨＣＴ。
4. デジタルホーム通信端末（ＤＨＣＴ）のリソース制限に適応する方法であって、該方法は、
   デジタルホーム通信端末（ＤＨＣＴ)を提供する工程であって、該ＤＨＣＴは、リソース非制限モードおよび複数のリソース制限モードにおいて動作するように構成されている、工程と、
   メモリコンポーネントにおいて、完全なピクチャを含むビデオフレームを受信する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであるか否かを決定する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであると決定したことに応答して、該リソース制限モードを開始する工程と
   を含み、
   該リソース制限モードを開始する工程は、
   該メモリコンポーネントから該ビデオフレームを受信する工程と、
   表示デバイスへの転送の途中に、該取り出されたビデオフレームをダウンスケーリングしながら、該取り出されたビデオフレームを該表示デバイスに転送する工程と
   を含む、方法。
5. リソース制限に適応するためにデジタルホーム通信端末（ＤＨＣＴ）において用いられるプログラムを含むコンピュータ読み取り可能な媒体であって、該プログラムは、
   デジタルホーム通信端末（ＤＨＣＴ)を提供する工程であって、該ＤＨＣＴは、リソース非制限モードおよび複数のリソース制限モードにおいて動作するように構成されている、工程と、
   メモリコンポーネントにおいて、完全なピクチャを含むビデオフレームを受信する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであるか否かを決定する工程と、
   該複数のリソース制限モードのうちの１つが開始されるべきであると決定したことに応答して、該リソース制限モードを開始する工程と
   を含み、
   該リソース制限モードを開始する工程は、
   該メモリコンポーネントから該ビデオフレームを受信する工程と、
   表示デバイスへの転送の途中に、該ピクチャをダウンスケーリングしながら、該取り出されたビデオフレームを該表示デバイスに転送する工程と
   を実行する論理を含む、コンピュータ読み取り可能な媒体。
6. 前記プログラムは、
   グラフィックスデータを前記表示デバイスに送信する工程であって、該グラフィックスデータは、前記スケーリングされたビデオフレームと同時に表示される、工程
   を実行する論理をさらに含む、請求項５に記載のコンピュータ読み取り可能な媒体。
7. 前記ダウンスケーリングすることは、水平スケーリングすることを含む、請求項５に記載のコンピュータ読み取り可能な媒体。
8. 前記ダウンスケーリングすることは、垂直スケーリングすることを含む、請求項５に記載のコンピュータ読み取り可能な媒体。
9. 前記ダウンスケーリングされたピクチャは、前記メモリコンポーネントに格納されない、請求項５に記載のコンピュータ読み取り可能な媒体。
10. グラフィックスデータを前記表示デバイスに転送する工程であって、該グラフィックスデータは、前記ダウンスケーリングされたピクチャと同時に表示される、工程をさらに含む、請求項１に記載の方法。
11. 前記ダウンスケーリングすることは、水平スケーリングすることを含む、請求項１に記載の方法。
12. 前記ダウンスケーリングすることは、垂直スケーリングすることを含む、請求項１に記載の方法。
13. 該グラフィックスデータを前記表示デバイスに送信する工程であって、該グラフィックスデータは、前記スケーリングされたビデオフレームと同時に表示される、工程
    をさらに含む、請求項２に記載の方法。
14. 前記スケーリングすることは、ダウンスケーリングすることを含む、請求項２に記載の方法。
15. 前記スケーリングすることは、水平スケーリングすることを含む、請求項２に記載の方法。
16. 前記スケーリングすることは、垂直スケーリングすることを含む、請求項２に記載の方法。
17. 前記システムは、
    グラフィックスデータを前記表示デバイスに送信する工程であって、該グラフィックスデータは、前記スケーリングされたビデオフレームと同時に表示される、工程
    を行うようにさらに構成されている、請求項３に記載のＤＨＣＴ。
18. 前記スケーリングすることは、水平スケーリングすることを含む、請求項３に記載のＤＨＣＴ。
19. 前記スケーリングすることは、垂直スケーリングすることを含む、請求項３に記載のＤＨＣＴ。
20. グラフィックスデータを前記表示デバイスに送信する工程であって、該グラフィックスデータは、前記スケーリングされたビデオフレームと同時に表示される、工程
    をさらに含む、請求項４に記載の方法。
21. 前記複数のリソース制限モードは、メモリが制限されたモードと、バス帯域幅が制限されたモードと、メモリおよびバス帯域幅が制限されたモードとを含む、請求項１に記載の方法。
22. 前記複数のリソース制限モードは、メモリが制限されたモードと、バス帯域幅が制限されたモードと、メモリおよびバス帯域幅が制限されたモードとを含む、請求項２に記載の方法。
23. 前記複数のリソース制限モードは、メモリが制限されたモードと、バス帯域幅が制限されたモードと、メモリおよびバス帯域幅が制限されたモードとを含む、請求項３に記載のＤＨＣＴ。
24. 前記複数のリソース制限モードは、メモリが制限されたモードと、バス帯域幅が制限されたモードと、メモリおよびバス帯域幅が制限されたモードとを含む、請求項４に記載の方法。

Images