JP2016521518A - ワイヤレス通信システムにおけるビデオストリーミング - Google Patents

Abstract

ワイヤレス通信デバイスに、ダイレクトビデオおよびオーディオストリーミング能力を提供する。ストリーミング能力は、オーバーレイをサポートし、機能性を探索してもよい。いくつかのインプリメンテーションは、ミラキャストのようなミラーリング表示モードを有するデバイスに、これらの特徴を組み込むことを含んでいる。【選択図】図３

Description

背景

［０００１］
最近の進歩は、１つのワイヤレス通信を可能にしたデバイスから別のデバイスに直接的に、ビデオおよびオーディオのダイレクトストリーミングを可能にしている。１つのこのようなシステムは「ミラキャスト（登録商標）」として知られている。ミラキャストは、Ｗｉ−Ｆｉ（登録商標）アライアンスによって公表されたワイヤレス（例えば、ワイヤレスプロトコルのＩＥＥＥ８０２．１１ファミリまたは「Ｗｉ−Ｆｉ」）表示プロトコルに対する商標である。ここで使用するように、用語「ミラキャスト」は、Ｗｉ−Ｆｉディスプレイ（ＷＦＤ）としても知られている、Ｗｉ−Ｆｉアライアンスの表示共有プロトコルの現在の形態を指している。ミラキャスト仕様は、ソースデバイスからシンクデバイスに任意のタイプのビデオビットストリームをストリーミングするように設計されている。１つの例として、ソースはスマートフォンであってもよく、シンクはテレビセットであってもよい。典型的なＩＥＥＥ８０２．１１ワイヤレスネットワークにおいて、クライアントデバイスはアクセスポイント（ＡＰ）デバイスを通して通信するが、ダイレクトデバイス通信をサポートする（Ｗｉ−Ｆｉダイレクトのような）プロトコルが存在する。スマートフォンからテレビまたはコンピュータへのように、１つのデバイスから別のデバイスへ、表示データを送るために、ミラキャストシステムはこのようなプロトコルを使用し、逆もまた同じである。ミラキャストシステムは、Ｗｉ−Ｆｉ接続を通して、ソースデバイスの、フレームバッファおよびスピーカーオーディオのコンテンツを、遠隔ディスプレイ／スピーカーデバイス（シンク）と共有することを伴っている。

［０００２］
ミラキャストプロトコルは、ソースが、ＲＧＢデータをフレームバッファから、任意のＰＣＭ（パルスコード化変調）オーディオデータをオーディオサブシステムから、捕捉することを伴っている。フレームバッファのコンテンツは、ソース上で実行される、アプリケーションプログラムまたはメディアプレーヤーから導出してもよい。その後、ソースは、ビデオまたはオーディオコンテンツを圧縮して、データをシンクデバイスに送信する。ビットストリームを受信すると、シンクは、ビットストリームをデコードし、シンクのローカルディスプレイおよびスピーカーにレンダリングする。

［０００３］
ミラキャスト可能ソースデバイス上で、ユーザが、オーディオ／ビデオクリップをローカルに再生するとき、ビットストリームはデコードされ、ソースディスプレイ上でローカルにレンダリングされ、その後、同時に、オーディオ／ビデオコンテンツは捕捉され、再エンコードされ、ミラキャスト可能シンクデバイスにストリーミングされる。その後、シンクデバイスは同じコンテンツをデコードし、シンクデバイスのディスプレイおよびスピーカーにレンダリングする。このような動作は、「ミラーリング」モードと呼ばれることが多い。

概要

［０００４］
１つのインプリメンテーションにおいて、仲介デバイスを通過することなくソースデバイスからワイヤレスに受信した表示コンテンツを表示する方法を提示する。方法は、第１のビデオ圧縮フォーマットを利用してエンコードされた、イメージフレームの第１のオーバーレイ部分に対する第１の組の表示データパケットを、ソースデバイスから直接、ワイヤレスに受信することを含んでいる。方法は、第２のビデオ圧縮フォーマットを利用してエンコードされた、イメージフレームの第２のオーバーレイ部分に対する第２の組の表示データパケットを、ソースデバイスから直接、ワイヤレスに受信することを含んでいる。方法は、オーバーレイブレンド情報を、ソースデバイスから直接、ワイヤレスに受信することを含んでいる。方法は、イメージフレームの第１のオーバーレイ部分を第１の組の表示データパケットから、イメージフレームの第２のオーバーレイ部分を第２の組の表示データパケットから、抽出することを含んでいる。方法は、ソースデバイスから受信したオーバーレイブレンド情報に少なくとも部分的に基づいて、表示のために、第１のオーバーレイ部分と第２のオーバーレイ部分とをブレンドすることを含んでいる。

［０００５］
別のインプリメンテーションにおいて、表示コンテンツを仲介デバイスを通過させることなく表示コンテンツをシンクデバイスにワイヤレスに送信する方法を提示する。方法は、第１のビデオ圧縮フォーマットを利用して、イメージフレームの第１のオーバーレイ部分に対する第１の組の表示データパケットをエンコードすることを含んでいる。方法は、第２のビデオ圧縮フォーマットを利用して、イメージフレームの第２のオーバーレイ部分に対する第２の組の表示データパケットをエンコードすることを含んでいる。方法は、第１のオーバーレイ部分と第２のオーバーレイ部分とに関係付けられている、オーバーレイブレンド情報を発生させることを含んでいる。方法は、第１の組の表示データパケットと、第２の組の表示データパケットと、オーバーレイブレンド情報とを、シンクデバイスに直接、ワイヤレスに送信することを含んでいる。

［０００６］
別のインプリメンテーションにおいて、表示データシンクデバイスを提示する。デバイスは、ディスプレイと、複数のビデオデコーダと、処理回路とを含んでいる。処理回路は、第１のビデオ圧縮フォーマットを利用してエンコードされた、イメージフレームの第１のオーバーレイ部分に対する第１の組の表示データパケットを、ソースデバイスから直接、ワイヤレスに受信するように構成されている。処理回路は、第２のビデオ圧縮フォーマットを利用してエンコードされた、イメージフレームの第２のオーバーレイ部分に対する第２の組の表示データパケットを、ソースデバイスから直接、ワイヤレスに受信するように構成されている。処理回路は、オーバーレイブレンド情報を、ソースデバイスから、ワイヤレスに受信するように構成されている。処理回路は、イメージフレームの第１のオーバーレイ部分を第１の組の表示データパケットから、イメージフレームの第２のオーバーレイ部分を第２の組の表示データパケットから、抽出するように構成されている。処理回路は、ソースデバイスから受信したオーバーレイブレンド情報に少なくとも部分的に基づいて、第１のオーバーレイ部分と第２のオーバーレイ部分とをブレンドするように構成されている。処理回路は、イメージフレームをディスプレイ上に提示するように構成されている。

