WO2023084789A1 - 配信装置、配信方法及びプログラム - Google Patents

Abstract

一実施形態に係る配信装置は、ポリゴンメッシュとテクスチャとで構成される物体の立体映像コンテンツを端末に配信する配信装置であって、前記ポリゴンメッシュの各フレームデータをそれぞれ表す各メッシュフレームデータから複数の第１のチャンクデータを作成する第１のチャンク作成部と、前記テクスチャの各フレームデータをそれぞれ表す各テクスチャフレームデータから複数の第２のチャンクデータを作成する第２のチャンク作成部と、前記端末からのチャンク配信要求に応じて、前記チャンク配信要求に係る第１のチャンクデータ及び第２のチャンクデータの少なくとも一方を前記端末に送信するチャンク配信部と、を有する。

Description

配信装置、配信方法及びプログラム

　本発明は、ボリュメトリックビデオやホログラム等の立体映像コンテンツの配信技術に関する。

　ボリュメトリックビデオやホログラム等に代表される６自由度（６ＤｏＦ：six degrees of freedom）を持つ立体映像コンテンツが知られている。このようなコンテンツを通信ネットワークにより高品質に配信するためには、高いデータ圧縮技術や通信ネットワーク／システムの負荷分散技術等の利用に加えて、コンテンツ自体の配信を制御する仕組みが必要である。特に、クライアントとなるＸＲ（ＶＲ／ＡＲ／ＭＲ／ＳＲ等）デバイスの視界情報や仮想空間におけるユーザの位置情報等に応じて、コンテンツの配信を動的に制御する仕組みが重要である。

　ボリュメトリックビデオはポリゴンメッシュ（以下、単に「メッシュ」ともいう。）とテクスチャとで構成された物体のアニメーションデータであり、クライアント側で仮想環境と合わせてレンダリングすることで、ＸＲデバイスのディスプレイ上に表示され、視聴ができる。

　ボリュメトリックビデオ配信技術として、非特許文献１～３に記載されている技術が知られている。非特許文献１では、クライアントであるＡＲ／ＶＲデバイスで検出されたユーザの頭の動きに基づいて、ボリュメトリックビデオのレンダリングをサーバ側で行い、２Ｄデータとして当該クライアントに送信する手法が提案されている。また、非特許文献２では、リアルタイムで生成されたボリュメトリックビデオをクライアントに配信し、クライアント側でレンダリングする手法が提案されている。更に、非特許文献３では、２Ｄ映像コンテンツのデータの配信に関するＭＰＥＧ－ＤＡＳＨと呼ばれる仕組みが提案されている。ＭＰＥＧ－ＤＡＳＨでは２Ｄ映像コンテンツのデータがチャンク（又はセグメント）と呼ばれるファイルに分割されており、２Ｄ映像を再生する端末は、チャンクファイルの一覧等が記載されたマニフェストファイルに基づいて、チャンクファイルの取得要求をデータ配信サーバに対して送信する。このようなデータ配信方式はチャンク配信方式とも呼ばれる。

Serhan Gul, Dimitri Podborski, Thomas Buchholz, Thomas Schierl and Cornelius Hellge, "Low-latency cloud-based volumetric video streaming using head motion prediction," https://arxiv.org/abs/2001.06466 Sergio Orts-Escolano et al., "Holoportation: Virtual 3D teleportation in real-time," https://dl.acm.org/doi/10.1145/2984511.2984517 MPEG-DASH, https://mpeg.chiariglione.org/standards/mpeg-dash

　ところで、ボリュメトリックビデオはデータ量が大きく、その配信に必要な通信ネットワークの帯域が大きいため、効率的に配信する手法が求められている。

　しかしながら、上記の非特許文献１で提案されている手法では、各ユーザのレンダリングをサーバ側で行う必要があるため、サーバの負荷が大きい。また、ユーザ数が増えた場合にはサーバリソースの分割によって、各ユーザが視聴する映像品質の劣化が発生し得る。更に、クライアントからサーバに対して位置情報を高頻度に低遅延で送信する必要があり、例えば、ＶＲ酔いが発生し始めるＭｏｔｉｏｎ　ｔｏ　Ｐｈｏｔｏｎ遅延を２０ｍｓ以下に抑えることは通信ネットワークとサーバの両方で負担が大きい。

