JPH06195468A

JPH06195468A - ビデオ処理システム

Info

Publication number: JPH06195468A
Application number: JP5172728A
Authority: JP
Inventors: Kevin Harney; ハーニーケビン; Louis A Lippincott; エイリピンコツトルイス
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1992-06-19
Filing date: 1993-06-18
Publication date: 1994-07-15
Also published as: EP0574748B1; EP0574748A3; DE69313191T2; DE69313191D1; EP0574748A2; US5335321A

Abstract

(57)【要約】【構成】スケーラブル・プラットフォーム・アーキテ
クチャは種々のビデオ処理サブシステム間でデータを高
ビット速度で伝送するための高帯域幅バス（３２）を含
み、これにグラフィックスメモリを有するグラフィック
ス処理サブシステム（３１）が接続されている。グラフ
ィックス処理サブシステムはビデオメモリを受入れてビ
デオ処理を行うようにされている。高帯域幅バスには、
ビデオ処理サブシステム（１５）やビデオ捕捉システム
（１２）を含む種々のサブシステムを切り離し可能に接
続する拡張コネクタ（５６、５８）が設けられており、
さらに、この高帯域幅バスを低帯域幅バス（４２）ある
いは中央処理ユニット（３８）に結合するためのバスブ
リッジが設けられている。【効果】必要に応じて性能を高めることの可能なマル
チメディア・プラットフォーム・アーキテクチャが提供
される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明はビデオ信号処理に、更
に具体的には、ビデオ情報及びグラフィックス情報を表
すデジタル信号を供給するシステムに関するものであ
る。

【０００２】

【発明の背景】ビデオ信号処理技術においては、通常、
１つの中央処理ユニット（ＣＰＵ）を有し、この中央処
理ユニットに付属の全ての構成素子を結合するバスを介
して制御を行っている。その結果、１つの中央処理ユニ
ットで信号の供給とグラフィックス・サブシステムの制
御とを行っているので、実行可能なトランザクションが
非常に限られてしまう。従って、この構成は低解像度グ
ラフィックスのアプリケーションに対してのみ良好に働
く。グラフィックス・コントローラ・チップにおけるあ
る程度の加速を可能にするアドオン・カードがある。こ
の改良により帯域幅が節約され、また、グラフィックス
・サブシステムに対する幾つかの高レベルの指令の負担
が軽くなる。例えば、中央処理ユニットは、グラフィッ
クス・サブシステムに線を引けあるいは矩形を描けとい
う指令を送り、かつ座標点のみを送る。これによって、
ピクセル毎の情報を送る場合に較べて、処理を加速する
ことが可能となる。

【０００３】低解像度のグラフィックスでは、この方法
は充分うまく働く。しかし、高解像度のシステムでは、
中央処理ユニットの処理能力が不足する可能性がある。
従って、グラフィックスの解像度が大きくなるにつれ
て、グラフィックスの演算の幾つかのものを加速するた
めに、加速を付加することもあったが、そのようにして
も、最終的には、コンピュータシステムの代表的なバス
が持つ実際のバス帯域幅がそのようなグラフィックス像
の非常に高い更新速度を維持することが出来なくなるよ
うな点にまで達していた。しかも、このことは、ビデオ
が付加されるとさらに複雑になってくる。即ち、ビデオ
は１秒間に３０フレームで更新する必要があり、グラフ
ィックス・サブシステムへのバスにおいて、５〜９メガ
バイト／秒の持続帯域幅（ｓｕｓｔａｉｎｅｄｂａｎ
ｄｗｉｄｔｈ）を必要とすることがあるためである。

【０００４】総合型ビデオ／グラフィックスシステムを
得るためには、ビデオ・サブシステムとグラフィックス
・サブシステムが持つ互いに相容れない要求をバランス
させるシステム・アーキテクチャが必要となる。例え
ば、グラフィックス画像には水平及び垂直解像度を大き
くすることは有用であるが、デジタルビデオ・サブシス
テムにおいては、水平及び垂直解像度を増加させること
は非常に費用がかかり、しかも、画質は目に見えるほど
変化しない。同様に、グラフィックス・サブシステムに
おいては、ピクセル深度（ｐｉｘｅｌｄｅｐｔｈ）、
即ち、同時に利用出来る色の数は、ビデオシステムの場
合ほど重要ではない。グラフィックス・システムでは１
６ビットの真色に近い色のピクセルで充分であるが、ビ
デオシステムは２４ビットピクセルを用いることがあ
る。

【０００５】再生中のデジタルビデオ・サブシステムに
おけるビデオプロセッサの動作能力は分割されて、２つ
のタスクを実行するために用いられる。即ち、（１）圧
縮されたデータ・ストリームからのビデオ画像の作成、
及び（２）表示バッファへの画像のコピー／拡大・縮小
である。ビデオ・サブシステムの動作能力はコピー／拡
大・縮小動作とビデオ・デコンプレッション（圧縮状態
から元に戻す）動作の間でバランスがとられねばならな
い。この２つの動作は、滑らかで自然な動きのビデオを
得るためには、１秒間に３０回実行されねばならない。
動作能力の分割を行うと通常は事態は悪くなり、充分な
動作能力を全スクリーン動きを持つビデオのコピー／拡
大・縮小動作に割り当て、残りの動作能力をビデオ・デ
コンプレッション動作に振り分けることになる。コピー
／拡大・縮小動作中に書き込まれるべきピクセル及び／
またはバイトの数が増加すると、必然的にビデオ・デコ
ンプレッションの性能が低下する。ある所定のビデオ技
術レベルに対して、解像度を増加させようとすると、デ
コンプレッション処理された画像の情報量が少な過ぎる
ためにビデオ画像の画質が低下し始める点に達する。

【０００６】上述したように、グラフィックス・システ
ムに対する要件には、浅いピクセル（ｓｈａｌｌｏｗ
ｐｉｘｅｌ）で高い水平及び垂直解像度を得るというこ
とが含まれる。表示が１Ｋバイト×１Ｋバイトで８ビッ
トがＣＬＵＴ（ＣｏｌｏｒＬｏｏｋＵｐＴａｂｌｅ
＝カラー・ルックアップテーブル）ピクセルであるよう
なグラフィックス・サブシステムは、条件の厳しい構成
のほとんど全てのものの要求を満たす。これに対し、ビ
デオシステムの要件には、２４ビットで表される真色
（ｔｒｕｅｃｏｌｏｒ）のピクセルを最少のバイトで
表示バッファ中で発生する能力が含まれる。（なお、２
４ビット以上を用いて色を表しても、人間の目に知覚さ
れる色にはあまり差がない。）代表的な妥当なグラフィ
ックス・サブシステムは、例えば、ＹＵＶフォーマット
で３５２×２４０×２４ビットを備える。これは全スク
リーン用には拡大（スケール・アップ）することができ
るが、多くの場合、全スクリーン表示は必要とされな
い。

