(57)【要約】  メディアチャネルを介して受信したビデオデータを処理するシステムと方法が開示される。この方法によれば、インデックステーブルを用いて、動きベクトルを含んで格納されたビデオデータを参照するので、トランスコーダのエンコーダおよびデコーダ部分により、ビデオデータを効率的にアクセスすることができる。ここで、デコーダはソースピクセル画像を生成し、エンコーダは、記憶された動きベクトルデータに基づいて、予測された動きベクトルを生成する。
2005510981.tif 000002
【特許請求の範囲】
【請求項１】
第１のインデックステーブルにアクセスするステップと、
第１の復号画像を生成するために、ビデオデコーダにおいて、第１の順で第１の複数のマクロブロック情報にアクセスするステップであって、前記第１の順は、前記第１のインデックステーブルに基づき、前記第１の複数のマクロブロック情報はソースマクロブロックに関連しているステップと、
第１の予測されたデスティネーション動きベクトルを生成するために、第１の複数のマクロブロック情報にアクセスするステップと、
を有する方法であって、前記マクロブロック情報は、動きベクトルと量子化情報を含む方法。
【請求項２】
さらに、前記第１の復号画像と前記予測されたデスティネーションマクロブロック情報とに基づいて、符号化デスティネーションビデオ画像を生成するステップを有する請求項１に記載の方法。
【請求項３】
前記第１のインデックステーブルは複数項目を備え、複数項目のそれぞれは、ソースマクロブロックの位置を指示する値を保持するポインタ部と、デスティネーションマクロブロック部の最後は、複数項目の１項目が第１のデスティネーションマクロブロック情報に関連するラスト項目であるか否かを指示する値を保持するデスティネーションマクロブロックエンド部とを含む請求項１に記載の方法。
【請求項４】
前記複数項目の各項目は所定のサイズをもつ請求項１に記載の方法。
【請求項５】
前記各項目の所定のサイズは同一である請求項４に記載の方法。
【請求項６】
前記複数項目の各項目は、前記第１の順を指示するために、複数項目中の他の各項目に関連して配置される請求項１に記載の方法。
【請求項７】
さらに、第１のデスティネーションマクロブロックに対する第１の予測されたマクロブロック情報を生成するステップであって、前記第１のデスティネーションマクロブロック情報は、少なくとも第１の複数のマクロブロック情報に基づいており、前記第１のデスティネーションマクロブロックは、ソースマクロブロックに比較してダウンスケールされるステップを有する請求項１に記載の方法。
【請求項８】
前記第１のインデックステーブルは複数の項目を含み、複数の項目のそれぞれは、ソースマクロブロック情報の位置を指示する値を保持するポインタ部と、複数の項目の１項目が、第１のデスティネーションマクロブロック情報に関連するラスト項目であるか否かを指示するデスティネーションマクロブロックエンド部とを含む請求項５に記載の方法。
【請求項９】
前記複数項目の各項目は、前記第１の順を指示するために、複数項目の他の項目に関連して配置される請求項８に記載の方法。
【請求項１０】
前記複数項目の各項目は所定のサイズをもつ請求項９に記載の方法。
【請求項１１】
前記各項目の前記所定のサイズは同一である請求項１０に記載の方法。
【請求項１２】
さらに、第２のインデックステーブルにアクセスするステップと、
第２の復号画像を生成するために、ビデオデコーダにおいて第２の順で、第１の複数のソースマクロブロック情報にアクセスするステップであって、前記第２の順は前記第２のインデックステーブルに基づいていて、前記第１の複数のソースマクロブロック情報はソースマクロブロックに関連しているステップと、
第２の予測されたデスティネーションマクロブロック情報を生成するために、第２の複数のソースマクロブロック情報にアクセスするステップと、
を有する請求項７に記載の方法。
【請求項１３】
さらに、第１の予測されたデスティネーションベクトルに基づいて第１マクロブロクを生成し、第２の予測されたデスティネーションベクトルに基づいて第２のマクロブロックを生成するとともに、第１および第２のマクロブロックはリアルタイムで同時に表示されるステップを有する請求項１０に記載の方法。
【請求項１４】
第１の複数のソースマクロブロックの各ソースマクロブロックに対するビデオソースマクロブロック情報を記憶するステップと、
複数の項目をもち、ビデオソース解像度とビデオデスティネーション解像度とに基づくインデックステーブルを決定するステップであって、そこでは各マクロブロックに対する各ソースマクロブロック情報の位置が、インデックステーブルの対応する項目により参照されるステップと、
前記インデックステーブルを記憶するステップと、
を有する方法。
【請求項１５】
さらに、ビデオトランスコーダの一部により処理されるデータ命令パケットを決定するステップであって、データ命令パケットは前記インデックステーブルの位置を識別するステップを有する請求項１４に記載の方法。
【請求項１６】
前記ビデオトランスコーダの一部は、ビデオデコーダ部である請求項１４に記載の方法。
【請求項１７】
前記ビデオトランスコーダの一部は、ビデオエンコーダ部である請求項１４に記載の方法。
【請求項１８】
前記ビデオトランスコーダの一部は、ビデオエンコーダ部とビデオデコーダ部である請求項１４に記載の方法。
【請求項１９】
前記インデックステーブルの各項目は、共通のサイズをもつ請求項１４に記載の方法。
【請求項２０】
前記インデックステーブルは、デスティネーションマクロブロックに関連するインデックステーブルの一部を指示するためのマクロブロックエンド・インジケータを含む請求項１４に記載の方法。
【請求項２１】
前記マクロブロックエンド・インジケータは、インデックステーブルの項目のフィールド内に値として記憶される請求項２０に記載の方法。
【請求項２２】
ソースビデオデータを受信する第１の入力ポートと、
受信したソースビデオデータに対応するマクロブロック情報データを決定するために、前記第１の入力ポートと接続するコントローラ部であって、前記マクロブロック情報は動きベクトルと量子化情報を含むコントローラ部と、
前記ソースビデオデータに対応する複数のソースマクロブロック情報を保存するために、前記コントローラ部と接続する第１のメモリ制御部と、
デスティネーション画像のサイズインジケータを受信するため、および第１のデスティネーションソースベクトル生成するために使用される複数のソースマクロブロック情報の第１の部分を識別するインデックステーブルを生成するために、接続されたインデックステーブル・ジェネレータであって、該インデックステーブルは、前記デスティネーション画像のサイズインジケータに基づいているインデックステーブル・ジェネレータと、
を備えるシステム。
【請求項２３】
さらに、インデックステーブル項目に基づいて、ソースマクロブロック情報を探索するために接続された第２のメモリ制御部と、
前記探索されたソースマクロブロック情報に基づいてデスティネーションベクトルを生成するために、第２のメモリ制御部に接続するエンコーダ部と、
を備える請求項２１に記載のシステム。
【請求項２４】
前記インデックステーブル・ジェネレータは、汎用プロセッサコアを用いて実現される請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
〔同時係属出願〕
この出願は、代理人整理番号VIXS0100010をもつ、２００１年３月２７日に出願された米国特許出願第09/819,147号「ビデオストリームの圧縮装置および方法」、代理人整理番号VIXS,0100100をもつ、２００１年７月３０日に出願された米国特許出願第09/917,967号「ビデオ処理方法および装置」、代理人整理番号VIXS0100110をもつ、２００１年７月３０日に出願された米国特許出願第09/918,384号「データアクセス方法および装置」、代理人整理番号VIXS0100090をもつ、２００１年７月３０日に出願された米国特許出願第09/918,380号「複数チャネル・ビデオトランスコーディングシステムおよび方法」に関連する。
【０００２】
本発明は、一般的にビデオストリームを処理するシステムに関し、具体的にはビデオ処理に用いられるデータを記憶するシステムおよび方法に関する。
【背景技術】
【０００３】
アナログ放送システム用のアナログチューナは、受信したアナログメディアデータを非常に簡単な回路により復号することができるが、これとは異なり、動画ビデオのようなデジタルメディアデータは、デジタルメディアを再生するのに、一般にプロセッサの集中的な演算を必要とする。高品位テレビジョン（ＨＤＴＶ）の1920x1080iフォーマットをサポートするために要求されるデータ送信レートのように、そのメディアストリームに関連するデータ量が比較的大きい場合、同時に存在する複数のデジタルメディアストリームを復号するための費用と取組みは法外なものとなる。この問題は現在では、フレーム間コンテンツの連続性を利用して、きわめて高圧縮のデータを生成する圧縮スキームにより解決されている。動画専門家グループ（ＭＰＥＧ）は、圧縮を行なうために、フレーム間の画像ブロックについて動き予測を用いる方法を提案した。
【０００４】
ビデオデータを圧縮するステップは、プロセッサおよびメモリ帯域を集中的に使用する。動き予測すなわち１つの圧縮ステップは、莫大な演算作業量を必要とし、利用可能な広い帯域量を使い尽くすことになる。通常の動き予測方法ではまず、１フレームの画像データが、複数のフラグメント又はブロックに細分割される。次いで、カレントフレームの画像のブロックの１つのフラグメント又はグループが、他の１以上のフレームのブロックの１以上のフラグメント又はグループに対して比較される。交代するフレームそれぞれのブロックの最適なフラグメント又はグループは、カレントフレームと同じ場所にないかもしれない。この場所は、１以上の交代するフレームとカレントフレームとでしばしば異なる。前のフレームに関するフラグメントの場所は、動きベクトルで表現される。各々の動きベクトルを構成するために、多数のフラグメントの組合せを考慮する必要のある、プロセッサとメモリ帯域を集中的に使用する複雑な探索アルゴリズムが、一般に使用されている。
【０００５】
きわめて高精細な、例えば1920x1080iフォーマットのようなデータでは、その圧縮ストリームのデータレートは、きわめて高い。このような高レートには少なくとも３つの問題がある。第一は、任意の時間にストリームを記憶あるいは保存するためには、きわめて高価になる莫大な記憶容量を必要とする。第二に、ストリームを見るために用いる表示装置は、高精細データストリームを表示することができないこかもしれないかもしれない。第三に、複数の視聴すなわち受信装置をもつデータネットワークが存在する場合、通常そのネットワークは、固定帯域又は固定容量を有する。そのようなネットワークでは、複数の視聴装置を同時にサポートすることが物理的に不可能である。さらに、フレームのフラグメントすなわちマクロブックを構築するために一般的に必要とされる動きベクトルが、多数存在する可能性がある。これがさらに、処理と帯域の問題に付け加わる。
【０００６】
したがって、ビデオストリームを処理する、改良されたシステムおよび方法が求められている。
【０００７】
〔図の詳細な説明〕
本発明の少なくとも１つの実施形態によると、トランスコーディングシステムが提供される。このシステムは、デジタルビデオデータを受信し、パーシングされたビデオデータを提供する第１の汎用プロセッサを備える。さらに、このシステムは、パーシングされたビデオデータにアクセスするために、第１プロセッサに接続する第２プロセッサを備え、第２プロセッサはビデオトランスコーダを有する。図２５〜図２９で開示する特定の実施形態では、動きベクトルデータおよび量子化情報は、メモリに記憶され、インデックステーブルを用いてアクセスされ、システムに用いるメモリ帯域を減少させる。本発明の利点は、メディアチャネルの受信およびトランスコードが効率的に実行できることである。さらに他の利点は、ビデオチャネルのリアルタイムの再生をより効率的にサポートすることである。
【０００８】
図１〜図５には、複数のメディアチャネルをトランスコードするシステムおよび方法を示す。このシステムは、１以上のメディアチャネルをもつメディアデータストリームをパーシングする第１のプロセッサと、パーシングされたメディアチャネルを伸張し、スケーリングし、そして圧縮するベクトルプロセッサとを備える。１実施形態では、パーシングされたメディアチャネルは、デコーダ命令パケットにパケット化され、シーケンサを用いてベクトルプロセッサに送信される。ベクトルプロセッサは、デコーダ命令パケットを伸張し、パケットから生成されたマクロブロックをスケーリングし、スケーリングされた結果を圧縮する。この結果、スケーリングされ圧縮された出力は、メディアチャネルと関連の少ないデータをもち、より高速および／または高効率の記憶または送信を可能にする。
【０００９】
図１を参照すると、本発明の少なくとも１つの実施形態による、ビデオ処理システムの上位レベルの機能ブロック図が示されている。ビデオ処理システム１１０は、入力バッファ１０５を備え、これによりビデオ画像を表現するデータを受信し、ＭＰＥＧデコーダ１１０に供給する。ＭＰＥＧデコーダ１１０は、メモリ（ＲＡＭ１  １２０）にフレームを伸張した、そのビデオ画像またはそのビデオ画像の必要なら縮小した表現のいずれかを生成する。このとき、ＭＰＥＧデコーダ１１０は、伸張処理から動きベクトルと量子化情報とを得る。以下説明のために、各マクロブロックに関する動きベクトルと量子化情報の集合体をマクロブロック情報という。マクロブロック情報はメモリ（ＲＡＭ２  １４０）に保存される。なお、マクロブロック情報は通常、標準ＭＰＥＧデコーダを用いるメモリには保存されない。また、他の実施形態では、メモリ１２０とメモリ１４０とには、ダイナミック・ランダムアクセスメモリ、スタティック・ダイナミックランダムアクセスメモリ、ハードディスク装置その他が含まれる。
【００１０】
ＭＰＥＧエンコーダ１５０は、１実施形態では、通常のＭＰＥＧ符号化の多くのステップを実行するが、演算負荷の大きな動き予測ステップは回避して、以前にＲＡＭ２  １４０に保存された動きベクトルを探索する。周囲の動きベクトルのセットを検索し、新たな動きベクトルのセットを構築することによって、ＭＰＥＧエンコーダ１５０は、従来の動きベクトル予測に必要である費用のかかる探索を回避できる。出力バッファ１６０は、ビットバケットを備え、ビットバケットは、データビットを計算した後、データを受信するように接続された装置への出力ポート、あるいはメモリなどの最終デスティネーションに出力する。
【００１１】
さらに、各ピクチャデータ内では、各マクロブロックに対する量子化情報は、マクロブロックごとの内容に依存して変化する。大きな量子化値を用いると、高圧縮されたデータを生成して、その結果より小さなデータストリームを得ることができるが、各マクロブロック内のディテールを失うことになる。適切に符号化されたソースＭＰＥＧ２ストリーム（受信データ）では、各マクロブロックからの量子化情報は最適化され、名称が「ビデオトランスコーディング中のレート制御方法および装置」であり、本出願と同日に出願され、ここに参照として組み込まれる、整理番号VIXS.0100130をもつ係属中の特許出願に開示されているように、本発明に従って、この量子化情報を再利用できる。実際、より高品質なピクチャが、この量子化情報を再利用することで得られ、より細かなディテールを含む必要のあるマクロブロックに対してディテールを保持しながら、高圧縮によりディテールを失ってもよいマクロブロックに対してより大きな量子化が可能となる。
【００１２】
図２には、トランスコーディング方法が、本発明の少なくとも１つの実施形態に従って記載されている。図２に示された特定の実施形態を参照すると、２０５〜２５０の符号を付した要素は、デコーダ部分の機能を示し、要素２２５〜２９５は、トランスコーダのエンコーダ部分の機能を示す。なお、この例は、１/２×１/２の画像ダウンスケーリングを想定している。ＭＰＥＧ用語であるマクロブロックは、個々のピクチャ要素の１６×１６の行列である。ＭＰＥＧ用語のブロックは、個々のピクチャ要素の８×８の行列である。１/２×１/２にダウンスケーリングする場合、２×２のマクロブロックセットが、単一のマクロブロックを形成するように変換される。この１/２×１/２へのダウンスケール動作は一般に、最終結果がより小さなビットマップで表されるとともに、できる限り原画像の内容の多くを保持するように実行される。ダウンスケーリングは、理解されるように、ピクチャ要素の１グループがある手法で組合わされて、より少ない画素で構成される他のグループを生成することを意味する。１/２×１/２の縮小には、いくつかのオプションが利用できる。例えば、可能な１つは、ピクチャ要素を所定の方法で混合することである。しかしながら、当業者であれば理解できるように、それらを混合して同じ結果を与える方法、あるいは、混合しないでスケーリングする方法は多数存在している。
【００１３】
ステップ２０５では、復号されたマクロブロックが探索され、ビットパーシングされる。ステップ２１０では、特定のブロックについての情報を探索するために、例えばハフマンデコーダを用いて、可変長復号が実行される。これは、ランレベルまたはレンレングス復号であってもよい。探索された情報は一連のランレベル・シーケンスを含み、このそれぞれは、（ブロックとして知られる）８×８疎行列を表わし、そのランによって暗黙のうちに規定される連続する一連の零値をもつ。ＭＰＥＧ領域でランレベルというときには、そのランは、レベル内の値の繰り返しではなく、零の連続である。ＭＰＥＧの場合、ブロックはジグザグに構築される。
【００１４】
復号の後、ステップ２１５で生成されたブロックの逆量子化の処理がなされる。これには、ブロックの要素に行列の要素をかけることが含まれている。当該技術分野で周知のとおり、逆量子化は量子化の逆であり、ここでは、固定定数の行列は、復号処理の開始時に探索され、または決定され、ストリームを復号するときにはほとんど変化しない。疎行列の各要素は、定数行列の対応する要素の定数値で乗算される、逆量子化処理の意義を理解するためには、１実施形態では、圧縮処理において、ブロックが、離散コサイン変換（ＤＣＴ）ステップを通って、ピクチャブロックは周波数領域に変換されていることをまず理解する必要がある。ピクチャブロックのこの表現では、原ブロックは、（数値表現における制限による数学的丸めまでは）何らの損失もなく回復される。
【００１５】
周波数領域では、データブロックは、興味深い特性をもつ。人間の目に見える画像の外観を決定する主要な因子は、基本的に（行列の[０，０]から始まる）左上の隅にあるブロック（行列）の項によって決定される。その項がブロックの右下へ移動してゆくと、再構成されるブロックについて、人間の目の視認性への影響が少なくなる傾向がある。符号化処理における量子化の目的は、この特性を利用することで、左上の隅の情報をできるかぎり多く保持しながら、右下近傍に位置する、零に近い項を零として扱うようにすることである。
【００１６】
ブロックが逆量子化された後、ステップ２２０で、逆離散コサイン変換（ＩＤＣＴ）方法をデータブロックに適用し、生の形のブロックを得る。ステップ２０５〜２２０は、完全なマクロブロックを得るまで、マクロブロック決定終了ステップ２２５を通るループを介して進行する。ＭＰＥＧにとって、このマクロブロックは、一般的に、Ｙ（ルーマすなわち輝度）情報の４（２×２）ブロックと、Ｃｒの１ブロックと、およびＣｂの１ブロックとからなる。完全なマクロブロックが得られると、処理は、？？動きベクトル復号検証ステップ２３０？？に進み、ここではマクロブロックに対する動きベクトルが決定されるか、識別される。あるマクロブロックに動きベクトルがなければ、１実施形態では、そのマクロブロックは、１，２，４，または８のようなスケールファクタによってダウンスケールされ、ステップ２４５で書き込まれる。
【００１７】
動きベクトルのセットがある場合には、動きベクトルはステップ２３５で、メモリ１４０（図１）のような記憶領域に保存される。ここには、このフレームを構築するために用いられたすべての元の動きベクトルを保持している。ステップ２４０では、動き補償を行い、新たなマクロブロックを構築する。それからステップ２４５で、この新たなマクロブロックはダウンスケールされて出力する。
【００１８】
ステップ２５０で、そのフレームが終了したなら、ステップ２５５で、フレームエンコーダを初期化し、ステップ２６０で、マクロブロックの符号化を開始する。現在のマクロブロックが、動きベクトルを持たない（ステップ２６５で判断される）場合、ステップ２８２で、復号処理の過程で生成され、ダウンスケールされ伸張されたフレームから、マクロブロックが読み出され、ステップ２８４で、マクロブロックの各ブロックは離散コサイン変換を受ける。現在のマクロブロックが、動きベクトルを持つ（ステップ２６５で判断される）場合、隣接する動きベクトルの４セットが、ステップ２７０で記憶装置から探索され、ステップ２７５とステップ２８０とで、原画像フレームを構築するために用いられる。なお、本例では、１／２×１／２を用いている。他のスケールファクタに対してより多くの動きベクトルを検索することが要求されるかもしれない。例えば、１／３×１／３でスケーリングする場合、９個の動きベクトルが用いられる。また、スケーリングが２／５×２／５では、結果として生じる動きベクトルが生成される方法に応じて、４個から９個の動きベクトルが用いられる。
【００１９】
ステップ２７５では、新たな動きベクトルを複数の方法で構築することができる。１つの方法では、１／２の単純平均モジュロが、動きベクトルの４つのセットのそれぞれから得られるベクトルの各成分に適用される。これに代る他の方法では、ｋ次の動きベクトルの各セットから最も頻繁に起こる動きベクトル（ΔＸk，ΔＹk）が、任意のタイブレイク（breaking ties）方法により選択される。1つのタイブレイク方法は、左上の動きベクトルに最も近い要素を選択することである。
【００２０】
ステップ２７５で、新たな動きベクトルが構築されると、ステップ２８０で、記憶された伸張画像フレームからマクロブロックを読み込み、逆動きベクトル補償の適用結果を含むデルタフレームを構築して、デルタマクロブロックを得る。この時点で、デルタマクロブロックは、ステップ２８６で、すべてについて離散コサイン変換（ＤＣＴ）を行なう（行列の要素ごとの整数除算を丸める）ユニットに送られる。ステップ２８８で、その結果である各ブロックの量子化行列表現は、可変長符号化され、圧縮結果は、ステップ２９０の出力符号化マクロブロックユニットに送られる。ステップ２９５では、フレームの復号終了を検出するまで処理は続行され、次いでデコーダに次のフレームについて作業を開始する信号を送る。なお、ここでは動きベクトルの二重バッファリングを用いており、他の命令ストリームは待ち行列に入れて、エンコーダとデコーダの両ステップは、並列に動作している。
【００２１】
少なくとも１つの実施形態の特徴の１つは、動きベクトルがある場合には、ステップ２３５で、処理されたフレームを構築するために用いるすべての元の動きベクトルを保持している記憶領域に、動きベクトルが保存されることである。さらに、ステップ２７５で、記憶された動きベクトルを探索し、簡単な処理ステップを用いて新たな動きベクトルのセットを構築することによって、負荷が大きく費用のかかる演算を必要とする動き予測ステップが回避される。費用のかかる動き予測ステップを回避することにより、本発明は、よりいっそう費用対効果の優れた解決策を提供することができ、またこれにより動きベクトルを一から検索するシステムとほぼ同じ品質のトランスコーディングを実現できる。
【００２２】
図３には、圧縮ビデオ・トランスコーディングシステムが、本発明の他の実施形態に従って示されている。圧縮ビデオ・トランスコーディングシステム３００、以下トランスコーディングシステム３００として言及するが、さまざまな実施例では、ビデオ処理システム１００（図１）のすべてを含むこともできるし、まったく含まないようにもできる。トランスコーディングシステム３００は、メディアソース３０１と、トランスコーダ装置３０３と、ホスト中央処理装置（ＣＰＵ）３０５と、バス／メモリ・コントローラ３０７（すなわち、ノースブリッジチップ）と、ホスト・ダイナミック・ランダムアクセスメモリ（ＤＲＡＭ）３０９と、システム入出力（Ｉ／Ｏ）バス３１５と、ネットワーク・コントローラ３２０と、デバイスメモリ３９０とを備える。
【００２３】
１実施形態では、トランスコーダ装置３０３は、プロセッサ３３０と、ハフマン復号器３３３と、入力ビットバケット３３５、メモリコントローラ３４０と、デコーダ命令パケット（ＤＩＰ）シーケンサ３４５と、ビデオプロセッサ３５０と、システムダイレクトメモリアクセス（ＤＭＡ）バスインタフェース３８０とを備える。少なくとも１つの実施形態では、プロセッサ３３０は、ＲＩＳＣプロセッサのような汎用プロセッサであり、他方ＤＩＰシーケンサ３４５とビデオプロセッサ３５０は、特定の作業を効率的に扱えるように最適化した専用データ処理装置である。１実施形態では、ビデオプロセッサ３５０と、シーケンサ３４５と、プロセッサ３３０とは、半導体基板あるいはパッケージ基板のような共通の基板に一体化されている。トランスコーディングシステム３００は、本発明の精神または範囲から離れることなく、適宜付加的な素子を備えるようにできる。
【００２４】
少なくとも１つの実施形態では、メディアデータストリーム３１０は、１以上のソース３０１からのディジタルメディアデータを表し、各ソースは、１以上のメディアデータチャネルをもつ。メディアソース３０１は、メディアデータストリーム３２０の任意のソース、例えばＭＰＥＧ再生装置や、ネットワークコントローラを介してトランスコーディングシステム３００に接続したデータサーバ等を含む。１実施形態では、メディアデータストリーム３１０は、バイト又はワードの形式で、システム３０３に受信される。他の実施形態では、メディアデータストリーム３１０は、システム３３０によってバイト又は適切なワードのサイズに編成されたビットストリームであってもよい。適切なワード形式が与えられると、データはメモリコントローラ３４０に送信される。１実施形態では、メディアデータストリーム３１０は、メモリコントローラ３４０のクライアントとして扱われる。メディアデータストリームは、共用または専用の入力ピンのセットを介し、またはシステムＩ／Ｏバス３１５を介して、メモリコントローラ３４０に供給される。一般に、メモリコントローラ３４０は、ラウンドロビン・スキームのような予め定められた優先順位スキームに基づいて、または後に図５を参照して詳しく説明する固定優先順位に基づいて、各クライアント間の調停を行なう。
【００２５】
メディアデータストリーム３１０からのデータは、デバイスメモリ３９０に記憶される。デバイスメモリ３９０には、フラッシュメモリ、ランダムアクセスメモリ、キャッシュ等を含む。データストリームが、デバイスメモリ３９０に記憶されると、プロセッサ３３０とビデオプロセッサ３５０を含む複数のクライアントは、コントローラ３４０を介してメモリ３９０にアクセスすることができ、デバイスメモリ３９０からのデータストリームにアクセスすることができる。これにより、システム３０３はデータを並列に処理することができる。
【００２６】
１実施形態では、プロセッサ３３０は、入力ビットバケット３３５を中間準備段階として使用し、そこでは、メモリ３９０に記憶されたデータに対するビットレベルアクセスを支援し、かつデータをバッファしてプロセッサ３３０とメモリ３９０に記憶されたデータとの間の待ち時間を減少させる。例えば、プロセッサ３３０は、入力ビットバケット３３５を用いて、可変範囲の任意のビットあるいは複数ビットを要求することができる。例えば、プロセッサは、アドレス位置のビット３から始まるバイトあるいは適切なサイズのワードを要求することができる。戻り値は、プロセッサ３３０に与えられる実際のデータの境界に整列するビット３の値をもつことになる。
【００２７】
１実施形態では、プロセッサ３３０は、ＭＩＰｓプロセッサのような汎用プロセッサ、またはＡＳＩＣのような専用プロセッサである。汎用プロセッサは、ソフトウェアで特定される１以上の機能を果たすデータ処理装置である。なお、理解されるとおり、ソフトウェアはファームウェアを含む。１実施形態では、プロセッサ３３０は、受信したビデオデータにアクセスし、誤り訂正を行い、メディアデータストリーム３１０のパーシングまたは復号のようなフィルタ処理によって、メディアデータストリーム３１０を通じて受信する、所望のメディアデータチャネルに対するデコーダ命令パケット（ＤＩＰ）生成する。ＤＩＰは、特定の命令および／または制御情報を有して、ＤＩＰシーケンサ２２０とベクトルプロセッサ２３０はこれを用いて、新たなマクロブロック生成する。ＤＩＰは、いったん生成されると、メモリコントローラ３４０によってデバイスメモリ３９０に記憶される。他の実施形態では、誤り訂正、フィルタリング、またはパーシング機能の１以上のものが、トランスコーダ装置３０３の他の構成要素により実行される。例えば、ビットストリームフィルタ（図示せず）を用いて、メモリメディアデータストリームが、メモリコントローラ３４０によってデバイスメモリ３９０に記憶される前に、メディアデータストリーム３１０に関してフィルタリング処理を行うことができる。プロセッサ３３０はまた、専用のハフマン復号器３３３を用いて、ハフマン復号処理を行なうことができる。ハフマン復号器３３３は、簡単な可変ビット・ルックアップテーブルを、ハードウェアあるいはソフトウェアに備えて、復号処理をスピードアップすることができる。
【００２８】
ＤＩＰシーケンサ３４５は、ビデオプロセッサ３５０に対する制御ユニットとして動作する。実際ＤＩＰシーケンサは、ビデオプロセッサ３５０の一部ともみなせる。シーケンサ３４５は、メモリコントローラ３４０のクライアントであり、メモリコントローラ３４０からデータを受信し、制御信号に従ってビデオプロセッサ（トランスコーダ）３５０にデータを伝送する。
【００２９】
１実施形態では、ビデオプロセッサ３５０は、ビデオトランスコーダであり、ＤＩＰシーケンサ３４５からＤＩＰと制御信号とを受信して、引き続きスループットを最大化するパイプライン手法により、メディアの復号を実行する。少なくとも１つの実施形態では、ビデオプロセッサ３５０は、伸張ブロック３５５を用いてＤＩＰを伸張する。伸張ブロック３５５からの出力データは、スケーラブロック３６０に伝送され、そこでは伸張されたビデオデータが、スケールファクタによってスケーリングされ、圧縮ブロック３６５に出力される。１実施形態では、圧縮ブロック３６５は、スケーラブロック３６０の出力を圧縮してビデオフレームのような圧縮データを生成し、圧縮データを出力ビットバケットに送信する。出力ビットバケットでは、すべてのワードがメモリコントローラ３４０に記憶される準備ができるまで、圧縮ビデオデータを記憶する。ビデオプロセッサ３５０の特定の実施例は、図４を参照して詳細に説明する。
【００３０】
メモリコントローラ３４０は、ビデオプロセッサ３５０をクライアントとして扱い、出力ビットバケット３７０からそのデータを探索し、それをデバイスメモリ３９０に記憶する。いったん圧縮メディアの１フレームがビデオプロセッサ３５０から探索し、デバイスメモリ３９０に記憶すると、それはシステムＤＭＡバスインタフェース３８０によってアクセスされ、システムＩ／Ｏバス３１５を用いてノースブリッジ３０７に送られる。次いで、ノースブリッジ３０７は、データをホストＤＲＡＭ３０９へ送る。１実施形態では、ホストＤＲＡＭ３０９は、システムの他の個所に配信される最終メディアデータチャネルのストレージとして用いられる。１実施形態では、ホストプロセッサ３０５は、最終メディアデータチャネルを、最終メディアデータチャネルの配信と放送を管理するネットワークコントローラ３２０にいつ送るかをスケジューリングする。１実施形態では、ネットワークコントローラは、送信情報を表示するための複数の表示装置に接続される。なお、ノースブリッジ３０７は、ホストＣＰＵ３０５をシステム（ホスト）メモリ３０９とＩＯバス３１５とにインタフェースするための、集積化またはマルチチップの手段を表す。
【００３１】
図４を参照すると、ビデオプロセッサ３５０の特定の実施例が、少なくとも１つの実施形態に従って示されている。ビデオプロセッサ３５０は、メディアデータストリーム３１０からパーシングされた（ＤＩＰの形式の）メディアデータチャネルを、伸張ブロック３５５を用いて伸張し、スケーラブロック３６０を用いて出力をスケーリングし、圧縮ブロック３６５を用いてスケーリングされた出力を圧縮するものである。本発明の１実施形態では、伸張ブロック３５５は、逆ジグザグ化／逆量子化ブロック４１０と、逆離散コサイン変換（ＩＤＣＴ）ブロック４２０と、動き補償４３０と、マクロブロックバッファ４４０とを備え、他方、圧縮ブロック３６５は、バッファ付き動き予測ブロック３６５と、離散コサイン変換（ＤＣＴ）ブロック４６０と、量子化／ジグザグ化ブロック４７０と、ハフマンエンコーダ４８０とを備える。伸張ブロックおよび／または圧縮ブロック３６５の１以上の構成部品が個別に設けてもよいことは明らかである。
【００３２】
先に説明したように、１実施形態では、デコーダ命令パケット（ＤＩＰ）は、メモリコントローラ２４０を通してＤＩＰシーケンサ３４５によってデバイスメモリ３９０（図３）から探索される。この場合、ＤＩＰシーケンサ３４５は、ＤＩＰを適切な場所に供給できるような方法で、ＤＩＰをトランスコーダ３５０に転送する。例えば、シーケンサ３４５は、直接アドレス指定を行い、トランスコーダ３５０へのローカルバスを介してデータを供給することによって、個々のブロックにデータを供給することができる。またシーケンサ３４５は、トランスコーダ３５０のブロックによってアクセス可能なレジスタバックボーンに、コントロールおよび／またはデータ情報を書き込むことができる。通常のデータフローにおいては、シーケンサによって、逆ジグザグ化／逆量子化ブロック４１０がデータを探索可能である。
【００３３】
１実施形態では、メディアデータストリーム３１０を介して受信して、メモリ３９０に記憶される基本ストリームデータに基づいて、ＤＩＰシーケンサがＤＩＰを探索する。少なくとも１つの実施形態では、メディアデータストリーム３１０（図３）は、１以上のＭＰＥＧビデオデータチャネル含むものである。この場合、ビデオチャネル圧縮のためのＭＰＥＧアルゴリズムは、アルゴリズム中に離散コサイン変換（ＤＣＴ）の段階をもち、時間領域から周波数領域への変換を行なう。この変換の結果、ＤＣＴ後、生成される行列の（０，０）である左上の要素に最も近い、周波数領域の要素は、その行列の右下の要素に比較して、より大きく重み付けされる。周波数領域の行列が、行列の下方の右半部における要素を表現するほど正確でなくてもよければ、その行列の下方の右半部における要素の小さな値は、量子化ファクタに基づく閾値より小の場合には零に変換される。量子化ファクタによって各要素を割るのは、より多くの零を得るために用いる方法である。ＭＰＥＧおよび関連アルゴリズムはしばしば、大きな量子化値を用いて、周波数領域の行列の正確さを減少させ、その結果多くの零要素を得てデータ送信レートを減少させる。したがって、１実施形態では、逆ジグザグ化／逆量子化ブロック４１０は、メディアデータチャネルについてのＤＣＴ処理の結果を逆量子化する。
【００３４】
同様に、行列を表現する通常の方法は、（行，列）形式で行なわれるが、ＤＣＴ作用の結果として得られる行列の顕著な性質は、ＤＣＴ後の行列を表現する異なる方法に導く。１実施形態では、ＤＣＴ後の行列は、ジグザグに、例えば、（１，１）、（２，１）、（１，２）、（１，３）、（２，２）、（３，１）、（４，１）、（３，２）、（２，３）等で表現される。この方法でＤＣＴ後の行列を表現することによって、ＤＣＴ後の行列に比較的長い零の連続が起こりやすくなる。結果として、ＤＣＴ後の行列は、（ラン，レベル）形式を用いてより効率的に表現されることができる。なお、ランは、連続する零の数を表し、レベルは、ＤＣＴ後の行列の次の非零要素の値を表す。（ラン，レベル）ペアは、固定ハフマンテーブルを介して符号化され、ＤＣＴ後の行列をさらに圧縮することができる。
【００３５】
１実施形態では、逆ジグザグ化／逆量子化ブロック４１０からの出力は、出力を周波数領域から時間領域へ変換する構成要素に送られるか、または異なる方法で利用される。例えば、（ＤＩＰにより表される）メディアデータストリーム３１０のパーシングチャネルが、前もって離散コサイン変換により処理されている場合、逆ジグザグ化／逆量子化ブロック４１０からの出力は、逆離散コサイン変換（ＩＤＣＴ）ブロック４２０に送られ、そこで逆離散コサイン変換機能を用いて、出力を周波数領域から時間領域へ変換し、データブロックを生成する。周波数領域と時間領域とを変換する他の変換方法も使用可能で、これも本発明の精神と範囲内に含まれる。ＩＤＣＴブロック４２０で生成されたブロックは、マクロブロックバッファ４３０に記憶される。マクロブロックを形成するのに十分なブロックが生成すると、マクロブロックバッファ４３０は、（動きベクトルと量子化情報を含む）マクロブロック情報に従って、マクロブロックデータを動き補償回路４４０に送る。
【００３６】
１実施形態では、動き補償回路４４０は、図２のステップ２４０を参照して先に説明したように動作する。ここで、動き補償回路は、後の利用のためにマクロブロック情報を記憶する。これに代る実施形態では、記憶されるマクロブロック情報は、量子化情報のみを含む。動き補償回路４４０に送信されるマクロブロックが、参照フレーム（Ｉフレーム）の一部であれば、動き補償回路４４０は、マクロブロックを復号し、デバイスメモリ３９０（図３）に復号結果と量子化情報のみを書き込む。参照フレームは一般に、動きベクトルから構成される必要がある他の非参照フレームを復号するために用いられる。
【００３７】
１実施形態では、動き補償回路４４０で生成されたマクロブロックは、スケーラブロック３６０に送られ、そこでマクロブロックは、スケールファクタを用いてスケーリングされる。例えば、マクロブロックがブロックの４×４行列を有し、スケールファクタ２を用いると、スケーリングの結果であるクロブロックは、ブロックの２×２行列を有することになる。スケーリングの結果であるマクロブロックは、バッファ付き動き予測回路４５０に送られ、圧縮処理を開始する。
【００３８】
１実施形態では、スケーリングされたマクロブロックが十分に生成され、新たなマクロブロックが形成されると、関連の記憶された動きベクトルが、バッファ付き動き予測回路４４０のような動きベクトル発生器によって処理され、動きベクトルの新たなセットを生成する。これに代る実施形態では、動きベクトルは従来の方法により、隣接フレームのマクロブロックに基づいて生成することができる。
【００３９】
参照フレームは、１回に１ブロックをＤＣＴ４６０に転送する。ＤＣＴ４６０は、各ブロックを得て、先に説明したように、例えば離散コサイン変換を実行することによって、データブロックを時間領域から周波数領域へ変換する。１実施形態では、マクロブロックが、イントラフレームまたはＩフレームのようにそれに関連する動きベクトルをもたない場合、マクロブロックは、例えば内部データパスを用いて、動き予測回路４５０の処理を経ないで、スケーラ３６０からＤＣＴブロック４６０へ直接転送される。
【００４０】
１実施形態では、ＤＣＴ４６０による修正ブロック出力は、量子化／ジグザグ化ブロック４７０に送られ、そこでブロックは、（行，列）形式からラン・レベル符号化により適する形式に、量子化および／または変換あるいはジグザグ化される。量子化／ジグザグ化ブロック４７０からの量子化および／またはジグザグ化出力は、ハフマンエンコーダ４８０に転送され、そこで量子化／ジグザグ化ブロック４７０からの出力はコンパクト化または圧縮され、圧縮結果は、ビットストリームとして出力ビットバケット３７０に送られる。１実施形態では、出力ビットバケットは、わずかの待ち時間で任意のビット位置に、ビットレベルの方法でデータを記憶できる。例えば、出力ビットバケットは、バッファとして動作して、ハフマンエンコーダ４８０からのビットストリーム出力を計算し、効率的な方法でデバイスメモリ３９０に書き込むことができる。
【００４１】
トランスコーダ３５０はさらに、量子化器からのデータについてＩＤＣＴを実行するＩＤＣＴ部４７５を備える。このデータは、動き予測回路４５０からのデータと組合わされ、損失のある圧縮の影響を修正するために記憶される。ある実施形態では、トランスコーダにより生成されたフレームが、他のフレームを形成するための基準フレームとして使用されるとき、損失のある圧縮に対する訂正が行なわれる。誤差の伝達は、損失のある圧縮を訂正するステップを設けることによって歯止めをかけることができ、その結果エンコーダ部分によって生成されるデータの正確さが増す。
【００４２】
図５は、メモリコントローラ３４０の特定の１実施形態を示す。具体的には、図５は、特定のクライアントからの要求を受信する多数のクライアントインタフェースＦＩＦＯ５１０〜５１４（先入れ先出しメモリ）をもつメモリコントローラを示す。クライアントインタフェースＦＩＦＯはそれぞれ、特定のクライアントからデータアクセスのための要求を受信することができる。図示の実施形態では、書き込みデータは、多数の書き込みデータバスによりマルチプレクサ５２０で受信される。アービタ５２５は、保留されている書き込み要求のいずれがサービスを受けるべきかを判断し、適切な制御信号を供給して、対応する入力チャネルを受信するようにする。メモリシーケンサ５３０は、効率的に読出し要求を管理する。例えば、メモリの１ページが開かれると、シーケンサは一般に、待ち時間のオーバヘッドを減少させるために、同じページからの要求に応えようとする。デュアルデータレート（ＤＤＲ）メモリのようなメモリとのインタフェースに加えて、シーケンサは、レジスタバス・クライアントインタフェースとインタフェースをとるレジスタファイルにアクセスすることができる。読出しデータリターンパスは読出しリターン制御部５３５に、アクセスされたデータを供給する。読出しリターン制御部５３５は、読出しデータバスに対してインタフェースをとって、多数のクライアントの１つに情報を返す。
【００４３】
図６を参照して、本発明の少なくとも１つの実施形態に従って、トランスコーディングシステム３００を使用する方法を説明する。トランスコーディング方法６００は、ステップ６１０からはじまる。ここではメディアデータストリーム３１０（図３）が、トランスコーダ装置３０３により受信あるいは送信される。先に説明したように、メディアデータストリーム３１０は、後の探索のためにデバイスメモリ３９０（図３）に記憶可能である。ステップ６２０では、プロセッサ３３０は、メディアデータストリーム３１０をパーシングし、所望のデータチャネル、例えばＭＰＥＧ再生装置から送られるビデオデータチャネルを識別する。プロセッサ３３０はまた、ステップ６２０で、メディアデータストリーム３１０について他の処理、例えば誤り訂正、フィルタリング等の処理を行なう。
【００４４】
１実施形態では、ステップ６３０で、パーシングされたデータチャネルが、デコーダ命令パケット（ＤＩＰ）の形でビデオプロセッサ３５０に送信される。ビデオプロセッサ３５０の伸張ブロック３５５は、先に図４を参照して説明したようにＤＩＰを伸張する。ステップ６４０では、伸張ブロック３５５の出力は、スケーラブロック３６０（図３）でスケールファクタを用いてスケーリングされ、メディアデータストリーム３１０の所望のチャネルの要素に関連するデータ量を削減する。例えば、ＭＰＥＧビデオチャネルのマクロブロックをスケーリングすることによって、各フレームを表現するために要するデータは少なくなる。ステップ６５０では、スケーラブロック３６０からのスケーリングされたデータ出力は、先に図４を参照して説明したように、圧縮ブロック３６５により圧縮される。圧縮ブロック３６５からの圧縮出力は、１以上の受信器ユニットに出力される。受信器ユニットには、各種のメディア装置、例えばビデオディスプレイ端末、オーディオ装置等を含む。
【００４５】
トランスコーディングシステム３００によって行なわれる処理の結果、メディアデータストリーム３１０（図１）のチャネルはダウンスケールあるいは圧縮され、チャネルに関連するデータが減少する。例えば、ビデオプロセッサ３５０（図３）は、ＭＰＥＧプレーヤからのビデオデータストリーム（メディアデータストリーム３１０）のチャネルをダウンスケールし、チャネルのフレームごとのデータを減少させる。このダウンスケールにより、ビデオデータチャネルは、ネットワークまたはその他の媒体を介して、より速くおよび／またはより効率的に送信される。１実施形態では、メディアデータストリーム３１０は、リアルタイム再生に用いる多数のビデオデータチャネルをもつ。この場合、１以上のビデオデータチャネルを個別にダウンスケールすることによって、より速くおよび／またはより効率的に送信され、ビデオチャネルのリアルタイム再生をサポートする。
【００４６】
明細書に開示する具体的な実施形態には、種々の改変および代替的な形態が可能である。図面および詳細な説明には、特定の実施形態が例として示されている。理解されるように、図面や詳細な説明は、開示した特定の形態に本発明を限定しようとするものではなく、これとは反対に、法が許す限り最大の範囲を意図するものである。本発明は、添付の請求の範囲およびその同等物によって規定されるとおりの本発明の精神と範囲内にあるすべての改変物、均等物、および代替物とに及ぶものである。例えば、図１に示されているシステムでは、デコーダ１１０とメモリ１２０，１４０との接続は、個別のバスを表していてもよいし、共通のバスを表していてもよい。同様に、エンコーダ１５０と出力バッファとの接続、およびデコーダと入力バッファとの接続は、同じ接続を表すものでもよいし、異なる接続を表すものであってもよく、さらにメモリ１２０，１４０の接続と共通のものでもよい。本発明の他の実施形態では、エンコーダが動きベクトルを決定する通常の動作モードの１つが選択され、明細書に説明したような動きベクトル再利用モードが選択される。モードの選択は、一般に以前に保存したマクロブロック情報の利用性に基づいて行なわれる。なお、他の実施形態では、通常の動作モードでは、デコーダは動きベクトルを保存しないものである。
【００４７】
本発明の１つの実施態様は、おおむね図に示すように構成された１以上の処理システムのランダムアクセスメモリに存在するコンピュータ可読命令のセットとして存在する。処理システムによって要求されるまで、その命令セットは、他のコンピュータ可読メモリ、例えばハードディスクドライブまたはリムーバブルメモリに記憶しておくことができる。リムーバブルメモリには、例えばＣＤドライブまたはＤＶＤドライブで使用される光学ディスク、あるいはフロッピーディスクドライブで使用されるフロッピーディスクがある。さらに命令セットは、他の画像処理システムのメモリに記憶され、ローカルエリアネットワークあるいはインターネットのようなワイドエリアネットワークを介して送信されることも可能である。ここで、送信信号は、ＩＳＤＮラインのような媒体を通じて伝搬された信号でもよいし、空気媒体を通じて伝搬し、ローカル局で受信されて、処理システムに伝送されてもよい。そのような信号は、キャリア信号をもつコンポジット信号とすることもでき、本発明を実施する少なくとも１つのコンピュータプログラム命令を含む所望の情報がキャリア信号内に含まれていて、ユーザが求めるときにダウンロードするようにしてもよい。当業者であれば理解できるように、命令セットの物理的な記憶および／または伝送は、電気的、磁気的あるいは化学的に情報を記憶し、コンピュータ可読情報を伝えるようにした媒体を物理的に変化させるものである。
【００４８】
データ命令パケット（ＤＩＰまたは「ＤＩＰパケット」）は、命令情報とデータとの双方を含むデータパケットである。図７は、ＤＩＰパケットの一例を示す。
【００４９】
図７に示すＤＩＰは、ヘッダ部と、コンフィギュレーション部と、データ部とをもつ。ＤＩＰのヘッダは、ＯＰコードとサイズインジケータを備える。ＤＩＰのＯＰコード部は、特定のＤＩＰパケットに関連する命令または他の制御情報を示す。１実施形態では、ヘッダのサイズ部は、ＤＩＰに関連してサイズペイロードが存在するか否かを示す。例えば、サイズ部は、ＤＩＰに関連するコンフィギュレーションまたはデータがなく、ヘッダのサイズのみを示す値をもつことがあり得る。他の実施形態によると、サイズ部の値が、ＤＩＰがＤＩＰ（ＥＯＤ）インジケータの最後で終ることを示す。他の実施形態によると、サイズ部の値は、ＤＩＰのサイズがその後のバイトの数で指定されることを示す。例えば、サイズ部の値は、次の２バイトまたは４バイトが、ＤＩＰのサイズを特定する符号なしの整数を含むことを示すことができる。
【００５０】
ＤＩＰのコンフィギュレーション部は、その特定のＯＰコードに特定的に関連するコンフィギュレーション情報を含む。例えば、ＤＩＰは、ピクチャ制御情報が含まれていることを示すＯＰコードをもち、これによりコンフィギュレーション部は予め規定され、ＤＩＰデコーダが、予め規定された位置のコンフィギュレーション部から制御情報にアクセスすることができる。なお、ＤＩＰのコンフィギュレーション部は、実際のＤＩＰによって決まるオプションである。また、コンフィギュレーション部は、上記したサイズペイロードデータを含んでいてもよい。
【００５１】
命令パケットのデータ部は、ＤＩＰパケットに関連するデータを含む。例えば、圧縮あるいは伸張されたビデオデータは、特定のＤＩＰの一部として含まれる。なお、データ部の存在は、ＯＰコードに基づいている。コンフィギュレーション部あるいはデータ部が利用できないモードでは、ヘッダ部が特定のオペレーションを指定して、コンフィギュレーションおよびオペレーションデータから独立して実行することができる。
【００５２】
ここで開示した特定のモードによると、ＤＩＰパケットは、ビデオデータが、受信されるデータ型に依存しないような方法で、基本のストリームデータのようなディジタルビデオデータをパケット化するために用いられる。したがって、ＭＰＥＧ標準のような特定のビデオ標準が将来変化しても、あるいは異なるディジタルビデオ標準がサポートされるように求められる場合でも、ＤＩＰフォーマットは不変のまま、ＤＩＰを生成するのに用いられる手順が、受信したビデオデータに適合するように変化する。これにより、ハードウェアが特定のビデオ標準に依存しないように効率的に設計できる。
【００５３】
特定のＤＩＰ・ＯＰコードの例として、ＤＩＰがビデオ・タイムスタンプ情報を含むことを示すＤＩＰ・ＯＰコード、ＤＩＰがピクチャ構成情報を含むことを示すＤＩＰ・ＯＰコード、ＤＩＰがスライスあるいはマクロブロック情報を含むことを示すＤＩＰ・ＯＰコード、ＤＩＰがスケーリングされたマクロブロック情報を含むことを示すＤＩＰ・ＯＰコード、ＤＩＰが量子化行列データを含むことを示すＤＩＰ・ＯＰコード、最後のピクチャＤＩＰが繰り返されることを示すＤＩＰ・ＯＰコード、および特定のピクチャ位置、例えばスライス、フレームまたはマクロブロックの最後を示すＤＩＰ・ＯＰコードの各々またはその任意の組合わせが存在する。付加的なＯＰコードが他の機能をサポートするように含まれ得ること、ＯＰコードを含む実際のＤＩＰは一般に、記憶され、引き続き復号されることは明らかであろう。
【００５４】
図８に、ＤＩＰパケットを生成するために用いられるシステム３００（図３）の一部をブロック図で示す。図８には、１実施形態では図３のプロセッサ３３０の一部に相当する、ＤＩＰ発生器部７１０と、メモリデバイス３９０と、１実施形態ではＤＩＰシーケンサ３４５の一部に相当する、データ入力コントローラ７１５とを含む。図示の構成要素は、他の実施形態では図示のものとは異なるハードウェアあるいはソフトウェアで実施され得ることは明らかであろう。
【００５５】
ＤＩＰ発生器７１０は、基本ストリーム読み取り器７１２と、データ命令発生器７１１と、ポインタ制御部７１３を備える。１実施形態では、各要素７１１〜７１３は、個々のソフトウェアモジュールとデータをやりとりする入出力ポートの組合せをもつ汎用プロセッサ上のソフトウェアで実現できる。他の実施形態では、各要素７１１〜７１３は、お互いに素子同士を接続する入出力ポートをもつハードウェアで実現することもできる。
【００５６】
メモリ３９０は、基本ストリームデータ３９１と、ＤＩＰデータ３９２と、ＤＩＰポインタデータ３９３とを記憶する部分を備える。
【００５７】
動作としては、基本ストリーム読み取り器７１２が、メモリ部３９１から、基本ストリームデータまたは他のビデオデータを受信する。１実施形態では、まず基本ストリームデータ３９１を、図３に示すようにメディアソース３０１から受信し、メモリ部３９０に記憶する。一般に、このデータは、ビデオ画像を表す基本ストリームデータとして記憶される。図３を参照して説明したように、データは、メモリコントローラに対するクライアント要求の結果として受信される。基本ストリーム読取り器は、ビデオデータを受信して、データ命令パケット発生器７１１によってパケット化する。データ命令パケット発生器は、実際のＤＩＰを生成する。このＤＩＰには、図３のビデオプロセッサ部３５０のこの後の制御と動作に必要な命令およびデータを含む。
【００５８】
ビデオプロセッサ３５０による使用のためにビデオデータをパケット化するのに加えて、データ命令パケット発生器は、ビデオプロセッサ３５０を設定するためのＤＩＰを生成する。１実施形態では、データの各マクロブロックは、単一のＤＩＰとして記憶される。他の実施形態では、複数のマクロブロックが単一のＤＩＰに関連する。例えば、スライスデータの全体が単一のＤＩＰの一部として送信されてもよい。同様に、任意の数の各種のＤＩＰがビデオ情報を送信するために実現可能であることは明らかであろう。
【００５９】
特定のＤＩＰが、データ命令パケット発生器７１１によって生成されると、メモリ３９０の一部であるＤＩＰ記憶部３９２に書き戻される。ＤＩＰ記憶部３９２には、揮発性メモリまたは不揮発性メモリ例えばハードディスクが使用できるのは明らかである。１実施形態では、ＤＩＰ記憶部３９２は、巡回バッファとすることができ、この巡回バッファは、ビデオプロセッサによりアクセスされるフレームバッファに関連する。一般に、基本ストリーム読取り器７１２による基本ストリームデータへのアクセスとＤＩＰの生成とは、生成される画像の表示に関連してリアルタイムで行われる。ＤＩＰデータがメモリ領域３９２に記憶されると、データ入力コントローラ７１５は、後に説明するように、ＤＩＰデータを受信してＤＩＰデコーダに供給する。
【００６０】
本発明の特定の実施形態によると、ポインタ制御部７１３は、新たなＤＩＰが生成する時を監視し、そのＤＩＰに対するポインタを記憶領域３９３に記憶する。ＤＩＰポインタデータを用いることは、後に詳細に説明する。
【００６１】
図９には、装置３０３（図３）の一部の詳細とデバイスメモリ３９０とを示す。具体的には、図９は、メモリコントローラ３４０と、ＤＩＰシーケンサ３４５と、ビデオプロセッサ３５０と、キャッシュメモリ３４１とを示す。図９に示すＤＩＰシーケンサはさらに、図８のデータ入力コントローラに相当するＤＩＰ入力制御モジュール３４６と、ＤＩＰデコーダモジュール７４７と、ＤＩＰ出力制御モジュール３４８とを備える。ＤＩＰシーケンサは、ビデオプロセッサ３５０に接続されている。
【００６２】
ビデオプロセッサ３５０は、スケーラブロック３６０に関連する付加的細部をも含む。具体的には、スケーラブロック３６０はさらに、スケールバッファ３５１とスケールエンジン３５２とを含む。ＤＩＰシーケンサ３４５は、メモリコントローラ３４０に接続され、メモリコントローラ３４０は、同様にデバイスメモリ３９０のような１以上のメモリデバイスに接続される。なお、図示のキャッシュメモリ３４１は、メモリ３９０に記憶されるデータを含むことができる。
【００６３】
動作においては、ＤＩＰシーケンサ３４５の入力制御モジュール３４６は、メモリコントローラ３４０を通って特定のＤＩＰ情報を受信する。１実施形態では、ＤＩＰ入力制御モジュールは、メモリコントローラ３４０に対するクライアント読出し要求に従う。メモリコントローラ３４０は、キャッシュメモリ３４１またはデバイスメモリ３９０のいずれかを介してＤＩＰを受信する。要求したＤＩＰを受信すると、デコーダ３４７は、ＤＩＰパケットのＯＰコード部に基づいて動作する。１実施形態では、ＤＩＰデコーダモジュール３４７は、各ＤＩＰ・ＯＰコードと関連するマイクロコードを含む。特定のＯＰコードをに基づいて、ＤＩＰシーケンサ３４５は、ＤＩＰ出力制御モジュール３４８を介して、ビデオプロセッサ部３５０とインタフェースをとる。
【００６４】
例えば、特定のＤＩＰ中のＯＰコードが、含まれているピクチャ・コンフィギュレーション・データを示している場合、特定の情報でそれをコンフィギュレーションするために、ＤＩＰデコーダモジュール３４７は、ビデオプロセッサ３５０の適切なレジスタに書き込む機能を、ハードウェアまたはソフトウェアを用いて実行する。例えば、ソースピクチャサイズと、ＤＩＰパケットの一部を含むターゲットピクチャサイズとに関連する情報のような特定のスケール情報が、スケールエンジン３５２の機能を制御する１以上のレジスタに記憶可能である。
【００６５】
図１０〜１４は特に、特定の実施形態において、ビデオプロセッサ３５０を用いるスケーリングプロセスのＤＩＰの使用に関連する。
【００６６】
ここに開示する１実施形態では、ＤＩＰシーケンサが、デバイスメモリ３９０に記憶されたＤＩＰにアクセスし、マクロブロックを表す情報をビデオプロセッサ３５０に供給する。一般に、トランスコーダ３５０に供給されるＤＩＰデータは、ビデオのマクロブロックを表す圧縮データである。ビデオプロセッサ３５０にデータを供給することによって、適切な伸張情報に従って、ビデオプロセッサは、データを伸張し、伸張マクロブロックデータを抽出する。説明として、圧縮されていないマクロバッファデータがスケールバッファ３５１に記憶される前に、ビデオプロセッサ３５０によって実行される、いくつかの伸張方法があり得ることは理解されるであろう。しかしながら、以下説明のために、ＤＩＰシーケンサが、スケールバッファにマクロブロックデータを供給することが述べられる。さらに理解すべきであるのは、本開示の他の実施形態では、ＤＩＰシーケンサは、ビデオプロセッサによって行われる伸張機能のいくつかあるいはすべてを実行することができることである。
【００６７】
スケールブロック３６０のスケールバッファ３５１に、マクロブロックが記憶されると、スケールエンジン３５２が、スケールバッファ３５１に記憶されたマクロブロックにアクセスして、スケーリングされたマクロブロックを供給し、スケールエンジンは、従来のスケーリング方法、あるいは本明細書に開示するスケーリング方法を用いて、スケーリングされた画像を生成する。本発明をより容易に理解するために、画像フレームに対するマクロブロックの関係を示す図１０を参照するとよい。
【００６８】
図１０は、マクロブロックＭ（０，０）からＭ（ｎ，ｍ）を含むビデオフレームを示す。説明のために、図１０のマクロブロックは、フレームデータを表すように記載されているが、他の実施形態では、図１０のマクロブロックは、フィールドデータ、またはフレームあるいはフィールドの一部のみを表していてもよい。
【００６９】
図１０のフレームは、特定の解像度に関連している。例えば、図１０のフレームは、１９２０画素×１０８０画素の解像度をもつソースフレームを考慮している。各マクロブロックは、フレームの１６画素×１６画素部分を表すので、１フレームを表すために用いられるマクロブロックの数は、フレームの解像度に依存する。なお、マクロブロックという用語は、特定の意味をもつ一方、説明および／または実施のために、本発明の他の実施形態では、従来のマクロブロックとは異なるブロックサイズが使用されることもある。
【００７０】
動作においては、図１０に示すフレームのマクロブロックは、スケールバッファ３５１に記憶され、その後スケールエンジン３５２によりアクセスされ、スケーリングされた画像を表すデスティネーション・マクロブロックを生成する。例えば、１９２０×１０８０より少ない、例えば１２８０×７２０の解像度のデスティネーション画像を生成するためには、スケールエンジン３５２が、複数のソースマクロブロックにアクセスする必要がある。図１０に示すように、行がＤＭ０で列がＤＭＣ０で表される、新たなマクロブロックＤＭ（ＤＭＲ０，ＤＭＣ０）を生成するために、４つのマクロブロックが必要である。言い換えれば、画像がダウンスケールされる場合、単一のデスティネーション画像は２以上のソースブロックから生成されるということである。
【００７１】
スケールエンジン３５２が効率的にスケーリングを行うために、ソースマクロブロックは、スケールバッファ３５１を通ってスケールエンジン３５２に利用されることになる。ここに開示する特定の実施形態では、これは、マクロブロックの第１のセット、例えばデータの１つのスライス（すなわち、マクロブロックの第１行（０，０）から（ｎ，０））あるいは第１の複数のスライスを取り込むことによって行われる。新たなデスティネーションスライスは、ＤＭＲ０で区切られる水平データを含む新たな行あるいはマクロブロックを生成する。したがって、ソースマクロブロックの単一スライスは、新たなスライスを表すために用いる、デスティネーションマクロブロックを生成するのに十分な、マクロブロックデータを含んでいない。ここに開示する特定の実施形態では、マクロブロックの行の一部のみがまた取り込まれる。例えば、デスティネーション・マクロブロックＤＭ（ＤＭＲ０，ＤＭＣ０）を生成するためには、マクロブロックの第２行Ｍ（ｘ，１）のソースマクロブロックＭ（０，１）とＭ（１，１）が必要である。この特定の実施形態は、公知の方法を超える効率を提供できる。すなわち、デスティネーションブロックが、ビデオデータのすべてのスライスをスケールバッファに記憶することなく、生成されるので、スケールバッファのサイズを減少させることができる。
【００７２】
いったんデスティネーション・マクロブロックが生成すると、次のデスティネーション・マクロブロックを生成するのに、ソースマクロブロックを必要としない。なお、この実施形態では、スケールバッファのサイズは、具体化された実際のスケールファクタにより決定されるか、あるいは具体化の可能性のあるスケールファクタの最大値によって決定される。例えば、図１０を参照すると、指示されたデスティネーション・ブロックサイズに対して、デスティネーション・マクロブロック（Ｍ（ＤＭＲ１，ＤＭＣ１）を参照）を生成するのに、９個のソースマクロブロックと同数のものが必要とされる。この実施形態では、スケールバッファは、２個のスライスに加えて、第３のスライスの３個の付加的なマクロブロックを格納する必要がある。付加的なバッファリングを提供して、スケールエンジン３５２をストップさせないことが望まれる場合には、第３のスライスのより大きな部分を含むことになる。
【００７３】
この実施形態の１つの利点は、ソースマクロブロックが、例えば走査順序に関連して順次記憶されるので、マクロブロックを表すＤＩＰパケットが順次アクセスされることである。図１１は、アドレス空間に順次に直接記憶された各マクロブロックに対するＤＩＰパケットを示す。ここに開示する特定の実施形態によると、各ＤＩＰパケットは異なるサイズをもつことがある。ＤＩＰパケットに順次アクセスすることによって、あるパケットが始まり、他のパケットが終了する箇所を、ＤＩＰシーケンサが判定することができる。したがって、マクロブロックの特定のスライスに関連するすべてのＤＩＰパケットを、メモリ３９０に順次記憶することにより、隣接するマクロブロックを、メモリ３９１から順次アクセスすることができる。
【００７４】
図１２は、フレームメモリでも、キャッシュメモリでもよいメモリデバイス３９０の一部に記憶される、ＤＩＰデータ３９１を示す。メモリ表示３９１に示すとおり、ＤＩＰ（０，０）からＤＩＰ（ｎ，ｍ）までのメモリに、ＤＩＰデータ３９１が順次記憶される。１実施形態では、連続するＤＩＰのそれぞれの位置は、カレントのＤＩＰが読み込まれた後にのみ識別可能となる。一般に、これは、リニアなメモリ空間に関連して、お互いに直接隣接する位置にＤＩＰを記憶することによって達成される。スケールバッファ３５２に記憶されるデータを示すメモリ表示３５２は、ＤＩＰデータ３９１から生成されるマクロブロックデータを表している。なお、図１２には、第１のスライスに関連したマクロブロックと、マクロブロックＭ（０，１）からマクロブロックＭ（３，１）が記憶されていることが示されている。これは、デスティネーション・マクロブロックＭ（ＤＭＲ０，ＤＭＣ０）を生成するのに必要なマクロブロックの数より多いが、これにより、スケールエンジン３５２がストップしないことを保証するための付加的情報を記憶することができる。明らかなように、付加的なスケールバッファサイズは、本発明の設計事項である待ち時間に依存して選ばれる。
【００７５】
図１３、１４は、本発明の他の実施形態を示す。これによれば、次のデスティネーション・マクロブロックを生成するために必要なソースマクロブロックのみを記憶することによって、より小さなサイズのスケールバッファ３５１を使用できる。図９のシステムにとっては、特定のデスティネーション・マクロブロックを復号するためには、走査列に関して順番に並んでいない特定のＤＩＰにアクセスする必要があることは明らかである。図１３は、特定のシーケンス３５３に記憶されたＤＩＰデータを示し、特定のＤＩＰの位置を識別するポインタを示す。図１４にさらに示すように、特定のマクロブロックを表す個々のＤＩＰに対するポインタは、メモリ３９０のＤＩＰポインタテーブル部に記憶される。
【００７６】
１実施形態では、ポインタ値は、各ポインタ間に公知のスペースを設けて、ＤＩＰポインタ部に記憶される。例えば、ポインタ値は、直接隣接するワードで記憶することができる。公知の、または予め計算可能な位置に記憶されたポインタをもつことにより、生成される予定のデスティネーション・マクロブロックに基づいて、ＤＩＰ入力制御モジュール３４６が、特定のＤＩＰにアクセスすることができる。順に並んでいないＤＩＰへアクセス可能であることは、公知技術および先に説明した方法以上の利点であり、特定のデスティネーションマクロブロックを生成するために、スケールエンジン３５２が必要とするソースマクロブロックを格納するだけでよいので、縮小したサイズのスケールバッファを実現することができる。したがって、ＤＩＰ入力制御モジュール３４６が、所望のデスティネーション・マクロブロックを生成するのに必要なだけのソースＤＩＰにアクセスすることができる。例えば、図１４を参照して、マクロブロックＭ（０，０），Ｍ（１，０），Ｍ（１，０），Ｍ（２，０）に関連するＤＩＰのみにアクセスして、デスティネーションマクロブロックＭ（ＤＭＲ０，ＤＭＣ０）を生成することができる。
【００７７】
ここに開示する１実施形態では、ソースＤＩＰは、実際の走査順にメモリ３９０内に記憶される。他の実施形態では、ソースＤＩＰパケットは、スケーリング順のような予想されるアクセス順に記憶される。スケーリング順という用語は、特定の順のデスティネーション・マクロブロックの生成に供するようにアクセスするために、ソースマクロブロックが必要とする順序を示すために用いられる。例えば、マクロブロックの走査順の列が、マクロブロックの各行を横切って左から右へ、最上位の列から始めて最下位の列に進むのに対して、スケーリング順の列は、デスティネーション・マクロブロックが生成される順に基づいている。したがって、生成されるデスティネーション・マクロブロックの順は、Ｍ（ＤＭＲ０，ＤＭＣ０）に続いてＭ（ＤＭＲ０，ＤＭＣ１）であり、走査列の１例では、ソースマクロブロックを次の順：Ｍ（０，０），Ｍ（１，０），Ｍ（０，１），Ｍ（１，１），Ｍ（２，０），Ｍ（３，０），Ｍ（２，１），Ｍ（３，１）でアクセスすることになる。なお、ここで、マクロブロックＭ（０，０）とＭ（１，０）は、マクロブロックＭ（ＤＭＲ０，ＤＭＣ１）を生成するときだけ使用されるので、必要がなくなれば、次のマクロブロックによって書き換えられることができる。
【００７８】
ポインタテーブルが保持され、連続するＤＩＰが記憶される場所を示すので、ＤＩＰ自体がメモリに記憶される実際の順序は、ＤＩＰが記憶されている場所を知るためにはそれほど重要ではない。しかしながら、他の実施形態では、ＤＩＰは、走査アクセス順とは逆に、スケーリングアクセス順に記憶され、連続的にすぐにアクセスすべきデータが、メモリの共通のページに記憶される可能性を大きくして、メモリからのＤＩＰデータへアクセスに関連する待ち時間を減らすことができる。同様に、ＤＩＰポインタが保存される実際の順序は、スケーリングの順序あるいは走査順とは異なる順序に基づくことができる。この場合、ポインタ自体は、例えば走査アクセス順に関連して連続的なＤＩＰをアクセスするように記憶され得る。
【００７９】
図１５〜１８は、本開示による特定の方法を示す。図１５は、本開示による特定の情報記憶方法を示し、ステップ８１０では、マクロブロックの第１のセットがスケールバッファに記憶される。１実施形態では、マクロブロックの第１セットは、特定のピクチャフレームに関連するビデオ情報の１以上のスライスを含む。１以上の全スライスに関連するマクロブロックを記憶することにより、それぞれ隣接して記憶されたＤＩＰの最初と最後を判定可能にする。
【００８０】
ステップ８１１では、マクロブロックデータの第２のセットがスケールバッファに記憶される。マクロブロックデータの第２セットは、フレームデータのスライスの一部を表す。先に説明したように、１実施形態では、第２のセットのデータは、新たにスケーリングされるマクロブロックのセットの生成を開始するのに必要なビデオスライスのマクロブロックを含む。
【００８１】
図１６には、本開示の特定の実施形態による他の方法を示す。図１６の方法は、図１５を参照して説明したステップ８１０とステップ８１１を含む。ステップ８１２では、付加的なマクロブロックが、スケールバッファに記憶される。例えば、ステップ８１０と８１１は、新たなデスティネーションマクロブロックのスケーリングを開始することを可能にするソースマクロブロックのみを記憶するのに対し、付加的なソースマクロブロックをスケールバッファに記憶することにより、スケーリングエンジン３５２が行き詰まることなく、付加的なマクロブロックを生成することができる。例えば、単一の新たなデスティネーションマクロブロック生成するために必要な第２セットのマクロブロックの最大値が、３である場合、ステップ８１２では、十分な付加的マクロブロック（すなわち６個のマクロブロック）を記憶して、スケールバッファが常に十分な情報を有して、中断することなくスケーリングされたマクロブロックの生成を進めることができることを保証することができる。
【００８２】
ステップ８１３では、図１６の方法によりフレームバッファと関連するすべてのマクロブロックを、スケールバッファに記憶したか否かが判定される。すべてのマクロブロックが記憶されたなら、このフローは終了する。フレームのすべてのマクロブロックがまだ記憶されていないのなら、フローはステップ８１４に進み、次のマクロブロックがフレームバッファに記憶される。ステップ８１４で次のマクロブロックを記憶すると、もはや使用されない前のマクロブロックを上書きすることができる。図１６の方法は、１以上の全スライスデータおよび次のスライスデータの一部を記憶し、全ビデオスライスを記憶することを避ける方法を示す。さらに、図１６の方法は、ポインタテーブルを用いないで、走査順に記憶したＤＩＰの使用を容易にする。
【００８３】
図１７の方法は、概して図１６の方法と類似している。ステップ８１８とステップ８１４では、スケールバッファに最初のマクロブロックを取り込む。続いて、ステップ８２０で、新たなマクロブロックが、記憶された情報に基づいて生成される。新たなマクロブロックが生成されると、フローはステップ８３０に進み、フレームバッファが完成したか否かを判定する。完成していない場合、フローはステップ８３５に進み、次のマクロブロックが取り込まれ、フローはステップ８２０に戻り、新たなマクロブロックを生成する。このループは、全フレームが生成されるまで繰り返される。
【００８４】
図１８には、本開示の他の実施形態によるＤＩＰを生成する方法を示す。ステップ８６０で、フレームの第１のマクロブロックが、カレントマクロブロックとして識別される。一般に、フレームの第１のマクロブロックは、表示装置において表示又は走査される第１の画素となる画素を含むマクロブロックである。代表的には、特定フレームの左上のマクロブロックである。
【００８５】
１実施形態では、特定のフレームの第１のマクロブロックが、メモリに記憶された基本ストリームから識別される。基本ストリームは、一般にＭＰＥＧストリームのようなディジタルビデオデータの受信結果としてメモリに記憶される。
【００８６】
ステップ８６１では、カレントマクロブロックに対して、ＤＩＰが生成される。１実施形態では、ＤＩＰ・ＯＰコードと、メモリからＤＩＰパケットのペイロード部にアクセスされるビデオデータ表現とを含むことによって、ＤＩＰが生成される。ここでＯＰコードは、ＤＩＰパケットがマクロブロック情報を含むことを示すものである。他の実施形態では、基本ストリームデータからアクセスされるマクロブロック情報をまず処理して、ＤＩＰに記憶する前にマクロブロックデータに対する特定のフォーマットを生成することが可能である。
【００８７】
ステップ８６２では、カレントＤＩＰがメモリに記憶される。１実施形態では、カレントＤＩＰは、フレームバッファに関連する巡回バッファに記憶される。この実施形態では、ＤＩＰは、ビデオ処理装置の次の部分によりすぐにアクセスされる。他の実施形態では、ＤＩＰはシステムメモリ資源、例えばビデオ処理装置による後のアクセスのためのハードディスク装置に記憶される。
【００８８】
ステップ８６３では、カレントＤＩＰに対するポインタが、ＤＩＰポインタ位置に記憶される。ＤＩＰには、種々のサイズが可能であるから、カレントＤＩＰが記憶されている場所を示すポインタをもつことによって、カレントＤＩＰの位置を記録しておくことは、有用である。これにより、カレントＤＩＰを次々に順番を変えてアクセスすることができる。ポインタは、予め決められた公知の方法により、メモリのポインタ位置に記憶される。例えば、ポインタのそれぞれは固定サイズとすることができ、これによりポインタ間は固定距離となる。特定のマクロブロックを生成するために必要とされるマクロブロックのみを、スケールバッファに取り込み、これによりスケールバッファに要求されるサイズを減少することが望まれる場合には、このことは有利である。
【００８９】
ステップ８４０では、図１８のフローが実行されたか否かについて判断する。１実施形態では、特定のフレームの基本ストリームからＤＩＰを生成することによって、データの１フレーム全体が処理された場合、またはもはや処理すべきデータがない場合、図１８のフローがなされたことになる。処理がなされたときには、フローは終了する。そうでない場合はフローはステップ８６４に進む。
【００９０】
ステップ８６４では、そのフレームの次のマクロブロックが、カレントマクロブロックとして識別される。１実施形態では、次のマクロブロックは、走査順での次のマクロブロックである。他の実施形態では、次のマクロブロックは、アクセスが予想される次のマクロブロックである。例えば、アクセスされるべき次のマクロブロックは、スケーリング順での次のマクロブロックである。
【００９１】
図１９には、本発明の特定の実施形態による他の方法を示す。具体的には、ステップ８５１で、可変サイズのＤＩＰが第１の順序で記憶される。この第１の順序は、走査順、またはスケーリング順、あるいはその他の順序に相当する。
【００９２】
次いで、ステップ８５２で、記憶されたＤＩＰは、第１の順とは異なる第２の順でアクセスされる。例えば、ＤＩＰが、ステップ８５１で走査順に記憶される場合、ＤＩＰは、ステップ８５２でスケーリング順にアクセスされる。先に説明したように、ＤＩＰは、各ＤＩＰが記憶されている場所を示す項目を有するポインタテーブルをもつことにより、異なる順でアクセス可能となる。したがって、ＤＩＰが、スケーリング順のような第１の順で記憶される場合でも、特定のＤＩＰが始まる場所を決定するために、複数のＤＩＰを通じてパーシングすることなく順に並んでいないＤＩＰにアクセス可能である。特定の新たなマクロブロックを生成するのに必要なだけのマクロブロックがスケールバッファに記憶される実施形態においては、図１９に示された特定の実施形態を具体化する実施形態は有利である。
【００９３】
図３を参照すると、ビットマニピュレータ３３５が汎用データプロセッサ３３０に接続している。特定の実施形態では、汎用データプロセッサ３３０は、ここに説明される特定用途向け集積回路（ＡＳＩＣ）の一部として半導体装置に集積されたマイクロプロセッサ／マイクロコントローラ・コアである。同様に、ビットマニピュレータ３３５は、ＡＳＩＣに集積され、データのビット操作をサポートするために、プロセッサ３３０によりアクセス可能である。
【００９４】
１実施形態の動作では、プロセッサ３３０は、マイクロコントローラ３４０に読出し要求を出す。プロセッサ３３０はさまざまな状況に応答する読出し要求を生成可能である。そのような状況には、新たなアドレスのデータが要求されたとき、ビットマニピュレータにバッファリングされたデータが所定の水準に達したとき、およびプロセッサ３３０が、ビットマニピュレータにおけるデータ量が所定の数より少ないと判断するときなどがある。１実施形態では、プロセッサ３３０は、ビットマニピュレータに関連するレジスタを読み出して、ビットマニピュレータにおけるデータ量を決定することができうる。他の実施形態では、プロセッサ３３０は、特定の量のデータが使用されたことを示す割り込みを、ビットマニピュレータから受けることにより、ビットマニピュレータにおける利用可能なデータ量を決定することができる。
【００９５】
図示の具体例では、プロセッサにより要求されたすべてのデータは、ビットマニピュレータ３３５を介して戻される。なお、他の実施形態では、どのデータがビットマニピュレータ３５を介して戻されるべきか、どのデータが直接プロセッサ３３０に戻されるべきかを、プロセッサ３３０がメモリコントローラ３４０に指示することは可能である。図示のように、データは、バス、例えば専用バス、リードバス、リード／ライトバスを介して、ビットマニピュレータ３３５に戻される。
【００９６】
１実施形態のこれに代る動作では、ビットマニピュレータ３３５はプロセッサ３３０とインタフェースをとって、それ自身のメモリ制御ロジックがメモリコントローラ３４０からデータを要求することができる。
【００９７】
ビットマニピュレータ３３５によって受信されたデータは、引き続きプロセッサ３３０によってアクセスされる。１実施形態では、データは、ビットマニピュレータ３３５に関連するレジスタを読み出すことにより、データプロセッサ３３０によりアクセスされる。例えば、数値Ｎをプロセッサ３３０のリードバスのバスサイズとして、１〜Ｎまでの特定の数値を返すレジスタのセットを、ビットマニピュレータ３３５に備えることができる。さらに、ビットマニピュレータは、返されるデータの第１ビットの位置を示すビットオフセット・レジスタをもつことができる。他の実施形態では、データは、データサイズを指示する制御信号を与え、適切な制御情報を与えることにより、ビットマニピュレータからアクセスされる。
【００９８】
図２０は、ラインバッファ９１０と、ビットアクセスコントローラ９０５と、レジスタ９３０と、割り込みロジック９２０を含むビットマニピュレータ３３５の特定の具体例を示す。
【００９９】
１実施形態では、ラインバッファ９１０は、先入れ先出し（ＦＩＦＯ）として動作する巡回バッファであり、メモリコントローラ３４０を介してメモリから返されるデータを記憶する。１実施形態では、受信データは、メモリからのデータバスのサイズに基づくサイズの１ワードをもつ。例えば、ラインバッファは、３２ビット幅のデータワードを受信でき、そこではメモリ設定が３２ビットのワードをサポートする。他の実施形態では、データバスのサイズは、汎用プロセッサ３３０のデータバスのサイズに基づく。
【０１００】
ビットアクセスコントローラ３３５は、プロセッサ３３０からの特定のデータに対する要求を受信し、プロセッサのデータバスを介して要求された特定のビットを提供する。なお、プロセッサ３３０とビットマニピュレータ３３５間のデータバスのサイズは、メモリとビットマニピュレータ間のデータバスのサイズとでは異なる。図示の例では、プロセッサ３３０へのデータバスは、１６ビット幅のバスである。プロセッサ３３０からの要求に基づいて、１〜１６ビットのデータが返される。なお、最大値より少ないデータビットがプロセッサ３３０に返される場合、未使用ビットは、所定の設定、すなわち固定した設定または可変の設定に基づいて、１による充填または０による充填のいずれかが行なわれる。
【０１０１】
レジスタ９３０は、プロセッサ３３０によりアクセス可能で、ビットアクセスコントローラ９０５とラインバッファ９１０とに接続されて動作可能である。１実施形態では、明細書で詳細に説明するように、プロセッサ３３０は、ビットマニピュレータ３３５の状態を監視し、ビットマニピュレータ３３５に制御を与え、レジスタ９３０へのアクセスによりビットマニピュレータ３３５からのデータにアクセスする。
【０１０２】
割り込みロジック９２０を用いて、ビットマニピュレータ３３５で利用可能なデータ量を追跡する。１実施形態では、ラインバッファ９１０で所定量のデータが使用されるときは常に、１つの割り込みがプロセッサ３３０に加えられる。他の実施形態では、特定の数のデータがラインバッファ９１０から読み出された場合はいつも、割り込みの発生を指示するように、レジスタセット９３０からなるレジスタをプログラミングして、所定量のデータは、ユーザが選択可能とすることができる。例えば、８ビット、１６ビット、３２ビット、６４ビット、又は１２８ビットのデータが使用されたことを監視できるように、レジスタはプログラミングされる。他の実施形態では、ラインバッファに記憶されたカレントデータのバイトの合計が、レジスタセット９３０の１レジスタに保持される。
【０１０３】
プロセッサ３３０に対して、ラインバッファで利用できるデータ量を監視する方法を与えることにより、プロセッサ３３０が、メモリアクセス要求をメモリコントローラ３４０に行なうことができ、データがビットマニピュレータに保持されることを確実にする。また、プロセッサ３３０に対して、ラインバッファで利用できるデータ量を監視する方法を与えることにより、データ要求がビットマニピュレータ３３５に求められる前に、プロセッサ３３０によりキャッシュメモリでデータを利用できるようにする。この結果、ビットマニピュレータへの読出しにより、キャッシュされるはずのデータアクセス要求がうまくいかないようであれば、プロセッサ３３０は、ビットマニピュレータへのデータ要求を遅らせることができる。
【０１０４】
図２１は、図２０の一部をより詳細に示すもので、レジスタセット９３０とラインバッファ８１０とを含む。
【０１０５】
レジスタセットは多くのレジスタを有し、これらのレジスタには、ラインバッファの記憶位置をもつアドレス範囲を特定するトップレジスタとベースレジスタが含まれる。テールレジスタは、データがアクセスされる予定のラインバッファの次の有効なラインを指定する。なお、ポインタは、データがアクセスされるラインバッファの実際のラインを指示してもよいし、またデータがアクセスされる実際のラインバッファラインからのオフセットである、ラインバッファのラインを指示するようにもできる。ヘッドレジスタは、有効なデータが記憶されるラインバッファの次に利用可能なラインを指定する。
【０１０６】
ビットオフセットレジスタは、アクセスされる次のビットのセットのうちの第１ビットに対するオフセットを示す。例えば、図２１は、ビット３を指定するビットオフセットポインタを示す。ビットオフセット値により指示されたビットは、ビットマニピュレータ出力によって左揃えされたビットである。なお、これに替わる実施形態では、戻されるビットは、右揃えすることもできる。
【０１０７】
ウォータマークレジスタは、付加的データがラインバッファに取り込まれる時を指示する値を記憶する。ウォータマーク値は、テールポインタまたはヘッドポインタからのオフセットを指示するようにできる。オフセットは、テールポインタまたはヘッドポインタとそれぞれ比較されて、データをいつアクセスするかを決定できる。これに代えて、ウォータマーク値は、固定位置を指示することもでき、テールポインタと比較して、データをいつアクセスするかを決定することができる。さまざまな実施形態でウォータマークを用いて、割り込みプロセッサ３３０の処理を初期化することでき、あるいはプロセッサ３３０がウォータマークおよびその他のレジスタを読み込んで、ビットマニピュレータに付加的データを取り込む時期を決定することができる。
【０１０８】
先に説明したように、ラインバッファ・カウントレジスタは、ラインバッファに関連する有効なデータ量を指示する値を記憶する。例えば、ラインバッファ・カウントレジスタは、ラインバッファ９１０に記憶された、これからアクセス予定のバイト数を指示する。
【０１０９】
図２２は、ビットマニピュレータ５３５を通る機能データフローを示すブロック図である。メモリロケーション９５５は、プロセッサ３３０のデータバスのサイズの少なくとも２倍のデータを記憶する。プロセッサ３３０に供給されるデータデータワードの第１ビットは、任意のビット位置に配置され得るので、この供給されるワードは次のカレントとなる２つのワード内に位置する可能性がある。マルチプレクサ９５０を使用して、ロケーション９５５の１ワードから次へ移行するビットオフセット値に応答して、次のワードを記憶ロケーション９５５に取り込む。図示された実施形態では、マルチプレクサ９５０への入力は、１６ビット幅である。マルチプレクサ９５０に次の１６ビットを供給するために、付加的ロジック（図示せず）を用いることができることは明らかである。
【０１１０】
図２３には、ビットオフセット値を更新する特定の実施形態をブロック図により示す。この実施形態では、カレントビットオフセット値と読み出されるビット数のサイズとを入力とするモジュロ加算器を示す。加算器の出力は、新たなビットオフセット値を提供する。
【０１１１】
ビットシフタ９６０は、ビットオフセットに基づいて、ロケーション９５５に記憶されたビット値を整列させて、ビットシフタ９６０による出力データの左側のビットが、ビットオフセット値によって特定されるものであるようにする。マスク９６２は、データ要求によって特に要求されていないビットに対して、零を充填するかまたは１を充填する。例えば、１実施形態では、３ビットのデータが要求されている場合、それらは左に位置合わせされる一方、マスクは、右側の１３ビットに零を充填する。
【０１１２】
本発明の１実施形態では、Ｘを返送するビット数を特定するものとして、ＧＥＴ＿ＢＩＴ（Ｘ）関数に応答して、ビットマニピュレータ３３５へのアクセスが行なわれる。内部レジスタおよびプロセッサ処理を用いないで、プロセッサ３３０が、ビットマニピュレータ３３５のレジスタに対応する特定のアドレス位置をアクセスする。例えば、１６個のアドレス位置（レジスタ）を用いて、ＧＥＴ＿ＢＩＴ（１）からＧＥＴ＿ＢＩＴ（１６）までの１６個の命令を実現できる。ここでは、ビットマニピュレータ３３５は、要求された量のデータを返送し、ビットオフセット値を含み、読み出されるデータ量によってインクリメントする、レジスタを適正に更新する。他の実施形態では、特定の数のビットにアクセスはするが、ビットオフセットレジスタあるいはテールレジスタをインクリメントしないビットマニピュレータに、付加的命令が与えられる。例えば、１実施形態では、テールレジスタをインクリメントせずに、データの１ワード全体をアクセスする。
【０１１３】
先に説明した実施形態では、データ命令パケットは、マクロブロックデータをトランスコーダ３５０に送るために用いられる。例えば、ソースマクロブロック情報データは、トランスコーダ３５０で、ＤＩＰの一部として受信される。図３に戻ると、ビデオデータ（すなわち、ソース動きベクトルおよび量子化情報）は、メディアデータストリームの一部であり、装置３０３で受信され、後の処理のために用意されているデバイスメモリ３９０に記憶される。次に、システム３０３は、ソース動きベクトルを含む記憶されたデータを検索し、トランスコーダ２５０によって使用されるＤＩＰを生成する。１実施形態では、ＤＩＰは、復号および符号化機能の動作を制御するために、トランスコーダ３５０で受信される。１実施形態では、第１のＤＩＰは、ソース画素データを生成するために、デコーダで使用されるソースマクロブロック情報を含み、第２のＤＩＰは、動きベクトル予測が実行されることを可能にする、エンコーダによって用いられるソース情報を含み、これは、２００１年３月２７に出願された係属中の特許出願であり、参照によりこの明細書に組み込まれる出願番号０９／８１９，１４７号の名称を「ビデオストリームの圧縮方法および装置」とする特許出願において説明されている。
【０１１４】
動きベクトルと量子化情報がＤＩＰの一部として送信される場合、特定のマクロブロックに対するマクロブロック情報は、メモリコントローラ３４０とデバイスメモリ３９０との間で７回転送される。第１に、マクロブロック情報データを最初に受信したとき、第２に、デコーダＤＩＰをアセンブルするために検索するとき、第３に、エンコーダＤＩＰをアセンブルするために検索するとき、第４に、デコーダＤＩＰを記憶するとき、第５に、エンコーダＤＩＰを記憶するとき、第６に、デコーダＤＩＰがデコーダにアクセスされるとき、第７に、エンコーダＤＩＰがエンコーダにアクセスされるときである。本開示によるこれに替わる実施形態が、ここに説明される。それは、マクロブロック情報が、メモリコントローラ３４０とデバイスメモリ３９０との間で送信される回数を減少させ、メモリ帯域量を減少させる者である。このようなメモリ帯域を有効に利用する代替実施形態は、図２４〜２９で説明される。
【０１１５】
図２４は，本発明の特定の実施形態を説明する方法を示す。図２４の方法は、図３および図２５〜２７を参照して説明される。ここで、図２５は、ブロック図により、お互いに重畳されたソースおよびデスティネーションマクロブロックのビデオフレームを示し、図２６は、ブロック図により、図２４の方法に関連するデータのメモリマップを示す。
【０１１６】
図２４に示された方法のステップ１０１０では、ソースビデオ情報が受信される。図３を参照すると、ソースビデオ情報は、メディアデータストリーム３１０の一部である。１実施形態では、ソースビデオ情報は、例えばＭＰＥＧタイプの情報に関連するマクロブロック情報を含む。図２５は、Ｘ×Ｙアレイで形成される多数のマクロブロックをもつ、細い実線で描かれたソースフレームを示し、Ｘは、特定のマクロブロックを表わす数であり、Ｙは、マクロブロックの特定の行を表わす数である。例えば、ソースマクロブロック（１，２）は、ＳＭＢ（１，２）とも表され、ソースフレームの列１および行２の双方に位置するソースマクロブロックである。
【０１１７】
ステップ１０１２では、ソースビデオ情報が記憶される。この特定の実施形態に関しては、ソースビデオ情報のマクロブロック情報部分に焦点を絞って説明する。図２６は、ソースデータアレイが保存されているメモリマップを示す。１実施形態では、ソースデータアレイ内の各ノードは、特定のマクロブロックに関連するマクロブロック情報とともに、対応するマクロブロックに対する特定のマクロブロック設定データ（ＭＢＣＯＮＦＩＧ）を含む。図３を参照すると、ソースビデオ情報は、メモリ３９０に記憶されることが可能である。
【０１１８】
ＭＢＣＯＮＦＩＧフィールドに記憶されたマクロブロック設定データは、特定のマクロブロックに関係する種々の情報を含む。例えば、ＭＢＣＯＮＦＩＧフィールドは、動き補償動作が、順方向予測、逆方向予測、または双方向予測のいずれかを用いて処理されるか否かを指示することができる。さらに、ＭＢＣＯＮＦＩＧフィールドは、受信したソースビデオを復号あるいは符号化する後の目的に関連するあるいは有用な任意のタイプの情報を格納することができるばかりでなく、動きベクトルの第１または第２の最下位ビットが、使用される半画素精度の情報を識別するか否かを示すデータを記憶することができ、また、ピッチ・インジケータの値が、ソース動きベクトルアレイの次のノードにアクセスする方法を指示するために含まれるか否かを示すデータを格納することができる。
【０１１９】
ステップ１０１４では、デスティネーション・ピクチャ情報が受信される。一般に、デスティネーション・ピクチャ情報は、デスティネーション・ピクチャの解像度の情報をもつ。図２５には、デスティネーション・ピクチャ情報を示す。ソースフレーム上に重ねた太字の破線を参照されたい。デスティネーションフレームは、Ｍ×Ｎアレイに配置された多数のマクロブロックをもつ。ここで、Ｍは、デスティネーションフレームのマクロブロックの列を表す数であり、Ｎは、デスティネーションフレームのマクロブロックの行を表す数である。例えば、デスティネーションマクロブロック（１，２）またはＤＭＢ（１，２）は、デスティネーションフレームの列１と行２の双方にあるデスティネーションマクロブロックである。
【０１２０】
ステップ１０１６では、インデックステーブルが、デスティネーションピクチャ情報とソースピクチャ情報とに基づいて作成される。特に、各デスティネーションマクロブロックを生成するために、どのソースマクロブロックをアクセスする必要があるかが判断される。例えば、デスティネーションピクチャが、ソースピクチャに関連してダウンスケールされる予定の場合、図２５に示すように、ソースフレームからの複数のマクロブロックに、デコーダがデスティネーションマクロブロックを生成するのに必要な情報が含まれている。例えば、デスティネーション・マクロブロック（０，０）、すなわち図２６のアレイの左上部のデスティネーション・マクロブロックを生成するためには、デコーダ／エンコーダは、ソースマクロロックＳＭＢ（０，０）、ＳＭＢ（０，１）、ＳＭＢ（１，０）、ＳＭＢ（１，１）に対するソースマクロブロック情報を必要とする。デスティネーション・マクロブロックは、これらの各マクロブロックからの少なくともいくらかのデータを含むので、これらの４つのソースマクロブロックを必要とする。
【０１２１】
ソースおよびデスティネーションの画像解像度情報に基づいて、インデックステーブルが生成され、それは多数の項目をもち、各項目は、先にステップ１０１２で記憶されたマクロブロックのソース動きベクトルと量子化情報に対するポインタをもつ。インデックステーブルの項目は、他のインデックステーブルに関連して配置され、インデックステーブルが、例えば最初の項目から最後の項目まで、予め定められた方法でアクセスされるとき、項目中のポインタが使用され、デコーダおよびエンコーダによって必要とされる順序で、ステップ１０１２で記憶されたソース動きベクトルををアクセスし、デスティネーションマクロブロック情報を生成する。
【０１２２】
ステップ１０１６で生成されたインデックステーブルは、メモリに記憶される。図２６には、第１のマクロブロック情報（動きベクトル及び量子化情報を含む）インデックステーブルは、ＰＯＩＮＴＥＲ  １からＰＯＩＮＴＥＲ  ＬＡＳＴまでを含む。ＰＯＩＮＴＥＲ  ＬＡＳＴは、ビデオデータの特定のフレームを完全に生成するためにアドレスしなければならないソースマクロブロックの最後の動きベクトルを指示する。図２５の実施形態を参照すると、各デスティネーション・マクロブロックは、４つのソースマクロブロックからのデータを必要とし、したがって図２６のインデックステーブル１の項目の総数は、Ｍ×Ｎ×４である。
【０１２３】
インデックステーブル項目は、特定のソースノードに対するポインタを含むことに加えて、生成されるべきデスティネーション・マクロブロックに関連するラストソースマクロブロックを指示するフィールドを含む。このラストソースマクロブロック・インジケータは、デコーダ、またはエンコーダにより用いられ、デスティネーション・マクロブロックを生成するのに十分なソースデータが受信された時を判定することができる。
【０１２４】
図２７は、特定のインデックステーブルの内容を、テーブル形式で表したものである。図２７の第１の列は、特定のインデックステーブルの項目位置を示し、第２の列は、どのデスティネーションマクロブロック情報が入力ポインタにより参照されるかを示し、第３の列は、新たなデスティネーション・マクロブロックを生成するために必要なラストソースマクロブロック情報にどの入力が対応するかを示す。第３列の「１」は、その項目が、特定のデスティネーションマクロブロックを生成するために必要な最後のソースマクロブロックであることを示す。
【０１２５】
１実施形態では、項目位置１は、図２６に示されたソースデータアレイの第１項目に対応し、ＰＯＩＮＴＥＲ  １を含む。なお、特定のソースマクロブロックは一般に、インデックステーブルの１より多くの項目により参照される。例えば、図２７では、項目２および項目５の両方とも、ソースマクロブロックＳＭＢ（０，１）を参照する。これは、ソースマクロブロックＳＭＢ（０，１）が、デスティネーション・マクロブロックＤＭＢ（０，０）およびＤＭＢ（０，１）の両方に必要なデータを含むからである。
【０１２６】
ステップ１０１８で、インデックステーブルの項目を参照する１以上のデータ命令パケットが生成される。一般に、データにアクセスしてデスティネーション・マクロブロックを生成するために、デコーダおよびエンコーダによって用いられるインデックステーブルの第１項目を、このＤＩＰは参照する。なお、複数のデスティネーションターゲットが存在する場合には、付加的なインデックステーブルが生成され記憶される。マクロブック情報データを一度に記憶し、デコーダとエンコーダが特定の順でベクトルにアクセスできるような複数のインデックステーブルを生成することにより、生成される各デスティネーションピクチャについて、メモリが２セットのＤＩＰを保存しなければならない実施形態において、メモリ帯域を減少させることができる。
【０１２７】
図２８には、本発明による他の方法を示す。ステップ１０５０では、第１のインデックステーブルが、アクセスされる。先に説明したように、インデックステーブルの順番により指定される順が、デスティネーションマクロブロックを生成するためには、それに従って特定のマクロブロック情報すなわち１つのマクロブロック情報をアクセスしなければならない順となるように、インデックステーブルが格納されている。
【０１２８】
ステップ１０５２では、複数のソースマクロブロック情報が、第１のインデックステーブルの項目順に基づく第１の順にアクセスされる。図２７を参照すると、第１の複数のソースマクロブロック情報が、ＩＮＤＥＸ  ＴＡＢＬＥ  １の項目内に記憶されたポインタ値に基づいてアクセスされる。ステップ１０５４では、特定の画像データがステップ１０５２でアクセスされたデータに基づいて生成される。１実施形態では、デコーダは、アクセスされたマクロブロック情報を用いるソース画素セットを生成する。他の実施形態では、トランスコーダのエンコーダ部が、ステップ１０５２でアクセスされたデータに基づいて予測された動きベクトルを生成する。
【０１２９】
画素セットと予測された動きベクトルの生成は、一般にソース画素セットの生成と同時にリアルタイムで行なわれる。なお、同時リアルタイムということは、別個の処理モジュールを用いて２つの機能を同時に（まったく同じ時に）行って、システムのリアルタイム要求に応じることを意味するか、あるいは１以上の処理モジュールを順次使用して、これによりその処理モジュールが２つの機能を十分速く実行して、両方の結果に依存するアプリケーションのリアルタイム要求に対処することを意味する。
【０１３０】
例えば、ビデオアプリケーションの同時リアルタイムとは、デコーダからのソース画素とエンコーダからの予測された動きベクトルが十分速く生成され、所望のフレーム表示レートでデスティネーション・マクロブロックの生成に使用できることを意味する。例えば、特定のリアルタイム表示レートは、毎秒２０、３０、または６０回である。
【０１３１】
第２のデスティネーションシステムについて、ステップ１０５６、１０５８、および１０６０は、ステップ１０５０、１０５２および１０５８と類似している。例えば、２つのモニタが、ソース画像の表現を受信することができる。この特定の実施形態によると、付加的なソースデータすなわちソースマクロブロック情報の１つのコピーのみをメモリに格納するだけで、１以上のデスティネーション画像をサポートすることができることが分る。
【０１３２】
なお、ソース画像とデスティネーション画像間のスケーリングは、比較的頻繁に変更されるというものではないので、インデックステーブルは、一般に与えられた画像に対して静的である。ソースデータを記憶するために固定サイズノードを用いることによって、新たなソースフレームの各マクロブロックは、以前のマクロブロック・セットと同じマクロブックフットプリントに記憶するることができ、同じインデックステーブルを用いて、複数のフレームに対し変更なくマクロブロックデータにアクセスすることができる。
【０１３３】
図２９は、本発明による特定のシステムを示す。ビデオソースデータは、コントローラ部１１０２で受信され、コントローラ部１１０２は、入力ソースからのデータをパーシングし、少なくともソースマクロブロック情報の一部をメモリに記憶する役目をもつ。例えば、コントローラ１１０２は、図２６に示すソースデータアレイ情報を記憶する役割を果たす。なお、マクロブロック情報を含むノードは、インデックステーブル項目のポインタ値に基づいて、個々にアクセスされるので、それらは、お互いに独立して記憶でき、アレイに記憶される必要はない。１実施形態では、コントローラ１１０２は、プロセッサ３３０を用いるソフトウェアあるいはファームウェアで実現されることができる。
【０１３４】
コントローラ１１０２は、メモリコントローラ１１０４とインタフェースをとり、メモリコントローラ１１０４は、このデータを記憶するためにメモリ１１１１とインタフェースをとる。さらに、コントローラ１１０２は、ビデオソースから情報を得て、受信したソースビデオ画像のサイズを決定する。このソースのサイズは、解像度および／または各ソースフレームを表現するために用いられるマクロブロックの数を示す。ソースイメージサイズは、メモリ１１１１の一部あるいはレジスタのようなメモリローケーションでもよいブロック９１５で記憶される。さらには、デスティネーション画像サイズは、第１のデスティネーション画像サイズについてはブロック１１１６に記憶され、第２のデスティネーション画像サイズについてはブロック１１１７に記憶される。デスティネーション画像サイズは、エンコーダ１１０６により生成される所望の出力ピクチャの解像度を含む。説明のために、ブロック１１１６に記憶された第１のデスティネーション画像サイズのみが参照されるとする。なお、２以上のデスティネーション画像を生成することが求められるなら、２以上のデスティネーション画像サイズ部が含まれることは明らかである。１実施形態では、コントローラ１１０４は、図３に示したメモリコントローラ３４０に対応する。同様に、メモリ１１１１は、特定の実施形態では、デバイスメモリ３９０に対応する。
【０１３５】
インデックステーブル・ジェネレータ１１０９は、１１１５に記憶されたソースサイズおよび１１１６に記憶されたデスティネーションサイズを受信し、また他方ではアクセスする。ソースサイズおよびデスティネーションサイズに基づいて、インデックステーブル・ジェネレータは、先に説明したフォーマットをもつインデックステーブルを生成する。メモリコントローラ１１０４は、ジェネレータ１１０９によって生成されたインデックステーブルの格納をメモリ１１１１と連係させる。１実施形態では、インデックステーブル・ジェネレータ１１０９は、ソフトウェアあるいはファームウェアのコードを実行することにより、プロセッサ３３０によって実現されることができる。
【０１３６】
エンコーダ１１０６は引き続き、メモリコントローラ１１０４を用いて、インデックステーブル内の特定の項目のポインタを参照することにより、メモリ１１１１に記憶されたソースマクロブロック情報を探索する。同様の方法で、デコーダはまた、メモリ１１１１に記憶されたソースマクロブロック情報にアクセスすることができる。なお、エンコーダおよびデコーダは、特定の動きベクトルを得るために、メモリ１１１１に対する共通の読出しを可能にするように設計される。また、エンコーダおよびデコーダは、共通のキャッシュを共有して、メモリバスの使用を減少させる。１実施形態では、エンコーダ１１０６は、圧縮ブロック３６５（図３）の一部によって実現でき、デコーダ１１０７は、伸張ブロック３５５の一部によって実現できる。
【０１３７】
これまでの図の詳細な説明において、その一部である添付の図面が参照され、発明が実施された特定の好ましい実施形態が実例として示された。これらの実施形態は、当業者が本発明を実施することができるように、十分詳細に説明されている。また、他の実施形態が使用可能であること、本発明の精神または範囲から逸脱することなく、論理的、機械的、化学的そして電気的な変更が実行可能であることは明らかである。当業者が本発明を実施するために必要としない細部に立ち入ることのないように、当業者にとって公知である情報の説明を省略している。さらに、本発明を含む他の多様な実施形態は、当業者により容易に構成できる。したがって、本発明は、明細書に示された特定の形態に限られるものではなく、その反対に、代替例、修正例、および均等例を包含するものである。したがって、先の詳細な説明は、限定する意味はなく、本発明の範囲は、添付の特許請求の範囲により規定される。
【図面の簡単な説明】
【０１３８】
【図１】本発明の少なくとも１つの実施形態によるＭＰＥＧトランスコーダ・プロセッサを示すブロック図である。
【図２】本発明の少なくとも１つの実施形態によるＭＰＥＧトランスコーダ・プロセッサの動作を示すフローチャートである。
【図３】本発明の少なくとも１つの実施形態による圧縮ビデオトランスコーディング・システムを示すブロック図である。
【図４】本発明の少なくとも１つの実施形態によるベクトルプロセッサを示すブロック図である。
【図５】本発明の少なくとも１つの実施形態による圧縮ビデオトランスコーディング・プロセッサの動作を示すフローチャートである。
【図６】本発明の少なくとも１つの実施形態に開示されたトランスコーディング・システムを用いる方法を示す図である。
【図７】本発明の少なくとも１つの実施形態によるデータ命令パケットを示す図である。
【図８】図３の一部をより詳しく示す図である。
【図９】図３の一部をより詳しく示す図である。
【図１０】ピクチャフレームに関するソース・マクロブロックとデスティネーション・マクロブロックとの関係を示す図である。
【図１１】本発明の特定の１実施形態の線形アドレス空間に記憶されたデータ命令パケットを示す図である。
【図１２】メモリ装置に記憶されたデータ命令パケット情報と、これに対応するスケールバッファに記憶されたマクロブロック情報とを示す図である。
【図１３】本発明の他の実施形態の線形アドレス空間に記憶されたデータ命令パケット情報を示す図である。
【図１４】デバイスメモリに記憶されたデータ命令パケット情報とデータ命令パケットポインタと、これに対応するスケールバッファに記憶されたマクロブロック情報とを示す図である。
【図１５】本発明による特定の方法を示す図である。
【図１６】本発明による特定の方法を示す図である。
【図１７】本発明による特定の方法を示す図である。
【図１８】本発明による特定の方法を示す図である。
【図１９】本発明による特定の方法を示す図である。
【図２０】ビットマニピュレータの特定の実施形態をより詳細に示す図である。
【図２１】ビットマニピュレータのラインバッファとレジスタの特定の実施形態をより詳細に示す図である。
【図２２】ビットマニピュレータを通る作用を示すデータフローを表すブロック図である。
【図２３】ビット・オフセット・ポインタを生成する特定の方法または装置をブロック図の形式で示す図である。
【図２４】開示した特定の実施形態による方法をフローチャートの形式で示す図である。
【図２５】１フレームのソースマクロブロックに重なった１フレームの決定マクロブロックをブロック形式で表現した図である。
【図２６】開示した特定の実施形態を実現するために用いられるメモリをブロック形式で示す図である。
【図２７】特定の実施形態による図２６のメモリの一部に記憶されたデータを表形式で示す図である。
【図２８】開示した特定の実施形態による方法をフローチャートの形式フローチャート形式で示す図である。
【図２９】本発明によるシステムをブロック図の形式で示す図である。
【図１】
2005510981.tif 000003
【図２】
2005510981.tif 000004
【図３】
2005510981.tif 000005
【図４】
2005510981.tif 000006
【図５】
2005510981.tif 000007
【図６】
2005510981.tif 000008
【図７】
2005510981.tif 000009
【図８】
2005510981.tif 000010
【図９】
2005510981.tif 000011
【図１０】
2005510981.tif 000012
【図１１】
2005510981.tif 000013
【図１２】
2005510981.tif 000014
【図１３】
2005510981.tif 000015
【図１４】
2005510981.tif 000016
【図１５】
2005510981.tif 000017
【図１６】
2005510981.tif 000018
【図１７】
2005510981.tif 000019
【図１８】
2005510981.tif 000020
【図１９】
2005510981.tif 000021
【図２０】
2005510981.tif 000022
【図２１】
2005510981.tif 000023
【図２２】
2005510981.tif 000024
【図２３】
2005510981.tif 000025
【図２４】
2005510981.tif 000026
【図２５】
2005510981.tif 000027
【図２６】
2005510981.tif 000028
【図２７】
2005510981.tif 000029
【図２８】
2005510981.tif 000030
【図２９】
2005510981.tif 000031
【国際調査報告】
2005510981.tif 000032
2005510981.tif 000033
2005510981.tif 000034