図面 (/)

技術 同期したワイヤレスディスプレイデバイス

出願人 クゥアルコム・インコーポレイテッド
発明者 シェス、ソハム・ブイ.ソリマン、サミア・サリブラビーンドラン、ビジャヤラクシュミ・アール.
出願日 2012年9月10日 (7年0ヶ月経過) 出願番号 2014-530722
公開日 2015年1月22日 (4年8ヶ月経過) 公開番号 2015-502672
状態 特許登録済
技術分野 通信制御 双方向TV,動画像配信等 電話通信サービス
主要キーワード 絶対最大 トリガ遅延 ソースキュー 代替メディア ワイヤードデバイス ストリーミングモード ローカルディスプレイ スケジューリング順
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年1月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題・解決手段

本開示は、ワイヤレスディスプレイ(WD)システム中のソースデバイスと1つまたは複数のシンクデバイスとの間でメディアデータの再生を同期させるための技法に関する。WDシステムは、モバイルデバイスがソースデバイスのローカルディスプレイリモートシンクデバイスと共有することを可能にする。本開示の技法は、ソースデバイスおよび参加しているシンクデバイスのためのユニバーサルキューサイズを選択するためのソースデバイスにおける管理プロシージャを含む。ソースデバイスは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択する。次いで、ソースデバイスおよびシンクデバイスにおいてユニバーサルキューサイズを有するキュー中にメディアパケットが保持される。送信遅延補償と組み合わされた均一なキューサイズは、デバイスの各々が同時にメディアパケットの処理を開始することを可能にする。

概要

背景

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

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

概要

本開示は、ワイヤレスディスプレイ(WD)システム中のソースデバイスと1つまたは複数のシンクデバイスとの間でメディアデータの再生を同期させるための技法に関する。WDシステムは、モバイルデバイスがソースデバイスのローカルディスプレイをリモートシンクデバイスと共有することを可能にする。本開示の技法は、ソースデバイスおよび参加しているシンクデバイスのためのユニバーサルキューサイズを選択するためのソースデバイスにおける管理プロシージャを含む。ソースデバイスは、少なくともソースデバイスおよびシンクデバイスのサポートキューサイズに基づいてユニバーサルキューサイズを選択する。次いで、ソースデバイスおよびシンクデバイスにおいてユニバーサルキューサイズを有するキュー中にメディアパケットが保持される。送信遅延補償と組み合わされた均一なキューサイズは、デバイスの各々が同時にメディアパケットの処理を開始することを可能にする。

目的

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記通信セッションは、前記ソースデバイスと1つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、請求項1に記載の方法。

請求項3

サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、をさらに備える、請求項1に記載の方法。

請求項4

前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、をさらに備える、請求項1に記載の方法。

請求項5

前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、をさらに備える、請求項1に記載の方法。

請求項6

前記通信セッションを確立することは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを確立することを備える、請求項1に記載の方法。

請求項7

特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせることをさらに備える、請求項1に記載の方法。

請求項8

前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知することをさらに備える、請求項1に記載の方法。

請求項9

前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように前記ユニバーサルキューサイズを選択することを備える、請求項1に記載の方法。

請求項10

前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいて、すべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算することをさらに備える、請求項9に記載の方法。

請求項11

前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケットレートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの1つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、請求項1に記載の方法。

請求項12

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの1つを備え、前記ソースデバイスと前記シンクデバイスのうちの1つとの間の送信遅延間隔を測定することと、前記ソースキューが満杯であることを検出すると、前記送信遅延間隔の間待ってから前記ソースキュー中の前記パケットの処理を開始することと、をさらに備える、請求項1に記載の方法。

請求項13

前記通信セッションは、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションを備え、前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記パケットの処理を開始する前に、前記送信遅延間隔の間待つことと、をさらに備える、請求項1に記載の方法。

請求項14

別のシンクデバイスによってサポートされる前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外することをさらに備える、請求項1に記載の方法。

請求項15

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの1つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は0に等しい、請求項14に記載の方法。

請求項16

前記通信セッションは、ストリーミングモードフレームバッファモードとのうちの1つで動作する、請求項1に記載の方法。

請求項17

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

請求項18

前記通信セッションは、前記ソースデバイスと前記シンクデバイスのみとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを確立することを備える、請求項17に記載の方法。

請求項19

前記シンクデバイスの前記サポートキューサイズを報告するための前記ソースデバイスからのクエリ応答することをさらに備える、請求項17に記載の方法。

請求項20

前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、請求項17に記載の方法。

請求項21

前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも1つが前記データパケットを受信するための時間間隔を表し、前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、をさらに備える、請求項17に記載の方法。

請求項22

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの1つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は0に等しい、請求項17に記載の方法。

請求項23

前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの1つで動作する、請求項17に記載の方法。

請求項24

第2のシンクデバイスが前記ソースデバイスとのすでに確立された通信セッションに加わることをさらに備える、請求項17に記載の方法。

請求項25

前記シンクデバイスが、データパケットのセットの完了する前に、前記ソースデバイスとのすでに確立された通信セッションを終了すること、をさらに備える請求項17に記載の方法。

請求項26

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

請求項27

前記通信セッションは、前記ソースデバイスと1つまたは複数のシンクデバイスとの間のメディア共有セッションを備える、請求項26に記載のソースデバイス。

請求項28

前記プロセッサは、さらに、サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、を行うように構成された、請求項26に記載のソースデバイス。

請求項29

前記プロセッサは、さらに、前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、を行うように構成された、請求項26に記載のソースデバイス。

請求項30

前記プロセッサは、さらに、前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、を行うよう構成された、請求項26に記載のソースデバイス。

