JP2005051794A - ビデオをオン・デマンドでレンダリングするｖｃｒに似た機能 - Google Patents

Abstract

【課題】ストリーム・ディジタル・ビデオ・データをクライアント・コンピュータ上に表示する方法を提供する。
【解決手段】 クライアント・コンピュータはストリーム・ディジタル・ビデオ・データをコンピュータ・ネットワークを介してサーバ・コンピュータから受信するように構成される。ストリーム・ディジタル・ビデオ・データはビデオ・フレームのストリームとしてサーバ・コンピュータからクライアント・コンピュータに送信される。この方法はさらに、クライアント・コンピュータに関連付けられたビデオ表示端末上に第１の複数のビデオ・フレームを表示するステップを含む。さらに、クライアント・コンピュータからサーバに巻き戻しコマンドを発行するステップも含まれる。
【選択図】図１Ｂ

Description

本発明はコンピュータ・ネットワーク上で送信されるビデオ画像を表示する改善された方法に関する。本発明は、特に、サーバ・コンピュータからクライアント・コンピュータへコンピュータ・ネットワークを介して送達されるリアルタイム・ビデオ・ストリームおよび／またはライブ・ビデオ・ストリームに対して、再生、巻き戻し、早送り、一時停止、停止、録画などの制御機能を実施又は具現化する改善された方法および装置に関する。

ディジタル・ビデオ・データはコンピュータを使用して操作されレンダリングされることはよく知られている。コンピュータ・ネットワーク、例えばクライアント・サーバ・コンピュータ・ネットワークでは、１つまたは複数のコンピュータを使用してアナログ・ビデオ・データを受信し（例えば、ビデオ・カメラから）、そのアナログ・ビデオ・データを適当なディジタル・フォーマットに符号化し、ディジタル・ビデオ・データ・ファイルを記憶することができる。ユーザはその後、ネットワークに結合されたコンピュータを使用して、クライアント・コンピュータに関連付けられたビデオ・ディスプレイに表示する事前に記憶されたディジタル・ビデオ・データ・ファイルを要求することができる。

コンピュータが職場と家庭に普及するにつれて、それに応じて、ディジタル・ビデオ・サービスの需要が増加してきた。例を挙げると、クライアント・コンピュータがファイルを受信した後で画像を表示するために事前に記憶されたディジタル・ビデオ・ファイルをサーバから１つまたは複数のクライアント・コンピュータに送信できる大容量通信媒体として、ネットワーク接続されたコンピュータを使用できることが分かっている。この技術は、例えば、表示するために中央サーバから１つまたは複数のクライアント・コンピュータに映画または訓練用ビデオ・クリップを送達するのに使用できる。

上の例では、クライアント・コンピュータが画像をレンダリングする前に事前に記憶されたディジタル・ビデオ・ファイル全体を受信することが通常必要である。他方、リアルタイム・ビデオ・ストリーミングは、クライアント・コンピュータがサーバ・コンピュータから伝送されている画像をレンダリングする状況を指す。用途によっては、リアルタイム・ビデオ・ストリーミングでは、ユーザはサーバ・コンピュータから事前に記憶されたファイル全体がダウンロードされるのを待たずに、ビデオ・ファイルを要求した直後にビデオ・フレームの表示を開始できるため、リアルタイム・ビデオ・ストリーミングが好ましい。

ただし、リアルタイム・ビデオ・ストリーミングは、とりわけ、さまざまな軍事、政府、教育、非営利、産業、金融機関、営利企業、および個人をリンクするよく知られている国際コンピュータ・ネットワークである企業内ネットワーク、すなわちイントラネットなどの異機種の伝送損失が多いネットワーク上で実施するのが難しいことが分かっている。これは、すべてディジタル・ビデオの適用例であるリアルタイム・ディジタル・ビデオの適用例の実施に大量のリソースを必要とすることによる。圧縮した場合でも、高品質のビデオ・クリップ（すなわち、許容フレーム速度およびフレーム品質を備えたビデオ・クリップ）はコンピュータ・ネットワーク上でかなりの帯域幅を使用する。この理由から、リアルタイム・ビデオ・ストリームは、従来、高速の伝送速度をサポートできる専有の高価なネットワーク（例えば、私設高速ローカル・エリア・ネットワーク（ＬＡＮ）または専用データ・リンク）上で実施されてきた。

さらに、リアルタイム・ビデオ・データは時間に敏感である、すなわち、リアルタイム・ビデオ・データを含むデータ・パケットは、受け入れられる表示のために正しいシーケンスで適時に受信される必要がある。帯域幅が限られたネットワーク、例えば、多数のユーザをサポートする企業イントラネットまたは上記のインターネットのような異機種の伝送損が多い公衆ネットワークでは、リアルタイム・ディジタル・ビデオ・データの時間に敏感な性質が特別の課題を投げかける。例えば、クライアント・コンピュータで所与のデータ・パケットを表示する時間が過ぎると、そのデータ・パケットが到着した場合でも、また到着した時にもそのデータ・パケットの使途はほとんどないので、紛失データ・パケットを再送する時間は少なくなる。

リアルタイム・ディジタル・ビデオ・ストリーミングは複雑なフレーム同期化の問題を引き起こす。表示されるビデオ・フレームはクライアント・コンピュータで記憶されないので、巻き戻し、早送り、再生、および一時停止などの制御機能を実行する事前に記憶されたファイルは存在しない。通常、これらの機能を実行するのに必要なビデオ・フレームはサーバ・コンピュータ自体が要求する。次いで、制御コマンドに応答して、要求された制御機能を実行するのに必要なビデオ・フレームは、通常は同じデータ接続上でクライアント・コンピュータへ伝送され、別のデータ接続を確立する処理に関連付けられた待ち時間を最小限にする。当業者には明らかなように、異なるグループのビデオ・フレームを切り替える場合に厄介な問題が発生することがあり、ビデオ・フレームの一部はサーバで送信待ち状態であるか、クライアントで表示待ち状態であるか、ネットワークを介して中継中であるか、または失われている。

リアルタイム・ビデオ・ストリームに対して制御機能を実施することに含まれる複雑さは、リアルタイム・ビデオ・アプリケーションが課す短い待ち時間の要件、すなわち、サーバ・コンピュータから所与のビデオ・フレームが送信されてからクライアント・コンピュータでレンダリングされるまでの時間を最小限にする要求によってさらに拡大される。これらの制御機能が適正に実施されない場合、過度の待ち時間が発生し、かつ／または表示状態の品質が劣化することがある。

上記のすべての課題はライブ・ビデオ・ストリーミングにも当てはまる。ライブ・ビデオ・ストリーミングでは、ビデオ・データは１つのロケーションでディジタル化され、次いで符号化され、ほぼ瞬間的に（サーバを介して）表示のためにクライアント・コンピュータに送信される（ビデオ・フレームの符号化と送信による多少の遅延があるが）。ライブ・ビデオおよびリアルタイム・ビデオは、伝送されるビデオのサブセットと考えられるが、これはライブ・ビデオ・フレームもリアルタイム・ビデオ・フレームもサーバから伝送される先からレンダリングされることによる。ただし、ライブ・ビデオ・レンダリングでは最も最近符号化されたビデオ・フレームが表示される一方、リアルタイム・ビデオ・レンダリングでは現在記録されているイベントまたは過去に発生しはるか前に記録されたイベントの過去のビデオ・フレームさえも表示される。ライブ・ビデオ・ストリーム・アプリケーションはネットワークを介して送信されるデータ・パケットに関してさらに敏感であることが理解できよう。これは、記録されているライブ・イベントがつねに展開され、それに関連するビデオ・フレームが常に形成され時が経つと共に表示される必要があるためである。

ライブ・ビデオ・ストリーミングに関するフレーム同期化は、サーバのディジタル・ビデオ・データ・ファイルがそれに関連するビデオ・フレームがクライアント・コンピュータで表示されると同時に形成されているということによってさらに複雑になっている。これはクライアント・コンピュータに送信されるビデオ・フレームのコピーも後で使用するためにサーバのディジタル・ビデオ・データ・ファイルに記憶されるためである。したがって、例えば、ユーザがライブ・ビデオ表示モードから巻き戻しモードに切り替えようとする場合、表示がビデオ・フレームに数秒分遅れ、依然として増大しているディジタル・ビデオ・データ・ファイルの最後まで早送りを行ってライブ・ビデオ・フレームを再度再生する。これに含まれる複雑さと帯域幅および待ち状態時間の要件のために、ライブ・ビデオ・ストリームに対する制御機能を具現化する従来技術の試みは大幅に不満足な結果となっている。これは大半のネットワークに当てはまるが、トランスポート・ネットワークが通常伝送損が多くサーバおよび／またはクライアント・コンピュータのオーナの制御下になく、また利用可能な帯域幅が制限され、変動しやすいインターネットには特に当てはまる。

前記の事態に鑑みて、サーバ・コンピュータからクライアント・コンピュータにコンピュータ・ネットワークを介して送信されるリアルタイム・ビデオ・ストリームおよび／またはライブ・ビデオ・ストリームに対する制御機能を具現化する改善された方法と装置が望まれる。

一実施形態では、本発明はサーバからストリーム・ディジタル・ビデオ・データを伝送する方法に関する。サーバはコンピュータ・ネットワークを介してクライアント・コンピュータに結合するように構成される。この方法は第１の複数のデータ・パケットをサーバ・プレイアウト・バッファに入力するステップを含む。第１の複数のデータ・パケットはストリーム・ディジタル・ビデオ・データを表すビデオ・フレームを含む。サーバ・プレイアウト・バッファの出力は第１の複数のデータ・パケットをクライアント・コンピュータに送信するためにネットワーク・データ接続に結合するように構成される。

この方法は再送バッファを使用してサーバ・プレイアウト・バッファから第１の複数のデータ・パケットを受信するステップを含む。再送バッファの出力はネットワーク・データ接続に結合される。この方法はさらに、データ・パケットをコンピュータ・ネットワークを介してクライアント・コンピュータに送信するために、サーバ・プレイアウト・バッファからネットワーク・データ接続に第１の複数のデータ・パケットを出力するステップを含む。