　一方で、上記の非特許文献２で提案されている手法では、通信帯域に４Ｇｂｐｓ必要であるが、４Ｇｂｐｓの通信帯域をユーザが常に安定して確保することは難しい。また、通信ネットワークの負荷が大きいため、同一の通信ネットワークを使用する他のユーザの使用可能帯域が狭まり、他のユーザの体感品質を落としてしまう。更に、２Ｄデータがフレーム単位で配信されるため、各フレームをメモリにロードする負荷が高く、例えば、高性能ではないＰＣで映像を再生する場合やネットワーク帯域が不足している場合には、２Ｄデータがバッファリングされずに映像の映像が頻繁に中断されてしまう。

　これに対して、チャンク配信方式を用いることで上記の課題を解決することができると考えられるが、非特許文献３に記載されているチャンク配信方式は２Ｄ映像コンテンツを対象としており、例えば、ＭＰ４形式等といったデータ形式である必要がある。

　本発明の一実施形態は、上記の点に鑑みてなされたもので、立体映像コンテンツに対するチャンク配信方式を実現することを目的とする。

　上記目的を達成するため、一実施形態に係る配信装置は、ポリゴンメッシュとテクスチャとで構成される物体の立体映像コンテンツを端末に配信する配信装置であって、前記ポリゴンメッシュの各フレームデータをそれぞれ表す各メッシュフレームデータから複数の第１のチャンクデータを作成する第１のチャンク作成部と、前記テクスチャの各フレームデータをそれぞれ表す各テクスチャフレームデータから複数の第２のチャンクデータを作成する第２のチャンク作成部と、前記端末からのチャンク配信要求に応じて、前記チャンク配信要求に係る第１のチャンクデータ及び第２のチャンクデータの少なくとも一方を前記端末に送信するチャンク配信部と、を有する。

　立体映像コンテンツに対するチャンク配信方式を実現することができる。

本実施形態に係る配信システムの全体構成の一例を示す図である。 本実施形態に係るチャンクデータ作成処理の一例を示すフローチャートである。 ポリゴンメッシュフレームのチャンク化の一例を模式的に示す図である。 テクスチャフレームのチャンク化の一例を模式的に示す図である。 本実施形態に係るボリュメトリックビデオ再生処理の一例を示すシーケンス図である。 チャンクデータのレンダリングの一例を模式的に示す図である。 本実施形態に係る配信サーバのハードウェア構成の一例を示す図である。 本実施形態に係るクライアント端末のハードウェア構成の一例を示す図である。

　以下、本発明の一実施形態について説明する。本実施形態では、立体映像コンテンツの一例としてボリュメトリックビデオを対象に、ボリュメトリックビデオに対するチャンク配信方式を実現する配信システム１について説明する。ここで、ボリュメトリックビデオとは、メッシュとテクスチャとで表される物体（人、動物等も含む。）の３Ｄデータ（３次元データ又は立体データともいう。）で構成されたアニメーションデータのことである。すなわち、例えば、時刻ｔのフレームにおける３Ｄデータをｄ_ｔとすれば、ボリュメトリックビデオは｛ｄ_ｔ＝（ｍ_ｔ，ｎ_ｔ）｜ｔ∈［ｔ_ｓ，ｔ_ｅ］｝と表される。ｍ_ｔは時刻ｔのフレームのメッシュデータ、ｎ_ｔは時刻ｔのフレームのテクスチャデータ、ｔ_ｓはボリュメトリックビデオの開始時刻、ｔ_ｅは終了時刻である。以下、ｄ_ｔを時刻ｔの３Ｄフレームデータ、ｍ_ｔを時刻ｔのメッシュフレームデータ、ｎ_ｔを時刻ｔのテクスチャフレームデータとも呼ぶことにする。また、以下では、簡単のため、ｔ_ｓ＝１、ｔ_ｅ＝Ｔとする。

　なお、以下で説明する実施形態は、ボリュメトリックビデオに限られず、例えば、ホログラム等といった６自由度を持つ立体映像コンテンツに対しても同様に適用することができる。

　＜配信システム１の全体構成＞
　まず、本実施形態に係る配信システム１の全体構成について、図１を参照しながら説明する。図１は、本実施形態に係る配信システム１の全体構成の一例を示す図である。

　図１に示すように、本実施形態に係る配信システム１には、配信サーバ１０と、クライアント端末２０と、視聴デバイス３０とが含まれる。配信サーバ１０とクライアント端末２０は、例えば、インターネット等の通信ネットワークＮを介して通信可能に接続される。一方で、クライアント端末２０と視聴デバイス３０は、任意の有線又は無線接続方式により通信可能に接続される。

　配信サーバ１０は、ボリュメトリックビデオを構成する各３Ｄフレームデータに含まれるメッシュフレームデータ及びテクスチャフレームデータのそれぞれをチャンクと呼ばれるまとまりに分割してチャンクデータを作成すると共に、各チャンクの番号（以下、チャンク番号ともいう。）と各チャンクのデータサイズ（以下、チャンクサイズともいう。）とが含まれるチャンク情報を作成する。