請求項31

前記通信セッションを確立することは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを確立することを備える、請求項26に記載のソースデバイス。

請求項32

前記プロセッサは、さらに、特定のシンクデバイスのサポートキューサイズについて前記シンクデバイスの各々に問い合わせるように構成された、請求項26に記載のソースデバイス。

請求項33

前記プロセッサは、さらに、前記シンクデバイスの各々に前記選択されたユニバーサルキューサイズを通知するように構成された、請求項26に記載のソースデバイス。

請求項34

前記ユニバーサルキューサイズを選択することは、すべての前記シンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しいように前記ユニバーサルキューサイズを選択することを備える、請求項26に記載のソースデバイス。

請求項35

前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズとトリガ遅延間隔とに基づいてすべての前記シンクデバイスにわたる前記最小サポートキューサイズを計算するように構成された、請求項34に記載のソースデバイス。

請求項36

前記ユニバーサルキューサイズを選択することは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズと、前記ソースデバイスにおけるパケットレートと、前記シンクデバイスの各々における送信遅延間隔、受信遅延間隔、およびトリガ遅延間隔のうちの1つまたは複数と、に基づいて前記ユニバーサルキューサイズを選択することを備える、請求項26に記載のソースデバイス。

請求項37

前記プロセッサは、さらに、前記シンクキューが満杯であることを検出することと前記シンクキュー中の前記パケットの処理を開始することとの間の特定のシンクデバイスのための待ち時間を表す、前記シンクデバイスの各々のためのトリガ遅延間隔を計算することと、前記シンクデバイスの各々にそれらのそれぞれのトリガ遅延間隔を通知することと、を行うように構成された、請求項26に記載のソースデバイス。

請求項38

前記通信セッションが、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの1つを備えるとき、前記シンクデバイスの各々のための前記トリガ遅延間隔は0に等しい、請求項37に記載のソースデバイス。

請求項39

前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの1つで動作する、請求項26に記載のソースデバイス。

請求項40

前記選択されたユニバーサルキューサイズをサポートすることができないシンクデバイスを除外するようにさらに構成された、請求項26に記載のソースデバイス。

請求項41

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

請求項42

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを備える、請求項41に記載のシンクデバイス。

請求項43

前記プロセッサは、さらに、前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答するように構成された、請求項41に記載のシンクデバイス。

請求項44

前記ユニバーサルキューサイズは、前記通信セッションに参加しているすべてのシンクデバイスにわたる最小サポートキューサイズよりも小さいかまたはそれに等しくなるように選択される、請求項41に記載のシンクデバイス。

請求項45

前記プロセッサは、さらに、前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも1つが前記データパケットを受信するための時間間隔を表し、前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、を行うように構成された、請求項41に記載のシンクデバイス。

請求項46

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションとのうちの1つを備えるとき、前記シンクデバイスのためのトリガ遅延間隔は0に等しい、請求項41に記載のシンクデバイス。

請求項47

前記通信セッションは、ストリーミングモードとフレームバッファモードとのうちの1つで動作する、請求項41に記載のシンクデバイス。

請求項48

前記プロセッサは、前記シンクデバイスに、前記ソースデバイスとのすでに確立された通信セッションに参加させ、提示に参加させるように構成され、さらに、前記シンクデバイスに、データパケットのセットの完了の前に、前記ソースデバイスとのすでに確立された通信セッションを終了するように構成された、請求項41に記載のシンクデバイス。

請求項49

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

請求項50

サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、を行う手段をさらに備える、請求項49に記載のソースデバイス。

請求項51

前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つこととを行う手段をさらに備える、請求項49に記載のソースデバイス。

請求項52

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

請求項53

前記通信セッションは、前記ソースデバイスと1つのシンクデバイスとの間のユニキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、前記ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを備える、請求項52に記載のシンクデバイス。

請求項54

前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信する手段と、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも1つが前記データパケットを受信するための時間間隔を表し、前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つための手段と、をさらに備える、請求項52に記載のシンクデバイス。

請求項55

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

請求項56

ソースデバイス中で実行されたとき、プロセッサに、サポートキューサイズについて前記シンクデバイスの各々に問い合わせることと、前記ソースデバイスで、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ユニバーサルキューサイズを選択することと、を行わせる命令をさらに備える、請求項55に記載のコンピュータ可読媒体。

請求項57

ソースデバイス中で実行されたとき、プロセッサに、前記ソースデバイスのための送信遅延間隔を測定することと、前記送信遅延間隔は、最後のシンクデバイスが前記データパケットを受信するための時間間隔を表し、前記ソースキューが満杯であることを検出すると、前記ソースキュー中の前記データパケットの処理を開始する前に、前記送信遅延間隔の間待つことと、を行わせる命令をさらに備える、請求項55に記載のコンピュータ可読媒体。

請求項58

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

請求項59

ソースデバイス中で実行されたとき、プロセッサに、前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも1つが前記データパケットを受信するための時間間隔を表し、前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記パケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、を行わせる命令をさらに備える、請求項58に記載のコンピュータ可読媒体。

請求項60

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

請求項61

前記シンクデバイスの前記サポートキューサイズを報告するために前記ソースデバイスからのクエリに応答することと、請求前記ユニバーサルキューサイズは、前記ソースデバイスおよび前記シンクデバイスのサポートキューサイズに基づいて前記ソースデバイスによって選択される、をさらに備える請求項60に記載の方法。

請求項62

前記ソースデバイスから前記シンクデバイスのためのトリガ遅延間隔の前記通知を受信することと、前記トリガ遅延間隔は、前記通信セッションに参加している前記他のシンクデバイスのうちの少なくとも1つが前記データパケットを受信するための時間間隔を表し、前記シンクキューが満杯であることを検出すると、前記シンクキュー中の前記データパケットの処理を開始する前に、前記トリガ遅延間隔の間待つことと、をさらに備える、請求項60に記載の方法。