別の実施形態では、本発明はストリーム・ディジタル・ビデオ・データをクライアント・コンピュータ上に表示する方法に関する。クライアント・コンピュータはストリーム・ディジタル・ビデオ・データをコンピュータ・ネットワークを介してサーバ・コンピュータから受信するように構成される。ストリーム・ディジタル・ビデオ・データはビデオ・フレームのストリームとしてサーバ・コンピュータからクライアント・コンピュータに送信される。この方法はクライアント・コンピュータで第１の複数のビデオ・フレームを受信するステップを含む。複数のビデオ・フレームはビデオ・フレームのストリームのサブセットを表す。ビデオ・フレームのストリームは独立の再生可能なビデオ・フレームと従属の再生可能なビデオ・フレームとを含む。

この方法はさらに、クライアント・コンピュータに関連付けられたビデオ表示端末上に第１の複数のビデオ・フレームを表示するステップを含む。さらに、クライアント・コンピュータからサーバに巻き戻しコマンドを発行するステップも含まれる。巻き戻しコマンドを使用すると、第１の複数のビデオ・フレームとは異なるビデオ・フレームのストリームの第２の複数のビデオ・フレームがサーバ・コンピュータからクライアント・コンピュータに伝送される。第２の複数のビデオ・フレームは少なくとも１回、クライアント・コンピュータに伝送される。

さらに別の実施形態では、本発明は、クライアント・コンピュータが第１の制御モードから第２の制御モードに移行する際にクライアント・コンピュータでのストリーム・ディジタル・ビデオ・データの表示を制御するように構成された制御機能を実施するコンピュータが読み取り可能な命令を含むコンピュータ読取り可能な媒体に関する。クライアント・コンピュータは、コンピュータ・ネットワークを介してサーバ・コンピュータに結合するように構成される。ストリーム・ディジタル・ビデオ・データは、サーバ・コンピュータからクライアント・コンピュータに独立のビデオ・フレームと従属のビデオ・フレームとを含むビデオ・フレームのストリームとして送信される。ビデオ・フレームのストリームはそれぞれ一意的なパケット・シーケンス番号と一意的なタイム・スタンプを備えた複数のデータ・パケット内にカプセル化される。コンピュータ読取り可能な命令は制御コマンドを送信するためのコンピュータ読取り可能な命令とクライアント・コンピュータからサーバ・コンピュータへの時間パラメータとを含む。制御コマンドは、第２の制御モードに従ってビデオ・フレームのストリームの第１の複数のビデオ・フレームをクライアント・コンピュータに送信するためのサーバへのコマンドを表す。

また、コンピュータ読取り可能な命令は、制御コマンドに応答して、かつサーバ・コンピュータを使用して、クライアント・コンピュータに送信する第１の独立のビデオ・フレームを確認するためのコンピュータ読取り可能な命令を含む。第１の独立のビデオ・フレームは時間パラメータに応答して選択される。コンピュータ読取り可能な命令は、サーバ・コンピュータからクライアント・コンピュータに第１の独立のビデオ・フレームに関連付けられたパケット・シーケンス番号を送信するためのコンピュータ読取り可能な命令をさらに含む。コンピュータ読取り可能な命令は、第１の独立のビデオ・フレームから開始するビデオ・フレームのストリームの第１の複数のビデオ・フレームをサーバ・コンピュータからクライアント・コンピュータに伝送して、第１の複数のビデオ・フレームをクライアント・コンピュータに表示するためのコンピュータ読取り可能な命令をさらに含む。

本発明のこれらの特徴とその他の特徴を、以下の本発明の詳細な説明中で下記の図面を参照しながら詳述する。

添付の図面に示すいくつかの本発明の好ましい実施形態を参照しながら、本発明を詳述する。以下の説明では、本発明を完全に理解するために多数の特定の詳細内容を記載する。ただし、本発明はこれらの特定の詳細内容の一部または全部がなくても実施できることは、当業者には明らかであろう。その他の場合、本発明を不必要に分かりにくくしないように、よく知られている方法ステップは記載しない。

本発明の一態様によれば、リアルタイム・ビデオ・データをサーバ・コンピュータからクライアント・コンピュータに表示のために伝送する改善された技術が提供される。本発明のこの態様によれば、リアルタイム・ビデオ・ストリームに関するディジタル・データは、再生ストリームと早送りストリームの２つのストリームのいずれかの形式のデータ・パケットとしてサーバ・コンピュータからクライアント・コンピュータに送信される。本明細書で詳述するように、ビデオ・フレームの個別の早送りストリームの使用によって、早送り機能はより小さい帯域幅要件と改善された表示品質の要件で実施できる。ユーザが再生モードから早送りモードに切り替え、またその逆に切り替える場合、再生ストリームまたは早送りストリーム内にビデオ・データを含むデータ・パケットはサーバ・コンピュータからクライアント・コンピュータに表示のために送信される。

再生ストリームは、クライアント・コンピュータのレンダラ・アプリケーションによって指定のフレーム速度（一例では約１０フレーム／秒）で再生される時に品質が最大限になり帯域幅要件が最小限になるフレームを含む。この通常再生モードは、ユーザがビデオ・フレームを表示する（例えば、映画またはビデオ・クリップを鑑賞する）場合に通常使用するモードを表す。通常再生は、通常、音響（通常、ビデオを送信するためのデータ接続とは異なるデータ接続を介してクライアントに供給される）と、おそらく他のアプレットを伴うことを理解すべきである。早送りストリームは、クライアント・コンピュータ内のレンダラ・アプリケーションによって指定のフレーム速度で再生される時に、ユーザに早送りの効果を提供する一方で、有利なことに表示品質を高く保持し、再生ストリームが早送りのために使用されていたなら可能であった速度より伝送速度を低くするフレームを含む。本発明のこの態様については本明細書に後述する。例を挙げると、早送りストリームは秒あたり５フレームを再生するが、これによって再生速度の５倍のフレームが表示される。

本発明の別の態様によれば、データ・パケットは表示のためにクライアント・コンピュータ内のレンダ・アプリケーションに到着する前に少なくとも２つのバッファを通過する。すなわち、サーバ・コンピュータの再送バッファとクライアント・コンピュータのプレイアウト・バッファである。一実施形態では、サーバ・プレイアウト・バッファが効率的なデータ・パケットの送信を容易にするためにサーバ側にも提供される。クライアント・プレイアウト・バッファおよび／またはサーバ・プレイアウト・バッファの使用によって、表示の準備ができたクライアントで利用可能なデータ・パケットを少量供給して、したがって、ネットワークの利用可能な帯域幅の一時的な変動および一時的なネットワーク輻輳によるコンピュータ・ネットワークを介したデータ・パケットの送信の一時的な混乱による表示状態への影響が最小限になる。

本発明の別の態様によると、再生、巻き戻し、早送り、一時停止、停止、録画および／またはその他の制御機能を実施する新規で効率的な実施態様が提供される。一実施形態では、制御機能は一般のビデオ・カセット・レコーダ（ＶＣＲ）制御機能へのユーザの慣れを最大限にするために実施される。本発明の制御機能を使用して、ユーザはユーザフレンドリで直感的な方法で、リアルタイム・ビデオ・ストリーム、または有利なことに、クライアント・コンピュータのライブ・ビデオ・ストリームに関するビデオ・フレームの送信と表示とを制御することができる。ユーザは、本発明の技術を使用して、データのリアルタイムの性質または送信されるリアルタイム・データ・パケットに固有の時間に敏感な性質に不当に制約されずに伝送されるリアルタイム・ビデオ・フレームの表示を柔軟に制御できるので、本発明のこの態様は特に有利である。一実施形態では、異なる制御モード間の移行、例えば、再生モードから早送りモード、巻き戻しモードから再生モードへの移行は効率化されて同期化され、したがって、ビデオ・フレームの表示品質が最大限になる。

以上の説明をさらに分かりやすくするために、図１Ａに、本発明の一実施形態による、本発明のリアルタイム・ビデオ表示技術を実施するのに適したコンピュータ・ネットワークを示すコンピュータ・ネットワーク１００を示す。コンピュータ・ネットワーク１００は、例えば、前述したインターネットまたは企業イントラネットの一部を表す。

図１Ａでは、コンピュータ・ネットワーク１００はサーバ・コンピュータ１０２とクライアント・コンピュータ１０４とを含む。またビデオ・カメラ１０６も示されている。この例では、ビデオ・カメラ１０６はビデオ・データを記録する装置を表す。記録されたビデオ・データは次いでディジタル化され、エンコーダ１１０によって、サーバ１０２または記憶のためにメモリ１１５に送信するのに適したディジタル・データ・フォーマットに符号化される。本発明の一実施形態では、エンコーダ１００は、そこからサーバを介してデータをクライアントに伝送できるビデオ・ソースを表す。エンコーダ１１０は、ハードウェアまたはソフトウェアで実施でき、生のディジタル・ビデオ・データを圧縮して記憶と送信の効率を改善することもできる。１つの適切な符号化方式が、すべての目的のため参照として本明細書に組み込まれた、共通に譲渡された１９９６年３月２８日出願の同時係属の特許文献１に開示されている。
米国特許出願第０８／６２３２９９号

次いで、エンコーダ１１０から出力された（またはメモリ１１５から取り出された）データ・パケットは、クライアント・コンピュータ１０４に送信するためサーバ・プレイアウト・バッファ１１２に入れられる。メモリ１１５は、図１Ａでは不揮発性ディスク・メモリとして示されているが、メモリ１１５は揮発性半導体メモリを含む任意の適切なタイプのメモリ装置を表すことができる。前述のように、メモリ１１５内に記憶されたデータ・パケットのファイルを使用して、クライアント・コンピュータ１０４は巻き戻し、早送り、およびその他の制御モードを容易にすることができる。

各データ・パケットまたはデータ・パケットのグループがサーバ・プレイアウト・バッファ１１２から送信のためにデータ接続１１４に出力される際（例えば、サーバ・コンピュータ１０２が制御接続１１６を介して受信するクライアント・コンピュータ１０４からのコマンドに応答して）、同じデータ・パケットまたはデータ・パケットのグループがサーバの再送バッファ１１８に入力される。制御接続１１６およびデータ接続１１４は、「Methods and Apparatus for Implementing Control Functions in a Streamed Video Display System」と題された共通に譲渡された同時係属の特許文献２に詳述されている。
米国特許出願第＿＿号（整理番号：ＶＸＴＭＰ００１／ＶＸＴ７０４）