【０００７】グラフィックス・サブシステム表示バッフ
ァをビデオ・サブシステム表示バッファと一体化するシ
ステムは、一般に、２つのカテゴリーに分類される。こ
れらの２つのアプローチは、単一フレームバッファ・ア
ーキテクチャとデュアルフレームバッファ・アーキテク
チャとして知られている。

【０００８】単一フレームバッファ・アーキテクチャは
最も直接的なアプローチであって、１つのグラフィック
ス・コントローラ、１つのデジタル−アナログ変換器、
及び１つのフレームバッファからなる。最も簡単な形で
は、単一フレームバッファ・アーキテクチャは、表示器
上の各ピクセルが、その表示器上のピクセルの意味には
関係なく、そのフォーマットが一致する、表示バッファ
中のビットによって表される。このアーキテクチャで
は、グラフィックスピクセルとビデオピクセルはフレー
ムバッファメモリ中では見分けがつかない。しかし、単
一フレームバッファ・アーキテクチャのグラフィックス
／ビデオ・サブシステム、即ち、単一フレームバッファ
・アーキテクチャのビジュアルシステムは、ビデオ・サ
ブシステムの要求には充分には応えられない。単一フレ
ームバッファ・アーキテクチャ・ビジュアルシステム上
の全スクリーン運動（動き）ビデオに対しては、表示バ
ッファ中の各ピクセルを１秒間に３０回更新せねばなら
ない。このフレームバッファは、およそ１２８０×１０
２４×８ビットとなる可能性が大きい。表示バッファに
対し、３０メガバイト以上を書込むという負担がなかっ
たとしても、８ビットビデオそれ自体は、所要のビデオ
画質を与えることができない。そこで、単一フレームバ
ッファ・アーキテクチャシステムを、ピクセルの色を表
すために１６ビット／ピクセルを用いるようにするか、
あるいは、通常の８ビットＹＵＶサブサンプル技法を実
施するということも考えられる。

【０００９】ビジュアルシステムは、表示器上にビデオ
とグラフィックスをミックスして表示することができな
ければならず、そのためには、時には、グラフィックス
ピクセル相互間に１つのビデオピクセルを位置させて表
示する必要がある。ビデオとグラフィックスをミックス
する必要があるために、表示バッファ中の全てのピクセ
ルは、スクリーン上で単独で存在し、自立したピクセル
でなければならない。

【００１０】この発明の目的はグラフィックス情報とビ
デオ情報を記憶し表示するための総合システムを提供す
ることである。さらに、この発明の別の目的はグラフィ
ックス情報あるいはビデオ情報の一方を記憶表示するシ
ステムであって、グラフィックス情報とビデオ情報を記
憶表示する総合システムに拡大可能に改良できるシステ
ムを提供することである。この発明の他の目的及び効果
は以下の説明により、明らかとなろう。

【００１１】

【発明の概要】この発明のスケーリング可能なプラット
フォームアーキテクチャは、種々のビデオ処理サブシス
テム間で高ビット速度でデータの転送を行うための高帯
域幅のバスを含んでいる。グラフィックスメモリを有す
るグラフィックス処理サブシステムがこの高帯域幅バス
に結合されている。グラフィックス処理サブシステムは
ビデオメモリを受け入れ、このビデオメモリが受け入れ
られた時に、ビデオ処理を行うようにされている。高帯
域幅バスには、種々のサブシステムに切り離し可能に結
合するための拡張コネクタが設けられている。これらの
種々のサブシステムには、例えば、ビデオ処理サブシス
テム及びビデオ捕捉（ｃａｐｔｕｒｅ）システムが含ま
れる。さらに、この高帯域幅バスには、この高帯域幅バ
スを低帯域幅バスまたは中央処理ユニットバスに結合す
るためのバスブリッジが設けられている。

【００１２】

【実施例】図１は、マルチメディア・スケーリング可能
（スケーラブル）・プラットフォーム・アーキテクチャ
１０ａのブロック図である。このマルチメディア・スケ
ーラブル・プラットフォーム・アーキテクチャ１０ａ内
には、高性能バス３２がビデオ捕捉サブシステム１２、
ビデオ・アクセラレータ・サブシステム１５及びグラフ
ィックス・サブシステム３１に結合されており、これら
の間でデータを非常に高い速度で転送することを可能と
している。高性能バス３２は、バスブリッジ３４によっ
て、中央処理ユニットバス４２と低帯域幅バス３６のよ
り低い帯域幅のトラフィックから切り離されている。こ
のようにすることによって、バス３６及び４２に結合さ
れたより低速の装置に関係なく、非常に高いビデオ及び
グラフィックス処理速度が可能となり、サブシステム１
２、１５による画像の操作及び伝送が行える。

【００１３】マルチメディア・プラットフォーム・アー
キテクチャ１０ａは、その処理能力が拡張コネクタ５
６、５８を用いることにより、また、グラフィックス・
アクセラレータ・サブシステム３１内のメモリ２６を付
加したり除去したりすることによってスケーリング可能
とされている。拡張コネクタ５６は、捕捉サブシステム
１２が高性能バス３２に切り離し可能に結合できるよう
にするために、アーキテクチャ１０ａに設けられてい
る。拡張コネクタ５８は、ビデオ・アクセラレータ・サ
ブシステム１５が高性能バス３２に切り離し可能に結合
できるようにするために、アーキテクチャに設けられて
いる。このようにすることによって、プラットフォーム
・アーキテクチャ１０ａはスケーラブル処理性能を持つ
ことができる。

【００１４】マルチメディア・スケーラブル・プラット
フォーム・アーキテクチャ１０ａの高性能バス３２は物
理的な相互接続で、グラフィックスプロセッサ及びビデ
オプロセッサ、例えば、ビデオ・サブシステム１５及び
グラフィックス・サブシステム３１のプロセッサ、並び
にその他の高度に集積されたたサブシステムを、最少の
インタフェース・ロジックを用いて共通のインタフェー
スに接続することを可能にするものである。推奨実施例
においては、高性能バス３２は、好ましくは、３２ビッ
トのトランザクション向きバスで、約１００メガバイト
／秒のピークデータ転送速度を持っている。

