JP5989779B2 - 同期したワイヤレスディスプレイデバイス - Google Patents

Description

優先権の主張

本出願は、各々の内容全体が参照により本明細書に組み込まれる、２０１１年９月１３日に出願された米国仮出願第第６１／５３４，１９３号、２０１１年９月２７日に出願された米国仮出願第６１／５３９，７２６号、および２０１２年２月７日に出願された米国仮出願第６１／５９５，９３２号の利益を主張する。

本開示は、メディアデータのトランスポートおよび再生に関し、より詳細には、モバイルデバイスによるメディアデータのトランスポートおよび再生の管理に関する。

[0003]モバイルデバイスは、携帯電話、ワイヤレス通信カードをもつポータブルコンピュータ、携帯情報端末（ＰＤＡ）、ポータブルメディアプレーヤ、あるいは、いわゆる「スマート」フォンおよび「スマート」パッドもしくはタブレット、または他のタイプのワイヤレス通信デバイスを含む、ワイヤレス通信機能をもつ他のフラッシュメモリデバイスの形態をとり得る。モバイルデバイスは、高電力プロセッサの追加、メディアコンテンツを処理する能力、およびクラウド中のネットワークと対話する能力によってますます強力になっている。これらの改善により、より良いユーザエクスペリエンスを与え、生産性を向上させるモバイルデバイスのための新しい使用モデルを開発することが可能になる。

[0004]モバイルデバイス上での処理能力およびメモリ可用度の著しい改善によって可能な新しい使用モデルの一例は、ワイヤレスディスプレイまたはＷｉ−Ｆｉ（登録商標）ディスプレイ（ＷＦＤ）である。ワイヤレスディスプレイ（ＷＤ）システムは、ソースデバイスと１つまたは複数のシンクデバイスとを含む。ソースデバイスはモバイルデバイスであり得、シンクデバイスの各々はモバイルデバイスまたはワイヤードデバイスであり得る。ソースデバイスは、１つまたは複数の参加しているシンクデバイスにオーディオビデオ（ＡＶ）データを送る。ＡＶデータは、ソースデバイスのローカルディスプレイと、シンクデバイスのディスプレイの各々との両方において再生され得る。

[0005]概して、本開示は、ワイヤレスディスプレイ（ＷＤ）システム中のソースデバイスと１つまたは複数のシンクデバイスとの間でメディアデータの再生を同期させるための技法に関する。ＷＤシステムは、モバイルデバイスがソースデバイスのローカルディスプレイをリモートシンクデバイスと共有することを可能にする。たとえば、モバイルデバイスを有する数人の人々が集まったとき、１人のモバイルデバイスユーザが、共有すべきコンテンツを有し得、他のユーザの各々は、自分自身のＷＤ対応モバイルデバイスを使用してそのコンテンツを受信し、閲覧することができる。このシナリオでは、コンテンツ所有者のモバイルデバイスはソースデバイスとして働き、他のモバイルデバイスはシンクデバイスとして働く。しかしながら、ソースデバイスおよびシンクデバイスの各々中のメディアプレーヤは、一般に、表示のための処理より前に、任意に決定されたキューサイズを使用して着信メディアパケットをキャッシュする。ソースデバイスおよびシンクデバイスの各々は、キューサイズを別様に設定し、したがって、異なる時間にメディアパケットを処理することを開始し得る。この非同期処理は、時々、デバイスにおけるメディアデータの非同期再生を生じることがある。

[0006]本開示の技法は、ソースデバイスおよび参加しているシンクデバイスのためのユニバーサルキューサイズを選択するためのソースデバイスにおける管理プロシージャを含む。ソースデバイスは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択する。メディアパケットは、次いで、表示のための処理より前に、ソースデバイスおよびシンクデバイスにおいてユニバーサルキューサイズを有するキュー中に保持される。参加しているデバイスの各々における均一な（uniform）キューサイズは、デバイスの各々が同時にメディアパケットの処理を開始することを可能にし、これにより、個々のデバイスにおけるメディアデータの再生が同期する。

[0007]一例では、本開示は、ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、シンクデバイスのうちの少なくとも１つに、通信セッションのためのソースデバイスによって選択されたユニバーサルキューサイズを通知することと、シンクデバイスの各々にデータパケットを送ることと、データパケットは、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持され、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中にデータパケットを保持することと、ソースキューが満杯であることを検出すると、ソースデバイスにおける表示のためのソースキュー中のデータパケットの処理を開始することと、ソースデバイスにおける処理はシンクデバイスにおけるデータパケットの処理と同期する、を備える方法を対象とする。

[0008]別の例では、本開示は、ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、ソースデバイスからユニバーサルキューサイズの通知を受信することと、ユニバーサルキューサイズは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいて選択され、通信セッションの一部としてソースデバイスからデータパケットを受信することと、パケットは、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中にデータパケットを保持することと、シンクキューが満杯であることを検出すると、シンクデバイスにおける表示のためのシンクキュー中のパケットの処理を開始することと、シンクデバイスにおけるパケット処理はソースデバイスにおけるパケット処理と同期する、を備える方法を対象とする。

[0009]さらなる一例では、本開示は、ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立し、ソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択するように構成されたプロセッサを備えるソースデバイスを対象とする。ソースデバイスはまた、通信セッションのために選択されたユニバーサルキューサイズの通知をシンクデバイスに送信するための送信機を備え、送信機は通信セッションの一部としてシンクデバイスの各々にデータパケットを送り、データパケットは、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持される。ソースデバイスは、パケットを保持するユニバーサルキューサイズを有するソースキューをさらに備え、ソースキューが満杯であることを検出すると、プロセッサは、ソースデバイスにおける表示のためのソースキュー中のデータパケットを処理することを開始し、ソースデバイスにおけるデータパケット処理はシンクデバイスにおけるパケット処理と同期する。

[0010]追加の例では、本開示は、ソースデバイスにシンクデバイスとの通信セッションを確立することを要求するように構成されたプロセッサを備えるシンクデバイスを対象とする。シンクデバイスは、ソースデバイスからユニバーサルキューサイズの通知を受信することと、ユニバーサルキューサイズは少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいて選択され、通信セッションの一部としてソースデバイスからパケットを受信することと、パケットはソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され、を行う受信機をさらに備える。ソースデバイスは、パケットを保持するユニバーサルキューサイズを有するシンクキューをさらに備え、シンクキューが満杯であることを検出すると、プロセッサは、シンクデバイスにおける表示のためのシンクキュー中のパケットを処理することを開始し、シンクデバイスにおけるパケット処理は少なくともソースデバイスにおけるパケット処理と同期する。

[0011]さらなる一例では、本開示は、ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立するための手段と、シンクデバイスの各々に通信セッションのためのソースデバイスによって選択されたユニバーサルキューサイズを通知するための手段と、シンクデバイスの各々にデータパケットを送るための手段と、データパケットはシンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持するための手段と、ソースキューが満杯であることを検出すると、ソースデバイスにおける表示のためのソースキュー中のデータパケットの処理を開始するための手段と、ソースデバイスにおける処理はシンクデバイスにおけるデータパケットの処理と同期する、を備えるソースデバイスを対象とする。

[0012]別の例では、本開示は、ソースデバイスにシンクデバイスとの通信セッションを確立することを要求するための手段と、ソースデバイスからユニバーサルキューサイズの通知を受信するための手段と、ユニバーサルキューサイズが、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいて選択され、通信セッションの一部としてソースデバイスからデータパケットを受信するための手段と、パケットは、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中にデータパケットを保持するための手段と、シンクキューが満杯であることを検出すると、シンクデバイスにおける表示のためのシンクキュー中のパケットの処理を開始するための手段と、を備え、シンクデバイスにおけるパケット処理はソースデバイスにけるパケット処理と同期する、シンクデバイスを対象とする。

[0013]別の例では、本開示は、ソースデバイス中で実行されたとき、プロセッサに、ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、シンクデバイスの各々に通信セッションのためのソースデバイスによって選択されたユニバーサルキューサイズを通知することと、シンクデバイスの各々にデータパケットを送ることと、データパケットはシンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持され、ソースキューが満杯であることを検出すると、ソースデバイスにおける表示のためのソースキュー中のデータパケットの処理を開始することと、を行わせる命令を備え、ソースデバイスにおける処理はシンクデバイスにおけるデータパケットの処理と同期する、コンピュータ可読媒体を対象とする。

[0014]別の例では、本開示は、シンクデバイス中で実行されたとき、プロセッサに、ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、ソースデバイスからユニバーサルキューサイズの通知を受信することと、ユニバーサルキューサイズは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいて選択され、通信セッションの一部としてソースデバイスからデータパケットを受信することと、パケットはソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中にデータパケットを保持することと、シンクキューが満杯であることを検出すると、シンクデバイスにおける表示のためのシンクキュー中のパケットの処理を開始することと、を行わせる命令を備え、シンクデバイスにおけるパケット処理はソースデバイスにおけるパケット処理と同期する、コンピュータ可読媒体を対象とする。

[0015]別の例では、本開示は、シンクデバイスとソースデバイスとの間の通信セッションを確立することと、ソースデバイスからユニバーサルキューサイズの通知を受信することと、ユニバーサルキューサイズが、通信セッションのためにソースデバイスによって選択され、ソースデバイスからデータパケットを受信することと、データパケットは、ソースデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持され、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中にデータパケットを保持することと、シンクキューが満杯であることを検出すると、シンクデバイスにおける表示のためのシンクキュー中のデータパケットの処理を開始することと、を備え、シンクデバイスにおける処理はソースデバイスにおけるデータパケットの処理と同期する、方法を対象とする。

[0016]本開示の１つまたは複数の例の詳細を添付の図面および以下の説明に記載する。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。

ソースデバイスとシンクデバイスとを含むＷＤシステムを示すブロック図。 ソースデバイスと通信セッションに参加しているシンクデバイスとを含む例示的なＷＤシステムを示すブロック図。 本開示の技法による、ソースデバイスと、ストリーミングモードでの同期通信セッションに参加することが可能なシンクデバイスとを含む別の例示的なＷＤシステムを示すブロック図。 本開示の技法による、ソースデバイスと、フレームバッファモードでの同期通信セッションに参加することが可能なシンクデバイスとを含む別のＷＤシステムを示すブロック図。 ソースデバイスと参加しているシンクデバイスとの間の通信セッションのためのユニバーサルキューサイズを選択するために使用される例示的な情報交換を示す論理図。 本開示の技法による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な動作を示す流れ図。 本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図。 本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図。 本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図。

[0026]本開示は、ワイヤレスディスプレイ（ＷＤ）システム中のソースデバイスと１つまたは複数のシンクデバイスとの間でメディアデータの再生を同期させるための技法に関する。ＷＤシステムは、モバイルデバイスがソースデバイスのローカルディスプレイをリモートシンクデバイスと共有することを可能にする。たとえば、モバイルデバイスを有する数人の人々が集まったとき（たとえば、仕事上の会議または家族／友人の集まり）、１人のモバイルデバイスユーザは、ビデオクリップなどのコンテンツを有し、室内の皆にそのコンテンツを見せ、および／またはそのコンテンツが表示されている間、説明および追加情報を与えたいと思うことがある。ＷＤシステムでは、皆が自分自身のＷＤ対応モバイルデバイスを使用してコンテンツを受信し、閲覧することができる。このシナリオでは、コンテンツ所有者のモバイルデバイスはソースデバイスとして働き、他のモバイルデバイスはシンクとして働く。このジョイントユーザエクスペリエンスを与えるためには、すべてのユーザが同じコンテンツを視聴し、任意の言語説明を正しいコンテンツと関係付けるように、すべてのデバイスにおけるコンテンツ再生が同期されることが重要である。

[0027]しかしながら、ソースデバイスおよびシンクデバイスの各々中のメディアプレーヤは、一般に、表示のための処理より前に、任意に決定されたキューサイズを使用して着信メディアパケットをキャッシュする。ソースデバイスおよびシンクデバイスの各々は、キューサイズを別様に設定し、したがって、異なる時間にメディアパケットを処理することを開始し得る。この非同期処理は、デバイスにおけるメディアデータの非同期再生を生じることになる。

[0028]本開示の技法は、ソースデバイスおよび参加しているシンクデバイスのためのユニバーサルキューサイズを選択するためのソースデバイスにおける管理プロシージャを含む。ソースデバイスは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択する。メディアパケットは、次いで、表示のための処理より前に、ソースデバイスおよびシンクデバイスにおいてユニバーサルキューサイズを有するキュー中に保持される。参加しているデバイスの各々における均一なキューサイズは、デバイスの各々が同時にメディアパケットを処理を開始することを可能にし、これにより、個々のデバイスにおけるメディアデータの再生が同期する。

[0029]図１は、ソースデバイス５とシンクデバイス７とを含むＷＤシステムを示すブロック図である。ソースデバイスは、特定の通信セッションに参加しているシンクデバイスのうちの１つまたは複数に、オーディオおよび／またはビデオ（ＡＶ）データなどのメディアデータを送る。メディアデータは、ソースデバイスのローカルディスプレイと、シンクデバイスのディスプレイの各々との両方において再生され得る。より詳細には、参加しているシンクデバイスの各々は、それのスクリーンおよびオーディオ機器上で、受信されたメディアデータをレンダリングする。場合によっては、シンクデバイスのユーザは、タッチ入力およびリモート制御入力など、ユーザ入力をシンクデバイスに適用し得る。ＷＤシステムでは、ユーザ入力は、シンクデバイスからソースデバイスに送られる。ソースデバイスは、シンクデバイスから受信したユーザ入力を処理し、シンクデバイスに送られた後続のメディアデータにユーザ入力の効果を適用する。

