JP5215604B2 - クライアント装置、通信システム及びデータ処理方法 - Google Patents

Description

本発明は、特に、サーバ装置及びクライアント装置がネットワークに接続され、サーバ装置が、クライアント装置における再生のために、ネットワーク上のオーディオ／ビデオストリームを提供するオーディオ／ビデオストリーミングシステム及びオーディオ／ビデオストリーミング方法に関する。

サーバ装置又は基地局が、ローカルで、住居内のオーディオ／ビデオ設備に直接接続されると共に、インターネット等のネットワークに接続されるシステムが知られている。サーバ装置は、ネットワークを介する送信のために、ローカルのオーディオ／ビデオ設備から受信したオーディオ／ビデオ信号をパッケージ化することができる。これにより、ユーザは、例えば、ソニープレイステーションポータブル（Sony PlayStation Portable：ＰＳＰ）（商標）、又はネットワークに接続されたラップトップコンピュータ等のクライアント装置を操作し、サーバ装置にとってローカルなオーディオ／ビデオ設備が提供するあらゆるオーディオ／ビデオ信号を受信し、視聴することができる。ロケーションフリー（LocationFree）（商標）等のシステムは、既にこのような機能を提供している。サーバ装置は、リモートコントロール信号をオーディオ／ビデオ設備に送信し、そのオーディオ／ビデオ設備を制御するための赤外線ブラスタを備えていてもよい。この場合、ネットワーク上のクライアント装置は、ネットワークを介して、サーバ装置にコマンドデータを送信して、オーディオ／ビデオ設備を制御する。例えば、クライアント装置は、コマンドデータを送信することによって、ネットワークを介して提供されている、生で放送されているオーディオ／ビデオストリームを変更し、又は、録画された番組が再生されている場合は、例えば、一時停止、早送り、巻戻し等、既知の様々なコマンド機能を送信することができる。

ネットワーク性能の変化に対応するために、クライアント装置において、ネットワークからのオーディオ／ビデオストリームの受信と、エンドユーザへの再生との間で、バッファリングを行うことが提案されている。通常、約３秒間のバッファリングが想定されている。

このバッファリングのために、例えばチャンネルを変更する場合、エンドユーザ側では、通常、例えば、少なくとも３秒間の対応する遅延が生じる。この遅延は、ユーザにとって不快であることは明らかであり、デジタル又はアナログ受信機でオーディオ／ビデオ放送を受信し、チャンネルを変更する場合に比べて劣っている。

ユーザの待ち時間を短縮するために、ネットワークを介してコマンドデータを送信する時点で、保存されている全てのデータのバッファリングをフラッシュすることが提案されている。

ここで、このシステムでは、サービスに送信されるコマンドデータの前に生成されたオーディオ／ビデオストリームの一部のデータは、システム内にまだ残っており、まだエンドユーザに表示されていないという問題がある。

本発明に係るデータ処理方法は、オーディオ／ビデオストリームをストリーミングするデータ処理方法において、ネットワークを介してサーバ装置が提供するオーディオ／ビデオストリームを受信するステップと、受信したオーディオ／ビデオストリームを処理し、所定の再生速度での再生を可能にするステップと、ネットワークを介して、サーバ装置にコマンドデータを送信し、サーバ装置が提供するオーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させるステップと、バッファにおいて、ネットワークから受信したオーディオ／ビデオストリームをバッファリングするステップと、コマンドデータを送信する時点で、所定の最短バッファリング時間内にバッファを空にするために必要なバッファ内のオーディオ／ビデオストリームの再生の高速再生速度を算出するステップと、コマンドデータの送信に応じて、バッファ内のオーディオ／ビデオストリームを処理し、少なくとも所定の最短バッファリング時間の間、オーディオ／ビデオストリームを高速再生速度で再生し、必要であれば、バッファリングされたオーディオ／ビデオストリームの量を、所定の再生速度において、所定の最短バッファリング時間に等しい再生時間を有する量に低減させる任意の更なる時間、バッファ内のオーディオ／ビデオストリームを高速再生速度で再生するようにバッファ内のオーディオ／ビデオストリームを処理し、次に、所定の再生速度で再生するように、バッファ内のオーディオ／ビデオストリームを処理するステップとを有する。

更に、本発明に係るクライアント装置は、ネットワークに接続し、ネットワーク上のサーバ装置から受信したオーディオ／ビデオストリームを再生するクライアント装置において、ネットワークに接続し、オーディオ／ビデオストリームを受信し、所定の再生速度での再生を可能にするように受信したオーディオ／ビデオストリームを処理し、ネットワークを介して、サーバ装置にコマンドデータを送信し、サーバ装置に、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させ、クライアント装置は、更に、ネットワークから受信したオーディオ／ビデオストリームをバッファリングするバッファを備え、コマンドデータを送信する時点で、所定の最短バッファリング時間内にバッファを空にするために必要なバッファ内のオーディオ／ビデオストリームの再生の高速再生速度を算出し、コマンドデータの送信に応じて、バッファ内のオーディオ／ビデオストリームを処理し、少なくとも所定の最短バッファリング時間の間、オーディオ／ビデオストリームを高速再生速度で再生し、必要であれば、バッファリングされたオーディオ／ビデオストリームの量を、所定の再生速度において、所定の最短バッファリング時間に等しい再生時間を有する量に低減させる任意の更なる時間、バッファ内のオーディオ／ビデオストリームを高速再生速度で再生するようにバッファ内のオーディオ／ビデオストリームを処理し、次に、所定の再生速度で再生するように、バッファ内のオーディオ／ビデオストリームを処理する。

これにより、クライアント装置のバッファに既に保存されている、第１のコンテンツに関連する全てのオーディオ／ビデオデータ、換言すれば、クライアント装置からコマンドデータを受信する前にサーバ装置が生成したオーディオ／ビデオデータは、高速再生によってスキップされる。これにより、レーテンシー又はクライアント装置におけるバッファリングが低減され、速やかな応答が実現する。更に、ユーザは、システムの応答を速やかに実感でき、第２のコンテンツのオーディオ／ビデオストリームがバッファリングされている間も、ディスプレイに何も表示されない状態を避けることができる。所定の最短バッファリング時間の最後に、バッファリングされたデータの量を再評価し、予想より多くのデータが残っている場合、高速再生を継続することによって、ネットワーク内又はネットワーク上で伝送中の第１のコンテンツのオーディオ／ビデオデータの高速再生を改善することができる。

更に、本発明に係るデータ処理方法は、オーディオ／ビデオストリームをストリーミングするデータ処理方法において、ネットワークを介してオーディオ／ビデオストリームをクライアント装置に供給するステップと、ネットワークを介してクライアント装置から送信されたコマンドデータに応じて、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更するステップと、バッファにおいて、ネットワークに出力されるオーディオ／ビデオストリームをバッファリングするステップと、クライアント装置からコマンドデータを受信すると、バッファをフラッシュするステップとを有する。

また、本発明に係るサーバ装置は、ネットワークに接続し、ネットワーク上のクライアント装置にオーディオ／ビデオストリームを提供するサーバ装置において、ネットワークに接続し、ネットワークを介して、クライアント装置にオーディオ／ビデオストリームを供給し、クライアント装置から送信されたコマンドデータを受信し、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更することによってコマンドデータに応答し、サーバ装置は、更に、ネットワークにオーディオ／ビデオストリームを出力するバッファを備え、サーバ装置は、クライアント装置からコマンドデータを受信すると、バッファをフラッシュする。

これにより、クライアント装置が受信する可能性がある第１のコンテンツのオーディオ／ビデオデータの量を低減することができる。コマンドデータがサーバ装置側で受信されると、第１のコンテンツに関連する全てのオーディオ／ビデオデータがサーバ装置側でフラッシュされ、ネットワークを介してクライアント装置に送信されなくなる。これにより、システム全体が、エンドユーザに第２のコンテンツのオーディオ／ビデオストリームをより速やかに提供することができる。

