JP4073457B2 - ビデオ圧縮システム - Google Patents

Description

本発明は、コンピュータデータ処理に関し、特にコンピュータ・ビデオ圧縮に関する。

現存する複数のビデオ圧縮システムは１つの通信チャネルを介して送るためにより狭い帯域幅を取るようにビデオ・データの１つのストリームを圧縮する事が出来る。この様な複数のシステムは、圧縮しようとするビデオで発生すると予想される複数の冗長性を利用する。例えば、ＪＰＥＧとＭＰＥＧとは複数の写真イメージにおける隣り合う複数のピクセルの複数の色の頻繁に現れる複数の類似を利用する。更に、ＭＰＥＧは、ビデオの多数のフレームの間同じ色のままであったり或いはカメラが動くときにスクリーン上でその位置を移すだけであるようなピクセルが複数の映画には多数あるという事実を利用する。
なお、本出願に対応する外国の特許出願においては下記の文献が発見または提出されている。
米国特許出願公開第２００４／００６２３０５号明細書 米国特許出願公開第２００５／００６９０３４号明細書 米国特許第３９３５３７９号明細書 米国特許第４００５４１１号明細書 米国特許第４１３４１３３号明細書 米国特許第５３３９１６４号明細書 米国特許第５７５７９７３号明細書 米国特許第５７９６８６４号明細書 米国特許第６１２４８１１号明細書 米国特許第６２４３４９６号明細書 米国特許第６４５３１２０号明細書 米国特許第６５７４３６４号明細書 米国特許第６９４０９００号明細書 米国特許第７００６７００号明細書 ＥＵ−０４９５４９０ PCT International Search Report for PCT/US05/17626 PCT International Search Report for PCT/US05/19256

ビデオは、ビデオを見ている人（或いは"ユーザー"）にとってビデオの質（或いは"ビデオ・ロス"）のどの程度の低下が容認できるかによって更に圧縮可能であるが、様々なタイプのビデオ・ロスの容認性はユーザーの活動（又は"アプリケーション"）に大いに依存する。４つのタイプのビデオ・ロスは次の通りである、（１）解像度ロス（ぼんやり見える）、（２）色の深度ロス（色の濃淡の数が少ない）、（３）フレーム率ロス（１つの映画の失速又はギクシャクする感じ）、及び（４）時間ロス又は"ビデオ遅延"（ビデオ・キャプチャーから、それを見られるようになるまでの時間遅延））。

高い圧縮比を達成するために、様々な圧縮システムが、満足させようとしている複数のユーザーにとって最も容認し得る複数のタイプのビデオ・ロスを利用している。例えば、ＭＰＥＧでは、映画を見ている複数の人はフレーム率ロス或いは色の深度のロスよりは解像度ロスの方をより良く容認するので、通信チャネルにとってあまりに大量のデータを発生させる複数の高速動作シーンは解像度ロスで送られる。

ビデオ遅延は、或る複数のアプリケーションでは問題ではないが、他の複数のアプリケーションでは１つの重大な問題である。様々な圧縮システムが、ビデオを圧縮するとき、様々な量の遅延をもたらす。遅延中に捕捉され、保持されて検査される全ての複数のビデオ・フレームが、それらを圧縮する方法を決定するより良好な１つの機会を提供するので、より大きな遅延をもたらす複数のシステムの方がより高い複数の圧縮比を達成する（例えば、カメラが動いているか或いはシーン中の１つのオブジェクトだけが動いているか）。

ビデオ遅延は、映画を見るなどの"片方向"ユーザー活動では１つの問題ではない。従って、これらのアプリケーション（ＭＰＥＧなど）のために使用される複数の圧縮システムは、ビデオを圧縮してそれを通信チャネルを介して送信し始めるまでに１つの大きな遅延（多数秒以上）をもたらす。実際、通信チャネルが利用可能帯域幅が不確定な（インターネットなどの）１つのネットワークである場合には、ネットワークから受信されたビデオは、（ネットワーク輻輳に起因する失速を無くすために）更に多数秒間にわたって緩衝記憶され遅延させられることが良くある。複数の映画を見るなどの片方向ユーザー活動では時間遅延は１つの問題ではないが、圧縮されたビデオ・イメージの一部分である１つのカーソルを１つのマウスで制御する複数のユーザーなどの複数のリアルタイム"相互作用する"ユーザーにとってはそれは１つの重大な問題である。

この様な複数のリアルタイム相互作用ユーザーのその様な例の一つは、１つの通信チャネルを介する１つのコンピュータＫＶＭコンソール（キーボード、ビデオ・ディスプレイ及びマウス）のリモーティング（ｒｅｍｏｔｉｎｇ）に関連する。これらの"リモート・コンソール"アプリケーションでは、キーボード及びマウスのデータは、リモート・コンソールから通信チャネルを介して送信され、該キーボード及びマウスがあたかもターゲット・サーバに直接結合されているかのように数個の"ターゲット"サーバ・コンピュータのうちの一つに"切り換えられる"。あたかもターゲット・サーバがリモート・コンソールのビデオ・ディスプレイに直結されているかのように、対応するビデオはターゲット・サーバからリモート・コンソールへ送信される。複数のＫＶＭシステムの複数の例は、共通に所有されているビースレイら（Ｂｅａｓｌｅｙ ｅｔ ａｌ）の米国特許第５，７２１，８４２号及びパーホルツら（Ｐｅｒｈｏｌｔｚ ｅｔ ａｌ）の米国特許第５，７３２，２１２号に記載されており、この各々を参照により本明細書に援用する。

或る複数のＫＶＭシステムのための通信チャネルは、専用のローカル・ケーブルと１つの専用の回路スイッチとを使用するので、圧縮されていないビデオを伝送するのに充分な帯域幅を提供する。例えばインターネット・プロトコルを介して１つのネットワーク経由で動作するようになっている複数のＫＶＭシステム（本明細書では"ＫＶＭ／ＩＰ"システムと略称する）は、１つの専用ローカル・ケーブルに基づくＫＶＭシステムと比べると限られていて且つ不確定の帯域幅利用性を提供する。キーボード及びマウス情報をリモート・コンソールから選択されたターゲット・サーバへ折り良く送ることは、ＫＶＭ／ＩＰシステムの一つの関心事である。もっと大きな１つの関心事は、比較的大量のビデオ・データをリモート・コンソールへ折り良く送り戻すことである。今日の代表的な複数のコンピュータは毎秒２ギガビット以上で連続的にビデオを出力し、複数のリモート・インターネット接続（ＤＳＬなど）は通常は毎秒１メガビット未満で動作するので、平均して２０００対１よりかなり大きな複数のビデオ圧縮比が必要である。毎秒５０キロビットのダイヤル・モデムを使用する複数のリモート・インターネット接続は、もっと大きな複数の平均圧縮比を必要とする。

リモート・コンソールの一人のユーザーが新しい情報をサーバに入力するために自分のマウスを動かしたり自分のキーボードでタイプしたりする時、それらの動作はサーバに伝えられて、複数の新しいビデオ・イメージを作り出すためにサーバにより操作されなければならず、それはリモート・コンソールのユーザーのスクリーンに送り戻される。ビデオをリモート・コンソールのユーザーに送り戻すときの複数の遅延は、ユーザーによるキーボード又はマウス情報の入力とユーザーのスクリーンでユーザーにより知覚されるビデオ応答との間の一時的遅れを生じさせるので、不愉快である。キーボード活動後の複数の遅延は、複数のマウス動作後の複数の遅延よりは不愉快で無いので、この問題を記述するために"マウス−カーソル応答"という用語が使用される。

複数の（上記の）リモート・コンソール・アプリケーションについてのこの問題は、複数のタイプの複数の代表的ウェブ・ブラウザ・アプリケーションには当てはまらない。
複数のウェブ・ブラウザ・アプリケーションでは、ビデオ・カーソル・イメージはユーザーのコンピュータで局所的に作られるので、ネットワークがサーバにより作られた複数のビデオ・イメージで応えるときに低速であってもマウス−カーソル応答は常に非常に良好である。複数のリモート・コンソール・アプリケーションでは、カーソルはサーバから生じたビデオ・イメージの不可欠の一部分として表わされてネットワークを介してリモート・コンソールへ送られるので、複数のネットワーク遅延はマウス−カーソル応答に影響を及ぼす。

複数のリモート・コンソール・アプリケーションでは、上記４タイプのビデオ・ロスについてのユーザー容認性は他の複数のビデオ・アプリケーションの場合とは正反対である。上記のように、最小ビデオ時間遅延は複数のリモート・コンソール・アプリケーションにおける一つの要素であるが、ビデオ遅延は他の複数のアプリケーションでは重要度の低いタイプのビデオ・ロスである。複数のリモート・コンソールに送られる複数のコンピュータ・スクリーンは、通常はかなりの量の比較的小さなフォントの英数字テキストと、多数の小さなアイコンと、多数のハイ・コントラストの鋭いエッジとから成るので、複数のリモート・コンソール・アプリケーションにおける解像度の重要性は他の複数のアプリケーションの場合とは正反対である。解像度ロスをもたらすＪＰＥＧ或いはＭＰＥＧなどの複数の圧縮システムは、他の多くのアプリケーションについては満足できるものであろうが、小フォント英数字テキストと、ハイ・コントラストの複数の鋭いエッジのある複数のイメージとを読むためには満足できるものではない。このユーザー容認性の逆の順序は、色深度ロス及びフレーム率ロスにも当てはまる。これら２タイプのビデオ・ロスは、複数のリモート・コンソール・アプリケーションでは最善に容認可能であり、他のビデオ・アプリケーションでは最低に容認可能である。

複数の現存するビデオ圧縮システムは広く使用されていて広範なアプリケーションに良く適しているが、最善の可能な相互作用コンピュータ・ユーザー体験のために最適化された１つのビデオ圧縮システムが必要である。