一実施形態では、再送バッファ１１８は、サーバ・プレイアウト・バッファ１１２から送信されたデータ・パケットを限定された期間保持する先入れ先出し（ＦＩＦＯ）バッファを表す。新しいデータ・パケットが再送バッファ１１８に入力されると、古いデータ・パケット（最古のデータ・パケットから開始する）は、送信バッファ１１８から廃棄される。再送バッファを使用することで、有利なことに、その中のデータ・パケットの再送要求がクライアント・コンピュータ１０４から送られると（例えば、クライアント・コンピュータ１０４によって不明データ・パケットが検出された場合）、前記データ・パケットを迅速に再送することが容易にできる。再送バッファ１１８は、データ・パケットがサーバ１０２から送信されてからクライアント・コンピュータ１０４で表示されるまでの平均待ち時間よりもわずかに長い時間だけデータ・パケットが再送バッファ内にとどまる程度のサイズであることが好ましい。本発明の一実施形態では、リアルタイム・ビデオおよび／またはライブ・ビデオの時間に敏感な性質のため、表示のためにクライアント・コンピュータ１０４で要求されてから長い期間、データ・パケットを再送バッファ内にとどめておくことは通常は有用でないので、再送バッファ１１８が上記のサイズよりはるかに大きい必要はない。

データ・パケットがデータ接続１１４からクライアント・コンピュータ１０４によって受信されると、データ・パケットはレンダラ・アプリケーション１２２によって表示されるためにクライアント・プレイアウト・バッファ１２０に入力される。一実施形態では、クライアント・プレイアウト・バッファ１２０はＦＩＦＯバッファを表すことがある。クライアント・プレイアウト・バッファ１２０および／またはサーバ・プレイアウト・バッファ１１２は通常、データ接続１１４が通過するネットワーク１００の信頼性と耐久性とを考慮する一方で待ち時間を最小限にするのに適当なサイズである。ネットワークにかなりの信頼性があり、その帯域幅がかなり安定している場合、クライアント・プレイアウト・バッファ１２０および／またはサーバ・プレイアウト・バッファ１１２は、データ・パケットがエンコーダ１１０によって出力されてからクライアント・コンピュータで表示されるまでの待ち状態時間を最小限にするため比較的小さくてよい。他方、より大きいクライアント・プレイアウト・バッファ１２０および／またはサーバ・プレイアウト・バッファ１１２はレンダラ・アプリケーション１２２を一時的な帯域幅容量の変動とサーバ・コンピュータ１０２からのデータ・パケットの送信の混乱からより有効に防止することができる可能性がある。

再送バッファ１１８からのデータ・パケットの再送は、通常、前記データ・パケットが表示される前に限って、すなわち、データ・パケットがクライアント・プレイアウト・バッファ１２０の出力で必要とされる前に限って有用であることから、クライアント・プレイアウト・バッファ１２０は再送バッファ１１８と同じサイズであってもよいが、このことが必要であるというわけではない。本明細書に示すバッファは、一実施形態では、ソフトウェアで実施でき、必要に応じて動的にサイズを変更できることを理解すべきである。この例では、レンダラ・アプリケーション１２２は符号化されたディジタル・データを復号化するためのデコーダを含むことができる。

説明を簡単にするために、図１Ａには、１つの制御接続１１６と１つの制御接続１１４しか示されていないが、所与のリアルタイム・ビデオ・セッションは、ビデオ、オーディオ、注釈などの多数のデータ・ストリームのための多数のデータおよび制御接続を含むことができる。さらに、エンコーダ１１０はサーバ１０２以外のコンピュータ上で物理的に実施できる。一実施形態では、単一のエンコーダが、地理的に分散したロケーションに存在する可能性がある多数のサーバにビデオ・データを供給して、これらのサーバに任意の数のクライアント・コンピュータからの要求を処理させることができる。図１Ｂに、エンコーダ１５２がビデオ・カメラ１５４からのビデオ・データを多数のサーバ１５６に供給するこの実施形態を示す。適切なプロトコルを使用して、クライアント１５８は１つまたは複数のサーバ１５６にビデオ・データ・パケットを要求して、クライアント１５８でビデオ・フレームを表示することができる。

特に有利な一実施形態では、クライアント１５８はクライアント・コンピュータ上で実行されるウェブ・ブラウザにそのまま接続されるプラグイン・ソフトウェア・アプリケーションを表す。クライアント・アプリケーション１５８が起動されると、クライアント・アプリケーション１５８は１つまたは複数のサーバ１５６との制御接続を確立し、前記サーバ１５６に所望のビデオ・ファイルを要求する。所望のビデオ・ファイルがサーバ１５６上に見つかると、サーバ１５６はメモリ１１５から、またはエンコーダ１１０から直接、データ接続を介して要求元クライアント・アプリケーション１５８へのビデオ・データ・パケットの伝送を開始できる。制御接続を介して、ユーザは、ビデオ・データ・パケットがクライアント・アプリケーション１５８に送達される順序を変更する制御コマンド、例えば、早送り、巻き戻し、一時停止、停止解除、録画コマンドなどを発行することもできる。

本発明のサーバとクライアント・コンピュータは、コンピュータ・ネットワークを介して相互接続できる任意の数のよく知られているコンピュータを使用して実施できる。場合によっては、クライアント・コンピュータ１０４はデータを表示する特別な目的の装置、例えば、デコーダと適当なレンダラ・ソフトウェアとハードウェアを内蔵したディジタル・テレビジョン・セットを表すことがある。図２は、図１のサーバ・コンピュータ１０２またはクライアント・コンピュータ１０４を実施するのに適したコンピュータを表す例示のディジタル・コンピュータ２０２のブロック図である。ディジタル・コンピュータ２０２は、ディスプレイ画面（またはモニタ）２０４、プリンタ２０６、フロッピー・ディスク・ドライブ２０８、ハード・ディスク・ドライブ２１０、ネットワーク・インタフェース２１２、およびキーボード２１４を含むことができる。ディジタル・コンピュータ２０２は、マイクロプロセッサ２１６、メモリ・バス２１８、ランダム・アクセス・メモリ（ＲＡＭ）２２０、読出し専用メモリ（ＲＯＭ）２２２、周辺バス２２４、およびキーボード・コントローラ２２６を含む。ディジタル・コンピュータ２０２は、パーソナル・コンピュータ（Apple MacintoshなどのＡｐｐｌｅコンピュータ、ＩＢＭのパーソナル・コンピュータ、またはそれら互換コンピュータの１つ）、ワークステーション・コンピュータ（Sun MicrosystemsまたはHewlett-Packardワークステーション）、または何か別のタイプのコンピュータである。

マイクロプロセッサ２１６は、ディジタル・コンピュータ２０２の動作を制御する汎用ディジタル・プロセッサである。マイクロプロセッサ２１６は、シングルチップ・プロセッサでもよいし、多数のコンポーネントで実施してもよい。メモリから取り出した命令を使用して、マイクロプロセッサ２１６は、入力データの受信および処理と、出力装置上のデータの出力および表示とを制御する。

メモリ・バス２１８はマイクロプロセッサ２１６が使用してＲＡＭ２２０およびＲＯＭ２２２にアクセスする。ＲＡＭ２２０はマイクロプロセッサ２１６が一般記憶領域およびスクラッチ・パッド記憶として使用し、入力データおよび処理データを記憶するためにも使用される。ＲＯＭ２２２を使用して、プログラム・コード上に命令を記憶し、それに続けてマイクロプロセッサ２１６とその他のデータを記憶することができる。

周辺バス２２４を使用して、ディジタル・コンピュータ２０２が使用する入力、出力、および記憶装置にアクセスできる。この実施形態では、これらの装置は、ディジタル・コンピュータ２０２をネットワークに接続するために使用するディスプレイ画面２０４、プリンタ装置２０６、フロッピー・ディスク・ドライブ２０８、ハード・ディスク・ドライブ２１０、およびネットワーク・インタフェース２１２を含む。キーボード・コントローラ２２６を使用して、キーボード２１４からの入力を受信し、押したキーごとに復号化された記号をバス２２８を介してマイクロプロセッサ２１６に送信することができる。

ディスプレイ画面２０４はマイクロプロセッサ２１６が周辺バス２２４を介して提供した、またはディジタル・コンピュータ２０２内の他のコンポーネントが提供したデータ画像を表示する出力装置である。プリンタとして動作している時のプリンタ装置２０６は、１枚の紙または同様の表面に画像を提供する。プロッタなどのその他の出力装置をプリンタ装置２０６の代わりに、またはそれに追加して使用できる。

フロッピー・ディスク２０８とハード・ディスク・ドライブ２１０はさまざまなタイプのデータを記憶するために使用できる。フロッピー・ディスク・ドライブ２０８はそのようなデータの他のコンピュータ・システムへのトランスポートを容易にし、ハード・ディスク・ドライブ２１０は、大容量の記憶されたデータへの高速アクセスを可能にする。

マイクロプロセッサ２１６はオペレーティング・システムと共に動作してコンピュータ・コードを実行し、データを作成して使用する。コンピュータ・コードとデータはＲＡＭ２２０、ＲＯＭ２２２、ハード・ディスク・ドライブ２２０、またはネットワーク上の他のコンピュータにさえ常駐できる。コンピュータ・コードとデータはリムーバブル・プログラム媒体にも常駐でき、必要に応じて、ディジタル・コンピュータ２０２にロードまたはインストールすることができる。リムーバブル・プログラム媒体は、例えば、ＣＤ−ＲＯＭ、ＰＣ−ＣＡＲＤ、フロッピー・ディスクおよび磁気テープを含む。

ネットワーク・インタフェース回路２１２を使用して他のコンピュータ・システムに接続されたネットワークを介してデータを送受信できる。インタフェース・カードまたは同様の装置およびマイクロプロセッサ２１６が実施する適切なソフトウェアを使用して、ディジタル・コンピュータ２０２を既存のネットワークに接続して標準プロトコルに従ってデータを転送することができる。

