(57)【特許請求の範囲】
【請求項１】
ＣＰＵ及びバスを使用して、複数のイメージをデコードし表示する方法であって、
所定期間内に、表示サイズを有する複数のウインドウ内に表示するために、前記イメージをデコードし表示する処理に必要とされる前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ及びバス帯域幅の利用可能度を超えることになるか否かを決定するステップと、
前記イメージを表示するために必要とされる前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ及び前記バスがもつ帯域幅の利用可能度を超えることになると決定された場合に、前記複数のウインドウのうちのより大きなウインドウに対してより小さいウインドウのサイズを縮小し、縮小後のウインドウ・サイズを含めて、提案ウインドウ・サイズのセットをビューワに提示するステップと、ユーザのウインドウ・サイズ入力を検出する監視を行うステップと、ユーザのウインドウ・サイズ入力を検出した場合には、入力されたウィンドウ・サイズを使用して前記イメージをデコードし表示する処理に必要な前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ及び前記バスがもつ帯域幅の利用可能度を超えるか否かを判定するステップと、入力されたウィンドウ・サイズを使用して前記イメージをデコードし表示する処理に必要な前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ及び前記バスがもつ帯域幅の利用可能度を超えない場合には、入力されたウィンドウ・サイズを表示ウィンドウ・サイズとして、ユーザのウィンドウ・サイズ入力を検出しない場合には、縮小後のウインドウ・サイズを表示ウィンドウ・サイズとして、前記イメージの少なくとも一部をデコードして表示するステップと、入力されたウィンドウ・サイズを使用して前記イメージをデコードし表示する処理に必要な前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ及び前記バスがもつ帯域幅の利用可能度を超える場合には、直前のフレームとの比較において新しいコンテンツが一定量以上含まれる重要なシーンの変化を検出し、前記重要なシーンの変化を伴わないイメージを表示させないことによって、必要な前記ＣＰＵ処理能力及びバス帯域幅の量をコントロールするステップと、を包含すること
を特徴とする方法。
【請求項２】
請求項１記載の方法であって、
さらに、前記ユーザのウインドウ・サイズ入力によって指定されたウインドウ・サイズを使用して表示するための前記イメージをデコードし表示する処理に必要な前記ＣＰＵ処理能力及びバス帯域幅が、前記ＣＰＵ処理能力及びバス帯域幅の利用可能度を超えることになると決定された場合に、インター‐コーデッド・フレームに対応するデータを検出し、前記インター‐コーデッド・フレームの少なくとも一部に対応するデータを放棄することによって前記ＣＰＵ処理能力及びバス帯域幅をコントロールするステップを包含すること
を特徴とする方法。
【発明の詳細な説明】
【０００１】
（関連出願）
本件出願は、１９９８年１２月１日に出願の係属中の米国特許出願第６０／１１２，０３１号の継続出願であり、当該出願については、特に、参照を通じて本件に採り入れられている。
【０００２】
（発明の分野）
本発明は、イメージのデコードおよび表示を行う方法および装置に関し、より詳細に述べれば、限られたリソースを使用し、同時に表示される複数のイメージをデコードするための方法および装置に関する。
【０００３】
（発明の背景）
テレビジョン・セットおよび、その他多くのビデオ・ディスプレイ・デバイス、たとえばコンピュータ等は、複数のイメージを同時に表示する機能をサポートしている。複数のビデオ・ウィンドウをディスプレイ・デバイスに同時に表示するシステムの一例は、US−A−５，６４２，４９８(KUTNER MICHAEL A)において開示されている。テレビジョン・セットの場合は、同時に複数イメージを表示する機能が、しばしばピクチャ‐イン‐ピクチャ（ＰＩＰ）機能と呼ばれる。コンピュータ・システムの場合は、ウインドウ‐ベースのユーザ・インターフェースをサポートするシステム内において複数のウインドウが同時に開かれるとき、同時の複数イメージの表示がしばしば行われる。
【０００４】
データ・ストレージおよび伝送帯域幅の要件を軽減するために、通常は、伝送および／またはストアに先行してビデオ信号およびイメージ、たとえばディジタル・テレビジョン信号の圧縮が行われる。しかし圧縮後の、たとえばエンコード済みフォームにおいても、ビデオ・イメージは大量のデータを包含するものとなり得る。また表示の前には、通常はこれらのデコードを行わなければならない。イメージのデコーディングには、大量のプロセッシング・リソースが必要になる可能性がある
イメージのシーケンスを包含するビデオ・プログラムの表示が行われているとき、各ウインドウのイメージは、所定のウインドウ内に表示されているイメージ・シーケンスの変化に従って、たとえば表示中のイメージ内における動きに起因して各ウインドウ内のイメージの更新が必要になる。したがって、ビデオ・シーケンスを表示するためには、たとえばフレームによって表現される複数のイメージが所定期間にわたってデコードされ、表示される必要がある。
【０００５】
所定のビデオ・イメージに関して所定時間内に表示されるイメージの数は、しばしばフレーム・レートと呼ばれる。多くの場合、１秒当たりのフレーム数としてこれが表される。単一イメージの表示に必要な時間は、フレーム・タイムと呼ばれる。
【０００６】
テレビジョンの場合、デコーダ回路がリアルタイム・プロセッシング制限を受けることが少なくない。言い換えると、ビデオ・イメージは、イメージの表示に使用されることになる時間と等しいか、それより短い時間内にデコードされなければならない。このリアルタイム・デコーディング要件が満たされない場合には、データ、たとえばフレームの脱落が招かれ、現れた動きが滑らかでなくなることがある。またそれによって、別のイメージ・エラーおよび／またはひずみが惹起されることもあり、見る側にとって好ましくない結果および／または望ましくない結果を招きかねない。
【０００７】
複数のウインドウ内にビデオ・シーケンスが同時に表示されているときには、表示中のビデオ・シーケンス内のすべてのイメージのリアルタイム・デコーディングをサポートするために、デコーダは、平均して、表示中の個々のビデオ・シーケンスの各フレーム・レートの合計に等しいレートにおいて多数のイメージをデコードできなければならない。
【０００８】
複数イメージおよび／またはビデオ・シーケンスの同時表示をサポートすることは、デコーダのプロセッシング・リソースに加えて、そのほかのシステム・リソースにも同様の大きな負担を強いる可能性がある。ビデオ・イメージに関連付けされた、デコーディングのために転送を必要とする大量のデータは、場合によっては、システムの使用可能なバス帯域幅を超えることもあり得る。これは特に、複数イメージをデコードし、同時に表示しなければならないときに問題となる。
【０００９】
デコーダのプロセッシング・リソースおよび／またはバス・リソースの需要は、一定時間内にデコーディングおよび表示を行わなければならないイメージの数の関数となる。ＰＩＰ可能なテレビジョン・システム等のＰＩＰ実施態様の場合においては、デコーダのプロセッシング・リソースおよびバス・リソースの需要がかなりのものとなり得る。
【００１０】
１つのシステム上、たとえばテレビジョンまたはコンピュータ上において、２以上のビデオ・シーケンスが表示されるとき、当該ビデオ・シーケンスのデコードおよび表示に必要となるシステム・リソース、たとえばＣＰＵおよび／またはバスに掛かる合計の負荷が使用可能なリソースを超えると、シーケンス内のイメージが、通常は劣化および／または脱落を生じる。開いているすべてのウインドウ内に表示するべきイメージを完全にデコードできない場合には、１ないしは複数のイメージ・シーケンス内に不自然な動きが招かれることがある。
【００１１】
デコードされたイメージを見る側にとってはこれが不愉快に感じられることがある。それに加えて、表示中のビデオ・シーケンス、たとえばＴＶプログラムを見ている者にとっては、それを追うことが困難になることもあり得る。限られたリソースがもたらすこの種の結果は、単一のスクリーン上において複数のイメージを表示する目的を潜在的に挫折させることになりかねない。
【００１２】
上述した観点から、複数のイメージ、または複数のイメージ・シーケンスのデコードおよび単一ディスプレイ・デバイス上における表示が行われるとき、リソースを割り当てる方法および装置が必要であることは明らかである。また、デコーダ・リソースならびに表示リソースの需要を、たとえば与えられたシステム内において使用可能なレベルまで低減し、あるいは限定することも求められている。
【００１３】
（発明の要約）
本発明は、複数のイメージ・シーケンス、たとえばＴＶプログラムを表すデータを処理し、単一のディスプレイ・スクリーンの異なるウインドウ内に異なるビデオ・シーケンスからの複数のイメージを表示するための方法および装置に関する。本発明の方法および装置を使用して、テレビジョン、コンピュータ、およびイメージを表示するそのほか各種のシステムを実装することができる。
【００１４】
たとえばＴＶプログラムを表すイメージ・データの処理および表示に必要なシステム・リソースの量は、当該プログラムのイメージが表示されるウインドウのサイズの関数になる。本発明によれば、システム・リソースの需要が評価され、使用可能なシステム・リソースの量と比較される。システム・リソースの需要が使用可能なシステム・リソースの量を超えることになるときには、二次的なイメージの表示に使用されている１ないしは複数のウインドウ、たとえば小さい方のＰＩＰウインドウのサイズが縮小されて、１ないしは複数のシステム・リソースに掛かる負担、たとえばプロセッシングまたはバス帯域幅の負担が軽減される。プロセッシング・リソースの需要の評価および表示ウインドウ・サイズの調整は、周期的に、たとえばあらかじめ選択した複数のフレーム・タイムに対応する時間周期で実行することができ、各種の実施態様においてはそのように行われる。
【００１５】
一実施例においては、システムからウインドウ・サイズのセットがユーザに提案される。このとき提案されるウインドウ・サイズは、使用可能なシステム・リソースの超過をもたらさないプログラムのデコードおよび表示を可能にする。ユーザは、提案されたプログラム・ウインドウ・サイズを受け入れるか、あるいはそれを修正することができる。ユーザの入力が使用可能なリソースを超えるシステム・リソースの需要をもたらすものであるときには、インター‐コーデッド・フレーム（フレーム間予測符号化フレーム）に対応するデータが無視され、かつ／または、１ないしは複数の二次的なプログラム内のイメージのデコードおよび表示が、著しいシーンの変化を伴うイメージ、たとえば直前のフレームとの比較において新しいコンテンツが４０％を超えるイメージに制限される。
【００１６】
ＰＩＰ実施態様の１つにおいては、二次的なプログラムを、メインのピクチャ・ウインドウに対して小さいウインドウ内に表示されるプログラムとする。
【００１７】
このように、本発明のテクニックによれば、同時に複数のウインドウ内に表示されるデータの処理を、使用可能なシステム・リソース、たとえばプロセッサまたはバス帯域幅のリソースを超えない態様において行うことができる。
【００１８】
上記の実施態様および特徴に加えて、本発明の方法および装置に係る多数の追加の特徴、実施態様および利点について次に説明する。
【００１９】
（詳細な説明）
前述したように、本発明は、限られたリソースを使用し、同時に表示される複数のイメージをデコードするための方法および装置に関する。
【００２０】
図１は、複数のイメージ・シーケンス、たとえばテレビジョン・プログラムに対応するデータを処理するためのシステム１００を図示している。図３Ａおよび３Ｂに関連して説明を後述するように、異なるプログラムからのイメージを同時に表示することができる。図からわかるように、システム１００は、テレビジョン・プログラム、たとえばディジタル・テレビジョン信号を受信するためのアンテナ１０２を備えている。それに加えてシステム１００は、たとえばキーボードまたはコントロール・パネル等の入力デバイス１０４、中央処理ユニット（ＣＰＵ）１１０、ビデオ・メモリ１３０、ビデオ・ディジタル・アナログ・コンバータ（ＤＡＣ）１３２、ディスプレイ１３４、オーディオ・メモリ１４０、オーディオ・ディジタル・アナログ・コンバータ１４２、およびスピーカ１４４を備えている。システム１００のコンポーネントは、図１に示すように互いに結合されている。
【００２１】
さらにシステム１００は、ペアとして構成されたチューナおよび復調器（１０６，１０８）、（１０６’，１０８’）および（１０６”，１０８”）を包含している。これらのチューナ／復調器のペアは、アンテナ１０２をＣＰＵ  １１０に結合し、チャンネルの選択性を提供する。
【００２２】
図には３つのチューナ／復調器のペアが示されているが、任意数のこれらのデバイスをサポートすることができる。各チューナ／復調器のペアは、随時デコードおよび表示が可能な、ユーザ選択可能であり、かつ異なる、たとえばテレビジョン・プログラムに対応するビデオ・チャンネルをサポートするために使用される。したがって、各チューナ１０６、１０６’、１０６”に対する入力信号は同一であるが、それぞれに対応する各復調器１０８、１０８’、１０８”の出力信号は、通常、ユーザが選択した異なるビデオ／オーディオ・プログラムを表している。
【００２３】
入力デバイス１０４は、たとえばチャンネル選択またはウインドウ・サイズ情報を表すユーザ入力を受け取り、この情報をそれぞれのチューナ／復調器のペア（１０６，１０８）、（１０６’，１０８’）ならびに（１０６”，１０８”）およびＣＰＵ  １１０に供給する。図においては、図示を簡略化する目的から入力デバイス１０４とチューナ／復調器のペア（１０６，１０８）ならびに（１０６’，１０８’）の接続が示されていないが、入力デバイス１０４と、各チューナ／復調器のペア（１０６，１０８）、（１０６’，１０８’）ならびに（１０６”，１０８”）の間に接続が存在することを理解されたい。
【００２４】
ユーザは、第１の通信チャンネルを選択し、かつそれに対応する信号を変調するべくチューナ／復調器のペア（１０６，１０８）をセットすること、第２の通信チャンネルを選択し、かつそれに対応する信号を変調するべくチューナ／復調器のペア（１０６’，１０８’）をセットすること、および第３の通信チャンネルを選択し、かつそれに対応する信号を変調するべくチューナ／復調器のペア（１０６”，１０８”）をセットすることを示す入力情報を、入力デバイス１０４を介して提供する。
【００２５】
ＣＰＵ  １１０は、第１、第２および第３のチューナ／復調器の各ペアからディジタル信号出力を受け取る。受け取ったディジタル信号は、異なるチャンネルに対応するエンコード済みのビデオおよび／またはオーディオのプログラムを表す。各チャンネルに対応する信号は、ＣＰＵ  １１０によって処理され、ディジタル・ビデオ出力信号が生成される。１つのオーディオ出力信号が、３つの入力プログラム信号のうちの１つから生成される。３つのビデオ出力信号のそれぞれは、フレームのシーケンスを表すことが可能であり、それにおいて各フレームは複数のイメージを含み、各イメージは、異なるフレーム用のウインドウに表示され、また、異なるプログラムに対応する可能性がある。
【００２６】
ディジタル・ビデオ出力信号は、フレーム・バッファとして機能するビデオ・メモリ１３０内にストアされる。ビデオ出力信号をフレーム・バッファ内にストアすることによって、複数のビデオ出力信号からのイメージが単一のフレームに合成される。周期的に、たとえばディスプレイ１３４がリフレッシュされるごとに、ビデオ・メモリ１３０内にストアされているフレームがビデオＤＡＣ  １３２に向けて出力される。ＤＡＣ  １３２は、受け取ったディジタル・フレーム・データをアナログ信号に変換し、それがディスプレイ１３４のコントロールに使用され、表示するべきフレームを表すビデオ・イメージが生成される。
【００２７】
複数のプログラムに対応するビデオ・イメージについては、それらを合成し、随時、たとえば異なるプログラム・ウインドウ内に同時に表示することができるが、システム１００が任意の時点において生成し、出力するオーディオ信号は、１つだけになる。そのオーディオ信号は、通常、受信した表示中のプログラムの１つに対応する。ＣＰＵ  １１０によって生成されるオーディオ信号は、オーディオ・メモリ１４０内にストアされる。たとえばオーディオ・メモリ１４０内にストアされたディジタル・オーディオ・データは、その後オーディオＤＡＣ  １４２によってアナログ信号に変換される。このアナログのオーディオ信号は、スピーカ１４４をコントロールするために使用される。
【００２８】
図１の実施態様においては、単一の中央プロセッサ１１０および回路、たとえばそれに包含された内蔵メモリおよび処理回路が使用され、広範なビデオならびにオーディオのデコーディング・オペレーションが実行される。図１の実施態様においては、しばしばコンポーネントとも呼ばれるソフトウエア・ルーチンが使用されており、ＣＰＵ  １１０をコントロールして、各種の逆多重化、ビデオ・デコーディング、ビデオ・スケーリング、ビデオ出力、オーディオ・デコーディングおよびオーディオ出力の機能を実行させている。図１においては、ボックスを用いて、各機能を実行するためにＣＰＵ  １１０によって実行されるソフトウエア・ルーチンまたはコンポーネントを表している。これに代えて、それぞれのルーチンによって実行される各機能を、ＣＰＵ  １１０の内部または外部の専用ハードウエア回路を使用して実装してもよい。したがって、図１の実施態様におけるソフトウエア・ルーチンを使用して実行される機能の１ないしは複数を実行するために専用ハードウエアを含めた実施態様は、本発明の企図しているところであり、その範囲に含まれる。
【００２９】
第１〜第３のデマルチプレクサ・ルーチン１１２、１１２’、および１１２”は、それぞれ逆多重化を担い、それぞれ第１〜第３のチューナ／復調器のペア（１０６，１０８）、（１０６’，１０８’）および（１０６”，１０８”）を介して受信された入力プログラム信号の１つをオーディオ部分とビデオ部分に分離する。
【００３０】
ユーザが選択したプログラム信号の１つのオーディオ信号部分が、デマルチプレクサ１１２、１１２’、および１１２”のうちの１つによってオーディオ・デコーダ・ルーチン１２０に供給される。オーディオ・デコーダ・ルーチン１２０によって生成されたデコード済みオーディオ信号は、オーディオ出力コントローラ・ルーチン１２２のコントロールの下にオーディオ・メモリ１４０にストアされる。出力オーディオ信号は、通常、最大のスクリーン面積を使用してイメージの表示が行われているプログラム、たとえばメイン・ピクチャに対応する。しかしながら、ユーザは、ディスプレイ１３４上に含まれるウインドウの任意の１つに表示されているプログラムに対応するオーディオ出力を随時選択することができる。
【００３１】
前述したようにＣＰＵ  １１０は、デマルチプレクサ・ルーチン１１２、１１２’、および１１２”のコントロールの下に、そこに入力される異なるプログラム信号ごとに、オーディオ／ビデオ逆多重化オペレーションを実行する。図１の実施態様においては、入力されるプログラムが３つあることから、ルーチン１１２、１１２’、１１２”を使用して実行される第１〜第３のビデオ／オーディオ逆多重化オペレーションの結果として、３つのビデオ信号が生成される。
【００３２】
続いて、たとえばビデオ・メモリ１３０内において結合され、１ないしは複数のスクリーン表示が形成されるまえに、第１〜第３の各ビデオ信号の処理が行われる。
【００３３】
つまり、第１〜第３のビデオ・デコーディング・オペレーションがルーチン１１４、１１４’、１１４”を使用して実行され、第１〜第３のイメージ・スケーリング・オペレーションがルーチン１１６、１１６’、１１６”を使用して実行され、さらに、第１〜第３のビデオ出力コントロール・オペレーションがルーチン１１８、１１８’、１１８”を使用して実行される。
【００３４】
第１〜第３の逆多重化オペレーションのそれぞれによって生成されるビデオ信号は、たとえばＭＰＥＧビデオ・ストリームとすることができる。第１〜第３のビデオ・デコーディング・ルーチン１１４、１１４’、および１１４”は、デマルチプレクサ・ルーチン１１２、１１２’、１１２”によって生成された対応する第１〜第３のビデオ信号に対するビデオ・デコーディング・オペレーション、たとえば伸張オペレーションを担う。デコーディング・ルーチン１１４、１１４’、および１１４”は、表示されるイメージを表す第１〜第３のビデオ信号を生成する。デコード後のビデオ信号は、スケーリング・ルーチン１１６、１１６’、１１６”によってスケーリングされる。各イメージは、デコード後のイメージが表示されるウインドウのサイズに対応するサイズにスケーリングされる。ビデオ出力コントローラ・ルーチン１１８、１１８’、１１８”は、スケーリング後のイメージ・データの出力を担い、それにより各プログラム・ウインドウに対応するイメージがビデオ・メモリ内の適切なメモリ・ロケーションにストアされ、その結果、表示時には、ディスプレイ・デバイスのスクリーン上の適切なポジションにそれらが現れることになる。
【００３５】
ＣＰＵ  １１０が実行しなければならない処理の量は、所定期間内に処理および表示が行われるプログラムの数の関数になる。複数のプログラムに対応するイメージがデコードされ、リアルタイムで表示されるとき、たとえば単一スクリーンの異なるウインドウに表示されるとき、イメージのデコーディングおよび表示に関連するプロセッシング負荷が、ＣＰＵのプロセッシング・パワーを超えることがある。それに加えて、ＣＰＵの内部バスまたはＣＰＵとメモリ・デバイス、たとえばビデオ・メモリ１３０もしくはリファレンス・フレーム・メモリ（たとえば図２Ｂのエレメント１１５、１６８を参照されたい）を接続するバスを介した転送を必要とするデータの量が、それらのバスの帯域幅を超えることがある。
【００３６】
図３Ａおよび３Ｂは、本発明に従ってディスプレイ１３４上に生成することができるスクリーンの例を示している。図３Ａにおいては、単一のスクリーン３０２が第１〜第３のウインドウ３０４、３０８、３０６を包含している。これらの各ウインドウは、異なるテレビジョン・プログラムを表示するために使用され、その結果、３つの異なるプログラムからのイメージが同時に表示される。図３Ｂおいては、第１のテレビジョン・プログラムがメイン・ピクチャ・ウインドウ３０４’内に表示され、このウインドウは、スクリーン３０２’の、挿入ピクチャ・ウインドウ３０６’、３０８’によって占有されていない部分を構成する。
【００３７】
図からも認識されようが、図３Ａのディスプレイは、より厳密に言えば、コンピュータを使用するユーザの多くが見慣れているイメージ・フォーマットを模しており、図３Ｂは、より一般的にＰＩＰテレビジョン・セットに使用されているフォーマットを示している。本発明の方法および装置は、図３Ａまたは図３Ｂのスクリーン・フォーマットのいずれにも使用することができる。図３Ａの実施態様においては、各ウインドウ３０４、３０６、および３０８のサイズが、オーバーラップしているウインドウの部分を差し引いていないウインドウの矩形の寸法に対応している。図３Ｂの実施態様の場合は、メイン・ピクチャの表示に使用されているウインドウのサイズが、スクリーン３０２’の矩形のサイズに対応する。一方、挿入ピクチャ・ウインドウ３０６’および３０８’のサイズは、ウインドウ３０６’および３０８’の矩形のサイズに対応している。別の実施態様においては、別のウインドウによって覆われている、つまりオーバーラップしているウインドウの部分をウインドウ・サイズに含めない。
【００３８】
イメージ・データのセットをデコードするために必要となるプロセッシング・リソースの量は、最終的なイメージの表示サイズが小さくなるほど少なくなるという関数として変化し得る。米国特許第５，６１４，９５７号には、ピクチャ‐イン‐ピクチャ表示目的で挿入ピクチャとして表示するためにイメージのデコードを行うときに、ビデオ・デコーダのプロセッシング要件を軽減することができるいくつかの方法が開示されている。それによれば、ビデオ・デコーダのプロセッシング要件は、デコードされているイメージが表示されるウインドウのサイズの関数になる。
【００３９】
イメージ・データのセットをスケーリングするために必要となるプロセッシング・リソースの量は、最終的なイメージの表示サイズが大きくなるほど多くなるという関数となる傾向を持つ。大きなウインドウ内に表示されるイメージをスケーリングする方が、小さなウインドウ内に表示されるイメージより、しばしば多くのプロセッシング・リソースを必要とする。
【００４０】
出力イメージの解像度を同一と仮定すれば、通常は、小さいイメージの方が、大きいイメージよりデータが少ない。したがって、小さいウインドウを使用して表示されるイメージは、一般に、大きいウインドウを使用して表示されるイメージより少ないデータを用いて表現することができる。イメージの表現に使用されるデータの量が少ないほど、所定の時間内に、たとえばビデオ・フレーム・メモリ１３０に対してイメージ・データを転送するために必要なバス帯域幅の量が小さくなる。
【００４１】
上記の観点から、イメージの表示が行われる１ないしは複数のウインドウのサイズを縮小することによって、スケーリングおよび／またはデコーディング・オペレーションを実行するために必要なプロセッシング・リソースを減少できることは明らかである。またバス・リソースの需要、たとえば帯域幅についても、イメージの表示が行われる１ないしは複数のウインドウのサイズを縮小することによって抑えることができる。
【００４２】
図２Ａ〜２Ｃは、本発明の各種実施態様を図示しており、それにおいては、同時に表示される１ないしは複数のウインドウ・サイズが、システム・リソース、たとえばプロセッサ１１０および／またはプロセッサとビデオ・メモリ１３０を結合するバスの需要が使用可能なリソースを超えることのないように調整される。
【００４３】
図２Ａは、本発明の一例のシステム２００を図示しており、この図を参照すると、たとえば異なるプログラムに対応する複数のイメージのデコーディングおよび同時表示のために、効率的にプロセッシング・リソースが割り当てられることを保証するべく、回路が追加されている。
【００４４】
図２Ａの実施態様においては、図１の実施態様のエレメントと同じもしくは類似のエレメントを、図１に使用したものと同じ参照番号を用いて識別している。簡略化を目的とし、その種のエレメントおよびその接続については再度の説明を行わない。
【００４５】
システム２００は、シーン変化検出回路１５６、パラメータ・コントロール回路１５２およびデータベース１５４が追加されている点がシステム１００と異なる。それに加えて、システム２００においては、入力デバイス１０５が、チューナ／復調器のペアのほかにもパラメータ・コントロール回路１５２に対して入力を供給する。また、ここでシステム２００においては、ビデオ・スケーラ・ルーチン１１７、１１７’、１１７”がパラメータ・コントロール回路１５２に応答すること、およびパラメータ・コントロール回路１５２がビデオ・メモリ１３０にアクセス可能なことに注意する必要がある。なお、図２Ａの実施態様においては、シーン変化検出回路１５６およびパラメータ・コントロール回路１５２がハードウエア回路として実装されているが、これらをＣＰＵ  ２１０によって実行されるルーチンとして実装することは可能であり、別の実施態様においてはそのようになっている。
【００４６】
パラメータ・コントロール回路１５２は、システム・リソースの需要が使用可能なリソースを超えないことを保証することが意図された各種のコントロール機能を実行する役割を有する。たとえば、ウインドウ・サイズのセットが与えられた場合の使用可能なシステム・リソースに掛かる負荷を計算するために使用され、必要に応じて使用可能なシステム・リソースに掛かる負荷を軽減するために１ないしは複数のウインドウのサイズを調整し、またシステム・リソースを用いて、有効な時間内に表示予定のすべてのプログラムに対応するすべてのイメージのデコーディングを行うことが不可能な場合には、表示に関するイメージの処理を制限する。
【００４７】
シーン変化検出回路１５６は、シーンの変化、たとえばイメージのコンテンツにおける著しい変化を伴うプログラム・フレームを検出する。これは、本発明に従って、補助的なプログラム・データとして、受信されるＴＶプログラムとともに放送されたシーン変化情報を使用することによって行われる。それに代えて、１ないしは複数の周知のシーン変化検出テクニックを使用して、デコードおよび表示が行われているプログラム内のシーンの変化を検出することもできる。シーン変化検出回路１５６は、パラメータ・コントロール回路１５２に対してシーン変化情報を提供し、それがビデオ・デコーダ・ルーチンおよび／またはビデオ・スケーラ・ルーチンをコントロールし、その結果、少なくとも一部の、著しい変化を伴わないフレームを表すデータが、図５に関連して説明を後述するように、特定の状況の下において無視あるいは等閑視される。
【００４８】
図２Ｂは、本発明に従って実装される別のシステム２０２を示している。システム２０２は、図２Ａのシステム２００に類似である。しかしながらシステム２０２は、システム２００と異なり、デコーディング・ルーチン１１４、１１４’、および１１４”によって使用されるリファレンス・フレーム・メモリ１６８が明示的に示されている。バス１１５は、リファレンス・フレーム・メモリ１６８をＣＰＵ  １１０に接続し、したがってそれにおいて実装されるビデオ・デコーダの機能とも結合される。リファレンス・フレーム・メモリ１６８は、デコーディングの間における動き補償予測オペレーションのために使用することができる。
【００４９】
またシステム２０２は、デコーダおよびコントロール・ルーチン１６２およびオペレーティング・システム１６４のストアに使用されるＲＡＭ  １６０が示されている点においてもシステム２００と異なる。コントロール・ルーチンは、ＣＰＵ  ２１０’を介してパラメータ・コントロール回路１５２’にロードすることができる。ＲＡＭ  １６０は、ハードディスク、ＲＯＭ、フロッピーディスク等の不揮発性ディジタル・ストレージ・メディアを含むものとしてもよい。
【００５０】
ここで、システム２０２においては、ビデオ・デコーダ・ルーチン１１４、１１４’、および１１４”がパラメータ・コントロール回路１５２’に応答し、デコード後のイメージを表示するウインドウのサイズの関数としてデコーディングを実行することに注意が必要である。したがって、図２Ｂの実施態様においては、パラメータ・コントロール回路１５２’が、ビデオ・デコーダ・ルーチンおよびビデオ・スケーラ・ルーチンのいずれか一方もしくは両方に対して、特定のプログラムに関連付けされたウインドウ・サイズが縮小されることを通知することによってプロセッシング・リソース要件を軽減することができる。システム２００の場合と同様に、パラメータ・コントロール回路１５２’は、ＣＰＵ、たとえばＣＰＵ  ２１０’を使用して実装し、メモリ、たとえばＲＡＭ  １６０にストアしているコントロール・ルーチンを実行させてもよい。
【００５１】
システム２０２は、システム２００に存在したシーン変化検出回路１５６に代えて、フレーム・タイプ検出器１５６’を備える。フレーム・タイプ検出器１５６’は、たとえばＤＥＭＵＸ  １１２によって逆多重化されたビデオ・ストリーム内のヘッダ情報をチェックすることにより、フレーム・タイプを検出する。フレーム・タイプ検出器１５６’は、フレーム・タイプ情報をパラメータ・コントロール回路１５２’に供給する。パラメータ・コントロール回路１５２’は、図５に関連して説明を後述するように、特定の状況の下にこの情報を使用し、ビデオ・デコーダおよび／またはスケーラ・ルーチンをコントロールして、特定のフレーム・タイプに対応するデータを無視、放棄、もしくは等閑視する。
【００５２】
図２Ｃに、システム２０４を示すが、機能的にはこれと図２Ａおよび２Ｂは同じである。しかしながら、図２Ｃの実施態様においては、ＣＰＵが除去されている。図２Ｃの実施態様においては、ソフトウエアの使用により実行されていた機能が物理的な回路、たとえばデマルチプレクサ回路３１２、３１２’、３１２”；ビデオ・デコーダ回路３１４、３１４’、３１４”；ビデオ・スケーラ回路３１７、３１７’、３１７”；ビデオ出力コントローラ回路３１８、３１８’、３１８”；オーディオ・デコーダ回路３２０およびオーディオ出力コントローラ回路３２２を使用して実行される。これらの回路は、図２Ｂに示した対応するルーチンと同じ機能を実行し、パラメータ・コントロール回路１５２”に応答する。
【００５３】
図４を簡単に参照すると、データベース１５４のコンテンツの一例が示されている。ここに図示されているように、このデータベースは、イメージのオリジナルのエンコード済みサイズに関係する情報４０２、このイメージを表示した場合に使用される表示ウインドウに関する情報４０４、およびあらかじめ選択した期間、たとえば１ないしは複数のフレーム・タイム内にそのイメージをデコードするために必要な負荷を、たとえばＣＰＵまたはシステム・バス等の使用可能なリソースのパーセンテージを用いて示した情報４０６を含んでいる。データベース１５４の各行は、入力イメージ・サイズ、表示ウインドウ・サイズ、および指定サイズ条件に適合するイメージのデコーディングおよび表示に関連するシステム負荷についての、可能性のある異なる組み合わせを表している。オリジナルのエンコード済みイメージは、水平および垂直の寸法４０８、４１０を用いる形で表すことができる。同様に、表示ウインドウ・サイズも、水平および垂直の寸法４１２、４１４を用いる形で表すことができる。図４には、単一のシステム負荷の列４０６が示されているが、注目する各個別のシステム・リソースについての追加の列、たとえばＣＰＵ付加に関する列およびシステム・バス付加に関する別の列を持たせることも考えられる。データベース１５４内の値は、あらかじめ計算済みの値とすることもできるが、必要に応じて、たとえばＣＰＵ  ２１０により計算した値としてもよく、その場合、続く使用のために計算した値をストアしておけば、リアルタイムでリソース負荷を決定する必要性が回避される。
【００５４】
あらかじめ選択済みの所定の期間内において、ディスプレイ・スクリーン上に表示する予定のイメージのセットをデコーディングするための合計のシステム負荷は、単独の負荷測定がたとえば図４に示すように使用されることを前提とすれば、当該選択済みの所定期間内において表示する予定の各個別のイメージをデコーディングするための負荷の合計として計算することができる。
【００５５】
次に、図５を参照して、イメージのスケーリング、デコーディング、およびプログラム・ウインドウ・サイズをコントロールし、デコーディングおよびその他のイメージ・プロセッシング・オペレーションを実行するシステムのリソースに対する需要が超過しないことを保証する本発明の方法について説明する。図５に示した方法は、図２Ａ〜２Ｃに示したパラメータ・コントロール回路１５２、１５２’、または１５２”によって実装され得る。パラメータ・コントロール回路のコントロールに使用されるコンピュータ実行可能コードのセットは、ＲＡＭ  １６０内にストアしておくことができる。
【００５６】
これに示されるように、本発明のコントロール方法５００は、ステップ５０２から開始する。ステップ５０２においては、表示が予定されているプログラムの数、およびそれらが表示されるプログラム・ウインドウの初期サイズ（表示ウインドウ・サイズ）に関する情報を用いて、パラメータ・コントロール回路１５２が初期化される。この情報は、ユーザ入力から、あるいは、オペレーティングシステム情報にアクセスすることにより得られうる。続いてステップ５０４において１つのシステム・リソースまたは複数のリソースに掛かることになる合計の負荷が、たとえばエンコード済みデータから得られるエンコード済みイメージ・サイズ情報（オリジナル・イメージ・サイズ）、表示ウインドウ・サイズ情報、および／またはレンダリングが予定されるイメージの数に関する情報、たとえば同時に表示が予定されたプログラムの数を使用して計算される。データベース１５４内のデータを使用して、表示が予定されたプログラムまたは一連のプログラム・イメージに関連する負荷を決定することもできる。所定期間、つまり合計の負荷の計算に用いた所定期間にわたるこの合計の負荷は、各プログラムに関連付けされた１ないしは複数のイメージの表示に関する個別の負荷の合計として決定される。単純化のため、例示の実施態様においては、合計の負荷の計算が、もっとも限られたリソース、たとえばプロセッサまたはバスに関して行われる。
【００５７】
それに代えて、各システム・リソースに関して個別のシステム負荷計算を行い、その後、本発明のテクニックを使用してリソースの需要が、システム内にある各種リソースの利用可能度を超えないことを保証することもできる。
【００５８】
合計のシステム負荷が計算されると、オペレーションがステップ５０６に進み、それにおいて、合計の負荷が使用可能なシステム・リソースを超えるか否か、たとえば合計の負荷が１００％より大きくなるか否かについてのチェックがなされる。合計の負荷は１００％より低くなると判断され、検討中の期間内におけるすべてのイメージのデコードおよび表示に充分なリソースが利用可能であることが示されると、オペレーションがステップ５０９に進む。ステップ５０９においては、パラメータ・コントロール回路１５２または１５２’がビデオ・スケーラ、ビデオ・デコーダおよび／またはビデオ・メモリをコントロールし、初期表示ウインドウ・サイズを使用してイメージの処理およびストアを行う。その後オペレーションは、ステップ５２６に進む。
【００５９】
しかしながら、ステップ５０６においてシステム・リソース上の負荷が１００％を超えることになると判断されると、オペレーションがステップ５０７に進み、それにおいては、二次的なプログラムの１つ、たとえば、より大きなメイン・ウインドウに対してより小さいウインドウに表示されているプログラムが選択され、表示ウインドウ・サイズの調整を受ける。
【００６０】
続いてステップ５０８において、選択した二次的なプログラムが表示されることになるウインドウのサイズを調整してそのウインドウを小さくする。ルーチン内のこのポイントにおいては、調整後のサイズを計算の目的で使用し、それを使用して実際に表示されるウインドウのサイズを変化していないことから、この調整は、仮想的な調整と言うことができる。なお、ステップ５０８におけるサイズ縮小は、あらかじめ選択済みの、たとえば一定量の縮小とすることができる。
【００６１】
オペレーションは、ステップ５０８からステップ５１０に進む。ステップ５１０においては、すべての二次的なプログラムのサイズがゼロにセットされたか否かについての判断が行われる。この判断結果が肯定されるときには、二次的なプログラムがまったく表示されないことになり、オペレーションがステップ５１６に進む。
【００６２】
しかしながら、ステップ５１０において、サイズがゼロまで縮小されていない二次的なプログラムに関連付けされているウインドウが１ないしは複数あると判断されると、オペレーションがステップ５１２に進む。ステップ５１２においては、ステップ５０８において生成された新しい縮小後のウインドウ・サイズを用いてシステム・リソース上の合計の負荷が再計算される。次にステップ５１４において、再度、システム・リソース上の合計の負荷が１００％を超えるか否かについてのチェックが行われる。この判断結果が肯定であるときには、オペレーションがステップ５０７に進み、それにおいて二次的なプログラムが選択され、その表示ウインドウ・サイズが縮小される。ステップ５０７から５１４までのステップは、すべての二次的なプログラムのサイズがゼロにセットされるまで、あるいはシステム・リソース上の合計の負荷が１００％に等しいかそれより小さくなるまで繰り返される。
【００６３】
ステップ５１４において、システム・リソース上の合計の負荷が１００％に等しいかそれより小さくなると判断され、調整後の二次的なウインドウ・サイズを用いてプログラム・イメージのデコーディングおよび表示が可能であることが示されると、オペレーションがステップ５１６に進む。
【００６４】
ステップ５１６においては、たとえばディスプレイ・デバイス１３４上に、二次的なプログラム・ウインドウの提案サイズのセットがユーザに対して示される。次に、ステップ５１８において、ユーザから二次的なウインドウに関するスクリーン・サイズの情報の入力が提供されたか否かについての判断が行われる。このステップ５１８において、提案ウインドウ・サイズにユーザが同意したか、あるいはウインドウ・サイズに関する情報の入力がなかったと判断された場合、たとえば、１０秒間というような形であらかじめ選択した時間が経過した場合には、オペレーションがステップ５１９に進む。ステップ５１９においては、パラメータ・コントロール回路１５２、１５２’、１５２”がビデオ・スケーラ、デコーダおよび／またはビデオ・メモリをコントロールし、新しい表示ウインドウ・サイズの関数として、たとえばステップ５１６においてユーザに対して提案した、仮想的に調整済みのウインドウ・サイズの関数としてプログラム・イメージを処理し、ストアする。その後、オペレーションはステップ５２６に進む。
【００６５】
ステップ５１８において、ユーザが二次的なウインドウ・サイズに関する入力を提供したと判断されると、その入力が収集されて、オペレーションがステップ５２０に進む。ステップ５２０においては、新しいウインドウ・サイズ、たとえばユーザにより選択もしくは提供が行われた新しいウインドウ・サイズを使用してシステム・リソースの合計の負荷が再計算される。次にステップ５２２において、その新しいウインドウ・サイズの使用によってシステムの使用可能なリソースの１００％を超えるか否かについての判断が行われる。その新しいウインドウ・サイズによっても使用可能なリソースの需要が実際の利用可能度を超える結果はもたらされないと判断されると、オペレーションがステップ５１９に進む。
【００６６】
しかしながら、ステップ５２２において、ユーザが提供した新しいウインドウ・サイズの使用によって、イメージのデコーディングおよび表示に使用可能なシステム・リソースより多くのシステム・リソースが必要になると判断されると、オペレーションがステップ５２４に進む。ステップ５２４においては、シーン変化検出回路１５６、フレーム・タイプ検出回路１５６’、または組み合わせによるシーン変化／フレーム・タイプ検出回路１５６”が使用されてビデオ・デコーディングおよび／または表示オペレーションがコントロールされる。前述したように、シーン変化検出回路１５６または検出器１５６”のシーン変化検出部分は、シーンの変化を伴うプログラム・フレーム、たとえばイメージのコンテンツに重要な変化のあるフレームを検出する。この検出は、本発明に従って、補助的なプログラム・データとして、受信されたＴＶプログラムとともに放送されたシーン変化情報を使用することによって行うことができる。それに代えて、１ないしは複数の周知のシーン変化検出テクニックを使用して、デコードおよび表示が行われているプログラム内のシーンの変化を検出することもできる。フレーム・タイプ検出器１５６’または検出器１５６”のフレーム・タイプ検出部分は、前述したように、ＤＥＭＵＸ  １１２または２１２によって逆多重化されたビデオ・ストリーム内のヘッダ情報をチェックすることにより、データが対応しているフレーム・タイプを検出する。パラメータ・コントロール回路１５２”は、シーン変化／フレーム・タイプ検出回路１５６”によって提供されるシーン変化および／またはフレーム・タイプ情報に応答する。
【００６７】
一実施例のステップ５２４においては、重要な変化、たとえばコンテンツ内に主要な変化があった１ないしは複数の二次的なプログラムに対応するフレームが識別されて処理される。それに加えて、主要な変化を表さないイメージに対応する１ないしは複数の二次的なプログラムの一部または全部は、使用されずに、たとえば無視または放棄される。このようにして、プロセッシング・リソースに関する需要が抑えられる。
【００６８】
別の実施態様のステップ５２４においては、１ないしは複数の二次的なプログラム対応のインター‐コーデッド・フレームに対応するデータが識別されて無視される。つまり、デコーディング、スケーリングおよびその他のリソースの需要が、少なくとも１つの二次的なプログラムの１ないしは複数のインター‐コーデッド・フレームを無視することによって抑えられる。さらに別の実施態様においては、シーン変化検出情報が、フレーム・タイプ情報とともに使用されて、たとえばシステム２０４によって実装されたプロセスをもたらし、それにおいてはステップ５２４で、重要なシーンの変化を伴わない二次的なプログラムのいくつかのフレームに対応するデータが無視され、かつ１ないしは複数の二次的なプログラムのインター‐コーデッド・フレームが無視され、たとえばデコードおよび表示が行われない。その後オペレーションは、ステップ５２４からステップ５２６に進む。
【００６９】
ステップ５２６においては、パラメータ・コントロール回路１５２、１５２’、１５２”が、システムのユーザによって別の入力プログラムが選択されるまで、あるいは、たとえばユーザによって１ないしは複数の表示ウインドウ・サイズが変更されるまで待機する。その後は、オペレーションがステップ５０４に進み、それにおいて再度、負荷の計算から実行される。
【００７０】
方法５００を使用すると、単一のスクリーン上に同時に表示される複数のイメージのデコーディングおよび表示をコントロールすることが可能になる。本発明の方法は、メイン・プログラムのデコーディングおよび表示が適正に行われ、かつ二次的なプログラムまたはイメージのデコーディングおよび表示の結果としてもたらされるシステム・リソースの需要が使用可能なシステム・リソースに制限されることを保証する。また本発明の方法は、二次的なイメージにおける問題を最小化するべく意図された方法でのシステム・リソースの割り当てを提供する。
【図面の簡単な説明】
【図１】  複数のイメージ・シーケンスに対応するデータを処理するための典型的なシステムを示している。
【図２Ａ】  本発明に従って実装される、１つのディスプレイ・デバイス上に複数のイメージを同時に表示するための各種のシステムを示している。
【図２Ｂ】  本発明に従って実装される、１つのディスプレイ・デバイス上に複数のイメージを同時に表示するための各種のシステムを示している。
【図２Ｃ】  本発明に従って実装される、１つのディスプレイ・デバイス上に複数のイメージを同時に表示するための各種のシステムを示している。
【図３Ａ】  異なるビデオ・プログラムからのイメージが同時に表示される複数のウインドウを有するスクリーンを含んだディスプレイ・デバイスを示している。
【図３Ｂ】  異なるビデオ・プログラムからのイメージが同時に表示される複数のウインドウを有するスクリーンを含んだディスプレイ・デバイスを示している。
【図４】  図２Ａ〜２Ｃの実施態様に使用されるタイプの情報データベースのコンテンツの一例を示している。
【図５】  図２Ａ〜２Ｃに示したシステムの動作の一部として実行されるステップを示したフローチャートである。
【図１】
0004212775.tif 000002
【図２Ａ】
0004212775.tif 000003
【図２Ｂ】
0004212775.tif 000004
【図２Ｃ】
0004212775.tif 000005
【図３Ａ】
0004212775.tif 000006
【図３Ｂ】
0004212775.tif 000007
【図４】
0004212775.tif 000008
【図５】
0004212775.tif 000009