　また、配信サーバ１０は、クライアント端末２０からの視聴開始要求に応じてチャンク情報を送信すると共に、クライアント端末２０からのチャンク配信要求に応じて該当のチャンクデータを送信する。

　クライアント端末２０は、ボリュメトリックビデオを視聴するユーザが利用する各種端末（例えば、ＰＣやゲーム機器等）である。クライアント端末２０は、チャンク情報に基づいて、配信サーバ１０に対して配信を要求するチャンクデータを決定する。また、クライアント端末２０は、配信サーバ１０から配信されたチャンクデータをバッファすると共に、チャンクデータのレンダリングを行って映像データをストリームとして視聴デバイス３０に送信する。

　視聴デバイス３０は、ボリュメトリックビデオを視聴するための各種端末であり、クライアント端末２０から受信した映像データに基づいてボリュメトリックビデオを再生する。なお、視聴デバイス３０としては、例えば、ＸＲ（ＶＲ／ＡＲ／ＭＲ／ＳＲ等）デバイスとして機能するＨＭＤ（Head Mount Display）、ＸＲデバイスとして機能するアプリケーションプログラムが搭載されたスマーフォンやタブレット端末、ウェアラブルデバイス等が挙げられる。

　なお、例えば、クライアント端末２０がＸＲデバイスとしても機能する場合には、クライアント端末２０でボリュメトリックビデオを再生してもよい。この場合、視聴デバイス３０は不要である。

　ここで、本実施形態に係る配信サーバ１０は、チャンク作成部１０１と、要求受信部１０２と、データ配信部１０３と、データ記憶部１０４とを有する。

　チャンク作成部１０１は、データ記憶部１０４に記憶されているボリュメトリックビデオからチャンクデータを作成する。このとき、チャンク作成部１０１は、ボリュメトリックビデオを構成する３Ｄフレームデータに含まれるメッシュフレームデータをチャンクに分割し、各チャンクを圧縮することでメッシュチャンクデータを作成する。同様に、チャンク作成部１０１は、ボリュメトリックビデオを構成する３Ｄフレームデータに含まれるテクスチャフレームデータをチャンクに分割し、各チャンクを圧縮することでテクスチャチャンクデータを作成する。そして、チャンク作成部１０１は、各メッシュチャンクデータと各テクスチャチャンクデータとに対してそれぞれチャンク番号を付与した上でデータ記憶部１０４に保存する。以下、メッシュチャンクデータに付与されたチャンク番号をメッシュチャンク番号、テクスチャチャンクデータに付与されたチャンク番号をテクスチャチャンク番号ともいう。なお、各チャンク番号は時系列順にそれぞれ１から順に付与される。

　また、チャンク作成部１０１は、メッシュチャンク番号及びそのチャンク番号のメッシュチャンクデータのチャンクサイズと、テクスチャチャンク番号及びそのチャンク番号のテクスチャチャンクデータのチャンクサイズとが含まれるチャンク情報を作成する。そして、チャンク作成部１０１は、チャンク情報をボリュメトリックビデオと対応付けてデータ記憶部１０４に保存する。

　要求受信部１０２は、クライアント端末２０からの視聴開始要求やチャンク配信要求を受信する。視聴開始要求とは、ボリュメトリックビデオの視聴を開始するための要求であり、例えば、ユーザが視聴を所望するボリュメトリックビデオのＩＤ等が含まれる。また、チャンク配信要求とは、チャンクデータの配信要求であり、例えば、チャンクデータのチャンク番号（メッシュチャンク番号とテクスチャチャンク番号の少なくとも一方）が含まれる。

　データ配信部１０３は、要求受信部１０２が視聴開始要求を受信した場合、この視聴開始要求に含まれるＩＤのボリュメトリックビデオに対応付けられているチャンク情報を要求元のクライアント端末２０に送信する。また、データ配信部１０３は、要求受信部１０２がチャンク配信要求を受信した場合、このチャンク配信要求に含まれるチャンク番号のチャンクデータを要求元のクライアント端末２０に送信する。

　データ記憶部１０４は、ボリュメトリックビデオと、このボリュメトリックから作成されたチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）及びチャンク情報と記憶する。なお、ボリュメトリックビデオにはそのボリュメトリックビデオを一意に識別するＩＤ（以下、ボリュメトリックビデオＩＤともいう。）が付与されている。

　また、本実施形態に係るクライアント端末２０は、データ受信部２０１と、要求チャンク決定部２０２と、要求送信部２０３と、レンダリング部２０４と、バッファ部２０５とを有する。

