JP6867162B2 - 異なる符号化パラメータを用いて符号化された複数の符号化物のストリーミング - Google Patents

Description

本開示は、ビデオデータの符号化に関し、特に、複数の符号化物を提供してストリーミングすることに関する。

関連出願への相互参照
本願は、米国特許法１１９条（ｅ）により２０１４年１月１５日に出願された米国仮特許出願第６１／９２７９５２号の利益を主張する、米国特許法１１９条（ｅ）により２０１４年１２月１１日に出願された米国特許出願第１４／５６８０８１号の利益を主張する。これらの開示内容の全体は参照によってここに組み込まれる。

典型的なビデオ監視システムにおいて、サーバシステムには１つ又は複数のカメラが通信可能に接続される可能性がある。ビデオデータがカメラによって記録されるとき、それはサーバシステムに転送され、それはここで後の検索のために格納される。クライアントシステムは、サーバシステムに通信可能に接続される。クライアントシステムは、記録されたビデオデータのストリームを要求して受信するために使用されてもよい。

ビデオデータをクライアントへストリーミングする際に使用するために様々な技術が開発されている。しかしながら、既存の技術には欠落がある。例えば、多くの技術が、関連するビデオ符号化間における同期の必要性に適切に対処することに失敗している。

本発明は、異なる符号化パラメータを用いて符号化された複数の符号化物のストリーミングのための方法及びディスプレイシステムを提供する。

開示した実施形態の態様によれば、ソースビデオを符号化する方法が開示される。例示の実施形態において、ソースビデオのソースフレームを受信する、ソースフレームの異なる仮想フレームが符号化され、異なる仮想フレームのそれぞれは、少なくとも１つの異なる符号化パラメータを用いて符号化されている。コンテナフレームは、複数の仮想フレームから形成され、ネットワークを介して送信される。例示の実施形態において、コンテナフレームは、仮想フレームと、コンテナフレームにおける仮想フレームのすべてに適用可能なコンテナタイムスタンプとを含む。

例示のシナリオにおいて、複数の仮想フレームはコンテナフレームにおいてともに連結され、仮想フレームのそれぞれは、互いに仮想フレームの境界を定めるデリミタを有する仮想フレームヘッダを含む。コンテナフレームは、コンテナタイムスタンプを含むコンテナフレームヘッダを含んでもよい。コンテナフレームタイムスタンプは、仮想フレームが生成されたソースフレームに含まれるタイムスタンプと同じである。

例えば、仮想フレームを符号化するために使用される符号化パラメータは、任意の適切なパラメータであってもよく、ソースフレームの関心対象領域、フレームレート、ビデオ品質、圧縮比、量子化パラメータ、ビデオ解像度、及び、圧縮技術／符号化フォーマットを含むグループから選択されてもよい。

例示の実施形態において、ビデオソース装置は、仮想フレームを符号化して制御サーバへ送信する。ビデオソース装置は、例えば、ソースビデオのソースフレームを受信するプロセッサと、プロセッサに通信可能に接続されたメモリであって、本明細書で説明するように、プロセッサにソースフレームを符号化させて、かつ符号化されたフレームを送信させるためのステートメント及び命令をそこに格納したメモリとを備えてもよい。

開示した実施形態の態様によれば、制御システムは、複数の異なる及び独立の解像度符号化物を提供するように複数の符号化構成要素を構成するために、ビデオソース装置に構成コマンドを送信してもよい。コマンドは、解像度符号化物のうちの少なくとも１つが複数の個々に符号化された仮想ストリームを含むことを指定してもよい。制御システムは、ビデオソース装置から、ビデオソース装置が提供するように構成される複数の個々の仮想ストリームの記述を受信してもよく、ここで、解像度符号化物のそれぞれが個々の仮想ストリームのうちの１つ又は複数を含む。制御システムが複数の個々の仮想ストリームのデータストリームを受信するとき、システムは、複数の個々の仮想ストリームのそれぞれに各解像度符号化物を関連付ける。

開示した実施形態のもう１つの態様によれば、制御サーバは、符号化されたビデオをクライアントシステムへストリーミングしてもよい。例示の実施形態において、制御サーバは、複数の符号化物のうちのどれがクライアントに送信されるかを示す情報を含むクライアントストリーミングパラメータを受信する。複数の符号化物のそれぞれは、少なくとも１つの異なる符号化パラメータを用いて符号化されたビデオデータを含んでもよい。サーバは、複数の符号化物のうちのどれがクライアントストリーミングパラメータを満たすか決定し、クライアントストリーミングパラメータを満たす１つ又は複数の複数の符号化物をクライアントに送信する。例えば、符号化パラメータは、任意の適切なパラメータであってもよく、ソースフレームの関心対象領域、フレームレート、ビデオ品質、圧縮比、量子化パラメータ、ビデオ分解能、及び圧縮技術／符号化フォーマットを含むグループから選択されてもよい。例示の実施形態において、複数の符号化物は、不同一の第１及び第２の関心対象領域（ＲＯＩ）に従ってそれぞれ符号化された第１及び第２の符号化物を含んでもよい。ＲＯＩは相互に排他的であってもよい。

開示した実施形態のもう１つの態様によれば、第１及び第２の符号化物はモニタ上に表示されてもよい。例示のシナリオにおいて、第１及び第２の符号化物はモニタの隣接した部分の上に表示されてもよい。さらにもう１つの例示のシナリオにおいて、複数のＲＯＩは少なくとも部分的に重複してもよい。第１のＲＯＩは第２のＲＯＩの部分集合であってもよく、第１の符号化物は第２の符号化物よりも高い解像度で符号化されてもよい。

開示した実施形態のもう１つの態様によれば、複数の符号化物を表示するための方法が開示され、各符号化物は、少なくとも１つの異なる符号化パラメータを用いて符号化されたビデオデータを含む。例示のシナリオにおいて、本方法は、クライアントにおいて、複数の符号化物を受信することを含んでもよく、複数の符号化物は、不同一の第１及び第２の関心対象領域（ＲＯＩ）に従ってそれぞれ符号化された第１及び第２の符号化物を含む。例示のシナリオにおいて、ＲＯＩは相互に排他的であってもよい。符号化物は、コンテナフレームの一部としてクライアントに送信されてもよい。コンテナフレームは、符号化物のうちの１つにそれぞれ対応する複数の仮想フレームを含んでもよく、仮想フレームのすべてに適用可能なコンテナタイムスタンプを含んでもよい。第１及び第２の符号化物はクライアントのモニタ上に表示される。

この概要は簡単化された形態で概念の選択を導入するために提供され、この概念は以下の発明を実施するための形態でさらに説明される。この概要では、本願要旨のキーとなる特徴又は本質的な特徴を識別することは意図せず、また、本願要旨の範囲を限定するために用いることも意図しない。他の特徴を以下に説明する。

複数解像度符号化物を生成して格納するように適合した例示の監視システムを示す。 複数解像度符号化物を表示するように適合した例示のディスプレイモニタを示す。 複数解像度符号化物を生成して受信するように適合した例示のビデオソース装置及び制御サーバを示す。 ビデオソース装置及び制御サーバによって提供される例示の機能的特徴を示す。 多重化された仮想フレームとそれらの仮想フレームを記述するために使用される記述子とを含む例示のコンテナフレームを示す。 多重化されたコンテナフレームを含む例示のビデオストリームであって、多重化されたコンテナフレームが制御サーバによって多重分離されて処理される場合を示す。 複数解像度符号化に含まれる個々の仮想ストリームを記述する例示のビデオソース装置応答を示す。 異なる解像度における関心対象領域の例示の符号化の図を示す。 ビデオソース装置からデータをストリーミングする例示の方法のフロー図を示す。 ソースビデオを符号化する例示の処理のフロー図を示す。 ソースビデオを符号化する例示の方法のフロー図を示す。 制御サーバ及びクライアントによって提供される例示の機能的特徴を示す。 制御サーバによって多重化されてクライアントに送信されるコンテナフレームを含む例示のビデオストリームを示す。 クライアントから制御サーバにクライアントストリーミングパラメータを送信する例示の方法を示す。 制御サーバからクライアントに、コンテナフレームを備えるデータストリームを送信する例示の方法を示す。 複数の仮想ストリームのどれを多重化して制御サーバからクライアントに送信するかを決定する例示の方法を示す。 ビデオソース装置からビデオのアクティブセッションの通信に適合した例示のクライアントサーバーシステムのブロック図を示す。 画像合成方法の例示のアプリケーションを示す。

前述した発明の概要及び後述する発明を実施するための形態の追加の説明は、添付された図面と共に読んだとき、よりよく理解される可能性がある。開示したシステム及び方法の潜在的な実施形態が図示されたものに限定しないことが理解される。

出願人はここで、ソースビデオストリームの複数の符号化物をストリーミングするためのシステム及び方法を開示する。例示の実施形態では、ソースビデオ装置システムは、複数のソースビデオフレームを含むソースビデオの取り込み及び／又は受信を行ってもよい。符号化前のビデオは「ソースビデオ」と呼ばれ、ビデオの各フレームは「ソースフレーム」と呼ばれる。ソースビデオ装置システムは、ソースビデオフレームを仮想フレームへ符号化する。仮想フレームのそれぞれは、少なくとも１つの異なる符号化パラメータを用いて符号化されている。符号化パラメータは、例えば、関心対象領域、フレームレート、ビデオ品質、ビデオ解像度、及び圧縮技術／符号化フォーマットを含む、任意の適切なものであってもよい。ソースビデオ装置システムは、仮想フレームからコンテナフレームを形成し、ネットワークを介してコンテナフレームを送信する。例示の実施形態において、コンテナフレームは、特定のソースフレームに関連付けられた仮想フレームと、コンテナフレームにおける仮想フレームのすべてに適用可能なコンテナタイムスタンプとを含む。

クライアントにソースビデオの複数の符号化物を送信するとき、クライアントが、受信する複数の符号化物からのフレームを同期化可能であることが望ましい。同期化は少なくとも以下の２つの問題を扱う。
１）クライアントが符号化物のうちのあるものから他のものに切り換えるとき、符号化物間の任意の時間オフセットは、ビデオにおける不連続（又は時間的な「ジャンプ」）として現れる。これは望ましくない。
２）クライアントがソースビデオの隣接した複数の関心対象領域（region of interest：以下では「ＲＯＩ」とも呼び、これらの用語は互いに交換可能である）を表す複数の符号化物を同時に表示しているとき、それらの符号化物間の任意の時間オフセットは、それらの関心対象領域間で交差する任意の目標物に、不連続、又は時間的な「ジャンプ」を経験させる。このことは、目標物がそれらの関心対象領域間で滑らかに遷移することを妨げる。これもまた望ましくない。

ビデオを同期させる複数の従来の方法がある。例えば、ＪＰＥＧ２０００フォーマットを用いて符号化物が形成されるとき、複数の異なる解像度及び画像タイルを同じビットストリームへ埋め込むことができる。この技術に係る問題点は、消費者空間において広くは採用されていないＪＰＥＧ２０００に圧縮標準が限定されていることと、異なる解像度及びタイルを互いに分離することがビットストリームの構文解析を必要とすることとを含む。

もう１つの例示として、リアルタイム送信のための最も一般的なメディアトランスポートプロトコルであるリアルタイムトランスポートプロトコル（ＲＴＰ）上でビデオを送信するとき、ＲＴＰ制御プロトコル（ＲＴＣＰ）は、各ストリームの各ビデオフレームについて、ストリームを生成して送信するカメラによって生成された協定世界時（ＵＴＣ）の時間を回復するために使用される。この方法で複数の符号化物を送信するとき、カメラは、符号化物のそれぞれを送信するために異なるＲＴＰストリームを使用する。フレームについてＵＴＣ時間を回復し、その時間を用いて異なるストリームからのビデオを同期させることができる。しかしながら、カメラ時間におけるＵＴＣは、それが同期させられる時間ソースにおける変化に起因して、又は、その時間ソースにおける不正確さに起因して、不連続、又は時間的な「ジャンプ」を経験する可能性がある。ＵＴＣ時間におけるいかなるジャンプも、結果的に、各フレームについて回復されたＵＴＣ時間における変化をもたらす。しかしながら、この時間変化は各ストリームに同時には影響しない。従って、異なるストリームのフレームは、カメラにおけるＵＴＣ時間ジャンプが生じるごとに一時的に非同期になる。これはユーザの観点から見て不適当である。

