JP2015511787A - ワイヤレスディスプレイシステム内のシンクデバイスにおけるカスタマイズされた再生 - Google Patents

Abstract

本開示は、ワイヤレスディスプレイ（ＷＤ）システム内のユーザ体験を改善する技法を記載する。ＷＤシステムは、１つまたは複数のシンクデバイスにメディアデータを供給するソースデバイスを含む。本技法は、シンクデバイスでのビデオの再生品質を改善しながら、ＷＤシステム内のエンドツーエンドの待ち時間を低減することに関する。より具体的には、本技法は、ソースデバイスから受信されたメディアデータのタイプに基づいて、シンクデバイスでカスタマイズされた再生を行うことを含む。メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイスの処理パイプラインは、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングするように構成される。メディアデータがビデオデータとオーディオデータの両方を含む場合、オーディオレンダリング開始タイマは削減され、処理パイプラインは削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングする。

Description

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

[0002]本開示は、ワイヤレスソースデバイスとワイヤレスシンク（sink、受信）デバイスとの間でデータを送信することに関する。

[0003]ワイヤレスディスプレイ（ＷＤ）システムは、ソースデバイスと１つまたは複数のシンクデバイスとを含む。ソースデバイス、およびシンクデバイスの各々は、モバイルデバイス、またはワイヤレス通信機能を有する有線デバイスのいずれかであり得る。たとえば、モバイルデバイスとして、ソースデバイスおよびシンクデバイスのうちの１つまたは複数は、モバイル電話、タブレットコンピュータ、ラップトップコンピュータ、ワイヤレス通信カード付きポータブルコンピュータ、携帯情報端末（ＰＤＡ）、ワイヤレスゲームデバイス、ポータブルメディアプレーヤ、またはワイヤレス通信機能を有する他のフラッシュメモリデバイスを備える場合がある。モバイルデバイスはまた、いわゆる「スマート」フォンおよび「スマート」パッドもしくはタブレット、または他のタイプのワイヤレス通信デバイスを含む場合がある。有線デバイスとして、たとえば、ソースデバイスおよびシンクデバイスのうちの１つまたは複数は、ワイヤレス通信機能を含むテレビジョン、デスクトップコンピュータ、モニタ、プロジェクタなどを備えることができる。

[0004]ソースデバイスは、特定の通信セッションに参加しているシンクデバイスのうちの１つまたは複数に、オーディオおよび／またはビデオデータなどのメディアデータを送る。メディアデータは、ソースデバイスのローカルディスプレイとシンクデバイスのディスプレイの各々の両方で再生することができる。より具体的には、参加しているシンクデバイスの各々は、受信されたメディアデータをそのディスプレイおよびオーディオ機器にレンダリングする。場合によっては、シンクデバイスのユーザは、タッチ入力および遠隔制御入力などのユーザ入力をシンクデバイスに加えることができる。ＷＤシステムでは、ユーザ入力はシンクデバイスからソースデバイスに送られる。ソースデバイスは、シンクデバイスから受信されたユーザ入力を処理し、シンクデバイスに送られる以後のメディアデータにユーザ入力の効果を加える。

[0005]一般に、本開示は、ワイヤレスディスプレイ（ＷＤ）システム内のユーザ体験を改善する技法を記載する。ＷＤシステムは、メディアデータ、たとえば、オーディオデータおよび／またはビデオデータを再生用の１つまたは複数のシンクデバイスに供給するソースデバイスを含む。本技法は、シンクデバイスでのビデオの再生品質（すなわち、滑らかさ）を改善しながら、ソースデバイスとシンクデバイスとの間のメディアデータのエンドツーエンドの待ち時間を削減することに関する。

[0006]より具体的には、本開示の技法は、ソースデバイスから受信されたメディアデータのタイプに基づいて、ＷＤシステムのシンクデバイスでカスタマイズされた再生を行うことを含む。メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイスの処理パイプラインに含まれるレンダラは、ビデオデータの加速されたレンダリングを実行するように構成される。たとえば、メディアデータがオーディオデータを含まないことを検出すると、本技法は、シンクデバイスの処理パイプラインに含まれるレンダラでの同期を無効にすることと、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングすることとを含む。別の例として、メディアデータがビデオデータとオーディオデータの両方を含むことを検出すると、本技法は、オーディオレンダリング開始タイマを削減することと、削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることとを含む。加えて、本技法は、セットアップ時間に起因する待ち時間を削減するために、通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信するより前に、シンクデバイス内の処理パイプラインを構成することを含む。

[0007]一例では、本開示は、ＷＤシステムにおいてソースデバイスとシンクデバイスで通信セッションを確立することと、シンクデバイスを用いてソースデバイスからメディアデータを受信することと、ここにおいて、メディアデータは少なくともビデオデータを含む、シンクデバイスの処理パイプラインを用いて受信されたメディアデータを復号することと、復号されたメディアデータがオーディオデータを含むかどうかを検出することと、復号されたメディアデータがオーディオデータを含まないとき、シンクデバイスの処理パイプラインを用いてビデオデータの加速されたレンダリングを実行することとを備える方法に関する。

[0008]別の例では、本開示は、ＷＤシステムにおいてソースデバイスとシンクデバイスで通信セッションを確立することと、ソースデバイスから少なくともビデオデータを含むメディアデータを受信することであって、ここにおいて、メディアデータが少なくともビデオデータを含む、受信することと、受信されたメディアデータを復号することと、受信されたメディアデータがオーディオデータを含むかどうかを検出することと、受信されたメディアデータがオーディオデータを含まないとき、ビデオデータの加速されたレンダリングを実行することとを行うように構成された１つまたは複数の処理ユニットを含む処理パイプラインと、シンクデバイスの処理パイプラインを管理するように構成されたパイプラインマネージャとを備えるシンクデバイスに関する。

[0009]さらなる一例では、本開示は、ＷＤシステムにおいてソースデバイスとシンクデバイスで通信セッションを確立するための手段と、ソースデバイスからメディアデータを受信するための手段と、ここにおいて、メディアデータが少なくともビデオデータを含む、シンクデバイスの処理パイプラインを用いて受信されたメディアデータを復号するための手段と、受信されたメディアデータがオーディオデータを含むかどうかを検出するための手段と、受信されたメディアデータがオーディオデータを含まないとき、シンクデバイスの処理パイプラインを用いてビデオデータの加速されたレンダリングを実行するための手段とを備えるシンクデバイスに関する。

[0010]別の例では、本開示は、シンクデバイス内で実行されたとき、ＷＤシステムにおいてソースデバイスとシンクデバイスで通信セッションを確立することと、ソースデバイスからメディアデータを受信することと、ここにおいて、メディアデータは少なくともビデオデータを含む、シンクデバイスの処理パイプラインを用いて受信されたメディアデータを復号することと、受信されたメディアデータがオーディオデータを含むかどうかを検出することと、受信されたメディアデータがオーディオデータを含まないとき、シンクデバイスの処理パイプラインを用いてビデオデータの加速されたレンダリングを実行することとをプログラマブルプロセッサに行わせる命令を備えるコンピュータ可読媒体に関する。

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

[0012]本開示の技法をサポートして、ビデオの再生品質を改善しながらソースデバイスとシンクデバイスとの間のエンドツーエンドの待ち時間を削減することが可能なソースデバイスとシンクデバイスとを含むワイヤレスディスプレイ（ＷＤ）システムの例を示すブロック図。 [0013]本開示の技法を実装できるＷＤシステム内のソースデバイスの例を示すブロック図。 [0014]本開示の技法を実装できるＷＤシステム内のシンクデバイスの例を示すブロック図。 [0015]本開示の技法を実装できる送信機システムと受信機システムとを示すブロック図。 [0016]本開示の技法をサポートして、ソースデバイスの処理パイプライン内の待ち時間を削減することが可能なソースデバイスの例を示すブロック図。 [0017]本開示の技法をサポートして、シンクデバイスの処理パイプライン内の待ち時間を削減し、シンクデバイスでのビデオ再生を改善することが可能なシンクデバイスの例を示すブロック図。 [0018]シンクデバイスで取得されたユーザ入力データおよび／またはフィードバックデータをソースデバイスに配信するために使用され得る例示的なデータパケットを示す概念図。 [0019]処理パイプライン内のメディアデータの低遅延のフレーム取込みとバッファリングとをサポートすることが可能なソースデバイスの例示的な動作を示すフローチャート。 [0020]処理パイプライン内のカスタマイズされたビデオ再生をサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャート。 [0021]処理パイプライン内のメディアデータのアプリケーション認識に基づいて、カスタマイズされたバッファリングをサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャート。 [0022]ＷＤシステム内のオーディオデータの優先トランスポートをサポートすることが可能なソースデバイスおよびシンクデバイスの例示的な動作を示すフローチャート。

[0023]本開示では、ワイヤレスディスプレイ（ＷＤ）システム内のユーザ体験を改善する技法が記載される。ＷＤシステムは、メディアデータ、たとえば、オーディオデータおよび／またはビデオデータを再生用の１つまたは複数のシンクデバイスに供給するソースデバイスを含む。本技法は、シンクデバイスでのビデオの再生品質（すなわち、滑らかさ）を改善しながら、ソースデバイスとシンクデバイスとの間のメディアデータのエンドツーエンドの待ち時間を削減することに関する。

[0024]一例では、本技法は、ＷＤシステムのソースデバイスでの低遅延の画面取込みとバッファリングとを含む。たとえば、ＷＤシステム内で通信セッションを確立すると、パイプラインマネージャは、待ち時間を削減するために処理ステップ間で最小サイズのバッファを含むように、ソースデバイスの処理パイプラインを構成することができる。次いで、ソースデバイスは、メディアデータの少なくとも直近のフレーム更新を最小サイズのバッファにバッファリングし、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除する。加えて、処理パイプラインは、ソースデバイスのパイプライン処理を用いた処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。ハードウェア加速の使用は、フレームレートを増大させ、待ち時間を削減させるためのソースデバイスの中央処理装置（ＣＰＵ）上の処理負荷を低減することができる。ソースデバイスはまた、シンクデバイスによる時宜を得た受信を保証して、ＷＤシステム内の待ち時間をさらに削減するために、符号化されたフレーム更新を再送信する（すなわち、重複プッシュを実行する）ことができる。

[0025]別の例では、本技法は、ソースデバイスから受信されたメディアデータのタイプに基づく、ＷＤシステムのシンクデバイスでのカスタマイズされた再生を含む。メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイスの処理パイプラインに含まれるレンダラは、ビデオデータの加速されたレンダリングを実行するように構成される。たとえば、メディアデータがオーディオデータを含まないことを検出すると、パイプラインマネージャは、シンクデバイスの処理パイプラインに含まれるレンダラでの同期を無効にして、存在しないオーディオデータとの同期を待たずに、レンダラがビデオデータをレンダリングすることを可能にすることができる。別の例として、メディアデータがビデオデータとオーディオデータの両方を含むことを検出すると、パイプラインマネージャは、オーディオレンダリング開始タイマを削減することができ、その結果、レンダラは削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。加えて、パイプラインマネージャは、セットアップ時間に起因する待ち時間を削減するために、通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に、シンクデバイス内の処理パイプラインを構成することができる。

[0026]さらなる一例では、本技法は、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づく、ＷＤシステムのシンクデバイスでのカスタマイズされたバッファリングを含む。シンクデバイスは、メディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャは、シンクデバイスの処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現する。場合によっては、メディアデータ用のアプリケーションのタイプは、ソースデバイスで検出され得、シンクデバイスは、ソースデバイスから受信された情報に基づいて、アプリケーションのタイプを知ることができる。他の場合、シンクデバイスは、アプリケーションのタイプ自体を検出することによって、メディアデータ用のアプリケーションのタイプを知ることができる。たとえば、メディアデータが、再生の品質または滑らかさがシンクデバイスで最も優先度が高く、上述された低遅延技法は目に見えるジッタをもたらす場合がある、ビデオ再生アプリケーション用であるとき、バッファサイズは増大されて、ビデオ再生アプリケーション用内のメディアデータの滑らかさを増大させる。反対に、メディアデータが、低遅延がシンクデバイスで最も優先度が高い、ユーザインターフェース（ＵＩ）アプリケーションまたはゲームアプリケーション用であるとき、バッファサイズは減少されて、ＵＩアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。

[0027]本技法はまた、ＷＤシステム内のソースデバイスとシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャは、ソースデバイス内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。加えて、ソースデバイスでのワイヤレスモデムソケットは、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。さらなるバッファリングにより、ソースデバイスで削除されるオーディオパケットがより少なくなることが保証される。より高い優先度のトランスポートキューにより、ビデオパイプライン経路内の遅延または失速（stall）を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイスでトランスポート用にキューイングされることが保証される。加えて、シンクデバイスは、ソースデバイスに通信チャネルのトランスポート状態を記述するフィードバック情報を供給することができ、パイプラインマネージャは、フィードバック情報に基づいてソースデバイスの処理パイプラインを修正することができる。

[0028]図１は、本開示の技法をサポートして、ビデオの再生品質を改善しながらソースデバイス１２０とシンクデバイス１６０との間のエンドツーエンドの待ち時間を削減することが可能なソースデバイス１２０とシンクデバイス１６０とを含むワイヤレスディスプレイ（ＷＤ）システム１００の例を示すブロック図である。図１に示されるように、ＷＤシステム１００は、通信チャネル１５０を介してシンクデバイス１６０と通信するソースデバイス１２０を含む。

[0029]ソースデバイス１２０は、オーディオおよび／またはビデオ（Ａ／Ｖ）メディアデータ１２１を記憶するメモリと、ディスプレイ１２２と、スピーカ１２３と、（エンコーダ１２４とも呼ばれる）オーディオおよび／またはビデオ（Ａ／Ｖ）エンコーダ１２４と、オーディオおよび／またはビデオ（Ａ／Ｖ）制御モジュール１２５と、送信機／受信機（ＴＸ／ＲＸ）ユニット１２６とを含むことができる。シンクデバイス１６０は、ディスプレイ１６２と、スピーカ１６３と、（デコーダ１６４とも呼ばれる）オーディオおよび／またはビデオ（Ａ／Ｖ）デコーダ１６４と、送信機／受信機ユニット１６６と、ユーザ入力（ＵＩ）デバイス１６７と、ユーザ入力処理モジュール（ＵＩＰＭ）１６８とを含むことができる。図示された構成要素は、ＷＤシステム１００の１つの例示的な構成をなすにすぎない。他の構成は、図示された構成要素よりも少ない構成要素を含む場合があるか、または図示された構成要素以外のさらなる構成要素を含む場合がある。

[0030]図１の例では、ソースデバイス１２０は、Ａ／Ｖメディアデータ１２１のビデオ部分をディスプレイ１２２に表示することができ、Ａ／Ｖメディアデータ１２１のオーディオ部分をスピーカ１２３に出力することができる。Ａ／Ｖメディアデータ１２１は、ソースデバイス１２０にローカルに記憶されるか、ファイルサーバ、ハードドライブ、外部メモリ、ブルーレイ（登録商標）ディスク、ＤＶＤ、もしくは他の物理記憶媒体などの外部記憶媒体からアクセスされるか、またはインターネットなどのネットワーク接続を介してソースデバイス１２０にストリーミングすることができる。場合によっては、Ａ／Ｖメディアデータ１２１は、ソースデバイス１２０のカメラとマイクロフォンとを介して、リアルタイムにキャプチャすることができる。Ａ／Ｖメディアデータ１２１は、映画、テレビ番組、または音楽などのマルチメディアコンテンツを含むことができるが、ソースデバイス１２０によって生成されたリアルタイムコンテンツも含むことができる。そのようなリアルタイムコンテンツは、たとえば、ソースデバイス１２０で動作しているアプリケーションによって生成されるか、または、たとえば、ビデオテレフォニーセッションの一部としてキャプチャされたビデオデータであり得る。場合によっては、そのようなリアルタイムコンテンツは、ユーザが選択する場合に利用可能なユーザ入力オプションのビデオフレームを含むことができる。場合によっては、Ａ／Ｖメディアデータ１２１は、ビデオのフレーム上にオーバーレイされたユーザ入力オプションを有する映画またはＴＶ番組のビデオフレームなどの、異なるタイプのコンテンツの組合せであるビデオフレームを含むことができる。

