(57)【要約】  ワイヤレスディスプレイ（ＷＤ）システムにおけるシンクデバイスは、ソースデバイスにおいてメディアデータ処理を調整するためにソースデバイスに性能情報フィードバックを送ることができる。性能情報フィードバックは、メディアデータの送信を調整するための要求または受信されたメディアデータに基づいてシンクデバイスで測定または計算されることができるＷＤシステムの性能インジケータを含むことができる。例えば、性能情報フィードバックは、往復遅延、遅延ジッタ、パケットロスレート、エラー分布、受信信号強度インジケーション（ＲＳＳＩ）のうちの１つまたは複数を含むことができる。フィードバックチャネルはソースデバイスとシンクデバイスの間でインプリメントされる、ユーザ入力バックチャネル（ＵＩＢＣ）と称される逆チャネルアーキテクチャ上にピッギーバックされうる。【選択図】図１
2015501579.tif 000002
【特許請求の範囲】
【請求項１】
メディアデータを送信するための方法であって、
シンクデバイスにメディアデータを送信することと、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
前記シンクデバイスからメッセージを受信することと、ここにおいて前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされ、
前記メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて決定することと、
前記メッセージに基づいて、前記メディアデータの送信を調整することと
を備える方法。
【請求項２】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは、送信制御プロトコル（ＴＣＰ）である、
請求項１に記載の方法。
【請求項３】
リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、前記シンクデバイスの能力を決定することをさらに備える、
請求項１に記載の方法。
【請求項４】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項１に記載の方法。
【請求項５】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整することは、前記メディアデータを符号化するために使用される量子化パラメータを調整することを含む、
請求項１に記載の方法。
【請求項６】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整することは、瞬時復号化リフレッシュフレームを送信することを含む、
請求項１に記載の方法。
【請求項７】
メディアデータを受信するための方法であって、
ソースデバイスからメディアデータを受信することと、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて示すことと、
前記ソースデバイスに前記メッセージを送信することと
を備え、前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされる、
を備える、
方法。
【請求項８】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、
請求項７に記載の方法。
【請求項９】
リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、能力メッセージを送信することをさらに備える、
請求項７に記載の方法。
【請求項１０】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項７に記載の方法。
【請求項１１】
前記メッセージは、性能情報を含み、前記性能情報は、前記メディアデータの前記送信レートを調整するための、前記ソースデバイスに対する要求を含む、
請求項７に記載の方法。
【請求項１２】
前記メッセージは、性能情報を含み、前記性能情報は、瞬時復号化リフレッシュフレームを送信するための、前記ソースデバイスに対する要求を含む、
請求項７に記載の方法。
【請求項１３】
シンクデバイスにメディアデータを送信するための手段と、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
前記シンクデバイスからメッセージを受信するための手段と、ここにおいて前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされ、
前記メッセージが、ユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて決定するための手段と、
前記メッセージに基づいて、前記メディアデータの送信を調整するための手段と、
を備えるソースデバイス。
【請求項１４】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、
請求項１３に記載のソースデバイス。
【請求項１５】
リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、前記シンクデバイスの能力を決定するための手段をさらに備える、
請求項１３に記載のソースデバイス。
【請求項１６】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項１３に記載のソースデバイス。
【請求項１７】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整するための手段は、前記メディアデータを符号化するために使用される量子化パラメータを調整するための手段を含む、
請求項１３に記載のソースデバイス。
【請求項１８】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整するための手段は、瞬時復号化リフレッシュフレームを送信するための手段を含む、
請求項１３に記載のソースデバイス。
【請求項１９】
ソースデバイスからメディアデータを受信するための手段と、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
メッセージが、ユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて示すための手段と、
前記ソースデバイスに前記メッセージを送信するための手段と
を備え、前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされる、
シンクデバイス。
【請求項２０】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、
請求項１９に記載のシンクデバイス。
【請求項２１】
リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、能力メッセージを送信するための手段をさらに備える、
請求項１９に記載のシンクデバイス。
【請求項２２】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項１９に記載のシンクデバイス。
【請求項２３】
前記メッセージは、性能情報を含み、前記性能情報は、前記メディアデータの前記送信レートを調整するための、前記ソースデバイスに対する要求を含む、
請求項１９に記載のシンクデバイス。
【請求項２４】
前記メッセージは、性能情報を含み、前記性能情報は、瞬時復号化リフレッシュフレームを送信するための、前記ソースデバイスに対する要求を含む、
請求項１９に記載のシンクデバイス。
【請求項２５】
ソースデバイスであって、
メディアデータを記憶するメモリと、
前記ソースデバイスに、シンクデバイスにメディアデータを送信させ、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、前記シンクデバイスから受信されたメッセージを処理させ、ここにおいて前記メッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、前記メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて決定させ、前記メッセージに基づいて前記メディアデータの送信を調整させるための命令を実行するように構成されたプロセッサと、
を備えるソースデバイス。
【請求項２６】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、
請求項２５に記載のソースデバイス。
【請求項２７】
前記プロセッサは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、前記シンクデバイスの前記能力を決定するようにさらに構成される、
請求項２５に記載のソースデバイス。
【請求項２８】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項２５に記載のソースデバイス。
【請求項２９】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整するように構成されることは、前記メディアデータを符号化するために使用される量子化パラメータを調整することを含む、
請求項２５に記載のソースデバイス。
【請求項３０】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整するように構成されることは、瞬時復号化リフレッシュフレームを送信することを含む、
請求項２５に記載のソースデバイス。
【請求項３１】
シンクデバイスであって
メディアデータを記憶するメモリと、
前記シンクデバイスに、ソースデバイスから受信されたメディアデータを処理するように送信させ、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、前記ソースデバイスにメッセージを送信させ、ここにおいて前記メッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、前記メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて示させる、命令を実行するように構成されたプロセッサと、
を備える、シンクデバイス。
【請求項３２】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは、送信制御プロトコル（ＴＣＰ）である、
請求項３１に記載のシンクデバイス。
【請求項３３】
前記プロセッサは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、前記シンクデバイスの前記能力を決定するようにさらに構成される、
請求項３１に記載のシンクデバイス。
【請求項３４】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項３１に記載のシンクデバイス。
【請求項３５】
前記メッセージは、性能情報を含み、前記性能情報は、前記メディアデータの前記送信レートを調整するための、前記ソースデバイスに対する要求を含む、
請求項３１に記載のシンクデバイス。
【請求項３６】
前記メッセージは、性能情報を含み、前記性能情報は、瞬時復号化リフレッシュフレームを送信するための、前記ソースデバイスに対する要求を含む、
請求項３１に記載のシンクデバイス。
【請求項３７】
ソースデバイスのプロセッサにおいて実施されるとき、前記ソースデバイスに、
シンクデバイスにメディアデータを送信させ、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
前記シンクデバイスから受信されたメッセージを処理させ、ここにおいて前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされ、
前記メッセージが、ユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて決定させ、
前記メッセージに基づいて、前記メディアデータの送信を調整させる、
命令を記憶したコンピュータ可読媒体。
【請求項３８】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、
請求項３７に記載のコンピュータ可読媒体。
【請求項３９】
ソースデバイスで実施されるとき、プログラム可能プロセッサにリアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、前記シンクデバイスの前記能力を決定させる命令をさらに記憶した
請求項３７に記載のコンピュータ可読媒体。
【請求項４０】
前記メッセージは性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項３７に記載のコンピュータ可読媒体。
【請求項４１】
前記メッセージは性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整することは、前記メディアデータを符号化するために使用される量子化パラメータを調整することを含む、
請求項３７に記載のコンピュータ可読媒体。
【請求項４２】
前記メッセージは、性能情報を含み、前記性能情報は、パケットエラー情報を含み、前記メッセージに基づいて前記メディアデータの送信を調整することは、瞬時復号化リフレッシュフレームを送信することを含む、
請求項３７に記載のコンピュータ可読媒体。
【請求項４３】
シンクデバイスのプロセッサにおいて実施されるとき、前記シンクデバイスに、
ソースデバイスから受信されたメディアデータを処理させ、ここにおいてメディアデータは、第１のトランスポートプロトコルにしたがってトランスポートされ、
メッセージが、ユーザ入力情報または性能情報のうちの１つを含むかどうかを、少なくとも部分的にデータパケットヘッダに基づいて示させ、
前記ソースデバイスに前記メッセージを送信させ、ここにおいて前記メッセージは、第２のトランスポートプロトコルにしたがってトランスポートされる、
命令を記憶したコンピュータ可読媒体。
【請求項４４】
前記第１のトランスポートプロトコルは、ユーザデータプロトコル（ＵＤＰ）であり、前記第２のトランスポートプロトコルは送信制御プロトコル（ＴＣＰ）である、請求項４３に記載のコンピュータ可読媒体。
【請求項４５】
シンクデバイスで実施されるとき、プログラム可能プロセッサにリアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して、能力メッセージを送信させる、命令をさらに記憶した、
請求項４３に記載のコンピュータ可読媒体。
【請求項４６】
前記メッセージは、性能情報を含み、前記性能情報は、少なくとも前記シンクデバイスで受信された前記メディアデータのためのタイムスタンプ値を含む、
請求項４３に記載のコンピュータ可読媒体。
【請求項４７】
前記メッセージは、性能情報を含み、前記性能情報は、前記メディアデータの前記送信レートを調整するための、前記ソースデバイスに対する要求を含む、
請求項４３に記載のコンピュータ可読媒体。
【請求項４８】
前記メッセージは、性能情報を含み、前記性能情報は、瞬時復号化リフレッシュフレームを送信するための、前記ソースデバイスに対する要求を含む、
請求項４３に記載のシンクデバイス。
【発明の詳細な説明】
【関連出願】
【０００１】
本願は、２０１１年１０月１４日付で提出された米国仮出願第６１／５４７、３９７号、および２０１２年２月２９日付で提出された米国仮出願第６１／６０４、６７４号の利益を主張し、その内容全体が参照によりここに組み込まれる。
【技術分野】
【０００２】
本開示は、メディアデータのトランスポートおよび再生、より具体的には、メディアデータのトランスポートおよび再生にわたる制御に関する。
【背景技術】
【０００３】
ワイヤレスディスプレイ（ＷＤ）システムは、ソースデバイスおよび１つまたは複数のシンクデバイスを含む。ソースデバイスは、ワイヤレスローカルエリアネットワーク内でメディアコンテンツを送信することができるデバイスでありうる。シンクデバイスは、メディアコンテンツを受信およびレンダリングすることができるデバイスでありうる。ソースデバイスおよびシンクデバイスは、移動デバイスまたはワイヤード（wired）デバイスのどちらかでありうる。移動デバイスとして、例えばソースデバイスおよびシンクデバイスは、移動電話、ワイヤレス通信カードを有する携帯用コンピュータ、携帯情報端末（ＰＤＡ）、携帯用メディアプレイヤ、カメラまたはビデオカメラのようなデジタル画像キャプチャデバイス、あるいは、いわゆる「スマート」フォンおよび「スマート」パッドまたはタブレット、もしくは他のタイプのワイヤレス通信デバイスを含む、ワイヤレス通信能力を有する他のフラッシュメモリデバイスを備えることができる。ワイヤードデバイスとして、例えばソースデバイスおよびシンクデバイスは、テレビ、デスクトップコンピュータ、モニタ、プロジェクタ、プリンタ、音声増幅器、セットトップボックス、ゲーム機、ルータ、ならびにデジタルビデオディスク（ＤＶＤ）プレイヤおよびメディアサーバを備えることができる。
【０００４】
ソースデバイスは、音声ビデオ（ＡＶ）データのような、メディアデータを特定のメディア共有セッションに参加するシンクデバイスの１つまたは複数に伝送することができる。メディアデータは、ソースデバイスの局地的ディスプレイ、およびシンクデバイスのディスプレイの各々の両方で再生されうる。より具体的には、参加するシンクデバイスの各々は、そのスクリーンおよび音声機器上での表示のために受信されたメディアデータをレンダリングする。いくつかのケースでは、シンクデバイスのユーザは、タッチ入力および遠隔制御入力のような、ユーザ入力をシンクデバイスに適用することができる。
【発明の概要】
【０００５】
概して、本開示は、ワイヤレスディスプレイ（ＷＤ）システムにおけるシンクデバイスが、ソースデバイスにおける、例えば音声ビデオ（ＡＶ）データなどのメディアデータの処理を調整するためにソースデバイスに性能情報フィードバックを伝送することを可能にする技法に関する。ソースおよびシンクデバイスは、現在開発中にある、ワイヤレスＨＤ、ワイヤレスホームデジタルインターフェース（ＷＨＤＩ）、ＷｉＧｉｇ、ワイヤレスＵＳＢおよびＷｉ−Ｆｉディスプレイ（ＷＦＤ）規格のような、規格に準拠するＷＤ通信技法をインプリメントしうる。ＷＦＤ規格についての追加の情報は、Ｗｉ−Ｆｉアライアンス技術協会、Ｗｉ−Ｆｉアライアンスのディスプレイタスクグループ(Wi-Fi Alliance Technical Committee, Display Task Group)、「Wi-Fi Display Specification draft version 1.31」に見受けられることができ、これは、全体として参照によりここに組み込まれている。ＷＤシステムは、ソースデバイスとシンクデバイスとの間のパケットロスまたはチャネル輻輳に起因したメディア性能の低下を時により経験しうる。ソースデバイスが、シンクデバイスで経験された性能の低下に基づいて、例えばコード化および／またはパケット送信の動作などの、そのメディアデータの処理を調整することができることは有利でありうる。しかしながら現在のＷＦＤ基準は、ソースデバイスがシンクデバイスから性能情報を受信することができるメカニズムを含まない。
【０００６】
本開示の技法は、シンクデバイスがソースデバイスに性能情報フィードバックを伝送することができるように、ＷＤシステムにおいてソースデバイスとシンクデバイスとの間にフィードバックチャネルを確立することを含むことができる。性能情報フィードバックは、受信されたメディアデータに基づいてシンクデバイスで測定または計算されることができるメディアデータ通信チャネルおよびＷＤシステムの性能インジケータを含むことができる。例えば、性能情報フィードバックは、往復遅延、遅延ジッタ、パケットロスレート、エラー分布、パケットエラーレート、および受信信号強度指示（ＲＳＳＩ）のうちの１つまたは複数を含むことができる。いくつかの例では、ソースデバイスは、性能情報に基づいてメディアデータの送信に対する調整を行うことができる。他の例では、シンクデバイスは、ソースデバイスによって行われるべきメディアデータの送信の明示的な調整を有する性能情報に提供することができる。例えば、性能情報メッセージは、ビットレートを増加または減少させるための、あるいは瞬時復号化リフレッシュ(instantaneous decoder refresh)（ＩＤＲ）フレームを送信するためのメッセージを含むことができる。フィードバックチャネルは、シンクデバイスで受信されたユーザ入力をソースデバイスに通信するようにインプリメントされる、ユーザ入力バックチャネル(User Input Back Channel)（ＵＩＢＣ）と称される逆チャネルアーキテクチャ上でピギーバックされうる。
【０００７】
１つの例では、メディアデータを送信する方法は、シンクデバイスにメディアデータを送信することと、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、シンクデバイスからメッセージを受信することと、ここにおいて、メッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報またはデータパケットヘッダに基づく性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて決定することと、メッセージに基づいてメディアデータの送信を調整することと、を備える。
【０００８】
別の例では、メディアデータを受信する方法は、ソースデバイスからメディアデータを受信することと、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、ソースデバイスにメッセージを送信することと、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて示すことと、を備える。
【０００９】
別の例では、ソースデバイスは、シンクデバイスにメディアデータを送信するための手段と、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、シンクデバイスからメッセージを受信するための手段と、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて決定するための手段と、メッセージに基づいてメディアデータの送信を調整するための手段と、を備える。
【００１０】
別の例では、シンクデバイスは、ソースデバイスからメディアデータを受信するための手段と、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、ソースデバイスにメッセージを送信するための手段と、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて示すための手段と、を備える。
【００１１】
別の例では、ソースデバイスは、メディアデータを記憶するメモリと、ソースデバイスに、シンクデバイスにメディアデータを送信させ、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、シンクデバイスから受信されたメッセージを処理させ、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて決定させ、メッセージに基づいてメディアデータの送信を調整させる、命令を実行するように構成されたプロセッサを備える。
【００１２】
別の例では、シンクデバイスは、メディアデータを記憶するメモリと、シンクデバイスに、ソースデバイスから受信されたメディアデータを処理するように送信させ、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、ソースデバイスにメッセージを送信させ、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて示させる、命令を実行するように構成されたプロセッサを備える。
【００１３】
別の例では、コンピュータ可読媒体は、ソースデバイスにおいて実行されるときに、プロセッサに、シンクデバイスにメディアデータを送信させ、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、シンクデバイスから受信されたメッセージを処理させ、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて決定させ、メッセージに基づいてメディアデータの送信を調整させる、命令を記憶する。
【００１４】
１つの例では、コンピュータ可読媒体は、シンクデバイスにおいて実行されるときに、プロセッサに、ソースデバイスから受信されたメディアデータを処理させ、ここにおいてメディアデータは第１のトランスポートプロトコルにしたがってトランスポートされ、ソースデバイスにメッセージを送信させ、ここにおいてメッセージは第２のトランスポートプロトコルにしたがってトランスポートされ、メッセージがユーザ入力情報または性能情報のうちの１つを含むかどうかを、データパケットヘッダに少なくとも部分的に基づいて示させる、命令を記憶する。
【００１５】
本開示の１つまたは複数の例の詳細は、添付図面および以下の説明において述べられている。他の特徴、オブジェクト、および利点は、記述および図面から、ならびに請求項から明らかになる。
【図面の簡単な説明】
【００１６】
【図１】ソースデバイスおよびシンクデバイスを含むワイヤレス通信システムを例示するブロック図。
【図２】通信基準モデル例を例示する概略図。
【図３】ソースデバイスにフィードバックとしてシンクデバイスから性能情報をシグナリングするように使用されるフィードバックパケットを例示する概略図。
【図４】シンクデバイスからソースデバイスへの性能情報フィードバックに基づいてメディアデータのビットレートを適合させる実例となる動作を例示するフローチャート。
【図５】いくつかの異なるシナリオにおける、図３からのフィードバックパケットのペイロードデータに含まれるフィードバックメッセージまたはユーザ入力のための実例となるメッセージフォーマットを例示する概略図。
【図６】フィードバック情報に基づいてメディアデータの送信を調整するための技法をインプリメントするソースデバイスの例を例示するブロック図。
【図７】フィードバック情報を提供するための技法をインプリメントするシンクデバイスの例を例示するブロック図。
【図８】フィードバック情報に基づいてメディアデータの送信を調整するための技法を例示するフローチャート。
【図９】フィードバック情報を提供するための技法を例示するフローチャート。
【詳細な説明】
【００１７】
現在のＷＤシステムでは、レガシフィードバックメッセージングは、シンクデバイスからソースデバイスにフィードバックを提供するために使用される。レガシフィードバックメッセージングは以下のように進行する：シンクデバイスは、シーケンスパラメータセット（ＳＰＳ）または画像パラメータセット（ＰＰＳ）を要求する；ソースデバイスは、ＳＰＳまたはＰＰＳで応答する；シンクデバイスは、ストリーミングを開始するように要求する；シンクデバイスは、信号が生成されると、ユーザ起動型ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）ユーザ入力を伝送する。シンクデバイスはまた、時間において増加し続ける値として、通信チャネルのためのパケットエラーレート（ＰＥＲ）を計算する。現在のＷＤシステムは、ソースデバイスにＰＥＲ値をフィードバックしない。
【００１８】
本開示の技法にしたがって、フィードバックチャネルは、シンクデバイスがソースデバイスに性能情報フィードバックを伝送することができるように、シンクデバイスとソースデバイスとの間に確立される。フィードバックチャネルは、一定の間隔でソースデバイスに、通信チャネルおよびシンクデバイスの両方のための性能情報を送ることができる。例えば、技法にしたがうと、シンクデバイスは、時間において増加する値にわたるのではなく同期ウィンドウ間隔で、音声またはビデオチャネルのどちらかについてのＰＥＲを計算することができる。同期ウィンドウは１秒であるように定義されうる。したがって、シンクデバイスは、毎秒ＰＥＲを算出することができ、ソースデバイスに伝送されるべきフィードバックメッセージを生成することができる。本開示の技法は、適切なメッセージを定義し、ソースデバイスおよびシンクデバイスの両方によって合意されるフォーマットでソースデバイスに返送するようにシンクデバイスでインプリメントされるエラー管理プロセスを含むことができる。エラー管理システムおよびメッセージフォーマットは以下でより詳細に説明される。
【００１９】
性能情報フィードバックを受信する際に、ソースデバイスは、どのようにそれがシンクデバイスに伝送される後のメディアデータを処理するかを調整することができる。シンクデバイスからの性能情報フィードバックに基づいて、ソースデバイスは、そのメディアデータ符号化動作および／またはそのパケット送信動作を調整することができる。例えば、ソースデバイスは、類似の性能の低下を回避するために、より低い品質で後のメディアデータを符号化することができる。別の例では、ソースデバイスは、失った指定パケットを識別し、そのパケットを再送信することを決めることができる。
【００２０】
図１は、性能情報メッセージに基づいてメディアデータの送信の調整をサポートすることができるシンクデバイス１６０とソースデバイス１２０を含むワイヤレスディスプレイ（ＷＤ）システム１００の例を例示するブロック図である。図１で提示されているように、ＷＤシステム１００は、通信チャネル１５０を介してシンクデバイス１６０と通信するソースデバイス１２０を含む。
【００２１】
ソースデバイス１２０は、メモリ１２２、ディスプレイ１２４、スピーカ１２６、音声および／またはビデオ（Ａ／Ｖ）符号化器１２８、音声および／またはビデオ（Ａ／Ｖ）制御モジュール１３０、および送信機／受信機（ＴＸ／ＲＸ）ユニット１３２を含むことができる。シンクデバイス１６０は、送信機／受信機ユニット１６２、音声および／またはビデオ（Ａ／Ｖ）復号器１６４、ディスプレイ１６６、スピーカ１６８、ユーザ入力（ＵＩ）デバイス１７０、およびユーザ入力処理モジュール（ＵＩＰＭ）１７２を含むことができる。例示されたコンポーネントは、単にＷＤシステム１００のための１つの例示的な構成の構成要素となる。他の構成は、例示されるものよりも少ないコンポーネントを含むことをできる、あるいは例示されるものよりも追加のコンポーネント含むことができる。
【００２２】
図１の例において、ソースデバイス１２０は、ディスプレイ１２４上にＡ／Ｖデータのビデオ部分をディスプレイすることができ、スピーカ１２６を使用してＡ／Ｖデータの音声部分を出力することができる。Ａ／Ｖデータは、メモリ１２２上にローカルに記憶され、ファイルサーバ、ハードドライブ、外部メモリ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、または他の物理的記憶媒体のような外部記憶メディアからアクセスされ、あるいは、インターネットのようなネットワーク接続を介してソースデバイス１２０にストリーミングされうる。いくつかの事例では、Ａ／Ｖデータは、ソースデバイス１２０のマイクロフォンおよびカメラを介してリアルタイムにキャプチャされうる。Ａ／Ｖデータは、映画、テレビ番組、または音楽のようなマルチメディアコンテンツを含むことができるけれども、ソースデバイス１２０によって生成されるリアルタイムコンテンツを含むこともできる。そのようなリアルタイムコンテンツは、例えば、ソースデバイス１２０上で作動するアプリケーションまたは、例えばビデオ電話セッションの一部としてキャプチャされるビデオデータによって作り出されうる。そのようなリアルタイムコンテンツは、いくつかの事例では、ユーザが選択するのに利用可能であるユーザ入力オプションのビデオフレームを含むことができる。いくつかの事例では、Ａ／Ｖデータは、ビデオのフレームに重ね合わせられたユーザ入力オプションを有する動画またはＴＶプログラムのビデオフレームのような、異なるタイプのコンテンツの組み合わせであるビデオフレームを含むことができる。
【００２３】
ディスプレイ１２４およびスピーカ１２６を介してローカルにＡ／Ｖデータをレンダリングすることに加えて、ソースデバイス１２０のＡ／Ｖ符号化器１２８は、Ａ／Ｖデータを符号化することができ、送信機／受信機ユニット１３２は、シンクデバイス１６０に通信チャネル１５０を通じて符号化されたデータを送信することができる。シンクデバイス１６０の送信機／受信機ユニット１６２は、符号化されたデータを受信し、Ａ／Ｖ復号器１６４は、符号化されたデータを復号し、ディスプレイ１６６およびスピーカ１６８上での表示のために復号されたデータを出力しうる。この方法で、ディスプレイ１２４およびスピーカ１２６によってレンダリングされている音声およびビデオデータは、ディスプレイ１６６およびスピーカ１６８によって同時にレンダリングされうる。音声データおよびビデオデータはフレーム内で配列され、音声フレームは、レンダリングされるとき、ビデオフレームと時間同期されうる。
【００２４】
Ａ／Ｖ符号化器１２８およびＡ／Ｖ復号器１６４は、ＭＰＥＧ４、パート１０、進化型ビデオコーディング（ＡＶＣ）、または新興の高効率ビデオコーディング（ＨＥＶＣ）規格として代わりに称される、ＩＴＵ−Ｔ  Ｈ．２６４規格のような、あらゆる数の音声およびビデオ圧縮規格をインプリメントすることができる。多くの他のタイプの特許権のある、または規格化された圧縮技法もまた使用されうる。一般的に言えば、Ａ／Ｖ復号器１６４は、Ａ／Ｖ符号化器１２８の相互コード化動作を実行するように構成される。図１では提示されていないけれども、いくつかの態様では、Ａ／Ｖ符号化器１２８およびＡ／Ｖ復号器１６４は、それぞれ音声符号化器および復号器と一体化し、共通のデータストリームまたは別個のデータストリームにおける音声およびビデオの両方の符号化を扱うために、適切なＭＵＸ−ＤＥＭＵＸユニットまたは他のハードウェアおよびソフトウェアを含むことができる。
【００２５】
以下でより詳細に記述されることになるように、Ａ／Ｖ符号化器１２８は、上で記述されたビデオ圧縮規格をインプリメントすることに加えて、他の符号化機能を行うことができる。例えば、Ａ／Ｖ符号化器１２８は、Ａ／Ｖデータがシンクデバイス１６０に送信される前にＡ／Ｖデータに様々なタイプのメタデータを加えることができる。いくつかの事例では、Ａ／Ｖデータは、符号化された形態でソースデバイス１２０に記憶される、またはソースデバイス１２０で受信されることができ、したがってＡ／Ｖ符号化器による更なる圧縮を要求しない。
【００２６】
図１は、音声ペイロードデータおよびビデオペイロードデータを別個で搬送する通信チャネル１５０を提示しているけれども、いくつかの事例では、ビデオペイロードデータおよび音声ペイロードデータは共通のデータストリームの一部でありうることは理解されるべきである。適用可能である場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ．Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルに従うことができる。Ａ／Ｖ符号化器１２８およびＡ／Ｖ復号器１６４はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせとしてインプリメントされうる。Ａ／Ｖ符号化器１２８およびＡ／Ｖ復号器１６４のそれぞれは、１つまたは複数の符号化器または復号器に含まれることができ、符号化器または復号器のどちらかは、結合された符号化器／復号器（ＣＯＤＥＣ）の一部として一体化されうる。したがって、ソースデバイス１２０およびシンクデバイス１６０のそれぞれは、本開示の技法の１つまたは複数を実施するように構成された専門の機械を備えうる。
【００２７】
ディスプレイ１２４およびディスプレイ１６８は、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なビデオ出力デバイスのいずれも備えることができる。これらの、または他の例では、ディスプレイ１２４および１６８はそれぞれ、放射ディスプレイまたは透過ディスプレイでありうる。ディスプレイ１２４およびディスプレイ１６６はまた、それらが同時に入力デバイスおよびディスプレイデバイスの両方であるようなタッチディスプレイでもありうる。そのようなタッチディスプレイは、容量型(capasitive)であり、抵抗性(resistive)であり、またはユーザが各デバイスにユーザ入力を提供することができるようにする他のタイプのタッチパネルでありうる。
【００２８】
スピーカ１２６およびスピーカ１６８は、ヘッドフォン、シングルスピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。加えて、ディスプレイ１２４およびスピーカ１２６は、ソースデバイス１２０の一部として提示され、ディスプレイ１６６およびスピーカ１６８は、シンクデバイス１６０の一部として提示されているけれども、ソースデバイス１２０およびシンクデバイス１６０は、実際はデバイスのシステムでありうる。１つの例として、デディスプレイ１６６はテレビであることができ、スピーカ１６８はサラウンド音響システムであることができ、Ａ／Ｖ復号器１６４は、ディスプレイ１６６およびスピーカ１６８にワイヤードまたはワイヤレスのどちらかで接続された外部ボックスの一部でありうる。他の事例では、シンクデバイス１６０は、タブレットコンピュータまたはスマートフォンのようなシングルデバイスでありうる。また他のケースでは、ソースデバイス１２０およびシンクデバイス１６０は、例えば両方がスマートフォン、タブレットコンピュータであるなど、類似のデバイスである。このケースでは、１つのデバイスはソースとして動作し、もう一方はシンクとして動作しうる。これらの役割は、後の通信セッションで逆にされうる。また他のケースでは、ソースデバイス１２０は、スマートフォン、ラップトップ、またはタブレットコンピュータのようなモバイルデバイスを備えることができ、シンクデバイス１６０は、（例えば、ＡＣ電力コードを有する）より静的なデバイスを備えることができ、そのケースではソースデバイス１２０は、シンクデバイス１６０を介して１つまたは複数の視聴者への表示のために音声およびビデオデータを配信することができる。
【００２９】
送信機／受信機ユニット１３２および送信機／受信機ユニット１６２はそれぞれ、様々なミキサ、フィルタ、増幅器、および信号変調のために設計された他のコンポーネントを、データを送信および受信するために設計された１つまたは複数のアンテナおよび他のコンポーネントと同様に含むことができる。通信チャネル１５０は、ソースデバイス１２０とシンクデバイス１６０との間の音声／ビデオデータ、制御データおよびフィードバックを送信するための、あらゆる適した通信メディアまたは異なる通信メディアの集合を概して表す。通信チャネル１５０は、大抵、比較的短距離の通信チャネルであり、定義された２．４ＧＨｚ、３．６ＧＨｚ、５ＧＨｚ、６０ＧＨｚ、または超高帯域（ＵＷＢ）周波数帯域構造をインプリメントするような、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などに類似する物理チャネル構造をインプリメントすることができる。しかしながら通信チャネル１５０は、この点で必ずしも限定されず、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理送信ラインのようなあらゆるワイヤレスまたはワイヤード通信メディア、あるいはワイヤレスおよびワイヤードメディアのあらゆる組み合わせを備えることができる。他の例では、通信チャネル１５０は、ワイヤードまたはワイヤレスローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークのような、パケットに基づくネットワークの一部を形成さえしうる。加えて、通信チャネル１５０は、ピアツーピアリンクを作り出すためにソースデバイス１２０およびシンクデバイス１６０によって使用されうる。
【００３０】
ソースデバイス１２０およびシンクデバイス１６０は、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを使用する能力ネゴシエーションにしたがって通信セッションを確立することができる。１つの例では、通信セッションを確立するための要求は、シンクデバイス１６０にソースデバイス１２０によって伝送されうる。一度メディア共有セッションが確立されると、ソースデバイス１２０は、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用して参加しているシンクデバイス１６０に、例えば音声ビデオ（ＡＶ）データのようなメディアデータを送信する。シンクデバイス１６０は、そのディスプレイおよび音声機器（図１には図示せず）に受信されたメディアデータをレンダリングする。
【００３１】
ソースデバイス１２０およびシンクデバイス１６０は、その後、規格のうちのＩＥＥＥ８０２．１１ファミリの規格のような通信プロトコルを使用して、通信チャネル１５０を通じて通信することができる。１つの例では、通信チャネル１５０は、ネットワーク通信チャネルでありうる。この例では、通信サービスプロバイダが、ネットワークハブとして基地局を使用して１つまたは複数のネットワークを中心的に動作させ、統括することができる。ソースデバイス１２０およびシンクデバイス１６０は、例えば、ソースデバイス１２０およびシンクデバイス１６０がワイヤレスポイントまたはいわゆるホットスポットのような媒介を使用することなく互いに直接通信するように、Ｗｉ−ＦｉダイレクトまたはＷｉ−Ｆｉディスプレイ（ＷＦＤ）規格にしたがって通信することができる。ソースデバイス１２０およびシンクデバイス１６０はまた、ネットワーク輻輳を回避または低減するために、トンネルされた直接リンクセットアップ(tunneled direct link setup)（ＴＤＬＳ）を確立することもできる。ＷＦＤおよびＴＤＬＳは、比較的短距離の通信セッションをセットアップするように意図される。このコンテクストにおける比較的短距離は、例えば、雑音のある、または妨害された環境において、デバイス間の距離が約３５メートルより短いまたは約２０メートルよりも短い、など、さらに短くなりうるけれども、約７０メートルよりも短いものを称しうる。
【００３２】
本開示の技法は、時に触れてＷＦＤに関係して記述されうるけれども、これらの技法の態様はまた、他の通信プロトコルと互換性がありうると考慮される。限定ではなく例としてソースデバイス１２０とシンクデバイスとの間のワイヤレス通信は、直交周波数多重（ＯＦＤＭ）技法を利用することができる。時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡ、および／またはＣＤＭＡのあらゆる組み合わせを限定ではなく含む幅広い種類の他のワイヤレス通信技法もまた、使用されうる。
【００３３】
ソースデバイス１２０から受信されたデータを復号およびレンダリングすることに加えて、シンクデバイス１６０はまた、ユーザ入力デバイス１７０からユーザ入力を受信することもできる。ユーザ入力デバイス１７０は、例えば、キーボード、マウス、トラックボールまたはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、またはあらゆる他のそのようなユーザ入力デバイスでありうる。ＵＩＰＭ１７２は、ソースデバイス１２０が処理することができるデータパケット構造に、ユーザ入力デバイス１７０によって受信されるユーザ入力コマンドをフォーマット化する。そのようなデータパケットは、通信チャネル１５０を通じてソースデバイス１２０に送信機／受信機１６２によって送信される。送信機／受信機ユニット１３２は、データパケットを受信し、Ａ／Ｖ制御モジュール１３０は、ユーザ入力デバイス１７０によって受信されたユーザ入力コマンドを解釈するためにデータパケットを解析する。データパケットにおいて受信されたコマンドに基づいて、Ａ／Ｖ制御モジュール１３０は、符号化および送信されているコンテンツを変更しうる。この方法で、シンクデバイス１６０のユーザは、遠隔で、ならびにソースデバイス１２０と直接情報を交換することなく、ソースデバイス１２０によって送信されている音声ペイロードデータおよびビデオペイロードデータを制御することができる。
【００３４】
加えて、シンクデバイス１６０のユーザは、ソースデバイス１２０上でアプリケーションを開始および制御することができることがある。例えば、シンクデバイス１６０のユーザは、ソースデバイス１２０上に記憶されたフォト編集アプリケーションを開始し、ソースデバイス１２０上にローカルに記憶されるフォトを編集するためのアプリケーションを使用することができる。シンクデバイス１６０は、実際にフォトがソースデバイス１２０上で編集されている間にフォトがシンクデバイス１６０上でローカルに編集されているように見える、ならびに感じるユーザエクスペリエンスをユーザに表示しうる。そのような構成を使用して、ユーザは、いくつかのデバイスと共に使用する１つのデバイスの能力を活用することができる。例えば、ソースデバイス１２０は、大容量のメモリおよびハイエンド処理能力を有するスマートフォンを備えることができる。しかしながら、動画を視聴しているとき、ユーザは、より大きなディスプレイスクリーンを有するデバイス上で動画を視聴することを望み、そのケースでは、シンクデバイス１６０がタブレットコンピュータまたは、さらにより広いディスプレイデバイスあるいはテレビでありうる。ｅｍａｉｌを伝送またはｅｍａｉｌに応答したいとき、ユーザは、物理的なキーボードを有するデバイスを使用することを望み、そのケースではシンクデバイス１６０はラップトップでありうる。両方の事例において、ユーザはシンクデバイス１６０と情報を交換するけれども大量の処理が依然としてソースデバイス１２０によって行われうる。ソースデバイス１２０およびシンクデバイス１６０は、通信チャネル１５０を通じたあらゆる所与のセッションにおいてデバイスの能力をネゴシエートおよび／または識別するために使用されるデータのような、制御データを送信することによって双方向に情報を交換することを容易にしうる。
【００３５】
いくつかの構成では、Ａ／Ｖ制御モジュール１３０は、ソースデバイス１２０の動作システムによって実施されている動作システムプロセスを備えることができる。しかしながら他の構成では、Ａ／Ｖ制御モジュール１３０は、ソースデバイス１２０上で作動するアプリケーションのソフトウェアプロセスを備えることができる。そのような構成では、ユーザ入力コマンドは、ソースデバイス１２０上で作動する動作システムとは対照的なものとしてのソースデバイス１２０上で作動するアプリケーションとシンクデバイス１６０のユーザが直接情報を交換するように、ソフトウェアプロセスによって解釈されうる。動作システムとは対照的なものとしてのアプリケーションと直接情報を交換することによって、シンクデバイス１６０のユーザは、ソースデバイス１２０の動作システムに生来属していないコマンドのライブラリへのアクセスを有すことができる。加えて、アプリケーションと直接情報を交換することは、コマンドが異なるプラットフォーム上で作動するデバイスによってより容易に送信および処理されることを可能にする。
【００３６】
シンクデバイス１６０で適用されるユーザ入力は、通信チャネル１５０を通じてソースデバイス１２０に返送されうる。１つの例では、ユーザインターフェースバックチャネル（ＵＩＢＳ）としても称される、逆チャネルアーキテクチャは、シンクデバイス１６０がソースデバイス１２０にシンクデバイス１６０で適用されるユーザ入力を送信することを可能にするようにインプリメントされうる。逆チャネルアーキテクチャは、ユーザ入力をトランスポートするためのより上部のレイヤメッセージ、およびシンクデバイス１６０およびソースデバイス１２０でユーザインターフェース能力をネゴシエートするためのより下部のレイヤフレームを含むことができる。ＵＩＢＣは、シンクデバイス１６０とソースデバイス１２０との間のインターネットプロトコル（ＩＰ）トランスポートレイヤにわたって存在しうる。この方法で、ＵＩＢＣは、開放型システム間相互接続（ＯＳＩ）通信モデルにおいてトランスポートレイヤよりも上部にありうる。信頼性のある送信を促すため、ならびにユーザ入力データを含むデータパケットのシーケンスな配信において、ＵＩＢＣは、送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）またはユーザデータグラムプロトコル（ＵＤＰ）のような他のパケットに基づく通信プロトコルのトップで作動するように構成されうる。ＵＤＰおよびＴＣＰは、ＯＳＩレイヤアーキテクチャにおいて並列で動作しうる。ＴＣＰ／ＩＰは、シンクデバイス１６０およびソースデバイス１２０がパケットロスのイベントにおいて再送信技法をインプリメントすることを可能にしうる。
【００３７】
ＵＩＢＣは、クロスプラットフォームユーザ入力データを含む、様々なタイプのユーザ入力データをトランスポートするように設計されうる。例えば、ソースデバイス１２０は、ｉＯＳ動作システムを作動させ、一方でシンクデバイス１６０は、Ａｎｄｒｏｉｄ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）のような別の動作システムを作動させる。プラットフォームに関わらず、ＵＩＰＭ１７２は、Ａ／Ｖ制御モジュール１３０に対して理解可能な形態で、受信されたユーザ入力をカプセル化しうる。多数の異なるタイプのユーザ入力フォーマットは、多くの異なるタイプのソースおよびシンクデバイスが、ソースおよびシンクデバイスが異なるプラットフォーム上で動作するかどうかに関わらずプロトコルを有効に使うことができるように、ＵＩＢＣによってサポートされうる。定義される包括的入力フォーマットおよびプラットフォーム特有入力フォーマットは両方ともサポートされ、それにより、ユーザ入力がＵＩＢＣによってソースデバイス１２０とシンクデバイス１６０との間で通信されることができる方法でフレクシビリティを提供する。
【００３８】
ＷＤシステム１００は、ソースデバイス１２０とシンクデバイス１６０との間のパケットロスまたはチャネル輻輳に起因したメディア性能の低下を時により経験しうる。例えば、ロスの多い、ならびにエラーを起こしやすい通信ネットワークを通じたビデオ送信は、送信中に差し込まれるエラーを起こしやすい。いくつかのアプリケーションでは、リアルタイムでビデオをストリーミングすることが要求されうる。これらのアプリケーションでは、エラーは受け入れられないユーザエクスペリエンスを提供しうる。例えば、ロスが受け入れられないまたは管理できないレベルまで増加する前に、通信セッションおける初期でエラーを正す、または低減させるように適切な測定を行うことが望ましい。送信中に差し込まれたエラーが正されうる、または低減されうるいくつかのステージが存在する。現在のＷＦＤ規格は、ソースデバイス１２０がシンクデバイス１６０から性能情報を受信することができるメカニズムを含まない。ソースデバイス１２０が、パケットロスまたはチャネル輻輳に起因したメディア性能の低下を低減させるためにシンクデバイス１６０で経験される性能に基づいて、例えばコード化および／またはパケット送信動作などの、そのメディアデータ処理を調整することができることが利点である。
【００３９】
より具体的には、シンクデバイス１６０は、フィードバック信号を使用して、ソースデバイス１２０に性能情報をシグナリングすることができる。ソースデバイス１２０におけるＡ／Ｖ制御モジュール１３０はその後、性能情報に基づいてＡ／Ｖ処理をどのように調整するかを識別するために受信された信号を解析することができる。Ａ／Ｖ制御モジュール１３０は、シンクデバイス１６０にレンダリングおよび送信されているコンテンツのタイプを変更するために、ソースデバイス１２０の動作、および／またはソースデバイス１２０上で作動するアプリケーションを修正しうる。本開示の技法にしたがって、ソースデバイス１２０およびシンクデバイス１６０は、性能情報メッセージに基づいてメディアデータの送信レートの調整をサポートすることができる。
【００４０】
図２は、ＷＤシステムのためのデータ通信モデルまたはプロトコルスタックの例を例示するブロック図である。データ通信モデル２００は、インプリメントされるＷＤシステムにおけるソースデバイスとシンクデバイスとの間でデータを送信するために使用されるデータと制御プロトコルとの間の情報を交換することを例示している。１つの例では、ＷＤシステム１００はデータ通信モデル２００を使用することができる。データ通信モデル２００は、物理（ＰＨＹ）レイヤ２０２、メディアアクセス制御（ＭＡＣ）レイヤ（２０４）、インターネットプロトコル（ＩＰ）２０６、ユーザデータグラムプロトコル（ＵＤＰ）２０８、リアルタイムプロトコル（ＲＴＰ）２１０、ＭＰＥＧ２トランスポートストリーム（ＭＰＥＧ２−ＴＳ）２１２、コンテンツ保護２１４、パケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６、ビデオコデック２１８、音声コデック２２０、送信制御プロトコル（ＴＣＰ）２２２、リアルタイムストリーミングプロトコル（ＲＴＳＰ）２２４、フィードバックパケット化２２８、ヒューマンインターフェースデバイス制約２３０、包括的ユーザ入力２３２、および性能分析２３４を含む。
【００４１】
物理レイヤ２０２およびＭＡＣレイヤ２０４は、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定、およびチャネルアクセス制御を定義することができる。物理レイヤ２０２およびＭＡＣレイヤ２０４は、例えば、２．４ＧＨｚ、３．６ＧＨｚ、５ＧＨｚ、６０ＧＨｚ、または超高帯域（ＵＷＢ）周波数帯域構造で定義された米国連邦通信委員会の帯域のような、通信のために使用される周波数帯域構造、を定義しうる。物理レイヤ２０２およびＭＡＣ２０４は、アナログおよびデジタル振幅変調技法、周波数変調技法、位相変調技法、およびそれらの組み合わせなどの、データ変調技法を定義することもできる。物理レイヤ２０２およびＭＡＣ２０４はまた、例えば時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡ、および／またはＣＤＭＡのあらゆる組み合わせのような多重化技法も定義しうる。１つの例では、物理レイヤ２０２およびメディアアクセス制御レイヤ２０４は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ８０２．１１−２００７および８０２．１１ｎ−２００９ｘ）規格によって定義されうる。他の例では、物理レイヤ２０２およびメディアアクセス制御レイヤ２０４は、ワイヤレスＨＤ、ワイヤレスホームデジタルインターフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢのうちのいずれかによって定義されうる。
【００４２】
インターネットプロトコル（ＩＰ）２０６、ユーザデータグラムプロトコル（ＵＤＰ）２０８、リアルタイムプロトコル（ＲＴＰ）２１０、送信制御プロトコル（ＴＣＰ）２２２、リアルタイムストリーミングプロトコル（ＲＴＳＰ）２２４は、ＷＤシステムにおいて使用されるパケット構造およびカプセル化を定義し、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって維持されている規格にしたがって定義されうる。
【００４３】
ＲＴＳＰ２２４は、能力をネゴシエートし、セッションを確立し、およびセッション維持と管理をするために、ソースデバイス１２０およびシンクデバイス１６０によって使用されうる。ソースデバイス１２０およびシンクデバイス１６０は、ＵＩＢＣ上のフィードバック入力カテゴリおよびフィードバックチャネルをサポートするためにソースデバイス１２０およびシンクデバイス１６０の能力をネゴシエートするように、ＲＴＳＰメッセージトランザクションを使用してフィードバックチャネルを確立しうる。フィードバックチャネルを確立するためのＲＴＳＰネゴシエーションの使用は、メディア共有セッションおよび／またはＵＩＢＣを確立するためのＲＴＳＰネゴシエーションプロセスを使用することに類似しうる。
【００４４】
例えば、ソースデバイス１２０は、シンクデバイス１６０に、ソースデバイス１２０にとって興味深い能力のリストを指定する能力要求メッセージ（例えば、ＲＴＳＰ  ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送しうる。本開示にしたがって、能力要求メッセージは、ＵＩＢＣ上でフィードバックチャネルをサポートするための能力を含むことができる。シンクデバイス１６０は、ソースデバイス１２０に、フィードバックチャネルをサポートする能力を表す能力応答メッセージ（例えば、ＲＴＳＰ  ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答しうる。例として、能力応答メッセージは、シンクデバイス１６０がＵＩＢＣ上でフィードバックチャネルをサポートする場合、「はい」を示しうる。ソースデバイス１２０はその後、シンクデバイス１６０に、フィードバックチャネルがメディア共有セッション中に使用されることになることを示す肯定応答要求メッセージ（例えば、ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送しうる。シンクデバイス１６０は、ソースデバイス１２０に、フィードバックチャネルがメディア共有セッション中に使用されることになることを肯定応答する肯定応答要求メッセージ（例えば、ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ）に応答しうる。
【００４５】
ビデオコデック２１８は、ＷＤシステムによって使用されうるビデオデータコード化技法を定義しうる。ビデオコデック２１８は、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４、ＶＰ８、および高効率ビデオコーディング（ＨＥＶＣ）のような、ビデオ圧縮規格のあらゆる数をインプリメントしうる。いくつかの事例では、ＷＤシステムがビデオデータを圧縮または非圧縮のどちらかをしうることは留意されるべきである。
【００４６】
音声コデック２２０は、ＷＤシステムによって使用されうる音声データコード化技法を定義しうる。音声データは、Ｄｏｌｂｙおよびデジタルシアターシステムによって発展されたもののようなマルチチャネルフォーマットを使用してコード化されうる。音声データは、圧縮または非圧縮されたフォーマットを使用してコード化されうる。圧縮された音声フォーマットの例は、ＭＰＥＧ−１、２音声レイヤＩＩおよびＩＩＩ、ＡＣ−３、ＡＡＣを含む。非圧縮された音声フォーマットの例は、パルス符号変調（ＰＣＭ）音声フォーマットを含む。
【００４７】
パケット化エレメントリストリーム（ＰＥＳ）パケット化２１６およびＭＰＥＧ２トランスポートストリーム（ＭＰＥＧ２−ＴＳ）２１２は、どのようにコード化された音声およびビデオデータがパケット化および送信されるかを定義しうる。パケット化エレメントリストリーム（ＰＥＳ）パケット化２１６およびＭＰＥＧ−ＴＳ２１２は、ＭＰＥＧ−２パート１にしたがって定義されうる。他の例では、音声およびビデオデータは、他のパケット化およびトランスポートストリームプロトコルにしたがってパケット化および送信されうる。コンテンツ保護２１４は、音声またはビデオデータの認可されていないコピーに対する保護を提供しうる。１つの例では、コンテンツ保護２１４は、高帯域幅デジタルコンテンツ保護２．０仕様にしたがって定義されうる。
【００４８】
フィードバックパケット化２２８は、どのようにユーザ入力および性能情報がパケット化されるのかを定義しうる。図３は、ソースデバイスに関してシンクデバイスから入力または性能情報をシグナリングするために使用されるフィードバックパケット３００の例を例示する概略図である。フィードバックパケット３００は、データパケットヘッダ３０２およびペイロードデータ３０４を含む。フィードバックパケット３００は、ＷＦＤによって定義されるＵＩＢＣ逆チャネルアーキテクチャを介してシンクデバイス１６０からソースデバイス１２０に送信されうる。この方法で、フィードバックチャネルは、シンクデバイス１６０とソースデバイス１２０との間でインプリメントされるＵＩＢＣ逆チャネルアーキテクチャ上でピギーバックされうる。ＵＩＢＣ上でピギーバックするために、「フィードバック」と呼ばれる新たな入力カテゴリが、ＵＩＢＣパケットのペイロードデータが性能情報フィードバックを含むことを示すようにＷＦＤにおいて定義されるＵＩＢＣデータパケットヘッダで利用されうる。フィードバックパケット３００のデータパケットヘッダ３０２のコンテンツに基づいて、ソースデバイス１２０がシンクデバイス１２０からペイロードデータ３０４を解析することができる。ペイロードデータ３０４に基づいて、ソースデバイス１２０は、ソースデバイス１２０からシンクデバイス１６０に送信されているメディアデータを変えることができる。
【００４９】
データパケットヘッダ３０２の例が図３において例示されている。数０−１５はデータパケット３０２内のビット位置を識別し、数０、１６、および３２は、データパケットヘッダ３０２における別個のフィールド間のビットオフセットを識別する。データパケットヘッダ３０２は、バージョンフィールド、タイムスタンプフラグ（「Ｔ」）、保留されたフィールド、フィードバックカテゴリフィールド、長さフィールド、およびオプションのタイムスタンプフィールドを含む。図３の例において、バージョンフィールドは、シンクデバイスによってインプリメントされる特定の通信プロトコルのバージョンを示すことができる３ビットフィールドである。バージョンフィールドにおける値は、どのようにペイロードデータ３０４を解析するかと同様に、どのようにデータパケットヘッダ３０２のリマインダを解析するか、をソースデバイスに知らせることができる。タイムスタンプフラグは、オプションのタイムスタンプフィールドがデータパケットヘッダ３０２に存在するか否かを示す１ビットフィールドである。タイムスタンプフラグは、例えば、タイムスタンプフィールドが存在することを示すために「１」を含むことができ、タイムスタンプフィールドが存在しないことを示すために「０」を含むことができる。リザーブされたフィールドは、バージョンフィールドにおいて識別される特定のプロトコルの将来のバージョンによる使用のために保留される８ビットフィールドである。
【００５０】
図３の例において、フィードバックカテゴリフィールドは、フィードバックパケット３００に含まれるペイロードデータ３０４のための入力カテゴリまたは性能情報カテゴリを識別するための４ビットフィールドである。フィードバックカテゴリフィールドの値は、ペイロードデータ３０４に含まれるデータのタイプ、およびどのようにペイロードデータ３０４がフォーマット化されるかをソースデバイスに識別する。このフォーマット化に基づいて、ソースデバイスはどのようにペイロードデータ３０４を解析するかを決定する。１つの例として、フィードバックカテゴリフィールドは、ペイロードデータ３０４がソースデバイスおよびシンクデバイスの両方によって実施されているプロトコルで定義される包括的情報要素を使用してフォーマット化されることを示すための包括的入力カテゴリを識別することができる。別の例として、フィードバックカテゴリフィールドは、ペイロードデータ３０４が、入力データがシンクデバイスにおいて受信されるユーザインターフェースのタイプに基づいてフォーマット化されることを示すためのヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）入力カテゴリを識別することができる。別の例として、フィードバックカテゴリフィールドは、ペイロードデータ３０４が、ソースデバイスまたはシンクデバイスのどちらかによって使用されるタイプ動作システム（ＯＳ）に基づいてフォーマット化されることを示すためのＯＳ特有入力カテゴリを識別することができる。本開示の技法にしたがって、フィードバックカテゴリフィールドはまた、ペイロードデータ３０４がシンクデバイスで決定される性能情報のタイプに基づいてフォーマット化されることを示すためのフィードバック入力カテゴリを識別することもできる。フィードバック入力カテゴリは、包括的ユーザ入力およびＨＩＤＣユーザ入力からフィードバックパケットにおけるペイロードデータを区別する。包括的またはＨＩＤＣユーザ入力のケースでは、シンクデバイスに伝送される後のメディアデータへのユーザ入力の作用は通常、どのようにメディアデータがシンクデバイスにおいてユーザに表示されるか、例えばズームおよびパンの動作、に関する。フィードバックユーザ入力のケースでは、シンクデバイス１６０に伝送される後のメディアデータへのユーザ入力の作用は通常、どのようにソースデバイス１２０がメディアデータを符号化し、シンクデバイス１６０にメディアデータを送信するかに関する。
【００５１】
タイムスタンプフィールドは、存在するときはソースデバイスによって生成され、シンクデバイスに送信されるメディアデータに関連付けられたタイムスタンプを含むことができる、オプションの１６ビットフィールドを備えることができる。例えば、ソースデバイス１２０は、シンクデバイス１６０にメディアデータパケットを送信する前にメディアデータパケットにタイムスタンプを適用している。存在するときはデータパケットヘッダ３０２におけるタイムスタンプフィールドは、シンクデバイス１６０がソースデバイスにフィードバックパケット３００を送信する前にシンクデバイス１６０において受信される最新のメディアデータパケットを識別するタイムスタンプを含むことができる。他の例では、タイムスタンプフィールドは、シンクデバイス１６０において受信される異なるメディアデータパケットを識別するタイムスタンプを含むことができる。タイムスタンプ値は、ソースデバイス１２０がどのメディアデータパケットがレポートされた性能の低下を経験したかを識別し、ＷＤシステムにおける往復遅延を計算することを可能にしうる。
【００５２】
長さフィールドは、フィードバックパケット３００の長さを示すために１６ビットフィールドを備えることができる。長さフィールドの値に基づいて、ソースデバイス１２０は、フィードバックパケットの終わり、および新たな、後のフィードバックパケットの始まりを識別することができる。図３において例示されているフィードバックパケット３００におけるフィールドの数およびサイズは単なる説明のためのものである。他の例では、フィードバックパケットは、図３において例示されているフィードバックパケット３００におけるものよりも大きいまたは小さいサイズを有するフィールドを含むことができ、ならびに／あるいは、図３において例示されているフィードバックパケット３００よりも多いまたは少ないフィールドを含むことができる。
【００５３】
図２に戻って参照すると、ＨＩＤＣのケースでは、包括的およびＯＳ特有ユーザ入力は通常、どのように後のメディアデータがシンクデバイス１６０においてユーザに表示されるか（例えば、ズームおよびパンの動作）、およびどのようにソースデバイス１２０がシンクデバイス１６０へのメディアデータを処理（例えば、符号化および／または送信）するかに影響を与える。
【００５４】
ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）２３０、包括的ユーザ入力２３２およびＯＳ特有ユーザ入力２３４は、どのようにユーザ入力のタイプが情報要素にフォーマット化されるかを定義することができる。上で記述されたように、これらの情報要素は、フィードバックパケット３００を使用してカプセル化されうる。例えば、ヒューマンインターフェースデバイスコマンド２３０および包括的ユーザ入力２３２がユーザインターフェースのタイプ（例えば、マウス、キーボード、タッチ、マルチタッチ、ボイス、ジェスチャ、ベンダ特有インターフェースなど）、およびコマンド（例えば、ズーム、パンなど）に基づいて入力を分類し、どのようにユーザ入力が情報要素にフォーマット化されるべきかを決定することができる。
【００５５】
１つの例では、ヒューマンインターフェースデバイスコマンド２３０は、ユーザ入力データをフォーマット化し、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ、およびＺｉｇｂｅｅ（登録商標）のような定義されたユーザ入力デバイスの仕様に基づいてユーザ入力値を生成することができる。表１Ａ、１Ｂ、および１Ｃは、ＨＩＤＣ入力ボディフォーマット、ＨＩＤインターフェースタイプ、およびＨＩＤタイプ値の例を提供する。１つの例では、ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）２３０は、ＷＦＤにしたがって定義されうる。表１Ａでは、ＨＩＤインターフェースタイプフィールドがヒューマンインターフェースデバイス（ＨＩＤ）タイプを指定している。ＨＩＤインターフェースタイプの例は、表１Ｂで提供されている。ＨＩＤタイプフィールドは、ＨＩＤタイプを指定している。表１Ｃは、ＨＩＤタイプの例を提供している。長さフィールドは、オクテットでＨＩＤＣ値の長さを指定している。ＨＩＤＣは、Ｂｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅ、およびＵＳＢのような仕様で定義されうる入力データを含む。
【表１】
2015501579.tif 000003
【表２】
2015501579.tif 000004
【表３】
2015501579.tif 000005
【００５６】
１つの例では、包括的ユーザ入力２３２は、アプリケーションレベルで処理され、特有のユーザ入力デバイスから独立した情報要素としてフォーマット化されうる。包括的ユーザ入力２３２は、ＷＦＤ規格によって定義されうる。表２Ａおよび２Ｂは、包括的ユーザ入力のための情報要素および包括的入力ボディフォーマットの例を提供している。表２Ａにおいて、包括的ＩＥ  ＩＤフィールドは、包括的情報要素（ＩＥ）ＩＤタイプを指定する。包括的ＩＥ  ＩＤタイプの例は、表２Ｂで提供されている。長さフィールドは、オクテットで包括的ＩＥ  ＩＤ値の長さを指定している。記述フィールドは、ユーザ入力の詳細を指定している。簡潔さために、表２Ａの記述フィールドにおけるユーザ入力の詳細は説明されていないけれども、いくつかの例ではマウスタッチ／移動イベントのためのＸＹ座標値、ＡＳＣＩＩキーコードおよび制御キーコード、ズーム、スクロール、および回転値を含むことができる。１つの例では、ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）２３０および包括的ユーザ入力２３２は、ＷＦＤにしたがって定義されうる。
【表４】
2015501579.tif 000006
【表５】
2015501579.tif 000007
【００５７】
ＯＳ特有ユーザ入力２３４は、デバイスプラットフォーム依存である。ｉＯＳ、Ｗｉｎｄｏｗｓ  Ｍｏｂｉｌｅ、およびＡｎｄｒｏｉｄのような異なるデバイスプラットフォームでは、ユーザ入力のフォーマットが異なりうる。解釈されたユーザ入力として分類されたユーザ入力は、デバイスプラットフォーム独立でありうる。そのようなユーザ入力は、クリア動作を指示しうる共通のユーザ入力を記述するための規格化された形態で解釈される。ワイヤレスディスプレイシンクおよびワイヤレスディスプレイソースは、いずれのデバイスプラットフォームによっても指定されず、解釈されたユーザ入力カテゴリで規格化もされない共通のベンダ特有ユーザ入力インターフェースを有しうる。そのようなケースでは、ワイヤレスディスプレイソースは、ベンダライブラリによって指定されるフォーマットでユーザ入力を伝送することができる。ユーザ入力を転送することは、ワイヤレスディスプレイシンクから生じないメッセージを転送するために使用されうる。ワイヤレスディスプレイシンクがユーザ入力を転送するときに、第３のデバイスからそのようなメッセージを伝送し、その後、ワイヤレスディスプレイソースが正しいコンテクストでそれらのメッセージに応答することを予期することは可能である。
【００５８】
性能分析２３６は、性能情報を決定するための技法を定義し、どのようにメディア性能データが情報要素にフォーマット化されるかを定義することができる。性能情報は、シンクデバイス１６０で測定または計算されることのできるメディアデータ通信チャネルおよびＷＤシステムの性能インジケータを含むことができる。例えば、性能情報フィードバックは、往復遅延、遅延ジッタ、パケットロスレート、パケットエラーレート、エラー分布、受信信号強度指示（ＲＳＳＩ）のうちの１つまたは複数を含むことができる。別の例では、性能情報は、ビットレートを増加または減少させる要求、瞬時復号化リフレッシュフレームについての要求のような明示的な要求を含むことができる。
【００５９】
１つの例では、シンクデバイス１６０は、ソースデバイス１２０から受信されたメディアデータパケットに基づいて性能情報を決定することができる。例えば、シンクデバイス１６０は、連続的受信メディアデータパケット間の遅延ジッタ、アプリケーションレベルまたはメディアアクセス制御（ＭＡＣ）レベルのどちらかにおけるパケットロス、パケットロスに基づく時間におけるエラー分布、および時間におけるＲＳＳＩ分布を計算しうる。
【００６０】
別の例では、シンクデバイス１６０は、ソースデバイス１２０から受信されたメディアデータパケットの遅延ジッタを計算することができる。遅延ジッタは、パケット間の遅延時間におけるバリエーションを備える。到着時間の差異が遅延時間の差異を示すことができるようにパケットは一定の間隔で送信されるので、遅延ジッタは、パケット間到着時間に基づいて計算されうる。しかしながらこの計算は、パケット送信時間への変更がパケット間到着時間に著しく影響しないように、往復遅延がパケット送信時間よりも一層大きいネットワークを通じてパケットを送信するときのみ、正確でありうる。いくつかのケースでは、パケット送信時間は、送信されているパケットのサイズに基づいて、広く変化しうることは留意されるべきである。
【００６１】
ＷＤシステムがシングルリンクを通じてメディアデータパケットを送信する例では、パケット送信時間は、パケット送信時間への変更がパケット間到着時間に著しく影響を与えるように往復遅延と同じ大きさでありうる。したがって、従来の遅延ジッタ計算は、結果として、シングルリンクをわたったチャネル条件の不正確な測定をもたらしうる。本開示の技法にしたがうと、シンクデバイス１６０は、パケット間到着時間を測定し、その後、ソースデバイス１２０から受信されたパケットのサイズに基づいて標準化されたパケット間到着時間を計算することができる。シンクデバイス１６０は、その後、標準化されたパケット間到着時間に基づいて遅延ジッタを計算することができる。例として、シンクデバイス１６０は、以下の式を使用することができる。
【数１】
2015501579.tif 000008
【００６２】
式（１）では、Ｘ’は標準化されたパケット間到着時間を指しており、Ｘは測定されたパケット間到着時間を指しており、Ｔはパケット生成間隔を指しており、Ｆはパケット送信間隔を指しており、ならびにＬはパケットサイズを指している。
【００６３】
別の例では、シンクデバイス１６０はパケットロス、およびパケットロスに基づいた時間におけるエラー分布を計算することができ、ソースデバイス１２０に性能情報フィードバックとして時間におけるエラー分布を伝送する。１つの例では、シンクデバイス１６０は、シンクデバイス１１６０で受信されたメディアデータパケットのシーケンスにおけるパケットロスを計算することができる。例えば、シンクデバイス１６０は、受信されたメディアデータパケットと関連付けられたＲＴＰシーケンス番号に基づくアプリケーションレベル、またはＭＡＣレベルのどちらかで失ったパケットを検出することができる。シンクデバイス１６０は、アプリケーションレベルで検出されたパケットロスに基づいて時間における明示的なエラー分布を、または、ＭＡＣレベルで検出されたパケットロスに基づいて時間における暗黙的なエラー分布を計算することができる。
【００６４】
１つの例として、シンクデバイス１６０は、アプリケーションレベルで検出された失ったパケットのＲＳＰシーケンス番号に基づいて時間における明示的なエラー分布を計算することができる。このケースでは、シンクデバイス１６０は、受信されなかったＲＴＰシーケンス番号を伝送することによって時間における明示的なエラー分布をソースデバイス１２０に知らせることができる。しかしながら、時間における明示的なエラー分布は、紛失中のＲＴＰシーケンス番号を検出したとき、それは連結された、または分割されたパケットを考慮に入れることに失敗するために精度に欠けうる。フィードバックパケットにおける受信されたＲＴＰシーケンス番号に基づいて、ソースデバイス１２０は、どのメディアデータパケットが失ったかを正確に決定することができる。
【００６５】
別の例として、シンクデバイス１６０は、失ったパケットがＭＡＣレベルで検出されたときに基づいて時間における暗黙的なエラー分布を計算することができる。より具体的には、時間における暗黙的なエラー分布は、ＭＡＣレベルで検出されたパケットロスからフィードバックパケットが生成される時間へ経過した時間を使用しては表されることができる。代わりとして、時間における暗黙的なエラー分布は、所定の時間間隔の間にＭＡＣレベルで検出された失ったパケットの数を使用して表されることができる。シンクデバイス１６０は、ソースデバイス１２０に、タイムスタンプ値を有するパケットロスタイミング情報を伝送することによって、時間における暗黙的エラー分布をソースデバイスに知らせることができる。時間における暗黙的エラー分布は、ソースデバイス１２０に性能情報のより細かな精度を提供することができる。フィードバックパケットにおけるタイムスタンプ値および受信されたパケットロスタイミング情報に基づいて、ソースデバイス１２０は、どのメディアデータパケットが失われ、あるいはいくつかの障害を経験したかを推測することができる。受信された性能情報フィードバックに基づいて、ソースデバイス１２０は、どのメディアデータパケットが失ったか、および失ったパケットが全体のメディアシーケンスにどれほど重要であるかを決定することができる。失ったパケットが非常に重要である場合、例えばそれがビデオシーケンスのための基準またはＩフレームを含んでいる場合、ソースデバイス１２０は、失ったパケットを再送信することを決めることができる。他のケースでは、ソースデバイス１２０は、失ったメディアデータパケットの重要性およびエラー分布に基づいてシンクデバイスに送信される後のメディアデータパケットのためにそのメディアデータ符号化品質を調整することができる。
【００６６】
別の例では、シンクデバイス１２０は時間における受信信号強度指示（ＲＳＳＩ）分布を計算し、ソースデバイス１２０に性能情報フィードバックとして時間におけるＲＳＳＩ分布を送信することができる。ＲＳＳＩ測定値は、パケットが受信されるとき通信信号がどれほど強いかを示している。したがって、時間におけるＲＳＳＩ分布は、信号強度が低いときの指示、およびそのときのあらゆるパケットロスが干渉ではなく低信号強度に起因する可能性が高いことを提供する。シンクデバイス１６０は、ＲＳＳＩ測定が行われる時間に基づいて時間におけるＲＳＳＩ分布を計算することができる。より具体的には、時間におけるＲＳＳＩ分布は、ＲＳＳＩ測定からフィードバックパケットが生成される時間へ経過した時間を使用して表されうる。このケースでは、シンクデバイス１６０は、フィードバックチャネルを介して、ソースデバイス１２０に、タイムスタンプ値を有する経過したタイミング情報を伝送することによって時間におけるＲＳＳＩ分布をソースデバイス１２０に知らせることができる。代わりとしてソースデバイス１２０は、前のＲＳＳＩ測定値または所定のしきい値に対してＲＳＳＩ測定値を比較することができる。シンクデバイス１６０はその後、ＲＳＳＩ測定値を、それが前のＲＳＳＩ測定値から変更する、またはタイムスタンプ値と共に、所定のしきい値を超えるときに、ソースデバイス１２０に知らせることができる。このケースでは、シンクデバイス１６０は、ソースデバイス１２０にＲＳＳＩ測定値を有する経過したタイミング情報を伝送する必要はない。どちらのケースでも、ソースデバイス１２０は、フィードバックチャネルを介してシンクデバイス１６０からＲＳＳＩ情報を受信することができる。受信された性能情報フィードバックに基づいて、ソースデバイス１２０は、前に送信されたメディアデータパケットのチャネルコンディションを決定することができる。チャネルコンディションが低いとき、ソースデバイス１２０は、タイムスタンプ値および／または経過したタイミング情報によって示された時間中のいずれのパケットロスも、干渉ではなく低信号強度に起因する可能性が高いことを推測することができる。したがって受信されたＲＳＳＩ測定値が低いとき、シンクデバイス１２０は、さらなる性能の低下を回避するためにそのメディアデータ符号化を調整し、より低い品質で後のメディアデータを符号化することができる。
【００６７】
性能情報として測定値を含むことに加えた、または代わりとした別の例では、性能情報は、ビットレートを増加または減少させる要求、または瞬時復号化リフレッシュフレームについての要求のような明示的な要求を含むことができる。図４は、シンクデバイスからソースデバイスへの性能情報フィードバックに基づいてメディアデータのビットレートを適合させる実例となる動作を例示するフローチャートである。図５に関係して以下で記述されるように、性能情報フィードバックのためのメッセージフォーマットは、フィードバック情報が音声チャネルについてかビデオチャネルについてかを示すことができる。性能フィードバック情報がビデオチャネルについてであるとき、メッセージフォーマットは、情報が、ビデオチャネルについてのパケットエラーレート（ＰＥＲ）を含むか、ビデオチャネルについてのＰＥＲに基づくソースデバイスにおける後のビデオデータの処理への変更を求める要求を含むかをさらに示すことができる。例えば、メッセージフォーマットは、ビデオデータのビットレートを増加させる、またはビットレートを減少させるように要求する符号化パラメータを示すことができる。このケースでは、フィードバック情報は、シンクデバイスで決定されたビットレートにおける変更のパーセントを含む。例示されたフローチャートは、シンクデバイス１６０からのフィードバック情報に基づいてソースデバイス１２０でビットレートを適合させる１つの例示的な動作を提供する。
【００６８】
説明の目的で、いくつかの変数および定数は特定の値で定義される。しかしながら変数および定数は他の例で異なる値を有することができる。例示された例では、ビットレート適合に関する変数および定数が、以下のように定義される。
【表６】
2015501579.tif 000009
【００６９】
ビットレートの増加または減少は、大抵約１秒内である次のＩＤＲフレームの始まりで生じることが想定される。本開示の技法にしたがうと、ＰＥＲは、シンクデバイス１６０で計算され、ソースデバイス１２０に送信する適切なフィードバックメッセージが生成されうる。例えば、ＰＥＲ＞１０％である場合、シンクデバイス１６０は、フィードバックメッセージにおいてＩＤＲフレームを要求することができる。ＰＥＲ＞３０％である場合、シンクデバイス１６０は、ＩＤＲフレームを送信することと共にビットレートを低減するように、３だけ量子化パラメータ（ＱＰ）を増加させるように、または元のレートの４分の１だけビットレートを低減するようにソースデバイス１２０に要求することができる。ＰＥＲ＞７０％である場合、シンクデバイス１６０は、ＩＤＲフレームを送信すること、およびビットレートが絶対的最小ビットレート（ＡＭＩＮ）に設定されることと共に、ビットレートを低減するようにソースデバイス１２０に要求することができる。ＰＥＲ＝０である場合、シンクデバイス１６０は、１０秒間ビットレートを増加させるようにソースデバイス１２０に要求することができる。ビットレートの増加または減少は、ビデオチャネルを通じてストリーミングされている、または再生されているコンテンツのタイプおよび現在のビットレートの関数でありうる。
【００７０】
記述されるビットレート適合動作は、本開示が開ループレート適合システムにおいて（つまりフィードバックなしで）、あるいは閉ループレート適合システムにおいて（つまり、フィードバックを用いて）のどちらかで使用されうる一般化された動作を備えることである。同じ動作が、適切なパラメータをモニタリングすることによって、ソースデバイス１２０、またはシンクデバイス１６０のどちらかにおいて、ビットレートにおける変更を決定するために使用されうる。例えば開ロープシステムでは、ソースデバイス１２０は、パラメータに基づいて適切なビットレートの変更を決定するために、送信レート、送信されたパケットおよびエラーパケットにおける統計、およびＲＳＳＩをモニタリングすることができる。閉ループシステムでは、本開示の技法にしたがって、シンクデバイス１６０はパラメータをモニタリングし、ならびにビットレートの変更を決定するためにソースデバイス１２０のための性能情報フィードバックとしてソースデバイス１２０にパラメータを返送するか、あるいはパラメータに基づいてビットレート変更を決定し、フィードバックとしてソースデバイス１２０にビットレート変化を求める要求を返送するかのどちらかを行うことができる。
【００７１】
シンクデバイス１６０からソースデバイス１２０に報告され返すエラーが存在しないとき、ソースデバイス１２０は、図４で例示された動作に基づいてビットレートを増加させることができる。代わりとして、図４で例示された動作は、ビットレート増加の量を決定するためにシンクデバイス１６０で適用され、シンクデバイス１６０はその後、フィードバックチャネルを通じてソースデバイス１２０にレート変化を報告し返すことができる。
【００７２】
図４で例示された例では、ステップ４０２で、現在のビットレート（ＢＲ）が絶対的最小ビットレート（ＡＭＩＮ）よりも大きく、第１のビットレートしきい値、１Ｍｂｐｓ以下である場合、ステップ４０４で、ソースデバイス１２０は、ソースデバイス１２０が１Ｍｂｐｓ（メガビット／秒）または１０秒、それらのどちらか早い方に到達するまで、２秒毎に５％のステップでエラーのない（ＰＥＲ＝０）ビットレートを増加させることができる。ステップ４０６で、１０秒がいずれのエラーもなく到達された場合、ビットレートはステップ４０８で直接１Ｍｂｐｓまで増加されうる
図４の例を継続すると、ステップ４１０で、現在のビットレート（ＢＲ）が１Ｍｂｐｓよりも大きく、第２のビットレートしきい値、２Ｍｂｐｓ以下である場合、ステップ４１２で、ソースデバイス１２０は、５秒毎に２０％のステップでビットレートを増加させることができる。ステップ４１２で、現在のビットレート（ＢＲ）が２Ｍｂｐｓよりも大きく、第３のビットレートしきい値、４Ｍｂｐｓよりも小さいまたは等しい場合、ステップ４１４で、ソースデバイス１２０は、５秒毎に１０％のステップでビットレートを増加させることができる。ステップ４１６で、現在のビットレート（ＢＲ）が４Ｍｂｐｓよりも大きい場合、ステップ４１８でソースデバイス１２０は、絶対的最大ビットレート（ＡＭＡＸ）が到達されるまで、１０秒毎に５％のステップでビットレートを増加させることができる。
【００７３】
図４で例示された例示的な動作で使用される１Ｍｂｐｓの値は、ワイヤレスディスプレイ動作のための３０フレーム／秒（ｆｐｓ）ビデオにおけるＷＶＧＡ（ワイドビデオグラフィックアレイ）に関する名目上品質レベルに対応する。レート変更は、ビデオフォーマットに依存して、低品質レベルと高品質レベルに対応する最小ビットレートと最大ビットレートの間で変動する。以下の表３は、様々なビデオフォーマットに関する最小ビットレート、名目上ビットレート、および最大ビットレートを記述している。表３における値は、ガイドラインとしてのみ提供されている。他の例は、追加のビデオフォーマットおよび／またはビデオフォーマットの各々に関連付けられた異なる最小、名目上、および最大ビットレートを含むことができる。図４で例示された動作は、簡略的な外挿を通じて他のビデオフォーマットおよび品質レベルに適合されうる。
【表７】
2015501579.tif 000010
【００７４】
概して、最小ビットレート、名目上のビットレート、最大ビットレート、ビットレートの増加、およびビットレートの増加の時間期間に関して上で提供された値は、図４で例示された例示的なビットレート適合動作に関して実例となる。他の例では、異なる値、またはここで使用される値におおよそ等しい値が、図４で例示されたものと同様のビットレート適合動作を行うために使用されうる。例えば、第１のビットレートしきい値、第２のビットレートしきい値、および第３のビットレートしきい値は、上向きに、または下向きに修正され、各しきい値に対応する各時間期間は増加または減少されうる。
【００７５】
図３は、ユーザ入力またはフィードバックメッセージのための実例となるメッセージフォーマットを例示する概略図である。ユーザ入力またはフィードバックメッセージは、いくつかの異なるシナリオで図３のフィードバックパケット３００のペイロードデータ３０４に含まれうる。例示されたメッセージフォーマット５００は、ユーザ入力またはフィードバックのどちらかについてのメッセージを伝送するように使用されうる。フィードバックメッセージは、音声および／またはビデオデータにおけるチャネルコンディションの影響についての情報を含むことができる。２バイトメッセージは、シンクデバイス１６０がソースデバイス１２０でメディアデータへのいくらかの修正を要求するとき、図５において例示されたメッセージフォーマットを使用して伝送されうる。例えば、シンクデバイス１６０は、どのようにメディアデータがシンクデバイス１６０でユーザに表されたか、例えば、ズームおよびパンの動作を修正するためにソースデバイス１２０にユーザ入力を伝送するようにメッセージフォーマットを使用することができる。本開示の技法にしたがって、シンクデバイス１６０は、どのようにソースデバイス１２０がメディアデータを符号化し、シンクデバイス１６０にそのメディアデータを送信するかを修正するためにソースデバイス１２０に性能情報フィードバックを伝送するようにメッセージフォーマットを使用することができる。
【００７６】
ユーザ入力またはフィードバックメッセージについての例示されたメッセージフォーマット５００は、ヘッダ（ＨＲＤ）フィールド５０２、メッセージタイプ（ＭＳＧタイプ）フィールド５０４、およびメッセージパラメータ（ＭＳＧパラメータ）フィールド５０６を含む。より具体的には、ＨＤＲフィールド５０２は、メッセージがソースデバイス１２０に関する変更情報を含むことを識別するためのメッセージに関する規格ヘッダを含む７ビットフィールドでありうる。ＭＳＧタイプフィールド５０４は、伝送されているメッセージのタイプを示す１ビットフィールドでありうる。例えば、０の値を有するＭＳＧタイプフィールド５０４は、メッセージがユーザ入力メッセージであることを示す。１の値を有するＭＳＧタイプフィールド５０４は、メッセージがフィードバックメッセージであることを示す。ＭＳＧパラメータフィールド５０６は、メッセージのパラメータを含む１６ビットフィールドでありうる。
【００７７】
ＭＳＧタイプフィールド５０４が、メッセージがユーザ入力メッセージであることを示すケースでは、ＭＳＧパラメータフィールド５０６におけるメッセージパラメータは、どのようにメディアデータがシンクデバイス１６０でユーザに表されるか、例えば、ズームおよびパンの動作を修正するようにソースデバイス１２０を要求するユーザ入力メッセージを含む。ＭＳＧタイプフィールド５０４が、メッセージがフィードバックメッセージであることを示すケースでは、ＭＳＧパラメータフィールド５０６におけるメッセージパラメータは、どのようにメディアデータが符号化され、シンクデバイス１６０に送信されるかを修正することをソースデバイス１２０に要求する音声またはビデオメッセージ５１０およびチャネルフィールド５０８を含む。
【００７８】
チャネルフィールド５０８は、第１に、フィードバック情報が音声チャネルについてであるか、ビデオチャネルについてであるかを示す。音声またはビデオメッセージフィールド５１０はその後、音声またはビデオチャネルのそれぞれについてのパケットエラーレート（ＰＥＲ）を指定することができる。シンクデバイス１６０は、さらに増加する値に対する代わりに同期ウィンドウ間隔で、音声または映像チャネルのどちらかについてのＰＥＲを計算することができる。同期ウィンドウは１秒であるように定義されうる。したがって、シンクデバイス１６０は、毎秒にＰＥＲを算出することができ、ソースデバイス１２０に伝送されるべきフィードバックメッセージを生成することができる。代わりとして、音声またはビデオメッセージフィールド５１０は、ビデオチャネルについてのＰＥＲに基づくソースデバイス１２０における後のビデオデータの処理への修正を要求することができる。例えば、シンクデバイス１６０は、シンクデバイス１６で計算されたビデオチャネルについてのＰＥＲに基づいてソースデバイス１２０から減少したビットレート、増加したビットレート、または瞬時復号化リフレッシュ（ＩＤＲ）フレームを要求するためにフィードバックメッセージを伝送することができる。
【００７９】
より具体的には、チャネルフィールド５０８は、フィードバック情報が音声チャネルについてであるか、ビデオチャネルについてであるかを示す１ビットフィールドを備えることができる。チャネルフィールド５０８が音声チャネルを示す０の値を有するとき、１５ビットの音声またはビデオメッセージ５１０は、音声チャネルについてのパケットの総数およびＰＥＲを伝送するように使用されることができる。１つの例では、音声チャネルは、パルス符号変調（ＰＣＭ）フォーマットでありうる。
【００８０】
チャネルフィールド５０８がビデオチャネルを示す１の値を有するとき、１５ビットの音声またはビデオメッセージ５１０は、ビデオパラメータフィールドおよびビデオメッセージを含むことができる。ビデオパラメータフィールドは、ビデオメッセージに含まれる情報のタイプを示す４ビットフィールドでありうる。ビデオメッセージは、ソースデバイス１２０が直接動作する符号化パラメータまたはビデオチャネルについてのＰＥＲのどちらかを伝送するために使用される１１ビットフィールドでありうる。以下の表４は、ビデオパラメータフィールドの異なる値に対するビデオメッセージに含まれるビデオメッセージタイプを提供している。
【表８】
2015501579.tif 000011
【００８１】
ビデオパラメータフィールドがビットレートを増加させるように（ＢＲ  ＩＮＣ）またはビットレートを減少させるように（ＢＲ  ＤＥＣ）要求する符号化パラメータを示すとき、ビットレートにおける変更のパーセントは決定され、その結果はビデオメッセージの保留の１１ビットを使用して伝送されうる。１つの例では、ビットレート適合は、図４に関係してより詳細に記述された技法を利用することができる。ビデオパラメータフィールドがＩＤＲフレームを要求する符号化パラメータを示すとき、ビデオメッセージの残りの１１ビットは、他の性能情報を伝送するために使用または無視されうる。加えて、ビデオパラメータフィールドがビデオチャネルについてのＰＥＲを示すとき、ビデオメッセージの残りの１１ビットは、ソースデバイス１２０にビデオチャネルについてのＰＥＲ情報を伝送するために使用されうる。
【００８２】
図６は、性能情報メッセージに基づいてメディアデータの送信を調整する技法をインプリメントしうるソースデバイスの例を例示するブロック図である。ソースデバイス６００は、図２で提供されたデータ通信モデルを組み込むＷＤシステムの一部でありうる。ソースデバイス６００は、トランスポート、記憶、および／またはディスプレイのためにメディアデータを符号化および／または復号するように構成されうる。ソースデバイス６００は、メモリ６０２、ディスプレイプロセッサ６０４、ローカルディスプレイ６０６、音声プロセッサ６０８、スピーカ６１０、ビデオ符号化器６１２、ビデオパケタイザ６１４、音声符号化器６１６、音声パケタイザ６１８、Ａ／Ｖマルチプレクサ（ｍｕｘ）６２０、トランスポートモジュール６２２、モデム６２４、制御モジュール６２６、フィードバックデパケタイザ６２８、およびフィードバックモジュール６３０を含む。ソースデバイス６００のコンポーネントは、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせのような、様々な適した回路のいずれかとしてインプリメントされうる。
【００８３】
メモリ６０２は、圧縮または非圧縮されたフォーマットでメディアデータの形態でＡ／Ｖ映像データを記憶することができる。メモリ６０２は、全体のメディアデータファイルを記憶する、あるいは例えば別のデバイスまたはソースからストリーミングされたメディアデータファイルの一部を単に記憶するより小さなバッファを備えることができる。メモリ６０２は、同期型動的ランダムアクセスメモリ（ＳＤＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電子的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、ＦＬＡＳＨメモリなどのようなランダムアクセスメモリ（ＲＡＭ）に限定されないけれども含む、幅広い種類の揮発性または非揮発性メモリのいずれかを備えることができる。メモリ６０２は、メディアデータを、他の種類のデータと同様に、記憶するためのコンピュータ可読記憶媒体を備えることができる。メモリ６０２は、追加で、本開示で記述されている様々な技法を行うことの一部としてプロセッサによって実施されるプログラムコードおよび命令を記憶することができる。
【００８４】
ディスプレイプロセッサ６０４は、キャプチャされたビデオフレームを取得し、ローカルディスプレイ６０６上でのディスプレイのためにビデオデータを処理することができる。ディスプレイ６０６は、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、またはソースデバイス６００のユーザにビデオデータを表すことができる別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスの１つを備える。
【００８５】
音声プロセッサ６０８は、音声キャプチャされた音声サンプルを取得し、スピーカ６１０への出力のためにオーディオデータを処理することができる。スピーカ６１０は、ヘッドフォン、シングルスピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。
【００８６】
ビデオ符号化器６１２は、メモリ６０２からビデオデータを取得し、所望のビデオフォーマットにビデオデータを符号化することができる。ビデオ符号化器６１２は、図２に関係して上で記述されたビデオコデック２１８の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。ビデオ符号化器６１２は、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４、ＶＰ８、および高効率ビデオコーディング（ＨＥＶＣ）のようなビデオ圧縮規格のあらゆる数にしたがってビデオを符号化することができる。いくつかのケースでは、ビデオ符号化器６１２は、ビデオデータがロスのない、またはロスの多い圧縮技法を使用して圧縮されるようにビデオを符号化することができることは留意されるべきである。
【００８７】
ビデオパケタイザ６１４は、符号化されたビデオデータをパケット化することができる。１つの例では、ビデオパケタイザ６１４は、ＭＰＥＧ―２パート１にしたがって定義されるような符号化されたビデオデータをパケット化することができる。他の例では、ビデオデータは、他のパケット化プロトコルにしたがってパケット化されうる。ビデオパケタイザ６１４は、図２に関係して上で記述されたパケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。
【００８８】
音声符号化器６１６は、メモリ６０２から音声データを取得し、所望の音声フォーマットに音声データを符号化することができる。音声符号化器６１６は、図２に関係して上で記述された音声コデック２２０の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。音声データは、Ｄｏｌｂｙおよびデジタルシアターシステムによって発展されたもののようなマルチチャネルフォーマットを使用してコード化されうる。音声データは、圧縮または非圧縮されたフォーマットを使用してコード化されうる。圧縮された音声フォーマットの例は、ＭＰＥＧ−１、２音声レイヤＩＩおよびＩＩＩ、ＡＣ−３、ＡＡＣを含む。非圧縮された音声フォーマットの例は、パルス符号変調（ＰＣＭ）音声フォーマットを含む。
【００８９】
音声パケタイザ６１８は、符号化された音声データをパケット化することができる。１つの例では、音声パケタイザ６１８は、ＭＰＥＧ−２パート１にしたがって定義されたような符号化された音声データをパケット化することができる。他の例では、音声データは、他のパケット化プロトコルにしたがってパケット化されうる。音声パケタイザ６１８は、図２に関係して上で記述されたパケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。
【００９０】
Ａ／Ｖマルチプレクサ６２０は、共有データストリームの一部としてビデオペイロードデータおよび音声ペイロードデータを結合するために多重化技法を適用することができる。１つの例では、Ａ／Ｖマルチプレクサ６２０は、ＭＰＥＧ−２パート１にしたがって定義されるＭＰＥＧ２トランスポートストリームとしてパケット化されたエレメンタリビデオおよび音声ストリームをカプセル化することができる。Ａ／Ｖマルチプレクサ６２０は、エラー訂正技法と同様に音声およびビデオパケットのための同期を提供することができる。
【００９１】
トランスポートモジュール６２２は、シンクデバイスへのトランスポートのためにメディアデータを処理することができる。さらにトランスポートモジュール６２２は、シンクデバイスから受信されたパケットを、それらがさらに処理されうるように処理することができる。例えば、トランスポートモジュール６２２は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＳＴＰを使用して通信するように構成されうる。例えば、トランスポートモジュール６２２はさらに、シンクデバイスへの、あるいはネットワークをわたった通信のためにＭＰＥＧ２−ＴＳをカプセル化することができる。
【００９２】
モデム６２４は、ＷＤシステムで利用される物理およびＭＡＣレイヤにしたがって物理およびＭＡＣレイヤ処理を行うように構成されうる。図２を参照して記述される。物理およびＭＡＣレイヤは、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定、およびチャネルアクセス制御を定義することができる。１つの例では、モデム６２４は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ  ８０２．１１ｘ）規格によって定義される物理およびＭＡＣレイヤのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。他の例では、モデム６２４は、ワイヤレスＨＤ、ＷｉＭｅｄｉａ、ワイヤレスホームデジタルインターフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢ、のいずれかのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。
【００９３】
制御モジュール６２６は、ソースデバイス６００通信制御機能を行うように構成されうる。通信制御機能は、シンクデバイスと能力をネゴシエートすることと、シンクデバイスとのセッションを確立することと、ならびにセッション維持と管理をすることに関連しうる。制御モジュール６２６は、シンクデバイスと通信するためにＲＴＳＰを使用することができる。さらに、制御モジュール６２６は、ＵＩＢＣ上のフィードバック入力カテゴリおよびフィードバックチャネルをサポートするためにソースデバイス６００およびシンクデバイスの能力をネゴシエートするように、ＲＴＳＰメッセージトランザクションを使用してフィードバックチャネルを確立しうる。フィードバックチャネルを確立するためのＲＴＳＰネゴシエーションの使用は、メディア共有セッションおよび／またはＵＩＢＣを確立するためにＲＴＳＰネゴシエーションプロセスを使用することに類似しうる。
【００９４】
フィードバックデパケタイザ６２８は、フィードバックパケットからのヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）、包括的ユーザ入力、ＯＳ特有ユーザ入力、および性能情報を解析することができる。１つの例では、フィードバックパケットは、図３に関係して記述されたメッセージフォーマットを使用することができる。この例では、フィードバックデパケタイザ６２８は、どのようにフィードバックパケットヘッダにおけるフィードバックカテゴリフィールドの値に部分的に基づいてフィードバックパケットを解析するかを決定することができる。１つの例として、フィードバックカテゴリフィールドは、フィードバックパケットペイロードデータが包括的情報要素を使用してフォーマット化されることを示すために包括的入力カテゴリを識別することができる。別の例として、フィードバックカテゴリフィールドは、ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）入力カテゴリを識別することができる。別の例として、フィードバックカテゴリフィールドは、ペイロードデータが、ソースデバイスまたはシンクデバイスのどちらかによって使用されるタイプ動作システム（ＯＳ）に基づいてフォーマット化されることを示すためのＯＳ特有入力カテゴリを識別することができる。
【００９５】
別の例では、フィードバックデパケタイザ６２８は、どのようにフィードバックパケットのペイロードデータに部分的に基づいてフィードバックパケットを解析するかを決定することができる。１つの例では、フィードバックパケットは、図３に関係して記述されたメッセージフォーマットを使用することができ、フィードバックメッセージペイロードは、図５における例にしたがってフォーマット化されうる。
【００９６】
フィードバックモジュール６３０は、ソースデバイス６００が性能情報メッセージに基づいてメディアデータの送信を調整することができるように、フィードバックデパケタイザからの性能情報を受信し、性能情報を処理する。上で記述されたように、メディアデータの送信は、以下の技法のあらゆる組み合わせによって調整されうる；符号化量子化パラメータが調整されうる、メディアデータの品質が調整されうる、メディアパケットの長さが調整されうる、瞬時復号化リフレッシュフレームが送信されうる、符号化または送信ビットレートが調整されうる、および余剰情報がメディアデータパケットロスの可能性に基づいて送信されうる。
【００９７】
図７は、ソースデバイスにおける、例えば音声ビデオ（ＡＶ）データなどのメディアデータの処理を調整するためにソースデバイスに性能情報フィードバックを伝送するための技法をインプリメントするシンクデバイスの例を例示しているブロック図である。シンクデバイス７００は、図２で提供されたデータ通信モデルを組み込むＷＤシステムの一部でありうる。１つの例では、シンクデバイス７００は、ソースデバイス６００と共にＷＤシステムを形成することができる。シンクデバイス７００は、モデム７０２、トランスポートモジュール７０４、Ａ／Ｖデマルチプレクサ（ｄｅｍｕｘ）７０６、ビデオデパケタイザ７０８、ビデオ復号器７１０、ディスプレイプロセッサ７１２、ディスプレイ７１４、音声デパケタイザ７１６、音声復号器７１８、音声プロセッサ７２０、スピーカ７２２、ユーザ入力モジュール７２４、性能分析モジュール７２６、フィードバックパケタイザ７２８、および制御モジュール７３０を含む。シンクデバイス７００のコンポーネントは各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせのような、様々な適した回路のいずれかとしてインプリメントされうる。
【００９８】
モデム７０２は、ＷＤシステムで利用される物理およびＭＡＣレイヤにしたがって物理およびＭＡＣレイヤ処理を行うように構成されうる。図２を参照して記述される。物理およびＭＡＣレイヤは、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定、およびチャネルアクセス制御を定義することができる。１つの例では、モデム７０２は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ  ８０２．１１ｘ）規格によって定義された物理およびＭＡＣレイヤのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。他の例では、モデム７０２は、ワイヤレスＨＤ、ＷｉＭｅｄｉａ、ワイヤレスホームデジタルインターフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢ、のいずれかのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。
【００９９】
トランスポートモジュール７０４は、ソースデバイスから受信されたメディアデータを処理することができる。さらにトランスポートモジュール７０４は、ソースデバイスへのトランスポートのためにフィードバックパケットを処理することができる。例えば、トランスポートモジュール７０４は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＳＴＰを使用して通信するように構成されうる。加えて、トランスポート７０４は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＳＴＰパケットのあらゆる組み合わせにおけるタイムスタンプ値を含むことができる。タイムスタンプ値は、ソースデバイスがどのメディアデータパケットがレポートされた性能の低下を経験したかを識別し、ＷＤシステムにおける往復遅延を計算することを可能にしうる。
【０１００】
Ａ／Ｖデマルチプレクサ７０６は、データストリームからビデオペイロードデータおよび音声ペイロードデータを区別するための逆多重化技法を適用することができる。１つの例では、Ａ／Ｖデマルチプレクサ７０６は、ＭＰＥＧ−２パート１にしたがって定義されるＭＰＥＧ２トランスポートストリームのパケット化されたエレメンタリビデオおよび音声ストリームを区別することができる。
【０１０１】
ビデオデパケタイザ７０８およびビデオ復号器７１０は、ここで記述されるパケット化およびコード化技法をインプリメントするビデオパケタイザおよびビデオ符号化器の相互処理を行い、ディスプレイ７１２にビデオ出力ビデオデータを出力することができる。
【０１０２】
ディスプレイプロセッサ７１２は、キャプチャされたビデオフレームを取得し、ディスプレイ７１４上でのディスプレイのためにビデオデータを処理することができる。ディスプレイ７１４は、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイのような、様々なディスプレイデバイスの１つを備えることができる。
【０１０３】
音声デパケタイザ７１６および音声復号器７１８は、ここで記述されているパケット化およびコード化技法をインプリメントする音声パケタイザおよび音声符号化器の相互処理を行い、ディスプレイプロセッサ７２０に音声データを出力することができる。
【０１０４】
音声プロセッサ７２０は、音声復号器から音声データを取得し、スピーカ７２２への出力のために音声データを処理することができる。スピーカ７２２は、ヘッドフォン、シングルスピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。
【０１０５】
ユーザ入力デバイス７２４は、例えば、キーボード、マウス、トラックボールまたはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、またはあらゆる他のそのようなユーザ入力デバイスのようなユーザ入力デバイスによって受信されたユーザ入力コマンドをフォーマット化することができる。１つの例では、ユーザ入力モジュール７２４は、図２に関係して上で記述されたヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）２３０、包括的ユーザ入力２３２、およびＯＳ特有ユーザ入力２３４にしたがって定義されるユーザ入力コマンドをフォーマット化することができる。
【０１０６】
性能分析モジュール７２６は、ソースデバイスから受信されたメディアデータパケットに基づいて性能情報を決定することができる。性能情報は、遅延ジッタ、パケットロス、時間におけるエラー分布、パケットエラーレート、および時間におけるＲＳＳＩ分布を、ここに記述されている他の例と同様に含むことができる。性能分析モジュール７２６は、ここに記述されている技法のいずれかにしたがって性能情報を計算することができる。
【０１０７】
フィードバックパケタイザ７２８は、フィードバックパケットを作り出すために、ユーザ入力モジュール７２４および性能分析モジュール生成器７２６からユーザ入力情報を処理することができる。１つの例では、フィードバックパケットは、図３に関係して記述されたメッセージフォーマットを使用することができる。加えて、フィードバックパケタイザ７２８は、フィードバックパケットの各々におけるタイプスタンプ値を含むことができる。タイムスタンプ値は、ソースデバイスがどのメディアデータパケットがレポートされた性能の低下を経験したかを識別し、ＷＤシステムにおける往復遅延を計算することを可能にしうる。
【０１０８】
制御モジュール７３０は、シンクデバイス７００通信制御機能を行うように構成されうる。通信制御機能は、ソースデバイスと能力をネゴシエートすることと、ソースデバイスとのセッションを確立することと、ならびにセッション維持と管理をすることに関連しうる。制御モジュール７３０は、ソースデバイスと通信するためにＲＴＳＰを使用することができる。さらに、制御モジュール７３０は、ＵＩＢＣ上のフィードバック入力カテゴリおよびフィードバックチャネルをサポートするためにシンクデバイス７００およびソースデバイスの能力をネゴシエートするように、ＲＴＳＰメッセージトランザクションを使用してフィードバックチャネルを確立しうる。フィードバックチャネルを確立するためのＲＴＳＰネゴシエーションの使用は、メディア共有セッションおよび／またはＵＩＢＣを確立するためのＲＴＳＰネゴシエーションプロセスを使用することに類似しうる。
【０１０９】
図８はフィードバック情報に基づいてメディアデータの送信を調整するための技法を例示するフローチャートである。ソースデバイスはメディアデータをシンクデバイスに送信する。ソースデバイスおよびシンクデバイスは、ここに記述されているソースおよびシンクデバイスのあらゆる組み合わせでありうる（８０２）。１つの例では、メディアデータはＵＤＰにしたがって送信されうる。ソースデバイスは、シンクデバイスからフィードバックメッセージを受信する（８０４）。フィードバックメッセージは、ここで記述されているあらゆるメッセージフォーマットにしたがってフォーマット化され、ここに記述されているあらゆるタイプのフィードバック情報を含むことができる。例えば、フィードバックメッセージは、図３に関係して記述されたメッセージフォーマットにしたがってフォーマット化されうる。１つの例では、受信されたフィードバックメッセージがＴＣＦにしたがって送信されうる。ソースデバイスは、ここに記述されている技法のいずれかにしたがってフィードバックメッセージに基づいてメディアデータの送信を調整することができる（８０６）。例えば、メディアデータの送信は、以下の技法のあらゆる組み合わせによって調整されうる、符号化量子化パラメータが調整されうる、メディアパケットの長さが調整されうる、瞬時復号化リフレッシュフレームが送信されうる、符号化または送信ビットレートが調整されうる、および余剰情報がメディアデータパケットロスの可能性に基づいて送信されうる。
【０１１０】
図９は、フィードバック情報を提供するための技法を例示するフローチャートである。シンクデバイスは、ソースデバイスからメディアデータを受信する（９０２）。ソースデバイスおよびシンクデバイスは、ここに記述されているソースおよびシンクデバイスのあらゆる組み合わせでありうる。１つの例では、メディアデータはＵＤＰにしたがって送信されうる。シンクデバイスは、ソースに送信されるべきメッセージが性能情報を含むかどうかを示す（９０４）。１つの例では、シンクデバイスは、メッセージがデータパケットヘッダ値を使用して性能情報を含むことを示すことができる。例えば、シンクデバイスは、図３におけるフィードバックカテゴリフィールド、および／または図５におけるＭＳＧタイプフィールドを使用してメッセージのコンテンツを指定することができる。シンクデバイスは、ソースデバイスにフィードバックメッセージを送信する（９０６）。フィードバックメッセージは、ここに記述されているあらゆるメッセージフォーマットにしたがってフォーマット化され、ここに記述されているあらゆるタイプのフィードバック情報を含むことができる。１つの例では、フィードバックメッセージがＴＣＦにしたがって送信されうる。
【０１１１】
１つまたは複数の例では、記述されている機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらのあらゆる組み合わせでインプリメントされうる。ソフトウェアでインプリメントされる場合、機能は、コンピュータ可読媒体上で１つまたは複数の命令またはコードとして格納または送信されうる。コンピュータ可読媒体は、１つの場所から別の場所へのコンピュータプログラムの移送を容易にするあらゆる媒体を含むコンピュータデータ記憶媒体または通信媒体を含みうる。いくつかの例では、コンピュータ可読媒体は、非トランジトリなコンピュータ可読媒体を備えうる。データ記憶媒体は、本開示において記述された技法のインプリメンテーションのための命令、コード、および／またはデータ構造を読み取るために、１つまたは複数のコンピュータ、あるいは１つまたは複数のプロセッサによってアクセスされることができるあらゆる利用可能な媒体でありうる。
【０１１２】
限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、フラッシュメモリ、あるいは、データ構造または命令の形態で所望のプログラムコードを記憶または搬送するために使用されることができ、かつコンピュータによってアクセスされうるあらゆる他の媒体のような、非トランジトリな媒体を備えることができる。また、いずれの接続手段もコンピュータ可読媒体と適切に名づけられる。ディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、ここで使用される場合、コンパクトディスク（ｄｉｓｃ）（ＣＤ）、レーザーディスク（登録商標）（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、およびブルーレイディスク（ｄｉｓｃ）を含み、ディスク（ｄｉｓｋ）は通常、磁気的にデータを再生するが、ディスク（ｄｉｓｃ）は、レーザーを用いて光学的にデータを再生する。上記の組み合わせは、また、コンピュータ可読媒体の範囲内に含まれるべきである。
【０１１３】
コードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または、他の同等な集積またはディスクリートな論理回路、のような１つまたは複数のプロセッサによって実施されうる。したがって、ここで使用されるような「プロセッサ」という用語は、前述の構造、またはここに記述されている技法のインプリメンテーションに適したあらゆる他の構造のいずれかを称しうる。加えて、いくつかの態様では、ここで記述された機能は、符号化および復号化のために構成された専用ハードウェアモジュールおよび／またはソフトウェアモジュール内で提供されうる、または、結合されたコデックに組み込まれうる。また、技法は、１つまたは複数の回路または論理要素において十分にインプリメントされることができる。
【０１１４】
本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置においてインプリメントされうる。様々なコンポーネント、モジュール、またはユニットは、開示された技法を行うように構成されたデバイスの機能的な態様を強調するために本開示で記述されているけれども、必ずしも異なるハードウェアユニットによる実現を要求しない。むしろ、上で記述されたように、様々なユニットはコデックハードウェアユニットで結合されうる、あるいは、適したソフトウェアおよび／またはファームウェアと関連して、上で記述された１つまたは複数のプロセッサを含む、情報を交換するハードウェアユニットの集合によって提供されうる。
【０１１５】
本発明の様々な実施形態が記述されてきた。これらおよび他の実施形態は、特許請求の範囲の範囲内にある。
【図１】
2015501579.tif 000012
【図２】
2015501579.tif 000013
【図３】
2015501579.tif 000014
【図４】
2015501579.tif 000015
【図５】
2015501579.tif 000016
【図６】
2015501579.tif 000017
【図７】
2015501579.tif 000018
【図８】
2015501579.tif 000019
【図９】
2015501579.tif 000020
【国際調査報告】
2015501579.tif 000021
2015501579.tif 000022
2015501579.tif 000023
2015501579.tif 000024