更に、本発明に係るデータ処理方法は、オーディオ／ビデオストリームをストリーミングするデータ処理方法において、ネットワークを介してオーディオ／ビデオストリームをクライアント装置に供給するステップと、ネットワークを介してクライアント装置から送信されたコマンドデータに応じて、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更するステップと、オーディオ／ビデオストリームにおける第２のコンテンツの開始を示すマーカデータを提供するステップとを有する。

更に、本発明に係るデータ処理方法は、オーディオ／ビデオストリームをストリーミングするデータ処理方法において、ネットワークを介してサーバ装置が提供するオーディオ／ビデオストリームを受信するステップと、受信したオーディオ／ビデオストリームを処理し、所定の再生速度での再生を可能にするステップと、ネットワークを介して、サーバ装置にコマンドデータを送信し、サーバ装置が提供するオーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させるステップと、サーバ装置が送信したオーディオ／ビデオストリームにおける第２のコンテンツの開始を示すマーカデータを特定するステップとを有する。

更に、本発明に係るサーバ装置は、ネットワークに接続し、ネットワーク上のクライアント装置にオーディオ／ビデオストリームを提供するサーバ装置において、ネットワークに接続し、ネットワークに接続されたとき、ネットワークを介して、クライアント装置にオーディオ／ビデオストリームを提供し、クライアント装置から送信されたコマンドデータを受信し、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更することによってコマンドデータに応答し、オーディオ／ビデオストリームにおける第２のコンテンツの開始を示すマーカデータを提供するステップとを有する。

更に、本発明に係るクライアント装置は、ネットワークに接続し、ネットワーク上のサーバ装置から受信したオーディオ／ビデオストリームを再生するクライアント装置において、ネットワークに接続し、オーディオ／ビデオストリームを受信し、再生を可能にするように受信したオーディオ／ビデオストリームを処理し、ネットワークを介して、サーバ装置にコマンドデータを送信し、サーバ装置に、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させ、クライアント装置は、更に、サーバ装置が送信したオーディオ／ビデオストリームにおける第２のコンテンツの開始を示すマーカデータを特定する。

これにより、オーディオ／ビデオストリームにおける第２のコンテンツの開始点が特定され、クライアント装置は、第１のコンテンツのオーディオ／ビデオストリームの再生から第２のコンテンツのオーディオ／ビデオストリームの再生に、直接及び確実に移行できる。

クライアント装置は、好ましくは、ネットワークから受信したオーディオ／ビデオストリームをバッファリングするバッファを備える。

クライアント装置は、マーカデータを受信すると、バッファをフラッシュするように構成してもよい。

これにより、クライアント装置は、バッファをいつフラッシュするべきかを特定できる。

クライアント装置は、好ましくは、マーカデータの受信後に受信したオーディオ／ビデオストリームのいずれかを再生する前に、マーカデータの受信後に受信した所定量のオーディオ／ビデオストリームをバッファリングする。

この構成では、クライアント装置は、ネットワークにおいて予想される比較的大きい割込みを考慮に入れるために必要な通常の定常状態のバッファリング又はレーテンシーを提供しないが、マーカデータの受信後に受信したオーディオ／ビデオストリームのいずれかを再生する前に、クライアント装置は、ネットワークにおけるデータレートの通常の変動を考慮に入れた十分なバッファリングを提供する。

クライアント装置は、マーカデータの受信後に受信した所定量のオーディオ／ビデオストリームをバッファリングした後にバッファをフラッシュすることに代えて、先にバッファリングされたオーディオ／ビデオストリームデータの全てを単にスキップしてもよい。

クライアント装置は、バッファリングされたオーディオ／ビデオストリームの各部分を順次解析し、マーカデータより前に受信したバッファリングされたオーディオ／ビデオストリームの部分をスキップしてもよい。

クライアント装置は、バッファリングされたオーディオ／ビデオストリームのスキップされた部分を、再生しないで削除してもよい。これに代えて、この部分を高速再生してもよい。

オーディオ／ビデオストリームは、好ましくは、複数の連続したオーディオ／ビデオパケットで搬送されるオーディオ及びビデオデータを含み、第２のコンテンツの開始を示すマーカデータは、ダミーオーディオパケット内に含ませてもよい。サーバ装置は、好ましくは、このようなダミーオーディオパケットを生成及び挿入するように構成してもよい。

更に、本発明に係るデータ信号は、タンジブルなインタフェースに解釈されるデータ信号において、第１のオーディオ及びビデオコンテンツのデータを表す第１の複数の連続するパケットに、第２のオーディオ及びビデオコンテンツのデータを表す第２の複数の連続するパケットが続き、第２の複数の連続するパケットの開始を示すマーカデータを搬送するダミーオーディオパケットを含む複数の連続したオーディオ／ビデオパケットによって搬送されるオーディオ及びビデオデータのストリームを含む。

また、本発明は、クライアント装置又はサーバ装置において実行されると、上述したいずれかのデータ処理方法におけるステップを実行するプログラムコードを有するコンピュータプログラムを提供する。更に、本発明は、コンピュータにより読取可能な媒体に保存された、このようなプログラムコードを有するコンピュータプログラム製品としても実現できる。

なお、本明細書及び特許請求の範囲におけるオーディオ／ビデオという表現は、オーディオ又はビデオの一方のみを処理するシステムも包含するものとする。なお、本発明は、オーディオ及びビデオの両方を処理するシステムに特に好適に適用される。

テレビジョン受像機、ビデオテープレコーダ、ビデオディスクプレーヤ及びレコーダ、デジタルテレビジョン放送を受信及び復号するセットトップボックス、例えば、ハードディスク記録装置を含むパーソナルビデオレコーダ（personal video recorder：ＰＶＲ）等、多くの異なる種類のオーディオ／ビデオ機器が消費者に提供されている。エンドユーザは、必要に応じて、これらの機器を選択し、相互に接続し、オーディオ／ビデオシステムとして使用する。

例えば、図１に示すオーディオ／ビデオシステム（以下、テレビジョンシステムとも言う。）（２）は、デジタルテレビジョンデコーダ（６）及びＰＶＲ（８）に接続されたテレビジョン表示装置（４）を備える。

図１に示すように、後に説明する基地局又はサーバ装置（１０）は、テレビジョンシステム（２）の１つ以上のオーディオ／ビデオ出力に接続されている。また、サーバ装置（１０）は、インターネット等の外部ネットワークに接続するためのポート又はインタフェース（１２）を備えている。

ここでは、利便性のため、及び説明を明瞭にするためにクライアント及びサーバ装置という用語を使用する。サーバ装置とは、クライアント装置における視聴／インタラクションのためにクライアント装置に送信されるオーディオ／ビデオデータのソースの一部又はソースと通信を行う機器を指す。もちろん、クライアント装置は、オーディオ／ビデオコンテンツのソースであってもよく、幾つかの実施の形態では、視聴／インタラクションのために、あるバージョンのオーディオ／ビデオコンテンツをサーバ装置に供給する。したがって、クライアント装置という用語とサーバ装置という用語は、交換可能であると解釈できる。幾つかの実施の形態では、クライアント装置及び／又はサーバ装置は、ピアツーピアネットワークのノードであってもよい。

また、図２に示すように、クライアント装置（１４）は、ネットワーク（１６）に接続されている。サーバ装置（１０）は、テレビジョンシステム（２）から受信した何らかのオーディオ／ビデオ信号を処理し（例えば、アナログ信号をデジタル化し）、ネットワークを介して、クライアント装置（１４）にデータを送信する。例えば、インターネットを用いる場合、サーバ装置（１０）は、例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＲＴＰ及びＲＴＳＰ等の標準のインターネットプロトコルを使用できる。クライアント装置（１４）は、受信データを復号し、表示に適するフォーマットのデータを生成する。クライアント装置は、表示用の信号を外部機器に供給してもよいが、好ましい実施の形態では、例えば、ラップトップコンピュータ及びソニープレイステーションパーソナル（Sony PlayStation Personal：商標）等のように、クライアント装置には、ディスプレイが組み込まれている。このようにして、エンドユーザは、世界中からのテレビジョン番組を生で又は録画して視聴することができる。