ユーザは、キーボード２１４を使用して、ディジタル・コンピュータ２０２に入力コマンドおよびその他の命令を入力することができる。その他のタイプのユーザ入力装置も本発明と併用できる。例えば、コンピュータ・マウス、トラック・ボール、スタイラス、またはタブレットなどのポインティング装置を使用して、汎用コンピュータの画面上でポインタを操作することができる。

本発明はコンピュータ読取り可能な媒体上でコンピュータ読取り可能なコードとしても具体化できる。コンピュータ読取り可能な媒体は、その後コンピュータ・システムが読み出すことができる、データを記憶できる任意のデータ記憶装置である。コンピュータ読取り可能な媒体の例は、読出し専用メモリ、ランダム・アクセス・メモリ、ＣＤ−ＲＯＭ、磁気テープ、光データ記憶装置を含む。また、コンピュータ読取り可能なコードを分散形式で記憶し、実行できるように、コンピュータ読取り可能なコードをネットワークに接続されたコンピュータ・システムを介して配布することができる。

本発明の一実施形態によれば、エンコーダはクライアント・コンピュータに伝送する（サーバを介して）ために、ＶＸＦフォーマットでビデオ・データを符号化する。図３に、本発明の一実施形態による、ビデオ・カメラなどのソースからサーバおよびクライアント・アプリケーションに符号化されたビデオ・データを伝送するファイルを表すＶＸＦフォーマットのファイルを示す。

一般に、ＶＸＦフォーマット・ファイル３００は、ファイル３００の長さ、使用する圧縮タイプ（例えばＨＶＱ）、およびファイルに関するその他の文献情報などのデータを含むファイル・ヘッダ３０２を含む。ＶＸＦフォーマット・ファイル３００はファイル３００を符号化するのに使用するパラメータに関するデータを含む圧縮ヘッダ３０４をさらに含む。圧縮ヘッダ３０４内のデータは、例えば、クライアント・コンピュータ内のデータを復号化するためにクライアント・コンピュータのデコーダが使用することができる。

実際の符号化されたビデオ・データは複数のデータ・パケット３０６内に記憶される。データ・パケット３０６はそれぞれパケット・ヘッダ３０８とペイロード３１０を含む。ペイロード３１０を使用して任意のタイプのデータを送信できる。本開示に関しては、ペーロード３１０を使用して符号化ビデオ、オーディオ、または注釈データをサーバおよび／またはクライアント・コンピュータに送信できる。パケット・ヘッダはまたデータ・パケットが再生ストリームと早送りストリームのどちらに関連付けられているかを示すデータを含む。再生ストリームと早送りストリームの両方を提供することに関連付けられた利点は本明細書で後述する。

一実施形態では、パケット・ヘッダ３１０はまた、このデータ・パケットが再生可能、検索可能、または早送り可能であるビデオ・フレームに関連付けられているかどうかを示すデータを含む。再生可能なビデオ・フレームは、クライアント・アプリケーションがリアルタイム再生モードまたはライブ再生モードの時に表示に適したビデオ・フレームを表す。サーバは、検索可能なビデオ・フレームを使用して、検索可能なフレームを検索する際にフレームのグループを逆方向または順方向にスキップすることができる。検索可能なフレームは隣接フレームからの情報に依存せずに復号化が可能なフレームであることが好ましい。早送り可能なビデオ・フレームは、クライアント・アプリケーションが早送りモードの時に表示に適したビデオ・フレームを表す。本発明のこの態様についても後出の図４と関連して後ほど詳述する。

パケット・ヘッダ３１０は、各データ・パケットに順次割り当てられるパケット番号も含むことができる。受信したデータ・パケットに関連付けられたパケット番号のシーケンスを監視することで、クライアント・アプリケーションは所与のデータ・パケットが不明であるかどうかを（例えば、ネットワーク障害によって）確認でき、不明データ・パケットの送信を要求できる。パケット・ヘッダ３１０は、ファイル３００の先頭からのオフセット時間値を通常表すタイム・スタンプも含むことができる。一般にビデオ・レコーダおよび／またはエンコーダによって割り当てられるこのタイム・スタンプを読み取ることで、クライアント・アプリケーションは特定のデータ・パケットに関するビデオ・データをいつレンダリングするかを確認することができる。

一実施形態では、ディジタル・ビデオ・データは、Hierarchical Vector Quantization符号化技法に従って符号化されている一連の独立の（Ｉ）フレームと従属の（Ｐ）フレームに符号化される。この技法の実施は、本明細書に参照として組み込まれた、上記特許文献１に詳述されている。一般に、Ｉフレームは他のどのフレームのデータにも依存せずにビデオ・フレームに復号化するのに必要なすべてのデータを含む。他方、Ｐフレームは、それが表すビデオ・フレームと最も最近のＩフレームとの差分だけを符号化する。Ｐフレームは差分だけを符号化するため、一般により小さく、したがって、より効率的に送信して記憶できる。

本発明の一態様によれば、所与のセッションに関するビデオ・データは、ディジタル再生ストリームとディジタル早送りストリームという２つの別個のデータ・ストリームで符号化される。説明を分かりやすくするために、図４に本発明の一実施形態による再生ストリーム４００と早送りストリーム４５０の２つのビデオ・ストリームを示す。図４では、説明を容易にするために、これらのストリームは一連のビデオ・フレームで示されているが、実際には各フレームはデータ・パケットの一部あるいは１つまたは複数のデータ・パケットに乗せて送信することができることを銘記する必要がある。したがって、早送りストリームは、早送りビデオ・フレームを表す複数の基礎のデータ・パケットを含み、再生ストリームは再生可能なビデオ・フレームを表す複数の基礎のデータ・パケットを含む。

再生モードでは、再生ストリーム４００に関連付けられたデータ・パケットは、レンダラ・アプリケーションによってレンダリングされるためにサーバからクライアントに伝送される。クライアント・コンピュータは各パケット４０２〜４２４に関連付けられたパケット・ヘッダを参照してそれらが再生可能かどうかを確認する。各パケット・ヘッダは再生ストリームに関連付けられているので、各パケット４０２〜４２４が再生可能であることとを示す。レンダリングされるフレーム速度は、一実施形態では例えば秒あたり１０フレームであるが、特定のシステムの要件と機能に適合するように変更してもよい。

前述したように、本発明の一実施形態によれば、個別の早送りストリームが提供される。早送りストリームの使用は有利なことに帯域幅要件より小さいが、一方レンダラ・アプリケーションは早送りモードで早送りビデオ・フレームの品質を改善する。本発明のこの態様について説明するため、早送りストリーム４５０に言及し、この早送りストリームを再生ストリーム４００と比較する。

早送りストリーム４５０の使用について説明する前に、早送りに再生ストリーム４００が使用される場合を考えてみる。再生ストリーム４００では、Ｉフレームも再生可能なだけでなく早送りが可能である。早送りに再生ストリーム４００も使用する場合、少なくとも表示のためにＩフレームをクライアント・コンピュータに送信する必要がある。Ｉフレームに関する情報をデコーダが利用できない限り、Ｐフレームはクライアント・コンピュータで復号化できないので、Ｉフレームを送信する必要がある。この例では、Ｉフレーム４０１、４１０、および４１８が送信される。早送りの時にもＩフレーム４１０を省略できるのは当然であるが、ビデオ・クリップのこの部分を早送りするとクライアント・コンピュータでは２つのフレーム（Ｉフレーム４０２および４１８）しか使用できないので、このことは早送りビデオの表示品質に悪影響を与える、すなわち、ビデオ・クリップがぎくしゃくする可能性がある。

早送りの視覚効果は、一部のフレームが廃棄され、残りのフレームが再生ストリーム内のすべての対応するフレームをレンダリングする期間より短い期間でレンダリングされる時に達成される。この例では、Ｐフレーム４０４、４０６、４０８、４１２、４１４、および４１６が廃棄され（すなわち、サーバ・コンピュータからクライアント・コンピュータに送信されず）、Ｉフレーム４０２、４１０、および４１８が短縮された期間（例えば、再生モードでフレーム４０２〜４１８を再生するのに必要な期間の３／９）でレンダリングされる場合、早送りは再生ストリーム４００だけを使用して達成されていたであろう。

早送り効果を達成するために早送りストリーム４５０が使用される状況との比較を行う。図４では、再生ストリーム４００内のＩフレーム４０２のタイム・スタンプは早送りストリーム４５０内のＩフレーム４５２のタイム・スタンプにほぼ対応する。同様に、再生ストリーム４００内のＩフレーム４１８のタイム・スタンプは早送りストリーム４５０内のＩフレーム４６０のタイム・スタンプに時間に関してほぼ対応する。再生ストリーム４００のその他の６つのＰフレーム（４０４、４０６、４０８、４１２、４１４、および４１６）と他方のＩフレーム（４１０）内に含まれるデータは、早送りストリーム４５０の３つのＰフレーム（４５６、４５８、および４６０）内で符号化されることに注意する必要がある。早送りモードで早送りストリーム４５０が使用されると、ビデオ・クリップの同じ部分が２つのＩフレーム（４５２および４６０）と３つのＰフレーム（４５４、４５６、および４５８）内でレンダリングされる。前述したように、ビデオ・クリップのこの同じ部分は早送りに再生ストリーム４００を使用していたなら３つのＩフレーム（４０２、４１０、および４１８）を必要としたであろう。大半の場合、３つのＰフレーム（４５４、４５６、および４５８）を送信するには追加のＩフレーム（４１０）を送信する場合と比べて必要な帯域幅が狭い。これはＰフレームが前述したように差分だけを符号化するからである。したがって、早送りストリーム４５０を使用することによって、有利なことに、レンダラ・アプリケーションが早送りモードの状態で帯域幅要件が低減される。

追加の利点として、早送りストリーム４５０を使用することで、再生ストリーム４００を早送りに使用した場合のように３つのＩフレーム（４０２、４１０、および４１８）だけを使用するのではなく５つのフレーム（４５２〜４６０）でビデオ・クリップの同じ部分がレンダリングできる。当業者には明らかなように、２つの追加フレームを使用できることで、レンダリングされたビデオ・クリップのぎくしゃくする表示が低減され、したがって、よりスムーズな早送りシーケンスが実現される。