【００１５】スケーラブル・プラットフォーム・アーキ
テクチャ１０ａのビデオ捕捉サブシステム１２は、アナ
ログ入力ライン１１を介して複合ベースバンド入力を受
入れ、この技術分野の者には公知の態様で画像をデジタ
ル化する。ビデオ捕捉サブシステム１２の捕捉された画
像出力は、別々の、全解像度Ｙビットマップと可変解像
度（２：１、４：１）ＵＶサブサンプル・ビットマップ
の形で、高性能バス３２に供給することができる。

【００１６】スケーラブル・プラットフォーム・アーキ
テクチャ１０ａのビデオ・アクセラレータ・サブシステ
ム１５は、拡張コネクタ５８によって高性能バス３２に
切り離し可能に、直接結合されている。ビデオサブシス
テム１５は、ビデオプロセッサ１６と局部ビデオメモリ
１４を含んでいる。スケーラブル・プラットフォーム・
アーキテクチャ１０ａ内のビデオ処理及びオーディオ処
理は、ビデオ・アクセラレータ１５で実行することがで
きる。ビデオ・アクセラレータ・サブシステム１５内で
は、ビデオメモリ１４に対する条件は、単に拡張可能で
あるということよりも、むしろ、「浅く（ｓｈａｌｌｏ
ｗ）」かつ「幅が広い（ｗｉｄｅ）」であることであ
る。

【００１７】スケーラブル・アーキテクチャ１０ａの基
本構成は、例えば、ビデオ・サブシステム１５中に１つ
のメモリの３２ビットバンクを含んでいる。高性能の基
本構成では、高帯域幅インタフェース用に６４ビットの
バンクを含むようなものを用いることができる。通常
は、高性能バス３２の幅の選定はメモリの帯域幅に対す
る要求により制限を受け、一方、サブシステム１５内の
バンクのサイズ及び／またはバンクの数は全メモリに対
する要求によって決まる。これら２つの選定は相互に関
係している。なぜなら、６４ビットインタフェースを用
いると、他の全てのパラメータを等しいとしても、メモ
リの総量も２倍になるからである。

【００１８】拡大可能なマルチメディア・プラットフォ
ーム・アーキテクチャ１０ａのグラフィックス・アクセ
ラレータ・サブシステム３１は、グラフィックスプロセ
ッサ３０の他に、ビデオ及びグラフィックス記憶用にラ
ンダムアクセスメモリ（ＲＡＭ）２６と２８を備えてい
る。グラフィックスサブシステム３１のメモリ２６と２
８は仮想メモリでもよい。グラフィックス出力路２２
は、ビデオ及びグラフィックス伝送のためにグラフィッ
クス・サブシステム３１内に設けられている。グラフィ
ックス・サブシステム３１のデジタル−アナログ変換器
２４はビデオメモリ２６とグラフィックスメモリ２８か
らのビットストリームを合流させるようにされている。

【００１９】中央処理ユニット３８は、スケーラブル・
アーキテクチャ１０ａの拡張コネクタ５６と５８によっ
てどのサブシステムが高性能バス３２に結合されている
かには関係なく、中央処理ユニットバス４２に結合され
ている。中央処理ユニットバス４２によって、中央処理
ユニット３８に対して、プログラムメモリ４０とベース
入／出力５０を設けることができる。さらに、スケーラ
ブル・アーキテクチャ１０ａにハードディスク５２やコ
ンパクトディスク記憶装置５４等の装置を結合するため
に低帯域幅バス３６を設けることもできる。この技術分
野の技術者には、別の実施例（図示せず）として、大容
量記憶装置５２、５４をバス３６の代わりにバス３２に
直接結合するようにできることは理解できよう。

【００２０】スケーラブル・プラットフォーム・アーキ
テクチャ１０ａのバスブリッジ３４は、高性能バス３
２、中央処理ユニットバス４２及び低帯域幅バス３６の
間の交信を可能にする。バスブリッジ３４は、また、バ
ス３２、３６及び４２を互いに分離する働きもする。従
って、ブリッジ３４は、スケーラブル・プラットフォー
ム・アーキテクチャ１０ａ内の中央処理ユニット３８、
高性能バス３２及び低帯域幅バス３６相互間の中央スイ
ッチ点となる。これによって、３つのバス３２、３６、
４２間を簡単なアービトレーション（ａｒｂｉｔｒａｔ
ｉｏｎ）と優先使用プロトコールを用いて最少待ち時間
で接続することができる。

【００２１】スケーラブル・アーキテクチャのグレード
アップ図２〜５には、高性能バス３２に直接結合される、この
発明のマルチメディア・スケーラブル・プラットフォー
ム・アーキテクチャ１０ｂ、１０ｃ、１０ｄ、及び１０
ｅの部分を示す。マルチメディア・スケーラブル・プラ
ットフォーム・アーキテクチャ１０ｂ，１０ｃ，１０
ｄ，及び１０ｅは、マルチメディア・スケーラブル・プ
ラットフォーム・アーキテクチャ１０ａの代替実施例で
あって、アーキテクチャ１０ａのシステム性能の一部
を、アーキテクチャ１０ｂ、１０ｃ、１０ｄ、１０ｅの
持つ簡単でかつ費用のかからない構成と交換するため
に、アーキテクチャ１０ａの一部が省略されている。ア
ーキテクチャ１０ｂ、１０ｃ、１０ｄ、１０ｅを用いる
ために除いたアーキテクチャ１０ａの部分は、システム
性能のグレードアップを容易に行えるように、簡単に結
合切り離しができる。

【００２２】図２のマルチメディア・スケーラブル・プ
ラットフォーム・アーキテクチャ１０ｂはグラフィック
スＲＡＭ２８及び単一のアクティブ・フレームバッファ
・デジタル−アナログ変換器２４と共にグラフィックス
プロセッサ３０を含んでいる。このアーキテクチャ１０
ｂは、単一のグラフィックス・メモリを有する基本的な
通常の単一グラフィックス・システムの機能を、公知の
態様で実行する。このような、基本グラフィックス・シ
ステムは、ビデオ及びグラフィックス用に単一のメモリ
のバンクを用いてビデオ信号のソフトウェア復号及び許
容しうる画質でビデオ再生を行うことができる。