[0031]ディスプレイ１２２とスピーカ１２３とを介してローカルにＡ／Ｖメディアデータ１２１をレンダリングすることに加えて、ソースデバイス１２０のＡ／Ｖエンコーダ１２４は、Ａ／Ｖメディアデータ１２１を符号化することができ、送信機／受信機ユニット１２６は、通信チャネル１５０を介してシンクデバイス１６０に符号化されたデータを送信することができる。シンクデバイス１６０の送信機／受信機ユニット１６６は、符号化されたデータを受信し、Ａ／Ｖデコーダ１６４は、符号化されたデータを復号し、ディスプレイ１６２とスピーカ１６３とを介して復号されたデータを出力する。このようにして、ディスプレイ１２２およびスピーカ１２３によってレンダリングされているオーディオおよびビデオデータは、同時にディスプレイ１６２およびスピーカ１６３によってレンダリングすることができる。オーディオデータおよびビデオデータはフレームに構成することができ、オーディオフレームは、レンダリングされるときにビデオフレームと時刻同期することができる。

[0032]Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、代替的にＭＰＥＧ−４，Ｐａｒｔ １０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格、または新興の高効率ビデオコーディング（ＨＥＶＣ）規格などの任意の数のオーディオおよびビデオ圧縮規格を実装することができる。多くの他のタイプのプロプライエタリな、または規格化された圧縮技法も使用することができる。概して、Ａ／Ｖデコーダ１６４は、Ａ／Ｖエンコーダ１２４の逆のコーディング演算を実行するように構成される。図１には示されないが、いくつかの態様では、Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、各々オーディオのエンコーダおよびデコーダと統合することができ、共通のデータストリームまたは別々のデータストリーム内のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアとソフトウェアとを含むことができる。

[0033]Ａ／Ｖエンコーダ１２４は、上述のようなビデオ圧縮規格を実装することに加えて、他の符号化機能も実行することができる。たとえば、Ａ／Ｖエンコーダ１２４は、Ａ／Ｖデータメディア１２１がシンクデバイス１６０に送信されるより前に、Ａ／Ｖメディアデータ１２１に様々なタイプのメタデータを追加することができる。場合によっては、Ａ／Ｖメディアデータ１２１は、符号化された形態でソースデバイス１２０に記憶されるかまたはソースデバイス１２０で受信され、したがってＡ／Ｖエンコーダ１２４によるさらなる圧縮を必要としない場合がある。

[0034]図１は、オーディオペイロードデータとビデオペイロードデータとを別々に搬送する通信チャネル１５０を示すが、場合によっては、ビデオペイロードデータとオーディオペイロードデータは共通のデータストリームの一部であり得ることを理解されたい。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、各々１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せとして実装することができる。Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ、それらのいずれかは、複合エンコーダ／デコーダ（コーデック）の一部として統合することができる。したがって、ソースデバイス１２０およびシンクデバイス１６０の各々は、本開示の技法のうちの１つまたは複数を実行するように構成された専用の機械を備えることができる。

[0035]ディスプレイ１２２およびディスプレイ１６２は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなどの様々なビデオ出力デバイスのうちのいずれも備えることができる。これらまたは他の例では、ディスプレイ１２２および１６２は、各々発光型ディスプレイまたは透過型ディスプレイであり得る。ディスプレイ１２２およびディスプレイ１６２はまた、それらが同時に入力デバイスとディスプレイデバイスの両方であるようなタッチディスプレイであり得る。そのようなタッチディスプレイは、ユーザがそれぞれのデバイスにユーザ入力を与えることを可能にする、静電容量式、抵抗式、または他のタイプのタッチパネルであり得る。

[0036]スピーカ１２３は、ヘッドフォン、シングルスピーカシステム、マルチスピーカシステム、またはサラウンドサウンドシステムなどの様々なオーディオ出力デバイスのうちのいずれも備えることができる。加えて、ディスプレイ１２２およびスピーカ１２３はソースデバイス１２０の一部として示され、ディスプレイ１６２およびスピーカ１６３はシンクデバイス１６０の一部として示されているが、ソースデバイス１２０およびシンクデバイス１６０は、実際はそれらのデバイスのシステムであり得る。一例として、ディスプレイ１６２はテレビジョンであり得るし、スピーカ１６３はサラウンドサウンドシステムであり得るし、デコーダ１６４は有線またはワイヤレスのいずれかでディスプレイ１６２とスピーカ１６３とに接続された外部ボックスの一部であり得る。他の例では、シンクデバイス１６０は、タブレットコンピュータまたはスマートフォンなどの単一デバイスであり得る。さらに他の場合では、ソースデバイス１２０およびシンクデバイス１６０は、同様のデバイス、たとえば両方ともスマートフォン、タブレットコンピュータなどである。この場合、一方のデバイスがソースとして動作することができ、他方がシンクとして動作することができる。これらの役割は、以後の通信セッションでは反転される場合さえある。さらに他の場合、ソースデバイスは、スマートフォン、ラップトップコンピュータまたはタブレットコンピュータなどのモバイルデバイスを備えることができ、シンクデバイスは、（たとえば、ＡＣ電源コードを有する）より固定されたデバイスを備えることができ、その場合、ソースデバイスは、シンクデバイスを介して大群衆に提示用のオーディオおよびビデオデータを配信することができる。

[0037]送信機／受信機ユニット１２６および送信機／受信機ユニット１６６は、各々様々なミキサ、フィルタ、増幅器、および信号変調用に設計された他の構成要素、ならびに、１つまたは複数のアンテナ、およびデータを送受信するために設計された他の構成要素を含むことができる。通信チャネル１５０は、概して、ソースデバイス１２０からシンクデバイス１６０にビデオデータを送信するのに適した任意の通信媒体、または様々な通信媒体の集合を表す。通信チャネル１５０は、通常、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などと同様の比較的短距離の通信チャネルである。しかしながら、通信チャネル１５０は、この点において必ずしも限定されるとは限らず、無線周波数（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路などの任意のワイヤレスまたは有線の通信媒体、あるいはワイヤレス媒体と有線媒体との任意の組合せを備えることができる。他の例では、通信チャネル１５０は、有線もしくはワイヤレスのローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成する場合さえある。加えて、通信チャネル１５０は、ピアツーピアリンクを作成するために、ソースデバイス１２０およびシンクデバイス１６０によって使用することができる。

[0038]ソースデバイス１２０およびシンクデバイス１６０は、たとえば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを使用して、能力ネゴシエーションに従って通信セッションを確立することができる。次いで、ソースデバイス１２０およびシンクデバイス１６０は、ＩＥＥＥ８０２．１１規格ファミリーからの規格などの通信プロトコルを使用して、通信チャネル１５０を介して通信することができる。ソースデバイス１２０およびシンクデバイス１６０は、たとえば、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（ＷＦＤ）規格に従って通信することができ、その結果、ソースデバイス１２０およびシンクデバイス１６０は、ワイヤレスアクセスポイントまたはいわゆるホットスポットなどの仲介者を使用せずに互いと直接通信する。ソースデバイス１２０およびシンクデバイス１６０はまた、Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ（ＴＤＬＳ）を確立して、ネットワーク輻輳を回避または低減することができる。ＷＦＤおよびＴＤＬＳは、比較的短距離の通信セッションをセットアップすることを目的とする。この文脈では、比較的短距離は、たとえば、約７０メートル未満を指す場合があるが、雑音の多いまたは遮るもののある環境では、デバイス間の距離は、約３５メートル未満、または約２０メートル未満など、さらに短い場合がある。

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

[0040]ソースデバイス１２０から受信されたデータを復号しレンダリングすることに加えて、シンクデバイス１６０は、ユーザ入力デバイス１６７からユーザ入力を受信することもできる。ユーザ入力デバイス１６７は、たとえば、キーボード、マウス、トラックボールもしくはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、または任意の他のそのようなユーザ入力デバイスであり得る。ＵＩＰＭ１６８は、ユーザ入力デバイス１６７によって受信されたユーザ入力コマンドを、ソースデバイス１２０が解釈することが可能なデータパケット構造にフォーマットする。そのようなデータパケットは、送信機／受信機１６６により、通信チャネル１５０を介してソースデバイス１２０に送信される。送信機／受信機ユニット１２６はデータパケットを受信し、Ａ／Ｖ制御モジュール１２５はデータパケットを解析して、ユーザ入力デバイス１６７によって受信されたユーザ入力コマンドを解釈する。データパケット内で受信されたコマンドに基づいて、Ａ／Ｖ制御モジュール１２５は、符号化され送信されているコンテンツを変更することができる。このようにして、シンクデバイス１６０のユーザは、リモートで、かつソースデバイス１２０と直接対話することなしに、ソースデバイス１２０によって送信されているオーディオペイロードデータとビデオペイロードデータとを制御することができる。

[0041]加えて、シンクデバイス１６０のユーザは、ソースデバイス１２０上のアプリケーションを起動し、制御することが可能である場合がある。たとえば、シンクデバイス１６０のユーザは、ソースデバイス１２０に記憶された写真編集アプリケーションを起動し、そのアプリケーションを使用して、ソースデバイス１２０にローカルに記憶された写真を編集することが可能である場合がある。シンクデバイス１６０は、その写真が実際はソースデバイス１２０上で編集されているが、その写真がシンクデバイス１６０上でローカルに編集されているように見え感じる、ユーザエクスペリエンスをユーザにもたらすことができる。そのような構成を使用して、デバイスユーザは、いくつかのデバイスとともに使用するために１つのデバイスの能力を活用することが可能である場合がある。たとえば、ソースデバイス１２０は、大量のメモリとハイエンド処理能力とを有するスマートフォンを備え得る。しかしながら、映画を見るとき、ユーザは、より大きいディスプレイスクリーンを有するデバイス上で映画を見ることを望む場合があり、その場合、シンクデバイス１６０は、タブレットコンピュータまたはさらに大きいディスプレイデバイスもしくはテレビジョンであり得る。電子メールを送ることまたは電子メールに応答することを行いたいとき、ユーザは、物理キーボードを有するデバイスを使用することを望む場合があり、その場合、シンクデバイス１６０はラップトップであり得る。どちらの場合でも、ユーザはシンクデバイスと対話していても、処理の大半は依然としてソースデバイス１２０によって実行することができる。ソースデバイスおよびシンクデバイスは、任意の所与のセッションにおいて、デバイスの能力をネゴシエーションおよび／または識別することにより、双方向対話を容易にすることができる。

[0042]いくつかの構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０のオペレーティングシステムによって実行されるオペレーティングシステムプロセスを備え得る。しかしながら、他の構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０上で動作しているアプリケーションのソフトウェアプロセスを備え得る。そのような構成では、ユーザ入力コマンドはソフトウェアプロセスによって解釈することができ、その結果、シンクデバイス１６０のユーザは、ソースデバイス１２０上で動作しているオペレーティングシステムとは対照的に、ソースデバイス１２０上で動作しているアプリケーションと直接対話している。オペレーティングシステムとは対照的にアプリケーションと直接対話することにより、シンクデバイス１６０のユーザは、ソースデバイス１２０のオペレーティングシステムに対してネイティブでないコマンドのライブラリにアクセスすることができる。加えて、アプリケーションと直接対話することにより、コマンドは、異なるプラットフォーム上で動作しているデバイスによってより容易に送信され、処理されることが可能になり得る。

[0043]シンクデバイス１６０で加えられたユーザ入力は、通信チャネル１５０を介してソースデバイス１２０に送り返すことができる。一例では、ユーザインターフェースバックチャネル（ＵＩＢＣ）とも呼ばれる逆方向チャネルアーキテクチャは、シンクデバイス１６０で加えられたユーザ入力を、シンクデバイス１６０がソースデバイス１２０に送信することを可能にするために実装することができる。逆方向チャネルアーキテクチャは、ユーザ入力をトランスポートするための上位レイヤメッセージと、シンクデバイス１６０およびソースデバイス１２０でユーザインターフェース能力をネゴシエーションするための下位レイヤフレームとを含むことができる。ＵＩＢＣは、シンクデバイス１６０とソースデバイス１２０との間のインターネットプロトコル（ＩＰ）トランスポートレイヤ上に常駐することができる。このようにして、ＵＩＢＣは、開放型システム間相互接続（ＯＳＩ）通信モデルにおいてトランスポートレイヤより上位であり得る。ユーザ入力データを含んでいるデータパケットの信頼できる送信と順次配信とを促進するために、ＵＩＢＣは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）またはユーザデータグラムプロトコル（ＵＤＰ）などの他のパケットベース通信プロトコルの上で動作するように構成することができる。ＵＤＰおよびＴＣＰは、ＯＳＩレイヤアーキテクチャにおいて並列に動作することができる。ＴＣＰ／ＩＰにより、シンクデバイス１６０およびソースデバイス１２０は、パケットロスの場合の再送信技法を実装することが可能になり得る。

[0044]ＵＩＢＣは、クロスプラットフォームユーザ入力データを含む、様々なタイプのユーザ入力データをトランスポートするように設計することができる。たとえば、ソースデバイス１２０は、ｉＯＳ（登録商標）オペレーティングシステムを実行することができ、一方シンクデバイス１６０は、Ａｎｄｒｏｉｄ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）などの別のオペレーティングシステムを実行する。プラットフォームにかかわらず、ＵＩＰＭ１６８は、受信されたユーザ入力を、Ａ／Ｖ制御モジュール１２５が理解できる形態にカプセル化することができる。ソースデバイスとシンクデバイスが異なるプラットフォーム上で動作するかどうかにかかわらず、多くの異なるタイプのソースデバイスおよびシンクデバイスがプロトコルを活用することが可能になるように、いくつかの異なるタイプのユーザ入力フォーマットをＵＩＢＣによってサポートすることができる。一般入力フォーマットを定義でき、プラットフォーム固有入力フォーマットを両方ともサポートでき、したがって、ユーザ入力がＵＩＢＣによってソースデバイス１２０とシンクデバイス１６０との間で通信できる方式でフレキシビリティが与えられる。

[0045]本開示の技法は、ＷＤシステム１００内のユーザ体験を改善することができる。ＷＤシステム１００のユーザ向けの典型的な使用事例には、ソースデバイス１２０上で動作するユーザインターフェースアプリケーションを、逆ヒューマンインターフェースデバイス（ＨＩＤ）フィードバックでシンクデバイス１６０のより大きいディスプレイ画面に表示すること、ソースデバイス１２０上で動作するゲームアプリケーションをシンクデバイス１６０で表示すること、およびソースデバイス１２０上で動作するビデオ再生アプリケーションをシンクデバイス１６０で表示することが含まれる。これらの使用事例の各々について、ソースデバイス１２０は、全フレームバッファのコンテンツとフレーム更新エンドツーエンドとを、シンクデバイス１６０のユーザへの表示用にシンクデバイス１６０に送信することができる。ソースデバイス１２０の送信機／受信機１２６は、リアルタイムトランスポートプロトコル（ＲＴＰ）／ユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）を使用して、ソースデバイス１６０の送信機／受信機１６６に符号化されたビデオフレームをトランスポートすることができる。

[0046]ＷＤシステム１００が高精細度マルチメディアインターフェース（ＨＤＭＩ（登録商標））または他のタイプのディスプレイケーブルと同様のユーザ体験を提供するために、ＷＤシステム１００は、約８０ミリ秒（ｍｓ）未満のエンドツーエンドの待ち時間を実現する必要がある。しかしながら、ビデオ再生アプリケーションの使用事例の場合、ＷＤシステム１００は、過剰なさらなる待ち時間をもたらさずに、シンクデバイス１６０でのビデオ再生で高い品質（すなわち、滑らかさ）も実現する必要がある。本開示は、改善されたユーザ体験のための上述された待ち時間および品質のニーズを実現するために、個々に、または組合せでＷＤシステム１００に適用され得るいくつかの技法を記載する。

[0047]本開示の技法によれば、処理パイプラインは、シンクデバイス１６０でのビデオの再生品質を改善しながら、ソースデバイス１２０とシンクデバイス１６０との間で送信されるＡ／Ｖメディアデータ１２１のエンドツーエンドの待ち時間を削減するように、ソースデバイス１２０とシンクデバイス１６０の両方で構成され得る。一例では、本技法は、ソースデバイス１２０での低遅延の画面取込みとバッファリングとを含む。たとえば、ＷＤシステム１００内で通信セッションを確立すると、パイプラインマネージャは、待ち時間を削減するために処理ステップ間でＡ／Ｖメディアデータ１２１の少なくとも直近のフレーム更新を保持することが可能な最小サイズのバッファを含むように、ソースデバイス１２０の処理パイプラインを構成することができる。加えて、ソースデバイス１２０の処理パイプラインは、パイプライン処理を用いた処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。

[0048]別の例では、本技法は、ソースデバイス１２０から受信されたＡ／Ｖメディアデータ１２１のタイプに基づく、シンクデバイス１６０でのカスタマイズされた再生を含む。Ａ／Ｖメディアデータ１２１がビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス１６０の処理パイプラインに含まれるレンダラは、ビデオデータの加速されたレンダリングを実行するように構成され得る。Ａ／Ｖメディアデータ１２１がビデオデータとオーディオデータの両方を含む場合、パイプラインマネージャは、オーディオレンダリング開始タイマを削減することができ、その結果、レンダラは削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。加えて、パイプラインマネージャは、セットアップ時間に起因する待ち時間を削減するために通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイス１２０からＡ／Ｖメディアデータ１２１を受信する前に、シンクデバイス１６０内の処理パイプラインを構成することができる。