優先権の主張

0001

本出願は、各々の内容全体が参照により本明細書に組み込まれる、2011年9月13日に出願された米国仮出願第第61/534,193号、2011年9月27日に出願された米国仮出願第61/539,726号、および2012年2月7日に出願された米国仮出願第61/595,932号の利益を主張する。

技術分野

0002

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

背景技術

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

図面の簡単な説明

0017

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

実施例

0018

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

0019

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

0020

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

0021

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

0022

[0030]図2は、ソースデバイス10と、通信セッションに参加しているシンクデバイス12A〜12B(「シンクデバイス12」)とを含むWDシステムを示すブロック図である。他の例では、WDシステムは、3つ以上の参加しているシンクデバイスを含み得る。WDシステムはまた、WD通信セッションがそれを介してソースデバイス10とシンクデバイス12との間で確立される複数のWi−Fi(たとえば、IEEE802.11x)ネットワークをサポートする、1つまたは複数の基地局(図示せず)を含み得る。通信サービスプロバイダは、ネットワークハブとして基地局を使用して、これらのネットワークのうちの1つまたは複数を集中的に動作させ、管理し得る。

0023

[0031]ソースデバイス10およびシンクデバイス12の各々は、携帯電話、ワイヤレス通信カードをもつポータブルコンピュータ、携帯情報端末(PDA)、ポータブルメディアプレーヤ、ワイヤレス通信機能をもつ他のフラッシュメモリデバイス、または任意のタイプのワイヤレス通信デバイスなど、モバイルデバイスの形態をとり得る。他の例では、シンクデバイス12のうちの1つまたは複数は、テレビジョンデスクトップコンピュータモニタプロジェクタなど、ワイヤレス通信機能をもつワイヤードデバイスの形態をとり得る。図2の図示の例では、ソースデバイス10は、記憶されたコンテンツ16と、パーサ18と、デコーダ20と、レンダラ22と、ローカルディスプレイ24と、送信機(TX)26とを含む。シンクデバイス12は、受信機30A〜30B(「受信機30」)と、デコーダ32A〜32B(「デコーダ32」)と、レンダラ34A〜34B(「レンダラ34」)と、ディスプレイ36A〜36B(「ディスプレイ36」)とを含む。

0024

[0032]ソースデバイス10およびシンクデバイス12の構成要素はそれぞれ、1つまたは複数のマイクロプロセッサデジタル信号プロセッサ(DSP)、特定用途向け集積回路ASIC)、フィールドプログラマブルゲートアレイFPGA)、ディスクリート論理ソフトウェアハードウェアファームウェアなど、様々な好適な回路のいずれか、またはそれらの任意の組合せとして実装され得る。ローカルディスプレイ24およびディスプレイ36はそれぞれ、液晶ディスプレイ(LCD)、プラズマディスプレイ有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

0025

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

0026

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

0027

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

0028

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

0029

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

0030

[0038]図3の図示の例では、ソースデバイス40Aは、図2からのソースデバイス10と同様に、記憶されたコンテンツ16と、パーサ18と、デコーダ20と、レンダラ22と、ローカルディスプレイ24と、送信機(TX)26とを含む。説明する技法によれば、ソースデバイス40Aはまた、セッションマネージャ41と、キューモニタ43と、ユニバーサルキューサイズを有するソースキュー44とを含む。シンクデバイス42は、図2からのシンクデバイス12と同様に、受信機30と、デコーダ32と、レンダラ34と、ディスプレイ36とを含む。シンクデバイス42は、セッションマネージャ45A〜45B(「セッションマネージャ45」)と、キューモニタ47A〜47B(「キューモニタ47」)と、ユニバーサルキューサイズを有するシンクキュー46A〜46B(「キュー46」)とをさらに含む。

0031

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

0032

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

0033

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

0034

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

0035

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

0036

TxDelay (one way delay) = Roundtrip delay/2, および
RxDelay (at sink device) = TxDelay - TxTime.
[0044]本開示におけるユニバーサルキューサイズとトリガ遅延とを計算するために使用される追加のパラメータは、ソースデバイス40Aにおいてサポートされる最大キューサイズを表すMaxSyncQSizeと、特定の通信セッションのためのシンクデバイス42の各々においてサポートされるキューサイズを表すSupportedSinkQSizeと、ビデオデータのためのフレームレートによって決定され得る、ソースデバイス40Aにおけるパケット生成レートを表すPktRateとを含む。TriggerDelayは、シンクデバイス42の各々におけるユニバーサルキューサイズを有するシンクキューが満杯になった後であるが、シンクキュー中に保持されたパケットを処理することを開始するようにデコーダをトリガする前の待ち時間を表す。SelectedOptimalQueueSizeは、通信セッションに参加するであろうすべてのデバイスのためのソースデバイス10によって選択されたユニバーサルキューサイズを表す。

0037

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

0038

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

0039

RxDelayallDevices = max(RxDelay1, RxDelay2, ... , RxDelayn),
SupportedSinkQSizemin = min(SupportedSinkQSize1, SupportedSinkQSize2, ... SupportedSinkQSizen), ここでSupportedSinkQSizei はシンクデバイスiによりサポートされるキューサイズであり、
MaxSyncQSize - (PktRate * RxDelayallDevices) - UniversalQueueSize >= 0, および
UniversalQueueSize <= SupportedSinkQSizemin.