なお、ネットワーク（１６）の全部又は一部は、無線であってもよく、オーディオ／ビデオデータは、ワイドエリアネットワーク（例えば、インターネット）、又は、例えば、エンドユーザの住居内又はリビングルーム内に限定されたローカルエリアネットワークを経由して伝送することができる。

ライブストリーミングの品質を決定する要素として、画像及び音が所定のビデオレート及びオーディオレートで連続していることが重要である。クライアント側にフレームが到着しないと、又は到着が遅れると、オーディオ／ビデオ情報が不連続になる。オーディオ／ビデオの再生速度を安定させるために、ストリーミングのレーテンシーが使用されている。ストリーミングのレーテンシーとは、サーバ装置側でフレームが生成された時刻と、クライアント側でフレームが再生される時刻との間の遅延である。

ネットワークの両側でオーディオ／ビデオストリームのデータをバッファリングし、必要なレーテンシーを実現することによって、ネットワーク内に生じる遅延及びレートの変動を補償することができ、クライアント装置のエンドユーザは、オーディオ／ビデオストリームを連続的に受信することができる。

サーバ装置（１０）でのバッファリング量は、クライアント装置（１４）でのバッファリング量と略々等しくしてもよい。ネットワーク（１６）がインターネットである場合、サーバ装置（１０）及びクライアント装置（１４）の両方において、約３秒のバッファリングを行うとよい。なお、これらのパラメータは、例示的に示しているに過ぎない。以下の説明から明らかであるが、バッファリング時間は、任意の期間に設定できる。

サーバ装置（１０）においては、ネットワーク（１６）にオーディオ／ビデオストリームのデータを途切れることなく提供する必要がある。したがって、通常、サーバ装置（１０）内でバッファリングを行う１つ以上のバッファは、空の状態にある。ネットワーク割込みのためにネットワークにオーディオ／ビデオストリームのデータを出力することができなくなると、サーバ装置（１０）のバッファは、データのバッファリングを開始し、そのデータをネットワークに供給できるようになるまで、バッファリングされたデータを保持する。一方、クライアント装置（１４）では、１つ以上のバッファが、オーディオ／ビデオストリームのいずれかをエンドユーザに再生する前に、所定の期間、例えば、３秒間、データのバッファリングを行う。オーディオ／ビデオストリームは、間断なく再生するべきであるが、ネットワークからオーディオ／ビデオストリームを受信する際に、割込みが生じることがあり、したがって、これらの割込みの間、バッファリングされたデータの量が減少する。

なお、このバッファリング及びストリーミングのレーテンシーによって、全てのオーディオ／ビデオストリーミングの開始時に、長時間の遅延（例えば、３秒）が導入される。

クライアント装置（１４）は、ネットワーク（１６）を介して、サーバ装置（１０）にコマンドデータを送信することができる。このコマンドデータは、テレビジョンシステム（２）の一部を制御することを意図している。サーバ装置（１０）は、通常のリモートコントローラチャンネルによってテレビジョンシステム（２）のコンポーネントの１つ以上を制御する赤外線ブラスタ（infrared blaster）を備える。これに代えて、サーバ装置（１０）は、これらのコンポーネントを直接制御するために、これらのコンポーネントへのダイレクトリンクを備えていてもよい。

クライアント装置（１４）がチャンネルを変更するためのコマンドデータを送信すると、システムのレーテンシーが大きいために、チャンネル変更要求が行われた時刻と、クライアント装置（１４）がユーザに新たなチャンネルを再生する時刻との間に長い遅延が導入される。具体的には、新たなチャンネルの映像及び音のシーケンスは、レーテンシーに対応する遅延の後にしか再生できない。これにより、遅延の期間の間、映像及び音が止まってしまう。オーディオ／ビデオストリームのコンテンツを変化させる他の何らかのコマンドによっても同様の問題が生じる。例えば、一時停止、巻戻し、早送り、チャプタマーカに進む等のコマンドによって、記録されたオーディオ／ビデオシーケンスの再生を制御しようとする場合、ユーザは、同様の遅延を経験する。また、ユーザが、クライアント装置（１４）にストリーミングされているテレビジョンシーケンスを変更することなく、テレビジョンシステム（２）の一部を制御しようとした場合であっても、同様の問題が生じることがある。例えば、ユーザが、クライアント装置（１４）を用いて、テレビジョンシステム（２）の録画機能を設定する場合、テレビジョン画像にディスプレイ情報がスーパーインポーズされ、オーディオ／ビデオストリームが変更されるが、この画像をユーザに表示させるまでに、長いレーテンシーに対応する遅延が生じることは望ましくない。

図３は、本発明に基づくクライアント装置（１４）の構成を示している。

コントローラ（２０）は、クライアント装置（１４）を制御し、他のコンポーネント間のインタラクションを管理する。

インタフェース（２２）は、ネットワーク（１６）に接続され、コントローラ（２０）による制御の下で、必要なハンドシェーク及びネットワーク（１６）のためのプロトコルを処理する。

インタフェース（２２）を介してネットワーク（１６）から提供されたオーディオ／ビデオストリームは、バッファ（２４）に供給される。上述のように、バッファ（２４）は、例えば、通常３秒間のバッファリングを行う。

プロセッサ（２６）は、エンドユーザにオーディオ／ビデオストリームを再生するために、バッファ（２４）からオーディオ／ビデオストリームを読み出し、必要な処理を行い、ディスプレイ（２８）及びオーディオ変換器（３０）に信号を供給する。ディスプレイ（２８）及びオーディオ変換器（３０）は、クライアント装置（１４）から独立していてもよく、クライアント装置（１４）と一体に設けられていてもよい。

ユーザインタフェース（３２）は、コントローラ（２０）によって、クライアント装置（１４）及びサーバ装置（１０）を制御する。ここでは、タッチセンサ付きディスプレイとしてディスプレイ（２８）に統合されたインタフェースを含む如何なる適切な形式のユーザインタフェースを用いてもよい。ユーザインタフェース（３２）は、グラフィカルユーザインタフェース（graphical user interface：ＧＵＩ）の形式のインタフェースであってもよい。ユーザインタフェース（３２）は、従来の遠隔制御装置のボタンを仮想ボタンによって置き換えることによって、従来の遠隔制御装置をシミュレートしたインタフェースであってもよい。

ユーザインタフェース（３２）の起動に応じて、コントローラ（２０）は、インタフェース（２２）から、ネットワーク（１６）を介して、サーバ装置（１０）に、適切な形式でコマンドデータを送信させる。

図４は、本発明に基づくサーバ装置（１０）の構成を示している。

コントローラ（４０）は、他のコンポーネントを制御するように構成されている。

インタフェース（４２）は、ネットワーク（１６）に接続され、適切なハンドシェーク及びプロトコルを用いて、ネットワーク（１６）を介して通信を行う。一方、オーディオ／ビデオ（ＡＶ）インタフェース（４４）は、テレビジョンシステム（２）の１つ以上のコンポーネントに接続されている。２つ以上のコンポーネントへの接続が可能である場合、コントローラ（４０）は、サーバ装置（１０）内の更なる処理にどのオーディオ／ビデオ信号を渡すかを制御できるように構成してもよい。

プロセッサ（４６）は、ＡＶインタフェース（４４）から適切なオーディオ／ビデオ信号を読み出し、バッファ（４８）にオーディオ／ビデオストリームを供給する。プロセッサ（４６）は、例えば、デジタル−アナログ変換又はあるデジタルフォーマットから他のデジタルフォーマットへの変換等、必要に応じて、如何なる機能を実行してもよい。もちろん、２つ以上のプロセッサを設けてもよいことは明らかである。例えば、幾つかのシステムは、オーディオ／ビデオデコードを実行するための専用プロセッサ（ＤＳＰ）を備えていてもよい。