[0049]さらなる一例では、本技法は、ソースデバイス１２０から受信されたＡ／Ｖメディアデータ１２１についてのアプリケーション認識に基づく、シンクデバイス１６０でのカスタマイズされたバッファリングを含む。シンクデバイス１６０は、Ａ／Ｖメディアデータ１２１用のアプリケーションのタイプを知り、パイプラインマネージャは、シンクデバイス１６０の処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現する。たとえば、Ａ／Ｖメディアデータ１２１がビデオ再生アプリケーション用であるとき、バッファサイズは増大されて、ビデオ再生アプリケーションについての滑らかさを増大させる。反対に、Ａ／Ｖメディアデータ１２がユーザインターフェース（ＵＩ）アプリケーションまたはゲームアプリケーション用であるとき、バッファサイズは減少されて、ＵＩアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。

[0050]本開示の技法はまた、ソースデバイス１２０とシンクデバイス１６０との間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャは、ソースデバイス１２０内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。加えて、ソースデバイス１２０でのワイヤレスモデムソケットは、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。加えて、シンクデバイス１６０は、ＵＩＢＣを介して通信チャネル１５０のトランスポート状態を記述するフィードバック情報をソースデバイス１２０に供給することができ、パイプラインマネージャは、フィードバック情報に基づいてソースデバイス１２０の処理パイプラインを修正することができる。

[0051]図１の例では、ソースデバイス１２０は、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Ｗｉ−Ｆｉ対応テレビジョン、またはオーディオデータおよびビデオデータを送信することが可能な任意の他のデバイスを備えることができる。シンクデバイス１６０は、同様に、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Ｗｉ−Ｆｉ対応テレビジョン、またはオーディオデータおよびビデオデータを受信し、ユーザ入力データを受信することが可能な任意の他のデバイスを備えることができる。場合によっては、シンクデバイス１６０は、ディスプレイ１６２、スピーカ１６３、ＵＩデバイス１６７、およびＡ／Ｖエンコーダ１６４が、別個であるが相互動作可能なデバイスのすべての部品であるような、デバイスのシステムを含むことができる。ソースデバイス１２０は、同様に、単一のデバイスではなく、デバイスのシステムであり得る。

[0052]本開示では、ソースデバイスという用語は、一般に、Ａ／Ｖデータを送信しているデバイスを指すために使用され、シンクデバイスという用語は、一般に、ソースデバイスからＡ／Ｖデータを受信しているデバイスを指すために使用される。多くの場合、ソースデバイス１２０とシンクデバイス１６０は、一方のデバイスがソースとして動作し、他方がシンクとして動作する、同様または同等のデバイスであり得る。その上、異なる通信セッションではこれらのロールが逆になる場合がある。したがって、１つの通信セッション内のシンクデバイスは、次の通信セッションではソースデバイスになる場合があり、その逆もあり得る。

[0053]いくつかの例では、ＷＤシステム１００は、シンクデバイス１６０に加えて１つまたは複数のシンクデバイスを含む場合がある。シンクデバイス１６０と同様に、追加のシンクデバイスは、ソースデバイス１２０からＡ／Ｖデータを受信し、かつ確立されたＵＩＢＣを介してソースデバイス１２０にユーザコマンドを送信することができる。いくつかの構成では、複数のシンクデバイスは互いに独立して動作することができ、ソースデバイス１２０でのＡ／Ｖデータ出力は、シンクデバイス１６０および追加のシンクデバイスのうちの１つまたは複数で同時に出力され得る。代替の構成では、シンクデバイス１６０は主要なシンクデバイスであり得、追加のシンクデバイスのうちの１つまたは複数は二次的なシンクデバイスであり得る。そのような例示的な構成では、シンクデバイス１６０および追加のシンクデバイスのうちの１つが結合される場合があり、シンクデバイス１６０はビデオデータを表示することができ、一方追加のシンクデバイスは対応するオーディオデータを出力する。加えて、いくつかの構成では、シンクデバイス１６０は送信されたビデオデータのみを出力することができ、一方追加のシンクデバイスは送信されたオーディオデータを出力する。

[0054]図２は、本開示の技法を実装できるＷＤシステム内のソースデバイス２２０の一例を示すブロック図である。ソースデバイス２２０は、図１内のソースデバイス１２０と同様のデバイスであり得るし、ソースデバイス１２０と同じ方式で動作することができる。ソースデバイス２２０は、ローカルディスプレイ２２２と、スピーカ２２３と、プロセッサ２３１と、ディスプレイプロセッサ２３５と、オーディオプロセッサ２３６と、メモリ２３２と、トランスポートユニット２３３と、ワイヤレスモデム２３４とを含む。図２で示されたように、ソースデバイス２２０は、トランスポート、記憶、および表示のためにＡ／Ｖメディアデータを符号化および／または復号する１つまたは複数のプロセッサ（すなわち、プロセッサ２３１、ディスプレイプロセッサ２３５およびオーディオプロセッサ２３６）を含むことができる。Ａ／Ｖメディアデータは、たとえばメモリ２３２で記憶することができる。メモリ２３２は、Ａ／Ｖファイル全体を記憶することができるか、または、たとえば別のデバイスもしくはソースからストリームされたＡ／Ｖファイルの一部分を記憶するだけのより小さいバッファを備えることができる。

[0055]トランスポートユニット２３３は、符号化されたＡ／Ｖメディアデータをネットワークトランスポート用に処理することができる。たとえば、符号化されたＡ／Ｖメディアデータはプロセッサ２３１によって処理され、ネットワークにわたる通信用のネットワークアクセスレイヤ（ＮＡＬ）ユニットに、トランスポートユニット２３３によってカプセル化することができる。ＮＡＬユニットは、ワイヤレスモデム２３４により、ネットワーク接続を介してワイヤレスシンクデバイスに送ることができる。ワイヤレスモデム２３４は、たとえば、ＩＥＥＥ８０２．１１規格ファミリーのうちの１つを実装するように構成されたＷｉ−Ｆｉモデムであり得る。ソースデバイス２２０はまた、Ａ／Ｖメディアデータをローカルに処理し表示することができる。特に、ディスプレイプロセッサ２３５は、ローカルディスプレイ２２２で表示されるようにビデオデータを処理することができ、オーディオプロセッサ２３６は、スピーカ２２３での出力用にオーディオデータを処理することができる。

[0056]図１のソースデバイス１２０に関して上述されたように、ソースデバイス２２０はまた、シンクデバイスからユーザ入力コマンドを受信することができる。たとえば、ソースデバイス２２０のワイヤレスモデム２３４は、ＮＡＬユニットなどのカプセル化されたユーザ入力データパケットを受信し、カプセル化されたデータユニットをカプセル化解除のためにトランスポートユニット２３３に送ることができる。トランスポートユニット２３３はＮＡＬユニットからユーザ入力データパケットを抽出することができ、プロセッサ２３１はデータパケットを解析して、ユーザ入力コマンドを抽出することができる。ユーザ入力コマンドに基づいて、プロセッサ２３１は、ソースデバイス２２０によるＡ／Ｖメディアデータの処理を修正する。他の例では、ソースデバイス２２０は、トランスポートユニット２３３からユーザ入力データパケットを受信し、データパケットを解析してユーザ入力コマンドを抽出し、ユーザ入力コマンドに基づいてソースデバイス２２０によるＡ／Ｖメディアデータの処理を修正するようにプロセッサ２３１に指示する、ユーザ入力ユニットまたはユーザ入力ドライバ（図２には示されず）を含むことができる。

[0057]図２のプロセッサ２３１は、一般に、限定はしないが、１つもしくは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、他の等価な集積回路もしくはディスクリート論理回路、またはそれらのいくつかの組合せを含む、多種多様なプロセッサのうちのいずれをも表す。図２のメモリ２３２は、限定はしないが、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュメモリなどを含む、多種多様な揮発性メモリまたは不揮発性メモリのいずれも備えることができる。メモリ２３２は、オーディオ／ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えることができる。加えて、メモリ２３２は、本開示に記載される様々な技法を実行することの一部として、プロセッサ２３１によって実行される命令とプログラムコードとを記憶することができる。

[0058]本開示の技法は、ＷＤシステム内のソースデバイス２２０および１つまたは複数のシンクデバイスでのユーザ体験を改善するために、待ち時間を削減するようにソースデバイス２２０の処理パイプラインを構成することを含む。ソースデバイス２２０の処理パイプラインは、プロセッサ２３１および／またはトランスポートユニット２３３によって実行される１つたは複数の処理ユニットを含む。本技法は、図５に示されるソースデバイス５２０の処理パイプラインに関して、さらに詳細に記載される。

[0059]一例では、ソースデバイス２２０の処理パイプラインは、低遅延の画面取込みとメディアデータのバッファリングとを提供するように修正され得る。より具体的には、ソースデバイス２２０の処理パイプラインは、待ち時間を削減するためにプロセッサ２３１内の処理ステップ間で最小サイズのバッファを含むように構成され得る。次いで、ソースデバイス２２０は、メディアデータの少なくとも直近のフレーム更新を最小サイズのバッファにバッファリングし、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除する。

[0060]ソースデバイス２２０の処理パイプラインはまた、処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。ハードウェア加速の使用は、ソースデバイス２２０の中央処理装置（ＣＰＵ）上の処理負荷を低減することができ、このことは、ＷＤシステム内のフレームレートを増大させ、待ち時間を削減する。ソースデバイス２２０はまた、シンクデバイスによる時宜を得た受信を保証して、ＷＤシステム内の待ち時間をさらに削減するために、符号化されたフレーム更新を再送信する（すなわち、重複プッシュを実行する）ことができる。

[0061]別の例として、本技法によれば、ソースデバイス２２０の処理パイプラインは、ＷＤシステム内のソースデバイス２２０とシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先するように構成され得る。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。

[0062]より具体的には、ソースデバイス２２０のオーディオパイプライン経路は、ビデオパイプライン経路よりも多くのバッファリングを含むように構成され得る。さらなるバッファリングにより、ソースデバイス２２０で削除されるオーディオパケットがより少なくなることが保証される。別の例として、ソースデバイス２２０の処理パイプラインは、ビデオパイプライン経路よりもオーディオパイプライン経路に、ワイヤレスモデム２３４でより高い優先度のトランスポートキューを与えるように構成され得る。より高い優先度のトランスポートキューにより、対応するオーディオパケットを待つビデオパケットによって生じるビデオパイプライン経路内の遅延または失速を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイス２２０でトランスポート用にキューイングされることが保証される。加えて、ソースデバイス２２０のワイヤレスモデム２３４は、通信チャネルのトランスポート状態を記述するフィードバック情報を、ＷＤシステム内のシンクデバイスから受信することができる。それに応答して、ソースデバイス２２０は、フィードバック情報に基づいて処理パイプラインを修正することができる。

[0063]上述された技法のうちの１つまたは複数をソースデバイス２２０に適用すると、ＷＤシステム内のエンドツーエンドの待ち時間が削減され、ＷＤシステム内のソースデバイス２２０とシンクデバイスの両方でユーザ体験が改善され得る。

[0064]図３は、本開示の技法を実装できるＷＤシステム内のシンクデバイス３６０の例を示すブロック図である。シンクデバイス３６０は、図１のシンクデバイス１６０と同様のデバイスであり得、シンクデバイス１６０と同じ方式で動作することができる。シンクデバイス３６０は、プロセッサ３３１と、メモリ３３２と、トランスポートユニット３３３と、ワイヤレスモデム３３４と、ディスプレイプロセッサ３３５と、ローカルディスプレイ３６２と、オーディオプロセッサ３３６と、スピーカ３６３と、ユーザ入力インターフェース３７６とを含む。

[0065]シンクデバイス３６０は、ソースデバイスから送られたカプセル化されたデータユニットをワイヤレスモデム３３４で受信する。ワイヤレスモデム３３４は、たとえば、ＩＥＥＥ８０２．１１規格ファミリーからのもう１つの規格を実装するように構成されたＷｉ−Ｆｉモデムであり得る。トランスポートユニット３３３は、カプセル化されたデータユニットをカプセル化解除することができる。たとえば、トランスポートユニット３３３は、カプセル化されたデータユニットから符号化されたビデオデータを抽出し、かつ復号され出力用にレンダリングされるべき符号化されたＡ／Ｖデータをプロセッサ３３１に送ることができる。ディスプレイプロセッサ３３５は、ローカルディスプレイ３６２に表示されるべき復号されたビデオデータを処理することができ、オーディオプロセッサ３３６は、スピーカ３６３に出力するために復号されたオーディオデータを処理することができる。

[0066]オーディオおよびビデオデータをレンダリングすることに加えて、ワイヤレスシンクデバイス３６０は、ユーザ入力インターフェース３７６を介してユーザ入力データも受信することができる。ユーザ入力インターフェース３７６は、限定はしないが、タッチディスプレイインターフェース、キーボード、マウス、ボイスコマンドモジュール、（たとえば、カメラベースの入力キャプチャ機能を有する）ジェスチャキャプチャデバイスを含む、いくつかのユーザ入力デバイスのいずれも、またはいくつかのユーザ入力デバイスの任意の他のユーザ入力デバイスを表すことができる。ユーザ入力インターフェース３７６を介して受信されたユーザ入力は、プロセッサ３３１によって処理することができる。この処理は、受信されたユーザ入力コマンドを含むデータパケットを生成することを含むことができる。生成されると、トランスポートユニット３３３は、そのデータパケットを、ＵＩＢＣを介したソースデバイスへのネットワークトランスポート用に処理することができる。

[0067]図３のプロセッサ３３１は、１つもしくは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、他の等価な集積回路もしくはディスクリート論理回路などの広範囲のプロセッサのうちの１つまたは複数、あるいはそれらの何らかの組合せを備えることができる。図３のメモリ３３２は、限定はしないが、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリなどを含む、多種多様な揮発性メモリまたは不揮発性メモリのいずれも備えることができる。メモリ２３２は、オーディオ／ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えることができる。加えて、メモリ３３２は、本開示に記載される様々な技法を実行することの一部として、プロセッサ３３１によって実行される命令とプログラムコードとを記憶することができる。

[0068]本開示の技法は、シンクデバイス３６０でのユーザ体験を改善するために、待ち時間を削減し、ビデオの再生品質（すなわち、滑らかさ）を改善するように、シンクデバイス３６０の処理パイプラインを構成することを含む。シンクデバイス３６０の処理パイプラインは、プロセッサ３３１および／またはトランスポートユニット３３３によって実行される１つたは複数の処理ユニットを含む。本技法は、図６に示されるシンクデバイス６６０の処理パイプラインに関して、さらに詳細に記載される。

[0069]一例では、シンクデバイス３６０の処理パイプラインは、ＷＤシステム内のソースデバイスから受信されたメディアデータのタイプに基づいて、シンクデバイス３６０でメディアデータのカスタマイズされた再生を提供するように構成され得る。より具体的には、メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス３６０の処理パイプラインは、ビデオデータの加速されたレンダリングを実行するように構成され得る。たとえば、メディアデータがオーディオデータを含まないことを検出すると、シンクデバイス３６０は、同期を無効にし、存在しないオーディオデータとの同期を待たずに、ビデオデータをレンダリングすることができる。一方、メディアデータがビデオデータとオーディオデータの両方を含むことを検出すると、シンクデバイス３６０は、オーディオレンダリング開始タイマを削減し、削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。

[0070]加えて、シンクデバイス３６０の処理パイプラインは、ストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に構成され得る。ストリームヘッダ情報は、ＷＤシステム内の通信セッションの能力交渉期間の間に、シンクデバイス３６０とソースデバイスによって交換され得る。このようにして、シンクデバイス３６０の処理パイプラインは、受信されたメディアデータの処理を直ちに開始し、処理パイプラインのセットアップ時間に起因するいかなる待ち時間も除去または削減することができる。

[0071]別の例として、本技法によれば、シンクデバイス３６０の処理パイプラインは、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づいて、メディアデータのカスタマイズされたバッファリングを提供するように構成され得る。より具体的には、シンクデバイス３６０は、受信されたメディアデータ用のアプリケーションのタイプを知り、処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現することができる。場合によっては、メディアデータ用のアプリケーションのタイプはソースデバイスで検出され、シンクデバイス３６０にメディアデータとともに通知され得る。その場合、シンクデバイス３６０は、ソースデバイスから受信された指示に基づいて、メディアデータ用のアプリケーションのタイプを知る。他の場合、シンクデバイス３６０は、アプリケーションのタイプ自体を検出することによって、メディアデータ用のアプリケーションのタイプを知ることができる。