【００２３】図３のスケーラブル・マルチメディア・プ
ラットフォーム・アーキテクチャ１０ｃは図２のスケー
ラブル・マルチメディア・プラットフォーム・アーキテ
クチャ１０ｂよりも高級なものである。スケーラブル・
プラットフォーム・アーキテクチャ１０ｃにおいては、
ビデオメモリ２６がグラフィックスメモリ２８と並列
に、ビデオプロセッサ３０と単一のアクティブ・フレー
ムバッファデジタル−アナログ変換器２４とに結合され
ている。この付加されたビデオメモリ２６は、例えば、
約１メガバイトの大きさを持つものを用いることができ
る。スケーラブル・プラットフォーム・アーキテクチャ
１０ｃ内のこの構成は、スケーラブル・プラットフォー
ム・アーキテクチャ１０ａのグラフィックス・アクセラ
レータ・サブシステム３１と同等である。

【００２４】ビデオメモリ２６をグラフィックス・アク
セラレータ・サブシステム３１に置く場合は、中央処理
ユニット３８がビデオ情報をソフトウェア的に復号し、
グラフィックスメモリ２８を用いずに、ビデオメモリ２
６に書き込む。例えば、スケーラブル・プラットフォー
ム・アーキテクチャ１０ｂにビデオメモリ２６を結合し
て、グラフィックス・アクセラレータ・サブシステム３
１を形成するようにすれば、８ビット／ピクセル構成で
はなく、２４ビット／ピクセル構成を形成することが可
能となる。しかし、これはビデオ画像のみに適用可能で
あることが理解されよう。この構成を用いると、プラッ
トフォーム・アーキテクチャ１０ｃを形成するためにプ
ラットフォーム・アーキテクチャ１０ｂに単に付加的な
メモリを付加することによってアーキテクチャ１０ｂで
得られるよりも高いビデオ画質が得られる。

【００２５】図４に示すスケーラブル・マルチメディア
・プラットフォーム・アーキテクチャ１０ｄは、図３の
アーキテクチャ１０ｃを高級化したものである。スケー
ラブル・マルチメディア・プラットフォーム・アーキテ
クチャ１０ｄにおいて、ビデオ捕捉サブシステム１２が
拡張コネクタ５６によって高性能バス３２に結合されて
いる。ビデオ捕捉サブシステム１２は、データを捕捉し
て、実時間再生や実時間会議に用いるために、アナログ
及びデジタル入力を捕捉しデジタル化するように構成さ
れている。ビデオ捕捉サブシステム１２における専用捕
捉機能により、スケーラブル・マルチメディア・プラッ
トフォーム・アーキテクチャ１０ａのビデオ・アクセラ
レータ・サブシステム１５がなくても、アナログ信号及
びビデオ信号の捕捉が可能となる。このように、プラッ
トフォーム・アーキテクチャ１０ｄを用いることによ
り、ビデオ信号を捕捉することができ、また、中央処理
ユニット３８によってデータをより低いフレーム周波数
と解像度で圧縮することが可能となる。このようにすれ
ば、画質を落としてハードウェアであるアクセラレータ
のコストを下げることができる。

【００２６】拡張コネクタ５８によってビデオ・アクセ
ラレータ・サブシステム１５をスケーラブル・マルチメ
ディア・プラットフォーム・アーキテクチャ１０ｄの高
性能バス３２に結合すると、アーキテクチャ１０ｄはグ
レードアップされて、スケーラブル・マルチメディア・
プラットフォーム・アーキテクチャ１０ａの全能力を持
つことになる。プラットフォーム・アーキテクチャ１０
ｄに対しビデオ・アクセラレータ・サブシステム１５を
付加することにより、ビデオ会議やビデオ再生が加速さ
れ、それによってより高画質の画像が得られる。

【００２７】当業者には理解されるが、スケーラブル・
マルチメディア・プラットフォーム・アーキテクチャ１
０ａ、１０ｂ、１０ｃ及び１０ｄの代替実施例である図
５に示すアーキテクチャ１０ｅにおいて、ビデオ・アク
セラレータ・サブシステム１５は、ビデオ捕捉サブシス
テム１２を高性能バス３２に結合せずに、拡張コネクタ
５８によってビデオ・アクセラレータ・サブシステム１
５をスケーラブル・マルチメディア・プラットフォーム
・アーキテクチャ１０ｃに結合することができる。

【００２８】ビデオ・アクセラレータ・サブシステム１
５がプラットフォーム・アーキテクチャ１０ａ内に設け
られている場合には、プラットフォーム・アーキテクチ
ャ１０ａのビデオ及びオーディオ復号はビデオプロセッ
サ１６によって行われる。この場合、ビデオ及びオーデ
ィオはビデオプロセッサ１６によってデコンプレッショ
ン処理される。ビデオはグラフィックス・サブシステム
３１のフレームバッファに書き込まれ、オーディオデー
タは外部のオーディオ・コーダ１８とオーディオ直列イ
ンタフェース２０に書き込まれる。

【００２９】中央処理ユニット３８による復号と同様
に、ビデオ及びオーディオデータのデータ源は低帯域幅
バス３６であってもよいし、あるいは高性能バス３２上
の総合サブシステムの１つであってもよい。ビデオスト
リームに要求されるデータ速度は、約１５０キロバイト
／秒である。圧縮されたビットストリームは、ビデオプ
ロセッサ１６を通して、サブシステム１５の局部メモリ
１４中の圧縮バッファに書き込まれる。

【００３０】一旦、圧縮されたデータが局部メモリ１４
に書き込まれると、デコンプレッション処理を開始させ
ることができる。画像の復号に用いられるデコンプレッ
ション・アルゴリズムによっては、局部メモリ１４には
２〜４個のフレームバッファが必要となろう。例えば、
ｐｘ６４デコードには、１つの基準フレームと１つの再
構成フレームが復号に必要とされる。ＭＰＥＧでは、２
つの基準フレームと、１つの再構成フレームと、１つの
進行中のフレームを局部メモリ１４に退避させねばなら
ない。

【００３１】ビデオプロセッサ１６はプログラム可能で
あるから、多くの種類のアルゴリズムをサポートするこ
とができる。そのアーキテクチャは、中央処理ユニット
３８による復号より遙かに優れた性能を提供するに充分
な汎用性を持っているべきである。さらに、ビデオプロ
セッサ１６は、ソフトウェア・デコンプレッション・ア
ルゴリズムの性能を改善できるように充分に特殊な加速
ハードウェアを備えているべきである。