クライアントにおける異なるストリーム間のフレームの同期化の必要性を回避するために、また、本明細書で説明するように、カメラにおける異なる符号化物のフレームを同期させて、同じＵＴＣタイムスタンプを有するすべてのフレームを１つのコンテナフレームにラップし、複数のコンテナフレームからなる単一のストリームをクライアントに送信することができる。例えばカメラのようなビデオソース装置は、ソースフレームを含むソースビデオを生成する。カメラは、ＵＴＣタイムスタンプを各ソースフレームに適用する（「ソースフレームタイムスタンプ」）。ビデオソース装置は、各ソースフレームの複数の符号化物を生成し、そのそれぞれは、少なくとも１つの異なる符号化パラメータを用いることにより他の符号化物から識別される。ソースフレーム符号化物のそれぞれは同じソースフレームから生成されるので、それらはすべて同じタイムスタンプを共有する。ビデオソース装置は、共通のタイムスタンプを共有するソースフレーム符号化物から１つのコンテナフレームを生成する。ビデオソース装置は、コンテナフレームのヘッダ（「コンテナフレームヘッダ」）に、様々なソースフレーム符号化物のタイムスタンプに同一であるタイムスタンプ（「コンテナタイムスタンプ」）を付加する。ビデオソース装置は、さらに詳細に以下で議論されるように、仮想ストリーム識別子又は「ｖｓｔｒｅａｍ ｉｄ」を含むデリミタを含むヘッダ（「仮想フレームヘッダ」）を有する異なるソースフレーム符号化物をそれぞれ含むフレームを生成することによって、以下では「仮想フレーム」とも呼ばれるものを生成する。複数の符号化物のうちのいずれか１つの仮想フレームは、まとめて「仮想ストリーム」を構成する。本明細書で使用されるように、コンテナ及び仮想フレームは、典型的には、ＯＳＩモデルのデータリンク層におけるデータ構造と比較して、ＯＳＩモデルのアプリケーション層におけるデータ構造を参照する。

例示的な符号化システム
図１は、ビデオの複数解像度符号化物（複数解像度の符号化物）を提供することができる監視システム１００を示す。図１の例示の実施形態は、仮想ストリーム間で異なる可能性がある符号化パラメータの一例として、異なるソースの関心対象領域の複数解像度を用いているが、代替例では、仮想ストリーム間で任意の１つ又は複数の符号化パラメータが異なっていてもよい。システム１００は、複数のビデオソース装置１１０、１１４からビデオを受信することと、受信されたビデオの記憶装置を管理することと、ビデオを１つ又は複数クライアント１４２へストリーミングすることとを含む様々な機能を提供する制御サーバ１０２を含む。制御サーバ１０２は、１つ以上の物理的コンピュータによって、及び／又は、１つ以上の仮想コンピュータによって提供されてもよい。１つの代替の実施形態（図示せず）において、制御サーバ１０２機能は、ビデオソース装置１１０、１１４のうちの１つ又は複数自体によって実装可能である。次いで、それらは、複数解像度符号化物をクライアント１４２に直接に送信することができる。制御サーバ１０２は、複数のディジタルＩＰカメラ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ（まとめてＩＰカメラ１１０と呼ぶ）に接続されるとともに、複数のストリーミングエンコーダ１１４ａ、１１４ｂ（まとめてエンコーダ１１４と呼ぶ）に接続されてもよい。エンコーダ１１４は、１つ又は複数のディジタル又はアナログカメラ１１２ａ、１１２ｂ、１１２ｃ（まとめてカメラ１１２と呼ぶ）に接続されてもよい。ＩＰカメラ１１０及びエンコーダ１１４を、まとめて、ビデオソース装置と呼ぶこともある。ビデオソース装置は、ネットワーク１１６を介して制御サーバ１０２へビデオをストリーミングしてもよい。ネットワーク１１６は、任意の適切な技術を備えてもよく、ネットワーク１１６は、例えば、有線のローカルエリアネットワーク（ＬＡＮ）、無線のローカルエリアネットワーク（ＷＬＡＮ）、さらにワイドエリアネットワーク（ＷＡＮ）を含む、１つ又は複数の個々のネットワークによって提供されてもよい。

制御サーバ１０２は、仮想ストリームマネージャ機能を備えてもよい。制御サーバ１０２が装置から受信する仮想ストリームを管理する、制御サーバ１０２に常駐の仮想ストリームマネージャを、以下では、「サーバ・装置仮想ストリームマネージャ」又は「サーバ・装置ＶＳマネージャ」１０４とする。サーバ・装置ＶＳマネージャ１０４は、独立の複数解像度符号化物をストリーミングするためにビデオソース装置１１０、１１４を構成する機能を提供する。サーバ・装置ＶＳマネージャ１０４は、ビデオソース装置１１０、１１４からストリームを受信し、受信されたストリームを個々の仮想ストリームへ多重分離する機能を備えてもよい。多重分離された仮想ストリームは、例えば、複数の仮想ストリームのうちの１つ又は複数を除去することにより、異なる方法で合成されて再び多重化されてもよい。ビデオソース装置１１０、１１４からのストリームの個々の仮想ストリームは、記憶のために記憶装置管理機能１０８に提供されることが可能である。さらに、個々の仮想ストリームの１つ又は複数は、追加の仮想ストリームマネージャ機能に提供されてもよく、特に、制御サーバ１０２がクライアント１４２に送信する仮想ストリームを管理する、制御サーバ１０２に常駐する仮想ストリームマネージャを、以下では、「サーバ・クライアント仮想ストリームマネージャ」又は「サーバ・クライアントＶＳマネージャ」１０６とする。個々の仮想ストリームは、記憶装置管理機能１０８及びサーバ・装置ＶＳマネージャ１０４のいずれかから、サーバ・クライアントＶＳマネージャ１０６に提供されてもよい。サーバ・クライアントＶＳマネージャ１０６は、１つ以上の仮想ストリームを、ネットワーク１４４を介してクライアント１４２へストリーミングする。

ビデオソース装置１１０、１１４のそれぞれは、各ビデオソース装置１１０、１１４の能力と、ネットワーク１１６の帯域幅、ネットワーク１４４の帯域幅、利用可能な記憶スペース、及び監視システムの要件のような、他の構成要素の能力と、ビデオソース装置１１０、１１４の動作にとって本質的な他の適切なパラメータとに依存して、様々な仮想ストリーム符号化物を提供するように構成されてもよい。ビデオソース装置１１０、１１４は、単一解像度符号化物又は複数の個別解像度符号化物を提供してもよい。さらに、各解像度符号化物は、多数の仮想ストリームによって提供されてもよい。ストリーム１１８は、図１では、ＩＰカメラ１１０からネットワーク１１６を介して制御サーバ１０２にストリーミングされるように示す。

図示するように、ストリーム１１８は、多数の個別解像度符号化物１２０、１２２、１２４を備える。個別解像度符号化物１２０、１２２、１２４は、ソースビデオの同じ部分を符号化したものとして図示される。それは、カメラ１１０ａのセンサの関心対象領域の実質的に全体であることが意図される。例えば、解像度符号化物１２０はソースのフル解像度で符号化されてもよく、解像度符号化物１２２はソース解像度の２分の１で符号化されてもよく、解像度符号化物１２４はソース解像度の４分の１で符号化されてもよい。個別解像度符号化物１２０、１２２、１２４のそれぞれは、Ｈ．２６４又はＪＰＥＧのような各符号化フォーマットを用いて、ソースビデオを符号化する。代替の実施形態において、解像度を調整する代わりに、ストリーム１１８は、解像度に加えて、又は解像度に代えて、フレームレート及びビデオ品質のような１つ以上の異なる符号化パラメータを変化させることで符号化されてもよい。

個別解像度符号化物１２０、１２２、１２４のそれぞれは、ストリーム１１８内の１つ又は複数の仮想ストリーム１２６、１２８、１３０によって提供されてもよい。
各仮想ストリーム１２６、１２８、１３０は、各解像度符号化物１２０、１２２、１２４の圧縮レベルで符号化されたビデオソースの少なくとも一部を含む。図示するように、フル解像度符号化物１２０は、仮想ストリームの３×４タイリングによって提供される。１２個の仮想ストリーム１２６のそれぞれは、同じ符号化フォーマットで符号化され、１２個の仮想ストリームが互いに合成されるとき、それらはフル解像度のソースビデオを提供する。代替の実施形態において、これらの１２個の仮想ストリームのうちの任意の１つ又は複数を符号化するために、異なる符号化フォーマット又は異なる符号化パラメータが使用可能である。解像度符号化物１２２は、単一の仮想ストリームによって提供されるものとして図示される。従って、仮想ストリーム１２８は、ビデオソースの１／２の解像度を有してもよい。同様に、仮想ストリーム１３０は、ビデオソースの１／４の解像度を有してもよい。より大きな領域のタイリングを提供するものとして説明したが、仮想ストリームはタイルを形成する必要はなく、むしろ、各仮想ストリームは、フルソースビデオを含んでもよい特定の関心対象領域又はその部分を符号化してもよい。様々な仮想ストリームは、同じ関心対象領域で重複してもよく、又は、ソースビデオの重複しない部分を符号化してもよい。

サーバ・装置ＶＳマネージャ１０４は、ストリーム１１８のような、ビデオソース装置１１０、１１４からのストリームを受信してもよい。サーバ・装置ＶＳマネージャ１０４は、受信されたストリーム１１８から、個別解像度符号化１２０、１２２、１２４の仮想ストリームを多重分離してもよい。多重分離された仮想ストリームは、記憶装置管理機能１０８にわたされてもよい。さらに、複数の仮想ストリームのうちの１つ又は複数は、クライアント１４２にストリーミングするためにサーバ・クライアントＶＳマネージャ１０６にわたされてもよい。

図示するように、記憶装置管理機能１０８は、解像度符号化物の仮想ストリームをデータ記憶装置１３２に格納する。記憶装置管理機能１０８は、解像度符号化物１３４の各々をデータ記憶装置へわたしてもよい。記憶装置管理機能１０８及びデータ記憶装置１３２は、必要とされる記憶容量を減らすために、複数の異なる記憶装置セクション又は層にビデオデータを格納してもよい。図示するように、短期記憶装置層１３６が解像度符号化物の各々を格納してもよい。所定期間が経過した後、フル解像度符号化物がもはや格納される必要はないと決定されてもよい。フル解像度符号化物は記憶装置から削除されてもよく、残りの解像度符号化物が記憶装置層１３８に格納されていてもよい。同様に、所定期間の後、中解像度符号化物がもはや格納される必要はないと決定されてもよく、また、それ自体は記憶装置から除去されてもよく、残りの解像度符号化物は１４０として格納されていてもよい。例示の実施形態において、仮想ストリームは、記憶領域又は層１３６、１３８、及び１４０のそれぞれにおいて別々に格納され、各仮想ストリームが格納されていた期間又は時間長は独立して保持される。そのような実施形態では、所定期間が経過した後、記憶領域１３６、１３８、及び１４０に格納されたままであった仮想ストリームからコンテナフレームが再構成されてもよい。

データ記憶装置１３２は、制御サーバと同じ計算システムによって提供されてもよい。追加的又は代替的に、データ記憶装置は別個の計算装置によって提供されてもよい。さらになお、制御サーバに直接に接続されるように図示したが、データ記憶装置はネットワークによって制御サーバに接続されてもよいことが意図される。

上述したように、サーバ・クライアントＶＳマネージャ１０６は、ネットワーク１４４を介してモニタリングクライアント１４２にストリーミングするために、サーバ・装置ＶＳマネージャ１０４及び記憶装置管理機能１０８のいずれかから解像度符号化物を受信してもよい。複数の解像度符号化物は、複数の異なるビデオソース装置からのものであってもよい。図示したように、各解像度符号化物１４６ａ、１４６ｂ、１４６ｃ、１４６ｄは個々にストリーミングされてもよく、又は、複数の解像度符号化物のうちの１つ又は複数は互いに合成されて単一のストリームにされてもよい。図示するように、複数の異なるビデオソース装置からの低解像度符号化物に対応する多数の仮想ストリーム１４８ａ、１４８ｂ、１４８ｃ、１４８ｄは、モニタリング装置１４２にストリーミングされる。モニタリング装置１４２は、仮想ストリーム１４８ａ、１４８ｂ、１４８ｃ、１４８ｄを受信して復号し、復号されたビデオ１５０を表示してもよい。