［０００７］
別のインプリメンテーションにおいて、表示データソースデバイスを提示する。デバイスは、ディスプレイと、複数のビデオデコーダと、少なくとも１つのメディアプレーヤープログラムと、処理回路とを含んでいる。処理回路は、第１のビデオ圧縮フォーマットを利用して、イメージフレームの第１のオーバーレイ部分に対する第１の組の表示データパケットをエンコードするように構成されている。処理回路は、第２のビデオ圧縮フォーマットを利用して、イメージフレームの第２のオーバーレイ部分に対する第２の組の表示データパケットをエンコードするように構成されている。処理回路は、第１のオーバーレイ部分と第２のオーバーレイ部分とに関係付けられている、オーバーレイブレンド情報を発生させるように構成されている。処理回路は、第１の組の表示データパケットと、第２の組の表示データパケットと、オーバーレイブレンド情報とを、シンクデバイスに直接、ワイヤレスに送信するように構成されている。

［０００８］
別のインプリメンテーションにおいて、表示データを仲介デバイスを通過させることなくソースデバイスからシンクデバイスに表示データをワイヤレスに送信するシステムを提示する。システムは、ディスプレイとワイヤレス送信および受信回路とを有するソースデバイスを含んでいる。システムは、ディスプレイとワイヤレス送信および受信回路とを有するシンクデバイスを含んでいる。ソースデバイスとシンクデバイスは、第１のモードと第２のモードとができるように、表示送信および受信パラメータを交渉するように構成されている。第１のモードでは、表示データは、ソースデバイスのディスプレイフレームバッファから取り出され、ワイヤレス送信のためにエンコードされ、シンクデバイスにワイヤレスに送信され、シンクデバイス上でデコードされ、シンクデバイスのディスプレイ上に提示される。第２のモードでは、ソースデバイスにおいて、少なくとも、イメージフレームの第１のオーバーレイ部分が、第１のビデオ圧縮フォーマットを利用してエンコードされ、イメージフレームの第２のオーバーレイ部分が、第２のビデオ圧縮フォーマットを利用してエンコードされる。第２のモードにおいて、第１のオーバーレイ部分と第２のオーバーレイ部分が、シンクデバイスに対してワイヤレスに送信され、シンクデバイス上で別々にデコードされ、ソースデバイスから受信されたオーバーレイブレンド情報に少なくとも部分的に基づいて、シンクデバイス上でブレンドされ、シンクデバイスのディスプレイ上に提示される。

［０００９］ 図１は、ダイレクトストリーミングをサポートする、拡張ミラキャストビデオストリーミングシステムの１つのインプリメンテーションにおけるソースおよびシンクデバイスのブロックダイヤグラムである。 ［００１０］ 図２は、図１の拡張ミラキャストビデオストリーミングシステムの１つのインプリメンテーションにおけるソースデバイスのブロックダイヤグラムである。 ［００１１］ 図３は、図１の拡張ミラキャストビデオストリーミングシステムの１つのインプリメンテーションにおけるシンクデバイスのブロックダイヤグラムである。 ［００１２］ 図４は、ミラーリングからダイレクトストリーミングへとスイッチするためのメッセージシーケンスの１つのインプリメンテーションを図示するシーケンスダイヤグラムである。 ［００１３］ 図５は、シンク側の探索機能性に対するメッセージシーケンスの１つのインプリメンテーションを図示するシーケンスダイヤグラムである。 ［００１４］ 図６は、シンクデバイスにおいてオーバーレイ処理をサポートする、拡張ミラキャストビデオストリーミングシステムにおけるトランスポートストリームの１つのインプリメンテーションを図示している。 ［００１５］ 図７は、シンクデバイスにおいてオーバーレイ処理をサポートする、拡張ミラキャストビデオストリーミングシステム１つのインプリメンテーションのブロックダイヤグラムである。 ［００１６］ 図８は、シンクデバイスにおいてオーバーレイ処理をサポートする、拡張ミラキャストビデオストリーミングシステムのシンクデバイスにおけるブレンドモジュールの１つのインプリメンテーションのブロックダイヤグラムである。 ［００１７］ 図９は、ソースデバイスまたはシンクデバイスのうちの１つインプリメンテーションのブロックダイヤグラムである。

詳細な説明

［００１８］
添付した図面を参照して、新規なシステム、装置、および方法のさまざまな態様を以下でさらに十分に説明する。しかしながら、開示する教示は、多くの異なる形態で具現化され、この開示全体を通して提示する、何らかの特定の構造または機能に限定されるものとして解釈すべきではない。むしろ、この開示が、徹底して完全なものになるように、および、本開示の範囲を当業者に十分に伝えるために、これらの態様を提供する。ここでの教示に基づいて、本開示の範囲は、本発明の他の何らかの態様と独立して、または、本発明の他の何らかの態様と組み合わせて実現するか否かにかかわらず、ここで開示した新規なシステム、装置、および方法の何らかの態様をカバーすることを意図していることを、当業者は認識すべきである。例えば、ここで述べる任意の数の態様を使用して、装置を実現してもよく、または、方法を実施してもよい。さらに、ここで述べる本発明のさまざまな態様に加えて、または、ここで述べる発明のさまざまな態様以外の、他の構造、機能性、または、構造および機能性を使用して実施される、このような装置または方法をカバーすることを、本発明の範囲は意図している。ここに開示した任意の態様は、請求項の１つ以上のエレメントにより具現化してもよいことを理解すべきである。

［００１９］
特定の態様をここで説明するが、これらの態様の多くのバリエーションおよび置換が、本開示の範囲内に入る。好ましい態様のいくつかの利益および利点に言及するが、本開示の範囲は、特定の利益、使用、または、目的に限定されることを意図していない。むしろ、本開示の態様は、異なるワイヤレス技術、システムコンフィギュレーション、ネットワーク、および、送信プロトコルに広く適用可能であるように意図されており、そのうちのいくつかは、例として、図面中で、および、好ましい態様の以下の説明中で示されている。詳細な説明および図は、限定よりむしろ、本開示の単なる例示であり、本開示の範囲は、添付の特許請求の範囲およびそれらの均等物により規定される。

［００２０］
本開示は、ソースとしてここで呼ばれている第１のデバイスが、シンクとしてここで呼ばれている第２のデバイスに、第２のデバイス上の表示のために、ビデオコンテンツを配信できるようにする、システムおよび方法に向けられている。いくつかのインプリメンテーションにおいて、各デバイスは、ワイヤレス通信プロトコルのＩＥＥＥ８０２．１１ファミリのうちの１つ以上にしたがって、ワイヤレスに通信することができる。このようなデバイスは、典型的に、直接よりもむしろアクセスポイント（ＡＰ）を通して通信するが、任意のＡＰまたは他の仲介を使用することなく、ソースデバイスがシンクデバイスに直接ビデオを送信できるようにプロトコルが開発されている。上記で説明したように、１つのこのようなプロトコルは、ミラキャストまたはＷｉ−Ｆｉディスプレイとして知られている。以下で説明するインプリメンテーションは、現存するミラキャストプロトコルの一般に使用されているミラーリングモードで、現存するミラキャストプロトコルを開始点として使用する。このプロトコルの強化および拡張は以下で述べる。これらの強化および拡張は、ミラキャストに対する適用だけでなく、ローカル環境においてワイヤレスに接続されているデバイス上でおよびローカル環境においてワイヤレスに接続されているデバイス間で、表示データの送信、受信、および表示できるようにする、任意の表示共有デバイスまたはプロトコル、システム、あるいは方法に対する適用を有し、ここで、「ローカル」は一般的に、部屋、ビルディング、および、これらに類するものの内のような、ワイヤレスＬＡＮ接続の範囲を指す。