本発明は、複数のコンピュータ・スクリーンで典型的に生じる複数の冗長性を利用するように最適化され且つ複数のリアルタイム相互作用コンピュータ・ユーザーにとって容認できる様々なタイプのビデオ・ロスを利用するためにも最適化されている１つの新しいビデオ圧縮システムである。本発明の一実施形態では、コンピュータ・ビデオの複数の捕捉されたフレームは５種類の独特に選択される"コマンド"の組み合わせに"符号化"され、該コマンドは、該コマンドの、捕捉されたビデオを非常に効率良く圧縮する能力に基づいて選択されて順番に配列される。これらのコマンドは、ネットワークを介して"クライアント"に送られ、ここで該コマンドは、どのように該複数のコマンドを解凍又は復号し、複数の捕捉されたビデオ・フレームをリモート・ビデオ・ディスプレイ上で再現するかを"デコーダ"に連続的に指図（又は命令）する。１つの独特の方法で、この実施形態は、解像度ロスや色深度ロスを伴わないが、利用可能なネットワーク帯域幅に応じて動的に調整されるフレーム率ロスを伴って、コンピュータ・ビデオを圧縮し解凍する事が出来る。それは、符号化及び復号のときに極めて小さい遅延ももたらす。

該５つのコマンドは次の通りである。即ち、（１）１つの前のフレームから複数の古いピクセルをコピーする（時には"１つの前のフレームから変化無し"、"変化無し"又は単に"ＮＣ"と称される）、（２）左からピクセルをコピーする、（３）上からピクセルをコピーする、（４）２色集合を用いて一続きの複数のピクセルの１つの列を作る、及び（５）指定された１つの色を用いて１つ以上のピクセルを作る。各コマンドは、１つの階層構造で使用されるとき、複数の独特の効率を提供する。また、複数の該コマンドは、ソフトウェア或いはハードウェアで容易に送信され、受信され、復号され得るように、８ビット以上の１つの固定された長さである複数のパケットから構成され含まれる。本発明はどのようなコマンド又はパケット長さにも限定されないが、複数の好ましい実施形態は、人気があって良く利用される複数のコンポーネント及び複数のプロセッサと両立するように８ビットの倍数（１６，３２又は６４など）である複数の長さを使用するであろう。

本発明の複数のより広い実施形態では、複数の上記コマンドのタイプのうちの１つ、２つ、３つ、又は４つが、単独で、或いはこれらの任意の組み合わせで、使用される。例えば、（この文書を１つのワード・プロセッシング・プログラムで見るなど）かなりの量の英数字テキストを含むビデオを圧縮するときに１つの２色集合だけから一系列の複数のピクセルを作るコマンドの使用は独特であると発明者は考える。複数の該コマンドのうちの他の複数のコマンドが種々の組み合わせでそれに付け加えられるときには、複数の更なる利点及び効率が得られる。他の複数の実施形態では、公知システムのビデオ圧縮を更に強化するために、該コマンドのうちの１つ、２つ、３つ、４つ、又は該５個のコマンドの全てが任意の種類の従来技術圧縮システムと関連して使用される。例えば、ＭＰＥＧ、ＪＰＥＧ、及び複数のその他（及びその全ての複数の変化形（例えば、ＭＰＥＧ２））を本明細書記載の５個のコマンドのうちの１つ以上と共に用いて複数の従来技術圧縮手法のビデオ圧縮を強化する事が出来る。

複数の"灰色優遇"色モードと称される本発明の他の複数の実施形態では、複数のリモート・コンソールのユーザーは他のどのタイプのビデオ・ロスよりも色深度ロスを良く容認するという事実を利用することによって、捕捉されたビデオを更に圧縮する事が出来る。このモードでは、捕捉されたビデオの各ピクセルは、複数のコンピュータ・スクリーンで使用される複数の代表的な色と調和する、特別に選択された複数の色の１つの集合からの、最も近い色に変換される。複数の灰色は、複数の代表的なコンピュータ・スクリーン上で優遇されるので（白と黒とは"複数の灰色"の定義に含まれる）、複数の色の集合の中で優遇される。

本発明は、ハードウェアで、ソフトウェアで、又はハードウェア及びソフトウェアの１つの組み合わせで実行される圧縮符号化で具体化され得るものである。同様に、ハードウェアで、ソフトウェアで、又は１つの組み合わせで、復号を実行する事が出来る。
１つのコンピュータの中の１つのビデオ・コントローラ・チップに直接接続することによって"ソース"ビデオを捕捉する事が出来る。或いは、１つのコンピュータの外部のアナログ・ビデオ出力、外部のディジタル・ビデオ・インターフェース（ＤＶＩ）又はその他の外部インターフェースからビデオを捕捉する事が出来る。一実施形態では、１つのＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）又はＡＳＩＣ（アプリケーション専用集積回路）を用いてハードウェアでビデオを圧縮する。他の１つの実施形態では、ビデオは、１つのビデオ出力ストリームに変換される前に、完全にソフトウェアで圧縮される。

複数のビデオ圧縮コマンドは、１つのネットワークを介してリモート・コンソールに送られ、ここで解凍されてユーザーに対して表示される。リモート・コンソールは、ＰＣソフトウェアを用いて複数のコマンドを復号する１つの普通のＰＣ（パーソナルコンピュータ）であって良く、或いは１つの低性能マイクロプロセッサで作られた１つの小型の"シン・クライアント"装置であって良い。一実施形態では、複数のコマンドは、全て、１つの低性能マイクロプロセッサで動作するソフトウェアで容易に解凍され得るように、１つ以上の８ビット・パケットから成るように設計される。或いは、１つのハードウェア装置（１つのＦＰＧＡ又はＡＳＩＣなど）は、リモート・コンソールで複数のコマンドを完全に復号する事が出来る。その様な１つの場合には、リモート・コンソールは、コマンド復号のための１つの計算装置や、ユーザーのビデオを表示するための１つのビデオ・コントローラ・チップを必要としないであろう。この様な１つの低コスト・ハードウェア（又は組み合わされたハードウェア／ソフトウェア）リモート・コンソールは、以下では１つの"マイクロクライアント"と称される。

本発明はコンピュータ"ブレード"手法にも応用され、これらの手法では複数の個々のサーバ・コンピュータは単一のカードに内蔵され、これらのカードの多くは１つの共通のブレード・シャシーに組み込まれて１つの共通の電源と複数の中央制御機能とを共有する。複数のブレード上の在来のケーブルに基づくＫＶＭスイッチ手法は、複数のローカル・ケーブル取り付けユーザーに各ブレード・コンピュータへのアクセスを与える事が出来るが、もし複数のユーザーが１つのネットワークを介する複数のブレードへのＫＶＭアクセスを必要とするならば、本発明をブレード・シャシー又は各ブレードに包含させることが可能であり、複数のビデオ圧縮コマンドをブレード・シャシー内の１つの共通ネットワーク・インターフェースに与えてネットワークを介して種々のリモート・コンソールに送る事が出来る。

従って、シン・クライアント、マイクロクライアントにおける複数のアプリケーションと複数のリモート・コンソール・アプリケーション（複数のＫＶＭ／ＩＰシステムなど）のために複数のＬＡＮ、複数のＷＡＮ、ダイヤルアップ又は他の任意の複数のネットワークを介してコンピュータ・ビデオを送るために一般的にコンピュータ・ビデオを圧縮するときに本発明を使用する事が出来る。

本特許出願ファイルは、カラーで制作された少なくとも１つの図面を含む。複数のカラー図面を伴うこの特許又は特許出願公開の複数のコピーは、請求と所要手数料の支払いとに応じて庁から提供されるであろう。

本発明は、１つの介在するネットワークを経由することを含めて、１つの通信チャネルを介してコンピュータ・ビデオを送ろうとする任意のハードウェア又はソフトウェアで実施され得るものである。その様な実施例の一つが図１に示されており、これは限定ではなくて例として記述されている。実際、当業者が本発明を検討すれば、複数の添付図面において具体化されて本明細書に記載されているように、他の複数の実施形態が理解されるであろう。

図１において、ＫＶＭ／ＩＰシステム１０は、１つのリモート・コンソール・クライアント１１と１つのサーバ装置１４とを含む。図示されている実施形態では、リモート・コンソール１１は、ネットワークに対する備えができている１つのＰＣ（これは１つのキーボード、ビデオ・ディスプレイ及びマウスを含んでいる）においてＰＣソフトウェアで実現されている。クライアント１１は、ＫＶＭ／ＩＰ装置１４を介して１つのターゲット・サーバ１５と１つのインターネット・プロトコル・ネットワーク１３を介して通信する。装置１４及びクライアント１１は、１つのダイヤル・イン、ＤＳＬ、ＷＡＮ、ＬＡＮ、Ｔ１、無線などの任意の形のインターネット・プロトコル接続性を介して該装置及びクライアントが通信することを可能にする標準的なネットワークＩ／Ｏハードウェア及びソフトウェアを含む。

図１において、該装置はターゲット・サーバ１５とクライアント１１との間の１つの媒介として作用し、あたかもクライアント１１がそれに接続され向けられているかのように自分のキーボード、ビデオ・ディスプレイ及びマウスをサーバ１５に結合させることを可能にする。この点に関して、ＩＰネットワークのアドレス指定及びスイッチング能力と組み合わされたシステム１０の方法及び動作は、本譲受人により、及びアラバマ州ハンツビルのサイバーコンピュータプロダクツ（Ｃｙｂｅｒ Ｃｏｍｐｕｔｅｒ Ｐｒｏｄｕｃｔｓ）により、及びワシントン州レドモンドのアペックス社（Ａｐｅｘ，Ｉｎｃ．）により販売されているものなどの複数のＫＶＭスイッチの特徴を示す。

クライアント１１は、１つの標準的ＴＣＰ／ＩＰアドレスによるなどの方法による（装置１４を介する）ターゲット・サーバ１５の識別を容易にするソフトウェアを含んでいる。クライアント１１と装置１４との通信が確立されると、クライアント１１は、該クライアントで入力されたキーボード・データ及びマウス・データをＩＰネットワーク１３を介して装置１４に送るソフトウェアを使用する。装置１４は自分に向けて転換され又は送られたデータを受け取り、それを、該キーボード及びマウスがサーバ１５に直接取り付けられているかのようにサーバ１５のキーボード・ポート及びマウス・ポートに加える。これに応答して、サーバ１５は（サーバ１５で動作している任意のアプリケーションを介して）該キーボード・データ及びマウス・データを操作して新しいビデオ・データを作り、これはサーバ１５のビデオ・出力を介して装置１４へ出力される。

