JP5495564B2 - ホームネットワークｇｕｉ応答時間とプレゼンテーションとを改良するためのシステムと方法 - Google Patents

Description

本発明は、広くホームネットワークに関する。

ホームネットワークは、ますます大きな規模で使用されるようになっている。ホームネットワークのユーザは、例えばＴＶリモート制御装置のような入力装置を使用して、ネットワークを介してクライアント装置からリモートサーバを制御する。ＤＶＤプレーヤやパーソナルビデオ制御装置等のような他のクライアント装置はまた典型的にネットワークの部分であり、このようにサーバは、単純なリモート制御装置によって全部の装置の中央制御（ｃｅｎｔｒａｌ ｃｏｎｔｒｏｌ）を可能にする。

ここで理解されるように、例えばユーザがコマンドを入力することに使用されるクライアントＴＶで、サーバが表示するグラフィックユーザインターフェース（ｇｒａｐｈｉｃ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：ＧＵＩ）は容易にリモートで使用されないものである。より具体的には、ＧＵＩは通常、メニュー（ｍｅｎｕ）、終了（ｅｘｉｔ）、戻る（ｂａｃｋ）等のような静止テキストデータを表示するが、決して最適ではないビデオ符号化、すなわち動画品質を最適化するために使用されるビデオ符号化を使用して表示される。本発明によって理解されるように、このビデオ符号化レートは、テキストデータをもつ静止画について非効率的であり、ＧＵＩテキストデータがしばしば不明確に表示されるという結果を生む。

ここでまた認識されるように、多くのサーバベースのホームネットワークシステムの、リモートコマンドへの応答は遅く、ときには１秒を超える。これは、他のデータ、例えばオーディオ／ビデオデータによって占有されたタイムスロットにリモートコマンドが押し込められるからであり、ゆえに、クライアント装置からサーバへのコマンドの送信は、非コマンドデータの送信が達成される顕著で不都合な期間によって遅らされる場合がある。

ネットワーク内のビデオディスプレイにグラフィカルユーザインターフェース（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：ＧＵＩ）を表示するための方法が開示される。そのネットワークは、サーバと通信するクライアント装置を含み、そのクライアント装置は、ユーザ入力装置から入力を受信する。ビデオディスプレイにムービングビデオ（ｍｏｖｉｎｇ ｖｉｄｅｏ）を表示するための第１のビデオ符号化を使用することと、ビデオディスプレイにＧＵＩを表示するための、第１の符号化とは異なる第２のビデオ符号化を使用することとを、この方法は含む。

非限定的な実施形態において、クライアント装置はＴＶであり、ユーザ入力装置はＴＶと通信するワイヤレスリモート制御装置であり、ビデオディスプレイはＴＶによって構築され、リモート制御装置からの信号はＴＶによって受信され、サーバに送信される。

いくつかの実施形態において、第１のビデオ符号化は、ピクチャのグループ（ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ：ＧＯＰ）を決定するＭＰＥＧ符号化であることが可能である。第１の符号化での各ＧＯＰは、１個のイントラフレーム（ｉｎｔｒａ‐ｆｒａｍｅ：Ｉ‐ｆｒａｍｅ：Ｉフレーム）と、複数の予測フレーム（ｐｒｅｄｉｃｔｉｖｅ ｆｒａｍｅ：Ｐ‐ｆｒａｍｅ：Ｐフレーム）と、複数の双方向予測フレーム（ｂｉ‐ｄｉｒｅｃｔｉｏｎａｌｌｙ ｐｒｅｄｉｃｔｉｖｅ ｆｒａｍｅ：Ｂ‐ｆｒａｍｅ：Ｂフレーム）とを含み、それらはおそらくは以下の順、すなわちＩ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂである。対照的に、非限定的な実施形態において、第１の符号化のＧＯＰより多くの数のフレームをもつ、及び／または第１の符号化よりもＩフレーム内に大きなデータ量をもつピクチャのグループ（ＧＯＰ）を、第２の符号化は決定可能である。例えば、第２の符号化のＧＯＰは、実質的に第１の符号化のＧＯＰの２倍の数のＩフレームを含むことが可能であり、第２の符号化のＧＯＰ内の各Ｉフレームは、実質的に、第１の符号化のＧＯＰ内のＩフレームで運ばれる２倍のデータ量を運ぶことができる。第２の符号化のＧＯＰは、Ｉフレームと複数のＰフレームとのみをもち、Ｂフレームをもたないということが可能である。例えば、第２のＧＯＰは３０個のフレーム、すなわち１個のＩフレームと２９個のＰフレームとを含むことができる。