[0047]第3の場合では、ソースデバイス40Aは、複数のシンクデバイス1、2、...、n、たとえばシンクデバイス42の各々との複数のユニキャスト通信セッションを確立する。通信セッションをセットアップすることに関心があるシンクデバイス42の各々からSupportedSinkQSizeを受信すると、ソースデバイス40Aは、最大のSupportedSinkQSizeをもつシンクデバイス42のうちの1つがメディアストリームの第1の受信側になり、2番目に大きいSupportedSinkQSizeをもつシンクデバイス42のうちの1つがメディアストリームの第2の受信側になるなどのように、送信スケジュールソートする。送信スケジュールを決定した後に、ソースデバイス40Aはシンクデバイスi=1、2、...nの各々のためのTriggerDelayiを計算する。シンクデバイス42の各々のためのトリガ遅延の計算については、以下でより詳細に説明する。

0040

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

0041

SupportedSinkQSizemin = min((SupportedSinkQSize1 - (PktRate * TriggerDelay1)), (SupportedSinkQSize2 - (PktRate * TriggerDelay2)), … (SupportedSinkQSizen - (PktRate * TriggerDelayn))).
この場合、SupportedSinkQSizeminは、(SupportedSinkQSizei−(PktRate*TriggerDelayi))>0をもつシンクデバイスiのみに基づいて計算される。(SupportedSinkQSizei−(PktRate*TriggerDelayi))<0をもつシンクデバイスiは、(SupportedSinkQSizex−(PktRate*TriggerDelayx))>0をもつシンクデバイスxと同じ通信セッションの一部になり得ない。ソースデバイス40Aは、次いで、以下のように、ユニキャスト通信セッションのためのソースデバイス40Aおよびシンクデバイス42によって使用されるべきユニバーサルキューサイズを選択する。

0042

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

0043

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

0044

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

0045

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

0046

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

0047

[0054]第1の場合では、通信セッションが、ソースデバイス40Aと1つのシンクデバイスのみ、たとえばシンクデバイス42Aとの間に確立される。シンクデバイス42Aのキューモニタ47Aが、シンクキュー46Aが完全に満たされたことを検出したとき、キューモニタ47Aは、シンクデバイス42AのためのTriggerDelay間隔の後にシンクキュー46A中のメディアパケットを処理することを開始するようにデコーダ32Aをトリガする。概して、TriggerDelay間隔は、シンクキュー46Aが満杯であることを検出することと、メディアパケットの処理を開始することとの間の待ち時間を表す。通信セッションがシンクデバイス42Aのみと確立される第1の場合では、デコーダ32Aは、シンクキュー46Aが満たされるとすぐにメディアパケットを処理することを開始することができるので、TriggerDelay間隔値は0に等しい。

0048

[0055]一方、ソースデバイス40Aは、メディアパケットを処理することを開始するために、シンクデバイス42Aのシンクキュー46Aがメディアパケットで満たされるまで待つ。ソースデバイス40Aのキューモニタ43が、ソースキュー44が完全に満たされたことを検出したとき、キューモニタ43は、TxDelay、すなわち、ソースデバイス40Aからシンクデバイス42Aまでの送信時間の後にソースキュー44中のメディアパケットを処理することを開始するようにデコーダ20をトリガする。このようにして、キューモニタ43は、ソースデバイス40Aとシンクデバイス42Aとが同時にメディアパケットを処理することを開始することを保証する。

0049

[0056]第2の場合では、マルチキャスト通信セッションが、ソースデバイス40Aと、複数のシンクデバイス1、2、...n、たとえばシンクデバイス42の両方との間で確立される。第1の場合について上記で説明したのと同じ同期パケット処理を達成する方法が、第2の場合のために使用され得る。マルチキャスト通信セッション中、シンクデバイス42のすべては、シンクデバイス42の各々のためのTriggerDelay間隔値が0に等しくなるように、同時にソースデバイス40Aからメディアパケットを受信することになる。さらに、シンクデバイス42のためのTxDelay間隔値はすべて同じである。この場合、シンクキュー46は同時にメディアパケットで満たされ、デコーダ32の各々は、それぞれのシンクキュー46が満たされるとすぐに、メディアパケットの同期処理を開始することができる。ソースデバイス40Aは、TxDelay時間を待ってからシンクデバイス42との同期処理を開始する。TxDelayの値中のいくつかのファクタのうちの1つは、一方向遅延、または2で除算された往復遅延である。

0050

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

0051

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

0052

[0059]第3の場合では、複数のユニキャスト通信セッションが、ソースデバイス40Aと、複数のシンクデバイス1、2、...n、たとえばシンクデバイス42の両方との間に確立される。ソースデバイス40Aからシンクデバイス1、2、...nの各々までの一方向送信遅延は、それぞれ、TxDelay1、TxDelay2、...TxDelaynである。同様に、シンクデバイスの各々における受信遅延は、RxDelay1、RxDelay2、...RxDelaynである。ソースデバイス40Aのセッションマネージャ41は、通信セッションに参加するシンクデバイス42の各々のためのTriggerDelayを計算する。シンクデバイス42の各々のためのTriggerDelayは、シンクデバイス42の各々が、残りのシンクデバイス42のシンクキュー46がメディアパケットで満たされるまで、メディアパケットを処理することを開始するのを待つように計算され得る。

0053