装置１４は、サーバ１５からビデオを受け取ると、後述する本発明の複数のアルゴリズムのうちの一つによってそれを圧縮し、その結果としてのビデオ圧縮コマンドをＩＰネットワーク１３を介してクライアント１１に送る。圧縮は、装置１４において１つのＦＰＧＡ、ＡＳＩＣ又はその他の任意のハードウェア又はソフトウェアで行われ得る。或いは、装置１４をサーバ１５に"埋め込んでも良く、或いは、もしサーバ１５が圧縮を実行して、その結果としての複数のコマンドをＩＰネットワーク１３に直接送るソフトウェアを含んでいれば、装置１４を無くする事が出来る。受領すると、クライアント１１は該コマンドをＰＣソフトウェアで復号し、ユーザーに見せるためにターゲット・サーバのビデオをクライアントＰＣのスクリーンで再生する。或いは、コマンド復号はクライアント１１においてハードウェアで行われても良い。

図１の実施形態では、たとえクライアント１１とサーバ１５とが地球の正反対の場所のような物理的に遠くの場所に位置していても、ユーザーはクライアントＰＣのキーボード、ビデオ・ディスプレイ及びマウスをこれらがサーバ１５に直接接続されているものとして知覚するべきである。装置１４を介してキーボード・データ及びマウス・データをサーバ１５に送り、ビデオを逆に送るときに過剰な遅延があれば、この目的が妨げられる可能性がある。キーボード及びマウスは比較的少ない１つの量のデータ・トラフィックを必要とし、それは迅速に且つ比較的効率良く運ばれ得るのであるが、大量のビデオ・データは１つのより困難な問題をもたらす。効率的であるためには、ビデオは、成るべく迅速に装置１４により圧縮され、ＩＰネットワーク１３を介して伝送され、クライアント１１により解凍され、ユーザーのスクリーンで提示されなければならない。過度の遅延はマウス−カーソル応答において最も明らかである。複数のマウス動作と、スクリーンに提示されるカーソルの応答との間のどんなに僅かな遅れでも、ユーザーにとっては不愉快なものである。

図２は、本発明の１つの実施例を示している。本発明の範囲内で考えられる様々なハードウェア及びソフトウェアの実施形態が多数あり、図２の実施形態は唯一のその様な方法ではない。本教示を検討した後、当業者は本発明の範囲と矛盾しない、本発明を実施する他の複数の方法を認識するであろう。

図２の上部において、ソース・ビデオ２１は、アナログであってもディジタルであっても、任意の形であって良い。大概の現在の複数のビデオ・コントローラ・チップのビデオ出力は、複数のラップトップ・コンピュータに用いられているものなどの複数のフラットパネル・ディスプレイに用いられるディジタル形で利用可能である。ビデオ・コンプレッサ２３は、ビデオ・コントローラ・チップ２０の複数の出力ピンに直接接続することができ、或いはターゲット・サーバ１５の１つの外部コネクタに接続する事が出来る。外部コネクタの一つのタイプはＤＶＩ（ディジタル・ビデオ・インターフェース）であり、これはディジタル・ビデオを複数の外部ディジタル表示装置に接続するための１つの規格である。他の任意のソース・ビデオも十分役に立ち、本発明はそれ自体としては限定されない。

任意に、各ピクセルの色を定義する複数のビットの数を減らすために１つの色深度減少器２２をビデオ・コンプレッサ２３に包含させる事が出来る。それは、これを、ピクセルの複数の色を複数のゾーンに分類することによって実行する。ソース・ビデオ２１がディジタル・ビデオであるときには、色深度減少の最も簡単な手段は複数の最下位桁ビットを無視することである。例えば、８ビット赤信号、緑信号及び青信号の各々の最下位桁３ビットを無視することによって２４ビットの色を１５ビットの色に変換する事が出来る。各８ビット色信号の最下位桁４ビットを無視すれば１２ビットの色になる。７ビット灰色優遇色モード及び５ビット灰色優遇色モードと称されるより複雑な色減少方法が後述され、また図１１及び１８に示されている。

ソース・ビデオ２１がアナログ・ビデオ信号であれば、色深度減少器２２は１つのアナログ−ディジタル変換器を包含する必要がある。アナログ・ビデオの場合には、各ピクセルは３つのアナログ信号（赤、緑及び青）によって定義される。Ａ／Ｄ変換器は、各ピクセルの３つの信号の強度を、それらがどんな"ゾーン"の中にあるかを検出することによってディジタル化する（上記のディジタル色深度減少器が実行することと非常に良く似ている）。アナログ・ビデオに関しての主要な相違点はノイズである。一つのアナログ信号が一つのゾーンの端にある場合、一つの少量のアナログ・ノイズが後のフレームにおいてディジタイザを一つのゾーンから他のゾーンへと跳ねまわらせる可能性がある。その様な場合には、ソース・ビデオ２１が、たとえ変化していなくても、変化しているように思われるであろう。従って、アナログ入力では、この"ゾーン跳ね回り"を減少させるために何らかのノイズ抑圧方法を使用する必要がある。任意のノイズ抑圧方法を使用することが出来るが、一例においては、入力信号は、１つのゾーンにある時、他のゾーンにあると思われるようになる前に少なくとも閾値量だけそのゾーンから外に出なければならない。前のフレームの間に各ピクセルの信号がどのゾーンの中にあったのかというこの比較は、ビデオ・フレーム中の全てのピクセルについて実行される。

ソース・ビデオについて言及された数個の実施形態は本発明の範囲内で考えられるが、図２の特定の実施例は、ターゲット・サーバ１５内のビデオ・コントローラから受信されたディジタル・ビデオはソース・ビデオであろうと推定する。ビデオ・チップ２０の出力はソース・ビデオ２１であり、これはビデオ・データの１つの連続的ストリームである。ビデオ・コントローラ・チップ２０は本発明のどの側面によっても制御される必要はない（本発明は確かに何らかのビデオ・チップ制御と関連して使用され得るが）。即ち、ビデオ・チップ２０は、自分の内部タイミングに従って１つの連続するストリームでビデオを出力する。

ソース・ビデオ２１は、ビデオ・コンプレッサ２３への入力である。もちろん、複数の汎用又は専用プロセッサなどの他の複数の処理装置をハードウェア・ビデオ・コンプレッサ２３の代わりに用いる事が出来る。ビデオ・コンプレッサ２３は、少なくとも２つのフレーム・バッファ２４及び２５を含んでおり、又、付加的な複数の動作複雑さのために付加的な複数のフレーム・バッファ又は複数のフレーム・バッファ・タイプを含むこともできる。クライアント１１がネットワーク２９上で接続を確立する前、ソース・ビデオ２１はフレーム・バッファ２４又は２５の一方によって（図２に示されている時点では、フレーム・バッファ２５がアクティブであり、このことは、それがビデオを捕捉していることを意味する）連続的に捕捉される（そして連続的に上書きされる）。

１つのクライアントが初めにネットワーク２９上に接続するとき、ビデオ捕捉は停止し、エンコーダ２６はバッファ２５内の捕捉されたビデオ・データを読み取って圧縮し始める。それは、フレーム・バッファの始まり（これはスクリーン上の左上のピクセルである）から出発し、１ピクセルずつフレーム・バッファの終わり（これはスクリーン上の右下のピクセルである）まで進み、前を見て複数のコマンドの最も効率的なシーケンスを構築する。エンコーダ２６が（後述するアルゴリズム実施形態に従って）このコマンド列を構築するとき、サーバＣＰＵ２７は、Ｉ／Ｏ２８及びネットワーク２９を介してそれらをクライアント１１へ送っている。エンコーダ２６がバッファ２５内の最後のピクセルで終了した後、該複数のフレーム・バッファは切り換わって、ソース・ビデオは他方のフレーム・バッファ（この場合にはバッファ２４）で捕捉され始める。この切り換わりは、たとえＣＰＵ２６がネットワーク２９へのコマンドの送信を終えていなくても行われる。この切り換わり後、バッファ２５内のフレームは旧フレームになって、クライアントのスクリーン上で表示されている（或いは直ぐに表示される）フレームを表わす。

ソース・ビデオは、捕捉されていない間動作し続けていたので、捕捉が始まるときにソース・ビデオはスクリーンを半ばまで下っていたか、或いはスクリーン中の何処かにあり得る。バッファ２４内への新しい捕捉が何処から始まるかということに関わらずに、バッファ２４は自分が捕捉を開始したスクリーン位置に戻るまで完全な１ラップの間継続する。その結果は、ソース・ビデオ２１から捕捉されたビデオの１つの完全な"新しい"フレームである。新しいビデオのフレームが捕捉された後にＣＰＵ２７が第１の圧縮されているフレームからの全コマンドをネットワークを介して送れるようになっていなければ（場合によってはネットワーク輻輳或いは低速のネットワークに起因して）、捕捉プロセスはバッファ２４内の捕捉されたビデオに上書きする動作を続行する。ネットワークがもっと多くのコマンドに対する準備を整えているならば（そして、ビデオの少なくとも１つのフレームが捕捉されているならば）、捕捉は中止され、第１フレームのために行われた同じプロセスが続行される。しかし、今、クライアント１１はその第１フレームを持っているので、エンコーダ２６は、今、新しいフレームの中の各ピクセルを旧フレームの中の各ピクセルと比較することができ、もし複数のピクセルが変化していなければ、圧縮は遥かに良好であろう。新しいビデオの少なくとも１フレームが捕捉され、ネットワークがより多くのコマンドのために準備ができた後、同じプロセスが続行される。ネットワークの準備が整うのを待ちながら捕捉を続行するこのプロセスは、クライアントにとっての実効フレーム率をネットワークの複数の条件に応じて低下させ、"最新の"ビデオを表示する動作はビデオの"全部"を表示する動作より優先される。事実上、捕捉されたビデオは１つの期限切れの商品。リモート・コンソールの複数のユーザーは、ビデオ遅延よりもフレーム率ロスの方を遥かに容認するので、もし"全ての"ビデオ動作が待ち合わされて後に送られるならば、該ユーザーは我慢しなければならない。