別の側面においては、ユーザ入力装置から受信されるコマンドに応じてサーバによって制御されるクライアントオーディオ／ビデオ装置をもつシステムにおいて比較的早いコマンド応答時間を容易にする方法は、複数の送信サイクルを確立することを含む。各サイクルは、無競合期間（ｃｏｎｔｅｎｔｉｏｎ‐ｆｒｅｅ ｐｅｒｉｏｄ：ＣＦＰ）と競合期間（ｃｏｎｔｅｎｔｉｏｎ ｐｅｒｉｏｄ：ＣＰ）とを含む。オーディオ／ビデオストリームはＣＦＰでサーバからクライアント装置に送信され、ＣＦＰの時間割り当てはストリームのために獲得されて、ストリームが終了するまで毎サイクル予約される。ユーザ入力装置由来のコマンドの、サーバとクライアント間の送信専用に、少なくとも１つのタイムスロットが各サイクルのＣＦＰにおいて予約される。

この第２の側面の非限定的な実施形態においては、タイムスロットは毎秒数キロバイト以下の帯域幅をもつ。タイムスロットとストリームとは時間軸上で連続であることを強制されない。必要に応じて、タイムスロットは、ストリーム送信が終了するまでコマンドのために予約されることが可能である。

リモートコマンドはそのタイムスロットにおいてクライアント装置からサーバに送信されることが可能である。また、そのタイムスロットは、サーバとクライアント装置間で情報を交換することに、双方向に使用されることが可能である。例えば、ＣＦＰ内の第１のタイムスロットの部分は、サーバからクライアント装置へのメッセージのために予約されることが可能であり、ＣＦＰ内の第２のタイムスロットの部分は、クライアント装置からサーバへのメッセージのために予約されることが可能である。

もしＣＦＰが実質的に占有されるならば、ユーザ入力装置によって生成される最初のコマンドをＣＰ間にクライアント装置からサーバへ送信することを、この方法は含むことができる。この場合、最初のコマンドを受信することに応じて、ＣＦＰにおいてタイムスロットを後に続くコマンドのために予約することを、この方法は含むことができる。それから、もし既定の期間にコマンドが１つも受信されなければ、そのタイムスロットは解放されることが可能であり、ＣＰ間に送信される次のコマンドが最初のコマンドとして扱われることが可能である。

非限定的な実施形態において、もしコマンドがクライアント装置またはサーバで割り込みを引き起こすならば、その割り込みには最高の優先権が与えられる。サイクルはＡＣ線サイクルに同期されたビーコンサイクルとしても良く、ＣＰは、後に続くサイクルのために同じ時間割り当てが予約されるという保証なしの１回アクセス期間であることが可能である。

別の側面においては、サーバからのオーディオ／ビデオストリームを表示するよう構成されるクライアント装置とユーザ入力装置とを含むシステムのためのサーバは、第１のビデオ符号化を使用して、グラフィカルユーザインターフェース（ＧＵＩ）信号をクライアント装置に送信する。サーバはまた、第１のビデオ符号化とは異なる第２のビデオ符号化を使用して、ビデオストリーム信号をクライアント装置に送信する。

なお別の側面においては、サーバはシステムのために開示される。サーバからのオーディオ／ビデオストリームを表示するよう構成されるクライアント装置とユーザ入力装置とを、システムはもち、ユーザ入力装置由来のグラフィカルユーザインターフェース（ＧＵＩ）コマンドの、サーバとクライアント装置間の送信のために、少なくとも２つの連続的なビーコンサイクルの無競合期間（ＣＦＰ）において少なくとも１つのタイムスロットを、サーバは予約する。各ビーコンサイクルはまたそれぞれの競合期間（ＣＰ）をもつ。