[0060]ソースデバイス40Aは、シンクデバイスn、シンクデバイスn−1、...シンクデバイス2、およびシンクデバイス1という順序で、シンクデバイスにメディアパケットのペイロードを送り得る。ソースデバイス40Aのセッションマネージャ41は、次いで、TriggerDelayx=RxDelay1+RxDelay2+...+RxDelayx-1としてシンクデバイスxのTriggerDelay値を計算する。たとえば、ソースデバイス40Aは、第1に、0の受信遅延でシンクデバイス42Aにメディアパケットを送り、次いで第2に、約5ミリ秒(ms)の受信遅延でシンクデバイス42Bにメディアパケットを送り得る。セッションマネージャ41は、次いで、シンクデバイス42BのRxDelay、すなわち、5msに等しいとしてシンクデバイス42AのためのTriggerDelay値を計算し、0に等しいとしてシンクデバイス42BのためのTriggerDelay値を計算し得る。ソースデバイス40Aのセッションマネージャ41は、通信セッションセットアップの前またはその間のいずれかに、シンクデバイス42の各々に、関連するTriggerDelayを通知する。

0054

[0061]ソースデバイス40Aのセッションマネージャ41はまた、ローカルソースTriggerDelay値を計算する。ソースデバイス20AのTriggerDelay値は、メディアストリームの最後の受信側であるシンクデバイスのためのTxDelayに等しく設定される。この例では、メディアパケットの最後の受信側はシンクデバイス1であるので、TriggerDelaysource=TxDelay1である。このようにして、ソースデバイス40Aは、シンクデバイス42のシンクキュー46のすべてがメディアパケットで満たされるまで、メディアパケットの処理を開始するのを待つ。これらの技法によれば、TriggerDelay値は、シンクデバイス42の各々およびソースデバイス40Aにおいて調整され(tailored)、スキューされる(skewed)。このようにして、ソースデバイス40Aおよびシンクデバイス42のすべては、メディアデータの同期再生を与えるために同時にメディアパケットの処理を開始することになる。したがって、すべての参加しているデバイスは、所与時間インスタンスにおいて同じビデオフレームを表示することになる。

0055

[0062]上記で説明した第3の場合では、ユニバーサルキューサイズ決定中に、セッションマネージャ41は、単なるシンクデバイスの各々におけるサポートキューサイズ以上のものに基づいて、すべてのシンクデバイス42にわたる最小サポートキューサイズ、SupportedSinkQSizeminを計算する。最小サポートキューサイズは、シンクデバイスの各々のためのTriggerDelay間隔をも考慮に入れる。この追加のパラメータは、シンクデバイスのいずれも、TriggerDelay間隔の間待つ間に次の着信メディアパケットを消失しないことを保証する。

0056

[0063]たとえば、ソースデバイス40Aは、設定されたパケットレートに従ってシンクデバイス42にメディアパケットを送る。1秒当たり15(またはさらに少ない)パケットから1秒当たり1000またはそれ以上のパケットまで、多種多様なパケットレートが使用され得る。パケットレートは、概して、パケットサイズデータレートとに依存し得る。いくつかのシステムのための一般的なパケットレートは、1秒当たり15〜60パケットであり得る。しかしながら、シンクキューが満たされると、シンクデバイス42は、パケット処理がシンクキュー中に追加のメディアパケットのためのスペースを作り始めるまで、追加のメディアパケットを受信することができない。場合によっては、送信スケジュールの最上位またはその近くにあるシンクデバイスは、シンクキューが満杯であることを検出することとパケット処理を開始することとの間の長いTriggerDelay間隔の間待たなければならないことがある。これらのシンクデバイスは、シンクキュー中に着信パケットを保持するためのスペースがない場合、長い遅延中に着信パケットを消失する危険にさらされ得る。パケットレートは、通信セッションのためのビットレートに基づき得る。いくつかのデバイスのための例示的なビットレートは、限定はしないが、400Kbpsの絶対最小ビットレート、4Mbps開始ビットレート、および10Mbpsの絶対最大ビットレートであり得る。ビットレートは、使用され得るビデオフォーマットに影響を及ぼし得、たとえば、表1を参照されたい。

0057

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

0058

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

0059

[0066]別の例では、シンクデバイス42のうちの1つまたは複数が、通信セッション中に加わり得る。シンクデバイスn+1が、たとえば、通信セッションに加わるとき、ソースデバイス40Aのセッションマネージャ41は、シンクデバイスn+1を受信側リストの最上位に追加する。ソースデバイス40Aは、次いで、他のシンクデバイス42のいずれかにパケットを送る前に、新しいシンクデバイスn+1にメディアパケットを送る。さらに、セッションマネージャ41は、新しいシンクデバイスn+1を含むすべてのデバイスにおけるメディアデータの同期再生を保証するために、新しいシンクデバイスn+1のためのTriggerDelay値を計算する。

0060

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

0061

[0068]新しいシンクデバイスn+1を受信側リストの最上位に追加することによって、新しいシンクデバイスは、すべての他のシンクデバイス42のシンクキュー46が満杯になるまで待つ必要があるので、新しいシンクデバイスは最長TriggerDelay間隔を有することになる。新しいシンクデバイスn+1の後の送信スケジューリング順序は同じままであるので、後続のシンクデバイス42のためのTriggerDelay間隔は同じままである。このようにして、メディアデータの同期再生は、新しいシンクデバイスが通信セッションに加わった後に、既存のシンクデバイス42のためのTriggerDelay値を再計算する必要なしに続き得る。新しいシンクデバイスn+1が通信セッションに追加されると、新しいシンクデバイスはソースデバイス40Aからメディアパケットを受信することを開始する。新しいシンクデバイスのシンクキューが満杯になると、新しいシンクデバイスは、TriggerDelay間隔の後に、WDシステム中のすべての他のデバイスと同期してメディアパケットを処理することを開始する。

0062