本発明の特に有利な一実施形態によれば、ライブ再生モードとリアルタイム再生モードの２つの再生モードが提供される。ライブ再生モードは、クライアント・コンピュータ側のユーザがビデオ・フレームがエンコーダから伝送される時に（サーバを介して）前記ビデオ・フレームを表示したいことを示す時のレンダラ・アプリケーションの動作モードを表す。通常、ライブ再生モードはデータ・パケットが表すイベントが記録されると前記データ・パケットをほぼ表示する（符号化と送信による多少の遅延はあるが）。ライブ再生モードでは、通常、早送りは許されない（後続のビデオ・フレームが取り込むイベントがまだ発生していないので）。

他方、リアルタイム再生モードは、クライアント・コンピュータ側のユーザがサーバ内に、すなわちディジタル・ビデオ・ファイル内にすでに記憶されているビデオ・フレームを表示したいことを示す時のレンダラ・アプリケーションの動作モードを表す。ディジタル・ビデオ・ファイルは完全に形成されているか部分的に形成されている（例えば、ユーザがライブ・ビデオ・ストリームのビデオ・フレームを超えて巻き戻した場合）。したがって、後続のフレームはすでに符号化されてサーバに事前に記憶されている可能性があるので、リアルタイム再生モードで早送りをすることは可能である。所与のライブ・ビデオ・ストリームでは、ユーザは過去に符号化され事前に記憶されているイベントを鑑賞する時にリアルタイム再生モードである可能性があることを再度指摘すべきである。ユーザが同じライブ・ストリーム上で早送りをする場合、事前に記憶されたファイルの終わりに達することがあり（ファイルは新しいビデオ・フレームが取り込まれ、符号化され、記憶されるにつれて拡大し続けている）、場合によっては、ライブ再生モードに切り替えてより最近記録されて符号化されたビデオ・フレームを表示する必要がある。

図５に本発明の一実施形態による、再生および早送りなどの一定の制御機能の実施を示す簡単な流れ図を示す。図５は一般的な場合の流れ図である。特定の制御機能は、図５の一般流れ図を参照しながら、以下の図面および本文で詳述する。ステップ５０２で、クライアントは、例えば適当なアイコンをクリックするかダイアログ・ボックスを介して対話することで、クライアント・コンピュータからコマンドを発行する。本明細書に関しては、このコマンドは例えば再生コマンドを表すことがある。再生コマンドは、通常、コマンド自体と時間パラメータとを含む。例えば、ユーザはライブ再生モードで再生することができ、この場合、時間パラメータはサーバが最も最近符号化されたフレームを表示のためにクライアント・コンピュータに伝送するためのフラグを表すにすぎない。他の例として、ユーザは時間２秒、すなわち、ビデオ・ファイルの先頭から２秒のところから再生することができる。記録セッションが２秒より長い場合（例えば、現在記録され符号化されているビデオ・フレームは５分のタイム・スタンプを備える）、時間２秒から開始するコマンドは、サーバに事前に記憶されたビデオ・フレームをレンダリングのために再び呼び出す必要があること、すなわち、レンダ・アプリケーションはライブ再生モードではなくリアルタイム再生モードで動作する必要があることを示す。

ステップ５０４で、サーバはステップ５０２の要求を満たすために送信する最初のデータ・パケットを確認する。再生コマンドに関しては、ステップ５０４は再生モードがリアルタイムかライブかによって異なる仕方で実施される。図６に、本発明の一実施形態によるリアルタイム再生モードのステップ５０４を実施するのに必要なステップを示す。上記のリアルタイム再生モードの例を使用して、サーバは再生ストリーム、すなわち図４の再生ストリーム４００上で、指定された時間の前の検索可能なフレームまで、検索可能なフレームを逆方向に検索する（ステップ５３２）。上記の例で述べたように、指定の時間は２秒である。２秒に対応するフレームが例えばＰフレーム４１４の場合、サーバは逆方向にＩフレーム４１０、すなわち、Ｐフレーム４１４の前の検索可能なＩフレームまで検索する（Ｉフレームは再生と早送りが可能なことに加えて検索可能でもある）。Ｉフレーム４１０は、ユーザが再生を開始するフレームであるＰフレーム４１４を復号化するのに必要な情報を含むので、Ｉフレームをクライアント・アプリケーションに伝送する必要がある。この場合、伝送される最初のデータ・パケットはＩフレーム４１０を表すデータ・パケットである（ステップ５３４）。あるいは、サーバは再生ストリーム上で次の検索可能なフレームを順方向に検索することができ、その結果、Ｉフレーム４１８は伝送される最初のビデオ・フレームになる。

他方、図７は、本発明の一実施形態によるライブ再生モードのための実施ステップ５０４を実施するのに必要なステップを示す。ライブ再生モードでは、ユーザは現在符号化されているビデオ・フレームから監視しようと考える。この場合、サーバは符号化ビデオ・フレームがエンコーダからサーバに送信される時に前記符号化ビデオ・フレームを監視するだけである。次にサーバに到着する検索可能なビデオ・フレーム、すなわち、次のＩフレームは、クライアント・アプリケーションに送信される最初のビデオ・フレームである。これは、このＩフレーム内の情報を使用してそれ自体と後続のＰフレームを復号化してリアルタイムでビデオ・レンダリングができるようにする（ステップ５５２）。したがって、伝送される最初のデータ・パケットは、このＩフレームを表すデータ・パケットである（ステップ５３４）。

再度図５を参照すると、サーバおよびクライアント・コンピュータはステップ５０６でバッファ、例えば、図１のサーバ・プレイアウト・バッファ１１２、再送バッファ１１８、およびクライアント・プレイアウト・バッファ１２０をフラッシュすることができる。バッファは、ユーザによる最新のコマンドの発行（クライアント・コンピュータを介した）以前に送信され、かつ／または受信されているデータ・パケットを含んでいる可能性があるのでフラッシュされる。この例に関しては、レンダラ・アプリケーションは、ユーザがライブ再生のコマンドを発行する前にはリアルタイム再生モードであった可能性があり、バッファは、事前に記憶されたビデオ・フレームに関するデータ・パケットをその中にすでに含んでおり、ライブ・ビデオ・フレームに関する新しいビデオ・フレームを送信および受信できるようにフラッシュする必要がある。

ステップ５０８で、サーバは、ステップ５０２の要求を満足するためにレンダリングする一連のパケットの最初の有効なパケット・シーケンス番号をクライアントに通知する。ステップ５１０で、サーバは、ステップ５０４で確認されたデータ・パケットから開始する複数のデータ・パケットを伝送する。最初のデータ・パケットは通常、ステップ５０８ですでに通知されているパケット・シーケンス番号を示す。クライアント・コンピュータは、受信したデータ・パケットのストリームを監視して、シーケンス番号がステップ５０８で通知されたパケット・シーケンス番号より小さい可能性があるすべてのデータ・パケットを無視する。これは、以前のモードに関連付けられた一部のデータ・パケットが中継されていて、クライアント・コンピュータに到着したばかりの可能性があることによる。クライアント・コンピュータは必要とする最初のデータ・パケットのシーケンス番号を前もって認識しているので、クライアント・コンピュータは、これらのその後到着したデータ・パケットを無視してレンダリングの前に適正なデータ・パケットを待つことしかしない可能性がある。適正なデータ・パケットがクライアント・コンピュータに到着すると、クライアント・コンピュータはステップ５０８ですでに通知されているシーケンス番号を備えたデータ・パケットからデータ・パケットのレンダリングを開始することができる（ステップ５１２）。

事前に記憶モード（またはライブ再生以外の任意のその他のモード）で再生する際、ユーザは事前に記憶されたビデオ・ファイル内の後続のビデオ・フレームまたは現在のライブ・ビデオ・フレームまで早送りすることができる。傍注として、記録するイベントがまだ発生しておらず、まして送信のためにディジタル化も符号化もされていない以上、ユーザがライブ再生モードである限りは早送りは不可能である。例えば、リアルタイム再生と早送りとの間の移行に必要なステップは、図５を再度参照すればよりよく理解できるであろう。

レンダラ・アプリケーションが現在リアルタイム再生モードの場合、ユーザによる早送りの命令によって、早送りコマンドが実行され、同時に時間パラメータがクライアント・コンピュータからサーバ・コンピュータに送信される（ステップ５０２）。一実施形態では、時間パラメータは、最も最近レンダリングされたビデオ・フレームのタイム・スタンプをサーバに示して、再生から早送りへのスムーズな移行を保証するために早送りストリームのどのビデオ・フレームを最初に送信するかをサーバが確認できるようにする。これは通常、クライアントだけが早送りコマンドの発行以前にどのビデオ・フレームが最後にレンダリングされたかを認識しているためである。サーバはまだ中継状態であり、またはバッファ内にあってクライアント・コンピュータによってレンダリングされていない他のビデオ・フレームを伝送した可能性があるので、サーバ・コンピュータはこの情報を認識していない。

ステップ５０４で、サーバは、ステップ５０２で発行されたコマンドに応答して、クライアント・コンピュータに送信する最初の早送り可能なビデオ・フレームを確認する。一実施形態では、再生ストリームが早送りに使用される。この実施形態では、最初の早送り可能なフレームは、ステップ５０２で送信された時間パラメータに対応するビデオ・フレームの時間的に直前のＩフレームを表す。あるいは、ステップ５０２で送信された時間パラメータに対応するビデオ・フレームの時間的に直後のＩフレームを最初の早送り可能なフレームとして使用してもよい。

特に有利な実施形態では、早送りに早送りストリームが使用される。リアルタイム再生モード（またはライブ再生以外のその他のモード）から早送りモードへの移行時にサーバが早送りストリームの最初のデータ・パケットを確認するために実行するステップを図８に示す。ステップ８０２で、サーバは、ステップ５０２でクライアントからサーバに送信された時間パラメータに対応するかまたは最も密に対応する時間を備えたビデオ・フレームから、早送りストリーム内で、送信する最初のフレームを逆方向に検索する。あるいは、サーバは、ステップ５０２でクライアントからサーバに送信された時間パラメータに対応するかまたは最も密に対応する時間を備えたビデオ・フレームから、送信する最初のフレームを順方向に検索することもできる。早送りストリームは、再生ストリームと同様、記録セッションがビデオ・ファイルとして進行するにつれてサーバ内に記憶される。