[0030]図２は、ソースデバイス１０と、通信セッションに参加しているシンクデバイス１２Ａ〜１２Ｂ（「シンクデバイス１２」）とを含むＷＤシステムを示すブロック図である。他の例では、ＷＤシステムは、３つ以上の参加しているシンクデバイスを含み得る。ＷＤシステムはまた、ＷＤ通信セッションがそれを介してソースデバイス１０とシンクデバイス１２との間で確立される複数のＷｉ−Ｆｉ（たとえば、ＩＥＥＥ８０２．１１ｘ）ネットワークをサポートする、１つまたは複数の基地局（図示せず）を含み得る。通信サービスプロバイダは、ネットワークハブとして基地局を使用して、これらのネットワークのうちの１つまたは複数を集中的に動作させ、管理し得る。

[0031]ソースデバイス１０およびシンクデバイス１２の各々は、携帯電話、ワイヤレス通信カードをもつポータブルコンピュータ、携帯情報端末（ＰＤＡ）、ポータブルメディアプレーヤ、ワイヤレス通信機能をもつ他のフラッシュメモリデバイス、または任意のタイプのワイヤレス通信デバイスなど、モバイルデバイスの形態をとり得る。他の例では、シンクデバイス１２のうちの１つまたは複数は、テレビジョン、デスクトップコンピュータ、モニタ、プロジェクタなど、ワイヤレス通信機能をもつワイヤードデバイスの形態をとり得る。図２の図示の例では、ソースデバイス１０は、記憶されたコンテンツ１６と、パーサ１８と、デコーダ２０と、レンダラ２２と、ローカルディスプレイ２４と、送信機（ＴＸ）２６とを含む。シンクデバイス１２は、受信機３０Ａ〜３０Ｂ（「受信機３０」）と、デコーダ３２Ａ〜３２Ｂ（「デコーダ３２」）と、レンダラ３４Ａ〜３４Ｂ（「レンダラ３４」）と、ディスプレイ３６Ａ〜３６Ｂ（「ディスプレイ３６」）とを含む。

[0032]ソースデバイス１０およびシンクデバイス１２の構成要素はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適な回路のいずれか、またはそれらの任意の組合せとして実装され得る。ローカルディスプレイ２４およびディスプレイ３６はそれぞれ、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

[0033]ソースデバイス１０が記憶されたコンテンツ１６を再生しているとき、ソースデバイス１０は、リモートシンクデバイス１２のうちの１つまたは複数から通信セッションを設置したいという要求を受信し得る。ソースデバイス１０は、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、ソースデバイス１０と１つまたは複数の要求元シンクデバイス１２との間の通信セッションを確立し得る。確立されると、通信セッションは、図１および図２に示したように、ソースデバイスが記憶された符号化メディアストリームを送信するストリーミングモードで動作するか、または図４に示したように、ソースデバイスがメディアフレームをキャプチャし、符号化し、送信するフレームバッファモードで動作し得る。いずれの場合も、メディアデータは、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用して、ソースデバイスから参加しているシンクデバイスに送信され得る。

[0034]図２の図示の例では、記憶されたコンテンツ１６は、ソースデバイス１０のメモリ（図示せず）中の符号化されたメディアデータ、すなわち、オーディオおよび／またはビデオデータを含み得る。パーサ１８は、記憶されたコンテンツ１６を処理し、異なるメディアストリーム、すなわち、オーディオおよび／またはビデオストリームを抽出することを担当し得る。デコーダ２０は、パーサ１８から出力されたメディアストリームを受信し、ストリーム内のメディアデータを復号する。デコーダ２０は、たとえば、ビデオデコーダとオーディオデコーダの両方を含み得る。レンダラ２２は、次いで、ソースデバイス１０上でのローカルな提示のための復号されたメディアデータから、コンテンツ、たとえば、画像および／または音を生成する。たとえば、レンダラ２２は、ローカルディスプレイ２４上での提示のために復号されたビデオデータから画像を生成し得、ソースデバイス１０のスピーカー（図示せず）上での提示のために復号されたオーディオデータから音を生成し得る。

[0035]パーサ１８から出力されたメディアストリームはまた、タップアウト（tap out）され、通信セッションの一部として送信機（ＴＸ）２６を介してシンクデバイス１２の一方または両方に送られる。シンクデバイス１２において、受信機３０はソースデバイス１０からメディアストリームを受信し、デコーダ３２はストリーム内のメディアデータを復号する。デコーダ３２の各々は、たとえば、ビデオデコーダとオーディオデコーダの両方を含み得る。レンダラ３４は、次いで、それぞれのシンクデバイス１２上での提示のために復号されたメディアデータから、コンテンツ、たとえば、画像および／または音を生成する。たとえば、レンダラ３４は、ディスプレイ３６上での提示のために復号されたビデオデータから画像を生成し得、シンクデバイス１２のスピーカー（図示せず）上での提示のために復号されたオーディオデータから音を生成し得る。

[0036]非同期処理を用いて、ソースデバイス１０およびシンクデバイス１２の各々は、表示のための処理より前に、任意に決定されたキューサイズを使用して着信メディアパケットをキャッシュし得る。ソースデバイス１０およびシンクデバイス１２の各々は、メディアデータのタイプ、すなわち、ビデオデータおよび／またはオーディオデータのために異なるキューサイズを設定し、したがって、異なる時間にメディアパケットを処理することを開始し得る。この非同期処理は、デバイスにおけるメディアデータの非同期再生を生じることがある。たとえば、ソースデバイス１０およびシンクデバイス１２の各々が異なる時間においてビデオデータを復号およびレンダリングすることを開始した場合、再生画像は、すべてのシンクデバイス１２および／またはソースデバイス１０にわたって同期されるとは限らないであろう。

[0037]図３は、本開示の技法による、ソースデバイス４０Ａと、ストリーミングモードでの同期通信セッションに参加することが可能なシンクデバイス４２Ａ〜４２Ｂ（「シンクデバイス４２」）とを含むＷＤシステムを示すブロック図である。ソースデバイス４０Ａは、ソースデバイス４０Ａおよび参加しているシンクデバイス４２が、あるタイプのメディアデータについて同じユニバーサルキューサイズを使用するように通信セッションを協調させるセッションマネージャ４１を含む。さらに、ソースデバイス４０Ａおよびシンクデバイス４２の各々は、ユニバーサルキューサイズを有するそれぞれのキューが満杯であることを検出するとパケット処理をトリガするキューモニタを含む。このようにして、ソースデバイス４０Ａおよびシンクデバイス４２は、個々のデバイスにおけるメディアデータの同期再生を生成するために、メディアパケットを同期して処理する。

[0038]図３の図示の例では、ソースデバイス４０Ａは、図２からのソースデバイス１０と同様に、記憶されたコンテンツ１６と、パーサ１８と、デコーダ２０と、レンダラ２２と、ローカルディスプレイ２４と、送信機（ＴＸ）２６とを含む。説明する技法によれば、ソースデバイス４０Ａはまた、セッションマネージャ４１と、キューモニタ４３と、ユニバーサルキューサイズを有するソースキュー４４とを含む。シンクデバイス４２は、図２からのシンクデバイス１２と同様に、受信機３０と、デコーダ３２と、レンダラ３４と、ディスプレイ３６とを含む。シンクデバイス４２は、セッションマネージャ４５Ａ〜４５Ｂ（「セッションマネージャ４５」）と、キューモニタ４７Ａ〜４７Ｂ（「キューモニタ４７」）と、ユニバーサルキューサイズを有するシンクキュー４６Ａ〜４６Ｂ（「キュー４６」）とをさらに含む。

[0039]説明のために、通信セッションは、ＷＤシステムのためのソリューションを使用するソースデバイス４０Ａによってセットアップされると仮定され得る。たとえば、ソースデバイス４０Ａおよびシンクデバイス４２Ａ〜４２Ｂは、通信セッションに参加しているデバイスを識別するためにデバイスディスカバリを実行する。

[0040]通信セッションが確立されると、ソースデバイス４０Ａにおけるセッションマネージャ４１は、通信セッション中にすべての参加しているデバイスにおいて使用するためのユニバーサルキューサイズを選択する。いくつかの例では、セッションマネージャ４１は、シンクデバイス４２におけるサポートキューサイズを決定するために、シンクデバイス４２におけるセッションマネージャ４５の各々に問い合わせ得る。その場合、セッションマネージャ４１は、ソースデバイス４０Ａおよびシンクデバイス４２におけるサポートキューサイズに基づいてユニバーサルキューサイズを選択し得る。他の例では、ソースデバイス４０Ａは、任意にユニバーサルキューサイズを選択し得る。ソースデバイス４０Ａのセッションマネージャ４１は、次いで、それ自体のメディア処理パイプラインとシンクデバイス４２のセッションマネージャ４５とにユニバーサルキューサイズを通知する。ユニバーサルキューサイズ値は、所定の様式、たとえば、持続時間、フレームの数などで提示され得る。ユニバーサルキューサイズ選択プロセスについて図５でより詳細に説明する。ソースデバイス４０Ａのセッションマネージャ４１は、次いで、シンクデバイス４２とのメディアセッションを開始し得る。

[0041]異なる能力および処理遅延をもつ異なるデバイス間での同期を保証するためにユニバーサルキューサイズを選択することに加えて、セッションマネージャ４１はまた、シンクデバイス４２の各々において使用するためのトリガ遅延を含む遅延間隔値を計算し得る。トリガ遅延は、ソースデバイス４０Ａからシンクデバイス４２の各々までのメディアパケットの異なる送信時間を考慮し、シンクキューが満杯であることを検出することと、シンクキュー中のメディアパケットの処理を開始することとの間の待ち時間を課する。このようにして、参加しているデバイスは、デバイスの各々におけるキューが満杯になるまで、メディアパケットを処理することを開始しない。例示的な方法では、シンクデバイスの各々は、それらのそれぞれのトリガ遅延間隔を通知され得る。たとえば、ソースデバイス４０Ａにおける送信時間、ソースデバイス４０Ａとシンクデバイス４２の各々の間の伝搬遅延、およびシンクデバイス４２の各々における受信遅延などの遅延間隔を考慮することが重要であり得る。これらのパラメータの各々は、以下で説明するように測定されるか、または他の手段または方法を使用して導出され得る。ソースデバイス４０Ａにおける送信時間パラメータ（「ＴｘＴｉｍｅ」）は、ソースデバイス４０Ａにおけるデータパケットを送信するためのプロトコルスタック処理時間を表す。より詳細には、ＴｘＴｉｍｅは、アプリケーションレイヤがトランスポートレイヤにペイロードをサブミット（submit）したときと、ペイロード中のデータが物理レイヤ（たとえば、Ｗｉ−Ｆｉレイヤ）によって処理されるときとの間の時間を表す。ソースデバイス４０Ａのアプリケーションは、たとえば、ｌｏｃａｌｈｏｓｔアドレスを使用してそれ自体にペイロードを送ることによって、ループバック送信時間を測定し得る。代替的に、ループバック送信時間はプロトコルスタックに問い合わせられ得る。いずれの場合も、以下の通りである。

TxTime = Loopback transmission time/2.
[0042]伝搬遅延パラメータは、ソースデバイス４０Ａがそれと通信しているシンクデバイス４２の各々までのソースデバイス４０Ａの近接度に依存する。ＷＤシステムの場合、伝搬遅延は、一般に、人間のユーザが体験するためには極めて小さく、たとえば、数百フィート当たり数マイクロ秒である。したがって、伝搬遅延パラメータは、本開示では計算において無視され得る。

[0043]シンクデバイス４２の各々における受信遅延パラメータ（「ＲｘＤｅｌａｙ」）は、シンクデバイス４２の各々におけるメディアパケットを受信するためのプロトコルスタック処理時間を表す。ソースデバイス４０Ａは、以下の例示的な方法を使用してシンクデバイス４２の各々におけるＲｘＤｅｌａｙを計算し得る。ソースデバイス４０Ａにおけるアプリケーションが、たとえば、シンクデバイス４２Ａにペイロードを送信する。シンクデバイス４２Ａにおける等価なアプリケーションは、ソースデバイス４０Ａに同じペイロードを送信する。これは、ソースデバイス４０Ａにおけるアプリケーションが往復遅延（roundtrip delay）を測定することを可能にする。代替的に、往復遅延時間は受信スタックのための処理時間を表すので、往復遅延時間はシンクデバイス４２Ａに問い合わせられ得る。いずれの場合も、以下の通りである。

TxDelay (one way delay) = Roundtrip delay/2, および
RxDelay (at sink device) = TxDelay - TxTime.
[0044]本開示におけるユニバーサルキューサイズとトリガ遅延とを計算するために使用される追加のパラメータは、ソースデバイス４０Ａにおいてサポートされる最大キューサイズを表すＭａｘＳｙｎｃＱＳｉｚｅと、特定の通信セッションのためのシンクデバイス４２の各々においてサポートされるキューサイズを表すＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅと、ビデオデータのためのフレームレートによって決定され得る、ソースデバイス４０Ａにおけるパケット生成レートを表すＰｋｔＲａｔｅとを含む。ＴｒｉｇｇｅｒＤｅｌａｙは、シンクデバイス４２の各々におけるユニバーサルキューサイズを有するシンクキューが満杯になった後であるが、シンクキュー中に保持されたパケットを処理することを開始するようにデコーダをトリガする前の待ち時間を表す。ＳｅｌｅｃｔｅｄＯｐｔｉｍａｌＱｕｅｕｅＳｉｚｅは、通信セッションに参加するであろうすべてのデバイスのためのソースデバイス１０によって選択されたユニバーサルキューサイズを表す。