[0069]場合によっては、WDシステムのレイテンシの必要または通信セッションのメディアコンテンツタイプに基づいて、ソースデバイス40Aのセッションマネージャ41は、TriggerDelay値および/またはユニバーサルキューサイズを0または極めて小さい数に設定し得る。他の場合には、ソースデバイス40Aがシンクデバイス42のうちの1つまたは複数とのアクティブ通信セッション中にないとき、ソースデバイス40Aは、ソースデバイス40Aにおけるローカル応答時間を改善するためにソースキュー44を縮小および/またはバイパスし得る。この場合、ソースデバイス40Aにおけるメディアパケットは、パーサ18からデコーダ20に直接移動し得、シンクデバイス42において受信されたメディアパケットは、受信機30からデコーダ32に直接移動し得る。

0063

[0070]別の例では、ユニキャスト通信セッションは、ソースデバイス40Aとシンクデバイス42の各々との間に確立され得る。この場合、ソースデバイス40Aのセッションマネージャ41は、通信セッションに参加するシンクデバイス42の各々のためのTriggerDelayを計算する。たとえば、ソースデバイス40Aのセッションマネージャ41は、TriggerDelayx=RxDelay1+RxDelay2+...RxDelayx−1としてシンクデバイスxのTriggerDelay値を計算し、ここで、RXDelayxはシンクデバイスxにおける受信遅延である。シンクデバイス42の各々のためのTriggerDelayは、シンクデバイスの各々が、すべてのシンクデバイスのシンクキューがメディアパケットで満たされるまで、データパケットの処理を開始するのを待つように計算され得る。ソースデバイス40Aのセッションマネージャ41は、通信セッションセットアップの前またはその間のいずれかに、シンクデバイス42の各々に、関連するTriggerDelayを通知する。

0064

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

0065

[0072]シンクデバイス42Aのキューモニタ47Aが、シンクキュー46Aが完全に満たされたことを検出したとき、キューモニタ47Aは、シンクデバイス42Aのための計算されたTriggerDelay間隔の後にシンクキュー46A中のメディアパケットの処理を開始するようにデコーダ32Aをトリガする。概して、TriggerDelay間隔は、シンクキュー46Aが満杯であることを検出することと、メディアパケットの処理を開始することとの間の待ち時間を表す。シンクデバイス42Bは、シンクデバイス42Bのための計算されたTriggerDelay間隔に基づいて同様に動作する。ソースデバイス40Aは、シンクデバイス42Aのシンクキュー46Aとシンクデバイス42Bのシンクキュー46Bの両方がデータパケットで満たされるまで、データパケットの処理を開始するのを待つ。ソースデバイス40Aのキューモニタ43が、ソースキュー44が完全に満たされたことを検出したとき、キューモニタ43は、ローカルソースTxDelayの後にソースキュー44中のデータパケットの理を開始するようにデコーダ20をトリガする。このようにして、キューモニタ43は、ソースデバイス40Aとシンクデバイス42とが同時にメディアパケットの処理を開始することを保証する。

0066

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

0067

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

0068

[0075]通信セッションは、1つまたは複数の通信チャネルを介した通信を含み得る。これらの通信チャネルは、比較的短距離の通信チャネルであり得、定義された2.4GHz、3.6GHz、5GHz、60GHzまたは超広帯域(UWB)周波数帯域構造を実装するなど、Wi−Fi、Bluetooth(登録商標)などと同様の物理チャネル構造を実装し得る。ただし、通信チャネルは、この点において必ずしも限定されるとは限らず、無線周波数(RF)スペクトルまたは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。他の例では、通信チャネルは、ワイヤードまたはワイヤレスローカルエリアネットワークワイドエリアネットワーク、あるいはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成することさえある。さらに、通信チャネルは、ピアツーピアリンクを作成するためにソースデバイス40Aとシンクデバイス42とによって使用され得る。

0069

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

0070

[0077]本開示の技法について時々WFDに関して説明することがあるが、これらの技法の態様は他の通信プロトコルにも適合し得ることが企図される。限定ではなく例として、ソースデバイス40Aとシンクデバイス42との間のワイヤレス通信直交周波数分割多重化(OFDM)技法を利用し得る。限定はしないが、時分割多元接続TDMA)、周波数分割多元接続FDMA)、符号分割多元接続(CDMA)、あるいはOFDM、FDMA、TDMAおよび/またはCDMAの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用され得る。

0071

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

0072

[0079]図4の図示の例では、ソースデバイス40Aと同様に、ソースデバイス40Bは、セッションマネージャ41と、キューモニタ43と、ユニバーサルキューサイズを有するソースキュー44と、記憶されたコンテンツ16と、ローカルディスプレイ24と、送信機(TX)26とを含む。ソースデバイス40Bは、ディスプレイプロセッサ52と、フレームバッファ54と、ディスプレイドライバホスト58と、ディスプレイドライバクライアント60と、ビデオプロセッサ62と、スクリーンキャプチャモジュール63と、エンコーダ64と、トランスポートモジュール66とをさらに含む。ディスプレイプロセッサ52は、生ピクセルフォーマット(たとえば、RGB、YUV、YCbCr)での出力を生成するディスプレイプロセッサを表す。生ピクセルデータは、最初にフレームバッファ54中に保持される。ディスプレイドライバホスト58、たとえばモバイルディスプレイデジタルインターフェース(MDDI)ホストドライバは、フレームバッファ54からディスプレイドライバクライアント60にメディアコンテンツをプッシュするドライバを表す。ディスプレイドライバクライアント60は、ローカルディスプレイ24におけるメディアコンテンツのレンダリングを制御する。

0073