早送りストリームが関係する時にリアルタイム再生モード（またはライブ再生以外のその他のモード）から早送りモードへの移行に必要なステップを示すため、以下の例を考慮する。クライアントが現在リアルタイム再生モードであり、クライアント・コンピュータがレンダリングした最後のビデオ・フレームが図４の再生ストリーム４００のＰフレーム４１２であるとする。さらに、このＰフレーム４１２が６秒のタイム・スタンプを備えているものとする。ステップ５０４で、サーバは早送りストリーム４５０に切り替えて、時間が６秒に対応するかまたは最も密に対応するビデオ・フレームから逆方向に検索する（ステップ８０２）。早送りストリーム４５０のＰフレーム４５６は６秒に対応するかまたは最も密に対応するタイム・スタンプを備え、サーバは以前の検索可能なフレーム、すなわち、Ｉフレーム４５２まで逆方向に検索するものとする（早送りストリーム４５０では、すべてのＩフレームは検索可能で早送り可能である一方、すべてのＰフレームは早送り可能である）。Ｉフレーム４５２が確認されると、早送りストリーム４５０のビデオ・フレームを表すデータ・パケットは早送りビデオ・クリップとしてレンダリングされるためにクライアントに伝送される（図５のステップ５０６〜５１４）。大半の場合に、任意の所与の時間にサーバからクライアントに１つのストリーム（再生または早送り）しか送信されないことを理解する必要がある。

逆の状況では、ユーザは早送りモードから再生モードに移行することができる。早送りストリーム４５０がまだ記録されているイベントに関連付けられているとすると、移行した再生モードは早送りが再生に移行する前に（例えば、ユーザが再生ボタンまたはアイコンを押す前に）早送りストリーム４５０（サーバ内に記憶された）の終わりに到達したかどうかによって変わる。早送り時に早送りストリームの終わりに到達しなかった場合、移行した再生モードはリアルタイム再生モードである（すなわち、以前記録され記憶されたビデオ・フレームとライブ・ビデオ・フレームを対比して再生する）。これは、ライブ・ビデオ・フレームが例えば６分のタイム・スタンプを備える時に４分のタイム・スタンプを備えたビデオ・フレームから再生を開始する早送りの実行中に、ユーザが再生ボタンまたはアイコンを押したという状況である。

早送りからリアルタイム再生への移行に必要なステップは、図５を再度参照すればよりよく理解できるであろう。レンダラ・アプリケーションが現在早送りモードの場合、ユーザによる再生の命令によって、再生コマンドが実行され、同時に時間パラメータがクライアント・コンピュータからサーバ・コンピュータに送信される（ステップ５０２）。タイム・パラメータが現在のライブ・ビデオ・フレームのタイム・スタンプよりも時間的に早い場合、レンダラ・アプリケーションがリアルタイム再生モードに移行中であることが分かる。一実施形態では、時間パラメータは、最も最近レンダリングされたビデオ・フレームのタイム・スタンプをサーバに示して、早送りと再生との間のスムーズな移行を保証するために再生ストリーム４００のどのビデオ・フレームを最初に送信するかをサーバが確認できるようにする。これは、クライアントだけが通常、再生コマンドの発行以前にどのビデオ・フレームが最後にレンダリングされたかを認識しているためである（すなわち、サーバは中継状態でクライアント・コンピュータにまだ到着していないその他のビデオ・フレームを伝送した可能性があるので）。

ステップ５０４で、サーバは、ステップ５０２で発行されたコマンドに応答して、クライアント・コンピュータに送信する最初のビデオ・フレームを確認する。一実施形態では、サーバは再生ストリームに切り替えて、ステップ５０２で最初に検索可能なビデオ・フレームに対してクライアントからサーバに送信された時間パラメータに対応するかまたは最も密に対応する時間を備えたビデオ・フレームから再生ストリーム内で逆方向に（または別法では順方向に）検索する。早送りモードからリアルタイム再生モードへの移行時にサーバが再生ストリームの最初のデータ・パケットを確認するために実行するステップ（図５のステップ５０４）を、図９に示す。

以上を例示するために、クライアント・コンピュータがレンダリングした最後のビデオ・フレームは図４の早送りストリーム４５０のＰフレーム４５８で、このＰフレーム４５８は３６秒のタイム・スタンプを備えているものとする。ステップ５０４で、サーバは再生ストリーム４００に切り替え、３６秒に対応するかまたは最も密に対応する時間を備えたビデオ・フレームから逆方向に検索する（ステップ９０２）。再生ストリーム４００のＰフレーム４１６は３６秒に最も密に対応する時間を備えているとすると、サーバは再生ストリーム内の以前の検索可能なフレーム、すなわち、Ｉフレーム４１０まで逆方向に検索する（ステップ９０４）。Ｉフレーム４１０が確認されると、再生ストリーム４００のビデオ・フレームを表すデータ・パケットは、リアルタイム・ビデオ・クリップとしてレンダリングされるためにクライアントに伝送される（図５のステップ５０６〜５１４）。別法としてサーバが順方向に検索した場合、Ｉフレーム４１８はクライアントに伝送する最初のビデオ・フレームを表す。

前述したように、ライブ再生モードから早送りモードへ移行することはできない。ただし、ユーザは早送りモードからライブ再生モードへ移行することはできる（その旨をクライアント・コンピュータに直接示すか、サーバ内の早送りファイルの終わりまで早送りして事前に記憶された早送り可能なフレームを使い果たすことによって）。一実施形態では、早送りモードとライブ再生モードとの間の移行は、記憶されたビデオ・フレームのファイルの終わりに達すると自動的に実行される（すなわち、ユーザおよび／またはクライアント・コンピュータの介入なしに）。早送りモードとライブ再生モードとの間の移行に必要なステップは、図５を再度参照すればよりよく理解できるであろう。レンダラ・アプリケーションが現在早送りモードの場合、ユーザによるライブ再生の命令によって、ライブ再生モードコマンドが実行され、同時に時間パラメータがクライアント・コンピュータからサーバ・コンピュータに送信される（ステップ５０２）。一実施形態では、時間パラメータは、クライアントがライブ・ビデオを再生したいということだけを示すフラブを表すことができる。

ステップ５０４で、サーバは、ステップ５０２で発行されたコマンドに応答して、クライアント・コンピュータに送信する最初のビデオ・フレームを再生ストリーム内で確認する。一実施形態では、サーバは再生ストリーム４００の次の検索可能なビデオ・フレームを受信するまで待つだけである。この検索可能なビデオ・フレーム（通常Ｉフレーム）および再生ストリーム４００から受信した後続のビデオ・フレームは、ライブ・ビデオの表示のためにサーバからクライアントに送信される。

ライブ再生モードで、ユーザは、例えば特に面白いシーケンスを即座に再生するため、または以前にレンダリングされたビデオ・フレームまで戻ってそこから再生を再開するために、巻き戻しモードに移行できる。本発明の一態様によれば、ライブ再生ストリーム上で効率的な様式で巻き戻しができるので、これは本発明の特に有利な態様である。巻き戻しでは、クライアントに指定されたタイム・スタンプを備えたビデオ・フレームの直前のＩフレームから再生ストリームのＩフレームが逆の発生順にクライアントに送信される。

ライブ再生（またはその他の任意のモード）と巻き戻しとの間の移行に必要なステップは、図５を再度参照すればよりよく理解できるであろう。レンダラ・アプリケーションが現在ライブ再生モード（またはその他の任意のモード）の場合、ユーザによる巻き戻しの命令によって、巻き戻しコマンドが実行され、同時に時間パラメータがクライアント・コンピュータからサーバ・コンピュータに送信される（ステップ５０２）。一実施形態では、時間パラメータは、最も最近レンダリングされたビデオ・フレームのタイム・スタンプをサーバに示して、再生と巻き戻しとの間のスムーズな移行を保証するために再生ストリーム４００のどのビデオ・フレームを送信するかをサーバが確認できるようにする。これは通常、クライアントだけが巻き戻しコマンドの発行以前にどのビデオ・フレームが最後にレンダリングされたかを認識しているためである（すなわち、サーバはクライアント・コンピュータにまだ到着していない他のビデオ・フレームを伝送した可能性があるので）。

ステップ５０４で、サーバは、ステップ５０２で発行されたコマンドに応答して、クライアント・コンピュータに送信する最初のビデオ・フレームを確認する。一実施形態では、サーバは、ステップ５０２でクライアントからサーバに送信された時間パラメータに対応するかまたは最も密に対応する時間を備えたビデオ・フレームから再生ストリーム内で最初の検索可能なフレーム（Ｉフレーム）を逆方向に検索する。あるいは、サーバはステップ５０２でクライアントからサーバに送信された時間パラメータに対応するかまたは最も密に対応する時間を備えたビデオ・フレームから、再生ストリーム内で、検索可能なフレームを順方向に検索することもできる。以前のモードが早送りの場合、サーバは、巻き戻しを達成するためにクライアントに送信する最初のビデオ・フレームを確認する前に、早送りストリーム４５０から再生ストリーム４００に切り替えが可能であることを理解する必要がある。

適切なＩフレームが確認されると、サーバはクライアントが巻き戻されたビデオ・フレームを受信する準備をする（図５のステップ５０６および５０８）。その後、サーバは再生ストリーム４００のＩフレームを逆の順序で送信する（例えば、再生ストリーム４００内で以前の検索可能なフレームを逆方向に繰り返し検索し、各Ｉフレームをクライアントに送信することによって）。Ｉフレームの逆方向の送信と、クライアントでの各Ｉフレームの表示は、図５のステップ５１０および５１２で実行される。以上の説明は、この問題に関して、リアルタイム再生モードから巻き戻しモードへの、または任意のモードから巻き戻しモードへの移行の場合にも当てはまることは明らかである。