[0045]ソースデバイス４０Ａは、確立されている通信セッションのタイプに応じてユニバーサルキューサイズを計算するために異なる方法を適用し得る。第１の場合では、ソースデバイス４０Ａは、１つのシンクデバイスのみ、たとえばシンクデバイス４２Ａとの通信セッションを確立する。ソースデバイス４０Ａは、以下のように、通信セッションのためのソースデバイス４０Ａおよびシンクデバイス４２Ａによって使用されるべきユニバーサルキューサイズを選択する。

MaxSyncQSize - (PktRate * TxDelay) - UniversalQueueSize >= 0, および
UniversalQueueSize <= SupportedSinkQSize.
[0046]第２の場合では、ソースデバイス４０Ａは、シンクデバイス１、２、．．．ｎ、たとえばシンクデバイス４２の両方とのマルチキャスト通信セッションを確立する。ソースデバイス４０Ａは、以下のように、マルチキャスト通信セッションのためのソースデバイス４０Ａおよびシンクデバイス４２によって使用されるべきユニバーサルキューサイズを選択する。

RxDelay_allDevices = max(RxDelay₁, RxDelay₂, ... , RxDelay_n),
SupportedSinkQSize_min = min(SupportedSinkQSize₁, SupportedSinkQSize₂, ... SupportedSinkQSize_n), ここでSupportedSinkQSize_i はシンクデバイスｉによりサポートされるキューサイズであり、
MaxSyncQSize - (PktRate * RxDelay_allDevices) - UniversalQueueSize >= 0, および
UniversalQueueSize <= SupportedSinkQSize_min.

[0047]第３の場合では、ソースデバイス４０Ａは、複数のシンクデバイス１、２、．．．、ｎ、たとえばシンクデバイス４２の各々との複数のユニキャスト通信セッションを確立する。通信セッションをセットアップすることに関心があるシンクデバイス４２の各々からＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅを受信すると、ソースデバイス４０Ａは、最大のＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅをもつシンクデバイス４２のうちの１つがメディアストリームの第１の受信側になり、２番目に大きいＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅをもつシンクデバイス４２のうちの１つがメディアストリームの第２の受信側になるなどのように、送信スケジュールをソートする。送信スケジュールを決定した後に、ソースデバイス４０Ａはシンクデバイスｉ＝１、２、．．．ｎの各々のためのＴｒｉｇｇｅｒＤｅｌａｙ_iを計算する。シンクデバイス４２の各々のためのトリガ遅延の計算については、以下でより詳細に説明する。

[0048]ソースデバイス４０Ａは、次いで、次のようにシンクデバイス４２における最小サポートキューサイズを決定する。

SupportedSinkQSize_min = min((SupportedSinkQSize₁ - (PktRate * TriggerDelay₁)), (SupportedSinkQSize₂ - (PktRate * TriggerDelay₂)), … (SupportedSinkQSize_n - (PktRate * TriggerDelay_n))).
この場合、ＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅ_minは、（ＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅ_i−（ＰｋｔＲａｔｅ＊ＴｒｉｇｇｅｒＤｅｌａｙ_i））＞０をもつシンクデバイスｉのみに基づいて計算される。（ＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅ_i−（ＰｋｔＲａｔｅ＊ＴｒｉｇｇｅｒＤｅｌａｙ_i））＜０をもつシンクデバイスｉは、（ＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅ_x−（ＰｋｔＲａｔｅ＊ＴｒｉｇｇｅｒＤｅｌａｙ_x））＞０をもつシンクデバイスｘと同じ通信セッションの一部になり得ない。ソースデバイス４０Ａは、次いで、以下のように、ユニキャスト通信セッションのためのソースデバイス４０Ａおよびシンクデバイス４２によって使用されるべきユニバーサルキューサイズを選択する。

MaxSyncQSize - (PktRate * TriggerDelay_soure) - UniversalQueueSize >= 0 ここで、 TriggerDelay_source はメディアストリームの最後の受信側であるシンクデバイスのためのTxDelayに等しく、
UniversalQueueSize <= SupportedSinkQSize_min.
[0049]したがって、シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することが可能であり得る。

[0050]図３に示したように、セッションマネージャ４１によって選択されたユニバーサルキューサイズに基づいて、ソースデバイス４０Ａのメディア処理パイプラインは、パーサ１８とデコーダ２０との間のユニバーサルキューサイズを有するソースキュー４４を生成する。同様に、シンクデバイス４２のメディア処理パイプラインはまた、受信機３０とデコーダ３２との間のユニバーサルキューサイズを有するシンクキュー４６を生成する。いくつかの例では、追加のキューが、ソースデバイス４０Ａ中のデコーダ２０とレンダラ２２との間、およびシンクデバイス４２中のデコーダ３２とレンダラ３４との間に生成され得る。この場合、上記で説明したキューサイズ選択プロセスの一部として、ソースデバイス４０Ａのセッションマネージャ４１はまた、デコーダとレンダラとの間の追加のキューのためのユニバーサルキューサイズとして選択し得る。

[0051]ユニバーサルキューサイズを有するソースキュー４４が生成されると、パーサ１８は記憶されたコンテンツ１６を処理し、異なるメディアストリーム、すなわち、オーディオおよび／またはビデオストリームを抽出する。ユニバーサルキューサイズは、一般に、ビデオが表示されるためのフレームの数または時間の量に基づくことができる。たとえば、いくつかのデバイスでは、５００〜２５００ミリ秒のビデオが記憶され得る。このビデオを記憶するための多くの異なるユニバーサルキューサイズ、たとえば、０．０１Ｍｂ〜１００００Ｍｂ、０．１Ｍｂ〜１０００Ｍｂ、または１Ｍｂ〜１００Ｍｂが可能である。さらに、特定のシステムのためのキューサイズは、そのシステムによって使用されるビデオの特性に基づいて変動し得る。

[0052]ソースデバイス４０Ａのキューモニタ４３は、ソースキュー４４にメディアパケットを送るためにパーサ１８と協調する。ソースキュー４４は、次いで、ソースデバイス４０Ａのメディア処理パイプラインによるさらなる処理より前に、パーサ１８から出力されたメディアパケットを保持する。メディアパケットなど、データパケットはまた、通信セッションの一部としてシンクデバイス４２の各々に送られる。シンクデバイス４２において、キューモニタ４７は、ユニバーサルキューサイズを有するシンクキュー４６にメディアパケットを送るために受信機３０と協調する。シンクキュー４６は、シンクデバイス４２のメディア処理パイプラインによるさらなる処理より前に、ソースデバイス４０Ａから受信したメディアパケットを保持する。

[0053]ソースデバイス４０Ａおよびシンクデバイス４２は、確立される通信セッションのタイプに応じて異なる方法を適用することによって同期パケット処理を達成し得る。

[0054]第１の場合では、通信セッションが、ソースデバイス４０Ａと１つのシンクデバイスのみ、たとえばシンクデバイス４２Ａとの間に確立される。シンクデバイス４２Ａのキューモニタ４７Ａが、シンクキュー４６Ａが完全に満たされたことを検出したとき、キューモニタ４７Ａは、シンクデバイス４２ＡのためのＴｒｉｇｇｅｒＤｅｌａｙ間隔の後にシンクキュー４６Ａ中のメディアパケットを処理することを開始するようにデコーダ３２Ａをトリガする。概して、ＴｒｉｇｇｅｒＤｅｌａｙ間隔は、シンクキュー４６Ａが満杯であることを検出することと、メディアパケットの処理を開始することとの間の待ち時間を表す。通信セッションがシンクデバイス４２Ａのみと確立される第１の場合では、デコーダ３２Ａは、シンクキュー４６Ａが満たされるとすぐにメディアパケットを処理することを開始することができるので、ＴｒｉｇｇｅｒＤｅｌａｙ間隔値は０に等しい。

[0055]一方、ソースデバイス４０Ａは、メディアパケットを処理することを開始するために、シンクデバイス４２Ａのシンクキュー４６Ａがメディアパケットで満たされるまで待つ。ソースデバイス４０Ａのキューモニタ４３が、ソースキュー４４が完全に満たされたことを検出したとき、キューモニタ４３は、ＴｘＤｅｌａｙ、すなわち、ソースデバイス４０Ａからシンクデバイス４２Ａまでの送信時間の後にソースキュー４４中のメディアパケットを処理することを開始するようにデコーダ２０をトリガする。このようにして、キューモニタ４３は、ソースデバイス４０Ａとシンクデバイス４２Ａとが同時にメディアパケットを処理することを開始することを保証する。

[0056]第２の場合では、マルチキャスト通信セッションが、ソースデバイス４０Ａと、複数のシンクデバイス１、２、．．．ｎ、たとえばシンクデバイス４２の両方との間で確立される。第１の場合について上記で説明したのと同じ同期パケット処理を達成する方法が、第２の場合のために使用され得る。マルチキャスト通信セッション中、シンクデバイス４２のすべては、シンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙ間隔値が０に等しくなるように、同時にソースデバイス４０Ａからメディアパケットを受信することになる。さらに、シンクデバイス４２のためのＴｘＤｅｌａｙ間隔値はすべて同じである。この場合、シンクキュー４６は同時にメディアパケットで満たされ、デコーダ３２の各々は、それぞれのシンクキュー４６が満たされるとすぐに、メディアパケットの同期処理を開始することができる。ソースデバイス４０Ａは、ＴｘＤｅｌａｙ時間を待ってからシンクデバイス４２との同期処理を開始する。ＴｘＤｅｌａｙの値中のいくつかのファクタのうちの１つは、一方向遅延、または２で除算された往復遅延である。

[0057]一方向遅延または２で除算された往復遅延は、ハードウェアレイヤおよびソフトウェアレイヤによってもたらされる距離および処理遅延に依存する。したがって、ＴｘＤｅｌａｙは、ハードウェアレイヤおよびソフトウェアレイヤによってもたらされる処理遅延によって大きく影響を受ける。異なるデバイスは異なる能力を有する。多くの異なる遅延が可能であることを理解されよう。

[0058] さらに、ソースデバイス４０ＢにおけるＴｘＤｅｌａｙ値はシンクデバイスの処理能力に依存し得る。したがって、処理速度はＴｘＤｅｌａｙを計算する際のファクタである。シンクデバイスの処理能力に応じて、処理時間は、たとえば、１ミリ秒から２０ミリ秒程度だけ、また、おそらくいくつかのシンクデバイスの場合は処理能力に応じてより長くだけ、ＴｘＤｅｌａｙ値に影響を及ぼし得る。他のシステムは１ミリ秒〜１００ミリ秒の復号遅延を有し得る。いくつかのシステムでは、一般的なＴｘＤｅｌａｙは、３００マイクロ秒から１５００マイクロ秒まで変動し得る。

[0059]第３の場合では、複数のユニキャスト通信セッションが、ソースデバイス４０Ａと、複数のシンクデバイス１、２、．．．ｎ、たとえばシンクデバイス４２の両方との間に確立される。ソースデバイス４０Ａからシンクデバイス１、２、．．．ｎの各々までの一方向送信遅延は、それぞれ、ＴｘＤｅｌａｙ₁、ＴｘＤｅｌａｙ₂、．．．ＴｘＤｅｌａｙ_nである。同様に、シンクデバイスの各々における受信遅延は、ＲｘＤｅｌａｙ₁、ＲｘＤｅｌａｙ₂、．．．ＲｘＤｅｌａｙ_nである。ソースデバイス４０Ａのセッションマネージャ４１は、通信セッションに参加するシンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙを計算する。シンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙは、シンクデバイス４２の各々が、残りのシンクデバイス４２のシンクキュー４６がメディアパケットで満たされるまで、メディアパケットを処理することを開始するのを待つように計算され得る。

[0060]ソースデバイス４０Ａは、シンクデバイスｎ、シンクデバイスｎ−１、．．．シンクデバイス２、およびシンクデバイス１という順序で、シンクデバイスにメディアパケットのペイロードを送り得る。ソースデバイス４０Ａのセッションマネージャ４１は、次いで、ＴｒｉｇｇｅｒＤｅｌａｙ_x＝ＲｘＤｅｌａｙ₁＋ＲｘＤｅｌａｙ₂＋．．．＋ＲｘＤｅｌａｙ_x-1としてシンクデバイスｘのＴｒｉｇｇｅｒＤｅｌａｙ値を計算する。たとえば、ソースデバイス４０Ａは、第１に、０の受信遅延でシンクデバイス４２Ａにメディアパケットを送り、次いで第２に、約５ミリ秒（ｍｓ）の受信遅延でシンクデバイス４２Ｂにメディアパケットを送り得る。セッションマネージャ４１は、次いで、シンクデバイス４２ＢのＲｘＤｅｌａｙ、すなわち、５ｍｓに等しいとしてシンクデバイス４２ＡのためのＴｒｉｇｇｅｒＤｅｌａｙ値を計算し、０に等しいとしてシンクデバイス４２ＢのためのＴｒｉｇｇｅｒＤｅｌａｙ値を計算し得る。ソースデバイス４０Ａのセッションマネージャ４１は、通信セッションセットアップの前またはその間のいずれかに、シンクデバイス４２の各々に、関連するＴｒｉｇｇｅｒＤｅｌａｙを通知する。