従って、本例では、（以前は旧フレーム・バッファだった）新フレーム・バッファはソース・ビデオの最新のフレームを捕捉する。（旧フレーム・バッファ内の）旧フレームと（新フレーム・バッファ内の）新フレームとは、ビデオを比較して圧縮する目的のためにエンコーダ２６により読み出される。複数のビデオ・フレームを捕捉して圧縮のために比較する複数の代替法があるが、本明細書ではその様な方法の全ては説明しない。

本発明の実施形態のうちの狭い方の実施形態では、図３に関して本明細書に記載されたビデオエンコーダの全ての側面が使用される。"本発明"又は"複数の本発明"に関して本明細書に記載されたこれらの側面の全てについての詳細な記述は、記載された複数のアルゴリズム例の全ての側面を本発明が必要とすることを意味すると解されるべきではない。複数の例は、複数の本発明の複数の効率を実現し得る１つの方法の例を記述する目的のために提供されたものである。本発明の他のより広い側面及びより狭い側面を、以下の複数の記述から理解することができよう。図３では、フレーム・バッファ２４及び２５から読み出されたビデオを圧縮するために５つのビデオ圧縮コマンドが提示されている。それらは、階層的順に、（１）１つの前のフレームから複数の旧ピクセルをコピーする、（２）左からピクセルをコピーする、（３）上からピクセルをコピーする、（４）２色集合を用いて複数のピクセルの列を作る、（５）指定された色を用いて１つのピクセルを作る、である。本発明者は、階層的コマンドのこの組み合わせが複数のコンピュータ・ディスプレイのための強制的なビデオ圧縮を提供することを発見した。これらのコマンドのうちの初めの３つは３次元コピー動作（水平、垂直及び時間）を提供し、４番目のコマンドは（テキストなどの）２色だけから成るスクリーン・セグメントについての複数の独特の効率を提供する。

図３に示されている実施形態では、５つの異なるビデオ圧縮コマンドがある。これら全てのコマンドは単一のパケット又は複数のパケットから作られ、その各パケットは１つの８ビット・バイトから成る。各コマンドの第１パケットの初めの１ビットから３ビットは命令符号（即ち"オプコード"）であって、これらはそのコマンドの基本機能を決定する。"Ｅ"ビットは"拡張"ビットであり、残りの複数のビット（Ｒ、Ｃ及びＰ）は"ペイロード"ビットである。５つのコマンドの一般フォーマットが図３に示されており、これらのより詳細なフォーマットが図４〜１０に示されている。パケットの長さが異なる複数の実施形態では、複数のペイロード・ビットの数が異なるであろう。例えば、複数の１６ビット・パケットは８個の付加的なペイロード・ビットを有する。

最低階層コマンドであるＭＰ（ピクセルを作る）コマンドは第１ビット位置（ビット位置７）に１を有し、その次に、１つの色を定義する複数のペイロード・ビット（"Ｐ"ビット）がある（１から始まるコマンドは他には無い）。使用される色ビットの数が７であれば、ＭＰコマンドの長さは１バイトである（図３に示されているように）。使用される色ビットの数が１５であれば、ＭＰコマンドは２バイトの長さとなり、第１バイトの第１ビットは１である（図４に示されているように）。同様に、色ビット（Ｐビット）の数が２３であれば、ＭＰコマンドの長さは（図５に示されているように）３バイトになり、以降同様である。ＭＰコマンドは最も理解しやすいコマンドであって、最小の圧縮を提供する。それは、本質的に、色を特定するペイロードで"１ピクセルをこの色にせよ"と言う。コンピュータ・コンソールのための一般のセッティングは１５ビット色（赤のために５ビット、緑のために５ビット、青のために５ビット）である。１５ビット色は２バイトＭＰコマンドにより支援される。複数の単一バイトＭＰコマンドは、７個のペイロード・ビットを有するので、２^７（１２８）個の異なる色を与える事が出来る。更に後述される７ビット灰色優遇色モードは、ソース・ビデオをコンピュータ・コンソールで広く使用されている１２８色のうちの最も近い色にどのように"変える"事が出来るかを説明する。本発明の作用についての以下の検討は複数の１バイトＭＰコマンドでの作用を記述しているが、本発明は特定の数の色ビット（Ｐビット）に限定されない。

圧縮性に関して、全てのピクセルが１つのランダムな色であるフレームは、解像度の低下無しでは圧縮不可能であろう（ＪＰＥＧ、フラクタル分析などの他の圧縮システムは、まちまちな程度の解像度低下で圧縮を提供する事が出来る）。図３の実施形態では、このランダムなフレーム内の全ての単一ピクセルは１つのＭＰコマンドで符号化され、もしこのフレームが百万個のピクセルを有するならば、これを符号化するために百万個のＭＰコマンドが使用されるであろう。もしエンコーダが１つのピクセルを符号化するために他のどのコマンドも使えなければ、エンコーダはＭＰコマンドを使う。全てのピクセルは、常に、１つのＭＰコマンドで符号化されるのに適している。従ってＭＰコマンドは図３において最低の階層位置を占める。優先順位の一覧表である図３は、エンコーダ２６が一番上のコマンドを、次に２番目のを、その後に３番目、その後に４番目のを行おうとし、その後に最後の手段としてのＭＰコマンドに到達することを示している。

図３のオプコードを見ると、ビット位置７の１つの"１"は、ピクセルを作るコマンドを一義的に特定する。もしビット位置７に１つの"０"があるならば、そのコマンドは図３に示されている他の４つのコマンドのうちの１つであり、次の２ビット（ビット位置５及び６）が、他の４つのコマンドのうちのどれが当てはまるかを特定する。ビット位置５及び６の１つの００は１つのＣＯ（旧をコピーするか又は無変化）コマンドを示し、１つの０１は１つのＣＬ（左をコピーする）コマンドを示し、１つの１０は１つのＣＡ（上をコピーする）コマンドを示し、１つの１１は１つのＭＳ（列を作る）コマンドを示す。その後、これら４つのコマンド・タイプの各々は、オプコードに続くペイロード・ビットを有する。ペイロード・ビットは複数のＲビット、Ｃビット及びＰビットである。ＥビットについてはＭＳコマンドのもとで後述する。

ＣＯ、ＣＬ及びＣＡコマンドのペイロード・ビット（Ｒビット）は、該コマンド操作が反復される回数を示す。ＣＯコマンドは、複数のピクセルが現在表示されているピクセルから変化していないことをクライアントに教える。従って、エンコーダ２６は、旧フレーム・バッファと新フレーム・バッファとを比較し、"新"フレーム内の現在のピクセルが"旧"フレーム内の同じ複数の位置のピクセルと異ならないと判定したときには複数のＣＯコマンドを喚起する。従って、ソース・ビデオにおいて変化していないスクリーンの複数の位置のために複数のＣＯコマンドが送られる。

次の２つのコマンドは、旧フレームと新フレームとの比較ではなくて１つの共通の"新"フレーム内の位置に関して複数のピクセルを比較する。ＣＬコマンドは、現在のフレーム内の直ぐ左の位置のピクセルから色をコピーするようにクライアントに指示する。もし現在のピクセルがビデオ・ライン上の第１ピクセルであれば、直ぐ左のピクセルは前のライン上の最後のピクセルである。ＣＡコマンドは、現在のフレーム内で直ぐ上のピクセルから色をコピーするようにクライアントに指示する。ＣＬ、ＣＡ及びＣＯコマンドは、以降、"コピー"コマンドと称される。１つの共通のフレーム内での関連或いは旧フレーム及び新フレーム間の複数の関連でピクセルをコピーする動作を提供する他の複数のコマンドを代わりに使用する事が出来る。コンピュータ・ビデオに存在する水平及び垂直の複数の長方形と複数のラインとの激増のために現在記述されているコマンドはコンピュータ・ビデオにおいて特別に有利である。例えば、複数の水平なラインではＣＬコマンドが特に有益であり、複数の垂直なラインではＣＡコマンドが特に有益である。

最後のコマンドはＭＳコマンド即ち列を作るコマンドであり、それ自身、現在の複数のタイプのビデオ符号化において独特のものである。ＭＳコマンドは、コンピュータ・ビデオの特別の側面、即ち代表的コンピュータ・スクリーンの大部分が２色だけから構成されるという側面を利用する。コンピュータ・ビデオにおけるその典型的な例は、スクリーンの大部分が一様な背景色上のテキスト表示色から成るテキスト情報である。その様な場合、ＭＳコマンドは、エンコーダ２６がテキストの鮮明さを低下させずに非常に大量の圧縮を行って大量のビデオを作ることを可能にする。

該複数のコマンドの各々について、その複数のペイロード構造及び現実の複数のアプリケーションに関して論じる。前述したように、ＣＯコマンド（図３，６及び７）は、本質的に、現在のピクセルが前のフレームの同じ位置にあるピクセルから変化していないことを確認する。圧縮を促進するために、ペイロードは、現在のピクセルが変化していないことだけではなくて、一定の数の引き続くピクセルが変化しなかったことも確認する。その数がどんなものであるか、後述する。図３でＣＯコマンドについて示されているように、３ビット・オプコードの後に、そのＣＯコマンドの繰り返し総数を示す５ビット（ＲＲＲＲＲ）がある。これら５ビットは、０と３１との間の任意の２進値にセットされて良い。

ゼロの繰り返し総数は無意味であるので、初めは、この５ビット総数は前のフレームから変化しなかったロー内の３２個までの連続するピクセルを定義すると推測される。しかし、（２バイト以上の長さのＭＰコマンドの代わりに）複数の１バイトＭＰコマンドが使用されるだけならば、繰り返し総数１では１つの１バイトのピクセルを作る（ＭＰ）コマンドは１つのＣＯコマンドと同じ圧縮値を有するので繰り返し総数１も無意味である。その場合、０００００のペイロードが繰り返し総数２を意味し、１１１１１のペイロードが繰り返し総数３３を意味するように、繰り返し総数ペイロードは総数２から始まって良い。その場合、少量の追加の効率が提供される、即ち、１つの５ビット・ペイロードを有するＣＯコマンドが２ピクセルと３３ピクセルとの間の何処かで既に表示されたフレームから変化していないという事実を確認する。