巻き戻しモードから再生モードまたは早送りモードへの移行は図５の各ステップに従うが、これについてはすでに本明細書に詳述した。一般に、クライアントが巻き戻しコマンドを送信する場合は、巻き戻し時にクライアントがレンダリングした最後のビデオ・フレームを示す時間パラメータを同時に送信する（ステップ５０４）。巻き戻しの場合、レンダリングされた最後のビデオ・フレームは、巻き戻しを容易にするために逆方向に送信された検索可能なフレーム（すなわちＩフレーム）の１つを表す。その後、サーバは、送信されたタイム・スタンプに対応するかまたは最も密に対応する時間を備えた最初の検索可能なフレームから始めて、クライアントにデータ・パケット（クライアントの移行先のモードによって再生ストリームまたは早送りストリームの）を伝送する（ステップ５０４〜５１２）。

本発明の一実施形態によれば、クライアントは他の任意のモードから停止モードに移行できる。停止モードへの移行は、現在のモードを終了して再生ストリームをビデオ・フレームの最初のビデオ・フレームにリセットする信号をサーバに送信する（例えば、サーバにゼロの時間パラメータを送信することによって）ステップを含む。停止モードから他の任意のモードへの移行は基本的に図５の各ステップを含み、その詳細は移行先のモードによって変わる。例えば、ユーザは、クライアントを介して、早送り、特定のビデオ・フレームからの再生の開始（最初に早送りするか、現在のファイル開始位置から検索することによって）、またはその他の操作ができる。

本発明の一実施形態によれば、クライアントは他の任意のモードから停止モードに移行できる。停止モードはクライアント側で表示を直ちに終了するステップと、サーバに新しいデータ・パケットの送信を停止するよう要求するステップとを含む。特に有利な一実施形態では、クライアントは、発信帯域幅をゼロに設定する信号をサーバに送信し、したがって、サーバからクライアントへのデータ・パケットの送信を停止する。ただし、図５の各ステップとは異なり、一時停止はバッファのフラッシュを含まないことに注意されたい。言いかえると、すでに送信または受信された、あるいは現在ネットワークで中継中のデータ・パケットは、保持され、クライアント・コンピュータのクライアント・プレイアウト・バッファ１２０内に継続して受信され、したがって、レンダラ・アプリケーションは一時停止解除モードに移行した時に終了した位置から直ちにビデオ・フレームのレンダリングを開始できる。

一時停止解除モードに移行すると、クライアント・コンピュータは、帯域幅をゼロ以外の値にリセットして、送信が中断した（一時停止モードに移行した時に）位置からデータ・パケットの送信を可能にする信号をサーバ・コンピュータに送信することができる。このように、クライアント・コンピュータは有利なことに、クライアント・コンピュータに関連付けられたクライアント・プレイアウト・バッファに入れられたフレームを使用して、一時停止解除の後でビデオ・フレームのレンダリングを直ちに実行することができる。ビデオ・フレームはクライアント・プレイアウト・バッファ内にすでに存在し、フラッシュされていないので、一時停止解除モードに移行する際に待ち時間はないことに注意する必要がある。さらに、サーバ・コンピュータは発信帯域幅がゼロにリセットされた時に終了した位置からデータ・パケットの送信を開始するだけなので、同期化の問題は大幅に簡単化される。さらに、一時停止解除（バッファがフラッシュされ、最も近い検索可能なＩフレームからサーバが伝送を開始する必要がある場合など）の際に不明フレームはないので、本発明の一時停止および一時停止解除技法は、最大限にスムーズな表示ビデオ・フレームを実現する。

本発明のさらに別の態様によれば、サーバから伝送されたデータ・パケットは再びサーバから再送する必要なしに、後で表示するためにクライアント・コンピュータで記憶、すなわち記録できる。例えば、録画ボタンまたはアイコンに応答して、ビデオ・フレームを表示しながら（ライブ再生またはリアルタイム再生モードで）、またはクライアント・コンピュータでフレームを表示せずにビデオ・フレームのファイルをサーバから伝送するように要求するだけで、クライアント・コンピュータはビデオ・フレームを記録できる。また、一部のクライアント・アプリケーションは、無許可の記録を防止するための機構、または例えば課金などの運用目的のために記録を追跡する機構を備えることができる。無許可の記録を禁止する機構はサーバ・コンピュータにも、またデータ・パケット自体にも備えることができることを理解する必要がある。

本発明の別の態様によれば、早送りストリームを使用して、ネットワークの利用可能な帯域幅が再生ストリーム内でのビデオ・フレームの送信をサポートするには不十分な時に狭帯域幅の再生（ライブまたはリアルタイム）を容易にすることができる。図４と本明細書の説明から分かるように、早送りストリームは、再生ストリームが要求するフレーム数よりも少ないフレームを使用して、所与のビデオ・イベントに関するビデオ・データを符号化する。ネットワークの利用可能な帯域幅が劣化すると、サーバは再生ストリームの代わりに早送りストリームを送信できる。次いでレンダラ・アプリケーションは、早送りストリームのフレームで通常使用されるフレーム速度よりも遅いフレーム速度で早送りストリームのフレームを表示して、早送りストリームの少数のフレームを再生ストリームのより多数のフレームを表示する（再生ストリームを送信したとして）のに必要な時間と同じ量の時間だけ表示できるようにする。その結果得られるビデオはよりぎくしゃくする可能性があるが、本発明のこの態様によって、ビデオ・ストリーミングは、他の方法では再生ストリーム内でフレームを適時に送信できず、再生が停止してしまう極めて限定されたネットワーク帯域幅でも継続できる。

本発明をいくつかの好ましい実施形態に関連して説明してきたが、本発明の範囲に入る変更、並べ替え、および同等の実施形態がある。例えば、説明を簡潔にするために、制御モード間の移行のすべての並べ替えのサブセットだけを本明細書に詳述しているが、本明細書の開示が与えられる当業者は、本明細書で開示された一般技法に従ってその他のモードを含む移行を実施できることは明らかである。さらに、本開示で一貫してＩフレームとＰフレームについて説明しているが、本発明はビデオ・データが一連の独立の、また従属のビデオ・フレームとして符号化される任意の符号化方式に適用されることを理解する必要がある。別の例としては、本明細書では説明を分かりやすくするためにクライアント−サーバ・コンピュータ・アーキテクチャを使用しているが、「クライアント」という用語は、他のコンピュータからデータを受信できる任意のタイプのコンピュータを示す。同様に、「サーバ」という用語は、他のコンピュータにデータを伝送できる任意のタイプのコンピュータを示す。コンピュータが広く知られている「クライアント−サーバ」アーキテクチャを使用して結合されているかどうかにかかわらず、上記の内容が当てはまる。また、本発明の方法および装置を実施する多数の代替方法があることに注意する必要がある。したがって、以下の添付の請求の範囲は、本発明の真の精神と範囲を逸脱しないそのような変更、並べ替え、および同等の実施形態をすべて含むことが意図されている。

図１Ａは、本発明の一実施形態による、本発明の伝送ビデオ表示技術を実施するのに適したコンピュータ・ネットワーク１を示す図である。 図１Ｂは、エンコーダがビデオ・データをビデオ・ソースから多数のサーバに供給する本発明の一実施形態を示す図である。 図２は、本発明のサーバ・コンピュータまたはクライアント・コンピュータを実施するのに適したコンピュータを表すディジタル・コンピュータの一例を示す図である。 図３は、本発明の一実施形態による、ソース、例えば、ビデオ・カメラからサーバおよびクライアント・アプリケーションに符号化されたビデオ・データを伝送するのに適したファイルを表すＶＸＦフォーマット・ファイルを示す図である。 図４は、本発明の一実施形態による、説明を簡単にするための再生ストリームと早送りストリームとの２つのビデオ・ストリームを示す図である。 図５は、本発明の一実施形態による、再生および早送りなどの一定の制御機能の実施を示す簡単化された流れ図である。 図６は、本発明の一実施形態による、リアルタイム再生モードで送信する第１のデータ・パケットを確認するためのステップを実施するのに必要な各ステップを示す図である。 図７は、本発明の一実施形態による、ライブ再生モードで送信する第１のデータ・パケットを確認するためのステップを実施するのに必要な各ステップを示す図である。 図８は、本発明の一実施形態による、リアルタイム再生モード（またはライブ再生以外のその他のモード）から早送りモードへの移行時に送信する第１のデータ・パケットを確認するためのステップを実施するのに必要な各ステップを示す図である。 図９は、本発明の一実施形態による、早送りモードからリアルタイム再生モードへの移行時に送信する第１のデータ・パケットを確認するためのステップを実施するのに必要な各ステップを示す図である。

符号の説明

１００ コンピュータ・ネットワーク
１０２，１５６ サーバ・コンピュータ
１０４，１５８ クライアント・コンピュータ
１０６，１５４ ビデオ・カメラ
１１０，１５２ エンコーダ
１１５ メモリ
２０２ ディジタル・コンピュータ
２０４ ディスプレイ画面（モニタ）
２０６ プリンタ
２０８ フロッピー・ディスク・ドライブ
２１０ ハード・ディスク・ドライブ
２１２ ネットワーク・インタフェース
２１４ キーボード
２１６ マイクロプロセッサ
２１８ メモリ・バス
２２０ ランダム・アクセス・メモリ
２２２ 読出し専用メモリ
２２４ 周辺バス
２２６ キーボード・コントローラ

Claims (15)