［００２１］
ビデオクリップが、ミラキャストタイプシステム中のソースデバイス上で再生される場合、ミラキャストタイプシステムのベーシックモード（ミラーリング）によるミラキャストは、ビデオクリップがデコードされた後にビデオ出力を捕捉することを要求し、その後、ビデオクリップをシンクデバイスにストリーミングする前に、Ｈ．２６４コーデックでビデオクリップを再エンコードすることを要求する。このような動作は、トランスコーディングと呼ばれることが多く、ビデオクリップは最初にビデオデコーダを使用して、クリップをデコードし、その後、デコードされたビデオクリップを、シンクデバイスにストリームする前に再エンコードするので、より多くの電力をデバイスに消費させる。

［００２２］
特に、エンコードされたビットレートがビデオクリップのネイティブビットレートよりも、より低いとき、ビデオのトランスコーディングは、ビデオ品質を潜在的に下げるかもしれない。ビデオコンテンツは他のフォーマットで利用可能になることが多い一方で、現在のミラキャストインプリメンテーションは、Ｈ．２６４コーデックの、制約されたベースまたは制約された高いプロフィールのみを使用して、再エンコードすることを要求することから、これは生じるかもしれない。

［００２３］
これらの制限を克服するために、追加でダイレクトストリーミング能力をサポートするように、ワイヤレス通信可能デバイスを補うことができる。これは、トランスコーディングの必要なく、オーディオ／ビデオコンテンツのストリーミングを可能にする。これは、トランスコーディングをうまく回避することによる、ビットストリームのストリーミングを通しての電力削減と、より高い品質とを可能にする。

［００２４］
これから、図１〜３を参照すると、拡張されたミラキャストシステムにおいて、ソースデバイス３０とシンクデバイス３２との間で、追加の制御通信および転送プロトコル交渉が生じることがある。図１中に示すように、ソース３０において、表示データ３４がエンコーダ３６にルーティングされている。従来のミラキャストシステムでは、エンコーダ３６とデコーダ３８を唯一サポートしているのは、Ｈ．２６４プロトコルである。このデータは、その後、従来のミラキャストシステムにおけるリアルタイムトランスポートプロトコル（ＲＴＳＰ）メッセージングにより、ＭＰＥＧ２トランスポートストリームを使用して、ワイヤレスにシンク３２に対して送信される。データがシンク３２において受信されたとき、対応するデコーダ３８にルーティングされ、シンク３２上のディスプレイ４０に送られる。制御信号も、ソース３０とシンク３２との間で渡される。従来のミラキャストシステムでは、セッションセットアップとセッション維持のために、制御信号が利用される。図１〜３のシステムにおいて、ソース３０とシンク３２との間に、１つ以上の追加の制御通信が生じるかもしれない。１つのインプリメンテーションにおいて、能力交渉の間、シンクがシンク自体で特徴をサポートするか否かを確かめるために、ソース３０はシンク３２にダイレクトストリーミングについて問い合わせる。ソース３０はまた、シンク３２がサポートする、オーディオおよびビデオに対するさまざまな、コーデックおよびプロフィールについてと、シンク３２がソースにストリームコンテンツを向けてもらいたい、ＴＣＰ（送信制御プロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）ポート番号について問い合わせる。ミラキャストセッションの間、シンク３２がダイレクトストリーミングをサポートする場合、シンク３２は、オーディオ／ビデオコーデックおよびプロフィールのリストと、ＴＣＰまたはＵＤＰポート番号とともに返答してもよい。１つのビデオクリップをストリーミングした後、別のビデオクリップをダイレクトストリーミングデータパスにスイッチしてもよい。これは、以下でこれからさらに説明する利点とともに、さまざまな、エンコーダ３６とデコーダ３８の使用を可能にする。これから以下でさらに説明するように、オーバーレイを取り扱うサポートと、シンク側の探索機能性も提供することができる。

［００２５］
これから図２を参照すると、図１のソースデバイス３０の１つのインプリメンテーションのブロックダイヤグラムが図示されている。図２において、ソースデバイスは、グラフィック処理ユニット（ＧＰＵ）５０と、ディスプレイプロセッサ／ブレンダ５２と、フレームバッファ５４と、ディスプレイ５６とを含んでいる。ソースは、ユーザへの表示のために、表示データを提供できる、アプリケーション１ ６２およびアプリケーション２ ６４のような、いくつかのアプリケーションを実行してもよい。ソースオペレーティングシステムの制御下で、ＧＰＵ５０とディスプレイプロセッサ／ブレンダ５２は、ディスプレイ５６に転送するために、表示データを準備し、フレームバッファ５４を埋める。ソースは、ビデオデコーダを通してコンテンツをディスプレイプロセッサ／ブレンダ５２にもルーティングするメディアプレーヤー６６も含んでいてもよい。

［００２６］
従来の独立型の表示モードにおけるデータフローと、従来のミラキャストミラーリングモードにおけるデータフローとが、図２の実線の矢印によって図示されている。ミラキャストミラーリングが実行されるとき、フレームバッファ５４におけるピクセルデータの連続するフレームは、データパス８０に沿ってビデオエンコーダ７２にルーティングされ、エンコードされたデータは、モジュール７４によってＭＰＥＧ２トランスポートストリームにアセンブリされ、モジュール７５によってＲＴＰメッセージングデータと組み合わされ、シンクデバイス３２への送信のために、ソケット７７にルーティングされる。従来のミラキャストでは、エンコーダ７２は、Ｈ．２６４エンコーダであり、ソケットは、ＵＤＰソケットであり、他のオプションはサポートされていない。

［００２７］
シンクデバイス３２が、図３中に図示されている。シンクにおいて、ソケット９２が、到来データストリームを受信し、ＲＴＰメッセージングが、モジュール９４により抽出され、表示データが、モジュール９６により抽出される。図２のように、従来のミラキャストデータフローは、実線の矢印で図示されている。表示データは、ビデオデコーダ９８にルーティングされ、その後、ディスプレイプロセッサ／ブレンダ１０２にルーティングされてもよく、これは、ディスプレイ１０６上の表示のために、フレームバッファ１０４を埋める。従来のミラキャストでは、ビデオデコーダ９８は、Ｈ．２６４デコーダであり、Ｈ．２６４デコーダは、ミラキャスト標準規格と互換性のある任意のシンクデバイスにおいて要求される。

［００２８］
従来のミラキャストシステムでは、シンク３２への送信のために、フレームバッファからピクセルデータが取り出されることから、表示情報のどのタイプがフレームバッファ５４中にロードされているかに関する利用可能な情報がないことが理解できる。表示情報のどのタイプがフレームバッファ５４中にロードされているかに関する利用可能な情報は、アプリケーションプログラム６２および６４からのテキスト、または、メディアプレーヤー６６からのムービー、または２つの組み合わせであることがある。多くのケースにおいて、この情報は、シンク表示品質を最適化する際と、ソースデバイスの電力ドレインを最小化する際に、有用であることがある。