好ましい実施形態は、更に効率を付加する。３４個以上のピクセルが変化していないと仮定しよう。図６に示されているように、１つの０００オプコードを有する１つの第２の直接連続するバイトが、０００オプコードを有する１つの第１バイトに続いて、２ピクセルから３３ピクセルまでのピクセルを再び表わす第２の５ビットを提供する事が出来る。しかし、その代わりに、デコーダ３０は、ＣＯオプコードを有する２つの連続するパケットを検出し、その両方の５ビット・ペイロードを１つの１０ビット・ペイロードを有する単一のＣＯコマンドとして解釈する。１つの１０ビット・ペイロードでは、連続するＣＯピクセルの数は３４から１０２５に増える。換言すれば、僅か２つの８ビット・バイトで一千個以上のピクセルをクライアントに送る事が出来る。ＣＯコマンドの効率は上昇している。ＣＯオプコードを有する２つの連続するパケットを作る理由は、３４以上の繰り返し総数が必要であるという事実以外には無い。もし３３以上の繰り返し総数が不要ならば、エンコーダ２６はオプコードを有する２つの連続するパケットを作らない。

もしエンコーダ２６が３５又は３６の繰り返し総数を必要とし、第２バイトを必要とするならば、１つの２バイトＣＯコマンドは一時的に低効率となる。しかし、（１０２４×７６８解像度スクリーン上の実線など）繰り返し総数が一千ピクセルまで増大すると、２バイトだけで線全体を圧縮する事が出来る。更に、第２のＣＯコマンドに１つの第３のＣＯコマンドが続くならば（図７に示されているように）、デコーダ３０は１５ビット・ペイロードを検出する。１つの第４のＣＯコマンドがあれば、それは２０ビット・ペイロードを検出する。１つの４バイトＣＯは百万以上のピクセルが変化していないということを確認する事が出来るが、これは１０２４×７６８解像度の１つの完全なフレームのために必要とされる数より多い。本発明は連続するＣＯコマンドのどのような特定の数にも、或いはどのようなビデオ・スクリーン解像度にも限定されないが、本目的のために、（三千三百万ピクセルまで支援する）１つの５バイト・コマンドは、現在考えられている最高のビデオ・スクリーン解像度での１つの完全なフレームのために充分に大きな繰り返し総数を提供する。

ＣＬコマンド及びＣＡコマンドは、上記のＣＯコマンドと同様に作用する。これらは、複数の異なるピクセル（左のピクセル、或いは上のピクセル）を複写するが、これらは同じ構造を、即ち１つの３ビット・オプコードに繰り返し総数を特定する１つの５ビットＲＲＲＲＲペイロードが続く構造を有する。また、ＣＬコマンド及びＣＡコマンドの各々は、図８にＣＬコマンドについて示されているように、１０ビット、１５ビット、２０ビット、或いはもっと長いペイロードを形成するように配列され得る。

ＣＯ、ＣＬ及びＣＡ間の階層的優先順位は、これらのコマンドのうちの２つ以上が現在のピクセルに対して同時に適している場合に限って適用される。ＣＯコマンドが現在のピクセルに適していて他のどのコマンドも適していないとエンコーダ２６が判定すると、エンコーダは一時的に他のコピー・コマンドを無視して旧フレーム及び新フレームからの複数のピクセルを比較して１つのローの中の何個のピクセルに対してＣＯコマンドが適するのか判定し続ける。エンコーダ２６は、現在のピクセルに対してＣＡコマンド又はＣＬコマンドだけが適していることを見出したならば、同じことを実行する。特定された（ＣＯ、ＣＡ又はＣＬ）条件が最早当てはまらないという最初の場合に、エンコーダ２６は１つ以上の連続する図３のコマンドを送り、その後、符号化のために次のピクセルを評価する。換言すれば、与えられたピクセルについて１つの繰り返し総数条件が当てはまり、そして唯一の繰り返し総数条件が与えられたピクセルに当てはまるとエンコーダ２６が判定すると、該エンコーダは現在の繰り返し総数条件が有効でなくなるまで他の全てのコマンド評価を無視する。これが起こると、それはコマンド（オプコード及び繰り返し総数）を作って、それをクライアントに送る。

１つのコピー・コマンド（ＣＯ、ＣＬ、又はＣＡ）が適する間は、それが適さなくなるまでエンコーダはそれで続行する。その後、エンコーダはその分析を終え、複数の適切なバイトを作る。しかし、もし始めに同じピクセルに対して複数の繰り返し総数条件（ＣＯ、ＣＡ又はＣＬ）が適するならば、エンコーダは、単に、これらの条件が当てはまる複数の連続するピクセルを数え始める。これらのコマンドのうちの１つが当てはまる間、該カウンターは動作し続ける。結局、エンコーダは、繰り返し総数全体に当てはまった唯一のコマンドだけを選択するので、１つのカウンターを数えるだけである。それは、各コピー・コマンドについて１つずつの、３つの異なるカウンターを動作させなくても良い。エンコーダは、数え続けているとき、いずれかのコマンドが最早適さないことを見出すであろう。そのことが、"立ったままにされて"いるコマンド・タイプが無くなるまで充分な回数だけ発生したならば、エンコーダ２６は残存していた最後のコマンドのためのオプコードを、最後まで残存していたコマンドが適さなくなる前に適していたピクセルの数を特定する繰り返し総数と共に、作成する。

１つの例として、現在のピクセルに対してＣＬ、ＣＡ及びＣＯコマンドが全て適すると仮定しよう。エンコーダは、それを記録して数え始める。次のピクセルで、エンコーダは、全てが依然として当てはまると判定するので、カウンターを２にインクリメントする。このプロセスは、７番目のピクセルでＣＬ条件が最早当てはまらなくなるまで、全く同じに続行される。エンコーダ２６はＣＬを動作から脱落させ、カウンターをインクリメントし続ける。続行中、１４番目のピクセルでＣＡ条件が当てはまらなくなる。ＣＯコマンドが最後まで残存したコマンドであるが、エンコーダはなお数えるのを止めない。それは、（５１"ピクセルで、と仮定する）ＣＯ条件が当てはまらなくなるまで、インクリメントを続ける。そのポイントで、エンコーダ２６は２個の連続するバイト、０００００００１及び０００１００００、をクライアント１１に送る。第１バイトは、初めに繰り返し総数３であると思われるものについての１つのＣＯ条件（オプコード＝０００）を示す（１つの"ゼロ"は繰り返し総数２を明示することを想起）。しかし、デコーダ３０は、次のバイトを見て、複数の連続するＣＯコマンドを１つの１０ビット・ワードを形成するように一緒に読まなければならないことを知る。（デコーダ３０は、そのワードを復号する前に１つの第３ＣＯバイトが該第２バイトに続かないことを確かめるために、その０００１００００バイトの先の次のバイトも見ることに注意しなければならない）。１０ビット・ワード００００１１００００は、繰り返し総数５０と一致する。２つのＣＯコマンドのこの列は、次の５０個のピクセルを前に送られたフレームでの該ピクセルの色から変化させないようにデコーダに指示する。

１つのコピー・コマンドが立っている最後の１つになったならば、次のコマンドのためのオプコードが決定される。この最後の立っているコマンドが適さなくなったとき、このコマンドについての繰り返し総数が決定される。そのポイントで、エンコーダは、その繰り返し総数を特定するために必要なバイトの数も決定する。その総数を５ビットで提供し得るならば、エンコーダは１つの１バイト・コマンドを作る。もし１０ビットが必要であれば、エンコーダは１つの２バイト・コマンドを作り、以降同様である。好ましい実施形態のこの側面は、複数の可能な最長の繰り返し総数の特定を最善に利用するので、有利である。実際、他の関連する面に基づいて複数のピクセルを特定する、ＣＡ、ＣＬ及びＣＯ以外の他の複数のコピー・コマンドが考えられる。

ＣＯ、ＣＬ及びＣＡコマンド間の階層的優先順位は、もしこれらのコマンドのうちの２つ以上が等しく最後に立っているコマンドであれば、適用される。その場合、エンコーダは始めに旧コピー・コマンドを利用する。旧コピー・コマンドは、その結果が複数のピクセルを跳び越すことであるのに過ぎないので、クライアントに課される負担は最小になる。一方、上からコピーし或いは左からコピーするためにはクライアントは動作しなければならない。これら２つのコピー・コマンド間では左コピーの方が上からのコピーよりも軽い負担をクライアントに課すので、優先順位が高い。左コピーでは、クライアントは直前のピクセルを一度読んでそれをピクセルの数だけ書くだけで良い。しかし、上からコピーするには、上のビデオ・ラインから或る数のピクセルを読み取ってそれを或る数のピクセルに書くことによらなければならない。

一方、もしクライアントがソフトウェアではなくてハードウェアで実現されていれば、そのハードウェアは複数のコマンドを処理するために専用されるであろうから、コピー・コマンド優先順位は問題ではない。好ましい実施形態は、複数のコピー・コマンドに優先順位を付けることによってソフトウェア・クライアントに対する負荷を最小にする。

第４のコマンド・タイプ（そして、複数の非コピー・コマンドのうちの最高優先順位）は、図３、９及び１０に示されているＭＳ（列を作る）コマンドである。典型的コンピュータ・スクリーンの圧縮の分析に基づいて、列を作るコマンドは、最後に圧縮効率に大いに寄与する。ＭＳコマンドに関する理論は、テキストというものは、その色が何色であれ、殆ど常に２色モードであるということである。実際、本発明者は、典型的なコンピュータ・スクリーンを調べて、スクリーンのテキスト及びその他の領域の大部分を複数の長いＭＳコマンドで定義し得ることを確かめた。ＭＳコマンドは、複数のアイコン、複数の文書、複数のラベル、及び複数のツールバーの複数のテキスト部分を圧縮することに関して大きな効率を提供する。他の圧縮方法は、必要な圧縮効率を提供しないか、或いはスクリーン上のテキスト資料を読まねばならないユーザーにより要求される鮮明さを提供しない。

例えば、ユーザーがテキストを１フレームから次のフレームへとスクロールしている場合を取り上げると、テキストは単に少し上に移動するだけである。圧縮器の見地からは、各フレームは符号化される必要のある複数のピクセルの１つの新しいグループである。圧縮器は、テキスト・ウィンドウの回りの領域についてＣＯコマンドを書くことによって或る繰り返し総数効率を得られるけれども、調整されたテキストにぶつかると、複数の長い繰り返し総数が発生しないので繰り返し総数圧縮は非能率となる。本発明者は、コピー・コマンドがうまく働かない複数のテキスト型領域のために効率を付け加えた。正確にどのようにしてこれらのＭＳコマンドが圧縮効率を付け加えるか説明する。

