特開 2024-19620 遠隔端末用の没入型テレビ会議およびテレプレゼンスのためのＲＴＣＰビューポートのシグナリングにおけるイベントベースのトリガ間隔

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024019620

(43)【公開日】2024-02-09

(54)【発明の名称】遠隔端末用の没入型テレビ会議およびテレプレゼンスのためのＲＴＣＰビューポートのシグナリングにおけるイベントベースのトリガ間隔

(51)【国際特許分類】

   H04N 7/15 20060101AFI20240202BHJP

   H04N 21/442 20110101ALI20240202BHJP

【ＦＩ】

H04N7/15

H04N21/442

【審査請求】未請求

【請求項の数】1

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023213952

(22)【出願日】2023-12-19

(62)【分割の表示】P 2022526276の分割

【原出願日】2021-04-12

(31)【優先権主張番号】63/022,394

(32)【優先日】2020-05-08

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/095,282

(32)【優先日】2020-11-11

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】ロヒト・アビシェーク

(72)【発明者】

【氏名】イーラジ・ソダガー

(57)【要約】

【課題】コンピュータコードを含む方法および装置が提供される。
【解決手段】コンピュータコードは、1つまたは複数のプロセッサに、ビューポートへのビデオ会議通話の配信を制御することと、ビデオ会議通話に関するイベントベースの閾値を設定することと、イベントに基づいてイベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定することと、イベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定することに基づいて、ビューポートへのビデオ会議通話の配信をさらに制御することと、を実行させるように構成される。
【選択図】図１

【特許請求の範囲】

【請求項1】

少なくとも1つのプロセッサによって実行される、ビデオシグナリング方法であって、
ビューポートへのビデオ会議通話の配信を制御するステップと、
前記ビデオ会議通話に関してイベントベースの閾値を設定するステップと、
イベントに基づいて前記イベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定するステップと、
前記イベントベースの閾値がトリガされたかどうか、および前記別のイベントから経過した前記時間が前記所定の時間未満であるかどうかを判定する前記ステップに基づいて、前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御するステップと、
を含むビデオシグナリング方法。

【請求項2】

前記イベントベースの閾値は、前記ビューポートの空間的方向の変化の度合いを少なくとも含む、請求項1に記載のビデオシグナリング方法。

【請求項3】

前記イベントベースの閾値がトリガされたかどうかを判定する前記ステップは、
前記ビューポートの前記空間的方向が以前の前記イベントベースの閾値の変化の度合いよりも大きく変化したかどうかを判定するステップ
を含む、請求項2に記載のビデオシグナリング方法。

【請求項4】

前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御する前記ステップは、
前記ビューポートの前記空間的方向が前記イベントベースの閾値の前記変化の度合いよりも大きく変化したと判定された場合に、前記ビデオ会議通話の少なくとも追加のマージンを前記ビューポートに配信するステップ
を含む、請求項3に記載のビデオシグナリング方法。

【請求項5】

前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御する前記ステップは、
タイマがトリガされたかどうか、または前記イベントベースの閾値がトリガされたかどうかに応じて、異なる長さのパケットを処理するステップ
を含む、請求項1に記載のビデオシグナリング方法。

【請求項6】

前記異なる長さのパケットのうち、前記タイマがトリガされた第1のパケットは、前記イベントベースの閾値がトリガされた第2のパケットよりも長い、請求項5に記載のビデオシグナリング方法。

【請求項7】

前記別のイベントから経過した前記時間が前記所定の時間未満であるかどうかを判定することに基づいて、前記イベントが前記イベントベースの閾値をトリガする頻度が頻度の閾値を超えるかどうかを判定するステップ
をさらに含む、請求項1に記載のビデオシグナリング方法。

【請求項8】

前記イベントが前記イベントベースの閾値をトリガする前記頻度が前記頻度の閾値を超えると判定したことに応答して、タイマを更新するステップ
をさらに含む、請求項7に記載のビデオシグナリング方法。

【請求項9】

前記ビューポートは、ヘッドセットおよびハンドヘルド・モバイル・デバイスのうちの少なくとも1つのディスプレイである、請求項1に記載のビデオシグナリング方法。

【請求項10】

前記ビデオ会議通話は、全方位カメラの360度のビデオデータを含む、請求項1に記載のビデオシグナリング方法。

【請求項11】

ビデオシグナリング装置であって、
コンピュータ・プログラム・コードを記憶するように構成された少なくとも1つのメモリと、
前記コンピュータ・プログラム・コードにアクセスし、前記コンピュータ・プログラム・コードの命令に従って動作するように構成された少なくとも1つのプロセッサと、
を備え、前記コンピュータ・プログラム・コードは、
前記少なくとも1つのプロセッサに、ビューポートへのビデオ会議通話の配信を制御させるように構成された制御コードと、
前記少なくとも1つのプロセッサに、前記ビデオ会議通話に関するイベントベースの閾値を設定させるように構成された設定コードと、
前記少なくとも1つのプロセッサに、イベントに基づいて前記イベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定させるように構成された判定コードと、
前記少なくとも1つのプロセッサに、前記イベントベースの閾値がトリガされたかどうか、および前記別のイベントから経過した前記時間が前記所定の時間未満であるかどうかを判定することに基づいて、前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御させるように構成された制御コードと、
を含む、ビデオシグナリング装置。

【請求項12】

前記イベントベースの閾値は、前記ビューポートの空間的方向の変化の度合いを少なくとも含む、請求項11に記載のビデオシグナリング装置。

【請求項13】

前記イベントベースの閾値がトリガされたかどうかを判定することは、
前記ビューポートの前記空間的方向が前記イベントベースの閾値の変化の度合いよりも大きく変化したかどうかを判定すること
を含む、請求項12に記載のビデオシグナリング装置。

【請求項14】

前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御することは、
前記ビューポートの前記空間的方向が前記イベントベースの閾値の前記変化の度合いよりも大きく変化したと判定された場合に、前記ビデオ会議通話の少なくとも追加のマージンを前記ビューポートに配信すること
を含む、請求項13に記載のビデオシグナリング装置。

【請求項15】

前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御することは、
タイマがトリガされたかどうか、または前記イベントベースの閾値がトリガされたかどうかに応じて、異なる長さのパケットを処理すること
を含む、請求項11に記載のビデオシグナリング装置。

【請求項16】

前記異なる長さのパケットのうち、前記タイマがトリガされた第1のパケットは、前記イベントベースの閾値がトリガされた第2のパケットよりも長い、請求項15に記載のビデオシグナリング装置。

【請求項17】

前記少なくとも1つのプロセッサに、前記別のイベントから経過した前記時間が前記所定の時間未満であるかどうかを判定することに基づいて、前記イベントが前記イベントベースの閾値をトリガする頻度が頻度の閾値を超えるかどうかを判定させるように構成された判定コード
をさらに含む、請求項11に記載のビデオシグナリング装置。

【請求項18】

前記少なくとも1つのプロセッサに、前記イベントが前記イベントベースの閾値をトリガする前記頻度が前記頻度の閾値を超えると判定したことに応答して、タイマを更新させるように構成された更新コード
をさらに含む、請求項17に記載のビデオシグナリング装置。

【請求項19】

前記ビューポートは、ヘッドセットおよびハンドヘルド・モバイル・デバイス（HMD）のうちの少なくとも1つのディスプレイである、請求項11に記載のビデオシグナリング装置。

【請求項20】

コンピュータに処理を実行させるプログラムを記憶した非一時的コンピュータ可読媒体であって、前記処理は、
ビューポートへのビデオ会議通話の配信を制御することと、
前記ビデオ会議通話に関してイベントベースの閾値を設定することと、
イベントに基づいて前記イベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定することと、
前記イベントベースの閾値がトリガされたかどうか、および前記別のイベントから経過した前記時間が前記所定の時間未満であるかどうかを判定することに基づいて、前記ビューポートへの前記ビデオ会議通話の前記配信をさらに制御することと、
を含む、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2020年5月8日に出願された米国仮特許出願第63/022,394号、および2020年11月11日に出願された米国特許出願第17/095,282号の優先権を主張し、それらの全体が参照により本明細書に明示的に組み込まれる。

【0002】

本開示は、リアルタイム・トランスポート制御プロトコル（RTCP）に関し、より詳細には、没入型テレビ会議および遠隔端末用のテレプレゼンスのためのRTCPビューポートのフィードバックシグナリングにおけるイベントベースのトリガ間隔に関する。