図１には図示しないが、代替として、モニタリングクライアント１４２のようなクライアント装置、または、制御サーバ１０２のようなサーバにおいて実行中のクライアントプロセスは、仮想ストリーム１４８ａ、１４８ｂ、１４８ｃ、１４８ｄの１つ又は複数を受信して復号し、ビデオ１５０と同様である合成ビデオストリームを作成してもよい。ただし、それは表示されない。代わりに、そのようなクライアント装置又は処理は、セルラー電話機、ラップトップコンピュータ、タブレットなどのような移動体装置上に表示される合成ビデオストリームを再符号化し、次に、再符号化された合成ストリームをネットワーク１１６又はネットワーク１４４のようなネットワークを介して移動体装置に送信してもよい。その後、移動体装置は、移動体装置のユーザのために移動体フォーマットでビデオを表示してもよい。

図２は、ビデオの複数の異なる解像度符号化物を表示するモニタを示す。モニタはコンピュータモニタであってもよいが、代替として、それは、タブレット型コンピュータのディスプレイ、スマートフォンディスプレイ、タイリングされたディスプレイのような任意の適切なディスプレイであってもよい。図２は、３つの異なるビュー２００、２１２、２１８を示す。最初に、モニタリングクライアントはビュー２００を表示する。それは４つの仮想ストリームの最低解像度符号化物２０２、２０４、２０６、２０８を含む。例えば、４つの異なるカメラからの仮想ストリームが同時に表示されてもよい。低解像度符号化物２０２のうちの１つは、ズームインするために、例えばそれをマウス又は他のポインタ２１０でクリックすることで選択されてもよい。解像度符号化物２０２が全画面で表示されるとき、符号化物の品質は所望よりも低い可能性がある。従って、選択されたカメラのビューからの中解像度符号化物２１４が、ビュー２１２に示すようにストリーミングされて表示されることが可能である。ユーザは、表示された解像度符号化物２１４の一部２１６を見るためにさらにズームインすることを望んでもよい。再び、所望の画質を提供するためにズームインするとき、解像度符号化物２１４の品質は十分ではない可能性がある。従って、ビュー２１８に示すように部分２２０にズームインしたものを表示する際に、フル解像度符号化物が使用可能である。

上述したように、フル解像度符号化物は多数の仮想ストリームを含んでもよい。従って、選択されたズームインされた領域を覆うフル解像度符号化物の仮想ストリームのみが、モニタリングクライアント１４２にストリーミングされる必要がある。例えば、フル解像度が仮想ストリームの４×３グリッドとして提供される場合、上の行及び第３及び第４列における仮想ストリームが所望の領域を覆ってもよい。

上述したように、複数カメラからのビデオが表示されているか否か、又は、表示のために単一カメラの小部分にズームインしているか否かにかかわらず、複数の仮想ストリームを供給することは、ビデオをモニタリング場所へストリーミングするとき、帯域幅の効率的な使用を可能にする。

図３は、ビデオソース装置及び機能と、複数解像度符号化物をストリーミングすることができる制御サーバ及び機能とを示す。システム３００は、制御サーバ３０２及びビデオソース装置３１６を備えるものとして図示される。制御サーバ３０２は、命令を処理するための中央処理装置３０４を備える。その命令はメモリ３０６に格納されてもよい。制御サーバ３０２は、データ及び命令の永続的な記憶のための不揮発性記憶装置３０８をさらに備えてもよい。制御サーバ３０２は、１つ又は複数の入力／出力（Ｉ／Ｏ）インターフェース３１０をさらに備えてもよい。Ｉ／Ｏインターフェースは、入力及び／又は出力構成要素が制御サーバに接続されることを可能にする。例えば、制御サーバ３０２を通信ネットワークに接続するために、制御サーバ３０２にネットワークインターフェースカード（ＮＩＣ）が接続されていてもよい。

ＣＰＵ３０４は、メモリに格納された命令を実行してもよい。３１２として示す命令は、実行されたとき、上述した機能を実行するように、さらに、以下に述べる機能を有するサーバ・装置ＶＳマネージャ３１４を実装するように、制御サーバ３０２を構成してもよい。

ビデオソース装置３１６は、例えばカメラ装置又はシステムであってもよく、それは、命令を処理するための中央処理装置３１８を備える。その命令はメモリ３２０に格納されてもよい。ビデオソース装置３１６は、データ及び命令の永続的な記憶のための不揮発性記憶装置３２２をさらに備えてもよい。ビデオソース装置３１６は、１つ又は複数の入力／出力（Ｉ／Ｏ）インターフェース３２４をさらに備えてもよい。Ｉ／Ｏインターフェースは、入力及び／又は出力構成要素がビデオキャプチャに接続されることを可能にする。例えば、ビデオソース装置３１６を通信ネットワークに接続するために、入力／出力インターフェース３２４にネットワークインターフェースカード（ＮＩＣ）が接続されていてもよい。さらに、ビデオソース装置３１６がカメラである場合、ＩＰであってもアナログであっても、画像データを取り込むために、Ｉ／ＯインターフェースはＣＰＵにさらにセンサを接続してもよい。

ＣＰＵ３１８は、メモリに格納された命令を実行してもよい。３２６として示す命令は、実行されたとき、装置仮想ストリーム（ＶＳ）マネージャ３２８及びエンコーダ機能３３０を提供するように、ビデオソース装置３１６を構成してもよい。

制御サーバ３０２のサーバ・装置仮想ストリーム（ＶＳ）マネージャ３１４と、ビデオソース装置３１６の装置ＶＳマネージャ３２８とは、所望又は必要に応じて、例えばカメラを含んでもよい、ビデオソース装置３１６を構成３３２するために協働する。エンコーダ機能３３０は、ビデオ及び指定された設定内容をそれぞれ符号化することができる複数の符号化構成要素を提供するために構成されてもよい。それらは、個々に符号化されたタイルの多数の行及び列を含んでもよい。符号化構成要素によって提供された符号化物は、データストリーム３３４によって示すように、制御サーバ３０２にストリーミングされることが可能である。

図面及び本明細書ではビデオソース装置３１６及びサーバ１０２を別々に参照しているが、いくつかの実施形態では、両方の説明されたシステムからの機能が単一のシステムに存在してもよいことが認識される。例えば、ビデオソース装置３１６は、カメラ及び画像収集にも関して本明細書で説明した機能と、制御サーバ１０２に関して本明細書で説明した機能とのすべてを提供するカメラシステムであってもよい。そのような実施形態において、カメラシステムは、他のカメラシステムを制御して通信する能力を備えるサーバとして動作してもよい。

図４は、ビデオソース装置機能と、複数解像度符号化物をストリーミングすることができる制御サーバ機能とをさらに示す。機能は、例えば、メモリに格納された命令によって、上述した制御サーバ３０２に提供されてもよい。制御サーバ３０２のＣＰＵによって実行されたとき、命令は、ネットワーク層プロトコル機能４０２、アプリケーション層プロトコル機能４０４、及び構成機能４０８を提供してもよい。他の機能が制御サーバ３０２に提供されてもよいことが認識される。

同様に、ビデオソース装置機能は、プロセッサにより命令を実行することにより、上述したビデオソース装置３１６のようなビデオソース装置に提供されてもよい。ビデオソース装置機能は、ネットワーク層プロトコル機能４１０、エンコーダ機能４１２、及びアプリケーション層プロトコル機能４１４を含んでもよい。ビデオソース装置は、図４に図示しない追加の機能を提供してもよい。

制御サーバ３０２及びビデオソース装置３１６のネットワーク層プロトコル機能４０２、４１０は、所望の方法でビデオソース装置３１６を構成するために協働する。ネットワーク層プロトコル機能４０２、４１０は、標準化されたネットワークインターフェースをビデオ装置に提供し、準拠した装置の発見、構成、管理、及び制御を可能にする。ネットワーク層プロトコル機能４０２、４１０は、ビデオソース装置３１６及びその能力の発見を可能にするとともに、装置３１６の構成を可能にする、制御サーバ３０２及びビデオソース装置３１６の間の共通インターフェースを提供する。さらに以下で説明されるように、ネットワーク層プロトコル機能４０２、４１０は、上述したように、特定の関心対象領域の符号化物を含む、複数の独立の解像度符号化物をストリーミングするように装置３１６をセットアップするためにエンコーダ機能４１６を構成するために使用されてもよい。いったん所望のように構成されると、ビデオソース装置３１６は、構成された解像度符号化物のデータストリームを提供するために、構成されたエンコーダ機能を用いてソースビデオを符号化してもよい。エンコーダからのデータストリームは、データストリーム４１８のリアルタイム制御及びトランスポートを提供するアプリケーション層プロトコル機能４０４、４１４を用いて、ビデオソース装置３１６から制御サーバ３０２に送信可能である。

いったんデータストリーム４１８が制御サーバ３０２において受信されると、それは、同じ解像度符号化物に属する仮想ストリームをともにグループ化するために処理されてもよい。上述したように、単一解像度符号化物は、１つ以上の独立して符号化された関心対象領域から構成されていてもよい。その後、解像度符号化物は、所望により、例えば記憶のため又はモニタリングクライアントへのストリーミングのために、さらに処理されてもよい。

制御サーバ３０２は構成機能４０８を備えてもよい。構成機能４０８は、ユーザが監視システムの構成要素の構成パラメータを設定すること、閲覧すること、及び／又は修正することを可能にしてもよい。例えば、構成機能は、ビデオソース装置のための所望のエンコーダ構成を可能にしてもよい。

図５Ａは、多重化された仮想フレームとそれらの仮想フレームを記述するために使用される記述子とを含むコンテナフレーム５０６を示す。図５Ａにおいて、単一のセッションに関連付けられた２つのフレーム、すなわち、ビデオデータを格納するコンテナフレーム５０６と、対応するオーディオデータを格納するオーディオフレーム５０７とが示される。コンテナフレーム５０６及びオーディオフレーム５０７は、ビデオ及びオーディオデータをそれぞれ保持するために使用されるデータ構造のインメモリ表現として図示される。フレーム５０６、５０７の各々は、記述子、タイムスタンプ、及びペイロードを含む。コンテナフレーム５０６のペイロードは、仮想ストリームのそれぞれのペイロードを指す間接テーブルを含む。図５Ａの例示の実施形態でオーディオフレームがビデオフレームに関連付けられているが、オーディオフレームはオプションであることが認識される。さらに、オーディオフレームは単なる例であり、例えばメタデータのような他の情報が、オーディオフレームに関して本明細書で説明した方法で仮想フレームとともに同様にストリーミングされてもよい。

図６に関して以下でさらに詳細に議論されるように、ビデオソース装置から制御サーバ３０２にコンテナ及びオーディオフレーム５０６、５０７を送信する前に、セッション記述は、まず、ＴＣＰ、ＨＴＴＰ、又はＲＴＳＰのような信頼できるトランスポート機構上で記述される。コンテナ及びオーディオフレーム５０６、５０７からの記述子は、それらのフレーム５０６、５０７から検索され、セッション記述情報５０９へシリアル化される。一実施形態では、それは、計算メモリにおいてファイルとして存在してもよい。記述情報／ファイル５０９は、コンテナ及びオーディオフレーム５０６、５０７を備えるオーディオ及びビデオの特性と、ネットワークを介してそれらのメディアファイルをストリーミングするためにトランスポートを確立することができるＵＲＩ（uniform resource identifier）とを列挙する。仮想ストリームは、パケットレベルトランスポートの多重化及び多重分離のために使用されるｖｓｔｒｅａｍ ｉｄのような追加の特性と、ソースＲＯＩ及び画像解像度のような符号化パラメータとを含む。