なお別の側面においては、システムはサーバと、クライアント装置での表示のためのオーディオ／ビデオストリームをサーバから受信するクライアント装置と、クライアント装置にコマンドを入力するためにクライアント装置と通信するユーザ入力装置とをもつ。そのコマンドはクライアント装置からサーバに送信される。クライアント装置での表示のために第１の符号化を使用してビデオストリーム信号が符号化される手段が提供され、また、クライアント装置でのＧＵＩの表示のために第１の符号化とは異なる第２の符号化を使用してグラフィカルユーザインターフェース（ＧＵＩ）が符号化される手段が提供される。さらに、競合期間（ＣＰ）をも有する送信サイクルの無競合期間（ＣＦＰ）において少なくとも１つのタイムスロットを予約するための手段を、システムは含み、そのタイムスロットは、ユーザ入力装置由来のコマンドの、クライアント装置からサーバへの送信のために予約される。

最初に図１を参照すると、ネットワーク装置をもつ電力線ネットワークとして実施される非限定的なホームネットワークが示されており、そのネットワークはイーサネット（Ｅｔｈｅｒｎｅｔ）、または８０２．１１ワイヤレスネットワーク、または何か他のネットワークであることが可能であると理解される。サーバ２は、ケーブル１０から信号を、またはモデム９からインターネットデータを受信可能である。例えば、モデム９は、ケーブルモードまたはＡＤＳＬ電話回線モデムであることが可能である。さらに、電力線１を通して、または上で言及されるように別の種類のネットワークバックボーンを通して、サーバ２はクライアントＴＶ１４にオーディオ／ビデオストリームを送信する。それに応じて、クライアントＴＶ１４はストリームを復号し、復号されたビデオをスクリーンに表示する。加えて、再生（ｐｌａｙ）、停止（ｓｔｏｐ）、早送り（ｆａｓｔ ｆｏｒｗａｒｄ）、早戻し（ｆａｓｔ ｒｅｖｅｒｓｅ）、チャネル上／下（ｃｈａｎｎｅｌ ｕｐ／ｄｏｗｎ）、音量上／下（ｖｏｌｕｍｅ ｕｐ／ｄｏｗｎ）等のようなリモートコマンダ１２からのコマンドを、クライアントＴＶ１４は受信可能である。コマンドによっては、いくつかのコマンドはサーバ２に転送されるであろう。どんな場合においても、ＤＶＤプレーヤ、ＰＶＲ等のような追加のクライアント装置はまたそのネットワークの部分になることが可能である。

図２は、サーバ２の非限定的な実施形態のブロック図を示す。アナログケーブル信号はチューナ／フロントエンド（ＦＥ）３０９において同調され、復調される。チューナ／フロントエンドからのビデオ出力はアナログ‐デジタルコンバータ（ａｎａｌｏｇ ｔｏ ｄｉｇｉｔａｌ ｃｏｎｖｅｒｔｅｒ：Ａ／Ｄ）３１０においてアナログ‐デジタル変換され、スイッチ（ＳＷ）３１４に送信される。例えば、Ａ／Ｄ３１０の出力はＩＴＵ‐Ｒ ＢＴ．６５６フォーマット４であることが可能である。同様に、チューナ／フロントエンド３０９からのオーディオ出力はＡ／Ｄ３１１においてアナログ‐デジタル変換されることが可能であり、スイッチ３１４に送信される。同じ方法において、ＤＶＤプレーヤのようなソースからの外部アナログオーディオ／ビデオ信号は、Ａ／Ｄ３１２と３１３とにおいてアナログ‐デジタル変換され、スイッチ３１４に送信される。

図２に示されるように、スイッチ３１４の出力は、ミキサ３１５にて、グラフィックエンジン３１６によって生成されるグラフィック（ＧＵＩ）データと混合される。その結果はＭＰＥＧエンコーダ３１７においてＭＰＥＧ符号化される。