［００２９］
従来のミラキャスト表示システムの性能および能力を拡張するために、システムによって、追加のビデオエンコーダ８２、８４をサポートすることができ、破線の矢印によって図示されている追加のデータパスを提供できる。

［００３０］
１つのインプリメンテーションにおいて、データパス８０におけるフレームバッファ入力を使用する代わりに、ＭＰＥＧ２トランスポートストリームにトランスコードすることなく、モジュール７４によって、メディアプレーヤー６６からの予めエンコードされているビットストリームを含むダイレクトストリーミングパス８６自体をアセンブルすることができる。これは、トランスポートストリームアセンブリより前に、ビデオデコーダ６８による最初のデコードと、後続する、ビデオエンコーダ７２によるＨ．２６４再エンコードとの実行を回避する。これは、ソース３０における電力をセーブする。シンクデバイス３２において、メディアプレーヤー６６からの表示データ出力の、元の予めエンコードされたフォーマットに対応するデータはデコーダによりデコードされ、このフォーマットは、Ｈ．２６４フォーマットでないかもしれない。このインプリメンテーションにおいて、シンクデバイスが互換性のあるデコーダである限り、上記で説明したクエリプロセスの間に、ソースデバイスによって決定される、任意のエンコードフォーマットが適切である。図２〜３を参照すると、例えば、このインプリメンテーションにおいて、ビデオデコーダ９８上の唯一の制限は、図２のパス８６からの元の予めエンコードされたビットストリームをデコードできることである。

［００３１］
ダイレクトストリーミングに対する少なくとも２つのオプション、ＲＴＳＰベースのメッセージングおよびＭＰＥＧ２−ＴＳベースのメッセージングを、利用してもよい。

［００３２］
ＲＴＳＰベースのメッセージングが、図４に図示されている。システムは、状態１１０において、従来のミラキャストプロトコルにおいてのように、表示ミラーリングモードで開始してもよく、ここで、（例えば、上記で説明したような図２および３の実線を利用して）イメージデータは、ソースのフレームバッファから取得され、ソースにおいてＨ．２６４エンコードされ、シンクにおいてＨ．２６４デコードされる。このモードは、上記でも説明したように、表示データのトランスコードを要求する。シンク３２が互換性のあるコーデックを含んでいるエンコードフォーマットで、ソースによって、記憶され、発生され、または、受信される、ビデオクリップを再生することを、ソースデバイス３０のユーザが選択する場合、１１２において、ミラーリングからダイレクトストリーミングへのストリームスイッチがこれから開始することを示すＲＴＳＰ要求メッセージを、ソース３０デバイスは送ってもよい。シンクがこの要求を受信するとき、１１４において、シンクはミラーリングからダイレクトストリーミングにビットストリームを変更するように、ソースに応答し、交渉されたＴＣＰ／ＵＤＰポート上で新たなビットストリームを受信するためにシンクのデコーダを準備し、シンクはダイレクトストリーミングに対して準備ができていることをソースに通知する。ブロック１１５において、シンクからの応答を受信すると、ソースはミラーリングビットストリームを停止し、ビデオクリップ中に含まれるビットストリームを、この目的のために交渉されたＴＣＰ／ＵＤＰポートにストリームし始め、ダイレクトストリーミングモードに入る。ユーザがクリップを停止する場合、または、クリップがストリームの終わりに達する場合、１１６において、ソースは、ダイレクトストリーミングが終了であることを示すＲＴＳＰ要求を送る、すなわち、ダイレクトストリーミングからミラーリングへのストリームスイッチが開始する。シンクがこの要求を受信するとき、１１８において、シンクは、ビットストリームをダイレクトストリーミングからミラーリングモードに変更するように、ソースに応答し、ミラキャストセッションに対してセットアップされたデフォルトミラキャストポート上でミラーリングビットストリームを受信するためにシンクのデコーダを準備する。シンクからの応答を受信すると、ソースは、１２０においてミラーリングモードに入り、デフォルトミラキャストポートにミラーリングビットストリームをストリーミングし始める。

［００３３］
別の可能性あるインプリメンテーションにおいて、ＵＤＰトランスポートポートを使用するときに、ＭＥＰＧ２ＴＳベースのメッセージングを使用してもよい。例えば、ソースデバイスのユーザが、コーデックとプロフィールがシンクによってサポートされているビデオクリップを再生することを選択する場合、ダイレクトストリーミング用に、新たなビットストリームをトランスポートするための異なるアクティブなプログラム番号を使用するために、ソースデバイスは、プログラム関係付けテーブル（ＰＡＴ）とプログラムマップテーブル（ＰＭＴ）を変更する。シンクが新たなＰＡＴとＰＭＴを受信するとき、シンクはミラーリングビットストリームを再生するのを停止し、ミラーリングの間に使用されていたのと同じＵＤＰポート上で継続的に受信されることになる新たなビットストリームを受信するために、シンクのデコーダを準備する。更新されたＰＡＴとＰＭＴを送った後、ソースは、ビデオクリップ中に含まれるビットストリームを、ミラーリングビットストリームと同じＵＤＰポートにストリーミングし始める。ユーザがクリップを停止する場合、または、クリップがストリームの終わりに達する場合、ソースはＰＡＴとＰＭＴを、アクティブブログラムとしてミラーリングプログラム番号のものに変更し戻す。シンクが更新されたＰＡＴとＰＭＴを受信するとき、シンクは、ダイレクトストリーミングビットストリームを再生するのを停止し、同じＵＤＰポート上で継続的に受信されることになるミラーリングビットストリームを受信するために、シンクのデコーダを準備する。

［００３４］
上記で説明したインプリメンテーションにおいて、ビデオコンテンツの現在の圧縮フォーマットは、シンクデバイス上の既存のコーデックと互換性がある、とソースは決定してもよく、ソースは元のフォーマットでビデオコンテンツを送ってもよく、それにより、従来のミラキャストシステムによって実行されるトランスコーディングプロセスを避ける。いくつかのインプリメンテーションにおいて、異なる圧縮フォーマットを使用することが有利であるとチャネル状態（または他の情報）が示すかもしれない。なぜなら、ソースはシンク上のコーデックを知っていることから、ソースは、異なるシンクコーデックと互換性のある異なる圧縮フォーマットを選んで、使用するかもしれないからである。これは、元のビデオコンテンツをトランスコードすることを伴っているが、チャネル状態に依存して、シンクデバイス上のビデオ品質を向上させるかもしれない。

［００３５］
ビデオコンテンツのダイレクトストリーミングの間、探索機能性を、柔軟にサポートすることができる。ライブセッションは、ソースデバイス上の表示フレームバッファのコンテンツを使用してストリームされるという事実により、探索機能性は、ミラキャスト中には現存しない。ミラーリング中の間に、時間的に行ったり来たりすることは、実用的ではない。しかしながら、ダイレクトストリーミングの間、ソースからシンクにストリームされるメディアクリップを巻き戻しおよび早送りする要望があるかもしれない。