一実施形態において、フレーム５０６、５０７の各々は、パケット化されて、ＵＤＰのような低信頼性のトランスポート機構を介してビデオソース装置から制御サーバに送られる。代替の実施形態において、フレーム５０６、５０７を送信するために異なるトランスポート機構が使用されてもよい。

図５Ｂに示すビデオストリーム１１８の部分は、第１及び第２のコンテナフレーム５０６ａ〜ｃ（まとめて「コンテナフレーム５０６」）を含む。これらのコンテナフレームは、それらをネットワーク１１６を介して制御サーバへ送信する前にビデオソース装置によって準備される。コンテナフレーム５０６ａ〜ｃの各々は、そのコンテナフレーム５０６ａ〜ｃのすべての仮想フレーム５０８に共通のタイムスタンプ５１０ａ〜ｃをそれぞれ含む。仮想フレームヘッダの各々は、仮想フレーム５０８のそれぞれの境界を互いに定めるフレームデリミタを備え、この例示の実施形態において、フレームデリミタはｖｓｔｒｅａｍ ｉｄを含む。図５Ｂのコンテナフレーム５０６はそれぞれ、Ｈ．２６４符号化されたビデオのための１つの仮想フレーム５０８ａ、ｃ、ｅと、ＪＰＥＧ符号化されたビデオでためのもう１つの仮想フレーム５０８ｂ、ｄ、ｆとを含む。それ自体のタイムスタンプをそれぞれ有する別個のストリームを介してＨ．２６４及びＪＰＥＧビデオを制御サーバに送信することとは対照的に、図示した実施形態において、Ｈ．２６４及びＪＰＥＧビデオをコンテナフレーム５０６に配置して次にコンテナフレーム５０６を送信することは、本質的に、Ｈ．２６４及びＪＰＥＧビデオを時分割多重して制御サーバへ送る。

単一ソースフレームのタイムスタンプを仮想フレーム５０８のグループに関連付けることは、仮想フレーム５０８間の同期化を容易にし、従って、異なる仮想ストリームからのビデオがクライアント１４２上に表示されることと、待ち時間の削減とを容易にする。サーバ・装置ＶＳマネージャ３１４がストリーム１１８を受信するとき、それは、図５Ｂに示すように、各フレーム５０６のタイムスタンプ５１０に基づいてコンテナフレーム５０６のそれぞれを多重分離することができ、続いて、コンテナフレーム５０６を互いに多重分離し、コンテナフレーム５０６内の他の任意の仮想フレーム５０８から仮想フレーム５０８のそれぞれを多重分離することができる。制御サーバ３０２は、続いて、所望により、データ記憶装置１３２にコンテナフレーム５０６を格納することなどによって、コンテナフレーム５０６及び仮想フレーム５０８の任意の１つ又は複数を処理することができる。

図６は、複数解像度符号化物を提供する個々の仮想ストリームを記述するビデオソース装置３１６からの応答を示し、セッション記述情報／ファイル５０９の特定の例である。応答６００は、ビデオソース装置３１６から提供されるストリームを記述してもよい。応答６００は、ビデオストリームにおける仮想ストリームの各々を記述する。ビデオストリームは、多数の個々の仮想ストリーム６１０ａ、６１０ｂ、６１０ｃ、６１２、及び６１４を有してもよい。各仮想ストリームの符号化パラメータが提供される。例えば、各仮想ストリームは、仮想ストリームの一意の識別子６０２、仮想ストリームによって符号化されたビデオソースの領域又は関心対象領域６０４、符号化された仮想ストリームの結果の解像度６０６、及び符号化された仮想ストリーム６０８の品質の表示を含んでもよい。概略的に図示するように、複数の仮想ストリームは、同じエンコーダ設定で異なる関心対象領域を符号化してもよい。例えば、仮想ストリーム６１０ａ、６１０ｂ、６１０ｃは、同じエンコーダ設定でソースビデオの異なる関心対象領域を符号化する。さらに、複数の仮想ストリームは、同じ関心対象領域を異なるパラメータ設定で符号化してもよい。例えば、仮想ストリーム６１２及び６１４は同じ関心対象領域を符号化するが、異なる解像度をもたらす。ストリームの記述６００は様々なフォーマットで提供され、制御サーバのようなストリームを受信する構成要素が成分仮想ストリームを適切に多重分離して識別できるようにするために十分な情報を提供する。

図７は、異なる解像度におけるタイルの符号化を示す。仮想ストリームは、ビデオソースの特定の領域を特定のサイズに符号化してもよい。例えば、ソースビデオは、４９４４×３２８０の領域７０２を有してもよい。第１の仮想ストリームは、ソースビデオの左上であるｘ＝０、ｙ＝０に位置して寸法１２３２×１０８０を有する、合計領域の一部７０４を符号化してもよい。第１の仮想ストリームは、領域７０４のフル解像度符号化物を提供してもよく、それは、寸法１２３２×１０８０を有する第１の仮想ストリーム符号化７０６を結果としてもたらす。第２の仮想ストリームは同じ領域７０４を符号化してもよい。しかしながら、符号化は、ソース解像度の１／４を提供するために解像度をダウンサンプリングしてもよい。そのため、同じソースビデオ領域７０４を符号化する第２の仮想ストリーム７０８は、３０８×２７０の寸法を有する。

図８は、ビデオソース装置３１６から制御サーバ３０２にデータをストリーミングする方法８００を示す。ブロック８０２において、ビデオソース装置の符号化構成要素が構成される。構成動作は、１つ又は複数の構成コマンドを、例えば制御サーバ３０２からエンコーダ１１４を備えてもよい１つ又は複数のビデオソース装置３１６に送信することを含んでもよい。ビデオソース装置３１６の符号化構成要素は、ビデオソース装置３１６から送られたストリーム内で多数の仮想ストリームを提供するために構成される。符号化構成要素は、ソースビデオの少なくとも一部の独立の解像度符号化物を提供するために構成されてもよい。独立の解像度符号化物の少なくとも１つは、解像度符号化物のモザイクのタイルをそれぞれ備える複数の仮想ストリームによって提供される。ビデオソース装置３１６に備えられた符号化構成要素は、各仮想ストリームを提供するように構成されてもよい。

いったんストリームのための符号化構成要素が構成されると、ブロック８０４において、図５Ａ（参照番号５０９）及び図６（参照番号６００）に関して上述したようなストリームの記述は、ビデオソース装置３１６から制御サーバ３０２に伝送される。例示の実施形態において、ストリーム記述５０９は、制御サーバ３０２によって送られた記述要求に応じて、ビデオソース装置３１６によって制御サーバ３０２へ提供されてもよい。受信された記述５０９は、ビデオソース装置３１６が提供するように構成される複数の個々のストリームを記述する。所望の解像度符号化物の各々は、記述５０９に記述された１つ又は複数の仮想ストリームによって提供されてもよい。各仮想ストリームの記述５０９は、仮想ストリームの識別子、仮想ストリームの符号化情報、及び仮想ストリームによって符号化されるソースビデオの領域の表示を含んでもよい。

ブロック８０６において、データストリーム自体がビデオソース装置３１６から伝送され、制御サーバ３０２において受信される。ブロック８０８において、制御サーバ３０２は、各仮想ストリームに各解像度符号化物を関連付ける。仮想ストリームのどれが各解像度符号化に関連付けられているかを識別することは、ストリーム記述５０９における情報を用いて行われてもよい。さらに、複数の仮想ストリームがソースビデオの同じ領域を符号化する場合、仮想ストリームがどの解像度符号化物に関連付けられているかを決定するために、仮想ストリームに符号化された追加情報を利用することが必要になる可能性がある。いったん各解像度符号化物が各仮想ストリームに関連付けられると、同じ解像度符号化物の仮想ストリームがさらに処理されてもよい。例えば、ブロック８１０において、各解像度符号化物の仮想ストリームは、記憶のために提供されてもよい。仮想ストリーム及びストリーム記述５０９は、互いに関連して格納されてもよい。追加的又は代替的に、ブロック８１２において、１つの解像度符号化物の複数の仮想ストリームのうちの１つ又は複数は、１つ又は複数のモニタリングクライアントにストリーミングされてもよい。上述の説明では、個々の仮想ストリームが格納される及び／又はクライアントに送信される前に、多数の仮想ストリームが処理されることが意味されるが、仮想ストリームのそれぞれが独立して復号可能であり、直ちに格納される及び／又はクライアントに送信されてもよいことが認識される。

上述のものは、ソースビデオの異なる関心対象領域を符号化することを説明した。符号化された異なる関心対象領域は、ソースビデオ全体を符号化してもよく、又は、ソースビデオの一部のみを符号化してもよい。表示される符号化された関心対象領域間で切り換えるとき、又は、ソースビデオのモザイクを提供するために互いに隣接するか、互いの上に重ねられて、複数の関心対象領域が同時に表示されるとき、表示された符号化物の同期の間の何らかの不一致が見る人には明らかになる可能性がある。そのような同期の欠如は、望ましくないユーザ経験をもたらす。図９及び図１０を参照して以下でさらに説明するように、複数の仮想ストリーム間の同期を保持するために、複数の関心対象領域をともに符号化して多重化することが可能である。

図９は、複数の関心対象領域を符号化する処理を概略的に示す。処理９００は、多数のソースフレーム９０４ａ〜ｄ（まとめてソースフレーム９０４と呼ぶ）を備えるソースビデオのストリーム９０２を符号化する。多数のソースフレーム９０４は、ビデオソースのフレームレートに依存して変化してもよい。例えば、ビデオソースストリームは３０フレーム／秒を備えてもよい。ビデオソースストリームのフレームレートは、３０フレーム／秒より高くても低くてもよい。ソースフレームの各々は、例えば、ソースフレームが生成されたときのＵＴＣを識別するソースフレームタイムスタンプ（図示せず）を備える。

１つ又は複数のエンコーダ９０６は、ビデオソースフレーム９０４の各々を複数の符号化された仮想フレーム９０８に符号化するために構成される。図９に示すように、第１のビデオソースフレーム９０４ａは、高解像度符号化物９１０ａ、中解像度符号化物９１０ｂ、及び低解像度符号化物９１０ｃに符号化される。ビデオソースフレーム９０４ａ全体をそれぞれ符号化するように図示しているが、符号化された異なる仮想フレームの各々が、ビデオソースフレームの異なる関心対象領域を符号化してもよい。さらに、符号化された仮想フレーム９０８は、ソースビデオフレーム９０４ａとは異なる解像度において符号化されるように説明されるが、符号化された複数の仮想フレームは同じ解像度で符号化されてもよいが、符号化フォーマット、フレームレート、及びビデオ品質のような、他の符号化パラメータにおいて異なってもよいということが意図される。エンコーダ９０６は、ラウンドロビン方法で仮想フレーム９０８の各々を符号化してもよい。追加的又は代替的に、１つ又は複数のエンコーダは、複数の異なる仮想フレームを符号化するように構成されてもよい。複数のエンコーダが使用される場合、どの符号化された仮想フレームが同じビデオソースフレームの対応するのかを追跡するための機構を提供する必要があるかもしれない。これは、符号化された仮想フレームのそれぞれに共通識別子をタグ付けすることで達成されてもよい。追加的又は代替的に、各エンコーダの入力及び出力は、出力された符号化された仮想フレームがどのビデオソースフレームに対応するかを決定するために追跡されてもよい。処理９００のこの段階における仮想フレームの各々は、ソースフレームタイムスタンプから導出された仮想フレームタイムスタンプを含む仮想フレームヘッダを含む。

いったんビデオソースフレームが複数の仮想フレームへ符号化されると、同じビデオソースフレームに対応する符号化された仮想フレームの各々は、仮想ストリームマルチプレクサ９１２によってともに多重化される。仮想ストリームマルチプレクサ９１２は、複数の符号化された仮想フレーム９１０ａ、９１０ｂ、９１０ｃを単一のコンテナフレーム９１４へ多重化する。これは、ネットワークを介して、例えば制御サーバ３０２に送信されてもよい。多重化は複数の仮想フレームをともに連結することで達成される。ここで、各仮想フレームは仮想フレームの境界を定める仮想フレームヘッダを有し、コンテナフレームはコンテナフレームの境界を互いから定めるコンテナフレームヘッダを有する。ビデオストリームのみがフレームコンテナ９１４へ多重化されるように図示されるが、オーディオデータ、分析データ、及びメタデータ情報のような他のデータが含まれてもよいことが意図される。コンテナフレーム９１４はコンテナフレームヘッダを備える。それは、仮想フレームタイムスタンプから導出されたコンテナフレームタイムスタンプを含む。図５Ａ及び図５Ｂに関してさらに詳細に上で議論したように、仮想フレームヘッダの各々は、その特定の仮想フレームを識別するｖｓｔｒｅａｍ ｉｄを含む。