　データ受信部２０１は、配信サーバ１０からのチャンク情報やチャンクデータを受信する。また、データ受信部２０１は、配信サーバ１０から受信したチャンクデータをバッファ部２０５にバッファ（一時的に記憶）する。

　要求チャンク決定部２０２は、チャンク情報に基づいて、配信サーバ１０に対して配信を要求するチャンクデータのチャンク番号を決定する。

　要求送信部２０３は、ボリュメトリックビデオの視聴を開始する場合に視聴開始要求を配信サーバ１０に送信する。また、要求送信部２０３は、要求チャンク決定部２０２によりチャンク番号が決定された場合、そのチャンク番号が含まれるチャンク配信要求を配信サーバ１０に送信する。

　レンダリング部２０４は、バッファ部２０５にバッファされているチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）を仮想環境と合わせてレンダリングすることで映像データを生成する。そして、レンダリング部２０４は、映像データをストリームとして視聴デバイス３０に送信する。

　バッファ部２０５は、配信サーバ１０から受信したメッシュチャンクデータとテクスチャチャンクデータをそれぞれバッファ（一時的に記憶）する。

　＜チャンクデータ作成処理＞
　以下、本実施形態に係るチャンクデータ作成処理について、図２を参照しながら説明する。図２は、本実施形態に係るチャンクデータ作成処理の一例を示すフローチャートである。なお、このチャンクデータ作成処理はオフラインで実施（つまり、ボリュメトリックビデオの再生よりも前に事前に実施）される。

　配信サーバ１０のチャンク作成部１０１は、データ記憶部１０４に記憶されているボリュメトリックビデオを構成する３Ｄフレームデータ｛ｄ_ｔ＝（ｍ_ｔ，ｎ_ｔ）｜ｔ∈［１，Ｔ］｝に含まれるメッシュフレームデータ｛ｍ_ｔ｜ｔ∈［１，Ｔ］｝及びテクスチャフレームデータ｛ｎ_ｔ｜ｔ∈［１，Ｔ］｝をそれぞれチャンクに分割する（ステップＳ１０１）。

　このとき、メッシュフレームデータ｛ｍ_ｔ｜ｔ∈［１，Ｔ］｝に関しては、チャンク作成部１０１は、例えば、各３Ｄフレームデータｄ_ｔ（又は各ポリゴンメッシュフレームｍ_ｔ）の内容を分析し、フレーム補間等に基づいて、各チャンクのチャンクサイズが最も小さくようにメッシュフレームデータ｛ｍ_ｔ｜ｔ∈［１，Ｔ］｝をチャンクに分割する。

　一方で、テクスチャフレームデータ｛ｎ_ｔ｜ｔ∈［１，Ｔ］｝に関しては、チャンク作成部１０１は、例えば、互いに隣り合うテクスチャフレームデータｎ_ｔ及びｎ_ｔ＋１をｔ＝１から順に分析し、テクスチャの構造が大きく変化する前までのテクスチャフレームデータを１つのチャンクとして、テクスチャフレームデータ｛ｎ_ｔ｜ｔ∈［１，Ｔ］をチャンクに分割する。例えば、時刻ｔ_１，ｔ_２，ｔ_３（ただし、ｔ_１＜ｔ_２＜ｔ_３）でテクスチャの構造が大きく変化した場合、｛ｎ_ｔ｜ｔ∈［１，ｔ_１－１］｝と｛ｎ_ｔ｜ｔ∈［ｔ_１，ｔ_２－１］｝と｛ｎ_ｔ｜ｔ∈［ｔ_２，ｔ_３－１］｝と｛ｎ_ｔ｜ｔ∈［ｔ_３，Ｔ］｝の４つのチャンクに分割される。ここで、テクスチャの構造が大きく変化する場合とは、例えば、テクスチャフレームデータｎ_ｔが表すテクスチャとテクスチャフレームデータｎ_ｔ＋１が表すテクスチャとの間で、明るさ、色、濃淡、模様のパターン等を数値化して比較したときに、それらのうちの少なくとも一部が予め決められた所定の閾値以上変化した場合のことをいう。なお、テクスチャの構造が大きく変化する場合は、例えば、テクスチャフレームデータｎ_ｔが表すテクスチャとテクスチャフレームデータｎ_ｔ＋１が表すテクスチャとの間で、明るさ、色、濃淡、模様のパターン等を数値化して重み付け和等を計算したときに、その重み付け和の値が予め決められた所定の閾値以上変化した場合のことであってもよい。