データは、バッファ（４８）から、インタフェース（４２）を介して、ネットワーク（１６）にストリーミングされる。ネットワーク（１６）上のサービスに何らかの割込みが生じ、インタフェース（４２）がネットワーク（１６）にデータを供給できない場合、バッファ（４８）は、ネットワーク（１６）がデータの適切な送信を許可するまで、そのデータをバッファリングする。上述のように、通常は、ネットワーク（１６）としてインターネットを用いる場合、約３秒のオーディオ／ビデオストリームに値するバッファサイズが好適である。

また、インタフェース（４２）は、クライアント装置（１４）が送信したコマンドデータを、ネットワーク（１６）から受信できる。コントローラ（４０）は、コマンドデータを解釈し、クライアント装置（１４）のユーザインタフェース（３２）及びクライアント装置（１４）のコントローラ（２０）によって生成された対応するコマンドデータによって指示された動作を実行する。

コントローラ（４０）は、もちろん、コマンドデータに応じて、サーバ装置（１０）のコンポーネントを制御することによって、サーバ装置（１０）自体の動作を制御してもよい。なお、コントローラ（４０）は、制御インタフェース（５０）のコマンドも有している。制御インタフェース（５０）は、テレビジョンシステム（２）の１つ以上のコンポーネントを制御するために適切な赤外線信号を生成できる赤外線ブラスタの形式を有していてもよい。このような構成により、サーバ装置（１０）は、特定のテレビジョン受像機について特別に設計又は実装されたインタフェースを用いる必要なく、如何なるテレビジョン受像機も制御できるという利点がある。コントローラ（４０）は、制御インタフェース（５０）を用いて、例えば、チャンネルの変更、録画機能の設定、録画されたオーディオ／ビデオシーケンスの再生等、テレビジョンシステム（２）のコンポーネントの使用可能な機能のいずれをも実現できる。もちろん、テレビジョンシステム（２）のコンポーネントが適切な通信リンクを有している場合、制御インタフェース（５０）は、これらの通信リンクを用いて、テレビジョンシステム（２）のコンポーネントと直接通信を行い、これらのコンポーネントを直接制御することができる。実際には、サーバ装置（１０）をテレビジョンシステム（２）内に統合してもよい。

クライアント装置（１４）のユーザインタフェース（３２）を操作することなくクライアント装置（１４）にオーディオ／ビデオストリームを供給するサーバ装置（１０）及びクライアント装置（１４）の実際の動作では、システムは、クライアント装置（１４）のバッファ（２４）を例えば、オーディオ／ビデオデータの３秒に相当するフル状態にし、サーバ装置（１０）のバッファ（４８）を略々空の状態にするよう試みる。これにより、オーディオ／ビデオストリームは、例えば、意図された３秒の定常状態レーテンシーでユーザに再生される。本発明を説明するために、この時点でのオーディオ／ビデオストリームのコンテンツを第１のコンテンツとする。

クライアント装置（１４）のユーザインタフェース（３２）が操作され、ネットワーク（１６）を介してサーバ装置（１０）にコマンドデータが送信されると、クライアント装置（１４）は、通常、何らかの応答を期待する。この応答には、例えば、サーバ装置からストリーミングされるライブチャンネルの変更、録画されたテレビジョンシーケンスの再生の一時停止又は停止、又は、単にテレビジョンシステム（２）のコンポーネントの１つの録画機能の設定の一部としてテレビジョン画像に制御情報をスーパーインポーズする処理、又は例えば、ＤＶＤ機器等の機器のコンテンツメニュー、及び文字放送等のナビゲーティングサービス等として、テレビジョン画像にナビゲーションメニューをスーパーインポーズする処理等が含まれる。コマンドデータに応じてオーディオ／ビデオストリームが変更されるこれらの状況の全てについて、本発明では、説明のために、オーディオ／ビデオストリームのコンテンツが第１のコンテンツから第２のコンテンツに変更されたと表現する。したがって、上述したように、第２のコンテンツは、テレビジョンデータの新たなライブストリーム、一時停止又は停止された画像、及び制御情報がスーパーインポーズされた画像のいずれをも指す。

通常の動作では、第２のコンテンツを表すオーディオ／ビデオストリームは、例えば、通常の３秒間のレーテンシー又はバッファリング遅延の後にエンドユーザに再生される。本発明は、上述したシステムの制御処理を改善し、この遅延を低減し、ユーザの操作性を向上させる。

なお、オーディオ／ビデオストリームは、広義に解釈され、第１のコンテンツから第２のコンテンツにオーディオ／ビデオストリームを変更するという表現は、第１のトランスポートストリームと第２のトランスポートストリームとの間の切換をも含み、第２のコンテンツを表すトランスポートストリームを第２のトランスポートストリームとして生成でき、システムは、これらのストリームを切り換える。

クライアント装置（１４）からコマンドデータを送信する際、単に、任意のデータのクライアント装置（１４）のバッファ（２４）をフラッシュしてもよい。例えば、コマンドデータによって、チャンネルの変更が開始された場合、ユーザは、既にバッファ（２４）内にあるオーディオ／ビデオストリームに基づく情報を視聴することを望んでいないとみなすことができる。更に、クライアント装置（１４）のアップストリームには、オーディオ／ビデオストリームの後続する部分が存在し、この部分も、ユーザは、視聴を必要としていない。

ここでは、サーバ装置（１０）がコマンドデータの受信を検出すると、サーバ装置（１０）のコントローラ（４０）は、サーバ装置（１０）のバッファ（４８）をフラッシュする。サーバ装置（１０）がコマンドデータを受信した時点では、ネットワーク（１６）を介する送信のためにバッファ（４８）に既にキューイングされているオーディオ／ビデオストリームの全てのデータは、第２のコンテンツではなく、第１のコンテンツに関連するデータである。したがって、このオーディオ／ビデオストリームの部分は、ユーザに再生する必要がないため、フラッシュすることができる。

サーバ装置（１０）のコントローラ（４０）は、コマンドデータを受信すると、内部的に、又は制御インタフェース（５０）を制御することによって、テレビジョンシステム（２）のコンポーネントの１つを制御する。テレビジョンシステム（２）のコンポーネントは、これに応答し、この応答に続くオーディオ／ビデオ信号は、オーディオ／ビデオインタフェース（４４）に供給され、プロセッサ（４６）によって処理され、新たなデータがバッファ（４８）に供給され、第２のコンテンツを表すオーディオ／ビデオストリームとしてネットワーク（１６）に送出される。

この構成の結果、クライアント装置（１４）は、実際にネットワーク（１６）を介して伝送中の第１のコンテンツに関連するオーディオ／ビデオストリームのユーザデータのみを受信及び再生する。このデータは、非常に僅かな量のデータであり、実際に、後述する理由のために、再生されなくてもよい。

なお、ビデオシーケンスのデジタル符号化は、通常、例えば、１〜２秒間隔で行われるＩフレームと呼ばれる完全な信号フレームの符号化を含む。Ｉフレームは、イントラマクロブロックを含む。そして、フレーム間補間によって、中間フレームが符号化され、すなわち、連続するフレーム間の補間によって、Ｐフレーム及びＢフレームと呼ばれる補間されたフレームが生成される。Ｐフレーム及びＢフレームは、イントラマクロブロックを含んでいてもよいが、これらは、多くの場合、（予測又は双方向予測された）インターマクロブロックを含む。

プロセッサ、例えばクライアント装置（１４）のプロセッサ（２６）等にＰフレーム又はＢフレームだけしか供給されなかった場合、元の画像を再生することはできない。プロセッサには、連続したＰフレーム及びＢフレームを供給する前に、Ｉフレームを供給する必要がある。このように、システムが単に、サーバ装置（１０）のバッファ（４８）及びクライアント装置（１４）のバッファ（２４）をフラッシュするように構成されている場合、ネットワーク（１６）で伝送中の次フレームは、先行する適切なＩフレームがなく、したがって、除外されることも多くある。