[0061]ソースデバイス４０Ａのセッションマネージャ４１はまた、ローカルソースＴｒｉｇｇｅｒＤｅｌａｙ値を計算する。ソースデバイス２０ＡのＴｒｉｇｇｅｒＤｅｌａｙ値は、メディアストリームの最後の受信側であるシンクデバイスのためのＴｘＤｅｌａｙに等しく設定される。この例では、メディアパケットの最後の受信側はシンクデバイス１であるので、ＴｒｉｇｇｅｒＤｅｌａｙ_source＝ＴｘＤｅｌａｙ₁である。このようにして、ソースデバイス４０Ａは、シンクデバイス４２のシンクキュー４６のすべてがメディアパケットで満たされるまで、メディアパケットの処理を開始するのを待つ。これらの技法によれば、ＴｒｉｇｇｅｒＤｅｌａｙ値は、シンクデバイス４２の各々およびソースデバイス４０Ａにおいて調整され（tailored）、スキューされる(skewed)。このようにして、ソースデバイス４０Ａおよびシンクデバイス４２のすべては、メディアデータの同期再生を与えるために同時にメディアパケットの処理を開始することになる。したがって、すべての参加しているデバイスは、所与の時間インスタンスにおいて同じビデオフレームを表示することになる。

[0062]上記で説明した第３の場合では、ユニバーサルキューサイズ決定中に、セッションマネージャ４１は、単なるシンクデバイスの各々におけるサポートキューサイズ以上のものに基づいて、すべてのシンクデバイス４２にわたる最小サポートキューサイズ、ＳｕｐｐｏｒｔｅｄＳｉｎｋＱＳｉｚｅ_minを計算する。最小サポートキューサイズは、シンクデバイスの各々のためのＴｒｉｇｇｅｒＤｅｌａｙ間隔をも考慮に入れる。この追加のパラメータは、シンクデバイスのいずれも、ＴｒｉｇｇｅｒＤｅｌａｙ間隔の間待つ間に次の着信メディアパケットを消失しないことを保証する。

[0063]たとえば、ソースデバイス４０Ａは、設定されたパケットレートに従ってシンクデバイス４２にメディアパケットを送る。１秒当たり１５（またはさらに少ない）パケットから１秒当たり１０００またはそれ以上のパケットまで、多種多様なパケットレートが使用され得る。パケットレートは、概して、パケットサイズとデータレートとに依存し得る。いくつかのシステムのための一般的なパケットレートは、１秒当たり１５〜６０パケットであり得る。しかしながら、シンクキューが満たされると、シンクデバイス４２は、パケット処理がシンクキュー中に追加のメディアパケットのためのスペースを作り始めるまで、追加のメディアパケットを受信することができない。場合によっては、送信スケジュールの最上位またはその近くにあるシンクデバイスは、シンクキューが満杯であることを検出することとパケット処理を開始することとの間の長いＴｒｉｇｇｅｒＤｅｌａｙ間隔の間待たなければならないことがある。これらのシンクデバイスは、シンクキュー中に着信パケットを保持するためのスペースがない場合、長い遅延中に着信パケットを消失する危険にさらされ得る。パケットレートは、通信セッションのためのビットレートに基づき得る。いくつかのデバイスのための例示的なビットレートは、限定はしないが、４００Ｋｂｐｓの絶対最小ビットレート、４Ｍｂｐｓの開始ビットレート、および１０Ｍｂｐｓの絶対最大ビットレートであり得る。ビットレートは、使用され得るビデオフォーマットに影響を及ぼし得、たとえば、表１を参照されたい。

[0064]パケット損失を回避するために、セッションマネージャ４１は、上記のように、ＴｒｉｇｇｅｒＤｅｌａｙ間隔を考慮に入れて最小サポートキューサイズを計算する。この最小サポートキューサイズは、セッションマネージャ４１が、すべてのシンクデバイス４２にわたってサポートされる最小キューサイズよりも小さくなるようにユニバーサルキューサイズを選択することを保証する。一例として、シンクデバイスのすべてが少なくとも５のキューサイズをサポートするとき、ユニバーサルキューサイズが４に等しくなるように選択することによって、シンクデバイスのすべては、それらのキュー中に、ＴｒｉｇｇｅｒＤｅｌａｙ間隔中の着信メディアパケットを保持するためのスペースを有することになる。

[0065]一例では、シンクデバイス４２のうちの１つまたは複数が通信セッション中に離れるか、または離脱し得る。ソースデバイス４０Ａは、シンクデバイス４２のうちのはずれたシンクデバイスにメディアパケットを送信することを停止することになる。ソースデバイス４０Ａおよび残りのシンクデバイス４２におけるパケット処理が同期し続けることを保証し、パケット損失を回避するために、ソースデバイス４０Ａは、はずれたシンクデバイスにメディアパケットを送信することの代わりに、ＴｘＴｉｍｅ、すなわち、ソースデバイス４０Ａにおける送信時間の間、休止する。休止の後に、ソースデバイス４０Ａは、はずれたシンクデバイスの後にパケットを受信するようスケジュールされたシンクデバイスに、メディアパケットを送信することを再開する。このようにして、メディアデータの同期再生は、シンクデバイスが通信セッションを離れた後に、送信スケジュールを再構成する必要なしに、またはシンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙ値を再計算する必要なしに続き得る。

[0066]別の例では、シンクデバイス４２のうちの１つまたは複数が、通信セッション中に加わり得る。シンクデバイスｎ＋１が、たとえば、通信セッションに加わるとき、ソースデバイス４０Ａのセッションマネージャ４１は、シンクデバイスｎ＋１を受信側リストの最上位に追加する。ソースデバイス４０Ａは、次いで、他のシンクデバイス４２のいずれかにパケットを送る前に、新しいシンクデバイスｎ＋１にメディアパケットを送る。さらに、セッションマネージャ４１は、新しいシンクデバイスｎ＋１を含むすべてのデバイスにおけるメディアデータの同期再生を保証するために、新しいシンクデバイスｎ＋１のためのＴｒｉｇｇｅｒＤｅｌａｙ値を計算する。

TriggerDelay_n+l = RxDelay₁ + RxDelay₂ + ... RxDelay_n.
[0067]したがって、トリガ遅延は、どのくらい多くのシンクデバイスがシステム中に存在するか、およびそれらがスケジュールされる順序に依存する。一般的な値は、ただ１つのシンクデバイスが存在する場合の０ミリ秒から、たとえば、セッションに参加しようとする８個のシンクデバイスがある場合の≦２．４〜１２ミリ秒までにわたり得る。

[0068]新しいシンクデバイスｎ＋１を受信側リストの最上位に追加することによって、新しいシンクデバイスは、すべての他のシンクデバイス４２のシンクキュー４６が満杯になるまで待つ必要があるので、新しいシンクデバイスは最長ＴｒｉｇｇｅｒＤｅｌａｙ間隔を有することになる。新しいシンクデバイスｎ＋１の後の送信スケジューリング順序は同じままであるので、後続のシンクデバイス４２のためのＴｒｉｇｇｅｒＤｅｌａｙ間隔は同じままである。このようにして、メディアデータの同期再生は、新しいシンクデバイスが通信セッションに加わった後に、既存のシンクデバイス４２のためのＴｒｉｇｇｅｒＤｅｌａｙ値を再計算する必要なしに続き得る。新しいシンクデバイスｎ＋１が通信セッションに追加されると、新しいシンクデバイスはソースデバイス４０Ａからメディアパケットを受信することを開始する。新しいシンクデバイスのシンクキューが満杯になると、新しいシンクデバイスは、ＴｒｉｇｇｅｒＤｅｌａｙ間隔の後に、ＷＤシステム中のすべての他のデバイスと同期してメディアパケットを処理することを開始する。

[0069]場合によっては、ＷＤシステムのレイテンシの必要または通信セッションのメディアコンテンツタイプに基づいて、ソースデバイス４０Ａのセッションマネージャ４１は、ＴｒｉｇｇｅｒＤｅｌａｙ値および／またはユニバーサルキューサイズを０または極めて小さい数に設定し得る。他の場合には、ソースデバイス４０Ａがシンクデバイス４２のうちの１つまたは複数とのアクティブ通信セッション中にないとき、ソースデバイス４０Ａは、ソースデバイス４０Ａにおけるローカル応答時間を改善するためにソースキュー４４を縮小および／またはバイパスし得る。この場合、ソースデバイス４０Ａにおけるメディアパケットは、パーサ１８からデコーダ２０に直接移動し得、シンクデバイス４２において受信されたメディアパケットは、受信機３０からデコーダ３２に直接移動し得る。

[0070]別の例では、ユニキャスト通信セッションは、ソースデバイス４０Ａとシンクデバイス４２の各々との間に確立され得る。この場合、ソースデバイス４０Ａのセッションマネージャ４１は、通信セッションに参加するシンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙを計算する。たとえば、ソースデバイス４０Ａのセッションマネージャ４１は、ＴｒｉｇｇｅｒＤｅｌａｙｘ＝ＲｘＤｅｌａｙ１＋ＲｘＤｅｌａｙ２＋．．．ＲｘＤｅｌａｙｘ−１としてシンクデバイスｘのＴｒｉｇｇｅｒＤｅｌａｙ値を計算し、ここで、ＲＸＤｅｌａｙｘはシンクデバイスｘにおける受信遅延である。シンクデバイス４２の各々のためのＴｒｉｇｇｅｒＤｅｌａｙは、シンクデバイスの各々が、すべてのシンクデバイスのシンクキューがメディアパケットで満たされるまで、データパケットの処理を開始するのを待つように計算され得る。ソースデバイス４０Ａのセッションマネージャ４１は、通信セッションセットアップの前またはその間のいずれかに、シンクデバイス４２の各々に、関連するＴｒｉｇｇｅｒＤｅｌａｙを通知する。

[0071]ソースデバイス４０Ａのセッションマネージャ４１はまた、ローカルソースＴｒｉｇｇｅｒＤｅｌａｙ値を計算する。ソースデバイス２０ＡのＴｒｉｇｇｅｒＤｅｌａｙ値は、メディアストリームの最後の受信側であるシンクデバイスのための送信遅延に等しく設定される。このようにして、ソースデバイス４０Ａは、シンクデバイス４２のシンクキュー４６のすべてがデータパケットで満たされるまで、データパケットの処理を開始するのを待つ。これらの技法によれば、ＴｒｉｇｇｅｒＤｅｌａｙ値は、シンクデバイス４２の各々およびソースデバイス４０Ａにおいて調整され、スキューされる。このようにして、ソースデバイス４０Ａとシンクデバイス４２のすべてとは、メディアデータの同期再生を与えるために同時にメディアパケットを処理することを開始することになる。

[0072]シンクデバイス４２Ａのキューモニタ４７Ａが、シンクキュー４６Ａが完全に満たされたことを検出したとき、キューモニタ４７Ａは、シンクデバイス４２Ａのための計算されたＴｒｉｇｇｅｒＤｅｌａｙ間隔の後にシンクキュー４６Ａ中のメディアパケットの処理を開始するようにデコーダ３２Ａをトリガする。概して、ＴｒｉｇｇｅｒＤｅｌａｙ間隔は、シンクキュー４６Ａが満杯であることを検出することと、メディアパケットの処理を開始することとの間の待ち時間を表す。シンクデバイス４２Ｂは、シンクデバイス４２Ｂのための計算されたＴｒｉｇｇｅｒＤｅｌａｙ間隔に基づいて同様に動作する。ソースデバイス４０Ａは、シンクデバイス４２Ａのシンクキュー４６Ａとシンクデバイス４２Ｂのシンクキュー４６Ｂの両方がデータパケットで満たされるまで、データパケットの処理を開始するのを待つ。ソースデバイス４０Ａのキューモニタ４３が、ソースキュー４４が完全に満たされたことを検出したとき、キューモニタ４３は、ローカルソースＴｘＤｅｌａｙの後にソースキュー４４中のデータパケットの理を開始するようにデコーダ２０をトリガする。このようにして、キューモニタ４３は、ソースデバイス４０Ａとシンクデバイス４２とが同時にメディアパケットの処理を開始することを保証する。

[0073]他の例では、本開示の技法は、マルチキャスト通信セッション、またはただ１つのシンクデバイスとのユニキャスト通信セッションなど、異なるタイプの通信セッションに適用され得る。これらの場合、本技法は、上記で説明したものと実質的に同様に動作し得るが、遅延間隔計算が変更される。たとえば、マルチキャストの場合、すべてのシンクデバイスがソースデバイスからデータパケットを同時に受信することになり、したがって異なるシンクデバイスのためのトリガ遅延は計算されない。同様に、単一のユニキャストの場合、ただ１つのシンクデバイスがソースデバイスからデータパケットを受信し、したがって単一のシンクデバイスのためのトリガ遅延は計算されない。