　なお、上記のステップＳ１０１において、メッシュフレームデータとテクスチャフレームデータは互いに独立にチャンクに分割されることに留意されたい。

　次に、配信サーバ１０のチャンク作成部１０１は、上記のステップＳ１０１で分割された各チャンクのチャンクサイズが最も小さくなるように各フレームデータ（各メッシュフレームデータ及び各テクスチャフレームデータ）を圧縮する（ステップＳ１０２）。すなわち、メッシュフレームデータに関して、チャンク作成部１０１は、上記のステップＳ１０１で分割された各チャンクのチャンクサイズが最も小さくなるように各メッシュフレームデータｍ_ｔを圧縮する。同様に、テクスチャフレームデータに関して、チャンク作成部１０１は、上記のステップＳ１０１で分割された各チャンクのチャンクサイズが最も小さくなるように各テクスチャフレームデータｎ_ｔを圧縮する。これにより、チャンク単位の圧縮後のメッシュフレームデータで構成されるメッシュチャンクデータと、チャンク単位の圧縮後のテクスチャフレームデータで構成されるテクスチャチャンクデータとが作成されたことになる。

　次に、配信サーバ１０のチャンク作成部１０１は、上記のステップＳ１０１で作成されたメッシュチャンクデータとテクスチャチャンクデータとをデータ記憶部１０４に保存する（ステップＳ１０３）。また、このとき、チャンク作成部１０１は、各メッシュチャンクデータに対してメッシュチャンク番号を付与すると共に、各テクスチャチャンクデータに対してテクスチャチャンク番号を付与する。

　ここで、メッシュチャンクデータの一例を図３に示す。図３に示す例では、メッシュフレームデータｍ_１～ｍ_１０が１つのチャンクに分割されており、これらのメッシュフレームデータｍ_１～ｍ_１０の各々を圧縮したデータで構成されるメッシュチャンクデータが、メッシュチャンク番号「１」のメッシュチャンクデータとなっている。同様に、メッシュフレームデータｍ_１１～ｍ_１５が１つのチャンクに分割されており、これらのメッシュフレームデータｍ_１１～ｍ_１５の各々を圧縮したデータで構成されるメッシュチャンクデータが、メッシュチャンク番号「２」のメッシュチャンクデータとなっている。

　また、テクスチャチャンクデータの一例を図４に示す。図４に示す例では、テクスチャフレームデータｎ_１～ｎ_１０が１つのチャンクに分割されており、これらのテクスチャフレームデータｎ_１～ｎ_１０の各々を圧縮したデータで構成されるテクスチャフレームデータが、テクスチャチャンク番号「１」のテクスチャフレームデータとなっている。同様に、テクスチャフレームデータｎ_１１～ｎ_３０が１つのチャンクに分割されており、これらのテクスチャフレームデータｎ_１１～ｎ_３０の各々を圧縮したデータで構成されるテクスチャフレームデータが、テクスチャチャンク番号「２」のテクスチャフレームデータとなっている。

　そして、配信サーバ１０のチャンク作成部１０１は、チャンク番号とチャンクサイズとが含まれるチャンク情報を作成してボリュメトリックビデオと対応付けてデータ記憶部１０４に保存する（ステップＳ１０４）。具体的には、チャンク情報には、メッシュチャンク番号及びそのチャンク番号のメッシュチャンクデータのチャンクサイズと、テクスチャチャンク番号及びそのチャンク番号のテクスチャチャンクデータのチャンクサイズとが含まれる。

　＜ボリュメトリックビデオ再生処理＞
　以下、本実施形態に係るボリュメトリックビデオ再生処理について、図５を参照しながら説明する。図５は、本実施形態に係るボリュメトリックビデオ再生処理の一例を示すシーケンス図である。

　クライアント端末２０の要求送信部２０３は、視聴開始要求を配信サーバ１０に送信する（ステップＳ２０１）。ここで、視聴開始要求には、ユーザが視聴を所望するボリュメトリックビデオのボリュメトリックビデオＩＤが含まれる。

　配信サーバ１０のデータ配信部１０３は、要求受信部１０２が視聴開始要求を受信すると、当該視聴開始要求に含まれるボリュメトリックビデオＩＤのボリュメトリックビデオに対応付けられているチャンク情報をデータ記憶部１０４から取得し、取得したチャンク情報を要求元のクライアント端末２０に送信する（ステップＳ２０２）。

　以下のステップＳ２０３～ステップＳ２０８は、ユーザがボリュメトリックビデオを視聴している間、繰り返し実行される。