次に、サーバ装置（１０）のコントローラ（４０）は、コマンドデータを受信した後、好ましくは、プロセッサ（４６）を制御し、オーディオ／ビデオインタフェース（４４）からの第２のコンテンツに関連する新たなオーディオ／ビデオ信号を、Ｉフレームとして符号化される第１のフレームとして符号化させる。このようにして、第２のコンテンツを表すオーディオ／ビデオストリームの第１のフレームは、イントラフレーム補間のみが行われるＩフレームとなり、クライアント装置（１４）のプロセッサ（２６）は、そのフレームの元の画像を再生することができる。

上述したように、クライアント装置（１４）のバッファ（２４）は、例えば、ネットワーク（１６）における何らかの割込みを考慮に入れた通常のバッファ遅延時間又はレーテンシーで動作するように構成されている。バッファ（２４）がこの通常のバッファリング量を取り戻すまで、クライアント装置（１４）が待機した後に、オーディオ／ビデオストリームの再生を開始する場合、バッファ（２４）のフラッシングによって遅延時間を短縮する利益は得られない。一方、第２のコンテンツを表すオーディオ／ビデオストリームの受信の後に、バッファリングなしで、再生を開始する場合、ネットワーク（１６）からのデータの受信が不安定であれば、再生も必然的に不安定になる。そこで、このような状況において、ネットワーク（１６）を介する通常のデータフローの変化を考慮に入れて、十分な所定の最短バッファ遅延でバッファ（２４）を動作させることを提案する。換言すれば、通常の動作では、ネットワーク（１６）が正常に動作している場合、必然的に、データフローには変動があり、所定の最短バッファ遅延は、これらを考慮に入れるように意図して設定する。一方、通常のバッファリング遅延時間は、頻繁ではないが、定期的にネットワーク（１６）に生じる割込みを考慮して設定する。現実的には、所定の最小バッファリングの値は、４００ミリ秒相当のデータが適切であることが見出された。なお、最小バッファリングの量は、ネットワークに応じて、２００ミリ秒、又は１００ミリ秒相当のデータとしてもよい。より性能が劣るネットワークでは、この値を６００ミリ秒、８００ミリ秒又は１０００ミリ秒等としてもよい。

コマンドデータを送信し、クライアント装置（１４）のバッファ（２４）をフラッシュしたクライアント装置（１４）のコントローラ（２０）は、プロセッサ（２６）がオーディオ／ビデオストリームを再生する前に、バッファ（２４）に、例えば、４００のミリ秒等、所定のバッファリング時間に相当するデータをバッファリングさせる。これにより、エンドユーザが経験する遅延が大幅に短縮されるとともに、ネットワーク（１６）において生じるデータフローレートの通常の最小の変動を考慮に入れたバッファリングが行われる。

もちろん、オーディオ／ビデオストリームを安定させるためには、通常のより長いバッファリング遅延時間を用いることが望ましい。そこで、クライアント装置（１４）内のバッファ（２４）が行うバッファリングの量は、正常なより長いバッファリング時間に復元することが望ましい。このために、プロセッサ（２６）は、バッファ（２４）から、本来意図されている速度より僅かに遅い速度でオーディオ／ビデオストリームを再生する。ここでは、例えば、元の速度より５％遅い速度で再生を行うことが望ましい。プロセッサ（２６）が通常の速度より遅い速度でオーディオ／ビデオストリームを再生している間、バッファ（２４）には徐々にデータが満たされ、正常なより長いバッファリング時間に対応するデータがバッファリングされる。一旦、バッファ（２４）が正常なバッファリング時間を回復すると、プロセッサ（２６）は、通常の速度によるオーディオ／ビデオストリームの再生に戻る。

上述した構成の変形例として、クライアント装置（１４）のバッファ（２４）が再び満たされるまで、サーバ装置（１０）が遅い速度でオーディオ／ビデオシーケンスを供給しても同様の効果が得られる。実際には、サーバ装置（１０）側において、オーディオ／ビデオストリームを引き延ばし、ネットワーク（１６）を介して、クライアント装置（１４）のバッファ（２４）に実時間より速くストリーミングする。

上述した構成を更に改良して、クライアント装置（１４）からコマンドデータを受信したサーバ装置（１０）のコントローラ（４０）が、ネットワーク（１６）を介して送信するオーディオ／ビデオストリームに、第２のコンテンツを表すオーディオ／ビデオストリームの開始点を示すマーカデータを挿入することを提案する。これにより、クライアント装置（１４）は、オーディオ／ビデオストリームにおいて、第２のコンテンツの開始点を明確に特定することができる。

上述のように、オーディオ／ビデオストリームという表現は、広義に解釈され、サーバ装置からクライアント装置に情報を搬送する一般的なあらゆるデータストリームを含む。マーカデータを用いて、いずれも、概念的には同じオーディオ／ビデオストリームに含まれるある特定のトランスポートストリームから他の特定のトランスポートストリームへの変化を示すことができる。一方、全く異なるチャンネルを介してマーカデータを送信することもできる。例えば、コンテンツ／トランスポートストリームが変化した時刻を特定する「帯域外（out-of-band）」制御メッセージを送信してもよい。これは、クライアント装置に第１の新たなオーディオ又はビデオコンテンツのタイムスタンプを送信することによって、又は例えば、パケット番号、パケットカウント、フレームカウント等の他の手法で第１の新たなオーディオ又はビデオコンテンツを特定することによって実現できる。同様に、直前のオーディオ／ビデオコンテンツを特定でき、この情報をクライアント装置に送信することもできる。なお、ここでは、「帯域外」という表現を用いているが、必ずしもＴＣＰを使用する必要はなく、例えば、特別なＲＴＳＰメッセージ等、他の如何なるソケット接続を制御目的で用いてもよい。

クライアント装置（１４）は、ネットワーク（１６）を介してコマンドデータを送信したときにクライアント装置（１４）のバッファ（２４）をフラッシュするのではなく、サーバ装置（１０）からのマーカデータの受信を待ってバッファ（２４）をフラッシュするとよい。これにより、クライアント装置（１４）は、ネットワーク（１６）を介して伝送中のストリームを含む第１のコンテンツを表すオーディオ／ビデオストリームの全てを確実にフラッシュ又は無視できる。更に、コマンドデータの送信とマーカデータとの間の短い期間、クライアント装置（１４）は、第１のコンテンツを表すオーディオ／ビデオストリームの再生を続けることができる。ユーザは、このオーディオ／ビデオストリームの部分の再生を特に必要としていないかもしれないが、この手法により、途切れることなくエンドユーザにサービスを提供することができる。

上述のように、好ましい実施の形態では、クライアント装置（１４）のコントローラ（２０）は、バッファ（２４）及びプロセッサ（２６）を制御し、例えば、４００ミリ秒等、所定の最小バッファリングが完了するまで待って、第２のコンテンツを表すオーディオ／ビデオストリームの再生を開始する。もちろん、これによりエンドユーザへの再生が僅かに中断されるが、約４００ミリ秒程度の割込みは、例えば、テレビジョンシステムでのチャンネルの変更等の操作を行う場合と同様であり、ユーザにとって違和感は小さい。

ここで、オーディオ／ビデオストリームのどこにマーカデータを挿入するかを検討する必要がある。既存のクライアント装置は、サーバ装置（１０）からマーカデータを受信するように設計されていない。したがって、サーバ装置（１０）が送信したマーカデータが、これらの既存のクライアント装置の処理を妨げないことが重要である。