［００３６］
例えば、ソースにおけるユーザ入力に基づいて、ソースが探索トリガを開始するとき、ソースは、所望の「表示時間」値とともに休止または再生アクションにセットされたＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲトリガ方法を送ってもよい。この後、シンクは、トリガ要求に対する応答を送り返してもよく、ソースは、その後、新たな時間からストリームする準備できているとき、新たな再生要求メッセージを開始してもよい。

［００３７］
シンク側探索要求の例が、図５において提供されている。この例において、シンクが探索を開始するとき、シンクは、１２６において、休止のためのＭ９要求を送ることができ、ソースは、１２８において、ストリーミングを停止し、ストリーム停止肯定応答をシンクに送ってもよい。１３０において、シンクは、シンクのユーザがビデオ再生に対する新たな開始点として選択する、ビデオクリップ中の時間に対応する、所望の「表示時間」値とともに再生要求をソースに送ってもよい。１３２において、シンクが選択した新たな時間から、ソースがストリーミングを開始する。

［００３８］
現在、ビデオとともにオーバーレイコンテンツをソースからシンクに送る能力は、現在のミラキャスト仕様においてサポートされておらず、現在のミラキャスト仕様は、単一のフォーマットのみを使用して、ビデオコンテンツをストリームする。オーバーレイ能力なしでの、ビデオ再生のフルスクリーンモードのみが可能である。ソースのフレームバッファにおけるフルスクリーンは、表示の異なる部分におけるコンテンツの特質に関わらず、同じビデオエンコーダによりエンコードされる。いくつかのインプリメンテーションにおいて、拡張されたシステムは、柔軟に複数のオーバーレイを可能にし、シンク側で実行される柔軟なオーバーレイ動作を提供することができる。

［００３９］
図２〜３に戻って参照すると、各イメージフレームの異なるオーバーレイコンポーネントに対して、図２のエンコーダ７２、８２、および８４による別々のエンコーディングプロセスを使用して、インテリジェントなオーバーレイサポートを提供してもよい。各オーバーレイに対するエンコードされたデータは、モジュール７４によって、単一のＭＰＥＧ２トランスポートストリームにアセンブルしてもよい。エンコーダ７２、８２、および８４は、同じまたは異なるフォーマットのものであってもよい。異なるオーバーレイに対して異なるフォーマットのエンコーディングを使用するとき、グラフィックおよびＵＩに対しては無損失なコーデックや、損失のある圧縮アーティファクトが簡単には見えない、ビデオおよび他のコンテンツに対しては損失のあるコーデックのような、最適な性能を達成することが可能である。また、オーバーレイに対するサポートは、グラフィックに対してフレームバッファコンテンツにおけるインクリメントな変化のみを送ることや、高解像度コンテンツディスプレイに対する帯域幅要件を減少させることを可能にする。ミラキャストに対するこのような拡張は、複数のオーバーレイに柔軟にサポートでき、オーバーレイコンテンツを、シンクデバイスにストリームして、シンクディスプレイにおける関心ある所望の領域に対して表示することができる。

［００４０］
図３において図示されている、シンク３２側上で、ＭＰＥＧ２トランスポートストリームの異なる部分におけるデータを、抽出し、別々のデコーダ９８、１４０、および／または１４２にルーティングすることができ、デコーダ９８、１４０、および／または１４２は、ソース３０上で実行されたそれぞれのエンコーディング方法にしたがって、別々にデータストリームをデコードできる。その後、フレームバッファ１０４に入れて、シンクディスプレイ１０６上で表示するために、オーバーレイデータは、制御情報にしたがって、ディスプレイプロセッサ／ブレンダ１０２によって、シンク側上でブレンドされてもよく、制御情報は、（以下でさらに説明するような）ＭＰＥＧ２／ＲＴＰストリームとともに送られてもよい。

［００４１］
通常のビデオ表示とともに、ディスプレイの所望のロケーションにおいて、あるグラフィックまたはＵＩ制御情報を表示することに対して、より高いビジュアル品質が必要であるとき、１つ以上のオーバーレイコンテンツを同時に送信する要望が、多くのゲームおよびＷｉ−Ｆｉディスプレイの他の使用において生じる。オーバーレイ表示コンテンツは、生のＲＧＢまたは他の無損失な圧縮方法を使用してもよい。

［００４２］
ビデオデータとともにオーバーレイをストリームすることをサポートするために、追加のメッセージングおよびプロトコル拡張を、ミラキャストプロトコルに追加してもよい。ダイレクトストリーミング交渉の間、ソースおよびシンクデバイスは、パラメータを交換して、シンクがオーバーレイをサポートできるか否かや、組み合わせたフレームコンポジションと、オーバーレイコンテンツとをブレンドするのにどの方法をサポートできるかを交渉できる。圧縮されたおよび圧縮されていないＲＧＢオーバーレイフレームを、ＭＰＥＧ２ＴＳに多重化および多重分離する方法を提供でき、オーバーレイに対してサポートされているビデオフォーマット、例えば、ＲＧＢ、または、クロマフォーマット、または、何らかの特定のコーデックフォーマット、を決定して、交渉できる。

［００４３］
ＲＴＳＰメッセージングに対して、ソースは、ビデオコーデックのサポートと、オーバーレイがサポートされているか否かおよびいくつのオーバーレイがサポートされているかについての能力情報とに対して、シンクと交渉してもよい。ソースは、バックグラウンドフレームに対するコーデックタイプと、オーバーレイに対するコーデックタイプとを選ぶ、パラメータを設定してもよい。いくつかのインプリメンテーションにおいて、最大２つのコーデックタイプが許容されてもよい。例えば、バックグラウンドは、ＪＰＥＧでエンコードすることができ、ビデオオーバーレイは、Ｈ．２６４でエンコードすることができる。または、バックグラウンドとオーバーレイの両方を、Ｈ．２６４でエンコードしてもよい。ソースは、送られることになる最大数のオーバーレイに対するパラメータも設定してもよい。

［００４４］
図６は、ＭＰＥＧ２ＴＳシグナリングを使用する例を図示している。この例において、各オーバーレイには、（７６ａ、７６ｂ、７６ｃ、７６ｄで指定されている）パケット化エレメンタリストリーム（ＰＥＳ）ヘッダ中でオーバーレイを説明する特性が先行していてもよい。各ヘッダには、対応するオーバーレイデータパケット７８ａ、７８ｂ、７８ｃ、および、７８ｄが続いている。ＭＰＥＧ２トランスポートストリームにおけるＰＥＳヘッダフォーマットはとても柔軟であり、システム特有情報転送に対して使用することができる、ヘッダ中のプライベートデータフィールドの生成をできるようにする。ＰＥＳヘッダ中に含まれるオーバーレイ特性は、バックグラウンドに関連するオーバーレイのロケーションに印をつけるために、左上座標（ｘ，ｙ）を含んでいてもよい。ｘに対して２バイト、ｙに対して２バイトであるＡを有する座標は、ピクセルロケーションのものであってもよい。オーバーレイの幅および高さに対して、Ｗ＝幅に対して２バイト、Ｈ＝高さに対して２バイトである。オーバーレイがバックグラウンドにブレンドされる順序も提供してもよく、１バイトであるＺを有する下位数は、オーバーレイを最初にブレンドすべきであると示している。０ｘ００は、バックグラウンドレイヤを示しており、アルファ＝１バイトであるアルファに対する値を提供してもよい。色キーに対する３バイトＣＫ値を提供してもよい。

