(57)【要約】【課題】セグメントに分割された送信データの受信に当たり、通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施可能なクライアントを提供する。【解決手段】本クライアントは、セグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データをサーバから受信する。ここで、１つのセグメント分を受信するにあたり、この１つのセグメント分として準備された複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、サーバ宛てに送信し、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を送信する。また、要求したファイルの受信後、受信した１つのセグメント分のセグメントファイルの処理を実行する。なお、設定された優先度のより高いセグメントファイルを取得する要求を、より優先して送信することも好ましい。【選択図】図１
2018125621.tif 000002
【特許請求の範囲】
【請求項１】
複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントであって、
１つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有することを特徴とするクライアント。
【請求項２】
前記データ要求手段は、受け付けた指示又は予め決められた事項に基づいて、取得すべき当該複数種のセグメントファイルに優先度を設定し、当該優先度のより高いセグメントファイルを取得する要求を、より優先して送信させることを特徴とする請求項１に記載のクライアント。
【請求項３】
当該送信データは映像及び／又は音声ストリ−ムデータであって、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであり、
前記データ要求手段は、注視点及び／又は注聴点に係る映像及び／又は音声セグメントファイルに最も高い優先度を設定する
ことを特徴とする請求項２に記載のクライアント。
【請求項４】
当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
前記データ要求手段は、受け付けた指示又は予め決められた事項に基づいて、次のセグメント分を受信するにあたって取得すべき各セグメントファイルにつき、いずれの当該段階のセグメントファイルを選択するかを決定する
ことを特徴とする請求項１から３のいずれか１項に記載のクライアント。
【請求項５】
当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
前記データ要求手段は１つのセグメント分を受信するにあたり、１つの要求の結果として受信されたある段階のセグメントファイルの受信の具合に基づいて、次に又は以後取得を要求するセグメントファイルの段階を決定する
ことを特徴とする請求項１から４のいずれか１項に記載のクライアント。
【請求項６】
当該送信データは映像及び／又は音声ストリ−ムデータであり、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであって、当該複数段階のセグメントファイルは、互いにビットレートの異なる映像及び／又は音声セグメントファイルであり、
前記データ要求手段は、１つの要求の結果として受信されたあるビットレートのセグメントファイルの受信の具合に基づいて、次に又は以後取得を要求するセグメントファイルのビットレートを決定する
ことを特徴とする請求項５に記載のクライアント。
【請求項７】
前記データ要求手段は、当該あるビットレートのセグメントファイルの受信の際に算出されたスループットに基づいて、以後取得を要求する当該複数種の映像及び／又は音声セグメントファイルの各々に対し選択すべきビットレートを割り当てたビットレート分布を決定することを特徴とする請求項６に記載のクライアント。
【請求項８】
１つのセグメント分の受信が、少なくとも、次に受信すべき次のセグメント分の受信の開始までに完了するか否かを判定する受信遅延判定手段を更に有し、
前記データ要求手段は、当該１つのセグメント分を受信するにあたり、前記受信遅延判定手段での判定結果に基づき、以後行う各要求において、取得を要求するセグメントファイルの数を決定する
ことを特徴とする請求項１から７のいずれか１項に記載のクライアント。
【請求項９】
前記データ要求手段は、以後行う１つの要求において、複数のセグメントファイルの取得を要求する際、当該１つの要求の中に、前記サーバによるプッシュ送信の指示を含めることを特徴とする請求項８に記載のクライアント。
【請求項１０】
複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータを機能させるクライアント制御プログラムであって、
であって、
１つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
してコンピュータを機能させることを特徴とするクライアント制御プログラム。
【請求項１１】
複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータにおけるクライアント制御方法であって、
１つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるステップと、
受信された１つのセグメント分のセグメントファイルの処理を実行するステップと
を有することを特徴とするクライアント制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大容量のデータをサーバから取得するクライアントにおける受信制御技術に関する。
【背景技術】
【０００２】
次世代における高い臨場感を提供可能なメディアの一つとして、自由視点映像が注目されている。自由視点映像とは、対象物に対する視点をユーザが任意に指定し、指定された視点からの映像を随時提供する、といったインタラクティブな視聴を可能にする映像である。
【０００３】
この自由視点映像の合成方式の一典型例として、３次元モデル上に視点毎の対象物画像を配置し、ユーザが指定した任意の仮想視点からの見え方を、これらの配置画像を用いて計算することによって描画を実施する方法が挙げられる。具体的に、この方法での合成処理は、サーバから配信された以下の（ａ）〜（ｃ）を含むコンテンツを取得したクライアント側で実施される。
（ａ）各視点の映像ストリーム
（ｂ）各視点に存在する対象物情報（マスク画像、３次元の位置・大きさに係る情報）
（ｃ）各視点のカメラキャリブレーション情報
【０００４】
このように、自由視点映像の合成処理では、サーバ側において、各コンテンツを視点数分（多視点分）だけ予め準備しておく必要のあるのが通常である。この際、特に、上記（ａ）の映像ストリームについては高解像度化によって１視点当たりのビットレートも相当に高くなっており、インターネット経由で配信することを考えると、データ量が大きくなり過ぎるという問題が生じていた。
【０００５】
この問題に対し、例えば特許文献１では、全視点分の映像ストリームを配信しつつ、ユーザが現在指定している視点以外の映像についてはそのビットレートを下げることによって、全体のレートをできる限り低下させる技術が提案されている。
【０００６】
一方、自由視点映像の配信方式としては、例えば予め作成された映像コンテンツを配信する場合、ＶｏＤ（Video on Demand）型配信が用いられることが一般的である。具体的には、ＤＡＳＨ（Dynamic Adaptive Streaming over Hyper transfer protocol）や、ＨＬＳ（HTTP Live Streaming）といったプロトコルが広く利用されている。このような方式では、予め映像ストリームを数〜１０秒程度の再生時間長を有するセグメントファイルに分割しておき、クライアント側がこのセグメント単位で受信及び再生開始を行うことによって、映像ストリームを受信しながら再生する擬似ストリーミングが実現される。
【０００７】
さらに、映像ストリームに異なる品質（ビットレート）のものを用意し、セグメント毎に互いに異なるビットレートのセグメントファイルを揃えておくことによって、セグメント単位でビットレートを切り替えることも可能となる。これにより、通信ネットワークの通信状況に応じ、クライアント側が要求するコンテンツの品質を変更することもできるのである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１３−１８３２０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に記載された技術を含む従来の技術では、配信に使用される通信ネットワークの通信状況によっては、クライアント側でセグメントファイルの受信遅延が生じ、例えば、配信映像の再生が途中で停止したり何らかの障害を受けたりする場合のあることが問題となってきた。
【００１０】
実際、特許文献１に記載の技術では、クライアント側で、要求する各視点のセグメントファイルにおけるビットレートの配分を、注視点を最大とする確率分布に基づいて決定し、その後、サーバがクライアントからの要求を受け、決定されたビットレートを有する各視点のセグメントファイルを多重化して配信している。
【００１１】
このため、各視点のセグメントファイルにおけるビットレートの配分を決定して当該各視点のセグメントファイルを要求するタイミングが、全ての視点にわたって同時となっている。したがって、例えば、セグメントファイルの要求後に通信ネットワークのスループットが急激に低下したような場合でも、配信されてくるセグメントファイルのビットレートを後追いでより低いものにする、といったような対応は不可能である。
【００１２】
すなわち、従来技術では具体的に、全視点のセグメントファイルが受信完了するまでは、再生(デコード)を開始し、さらに各視点のセグメントファイルにおけるビットレートの配分を変更することができない。その結果、例えば、ユーザが今現在選択した視点（以下、注視点と略称）以外の視点についてのビットレートを適応的に下げて、全視点のセグメントファイルの受信を次の再生開始に間に合わせるといった制御は不可能となっている。これにより、スループットが頻繁に変動する状況では、視点毎の動的な配信制御によって対応することはできず、再生停止が発生しやすくなるという問題が生じていた。
【００１３】
さらに、各視点についてのビットレートの配分は、前回の要求の際の配分に依ることなく独立に決定されるので、結果的に、スループットの低下時には注視点のセグメントファイルにおけるビットレートも引きずられて低下してしまうという問題も生じていた。
【００１４】
ちなみに、このような受信遅延によるクライアント側での処理の停止・中断の問題は、以上に例示した多視点映像ストリームのケースに限定されるものではない。例えば、複数のセグメントファイルに分割された大容量の送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対し、データ要求を行うクライアントであれば、同様の問題が現実に生じる。
【００１５】
そこで、本発明は、セグメントに分割された送信データの受信に当たり、通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施可能なクライアント、クライアント制御プログラム及びクライアント制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明によれば、複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントであって、
１つのセグメント分を受信するにあたり、この１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、サーバ宛てに送信させるデータ要求手段と、
受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有するクライアントが提供される。
【００１７】
この本発明によるクライアントのデータ要求手段は、受け付けた指示又は予め決められた事項に基づいて、取得すべき当該複数種のセグメントファイルに優先度を設定し、当該優先度の最も高いセグメントファイルを取得する要求を、優先して送信させることも好ましい。
【００１８】
ここで、上記の優先度を用いた実施形態の一具体例として、該送信データは映像及び／又は音声ストリ−ムデータであって、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであり、
データ要求手段は、注視点及び／又は注聴点に係る映像及び／又は音声セグメントファイルに最も高い優先度を設定することも好ましい。
【００１９】
また、本発明によるクライアントの他の実施形態として、当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
データ要求手段は、受け付けた指示又は予め決められた事項に基づいて、次のセグメント分を受信するにあたって取得すべき各セグメントファイルにつき、いずれの当該段階のセグメントファイルを選択するかを決定することも好ましい。
【００２０】
さらに、本発明によるクライアントの更なる他の実施形態として、当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
データ要求手段は１つのセグメント分を受信するにあたり、１つの要求の結果として受信されたある段階のセグメントファイルの受信の具合に基づいて、次に又は以後取得を要求するセグメントファイルの段階を決定することも好ましい。
【００２１】
また、上記のセグメントファイルの段階を決定する実施形態において、データ要求手段は、当該ある段階のセグメントファイルの受信の具合に基づいて、以後取得を要求する当該複数種の映像及び／又は音声セグメントファイルの各々に対し選択すべきビットレートを割り当てたビットレート分布を決定することも好ましい。
【００２２】
ここで、上記のセグメントファイルの段階を決定する実施形態の一具体例として、当該送信データは映像及び／又は音声ストリ−ムデータであり、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであって、当該複数段階のセグメントファイルは、互いにビットレートの異なる映像及び／又は音声セグメントファイルであり、
データ要求手段は、１つの要求の結果として受信されたあるビットレートのセグメントファイルの受信の際に算出されたスループットに基づいて、次に又は以後取得を要求するセグメントファイルのビットレートを決定することも好ましい。
【００２３】
さらに、本発明によるクライアントの更なる他の実施形態として、本クライアントは、１つのセグメント分の受信が、少なくとも、次に受信すべき次のセグメント分の受信の開始までに完了するか否かを判定する受信遅延判定手段を更に有し、
データ要求手段は、当該１つのセグメント分を受信するにあたり、受信遅延判定手段での判定結果に基づき、以後行う各要求において、取得を要求するセグメントファイルの数を決定することも好ましい。
【００２４】
また、この受信遅延判定を行う実施形態において、データ要求手段は、以後行う１つの要求において、複数のセグメントファイルの取得を要求する際、当該１つの要求の中に、サーバによるプッシュ送信の指示を含めることも好ましい。
【００２５】
本発明によれば、また、複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータを機能させるクライアント制御プログラムであって、
であって、
１つのセグメント分を受信するにあたり、この１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、サーバ宛てに送信させるデータ要求手段と、
受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
してコンピュータを機能させるクライアント制御プログラムが提供される。
【００２６】
本発明によれば、さらに、複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータにおけるクライアント制御方法であって、
１つのセグメント分を受信するにあたり、この１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、サーバ宛てに送信させるステップと、
受信された１つのセグメント分のセグメントファイルの処理を実行するステップと
を有するクライアント制御方法が提供される。
【発明の効果】
【００２７】
本発明のクライアント、クライアント制御プログラム及びクライアント制御方法によれば、セグメントに分割された送信データの受信に当たり、通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明によるクライアントの一実施形態における機能構成を示す機能ブロック図である。
【図２】配信サーバにおいて準備される多視点映像ストリームデータの一実施形態を示す模式図である。
【図３】ＤＡＳＨによるＨＴＴＰクライアントとＨＴＴＰサーバとの通信の概略を示すシーケンス図である。
【図４】従来のセグメントファイルの配信形態を概略的に示した模式図である。
【図５】スマートフォン（クライアント）におけるユーザによって選択される視点の位置関係を説明するための模式図である。
【図６】本発明によるセグメントファイルの配信制御の一実施形態を概略的に示した模式図である。
【図７】本発明による受信遅延に対応するセグメントファイル配信制御の実施形態を概略的に示した模式図である。
【発明を実施するための形態】
【００２９】
以下、本発明の実施形態について、図面を用いて詳細に説明する。
【００３０】
図１は、本発明によるクライアントの一実施形態における機能構成を示す機能ブロック図である。
【００３１】
図１に示した本実施形態のスマートフォン１は、配信サーバ２に対し、通信ネットワークを介して大容量の送信データの送信要求を行い、当該送信データを受信して処理するクライアント（端末）である。
【００３２】
具体的には、本実施形態において、配信サーバ２の保存する送信データは、「多視点映像ストリームデータ」であって複数のセグメントに分割されており、各セグメントについて複数種のセグメントファイルが準備されている。本実施形態では、この複数種のセグメントファイルは、互いに視点の異なる複数の映像データである。スマートフォン１は、このような互いに視点の異なる（多視点の）複数のセグメントファイルを取得（受信）して合成し自由視点映像を生成するのである。
【００３３】
また、本実施形態において、「多視点映像ストリームデータ」は、多視点映像のＨＴＴＰ（HyperText Transfer Protocol）型ストリーミング方式に基づいて送受信され、そのプロトコルとしては具体的にＤＡＳＨ（Dynamic Adaptive Streaming over Hyper transfer protocol）が使用される。また、ＨＴＴＰサーバである配信サーバ２は、予め作成された映像コンテンツとしての「多視点映像ストリームデータ」を、ＶｏＤ（Video on Demand）型配信方式を用いて配信する。なお当然に、「多視点映像ストリームデータ」の配信方式及び採用可能なプロトコルは、以上に述べたものに限定されるものではない。
【００３４】
このように、「多視点映像ストリームデータ」は、配信サーバ２において、セグメントに分割された映像コンテンツを視点数分（多視点分）だけ予め用意しておく必要があり、また、各視点の映像ストリームは、高解像度化によって通常、ビットレート（品質）も非常に大きいものとなっている。したがって、通信ネットワークの通信状況によっては、スマートフォン１で映像再生処理を滞りなく実施するべく、「多視点映像ストリームデータ」の配信に相当の工夫・配慮が必要となってくるのである。
【００３５】
同じく図１において、スマートフォン１は、その顕著な特徴として、
（Ａ１）配信サーバ２から１つのセグメント分を受信するにあたり、この１つのセグメント分として準備された複数種のセグメントファイル（本実施形態では、互いに視点の異なる複数の映像データ）のうちの１つ又は一部を取得する要求（本実施形態ではHTTP Request）を、配信サーバ２宛てに送信させ、
（Ａ２）次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求（HTTP Request）を、配信サーバ２宛てに送信させ、
（Ｂ）受信された１つのセグメント分のセグメントファイルの処理、本実施形態では映像再生処理、を実行する。
【００３６】
このように、スマートフォン１は、１つのセグメント分を受信するにあたり、１つの要求（HTTP Request）によって、取得すべき各視点のセグメントファイルの全てを取得するのではなく、そのうちの１つ又は一部を取得する。したがって、例えばこの要求後において、通信ネットワークの通信状況の変化が発生した際、この変化に対応して残りのセグメントファイルの要求の内容を調整することが可能となる。言い換えると、特に上記構成（Ａ１）及び（Ａ２）を適用することにより、通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施することができるのである。
【００３７】
さらに、本実施形態の配信サーバ２には、互いに視点の異なる複数種の（多視点の）セグメントファイルの各々について、互いにビットレート（品質）の異なる複数段階のセグメントファイルが準備されている。ここで、スマートフォン１は、１つのセグメント分を受信するにあたり、１つの要求（HTTP Request）の結果として受信されたあるビットレートのセグメントファイルの受信の具合、例えば（使用している通信ネットワークの）スループットに基づいて、次に又は以後取得を要求するセグメントファイルのビットレートを決定し、この決定されたセグメントファイルを要求することができる。
【００３８】
この点、従来技術では、全視点のセグメントファイルが受信完了するまでは、各視点のセグメントファイルにおけるビットレートの配分を変更することができなかった。その結果、例えば、スループットが頻繁に変動する状況においても、各視点のセグメントファイル毎の動的な配信制御によって対応することはできず、再生停止が発生しやすくなるという問題が生じていた。
【００３９】
これに対し、本実施形態のスマートフォン１は、そのようなスループットが頻繁に変動する状況であっても、全視点のセグメントファイルの受信完了までの間に適宜、通信状況に適したビットレートのセグメントファイルを選択し直して要求し、再生停止を抑制することが可能となる。
【００４０】
ちなみに、このような受信遅延によるクライアント側での処理の停止・中断の問題は、以上に例示した多視点映像ストリームのケースに限定されるものではない。例えば、複数のセグメントに分割された大容量の送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対し、データ要求を行うクライアントであれば、同様の問題が現実に生じている。本発明のクライアントによれば、そのような送信データに係る処理の停止・中断の問題を解決することができるのである。
【００４１】
［装置の機能構成］
同じく、図１に示した機能ブロック図によれば、本発明のクライアントであるスマートフォン１は、通信インタフェース部１０１と、タッチパネルディスプレイ（ＴＰ・ＤＰ）１０２と、プロセッサ・メモリとを有する。ここで、プロセッサ・メモリは、スマートフォン１のコンピュータを機能させるプログラムを実行することによって、本発明によるクライアント制御方法の一実施形態であるデータ要求、受信及び処理機能を実現させる。
【００４２】
さらに、このプロセッサ・メモリは、機能構成部として、要求視点決定部１１１ａ、要求ビットレート決定部１１１ｂ及び要求タイミング決定部１１１ｃを含むデータ要求部１１１と、スループット算出部１１２ａ及び受信遅延判定部１１２ｂを含む通信管理部１１２と、視点位置検出部１１３ａ、自由視点合成部１１３ｂ、メディアエンジン１１３ｃ及び受信履歴記録部１１３ｄを含むデータ処理部１１３とを有する。ここで、図１におけるスマートフォン１の機能構成部間を矢印で接続して示した処理の流れは、本発明によるクライアント制御方法の一実施形態としても理解される。
【００４３】
通信インタフェース部１０１は、
（ａ）後に詳述するデータ要求部１１１で生成されたHTTP Request（セグメント要求）を、事業者通信網やインターネット等の無線又は有線の通信ネットワークを介して配信サーバ２宛てに送信する。また、
（ｂ）配信サーバ２から、HTTP Requestへの応答として、要求した視点及びビットレートのセグメントファイルを受信する。
【００４４】
また、通信インタフェース部１０１は、
（ｃ）後に詳述するデータ処理部１１３での処理結果、例えば合成された自由視点映像データ、を外部の情報処理装置宛てに送信してもよく、
（ｄ）外部のサーバから、本発明によるクライアント制御プログラム（アプリ）をダウンロードしてもよい。
【００４５】
図２は、配信サーバ２において準備される多視点映像ストリームデータの一実施形態を示す模式図である。
【００４６】
図２において、配信サーバ２は、配信用として保存・管理する多視点映像ストリームデータを準備するため、最初に、設定された複数の視点（図２では５つの視点Ａ〜Ｅ）の各々についての映像データを含む１つの多視点映像コンテンツにおいて、例えば圧縮符号化等の公知技術を用いて、視点毎に、互いにビットレートの異なる複数段階の映像データを用意する。ちなみに、ビットレートとは、対象の（映像）データの品質を表す数値（単位は例えばbps(bits/sec)）であり、例えば１秒間にどれだけの（映像）情報を詰め込んでいるかの程度を示す値となっている。
【００４７】
次いで、複数の視点（５つの視点Ａ〜Ｅ）の各々について、各ビットレートの映像データを、時間軸上で複数のセグメントに分割する。ここで、１つの映像データを構成する複数のセグメントは、再生の順番である再生時間１、２、３、・・・に対応している。また、１つのセグメントは、例えば数〜１０秒程度の再生時間長を有するものとすることができる。さらに、１つの映像データを構成するセグメントの再生時間長は、特にＶｏＤ配信の場合、一定値に設定されることが好ましい。
【００４８】
以上に述べた準備処理によって、図２に示すように、多視点映像ストリームデータは、各視点について、再生時間毎に、互いにビットレートの異なる複数の（図２では４つの）セグメントファイルが用意されたデータセットとして保存・管理される。図２では、セグメントファイルを示す矩形の相対的な高さ（高さ方向の幅）が、ビットレートの高低（段階）を表している。また、例えば、視点「Ａ」の映像データにおける再生時間「１」のセグメントファイルには、「Ａ１」との記号が付され他と区別されている。
【００４９】
ちなみに、配信サーバ２で準備可能な送信データは当然に、多視点映像ストリームデータに限定されるものではない。例えば、複数の録音点での録音によって生成された多聴点音声ストリームデータ等を取り扱うこともできる。この場合、音声データのセグメントについて複数のビットレートのものが準備されてもよい。また、多視点映像ストリームデータにしても、多聴点ではない通常の音声データを含むものであってもよく、この音声データのセグメントについて複数のビットレートのものが準備されてもよい。さらに、多聴点音声ストリームデータを含む多視点映像ストリームデータとすることもできる。この場合、映像データ及び音声データのそれぞれについて、図２に示すような構成を準備しておくことが可能である。
【００５０】
以上に説明したような配信サーバ２で準備された多視点映像ストリームデータを取得するため、スマートフォン１（の通信インタフェース部１０１）は、本実施形態においてＤＡＳＨに基づき、配信サーバ２との間で送受信を実施する。
【００５１】
図３は、ＤＡＳＨによるＨＴＴＰクライアントとＨＴＴＰサーバとの通信の概略を示すシーケンス図である。
【００５２】
（Ｓ１０１）ＨＴＴＰクライアントは、ＨＴＴＰサーバに対し、映像メタデータが記述されたＭＰＤ（Media Presentation Description）ファイルを要求する。
（Ｓ１０２）ＨＴＴＰサーバは、予め生成しておいたＭＰＤファイルを、要求元のＨＴＴＰクライアントに送信する。
【００５３】
（Ｓ１０３）ＨＴＴＰクライアントは、ＨＴＴＰサーバに対し、予め設定されていたビットレートを有する再生時間１のセグメントファイルの要求（HTTP Request）を行う。
（Ｓ１０４）ＨＴＴＰサーバは、ステップＳ１０３の要求に応答し、再生時間１のセグメントファイルを、要求元のＨＴＴＰクライアントに送信する。
【００５４】
（Ｓ１０５）ＨＴＴＰクライアントは、ステップＳ１０４によって受信されたセグメントファイルのサイズと、要求時刻から見て全ての（全視点の）セグメントファイルを受信するのに要した時間とに基づいて、使用しているネットワークのスループットを算出する。次いで、ステップＳ１０２によって受信されたＭＰＤファイルに記載された、要求可能なセグメントファイルのビットレートの種類（段階）と、算出したスループットとを比較して、次に要求するセグメントファイルのビットレートを決定する。
【００５５】
ここで、例として、ビットレートとして5Mbps、2Mbps、1Mbps、・・・が要求可能である場合に、スループットが2.5Mbpsと算定された際、次に要求するセグメントファイルのビットレートを、スループットを上回らない最大値として2Mbpsに決定することができる。
【００５６】
（Ｓ１０６）ＨＴＴＰクライアントは、受信した再生時間１のセグメントファイルをメディアエンジンに渡し、メディアエンジンは、（バッファが１セグメント分の長さに設定されている場合、）同セグメントファイルの再生を開始する。
【００５７】
（Ｓ１０７）ＨＴＴＰクライアントは、ＨＴＴＰサーバに対し、ステップＳ１０５で決定したビットレートを有する再生時間２のセグメントファイルの要求（HTTP Request）を行う。
（Ｓ１０８）ＨＴＴＰサーバは、ステップＳ１０７の要求に応答し、再生時間２のセグメントファイルを、要求元のＨＴＴＰクライアントに送信する。
【００５８】
これ以降、ＨＴＴＰクライアントとＨＴＴＰサーバとは、Ｓ１０５〜Ｓ１０８と同様の手順を繰り返し、順次再生時間３以降のセグメントファイルの要求、送受信及び再生を実施していく。なお、通常、ＨＴＴＰクライアントによる要求（HTTP Request）は、１セグメント（に含まれるメディア）分の再生時間長（例えば数〜１０秒程度）の経過毎に、周期的に行われることになる。
【００５９】
図４は、従来のセグメントファイルの配信形態を概略的に示した模式図である。
【００６０】
図４において、ＨＴＴＰクライアントは、再生時間１のセグメントファイルA1、B1、C1、D1及びE1を要求するHTTP Requestを行うタイミングで、直近のスループットを参考にして（又は予めの設定に従って）利用できるビットレート量の基準を決定し、さらに、予め設定された各視点へのビットレート配分の分布に基づいて、各視点のセグメントファイルのビットレートを決定する。
【００６１】
次いで、決定されたビットレートのセグメントファイルの要求を受けたＨＴＴＰサーバは、該当する全視点分のセグメントファイルA1、B1、C1、D1及びE1を多重化し、１つのファイルとしてＨＴＴＰクライアント宛てに配信する。ＨＴＴＰクライアントは、この再生時間１の全視点分の1ファイルを、再生時間１の開始時刻までに受信し、受信完了後、この再生処理を行うとともに、次の再生時間２のセグメントファイルA2、B2、C2、D2及びE2を要求するHTTP Requestを行う。
【００６２】
このように、従来のセグメントファイルの配信では、１つのHTTP Requestをもって全視点のセグメントファイルの取得を要求するので、結果として、実質的に全視点分のセグメントファイルの受信が完了するまで、注視点のセグメントファイルの再生を他の受信を待たずに開始したり、各視点のビットレート配分をダウンロードの途中で変更したりすることは不可能であった。
【００６３】
ここで、この従来のセグメント要求時におけるビットレートの決定処理、具体的には、各視点のセグメントファイルに対するビットレート配分の方法について説明する。最初に、時刻tにおける全ての視点のセグメントファイルの合計ビットレートをb(t)とする。このb(t)は、（ＭＰＤファイルに記述された）複数のビットレート候補の中から、直近のスループットを越えない且つ最も高いビットレートを選択することにより決定される。
【００６４】
合計ビットレートb(t)が決定されると、次いで、予め設定された視点間の選択確率分布p(xi|xi-1)に基づいて、各視点へビットレートを配分する。この確率分布p(xi|xi-1)としては、例えば、xi＝xi-1の場合に最大値をとる正規分布とすることができる。この確率分布を用いると、視点xiの時刻tにおけるビットレートbi(t)は、直前に選択された視点をxi-1として、次式
（１）  bi(t)＝p(xi|xi-1)＊b(t)
によって決定することができる。なお、直近のスループットは、前の再生時間の全視点分のセグメントファイルの合計サイズと、ダウンロードに要した全時間とから算出される。
【００６５】
このように、ネットワークの通信状況に応じて決定した合計ビットレートb(t)を、要求すべき各視点に配分することによって、できるだけ高い品質のセグメントファイルを要求するのである。
【００６６】
次に、本発明によるセグメントファイル配信制御の一実施形態を説明する。スマートフォン１のデータ要求部１１１（図１）がこの配信制御の役割を担う。このデータ要求部１１１は、１つのセグメント分を受信するにあたり、
（ａ）この１つのセグメント分として準備された多視点の（複数種の）セグメントファイルのうちの１つ又は一部を取得する要求（HTTP Request）を、配信サーバ２宛てに送信させ、
（ｂ）次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求（HTTP Request）を、配信サーバ２宛てに送信させる。
【００６７】
ちなみに本実施形態において、データ要求部１１１は、要求（HTTP Request）におけるセグメントファイルの視点を決定する要求視点決定部１１１ａと、要求（HTTP Request）におけるセグメントファイルのビットレートを決定する要求ビットレート決定部１１１ｂと、要求（HTTP Request）のタイミングを決定する要求タイミング決定部１１１ｃとを有する。最初に、このデータ要求部１１１（要求視点決定部１１１ａ）における要求する視点（の順序）の決定について説明する。
【００６８】
図５は、スマートフォン１におけるユーザによって選択される視点の位置関係を説明するための模式図である。
【００６９】
図５には、撮影対象を中心とした当該撮影対象に対する視点Ａ、視点Ｂ、・・・、視点Ｅの位置関係が示されている。各視点は、撮影対象から見た方向角θ（0°≦θ＜360°）で表される視点位置について所定の範囲を占めている。例えば図６の例では、視点Ｂは、視点位置の範囲として36°〜108°の範囲を仮想的にカバーする視点となっている。例えば、視点位置60°はこの視点Ｂに属することになる。
【００７０】
ユーザは、タッチパネルディスプレイ１０２（図１）に表示された視点操作用画像に対する操作や、又はそのような表示に関わらない（暗黙の）操作等によって、自らが見たいと思う視点位置（又は視点）を指定する。ここで指定された（視点位置に係る）視点が注視点となる。ここで、ユーザは、随時にしかも連続的に、指定する視点位置を変更することが可能であってもよい。
【００７１】
視点位置検出部１１３ａ（図１）は、常時、ユーザによる視点指示操作を監視し、ユーザによる注視点の指示を受けて、当該指示内容をデータ要求部１１１（要求視点決定部１１１ａ）（図１）に出力する。ここで、この要求視点決定部１１１ａは、入力した当該指示内容を受けて、設定された視点（例えば５つの視点Ａ〜Ｅ）のうちから注視点を決定し、さらにこれらの視点のセグメントファイルにおける、要求する順序（優先度）を決定する。これにより、クライアントにおける視点移動（ユーザによる視点選択）に対応した配信制御を実施することが可能となるのである。
【００７２】
ちなみに、要求視点決定部１１１ａ（図１）は、受け付けた指示のみならず、例えば予め決められた事項に基づいて、取得すべき多視点の（複数種の）セグメントファイルに優先度を設定し、優先度のより高いセグメントファイル（優先度の最も高い注視点のセグメントファイル）を取得する要求を、より優先して（最優先で）送信させることも好ましい。
【００７３】
図６は、本発明によるセグメントファイルの配信制御の一実施形態を概略的に示した模式図である。
【００７４】
図６（Ａ）によれば、スマートフォン１（データ要求部１１１）は、再生時間１の１つのセグメント分を受信するにあたり、計５回のHTTP Requestを行っている。具体的には、最初に、最もビットレートの高い注視点のセグメントファイルC1の取得を要求するHTTP Requestを行い、次いで、この注視点に隣接する（注視点に最も近い）セグメントファイルB1及びD1の一方（図６（Ａ）ではB1）を要求するHTTP Requestを行い、その後、他方（図６（Ａ）ではD1）を要求するHTTP Requestを行っている。これらのセグメントファイルB1及びD1のビットレートは、本実施形態において２番目に高い値に決定される。
【００７５】
ここで、セグメントファイルB1及びD1は要求について順不同であるが、上述した視点位置を考慮し、視点位置（角度値）から見てより近い視点を先に要求することも好ましい。例えば、カバーする視点位置範囲の中心となる視点位置（角度値）が、注視点の中心となる視点位置（角度値）により近い方の視点を、優先して要求してもよい。
【００７６】
その後、注視点から最も離隔した（２番目に注視点に近い）セグメントファイルA1及びE1の一方（図６（Ａ）ではA1）を要求するHTTP Requestを行い、次いで他方（図６（Ａ）ではE1）を要求するHTTP Requestを行っている。これらのセグメントファイルA1及びE1のビットレートは、本実施形態において最も低い（３番目に高い）値に決定される。ちなみに、通信状況等によっては（選択される可能性の低い）これらのセグメントファイルA1及びE1は要求しない、という配信形態も可能である。
【００７７】
なお、本実施形態において、データ要求部１１１（要求ビットレート決定部１１１ｂ）は、１つのセグメント分を受信するにあたって取得すべき各セグメントファイルにつき、いずれのビットレート（段階）のセグメントファイルを選択するかを、設定事項又はユーザから受け付けた指示に基づいて予め決定しておくことができる。この場合、上述した従来のセグメント要求時における、選択確率分布p(xi|xi-1)を用いたビットレートの分配処理を採用することも可能である。
【００７８】
このような分配処理を行うことによって、データ要求部１１１（要求ビットレート決定部１１１ｂ）は、ユーザから受け付けた指示（又は予め決められた事項）に基づいて、当該次のセグメント分を受信するにあたって取得すべき全ての視点のセグメントファイルの各々に対し選択すべきビットレートを割り当てたビットレート分布を決定することができる。また、この分布において、注視点のセグメントファイルは、取得すべき全視点のセグメントファイルのうちで最もビットレートの高いセグメントファイルとなることも好ましい。
【００７９】
以上説明したように、本実施形態では、１つのセグメント分を受信するにあたり、各視点のセグメントファイルを個別に要求し、その際、ユーザに指定された（又は予め設定された）注視点を考慮して、この注視点を最初に要求し、次いでこの注視点から近い順に（注視点により近い視点を優先して）要求を行っている。
【００８０】
これにより、例えば、従来各視点のビットレートをダウンロードの途中で変更することはできなかったのに対し、スマートフォン１では、次に図６（Ｂ）を用いて説明するように、その変更が可能となるのである。また、全視点分のセグメントファイルの受信が完了する前であっても、必要ならば、注視点のセグメントファイルの再生を開始することも可能となる。
【００８１】
ここで、基本的に、スマートフォン１のデータ要求部１１１は、再生時点までの時間、注視点、使用している通信ネットワークのスループット等に基づいて、要求する視点別セグメントファイルの要求順序、及び各視点へのビットレートの配分、さらには要求を行うタイミングを決定することができる。ここで、スループットは、通信管理部１１２のスループット算出部１１２ａ（図１）によって算出される。このスループット算出部１１２ａは、例えば要求（HTTP Request）を行って１つのセグメントファイルを受信する毎に、その時点でのスループットを算出することができる。
【００８２】
なお、各視点についての要求（HTTP Request）のタイミングは、図６（Ａ）の実施形態では、１つ前の要求済みの視点のセグメントファイルが受信された直後となっているが、当然にこれに限定されるものではない。例えばこの受信を見越してこの受信の完了前に次の視点についての要求（HTTP Request）を行うことも可能である。また、１つのセグメントファイルを受信し、この受信に基づいてスループットを算出して次のビットレートを決定した直後に、要求（HTTP Request）を行ってもよい。
【００８３】
次に、通信ネットワークのスループットが急激に変動した場合における、スマートフォン１によるビットレートの動的変更処理の一実施形態について説明する。
【００８４】
図６（Ｂ）によれば、再生時間１のセグメントファイルの要求時、具体的には２回目のHTTP Request送信の直後に、使用中の通信ネットワークのスループットが急激に低下している。この場合、要求ビットレート決定部１１１ｂ（データ要求部１１１）は、先に要求した視点のセグメントファイル（図６（Ｂ）ではB1）のダウンロード結果に基づき、次に要求する視点のセグメントファイル（図６（Ｂ）ではD1）のビットレートを決定する。
【００８５】
例えば、セグメントファイルB1のデータサイズとダウンロードに要した時間とからスループットを算出し、このスループットが、1つ前のセグメントファイルC1をダウンロードした際の（同様に算出された）スループットに比べて、又は予め設定された基準に比べて、所定以上に低下しているか否かを判定する。スループットが所定以上低下していると判定した場合、次に要求する視点のセグメントファイルD1のビットレートを、より小さいものに動的に変更することができる。また、さらにその後に要求するセグメントファイルA1やセグメントファイルE1のビットレートを変更してもよい。
【００８６】
ここで、各視点へのビットレートの配分変更方法について説明する。図６（Ｂ）の実施形態において、セグメントファイルB1のダウンロードが完了した時刻t'における、以後要求すべき全ての視点における合計ビットレートをb'(t')とする。また、時刻t'における直近に計測したスループットをTPとし、再生時間時間１のセグメントファイルの再生開始時刻までの残り時間をΔtとし、１つのセグメントファイルの再生時間長をlとすると、b'(t')は、次の条件式
（２）  b'(t')＊l ＜ TP＊Δt
を満たす最大値に決定することができる。または、上式（２）を満たす、予め設定された合計ビットレート候補値の中から選択して決定してもよい。ここで、直近のスループットTPは、時刻t'以前に受信されたセグメントファイルの各受信時に算出されたスループット値の重み付き平均（例えば、直前に算出したスループットの重みをより大きくした平均）によって算定されることも好ましい。また、上式（２）の再生時間長lは、例えばＭＰＤファイルに記述されている値を採用することができる。
【００８７】
次いで、b'(t')が決定されると、視点間の選択確率分布p(xi|xi-1)に基づいて、各視点へビットレートを配分する。この確率分布p(xi|xi-1)としても、例えばxi＝xi-1の場合に最大値をとる正規分布とすることができる。この確率分布を用いると、視点xiの時刻t'におけるビットレートbi'(t')は、直前に選択された視点をxi-1として、次式
（３）  bi'(t')＝p(xi|xi-1)＊b'(t')
によって決定することができる。
【００８８】
なお、視点間の選択確率分布p(xi|xi-1)は、時刻t'までの視点選択の状況を反映して更新されてもよい。具体的には、例えばユーザによる視点の選択（注視点の決定）の履歴を記録して、時刻t'を終時点とする所定時間区間における各視点の選択率を算出しておき、この選択率のより高い視点ほどより高い確率値となるように選択確率分布p(xi|xi-1)を更新することができる。
【００８９】
いずれにしても、データ要求部１１１（要求ビットレート決定部１１１ｂ）は、１つのセグメント分を受信するにあたり、１つの要求（HTTP Request）の結果として受信された（あるビットレートの）セグメントファイルの受信の具合、例えば当該受信の際に算出されたスループットに基づいて、次に又は以後取得を要求するセグメントファイルのビットレートを決定することができるのである。
【００９０】
次に、本発明の他の実施形態として、受信遅延に対応するセグメントファイル配信制御について説明する。
【００９１】
図１に戻って、通信管理部１１２の受信遅延判定部１１２ｂは、１つのセグメント分の受信が、少なくとも、次に受信すべき次のセグメント分の受信の開始までに完了するか否か、すなわち受信遅延が発生するか否かを判定する。データ要求部１１１は、１つのセグメント分を受信するにあたり、この受信遅延判定部１１２ｂでの判定結果に基づき、以後行う各要求（HTTP Request）において、取得を要求するセグメントファイルの数を決定するのである。
【００９２】
図７は、本発明による受信遅延に対応するセグメントファイル配信制御の実施形態を概略的に示した模式図である。
【００９３】
図７（Ａ）によれば、スマートフォン１（データ要求部１１１）は、再生時間１の１つのセグメント分を受信するにあたり、最初に、最もビットレートの高い注視点のセグメントファイルC1の取得を要求するHTTP Requestを行い、このセグメントファイルC1の受信を完了している。次いで、受信遅延判定部１１２ｂ（図１）が現時点について行った受信遅延判定結果を参照することによって、「以後、４回のHTTP Requestを行って残りの４つの視点のセグメントファイルB1、D1、A1及びE1を個別に受信したとすると、当該受信の完了が次の再生開始に間に合わない」と判断する。
【００９４】
そこで、スマートフォン１（データ要求部１１１）は、図７（Ｂ）に示すように、１つのHTTP Requestによって複数の（同図では２つの）セグメントファイルを要求し、これらのファイルのパラレル受信を行う。これにより、受信遅延が回避され、映像の再生処理が途切れることなく良好に実施される。ここで、パラレル受信の要求は、例えば、HTTP/2のServer PUSH送信機能等を利用して実施することができる。具体的には、例えば図７（Ｂ）に示した（２回目の要求である）B1を要求するHTTP Requestにおいて、GETのヘッダにプッシュ対象のセグメントファイルD1を指定し、配信サーバ２によるD1のプッシュ送信の指示を含めてもよい。
【００９５】
ここで、受信遅延判定部１１２ｂによる受信遅延判定を説明する。受信遅延判定部１１２ｂは、直近に（例えばセグメントファイルC1の要求・受信によって）計測されたラウンドトリップタイム（Round Trip Time）RTT及びスループットTP、並びに以後受信すべきセグメントファイルグループの数n、及び以後受信すべきセグメントファイルの合計サイズSを用いた次式
（４）  S／TP＋(RTT／2)＊n ＞ Δt
が成立する場合、受信遅延が発生するとの判定を行う。ここで、Δtは、次の再生時間（今回受信すべきセグメントファイルの再生時間）である再生時間２の開始時刻までの残り時間である。また、nは（「以後送信するHTTP Requestの数」−1）に相当する。結局、上式（４）は、現時点から見て受信完了に必要な時間が、このΔtを超えてしまう場合の条件式となっている。
【００９６】
ちなみに、上記の受信遅延は、HTTP Request数の増加に伴うトータルのRTTの増大によって発生する。そこで、受信遅延が発生するとの判定結果を受けたデータ要求部１１１は、１つのHTTP Requestで複数のセグメントファイルを要求し、発信するHTTP Request数を減らすことによって予想される受信遅延を回避する。この際、データ要求部１１１は、１つのHTTP Requestで要求するセグメントファイルの個数が２、３、・・・である場合の受信遅延の有無を受信遅延判定部１１２ｂに判定させ、上式（４）を満たす最小の個数を決定することも好ましい。このように、１つのHTTP Requestで要求するセグメントファイルの個数をできるだけ小さくすることによって、１つのセグメント分の受信の途中で、受信すべき視点分のビットレートを見直す時間的余地がより多く確保されるのである。
【００９７】
ここで勿論、受信遅延が回避されるならば、各HTTP Requestで要求するセグメントファイルの個数は一定ではなく、とりあえず２つを要求した後、例えばその際の通信状況に合わせて、１つのHTTP Requestで１つのセグメントファイルを要求したり、あるいは３つ以上のセグメントファイルを要求したりすることも可能である。また、最初のHTTP Requestで注視点のセグメントファイルを要求した後、通信状況によっては、残りの全てのセグメントをまとめて要求し、全視点分を確実に受信することもできる。
【００９８】
次に、具体的に、図７（Ａ）に示した配信形態と、図７（Ｂ）の配信形態とにおける受信遅延発生の有無の様子を説明する。具体例として、1セグメントの時間長は10秒であって、RTT／2は1秒であるとする。最初に、図７（Ａ）の配信形態では、
＜ダウンロード（予測）時間＞  ＜RTT/2＞
セグメントファイルC1：  2秒                          1秒
セグメントファイルB1：  1.5秒                        1秒
セグメントファイルD1：  1.5秒                        1秒
セグメントファイルA1：  0.5秒                        1秒
セグメントファイルE1：  0.5秒                        1秒
となり、現時点から見て受信完了に必要な時間は、合計して11秒となる。これは、1セグメントの時間長（10秒）を超える値であり、結果として受信遅延が発生すると判定される。
【００９９】
一方、図７（Ｂ）の配信形態では、
＜ダウンロード（予測）時間＞  ＜RTT/2＞
セグメントファイルC1：  2秒                          1秒
ファイルB1及びD1：  1.5秒＋1.5秒                 1秒
ファイルA1及びE1：  0.5秒＋0.5秒                 1秒
となり、現時点から見て受信完了に必要な時間は、合計して9秒となる。これは、1セグメントの時間長（10秒）内に収まる値であり、結果として受信遅延は発生しないと判定される。
【０１００】
なお、図６及び図７を用いて説明した本発明によるセグメント配信制御の実施形態においては、送信データは多視点映像ストリームデータであり、複数種のセグメントファイルは、互いに視点の異なる映像セグメントファイルであって、複数段階のセグメントファイルは、互いにビットレート、すなわち画質の異なる映像セグメントファイルである。ただし、変更態様として、送信データを多聴点音声ストリームデータとし、複数種のセグメントファイルを、互いに聴点の異なる音声セグメントファイルとして、さらに、複数段階のセグメントファイルを、互いにビットレート、すなわち音質の異なる音声セグメントファイルとしてもよい。さらには、送信データとして、上記の多視点映像ストリームデータと多聴点音声ストリームデータとを合わせたストリームデータを採用することも可能である。
【０１０１】
いずれにしても、図６及び図７を用いて以上に説明したような本発明によるセグメント配信制御の実施形態では、多視点及び／又は多聴点のストリーム配信において、各視点及び／又は各聴点のセグメントファイルを個別に要求し、さらに、下記の（ａ）〜（ｃ）のように動的に配信制御を行っている。
（ａ）注視点及び／又は注聴点のセグメント、さらには注視点及び／又は注聴点に近い視点及び／又は聴点のセグメントから順序立てて要求する。
（ｂ）先に要求した視点及び／又は聴点のダウンロード結果に基づき、後に要求する視点及び／又は聴点のビットレート配分と要求タイミングとを動的に決定する。
（ｃ）複数のHTTP Request発信におけるオーバーヘッドによる受信遅延がないことを確認し、受信遅延が見込まれる場合、１つのHTTP Requestによって複数視点及び／又は複数聴点のセグメントファイルのパラレル受信を行う。
【０１０２】
これにより、スループットが変動しやすい状況においても、セグメントファイルのビットレートを動的に変更可能となるので、結果として、再生が停止する頻度を低減したり、または再生画質を向上させたりすることができる。
【０１０３】
図１に戻って、データ処理部１１３は、自由視点合成部１１３ｂ及びメディアエンジン１１３ｃを有し、以上に説明したように配信サーバ２から受信された各セグメント分のセグメントファイルの処理を実行する。具体的に、自由視点合成部１１３ｂは、受信された各視点のセグメントファイルを合成して自由視点映像を生成し、例えばスマートフォン１に搭載されたアプリ（アプリケーション・プログラム）に出力して、当該アプリに当該自由視点映像を利用させてもよい。
【０１０４】
また、メディアエンジン１１３ｃは、受信された各視点のセグメントファイルを処理し、タッチパネルディスプレイ１０２に注視点の映像を表示させたり、ユーザの視点選択指示を視点位置検出部１１３ａから入力した際、選択された視点の映像をタッチパネルディスプレイ１０２に表示させたりすることも好ましい。ちなみに、スマートフォン１では、従来と異なり、とりあえず注視点のセグメントファイルを受信すれば、他の視点のセグメントファイルの受信完了を待たずに、メディアエンジン１１３ｃがこの注視点の再生を実施することも可能となる。
【０１０５】
以上、詳細に説明したように、本発明によれば、１つのセグメント分を受信するにあたり、１つの要求によって、取得すべき各視点のセグメントファイルの全てを取得するのではなく、そのうちの１つ又は一部を取得する。したがって、使用する通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施することができるのである。
【０１０６】
以上に述べた本発明の種々の実施形態について、本発明の技術思想及び見地の範囲内での種々の変更、修正及び省略は、当業者によれば容易に行うことができる。以上に述べた説明はあくまで例示であって、何ら制約を意図するものではない。本発明は、特許請求の範囲及びその均等物によってのみ制約される。
【符号の説明】
【０１０７】
１  スマートフォン（クライアント）
１０１  通信インタフェース部
１０２  タッチパネルディスプレイ（ＴＰ・ＤＰ）
１１１  データ要求部
１１１ａ  要求視点決定部
１１１ｂ  要求ビットレート決定部
１１１ｃ  要求タイミング決定部
１１２  通信管理部
１１２ａ  スループット算出部
１１２ｂ  受信遅延判定部
１１３  データ処理部
１１３ａ  視点位置検出部
１１３ｂ  自由視点合成部
１１３ｃ  メディアエンジン
１１３ｄ  受信履歴記録部
２  配信サーバ
【図１】
2018125621.tif 000003
【図２】
2018125621.tif 000004
【図３】
2018125621.tif 000005
【図４】
2018125621.tif 000006
【図５】
2018125621.tif 000007
【図６】
2018125621.tif 000008
【図７】
2018125621.tif 000009