1. ライブ・ストリーム・ディジタル・ビデオ・データをクライアント・コンピュータ上に表示する方法であって、前記クライアント・コンピュータがコンピュータ・ネットワークを介してサーバ・コンピュータから前記ライブ・ストリーム・ディジタル・ビデオ・データを受信するように構成され、前記ライブ・ストリーム・ディジタル・ビデオ・データが前記サーバ・コンピュータから前記クライアント・コンピュータに、複数の独立の再生可能なビデオ・フレームと複数の従属の再生可能なビデオ・フレームを含むビデオ・フレームのストリームとして送信され、前記方法が、
   前記クライアント・コンピュータで第１のフレームビデオ・フレームを受信するステップであり、前記複数のビデオ・フレームが前記ビデオ・フレームのストリームのサブセットを表し、前記ビデオ・フレームのストリームが独立の再生可能なビデオ・フレームと従属の再生可能なビデオ・フレームとを含むことから成るステップと、
   前記複数のビデオ・フレームを前記クライアント・コンピュータに関連付けられたビデオ表示端末上に表示するステップと、の諸ステップを含み、
   前記クライアント・コンピュータから前記サーバに発行された巻き戻しコマンドに応答して、前記第１の複数のビデオ・フレームとは異なる前記ビデオ・フレームの第２の複数のビデオ・フレームを前記サーバ・コンピュータから前記クライアント・コンピュータに伝送し、前記第２の複数のビデオ・フレームが発生順と逆に配置された独立の再生可能なビデオ・フレームの少なくとも一部からなり、
   前記第２のビデオ・フレームが巻き戻された独立の再生可能なビデオ・フレームを表し、前記巻き戻された独立の再生可能なビデオ・フレームが、前記巻き戻しコマンドを発行する前記ステップの直前にレンダリングされたビデオ・フレームより時間的に前のビデオ・フレームでありかつ前記サーバ・コンピュータから前記クライアント・コンピュータに逆の発生順に送信される前記ビデオ・フレームのストリームの従属の再生可能なビデオ・フレームを表し、
   前記クライアント・コンピュータから前記サーバ・コンピュータに、前記巻き戻しコマンドの直前にレンダリングされた前記ビデオ・フレームに関連付けられたタイム・スタンプを表す時間パラメータを発行するステップをさらに含み、
   前記ライブ・ストリーム・ディジタル・ビデオ・データのコピーがディジタル・ビデオ・データ・ファイル内に記憶され、前記時間パラメータが前記サーバによって利用されて、前記巻き戻しコマンドの発行の直前にレンダリングされた前記ビデオ・フレームを前記ディジタル・ビデオ・データ・ファイル内で確認することから成る方法。
2. 前記巻き戻された独立の再生可能なビデオ・フレームの第１の独立の再生可能なビデオ・フレームが、前記ディジタル・ビデオ・データ・ファイル内で前記巻き戻しコマンドを発行する前記ステップの直前にレンダリングされた前記ビデオ・フレームから時間的に直前の独立の再生可能なビデオ・フレームを逆方向に検索することで確認される、請求項１に記載の方法。
3. 前記巻き戻された独立の再生可能なビデオ・フレームの第１の独立の再生可能なビデオ・フレームが、前記ディジタル・ビデオ・データ・ファイル内で前記巻き戻しコマンドを発行する前記ステップの直前にレンダリングされた前記ビデオ・フレームから時間的に直後の独立の再生可能なビデオ・フレームを順方向に検索することで確認される、請求項１に記載の方法。
4. 前記巻き戻しコマンドを発行する前記ステップの後に前記クライアント・コンピュータからリアルタイム再生コマンドを発行するステップをさらに含み、前記リアルタイム再生コマンドを発行する前記ステップによって第３の複数のビデオ・フレームが前記ビデオ表示端末上に表示するために前記サーバ・コンピュータから前記クライアント・コンピュータに伝送され、前記第３の複数のビデオ・フレームが、前記リアルタイム再生コマンドを発行する前記ステップの前の前記第２の複数の前記ビデオ・フレームの最後に表示されたビデオ・フレームの時間的に後のビデオ・フレームを表す、請求項１に記載の方法。
5. 前記リアルタイム再生コマンドを発行する前記ステップが、
   前記サーバによって前記ライブ・ストリーム・ディジタル・ビデオ・データのコピーをディジタル・ビデオ・データ・ファイル内に記憶するステップと、
   前記第２の複数の前記ビデオ・フレームの最後に表示されたビデオ・フレームに関連付けられた時間パラメータを発行し、前記時間パラメータを用いて、前記第２の複数の前記ビデオ・フレームの前記最後に表示されたビデオ・フレームを前記ディジタル・ビデオ・ファイル内で確認するステップをさらに含む、請求項４に記載の方法。
6. 前記第３の複数の前記ビデオ・フレームの第１のビデオ・フレームを、前記ディジタル・ビデオ・データ・ファイル内で前記最後に表示されたビデオ・フレームから時間的に直前の独立の再生可能なビデオ・フレームを逆方向に検索することで確認するステップをさらに含む、請求項５に記載の方法。
7. 前記第３の複数の前記ビデオ・フレームの第１のビデオ・フレームを、前記ディジタル・ビデオ・データ・ファイル内で前記最後に表示されたビデオ・フレームから時間的に直後の独立の再生可能なビデオ・フレームを順方向に検索することで確認するステップをさらに含む、請求項５に記載の方法。
8. クライアント・コンピュータに結合されたサーバ・コンピュータを備えたコンピュータ・ネットワーク内で、ストリーム・ディジタル・ビデオ・データの表示を制御するように構成された制御機能を実施する方法であって、前記ストリーム・ディジタル・ビデオ・データが、複数の独立のビデオ・フレームと複数の従属のビデオ・フレームを含む複数のビデオ・フレームのストリームとして、前記サーバ・コンピュータから前記クライアント・コンピュータに送信され、前記ビデオ・フレームのストリームが一意的なタイム・スタンプをそれぞれが有する複数のデータ・パケットにカプセル化され、
   前記クライアント・コンピュータによって第1制御モードから第２制御モードに移動するステップであり、前記第１制御モードが前記クライアント・コンピュータに前記ストリーム・ディジタル・ビデオ・データを特定の方式で表示するように要求し、前記第２制御モードが前記クライアント・コンピュータに前記ストリーム・ディジタル・ビデオ・データを別の方式で表示するように供給することから成るステップと、
   前記第１制御モードから前記第２制御モードへの前記移行に応答して、前記クライアント・コンピュータから前記サーバ・コンピュータに制御コマンドと時間パラメータとを送信するステップであり、前記制御コマンドが前記サーバに、前記第２の制御モードに従って、前記複数のビデオ・フレームのストリームの一部である第１の複数のビデオ・フレームを前記クライアント・コンピュータへ送信させことから成るステップと、
   前記制御コマンドに応答して、前記クライアント・コンピュータに送信する第１の独立のビデオ・フレームを前記サーバ・コンピュータによって確認するステップであり、前記第１の独立のビデオ・フレームが前記時間パラメータの関数として選択されることから成るステップと、
   前記第１の独立のビデオ・フレームから始まる前記第１の複数のビデオ・フレームを前記サーバ・コンピュータから前記クライアント・コンピュータに伝送して、前記第１の複数のビデオ・フレームを前記クライアント・コンピュータで表示させることから成るステップと、
   再送要求に応答して、サーバ・プレイアウト・バッファによって転送された前記第１の複数のビデオ・フレームの少なくとも一部を、サーバ・コンピュータからクライアント・コンピュータに再送するために再送バッファに送信するステップと、
   の諸ステップを含む方法。
9. 前記第１の制御モードが停止モードであり、前記第２の制御モードが前記クライアント・コンピュータが前記時間パラメータが指定した時間から始めてビデオ・フレームを表示するリアルタイム再生モードである、請求項８に記載の方法。
10. 前記第１の制御モードが停止モードであり、前記第２の制御モードが前記クライアント・コンピュータが前記サーバ・コンピュータに結合されたエンコーダからライブ・ビデオ・フレームを受信しながら表示するライブ再生モードである、請求項８に記載の方法。
11. 前記第１の制御モードがライブ再生モードであり、前記第２の制御モードが巻き戻しモードであり、前記ライブ再生モードが、前記クライアント・コンピュータが前記サーバ・コンピュータに結合されたエンコーダからライブ・ビデオ・フレームを受信しながら表示するモードを表し、前記巻き戻しモードが、前記クライアント・コンピュータが、前記時間パラメータに最も密に対応するタイム・スタンプを備えた独立のビデオ・フレームから始めて、逆の発生順に独立のビデオ・フレームを表示するモードを表す、請求項８に記載の方法。
12. 前記第１の制御モードがリアルタイム再生モードであり、前記第２の制御モードが早送りモードであり、前記リアルタイム再生モードが、前記クライアント・コンピュータが事前に記憶されたビデオ・フレームを表示し、前記早送りモードが前記クライアント・コンピュータが前記時間パラメータに最も密に対応するタイム・スタンプを備えた独立のビデオ・フレームから始めて早送り可能なビデオ・フレームを表示し、前記早送り可能なビデオ・フレームが前記リアルタイム再生モードの速度よりも速い速度で記録されたイベントが表示できるように構成される、請求項８に記載の方法。
13. 前記早送り可能なビデオ・フレームがビデオ・フレームの早送りストリームのビデオ・フレームを表し、前記ビデオ・フレームの早送りストリームが前記リアルタイム再生用ビデオ・フレームの再生ストリームとは異なり、前記早送りストリームと前記再生ストリームが単一の記録されたイベントから符号化される、請求項１２に記載の方法。
14. 前記第１の制御モードがライブ再生モードであり、前記第２の制御モードが一時停止モードであり、前記ライブ再生モードが、前記クライアント・コンピュータが前記サーバ・コンピュータからライブ・ビデオ・フレームを受信しながら表示するモードを表し、前記一時停止モードが、前記サーバ・コンピュータから前記クライアント・コンピュータへの前記データ・パケットの送信が前記サーバ・コンピュータの発信帯域幅をゼロに設定することによって終了されるモードを表す、請求項８に記載の方法。
15. 前記第１の制御モードが早送りモードであり、前記第２の制御モードがライブ再生モードであり、前記ライブ再生モードが、前記クライアント・コンピュータが前記サーバ・コンピュータに結合されたエンコーダからライブ・ビデオ・フレームを受信しながら表示するモードを表し、前記早送りモードが、前記クライアント・コンピュータが前記時間パラメータに最も密に対応するタイム・スタンプを備えた独立のビデオ・フレームから始まる記憶されたビデオ・ストリームの早送り可能なビデオ・フレームを表示するモードを表し、前記早送り可能なビデオ・フレームが、記録されたイベントが前記ライブ再生モードの速度よりも速い速度で表示できるように構成され、前記第１の制御モードが、前記記憶されたビデオ・ストリームの終わりに到達すると、前記クライアント・コンピュータのユーザの介入なしに前記第２の制御モードに自動的に移行する請求の範囲第８項に記載の方法。

Images