通常、ビデオ信号に含まれる僅かな欠陥に比べて、オーディオ信号の再生への割込みは、エンドユーザに知覚されやすい。したがって、オーディオ／ビデオストリームのオーディオ部分が優先される。このため、オーディオストリームの一部にマーカデータを含ませることを提案する。具体的には、オーディオデータを全く搬送しないダミーオーディオフレームを導入することを提案する。標準的なヘッダオーディオフレームのデータを、フレームがマーカデータに関連することを示す非標準的なデータに置換することによって、マーカデータを受信し、マーカデータに応じた処理を行うクライアント装置は、オーディオフレームをマーカデータに関連するフレームとして認識し、マーカデータを受信するように構成されていないクライアント装置は、単に、このデータにエラーが含まれているとみなし、フレームを除外する。リアルタイムのプロトコル及びアドバンスドオーディオコーデック（Advanced Audio Codec：ＡＡＣ）データに基づくオーディオフレームを用いるシステムでは、ＡＡＣヘッダを、フレームがマーカデータを含むことを示す非標準的なヘッダに置換してもよい。

他の代替例を以下に説明する。オーディオフレームをストリーミングする前に幾つかの具体例では、ＡＡＣヘッダ（ＡＤＴＳヘッダとも呼ばれる。）が除去され、したがって、このヘッダを置換することができない。ＡＤＴＳヘッダがない場合は、以下のような処理を行うことができる。ＡＡＣフレームは、幾つかのシンタクス要素から構成されている。最後の要素は、ＴＥＲＭ要素（ＩＤ＿ＥＮＤ，０ｂ１１１）でなくてはならない。ＴＥＲＭ要素から始まるフレームは、標準のデコーダでは無視されるため、チャンネルマーカとしての使用に適切であると考えられる。ＴＥＲＭ要素の後に、マーカとして認識できるデータパターンを隠すことができる。このマーカは、ＡＡＣデータ及び通常のオーディオデータに限らず、ビデオ又は他のデータパケットに含ませてもよい。

ダミーオーディオフレームは、オーディオストリーム内における時間的な位置を示すタイムスタンプを有する場合がある。サーバ装置（１０）のコントローラ（４０）は、マーカデータを含むオーディオフレームのタイムスタンプを、第２のコンテンツを表すオーディオ／ビデオストリームの第１のフレーム（実際には、Ｉフレーム）のタイムスタンプの直前に配置する。したがって、クライアント装置（１４）では、コントローラ（２０）は、マーカデータを示すダミーオーディオフレームを特定し、このマーカデータを示すダミーオーディオフレームより遅いタイムスタンプを有する後続する全てのデータを、第２のコンテンツを表すオーディオ／ビデオストリームに関連するフレームとして特定できる。

他の実施の形態では、マーカを、オーディオフレームとしてではなく、所謂「帯域外」シグナリングデータとして送信する。帯域外シグナリングとは、ビデオストリームに関するオーディオ又はビデオデータ自体から独立した情報の交換である。例えば、ＴＣＰを用いる実施の形態では、例えば、オーディオ又はビデオデータを伝送するために使用されていないソケットを介してマーカを送信することができる。この実施の形態では、マーカは、サーバ装置が第１のコンテンツを第２のコンテンツに切り換える時刻を一意的に特定する。これは、例えば、第２のコンテンツに第１のオーディオ又はビデオフレームのタイムスタンプを含ませることによって実現できる。

以下では、クライアント装置（１４）のバッファ（２４）をフラッシュしない変形例について説明する。更に、この変形例では、クライアント装置（１４）のバッファ（２４）が例えば、上述したように、４００ミリ秒の遅延に相当する所定の最小バッファリング量を確保すると共に、エンドユーザに表示される画像が途切れる状況を回避することができる。

クライアント装置（１４）においてマーカデータを受信した後も、コントローラ（２０）は、プロセッサ（２６）がバッファ（２４）から第１のコンテンツのオーディオ／ビデオストリームを再生し続けることを許可する。コントローラ（２０）が、バッファ（２４）を制御し、例えば、４００ミリ秒の第２のコンテンツのオーディオ／ビデオストリームに相当する所定の最小バッファリング量のバッファリングを行った後、プロセッサ（２６）は、バッファ（２４）にバッファリングされている第１のコンテンツのオーディオ／ビデオストリームを無視又はスキップする。具体的には、コントローラ（２０）は、第２のコンテンツの開始を示すマーカデータによって、第１のコンテンツの全てのオーディオ／ビデオストリームデータを特定できる。例えば、マーカデータのタイムスタンプを用いることによって、コントローラ（２０）は、より早いタイムスタンプを有するデータフレームを、第１のコンテンツに関連するフレームであると認識することができる。

このように、一実施の形態では、バッファ（２４）から第１のコンテンツに関連するフレームを除去する処理は、単に、各フレームをバッファ（２４）から順次読み出し、マーカデータより前のタイムスタンプを有する全てのフレームを削除することによって実現される。この処理は、フレームに含まれるデータを処理する必要がなく、非常に高速に行うことができる。

更なる変形例として、クライアント装置（１４）においてマーカデータを受信すると、バッファ（２４）が所定の最小バッファ量の第２のコンテンツのオーディオ／ビデオストリームをバッファリングしている間、コントローラ（２０）は、プロセッサ（２６）に対し、バッファ（２４）内の第１のコンテンツのオーディオ／ビデオストリームを、高速で、換言すれば、早送りモードで、再生させる。この速度は、例えば、バッファ（２４）が所定の最小バッファリング量の第２のコンテンツのオーディオ／ビデオストリームを取得するために必要な時間でバッファ（２４）の通常の容量を空にする所定の固定された速度であってもよい。これに代えて、コントローラが、現在、バッファ（２４）にバッファリングされているデータの量を考慮して、そのデータの全てが所定の最小バッファリング時間で再生されるように、再生の速度を設定するようにしてもよい。

ここに説明した構成では、所定の最小バッファリング量を選択又は変更することもできる。例えば、まず、クライアント装置（１４）のユーザインタフェース（３２）を用いて、サーバ装置（１０）へのコマンドデータの送信を開始したとき、コントローラは、例えば、２００ミリ秒の再生に相当する比較的短く設定された最小バッファリング量を試す。第１のコンテンツから第２のコンテンツへの切換において、第２のコンテンツの再生の開始時にバッファ（２４）が完全に空になっていることをコントローラが検出した場合、そのユーザインタフェース（３２）が次に使用され、コマンドデータが送信され、及び（新たな）第１のコンテンツ（前の第２のコンテンツに対応する。）が（新たな）第２のコンテンツに置換されるときは、コントローラは、バッファ（２４）の所定の最小バッファリング量をより大きくし、例えば、４００ミリ秒に相当するバッファリング量にする。

高速再生動作の間は、単に、ビデオシーケンスが、標準より速い速度で再生される。オーディオ及びビデオフレームは、サーバ装置ＤＳＰによって生成されるタイムスタンプによって同期される。クライアント装置は、タイムスタンプの情報に基づいて、ビデオフレームを再生するか否かを判定する。この結果、オーディオデータをより速く再生することによって、結果的に、ビデオフレームのシーケンスもより速く再生される。例えば、ソニーＰＳＰ（商標）、電話機等、演算能力が限定的な組込み機器を用いる幾つかの実施の形態においては、処理（ＣＰＵ）負担を軽減するために、ＩＤＲフレーム（ＡＶＣストリーミング）又はＩフレーム（ＭＰＥＧ−４ストリーミング）以外の全てのビデオフレームをスキップすることが望ましい。他のコンピュータ機器では、円滑な高速再生を実現するために、より速い再生速度で全てのビデオフレームを再生することが望ましい。

音声が出力されないように、オーディオストリームの音をミュートしてもよい。これに代えて、オーディオストリームを高速で再生してもよく、この場合、ピッチ制御を行っても行わなくてもよい。幾つかの実施の形態では、高速で再生されるオーディオストリームの音量を低減する。更なる変形例としてオーディオストリームを、例えば、クライアント装置（１４）内で生成された所定のビープ音、ジングル、何かを発射する音又は何かを加速する音等の所定のオーディオ信号に置換してもよい。