［００４５］
図７は、特定のオーバーレイストリーミングの例を図示している。この例において、フォアグラウンドオーバーレイ１５０は、バックグラウンドビデオストリーム１５２と組み合わされる。オーバーレイ１５０は、ビデオプレーヤー６６、ソース３０上の異なるアプリケーションプログラム６２または６４、あるいは、ソース３０のオペレーティングシステムによって発生させてもよい。図７は、トランスコーディングすることなく、その予めエンコードされた状態において、ビデオデータをストリームする例を図示している。オーバーレイは、異なる無損失な圧縮エンコーディングによりエンコードされる。シンク３２側上で、ＭＰＥＧ２ＴＳ／ＲＴＰストリームは、アンパックされ、２つのデータセットは、ＭＰＥＧ２ＴＳ／ＲＴＰストリームにおいて提供されるオーバーレイ情報にしたがって、モジュール１０２におけるブレンドのために、別々にデコードされる。

［００４６］
シンク側において、合成されたバックグラウンドレイヤとフォアグラウンド（オーバーレイ）との間にブレンド式を適用してもよい。例えば、
ブレンドされたピクセル＝アルファ*ピクセル_ＦＧ＋（１−アルファ）*ピクセル_ＢＧ
最終ピクセル＝色キーを使用する透過チェックがパスした場合、フォアグラウンドピクセル
そうでなければ、最終ピクセル＝ブレンドされたピクセル。

［００４７］
このアルゴリズムは、図８の機能性ブロックダイヤグラムによって実現される。この図において、オーバーレイレイヤ０のピクセル１６０は、異なるオーバーレイレイヤ１ １６２の対応するピクセルにより処理される。選択信号ｂｌｅｎｄ＿ｅｑ＿ｓｅｌは、マルチプレクサ１６４および１６６を使用して、どのオーバーレイがフォアグランウンドであり、どれが、バックグラウンドであるかを決定する。別の制御信号ｂｌｅｎｄ＿ｔｒａｎｓｐ＿ｅｎは、ブロック１７２において、透過色チェックが実行されるか否かを決定する。透過色チェックがパスした場合、バックグラウンドピクセルがマルチプレクサ１７４から出力され、そうでなければ、ブロック１７６からのブレンドされたピクセルが、そのピクセルロケーションにおける表示のために、シンク３２のマルチプレクサ１７４からフレームバッファ１０４へ出力される。ブロック１７６において実現されるブレンド式に対するパラメータと、制御信号のステータスは、ＭＰＥＧ２トランスポートストリーム上でソース３０から送られる情報によって制御してもよい。

［００４８］
例えば、シンクデバイスは、ブレンド動作が開始する前に、Ｚ＝０ｘ００によって印付けられ、（スタートアップにおいて交渉された）総オーバーレイに一致するオーバーレイカウントであるバックグラウンドレイヤを受信するのを待ってもよい。バックグラウンドレイヤは、幅および高さにおいて、オーバーレイよりもより大きくてもよく、交渉したシンクの表示解像度に一致していてもよい。Ｚ＝０ｘ００を受信した後に受信する次のオーバーレイがなく、かつ、表示タイムアウト時間を超えてしまった場合、その後、オーバーレイプロセスは終了してもよく、レンダリングのために、フレームをディスプレイに送ることができる。表示タイムアウト時間は、受信フレームレートに基づいていてもよい。例えば、受信されている表示データのフレームレートが３０ｆｐｓである場合、表示タイムアウトは、約３３ミリ秒であってもよい。

［００４９］
ミラキャストセッションの間、スタートアップにおいて交渉されたオーバーレイの最大数を任意の数のオーバーレイが超えない限り、任意の数のオーバーレイは、任意の瞬間に開始してもよい。各オーバーレイは、交渉したコーデック、すなわち、ＪＰＥＧ、Ｈ．２６４に基づいた、オーバーレイ自身の基本ストリームを有してもよい。オーバーレイを伝えるプログラムから追加されたまたは取り除かれた、基本ストリームがある毎に、ＭＰＥＧ２トランスポートストリームに対するプログラムマップテーブル（ＰＭＴ）を更新してもよい。新たな基本ストリームが追加される場合、その後、連続するＭＰＥＧ２トランスポートパケットは、新たな基本ストリームに対するＰＥＳパケットを含んでいてもよい。シンク上のブレンダが、レンダリングされることになる最終フレームを構成できるように、各基本ストリームは、オーバーレイのある詳細を伝えてもよい。新たなＰＥＳ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇを使用して、ＰＥＳ中のでのオーバーレイ情報の存在を示してもよい。新たなフィールドをＰＥＳ中に加えて、座標、幅、高さ、Ｚ順序、アルファ値、色キーおよびブレンド式を含む、ＰＥＳ中でオーバーレイ情報を伝えてもよい。レンダリングされることになる最終フレーム発生させるために、この情報を、シンク上のディスプレイプロセッサに渡してもよい。

［００５０］
上記で説明したように、いくつかのインプリメンテーションにおいて、ミラキャストプロトコルの拡張は、サポートされているコーデックパラメータを含む相互能力を、および／または、ダイレクトストリーミング間の使用のためにＴＣＰポートを生成させるシンクのオプションを交渉できる。ミラキャストの別の拡張は、待ち時間対頑強性の要件（例えば、ＴＣＰまたはＵＤＰを使用するか否か）に依存して、ＲＴＳＰベースのアプローチとＭＰＥＧ２−ＴＳベースのアプローチを使用して再生する間に、ビットストリームのスイッチングをサポートできる。ミラキャストの拡張は、ダイレクトストリーミングモードを使用している間に、探索機能性をサポートできる。ミラキャストプロトコルの拡張は、ミラキャストセッションを通して送られる複数のオーバーレイをサポートでき、シンクは、ＲＴＰＳを通したオーバーレイシグナリングと、オーバーレイブレンド技術と、オーバーレイトランスポートのためのＰＥＳ情報とを含む、予め交渉した、ビデオフォーマットおよびブレンドモードを使用して、組み合わされたフレームコンポジションをレンダリングしてもよい。

［００５１］
図９は、上記で説明したワイヤレス通信システム内で用いてもよい、ワイヤレスデバイス１８０において利用できる、さまざまなコンポーネントを図示している。ワイヤレスデバイス１８０は、ここで説明するさまざまな方法を実現するように構成されていてもよいデバイスの例である。

