(57)【特許請求の範囲】
【請求項１】
送信器と、クロックと、受信器と、ネットワークユニットとを備えた装置であって、
前記送信器は、複数のデータストリームを複数の受信装置へ送信し、データパケットを前記複数の受信装置のそれぞれへ送信するように構成され、
前記クロックは、前記装置が前記データパケットを送信する時に使用され、前記複数の受信装置へ送信された複数のデータパケットのそれぞれに対する第１タイムスタンプを与えるように構成されており、
前記受信器は、前記送信されたデータパケットに応答して前記複数の受信装置からの返送データパケットを受信し、前記各返送データパケットは、前記受信装置による前記送信されたデータパケットの受領に関する第２タイムスタンプと、前記受信装置による前記返送データパケットの送信に関する第３タイムスタンプとを含み、前記装置は、前記受信装置から前記返送データパケットを受信すると、第４タイムスタンプを提供するように構成され、
前記装置のオペレーションを指令する前記ネットワークユニットは、前記受信装置へ送信される前記複数のデータストリームのうちの各データストリームをデコードするため、前記複数の受信装置のそれぞれに関する開始時間を決定するよう構成され、前記開始時間は、前記返送データパケットに関する前記第１、第２、第３及び第４タイムスタンプに少なくとも部分的に基づいており、
前記各受信装置のそれぞれに関する開始時間の決定は、
前記装置に対する前記受信装置のフェーズオフセットを、前記受信装置からの返送データパケットの前記第１、第２、第３及び第４タイムスタンプに基づき決定すること、
前記複数の受信装置のそれぞれに関するデータパケット送受信の際の往復遅延時間を、それぞれの前記返送データパケットの前記第１、第２、第３、および第４タイムスタンプに基づき決定すること、
前記複数の受信装置のそれぞれに関するデータパケット送受信の際の前記往復遅延時間、及び前記複数の受信装置のそれぞれに関するデコーダ待ち時間に少なくとも部分的に基づく初期デコード時間を、前記受信装置のすべてのために決定すること、
前記受信装置の開始時間を発生するため、前記受信装置すべてのための前記初期デコード時間に、前記受信装置に関する前記フェーズオフセットを加えること、を含んでいることを特徴とする装置。
【請求項２】
前記装置のタイムスタンプは前記装置のクロックに基づいており、前記各受信装置のタイムスタンプは前記各受信装置のローカルクロックに基づいている、請求項１に記載の装置。
【請求項３】
前記装置は、各受信装置において、前記複数の受信装置のそれぞれに関する各データストリームのデコードのために確立された開始時間を用いて、複数の関連データストリームのデコードを同期させる、請求項２に記載の装置。
【請求項４】
前記複数の受信装置に関する前記初期デコード時間の決定は、前記複数の受信装置のそれぞれに関するデータパケットの送受信の際の往復遅延時間に基づく前記複数の受信装置のデータパケットの送信及び返信に関する最大往復遅延時間の決定を含む、請求項１に記載の装置。
【請求項５】
前記装置と前記各受信装置との間のフェーズオフセットの決定は、前記受信装置に関する第１タイムスタンプと第２タイムスタンプ間の差＋前記受信装置に関する第３タイムスタンプと第４タイムスタンプ間の差を２で割って算出される、請求項１に記載の装置。
【請求項６】
前記受信装置すべてのためのデコード時間の決定は、前記受信装置それぞれのバッファ情報に基づく最大バッファ値と、前記受信装置それぞれに関するデコーダー待ち時間情報に基づくデコード前の最小バッファ量とを更に含む、請求項１に記載の装置。
【請求項７】
前記各受信装置に関する返送データパケットは、前記受信装置のバッファ情報を更に含む、請求項６に記載の装置。
【請求項８】
前記各受信装置の返送データパケットは、更に、前記受信装置に関する前記デコーダ待ち時間情報を含む、請求項７に記載の装置。
【請求項９】
前記各データストリームはメディアデータのストリームを含む、請求項１に記載の装置。
【請求項１０】
前記複数の受信装置は、前記複数のデータストリームの同期に関して互いに通信を行わない、請求項１に記載の装置。
【請求項１１】
受信装置は、前記受信装置のバッファのレベルに基づいて前記受信装置のクロックのレートを変更する、請求項１に記載の装置。
【請求項１２】
複数の受信装置に対する複数の関連データストリームを同期させる方法であって、
送信装置から、前記複数の受信装置の各受信装置へ送信するためのパケットを準備するステップであって、前記複数の受信装置の各受信装置は、前記複数の関連データストリームのうちの１つのデータストリームを受信し、
前記送信装置から前記各受信装置へ前記パケットを送信する際に第１タイムスタンプを与えるステップと、
前記受信装置へ送られるパケットに応答して各受信装置からの返送パケットを受信するステップであって、前記返送パケットは、前記受信装置による前記パケットの受領に関する第２タイムスタンプと、前記受信装置による前記返送パケットの送信に関する第３タイムスタンプとを含んでいる当該ステップと、
前記各受信装置からの返送パケットを前記送信装置で受信すると、第４タイムスタンプを提供するステップと、
前記受信装置からの前記返送パケットのタイムスタンプの前記第１、第２、第３及び第４タイムスタンプに少なくとも部分的に基づいて前記各受信装置に対する開始時間を前記送信装置によって決定するステップであって、前記各受信装置に対する開始時間を前記送信装置によって決定することには、
前記装置に対する前記受信装置のフェーズオフセットを、前記返送パケットの前記第１、第２、第３、及び第４タイムスタンプに基づき決定すること、
前記複数の受信装置のそれぞれに関するデータパケット送受信の際の往復遅延時間を、それぞれの前記返送データパケットの前記第１、第２、第３、及び第４タイムスタンプに基づき決定すること、
前記複数の受信装置のそれぞれに関するデータパケット送受信の際の前記往復遅延時間、及び前記複数の受信装置のそれぞれに関するデコーダ待ち時間に少なくとも部分的に基づく初期デコード時間を、前記受信装置のすべてのために決定すること、
前記受信装置の開始時間を発生するため、前記受信装置すべてのための前記初期デコード時間に、前記受信装置に関する前記フェーズオフセットを加えること、
を含む当該ステップと、
を含む方法。
【請求項１３】
前記複数の受信装置に関する開始時間に基づき前記複数のデータストリームの同期を与えるステップを更に含む、請求項１２に記載の方法。
【請求項１４】
前記複数の受信装置のそれぞれからバッファ情報及びデコーダ情報を受信するステップを更に含み、前記受信装置のすべてに関する初期デコード時間の決定は、前記バッファ情報及びデコーダ情報の使用を含む、請求項１２に記載の方法。
【請求項１５】
前記デコード時間は、現在時間と、全ての受信装置に対して充分なネットワーク待ち時間と、全ての受信器のバッファを、処理を開始するに充分なレベルに充填するに要する時間と、全ての受信器のバッファを、デコーダ待ち時間を与えるに充分なレベルに充填するための時間とに基づくものである、請求項１２に記載の方法。
【請求項１６】
前記複数のデータストリームは、複数のメディアデータストリームを含む、請求項１２に記載の方法。
【請求項１７】
前記複数のデータストリームのうちの第１データストリーム及び第２データストリームは、オーディオ又はビデオデータストリームのコピーである、請求項１６に記載の方法。
【請求項１８】
第１データストリームは、ビデオデータストリームであり、第２データストリームは、そのビデオデータストリームに関連したオーディオデータストリームである、請求項１６に記載の方法。
【請求項１９】
前記送信装置と前記各受信装置との間のフェーズオフセットの決定は、前記受信装置に関する第１タイムスタンプと第２タイムスタンプ間の差＋前記受信装置に関する第３タイムスタンプと第４タイムスタンプ間の差を２で割って算出される、請求項１２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、一般的に、ネットワークの分野に係り、より詳細には、相互接続ネットワークにおいて関連データストリームを同期させる方法及び装置に係る。
【背景技術】
【０００２】
ネットワークは、パーソナル電子娯楽装置のような複数の装置を相互接続したものを含むことがある。このようなネットワークでは、相互接続された装置は、データの関連ストリームの共有を含めて、データを共有することができる。送信装置は、複数の装置へストリーミングされるべきデータを含む。一例において、送信装置は、１つ以上のディスプレイ装置により表示するか又は他の使用のためにストリーミングされるべき動画又は他のオーディオ／ビジュアルデータのようなメディアデータのセットを含むか又はそれにアクセスする装置であり、ディスプレイ装置は、おそらく、ビデオを表示するスクリーン、オーディオを発生するスピーカ、又はその両方を含む。用語の簡単化のために、ストリーミングされるデータの使用は、そのようなデータの「表示」と称され、そしてそのようなデータを使用する装置は、「表示装置」又は「受信装置」と称される。
【０００３】
このようなネットワークでは、データの表示を同期させる必要がある。同期のクオリティは、このようなデータの使用、及び不一致表示に対する受信者の敏感さに依存する。この環境内での共通のシナリオは、表示を同期させるという要件で、単一ソースから複数の行先へ複数のメディアストリームを配信することである。受信装置がメディアデータを表示し且つ表示が互いに視覚又は聴覚内にある場合に、見る人又は聞く人が表示装置間の表示時間差に気付かないほど同期が充分厳密であることが要求される。
【０００４】
例えば、ビデオサーバーは、ストリームを、周囲サウンドのデコーディングのためにオーディオ受信器へ且つビデオの表示のために個別のデジタルテレビジョンへ送信することがある。このケースでは、適切な表示のために装置間に適切な唇同期を維持しなければならない。第２の例は、同じメディアストリームを複数のデジタルテレビジョンへ配布することである。このケースでは、各ストリームに対するオーディオ及びビデオのデコーディングは、単一装置内で遂行されて装置に対する適切な唇同期を確保するが、全てのストリームが同期されるよう確保するには複数の表示を互いに整合させねばならない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、同期は、一般的に、装置間に比較的厳密な整合及び通信を要求する。この同期プロセスは、メッセージング及び処理に著しいオーバーヘッドを要求することがある。パーソナル娯楽装置を含む低リソース装置を相互接続するネットワークのような限定ネットワークでは、このような装置間整合及び通信を与えることが困難である。
【課題を解決するための手段】
【０００６】
相互接続ネットワークにおいて関連データストリームを同期させるための方法及び装置が提供される。
【０００７】
本発明の第１の態様では、装置は、データストリームを第２装置へ送信するための送信器を備え、この送信器は、データパケットを第２装置へ送信する。装置は、更に、クロックを備え、装置は、データパケットを送信する際にデータパケットに対する第１タイムスタンプを与える。装置は、第２装置から返送パケットを受信する際に第２タイムスタンプを与え、返送パケットは、第２装置によりパケットを受信及び送信するためにタイムスタンプを含む。ネットワークユニットは、第２装置によりデータストリームをデコードするための開始時間を、少なくとも一部分はパケットに対するタイムスタンプに基づいて決定する。
【０００８】
本発明の第２の態様では、装置は、第２装置からのデータを受け取るための受信器と、クロックとを備え、装置は、第２装置から同期パケットを受信する際に第１タイムスタンプを、そして返送同期パケットを送信する際に第２タイムスタンプを与える。装置は、データストリームのデータを保持するためのバッファを備え、このバッファは、第２装置からのデータストリームに対する開始時間に達したときに流出を開始する。装置は、更に、データストリームをデコードするためのデコーダを備えている。
【０００９】
本発明の第３の態様では、関連データストリームを同期させる方法は、第１受信装置へ送信すべきパケットを準備することを含み、その第１受信装置は、関連データストリームの少なくとも第１データストリームを受信する。パケットを送信する際に第１タイムスタンプが与えられ、返送パケットを受信する際に第２タイムスタンプが与えられ、返送パケットは、更に、第１受信装置によりパケットを受信するためのタイムスタンプ、及び第１受信装置により返送パケットを送信するためのタイムスタンプを含む。第１受信装置に対する第１の開始時間が、パケット及び返送パケットのタイムスタンプに少なくとも一部分基づいて決定される。
【００１０】
本発明の実施形態は、同様の要素が同じ参照番号で示された添付図面を参照して、一例として説明するが、これに限定されない。
【図面の簡単な説明】
【００１１】
【図１】複数の受信装置へ配信されるデータストリームの実施形態を示す。
【図２】位相関係を決定するためのプロセスの一実施形態を示す。
【図３】ある実施形態において同期をとるために受信装置により与えられるデータを示す。
【図４】送信器が関連データストリームを同期させるためのプロセスの実施形態を示すフローチャートである。
【図５】受信器が関連データストリームを同期させるためのプロセスの実施形態を示すフローチャートである。
【図６】娯楽ネットワークの実施形態を示す。
【図７】ネットワーク装置の実施形態を示す。
【図８】ネットワーク装置のコンポーネントの実施形態を示す。
【発明を実施するための形態】
【００１２】
本発明の実施形態は、一般的に、相互接続ネットワークにおいて関連データストリームを同期させることに向けられる。
【００１３】
ここで使用する「関連データストリーム」とは、任意の仕方で互いに関連している同じデータストリーム又は異なるデータストリームの複数の態様を意味する。１つの例では、複数の表示装置に向けられる単一のビデオデータストリームが、関連データストリームをなす。第２の例では、同じ又は異なる表示装置に向けられるビデオデータストリーム及びオーディオデータストリームが、関連データストリームをなす。
【００１４】
ここで使用する「娯楽ネットワーク」とは、（音楽、オーディオ／ビデオ、ゲーム、写真、等を含む）デジタルメディアコンテンツを装置間に配信するための相互接続ネットワークを意味する。娯楽ネットワークは、パーソナル娯楽ネットワーク、例えば、家庭用のネットワーク、業務設定の娯楽ネットワーク、又は娯楽装置の他のネットワークを含む。このようなネットワークでは、あるネットワーク装置は、メディアコンテンツのソース、例えば、デジタルテレビジョンチューナ、ケーブルセットトップボックス、ビデオ記憶サーバー、及び他のソース装置である。他の装置は、メディアコンテンツを表示又は使用するもので、例えば、デジタルテレビジョン、ホームシアターシステム、オーディオシステム、ゲームシステム、及び他の装置である。更に、ある装置は、メディアコンテンツを記憶又は転送するように意図されたもので、例えば、ビデオ及びオーディオ記憶サーバーである。ある装置は、複数のメディアファンクションを遂行することができる。ある実施形態では、ネットワーク装置は、単一のローカルエリアネットワーク上の同じ位置にある。他の実施形態では、ネットワーク装置は、例えば、ローカルエリアネットワーク間のトンネルを通して複数のネットワークセグメントに広がる。娯楽ネットワークは、複数のデータエンコード及び暗号化プロセスを含む。
【００１５】
ある実施形態では、ネットワークにおける複数の関連データストリームが同期される。ある実施形態では、送信装置と各受信装置との間の位相差を決定し、そして適用可能な位相差に少なくとも一部分基づいて各受信装置のオペレーションを調整することによって、データストリームが同期される。ある実施形態では、送信装置と受信装置との間の位相差は、少なくとも一部分は、受信装置へデータパケットを送信し、返送されるデータパケットを受信し、そしてデータパケットに対して収集されたタイムスタンプを使用することにより、決定される。ある実施形態では、データストリームの同期は、更に、受信装置のオペレーションに関する情報も使用する。
【００１６】
ある実施形態では、プロセスの複雑さを最小にしながら、人間の使用又は操作にとって充分なクオリティとなるようにストリームの同期を維持するためのプロセスが提供される。又、ある実施形態では、単一チップ解決策のように低リソース装置内で具現化することのできる同期プロセスが提供される。
【００１７】
図１は、複数の受信装置へ配信されるデータストリームの実施形態を示す。この図において、ネットワーク１０５は、複数の装置を含み、そのような装置間で関連データストリームが転送される。データストリームは、メディアストリームデータを含むが、それに限定されない。例えば、送信装置１１０が、特定のデータストリーム（１つ又は複数）１３０を、複数の受信装置、例えば、受信装置Ａ  １１５、受信装置Ｂ  １２０及び受信装置Ｃ  １２５へ配信することが要求される。データストリーム（１つ又は複数）１３０は、一例においては、複数の位置に表示されるべきオーディオビジュアルデータストリームであるか、又は一緒に表示されるべきオーディオストリーム及びビデオストリームである。位置が１人の個人により観察されるに充分なほど接近している場合に、その個人は、表示が同期されていないことに気付く。しかしながら、装置が異なり、各装置への距離が異なることがある。このために、一般的に、受信装置間には未知のサイズの位相差が生じる。ある実施形態では、各受信装置に対してデータストリームを同期するためのプロセス又はシステムが提供される。
【００１８】
ある実施形態では、システムは、データストリーミングのために「プッシュモデル」を使用する。又、ある実施形態では、単一ソースが相互接続ネットワークを経て単一の行先へメディアストリームを配信する。この環境において、送信器クロック、受信器クロック及びデコーダクロックの３つの関連クロックドメインがある。プッシュモデル実施形態では、送信器は、他の装置に関わらず既知のレートで受信器へメディアストリームを送信し（従って、データを受信器へプッシュし）、受信器からのフィードバックは要求されない。受信器は、ネットワークを通しての可変待ち時間を吸収するために到来するストリームに対してバッファを維持し、そしてストリームデータをデコーダへ転送し、このデコーダは、ストリームからクロックを回復し、そしてそのクロックを標準ＰＬＬ及びＶＣＯ技術によりロックする。このクロック回復は、受信器がストリームデータをデコーダへ配信するレートに基づき、これは、次いで、ストリームレート及び受信器のローカルクロックに基づく。
【００１９】
この例では、デコーダがストリームからクロックを適切に回復できるようにするために、受信器は、「リーキーバケット(leaky bucket)」プロセス又は同様のプロセスを具現化する。ストリームパケットがネットワークから到着するにつれて、それらは、（ネットワークジッタを吸収するために）受信器によってバッファされ、次いで、そのローカルクロックに基づく均一なレートでデコーダへ配送される。受信器クロックは、送信器クロックとは異なるので、受信器がバッファを流出させるレートは、周期的に調整される。このような調整がないと、バッファは、最終的にアンダーフロー又はオーバーフローとなる。
【００２０】
ある実施形態では、標準レート一致技術を使用して、受信器のバッファが流出されるレートを制御することができ、様々な技術が考えられる。このプロセスでは、バッファの深度がモニタされ、平滑機能が適用される。時間と共に、受信器のクロック周波数が送信器のクロック周波数に一致されるというのが有効な結果である。これは、受信器と送信器との間のフィードバック又は通信を必要とせずに、受信器が、送信器により決定されたレートでストリームを再生することを保証する。
【００２１】
ある実施形態では、受信器バッファのサイズは、変化する条件に対して調整することができる。バッファのサイズは、吸収できるネットワークジッタの量、及びレート一致アルゴリズムが有効である時間周期を決定する。大きなバッファは、ネットワーク変動を吸収するための良好な結果を与えるが、この効果は、オペレーションにおける初期待ち時間のコストで発生する。従って、バッファのサイズは、設計上の兼ね合いである。
【００２２】
ある実施形態では、ディスプレイのような装置間の位相関係が対処される。単一ソースから単一行先へメディアストリームのようなデータストリームを送信するための上述したプッシュモデルは、３つのクロック（送信器、受信器及びデコーダ）を同じ周波数に有効にロックさせて、滑らかなデコーディング及び再生を確保する。送信器が、次いで、同じストリーム（又はその異なる部分）を複数の行先に配送する場合には、全てのクロックのレートが、単一行先のケースと同様に、同じ周波数にロックされる。従って、ストリームは、時間と共に離れるようにドリフトしない。
【００２３】
しかしながら、装置のクロック位相は異なる。特に、各ストリームは、第１パケットを受信する時間、バッファ待ち時間及びデコーダ待ち時間に基づいて、実時間の異なる点でデコーディングを開始する。ある実施形態では、全ての関連ストリームの受信器が同時にデコーディングを開始するよう確保するための付加的なメカニズムが設けられる。これは、送信器からの受信器クロックの位相オフセットを決定することを必要とする。
【００２４】
ＮＴＰ（ネットワークタイムプロトコル）又はイーサネットＡＶ（オーディオビデオ）のようなクロック同期技術は、同じ位相を有するように全てのクロックをセットするのに使用できるが、データストリームにとって重要なのは初期オフセットだけであるから（ソースに対するレート一致が長期間ドリフトを防止するので）、これは必要ではない。ある実施形態では、送信器と各受信器との間の単純な一連のタイムドパケット交換により位相差が評価される。ストリームが開始されるときに瞬時位相差を決定することは、複数のストリーム間に適切な同期を確保するのに充分である。
【００２５】
図２は、位相関係を決定するためのプロセスの一実施形態を示す。この図において、送信器２０５は、ローカルクロック２１０を有し、そして受信器２１５は、ローカルクロック２２０を有する。ある実施形態では、送信器２０５は、受信器２１５へパケット２２５を送信する。送信器２０５は、パケット２２５が出発するときにそのローカルクロック２１０に基づいてタイムスタンプＴs0２３０を挿入する。パケット２２５が受信器２１５に到着すると、受信器のクロック２２０に基づき新たなタイムスタンプＴr1２３５がパケット２２５に挿入される。パケット２２５は、次いで、送信器２０５へ返送され、パケット２２５が出発するときに、受信器のローカルクロック２２０に基づいて第３のタイムスタンプＴr2２４０が挿入される。最終的に、パケット２２５が送信器２０５に戻ると、送信器のクロック２１０に基づいて第４のタイムスタンプＴs3２４５が注目される。ある実施形態では、これらの値は、２つのクロック間の位相差を決定するために少なくとも一部分使用される。
【００２６】
ネットワーク装置に使用されるもののような近代的なクロックは、非常に高精度であり、典型的に、公称周波数との相違は、１００ｐｐｍ（パーツ・パー・ミリオン）以下であり、これは、約１００μｓ／秒の最大スキューを意味する。メディアストリームのようなデータストリームの状況では、このスキューは、一般的に、取るに足らないもので、安全に無視することができる。従って、２つのクロック間の位相関係を確立するために、２つのクロックの周波数が同一であると簡単に仮定するのが安全である。より詳細には、往復遅延δは、次のように決定される。
δ＝(Ｔs3−Ｔs0)−(Ｔr2−Ｔr1)                             [1]
【００２７】
同様に、受信器クロックに対する送信器クロックのオフセット（即ち、受信器クロックに対して等価な時間を得るために送信器クロックに加算される時間）は、次のように決定される。
0005624468.tif 000002
但し、送信器の時間は、次の式により特定受信器の時間へと変換される。
0005624468.tif 000003
【００２８】
一実施形態では、位相オフセットの決定は、往復遅延δが対称的であるという仮定に基づく。しかしながら、実際には、ネットワークジッタが予想不能であり、従って、位相オフセットは、往復遅延の半分δ／２以内の精度となる。ステレオサウンドのような緊密に結合されたオーディオではなくメディアストリーム同期の場合には、人間は、一般的に、８０ｍｓまでのスキューは我慢できると分かっている。従って、δ／２＜８０ｍｓであれば、位相オフセットは、受け容れられる性能を生じる。位相オフセットは、送信器と各受信器との間のこのプロセスにおいて決定され、受信器と受信器との間ではないので、受信器と受信器との間の最大スキューは、加算的である。従って、受信器と受信器との間の受け容れられるストリーム同期は、往復遅延が人間の許容スレッシュホールドの半分未満であるとき、ひいては、δ／２＜４０ｍｓであるときに、達成できる。
【００２９】
ある実施形態では、前記情報を使用すると、送信器と各受信器との間の位相オフセットを決定するための手順は、往復遅延が適切な範囲内になるまで繰り返される。ターゲット環境がローカルネットワークである具現化では、位相決定の繰り返しが実際に僅かな制約に過ぎず、過渡的バースト又はノイズに対処するだけでよい。
【００３０】
送信器に対する受信器クロックの位相オフセットの最終的コンポーネントは、受信器においてメディアストリームデコーダを通る待ち時間である（待ち時間とは、データパケットが、結果データを送出するまでにメディアストリームデコーダにより保持される期間である）。例えば、ＭＰＥＧ（ムービングピクチャーエクスパートグループ）デコーダは、その内部バッファ要件のために付加的な待ち時間を追加することがある。ある実施形態では、この余計な遅延を考慮するために、受信器は、タイムドパケット要求に応答してこの値を含ませる。
【００３１】
送信器及び受信器におけるタイムドパケット要求の処理オーバーヘッドは、非常に変動しがちである。それ故、ある実施形態では、システム又はプロセスは、タイムドパケットレスポンダを、束縛された既知の遅延をもつハードウェア状態マシンとして具現化する。同様に、送信器におけるパケット進入及び退出タイムスタンプをハードウェアにより発生して、タイムスタンプの精度を改善することができる。タイムスタンプの発生がハードウェアにより遂行されない実施形態では、クロック間の位相オフセットを決定するときに、付加的なエラー補償が要求される。しかしながら、エラーを、人間の許容範囲（例えば、サウンドの位相差に対する人間の許容範囲）内に束縛するだけでよい実施形態では、ハードウェアサポートが要求されなくてもよい。
【００３２】
ある実施形態では、付加的なデコーディング待ち時間と共に各受信器クロック間の位相差が分かると、送信器は、データストリームの表示又は他の使用を一致させるために、各ストリームのデコーディングの開始を各受信器にいつ命令すべきか非常に正確に決定することができる。しかしながら、一般的に、各受信器は、ネットワークの待ち時間を吸収するために異なるバッファ要件を有する。ある実施形態では、送信器は、受信器が受信器の最大デコーダ待ち時間を考慮するために将来のデコード時間をセットする。
【００３３】
図３は、ある実施形態において同期のために受信装置により与えられるデータを示す。ある実施形態では、クロックタイムスタンプ及びデコーダ待ち時間と共に、各受信器は、タイムドパケット要求に応答してそのバッファ情報を含ませる。これは、最小値又はローウオーターマーク(low water mark)、即ちデコーディングを開始できるまでにバッファされねばならないストリームの最小量と、最大値又はハイウオーターマーク(high water mark)、即ちバッファすることのできるストリームデータの最大量とを含む。
【００３４】
例えば、図３も、ローカルクロック１２０をもつ受信器１１５を示す。ある実施形態では、受信器１１５は、送信器によって与えられた送信タイムスタンプＴs0１３０を含むパケット１２５を受信する。パケット１２５が受信器１１５に到着すると、受信器のクロック１２０に基づく新たなタイムスタンプＴr1１３５がパケット１２５に挿入される。ある実施形態では、受信器１１５は、受信器１１５のデコーダ３７５に対する待ち時間値３５０（デコーダが、結果データを送出するまでデータパケットを保持する期間を示す）を与える。ある実施形態では、受信器１１５は、受信器１１５のバッファ３８０に記述するためのバッファ情報３６０を更に与える。ここに提供される発明は、ハイウオーターマーク３６５（バッファすることのできるストリームの最大量）と、ローウオーターマーク３７０（デコーディングを開始できるまでにバッファされねばならないストリームデータの最小量）とを含む。パケット１２５は、次いで、送信器１０５へ返送され、そしてパケット１２５が出発するときに、受信器のローカルクロック１２０に基づいて別のタイムスタンプＴr2１４０が挿入される。
【００３５】
ある実施形態では、全ての受信器を同期させるために、送信器は、受信器に対する初期デコード時間をセットする。ある実施形態では、デコード時間は、現在時間、全ての受信器にとって充分なネットワーク待ち時間、処理を開始するに充分なレベルまで全ての受信器のバッファを充填するに要する時間、及びデコーダ待ち時間を与えるに充分なレベルまで全ての受信器のバッファを充填する時間に基づくものである。ある実施形態では、デコード時間は、現在時間と、（予想ネットワーク遅延を考慮するための）全受信器にわたる最大往復遅延の半分と、全受信器の最大ローウオーターマークまでバッファを充填するに要する時間と、全受信器の最大デコーダ待ち時間までバッファを充填するに要する時間との和であるように決定される。
ＴDECODE＝ＴCURRENT＋δMax／２＋ＴMaxLowWM＋ＴMaxDecLat        [4]
時間ＴDECODEは、送信器のクロックに対して式４で決定される。その値は、式３に従い各受信器クロックに対する等価な時間へ変換される。
【００３６】
受信器におけるバッファサポートが許す場合には、エラーの余裕を減少する助けとして付加的な初期待ち時間が追加されてもよい。一実施形態では、開始時間が、ハイウオーターマークを越えるバッファ要件に対応する場合には、ストリームを中断するか、又は同期性能低下のおそれはあるが要件を緩和することもできる。
【００３７】
ある実施形態では、送信器は、各受信器クロックに基づいて開始時間を決定し、開始時間は、式４から得られるＴDECODE値と、所与の受信器に対する適当なオフセットとの和である。
0005624468.tif 000004
【００３８】
送信器は、開始時間（受信器のクロックに基づく）、第１パケットのシーケンス番号、及びパケットレートを、そしてそれに続いてストリームデータを、各受信器へ送信することにより、データストリームを開始する。このプロセスにおいて、送信器は、ストリーム開始情報を受信器へ確実に配送して適切なデコーディング及び同期を保証するように確保する。
【００３９】
ある実施形態では、データストリームを受信する各受信器は、到来するストリームを、受信器のクロックに基づく開始時間に達するまでバッファし、そしてその時点で、受信器は、バッファを流出させてストリームデータをデコーダへ配送し始める。次いで、受信器は、上述したように振る舞う。幾つかのストリームデータパケットがストリームの始めから失われた場合には、受信器は、ストリームパケットレート及び第１の使用可能なシーケンス番号に基づいて、ストリームをデコードし始めるまでに、どれほど長く遅延するかを決定することができる。
【００４０】
図４は、送信器が関連データストリームを同期させるプロセスの実施形態を示すフローチャートである。この図において、データストリームに対する要求が受け取られる。関連データストリームに対して複数のデータ受信器がない場合には（４０４）、ある実施形態では、送信器は、同期をとらずにデータストリームを開始する（４３０）。複数のデータ受信器がある場合には（４０４）、データのデコーディングを同期するプロセスが続く。このプロセスでは、受信器へ送信するための同期パケットが準備される（４０６）。第１タイムスタンプがデータパケットに挿入され（４０８）、データパケットが受信器へ送信される。次いで、送信器は、受信装置から返送パケットを受信し（４１２）、パケットが受信されるときに第２のタイムスタンプを与える（４１４）。データパケットは、更に、パケットの到着及び送信に対して受信装置からのタイムスタンプを含み、そして更に、デコーダ待ち時間情報及びバッファ情報を含む。このようなデータを使用して、送信器は、受信器に対する往復遅延が、送信器におけるデータパケットの送信と到着との間の時間差から、受信器におけるデータパケットの到着と送信との間の差を差し引いたものに等しいことを決定する（４１６）。その決定された遅延がスレッシュホールド内にない場合には（４１８）、変化するネットワークジッタが余計な遅延を生じさせることを示し、遅延の決定が繰り返される。遅延がスレッシュホールド内である場合には（４１８）、タイムスタンプ値に基づいて位相オフセットが決定される（４２０）。対処すべき受信器が更にある場合は（４２２）、同期プロセスが繰り返される（４０６）。さもなければ、各受信器によるデコーディングの開始時間が決定される。一実施形態では、デコード時間は、現在時間と、受信装置に対する最大往復遅延の半分と、受信装置に対する最大ローウオーターマークの時間と、受信装置に対する最大デコーダ待ち時間との和として決定される（４２４）。次いで、特定受信装置に対する開始時間は、デコード時間を受信装置のオフセット
0005624468.tif 000005
ウオーターマークに対する時間より大きい（従って、バッファのオーバーフローを生じる）場合には、問題に対処するアクションが取られ（４２８）、例えば、特定の受信装置へのストリームを中断し、又は同期要件を緩和する。受信装置が使用可能な開始時間を有するか、さもなければ、同期に対処できる場合には、各受信装置に対してデータストリームを開始することができる（４３０）。
【００４１】
図５は、受信器が関連データストリームを同期させるプロセスの実施形態を示すフローチャートである。この図において、受信器でデータストリームを受信する要求がある（５０２）。関連データストリームに対して複数のデータ受信器がない場合には（５０４）、ある実施形態では、受信したデータをバッファし（５０６）、そして最小量のデータがバッファされたときにデコーダへデータを配送する（５０８）ことを含めて、同期をとらずに、データストリームが開始する。関連データストリームに対して複数のデータ受信器がある場合には（５０４）、データ受信器は、送信器から同期パケットを受信する（５１０）。受信器は、受信の際にパケットに第１タイムスタンプを挿入させる（５１２）。受信器は、送信器へ返送するためのパケットを準備し（５１４）、受信器のデコーダの待ち時間に関する情報をパケットに挿入し（５１６）、そして受信器のバッファに関する情報を挿入する（５１８）。受信器は、パケットが送信器へ送信されて戻されるときに（５２２）、第２タイムスタンプを挿入する（５２０）。
【００４２】
受信器は、次いで、デコーダへのデータの配送を開始する開始時間を含めて、データストリームを開始するためのインストラクションを受け取る（５２４）。データストリームを開始すると（５２６）、受信器は、受信したデータをバッファし始める（５２８）。バッファ動作（５２８）は、受信器に対する開始時間に到達する（５３０）まで続けられ、この点において、受信器は、バッファからデータを流出し（５３２）そしてそのようなデータをデコーダへ配送する（５３４）ことを開始する。
【００４３】
図６は、娯楽ネットワークの実施形態を示す。娯楽ネットワークの要素は、複数の装置への関連データストリームを同期させるのに使用される。この図において、娯楽ネットワークシステム６００は、互換性のあるメディア装置をネットワークに接続する。接続は、娯楽ネットワーク６０５への接続として示されている。ある実施形態では、装置は、中央ネットワークサーバーをもたないネットワークとして動作する。娯楽ネットワークを通して、メディアデータストリームは、接続された任意の装置間で転送される。更に、装置は、ネットワークを通して遠隔制御することができる。装置は、同軸ケーブル、イーサネットケーブル、及びファイアワイヤを含む既知のコネクタ及び接続プロトコルを経てネットワークに接続されると共に、Ｗｉ−Ｆｉ、ブルーツース、及び他のワイヤレス技術を経てワイヤレス接続部へ接続される。
【００４４】
ある実施形態では、装置は、メディアソース又は受信者を含む。図６において、オフィス６１０は、モデム６２２を経てネットワーク６０５へインターネット接続６２０を与える。インターネットから受信されるデータは、ストリーミングメディアソースを含み、これは、購入したオーディオファイル（ダウンロードされた音楽ファイルのような）、ビデオファイル（映画、テレビ、等の）、及びコンピュータゲームを含むが、これらに限定されない。又、オフィス６１０は、パーソナルコンピュータ６２４にも接続され、これは、他のファンクションの中でも、あるメディアストリームを表示し又はあるコンピュータゲームを動作するモニタ６２６を使用する。
【００４５】
又、娯楽ネットワークは、ベッドルーム６１２内の装置にも接続され、これは、例えば、テレビジョン６３２へデータを与えるセットトップボックス６３０を含む。更に、ベッドルーム（又は他のスペース）は、メディア記憶ユニット６２８を含む。このメディア記憶ユニット６２８は、ネットワーク６０５に接続されたソースからデータを受信し、且つネットワーク６０５へ接続されたデータ受信者へデータを与える。メディア記憶装置６２８は、ネットワークに対していかなる形式のメディアストリームデータを含んでもよい。
【００４６】
このシステムは、更に、ケーブル又はファイバシステム６３４から、或いは衛星ディスクネットワーク６３６から入力を受信するリビングルーム６１４も備えている。このようなソースからのメディア入力は、ネットワーク６０５及び第２テレビジョン６４０に接続されたセットトップボックス６３８へ供給される。リビングルームのテレビジョン６４０に表示するためにネットワーク６０５に接続されているのは、ビデオゲームユニット６４２である。ネットワーク装置をもつ多数の他の部屋があり、例えば、ネットワーク６０５に接続された第３テレビジョン６４４を含むキッチンがある。又、これに限定されないが、家全体に配置されたスピーカを含むステレオオーディオシステムを含む他のネットワーク装置も存在する。
【００４７】
更に、多数の移動パーソナル電子装置もネットワークに接続される。これらの装置は、ケーブル又はワイヤレス信号を経て接続され、ワイヤレス信号は、ブルーツース、Ｗｉ−Ｆｉ、赤外線又は他の同様のワイヤレス通信プロトコルを含むが、これに限定されない。このような各々のプロトコルは、（図６には示されていない）ネットワークへのインターフェイス、例えば、Ｗｉ−Ｆｉベースステーションを必要とする。このような移動パーソナル電子装置は、デジタルカメラ６４６、セルラー電話６４８、パーソナル音楽装置６５０、又はビデオカメラ６５２を含むことができる。更に、自動車６５４に収容された移動システムは、自動車がネットワークに接近したときに（例えば、家のガレージに入ったときに）ネットワーク６０５に接続することができる。移動パーソナル電子装置は、例えば、ネットワークの範囲内に入ったときにネットワークに自動的に接続される。接続時に、装置は、装置への考えられる自動更新又はダウンロードを含めて、ネットワークを通してデータを得るか、又はネットワークへデータを供給するのに使用できる。一例において、ユーザは、ネットワークを通していずれかの移動電子装置に含まれたデータにアクセスすることができ、例えば、セットトップボックス６３８を経て、リビングルームのテレビジョン６４０のデジタルカメラ６４６に記憶された写真にアクセスすることができる。ある実施形態では、図６に示すネットワーク装置は、ネットワーク処理及びバッファ能力に限度があるように設計された低リソース装置である。
【００４８】
図７は、ネットワーク装置の実施形態を示す。ある実施形態では、ネットワーク装置７０５は、１つの物理的ネットワークインターフェイス、例えば、イーサネットＭＡＣアドレスを伴うエンティティである。図７に示すように、ネットワーク装置は、２つのネットワークインターフェイス７１０及び７１５を備えている。従って、ある実施形態では、ネットワーク装置は、物理的エンティティである。又、ある実施形態では、ネットワーク装置は、１つ以上のエージェントを含み、各エージェントは、ネットワーク装置に常駐する論理的エンティティである。ネットワーク装置には複数のエージェントがある。例えば、図７は、ネットワーク装置７０５を示し、ネットワークインターフェイス７１０は、通信マネージャー７２０を経てエージェント７３０、７３５及び７４０にアクセスし、通信マネージャー７２５を経てエージェント７４５及び７５０にアクセスし、且つネットワークインターフェイス７１５は、通信マネージャー７２８を経てエージェント７５５及び７６０にアクセスする。ある実施形態では、各エージェントには、ネットワーク装置ＩＰアドレスとは独立して、装置のリセットオペレーションにわたり、それを他のエージェントから区別するためのグローバルに独特の識別子が指定される。このように、エージェント７５５に意図されたコマンドが、エージェントに対する独特のアドレスに宛てられ、次いで、メッセージは、ネットワークインターフェイス７１５を経てエージェント７５５へ向けられる。
【００４９】
ある実施形態では、エージェントは、ネットワーク装置内の通信のエンドポイントとして働き、特定セットの能力及び関連振舞いを与える。エージェントは、メディアソース、メディアシンク、メディアコントローラ、及び他の要素を含む。一例において、エージェントは、ビデオストリーミングサービスを提供する。この例では、エージェントは、メッセージに応答してメディアストリームに問合せ且つそれを制御し、そして命令されると、エージェントは、メディアストリームを別のエージェントへ自律的に配送する。ある実施形態では、エージェントは、いつでも、１つ以下のアクティブなメディアセッションを有し、比較的簡単なオペレーションを与える。エージェントは、メッセージを送信及び受信し、そのようなメッセージに応答して内部状態を変更し、そして副次的作用として連続的アクションを遂行する能力を有するという点で、アクティブなオブジェクトとして働くと見ることができ、又、そのように説明することができる。
【００５０】
ある実施形態では、エージェントは、通信マネージャーによって娯楽ネットワーク上で通信することができる。ある実施形態では、図７の通信マネージャー７２０、７２５及び７３０のように、装置当たり１つ以上の通信マネージャーがある。又、ある実施形態では、単一の通信マネージャーによって複数のエージェントをマネージすることができ、例えば、通信マネージャー７２０によってエージェント７３０、７３５及び７４０がマネージされる。ある実施形態では、通信マネージャーは、その通信マネージャーに結び付けられたエージェントへ及びエージェントからメッセージをルーティングする役割を果たす。そのプロセスは、同じネットワーク装置に対してローカルの他のエージェントへメッセージを配送し、個々のエージェントから出力接続を経てリモートネットワーク装置のエージェントへメッセージをマルチプレクスし、そしてブロードキャスト要求を取り扱うことを含む。ある実施形態では、エージェントは、１つの通信エージェントのみに結び付けられ、通信マネージャーは、１つのネットワークインターフェイスのみに結び付けられる。
【００５１】
ある実施形態では、表示マネージャーは、表示装置のリソースをマネージするエージェントである。より詳細には、表示マネージャーは、表示リソース及びスクリーン幾何学へのアクセスを許可する役割を果たす。ある実施形態では、各表示装置は、ビデオ出力、グラフィック出力、オーディオ出力、及びユーザ入力のようなＩ／Ｏ装置の各関連セットに対して１つの表示マネージャーしかもたない。又、ある実施形態では、エージェントは、セッションマネージャーと共に働き、表示装置へのメディアコンテンツの配送及び表示を整合し、表示装置リソースへのアクセスを許可する。又、ある実施形態では、表示マネージャーは、ユーザセッションのためのスタート点を表し、そしてセッションマネージャーへ制御を委任する。
【００５２】
ある実施形態では、セッションマネージャーは、アクティブなユーザに対してメディアコンテンツのセットを整合するエージェントである。又、ある実施形態では、選択がなされると、セッションマネージャーは、対応する表示マネージャーとのリモートオンスクリーン表示セッションを開始し、そしてネットワーク内の他の装置をマネージするためにアプリケーションプログラムの実行を開始する。又、ある実施形態では、表示マネージャーは、入力イベントをセッションマネージャーへ転送し、そして表示リソースへのアクセス権を許可し、セッションマネージャーは、それを他のエージェントへ委任することができ、従って、他のエージェントが表示装置へコンテンツを配送できるようにする。一例において、表示マネージャーは、セットトップボックス内で実行されるセッションマネージャーへアクセス権を許可する。セッションマネージャーは、表示装置とのリモートＵＩ（ユーザインターフェイス）セッションを開始し、そしてネットワーク装置のユーザが、再生されるべきビデオを、リモートビデオ記憶装置から選択できるようにする。ある実施形態では、セッションマネージャーは、ビデオサーバーへアクセス権を通し、そしてメディアストリームを表示装置へ配送するようにビデオサーバーに指令する。又、ある実施形態では、セッションマネージャーは、メディアコンテンツを使用してユーザの経験をマネージするのに必要な状態を維持する。
【００５３】
図８は、ネットワーク装置のコンポーネントの実施形態を示す。この図において、ネットワーク装置８０５は、娯楽ネットワークにおける任意の装置であり、図６に示す装置を含むが、これに限定されない。例えば、ネットワーク装置は、テレビジョン、セットトップボックス、記憶ユニット、ゲームコンソール、又は他のメディア装置である。ある実施形態では、ネットワーク装置８０５は、ネットワークファンクションを与えるためのネットワークユニット８１０を備えている。ネットワークファンクションは、メディアデータストリームを発生し、転送し、記憶し及び受信することを含むが、これに限定されない。ネットワークユニット８１０は、チップ上の単一システム（ＳｏＣ）として又は複数のコンポーネントとして具現化することができる。
【００５４】
ある実施形態では、ネットワークユニット８１０は、データを処理するためのプロセッサを含む。データの処理は、メディアデータストリームを発生し、メディアデータストリームを転送又は記憶で操作し、そしてメディアデータストリームを使用のために解読及びデコーディングすることを含む。又、ネットワーク装置は、ネットワークオペレーションをサポートするためのメモリ、例えば、ＤＲＡＭ（ダイナミックランダムアクセスメモリ）８２０、又は他の同様のメモリ及びフラッシュメモリ８２５、或いは他の不揮発性メモリを含む。
【００５５】
又、ネットワーク装置８０５は、各々１つ以上のネットワークインターフェイス８５５を経てネットワークにデータを送信し又はネットワークからデータを受信するための送信器８３０及び／又は受信器８４０も備えている。送信器８３０又は受信器８４０は、例えば、イーサネットケーブル８５０を含むワイヤード送信ケーブル、又はワイヤレスユニットに接続される。送信器８３０又は受信器８４０は、データ送信のためのライン８３５及びデータ受信のためのライン８４５のような１つ以上のラインで、データ転送及び制御信号のためのネットワークユニット８１０に結合される。付加的な接続も存在する。又、ネットワーク装置８０５は、装置のメディアオペレーションのための多数のコンポーネントを含むが、ここには示されていない。
【００５６】
上述した説明において、説明上、本発明を完全に理解するために多数の特定の細部について述べた。しかしながら、当業者であれば、幾つかの特定の細部がなくても、本発明を実施できることが明らかであろう。他の点では、良く知られた構造及び装置は、ブロック図の形態で示された。図示されたコンポーネントとコンポーネントとの間に中間構造が存在することがある。説明又は図示されたコンポーネントは、ここに図示又は説明されない付加的な入力又は出力を有することがある。
【００５７】
本発明は、種々のプロセスを含むことができる。本発明のプロセスは、ハードウェアコンポーネントによって遂行することもできるし、又はマシン実行可能なインストラクションによって実施することもでき、これらインストラクションでプログラムされた汎用又は特殊目的プロセッサ或いはロジック回路でプロセスを遂行するように使用できる。或いは又、プロセスは、ハードウェア及びソフトウェアの組合せで遂行することもできる。
【００５８】
本発明の各部分は、本発明によるプロセスを遂行するようにコンピュータ（又は他の電子装置）をプログラムするのに使用されるコンピュータプログラムインストラクションが記憶されたコンピュータ読み取り可能な媒体を含むコンピュータプログラム製品として提供されてもよい。マシン読み取り可能な媒体は、フロッピーディスケット、光学ディスク、ＣＤ−ＲＯＭ（コンパクトディスクリードオンリメモリ）、磁気−光学ディスク、ＲＯＭ（リードオンリメモリ）、ＲＡＭ（ランダムアクセスメモリ）、ＥＰＲＯＭ（消去可能なプログラマブルリードオンリメモリ）、ＥＥＰＲＯＭ（電気的に消去可能なリードオンリメモリ）、マグネット又は光学的カード、フラッシュメモリ、又は電子的インストラクションを記憶するのに適した他の形式のメディア／マシン読み取り可能なメディアを含むが、これに限定されない。更に、本発明は、コンピュータプログラム製品としてダウンロードすることもでき、このプログラムは、リモートコンピュータから、要求を発しているコンピュータへ転送することができる。
【００５９】
多数の方法を最も基本的な形態で説明したが、本発明の基本的な範囲から逸脱せずに、いずれかの方法にプロセスを追加したり又は削除したりすることができ、又、いずれかの上述したメッセージに情報を追加したり削除したりすることができる。当業者であれば、多数の更に別の変更や適応がなされ得ることが明らかであろう。本発明を限定するのではなく例示するために特定の実施形態が示された。本発明の範囲は、上述した特定例によって決定されるのではなく、特許請求の範囲のみによって決定されるものとする。
【００６０】
要素“Ａ”が要素“Ｂ”に結合されると言える場合には、要素Ａは、要素Ｂに直結されるか、又は、例えば、要素Ｃを経て間接的に結合される。コンポーネント、特徴、構造、プロセス、又は特性Ａが、コンポーネント、特徴、構造、プロセス、又は特性Ｂを「引き起こす」と明細書又は請求の範囲に述べられたときには、“Ａ”は、“Ｂ”の少なくとも部分的な原因であるが、“Ｂ”を引き起こす上で助けとなる少なくとも１つの他のコンポーネント、特徴、構造、プロセス、又は特性でもあることを意味する。コンポーネント、特徴、構造、プロセス、又は特性を含んでもよく(may)、含むことがあり(might)、又は含むことができる(could)と明細書に示された場合に、その特定のコンポーネント、特徴、構造、プロセス、又は特性を含むことが要求されるのではない。明細書又は請求の範囲で「ある(“a”又は“an”)」要素が言及された場合には、述べられた要素が１つしかないことを意味するものではない。
【００６１】
実施形態は、本発明の具現化又は一例である。明細書において「実施形態」、「１つの実施形態」、「ある実施形態」又は「他の実施形態」を言及するときには、その実施形態について述べる特定の特徴、構造又は特性が、少なくともある実施形態には含まれるが、必ずしも全ての実施形態に含まれるのではないことを意味している。「実施形態」、「１つの実施形態」又は「ある実施形態」の種々の出現は、必ずしも全てが同じ実施形態を示していない。本発明の実施形態の以上の説明において、開示を合理化し且つ本発明の１つ以上の種々の態様を理解する上で助けとなるように、本発明の種々の特徴は、時々、単一の実施形態、図面又はその説明に一緒にグループ編成されたことが明らかであろう。しかしながら、開示のこの方法は、請求の範囲に記載の発明が各請求項に述べた以上の特徴を要求するという意図を反映するものとして解釈されるものではない。むしろ、請求の範囲に反映されるように、本発明の態様は、以上に開示された単一実施形態の全ての特徴未満のものに存在する。従って、この説明に明確に組み込まれた請求の範囲において、各請求項は、本発明の個別の実施形態としてそれ自身自立している。
【符号の説明】
【００６２】
１０５：ネットワーク
１００：送信装置
１１５：受信装置Ａ
１２０：受信装置Ｂ
１２５：受信装置Ｃ
１３０：データストリーム
２０５：送信器
２１０：クロック
２１５：受信器
２２０：ローカルクロック
２２５：パケット
２３０、２３５、２４０：タイムスタンプ
３５０：待ち時間値
３６０：バッファ情報
３６５：ハイウオーターマーク
３７０：ローウオーターマーク
３７５：デコーダ
３８０：バッファ
【図１】
0005624468.tif 000006
【図２】
0005624468.tif 000007
【図３】
0005624468.tif 000008
【図４】
0005624468.tif 000009
【図５】
0005624468.tif 000010
【図６】
0005624468.tif 000011
【図７】
0005624468.tif 000012
【図８】
0005624468.tif 000013