また、マーカデータを用いることなく、基本システムを改良することもできる。

一構成例においては、クライアント装置（１４）のコントローラ（２０）がサーバ装置（１０）にコマンドデータを送信すると、プロセッサ（２６）は、コントローラ（２０）に制御されて、より速い速度で、換言すれば、早送りで、バッファ（２４）からのデータの再生又は出力を開始する。

一構成例では、コントローラ（２０）は、プロセッサ（２６）に、バッファ（２４）の通常の完全なバッファリング量に等しい量のデータを高速再生させる。高速再生速度は、この動作の最後に、バッファ（２４）が、ネットワーク（１６）を介して受信した、所定の最小バッファリング量の新たなデータによって満たされるように設定することが望ましい。これは、通常、第２のコンテンツのオーディオ／ビデオストリームに対応する。上述のように、高速再生速度は、所定の最小バッファリング量に相当する時間（例えば、４００ミリ秒）の間に、完全なバッファリング量（例えば、３秒）のデータが再生されるように固定してもよい。これに代えて、コントローラは、バッファ（２４）内のデータを見積もり、これに応じて、このデータが必要な時間で再生されるように高速再生速度を設定してもよい。また、上述のように、所定の最小バッファリング量を適応的に選択してもよい。

更なる改善例として、コントローラ（２０）がコマンドデータを送信する際、コントローラ（２０）が、クライアント装置（１４）のバッファ（２４）内のデータ量を判定し、所定の最小バッファリング量に対応する時間、例えば、４００ミリ秒間に全てのデータを再生するために必要な高速再生速度を算出してもよい。そして、クライアント装置（１４）のプロセッサ（２６）は、バッファ（２４）からのデータを、算出された高速再生速度で再生するように制御される。

コマンドデータを送信し、クライアント装置（１４）のバッファ（２４）内のデータ量を判定する時点で、何らかの割込みのために、ネットワーク（１６）上にデータのバックログがある場合、上述した高速再生処理の間に、所定の最小バッファリング量より多い量のデータがクライアント装置（１４）のバッファ（２４）に到着することがある。例えば、高速再生速度が４００ミリ秒に相当するデータを再生するように設定されている場合、その期間の間に、５００ミリ秒に相当するデータがバッファ（２４）に供給されることがある。この場合、バッファ（２４）に供給される追加的データは、第１のコンテンツのオーディオ／ビデオストリームに関連するデータであることがほぼ確実であるため、コントローラ（２０）は、プロセッサ（２６）に対して、高速再生速度で、バッファ（２４）からのオーディオ／ビデオストリームの出力を継続させる。具体的には、プロセッサ（２６）による高速再生は、バッファ（２４）のデータ量が、例えば、４００ミリ秒に相当する所定の最小バッファリング量になるまで続けられる。

システムの他の改善例として、ネットワーク遅延又はレーテンシーの推定に基づいて、高速再生速度でバッファから読み出されるデータ量を調整してもよい。換言すれば、ネットワークレーテンシーの推定によって、クライアント装置は、コントローラがコマンドデータを送信した際に、ネットワークに存在する（そして、バッファ２４が未だ受信していない）第１のコンテンツのオーディオ／ビデオストリームの追加的データの量を推定することができる。このデータに相当する更なる期間、高速再生速度でバッファ２４からデータを出力することにより、第１のコンテンツのオーディオ／ビデオストリームの全てに亘るより最適な高速再生を実現できる。

また、ユーザが、ネットワークに接続されたクライアント装置を使用した経験に基づいて、必要な追加的な期間を入力するようにしてもよい。これに代えて、クライアント装置自体がネットワークを介して送受信されるパケットを監視し、ネットワークレーテンシーの推定を行ってもよい。一具体例においては、クライアント装置が、サーバ装置に検査信号を送信し、応答時間を監視するように構成してもよい。換言すれば、クライアント装置が、無意味な情報を含むパケットを生成し、サーバ装置に送信してもよい。他の具体例として、リアルタイムトランスポート制御プロトコル（Real-Time Transport Control Protocol：ＲＴＣＰ）を用いてもよい。これにより、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol：ＲＴＰ）フローのための帯域外制御情報が提供される。周知のとおり、この情報は、ストリーミングマルチメディアセッションに参加する機器に制御パケットを送信するために周期的に使用される。主な機能は、リアルタイムトランスポートプロトコルが提供するサービス品質のフィードバックを提供することである。そして、メディア接続に関する統計的な情報が収集される。

上述した構成により、第２のコンテンツのオーディオ／ビデオシーケンスへの速やかな変化を伴うユーザインタフェース（３２）の操作に対して、有効で最適なフィードバックをエンドユーザに効率的に提供することができる。

なお、上述した構成の全てにおいて、クライアント装置（１４）のバッファリング量が所定の最小バッファリング量にまで減少すると、システムは、遅延及びネットワーク（１６）における問題の影響を受けやすくなる。

この問題の影響を軽減するために、コントローラ（４０）がプロセッサ（４６）を制御し、より低いビットレートでオーディオ／ビデオストリームのフレームを提供するようにサーバ装置（１０）を構成してもよい。この結果、クライアント装置（１４）により再生される情報の品質が低下するが、この品質の低下は、欠落するフレームの数が減少する等の性能の改善によって相殺される。ビットレートを用いる選択又は実際のビットレートの低減の度合いは、ユーザ選択によって、又は過剰な数のフレームの欠落が生じているかをシステムが判定することによって適応的に決定することができる。

上述の説明は、システムが、第１のコンテンツのオーディオ／ビデオストリームの定常的な再生状態にあり、コマンドデータがサーバ装置（１０）に送信され、システムが、第２のコンテンツを表すオーディオ／ビデオストリームの他の定常的な再生状態に移行する状況だけを考慮している。クライアント装置（１４）において再生速度を遅くすることにより、クライアント装置（１４）のバッファ（２４）を通常の完全なバッファリング状態に戻してもよく、ここでは、例えば、２分間で、定常的な再生状態に戻すことを提案する。

もちろん、第１のコンテンツ及び第２のコンテンツという表現は、特定の各コマンドデータの前後のオーディオ／ビデオストリームのみを指している。

多くの場合、クライアント装置（１４）のユーザインタフェース（３２）は、間断なく何度も操作される。このような状況では、クライアント装置（１４）のコントローラ（２０）は、コマンドデータを送信する度にバッファ（２４）をフラッシュしようと試みないことが好ましい。これに代えて、単に、所定の最小バッファリング量でバッファ（２４）を動作させれば十分である。実際には、このような観点から、コントローラ（２０）は、バッファ（２４）が中間的バッファリング量（所定のバッファリング量と通常のバッファリング量との間）のデータをバッファリングしているかを判定し、バッファ（２４）がこの中間的バッファリング量以下のデータ（例えば、１秒未満相当のデータ）しかバッファリングしていない場合、バッファ（２４）のフラッシュ又は高速再生関する動作を行わないようにしてもよい。サーバ装置（１０）がバッファ（４８）をフラッシュする場合も、同様の改良を加えてもよい。サーバ装置（１０）は、短時間に連続するコマンドデータによって、第２の又は更なる動作が開始されたことを知る。第２、第３又は更なる操作が短期間に連続して実行された場合には、コントローラ（４０）は、バッファ（４８）をフラッシュし、Ｉフレームを生成する代わりに、何も動作を行わないようにしてもよい。

上述した実施の形態では、クライアント装置（１４）のバッファ（２４）のデータ量を所定の最小バッファリング量に低減した後、クライアント装置（１４）は、バッファ（２４）が徐々に満たされるように、低速再生モードでオーディオ／ビデオストリームを再生する。これに代えて、サーバ装置側におけるオーディオ／ビデオストリームが非実時間である場合、例えば、パーソナルビデオレコーダ（personal video recorder：ＰＶＲ）に事前に記録されたものである場合、ネットワークの制約に従い、オーディオ／ビデオストリームのデータをサーバ装置からクライアント装置に実時間より速いレートで送信でき、これにより、クライアント装置のバッファを再び満たすことができる。これにより、第１のコンテンツから第２のコンテンツへの変化の後に、クライアント装置が遅いレートでデータを再生する必要をなくすことができる。