[0074]本技法はまた、すべてのデバイスにおける同期再生を達成するために、ソースデバイス４０Ａとシンクデバイス４２の各々との間の時間オフセットを考慮に入れ得る。たとえば、ソースデバイス４０Ａのセッションマネージャ４１は、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）を使用して、時間オフセットならびにソースデバイス４０Ａとシンクデバイス４２の各々との間の送信遅延を測定し得る。シンクデバイス４２の各々から受信したＲＴＣＰフィードバックに基づいて、ソースデバイス４０Ａは、ソースデバイス４０Ａにおけるローカルレンダリングのための提示タイムスタンプ（ＰＴＳ）を調整する。シンクデバイス４２の各々はまた、それぞれのシンクデバイスにおけるローカルレンダリングのためのＰＴＳを調整するために、他のシンクデバイス４２からＲＴＣＰフィードバックを受信し得る。

[0075]通信セッションは、１つまたは複数の通信チャネルを介した通信を含み得る。これらの通信チャネルは、比較的短距離の通信チャネルであり得、定義された２．４ＧＨｚ、３．６ＧＨｚ、５ＧＨｚ、６０ＧＨｚまたは超広帯域（ＵＷＢ）周波数帯域構造を実装するなど、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などと同様の物理チャネル構造を実装し得る。ただし、通信チャネルは、この点において必ずしも限定されるとは限らず、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。他の例では、通信チャネルは、ワイヤードまたはワイヤレスローカルエリアネットワーク、ワイドエリアネットワーク、あるいはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成することさえある。さらに、通信チャネルは、ピアツーピアリンクを作成するためにソースデバイス４０Ａとシンクデバイス４２とによって使用され得る。

[0076]ＷＦＤおよびＴＤＬＳは、比較的短距離の通信セッションをセットアップするように意図される。このコンテキストにおける比較的短距離は、たとえば、約７０メートル未満を指すことがあるが、雑音の多いまたは障害物のある環境では、デバイス間の距離は、約３５メートル未満、または約２０メートル未満など、さらに短いことがある。

[0077]本開示の技法について時々ＷＦＤに関して説明することがあるが、これらの技法の態様は他の通信プロトコルにも適合し得ることが企図される。限定ではなく例として、ソースデバイス４０Ａとシンクデバイス４２との間のワイヤレス通信は直交周波数分割多重化（ＯＦＤＭ）技法を利用し得る。限定はしないが、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、あるいはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡおよび／またはＣＤＭＡの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用され得る。

[0078]図４は、本開示の技法による、ソースデバイス４０Ｂと、フレームバッファモードでの同期通信セッションに参加することが可能なシンクデバイス４２とを含むＷＤシステムを示すブロック図である。ソースデバイス４０Ｂは、個々のデバイスにおけるメディアパケットの同期再生を行うために、ソースデバイス４０Ｂおよびシンクデバイス４２において使用するためのユニバーサルキューサイズを選択することと、シンクデバイス４２の各々のトリガ遅延値を計算することとに関して、図３からのソースデバイス４０Ａと実質的に同様に動作する。ソースデバイス４０Ｂは、図３のソースデバイス４０Ａに示したメディア処理パイプラインの代替メディア処理パイプラインを示している。図４に示したフレームバッファモードでは、ソースデバイス４０Ｂは、メディアフレームをキャプチャし、符号化し、ソースデバイス４０Ｂに送信する。メディア処理パイプラインのこの段階において、ソースデバイス４０Ａはメディアコンテンツを復号する必要がない。

[0079]図４の図示の例では、ソースデバイス４０Ａと同様に、ソースデバイス４０Ｂは、セッションマネージャ４１と、キューモニタ４３と、ユニバーサルキューサイズを有するソースキュー４４と、記憶されたコンテンツ１６と、ローカルディスプレイ２４と、送信機（ＴＸ）２６とを含む。ソースデバイス４０Ｂは、ディスプレイプロセッサ５２と、フレームバッファ５４と、ディスプレイドライバホスト５８と、ディスプレイドライバクライアント６０と、ビデオプロセッサ６２と、スクリーンキャプチャモジュール６３と、エンコーダ６４と、トランスポートモジュール６６とをさらに含む。ディスプレイプロセッサ５２は、生ピクセルフォーマット（たとえば、ＲＧＢ、ＹＵＶ、ＹＣｂＣｒ）での出力を生成するディスプレイプロセッサを表す。生ピクセルデータは、最初にフレームバッファ５４中に保持される。ディスプレイドライバホスト５８、たとえばモバイルディスプレイデジタルインターフェース（ＭＤＤＩ）ホストドライバは、フレームバッファ５４からディスプレイドライバクライアント６０にメディアコンテンツをプッシュするドライバを表す。ディスプレイドライバクライアント６０は、ローカルディスプレイ２４におけるメディアコンテンツのレンダリングを制御する。

[0080]ソースデバイス４０Ｂのセッションマネージャ４１は、本開示で説明する技法による、フレームバッファモードでのシンクデバイス４２との同期通信セッションを確立し得る。フレームバッファモードでは、ソースデバイス４０Ｂは、図３からのソースデバイス４０Ａに関して上記で説明したのと同様の手法を使用する。たとえば、セッションマネージャ４１は、シンクデバイス４２のサポートキューサイズに基づいてユニバーサルキューサイズを選択する。ユニバーサルキューサイズが選択され、参加しているデバイスが通知されると、ソースデバイス４０Ｂは、ユニバーサルキューサイズを有するソースキュー４４を生成し、シンクデバイス４２は、ユニバーサルキューサイズを有するシンクキュー４６を生成する。ソースデバイス４０Ｂのセッションマネージャ４１はまた、参加するシンクデバイス４２の各々のためのＴｘＤｅｌａｙと、ＲｘＤｅｌａｙと、ＴｒｉｇｇｅｒＤｅｌａｙとを計算し、次いで、それぞれのシンクデバイス４２に遅延間隔値を通知する。フレームバッファモードでは、キューモニタ４３が、ディスプレイプロセッサ５２と、ディスプレイドライバホスト５８と、トランスポートモジュール６６とから出力されるメディアコンテンツの処理を調整する。

[0081]上述のように、ソースデバイス４０Ｂは代替メディア処理パイプラインを示しており、その中でソースデバイス４０Ｂはすでに、復号されたメディアコンテンツを使用してローカルディスプレイ２４上でそれをレンダリングする。シンクデバイス４２は、しかしながら、依然として、受信したメディアフレームを復号する必要がある。ＴｘＤｅｌａｙ値を計算するとき、ソースデバイス４０Ｂは、シンクデバイス４２の各々における復号時間を考慮に入れ得る。

[0082]ユニバーサルキューサイズを有するソースキュー４４がソースデバイス４０Ｂにおいて生成された後に、ディスプレイプロセッサ５２は、ローカルディスプレイ２４上にメディアフレームを表示するために、フレームバッファ５４中に記憶されたコンテンツ１６からメディアフレームを作成する。各メディアフレームはまた、スクリーンキャプチャモジュール６３によってキャプチャされ、エンコーダ６４によって符号化され、送信機（ＴＸ）２６によって参加するシンクデバイス４２の各々に送信さる。キューモニタ４３は、符号化および送信を含むソースデバイス３０Ｂのメディア処理パイプライン中で各メディアフレームを追跡する。所与のメディアフレームがシンクデバイス４２に送信されると、キューモニタ４３はフレームバッファ５４からソースキュー４４に、対応するメディアフレームを移動する。キューモニタ４３が、ソースキュー４４が満たされたことを検出したとき、キューモニタ４３は、ＴｘＤｅｌａｙを待ち、次いでメディアフレームをレンダリングすることを開始するように、ディスプレイドライバホスト５８をトリガする。このようにして、ソースデバイス４０Ａは、すべてのシンクデバイス４２が同じフレームを受信し、処理することを開始するのに十分な時間を有するまで、ローカルディスプレイ２４上での表示のためにメディアフレームを処理することを開始するのを待つ。

[0083]図３に関して上記で説明したように、シンクデバイス４２Ａにおけるキューモニタ４７Ａが、たとえば、シンクキュー４６Ａが満たされたことを検出したとき、キューモニタ４７Ａは、シンクデバイス４２ＡのためのＴｒｉｇｇｅｒＤｅｌａｙ間隔の後にメディアフレームを処理することを開始するようにデコーダ３２Ａをトリガする。通信セッションがシンクデバイス４２Ａのみと確立されるとき、または、通信セッションが複数のシンクデバイスとのマルチキャストセッションであるとき、デコーダ３２Ａは、シンクキュー４６Ａが満たされるとすぐにメディアフレームの処理を開始することができるので、ＴｒｉｇｇｅｒＤｅｌａｙ間隔値は０に等しい。複数の通信セッションが複数のシンクデバイスと確立されるとき、ソースデバイス４０Ｂのセッションマネージャ４１は、シンクデバイスの各々のためのＴｒｉｇｇｅｒＤｅｌａｙ間隔を計算する。このようにして、シンクデバイス４２の各々は、すべてのシンクデバイス４２が同じフレームを受信し、処理を開始するのに十分な時間を有するまで、受信したメディアフレームを処理することを開始するのを待つ。

[0084]図５は、ソースデバイス４０Ａと参加しているシンクデバイス４２との間の通信セッションのためのユニバーサルキューサイズを選択するために使用される例示的な情報交換を示す論理図である。説明のために、通信セッションは、ＷＤシステムのためのソリューションを使用するソースデバイス４０Ａによってセットアップされると仮定され得る。たとえば、ソースデバイス４０Ａおよびシンクデバイス４２Ａ〜４２Ｂは、通信セッションに参加しているデバイスを識別するためにデバイスディスカバリを実行する。ソースデバイス４０Ａのセッションマネージャ４１は、ソースデバイス４０Ａが、共有すべきコンテンツを有することを広告し、シンクデバイス４２Ａがそのコンテンツを受信することに関心があるかどうかを決定するために、シンクデバイス４２Ａのセッションマネージャ４５Ａとのディスカバリ通信７６Ａを開始し得る。ソースデバイス４０Ａのセッションマネージャ４１はまた、ソースデバイス４０Ａが、共有すべきコンテンツを有することを広告し、シンクデバイス４２Ｂがそのコンテンツを受信することに関心があるかどうかを決定するために、シンクデバイス４２Ｂのセッションマネージャ４５Ｂとのディスカバリ通信７６Ｂを開始し得る。

[0085]ソースデバイス４０Ａのセッションマネージャ４１が、広告されたコンテンツのためにシンクデバイス４２Ａとの通信セッションを確立したいという要求を受信したとき、セッションマネージャ４１は、シンクデバイス４２Ａのセッションマネージャ４５Ａに、このタイプのメディアデータのためのサポートキューサイズについてのクエリ７８Ａを送る（「Ｑサイズを問い合わせる」）。セッションマネージャ４５Ａは、次いで、セッションマネージャ４１にシンクデバイス４２Ａのためのサポートキューサイズを含む応答８０Ａを送る（「Ｑサイズで応答する」）。同様に、ソースデバイス４０Ａのセッションマネージャ４１が、広告されたコンテンツのためにシンクデバイス４２Ｂとの通信セッションを確立したいという要求を受信したとき、セッションマネージャ４１は、シンクデバイス４２Ｂのセッションマネージャ４５Ｂに、このタイプのメディアデータのためのサポートキューサイズについてのクエリ７８Ｂを送る（「Ｑサイズを問い合わせる」）。セッションマネージャ４５Ｂは、次いで、セッションマネージャ４１にシンクデバイス４２Ｂのためのサポートキューサイズを含む応答８０Ｂを送る（「Ｑサイズで応答する」）。

[0086]問い合わせられたシンクデバイス４２から応答を受信すると、ソースデバイス４０Ａにおけるセッションマネージャ４１は、次いで、通信セッション中にすべての参加しているデバイスにおいて使用するためのユニバーサルキューサイズを選択する。ソースデバイス４０Ａのセッションマネージャ４１は、次いで、それ自体のメディア処理パイプラインにユニバーサルキューサイズの通知８２を送り（「Ｑサイズを選択する」）、シンクデバイス４２Ａのセッションマネージャ４５Ａにユニバーサルキューサイズの通知８４Ａを送り（「Ｑサイズを設定する」）、シンクデバイス４２Ｂのセッションマネージャ４５Ｂにユニバーサルキューサイズの通知８４Ｂを送る（「Ｑサイズを設定する」）。ユニバーサルキューサイズ値は、所定の様式、たとえば、持続時間、フレームの数などで提示され得る。言い換えれば、ユニバーサルキューサイズは、たとえば、ある持続時間のビデオ、またはある数のビデオフレームを記憶する能力に基づき得る。したがって、ユニバーサルキューサイズは、１秒、１０秒、２０秒またはそれ以上のビデオを記憶することに基づき得る。いくつかのデバイスは、より長い持続時間のビデオを記憶し得、他のデバイスは、より短い持続時間を記憶し得る。さらに、所与のユニバーサルキューサイズのための記憶される持続時間は、ビデオのために使用される１秒当たりのビット数に基づいて変動し得ることを理解されよう。異なるビデオフォーマットおよびビットレートのための例を表１に与える。したがって、３０ｆｐｓにおける１０８０ｐと公称ビットレートとの１０Ｍｂｐｓを仮定すると、１０秒のビデオを記憶するためのユニバーサルキューサイズは１００Ｍｂであろう。ユニバーサルキューサイズは、代替的に、ある数のビデオフレームを記憶することに基づき得る。したがって、特定のビデオフォーマットのためのフレームが３３，３３３．３ビットを必要とすると仮定すると、デバイスが３０フレームを記憶するように設計された場合、ユニバーサルキューは１Ｍｂを記憶し得る。