　クライアント端末２０の要求チャンク決定部２０２は、チャンク情報に基づいて、配信サーバ１０に対して配信を要求するチャンクデータのチャンク番号（メッシュチャンク番号とテクスチャチャンク番号）を決定する（ステップＳ２０３）。ここで、要求チャンク決定部２０２は、既知のチャンク配信方式と同様の手法により配信を要求するチャンクデータのチャンク番号を決定すればよい。例えば、メッシュチャンク番号「ｋ_１」までのメッシュチャンクデータとテクスチャチャンク番号「ｋ_２」までのテクスチャチャンクデータとが受信済みであるとする。この場合、要求チャンク決定部２０２は、現在のネットワーク帯域やバッファ部２０５の空き容量等といった条件と、メッシュチャンク番号「ｋ_１＋１」以降のメッシュチャンクデータのチャンクサイズと、テクスチャチャンク番号「ｋ_２＋１」のテクスチャチャンクデータのチャンクサイズとに基づいて、「ｋ_１＋１」以降のメッシュチャンク番号と、「ｋ_２＋１」以降のテクスチャチャンク番号とを、配信サーバ１０に対して配信を要求するチャンクデータのチャンク番号として決定する。なお、例えば、配信サーバ１０に対して配信を要求するチャンクデータのチャンク番号として、メッシュチャンク番号又はテクスチャチャンク番号のいずれか一方のみが決定される場合が存在してもよい。

　次に、クライアント端末２０の要求送信部２０３は、上記のステップＳ２０３で決定されたチャンク番号（メッシュチャンク番号とテクスチャチャンク番号）が含まれるチャンク配信要求を配信サーバ１０に送信する（ステップＳ２０４）。なお、メッシュチャンク番号とテクスチャチャンク番号のいずれか一方のみがチャンク配信要求に含まれる場合が存在してもよい。

　配信サーバ１０のデータ配信部１０３は、要求受信部１０２がチャンク配信要求を受信すると、上記のステップＳ２０２で受信した視聴開始要求に含まれるボリュメトリックビデオＩＤのボリュメトリックビデオのチャンクデータのうち、当該チャンク配信要求に含まれるチャンク番号のチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）を要求元のクライアント端末２０に送信する（ステップＳ２０５）。

　クライアント端末２０のデータ受信部２０１は、配信サーバ１０からチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）を受信すると、これらのチャンクデータをバッファ部２０５に格納する（ステップＳ２０６）。これにより、メッシュチャンクデータとテクスチャチャンクデータがバッファ部２０５にバッファされたことになる。

　以下のステップＳ２０７～ステップＳ２０８は、バッファ部２０５の容量が或る閾値ｔｈ_１を超えた場合に、その容量が別の或る閾値ｔｈ_２（＜ｔｈ_１）を下回るまで、上記のステップＳ２０３～ステップＳ２０６と並列に繰り返し実行される。例えば、典型的には、バッファ部２０５が一杯になった場合に、バッファ部２０５が空になるまで、以下のステップＳ２０７～ステップＳ２０８が上記のステップＳ２０３～ステップＳ２０６と並列に繰り返し実行される。

　クライアント端末２０のレンダリング部２０４は、バッファ部２０５にバッファされているチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）を仮想環境と合わせてレンダリングする（ステップＳ２０７）。これにより、映像データが生成される。バッファ部２０５にバッファされているチャンクデータ（メッシュチャンクデータとテクスチャチャンクデータ）のレンダリングの様子の一例を図６に示す。図６に示す例では、メッシュチャンク番号「１」のメッシュチャンクデータ１～メッシュチャンク番号「４」のメッシュチャンクデータ４と、テクスチャチャンク番号「１」のテクスチャチャンクデータ１～テクスチャチャンク番号「２」のテクスチャチャンクデータ２とがバッファ部２０５にバッファされており、これらのチャンクデータに含まれるフレームデータ（メッシュフレームデータとテクスチャフレームデータ）が時系列順にレンダリングされる。

　なお、すべてのフレームデータがレンダリングされたチャンクデータはバッファ部２０５から削除される。これにより、上記のステップＳ２０６で新たなチャンクデータをバッファ部２０５にバッファさせることが可能となる。

　クライアント端末２０のレンダリング部２０４は、上記のステップＳ２０７で生成された映像データをストリームとして視聴デバイス３０に送信する（ステップＳ２０８）。これにより、視聴デバイス３０では、クライアント端末２０から受信した映像データに基づいてボリュメトリックビデオが再生される。

　＜配信サーバ１０及びクライアント端末２０のハードウェア構成＞
　　≪配信サーバ１０≫
　次に、本実施形態に係る配信サーバ１０のハードウェア構成について、図７を参照しながら説明する。図７は、本実施形態に係る配信サーバ１０のハードウェア構成の一例を示す図である。