[0080]ソースデバイス40Bのセッションマネージャ41は、本開示で説明する技法による、フレームバッファモードでのシンクデバイス42との同期通信セッションを確立し得る。フレームバッファモードでは、ソースデバイス40Bは、図3からのソースデバイス40Aに関して上記で説明したのと同様の手法を使用する。たとえば、セッションマネージャ41は、シンクデバイス42のサポートキューサイズに基づいてユニバーサルキューサイズを選択する。ユニバーサルキューサイズが選択され、参加しているデバイスが通知されると、ソースデバイス40Bは、ユニバーサルキューサイズを有するソースキュー44を生成し、シンクデバイス42は、ユニバーサルキューサイズを有するシンクキュー46を生成する。ソースデバイス40Bのセッションマネージャ41はまた、参加するシンクデバイス42の各々のためのTxDelayと、RxDelayと、TriggerDelayとを計算し、次いで、それぞれのシンクデバイス42に遅延間隔値を通知する。フレームバッファモードでは、キューモニタ43が、ディスプレイプロセッサ52と、ディスプレイドライバホスト58と、トランスポートモジュール66とから出力されるメディアコンテンツの処理を調整する。

0074

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

0075

[0082]ユニバーサルキューサイズを有するソースキュー44がソースデバイス40Bにおいて生成された後に、ディスプレイプロセッサ52は、ローカルディスプレイ24上にメディアフレームを表示するために、フレームバッファ54中に記憶されたコンテンツ16からメディアフレームを作成する。各メディアフレームはまた、スクリーンキャプチャモジュール63によってキャプチャされ、エンコーダ64によって符号化され、送信機(TX)26によって参加するシンクデバイス42の各々に送信さる。キューモニタ43は、符号化および送信を含むソースデバイス30Bのメディア処理パイプライン中で各メディアフレームを追跡する。所与のメディアフレームがシンクデバイス42に送信されると、キューモニタ43はフレームバッファ54からソースキュー44に、対応するメディアフレームを移動する。キューモニタ43が、ソースキュー44が満たされたことを検出したとき、キューモニタ43は、TxDelayを待ち、次いでメディアフレームをレンダリングすることを開始するように、ディスプレイドライバホスト58をトリガする。このようにして、ソースデバイス40Aは、すべてのシンクデバイス42が同じフレームを受信し、処理することを開始するのに十分な時間を有するまで、ローカルディスプレイ24上での表示のためにメディアフレームを処理することを開始するのを待つ。

0076

[0083]図3に関して上記で説明したように、シンクデバイス42Aにおけるキューモニタ47Aが、たとえば、シンクキュー46Aが満たされたことを検出したとき、キューモニタ47Aは、シンクデバイス42AのためのTriggerDelay間隔の後にメディアフレームを処理することを開始するようにデコーダ32Aをトリガする。通信セッションがシンクデバイス42Aのみと確立されるとき、または、通信セッションが複数のシンクデバイスとのマルチキャストセッションであるとき、デコーダ32Aは、シンクキュー46Aが満たされるとすぐにメディアフレームの処理を開始することができるので、TriggerDelay間隔値は0に等しい。複数の通信セッションが複数のシンクデバイスと確立されるとき、ソースデバイス40Bのセッションマネージャ41は、シンクデバイスの各々のためのTriggerDelay間隔を計算する。このようにして、シンクデバイス42の各々は、すべてのシンクデバイス42が同じフレームを受信し、処理を開始するのに十分な時間を有するまで、受信したメディアフレームを処理することを開始するのを待つ。

0077

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

0078

[0085]ソースデバイス40Aのセッションマネージャ41が、広告されたコンテンツのためにシンクデバイス42Aとの通信セッションを確立したいという要求を受信したとき、セッションマネージャ41は、シンクデバイス42Aのセッションマネージャ45Aに、このタイプのメディアデータのためのサポートキューサイズについてのクエリ78Aを送る(「Qサイズを問い合わせる」)。セッションマネージャ45Aは、次いで、セッションマネージャ41にシンクデバイス42Aのためのサポートキューサイズを含む応答80Aを送る(「Qサイズで応答する」)。同様に、ソースデバイス40Aのセッションマネージャ41が、広告されたコンテンツのためにシンクデバイス42Bとの通信セッションを確立したいという要求を受信したとき、セッションマネージャ41は、シンクデバイス42Bのセッションマネージャ45Bに、このタイプのメディアデータのためのサポートキューサイズについてのクエリ78Bを送る(「Qサイズを問い合わせる」)。セッションマネージャ45Bは、次いで、セッションマネージャ41にシンクデバイス42Bのためのサポートキューサイズを含む応答80Bを送る(「Qサイズで応答する」)。

0079

[0086]問い合わせられたシンクデバイス42から応答を受信すると、ソースデバイス40Aにおけるセッションマネージャ41は、次いで、通信セッション中にすべての参加しているデバイスにおいて使用するためのユニバーサルキューサイズを選択する。ソースデバイス40Aのセッションマネージャ41は、次いで、それ自体のメディア処理パイプラインにユニバーサルキューサイズの通知82を送り(「Qサイズを選択する」)、シンクデバイス42Aのセッションマネージャ45Aにユニバーサルキューサイズの通知84Aを送り(「Qサイズを設定する」)、シンクデバイス42Bのセッションマネージャ45Bにユニバーサルキューサイズの通知84Bを送る(「Qサイズを設定する」)。ユニバーサルキューサイズ値は、所定の様式、たとえば、持続時間、フレームの数などで提示され得る。言い換えれば、ユニバーサルキューサイズは、たとえば、ある持続時間のビデオ、またはある数のビデオフレームを記憶する能力に基づき得る。したがって、ユニバーサルキューサイズは、1秒、10秒、20秒またはそれ以上のビデオを記憶することに基づき得る。いくつかのデバイスは、より長い持続時間のビデオを記憶し得、他のデバイスは、より短い持続時間を記憶し得る。さらに、所与のユニバーサルキューサイズのための記憶される持続時間は、ビデオのために使用される1秒当たりのビット数に基づいて変動し得ることを理解されよう。異なるビデオフォーマットおよびビットレートのための例を表1に与える。したがって、30fpsにおける1080pと公称ビットレートとの10Mbpsを仮定すると、10秒のビデオを記憶するためのユニバーサルキューサイズは100Mbであろう。ユニバーサルキューサイズは、代替的に、ある数のビデオフレームを記憶することに基づき得る。したがって、特定のビデオフォーマットのためのフレームが33,333.3ビットを必要とすると仮定すると、デバイスが30フレームを記憶するように設計された場合、ユニバーサルキューは1Mbを記憶し得る。