［００５２］
ワイヤレスデバイス１８０は、ワイヤレスデバイス１８０の動作を制御するプロセッサ１８４を含んでいてもよい。プロセッサ１８４は、中央処理ユニット（ＣＰＵ）と呼ばれることもある。リードオンリーメモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＯＭ）の両方を含んでいてもよいメモリ１８６は、命令およびデータをプロセッサ１８４に提供する。メモリ１８６の一部分は、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）も含んでいてもよい。プロセッサ１８４は典型的に、メモリ１８６内に記憶されているプログラム命令に基づいて、論理および演算動作を実行する。メモリ１８６中の命令は、ここで説明する方法を実現するために実行可能であってもよい。例えば、デバイスが、ソース３０、シンク３２、または、両方であるか否かに依存して、図１、２、および３のブロックを、プロセッサ１８４およびメモリ１８６によって実現してもよい。プロセッサ１８４は、１つ以上のプロセッサによって実現する処理システムのコンポーネントを含んでもよく、または、１つ以上のプロセッサによって実現する処理システムのコンポーネントであってもよい。１つ以上のプロセッサは、汎用マイクロプロセッサ、マイクロ制御装置、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理デバイス（ＰＬＤ）、制御装置、状態機械、ゲート論理、ディスクリートハードウェアコンポーネント、専用ハードウェア有限状態機械、あるいは、情報の、計算または他の操作を実行できる他の何らかの適切なエンティティ、の任意の組み合わせにより実現してもよい。

［００５３］
処理システムは、ソフトウェアを記憶する機械読取可能媒体も備えていてもよい。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはその他のものと呼ばれようとなかろうと、何らかのタイプの命令を意味するように広く解釈すべきである。命令は、（例えば、ソースコードのフォーマットの、バイナリコードフォーマットの、実行可能なコードのフォーマットの、または、他の何らかの適切なコードのフォーマットの）コードを含んでいてもよい。命令は、１つ以上のプロセッサによって実行されるときに、ここで説明するさまざまな機能を処理システムに実行させる。

［００５４］
ワイヤレスデバイス１８０はまた、ハウジング１８８も含んでいてもよく、ハウジング１８８は、ワイヤレスデバイス１８０と遠隔ロケーションとの間でのデータの送受信を可能にする、送信機１９０および受信機１９２を含んでもよい。送信機１９０および受信機１９２は、組み合わせて、トランシーバ１９４にしてもよい。アンテナ１９６をトランシーバ１９４に提供して、トランシーバ１９４に電気的に結合してもよい。ワイヤレスデバイス１８０は、（示されていない）複数の送信機、複数の受信機、複数のトランシーバ、および／または、複数のアンテナも含んでいてもよい。

［００５５］
ワイヤレスデバイス１８０は、信号検出器２００も備えていてもよく、信号検出器２００は、トランシーバ１９４によって受信された信号のレベルを検出して定量化しようとするために使用してもよい。信号検出器２００は、総エネルギー、シンボル当たりの副搬送波毎のエネルギー、電力スペクトル密度、および他の信号のような、信号を検出してもよい。ワイヤレスデバイス１８０は、信号を処理する際に使用するために、デジタル信号プロセッサ（ＤＳＰ）２０２も含んでいてもよい。ＤＳＰ２０２は、送信のためにデータユニットを発生させるように構成されていてもよい。ワイヤレスデバイス１８０は、ディスプレイ２０４およびユーザインターフェース２０６をさらに備えていてもよい。ユーザインターフェース２０６は、タッチスクリーン、キーパッド、マイクロフォン、および／または、スピーカーを含んでいてもよい。ユーザインターフェース２０６は、ワイヤレスデバイス１８０のユーザに情報を伝える、および／または、ユーザからの入力を受け取る、何らかのエレメントまたは何らかのコンポーネントを含んでいてもよい。

［００５６］
１つ以上のバスシステム２０８によって、ワイヤレスデバイス１８０のさまざまなコンポーネントを互いに結合してもよい。バスシステム２０８は、データバスを含んでいてもよく、データバスに加えて、例えば、電力バス、制御信号バス、および、ステータス信号バスも含んでいてもよい。当業者であれば、他の何らかのメカニズムを使用して、ワイヤレスデバイス１８０のコンポーネントを、互いに結合してもよく、または、ワイヤレスデバイス１８０のコンポーネントが、入力を受け取ってもよく、または、ワイヤレスデバイス１８０のコンポーネントが、入力を互いに提供してもよいと認識するだろう。

［００５７］
図９において、多数の別々のコンポーネントが図示されているが、コンポーネントのうちの１つ以上を組み合わせ、または、共通して実現してもよい。例えば、プロセッサ１８４は、プロセッサ１８５に関して上記で説明した機能性を実現するためだけでなく、信号検出器２００および／またはＤＳＰ２０２に関して上記で説明した機能性を実現するためにも使用してもよい。さらに、図９中で図示したコンポーネントのそれぞれは、複数の別々のエレメントを使用して、実現してもよい。さらに、プロセッサ１８４は、コンポーネント、モジュール、回路、または以下で説明するこれに類するもののうちのいずれかを実現するために使用してもよく、あるいは、それぞれは、複数の別々のエレメントを使用して、実現してもよい。

［００５８］
ここで使用される、用語「決定する」は、幅広いアクションを含んでいる。例えば、「決定する」は、算出する、計算する、処理する、導出する、調べる、検索する（例えば、表、データベース、または、別のデータ構造中において検索する）、確認する、および、これらに類するものを含んでいてもよい。また、「決定する」は、受信する（例えば、情報を受信する）、アクセスする（例えば、メモリ中のデータにアクセスする）、および、これらに類するものを含んでいてもよい。また、「決定する」は、解決する、選択する、選ぶ、確立する、および、これらに類するものを含んでいてもよい。さらに、ここで使用されるような「チャネル帯域」は、ある態様において、帯域幅を含むまたは帯域幅と呼ばれてもよい。

［００５９］
ここで使用されるように、アイテムのリスト「のうちの少なくとも１つ」というフレーズは、単一の要素を含む、これらのアイテムの任意の組み合わせを指す。例として、「ａ、ｂ、またはｃのうちの少なくとも１つ」は、ａ、ｂ、ｃ、ａ−ｂ、ａ−ｃ、ｂ−ｃ、およびａ−ｂ−ｃをカバーするように意図されている。

［００６０］
上記で説明した方法のさまざまな動作は、さまざまなハードウェアおよび／またはソフトウェアコンポーネント、回路、ならびに／あるいは、モジュールのような、動作を実行することが可能な何らかの適切な手段により実行できる。一般的に、図中に図示した何らかの動作は、動作を実行することが可能な対応する機能手段により実行できる。

［００６１］
本開示に関連して説明した、さまざまな例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ信号（ＦＰＧＡ）または他のプログラマブル論理デバイス（ＰＬＤ）、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここで説明した機能を実行するように設計されているこれらの任意の組み合わせで実現しても、あるいは、実行してもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代替実施形態では、プロセッサは、何らかの商業的に入手可能なプロセッサ、制御装置、マイクロ制御装置、または、状態機械であってもよい。プロセッサはまた、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つ以上のマイクロプロセッサ、または、他の何らかのこのようなコンフィギュレーションのような、コンピューティングデバイスの組み合わせとして実現してもよい。

