JP6560696B2 - データのセグメント受信を制御するクライアント、プログラム及び方法 - Google Patents

データのセグメント受信を制御するクライアント、プログラム及び方法 Download PDF

Info

Publication number
JP6560696B2
JP6560696B2 JP2017014691A JP2017014691A JP6560696B2 JP 6560696 B2 JP6560696 B2 JP 6560696B2 JP 2017014691 A JP2017014691 A JP 2017014691A JP 2017014691 A JP2017014691 A JP 2017014691A JP 6560696 B2 JP6560696 B2 JP 6560696B2
Authority
JP
Japan
Prior art keywords
segment
request
data
files
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017014691A
Other languages
English (en)
Other versions
JP2018125621A (ja
Inventor
福井　啓允
啓允 福井
内藤　整
整 内藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2017014691A priority Critical patent/JP6560696B2/ja
Publication of JP2018125621A publication Critical patent/JP2018125621A/ja
Application granted granted Critical
Publication of JP6560696B2 publication Critical patent/JP6560696B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は、大容量のデータをサーバから取得するクライアントにおける受信制御技術に関する。
次世代における高い臨場感を提供可能なメディアの一つとして、自由視点映像が注目されている。自由視点映像とは、対象物に対する視点をユーザが任意に指定し、指定された視点からの映像を随時提供する、といったインタラクティブな視聴を可能にする映像である。
この自由視点映像の合成方式の一典型例として、３次元モデル上に視点毎の対象物画像を配置し、ユーザが指定した任意の仮想視点からの見え方を、これらの配置画像を用いて計算することによって描画を実施する方法が挙げられる。具体的に、この方法での合成処理は、サーバから配信された以下の（ａ）〜（ｃ）を含むコンテンツを取得したクライアント側で実施される。
（ａ）各視点の映像ストリーム
（ｂ）各視点に存在する対象物情報（マスク画像、３次元の位置・大きさに係る情報）
（ｃ）各視点のカメラキャリブレーション情報
このように、自由視点映像の合成処理では、サーバ側において、各コンテンツを視点数分（多視点分）だけ予め準備しておく必要のあるのが通常である。この際、特に、上記（ａ）の映像ストリームについては高解像度化によって１視点当たりのビットレートも相当に高くなっており、インターネット経由で配信することを考えると、データ量が大きくなり過ぎるという問題が生じていた。
この問題に対し、例えば特許文献１では、全視点分の映像ストリームを配信しつつ、ユーザが現在指定している視点以外の映像についてはそのビットレートを下げることによって、全体のレートをできる限り低下させる技術が提案されている。
一方、自由視点映像の配信方式としては、例えば予め作成された映像コンテンツを配信する場合、ＶｏＤ（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によって複数視点及び／又は複数聴点のセグメントファイルのパラレル受信を行う。
これにより、スループットが変動しやすい状況においても、セグメントファイルのビットレートを動的に変更可能となるので、結果として、再生が停止する頻度を低減したり、または再生画質を向上させたりすることができる。
図１に戻って、データ処理部１１３は、自由視点合成部１１３ｂ及びメディアエンジン１１３ｃを有し、以上に説明したように配信サーバ２から受信された各セグメント分のセグメントファイルの処理を実行する。具体的に、自由視点合成部１１３ｂは、受信された各視点のセグメントファイルを合成して自由視点映像を生成し、例えばスマートフォン１に搭載されたアプリ（アプリケーション・プログラム）に出力して、当該アプリに当該自由視点映像を利用させてもよい。
また、メディアエンジン１１３ｃは、受信された各視点のセグメントファイルを処理し、タッチパネルディスプレイ１０２に注視点の映像を表示させたり、ユーザの視点選択指示を視点位置検出部１１３ａから入力した際、選択された視点の映像をタッチパネルディスプレイ１０２に表示させたりすることも好ましい。ちなみに、スマートフォン１では、従来と異なり、とりあえず注視点のセグメントファイルを受信すれば、他の視点のセグメントファイルの受信完了を待たずに、メディアエンジン１１３ｃがこの注視点の再生を実施することも可能となる。
以上、詳細に説明したように、本発明によれば、１つのセグメント分を受信するにあたり、１つの要求によって、取得すべき各視点のセグメントファイルの全てを取得するのではなく、そのうちの１つ又は一部を取得する。したがって、使用する通信ネットワークの通信状況に応じて適宜、より適したセグメントファイルの要求を実施することができるのである。
以上に述べた本発明の種々の実施形態について、本発明の技術思想及び見地の範囲内での種々の変更、修正及び省略は、当業者によれば容易に行うことができる。以上に述べた説明はあくまで例示であって、何ら制約を意図するものではない。本発明は、特許請求の範囲及びその均等物によってのみ制約される。
１ スマートフォン（クライアント）
１０１ 通信インタフェース部
１０２ タッチパネルディスプレイ（ＴＰ・ＤＰ）
１１１ データ要求部
１１１ａ 要求視点決定部
１１１ｂ 要求ビットレート決定部
１１１ｃ 要求タイミング決定部
１１２ 通信管理部
１１２ａ スループット算出部
１１２ｂ 受信遅延判定部
１１３ データ処理部
１１３ａ 視点位置検出部
１１３ｂ 自由視点合成部
１１３ｃ メディアエンジン
１１３ｄ 受信履歴記録部
２ 配信サーバ

Claims (11)

  1. 複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントであって、
    １つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
    受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
    を有することを特徴とするクライアント。
  2. 前記データ要求手段は、受け付けた指示又は予め決められた事項に基づいて、取得すべき当該複数種のセグメントファイルに優先度を設定し、当該優先度のより高いセグメントファイルを取得する要求を、より優先して送信させることを特徴とする請求項１に記載のクライアント。
  3. 当該送信データは映像及び／又は音声ストリ−ムデータであって、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであり、
    前記データ要求手段は、注視点及び／又は注聴点に係る映像及び／又は音声セグメントファイルに最も高い優先度を設定する
    ことを特徴とする請求項２に記載のクライアント。
  4. 当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
    前記データ要求手段は、受け付けた指示又は予め決められた事項に基づいて、次のセグメント分を受信するにあたって取得すべき各セグメントファイルにつき、いずれの当該段階のセグメントファイルを選択するかを決定する
    ことを特徴とする請求項１から３のいずれか１項に記載のクライアント。
  5. 当該複数種のセグメントファイルの各々について、互いにデータ量の異なる複数段階のセグメントファイルが準備されており、
    前記データ要求手段は１つのセグメント分を受信するにあたり、１つの要求の結果として受信されたある段階のセグメントファイルの受信の具合に基づいて、次に又は以後取得を要求するセグメントファイルの段階を決定する
    ことを特徴とする請求項１から４のいずれか１項に記載のクライアント。
  6. 当該送信データは映像及び／又は音声ストリ−ムデータであり、当該複数種のセグメントファイルは、互いに視点及び／又は聴点の異なる複数種の映像及び／又は音声セグメントファイルであって、当該複数段階のセグメントファイルは、互いにビットレートの異なる映像及び／又は音声セグメントファイルであり、
    前記データ要求手段は、１つの要求の結果として受信されたあるビットレートのセグメントファイルの受信の具合に基づいて、次に又は以後取得を要求するセグメントファイルのビットレートを決定する
    ことを特徴とする請求項５に記載のクライアント。
  7. 前記データ要求手段は、当該あるビットレートのセグメントファイルの受信の際に算出されたスループットに基づいて、以後取得を要求する当該複数種の映像及び／又は音声セグメントファイルの各々に対し選択すべきビットレートを割り当てたビットレート分布を決定することを特徴とする請求項６に記載のクライアント。
  8. １つのセグメント分の受信が、少なくとも、次に受信すべき次のセグメント分の受信の開始までに完了するか否かを判定する受信遅延判定手段を更に有し、
    前記データ要求手段は、当該１つのセグメント分を受信するにあたり、前記受信遅延判定手段での判定結果に基づき、以後行う各要求において、取得を要求するセグメントファイルの数を決定する
    ことを特徴とする請求項１から７のいずれか１項に記載のクライアント。
  9. 前記データ要求手段は、以後行う１つの要求において、複数のセグメントファイルの取得を要求する際、当該１つの要求の中に、前記サーバによるプッシュ送信の指示を含めることを特徴とする請求項８に記載のクライアント。
  10. 複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータを機能させるクライアント制御プログラムであって、
    であって、
    １つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるデータ要求手段と、
    受信された１つのセグメント分のセグメントファイルの処理を実行するデータ処理手段と
    してコンピュータを機能させることを特徴とするクライアント制御プログラム。
  11. 複数のセグメントに分割された送信データであって、各セグメントについて複数種のセグメントファイルが準備されている送信データを送信可能なサーバに対するクライアントに搭載されたコンピュータにおけるクライアント制御方法であって、
    １つのセグメント分を受信するにあたり、該１つのセグメント分として準備された当該複数種のセグメントファイルのうちの１つ又は一部を取得する要求を、前記サーバ宛てに送信させ、次いで順次、要求していない残りのセグメントファイルのうちの少なくとも１つを取得する要求を、前記サーバ宛てに送信させるステップと、
    受信された１つのセグメント分のセグメントファイルの処理を実行するステップと
    を有することを特徴とするクライアント制御方法。
JP2017014691A 2017-01-30 2017-01-30 データのセグメント受信を制御するクライアント、プログラム及び方法 Active JP6560696B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017014691A JP6560696B2 (ja) 2017-01-30 2017-01-30 データのセグメント受信を制御するクライアント、プログラム及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017014691A JP6560696B2 (ja) 2017-01-30 2017-01-30 データのセグメント受信を制御するクライアント、プログラム及び方法

Publications (2)

Publication Number Publication Date
JP2018125621A JP2018125621A (ja) 2018-08-09
JP6560696B2 true JP6560696B2 (ja) 2019-08-14

Family

ID=63109758

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017014691A Active JP6560696B2 (ja) 2017-01-30 2017-01-30 データのセグメント受信を制御するクライアント、プログラム及び方法

Country Status (1)

Country Link
JP (1) JP6560696B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7365212B2 (ja) * 2019-12-03 2023-10-19 株式会社ソニー・インタラクティブエンタテインメント 動画再生装置、動画再生システム、および動画再生方法
WO2022269723A1 (ja) * 2021-06-21 2022-12-29 日本電信電話株式会社 同期制御を行う通信システム、その同期制御方法、受信サーバ及び同期制御プログラム
CN113973217B (zh) * 2021-11-02 2023-09-22 秒影工场(北京)科技有限公司 一种影像数据传输到云端的方法及装置
JP7339999B2 (ja) * 2021-12-16 2023-09-06 ソフトバンク株式会社 配信システム、配信サーバ、配信方法、通信端末、再生方法、及びプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1188866A (ja) * 1997-07-18 1999-03-30 Pfu Ltd 高精細画像表示装置及びそのプログラム記憶媒体
JP6607433B2 (ja) * 2014-06-23 2019-11-20 パナソニックＩｐマネジメント株式会社 映像配信方法及びサーバ
JP2017022529A (ja) * 2015-07-09 2017-01-26 キヤノン株式会社 通信システム、通信装置、通信方法、及び、プログラム

Also Published As

Publication number Publication date
JP2018125621A (ja) 2018-08-09

Similar Documents

Publication Publication Date Title
US20230283653A1 (en) Methods and apparatus to reduce latency for 360-degree viewport adaptive streaming
EP3459252B1 (en) Method and apparatus for spatial enhanced adaptive bitrate live streaming for 360 degree video playback
JP7436599B2 (ja) 空間的不均等ストリーミング
KR102324326B1 (ko) 상이한 인코딩 파라미터를 이용해 인코딩되는 복수의 인코딩 스트리밍
JP6560696B2 (ja) データのセグメント受信を制御するクライアント、プログラム及び方法
JP7486527B2 (ja) イマーシブメディアコンテンツの提示および双方向性の３６０°ビデオ通信
EP4046389A1 (en) Immersive viewport dependent multiparty video communication
US9402114B2 (en) System and method for providing randomization in adaptive bitrate streaming environments
JP5481606B1 (ja) 画像生成システムおよび画像生成用プログラム
JP7307211B2 (ja) クライアント、サーバ、受信方法及び送信方法
US11523144B2 (en) Communication apparatus, communication method, and computer-readable storage medium
WO2018020901A1 (ja) 情報処理装置及びその制御方法、コンピュータプログラム
US10708667B1 (en) Combining fragments with different encodings
JP5915604B2 (ja) 情報処理装置、プログラム及び情報処理方法
KR101454809B1 (ko) 트랜스코딩 작업 스케줄링 방법 및 이를 이용한 트랜스코딩 시스템
JP6611748B2 (ja) 画質情報でセグメント受信を制御するクライアント、システム、プログラム及び方法
JP6758268B2 (ja) 表示可能解像度に基づいて配信プロファイルを決定するクライアント、プログラム及び方法
JP6513054B2 (ja) コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム
JP5997439B2 (ja) オーディオ、ビデオ、及びコンピュータグラフィックスコンテンツの少なくとも一つをレンダリングするための方法及び入出力デバイス、及び、プリレンダリングされたオーディオ、プリレンダリングされたビデオ、及びプリレンダリングされたコンピュータグラフィックスコンテンツの少なくとも一つを配信するためのサービスを行うデバイス
JP2019033362A (ja) 配信装置、受信装置及びプログラム
WO2018178510A2 (en) Video streaming
Alhilal et al. FovOptix: Human Vision-Compatible Video Encoding and Adaptive Streaming in VR Cloud Gaming
EP4099702A2 (en) Management of a client device buffer
JP7259947B2 (ja) 映像配信装置、映像配信方法及びプログラム
KR20230094695A (ko) 멀티뷰 스트림을 위한 적응적 스트리밍 처리 방법 및 장치

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190107

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190607

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190712

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190719

R150 Certificate of patent or registration of utility model

Ref document number: 6560696

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150