同じビデオソースフレームに対応する符号化されたすべての仮想フレームを共通コンテナフレームに多重化することによって、個々の仮想ストリームの完全な同期を保持することが可能である。従って、同期の不一致なしで符号化された複数の関心対象領域を同時に表示することが可能であり、これは改善されたユーザ経験を提供する可能性がある。

図１０は、ソースビデオを符号化する方法１０００を示す。ブロック１００２において、ビデオソース装置１１０は、符号化されているビデオソースストリームからソースフレームを受信する。ブロック１００４において、１つ又は複数のエンコーダは、ソースフレームの複数の仮想フレームを符号化する。各仮想フレームは、符号化されているソースフレームの領域、符号化のフレームレート、符号化の品質、符号化された仮想フレームの解像度、使用された圧縮技術／符号化フォーマット、及び他の符号化パラメータを含む異なるパラメータを用いて符号化されてもよい。ブロック１００６において、ビデオソース装置１１０及び／又はエンコーダ１１４は、複数の符号化された仮想フレームをコンテナフレームへ多重化する。コンテナフレームは、同じソースフレームから符号化された仮想フレームのすべてをともに多重化する。２つ以上の仮想ストリームが異なるフレームレートで符号化される場合、コンテナストリームの各コンテナフレームは各仮想フレームを含まなくてもよい。例えば、１つの仮想ストリームが３０仮想フレーム／秒（ｆｐｓ）で符号化される一方で、もう１つの仮想ストリームが１５仮想フレーム／秒で符号化される場合、すべてのコンテナフレームは３０ｆｐｓ符号化の仮想フレームを含む一方で、２つのうち１つのコンテナフレームのみが３０ｆｐｓ符号化及び１５ｆｐｓ符号化の両方を含む。代替として、１５ｆｐｓ符号化のフレームは、各コンテナフレームに含まれるために複製されてもよい。さらに、互いの倍数でない２つ以上の異なるフレームレートが符号化され、コンテナストリームのフレームレートは、符号化されたフレームレートのすべての最小公分母まで増大されてもよい。例えば、１つの仮想ストリームが２０ｆｐｓで符号化され、第２の仮想ストリームが３０ｆｐｓで符号化される場合、コンテナストリームのフレームレートは６０ｆｐｓであってもよい。いったん複数の仮想フレームがコンテナフレームにともに多重化されると、ブロック１００８において、コンテナフレームは、上述した制御サーバのような、所望の宛先に送信されてもよい。

サーバ及びクライアントの相互動作
図１１は、複数の符号化物をクライアント１４２へストリーミングするためのシステム１１００を示す。システム１１００は、制御サーバ１０２及びクライアント１４２を備える。制御サーバ１０２は、命令を処理するための中央処理装置１１０４を備える。その命令はメモリ１１０６に格納されてもよい。制御サーバ１０２は、データ及び命令の永続的な記憶のための不揮発性記憶装置１１０８をさらに備えてもよい。制御サーバ１０２は、１つ又は複数の入力／出力（Ｉ／Ｏ）インターフェース１１１０をさらに備えてもよい。Ｉ／Ｏインターフェースは、入力及び／又は出力構成要素が制御サーバ１０２に接続されることを可能にする。例えば、制御サーバ１０２を通信ネットワークに接続するために、制御サーバ１０２にネットワークインターフェースカード（ＮＩＣ）が接続されていてもよい。

ＣＰＵ１１０４は、メモリに格納された命令を実行してもよい。１１０７として示すその命令は、実行されたとき、サーバ・クライアントＶＳマネージャ１０６を上述した他の機能とともに提供するように制御サーバ１０２を構成してもよい。以下でさらに詳細に議論するように、サーバ・クライアントＶＳマネージャ１０６は、制御サーバ１０２が複数解像度符号化物をクライアント１４２へストリーミングすることを可能にする。

クライアント１４２は、命令を処理するための中央処理装置１１１８を備える。その命令はメモリ１１２０に格納されてもよい。クライアント１４２は、データ及び命令の永続的な記憶のための不揮発性記憶装置１１２２をさらに備えてもよい。クライアント１４２は、１つ又は複数の入力／出力（Ｉ／Ｏ）インターフェース１１２４をさらに備えてもよい。Ｉ／Ｏインターフェースは、クライアント１４２がサーバ１０２から受信するストリームが表示されることを可能にするように、入力及び／又は出力構成要素がＣＰＵ１１１８に接続されることを可能にする。図示した実施形態では、この目的のために、モニタ１１２７がＩ／Ｏインターフェース１１２４のうちの１つに接続されている。

ＣＰＵ１１１８は、メモリ１１２０に格納された命令を実行してもよい。１１２６として示す命令は、実行されたとき、クライアントＶＳマネージャ１１２８及びデコーダ機能１１３０を提供するように、クライアント１４２を構成してもよい。

制御サーバ１０２の顧客管理機能１０６及びクライアント１４２のクライアントＶＳマネージャ１１２８は、所望又は要求により、初期化データ１１３２を交換することにより、かつ、クライアント１４２が制御サーバ１０２にクライアントストリーミングパラメータ１１３３を送信することにより、制御サーバ１０２からクライアント１４２へのストリーミングを構成するために協働する。デコーダ機能１１３０は、ビデオ及び指定された設定内容をそれぞれ復号することができる複数の復号構成要素を提供するために構成されてもよい。それらは、個々に符号化されたタイルの多数の行及び列を含んでもよい。制御サーバ１０２を用いて格納されたか制御サーバ１０２を介して中継されている符号化されたストリームは、データストリーム１１３４として示すように、クライアント１４２にストリーミングすることが可能である。

ここで図１２を参照すると、複数のコンテナフレーム５０６を多重化することによりサーバ・クライアントＶＳマネージャ１０６が生成するビデオストリーム１１８であって、次に、サーバ・クライアントＶＳマネージャ１０６がクライアントＶＳマネージャ１１２８に送信するビデオストリーム１１８が示される。図５Ｂに関して上で議論したように、コンテナフレーム５０６のうちの任意の１つに構成された仮想フレーム５０８の各々は、仮想フレーム間で境界を定めるデリミタを備えた仮想フレームヘッダを含む。また、コンテナフレーム５０６は各々、そのコンテナフレームにおけるすべての仮想フレーム５０８に適用可能なタイムスタンプ５０８を含む。図１２において、サーバ・クライアントＶＳマネージャ１０６がアクセスするコンテナフレーム５０６は、データ記憶装置１３２及びビデオソース装置の一方又は両方から取得可能である。図１２に示す例示のシナリオにおいて、サーバ・クライアントＶＳマネージャ１０６は、Ｈ．２６４仮想ストリームのみがクライアント１４２に送信されるものと決定した。従って、クライアントＶＳマネージャ１１２８に送られたコンテナフレーム５０６のそれぞれは、ＪＰＥＧストリームではなく、Ｈ．２６４仮想ストリームを含む。いったんクライアントＶＳマネージャ１１２８がビデオストリーム１１８を受信すると、それは、それを多重分離し、図５Ｂに関して上述したように、サーバ・装置ＶＳマネージャによって実行されるものと同様の方法で仮想ストリームを表示又は格納する。クライアント１４２は、例えば、以下でさらに詳細に議論するように、より大きな画像を形成するか又は複数の仮想ストリームが互いに重複することを可能にするために、様々な仮想ストリームをともに合成（stitch）してもよい。

しかしながら、ビデオストリーム１１８を受信する前に、クライアント１４２は、制御サーバ１０２からのビデオストリーム１１８を要求する。クライアント１４２がビデオストリーム１１８を要求して制御サーバ１０２がクライアントに送信するために仮想ストリームを選択する方法は、図１３及び１５に関して以下に説明される。

ここで図１３を参照すると、クライアント１４２から制御サーバ１０２にクライアントストリーミングパラメータ１１３３を送信する方法１３００が示される。クライアントストリーミングパラメータ１１３３は、モニタ１１２７に表示するためにクライアント１４２に仮想ストリームのどれを送信するかを決定するときに制御サーバ１０２が考慮するパラメータである。方法１３００を実行するための命令は、プログラムコードとして符号化され、ＣＰＵ１１１８による実行のためにメモリ１１２０上に格納されてもよい。

ＣＰＵ１１１８は、ブロック１３０２において方法１３００を実行し始め、ブロック１３０４に進む。ここで、ＣＰＵ１１１８は、図１〜図１０に関して上述したように制御サーバ１０２及びビデオソース装置がセッションを確立する方法と同様の方法で、制御サーバ１０２とのセッションを確立する。セッション確立の一部として、制御サーバ１０２からクライアント１４２に送られる初期化データ１１３２は、符号化パラメータと、解像度及び画素カウントの一方又は両方と、仮想ストリーム１２６、１２８、１３０のそれぞれの位置とを記述するセッション情報を含む。以下でさらに詳細に議論するように、一例の実施形態では、クライアント１４２は、仮想ストリーム１２６、１２８、１３０のどれを表示するかをユーザが指定することを可能にするために、仮想ストリーム１２６、１２８、１３０に関するこの情報をユーザに提示してもよい。

初期化の後、ＣＰＵ１１１８は、仮想ストリーム１２６、１２８、１３０のどれを表示するかを明示的に又は暗黙的に記述するユーザ入力を受信する。このユーザ入力は次のものを含んでいてもよい。
（ａ）表示領域。
表示領域は、ユーザがビデオを見るために使用するモニタ１１２７、１５０上のウィンドウ内の画素数であり、典型的には画素数として表される。例えば、図１において、クライアント１４２は、４つの仮想ストリームからのビデオを示すためにモニタ１５０全体を使用する。従って、ストリームの各々の表示領域は、以下に説明する品質バイアスパラメータのべき乗まで２で除算したモニタ全体の合計画素数である。
（ｂ）画像領域。
画像領域／関心対象領域は、ユーザがモニタ１１２７、１５０上に表示されることを望む画像の一部を表す。画像領域は、画像領域の左上及び右下座標の座標を提供することにより指定されてもよい。例えば、ユーザは、画像の一部へズームインしようとするとき、マウス又は他のポインティングデバイスを用いて、モニタ上に表示された画像の一部の上に長方形を描画してもよい。この長方形が画像領域を表す。
（ｃ）ディスプレイ品質バイアスパラメータ。
ディスプレイ品質バイアスパラメータは、ユーザがフレームレートの低下のコストに代えても高品質を好むか否かを表す。フレームレートはフレーム／秒で測定される、品質は高い画素カウントの代理である。このパラメータは、直観的に、「高」品質、「中」品質、又は「低い」品質に設定されてもよい。ここで、「高品質」は、高い画素カウントのためにフレームレートを犠牲にするというユーザの望みを表し、「低」品質は、フレームレートを高くするが画素カウント／解像度を低くするというユーザの望みを表す。
（ｄ）色仕様パラメータ。
色仕様パラメータは、ユーザがビデオをカラーで見ることを望むか、それとも単色で見ることを望むかを表す。
（ｅ）帯域幅限界パラメータ。
帯域幅限界パラメータは、合計帯域幅使用量の上限をビット／秒で測定される所定のレートに定めることをユーザが望むか否かを表す。ユーザは、帯域幅に対するいかなるハード限界も指定しないと決定してもよい。
（ｆ）ビデオの特性及び使用。
ユーザは、見られるビデオが記憶装置から検索されるか（すなわち、データ記憶装置１３２からストリーミングされるか）、それともライブで見られるかを指定することができ、また、ビデオがパン・チルト・ズーム（ＰＴＺ）カメラのような１個のハードウェアを制御するために使用されているか否かを指定することができる。ビデオがデータ記憶装置１３２からストリーミングされる場合、待ち時間は比較的重要ではなく、比較的高い画素カウント又はフレームレートを有するビデオは、比較的長い待ち時間のコストを費やして送信される可能性がある。対照的に、ビデオがライブであるか、ハードウェアを制御するために使用されている場合、画像をリアルタイムで得るためには短い待ち時間が重要である。この場合、短い待ち時間は、高品質ビデオよりも優先される。
（ｇ）仮想ストリーム１２６、１２８、１３０のどれを表示するか。
仮想ストリームのどれが利用可能であるかをユーザが知っている実施形態では、ユーザは、上に列挙した基準を調整することにより仮想ストリームを間接的に選択することとはとは対照的に、見るための特定の仮想ストリームを手動で直接的に指定してもよい。