【背景技術】

【0003】

没入型テレビ会議は、会議のために対面での高精細ビデオおよびオーディオ体験を提供する。それは、ヘッド・マウント・ディスプレイ（HMD）デバイス／ビデオプレーヤ上での没入型ビデオのリアルタイムのマルチ・コネクション・ストリーミングをサポートする。没入型テレビ会議は、高精細のビデオおよびオーディオサービスによる本物のような通信を体験することを可能にする。これは、遠隔で会議に参加するユーザの没入体験を作り出すことを目的とする。

【0004】

IMSにおけるマルチメディア・テレフォニー・サービス（MTSI）およびIMSベースのテレプレゼンスにおけるVRサポートは、テレビ会議およびテレプレゼンス・セッションに参加する遠隔端末の没入体験のサポートを可能にする。これは、双方向オーディオおよび一方向没入型ビデオを可能にし、例えば、HMDを装着している遠隔ユーザが会議に参加し、会議室で全方位カメラによって取り込まれた没入型オーディオおよびビデオを受信するが、オーディオおよび任意選択的に2Dビデオのみを送信する。

【0005】

帯域幅および他の技術的制限により、HMDの空間的方向がリアルタイムで遠隔的に更新されるため、視点マージンの更新に関して、没入型ビデオ配信の改善が妨げられている。

【0006】

したがって、ネットワークオーバーヘッドおよびサーバ計算オーバーヘッドを伴うこのような問題に対する技術的解決策が望まれている。

【発明の概要】

【課題を解決するための手段】

【0007】

1つまたは複数の異なる技術的問題に対処するために、本開示は、例示的な実施形態による1つまたは複数のビューポートマージン更新に関して、没入型ビデオを配信しながら、ネットワークオーバーヘッドおよびサーバ計算オーバーヘッドを低減するための技術的解決策を提供する。
コンピュータ・プログラム・コードを記憶するように構成されたメモリと、コンピュータ・プログラム・コードにアクセスし、コンピュータ・プログラム・コードの命令に従って動作するように構成されたプロセッサまたは複数のプロセッサと、を備える方法および装置が含まれる。コンピュータ・プログラム・コードは、少なくとも1つのプロセッサに、ビューポートへのビデオ会議通話の配信を制御させるように構成された制御コードと、少なくとも1つのプロセッサに、ビデオ会議通話に関してイベントベースの閾値を設定させるように構成された設定コードと、少なくとも1つのプロセッサに、イベントに基づいてイベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定させるように構成された判定コードと、少なくとも1つのプロセッサに、イベントベースの閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定することに基づいて、ビューポートへのビデオ会議通話の配信をさらに制御させるように構成された制御コードと、を含む。

【0008】

例示的な実施形態によれば、イベントベースの閾値は、少なくともビューポートの空間的方向の変化の度合いを含む。

【0009】

例示的な実施形態によれば、イベントベースの閾値がトリガされたかどうかを判定することは、ビューポートの空間的方向がイベントベースの閾値の変化の度合いよりも大きく変化したかどうかを判定することを含む。

【0010】

例示的な実施形態によれば、ビューポートへのビデオ会議通話の配信をさらに制御することは、ビューポートの空間的方向がイベントベースの閾値の変化の度合いよりも大きく変化したと判定された場合に、ビューポートへのビデオ会議通話の少なくとも追加のマージンを配信することを含む。

【0011】

例示的な実施形態によれば、ビデオ会議通話のビューポートへの配信をさらに制御することは、タイマがトリガされたかどうか、またはイベントベースの閾値がトリガされたかどうかに応じて、異なる長さのパケットを処理することを含む。

【0012】

例示的な実施形態によれば、異なる長さのパケットのうち、タイマがトリガされた第1のパケットは、イベントベースの閾値がトリガされた第2のパケットよりも長い。

【0013】

例示的な実施形態によれば、コンピュータ・プログラム・コードは、少なくとも1つのプロセッサに、他のイベントから経過した時間が所定の時間未満であるかどうかに基づいて、イベントがイベントベースの閾値をトリガする頻度が頻度の閾値を超えるかどうかを判定させるように構成された判定コードをさらに含む。

【0014】

例示的な実施形態によれば、コンピュータ・プログラム・コードは、少なくとも1つのプロセッサに、イベントがイベントベースの閾値をトリガする頻度が頻度の閾値を超えると判定したことに応答して、タイマを更新させるように構成された更新コードをさらに含む。

【0015】

例示的な実施形態によれば、ビューポートは、ヘッドセットおよびハンドヘルド・モバイル・デバイス（HMD）のうちの少なくとも1つのディスプレイである。

【0016】

開示される主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。

【図面の簡単な説明】

【0017】

【図1】一実施形態による簡略図である。

【図2】一実施形態による簡略図である。

【図3】一実施形態によるデコーダに関する簡略ブロック図である。

【図4】一実施形態によるエンコーダに関する簡略ブロック図である。

【図5】一実施形態による会議通話に関する簡略図である。

【図6】一実施形態によるメッセージフォーマットに関する簡略図である。

【図7】一実施形態によるピクチャに関する簡略ブロック図である。

【図8】一実施形態による簡略フロー図である。

【図9】一実施形態による簡略フローチャートである。

【図10】一実施形態による簡略グラフ図である。

【図11】一実施形態による簡略グラフ図である。

【図12】一実施形態による簡略グラフ図である。

【図13】一実施形態による簡略グラフである。

【図14】一実施形態による概略図である。

【発明を実施するための形態】

【0018】

以下で説明する提案された特徴は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、実施形態は、処理回路（例えば、1つまたは複数のプロセッサまたは1つまたは複数の集積回路）によって実施されてもよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に格納されているプログラムを実行する。

【0019】

図1は、本開示の一実施形態による通信システム100の簡略化されたブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102、103を含んでよい。データの一方向送信のために、第1の端末103は、ネットワーク105を介して他の端末102に送信するためにローカル位置でビデオデータをコーディングしてよい。第2の端末102は、ネットワーク105から他の端末のコーディングされたビデオデータを受信し、コーディングされたデータを復号し、復元されたビデオデータを表示してよい。一方向データ送信は、メディアサービング用途などで一般的であることがある。

【0020】

図1は、例えばビデオ会議中に発生する可能性があるコーディングされたビデオの双方向送信をサポートするために提供される端末101と104の第2のペアを示す。データの双方向送信のために、各端末101および104は、ネットワーク105を介して他の端末に送信するために、ローカル位置で取り込まれたビデオデータをコーディングしてよい。各端末101および104はまた、他方の端末によって送信されたコーディングされたビデオデータを受信する場合もあり、コーディングされたデータを復号してよく、復元されたビデオデータをローカルディスプレイデバイスに表示してよい。

【0021】

図1では、端末101、102、103および104は、サーバ、パーソナルコンピュータおよびスマートフォンとして示されてよいが、本開示の原理はそのように限定されるものではない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、および／または専用のビデオ会議機器を伴う用途を見出す。ネットワーク105は、例えば有線および／または無線通信ネットワークを含む、端末101、102、103および104間で、コーディングされたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回路交換および／またはパケット交換チャネルにおいてデータを交換してよい。代表的なネットワークには、通信ネットワーク、ローカルエリア・ネットワーク、ワイドエリア・ネットワークおよび／またはインターネットが含まれる。本考察の目的のために、ネットワーク105のアーキテクチャおよびトポロジは、本明細書で以下に説明されない限り、本開示の動作にとって重要ではない場合がある。

【0022】

図2は、開示される主題のための用途の一例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルテレビ、CD、DVD、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの保存を含む、他のビデオ対応用途に等しく適用することができる。

【0023】

