(57)【要約】  ビデオ電話を行うためのシステムおよび方法が、開示される。一例では、ネットワーク（５６５）から、ビデオ電話データと、第１のディスプレイから第２のディスプレイへの切り替え（５１４）を示す情報とを受信する（５０６、５２０）ように設定されるトランシーバ（５５０）を有する装置が提供される。装置はまた、トランシーバに動作的に結合され、ビデオ電話データを復号するように設定されるデコーダ（５６０）と、復号されたビデオ電話データを記憶するように設定される、コーディングされたピクチャバッファを備えるメモリと、トランシーバ、デコーダ、およびメモリに動作的に結合されるプロセッサと、を含む。プロセッサは、第１のディスプレイから第２のディスプレイへの切り替えを示す情報を受信することに応答して、トランシーバに、ネットワークへの、Ｉフレームを求める要求（５１８）を送信することを命令するように設定される。【選択図】      図５
2018529249.tif 000002
【特許請求の範囲】
【請求項１】
ビデオ電話（ＶＴ）のための装置であって、
ネットワークから、ＶＴデータと、第１のディスプレイから第２のディスプレイへの切り替えを示す情報とを受信するように設定されるトランシーバと、
前記トランシーバに動作的に結合され、前記ＶＴデータを復号するように設定されるデコーダと、
前記復号されたＶＴデータを記憶するように設定されるメモリと、
前記トランシーバ、前記デコーダ、および前記メモリに動作的に結合されるプロセッサと、前記プロセッサは、第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報を受信することに応答して、前記トランシーバに、前記ネットワークへの、Ｉフレームを求める要求を送信することを命令するように設定される、
を備える、装置。
【請求項２】
前記プロセッサは、第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報を受信することに応答して、前記切り替えを示す前記情報に少なくとも部分的に基づいて、前記デコーダを再設定するようにさらに設定される、請求項１に記載の装置。
【請求項３】
前記メモリは、コーディングされたピクチャバッファ（ＣＰＢ）を備える、請求項２に記載の装置。
【請求項４】
前記デコーダを再設定することは、前記ＣＰＢを空にすることを備える、請求項３に記載の装置。
【請求項５】
前記トランシーバは、前記ネットワークから前記Ｉフレームを受信するようにさらに設定され、
前記デコーダは、前記Ｉフレームを復号するようにさらに設定され、
前記プロセッサは、前記トランシーバに、前記第２のディスプレイに前記復号されたＩフレームを送信することを命令するようにさらに設定される、請求項１に記載の装置。
【請求項６】
前記第２のディスプレイは、前記装置の外部にあるディスプレイデバイスと関連付けられる、請求項１に記載の装置。
【請求項７】
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報は、前記第２のディスプレイと関連付けられたサーフェスアドレスを備える、請求項１に記載の装置。
【請求項８】
前記第１のディスプレイは、第１のサーフェスアドレスと関連付けられ、ここにおいて、前記プロセッサは、前記第１のディスプレイ上で、前記復号されたＶＴデータの少なくとも一部をレンダリングするようにさらに設定され、前記第２のディスプレイと関連付けられた前記サーフェスアドレスは、第２のサーフェスアドレスである、請求項７に記載の装置。
【請求項９】
前記Ｉフレームを求める前記要求は、ピクチャロスインジケーション（ＰＬＩ）メッセージまたはフルイントラ要求（ＦＩＲ）メッセージのうちの１つを備える、請求項１に記載の装置。
【請求項１０】
ビデオ電話（ＶＴ）デバイスによって動作可能な方法であって、
ネットワークからＶＴデータを受信することと、
デコーダを介して前記ＶＴデータを復号することと、
メモリに前記復号されたＶＴデータを記憶することと、
第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することと、
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報を検出することに応答して、前記ネットワークへの、Ｉフレームを求める要求を送信することと
を備える、方法。
【請求項１１】
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報を検出することに応答して、前記切り替えを示す前記情報に少なくとも部分的に基づいて、前記デコーダを再設定することをさらに備える、請求項１０に記載の方法。
【請求項１２】
前記メモリは、コーディングされたピクチャバッファ（ＣＰＢ）を備える、請求項１１に記載の方法。
【請求項１３】
前記デコーダを再設定することは、前記ＣＰＢを空にすることを備える、請求項１２に記載の方法。
【請求項１４】
前記ネットワークから前記Ｉフレームを受信することと、
前記Ｉフレームを復号することと、
前記第２のディスプレイに前記復号されたＩフレームを送信することと
をさらに備える、請求項１０に記載の方法。
【請求項１５】
前記第２のディスプレイは、前記ＶＴデバイスの外部にあるディスプレイデバイスと関連付けられる、請求項１０に記載の方法。
【請求項１６】
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報は、前記第２のディスプレイと関連付けられたサーフェスアドレスを備える、請求項１０に記載の方法。
【請求項１７】
前記第１のディスプレイ上で、前記復号されたＶＴデータの少なくとも一部をレンダリングすることをさらに備え、ここにおいて、前記第１のディスプレイは、第１のサーフェスアドレスと関連付けられ、前記第２のディスプレイと関連付けられた前記サーフェスアドレスは、第２のサーフェスアドレスである、請求項１６に記載の方法。
【請求項１８】
前記Ｉフレームを求める前記要求は、ピクチャロスインジケーション（ＰＬＩ）メッセージまたはフルイントラ要求（ＦＩＲ）メッセージのうちの１つを備える、請求項１０に記載の方法。
【請求項１９】
命令を記憶した非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、実行されるとき、デバイスのプロセッサに、
ネットワークからビデオ電話（ＶＴ）データを受信することと、
デコーダを介して前記ＶＴデータを復号することと、
メモリに前記復号されたＶＴデータを記憶することと、
第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することに応答して、前記ネットワークへの、Ｉフレームを求める要求を送信することと
を行わせる、非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項２０】
実行されるとき、前記プロセッサに、第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報を検出することに応答して、前記切り替えを示す前記情報に少なくとも部分的に基づいて、前記デコーダを再設定することを行わせる命令をさらに記憶した、請求項１９に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項２１】
前記メモリは、コーディングされたピクチャバッファ（ＣＰＢ）を備える、請求項１９に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項２２】
実行されるとき、前記プロセッサに、
前記ネットワークから前記Ｉフレームを受信することと、
前記Ｉフレームを復号することと、
前記第２のディスプレイに前記復号されたＩフレームを送信することと
を行わせる命令をさらに記憶した、請求項１９に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項２３】
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報は、前記第２のディスプレイと関連付けられたサーフェスアドレスを備える、請求項１９に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項２４】
ビデオ電話（ＶＴ）を行うためのビデオコーディングデバイスであって、
ネットワークからＶＴデータを受信するための手段と、
前記ＶＴデータを復号するための手段と、
前記復号されたＶＴデータを記憶するための手段と、
第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出するための手段と、
前記切り替えを示す前記情報を検出することに応答して、前記ネットワークへの、Ｉフレームを求める要求を送信するための手段と、
を備える、ビデオコーディングデバイス。
【請求項２５】
前記第１のディスプレイから前記第２のディスプレイへの前記切り替えを示す前記情報を検出することに応答して、前記切り替えを示す前記情報に少なくとも部分的に基づいて、復号するための前記手段を復号するための前記手段を再設定するための手段をさらに備える、請求項２４に記載のビデオコーディングデバイス。
【請求項２６】
前記ネットワークから前記Ｉフレームを受信するための手段と、
前記Ｉフレームを復号するための手段と、
前記第２のディスプレイに前記復号されたＩフレームを送信するための手段と
をさらに備える、請求項２４に記載のビデオコーディングデバイス。
【請求項２７】
第１のディスプレイから第２のディスプレイへの切り替えを示す前記情報は、前記第２のディスプレイと関連付けられたサーフェスアドレスを備える、請求項２４に記載のビデオコーディングデバイス。
【請求項２８】
前記サーフェスアドレスは、前記ビデオコーディングデバイスの外部にあるディスプレイデバイスを示す、請求項２７に記載のビデオコーディングデバイス。
【請求項２９】
第１のサーフェスアドレスと関連付けられた第１のディスプレイ上で、前記復号されたＶＴデータの少なくとも一部をレンダリングするための手段をさらに備え、ここにおいて、前記第２のディスプレイと関連付けられた前記サーフェスアドレスは、第２のサーフェスアドレスである、請求項２７に記載のビデオコーディングデバイス。
【請求項３０】
前記Ｉフレームを求める前記要求は、ピクチャロスインジケーション（ＰＬＩ）メッセージまたはフルイントラ要求（ＦＩＲ）メッセージのうちの１つを備える、請求項２４に記載のビデオコーディングデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]  本開示は、ビデオ電話（ＶＴ：video telephony）に関し、より具体的には、ＶＴセッション中にディスプレイデバイスを切り替える間、ＶＴ品質を管理することに関する。
【背景技術】
【０００２】
[0002]  モバイル電話のような通信デバイスは、マイクロフォンまたは音声合成器のようなオーディオキャプチャデバイス、オーディオパケット（またはフレーム）を生成するためのオーディオエンコーダ、カメラのようなビデオキャプチャデバイス、およびビデオフレームを生成するためのビデオエンコーダを含み得る。ビデオフレームは、ビデオ電話（ＶＴ）の際に使用するデバイスの間で送信され得る。通信デバイス（すなわち、ＶＴデバイス）は、リアルタイムトランスポートプロトコル（ＲＴＰ：real-time transport protocol）、無線リンクプロトコル（ＲＬＰ：radio link protocol）、媒体アクセス制御（ＭＡＣ：medium access control）、および物理（ＰＨＹ：physical）レイヤのような、通信プロトコルレイヤを使用し得る。ビデオ電話アプリケーションにおいて、通信デバイスは、ＲＬＰキュー（RLP queue）にビデオおよびオーディオＲＴＰパケットを配置し得る。ＭＡＣレイヤモジュールは、ＲＬＰキューのコンテンツからＭＡＣレイヤパケットを生成し得る。ＭＡＣレイヤパケットは、別の通信デバイスへの、ある通信チャネルにわたる送信のために、ＰＨＹレイヤパケットに変換され得る。
【０００３】
[0003]  本開示のシステム、方法、およびデバイスは各々、いくつかの革新的な態様を有し、それらのうちの１つとして、本明細書で開示されている所望の属性に対して単独で責任を負うわけではない。
【発明の概要】
【０００４】
[0004]  一態様では、ビデオ電話（ＶＴ）のための装置は、ネットワークからＶＴデータを受信するように設定されるトランシーバと、トランシーバに動作的に（operatively）結合され、ＶＴデータを復号するように設定されるデコーダと、復号されたＶＴデータを記憶するように設定される、コーディングされたピクチャバッファ（ＣＰＢ：coded picture buffer）を備えるメモリと、トランシーバ、デコーダ、およびメモリに動作的に結合されるプロセッサと、を備える。プロセッサは、ディスプレイと関連付けられたサーフェスアドレス（surface address）を受信することに応答して、（ｉ）受信されたサーフェスアドレスに少なくとも部分的に基づいてデコーダを再設定することと、（ｉｉ）トランシーバに、ネットワークへの、Ｉフレームを求める要求を送信することとを命令するように設定される。
【０００５】
[0005]  別の態様では、ＶＴを行う方法は、ネットワークから、受信デバイス（receiving device）においてＶＴデータを受信することと、デコーダを介してＶＴデータを復号することと、メモリに、復号されたＶＴデータを記憶することと、第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することと、第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することに応答して、ネットワークへの、Ｉフレームを求める要求を送信することとを備える。
【０００６】
[0006]  別の態様では、非一時的なコンピュータ読み取り可能な記憶媒体は命令を記憶し、命令は、実行されるときに、デバイスのプロセッサに、ネットワークからＶＴデータを受信することと、デコーダを介してＶＴデータを復号することと、メモリに、復号されたＶＴデータを記憶することと、第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することに応答して、ネットワークへの、Ｉフレームを求める要求を送信することとを行わせる。
【０００７】
[0007]  さらに別の態様では、ＶＴを行うためのビデオコーディングデバイスは、ネットワークから、ＶＴデータと、第１のディスプレイから第２のディスプレイへの切り替えを示す情報とを受信するための手段と、ＶＴデータを復号するための手段と、復号されたＶＴデータを記憶するための手段と、切り替えを示す情報を検出することに応答して、ネットワークへの、Ｉフレームを求める要求を送信するための手段と、を備える。
【図面の簡単な説明】
【０００８】
【図１】[0008]  図１は、ビデオ電話（ＶＴ）デバイスを伴う例となるシステムを例示する。
【図２】[0009]  図２は、ＶＴで使用され得るフレームタイプ（すなわちピクチャタイプ）を例示する。
【図３】[0010]  図３は、ビデオ電話をサポートするために、通信デバイス内で提供され得るビデオおよびオーディオエンコーディングおよびデコーディングシステムを例示する。
【図４】[0011]  図４は、汎用パケット交換（ＰＳ：packet-switched）ネットワークにわたる２方向ＶＴコール（2-way VT call）の簡略化されたブロック図を描写する。
【図５】[0012]  図５は、複数の例となるコンポーネントの間でのコールフローを例示する。
【図６】[0013]  図６は、本開示の技法に従う、例となるＶＴ方法を図示するフローチャートである。
【図７】[0014]  図７は、本開示の技法に従う、別の例となるＶＴ方法を図示するフローチャートである。
【詳細な説明】
【０００９】
[0015]  本開示は、ビデオ電話（ＶＴ）に関し、より具体的には、ＶＴセッション中のデバイスの間の改善された切り替えのための技法に関する。ＶＴは、オーディオだけである従来の電話とは対照的に、概して、ビデオおよびオーディオの両方を含む、リアルタイム通信を指す。ＶＴセッション中に、異なるロケーションにおける通信デバイスは、インターネットのようなネットワークにわたってオーディオおよびビデオデータを運ぶパケットを送信および受信する。
【００１０】
[0016]  図１は、ＶＴデバイスを伴う例となるシステムを例示する。ある実施形態では、第１のＶＴデバイス３（すなわち、通信デバイス）は、ネットワーク５を介して、第２のＶＴデバイス４と通信し得る。ＶＴデバイスは、ビデオ情報を受信および／または送信するのに適している任意のデバイス、例えば、スマートフォン、ラップトップまたはデスクトップコンピュータ、タブレット、等であり得る。第１のＶＴデバイス３はまた、ネットワーク７を介してディスプレイデバイス６と通信し得る。ディスプレイデバイス６は、ビデオ情報をディスプレイするのに適している任意のデバイス、例えば、スマートフォン、ラップトップまたはデスクトップコンピュータ、タブレット、テレビ、等であり得る。
【００１１】
[0017]  第１および第２のＶＴデバイス３、４は、受信されたビデオ情報をディスプレイするためのサーフェスアドレスを指定し得る。例えば、ＶＴデバイスが、ビデオをディスプレイするのに適しているディスプレイを有するスマートフォンである場合、ディスプレイは、関連付けられたアドレスを有し得る。ＶＴデバイスは、受信されたビデオ情報のためのサーフェスアドレスとしてディスプレイアドレスを指定し得、ビデオ情報がディスプレイ上にディスプレイされることを可能にする。
【００１２】
[0018]  ＶＴセッション中に、ＶＴデバイスのサーフェスアドレスは、変化し得る。例えば、スマートフォン上でＶＴ会話中のユーザは、テレビのような、より大きいスクリーン上でビデオがディスプレイされることを望み得る。ユーザは、所望のディスプレイデバイス６としてテレビを指定し得、テレビの関連付けられたアドレスは、新たなサーフェスアドレスとしてＶＴデバイスに送られ得る。サーフェスアドレスが変化するとき、ディスプレイデバイス６において生成されたオーディオおよび／またはビデオは、ＶＴデバイス３において生成されていたものからの質の低下（drop）を経験し得る。このことは、時間期間の間に部分的な情報だけ（例えば、Ｐおよび／またはＢピクチャだけ）を受信するデバイスによって生じ得る。よって、サーフェスアドレスの変化が生じるときの（例えば、Ｉピクチャを含む）フルピクチャ情報（full picture information）を要求するためのシステムおよび方法が、望まれる。
【００１３】
[0019]  ＶＴデバイスと代替的に称され得る、通信デバイスは、ワイヤードおよび／またはワイヤレス通信のために装備され得る。ＶＴデバイスは、ＶＴアプリケーション専用であり得る、あるいは、例えばＶＴアプリケーションに加えて、ウェブブラウジング、ゲーミング、ワード処理、グラフィックス処理、ビデオおよび／またはオーディオエンターテインメント、ならびにロケーショントラッキングのような幅広い他のコンピューティングアプリケーション（computing application）のうちのいずれかをサポートするために装備され得る。いくつかの例では、ＶＴデバイスは、いわゆるスマートフォン、タブレット、またはウェアラブルスマートデバイスであり得る。
【００１４】
[0020]  ＶＴデバイスによって生成されるパケットは、例えば、標準化されたパケットフォーマット（standardized packet format）を定義するリアルタイムトランスポートプロトコル（ＲＴＰ：Real-Time Transport Protocol）に従って送信され得る。さらに、ＶＴデバイスは、ＲＴＰセッションのための制御情報および帯域外の統計を送信するための標準化されたパケットフォーマットを定義するＲＴＰ制御プロトコル（ＲＴＣＰ：RTP Control Protocol）に従って情報パケットを送信および受信し得る。
【００１５】
[0021]  ネットワークにわたって送信される必要があるデータの量を低減するために、ＶＴデバイスは、オーディオおよびビデオエンコーダおよびデコーダを含む。第１のＶＴデバイスのビデオエンコーダは、典型的に、様々なビデオ圧縮ツールを使用して、カメラによってキャプチャされるビデオデータを圧縮し、一方第２のＶＴデバイスのビデオデコーダは、概して、第２のＶＴデバイスにおける再生のために、符号化されたビデオデータを復号するために、ビデオエンコーダのそれらに互恵的技法（reciprocal technique）を行う。
【００１６】
[0022]  図２は、ＶＴで使用され得るフレームタイプ（すなわち、ピクチャタイプ）−つまりＩフレーム、Ｐフレーム、およびＢフレーム、を例示する。本明細書で使用される場合、「ピクチャ（picture）」および「フレーム（frame）」という用語は、置き替え可能に使用され得る。同様に、「Ｉピクチャ（I-picture）」および「Ｉフレーム（I-frame）」、「Ｐピクチャ（P-picture）」および「Ｐフレーム（P-frame）」、ならびに「Ｂピクチャ（B-picture）」および「Ｂフレーム（B-frame）」という用語もまた、置き替え可能に使用され得る。
【００１７】
[0023]  ＶＴデバイスのビデオエンコーダは、一連のピクチャとしてキャプチャされたビデオを符号化し、ここで、ピクチャは、ビデオデータのフレームを指し得、あるいはインターレースされたビデオ（interlaced video）のケースでは、ビデオデータのフィールドを指し得る。ビデオエンコーダは、一連のイントラコーディングされたピクチャ（intra-coded picture）（ＩピクチャまたはＩフレーム）および予測されたピクチャ（ＰまたはＢピクチャ）を生成する。Ｉピクチャは、他のピクチャへの参照なしに復号されるが、典型的に、ＰおよびＢピクチャより低い圧縮を提供することができる。ＰおよびＢピクチャは、その一方で、前に復号されたピクチャの情報を利用し、よってエラーに対してより影響を受けやすく（susceptible）なり得るが、Ｉピクチャと比較して、より高い圧縮を提供する。Ｐピクチャは、別のピクチャに関連して予測される。Ｂピクチャは、２つの他のピクチャに関連して予測される。ＰまたはＢピクチャを符号化する場合、Ｉピクチャを符号化するときより、より多くの数のコーディングツールがビデオエンコーダに利用可能である。１つの例として、Ｐピクチャのブロックは、既に復号されたピクチャにおけるブロックに基づいて予測されるか、Ｐピクチャにおける他のピクセル値に基づいて予測されるか、または全く予測されない可能性がある。Ｉピクチャは、前に復号されたピクチャに依存しないため、Ｉピクチャにおけるブロックは、対照的に、既に復号されたピクチャのブロックに基づいて予測されることができない。代わりに、Ｉピクチャにおけるブロックは、Ｉピクチャ内で既に復号されたピクセルに基づいて復号される。より少ないコーディングツールの利用可能性は、概して、ＰピクチャおよびＢピクチャより低い圧縮を提供するＩピクチャをもたらす。
【００１８】
[0024]  連続的なＰまたはＢピクチャは、ビデオデコーダがＩピクチャを受信するまで１つのピクチャから次のものに伝播されるエラーをもたらし得る。加えて、ＰまたはＢピクチャが前に復号されたピクチャを使用して復号されるが、ＰまたはＢピクチャが依存するピクチャが、例えば、パケット損失のため、適切に復号されなかった場合、ビデオデコーダは、ＰまたはＢピクチャを適切に復号することができない可能性がある。これらの事例では、ビデオデコーダは、数秒の間、別のＩピクチャが受信されるまで、認識できないビデオを生成し得る、または一切ビデオを生成することができない可能性がある。不十分なビデオのこの数秒、またはビデオがないこの数秒は、ユーザ経験を減らし得る。ビデオ品質を改善するため、および誤り耐性（error resiliency）を改善するために、ビデオエンコーダは、典型的に、符号化されたビデオビットストリームにＩピクチャを周期的に含めるように設定され、より多くのＩピクチャでは、典型的に、ビデオ品質を改善するが、全体のビデオ圧縮を低減し、より少ないＩピクチャでは、ビデオ品質を低減させるが、全体のビデオ圧縮を改善する。
【００１９】
[0025]  ビデオエンコーダは、典型的に、符号化されているピクチャにおける大量の変化を検出することに応答して、Ｉピクチャを生成するように設定される。ピクチャにおける大量の変化は、例えば、カメラが動き、１つのピクチャの全シーンが最近コーディングされたピクチャ（recently coded picture）のそれとは異なるときに生じ得る。その一方、ピクチャにおける少量の変化は、カメラが、ほんのわずかに動いているオブジェクトにフォーカスされる固定の位置にあるときに生じ得る。例えば、カメラが固定の人または人々のグループにフォーカスされるＶＴセッションでは、人々の動きは、典型的に小さく、背景の部分は、わずかに変化する、または全く変化しない可能性がある。そのようなシナリオでは、ＶＴデバイスは、Ｉピクチャの間の時間の量を増加させ得る。ピクチャにおける変化がない、または事実上変化がないシナリオにおいてさえ、ＶＴデバイスは、ビデオ品質を改善するため、および誤り耐性を改善するために、なお周期的にＩピクチャを送り得る。
【００２０】
[0026]  ＶＴセッション中に、１つ以上のＶＴデバイスは、ディスプレイを切り替え得る。例えば、ＶＴデバイス（例えば、スマートフォン）を介したビデオコールに参加するユーザは、ディスプレイデバイス（例えば、コンピュータモニタ）にビデオを切り替えたいと望む可能性がある。「ＶＴデバイス（VT device）」および「ディスプレイデバイス（display device）」という用語が使用されるが、これらの用語が、相互に排他的でないこと、ならびに多くのデバイス（例えば、スマートフォン、ラップトップ／デスクトップコンピュータ、タブレット、テレビ、等）がＶＴデバイスおよびディスプレイデバイスの両方としての使用に適し得ることに留意されたい。切り替えることは、ＶＴデバイスとディスプレイデバイスとの間のワイヤレスおよび／またはワイヤード接続を使用することによって可能であり得る。例えば、データは、Ｗｉ−Ｆｉネットワークおよび／またはローカルエリアネットワーク（ＬＡＮ）を介してＶＴデバイスとディスプレイデバイスとの間で送信され得る。
【００２１】
[0027]  ディスプレイ切り替え（display switching）がＶＴデバイスとディスプレイデバイスとの間の通信を含むため、ＶＴセッションに参加する他のＶＴデバイスは、切り替えが生じたことに気付かない可能性がある。しかしながら、本開示の実施形態は、ＶＴデバイスの間のディスプレイ切り替えを示す情報を提供するために様々な技法を採用し得る。このようにして、ＶＴデバイスは、ディスプレイ切り替え中、およびディスプレイ切り替えの後、ＶＴコールのパフォーマンスを改善し得るデータ（例えば、Ｉピクチャ）を要求し得る。
【００２２】
[0028]  上記に導入されたように、ＶＴセッションに参加する２つのデバイスは、ＶＴセッションのステータスに関するＲＴＣＰメッセージを交換し得る。ＲＴＣＰメッセージは、例えば、Ｉピクチャを求める要求を持つ、フィードバックを持つオーディオビジュアルプロファイル（ＡＶＰＦ：audio-visual profile with feedback）メッセージを含み得る。ＡＶＰＦは、ＲＴＣＰベースのフィードバックのための拡張されたＲＴＰプロファイルを指す。ＲＴＣＰメッセージの例は、イントラコーディングされたピクチャ、ピクチャロスインジケーション（ＰＬＩ：picture loss indication）メッセージ、およびフルイントラ要求（ＦＩＲ：full intra request）メッセージを求める要求を含む。
【００２３】
[0029]  第１のＶＴデバイスは、Ｉピクチャ、Ｐピクチャ、およびＢピクチャの形式で、第２のＶＴデバイスにデータを送り得る。デバイスのうちの一方または両方は、内部のまたは外部のサーフェスに、受信されたビデオ情報をディスプレイし得る。サーフェスは、ビデオをディスプレイするのに適している任意のタイプのスクリーン、例えば、タッチスクリーン、高精細度テレビジョン（ＨＤＴＶ：high-definition television）スクリーン、コンピュータモニタ、等であり得る。例えば、第２のＶＴデバイス（例えば、スマートフォン）は、ビデオをディスプレイするためのサーフェスを含み得る。サーフェスは、ビデオをディスプレイするのに適している任意のタイプのスクリーン、例えば、タッチスクリーン、高精細度テレビジョン（ＨＤＴＶ）スクリーン、等であり得る。そのようケースでは、第２のＶＴデバイスは、ビデオ情報をディスプレイするための、デフォルトのサーフェスアドレスとして、その内部のサーフェスを定義し得る。しかしながら、ＶＴセッション中に、第２のＶＴデバイスが、（例えば、サーフェスビューコンポーネントから）新たなサーフェスアドレスを受信する場合、第２のデバイスは、サーフェスアドレスを変更するために、デコーダ再設定を行い得る。デコーダ再設定は、例えば、前に送られたＩピクチャを含むバッファをフラッシュすることを含み得る。Ｉピクチャがバッファからフラッシュされる場合、次に、第２のＶＴデバイスは、新たなＩピクチャが受信されるまで、続いて送られるＰピクチャおよびＢピクチャを適切に復号することができない可能性があり、不十分なビデオの期間、またはビデオのない期間をもたらす。不十分なビデオは、デコーダ再設定動作の一部としてバッファをフラッシュする第２のＶＴデバイスのため、第２のＶＴデバイスがもはや、そのコーディングされたピクチャバッファに記憶していない、フラッシュされたＩピクチャに依存するＢピクチャおよびＰピクチャの結果として起こり得る。そのようなシナリオにおいて、第１のＶＴデバイスは、第２のＶＴデバイスがバッファからＩピクチャをフラッシュしたことを既知でなく、それゆえに第１のＶＴデバイスは、数秒の間ＢおよびＰピクチャを送り続け得、それら数秒中の不快なユーザ経験（bad user experience）をもたらす。
【００２４】
[0030]  本開示の技法に従って、不十分なビデオのこの期間、またはビデオのないこの期間を避けるまたは低減するために、第２のＶＴデバイスは、デコーダ再設定を検出することに応答してＩピクチャ要求メッセージを送るように設定され得る。追加として、または代替として、第２のＶＴデバイスは、復号されたピクチャを記憶する、コーディングされたピクチャバッファのフラッシングを検出することに応答して、Ｉピクチャ要求メッセージを送るように設定され得る。Ｉピクチャ要求メッセージは、例えば、ＲＴＣＰにわたるピクチャロスインジケーション（ＰＬＩ）メッセージか、ＲＴＣＰにわたるフルイントラ要求（ＦＩＲ）メッセージか、または何らかの他のそのようなタイプのＩピクチャ要求メッセージであり得る。Ｉピクチャ要求メッセージを送ることなしに、第１のデバイスは、第２のＶＴデバイスがフラッシュされたＩピクチャを記憶しており、よって後続のＰおよびＢピクチャを予測するために、記憶されたＩピクチャを使用することができるという前提の下、ビデオデータをコーディングし続けるであろうこととなる。従って、第１のデバイスが、符号化されているビデオにおける検出された変化か、またはＩピクチャの間の時間かのどちらかに基づいて、別のＩピクチャを送るまで、第２のデバイスは、別のＩピクチャを受信しないであろうこととなり、それは、いくつかの事例において数秒、または最大で１０秒にすらなり得る。そのコーディングされたピクチャバッファをフラッシュすることに応答して、Ｉピクチャ要求メッセージを送ることによって、第２のＶＴデバイスは、Ｉピクチャのないこの時間を低減し得、よって、不十分なビデオ品質を伴う時間の量を低減することによって全体のユーザ経験を改善する。
【００２５】
[0031]  図３は、本開示の技法を利用し得るビデオエンコーディングおよびデコーディングシステム１０を例示する。システム１０は、デコーダシステム１４に送信チャネル１６にわたってデータを送るエンコーダシステム１２を含む。エンコーダシステム１２は、第１のビデオ通信デバイス中にあり得、オーディオソース１７、ビデオソース１８、ビデオエンコーダ２０、オーディオエンコーダ２２、インターネットプロトコル（ＩＰ：Internet protocol）マルチメディアサブシステム（ＩＭＳ：Internet protocol multimedia subsystem）ＶＴアプリケーションモジュール２４、リアルタイムトランスポートプロトコル（ＲＴＰ）／ＲＴＣＰ／ユーザデータグラムプロトコル（ＵＤＰ：user datagram protocol）／ＩＰ／ポイント対ポイントプロトコル（ＰＰＰ：point-to-point protocol）変換モジュール２６、無線リンクプロトコル（ＲＬＰ）キュー２８、ＭＡＣレイヤモジュール３０、および物理（ＰＨＹ）レイヤモジュール３２を含み得る。他の例では、エンコーダシステム１２は、図１に図示されている要素の代わりに、またはその要素に加えて、他の要素を含み得る。エンコーダシステム１２の他の例は、図１で図示されているものよりも少ない要素を含み得る。
【００２６】
[0032]  デコーダシステム１４は、別のビデオ通信デバイス中にあり得、ＰＨＹレイヤモジュール３４、ＭＡＣレイヤモジュール３６、ＲＬＰキュー３８、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０、ＩＭＳ  ＶＴアプリケーションモジュール４２、ビデオデコーダ４４、オーディオデコーダ４６、オーディオ出力ユニット４８、およびビデオ出力ユニット５０を含み得る。他の例では、デコーダシステム１４は、図１に図示されている要素の代わりに、またはその要素に加えて、他の要素を含み得る。デコーダシステム１４の他の例は、図１で図示されているものよりも少ない要素を含み得る。
【００２７】
[0033]  システム１０は、例えば、送信チャネル１６を介したＶＴセッションの間、双方向のビデオおよびオーディオ送信を提供し得る。互恵的な符号化、復号、および変換モジュール（Reciprocal encoding, decoding, and conversion module）は、チャネル１６の反対端上で提供され得る。いくつかの実施形態では、エンコーダシステム１２およびデコーダシステム１４は、ビデオストリーミング、ＶＴ、またはその両方のために装備されたワイヤレスモバイル端末のようなビデオ通信デバイス内で具現化され得る。モバイル端末は、ＲＴＰ、ＲＴＣＰ、ＵＤＰ、ＩＰ、またはＰＰＰのようなパケット交換規格に従ってＶＴをサポートし得る。
【００２８】
[0034]  ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーディオエンコーダ２２およびビデオエンコーダ２０から受信されたオーディオおよびビデオデータに、ならびにＩＭＳ  ＶＴアプリケーションモジュール２４から受信された制御情報に、適切なＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダデータを加え、ＲＬＰキュー２８にそのデータを配置する。ＲＴＰがＵＤＰの上部で作動する一方で、ＵＤＰがＩＰの上部で作動し、ＩＰはＰＰＰの上部で作動する。ＭＡＣレイヤモジュール３０は、ＲＬＰキュー２８のコンテンツからＭＡＣ  ＲＬＰパケットを生成する。ＰＨＹレイヤモジュール３２は、チャネル１６にわたる送信のために、ＰＨＹレイヤパケットへとＭＡＣ  ＲＬＰパケットを変換する。
【００２９】
[0035]  復号システム１４のＰＨＹレイヤモジュール３４およびＭＡＣレイヤモジュール３６は、互恵的形式で動作する。ＰＨＹレイヤモジュール３４は、ＭＡＣ  ＲＬＰパケットに、チャネル１６から受信されたＰＨＹレイヤパケットを変換する。ＭＡＣレイヤモジュール３６は、ＲＬＰキュー３８にＭＡＣ  ＲＬＰパケットを配置する。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、ＲＬＰキュー３８の中のデータからヘッダ情報を取り除き、ビデオデコーダ４４およびオーディオデコーダ４６のそれぞれへの搬送のためにビデオおよびオーディオデータをリアセンブルする。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、同様に、ＲＬＰキュー３８の中のデータからヘッダ情報を取り除き、ＩＭＳ  ＶＴアプリケーションモジュール４２への搬送のために制御情報をリアセンブルする。ビデオデコーダ４４およびオーディオデコーダ４６は、ＩＭＳ  ＶＴアプリケーションモジュール４２と併せて、受信された制御情報に基づいて、ビデオおよびオーディオ復号決定（video and audio decoding decision）を行い得る。制御情報は、例えば、デバイス１２についての送信ビットレートが変わるべきかどうかを、ＩＭＳ  ＶＴアプリケーションモジュール４２がそれに基づいて決定することができる、送り手の報告を含み得る。ビットレートを変えることの一部として、ＩＭＳ  ＶＴアプリケーションモジュール４２は、ビデオデータが符号化されている解像度を調整し得る。
【００３０】
[0036]  システム１０は、符号分割多元接続（ＣＤＭＡ：code division multiple access）、周波数分割多元接続（ＦＤＭＡ：frequency division multiple access）、時分割多元接続（ＴＤＭＡ：time division multiple access）、または直交周波数分割多重（ＯＦＤＭ：orthogonal frequency divisional multiplexing）、または別の適したワイヤレス技法のような、１つ以上のワイヤレス通信技術をサポートするように設計され得る。上記のワイヤレス通信技術は、様々な無線アクセス技術のうちのいずれかに従って搬送され得る。例えば、ワイヤレス通信は、ｃｄｍａ２０００、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標）：wideband CDMA）規格、３Ｇ、４Ｇ、ロングタームエボリューション（ＬＴＥ（登録商標）：Long-Term Evolution）、または任意の他のＣＤＭＡベースのエアインターフェースに従って行われ得る。ＴＤＭＡは、モバイル通信のためのグローバルシステム（ＧＳＭ（登録商標）：Global System for Mobile Communications）規格に従って搬送され得る。ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ：Universal Mobile Telecommunication System）規格は、ＧＳＭまたはＷＣＤＭＡ動作を許可する。ＶＴアプリケーションの場合、システム１０は、ｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ、リリース０、リビジョンＡ、または後続ＥＶＤＯリリースのような高データレート（ＨＤＲ：high data rate）技術をサポートするように設計され得る。
【００３１】
[0037]  ビデオソース１８は、１つ以上のビデオカメラ、１つ以上のビデオアーカイブ、またはビデオカメラとビデオアーカイブの組み合わせのような、ビデオキャプチャデバイスであり得る。ビデオソース１８はさらに、コンピュータ生成グラフィックス（computer generated graphics）をキャプチャする、生成する、および／または含む能力を含み得る。ビデオエンコーダ２０は、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣ（アドバンスドビデオコーディング（ＡＶＣ：Advanced Video Coding））、またはＩＴＵ−Ｔ  Ｈ．２６５（高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）のような、ビデオ圧縮方法に従って、符号化されたビデオデータを生成する。国際電気通信連合（ＩＴＵ：International Telecommunication Union）Ｈ．２６３、ＶＰ９、ＭＰＥＧ−２、または他の標準化されたもしくは独占権下にある方法（standardized or proprietary method）のような、他のビデオ圧縮方法もまた使用され得る。ビデオエンコーダ２０は、概してＣＯＤＥＣ依存であるビデオソースレート制御スキームを提供し得る。例えば、ビデオエンコーダ２０は、ＨＥＶＣ、ＭＰＥＧ４、ＩＴＵ  Ｈ．２６３、ＩＴＵ  Ｈ．２６４、あるいは別の規格または技法に従うビデオ符号化のために適応され得る。一例では、ビデオエンコーダ２０は、デジタルシグナルプロセッサ（ＤＳＰ：digital signal processor）または埋め込まれたロジックコアによって実装され得る。
【００３２】
[0038]  オーディオソース１７は、マイクロフォンまたは音声合成器デバイスのような、オーディオキャプチャデバイスであり得る。オーディオエンコーダ２２は、ビデオデータに付随するようにオーディオデータを符号化し得る。オーディオデータは、適応マルチレート狭帯域（ＡＭＲ−ＮＢ：adaptive multi-rate narrow band）または他の技法のような、オーディオ圧縮方法に従って符号化され得る。ＶＴアプリケーションの場合、ビデオは、ＶＴ会議に対する当事者の表示を許可することとなり、オーディオは、その当事者の話す声が聞こえることを許可することとなる。
【００３３】
[0039]  オペレーションにおいて、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオエンコーダ２０およびオーディオエンコーダ２２からビデオおよびオーディオデータパケットを取得する。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーディオパケットに適切なヘッダ情報を追加し、ＲＬＰキュー２８内に、結果として生じたデータを挿入する。同様に、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオパケットに適切なヘッダ情報を追加し、ＲＬＰキュー２８内に、結果として生じたデータを挿入する。ＭＡＣレイヤモジュール３０は、ＲＬＰキュー２８からデータを検索し、ＭＡＣレイヤパケットを形成する。各ＭＡＣレイヤパケットは、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダ情報、およびＲＬＰキュー２８内に包含される、オーディオまたはビデオパケットデータを運ぶ。
【００３４】
[0040]  オーディオパケットは、ビデオパケットから独立して、ＲＬＰキュー２８に挿入され得る。いくつかのケースでは、ＲＬＰキュー２８のコンテンツから生成されたＭＡＣレイヤパケットは、ヘッダ情報およびビデオパケットデータのみを運ぶこととなる。他のケースでは、ＭＡＣレイヤパケットは、ヘッダ情報およびオーディオパケットデータのみを運ぶこととなる。
【００３５】
[0041]  いくつかのケースでは、ＭＡＣレイヤパケットは、ＲＬＰキュー２８のコンテンツに依存して、ヘッダ情報、オーディオパケットデータ、およびビデオパケットデータを運ぶこととなる。ＭＡＣレイヤパケットは、無線リンクプロトコル（ＲＬＰ）に従って設定され得、ＭＡＣ  ＲＬＰパケットと称され得る。ＰＨＹレイヤモジュール３２は、チャネル１６にわたる送信のために、ＰＨＹレイヤパケットへとＭＡＣ  ＲＬＰオーディオ−ビデオパケットを変換する。
【００３６】
[0042]  チャネル１６は、デコーダシステム１４にＰＨＹレイヤパケットを運ぶ。例えば、チャネル１６は、ローカルまたはワイドエリアワイヤードネットワークのような、ワイヤード接続であり得る。代替として、本明細書に説明されるように、チャネル１６は、セルラ、衛星、または光学チャネルのようなワイヤレスチャネルであり得る。チャネル１６はまた、ワイヤレスおよびワイヤードチャネルの組み合わせであり得る。
【００３７】
[0043]  チャネル条件は、ワイヤードおよびワイヤレスチャネルに関する懸念事項であり得るが、特に、チャネル条件がフェーディングまたは輻輳に起因して損害を被り得る、ワイヤレスチャネル１６にわたって行われるモバイルＶＴアプリケーションに対して問題がある。例えば、チャネル１６は、チャネル条件に従って変わるスループットを有する逆リンク（ＲＬ：reverse link）によって特徴付けられ得る。スループットは、現在のワイヤレスチャネル送信レート、ワイヤレス基地局アクティビティ、および送信電力制限、のうちの１つ以上によって表されるような、チャネル条件に基づいて推定され得る。例えば、チャネル条件は、現在のＭＡＣレイヤデータレート、逆アクティビティビット（ＲＡＢ：reverse activity bit）、および電力増幅器（ＰＡ：power amplifier）制限に基づいて決定され得る。
【００３８】
[0044]  ビデオエンコーダ２０は、ターゲット符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファを維持し得る。ターゲット符号化レートは、チャネル１６にわたって送信されるビデオパケットに対して指定された最大符号化レートであり得る。ビデオエンコーダ２０は、ビデオソース１８からのビデオの実際の符号化レートを制御し得る。
【００３９】
[0045]  デコーダシステム１４のＰＨＹレイヤモジュール３４は、ＰＨＹレイヤパケットからＭＡＣレイヤパケットを識別し、ＭＡＣ  ＲＬＰパケットへとコンテンツをリアセンブルする。ＭＡＣレイヤモジュール３６はその後、ＲＬＰキュー３８内への挿入のためのビデオおよびオーディオパケットを提供するために、ＭＡＣ  ＲＬＰパケットのコンテンツをリアセンブルする。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール４０は、付随するヘッダ情報を除去し、ビデオデコーダ４４にビデオパケットを、オーディオデコーダ４６にオーディオパケットを提供する。
【００４０】
[0046]  ビデオデコーダ４４は、ビデオ出力デバイス５０の一部を形成するディスプレイデバイスを駆動させる際に使用するビデオデータのストリームを発生させるためにビデオデータフレームを復号する。オーディオデコーダ４６は、例えば、オーディオ出力デバイス４８の一部を形成するオーディオスピーカを介して、ユーザへの提示のためのオーディオ情報を発生させるように、オーディオデータを復号する。
【００４１】
[0047]  ビデオ電話は、システム１２および１４のような、少なくとも２つのデバイスの間でオーディオおよびビデオデータを運ぶパケットのリアルタイム通信を指す。第１のＶＴデバイス１２は、例えば、ビデオカメラまたはビデオアーカイブであり得るビデオソース１８からビデオを取得し、ビデオパケットを生成するビデオエンコーダ２０を含む。同様に、ＶＴデバイス１２の中のオーディオエンコーダ２２は、例えば、マイクロフォンまたは音声合成器であり得るオーディオソース１７からオーディオを取得し、オーディオパケットを生成する。ビデオパケットおよびオーディオパケットは、ＲＬＰキュー２８に配置される。ＭＡＣレイヤモジュール３０は、ＲＬＰキュー２８のコンテンツからＭＡＣレイヤパケットを生成する。ＭＡＣレイヤパケットは、第２のＶＴデバイス１４への通信チャネル１６にわたる送信のために、ＰＨＹレイヤパケットに変換される。
【００４２】
[0048]  モバイルＶＴアプリケーションでは、ＶＴデバイス（ワイヤレス端末）は、基地局からワイヤレス順方向リンク（ＦＬ：forward link）（すなわち、「ダウンリンク（downlink）」）を介してＰＨＹレイヤパケットを受信する。ＶＴデバイスは、基地局にワイヤレス逆リンク（ＲＬ：reverse link）（すなわち、「アップリンク（uplink）」）を介してＰＨＹレイヤパケットを送信する。各ＶＴデバイスは、受信されたＰＨＹおよびＭＡＣレイヤパケットを変換し、オーディオパケットおよびビデオパケットへとパケットペイロードをリアセンブルするためのＰＨＹおよびＭＡＣレイヤを含む。ＶＴデバイス内のビデオデコーダ４４は、ディスプレイデバイス（ビデオ出力）５０を介したユーザへの提示のためにビデオデータを復号する。ＶＴデバイス内のオーディオデコーダ４６は、オーディオスピーカ（オーディオ出力）４８を介した出力のためにオーディオデータを復号する。
【００４３】
[0049]  図４は、汎用パケット交換（ＰＳ）ネットワーク５２にわたる２方向ＶＴコールの簡略化されたブロック図を描写する。ＰＳネットワーク５２は、ＬＴＥ、高速パケットアクセス（ＨＳＰＡ：high-speed packet access）、発展型高レートパケットデータ（（ｅ）ＨＲＰＤ：evolved high rate packet data）、ＷｉＦｉ、衛星、同軸ケーブル、電力線通信、および同様のもの、または上記の任意のものの組み合わせであることができる。図２のデバイスＡおよびＢは概して、図１のデバイス１２および１４に従うように設定され得る。デバイスＡの送信側では、ＶＴコールのオーディオ／ビデオは、マイク／スピーカ５６およびカメラ／ディスプレイ５４においてキャプチャされ、処理ユニット５８によって、該当する場合（if applicable）、前処理され、符号化／圧縮され、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰパケット化され、およびモデムに渡される。デバイスＡの受信側では、受信されたオーディオ／ビデオパケットは、マイク／スピーカ５６およびカメラ／ディスプレイ５４に送られる前に処理ユニット５８によって、該当する場合、復調され、パケット解除され（dis-packetized）、ジッタ除去され（de-jittered）、復号され、ＡＶ同期され、および後処理される。
【００４４】
[0050]  同様に、デバイスＢの送信側では、ＶＴコールのオーディオ／ビデオは、マイク／スピーカ６６およびカメラ／ディスプレイ６４においてキャプチャされ、処理ユニット６８によって、該当する場合、前処理され、符号化／圧縮され、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰパケット化され、およびモデムに渡される。デバイスＢの受信側では、受信されたオーディオ／ビデオパケットは、マイク／スピーカ６６およびカメラ／ディスプレイ６４に送られる前に処理ユニット６８によって、該当する場合、復調され、パケット解除され、ジッタ除去され、復号され、ＡＶ同期され、および後処理される。
【００４５】
[0051]  オーディオ／ビデオＲＴＣＰパケットもまた、ＡＶ同期、メディアパフォーマンス関連統計、レート適応、および同様のもののためにオーディオ／ビデオＲＴＰパケットとともに送られる。ＲＴＣＰパケットは、ＲＴＰパケットよりも低い頻度で生じる。すなわち、ＲＴＣＰパケットの制御情報が典型的に、５００ｍｓ毎から２秒毎でシグナリングされる一方で、ＲＴＰパケットは、より高い頻度で生じる。
【００４６】
[0052]  典型的な２当事者（two-party）ＶＴセッション中、ビデオは、ユーザアクションの結果として一方向または両方向で１回以上中断され得る。例えば、どちら側のユーザも、いくつかの他のタスクを簡潔に行うために、デバイス上でバックグラウンドにＶＴアプリケーションを移動させ得る。例えば、ＶＴコールの途中で、ユーザの一方が、写真を撮るために電話カメラを使用する、電子メールを素早くチェックする、または別のタスクを行い得る。結果として、ＶＴコールのためのカメラリソースはリリースされ得、このケースでは、どのビデオもピアサイドに送られない。すなわち、ユーザがバックグラウンドにＶＴアプリケーションを移動させるとき、ビデオは典型的に、ＶＴコールにおけるもう一方の当事者にはもはや送られない。バックグラウンドにおけるＶＴアプリケーションのユーザが、何のビデオが送信されているかを示すプレビューウィンドウをもはや見ることができないため、ビデオは、停止され得る。増大したプライバシを提供するために、および通知なしでビデオを送ることを回避するために、ＶＴアプリケーションは典型的に、ビデオＲＴＰパケットを送ることを中止することとなる。しかしながら、オーディオパケットは継続するであろうこととなり（would）、ＶＴはドロップ（drop）されない。ボイス通話が継続する一方でビデオストリームが１つ以上の方向に流れるのを停止する現象は典型的に、ビデオ中断と呼ばれる。
【００４７】
[0053]  図３および４は、本開示のビデオ電話技法を実装し得るシステムの例を図示する。例えば、第１のＶＴデバイス（例えば、図３のデバイス１２またはデバイス１４のうちの１つ、あるいは図４のデバイスＡまたはデバイスＢのうちの１つ）は、第２のＶＴデバイス（例えば、図３のデバイス１２またはデバイス１４のうちのもう１つ、あるいは図４のデバイスＡまたはデバイスＢのうちのもう１つ）ビデオ電話データを受信するように設定され得る。第１のＶＴデバイスは、ディスプレイデバイスにディスプレイを変更するための要求を受信し得、ピクチャバッファから第１のイントラコーディングされたピクチャをフラッシュし得る。要求を受信することおよび／またはピクチャバッファから第１のイントラコーディングされたピクチャをフラッシュすることに応答して、第１のＶＴデバイスおよび／またはディスプレイデバイスは、第２のＶＴデバイスに、第２のイントラコーディングされたピクチャを求める要求を送り得る。
【００４８】
[0054]  いくつかの実施形態では、第１のＶＴデバイス３は、第１のＶＴデバイス３に送られたディスプレイ情報が、ディスプレイデバイス６上でディスプレイされ得るように、ディスプレイデバイス６のアドレスに基づいて再設定され得る。第１のＶＴデバイス３は、ディスプレイデバイス６がrawビデオデータのみを受信し、データを処理する必要がないように、ビデオ情報を処理および／または復号し続け得る。図５は、以下にこのことがどのようにしてなされることができるかの例となる方法を提供する。
【００４９】
[0055]  図５は、複数の例となるコンポーネントの間でのコールフロー５００を例示する。一態様では、ＶＴアプリケーション５５０は、サーフェスビューコンポーネント（SurfaceView component）５５５、ＯｐｅｎＭａｘ（ＯＭＸ）デコーダ５６０、およびネットワーク５６５と相互作用し得る。これらのコンポーネントのうちの１つ以上は、デバイス、例えば、第１のＶＴデバイス３、１２に、およびに／または第１のデバイス３、１２と通信するように設定されるデバイスに一体化され得る。
【００５０】
[0056]  イベント１において、ＶＴアプリケーション５５０は、ＶＴセッションを開始し得る。例えば、セッションは、２つのユーザの間のＶＴコールの結果として始まり得る。サーフェスビューコンポーネント５５５は、ローカルまたはワイヤレスデバイスからアンドロイドフレームワークを介してサーフェスアドレスを受信し得る。サーフェスビューコンポーネント５５５は、ＶＴアプリケーション５５０にサーフェスアドレス５０２を送り得る。例えば、サーフェスアドレス５０２は、ＶＴコールで使用されるＶＴデバイス、サーフェスを示し得る。ある実施形態では、サーフェスアドレス５０２は、アンドロイドフレームワークから受信され得る。ＶＴアプリケーション５５０は、ＯＭＸデコーダ５６０にサーフェスアドレス５０４を送信し得る。ＯＭＸデコーダ５６０は次に、ＶＴアプリケーション５５０が指定されたアドレスにビデオ情報を直接キューすることを可能にするために、サーフェスアドレス５０４に基づいて、バッファを割り当て得る。
【００５１】
[0057]  ＶＴアプリケーション５５０は、ＲＴＰパケット５０６を受信するために、ネットワーク５６５と相互作用し得る。ＶＴアプリケーション５５０は、フレームをアセンブルし、ＯＭＸデコーダ５６０にそれらをキューするためにＲＴＰパケットを使用し得る。具体的には、Ｐフレームによって後続されるＩフレーム５０８は、復号されるようにＯＭＸデコーダ５６０にキューされ得る。ＯＭＸデコーダ５６０は、ＶＴアプリケーション５５０において受信され得る、rawフレーム５１０を戻し得る。ＶＴアプリケーションは次に、サーフェスビューコンポーネント５５５にrawフレーム５１２を送り得る。rawフレームは、第１のＶＴデバイス３、１２のサーフェスに直接レンダリングされ得る。
【００５２】
[0058]  新たなディスプレイデバイス６に切り替えるために、サーフェスビューコンポーネント５５５はまず、新たなディスプレイデバイス６を示す新たなサーフェスアドレス５１４を受信し、ＶＴアプリケーション５５０にそれを送信し得る。新たなサーフェスアドレスは、アンドロイドフレームワークから受信され得る。イベント２において、ＶＴアプリケーション５５０は、第１のＶＴデバイスのデコーダを再設定し、デコーダに包含された、異なるＶＴデバイスから受信されたＰフレームをレンダリングすることを停止し得る。ＶＴアプリケーションは、ＯＭＸデコーダ５６０に新たなサーフェスアドレス５１６を送信し得る。
【００５３】
[0059]  イベント３において、ＶＴアプリケーション５５０は、Ｉフレームを要求し得る。イベント３は、再設定が完了した後、または代替として、再設定が始まるとき、または再設定中に、起こり得る。ＶＴアプリケーション５５０は、ネットワーク５６５に、Ｉフレームを求める要求５１８を送り得る。例えば、要求は、ＲＴＣＰにわたるＡＶＰＦ  ＰＬＩまたはＦＩＲメッセージであり得る。ネットワーク５６５は、ＶＴアプリケーション５５０にＲＴＰパケット５２０を送り得る。ＶＴアプリケーション５５０は、フレームをアセンブルし、ＯＭＸデコーダ５６０にそれをキューするためにＲＴＰパケットを使用し得る。具体的には、Ｐフレームによって後続されるＩフレーム５２２は、復号されるようにＯＭＸデコーダ５６０にキューされ得る。
【００５４】
[0060]  ＯＭＸデコーダ５６０は、ＶＴアプリケーション５６０にrawフレーム５２４を戻し得、ＶＴアプリケーションは、新たなディスプレイデバイス６のサーフェス上でrawフレームをレンダリングするために、サーフェスビューコンポーネント５５５にrawフレーム５２６を送信し得る。イベント４において、ＶＴセッションは、終わり得る。
【００５５】
[0061]  図６は、本開示の技法に従う、例となるＶＴ方法を図示するフローチャートである。ブロック６０５において、プロセス６００が始まる。ブロック６１０において、プロセス６００は、ＶＴセッションを開始することに関与し得る。ＶＴセッションは、２つ以上のＶＴデバイス３、４の間のワイヤレスまたはワイヤード接続に関与し得る。ＶＴセッションは、別のＶＴデバイスにＶＴコールを行う１つのＶＴデバイスの結果として始まり得る。
【００５６】
[0062]  決定ブロック６１５において、プロセスは、ディスプレイ切り替えがＶＴデバイスのうちの１つに対して要求されたかどうかを決定することに関与し得る。ある実施形態では、ディスプレイ切り替えが要求されたかどうかを決定することは、新たなサーフェスアドレスが受信されたかどうかを決定することに関与し得る。代替の実施形態では、ディスプレイ切り替えを求める要求が新たなサーフェスアドレスなしに受信される場合、プロセス６００はまた、新たなサーフェスアドレスを要求することに関与し得る。ある実施形態では、ディスプレイ切り替えが要求されていない場合、プロセス６００は、ディスプレイ切り替えが要求されるかどうかを連続的におよび／または周期的に再チェックすることに関与し得る。代替的に、プロセス６００は、１度だけ、または異なる有限の数の回数、切り替え要求についてチェックすることに関与し得る。
【００５７】
[0063]  ブロック６２０において、ディスプレイ切り替えが要求されている場合、プロセス６００は、ディスプレイ切り替えを要求したＶＴデバイスのデコーダを再設定することに関与し得る。デコーダを再設定することは、デコーダに記憶されたフレーム（例えば、Ｉフレーム、Ｂフレーム、およびＰフレーム）のデコーダをフラッシュすることに関与し得る。結果として、ＶＴデバイスは、既存のフレームをレンダリングすることを停止し得る。再設定することはまた、ターゲットディスプレイデバイス６のアドレスに、サーフェスアドレスを更新することに関与し得る。
【００５８】
[0064]  決定ブロック６２５において、プロセス６００は、再設定が完了したかどうかを決定することに関与し得る。再設定が完了した場合、プロセス６００は、ブロック６３０に進み得、ここで、プロセス６００は、Ｉフレームを求める要求を送ることに関与し得る。再設定が完了していない場合、プロセス６００は、再設定が完了したかどうかをチェックし続けることに関与し得る。代替として、プロセス６００は、再設定中に、および／または再設定の前にＩフレーム要求を送ることに関与し得る。第１のＶＴデバイスおよび／またはターゲットディスプレイデバイス６は、Ｉフレームを求める要求を送り得る。１つの例では、Ｉフレーム要求は、ＰＬＩまたはＦＩＲメッセージをトリガすることによって行われ得る。
【００５９】
[0065]  ブロック６３５において、プロセス６００は、ターゲットディスプレイデバイス６上でＶＴデータをレンダリングすることに関与し得る。ターゲットディスプレイデバイス６において受信されたデータは、ターゲットディスプレイデバイス６がデータを処理する必要がないような、rawデータであり得る。代替として、ターゲットディスプレイデバイス６は、符号化されたデータを受信し得、サーフェス上でそれをレンダリングする前にデータを復号するためのデコーダを備え得る。ブロック６４０において、プロセス６００が終わる。
【００６０】
[0066]  図７は、本開示の技法に従う、別の例となるＶＴ方法を図示するフローチャートである。ブロック７０５において、プロセス７００が始まる。ブロック７１０において、プロセス７００は、ＶＴデータを受信することに関与し得る。例えば、ＶＴデータは、ネットワーク５を介してＶＴデバイス３において受信され得る。
【００６１】
[0067]  ブロック７１５において、プロセス７００は、受信されたＶＴデータを復号したに関与し得る。上記に説明されたように、ＶＴデバイス３は、デコーダ受信されたデータ（decoder received data）のためのデコーダ、例えば、ＯＭＸデコーダを有し得る。
【００６２】
[0068]  ブロック７２０において、プロセス７００は、復号されたＶＴデータを記憶することに関与し得る。ＶＴは、例えば、ＣＰＢに記憶され得る。
【００６３】
[0069]  決定ブロック７２５において、プロセス７００は、第１のディスプレイから第２のディスプレイへの切り替えを示す情報を検出することに関与し得る。ある実施形態では、検出することは、送信された情報を受信することを備え得る。例えば、情報は、ネットワーク５を介してＶＴデバイス３において受信され得る。ある実施形態では、情報は、第２のディスプレイと関連付けられたサーフェスアドレスであり得る。サーフェスアドレスは、任意のディスプレイサーフェスを示し得る。例えば、ディスプレイサーフェスは、ＶＴデバイス３またはディスプレイデバイス６と一体化され得る。
【００６４】
[0070]  ブロック７３０において、プロセス７００は、Ｉフレーム要求を送信することに関与し得る。Ｉフレーム要求は、ネットワーク５を介して送信され得る。ブロック７３５において、プロセス７００が終わる。
【００６５】
[0071]  １つ以上の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせで実現され得る。ソフトウェアで実現される場合、機能は、コンピュータ読み取り可能な媒体上で１つ以上の命令またはコードとして記憶または送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ読み取り可能な媒体は、例えば、通信プロトコルに従って、１つの場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体、またはデータ記憶媒体のような有形の媒体に対応するコンピュータ読み取り可能な記憶媒体を含み得る。このように、コンピュータ読み取り可能な媒体は概して、（１）非一時的である有形のコンピュータ読み取り可能な記憶媒体、または（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示に説明された技法の実施のための命令、コード、および／またはデータ構造を検索するために、１つ以上のコンピュータまたは１つ以上のプロセッサによってアクセスされることができる任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ読み取り可能な媒体を含み得る。
【００６６】
[0072]  限定ではなく例として、そのようなコンピュータ読み取り可能な記憶媒体は、ランダムアクセスメモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ（登録商標）：electrically erasable programmable read-only memory）、ＣＤ−ＲＯＭまたは他の光ディスク記憶媒体、磁気ディスク記憶媒体、または他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態で所望されるプログラムコードを記憶するために使用されることができ、コンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、任意の接続は、コンピュータ読み取り可能な媒体と適切に称される。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：digital subscriber line）、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバ、または他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ読み取り可能な記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まないが、代わりに非一時的な、有形の記憶媒体を対象にすることが理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ：compact disc）、レーザーディスク（登録商標）、光ディスク、デジタル多目的ディスク（ＤＶＤ：digital versatile disc）、フロッピー（登録商標）ディスクおよびブルーレイディスクを含み、ここで、ディスク（disk）は、通常磁気的にデータを再生し、一方ディスク（disc）は、レーザーを用いて光学的にデータを再生する。上記の組み合わせもまた、コンピュータ読み取り可能な媒体の範囲内に含まれるべきである。
【００６７】
[0073]  命令は、１つ以上のＤＳＰ、汎用マイクロプロセッサ、特定用途集積回路（ＡＳＩＣ：application specific integrated circuit）、フィールドプログラマブル論理アレイ（ＦＰＧＡ：field programmable logic array）、または他の同等な集積または離散論理回路のような１つ以上のプロセッサによって実行され得る。従って、本明細書で使用される場合、「プロセッサ（processor）」という用語は、前述の構造または本明細書に説明された技法の実現に適したあらゆる他の構造のいずれかを指し得る。加えて、いくつかの態様において、本明細書に説明された機能は、符号化および復号のために設定される専用ハードウェアモジュールおよび／またはソフトウェアモジュール内で提供され得る、または組み合わせられたコーデックに組み込まれ得る。また、技法は、１つ以上の回路または論理要素において完全に実現されることができる。
【００６８】
[0074]  本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ：integrated circuit）またはＩＣのセット（例えば、チップセット）を含む、幅広い様々なデバイスまたは装置において実装され得る。様々なコンポーネント、モジュール、またはユニットは、本開示において、開示された技法を行うように設定されるデバイスの機能的な態様を強調するために説明されているが、それらは、異なるハードウェアユニットによる実現を必ずしも必要とするわけではない。むしろ、上記に説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて組み合わせられるか、または、適切なソフトウェアおよび／またはファームウェアと併せて、上記に説明されたような１つ以上のプロセッサを含む、相互動作のハードウェアユニットの集合によって提供され得る。
【００６９】
[0075]  様々な例が説明されてきた。これらの例および他の例は、以下の特許請求の範囲内にある。
【図１】
2018529249.tif 000003
【図２】
2018529249.tif 000004
【図３】
2018529249.tif 000005
【図４】
2018529249.tif 000006
【図５】
2018529249.tif 000007
【図６】
2018529249.tif 000008
【図７】
2018529249.tif 000009
【国際調査報告】
2018529249.tif 000010
2018529249.tif 000011
2018529249.tif 000012