初めに、前と同様に、３ビット・オプコードがＭＳコマンドを特定する。第１オプコード・ビット（０）は、そのコマンドがピクセルを作るコマンドではないことを示す。次の２ビット（１１）は、該コマンドを列を作るコマンドであると特定する。ＭＳコマンドを呼び起こす機会は前の４つのピクセルを見るエンコーダによって特定される。（複数の付加的な特徴を提供するために複数の前を見る操作を付け加える事が出来るが）コピー・コマンドは前を見る操作を必要としないことに当業者は注意するべきである。或いは、ＭＳコマンドでは、この前を見る操作のために多少のピクセルを使用する事が出来る。理解されるであろうように、前を見るのピクセルの数は、（１）繰り返し総数符号化がそれ以上効率良くはならないことを保証するのに充分な程度に大きく、（２）ＭＳコマンドを適切に適用し得るようにするのに充分な程度に短く、且つ（３）使用されるワード長さを収容する整数として評価されるように、戦略的に選択されるべきである。本明細書において単に実例を挙げる目的のために、４ピクセルを説明する。ＭＳコマンドは、次の４ピクセルの中で２つの条件、即ち、（１）ＣＯ、ＣＬ又はＣＡコマンドが適するようになろうとしていないこと、及び（２）これらの、次の４ピクセルが２種類の色に限定されていること、が発生しているとエンコーダが判定したときに、呼び出される。図９及び１０に例示されている"拡張された"ＭＳコマンドは、ＭＳ操作を拡張するけれども、第１バイトだけがビット５，６及び７においてオプコードを含んでいる。次に、拡張されたＭＳコマンドについて更に説明する。

前述されたように、ＭＳコマンドは、異なる２色の組み合わせであるピクセルの列について使用される。利用し得る色の集合に含まれている該２つの色は、直前のピクセルからの色（色０）及びそれの前の最新の異なる色のピクセルからの色である。もちろん、ＭＳコマンドのために２つのピクセル色を特定する他の方法を、該色の厳格な特定、現在のフレーム又は前のフレーム内の選択された位置からの特定、或いは２色集合のルックアップ・テーブルからの特定を含む様々な選択肢から採用する事が出来る。好ましい実施形態では、２色は、直ぐ前の２つの異なる色ピクセルから得られ、これらはピクセル製作コマンド、コピー上コマンド、コピー左コマンド、或いはコピー旧コマンドを用いて符号化されていて良い。ＭＳコマンドは、これら２つのピクセルがどのようにしてそこに来たのかを問わず、それらが、今度のＭＳコマンドのピクセル列の２色になることに関心を持つだけである。

上記２色の集合を有するＭＳコマンドは、色特定ビットを有するバイトを必要としないので、有利である。即ち、ＭＳコマンドは、どの色が使われることになるかを特定するビットを含んでおらず、ただ２つの前に特定された色のうちのどちらが列に用いられるか特定するだけである。従って、例えば、エンコーダが白い背景上の黒い文字"Ｈ"の上左隅などの、或るテキストの始まりに到達したとき、"Ｈ"の上左隅の第１ピクセルは１つの黒ＭＰ（ピクセル製作）コマンドで定義され、これに数個のピクセルについての１つのＣＬ（コピー左）コマンドが続く。このＨの上中央及び上右がエンコーダの前を見るで見出されると、エンコーダは、来るべき複数のピクセルにおける２つの色（テキスト及び背景）だけを検出しているので、列を作るコマンドを作る。

図９に示されているように、第１ＭＳコマンド・バイトは３ビットのオプコードを１つ有し、これに続いて、このコマンドが次のバイトまで拡張されることを示す１つの"拡張"ビット（ビット位置４）がある。この拡張ビットがゼロならば、ＭＳコマンドは拡張されず、第１バイト後に終了する。その場合には、そのバイトの中の４つの"Ｃ"ビットは４個のピクセルについての２色パターンを提供し、現在の列は終了する。しかし、拡張ビットがオンであれば、現在のＭＳデータの後に他の１つの完全なＭＳデータのバイトが続く。従って、図９において、第２バイトは１つの"拡張されたコマンド"バイトである。拡張ビットは前のバイトの中に存在するので、次のバイトは３ビットのオプコードを含んでいなくても良い。従って、拡張されたコマンドのアイデンティティーは、現在のバイト内のオプコードから生じるのではなくて、前のバイトの中の拡張ビットから生じたものである。その結果は、第１バイトに続く全てのバイトについての列作りデータのために７ビットを提供する。拡張されたコマンド・バイトは、次のバイトが拡張バイトであるかいなか特定する自分自身の拡張ビット（ビット位置７）を含む。この拡張は、Ｅビットがオンである間、続く事が出来る。Ｅビットがオフになると、現在の列は終了する。図１０の列は、８８個の連続するピクセルの１つの列を定める１つの１３バイトの長さのＭＳコマンドの例を示す。

デコーダは、複数の列作りバイトを受け取ると、直ちに、次のようにクライアント・スクリーンのためのピクセルを作り始める。オプコード０１１を読んだ後、デコーダは１つの列作りが始まることを理解する。それは、前のピクセルの色を読み取り、その色を"色０"と定義する。その後、それは、その前の最近の異なる色ピクセルを読み、その色を"色１"と定義する。

デコーダは、その後、その列が１バイトであるか或いは２バイト以上であるか判定するためにＥビットを読む。最後に、デコーダは、ビット０−３を順に読み、各ピクセルの２進ステータスに基づいて２つの利用可能な色から複数のピクセルを作る。第１バイトについては、デコーダは４個のピクセルを作る。例えば、もし第１ＭＳバイトが０１１１０１１０であって色０が黒で色１が白ならば、デコーダは黒、白、白、黒の４個のピクセル（０１１０）を作る。その後、Ｅビットが１にセットされているので、デコーダは次のバイトに注意して、もう７個の黒ピクセル及び白ピクセルを作る。

１つのＭＳコマンドの第１バイトは、好ましい実施形態では、４個（８ビット−３オプコード・ビット−１拡張ビット）のピクセルを作る。もし列中に４個未満のピクセルが存在する（即ち、３以上の色が次の４ピクセル中に存在する）とエンコーダが見出したならば、好ましい実施形態ではＭＳコマンドを使えない。更に、もしＭＳコマンドの第１拡張バイト（２番目の累積バイト）を使うことになるならば、エンコーダは、次の７個の連続するピクセルがＭＳステータスに適すること（即ち、全て２色の選択肢だけからのピクセルであってコピー・コマンドが適用されない）を見出すために前を見なければならない。図９に示されているように、第１バイト中の４個のＣビットは１１ピクセル列の始めの４個のピクセルを特定し、第２バイト中の７個のＣビットは該１１ピクセル列中の次の７個のピクセルを特定する。その後、新しいＭＳ拡張バイトは、７ピクセルの整数倍を列に付け加える事が出来るときに限って、使用される。従って、前述されたように、（１）始めの４ピクセルがＭＳ扱いに適するか否か判定し、（２）７ピクセルの追加のバイトが適するか否か判定するために、エンコーダはＭＳコマンド・バイトを符号化する前に"前を見る"。

今理解されるであろうように、ＭＳコマンドは、各ビットが色０或いは色１であるピクセルに対応するように、連続するビットを用いて連続するピクセルを定義する。事実上、複数のＭＳコマンドの複数のＣビットはピクセル列のようなものである。

前述のように、ＭＳモードにおいてはエンコーダは常に前を見て、次の拡張コマンド・バイトの次の７ビットを満たすのに充分なピクセルが来るべきピクセル列にあると分からなければＥビットをセットしない。もしエンコーダが前を見て、次の７ピクセルの中に２色の集合とは異なる色と遭遇したならば、エンコーダは列作りコマンドを現在のバイトで終了させる（ストップ・ビットを現在のバイトのＥビットに書き込む）。

一実施形態では、エンコーダは、そのときの複数のピクセルの全部について複数のコマンド・タイプの全てについて複数の比較を行う。その場合、その複数の比較は常に平行して行われ、常に複数の全てのコマンドについて行われる。該複数のコマンド・タイプのうちの１つが自分自身の適用の可能性を認めると、エンコーダは、そのことをフラグで知らせ、（他の複数の比較と該複数のコマンド間での複数の優先順位とに基づいて）現在の状況においてどのコマンド・タイプが最適であるかを判定する。例えば、図２の実施形態では、ビデオ・コンプレッサ２３は、全ての個々のピクセルについて、５つのコマンド・タイプの各々の適用の可能性を探し、複数のＭＳコマンド要件に従って前を見る。

写真は比較的多数のピクセル製作ＭＰコマンドを必要とするので、写真の最初の提示のときには上記の複数の実施形態は良好には働かない。１つの静止写真が一度送られるまでは、エンコーダは多数のコピー・コマンドを作らず、これは複数の良好な効率をもたらす。もちろん、静止写真が最初にクライアントに送られた後、エンコーダはその後の複数のフレームにおいてスクリーンのそれらの部分についてＣＯコマンドを作る。複数の本実施形態は、写真情報にはあまり適さないけれども、多数の垂直及び水平の線がコピー・コマンドに適することが良くあって複数のスクリーンが１つの相当の量のテキストを包含するコンピュータ・コンソール・スクリーンのアプリケーションでは極めて大きな効率を提供する。

本発明の、７ビット灰色優遇色モードと称される実施形態は、ピクセル製作（ＭＰ）コマンド対色及び灰色強度表の新しい独創的使用方法を提供する。このモードは、１つの１バイトＭＰコマンドの７ビット・ペイロードから最高の性能を引き出そうとするものである。図１１に示されているように、入って来る複数の色（赤、緑及び青）の各々の強度は０（最も暗い）から２５５（最も明るい）までにわたる。或る現存するコンピュータ・コンソール色深さ減少方式は全ての色を確定するために合計６ビット（２ビットが赤に、２ビットが青に、２ビットが緑に、提供される）を使用し、その結果として赤の４つの異なる濃淡と、青の４つの異なる濃淡と、緑の４つの異なる濃淡とをもたらす。４３の組み合わせは６４個の可能な色の組み合わせである。