ストリーミングシステムは、例えば非圧縮ビデオ・サンプル・ストリーム213を作成する、例えばデジタルカメラなどのビデオソース201を含むことができるキャプチャサブシステム203を含んでよい。そのサンプルストリーム213は、符号化されたビデオビットストリームと比較して高いデータ量として強調されてよく、カメラ201に結合されたエンコーダ202によって処理することができる。エンコーダ202は、以下でより詳細に説明するように、開示される主題の態様を可能にするか、または実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。符号化されたビデオビットストリーム204は、サンプルストリームと比較してより低いデータ量として強調されてよく、将来の使用のためにストリーミングサーバ205に格納することができる。1つまたは複数のストリーミングクライアント212および207は、ストリーミングサーバ205にアクセスして、符号化されたビデオビットストリーム204のコピー208および206を取得することができる。クライアント212は、符号化されたビデオビットストリームの着信コピー208を復号し、ディスプレイ209または他のレンダリングデバイス（図示せず）上にレンダリングすることができる発信ビデオ・サンプル・ストリーム210を形成するビデオデコーダ211を含むことができる。一部のストリーミングシステムでは、ビデオビットストリーム204、206および208は、特定のビデオコーディング／圧縮規格に従って符号化することができる。これらの規格の例は、上記で言及されており、本明細書でさらに説明される。

【0024】

図3は、本発明の一実施形態によるビデオデコーダ300の機能ブロック図であり得る。

【0025】

受信機302は、デコーダ300によって復号されるべき1つまたは複数のコーデックビデオシーケンスを受信してよく、同じまたは別の実施形態では、一度に1つのコーディングされたビデオシーケンスを受信してよく、この場合、各コーディングされたビデオシーケンスの復号は、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、チャネル301から受信されてよく、チャネルは、符号化されたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信機302は、それぞれの使用エンティティ（図示していない）に転送され得る他のデータ、例えばコーディングされたオーディオデータおよび／または補助データストリームとともに、符号化されたビデオデータを受信してもよい。受信機302は、コーディングされたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ303が、受信機302とエントロピーデコーダ／パーサ304（以降、「パーサ」）との間に結合されてよい。受信機302が十分な帯域幅と制御性を持つ記憶／転送装置から、またはアイソクロナスネットワークからデータを受信している場合、バッファ303は必要ではなく、または小さくすることができる。インターネットなどのベストエフォートパケットネットワークで使用する場合、バッファ303が必要とされる場合があり、比較的大きくすることができ、有利には適応サイズとすることができる。

【0026】

ビデオデコーダ300は、エントロピーコーディングされたビデオシーケンスからシンボル313を再構築するためのパーサ304を含み得る。これらのシンボルのカテゴリには、デコーダ300の動作を管理するために使用される情報、および場合によっては、デコーダの不可欠な部分ではないが、それに結合することができるディスプレイ312などのレンダリングデバイスを制御するための情報が含まれる。（複数の）レンダリングデバイスの制御情報は、補足拡張情報（SEIメッセージ）またはビデオユーザビリティ情報パラメータセットの小部分（図示していない）の形式であり得る。パーサ304は、受信したコーディングされたビデオシーケンスを解析／エントロピー復号してよい。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術または規格に従うことができ、可変長コーディング、ハフマンコーディング、文脈依存性を伴う、または伴わない算術コーディングなどを含む、当業者によく知られた原理に従うことができる。パーサ304は、コーディングされたビデオシーケンスから、そのグループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャのグループ（GOP）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことができる。エントロピーデコーダ／パーサはまた、変換係数、量子化パラメータ値、動きベクトルなどのコーディングされたビデオシーケンス情報から抽出し得る。

【0027】

パーサ304は、シンボル313を作成するために、バッファ303から受信したビデオシーケンスに対してエントロピー復号／解析動作を実行することができる。パーサ304は、符号化されたデータを受信し、特定のシンボル313を選択的に復号してよい。さらに、パーサ304は、特定のシンボル313が、動き補償予測ユニット306、スケーラ／逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311に提供されるべきかどうかを判定してよい。

【0028】

シンボル313の再構築には、コーディングされたビデオピクチャまたはその一部のタイプ（インターピクチャおよびイントラピクチャ、インターブロックおよびイントラブロックなど）、ならびにその他の要因に応じて、複数の異なるユニットを関与させることができる。どのユニットがどのように関与しているかは、パーサ304によって、コーディングされたビデオシーケンスから解析されたサブグループ制御情報によって管理することができる。パーサ304と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。

【0029】

すでに言及した機能ブロックのほかに、デコーダ300は、以下で説明するように、いくつかの機能ユニットに概念的に再分割することができる。商業的な制約の下で動作する実際の実装形態では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合させることができる。しかしながら、開示された主題を説明するために、以下の機能ユニットへの概念的な細分化が適切である。

【0030】

最初のユニットは、スケーラ／逆変換ユニット305である。スケーラ／逆変換ユニット305は、量子化された変換係数、ならびに使用する変換、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報をパーサ304から（複数の）シンボル313として受け取る。それは、アグリゲータ310に入力することができるサンプル値を含むブロックを出力することができる。

【0031】

場合によっては、スケーラ／逆変換305の出力サンプルは、イントラコーディングされたブロックに関係する場合があり、つまり、以前に再構築されたピクチャからの予測情報は使用していないが、現在のピクチャの以前に再構築された部分からの予測情報を使用できるブロックに関係する場合がある。そのような予測情報は、イントラピクチャ予測ユニット307によって提供することができる。場合によっては、イントラピクチャ予測ユニット307は、現在の（部分的に再構築された）ピクチャ309からフェッチされた周囲のすでに再構築された情報を使用して、再構築中のブロックの同一サイズおよび同一形状のブロックを生成する。アグリゲータ310は、場合によっては、サンプルごとに、イントラ予測ユニット307が生成した予測情報をスケーラ／逆変換ユニット305によって提供されるような出力サンプル情報に追加する。

【0032】

他のケースでは、スケーラ／逆変換ユニット305の出力サンプルは、インターコーディングされた、および場合によっては動き補償されたブロックに関係する場合もある。そのようなケースでは、動き補償予測ユニット306は、参照ピクチャメモリ308にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルをブロックに関連するシンボル313に従って動き補償した後、これらのサンプル（この場合、残差サンプルまたは残差信号と呼ばれる）は、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ／逆変換ユニットの出力に追加することができる。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、動きベクトルによって制御することができ、例えば、X、Y、および参照ピクチャ成分を有し得るシンボル313の形態で動き補償ユニットが利用できるようにすることができる。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされたサンプル値の補間、動きベクトル予測機構などを含むことができる。

【0033】

アグリゲータ310の出力サンプルは、ループフィルタユニット311における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、コーディングされたビデオビットストリームに含まれるパラメータによって制御され、パーサ304からのシンボル313としてループフィルタユニット311が利用できるようになっているループ内フィルタ技術を含むことができるが、これはまた、コーディングされたピクチャまたはコーディングされたビデオシーケンスのこれまでの（復号順で）部分の復号中に取得されたメタ情報に応答し、また以前に再構築されループフィルタリングされたサンプル値に応答したりする場合もある。

【0034】

ループフィルタユニット311の出力は、レンダリングデバイス312に出力され得るだけでなく、将来のインターピクチャ予測で使用するために参照ピクチャメモリ557に記憶されるサンプルストリームにすることもできる。

【0035】

特定のコーディングされたピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用できる。コーディングされたピクチャが完全に再構築され、コーディングされたピクチャが（例えば、パーサ304によって）参照ピクチャとして識別されると、現在の参照ピクチャ309は、参照ピクチャバッファ308の一部になることができ、次のコーディングされたピクチャの再構築を開始する前に、新しい現在のピクチャメモリを再割り当てすることができる。

【0036】

ビデオデコーダ300は、ITU-T Rec. H.265などの規格で文書化され得る所定のビデオ圧縮技術に従って復号動作を実行することができる。コーディングされたビデオシーケンスは、ビデオ圧縮技術文書または規格において指定されるように、および具体的にはそこで文書化されたプロファイルにおいて指定されるように、ビデオ圧縮技術または規格の構文に準拠しているという意味において、使用されているビデオ圧縮技術または規格によって指定された構文に従ってよい。また、コンプライアンスのために必要なのは、コーディングされたビデオシーケンスの複雑さが、ビデオ圧縮技術または標準のレベルによって定義された範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒当たりのメガサンプルで測定される）、最大参照ピクチャサイズなどを、制限する。レベルによって設定される制限は、場合によっては、ハイポセティカル・リファレンス・デコーダ（HRD）仕様と、コーディングされたビデオシーケンスにおいて伝えられるHRDバッファ管理のメタデータによってさらに制限されることがある。

【0037】