[0072]メディアデータが、再生の品質または滑らかさがシンクデバイスで最も優先度が高く、上述された低遅延技法が目に見えるジッタをもたらす場合がある、ビデオ再生アプリケーション用であるとき、シンクデバイス３６０の処理パイプライン内のバッファサイズは増大されて、ビデオ再生アプリケーション用内のメディアデータの滑らかさを増大させる。反対に、メディアデータが、低遅延がシンクデバイスで最も優先度が高い、ユーザインターフェース（ＵＩ）アプリケーションまたはゲームアプリケーション用であるとき、シンクデバイス３６０の処理パイプライン内のバッファサイズは減少されて、ＵＩアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。

[0073]さらなる例として、本技法によれば、シンクデバイス３６０のワイヤレスモデム３３４は、通信チャネルのトランスポート状態を記述するフィードバック情報を、ＷＤシステム内のソースデバイスに送信することができる。シンクデバイス３６０は、前に受信されたメディアデータの誤り率および／またはパケット損失に基づいて、通信チャネルのトランスポート状態を判断することができる。ワイヤレスモデム３３４は、ソースデバイスにＵＩＢＣまたは他の逆チャネルを介してフィードバック情報を送信することができる。場合によっては、シンクデバイス３６０は、フィードバックストリーミング用にリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）を使用することができる。それに応答して、ソースデバイスは、フィードバック情報に基づいて、シンクデバイス３６０に向けられたメディアデータのその処理を修正することができる。

[0074]上述された技法のうちの１つまたは複数をシンクデバイス３６０に適用すると、ＷＤシステム内のエンドツーエンドの待ち時間が削減され、ビデオの再生品質が増大されて、ＷＤシステム内のシンクデバイス３６０でのユーザ体験が改善され得る。

[0075]図４は、通信チャネル１５０を介して通信するために、図１の送信機／受信機１２６および送信機／受信機１６６によって使用できる、例示的な送信機システム４１０と受信機システム４５０とを示すブロック図である。送信機システム４１０では、いくつかのデータストリームのトラフィックデータが、データソース４１２から送信（ＴＸ）データプロセッサ４１４に供給される。各データストリームは、それぞれの送信アンテナを介して送信することができる。ＴＸデータプロセッサ４１４は、データストリームごとのトラフィックデータを、そのデータストリーム用に選択された特定の符号化方式に基づいてフォーマットし、符号化し、インターリーブする。データストリームごとの符号化データは、直交周波数分割多重（ＯＦＤＭ）技法を使用して、パイロットデータと多重化することができる。限定はしないが、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、符号分割多重アクセス（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡ、および／もしくはＣＤＭＡの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用することができる。

[0076]図４に従って、パイロットデータは、通常、知られている方式で処理される知られているデータパターンであり、チャネル応答を推定するために受信機システム４５０で使用することができる。次いで、データストリームごとに多重化されたパイロットデータおよび符号化データは、変調シンボルを与えるために、そのデータストリーム用に選択された特定の変調方式（たとえば、２位相シフトキーイング（ＢＰＳＫ）、４位相シフトキーイング（ＱＰＳＫ）、Ｍ−ＰＳＫ、またはＭ−ＱＡＭ（直交振幅変調）、ここでＭは２のべき乗であり得る）に基づいて、変調（たとえば、シンボルマッピング）される。データストリームごとのデータレート、符号化、および変調は、メモリ４３２と結合できるプロセッサ４３０によって実行される命令によって決定することができる。

[0077]次いで、データストリーム用の変調シンボルがＴＸ ＭＩＭＯプロセッサ４２０に供給され、ＴＸ ＭＩＭＯプロセッサ４２０はさらに（たとえば、ＯＦＤＭ用に）その変調シンボルを処理することができる。次いで、ＴＸ ＭＩＭＯプロセッサ４２０は、Ｎ_T個の変調シンボルストリームをＮ_T個の送信機（ＴＭＴＲ）４２２Ａ〜４２２Ｔ（「送信機４２２」）に供給することができる。いくつかの態様では、ＴＸ ＭＩＭＯプロセッサ４２０は、データストリームのシンボルと、シンボルがそこから送信されているアンテナとにビームフォーミング重みを適用する。送信機４２２の各々は、それぞれのシンボルストリームを受信し処理して、１つまたは複数のアナログ信号を供給し、さらに、それらのアナログ信号を調整（たとえば、増幅、フィルタ処理、およびアップコンバート）して、ＭＩＭＯチャネルを介して送信するのに適した変調信号を供給することができる。次いで、送信機４２２からのＮ_T個の変調信号は、それぞれＮ_T個のアンテナ４２４Ａ〜４２４ｔ（「アンテナ４２４」）から送信される。

[0078]受信機システム４５０では、送信された変調信号はＮ_R個のアンテナ４５２Ａ〜４５２Ｒ（「アンテナ４５２」）によって受信され、アンテナ４５２の各々からの受信信号は、受信機（ＲＣＶＲ）４５４Ａ〜４５４Ｒ（「受信機４５４」）のうちのそれぞれに供給される。受信機４５４の各々は、それぞれの受信信号を調整（たとえば、フィルタ処理、増幅、およびダウンコンバート）し、調整された信号をデジタル化してサンプルを供給し、さらにそれらのサンプルを処理して、対応する「受信」シンボルストリームを供給する。次いで、受信（ＲＸ）データプロセッサ４６０は、Ｎ_R個の受信機４５４からＮ_R個の受信シンボルストリームを受信し、特定の受信機処理技法に基づいて処理して、Ｎ_T個の「検出」シンボルストリームを供給する。次いで、ＲＸデータプロセッサ４６０は、各検出シンボルストリームを復調し、デインターリーブし、復号して、データストリームのトラフィックデータを復元する。ＲＸデータプロセッサ４６０による処理は、送信機システム４１０でのＴＸ ＭＩＭＯプロセッサ４２０およびＴＸデータプロセッサ４１４によって実行される処理と相補関係にある。

[0079]メモリ４７２と結合できるプロセッサ４７０は、どのプリコーディング行列を使用すべきかを周期的に判定する。逆方向リンクメッセージは、通信リンクおよび／または受信データストリームに関する様々なタイプの情報を備えることができる。次いで、逆方向リンクメッセージは、データソース４３６からいくつかのデータストリームのトラフィックデータも受信するＴＸデータプロセッサ４３８によって処理され、変調器４８０によって変調され、送信機４５４によって調整され、送信機システム４１０に返送される。

[0080]送信機システム４１０では、受信機システム４５０からの変調信号は、アンテナ４２４によって受信され、受信機４２２によって調整され、復調器４４０によって復調され、受信機システム４５０によって送信された逆方向リンクメッセージを抽出するためにＲＸデータプロセッサ４４２によって処理される。次いで、プロセッサ４３０は、ビームフォーミング重みを決定するためにどのプリコーディング行列を使用すべきかを判定し、抽出されたメッセージを処理する。

[0081]図５は、本開示の技法をサポートして、ソースデバイス５２０の処理パイプライン５５０内の待ち時間を削減することが可能なソースデバイス５２０の例を示すブロック図である。ソースデバイス５２０は、図１からのソースデバイス１２０または図２からのソースデバイス２２０と同様のデバイスであり得、ソースデバイス１２０またはソースデバイス２２０と同じ方式で動作することができる。

[0082]ソースデバイス５２０は、ローカルディスプレイ５２２と、ディスプレイプロセッサ５３５と、メモリ５３２と、ワイヤレスモデムソケット５７０と、ワイヤレスモデム５３４と、処理パイプライン５５０とを含む。処理パイプライン５５０は、バッファと、プロセッサ５３１およびトランスポートユニット５３３によって実行される処理ユニットとを含む。具体的には、処理パイプライン５５０は、プロセッサ５３１内のビデオ処理エンジン（ＶＰＥ）５６０およびエンコーダ５６２と、トランスポートユニット５３３内のパケッタイザ５６４とを含む。加えて、処理パイプライン５５０は、ディスプレイプロセッサ５３５とＶＰＥ５６０との間に位置するライトバック（ＷＢ）バッファ５４０と、ＶＰＥ５６０とエンコーダ５６２との間のフレームバッファ５４２と、エンコーダ５６２とパケッタイザ５６４との間のコード化ピクチャバッファ（ＣＰＢ）５４４とを含む。

[0083]ソースデバイス５２０はまた、ハードウェア加速器５３６とパイプラインマネージャ５３８とを含む。本開示の技法によれば、パイプラインマネージャ５３８は、ソースデバイス５２０でメディアデータについての低遅延の画面取込みとバッファリングとを提供するように、処理パイプライン５５０を構成する。具体的には、パイプラインマネージャ５３８は、最小サイズのバッファを含み、ハードウェア加速器５３６を使用してメモリ５３２および最小サイズのバッファからメディアデータを取り出すように、処理パイプライン５５０を構成する。

[0084]一例では、ＷＤシステム内の１つまたは複数のシンクデバイスと通信セッションを確立すると、パイプラインマネージャ５３８は、待ち時間を削減するために処理ステップ間で最小サイズのバッファを含むように、ソースデバイス５２０の処理パイプライン５５０を構成する。ある場合には、最小サイズのバッファは、メディアデータがディスプレイプロセッサ５３５とＶＰＥ５６０との間を通り抜けるために、削減された数のＷＢバッファ５４０を含む場合がある。たとえば、パイプラインマネージャ５３８は、メディアデータの少なくとも直近のフレーム更新を保持するために、２つのみのＷＢバッファ５４０、たとえばピンポンバッファを含むように、処理パイプライン５５０を構成することができる。ＷＢバッファ５４０は、ＶＰＥ５６０による処理の前にフレーム更新を保持することができる。加えて、ＷＢバッファ５４０は、メモリ５３２にライトバックされる前に、少なくとも直近のフレーム更新を保持するように構成され得る。たとえば、２つのＷＢバッファ５４０は、３２個未満のエントリ、場合によっては１６個未満のエントリを保持するように構成され得る。

[0085]他の場合には、最小サイズのバッファはまた、メディアデータがＶＰＥ５６０とエンコーダ５６２との間を通り抜けるために、削減された数のフレームバッファ５４２を含む場合がある。たとえば、パイプラインマネージャ５３８は、メディアデータの少なくとも直近のフレーム更新を保持するために、４つのみのフレームバッファ５４２、たとえば、２つのピンポンバッファと２つの保持バッファとを含むように、処理パイプライン５５０を構成することができる。加えて、最小サイズのバッファは、メディアデータがエンコーダ５６２とパケッタイザ５６４との間を通り抜けるために、削減された数のＣＰＢ５４４を含む場合がある。たとえば、パイプラインマネージャ５３８は、メディアデータの少なくとも直近のフレーム更新を保持するために、６個のみのＣＰＢ５４４、たとえば２つのピンポンバッファと４つの保持バッファとを含むように、処理パイプライン５５０を構成することができる。

[0086]ソースデバイス５２０の処理パイプライン５５０内で最小サイズのバッファを使用すると、本技法によれば、フレーム更新が処理の前と間により少なく小さいバッファを通り抜けるので、ソースデバイス５２０での待ち時間が削減される。加えて、ＷＢバッファ５４０のサイズを３２個未満のエントリを有する２つのピンポンバッファに最小化すると、処理パイプライン５５０のさらなるダウンストリームを詰まらせるのではなく、ソースデバイス５２０の処理パイプライン５５０の早い段階でフレームドロップが発生することが可能になる。

[0087]ソースデバイス５２０の処理パイプライン５５０が最小サイズのバッファを含むように修正されたとき、パイプラインマネージャ５３８はまた、直近のフレーム更新がバッファリングされ、処理され、シンクデバイスに送信されることを保証するように、処理パイプライン５５０内のフレーム取込みプロセスを修正することができる。本技法は、最小サイズのバッファにメディアデータから取り込まれた少なくとも直近のフレーム更新をバッファリングすることと、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除することとを含む。たとえば、各フレーム更新（たとえば、部分フレームまたは全体フレームのいずれか）は、ソースデバイス５２０内のＷＤシステム専用のＷＢバッファ５６０にキューイングされ得るか、または蓄積され得る。最小サイズのＷＢバッファ５６０がさらなるフレーム更新のために一杯になった場合、ＷＢバッファ５６０は、より古いフレーム更新を削除し、より最近のフレーム更新を維持するように構成され得る。最小サイズのＷＢバッファ５６０は、新しいフレーム更新が受信されるやいなや処理用にフレーム更新を出力することができない可能性がある。本技法によれば、より古いフレーム更新のうちの１つまたは複数は、新しいフレーム更新がバッファリングされ、処理され、送信されることを可能にするために、ＷＢバッファ５６０から削除され得る。

[0088]別の例として、処理パイプライン５５０は、メモリ５３２、ＷＢバッファ５４０、フレームバッファ５４２、および／またはＣＰＢ５４４からフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。たとえば、処理パイプライン５５０は、ハードウェア加速器５３６を使用して、ソースデバイス５２０の中央処理装置（ＣＰＵ）の代わりに処理パイプライン５５０内の処理ユニットにより、処理用にフレーム更新を取り出すことができる。ハードウェア加速器５３６を使用すると、ソースデバイス５２０のＣＰＵ上の処理負荷が低減され得、このことは、フレームレートを増大させ、ソースデバイス５２０内の待ち時間を削減することができる。

[0089]メディアデータの取り込まれたフレームのピクセル用イメージフォーマットは、通常、ＲＧＢ８８８、ＲＧＢ５６５、またはＹＵＶ生フォーマットのうちの１つである。ソースデバイス５２０のＣＰＵを使用してメディアデータの取り込まれたフレームの標準メモリコピーにアクセスすると、高いフレームレートの更新を実現するために多くのＣＰＵ負荷がかかりすぎる。ＷＤシステム用のメディアデータ処理がソースデバイス５５０で過剰なＣＰＵ処理負荷を消費するとき、ユーザは、ＷＤシステム内のソースデバイス５５０およびシンクデバイス上で実行されているメディアアプリケーションの待ち時間または緩慢さに気付く場合がある。本技法は、ハードウェア加速器５３６を使用して直接メモリアクセス（ＤＭＡ）を実行して、メモリ５３２またはバッファのうちの１つに保持されたフレーム更新を取り出し、ＣＰＵから独立して、処理パイプライン５５０内の処理ユニット間でフレーク更新を移動させることを含む。

[0090]ソースデバイス５２０内のエンコーダ５６２は、ハードウェアベースおよび／またはソフトウェアベースであり得る。ＶＰＥ５６０がフレーム更新をフレームバッファ５４２内にレンダリングした後、エンコーダ５６２はフレーム更新を符号化する。符号化されたフレーム更新は、パケッタイザ５６４によるパケット情報およびワイヤレスモデム５３４によるシンクデバイスへの送信の前に、ＣＰＢ５４４にバッファリングされ得る。場合によっては、ＣＰＢ５４４は、ＣＰＢ５４４にバッファリングするために符号化されたフレーム更新のさらなるメモリコピーを作成する代わりに、メモリ５３２に記憶された符号化されたフレーム更新へのポインタをバッファリングするように構成され得る。一例として、ポインタは、メモリ５３２内の符号化されたフレーム更新のソースアドレスを指定することができ、その結果、符号化されたフレーム更新はＣＰＢ５４４内で参照されるが、実際のメモリコピーはメモリ５３２に保持される。このようにして、ソースデバイス５２０は、符号化されたフレーム更新のさらなるメモリコピーを生成および記憶することのコストを回避することができる。他の例では、本技法は、他の方法を使用して、さらなるメモリコピーのコストを節約することができる。より具体的には、本技法は、符号化されたフレーム更新のさらなるメモリコピーを作成せずにＣＰＢ５４４内の符号化されたフレーム更新を参照するために、マッピングされたメモリまたはメモリ５３２への送受信要求を使用することを含むことができる。

[0091]さらなる一例では、本技法はまた、シンクデバイスによる時宜を得た受信を保証して、ＷＤシステム内の待ち時間をさらに削減するために、ソースデバイス５２０からの符号化されたフレーム更新の再送信（すなわち、重複プッシュ）を含むことができる。重複プッシュは、ソース５２０とシンクデバイスとの間で多くのメディアデータパケットが削除され得る不十分な通信チャネルの場合、特に有用であり得る。一例では、ソースデバイス５２０は、失われたフレームを再送信するためにシンクデバイスからのフィードバックに依拠しない場合がある。代わりに、ソースデバイス５２０のワイヤレスモデム５３４は、新しいフレーム更新がシンクデバイスへの送信用に受信されなかった場合、所定の時間期間の後、フレーム更新を自動的に再送信することができる。たとえば、ワイヤレスモデム５３４は、新しいフレーム更新が受信されなかった場合、約１３秒後に最新のフレーム更新を自動的に再送信することができる。他の場合、ワイヤレスモデム５３４は、約１０秒またはそれ未満の後に最新のフレーム更新を再送信することができる。