灰色もコンピュータ・アプリケーションでは重要であって、Ｒ、Ｇ、及びＢが等強度で存在する各組み合わせから成る。上記の６ビット色方式は、デフォルトで、灰色の４つの可能な濃淡を提供する。Ｒ、Ｇ、及びＢの４つの濃淡は容認可能な色深度を提供するであろうけれども、灰色の限定されている数の濃淡はグレースケール深さについては不充分であることが分かる。

１つの実施例（限定する実施例ではないけれども）では、色の数を６４以上に増やすことができ、複数の色が増やされた以上の割合で灰色の濃淡の数も増やす。そうするために、任意のコンピュータ・コンソール・スクリーンのコレクション、１つの所定の色の選択などに基づいて全ての色（灰色を含む）について"使用の人気度（ｐｏｐｕｌａｒｉｔｙ ｏｆ ｕｓｅ）"が割り当てられ、そして、それから、度数分布表はどの色（及び灰色）がもっとも人気があるかを特定する。図１１において、２進法及び十進法の強度レベル（０から２５５まで）が複数の左コラムに示されており、それに"使用の人気"ランキングが続いている。そのコラムでは、線が長ければ長いほど、代表的コンピュータ・スクリーンのプールにおいてより多くその色が特定されている。図示されているように、ゼロ強度は良く使用され、６３及び６４は良く使用され、１２７及び１２８は良く使用され、１９１及び１９３は良く使用され、２５５は良く使用される。

本発明者は、複数の代表的なコンピュータ・スクリーンにおいて複数の灰色は灰色でない複数の色より人気があることを見出した。例えば、複数のスクロールバーは灰色であり、複数のツールバーは灰色であり、そして１つの"ボタン"が押されたときには複数のボタンの周囲の複数の縁が様々な濃淡の灰色に変更される。黒と白とは複数の濃淡の灰色であって、非常に良く使用される。コンピュータ・スクリーンは様々な濃淡の灰色を大量に使用し、様々な濃淡はコントラストのために重要である。ビデオ圧縮を目的として色の深度が減じられたとき、ビデオの質が被った第１の難点は複数の灰色にあった。判明した通りに、実際の複数の色はあまり重要ではなかった。例えば、赤い色がどの程度に赤いか、緑色がどの程度に緑であるかはあまり重要ではなかった。しかし、色深度減少方式で複数の灰色の深度が消えてしまうと、スクリーン上で"ボタンが押された"ときのような重要な複数のコントラストが失われた。

複数の色の人気を考察し、Ｒ、Ｇ、及びＢの各々について５つの濃淡を提供し、コード位置を見出してより多くの複数の灰色を付け加えることにより、本実施形態は、良好な色コントラストに必要とされる全ての色を提供し、同時に優れたグレースケール・コントラストを付け加える。始めに、一般の赤、緑、及び青の強度の集合が選択された。図１１の例では、赤、緑及び青の各々は最も一般の５つの強度、即ち０，６４，１２８，１９２及び２５５、のうちの１つで生じ得る。これらが、各色に提供される５つの異なる濃淡、即ち赤の５つの濃淡、緑の５つの濃淡、及び青の５つの濃淡となる。これら５つの濃淡を用いて利用し得る色の総数は、５３＝１２５である。この１２５色のうちには、自動的に５つの濃淡の灰色、即ち具体的には（１）Ｒ、Ｇ、及びＢがすべて０に等しい、（２）Ｒ、Ｇ、及びＢが全て６４に等しい等、がある。５つの濃淡は４より良いけれども、望ましい程度には良くない。

この理由から、ピクセル符号化の"隠れた"領域の中に付加的な複数の灰色を符号化する事が出来る。図４に示されているように、ＭＰコマンドは赤、緑及び青の強度を７ビットで定義する。１２８個の状態（２）をこれら７ビットで定義し得るけれども、上記の５濃淡人気色方式を用いると、１２５色だけが特定される。本例は、残りの３状態（１２８−１２５）を３つの付加的なグレースケールのために使用する。今、５つの濃淡の灰色（ＲＧＢ＝０，６４，１２８，１９２，及び２５５）の代わりに、３つの付加的な濃淡の灰色（ＲＧＢ＝９６，１６０及び２２４）が含まれている。これら８個の灰色が図１１の右端コラムに示されている。

図１２は、２４ビット色のためにセットされたコンピュータのビデオ・スクリーン上のテスト・パターン（０−２５５ＲＧＢ＋Ｇｒａｙテスト・パターンと称される）のカラー・プリントである。該テスト・パターンは、０（最も暗い）から２５５（最も明るい）まで増大する純粋な赤、純粋な緑及び純粋な青の水平なバーを有する。それは、ゼロから２５５まで増大する純粋な灰色（等量の赤、緑及び青）のバーも有する。図１３は、本発明の"７ビット灰色優遇色モード"が使用され、ソース・ビデオが図１２に示されているテスト・パターンであるときに得られたクライアント・スクリーンのカラー・プリントである。結局、７ビット灰色優遇色モードは、赤、緑及び青の最も一般の５つの濃淡を正確に表示し、当業者が７ビットから期待するより多い灰色のレベルを提供する。

従来技術の６ビット色方式と比べると、７ビット灰色優遇色モードは、２倍の多さの灰色（８対４）と共に良好な色の質を提供する。７ビット灰色優遇色モードは、高度の色の深度はあまり重要ではないコンピュータ技術に特別の用途を有し、また、ネットワーク管理技術にもっと特別の用途を有する。ネットワーク管理者は、該管理者に近くないサーバを頻繁に保守する。それでも、管理者は、複数のサーバにアクセスし、該サーバとリアルタイムで相互作用しなければならない。キーボード又はマウスの複数の入力の後にサーバからネットワーク管理者へビデオをなるべく迅速に入手することは重要である。また、その様な貧弱な色又は灰色の質でビデオを返したり或いは低速過ぎてキーボード及びマウスの入力に追いつけないような従来技術のビデオ方式は容認できない。７ビット灰色優遇色モードを有する本圧縮システムは、コンピュータ・インターフェースの機能的側面（ボタン、バー等）のために良好なビデオを必要とするネットワーク管理者のために優れた色の質とグレースケールの質とを提供する。

本発明の他の実施形態では、色の深度は、ソース・ビデオの内容及び／又はネットワーク帯域幅の入手可能性の関数として動的に増減される。ビデオ圧縮エンコーダは、ＭＰコマンドの長さが増減され、他の全てのコマンドが同じままであることをクライアントに知らせる。ＭＰコマンドは最低優先順位であって比較的希であるので、各ＭＰコマンドのための２以上の数のバイトへの拡張は、大抵のコンピュータ・スクリーンを用いることから作られるネットワーク・トラフィックを激増させない。写真等の見るイメージは、ＭＰコマンドの数を増やし、差を増大させる。複数のテストにより、ＭＰコマンドを１バイトから２バイトへ増大させても複数の典型的コンピュータ・スクリーンでのトラフィックを３０％しか増大させないことが示された。

本発明の他の実施形態では、ソース・ビデオが送信された前のフレームから変化していなければデータを送らないことによってネットワーク・トラフィックを最小にする事が出来る。この実施形態では、クライアント１１がコマンドを受け取らなければデフォルトによりクライアント・スクリーンは変更されないので、複数の変化が生じていないことをエンコーダ２６が知ったときには、複数のコマンドを送る必要はない。他の代わりの実施形態では、或る期間（例えば１分）後に、接続が依然として働いていてスクリーンが変化していないことをクライアント１１に分からせるためにサーバ・ソフトウェアは１つのメッセージをクライアントに送る。

図１及び２に記載されている実施形態では、ソース・ビデオはビデオ作製ソフトウェア及びビデオ・コントローラ・チップから得られ、これらは共にターゲット・サーバ１５に置かれている。他の実施例は、ソース・ビデオをビデオ作製ソフトウェア及びビデオ・コントローラ・チップから得るが、これらは共にビデオ・コンプレッサと統合されている。その様な"埋め込み"の完全に統合されたシステムが図１４に描かれている。

他の代わりの実施形態は、ビデオ作製ソフトウェアとインターフェースで直接接続するソフトウェアで完全にビデオを（上記のものと同じ複数のタイプの複数のビデオ・コマンドを用いて）圧縮し、ビデオ・コントローラ・チップを不要にする。その様な純粋なソフトウェア"無コントローラ"実施形態が図１５に描かれている。

前の複数の実施例では、コマンドデコーダはＰＣソフトウェアで実現された。１つの代わりの実施形態は、完全にハードウェアで、或いはハードウェアと小型低コスト低性能マイクロプロセッサとの組み合わせで、デコーダを実現する。この"埋め込み"デコーダは、図１６に示されているように、（１つのＰＣ或いはビデオ・コントローラ・チップ無しで）ビデオを１つのビデオ・ディスプレイに直接出力する。この"マイクロクライアント"は、キーボード及びマウス・インターフェース回路も含むことができ、また、ビデオ・ディスプレイに統合されても良い。マイクロクライアントは、複数の作業者のコンピュータの全てが主作業域外の１つのバック・ルームにあることが望ましいアプリケーションに応用し得るであろう。作業域では、キーボード、モニター及びマウスだけが机上に存在するであろう。一人の作業者は、１つの場所から他へ移動するとき、どのマイクロクライアントからでも自分のコンピュータ（又は、他の、該作業者がログオンすることを許されている任意のコンピュータ）にログオンする事が出来る。

本発明の他の側面例について図１７に関して説明する。同じクライアント・ソフトウェアを持っていてＩＰネットワークに接続されている第２のクライアント１６が付け加えられたならば（クライアント１１と同じ）、サーバ装置１４は、複数の同じビデオ圧縮コマンドを両方のクライアントに送ることができ、両方のクライアントがターゲット・サーバ１５へのアクセスを同時に"共有"することを可能にするであろう。普通、この"共有"モードでは、一方のクライアントがサーバ１５にアクセスしていて他方のクライアントはワッチしている。実例は、クライアント１１が１つのサーバを使用していて該クライアント・ユーザーがネットワーク管理者（これは他の場所にいる）の確認が所望される動作エラー状態にあるときに発生する。これは"ヘルプ・デスク"モードと称される。複数のそれぞれのクライアント・リモート・コンソール１７及び１８の所に座っている被訓練者のグループなどにビデオがマルチキャストされる場合に共有モードが極端に使用される。