一実施形態では、受信機302は、符号化されたビデオとともに追加の（冗長な）データを受信する場合がある。追加のデータは、（複数の）コーディングされたビデオシーケンスの一部として含まれる場合がある。追加のデータは、データを適切に復号する、および／または元のビデオデータをより正確に再構築するためにビデオデコーダ300によって使用されてよい。追加のデータは、例えば、時間的、空間的、または信号対雑音比（SNR）強化層、冗長スライス、冗長ピクチャ、フォワードエラー訂正コードなどの形式をとることができる。

【0038】

図4は、本開示の一実施形態によるビデオエンコーダ400の機能ブロック図であり得る。

【0039】

エンコーダ400は、エンコーダ400によってコーディングすべき（複数の）ビデオ画像を取り込むことができる（エンコーダの一部ではない）ビデオソース401からビデオサンプルを受信できる。

【0040】

ビデオソース401は、任意の適切なビット深度（例えば8ビット、10ビット、12ビット…）、任意の色空間（例えば、BT.601 Y CrCB、RGB、…）、および任意の適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタル・ビデオ・サンプル・ストリームの形態で、エンコーダ（303）によってコーディングすべきソースビデオシーケンスを提供できる。メディア供給システムでは、ビデオソース401は、これまでに準備されたビデオを格納する記憶装置であり得る。ビデオ会議システムでは、ビデオソース401は、ローカル画像情報をビデオシーケンスとして取り込むカメラである場合もある。ビデオデータは、順番に見たときに動きを与える複数の個別のピクチャとして提供され得る。ピクチャ自体は、画素の空間アレイとして編成することができ、各画素は、使用中のサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含み得る。当業者であれば、画素とサンプルとの関係を容易に理解することができる。以下の説明はサンプルに焦点を当てている。

【0041】

一実施形態によれば、エンコーダ400は、リアルタイムで、または用途によって必要とされる他の時間制約下で、ソースビデオシーケンスのピクチャを、コーディングされたビデオシーケンス410に、コーディングし圧縮できる。適切なコーディング速度にすることが、コントローラ402の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、結合は図示していない。コントローラによって設定されるパラメータには、レート制御関連パラメータ（ピクチャスキップ、量子化、レート歪み最適化手法のラムダ値など）、ピクチャサイズ、ピクチャグループ（GOP）レイアウト、最大動きベクトル検索範囲などを含めることができる。当業者であれば、コントローラ402の他の機能は、それらが特定のシステム設計のために最適化されたビデオエンコーダ400に関連し得るため、容易に特定することができる。

【0042】

一部のビデオエンコーダは、当業者が「コーディングループ」として容易に認識するもので動作する。過度に簡略化された説明として、コーディングループは、エンコーダ402（以後は「ソースコーダ」）（コーディングすべき入力ピクチャおよび（複数の）参照ピクチャに基づいてシンボルを作成する役割を担う）のコーディング部分と、（遠隔）デコーダも同様に作成するであろう（開示された主題で考慮されるビデオ圧縮技術では、シンボルとコーディングされたビデオビットストリームとの間の任意の圧縮が可逆的であるため）サンプルデータを作成するためにシンボルを再構築する、エンコーダ400に埋め込まれた（ローカル）デコーダ406と、で構成することができる。再構築されたサンプルストリームは、参照ピクチャメモリ405に入力される。シンボルストリームの復号は、デコーダの場所（ローカルまたはリモート）に関係なくビットイグザクト結果をもたらすため、参照ピクチャバッファコンテンツもまた、ローカルエンコーダとリモートエンコーダとの間でビットイグザクトである。言い換えると、エンコーダの予測部分は、復号中に予測を使用するときにデコーダが「見る」のとまったく同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期性（および、例えばチャネルエラーのために同期性を維持できない場合に生じるドリフト）のこの基本原理は、当業者によく知られている。

【0043】

「ローカル」デコーダ406の動作は、「リモート」デコーダ300の動作と同じであってよく、これは、図3に関連して上記で詳細にすでに説明されている。しかしながら、図4も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ408およびパーサ304によるコーディングされたビデオシーケンスへのシンボルのコーディング／復号は可逆であり得るため、チャネル301、受信機302、バッファ303およびパーサ304を含むデコーダ300のエントロピー復号化部分は、ローカルデコーダ406に完全には実装されない場合がある。

【0044】

この時点で行うことができる観察は、デコーダに存在する解析／エントロピー復号以外のデコーダ技術も、対応するエンコーダにおいて、実質的に同一の機能形式で必ず存在する必要があるということである。エンコーダ技術の説明は、包括的に説明されているデコーダ技術の逆であるため、省略できる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。

【0045】

その動作の一部として、ソースコーダ403は、動き補償予測コーディングを実行してよく、これは、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前にコーディングされたフレームを参照して、入力フレームを予測的にコーディングする。この方法において、コーディングエンジン407は、入力フレームのピクセルブロックと、入力フレームへの（複数の）予測参照として選択され得る（複数の）参照フレームのピクセルブロックとの差をコーディングする。

【0046】

ローカルビデオデコーダ406は、ソースコーダ403によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコーディングされたビデオデータを復号してよい。コーディングエンジン407の動作は、非可逆処理であることが有利であり得る。コーディングされたビデオデータがビデオデコーダ（図4には示されていない）で復号され得るとき、再構築されたビデオシーケンスは通常、いくつかのエラーを伴うソースビデオシーケンスの複製であり得る。ローカルビデオデコーダ406は、参照フレームに対してビデオデコーダによって実行され得る復号処理を複製し、再構築された参照フレームを参照ピクチャキャッシュ405に記憶させてよい。この方法において、エンコーダ400は、（送信エラーがない限り）遠端のビデオデコーダによって取得されるであろう再構築された参照フレームとして共通のコンテンツを有する再構築された参照フレームのコピーをローカルに格納してよい。

【0047】

予測器404は、コーディングエンジン407の予測検索を実行してよい。すなわち、コーディングすべき新しいフレームについて、予測器404は、サンプルデータ（候補参照ピクセルブロックとしての）、または新しいピクチャの適切な予測参照として機能し得る、参照ピクチャの動きベクトル、ブロック形状などの特定のメタデータについて参照ピクチャメモリ405を検索してよい。予測器404は、適切な予測参照を見つけるために、ピクセルブロックごとのサンプルブロックに基づいて動作してよい。場合によっては、予測器404によって得られた検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ405に格納された複数の参照ピクチャから引き出された予測参照を有してよい。

【0048】

コントローラ402は、例えば、ビデオデータを符号化するために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ403のコーディング動作を管理してよい。

【0049】

すべての前述の機能ユニットの出力は、エントロピーコーダ408でエントロピーコーディングを受ける場合がある。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを無損失圧縮することにより、様々な機能ユニットによって生成された記号をコーディングされたビデオシーケンスに変換する。

【0050】

送信機409は、エントロピーコーダ408によって作成された（複数の）符号化されたビデオシーケンスをバッファリングして、通信チャネル411を介した送信のためにそれを準備することができ、この通信チャネルは、符号化されたビデオデータを格納する記憶装置へのハードウェア／ソフトウェアリンクであってよい。送信機409は、ビデオコーダ403からのコーディングされたビデオデータを、送信すべき他のデータ、例えばコーディングされたオーディオデータおよび／または補助データストリーム（ソースは図示せず）と合体させてもよい。

【0051】

コントローラ402は、エンコーダ400の動作を管理してよい。コーディング中に、コントローラ405は、各コーディングされたピクチャに特定のコーディングピクチャタイプを割り当ててよく、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼす可能性がある。例えば、ピクチャは多くの場合、次のフレームタイプのいずれかとして割り当てられ得る。

【0052】

イントラピクチャ（Iピクチャ）は、予測のソースとしてシーケンス内の他のフレームを使用せずにコーディングおよび復号され得るものであり得る。一部のビデオコーデックでは、例えば、独立デコーダ・リフレッシュ・ピクチャ（Independent Decoder Refresh Picture）など、様々なタイプのイントラピクチャを使用できる。当業者は、Iピクチャの変形、および、それらのそれぞれの用途および機能を認識している。

【0053】

予測ピクチャ（Pピクチャ）は、各ブロックのサンプル値を予測するために、最大1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用して、コーディングおよび復号され得るものであり得る。

【0054】

双方向予測ピクチャ（Bピクチャ）は、各ブロックのサンプル値を予測するために、最大2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用して、コーディングおよび復号され得るものであり得る。同様に、複数予測ピクチャは、単一ブロックの再構成のために3つ以上の参照ピクチャおよび関連するメタデータを使用し得る。

【0055】