ユーザは、仮想ストリームのどれを表示するかを間接的に選択してもよい。例えば、ユーザは、ソースビデオの１つ又は複数のＲＯＩ及び／又は１つ又は複数の解像度を選択してもよく、各ＲＯＩ及び解像度は特定の仮想ストリームに対応してもよい。図２において、例えば、図２の破線で示す部分２１６を関心対象領域として選択することによって、ユーザは、仮想ストリームＡ_１，３及びＡ_１，４を送信のために暗黙的に選択する。もう１つの例示として、ユーザは、仮想ストリームＡ_１，３及びＡ_１，４のみを見ている状態にあり、その後、ＲＯＩがソースビデオの全体解像度になるように速くズームアウトしてもよい。これは、サーバからクライアントに高解像度の仮想ストリーム１２６が送信可能になるまで、ソースビデオ全体の低解像度の仮想ストリーム１３０を暫定的に表示することをユーザが要求しているものと暗黙的に解釈されてもよい。

ブロック１３０６においてユーザ入力を受信した後に、ＣＰＵ１１１８はクライアントストリーミングパラメータ１１３３を決定する。クライアントストリーミングパラメータ１１３３は、上に列挙したユーザ入力のタイプのすべてを含み、ＣＰＵ１１１８自体が生成するパラメータをさらに含む。ＣＰＵ１１１８自体が生成するデータは、ネットワーク輻輳を示すパケット損失の統計情報と、高フレームレート又は高い画素カウント又はそれらの両方を有するビデオを復号するために利用可能なリソースを示すＣＰＵ１１１８及びメモリ１１２０の現在の使用量の統計情報と、提案された仮想ストリームリストとを含む。ＣＰＵ１１１８は、利用可能な仮想ストリームのリストをユーザに直接的に提示しなくてもよいが、ＣＰＵ１１１８は、それが応答６００を有するので、そのリストと、仮想ストリームによって表されるタイルの場所及びサイズとへのアクセスを有する。従って、ＣＰＵ１１１８は、仮想ストリームのどれを表示するためにクライアント１４２が最も適しているかを決定することができる。

例えば、図２を再び参照すると、ユーザは、中解像度符号化物２１４を見ている状態にあり、次に、図２の破線で示す部分２１６である特定の画像領域にズームインしてもよい。ＣＰＵ１１１８は、部分２１６を仮想ストリームＡ_１，３及びＡ_１，４にマッピングする。これらは、部分２１６を中解像度符号化物２１４よりも詳細に（すなわち、より多くの画素を用いて）表示する。図２において、次に、クライアント１４２は仮想ストリームＡ_１，３及びＡ_１，４を表示する。しかしながら、もう１つの実施形態において、考慮される複数のファクタのうちのただ１つのものとして、ＣＰＵ１１１８は画像領域を考慮し、また、例えば、現在のＣＰＵ１１１８の使用量と、ビデオの性質及び使用とを考慮してもよい。比較的に高解像度の仮想ストリームＡ_１，３及びＡ_１，４のリアルタイム復号をサポートするにはＣＰＵ１１１８使用量が高すぎる場合、かつ、ビデオが短い待ち時間が重要であるライブストリームである場合、ＣＰＵ１１１８は、中解像度符号化物２１４が使用され続けることを提案してもよく、又は、短い待ち時間を可能にするためにビデオを十分に速く復号できることを保証するために、低解像度ストリーム１３０が使用されることさえ提案してもよい。上で議論したように、現在の例示は解像度に基づいて仮想ストリームを識別するが、代替の実施形態では、仮想ストリームは異なる方法で識別されてもよい。それらは、例えば、関心対象領域、フレームレート、解像度、量子化品質、ビットレート、及び符号化フォーマットのうちの任意の１つ又は複数に基づいて識別されてもよい。コンテナフレーム５０６が拡張可能なフォーマットであるとき、将来は、運動又は人の顔が検出されるような、他の卓越した特性が使用されてもよい。仮想ストリームマネージャ又はコンテナフレーム５０６の他のパーザは、未知の属性又はデータフィールドを無視するように設計可能であるので、コンテナフレーム５０６のフォーマットは、後方互換性を損なうことなく変更可能である。

ブロック１３０８においてＣＰＵ１１１８がクライアントストリーミングパラメータ１１３３を決定した後、それはブロック１３１０に進み、それらのパラメータに１１３３を制御サーバ１０２に送信する。その後、ＣＰＵ１１１８はブロック１３１２に進み、ここで方法１３００は終了し、従って、ＣＰＵ１１１８は、制御サーバ１０２がデータストリーム１１３４を送信するのを待機する。

ここで図１４を参照すると、制御サーバ１０２からクライアント１４２にビデオデータを含むデータストリームを送信する方法１４００が示される。
方法１４００を実行するための命令は、プログラムコードとして符号化され、ＣＰＵ１１０４による実行のためにメモリ１１０６上に格納されてもよい。図１４の方法１４００において、制御サーバ１０２は、３つの異なる仮想ストリーム、すなわち、高フレームレートただし低解像度（中品質）を有するように符号化された第１のストリームと、低フレームレート及び低解像度（低品質）を有するように符号化された第２のストリームと、高フレームレート及び高解像度（高品質）を有するように符号化された第３のストリームとへのアクセスを有する。例えば、高品質ストリームは毎秒３０個の画像（ｉｐｓ）で２ＭＰであってもよく、中品質ストリームは３０ｉｐｓで０．０８ＭＰであってもよく、低品質ストリームは５ｉｐｓで０．０８ＭＰであってもよい。この例は、異なる関心対象領域の高解像度ビューが必要でないときに使用されてもよい。このように、コンテナフレーム５０６の柔軟性は、代替フレームレートのビデオストリームを提供するために使用される。

ＣＰＵ１１０４はブロック１４０４において方法１４００を実行し始め、ブロック１４０６に進み、ここで、ＣＰＵ１１０４は、図６に関して説明したようにクライアント１４２が生成して送信したクライアントストリーミングパラメータ１１３３を、クライアント１４２から受信する。ＣＰＵ１１０４は、ブロック１４０８に進み、クライアントパラメータ１１３３から、クライアント１４２が要求しているビデオデータがライブビデオを含むか否かを決定する。要求されたデータがライブビデオデータを含む場合、ＣＰＵ１１０４はブロック１４１０に進み、ここで、ＣＰＵ１１０４は、ＰＴＺカメラの動きを制御することのような、待ち時間に敏感なアプリケーションにデータが使用されるか否かを、クライアントパラメータ１１３３から決定する。ＹＥＳの場合、クライアント１４２は、フレームレートが解像度よりも優先される「優先モード」にあるとみなされ、ＣＰＵ１１０４はブロック１４１６に進み、ここで、ＣＰＵ１１０４は、１つ又は複数の高フレームレートかつ低解像度の仮想ストリームをクライアント１４２へ送信する。１つ又は複数のストリームを送信した後に、ＣＰＵ１１０４はブロック１４２２に進み、ここで方法１４００は終了する。

クライアント１４２がライブビデオを要求していない場合、ＣＰＵ１１０４は、ブロック１４０８からブロック１４１０にではなくブロック１４１２に進む。ブロック１４０８において、ＣＰＵ１１０４は、データ記憶装置１３２が高フレームレートかつ高解像度のストリームを送信できないほどビジーであるか否かを決定する。データ記憶装置１３２がこれを実行できないほどビジーである場合、ＣＰＵ１１０４はブロック１４１８に進み、ここで、ＣＰＵ１１０４は、１つ又は複数の低フレームレートかつ低解像度の仮想ストリームをクライアント１４２へ送信する。ＣＰＵ１１０４が特定のストリームを選択する方法は、図１５に関して以下でさらに詳細に説明される。１つ又は複数のストリームを送信した後に、ＣＰＵ１１０４はブロック１４２２に進み、方法１４００は終了する。

クライアント１４２がライブビデオを要求しているが、優先モードにあるとはみなされない場合、又は、クライアント１４２がデータ記憶装置１３２に格納されたビデオを要求し、データ記憶装置１３２が高フレームレートかつ高解像度のストリームを送信する容量を有している場合、ＣＰＵ１１０４はブロック１４１４に進む。ここで、ＣＰＵ１１０４は、例えば、ＣＰＵ１１０４使用量を決定し、ネットワーク１４４が輻輳しているか否かを決定することにより、制御サーバ１４２及びネットワーク１４４の一方又は両方が、高フレームレートかつ高解像度のストリームを送信できないほどビジーであるか否かを決定する。制御サーバ１４２及びネットワーク１４４の一方又は両方が、高フレームレートかつ高解像度のストリームを送信できないほどビジーである場合、ＣＰＵ１１０４はブロック１４１８に進み、ここで、ＣＰＵ１１０４は、低フレームレートかつ低解像度のストリームをクライアント１４２へ送信する。さもなければ、ＣＰＵ１１０４はブロック１４２０に進み、ここで、ＣＰＵ１１０４は、高フレームレートかつ高解像度のストリームをクライアント１４２へ送信する。ＣＰＵ１１０４が特定のストリームを選択する方法は、図１５に関して以下でさらに詳細に説明される。１つ又は複数のストリームを送信した後に、ＣＰＵ１１０４はブロック１４２２に進み、方法１４００は終了する。

ここで図１５を参照すると、制御サーバ１０２からクライアント１４２に複数の仮想ストリームのうちのどれを送信するのかを決定する方法１５００が示される。方法１５００を実行するための命令は、プログラムコードとして符号化され、ＣＰＵ１１０４による実行のためにメモリ１１０６上に格納されてもよい。図１５の方法１５００へコンテキストを提供するために、方法１５００に関連して、図１の１４個の仮想ストリームが考慮される。フル解像度符号化物１２０は１２個の仮想ストリームを含み、それぞれ異なる画像領域を表し、１．３メガピクセルで符号化され、１２個の領域のすべては、まとめて関心対象領域を構成し、３０ｆｐｓで符号化される。中解像度符号化物１２２は、２メガピクセルかつ３０ｆｐｓで符号化された関心対象領域全体を表す単一の仮想ストリームを含む。低解像度符号化物１２４は、０．０７７メガピクセル（ＱＶＧＡ）かつ１５ｆｐｓで符号化された単一の仮想ストリームを含む。

ＣＰＵ１１０４はブロック１５０２において方法１５００を実行し始め、ブロック１５０４に進み、ここで、ＣＰＵ１１０４は、クライアントストリーミングパラメータ１１３３及びサーバリソース利用可能性に基づいて、許容される画素カウント及びフレームレートを決定する。サーバリソース利用可能性は、現在の例示の実施形態では、ＣＰＵ１１０４、データ記憶装置１３２、及びネットワーク１４４の利用可能性を含む。

ブロック１５０４において、本コンテキストではビデオ解像度の代理である許容される画素カウントと、フレームレートとを決定した後に、ＣＰＵ１１０４はブロック１５０６に進み、ここで、ＣＰＵ１１０４は、仮想ストリームのうちのどれが、クライアント１４２に送信するために最も適するかを決定し始める。ブロック１５０６において、ＣＰＵ１１０４は、クライアント１４２に送信するために適しているか否かを決定するために１４個の仮想ストリームのすべてを分析したか否かを決定する。ＮＯの場合、ＣＰＵ１１０４はブロック１５０７に進み、ここで、ＣＰＵ１１０４は、残りの考慮されていない仮想ストリームのうちの１つを識別する。これは、ブロック１５０８〜１５１２では「現在の仮想ストリーム」と呼ぶ。その後、ＣＰＵ１１０４はブロック１５０８に進み、ここで、ＣＰＵ１１０４は、現在の仮想ストリームが要求された画像領域を含むか否かを決定する。一例として図２を使用すると、図２に示す破線の長方形をユーザが選択したことをクライアントストリーミングパラメータ１１３３が示す場合、ＣＰＵ１１０４が「ＹＥＳ」を返す仮想ストリームは、ストリームＡ_１，３、Ａ_１，４、Ｂ１、及びＣ１のみである。選択された画像領域を表示するために、かつ、クライアントストリーミングパラメータ１１３３を満たすために、ストリームＡ_１，３及びＡ_１，４の両方をクライアント１４２に送信する必要があるので、ＣＰＵ１１０４は、ブロック１５０６〜１５１４の目的では、ストリームＡ_１，３及びＡ_１，４を単一の仮想ストリームであると考える。

