▶ フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ．の特許一覧
特許7486527イマーシブメディアコンテンツの提示および双方向性の３６０°ビデオ通信
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-09
(45)【発行日】2024-05-17
(54)【発明の名称】イマーシブメディアコンテンツの提示および双方向性の３６０°ビデオ通信
(51)【国際特許分類】
H04N 21/431 20110101AFI20240510BHJP
H04N 21/2343 20110101ALI20240510BHJP
【ＦＩ】
H04N21/431
H04N21/2343
【請求項の数】
19
(21)【出願番号】P 2021569181
(86)(22)【出願日】2020-05-20
(65)【公表番号】
(43)【公表日】2022-07-25
(86)【国際出願番号】 EP2020064111
(87)【国際公開番号】W WO2020234373
(87)【国際公開日】2020-11-26
【審査請求日】2022-01-07
(31)【優先権主張番号】19175477.9
(32)【優先日】2019-05-20
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】19194172.3
(32)【優先日】2019-08-28
(33)【優先権主張国・地域又は機関】EP
【前置審査】
(73)【特許権者】
【識別番号】500242786
【氏名又は名称】フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ．
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】セルハン・グル
(72)【発明者】
【氏名】ヤゴ・サンチェス・デ・ラ・フエンテ
(72)【発明者】
【氏名】コルネリウス・ヘルゲ
(72)【発明者】
【氏名】トーマス・シエル
(72)【発明者】
【氏名】ローベルト・スクピン
(72)【発明者】
【氏名】トーマス・ヴィーガント
【審査官】大西 宏
(56)【参考文献】
【文献】特開２０１７－２１５８７５（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１９／０１０４３２６（ＵＳ，Ａ１）
【文献】国際公開第２０１８／１２３６４６（ＷＯ，Ａ１）
【文献】国際公開第２０１９／０８３２６６（ＷＯ，Ａ１）
【文献】Yanan Bao; Tianxiao Zhang; Amit Pande; Huasen Wu; Xin Liu，Motion-Prediction-Based Multicast for 360-Degree Video Transmissions，2017 14th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON)，米国，IEEE，2017年06月12日，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7964928
【文献】Duc V. Nguyen; Huyen T. T. Tran; Anh T. Pham; Truong Cong Thang，An Optimal Tile-Based Approach for Viewport-Adaptive 360-Degree Video Streaming，IEEE Journal on Emerging and Selected Topics in Circuits and Systems，Volume: 9, Issue: 1, March 2019，米国，IEEE，2019年02月14日，pp. 29 - 42，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8642331
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００ －２１／８５８
(57)【特許請求の範囲】
【請求項1】
送信機との360°ビデオ通信のための装置であって、360°ビデオの特定の視線方向に応じてビデオデータを前記送信機から取得することと、
前記360°ビデオの前記特定の視線方向を表現する前記ビデオデータを表示することと、を行うように構成され、
前記ビデオデータがビューポートの周りのマージンエリアを含み、
前記360°ビデオ通信のセッションの最初において、前記装置が、前記ビデオデータの前記マージンエリアに関する情報を前記送信機とネゴシエートするように構成され、
前記360°ビデオ通信の前記特定の視線方向について、前記装置が、前記セッションの間に、
(i)前記送信機によってレンダリングされ、前記360°ビデオの前記特定の視線方向の2Dビデオを表現する第1のビデオデータ、及び
(ii)前記送信機によってレンダリングされず、特定の投影を使用して前記送信機によって送信されるべき前記360°ビデオの少なくとも一部を表現する第2のビデオデータ
の間の切り替えを引き起こすように構成された、装置。
【請求項2】
前記送信機から前記ビデオデータを取得するために、前記装置が、前記360°ビデオの前記特定の視線方向を前記送信機にシグナリングし、
前記360°ビデオの前記特定の視線方向に対する前記ビデオデータを前記送信機から受信するように構成された、請求項1に記載の装置。
【請求項3】
前記装置が、前記360°ビデオの前記特定の視線方向に対する前記ビデオデータをユーザに表示するための表示デバイスと、
前記ユーザの前記視線方向を検出するためのセンサと、
前記検出された視線方向を前記送信機にシグナリングし、前記取得されたビデオデータを前記表示デバイス上での表示のために処理するためのプロセッサとを備える、請求項1または2に記載の装置。
【請求項4】
前記360°ビデオ通信のセッションの間に、前記装置が、受信機と前記送信機との間のエンドツーエンドレイテンシに応じて、前記送信機からの前記第1のビデオデータまたは前記第2のビデオデータを要求するように構成された、請求項1に記載の装置。
【請求項5】
前記360°ビデオ通信のセッションの最初において、前記装置は前記送信機とネゴシエートするように構成され、前記送信機とネゴシエートするとき、前記装置が、投影タイプ、回転、およびregion-wise packing (RWP)制約のうちの1つまたは複数を示す補足強化情報(SEI)メッセージを、前記送信機から受信するように構成された、請求項1から4のいずれか一項に記載の装置。
【請求項6】
前記装置が、ビューポート予測を提供するビューポート予測子を備え、または、前記装置が、前記ビューポート予測を前記送信機から受信するように構成され、前記ビューポート予測が、先読み時間の後にユーザの現在の視線方向から前記ユーザの新しい視線方向への変化が起きることを示す、請求項1から5のいずれか一項に記載の装置。
【請求項7】
前記マージンエリアが前記ビューポートの特定の割合である、請求項1から6のいずれか一項に記載の装置。
【請求項8】
前記360°ビデオ通信のセッションの間、ビューポートサイズが前記マージンエリアを含む場合、前記装置が、前記装置が前記ビューポートをクロッピング/ワーピングするのを助けるために、レンダリングのために使用されるレンズ/ひずみパラメータの指示を受信するように構成された、請求項1から7のいずれか一項に記載の装置。
【請求項9】
受信機を伴う360°ビデオ通信のための装置であって、前記受信機における360°ビデオの特定の視線方向の指示を前記受信機から受信することと、
360°ビデオの前記特定の視線方向に対するビデオデータを前記受信機に送信することと、を行うように構成され、
前記ビデオデータがビューポートの周りのマージンエリアを含み、
前記360°ビデオ通信のセッションの最初において、前記装置が、前記ビデオデータの前記マージンエリアに関する情報を前記受信機とネゴシエートするように構成され、
前記360°ビデオ通信の前記特定の視線方向について、前記装置が、前記セッションの間に、
(i)前記装置によってレンダリングされ、前記360°ビデオの前記特定の視線方向の2Dビデオを表現する第1のビデオデータ、及び
(ii)前記装置によってレンダリングされず、特定の投影を使用して前記装置によって送信されるべき前記360°ビデオの少なくとも一部を表現する第2のビデオデータ
の間の切り替えを引き起こすことを受信するように構成された、装置。
【請求項10】
前記装置が、前記第1のビデオデータが提供されるように構成される場合、前記ビデオデータをレンダリングし、前記レンダリングされたビデオデータを符号化し、前記符号化されたビデオデータを前記受信機に送信し、
前記第2のビデオデータが提供されるように構成される場合、レンダリングすることなく、特定の投影を使用して前記ビデオデータを符号化し、投影タイプ、回転、およびregion-wise packing (RWP)制約を示す、1つまたは複数の補足強化情報(SEI)メッセージを符号化し、前記符号化されたビデオデータおよび前記符号化された1つまたは複数のメッセージを前記受信機に送信することになる、請求項9に記載の装置。
【請求項11】
前記装置が、前記受信機と送信機との間のエンドツーエンドレイテンシに応じて、前記第1のビデオデータまたは前記第2のビデオデータを前記受信機に提供するように構成された、請求項10に記載の装置。
【請求項12】
前記360°ビデオ通信のセッションの最初において、前記装置が前記受信機とネゴシエートするように構成され、前記受信機とネゴシエートするとき、前記装置が、前記受信機に、投影タイプ、回転、およびregion-wise packing (RWP)制約のうちの1つまたは複数を示す補足強化情報(SEI)メッセージを、前記受信機に送信するように構成された、請求項9から11のいずれか一項に記載の装置。
【請求項13】
前記装置が、ビューポート予測を提供するビューポート予測子を備え、または、前記装置が、前記ビューポート予測を前記受信機から受信するように構成され、前記ビューポート予測が、先読み時間の後に前記受信機のユーザの現在の視線方向から前記ユーザの新しい視線方向への変化が起きることを示す、請求項9から12のいずれか一項に記載の装置。
【請求項14】
前記マージンエリアが前記ビューポートの特定の割合である、請求項9から13のいずれか一項に記載の装置。
【請求項15】
前記360°ビデオ通信のセッションの間、ビューポートサイズが前記マージンエリアを含む場合、前記装置が、前記受信機が前記ビューポートをクロッピング/ワーピングするのを助けるために、レンダリングのために使用されるレンズ/ひずみパラメータの指示を前記受信機に送信するように構成された、請求項9から14のいずれか一項に記載の装置。
【請求項16】
360°ビデオ通信システムであって、請求項9から15のいずれか一項に記載の装置を含む送信機と、
請求項1から8のいずれか一項に記載の装置を含む受信機とを備える、360°ビデオ通信システム。
【請求項17】
360°ビデオ通信のための方法であって、送信機において、受信機における360°ビデオの特定の視線方向の指示を前記受信機から受信するステップと、
前記送信機によって、360°ビデオの前記特定の視線方向に対するビデオデータを前記受信機に送信するステップとを備え、
前記ビデオデータがビューポートの周りのマージンエリアを含み、
前記360°ビデオ通信のセッションの最初において、前記送信機及び前記受信機が、前記ビデオデータの前記マージンエリアに関する情報をネゴシエートするように構成され、
前記360°ビデオ通信の前記特定の視線方向について、前記方法が、前記セッションの間に、
(i)前記送信機によってレンダリングされ、前記360°ビデオの前記特定の視線方向の2Dビデオを表現する第1のビデオデータ、及び
(ii)前記送信機によってレンダリングされず、特定の投影を使用して前記送信機によって送信されるべき前記360°ビデオの少なくとも一部を表現する第2のビデオデータ
の間の切り替えを引き起こすステップを含む、方法。
【請求項18】
前記受信機によって、前記受信機における360°ビデオの前記特定の視線方向に応じて前記送信機から前記ビデオデータを取得するステップと、前記受信機において、前記360°ビデオの前記特定の視線方向を表現する前記ビデオデータを表示するステップとをさらに備える、請求項17に記載の方法。
【請求項19】
命令を備えるコンピュータプログラムであって、コンピュータによって実行されると、前記命令が、請求項17または18に記載の方法を前記コンピュータに行わせる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、イマーシブメディアおよび360°ビデオの分野に関する。本発明の手法の実施形態は、たとえば、ビデオオンデマンド(VoD)、ストリーミング、ライブストリーミング、ビデオ会議、または、オンラインゲーム応用などの仮想現実(VR)応用を含む、イマーシブメディアの通信またはイマーシブメディアコンテンツの提示の改善に関する。本発明の手法の実施形態は、たとえば、ビデオ会議、または、オンラインゲーム応用などの仮想現実(VR)応用を含む、360°ビデオ通信の改善に関する。
【背景技術】
【0002】
近年、イマーシブメディアが多くの注目を集めている。イマーシブメディアコンテンツの提示または表現のために重要な技術は、
(i)3DoF(3自由度)コンテンツ、たとえば360°ビデオ、
(ii)6DoF(6自由度)コンテンツ、たとえば、実際の物体のような、キャプチャされたボリュメトリックオブジェクト、または、たとえば実際の物体のボリュメトリックビデオ、
(iii)たとえば、Computer-Generated Imagery (CGI)のようなコンピュータグラフィクスを使用して生成され、たとえば3Dメッシュおよび2Dテクスチャからなる、3Dオブジェクト
へと分類され得る。
(i)3DoF(3自由度)コンテンツ、たとえば360°ビデオ、
(ii)6DoF(6自由度)コンテンツ、たとえば、実際の物体のような、キャプチャされたボリュメトリックオブジェクト、または、たとえば実際の物体のボリュメトリックビデオ、
(iii)たとえば、Computer-Generated Imagery (CGI)のようなコンピュータグラフィクスを使用して生成され、たとえば3Dメッシュおよび2Dテクスチャからなる、3Dオブジェクト
へと分類され得る。
【0003】
これらの技術の組合せも可能である。たとえば、複数のボリュメトリックオブジェクトが、背景で再生される360°ビデオに重畳されてユーザに提示され得る。提示されるボリュメトリックオブジェクトは、ダイナミックシーケンスまたはコンピュータで生成された3Dオブジェクトであり得る。
【0004】
近年、360°ビデオは多くの注目を集めており、360°応用向けのいくつかの製品が市場に出現した。標準化の活動が、360°ビデオデータのストリーミングと符号化を規定する。この分野における作業は主に、Hypertext Transfer Protocol(HTTP)を使用した360°ビデオのストリーミング、またはブロードキャスト/ブロードバンド送信に集中している。
【0005】
様々なイマーシブ応用に対して最近注目を集めている実現技術は、ボリュメトリックビデオである。ボリュメトリックビデオは、現実感のある方法で3次元空間をキャプチャし、360°ビデオと比較してより高い没入感を提供することができる。ボリュメトリックビデオは、6自由度(6DoF)コンテンツの表現にも適しており、視聴者がコンテンツの中を自由に動き、様々な視点および距離からボリュメトリックオブジェクトを観察することを可能にする。
【0006】
近年、ボリュメトリックコンテンツのキャプチャ、処理、圧縮、およびストリーミングのための、様々な技術が出現している。圧縮分野の1つの顕著な例は、Video-based Point Cloud Compression(V-PCC)規格である。V-PCCは、ポイントクラウドを、テクスチャ、ジオメトリ、占有マップ、さらに追加のメタデータのような、異なるビデオビットストリームへと符号化する。ポイントクラウド圧縮のための既存のビデオ圧縮アルゴリズムを適用することで、非常に高い圧縮効率がもたらされ、特にモバイルデバイス上で利用可能なハードウェアビデオデコーダを再使用することを可能にする。
【0007】
360°ビデオとは異なり、ボリュメトリックビデオは通常、3Dフォーマット、たとえばポイントクラウド、メッシュなどで表現され、これは、効率的な配信のために異なる処理および送信技術を必要とし得る。キャプチャされた、またはコンピュータで生成された複数のボリュメトリックビデオがシーンに存在するとき、互いのオブジェクトの位置および関係は、シーンに存在するエンティティをそのノードが表すシーングラフを使用して記述され得る。オブジェクトを記述するシーングラフを構築するために、シーン記述言語、たとえばX3Dが使用され得る。複数の3Dオブジェクトを配信することは、帯域幅の要件を高め、ボリュメトリックオブジェクトの再生の厳密な同期を必要とすることがある。
【0008】
ビデオ通信は通常、RTP/RTCP(Real-Time/Real-Time Control Protocol)を介して行われる。RTPでは、アクセスユニット(AU)が、ビデオのヘッダおよびコンテンツを含むRTPパケットへと分割される。ビデオの実際の送信の前に、両方のエンドポイント、すなわちサーバおよび受信機が、その間に能力を交換し、ビデオの特性およびビデオ通信に使用されるべきモードについて合意する、ネゴシエーション段階が通常は存在する。送信されるビットストリームの特性、ならびに使用される送信モードを記述するために、セッション記述プロトコル(SDP)が使用され得る。SDPは、能力のネゴシエーションのために使用され得る。たとえば、高効率ビデオコーディング(HEVC)ビットストリームを考えると、サーバは、それぞれのパラメータセット、たとえばsprop-parameter-setsを送信してもよく、送信は帯域外であってもよく、すなわち、ビデオデータの実際の送信の中になくてもよい。クライアントは、パラメータをそのまま受け入れ得る。SDPネゴシエーションの例が以下で与えられ、パラメータセット#0がサーバのエンコーダおよびクライアントのデコーダによって記憶され使用されてもよく、一方、パラメータセット#1がクライアントのエンコーダおよび送信機のデコーダによって使用されてもよい。
送信機:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#0>
sprop-sps=<sps data#0>
sprop-pps=<pps data#0>
クライアント:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#1>
sprop-sps=<sps data#1>
sprop-pps=<pps data#1>
送信機:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#0>
sprop-sps=<sps data#0>
sprop-pps=<pps data#0>
クライアント:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#1>
sprop-sps=<sps data#1>
sprop-pps=<pps data#1>
【0009】
SDPネゴシエーションのさらなる例が以下で与えられ、これは上の例と似ているが、レベルが下げられている。パラメータセット#0は無視され、帯域内に、すなわち実際のビデオデータの送信の間に来てもよい。
送信機:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=120; //Main profile, Level 4.0
sprop-vps=<vps data#0>
sprop-sps=<sps data#0>
sprop-pps=<pps data#0>
クライアント:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#1>
sprop-sps=<sps data#1>
sprop-pps=<pps data#1>
送信機:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=120; //Main profile, Level 4.0
sprop-vps=<vps data#0>
sprop-sps=<sps data#0>
sprop-pps=<pps data#0>
クライアント:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 level-id=90; //Main profile, Level 3.0
sprop-vps=<vps data#1>
sprop-sps=<sps data#1>
sprop-pps=<pps data#1>
【0010】
上の例に示されるようなメディア記述に加えて、SDPは、能力のネゴシエーションおよび異なる構成の選択にも使用され得る。たとえば、RFC 5939は、SDP能力ネゴシエーション(SDPCapNeg)を定義することによってSDPを拡張し、これは、実際の構成のためのSDPだけではなく、潜在的な構成とも呼ばれる1つまたは複数の代替のSDPセッション記述も可能にする解決策である。実際の構成が選ばれるか、または潜在的な構成のうちの1つが選ばれるかに応じて、選択された構成を実装するために、サーバがさらなる処理を実行することが必要であり得る。潜在的な構成は、SDPメッセージのmの行に含まれる構成に加えて提供される。たとえば、サーバがセキュアなRTP、SRTP、メディアストリームを確立することを望むが、単純なRTPも受け入れることができる場合、サーバは、単純なRTPを実際の構成にして、SRTPを潜在的な構成にする。クライアントがSRTPをサポートしない場合、またはSDPCapNegを理解しない場合、クライアントは単純なRTPを使用し得る。
【0011】
SDPCapNegは、能力を表現するための、および構成をネゴシエートするための、追加のSDP属性を定義する。より具体的には、以下の追加の属性が使用され得る。
・「a=acap」は、属性名およびその値を能力としてどのように列挙するかを定義する。
・「a=tcap」は、トランスポートプロトコル、たとえばRTPオーディオ/ビデオプロファイル、RTP/AVPを能力としてどのように列挙するかを定義する。
・「a=pcfg」は、サポートされる潜在的な構成を列挙し、潜在的な構成は、属性能力、トランスポート能力、またはこれらの組合せを含み得る。これらの能力は、従来のSDP手順またはネゴシエーション手順により使用され得る代替のSDPセッション記述を生成するために使用され得る。
・「a=acfg」は、サーバによって提供される潜在的な構成を特定するためにクライアントによって使用され得る属性である。
・「a=acap」は、属性名およびその値を能力としてどのように列挙するかを定義する。
・「a=tcap」は、トランスポートプロトコル、たとえばRTPオーディオ/ビデオプロファイル、RTP/AVPを能力としてどのように列挙するかを定義する。
・「a=pcfg」は、サポートされる潜在的な構成を列挙し、潜在的な構成は、属性能力、トランスポート能力、またはこれらの組合せを含み得る。これらの能力は、従来のSDP手順またはネゴシエーション手順により使用され得る代替のSDPセッション記述を生成するために使用され得る。
・「a=acfg」は、サーバによって提供される潜在的な構成を特定するためにクライアントによって使用され得る属性である。
【0012】
以下に、SDPCapNegを使用したSDPネゴシエーションの例が与えられる。
V=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
V=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
【0013】
上の例では、2つのあり得る構成が、属性a=pcfg:1およびa=pcfg:2によって示される。第1のあり得る構成は、t=1かつa=1であることを示し、これは、属性a=tcapによって示される第1のトランスポート能力、すなわちRTP/SAVP(Real-Time Transport Protocol/Secure Audio Video Profile)が第1のあり得る構成のために提供され、属性能力がcrypto:1:..であるものとしてa=acapにおいて示されることを意味する。同様に、第2のあり得る構成は、t=2かつa=1であることを示し、これは、a=tcapにおいて示される第2のトランスポート能力、すなわちRTP/SAVPF(RTP/SAVPF=)が使用され、属性能力がcrypto:1:..であるものとしてa=acapにおいて示されることを意味する。
【0014】
実際のビデオ送信が開始する前に構成のために使用され得るSDPネゴシエーションに加えて、RTPと一緒に通常は使用されるリアルタイム制御プロトコル(RTCP)が、セッションの間の符号化モードを制御するために、フィードバック機構として使用され得る。RTCPは通常、RTPストリームの同期、パケット喪失の報告、遅延推定などのために使用され得る。それは、ビデオコーディングパラメータを制御するために、フィードバックチャネルとしても使用され得る。たとえば、HEVCペイロードフォーマットにおいて、制御されるべき以下のパラメータがあり得る。
・Picture Loss Indication(PLI):1つまたは複数のピクチャに属する定義されていない量のコーディングされたビデオデータの喪失の指示
・Slice Loss Indication(SLI):CTBラスタースキャン(CTB=コーディングツリーブロック)におけるある数のCTBの喪失の指示
・Reference Picture Selection Indication(RPSI):誤差の伝播を防ぐための参照ピクチャの選択
・Full Intra Request(FIR):IDR(IDR=瞬時デコーダリフレッシュ)をエンコーダに送信させるためのメッセージ
・Picture Loss Indication(PLI):1つまたは複数のピクチャに属する定義されていない量のコーディングされたビデオデータの喪失の指示
・Slice Loss Indication(SLI):CTBラスタースキャン(CTB=コーディングツリーブロック)におけるある数のCTBの喪失の指示
・Reference Picture Selection Indication(RPSI):誤差の伝播を防ぐための参照ピクチャの選択
・Full Intra Request(FIR):IDR(IDR=瞬時デコーダリフレッシュ)をエンコーダに送信させるためのメッセージ
【0015】
RTCP制御パケットは、ビデオ通信のエンドポイント間で定期的に交換され得る。ポイントツーポイントのシナリオでは、RTP送信機およびRTP受信機は、相互の送信機報告(SR)および受信機報告(RR)を互いに送信し得る。RTCP受信機報告(RR)は、受信品質を示すことができ、以下のサービス品質(QoS)メトリクスのうちの1つまたは複数を含み得る。
・累積のパケット喪失の数
・喪失の割合
・到着間ジッタ
・タイミング情報
・累積のパケット喪失の数
・喪失の割合
・到着間ジッタ
・タイミング情報
【0016】
タイミング情報は、
・最後のSR(LSR)が受信されたときのタイムスタンプ
・最後のSRが受信されてからの遅延(DLSR)
・最後のSR(LSR)が受信されたときのタイムスタンプ
・最後のSRが受信されてからの遅延(DLSR)
【0017】
送信機は、LSRおよびDLSRフィールドを使用して、送信機と受信機との間のラウンドトリップタイム(RTT)を計算し得る。
【0018】
図1は、送信機と受信機との間で交換されるそれぞれのRTCP報告を使用してRTTを計算するための例を示す。最初に、100において示されるように、送信機は、102において示されるタイミング情報を含む送信機報告(SR)を受信機に送信する。受信機は、SRを受信した後で、104において示されるように、受信機報告(RR)を送信し、受信機報告はLSRおよびDLSRフィールドを含む。106において示されるように、送信機においてRRを受信すると、108において示されるように実際の時間を決定し、110において示されるようにRTTを計算する。より具体的には、送信機は、実際の時間とも呼ばれる到着時間110aを決定し、実際の時間110aからDLSR110bおよびLSR110cを差し引き、RTTを得る。計算された時間は、ネットワークRTTであり、エンドポイントにおけるあらゆる処理、たとえば、ジッタなどを滑らかにするための受信機におけるバッファリング遅延を含まない。送信機は、ビデオ符号化を最適化するために、既知のRTTを使用し得る。
【0019】
ネットワーク特性のマルチキャスト干渉(MINC)またはvoice-over IP(VoIP)、モニタリングなどの一部の応用では、他のより詳細な統計が必要である。たとえば、RFC 3611(RTCP拡張報告)はいくらかの拡張をもたらす。たとえば、受信機参照時間報告ブロックは、非送信機もタイムスタンプを送信し得るような方法で、RTCPのタイムスタンプを拡張する。言い換えると、受信機も、報告を送信してRFC 3611において定義されるようなDLRR報告(DLRR=最後にRRが受信されてからの遅延)を受信することによって、他の参加者と比較したときのRTTを推定することができる。
【0020】
通常、RTCPパケットは、個別に送信されず、送信のために合成パケットへと詰め込まれ、RTCPパケットにより引き起こされるオーバーヘッドが大幅に増大しないように、好ましくはトラフィックの5%前後に保たれるように、比較的長い時間間隔で送信される。加えて、RTCP報告間の最短の間隔、たとえば約5秒が推奨され得る。しかしながら、一部の応用は高速な報告を必要とすることがあり、タイムリーなフィードバックを達成するために、RFC 4585において定義されるようなRTCベースのフィードバックのための拡張されたRTPプロファイル(RTP/AVPF)は、早期RTCPメッセージという概念、ならびに小さいマルチキャストグループにおける低遅延フィードバックを可能にし、大きいグループにおけるフィードバックインプロージョンを防ぐアルゴリズムを導入する。RTP/AVPFでは3つの動作モード、すなわち、
・即刻フィードバック
・早期RTCPモード
・通常RTCPモード
がある。
・即刻フィードバック
・早期RTCPモード
・通常RTCPモード
がある。
【0021】
受信機は、即刻フィードバックモードを使用することによって、次の通常のRTCP報告間隔より早くフィードバックメッセージを送信し得る。これらの技法は、遅延に厳しい状況に対して符号化技法または判断を制御すること、もしくは操作すること、もしくはそれらに影響を与えることを可能にする、応用固有のメッセージを定義するために使用され得る。RTCPフィードバックメッセージの使用の例は、3GPP TS 26.114(IMS Media Handling and Interaction)において見出され得る。3GPP TS 26.114は、
(i)受信機によって任意に選択されるビデオ関心領域(ROI)、および
(ii)3GPP TS 26.114、Section 7.3.7において述べられるような、送信機によってあらかじめ定義され、受信機によって選択されるビデオROI
を伝えるために、SDPにおいて異なる「rtcp-fb」属性値を規定する。
(i)受信機によって任意に選択されるビデオ関心領域(ROI)、および
(ii)3GPP TS 26.114、Section 7.3.7において述べられるような、送信機によってあらかじめ定義され、受信機によって選択されるビデオROI
を伝えるために、SDPにおいて異なる「rtcp-fb」属性値を規定する。
【0022】
より大きい画像内での特定の位置、すなわちROIを示すRTCPフィードバックメッセージの例は、以下のように規定され得る。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Position_X (h)| Position_X (l)| Position_Y (h)| Position_Y(l)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size_X (h) | Size_X (l) | Size_Y (h) | Size_Y(l) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Position_X (h)| Position_X (l)| Position_Y (h)| Position_Y(l)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size_X (h) | Size_X (l) | Size_Y (h) | Size_Y(l) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【先行技術文献】
【非特許文献】
【0023】
【文献】RFC 3550 RTP: A Transport Protocol for Real-Time Applications
【文献】RFC 7798 RTP Payload Format for High Efficiency Video Coding (HEVC)
【文献】RFC 8285 A General Mechanism for RTP Header Extensions
【文献】RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
【文献】RFC 3611 RTCP extended reports (XRs)
【文献】RFC 5968 Guidelines for Extending the RTP Control Protocol (RTCP)
【文献】3GPP TS 26.114 v16.0.0 - IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction
【発明の概要】
【発明が解決しようとする課題】
【0024】
イマーシブメディアの通信またはイマーシブメディアコンテンツの提示を改善する必要がある。360°ビデオ通信をさらに改善する必要がある。
【課題を解決するための手段】
【0025】
この必要性は、本出願において定義されるような、および添付の特許請求の範囲において定義されるような主題によって達成され得る。
【0026】
ここで、本発明の実施形態が添付の図面を参照してさらに詳細に説明される。
【図面の簡単な説明】
【0027】
【図1】送信機と受信機との間で交換されるそれぞれのRTCP報告を使用してRTTを計算するための例を示す図である。
【図2】送信機と受信機との間の360°ビデオ通信のためのシステムの概略的な表現の図である。
【図4】受信機における視線方向と一致するビデオデータを含むビットストリームを送信機が提供する、360°ビデオ通信の間のビューポート送信遅延を示す図である。
【図5】ビューポート予測技法を適用するときに受信機における視線方向と一致するビデオデータを含むビットストリームを送信機が提供する、360°ビデオ通信の間のビューポート送信遅延を示す図である。
【図6】その周りの外側エリアより高い解像度を有する、受信機が見つめる中心エリアを伴うビューポートを示す図である。
【図7】本発明の手法に従って説明されるユニットまたはモジュールならびに方法のステップが実行され得る、コンピュータシステムの例を示す図である。
【発明を実施するための形態】
【0028】
本発明の実施形態がここで、添付の図面を参照してより詳しく説明され、図面において、同じまたは同様の要素は同じ参照記号を割り当てられている。
【0029】
ストリーミング応用では、全体の360°ビデオの360°ビデオデータは、たとえば、ブロードキャスト/ブロードバンド送信によって電波を介して、または、インターネットのようなネットワークを介してHTTPを使用して、クライアントに向かってサーバにより提供され、クライアントは、受信されたビデオデータを表示のためにレンダリングする。したがって、ビデオコンテンツ全体が受信機に提供される。ビデオ通信応用、たとえば、ビデオ会議またはオンラインゲーム応用などの仮想現実(VR)応用では、一般に、360°ビデオのシーンの一部のみが、たとえばユーザの視線方向に応じて、受信機においてユーザに提示される。クライアントは、視線方向に基づいて、ユーザの視線方向に対応する360°ビデオのシーンのその部分をユーザに表示するために、ビデオデータ全体を処理する。しかしながら、360°ビデオのビデオデータ全体を受信機に提供することは、送信機と受信機との間のリンクの高い送信能力を必要とする。また、受信機は、シーンの所望の部分をユーザに提示するために、ビデオデータ全体を処理するのに十分な処理能力を有する必要がある。一部の360°ビデオ通信の応用はリアルタイムの応用であり得るので、データ全体の送信および/または処理と関連付けられる期間または時間が長いことは、不利であり得る。
【0030】
RTP、RTCP、およびSDPのような上で説明されたプロトコルは、ビデオデータの送信のための機構およびシグナリングを提供し、既存の機構およびシグナリングは360°ビデオ通信に固有ではないので、既知の機構およびシグナリングを使用するのは不利であり得る。
【0031】
本発明の実施形態は、イマーシブメディアの通信またはイマーシブメディアコンテンツの提示を改善するための様々な態様を提供する。本発明の実施形態は、360°ビデオ通信を改善するための様々な態様を提供する。
【0032】
図2は、サーバとも呼ばれる送信機200と、クライアントとも呼ばれる受信機202との間の、イマーシブメディアの通信または360°ビデオ通信のためのシステムの概略的な表現である。サーバ200およびクライアント202は、ビデオもしくはピクチャおよび/またはオーディオ情報を含むメディアストリーム204を送信するための、有線通信リンクまたはワイヤレス通信リンクを介して通信し得る。より具体的には、メディアストリーム204は、たとえばそれぞれのRTPパケットにおいて、サーバ200によって提供されるような360°ビデオデータを含む。加えて、それぞれのRTCPパケットは、上で説明されたようなメディアストリームに含まれる。本発明の実施形態によれば、RTP、RTCP、およびSDPは、改善されたより効率的なイマーシブメディアの通信もしくはイマーシブメディアコンテンツの提示のための、または改善されたより効率的な360°ビデオ通信のための、機構およびシグナリングを提供するように拡張される。サーバ200はシグナルプロセッサ206を含み、クライアント202はシグナルプロセッサ208を含む。クライアント202ならびにサーバ200は、本明細書において以下でより詳しく説明される本発明の教示に従って動作し得る。
【0033】
イマーシブメディアの提示のための受信機/クライアント
本発明は、イマーシブメディアコンテンツを提示するための装置を提供し(たとえば請求項1を参照されたい)、この装置は、
特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを送信機から取得し、
特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを表示する
ことになる。
本発明は、イマーシブメディアコンテンツを提示するための装置を提供し(たとえば請求項1を参照されたい)、この装置は、
特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを送信機から取得し、
特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを表示する
ことになる。
【0034】
実施形態(たとえば請求項2を参照されたい)によれば、送信機からビデオを取得するために、装置は、
-特定の視線方向および/または特定の視点を送信機にシグナリングし、
-特定の視線方向および/または特定の視点に対するビデオデータを送信機から受信する
ことになる。
-特定の視線方向および/または特定の視点を送信機にシグナリングし、
-特定の視線方向および/または特定の視点に対するビデオデータを送信機から受信する
ことになる。
【0035】
実施形態(たとえば請求項3を参照されたい)によれば、装置は、
特定の視線方向および/または特定の視点に対するビデオデータをユーザに表示するための表示デバイス、たとえばHMDと、
ユーザの視線方向および/または視点を検出するためのセンサと、
検出された視線方向および/または特定の視点を送信機にシグナリングし、受信されたビデオデータを表示デバイス上での表示のために処理するためのプロセッサ
とを備える。
特定の視線方向および/または特定の視点に対するビデオデータをユーザに表示するための表示デバイス、たとえばHMDと、
ユーザの視線方向および/または視点を検出するためのセンサと、
検出された視線方向および/または特定の視点を送信機にシグナリングし、受信されたビデオデータを表示デバイス上での表示のために処理するためのプロセッサ
とを備える。
【0036】
実施形態(たとえば請求項4を参照されたい)によれば、装置は、イマーシブコンテンツを表現するビデオデータの特定の視線方向および/または特定の視点に対して、送信機から、
(i)送信機によってレンダリングされ、特定の視線方向および/もしくは特定の視点に対するイマーシブコンテンツを表現するビデオデータの2Dビューポートバージョンを表現する、第1のビデオデータと、
(ii)送信機によってレンダリングされず、送信機によって送信されるべきイマーシブコンテンツの少なくとも一部を表現する、第2のビデオデータと
を受信することになる。
(i)送信機によってレンダリングされ、特定の視線方向および/もしくは特定の視点に対するイマーシブコンテンツを表現するビデオデータの2Dビューポートバージョンを表現する、第1のビデオデータと、
(ii)送信機によってレンダリングされず、送信機によって送信されるべきイマーシブコンテンツの少なくとも一部を表現する、第2のビデオデータと
を受信することになる。
【0037】
実施形態(たとえば請求項5を参照されたい)によれば、イマーシブメディアセッションの間に、装置は、受信機と送信機との間のレイテンシに応じて、第1のビデオデータまたは第2のビデオデータを送信機から受信することになる。
【0038】
実施形態(たとえば請求項6を参照されたい)によれば、レイテンシは、
-ネットワークレイテンシ、レンダリングレイテンシ、およびコーディングレイテンシのうちの1つまたは複数を備えるエンドツーエンドレイテンシ、
-受信機における特定の視線方向および/または特定の視点の変化の検出から、新しい視線方向および/または新しい視点に対するレンダリングされたビデオデータの表示までの時間である、motion-to-photon(MTP)レイテンシのうちの1つまたは複数を備え、MTPレイテンシは予測先読み時間によって低減され得る。
-ネットワークレイテンシ、レンダリングレイテンシ、およびコーディングレイテンシのうちの1つまたは複数を備えるエンドツーエンドレイテンシ、
-受信機における特定の視線方向および/または特定の視点の変化の検出から、新しい視線方向および/または新しい視点に対するレンダリングされたビデオデータの表示までの時間である、motion-to-photon(MTP)レイテンシのうちの1つまたは複数を備え、MTPレイテンシは予測先読み時間によって低減され得る。
【0039】
実施形態(たとえば請求項7を参照されたい)によれば、
レイテンシが特定の閾値、たとえば15msから20ms以下である場合、装置は第1のビデオデータを送信機から受信することになり、
レイテンシが特定の閾値より大きい場合、装置は、第2のビデオデータを送信機から受信することになる。
レイテンシが特定の閾値、たとえば15msから20ms以下である場合、装置は第1のビデオデータを送信機から受信することになり、
レイテンシが特定の閾値より大きい場合、装置は、第2のビデオデータを送信機から受信することになる。
【0040】
実施形態(たとえば請求項8を参照されたい)によれば、
送信機が、2Dビューポートバージョンを表現する第1のビデオデータを第1のフォーマットで提供し、レンダリングされていないイマーシブコンテンツを表現する第2のビデオデータを第2のフォーマットで提供する場合、装置は、第1のフォーマットと第2のフォーマットの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、もしくはメッセージの後の特定の時間に、送信機に送信することになり、
送信機が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードからイマーシブコンテンツを表現するビデオデータのレンダリングされていない部分を提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、第1のモードと第2のモードの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、送信機に送信することになる。
送信機が、2Dビューポートバージョンを表現する第1のビデオデータを第1のフォーマットで提供し、レンダリングされていないイマーシブコンテンツを表現する第2のビデオデータを第2のフォーマットで提供する場合、装置は、第1のフォーマットと第2のフォーマットの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、もしくはメッセージの後の特定の時間に、送信機に送信することになり、
送信機が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードからイマーシブコンテンツを表現するビデオデータのレンダリングされていない部分を提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、第1のモードと第2のモードの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、送信機に送信することになる。
【0041】
実施形態(たとえば請求項9を参照されたい)によれば、特定の閾値は、
ネットワークレイテンシ、
エンドツーエンドレイテンシ、
最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ、
あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ、
未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
のうちの1つまたは複数である。
ネットワークレイテンシ、
エンドツーエンドレイテンシ、
最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ、
あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ、
未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
のうちの1つまたは複数である。
【0042】
実施形態(たとえば請求項10を参照されたい)によれば、イマーシブメディアセッションの最初において、レイテンシがまだ不明であるとき、装置は、レイテンシが判明するまで、または確実に推定され得るまで、第2のビデオデータのみを受け入れることになる。
【0043】
実施形態(たとえば請求項11を参照されたい)によれば、
イマーシブメディアセッションの最初において、装置は、送信機とネゴシエートすることになり、
送信機とネゴシエートするとき、装置は、たとえばセッション記述プロトコル(SDP)を使用して、イマーシブコンテンツを表現するビデオデータの1つまたは複数のパラメータ、たとえば補足強化情報(SEI)メッセージを送信機から受信することになる。
イマーシブメディアセッションの最初において、装置は、送信機とネゴシエートすることになり、
送信機とネゴシエートするとき、装置は、たとえばセッション記述プロトコル(SDP)を使用して、イマーシブコンテンツを表現するビデオデータの1つまたは複数のパラメータ、たとえば補足強化情報(SEI)メッセージを送信機から受信することになる。
【0044】
実施形態(たとえば請求項12を参照されたい)によれば、
送信機とネゴシエートするとき、装置は、ビデオデータまたはフォーマットが(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示をさらに送信機から受信することになり、
イマーシブメディアセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを受信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、
-第1のビデオデータと第2のビデオデータの即刻の切り替え、または
-第1のビデオデータと第2のビデオデータの切り替えまでの特定の時間
を示す。
送信機とネゴシエートするとき、装置は、ビデオデータまたはフォーマットが(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示をさらに送信機から受信することになり、
イマーシブメディアセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを受信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、
-第1のビデオデータと第2のビデオデータの即刻の切り替え、または
-第1のビデオデータと第2のビデオデータの切り替えまでの特定の時間
を示す。
【0045】
実施形態(たとえば請求項13を参照されたい)によれば、装置は、ビューポート予測および/もしくは視点予測を提供する予測子を備え、または、装置は、ビューポート予測および/もしくは視点予測を送信機から受信することになり、ビューポート予測は、先読み時間の後にユーザの現在の視線方向からユーザの新しい視線方向への変化が起きることを示し、視点予測は、先読み時間の後にユーザの現在のビューポートからユーザの新しいビューポートへの変化が起きることを示す。
【0046】
実施形態(たとえば請求項14を参照されたい)によれば、視点の変化は、
-制約され、たとえばユーザがアクセスできる複数の離散的な視点に制約され、または、
-制約されず、たとえば、ユーザは仮想シーンの中を完全に動き回ることが許される。
-制約され、たとえばユーザがアクセスできる複数の離散的な視点に制約され、または、
-制約されず、たとえば、ユーザは仮想シーンの中を完全に動き回ることが許される。
【0047】
実施形態(たとえば請求項15を参照されたい)によれば、ビューポート予測および/または視点予測に応答して、装置は、たとえば、予測の正確さ、先読み時間、およびラウンドトリップタイム(RTT)に基づいて、シグナリングされるべき具体的なビューポートおよび/または視点を決定し、フィードバックメッセージ、たとえばRTCPフィードバックメッセージを使用して、具体的なビューポートおよび/または視点を送信機にシグナリングすることになる。
【0048】
実施形態(たとえば請求項16を参照されたい)によれば、イマーシブメディアセッションの最初において、装置は、装置および/または送信機における予測能力に基づいて、特定の閾値の値を送信機とネゴシエートすることになる。
【0049】
実施形態(たとえば請求項17を参照されたい)によれば、予測能力は、視点ごとの予測の正確さを含み、視点ごとの予測の正確さは、ユーザが最も見る可能性の高い目立つエリアの数のような、視点のコンテンツ特性に応じて、別の視点より予測が難しいものとしてある視点を分類し得る。
【0050】
実施形態(たとえば請求項18を参照されたい)によれば、
装置は、送信機が装置からのビューポート予測および/もしくは視点予測を受け入れるかどうか、ならびに/または、送信機がビューポート予測および/もしくは視点予測を実行するかどうかを、送信機が決定することを可能にするために、送信機に、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さをシグナリングし、ビューポート予測および/または視点予測を装置がそれとともに実行する先読み時間をシグナリングすることになり、
装置は、たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または送信機によって実行されるべきかを示すシグナリングを、送信機から受信することになる。
装置は、送信機が装置からのビューポート予測および/もしくは視点予測を受け入れるかどうか、ならびに/または、送信機がビューポート予測および/もしくは視点予測を実行するかどうかを、送信機が決定することを可能にするために、送信機に、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さをシグナリングし、ビューポート予測および/または視点予測を装置がそれとともに実行する先読み時間をシグナリングすることになり、
装置は、たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または送信機によって実行されるべきかを示すシグナリングを、送信機から受信することになる。
【0051】
実施形態(たとえば請求項19を参照されたい)によれば、
装置は、送信機または装置がビューポート予測および/もしくは視点予測を実行するかどうかを決定することになり、
装置は、たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または送信機によって実行されるべきかを、送信機にシグナリングすることになる。
装置は、送信機または装置がビューポート予測および/もしくは視点予測を実行するかどうかを決定することになり、
装置は、たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または送信機によって実行されるべきかを、送信機にシグナリングすることになる。
【0052】
実施形態(たとえば請求項20を参照されたい)によれば、イマーシブメディアセッションの間に、
ビューポート予測および/または視点予測が送信機によって実行されるべきである場合、装置は、ビューポート予測および/または視点予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、視点、報告間隔、速度もしくは加速度に対する要求を、送信機から受信することになり、
ビューポート予測および/または視点予測が装置によって実行されるべきである場合、装置は、特定の視線方向および/または特定の視点についての装置によって使用されるべき特定の予測情報を、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、送信機から受信することになる。
ビューポート予測および/または視点予測が送信機によって実行されるべきである場合、装置は、ビューポート予測および/または視点予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、視点、報告間隔、速度もしくは加速度に対する要求を、送信機から受信することになり、
ビューポート予測および/または視点予測が装置によって実行されるべきである場合、装置は、特定の視線方向および/または特定の視点についての装置によって使用されるべき特定の予測情報を、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、送信機から受信することになる。
【0053】
実施形態(たとえば請求項21を参照されたい)によれば、シーンが複数の視点を含み、装置が予測を実行すべきである場合、装置は、以前のセンサデータを分析し、現在の視点内で切り替えが発生することになる可能性がより高いか、または視点が変化する可能性がより高いかを決定することになる。
【0054】
実施形態(たとえば請求項22を参照されたい)によれば、装置は、たとえばRTCP報告において、特定の視線方向および/または特定の視点に対する受信されたビデオデータが実際の視線の向きおよび/または実際の視点と一致しないことをシグナリングする、誤差またはドリフトの指示を送信機に送信することになる。
【0055】
実施形態(たとえば請求項23を参照されたい)によれば、装置は、最悪の場合のドリフトまたは平均のドリフトをシグナリングすることになり、平均のドリフトは、特定の期間にわたる、予測されるビューポートまたは視点と、実際の視線の向きまたは視点位置との比としてシグナリングされ、最悪の場合のドリフトは、特定の期間にわたって得られる最大のドリフト値としてシグナリングされる。
【0056】
実施形態(たとえば請求項24を参照されたい)によれば、ドリフトがある具体的な方向である場合、たとえば、予測されるビューポートおよび/または予測される視点が予測される方向におけるより小さい動きに対応する場合、装置はドリフトの方向をシグナリングすることになる。
【0057】
実施形態(たとえば請求項25を参照されたい)によれば、装置が第1のビデオデータを処理し、平均のドリフトが特定の期間の間特定の閾値を上回り、または最悪の場合のドリフトが特定の閾値を超える場合、装置は、第1のビデオデータから第2のビデオデータに切り替えると決定することになる。
【0058】
実施形態(たとえば請求項26を参照されたい)によれば、装置は、フォービエイテッドレンダリングの動作モードと一致するコンテンツを送信機が提供することを可能にするために、フォービエイテッドレンダリングを使用し、フォービエイテッドレンダリングアルゴリズムにおいて使用されるそれぞれのパラメータを送信機にシグナリングすることになる。
【0059】
実施形態(たとえば請求項27を参照されたい)によれば、フォービエイテッドレンダリングアルゴリズムにおいて使用されるパラメータは、
-視線方向の中心までの距離に基づく品質のパラメータ化された関数として使用される降格関数、または
-コンテンツの品質の降格につながる領域もしくは距離の閾値、または、
-送信機が送信を適合させること、たとえば、通常はユーザにより見つめられない外側の部分をより低いピクセル密度で符号化することを可能にするための、ある期間にわたり平均化された眼の動きのエリアの時間的な分布、たとえば、95%の時間、視線方向がビューポートの80%をカバーするエリアを見つめていること
を備える。
-視線方向の中心までの距離に基づく品質のパラメータ化された関数として使用される降格関数、または
-コンテンツの品質の降格につながる領域もしくは距離の閾値、または、
-送信機が送信を適合させること、たとえば、通常はユーザにより見つめられない外側の部分をより低いピクセル密度で符号化することを可能にするための、ある期間にわたり平均化された眼の動きのエリアの時間的な分布、たとえば、95%の時間、視線方向がビューポートの80%をカバーするエリアを見つめていること
を備える。
【0060】
イマーシブメディアの提示のための送信機/サーバ
本発明は、イマーシブメディアコンテンツを受信機に提供するための装置を提供し(たとえば請求項28を参照されたい)
装置は、
受信機においてイマーシブメディアコンテンツを表示するための特定の視線方向および/または特定の視点の指示を受信機から受信し、
特定の視線方向および/または特定の視点に対するイマーシブメディアコンテンツを表現するビデオデータを受信機に送信する
ことになる。
本発明は、イマーシブメディアコンテンツを受信機に提供するための装置を提供し(たとえば請求項28を参照されたい)
装置は、
受信機においてイマーシブメディアコンテンツを表示するための特定の視線方向および/または特定の視点の指示を受信機から受信し、
特定の視線方向および/または特定の視点に対するイマーシブメディアコンテンツを表現するビデオデータを受信機に送信する
ことになる。
【0061】
実施形態(たとえば請求項29を参照されたい)によれば、装置は、
(i)イマーシブコンテンツを表現するビデオデータの特定の視線方向および/もしくは特定の視点の2Dビューポートバージョンを表現する第1のビデオデータ、または
(ii)送信されるべきイマーシブコンテンツの少なくとも一部を表現する第2のビデオデータを提供し、
第1のビデオデータが提供されるべきである場合、ビデオデータをレンダリングし、レンダリングされたビデオデータを符号化し、符号化されたビデオデータを受信機に送信し、
第2のビデオデータが提供されるべきである場合、レンダリングすることなくビデオデータを符号化し、イマーシブコンテンツのパラメータを記述する1つまたは複数のメッセージ、たとえば補足強化情報(SEI)メッセージを符号化し、符号化されたビデオデータおよび符号化された1つまたは複数のメッセージを受信機に送信する
ことになる。
(i)イマーシブコンテンツを表現するビデオデータの特定の視線方向および/もしくは特定の視点の2Dビューポートバージョンを表現する第1のビデオデータ、または
(ii)送信されるべきイマーシブコンテンツの少なくとも一部を表現する第2のビデオデータを提供し、
第1のビデオデータが提供されるべきである場合、ビデオデータをレンダリングし、レンダリングされたビデオデータを符号化し、符号化されたビデオデータを受信機に送信し、
第2のビデオデータが提供されるべきである場合、レンダリングすることなくビデオデータを符号化し、イマーシブコンテンツのパラメータを記述する1つまたは複数のメッセージ、たとえば補足強化情報(SEI)メッセージを符号化し、符号化されたビデオデータおよび符号化された1つまたは複数のメッセージを受信機に送信する
ことになる。
【0062】
実施形態(たとえば請求項30を参照されたい)によれば、装置は、受信機と送信機との間のレイテンシに応じて、第1のビデオデータまたは第2のビデオデータを受信機に提供することになる。
【0063】
実施形態(たとえば請求項31を参照されたい)によれば、
装置が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードからイマーシブコンテンツを表現するレンダリングされていないビデオデータを提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、ビデオの処理モードを切り替え、新しいモードに従って処理されるビデオを受信機に提供し、
装置が、第1のフォーマットで2Dビューポートバージョンを表現する第1のビデオデータを提供し、第2のフォーマットでイマーシブコンテンツのレンダリングされていない部分を表現する第2のビデオデータを提供する場合、装置は、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、第1のフォーマットまたは第2のフォーマットを使用してビデオを受信機に送信することになる。
装置が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードからイマーシブコンテンツを表現するレンダリングされていないビデオデータを提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、ビデオの処理モードを切り替え、新しいモードに従って処理されるビデオを受信機に提供し、
装置が、第1のフォーマットで2Dビューポートバージョンを表現する第1のビデオデータを提供し、第2のフォーマットでイマーシブコンテンツのレンダリングされていない部分を表現する第2のビデオデータを提供する場合、装置は、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、第1のフォーマットまたは第2のフォーマットを使用してビデオを受信機に送信することになる。
【0064】
実施形態(たとえば請求項32を参照されたい)によれば、レイテンシは、
-ネットワークレイテンシ、レンダリングレイテンシ、およびコーディングレイテンシのうちの1つまたは複数を備えるエンドツーエンドレイテンシ、
-受信機における特定の視線方向および/または特定の視点の変化の検出から、新しい視線方向および/または新しい視点に対するレンダリングされたビデオデータの表示までの時間である、motion-to-photon(MTP)レイテンシのうちの1つまたは複数を備え、MTPレイテンシは予測先読み時間によって低減され得る。
-ネットワークレイテンシ、レンダリングレイテンシ、およびコーディングレイテンシのうちの1つまたは複数を備えるエンドツーエンドレイテンシ、
-受信機における特定の視線方向および/または特定の視点の変化の検出から、新しい視線方向および/または新しい視点に対するレンダリングされたビデオデータの表示までの時間である、motion-to-photon(MTP)レイテンシのうちの1つまたは複数を備え、MTPレイテンシは予測先読み時間によって低減され得る。
【0065】
実施形態(たとえば請求項33を参照されたい)によれば、
レイテンシが特定の閾値、たとえば15msから20ms以下である場合、装置は第1のビデオデータを受信機に提供することになり、
レイテンシが特定の閾値より大きい場合、装置は、第2のビデオデータを受信機に提供することになる。
レイテンシが特定の閾値、たとえば15msから20ms以下である場合、装置は第1のビデオデータを受信機に提供することになり、
レイテンシが特定の閾値より大きい場合、装置は、第2のビデオデータを受信機に提供することになる。
【0066】
実施形態(たとえば請求項34を参照されたい)によれば、特定の閾値は、
ネットワークレイテンシ、
エンドツーエンドレイテンシ、
最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ、
あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ、
未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
のうちの1つまたは複数である。
ネットワークレイテンシ、
エンドツーエンドレイテンシ、
最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ、
あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ、
未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
のうちの1つまたは複数である。
【0067】
実施形態(たとえば請求項35を参照されたい)によれば、イマーシブメディアセッションの最初において、レイテンシがまだ不明であるとき、装置は、レイテンシが判明するまで、または確実に推定され得るまで、第2のビデオデータのみを提供することになる。
【0068】
実施形態(たとえば請求項36を参照されたい)によれば、
イマーシブメディアセッションの最初において、装置は、受信機とネゴシエートすることになり、
受信機とネゴシエートするとき、装置は、たとえばセッション記述プロトコル(SDP)を使用して、イマーシブコンテンツの1つまたは複数のパラメータ、たとえば補足強化情報(SEI)メッセージを受信機に送信することになる。
イマーシブメディアセッションの最初において、装置は、受信機とネゴシエートすることになり、
受信機とネゴシエートするとき、装置は、たとえばセッション記述プロトコル(SDP)を使用して、イマーシブコンテンツの1つまたは複数のパラメータ、たとえば補足強化情報(SEI)メッセージを受信機に送信することになる。
【0069】
実施形態(たとえば請求項37を参照されたい)によれば、
送信機の1つまたは複数のSDPメッセージはさらに、ビデオデータまたはフォーマットが(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示を含み、
イマーシブメディアセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを送信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、
-第1のビデオデータと第2のビデオデータの即刻の切り替え、または
-第1のビデオデータと第2のビデオデータの切り替えまでの特定の時間
を示す。
送信機の1つまたは複数のSDPメッセージはさらに、ビデオデータまたはフォーマットが(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示を含み、
イマーシブメディアセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを送信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、
-第1のビデオデータと第2のビデオデータの即刻の切り替え、または
-第1のビデオデータと第2のビデオデータの切り替えまでの特定の時間
を示す。
【0070】
実施形態(たとえば請求項38を参照されたい)によれば、装置は、ビューポート予測および/もしくは視点予測を提供する予測子を備え、または、装置は、ビューポート予測および/もしくは視点予測を受信機から受信することになり、ビューポート予測および/または視点予測は、先読み時間の後にユーザの現在の視線方向および/または視点からユーザの新しい視線方向および/または視点への変化が起きることを示す。
【0071】
実施形態(たとえば請求項39を参照されたい)によれば、視点の変化は、
-制約され、たとえばユーザがアクセスできる複数の離散的な視点に制約され、または、
-制約されず、たとえば、ユーザは仮想シーンの中を完全に動き回ることが許される。
-制約され、たとえばユーザがアクセスできる複数の離散的な視点に制約され、または、
-制約されず、たとえば、ユーザは仮想シーンの中を完全に動き回ることが許される。
【0072】
実施形態(たとえば請求項40を参照されたい)によれば、ビューポート予測および/または視点予測に応答して、装置は、たとえば、予測の正確さ、先読み時間、およびラウンドトリップタイム(RTT)に基づいて、提供されるべき具体的なビューポートおよび/または視点を決定することになる。
【0073】
実施形態(たとえば請求項41を参照されたい)によれば、イマーシブメディアセッションの最初において、装置は、装置および/または送信機における予測能力に基づいて、特定の閾値の値を受信機とネゴシエートすることになる。
【0074】
実施形態(たとえば請求項42を参照されたい)によれば、予測能力は、視点ごとの予測の正確さを含み、視点ごとの予測の正確さは、ユーザが最も見る可能性の高い目立つエリアの数のような、視点のコンテンツ特性に応じて、別の視点より予測が難しいものとしてある視点を分類し得る。
【0075】
実施形態(たとえば請求項43を参照されたい)によれば、装置は、
受信機から、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さを受信し、ビューポート予測および/または視点予測を受信機がそれとともに実行する先読み時間を受信し、
装置が受信機からのビューポート予測および/もしくは視点予測を受け入れるかどうか、または、装置がビューポート予測および/もしくは視点予測を実行するかどうかを決定し、
たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または受信機によって実行されるべきかを受信機にシグナリングする
ことになる。
受信機から、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さを受信し、ビューポート予測および/または視点予測を受信機がそれとともに実行する先読み時間を受信し、
装置が受信機からのビューポート予測および/もしくは視点予測を受け入れるかどうか、または、装置がビューポート予測および/もしくは視点予測を実行するかどうかを決定し、
たとえばSDPを介して、ビューポート予測および/もしくは視点予測が装置によって実行されるべきか、ならびに/または受信機によって実行されるべきかを受信機にシグナリングする
ことになる。
【0076】
実施形態(たとえば請求項44を参照されたい)によれば、
ビューポート予測および/または視点予測が装置によって実行されるべきである場合、装置は、ビューポート予測および/または視点予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、視点、報告間隔、速度もしくは加速度を、受信機から受信することになり、
ビューポート予測および/または視点予測が受信機によって実行されるべきである場合、装置は、特定の視線方向および/または視点についての装置によって使用されるべき特定の予測情報を、たとえば、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、受信機に送信することになる。
ビューポート予測および/または視点予測が装置によって実行されるべきである場合、装置は、ビューポート予測および/または視点予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、視点、報告間隔、速度もしくは加速度を、受信機から受信することになり、
ビューポート予測および/または視点予測が受信機によって実行されるべきである場合、装置は、特定の視線方向および/または視点についての装置によって使用されるべき特定の予測情報を、たとえば、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、受信機に送信することになる。
【0077】
実施形態(たとえば請求項45を参照されたい)によれば、シーンが複数の視点を含み、送信機が予測を実行すべきである場合、装置は、現在の視線方向およびシーン内の位置についてのフィードバックを受信機から受信し、切り替えが現在の視点内で起きる可能性が高いかどうか、または視点が変化するかどうかを決定するために、他のユーザまたはコンテンツ情報の統計、たとえば、特定のビューポートのどの空間エリアにおいてユーザが視点を変える可能性がより高いかということとフィードバックを組み合わせることになる。
【0078】
実施形態(たとえば請求項46を参照されたい)によれば、
装置は、たとえばRTCP報告において、特定の視線方向および/または特定の視点に対する受信されたビデオデータが装置における実際の視線の向きおよび/または実際の視点と一致しないことをシグナリングする、誤差またはドリフトの指示を受信機から受信することになり、
誤差またはドリフトに応答して、装置が、たとえば使用されるマージンまたはプリフェッチを適応させることになる。
装置は、たとえばRTCP報告において、特定の視線方向および/または特定の視点に対する受信されたビデオデータが装置における実際の視線の向きおよび/または実際の視点と一致しないことをシグナリングする、誤差またはドリフトの指示を受信機から受信することになり、
誤差またはドリフトに応答して、装置が、たとえば使用されるマージンまたはプリフェッチを適応させることになる。
【0079】
実施形態(たとえば請求項47を参照されたい)によれば、装置は、最悪の場合のドリフトまたは平均のドリフトを受信することになり、平均のドリフトは、ある期間にわたる、予測されるビューポートまたは視点と、実際の視線の向きまたは視点位置との比としてシグナリングされ、最悪の場合のドリフトは、特定の期間にわたって得られる最大のドリフト値としてシグナリングされる。
【0080】
実施形態(たとえば請求項48を参照されたい)によれば、ドリフトがある具体的な方向である場合、たとえば、予測されるビューポートおよび/または予測される視点が予測される方向におけるより小さい動きに対応する場合、装置は、ドリフトの方向を受信し、たとえば一致しない予測の方向におけるプリフェッチを追加することによってその予測を適応させることになる。
【0081】
実施形態(たとえば請求項49を参照されたい)によれば、受信機は、フォービエイテッドレンダリングを使用し、装置は、フォービエイテッドレンダリングアルゴリズムにおいて使用されるそれぞれのパラメータを受信機から受信し、フォービエイテッドレンダリングの動作モードと一致するコンテンツを提供することになる。
【0082】
イマーシブメディアの提示のための受信機/クライアントおよび送信機/サーバ
実施形態(たとえば請求項50を参照されたい)によれば、イマーシブコンテンツは、
-3DoF(3自由度)コンテンツ、たとえば1つまたは複数の360°ビデオ、
-6DoF(6自由度)コンテンツ、たとえば、実際の物体のようなキャプチャされたボリュメトリックオブジェクト、または、たとえば実際の物体のボリュメトリックビデオ、
-たとえば、Computer-Generated Imagery(CGI)のようなコンピュータグラフィクスを使用して生成される3Dオブジェクト
のうちの1つまたは複数を含む。
実施形態(たとえば請求項50を参照されたい)によれば、イマーシブコンテンツは、
-3DoF(3自由度)コンテンツ、たとえば1つまたは複数の360°ビデオ、
-6DoF(6自由度)コンテンツ、たとえば、実際の物体のようなキャプチャされたボリュメトリックオブジェクト、または、たとえば実際の物体のボリュメトリックビデオ、
-たとえば、Computer-Generated Imagery(CGI)のようなコンピュータグラフィクスを使用して生成される3Dオブジェクト
のうちの1つまたは複数を含む。
【0083】
実施形態(たとえば請求項51を参照されたい)によれば、送信機によって送信されるべき、または受信機によって受信されるべきイマーシブコンテンツは、
-360°ビデオまたは360°グラフィックの場合、投影されたビデオ送信、たとえば、ある具体的な投影を使用して送信される完全な360°ビデオの一部、
-ボリュメトリックオブジェクトまたはボリュメトリックビデオの場合、特定の3Dフォーマット、たとえばポイントクラウドまたはメッシュとしての、完全なボリュメトリックオブジェクトまたはボリュメトリックオブジェクトの一部の3Dデータ送信、
-3Dコンピュータグラフィクスの場合、たとえば、複数のポイントクラウドまたはメッシュなどの特定の3Dフォーマットの、ゲーム、完全なシーン、たとえば複数のボリュメトリックオブジェクト
のうちの1つまたは複数を含む。
-360°ビデオまたは360°グラフィックの場合、投影されたビデオ送信、たとえば、ある具体的な投影を使用して送信される完全な360°ビデオの一部、
-ボリュメトリックオブジェクトまたはボリュメトリックビデオの場合、特定の3Dフォーマット、たとえばポイントクラウドまたはメッシュとしての、完全なボリュメトリックオブジェクトまたはボリュメトリックオブジェクトの一部の3Dデータ送信、
-3Dコンピュータグラフィクスの場合、たとえば、複数のポイントクラウドまたはメッシュなどの特定の3Dフォーマットの、ゲーム、完全なシーン、たとえば複数のボリュメトリックオブジェクト
のうちの1つまたは複数を含む。
【0084】
実施形態(たとえば請求項52を参照されたい)によれば、イマーシブコンテンツは、
-特定の補足強化情報(SEI)パラメータ、たとえばsprop-seiパラメータ、
-具体的なビデオコーデックもしくはプロファイルの指示、または、
-セッション記述プロトコル(SDP)における追加の属性、たとえば、「videoformat 3DoF」、「videoformat 6DoF」、または「videoformat Volumetric」
によって特定されることになる。
-特定の補足強化情報(SEI)パラメータ、たとえばsprop-seiパラメータ、
-具体的なビデオコーデックもしくはプロファイルの指示、または、
-セッション記述プロトコル(SDP)における追加の属性、たとえば、「videoformat 3DoF」、「videoformat 6DoF」、または「videoformat Volumetric」
によって特定されることになる。
【0085】
実施形態(たとえば請求項53を参照されたい)によれば、イマーシブコンテンツが1つまたは複数のボリュメトリックオブジェクトを含むボリュメトリックシーンを表現する場合、イマーシブコンテンツは、ボリュメトリックオブジェクトのそれぞれの性質を記述するための複数のビットストリーム、たとえば、少なくともテクスチャビットストリームおよびジオメトリビットストリーム、または圧縮されたメッシュビットストリームおよびテクスチャビットストリームを含む。
【0086】
実施形態(たとえば請求項54を参照されたい)によれば、異なるビットストリームの使用は、たとえばSDPを使用してシグナリングされ、SDPは、異なる種類のビットストリームおよびビットストリームのあり得る変形についての情報を含み得る。
【0087】
実施形態(たとえば請求項55を参照されたい)によれば、ボリュメトリックオブジェクトのそれぞれの性質を記述する複数のビットストリームは、たとえばSDPのグループ化機構を使用して互いと関連付けられる。
【0088】
イマーシブメディアの提示のためのシステム
本発明は、本発明の実施形態のいずれか1つに従った装置を含む送信機と、本発明の実施形態のいずれか1つに従った装置を含む受信機とを備える、システムを提供する(たとえば請求項56を参照されたい)。
本発明は、本発明の実施形態のいずれか1つに従った装置を含む送信機と、本発明の実施形態のいずれか1つに従った装置を含む受信機とを備える、システムを提供する(たとえば請求項56を参照されたい)。
【0089】
イマーシブメディアの提示のための方法
本発明は、イマーシブメディアコンテンツを提示するための方法を提供し(たとえば請求項57を参照されたい)、方法は、
受信機によって、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを送信機から取得するステップと、
受信機において、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを表示するステップとを備える。
本発明は、イマーシブメディアコンテンツを提示するための方法を提供し(たとえば請求項57を参照されたい)、方法は、
受信機によって、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを送信機から取得するステップと、
受信機において、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを表示するステップとを備える。
【0090】
本発明は、イマーシブメディアコンテンツを提供するための方法を提供し(たとえば請求項58を参照されたい)、方法は、
送信機において、受信機においてイマーシブコンテンツを表示するための特定の視線方向および/または特定の視点の指示を受信するステップと、
送信機によって、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを受信機に送信するステップとを備える。
送信機において、受信機においてイマーシブコンテンツを表示するための特定の視線方向および/または特定の視点の指示を受信するステップと、
送信機によって、特定の視線方向および/または特定の視点に対するイマーシブコンテンツを表現するビデオデータを受信機に送信するステップとを備える。
【0091】
実施形態(たとえば請求項59を参照されたい)によれば、受信機は、本発明の実施形態のいずれか1つに従った装置を含み、および/または、送信機は、本発明の実施形態のいずれか1つに従った装置を含む。
【0092】
360°ビデオ通信のための受信機/クライアント
本発明は、送信機との360°ビデオ通信のための装置を提供し(たとえば請求項61を参照されたい)、
装置は、360°ビデオの特定の視線方向に応じてビデオデータを送信機から取得し、360°ビデオの特定の視線方向を表現するビデオデータを表示することになる。
本発明は、送信機との360°ビデオ通信のための装置を提供し(たとえば請求項61を参照されたい)、
装置は、360°ビデオの特定の視線方向に応じてビデオデータを送信機から取得し、360°ビデオの特定の視線方向を表現するビデオデータを表示することになる。
【0093】
実施形態(たとえば請求項62を参照されたい)によれば、送信機からビデオデータを取得するために、装置は、360°ビデオの特定の視線方向を送信機にシグナリングし、360°ビデオの特定の視線方向に対するビデオデータを送信機から受信することになる。
【0094】
実施形態(たとえば請求項63を参照されたい)によれば、装置は、360°ビデオの特定の視線方向に対するビデオデータをユーザに表示するための表示デバイス、たとえばHMDと、ユーザの視線方向を検出するためのセンサと、検出された視線方向を送信機にシグナリングし、受信されたビデオデータを表示デバイス上での表示のために処理するためのプロセッサとを備える。
【0095】
実施形態(たとえば請求項64を参照されたい)によれば、装置は、360°ビデオの特定の視線方向について、送信機からの、(i)送信機によってレンダリングされ、360°ビデオの特定の視線方向の2Dビューポートバージョンを表現する第1のビデオデータ、または(ii)送信機によってレンダリングされず、特定の投影を使用して送信機によって送信されるべき360°ビデオの少なくとも一部を表現する第2のビデオデータを要求することになる。
【0096】
実施形態(たとえば請求項65を参照されたい)によれば、360°ビデオ通信のセッションの間に、装置は、受信機と送信機との間のエンドツーエンドレイテンシに応じて、送信機からの第1のビデオデータまたは第2のビデオデータを要求することになる。
【0097】
実施形態(たとえば請求項66を参照されたい)によれば、エンドツーエンドレイテンシは、受信機における特定の視線方向の変化の検出から、新しい視線方向に対するレンダリングされたビデオデータを表示するまでの時間である。
【0098】
実施形態(たとえば請求項77を参照されたい)によれば、装置は、エンドツーエンドレイテンシが特定の閾値、たとえば15msから20ms以下である場合、送信機からの第1のビデオデータを要求することになり、エンドツーエンドレイテンシが特定の閾値より大きい場合、装置は、送信機からの第2のビデオデータを要求することになる。
【0099】
実施形態(たとえば請求項88を参照されたい)によれば、送信機が、第1のフォーマットで2Dビューポートバージョンを表現する第1のビデオデータを提供し、第2のフォーマットで360°ビデオのレンダリングされていない部分を表現する第2のビデオデータを提供する場合、装置は、第1のフォーマットと第2のフォーマットの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、もしくはメッセージの後の特定の時間に、送信機に送信することになり、または、送信機が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードから360°ビデオのレンダリングされていない部分を提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、第1のモードと第2のモードの切り替えを要求するメッセージ、たとえばRTCPメッセージを、直ちに、もしくはメッセージの後の特定の時間に、送信機に送信することになる。
【0100】
実施形態(たとえば請求項69を参照されたい)によれば、特定の閾値は、たとえば、あらかじめ定められた体験品質(QoE)を生む最大のもしくは許容可能なmotion-to-photon(MTP)レイテンシ、または、MTPレイテンシと未来を見るための予測子の時間的能力を示す予測先読み時間とを足したものである。
【0101】
実施形態(たとえば請求項70を参照されたい)によれば、360°ビデオ通信のセッションの最初において、エンドツーエンドレイテンシがまだ不明であるとき、装置は、エンドツーエンドレイテンシが判明するまで、または確実に推定され得るまで、第2のビデオデータのみを受け入れることになる。
【0102】
実施形態(たとえば請求項71を参照されたい)によれば、360°ビデオ通信のセッションの最初において、装置は送信機とネゴシエートすることになり、送信機とネゴシエートするとき、装置は、たとえばセッション記述プロトコル(SDP)を使用して、360°ビデオの1つまたは複数のパラメータ、たとえば、投影タイプ、回転、およびregion-wise packing (RWP)制約のうちの1つまたは複数を示す補足強化情報(SEI)メッセージを、送信機から受信することになる。
【0103】
実施形態(たとえば請求項72を参照されたい)によれば、送信機とネゴシエートするとき、たとえばSDPを使用して、装置は、装置の能力に従って360°ビデオの1つまたは複数の追加のパラメータを含め、および/または、装置の能力に従って、360°ビデオのパラメータのうちの1つまたは複数を修正もしくは削除し、
送信機が送信された360°ビデオのパラメータに従って投影されたビデオを符号化することを可能にするために、360°ビデオのパラメータを送信機に送信することになる。
送信機が送信された360°ビデオのパラメータに従って投影されたビデオを符号化することを可能にするために、360°ビデオのパラメータを送信機に送信することになる。
【0104】
実施形態(たとえば請求項73を参照されたい)によれば、360°ビデオのパラメータのうちの1つまたは複数は、Region-Wise Packing (RWP)パラメータを備え、装置は、RWPフォーマットを装置の能力へと制約するために1つまたは複数の新しい要素をSDPメッセージに含めることになり、RWPフォーマットは、たとえば、以下の制約のうちの1つまたは複数を示し得る。
・パッキングされる領域の最大の数を示すrwp-max-num-packed-regions
・投影される領域の最小の幅/高さを示すrwp-min-proj-region-width/height
・パッキングされる領域の最小の幅/高さを示すrwp-min-packed-region-width/height
・許容される変換タイプを示すrwp-allowed-transform-types
・パッキングされる領域の周りのガードバンドを示すrwp-guard-band-flag-constraint
・パッキングされる領域に対する最大のスケーリング係数を示すrwp-max-scaling-factor
・パッキングされる領域の最大の数を示すrwp-max-num-packed-regions
・投影される領域の最小の幅/高さを示すrwp-min-proj-region-width/height
・パッキングされる領域の最小の幅/高さを示すrwp-min-packed-region-width/height
・許容される変換タイプを示すrwp-allowed-transform-types
・パッキングされる領域の周りのガードバンドを示すrwp-guard-band-flag-constraint
・パッキングされる領域に対する最大のスケーリング係数を示すrwp-max-scaling-factor
【0105】
実施形態(たとえば請求項74を参照されたい)によれば、送信機とネゴシエートするとき、装置は、ビデオデータまたはフォーマットが、(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示をさらに送信機から受信することになり、360°ビデオ通信のセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを受信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータとの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、第1のビデオデータと第2のビデオデータとの即刻の切り替え、または、第1のビデオデータと第2のビデオデータとの切り替えまでの特定の時間を示す。
【0106】
実施形態(たとえば請求項75を参照されたい)によれば、装置は、ビューポート予測を提供するビューポート予測子を備え、または、装置は、ビューポート予測を送信機から受信することになり、ビューポート予測は、先読み時間の後にユーザの現在の視線方向からユーザの新しい視線方向への変化が起きることを示す。
【0107】
実施形態(たとえば請求項76を参照されたい)によれば、ビューポート予測に応答して、装置は、たとえば、予測の正確さ、先読み時間、およびラウンドトリップタイム(RTT)に基づいて、要求されるべき具体的なビューポートを決定し、フィードバックメッセージ、たとえばRTCPフィードバックメッセージを使用して、具体的なビューポートを送信機にシグナリングすることになる。
【0108】
実施形態(たとえば請求項77を参照されたい)によれば、360°ビデオ通信のセッションの最初において、装置は、装置および/または送信機における予測能力に基づいて、特定の閾値の値を送信機とネゴシエートすることになる。
【0109】
実施形態(たとえば請求項78を参照されたい)によれば、装置は、送信機が装置からのビューポート予測を受け入れるかどうか、または、送信機がビューポート予測を実行するかどうかを、送信機が決定することを可能にするために、送信機に、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さをシグナリングし、ビューポート予測を装置がそれとともに実行する先読み時間をシグナリングすることになり、装置は、たとえばSDPを介して、ビューポート予測が装置によって実行されるべきか、または受信機によって実行されるべきかを示すシグナリングを送信機から受信することになる。
【0110】
実施形態(たとえば請求項79を参照されたい)によれば、装置は、送信機または装置がビューポート予測を実行するかどうかを決定することになり、装置は、たとえばSDPを介して、ビューポート予測が装置によって実行されるべきか、または送信機によって実行されるべきかを、送信機にシグナリングすることになる。
【0111】
実施形態(たとえば請求項80を参照されたい)によれば、360°ビデオ通信のセッションの間、ビューポート予測が送信機によって実行されるべきである場合、装置は、ビューポート予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、報告間隔、速度もしくは加速度に対する要求を、送信機から受信することになり、ビューポート予測が装置によって実行されるべきである場合、装置は、特定の視線方向または特定の領域についての装置によって使用されるべき特定の予測情報を、たとえば、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、送信機から受信することになる。
【0112】
実施形態(たとえば請求項81を参照されたい)によれば、ビデオデータは、ビューポートサイズと厳密に一致し、それにより、表示デバイスの視野(FoV)と一致し、または、ビデオデータはビューポートの周りのマージンエリアを含み、マージンエリアはビューポートの特定の割合である。
【0113】
実施形態(たとえば請求項82を参照されたい)によれば、360°ビデオ通信のセッションの間、ビューポートサイズがマージンを含む場合、装置は、装置がビューポートをクロッピング/ワーピングするのを助けるために、レンダリングのために使用されるレンズ/ひずみパラメータの指示を受信することになる。
【0114】
実施形態(たとえば請求項83を参照されたい)によれば、360°ビデオ通信のセッションの最初において、装置は、ビデオデータの寸法および/またはマージンエリアについて送信機とネゴシエートすることになる。
【0115】
実施形態(たとえば請求項84を参照されたい)によれば、装置は、たとえばRTCP報告において、特定の視線方向に対する受信されたビデオデータが装置における実際の視線の向きと一致しないことをシグナリングする誤差またはドリフトの指示を送信機に送信することになる。
【0116】
実施形態(たとえば請求項85を参照されたい)によれば、装置は、最悪の場合のドリフトまたは平均のドリフトをシグナリングすることになり、平均のドリフトは、ある期間にわたる、予測されるビューポートと実際の視線の向きとの比としてシグナリングされ、最悪の場合のドリフトは、特定の期間にわたって得られる最大のドリフト値としてシグナリングされる。
【0117】
実施形態(たとえば請求項86を参照されたい)によれば、ドリフトが特定の方向である場合、たとえば、予測されるビューポートが予測される方向におけるより小さい動きに対応する場合、装置はドリフトの方向をシグナリングすることになる。
【0118】
実施形態(たとえば請求項87を参照されたい)によれば、装置が第1のビデオデータを処理し、平均のドリフトが特定の期間の間特定の閾値を上回り、または最悪の場合のドリフトが特定の閾値を超える場合、装置は、第1のビデオデータから第2のビデオデータに切り替えると決定することになる。
【0119】
実施形態(たとえば請求項88を参照されたい)によれば、装置は、フォービエイテッドレンダリングの動作モードと一致するコンテンツを送信機が提供することを可能にするために、フォービエイテッドレンダリングを使用し、フォービエイテッドレンダリングアルゴリズムにおいて使用されるそれぞれのパラメータを送信機にシグナリングすることになる。
【0120】
実施形態(たとえば請求項89を参照されたい)によれば、フォービエイテッドレンダリングアルゴリズムにおいて使用されるパラメータは、視線方向の中心までの距離に基づく品質のパラメータ化された関数として使用される降格関数、または、コンテンツの品質の降格につながる領域もしくは距離の閾値、または、送信機が送信を適合させること、たとえば、通常はユーザにより見つめられない外側の部分をより低いピクセル密度で符号化することを可能にするための、ある期間にわたり平均化された眼の動きのエリアの時間的な分布、たとえば、95%の時間、視線方向がビューポートの80%をカバーするエリアを見つめていることを備える。
【0121】
360°ビデオ通信のための送信機/サーバ
本発明は、受信機を伴う360°ビデオ通信のための装置を提供し(たとえば請求項90を参照されたい)、装置は、受信機における360°ビデオの特定の視線方向の指示を受信機から受信し、360°ビデオの特定の視線方向に対するビデオデータを受信機に送信することになる。
本発明は、受信機を伴う360°ビデオ通信のための装置を提供し(たとえば請求項90を参照されたい)、装置は、受信機における360°ビデオの特定の視線方向の指示を受信機から受信し、360°ビデオの特定の視線方向に対するビデオデータを受信機に送信することになる。
【0122】
実施形態(たとえば請求項91を参照されたい)によれば、装置は、(i)360°ビデオの特定の視線方向の2Dビューポートバージョンを表現する第1のビデオデータ、または、(ii)特定の投影を使用して、送信されるべき360°ビデオの少なくとも一部を表現する第2のビデオデータを提供し、第1のビデオデータが提供されるべきである場合、ビデオデータをレンダリングし、レンダリングされたビデオデータを符号化し、符号化されたビデオデータを受信機に送信し、第2のビデオデータが提供されるべきである場合、レンダリングすることなく、特定の投影を使用してビデオデータを符号化し、投影タイプ、回転、およびregion-wise packing (RWP)制約を示す、360°ビデオのパラメータを記述する1つまたは複数のメッセージ、たとえば補足強化情報(SEI)メッセージを符号化し、符号化されたビデオデータおよび符号化された1つまたは複数のメッセージを受信機に送信することになる。
【0123】
実施形態(たとえば請求項92を参照されたい)によれば、装置は、受信機と送信機との間のエンドツーエンドレイテンシに応じて、第1のビデオデータまたは第2のビデオデータを受信機に提供することになる。
【0124】
実施形態(たとえば請求項93を参照されたい)によれば、装置が、同じフォーマットを使用して第1のビデオデータおよび第2のビデオデータを提供し、2Dビューポートバージョンを提供するための第1の処理モードから360°ビデオのレンダリングされていない部分を提供するための第2の処理モードへの動的な切り替えを可能にする場合、装置は、第1のモードと第2のモードを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、要求に応答して、ビデオの処理モードを切り替え、新しいモードに従って処理されるビデオを受信機に提供することになり、
装置が、第1のフォーマットで2Dビューポートバージョンを表現する第1のビデオデータを提供し、第2のフォーマットで360°ビデオのレンダリングされていない部分を表現する第2のビデオデータを提供する場合、装置が、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、第1のフォーマットまたは第2のフォーマットを使用してビデオを受信機に送信することになる。
装置が、第1のフォーマットで2Dビューポートバージョンを表現する第1のビデオデータを提供し、第2のフォーマットで360°ビデオのレンダリングされていない部分を表現する第2のビデオデータを提供する場合、装置が、
第1のフォーマットと第2のフォーマットを切り替えるための要求メッセージ、たとえばRTCPメッセージを、直ちに、またはメッセージの後の特定の時間に、受信機から受信し、
要求に応答して、第1のフォーマットまたは第2のフォーマットを使用してビデオを受信機に送信することになる。
【0125】
実施形態(たとえば請求項94を参照されたい)によれば、エンドツーエンドレイテンシは、受信機における特定の視線方向の変化の検出から、新しい視線方向に対するレンダリングされたビデオデータを表示するまでの時間である。
【0126】
実施形態(たとえば請求項95を参照されたい)によれば、装置は、第1のビデオデータを受信機に提供することになり、エンドツーエンドレイテンシが特定の閾値、たとえば15msから20ms以下である場合、装置は第1のビデオデータを受信機に提供することになり、エンドツーエンドレイテンシが特定の閾値より大きい場合、装置は、第2のビデオデータを受信機に提供することになる。
【0127】
実施形態(たとえば請求項96を参照されたい)によれば、特定の閾値は、たとえば、あらかじめ定められた体験品質(QoE)を生む最大のもしくは許容可能なmotion-to-photon(MTP)レイテンシ、または、MTPレイテンシと未来を見るための予測子の時間的能力を示す予測先読み時間とを足したものである。
【0128】
実施形態(たとえば請求項97を参照されたい)によれば、360°ビデオ通信のセッションの最初において、エンドツーエンドレイテンシがまだ不明であるとき、装置は、エンドツーエンドレイテンシが判明するまで、または確実に推定され得るまで、第2のビデオデータのみを提供することになる。
【0129】
実施形態(たとえば請求項98を参照されたい)によれば、360°ビデオ通信のセッションの最初において、装置は受信機とネゴシエートすることになり、受信機とネゴシエートするとき、装置は、受信機に、たとえばセッション記述プロトコル(SDP)を使用して、360°ビデオの1つまたは複数のパラメータ、たとえば、投影タイプ、回転、およびregion-wise packing (RWP)制約のうちの1つまたは複数を示す補足強化情報(SEI)メッセージを、受信機に送信することになる。
【0130】
実施形態(たとえば請求項99を参照されたい)によれば、受信機とネゴシエートするとき、たとえばSDPを使用して、装置は、受信機の能力に従った360°ビデオの1つまたは複数の追加のパラメータを、および/または、受信機の能力に従った数が修正されまたは減らされた360°ビデオの1つまたは複数のパラメータを、受信機から受信し、受信されたパラメータに従って、投影されたビデオの符号化をスケジューリングすることになる。
【0131】
実施形態(たとえば請求項100を参照されたい)によれば、360°ビデオのパラメータのうちの1つまたは複数は、Region-Wise Packing (RWP)パラメータを備え、装置は、RWPフォーマットを装置の能力へと制約するために1つまたは複数の新しい要素をSDPメッセージに含めることになり、RWPフォーマットは、たとえば、以下の制約のうちの1つまたは複数を示し得る。
・パッキングされる領域の最大の数を示すrwp-max-num-packed-regions
・投影される領域の最小の幅/高さを示すrwp-min-proj-region-width/height
・パッキングされる領域の最小の幅/高さを示すrwp-min-packed-region-width/height
・許容される変換タイプを示すrwp-allowed-transform-types
・パッキングされる領域の周りのガードバンドを示すrwp-guard-band-flag-constraint
・パッキングされる領域に対する最大のスケーリング係数を示すrwp-max-scaling-factor
・パッキングされる領域の最大の数を示すrwp-max-num-packed-regions
・投影される領域の最小の幅/高さを示すrwp-min-proj-region-width/height
・パッキングされる領域の最小の幅/高さを示すrwp-min-packed-region-width/height
・許容される変換タイプを示すrwp-allowed-transform-types
・パッキングされる領域の周りのガードバンドを示すrwp-guard-band-flag-constraint
・パッキングされる領域に対する最大のスケーリング係数を示すrwp-max-scaling-factor
【0132】
実施形態(たとえば請求項101を参照されたい)によれば、送信機の1つまたは複数のSDPメッセージはさらに、ビデオデータまたはフォーマットが、(i)第1のビデオデータと(ii)第2のビデオデータとの間で動的に切り替え可能であることの指示を含み、360°ビデオ通信のセッションの間に、装置は、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを送信することになり、ビデオデータパケットは、第1のビデオデータと第2のビデオデータとの切り替えを示すために、たとえばRTPヘッダ拡張を使用してマークされてもよく、マークされたビデオデータパケットは、第1のビデオデータと第2のビデオデータとの即刻の切り替え、または、第1のビデオデータと第2のビデオデータとの切り替えまでの特定の時間を示す。
【0133】
実施形態(たとえば請求項102を参照されたい)によれば、装置は、ビューポート予測を提供するビューポート予測子を備え、または、装置は、ビューポート予測を受信機から受信することになり、ビューポート予測は、先読み時間の後に受信機のユーザの現在の視線方向からユーザの新しい視線方向への変化が起きることを示す。
【0134】
実施形態(たとえば請求項103を参照されたい)によれば、ビューポート予測に応答して、装置は、たとえば、予測の正確さ、先読み時間、およびラウンドトリップタイム(RTT)に基づいて、提供されるべき具体的なビューポートを決定することになる。
【0135】
実施形態(たとえば請求項104を参照されたい)によれば、360°ビデオ通信のセッションの最初において、装置は、装置および/または送信機における予測能力に基づいて、特定の閾値の値を受信機とネゴシエートすることになる。
【0136】
実施形態(たとえば請求項105を参照されたい)によれば、装置は、たとえばSDPを介して、たとえば経時的なドリフトまたは予測と現実の重複の形式で正確さを受信機から受信し、ビューポート予測を受信機がそれとともに実行する先読み時間を受信し、装置が受信機からのビューポート予測を受け入れるかどうか、または装置がビューポート予測を実行するかどうかを決定し、たとえばSDPを介して、ビューポート予測が装置によって実行されるべきか、または受信機によって実行されるべきかを、受信機にシグナリングすることになる。
【0137】
実施形態(たとえば請求項106を参照されたい)によれば、ビューポート予測が装置によって実行されるべきである場合、装置は、ビューポート予測を実行するために送信機において必要とされる特定のパラメータ、たとえば、視線方向、報告間隔、速度もしくは加速度を、受信機から受信することになり、ビューポート予測が受信機によって実行されるべきである場合、装置は、特定の視線方向または特定の領域についての装置によって使用されるべき特定の予測情報を、たとえば、コンテンツ特性についての送信機の知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識に基づいて、受信機に送信することになる。
【0138】
実施形態(たとえば請求項107を参照されたい)によれば、第1のビデオデータは、ビューポートサイズと厳密に一致し、それにより、表示デバイスの視野(FoV)と一致し、または、第1のビデオデータはビューポートの周りのマージンエリアを含み、マージンエリアはビューポートの特定の割合である。
【0139】
実施形態(たとえば請求項108を参照されたい)によれば、360°ビデオ通信のセッションの間、ビューポートサイズがマージンを含む場合、装置は、受信機がビューポートをクロッピング/ワーピングするのを助けるために、レンダリングのために使用されるレンズ/ひずみパラメータの指示を受信機に送信することになる。
【0140】
実施形態(たとえば請求項109を参照されたい)によれば、装置は、第1のビデオデータの寸法および/またはマージンエリアについて受信機とネゴシエートすることになる。
【0141】
実施形態(たとえば請求項110を参照されたい)によれば、装置は、たとえばRTCP報告において、特定の視線方向に対する受信されたビデオデータが装置における実際の視線の向きと一致しないことをシグナリングする、誤差またはドリフトの指示を受信機から受信することになり、誤差またはドリフトに応答して、装置は、たとえば使用されるマージンもしくはプリフェッチを適応させ、または、たとえば高品質のコンテンツのカバレッジをより大きくまたは小さくするために、視線の向きに固有の投影を変更することになる。
【0142】
実施形態(たとえば請求項111を参照されたい)によれば、装置は、最悪の場合のドリフトまたは平均のドリフトを受信することになり、平均のドリフトは、ある期間にわたる、予測されるビューポートと実際の視線の向きとの比としてシグナリングされ、最悪の場合のドリフトは、特定の期間にわたって得られる最大のドリフト値としてシグナリングされる。
【0143】
実施形態(たとえば請求項112を参照されたい)によれば、ドリフトが特定の方向である場合、たとえば、予測されるビューポートが予測される方向におけるより小さい動きに対応する場合、装置は、ドリフトの方向を受信し、たとえば一致しない予測の方向におけるプリフェッチを追加することによってその予測を適応させることになる。
【0144】
実施形態(たとえば請求項113を参照されたい)によれば、受信機は、フォービエイテッドレンダリングを使用し、装置は、フォービエイテッドレンダリングアルゴリズムにおいて使用されるそれぞれのパラメータを受信機から受信し、フォービエイテッドレンダリングの動作モードと一致するコンテンツを提供することになる。
【0145】
360°ビデオ通信のためのシステム
本発明は、360°ビデオ通信システムを提供し(たとえば請求項114を参照されたい)、これは、本発明の実施形態のいずれか1つに従った装置を含む送信機と、本発明の実施形態のいずれか1つに従った装置を含む受信機とを備える。
本発明は、360°ビデオ通信システムを提供し(たとえば請求項114を参照されたい)、これは、本発明の実施形態のいずれか1つに従った装置を含む送信機と、本発明の実施形態のいずれか1つに従った装置を含む受信機とを備える。
【0146】
360°ビデオ通信のための方法
本発明は、360°ビデオ通信のための方法を提供し(たとえば請求項115を参照されたい)、方法は、受信機によって、受信機における360°ビデオの特定の視線方向に応じて送信機からビデオデータを取得するステップと、受信機において、360°ビデオの特定の視線方向を表現するビデオデータを表示するステップとを備える。
本発明は、360°ビデオ通信のための方法を提供し(たとえば請求項115を参照されたい)、方法は、受信機によって、受信機における360°ビデオの特定の視線方向に応じて送信機からビデオデータを取得するステップと、受信機において、360°ビデオの特定の視線方向を表現するビデオデータを表示するステップとを備える。
【0147】
本発明は、360°ビデオ通信のための方法を提供し(たとえば請求項116を参照されたい)、方法は、送信機において、受信機における360°ビデオの特定の視線方向の指示を受信機から受信するステップと、送信機によって、360°ビデオの特定の視線方向に対するビデオデータを受信機に送信するステップとを備える。
【0148】
実施形態(たとえば請求項117を参照されたい)によれば、受信機は、本発明の実施形態のいずれか1つに従った装置を含み、および/または、送信機は、本発明の実施形態のいずれか1つに従った装置を含む。
【0149】
コンピュータプログラム製品
本発明は、プログラムがコンピュータによって実行されると、本発明に従った1つまたは複数の方法をコンピュータに実行させる命令を備える、コンピュータプログラム製品を提供する。
本発明は、プログラムがコンピュータによって実行されると、本発明に従った1つまたは複数の方法をコンピュータに実行させる命令を備える、コンピュータプログラム製品を提供する。
【0150】
本発明の手法のより詳細な実施形態が、ここで説明される。図3は、本発明の実施形態が適用され有利に使用され得る、図2と同様の環境の例を示す。図3は、効率的なイマーシブメディアの通信、またはイマーシブメディアコンテンツの提示、または仮想現実応用のための360°ビデオ通信のために準備される、サーバ200およびクライアント202を含むシステムを示す。システムは、ヘッドアップディスプレイ210を装着するユーザに、たとえばヘッドアップディスプレイ204の内部ディスプレイ212を使用して、特定の視線方向に対応する360°ビデオの一時的に変化する空間シーン216のビュー選択214を提示する。視線方向214のビュー選択は、内部方位センサ218によって測定され得るヘッドアップディスプレイ210の向きに対応し得る。したがって、ユーザに提示される選択214は空間シーン216の選択であり、空間シーン216の空間位置はヘッドアップディスプレイ210の向きに対応する。一時的に変化する空間シーン216は、イマーシブメディアコンテンツ、または、全方位ビデオもしくは全天球ビデオとも呼ばれる360°ビデオである。本発明は、ヘッドアップディスプレイに限定されず、むしろ、他の実施形態によれば、選択214は、普通のモニタなどのような別の表示デバイス上でユーザに表示され得る。センサ218およびディスプレイ210は、リモートコントロールおよび対応するテレビジョンセットなどの、別個のまたは異なるデバイスであり得る。他の実施形態によれば、センサ218およびディスプレイ212は、タブレットまたは携帯電話などの、モバイルデバイスのようなハンドヘルドデバイスの一部であり得る。
【0151】
サーバ200は、たとえば図2のシグナルプロセッサ206を使用して実装されるコントローラ206、およびストレージ220を備え得る。コントローラ206は、適切にプログラムされるコンピュータ、特定用途向け集積回路などであり得る。ストレージ202は、空間シーン216を表現するメディアセグメントを記憶し得る。コントローラ206は、クライアント202からの要求に応答して、メディアセグメント、たとえば要求されたビデオ/オーディオデータを、それぞれの制御情報と一緒にクライアント202へ送信し得る。コントローラ206は、要求されるメディアセグメントをストレージ220からフェッチしてもよく、実施形態に従って、レンダリングされたビューポートとも呼ばれるビュー選択214のレンダリングされたバージョンとして、クライアント202にビデオデータを提供してもよく、または、投影されたデータとして、すなわちレンダリングなしで、ビデオデータをクライアント202に提供してもよい。
【0152】
クライアント202は、たとえば、図2のシグナルプロセッサ208を使用して実装されるクライアントデバイスまたはコントローラ208を含んでもよく、適切にプログラムされたコンピュータ、マイクロプロセッサ、プログラムされたハードウェアデバイスなどであってもよい。クライアントデバイス208は、それぞれの制御情報と一緒に、サーバ200から取り出されるべきメディアセグメントを選択し得る。以下でより詳しく説明される実施形態によれば、クライアント202に転送されるビデオデータが、レンダリングされたビデオデータであるか、または投影されたビデオデータであるかに応じて、レンダリングされたビデオデータを受信する場合、デバイス210のディスプレイに対してそのまま、レンダリングされたビデオデータを使用する。受信されたデータが投影されたビデオである場合、デバイス210上での表示のために、受信された投影されたビデオデータに基づいてビューポートのレンダリングを実行するために、コントローラ208が提供される。
【0153】
メディアストリーム204内のデータの送信は、サーバ200およびクライアント202の中のそれぞれのエンティティ、たとえばコントローラ206および208がそれぞれのエンコーダ/デコーダを含むように、符号化された形式で実行される。
【0154】
【0155】
本発明の実施形態は、送信機および受信機または受信者とも呼ばれるサーバおよびクライアントがその間に対話するイマーシブメディアコンテンツの提示に関し、送信機は、ビデオデータ、たとえば、受信機によって提供されるフィードバックに基づいて受信機エンドポイントの視線方向および/または視点と一致するビデオデータを含むビットストリームを提供する。たとえば、図2または図3のシステムを考慮すると、受信機またはクライアント202は、クライアントにおける視線方向および/または視点のイマーシブメディアコンテンツを表現するビデオデータを、サーバまたは送信機200から取得することが可能である。言い換えると、イマーシブメディアコンテンツの提示のために、クライアント202は、特定の視線方向および/または特定の視点に応じて、ビデオデータをサーバから取得し、イマーシブメディアコンテンツの特定の視線方向を表現するビデオデータを表示する。
【0156】
実施形態によれば、クライアント202は、サーバ200からビデオデータを取得するために、特定の視線方向および/または特定の視点をサーバ200にシグナリングし、特定の視線方向および/または特定の視点に対するビデオデータをサーバ200から受信することができ、図2の両矢印、またはクライアント202のクライアントデバイス208から図3のサーバ200のコントローラ206への接続を参照されたい。
【0157】
さらなる実施形態によれば、クライアントは、図3に示されるように、メディアの特定の視線方向214および/または特定の視点に対するビデオデータをユーザに表示するための表示デバイス210、たとえばHMDを含む。クライアントはさらに、ユーザの視線方向および/または視点を検出するための1つまたは複数のセンサ218を含み、クライアントデバイスまたはプロセッサ208は、検出された視線方向および/または検出された視点をサーバにシグナリングし、表示デバイス210での表示のために、シグナリングされた視線方向および/または視点と関連付けられる受信されたビデオデータを処理する。
【0158】
クライアント202によるイマーシブメディアコンテンツの提示のために、サーバ200は、クライアント202から、クライアント202における特定の視線方向および/または特定の視点の指示を受信し、特定の視線方向214および/または特定の視点に対するビデオデータをクライアント202に送信する。
【0159】
上で説明された実施形態は、シーンの特定の視線方向および/または特定の視点に対するビデオデータが、クライアントにおける実際の視線方向および/または実際の視点に応答して送信されるので、従来の手法と比較してより少ないビデオデータしか送信および/または処理する必要がないという点で、有利である。したがって、リアルタイムの体験、またはより一般的には、ユーザの体験品質(QoE)の低下を引き起こす遅延を減らし、または避けることができる。
【0160】
本発明のさらなる実施形態は、上で説明されたプロトコル、たとえば、RTP、RTCP、およびSDPプロトコルを拡張することによって、イマーシブメディアコンテンツの改善されたより効率的な提示を可能にする、機構およびシグナリングを定義する。実施形態によれば、イマーシブメディアコンテンツの提示のための改善されたより効率的な機構およびシグナリングを提供する本発明の手法を達成するために、RTPおよびRTCPパケットならびにSDPのための新しい属性の拡張機構が定義される。
【0161】
本発明の実施形態は、イマーシブメディアセッションのための様々なメディアフォーマット、またはビデオデータのための処理モードを提供し、すなわち、イマーシブメディアコンテンツを表現するレンダリングされたビデオデータおよびレンダリングされていないビデオデータを提供し、レイテンシに応じたレンダリングされたビデオデータとレンダリングされていないデータの切り替えを可能にする。
【0162】
実施形態によれば、一方のエンドポイント、たとえば受信機またはクライアントに対して適切な単一のビットストリームが、他方のエンドポイント、たとえば送信機またはサーバによってそれに従って生成される、ポイントツーポイント通信のための、手法を考えることができる。エンドツーエンドレイテンシのようなレイテンシまたはシステムにおいて観測されるネットワークに応じて、以下の手法のうちの1つが適用され得る。
・ビューポート送信:2Dビューポートのようなレンダリングされたビューポートが、サーバ側において生成され、クライアントに直接提示される。言い換えると、レンダリングされた2Dビューポートがそのまま受信機に直接提示される。ビューポートは、360°ビデオ、ボリュメトリックビデオ、または3Dコンピュータグラフィクスのためのビューポートのような、イマーシブメディアコンテンツを表現し得る。これは、レイテンシがある閾値より小さい場合に行われ得る。
・イマーシブコンテンツ送信:
〇360°ビデオ/グラフィクス
投影されたビデオ送信:ある具体的な投影、たとえばERP、CMP、三角錐、角錐台を使用して、360°ビデオ全体の一部が送信される。実施形態によれば、たとえばregion-wise packingを使用した不均等な分解能のCMPのために、いくつかの部分が再サンプリングされ得る。
〇ボリュメトリックオブジェクト/ビデオ:
3Dデータ送信:全体のボリュメトリックオブジェクトまたはボリュメトリックオブジェクトの一部が、ポイントクラウドまたはメッシュなどの3Dフォーマットでクライアントに送信される。たとえば、対応するメッシュデコーダを有するクライアントが、ボリュメトリックオブジェクトを復号して再構築し、ユーザの対話に基づいてオブジェクトのビューをレンダリングし得るように、圧縮されたメッシュストリームがクライアントに送信され得る。
〇3Dコンピュータグラフィクス、たとえばゲーム:
完全なシーン、たとえば複数のボリュメトリックオブジェクトが、複数のポイントクラウドまたはメッシュなどの3Dフォーマットで送信され得る。
・ビューポート送信:2Dビューポートのようなレンダリングされたビューポートが、サーバ側において生成され、クライアントに直接提示される。言い換えると、レンダリングされた2Dビューポートがそのまま受信機に直接提示される。ビューポートは、360°ビデオ、ボリュメトリックビデオ、または3Dコンピュータグラフィクスのためのビューポートのような、イマーシブメディアコンテンツを表現し得る。これは、レイテンシがある閾値より小さい場合に行われ得る。
・イマーシブコンテンツ送信:
〇360°ビデオ/グラフィクス
投影されたビデオ送信:ある具体的な投影、たとえばERP、CMP、三角錐、角錐台を使用して、360°ビデオ全体の一部が送信される。実施形態によれば、たとえばregion-wise packingを使用した不均等な分解能のCMPのために、いくつかの部分が再サンプリングされ得る。
〇ボリュメトリックオブジェクト/ビデオ:
3Dデータ送信:全体のボリュメトリックオブジェクトまたはボリュメトリックオブジェクトの一部が、ポイントクラウドまたはメッシュなどの3Dフォーマットでクライアントに送信される。たとえば、対応するメッシュデコーダを有するクライアントが、ボリュメトリックオブジェクトを復号して再構築し、ユーザの対話に基づいてオブジェクトのビューをレンダリングし得るように、圧縮されたメッシュストリームがクライアントに送信され得る。
〇3Dコンピュータグラフィクス、たとえばゲーム:
完全なシーン、たとえば複数のボリュメトリックオブジェクトが、複数のポイントクラウドまたはメッシュなどの3Dフォーマットで送信され得る。
【0163】
上で言及されたレイテンシは、以下のレイテンシのうちの1つまたは複数を含み得る。
・ネットワークレイテンシ
・エンドツーエンドレイテンシ
・最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ
・あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ
・未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
・ネットワークレイテンシ
・エンドツーエンドレイテンシ
・最大のまたは許容可能なmotion-to-photon(MTP)レイテンシ
・あらかじめ定められた体験品質(QoE)に対応するMTPレイテンシ
・未来を見るための予測子の時間的能力を示す予測先読み時間によって低減されるMTPレイテンシ
【0164】
本発明の実施形態は、その間に、送信機および受信機または受信者とも呼ばれるサーバおよびクライアントが対話し、送信機が、ビデオデータ、たとえば受信機によって提供されるフィードバックに基づいて受信機エンドポイントの視線方向と一致するビデオデータを含むビットストリームを提供するような、360°ビデオ通信に関する。
【0165】
たとえば図2または図3のシステムについて考えると、受信機またはクライアント202は、クライアントにおける視線方向に応じて、360°ビデオのビデオデータをサーバまたは送信機200から取得することが可能である。言い換えると、サーバ200との360°ビデオ通信のために、クライアント202は、360°ビデオの特定の視線方向に応じて、ビデオデータをサーバから取得し、360°ビデオの特定の視線方向を表現するビデオデータを表示する。
【0166】
実施形態によれば、クライアント202は、サーバ200からビデオデータを取得するために、360°ビデオの特定の視線方向をサーバ200にシグナリングし、サーバ200から、360°ビデオの特定の視線方向に対するビデオデータを受信することができ、図2の両矢印、またはクライアント202のクライアントデバイス208から図3のサーバ200のコントローラ206への接続を参照されたい。
【0167】
さらなる実施形態によれば、クライアントは、図3に示されるように、360°ビデオの特定の視線方向214に対するビデオデータをユーザに表示するための表示デバイス210、たとえばHMDと、ユーザの視線方向を検出するためのセンサ218と、検出された視線方向をサーバにシグナリングし、表示デバイス210上での表示のためにシグナリングされた視線方向と関連付けられる受信されたビデオデータを処理するためのクライアントデバイスまたはプロセッサ208とを含む。
【0168】
クライアント202との360°ビデオ通信のために、サーバ200は、クライアント202における360°ビデオの特定の視線方向の指示をクライアント202から受信し、360°ビデオの特定の視線方向214に対するビデオデータをクライアント202に送信する。
【0169】
上で説明された実施形態は、360°ビデオのシーンの特定の視線方向に対するビデオデータが、クライアントにおける実際の視線方向に応答して送信されるので、従来の手法と比較してより少ないビデオデータしか送信および/または処理する必要がないという点で、有利である。したがって、リアルタイムの体験、またはより一般的には、ユーザの体験品質(QoE)の低下を引き起こす遅延を減らし、または避けることができる。
【0170】
本発明のさらなる実施形態は、上で説明されたプロトコル、たとえば、RTP、RTCP、およびSDPプロトコルを拡張することによって、改善されたより効率的な360°ビデオ通信を可能にする、機構およびシグナリングを定義する。実施形態によれば、360°ビデオ通信のための改善されたより効率的な機構およびシグナリングを提供する本発明の手法を達成するために、RTPおよびRTCPパケットならびにSDPのための新しい属性の拡張機構が定義される。
【0171】
本発明の実施形態は、360°ビデオ通信セッションのための様々なメディアフォーマット、またはビデオデータのための処理モードを提供し、すなわち、レンダリングされたビデオデータおよび投影されたビデオデータを提供するための実施形態に関し、レイテンシに応じたレンダリングされたビデオデータと投影されたビデオデータの切り替えのための実施形態に関する。
【0172】
一方のエンドポイント、たとえば受信機またはクライアントに対して適切な単一のビットストリームが、他方のエンドポイント、たとえば送信機またはサーバによってそれに従って生成される、ポイントツーポイント通信のための、2つの手法を考えることができる。システムにおいて見られるエンドツーエンドレイテンシに応じて、以下の手法のうちの1つが適用され得る。
・ビューポート送信:レンダリングされた2Dビューポートがサーバ側において生成され、クライアントに直接提示される。
・投影されたビデオ送信:ある具体的な投影、たとえばERP、CMP、三角錐、角錐台を使用して、360°ビデオ全体の一部が送信される。実施形態によれば、たとえばregion-wise packingを使用した不均等な分解能のCMPのために、いくつかの部分が再サンプリングされ得る。
・ビューポート送信:レンダリングされた2Dビューポートがサーバ側において生成され、クライアントに直接提示される。
・投影されたビデオ送信:ある具体的な投影、たとえばERP、CMP、三角錐、角錐台を使用して、360°ビデオ全体の一部が送信される。実施形態によれば、たとえばregion-wise packingを使用した不均等な分解能のCMPのために、いくつかの部分が再サンプリングされ得る。
【0173】
ビューポート送信と、イマーシブコンテンツまたは投影されたビデオ送信とのレイテンシ依存の切り替えが、ここでより詳しく説明される。たとえば、仮想現実サービスを考えるときに考慮されるべき重要な態様のうちの1つは、motion-to-photon(MTP)レイテンシである。MTPレイテンシは、ユーザの動きが表示画面上で完全に反映されるのに必要な時間であると見なされ得る。言い換えると、ユーザが対応する動き、たとえば左を見ることを始めたときに、仮想現実ヘッドセットの画面上で動きを反映するのに必要な時間が、MTPレイテンシである。良好なまたは許容可能な体験品質(QoE)を提供するために、低いMTPレイテンシ、たとえば15～20ms未満が必要である。360°ビデオ全体、ボリュメトリックオブジェクト全体、または3Dオブジェクト(コンピュータで生成される)全体が、クライアントにおいて利用可能であり、クライアントが、ユーザへの提示のために適切なビューポートをレンダリングすることを担うシナリオを考えると、ネットワークレイテンシは重要ではない。言い換えると、そのようなシナリオでは、良好なまたは許容可能なQoEを提供するために、内部レイテンシ、たとえば、ユーザの視線の向きの変化に反応するときのクライアントにおける処理と関連付けられるレイテンシは、MTPレイテンシより小さくなければならない。これは、イマーシブメディアの通信またはイマーシブメディアコンテンツの提示の例として、360°ビデオの提示または360°ビデオの通信に関してより詳しくここで説明される。
【0174】
しかしながら、送信機エンドポイントが受信機エンドポイントによって提供されるフィードバックに基づいて受信機エンドポイントの視線方向と一致するようにビットストリームを提供するような、360°ビデオ通信を考えると、良好なまたは許容可能なQoEを達成するために、内部レイテンシとネットワークレイテンシの合計がMTPレイテンシより小さくなるようにも、ネットワークのレイテンシを考えるべきである。
【0175】
図4は、送信機200が受信機202における視線方向と一致するビデオデータを含むビットストリームを提供するような360°ビデオ通信の間の、ビューポート送信遅延を示す。図4の例では、時間t0において、受信機202は、たとえば、センサ218からの信号に基づくHMD210の動きによって、視線方向の変化を検出する。視線方向の変化の検出を処理した後、時間t1において、受信機202は、ネットワーク204を介して、新しい視線方向ViewDIRaを送信機200に報告し、それぞれの受信機報告は、時間t2に送信機200において受信される。受信機は、たとえば、新しい視線方向ViewDIRaを表現するピクチャPicnに対するビデオデータを提供するために、コントローラ206によって、それがメモリ220に記憶した360°ビデオデータを処理する。ピクチャPicnは、サーバ200によって符号化され、符号化の後で、時間t3において、ビデオデータは、符号化されたビデオデータPicnをt4において受信する受信機に、ネットワーク204を介して送信される。受信機202は、たとえばコントローラまたはクライアントデバイス208によって、Picnを表現する受信されたビデオデータを復号し、復号遅延の後で、新しい視線方向ViewDiraが、時間t5においてディスプレイ212に出力される。図4は、時間t0における視線方向の変化の検出から、時間t5においてディスプレイ212に新しい視線方向が提示されるまでの、エンドツーエンド(E2E)遅延230を示す。
【0176】
図4において、矢印232および234はネットワーク遅延を表す。図4の例に示されるように、それぞれの矢印232および234は異なる遅延を表し、それは、異なる送信の部分の送信されるデータは異なるサイズを有し得るからである。たとえば、送信232、たとえば受信機報告(RR)は、視線方向の変化についてのフィードバックを含むので、少数のビットを含み得る。一方、送信234は、新しい視線方向ViewDiraを表現する符号化されたピクチャを実際に伝送されるデータが含むので、より多数のビットを含む。しかしながら、他の実施形態によれば、送信232と234に対して同じ伝搬遅延が想定されてもよい。
【0177】
図4は、上で言及されたように、クライアント202が受信されたビデオを復号の後でそのまま表示し得るように、すなわち、クライアントが受信されたビデオデータのレンダリングを実行する必要がないように、サーバ200がクライアントへの送信のためにレンダリングされたビューポートを生成するような例を示す。図4を参照して上で説明されたようなビューポート送信は、E2E遅延230が、15～20ms、またはMTPレイテンシ、または、たとえばあらかじめ定められた体験品質(QoE)を生む最大のもしくは許容可能なMTPレイテンシより短い限り、許容可能である。それ以外の場合、上で言及されたように、体験品質は良好なまたは許容可能なレベルを下回る。以下の表は、送信232のFeedbackLatencyと送信234のPictureTransLatencyの長さをms単位で示す、いくつかの例示的な遅延をまとめたものである。列Restは、図4において示される内部レイテンシまたは残りのレイテンシの長さ、すなわち、視線方向の変化の検出から、それを送信機に報告するまでのレイテンシ、新しいビデオデータを生成するための送信機における処理時間から受信された新しいピクチャデータを処理するための受信機における処理時間までのレイテンシ、すなわち、t0とt1の間の時間、t2とt3の間の時間、およびt4とt5の間の時間を示す。
【0178】
【表1】
【0179】
列E2Eは、メッセージ232、234と関連付けられるレイテンシと残りの処理の長さの合計を示す。最後の列は、E2EがMTPレイテンシ以下である場合、E2E遅延を許容可能であるものとして示し「Yes」、または、E2EがMTPレイテンシを超える場合、許容可能ではないものとして示す「No」。したがって、それぞれのレイテンシに応じて、ビューポート送信は、各々の状況において適切ではないことがある。
【0180】
実施形態によれば、図4を参照して上で説明されたビューポート送信手法を改善して、10～20msの閾値をレイテンシが上回るにもかかわらずMTP要件を満たすことを可能にするために、ビューポート予測技法が適用され得る。他の実施形態によれば、たとえば6DoFコンテンツの場合、ビューポート予測の代わりに、またはそれに加えて、ビューポート予測技法が適用され得る。この手法は、ビューポートの予測が高い正確さで可能であるような状況において適用され得る。図5は、ビューポート予測技法を使用する、たとえば図3に示されるようなシステムにおけるビューポート送信の例を示す。図5は、時間t0を除いて図4と同様であり、センサ218によって検出される視線方向の実際の変化はなく、むしろ、たとえばクライアント202のコントローラ208によって予測が行われ、予測期間Δpred236の後の時間t6において生じると予測される、新しい視線方向ViewDir'aを示す。図4を参照して上で説明されたのと同じ方法で、時間t1において、予測される視線方向ViewDir'aは、時間t3において符号化され受信機202に送信される新しいピクチャPicnに対するビデオデータを生成する送信機に報告される。時間t4において、視線方向の変化はすでに生じており、新しいピクチャが、出力遅延の後で、時間t5においてディスプレイ212に表示される。Δpred236は、先読み時間とも呼ばれる、未来を見るための予測子の時間的能力である。先読み時間は、ビューポートが特定の正確さで予測される未来の瞬間と、現在の瞬間との間の時間差として定義され得る。予測時間長Δpred236は、E2E遅延230から差し引かれ得る。MTP要件を満たすことが可能ではなかった、図4を参照して説明された以前の表からのこれらの事例を考慮すると、予測技法を適用したとき、これらの事例の一部では、予測時間を利用することによって、許容可能な全体の遅延を達成できることを、以下の表は示している。
【0181】
【表2】
【0182】
図3に関して、受信機202がビューポート予測を実行すると仮定されるが、他の実施形態によれば、予測は送信機側で実行されてもよいことに留意されたい。送信機および受信機が予測の実行を見込む場合、送信機200および受信機202は、たとえば360°ビデオ通信セッションの最初に、どちらが予測を実行するかについてネゴシエートし得る。
【0183】
ビューポート送信手法のための上で説明された実施形態では、ユーザの姿勢がHMD210によって追跡され、受信機202が、たとえばRTCPメッセージを使用して、ビューポート情報を送信機200にシグナリングすることが仮定される。それに対して、送信機200は、受信機のビューポートを適応的にレンダリングし、ビューポートに対応するレンダリングされた2Dビデオを符号化し、受信機202における表示のためにレンダリングされた2Dを送信する。360°ビデオに関するさらなる実施形態によれば、サーバ200によって提供され受信機202に転送されるようなレンダリングされたビデオは、送信機200に向かって受信機202によって提供されるレイテンシ情報に依存した、クライアント202におけるユーザのビューポートのオーバープロビジョニングされたバージョンであり得る。言い換えると、「No」とマークされた最後の列において上の表で示されるように、レイテンシが大きいのでMTPレイテンシが良好な体験品質を見込めない場合、ビューポートのレンダリングされた2Dバージョンの送信が依然としてMTPレイテンシ要件内で可能であるように、実際のビューポートの周りにさらなるマージン領域またはフォールバック領域を追加することが可能であり得る。しかしながら、ビューポートのレンダリングされた2Dバージョンのオーバープロビジョニングは、追加されるマージンが非常に大きくはない限り、すなわち、受信機における実際のレンダリングされたビデオが送信機側において使用されるものとはわずかに異なる視線方向に対応するので、受信機における復号された画像またはピクチャの画像処理のような小さな補正因子が受信機側において必要とされる限り、機能し得る。サーバから受信機に更新されたビデオデータを提供するためのビューポート送信手法の上記の議論からわかり得るように、実際に使用される2Dビューポート送信が適切であるかどうかは、RTCP報告メッセージの交換を通じて送信機および受信機によって測定され得るE2Eレイテンシに依存する。
【0184】
E2EレイテンシがMTPレイテンシ要件より長いことにより、クライアントへのサーバによるレンダリングされた2Dビューポート送信が可能ではない可能性がある状況に対処するために、実施形態によれば、レンダリングされた2Dビューポート送信を提供するのではなく、送信機はまた、たとえば、イマーシブメディアセッションまたは360°ビデオ通信セッションを準備すると、全体の360°ビデオデータのような、イマーシブメディアコンテンツのレンダリングされていない部分を提供する。たとえば、ビューポート送信を提供する実際の構成に加えて、全体の360°ビデオデータのようなイマーシブメディアコンテンツの一部が、たとえばHMD210またはビデオデータを表示するための別のデバイスを介してそれをユーザに提示するためのクライアントにおいてレンダリングするために、サーバによってレンダリングされることなく送信されるような、潜在的な構成が提供され得る。
【0185】
さらなる実施形態によれば、たとえばセッション記述プロトコル(SDP)を使用して、サーバ200とクライアント202との間にネゴシエーションがあってもよく、サーバ200は、ボリュメトリックビデオの場合、またはコンピュータ生成グラフィクスの場合には、360°ビデオまたは3Dコンテンツのようなイマーシブメディアコンテンツの1つまたは複数のパラメータを、360°ビデオの場合には、投影タイプ、回転、およびregion-wise packing (RWP)制約のうちの1つまたは複数を示す、たとえば補足強化情報(SEI)メッセージを記述し得る。たとえば、360°ビデオ通信のセッションの最初において、サーバ200およびクライアント202は、クライアント202によって使用される360°ビデオのような、イマーシブメディアコンテンツの実際のパラメータまたはパラメータ値をネゴシエートし得る。ネゴシエーションの間、クライアント202は、たとえばSDPを使用して、装置の能力に従って、360°ビデオのようなイマーシブメディアコンテンツの1つまたは複数の追加のパラメータを提供してもよく、および/または、装置の能力に従って、360°ビデオのようなイマーシブメディアコンテンツのパラメータのうちの1つまたは複数を修正もしくは除去してもよい。言い換えると、ネゴシエーションは、ボリュメトリックビデオまたはコンピュータ生成グラフィクスの場合に、ビューポートの2Dバージョンまたは投影された360°ビデオまたは3Dコンテンツが送信されるかどうかのネゴシエーションが、エンドポイント能力および受ける遅延に基づいて実行され得る。これは、送信機が360°ビデオの2Dビューポートバージョンおよび投影されたバージョンを提供し得ることと、測定された遅延、および、たとえば予測能力に応じて、受信機が、2Dビューポートバージョンを受け入れるか、または360°の投影されたバージョン/3Dコンテンツを受け入れるかを決定し得ることを意味する。イマーシブメディアセッションの最初において、(任意選択でクロッピングされる)投影された360°ビデオ/3Dコンテンツが配信されるべきであるか、またはビューポートと合う2Dビデオだけが配信されるべきであるかを決定するための、SDPネゴシエーションが行われ得る。
【0186】
360°ビデオに関する実施形態によれば、クライアントは、1つまたは複数の新しい要素を含めることによって、またはsprop-sei行を修正することによって、SDPネゴシエーションの間にRegion-Wise Packing(RWP)パラメータをネゴシエートし得る。これは、クライアントがその能力に従ってRWPフォーマットを制約することを可能にする。たとえば、クライアントは、
・最大で特定の数の領域までしか処理することが可能ではなくてもよく、および/または
・高さもしくは幅が制約されたパッキングもしくは投影された領域のみを許容してもよく、および/または
・特定の変換タイプ、たとえばスケーリング、回転、もしくはミラーリングのみを理解してもよく、および/または
・パッキングされた領域のいずれに対してもその周りにガードバンドエリアを有することを許容せず、もしくはそれらの領域の一部に対してのみそれを許容し、それらの領域のすべてに対してそれを許容してもよい。
・最大で特定の数の領域までしか処理することが可能ではなくてもよく、および/または
・高さもしくは幅が制約されたパッキングもしくは投影された領域のみを許容してもよく、および/または
・特定の変換タイプ、たとえばスケーリング、回転、もしくはミラーリングのみを理解してもよく、および/または
・パッキングされた領域のいずれに対してもその周りにガードバンドエリアを有することを許容せず、もしくはそれらの領域の一部に対してのみそれを許容し、それらの領域のすべてに対してそれを許容してもよい。
【0187】
クライアントは、たとえば、あり得るRWPフォーマットを制約するために、以下の1つまたは複数の新しいRWPパラメータ関連の要素を含み得る。
・rwp-max-num-packed-regions
・rwp-min-proj-region-width/height
・rwp-min-packed-region-width/height
・rwp-allowed-transform-types
・rwp-guard-band-flag-constraint
・rwp-max-scaling-factor
・rwp-max-num-packed-regions
・rwp-min-proj-region-width/height
・rwp-min-packed-region-width/height
・rwp-allowed-transform-types
・rwp-guard-band-flag-constraint
・rwp-max-scaling-factor
【0188】
他の実施形態によれば、RWPパラメータの代わりに、またはそれに加えて、ワーピングの成功を支援するレンズまたはひずみパラメータが、SDP能力ネゴシエーションの一部であってもよい。
【0189】
クライアント202の能力は、ビデオデータをレンダリングすること、オーバープロビジョニングを取り除くことなどのような、受信された投影されたビデオデータを処理するための能力を含み得る。
【0190】
セッションの間に、およびSDPネゴシエーションに基づいて、サーバ200は、クライアントによって指定されるパラメータまたは制約に従って、投影されたビデオを符号化し得る。
【0191】
上で説明されたネゴシエーションは、全体の360°ビデオのようなイマーシブメディアコンテンツのレンダリングされた2Dビューポート送信またはレンダリングされていない部分を提供する実施形態に限定されず、むしろ、上で説明されたネゴシエーションは、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0192】
実施形態によれば、送信機は、360°ビデオの2Dビューポートバージョンならびに投影されたバージョンのようなイマーシブメディアコンテンツを提供してもよく、セッションの最初において、360°ビデオの上で説明されたパラメータ、ならびに/または、たとえばRFC7798によって定義されるような、ビデオパラメータセット、シーケンスパラメータセット、およびピクチャパラメータセットのようなパラメータセットに関して、SDPネゴシエーションが実行され得る。実施形態によれば、サーバ200は、たとえばSDPを使用して、以下で表現されるような両方のメディアバージョンを送信し得る(以下のSDP記述は、投影された360°ビデオと2Dのレンダリングされたビデオとの間のオファーを記述するが、任意の種類のイマーシブメディアコンテンツに対して等しく適用可能である)。
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=360 video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP,CMP,sphere rotation,region-wise
packing>
a=rtpmap:98 H265/90000
a=fmtp:98 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=360 video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP,CMP,sphere rotation,region-wise
packing>
a=rtpmap:98 H265/90000
a=fmtp:98 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
【0193】
mの行において示されるように、提供されるビデオデータは、それぞれ投影された360°ビデオおよび2Dのレンダリングされたビデオという2つの異なるフォーマットに対する、SDPペイロードタイプ97および98を有する。ペイロードタイプ97の中の投影された360°ビデオに対して、ビデオパラメータセット、シーケンスパラメータセット、およびピクチャパラメータセットを表現するデータに加えて、たとえばRFC 7798によって定義されるように、たとえば、投影タイプ、回転、および/またはregion-wise packing(RWP)制約を実施形態に従って示す、補足強化情報(SEI)メッセージを使用して、投影されたビデオの特性も示される。これらの特性は、HEVC、RFC 7798のためのRTPペイロードフォーマットにおいて定義されるようなsprop-seiパラメータに含まれ得る。一方、2Dのレンダリングされたビデオのためのペイロードタイプ98は、それぞれの上で言及されたパラメータセットvps、sps、およびppsを含む。
【0194】
より一般的に言えば、実施形態によれば、SDPネゴシエーションは、異なるペイロードタイプに対する少なくとも以下の属性を含み得る。
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;and
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP, CMP, sphere
rotation, region-wise packing>
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;and
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP, CMP, sphere
rotation, region-wise packing>
【0195】
360°ビデオ通信のセッションの間に、クライアントは、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットをサーバから受信し得る。クライアントが、ネゴシエーションの間に、サーバによって提供されるような異なるビデオフォーマットを受け入れた場合、クライアントは、直ちに、またはRTCPパケットの後の特定の時間において、他のフォーマットを要求するメッセージ、たとえばRTCPパケットをサーバに送信し得る。サーバは、要求に応答して、要求されたフォーマットでビデオデータを提供する。
【0196】
ボリュメトリックビデオ/コンピュータ生成グラフィクスに関するさらなる実施形態によれば、ボリュメトリックビデオであるか、2Dのレンダリングされたビデオであるかの識別は、sprop-seiパラメータのようなSEIの存在によって、特定のビデオコーデックもしくはプロファイルの指示によって、または、たとえば「videoformat 6DoF」もしくは「videoformat Volumetric」などのSDPの中の追加の属性によって行われ得る。
【0197】
実施形態によれば、SDPは、2Dのレンダリングされたビデオが具体的な位置および視線方向に対応するシーンを表現することを示す関連付け情報を含み得るので、クライアントは、より適切である場合、2Dのレンダリングされたビデオによってイマーシブメディアコンテンツを表現することを選択し得る。その場合、以下でより詳しく論じられるように、位置おび視線方向(ある程度の頻度で)または視線方向の予測のようないくつかの情報が、送信機と受信機との間で交換され得る。
【0198】
ボリュメトリックシーンの場合、潜在的に各々いくつかのビットストリームからなる複数のボリュメトリックオブジェクトがあり得る。たとえば、V-PCCが使用される場合、オブジェクトは、少なくともテクスチャビットストリームおよびジオメトリビットストリームを有し得る。メッシュベースのコンテンツ表現が利用される場合、圧縮されたメッシュおよびテクスチャビットストリームがあり得る。そのような場合、SDPは、異なる種類のビットストリーム、たとえばテクスチャ、ジオメトリ、およびさらなる実施形態によればビットストリームの変形についての情報を含み得る。たとえば、より詳細にオブジェクトを表現するための複数のテクスチャビットストリーム、たとえばV-PCCにおける異なるテクスチャ「レイヤ」があり得る。各オブジェクトに対して、関連するビットストリームは、以下で説明されるようなSDPの既存のグループ化機構を使用して、互いと関連付けられ得る。
【0199】
さらなる実施形態によれば、上で説明されたように2つのメディアフォーマットを示すのではなく、さらなる実施形態によれば、あるモードから別のモードに動的に切り替えられ得る、単一のペイロードデータがシグナリングされ得る。言い換えると、サーバによって提供されるようなデータはセッションの間は残るが、処理モードは、2Dビデオデータを送信するためのサーバにおけるレンダリングと、投影されたビデオデータのようなイマーシブメディアコンテンツの提供との間で変化する。360°ビデオの対応するSDPネゴシエーション場合の例が以下で示される。
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=360 video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97
a=acap:1 dynamicallySwitched2DOrProjected
a=pcfg:1 a=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP,CMP,sphere rotation,region-wise
packing>
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=360 video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97
a=acap:1 dynamicallySwitched2DOrProjected
a=pcfg:1 a=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP,CMP,sphere rotation,region-wise
packing>
【0200】
上で説明された実施形態では、前の実施形態との比較からわかり得るように、mの行において、投影された360°ビデオのフォーマットを示す単一のビデオフォーマット、すなわちフォーマット97が示されている。さらに、acap属性において、ビデオフォーマットが2DからProjectedに動的に切り替えられ得ることが示される。
【0201】
より一般的に言えば、本実施形態によれば、SDPネゴシエーションは、少なくとも以下の属性を含み得る。
a=acap: <att-cap-num> dynamicallySwitched2DOrProjected; and
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP, CMP, sphere
rotation, region-wise packing>
a=acap: <att-cap-num> dynamicallySwitched2DOrProjected; and
a=rtpmap: <payload type> <encoding name>/<clock rate>
a=fmtp: <payload type>
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required SEI: ERP, CMP, sphere
rotation, region-wise packing>
【0202】
ボリュメトリックビデオまたはコンピュータ生成グラフィクスのような3Dコンテンツに関する実施形態によれば、単一のペイロードデータが、以下で示されるようにSDPネゴシエーションによってシグナリングされ得る。
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=Volumetric video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97
a=acap:1 videoformat dynamiclySwitched2Dor3D
a=pcfg:1 t=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required 6DoF SEI>
v=0
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=Volumetric video communication session
c=IN IP4 192.0.2.1
a=sendonly
m=video 49170 RTP/AVP 97
a=acap:1 videoformat dynamiclySwitched2Dor3D
a=pcfg:1 t=1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required 6DoF SEI>
【0203】
6DoF SEIは、ボリュメトリックビデオ/コンピュータ生成コンテンツを構築する背後のビデオビットストリームのSEIから導出され得る。たとえば、V-PCCの場合、テクスチャおよびジオメトリ情報を含む様々なHEVCビットストリームがあり得る。他の実施形態によれば、6DoF SEIは、たとえばV-PCC SEIメッセージを使用して、別個のメタデータとしてシグナリングされ得る。またさらなる実施形態によれば、6DoF SEIまたは他のメタデータは、各々の背後にあるビットストリームに対して別々にSDPにおいてシグナリングされ得る。
【0204】
他の実施形態によれば、V-PCCの場合、たとえばテクスチャ、ジオメトリビットストリームをシグナリングするために、SDP記述において異なるメディアの行(mの行)が使用され得る。SDPは、いくつかのmの行を一緒にグループ化することを可能にするグループ属性を有し、「group:LS」セマンティクス(RFC 3388)を使用してストリームが同期され得る。構成要素の各々の識別は、コーデックパラメータもしくはプロファイル、または、「videoformat geometry」、「videoformat texture」などの定義される具体的なビデオフォーマットのいずれかによって行われ得る。対応するSDPネゴシエーションの例が以下で示される。
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=Volumetric video communication session
c=IN IP4 192.0.2.1
a=group:LS 1 2
m=video 49170 RTP/AVP 97
i=This stream contains the texture bitstream
a=mid:1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required texture SEI>
m=video 49170 RTP/AVP 98
i=This stream contains the geometry bitstream
a=mid:2
a=rtpmap:98 H265/90000
a=fmtp:98 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required geometry SEI>
o=johndoe 25678 423582 IN IP4 192.0.2.1
s=Volumetric video communication session
c=IN IP4 192.0.2.1
a=group:LS 1 2
m=video 49170 RTP/AVP 97
i=This stream contains the texture bitstream
a=mid:1
a=rtpmap:97 H265/90000
a=fmtp:97 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required texture SEI>
m=video 49170 RTP/AVP 98
i=This stream contains the geometry bitstream
a=mid:2
a=rtpmap:98 H265/90000
a=fmtp:98 level_id=120;
sprop-vps=<vps data#0>;
sprop-sps=<sps data#0>;
sprop-pps=<pps data#0>;
sprop-sei=<required geometry SEI>
【0205】
さらに別の実施形態によれば、複数のボリュメトリック/コンピュータ生成オブジェクトが、シーンに存在し得る。各々のそのようなオブジェクトは、異なる構成要素、たとえばテクスチャ、ジオメトリからなっていてもよく、各オブジェクトの異なる構成要素に対応するビットストリームは、一緒にグループ化され、SDP記述において記述されてもよい。言い換えると、SDP記述は、1つのボリュメトリック/コンピュータ生成オブジェクトを構築するビットストリームのセット、たとえばテクスチャ、ジオメトリを各々記述する、複数のグループを含み得る。SDPネゴシエーションの間、複数のそのようなオブジェクトが提供されてもよく、受信機は、たとえばそれぞれのグループIDを返答において示すことによって、特定のオブジェクトを要求してもよい。
【0206】
360°ビデオ通信のセッションのようなイマーシブメディアコンテンツセッションの間に、クライアントは、サーバから、リアルタイムトランスポートプロトコル(RTP)パケットのようなそれぞれのビデオデータパケットを受信し得る。クライアントが、ネゴシエーションの間に、あるモードから別のモードへの動的な切り替えを受け入れた場合、クライアントは、モードの切り替えを要求するメッセージ、たとえばRTCPパケットを、直ちに、またはRTCPパケットの後の特定の時間に、サーバに送信し得る。サーバは、2Dビデオデータと投影されたビデオデータとの切り替えを示すために、たとえばRTPヘッダ拡張を使用して、マークされたまたは別様に修正されたビデオデータパケットを提供し得る。たとえば、360°ビデオのようなイマーシブメディアコンテンツが表現される方法(たとえば、2Dか、投影されるか)の変化をクライアントに認識させるために、関連するレンダリング情報がクライアントによって十分早く考慮され得るように、切り替えが起きるRTPパケットが、切り替えパケットとしてマークされ得る。これは、たとえば、RTPヘッダ拡張を用いて行われ得る。
【0207】
実施形態によれば、サーバは、たとえば時間で表される、ピクチャの数で表される、またはパケットの数で表される、特定の期間の後でモードの切り替えが起きること、すなわち、たとえば、切り替えパケットの送信の後の特定の瞬間または特定の期間における、2Dビデオデータと投影されたビデオデータのようなイマーシブメディアコンテンツとの切り替えまでに特定の時間があることを、事前に示し得るので、受信機は、それに従って動作モードの切り替えを予定することができる。
【0208】
他の実施形態によれば、受信機は、セッションの間に、投影されたビデオのようなイマーシブメディアコンテンツからあらかじめレンダリングされた2Dビデオへの動的な切り替えを、およびその逆方向の切り替えを引き起こすことができ、これはすなわち、たとえば投影されたビデオのようなイマーシブメディアコンテンツからあらかじめレンダリングされた2Dビデオへのフォーマット変更を予定するようにサーバに尋ねる適切なRTCPフィードバックメッセージを送信することによって、上で説明された単一のペイロードタイプの使用を維持しながら行われる。そのような実施形態では、切り替えビデオデータパケットは、2Dビデオデータと投影されたビデオデータのようなイマーシブメディアコンテンツとの即刻の切り替えを示し得る。
【0209】
またさらなる実施形態によれば、異なるビデオフォーマットおよび動的に切り替え可能なビデオフォーマットをサーバ200によって提供したことに応答して、システムにおけるレイテンシに基づいて、受信機またはクライアント202は、ネットワークレイテンシが特定の閾値を下回る場合に、ビューポートと一致するレンダリングされた2Dビデオビューポートを提供するビューポート送信が使用されるように、かつそれ以外の場合に、360°ビデオデータの投影されたビデオ送信のようなイマーシブメディアコンテンツの送信が実行されるように、あるフォーマットから別のフォーマットへの変更を要求するために、提供されたフォーマットのうちの1つを選択し得る。閾値は、上で言及されたMTPレイテンシ、またはMTPレイテンシと、未来を見るための予測子の時間的能力を示す予測先読み時間とを足したものであってもよく、15msと20msの間の値を有してもよい。したがって、この実施形態によれば、ビューポートの2Dバージョンが送信されるか、またはビューポートの投影された360°バージョンのようなイマーシブメディアコンテンツが送信されるかは、システムが経験する遅延に依存する。送信機は、2Dビューポートバージョンおよび360°ビデオの投影されたバージョンのようなイマーシブメディアコンテンツを提供し、上で説明されたE2E遅延のような測定された遅延またはレイテンシに応じて、2Dビューポートバージョンがサーバ200によって提供されるか、または360°の投影されたバージョンのようなイマーシブメディアコンテンツが提供されるかが決定される。さらなる実施形態によれば、受信機または送信機における予測能力も考慮され得る。さらなる実施形態によれば、特定の閾値は、
-ネットワークレイテンシ、
-エンドツーエンドレイテンシ、
-あらかじめ定められた体験品質(QoE)MTPレイテンシ、
-未来を見るための予測子の時間的能力を示す予測先読み時間により低減されるMTPレイテンシ
のうちの1つまたは複数である。
-ネットワークレイテンシ、
-エンドツーエンドレイテンシ、
-あらかじめ定められた体験品質(QoE)MTPレイテンシ、
-未来を見るための予測子の時間的能力を示す予測先読み時間により低減されるMTPレイテンシ
のうちの1つまたは複数である。
【0210】
セッションの最初において、サーバとクライアントとの間でRTPまたはRTCPメッセージの交換がないので、レイテンシは未知である。そのようなシナリオでは、サーバ200およびクライアント202によって交換されるそれぞれのRTCP報告を使用して、E2Eレイテンシを計算することができないので、さらなる実施形態によれば、セッションは、360°ビデオの場合は投影されたビデオのようなイマーシブコンテンツ、またはボリュメトリックビデオ/コンピュータ生成グラフィクスの場合は3Dコンテンツを伴うイマーシブコンテンツで開始し、それは、これがレイテンシ要件内で、それでも、データをディスプレイに提示するために受信機においてデータをレンダリングする時間を与えながら、クライアント202に向かってサーバによって提供され得るからである。それをもとに遅延またはRTTが確実に確立され得るRTCP報告が利用可能になるまで、投影されたビデオデータのようなイマーシブメディアコンテンツが提供され、それ以降は、実施形態によれば、現在のE2Eレイテンシに応じて、ビューポート送信またはイマーシブコンテンツまたは投影されたビデオ送信のいずれかが送信機によって実行される。
【0211】
ビューポート送信と投影されたビデオ送信とを切り替えるすぐ上で説明された実施形態は有利であり、それは、レイテンシが閾値より小さくなるように、たとえばMTPレイテンシより小さくなるように、ビデオデータをサーバからクライアントに送信するのを可能にするので、ビューポートが提示されるユーザに良好な体験品質を保証するからである。実施形態によれば、ビューポート送信が好ましい送信モードであり、それは、画像を提示するために処理負荷の大きなレンダリングステップをクライアントが実行する必要がなく、むしろ、この処理はレンダリング処理を実行するための十分なパワーを有し得るサーバにおいて行われ、一方で受信機において、たとえばデバイスがバッテリー駆動である場合には、パワーの制約があり得るからである。MTPレイテンシが所望の閾値より長い状況では、予測を伴うか伴わないかのいずれかで、クライアントがビデオデータを受信してクライアント側においてレンダリングを実行するように、投影されたビデオ送信が実行される。
【0212】
2Dビューポートモードの利点は、実際の表示の前に受信機側での軽量な処理ステップのみでコンテンツを示すことができるということである。2Dのレンダリングされたビデオを復号した後、オーバープロビジョニングされたビデオが受信機に送信される場合、受信機は、ビデオをクライアントFoVに合わせるように、かつあり得る予測ドリフトに対処するように、ビデオを復号してからクロッピングを適用し、その後それをディスプレイに送信し得る。いくつかの場合、受信機は、非対称にクロッピングするとき、復号された画像におけるレンズ特性、たとえば樽型/糸巻型歪曲を補償するために、何らかの計算的に安価なワーピングを適用し得る。
【0213】
一方、投影されたビデオの場合、復号されたピクチャは、典型的な360°投影、または領域ごとにパッキングされたビデオデータの処理、すなわち、任意に変換されたサブピクチャのモザイクからの元の画像の再構築を伴う完全なレンダリングステップを経なければならない。その処理は、レンダリングパラメータ(たとえば、RWP)が頻繁に(たとえば、各フレームにおいて)変化する場合は特に、リアルタイムで達成するのが困難であり得る。
【0214】
さらなる実施形態によれば、投影されたモードに対する必要とされるSEIまたは他のメタデータは、2Dモードデータとともに送信され得るか、または、切り替え点の前に送信され得るかのいずれかであり、GPUレンダラを、切り替えの前に、ならびに投影モードよりもある時間前に、たとえば実際の投影されるフレームより1フレームまたは2フレーム前に初期化させる。投影されるビデオの場合と同様に、6DoFにおけるボリュメトリックビデオまたはコンピュータ生成グラフィクスのような3Dコンテンツも、高負荷のレンダリング段階を経なければならない。したがって、さらなる実施形態では、3Dコンテンツ送信への切り替えの前のどこかで、たとえば切り替え点の前に、またはモードの切り替えが起きる前に2Dモードデータとともに、6DoF関連のメタデータが送信され得る。
【0215】
さらなる実施形態によれば、上で説明されたビューポート予測機構および/または視点予測機構は、送信機側または受信機側のいずれかで適用され得るので、投影されるビデオデータのようなイマーシブコンテンツが送信されるべきか、または2Dビデオデータが送信されるべきかの決定に影響を与える。ビューポート予測は、たとえば以前のセンサデータ、コンテンツ特性の分析、および/またはユーザの挙動に基づく、未来の瞬間におけるユーザの視線方向の予測を指す。3DoFの場合、ユーザは、たとえばHMDを装着している場合は頭を動かすことによって、ビューポートを変えることがある。しかしながら、ユーザは動かない視点を有し、これは、球面コンテンツをそこから観察している球の中心に相当する。ユーザが空間において、ヨー、ピッチ、ロールの運動に加えて、並進運動、たとえば前/後、上/下、左/右を行い得るような6DoF環境ではユーザの各並進運動がユーザの視点を変える。視点は、視点位置とも呼ばれる空間における位置を有し、その視点の内部で、ユーザは異なる視線方向を有することがあり、すなわち、ユーザは頭を回して周りを見ることがある。視点の変化は、たとえばコントローラを使用してユーザがアクセスできる、たとえば複数の離散的な視点に制約されることがあり、または、視点の変化は、制約されない/自由な視点であることがあり、たとえば現実世界の体験に似ていることがある。そしてユーザは、仮想シーンの内部を完全に動き回ることができる。3DoFのシナリオにおけるビューポート予測と同様に、ユーザの未来のビューポートも予測され得る。
【0216】
図5を参照して上で説明されたのと同様の方法で、ビューポート予測および/または視点予測を適用するとき、それぞれの予測期間がE2Eレイテンシから差し引かれてもよく、それにより、信頼性のあるビューポート予測および/または視点予測の場合、クライアント202のディスプレイ212を使用してユーザに提示されるべきビデオデータの処理と送信においてより長いレイテンシに対処できる可能性がある。実施形態によれば、予測が受信機側で実行される場合、受信機は、たとえば、予測の正確さ、予測先読み時間、および/またはRTTに基づいて、要求されるべき具体的なビューポートおよび/または視点を決定し、たとえば特定のRTCPフィードバックメッセージを使用して、これを送信機にシグナリングし得る。あるペイロードタイプから別のペイロードタイプへの、または同じペイロードタイプ内であるモードから別のモードへの切り替えを引き起こす実際のレイテンシは、受信機の予測能力に基づいてネゴシエートされ得る。
【0217】
上で説明されたビューポート予測および/または視点予測は、全体の360°ビデオデータのようなイマーシブコンテンツのレンダリングされた2Dビューポート送信およびレンダリングされていない部分を提供する実施形態には限定されず、むしろ、上で説明されたビューポート予測および/または視点予測は、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0218】
実施形態によれば、2Dのレンダリングされたビューポートは、クライアント202の視野(FoV)と正確に一致し得るが、他の実施形態によれば、2Dのレンダリングされたビューポートは、正確なビューポートのある割合であり得る、クライアントにおいて表示され得る実際のビューポートの周りのマージンを含み得る。2Dのレンダリングされたビューポートの実際のマージンまたはフォールバックおよび寸法は、たとえばセッションの最初において、サーバ200とクライアント202の間でネゴシエートされ得る。たとえば、ビューポートサイズが拡大される場合、レンダリングのために使用されるレンズ/ひずみパラメータは、ビューポートのクロッピング/ワーピングを支援するために受信機に示され得る。マージンを含むビューポートの使用は、全体の360°ビデオデータのレンダリングされた2Dビューポート送信およびレンダリングされていない部分を提供する実施形態に限定されず、むしろ、マージンを含むビューポートの上で説明された使用は、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0219】
本発明の実施形態は、ビューポート予測能力および/または視点予測能力の交換、すなわち、送信機側における予測能力と受信機側における予測能力の交換に関する。
【0220】
両方のエンドポイント、すなわち、たとえば図3において図示されるような送信機200および受信機202が予測を実行し得る場合を考えると、エンドポイントの一方の予測機構が、エンドポイントの他方の予測機構より良好に機能するということがあり得る。したがって、実施形態によれば、サーバ200およびクライアント202の予測能力を交換することができ、より具体的には、両方のエンドポイントが、それとともに予測を実行し得る正確さおよび先読み時間を記述し得る。実施形態によれば、これはRTCPを介して行われ、受信機の予測能力を含むフィードバック(FB)メッセージを受信すると、送信機は、この情報を使用して、受信機からの予測を受け入れるかどうか、または送信機が予測を実行するかどうかを決定し得る。実施形態によれば、上で言及されたFBメッセージは、以下のフォーマットを有するRTCP FBメッセージのフィードバック制御情報(FCI)を含み得る。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lookahead time | Accuracy | m | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i)Look-ahead-time(LAT)は、未来を見るための予測子の時間的能力を表す。
(ii)Accuracyは、所与の先読み時間の予測の正確さを表す。
(iii)mは、どちらが予測を行うかを示すフラグである。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lookahead time | Accuracy | m | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i)Look-ahead-time(LAT)は、未来を見るための予測子の時間的能力を表す。
(ii)Accuracyは、所与の先読み時間の予測の正確さを表す。
(iii)mは、どちらが予測を行うかを示すフラグである。
【0221】
他の実施形態によれば、FCIは、単一のLAT-Accuracyペアの代わりに、ペアのリスト、たとえば{(LAT=100ms,ACC=95%),(LAT=200ms,Acc=80%)}を含み得る。実施形態によれば、受信機が最初に予測を実行してFBメッセージを送信するとき、mは1に設定される。送信機は次いで、送信機がより高い予測能力を有し予測を実行することを示す0へとmを設定すること、または、受信機が予測を実行することを送信機が受け入れることを示す1のままにmをすることのいずれかによって、FBメッセージを受信機に送信し得る。言い換えると、送信機は、どちらが予測を行うかを決定する。送信機は次いで、適切にメディアの符号化を適応させ得る。
【0222】
別の実施形態によれば、受信機が、どちらが予測を行うかを決定し得る。この場合、受信機は、予測を実行することを示すためにフラグをm=1に設定する。それ以外の場合、送信機が予測を実行することを受信機が予想する場合、受信機はm=0に設定する。
【0223】
予測情報は、関連するメディアの行にpred型のa=rtcp-fb属性を含めることによって提供されてもよく、ワイルドカード属性(*)が、予測シグナリングに対するRTCPフィードバック属性がすべてのペイロードタイプに適用されることを示すために使用され得る。SDP記述における属性としてRTCP FBメッセージに基づいて予測情報をシグナリングするための属性は、次の通りであり得る。
a=rtcp-fb:*pred
またはより一般的には
a=rtcp-fb:*<att-name>
a=rtcp-fb:*pred
またはより一般的には
a=rtcp-fb:*<att-name>
【0224】
別の実施形態によれば、予測能力交換は、両方のエンドポイントである送信機および受信機が、それらがどれくらい先の未来で、およびどの程度の正確さで予測を実行し得るかをその間に示し得る、SDPネゴシエーションを使用して行われ得る。実施形態によれば、たとえば100ms先の90%の正確さの予測、200ms先の70%の正確さの予測などの、1つより多くの動作点が列挙され得る。ネゴシエーションの後で、受信機が予測を実行するために選択される場合、受信機は、未来の時間ならびに予測されるビューポートおよび/または視点予測を示す1つまたは複数のフィードバックメッセージを返す。
【0225】
実施形態によれば、6DoF通信のシナリオでは、予測能力交換は、視点ごとの予測の正確さを追加で含み得る。視点間で変化するコンテンツ特性によっては、送信機または受信機の両方が正確な予測を行うことは、より簡単または困難であり得る。たとえば、送信機は、コンテンツを事前に分析して、ユーザが見たい可能性の高い多くの目立つエリアまたはホットスポットを特定の視点が含むことを決定し得る。したがって、そのような視点は、ユーザが見ることを好み得る少数のホットスポットのみを含む、互いと比較して予測がより難しいものとして分類され得る。これをシグナリングするために、予測能力情報はまた、視点ごとの予測能力を含み得る。送信機が予測を実行するか、または受信機が予測を実行するかについての最終的な決定は、送信機または受信機がそのためのより正確な予測を実行する視点の数を考慮することによって得られ得る。
【0226】
他の実施形態によれば、予測能力交換は、一秒当たりのサンプル単位の平均のまたは最大のドリフトとともに先読み時間に基づいて行われ得る。予測能力交換に加えて、たとえばネゴシエーション段階の間に、予測を支持するための送信機と受信機との間で交換されるべきパラメータについて合意が行われ得る。
【0227】
送信機が予測を実行することになる場合、受信機は、視線方向、報告間隔、速度、加速度などについてのフィードバックを送信し得る。
【0228】
実施形態によれば、受信機は、複数の視点を含む6DoFシーンにおいて動いていることがある。予測を実行するために受信機が選ばれる場合、受信機は、以前のセンサデータを分析し、受信機が現在見ている視点の内部で切り替えが起きる可能性がより高いかどうか、すなわちビューポートの切り替えの可能性がより高いかどうか、または、視点が変化する可能性がより高いかどうかを、決定し得る。たとえば、受信機は、ユーザの挙動を分析して、特定の挙動がビューポートの切り替えにつながる可能性がより高いかどうかを観察することができ、たとえば、ビューポートの内部で探索すること/見て回ることの減少は、ユーザが特定の視点を完全に探索し、新しい視点に移ることをより望んでいる可能性があることを示し得る。
【0229】
別の実施形態によれば、予測を実行するために送信機が選ばれる場合、受信機は、実際の視線方向および6DoFシーン内部の位置についてのフィードバックを送信し、送信機は、受信機の実際のセンサデータと、他のユーザまたはコンテンツ情報の統計、たとえば、特定のビューポートのどの空間エリアにおいてユーザが視点を変える可能性がより高いかということとを組み合わせ得る。
【0230】
どのエンドポイントが予測を行うかが選ばれると、サーバとクライアントとの間のSDPにおいて、必要とされるフィードバックのフォーマットが交換される。たとえば、送信機側の予測のために、送信機は、実際の視線方向および所与の間隔での報告のみを必要とすることがあり、または、送信機は、実際の視線方向、加速度などを必要とすることがある。たとえば、受信機側の予測のために、受信機は、最も可能性の高いコンテンツなどについての顕著性情報または統計を要求し得る。言い換えると、ネゴシエーションの間に、送信機および受信機は、交換されるべきフィードバックメッセージおよびフィードバックコンテンツを決定し得る。
【0231】
受信機が予測を実行することになる場合、送信機は、コンテンツ特性についての知識、たとえば、ピクチャ領域の顕著性分析、ユーザの挙動の統計的分析、台本シーンの先験的な知識などに基づいて、視線方向または領域についての情報を受信機に提供し得る。受信機は、この情報を受信機側の予測処理へと含め得る。たとえば、送信機は、関心対象の領域のピクセル座標、または特定の領域に対応するヨー、ピッチ、ロールのような向きを受信機に示し得る。受信機は、送信機からのこの情報を、HMDセンサ218から受け取る高分解能の動きまたは向きの情報と融合させ、センサ218だけからのデータに基づく予測と比較して改善された予測を提供することができる。
【0232】
送信機側の予測の場合に送信機に送信されるべきセンサデータと比較すると、受信機側またはクライアント側の予測が有利であることがあり、それは、センサデータが直ちにまたは実質的に遅延なしで、かつより高い時間分解能で、たとえば90Hzと比べて1000Hzで利用可能であるからである。したがって、受信機は、送信機より正確な予測を可能にし得る。
【0233】
ビューポート予測能力および/または視点予測能力の交換に関する実施形態は、全体の360°ビデオデータのレンダリングされた2Dビューポート送信およびレンダリングされていない部分を提供する実施形態に限定されず、むしろ、ビューポート予測能力および/または視点予測能力の交換に関する上で説明された実施形態は、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0234】
本発明の実施形態は、予測されるビデオ視聴の向き対現実のビデオ視聴の向きという、視線の向きに関する誤差またはドリフトの報告に関する。
【0235】
実施形態によれば、受信機は、たとえばRTCP報告内で、送信機によって提供されるような特定の視線方向またはビューポートを示す、2Dのレンダリングされたビューポートまたは360°の投影されたビデオデータのようなイマーシブコンテンツが、受信機における実際の視線の向きと一致しないことをシグナリングする、誤差またはドリフトの指示を送信機に送信し得る。誤差またはドリフトは、使用されるマージンもしくはプリフェッチを適応させるために送信機によって使用されてもよく、または、より大きいもしくは小さい高品質のコンテンツカバレッジを有するように、視線の向きに固有の投影の変化を引き起こしてもよい。
【0236】
平均のドリフトは、特定の期間にわたる予測されるビューポート/視点および実際の視線の向き/視点位置の比としてシグナリングされてもよく、最悪の場合のドリフトは、特定の期間にわたって得られる最大のドリフト値としてシグナリングされてもよい。平均のドリフトまたは最大のドリフトまたは最悪の場合のドリフトのようなドリフトは、以下に図示されるようにRTCP拡張を使用してシグナリングされ得る。
0 1
+-+-+-+-+-+-+-+-+-+-+-+
| drift |
+-+-+-+-+-+-+-+-+-+-+-+
0 1
+-+-+-+-+-+-+-+-+-+-+-+
| drift |
+-+-+-+-+-+-+-+-+-+-+-+
【0237】
さらなる実施形態によれば、ドリフトが特定の方向、たとえばユーザの動きの方向である場合、すなわち、予測されるビューポートおよび/または予測される視点が同じ方向へのより小さい動きに相当する場合、ドリフトの方向がシグナリングされてもよく、送信機は、非対称のプリフェッチをもたらすように不一致予測の方向におけるプリフェッチを追加することによって予測を適応させることができ、すなわち、ある方向におけるプリフェッチが、別の方向におけるプリフェッチより多く行われ得る。
【0238】
またさらなる実施形態によれば、送信機に向かう受信機による誤差またはドリフトの報告が、レンダリングされたビューポートモードにおいて動作する間に行われる場合、および、ドリフト、たとえば平均のドリフトが、特定の時間長もしくは期間の間特定の閾値より大きい場合、または、最悪のドリフトが特定の閾値を超える場合、受信機は、ビューポート送信から投影されたビデオの送信に切り替えることを決定し得る。
【0239】
誤差またはドリフトの報告に関する実施形態は、全体の360°ビデオデータのようなイマーシブコンテンツのレンダリングされた2Dビューポート送信およびレンダリングされていない部分を提供する実施形態に限定されず、むしろ、誤差またはドリフトの報告に関する上で説明された実施形態は、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0240】
同じことが視点または位置に当てはまり、誤差/ドリフトは、そのためのコンテンツが送信される位置と比較した現在の位置の差分について示される。
【0241】
本発明の実施形態は、送信機と受信機との間のフォービエイテッドレンダリング情報の交換に関する。
【0242】
実施形態によれば、図3の受信機202のような受信機は、フォービエイテッドレンダリングを利用し得る。受信機は、フォービエイテッドレンダリングのために使用されるアルゴリズムのパラメータを送信機と共有し得るので、送信機は、フォービエイテッドレンダリングの動作モードと一致するコンテンツを生み出し得る。
【0243】
たとえば、視線方向の中心の距離に基づく品質のパラメータ化された関数として降格関数が使用され得るが、別の例は、コンテンツの品質の降格につながる領域または距離の閾値を提供することになる。
【0244】
さらに別の実施形態は、時間平均された眼の動きのエリアの時間的分布である。たとえば、受信機が95%の時間においてビューポートの80%をカバーするエリアを見つめている状況を考えると、送信機は、送信を適合させる、すなわち、ユーザにより通常は見つめられないビューポートの外側部分を、ユーザが95%の時間見つめている内側部分と比較してより低いピクセル密度で符号化すると決定し得る。品質は、量子化パラメータ(QP)またはそのデルタまたは別の尺度にマッピングされ得る。図6は、その周りの外側のエリア204より分解能が高い受信機が見つめている中心のエリア202を伴うビューポート200を示す。
【0245】
フォービエイテッドレンダリング情報の交換に関する実施形態は、全体の360°ビデオデータのレンダリングされた2Dビューポート送信およびレンダリングされていない部分を提供する実施形態に限定されず、むしろ、フォービエイテッドレンダリング情報の交換に関する上で説明された実施形態は、本明細書において説明される他の実施形態とも組み合わせて利用され得ることに留意されたい。
【0246】
説明された概念のいくつかの態様は装置の文脈で説明されたが、これらの態様は対応する方法の説明も表すことが明らかであり、ブロックまたはデバイスは方法ステップまたは方法ステップの特徴に対応する。同様に、方法ステップの文脈で説明される態様は、対応する装置の対応するブロックまたはアイテムまたは特徴の説明も表す。
【0247】
本発明の様々な要素および特徴は、アナログおよび/またはデジタル回路を使用してハードウェアで、1つまたは複数の汎用プロセッサもしくは専用プロセッサによる命令の実行を通じてソフトウェアで、またはハードウェアとソフトウェアの組合せで実装され得る。たとえば、本発明の実施形態は、コンピュータシステムまたは別の処理システムの環境において実装され得る。図7は、コンピュータシステム500の例を示す。ユニットまたはモジュール、ならびにこれらのユニットによって実行される方法のステップは、1つまたは複数のコンピュータシステム500上で実行され得る。コンピュータシステム500は、専用のまたは汎用のデジタルシグナルプロセッサのような1つまたは複数のプロセッサ502を含む。プロセッサ502は、バスまたはネットワークのような通信インフラストラクチャ504に接続される。コンピュータシステム500は、メインメモリ506、たとえばランダムアクセスメモリ(RAM)、セカンダリメモリ508、たとえばハードディスクドライブおよび/またはリムーバブルストレージドライブを含む。セカンダリメモリ508は、コンピュータプログラムまたは他の命令がコンピュータシステム500へとロードされることを可能にし得る。コンピュータシステム500はさらに、ソフトウェアおよびデータがコンピュータシステム500と外部デバイスとの間で伝送されることを可能にするための、通信インターフェース510を含み得る。通信は、通信インターフェースによって扱われることが可能な電気信号、電磁気信号、光信号、または他の信号の形態であり得る。通信は、ワイヤーまたはケーブル、光ファイバ、電話線、携帯電話リンク、RFリンク、および他の通信チャネル512を使用し得る。
【0248】
「コンピュータプログラム媒体」および「コンピュータ可読媒体」という用語は、リムーバブルストレージユニットまたはハードディスクドライブに設置されるハードディスクなどの、有形の記憶媒体を一般に指すために使用される。これらのコンピュータプログラム製品は、コンピュータシステム500にソフトウェアを提供するための手段である。コンピュータ制御論理とも呼ばれるコンピュータプログラムは、メインメモリ506および/またはセカンダリメモリ508に記憶される。コンピュータプログラムは、通信インターフェース510を介しても受信され得る。コンピュータプログラムは、実行されると、コンピュータシステム500が本発明を実施することを可能にする。具体的には、コンピュータプログラムは、実行されると、プロセッサ502が、本明細書において説明される方法のいずれかなどの本発明のプロセスを実施することを可能にする。したがって、そのようなコンピュータプログラムは、コンピュータシステム500のコントローラを表し得る。本開示がソフトウェアを使用して実装される場合、ソフトウェアは、コンピュータプログラム製品に記憶され、リムーバブルストレージドライブ、通信インターフェース510のようなインターフェースを使用して、コンピュータシステム500へロードされ得る。
【0249】
ハードウェアまたはソフトウェアでの実装は、電気的に可読の制御信号が記憶されており、それぞれの方法が実行されるようにプログラム可能コンピュータシステムと協働する(または協働することが可能な)、デジタル記憶媒体、たとえば、クラウドストレージ、フロッピーディスク、DVD、Blu-Ray、CD、ROM、PROM、EPROM、EEPROM、またはフラッシュメモリを使用して、実行され得る。したがって、デジタル記憶媒体はコンピュータ可読であり得る。
【0250】
本発明によるいくつかの実施形態は、本明細書において説明される方法のうちの1つが実行されるように、プログラム可能コンピュータシステムと協働することが可能な、電気的に可読の制御信号を有するデータ担体を備える。
【0251】
一般に、本発明の実施形態は、プログラムコードを伴うコンピュータプログラム製品として実装されてもよく、プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されるとき、方法のうちの1つを実行するために動作可能である。プログラムコードは、たとえば機械可読担体に記憶され得る。
【0252】
他の実施形態は、機械可読担体に記憶される、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムを備える。言い換えると、本発明の方法の実施形態は、したがってコンピュータプログラムがコンピュータ上で実行されるとき、本明細書において説明される方法のうちの1つを実行するためのプログラムコードを有するコンピュータプログラムである。
【0253】
本発明の方法のさらなる実施形態は、したがって、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムが記録されているデータ担体(またはデジタル記憶媒体、またはコンピュータ可読媒体)である。本発明の方法のさらなる実施形態は、したがって、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムを表現する信号のデータストリームまたはシーケンスである。信号のデータストリームまたはシーケンスは、データ通信接続を介して、たとえばインターネットを介して、伝送されるように構成され得る。さらなる実施形態は、本明細書において説明される方法のうちの1つを実行するように構成または適合される、処理手段、たとえばコンピュータ、またはプログラマブル論理デバイスを備える。さらなる実施形態は、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムがインストールされたコンピュータを備える。
【0254】
いくつかの実施形態では、プログラマブル論理デバイス(たとえば、フィールドプログラマブルゲートアレイ)は、本明細書において説明される方法の機能の一部またはすべてを実行するために使用され得る。いくつかの実施形態では、フィールドプログラマブルゲートアレイは、本明細書において説明される方法のうちの1つを実行するために、マイクロプロセッサと協働し得る。一般に、方法は、好ましくは任意のハードウェア装置によって実行される。
【0255】
上で説明された実施形態は、本発明の原理を例示するものにすぎない。本明細書において説明される構成および詳細の修正と変形が、当業者に明らかであることが理解される。したがって、直後の特許請求の範囲によってのみ限定され、本明細書の実施形態の記述と説明として提示される具体的な詳細によっては限定されないことが意図される。
【符号の説明】
【0256】
200 サーバ
202 クライアント
204 メディアストリーム
206 シグナルプロセッサ
208 シグナルプロセッサ
210 HMD
212 内部ディスプレイ
214 ビュー選択
216 空間シーン
218 センサ
220 ストレージ
502 プロセッサ
504 通信インフラストラクチャ
506 メインメモリ
508 セカンダリメモリ
510 通信インターフェース
512 通信チャネル
202 クライアント
204 メディアストリーム
206 シグナルプロセッサ
208 シグナルプロセッサ
210 HMD
212 内部ディスプレイ
214 ビュー選択
216 空間シーン
218 センサ
220 ストレージ
502 プロセッサ
504 通信インフラストラクチャ
506 メインメモリ
508 セカンダリメモリ
510 通信インターフェース
512 通信チャネル
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】