0080

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

0081

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

0082

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

0083

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

0084

[0091]ソースデバイス40Aのセッションマネージャ41は、ソースデバイス40Aが、通信セッションを介して1つまたは複数のシンクデバイス42と共有すべきコンテンツ、たとえば、オーディオおよび/またはビデオコンテンツを有することを広告する(90)。シンクデバイス42のうちの1つまたは複数のセッションマネージャ45は、通信セッションに参加することを要求することによってこの広告に応答する(91)。要求を受信すると、ソースデバイス40Aのセッションマネージャ41は、要求元シンクデバイス42との通信セッションを確立する(92)。セッションマネージャ41は、次いで、シンクデバイス42の各々における通信セッションのためのサポートキューサイズを知るために、シンクデバイス42に問い合わせる(93)。シンクデバイス42のセッションマネージャ45の各々は、通信セッションのためのそれのサポートキューサイズで応答する(94)。

0085

[0092]シンクデバイス42のためのサポートキューサイズを受信すると、ソースデバイス40Aのセッションマネージャ41は、シンクデバイスのサポートキューサイズに基づいて通信セッションのためのユニバーサルキューサイズを選択する(95)。セッションマネージャ41は、図3に関して上記で説明したようにユニバーサルキューサイズを選択し得る。シンクデバイス42の各々は、次いで、ソースデバイス40Aから、通信セッションのために使用されるべきユニバーサルキューサイズの通知を受信する(96)。ソースデバイス40Aおよびシンクデバイス42の各々は、ユニバーサルキューサイズを有するキューを生成する。

0086

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

0087

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

0088

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

0089

[0096]図7の例示的な方法では、ソースデバイス40Aは、1つまたは複数のシンクデバイス42との通信セッションを確立する(700)。通信セッションは、たとえば、ソースデバイス10、40Aと1つまたは複数のシンクデバイス42Bとの間のメディア共有セッションであり得る。一例では、ソースデバイス40Aと1つまたは複数のシンクデバイス42との間のメディア共有セッションなどの通信セッションを確立することは、たとえば、通信セッションの一部としてシンクデバイス42の各々にデータパケットを送信することを含み得る。

0090

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

0091

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

0092

[0099]ソースデバイス40Aのユニット26は、シンクデバイス42A、42Bの各々にデータパケットを送る。たとえば、ソースデバイス40Aは、通信セッションの一部としてシンクデバイス42にデータパケットを送る(98)。別の例では、シンクデバイス42は、ユニバーサルキューサイズを有するシンクキュー46中にデータパケットを保持する(704)。別の例では、ソースデバイス40Aのキューモニタ43は、ユニバーサルキューサイズを有するソースキュー44中にデータパケットを保持する(706)。

0093

[00100]ソースキュー44が満杯であることを検出すると、ソースデバイス40Aは、ソースデバイスにおける表示のためソースキュー中のデータパケットの処理を開始する(708)。たとえば、ソースデバイス40Aのキューモニタ43はソースキュー44を監視し得る。キューモニタ43が、ソースキュー44が満杯であることを検出すると、ソースデバイス40Aは、遅延間隔の間待ってから、シンクデバイス42と同期してパケットを処理することを開始する。さらに、ソースデバイスにおける処理は、シンクデバイスにおけるデータパケットの処理と同期し得る。

0094

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

0095

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

0096

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

0097

[00104]シンクデバイス42はソースデバイス40Aからユニバーサルキューサイズの通知を受信する。ソースデバイス40Aは通信セッションのためのユニバーサルキューサイズを選択する(802)。たとえば、シンクデバイス42の各々は、ソースデバイス40Aから通信セッションのために使用されるべきユニバーサルキューサイズの通知を受信する(96)。ソースデバイス40Aおよびシンクデバイス42の各々は、ユニバーサルキューサイズを有するキューを生成し得る。

0098

[00105]シンクデバイス42はソースデバイス40Aからデータパケットを受信する。データパケットは、ソースデバイスにおいてユニバーサルキューサイズを有するソースキュー中に保持され得る。さらに、受信されたデータパケットを、シンクデバイスにおいてユニバーサルキューサイズを有するシンクキュー中に保持する(804)。

0099

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

0100

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

0101

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

0102

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

0103

[00110]図9の例では、シンクデバイス42は、ソースデバイス40Aに通信セッションを確立することを要求する(900)。通信セッションは、(1)ソースデバイスとシンクデバイスのみとの間のユニキャスト通信セッションと、(2)ソースデバイスと複数のシンクデバイスとの間のマルチキャスト通信セッションと、(3)ソースデバイスと複数のシンクデバイスとの間の複数のユニキャスト通信セッションとのうちの1つを含み得る。一例では、シンクデバイス42のためのトリガ遅延間隔は0に等しくなり得る。

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

[00120]様々な実施形態について説明した。これらおよび他の実施形態は以下の特許請求の範囲内に入る。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