[0092]ソースデバイス５２０で実行される重複プッシュにより、ディスプレイコンテンツが、信頼できないトランスポートに起因してシンクデバイスで破損したフレームから回復することが可能になり得る。たとえば、ソースデバイス５２０のワイヤレスモデム５３４が、たとえば、伝送制御プロトコル（ＴＣＰ）と比較して相対的に信頼できないトランスポートプロトコルであるユーザデータグラムプロトコル（ＵＤＰ）を使用するとき、ワイヤレスモデム５３４は、所定の時間期間の後新しいフレーム更新が受信されなかった場合、重複プッシュを実行して最新のフレーム更新を再送信することができる。いくつかの例では、重複プッシュ間隔は、送信されているメディアデータのタイプに基づいて、動的に調整可能であり得る。ユーザインターフェース（ＵＩ）アプリケーションまたはゲームアプリケーション用のメディアデータの場合、失われたフレームは目立ち、ＷＤシステム内のＵＩアプリケーションのユーザ体験に悪影響を及ぼす。ビデオ再生アプリケーション用のメディアデータの場合、失われたフレームは容易に目立たず、ビデオ再生アプリケーションのユーザ体験に少ししか影響を与えないか、まったく影響を与えない。したがって、ＵＩアプリケーションおよびゲームアプリケーションの場合、ワイヤレスモデム５３４は、ビデオ再生アプリケーションよりも頻繁に重複プッシュを実行するように構成され得る。たとえば、ＵＩアプリケーションおよびゲームアプリケーションの場合、重複プッシュ間隔は、約１０秒またはそれ未満に削減され得る。

[0093]場合によっては、ソースデバイス５２０のエンコーダ５６２および／またはシンクデバイスの各々のデコーダからフレームをプッシュするために、同様の重複プッシュメカニズムが使用され得る。通常、エンコーダおよびデコーダは、コード化されたフレームを各々自動的に出力しないが、次のフレームを受信して前のコード化されたフレームを押し出す必要がある。したがって、本技法は、さらなるプッシュを与えてコード化されたフレーム更新を出力することによって、ソースデバイス５２０と１つまたは複数のシンクデバイスとの間の同期を改善することができる。

[0094]加えて、本開示の技法はまた、ＷＤシステム内のソースデバイス５２０とシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャ５３８は、ソースデバイス５２０内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。さらなるバッファリングにより、ソースデバイス５２０で削除されるオーディオパケットがより少なくなることが保証される。ワイヤレスモデムソケット５７０は、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。より高い優先度のトランスポートキューにより、キューイングされるべき対応するオーディオパケットを待つビデオパケットに起因するビデオパイプライン経路内の遅延または失速を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイス５２０でトランスポート用にキューイングされることが保証される。

[0095]従来、オーディオとビデオの両方の処理パイプライン経路は、同じまたは同様の量のバッファリングとトランスポート優先度とを有する。オーディオデータは、すべてのメディアデータがシンクデバイスで受信されることを保証するために、より注意深い処理とトランスポートとを必要とするので、ソースデバイス内の従来のビデオパイプライン経路は、関連するオーディオデータの準備ができるまでビデオデータのトランスポートを遅延または失速させ、このことはＷＤシステム内にさらなる待ち時間をもたらす。オーディオパイプライン経路を優先させることによって、ビデオパイプライン経路内のさらなる遅延または失速時間が不要になる。

[0096]本技法によれば、オーディオデータの優先トランスポートは、パケットがオーディオトラフィックを含むか、またはビデオトラフィックを含むかを示すように、メディアデータパケット内のサービスタイプ（ＴＯＳ）フィールドを設定することによって実現され得る。たとえば、通信チャネルがＷｉ−Ｆｉマルチメディア（ＷＭＭ）をサポートする場合、ＴＯＳフィールドは、音声と、ビデオと、ベストエフォートと、バックグラウンドとを含む優先順位づけ目的で、ＷＭＭによって規定されたアクセスカテゴリを示すことができる。メディアデータパケット内のＴＯＳフィールドにより、ソースデバイス５５０内のワイヤレスモデムドケット５７０が、オーディオパケットとビデオパケットとを、異なる優先レベルを有する異なるキューに入れることが可能になる。

[0097]加えて、ソースデバイス５２０は、シンクデバイスとの通信チャネルのトランスポート状態を記述するフィードバック情報をシンクデバイスから受信することができる。たとえば、フィードバック情報は、シンクデバイスで判断され、ソースデバイス５２０に通信される誤り率またはパケット損失を含む場合がある。場合によっては、フィードバック情報は、ＷＤシステム内のシンクデバイスとソースデバイス５２０との間で確立されたＵＩＢＣを介して、シンクデバイスからソースデバイス５２０に送られ得る。他の場合、フィードバック情報は、異なるソケットリンクを介してソースデバイス５２０に送られ得る。加えて、フィードバック情報は、ＲＴＣＰまたは他の何らかのカスタマイズされたシグナリングを使用して通信され得る。

[0098]それに応答して、ソースデバイス５２０のパイプラインマネージャ５３８は、フィードバック情報に基づいてソースデバイス５２０の処理パイプライン５５０を修正することができる。一例では、不十分な通信チャネルを記述するフィードバック情報を受信したことに応答して、ソースデバイス５２０は、メディアデータパケットを再送信する重複プッシュ間隔を、たとえば１０秒以上または１３秒以上に増大させるか、またはメディアデータパケットを処理および送信するためのデータレートを変更することができる。別の例では、フィードバック情報に応答して、ソースデバイス５２０は、全体的に、バッファサイズと符号化パラメータとを調整するか、またはトランスポートプロトコルのタイプ間を動的に切り替えることができる。たとえば、不十分な通信チャネルを記述するフィードバック情報に応答して、ソースデバイス５２０は、比較的信頼できないトランスポートプロトコルであるリアルタイムプロトコル（ＲＴＰ）／ユーザデータグラムプロトコル（ＵＤＰ）の通信チャネルから、ＲＴＰ／伝送制御プロトコル（ＴＣＰ）のトランスポートチャネルに切り替えることができる。

[0099]図６は、本開示の技法をサポートして、シンクデバイス６６０の処理パイプライン６５０内の待ち時間を削減し、シンクデバイス６６０でのビデオ再生を改善することが可能なシンクデバイス６６０の例を示すブロック図である。シンクデバイス６６０は、図１からのシンクデバイス１６０または図３からのシンクデバイス２６０と同様のデバイスであり得、シンクデバイス１６０またはシンクデバイス２６０と同じ方式で動作することができる。

[0100]シンクデバイス６６０は、ローカルディスプレイ６２２と、ディスプレイプロセッサ６３５と、メモリ６３２と、ワイヤレスモデムソケット６７０と、ワイヤレスモデム６３４と、処理パイプライン６５０とを含む。処理パイプライン６５０は、バッファと、プロセッサ６３１およびトランスポートユニット６３３によって実行される処理ユニットとを含む。具体的には、処理パイプライン６５０は、トランスポートユニット６３３内のパーサ６８０と、プロセッサ６３１内のデコーダ６８２およびレンダラ６８４とを含む。加えて、処理パイプライン６５０は、パーサ６８０とデコーダ６８２との間に位置するバッファ６９２と、デコーダ６８２とレンダラ６８４との間に位置するレンダリングキュー６８４と、レンダラ６８４とディスプレイプロセッサ６３５との間のフレームバッファ６９６とを含む。

[0101]シンクデバイス６６０は、パイプラインマネージャ６３８も含む。本開示の技法によれば、パイプラインマネージャ６３８は、ソースデバイスから受信されたメディアデータのタイプに基づいて、シンクデバイス６６０でのカスタマイズされた再生を提供するように、処理パイプライン６５０を構成する。具体的には、パイプラインマネージャ６３８は、メディアデータがオーディオデータを含むかどうかに基づいてレンダリングを修正するように、処理パイプライン６５０を構成する。

[0102]たとえば、メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス６６０の処理パイプライン６５０に含まれるレンダラ６８４は、ビデオデータの加速されたレンダリングを実行するように構成される。メディアデータがオーディオデータを含まないことを検出すると、パイプラインマネージャ６３８は、レンダラ６８４での同期を無効にすることができる。次いで、レンダラ６８４は、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングすることができる。

[0103]従来、メディアデータ処理パイプラインは、ビデオデータとオーディオデータの両方、またはオーディオデータがないビデオデータのみのために設計される。ビデオデータのみを受信すると、ビデオデータとオーディオデータの両方のために設計されたメディアデータ処理パイプラインは、ビデオデータとオーディオデータの両方を処理するのに必要な速度と同じ速度でビデオデータを処理し、存在しないオーディオデータとの同期用の待ち時間を含む。さらなる処理時間は、処理パイプラインに待ち時間を不必要に加える。本開示の技法により、シンクデバイス６６０のデコーダ６８２が、受信されたメディアデータのタイプを検出し、メディアデータのタイプに基づいてレンダラ６８４での再生処理速度を動的に調整することが可能になる。たとえば、デコーダ６８２は、メディアデータ内のオーディオタイムスタンプの存在または不在を検出することができ、オーディオタイムスタンプの存在により、ソースデバイスからのメディアデータがオーディオデータを含むことが示される。

[0104]たとえば、ＵＩアプリケーション用のメディアデータの場合、ビデオデータに付随するオーディオデータは存在しない。ＵＩアプリケーションデータの場合、パイプラインマネージャ６３８は、シンクデバイス６６０のレンダラ６８４での同期を無効にすることができる。このようにして、レンダラ６８４は、存在しないオーディオデータの処理および同期のための待ち時間なしに、可及的速やかにＵＩアプリケーション用のビデオデータをレンダリングすることができる。ビデオ再生アプリケーション用のメディアデータの場合、ビデオデータに付随するオーディオデータが存在する場合がある。オーディオデータ付きのビデオ再生アプリケーションデータの場合、パイプラインマネージャ６３８は同期を有効にすることができ、レンダラ６８４は、同期されたビデオデータとオーディオデータとを通常の処理速度でレンダリングすることができる。

[0105]加えて、本技法により、パイプラインマネージャ６３８がレンダラ６８４に適用可能なメディア時間に基づいて、レンダラ６８４でのサンプル時間を調整することも可能になる。このようにして、ソースデバイスによって設定されたメディアデータのサンプル時間がシンクデバイス６６０にあるレンダラ６８４に適用可能ではないとき、パイプラインマネージャ６３８は、メディア時間に基づいてメディアデータに適用可能なサンプル時間を選択することができる。

[0106]別の例として、メディアデータがビデオデータとオーディオデータの両方を含む場合、パイプラインマネージャ６３８は、オーディオレンダリング開始タイマを削減することができ、レンダラ６８４は削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。このようにして、本技法は、メディアデータがオーディオデータを含むときでも、シンクデバイス６６０での待ち時間を削減することができる。

[0107]いくつかの再生エンジンでは、着信したオーディオパケットの消失または削除を回避するために、オーディオのレンダリングは起動時に遅延され得る。遅延時間は、Ｂｌｕｅｔｏｏｔｈシステムなどの何らかの通信システムに必要であり得る。ＷＤシステムなどの他の通信システムの場合、同期が有効であるとき、遅延は不要であり、エンドツーエンドの待ち時間を増加させる。たとえば、Ｂｌｕｅｔｏｏｔｈシステムに必要なアドバンストオーディオ配信プロファイル（Ａ２ＤＰ）初期化時間、たとえば、１秒以上を補償するために、シンクデバイス６６０のレンダラ６８４でのオーディオレンダリング開始タイマは、比較的高く設定され得る。オーディオデータのレンダリングは開始時間だけ遅延され、着信したサンプルはレンダラ６８４に入力される前にバッファリングされる必要がある。オーディオデータが遅延された場合、オーディオデータとビデオデータの同期を保つために、対応するビデオデータも遅延される必要がある。

[0108]本開示に記載された技法によれば、ＷＤシステムの場合、レンダラ６８４でのオーディオレンダリング開始タイマは削減されて、シンクデバイス６６０内の待ち時間を削減し、オーディオデータとビデオデータの失速を回避する。たとえば、ＷＤシステムの場合、パイプラインマネージャ６３８は、シンクデバイス６６０でのより速いレンダリングと再生とを提供するために、オーディオレンダリング開始タイマを削減または除去することができる。オーディオレンダリング開始タイマは、１秒未満、５０ミリ秒（ｍｓ）未満、場合によっては２０ｍｓ未満になるように削減され得る。Ｂｌｕｅｔｏｏｔｈシステムの場合、パイプラインマネージャ６３８は、比較的高い、たとえば１秒以上になるようにオーディオレンダリング開始タイマを動的にリセットすることができる。

[0109]別の例では、パイプラインマネージャ６３８は、セットアップ時間に起因する待ち時間を削減するために通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に、シンクデバイス６６０内の処理パイプライン６５０を構成することができる。処理パイプライン６５０を事前構成するために、ソースデバイスおよびシンクデバイス６６０は、通信チャネルを介して送信されるべきメディアデータについての情報を含むストリームヘッダ情報を最初に交換する。ストリームヘッダ情報は、リアルタイムストリーミングプロトコル（ＲＴＳＰ）または他のプロプライエタリなメッセージを使用して交換され得る。次いで、パイプラインマネージャ６３８は、構成バッファサイズと、レンダリング開始タイマと、同期待ちタイマと、プログラマブルデコーダ設定とを含む、受信されたヘッダ情報に基づいて処理パイプライン６５０をセットアップする。処理パイプライン６５０が構成された後、シンクデバイス６６０は、メディアデータの送信を開始するようにソースデバイスに通知する。

[0110]加えて、ソースデバイスから受信されたメディアデータを処理する前に、シンクデバイス６６０は、デコーダ６８２から受信されたメディアデータの１つまたは複数のサンプルをフラッシュすることができる。メディアデータの最初の数個のサンプルは、通信セッションの交渉期間の間に生成された、ソースデバイスパイプラインからの古くて失速したサンプルを備える可能性がある。本技法は、ソースデバイスからのフレームを再送信して、シンクデバイス６６０にあるデコーダ６８２から失速したサンプルをプッシュするために、重複プッシュを提供する。このようにして、シンクデバイス６６０は、メディアデータの古くて失速したサンプルに対していかなる処理時間も浪費しない。

[0111]場合によっては、シンクデバイス６６０にあるパイプラインマネージャ６３８は、レンダラ６８４によるレンダリング用にデコーダ６８２からサンプルをプッシュするためにデコーダ６８２にダミーフレームを挿入することができる。これは、デコーダ６８２がプログラム可能ではなく、着信したメディアデータサンプルのピクチャ順序カウント（ＰＯＣ）の復号をサポートしないとき、必要であり得る。他の場合、デコーダ６８２がプログラム可能であり、ＰＯＣをサポートする場合、パイプラインマネージャ６３８は、表示順序の代わりに、ＰＩＣまたは復号順序に従ってメディアデータサンプルを出力するように、デコーダ６８２を構成することができる。復号順序でサンプルを出力するようにプログラマブルデコーダ６８２を構成すると、デコーダ６８２へのあらゆる入力サンプルは、復号が完了するとすぐに出力されることが保証される。このようにして、デコーダ６８２での失速および遅延は、削減または除去され得る。加えて、パイプラインマネージャ６３８は、デコーダ６８２とレンダラ６８４との間のレンダリングキュー６９４に含まれるバッファの数を最小化して、シンクデバイス６６０内の待ち時間をさらに削減することができる。たとえば、レンダリングキュー６９４は、レンダラ６８４によるレンダリングの前にメディアデータを保持するバッファを、４つまたはそれより少なく含む場合がある。

[0112]加えて、本開示の技法によれば、パイプラインマネージャ６３８は、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づいて、シンクデバイス６６０でカスタマイズされたバッファリングを提供するように、処理パイプライン６４０を構成する。具体的には、ソースデバイス６６０のデコーダ６８２は、受信されたメディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャ６３８は、処理パイプライン６５０内のバッファのサイズを調整するように処理パイプライン６５０を構成する。このようにして、シンクデバイス６６０は、メディアデータ用のアプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現することができる。パイプラインマネージャ６３８は、レンダリングキュー６９４、フレームバッファ６９６、または、メディアデータ用のアプリケーション内の表示の前にデータを保持する、処理パイプライン６５０に含まれる任意の他のバッファのサイズを調整することができる。