[0087]いくつかの例では、キューサイズは、ビデオのコンテンツに基づいて定義され得る。たとえば、高動きビデオはより多くのデータを必要とし、したがって、より大きいキューサイズが選択され得る。必要とされない限り過大なレイテンシまたは遅延がないことを保証するために、異なるビデオは異なるキューサイズを定義するように、キューサイズは特定のシーケンスに関連するコンテンツまたはビットレートに基づき得る。

[0088]いくつかの例では、セッションマネージャ４１はまた、セッションマネージャ４５の各々に、シンクデバイス４２の各々のために計算されたトリガ遅延または他の遅延間隔値を通知し得る。この遅延間隔は、メディアパケットの処理を遅延させるために使用され得る。

[0089]ソースデバイス４０Ａのセッションマネージャ４１は、次いで、シンクデバイス４２Ａとの通信セッション８６Ａを開始し、シンクデバイス４２Ｂとの通信セッション８６Ｂを開始し得る。通信セッション中、ソースデバイス４０Ａおよびシンクデバイス４２は、ユニバーサルキューサイズを有するキューと関連する遅延間隔とを使用してメディアパケットの同期処理を保証するであろう。このようにして、本開示の技法は、ソースデバイス４０Ａおよびシンクデバイス４２の各々におけるメディアデータの同期表示を与える。

[0090]図６は、本開示の技法による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な動作を示す流れ図である。図示した動作について、図３からのソースデバイス４０Ａとシンクデバイス４２とに関して説明する。図示した動作はまた、図４からのソースデバイス４０Ｂとともに使用され得る。

[0091]ソースデバイス４０Ａのセッションマネージャ４１は、ソースデバイス４０Ａが、通信セッションを介して１つまたは複数のシンクデバイス４２と共有すべきコンテンツ、たとえば、オーディオおよび／またはビデオコンテンツを有することを広告する（９０）。シンクデバイス４２のうちの１つまたは複数のセッションマネージャ４５は、通信セッションに参加することを要求することによってこの広告に応答する（９１）。要求を受信すると、ソースデバイス４０Ａのセッションマネージャ４１は、要求元シンクデバイス４２との通信セッションを確立する（９２）。セッションマネージャ４１は、次いで、シンクデバイス４２の各々における通信セッションのためのサポートキューサイズを知るために、シンクデバイス４２に問い合わせる（９３）。シンクデバイス４２のセッションマネージャ４５の各々は、通信セッションのためのそれのサポートキューサイズで応答する（９４）。

[0092]シンクデバイス４２のためのサポートキューサイズを受信すると、ソースデバイス４０Ａのセッションマネージャ４１は、シンクデバイスのサポートキューサイズに基づいて通信セッションのためのユニバーサルキューサイズを選択する（９５）。セッションマネージャ４１は、図３に関して上記で説明したようにユニバーサルキューサイズを選択し得る。シンクデバイス４２の各々は、次いで、ソースデバイス４０Ａから、通信セッションのために使用されるべきユニバーサルキューサイズの通知を受信する（９６）。ソースデバイス４０Ａおよびシンクデバイス４２の各々は、ユニバーサルキューサイズを有するキューを生成する。

[0093]ソースデバイス４０Ａは、次いで、通信セッションの一部としてシンクデバイス４２にパケットを送る（９８）。ソースデバイス４０Ａにおいて、キューモニタ４３は、ユニバーサルキューサイズを有するソースキュー４４中にパケットを保持する（１０２）。キューモニタ４３はソースキュー４４を監視する。キューモニタ４３が、ソースキュー４４が満杯であることを検出する（１０４）と、ソースデバイス４０Ａは、遅延間隔の間待って（１０６）から、シンクデバイス４２と同期してパケットを処理することを開始する（１０８）。キューモニタ４３が、ソースキュー４４が満杯であることを検出した（１０４）ときと、ソースデバイス４０Ａがシンクデバイス４２と同期してパケットを処理することを開始する（１０８）ときとの間の遅延間隔は、図３に関して上記で説明したように計算され得る。たとえば、通信セッションが１つのソースデバイスとのユニキャストセッションまたはマルチキャストセッションであるとき、遅延間隔は、ソースデバイス４０Ａとシンクデバイス４２との間の送信遅延間隔であり得る。別の例として、通信セッションが複数のユニキャストセッションであるとき、遅延間隔は、すべてのシンクデバイス４２がパケットを受信するまでのトリガ遅延間隔であり得る。

[0094]ソースデバイス４０Ａがパケットを送信した（９８）後、シンクデバイス４２の各々はソースデバイス４０Ａからパケットを受信する（１００）。シンクデバイス４２Ａにおいてパケットを受信すると、たとえば、キューモニタ４７Ａは、ユニバーサルキューサイズを有するシンクキュー４６Ａ中にパケットを保持する（１１０）。キューモニタ４７Ａはシンクキュー４６Ａを監視する。キューモニタ４７Ａがシンクキュー４６Ａが満杯であることを検出する（１１２）と、シンクデバイス４２は、遅延間隔の間待って（１１４）から、ソースデバイス４０Ａおよび他の参加しているシンクデバイス４２と同期してパケットを処理することを開始する（１１６）。同様のプロセスが、通信セッションに参加しているシンクデバイス４２の各々において行われる。キューモニタ４７Ａがシンクキュー４６Ａが満杯であることを検出した（１１２）ときと、シンクデバイス４２Ａがソースデバイス４０Ａおよび他のシンクデバイス４２と同期してパケットを処理することを開始する（１１６）ときとの間のオプションの遅延間隔は、図３に関して上記で説明したように計算され得る。たとえば、通信セッションが１つのソースデバイスとのユニキャストセッションまたはマルチキャストセッションであるとき、遅延間隔は０に等しくなり得る。この場合、シンクデバイス４２Ａは、シンクキュー４６Ａが満杯になるとすぐに、パケットを処理することを開始し得る。別の例として、通信セッションが複数のユニキャストセッションであるとき、遅延間隔は、すべての他の参加しているシンクデバイス４２がパケットを受信するまでのトリガ遅延間隔であり得る。

[0095]図７は、本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図である。図７の例示的な方法は、ソースデバイスの観点からある。通信セッションを確立することは、（１）ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、（２）ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、（３）ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを含み得る。

[0096]図７の例示的な方法では、ソースデバイス４０Ａは、１つまたは複数のシンクデバイス４２との通信セッションを確立する（７００）。通信セッションは、たとえば、ソースデバイス１０、４０Ａと１つまたは複数のシンクデバイス４２Ｂとの間のメディア共有セッションであり得る。一例では、ソースデバイス４０Ａと１つまたは複数のシンクデバイス４２との間のメディア共有セッションなどの通信セッションを確立することは、たとえば、通信セッションの一部としてシンクデバイス４２の各々にデータパケットを送信することを含み得る。

[0097]ソースデバイス４０Ａは、シンクデバイス４２の各々に、通信セッションのために選択され得るユニバーサルキューサイズを通知する（７０２）。ソースデバイス４０Ａは、ソースデバイス４０Ａおよび複数のシンクデバイス４２のサポートキューサイズに基づいてユニバーサルキューサイズを選択する。選択はまた、ソースデバイス４０Ａにおけるパケットレートと、シンクデバイスの各々における送信遅延間隔、受信遅延間隔、またはトリガ遅延間隔のうちの１つとに基づき得る。1秒当たり１５（またはさらに少ない）パケットから１秒当たり２００またはより多いパケットまでの多種多様なパケットレートが選択され得る。

[0098]一例では、方法は、シンクキューが満杯であることを検出することと、シンクキュー中のデータパケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、シンクデバイスの各々のためのトリガ遅延間隔を計算または測定し得る。シンクデバイスの各々は、それらのそれぞれのトリガ遅延間隔が通知される。

[0099]ソースデバイス４０Ａのユニット２６は、シンクデバイス４２Ａ、４２Ｂの各々にデータパケットを送る。たとえば、ソースデバイス４０Ａは、通信セッションの一部としてシンクデバイス４２にデータパケットを送る（９８）。別の例では、シンクデバイス４２は、ユニバーサルキューサイズを有するシンクキュー４６中にデータパケットを保持する（７０４）。別の例では、ソースデバイス４０Ａのキューモニタ４３は、ユニバーサルキューサイズを有するソースキュー４４中にデータパケットを保持する（７０６）。

[00100]ソースキュー４４が満杯であることを検出すると、ソースデバイス４０Ａは、ソースデバイスにおける表示のためソースキュー中のデータパケットの処理を開始する（７０８）。たとえば、ソースデバイス４０Ａのキューモニタ４３はソースキュー４４を監視し得る。キューモニタ４３が、ソースキュー４４が満杯であることを検出すると、ソースデバイス４０Ａは、遅延間隔の間待ってから、シンクデバイス４２と同期してパケットを処理することを開始する。さらに、ソースデバイスにおける処理は、シンクデバイスにおけるデータパケットの処理と同期し得る。

[00101]いくつかの例では、ソースデバイス４０Ａはさらに、サポートキューサイズについてシンクデバイス４２の各々に問い合わせ得る。したがって、ソースデバイス４０Ａは、シンクデバイス４２とのユニバーサルキューサイズを選択し得る。ユニバーサルキューサイズは、ソースデバイス４０Ａおよびシンクデバイス４２のサポートキューサイズに基づき得る。ソースデバイス４０Ａはさらに、ソースデバイス４０Ａのためのトリガ遅延間隔を測定し得る。トリガ遅延間隔は、最後のシンクデバイス４２がデータパケットを受信するための時間間隔を表し得る。さらに、ソースキュー４４が満杯であることを検出すると、ソースデバイス４０Ａは、トリガ遅延間隔の間待ってから、ソースキュー中のデータパケットの処理を開始し得る。

[00102]図８は、本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図である。図８の例示的な方法はシンクデバイスの観点からである。

[00103]図８の例示的な方法では、ソースデバイス４０Ａは、シシンクデバイス４２とソースデバイス４０Ａとの間の通信セッションを確立する（８００）。たとえば、ソースデバイス４０Ａは、特定のメディアセッションに参加しているシンクデバイス４２のうちの１つまたは複数に、オーディオおよび／またはビデオ（ＡＶ）データなどのメディアデータを送り得る。上記で説明したように、メディアデータは、ソースデバイスのローカルディスプレイと、シンクデバイスのディスプレイの各々との両方において再生され得る。より詳細には、参加しているシンクデバイス４２の各々は、それのスクリーンおよびオーディオ機器上で、受信されたメディアデータをレンダリングし得る。場合によっては、シンクデバイス４２のユーザは、タッチ入力およびリモート制御入力など、ユーザ入力をシンクデバイス４２に適用し得る。ＷＤシステムでは、ユーザ入力はシンクデバイス４２からソースデバイス４０Ａに送られる。ソースデバイス４０Ａは、シンクデバイス４２から受信したユーザ入力を処理し、シンクデバイスに送られた後続のメディアデータにユーザ入力の効果を適用する。

[00104]シンクデバイス４２はソースデバイス４０Ａからユニバーサルキューサイズの通知を受信する。ソースデバイス４０Ａは通信セッションのためのユニバーサルキューサイズを選択する（８０２）。たとえば、シンクデバイス４２の各々は、ソースデバイス４０Ａから通信セッションのために使用されるべきユニバーサルキューサイズの通知を受信する（９６）。ソースデバイス４０Ａおよびシンクデバイス４２の各々は、ユニバーサルキューサイズを有するキューを生成し得る。

[00105]シンクデバイス４２はソースデバイス４０Ａからデータパケットを受信する。データパケットは、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され得る。さらに、受信されたデータパケットを、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持する（８０４）。

[00106]シンクキュー４６が満杯であることを検出すると、シンクデバイス４２は、シンクデバイス４２における表示のためシンクキュー４６中のデータパケットの処理を開始する。シンクデバイス４２における処理はソースデバイス４０Ａにおけるデータパケットの処理と同期する（８０８）。たとえば、キューモニタ４７Ａがシンクキュー４６Ａが満杯であることを検出する（１１２）と、シンクデバイス４２は、場合によっては、遅延間隔の間待って（１１４）から、ソースデバイス４０Ａおよび他の参加しているシンクデバイス４２と同期してパケットを処理することを開始する（１１６）。同様のプロセスが、通信セッションに参加しているシンクデバイス４２の各々において行われ得る。キューモニタ４７Ａがシンクキュー４６Ａが満杯であることを検出した（１１２）ときと、シンクデバイス４２Ａがソースデバイス４０Ａおよび他のシンクデバイス４２と同期してパケットを処理することを開始する（１１６）ときとの間のオプションの遅延間隔は、図３に関して上記で説明したように計算され得る。

[00107]例示的な方法ではさらに、シンクデバイスのサポートキューサイズを報告するためのソースデバイスからのクエリに応答し得る。さらに、ユニバーサルキューサイズは、ソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてソースデバイスによって選択され得る。

[00108]一例では、シンクデバイスのためのトリガ遅延間隔の通知がソースデバイスから受信され得る。トリガ遅延間隔は、通信セッションに参加している他のシンクデバイスの最後がメディアパケットを受信するための時間間隔を表し得る。例示的な方法では、シンクキューが満杯であることを検出すると、トリガ遅延間隔の間待ってから、シンクキュー中のデータパケットの処理を開始する。

