[0024]本開示では、ワイヤレスディスプレイ(WD)システム内のユーザ体験を改善する技法が記載される。WDシステムは、メディアデータ、たとえば、オーディオデータおよび/またはビデオデータを再生用の1つまたは複数のシンクデバイスに供給するソースデバイスを含む。本技法は、シンクデバイスでのビデオの再生品質(すなわち、滑らかさ)を改善しながら、ソースデバイスとシンクデバイスとの間のメディアデータのエンドツーエンドの待ち時間を削減することに関する。
[0025]一例では、本技法は、WDシステムのソースデバイスでの低遅延の画面取込みとバッファリングとを含む。たとえば、WDシステム内で通信セッションを確立すると、パイプラインマネージャは、待ち時間を削減するために処理ステップ間で最小サイズのバッファを含むように、ソースデバイスの処理パイプラインを構成することができる。次いで、ソースデバイスは、メディアデータの少なくとも直近のフレーム更新を最小サイズのバッファにバッファリングし、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除する。加えて、処理パイプラインは、ソースデバイスのパイプライン処理を用いた処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。ハードウェア加速の使用は、フレームレートを増大させ、待ち時間を削減させるためのソースデバイスの中央処理装置(CPU)上の処理負荷を低減することができる。ソースデバイスはまた、シンクデバイスによる時宜を得た受信を保証して、WDシステム内の待ち時間をさらに削減するために、符号化されたフレーム更新を再送信する(すなわち、重複プッシュを実行する)ことができる。
[0026]別の例では、本技法は、ソースデバイスから受信されたメディアデータのタイプに基づく、WDシステムのシンクデバイスでのカスタマイズされた再生を含む。メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイスの処理パイプラインに含まれるレンダラは、ビデオデータの加速されたレンダリングを実行するように構成される。たとえば、メディアデータがオーディオデータを含まないことを検出すると、パイプラインマネージャは、シンクデバイスの処理パイプラインに含まれるレンダラでの同期を無効にして、存在しないオーディオデータとの同期を待たずに、レンダラがビデオデータをレンダリングすることを可能にすることができる。別の例として、メディアデータがビデオデータとオーディオデータの両方を含むことを検出すると、パイプラインマネージャは、オーディオレンダリング開始タイマを削減することができ、その結果、レンダラは削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。加えて、パイプラインマネージャは、セットアップ時間に起因する待ち時間を削減するために、通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に、シンクデバイス内の処理パイプラインを構成することができる。
[0027]さらなる一例では、本技法は、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づく、WDシステムのシンクデバイスでのカスタマイズされたバッファリングを含む。シンクデバイスは、メディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャは、シンクデバイスの処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現する。場合によっては、メディアデータ用のアプリケーションのタイプは、ソースデバイスで検出され得、シンクデバイスは、ソースデバイスから受信された情報に基づいて、アプリケーションのタイプを知ることができる。他の場合、シンクデバイスは、アプリケーションのタイプ自体を検出することによって、メディアデータ用のアプリケーションのタイプを知ることができる。たとえば、メディアデータが、再生の品質または滑らかさがシンクデバイスで最も優先度が高く、上述された低遅延技法は目に見えるジッタをもたらす場合がある、ビデオ再生アプリケーション用であるとき、バッファサイズは増大されて、ビデオ再生アプリケーション用内のメディアデータの滑らかさを増大させる。反対に、メディアデータが、低遅延がシンクデバイスで最も優先度が高い、ユーザインターフェース(UI)アプリケーションまたはゲームアプリケーション用であるとき、バッファサイズは減少されて、UIアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。
[0028]本技法はまた、WDシステム内のソースデバイスとシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャは、ソースデバイス内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。加えて、ソースデバイスでのワイヤレスモデムソケットは、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。さらなるバッファリングにより、ソースデバイスで削除されるオーディオパケットがより少なくなることが保証される。より高い優先度のトランスポートキューにより、ビデオパイプライン経路内の遅延または失速(stall)を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイスでトランスポート用にキューイングされることが保証される。加えて、シンクデバイスは、ソースデバイスに通信チャネルのトランスポート状態を記述するフィードバック情報を供給することができ、パイプラインマネージャは、フィードバック情報に基づいてソースデバイスの処理パイプラインを修正することができる。
[0029]図1は、本開示の技法をサポートして、ビデオの再生品質を改善しながらソースデバイス120とシンクデバイス160との間のエンドツーエンドの待ち時間を削減することが可能なソースデバイス120とシンクデバイス160とを含むワイヤレスディスプレイ(WD)システム100の例を示すブロック図である。図1に示されるように、WDシステム100は、通信チャネル150を介してシンクデバイス160と通信するソースデバイス120を含む。
[0030]ソースデバイス120は、オーディオおよび/またはビデオ(A/V)メディアデータ121を記憶するメモリと、ディスプレイ122と、スピーカ123と、(エンコーダ124とも呼ばれる)オーディオおよび/またはビデオ(A/V)エンコーダ124と、オーディオおよび/またはビデオ(A/V)制御モジュール125と、送信機/受信機(TX/RX)ユニット126とを含むことができる。シンクデバイス160は、ディスプレイ162と、スピーカ163と、(デコーダ164とも呼ばれる)オーディオおよび/またはビデオ(A/V)デコーダ164と、送信機/受信機ユニット166と、ユーザ入力(UI)デバイス167と、ユーザ入力処理モジュール(UIPM)168とを含むことができる。図示された構成要素は、WDシステム100の1つの例示的な構成をなすにすぎない。他の構成は、図示された構成要素よりも少ない構成要素を含む場合があるか、または図示された構成要素以外のさらなる構成要素を含む場合がある。
[0031]図1の例では、ソースデバイス120は、A/Vメディアデータ121のビデオ部分をディスプレイ122に表示することができ、A/Vメディアデータ121のオーディオ部分をスピーカ123に出力することができる。A/Vメディアデータ121は、ソースデバイス120にローカルに記憶されるか、ファイルサーバ、ハードドライブ、外部メモリ、ブルーレイ(登録商標)ディスク、DVD、もしくは他の物理記憶媒体などの外部記憶媒体からアクセスされるか、またはインターネットなどのネットワーク接続を介してソースデバイス120にストリーミングすることができる。場合によっては、A/Vメディアデータ121は、ソースデバイス120のカメラとマイクロフォンとを介して、リアルタイムにキャプチャすることができる。A/Vメディアデータ121は、映画、テレビ番組、または音楽などのマルチメディアコンテンツを含むことができるが、ソースデバイス120によって生成されたリアルタイムコンテンツも含むことができる。そのようなリアルタイムコンテンツは、たとえば、ソースデバイス120で動作しているアプリケーションによって生成されるか、または、たとえば、ビデオテレフォニーセッションの一部としてキャプチャされたビデオデータであり得る。場合によっては、そのようなリアルタイムコンテンツは、ユーザが選択する場合に利用可能なユーザ入力オプションのビデオフレームを含むことができる。場合によっては、A/Vメディアデータ121は、ビデオのフレーム上にオーバーレイされたユーザ入力オプションを有する映画またはTV番組のビデオフレームなどの、異なるタイプのコンテンツの組合せであるビデオフレームを含むことができる。
[0032]ディスプレイ122とスピーカ123とを介してローカルにA/Vメディアデータ121をレンダリングすることに加えて、ソースデバイス120のA/Vエンコーダ124は、A/Vメディアデータ121を符号化することができ、送信機/受信機ユニット126は、通信チャネル150を介してシンクデバイス160に符号化されたデータを送信することができる。シンクデバイス160の送信機/受信機ユニット166は、符号化されたデータを受信し、A/Vデコーダ164は、符号化されたデータを復号し、ディスプレイ162とスピーカ163とを介して復号されたデータを出力する。このようにして、ディスプレイ122およびスピーカ123によってレンダリングされているオーディオおよびビデオデータは、同時にディスプレイ162およびスピーカ163によってレンダリングすることができる。オーディオデータおよびビデオデータはフレームに構成することができ、オーディオフレームは、レンダリングされるときにビデオフレームと時刻同期することができる。
[0033]A/Vエンコーダ124およびA/Vデコーダ164は、代替的にMPEG−4,Part 10,Advanced Video Coding(AVC)と呼ばれるITU−T H.264規格、または新興の高効率ビデオコーディング(HEVC)規格などの任意の数のオーディオおよびビデオ圧縮規格を実装することができる。多くの他のタイプのプロプライエタリな、または規格化された圧縮技法も使用することができる。概して、A/Vデコーダ164は、A/Vエンコーダ124の逆のコーディング演算を実行するように構成される。図1には示されないが、いくつかの態様では、A/Vエンコーダ124およびA/Vデコーダ164は、各々オーディオのエンコーダおよびデコーダと統合することができ、共通のデータストリームまたは別々のデータストリーム内のオーディオとビデオの両方の符号化を処理するために、適切なMUX−DEMUXユニット、または他のハードウェアとソフトウェアとを含むことができる。
[0034]A/Vエンコーダ124は、上述のようなビデオ圧縮規格を実装することに加えて、他の符号化機能も実行することができる。たとえば、A/Vエンコーダ124は、A/Vデータメディア121がシンクデバイス160に送信されるより前に、A/Vメディアデータ121に様々なタイプのメタデータを追加することができる。場合によっては、A/Vメディアデータ121は、符号化された形態でソースデバイス120に記憶されるかまたはソースデバイス120で受信され、したがってA/Vエンコーダ124によるさらなる圧縮を必要としない場合がある。
[0035]図1は、オーディオペイロードデータとビデオペイロードデータとを別々に搬送する通信チャネル150を示すが、場合によっては、ビデオペイロードデータとオーディオペイロードデータは共通のデータストリームの一部であり得ることを理解されたい。適用可能な場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。A/Vエンコーダ124およびA/Vデコーダ164は、各々1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せとして実装することができる。A/Vエンコーダ124およびA/Vデコーダ164の各々は、1つまたは複数のエンコーダまたはデコーダに含まれ、それらのいずれかは、複合エンコーダ/デコーダ(コーデック)の一部として統合することができる。したがって、ソースデバイス120およびシンクデバイス160の各々は、本開示の技法のうちの1つまたは複数を実行するように構成された専用の機械を備えることができる。
[0036]ディスプレイ122およびディスプレイ162は、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、発光ダイオード(LED)ディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの様々なビデオ出力デバイスのうちのいずれも備えることができる。これらまたは他の例では、ディスプレイ122および162は、各々発光型ディスプレイまたは透過型ディスプレイであり得る。ディスプレイ122およびディスプレイ162はまた、それらが同時に入力デバイスとディスプレイデバイスの両方であるようなタッチディスプレイであり得る。そのようなタッチディスプレイは、ユーザがそれぞれのデバイスにユーザ入力を与えることを可能にする、静電容量式、抵抗式、または他のタイプのタッチパネルであり得る。
[0037]スピーカ123は、ヘッドフォン、シングルスピーカシステム、マルチスピーカシステム、またはサラウンドサウンドシステムなどの様々なオーディオ出力デバイスのうちのいずれも備えることができる。加えて、ディスプレイ122およびスピーカ123はソースデバイス120の一部として示され、ディスプレイ162およびスピーカ163はシンクデバイス160の一部として示されているが、ソースデバイス120およびシンクデバイス160は、実際はそれらのデバイスのシステムであり得る。一例として、ディスプレイ162はテレビジョンであり得るし、スピーカ163はサラウンドサウンドシステムであり得るし、デコーダ164は有線またはワイヤレスのいずれかでディスプレイ162とスピーカ163とに接続された外部ボックスの一部であり得る。他の例では、シンクデバイス160は、タブレットコンピュータまたはスマートフォンなどの単一デバイスであり得る。さらに他の場合では、ソースデバイス120およびシンクデバイス160は、同様のデバイス、たとえば両方ともスマートフォン、タブレットコンピュータなどである。この場合、一方のデバイスがソースとして動作することができ、他方がシンクとして動作することができる。これらの役割は、以後の通信セッションでは反転される場合さえある。さらに他の場合、ソースデバイスは、スマートフォン、ラップトップコンピュータまたはタブレットコンピュータなどのモバイルデバイスを備えることができ、シンクデバイスは、(たとえば、AC電源コードを有する)より固定されたデバイスを備えることができ、その場合、ソースデバイスは、シンクデバイスを介して大群衆に提示用のオーディオおよびビデオデータを配信することができる。
[0038]送信機/受信機ユニット126および送信機/受信機ユニット166は、各々様々なミキサ、フィルタ、増幅器、および信号変調用に設計された他の構成要素、ならびに、1つまたは複数のアンテナ、およびデータを送受信するために設計された他の構成要素を含むことができる。通信チャネル150は、概して、ソースデバイス120からシンクデバイス160にビデオデータを送信するのに適した任意の通信媒体、または様々な通信媒体の集合を表す。通信チャネル150は、通常、Wi−Fi(登録商標)、Bluetooth(登録商標)などと同様の比較的短距離の通信チャネルである。しかしながら、通信チャネル150は、この点において必ずしも限定されるとは限らず、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの任意のワイヤレスまたは有線の通信媒体、あるいはワイヤレス媒体と有線媒体との任意の組合せを備えることができる。他の例では、通信チャネル150は、有線もしくはワイヤレスのローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成する場合さえある。加えて、通信チャネル150は、ピアツーピアリンクを作成するために、ソースデバイス120およびシンクデバイス160によって使用することができる。
[0039]ソースデバイス120およびシンクデバイス160は、たとえば、リアルタイムストリーミングプロトコル(RTSP)制御メッセージを使用して、能力ネゴシエーションに従って通信セッションを確立することができる。次いで、ソースデバイス120およびシンクデバイス160は、IEEE802.11規格ファミリーからの規格などの通信プロトコルを使用して、通信チャネル150を介して通信することができる。ソースデバイス120およびシンクデバイス160は、たとえば、Wi−Fi Direct(WFD)規格に従って通信することができ、その結果、ソースデバイス120およびシンクデバイス160は、ワイヤレスアクセスポイントまたはいわゆるホットスポットなどの仲介者を使用せずに互いと直接通信する。ソースデバイス120およびシンクデバイス160はまた、Tunneled Direct Link Setup(TDLS)を確立して、ネットワーク輻輳を回避または低減することができる。WFDおよびTDLSは、比較的短距離の通信セッションをセットアップすることを目的とする。この文脈では、比較的短距離は、たとえば、約70メートル未満を指す場合があるが、雑音の多いまたは遮るもののある環境では、デバイス間の距離は、約35メートル未満、または約20メートル未満など、さらに短い場合がある。
[0040]本開示の技法は、時々WFDに関して記載される場合があるが、これらの技法の態様は他の通信プロトコルにも適合できると考えられる。限定ではなく例として、ソースデバイス120とシンクデバイスとの間のワイヤレス通信は、直交周波数分割多重化(OFDM)技法を利用することができる。限定はしないが、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、符号分割多元接続(CDMA)、またはOFDM、FDMA、TDMAおよび/もしくはCDMAの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用することができる。
[0041]ソースデバイス120から受信されたデータを復号しレンダリングすることに加えて、シンクデバイス160は、ユーザ入力デバイス167からユーザ入力を受信することもできる。ユーザ入力デバイス167は、たとえば、キーボード、マウス、トラックボールもしくはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、または任意の他のそのようなユーザ入力デバイスであり得る。UIPM168は、ユーザ入力デバイス167によって受信されたユーザ入力コマンドを、ソースデバイス120が解釈することが可能なデータパケット構造にフォーマットする。そのようなデータパケットは、送信機/受信機166により、通信チャネル150を介してソースデバイス120に送信される。送信機/受信機ユニット126はデータパケットを受信し、A/V制御モジュール125はデータパケットを解析して、ユーザ入力デバイス167によって受信されたユーザ入力コマンドを解釈する。データパケット内で受信されたコマンドに基づいて、A/V制御モジュール125は、符号化され送信されているコンテンツを変更することができる。このようにして、シンクデバイス160のユーザは、リモートで、かつソースデバイス120と直接対話することなしに、ソースデバイス120によって送信されているオーディオペイロードデータとビデオペイロードデータとを制御することができる。
[0042]加えて、シンクデバイス160のユーザは、ソースデバイス120上のアプリケーションを起動し、制御することが可能である場合がある。たとえば、シンクデバイス160のユーザは、ソースデバイス120に記憶された写真編集アプリケーションを起動し、そのアプリケーションを使用して、ソースデバイス120にローカルに記憶された写真を編集することが可能である場合がある。シンクデバイス160は、その写真が実際はソースデバイス120上で編集されているが、その写真がシンクデバイス160上でローカルに編集されているように見え感じる、ユーザエクスペリエンスをユーザにもたらすことができる。そのような構成を使用して、デバイスユーザは、いくつかのデバイスとともに使用するために1つのデバイスの能力を活用することが可能である場合がある。たとえば、ソースデバイス120は、大量のメモリとハイエンド処理能力とを有するスマートフォンを備え得る。しかしながら、映画を見るとき、ユーザは、より大きいディスプレイスクリーンを有するデバイス上で映画を見ることを望む場合があり、その場合、シンクデバイス160は、タブレットコンピュータまたはさらに大きいディスプレイデバイスもしくはテレビジョンであり得る。電子メールを送ることまたは電子メールに応答することを行いたいとき、ユーザは、物理キーボードを有するデバイスを使用することを望む場合があり、その場合、シンクデバイス160はラップトップであり得る。どちらの場合でも、ユーザはシンクデバイスと対話していても、処理の大半は依然としてソースデバイス120によって実行することができる。ソースデバイスおよびシンクデバイスは、任意の所与のセッションにおいて、デバイスの能力をネゴシエーションおよび/または識別することにより、双方向対話を容易にすることができる。
[0043]いくつかの構成では、A/V制御モジュール125は、ソースデバイス120のオペレーティングシステムによって実行されるオペレーティングシステムプロセスを備え得る。しかしながら、他の構成では、A/V制御モジュール125は、ソースデバイス120上で動作しているアプリケーションのソフトウェアプロセスを備え得る。そのような構成では、ユーザ入力コマンドはソフトウェアプロセスによって解釈することができ、その結果、シンクデバイス160のユーザは、ソースデバイス120上で動作しているオペレーティングシステムとは対照的に、ソースデバイス120上で動作しているアプリケーションと直接対話している。オペレーティングシステムとは対照的にアプリケーションと直接対話することにより、シンクデバイス160のユーザは、ソースデバイス120のオペレーティングシステムに対してネイティブでないコマンドのライブラリにアクセスすることができる。加えて、アプリケーションと直接対話することにより、コマンドは、異なるプラットフォーム上で動作しているデバイスによってより容易に送信され、処理されることが可能になり得る。
[0044]シンクデバイス160で加えられたユーザ入力は、通信チャネル150を介してソースデバイス120に送り返すことができる。一例では、ユーザインターフェースバックチャネル(UIBC)とも呼ばれる逆方向チャネルアーキテクチャは、シンクデバイス160で加えられたユーザ入力を、シンクデバイス160がソースデバイス120に送信することを可能にするために実装することができる。逆方向チャネルアーキテクチャは、ユーザ入力をトランスポートするための上位レイヤメッセージと、シンクデバイス160およびソースデバイス120でユーザインターフェース能力をネゴシエーションするための下位レイヤフレームとを含むことができる。UIBCは、シンクデバイス160とソースデバイス120との間のインターネットプロトコル(IP)トランスポートレイヤ上に常駐することができる。このようにして、UIBCは、開放型システム間相互接続(OSI)通信モデルにおいてトランスポートレイヤより上位であり得る。ユーザ入力データを含んでいるデータパケットの信頼できる送信と順次配信とを促進するために、UIBCは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)またはユーザデータグラムプロトコル(UDP)などの他のパケットベース通信プロトコルの上で動作するように構成することができる。UDPおよびTCPは、OSIレイヤアーキテクチャにおいて並列に動作することができる。TCP/IPにより、シンクデバイス160およびソースデバイス120は、パケットロスの場合の再送信技法を実装することが可能になり得る。
[0045]UIBCは、クロスプラットフォームユーザ入力データを含む、様々なタイプのユーザ入力データをトランスポートするように設計することができる。たとえば、ソースデバイス120は、iOS(登録商標)オペレーティングシステムを実行することができ、一方シンクデバイス160は、Android(登録商標)またはWindows(登録商標)などの別のオペレーティングシステムを実行する。プラットフォームにかかわらず、UIPM168は、受信されたユーザ入力を、A/V制御モジュール125が理解できる形態にカプセル化することができる。ソースデバイスとシンクデバイスが異なるプラットフォーム上で動作するかどうかにかかわらず、多くの異なるタイプのソースデバイスおよびシンクデバイスがプロトコルを活用することが可能になるように、いくつかの異なるタイプのユーザ入力フォーマットをUIBCによってサポートすることができる。一般入力フォーマットを定義でき、プラットフォーム固有入力フォーマットを両方ともサポートでき、したがって、ユーザ入力がUIBCによってソースデバイス120とシンクデバイス160との間で通信できる方式でフレキシビリティが与えられる。
[0046]本開示の技法は、WDシステム100内のユーザ体験を改善することができる。WDシステム100のユーザ向けの典型的な使用事例には、ソースデバイス120上で動作するユーザインターフェースアプリケーションを、逆ヒューマンインターフェースデバイス(HID)フィードバックでシンクデバイス160のより大きいディスプレイ画面に表示すること、ソースデバイス120上で動作するゲームアプリケーションをシンクデバイス160で表示すること、およびソースデバイス120上で動作するビデオ再生アプリケーションをシンクデバイス160で表示することが含まれる。これらの使用事例の各々について、ソースデバイス120は、全フレームバッファのコンテンツとフレーム更新エンドツーエンドとを、シンクデバイス160のユーザへの表示用にシンクデバイス160に送信することができる。ソースデバイス120の送信機/受信機126は、リアルタイムトランスポートプロトコル(RTP)/ユーザデータグラムプロトコル(UDP)または伝送制御プロトコル(TCP)を使用して、ソースデバイス160の送信機/受信機166に符号化されたビデオフレームをトランスポートすることができる。
[0047]WDシステム100が高精細度マルチメディアインターフェース(HDMI(登録商標))または他のタイプのディスプレイケーブルと同様のユーザ体験を提供するために、WDシステム100は、約80ミリ秒(ms)未満のエンドツーエンドの待ち時間を実現する必要がある。しかしながら、ビデオ再生アプリケーションの使用事例の場合、WDシステム100は、過剰なさらなる待ち時間をもたらさずに、シンクデバイス160でのビデオ再生で高い品質(すなわち、滑らかさ)も実現する必要がある。本開示は、改善されたユーザ体験のための上述された待ち時間および品質のニーズを実現するために、個々に、または組合せでWDシステム100に適用され得るいくつかの技法を記載する。
[0048]本開示の技法によれば、処理パイプラインは、シンクデバイス160でのビデオの再生品質を改善しながら、ソースデバイス120とシンクデバイス160との間で送信されるA/Vメディアデータ121のエンドツーエンドの待ち時間を削減するように、ソースデバイス120とシンクデバイス160の両方で構成され得る。一例では、本技法は、ソースデバイス120での低遅延の画面取込みとバッファリングとを含む。たとえば、WDシステム100内で通信セッションを確立すると、パイプラインマネージャは、待ち時間を削減するために処理ステップ間でA/Vメディアデータ121の少なくとも直近のフレーム更新を保持することが可能な最小サイズのバッファを含むように、ソースデバイス120の処理パイプラインを構成することができる。加えて、ソースデバイス120の処理パイプラインは、パイプライン処理を用いた処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。
[0049]別の例では、本技法は、ソースデバイス120から受信されたA/Vメディアデータ121のタイプに基づく、シンクデバイス160でのカスタマイズされた再生を含む。A/Vメディアデータ121がビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス160の処理パイプラインに含まれるレンダラは、ビデオデータの加速されたレンダリングを実行するように構成され得る。A/Vメディアデータ121がビデオデータとオーディオデータの両方を含む場合、パイプラインマネージャは、オーディオレンダリング開始タイマを削減することができ、その結果、レンダラは削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。加えて、パイプラインマネージャは、セットアップ時間に起因する待ち時間を削減するために通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイス120からA/Vメディアデータ121を受信する前に、シンクデバイス160内の処理パイプラインを構成することができる。
[0050]さらなる一例では、本技法は、ソースデバイス120から受信されたA/Vメディアデータ121についてのアプリケーション認識に基づく、シンクデバイス160でのカスタマイズされたバッファリングを含む。シンクデバイス160は、A/Vメディアデータ121用のアプリケーションのタイプを知り、パイプラインマネージャは、シンクデバイス160の処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現する。たとえば、A/Vメディアデータ121がビデオ再生アプリケーション用であるとき、バッファサイズは増大されて、ビデオ再生アプリケーションについての滑らかさを増大させる。反対に、A/Vメディアデータ12がユーザインターフェース(UI)アプリケーションまたはゲームアプリケーション用であるとき、バッファサイズは減少されて、UIアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。
[0051]本開示の技法はまた、ソースデバイス120とシンクデバイス160との間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャは、ソースデバイス120内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。加えて、ソースデバイス120でのワイヤレスモデムソケットは、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。加えて、シンクデバイス160は、UIBCを介して通信チャネル150のトランスポート状態を記述するフィードバック情報をソースデバイス120に供給することができ、パイプラインマネージャは、フィードバック情報に基づいてソースデバイス120の処理パイプラインを修正することができる。
[0052]図1の例では、ソースデバイス120は、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Wi−Fi対応テレビジョン、またはオーディオデータおよびビデオデータを送信することが可能な任意の他のデバイスを備えることができる。シンクデバイス160は、同様に、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Wi−Fi対応テレビジョン、またはオーディオデータおよびビデオデータを受信し、ユーザ入力データを受信することが可能な任意の他のデバイスを備えることができる。場合によっては、シンクデバイス160は、ディスプレイ162、スピーカ163、UIデバイス167、およびA/Vエンコーダ164が、別個であるが相互動作可能なデバイスのすべての部品であるような、デバイスのシステムを含むことができる。ソースデバイス120は、同様に、単一のデバイスではなく、デバイスのシステムであり得る。
[0053]本開示では、ソースデバイスという用語は、一般に、A/Vデータを送信しているデバイスを指すために使用され、シンクデバイスという用語は、一般に、ソースデバイスからA/Vデータを受信しているデバイスを指すために使用される。多くの場合、ソースデバイス120とシンクデバイス160は、一方のデバイスがソースとして動作し、他方がシンクとして動作する、同様または同等のデバイスであり得る。その上、異なる通信セッションではこれらのロールが逆になる場合がある。したがって、1つの通信セッション内のシンクデバイスは、次の通信セッションではソースデバイスになる場合があり、その逆もあり得る。
[0054]いくつかの例では、WDシステム100は、シンクデバイス160に加えて1つまたは複数のシンクデバイスを含む場合がある。シンクデバイス160と同様に、追加のシンクデバイスは、ソースデバイス120からA/Vデータを受信し、かつ確立されたUIBCを介してソースデバイス120にユーザコマンドを送信することができる。いくつかの構成では、複数のシンクデバイスは互いに独立して動作することができ、ソースデバイス120でのA/Vデータ出力は、シンクデバイス160および追加のシンクデバイスのうちの1つまたは複数で同時に出力され得る。代替の構成では、シンクデバイス160は主要なシンクデバイスであり得、追加のシンクデバイスのうちの1つまたは複数は二次的なシンクデバイスであり得る。そのような例示的な構成では、シンクデバイス160および追加のシンクデバイスのうちの1つが結合される場合があり、シンクデバイス160はビデオデータを表示することができ、一方追加のシンクデバイスは対応するオーディオデータを出力する。加えて、いくつかの構成では、シンクデバイス160は送信されたビデオデータのみを出力することができ、一方追加のシンクデバイスは送信されたオーディオデータを出力する。
[0055]図2は、本開示の技法を実装できるWDシステム内のソースデバイス220の一例を示すブロック図である。ソースデバイス220は、図1内のソースデバイス120と同様のデバイスであり得るし、ソースデバイス120と同じ方式で動作することができる。ソースデバイス220は、ローカルディスプレイ222と、スピーカ223と、プロセッサ231と、ディスプレイプロセッサ235と、オーディオプロセッサ236と、メモリ232と、トランスポートユニット233と、ワイヤレスモデム234とを含む。図2で示されたように、ソースデバイス220は、トランスポート、記憶、および表示のためにA/Vメディアデータを符号化および/または復号する1つまたは複数のプロセッサ(すなわち、プロセッサ231、ディスプレイプロセッサ235およびオーディオプロセッサ236)を含むことができる。A/Vメディアデータは、たとえばメモリ232で記憶することができる。メモリ232は、A/Vファイル全体を記憶することができるか、または、たとえば別のデバイスもしくはソースからストリームされたA/Vファイルの一部分を記憶するだけのより小さいバッファを備えることができる。
[0056]トランスポートユニット233は、符号化されたA/Vメディアデータをネットワークトランスポート用に処理することができる。たとえば、符号化されたA/Vメディアデータはプロセッサ231によって処理され、ネットワークにわたる通信用のネットワークアクセスレイヤ(NAL)ユニットに、トランスポートユニット233によってカプセル化することができる。NALユニットは、ワイヤレスモデム234により、ネットワーク接続を介してワイヤレスシンクデバイスに送ることができる。ワイヤレスモデム234は、たとえば、IEEE802.11規格ファミリーのうちの1つを実装するように構成されたWi−Fiモデムであり得る。ソースデバイス220はまた、A/Vメディアデータをローカルに処理し表示することができる。特に、ディスプレイプロセッサ235は、ローカルディスプレイ222で表示されるようにビデオデータを処理することができ、オーディオプロセッサ236は、スピーカ223での出力用にオーディオデータを処理することができる。
[0057]図1のソースデバイス120に関して上述されたように、ソースデバイス220はまた、シンクデバイスからユーザ入力コマンドを受信することができる。たとえば、ソースデバイス220のワイヤレスモデム234は、NALユニットなどのカプセル化されたユーザ入力データパケットを受信し、カプセル化されたデータユニットをカプセル化解除のためにトランスポートユニット233に送ることができる。トランスポートユニット233はNALユニットからユーザ入力データパケットを抽出することができ、プロセッサ231はデータパケットを解析して、ユーザ入力コマンドを抽出することができる。ユーザ入力コマンドに基づいて、プロセッサ231は、ソースデバイス220によるA/Vメディアデータの処理を修正する。他の例では、ソースデバイス220は、トランスポートユニット233からユーザ入力データパケットを受信し、データパケットを解析してユーザ入力コマンドを抽出し、ユーザ入力コマンドに基づいてソースデバイス220によるA/Vメディアデータの処理を修正するようにプロセッサ231に指示する、ユーザ入力ユニットまたはユーザ入力ドライバ(図2には示されず)を含むことができる。
[0058]図2のプロセッサ231は、一般に、限定はしないが、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、他の等価な集積回路もしくはディスクリート論理回路、またはそれらのいくつかの組合せを含む、多種多様なプロセッサのうちのいずれをも表す。図2のメモリ232は、限定はしないが、同期ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM(登録商標))、フラッシュメモリなどを含む、多種多様な揮発性メモリまたは不揮発性メモリのいずれも備えることができる。メモリ232は、オーディオ/ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えることができる。加えて、メモリ232は、本開示に記載される様々な技法を実行することの一部として、プロセッサ231によって実行される命令とプログラムコードとを記憶することができる。
[0059]本開示の技法は、WDシステム内のソースデバイス220および1つまたは複数のシンクデバイスでのユーザ体験を改善するために、待ち時間を削減するようにソースデバイス220の処理パイプラインを構成することを含む。ソースデバイス220の処理パイプラインは、プロセッサ231および/またはトランスポートユニット233によって実行される1つたは複数の処理ユニットを含む。本技法は、図5に示されるソースデバイス520の処理パイプラインに関して、さらに詳細に記載される。
[0060]一例では、ソースデバイス220の処理パイプラインは、低遅延の画面取込みとメディアデータのバッファリングとを提供するように修正され得る。より具体的には、ソースデバイス220の処理パイプラインは、待ち時間を削減するためにプロセッサ231内の処理ステップ間で最小サイズのバッファを含むように構成され得る。次いで、ソースデバイス220は、メディアデータの少なくとも直近のフレーム更新を最小サイズのバッファにバッファリングし、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除する。
[0061]ソースデバイス220の処理パイプラインはまた、処理用にバッファからフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。ハードウェア加速の使用は、ソースデバイス220の中央処理装置(CPU)上の処理負荷を低減することができ、このことは、WDシステム内のフレームレートを増大させ、待ち時間を削減する。ソースデバイス220はまた、シンクデバイスによる時宜を得た受信を保証して、WDシステム内の待ち時間をさらに削減するために、符号化されたフレーム更新を再送信する(すなわち、重複プッシュを実行する)ことができる。
[0062]別の例として、本技法によれば、ソースデバイス220の処理パイプラインは、WDシステム内のソースデバイス220とシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先するように構成され得る。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。
[0063]より具体的には、ソースデバイス220のオーディオパイプライン経路は、ビデオパイプライン経路よりも多くのバッファリングを含むように構成され得る。さらなるバッファリングにより、ソースデバイス220で削除されるオーディオパケットがより少なくなることが保証される。別の例として、ソースデバイス220の処理パイプラインは、ビデオパイプライン経路よりもオーディオパイプライン経路に、ワイヤレスモデム234でより高い優先度のトランスポートキューを与えるように構成され得る。より高い優先度のトランスポートキューにより、対応するオーディオパケットを待つビデオパケットによって生じるビデオパイプライン経路内の遅延または失速を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイス220でトランスポート用にキューイングされることが保証される。加えて、ソースデバイス220のワイヤレスモデム234は、通信チャネルのトランスポート状態を記述するフィードバック情報を、WDシステム内のシンクデバイスから受信することができる。それに応答して、ソースデバイス220は、フィードバック情報に基づいて処理パイプラインを修正することができる。
[0064]上述された技法のうちの1つまたは複数をソースデバイス220に適用すると、WDシステム内のエンドツーエンドの待ち時間が削減され、WDシステム内のソースデバイス220とシンクデバイスの両方でユーザ体験が改善され得る。
[0065]図3は、本開示の技法を実装できるWDシステム内のシンクデバイス360の例を示すブロック図である。シンクデバイス360は、図1のシンクデバイス160と同様のデバイスであり得、シンクデバイス160と同じ方式で動作することができる。シンクデバイス360は、プロセッサ331と、メモリ332と、トランスポートユニット333と、ワイヤレスモデム334と、ディスプレイプロセッサ335と、ローカルディスプレイ362と、オーディオプロセッサ336と、スピーカ363と、ユーザ入力インターフェース376とを含む。
[0066]シンクデバイス360は、ソースデバイスから送られたカプセル化されたデータユニットをワイヤレスモデム334で受信する。ワイヤレスモデム334は、たとえば、IEEE802.11規格ファミリーからのもう1つの規格を実装するように構成されたWi−Fiモデムであり得る。トランスポートユニット333は、カプセル化されたデータユニットをカプセル化解除することができる。たとえば、トランスポートユニット333は、カプセル化されたデータユニットから符号化されたビデオデータを抽出し、かつ復号され出力用にレンダリングされるべき符号化されたA/Vデータをプロセッサ331に送ることができる。ディスプレイプロセッサ335は、ローカルディスプレイ362に表示されるべき復号されたビデオデータを処理することができ、オーディオプロセッサ336は、スピーカ363に出力するために復号されたオーディオデータを処理することができる。
[0067]オーディオおよびビデオデータをレンダリングすることに加えて、ワイヤレスシンクデバイス360は、ユーザ入力インターフェース376を介してユーザ入力データも受信することができる。ユーザ入力インターフェース376は、限定はしないが、タッチディスプレイインターフェース、キーボード、マウス、ボイスコマンドモジュール、(たとえば、カメラベースの入力キャプチャ機能を有する)ジェスチャキャプチャデバイスを含む、いくつかのユーザ入力デバイスのいずれも、またはいくつかのユーザ入力デバイスの任意の他のユーザ入力デバイスを表すことができる。ユーザ入力インターフェース376を介して受信されたユーザ入力は、プロセッサ331によって処理することができる。この処理は、受信されたユーザ入力コマンドを含むデータパケットを生成することを含むことができる。生成されると、トランスポートユニット333は、そのデータパケットを、UIBCを介したソースデバイスへのネットワークトランスポート用に処理することができる。
[0068]図3のプロセッサ331は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、他の等価な集積回路もしくはディスクリート論理回路などの広範囲のプロセッサのうちの1つまたは複数、あるいはそれらの何らかの組合せを備えることができる。図3のメモリ332は、限定はしないが、同期ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリなどを含む、多種多様な揮発性メモリまたは不揮発性メモリのいずれも備えることができる。メモリ232は、オーディオ/ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えることができる。加えて、メモリ332は、本開示に記載される様々な技法を実行することの一部として、プロセッサ331によって実行される命令とプログラムコードとを記憶することができる。
[0069]本開示の技法は、シンクデバイス360でのユーザ体験を改善するために、待ち時間を削減し、ビデオの再生品質(すなわち、滑らかさ)を改善するように、シンクデバイス360の処理パイプラインを構成することを含む。シンクデバイス360の処理パイプラインは、プロセッサ331および/またはトランスポートユニット333によって実行される1つたは複数の処理ユニットを含む。本技法は、図6に示されるシンクデバイス660の処理パイプラインに関して、さらに詳細に記載される。
[0070]一例では、シンクデバイス360の処理パイプラインは、WDシステム内のソースデバイスから受信されたメディアデータのタイプに基づいて、シンクデバイス360でメディアデータのカスタマイズされた再生を提供するように構成され得る。より具体的には、メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス360の処理パイプラインは、ビデオデータの加速されたレンダリングを実行するように構成され得る。たとえば、メディアデータがオーディオデータを含まないことを検出すると、シンクデバイス360は、同期を無効にし、存在しないオーディオデータとの同期を待たずに、ビデオデータをレンダリングすることができる。一方、メディアデータがビデオデータとオーディオデータの両方を含むことを検出すると、シンクデバイス360は、オーディオレンダリング開始タイマを削減し、削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。
[0071]加えて、シンクデバイス360の処理パイプラインは、ストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に構成され得る。ストリームヘッダ情報は、WDシステム内の通信セッションの能力交渉期間の間に、シンクデバイス360とソースデバイスによって交換され得る。このようにして、シンクデバイス360の処理パイプラインは、受信されたメディアデータの処理を直ちに開始し、処理パイプラインのセットアップ時間に起因するいかなる待ち時間も除去または削減することができる。
[0072]別の例として、本技法によれば、シンクデバイス360の処理パイプラインは、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づいて、メディアデータのカスタマイズされたバッファリングを提供するように構成され得る。より具体的には、シンクデバイス360は、受信されたメディアデータ用のアプリケーションのタイプを知り、処理パイプライン内のバッファのサイズを調整して、アプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現することができる。場合によっては、メディアデータ用のアプリケーションのタイプはソースデバイスで検出され、シンクデバイス360にメディアデータとともに通知され得る。その場合、シンクデバイス360は、ソースデバイスから受信された指示に基づいて、メディアデータ用のアプリケーションのタイプを知る。他の場合、シンクデバイス360は、アプリケーションのタイプ自体を検出することによって、メディアデータ用のアプリケーションのタイプを知ることができる。
[0073]メディアデータが、再生の品質または滑らかさがシンクデバイスで最も優先度が高く、上述された低遅延技法が目に見えるジッタをもたらす場合がある、ビデオ再生アプリケーション用であるとき、シンクデバイス360の処理パイプライン内のバッファサイズは増大されて、ビデオ再生アプリケーション用内のメディアデータの滑らかさを増大させる。反対に、メディアデータが、低遅延がシンクデバイスで最も優先度が高い、ユーザインターフェース(UI)アプリケーションまたはゲームアプリケーション用であるとき、シンクデバイス360の処理パイプライン内のバッファサイズは減少されて、UIアプリケーションまたはゲームアプリケーションについての待ち時間を削減する。
[0074]さらなる例として、本技法によれば、シンクデバイス360のワイヤレスモデム334は、通信チャネルのトランスポート状態を記述するフィードバック情報を、WDシステム内のソースデバイスに送信することができる。シンクデバイス360は、前に受信されたメディアデータの誤り率および/またはパケット損失に基づいて、通信チャネルのトランスポート状態を判断することができる。ワイヤレスモデム334は、ソースデバイスにUIBCまたは他の逆チャネルを介してフィードバック情報を送信することができる。場合によっては、シンクデバイス360は、フィードバックストリーミング用にリアルタイムトランスポート制御プロトコル(RTCP)を使用することができる。それに応答して、ソースデバイスは、フィードバック情報に基づいて、シンクデバイス360に向けられたメディアデータのその処理を修正することができる。
[0075]上述された技法のうちの1つまたは複数をシンクデバイス360に適用すると、WDシステム内のエンドツーエンドの待ち時間が削減され、ビデオの再生品質が増大されて、WDシステム内のシンクデバイス360でのユーザ体験が改善され得る。
[0076]図4は、通信チャネル150を介して通信するために、図1の送信機/受信機126および送信機/受信機166によって使用できる、例示的な送信機システム410と受信機システム450とを示すブロック図である。送信機システム410では、いくつかのデータストリームのトラフィックデータが、データソース412から送信(TX)データプロセッサ414に供給される。各データストリームは、それぞれの送信アンテナを介して送信することができる。TXデータプロセッサ414は、データストリームごとのトラフィックデータを、そのデータストリーム用に選択された特定の符号化方式に基づいてフォーマットし、符号化し、インターリーブする。データストリームごとの符号化データは、直交周波数分割多重(OFDM)技法を使用して、パイロットデータと多重化することができる。限定はしないが、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、符号分割多重アクセス(CDMA)、またはOFDM、FDMA、TDMA、および/もしくはCDMAの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用することができる。
[0077]図4に従って、パイロットデータは、通常、知られている方式で処理される知られているデータパターンであり、チャネル応答を推定するために受信機システム450で使用することができる。次いで、データストリームごとに多重化されたパイロットデータおよび符号化データは、変調シンボルを与えるために、そのデータストリーム用に選択された特定の変調方式(たとえば、2位相シフトキーイング(BPSK)、4位相シフトキーイング(QPSK)、M−PSK、またはM−QAM(直交振幅変調)、ここでMは2のべき乗であり得る)に基づいて、変調(たとえば、シンボルマッピング)される。データストリームごとのデータレート、符号化、および変調は、メモリ432と結合できるプロセッサ430によって実行される命令によって決定することができる。
[0078]次いで、データストリーム用の変調シンボルがTX MIMOプロセッサ420に供給され、TX MIMOプロセッサ420はさらに(たとえば、OFDM用に)その変調シンボルを処理することができる。次いで、TX MIMOプロセッサ420は、NT個の変調シンボルストリームをNT個の送信機(TMTR)422A〜422T(「送信機422」)に供給することができる。いくつかの態様では、TX MIMOプロセッサ420は、データストリームのシンボルと、シンボルがそこから送信されているアンテナとにビームフォーミング重みを適用する。送信機422の各々は、それぞれのシンボルストリームを受信し処理して、1つまたは複数のアナログ信号を供給し、さらに、それらのアナログ信号を調整(たとえば、増幅、フィルタ処理、およびアップコンバート)して、MIMOチャネルを介して送信するのに適した変調信号を供給することができる。次いで、送信機422からのNT個の変調信号は、それぞれNT個のアンテナ424A〜424t(「アンテナ424」)から送信される。
[0079]受信機システム450では、送信された変調信号はNR個のアンテナ452A〜452R(「アンテナ452」)によって受信され、アンテナ452の各々からの受信信号は、受信機(RCVR)454A〜454R(「受信機454」)のうちのそれぞれに供給される。受信機454の各々は、それぞれの受信信号を調整(たとえば、フィルタ処理、増幅、およびダウンコンバート)し、調整された信号をデジタル化してサンプルを供給し、さらにそれらのサンプルを処理して、対応する「受信」シンボルストリームを供給する。次いで、受信(RX)データプロセッサ460は、NR個の受信機454からNR個の受信シンボルストリームを受信し、特定の受信機処理技法に基づいて処理して、NT個の「検出」シンボルストリームを供給する。次いで、RXデータプロセッサ460は、各検出シンボルストリームを復調し、デインターリーブし、復号して、データストリームのトラフィックデータを復元する。RXデータプロセッサ460による処理は、送信機システム410でのTX MIMOプロセッサ420およびTXデータプロセッサ414によって実行される処理と相補関係にある。
[0080]メモリ472と結合できるプロセッサ470は、どのプリコーディング行列を使用すべきかを周期的に判定する。逆方向リンクメッセージは、通信リンクおよび/または受信データストリームに関する様々なタイプの情報を備えることができる。次いで、逆方向リンクメッセージは、データソース436からいくつかのデータストリームのトラフィックデータも受信するTXデータプロセッサ438によって処理され、変調器480によって変調され、送信機454によって調整され、送信機システム410に返送される。
[0081]送信機システム410では、受信機システム450からの変調信号は、アンテナ424によって受信され、受信機422によって調整され、復調器440によって復調され、受信機システム450によって送信された逆方向リンクメッセージを抽出するためにRXデータプロセッサ442によって処理される。次いで、プロセッサ430は、ビームフォーミング重みを決定するためにどのプリコーディング行列を使用すべきかを判定し、抽出されたメッセージを処理する。
[0082]図5は、本開示の技法をサポートして、ソースデバイス520の処理パイプライン550内の待ち時間を削減することが可能なソースデバイス520の例を示すブロック図である。ソースデバイス520は、図1からのソースデバイス120または図2からのソースデバイス220と同様のデバイスであり得、ソースデバイス120またはソースデバイス220と同じ方式で動作することができる。
[0083]ソースデバイス520は、ローカルディスプレイ522と、ディスプレイプロセッサ535と、メモリ532と、ワイヤレスモデムソケット570と、ワイヤレスモデム534と、処理パイプライン550とを含む。処理パイプライン550は、バッファと、プロセッサ531およびトランスポートユニット533によって実行される処理ユニットとを含む。具体的には、処理パイプライン550は、プロセッサ531内のビデオ処理エンジン(VPE)560およびエンコーダ562と、トランスポートユニット533内のパケッタイザ564とを含む。加えて、処理パイプライン550は、ディスプレイプロセッサ535とVPE560との間に位置するライトバック(WB)バッファ540と、VPE560とエンコーダ562との間のフレームバッファ542と、エンコーダ562とパケッタイザ564との間のコード化ピクチャバッファ(CPB)544とを含む。
[0084]ソースデバイス520はまた、ハードウェア加速器536とパイプラインマネージャ538とを含む。本開示の技法によれば、パイプラインマネージャ538は、ソースデバイス520でメディアデータについての低遅延の画面取込みとバッファリングとを提供するように、処理パイプライン550を構成する。具体的には、パイプラインマネージャ538は、最小サイズのバッファを含み、ハードウェア加速器536を使用してメモリ532および最小サイズのバッファからメディアデータを取り出すように、処理パイプライン550を構成する。
[0085]一例では、WDシステム内の1つまたは複数のシンクデバイスと通信セッションを確立すると、パイプラインマネージャ538は、待ち時間を削減するために処理ステップ間で最小サイズのバッファを含むように、ソースデバイス520の処理パイプライン550を構成する。ある場合には、最小サイズのバッファは、メディアデータがディスプレイプロセッサ535とVPE560との間を通り抜けるために、削減された数のWBバッファ540を含む場合がある。たとえば、パイプラインマネージャ538は、メディアデータの少なくとも直近のフレーム更新を保持するために、2つのみのWBバッファ540、たとえばピンポンバッファを含むように、処理パイプライン550を構成することができる。WBバッファ540は、VPE560による処理の前にフレーム更新を保持することができる。加えて、WBバッファ540は、メモリ532にライトバックされる前に、少なくとも直近のフレーム更新を保持するように構成され得る。たとえば、2つのWBバッファ540は、32個未満のエントリ、場合によっては16個未満のエントリを保持するように構成され得る。
[0086]他の場合には、最小サイズのバッファはまた、メディアデータがVPE560とエンコーダ562との間を通り抜けるために、削減された数のフレームバッファ542を含む場合がある。たとえば、パイプラインマネージャ538は、メディアデータの少なくとも直近のフレーム更新を保持するために、4つのみのフレームバッファ542、たとえば、2つのピンポンバッファと2つの保持バッファとを含むように、処理パイプライン550を構成することができる。加えて、最小サイズのバッファは、メディアデータがエンコーダ562とパケッタイザ564との間を通り抜けるために、削減された数のCPB544を含む場合がある。たとえば、パイプラインマネージャ538は、メディアデータの少なくとも直近のフレーム更新を保持するために、6個のみのCPB544、たとえば2つのピンポンバッファと4つの保持バッファとを含むように、処理パイプライン550を構成することができる。
[0087]ソースデバイス520の処理パイプライン550内で最小サイズのバッファを使用すると、本技法によれば、フレーム更新が処理の前と間により少なく小さいバッファを通り抜けるので、ソースデバイス520での待ち時間が削減される。加えて、WBバッファ540のサイズを32個未満のエントリを有する2つのピンポンバッファに最小化すると、処理パイプライン550のさらなるダウンストリームを詰まらせるのではなく、ソースデバイス520の処理パイプライン550の早い段階でフレームドロップが発生することが可能になる。
[0088]ソースデバイス520の処理パイプライン550が最小サイズのバッファを含むように修正されたとき、パイプラインマネージャ538はまた、直近のフレーム更新がバッファリングされ、処理され、シンクデバイスに送信されることを保証するように、処理パイプライン550内のフレーム取込みプロセスを修正することができる。本技法は、最小サイズのバッファにメディアデータから取り込まれた少なくとも直近のフレーム更新をバッファリングすることと、最小サイズのバッファが一杯になったとき、より古いフレーム更新を削除することとを含む。たとえば、各フレーム更新(たとえば、部分フレームまたは全体フレームのいずれか)は、ソースデバイス520内のWDシステム専用のWBバッファ560にキューイングされ得るか、または蓄積され得る。最小サイズのWBバッファ560がさらなるフレーム更新のために一杯になった場合、WBバッファ560は、より古いフレーム更新を削除し、より最近のフレーム更新を維持するように構成され得る。最小サイズのWBバッファ560は、新しいフレーム更新が受信されるやいなや処理用にフレーム更新を出力することができない可能性がある。本技法によれば、より古いフレーム更新のうちの1つまたは複数は、新しいフレーム更新がバッファリングされ、処理され、送信されることを可能にするために、WBバッファ560から削除され得る。
[0089]別の例として、処理パイプライン550は、メモリ532、WBバッファ540、フレームバッファ542、および/またはCPB544からフレーム更新を取り出すようにハードウェア加速を使用するように構成され得る。たとえば、処理パイプライン550は、ハードウェア加速器536を使用して、ソースデバイス520の中央処理装置(CPU)の代わりに処理パイプライン550内の処理ユニットにより、処理用にフレーム更新を取り出すことができる。ハードウェア加速器536を使用すると、ソースデバイス520のCPU上の処理負荷が低減され得、このことは、フレームレートを増大させ、ソースデバイス520内の待ち時間を削減することができる。
[0090]メディアデータの取り込まれたフレームのピクセル用イメージフォーマットは、通常、RGB888、RGB565、またはYUV生フォーマットのうちの1つである。ソースデバイス520のCPUを使用してメディアデータの取り込まれたフレームの標準メモリコピーにアクセスすると、高いフレームレートの更新を実現するために多くのCPU負荷がかかりすぎる。WDシステム用のメディアデータ処理がソースデバイス550で過剰なCPU処理負荷を消費するとき、ユーザは、WDシステム内のソースデバイス550およびシンクデバイス上で実行されているメディアアプリケーションの待ち時間または緩慢さに気付く場合がある。本技法は、ハードウェア加速器536を使用して直接メモリアクセス(DMA)を実行して、メモリ532またはバッファのうちの1つに保持されたフレーム更新を取り出し、CPUから独立して、処理パイプライン550内の処理ユニット間でフレーク更新を移動させることを含む。
[0091]ソースデバイス520内のエンコーダ562は、ハードウェアベースおよび/またはソフトウェアベースであり得る。VPE560がフレーム更新をフレームバッファ542内にレンダリングした後、エンコーダ562はフレーム更新を符号化する。符号化されたフレーム更新は、パケッタイザ564によるパケット情報およびワイヤレスモデム534によるシンクデバイスへの送信の前に、CPB544にバッファリングされ得る。場合によっては、CPB544は、CPB544にバッファリングするために符号化されたフレーム更新のさらなるメモリコピーを作成する代わりに、メモリ532に記憶された符号化されたフレーム更新へのポインタをバッファリングするように構成され得る。一例として、ポインタは、メモリ532内の符号化されたフレーム更新のソースアドレスを指定することができ、その結果、符号化されたフレーム更新はCPB544内で参照されるが、実際のメモリコピーはメモリ532に保持される。このようにして、ソースデバイス520は、符号化されたフレーム更新のさらなるメモリコピーを生成および記憶することのコストを回避することができる。他の例では、本技法は、他の方法を使用して、さらなるメモリコピーのコストを節約することができる。より具体的には、本技法は、符号化されたフレーム更新のさらなるメモリコピーを作成せずにCPB544内の符号化されたフレーム更新を参照するために、マッピングされたメモリまたはメモリ532への送受信要求を使用することを含むことができる。
[0092]さらなる一例では、本技法はまた、シンクデバイスによる時宜を得た受信を保証して、WDシステム内の待ち時間をさらに削減するために、ソースデバイス520からの符号化されたフレーム更新の再送信(すなわち、重複プッシュ)を含むことができる。重複プッシュは、ソース520とシンクデバイスとの間で多くのメディアデータパケットが削除され得る不十分な通信チャネルの場合、特に有用であり得る。一例では、ソースデバイス520は、失われたフレームを再送信するためにシンクデバイスからのフィードバックに依拠しない場合がある。代わりに、ソースデバイス520のワイヤレスモデム534は、新しいフレーム更新がシンクデバイスへの送信用に受信されなかった場合、所定の時間期間の後、フレーム更新を自動的に再送信することができる。たとえば、ワイヤレスモデム534は、新しいフレーム更新が受信されなかった場合、約13秒後に最新のフレーム更新を自動的に再送信することができる。他の場合、ワイヤレスモデム534は、約10秒またはそれ未満の後に最新のフレーム更新を再送信することができる。
[0093]ソースデバイス520で実行される重複プッシュにより、ディスプレイコンテンツが、信頼できないトランスポートに起因してシンクデバイスで破損したフレームから回復することが可能になり得る。たとえば、ソースデバイス520のワイヤレスモデム534が、たとえば、伝送制御プロトコル(TCP)と比較して相対的に信頼できないトランスポートプロトコルであるユーザデータグラムプロトコル(UDP)を使用するとき、ワイヤレスモデム534は、所定の時間期間の後新しいフレーム更新が受信されなかった場合、重複プッシュを実行して最新のフレーム更新を再送信することができる。いくつかの例では、重複プッシュ間隔は、送信されているメディアデータのタイプに基づいて、動的に調整可能であり得る。ユーザインターフェース(UI)アプリケーションまたはゲームアプリケーション用のメディアデータの場合、失われたフレームは目立ち、WDシステム内のUIアプリケーションのユーザ体験に悪影響を及ぼす。ビデオ再生アプリケーション用のメディアデータの場合、失われたフレームは容易に目立たず、ビデオ再生アプリケーションのユーザ体験に少ししか影響を与えないか、まったく影響を与えない。したがって、UIアプリケーションおよびゲームアプリケーションの場合、ワイヤレスモデム534は、ビデオ再生アプリケーションよりも頻繁に重複プッシュを実行するように構成され得る。たとえば、UIアプリケーションおよびゲームアプリケーションの場合、重複プッシュ間隔は、約10秒またはそれ未満に削減され得る。
[0094]場合によっては、ソースデバイス520のエンコーダ562および/またはシンクデバイスの各々のデコーダからフレームをプッシュするために、同様の重複プッシュメカニズムが使用され得る。通常、エンコーダおよびデコーダは、コード化されたフレームを各々自動的に出力しないが、次のフレームを受信して前のコード化されたフレームを押し出す必要がある。したがって、本技法は、さらなるプッシュを与えてコード化されたフレーム更新を出力することによって、ソースデバイス520と1つまたは複数のシンクデバイスとの間の同期を改善することができる。
[0095]加えて、本開示の技法はまた、WDシステム内のソースデバイス520とシンクデバイスとの間で、オーディオデータのトランスポートをビデオデータのトランスポートより優先することを含む。ビデオデータパケットのトランスポートは、関連するオーディオデータパケットのトランスポートに結び付けられ、その結果、すべてのオーディオパケットがシンクデバイスに到達することを保証するので、削除されたパケットの受信を待つシンクデバイスでの待ち時間が削減される。パイプラインマネージャ538は、ソースデバイス520内のビデオパイプライン経路よりも多くのバッファリングを含むように、オーディオパイプライン経路を構成することができる。さらなるバッファリングにより、ソースデバイス520で削除されるオーディオパケットがより少なくなることが保証される。ワイヤレスモデムソケット570は、ビデオパイプライン経路よりもオーディオパイプライン経路に、より高い優先度のトランスポートキューを与えることができる。より高い優先度のトランスポートキューにより、キューイングされるべき対応するオーディオパケットを待つビデオパケットに起因するビデオパイプライン経路内の遅延または失速を回避するために、オーディオパケットが対応するビデオパケットより前にソースデバイス520でトランスポート用にキューイングされることが保証される。
[0096]従来、オーディオとビデオの両方の処理パイプライン経路は、同じまたは同様の量のバッファリングとトランスポート優先度とを有する。オーディオデータは、すべてのメディアデータがシンクデバイスで受信されることを保証するために、より注意深い処理とトランスポートとを必要とするので、ソースデバイス内の従来のビデオパイプライン経路は、関連するオーディオデータの準備ができるまでビデオデータのトランスポートを遅延または失速させ、このことはWDシステム内にさらなる待ち時間をもたらす。オーディオパイプライン経路を優先させることによって、ビデオパイプライン経路内のさらなる遅延または失速時間が不要になる。
[0097]本技法によれば、オーディオデータの優先トランスポートは、パケットがオーディオトラフィックを含むか、またはビデオトラフィックを含むかを示すように、メディアデータパケット内のサービスタイプ(TOS)フィールドを設定することによって実現され得る。たとえば、通信チャネルがWi−Fiマルチメディア(WMM)をサポートする場合、TOSフィールドは、音声と、ビデオと、ベストエフォートと、バックグラウンドとを含む優先順位づけ目的で、WMMによって規定されたアクセスカテゴリを示すことができる。メディアデータパケット内のTOSフィールドにより、ソースデバイス550内のワイヤレスモデムドケット570が、オーディオパケットとビデオパケットとを、異なる優先レベルを有する異なるキューに入れることが可能になる。
[0098]加えて、ソースデバイス520は、シンクデバイスとの通信チャネルのトランスポート状態を記述するフィードバック情報をシンクデバイスから受信することができる。たとえば、フィードバック情報は、シンクデバイスで判断され、ソースデバイス520に通信される誤り率またはパケット損失を含む場合がある。場合によっては、フィードバック情報は、WDシステム内のシンクデバイスとソースデバイス520との間で確立されたUIBCを介して、シンクデバイスからソースデバイス520に送られ得る。他の場合、フィードバック情報は、異なるソケットリンクを介してソースデバイス520に送られ得る。加えて、フィードバック情報は、RTCPまたは他の何らかのカスタマイズされたシグナリングを使用して通信され得る。
[0099]それに応答して、ソースデバイス520のパイプラインマネージャ538は、フィードバック情報に基づいてソースデバイス520の処理パイプライン550を修正することができる。一例では、不十分な通信チャネルを記述するフィードバック情報を受信したことに応答して、ソースデバイス520は、メディアデータパケットを再送信する重複プッシュ間隔を、たとえば10秒以上または13秒以上に増大させるか、またはメディアデータパケットを処理および送信するためのデータレートを変更することができる。別の例では、フィードバック情報に応答して、ソースデバイス520は、全体的に、バッファサイズと符号化パラメータとを調整するか、またはトランスポートプロトコルのタイプ間を動的に切り替えることができる。たとえば、不十分な通信チャネルを記述するフィードバック情報に応答して、ソースデバイス520は、比較的信頼できないトランスポートプロトコルであるリアルタイムプロトコル(RTP)/ユーザデータグラムプロトコル(UDP)の通信チャネルから、RTP/伝送制御プロトコル(TCP)のトランスポートチャネルに切り替えることができる。
[0100]図6は、本開示の技法をサポートして、シンクデバイス660の処理パイプライン650内の待ち時間を削減し、シンクデバイス660でのビデオ再生を改善することが可能なシンクデバイス660の例を示すブロック図である。シンクデバイス660は、図1からのシンクデバイス160または図3からのシンクデバイス260と同様のデバイスであり得、シンクデバイス160またはシンクデバイス260と同じ方式で動作することができる。
[0101]シンクデバイス660は、ローカルディスプレイ622と、ディスプレイプロセッサ635と、メモリ632と、ワイヤレスモデムソケット670と、ワイヤレスモデム634と、処理パイプライン650とを含む。処理パイプライン650は、バッファと、プロセッサ631およびトランスポートユニット633によって実行される処理ユニットとを含む。具体的には、処理パイプライン650は、トランスポートユニット633内のパーサ680と、プロセッサ631内のデコーダ682およびレンダラ684とを含む。加えて、処理パイプライン650は、パーサ680とデコーダ682との間に位置するバッファ692と、デコーダ682とレンダラ684との間に位置するレンダリングキュー684と、レンダラ684とディスプレイプロセッサ635との間のフレームバッファ696とを含む。
[0102]シンクデバイス660は、パイプラインマネージャ638も含む。本開示の技法によれば、パイプラインマネージャ638は、ソースデバイスから受信されたメディアデータのタイプに基づいて、シンクデバイス660でのカスタマイズされた再生を提供するように、処理パイプライン650を構成する。具体的には、パイプラインマネージャ638は、メディアデータがオーディオデータを含むかどうかに基づいてレンダリングを修正するように、処理パイプライン650を構成する。
[0103]たとえば、メディアデータがビデオデータのみを含み、オーディオデータを含まない場合、シンクデバイス660の処理パイプライン650に含まれるレンダラ684は、ビデオデータの加速されたレンダリングを実行するように構成される。メディアデータがオーディオデータを含まないことを検出すると、パイプラインマネージャ638は、レンダラ684での同期を無効にすることができる。次いで、レンダラ684は、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングすることができる。
[0104]従来、メディアデータ処理パイプラインは、ビデオデータとオーディオデータの両方、またはオーディオデータがないビデオデータのみのために設計される。ビデオデータのみを受信すると、ビデオデータとオーディオデータの両方のために設計されたメディアデータ処理パイプラインは、ビデオデータとオーディオデータの両方を処理するのに必要な速度と同じ速度でビデオデータを処理し、存在しないオーディオデータとの同期用の待ち時間を含む。さらなる処理時間は、処理パイプラインに待ち時間を不必要に加える。本開示の技法により、シンクデバイス660のデコーダ682が、受信されたメディアデータのタイプを検出し、メディアデータのタイプに基づいてレンダラ684での再生処理速度を動的に調整することが可能になる。たとえば、デコーダ682は、メディアデータ内のオーディオタイムスタンプの存在または不在を検出することができ、オーディオタイムスタンプの存在により、ソースデバイスからのメディアデータがオーディオデータを含むことが示される。
[0105]たとえば、UIアプリケーション用のメディアデータの場合、ビデオデータに付随するオーディオデータは存在しない。UIアプリケーションデータの場合、パイプラインマネージャ638は、シンクデバイス660のレンダラ684での同期を無効にすることができる。このようにして、レンダラ684は、存在しないオーディオデータの処理および同期のための待ち時間なしに、可及的速やかにUIアプリケーション用のビデオデータをレンダリングすることができる。ビデオ再生アプリケーション用のメディアデータの場合、ビデオデータに付随するオーディオデータが存在する場合がある。オーディオデータ付きのビデオ再生アプリケーションデータの場合、パイプラインマネージャ638は同期を有効にすることができ、レンダラ684は、同期されたビデオデータとオーディオデータとを通常の処理速度でレンダリングすることができる。
[0106]加えて、本技法により、パイプラインマネージャ638がレンダラ684に適用可能なメディア時間に基づいて、レンダラ684でのサンプル時間を調整することも可能になる。このようにして、ソースデバイスによって設定されたメディアデータのサンプル時間がシンクデバイス660にあるレンダラ684に適用可能ではないとき、パイプラインマネージャ638は、メディア時間に基づいてメディアデータに適用可能なサンプル時間を選択することができる。
[0107]別の例として、メディアデータがビデオデータとオーディオデータの両方を含む場合、パイプラインマネージャ638は、オーディオレンダリング開始タイマを削減することができ、レンダラ684は削減された開始タイマに従って、同期されたオーディオデータとビデオデータとをレンダリングすることができる。このようにして、本技法は、メディアデータがオーディオデータを含むときでも、シンクデバイス660での待ち時間を削減することができる。
[0108]いくつかの再生エンジンでは、着信したオーディオパケットの消失または削除を回避するために、オーディオのレンダリングは起動時に遅延され得る。遅延時間は、Bluetoothシステムなどの何らかの通信システムに必要であり得る。WDシステムなどの他の通信システムの場合、同期が有効であるとき、遅延は不要であり、エンドツーエンドの待ち時間を増加させる。たとえば、Bluetoothシステムに必要なアドバンストオーディオ配信プロファイル(A2DP)初期化時間、たとえば、1秒以上を補償するために、シンクデバイス660のレンダラ684でのオーディオレンダリング開始タイマは、比較的高く設定され得る。オーディオデータのレンダリングは開始時間だけ遅延され、着信したサンプルはレンダラ684に入力される前にバッファリングされる必要がある。オーディオデータが遅延された場合、オーディオデータとビデオデータの同期を保つために、対応するビデオデータも遅延される必要がある。
[0109]本開示に記載された技法によれば、WDシステムの場合、レンダラ684でのオーディオレンダリング開始タイマは削減されて、シンクデバイス660内の待ち時間を削減し、オーディオデータとビデオデータの失速を回避する。たとえば、WDシステムの場合、パイプラインマネージャ638は、シンクデバイス660でのより速いレンダリングと再生とを提供するために、オーディオレンダリング開始タイマを削減または除去することができる。オーディオレンダリング開始タイマは、1秒未満、50ミリ秒(ms)未満、場合によっては20ms未満になるように削減され得る。Bluetoothシステムの場合、パイプラインマネージャ638は、比較的高い、たとえば1秒以上になるようにオーディオレンダリング開始タイマを動的にリセットすることができる。
[0110]別の例では、パイプラインマネージャ638は、セットアップ時間に起因する待ち時間を削減するために通信セッションの能力交渉期間の間に交換されたストリームヘッダ情報に基づいて、ソースデバイスからメディアデータを受信する前に、シンクデバイス660内の処理パイプライン650を構成することができる。処理パイプライン650を事前構成するために、ソースデバイスおよびシンクデバイス660は、通信チャネルを介して送信されるべきメディアデータについての情報を含むストリームヘッダ情報を最初に交換する。ストリームヘッダ情報は、リアルタイムストリーミングプロトコル(RTSP)または他のプロプライエタリなメッセージを使用して交換され得る。次いで、パイプラインマネージャ638は、構成バッファサイズと、レンダリング開始タイマと、同期待ちタイマと、プログラマブルデコーダ設定とを含む、受信されたヘッダ情報に基づいて処理パイプライン650をセットアップする。処理パイプライン650が構成された後、シンクデバイス660は、メディアデータの送信を開始するようにソースデバイスに通知する。
[0111]加えて、ソースデバイスから受信されたメディアデータを処理する前に、シンクデバイス660は、デコーダ682から受信されたメディアデータの1つまたは複数のサンプルをフラッシュすることができる。メディアデータの最初の数個のサンプルは、通信セッションの交渉期間の間に生成された、ソースデバイスパイプラインからの古くて失速したサンプルを備える可能性がある。本技法は、ソースデバイスからのフレームを再送信して、シンクデバイス660にあるデコーダ682から失速したサンプルをプッシュするために、重複プッシュを提供する。このようにして、シンクデバイス660は、メディアデータの古くて失速したサンプルに対していかなる処理時間も浪費しない。
[0112]場合によっては、シンクデバイス660にあるパイプラインマネージャ638は、レンダラ684によるレンダリング用にデコーダ682からサンプルをプッシュするためにデコーダ682にダミーフレームを挿入することができる。これは、デコーダ682がプログラム可能ではなく、着信したメディアデータサンプルのピクチャ順序カウント(POC)の復号をサポートしないとき、必要であり得る。他の場合、デコーダ682がプログラム可能であり、POCをサポートする場合、パイプラインマネージャ638は、表示順序の代わりに、PICまたは復号順序に従ってメディアデータサンプルを出力するように、デコーダ682を構成することができる。復号順序でサンプルを出力するようにプログラマブルデコーダ682を構成すると、デコーダ682へのあらゆる入力サンプルは、復号が完了するとすぐに出力されることが保証される。このようにして、デコーダ682での失速および遅延は、削減または除去され得る。加えて、パイプラインマネージャ638は、デコーダ682とレンダラ684との間のレンダリングキュー694に含まれるバッファの数を最小化して、シンクデバイス660内の待ち時間をさらに削減することができる。たとえば、レンダリングキュー694は、レンダラ684によるレンダリングの前にメディアデータを保持するバッファを、4つまたはそれより少なく含む場合がある。
[0113]加えて、本開示の技法によれば、パイプラインマネージャ638は、ソースデバイスから受信されたメディアデータについてのアプリケーション認識に基づいて、シンクデバイス660でカスタマイズされたバッファリングを提供するように、処理パイプライン640を構成する。具体的には、ソースデバイス660のデコーダ682は、受信されたメディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャ638は、処理パイプライン650内のバッファのサイズを調整するように処理パイプライン650を構成する。このようにして、シンクデバイス660は、メディアデータ用のアプリケーションのタイプについての滑らかさと待ち時間との間の適切なバランスを実現することができる。パイプラインマネージャ638は、レンダリングキュー694、フレームバッファ696、または、メディアデータ用のアプリケーション内の表示の前にデータを保持する、処理パイプライン650に含まれる任意の他のバッファのサイズを調整することができる。
[0114]たとえば、メディアデータがビデオ再生アプリケーション用であるとき、再生の品質または滑らかさがシンクデバイス660で最も優先度が高く、上述された低遅延技法は目に見えるジッタをもたらす場合がある。この場合、パイプラインマネージャ638は、ビデオ再生アプリケーション内のメディアデータの滑らかさを増大させるために処理パイプライン650内のバッファのサイズを増大させることができる。反対に、メディアデータがユーザインターフェース(UI)アプリケーションまたはゲームアプリケーション用であるとき、低遅延がシンクデバイス660で最も優先度が高い。この場合、パイプラインマネージャ638は、UIアプリケーションまたはゲームアプリケーションについての待ち時間を削減するために処理パイプライン650内のバッファのサイズを減少させることができる。バッファサイズを削減することによって、パイプラインマネージャ638は、UIアプリケーションまたはゲームアプリケーション用のメディアデータが、失速または遅延なしにシンクデバイス660内の処理パイプライン650を通り抜けることを可能にする。
[0115]場合によっては、メディアデータ用のアプリケーションのタイプは、ソースデバイスで検出され、WDシステム内のシンクデバイス660に通知され得る。たとえば、シンクデバイス660は、ソースデバイスから受信された指示に基づいて、受信されたメディアデータ用のアプリケーションを検出することができる。ソースデバイスは、着信したオーディオレートとオーディオデータの画面更新レートとを検出することによって、メディアデータがビデオ再生アプリケーション用であると判断することができる。ソースデバイスは、ビデオ再生エンジン用のメディアデータの開始の指示をシンクデバイス660に送り、ビデオ再生アプリケーション用のメディアデータの終了の別の指示をシンクデバイス660に送ることができる。シンクデバイス660は、メディアプレーヤプロトコルまたは別のプロプライエタリなプロトコルで、メディアデータとともにフラグまたは他のインジケータを受信することができる。
[0116]他の場合、メディアデータ用のアプリケーションのタイプは、シンクデバイス660で検出され得る。シンクデバイス660にあるデコーダ682は、一定の間隔で受信されたメディアデータに含まれるオーディオタイムスタンプに基づいて、受信されたメディアデータ用のアプリケーションのタイプを判断することができる。メディアデータが一定の間隔で対応するオーディオデータを有するビデオデータを含むとき、メディアデータはビデオ再生アプリケーション用であるとみなされ得る。したがって、デコーダ682は、ビデオ再生アプリケーション用のメディアデータを受信しながら、一定の間隔で発生するオーディオタイムスタンプを検出することができる。
[0117]いずれの場合も、受信されたメディアデータがビデオ再生アプリケーション用であることをシンクデバイス660のデコーダ682が知ったとき、パイプラインマネージャ638は、ビデオ再生アプリケーション内の表示の前にメディアデータを保持するために使用されるバッファ、たとえば、レンダリングキュー694またはフレームバッファ696のサイズを増大させる。たとえば、パイプラインマネージャ638は、レンダリングキュー694内に4つ以上のバッファを含むように、かつ4つ以上のフレームバッファ696、たとえば、2つのピンポンバッファと少なくとも2つの保持バッファとを含むように、処理パイプライン650を構成することができる。バッファが大量のメディアデータを保持することが可能であるとき、フレームを落とすリスクは減少し、再生内のジッタの数も減少する。
[0118]一方、受信されたメディアデータがビデオ再生アプリケーション用ではなく、UIアプリケーションまたはゲームアプリケーション用であることをシンクデバイス660のデコーダ682が知ったとき、パイプラインマネージャ638は、UIアプリケーションまたはゲームアプリケーション内の表示の前にメディアデータを保持するために使用されるバッファのサイズを減少させる。たとえば、パイプラインマネージャ638は、レンダリングキュー694内に4つ未満のバッファを含むように、かつ4つ以下のフレームバッファ696、たとえば、2つのピンポンバッファと多くとも2つの保持バッファとを含むように、処理パイプライン650を構成することができる。このようにして、メディアデータは、シンクデバイス660の処理パイプライン650を通り抜けて、待ち時間を改善する。
[0119]場合によっては、パイプラインマネージャ638は、レンダリングキュー694にさらなるメディアデータサンプルを記憶するために、ある時間期間の間レンダラ684を休止することができる。たとえば、パイプラインマネージャ638は、しきい値の数のサンプルがレンダリングキュー694に記憶されるまでレンダラ684を休止し、次いで、レンダリングを再開してビデオ再生の滑らかさを増大することができる。場合によっては、しきい値の数のサンプルは、8個のサンプル、16個のサンプル、または場合によっては16個より多いサンプルに設定され得る。
[0120]加えて、シンクデバイス660は、ソースデバイスにソースデバイスとの通信チャネルのトランスポート状態を記述するフィードバック情報を供給することができる。ソースデバイスは、図5に関してより詳細に上述されたように、フィードバック情報に基づいてその処理パイプラインを修正することができる。たとえば、フィードバック情報は、シンクデバイス660で判断され、ソースデバイスに通信された誤り率またはパケット損失を含む場合がある。場合によっては、ワイヤレスモデム634は、WDシステム内のシンクデバイス660とソースデバイスとの間で確立されたUIBCを介して、シンクデバイス660からソースデバイスにフィードバック情報を送ることができる。他の場合、ワイヤレスモデム634は、異なるソケットリンクを介して、シンクデバイス660からソースデバイスにフィードバック情報を送ることができる。加えて、ワイヤレスモデム634は、RTCPまたは他の何らかのカスタマイズされたシグナリングを使用して、フィードバック情報を通信することができる。
[0121]図7は、シンクデバイスで取得されたユーザ入力データおよび/またはフィードバックデータをソースデバイスに配信するために使用され得る例示的なデータパケット700を示す概念図である。図1を参照してデータパケット700の態様が説明されるが、論じられる技法はWDシステムのさらなるタイプに適用可能であり得る。データパケット700は、その後にペイロードデータ750が続くデータパケットヘッダ710を含む場合がある。データパケット700は、たとえば、シンクデバイス160で受信されたユーザ入力データをシグナリングするため、または、通信チャネル150のトランスポート状態を記述するフィードバック情報をシグナリングするために、シンクデバイス160からソースデバイス120に送信され得る。
[0122]ペイロードデータ750に含まれるデータのタイプ、たとえば、ユーザ入力データまたはフィードバックデータは、データパケットヘッダ710内で識別され得る。このようにして、データパケットヘッダ710のコンテンツに基づいて、ソースデバイス120は、データパケット700のペイロードデータ750を構文解析して、シンクデバイス160からのユーザ入力データまたはフィードバックデータを識別することができる。本開示で使用する「構文解析」および「構文解析する」という用語は、一般に、ビットストリームを解析してビットストリームからデータを抽出するプロセスを指す。データを抽出することは、たとえば、ビットストリーム内の情報がどのようにフォーマットされているかを識別することを含む場合がある。以下でより詳細に記載されるように、データパケットヘッダ710は、ペイロードデータ750用の多くの可能なフォーマットのうちの1つを規定することができる。データパケットヘッダ710を構文解析することによって、ソースデバイス120は、ペイロードデータ750がどのようにフォーマットされているかと、ユーザ入力コマンドまたはフィードバック情報を抽出するためにペイロードデータ750をどのように構文解析すべきかとを判断することができる。
[0123]いくつかの例では、データパケットヘッダ710は、図7に示されたようにフォーマットされた1つまたは複数のフィールド720を含む場合がある。フィールド720に隣接する番号0〜15ならびにビットオフセット0、16、および32は、データパケットヘッダ710内のビット位置を識別するものであり、データパケットヘッダ710内に含まれている情報を実際に表すものではない。データパケットヘッダ710は、バージョンフィールドと、タイムスタンプフラグと、予備フィールドと、入力カテゴリフィールドと、長さフィールドと、オプションのタイムスタンプフィールドとを含む。図7の例では、バージョンフィールドは、シンクデバイス160によって実装されている特定の通信プロトコルのバージョンを示すことができる3ビットのフィールドである。バージョンフィールド内の値は、データパケットヘッダ710の残りをどのように構文解析すべきか、ならびにペイロードデータ750をどのように解析すべきかを、ソースデバイス120に通知することができる。
[0124]図7の例では、タイムスタンプフラグ(T)は、タイムスタンプフィールドがデータパケットヘッダ710内に存在するか否かを示す1ビットのフィールドである。存在する場合、タイムスタンプフィールドは、ソースデバイス120によって生成され、シンクデバイス160に送信されたマルチメディアデータに基づくタイムスタンプを含む16ビットのフィールドである。タイムスタンプは、たとえば、ビデオのフレームがシンクデバイス160に送信されるより前に、ソースデバイス120によってそのフレームに割り当てられる連続値であり得る。データパケットヘッダ710を構文解析し、タイムスタンプフィールドが存在するかどうかを判定すると、ソースデバイス120は、タイムスタンプフィールドに含まれるタイムスタンプを処理する必要があるかどうかを知る。図7の例では、予備フィールドは、バージョンフィールド内で識別される特定のプロトコルの将来のバージョン用に確保された8ビットのフィールドである。
[0125]図7の例では、入力カテゴリフィールドは、ペイロードデータ750に含まれているデータについての入力カテゴリを識別する4ビットのフィールドである。たとえば、シンクデバイス160は、ユーザ入力データを分類して入力カテゴリを特定することができる。ユーザ入力データは、コマンドの受信元のデバイスに基づいて、またはコマンド自体の特性に基づいて、分類され得る。シンクデバイス160はまた、フィードバック情報を分類して入力カテゴリを特定することができる。フィードバック情報は、シンクデバイス160で決定されたフィードバック情報のタイプ、またはフィードバック情報に基づいてソースデバイス120で要求された動作のタイプに基づいて、分類され得る。入力カテゴリフィールドの値は、場合によってはデータパケットヘッダ710の他の情報ととともに、ペイロードデータ750がどのようにフォーマットされているかをソースデバイス120に対して識別する。このフォーマッティングに基づいて、ソースデバイス120は、ペイロードデータ750を構文解析して、ユーザ入力コマンドまたはフィードバック情報を抽出することができる。
[0126]長さフィールドは、データパケット700の長さを示す16ビットのフィールドを備えることができる。データパケット700が16ビットのワードでソースデバイス120によって構文解析されるとき、データパケット700は16ビットの整数までパディングされ得る。長さフィールドに含まれている長さに基づいて、ソースデバイス120は、ペイロードデータ750の終了(すなわち、データパケット700の終了)と新しい後続のデータパケットの開始とを識別することができる。
[0127]図7の例で提供されたフィールドの様々なサイズは単に説明用のものであり、それらのフィールドは、図7に示されたものとは異なる数のビットを使用して実装され得るものである。加えて、データパケットヘッダ710は、上記で説明されたすべてのフィールドよりも少ないフィールドを含む場合があるか、または上記で説明されていないさらなるフィールドを使用する場合があることも考えられる。実際、本開示の技法は、パケットの様々なデータフィールドに使用される実際のフォーマットの点でフレキシブルであり得る。
[0128]図8は、処理パイプライン内のメディアデータの低遅延のフレーム取込みとバッファリングとをサポートすることが可能なソースデバイスの例示的な動作を示すフローチャートである。図示された動作は、図5からのソースデバイス520に含まれる処理パイプライン550に関して記載される。他の例では、図示された動作は、図2からのソースデバイス220、図1からのソースデバイス120、またはWDシステムの別のソースデバイスによって実行され得る。
[0129]ソースデバイス520は、最初にWDシステム内の1つまたは複数のシンクデバイスと通信セッションを確立する(800)。ソースデバイス520は、シンクデバイスとの能力交渉に従って通信セッションを確立することができる。本開示の技法によれば、メディアデータの低遅延のフレーム取込みとバッファリングとをサポートするために、ソースデバイス520のパイプラインマネージャ538は、最小サイズのバッファを含むように処理パイプライン550を構成する(802)。具体的には、パイプラインマネージャ538は、WBバッファ540のサイズを低減して2つのピンポンバッファのみを含むように、処理パイプライン550を構成することができる。処理パイプライン550に沿って通り抜けるようにメディアデータ用のバッファの数を低減すると、ソースデバイス520での待ち時間が削減される。加えて、パイプラインマネージャ538は、メディアデータの少なくとも直近のフレーム更新を保持することが可能な最小サイズのフレームバッファにフレームバッファ542のサイズを低減するように、処理パイプライン550を構成することができる。
[0130]さらに、本技法によれば、パイプラインマネージャ538は、ハードウェア加速器536を使用して処理パイプライン550内のメディアデータの直接メモリアクセスを実行するように、処理パイプライン550を構成することができる(804)。標準メモリコピーを使用してメモリ532および処理パイプライン550内のバッファからメディアデータのフレーム更新を取り出すと、CPU負荷が過剰に使用される。メディアデータのフレームレートを増大させ、待ち時間を削減するために、処理パイプライン550は、代わりにハードウェア加速器536を使用して、フレーム更新にアクセスし、CPUから独立した処理パイプライン550の処理ユニット間を移動させる。
[0131]処理パイプライン550がソースデバイス520内で構成された後、ソースデバイス520は、WDシステム内のシンクデバイスへの送信用のメディアデータの処理を開始することができる。ディスプレイプロセッサ535は、メディアソースからメディアデータのフレーム更新を取り込む(806)。メディアソースは、ソースデバイス520内に含まれるカメラまたは他のメディア取込みデバイスであり得るか、または、有線接続もしくはワイヤレス接続のいずれかを介してソースデバイス520に接続された外部メディアソースであり得る。フレーム更新は、メディアデータの全フレーム、フレームの更新された部分のみを表す部分フレーム、または2つの何らかの組合せを含む場合がある。
[0132]フレーム更新を取り込んだ後、ディスプレイプロセッサ535は、最小サイズのWBバッファ540が一杯かどうかを判定するよう求める要求をWBバッファ540に送る(808)。最小サイズのWBバッファ540が一杯である場合(808のYES分岐)、ディスプレイプロセッサ535から要求を受信すると、WBバッファ540は、WBバッファ540に保持されたより古いフレーム更新のうちの1つまたは複数を削除するようにトリガされる(810)。より古いフレーム更新を削除した後、WBバッファ540は、ディスプレイプロセッサ535によって取り込まれた直近のフレーム更新をバッファリングする(812)。ディスプレイプロセッサ525から要求を受信したとき最小サイズのWBバッファ540が一杯でない場合(808のNO分岐)、WBバッファ540は、ディスプレイプロセッサ535によって取り込まれた直近のフレーム更新を直ちにバッファリングすることができる(812)。フレームバッファ542などの処理パイプライン550に沿った他の最小サイズのバッファ内のフレーム更新をバッファリングするために、同様のプロセスが使用され得る。直近のフレーム更新がWBバッファ540に保持されると、次いで、フレーム更新は、ハードウェア加速器536を介してWBバッファ540からメモリ532に書き込まれ得る。
[0133]加えて、ハードウェア加速器536は、WBバッファ540からフレーム更新を取り出し、処理パイプライン550に沿った処理ユニットとバッファとの間を移動させる(814)。次いで、取り出されたフレーム更新は、WDシステム内のシンクデバイスへの送信用に処理パイプライン550内で処理される(816)。たとえば、プロセッサ531内で、ビデオ処理エンジン(VPE)560は、フレームバッファ542内にフレーム更新をレンダリングし、エンコーダ562は、フレームバッファ542からのフレーム更新を符号化する。符号化されたフレーム更新は、トランスポートユニット533内のパケッタイザ564でフレーム更新をパケット内に形成する前に、コード化ピクチャバッファ(CPB)544にバッファリングされ得る。本技法によれば、符号化されたフレーム更新のメモリコピーをCPB544にバッファリングする代わりに、符号化されたフレーム更新のメモリコピーを作成せずに、メモリ532に記憶された符号化されたフレーム更新へのポインタがCPB544にバッファリングされ得る。
[0134]次いで、ワイヤレスモデム534は、WDシステム内の通信セッションを介して、1つまたは複数のシンクデバイスに処理されたフレーム更新を送信する(818)。処理されたフレーム更新を送信した後、ワイヤレスモデム534は、新しいフレーム更新が送信用に受信されるまで、所定の時間期間後に、処理されたフレーム更新を再送信する(すなわち、重複プッシュを実行する)ことができる。重複プッシュは、シンクデバイスが送信されたフレーム更新を受信し、削除されたパケットを待つ処理時間を浪費しないことを保証することによって、WDシステム内のエンドツーエンドの待ち時間を削減することができる。
[0135]図9は、処理パイプライン内のカスタマイズされたビデオ再生をサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャートである。図6に関して記載される。図示された動作は、図6からのシンクデバイス660に含まれる処理パイプライン650に関して記載される。他の例では、図示された動作は、図3からのシンクデバイス360、図1からのシンクデバイス160、またはWDシステムの別のシンクデバイスによって実行され得る。
[0136]シンクデバイス660は、最初にWDシステム内のソースデバイスと通信セッションを確立する(900)。シンクデバイス660は、ソースデバイスとの能力交渉に従って通信セッションを確立することができる。本開示の技法によれば、処理パイプライン650内でカスタマイズされたビデオ再生をサポートするために、シンクデバイス660は、通信セッションについての能力交渉期間の間にメディアデータのストリーム用のストリームヘッダ情報をソースデバイスと交換する(902)。次いで、パイプラインマネージャ638は、受信されたストリームヘッダ情報に基づいて、シンクデバイス660内の処理パイプライン650を構成する(904)。
[0137]たとえば、ストリームヘッダ情報に基づいて、パイプラインマネージャ638は、ソースデバイスからメディアデータを受信するより前に、処理パイプライン650内のバッファサイズと、レンダリング開始タイマと、同期待ちタイマと、プログラマブルデコーダ設定などとを構成することができる。処理パイプライン650がメディアデータのストリーム用にシンクデバイス650内で構成されると、ワイヤレスモデム634は、シンクデバイス660へのメディアデータのストリームの送信を開始するようソースデバイスに通知することができる(906)。このようにして、復号およびレンダリングされるべきメディアデータをソースデバイスから受信すると、シンクデバイス660は、処理パイプライン線650をセットアップするいかなる処理時間も浪費しない。
[0138]処理パイプライン650が構成された後、シンクデバイス660は、ソースデバイスからのメディアデータの受信を開始する(908)。パーサ680は、符号化されたメディアデータをパケット化解除する。次いで、デコーダ682は、受信されたメディアデータを復号する(910)。受信されたメディアデータは、少なくともビデオデータを含む。復号すると、デコーダ682または処理パイプライン650内の他の何らかの処理ユニットは、復号されたメディアデータがオーディオデータを含むかどうかを検出する(912)。たとえば、デコーダ682は、メディアデータがオーディオデータを含むことを示す、受信されたメディアデータ内のオーディオタイムスタンプを検出することによって、メディアデータがオーディオデータを含むと判断することができる。同様に、デコーダ682は、受信されたメディアデータ内のオーディオタイムスタンプの不在に基づいて、メディアデータがビデオデータのみを含むと判断することができる。
[0139]オーディオデータがメディアデータに含まれていない場合(914のNO分岐)、処理パイプライン650はビデオデータの加速されたレンダリングを実行する。より具体的には、パイプラインマネージャ638は、レンダラ684でビデオデータのオーディオデータとの同期を無効にする(916)。次いで、レンダラ684は、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングする(918)。場合によっては、メディアデータがビデオデータのみを含むとき、パイプラインマネージャ638は、明示的に同期を無効にすることはできないが、いかなるオーディオデータも無視し、存在しないオーディオデータとの同期を待たずにビデオデータをレンダリングするように、レンダラ684を構成することができる。加えて、パイプラインマネージャ638はまた、レンダラ684に適用可能なメディア時間に基づいて、ビデオデータのサンプル時間を増大させることができる。このようにして、レンダラ684は、増大されたサンプル時間に従って、ビデオデータの加速されたレンダリングを実行することができる。
[0140]オーディオデータがメディアデータに含まれている場合(914のYES分岐)、パイプラインマネージャ638は、レンダラ684でのオーディオレンダリング開始タイマを削減することができる(920)。たとえば、いくつかの通信システムの場合、レンダラ684でのオーディオレンダリング開始タイマは、通信システムの初期化を補償するために高く保たれ得る。これはWDシステムに必要ではない。したがって、パイプラインマネージャ638は、オーディオデータがメディアデータに含まれているときでも、待ち時間を削減するために、WDシステム用のオーディオレンダリング開始タイマを削減することができる。次いで、レンダラ638は、ビデオデータをオーディオデータと同期し(922)、削減された開始タイマに従って、同期されたビデオデータとオーディオデータとをレンダリングする(924)ことができる。
[0141]場合によっては、ビデオデータのフレームはデコーダ682内で失速し、レンダラ684がデコーダ682から次のビデオフレームを受信することを待つ、シンクデバイス660でのさらなる待ち時間をもたらす場合がある。本技法によれば、デコーダ682が非プログラマブルデコーダであるとき、パイプラインマネージャ638は、レンダリング用にデコーダ682からビデオデータの復号されたサンプルをプッシュするためにシンクデバイス660でビデオデータにダミーフレームを挿入することができる。デコーダ682がプログラマブルデコーダであるとき、パイプラインマネージャ638は、復号が完了するとすぐにレンダリング用に復号順序でビデオデータの復号されたサンプルを出力するように、プログラマブルデコーダ682を構成することができる。通常、デコーダは、デフォルトではサンプルを表示順序で出力する。この場合、パイプラインマネージャ638は、デコーダ682を介して復号されたフレームをより早く移動させるように、デフォルト設定を変更することができる。
[0142]加えて、ソースデバイスからメディアデータを受信すると、パイプラインマネージャ638は、受信されたメディアデータをレンダリングするより前に、受信されたメディアデータの1つまたは複数のサンプルをデコーダ682からフラッシュすることができる。場合によっては、ソースデバイスから送信された最初の数個のサンプルは、ソースデバイスでより古いメディアデータの失速したサンプルを含む場合がある。パイプラインマネージャ638は、これらのサンプルをシンクデバイス660からフラッシュして、古いメディアデータに対する処理時間およびリソースの消費を回避することができる。
[0143]図10は、処理パイプライン内のメディアデータのアプリケーション認識に基づいて、カスタマイズされたバッファリングをサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャートである。図示された動作は、図6からのソースデバイス660に含まれる処理パイプライン650に関して記載される。他の例では、図示された動作は、図3からのシンクデバイス360、図1からのシンクデバイス160、またはWDシステムの別のシンクデバイスによって実行され得る。
[0144]シンクデバイス660は、最初にWDシステム内のソースデバイスと通信セッションを確立する(1000)。シンクデバイス660は、ソースデバイスとの能力交渉に従って通信セッションを確立することができる。次いで、シンクデバイス660は、ソースデバイスからのメディアデータの受信を開始する(1010)。本開示の技法によれば、処理パイプライン650内のメディアデータ用のアプリケーションのタイプに基づいてカスタマイズされたバッファリングをサポートするために、シンクデバイス660は、受信されたメディアデータ用のアプリケーションのタイプを知り、パイプラインマネージャ638は、アプリケーションのタイプに基づいて処理パイプライン650内のバッファのサイズを調整する。
[0145]受信されたメディアデータ用のアプリケーションのタイプを知るために、パーサ680は、最初にメディアデータ用のアプリケーションのタイプの指示がメディアデータとともにソースデバイスから受信されたかどうかを判定する(1020)。ソースデバイスから指示が受信された場合(1020のYES分岐)、シンクデバイス660のデコーダ682は、ソースデバイスからの指示に基づいて、メディアデータ用のアプリケーションのタイプを知る(1030)。この場合、WDシステム内のソースデバイスは、メディアデータ用のアプリケーションのタイプを検出し、メディアデータ用のアプリケーションのタイプの指示とともにメディアデータをシンクデバイス660に送信する。場合によっては、たとえば、シンクデバイス660は、ビデオ再生アプリケーション用のメディアデータのストリームの指示をソースデバイスから受信することができ、シンクデバイス660はまた、ビデオ再生アプリケーション用のメディアデータのストリームの終了の指示をソースデバイスから受信することができる。
[0146]ソースデバイスから指示が受信されなかった場合(1020のNO分岐)、シンクデバイス660のデコーダ682は、メディアデータ内のオーディオタイムスタンプの存在または不在に基づいて、メディアデータ用のアプリケーションのタイプを知る(1040)。たとえば、デコーダ682は、メディアデータ内の一定の間隔でオーディオタイムスタンプを検出することによって、メディアデータがビデオ再生アプリケーション用であると判断することができる。別の例として、デコーダ682は、受信されたメディアデータ内の一定の間隔でのオーディオタイムスタンプの不在に基づいて、メディアデータがUIアプリケーションまたはゲームアプリケーション用であると判断することができる。
[0147]受信されたメディアデータ用のアプリケーションのタイプがUIアプリケーションまたはゲームアプリケーションであり、ビデオ再生アプリケーションではないことをシンクデバイス660のデコーダ682が知ったとき(1050のNO分岐)、パイプラインマネージャ638は、UIアプリケーションまたはゲームアプリケーション内の表示の前に、処理パイプライン650内でメディアデータを保持するバッファのサイズを減少させるように、処理パイプライン650を構成する(1060)。たとえば、パイプラインマネージャ638は、バッファを通り抜けるメディアデータの待ち時間を削減するためにレンダリングキュー694のサイズおよび/またはフレームバッファ696のサイズを減少させることができる。UIアプリケーションまたはゲームアプリケーションの場合、WDシステム内の主な関心事は低遅延のユーザ体験を提供することであり、ビデオの再生品質はより低い関心事である。
[0148]受信されたメディアデータ用のアプリケーションのタイプがビデオ再生アプリケーションであることをシンクデバイス660のデコーダ682が知ったとき(1050のYES分岐)、パイプラインマネージャ638は、ビデオ再生アプリケーション内の表示の前に、処理パイプライン650内でメディアデータを保持するバッファのサイズを増大させることができる(1070)。たとえば、パイプラインマネージャ638は、ビデオ再生アプリケーション内のビデオ再生の品質(すなわち、滑らかさ)を改善するためにレンダリングキュー694のサイズおよび/またはフレームバッファ696のサイズを増大させることができる。バッファサイズを増大させると待ち時間が増大する場合があるが、ビデオ再生アプリケーションの場合の主な関心事は、増大した待ち時間の何らかのトレードオフを伴う高い品質のビデオ再生ユーザ体験を提供することである。
[0149]レンダラ684は、メディアデータ用に示されたアプリケーションのタイプでの使用のために、レンダリングキュー694からのメディアデータを処理パイプライン650内のフレームバッファ696内にレンダリングする(1080)。次いで、ディスプレイプロセッサ635は、フレームバッファ696からのレンダリングされたメディアデータを、シンクデバイス660で動作するメディアデータ用のアプリケーション内で表示する(1090)。
[0150]場合によっては、メディアデータがビデオ再生アプリケーション用であるとき、パイプラインマネージャ638は、シンクデバイス660がメディアデータのさらなるサンプルを受信するために、レンダリングキュー694からのメディアデータのレンダリングを休止するように、レンダラ684に指示することができる。次いで、パイプラインマネージャ638は、メディアデータのしきい値の数のサンプルがレンダリングキュー694に記憶された後、レンダリングキュー694からのメディアデータのレンダリングを再開するようにレンダラ684に指示する。このようにして、ビデオ再生の品質または滑らかさは、レンダリングされる用意ができたメディアデータの複数のサンプルをレンダリングキュー694内に有することによって、さらに改善され得る。
[0151]図11は、WDシステム内のオーディオデータの優先トランスポートをサポートすることが可能なソースデバイスおよびシンクデバイスの例示的な動作を示すフローチャートである。図示された動作は、図5からのソースデバイス520内の処理パイプライン550に関して、かつ図6からのシンクデバイス660に含まれる処理パイプライン650に関して記載される。他の例では、図示された動作は、図2からのソースデバイス220、図3からのシンクデバイス360、図1からのソースデバイス120およびシンクデバイス160、またはWDシステムの他のソースデバイスおよびシンクデバイスによって実行され得る。
[0152]ソースデバイス520は、最初にWDシステム内のシンクデバイス660と通信セッションを確立する(1100)。ソースデバイス520およびシンクデバイス660は、能力交渉に基づいて通信セッションを確立することができる。本開示の技法によれば、オーディオデータの優先トランスポートを提供するために、ソースデバイス520内のパイプラインマネージャ538は、処理パイプライン550内のビデオ経路よりも多くのバッファリングを含むように、処理パイプライン550内のオーディオ経路を構成する(1110)。加えて、ソースデバイス520内のパイプラインマネージャ538は、ワイヤレスモデムソケット570内のビデオトランスポートキューよりも高い優先度を有するワイヤレスモデムソケット570内のオーディオトランスポートキューを構成する(1120)。
[0153]オーディオデータ用の優先トランスポート経路が構成されると、ソースデバイス520は、別々の処理パイプライン経路内で、オーディオデータとビデオデータの処理を開始する(1130)。オーディオデータとビデオデータが処理されると、ワイヤレスモデム534は、ソケット570内の別々のトランスポートキューから、オーディオデータと関連するビデオデータとをシンクデバイス660にトランスポートする(1140)。
[0154]シンクデバイス660は、WDシステム内の通信チャネルを介してソースデバイス520から、オーディオデータと関連するビデオデータとを受信する(1150)。シンクデバイス660のプロセッサ631は、受信されたメディアデータに基づいて、通信チャネルのトランスポート状態を判断することができる(1160)。たとえば、シンクデバイス660のプロセッサ631は、通信チャネルを介したトランスポート後にメディアデータについての誤り率とパケット損失の量とを判断することができる。シンクデバイス660のトランスポートユニット631は、パケットを生成して、通信チャネルのトランスポート状態を記述するフィードバック情報を、シンクデバイス660からソースデバイス520に送信することができる(1170)。たとえば、ワイヤレスモデム634は、RTCPを使用して、UIBCまたは他のフィードバックチャネルを介してシンクデバイス660からソースデバイス660にパケットを送信することができる。
[0155]通信チャネルのトランスポート状態を記述するフィードバック情報を受信すると、ソースデバイス520のパイプラインマネージャ538は、シンクデバイス660からのフィードバック情報に基づいて、処理パイプライン550を修正することができる(1180)。処理パイプライン550が通信チャネル用に構成されると、ソースデバイス520は、別々の処理パイプライン経路内でのオーディオデータとビデオデータの処理(1130)と、ソケット570内の別々のトランスポートキューからのオーディオデータおよび関連するビデオデータのシンクデバイス660へのトランスポート(1140)とを再開する。
[0156]1つまたは複数の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装することができる。ソフトウェアに実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータデータ記憶媒体またはコンピュータデータ通信媒体を含むことができる。いくつかの例では、コンピュータ可読媒体は、非一時的コンピュータ可読媒体を備えることができる。データ記憶媒体は、本開示に記載された技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスできる任意の利用可能な媒体であり得る。
[0157]限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD−ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリなどの非一時的媒体、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用できる、コンピュータによってアクセスできる、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
[0158]コードは、1つもしくは複数のデジタル信号プロセッサ(DSP)などの1つもしくは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積回路もしくはディスクリート論理回路によって実行することができる。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書に記載された技法の実装に適した他の構造のいずれをも指す。加えて、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成された専用のハードウェアおよび/もしくはソフトウェアモジュールの内部に提供できるか、または複合コーデックに組み込むことができる。また、本技法は、1つまたは複数の回路または論理要素の中に完全に実装することができる。
[0159]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置に実装することができる。開示された技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが本開示に記載されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上述されたように、様々なユニットは、適切なソフトウェアおよび/またはファームウェアとともに、上述された1つまたは複数のプロセッサを含む、コーデックハードウェアユニットにおいて組み合わされるか、または相互動作ハードウェアユニットの集合によって提供することができる。
[0160]本発明の様々な実施形態が記載された。これらおよび他の実施形態は、以下の特許請求の範囲内に入る。