ソースピクチャは、一般に、空間的に複数のサンプルブロック（例えば、各々4×4、8×8、4×8、または16×16サンプルのブロック）に細分され、ブロックごとにコーディングされ得る。ブロックは、ブロックのそれぞれのピクチャに適用されたコーディング割り当てによって決定されるように、他の（すでにコード化された）ブロックを参照して予測的にコーディングされ得る。例えば、Iピクチャのブロックは、非予測的にコーディングされ得るか、または同じピクチャのすでにコーディングされたブロックを参照して予測的にコーディングされ得る（空間予測またはイントラ予測）。Pピクチャの画素ブロックは、空間予測を介して、または以前にコーディングされた1つの参照ピクチャを参照する時間予測を介して、非予測的にコーディングされ得る。Bピクチャのブロックは、空間予測を介して、または以前にコーディングされた1つまたは2つの参照ピクチャを参照する時間予測を介して、非予測的にコーディングされ得る。

【0056】

ビデオコーダ400は、ITU-T Rec. H.265などの所定のビデオのコーディング技術または規格に従ってコーディング動作を実行することができる。その動作において、ビデオコーダ400は、入力ビデオシーケンスの時間的および空間的冗長性を活用する予測コーディング動作を含む、様々な圧縮動作を実行することができる。従って、コーディングされたビデオデータは、使用されているビデオコーディング技術または標準によって指定されたシンタックスに準拠していることがある。

【0057】

一実施形態では、送信機409は、符号化されたビデオとともに追加データを送信してもよい。ソースコーダ403は、そのようなデータを、コーディングされたビデオシーケンスの一部として含む場合がある。追加データは、時間的／空間的／SNRエンハンスメント層、冗長なピクチャおよびスライスなどの他の形式の冗長データ、補足強化情報（SEI）メッセージ、視覚的有用性情報（VUI）パラメータセットフラグメントなどを含み得る。

【0058】

図5は、例示的な実施形態による、360度の会議通話などの通話500を示す。図5を参照すると、会議通話が部屋501で行われている。部屋501は、部屋501に物理的に存在する人々、全方位カメラ505、およびビュー画面502からなる。他の2人の人物503および504が会議に参加し、例示的な実施形態によれば、人物503はVRおよび／またはARヘッドセットを使用していてもよく、人物504はスマートフォンまたはタブレットを使用していてもよい。人物503および504は、全方位カメラ505を介して会議室の360度ビューを受信し、受信したビューは、それぞれの人物503および504であってもよく、例えば、特定のビュー画面の方向に対する360度ビューの異なる部分を見ているどうかにかかわらない。遠隔参加者、例えば人物503および504は、互いのカメラ供給画像に焦点を合わせるオプションも有する。図5では、人物503および504は、ビューポート情報507および508をそれぞれ部屋501、または全方位カメラ505およびビュー画面502に関連する他のネットワークデバイスに送信し、これらは次に、ビューポート依存ビデオ509および510をそれぞれ送信する。

【0059】

会議に参加している遠隔ユーザ、例えばヘッド・マウント・ディスプレイ（HMD）を装着している人物503は、全方位カメラによって取り込まれた会議室からステレオまたは没入型音声／オーディオ、および没入型ビデオを遠隔受信する。人物504はまた、HMDを着用してもよく、またはスマートフォンもしくはタブレットなどのハンドヘルド・モバイル・デバイスを使用してもよい。

【0060】

例示的な実施形態によれば、全方位メディアフォーマット（OMAF）は、（i）ビューポート非依存型、および（ii）ビューポート依存型の2つのタイプのメディアプロファイルを定義する。ビューポート非依存ストリーミング（VIS）を使用する場合、ビデオ全体はユーザのビューポートに関係なく高品質で送信される。VISが使用される場合、HMD移動中に待ち時間は発生しない。しかしながら、帯域幅要件は比較的高い場合がある。

【0061】

高解像度没入型ビデオ全体を所望の品質でストリーミングすることは、ユーザの視野（FoV）が制限される可能性があるため、ネットワーク帯域幅の制限、復号の複雑さ、およびエンドデバイスの計算上の制約のために効率が悪い場合がある。したがって、例示的な実施形態によれば、ビューポート依存ストリーミング（VDS）は、全方位メディアフォーマット（OMAF）で定義されている。VDSが使用される場合、ユーザの現在のビューポートのみが高品質でストリーミングされ、残りは比較的低い品質でストリーミングされる。これは、かなりの量の帯域幅を節約するのに役立つ。

【0062】

VDSを使用している間、遠隔ユーザ、例えば人物503および504は、RTCP報告を介してビューポート方向情報を送信することができる。これらのレポートは、固定間隔、イベントベースのトリガ、または一定の間隔およびイベントベースのトリガを含むハイブリッド方式を使用して送信することができる。

【0063】

例示的な実施形態によれば、イベントベースのフィードバックは、ビューポートが変更され、即時フィードバックが送信されるときはいつでもトリガされる。RTCP報告の頻度は、HMDの速度に依存し、HMD速度が増加するにつれて増加する。

【0064】

ここで、HMD速度が大きく、フィードバックトリガ角度が比較的短い場合、多数のイベントベースのRTCP報告が生成され、サーバに送信される。これにより、必要な帯域幅がRTCP 5％の帯域幅制限を超える可能性がある。例えば、図10を参照すると、20 Mbpsビデオのポイント・ツー・ポイント・シナリオの図表1000について、フィードバックトリガが0.1度であり、HMD速度が毎秒125度を超える場合、送信されるべきRTCP報告に必要な帯域幅は、1 MbpsのRTCP帯域幅制限を超える。図10は、0.1度、0.5度、1度、および2度のトリガに対して生成されたイベントベースのRTCPフィードバックを示す。

【0065】

図8のS803などで、会議室801と遠隔ユーザ802との間で、IMS（MTSI）通話シグナリングのための通常のマルチメディア・テレフォニー・サービスに加えて、通話セットアップ中に、ユーザの初期ビューポート方向、復号／レンダリングメタデータ、および取り込まれた視野は、セッション記述プロトコル（SDP）でシグナリングされる。通話確立後、遠隔当事者は、RTCP報告を介してビューポート方向情報を送信する。

【0066】

RTCPフィードバックは、例示的な実施形態による5％帯域幅ルールに従うことができる。したがって、RTCPの頻度は、グループサイズまたは遠隔参加者の数に依存する。グループサイズが大きくなるにつれて、帯域幅使用制限を遵守するためにフィードバックをあまり頻繁に送信することができない。遠隔参加者の数が少ない場合、即時フィードバックを使用することができる。参加者の数が増加するにつれて、早期のRTCPフィードバックを使用することができる。しかしながら、グループサイズが大きくなると、通常のRTCPフィードバックが送信されるべきである。インターネット技術タスクフォース（IETF）のコメント要求（RFC）3550に従って、RTCPの最小送信間隔は5秒でもよい。グループサイズが増加すると、RTCPフィードバック間隔も増加し、追加の遅延が生じる可能性がある。本明細書の例示的な実施形態によれば、例えば没入型ビデオで使用するために、RTCP報告は、固定間隔ベースおよびイベントベースのいずれかで送信することができ、これは、図5の人物503および／または人物504などの遠隔人物ごとのビューポート方向の変化によってトリガすることができる。

【0067】

例示的な実施形態によれば、RTCPフィードバックパケットは、状態報告およびフィードバック（FB）メッセージからなる複合パケットであってもよい。さらに、送信者報告（SR）／受信報告（RR）パケットは、他のメッセージに加えてソース記述を含む複合RTCPパケットの一部として、一定の間隔で送信される状況報告を含む。

【0068】

例示的な実施形態によれば、FBメッセージを含む複合RTCPパケット内のRTCPパケットの順序は、
－ オプションの暗号化されたプレフィックス、
－ 必須のSRまたはRR、
－ 必須のSDES、
－ 1または複数のFBメッセージ
である。

【0069】

複合パケットでは、FBメッセージは、RRおよびソース記述RTCPパケット（SDES）の後に配置され得る。

【0070】

フィードバックパケットを搬送する2つの複合RTCPパケットは、最小複合RTCPフィードバックパケットおよび完全複合RTCPフィードバックパケットと、記述することができる：

【0071】