その後、ＣＰＵ１１０４はブロック１５１０に進み、ここで、ＣＰＵ１１０４は、任意の以前に考慮された仮想ストリームに比較して、現在の仮想ストリームが最大の許容される画素カウントを有するか否かを決定する。上述の１４個の仮想ストリームを備えた例示では、許容される画素カウントは、１５．６メガピクセル／４^２＝０．９７５メガピクセルであり、従って、ブロック１５１０の基準を満たす仮想ストリームはストリームＣ１のみである。ブロック１５１２において、ＣＰＵ１１０４は、ストリームＣ１を「クライアントストリーム」に設定する。それは、方法１５００を実行する時点で考慮されているストリームの１つであり、ブロック１５０８及び１５１０の基準を満たし、クライアント１４２に送信されるように目印（earmark）が付けられている。次に、ＣＰＵ１１０４は、ブロック１５０６に戻る。

いったんＣＰＵ１１０４が仮想ストリームのすべてを考慮すると、ＣＰＵ１１０４は、ブロック１５０６からブロック１５１４に進み、図９に従ってクライアントストリームをクライアント１４２に送信し、その後、ＣＰＵ１１０４はブロック１５１６に進み、ここで、方法１５００は終了する。

図１５に関して説明された処理が、クライアントシステム１４２へ送信するための符号化物を決定する際に制御サーバ１０２によって実行される処理を示すということが認識される。図１５に関して説明された例示は、最大の画素アカウントを備えたストリームを識別することを参照しているが、クライアントパラメータは、符号化物をクライアントシステム１４２に送信するために他の特性を指定してもよい。例えば、クライアントパラメータは、所定範囲の特性を備えた複数の異なる符号化物を受信することを指定してもよい。例示のシナリオにおいて、クライアントパラメータは、複数の関心対象領域に関する符号化物を受信することを指定してもよい。パラメータは、記録されたフレームの第１の関心対象領域と、この記録されたフレーム内の第２の関心対象領域とを指定してもよい。ここで、第１及び第２の関心対象領域の各々は、表示領域全体の部分集合を表す。パラメータは、第１及び第２の関心対象領域の重複、非重複、又は他の任意の相対的な関係を有してもよいことを指定してもよい。例示のシナリオにおいて、パラメータは、第１の関心対象領域及び第２の関心対象領域の領域を含む表示領域全体を含む第３の関心対象領域をさらに指定してもよい。

１つの符号化物を指定するために複数のパラメータが組み合わせられてもよい。例えば、関心対象領域を指定することに加えて、パラメータは、符号化物が特定の符号化解像度を有することを指定してもよい。例示のシナリオにおいて、第１の関心対象領域に関連付けられた符号化物が、特定の値を有するか又は特定の範囲内にある符号化解像度を有するということを、パラメータは指定してもよく、また、サーバ１０２は送信のために選択してもよい。同様に、特定の値を有するか又は特定の範囲内にある符号化解像度を有する、第２の関心対象領域に関連付けられた符号化物を、パラメータは指定してもよく、また、サーバ１０２は送信のために選択してもよい。さらにまた、特定の値を有するか又は特定の範囲内にある符号化解像度を有する、第３の関心対象領域に関連付けられた符号化物を、パラメータは指定してもよく、また、サーバ１０２は送信のために選択してもよい。例示のシナリオにおいて、パラメータは、表示領域の部分のみに対応する第１及び第２に関心対象領域に関連付けられた符号化物が高解像度値を有する一方、第３の関心対象領域に対応する符号化物が、第１及び第２領域の符号化物に対してより低い解像度を有することを指定してもよい。例示のシナリオにおいて、表示領域と交差する複数の（第１及び第２の）高解像度かつ非重複の関心対象領域と、ソース領域全体を覆うもう１つの低行解像度領域（すなわち第３の領域）とを、クライアントパラメータは指定してもよく、また、サーバ１０２は処理中に識別してもよい。

処理の過程でシステム１０２がクライアントパラメータの複数の集合を使用してもよいことが認識される。例えば、サーバ１０２は、一次基準集合を満たす複数の符号化を識別するクライアントパラメータの第１の集合を使用してもよい。例示のシナリオにおいて、クライアントパラメータの第１の集合は、第１及び第２の関心対象領域によって関連付けられた符号化物であって、上述したように高解像度を有する符号化物を指定してもよい。サーバ１０２は、二次基準の異なる集合又は二次集合を指定するクライアントパラメータの追加集合又は二次集合を使用してもよい。例示のシナリオにおいて、２次クライアントパラメータは、上述したようにより低い解像度を有する、第３の関心対象領域に関連付けられた符号化物を指定してもよい。高符号化物を備えたそのような低解像度のフルソース関心対象領域は、損失への回復性を提供する可能性があり、又は、関心対象領域が速く変化する可能性があるとき、サーバがより高解像度の符号化物を送信できるようになるまで復号可能なデータを提供することにより、待ち時間を隠蔽する可能性がある。サーバ１０２が、例えば、上述したように第１、第２、及び第３の関心対象領域に関連付けられた符号化物のような、複数の符号化物を識別して送信する場合には、符号化物は、図１７に関して下記に述べるような重複又は合成された方法で表示されてもよい。例えば、２つの関心対象領域に関連付けられた２つの符号化物が識別されてクライアントシステム１４２に送信され、第１及び第２の関心対象領域を包含する第３の関心対象領域に関連付けられた第３の符号化が識別されてクライアントシステム１４２に送信されるシナリオにおいて、図１７に関して示すように、第１及び第２の符号化物は第３の符号化物の上に提示されてもよい。

サーバ・クライアント通信の概要
図１６のブロック図は、単一のビデオソース装置からのビデオのアクティブセッションに係る、ビデオ及びオーディオ経路、フィードバックモデル、及びサーバ・クライアント通信を示す。仮想ストリームの形式のビデオは、スクリーン上でユーザには見えない情報を除去するか、予約チャネル容量が与えられたとき送信可能であるように情報を除去する一連の選別ブロック１６１０を介して、フィードフォワードされる。オーディオ情報、又は、ビデオに関連付けられてビデオよりも低いデータレートを有するメタデータのような他の情報は、概して、修正なしで、ネットワークＡＰＩブロック１６１２に通過させられる。それは、プレゼンテーションブロック１６１４におけるプレゼンテーションの直前にビデオに同期される。

ユーザが現在見ている関心対象領域（ＲＯＩ）と、そのセッションの解像度とについての情報に加えて、復号についての計量値及び選別ブロックへのネットワーク容量をフィードバックする、別個のフィードバック経路が存在する。単一の仮想ストリームを複数のウィンドウ上に表示できるとき、図１６は、フィードバック経路において複数のＲＯＩを示す。

図１６は、単一のビデオ及びオーディオソースを有する単一セッションのためのフィードバック経路を示す。概して、多数のこれらのセッションが同時にアクティブになってもよい。それらが図１６の共通クロックソース（Ｔ）１６１８によって接続されるとき、それらはともに同期しているとみなされる。

選別ブロック
選別ブロック１６１０は、ＲＯＩ、幅、及び高さの組と、復号予約容量及びネットワーク予約容量のような他の計量値とのリストを取得し、また、許可（admittance）アルゴリズムを実行して、ビデオデータのどの部分を除去又は選別するかを決定する。

選別アルゴリズムが、表示されない情報、又は、ネットワークの容量又はデコーダの容量を超過する情報を除去することが望ましい。上述の計量値が与えられたとき、１つの可能な方法は以下のとおりである。

まず、われわれは、リストからの単一の目標ＲＯＩ及び解像度を考慮し、これを用いて、目標ＲＯＩを覆いながら目標解像度に等しいか少しだけ大きい最低解像度を有する仮想ストリームの集合を発見する。次に、残りのすべてのギャップを覆うＲＯＩが計算され、これを用いて、残りの仮想ストリームの集合から、ギャップＲＯＩを覆う最高解像度の仮想ストリームの集合が選択される。

この処理が繰り返され、各パスからの各ＲＯＩ、解像度ペア、及び選択された仮想ストリームが最終的なリストへ結合される。最終的なパスは、より高解像度の仮想ストリームの集合によって覆われる、リストにおけるすべての余分の仮想ストリームを除去するために使用される。

いったん解像度の選別が完了すると、その出力は、（最大復号ＦＰＳ、合計ビットレート、又はメガピクセル毎秒（ＭＰ／ｓ）のような、復号容量と相関された計量値を用いて）それがネットワーク予約ビットレート又は復号予約容量のいずれかを超過するか否かを決定するために評価される。ネットワーク及び復号容量のいずれかを超過する場合、フレーム全体を捨てることによる一時的なデシメーションを用いて、追加の選別を実行することができる。追加的又は代替的に、合計ビットレートを予約しきい値よりも低減するためにより低解像度の仮想ストリームの選択を選好するように、仮想ストリームの解像度の選別ステップにバイアスをかけることができる。

クライアント側における選別ブロック１６１０は、下流のネットワーク帯域幅の最適化が使用されていないという１つの相違点を有しているが類似している。クライアント側の選別ブロック１６１０は、クライアントにおけるより短いフィードバックループの遅延に起因して、サーバ側のブロック１６１０より高い周波数で適合する。

ネットワークＡＰＩブロック
ネットワークＡＰＩブロック１６１２は、次のサービスを提供する。
帯域幅予約、モニタリング、及びフィードバック；
プロトコル特有のパケット化；
セッション記述；
セッショントランスポート交渉及び確立；
及び
接続管理。

図１６のシステム図において、サーバ側のネットワークＡＰＩブロックは、チャネル容量に関するリアルタイムフィードバックを評価して提供し、これは、選別ブロックへの入力として使用される。

例えば、一例の実施形態において、応答６００は、ビデオストリーム及び関連付けられたオーディオストリームの記述を含む。クライアントは、単一のビデオストリーム及び単一のオーディオストリームをセットアップすることができる。いったん確立されると、現在見られている複数のＲＯＩ及び解像度、及び復号容量のような、クライアント状態に関するフィードバックを送信するために、クライアントからサーバへの呼び出しが使用される。このフィードバックは、サーバ側における選別ブロック１６１０に送られ、仮想ストリームの除去及びコンテナフレームの一時的なデシメーションを制御するために使用される。

フィードバックブロック
フィードバックブロック１６２４は、デコーダ１６２２及びプレゼンテーションブロック１６１４からフィードバックを取得し、その情報を選別ブロック１６１０に転送する。

フィードバックブロック１６２４は、選別ブロックによりさらに低解像度にバイアスをかけさせるように、ユーザが見ているウィンドウの報告された解像度を変更する、品質バイアスファクタを受理する。

例えば、「最高品質」バイアスは、選別ブロック１６１０への目標解像度フィードバックを変更しなくてもよいが、品質レベルを「高品質」に低下させることは、結果として、フィードバックブロック１６２４により２のファクタで目標解像度を除算させる。概して、品質が低下する各ステップでは、フィードバックブロックからのＲＯＩの報告された目標解像度は、２のファクタで低減される。一例の実施形態において、４つの品質バイアス設定、すなわち、最高、高、通常、及び低が存在する。