［００６２］
１つ以上の態様では、記述した機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせにおいて実現してもよい。ソフトウェアにおいて実現される場合、機能は、１つ以上の命令またはコードとしてコンピュータ読取可能媒体上に記憶されてもよく、あるいは、１つ以上の命令またはコードとしてコンピュータ読取可能媒体上で送信されてもよい。コンピュータ読取可能媒体は、１つの場所から別の場所へのコンピュータプログラムの転送を促進する任意の媒体を含む、コンピュータ記憶媒体および通信媒体の両方を含んでいる。記憶媒体は、コンピュータによってアクセスできる何らかの利用可能な媒体であってもよい。限定ではなく例として、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいはコンピュータによってアクセスできる命令またはデータ構造の形態で所望のプログラムコードを運ぶまたは記憶するために使用できる他の何らかの媒体を含むことができる。また、任意の接続は、コンピュータ読取可能媒体と適切に呼ばれる。例えば、ソフトウェアが、ウェブサイトから、サーバから、あるいは、同軸ケーブル、光ファイバケーブル、撚り対、デジタル加入者線（ＤＳＬ）、または、赤外線や、無線や、マイクロ波のようなワイヤレス技術を使用している他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバケーブル、撚り対、ＤＳＬ、または、赤外線や、無線や、マイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。ここで使用したようなディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル汎用ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイ（登録商標）ディスクを含むが、一般的に、ディスク（ｄｉｓｋ）は、データを磁気的に再生する一方で、ディスク（ｄｉｓｃ）はデータをレーザによって光学的に再生する。したがって、いくつかの態様では、コンピュータ読取可能媒体は、一時的ではないコンピュータ読取可能媒体（例えば、有形の媒体）を含んでもよい。加えて、いくつかの態様では、コンピュータ読取可能媒体は、一時的なコンピュータ読取可能媒体（例えば、信号）を含んでもよい。上記の組み合わせもまた、コンピュータ読取可能媒体の範囲内に含まれるべきである。

［００６３］
ここで開示する方法は、説明した方法を達成するための１つ以上の、ステップまたはアクションを含んでいる。方法の、ステップおよび／またはアクションは、特許請求の範囲から逸脱することなく、互いに交換可能であってもよい。言い換えると、ステップまたはアクションの特定の順序が指定されていない限り、特定のステップおよび／またはアクションの順序および／または使用は、特許請求の範囲から逸脱することなく、修正してもよい。

［００６４］
説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせにおいて実現してもよい。ソフトウェアにおいて実行される場合、機能は、コンピュータ読取可能媒体上の１つ以上の命令として記憶されてもよい。記憶媒体は、コンピュータによってアクセスできる何らかの利用可能な媒体であってもよい。限定ではなく例として、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいはコンピュータによってアクセスできる命令またはデータ構造の形態で所望のプログラムコードを運ぶまたは記憶するために使用できる他の何らかの媒体を含むことができる。ここで使用したような、ディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタル汎用ディスク（ＤＶＤ）、フロッピーディスク、およびブルーレイ（ディスクを含むが、一般的に、ディスク（ｄｉｓｋ）は、磁気的にデータを再生する一方で、ディスク（ｄｉｓｃ）はレーザにより光学的にデータを再生する。

［００６５］
したがって、ある態様は、ここに提示した動作を実行するためのコンピュータプログラム製品を備えていてもよい。例えば、このようなコンピュータプログラム製品は、その上に記憶されている（および／またはエンコードされている）命令を有するコンピュータ読取可能媒体を含んでもよく、命令は、ここで記述した動作を実行するために、１つ以上のプロセッサにより実行可能である。ある態様では、コンピュータプログラム製品は、パッケージングマテリアルを含んでもよい。

［００６６］
また、ソフトウェアまたは命令は、送信媒体を通して送信されてもよい。例えば、同軸ケーブル、光ファイバケーブル、撚り対、デジタル加入者回線（ＤＳＬ）、または、赤外線や、無線や、マイクロ波のようなワイヤレス技術を使用して、ソフトウェアが、ウェブサイトから、サーバから、または、他の遠隔ソースから、送信される場合、同軸ケーブル、光ファイバケーブル、撚り対、ＤＳＬ、または、赤外線や、無線や、マイクロ波のようなワイヤレス技術は、送信媒体の定義に含まれる。

［００６７］
さらに、ここで説明した方法および技術を実行するモジュールおよび／または他の適切な手段を、ユーザ端末および／または基地局によって、適宜、ダウンロードできる、および／または、そうでなければ取得できると認識すべきである。例えば、このようなデバイスは、ここで説明した方法を実行するための手段の転送を促進するように、サーバに結合することができる。代替的に、ここで説明したさまざまな方法は、記憶手段をデバイスに結合または提供する際、ユーザ端末および／または基地局がさまざまな方法を得ることができるように、記憶手段（例えば、ＲＡＭ、ＲＯＭ、コンパクトディスク（ＣＤ）またはフロッピーディスクのような物理記憶媒体、等）を介して提供することができる。さらに、ここで説明した方法および技術を提供するための、他の何らかの適切な技術が利用できる。

［００６８］
特許請求の範囲が、上記に図解したまさにその構成およびコンポーネントに限定されないことを理解すべきである。さまざまな改良、変更、および、バリエーションが、上記で説明した方法ならびに装置の構成、動作、および、詳細において、特許請求の範囲から逸脱することなく行われてもよい。

［００６９］
上記は、本開示の態様に向けられているが、本開示の他の態様およびさらなる態様が、その基本的な範囲から逸脱することなく考案することができ、その範囲は、下記の特許請求の範囲によって決定される。

Claims (38)

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. 表示データを仲介デバイスを通過させることなくソースデバイスからシンクデバイスに前記表示データをワイヤレスに送信するシステムにおいて、
    ディスプレイとワイヤレス送信および受信回路とを有するソースデバイスと、
    ディスプレイとワイヤレス送信および受信回路とを有するシンクデバイスとを具備し、
    表示データが、前記ソースデバイスのディスプレイフレームバッファから取り出され、ワイヤレス送信のためにエンコードされ、前記シンクデバイスにワイヤレスに送信され、前記シンクデバイス上でデコードされ、前記シンクデバイスの前記ディスプレイ上に提示される第１のモードと、
    前記ソースデバイスにおいて、少なくとも、イメージフレームの第１のオーバーレイ部分が、第１のビデオ圧縮フォーマットを利用してエンコードされ、前記イメージフレームの第２のオーバーレイ部分が、第２のビデオ圧縮フォーマットを利用してエンコードされる第２のモードと、
    少なくとも、前記第１のオーバーレイ部分と前記第２のオーバーレイ部分が、前記シンクデバイスに対してワイヤレスに送信され、前記シンクデバイス上で別々にデコードされ、前記ソースデバイスから受信されたオーバーレイブレンド情報に少なくとも部分的に基づいて、前記シンクデバイス上でブレンドされ、前記シンクデバイスの前記ディスプレイ上に提示されることとができるように、前記ソースデバイスと前記シンクデバイスは、表示送信および受信パラメータを交渉するように構成されているシステム。

Images