RTCPフィードバックメッセージは、IETF 4585で指定されている。これは、PT（ペイロードタイプ）＝PSFB（206）によって識別することができ、PSFBは、ペイロード固有フィードバックメッセージ（payload-specific feedback message）を指す。例示的な実施形態によれば、フィードバックメッセージは、通常の間隔およびイベントベースの両方のビューポート情報のシグナリングを含むことができる。

【0072】

図1の人物503および人物504のうちの1人などの任意の遠隔参加者が（それぞれのディスプレイデバイスの空間的方向を変更するなどして）、そのそれぞれのビューポートを変更するとき、RTCPビューポートフィードバックは適時に配信されるべきであり、そうでなければ遅延を引き起こし、そのユーザの高品質VR体験に影響を与える。遠隔参加者の数が増加するにつれて、RTCPフィードバック間隔は増加する。通常のRTCPフィードバック間隔が、5秒単位などで単独で送信される場合、遠隔参加者の数が増加するにつれて遅延する可能性がある。したがって、例示的な実施形態によれば、RTCP間隔は、そのような技術的欠陥を改善するために、通常のフィードバック間隔とイベントベースの間隔との組み合わせであってもよい。

【0073】

例示的な実施形態によれば、連続送信間の最小RTCP間隔（Tmin）が5秒であるべきであるRTPルールに準拠する複合RTCPパケットとして、通常のRTCPフィードバック間隔は送信されるべきである。このRTCP間隔は、RTCPパケットサイズおよび利用可能なRTCP帯域幅から導出することができる。完全複合パケットは、追加の受信機報告、追加のSDES項目などの任意の追加のRTCPパケットを含む。

【0074】

ビューポートが変化すると、イベントベースのフィードバックがトリガされる。この場合、最小の複合RTCPパケットが送信され得る。最小複合RTCPフィードバックパケットは、必要な暗号化プレフィックス、正確な1つのSRまたはRR、正確な1つのSDES（CNAME項目のみが存在する）、およびFBメッセージなどの必須情報のみを含む。これは、フィードバックのために送信されるRTCPパケットを最小限に抑えるのに役立ち、したがって、帯域幅に対する影響は最小限になる。イベントベースのフィードバックは、通常のRTCPフィードバック間隔とは異なり、グループサイズの影響を受けない。

【0075】

図7のように、ユーザがビューポート701を変更すると、イベントベースのフィードバックがトリガされ、通常のフィードバック間隔は最小間隔（Tmin）の後に開始する必要がある。ここで、ユーザが最小間隔の前にビューポート701を変更すると、イベントベースのフィードバックが再びトリガされる。これは、これらのイベントが連続して発生する場合、5％帯域幅ルールに影響を及ぼす可能性がある。しかしながら、イベントベースのフィードバックに最小間隔の制約を課すと、ユーザの体験が低下する。したがって、送信されるべきイベントベースのフィードバックのために定義された最小間隔は存在しないはずである。RTCPフィードバックの帯域幅使用量を考慮するために、通常のフィードバックの間隔は増加させることができ、したがって、イベントベースのフィードバックの頻度およびそれらの間隔に依存すべきである。

【0076】

本明細書に記載の例示的な実施形態を考慮して、ユーザは、M2HQ遅延などの遅延を最小限に抑え、ユーザ体験を向上させるために、ビューポート701の周りに、図7のイラスト700の702などの追加のより高い品質マージンを要求することができる。ビューポート701は、図5の遠隔人物503および504のデバイスのいずれかのビューポートであり得る。これは、遠隔人物503および504の一方が小さな頭部運動の摂動を実行しているときに非常に有用である。しかしながら、図8のS805のような通話中に、ユーザがビューポートマージン702から外れている（無視できるほど）小さな程度だけ頭を動かした場合、マージン外ビューポート領域は比較的無視できるので、イベントベースのフィードバックはトリガされるべきではなく、したがって通常のフィードバックが送信されるのを待つべきである。したがって、イベントベースのフィードバックをトリガすることができる前に、ヨー、ピッチ、およびロールに対してある程度の許容誤差703が定義されてもよく、例えば、図8のS804を参照すると、許容誤差情報が遠隔ユーザ802から会議室801に送信されてもよい。イベントベースのフィードバック許容誤差マージン705を含む許容誤差情報であるこの許容誤差703の度合いは、ユーザのビューポートからの回転角度ヨー（tyaw）、ピッチ（tpitch）、およびロール（troll）のうちの1つまたは複数として定義することができる。そのような情報は、図8のように初期SDPセッションS804中に、またはS806などの実施形態によるセッションの間にネゴシエートすることができる。

【0077】

図6は、例示的な実施形態による、本明細書に記載のそのようなフィードバックメッセージのフォーマット600を示す。

【0078】

図6は、RTCPフィードバック・メッセージ・フォーマット600を示す。図6では、FMTはフィードバック・メッセージ・タイプを示し、PTはペイロードタイプを示す。RTCPフィードバックメッセージに関して、FMTは、値「9」に設定されてもよく、PTは206に設定される。FCI（フィードバックメッセージ制御情報）は、ビューポート情報を含み、例示的な実施形態にしたがって、以下のパラメータから構成される。
ビューポート方位角（Viewport_azimuth）、ビューポート仰角（Viewport_elevation）、ビューポート傾斜（Viewport_tilt）、ビューポート方位角範囲（Viewport_azimuth_range）、ビューポート仰角範囲（Viewport_elevation_range）、ビューポート立体視（Viewport_stereoscopic）。

【0079】

図9は、フローチャート900を示す。S901として、図8のS803などでの初期化を含む通話設定901があり、一実施形態によれば、ユーザのビューポート方向、復号／レンダリングメタデータ、および取り込まれた視野は、IMS（MTSI）通話シグナリングのための通常のマルチメディア電話サービスに加えて、通話設定中にセッション記述プロトコル（SDP）でシグナリングされる。このS901では、上述したように、許容誤差の度合いを設定することができる。

【0080】

通話確立後、S902において、遠隔当事者は、通話の開始とともにRTCP報告を介して、それらのビューポート方向情報を送信する。次に、S903において、トリガされるイベントベースのフィードバックがあるかどうか、および通常のフィードバック間隔がトリガされるかどうか、を判定することができる。通常のフィードバック間隔は、例えば5秒などのある期間が経過したかどうかを時間ベースのフィードバックとして判定することによってトリガすることができる。イベントベースのフィードバックは、遠隔ユーザのビューポートが空間的方向で変更されたかどうか、および変更された場合、その変更が、図7の許容誤差マージン705に関してなど、予め設定された許容誤差範囲内にあるかまたは超えているかどうかによって判定することができる。

【0081】

S905で時間ベースのフィードバックが判定された場合、複合RTCPパケットを送信することができる。例示的な実施形態によれば、連続送信間の最小RTCP間隔（Tmin）が5秒であるべきであるRTPルールに準拠する複合RTCPパケットとして、通常のRTCPフィードバック間隔は送信されるべきである。このRTCP間隔は、RTCPパケットサイズおよび利用可能なRTCP帯域幅から導出することができる。完全複合パケットは、追加の受信機報告、追加のSDES項目などの任意の追加のRTCPパケットを含む。その後、S904において、許容誤差情報に対する何らかの更新のユーザ入力または他の入力があるかどうかを判定することができ、そうでない場合、処理は、S905の複合RTCPパケットに関して受信された任意の通信に従って、S902において通話をループまたは他の方法で進めることができる。このS905はまた、5秒などの別の期間をカウントするためにタイマをリセットすることができる。

【0082】

S906でイベントベースのフィードバックが判定された場合、最小のRTCPパケットが送信され得る。例えば、ビューポートが変化すると、イベントベースのフィードバックがトリガされる。この場合、最小の複合RTCPパケットが送信され得る。最小複合RTCPフィードバックパケットは、必要な暗号化プレフィックス、正確な1つのSRまたはRR、正確な1つのSDES（CNAME項目のみが存在する）、およびFBメッセージなどの必須情報のみを含む。これは、フィードバックのために送信されるRTCPパケットを最小限に抑えるのに役立ち、したがって、帯域幅に対する影響は最小限になる。イベントベースのフィードバックは、通常のRTCPフィードバック間隔とは異なり、グループサイズの影響を受けない。その後、S904で、許容誤差情報に対する何らかの更新のユーザ入力または他の入力があるかどうかが判定されてもよく、そうでない場合、処理は、S906の最小RTCPパケットに関して受信された任意の通信に従って、S902で通話をループまたは他の方法で進めることができる。このS906はまた、5秒などの別の期間をカウントするためにタイマをリセットすることができる。さらに、例えば図10、図11、図12、および図13に関してさらに説明したような実施形態によるRTCPの5％帯域幅ルールの超過に寄与するなど、イベントベースのトリガの頻度が閾値を超えるS906においても判定された場合には、S904において、S906から、増加した経過時間をカウントするためにタイマを更新するかどうかを判定することもできる。