【００３２】スケーラブル・アーキテクチャ内での処理ビデオ捕捉サブシステム１２は、アナログビデオ信号に
対してアナログ−デジタル変換を施し、その結果得られ
た信号の捕捉を可能とするビデオコデク（符号化／復号
器）（図示せず）を含んでいる。捕捉用特定用途向け集
積回路（ＡＳＩＣ）が、捕捉されたビデオ信号に一連の
処理を施す。この発明のマルチメディア・スケーラブル
・プラットフォーム・アーキテクチャ内では、３つのビ
デオ成分（Ｙ、Ｕ及びＶ）が別々のビットマップとして
処理される。また、この処理中、捕捉サブシステム１２
内では、タイミングブロックがライン・カウントを追跡
し、ワード・バッファのロードに対しピクセルをカウン
トし、偶数及び奇数フィールド時間を求め、ポインタ値
に対してピッチ値が何時加えられるかを検出する。

【００３３】代表的には、ＵまたはＶデータに対しＹデ
ータは４倍はあるので、Ｙデータのためにワードバッフ
ァを付加する方がＵ及びＶデータにワードバッファを付
加するより有効である。Ｕ及びＶ平面（ｐｌａｎｅ）を
交差指型（ｉｎｔｅｒｄｉｇｉｔａｔｅｄ）ＵＶ平面と
して記憶するようにすることによって、回路構成を節約
できる。このようにすると、ワードバッファとそれに付
随するポインタレジスタとピッチレジスタを節約でき
る。しかし、全体の回路構成に較べると、ゲートの節約
は小さなもので、これを行うためには、ビデオプロセッ
サ１６がＵＶビット平面を、別のソフトウェアステップ
として、または、カラー平面処理の一部として、各々の
成分に分離する必要がある。バイトの順序づけ（ｓｅｑ
ｕｅｎｃｉｎｇ）は一般的な動作であり、ポインタの演
算を結合して１つの演算ユニットにすることができる。
従って、ゲートの節約は、実際のレジスタ記憶装置のみ
に帰する。

【００３４】スケーラブル・プラットフォーム・アーキ
テクチャ１０ａ、１０ｂ、１０ｃ、１０ｄ、１０ｅの高
性能バス３２は、前述したように、バスブリッジ３４ま
たはバスインタフェース３４を介して中央処理ユニット
３８と低帯域幅バス３６に結合される。標準のバスプロ
トコールをサポートするために、ＤＭＡは、１／６０秒
の間に（３５２×２４０）＋（２×１８０×１２０）バ
イト、即ち、１２９，６００バイトを転送し、次の１／
６０秒にさらに多くのバイトを転送しなければならな
い。従って、平均ＤＭＡ速度は３．８８８メガバイト／
秒であるが、高性能バス３２は、有効フレーム期間中
に、７．７７６メガバイト／秒を保持するこ１ができな
ければならない。

【００３５】スケーラブル・マルチメディア・プラット
フォーム・アーキテクチャ１０ａ内での時間的サブサン
プリングにより、例えば、車の見掛け上の動きに対して
車輪が逆方向に回転して見えるというようなアーティフ
ァクトが生じる。この種の問題を解決するための時間的
濾波は、フレーム全体を記憶する必要があり、かつ、感
知しうる画質の向上が僅かでしかないにもかかわらず多
量の計算電力を消費するので、コストが高い。時間サブ
サンプリングは、ポインタ及びピッチレジスタ・ブロッ
クの構成を簡単にする。なぜなら、これによれば、各フ
ィールド用として、対応する全く同じレジスタを設ける
必要がないためである。この場合、タイミングブロック
が、廃棄されるフィールド期間中は全ＤＭＡを遮断す
る。

【００３６】水平Ｙサブサンプリングにより、処理され
たビデオ中にアーティファクトが生じるが、これはアー
キテクチャ１０ａ内で２つのファクタによって制御でき
る。先ず、Ｙデータをオーバサンプリングして、幾らか
の時間をサブサンプリングのために残すことができる。
第２に、直接ビデオデータを生成し、高周波数成分を保
存するビデオ源においては、Ｙデータを有限インパルス
応答カーネル（ｋｅｒｎｅｌ）を通すことが好ましい。
これを行うための許容できるフィルタとしては、例え
ば、係数の中の２つがゼロである７タップフィルタを用
いることができる。残りの５つの係数は、例えば、１係
数につき最大３つの加算器を連続して接続したものによ
って実現できる。最後の除数は、例えば、２５６ビット
に選ぶことができる。これは、単純な右方向シフト構成
である。

【００３７】ＵＶデータを水平方向にサブサンプルする
ことが可能である。ＵＶピクセルをＹピクセルに正確に
一致させるために、可調整Ｙ位相遅延を用いることもで
きる。さらに、ＵＶデータは垂直方向にもサブサンプル
される。このサブサンプリングはビデオプロセッサ１６
内で行わせてもよいし、ビデオ捕捉サブシステム１２内
で行わせてもよい。最も簡単なサブサンプリングの方法
は、データの一部のみを用い、用いなかったデータを廃
棄するという方法である。この方法を、簡易サブサンプ
リングと呼ぶ。しかし、この方法はかなりの周波数折り
重ね（フォールドオーバ）アーティファクトを生じさせ
る。このようなアーティファクトが生じる原因は、幾つ
かのフレームでは、カラーサンプルがある領域から取ら
れ、その色が流れたり、別の色になってしまうことがあ
り、別のフレームでは、カラーサンプルが他の色と一緒
になって、高度に飽和した色を生じさせてしまうことが
あるためである。

【００３８】ハードウェア中で良好な垂直カラーマップ
サブサンプリングを行うためには、基本的な捕捉ＡＳＩ
Ｃに２つの付加を行う必要がある。ＵＶマルチラインバ
ッファを内部に、あるいは外部に、ランダムアクセスメ
モリ中に付加する必要がある。さらに、二次元データを
低域通過濾波してサンプルストリーム中に入れるための
演算カーネル（核）が安全にサブサンプルされる。

【００３９】そこで、この問題に対する解決法に３つの
方法が考えられる。即ち、簡易サブサンプリングと、ハ
ードウェア中での濾波、及びソフトウェア中での濾波で
ある。ビデオ・アクセラレータ・サブシステム１５内の
ソフトウェア中での濾波を行うことなしにサブサンプリ
ングを行うことは非能率的であると考えられる。

【００４０】基本サンプリングクロック周波数は２７Ｍ
Ｈｚに固定されている。Ｙデータ周波数は１３．５メガ
バイト／秒で、また、１つおきのＹサンプルのみが有限
インパルス応答フィルタの他方の側に生成されるだけな
ので、サンプルを計算するためには４クロックサイクル
ある。好ましいフィルタの実施例では、計１５回の加算
に対して、非ゼロ係数は５個しかなく、その各々は多く
ても３個のビットがオンである。演算を行うために４ク
ロック周期があるので、回路設計は、例えば、８個のピ
クセルレジスタと、３個の加算器と、１６ビット帰還レ
ジスタとを用いて行うことができる。