　図７に示すように、本実施形態に係る配信サーバ１０は、外部Ｉ／Ｆ３０１と、通信Ｉ／Ｆ３０２と、プロセッサ３０３と、メモリ装置３０４とを有する。これらの各ハードウェアは、それぞれがバス３０５を介して通信可能に接続される。

　外部Ｉ／Ｆ３０１は、記録媒体３０１ａ等の外部装置とのインタフェースである。なお、記録媒体３０１ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。

　通信Ｉ／Ｆ３０２は、配信サーバ１０が通信ネットワークＮに接続するためのインタフェースである。プロセッサ３０３は、例えば、ＣＰＵ（Central Processing Unit）等の各種演算装置である。メモリ装置３０４は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等の各種記憶装置である。

　本実施形態に係る配信サーバ１０は、上記のハードウェア構成を有することにより、上述した各種処理を実現することができる。ただし、図７に示すハードウェア構成は一例であって、配信サーバ１０は、他のハードウェア構成を有していてもよい。例えば、配信サーバ１０は、キーボードやマウス等の入力装置、ディスプレイ等の表示装置等のハードウェアを更に有していてもよい。また、例えば、配信サーバ１０は、複数のプロセッサ３０３を有していてもよいし、複数のメモリ装置３０４を有していてもよい。

　なお、図１に示したチャンク作成部１０１、要求受信部１０２及びデータ配信部１０３は、例えば、配信サーバ１０にインストールされた１以上のプログラムが、プロセッサ３０３に実行させる処理により実現される。また、図１に示したデータ記憶部１０４は、例えば、ＨＤＤやＳＳＤ等といった補助記憶装置により実現される。ただし、データ記憶部１０４は、例えば、配信サーバ１０と通信ネットワークを介して接続されるデータベースサーバ等により実現されてもよい。

　　≪クライアント端末２０≫
　次に、本実施形態に係るクライアント端末２０のハードウェア構成について、図８を参照しながら説明する。図８は、本実施形態に係るクライアント端末２０のハードウェア構成の一例を示す図である。

　図８に示すように、本実施形態に係るクライアント端末２０は、入力装置４０１と、表示装置４０２と、外部Ｉ／Ｆ４０３と、通信Ｉ／Ｆ４０４と、プロセッサ４０５と、メモリ装置４０６とを有する。これらの各ハードウェアは、それぞれがバス４０７を介して通信可能に接続される。

　入力装置４０１は、例えば、キーボードやマウス、タッチパネル等である。表示装置４０２は、例えば、ディスプレイ等である。なお、クライアント端末２０は、例えば、入力装置４０１及び表示装置４０２のうちの少なくとも一方を有していなくてもよい。

　外部Ｉ／Ｆ４０３は、記録媒体４０３ａ等の外部装置とのインタフェースである。なお、記録媒体４０３ａとしては、例えば、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリカード等が挙げられる。

　通信Ｉ／Ｆ４０４は、クライアント端末２０が通信ネットワークＮに接続したり、視聴デバイス３０に映像データを送信したりするためのインタフェースである。プロセッサ４０５は、例えば、ＣＰＵやＧＰＵ（Graphics Processing Unit）等の各種演算装置である。メモリ装置４０６は、例えば、ＨＤＤ、ＳＳＤ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の各種記憶装置である。

　本実施形態に係るクライアント端末２０は、上記のハードウェア構成を有することにより、上述した各種処理を実現することができる。ただし、図８に示すハードウェア構成は一例であって、クライアント端末２０は、他のハードウェア構成を有していてもよい。例えば、クライアント端末２０は、複数のプロセッサ４０５を有していてもよいし、複数のメモリ装置４０６を有していてもよい。

　なお、図１に示したデータ受信部２０１、要求チャンク決定部２０２、要求送信部２０３及びレンダリング部２０４は、例えば、クライアント端末２０にインストールされた１以上のプログラムが、プロセッサ４０５に実行させる処理により実現される。また、図１に示したバッファ部２０５は、例えば、メモリ装置４０６により実現される。

　＜まとめ＞
　以上のように、本実施形態に係る配信システム１は、チャンク配信方式を実現する際に、ボリュメトリックビデオを構成する３Ｄフレームデータに含まれるメッシュフレームデータとテクスチャフレームデータをそれぞれ独立にチャンク化する。これにより、メッシュフレームデータの各チャンクと、テクスチャフレームデータの各チャンクとをそれぞれ高い圧縮率で圧縮することが可能となり、メッシュチャンクデータのチャンクサイズとテクスチャチャンクデータのチャンクサイズとを削減させることが可能となる。このため、クライアント端末２０の処理負荷を削減させることが可能となり、２Ｄ映像コンテンツと比較してデータサイズが大きいボリュメトリックビデオ等といった立体映像コンテンツであっても中断の少ない再生を実現することが可能となる。