【0083】

例示的な実施形態は、帯域幅要件がRTCP帯域幅制限を超えず、S904で更新または他の方法で考慮され得るように、2つの連続するイベントベースのRTCPフィードバック、例えば中間S905のないS906～S906の間の最小間隔を定義するためのパラメータを導入する。

【0084】

S906で比較的短いフィードバックトリガが大きなHMD運動に使用される場合、RTCP帯域幅要件はRTCP帯域幅制限を超える可能性がある。したがって、イベントベースのRTCP報告の帯域幅要件は、例示的な実施形態によるHMD速度およびフィードバックトリガの度合いに依存し得る。

【0085】

イベントベースのフィードバック間隔は、2つの連続するトリガ間の時間間隔である。HMD速度が増加すると、イベントベースのフィードバック間隔が減少し、帯域幅要件が増加する。イベントベースのフィードバックは、以下のように定義することができる。

【0086】

【数1】

【0087】

したがって、5％RTCPルールに準拠するように帯域幅要件を制限するために、閾値パラメータが定義される。この閾値パラメータは、イベントベースのフィードバック間隔に依存し得る。

【0088】

例示的な実施形態によれば、以下の仮定を行うことができる。
帯域幅（bps）＝B （式2）
RTCP割り当て帯域幅（bps）＝R_B （式3）
RTCPパケットサイズ（byte）＝P （式4）
RTCP最小間隔＝I_min （式5）
RTCP帯域幅は、RTCPルールに従って5％帯域幅を超えるべきではない。従って、
R_B＝0.05B （式6）
一方、I_minは以下のように表すことができる。

【0089】

【数2】

【0090】

総帯域幅を20 Mbpsと仮定すると、フィードバック度合いが0.1度であり、HMD速度が125度／秒を超える場合、帯域幅値は5％RTCP帯域幅制限を超える。図10の図表1000から分かるように、しかしながら、この値は、トリガが0.5、1、および2に増加する場合の制限内に十分にある。

【0091】

0.1度、0.5度、1度、および2度トリガに関して、1秒間に送信されるイベントベースのRTCPフィードバックの数が、図11の図表1100に示されている。したがって、RTCP帯域幅制限を考慮して、例示的な実施形態は、RTCPイベントベースのフィードバック間隔を増加させ、2つの連続するRTCPフィードバック間の最小間隔として定義することができ、

【数3】

のように選択することができるパラメータI_minを導入することができる。

【0092】

HMD速度が増加すると、1秒当たりのトリガの数も増加し、トリガ間隔の減少およびRTCPビットレートの増加をもたらす。トリガ間隔が最小点I_minに達すると、それ以上減少させるべきではなく、したがって、図12の図表1200に点線の曲線で示すように、最大トリガ数／秒に達する。図12は、一実施形態による、I_minパラメータが導入された後の0.1度、0.5度、1度、および2度のトリガに対して生成されたイベントベースのRTCPフィードバックを示す。RTCP帯域幅（R_B）が帯域幅の5％に近いがそれを超えない場合、この最小点に達する。したがって、I_minパラメータは、許容されるRTCP帯域幅に依存する。0.1度トリガの最小パラメータの導入前後のビットレートを図13の図表1300に示す。したがって、最小点I_minに達した後、グラフは平坦化する。

【0093】

さらに図13を参照すると、I_minは、一定のヘッド速度について計算され、一実施形態によるI_minパラメータが導入される前後の0.1度トリガのビットレートを指す。しかし、頭部の移動時間が比較的短いため、平均的な頭部速度と一定の頭部速度との差は無視できる。

【0094】

例示的な実施形態によれば、通常の間隔およびイベントベースのトリガからなるそのようなハイブリッド報告方式が使用される場合、
（i）通常の間隔は、RTCP最小間隔（通常は倍数）以上でなければならない。
（ii）トリガ閾値角度およびRTCP最小間隔は次のように選択されるべきである。

【0095】

【数4】

【0096】

図10、図11、図12、および図13に関して上述したそのような計算のうちの1つまたは複数は、図9のS904で実行することができる。

【0097】

したがって、本明細書に記載の例示的な実施形態によって、上記で指摘した技術的問題は、これらの技術的解決策の1つまたは複数によって有利に改善され得る。例えば、2つの連続するトリガ間の最小間隔として定義されるパラメータI_minが、イベントベースのRTCPフィードバックのために導入されるべきである。これは、1秒当たりに送信されるイベントベースのトリガの数を制限することによって、帯域幅要件を抑制するのに役立つ。したがって、頭部運動が増加し、RTCP間隔が最小（Imin）値に達すると、ビットレートは飽和し、それ以上増加しない。

【0098】

上述した技術は、コンピュータ可読命令を使用し、1つまたは複数のコンピュータ可読媒体に物理的に格納されたコンピュータソフトウェアとして、または特別に構成された1つまたは複数のハードウェアプロセッサによって、実施することができる。例えば、図14は、開示された主題の特定の実施形態を実装するのに適したコンピュータシステム1400を示している。

【0099】

コンピュータソフトウェアは、任意の適切な機械コードまたはコンピュータ言語を使用してコーディングでき、アセンブリ、コンパイル、リンク、または同様のメカニズムの対象となり、コンピュータ中央処理装置（CPU）、グラフィック処理装置（GPU）などによる直接、または解釈、マイクロコード実行などを通じて実行できる命令を含むコードを作成する。

【0100】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む様々な種類のコンピュータまたはその構成要素上で実行することができる。

【0101】

コンピュータシステム1400について図14に示される構成要素は、事実上例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲または機能に関する制限を示唆することを意図するものではない。構成要素の構成も、コンピュータシステム1400の例示的な実施形態に示される構成要素のいずれか1つまたは組み合わせに関連する、依存関係または要件を有すると解釈されるべきではない。

【0102】

コンピュータシステム1400は、特定のヒューマン・インターフェース入力デバイスを含んでよい。そのようなヒューマン・インターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（音声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（図示せず）を介して、1人または複数の人間ユーザによる入力に応答することができる。ヒューマン・インターフェース・デバイスを使用して、音声（スピーチ、音楽、環境音など）、画像（走査した画像、静止画像カメラから得られる写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係しない特定の媒体をキャプチャすることもできる。

【0103】

入力ヒューマン・インターフェース・デバイスには、キーボード1401、マウス1402、トラックパッド1403、タッチスクリーン1410、ジョイスティック1405、マイク1406、スキャナー1408、カメラ1407のうちの1つまたは複数（各々の1つのみが図示される）が含まれてよい。

【0104】

コンピュータシステム1400は、特定のヒューマン・インターフェース出力デバイスも含んでよい。そのようなヒューマン・インターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚を通じて、1人または複数の人間のユーザの感覚を刺激し得る。そのようなヒューマン・インターフェース出力デバイスには、触覚出力デバイス（例えば、タッチスクリーン1410、またはジョイスティック1405による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスが存在する可能性もある）、音声出力デバイス（スピーカ1409、ヘッドホン（図示していない）など）、視覚的出力デバイス（CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン1410であり、各々にタッチスクリーン入力機能を備えたものと、備えていないものがあり、各々に触覚フィードバック機能の備えたものと、備えていないものがあり、その一部は、ステレオグラフィック出力、仮想現実の眼鏡（図示していない）、ホログラフィックディスプレイおよびスモークタンク（図示していない）などの手段を介して二次元の視覚的出力、または三次元を超える出力を出力することが可能であり得る）、ならびに、プリンタ（図示していない）が含まれてよい。

【0105】

コンピュータシステム1400はまた、人間がアクセス可能な記憶装置と、それらに関連付けられた媒体、例えば、CD／DVD1411または同様の媒体を備えたCD／DVD ROM／RW1420、サムドライブ1422、取り外し可能なハードドライブまたはソリッド・ステート・ドライブ1423、テープおよびフロッピー（登録商標）ディスク（図示していない）などのレガシー磁気媒体、セキュリティ・ドングル（図示していない）などの専用のROM／ASIC／PLDベースのデバイスを含む光学媒体などを含み得る。