【００４１】ＵＶデータの垂直濾波には、外部にマルチ
ライン記憶装置を必要とする。この濾波法では、Ｕデー
タまたはＶデータのどちらかの４ビットが２クロックサ
イクル毎に供給される。推奨フィルタ係数を用いると、
Ｕ及びＶの両方について、計１２回の加算に対して、８
クロック毎に６回の加算しか行われない。従って、この
方法では、各カラーバイトに対して、４つのピクセルレ
ジスタ、１つの加算器、１１ビット帰還レジスタしか必
要でない。さらに、外部ラインバッファからは２回のバ
イト書込みと６回のバイト読出しが必要である。これ
は、外部に設けた４ビットラッチと１キロバイト×８ビ
ットの高速スタティックＲＡＭによって実施することが
できる。

【００４２】捕捉ＡＳＩＣは、例えば、９２信号入力／
出力ラインと約５７００〜６２００の等価ゲートで実施
できる。このゲートの数には、全偶数及び奇数の二重に
バッファされたポインタと、Ｙ、Ｕ、Ｖデータの各々に
対し８個のバイトワードのバッファが含まれる。Ｙ有限
インパルス応答フィルタの推計サイズは、例えば、４０
０ゲートである。このシステムのＵ及びＶフィルタの各
々は２００より幾らか少ない数のゲートを必要とし、ま
た、スタティックメモリ・コントローラは、タイミング
ブロックとの集積の程度に応じて３００乃至４００のセ
ルを必要とするであろう。ＵＶラインバッファ用に内部
記憶装置を付加すると、ＡＳＩＣがメモリに対する要件
に関し最適な構造を持ったものでない限り、１０×１０
００乃至１１×１０００のゲートを付加することにな
り、複雑になる。

【００４３】グラフィックス・サブシステム通常のパーソナルコンピュータのアーキテクチャは、中
央処理ユニットバス４２のような単一のシステムバスを
用いている。このような構成では、性能が制限されてし
まう。なぜなら、バス４２上で最も動作の遅い装置がそ
のようなアーキテクチャの最高トランザクション速度を
決めるからである。さらに、一つの中央処理ユニット３
８によってシステムの全てのプラットフォーム資源を制
御する場合には、低帯域幅トランザクションが、システ
ム全体の性能に重大な影響を与える。解像度に対する条
件が増せば増すほど、また、各サイクル中に実行される
グラフィックス演算が増せば増すほど、通常は中央処理
ユニットバス４２上の遠隔フレームバッファに対する入
／出力アクセスが通路を狭くしてしまう。

【００４４】この問題を軽減するために、前述したよう
に、スケーラブル・プラットフォームをグレードアップ
するためにグラフィックス・アクセラレータ・サブシス
テム３１を設けることができる。フレームバッファを中
央処理ユニット３８に近づけるればグラフィックス性能
は上がるが、ビデオ処理も行うことになると、入／出力
の問題が再び急速に浮上してくる。ビデオ処理に必要な
性能レベルを保持し、かつ、フレームバッファへの所要
の帯域幅を維持するために、グラフィックス・サブシス
テム３１は、分離して別の高性能バス３２に接続され
る。

【００４５】推奨実施例によるプラットフォーム・アー
キテクチャ１０ａでは、グラフィックス・アクセラレー
タ・サブシステム３１を用いることにより、既存の８ビ
ット乃至１６ビットのグラフィックス・フレームバッフ
ァを用いていても２４ビットビデオ解像度を実現するこ
とができる。これにより、低いクロック周波数で高い帯
域幅をデジタル−アナログ変換器に供給することがで
き、同時に、ビデオピクセルとグラフィックスピクセル
の合成（マージ）が容易になる。これらの２つの特徴は
グラフィックス・サブシステム３１の全体の設計を大い
に簡素化する。

【００４６】ビデオの源は低帯域幅バス３６であって
も、あるいは高性能バス３２上のサブシステムであって
もよい。ビデオストリームに必要なデータ速度は約１５
０キロバイト／秒である。ビデオの源がバス３６であ
れ、バス３２上のサブシステムであれ、帯域幅条件は同
様であり、また、ブリッジ３４を介するシステムメモリ
への待ち時間も同様である。中央処理ユニット３８はデ
コード動作を行うので、低帯域幅トランザクションによ
って、フレームバッファへの書込みが妨害されて、シス
テム性能が低下することはない。

【００４７】圧縮データがシステムメモリに入ると、中
央処理ユニット３８はデコンプレッション処理を開始す
る。使用するアルゴリズム、画質、及び要求されるフレ
ーム周波数に応じて、中央処理ユニット３８が使用でき
る処理電力の８０〜１００％が必要となる。

【００４８】単一アクティブフレームバッファ次に図６を参照すると、全体を１００で示す装置の動作
を説明するブロック図画示されている。装置１００は、
この発明のスケーラブル・マルチメディア・プラットフ
ォーム・アーキテクチャ内でビデオデータを処理するた
めに用いることができる。装置１００は第１のフォーマ
ットのビジュアルデータの第１のビット平面を記憶する
ための第１の記憶手段１１０を含んでいる。この第１の
記憶手段１１０は記憶バス１３２を通してグラフィック
ス・コントローラ１４０に結合されている。装置１００
の推奨実施例では、グラフィックス・コントローラ１４
０はスケーラブル・プラットフォーム・アーキテクチャ
１０ａ、１０ｂ、１０ｃ、１０ｄのグラフィックス・プ
ロセッサ３０と実質的に同じものとすることができる。
第１の記憶手段１１０とグラフィックス・コントローラ
１４０はまたデータバス１３０にも結合されている。装
置１００はさらに、第１のフォーマットとは異なる第２
のフォーマットでビジュアルデータの第２のビット平面
を記憶するための第２の記憶手段を受け入れるための手
段１２０を持っている。

