(57)【特許請求の範囲】
【請求項１】
少なくとも１つの第１通信ネットワークを介した少なくとも１つのデータサーバからのデータ要求装置であって、当該データ要求装置は、最大帯域幅レートまでサポート可能であり、
入力バッファサイズを有する少なくとも１つの入力バッファと、
少なくとも１つの第２通信ネットワークを介し前記サーバに決定されたデータの要求を送信する送信手段と、
前記第１通信ネットワークを介し前記入力バッファに前記サーバからストリーム処理されたデータを受信し、該データを利用するため、処理手段に該データを提供する受信手段と、
から構成され、
当該データ要求装置は、前記最大帯域幅レート及び前記入力バッファサイズを表す情報を抽出する抽出手段を有し、
前記送信手段は、前記サーバが前記要求されるデータの連続部分の少なくとも１つのサイズと、前記部分の２つの連続する送信ステップ間の少なくとも１つの遅延とを決定することが可能となるように、前記第２通信ネットワークを介し前記情報を前記サーバに送信することを特徴とする装置。
【請求項２】
請求項１記載のデータ要求装置であって、
当該データ要求装置は、前記入力バッファにおいて利用可能なデータを抽出し、前記処理手段が該データを利用するため、該データを中央メモリに転送するためのデータポンプを有し、
前記データポンプは、前記中央メモリのデータが該中央メモリの所定の高閾値レベルを超えたとき、一時停止制御信号を生成可能であり、
前記送信手段は、前記一時停止制御信号を前記サーバに送信する、
ことを特徴とする装置。
【請求項３】
請求項１または２記載のデータ要求装置であって、
前記データポンプは、前記入力バッファから前記中央メモリへのデータ転送が一時停止され、前記中央メモリのデータが前記中央メモリの所定の低閾値レベルまで減少すると、再開制御信号を生成可能であり、
前記送信手段は、前記再開制御信号を前記サーバに送信する、
ことを特徴とする装置。
【請求項４】
請求項２または３記載のデータ要求装置であって、
当該データ要求装置は、前記中央メモリのデータが前記中央メモリの所定の中間閾値レベルまで充填されたときのみ、前記中央メモリから前記処理手段に前記データを転送するための注入装置を有することを特徴とする装置。
【請求項５】
請求項２乃至４何れか一項記載のデータ要求装置であって、
前記中央メモリの前記閾値レベルの少なくとも１つが、当該データ要求装置と前記サーバとの間のラウンド・トリップ・タイムに依存することを特徴とする装置。
【請求項６】
請求項１乃至５何れか一項記載のデータ要求装置であって、
当該データ要求装置は、データストリーム処理の一時停止及び再開のため、及び前記決定されたデータの所与の適当な位置における位置決定のための一時停止、再開及びシーク制御信号を生成可能であり、
前記送信手段は、高速動作と逆動作の少なくとも１つの機能を可能にするため、連続する前記一時停止、シーク及び再開制御信号のシーケンスを前記サーバに送信する、
ことを特徴とする装置。
【請求項７】
請求項１乃至６何れか一項記載のデータ要求装置を有することを特徴とするデコーダ。
【請求項８】
少なくとも１つの第１通信ネットワークを介し少なくとも１つのデータサーバから、最大帯域幅レートまでサポート可能であり、入力バッファサイズを有する少なくとも１つの入力バッファを有するデータ要求装置へのデータ要求方法であって、
当該要求方法は、
決定されたデータの要求を少なくとも１つの第２通信ネットワークを介し前記サーバに送信するステップと、
前記データを利用するため、前記サーバから前記入力バッファにストリーム処理されたデータを受信するステップと、
から構成され、
当該データ要求方法は、前記サーバが前記要求されるデータの連続する部分の少なくとも１つのサイズと、前記部分の２つの連続する送信ステップの間の少なくとも１つの遅延とを決定することが可能となるように、前記最大帯域幅レートと前記入力バッファサイズを表す情報を、前記第２通信ネットワークを介し前記データ要求装置から前記サーバに送信するステップを有し、
当該データ要求方法は、請求項１乃至７何れか一項記載のデータ要求装置により実行される、
ことを特徴とする方法。
【請求項９】
少なくとも１つのデータ要求装置から決定されたデータの要求を受信する受信手段と、
前記データ要求装置に提供される前記データの連続部分の少なくとも１つのサイズを決定する仕様手段と、
前記データ要求装置に前記データ部分のストリーム処理をトリガーするストリーム処理手段と、
から構成されるデータ送信装置であって、
前記受信手段は、前記データ要求装置から前記データ要求装置の容量を表す情報を受信し、
前記仕様手段は、前記情報により前記部分サイズを決定し、
前記容量は、前記データ要求装置の入力バッファサイズと最大帯域幅レートであり、
前記仕様手段は、前記情報により前記部分の２つの連続する送信ステップ間の少なくとも１つの遅延を決定し、
前記ストリーム処理手段は、前記遅延と等しい期間により前記データ要求装置に前記部分のサイズを有する前記データ部分のストリーム処理を定期的にトリガーし、
当該データ送信装置は、請求項１乃至６何れか一項記載のデータ要求装置に対し設けられる、
ことを特徴とする装置。
【請求項１０】
請求項９記載のデータ送信装置であって、
前記受信手段は、前記データ要求装置から一時停止制御メッセージを受信し、
前記ストリーム処理手段は、前記一時停止制御メッセージの１つが受信されると、前記データストリーム処理を一時停止する、
ことを特徴とする装置。
【請求項１１】
請求項９または１０記載のデータ送信装置であって、
前記データ要求装置は、最大帯域幅レートまでサポート可能であり、入力バッファサイズを有する少なくとも１つの入力バッファを有し、
前記容量は、前記最大帯域幅レートと前記入力バッファサイズとから構成される、
ことを特徴とする装置。
【請求項１２】
請求項９乃至１１何れか一項記載のデータ送信装置であって、
前記受信手段は、前記データ要求装置から低速動作メッセージを受信し、
前記仕様手段は、前記低速動作メッセージが受信されると、前記期間の少なくとも１つの増加された値を決定する、
ことを特徴とする装置。
【請求項１３】
請求項９乃至１２何れか一項記載のデータ送信装置であって、
前記受信手段は、前記データ要求装置から高速動作と逆動作メッセージの少なくとも１つの種類のメッセージを受信し、
当該データ送信装置は、前記高速動作と逆動作の少なくとも１つに対し、前記決定されたデータにおける連続する関連位置を特定可能なパーシング手段を有し、
前記仕様手段は、前記高速動作メッセージと逆動作メッセージの１つが受信されると、前記位置における連続する位置決定に対し設けられる、
ことを特徴とする装置。
【請求項１４】
少なくとも１つのデータ要求装置から決定されたデータの要求と共に、前記データ要求装置の容量を表す情報とを受信するステップと、
前記情報により前記データ要求装置に与えられる前記データの連続部分の少なくとも１つのサイズを決定するステップと、
前記データ要求装置に前記データ部分をストリーム処理するステップと、
から構成されるデータ送信方法であって、
前記容量は、前記データ要求装置の入力バッファサイズと最大帯域幅レートであり、
前記仕様ステップは、前記情報により前記部分の２つの連続する送信ステップ間の少なくとも１つの遅延を決定することから構成され、
前記ストリーム処理ステップは、前記遅延に等しい期間により前記データ要求装置に前記部分のサイズを有する前記データ部分を定期的にストリーム処理することから構成され、
当該データ送信方法は、請求項９乃至１３何れか一項記載のデータ送信装置により実行される、
ことを特徴とする方法。
【請求項１５】
コンピュータ上での実行時に、請求項８及び１４の方法の１つのステップを実行するプログラムコード命令を有することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
本発明は、特にＶＯＤ（ビデオ・オン・デマンド）のためのデータ要求送信装置及びプロセス並びに対応するプロダクツに関する。
【０００２】
ＰＣ（パーソナルコンピュータ）に利用可能な既存の技術によると、要求元のＰＣをサーバと接続し、ＰＣのＩＰ（インターネットプロトコル）アドレスを与えることにより、インターネットを介しサーバから映像及び／または音声データ（以降では、「ＡＶデータ」と呼ぶ）をオーダすることができる。これは例えば、予告編や宣伝に適用される。ストリーミングに依存するこれらの技術は、以降における表示のため格納スペースにＡＶデータをダウンロードするだけでなく、表示されるのと同時にＡＶデータを取得することを可能にする。
【０００３】
しかしながら、そのような宣伝は、受信したデータを適切に格納及び利用するためのＣＰＵ（中央処理ユニット）処理やメモリに関するＰＣ側での対応するローカルリソースを要求する。そうでない場合には、オーバフローやデータロスなど、受信側に問題が生じる危険が相対的に高くなる。
【０００４】
サーバに格納されている選択された情報を読み込み、それをＰＣのバッファに転送することによって、そしてバッファが情報を十分に有するようになると即座に（典型的には、数秒）、データの読み込みを継続すると同時にバッファに蓄積されているＡＶデータを再生することによって、サーバからローカルネットワークを介しＰＣによりＡＶデータを取得することが知られている。
【０００５】
このような技術は、制限されたサイズのネットワークにのみ利用可能であり、ＰＣによるＡＶデータの正確な再生が格納されているサーバへの規則的かつ高速なアクセスを要するため、ＷＡＮ（ワイド・エリア・ネットワーク）には特に適していない。
【０００６】
ＪＰ２００２−２１５５１６は、データを端末にストリーミングし、そこで利用するため、端末（携帯電話機など）によってデータの各部分がサーバから逐次的に要求されるダウンロード制御方法を開示している。オーバフローを回避するため、端末に用いられているバッファメモリの利用可能な残りのサイズに基づき、端末は最大サイズの部分データの転送を繰り返し要求する。また、バッファの残りのデータ量が所定の閾値以下に低下すると、要求がサーバに送信される。
【０００７】
上記技術は端末の小さなサイズのバッファを用いたときでも、サーバの端末へのフレキシブルな適応を可能にするが、それは利用可能なスペースを計算し、サーバと通信するための繰り返しの動作を必要とする。また、サーバ側のストリーミングレート適応は、複数の端末が同時にデータを要求するときには、実行するのが困難になるかもしれない。
【０００８】
本発明は、リモートサーバからＷＡＮを介し処理、メモリ及び格納に関する必要とされる内蔵された限定的なリソースデータによって、特にＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）データのフレキシブルな取得を可能にするデータ要求装置に関する。特に、本発明の要求元装置は、そのようなサーバから再生される映画を一時停止及び抽出することを可能にするかもしれない。
【０００９】
本発明はまた、上記要求元装置に対応し、同様の効果を提供可能なデータ要求プロセス、データ送信装置及びプロセス並びにプロダクツに関する。
【００１０】
上記趣旨のため、本発明は請求項１に記載されるようなデータ要求装置に関する。
【００１１】
驚くべきことに、本発明は、ストリーミング中に受信側からサーバへの繰り返しの処理及び通信を要することなく、サーバのストリーミングが受信側のリソースに適応されることに依存する。対照的に、両者の間では単なる初期的な交渉のみで十分であるかもしれない。
【００１２】
また、本発明はサーバから複数の受信側への同時送信の間の改良された共有パスバンドを可能にするかもしれない。これは、受信側への与えられたデータ送信に対して、２つの連続するデータ部分の送信の間で、サーバは他のタスクに自由に着手できる。
【００１３】
データ要求装置により利用される第１及び第２通信ネットワークは、単一の双方向通信ネットワークから構成されるかもしれない。各種実施例において、それらはインターネットなどのＷＡＮネットワークや、企業あるいは限定的な地理的エリア（ビルなど）にローカルに利用されるネットワークやホームネットワークなどのＬＡＮネットワーク（ローカル・エリア・ネットワーク）から構成される。また、第１通信ネットワークは、要求されたデータをストリーミングするための配信ネットワークと、制御情報を送信するための双方向ネットワーク（電話リンクなど）から構成されてもよい。
【００１４】
データ要求装置は、好ましくは、従属クレーム２〜６の何れかに従う。
【００１５】
特に、一時停止制御信号に関する実施例では、データ要求装置における当該信号の生成は、特に中央メモリのオーバフローを回避するため、自動的にトリガーされたり、あるいはユーザインタフェースを介しユーザにより意図的にトリガーされるようにしてもよい。
【００１６】
また、サーバ側での一時停止後、データストリーミングの回復は所与に時間後に自動的に行われてもよいし（例えば、５分間の一時停止などの一時停止制御信号内にユーザにより送信されてもよい）、あるいは、データ要求装置から回復制御信号の送信によりトリガーされてもよい。
【００１７】
本発明はまた、本発明によるデータ要求装置と、請求項８に記載されるデータ要求プロセスとから構成されるデコーダに関する。
【００１８】
本発明はさらに、請求項９に記載されるデータ送信装置に関し、特に請求項１０〜１３の何れかに述べられる実施例の１つと、請求項１４に記載されるデータ送信プロセスに関する。
【００１９】
本発明のさらなる課題は、コンピュータ上での実行時に、本発明によるデータ送信プロセスまたはデータ要求プロセスの各ステップを実行するためのプログラムコード命令から構成されるコンピュータプログラムプロダクツである。「コンピュータプログラムプロダクツ」は、ディスケットやカセットなどのプログラムを有する格納スペースだけでなく、電気信号や光信号などに信号から構成可能なコンピュータプログラムサポートを意味する。
【００２０】
本発明は、添付した図面を参照することにより、以下の非限定的実施例によってより良く理解及び説明されるであろう。
【００２１】
図２及び３において、表示されたブロックは、物理的に分離した実体に必ずしも対応しない純粋な機能実体である。すなわち、それらはソフトウェアの形態により構成することも可能であるし、あるいは、１以上の集積回路により実現することも可能である。
【００２２】
データ送信装置１に設けられるサーバ１０（図１）は、データ要求装置２に設けられる少なくとも１つの受信機２０と第１ネットワーク５を介しデータをストリーミングすることができる。受信機２０は、第２ネットワーク６を介したリターンパスを介しサーバ１０に情報を送信可能である。例えば、第１ネットワーク５は、特に衛星、無線配信あるいはケーブルに依存する配信ネットワークであり、第２ネットワーク６は電話ネットワークである。ネットワーク５と６は共に、ＤＳＬ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｏｏｐ）通信に基づく一意的な双方向ネットワークにより構成されてもよい。
【００２３】
サーバ１０のデータ送信装置１（図２）は、
・データリクエストＲＥＱＵ、受信機２０の能力に関する情報ＩＮＦＯ、受信機側の正確な機能をチェックするためサーバ１０に定期的に送信される通常状態信号ＮＯＲＭＡＬ、データストリーミングモダリティを変更するための制御信号ＣＴＲＬ（特に、送信の一時停止または回復、低速または高速動作若しくは逆の動作を指示する）を含むメッセージを受信機２０から受信する受信モジュール１１と、
・受信機２０に与えられるべき連続するデータ部分のサイズと、情報ＩＮＦＯの機能中に当該部分の連続する２つの送信ステップの間の遅延を決定する仕様モジュール１２と（すなわち、受信機２０は、最大帯域幅レートまでサポート可能であり、入力バッファ（または複数の入力バッファ）を有し、情報ＩＮＦＯは、当該最大帯域幅レートと、当該入力バッファのサイズ（または当該入力バッファの累積サイズ）に関連する）、
・制御信号ＳＴＲＭによりデータ部分の形式により要求されたデータのストリーミングをトリガーするストリーミングモジュール１３と（データ部分のストリーミングの周期性は、クロック４１により確保される）、
・通常状態信号ＮＯＲＭＡＬの何れかが期限まで受信されないとき、受信機２０に警告メッセージＷＡＲＮを送信する転送モジュール１４と、
・警告メッセージＷＡＲＮが送信された後でも、通常状態信号ＮＯＲＭＡＬが期限までに受信されないとき、アラーム状態をトリガーするアラームモジュール１５と、
・所望の動作のための要求されたデータの連続する関連位置を特定可能であり、当該位置において連続的に位置決めを行う仕様モジュール１２と対話的に高速動作や逆動作を行うのに利用されるパーシングモジュール１６と、
から構成される。
【００２４】
受信機２０のデータ要求装置２（図３）は、
・リクエストメッセージＲＥＱＵ、情報ＩＮＦＯ、通常状態信号ＮＯＲＭＡＬ及び制御信号ＣＴＲＬをサーバ１０に送信する送信モジュール２２と、
・サーバ１０からストリーミングデータＤＡＴＡを受信し、それを入力バッファ２１（または複数の入力バッファ）に転送すると共に、サーバ１０から警告信号ＷＡＲＮを受信する受信モジュール２３と、
・例えば、映像及び音声ストリームを復号することにより、受信したデータＤＡＴＡを処理する処理モジュール２４と、
・情報ＩＮＦＯを抽出し、サーバ１０に送信するため、それを送信モジュール２２に提供可能な抽出モジュール２５と、
・入力バッファ２１から転送されたデータＤＡＴＡを、処理モジュール２４への送信前に一時的に格納する中央メモリ２６と、
・入力バッファ２１の利用可能なデータを抽出し、中央メモリ２６に転送するデータポンプ２７と、
・中央メモリ２６のデータが中央メモリ２６の所定の中間閾値レベルまで充填されると、中央メモリ２６から処理モジュール２４にデータを転送するインジェクタ２８と、
・制御信号ＣＴＲＬを生成し、サーバ１０に送信するため当該信号を送信モジュール２２に提供可能な制御モジュール３０と、
通常状態信号ＮＯＲＭＡＬを生成し、送信モジュール２２により当該信号のサーバ１０への周期的な送信をトリガーするメンテナンスモジュール３１と（通常状態信号ＮＯＲＭＡＬの送信の周期性は、クロック４２により確保される）、
・データポンプ２７に接続され、中央メモリ２６のデータが所定の高閾値レベルを超えると一時的制御信号を生成し、データストリーミングが以前に一時停止され、データが所定の低閾値に減少すると回復制御信号を生成する規制モジュール３２と、
・制御信号ＣＴＲＬをサーバ１０に供給するため、ユーザが制御モジュール３０及び送信モジュール２２をトリガーすることを可能にするユーザインタフェース３５と、
から構成される。
【００２５】
図４〜９を参照することにより詳細な具体的実施例は、上述のデータ送信装置１とデータ要求装置２の機能をより良く理解することを可能にする。
【００２６】
サーバ１０とそれぞれ２０−１〜２０−ｎにより記されるＩＲＤ（ＩＲＤ１〜ＩＲＤｎ）（各々は上述の受信機２０と同様であり、包括的に以下では参照番号「２０」が用いられる）とから構成される通信環境（図４）は、ネットワーク５及び６（同様のネットワーク）をＰＳＴＮネットワーク７として構成するＰＳＴＮ（Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）網を介し通信する。当該環境は、インターネットの世界に適合したリアル映像ストリーミングシステムを提供する。サーバ１０は、イーサネット（登録商標）リンクにより第１ＶＤＳＬ（Ｖｅｒｙ  ｈｉｇｈ  ｓｐｅｅｄ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｏｏｐ）モデム４３に接続され、各ＩＲＤは例えば、テレビ装置に関連付けされ、イーサネット（登録商標）リンクを介しスイッチ４５を介し第２ＶＤＳＬモデム４４に接続される。
【００２７】
ＶＤＳＬモデム４３及び４４は、６０Ｍｂｉｔ／ｓまでの高ビットレートを可能にする。従って、説明された通信環境は、エンドユーザがカタログから専用のプログラムを選び、不要な帯域幅を使用することなく当該プログラムの再生及び一時停止を要求するリアル・ビデオ・オン・デマンドシステムを提供する。
【００２８】
例えば、説明された通信環境は、Ｌｉｎｕｘ技術に基づきＰＣサーバ１０、ＶＤＳＬモデム４３と４４及びＩＲＤから構成されるＬＡＮ接続を有するセットトップボックス（以降では、ＳＴＢ）２０−１〜２０−ｎを有する。もちろん、Ｌｉｎｕｘ以外のオペレーティングシステムも利用可能である。
【００２９】
各ＩＲＤは要求元装置２を有する一方、サーバ１０は関連する送信装置１を有する。
【００３０】
変形として以下のようなものがあげられる。
・ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｏｏｐ）モデム技術とマルチキャスト処理が、本ＶＤＳＬモデム実施例の代わりに用いられる。一般にｘＤＳＬとは、他の可能性を提供するものである（「Ｈｉｇｈ−ｄａｔａ−ｒａｔｅ  ＤＳＬ」に対してはＨＤＳＬ、「１０Ｍｂｉｔｓ／ｓ  ＤＳＬ」に対しては１０ＭＤＳＬ、ＡＤＳＬ２など）。
・ユーザ側のイーサネット（登録商標）リンクの代わりにＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）コネクタ（バス上に直接的にある他の接続手段もまた可能である）
・第２ＶＤＳＬモデム４４に直接接続される１つのみのＩＲＤがユーザ側に存在する。
［Ａ／システム説明：特徴］
主要な要求は、映像／音声ストリームを要求することに関してユーザに供することである。本発明によると、この制限は５つまでの同時ストリームに固定される。他の実施例では、制限は異なるものであってもよいし、制限はなくてもよい。
【００３１】
テレビ装置のエンドユーザは、カタログから１つのプログラムを選択し、それを再生、停止及び一時停止／再開する機能を有する。
［Ａ１／ネットワーク］
ＡＤＳＬと同様に、ＶＤＳＬモデム４３及び４４は、実際のユーザローカル電話線を利用する。それらは、イーサネット（登録商標）またはＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）コネクタを有する。
【００３２】
伝送形式は、ＭＰＥＧ２（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）のＳＰＴＳ（Ｓｉｍｐｌｅ  Ｐｒｏｇｒａｍ  Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）であり、複数の音声情報がおそらくは言語のために伝送される。このように、ＳＴＢはこのタイプのストリームを容易に再生する機能を有する。
【００３３】
サーバ側では、ＰＣ１０はイーサネット（登録商標）１００ＢＴリンク（１００Ｂｓｅ−Ｔ）を介しモデム４３に接続される。
【００３４】
ユーザ側では、ＳＴＢ（４つまで）が、イーサネット（登録商標）１０ＢＴリンクを介し１００ＢＴ／１０ＢＴスイッチであるスイッチ４５に接続される。このとき、ユーザの何れもがホームＰＣや他の部屋のＳＴＢなどの異なる利用のためそれのＶＤＳＬラインを共有してもよい。また、スイッチを利用することにより、衝突スペースが分割され、衝突の拡散は発生しないかもしれない。
【００３５】
図示された例では、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）プロトコルスタックを超える特定のプロトコルが利用される。この手段による効果は（リンクが十分である限り）、モデムにより導入される帯域幅遅延と、イーサネット（登録商標）インタフェースが半二重の機能しか備えないＳＴＢの現在の利用性によるものであり、より複雑な効率性の低いプロトコルは必要とされない。すなわち、実験によりＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）プロトコルスタックが、いわゆる「ウィンドウ・スケール・オプション」を用いたとしてもこのネットワーク環境による真の制約を有する。
［Ａ２/サーバ１０］
Ｌｉｎｕｘに基づき、それは、
・エンドユーザのＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを設定するためのＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サーバを有し、
・ｄａｅｍｏｎとしてアプリケーションを実行し、
・各々がサーバのハードディスクドライブに基づくファイルであるプログラムのカタログへのアクセスを与え、
・開発されたプロトコルに基づきファイルをストリーミングし、
・ユーザデッド状態と共にユーザ接続／切断状態を管理する（既知のポートが使用される）。
【００３６】
サーバ１０は、効果的には、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ａｃｃｅｓｓ  Ｍｕｌｔｉｐｌｅｘｅｒ）にリンクされている中央オフィスにある。このとき、それのカタログは、効率的な方法（リフレッシュ法、キャッシュアルゴリズムなど）によりオペレータにより管理される。
［Ａ３／セットトップボックス２０−１〜２０−ｎ］
それらは、
・リストから１つのプログラムを選択し、
・「プログラム実行」ボタンを押下することにより当該プログラムを開始し、
・「プログラム一時停止／再開」ボタンを押下することにより、当該プログラムを一時停止／再開し、
・他のプログラムに移動し、
・音声及び映像を正確に復号及び同期化し、
・５Ｍｂｉｔｓ／ｓまでのフローサーバから本来の映像ビットレートを受付けることが可能である。
［Ｂ／プロトコル］
［Ｂ１／仕様］
サーバ１０及びＳＴＢ２０−１〜２０−ｎは、ＴＣＰ／ＩＰ  ＬＡＮ上で互いに接続されている。実際（図５）、ＳＴＢ２０の１つはソケットをサーバ１０に接続し、音声／映像ファイルを要求する。その後、サーバ１０は、バッファソケット１８を介しハードディスクドライバ１７から当該ファイルを以降のＳＴＢリクエストによってのみ終了されるループプロセスにおく。
【００３７】
ファイルは、ネットワーク７を介しＳＴＢ２０のソケットバッファ２１に送信される。そこから、例えば、１メガバイトのサイズのＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）により構成される中央メモリ２６に送信され、その後、ＭＰＥＧ  ＭＬＭＰ（Ｍａｉｎ  Ｌｅｖｅｌ  Ｍａｉｎ  Ｐｒｏｆｉｌｅ）バッファ５０に送信される。
【００３８】
具体的に設計されるファイル転送プロトコルは、
・利用可能なカタログに対するクエリと、
・ストリーム伝送パラメータ設定のための接続と、
・ファイルのオープン／クローズ処理と、
・クライアントのデータ使用を考慮して、ＭＰＥＧ２−ＳＰＴＳファイルのストリーミングと、
・ファイルのインデックス処理と、
・クライアントデッド状態のチェック処理と、
を可能にする。
【００３９】
プロトコルは、
・ストリーミングされたデータを転送し（このため、データリカバリは不要とされる）、
・使用されているモデムやスイッチのために衝突が発生しないことによる本システムの場合の十分なネットワーク、すなわちデータロスなく動作し、
・長いファット（ｆａｔ）パイプ、すなわち、ネットワークあるいはクライアントバッファに格納されている大量のデータにより動作するよう構成される。
【００４０】
これは、ＵＤＰを下位のプロトコルとして適切なものにする。
【００４１】
本システムは、あたかもクライアント（すなわち、ＩＲＤの１つにおいて）がネットワークにある記憶媒体からデータを要求しているかのように見られるかもしれない。
【００４２】
サーバ計算
プロトコルはＵＤＰに基づき、サーバ１０は大きな帯域幅容量を有するため、サーバはクライアントをオーバフローさせないよう配慮する必要がある。これを保証するため、設定時間においてパラメータがクライアントにより与えられる。これらのパラメータとしては、以下のものがあげられる。
・クライアントによる最大サポート帯域幅レート（ＣＢＷ）：当該レートは、全体として受信ＳＴＢ２０の機能に関するものであり、入力ソケットバッファ（おそらく、複数の入力ソケットバッファ）から受信データを抽出するレートに特にリンクするものである。
・クライアント入力ソケットバッファサイズ（ＣＳＯＣＫＢＵＦＳＺ）：入力データが共有される複数の入力ソケットバッファの場合、パラメータＣＳＯＣＫＢＵＦＳＺは、これらのバッファの累積サイズにより与えられる。
・クライアント・キープアライブ（ｋｅｅｐ  ａｌｉｖｅ）・メッセージリピート期間：そのようなメッセージは、ＳＴＢ２０が正確に動作し、ストリーミングされたデータを利用しており、それの欠落がＳＴＢの故障またはデッド状態として解釈されることをサーバ１０に警告するため、例えば、５秒ごとにＳＴＢ２０からサーバ１０に定期的に送信される。
【００４３】
サーバ１０は、これらのパラメータに従ってデータをストリーミングする。それは、要求元ＳＴＢに逐次的に送信される部分のサイズが与えられると、ソケットバッファサイズからＵＮＩＴ＿ＳＩＺＥ値を計算する。効果的な例では、当該値は、
ＵＮＩＴ＿ＳＩＺＥ＝ＣＳＯＣＫＢＵＦＳＺ／８
により与えられる。
【００４４】
係数「８」は、サーバ側において、ストリーミングされたデータを効率的に細分化するとわかっている小さなサイズの部分を有することを可能にする。すなわち、受信側におけるオーバフローの可能性は極めて低くなり、高いパーティション処理が他のストリームに関してパスバンドの共有を向上させるかもしれない。しかしながら、より小さな係数（例えば、２以下）と共に、サーバが対応可能である場合にはより大きな係数も可能である。
【００４５】
サーバ１０は、この値に対応する上限をおくデータの送信と、ＣＢＷビットレートを無効にしないように遅延の挿入をループ処理する（ＵＮＩＴ＿ＳＩＺＥ単位でループ処理する）。連続するデータ部分を送信するための期間ＰＥＲＩＯＤは、
ＰＥＲＩＯＤ＝ＵＮＩＴ＿ＳＩＺＥ／ＣＢＷ
として定義される。
【００４６】
当該期間は、典型的には、キープアライブ送信期間よりはるかに短いものである。
【００４７】
クライアント計算
ファイルをストリーミングするのに必要な帯域幅におけるホール（ｈｏｌｅ）なくデータ送信を一時停止／再開するため、クライアントにより計算される。これらのパラメータには、その処理前に入力バッファ２１から入力されるデータを一時的に格納するためのＦＩＦＯ−ＳＩＺＥのサイズのＳＴＢ２０の中央ＦＩＦＯメモリ２６の充填レベルの閾値が与えられる。一方では、低ＦＩＦＯ閾値ＬＦＩＦＯが、一時停止されたとき、ＸＯＮと呼ばれる特殊なメッセージによりデータストリーミングの再開を指示するための下方限界を与える。他方、高ＦＩＦＯ閾値ＨＦＩＦＯは、当該閾値がデータ処理にもかかわらず超過したとき、ＸＯＦＦと呼ばれる特殊なメッセージにより、サーバ１０からのデータストリーミングを一時停止するための上方限界を与える。
【００４８】
２つの閾値ＬＦＩＦＯとＨＦＩＦＯは、以下を満たすように選ばれる。
・ＬＦＩＦＯ≦ＨＦＩＦＯ
・ＦＩＦＯ＿ＳＩＺＥ−ＨＦＩＦＯ≧ＣＢＷ＊ＲＴＴ／２
・ＬＦＩＦＯ≧ＣＢＷ＊ＲＴＴ／２
ただし、ＲＴＴはラウンド・トリップ・タイムであり、パケットの送信とそれのアクノリッジメントの取得との間の遅延である（ＦＩＦＯのサイズは、ＦＩＦＯ＿ＳＩＺＥ＞ＣＢＷ＊ＲＴＴとなるよう十分大きなものである）。この時間は、設定時にクライアントにより測定され、定期的に再評価されてもよい。それは、サーバからの通信が中断されると、ネットワークに受信されるためにおそらく残るデータ量を表す。
【００４９】
入力ソケットバッファ２１
これらの入力バッファは、ＵＤＰ／ＩＰスタックにより埋め込まれる。それらは、ＳＴＢ２０を超過実行させないように十分大きなものである。サーバ１０は、クライアントソケットバッファサイズに従って、それのストリーミング部分を計算する。
【００５０】
中央ＦＩＦＯ２６
中央バッファ２６は、バースト副作用を処理するのに利用される。クライアントは、低閾値ＬＦＩＦＯと高閾値ＨＦＩＦＯとの間の値を有する中間閾値ＭＦＩＦＯである第３のＦＩＦＯ閾値により決定される十分なデータを当該ＦＩＦＯが有するときのみ、復号を開始する。処理ユニットへのデータ転送処理をトリガーする当該閾値ＭＦＩＦＯは、効率的な実施例では、低閾値ＬＦＩＦＯに等しい。上述のように、クライアントはまた、ＦＩＦＯがフルとなると（閾値ＨＦＩＦＯ）サーバストリーミングを一時停止し、ＦＩＦＯが低いとき（閾値ＬＦＩＦＯ）サーバストリーミングを再開する。
【００５１】
上記一時停止及び再開処理はそれぞれ、ＳＴＢ２０からサーバ１０に送信されるＸＯＦＦ及びＸＯＮメッセージにより実行される。同一の信号が、ストリーミング処理を一時停止し、以降においてそれを再開することを任意の時点において決定するのにクライアントにより利用されてもよい。
【００５２】
さらにここで説明される効果的な実現では、キープアライブメッセージが一時停止状態中であってもサーバにより定期的に送信及びチェックされ続ける。
【００５３】
第１の具体的実現形態では、これらの閾値は以下の値を有するように選ばれる。
【００５４】
ＬＦＩＦＯ＝ＭＦＩＦＯ＝１／４ＦＩＦＯ＿ＳＩＺＥ
ＨＦＩＦＯ＝３／４ＦＩＦＯ＿ＳＩＺＥ
である。ＦＩＦＯ＿ＳＩＺＥが１メガバイトであるとき、これは、
ＬＦＩＦＯ＝ＭＦＩＦＯ＝２５０キロバイト
ＨＦＩＦＯ＝７５０キロバイト
と与えられる。
【００５５】
このとき、データがＣＢＷ＝６Ｍｂｉｔｓ／ｓのストリーミングレートにより受信され、データ処理レートが４Ｍｂｉｔｓ／ｓに等しい符号化ビットレートＥＢＲに対応する復号化レートである場合、２秒間のストリーミング期間（ＸＯＮ）は、１秒間の一時停止期間（ＸＯＦＦ）と交互に行われる。実際、ストリーミングがオンであるとき、ＦＩＦＯの効果的な充填レートは（ＣＢＷ−ＥＢＲ）（ここでは、２Ｍｂｉｔｓ／ｓ）であり、ストリーミングがオフのときのエンプティレート（ｅｍｐｔｙｉｎｇ  ｒａｔｅ）はＥＢＲ（ここでは、４Ｍｂｉｔｓ／ｓ）である。
【００５６】
第２の具体的実現形態では、これらの閾値は以下の値を有するよう選ばれる。
【００５７】
ＬＦＩＦＯ＝ＭＦＩＦＯ＝ＣＢＷ＊ＲＴＴ／２
ＨＦＩＦＯ＝ＦＩＦＯ＿ＳＩＺＥ−ＣＢＷ＊ＲＴＴ／２
である。ＦＩＦＯ＿ＳＩＺＥ＝１メガバイト、ＲＴＴ＝１００ミリ秒であるとき、これは、
ＬＦＩＦＯ＝ＭＦＩＦＯ＝３９，３２１バイト
ＨＦＩＦＯ＝９６０，６７９バイトとなる。
【００５８】
このとき、ストリーミングレートがＣＢＷであり、６Ｍｂｉｔｓ／ｓを有し、処理レートが４Ｍｂｉｔｓ／ｓに等しいＥＢＲである場合、７．４秒のストリーミング期間が、１．８５秒の一時停止期間と交代に行われる。
【００５９】
ＭＬＭＰ  ＭＰＥＧバッファ５０
当該バッファは、ＭＰＥＧ２  ＰＥＳ（Ｐａｃｋｅｔ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）ストリームを正確に復号するために設けられる。ＳＴＢ埋め込み音声／映像デコーダスタックが利用される。メインレベル／メインプロファイルが実現される。
【００６０】
サーバ側に符号化プロセスがないため、ＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）は管理されず、ローカルＶＣＸＯ（Ｖｏｌｔａｇｅ  Ｃｏｎｔｒｏｌ  Ｃｒｙｓｔａｌ  Ｏｓｃｉｌｌａｔｏｒ）が２７ＭＨｚに設定される。何れかの方法により、映像音声ＰＴＳ（Ｐｒｏｇｒａｍ  Ｔｉｍｅ  Ｓｔａｍｐ）を用いて、音声は映像と同期される。復号化プロセスは、バッファアンダフロー耐性を有し、エラーによりＭＬＭＰバッファ５０をリセットまたはフラッシュしない。
［Ｂ２/プロトコルスタック］
図３及び４において、サーバ側からのプロトコル及びストリーミング状態遷移図がそれぞれ示される。
【００６１】
使用されるプロトコルスタックは、以下のようなものである。
【００６２】
【表１】
0004505450.tif 000002
ソケットはＵＤＰプロトコル上でオープンである。
［Ｂ３／アプリケーションプロトコル］
プロセスは以下のステップ、すなわち、
・ソケットの生成
・交換の初期化「Ｏｐｅｎ  Ｓｔｒｅａｍ」、交換「Ｗｒｉｔｅ／ｒｅａｄ  Ｓｔｒｅａｍ」、交換の終了「Ｃｌｏｓｅ  Ｓｔｒｅａｍ」から構成されるアプリケーションレイヤプロセス
・ソケットのクローズ
に分割される。
【００６３】
アプリケーションレイヤに構成されるパケットは、メッセージである。すべてのメッセージは汎用的フォーマットを有する。すなわち、
・ヘッダ：メッセージタイプ（１ロング）と、４つまでの任意的パラメータ（４ロング）
・データ：通知メッセージのためのエンプティまたはストリームの一部
である。
【００６４】
すべてのデータタイプがネットワークアライン（ｎｅｔｗｏｒｋ  ａｌｉｇｎｅｄ）、すなわち、ビッグエンディアン（ＭＳＢ（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ））である。
【００６５】
サーバ側からの主要なプロトコル処理は、以下の通りである（図６において、「ｒｅｃｖ」は「ｒｅｃｅｉｖｅ」を表す）。
・ＳＴＢの１つからメッセージを受信するため待機（ステップＳ１）
・ＳＴＢの１つから接続メッセージＣＯＮＮＥＣＴの受信（ステップＳ２）
・クライアントサーバプロセスの分岐（ステップＳ３）
・接続承認ＣＯＮＮＥＣＴ＿ＡＣＫの送信（ステップＳ４）
・ＳＴＢから接続パラメータを受信し（ステップＳ６）、パラメータを取得及び対応する計算を実行し（ステップＳ７）、及び接続メッセージを送信することによる（ステップＳ８）要求元ＳＴＢへの接続（ステップＳ５）
・要求されたＳＴＢがサーバに関して性格に留まっていることをチェックするためのクライアントデッド状態警告を開始（これは、所定の送信期間（５秒など）を有するキープアライブメッセージＫＥＥＰＡＬＩＶＥの定期的な受信を通じてチェックされる）
・関連するファイルを示すオープニングメッセージＯＰＥＮ（ｆｉｌｅ）を受信し（ステップＳ１１）、対応するファイル識別しＦｉｌｅ＿ｉｄの取得及びオープンを行うことによる（ステップＳ１２）ＳＴＢクライアントがターゲットとするファイルのオープン
・キープアライブメッセージを定期的に受信し（ステップＳ１４）、ファイル送信の終了までそれに応じて警告を再スタートしながら（ステップＳ１５）、要求元ＳＴＢクライアントにファイルをストリーミング（ステップＳ１３）
・クロージングメッセージＣＬＯＳＥを受信すると、ファイル送信を停止（ステップＳ１６）
・期限期間内にキープアライブメッセージを受信しないことにより、警告がトリガーされた場合、クライアントサーバプロセスから退出（ステップＳ１８）
サーバ側からのストリーミング処理は、以下の通りである（図７）。
・警告が再スタートするように、キープアライブメッセージが受信されると共に、ファイルが完全に送信されない限り（ステップＳ１４）、データファイルストリーミングに移行（期限期間にキープアライブメッセージを受信しないことにより、上述のように警告がトリガーされる（ステップＳ１７））
・特別な中断メッセージＸＯＦＦを受信すると（ステップＳ１９）、受信したキープアライブメッセージのチェックを継続し（ステップＳ１４）、これにより警告を再スタートしながら（ステップＳ１５）、ストリーミングを一時停止（ステップＳ２０）
・以降において特別な再開メッセージを受信すると（ステップＳ２１）、以前に中断された点からファイル送信を再開（ステップＳ１３）
・ストリーミングが現在実行されているか、あるいは一時停止されているかに関わらず、キープアライブメッセージが期限期間内に受信されていない場合、クライアントサーバプロセスから退出
当該プロセスにより、サーバ１０は、映像ストリーミングのための受信機２０の特徴に完全に適応することが可能である。さらに、当該プロセスはクライアントがストリーミングされたデータを実際に利用するのに効果的に必要な帯域幅のみを利用することができる。
【００６６】
効果的な実施例では、警告をトリガーする期限は、例えば、３または４のＲＴＴなどのラウンド・トリップ・タイムＲＴＴに応じた期間だけ増やされた予想時間により与えられる。
【００６７】
クライアント側でのストリーミングされたデータの正確な受信のサーバ側におけるチェックに関する改良では、警告はキープアライブメッセージがキープアライブ期間より有意に長い期間、例えば当該機関の３倍の期間などの間に受信されていない場合にのみトリガーされる。これは、ＳＴＢとサーバとの間の送信における可能な遅延を考慮することを可能にする。
【００６８】
チェック方法のさらなる改良によると、サーバ側においてキープアライブメッセージを受信する予想時間が経過し、そのようなメッセージが到着すると、サーバはクライアントＳＴＢに警告し、依然としてアクティブな受信状態にある場合、キープアライブメッセージを再び迅速に送り返す。これは、特にパケット損失などのネットワークにおける送信問題によるストリーミングプロセスの誤った中断の危険を大きく低下させることにより、システムの信頼性を向上させる。
【００６９】
決定的時間と警告メッセージの決定（上記特徴の両方）が効果的に組み合わされる。
【００７０】
【表２】
0004505450.tif 000003
ＩＰアドレスは一定である。
【００７１】
【表３】
0004505450.tif 000004
［ｃ／ストリームのオープン／クローズ］
【００７２】
【表４】
0004505450.tif 000005
［ｄ／ストリーミング］
【００７３】
【表５】
0004505450.tif 000006
［ｅ／交換終了及びソケットのクローズ］
【００７４】
【表６】
0004505450.tif 000007
［Ｃ／セットトップボックス２０］
ＳＴＢ２０の１つがＡＬ＿ＯＰＥＮメッセージを送信すると、それはサーバ１０がストリームデータパケットを送信するまで待機する（受信はブロックされない）。ＳＴＢ２０は、ソケットから可能な限り多くのデータを読み、スケジューリングされた注入及び復号プロセスのためＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を解放する。適切なアルゴリズムはデータポンプ２７の各スケジュールにおいてバッファソケットサイズの半分を読むことから構成されると、データポンプ２７はＳＴＢ２０に内蔵される要求元装置２の一部となる。
【００７５】
現在利用可能なＳＴＢの構成によると、最大測定保持ビットレートは約６Ｍｂｉｔｓ／ｓであり、それは良好なＭＰＥＧ２映像音声品質には十分高いものである。
【００７６】
データポンプ２７は、中央ＦＩＦＯ２６の「ライト」ポインタと当該ＦＩＦＯの連続する利用可能なスペースを入力ソケットバッファ２１に直接与える（これは、ソケットバッファからＦＩＦＯバッファへの中間的コピーを回避する）。
【００７７】
ＬｅｎＡｓｋｅｄ値により与えられる処理のための中央ＦＩＦＯ２６からの各転送期間内に取得されるデータ量は、ＦＩＦＯサイズの半分であり、作業の重いスケジューリングを回避する。そのようなＦＩＦＯ転送が実行された後、ＬｅｎＡｓｋｅｄはユーザポインタに従う連続的に利用可能なサイズとなる。要求元装置２の一部である注入装置２８は、それを管理するためのものである。
【００７８】
ユーザが１つのフローから他のフローに移行する場合、ソケット、ＦＩＦＯ２６及びビットバッファ２１はフラッシュされてもよい。
【００７９】
サーバ１０は、読み込まれたファイルを予想しない。読まれた長さと送信された長さは、一定であり、バースト伝送を回避するため、内部の入力ソケットバッファ２１（ＣＳＯＣＫＢＵＦＳＺ）より小さなものとなる。プロトコルはまた、ユーザレートに関して送信レートを規制する（ＣＢＷパラメータ：ＳＴＢ２０上のデータポンプ２７により管理される中央ＦＩＦＯ２６）。
【００８０】
ＩＲＤ処理の概要が以下で説明される（図８を参照）。説明される各種要素はＩＲＤ要求元装置の一部である。
・ザッパ（ｚａｐｐｅｒ）（「アプリ」）５４は、ユーザ入力選択（プログラム識別子）を取得し、データポンプ２７と注入装置２８を実行し、ＡＶデコーダを開始する。ユーザがプログラムを変更すると、ザッパはデータポンプ２７と注入装置２８を再び実行する前に、それらを停止する。映像デコーダは、停止される必要はない。
・イーサネット（登録商標）ドライバ５２は、例えば、Ｃｉｒｒｕｓ  Ｌｏｇｉｃなる企業による「ＣＳ８９００Ａ」として販売されているものなどの物理的イーサネット（登録商標）コントローラ５１とＴＣＰ／ＩＰスタック５３との間のインタフェースを行う。当該レートは、３〜６Ｍｂｉｔｓ／ｓからなる。従って、当該レートが４Ｍｂｉｔｓ／ｓである場合、１つのフレーム（１４６０バイト）は２．８６ミリ秒で処理される。中断プロセス（ＩＴ）が、制御データ送信をドライバ５に警告するため与えられる。
・ＴＣＰ／ＩＰスタック５３は、ソケット非ブロッキングＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を備えるイーサネット（登録商標）上のＴＣＰ／ＵＤＰ／ＩＰスタック５３である。ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）クライアントが、ＩＰアドレスを動的に取得するため埋め込まれる。ＴＣＰ／ＩＰスタック５３は、最大で６４キロバイトを有するソケットバッファ２１とタイマ４２を利用する。
・データポンプ２７は、サーバ１０からＭＰＥＧ２−ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）を取得するため、ＵＤＰポートを使用する。動作において、ファイル識別子がユーザにより指定され、接続中にサーバ１０に直接送信される。サーバ１０と接続されると、データポンプ２７は利用可能なＦＩＦＯ長を読み、ＦＩＦＯ２６がほとんどフルになったとき（ＨＦＩＦＯ閾値）、データストリーミングを一時停止し（ＸＯＦＦメッセージ）、ＦＩＦＯ２６がほとんどエンプティになったとき（ＬＦＩＦＯ閾値）、それを再開するようサーバ１０に依頼する。それはまた、ユーザがＦＩＦＯ２６をフラッシュするよう移行することを可能にする。このとき、フラッシュ方法は、注入装置２８に伝搬される。
・中央ＦＩＦＯ２６は、ＸメガバイトＦＩＦＯ（例えば、１メガバイトなど）であり、復号処理及びストリーミング処理を規制し、ネットワークバーストを処理するのに利用される。ＦＩＦＯマネージャは、注入プロセスをそれぞれトリガー及び一時停止する高低のＬＦＩＦＯとＨＦＩＦＯ、及びデータポンプ処理をトリガーする中間のＭＦＩＦＯの３つの閾値を管理する。
【００８１】
送信のため、例えば、３２キロバイトの単位サイズが選ばれる（５０キロバイトの単位サイズでは、送信に２０ミリ秒かかる）。すなわち、４Ｍｂｉｔｓ／ｓのレートを考慮すると、中央ＦＩＦＯ２６を充填には２秒間かかり、フルのＦＩＦＯは２秒間の復号化に対応する。
【００８２】
サーバファイルにおいて８キロバイトのブロックをとると、クライアントソケットバッファに到着するのに１６ミリ秒かかる。同じデータが、ＳＴＢに埋め込まれたＣＰＵに応じて、およそ２〜４ｋｂｙｔｅｓ／ｍｓｅｃのレートでＦＩＦＯ２６に伝送される。従って、ＳＴＢ伝送プロセスは無視できる。
【００８３】
中央ＦＩＦＯ２６は、サーバ１０及びネットワークから可能性のあるジッタを吸収する。好ましくは、クライアントの帯域幅レートＣＢＷは、符号化レートＥＢＲより大きい。ＥＢＲとＣＢＷの値がクローズしている場合、ＦＩＦＯ２６はより小さなものとなるかもしれない。
・注入装置２８：ＰＣサーバ１０（生成装置）と復号処理（ユーザ）との間のフロー制御の観念が計算される。スタートされると、注入装置２８は映像ビットバッファレベルを調査し、ＳＷＴＳ（Ｓｏｆｔｗａｒｅ  Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）入力５６を用いてＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）を介しＴＳＭＵＸ（トランスポート・ストリーム・マルチプレクサ）５５に与えられた量のＦＩＦＯデータを注入する。このとき、中央ＦＩＦＯ２６は、十分なデータを有する必要がある。
・ＴＳＭＵＸ５５：ＳＴマイクロエレクトロニクスなる企業によるＳＴ５５１６として販売されているものと同様のレジスタ６１（図９）に基づき、当該インタフェースは、（設定レジスタ６３を用いて）ＳＷＴＳモードによりメモリからＰＴＩ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｔｒａｎｓｐｏｒｔ  Ｉｎｔｅｒｆａｃｅ）５７へのデータの注入を可能にする。それは、データをそれの内部の３２ビットＳＷＴＳ  ＦＩＦＯ６２に一時的に格納し、ＰＴＩ５７にストリーム処理する。バイト伝送のスピードは、調整可能である。ペースレートは、例えば、４０Ｍｂｉｔｓ／ｓである。
・ＡＶスタック５８：音声映像復号プロセスは、復号化の対象となるＰＩＤ（Ｐａｃｋｅｔ  ＩＤｅｎｔｉｆｉｅｒ）に対する復号プロセスを設定することを可能にする。それは、復号プロセスの開始を可能にすると共に、映像ビットバッファレベル（ＶＢＢＬと記す）を示すことを可能にする。ビットバッファは、アンダフロー耐性を備える。
・ＡＶ同期化は、映像及び音声からのＰＴＳ（Ｐｒｏｇｒａｍ  Ｔｉｍｅ  Ｓｔａｍｐ）値に基づく。２７ＭＨｚのＶＣＸＯが固定されたコマンド値を有するように、ＰＣＲは管理されない。映像復号処理が開始され、第１映像ＰＴＳによりＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）値が初期化される。音声は、それのＰＴＳ値がＳＴＣ値の近傍となるまでフレームをスキップする。
［Ｃ１/注入装置２８］
注入装置２８とその機能が詳述される（図９を参照して）。
【００８４】
ＳＷＴＳ入力５６へのデータの注入は、ＰＴＩ「ＤＭＡ３」チャネルを介し送られるＳＷＴＳ＿ＲＥＱ信号を用いて制御される。このＳＷＴＳ＿ＲＥＱ信号は、内部のＳＷＴＳ  ＦＩＦＯ６２が少なくとも１６バイトのスペースを有するときアサートされる。ＳＷＴＳ＿ＲＥＱがローであり、ＸメガバイトのＦＩＦＯ２６から読み出されるデータが存在するたびに、プログラム可能ないくつかのバイトがＳＷＴＳ入力５６に転送される。転送が完全に完了すると、データの転送が完了したことを注入装置のタスクに通知するため中断が設定される。
【００８５】
ＳＷＴＳのエントリの場合、送信先ポインタはそれぞれ６４及び６５として記される映像及び音声圧縮データＦＩＦＯに備えられる。当該注入はＣＤ＿ＦＩＦＯと同様に処理される。ＳＷＴＳレジスタアドレスはＣＤ＿ＦＩＦＯアドレスを置換し、ＰＴＩ＿ＤＭＡ３ＳＥＴＵＰレジスタによってインクリメントが直接的にプログラムされない（従って、ＤＭＡ３ＢＬＯＣＫＭＯＶＥ＝０）。
【００８６】
ＰＴＩ５７バージョンドライバ
ＰＴＩドライバは、ＤＭＡ注入のソフトウェアサポートを提供することができる。それは、ＰＴＩ１後方互換モードで用いられるＰＴＩ３ハードウェアにおいて実行される。提示された実施例では、中断モードはＤＭＡ転送の終了を通知できないという制限があるのみである。すなわち、ｐｔｉ＿ｄａｔａ＿ｄｍａ＿ｓｙｎｃｈｒｏｎｉｚｅ機能の呼び出しは、ＤＭＡ転送の終了までブロックする。
【００８７】
ＴＳＭＵＸ５５とＰＴＩ  ＤＭＡ３との相互接続
ＳＷＴＳ＿ＲＥＱ信号が、ＣＯＮＦＩＧ＿ＣＯＮＴＲＯＬ＿Ａレジスタを設定することにより（すなわち、ＰＴＩＡ＿ＣＤＲＥＱ３＿ＭＵＸＳＥＬ［３：０］＝ＴＳＳＵＢ＿ＳＷＴＳ＿ＲＥＱ）、ＰＴＩＮＯＴ＿ＣＤＲＥＱ３信号に多重化される。
【００８８】
注入装置のタスクは、ＰＴＩ５７へのデータの注入前に、それぞれ６６と６７により記される映像及び音声ビットバッファの占有レベルを知る必要がある。各ストリームが映像及び音声コンポーネントを含み、音声ビットバッファ６７のキャパシティがオーバフロー及びアンダフローを避けるのに十分であるということをサポートする場合、映像ビットバッファレベルのみを監視することが許容される。
【００８９】
これを行うため、２キロビット（２５６バイト）の単位により映像ビットバッファ６６の現在レベルを与えるＶＩＤ＿ＶＢＬレジスタが読み込まれる。このとき、当該バッファのフリースペースのサイズは、迅速に減少する。注入装置のタスクは、ＴＳＭＵＸ５５を介しユーザ中央ＦＩＦＯ２６からＰＴＩ５７へのＤＭＡ転送を開始する。この転送のサイズは、ｍｉｎ（ＲＶＢＢ，中央ＦＩＦＯ利用可能データ）であり、ＲＶＢＢ（Ｒｅｍａｉｎｉｎｇ  ｓｐａｃｅ  ｉｎ  Ｖｉｄｅｏ  Ｂｉｔ  Ｂｕｆｆｅｒ）は、ＶＢＢ（Ｖｉｄｅｏ  Ｂｉｔ  Ｂｕｆｆｅｒ）６６の残っているフリースペースを表す。
【００９０】
従って、転送はＶＢＢ６６のみを考慮することにより計算される。このことは、ＡＢＢ（Ａｕｄｉｏ  Ｂｉｔ  Ｂｕｆｆｅｒ）６７がオーバフローしないくらい十分大きいことを意味する。
【００９１】
４Ｍｂｉｔｓ／ｓ（５００ｋｂｙｔｅｓ／ｓ）のフローに対し、５０キロバイトのデータの転送は、１００ミリ秒ごとに添付する。４０Ｍｂｉｔｓ／ｓ（５Ｍｂｙｔｅｓ／ｓ）に固定されたＳＷＴＳペースレートによると、転送時間は少なくとも１０ミリ秒かかる。従って、対応するスレッドは各転送間に９０ミリ秒スリープする。
［Ｃ２/音声／映像スタック５８］
音声／映像スタック５８は、３つの主要な機能を有する。すなわち、
・逆多重化の設定と音声及び映像デコーダの始動
・音声と映像の間の同期化の管理
・データストリーミングの制御、映像ビットバッファレベルの取得及び注入装置クライアントに対するそれの供給
映像を一時停止またはフリーズ、音声のミュート化あるいは静止画像の表示を行う必要はない。
【００９２】
映像デコーダからの音声の同期化は、音声ＰＴＳ及び映像ＰＴＳにより行われる。フローからのＰＣＲは管理されず、ＶＣＸＯは２７ＭＨｚに設定される。
【００９３】
ＳＴＣ値は、第１映像ＰＴＳにより設定される。同期アルゴリズムがすでに音声ドライバに存在する。映像ＰＴＳによりＳＴＣを設定するため、機能を変更することのみが必要とされる。これは以下のように処理可能である。
【００９４】
映像ＰＴＳを視聴することは、ストリームにエラーが生じた場合（ＳＴＣ／映像ＰＴＳ距離が、ＰＴＳの発生のたびに更新される）、中断されない。
【００９５】
スタックはまた、ビットバッファアンダフローに関して耐性を有し、すなわち、復号化プロセスもビットバッファもリセットされない。
【００９６】
ビットバッファ（ＶＢＢ６６とＡＢＢ６７）は、ＰＵＬＬモデルに対して正確にサイズがとられ、すなわち、デコーダプロセスはデータストリーミングを調整する。ＶＢＢ６６に関して、それは約３５６キロバイトのＭＬＭＰ構成に対してサイズがとられる。ＡＢＢ６７のサイズをとるため、最小映像ビットレートと最大映像ビットレートとの間の比率が計算される。この比率はＡＢＢ６７のサイズ決定するため以下のように適用される。
【００９７】
ＡＢＢサイズ＝ＭＡＢＲ／ｍＶＢＲ＊（ＭＬＭＰ  ＶＢＢサイズ）
ここで、ｍＶＢＲは最小映像ビットレートを表し、ＭＡＢＲは最大音声ビットレートを表す。
【００９８】
例えば、ｍＶＢＲとＭＡＢＲはそれぞれ、１Ｍｂｉｔｓ／ｓと４４８ｋｂｉｔｓ／ｓである。
【００９９】
追加的な構成として、クライアントはサーバ１０に低速または高速動作のための制御メッセージを送信するようにしてもよい。
【０１００】
低速動作に対する実施例では、データ部分を送信する期間ＰＥＲＩＯＤはより長いものとされ（周期性の変更は、クライアントにより要求された低速化レベルに依存する）、キープアライブメッセージの周期性は不変に維持される。
【０１０１】
高速動作及び逆動作の実施例の変形では、クライアントはさらに、ストリーミング対象となるデータファイルの位置決定を指示するための特定の制御メッセージＳＥＥＫをサーバ１０に送信することが可能であり、それは当該ファイルの開始または終了に関するいくつかのバイトであるかもしれない。このとき、ＳＥＥＫメッセージは、再生スピードと選ばれたデータのデータ量を取得し、高速動作の場合にアンダフローを補償するため、方向とオフセットの両方を含むものであってもよい。その場合、送信される指示のシーケンスは、ＸＯＦＦ／ＳＥＥＫ（方向，オフセット）／ＸＯＮ／ＸＯＦＦ．．．となる。
【０１０２】
さらに、当該実施例では、例えば、クライアントは復号化のためＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅ）のＩタイプの画像のみを取得するため、高速動作のための選ばれた復号化アルゴリズムに関する情報をサーバ１０に送信する。
【０１０３】
このとき、クライアントは適切な位置の決定を通じて、確実な再生を担当する。
【０１０４】
また低速動作と同様に、キープアライブメッセージの周期性は不変に保持される。
【図面の簡単な説明】
【０１０５】
【図１】図１は、本発明によるデータ送信装置を有するサーバと、本発明によるデータ要求装置を有する受信機とに関する通信環境を示す。
【図２】図２は、図１のデータ送信装置のブロック図である。
【図３】図３は、図１のデータ要求装置のブロック図である。
【図４】図４は、要求装置がＩＲＤ（Ｉｎｔｅｇｒａｔｅｄ  Ｒｅｃｅｉｖｅｒ  Ｄｅｃｏｄｅｒ）に備えられ、送信装置がＰＣサーバに備えられる図１の通信環境の特殊な実施例を示す。
【図５】図５は、図４の通信環境におけるストリーミングに関するパイプ及びバッファを表す。
【図６】図６は、サーバ側からの図４の通信環境におけるプロトコル状態遷移図である。
【図７】図７は、サーバ側からの図４の通信環境におけるストリーミング状態遷移図である。
【図８】図８は、図４のＩＲＤの処理概要を表す。
【図９】図９は、図４のＩＲＤの１つにおける注入装置の機能を示す。
【図１】
0004505450.tif 000008
【図２】
0004505450.tif 000009
【図３】
0004505450.tif 000010
【図４】
0004505450.tif 000011
【図５】
0004505450.tif 000012
【図６】
0004505450.tif 000013
【図７】
0004505450.tif 000014
【図８】
0004505450.tif 000015
【図９】
0004505450.tif 000016