【0106】

当業者はまた、ここで開示される主題に関連して使用される「コンピュータ可読媒体」という用語は、送信媒体、搬送波、または他の一時的な信号を包含しないことを理解するべきである。

【0107】

コンピュータシステム1400は、1つまたは複数の通信ネットワーク1498へのインターフェース1499も含むことができる。ネットワーク1498は、例えば、無線、有線、光であり得る。さらに、ネットワーク1498は、ローカル、広域、大都市圏、車両および産業、リアルタイム、遅延耐性などである場合がある。ネットワーク1498の例としては、イーサネット（登録商標）などのローカルエリア・ネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルテレビ、衛星テレビおよび地上波放送を含むTV有線または無線広域デジタルネットワーク、CANBusなどを含む車両用および産業用などが含まれる。特定のネットワーク1498は一般に、特定の汎用目的のデータポートまたは周辺バス（1450および1451）（例えば、コンピュータシステム1400のUSBポートなど）に結合された外部のネットワークインターフェースアダプタを必要とし、その他のものは一般に、以下に説明するようにシステムバスへの結合によってコンピュータシステム1400のコアに統合される（例えば、PCコンピュータシステムへのイーサネット（登録商標）インターフェースまたはスマートフォン・コンピュータ・システムへのセルラー・ネットワーク・インターフェース）。これらのネットワーク1498のいずれかを使用して、コンピュータシステム1400は他のエンティティと通信することができる。そのような通信は、単方向受信のみ（例えば、放送TV）、単方向送信のみ（例えば、CANbusから特定のCANbusデバイスへ）、または双方向、例えばローカルエリアまたはワイドエリア・デジタル・ネットワークを使用する他のコンピュータシステムへの通信であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースの各々で使用することができる。

【0108】

前述のヒューマン・インターフェース・デバイス、ヒューマンアクセス可能なストレージデバイス、およびネットワークインターフェースは、コンピュータシステム1400のコア1440に接続され得る。

【0109】

コア1440は、1つまたは複数の中央処理装置（CPU）1441、グラフィックス処理装置（GPU）1442、グラフィックスアダプタ1417、フィールド・プログラマブル・ゲート・アレイ（FPGA）1443の形態の専用のプログラマブル処理装置、特定のタスク用のハードウェア・アクセラレータ1444などを含むことができる。これらのデバイスは、読み取り専用メモリ（ROM）1445、ランダム・アクセス・メモリ1446、ユーザがアクセスすることができない内部ハードドライブ、SSDなどの内部大容量記憶装置1447とともに、システムバス1448を介して接続されてよい。一部のコンピュータシステムでは、システムバス1448に、1つまたは複数の物理的プラグの形態でアクセスして、追加のCPU、GPUなどによる拡張を可能にすることもできる。周辺機器は、コアのシステムバス1448に直接、または周辺バス1451を介して結合することができる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。

【0110】

CPU 1441、GPU 1442、FPGA 1443、およびアクセラレータ1444は、組み合わせて、前述のコンピュータコードを構成できる特定の命令を実行できる。そのコンピュータコードは、ROM 1445またはRAM 1446に格納され得る。移行データもまたRAM1446に記憶することができるが、永続的データは、例えば内部大容量記憶装置1447に記憶することができる。1つまたは複数のCPU 1441、GPU 1442、大容量記憶装置1447、ROM 1445、RAM 1446などと密接に関連付けることができるキャッシュメモリを使用することにより、メモリデバイスのいずれかへの高速記憶および高速取り出しを可能できる。

【0111】

コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってもよく、またはコンピュータソフトウェア技術の当業者に周知で利用可能な種類のものであってもよい。

【0112】

一例として、限定としてではなく、アーキテクチャを有するコンピュータシステム1400、具体的にはコア1440を有するコンピュータシステムは、1つまたは複数の有形のコンピュータ可読媒体で具体化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供することができる。そのようなコンピュータ可読媒体は、上部で紹介したようにユーザがアクセス可能な大容量記憶装置のほか、コア内部大容量記憶装置1447またはROM 1445などの非一時的性質のコア1440の特定の記憶装置にも関連する媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに格納され、コア1440によって実行され得る。コンピュータ可読媒体は、特定の必要性に応じて、1つまたは複数のメモリデバイスまたはチップを含み得る。ソフトウェアは、コア1440、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM 1446に記憶されたデータ構造の定義、およびソフトウェアによって定義された処理による、そのようなデータ構造の変更を含む、本明細書に記載の特定の処理または特定の処理の特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、本明細書に記載の特定の処理または特定の処理の特定の部分を実行するために、ソフトウェアの代わりにまたは一緒に動作することができる回路（例えば、アクセラレータ1444）に配線されたまたはそうでなければ具体化された論理回路の結果として、機能を提供することができる。ソフトウェアへの参照に論理回路を含めることができ、必要に応じてその逆も可能である。コンピュータ可読媒体への参照は、適切な場合には、実行のためにソフトウェアを格納する回路（集積回路（IC）など）、実行のための論理回路を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアとの任意の適切な組み合わせを包含する。

【0113】

本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある変更、置換、および様々な代替均等物が存在する。したがって、当業者は、本明細書では明示的に示されていないか、または記載されていないが、本開示の原理を具現化する、すなわち、その趣旨および範囲内にある、多数のシステムおよび方法を考案できることが理解されよう。

【符号の説明】

【0114】

100 通信システム
101，102，103，104 端末
105 ネットワーク
201 カメラ／ビデオソース
202 エンコーダ
203 キャプチャサブシステム
204 ビデオビットストリーム
205 ストリーミングサーバ
206 ビデオビットストリームのコピー
207 ストリーミングクライアント
208 ビデオビットストリームのコピー
209 ディスプレイ
210 発信ビデオ・サンプル・ストリーム
211 ビデオデコーダ
212 ストリーミングクライアント
213 サンプルストリーム
300 デコーダ
301 チャネル
302 受信機
303 バッファ
304 パーサ
305 スケーラ／逆変換ユニット
306 動き補償予測ユニット
307 イントラ予測ユニット
308 参照ピクチャバッファ
309 ピクチャ
310 アグリゲータ
311 ループフィルタユニット
312 ディスプレイ
313 シンボル
400 エンコーダ
401 ビデオソース
402 コントローラ
403 ソースコーダ
404 予測器
405 参照ピクチャメモリ
406 デコーダ
407 コーディングエンジン
408 エントロピーコーダ
409 送信機
410 ビデオシーケンス
411 通信チャネル
500 通話
501 部屋
502 ビュー画面
503，504 人物
505 全方向カメラ
507，508 ビューポート情報
509，510 ビューポート依存ビデオ
557 参照ピクチャメモリ
600 フィードバック・メッセージ・フォーマット
701 ビューポート
702 ビューポートマージン
703 許容誤差
705 イベントベースのフィードバックの許容誤差マージン
801 会議室
802 ユーザ
900 フローチャート
1400 コンピュータシステム
1401 キーボード
1402 マウス
1403 トラックパッド
1405 ジョイスティック
1406 マイク
1407 カメラ
1408 スキャナー
1409 スピーカ
1410 タッチスクリーン
1411 CD／DVD
1420 CD／DVD ROM／RW
1417 グラフィックスアダプタ
1422 サムドライブ
1423 ソリッド・ステート・ドライブ
1440 コア
1441 中央処理装置（CPU）
1442 グラフィックス処理装置（GPU）
1443 フィールド・プログラマブル・ゲート・アレイ（FPGA）
1444 アクセラレータ
1445 読み取り専用メモリ（ROM）
1446 ランダム・アクセス・メモリ（RAM）
1447 大容量記憶装置
1448 システムバス
1450，1451 周辺バス
1498 ネットワーク
1499 インターフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【手続補正書】

【提出日】2023-12-20

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも1つのプロセッサによって実行される、ビデオシグナリング方法であって、
ビデオ通話に関して閾値を設定するステップと、
イベントに基づいて前記閾値がトリガされたかどうか、および別のイベントから経過した時間が所定の時間未満であるかどうかを判定するステップと、
前記閾値がトリガされたかどうかの判定に基づいて、ビューポートへの前記ビデオ通話の配信を制御するステップと、
を含むビデオシグナリング方法。

【外国語明細書】