ここで理解されるように、外部アナログビデオ入力はすでにＧＵＩを含むことができる。例えば、ＤＶＤプレーヤはサーバ２にメニュースクリーンを出力可能である。この場合、ＧＵＩは１つも追加される必要がなく、混合は１つもミキサ３１５によって行われる必要がない。それどころか、デジタル信号はＭＰＥＧエンコーダ３１７へ直接進行する。

ここで熟慮されるように、ＭＰＥＧエンコーダ３１７は着信ストリームを固定レートまたは可変レートで符号化する。可変レートモードにおいては、符号化レートは送信条件に合うように調節される。ノイズが増加し、結果として実効帯域幅が低減されるとき、符号化レートは低減される。もしネットワーク条件が改善されると、符号化レートはもとの（より高い）レートに戻されることが可能である。

なお図２を参照すると、ストリームルータ３１８は着信ストリームを適切な方向へ送る。図２に示されるパスの１つをとると、ＭＰＥＧエンコーダ出力は、ネットワーク送信のための電力線通信（ｐｏｗｅｒ ｌｉｎｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ：ＰＬＣ）（または他のネットワーク）インターフェース（Ｉ／Ｆ）３１９へ送信されることが可能である。または、ストリームは、ハードディスクドライブ（ＨＤＤ）３２１に記録するためのＨＤＤインターフェース３２０へ送信されることが可能である。ストリームルータ３１８はまた、ＨＤＤインターフェース３２０からプレイバックストリームを受信可能であり、それをＰＬＣインターフェース３１９へ送信できる。

図２に示されるように、サーバ２は、内部バス３００を通して全部のサーバコンポーネントを制御する中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）３０２をもつ。ＣＰＵ３０２は、メモリ（Ｍｅｍ）３０１に記憶される制御ソフトウェアプログラムを実行する。また、キーパッド３０４は、バス３００を通してＣＰＵ３０２へユーザ入力データを送信するよう提供されることが可能である。液晶ディスプレイ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：ＬＣＤ）または他の種類の視覚ディスプレイ３０３は、ＣＰＵ３０２から送信されるデータ（例えば同調状態、ネットワーク状態、エラーメッセージ等）を表示する。図１に示されるモデム９は、サーバ２内のイーサネットポート３０６に接続されることが可能であるので、モデム９からのデータはイーサネットインターフェース３０５を通してＣＰＵ３０２に送信され、処理されることが可能である。必要に応じて、ＣＰＵ３０２は、赤外線（ｉｎｆｒａｒｅｄ：ＩＲ）コマンドを、ＩＲインターフェース３０７を通してＩＲマウス３０８に送信可能であり、そのＩＲマウス３０８はＤＶＤプレーヤのような外部ソースにＩＲコマンドを発する。

ここで、クライアントＴＶ１４として実施される非限定的なクライアント装置のブロック図を示す図３を見ると、クライアント装置のＰＬＣインターフェース１０８は、電力線１を通して送信された信号を受信できる。いくつかの実施形態において、ＰＬＣインターフェース１０８からの出力信号はデマルチプレクサ（ＤｅＭｕｘ）１０９において逆多重化され、オーディオデコーダ１１０とビデオデコーダ１１４とにそれぞれ送信される。ミキサ１１６において、ビデオデコーダ１１４からの復号されたビデオ信号は、グラフィックスエンジン１１９において生成されたグラフィックスデータと混合され、ビデオデジタル‐アナログコンバータ（Ｄ／Ａ）１１７においてデジタル‐アナログ変換される。ＧＵＩデータがサーバ２から送信されるとき、グラフィックスエンジンは使用される必要がなく、着信データはビデオＤ／Ａ１１７へ直接送信される。どちらの場合においても、クライアント装置のＴＶの実施形態においては、Ｄ／Ａ１１７の出力はディスプレイドライバ１１８に送信され、ビデオディスプレイ１２０に表示される。

オーディオ側においては、オーディオデコーダ１１０からの復号されたオーディオ信号は、オーディオＤ／Ａ１１１においてデジタル‐アナログ変換され、増幅器（Ａｍｐ）１１２において増幅され、スピーカ１１３に送信される。オーディオＤ／Ａ１１１と増幅器１１２とスピーカ１１３とは、非限定的な実施形態において、２つのオーディオチャネル、すなわち左と右とを取り扱う。