【００４９】手段１２０は記憶バス１３２を通して第２
の記憶手段をグラフィックス・コントローラ１４０に結
合するようにされている。従って、この発明のスケーラ
ブル・アーキテクチャ１０ｂからのスケーラブル・アー
キテクチャ１０ｃへのグレードアップはこのようにして
行うことができる。手段１２０はさらにデータバス１３
０ａを通して第２の記憶手段をグラフィックス・コント
ローラ１４０に結合するようにされている。グラフィッ
クス・コントローラ１４０は第１と第２の記憶手段に記
憶されているビジュアルデータから合成されたピクセル
ストリームを形成するための手段を持っている。また、
この合成されたピクセルストリームを表示するための手
段１６０も設けられている。手段１６０はピクセルバス
１５０を通してグラフィックス・コントローラ１４０に
結合されている。装置１００の好ましい実施例では、デ
ータバス１３０とデータバス１３０ａは別々の８ビット
バスである。別の実施例では、第１の記憶手段１１０と
第２の記憶手段の両方をグラフィックス・コントローラ
１４０に接続するために、１つの１６ビットデータバス
を使うことができる。また、別の幅を持ったデータバス
も用いることは可能である。

【００５０】装置１００において、第１の記憶手段１１
０はＲＡＭＢＡＮＫ０として表されている。このベー
ス構成は、例えば、８ビットＣＬＵＴモードで動作す
る。このモードは、ＲＡＭＢＡＮＫ０が８ビット／
ピクセルモードで単一のフレームバッファ・アーキテク
チャとして動作することを許容する。８ビットＣＬＵＴ
モードはこのベース構成を、ビデオ専用サブシステムま
たはグラフィックス専用サブシステムとして動作するこ
とができるようにする。このベース構成は、また、グラ
フィックス／ビデオ・インテグレーションが制限された
単一フレームバッファ・アーキテクチャ・システム、例
えば、８ビット／ピクセルのシステムとして動作するこ
とができる。８ビットＣＬＵＴモードでは、データバス
１３０の帯域幅は独立型８ビットＣＬＵＴグラフィック
ス・サブシステムに要求されるものと同じである。

【００５１】第２の記憶手段を受け入れる手段１２０を
用いることにより、第２の記憶手段を付加するだけで、
この発明のベース構成を、（１）デュアル・カラー・ス
ペース・モード、即ち、グラフィックス情報とビデオ情
報の双方を記憶し表示する統合されたシステムとして、
または（２）拡張単一フレームバッファモード、即ち、
グラフィックスのみ、あるいは、ビデオのみを、より大
きなピクセル深度及び／またはより高い解像度レベルで
記憶し表示する拡張単一フレームバッファとして動作す
るように、改変することができる。（なお、カラー・ス
ペースとは、１ピクセル当たり予め定められた数のビッ
トを用いた表示ピクセルの色を表すものを意味する。
「デュアル・カラー・スペース・モード」は、２つのカ
ラー・スペースが、表示のためにビデオプロセッサによ
って交互に選択されるモードであり、このモードでは、
例えば、ビデオプロセッサはグラフィックス・ピクセル
とビデオ・ピクセルを選択的に同じ表示装置に供給す
る。）

【００５２】デュアル・カラー・スペース・モードで
は、例えば、第１のタイプのビジュアルデータが第１の
フォーマットで第１の記憶手段１１０に記憶され、第２
のタイプのビジュアルデータが、第１のフォーマットと
は異なる第２のフォーマットで第２の記憶手段に記憶さ
れる。例えば、グラフィックスデータはＲＧＢフォーマ
ットで第１の記憶手段１１０に記憶され、ビデオデータ
はＹＵＶフォーマットで第２の記憶手段に記憶されるよ
うにできる。拡張単一フレームバッファモードでは、第
１の記憶手段１１０と第２の記憶手段は、好ましくは、
このシステムを１６ビット／ピクセルの、ビデオのみに
対するシステムまたはグラフィックスのみに対するサブ
システムとして動作させる。この拡張単一フレームバッ
ファモードは、グラフィックス／ビデオの統合が制限さ
れた、例えば、１６ビット／ピクセルの単一フレームバ
ッファ・アーキテクチャとして動作させることができ
る。

【００５３】グラフィックス・コントローラ１４０は、
記憶手段１１０に記憶されている第１のフォーマットの
データと、例えば、第２の記憶手段が手段１２０に受け
入れられた時、この第２の記憶手段に第２のフォーマッ
トで記憶されているデータとから合成ピクセルストリー
ムを形成するための手段を備えている。推奨実施例によ
れば、ベースシステムがグレードアップされると、例え
ば、第２の記憶手段が手段１２０に受け入れられて、デ
ュアル・カラー・スペース・モードで動作すると、グラ
フィックスデータは８ビットＣＬＵＴフォーマットで記
憶手段の一方に記憶され、ビデオデータは８ビットＹＵ
Ｖデータとして他方の記憶手段に記憶される。各位置が
単一バイトとしたデュアル・カラー・スペース・モード
における８ビットＹＵＶデータの推奨フォーマットは、
Ｙ_a, Ｕ_a, Ｙ_b, Ｖ_a, Ｙ_c,Ｕ_b, Ｙ_d, Ｖ_b, Ｙ
_e, Ｕ_c, ... として表すことができる。

【００５４】デュアル・カラー・スペース・モードで
は、ＲＧＢグラフィックスピクセル（ＧＰ_n）を表す第
１のピクセルストリームは、ＹＵＶビデオピクセルを表
す第２のピクセルストリームと並列に処理される。２つ
の並列ピクセルストリームは次のフォーマットに従って
並列に記憶される。

【表１】ＧＰ₁ＧＰ₂ＧＰ₃ＧＰ₄ＧＰ₅ＧＰ₆ＧＰ₇ＧＰ₈Ｇ
Ｐ₉．．．．Ｙ_a Ｕ_a Ｙ_b Ｖ_a Ｙ_c Ｕ_b Ｙ_d Ｖ_b Ｙ
_e．．．．

【００５５】デュアル・カラー・スペース・モードにお
いて、ビデオ・サブシステムによって生成されるピクセ
ル（ＶＰ_n）は好ましくは、２４ビットＹＵＶピクセル
から取り出された２４ビットＲＧＢ値である。この２４
ビットＹＵＶピクセルは次の式に従って、各ビデオピク
セルＶＰ_nについて求められる。ＶＰ₁に対しては、Ｙ＝Ｙ_a，Ｕ＝Ｕ_a及びＶ＝Ｖ_a ＶＰ₂に対しては、Ｙ＝０．５Ｙ_a＋０．５Ｙ_b，Ｕ＝
０．７５Ｕ_a＋０．２５Ｕ_b，Ｖ＝０．７５Ｖ_a＋０．
２５Ｖ_b ＶＰ₃に対しては、Ｙ＝Ｙ_b，Ｕ＝０．５Ｕ_a＋０．５
Ｕ_b，Ｖ＝０．５Ｖ_a＋０．５Ｖ_b ＶＰ₄に対しては、Ｙ＝０．５Ｙ_b＋０．５Ｙ_c，Ｕ＝
０．２５Ｕ_a＋０．７５Ｕ_b，Ｖ＝０．２５Ｖ_a＋０．
７５Ｖ_b ＶＰ₅に対しては、Ｙ＝Ｙ_c，Ｕ＝Ｕ_b，Ｖ＝Ｖ_b ・・・