代替の実施形態において、フィードバックブロック１６２４は、選別ブロック１６１０に、解像度、ＲＯＩ、及び容量とは別に出力を送ってもよい。フィードバックブロック１６２４は、例えば、選別ブロック１６１０がどの特定の仮想ストリームを包含するか、それとも除外するかを指定してもよい。仮想ストリームのための直接的な選別コマンドを受理する制御サーバは、選別のための論理がクライアントにおいて完全にカプセル化可能であるので、新たなクライアントからの改善された方法を理解するためにアップグレードされる必要はない。このことはまた、仮想ストリームリストを考慮することのみを必要とするので、選別ブロック１６１０へのフィードバックの複雑さを低減させ、また、どの仮想ストリームを包含するか、それとも除外するかについての複雑さを、フィードバックブロックに移す。この例示の実施形態において、応答６００は、仮想ストリーム自体を受信する前に、仮想ストリームのどれを包含するか、それとも除外するかをフィードバックブロック１６２４が決定するために十分な情報を含む。

復号ブロック
復号ブロック１６２２は、符号化フォーマット特有の復号機能を提供する。それは、Ｈ．２６４、ＪＰＥＧ、及びＪＰＥＧ２０００のような、サポートされた符号化物を復号することができるデコーダコンテキストからなる。それは、セッションごとを基準とするＦＩＦＯ順序の復号化と、他のすべての既存の復号セッション間における負荷分散とを提供する。復号ブロック１６２２の出力は、未処理のビットマップであり、又は、仮想ストリームの場合には、ビットマップ及びそれらの関連付けられたＲＯＩのリストである。出力画素フォーマットは符号化に依存する。典型的なフォーマットはＹＵＶ４：２：０又は４：２：２である。

オーディオのために、同様の復号１６２２ブロックが存在する。

プレゼンテーションブロック
図１６は、単一ソース装置からの複数の仮想ストリームの合成及び表示を管理するプレゼンテーションブロック１６１４を示す。プレゼンテーションブロック１６１４は、オーディオ／ビデオ同期機能と、共通クロックソース（図１６におけるＴ）を介した他のセッションとの同期とを提供する。異なるＲＯＩ及び解像度を備える複数のウィンドウ上に単一のビデオソースを表示できるので、プレゼンテーションブロックがある形態のディスプレイ多重化をビデオソースに提供するということに注意する。図１６に示すように、ソースビデオフレームは、いったん復号され、次に、ウィンドウ特有の状態及び合成を提供する個々のプレゼンテーションブロックサブユニットのそれぞれを介して送られる。

各プレゼンテーションブロック１６１４の内部には、復号されたコンテナフレームから未処理の出力ビットマップのリストを取得することと、これらを、バックバッファの現在のＲＯＩ及び解像度を用いて、ディスプレイウィンドウのバックバッファに合成することとを担当する合成（compositor）ブロックがある。ビデオ画像をバックバッファへ合成する方法の例示の擬似コードは、以下のとおりである。

擬似コードの例
――――――――――――――――――――――――――――――――――――
sort vStreams from lowest to highest resolution
for each vStream in sorted list
{
normalized_intersection = Intersect(Normalize(vStream.roi),
Normalize(viewingRoi));
inputRoi = Transform normalized_intersection into vStream.roi;
outputRoi = Transform normalized_intersection into viewingRoi;
CopyAndScale(vStream, inputRoi, backbuffer, outputRoi);
}
――――――――――――――――――――――――――――――――――――

コピー及び拡大縮小の動作は、入力データからｉｎｐｕｔＲｏｉをコピーし、出力データにおけるｏｕｔｐｕｔＲｏｉにそれを引き伸ばして書き込む。

図１７は、適用されている合成方法の例を示す。この例では、３つのＲＯＩが使用される。第１のＲＯＩ（ＲＯＩ Ａ）は、ソース画像領域全体を覆うが、低解像度である。第２及び第３のＲＯＩ（Ｂ及びＣ）は、ソース画像領域の部分を覆うが、ソースからサンプリングされた画素数に関してより高解像度である。例示の合成方法において、最低解像度のＲＯＩであるＲＯＩ Ａが最初にコピーされる。コピーの作成は、現在見ているＲＯＩの交差を発見することと、ＲＯＩ Ａの交差した領域をコピーすることと、それを、バックバッファ全体に引き伸ばすこととを含む。例示のシナリオにおいて、より高解像度を有するＲＯＩ Ｂが次にコピーされる。見えている領域を含むＲＯＩ Ｂの交差が発見され、この交差は、バックバッファに投影され、ＲＯＩ Ｂデータがより高解像度のデータであるので、バックバッファにおける既存のＲＯＩ Ａデータの上にコピーされる。同様の処理がＲＯＩ Ｃのために実行され、ＲＯＩ Ｃは、バックバッファにおける既存のＲＯＩ Ａデータの上にコピーされる。

例示の実施形態において、最低から最高解像度のＲＯＩを合成することにより、結果として、最高解像度の画像データが最後に書き込まれている。最高から最低解像度の合成物を生成する方法では、結果として、ＲＯＩ ＡがＲＯＩ Ｃ及びＢを上書きし、それはより低品質のビデオ画像をもたらす。

このように、出願人は、異なる符号化パラメータを用いて符号化された複数の符号化物をストリーミングするためのシステム及び方法を開示した。開示した実施形態において、ビデオソースは複数の仮想ストリームを形成するように符号化され、各仮想ストリームは異なるパラメータを用いて符号化されてもよい。共通のソースビデオフレームから符号化された複数の仮想ストリームは、コンテナフレームへともに多重化され、それは記憶及び／又はプレゼンテーションのためのサーバに送信される。

上述したことは、他の構成要素でもとりわけ、ハードウェア上で実行されたソフトウェアを含む例示の方法及び装置を開示するが、そのような方法及び装置は単に例示であり、限定としてみなされるべきでないことに注意すべきである。例えば、これらのハードウェア及びソフトウェア構成要素のうちのいずれか又はすべては、ハードウェアのみで、ソフトウェアのみで、ファームウェアのみで、又はハードウェア、ソフトウェア、及び／又はファームウェアの任意の組み合わせで具体化可能であることが意図される。従って、上述したことは例示の方法及び装置を説明するが、当業者は、提供された例示がそのような方法及び装置を実現する唯一のやり方ではないことを容易に認識するであろう。例えば、方法は、プロセッサ及びマイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、及び／又は他のハードウェア構成要素を含む、１つ又は複数のコンピュータハードウェア部分で実現されてもよい。

本明細書で議論された任意の態様又は実施形態の任意の部分が、実装可能であること、又は、本明細書で議論された他の任意の態様又は実施形態の任意の部分と組み合わせ可能であることが意図される。

例えば、図８〜図１０及び図１３〜図１５に関して説明したものを含む、本明細書で説明した方法に関して、いくつかの例では、説明した方法の構成部分が、本明細書で説明したものとは異なる順序で実行されてもよいことが認識されるであろう。さらに、フローチャートに説明したブロックのすべてが実行される必要はなく、追加ブロックは追加されてもよく、図示したブロックのうちのいくつかが他のブロックと置き換えられてもよいことが認識されるであろう。

本開示は、１つ又は複数の実施形態に関して様々なシステム及び方法を説明した。しかしながら、当業者には、本開示の開示内容から外れることなく、多数の変更及び修正を実施可能であることが明らかであろう。例えば、図面及び本明細書ではカメラ１１８／ビデオソース装置３１６及び制御サーバ１０２／３０２を別々に参照している間に、いくつかの実施形態では、両方の説明されたシステムからの機能が単一のシステムに存在してもよい。例えば、ビデオソース装置３１６は、カメラ及び画像収集にも関して本明細書で説明した機能と、制御サーバ１０２に関して本明細書で説明した機能とのすべてを提供するカメラシステムであってもよい。そのような実施形態において、カメラシステムは、他のカメラシステムを制御して通信する能力を備えるサーバとして動作してもよい。

要旨は、構造上の特徴及び／又は方法論的な動作に特有の言葉で説明されているが、添付された請求項で定義された主題が上述した特有の特徴又は動作に必ずしも限定されないことが理解される。むしろ、上述した特有の特徴及び動作は、請求項を実施する例示の形態として開示される。

Claims (6)

1. 受信機、プロセッサ、及びモニタを備えたディスプレイシステムであって、
   上記受信機は、ネットワークを介して複数のコンテナフレームを受信するように適合され、
   各コンテナフレームは、複数の仮想フレームと、上記複数の仮想フレームのそれぞれに共通である１つのコンテナタイムスタンプとを含み、
   上記複数の仮想フレームは、全体として、互いに異なる少なくとも２つの符号化標準を用いてソースビデオの１つのソースフレームから符号化された少なくとも２つの仮想フレームを含む１つのデータストリームを形成し、
   上記プロセッサは、各コンテナフレーム内の上記受信された複数の仮想フレームの第１の選択された仮想フレームに第１の符号化物を関連付け、上記コンテナタイムスタンプに従って上記第１の選択された仮想フレームの第１の仮想ストリームを再構成するように適合され、
   上記モニタは、上記第１の仮想ストリームをユーザに対して表示するように適合されるディスプレイシステム。
2. 上記プロセッサはさらに、各コンテナフレーム内の上記受信された複数の仮想フレームの第２の選択された仮想フレームに第２の符号化物を関連付け、上記コンテナタイムスタンプに従って上記第２の選択された仮想フレームの第２の仮想ストリームを再構成するように適合され、
   上記モニタは、上記第１の仮想ストリーム及び上記第２の仮想ストリームの両方をユーザに対して表示するように適合される請求項１記載のディスプレイシステム。
3. ソースビデオを符号化する方法であって、上記方法は、
   計算システムが、ソースビデオの１つのソースフレームを受信することと、
   上記計算システムが、互いに異なる少なくとも２つのビデオ符号化標準を用いて上記１つのソースフレームを符号化することによって形成された複数の仮想フレームであって、全体として１つのデータストリームを形成する複数の仮想フレームを形成することと、
   上記計算システムが、上記複数の仮想フレームと、上記複数の仮想フレームのそれぞれに適用可能なコンテナタイムスタンプとを備えるコンテナフレームを、ネットワークを介して送信することとを含む方法。
4. データをストリーミングする方法であって、上記方法は、
   制御システムが、ビデオソースシステムから、ネットワークを介して、上記ビデオソースシステムが提供するように構成されている複数の仮想ストリームの記述を受信することを含み、上記複数の仮想ストリームは、互いに異なる少なくとも２つのビデオ符号化標準を用いてソースビデオの１つのソースフレームから符号化された複数の符号化物を含み、上記記述は、上記複数の符号化物にそれぞれ対応する複数の記述部分を含み、
   上記方法は、
   上記制御システムが、上記ビデオソースシステムから、上記ネットワークを介して、上記複数の仮想ストリームを含む１つのデータストリームを受信することと、
   上記制御システムが、受信された上記記述部分を用いて、上記受信された複数の仮想ストリームのそれぞれに符号化物を関連付けることとを含む方法。
5. ビデオデータを表示する方法であって、上記方法は、
   計算システムが、１つのソースビデオフレームから生成された複数の符号化物を受信することを含み、
   上記複数の符号化物のそれぞれは、互いに異なる少なくとも２つのビデオ符号化標準を用いて、上記１つのソースビデオフレームから符号化され、
   上記複数の符号化物は、上記ソースビデオフレームの第１の関心対象領域の第１の符号化物と、上記ソースビデオフレームの第２の関心対象領域の第２の符号化物とを含み、
   上記第１の関心対象領域及び上記第２の関心対象領域は不同一であり、
   上記方法は、上記計算システムが、上記第１の符号化物及び上記第２の符号化物をモニタ上に表示することを含む方法。
6. ビデオデータをストリーミングする方法であって、上記方法は、
   サーバにおいて、クライアント装置に送信される１つのソースフレームの所望の関心対象領域を指定するクライアントストリーミングパラメータを受信することと、
   上記サーバにおいて、互いに異なる少なくとも２つのビデオ符号化標準を用いて上記１つのソースフレームから符号化された上記ソースフレームの複数の符号化物であって、上記ソースフレームの符号化された異なる関心対象領域をそれぞれ表す複数の符号化物のうちのどの１つ又は複数の符号化物が、上記クライアントストリーミングパラメータを満たすかを決定することと、
   上記サーバから上記クライアント装置に、上記決定された１つ又は複数の符号化物を送信することとを含む方法。

Images