示される非限定的なクライアント装置において、クライアント装置ＣＰＵ１０２は、電力線１を通してサーバ２内のＣＰＵ３０２と非同期データ（コマンド、データ等）を交換できる。クライアントＣＰＵ１０２は、内部バス１００を通して全部のクライアント装置コンポーネントを制御する。クライアントＣＰＵ１０２は、メモリ１０１に記憶される制御ソフトウェアプログラムをバス１００上で実行可能であり、バス１００上のＩＲインターフェース１０３は、図１に示されるリモートコマンダ１２からコマンドを受信できる。そのコマンドはクライアントバス１００を通してクライアントＣＰＵ１０２に送信され、必要に応じて、サーバ２内のＣＰＵ３０２に電力線１を通して転送される。

サーバとクライアント装置との非限定的な実施形態を記述してきたが、ここで、本発明の差分符号化の側面を理解するために、図４‐ａと４‐ｂとに注目する。ＭＰＥＧビデオフォーマットにおいて、１つのピクチャのグループ（ＧＯＰ）は、１つのイントラフレーム（Ｉフレーム）と、いくつかの予測フレーム（Ｐフレーム）と双方向予測フレーム（Ｂフレーム）とからなる。（一時的な長さで約２分の１秒である）典型的なＧＯＰは、１５個のフレームをもち、そのフレームは１個のＩフレームと、４個のＰフレームと、１０個のＢフレームとであり、典型的にＩ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂ、Ｐ、Ｂ、Ｂの順である（図４‐ａ）。

ここで理解されるように、それは一般的に、ＧＵＩデータが小さい動きをもつ場合である。それどころか、ほとんどの場合のＧＵＩデータは、ユーザがリモートボタンを押すまで静止ピクチャである。それにより、ＧＵＩが表示されるとき、本原理に従って、サーバ２内のＭＰＥＧエンコーダ３１７はＧＵＩデータを符号化し、その符号化は「普通の（ｎｏｒｍａｌ）」ビデオ符号化とは異なり、例えばＧＯＰの長さを長く、例えば上で記述される「普通の」ＧＯＰの長さの２倍の長さ（３０個のフレーム）にすることによる。また、「普通に」符号化されたビデオストリームのＩフレーム内のデータと比べて、２倍の量のデータが各ＧＵＩ ＧＯＰ Ｉフレームに割り当てられることが可能である。これらの状況下の全データレートは同じままであるが、より高いレートをＩフレームに適用することによって、ＧＵＩピクチャ品質は改良される。

加えて、ＧＵＩ ＧＯＰを符号化するとき、Ｂフレームは１つも使用される必要がない。これは、ここで認識されるように、Ｂフレームがクライアント装置のＭＰＥＧデコーダ１１４においてフレーム並べ替えを必要とするからであるが、それは１つまたはそれ以上のフレームの遅延を引き起こす。動画を符号化するとき、Ｂフレームは、送信されなければならないデータの量を減少させるが、ＧＵＩイメージのような静止ピクチャにおいて、ＢフレームのデータサイズはＰフレームのものとほぼ同じである。

それにより、上の認識を念頭におくと、１つのＧＵＩ ＧＯＰは、例えば３０個のフレーム、すなわち図４‐ｂに示されるように１個のＩフレーム及び２９個のＰフレームとして符号化されることが可能である。ユーザがＧＵＩモードを選択するとき、この符号化モードが適用される。ＧＵＩモードが終わり、システムが普通のムービングビデオ再生モードに戻るとき、元の（「普通の」）符号化、例えば図４‐ａに示されるパターンが復帰する。この符号化スイッチは、ビデオの停止または一時停止（ｂｒｅａｋ）なしのオンザフライで行われることが可能である。