インターネット経由の共有モードでは（特に多数の同時ユーザーがいる場合）、ＴＣＯ通信の代わりにＵＤＰ通信を使用するのが有利である。当業者が理解するであろうように、ＵＤＰは肯定応答されないデータグラムを使用し、ＴＣＰのデータグラムは肯定応答される。多数の同時共有モード・ユーザーとの肯定応答の集中はサーバ装置をあふれさせる可能性があろう。ＴＣＰの利点は、全てが送信され、且つ、肯定応答されるまでは再送されるので、失われるデータが無いことである。しかし、ビデオでは、ユーザーは、失われたものよりも連続的なビデオの流れの方を気にする。換言すれば、失われたフレームに起因してスクリーンがちらつくことは、ビデオが見逃されたフレームに戻ってやり直すことをユーザーが望むことを意味しない。本発明は、ＴＣＰ、ＵＤＰ、又はその他の肯定応答されたり肯定応答されなかったりする任意のプロトコルで使用され得るものである。

本出願人は、インターネット上で悪意を持って行われる複数のサービス・アタックの拒絶の原因になり得ることが複数のＵＤＰプロトコルの１つの欠点であることに注目している。ＵＤＰは肯定応答されないので、トラフィックが１つのサーバをＵＤＰデータグラムであふれさせる可能性がある。それを防ぐために、複数のファイアウォールがＵＤＰの進行を妨げることが良くある。ＵＤＰを使用する実施例で本発明を使用することはＵＤＰデータグラムの受領を必要とするけれども、多数の共有モード・ユーザーのための複数のトレーニング・ルーム環境及びその他のアプリケーションは通常はファイアウォールの背後の設備の中にあるであろう。

更に他の実施形態では、送信される圧縮されたコンピュータ・スクリーンが監視を受けないようにデータ暗号方式が複数のビデオ圧縮コマンドに適用される。どのような暗号方式技術を使用しても良いのであるが、ビデオ圧縮符号化と共に同じビデオ・コンプレッサ２３で実行され得るＡＥＳ暗号方式等の１つの暗号方式技術は１つの実行の見地からは独立のデータ暗号化装置よりも遥かに望ましいであろう。

本発明者は、７ビット灰色優遇色方式と結合された上記の複数のコマンド構造の組み合わせを好ましい実施形態として提示したが、その理由は、この組み合わせが、ＫＶＭスタイルのサーバ管理環境で作業するコンピュータ管理者に良く適する複数の兼ね合いの１つの最適化だったことにある。複数のコマンド・オプコードを変更して色彩の配合を変化させれば、ネットワーク帯域幅要件を減少させ或いは他の複数の環境のために色の深度を増加させる事が出来る。

例えば、図１８に示されている５ビット灰色優遇色モードを実行するために色の５ビットだけが使用されるならば、図１９に示されているようにＭＳコマンドとＭＰコマンドとの間でオプコードを交換するのが有利であろうが、その理由は、単ビット・オプコードは５個のＰビットを有するだけの１つのＭＰコマンドでは"無駄にされる"ことにある。この実施形態では、ＭＳコマンドの効率を高めるために単ビット・オプコードを使用する方が良いであろう。図２０及び２１に示されているように、後続の複数のＭＳコマンドを単に送ることによってＭＳコマンドを拡張する事が出来るので、それはＭＳコマンドの拡張ビット（Ｅビット）を不要にするであろう。複数のコマンド構造と５ビット色とのこの代わりの組み合わせは、より低い色の深度を提供するけれども相当の量のテキストを有するスクリーンでは改良された性能を提供するが（より効率の良いＭＳコマンドの故に）、上記の７ビット色モードと同じ数の灰色（８）を提供する。より大きな色の深度を必要とする複数のアプリケーションのために最適化された他の実施形態は、図１９に示されているオプコードの同じ代替構成を使用するけれども、ＭＰコマンドは図２２，２３及び２４に示されているように１バイト又は２バイトの長さである。それは、２バイトの長さであるときには、図２３に示されているように１２ビットの色（４赤、４緑及び４青）を提供する。それは、１バイトの長さであるときには、図２４に示されているように灰色（赤、緑及び青が全て等しい）の１６個の濃淡を定義する４ビットのペイロードを提供する。図２２の"Ａ"ビット（又は"全"ビット）は、３色全部が"Ｐ"ビットの値に等しくて該コマンドが１バイトに限定されることを示す。実際上、複数の１バイト灰色コマンドから生じるネットワーク・トラフィックはより少ないので、可変長ＭＰコマンドは灰色優遇である。他の実施形態では、１バイトＭＰコマンドの４ビットのペイロードは、１６個の灰色の代わりに１６個の最も一般の色を表わす。その１６個の最も一般の色は、複数のＭＰコマンドでの最近の使用統計により、或いは１６個の一般の色の前もって決められたリストによって決定されて良い。また、上記の５ビット色モードでのより効率的なＭＳコマンドの複数の同じ利点がこの１２ビット色モードに含まれる。本明細書に記載された５ビット及び１２ビットの色モードは良く似ているので、ソース・ビデオ・コンテンツ及び／又は利用可能なネットワーク帯域幅に応じて動的に５ビット色と１２ビット色との間で切り換えられる１つの実施形態が可能である。５ビット及び１２ビットの色モードに適合するように示されているものと類似する複数のコマンドの他の再構成も、他の複数のアプリケーション或いは他の複数の環境において性能を高めるために有益であろう。

最も実用的で好ましい実施形態であると現在考えられるものと関連させて本発明を説明したけれども、本発明は開示された実施形態に限定されなくて、添付されている請求項の範囲内に含まれる種々の変更及び同等構成を含むように意図されていることが理解されるべきである。

クライアントがＰＣソフトウェアで実現されている１つのＫＶＭ／ＩＰシステムにおける本発明の１つの実施例の１つの構成図である。 １つのハードウェア・ビデオ・コンプレッサの内部動作を示す本発明の１つの実施例の１つの構成図である。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 複数の８ビット・パケット長さを有する本発明の１つの実施例における複数のビデオ圧縮コマンドの複数のテーブルである。 本発明の"７ビット灰色優遇色モード"実施形態において色深度がどのように低減されるかを記述した１つの図表である。 ２４ビット・カラー向けにセットされた１つのコンピュータのビデオ・スクリーン上のテスト・パターン（０−２５５ＲＧＢ＋グレイ・テストパターンと称される）の１つのカラー・プリントである。 本発明の"７ビット灰色優遇色モード"実施形態が使用され、ソース・ビデオが図１２に示されているテスト・パターンであるときの１つのクライアント・コンピュータ・スクリーンのカラー・プリントである。 ビデオ作製ソフトウェアと、ビデオ・コンプレッサと統合されたビデオ・コントローラ・チップとを有する本発明の１つの実施例の１つの構成図である。 ビデオ・コントローラ・チップを持たず、ソフトウェア・ビデオ圧縮を有する本発明の１つの実施例の１つの構成図である。 １つのマイクロクライアントと称される本発明の１つの実施例の１つの構成図である。 "シェア・モード"のコンセプトを記述する本発明の１つの実施例の１つの構成図である。 本発明の"５ビット灰色優遇色モード"実施形態において色深度がどのように低減されるかを記述する１つの図表である。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。 ５ビット及び１２ビットの複数の色モードで使用される本発明の１つの代替実施形態における複数のビデオ圧縮コマンドの複数のテーブルである。

Claims (7)

1. ビデオ情報を符号化する方法であって、
   前記ビデオ情報における赤、緑、及び青色の成分の強度のうちの、所定数の強度を選択するステップと、
   前記選択された所定数の強度において赤、緑、及び青が等強度である組み合わせで作られる所定数の灰色値以外の付加的な複数の灰色値を決定するステップと、
   前記ビデオ情報の各ピクセルの色を、前記所定数の灰色、前記選択された所定数の強度における赤、緑、及び青の成分の組合せから利用し得る前記所定数の灰色以外の色、及び前記付加的な複数の灰色に変換するステップと
   を備える方法。
2. 前記所定数の強度を選択するステップは、前記ビデオ情報における色の強度のうち、より多く使用される所定数の強度を選択する
   請求項１に記載の方法。
3. 前記所定数の強度を選択するステップは、合計２７個の可能な色の組み合わせのために、赤、緑及び青の成分について３つの強度を選択し、
   前記付加的な複数の灰色値を決定するステップは、前記選択された３つの強度において赤、緑、及び青が等強度である場合に作られる３つの灰色値以外の付加的な５個の灰色値を決定し、
   前記符号化するステップは、５ワードを残して３２ワードを該２７個の可能な色の組み合わせと相関させ、該残りの５ワードを前記付加的な５個の灰色値と相関させることによって、５ビットを有する色パケットを生成する
   請求項１に記載の方法。
4. ５ビットより多いビットを有する色パケットを提供するステップと、
   複数の低色解像度のための５ビット・パケットと、高色解像度のための５ビットより多いビットのパケットとのいずれかを動的に選択するステップと
   を更に含む、請求項３に記載の方法。
5. 前記所定数の強度を選択するステップは、前記強度の使用の人気度に基づいて前記所定数の強度を選択する
   請求項１に記載の方法。
6. 灰色を含む全ての色についての前記使用の人気度は、任意のコンピュータ・コンソール・スクリーンのコレクションに基づいて割り当てられる
   請求項５に記載の方法。
7. 前記所定数の強度を選択するステップは、合計１２５個の可能な色の組み合わせのために、赤、緑及び青の成分について５つの強度を選択し、
   前記付加的な複数の灰色値を決定するステップは、前記選択された５つの強度において赤、緑、及び青が等強度である場合に作られる５つの灰色値以外の付加的な３個の灰色値を決定し、
   前記符号化するステップは、３ワードを残して１２８ワードを該１２５個の可能な色の組み合わせと相関させ、該残りの３ワードを前記付加的な３個の灰色値と相関させることによって、７ビットを有する色パケットを生成する
   請求項１に記載の方法。

Images