[0113]たとえば、メディアデータがビデオ再生アプリケーション用であるとき、再生の品質または滑らかさがシンクデバイス６６０で最も優先度が高く、上述された低遅延技法は目に見えるジッタをもたらす場合がある。この場合、パイプラインマネージャ６３８は、ビデオ再生アプリケーション内のメディアデータの滑らかさを増大させるために処理パイプライン６５０内のバッファのサイズを増大させることができる。反対に、メディアデータがユーザインターフェース（ＵＩ）アプリケーションまたはゲームアプリケーション用であるとき、低遅延がシンクデバイス６６０で最も優先度が高い。この場合、パイプラインマネージャ６３８は、ＵＩアプリケーションまたはゲームアプリケーションについての待ち時間を削減するために処理パイプライン６５０内のバッファのサイズを減少させることができる。バッファサイズを削減することによって、パイプラインマネージャ６３８は、ＵＩアプリケーションまたはゲームアプリケーション用のメディアデータが、失速または遅延なしにシンクデバイス６６０内の処理パイプライン６５０を通り抜けることを可能にする。

[0114]場合によっては、メディアデータ用のアプリケーションのタイプは、ソースデバイスで検出され、ＷＤシステム内のシンクデバイス６６０に通知され得る。たとえば、シンクデバイス６６０は、ソースデバイスから受信された指示に基づいて、受信されたメディアデータ用のアプリケーションを検出することができる。ソースデバイスは、着信したオーディオレートとオーディオデータの画面更新レートとを検出することによって、メディアデータがビデオ再生アプリケーション用であると判断することができる。ソースデバイスは、ビデオ再生エンジン用のメディアデータの開始の指示をシンクデバイス６６０に送り、ビデオ再生アプリケーション用のメディアデータの終了の別の指示をシンクデバイス６６０に送ることができる。シンクデバイス６６０は、メディアプレーヤプロトコルまたは別のプロプライエタリなプロトコルで、メディアデータとともにフラグまたは他のインジケータを受信することができる。

[0115]他の場合、メディアデータ用のアプリケーションのタイプは、シンクデバイス６６０で検出され得る。シンクデバイス６６０にあるデコーダ６８２は、一定の間隔で受信されたメディアデータに含まれるオーディオタイムスタンプに基づいて、受信されたメディアデータ用のアプリケーションのタイプを判断することができる。メディアデータが一定の間隔で対応するオーディオデータを有するビデオデータを含むとき、メディアデータはビデオ再生アプリケーション用であるとみなされ得る。したがって、デコーダ６８２は、ビデオ再生アプリケーション用のメディアデータを受信しながら、一定の間隔で発生するオーディオタイムスタンプを検出することができる。

[0116]いずれの場合も、受信されたメディアデータがビデオ再生アプリケーション用であることをシンクデバイス６６０のデコーダ６８２が知ったとき、パイプラインマネージャ６３８は、ビデオ再生アプリケーション内の表示の前にメディアデータを保持するために使用されるバッファ、たとえば、レンダリングキュー６９４またはフレームバッファ６９６のサイズを増大させる。たとえば、パイプラインマネージャ６３８は、レンダリングキュー６９４内に４つ以上のバッファを含むように、かつ４つ以上のフレームバッファ６９６、たとえば、２つのピンポンバッファと少なくとも２つの保持バッファとを含むように、処理パイプライン６５０を構成することができる。バッファが大量のメディアデータを保持することが可能であるとき、フレームを落とすリスクは減少し、再生内のジッタの数も減少する。

[0117]一方、受信されたメディアデータがビデオ再生アプリケーション用ではなく、ＵＩアプリケーションまたはゲームアプリケーション用であることをシンクデバイス６６０のデコーダ６８２が知ったとき、パイプラインマネージャ６３８は、ＵＩアプリケーションまたはゲームアプリケーション内の表示の前にメディアデータを保持するために使用されるバッファのサイズを減少させる。たとえば、パイプラインマネージャ６３８は、レンダリングキュー６９４内に４つ未満のバッファを含むように、かつ４つ以下のフレームバッファ６９６、たとえば、２つのピンポンバッファと多くとも２つの保持バッファとを含むように、処理パイプライン６５０を構成することができる。このようにして、メディアデータは、シンクデバイス６６０の処理パイプライン６５０を通り抜けて、待ち時間を改善する。

[0118]場合によっては、パイプラインマネージャ６３８は、レンダリングキュー６９４にさらなるメディアデータサンプルを記憶するために、ある時間期間の間レンダラ６８４を休止することができる。たとえば、パイプラインマネージャ６３８は、しきい値の数のサンプルがレンダリングキュー６９４に記憶されるまでレンダラ６８４を休止し、次いで、レンダリングを再開してビデオ再生の滑らかさを増大することができる。場合によっては、しきい値の数のサンプルは、８個のサンプル、１６個のサンプル、または場合によっては１６個より多いサンプルに設定され得る。

[0119]加えて、シンクデバイス６６０は、ソースデバイスにソースデバイスとの通信チャネルのトランスポート状態を記述するフィードバック情報を供給することができる。ソースデバイスは、図５に関してより詳細に上述されたように、フィードバック情報に基づいてその処理パイプラインを修正することができる。たとえば、フィードバック情報は、シンクデバイス６６０で判断され、ソースデバイスに通信された誤り率またはパケット損失を含む場合がある。場合によっては、ワイヤレスモデム６３４は、ＷＤシステム内のシンクデバイス６６０とソースデバイスとの間で確立されたＵＩＢＣを介して、シンクデバイス６６０からソースデバイスにフィードバック情報を送ることができる。他の場合、ワイヤレスモデム６３４は、異なるソケットリンクを介して、シンクデバイス６６０からソースデバイスにフィードバック情報を送ることができる。加えて、ワイヤレスモデム６３４は、ＲＴＣＰまたは他の何らかのカスタマイズされたシグナリングを使用して、フィードバック情報を通信することができる。

[0120]図７は、シンクデバイスで取得されたユーザ入力データおよび／またはフィードバックデータをソースデバイスに配信するために使用され得る例示的なデータパケット７００を示す概念図である。図１を参照してデータパケット７００の態様が説明されるが、論じられる技法はＷＤシステムのさらなるタイプに適用可能であり得る。データパケット７００は、その後にペイロードデータ７５０が続くデータパケットヘッダ７１０を含む場合がある。データパケット７００は、たとえば、シンクデバイス１６０で受信されたユーザ入力データをシグナリングするため、または、通信チャネル１５０のトランスポート状態を記述するフィードバック情報をシグナリングするために、シンクデバイス１６０からソースデバイス１２０に送信され得る。

[0121]ペイロードデータ７５０に含まれるデータのタイプ、たとえば、ユーザ入力データまたはフィードバックデータは、データパケットヘッダ７１０内で識別され得る。このようにして、データパケットヘッダ７１０のコンテンツに基づいて、ソースデバイス１２０は、データパケット７００のペイロードデータ７５０を構文解析して、シンクデバイス１６０からのユーザ入力データまたはフィードバックデータを識別することができる。本開示で使用する「構文解析」および「構文解析する」という用語は、一般に、ビットストリームを解析してビットストリームからデータを抽出するプロセスを指す。データを抽出することは、たとえば、ビットストリーム内の情報がどのようにフォーマットされているかを識別することを含む場合がある。以下でより詳細に記載されるように、データパケットヘッダ７１０は、ペイロードデータ７５０用の多くの可能なフォーマットのうちの１つを規定することができる。データパケットヘッダ７１０を構文解析することによって、ソースデバイス１２０は、ペイロードデータ７５０がどのようにフォーマットされているかと、ユーザ入力コマンドまたはフィードバック情報を抽出するためにペイロードデータ７５０をどのように構文解析すべきかとを判断することができる。

[0122]いくつかの例では、データパケットヘッダ７１０は、図７に示されたようにフォーマットされた１つまたは複数のフィールド７２０を含む場合がある。フィールド７２０に隣接する番号０〜１５ならびにビットオフセット０、１６、および３２は、データパケットヘッダ７１０内のビット位置を識別するものであり、データパケットヘッダ７１０内に含まれている情報を実際に表すものではない。データパケットヘッダ７１０は、バージョンフィールドと、タイムスタンプフラグと、予備フィールドと、入力カテゴリフィールドと、長さフィールドと、オプションのタイムスタンプフィールドとを含む。図７の例では、バージョンフィールドは、シンクデバイス１６０によって実装されている特定の通信プロトコルのバージョンを示すことができる３ビットのフィールドである。バージョンフィールド内の値は、データパケットヘッダ７１０の残りをどのように構文解析すべきか、ならびにペイロードデータ７５０をどのように解析すべきかを、ソースデバイス１２０に通知することができる。

[0123]図７の例では、タイムスタンプフラグ（Ｔ）は、タイムスタンプフィールドがデータパケットヘッダ７１０内に存在するか否かを示す１ビットのフィールドである。存在する場合、タイムスタンプフィールドは、ソースデバイス１２０によって生成され、シンクデバイス１６０に送信されたマルチメディアデータに基づくタイムスタンプを含む１６ビットのフィールドである。タイムスタンプは、たとえば、ビデオのフレームがシンクデバイス１６０に送信されるより前に、ソースデバイス１２０によってそのフレームに割り当てられる連続値であり得る。データパケットヘッダ７１０を構文解析し、タイムスタンプフィールドが存在するかどうかを判定すると、ソースデバイス１２０は、タイムスタンプフィールドに含まれるタイムスタンプを処理する必要があるかどうかを知る。図７の例では、予備フィールドは、バージョンフィールド内で識別される特定のプロトコルの将来のバージョン用に確保された８ビットのフィールドである。

[0124]図７の例では、入力カテゴリフィールドは、ペイロードデータ７５０に含まれているデータについての入力カテゴリを識別する４ビットのフィールドである。たとえば、シンクデバイス１６０は、ユーザ入力データを分類して入力カテゴリを特定することができる。ユーザ入力データは、コマンドの受信元のデバイスに基づいて、またはコマンド自体の特性に基づいて、分類され得る。シンクデバイス１６０はまた、フィードバック情報を分類して入力カテゴリを特定することができる。フィードバック情報は、シンクデバイス１６０で決定されたフィードバック情報のタイプ、またはフィードバック情報に基づいてソースデバイス１２０で要求された動作のタイプに基づいて、分類され得る。入力カテゴリフィールドの値は、場合によってはデータパケットヘッダ７１０の他の情報ととともに、ペイロードデータ７５０がどのようにフォーマットされているかをソースデバイス１２０に対して識別する。このフォーマッティングに基づいて、ソースデバイス１２０は、ペイロードデータ７５０を構文解析して、ユーザ入力コマンドまたはフィードバック情報を抽出することができる。

[0125]長さフィールドは、データパケット７００の長さを示す１６ビットのフィールドを備えることができる。データパケット７００が１６ビットのワードでソースデバイス１２０によって構文解析されるとき、データパケット７００は１６ビットの整数までパディングされ得る。長さフィールドに含まれている長さに基づいて、ソースデバイス１２０は、ペイロードデータ７５０の終了（すなわち、データパケット７００の終了）と新しい後続のデータパケットの開始とを識別することができる。

[0126]図７の例で提供されたフィールドの様々なサイズは単に説明用のものであり、それらのフィールドは、図７に示されたものとは異なる数のビットを使用して実装され得るものである。加えて、データパケットヘッダ７１０は、上記で説明されたすべてのフィールドよりも少ないフィールドを含む場合があるか、または上記で説明されていないさらなるフィールドを使用する場合があることも考えられる。実際、本開示の技法は、パケットの様々なデータフィールドに使用される実際のフォーマットの点でフレキシブルであり得る。

[0127]図８は、処理パイプライン内のメディアデータの低遅延のフレーム取込みとバッファリングとをサポートすることが可能なソースデバイスの例示的な動作を示すフローチャートである。図示された動作は、図５からのソースデバイス５２０に含まれる処理パイプライン５５０に関して記載される。他の例では、図示された動作は、図２からのソースデバイス２２０、図１からのソースデバイス１２０、またはＷＤシステムの別のソースデバイスによって実行され得る。

[0128]ソースデバイス５２０は、最初にＷＤシステム内の１つまたは複数のシンクデバイスと通信セッションを確立する（８００）。ソースデバイス５２０は、シンクデバイスとの能力交渉に従って通信セッションを確立することができる。本開示の技法によれば、メディアデータの低遅延のフレーム取込みとバッファリングとをサポートするために、ソースデバイス５２０のパイプラインマネージャ５３８は、最小サイズのバッファを含むように処理パイプライン５５０を構成する（８０２）。具体的には、パイプラインマネージャ５３８は、ＷＢバッファ５４０のサイズを低減して２つのピンポンバッファのみを含むように、処理パイプライン５５０を構成することができる。処理パイプライン５５０に沿って通り抜けるようにメディアデータ用のバッファの数を低減すると、ソースデバイス５２０での待ち時間が削減される。加えて、パイプラインマネージャ５３８は、メディアデータの少なくとも直近のフレーム更新を保持することが可能な最小サイズのフレームバッファにフレームバッファ５４２のサイズを低減するように、処理パイプライン５５０を構成することができる。

[0129]さらに、本技法によれば、パイプラインマネージャ５３８は、ハードウェア加速器５３６を使用して処理パイプライン５５０内のメディアデータの直接メモリアクセスを実行するように、処理パイプライン５５０を構成することができる（８０４）。標準メモリコピーを使用してメモリ５３２および処理パイプライン５５０内のバッファからメディアデータのフレーム更新を取り出すと、ＣＰＵ負荷が過剰に使用される。メディアデータのフレームレートを増大させ、待ち時間を削減するために、処理パイプライン５５０は、代わりにハードウェア加速器５３６を使用して、フレーム更新にアクセスし、ＣＰＵから独立した処理パイプライン５５０の処理ユニット間を移動させる。

[0130]処理パイプライン５５０がソースデバイス５２０内で構成された後、ソースデバイス５２０は、ＷＤシステム内のシンクデバイスへの送信用のメディアデータの処理を開始することができる。ディスプレイプロセッサ５３５は、メディアソースからメディアデータのフレーム更新を取り込む（８０６）。メディアソースは、ソースデバイス５２０内に含まれるカメラまたは他のメディア取込みデバイスであり得るか、または、有線接続もしくはワイヤレス接続のいずれかを介してソースデバイス５２０に接続された外部メディアソースであり得る。フレーム更新は、メディアデータの全フレーム、フレームの更新された部分のみを表す部分フレーム、または２つの何らかの組合せを含む場合がある。

[0131]フレーム更新を取り込んだ後、ディスプレイプロセッサ５３５は、最小サイズのＷＢバッファ５４０が一杯かどうかを判定するよう求める要求をＷＢバッファ５４０に送る（８０８）。最小サイズのＷＢバッファ５４０が一杯である場合（８０８のＹＥＳ分岐）、ディスプレイプロセッサ５３５から要求を受信すると、ＷＢバッファ５４０は、ＷＢバッファ５４０に保持されたより古いフレーム更新のうちの１つまたは複数を削除するようにトリガされる（８１０）。より古いフレーム更新を削除した後、ＷＢバッファ５４０は、ディスプレイプロセッサ５３５によって取り込まれた直近のフレーム更新をバッファリングする（８１２）。ディスプレイプロセッサ５２５から要求を受信したとき最小サイズのＷＢバッファ５４０が一杯でない場合（８０８のＮＯ分岐）、ＷＢバッファ５４０は、ディスプレイプロセッサ５３５によって取り込まれた直近のフレーム更新を直ちにバッファリングすることができる（８１２）。フレームバッファ５４２などの処理パイプライン５５０に沿った他の最小サイズのバッファ内のフレーム更新をバッファリングするために、同様のプロセスが使用され得る。直近のフレーム更新がＷＢバッファ５４０に保持されると、次いで、フレーム更新は、ハードウェア加速器５３６を介してＷＢバッファ５４０からメモリ５３２に書き込まれ得る。

[0132]加えて、ハードウェア加速器５３６は、ＷＢバッファ５４０からフレーム更新を取り出し、処理パイプライン５５０に沿った処理ユニットとバッファとの間を移動させる（８１４）。次いで、取り出されたフレーム更新は、ＷＤシステム内のシンクデバイスへの送信用に処理パイプライン５５０内で処理される（８１６）。たとえば、プロセッサ５３１内で、ビデオ処理エンジン（ＶＰＥ）５６０は、フレームバッファ５４２内にフレーム更新をレンダリングし、エンコーダ５６２は、フレームバッファ５４２からのフレーム更新を符号化する。符号化されたフレーム更新は、トランスポートユニット５３３内のパケッタイザ５６４でフレーム更新をパケット内に形成する前に、コード化ピクチャバッファ（ＣＰＢ）５４４にバッファリングされ得る。本技法によれば、符号化されたフレーム更新のメモリコピーをＣＰＢ５４４にバッファリングする代わりに、符号化されたフレーム更新のメモリコピーを作成せずに、メモリ５３２に記憶された符号化されたフレーム更新へのポインタがＣＰＢ５４４にバッファリングされ得る。