ＧＵＩイメージ表示を改良するための差分符号化を記述してきたが、ここで、コマンド応答を加速するために使用されることが可能であるネットワークアクセスタイミングを示すための図５に注目する。サーバ２または他の装置は、ビーコン９００を周期的に放送する。ビーコンサイクルはＡＣ線サイクル（５０Ｈｚまたは６０Ｈｚ）に同期できる。典型的なビーコンサイクルは、以下でさらに決められるように、無競合期間（ＣＦＰ）と競合期間（ＣＰ）とからなる。オーディオ／ビデオストリームは等時性であり、それはＣＦＰを使用する。ひとたび時間割り当てがストリームのために獲得されると、その時間割り当ては、ストリームが終了するまで、毎ビーコンサイクル予約される（９０１ａと９０１ｂとにおいて示される）。

他方において、ＣＰは例えばキャリア感知多重アクセス（ｃａｒｒｉｅｒ ｓｅｎｓｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ：ＣＳＭＡ）のために使用される。ＣＰの使用は、早い者勝ちであり、１回のアクセスである。そのため、たとえひとたび時間割り当て（９０２）が現ビーコンサイクルにおいて獲得されたとしても、後に続くビーコンサイクルにおいて何か特定の処理のために同じ時間割り当てが予約されるという保証はない。

この理解を念頭におくと、もし完全に占有されるならば、他のメッセージとの衝突を引き起こし、１つまたはそれ以上のビーコンサイクルのコマンド実行遅延という結果を生むＣＰにおいて、前述のリモートコマンドが送信されてしまうことを本発明は認識する。言い換えると、これらの遅延は遅いコマンド応答という結果を生む。この問題を解決するために、本発明はコマンド送信にＣＦＰを使用する。サーバ２がＡＶストリーム（９０１）の送信を開始するとき、コマンドのためのタイムスロット（９０３）はＣＦＰにおいて予約される。そのタイムスロットは、例えば毎秒１または数キロバイトの、非常に狭い帯域幅をもつことが可能であり、それはリモートコマンドを送信するのに十分である。タイムスロット９０３とストリーム９０１とは、時間軸上で連続的な順番である必要はない。コマンドのためのタイムスロットは好ましくは、ストリーム送信が終了するまで、リモートコマンドのために独占的に予約される。

どんな場合においても、クライアントＴＶ１４は、このタイムスロット間にリモートコマンダ１２から受信されたリモートコマンドをサーバ２に送信できる。さらに、サーバ２とクライアントＴＶ１４間で情報を交換するために、ＣＦＰタイムスロットは双方向に使用されることが可能である。例えば、送信機が受信機からの肯定確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を期待するＴＣＰ／ＩＰが適用されることが可能である。代替的に、異なるタイムスロットは、着信メッセージと発信メッセージとの各々のために予約されることが可能である。たとえサーバ２とクライアントＴＶ１４間でコマンドが１つも送信されないときでも、ＣＦＰタイムスロットは予約されることが可能である。

他方においては、もしＣＦＰが全容量またはそれに近い容量まで満たされているならば、サーバ２はできる限り大きな帯域幅を保つことを望むことが可能であり、それにより以下の方法を適用することが可能である。第１のコマンドはＣＰ間に送信される（ＣＳＭＡ）。それに応じて、ＣＦＰタイムスロットはＣＦＰにおいて後に続くコマンドのために予約される。（たいてい、チャネルや音量レベル等を変えるために、ユーザがリモートボタンを連続して数回押す。）後に続くコマンドは全部、ＣＦＰ（９０３）を使用して送信される。もしある時間、例えば３０秒間、ユーザがボタンを１つも押さなければ、そのＣＦＰタイムスロット９０３は別の送信のために解放されることが可能である。このように、ユーザがリモートコマンダを使用するときにのみ、ＣＦＰスロットは予約される。

好ましくは、リモートコマンドはサーバ２とクライアントＴＶ１４とにおいてすぐに処理されるであろう。もしコマンドがクライアントまたはサーバＣＰＵ（１０２または３０２）への割り込みを引き起こすならば、最高の優先権がその割り込みに与えられるであろう。

ＭＰＥＧ符号化が想定されているが、例えばＨ．２６４／ＭＰＥＧ４ ＡＶＣが適用されるような他のＡＶコーデック技術に、ここで提言されるこの原理は適用されることが可能であるということが理解されるであろう。

