(57)【要約】【課題】ビルボード等の映像対象における画質を制御し、当該画質に起因する視認品質の低下を抑制可能なクライアントを提供する。【解決手段】本クライアントは、複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータをサーバから受信する。ここで、１つ又は複数のセグメント分を受信するにあたり、映像対象（ビルボード）に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定したセグメントファイルを取得する要求を、このサーバ宛てに送信する。また、受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行する。なお、画像領域の画質に係る情報として、セグメントファイルでの画像領域について算出された信号対雑音比を採用可能である。【選択図】図１
2018160805.tif 000002
【特許請求の範囲】
【請求項１】
複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントであって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有することを特徴とするクライアント。
【請求項２】
当該映像ストリームデータは、各セグメントについて互いに視点の異なる複数種の、さらには当該複数種の各々について互いにデータ量の異なる複数段階のセグメントファイルが準備されているデータであり、
前記データ要求手段は、当該多視点対象に対応する画像領域の画質に係る情報に基づいて、各視点についていずれの段階のセグメントファイルを取得するかを決定する
ことを特徴とする請求項１に記載のクライアント。
【請求項３】
前記データ要求手段は、各視点における各段階のセグメントファイルでの当該画像領域について算出された信号対雑音比の増分、又は当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大若しくは所定以上となるように、各視点のセグメントファイルの段階を決定することを特徴とする請求項２に記載のクライアント。
【請求項４】
前記データ要求手段は、設定された視点選択確率分布の値が高い視点ほど、該視点に対しより大きな重みを割り当て、当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大又は所定以上となるように、各視点のセグメントファイルの段階を決定することを特徴とする請求項３に記載のクライアント。
【請求項５】
前記データ要求手段は、当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大又は所定以上となるように、当該視点に単位分ずつビットレート又はファイルサイズを配分し、各視点のセグメントファイルの段階であるビットレート又はファイルサイズを決定することを特徴とする請求項４に記載のクライアント。
【請求項６】
前記データ要求手段は、算出されたスループットの値から、取得する全ての視点についての合計ビットレート又は合計ファイルサイズを算出し、当該視点に単位分ずつ配分されたビットレート又はファイルサイズの合計が当該合計ビットレート又は当該合計ファイルサイズを超えないように、各視点のセグメントファイルの段階であるビットレート又はファイルサイズを決定することを特徴とする請求項５に記載のクライアント。
【請求項７】
前記データ要求手段は、いずれの視点のセグメントファイルにおける当該画像領域の信号対雑音比も所定閾値を越えないように、ビットレート又はファイルサイズを単位分ずつ配分することを特徴とする請求項５又は６に記載のクライアント。
【請求項８】
前記データ要求手段は、当該画質に係る情報に基づいて、各視点のセグメントファイルを要求する順序を決定し、当該各視点のセグメントファイルを取得する要求を、決定した当該順序によって前記サーバ宛てに送信させることを特徴とする請求項２から７のいずれか１項に記載のクライアント。
【請求項９】
複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバと、該サーバに対するクライアントとを備えたシステムであって、
前記サーバは、準備した当該セグメントファイルにおける映像対象に対応する画像領域の画質に係る情報を生成する画質情報生成手段を有し、
前記クライアントは、
１つ又は複数のセグメント分を受信するにあたり、前記サーバから取得した画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有することを特徴とするシステム。
【請求項１０】
複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントに搭載されたコンピュータを機能させるクライアント制御プログラムであって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
してコンピュータを機能させることを特徴とするクライアント制御プログラム。
【請求項１１】
複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントに搭載されたコンピュータにおけるクライアント制御方法であって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、前記サーバ宛てに送信させるステップと、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するステップと
を有することを特徴とするクライアント制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大容量のデータをサーバから取得するクライアントにおける受信制御技術に関する。
【背景技術】
【０００２】
次世代における高い臨場感を提供可能なメディアの一つとして、自由視点映像が注目されている。自由視点映像とは、対象物（ビルボード）に対する視点をユーザが任意に指定し、指定された視点からの映像を随時提供する、といったインタラクティブな視聴を可能にする映像である。
【０００３】
この自由視点映像の合成方式の一典型例として、３次元モデル上に視点毎の対象物画像を配置し、ユーザが指定した任意の仮想視点からの見え方を、これらの配置画像を用いて計算することにより描画を実施する方法が挙げられる。具体的に、この方法での合成処理は、サーバから配信された以下の情報（ａ）〜（ｃ）を含むコンテンツを取得したクライアント側で実施される。
（ａ）各視点の映像ストリーム
（ｂ）各視点に存在するビルボード情報（マスク画像，３次元の位置，大きさの情報）
（ｃ）各視点のカメラキャリブレーション情報
【０００４】
このように、自由視点映像の合成処理では、サーバ側において、各コンテンツを視点数分（多視点分）だけ予め準備しておく必要のあるのが通常である。ここで特に、上記（ａ）の映像ストリームについては高解像度化によって１視点当たりのビットレートも相当に高くなっており、インターネット経由で配信することを考えると、データ量が大きくなり過ぎるという問題が生じていた。
【０００５】
この問題に対し、例えば特許文献１では、全視点分の映像ストリームを配信しつつ、ユーザが現在指定している視点以外の映像についてはそのビットレートを下げることによって、全体のレートをできる限り低減させる技術が提案されている。
【０００６】
ちなみに、自由視点映像の配信方式としては、例えば予め作成された映像コンテンツを配信する場合、ＶｏＤ（Video on Demand）型配信が用いられることが一般的である。具体的には、ＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over Hyper transfer protocol）や、ＨＬＳ（HTTP Live Streaming）といったプロトコルが広く利用されている。このような方式では、予め映像ストリームを数〜１０秒程度の再生時間長を有するセグメントファイルに分割しておき、クライアント側がこのセグメント単位で受信及び再生開始を行うことによって、映像ストリームを受信しながら再生する擬似ストリーミングが実現される。
【０００７】
さらに、映像ストリームに異なる品質（ビットレート）のものを用意し、セグメント毎に互いに異なるビットレートのセグメントファイルを揃えておくことによって、セグメント単位でビットレートを切り替えることも可能となる。この場合、通信ネットワークの通信状況に応じ、クライアント側が要求するコンテンツの品質を変更することもできるのである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１３−１８３２０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に記載された技術のような従来技術では、自由視点映像の対象物であるビルボードの画質が考慮されていないので、ビットレートを選択して適切な配信を期したとしても、結局、全体として視認品質が低下してしまうことが問題となってきた。
【００１０】
実際、主要な配信プロトコルであるＭＰＥＧ−ＤＡＳＨやＨＬＳでは、動画エンコード時に設定されるビットレートは、サーバからクライアントに提供されるプロファイルに記載されるが、ビルボードの画質に係る情報は記載されず考慮外となっている。このように、従来の多視点のＨＴＴＰ（HyperText Transfer Protocol）ストリーミングは、注目領域であるビルボードの画質を、例えば視点間で適切に設定するといったことを何ら想定していないのである。
【００１１】
そのため、例えば、特に注視点に近い視点において、ビルボードが小さな画像領域として(情報量として少なく)映っており、それ以上ビットレートを配分してもビルボード画質の向上に寄与しない（画質向上が視認されない）場合に、余分にビットレートを配分してしまう事態も生じ得る。さらに、ビットレートの配分によっては、隣接視点間のビルボード画質に偏りが生じて、視点切り替え時の画質低下が認知されやすくなり、その結果、全体として視認品質が低下してしまう。
【００１２】
ちなみに、このような映像の対象物の画質に係る視認品質の低下の問題は、以上に説明した多視点映像ストリームのケースに限定されるものではない。例えば、複数のセグメントファイルに分割された大容量の送信データであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている送信データを送信可能なサーバに対し、データ要求を行うクライアントであれば、同様の問題が現実に生じる。
【００１３】
そこで、本発明は、ビルボード等の映像対象における画質を制御し、当該画質に起因する視認品質の低下を抑制可能なクライアント、システム、クライアント制御プログラム及びクライアント制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明によれば、複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントであって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有するクライアントが提供される。
【００１５】
この本発明によるクライアントの一実施形態として、当該映像ストリームデータは、各セグメントについて互いに視点の異なる複数種の、さらには当該複数種の各々について互いにデータ量の異なる複数段階のセグメントファイルが準備されているデータであり、
データ要求手段は、当該多視点対象に対応する画像領域の画質に係る情報に基づいて、各視点についていずれの段階のセグメントファイルを取得するかを決定することも好ましい。
【００１６】
この上記の実施形態において、さらに、データ要求手段は、各視点における各段階のセグメントファイルでの当該画像領域について算出された信号対雑音比の増分、又は当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大若しくは所定以上となるように、各視点のセグメントファイルの段階を決定することも好ましい。
【００１７】
また、データ要求手段は、設定された視点選択確率分布の値が高い視点ほど、この視点に対しより大きな重みを割り当て、当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大又は所定以上となるように、各視点のセグメントファイルの段階を決定することも好ましい。
【００１８】
さらに、データ要求手段は、当該信号対雑音比と当該視点に割り当てられた重みとから算出される値の増分が最大又は所定以上となるように、当該視点に単位分ずつビットレート又はファイルサイズを配分し、各視点のセグメントファイルの段階であるビットレート又はファイルサイズを決定することも好ましい。
【００１９】
ここで、当該視点に単位分ずつビットレート又はファイルサイズを配分する際、データ要求手段は、算出されたスループットの値から、取得する全ての視点についての合計ビットレート又は合計ファイルサイズを算出し、当該視点に単位分ずつ配分されたビットレート又はファイルサイズの合計が当該合計ビットレート又は当該合計ファイルサイズを超えないように、各視点のセグメントファイルの段階であるビットレート又はファイルサイズを決定することも好ましい。
【００２０】
また、当該視点に単位分ずつビットレート又はファイルサイズを配分する際、データ要求手段は、いずれの視点のセグメントファイルにおける当該画像領域の信号対雑音比も所定閾値を越えないように、ビットレート又はファイルサイズを単位分ずつ配分することも好ましい。
【００２１】
さらに、本発明によるクライアントの他の実施形態として、データ要求手段は、当該画質に係る情報に基づいて、各視点のセグメントファイルを要求する順序を決定し、当該各視点のセグメントファイルを取得する要求を、決定した当該順序によってサーバ宛てに送信させることも好ましい。
【００２２】
本発明によれば、また、複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバと、このサーバに対するクライアントとを備えたシステムであって、
サーバは、準備した当該セグメントファイルにおける映像対象に対応する画像領域の画質に係る情報を生成する画質情報生成手段を有し、
クライアントは、
１つ又は複数のセグメント分を受信するにあたり、サーバから取得した画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
を有するシステムが提供される。
【００２３】
本発明によれば、さらに、複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントに搭載されたコンピュータを機能させるクライアント制御プログラムであって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、サーバ宛てに送信させるデータ要求手段と、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理手段と
してコンピュータを機能させるクライアント制御プログラムが提供される。
【００２４】
本発明によれば、さらにまた、複数のセグメントに分割された映像ストリームデータであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている映像ストリームデータを送信可能なサーバに対するクライアントに搭載されたコンピュータにおけるクライアント制御方法であって、
１つ又は複数のセグメント分を受信するにあたり、映像対象に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定した当該セグメントファイルを取得する要求を、サーバ宛てに送信させるステップと、
受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するステップと
を有するクライアント制御方法が提供される。
【発明の効果】
【００２５】
本発明のクライアント、システム、クライアント制御プログラム及びクライアント制御方法によれば、ビルボード等の映像対象における画質を制御し、当該画質に起因する視認品質の低下を抑制することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明によるクライアントを備えたデータ配信システムの一実施形態における機能構成を示す機能ブロック図である。
【図２】配信サーバにおいて準備される多視点映像ストリームデータの一実施形態を示す模式図である。
【図３】各視点のセグメントファイル内におけるビルボード画像領域を説明するための模式図である。
【図４】本発明のクライアントにおける、ビルボード画質を考慮したビットレート配分を説明するための模式図である。
【図５】ビルボード画質情報の生成についての一実施形態を説明するための模式図である。
【図６】本発明による配信制御方法の一実施形態の概略を示すシーケンス図である。
【図７】本発明のクライアントにおけるユーザによって選択される視点の位置関係を説明するための模式図である。
【図８】本発明に係るビルボード画質情報に基づいたビットレート配分決定処理の一実施形態を説明するための模式図である。
【発明を実施するための形態】
【００２７】
以下、本発明の実施形態について、図面を用いて詳細に説明する。
【００２８】
［データ配信システム］
図１は、本発明によるクライアントを備えたデータ配信システムの一実施形態における機能構成を示す機能ブロック図である。
【００２９】
図１に示した本実施形態のスマートフォン１は、配信サーバ２に対し、通信ネットワークを介して大容量の送信データの送信要求を行い、当該送信データを受信して処理するクライアント（端末）である。ここで、スマートフォン１、配信サーバ２及び両者を接続する通信ネットワークは、本発明によるデータ配信システムを構成している。
【００３０】
本実施形態において、配信サーバ２の保存する送信データは、「多視点映像ストリームデータ」であって複数のセグメントに分割されており、各セグメントについて複数種のセグメントファイルが準備されている。本実施形態では、この複数種のセグメントファイルは、互いに視点の異なる複数の映像データである。スマートフォン１は、このような互いに視点の異なる（多視点の）複数のセグメントファイルを取得（受信）して合成し自由視点映像を生成するのである。
【００３１】
さらに、本実施形態の配信サーバ２には、当該複数種の（多視点の）セグメントファイルの各々について、互いにビットレート（品質）の異なる複数段階のセグメントファイルが準備されている。ここで、スマートフォン１は、１つ又は複数のセグメント分を受信するにあたり、要求（HTTP Request）の結果として受信されたあるビットレートのセグメントファイルの受信の具合、例えば使用している通信ネットワークのスループットに基づいて、次に又は以後取得を要求するセグメントファイルの合計ビットレートを決定し、この決定に基づき、セグメントファイルを要求する。
【００３２】
また、本実施形態において、「多視点映像ストリームデータ」は、多視点映像のＨＴＴＰ型ストリーミング方式に基づいて送受信され、そのプロトコルとしては具体的にＤＡＳＨ（Dynamic Adaptive Streaming over Hyper transfer protocol）が使用される。また、ＨＴＴＰサーバである配信サーバ２は、予め作成された映像コンテンツとしての「多視点映像ストリームデータ」を、ＶｏＤ（Video on Demand）型配信方式を用いて配信する。
【００３３】
このような方式では、予め映像ストリームを数〜１０秒程度の再生時間長を有するセグメントファイルに分割しておき、クライアント側がこのセグメント単位で受信及び再生開始を行うことによって、映像ストリームを受信しながら再生する擬似ストリーミングが実現される。なお当然に、本データ配信システムにおける「多視点映像ストリームデータ」の配信方式及び採用可能なプロトコルは、以上に述べたものに限定されるものではない。
【００３４】
また、映像ストリームに異なる品質（ビットレート）のものを用意しておくことで、セグメント単位でビットレートを切り替えることができる。これによりネットワーク状況に応じてより適切な且つより高い品質のコンテンツを要求できるようになる。具体的に、スマートフォン１は、セグメント長間隔の要求時点において、直近で計測したスループットの値と、取り得るビットレート値とを比較し、このスループットを超えない範囲のビットレートを持つセグメントファイルを要求する。
【００３５】
ここで、配信サーバ２は、「多視点映像ストリームデータ」として、セグメントに分割された映像コンテンツを視点数分（多視点分）だけ予め用意しておく必要がある。また、各視点の映像ストリームのビットレート（品質）も、高解像度化によって通常、非常に高くなっている。したがって、通信ネットワークの通信状況によっては、スマートフォン１で映像再生処理を滞りなく実施するため、「多視点映像ストリームデータ」の配信に相当の工夫・配慮が必要となってくるのである。
【００３６】
また特に、再生された自由視点映像において、この映像の対象物（ビルボード）が良好に視認されるように配信が制御されなければならない。実際、ある視点に対してより多くのビットレートを配分しても、例えば当該視点におけるビルボードが小さな画像領域として(情報量として少なく)映っている場合、ビルボード画質はそれほど改善せず、結局、配分したビットレート分が生かされずに、全体として視認品質が低下してしまうことも生じ得るのである。
【００３７】
このような問題を解決すべく、スマートフォン１は、同じく図１に示すように、
（Ａ）各セグメントについて互いにデータ量の異なる複数段階の（例えば互いにビットレートの異なる）セグメントファイルが準備されている「映像ストリームデータ」を送信可能な配信サーバ２に対するクライアントであり、
（Ｂ）１つ又は複数のセグメント分を受信するにあたり、映像対象（例えばビルボード）に対応する画像領域の画質に係る情報に基づいて、いずれの段階のセグメントファイルを取得するかを決定し、決定したセグメントファイルを取得する要求を、配信サーバ２宛てに送信させるデータ要求部１１１と、
（Ｃ）受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行するデータ処理部１１３と
を有することを特徴としている。
【００３８】
このように、スマートフォン１は、要求（例えばHTTP Request）によって取得すべきセグメントファイルの段階（例えばビットレート）を、映像対象（例えばビルボード）に対応する画像領域の画質に係る情報に基づいて決定する。これにより、例えば、要求すべきセグメントファイルに対するビットレートの配分を制御し、当該配分によるビルボード画質の向上におけるコストパフォーマンスをより高めることができる。その結果、ビルボード画質に起因する視認品質の低下を抑制することが可能となるのである。
【００３９】
ここで、映像対象に対応する画像領域の画質に係る情報、例えばビルボード画質情報は、多視点映像ストリームデータを準備している配信サーバ２において、セグメントファイル毎に生成されてもよい。この変更態様として、スマートフォン１が、受信したセグメントファイル群を用いて、例えばビルボード画質情報を生成することも可能である。なお、生成されるビルボード画質情報としては、後に詳細に説明するが、例えばセグメントファイルにおけるビルボード画像領域でのＰＳＮＲ（Peak Signal-to-Noise Ratio）を採用することができる。
【００４０】
ちなみに、このような映像の対象物の画質に係る視認品質の低下の問題は、以上に説明した多視点映像ストリームのケースに限定されるものではない。例えば、複数のセグメントファイルに分割された大容量の送信データであって、各セグメントについて互いにデータ量の異なる複数段階のセグメントファイルが準備されている送信データを送信可能なサーバに対し、データ要求を行うクライアントであれば、同様の問題が現実に生じている。本発明のクライアントによれば、そのような送信データに係る視認品質の低下の問題を解決することができるのである。
【００４１】
［装置の機能構成、配信制御方法］
同じく、図１に示した機能ブロック図によれば、本発明のクライアントであるスマートフォン１は、通信インタフェース部１０１と、タッチパネルディスプレイ（ＴＰ・ＤＰ）１０２と、プロセッサ・メモリとを有する。ここで、プロセッサ・メモリは、スマートフォン１のコンピュータを機能させるプログラムを実行することによって、本発明によるクライアント制御方法の一実施形態であるデータ要求、受信及び処理機能を実現させる。
【００４２】
さらに、このプロセッサ・メモリは、機能構成部として、要求視点決定部１１１ａ、要求ビットレート決定部１１１ｂ及び要求タイミング決定部１１１ｃを含むデータ要求部１１１と、スループット算出部１１２ａ、受信遅延判定部１１２ｂ及びビルボード画質情報取得部１１２ｃを含む通信管理部１１２と、視点位置検出部１１３ａ、自由視点合成部１１３ｂ、メディアエンジン１１３ｃ及び受信履歴記録部１１３ｄを含むデータ処理部１１３とを有する。ここで、図１におけるスマートフォン１の機能構成部間を矢印で接続して示した処理の流れは、本発明によるクライアント制御方法の一実施形態としても理解される。
【００４３】
通信インタフェース部１０１は、
（ａ）後に詳述するデータ要求部１１１で生成されたHTTP Request（セグメント要求）を、事業者通信網やインターネット等の無線又は有線の通信ネットワークを介して配信サーバ２宛てに送信する。また、
（ｂ）配信サーバ２から、同じく後に詳述する、各セグメントファイルにおけるビルボード画質情報を受信し、さらに、
（ｃ）配信サーバ２から、HTTP Requestへの応答として、要求した視点及びビットレートのセグメントファイルを受信する。
【００４４】
また、通信インタフェース部１０１は、
（ｄ）後に詳述するデータ処理部１１３での処理結果、例えば合成された自由視点映像データ、を外部の情報処理装置宛てに送信してもよく、
（ｅ）外部のサーバから、本発明によるクライアント制御プログラム（アプリ）をダウンロードしてもよい。
【００４５】
データ要求部１１１は、要求視点決定部１１１ａと、画質増分判定部１１１ｂｊを含む要求ビットレート決定部１１１ｂと、要求タイミング決定部１１１ｃとを有している。このうち、要求視点決定部１１１ａは、現在の注視点の情報に基づいて、HTTP Request（セグメント要求）で要求する各視点のセグメントファイルの「重み」を決定する。この「重み」は、後に詳述する画質増分判定部１１１ｂｊでのビットレート配分処理の際に利用される。また、要求タイミング決定部１１１ｃは、HTTP Requestを発信するタイミングを決定し管理する。
【００４６】
さらに、要求ビットレート決定部１１１ｂは、１つ又は複数のセグメント分を受信するにあたり、多視点映像の対象であるビルボードに対応する画像領域の画質に係る情報（ビルボード画質情報）に基づいて、各視点についていずれの段階（ビットレート）のセグメントファイルを取得するかを決定する。データ要求部１１１は、ここで決定されたセグメントファイルを取得するためのHTTP Requestを、配信サーバ２宛てに送信させるのである。
【００４７】
同じく図１において、通信管理部１１２は、スループット算出部１１２ａ、受信遅延判定部１１２ｂ及びビルボード画質情報取得部１１２ｃを有している。このうち、スループット算出部１１２ａは、受信されたセグメントファイルのサイズと、要求時刻から見て当該セグメントファイルを受信するのに要した時間とに基づいて、使用している通信ネットワークのスループットを算出する。また、受信遅延判定部１１２ｂは、１つのセグメント分の受信が、少なくとも、次に受信すべき次のセグメント分の受信の開始までに完了するか否か、すなわち受信遅延が発生するか否かを判定する。
【００４８】
さらに、ビルボード画質情報取得部１１２ｃは、後に詳細に説明するように、配信サーバ２において、多視点映像ストリームデータを構成する各ビットレートのセグメントファイル毎に算出されたビルボード画質情報を、通信インタフェース部１０１を介して取得し、適宜、要求ビットレート決定部１１１ｂに出力する。
【００４９】
図２は、配信サーバ２において準備される多視点映像ストリームデータの一実施形態を示す模式図である。
【００５０】
図２において、配信サーバ２は、配信用として保存・管理する多視点映像ストリームデータを準備するため、最初に、設定された複数の視点（図２では３つの視点Ａ、B及びC）の各々についての映像データを含む１つの多視点映像コンテンツにおいて、例えば圧縮符号化等の公知技術を用いて、視点毎に、互いにビットレートの異なる複数段階の映像データを用意する。ちなみに、ビットレートとは、対象の（映像）データの品質を表す数値（単位は例えばbps(bits/sec)）であり、例えば１秒間にどれだけの（映像）情報を詰め込んでいるかの程度を示す値となっている。
【００５１】
次いで、複数の視点（３つの視点Ａ〜Ｃ）の各々について、各ビットレートの映像データを、時間軸上で複数のセグメントに分割する。ここで、１つの映像データを構成する複数のセグメントは、再生の順番である再生時間1，2，3，・・・に対応している。また、１つのセグメントは、例えば数〜１０秒程度の再生時間長を有するものとすることができる。ちなみに、１つの映像データを構成するセグメントの再生時間長は、特にＶｏＤ配信の場合、一定値に設定されることが好ましい。
【００５２】
以上に述べた準備処理によって、図２に示すように、多視点映像ストリームデータは、各視点について、再生時間毎に、互いにビットレートの異なる複数の（図２では４つの）セグメントファイルが用意されたデータセットとして保存・管理される。図２では、セグメントファイルを示す矩形の相対的な高さ（高さ方向の幅）が、ビットレートの高低（段階）を表している。また、例えば、視点「Ａ」の映像データにおける再生時間「１」のセグメントファイルには、「Ａ１」との記号が付され他と区別されている。
【００５３】
以上に説明したような配信サーバ２で準備された多視点映像ストリームデータを取得するため、スマートフォン１（の通信インタフェース部１０１）は、本実施形態においてＤＡＳＨに基づき、配信サーバ２との間でデータの送受信を行う。
【００５４】
図３は、各視点のセグメントファイル内におけるビルボード画像領域を説明するための模式図である。また、図４は、スマートフォン１における、ビルボード画質を考慮したビットレート配分を説明するための模式図である。
【００５５】
図３に示す例では、配信サーバ２には、３つの視点Ａ、Ｂ及びＣの各々について再生時間1，2，3，・・・のセグメントファイルが準備されている。ここでＢを注視点とする。配信サーバ２は、さらに、これら各視点及び各再生時間のセグメントファイルについて、画質、すなわちビットレートの異なる３段階のファイル、具体的には、ビットレートがそれぞれ1Mbps、2Mbps及び4Mbpsであるセグメントファイルを用意している。
【００５６】
ここで、配信要求を行う従来のクライアントでは、例えば再生時間3において、注視点である視点Ｂに最も高いビットレートである4Mbpsが配分されることになる。しかしながら、図３の例では、セグメントファイルＢ３におけるビルボード画像領域は比較的小さくなっており、例え高いビットレートが配分されたとしても、ビルボードそのものの視認について視認品質が大きく向上することはない。一方、視点Ｃは注視点ではないので、より低いビットレート、例えば2Mbpsが配分されることになる。しかしながら、セグメントファイルＣ３におけるビルボード画像領域は比較的大きく、低いビットレートの配分によってビルボードの視認品質の低下が顕著となってしまう。
【００５７】
そこで、スマートフォン１では、このビルボードの画質そのものに注目し、ビルボード画質に起因する視認品質の低下を抑制し、当該品質を向上させるようなビットレート配分を実施する。同じく図３のグラフに示すように、ビルボード画像領域の画質（ビルボード画質）に関するＲＤ（Rate Distortion）曲線からすると、再生時間3においては、視点Ｂのセグメントファイルでのビルボード画質は、ビットレートを2Mbpsから4Mbpsへ高くしてもほとんど向上しない。一方、視点Ｃでのビルボード画質は、2Mbpsから4Mbpsへ高くすることによって効果的に向上する。
【００５８】
したがってこの場合、スマートフォン１は、図４に示すように、視点Ｂが注視点であるにもかかわらず、より高いビットレートを視点Ｃに配分する（従来注視点である視点Ｂに配分していたビットレート分を視点Ｃに移す）。その結果、全体のビルボード画質の低下を抑制して視認品質を向上させることができるのである。
【００５９】
図５は、ビルボード画質情報の生成についての一実施形態を説明するための模式図である。
【００６０】
図５に示すように、本実施形態の配信サーバ２は、準備したセグメントファイルにおけるビルボード画像領域の画質に係る情報（ビルボード画質情報）を生成する画質情報生成部２１１を有している。画質情報生成部２１１は、ビルボード画質情報として、各セグメントファイルのビルボード画像領域におけるピーク信号対雑音比（ＰＳＮＲ，Peak Signal-to-Noise Ratio）値を算出し、リスト化する。
【００６１】
なお、後述するように、ビルボード画質情報は当然に、ＰＳＮＲに限定されるものではない。また、ビルボード画像領域は、予め付与されたマスク画像を用いて決定してもよく、または、公知の画像識別技術を用いてフレーム画像全体から抽出することもできる。例えば、対象となるビルボードの画像パッチによって機械学習の識別器を予め学習させておき、この学習済みの識別器に、セグメントファイルのフレームを入力することで、ビルボード画像領域を出力させてもよい。
【００６２】
以下、画質情報生成部２１１におけるＰＳＮＲの算出について説明する。一般に、解像度m×ｎの画像I及び画像Kにおいて、画像Iが画像Kよりもノイズによって劣化したもの（例えば画像Iが、ビットレート調整のために原画像Kを圧縮処理したもの）と見なされる場合を考える。次式
（１）  MSE＝(mn)-1Σi=0m-1Σj=0n-1(I(i, j)−K(i, j))2
で定義される平均二乗誤差MSEを用いると、画像Iのピーク信号対雑音比PSNRは、次式
（２）  PSNR＝10・log10(MAXI2／MSE)
＝20・log10(MAXI／MSE0.5)
で表される。ここで、MAXIは画像Iが取りうる最大の画素値である。１画素が8ビットで表現されている場合、MAXIの値は255となる。
【００６３】
次に、ビルボード画像領域のみにおけるPSNR値の算出について説明する。図５に示すように、セグメントファイル画像Iの中に複数のビルボード画像領域が存在する場合、全ての領域のＰＳＮＲを１つの値として表現する。例えば、P個のビルボード画像領域（解像度mp×ｎp，p＝1〜P）が存在する場合、最初に、各領域の平均二乗誤差MSE(p)を、次式
（３）  MSE(p)＝(mpnp)-1Σi=0mp-1Σj=0np-1(Ip(i, j)−Kp(i, j))2
を用いて算出する。ここで、Ip(i, j)は、ビルボード画像領域Kp(i, j)を有する原画像を、ビットレート調整のために圧縮処理した画像におけるビルボード画像領域（の画素値）である。次いで、このMSE(p)をビルボードの数Pで平均化して全体のMSEを、次式
（４）  MSE＝P-1Σp=1P MSE(p)
を用いて算出し、上式（２）によってビルボード画像領域全体のPSNR値を導出する。
【００６４】
ここで、上式（４）のビルボード数Pによる平均は、各ビルボードに予め重みを付与し、重み付き平均とすることもできる。例えば、スポーツ観戦の多視点映像ストリームデータにおけるセグメントファイルでのビルボードとして、スター選手やボールを持っている選手等の特定の選手（ビルボード認識の際に付与された識別子IDとして特定のもの）のビルボードに対し、より大きい重みを付与するとしてもよい。 
【００６５】
また、変更態様として、複数のビルボード領域全体を１つのPSNR値算出対象とし、MSEを、次式（５）を用いて算出してもよい。
（５）  MSE＝(Σp=1P mpnp)-1Σp=1PΣi=0mp-1Σj=0np-1(Ip(i, j)−Kp(i, j))2
【００６６】
配信サーバ２の画質情報生成部２１１は、以上のように算出したPSNR値を、各再生時間での各ビットレートのセグメントファイルにおけるビルボード画質情報として、図５に示すようにリスト（テーブル）化する。このビルボード画質情報のリスト（テーブル）を用いることによって、スマートフォン１は、ビットレートを増加させた際のビルボード画質の増加割合、すなわちビットレート増分のコストパフォーマンスを判断することが可能となる。
【００６７】
ここで、図５のテーブルのように、PSNR値を当該セグメントファイルのファイルサイズと紐づけて記録することも好ましい。これにより、上記のコストパフォーマンスを正確に査定することが可能となる。実際、互いに同一のビットレートでエンコードされたセグメントファイルであっても、その再生時間によって各々の映像の複雑度が異なることにより、ファイルサイズが異なってくる。したがって、スマートフォン１においてビルボード画質情報を取り扱う際、この紐づけられたファイルサイズを考慮することによって、結果的に、より適切なビットレートの配分を実現することも可能となる。
【００６８】
なお、ビルボード画質情報がエンコード時に得られない場合、同様に画質に影響を与える情報として、ビルボード画像領域の面積（の合計）、ビルボード（画像領域）の数、又はビルボードそのものに基づいて予め設定した重み等を代わりに採用することも可能である。
【００６９】
図６は、本発明による配信制御方法の一実施形態の概略を示すシーケンス図である。ここで、ベースとなる配信手順は、ＨＴＴＰクライアントとＨＴＴＰサーバとの通信に係るものであって、公知のＨＬＳやＭＰＥＧ−ＤＡＳＨ等のプロトコルに沿ったものとなっている。
【００７０】
（Ｓ１０１）スマートフォン１は、配信サーバ２に対しプロファイルを要求する。ここで、プロファイルは映像メタデータが記述されたファイルであり、ＨＬＳならばm3u8ファイルが、ＭＰＥＧ−ＤＡＳＨならばＭＰＤ（Media Presentation Description）がそれに相当する。
（Ｓ１０２）配信サーバ２は、予め生成しておいたプロファイルを、要求元のスマートフォン１に送信する。
（Ｓ１０３）スマートフォン１は、配信サーバ２に対しビルボード画質情報を要求する。（Ｓ１０４）配信サーバ２は、予め生成しておいたビルボード画質情報を、要求元のスマートフォン１に送信する。
【００７１】
（Ｓ１０５）スマートフォン１は、配信サーバ２に対し、予め設定されたビットレートを有する、再生時間１における各視点のセグメントファイルを取得するための要求（HTTP Request）を行う。
（Ｓ１０６）配信サーバ２は、ステップＳ１０５の要求に応答し、再生時間１のセグメントファイルを、要求元のスマートフォン１に送信する。
【００７２】
（Ｓ１０７）スマートフォン１は、ステップＳ１０６で受信したセグメントファイルのサイズと、要求時刻から見て全ての（全視点の）セグメントファイルを受信するのに要した時間とに基づいて、使用している通信ネットワークのスループットを算出する。次いで、ステップＳ１０２によって受信されたプロファイルに記載された、要求可能なセグメントファイルのビットレートの種類（段階）と、算出したスループットとに基づき、さらに、ステップＳ１０４で受信したビルボード画質情報を用いて、各視点について次に要求すべきビットレートを決定する。
【００７３】
（Ｓ１０８）スマートフォン１は、受信した再生時間１のセグメントファイルをメディアエンジン１１３ｃ（図１）に渡し、メディアエンジン１１３ｃは、（バッファが１セグメント分の長さに設定されている場合、）同セグメントファイルの再生を開始する。
【００７４】
（Ｓ１０９）スマートフォン１は、配信サーバ２に対し、ステップＳ１０７で決定したビットレートを有する、再生時間２における各視点のセグメントファイルを取得するための要求（HTTP Request）を行う。
（Ｓ１１０）配信サーバ２は、ステップＳ１０９の要求に応答し、再生時間２のセグメントファイルを、要求元のスマートフォン１に送信する。
【００７５】
これ以降、スマートフォン１と配信サーバ２とは、Ｓ１０７〜Ｓ１１０と同様の手順を繰り返し、順次再生時間３以降のセグメントファイルの要求、送受信及び再生を実施していく。なお、通常、スマートフォン１による要求（HTTP Request）は、１セグメント（に含まれるメディア）分の再生時間長（例えば数〜１０秒程度）の経過毎に、周期的に行われることになる。
【００７６】
図７は、スマートフォン１におけるユーザによって選択される視点の位置関係を説明するための模式図である。ちなみに、同図は選択可能な視点が５つ設定されている場合を示している。
【００７７】
図７には、撮影対象を中心とした当該撮影対象に対する視点Ａ、視点Ｂ、・・・、視点Ｅの位置関係が示されている。各視点は、撮影対象から見た方向角θ（0°≦θ＜360°）で表される視点位置について所定の範囲を占めている。例えば図７では、視点Ｂは、視点位置の範囲として36°〜108°の範囲を仮想的にカバーする視点となっている。例えば、視点位置60°はこの視点Ｂに属することになる。
【００７８】
ユーザは、タッチパネルディスプレイ１０２（図１）に表示された視点操作用画像に対する操作や、又はそのような表示に関わらない（暗黙の）操作等によって、自らが見たいと思う視点位置（又は視点）を指定する。ここで指定された（視点位置に係る）視点が注視点となる。ここで、ユーザは、随時にしかも連続的に、指定する視点位置を変更することが可能であってもよい。
【００７９】
視点位置検出部１１３ａ（図１）は、常時、ユーザによる視点指示操作を監視し、ユーザによる注視点の指示を受けて、当該指示内容をデータ要求部１１１（要求視点決定部１１１ａ）（図１）に出力する。ここで、この要求視点決定部１１１ａは、入力した当該指示内容を受けて、設定された視点（例えば５つの視点Ａ〜Ｅ）のうちから注視点を決定し、さらに、決定した（現在の）注視点の情報に基づいて、HTTP Request（セグメント要求）で要求する各視点のセグメントファイルの「重み」を決定する。これにより、クライアントにおける視点移動（ユーザによる視点選択）に対応した配信制御を実施することが可能となるのである。
【００８０】
次に、スマートフォン１の要求ビットレート決定部１１１ｂ（図１）におけるビルボード画質情報に基づいたビットレート配分決定処理を説明する。最初に、従来のクライアントにおけるビットレート配分の決定について述べる。
【００８１】
従来、要求するセグメントファイルにおけるビットレートの配分は、再生時刻、注視点や、計測されたスループットに基づいて決定される。すなわち、直近に計測されたスループットを参考にして全視点にわたって使用可能な合計ビットレートが決定され、この合計値が、所定の確率分布に従い各視点に基準ビットレートとして配分される。その後、視点毎に、基準ビットレートを超えずプロファイル内で最大となるビットレートが選択されるのである。
【００８２】
具体的に、再生時間tにおいて全視点で利用可能な合計ビットレートをb(t)とすると、このb(t)は、直近に計測されたスループット値を越えない範囲でできるだけ大きいビットレート値として設定される。なお，直近のスループットは、前の再生時間の全視点分のセグメントファイルの合計サイズとダウンロードに要した合計時間とから算出される。
【００８３】
次いで、所定の視点選択の確率分布p(xi| xi-1)に従い、設定されたb(t)を各視点に基準ビットレートとして配分する。ここで、確率分布p(xi| xi-1)は、視点xiの選択確率であって、xi-1を直前に選択された視点とすると例えばxi＝xi-1の場合に最大値をとる正規分布とすることができる。
【００８４】
この選択確率p(xi| xi-1)を用いると、視点xiの再生時間tにおける基準ビットレートbi(t)は、次式
（６）  bi(t)＝p(xi| xi-1)＊b(t)
のように算出される。その後、視点毎に、算出された基準ビットレートを超えない範囲においてプロファイル内で最大となるビットレートを選択する。このように、従来、ビルボード画質を一切考慮せずにビットレート配分がなされてきたのである。
【００８５】
これに対し、スマートフォン１の要求ビットレート決定部１１１ｂ（図１）は、各視点についての各ビットレートのセグメントファイルにおけるビルボード画像領域に対して算出された
（ａ）PSNR値の増分、又は
（ｂ）PSNR値と当該視点に割り当てられた重みとから算出される値の増分
が最大若しくは所定以上となるように、各視点のセグメントファイルのビットレートを決定する。ここで、注視点か否か等の条件を考慮し得る上記（ｂ）の形態を採用することがより好ましいが、この場合、設定された視点選択の確率分布pの値が高い視点ほど、この視点に対しより大きな重みを割り当てることも好ましい。
【００８６】
具体的に、要求ビットレート決定部１１１ｂは、上記（ｂ）の値の増分が最大又は所定以上となるように、個々の視点に単位分（例えば1Mbps又は1Mbits）ずつビットレート又はファイルサイズを配分し、各視点のセグメントファイルのビットレート又はファイルサイズを決定してもよい。なお、この配分に当たっては、
（ａ）予め算出されたスループットの値から、取得する全ての視点についての合計ビットレート又は合計ファイルサイズを算出し、
（ｂ）当該視点に単位分ずつ配分されたビットレート又はファイルサイズの合計が、算出された合計ビットレート又は合計ファイルサイズを超えないように、各視点のセグメントファイルのビットレート又はファイルサイズを決定する
ことができる。
【００８７】
また、この場合、いずれの視点のセグメントファイルにおけるビルボード画像領域のPSNR値も所定閾値を越えないように、ビットレート又はファイルサイズを単位分ずつ配分することも好ましい。以下、図８を用いて、この配分処理をさらに具体的に説明する。
【００８８】
図８は、本発明に係るビルボード画質情報に基づいたビットレート配分決定処理の一実施形態を説明するための模式図である。
【００８９】
図８に示した実施形態によれば、要求ビットレート決定部１１１ｂの画質増分判定部１１１ｂｊは、直近のスループットを参考にして全視点の合計として利用可能な合計ビットレートを決定した後、配信サーバ２から取得した各視点のビルボード画質に基づいて、ビットレートの配分を行う。言い換えると、各視点のビットレートの合計が合計ビットレート以下に収まることを制約条件とした上で、全体のビルボード画質、すなわち全視点についてのPSNR値が、最大又は所定以上となり、且つ各視点に割り当てられた重みに沿って配分されるように、各視点のビットレートを選択する。
【００９０】
具体的には、図８の実施例に示したような以下の手順（ア）〜（エ）が実行される。本実施例では、合計ビットレートは10Mbpsに決定されているとする。
（ア）視点Ａ、Ｂ及びＣの各々に重みを設定する。この重みの値は、例えば、それぞれの視点選択の確率分布に比例した値とすることができる。
（イ）各視点へのビットレート配分の最初として、視点Ａ、Ｂ及びＣの各々に、最低の値となるビットレート1Mbpsを配分する。
（ウ）次いで、いずれかの視点にビットレートを１段階ずつ（1Mbpsずつ）配分する。ここで、配分先の視点は、コストとして1Mbps増加させたときのビルボード画質向上効果（パフォーマンス）が最大となるように決定する。例えば、
（PSNR値（ビルボード画質）の増分）×（当該視点の重み）
のパフォーマンス値が最大となるパスを選択する。
【００９１】
（エ）上記（ウ）の手順を、各視点に配分したビットレートの合計が10Mbpsを越えない間、繰り返す。図８に示した実施例では、初期配分として各視点に1Mbpsが配分された後、次に、パフォーマンス値が12（＝(36−30)・2）であって最大となるパス１、すなわち視点Ｂに更に1Mbpsを配分するパスが選択される。次いで、順次、パフォーマンス値が最大となるパス２、パス３、・・・、パス７が選択される。本実施例では、最終的に、視点Ａと視点Ｂとについてビットレートは3Mbpsと決定され、視点Ｃについてビットレートは4Mbpsと決定される。
【００９２】
ここで、1Mbpsを配分されることによってPSNR値が所定の閾値を超えてしまう視点におけるパスは、選択されないことも好ましい。この場合、所定の閾値として例えば40dbを採用することができる。これは、通常、PSNR値が40dbを超えると、画質の劣化が認知され難くなり、それ以上のPSNR値を大きくしても画質向上効果がほとんど認識されないことが経験的に分かっていることによる。これに従い、例えば図８に示した実施例では、パス６に続く視点Ｃでの4Mpbsから5Mbpsへのパスは、パス７として選択されていない。
【００９３】
また、配分先の全ての視点において、配分することによりPSNR値が所定の閾値を超えてしまう場合、たとえビットレートの合計が10Mbpsに達していなくとも、ビットレートの配分を終了することも好ましい。
【００９４】
なお、以上に説明した実施形態では、簡単のため配分の単位をビットレートとしたが（すなわち1Mbpsずつ配分を行ったが）、厳密には同じビットレートのセグメントファイルであっても、視点が違えばファイルサイズも異なっている。したがって、単位ビットレートずつ配分するのではなく、単位ファイルサイズ分ずつ、例えば1Mbits分ずつ配分してもよい。この場合、配分のコストは、単位ファイルサイズ当たりに正規化して算定する。
【００９５】
さらに、上記手順（ウ）におけるパス選択について、パフォーマンス値、すなわち（PSNR値の増分）×（当該視点の重み）の値が最大となるパスを探索する範囲を、同一再生時間のセグメントファイル群内に限定せず、複数の再生時間に跨ったセグメントファイル群の中からパフォーマンス値の最大となるパスを選択してもよい。これにより、特に、複数のセグメントファイルをバッファリングするようなシステムにおいて、合計ビットレートに制約がある条件の下、例えばある再生時間において画質の飽和を検出した際、その分のビットレート増価を行わず、代わりに後の別の再生時間における画質向上のためにそのビットレート分を割り振ることも可能となる。
【００９６】
ちなみに、要求ビットレート決定部１１１ｂは、他の実施形態として、取得したビルボード画質情報に基づいて、各視点のセグメントファイルを要求する順序を決定し、各視点のセグメントファイルを取得するHTTP Request（セグメント要求）を、決定した順序によって配信サーバ２宛てに送信させてもよい。例えば、図８を用いて説明したように、ビルボード画質情報（と各視点の重みと）に基づいて決定した各視点のビットレートの大きさの順序（降順）を、この要求順序とすることができる。このように、ビルボード画質を考慮して最も高いビットレートを選択したセグメントファイルから順にセグメント要求を行うことによって、次の再生開始時刻までにその全体分を間に合わせて受信することが、より確実に可能となるのである。
【００９７】
図１に戻って、データ処理部１１３は、自由視点合成部１１３ｂ及びメディアエンジン１１３ｃを有し、以上に説明したように配信サーバ２から受信された１つ又は複数のセグメント分のセグメントファイルの処理を実行する。ここで、自由視点合成部１１３ｂは、受信された各視点のセグメントファイルを合成して自由視点映像を生成し、例えばスマートフォン１に搭載されたアプリ（アプリケーション・プログラム）に出力して、当該アプリに当該自由視点映像を利用させてもよい。
【００９８】
また、メディアエンジン１１３ｃは、受信された各視点のセグメントファイルを処理し、タッチパネルディスプレイ１０２に注視点の映像を表示させたり、ユーザの視点選択指示を視点位置検出部１１３ａから入力した際、選択された視点の映像をタッチパネルディスプレイ１０２に表示させたりしてもよい。
も好ましい。
【００９９】
具体的に、メディアエンジン１１３ｃは、受信された
（ａ）各視点の映像ストリーム（セグメントファイル）
（ｂ）各視点に存在するビルボード情報（マスク画像、３次元位置、大きさ情報）、及び
（ｃ）各視点のカメラキャリブレーション情報
によって、最初にセグメントファイルをデコードし、フレーム画像を取得する。次いで、マスク画像をフレーム画像に適用して、ビルボード画像領域のみの画像（ビルボード画像）を抽出する。さらに、このビルボード画像を３次元位置に基づいて３次元モデル内に表示する。メディアエンジン１１３ｃは、これらの処理を各視点について実施するのである。
【０１００】
なお、ユーザが視点位置を指示する入力操作を行った場合、指示された視点位置から視点を特定し、対応するビルボード画像に切り替える。この処理をフレーム毎に実施することによって、映像として任意の視点位置を指定した視聴が可能となるのである。
【０１０１】
以上、詳細に説明したように、本発明によれば、クライアント（例えばスマートフォン）は、要求（例えばHTTP Request）によって取得すべきセグメントファイルの段階（例えばビットレート）を、映像対象（例えばビルボード）に対応する画像領域の画質に係る情報（例えばビルボード画質情報）に基づいて決定する。これにより、例えば、要求すべきセグメントファイルに対する段階（ビットレート）の配分を制御し、当該配分による（ビルボード）画質の向上におけるコストパフォーマンスをより高めることができる。その結果、（ビルボード）画質に起因する視認品質の低下を抑制することが可能となるのである。
【０１０２】
特に、本発明を多視点自由映像のストリーム配信に適用した場合、ビルボード画像領域の画質を予め算出してクライアントに送信し、ビルボード画質に基づいて各視点へのビットレート配分を行うことによって、視点の切り替えを伴う映像の視聴において視認品質を従来と比較してより向上させることができる。また、この配信におけるネットワーク帯域の効率的な利用が可能となるのである。
【０１０３】
以上に述べた本発明の種々の実施形態について、本発明の技術思想及び見地の範囲内での種々の変更、修正及び省略は、当業者によれば容易に行うことができる。以上に述べた説明はあくまで例示であって、何ら制約を意図するものではない。本発明は、特許請求の範囲及びその均等物によってのみ制約される。
【符号の説明】
【０１０４】
１  スマートフォン（クライアント）
１０１  通信インタフェース部
１０２  タッチパネルディスプレイ（ＴＰ・ＤＰ）
１１１  データ要求部
１１１ａ  要求視点決定部
１１１ｂ  要求ビットレート決定部
１１１ｂｊ  画質増分判定部
１１１ｃ  要求タイミング決定部
１１２  通信管理部
１１２ａ  スループット算出部
１１２ｂ  受信遅延判定部
１１２ｃ  ビルボード画質情報取得部
１１３  データ処理部
１１３ａ  視点位置検出部
１１３ｂ  自由視点合成部
１１３ｃ  メディアエンジン
１１３ｄ  受信履歴記録部
２  配信サーバ
２１１  画質情報生成部
【図１】
2018160805.tif 000003
【図２】
2018160805.tif 000004
【図３】
2018160805.tif 000005
【図４】
2018160805.tif 000006
【図５】
2018160805.tif 000007
【図６】
2018160805.tif 000008
【図７】
2018160805.tif 000009
【図８】
2018160805.tif 000010