[0133]次いで、ワイヤレスモデム５３４は、ＷＤシステム内の通信セッションを介して、１つまたは複数のシンクデバイスに処理されたフレーム更新を送信する（８１８）。処理されたフレーム更新を送信した後、ワイヤレスモデム５３４は、新しいフレーム更新が送信用に受信されるまで、所定の時間期間後に、処理されたフレーム更新を再送信する（すなわち、重複プッシュを実行する）ことができる。重複プッシュは、シンクデバイスが送信されたフレーム更新を受信し、削除されたパケットを待つ処理時間を浪費しないことを保証することによって、ＷＤシステム内のエンドツーエンドの待ち時間を削減することができる。

[0134]図９は、処理パイプライン内のカスタマイズされたビデオ再生をサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャートである。図６に関して記載される。図示された動作は、図６からのシンクデバイス６６０に含まれる処理パイプライン６５０に関して記載される。他の例では、図示された動作は、図３からのシンクデバイス３６０、図１からのシンクデバイス１６０、またはＷＤシステムの別のシンクデバイスによって実行され得る。

[0135]シンクデバイス６６０は、最初にＷＤシステム内のソースデバイスと通信セッションを確立する（９００）。シンクデバイス６６０は、ソースデバイスとの能力交渉に従って通信セッションを確立することができる。本開示の技法によれば、処理パイプライン６５０内でカスタマイズされたビデオ再生をサポートするために、シンクデバイス６６０は、通信セッションについての能力交渉期間の間にメディアデータのストリーム用のストリームヘッダ情報をソースデバイスと交換する（９０２）。次いで、パイプラインマネージャ６３８は、受信されたストリームヘッダ情報に基づいて、シンクデバイス６６０内の処理パイプライン６５０を構成する（９０４）。

[0136]たとえば、ストリームヘッダ情報に基づいて、パイプラインマネージャ６３８は、ソースデバイスからメディアデータを受信するより前に、処理パイプライン６５０内のバッファサイズと、レンダリング開始タイマと、同期待ちタイマと、プログラマブルデコーダ設定などとを構成することができる。処理パイプライン６５０がメディアデータのストリーム用にシンクデバイス６５０内で構成されると、ワイヤレスモデム６３４は、シンクデバイス６６０へのメディアデータのストリームの送信を開始するようソースデバイスに通知することができる（９０６）。このようにして、復号およびレンダリングされるべきメディアデータをソースデバイスから受信すると、シンクデバイス６６０は、処理パイプライン線６５０をセットアップするいかなる処理時間も浪費しない。

[0137]処理パイプライン６５０が構成された後、シンクデバイス６６０は、ソースデバイスからのメディアデータの受信を開始する（９０８）。パーサ６８０は、符号化されたメディアデータをパケット化解除する。次いで、デコーダ６８２は、受信されたメディアデータを復号する（９１０）。受信されたメディアデータは、少なくともビデオデータを含む。復号すると、デコーダ６８２または処理パイプライン６５０内の他の何らかの処理ユニットは、復号されたメディアデータがオーディオデータを含むかどうかを検出する（９１２）。たとえば、デコーダ６８２は、メディアデータがオーディオデータを含むことを示す、受信されたメディアデータ内のオーディオタイムスタンプを検出することによって、メディアデータがオーディオデータを含むと判断することができる。同様に、デコーダ６８２は、受信されたメディアデータ内のオーディオタイムスタンプの不在に基づいて、メディアデータがビデオデータのみを含むと判断することができる。

[0138]オーディオデータがメディアデータに含まれていない場合(９１４のＮＯ分岐)、処理パイプライン６５０はビデオデータの加速されたレンダリングを実行する。より具体的には、パイプラインマネージャ６３８は、レンダラ６８４でビデオデータのオーディオデータとの同期を無効にする（９１６）。次いで、レンダラ６８４は、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングする（９１８）。場合によっては、メディアデータがビデオデータのみを含むとき、パイプラインマネージャ６３８は、明示的に同期を無効にすることはできないが、いかなるオーディオデータも無視し、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングするように、レンダラ６８４を構成することができる。加えて、パイプラインマネージャ６３８はまた、レンダラ６８４に適用可能なメディア時間に基づいて、ビデオデータのサンプル時間を増大させることができる。このようにして、レンダラ６８４は、増大されたサンプル時間に従って、ビデオデータの加速されたレンダリングを実行することができる。

[0139]オーディオデータがメディアデータに含まれている場合(９１４のＹＥＳ分岐)、パイプラインマネージャ６３８は、レンダラ６８４でのオーディオレンダリング開始タイマを削減することができる（９２０）。たとえば、いくつかの通信システムの場合、レンダラ６８４でのオーディオレンダリング開始タイマは、通信システムの初期化を補償するために高く保たれ得る。これはＷＤシステムに必要ではない。したがって、パイプラインマネージャ６３８は、オーディオデータがメディアデータに含まれているときでも、待ち時間を削減するために、ＷＤシステム用のオーディオレンダリング開始タイマを削減することができる。次いで、レンダラ６３８は、ビデオデータをオーディオデータと同期し（９２２）、削減された開始タイマに従って、同期されたビデオデータとオーディオデータとをレンダリングする（９２４）ことができる。

[0140]場合によっては、ビデオデータのフレームはデコーダ６８２内で失速し、レンダラ６８４がデコーダ６８２から次のビデオフレームを受信することを待つ、シンクデバイス６６０でのさらなる待ち時間をもたらす場合がある。本技法によれば、デコーダ６８２が非プログラマブルデコーダであるとき、パイプラインマネージャ６３８は、レンダリング用にデコーダ６８２からビデオデータの復号されたサンプルをプッシュするためにシンクデバイス６６０でビデオデータにダミーフレームを挿入することができる。デコーダ６８２がプログラマブルデコーダであるとき、パイプラインマネージャ６３８は、復号が完了するとすぐにレンダリング用に復号順序でビデオデータの復号されたサンプルを出力するように、プログラマブルデコーダ６８２を構成することができる。通常、デコーダは、デフォルトではサンプルを表示順序で出力する。この場合、パイプラインマネージャ６３８は、デコーダ６８２を介して復号されたフレームをより早く移動させるように、デフォルト設定を変更することができる。

[0141]加えて、ソースデバイスからメディアデータを受信すると、パイプラインマネージャ６３８は、受信されたメディアデータをレンダリングするより前に、受信されたメディアデータの１つまたは複数のサンプルをデコーダ６８２からフラッシュすることができる。場合によっては、ソースデバイスから送信された最初の数個のサンプルは、ソースデバイスでより古いメディアデータの失速したサンプルを含む場合がある。パイプラインマネージャ６３８は、これらのサンプルをシンクデバイス６６０からフラッシュして、古いメディアデータに対する処理時間およびリソースの消費を回避することができる。

[0142]図１０は、処理パイプライン内のメディアデータのアプリケーション認識に基づいて、カスタマイズされたバッファリングをサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャートである。図示された動作は、図６からのソースデバイス６６０に含まれる処理パイプライン６５０に関して記載される。他の例では、図示された動作は、図３からのシンクデバイス３６０、図１からのシンクデバイス１６０、またはＷＤシステムの別のシンクデバイスによって実行され得る。

[0143]シンクデバイス６６０は、最初にＷＤシステム内のソースデバイスと通信セッションを確立する（１０００）。シンクデバイス６６０は、ソースデバイスとの能力交渉に従って通信セッションを確立することができる。次いで、シンクデバイス６６０は、ソースデバイスからのメディアデータの受信を開始する（１０１０）。本開示の技法によれば、処理パイプライン６５０内のメディアデータ用のアプリケーションのタイプに基づいてカスタマイズされたバッファリングをサポートするために、シンクデバイス６６０は、受信されたメディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャ６３８は、アプリケーションのタイプに基づいて処理パイプライン６５０内のバッファのサイズを調整する。

[0144]受信されたメディアデータ用のアプリケーションのタイプを知るために、パーサ６８０は、最初にメディアデータ用のアプリケーションのタイプの指示がメディアデータとともにソースデバイスから受信されたかどうかを判定する（１０２０）。ソースデバイスから指示が受信された場合（１０２０のＹＥＳ分岐）、シンクデバイス６６０のデコーダ６８２は、ソースデバイスからの指示に基づいて、メディアデータ用のアプリケーションのタイプを知る（１０３０）。この場合、ＷＤシステム内のソースデバイスは、メディアデータ用のアプリケーションのタイプを検出し、メディアデータ用のアプリケーションのタイプの指示とともにメディアデータをシンクデバイス６６０に送信する。場合によっては、たとえば、シンクデバイス６６０は、ビデオ再生アプリケーション用のメディアデータのストリームの指示をソースデバイスから受信することができ、シンクデバイス６６０はまた、ビデオ再生アプリケーション用のメディアデータのストリームの終了の指示をソースデバイスから受信することができる。

[0145]ソースデバイスから指示が受信されなかった場合（１０２０のＮＯ分岐）、シンクデバイス６６０のデコーダ６８２は、メディアデータ内のオーディオタイムスタンプの存在または不在に基づいて、メディアデータ用のアプリケーションのタイプを知る（１０４０）。たとえば、デコーダ６８２は、メディアデータ内の一定の間隔でオーディオタイムスタンプを検出することによって、メディアデータがビデオ再生アプリケーション用であると判断することができる。別の例として、デコーダ６８２は、受信されたメディアデータ内の一定の間隔でのオーディオタイムスタンプの不在に基づいて、メディアデータがＵＩアプリケーションまたはゲームアプリケーション用であると判断することができる。

[0146]受信されたメディアデータ用のアプリケーションのタイプがＵＩアプリケーションまたはゲームアプリケーションであり、ビデオ再生アプリケーションではないことをシンクデバイス６６０のデコーダ６８２が知ったとき（１０５０のＮＯ分岐）、パイプラインマネージャ６３８は、ＵＩアプリケーションまたはゲームアプリケーション内の表示の前に、処理パイプライン６５０内でメディアデータを保持するバッファのサイズを減少させるように、処理パイプライン６５０を構成する（１０６０）。たとえば、パイプラインマネージャ６３８は、バッファを通り抜けるメディアデータの待ち時間を削減するためにレンダリングキュー６９４のサイズおよび／またはフレームバッファ６９６のサイズを減少させることができる。ＵＩアプリケーションまたはゲームアプリケーションの場合、ＷＤシステム内の主な関心事は低遅延のユーザ体験を提供することであり、ビデオの再生品質はより低い関心事である。

[0147]受信されたメディアデータ用のアプリケーションのタイプがビデオ再生アプリケーションであることをシンクデバイス６６０のデコーダ６８２が知ったとき（１０５０のＹＥＳ分岐）、パイプラインマネージャ６３８は、ビデオ再生アプリケーション内の表示の前に、処理パイプライン６５０内でメディアデータを保持するバッファのサイズを増大させることができる（１０７０）。たとえば、パイプラインマネージャ６３８は、ビデオ再生アプリケーション内のビデオ再生の品質（すなわち、滑らかさ）を改善するためにレンダリングキュー６９４のサイズおよび／またはフレームバッファ６９６のサイズを増大させることができる。バッファサイズを増大させると待ち時間が増大する場合があるが、ビデオ再生アプリケーションの場合の主な関心事は、増大した待ち時間の何らかのトレードオフを伴う高い品質のビデオ再生ユーザ体験を提供することである。

[0148]レンダラ６８４は、メディアデータ用に示されたアプリケーションのタイプでの使用のために、レンダリングキュー６９４からのメディアデータを処理パイプライン６５０内のフレームバッファ６９６内にレンダリングする（１０８０）。次いで、ディスプレイプロセッサ６３５は、フレームバッファ６９６からのレンダリングされたメディアデータを、シンクデバイス６６０で動作するメディアデータ用のアプリケーション内で表示する（１０９０）。

[0149]場合によっては、メディアデータがビデオ再生アプリケーション用であるとき、パイプラインマネージャ６３８は、シンクデバイス６６０がメディアデータのさらなるサンプルを受信するために、レンダリングキュー６９４からのメディアデータのレンダリングを休止するように、レンダラ６８４に指示することができる。次いで、パイプラインマネージャ６３８は、メディアデータのしきい値の数のサンプルがレンダリングキュー６９４に記憶された後、レンダリングキュー６９４からのメディアデータのレンダリングを再開するようにレンダラ６８４に指示する。このようにして、ビデオ再生の品質または滑らかさは、レンダリングされる用意ができたメディアデータの複数のサンプルをレンダリングキュー６９４内に有することによって、さらに改善され得る。

[0150]図１１は、ＷＤシステム内のオーディオデータの優先トランスポートをサポートすることが可能なソースデバイスおよびシンクデバイスの例示的な動作を示すフローチャートである。図示された動作は、図５からのソースデバイス５２０内の処理パイプライン５５０に関して、かつ図６からのシンクデバイス６６０に含まれる処理パイプライン６５０に関して記載される。他の例では、図示された動作は、図２からのソースデバイス２２０、図３からのシンクデバイス３６０、図１からのソースデバイス１２０およびシンクデバイス１６０、またはＷＤシステムの他のソースデバイスおよびシンクデバイスによって実行され得る。

[0151]ソースデバイス５２０は、最初にＷＤシステム内のシンクデバイス６６０と通信セッションを確立する（１１００）。ソースデバイス５２０およびシンクデバイス６６０は、能力交渉に基づいて通信セッションを確立することができる。本開示の技法によれば、オーディオデータの優先トランスポートを提供するために、ソースデバイス５２０内のパイプラインマネージャ５３８は、処理パイプライン５５０内のビデオ経路よりも多くのバッファリングを含むように、処理パイプライン５５０内のオーディオ経路を構成する（１１１０）。加えて、ソースデバイス５２０内のパイプラインマネージャ５３８は、ワイヤレスモデムソケット５７０内のビデオトランスポートキューよりも高い優先度を有するワイヤレスモデムソケット５７０内のオーディオトランスポートキューを構成する（１１２０）。

[0152]オーディオデータ用の優先トランスポート経路が構成されると、ソースデバイス５２０は、別々の処理パイプライン経路内で、オーディオデータとビデオデータの処理を開始する（１１３０）。オーディオデータとビデオデータが処理されると、ワイヤレスモデム５３４は、ソケット５７０内の別々のトランスポートキューから、オーディオデータと関連するビデオデータとをシンクデバイス６６０にトランスポートする（１１４０）。

[0153]シンクデバイス６６０は、ＷＤシステム内の通信チャネルを介してソースデバイス５２０から、オーディオデータと関連するビデオデータとを受信する（１１５０）。シンクデバイス６６０のプロセッサ６３１は、受信されたメディアデータに基づいて、通信チャネルのトランスポート状態を判断することができる（１１６０）。たとえば、シンクデバイス６６０のプロセッサ６３１は、通信チャネルを介したトランスポート後にメディアデータについての誤り率とパケット損失の量とを判断することができる。シンクデバイス６６０のトランスポートユニット６３１は、パケットを生成して、通信チャネルのトランスポート状態を記述するフィードバック情報を、シンクデバイス６６０からソースデバイス５２０に送信することができる（１１７０）。たとえば、ワイヤレスモデム６３４は、ＲＴＣＰを使用して、ＵＩＢＣまたは他のフィードバックチャネルを介してシンクデバイス６６０からソースデバイス６６０にパケットを送信することができる。

[0154]通信チャネルのトランスポート状態を記述するフィードバック情報を受信すると、ソースデバイス５２０のパイプラインマネージャ５３８は、シンクデバイス６６０からのフィードバック情報に基づいて、処理パイプライン５５０を修正することができる（１１８０）。処理パイプライン５５０が通信チャネル用に構成されると、ソースデバイス５２０は、別々の処理パイプライン経路内でのオーディオデータとビデオデータの処理（１１３０）と、ソケット５７０内の別々のトランスポートキューからのオーディオデータおよび関連するビデオデータのシンクデバイス６６０へのトランスポート（１１４０）とを再開する。

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

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

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

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

[0159]本発明の様々な実施形態が記載された。これらおよび他の実施形態は、以下の特許請求の範囲内に入る。

Claims (46)

1. ワイヤレスディスプレイ（ＷＤ）システムにおいてソースデバイスとシンクデバイスで通信セッションを確立することと、
   前記シンクデバイスを用いて前記ソースデバイスからメディアデータを受信することと、ここにおいて、前記メディアデータは少なくともビデオデータを含む、
   前記シンクデバイスの処理パイプラインを用いて前記受信されたメディアデータを復号することと、
   前記復号されたメディアデータがオーディオデータを含むかどうかを検出することと、
   前記復号されたメディアデータがオーディオデータを含まないとき、前記シンクデバイスの前記処理パイプラインを用いて前記ビデオデータの加速されたレンダリングを実行することと
   を備える、方法。