本発明によって提供される利点は以下のことを含むということが、ここで認識できる。ＧＵＩが表示中であるとき、応答とＧＵＩピクチャ品質とを改良するために、異なる符号化パターンが適用される。また、リモートコマンドは、無競合期間内のタイムスロットにおいて行き先に送信されるため、重大な送信遅延は１つもおこらない。そして、この発明は必要に応じてソフトウェアの変更のみで実施されることが可能であるので、特別なハードウェアは１つも必要ではない。

ホームネットワークＧＵＩ応答時間とプレゼンテーションとを改良するための、特定のシステムと方法とがここに示され、詳細に記述されるが、本発明によって含まれる主題は、特許請求の範囲によってのみ限定されるということが理解されることであろう。

本発明の機構と作動との両方についての詳細は、類似の参照数字が類似の部分を参照する、以下のような添付の図面を参照して、最も良く理解されることが可能である。
電力線ネットワークとして実施される非限定的なホームネットワークの図である。 非限定的なネットワークサーバのブロック図である。 ネットワーク上のＴＶとして実施される非限定的なクライアント装置のブロック図である。 普通のビデオのためのピクチャのグループ（ＧＯＰ）内のフレームの図である。 本原理に従ったＧＵＩプレゼンテーションのための非限定的なピクチャのグループ（ＧＯＰ）内のフレームの図である。 本原理に従ってＧＵＩ応答を促進するための、信号送信の非限定的なシーケンスを示す、タイミング図である。

Claims (7)

1. サーバ（２）からのオーディオ／ビデオストリームを表示するよう構成される少なくとも１つのクライアント装置（１４）と、少なくとも１つのユーザ入力装置（１２）とを含むシステムのための、前記サーバ（２）であって、
   第２のビデオ符号化を使用して、前記クライアント装置（１４）にグラフィカルユーザインターフェース（ＧＵＩ）信号を送信し、
   前記第２のビデオ符号化と異なる第１のビデオ符号化を使用して、前記クライアント装置（１４）にビデオストリーム信号を送信し、
   前記第１のビデオ符号化と前記第２のビデオ符号化とをスイッチし、
   前記ＧＵＩを符号化するために用いられる前記第２のビデオ符号化におけるピクチャのグループ（ＧＯＰ）は、イントラフレーム（Ｉフレーム）及び予測フレーム（Ｐフレーム）からなり、さらに、当該第２のビデオ符号化におけるＧＯＰのＩフレームのデータ量は、前記第１のビデオ符号化におけるＧＯＰのＩフレームのデータ量より大きいことを特徴とする前記サーバ（２）。
2. 前記クライアント装置（１４）はＴＶであり、前記ユーザ入力装置（１２）は前記ＴＶと通信するワイヤレスリモート制御装置であり、前記リモート制御装置からの信号は前記ＴＶによって受信され、前記サーバ（２）に送信される、請求項１のサーバ（２）。
3. 前記第１のビデオ符号化はビデオストリーミング用に最適化され、前記第２のビデオ符号化はグラフィックス用に最適化される、請求項１のサーバ（２）。
4. 前記第１のビデオ符号化は、ピクチャのグループ（ＧＯＰ）を決定するＭＰＥＧ符号化であり、各ＧＯＰは、１個のイントラフレーム（Ｉフレーム）と、複数の予測フレーム（Ｐフレーム）と、複数の双方向予測フレーム（Ｂフレーム）とを含む、請求項３のサーバ（２）。
5. 前記第２の符号化はピクチャのグループ（ＧＯＰ）を決定し、第２の符号化におけるＧＯＰは、当該第２の符号化におけるＧＯＰ内のフレームの数が前記第１の符号化のＧＯＰ内のフレームの数より多いことを含む、請求項３のサーバ（２）。
6. 前記第２の符号化のＧＯＰ内のＩフレームは、前記第１の符号化のＧＯＰ内のＩフレームよりも大きなデータ量を運ぶ、請求項５のサーバ（２）。
7. １個のＩフレームと２９個のＰフレームとを含む３０個のフレームを、前記第２の符号化のＧＯＰが含む、請求項５のサーバ（２）。

Images