図３及び図４は、クライアント装置（１４）及びサーバ装置（１０）の機能的ブロック図である。実際には、これらの機器に存在するレーテンシー又はバッファリングは、機器内に分散されている。例えば、クライアント装置（１４）は、ネットワーク（１６）から供給されたネットワークエンジンを備えていてもよく、個別のバッファを介して、オーディオ及びビデオデコーダに接続してもよい。オーディオ及びビデオデコーダは、更なる個別のバッファを介して、各オーディオ及びビデオ処理機器に接続してもよい。上述した構成は、いずれかの信号パスにおける総合的なレーテンシー又はバッファ遅延が上述した条件を満たすようにすることによって実現される。データのフラッシュ又はスキップは、特定の信号パス上の如何なるバッファで行ってもよいが、信号パスのアップストリーム側のバッファでデータをフラッシュ又はスキップすれば、これよりダウンストリーム側では、フラッシュ又はスキップされたデータを処理しなくても済むという利点がある。

本発明に基づくサーバ装置に接続されたテレビジョンシステムを示す図である。 本発明に基づくネットワーク接続されたシステムを示す図である。 図２のシステムにおいて用いられるクライアント装置の構成を示す図である。 図３のシステムにおいて用いられるサーバ装置の構成を示す図である。

Claims (13)

1. ネットワークに接続し、該ネットワーク上のサーバ装置から受信したオーディオ／ビデオストリームを再生するクライアント装置において、
   上記ネットワークに接続し、該ネットワークと通信して上記オーディオ／ビデオストリームを受信するインタフェースと、
   所定の再生速度での再生を可能にするように上記受信したオーディオ／ビデオストリームを処理するプロセッサと、
   上記ネットワークを介して、上記サーバ装置にコマンドデータを送信し、該サーバ装置に、上記オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させるコントローラと、
   上記ネットワークから受信したオーディオ／ビデオストリームをバッファリングするバッファとを備え、
   上記コントローラは、上記コマンドデータが毎回送信される度に、上記プロセッサを制御して、少なくとも所定の最短バッファリング時間の間、上記コマンドデータ送信時における上記バッファ内のオーディオ／ビデオストリームの量に関わらず、上記バッファ内のオーディオ／ビデオストリームを上記所定の再生速度より速い高速再生速度で再生し、次に、該所定の再生速度で再生するように、該バッファ内のオーディオ／ビデオストリームを処理する
   クライアント装置。
2. 上記コマンドデータの送信に応じて、上記コントローラは、上記プロセッサを制御し、所定の最短バッファリング時間の高速再生速度による再生後において、上記バッファリングされたオーディオ／ビデオストリームの量が、上記所定の再生速度において上記所定の最短バッファリング時間に等しい再生時間を有する所定量よりも多い場合、上記バッファリングされたオーディオ／ビデオストリームの量を前記所定量に低減させる任意の更なる時間、上記バッファ内のオーディオ／ビデオストリームを上記高速再生速度で再生するように該バッファ内のオーディオ／ビデオストリームを処理する請求項１記載のクライアント装置。
3. 上記コントローラは、上記高速再生速度として、上記コマンドデータを送信する時点で、所定の最短バッファリング時間内にバッファを空にするために必要な上記バッファ内のオーディオ／ビデオストリームの再生の高速再生速度を算出することを特徴とする請求項１又は２記載のクライアント装置。
4. 上記コントローラは、上記プロセッサを制御して上記高速再生速度での処理を実行させるときと、該プロセッサを制御して上記所定の再生速度での処理を実行させるときとの間に、該プロセッサを制御して、該所定の再生速度より遅い低速再生速度でオーディオ／ビデオストリームを再生するように上記バッファ内のオーディオ／ビデオストリームを処理させ、該バッファを再び満たすことを特徴とする請求項１乃至３いずれか１項記載のクライアント装置。
5. 上記コントローラは、上記オーディオ／ビデオストリームを処理し、上記高速再生速度で該オーディオ／ビデオストリームを再生する間、低減された音量で音声を出力することを特徴とする請求項１乃至４いずれか１項記載のクライアント装置。
6. 請求項１乃至５いずれか１項記載のクライアント装置と、
   上記ネットワークに接続し、該ネットワークと通信してオーディオ／ビデオストリームを供給するインタフェースと、
   オーディオ／ビデオ信号から上記オーディオ／ビデオストリームのデータを生成するプロセッサと、
   上記インタフェースと通信し、上記クライアント装置から送信されたコマンドデータを受信し、該コマンドデータに応じて、上記プロセッサを制御し、オーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更するコントローラと
   を備える通信システム。
7. オーディオ／ビデオストリームをストリーミングするデータ処理方法において、
   ネットワークを介してサーバ装置が提供するオーディオ／ビデオストリームを受信するステップと、
   上記受信したオーディオ／ビデオストリームを処理し、所定の再生速度での再生を可能にするステップと、
   上記ネットワークを介して、上記サーバ装置にコマンドデータを送信し、該サーバ装置が提供するオーディオ／ビデオストリームのコンテンツを第１のコンテンツから第２のコンテンツに変更させるステップと、
   バッファにおいて、上記ネットワークから受信したオーディオ／ビデオストリームをバッファリングするステップと、
   上記コマンドデータが毎回送信される度に、上記バッファ内のオーディオ／ビデオストリームを処理し、少なくとも所定の最短バッファリング時間の間、上記コマンドデータ送信時における上記バッファ内のオーディオ／ビデオストリームの量に関わらず、上記オーディオ／ビデオストリームを高速再生速度で再生し、次に、上記所定の再生速度で再生するように、該バッファ内のオーディオ／ビデオストリームを処理するステップと
   を有するデータ処理方法。
8. 上記コマンドデータの送信に応じて、上記バッファ内のオーディオ／ビデオストリームを処理し、所定の最短バッファリング時間の高速再生速度による再生後において、上記バッファリングされたオーディオ／ビデオストリームの量が、上記所定の再生速度において所定の最短バッファリング時間に等しい再生時間を有する量よりも多い場合、上記バッファリングされたオーディオ／ビデオストリームの量を、上記所定の再生速度において所定の最短バッファリング時間に等しい再生時間を有する量に低減させる任意の更なる時間、上記バッファ内のオーディオ／ビデオストリームを上記高速再生速度で再生するように該バッファ内のオーディオ／ビデオストリームを処理するステップを更に有する請求項７記載のデータ処理方法。
9. 上記高速再生速度として、上記コマンドデータを送信する時点で、所定の最短バッファリング時間内にバッファを空にするために必要なバッファ内のオーディオ／ビデオストリームの再生の高速再生速度を算出するステップを更に有する請求項７又は８記載のデータ処理方法。
10. 上記高速再生速度での処理と、上記所定の再生速度での処理との間に、上記所定の再生速度より遅い低速再生速度でオーディオ／ビデオストリームを再生するように上記バッファ内のオーディオ／ビデオストリームを処理するステップを更に有する請求項７乃至９いずれか１項記載のデータ処理方法。
11. 上記高速再生速度でオーディオ／ビデオストリームを再生する間、低減された音量で音声を出力するステップを更に有する請求項７乃至１０いずれか１項記載のデータ処理方法。
12. クライアント装置に、請求項７乃至１１いずれか１項記載のデータ処理方法におけるステップを実行させるコンピュータプログラム。
13. クライアント装置に、請求項７乃至１１いずれか１項記載のデータ処理方法におけるステップを実行させるコンピュータプログラムを記憶した記録媒体。

Images