2. 前記ビデオデータの加速されたレンダリングを実行することが、前記処理パイプラインに含まれるレンダラでの同期を無効にすることと、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングすることとを備える、請求項１に記載の方法。
3. 前記ビデオデータの加速されたレンダリングを実行することが、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするように、前記処理パイプラインに含まれるレンダラを構成することを備える、請求項１に記載の方法。
4. 前記ビデオデータの加速されたレンダリングを実行することが、前記処理パイプラインに含まれるレンダラに適用可能なメディア時間に基づいて、前記ソースデバイスから受信された前記ビデオデータのサンプル時間を増大させることと、前記増大されたサンプル時間に従って前記ビデオデータをレンダリングすることとを備える、請求項１に記載の方法。
5. 前記受信されたメディアデータがオーディオデータを含むかどうかを検出することが、前記受信されたメディアデータ内のオーディオタイムスタンプの存在または不在のうちの１つを検出することを備え、ここにおいて、前記オーディオタイムスタンプの前記存在が、前記メディアデータがオーディオデータを含むことを示す、請求項１に記載の方法。
6. 前記メディアデータを受信するより前に前記通信セッションについての能力交渉期間の間、前記ソースデバイスからストリームヘッダ情報を受信することと、
   前記ストリームヘッダ情報に基づいて前記シンクデバイスの前記処理パイプラインを構成することと、
   前記処理パイプラインが構成された後、前記メディアデータの送信を開始するように前記ソースデバイスに通知することと
   をさらに備える、請求項１に記載の方法。
7. 前記ストリームヘッダ情報に基づいて前記処理パイプラインを構成することが、バッファサイズ、レンダリング開始タイマ、同期待ちタイマ、およびプログラマブルデコーダ設定のうちの１つまたは複数を構成することを備える、請求項８に記載の方法。
8. 前記受信されたメディアデータがオーディオデータを含むとき、
   前記シンクデバイスの前記処理パイプラインに含まれるレンダラ用のオーディオレンダリング開始タイマを削減することと、
   前記オーディオデータと前記ビデオデータを同期することと、
   前記削減された開始タイマに従って前記同期されたオーディオデータとビデオデータとをレンダリングすることと
   をさらに備える、請求項１に記載の方法。
9. 前記シンクデバイスの前記処理パイプラインがプログラマブルではないデコーダを含み、レンダリング用に前記デコーダから前記ビデオデータの前記復号されたサンプルをプッシュするために前記シンクデバイスで前記ビデオデータ内にダミーフレームを挿入することをさらに備える、請求項１に記載の方法。
10. 前記シンクデバイスの前記処理パイプラインがプログラマブルデコーダを含み、復号が完了するとすぐにレンダリング用に復号順序で前記ビデオデータの前記復号されたサンプルを出力するように、前記プログラマブルデコーダを構成することをさらに備える、請求項１に記載の方法。
11. 前記ソースデバイスから前記メディアデータを受信すると、前記受信されたメディアデータをレンダリングするより前に、前記シンクデバイスの前記処理パイプラインに含まれるデコーダから前記受信されたメディアデータの１つまたは複数のサンプルをフラッシュすることをさらに備え、ここにおいて、前記１つまたは複数のサンプルが、前記ソースデバイスからの古いメディアデータの失速したサンプルを備える、請求項１に記載の方法。
12. 前記ソースデバイスにトランスポートチャネル状態を記述するフィードバック情報を送信することをさらに備え、ここにおいて、前記フィードバック情報が、前記ソースデバイスの処理パイプラインを修正するために使用される、請求項１に記載の方法。
13. 前記シンクデバイスで前記通信セッションを確立することが、前記ソースデバイスから前記通信セッション用の前記メディアデータの広告を受信することと、前記ソースデバイスに前記通信セッションへの参加の要求を送ることとを備える、請求項１に記載の方法。
14. ワイヤレスディスプレイ（ＷＤ）システムにおいてソースデバイスとシンクデバイスで通信セッションを確立することと、前記ソースデバイスからメディアデータを受信することであって、ここにおいて、前記メディアデータは少なくともビデオデータを含む、受信することと、前記受信されたメディアデータを復号することと、前記受信されたメディアデータがオーディオデータを含むかどうかを検出することと、前記受信されたメディアデータがオーディオデータを含まないとき、前記ビデオデータの加速されたレンダリングを実行することとを行うように構成された１つまたは複数の処理ユニットを含む処理パイプラインと、
    前記シンクデバイスの前記処理パイプラインを管理するように構成されたパイプラインマネージャと
    を備える、シンクデバイス。
15. 前記受信されたメディアデータがオーディオデータを含まないとき、前記パイプラインマネージャが、前記処理パイプラインに含まれるレンダラでの同期を無効にし、および、ここにおいて、前記処理パイプラインの前記１つまたは複数の処理ユニットが、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするように構成された、請求項１４に記載のシンクデバイス。
16. 前記受信されたメディアデータがオーディオデータを含まないとき、前記パイプラインマネージャが、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするように、前記処理パイプラインに含まれるレンダラを構成する、請求項１４に記載のシンクデバイス。
17. 前記パイプラインマネージャが、前記処理パイプラインに含まれるレンダラに適用可能なメディア時間に基づいて、前記ソースデバイスから受信された前記ビデオデータのサンプル時間を増大させ、および、ここにおいて、前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記増大されたサンプル時間に従って前記ビデオデータをレンダリングするように構成された、請求項１４に記載のシンクデバイス。
18. 前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記受信されたメディアデータ内のオーディオタイムスタンプの存在または不在のうちの１つを検出するように構成され、ここにおいて、前記オーディオタイムスタンプの前記存在が、前記メディアデータがオーディオデータを含むことを示す、請求項１４に記載のシンクデバイス。
19. 前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記メディアデータを受信するより前に前記通信セッションについての能力交渉期間の間、前記ソースデバイスからストリームヘッダ情報を受信するように構成され、
    前記パイプラインマネージャが、前記ストリームヘッダ情報に基づいて前記シンクデバイスの前記処理パイプラインを構成し、
    前記処理パイプラインが構成された後、前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記メディアデータの送信を開始するように前記ソースデバイスに通知するように構成された、
    請求項１４に記載のシンクデバイス。
20. 前記パイプラインマネージャが、前記処理パイプライン用のプログラマブルデコーダ設定、同期待ちタイマ、レンダリング開始タイマ、および、バッファサイズのうちの１つまたは複数を構成する、請求項１９に記載のシンクデバイス。
21. 前記受信されたメディアデータがオーディオデータを含むとき、前記パイプラインマネージャが、前記シンクデバイスの前記処理パイプラインに含まれるレンダラ用のオーディオレンダリング開始タイマを削減し、および、ここにおいて、前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記オーディオデータと前記ビデオデータを同期し、前記削減された開始タイマに従って前記同期されたオーディオデータとビデオデータとをレンダリングするように構成された、請求項１４に記載のシンクデバイス。
22. 前記処理パイプラインに含まれるプログラマブルではないデコーダをさらに備え、ここにおいて、前記処理パイプラインの前記１つまたは複数の処理ユニットが、レンダリング用に前記デコーダから前記ビデオデータの前記復号されたサンプルをプッシュするために前記シンクデバイスで前記ビデオデータ内にダミーフレームを挿入するように構成された、請求項１４に記載のシンクデバイス。
23. 前記処理パイプラインに含まれるプログラマブルデコーダをさらに備え、ここにおいて、前記パイプラインマネージャが、復号が完了するとすぐにレンダリング用に復号順序で前記ビデオデータの前記復号されたサンプルを出力するように、前記プログラマブルデコーダを構成する、請求項１４に記載のシンクデバイス。
24. 前記ソースデバイスから前記メディアデータを受信すると、前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記受信されたメディアデータをレンダリングするより前に、前記シンクデバイスの前記処理パイプラインに含まれるデコーダから前記受信されたメディアデータの１つまたは複数のサンプルをフラッシュするように構成され、ここにおいて、前記１つまたは複数のサンプルが、前記ソースデバイスからの古いメディアデータの失速したサンプルを備える、請求項１４に記載のシンクデバイス。
25. 前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記ソースデバイスにトランスポートチャネル状態を記述するフィードバック情報を送信するように構成され、ここにおいて、前記フィードバック情報が、前記ソースデバイスの処理パイプラインを修正するために使用される、請求項１４に記載のシンクデバイス。
26. 前記処理パイプラインの前記１つまたは複数の処理ユニットが、前記ソースデバイスから前記通信セッション用の前記メディアデータの広告を受信し、前記シンクデバイスで前記通信セッションを確立するために前記ソースデバイスに前記通信セッションへの参加の要求を送るように構成された、請求項１５に記載のシンクデバイス。
27. ワイヤレスディスプレイ（ＷＤ）システムにおいてソースデバイスとシンクデバイスで通信セッションを確立するための手段と、
    前記ソースデバイスからメディアデータを受信するための手段と、ここにおいて、前記メディアデータは少なくともビデオデータを含む、
    前記シンクデバイスの処理パイプラインを用いて前記受信されたメディアデータを復号するための手段と、
    前記受信されたメディアデータがオーディオデータを含むかどうかを検出するための手段と、
    前記受信されたメディアデータがオーディオデータを含まないとき、前記シンクデバイスの前記処理パイプラインを用いて前記ビデオデータの加速されたレンダリングを実行するための手段と
    を備える、シンクデバイス。
28. 前記受信されたメディアデータがオーディオデータを含まないとき、前記処理パイプラインに含まれるレンダラでの同期を無効にするための手段と、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするための手段とをさらに備える、請求項２７に記載のシンクデバイス。
29. 前記受信されたメディアデータがオーディオデータを含まないとき、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするように、前記処理パイプラインに含まれるレンダラを構成するための手段をさらに備える、請求項２７に記載のシンクデバイス。
30. 前記処理パイプラインに含まれるレンダラに適用可能なメディア時間に基づいて、前記ソースデバイスから受信された前記ビデオデータのサンプル時間を増大させるための手段と、前記増大されたサンプル時間に従って前記ビデオデータをレンダリングするための手段とをさらに備える、請求項２７に記載のシンクデバイス。
31. 前記受信されたメディアデータ内のオーディオタイムスタンプの存在または不在のうちの１つを検出するための手段をさらに備え、ここにおいて、前記オーディオタイムスタンプの前記存在が、前記メディアデータがオーディオデータを含むことを示す、請求項２７に記載のシンクデバイス。
32. 前記メディアデータを受信するより前に前記通信セッションについての能力交渉期間の間、前記ソースデバイスからストリームヘッダ情報を受信するための手段と、
    前記ストリームヘッダ情報に基づいて前記シンクデバイスの前記処理パイプラインを構成するための手段と、
    前記処理パイプラインが構成された後、前記メディアデータの送信を開始するように前記ソースデバイスに通知するための手段と
    をさらに備える、請求項２７に記載のシンクデバイス。
33. 前記受信されたメディアデータがオーディオデータを含むとき、
    前記シンクデバイスの前記処理パイプラインに含まれるレンダラ用のオーディオレンダリング開始タイマを削減するための手段と、
    前記オーディオデータと前記ビデオデータを同期するための手段と、
    前記削減された開始タイマに従って前記同期されたオーディオデータとビデオデータとをレンダリングするための手段と
    をさらに備える、請求項２７に記載のシンクデバイス。
34. 前記シンクデバイスの前記処理パイプラインがプログラマブルではないデコーダを含み、レンダリング用に前記デコーダから前記ビデオデータの前記復号されたサンプルをプッシュするために前記シンクデバイスで前記ビデオデータ内にダミーフレームを挿入するための手段をさらに備える、請求項２７に記載のシンクデバイス。
35. 前記シンクデバイスの前記処理パイプラインがプログラマブルデコーダを含み、復号が完了するとすぐにレンダリング用に復号順序で前記ビデオデータの前記復号されたサンプルを出力するように、前記プログラマブルデコーダを構成するための手段をさらに備える、請求項２７に記載のシンクデバイス。
36. 前記ソースデバイスから前記メディアデータを受信すると、前記受信されたメディアデータをレンダリングするより前に、前記シンクデバイスの前記処理パイプラインに含まれるデコーダから前記受信されたメディアデータの１つまたは複数のサンプルをフラッシュするための手段をさらに備え、ここにおいて、前記１つまたは複数のサンプルが、前記ソースデバイスからの古いメディアデータの失速したサンプルを備える、請求項２７に記載のシンクデバイス。
37. シンクデバイス内で実行されたとき、
    ワイヤレスディスプレイ（ＷＤ）システムにおいてソースデバイスと前記シンクデバイスで通信セッションを確立することと、
    前記ソースデバイスからメディアデータを受信することと、ここにおいて、前記メディアデータが少なくともビデオデータを含む、
    前記シンクデバイスの処理パイプラインを用いて前記受信されたメディアデータを復号することと、
    前記受信されたメディアデータがオーディオデータを含むかどうかを検出することと、
    前記受信されたメディアデータがオーディオデータを含まないとき、前記シンクデバイスの前記処理パイプラインを用いて前記ビデオデータの加速されたレンダリングを実行することと
    をプログラマブルプロセッサに行わせる命令を備える、コンピュータ可読媒体。
38. 前記受信されたメディアデータがオーディオデータを含まないとき、前記命令が、前記処理パイプラインに含まれるレンダラでの同期を無効にすることと、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングすることとを前記プログラマブルプロセッサに行わせる、請求項３７に記載のコンピュータ可読媒体。
39. 前記受信されたメディアデータがオーディオデータを含まないとき、前記命令が、オーディオデータとの同期を待たずに前記ビデオデータをレンダリングするように、前記処理パイプラインに含まれるレンダラを構成することを前記プログラマブルプロセッサに行わせる、請求項３７に記載のコンピュータ可読媒体。
40. 前記命令が、前記処理パイプラインに含まれるレンダラに適用可能なメディア時間に基づいて、前記ソースデバイスから受信された前記ビデオデータのサンプル時間を増大させることと、前記増大されたサンプル時間に従って前記ビデオデータをレンダリングすることとを前記プログラマブルプロセッサに行わせる、請求項３７に記載のコンピュータ可読媒体。
41. 前記命令が、前記受信されたメディアデータ内のオーディオタイムスタンプの存在または不在のうちの１つを検出することを前記プログラマブルプロセッサに行わせ、ここにおいて、前記オーディオタイムスタンプの前記存在が、前記メディアデータがオーディオデータを含むことを示す、請求項３７に記載のコンピュータ可読媒体。
42. 前記メディアデータを受信するより前に前記通信セッションについての能力交渉期間の間、前記ソースデバイスからストリームヘッダ情報を受信することと、
    前記ストリームヘッダ情報に基づいて前記シンクデバイスの前記処理パイプラインを構成することと、
    前記処理パイプラインが構成された後、前記メディアデータの送信を開始するように前記ソースデバイスに通知することと
    を前記プログラマブルプロセッサに行わせる命令をさらに備える、請求項３７に記載のコンピュータ可読媒体。
43. 前記受信されたメディアデータがオーディオデータを含むとき、
    前記シンクデバイスの前記処理パイプラインに含まれるレンダラ用のオーディオレンダリング開始タイマを削減することと、
    前記オーディオデータと前記ビデオデータを同期することと、
    前記削減された開始タイマに従って前記同期されたオーディオデータとビデオデータとをレンダリングすることと
    を前記プログラマブルプロセッサに行わせる命令をさらに備える、請求項３７に記載のコンピュータ可読媒体。
44. 前記シンクデバイスの前記処理パイプラインがプログラマブルではないデコーダを含み、レンダリング用に前記デコーダから前記ビデオデータの前記復号されたサンプルをプッシュするために前記シンクデバイスで前記ビデオデータ内にダミーフレームを挿入することを前記プログラマブルプロセッサに行わせる命令をさらに備える、請求項３７に記載のコンピュータ可読媒体。
45. 前記シンクデバイスの前記処理パイプラインがプログラマブルデコーダを含み、復号が完了するとすぐにレンダリング用に復号順序で前記ビデオデータの前記復号されたサンプルを出力するように、前記プログラマブルデコーダを構成することを前記プログラマブルプロセッサに行わせる命令をさらに備える、請求項３７に記載のコンピュータ可読媒体。
46. 前記ソースデバイスから前記メディアデータを受信すると、前記受信されたメディアデータをレンダリングするより前に、前記シンクデバイスの前記処理パイプラインに含まれるデコーダから前記受信されたメディアデータの１つまたは複数のサンプルをフラッシュすることを前記プログラマブルプロセッサに行わせる命令をさらに備え、ここにおいて、前記１つまたは複数のサンプルが、前記ソースデバイスからの古いメディアデータの失速したサンプルを備える、請求項３７に記載のコンピュータ可読媒体。

Images