(57)【特許請求の範囲】
【請求項１】
通信ネットワークを介して、複数のビデオ信号および関連するオーディオ信号を、伝送して、1人または複数のエンドユーザに示すためのオーディオビジュアル通信システムにおいて、前記ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、前記システムは、
前記通信ネットワークを介して、前記複数のビデオ信号および任意の関連するオーディオ信号を受信し、所定の基準の組に基づいて、前記表示されるビデオ信号のためにレイアウトを決定し、前記決定されたレイアウトについての情報を伝達するように構成されている受信機と、
前記決定されたレイアウトを使用して、前記受信されたビデオ信号のうちの1つまたは複数を表示するように構成されている、前記受信機に接続されたディスプレイと、
前記通信ネットワークを介して接続され、前記決定されたレイアウトについての前記情報を受信し、前記通信ネットワークを介して、前記複数のビデオ信号および任意の関連するオーディオ信号を伝送するように構成されている、1つまたは複数のサーバと
を備え、
前記1つまたは複数のサーバは、前記複数のビデオ信号のそれぞれに対して、前記決定されたレイアウトで前記ビデオ信号を表示するのに必要な、レイヤなしか、前記ベースレイヤか、または前記ベースレイヤおよび1つまたは複数のエンハンスメントレイヤかを、選択的に伝送するように構成されており、
前記基準の組は、複数のレイアウト候補を有し、前記レイアウト候補は、前記決定されたレイアウトになり得るレイアウトを規定するデータであり、
前記受信機は、レイアウトを変更するとき、変更前のレイアウトのビューに対して変更後の新規レイアウトの前記ビューが重複する面積が最大になるように、前記複数のレイアウト候補の中から１つのレイアウト候補を選択する、手段をさらに有する、
システム。
【請求項２】
前記複数のビデオ信号および関連するオーディオ信号のうちの少なくとも1つは、事前圧縮され、前記1つまたは複数のサーバは、ローカルまたは遠隔記憶装置から、前記事前圧縮されたビデオ信号および関連するオーディオ信号にアクセスするようにさらに構成されている、請求項1に記載のシステム。
【請求項３】
前記複数のビデオ信号および関連するオーディオ信号のうちの少なくとも1つは、リアルタイムに圧縮され、前記1つまたは複数のサーバは、前記1つまたは複数のサーバに取り付けられたビデオまたはオーディオソースから、前記リアルタイムに圧縮されたビデオ信号および関連するオーディオ信号をエンコーディングするようにさらに構成されている、請求項1に記載のシステム。
【請求項４】
前記1つまたは複数のサーバのうちの少なくとも1つは、前記通信ネットワークを介して、前記1つまたは複数のサーバのうちの前記少なくとも1つに接続された伝送システムから、前記複数のビデオ信号および関連するオーディオ信号のうちの1つまたは複数を得るようにさらに構成されている、請求項1に記載のシステム。
【請求項５】
前記関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤにスケーラブルにコーディングされ、前記1つまたは複数のサーバは、前記決定されたレイアウトに必要な前記オーディオ信号レイヤのデータのみを選択的に伝送するようにさらに構成されている、請求項1に記載のシステム。
【請求項６】
前記1つまたは複数のサーバは、どの前記オーディオ信号を、前記関連するオーディオ信号のそれぞれに対して、オーディオ活動インジケータを使用することによって、選択的に伝送するかを、および前記関連するビデオ信号が、前記決定されたレイアウトで表示されるかどうかの指示を決定するようにさらに構成されており、それにより、オーディオ信号データは、最も高い活動を有する前記オーディオ信号のうちの1つまたは複数に対して伝送され、前記決定されたレイアウトで表示される前記ビデオ信号うちの1つまたは複数と関連付けられたオーディオ信号データは、伝送され、残りのビデオ信号と関連付けられたオーディオ信号データは、伝送されないようになる、請求項1に記載のシステム。
【請求項７】
前記関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、前記1つまたは複数のサーバは、最も高い活動インジケータを有する1つまたは複数のオーディオ信号に対しては、ベースレイヤおよびエンハンスメントレイヤの両方のオーディオ信号データを、ならびに前記決定されたレイアウトで表示されている前記ビデオ信号のうちの前記1つまたは複数と関連付けられた前記オーディオ信号のうちの1つまたは複数に対しては、ベースレイヤのオーディオ信号データを選択的に伝送するようにさらに構成されている、請求項6に記載のシステム。
【請求項８】
前記オーディオ活動インジケータは、前記1つまたは複数のサーバにおいて計算される、請求項6に記載のシステム。
【請求項９】
前記オーディオ活動インジケータは、事前計算され、前記ビデオ信号と関連するオーディオ信号との組合せで、前記1つまたは複数のサーバにとって利用可能である、請求項6に記載のシステム。
【請求項１０】
前記受信機は、前記決定されたレイアウトについて、ビューの数N、および0からN-1までの幅がある拡大ビューの数P、ならびに関連するオーディオ信号を有するビデオ信号それぞれの総数Mを維持し、開始のとき、またはNもしくはPにおける変化のとき、新規レイアウトを決定し、前記新規レイアウトに:
オーディオ活動をリストF内に低下させることにより、前記M個の信号をソートすること
によって、ビューを割り当てるようにさらに構成され、Fは、
NまたはPが変化した場合、まず、前記決定されたレイアウトでビューを占有していたFにおけるそれぞれのビデオ信号を、前記ビデオ信号が、前記決定されたレイアウトで割り当てられていた前記ビューとの最大重複を有する前記新規レイアウトで、前記ビューに割り当て、
次いで、Fにおけるすべてのビデオ信号が処理されるまで、または前記新規レイアウトですべてのビューがビデオ信号を割り当てられるまで、前記新規レイアウトで、次に利用可能なビュー内に順次、Fにおいて割り当てられていないままのそれぞれのビデオ信号を割り当てる、
請求項6に記載のシステム。
【請求項１１】
前記受信機は、前記決定されたレイアウトについて、ビューの数N、および0からN-1までの幅がある拡大ビューの数P、ならびに関連するオーディオ信号を有するビデオ信号それぞれの総数Mを維持し、所定の時間に、またはMにおける変化のとき、前記決定されたレイアウトに:
関連するオーディオ活動をリストF内に低下させることにより、前記M個のビデオ信号をソートすることによって、ビューを再度割り当てるようにさらに構成され、Fは、
Fにおける前記第1のP個のビデオ信号を順次割り当て、それにより、
ビデオ信号が、拡大ビューをすでに割り当てられている場合、それは、その現在の拡大ビューを維持し、
前記ビデオ信号が、標準ビューを割り当てられていた場合、それは、拡大ビューを以前に割り当てられた前記ビデオ信号の中で、最も小さい関連するオーディオ活動を有する前記ビデオ信号に割り当てられていた前記拡大ビューを割り当てられ、 前記ビデオ信号が、以前に拡大または標準ビューを割り当てられていなかった場合、それは、以前に拡大ビューを割り当てられていた前記ビデオ信号の中で、最も小さい関連するオーディオ活動を有する前記ビデオ信号は、リストG内に挿入されるようになり、Gは、
Fにおけるトップmax{N-P-|G|, 0}のビデオ信号を、前記現在のレイアウトで前記次に利用可能なフリーのビューに順次割り当て、
Gにおける前記ビデオ信号を前記現在のレイアウトで、残りの利用可能なフリービューに順次割り当てる、
請求項6に記載のシステム。
【請求項１２】
前記受信機は、可能性のあるレイアウトのテーブルにアクセスし、第1の組の基準を使用して、可能性のあるレイアウトの前記テーブルから1つまたは複数の候補レイアウトを選択し、それぞれの候補レイアウトを目標画面サイズに適合させ、第2の組の基準に基づいて前記候補レイアウトのうちのゼロまたは1つを使用するように選択することによって、前記目標画面サイズのためにレイアウトを決定するようにさらに構成されている、請求項1に記載のシステム。
【請求項１３】
前記第1の組の基準は、数Nに等しい前記レイアウトで利用可能なビューの総数を含む、請求項12に記載のシステム。
【請求項１４】
前記第1の組の基準は、数Nに等しい前記レイアウトで利用可能なビューの総数と、残りのN-P個のビューよりも大きいサイズを有する数Pに等しいビューの数とを含む、請求項12に記載のシステム。
【請求項１５】
前記第1の組の基準は、前記受信機によって受け取られたビデオ信号の数Mより少ないか、または等しいビューの総数を有するレイアウトを有することを含む、請求項12に記載のシステム。
【請求項１６】
可能性のあるレイアウトの前記テーブルは、2次元配列を形成する基本ビュー形成ブロックの単位での前記レイアウトの水平なおよび垂直な寸法と、それぞれのビューについてのスケール係数および前記2次元配列のビュー形成ブロック内に前記ビューの左上隅部の水平なおよび垂直な位置決めとを少なくとも含むパラメータの組として、それぞれのレイアウトを示し、
それぞれの候補レイアウトを前記目標画面サイズに前記適合させることは、前記レイアウトが、前記目標画面サイズを垂直なまたは水平な寸法のうちの少なくとも1つに適合させるように、および結果生じるビュー形成ブロックのアスペクト比は、最小値と最大値との所与の範囲内になるように、適切なビュー形成ブロックの幅および高さを選択することによって実行され、
前記第2の組の基準は、スコアリング関数を計算することによって、それぞれの候補レイアウトをスコアリングし、前記スコアリング関数の最高値を有する前記候補レイアウトを選択し、複数の候補レイアウトが選択される場合、フィルタリング関数を使用してスコアを計算し、したがって、単一の候補レイアウトを識別し、前記単一の候補レイアウトの最も小さいビューサイズが、指定の値より大きい場合のみ、前記単一の候補レイアウトを使用することを含む、
請求項12に記載のシステム。
【請求項１７】
N個のビューを有するレイアウトの前記スコアリング関数は、前記P個の最大ビューの最も小さいビューサイズと、残りのN-P個ビューの最も小さいサイズとの加重平均であり、ただし、Pは0であってよい、請求項16に記載のシステム。
【請求項１８】
前記フィルタリング関数は、特定のレイアウトに対してアドホックな嗜好バイアスを示し、可能性のあるレイアウトの前記テーブルにそれぞれのレイアウトのエントリで保存されている追加の加重項を含む、請求項17に記載のシステム。
【請求項１９】
前記フィルタリング関数は、レイアウトのすべてのビューの総サイズに等しい、請求項16に記載のシステム。
【請求項２０】
前記受信機は、前記決定されたレイアウトにおけるビューの前記数が、所定の制限内にある前記受信機によって受信された前記ビデオ信号の集合ビットレートを生成するように、レイアウトを決定するようにさらに構成されている、請求項1に記載のシステム。
【請求項２１】
前記受信機は、前記決定されたレイアウトにおけるビューの前記数が、所定の制限内にあるデコーディングすべき画素の集合数を生成するように、レイアウトを決定するようにさらに構成されている、請求項1に記載のシステム。
【請求項２２】
前記受信機は、受信されたビデオ信号の前記数に基づいて、自動的にレイアウトを決定するようにさらに構成されている、請求項1に記載のシステム。
【請求項２３】
前記受信機は、前記表示された複数のビデオ信号のうちの1つまたは複数が、前記決定されたレイアウトで前記割り当てられたビュー内でクロップされる場合、ユーザが、割り当てられたビュー内で、前記表示された複数のビデオ信号のうちの1つまたは複数を手動でパンすることを可能にするようにさらに構成されている、請求項1に記載のシステム。
【請求項２４】
前記受信機は、前記複数の表示されたビデオ信号のうちの1つまたは複数が、前記決定されたレイアウトで割り当てられたビュー内でクロップされる場合、前記複数の表示されたビデオ信号のうちの前記1つまたは複数における被写体の頭部の存在および場所を自動的に検出し、前記被写体の頭部が完全なビュー内にあるように、前記割り当てられたビュー内で前記1つまたは複数の表示されたビデオ信号をパンするようにさらに構成されている、請求項1に記載のシステム。
【請求項２５】
通信ネットワークを介して、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされた複数のビデオ信号と、関連するオーディオ信号とを、伝送して、1人または複数のエンドユーザに示すための方法であって、
受信機が、所定の基準の組に基づいて、前記複数のビデオ信号を表示するためにレイアウトを決定するステップと、
前記受信機が、前記決定されたレイアウトについての情報をサーバへ伝達するステップと、
前記サーバが、前記決定されたレイアウトで前記ビデオ信号を、および任意の関連するオーディオ信号を表示するのに必要な前記ビデオ信号レイヤの前記データのみを選択的に前記受信機へ伝送するステップと、
前記受信機が、前記選択的に伝送されたデータを受信するステップと、
前記受信機が、前記決定されたレイアウトを利用して前記複数のビデオ信号を表示するステップと
を含み、
前記基準の組は、複数のレイアウト候補を有し、前記レイアウト候補は、前記決定されたレイアウトになり得るレイアウトを規定するデータであり、
前記受信機が、レイアウトを変更するとき、変更前のレイアウトのビューに対して変更後の新規レイアウトの前記ビューが重複する面積が最大になるように、前記複数のレイアウト候補の中から１つのレイアウト候補を選択する、ステップをさらに含む、
方法。
【請求項２６】
前記複数のビデオ信号および関連するオーディオ信号のうちの少なくとも1つは、事前圧縮され、
ローカルまたは遠隔記憶装置から、前記事前圧縮されたビデオ信号および関連するオーディオ信号にアクセスするステップを
さらに含む、請求項25に記載の方法。
【請求項２７】
前記複数のビデオ信号および関連するオーディオ信号のうちの少なくとも1つは、リアルタイムに圧縮され、
ビデオまたはオーディオソースから、前記リアルタイムに圧縮されたビデオ信号および関連するオーディオ信号をエンコーディングするステップを
さらに含む、請求項25に記載の方法。
【請求項２８】
前記サーバが、伝送システムから、前記複数のビデオ信号および関連するオーディオ信号のうちの1つまたは複数を得るステップを
さらに含む、請求項25に記載の方法。
【請求項２９】
前記関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、
前記サーバが、前記決定されたレイアウトに必要な前記関連するオーディオ信号レイヤの前記データのみを選択的に伝送するステップを
さらに含む、請求項25に記載の方法。
【請求項３０】
どの前記オーディオ信号を、前記関連するオーディオ信号のそれぞれに対して、オーディオ活動インジケータを使用することによって、選択的に伝送するかを、および前記関連するビデオ信号が、前記決定されたレイアウトで表示されるかどうかの指示を前記受信機が決定するステップであって、それにより、オーディオ信号データは、前記最も高い活動を有する前記オーディオ信号のうちの1つまたは複数に対して伝送され、前記決定されたレイアウトで表示される前記ビデオ信号のうちの1つまたは複数と関連付けられたオーディオ信号データは、伝送され、残りのビデオ信号と関連付けられたオーディオ信号データは、伝送されないようになる、ステップ
をさらに含む、請求項25に記載の方法。
【請求項３１】
前記関連付けられたオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、
前記最も高い活動インジケータを有する1つまたは複数のオーディオ信号に対しては、ベースおよびエンハンスメントレイヤ両方のオーディオ信号データを、ならびに前記決定されたレイアウトで表示される前記ビデオ信号のうちの前記1つまたは複数と関連付けられた前記オーディオ信号のうちの1つまたは複数に対しては、ベースレイヤオーディオ信号データを選択的に前記サーバが伝送するステップを
さらに含む、請求項30に記載の方法。
【請求項３２】
前記決定されたレイアウトについて、ビューの数N、および0からN-1までの幅がある拡大ビューの数P、ならびに関連するオーディオ信号を有するビデオ信号それぞれの総数Mを維持するステップと、開始のとき、またはNもしくはPにおける変化のとき、新規レイアウトを決定し、前記新規レイアウトに:
オーディオ活動をリストF内に低下させることにより、前記M個の信号をソートすること
によって、前記受信機が、ビューを割り当てるステップとをさらに含み、Fは、
NまたはPが変化した場合、まず、前記決定されたレイアウトでビューを占有していたFにおけるそれぞれのビデオ信号を、前記ビデオ信号が、前記決定されたレイアウトで割り当てられていた前記ビューと最大重複を有する前記新規レイアウトで、前記ビューに割り当て、
次いで、Fにおけるすべてのビデオ信号が処理されるまで、または前記新規レイアウトですべてのビューがビデオ信号を割り当てられるまで、前記新規レイアウトで、次の利用可能なビュー内に順次、Fにおいて割り当てられていないままのそれぞれのビデオ信号を割り当てる、
請求項30に記載の方法。
【請求項３３】
前記決定されたレイアウトについて、ビューの数N、および0からN-1までの幅がある拡大ビューの数P、ならびに関連するオーディオ信号を有するビデオ信号それぞれの総数Mを維持するステップと、所定の時間に、またはMにおける変化のとき、新規レイアウトに:
関連するオーディオ活動をリストF内に低下させることにより、前記M個のビデオ信号をソートすることによって、前記受信機が、ビューを再度割り当てるステップとをさらに含み、Fは、
Fにおける前記第1のP個のビデオ信号を順次割り当て、それにより、
ビデオ信号が、前記決定されたレイアウトで拡大ビューを割り当てられる場合、それは、前記新規レイアウトで、その現在の拡大ビューを維持し、
前記ビデオ信号が、前記決定されたレイアウトで標準ビューを割り当てられていた場合、それは、前記決定されたレイアウトで、拡大ビューを割り当てられていた前記ビデオ信号の中で、最も小さい関連するオーディオ活動を有する前記ビデオ信号に割り当てられていた前記新規レイアウトで、前記拡大ビューを割り当てられ、 前記ビデオ信号が、前記決定されたレイアウトで、以前に拡大または標準ビューを割り当てられていなかった場合、それは、前記決定されたレイアウトで、以前に拡大ビューを割り当てられていた前記ビデオ信号の中で、最も小さい関連するオーディオ活動を有する前記ビデオ信号に割り当てられていた新規レイアウトで、拡大ビューを割り当てる一方、前記決定されたレイアウトで、以前に拡大ビューを割り当てられていた前記ビデオ信号の中で、最も小さい関連するオーディオ活動を有する前記ビデオ信号は、リストG内に挿入されるようになり、Gは、
Fにおけるトップmax{N-P-|G|, 0}のビデオ信号を、前記新規レイアウトで前記次に利用可能なフリーのビューに順次割り当て、
Gにおける前記ビデオ信号を前記新規レイアウトで、残りの利用可能なフリービューに順次割り当てる、
請求項30に記載の方法。
【請求項３４】
可能性のあるレイアウトのテーブルにアクセスし、第1の組の基準を使用して、可能性のあるレイアウトの前記テーブルから1つまたは複数の候補レイアウトを選択し、目標画面サイズにそれぞれの候補レイアウトを適合させ、第2の組の基準に基づいて、前記候補レイアウトのうちのゼロまたは1つを使用するように選択することによって、前記目標画面サイズに対してレイアウトを前記受信機が、決定するステップ
をさらに含む、請求項25に記載の方法。
【請求項３５】
前記第1の組の基準は、数Nに等しい前記レイアウトで利用可能なビューの総数を含む、請求項34に記載の方法。
【請求項３６】
前記第1の組の基準は、数Nに等しい前記レイアウトで利用可能なビューの総数と、残りのN-P個のビューよりも大きいサイズを有する数Pに等しいビューの数とを含む、請求項34に記載の方法。
【請求項３７】
前記第1の組の基準は、前記受信機によって受け取られたビデオ信号の数Mより少ないか、または等しいビューの総数を有するレイアウトを有するステップを含む、請求項34に記載の方法。
【請求項３８】
2次元配列を形成する基本ビュー形成ブロックの単位で、前記レイアウトの水平および垂直な寸法と、それぞれのビューについてのスケール係数および前記2次元配列のビュー形成ブロック内に前記ビューの左上隅部の水平および垂直な位置決めとを少なくとも含むパラメータの組として、可能性のあるレイアウトの前記テーブルにそれぞれのレイアウトを示すステップをさらに含み、
それぞれの候補レイアウトを前記目標画面サイズに適合させるステップは、
前記レイアウトが、前記目標画面サイズを垂直または水平な寸法のうちの少なくとも1つに適合させるように、および結果生じるビュー形成ブロックのアスペクト比が、最小値と最大値との所与の範囲内になるように、適切なビュー形成ブロック幅および高さを選択するステップを含み、
前記第2の組の基準は、スコアリング関数を計算することによって、それぞれの候補レイアウトをスコアリングし、前記スコアリング関数の最高値を有する前記候補レイアウトを選択し、複数の候補レイアウトが選択される場合、フィルタリング関数を使用してスコアを計算し、したがって、単一の候補レイアウトを識別し、前記単一の候補レイアウトの最も小さいビューサイズが、指定の値より大きい場合のみ、前記単一の候補レイアウトを使用することを含む、
請求項34に記載の方法。
【請求項３９】
N個のビューを有するレイアウトの前記スコアリング関数は、前記P個の最大ビューの最も小さいビューサイズと、残りのN-Pのビューの最も小さいサイズとの加重平均であり、ただし、Pは0であってよい、請求項38に記載の方法。
【請求項４０】
前記フィルタリング関数は、特定のレイアウトに対してアドホックな嗜好バイアスを示し、可能性のあるレイアウトの前記テーブルにそれぞれのレイアウトのエントリで保存されている追加の加重項を含む、請求項39に記載の方法。
【請求項４１】
前記フィルタリング関数は、レイアウトのすべてのビューの総サイズに等しい、請求項38に記載の方法。
【請求項４２】
前記決定されたレイアウトにおけるビューの前記数は、所定の制限内にある前記受信されたビデオ信号の集合ビットレートを生成するように、レイアウトを決定するステップをさらに含む、請求項25に記載の方法。
【請求項４３】
前記決定されたレイアウトにおけるビューの前記数は、所定の制限内であるデコーディングすべき画素の集合数を生成するように、レイアウトを決定するステップをさらに含む、請求項25に記載の方法。
【請求項４４】
前記受信機が、受信された信号の前記数に基づいて、自動的にレイアウトを決定するステップをさらに含む、請求項25に記載の方法。
【請求項４５】
前記複数の表示されたビデオ信号のうちの1つまたは複数が、前記決定されたレイアウトで前記割り当てられたビュー内でクロップされる場合、ユーザが、割り当てられたビュー内で、前記複数の表示されたビデオ信号のうちの1つまたは複数を手動でパンすることを前記受信機が可能にするステップ
をさらに含む、請求項25に記載の方法。
【請求項４６】
前記複数のビデオ信号のうちの1つまたは複数は、前記決定されたレイアウトで割り当てられたビュー内でクロップされる場合、前記複数の表示されたビデオ信号のうちの前記1つまたは複数内の被写体の頭部の存在および場所を自動的に前記受信機が検出するステップと、
前記被写体の頭部が完全なビュー内にあるように、前記割り当てられたビュー内で、前記1つまたは複数の表示されたビデオ信号を前記受信機がパンするステップと
をさらに含む、請求項25に記載の方法。
【請求項４７】
1つまたは複数のサーバから通信ネットワークを介して、受信された複数のビデオ信号および関連するオーディオ信号を、示すためのシステムであって、前記ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、
受信機が、前記通信ネットワークを介して前記複数のビデオ信号および任意の関連するオーディオ信号を受信し、
前記受信機が、所定の基準の組に基づいて、前記受信されたビデオ信号のうちの1つまたは複数を表示するためにレイアウトを決定し、
前記受信機が、フィードバックとして、前記通信ネットワークを介して、前記決定されたレイアウトをサーバへ伝達する
ように構成されている受信機と、
前記受信機に接続され、前記決定されたレイアウトを使用して、前記受信されたビデオ信号のうちの1つまたは複数を表示するように構成されているディスプレイと
を備え、
前記フィードバックは、前記決定されたレイアウトで前記ビデオ信号レイヤを、選択的に前記受信機へ伝送するための命令を含み、
前記基準の組は、複数のレイアウト候補を有し、前記レイアウト候補は、前記決定されたレイアウトになり得るレイアウトを規定するデータであり、
前記受信機は、レイアウトを変更するとき、変更前のレイアウトのビューに対して変更後の新規レイアウトの前記ビューが重複する面積が最大になるように、前記複数のレイアウト候補の中から１つのレイアウト候補を選択する、手段をさらに有する、  システム。
【請求項４８】
前記関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、前記フィードバックは、前記決定されたレイアウトでオーディオ信号レイヤを前記選択的に伝送するための命令をさらに含む、請求項47に記載のシステム。
【請求項４９】
前記受信機は、可能性のあるレイアウトのテーブルにアクセスし、第1の組の基準を使用して、可能性のあるレイアウトの前記テーブルから1つまたは複数の候補レイアウトを選択し、目標画面サイズにそれぞれの候補レイアウトを適合させ、第2の組の基準に基づいて、前記候補レイアウトのうちのゼロまたは1つを使用するように選択することによって、前記目標画面サイズに対してレイアウトを決定するようにさらに構成されている、請求項47に記載のシステム。
【請求項５０】
複数のビデオ信号および1つまたは複数の関連するオーディオ信号を伝送するためのシステムであって、前記ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、
決定されたレイアウトに対応する前記ビデオ信号レイヤを選択的に伝送するための命令を受信し、
前記決定されたレイアウトで、前記ビデオ信号を表示するのに必要な前記ビデオ信号レイヤのデータのみを選択的に伝送する
ように構成されている1つまたは複数のサーバと、
前記複数のビデオ信号および任意の関連するオーディオ信号を受信し、所定の基準の組に基づいて、表示されるビデオ信号のためにレイアウトを決定し、前記決定されたレイアウトについての情報を前記サーバへ伝達するように構成されている受信機と、
を備え、
前記基準の組は、複数のレイアウト候補を有し、前記レイアウト候補は、前記決定されたレイアウトになり得るレイアウトを規定するデータであり、
前記受信機は、レイアウトを変更するとき、変更前のレイアウトのビューに対して変更後の新規レイアウトの前記ビューが重複する面積が最大になるように、前記複数のレイアウト候補の中から１つのレイアウト候補を選択する、手段をさらに有する、
システム。
【請求項５１】
前記1つまたは複数の関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、前記命令は、前記決定されるレイアウトで、オーディオ信号レイヤを選択的に伝送するための命令をさらに含む、請求項50に記載のシステム。
【請求項５２】
前記1つまたは複数の関連するオーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、前記1つまたは複数のサーバは、
最も高い活動インジケータを有する1つまたは複数のオーディオ信号に対しては、ベースおよびエンハンスメントレイヤのオーディオ信号データの両方を、および前記決定されたレイアウトで含まれる前記ビデオ信号のうちの前記1つまたは複数と関連付けられた前記オーディオ信号に対しては、ベースレイヤのオーディオ信号データを選択的に伝送する
ようにさらに構成されている、請求項50に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、「System and Method for Improved View Layout Management in Scalable Video and Audio Communication Systems」と題された2008年6月9日に出願の米国特許仮出願第61/060,072号からの優先権を主張するものである。
【０００２】
本願は、本発明の譲受人に譲渡された「System and Method for Scalable and Low-Delay Videoconferencing Using Scalable Video Coding」と題された国際特許出願第PCT/US06/028365号、および「System and Method for Videoconferencing Using Scalable Video Coding and Compositing Scalable Video Conferencing Servers」と題された国際特許出願第PCT/US06/62569号に関連し、それらの全体が参照により本明細書に組み込まれる。
【０００３】
本願は、ビデオ通信システムに関するものである。詳細には、1つまたは複数のディスプレイ上で、種々のスケーラブルビデオソースの多重ビューのレイアウトを管理するための機構に関するものである。
【背景技術】
【０００４】
多重ビデオビューが、1つまたは複数のビデオディスプレイ上に提示可能ないくつかのアプリケーションがある。一例が、多地点ビデオ会議のシステムであり、1つまたは複数のビデオストリームが受信機に到達し、共通のディスプレイ上に提示される必要がある。ハイエンドのビデオ会議のシステムは実際、2つ以上のディスプレイをその目的で使用することが可能である。参加者の数が増大するにつれて、所与のディスプレイエリア上にすべてのビデオウィンドウを適合させることは不可能になる。同時に、ディスプレイがコンピュータのディスプレイである場合、それは他のアプリケーションによって共有可能であり、したがって、ユーザは、ビデオ会議のアプリケーションウィンドウをコンピュータの画面のサブセットに制限することが可能である。別の例は、ビデオ監視アプリケーションであり、多重カメラからのフィードが制御ステーションに到達することが可能であり、そのフィードは再度、1つまたは複数の物理的なディスプレイ装置(コンピュータまたはTVモニタ)内に表示される必要がある。さらなる別のアプリケーションは、単一の装置が同時に多重プログラムを表示するマルチプログラムテレビである。さらには、ビデオプログラムがインターネット上でますます利用可能になることにより、アナログTVまたはデジタルTVの従来のピクチャインピクチャモードに類似しているが、より大きい組のビューを有する機能をもたらすプレーヤを創出し易い。
【０００５】
所与の画面上の多重ビューの編成は一般に、長方形格子編成パターンに続いて行われる。例えば、同じサイズの4つのフィードで、画面エリアを長方形配列の2×2のより小さいビューまたはウィンドウに分割し、それぞれのフィードをそれ自体のウィンドウ内に表示することが可能である。一般に、より小さいビューは、オリジナルフィードのスケールされたバージョンを含み、それにより、割り当てられた画面エリア内に適合するようになる。ビデオ会議などの会話型アプリケーションにおいてもまた、例えば画面の隅部のうちの1つを占有する、より大きいビュー内にアクティブな話者を表示することが一般的であり、他の参加者は、メインのビューをその両側で取り囲んだ、より小さいビュー内に示される。
【０００６】
トランスコーディング多地点制御ユニット(MCU)を使用する従来型ビデオ会議システムにおいては、個々のフィードの合成は、MCU自体で起こる。MCUは、伝送する参加者からの入ってくるフィードを受信し、それらをデコーディングし、それらを適切にダウンスケーリングした後で、新規フレームに合成する。MCUは次いで、その合成された信号をエンコーディングし、それを意図する受信者(複数可)に伝送する。MCUが個人用のレイアウトを支持する場合、合成およびエンコーディングは、それぞれの受信者に対して個別に実行される。所与の参加者は、所望のレイアウトを選択し、それが所望の合成をもたらす順序でMCUに伝達する。合成オプションは、MCUにおいて事前構成され、利用可能なパターンへのいずれの変更にも、その再設計または再プログラミングが必要である。
【０００７】
種々の場所から生じる可能性もある多重ビデオソースを受信し、表示するビデオプレーヤの一般的な設定においては、個々のビデオピクチャをスケールダウンし、表示されるピクチャに合成することがプレーヤの任務である。これは、それが選択する任意のやり方でレイアウトを編成するプレーヤに完全な柔軟性をもたらすが、それはまた、個々のソースのビットレートの合計である総ビットレート要件も、もたらす。対照的に、トランスコーディングMCUによるビデオ会議設定においては、受信された合成信号のビットレートは、単一のビデオソースのビットレートである。しかし、ビデオストリームをデコーディングし、再エンコーディングするためのMCUの要求は、相当な待ち時間を加え、また、十分な計算能力も必要とすることが分かる。
【０００８】
多重ビデオビューを特徴付けるシステムにおける柔軟性、複雑性、およびビットレートオーバヘッドの間のトレードオフを解決する本質的な限界が、このようなシステムは一般に、H.264 AVC、VC-1、MPEG-4、MPEG-2、およびVP6/VP7など、従来の単一レイヤビデオコーデックを使用して動作するという事実である。代替のコーディング技術は、レイヤードまたはスケーラブルコーディングである。スケーラブルコーディングは、対応するいくつかの忠実度ポイントにおいて、帯域幅有効な形で所与の媒体をまとめて示す2つ以上の「スケールされた」ビットストリームを生成するために使用される。スケーラビリティは、いくつかの異なる寸法をもたらすことが可能である。例えば、ビデオ信号は、CIFおよびQCIF解像度において、ならびに1秒当たり7.5フレーム、15フレーム、および30フレーム(fps)のフレームレートにおいて、異なるレイヤにスケーラブルにコーディング可能である。コーデックの構造に応じて、空間解像度とフレームレートとの任意の組合せが、コーディングされたビットストリームから得られることが可能である。種々のレイヤに対応するビットは、別個のビットストリーム(すなわち、1レイヤ当たり1つのストリーム)として伝送されても、あるいは1つまたは複数のビットストリームで一緒に多重化されてもよい。本明細書においては説明の便宜上、様々なレイヤが、単一のビットストリームで多重化され、伝送される場合であっても、所与のレイヤに対応するコーディングされたビットをそのレイヤのビットストリームと呼ぶことが可能である。
【０００９】
特にスケーラビリティ機能を提案するように設計されているビデオコーデックは、例えば、MPEG-2(ISO/IEC13818-2、またITU-T H.262としても知られている)、および現在、開発されているH.264 Scalable Video Coding(H.264 SVC)拡張(その全体を参照によって本明細書に組み込まれるAnnex G of ITU-T Recommendation H.264、2007年11月)を含む。スケーラブルオーディオコーデックは、ITU-T G.729.1およびSpeex(www.speex.orgを参照のこと)を含む。
【００１０】
特にビデオ通信向けに設計されているスケーラブルビデオコーディング(SVC)技術もまた、本発明の譲受人に譲渡された国際特許出願第PCT/US06/028365号、「System and Method for Scalable and Low-Delay Videoconferencing Using Scalable Video Coding」に記載されている。特にスケーラブルであるように設計されていないコーデックでさえも、時間的範囲でスケーラビリティ特性(例えば、MPEG-2またはH/264 AVC)を示すことが可能であることが分かる。
【００１１】
スケーラブルコーデックは一般に、ピラミッド状のビットストリーム構造を有する。一例としてH.264 SVCを使用して、第1の忠実度ポイントが、標準H.264技術(Advanced Video Coding-AVC)を使用してソースをエンコーディングすることによって得られる。追加の忠実度ポイントは、結果生じるコーディングエラー(第1の忠実度ポイントのオリジナル信号と、デコーディングされたバージョンとの間の差)をエンコーディングすることによって、およびそれ自体のビットストリームでそれを伝送することによって得ることが可能である。このピラミッド構成は、非常に一般的である(例えば、それは、MPGE-2およびMPEG-4において使用された)。第1の(最下位の)忠実度レベルのビットストリームは、ベースレイヤと呼び、追加の忠実度ポイントをもたらすビットストリームは、エンハンスメントレイヤと呼ぶ。忠実度エンハンスメントは、任意の忠実度範囲にあることが可能である。例えば、ビデオの場合、それは時間(フレームレート)、品質(信号対雑音比またはSNR)、空間(ピクチャサイズ)、または3-D(例えば、立体エンハンスメントレイヤを有する)であることが可能である。オーディオの場合、それは、時間(1秒当たりのサンプル)、品質(SNR)、または追加のチャンネルであることが可能である。
【００１２】
スケーラブルまたはレイヤード表現の別の例は、多重記述コーディングである。この場合、その構成は、ピラミッド状ではなく、それぞれのレイヤは独立して、デコーディング可能であり、基本的な忠実度で表現を生成し、しかし、複数のレイヤがデコーダに対して利用可能である場合、より高いレベルの忠実度においてオリジナル信号のデコーディングされた表現を生成することが可能である。1つの例が、ビデオ信号の奇数および偶数のピクチャを2つの別個のビットストリームとして伝送することである。それぞれのビットストリームは個別に、第1のレベルの忠実度を提案するが、他のビットストリームから受け取られる任意の情報が、この第1のレベルの忠実度を強化するために使用可能である。この意味において、ストリームのいずれかがベースレイヤとして働くことが可能である。ストリームのいずれもが、ベースレイヤとして作用することが可能である。すべてのストリームが受け取られた場合、特定の表現によって与えられる最大レベルの品質で、オリジナル信号の完全な表現が得られる。
【００１３】
レイヤード表現のさらなる別の例は、同時放送である。この場合では、オリジナル信号の2つ以上の独立した表現がエンコーディングされ、それら自体のストリーム内に伝送される。例えば、これはしばしば、標準解像度TVの情報および高解像度TVの情報を伝送するために使用される。同時放送は、ピラミッド状のスケーラブルコーディングの特別な場合であり、レイヤ間予測が使用されないことが分かる。以下においては、特に明白に別段の定めのない限り、すべてのこのようなレイヤードコーディング技術をスケーラブルコーディングと呼ぶ。
【００１４】
スケーラブルコーディングは、遅延の減少、複雑さの減少、およびシステムスケーラビリティの改良を含むパケットベースのビデオオーディオ通信に有意な利点を提案する。
【００１５】
国際特許出願第PCT/US06/028365号は、Scalable Video Communication Server(「SVCS」)(またはスケーラブルオーディオ信号の場合には、Scalable Audio Communication Server(「SACS」)が、オーディオ信号のスケーラブルなアスペクトを使用して、アクティブな話者にはフル解像度信号を、(例えば、計算された容量によって優先される)何人かの他の参加者にはベースレイヤのみを伝送することによって、話者同士の間の円滑なトランジションを確実にすることが可能な技術を開示している。
【００１６】
例えば、標準的なPCベースのハードウェアプラットフォーム上でホスティングされたSVCSユニットは、100人のユーザ、またはそれを超えるユーザをサポートすることが可能である。多数のユーザを有するセッションを効果的にホスティングする性能は、例えば、10〜15人を超えるユーザがいると、単一のディスプレイ上にすべてのユーザを効果的に組み合わせることが困難になるビューレイアウト管理についての課題をもたらす。本開示の対象は、このようなシステムにおいてビューレイアウトを効果的に管理するためのシステムおよび方法を示す。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】米国特許仮出願第61/060,072号
【特許文献２】国際特許出願第PCT/US06/028365号
【特許文献３】国際特許出願第PCT/US06/62569号
【非特許文献】
【００１８】
【非特許文献１】Annex G of ITU-T Recommendation H.264、2007年11月 SUMMARY
【非特許文献２】D.P. Petersen and D. Midleton、「Sampling and Reconstruction of Wave-number Limited Functions in n-dimensional Euclidean Spaces」Inf. Control、5:279-323、1962年
【非特許文献３】EleftheriadisおよびA.Jacquin、「Automatic Face Location Detection and Tracking for Model-Assisted Coding of Video Teleconferencing Sequences at Low Bit Rates」、Signal Processing:Image Communication、第7巻、3号、1995年9月、231〜248頁
【発明の概要】
【課題を解決するための手段】
【００１９】
本開示の対象は、スケーラブルコーディングを使用し、多重ビデオビューのレイアウトを管理するための技術を提供し、それにより、完全な柔軟性が、画面のサイズ、アスペクト比、およびビューの数に関してエンドユーザにもたらされ、ビットレート要件を含むと同時に、抑える。本開示の対象はまた、ユーザの嗜好と、サーバによって提供可能な、または受信機においてローカルに計算可能な補助データとの組合せを使用して、多重ビデオビューのレイアウトを自動化するための技術を提供する。
【００２０】
本開示の対象の実施形態は、通信ネットワークを介して、複数のビデオ信号および関連するオーディオ信号を、いずれかある場合に、伝送して、1人または複数のエンドユーザに示すためのオーディオビジュアル通信システムを含み、ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされる。受信機が、複数のビデオ信号および任意の関連するオーディオ信号を受信し、基準の組に基づいて、表示されるビデオ信号のためにレイアウトを決定し、決定されたレイアウトについての情報を伝達する。ディスプレイが、決定されたレイアウトを使用して、受信されたビデオ信号のうちの1つまたは複数を表示する。1つまたは複数のサーバは、決定されたレイアウトについての情報を受信し、通信ネットワークを介して、複数のビデオ信号および任意の関連するオーディオ信号を伝送する。1つまたは複数のサーバは、複数のビデオ信号のそれぞれに対して、決定されたレイアウトでビデオ信号を表示するのに必要な、レイヤなしか、ベースレイヤか、またはベースレイヤおよび1つまたは複数のエンハンスメントレイヤかを、いずれかある場合に、選択的に伝送するように構成されている。
【００２１】
本開示の対象のいくつかの実施形態においては、オーディオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされ、1つまたは複数のサーバは、決定されたレイアウトに必要なオーディオ信号レイヤのデータのみを選択的に伝送する。
【００２２】
本開示の対象のいくつかの実施形態においては、1つまたは複数のサーバは、どのオーディオ信号を、関連するオーディオ信号のそれぞれに対して、オーディオ活動インジケータを使用することによって、選択的に伝送するかを、および関連するビデオ信号が、決定されたレイアウトで表示されるかどうかの指示を決定し、それにより、オーディオ信号データは、最も高い活動を有するオーディオ信号のうちの1つまたは複数のオーディオ信号に対して伝送され、決定されたレイアウトで表示されるビデオ信号のうちの1つまたは複数と関連付けられたオーディオ信号データは、伝送され、残りのビデオ信号と関連付けられたオーディオ信号データは、伝送されないようになる。
【００２３】
本開示の対象の実施形態は、通信ネットワークを介して、ベースレイヤと、1つまたは複数のエンハンスメントレイヤとを含むレイヤ内にスケーラブルにコーディングされた複数のビデオ信号および関連するオーディオ信号を、いずれかある場合に、伝送して、1人または複数のエンドユーザに示すための方法を含み、基準の組に基づいて、複数のビデオ信号を表示するためにレイアウトを決定するステップと、決定されたレイアウトについての情報を伝達するステップと、決定されたレイアウトでビデオ信号を、および任意の関連するオーディオ信号を表示するのに必要なビデオ信号レイヤのデータのみを選択的に伝送するステップと、選択的に伝送されたデータを受信するステップと、決定されたレイアウトを使用して複数のビデオ信号を表示するステップとを含む。
【００２４】
本開示の対象の実施形態はまた、1つまたは複数のサーバから通信ネットワークを介して、受信された複数のビデオ信号および関連するオーディオ信号を、いずれかある場合に、示すためのシステムを含み、ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされる。受信機が、通信ネットワークから複数のビデオ信号および任意の関連するオーディオ信号を受信し、基準の組に基づいて、受信されたビデオ信号うちの1つまたは複数を表示するためにレイアウトを決定し、決定されたレイアウトでビデオ信号レイヤを、いずれかある場合に、選択的に伝送するための命令を含むフィードバックとして、通信ネットワークを介して、決定されたレイアウトを伝達する。受信機に接続されているディスプレイが、決定されたレイアウトを使用して、受信されたビデオ信号のうちの1つまたは複数を表示する。
【００２５】
本開示の対象の実施形態はまた、複数のビデオ信号および1つまたは複数の関連するオーディオ信号を伝送するためのシステムを含み、ビデオ信号は、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含むレイヤ内にスケーラブルにコーディングされる。1つまたは複数のサーバは、決定されたレイアウトに対応するビデオ信号レイヤを選択的に伝送するための命令を受信し、決定されたレイアウトでビデオ信号を表示するのに必要なビデオ信号レイヤのデータのみを選択的に伝送する。
【図面の簡単な説明】
【００２６】
【図１】本開示の対象の原理により、1つまたは複数のサーバから受信機に、多重スケーラブルビデオストリームおよびオーディオストリームを配信する例示的なオーディオビデオ通信システムの概括的なアーキテクチャを示すブロック図である。
【図２】サーバとしてトランスコーディングMCUを使用するオーディオビデオ会議システムを示すブロック図である。
【図３】本開示の対象の原理により、スケーラブルビデオオーディオコーディングを使用し、かつSVCS/SACSサーバを介して受信機に多重オーディオストリームおよびビデオストリームを配信するオーディオビデオ通信システムのアーキテクチャを示し、それらのストリームは、受信機上で合成/混合される、ブロック図である。
【図４】図４（ａ）−（ｇ）は本開示の対象の原理により、例示的な標準モードの長方形ビューを示す図である。
【図５】図５（ａ）−（b）は本開示の対象の原理により、長方形長方形行列のレイアウトのビュー幅広がりを計算するために使用されるパラメータを示す図と、本開示の対象の原理により、互い違い長方形レイアウトのビュー幅広がりを計算するために使用されるパラメータを示す図である。
【図６】図６（ａ）−（ｃ）は本開示の対象の原理により、例示的な標準モードの6角形レイアウトを示す図と、本開示の対象の原理により、例示的な拡大モードの6角形レイアウトを示す図と、本開示の対象の原理により、回転した6角形を含む例示的な標準モードの6角形レイアウトを示す図である。
【図７】本開示の対象の原理により、(回転した)6角形レイアウト対長方形行列のレイアウトおよび互い違いのレイアウトのより低いビュー幅広がりを明示するために使用されるパラメータを示す図である。
【図８】図８（ａ）−（ｄ）は本開示の対象の原理により、例示的な拡大モードの長方形ビューを示す図である。
【図９】図９（ａ）−（ｃ）は本開示の対象の原理により、互い違いの長方形ビューを使用する拡大モードの例示的な組合せを示す図と、本開示の対象の原理により、6角形ビューを使用する拡大モードの例示的な組合せを示す図と、本開示の対象の原理により、埋め込まれた拡大ビューを含む6角形ビューを使用する拡大モードの例示的な組合せを示す図である。
【図１０】本開示の対象の原理により、標準モードのレイアウトビューに切り替えられるレイアウト選択ボタン、およびプレビューボタンを含む受信機におけるビデオ会議のアプリケーションの例示的なユーザインターフェースを示す図である。
【図１１】本開示の対象の原理により、拡大モードのレイアウトビューに切り替えられるレイアウト選択ボタンを含む受信機におけるビデオ会議のアプリケーションの例示的なユーザインターフェースを示す図である。
【図１２】本開示の対象の原理により、画面上に示すべきビューの数を選択し、または自動ビュー決定モードを選択するためのドロップダウンメニューを含む受信機におけるビデオ会議のアプリケーションの例示的なユーザインターフェースを示す図である。
【図１３】図１３（ａ）−（ｂ）は本開示の対象の原理により、例示的なレイアウトのテーブルエントリを示す図と、本開示の対象の原理により、例示的なレイアウトのテーブルエントリの対応する鏡映を示す図である。
【図１４】本開示の対象の原理により、目標画面サイズ上のレイアウトのサイジングおよび位置決めを示す図である。
【図１５】本開示の対象の原理により、レイアウト選択プロセスを示すブロック図である。
【図１６】本開示の対象の原理により、ビュー割当てプロセスのレイアウト開始部分を示すブロック図である。
【図１７Ａ】本開示の対象の原理により、ビュー割当てプロセスのレイアウト再処理部分を示すブロック図である。
【図１７Ｂ】本開示の対象の原理により、ビュー割当てプロセスのレイアウト再処理部分を示すブロック図である。
【図１８】図１８（ａ）−（ｂ）は本開示の対象の原理により、種々のアスペクト比によるビューストリームーのクロッピングを示す図と、本開示の対象の原理により、種々のアスペクト比によるビューストリームの手動パンニングを示す図である。
【発明を実施するための形態】
【００２７】
図面全体を通じて、同一の参照数字および文字は、別段の定めのない限り、図示する実施形態の同様の特徴、要素、コンポーネント、または部分を示すために使用される。さらには、本開示の対象は次に、図面を参照して詳細に説明することになるが、例示的な実施形態と関連してそのように行われる。
【００２８】
図1は、例示的な実施形態によるシステムアーキテクチャ100を示し、1つまたは複数のサーバは、ビデオストリームおよびオーディオストリームを、ネットワーク102を介してReceiver101に供給する。図1は、2つのこのようなサーバを示し、Server1は、Stream1を供給し、Server2は、2つのストリーム、Stream2とStream3とを供給する。Server1およびServer2は、Scalable Video Communication Server(SVCS)システムおよび/またはScalable Audio Communication Server(SACS)システムであっても、または(例えば、ストレージからコンテンツにアクセスする)スタンドアロンのメディアサーバであってもよく、他の参加者(図示せず)から受け取られたデータを受信機に転送する。この場合の「参加者」はまた、エンコーディングのみを行う装置など(例えば、生のTV信号をエンコーディングし、伝送するシステム)、伝送のみのシステムであってもよいことが分かる。
【００２９】
例示的な実施形態は、ビデオ信号をエンコーディングするにはよく知られている商業的に利用可能なH.264標準を、オーディオにはSpeex(ウェブサイトwww.speex.orgを参照のこと)のスケーラブルコーデックを使用する。ストリームのうちのいくつかは、単一レイヤAVCを使用してエンコーディング可能であるが、他のいくつかは、そのスケーラブルな拡張SVCを使用してエンコーディング可能である。同様に、Speexオーディオストリームのうちのいくつかは、狭帯域のデータ(8KHz)のみを含むことが可能であるが、他は、狭帯域のならびに、または単独に、広帯域(16KHz)もしくは超広帯域(32KHz)のオーディオを含むことが可能である。ビデオにはMPEG-4/Part 2もしくはH.263++、またはオーディオにはG.729.1(EV)など、代替のスケーラブルコーデックも使用可能である。
【００３０】
ネットワークは、インターネットなど、任意のパケットベースのネットワーク、例えばIPベースのネットワークであってよい。
【００３１】
例示的な実施形態においては、Receiverは、ソフトウェアアプリケーションを実行するPCまたはAppleコンピュータ、デスクトップまたはラップトップなどの汎用コンピュータである。Receiverはまた、例えば商業用オペレーティングシステムの組み込まれたバージョンを使用して、単一のソフトウェアアプリケーションのみを実行するように設計されている専用コンピュータであっても、またはさらには受信用アプリケーションの機能を実行するように設計されているスタンドアロンの装置であってもよい。ソフトウェアアプリケーションは、接続を確立し、ならびに受信し、デコーディングし、かつ受信されたビデオおよび/またはオーディオストリームを表示するか、または再生するためのサーバ(複数可)との通信を担う。それはまた、それ自体のエンコーディングされたビデオおよび/またはオーディオストリームをサーバへと元に伝送することも可能である。このようなReceiver発信ストリームは、Receiverに備え付けられているカメラおよびマイクの出力のリアルタイムなエンコーディングの結果であることが可能であるか、またはReceiver上に、もしくはReceiverからNetworkを介してアクセス可能なファイルサーバ上に、ローカルに保存されている事前コーディングされたビデオおよびオーディオであることが可能である。1つの実施形態においては、Receiverは、接続されているカメラとマイクを備え、生成されたビデオオーディオ信号をエンコーディングし、1つまたは複数のServerを介して他の参加者に伝送する。
【００３２】
SVCS/SACSアーキテクチャにより、Receiverが、Server(複数可)から受信されたデコーディング済みのビデオストリームをそのディスプレイ上で合成し、またデコーディングされたオーディオストリームを混合し、再生することを担う。トランスコーディングMCUなどの従来型多地点ビデオサーバは、受信側のすべての参加者に対して一度にか、または受信側の参加者それぞれに対して別個にか、この機能をサーバ自体の上で実行することが分かる。それ自体の合成を実行するReceiverの性能は、ユーザに非常に大きな柔軟性を提案するが、適切に設計されない場合には、より高いビットレート要件と関連付け可能である。
【００３３】
図2は、3人の伝送参加者:Sender1、Sender2、およびSender3と、Server201と、Receiver203とを含むレガシシステムの典型的な例を示している。Server201は、トランスコーディングMCUとして動作し:それは、オーディオ(A)ストリーム1A、2A、および3Aと、ビデオ(V)ストリーム1V、2V、および3Vとをそれぞれ、Sender1、2、および3のそれぞれから受信し、それらの信号をデコーディングし、シグナリング経路202を介して、Receiver203によって、Server201に示される所望のレイアウトにより、ビデオを合成する。デコーディングされたオーディオ信号はまた、Server201で混合される。結果生じる合成されたビデオ信号と、混合されたオーディオ信号とは、Server201によってエンコーディングされ、2つの別個のストリーム:混合オーディオストリームA(混合された)、および合成ビデオストリームV(合成された)としてReceiver203に伝送される。これらのストリームは、実際には、単一の接続部(例えば、単一のReal-Time Protocol(RTP)ポート)を介して多重化されて、Receiver203に伝送可能であることが分かる。Receiver203は、オーディオ信号およびビデオ信号をデコーディングし、それらを再生する。図2はさらに、Receiverの画面210の例示的なレイアウトを示し、ディスプレイボックス1に表示されるSender1は、ディスプレイボックス2および3内にそれぞれ表示されるSender2および3よりも大きく示している。Server201とReceiver203との間で伝達されるオーディオストリームおよびビデオストリームに対する総ビットレート要件は、Receiverの画面210の解像度における単一のストリームのものである。実際のコンテンツ(すなわち、参加者のうちのいずれか1人から生じる画素)によってカバーされていないピクチャのいずれのエリアも同様に、Server201によってエンコーディングされる必要があることに留意されたい。しかし、コーディングオーバヘッドは一般に、これらのエリアがピクチャからピクチャに変化しないので、小さくなり、したがって、H.264などのコーデックに使用される予測コーディングは、予測エラーを少量に抑えることが可能である。
【００３４】
Receiver203を動作するユーザが別のレイアウトへの切替えを望む場合、このことは、シグナリング経路202を介してServer201に伝達される必要があり、それにより、Server201は、その合成プロセスを変更する。Server201への、およびそのServerからの伝送遅延、ならびにServer201における任意の処理遅延の組合せは、ユーザがアプリケーションソフトウェアで要求を作成する時間から、および新規レイアウトがReceiverの画面210上に現れる時間からの著しい遅延をもたらすことになる。
【００３５】
図3は、図2に示すのと同じ通信シナリオを示すが、この場合、スケーラブルコーディングがビデオ信号およびオーディオ信号において使用されるという仮定による。具体的には、ビデオ信号は、ベースレイヤおよびエンハンスメントレイヤ(例えば、VGAおよびQVGA)の間の水平なまたは垂直なピクチャ寸法間の比率が2の空間スケーラビリティの2つのレイヤにより、H.264SVCを使用してコーディングされると仮定される。同様に、オーディオ信号は、スケーラビリティの2つのレイヤ、狭帯域(ベース)、および広帯域(エンハンスメント)によりコーディングされる。それぞれのSender(1、2、3)からServer305への経路1A、2A、3A、1V、2V、3Vは、オーディオに関しては信号A、およびビデオに関しては信号Vのタイプによりラベル付けされ、レイヤは、ベースに関してはB、エンハンスメントに関してはEのそれぞれのストリーム内に存在する。Server305からReceiver307への経路301、302、303の場合、Senderの数(1から3)がラベルに加えられる。一例として、「1:A/B+E、V/B」は、ストリームがSender1からのデータを含んでいることを示し、オーディオに関しては、ベースレイヤおよびエンハンスメントレイヤがともに存在するが、ビデオに関しては、ベースレイヤのみが存在する。したがって、図3における経路301は、ストリームがSender1からのデータを含んでいることを示す「1:A/B+E、V/B+E」とラベル付けされ、オーディオおよびビデオの両方に関しては、ベースレイヤおよびエンハンスメントレイヤがともに存在する。
【００３６】
引き続き図3を参照すると、Sender(1、2、3)のそれぞれは、オーディオ信号およびビデオ信号のそれぞれに、ベースレイヤおよびエンハンスメントレイヤの何らかの組合せを送信する。レイヤの特定の選択は、SenderとReceiver307との間の利用可能なビットレート、Sender(1、2、3)において利用可能な装置(例えば、低解像度対高解像度のカメラ)、または他の因子によって指図可能である。後述するように、それはまた、エンハンスメントレイヤ(例えば、受信側の参加者のいずれかが、フル解像度で見ていないSender(1、2、3)に対するビデオエンハンスメントレイヤ)が必要でないというServer305からの指示によるするものであることが可能である。
【００３７】
本開示の対象の1つの焦点は、スケーラブルコーディングが使用される場合のReceiver307の動作、およびServer305とのその相互作用である。Receiver307が、適時に、特定の点で、その画面に対して一定のサイズを選択したことが仮定される。サイズは、Receiverのモニタ310の(画素における)物理的サイズであっても、またはアプリケーションウィンドウが全画面をカバーしてない場合、物理的サイズの一部分であってもよい。以下では、単語「画面」は、全体的な物理的画面(アプリケーションがフル画面モードにあるか、またはスタンドアロンの実装部にある場合)か、またはビデオディスプレイにとって利用可能なアプリケーションウィンドウのエリアかのいずれかを区別することなく示すために使用される。
【００３８】
さらには、特定のレイアウトが、Receiver307でユーザによって選択されたということが仮定可能であり、Sender1からのビデオは、フル解像度で示され、Sender2および3からのビデオは、フル解像度の3/4で示される。すべてのビデオ信号がVGA(640×480画素)のフル解像度を有する場合、Sender1のビューは、寸法が640×480になるのに対して、Sender2および3のビューは、寸法が480×360になる。これらのビューを適合させるために、図3に示すレイアウトにおいては、画面に対してアスペクト比4:3を示すが、少なくとも1120×840の長方形サイズが必要とされる。
【００３９】
トランスコーディングMCUからこの合成されたビューを伝送するために必要なビットレートオーバヘッドは、以下のように推定可能である。MCUビデオエンコーダは、画素当たりのビットの、ある平均固定数で動作することが仮定可能である。その場合、表示された画素をカウントすることによって、合成されたピクチャに必要な総ビットレート対VGA信号の総ビットレートが推定可能である。表示された画素の総数は、VGA信号の1+2*0.752、または2.125である。この計算はブランクスペースを無視しており、それは、無視できる数のビットによりエンコーディング可能であると仮定される。そのため、合成されたビデオに関する総ビットレートは、単一レイヤH.264 AVCを使用してコーディングされた単一のVGA信号に必要なビットレートの2.125倍になる。
【００４０】
引き続き図3、および例示的な実施形態における上記なされたレイアウトの仮定を参照すると、Receiver307は、:
1)Sender1には、フル解像度ビデオ(ベースおよびエンハンスメント)を伝送すること、
2)Sender2からのビデオには、ベースレイヤのみを伝送すること、および
3)Sender3からのビデオには、ベースレイヤのみを伝送すること
をServer305に命令する。
【００４１】
Receiver307は、フル解像度のVGA信号を受信すること、およびそれを3/4VGAにダウンサンプリングすることを比較すると、ほとんど視覚的な相違がない所望の3/4VGA解像度(480×360)に、ベースレイヤ信号(QVGA、または320×240)をアップサンプリングすることが可能であるので、Sender2および3からのビデオの受信をベースのみに切り替えるように選択する。アップサンプリング合成プロセスは、Receiver307自体において生じ、Server305は、どのレイヤパケットを特定のReceiver307に転送するかについてのみ伝達される。
【００４２】
この場合に要求される総ビットレートは、以下のように推定可能である。比率2の空間的スケーラビリティに対するベースおよびエンハンスメントレイヤの間の典型的な比率は、3:1である。言い換えると、ベースビットレートは、エンハンスメントレイヤのビットレートの1/3、または総ビットレートの0.25である。そのため、Server対Receiverのビデオ経路は1+2*0.25、またはVGA信号のビットレートの1.5を要求することになる。PSNRによって測定されるのと同じ品質を達成するためのスケーラブル対単一レイヤのコーディングと関連付けられる10%ビットレートオーバヘッドについて明らかにすると、総ビットレートは、1.5*110%または1.65である。トランスコーディングMCUの場合(2.125)と比較すると、この技術は、22%だけビットレート要件を抑える。
【００４３】
Serverが、SVCSでもMCUでもなく、多重ビデオストリームをReceiverに単純に転送する場合、総ビットレート要件オーバヘッドは、受信され、表示される3つのビューがあるので、3である。スケーラビリティまたはトランスコーディングがない場合、Receiverは、選択がないのではなく、すべてのビューに対してフル解像度信号を受信し、必要に応じて、スケーリングを実行する選択がある。本開示の対象のスケーラブルな設計の競争上の利点が、この場合にさらにより大きくなり、45%ビットレート抑制をもたらす。これらの利得は、参加者の数の増加により、さらに増幅される。
【００４４】
オーディオ通信アプリケーションの文脈においては、同様の利得が、単純な転送用サーバと比較して、スケーラブルコーディングによるSACSアーキテクチャを使用することによって得ることが可能である。この場合、国際特許出願第PCT/US06/62569号に記載されているように、「active plus N most recent speakers」技術が使用されることが仮定可能である。さらには、Nは1であり、アクティブな話者は、Sender1からであること、および次のより新しい話者はSender2であることが仮定可能である。音声の活動レベルは、SenderまたはServer自体において計算可能であることが分かる。
【００４５】
この情報により、および図3のレイアウトが使用されることを所与として、Serverは、Sender1からのベースおよびエンハンスメントのオーディオ信号、Sender2からのベースオーディオレイヤのみを伝送し、Sender3からのオーディオを伝送しない。総ビットレート要件は、それ自体の混合を実行するトランスコーディングサーバの要件よりもわずかに高いが、単純な転送Serverの要件の2/3よりも低い。後述するように、N個の最も新しいメモリを含むアクティブな話者の指示は、ビデオレイアウト自動化において(スケーラブルオーディオコーディングが使用されるか否かにかかわらず)有利に使用可能である。
【００４６】
前述の例は、はるかにより低いビットレート要件であっても、受信機における柔軟性の向上を得るために、スケーラブルコーディングおよび受信機-サーバのシグナリングとともに、レイアウト管理技術を使用することの利点を明示している。
【００４７】
一例を説明してきたが、本明細書においてなされる本開示の技術は、実用的な意義を有する広範囲のレイアウトに、より概括的に適用可能である。レイアウトは、2つの主なカテゴリ、またはモード:標準および拡大に分類可能である。標準モードにおいては、(画面上に示される)すべての参加者は、同じビューサイズに示される。拡大モードにおいては、1つまたは複数のビューが、より大きいサイズで示されるのに対して、他は、より小さいビューサイズに示される。ビデオ会議の設定における拡大ビューは、Server305か、またはReceiver307のいずれかによって決定されるように、1人または複数のアクティブな話者に対応することが可能である。オーディオビジュアル通信以外、例えば多重ソースの放送コンテンツを閲覧するアプリケーションにおいては、拡大ビュー(複数可)は、Receiver307において、ユーザが、より大きいサイズに示されるように選択するソース(複数可)であることが可能である。
【００４８】
図4(a)〜(g)は、長方形ビュー編成を使用する例示的な標準モードのレイアウトを示している。画面内のそれぞれのビューは、長方形である。1つ実施形態においては、長方形は、オリジナル信号のピクチャアスペクト比に従うことが可能である。図4(a)は、ビデオ会議システムによく見られる典型的な2×2行列レイアウトである。図4(b)は、すべてのビューが垂直に積層されている場合であるのに対して、図4(c)は、それらを水平に表示している。画面エリアは、典型的なモニタ画面アスペクト比(16:9、または4:3)と整合してないように見えるが、画面は、コンピュータ上で動くアプリケーションウィンドウのものであることが可能であり、したがって、ユーザは、同じコンピュータモニタ上で他のウィンドウを見ることができるために、このようなビューを選択することが可能である。
【００４９】
図4(d)はやはり、4面の長方形のものであるが、この場合、上下のビューが画面の中心線上に位置決めされている。一見したところ、このビューは、総画素に関する総画面エリアが図4(a)のものよりも広いという欠点を有するように思われる。実際、それぞれのビューが画素において幅Wであり、高さHである場合、図4(a)の画面サイズは、2W×2Hであるのに対して、図4(d)では、3H×2Wである。しかし、知覚的に、図4(d)におけるレイアウトは、それぞれのビューの中心にあると仮定される対象が、互いにより接近しているという利点を有することが可能である。これは、画面の中心点上に中心があり、画面上に示されるすべてのビューの中心を囲むことになる最も小さい円の半径を計算することによって見ることが可能である。より小さい半径は、ビューの被写体が、それらのそれぞれのビューの中心に位置決めされていると仮定されて、互いに、より接近して位置決めされていることを示している。これは、閲覧者が、直接的視野と周辺視野とをともに使用してそれぞれのビュー内の動作を認識することをはるかに容易にする。ビューの高さに対する円の半径の比率を、本明細書においては、特定のレイアウトの「ビュー幅広がり」として定義し、「v」で示す。
【００５０】
図5(a)〜5(b)は、4ビューの場合における行列および互い違いの長方形パターンを示し、また様々な寸法も示している。図5(a)に示す2×2長方形行列の場合、最も小さい囲んだ円の半径RMは、
【００５１】
【数１】
0005497020.tif 000002
【００５２】
になり、ただし、r=W/Hは、ビューアスペクト比である。
【００５３】
図5(b)に示す互い違いの1×2×1パターンの場合では、半径RSは、(典型的に、W/2<Hであるので)Hと等しくなり、したがって:
【００５４】
【数２】
0005497020.tif 000003
【００５５】
ビューアスペクト比rが典型的に、4/3または16/9であることを所与として、行列パターンについてのビュー幅広がりは、それぞれ、0.83および1.02になる。したがって、行列パターンは、低いアスペクト比に対しては、互い違いのパターンよりも低く、高いアスペクト比に対しては、わずかにより高い(2%だけ)ビュー幅広がりを有する。
【００５６】
示した図4(e)〜(g)に戻ると、図4(b)〜(d)に類似のレイアウトであり、この場合、3つのビューを有する。この場合、(すべてのビューが全く同じサイズであると仮定すると、)行列は、構成不可能であることに留意されたい。これらのレイアウトのオプションは、詳細に後述するように、レイアウト自動化に関連している。これらのレイアウト構造は、任意の数のユーザに対して概括可能である。あり得る制限は、(論理的または物理的な)画面のサイズであり、ユーザが閲覧するのに許容可能な最小ビューである。ビューの数が増えるにつれて、画面上にそれらのすべてを適合させることは不可能になり、したがって、詳細に後述するように、自動選択機構が使用される必要がある。
【００５７】
図5(a)〜(b)の文脈で論じるビュー幅広がりは、長方形でないパターンを考慮することによって概括可能である。サンプリング理論からの関連した問題が、最小の数のサンプリング点を使用して、そのサンプルから所与の帯域制限された信号を正確に再構成するサンプリングパターンを探し出すことである。2D等方性スペクトル、すなわち、環状に帯域制限された2D関数の場合、最適なサンプリングパターンは格子であり、軸は、角度45度であり、6角形状から成るVoronoi分割を招く(例えば、D.P. Petersen and D. Midleton、「Sampling and Reconstruction of Wave-number Limited Functions in n-dimensional Euclidean Spaces」Inf. Control、5:279-323、1962年を参照のこと)。Voronoi分割は、2-D平面を、格子上の点のうちの1つに最接近している点の組に分解する。等価的には、6角形の分割パターンは、それぞれの6角形がその内接する(最も効率的に詰まった)円板形に置き換えられる場合、最小の「空き」空間をもたらす。
【００５８】
この特性を使用して、図6(a)〜(c)に示すものなどのレイアウトパターンが設計可能である。図6(a)は、5面6角形標準モードのレイアウトであるのに対して、図6(b)は、5面拡大モードのレイアウトであり、単一の拡大ビューは、他の参加者のサイズの2倍で示されている。6角形「セル」はまた、30°だけ回転して使用可能であり、それにより、2つの頂点が垂直に配向される。回転した6角形パターンを有する7面標準モードのレイアウトについての一例が、図6(c)に示される。6角形のレイアウトは、多数の参加者では、ますます効果的である。
【００５９】
行列および互い違いの長方形ビューと同様に、この場合も同様に、4面6角形レイアウトで、ビューのすべての4つの中心を囲むことが可能な最も小さい円の半径RHが、計算可能であり、したがって、ビュー幅広がりは、得ることが可能である。辺Sを有する正6角形の場合、その最大直径は2Sであり、その最小直径は、
【００６０】
【数３】
0005497020.tif 000004
【００６１】
である。図7は、それぞれの6角形の高さがその最小直径、すなわち:
【００６２】
【数４】
0005497020.tif 000005
【００６３】
であることを示している。対称のため、半径RHは、
【００６４】
【数５】
0005497020.tif 000006
【００６５】
で与えられることになる。Sを、上記方程式におけるHで置き換えることにより、
【００６６】
【数６】
0005497020.tif 000007
【００６７】
がもたらされる。回転した6角形を使用すると(図6(c)を参照のこと)、それぞれのビューの高さは、2Sであるのに対して、半径は3S/2であり、したがって、ビュー幅広がりは、vrotH=0.75、すなわち、さらにより低い。行列および互い違いのレイアウトについての結果と比較すると、vrotHは、vS(1に等しい)およびvM(0.86以上)の両方よりも、著しく小さい。
【００６８】
第2のカテゴリのレイアウトは、拡大モードのレイアウトである。標準レイアウトに対する差は、少なくとも1つのビューは、残りのビューよりも大きいサイズで示されることである。図8(a)〜(d)は、いくつかの例を示している。図8(a)は、1つの拡大ビュー(ビュー1)を有する水平に配向された3面長方形レイアウトである。ビュー1は、残りのビューのサイズの2倍であるので、2つのビューは、ビュー1の側面に積層可能であることに留意されたい。図8(b)は、6面長方形行列のレイアウトである。この場合、拡大ビュー(ビュー1)は、画面の左上隅部に配置され、残りのビューは、右側および下部に、その拡大ビューの周囲に位置決めされる。図8(c)は、この場合、垂直に配向された同じ6面ビューを示している。ビュー6は、空きの画面空間に均等に分布するように、画面の中心線に配置されていることに留意されたい。最後に、図8(d)は、2つの拡大ビューを有する6面レイアウトであり、長方形行列で編成されている。N個のビューを有するレイアウトに対する拡大ビューPの数は、0とN-1との間であることが可能である(P=Nまたは0の場合、モードは基本的に、標準モードである)。
【００６９】
互い違いで、6角形のレイアウト(または、実際には、任意のレイアウト)は、一緒に組合せ可能である。図9(a)〜(c)は、図9(a)における互い違いのビュー、ならびに図9(b)〜(c)における6角形ビューを使用する組合せを示している。すべての場合において、単一の拡大ビューは、大きい長方形として示される。図9(c)においては、拡大ビューは、ビュー2および5の背後に「埋め込まれている」ことに留意されたい。このレイアウトは、ビュー2および5が重要な情報を隠していないと仮定して(この決定は、ユーザによって行われ得る)、画面エリアのより優れた使用をもたらす。6角形ビューのみを使用する拡大モードのレイアウトの一例を、図6(b)に示している。
【００７０】
種々のレイアウト構造間の多数の可能性を所与として、可能な選択に、ユーザを適切に導くことが重要である。明らかに、ユーザは、いくつの異なるビューが一緒に適合することが可能であるかを計算することが負担になってはならない。そうではなく、ユーザは、Receiverシステムに、ユーザの概括的な嗜好の指示を提供すべきである。具体的には、例示的な実施形態においては、ユーザは、Receiverシステムに、画面のサイズ、および標準または拡大モードのレイアウトを使用すべきか否かを指示する。後者の場合には、ユーザはまた、使用すべき拡大ビューの数を示すことが可能である。Receiverがスタンドアロンのシステムである場合には、画面サイズは、システムの全ディスプレイエリアであるように適合可能である。画面サイズおよびレイアウトカテゴリの特定の設定の場合、ユーザはまた、一定の数の参加者、または自動ビューレイアウトモードにより、ビュー間で選択することが可能である。
【００７１】
図10は、Receiverにおいてユーザに供給される例示的なビデオ会議ユーザインターフェースを示している。インターフェースは、ビデオを表示するために利用可能なエリアと、Receiverアプリケーションの機能へのアクセスを実行するメニューバーとから成るアプリケーションウィンドウ内でホスティングされる。アプリケーションウィンドウは、(オペレーティングシステムによって提供されるウィンドウ装飾の隅部でクリックし、ドラッグすることによって、)存在する場合には、ホストオペレーティングシステムの標準ルックアンドフィールポリシに続いて、サイズ変更するための手段を提供する。スタンドアロンシステムにおいては、アプリケーションウィンドウは、ユーザに利用可能であり得る他のプリケーションがないとき、全画面を占有することが可能である。このような場合には、画面サイズは、一定と考えることが可能である。
【００７２】
例示的な実施形態においては、メニューバーは、レイアウトの嗜好を選択するためのボタンを提供する。ボタンは、標準レイアウトモードと、アクティブな話者のレイアウトモードとの間でトグルする。図10においては、標準モードのレイアウト構成が選択されている。図はまた、4面のレイアウト構造での実際のビューを示している。「Preview」オプションが(対応するボタンを押すことによって)設定される場合、ビューのうちの1つが、Receiverに接続されているカメラから得られるローカルなビデオプレビューである。
【００７３】
図11は、同じユーザインターフェースを示し、この場合、レイアウト選択ボタンが拡大モードにトグルされている。ボタンアイコンは、レイアウトカテゴリ(ボタン上の、より大きいビュー長方形に留意されたい)を連想させる。図11はまた、6つのビューを有する実際のアクティブな話者のレイアウトを示している。例えば6角形の追加のレイアウトスタイルが、ユーザインターフェースのレイアウト選択ボタンによって提案される選択を開くことによって、同様に選択可能である。
【００７４】
レイアウトカテゴリのそれぞれについて、ユーザは、画面上に示すべき多数のビューを選択することが可能である。例示的な実施形態のユーザインターフェースにおいては、これは、レイアウト選択ボタンの右側にドロップダウンボタンを使用して実行される。図12は、ドロップダウンボタンが押されたときのユーザインターフェースを示している。ユーザには、1から8個のビューの選択、または画面上のビューの数の自動的な決定が提示される。図12においては、自動モードが選択されている。ビューの数に関する他の範囲、例えば1〜12も、この場合に提示されているプロセスの動作におけるいずれの変更もなく、選択可能である。
【００７５】
長方形ビューレイアウトを得るための例示的な実施形態によるプロセスを次に説明することにする。ユーザが画面サイズを修正することができる場合、プロセスのパラメータを所与として、そのプロセスは、ユーザによって選択されたサイズが、有効なレイアウトをもたらすかどうかを確認するために、アプリケーションウィンドウサイズ変更プロセス中に呼び出される。ユーザが画面のサイズ変更をするためにウィンドウの境界をドラッグするとき、レイアウトが計算される。有効な結果が見られた場合のみ、アプリケーションは、画面上のウィンドウのサイズ変更の境界を描画し、ユーザに対して、これは許容可能な構成であることを示す。以下に、長方形のレイアウト構成を論じる。6角形のレイアウト、および全体的にモザイク状のレイアウトをその後に論じる。
【００７６】
プロセスへの入力は、
-画素における画面の幅Wおよび高さH
-画面内に含むビューの数N
-拡大ビューの数P、
-ビューの所望のアスペクト比r
-幅および高さそれぞれに関する正規化されたクロッピング公差CWおよびCH
であることが可能である。
【００７７】
プロセスは、目標画面サイズにビューの特定の数の最良な適合性を探し出そうと試みる。ビューは、すべて同じアスペクト比を有すると仮定される。このアスペクト比は、所望のアスペクト比rを有する画像が、水平および垂直寸法それぞれにおける特定の最大値CWおよびCHほどそれをクロップすることなく、ビューに適合することが可能であるほどのものでなくてはならない。言い換えると、画面のアスペクト比rSは:
【００７８】
【数７】
0005497020.tif 000008
【００７９】
を満たさなくてはならない。
【００８０】
例示的な実施形態においては、rは、16/9に設定され、Cwは、0.3に設定され、CHは、0に設定される。
【００８１】
システムによって考えられるすべてのあり得る長方形のレイアウトの組は、レイアウトテーブルTによって示すことが可能である。テーブル内のそれぞれのエントリは、特定のビューレイアウトを示す。それぞれのエントリは、それが含むビューの数、ならびに同じ数のビューを有するレイアウトの組内の元々の数によって、インデックス化される。特定のエントリについて、および任意のサイズの長方形を示すことを可能にするために、テーブルは、「ブロックを形成する」基本的長方形K×Lの行列を使用して、レイアウトを示す。それぞれのビューは、適切な長方形を形成するこれらのブロックのサブセットに対応する。しかし、いかなるビューにも属さないブロックがあり得ることに留意されたい。それぞれのエントリについて、特定のビューは、行列上のビューの左上隅部の位置、およびビューのスケール係数を整数として示すことによって指定される。スケール係数は、水平にも、および垂直にも、ビューが何個のブロックを取ることになるかを示す。スケール係数は両方の寸法に適用され、したがって、設計によるアスペクト比を維持することに留意されたい。
【００８２】
例示的なレイアウトテーブルエントリを、図13(a)に示している。図は、3つのビューを有するレイアウトを示し(標準モード)、ビューは、互い違いである。4×4行列のブロックを形成する長方形が、ビューの相対的位置決めを指定することを可能にするためには必要とされる。ビュー0は、(1、0)において位置決めされ、すなわち、その左上隅部はそのブロックから開始し、そのサイズは、係数2である。これは、水平にも、および垂直にも、それが2つのブロックを占有することになることを意味する。したがって、そのビューに対応するテーブルエントリは、3重項{1、0、2}になる。ビュー1は、(0、2)において位置決めされ、それもまた、サイズ係数が2である。したがって、それは、3重項{0、2、2}によって示されることになる。同様に、ビュー2は、{2、2、2}によって示されることになる。したがって、レイアウト全体は、{4、4、{1、0、2}、{0、2、2}、{2、2、2}}と示すことが可能である。N個のビューを有する任意のレイアウトテーブルは、{K、L、{X0、Y0、S0}、...、{XN-1、YN-1、SN-1}}と示すことが可能であり、ただし、Xi、Yi、およびSiは、それぞれのビューの位置決めおよびスケール係数のパラメータにそれぞれ対応する。
【００８３】
所与のレイアウトについて、行列の主な対角線に沿ってテーブルエントリの像を映すことによって作成される対称的なレイアウトもまた、有効なレイアウトである。したがって、それぞれのレイアウトのテーブルエントリは、2つの別個のレイアウトを示す。鏡映は、それぞれのビューの左上隅部の位置のx座標およびy座標を交換したもの、ならびにビルディングブロック行列の寸法に対応する。言い換えると、テーブルエントリビュー{K、L、{X0、Y0、S0}、...、{XN-1、YN-1、SN-1}}は、{L、K、{Y0、X0、S0}、...、{YN-1、XN-1、SN-1}}に像を映す。図13(b)は、図13(a)から得られる鏡映レイアウトを示す。鏡映レイアウトは、自動的に考慮されるので、テーブルは単に、K≧Lを満たすレイアウトを含むことが必要なだけである。
【００８４】
所与のレイアウトが、以下のように目標画面サイズに対して適合される。所与のレイアウトは、目標画面サイズに適合するように引き伸ばされる。これが、所望の範囲でアスペクト比を有するビューをもたらす場合、それは、一致と見なされる。そうでない場合、レイアウトは、アスペクト比が有効範囲にあるように、1つの寸法にスケールダウンされる。この場合においては、レイアウトは、ウィンドウ全体をカバーすることはなく、目標画面サイズの中心に位置決めされることになる。
【００８５】
レイアウトがW×H画面上に表示される場合、仮にWLおよびHLがそれぞれ、ビルディングブロックの幅および高さに対応するとする。WLおよびHLは、以下の疑似コード:
【００８６】
【数８】
0005497020.tif 000009
【００８７】
ならば{//ワイド画面の場合
【００８８】
【数９】
0005497020.tif 000010
【００８９】
}あるいは
【００９０】
【数１０】
0005497020.tif 000011
【００９１】
ならば{//トール画面の場合
【００９２】
【数１１】
0005497020.tif 000012
【００９３】
}そうでなければ{//一致している画面の場合
【００９４】
【数１２】
0005497020.tif 000013
【００９５】
}から得られる。
【００９６】
特定の画面サイズに対するこのレイアウトの有効アスペクト比rLは:
【００９７】
【数１３】
0005497020.tif 000014
【００９８】
と定義される。
【００９９】
画面サイズに適合された特定のレイアウトの位置決めは、以下のように実行される。レイアウトは、{K、L、{X0、Y0、S0}、...、{XN-1、YN-1、SN-1}}によって特徴付け可能である。W×H目標画面サイズに対して有効レイアウトエリアKWL×LHLを中心に置くためには、水平に、または垂直にオフセットを適用することが必要である場合がある。水平寸法および垂直寸法におけるオフセットは:
【０１００】
【数１４】
0005497020.tif 000015
【０１０１】
および
【０１０２】
【数１５】
0005497020.tif 000016
【０１０３】
として得ることが可能である。
【０１０４】
i番目のビューは:
xi=Woffset+XiWL(11)およびyi=Hoffset+YiHL(12)
において(画素内に)位置決めされた左上隅部により位置決めされることになり、画素のサイズは、SiWL×SiHLになる。
【０１０５】
図14は、図13(a)に示すレイアウトを一例として使用する種々のサイジングおよび位置決めのパラメータ、具体的には、View0を示し、ワイド画面の場合を仮定している。
【０１０６】
レイアウトテーブルに示すそれぞれのレイアウト(およびそれぞれの鏡映)について、上述のレイアウト適合プロセスは、画面上に配置可能なレイアウトをもたらすことになる。しかし、明らかに、いくつかのレイアウトは、それらがいかに十分に目標画面サイズに適合するかという点で、好ましい。一例として、非常にワイドな画面に配置されている垂直な配向によるレイアウトを検討する。上述のプロセスは、ある解決策をもたらすことにはなるが、結果生じるビューは非常に小さく、同時に、表示されるレイアウトの左右に、大量の使用されない画面空間があることになる。したがって、本開示の対象は、所与の画面サイズに対するレイアウト適合プロセスの結果のランキングを可能にするスコアリングプロセスを導入する。最高スコアを有するレイアウトは、プロセスへの入力パラメータを所与として、手元の画面サイズに対して最良の一致するものと見なされる。
【０１０７】
本開示の対象の例示的な実施形態におけるスコアリングは、2段階のプロセスを使用する。第1には、それは、拡大および通常のビューに割当て可能なビューの最小サイズの加重平均を考慮する。同点の場合には、スコアリングプロセスは、すべての区画の総サイズを考慮する。拡大ビューが要求されない場合には、対応するスコアリングのコンポーネントは無視される。
【０１０８】
仮に、Nをビューの数とし、Pを拡大ビューの数とする。仮に、V={Vi、i=1、2、...}をN個のビューを含むレイアウトテーブルTにおけるレイアウトの組とする。レイアウトViが、{Ki、Li、{Xi0、Yi0、Si0}、...、{XiN-1、YiN-1、SiN-1}}によって特徴付けられる。仮に、Uを、それについて少なくともP個のビューがあるレイアウトを含むVのサブセットとし、それらのビューは、残りのN-P個のビューよりも大きいサイズ係数Sを有する。これらのビューは、拡大ビューとして使用されることになる。組VおよびUは、動的に計算可能であるか、または別の実施形態においては、レイアウトテーブルTにおける適切なパラメータによって示すことが可能である。言い換えると、テーブルエントリは、ビューの数ならびに支持される拡大ビューの数をともに直接、示すように開くことが可能である。あるレイアウトが、構造:{Ki、Li、Ni、Pi、{Xi0、Yi0、Si0}、...、{XiN-1、YiN-1、SiN-1}}によって特徴付け可能である。このように、VおよびUの要素を識別することは、テーブルTを順次走査し、パラメータNiおよびPiを調べることによって行うことが可能である。レイアウト適合プロセスは単に、入力パラメータが設定された後に、組Uに適用されることが必要なだけであることに留意されたい。
【０１０９】
組Uにおける特定のレイアウトのスコアリングは、以下のように実行される。:
1.P番目に大きいビューサイズのminp=(Sj)2WLHLを有するビューjを探し出す。これは、拡大ビューの中で、最も小さいビューサイズである。P=0、またはNの場合には、minpは、0に設定される。
2.すべてのビューのminN=(Sk)2WLHLの中で最も小さいビューサイズを有するビューkを探し出す。
3.スコアsを:
s=(1-w)minp+wminN(13)
と計算し、ただし、wは、加重係数である。例示的な実施形態においては、wは、1/11に設定される。
【０１１０】
次いで、Uにおけるレイアウトすべてのランキングは、以下により実行される。:
4.(スコアリング)UにおけるそれぞれのレイアウトUiについて、それのスコアsiを計算する。最も高いランキングのレイアウトが独自のものである場合は、それは選択されたものである。
5.(事後フィルタリング)2つ以上のレイアウトが同じスコアを生成する場合は、これらのレイアウトのそれぞれについて、それらの総サイズを計算する。:
【０１１１】
【数１６】
0005497020.tif 000017
【０１１２】
最も高いスコアtiを有するレイアウトは、選択されたものである。
【０１１３】
上述のプロセスは、拡大された参加者に大きいビューサイズをもたらし、他の参加者にはそれほど小さくないビューをもたらし、所与の画面サイズの優れた適用範囲をもたらすレイアウトの選択を助長する。プロセスはさらには、minp、minN、およびtiの計算から定数WLHLを除くことによって、計算する上で単純化可能である。
【０１１４】
大画面サイズの場合、総レイアウトサイズtiではなく、ビュー幅広がりを考慮することが好ましい場合がある。その場合、上述の2は:
2b.(事後フィルタリング)2つ以上のレイアウトが、同じスコアを生成する場合は、画面高さHがHthrよりも高ければ、最も低いビュー幅広がりを有するレイアウトを選択し、そうでなければ、最も高い総サイズtiを有するレイアウトを選択する
に置換え可能である。例示的な実施形態においては、Hthrは、720に設定可能である。このプロセスは、大画面サイズについて、それらがユーザのビューフィールドにおいて、より容易にアクセスできるように、ビューを位置決めすることが好ましい場合があることを考慮に入れる。
【０１１５】
もちろん、他のスコアリング/フィルタリングのプロセスも、可能である。さらには、(レイアウトパラメータから直接、計算されない)アドホックデータもまた、スコアリングプロセスにおいて考慮に入れることが可能である。例えば、それぞれのレイアウトテーブルエントリは、特定のレイアウトが特定のアプリケーションに対して、いかに適切であり得るか、または好ましいものであり得るかに関係する明示的な追加のスコアリングコンポーネントによって増大可能である。この追加のスコアリングコンポーネントは、特定のレイアウトの選択を助長または抑制するために、適切に加重されて、上述のスコアリングに追加可能である。追加のアドホックスコアリングコンポーネントをSadhocで、および関連する加重をxで示すと、sに関する方程式は:
s=(1-w-x)minp+wminN+xsadhoc(15)
になり、ただし、加重wおよびxは、0と1との間であり、0≦w+x≦1を満たす。例示的な実施形態においては、加重は、w=1/11およびx=5/11に設定される。
【０１１６】
上述のスコアリングプロセスは、入力パラメータに関係なく、出力レイアウトを生成することになる。極限状況を避けるために、それは、適切とは考えられない結果をフィルタリング除去する追加の制約により増大可能である。例えば、閾値は、任意の参加者に対する最小のアクセス可能なビューサイズ(例えば、120画素)に関して使用可能である。その場合、組Uは、この制約を満たさないいずれのレイアウトについて、レイアウト適合プロセスを適用後に、取り除くことが可能である(事前フィルタリング)。同様に、閾値は、レイアウトが使用されないまま残ることが可能な画面のパーセント(例えば、40%)として設定可能である。これは、比率ti/(WH)(すなわち、ti/(WH)>0.4)として表される。
【０１１７】
最後に、いくつかのレイアウトは、美的またはアプリケーション特有の理由で、それらの実際のスコアに関係なく、許容できないと考えられる場合がある。レイアウトのテーブルが、スクリプトによって自動的に作成される場合には、フラグが許容できないレイアウトを信号伝達するために、それぞれのレイアウトテーブルエントリに使用可能である。言い換えると、このようなフラグが設定されない場合は、レイアウトは、スコアリングプロセスにおいて全く考慮されない(事前フィルタリングで除かれる)。ビデオ会議からの1つの可能な例は、逆ピラミッドに似ているレイアウト(例えば、4:3:2:1として位置決めされるビューを有する長方形の行列レイアウト)である。
【０１１８】
例示的な実施形態においては、目標画面を対話形式でサイズ変更するプロセスの間、特定のサイズ選択は、有効レイアウトを作成する上述のレイアウト選択プロセスを許容可能であると考えられる。そうでない場合は、ユーザは、特定の画面構成を維持することができない。
【０１１９】
図15は、上述の例示的なレイアウト選択プロセスのブロック図を示している。NおよびPは、1501において設定される。WまたはHが、1502において変更される場合はいつも、オフセット、WoffsetおよびHoffsetならびにブロックサイズWLおよびHLが1503において計算される。次いで、プロセスは、レイアウトテーブル1504内に保存されているレイアウト全体にわたって反復するように進み、最大スコアを有するレイアウト(複数可)を1506において得る。すべてのレイアウトが考慮される必要はなく、図15に示すように、レイアウトが、NおよびP個のパラメータの値、ならびに配置された可能性がある任意の他の制約(例えば、最小ビューサイズ)に基づいて(スコアリングの前に、組Uを構成するために)、1505において事前フィルタリングされることに留意されたい。スコアリングプロセスの結果(ゼロ以上のレイアウト)は、1507において事後フィルタリングされる。少なくとも1つの結果が1508において見つけられた場合、そのレイアウトは適用され、プロセスは、1509において終了する。そうでなければ、プロセスは、1502においてWおよびHについての新規値を待つ状態に戻る。プロセスはまた、ReceiverアプリケーションにおいてNまたはPの変化がある場合はいつも、使用される。
【０１２０】
特定のレイアウトが有効になり次第、Receiver307は、シグナリング経路306を介してServer305にそれぞれのストリームのビューの寸法を含む情報を与える(図3を参照のこと)。次いで、Server305は、それぞれのストリームから、どのスケーラブルレイヤをReceiver307に転送するかを決めることが可能である。いくつかの場合においては、後述するように、それは、ストリームが全く表示されない場合であり得、したがって、Server305は、特定のストリームについて全くデータを送信することができないことに留意されたい。スケーラブルコーディングにより可能にされる、Server305の選択的な転送機能を有するReceiver307におけるレイアウト管理の結合は、柔軟性を最大限にする非常に有効な解決策をもたらし、同時に、所要のビットレートを最小限に抑える。
【０１２１】
これまでは、システムに存在するストリームの数対画面上の利用可能なビューの数の関係は対処されてこなかった。ユーザがいくつかの所望のビュー、およびあり得るいくつかの所望の拡大ビューを選択したことが仮定される。利用可能なストリームの数は、所望のビューの数より少なくても、それと等しくても、またはそれより多くてもよい。同様に、ビューのそれぞれに割り当てるための利用可能なストリームは、たとえ、それが拡大タイプまたは標準タイプであっても、対処されてこなかった。常に、Receiverにおけるユーザが、ビューに対して手動でストリームを割り当てることを可能にすることができることが分かる。例えば、ユーザは、特定のレイアウトと、特定のビューにストリームを割り当てるために、表示リストからレイアウト位置にドラッグアンドドロップストリームとを選択することが許可され得る。本開示の対象は、自動的なやり方で、これらの問題の両方に一緒に対処するプロセスを提供する。これは、利用可能な画面空間およびビューの数の最適な使用を確実にすることが可能であり、このシステムは、ストリームを標準ビューから拡大ビューに自動的に切り替えることも(例えば、ビデオ会議における発話活動がある場合)、またはストリームがシステムに加えられるか、もしくはシステムから取り除かれるとき、レイアウトを自動的に切り替えることも可能である。
【０１２２】
まず、利用可能なレイアウトビューの数に対する利用可能なストリームの数の関係に関しては、表示するために作成されるビューより少ない利用可能なストリームがある場合には、Receiverは、使用されないビューを空きのまま残すことが可能であり、オプションで、ロゴ画像または他の所定の情報を表示する。使用されない、または等価的な状態のまま残るビューの選択、使用されることになるビューの選択は、いくつかのやり方で実行可能である。一例が、まず、レイアウトのラスタ走査プロセスを使用して、拡大ビューを割り当てることであり、次いで、同じパターンに続いて標準ビューを割り当てることに進むことである。これは、画面の底部を使用されないまま残す傾向になるので、ラスタ走査への代替の走査パターンは、それらが長方形エリアにできるだけ近接してビューを割り当てられるように考案可能である。
【０１２３】
例示的な実施形態においては、ビューがレイアウトテーブルに入力される順番は、ビュー割当てのための所望の順番と考えられ得る。このように、設計によるレイアウトテーブルは、所望の割当て方策を示し、それは、それぞれのレイアウトテーブルエントリ用に完全にカスタマイズ可能である。特定の割当て方策にかかわらず、このプロセスは、画面のいくつの重要な部分を使用されないまま残すことになり、Receiverは、表示されるレイアウトの4つの側に空き空間を等しく配分するために、この場合には、画面を中央に置くことを選択することが可能である。
【０１２４】
例示的な実施形態においては、Receiverが、いずれのビューも使用されないまま残さないレイアウトを使用しようと試みることが可能であり、したがって、利用可能なストリームの数が、利用可能なビューの数よりも小さくなる状況においては、それは好ましくは、利用可能なストリームの数と同じ数のビューをもたらす異なるレイアウトに切り替えることが可能である。そうする際には、それは好ましくは、現在のレイアウトと同じ数の拡大ビューを保持することが可能である。言い換えると、現在のレイアウトが、M=Nストリームの総計に対して、N個のビューおよびP個の拡大ビューにより構成され、1つのストリームが、セッションから取り除かれる場合、Receiverは、N-1個のビューおよびP個の拡大ビューを有するレイアウトを使用しようと試みることになる。
【０１２５】
利用可能なビューの数が、利用可能なストリームの数と等しい場合は、それぞれのビューに対するそれぞれのストリームを指定することが唯一の問題である。利用可能なストリームの数がより高い場合は、どのストリームがビューを割り当てることがないかを識別する必要がある。本開示の対象において使用されるストリーム優先順位付けは、統一されたやり方で、これらの問題の両方に対処する自然の順序付け機構をもたらす。
【０１２６】
例示的な実施形態における優先順序付けプロセスは、オーディオ活動の情報に依存する。例示的な実施形態においては、オーディオ活動は、オーディオ信号の容量(例えば、スライドウィンドウ上で計算される短期平均エネルギー)として計算可能である。放送タイプのアプリケーションに向いている代替の実施形態においては、それは、発話活動(対音楽、または対効果)のインジケータであることが可能である。オーディオ活動は、Sender、Server、またはReceiverにおいて計算可能である。例示的な実施形態においては、それは、Senderにおいて計算される。これは、ServerおよびReceiverが、オーディオ活動を低下させる順序で、ストリームをランク付けし易くすることを可能にする。M個の利用可能なストリームがあり、現在のレイアウトを使用して表示されることになるために、N<Mであると仮定する。P<Nのいくつかのそれらは、拡大ビューに対応することが可能である。仮に、A(i)がストリームiに対するオーディオ活動のインジケータを示すとし、ただし、より高い値は、より高い活動を示す。
【０１２７】
ビュー割当てプロセスは、M、N、またはPの変化がある場合は常に、同調して、そうでなければ周期的に(オーディオ活動の変化を得るように)動作する。例示的な実施形態においては、その周期は、1秒に設定可能である。ビュー割当てプロセスが経時にわたって動作するとき、それは、どのストリームが現在のレイアウトにおけるそれぞれのビューに割り当てられるかを知る必要がある。ストリームが識別子と関連付けられること、およびこの識別子は、特定のビューへのストリームの割当てを示すそれぞれのビューと関連付けられることが仮定される。例えば、識別子は、Receiverがそれぞれのストリームに割り当てる独自の整数、ストリームを説明するメモリ構造に対するポインタなどであってよい。このように、ビュー割当てプロセスは、どのストリームがそれぞれのビューに示されるかを、およびその逆を識別することが可能である。
【０１２８】
図16は、例示的な実施形態によるビュー割当てプロセスのブロック図を示している。まず、アプリケーションが開始するとき、またはNもしくはPに変化があるとき(レイアウト開始)など、新規レイアウトが適用されることが仮定されるので、プロセスは、これらの状況によってトリガされるとき、1601において開始する。後述するように、プロセスは、オーディオ活動AをリストF内に低下させることにより、M個のストリームを1602においてソートする。
【０１２９】
2つの「for」ループ1604と1605とは、後述するように、リストF上の2つの経路に対応する。第1の経路は、アプリケーション(またはセッション)開始のとき、すなわち、以前に使用されたレイアウトがない場合、1603において迂回可能である。
【０１３０】
ビュー割当てプロセスは、P個の拡大ビューを、AのP個の最高値を有するストリームに割り当て、残りのN-P個の標準ビューを、Aの次のN-P個の最高値を有するN-P個のビューに割り当てることになる。上述したように、例示的な実施形態においては、特定のレイアウトにおけるビューの割当ての順序は、ビューが属しているレイアウトテーブルエントリにそれらが入力される順序である。
【０１３１】
利用可能なストリームの数MがNよりも大きい場合は、ビュー割当てプロセスは、最も小さいオーディオ活動を有するストリームを画面から除去することが可能である。同じオーディオ活動を有するストリームがあり、除去すべきM-N個のストリームの組が、オーディオ活動単独で決定不可能な場合、ビュー割当てプロセスは好ましくは、必要な場合には、ランダムにその同順位を解決する。例えば、活動0を有する2個のストリームと、活動1を有する3個のストリームがあり、4個のストリームが除去される必要がある場合は、ビュー割当てプロセスはまず、活動0を有する2つのストリームを選択して、除去する。次いで、それは、0と1との間のランダムな数をもたらすランダムな数のジェネレータを使用する。値が、0と1/3との間である場合は、活動1を有する第1のストリームが除去され、値が、1/3と2/3との間である場合は、第2のストリームが除去される、などである。プロセスは、複数のストリームがランダムに除去される必要がある場合、繰り返すことが可能である。
【０１３２】
レイアウト開始が、NまたはPにおける変化の結果である場合、ビュー割当ては、「for」ループ1604に示されるように動作する。ビュー割当てプロセスは、P個の拡大ビューを、AのP個の最高値を有するストリームに割り当て、残りのN-P個の標準ビューを、Aの次のN-P個の最高値を有するN-P個のビューに割り当てることになる。特定のストリームを、いずれかのカテゴリにおけるビューに割り当てる場合、プロセスはまず、ストリームが、ある場合には以前に使用されたレイアウトにおいて占有したビューを有するそれぞれの候補ビューの交点の画素におけるサイズを計算することによって、新規レイアウトにおける候補ビューをランク付けする。言い換えると、最高重複を有するビューを使用することによって、ビュー割当てプロセスは、以前のレイアウトにおいて目に見えたストリームが、以前のレイアウトに物理的に近接近している新規レイアウトにおける位置を占有することになることを確実にしようと試みる。これは、特定のストリームが、ユーザの画面上の近隣の位置に移動することになることを確実にし、混乱を避ける。
【０１３３】
概して、割り当てられることになるN個のストリームのうちのすべてが、以前のレイアウトでそれらに割り当てられるビューを有していた可能性があるわけではないので、ビュー割当てプロセスは、2経路のプロセスを使用する。それはまず、オーディオ活動を低下させる順序で、以前のレイアウトでそれらに割り当てられるビューを有していたストリームを1604で処理し、それらの以前のビュー位置との最高重複を有するビューにそれらを割り当てる。次いで、それはやはり、オーディオ活動を低下させる順序で、残りのストリームを1605で処理し、残りのビューにそれらを割り当てる。
【０１３４】
M>Nの場合についてのランダム化プロセスは、図には明示しておらず、必要に応じて、ソーティング1602の一部として実行可能である。
【０１３５】
図17は、その周期的なアプリケーションの一部として、またはMの変化により(NもしくはPにおける変化はなく)、1701においてトリガされたビュー割当てプロセスの動作、すなわち、レイアウト再処理のブロック図を示している。ストリームは、リストFにおけるそれらの活動により、1702においてソートされる。トップP個は、拡大ビューに割り当てられることになる。FのトップP個のストリームのそれぞれのストリームは、活動Aを低下させる順序で処理される。「for」ループ1703には、以下の3つの状況、およびそのプロセスがどのようにそれぞれを処理するかを示している。
【０１３６】
1)現在処理されているストリームがすでに、拡大ビューを占有している場合は、そのストリームは、それを全く同じレイアウト位置で保持する。
【０１３７】
2)そのストリームがすでに、標準ビューを占有している場合は、それは、最低の活動Aを有する拡大ビューを置き換え、ひいては、それを置き換えたストリームの標準ビューに割り当てられる。置き換えられたストリームは、すでにビューを割り当てられているので、存在するならば、リストFから取り除かれる。以前に、拡大ビューを有していたストリームは、そのストリームがもはや、システムの一部でない(例えば、ある参加者が、ビデオ会議セッションから離れた)場合、F内にあることは不可能であることに留意されたい。
【０１３８】
3)ストリームがいずれのビューをも占有していない(それが、新規ストリームであるか、またはそれが以前に表示されていなかった)場合、それは、最低活動Aを有する拡大ビューを置き換え、置き換えられつつある拡大ビューは、標準ビュー候補リストG内に配置され、存在するならば、Fから取り除かれる。
【０１３９】
拡大ビューだけを割り当てられたストリームは、上述の3つの場合のうちのすべてにおいてFから取り除かれる。
【０１４０】
順次、P個のトップにランク付けされたビューを処理することによって、拡大ビューの現在の組が決定され、標準モードのビューに対して意図された割り当てられていないストリームの組F、ならびに拡大ビューからそれらのストリームを除去することから、もたらされた標準ビュー候補ストリームの組Gが生じる。リストはともに、それらが、先入れ先出し(FIFO)リストとして実装されている場合の構造によって、それらのオーディオ活動により保存されている(図示せず)。置き換えられた拡大ビューのうちのいくつかが、上述のプロセスによって、標準ビューを割り当てた可能性がある場合、利用可能な標準ビューの数は、置き換えられた拡大ビューうちのいくつかが、上述のプロセスによって、標準ビューを割り当てられた可能性があるので、N-Pよりも少なくてよいことが分かる。仮に、Q=max{N-P-|G|, 0}を利用可能な標準ビューの数とし、ただし、|x|は、リストxのサイズを示す、すなわち、|G|は、リストGのサイズを示す。Qは、3つの標準ビュースロットの数を示し、Gにおけるビューはすべてビューを割り当てられていると仮定する。典型的なレイアウトにおいては、構成Pは、N/2より小さいか、またはそれと等しいので、典型的には、Q>0であることに留意されたい。
【０１４１】
ビュー割当てプロセスは、Fにおけるストリームより、Gにおけるストリームに優先順位を与える。同時に、Fにおけるストリームがすでに、現在のレイアウトで存在する場合、それは、異なる位置に移動すべきではない。したがって、「for」ループ1704が、F内のQ個の最も高いランキングのストリームを調べる。それらのストリームがすでに、あるビューと関連付けられている場合、それらは維持され、そうでなければ、それらは、フリーの標準ビューのうちの1つを割り当てられる。最後に、プロセスは、1705において、残りの|G|標準ビューをG内のビューに割り当てる。例示的な実施形態においては、これは、1706において、ビュー割当てプロセスを完了する。
【０１４２】
例示的な実施形態においては、ビュー割当てプロセスは、最も高いオーディオ活動を有するストリームが常に、画面上に示されることを確実にする。それはまた、拡大ビューが、拡大から標準に移動して、見えないように、レイアウトから「段階的に」除去されることを確実にすることが可能である。しかし、反対の方向は、段階的である必要はなく、例えば、セッションに加えられる新規ストリームが即座に、拡大ビューを占有することが可能である(例えば、セッションだけに参加し、発話を開始した参加者)。明らかに、このビュー割当て技術の変形形態は、アプリケーションに応じて可能である。本明細書における詳細な例示的な設計は、オーディオ活動が、無言の参加者にも、またはそうでない参加者にも対応するビデオ会議のアプリケーションによく適している。
【０１４３】
上述のビュー割当てプロセスは、アプリケーションが開始された場合と同じやり方で、NまたはPが変化する場合を処理する。言い換えると、ユーザがN=3およびP=1を有するレイアウトから、N=2およびP=1に切り替える場合、プロセスは、新規レイアウトのアプリケーションの前のストリーム-ビューの関係が何であるかを考慮することはない。これは、1つのレイアウトから別のレイアウトへのビューの空間的な位置決めが非常に異なる可能性があるからである。言い換えると、概して、この例における拡大ビューは、両方のレイアウトで同じ画面の場所に、位置決めされることになる保証はない。しかし、実際には、Nにおける変動は典型的には、Mにおける変動の結果であるので、Receiverが自動的に、レイアウトを調整し、Mにおける変化は典型的に、段階的である(1つのストリームが加えられるか、または取り除かれる)ので、プロセスは、空間的位置決めを考慮に入れるために、変更可能である。
【０１４４】
ここで説明する機能は、スケーラブルなオーディオコーディングによって可能にされるSACS機能とは別個のものであり、相補的なものであることが分かる。ビデオおよびSVCSの場合と同様に、SACSは自動的に、(存在するときは)拡大ビューにはベースおよびエンハンスメントレイヤ(複数可)を、標準ビューにはベースおよびエンハンスメントレイヤを、またはベースレイヤのみを伝送し、現在のレイアウトで示されていないストリームにはオーディオを伝送しないことが可能である。SACSへのシグナリングは、特定のレイアウトが選択され、適用され次第、実行される。
【０１４５】
図12に示したように、例示的な実施形態はまた、ユーザが、画面上に示すべきビューの数を明確に指定するのではなく、システムに自動的に適切な数を選択させることを可能にする。これは特に、多数のストリームがあるセッションには有益である。この場合におけるユーザは、所望の画面サイズを選択するだけである。スタンドアロンのシステムの場合、画面サイズは、固定されると仮定することが可能である。
【０１４６】
システムの自動モードは、固定されたビューモードと全く同じやり方で働く。唯一の違いは、レイアウト選択プロセスは、利用可能なストリームの数まで、任意の数の参加者を有するレイアウトをスコアリングすることになることである。言い換えると、組Uはこの場合、N個のビューを有するレイアウトだけではなくて、1からMのビューの数を有するすべてのレイアウトを含むことになる。自動モードにおいては、ユーザはやはり、拡大ビューの数を選択することが可能である。大きいセッションに対する拡大ビューの数についての典型的な値は、0であっても、または1であってもよい。自動モードの場合における拡大ビュー割当ては、(拡大ビューの数と適合するレイアウトの中で)ベストなレイアウトが選択され、利用可能なビューの数が決定された後に、固定モードの場合と同様に動作する。
【０１４７】
レイアウトがどのようにレイアウトテーブル内で説明され、最良の適合レイアウトがどのように選択されるかの前述の説明は、長方形のビューを仮定していた。前に述べたように、レイアウトは、任意のビューサイズを含んでよい。特定の対象の場合が、図6(a)および(c)に示すように、同じサイズの6角形、または回転した6角形のビューである。概して、(隙間なく複製された場合、全平面をカバーした)2D空間をモザイクにする任意の形状が使用可能である。複製は、2次元周期格子上に生じることになる。少なくとも人の頭部のアスペクト比に適合する必要性および水平対照の必要性など、ビデオビューに関する実施上の配慮点は、形状の選択肢を制限する。例えば、ひし形は、画像の上側および下側部分を制限する可能性がある。
【０１４８】
2D格子上のモザイク形によって作成される長方形でないビューの場合、既存のレイアウトテーブルが使用可能であり、2D格子が左右対称軸の基本回転と考えられ得ることが分かる。回転した6角形の場合では、作成格子は角度45°でy軸を有する。したがって、レイアウト内の(同一サイズの)ビューのレイアウトは、長方形ブロックのケースを有するように、これらの回転軸内の基本ブロックを使用することによって決定可能である。一例としての図6(c)の7面の回転した6角形レイアウトを使用して、そのレイアウトテーブルエントリは、{3、3、{0、0}、{1、0}、{0、1}、{1、1}、{2、1}、{1、2}、{2、2}}を示す。すべてのビューは、同じサイズであるので、スケール係数を指定する必要がないことに留意されたい。あるいは、長方形ビューの場合との一貫性を維持するために、数1は、それぞれのビュー内に追加可能であることもあり得る。同じ方法論は、正6角形に適用可能であり、作成格子において、x軸は、45°だけ傾斜している。
【０１４９】
これらの特別なレイアウトと、それらの表現の異なる解釈とを識別するために、フラグがレイアウトテーブルに追加可能である。これはまた、それぞれの6角形ビューの幅、高さ、範囲についての正確な公式を使用して、長方形レイアウトの場合において先に定義したスコアリング関数を適切に適用するために、必要であり得る。
【０１５０】
種々のビュー形状またはサイズがレイアウト内に組み合わせられる場合、レイアウト説明を概括することは重要である。これらの場合は、レイアウトテーブルにおける例外として処理可能である。個々のビューサイズおよび適合スコアについての計算は、特定のレイアウトに専用の特別なコードによって実行可能である。これらの特別な場合は、特定の画面サイズに関するビューサイズおよび適合スコアを計算するレイアウトテーブルに追加されたフラグ、ならびにまた、レイアウトテーブルに追加される機能ポインタによって、識別可能である。
【０１５１】
Receiverにおいて、種々の解像度で多重ビューを同時に提案する性能は、スケーラブルなビデオコーディングおよびSVCSアーキテクチャの独自の機能である。個々のストリームの合成が、サーバではなく、Receiverによって実行されるという事実は、Receiverに、より柔軟性をもたらして、変動するストリーム解像度ならびに個々のユーザの嗜好の両方を調整する。追加の柔軟性は、4:3および16:9のピクチャアスペクト比、または概して、種々のピクチャアスペクト比を組み合わせるストリームを取り扱う際のものである。レイアウト適合プロセスにおいては、レイアウトアスペクト比rLは、パラメータCWおよびCHによって指定される最小値と最大値との範囲内にあることが可能であることを思い出されたい。画面アスペクト比が正確なストリームアスペクト比に適合しない場合は、ビュー内のストリームを位置決めするために、ストリームのピクチャは、スケーリングおよび表示前に、クロップされる必要がある。ビューiを占有するストリームに要求されるクロップは、水平に(左右)Wcrop=CWWS/2画素になり、垂直に(上下)Hcrop=CHHS/2画素になり、ただし、それぞれ、WSおよびHSはそれぞれ、ストリームのピクチャの幅およびストリームピクチャの高さである。
【０１５２】
図18(a)は、ビューアスペクト比が4:3の3つの長方形のビューを有する例示的なレイアウトを示している。上部ビューは、16:9のピクチャアスペクト比のストリームと関連付けられる。ビュー内にストリームを表示するために、ピクチャは、この例においては、左右の側のみに(Hcrop=0)クロッピングされる。クロッピングは、この例では対照である(両方の側で等しい)と示され、ストリームのピクチャをビュー内の中心に置く。
【０１５３】
クロッピングは、クロップされる範囲がやはり、ストリームのデコーダの予測ループにおいて必要とされるので、デコーディングが行われた後に、適用される。フル解像度、クロップされないピクチャがReceiverにおいて利用可能であるので、ReceiverアプリケーションのGUIは、クロッピングが水平に、または垂直にそれぞれ適用されるかどうかに応じて、ユーザが、表示されたビューを左右または上下に手動でパンすることを可能にすることができる。パンニングは、ピクチャの左右または上下の部分へとクロップされた範囲の分布に及ぶ。例示的な実施形態においては、ユーザは、いずれかの方向にそれをパンするために、ビュー内のピクチャをクリックし、ドラッグすることが可能である。この手動パンニングオプションはクロッピングを受ける任意のビューにおいてイネーブル可能である。このスキームにより、4:3のレイアウトアスペクト比をもたらす画面サイズが、4:3および16:9ストリームの両方をホスティングすることが可能であり、16:9のストリームは、水平にクロップされることになるが、ユーザはやはり、それぞれのビューのパン位置を選択して、対象の被写体物がそれぞれのビュー内に完全に示されることを確実にすることができることになる。
【０１５４】
図18(b)は、ビュー内にピクチャが中心に置かれた場合、被写体の一部(この場合、円で示す)がビューの外側にある例を示している。右側にピクチャをクリックし、ドラッグすることによって、ビューは、右側をパンされる。ストリームピクチャは、右側に移動し、次に、全被写体がビューの内側にあり、したがって、完全に目に見える。
【０１５５】
手動のパンニングに加えて、Receiverはまた、手動のズームモードを提案することが可能である。これは、ユーザが、被写体は、近隣のビュー内の被写体と類似するサイズで現れるように特定のビューをサイジングすることを望む場合、非常に有益である。ビデオ会議システムからの一例は、ReceiverがデスクトップのユーザからVGAストリームを、およびビデオ会議室内に備え付けられたHDカメラから別のストリームを受け取る場合である。室内カメラは、典型的には、デスクトップカメラよりはるかに小さいサイズで人を示すことになる。ユーザがHDストリームビュー内にズームする(パンする)ことを可能にすることによって、サイズは比較できることを可能にする。例示的な実施形態においては、ズーミングは、ビュー内でシフトクリックおよびドラッグすることによって実施可能であり、上方へのドラッグは、ズームイン動作を示し、下方へのドラッグは、ズームアウト動作を示す。
【０１５６】
手動によるユーザが動作させるモードとしてのズーミングおよびパンニングを提案することに加えて、システムが、自動パンニングおよびズーミングを提案することも可能である。システムが自動的に、ズーミングおよびパンニングのパラメータを計算することを可能にする1つのやり方は、ビューフィールド、ならびに(カメラによって計算されるか、または手動で測定される)被写体距離および位置決めについての情報を有するビデオストリームにタグを付けることである。しかし、これは、すべての状況で実用的であることは不可能である。例えば、手動のタグ付け技術は、すべてのパラメータが、再度計算される必要があるので、随意にカメラを物理的に調整することを難しくすることがあり得る。しかし、人々など、重要な被写体の存在および位置を検出するために、Receiverにおいて(後述する)技術を使用することが可能である。ビデオコンテンツが、典型的には、頭部と両肩の画像であるビデオ会議の分野においては特に、自動化シーン分析のための技術は、非常に効果的に使用可能である。
【０１５７】
ビデオ会議のシステムにおいては一般的である頭部と両肩のビデオにおける頭部の全体的な位置を検出するためのロバストな方法が、例えば、EleftheriadisおよびA.Jacquin、「Automatic Face Location Detection and Tracking for Model-Assisted Coding of Video Teleconferencing Sequences at Low Bit Rates」、Signal Processing:Image Communication、第7巻、3号、1995年9月、231〜248頁に記載され、その全体を参照によって本明細書に組み込む。特定の方法は、それぞれのピクチャ内のある位置に(頭部をモデル化する)楕円形に適合する。方法の目的は、被写体の完全な外形を得ることではなく、その全体的な場所を検出することである。種々の方法もまた、同じ効果に使用可能である。被写体の場所情報は、それが、ビュー内の被写体の場所およびサイズについての重要な情報をもたらすので、レイアウト管理の文脈において使用可能である。
【０１５８】
例示的な実施形態においては、システムは、自動パンズームモードを提案し、被写体の場所検出は、Receiverにおいて、ユーザによって選択された場合、高解像度の参加者のパンおよびズームの係数を修正するために使用される。
【０１５９】
方法は、以下のように動作する。それぞれのビューの場合(解像度にかかわりなく)、被写体の位置およびサイズは、上述したものなどの技術を使用して、デコーディングされたビデオ信号から得られる。目標被写体サイズは次いで、すべての低解像度の参加者全体にわたって被写体サイズを平均化することによって、計算される。メジアン、または最大値など、他の測定基準もまた使用可能である。次いで、高解像度ビューについてのズーム係数は、目標被写体サイズに対する高解像度の被写体サイズの比に等しいように設定される。高解像度のビューサイズは、上述のレイアウトプロセスによって決定される。高解像度ビューは次いで、高解像度のデコーディングされたピクチャを所望のサイズにクロップすることによって定められ、被写体物が、クロップされた領域内の中心に置かれることを確実にし、計算されたズーム係数によって、それをダウン/アップサンプリングし、それにより、結果生じたスケールされ、クロップされたピクチャは、割り当てられたビューに適合することになる。急激で継続的なパンまたはズームの設定変化を避けるため、パンおよびズームのパラメータは、第1の順序IIRフィルタ(x'[n]=ax[n]+(1-a)x'[n-1]、ただし、aは、0.1と設定可能である)によって制御されて、変動を抑えることが可能である。
【０１６０】
同じ方法が、6角形ビュー内のビューをパンし、ズームするために使用可能である。6角形のアスペクト比が、
【０１６１】
【数１７】
0005497020.tif 000018
【０１６２】
に等しいとき、それは、標準解像度アスペクト比4:3およびワイド画面解像度アスペクト比16:9の両方よりも小さい。結果として、自動的に画像をパンし、ズームして、ビューにおけるその配置を最適化することができることは有利である。
【０１６３】
本開示の対象により、本明細書に説明される技術は、ハードウェアとソフトウェアとの任意の適切な組合せを使用して実装可能であることが認識されるであろう。前述のレイアウト管理技術を実装し、動作させるためのソフトウェア(すなわち、命令)は、ファームウェア、メモリ、記憶装置、マイクロコントローラ、マイクロプロセッサ、集積回路、ASIC、オンラインダウンロード可能な媒体、および他の利用可能な媒体に限定されずに、含むことが可能なコンピュータ可読媒体上で実行可能である。
【符号の説明】
【０１６４】
100  システムアーキテクチャ
101  受信機
102  ネットワーク
201  サーバ
202  シグナリング経路
203  受信機
210  受信機画面
301  サーバから受信機への経路
302  サーバから受信機への経路
303  サーバから受信機への経路
305  サーバ
306  シグナリング経路
307  受信機
310  受信機のモニタ
1501  プロセス
1502  プロセス
1503  プロセス
1504  レイアウトテーブル
1505  プロセス
1506  プロセス
1507  プロセス
1508  プロセス
1509  プロセス
1601  プロセス
1602  プロセス
1603  プロセス
1604  「for」ループ
1605  「for」ループ
1701  プロセス
1702  プロセス
1703  「for」ループ
1704  「for」ループ
1705  「for」ループ
1706  プロセス
【図１】
0005497020.tif 000019
【図２】
0005497020.tif 000020
【図３】
0005497020.tif 000021
【図４】
0005497020.tif 000022
【図５】
0005497020.tif 000023
【図６】
0005497020.tif 000024
【図７】
0005497020.tif 000025
【図８】
0005497020.tif 000026
【図９】
0005497020.tif 000027
【図１０】
0005497020.tif 000028
【図１１】
0005497020.tif 000029
【図１２】
0005497020.tif 000030
【図１３】
0005497020.tif 000031
【図１４】
0005497020.tif 000032
【図１５】
0005497020.tif 000033
【図１６】
0005497020.tif 000034
【図１７Ａ】
0005497020.tif 000035
【図１７Ｂ】
0005497020.tif 000036
【図１８】
0005497020.tif 000037