[00109]図９は、本開示で説明する１つまたは複数の例による、ソースデバイスとシンクデバイスとの間の通信セッションを同期させる例示的な方法を示す流れ図である。図９の例示的な方法はシンクデバイスの観点からである。

[00110]図９の例では、シンクデバイス４２は、ソースデバイス４０Ａに通信セッションを確立することを要求する（９００）。通信セッションは、（１）ソースデバイスとシンクデバイスのみとの間のユニキャスト通信セッションと、（２）ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、（３）ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを含み得る。一例では、シンクデバイス４２のためのトリガ遅延間隔は０に等しくなり得る。

[00111]別の例では、通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作し得る。たとえば、上記で説明したように、確立されると、通信セッションは、図１および図２に示したように、ソースデバイスが記憶された符号化メディアストリームを送信するストリーミングモードで動作するか、または図４に示したように、ソースデバイスがディスプレイバッファをキャプチャし、符号化し、送信するフレームバッファモードで動作し得る。

[00112]シンクデバイス４２は、ソースデバイス４０Ａからユニバーサルキューサイズの通知を受信する（９０２）。ソースデバイス４０Ａは、少なくともソースデバイス４０Ａおよび（１つまたは複数の）シンクデバイス４２のサポートキューサイズに基づいてユニバーサルキューサイズを選択し得る。さらに、ユニバーサルキューサイズは、通信セッションに参加しているすべてのシンクデバイス４２にわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択され得る。一例では、シンクデバイス４２は、シンクデバイス４２のサポートキューサイズを報告するためのソースデバイス４０Ａからのクエリに応答し得る。

[00113]（１つまたは複数の）シンクデバイス４２は、通信セッションの一部としてソースデバイス４０Ａからデータパケットを受信する（９０４）。たとえば、ソースデバイス４０Ａがパケットを送った後、シンクデバイス４２の各々はソースデバイス４０Ａからパケットを受信する。さらに、データパケットは、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され得る。

[00114]シンクデバイス４２は、ユニバーサルキューサイズを有するシンクキュー中にデータパケットを保持する（９０６）。たとえば、シンクデバイス４２は、ソースデバイス４０Ａからトリガ遅延間隔の通知を受信し得る。このトリガ遅延はシンクデバイス４２のものであり得る。トリガ遅延間隔は、通信セッションに参加している他のシンクデバイスの最後がデータパケット、たとえば、メディアパケットを受信するための時間間隔を表し得る。

[00115]シンクキュー４６が満杯であることを検出すると、シンクデバイス４２は、シンクデバイス４２における表示のためシンクキュー４６中のデータパケットの処理を開始する。シンクデバイス４２におけるパケット処理はソースデバイス４０Ａにおけるパケット処理と同期する（９０８）。一例では、シンクキュー４６が満杯であることを検出すると、シンクデバイス４２は、トリガ遅延間隔の間待ってから、シンクキュー４６中のデータパケットの処理を開始し得る。

[00116]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装された場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータデータ記憶媒体または通信媒体を含み得る。いくつかの例では、コンピュータ可読媒体は非一時的コンピュータ可読媒体を備え得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。

[00117]限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリなど、非一時的媒体、あるいは命令またはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

[00118]コードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路などの１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。

[00119]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。

[00120]様々な実施形態について説明した。これらおよび他の実施形態は以下の特許請求の範囲内に入る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］ ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、
前記シンクデバイスのうちの少なくとも１つに、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズを通知することと、
前記シンクデバイスの各々にデータパケットを送ることと、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持することと、
前記ソースキューが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始することと、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
を備える方法。
［２］ 前記通信セッションは、前記ソースデバイスと１つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、［１］に記載の方法。
［３］ サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
をさらに備える、［１］に記載の方法。
［４］ 前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、
前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、
をさらに備える、［１］に記載の方法。
［５］ 前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
をさらに備える、［１］に記載の方法。
［６］ 前記通信セッションを確立することは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、［１］に記載の方法。
［７］ 特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせることをさらに備える、［１］に記載の方法。
［８］ 前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知することをさらに備える、［１］に記載の方法。
［９］ 前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように前記ユニバーサルキューサイズを選択することを備える、［１］に記載の方法。
［１０］ 前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいて、すべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算することをさらに備える、［９］に記載の方法。
［１１］ 前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケットレートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの１つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、［１］に記載の方法。
［１２］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備え、
前記ソースデバイスと前記シンクデバイスのうちの１つとの間の送信遅延間隔を測定することと、
前記ソースキューが満杯であることを検出すると、前記送信遅延間隔の間待ってから前記ソースキュー中の前記パケットの処理を開始することと、
をさらに備える、［１］に記載の方法。
［１３］ 前記通信セッションは、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションを備え、
前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、
前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記パケットの処理を開始する前に、前記送信遅延間隔の間待つことと、
をさらに備える、［１］に記載の方法。
［１４］ 別のシンクデバイスによってサポートされる前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外することをさらに備える、［１］に記載の方法。
［１５］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は０に等しい、［１４］に記載の方法。
［１６］ 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、［１］に記載の方法。
［１７］ ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、
前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記ユニバーサルキューサイズは、少なくとも前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて選択され、
前記通信セッションの一部として前記ソースデバイスからデータパケットを受信することと、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持することと、
前記シンクキューが満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始することと、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期する、開始することと
を備える方法。
［１８］ 前記通信セッションは、前記ソースデバイスと前記シンクデバイスのみとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、［１７］に記載の方法。
［１９］ 前記シンクデバイスの前記サポートキューサイズを報告するための前記ソースデバイスからのクエリに応答することをさらに備える、［１７］に記載の方法。
［２０］ 前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、［１７］に記載の方法。
［２１］ 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、
をさらに備える、［１７］に記載の方法。
［２２］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は０に等しい、［１７］に記載の方法。
［２３］ 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、［１７］に記載の方法。
［２４］ 第２のシンクデバイスが前記ソースデバイスとのすでに確立された通信セッションに加わることをさらに備える、［１７］に記載の方法。
［２５］ 前記シンクデバイスが、データパケットのセットの完了する前に、前記ソースデバイスとのすでに確立された通信セッションを終了すること、をさらに備える［１７］に記載の方法。
［２６］ ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択することと、送信機に前記通信セッションのために選択された前記ユニバーサルキューサイズの通知をシンクデバイスに送信させることと、を行うように構成されたプロセッサと、前記送信機は、前記通信セッションの一部として前記シンクデバイスの各々にデータパケットを送り、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
前記パケットを保持する前記ユニバーサルキューサイズを有するソースキューと、
を備え、
前記ソースキューが満杯であることを検出すると、前記プロセッサは前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットを処理することを開始し、前記ソースデバイスにおける前記データパケット処理が前記シンクデバイスにおけるパケット処理と同期する、ソースデバイス。
［２７］ 前記通信セッションは、前記ソースデバイスと１つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、［２６］に記載のソースデバイス。
［２８］ 前記プロセッサは、さらに、
サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
を行うように構成された、［２６］に記載のソースデバイス。
［２９］ 前記プロセッサは、さらに、
前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、
前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、
を行うように構成された、［２６］に記載のソースデバイス。
［３０］ 前記プロセッサは、さらに、
前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
を行うよう構成された、［２６］に記載のソースデバイス。
［３１］ 前記通信セッションを確立することは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、［２６］に記載のソースデバイス。
［３２］ 前記プロセッサは、さらに、特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせるように構成された、［２６］に記載のソースデバイス。
［３３］ 前記プロセッサは、さらに、前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知するように構成された、［２６］に記載のソースデバイス。
［３４］ 前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しいように前記ユニバーサルキューサイズを選択することを備える、［２６］に記載のソースデバイス。
［３５］ 前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいてすべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算するように構成された、［３４］に記載のソースデバイス。
［３６］ 前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケットレートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの１つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、［２６］に記載のソースデバイス。
［３７］ 前記プロセッサは、さらに、
前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
を行うように構成された、［２６］に記載のソースデバイス。
［３８］ 前記通信セッションが、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は０に等しい、［３７］に記載のソースデバイス。
［３９］ 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、［２６］に記載のソースデバイス。
［４０］ 前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外するようにさらに構成された、［２６］に記載のソースデバイス。
［４１］ ソースデバイスにシンクデバイスとの通信セッションを確立することを要求するように構成されたプロセッサと、
前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記ユニバーサルキューサイズは、少なくとも前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて選択され、前記通信セッションの一部として前記ソースデバイスからパケットを受信することと、を行う受信機と、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
前記パケットを保持する前記ユニバーサルキューサイズを有するシンクキューと、前記シンクキューが満杯のことを検出すると、前記プロセッサは、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットを処理することを開始し、前記シンクデバイスにおける前記パケット処理は少なくとも前記ソースデバイスにおけるパケット処理と同期する、
を備えるシンクデバイス。
［４２］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを備える、［４１］に記載のシンクデバイス。
［４３］ 前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答するように構成された、［４１］に記載のシンクデバイス。
［４４］ 前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、［４１］に記載のシンクデバイス。
［４５］ 前記プロセッサは、さらに、
前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、
を行うように構成された、［４１］に記載のシンクデバイス。
［４６］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は０に等しい、［４１］に記載のシンクデバイス。
［４７］ 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、［４１］に記載のシンクデバイス。
［４８］ 前記プロセッサは、前記シンクデバイスに、前記ソースデバイスとのすでに確立された通信セッションに参加させ、提示に参加させるように構成され、さらに、前記シンクデバイスに、データパケットのセットの完了の前に、前記ソースデバイスとのすでに確立された通信セッションを終了するように構成された、［４１］に記載のシンクデバイス。
［４９］ ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立する手段と、
前記シンクデバイスの各々に、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズを通知する手段と、
前記シンクデバイスの各々にデータパケットを送る手段と、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持する手段と、
前記ソースキューが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する手段と、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
を備えるソースデバイス。
［５０］ サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
を行う手段をさらに備える、［４９］に記載のソースデバイス。
［５１］ 前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、
前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと
を行う手段をさらに備える、［４９］に記載のソースデバイス。
［５２］ ソースデバイスにシンクデバイスとの通信セッションを確立することを要求する手段と、
前記ソースデバイスからユニバーサルキューサイズの通知を受信する手段と、前記ユニバーサルキューサイズは、少なくとも前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて選択され、
前記通信セッションの一部として前記ソースデバイスからデータパケットを受信する手段と、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持する手段と、
前記シンクキューが満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始する手段と、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期する、
を備えるシンクデバイス。
［５３］ 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを備える、［５２］に記載のシンクデバイス。
［５４］ 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信する手段と、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つための手段と、
をさらに備える、［５２］に記載のシンクデバイス。
［５５］ ソースデバイス中で実行されたとき、プロセッサに、
前記ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、
前記シンクデバイスの各々に、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズを通知することと、
前記シンクデバイスの各々にデータパケットを送ることと、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持することと、
前記ソースキューが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始することと、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
を行わせる命令を備えるコンピュータ可読媒体。
［５６］ ソースデバイス中で実行されたとき、プロセッサに、
サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
を行わせる命令をさらに備える、［５５］に記載のコンピュータ可読媒体。
［５７］ ソースデバイス中で実行されたとき、プロセッサに、
前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、
前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、
を行わせる命令をさらに備える、［５５］に記載のコンピュータ可読媒体。
［５８］ シンクデバイス中で実行されたとき、プロセッサに、
ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、
前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記ユニバーサルキューサイズは、少なくとも前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて選択され、
前記通信セッションの一部として前記ソースデバイスからパケットを受信することと、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記パケットを保持することと、
前記シンクキューが満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始することと、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期する、
を行わせる命令を備えるコンピュータ可読媒体。
［５９］ ソースデバイス中で実行されたとき、プロセッサに、
前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、
を行わせる命令をさらに備える、［５８］に記載のコンピュータ可読媒体。
［６０］ シンクデバイスとソースデバイスとの間の通信セッションを確立することと、
前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記ユニバーサルキューサイズは、前記通信セッションのために前記ソースデバイスによって選択され、
前記ソースデバイスからデータパケットを受信することと、前記データパケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持することと、
前記シンクキューが満杯であることを検出すると、前記シンクデバイスにおける表示のための前記シンクキュー中の前記データパケットの処理を開始することと、前記シンクデバイスにおける前記処理は、前記ソースデバイスにおける前記データパケットの処理と同期する、
を備える方法。
［６１］ 前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答することと、請求前記ユニバーサルキューサイズは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ソースデバイスによって選択される、をさらに備える［６０］に記載の方法。
［６２］ 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記データパケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、
をさらに備える、［６０］に記載の方法。

Claims (62)

1. ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、
   前記シンクデバイスのうちの少なくとも１つに、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズおよびトリガ遅延間隔を通知することと、
   前記シンクデバイスの各々にデータパケットを送ることと、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
   前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持することと、
   前記ソースキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待つことと、
   前記送信遅延間隔の間待った後に、前記ソースキュー中の前記データパケットの処理を開始することと、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
   を備え、
   前記シンクデバイスのトリガ遅延間隔は、前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと、前記シンクキュー中の前記パケットの処理を開始することとの間の待ち時間を表し、
   前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記通信セッションに参加している全てのシンクデバイスのうちの１つの前記トリガ遅延間隔内に前記ソースデバイスにより生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、方法。