　本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。

　１　　　　配信システム
　１０　　　配信サーバ
　２０　　　クライアント端末
　３０　　　視聴デバイス
　１０１　　チャンク作成部
　１０２　　要求受信部
　１０３　　データ配信部
　１０４　　データ記憶部
　２０１　　データ受信部
　２０２　　要求チャンク決定部
　２０３　　要求送信部
　２０４　　レンダリング部
　２０５　　バッファ部
　３０１　　外部Ｉ／Ｆ
　３０１ａ　記録媒体
　３０２　　通信Ｉ／Ｆ
　３０３　　プロセッサ
　３０４　　メモリ装置
　３０５　　バス
　４０１　　入力装置
　４０２　　表示装置
　４０３　　外部Ｉ／Ｆ
　４０３ａ　記録媒体
　４０４　　通信Ｉ／Ｆ
　４０５　　プロセッサ
　４０６　　メモリ装置
　４０７　　バス
　Ｎ　　　　通信ネットワーク

Claims (7)

1. 　ポリゴンメッシュとテクスチャとで構成される物体の立体映像コンテンツを端末に配信する配信装置であって、
   　前記ポリゴンメッシュの各フレームデータをそれぞれ表す各メッシュフレームデータから複数の第１のチャンクデータを作成する第１のチャンク作成部と、
   　前記テクスチャの各フレームデータをそれぞれ表す各テクスチャフレームデータから複数の第２のチャンクデータを作成する第２のチャンク作成部と、
   　前記端末からのチャンク配信要求に応じて、前記チャンク配信要求に係る第１のチャンクデータ及び第２のチャンクデータの少なくとも一方を前記端末に送信するチャンク配信部と、
   　を有する配信装置。
2. 　前記第１のチャンク作成部は、
   　前記各メッシュフレームデータ又は前記立体映像コンテンツの各フレームデータの内容を分析し、フレーム補間に基づいて、各チャンクのサイズが最も小さくなるように、前記各メッシュフレームデータを複数のチャンクに分割することで、前記複数の第１のチャンクデータを作成する、請求項１に記載の配信装置。
3. 　前記第２のチャンク作成部は、
   　前記各テクスチャフレームデータのうち、互いに隣り合う時刻のテクスチャフレームデータ同士を時系列順に分析し、互いに隣り合う時刻のテクスチャフレームデータ間で前記テクスチャの構造が所定以上変化した場合、前記テクスチャの構造が所定以上変化する前までの各テクスチャフレームデータを１つのチャンクとして前記各テクスチャフレームデータを複数のチャンクに分割することで、前記複数の第２のチャンクデータを作成する、請求項１又は２に記載の配信装置。
4. 　前記テクスチャの構造は、前記テクスチャの明るさ、色、濃淡、模様のパターンの少なくとも１つである、請求項３に記載の配信装置。
5. 　前記複数の第１のチャンクデータそれぞれのチャンク番号及びデータサイズと、前記複数の第２のチャンクデータそれぞれのチャンク番号及びデータサイズとが含まれるチャンク情報を作成するチャンク情報作成部と、
   　前記端末からの視聴開始要求に応じて、前記視聴開始要求に係るチャンク情報を前記端末に送信するチャンク情報配信部と、を有し、
   　前記チャンク配信要求には、前記端末において、前記チャンク情報に基づいて決定されたチャンク番号が含まれる、請求項１乃至４の何れか一項に記載の配信装置。
6. 　ポリゴンメッシュとテクスチャとで構成される物体の立体映像コンテンツを端末に配信するコンピュータが、
   　前記ポリゴンメッシュの各フレームデータをそれぞれ表す各メッシュフレームデータから複数の第１のチャンクデータを作成する第１のチャンク作成手順と、
   　前記テクスチャの各フレームデータをそれぞれ表す各テクスチャフレームデータから複数の第２のチャンクデータを作成する第２のチャンク作成手順と、
   　前記端末からのチャンク配信要求に応じて、前記チャンク配信要求に係る第１のチャンクデータ及び第２のチャンクデータの少なくとも一方を前記端末に送信するチャンク配信手順と、
   　を実行する配信方法。
7. 　コンピュータを、請求項１乃至５の何れか一項に記載の配信装置として機能させるプログラム。

Images