【００５６】ＲＧＢ値を形成するために、他の変換技法
を用いてもよい。

【００５７】この発明の推奨実施例では、グラフィック
スピクセルストリームに対してクロマキー処理を用い
て、グラフィックスピクセルを見せるか、ビデオピクセ
ルを見せるかを決めることができる。ＧＰ₃とＧＰ₄が
クロマキー値に等しいピクセル値を持っていれば、デジ
タル−アナログ変換器に供給される合成グラフィックス
・ビデオピクセルストリーム、即ちビジュアルピクセル
ストリームは次のようなフォーマットを持つ。ＧＰ₁ＧＰ₂ＶＰ₃ＶＰ₄ＧＰ₅ＧＰ₆ＧＰ₇ＧＰ₈Ｇ
Ｐ₉．．．．

【００５８】次に、図７を参照すると、この発明の第２
の推奨実施例に従ってビジュアルデータを処理するため
の装置２００の動作を示すブロック図が示されている。
図７の構成は、ビジュアルデータの第１のビット平面を
第１のフォーマットで記憶するための第１の記憶手段２
１０を含んでいる。第１の記憶手段２１０は記憶バス２
３２を介してグラフィックス・コントローラ２４０に結
合されている。このグラフィックス・コントローラ２４
０は、図６に示した装置１００のグラフィックス・コン
トローラ１４０及びビデオ・アクセラレータ・サブシス
テム３１のビデオプロセッサ３０と実質的に同じであ
る。第１の記憶手段２１０とグラフィックス・コントロ
ーラ２４０はまたデータバス２３０によっても結合され
ている。この発明の装置はさらに、ビジュアルデータの
第２のビット平面を、第１のフォーマットとは異なる第
２のフォーマットで記憶するための第２の記憶手段２２
０も含んでいる。第２の記憶手段２２０は記憶バス２３
２を介してグラフィックス・コントローラ２４０に結合
されている。第２の記憶手段２２０とグラフィックス・
コントローラ２４０はさらにデータバス２３０ａによっ
ても結合されている。

【００５９】グラフィックス・コントローラ２４０は、
第１と第２の記憶手段に記憶されているビジュアルデー
タから合成ピクセルストリームを形成するための手段を
備えている。さらに、合成ピクセルストリームを表示す
るための手段２６０が設けられている。この手段２６０
はピクセルバス２５０によってグラフィックス・コント
ローラ２４０に結合されている。推奨実施例では、デー
タバス２３０と２３０ａは別々の３２ビットバスである
が、別の実施例として、１つの６４ビットデータバスを
用いて、第１の記憶手段２１０と第２の記憶手段２２０
の双方をグラフィックス・コントローラ２４０に結合す
るようにすることができる。また、別の幅のデータバス
を用いてもよい。装置２００は、手段１２０に第２の記
憶手段が受け入れられた時の装置１００と実質的に同じ
動作をする。従って、装置２００は、前述のデュアル・
カラー・ペース・モード及び拡張単一フレームバッファ
モードの一方で動作するように構成されている。

【図面の簡単な説明】

【図１】この発明のスケーラブル・アーキテクチャの第
１の実施例のブロック図である。

【図２】この発明のスケーラブル・アーキテクチャの第
２の実施例のブロック図である。

【図３】この発明のスケーラブル・アーキテクチャの第
３の実施例のブロック図である。

【図４】この発明のスケーラブル・アーキテクチャの第
４の実施例のブロック図である。

【図５】この発明のスケーラブル・アーキテクチャの第
５の実施例のブロック図である。

【図６】図１のアーキテクチャで使用するに適した型の
単一フレームバッファの実施例を示す図である。

【図７】図１のアーキテクチャで使用するに適した型の
単一フレームバッファの別の実施例を示す図である。

【符号の説明】

１２サブシステム１６サブシステム２６第２のビデオメモリ２７第２のビデオメモリを切り離し可能に受け入れる
手段２８第１のグラフィックスメモリ３０グラフィックス処理手段３２高帯域幅バス手段５６接続手段５８接続手段

Claims

【特許請求の範囲】

【請求項１】高ビット周波数でデータを伝送するため
の実質的に高帯域幅のバス手段と、この高帯域幅バス手
段に結合されており、グラフィックス処理を行うための
第１のグラフィックスメモリを有するグラフィックス処
理手段とを備え、上記グラフィックス処理手段は、（１）第２のビデオメ
モリを切り離し可能に受入れ、かつこの第２のビデオメ
モリに電気的に結合された手段と、（２）上記第２のビ
デオメモリに結合された時、ビデオ処理を行う手段とを
有し、上記高帯域幅バス手段は、複数のサブシステムの中の選
択されたサブシステムを切り離し可能に受入れ、かつ、
上記高帯域幅バス手段を上記選択されたサブシステムに
電気的に結合するための複数の接続手段を備えている、ビデオ処理システム。
【請求項２】上記複数の接続手段の第１のものがビデ
オ捕捉サブシステムを受け入れるようにされている、請
求項１に記載のビデオ処理システム。
【請求項３】上記複数の接続手段の第２のものがビデ
オ・アクセラレータ・サブシステムを受け入れるように
されている、請求項２に記載のビデオ処理システム。
【請求項４】上記第１と第２の接続手段の中の一方が
上記選択されたサブシステムを受け入れる、請求項３に
記載のビデオ処理システム。
【請求項５】上記第１と第２の接続手段の各々が、そ
れぞれのサブシステムを受け入れるようにされている、
請求項４に記載のビデオ処理システム。
【請求項６】さらに、実質的に低帯域幅のバス手段
と、上記高帯域幅バス及び上記低帯域幅バス手段とに結
合されており、上記バス手段を選択的に分離し結合する
ためのバス・ブリッジ手段とを備えてなる、請求項１に
記載のビデオ処理システム。
【請求項７】ソフトウェアデコーディングを実行する
ようにされた中央処理ユニットを含んでいる、請求項１
に記載のビデオ処理システム。