2. 前記通信セッションは、前記ソースデバイスと１つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、請求項１に記載の方法。
3. サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
   前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
   をさらに備える、請求項１に記載の方法。
4. 前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスの一方向遅延時間を表し、
   をさらに備える、請求項１に記載の方法。
5. 前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと、前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
   前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
   をさらに備える、請求項１に記載の方法。
6. 前記通信セッションを確立することは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、請求項１に記載の方法。
7. 特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせることをさらに備える、請求項１に記載の方法。
8. 前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知することをさらに備える、請求項１に記載の方法。
9. 前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように前記ユニバーサルキューサイズを選択することを備える、請求項１に記載の方法。
10. 前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいて、すべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算することをさらに備える、請求項９に記載の方法。
11. 前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケット生成レートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの１つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、請求項１に記載の方法。
12. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備え、
    前記ソースデバイスと前記シンクデバイスのうちの１つとの間の送信遅延間隔を測定することと、
    前記ソースキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記送信遅延間隔の間待ってから前記ソースキュー中の前記パケットの処理を開始することと、
    をさらに備える、請求項１に記載の方法。
13. 前記通信セッションは、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションを備え、
    前記ソースデバイスのための送信遅延間隔を測定すること、前記送信遅延間隔は、最後のシンクデバイスの一方向遅延時間を表し、
    をさらに備える、請求項１に記載の方法。
14. 別のシンクデバイスによってサポートされる前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外することをさらに備える、請求項１に記載の方法。
15. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は０に等しい、請求項１４に記載の方法。
16. 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、請求項１に記載の方法。
17. ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、
    前記ソースデバイスからユニバーサルキューサイズとの通知を受信することと、
    前記通信セッションの一部として前記ソースデバイスからデータパケットを受信することと、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
    前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持することと、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始する前に、トリガ遅延間隔の間待つことと、
    前記トリガ遅延間隔待った後に、前記シンクキュー中の前記パケットの処理を開始することと、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期し、
    を備え、
    前記ソースデバイスは、ソースキューが前記ユニバーサルキューサイズまでが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記通信セッションに参加している全てのシンクデバイスのうちの１つの前記トリガ遅延間隔内に前記ソースデバイスにより生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、方法。
18. 前記通信セッションは、前記ソースデバイスと前記シンクデバイスのみとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、請求項１７に記載の方法。
19. 前記シンクデバイスの前記サポートキューサイズを報告するための前記ソースデバイスからのクエリに応答することをさらに備える、請求項１７に記載の方法。
20. 前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、請求項１７に記載の方法。
21. 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信すること、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
    をさらに備える、請求項１７に記載の方法。
22. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は０に等しい、請求項１７に記載の方法。
23. 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、請求項１７に記載の方法。
24. 第２のシンクデバイスが前記ソースデバイスとのすでに確立された通信セッションに加わることをさらに備える、請求項１７に記載の方法。
25. 前記シンクデバイスが、データパケットのセットの完了する前に、前記ソースデバイスとのすでに確立された通信セッションを終了すること、をさらに備える請求項１７に記載の方法。
26. ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、ユニバーサルキューサイズを選択することと、送信機に前記通信セッションのために選択された前記ユニバーサルキューサイズおよびトリガ遅延間隔の通知をシンクデバイスに送信させることと、を行うように構成されたプロセッサと、前記送信機は、前記通信セッションの一部として前記シンクデバイスの各々にデータパケットを送り、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
    前記パケットを保持する前記ユニバーサルキューサイズを有するソースキューと、
    を備え、
    前記ソースキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記プロセッサは、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記プロセッサは、前記送信遅延間隔の間待った後に、前記ソースキュー中の前記データパケットを処理することを開始し、前記ソースデバイスにおける前記データパケット処理が前記シンクデバイスにおけるパケット処理と同期し、
    前記シンクデバイスのトリガ遅延間隔は、前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと、前記シンクキュー中の前記パケットの処理を開始することとの間の待ち時間を表し、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記通信セッションに参加している全てのシンクデバイスのうちの１つの前記トリガ遅延間隔内に前記ソースデバイスにより生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、ソースデバイス。
27. 前記通信セッションは、前記ソースデバイスと１つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、請求項２６に記載のソースデバイス。
28. 前記プロセッサは、さらに、
    サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
    前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
    を行うように構成された、請求項２６に記載のソースデバイス。
29. 前記プロセッサは、さらに、
    前記ソースデバイスのための送信遅延間隔を測定すること、前記送信遅延間隔は、最後のシンクデバイスの一方向遅延時間を表し、
    を行うように構成された、請求項２６に記載のソースデバイス。
30. 前記プロセッサは、さらに、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
    前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
    を行うよう構成された、請求項２６に記載のソースデバイス。
31. 前記通信セッションを確立することは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを確立することを備える、請求項２６に記載のソースデバイス。
32. 前記プロセッサは、さらに、特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせるように構成された、請求項２６に記載のソースデバイス。
33. 前記プロセッサは、さらに、前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知するように構成された、請求項２６に記載のソースデバイス。
34. 前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しいように前記ユニバーサルキューサイズを選択することを備える、請求項２６に記載のソースデバイス。
35. 前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいてすべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算するように構成された、請求項３４に記載のソースデバイス。
36. 前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケット生成レートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの１つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、請求項２６に記載のソースデバイス。
37. 前記プロセッサは、さらに、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、
    前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、
    を行うように構成された、請求項２６に記載のソースデバイス。
38. 前記通信セッションが、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は０に等しい、請求項３７に記載のソースデバイス。
39. 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、請求項２６に記載のソースデバイス。
40. 前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外するようにさらに構成された、請求項２６に記載のソースデバイス。
41. ソースデバイスにシンクデバイスとの通信セッションを確立することを要求するように構成されたプロセッサと、
    前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記通信セッションの一部として前記ソースデバイスからパケットを受信することと、を行う受信機と、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
    前記パケットを保持する前記ユニバーサルキューサイズを有するシンクキューと、前記シンクキューが前記ユニバーサルキューサイズまで満杯のことを検出すると、前記プロセッサは、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットを処理する前に、トリガ遅延間隔の間待ち、前記トリガ遅延間隔待った後に、前記シンクキュー中の前記パケットの処理を開始し、前記シンクデバイスにおける前記パケット処理は少なくとも前記ソースデバイスにおけるパケット処理と同期する、
    を備え、
    前記ソースデバイスは、ソースキューが前記ユニバーサルキューサイズまでが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、シンクデバイス。
42. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを備える、請求項４１に記載のシンクデバイス。
43. 前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答するように構成された、請求項４１に記載のシンクデバイス。
44. 前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、請求項４１に記載のシンクデバイス。
45. 前記プロセッサは、さらに、
    前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信すること、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
    を行うように構成された、請求項４１に記載のシンクデバイス。
46. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの１つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は０に等しい、請求項４１に記載のシンクデバイス。
47. 前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの１つで動作する、請求項４１に記載のシンクデバイス。
48. 前記プロセッサは、前記シンクデバイスに、前記ソースデバイスとのすでに確立された通信セッションに参加させ、提示に参加させるように構成され、さらに、前記シンクデバイスに、データパケットのセットの完了の前に、前記ソースデバイスとのすでに確立された通信セッションを終了するように構成された、請求項４１に記載のシンクデバイス。
49. ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立する手段と、
    前記シンクデバイスの各々に、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズおよびトリガ遅延間隔を通知する手段と、
    前記シンクデバイスの各々にデータパケットを送る手段と、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
    前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持する手段と、
    前記ソースキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待つことと、
    前記送信遅延間隔の間待った後に、前記ソースキュー中の前記データパケットの処理を開始する手段と、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
    を備え、
    前記シンクデバイスのトリガ遅延間隔は、前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと、前記シンクキュー中の前記パケットの処理を開始することとの間の待ち時間を表し、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記通信セッションに参加している全てのシンクデバイスのうちの１つの前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、ソースデバイス。
50. サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
    前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
    を行う手段をさらに備える、請求項４９に記載のソースデバイス。
51. 前記ソースデバイスのための送信遅延間隔を測定すること、前記送信遅延間隔は、最後のシンクデバイスの一方向遅延時間を表し、
    を行う手段をさらに備える、請求項４９に記載のソースデバイス。
52. ソースデバイスにシンクデバイスとの通信セッションを確立することを要求する手段と、
    前記ソースデバイスからユニバーサルキューサイズの通知を受信する手段と、
    前記通信セッションの一部として前記ソースデバイスからデータパケットを受信する手段と、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
    前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持する手段と、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始する前に、トリガ遅延間隔の間待つ手段と、
    前記トリガ遅延間隔待った後に、前記シンクキュー中の前記パケットの処理を開始する手段と、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期する、
    を備え、
    前記ソースデバイスは、ソースキューが前記ユニバーサルキューサイズまでが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、シンクデバイス。
53. 前記通信セッションは、前記ソースデバイスと１つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの１つを備える、請求項５２に記載のシンクデバイス。
54. 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信する手段、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
    をさらに備える、請求項５２に記載のシンクデバイス。
55. ソースデバイス中で実行されたとき、プロセッサに、
    前記ソースデバイスと１つまたは複数のシンクデバイスとの間の通信セッションを確立することと、
    前記シンクデバイスの各々に、前記通信セッションのための前記ソースデバイスによって選択されたユニバーサルキューサイズおよびトリガ遅延間隔を通知することと、
    前記シンクデバイスの各々にデータパケットを送ることと、前記データパケットは、前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
    前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に前記データパケットを保持することと、
    前記ソースキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待つことと、
    前記送信遅延間隔の間待った後に、前記ソースキュー中の前記データパケットの処理を開始することと、前記ソースデバイスにおける前記処理は前記シンクデバイスにおける前記データパケットの処理と同期する、
    を行わせる命令を備えるコンピュータプログラムを記憶し、
    前記シンクデバイスのトリガ遅延間隔は、前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出することと、前記シンクキュー中の前記パケットの処理を開始することとの間の待ち時間を表し、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記通信セッションに参加している全てのシンクデバイスのうちの１つの前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、コンピュータ可読記憶媒体。
56. 前記コンピュータプログラムは、
    ソースデバイス中で実行されたとき、プロセッサに、
    サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、
    前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、
    を行わせる命令をさらに備える、請求項５５に記載のコンピュータ可読記憶媒体。
57. 前記コンピュータプログラムは、
    ソースデバイス中で実行されたとき、プロセッサに、
    前記ソースデバイスのための送信遅延間隔を測定すること、前記送信遅延間隔は、最後のシンクデバイスの一方向遅延時間を表し、
    を行わせる命令をさらに備える、請求項５５に記載のコンピュータ可読記憶媒体。
58. シンクデバイス中で実行されたとき、プロセッサに、
    ソースデバイスにシンクデバイスとの通信セッションを確立することを要求することと、
    前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、
    前記通信セッションの一部として前記ソースデバイスからパケットを受信することと、前記パケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するソースキュー中に保持され、
    前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記パケットを保持することと、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記シンクデバイスにおける表示のために前記シンクキュー中の前記パケットの処理を開始する前に、トリガ遅延間隔の間待つことと、
    前記トリガ遅延間隔待った後に、前記シンクキュー中の前記パケットの処理を開始することと、前記シンクデバイスにおける前記パケット処理は前記ソースデバイスにおけるパケット処理と同期する、
    を行わせる命令を備えるコンピュータプログラムを記憶し、
    前記ソースデバイスは、ソースキューが前記ユニバーサルキューサイズまでが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、コンピュータ可読記憶媒体。
59. 前記コンピュータプログラムは、
    ソースデバイス中で実行されたとき、プロセッサに、
    前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信すること、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
    を行わせる命令をさらに備える、請求項５８に記載のコンピュータ可読記憶媒体。
60. シンクデバイスとソースデバイスとの間の通信セッションを確立することと、
    前記ソースデバイスからユニバーサルキューサイズの通知を受信することと、前記ユニバーサルキューサイズは、前記通信セッションのために前記ソースデバイスによって選択され、
    前記ソースデバイスからデータパケットを受信することと、前記データパケットは、前記ソースデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に保持され、
    前記シンクデバイスにおいて前記ユニバーサルキューサイズを有するシンクキュー中に前記データパケットを保持することと、
    前記シンクキューが前記ユニバーサルキューサイズまで満杯であることを検出すると、前記シンクデバイスにおける表示のための前記シンクキュー中の前記データパケットの処理を開始する前に、トリガ遅延間隔の間待つことと、前記シンクデバイスにおける前記処理は、前記ソースデバイスにおける前記データパケットの処理と同期する、
    を備え、
    前記ソースデバイスは、ソースキューが前記ユニバーサルキューサイズまでが満杯であることを検出すると、前記ソースデバイスにおける表示のために前記ソースキュー中の前記データパケットの処理を開始する前に、送信遅延間隔の間待ち、
    前記ユニバーサルキューサイズは、前記送信遅延間隔内または前記トリガ遅延間隔内に前記ソースデバイスによって生成される前記データパケットの量と、前記ソースデバイスおよび各シンクデバイスのサポートキューサイズとに基づき選択される、方法。
61. 前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答することと、請求前記ユニバーサルキューサイズは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ソースデバイスによって選択される、をさらに備える請求項６０に記載の方法。
62. 前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信すること、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも１つが前記データパケットを受信するための時間間隔を表し、
    をさらに備える、請求項６０に記載の方法。

Images