JP6861484B2 - 情報処理装置及びその制御方法、コンピュータプログラム - Google Patents

Description

本発明は情報処理装置及びその制御方法、コンピュータプログラムに関し、特に、画像データの通信を行うデータ通信技術に関する。

近年、音声データや映像データ等により構成されるストリーミング形式のコンテンツをユーザにリアルタイムに配信する配信システムが提供されている。このような配信システムにより、ユーザは、自身の端末装置を介して、ライブ映像等の所望のコンテンツをリアルタイムで楽しむことができる。

映像データの中の着目領域（Region of Interest、以下「ＲＯＩ」と記す。）の映像データを高精細に配信することが知られている。この構成によると、映像データをあらかじめタイル状に領域分割し、映像全体のデータとユーザの着目するオブジェクトが映り込む領域に対応するタイルの高精細データを送信することで、ＲＯＩ部の映像を高精細にした映像データを配信することが可能になる。

特許文献１には、あらかじめ所定数の領域に分割された映像の中から、ユーザの視聴対象の領域に対応するデータを抽出して送信することが記載されている。

特開２０１１−２４０１８号公報

特許文献１の構成では、着目領域とその周辺の領域を一つのビットストリームとして送信する。しかし、このような構成においては、周辺領域を一つのビットストリームに含んだ結果、ネットワークの帯域幅を消費してしまい、着目領域の送信が遅れてしまう場合があった。その結果、ユーザは映像データをスムーズに視聴することができない場合があった。

本発明は上記課題に鑑みなされたものであり、着目領域の画像データと非着目領域の画像データを通信する場合において、着目領域の画像データの通信に係る遅延を低減することが可能な技術を提供することを目的とする。

上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、複数の部分領域に空間的に分割された画像データをサーバ装置から受信する情報処理装置であって、
前記画像データに対応する画像における着目領域を指定する指定手段と、
前記サーバ装置との間で、論理的な通信路であるコネクションを確立すると共に、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームと、が異なるストリームとなるように、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームとを含む複数のストリームを、前記サーバ装置との間の前記コネクションに基づく複数のストリームとして確立する確立手段と、
前記着目領域の画像データが前記部分領域よりも優先的に取得されるように前記複数のストリームを制御する制御手段と、
前記制御手段により制御された前記複数のストリームを用いて前記サーバ装置からプッシュ通信により画像データを受信する受信手段と、
前記サーバ装置との間のネットワークの帯域を取得する帯域取得手段と、
前記サーバ装置に対してメタデータのみをプッシュするように要求することにより前記画像データの部分領域のビットレートを取得するビットレート取得手段と、
前記ネットワークの帯域と前記部分領域のビットレートとの比較に基づいて、受信する前記画像データの部分領域の画質を判定する判定手段と
を備え、
前記受信手段は、前記判定手段により判定された画質の部分領域の画像データを受信する。

本発明によれば、着目領域の画像データと非着目領域の画像データを通信する場合において、着目領域の画像データの通信に係る遅延を低減することが可能となる。

通信システムの構成図 映像データのレイヤ、タイル構成の一例を示す図 クライアントのハードウェア構成例を示すブロック図 クライアントの機能構成例を示すブロック図 サーバのハードウェア構成例を示すブロック図 サーバの機能構成例を示すブロック図 クライアントの動作を示すフローチャート 映像データのタイルとストリームの識別子との対応関係を示す図 クライアントの動作を示すフローチャート クライアントの動作を示すフローチャート クライアントの動作を示すフローチャート サーバの動作を示すフローチャート サーバの動作を示すフローチャート サーバの動作を示すフローチャート クライアントの動作を示すフローチャート サーバの動作を示すフローチャート 映像データの中で被写体が移動した様子を示す図

以下、添付図面を参照して本発明の実施の形態を詳細に説明する。

＜実施形態１＞
以下、本発明の実施形態に係る通信装置、通信システムについて、添付の図面を参照しながら詳細に説明する。以下の実施形態は特許請求の範囲に関る本発明を限定するものではなく、また、以下の実施形態で説明されている特徴の組み合わせの全てが本発明に必須のものとは限らない。

（通信システムの構成）
図１は、通信システムの構成の一例を示す図である。通信システムは、複数の部分領域に空間的に分割された画像データを提供するサーバ（サーバ装置）１０２と、画像データを受信して再生するクライアント（クライアント装置）１０１とを備える。クライアント１０１は、例えば、ＤＴＶ（Digital TV）、ＨＭＤ（HeadMount Display）、スマートフォン、タブレット等の、表示機能を備える通信装置である。クライアント１０１は、スマートフォン、タブレット、ＰＣ等の情報処理装置上の、Ｗｅｂブラウザや、情報処理装置にインストールされたアプリケーションであってもよい。サーバ１０２は、デジタルカメラ、デジタルビデオカメラ、ネットワークカメラ、プロジェクタ、携帯電話、スマートフォン、ＰＣ、及びサーバ装置等の情報処理装置であり、画像データとしての映像データの送信元であるサーバ装置として機能する。本実施形態では、サーバ１０２を１台のＰＣによって実現しているが、クラウド上で分散して配置されていてもよい。ネットワーク１０３には、クライアント１０１とサーバ１０２とが接続される。本実施形態は、ネットワーク１０３の形態により限定されない。例えば、ネットワーク１０３は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、公衆移動体通信であるＬＴＥ（Long Term Evolution），又はそれらの組み合わせにより接続される。ＬＡＮとしては、例えばＥｔｈｅｒｎｅｔ（登録商標）に則った有線ＬＡＮや、ＩＥＥＥ８０２．１１シリーズに則った無線ＬＡＮなどが用いられる。ＩＥＥＥとは、Institute of Electrical and Electronics Engineersの略称である。ＷＡＮとしては、例えばインターネットなどが用いられる。なお、クライアント１０１とサーバ１０２は、ネットワーク１０３を介さずに、直接接続されてもよい。例えば、無線アドホックネットワークを用いて、クライアント（通信装置）１０１とサーバ１０２とが通信するようにしてもよい。本実施形態では、画像データとして映像データ（動画像データ）を送受信する例を説明するが、静止画像を送受信するようにしてもよい。

本実施形態においては、通信プロトコルとしてＨＴＴＰ／２を例に挙げて説明するが、これに限定されるものではなく、ＳＰＤＹ（スピーディー）、ＱＵＩＣなどでもよい。ＱＵＩＣとは、Quick UDP Internet Connectionsの略称である。また、一つのコネクション上で複数の論理的ストリームを処理する他のプロトコルであってもよい。

ＨＴＴＰ（Hyper Text Transfer Protocol）とは、インターネットの標準技術として、一般に広く利用されているアプリケーション層のプロトコルの一つである。ＩＥＴＦ（Internet Engineering Task Force）では、ＨＴＴＰ／１．１の次の規格としてＨＴＴＰ／２が提案されている。ＨＴＴＰ／２においては、サーバ装置とクライアント装置との間でコネクションを確立し、そのコネクション上においてストリームと呼ぶ独立した論理的な通信シーケンス（通信路）を複数構築することができる。そして、そのストリーム毎にサーバ装置とクライアント装置の間でメッセージを送受信することができる。

ＨＴＴＰ／１．１においては、クライアント装置とサーバ装置との間の通信シーケンスの多重化を可能にするために、ＨＴＴＰパイプラインという枠組みが採用されていた。しかし、ＨＴＴＰパイプラインでは、サーバはリクエストの順序通りにレスポンスを返さなければならないという制約があった。これに対して、ＨＴＴＰ／２の各ストリームにおいては、それぞれ独立にリクエストとレスポンスを通信することができ、サーバ装置は、リクエストの順序にかかわらず、応答が可能なものからクライアント装置へレスポンスを返すことができる。したがって、ＨＴＴＰ／２のストリームは、ＨＴＴＰパイプラインと比較して、ストリーム間の独立性が高まっているといえる。

また、ＨＴＴＰ／２では、クライアント装置はストリームに対して優先度を設定することができる。ストリームに優先度が設定されると、サーバ装置は、より高い優先度が設定されたストリームを優先的に処理してより早くレスポンスを返す。したがって、優先度を適切に設定することで、クライアント装置におけるユーザ体験の質を高めることが可能となっている。さらに、ＨＴＴＰ／２では、クライアント装置のリクエストなしにサーバ装置からデータを送信するプッシュ通信などの仕組みが追加されている。

本実施形態は、後述するサーバ１０２のセグメント生成部５１４において、ＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤ（Media Presentation Description）を利用する例を説明する。なお、ＭＰＥＧ−ＤＡＳＨのＭＰＤに限らず、ＨＬＳ（Http Live Streaming）などの、プレイリスト記述方式を有するものでもよい。後述するように、プレイリストとは、サーバ１０２が提供する映像データの内容、より具体的には、映像データの空間的な分割構成を示す情報である。

ＭＰＥＧ−ＤＡＳＨ、ＨＬＳは、端末装置の能力や端末装置が置かれた通信状況に応じて、動的に取得するストリームを変更する方式である。ＤＡＳＨはDynamic Adaptive Streaming over HTTPの略称であり、ＨＬＳは、Http Live Streamingの略称である。近年、スマートフォンやタブレットのような端末の普及により、様々な端末装置によりいつでもどこでもライブ映像等のストリーミングコンテンツを楽しみたいという需要が高まって来ている。ＭＰＥＧ−ＤＡＳＨ、ＨＬＳは、このような要求を実現するために規定されたものである。これらの方式では、映像データを細かい時間単位のセグメントに分割し、セグメントを取得するためのＵＲＬ（Uniform Resource Locator）をプレイリストと呼ばれるファイルに記述する。受信装置は初めにこのプレイリストを取得し、プレイリストに記述されている情報を用いて所望の映像データを取得する。プレイリスト中に複数のバージョンの映像データセグメントに対するＵＲＬを記載することで、受信装置は自身の能力や通信環境に応じて、最適なバージョンの映像データセグメントを取得することができる。

（セグメント）
次に、図２を用いて取得するセグメントの具体例について説明する。本実施形態では、低画質層（ベースレイヤ）１００１と高画質層（エンハンスメントレイヤ）１００２を有する映像データの視聴をユーザが行っている場合の例を説明する。

１００３、１００５、１００７は、時系列順に並んだ映像データの各時刻での再生された状態を示す。時刻ｉの場合、ユーザは１００３で示される低画質層の映像データを視聴している。着目領域は１００４に示される太実線で囲まれた領域（タイル番号１１）である。また、周辺領域（隣接領域）は着目領域の周辺に存在する部分領域であり、図２の例では点線で囲まれた領域（タイル７、１０、１２、１５）である。時刻ｊの場合、ユーザは１００５で示される低画質層の映像データ（タイル番号１０）を視聴している。着目領域は１００６に示される太実線で囲まれた領域（タイル番号１０）である。また周辺領域は、点線で囲まれた領域（タイル番号５、６、７、９、１１、１３、１４、１５）である。時刻ｋの場合、ユーザは１００７で示される高画質層の映像データ（タイル番号２６）を視聴している。また、周辺領域は、点線で囲まれた領域（タイル番号２１、２２、２３、２５、２７、２９、３０、３１）である。

なお、本実施形態では、着目領域が１つのタイルとなっているが、これに限定されず、複数のタイルを着目領域としてもよい。

また、本実施形態では、低画質レイヤと高画質レイヤの２つのレイヤがある例を説明するがこれに限定されない。例えば、低画質、中間画質、高画質を含む３つ以上のレイヤを有するようにしてもよい。

また、本実施形態では、低画質レイヤと高画質レイヤで領域の分割数が同じであるが、これに限定されない。例えば、低画質レイヤは２×２の４分割で、高画質レイヤは４×４の１６分割であってもよい。また、低画質レイヤは１つの領域で、高画質レイヤは複数の領域に分割されていてもよい。また、複数のレイヤがあって、それぞれのレイヤの領域が１つであってもよい。

図２を参照して説明したような、映像データを符号化する符号化形式として、ＳＶＣ、Ｌ−ＨＥＶＣなどのスケーラブル符号化方式があるが、これらの符号化方式に限定されない。ＳＶＣはScalable Video Codingの略称であり、Ｌ−ＨＥＶＣはLayered-High Efficiency Video Codingの略称である。また、レイヤが１つの場合、符号化方式としてはＨＥＶＣ（High Efficiency Video Coding）のように映像を領域分割可能なものを利用できる。

（クライアントのハードウェア構成）
図３は、クライアント１０１のハードウェア構成例を示すブロック図である。図３において、制御部２０１は、クライアント１０１における動作を統括的に制御する中央演算処理装置（ＣＰＵ）であり、システムバス２１１を介して、各構成部（２０２、２０５、２０６、２０８〜２１０）を制御する。

記憶部２０２は、各種データを記憶し管理する。記憶部２０２は、ＲＡＭ（書込み可能メモリ）、ＲＯＭ（読出し専用メモリ）、ストレージ（ハードディスク、ＳＳＤ等）により実現される。表示部２０５は、例えば、液晶パネルを有し、制御部２０１の制御下で各種表示を行う。操作部２０６は、ユーザからの操作を受け付ける。操作部２０６は、例えば、タッチパネル、ポインティング装置、キーボード等により実現される。復号化部２０８は、映像データの復号化処理を行う。通信部２０９は、無線ＬＡＮインターフェース２１０を制御し、各種通信処理を制御する。２１０は、無線ＬＡＮインターフェースである。なお、本実施形態では、無線ＬＡＮインターフェースを介して、無線ＬＡＮ通信を行っているが、これに限らず、有線ＬＡＮインターフェース、または、公衆移動体通信インターフェースを介した通信であってもよい。また、これらの通信方式に限定されず、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの他の無線方式であっても実現できる。また、これらのインターフェースを複数備えていてもよい。なお、本実施形態では、映像データを表示する表示部２０５が１つのハードウェアに含まれているが、表示部は、例えばＨＤＭＩ（登録商標）などで接続された他の装置であってもよい。操作部２０６等の他の構成要素も同様である。

（クライアントの機能構成）
図４は、クライアント１０１の機能構成例を示すブロック図である。なお、本実施形態においては、以下に示す各機能ブロックの機能は、制御部２０１（ＣＰＵ）が記憶部２０２に格納されているソフトウェアプログラム（コンピュータプログラム）を実行することにより実施される。但し、各機能ブロックに含まれる一部または全部がハードウェア化されていてもよい。

図４において、通信制御部３０１は、通信部２０９を介して通信を制御する。表示制御部３０２は、表示部２０５を介して、サーバ１０２から取得した映像データを表示する。表示制御部３０２は、セグメント解析部３０６がデコードしたセグメントを、映像データとして表示部２０５に表示させる。また、表示制御部３０２は、ユーザからの操作を受け付けるためのＵＩを表示する。操作制御部３０３は、操作部２０６を制御し、ユーザからの操作を受け付ける。記憶制御部３０４は、記憶部２０２を制御し、処理データ、または映像データ等のデータを記憶、又は削除する。

ＴＣＰ／ＩＰ通信制御部３０５は、通信部２０９を利用して、サーバ１０２との間で、ＴＣＰ／ＩＰ方式の通信制御を行う。なお、本実施形態ではＴＣＰ／ＩＰ通信を利用する例を示すが、これに限らず、ＵＤＰ（User Datagram Protocol）を利用してもよい。セグメント解析部３０６は、サーバ１０２から取得した映像データであるセグメントをデコードする。

プレイリスト解析部３０７は、サーバ１０２から取得したプレイリストを解析する。サーバ１０２が生成するプレイリストは、ＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤに従う。

プレイリストには、特定のタイミングに、特定の画質の特定の領域のセグメントを取得するためにアクセスするＵＲＬが記述されている。また、プレイリストには、各レイヤのそれぞれの領域の、ビットレート、領域の位置を示す座標、領域の幅、領域の高さなどの情報が記述されている。また、プレイリストには、レイヤの数、各レイヤの映像データ全体の幅、高さ、などの映像データ全体に関する情報が記述されていてもよい。なお、本実施形態は、それぞれのタイルの情報をＭＰＤに記述してクライアントに渡しているが、この方式に限定されない。例えば、これらのパラメータをＨＴＭＬファイルや、ｊａｖａｓｃｒｉｐｔファイルなどのファイルを解析して取得してもよい。

ＨＴＴＰ／２通信処理部３０８は、ＨＴＴＰ／２（Hyper Text Transfer Protocol Version 2）において規定されるクライアントとしての通信処理を行う。

ストリーム設定部３０９は、ストリームを制御するための設定を行う。ストリーム設定部３０９は、ＨＴＴＰ／２通信処理部３０８を介して、ストリームに、優先度を設定する。

クライアント１０１は、ストリームに優先度を設定するために、プライオリティフレームを送信する。ストリーム設定部３０９は、着目領域を取得するストリーム、周辺領域を取得するストリーム、その他の領域を取得するストリームに対して、優先度を設定することができる。ストリーム設定部３０９は、着目領域の優先度を周辺領域と同等またはそれ以上の値に設定する。例えば、着目領域を取得するストリームに優先度１６を設定し、周辺領域を取得するストリームには優先度８を設定し、その他の領域を取得するストリームに対しては優先度１を設定する。着目領域の優先度を周辺領域よりも高く大きな値に設定することで、着目領域を優先して取得するように設定できる。その結果、着目領域をスムーズに表示することができる。なお、優先度の値は本例で紹介した値に限定されない。また、複数のストリームのうち少なくとも１つに対して優先度の設定をしても良い。

本実施形態では優先度を設定する例を説明するが、これに限定されず、ストリーム間の依存関係を設定してもよい。例えば、周辺領域を取得するストリームは、着目領域を取得するためのストリームに依存するように設定する。このように設定すると、着目領域を取得するまでは、周辺領域のストリームでの送信は行われないようになる。その結果、着目領域の取得が完了するまで、周辺領域の取得に帯域が使われないので、着目領域を取得しスムーズに表示することができる。

また、ストリーム設定部３０９は、ストリーム毎に、プッシュポリシーを設定する。ＨＴＴＰ／２通信処理部３０８は、ストリーム設定部３０９が設定したプッシュポリシーをサーバに通知する。

プッシュポリシーとは、クライアントとサーバの間で、サーバのプッシュの振る舞いについて交渉を行う公知の技術である。プッシュポリシーは、Accept-Push-Policy Header Field（https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00）に詳細な記述がある。

クライアントはサーバに対して、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ”というヘッダフィールドを送信する。クライアントはこのヘッダフィールドに、クライアントにとって好ましいサーバの振る舞いを設定して送信する。サーバは、クライアントから受け取ったプッシュポリシーに対して、サーバが選択したものを“ｐｕｓｈ−ｐｏｌｉｃｙ”というヘッダフィールドに設定して送信する。本実施形態では、プッシュポリシーをストリーム毎に設定することで、より詳細なストリームの制御が可能になる。本実施形態では、クライアント１０１はＨＴＴＰリクエストにａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙというプッシュポリシーを要求するためのヘッダフィールドを使用するが、ヘッダフィールドの名前はこれに限定されない。また、ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙには、ひとつまたは複数のプッシュポリシーを含めることができる。

クライアント１０１は、サーバ１０２に対してプッシュ送信をしないように要求することができる。この場合、クライアント１０１は、“ｎｏｎｅ“というプッシュポリシーを使用する。クライアント１０１は、ＨＴＴＰのリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｎｏｎｅ”と記述することで、サーバ１０２の該当するストリームに対してプッシュを行わないように要求する。着目領域以外の領域に対してはプッシュ送信をしないように設定することで、着目領域をスムーズに取得できるようになる。

クライアント１０１は、サーバ１０２に対してＨＴＴＰリクエストのレスポンスに含まれるメタデータのみをプッシュするように要求することができる。クライアント１０１は、ＨＴＴＰ Ｈｅａｄリクエストを送信した場合のレスポンス、即ちメタデータのみをプッシュで受信できるようになる。クライアント１０１は、ＨＴＴＰのリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｈｅａｄ”と記述することで、サーバ１０２の該当するストリームに対して、メタデータのみをプッシュするように要求する。これにより、クライアント１０１は、事前にサーバ１０２がプッシュしてくるセグメントのサイズを取得することができる。これにより、クライアント１０１は、必要なネットワークの帯域をより高い精度で計算することができるようになる。更に詳細なストリームの制御を行うことができるようになる。

クライアント１０１は、サーバ１０２のデフォルトの振舞いを使用するように要求することができる。クライアント１０１は、ＨＴＴＰリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｄｅｆａｕｌｔ”と記述する。

また、クライアント１０１は、プッシュポリシーの仕組みを利用して、送信したストリームが、着目領域、周辺領域、または、それ以外であるかを設定することができる。クライアント１０１は、該当するストリームを着目領域であると設定する場合、ＨＴＴＰリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｔｉｌｅ：ｐ”と記述する。これにより、サーバ１０２は、該当するストリームがクライアント１０１の着目領域であると判断できる。そして、サーバ１０２は、着目領域を優先してプッシュ送信することが可能となる。その結果、着目領域の映像データをスムーズに取得できる可能性が高まる。

クライアント１０１は、該当するストリームを周辺領域であると要求する場合、ＨＴＴＰリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｔｉｌｅ：ｓ“と記述する。これにより、サーバ１０２は、該当するストリームがクライアント１０１の周辺領域であると判断できる。これにより、ネットワークの帯域幅に余裕がある場合に周辺領域もスムーズに取得できる可能性が高まる。周辺領域に対して、優先度（ストリームの優先度とは別）をつけてもよい。例えば着目領域が１つのタイルで、その周囲にある８つのタイルが周辺領域である場合、上下左右の４つのタイルと、斜め方向にある４つのタイルに対して異なる優先度をつけてもよい。

クライアント１０１は、該当するストリームが、着目領域でも周辺領域でもない場合、ＨＴＴＰリクエストを送信する時に、“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｔｉｌｅ：ｎ“と記述する。これにより、サーバ１０２は、該当するストリームがクライアント１０１の着目でも周辺領域でもないと判断できる。これにより、サーバ１０２は、クライアントの必要性が低い領域をプッシュしないように判断することができる。

クライアント１０１は、サーバ１０２から、要求したプッシュポリシーへの応答を受信する。ストリーム設定部３０９は、サーバ１０２から受信したプッシュポリシーを、ストリームのプッシュポリシーとして設定する。

動画情報管理部３１０は、プレイリスト解析部３０７が解析した結果を管理する。

ストリームＩＤ管理部３１１は、ＨＴＴＰ／２のストリーム識別子（ストリームＩＤ）と、映像データを構成する領域とを紐づけて管理する。ストリームＩＤ管理部３１１は、映像データを構成するレイヤ毎のそれぞれの領域について、ＨＴＴＰ／２通信処理部３０８が作成したストリームのＩＤを紐づけて記憶する。また、サーバ１０２から送信された予約要求（ＰＵＳＨ＿ＰＲＯＭＩＳＥ）に基づき、各レイヤの領域毎に、プッシュを受信するためのストリームのＩＤも記憶する。ストリームＩＤ管理部３１１の処理により、クライアント１０１が主導的にセグメントを取得するストリームと、サーバ１０２からプッシュされたセグメントを受信するためのストリームを管理することができるようになる。その結果、ストリームの細かな制御が可能になる。

ウィンドウサイズ計算部３１３は、取得するセグメントのビットレートとセグメント長をもとに、必要となるＨＴＴＰ／２ウィンドウサイズを計算する。なお、本実施形態では、ＨＴＴＰ／２上でウィンドウサイズを制御する例を説明するが、ＴＣＰウィンドウサイズを制御するようにしてもよい。

帯域取得部３１４は、クライアント１０１とサーバ１０２間のネットワークの帯域幅を取得する。帯域取得部３１４は、各種計測プロトコルを使用し、ネットワークの帯域幅を実測してもよいし、サーバ１０２との通信履歴や、セグメントの送信履歴から、帯域を計算して取得してもよい。例えば、過去に２ＭＢｙｔｅのセグメントを、２秒で取得している場合、ネットワークの帯域幅が少なくとも（２ＭＢｙｔｅ×８ｂｉｔ）÷２秒＝８Ｍｂｐｓという値を取得する。

着目領域取得部３１５は、ユーザの着目領域を取得する。クライアント１０１は、ユーザの着目領域をユーザの操作から取得する。なお、クライアント１０１がスマートフォン等の加速度センサの機能を持っている装置の場合、ユーザがスマホを傾けた位置から、着目領域を取得してもよい。なお、クライアント１０１がＨＭＤ等の装置の場合、ユーザの視点の角度、加速度センサ等の各種情報、または、これらを組み合わせて、ユーザが着目している領域を取得してもよい。

（サーバのハードウェア構成）
図５は、サーバ１０２のハードウェア構成例を示すブロック図である。図５において、制御部４０１は、サーバ１０２における動作を統括的に制御する中央演算処理装置（ＣＰＵ）であり、システムバス４１１を介して、各構成部（４０２、４０５〜４０９）を制御する。

記憶部４０２は、各種データを記憶し管理する。記憶部４０２は、ＲＡＭ（書込み可能メモリ）、ＲＯＭ（読出し専用メモリ）、ストレージ（ハードディスク、ＳＳＤ等）により実現される。表示部４０５は、例えば液晶パネルを有し、制御部４０１の制御下で各種表示を行う。操作部４０６は、ユーザからの操作を受け付ける。操作部４０６は、例えば、タッチパネル、ポインティング装置、キーボード等により実現される。撮像部４０７は、映像データの撮像を行う。符号化部４０８は、映像データの符号化処理を行う。通信部２０９は、有線ＬＡＮインターフェース４１０を制御し、各種通信処理を制御する。４１０は、有線ＬＡＮインターフェースである。なお、本実施形態では、通信制御部は有線ＬＡＮインターフェースを制御しているが、これに限らず、無線ＬＡＮインターフェース、または、公衆移動体通信インターフェースを制御して通信を行ってもよい。また、これらの通信方式に限定されず、Ｂｌｕｅｔｏｏｔｈ（登録商標）など他の通信方式であっても実現できる。なお、本実施形態では、サーバ１０２が、撮像部４０７を含んでいるが、サーバ１０２は、他の装置から映像データを取得してもよい。なお、本実施形態では、サーバ１０２が、符号化部４０８を含んでいるが、サーバ１０２は他の装置から符号化済みのデータを取得してもよい。表示部４０５、操作部４０６等の構成要素はケーブル等により接続された他の装置であってもよい。

（サーバの機能構成）
図６において、通信制御部５０１は、通信部４０９を介して通信を制御する。表示制御部５０２は、表示部４０５を介して、ユーザからの操作を受け付けるためのＵＩを表示してもよい。操作制御部５０３は、操作部４０６を制御し、ユーザからの操作を受け付ける。記憶制御部３０４は、記憶部４０２を制御し、処理データ、または映像データ等のデータを記憶、又は削除する。

ＴＣＰ／ＩＰ通信制御部５０５は、通信部４０９を利用して、クライアント１０１との間で、ＴＣＰ／ＩＰ方式の通信制御を行う。なお、本実施形態ではＴＣＰ／ＩＰ通信を利用する例を示すが、これに限らず、ＵＤＰ（User Datagram Protocol）を利用してもよい。ＨＴＴＰ／２通信処理部５０６は、ＨＴＴＰ／２（Hyper Text Transfer Protocol Version 2）において規定されるサーバとして通信処理を行う。

ストリーム設定部５０９は、クライアント１０１から受信したＨＴＴＰ／２のプライオリティフレームに基づき、ストリームに優先度を設定する。

また、ストリーム設定部５０９は、クライアント１０１から受信したＨＴＴＰリクエストに含まれるプッシュポリシーをもとに、ストリームのプッシュポリシーを設定する。

ストリーム設定部５０９は、クライアント１０１へのＨＴＴＰレスポンスに、サーバ１０２が選択したプッシュポリシーを記述する。本実施形態では、サーバ１０２は、ＨＴＴＰレスポンスにｐｕｓｈ−ｐｏｌｉｃｙというプッシュポリシーを記述するためのヘッダフィールドを使用する。本実施形態では、プッシュポリシーを使用しているが、これに限らず、ストリームに対してプッシュするかどうかを通知する方式を用いれば、本実施形態は実現可能である。

サーバ１０２は、プッシュ送信しないように、クライアント１０１に通知する。この場合、サーバ１０２は、“ｎｏｎｅ”というプッシュポリシーを使用する。サーバ１０２は、ＨＴＴＰのレスポンスを送信する時に“ｐｕｓｈ−ｐｕｌｉｃｙ：ｎｏｎｅ”と記述することで、クライアント１０１に、該当するストリームではプッシュを行わないことを通知する。

サーバ１０２は、ＨＴＴＰレスポンスのメタデータのみをプッシュするように通知する。

サーバ１０２は、ＨＴＴＰ Ｈｅａｄリクエストへのレスポンス、即ちメタデータのみをプッシュで送信する。サーバ１０２は、ＨＴＴＰレスポンスを送信する時に、“ｐｕｓｈ−ｐｕｌｉｃｙ：ｈｅａｄ”と記述することで、該当するストリームに対してメタデータのみをプッシュすることを通知する。

サーバ１０２は、クライアントからデフォルトのプッシュポリシーを使用するように通知を受けた場合、サーバが使用するプッシュポリシーを選択してクライアントに通知する。

サーバ１０２は、クライアント１０１から、着目領域を設定するプッシュポリシーを要求された場合、該当するストリームに紐づいている領域を、着目領域であると判断する。

サーバ１０２は、クライアントにＨＴＴＰレスポンスを送信する時に“ｐｕｓｈ−ｐｕｌｉｃｙ：ｔｉｌｅ：ｐ”と記述し、クライアントの要求を受け付けた応答を行う。

サーバ１０２は、クライアント１０１から、周辺領域を設定するプッシュポリシーを要求された場合、該当するストリームに紐づいている領域を周辺領域であると判断する。サーバ１０２は、クライアントにＨＴＴＰレスポンスを送信する時に“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｔｉｌｅ：ｓ”と記述し、クライアントの要求を受け付けた応答を行う。

サーバ１０２は、クライアント１０１から、該当するストリームが着目領域でも周辺領域ないという設定を行うプッシュポリシーを要求された場合、該当するストリームに紐づいている領域を、着目領域でも周辺領域でもないと判断する。サーバ１０２は、クライアントにＨＴＴＰレスポンスを送信する時に“ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ：ｔｉｌｅ：ｎ”と記述し、クライアントの要求を受け付けた応答を行う。

なお、プッシュポリシーの種類、および、記述方式は、本実施形態で紹介したものに限定されない。なお、クライアント１０１が複数のプッシュポリシーを要求してきた場合、サーバ１０２はサーバが対応しているプッシュポリシーを選択する。また、クライアント１０１が要求してきたプッシュポリシーにサーバ１０２が対応していない場合、サーバ１０２は自身が対応しているプッシュポリシーを通知してもよい。なお、サーバ１０２が、該当するストリームに対してプッシュを行わない場合、クライアントからのプッシュポリシーの要求に関わらず、“ｎｏｎｅ”を送信してもよい。なお、サーバ１０２は、クライアントからのプッシュポリシーの送信がない場合でも、自身のポリシーを通知してもよい。

着目領域取得部５１０は、クライアント１０１が着目領域として選んでいる領域を取得する。クライアント１０１がＨＴＴＰリクエストを送信してきたセグメントに対応するタイルを着目領域として取得する。なお、この方式に限らず、プッシュポリシーから、着目領域を判断してもよい。また、クライアントからのＨＴＴＰリクエストに含まれるＨＴＴＰヘッダフィールドを使用して、着目領域を取得してもよい。

動画情報管理部５１１は、プレイリスト生成部５１５が生成したプレイリストに関連する映像データを構成する領域の数、映像データのレイヤの数、映像データの幅と高さ、それぞれの領域の幅と高さ、それぞれの領域のビットレート等の各種情報を管理する。ストリームＩＤ管理部５１２は、ＨＴＴＰ／２のストリーム識別子（ストリームＩＤ）と、映像データを構成する領域とを紐づけて管理する。ストリームＩＤ管理部５１２は、サーバ１０２が送信した予約要求（ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム）に基づき、各レイヤの領域毎に、プッシュを送信するためのストリームＩＤも記憶する。帯域取得部５１３は、クライアント１０１とサーバ１０２間のネットワークの帯域幅を取得する。帯域取得部５１３は、各種計測プロトコルを使用して、ネットワークの帯域幅を実測してもよいし、クライアント１０１との通信履歴、セグメントの送信履歴から、帯域を計算して取得してもよい。セグメント生成部５１４は、符号化部４０８を介して、撮像部４０７が取得した映像データをエンコードする。そして、セグメント生成部５１４は、符号化部４０８で符号化された映像データをもとに、映像データの送信単位であるセグメントを生成する。なお、本実施形態におけるセグメントのファイルフォーマットとしてはＩＳＯＢＭＦＦ（ISO Base Media File Format）を利用するが、これに限らずＭＰＥＧ２ＴＳや、その他の方式でもよい。プレイリスト生成部５１５はセグメント生成部５１４が作成したセグメントへのアクセスを可能とするＵＲＬ（Uniform Resource Locator）を記載したプレイリストを生成する。

プレイリスト生成部５１５は、クライアントが、映像データの取得に使用するプレイリストを生成する。プレイリスト生成部５１５は、生成するプレイリストに、また、プレイリストには、各レイヤのそれぞれの領域の、ビットレート、領域の位置を示す座標、領域の幅、領域の高さなどの情報が記述されている。

また、プレイリストには、レイヤの数、各レイヤの映像データ全体の幅、高さ、などの映像データ全体に関する情報が記述されていてもよい。なお、本実施形態では、各レイヤの領域毎の情報を、プレイリストに記述しているが、これに限定されず、ＨＴＭＬファイルや、ｊａｖａｓｃｒｉｐｔファイルに記述してもよい。

（クライアントの動作）
●クライアント全体処理
次に、以上のような構成を備えた本実施形態のクライアント１０１、サーバ１０２の動作について説明する。まず、クライアント１０１によるセグメントの取得動作（全体処理）ついて、図７のフローチャートを参照しながら詳細に説明する。図７の各ステップは、クライアント１０１の制御部２０１（ＣＰＵ）の制御に基づき実行される。

本実施形態では、図２で示すような低画質、高画質のレイヤと領域をもつ映像データについて説明する。なお、領域の数は図２で示すような分割数に限定されない。例えば、２×２、２×３、４×４というように領域が分割されていてもよい。

まず、ＨＴＴＰ／２通信処理部３０８は、サーバ１０２との間に、ＨＴＴＰ／２の接続を確立する（Ｓ６０１）。

クライアント１０１は、ＨＴＴＰ／２通信処理部３０８を介して、サーバ１０２からプレイリストを取得する（Ｓ６０２）。プレイリスト解析部３０７は、取得したプレイリストを解析する（Ｓ６０３）。プレイリスト解析部３０７は、プレイリストを解析して、各レイヤの各領域に対応するビットレート、領域の位置を示す座標、領域の幅、領域の高さ等の情報を取得する。動画情報管理部３１０は、プレイリスト解析部３０７が取得した情報を記憶する。

クライアント１０１は、ＨＴＴＰ／２通信処理部３０８を介して、各レイヤの領域毎に、ＨＴＴＰ／２のストリームを作成する（Ｓ６０４）。クライアント１０１は、各レイヤの各領域に、ＨＴＴＰ／２のストリームを作成する。ストリームＩＤ管理部３１１は、各レイヤの各領域と、ストリームのＩＤを紐づけて記憶する（Ｓ６０５）。また、ストリームＩＤ管理部３１１は、サーバ１０２から、プッシュ用のストリームを予約する予約要求（ＰＵＳＨ＿ＰＲＯＭＩＳＥ）を受け取った場合、プッシュを受信するためのストリームのＩＤも、各レイヤの各領域と紐づけて記憶する。

ＨＴＴＰ／２の標準では、予約要求はクライアントが作成したストリームに関連付けられている。このため、プッシュ予約要求が関連付けられているストリームから、プッシュ受信用のストリームが、どの領域に該当するかを特定する。

図８は、ストリームＩＤ管理部３１１が管理するストリームＩＤと各レイヤの領域毎の紐づけの例を示す。図８（Ａ）は、高画質層の９個のタイルに分割された領域を表す。分割された領域には、それぞれタイル番号ａ〜ｉが割り当てられている。図８（Ｂ）の表では、図８（Ａ）のタイル分割されたそれぞれの領域に対して、ＨＴＴＰ／２のストリームＩＤを割り当てた例を示している。図８（Ｂ）のａ（１１、１２）は、タイルａに対して、クライアント１０１がセグメント取得のためにストリームＩＤ１１のストリームを作成し、サーバ１０２がプッシュでセグメントを送信するためにＩＤ１２のストリームを作成していることを示す。図８（Ｃ）は、低画質層の９個のタイルに分割された領域を表す。分割された領域には、それぞれタイル番号ｊ〜ｒが割り当てられる。図８（Ｄ）では、図８（Ｃ）のタイル分割されたそれぞれの領域に対して、ＨＴＴＰ／２のストリームＩＤを割り当てた例を示している。

なお、本実施形態では、クライアント１０１は、各レイヤの領域毎にストリームを作成しているが、これに限定されない。例えば、複数の領域に対して、１つのストリームを割り当ててもよい。図８（Ａ）の例を参照すると、タイルａ、ｂ、ｃを一つのストリームで管理してもよい。これによりクライアント１０１が管理するストリームの数が減り、処理負荷が軽減ざれる。また、１つストリームに対して、複数レイヤの同一領域を割り当ててもよい。図８の例を参照すると、タイルａとタイルｊを同じストリームに紐づけてもよい。

着目領域取得部３１５は、表示する着目領域を取得する（Ｓ６０６）。着目領域は複数のタイル領域を含んでいてもよい。また、着目領域によって指定されているタイルは、低画質（ベースレイヤ）と高画質のもの（エンハンスメントレイヤ）が混在していてもよい。

クライアント１０１は着目領域をサーバ１０２に対して通知する。クライアントは、着目領域のサーバへの通知を、ＨＴＴＰ ＧＥＴリクエストで行ってもよい。この場合、着目領域と周辺領域の区別をつけるために、周辺領域に対しては、ＨＴＴＰ ＨＥＡＤリクエストを送信する。また、クライアントは、着目領域のサーバへの通知を、ＨＴＴＰリクエストに含まれるＨＴＴＰヘッダフィールドに記述してもよい。例えば、着目領域を通知する場合、“ｓｅｔ−ｔｉｌｅ：ｐ”と記述し、周辺領域を通知する場合、“ｓｅｔ−ｔｉｌｅ：ｓ”と記述し、その他の領域を通知する場合“ｓｅｔ−ｔｉｌｅ：ｎ”と記述することで、サーバに着目領域を通知することができる。なお、これらのヘッダフィールドを使用する場合、ＨＴＴＰのＨｅａｄリクエストを送信することで、サーバ１０２からのメタデータのみを受け取ることができる。その結果、サーバ１０２との間で受信するデータの量を削減することができる。なお、クライアント１０１がサーバに対して、着目領域を通知するためのヘッダフィールドの記述方式は、本実施形態で紹介している方式に限定されない。

ストリーム設定部３０９は、ストリーム制御のための設定をＨＴＴＰ／２のストリームに対して行う（Ｓ６０７）。ストリーム設定部３０９は、Ｓ６０６により取得された着目領域が、前回取得された着目領域と変更がない場合は本処理をスキップしてもよい。

具体的には、ストリーム設定部３０９は、着目領域と周辺領域に優先度を設定する。すなわち、着目領域の画像データを通信するためのストリームの優先度が、着目領域以外の部分領域の画像データを通信するためのストリームの優先度以上となるように、複数のストリームの少なくとも１つに対して優先度を設定する。例えば着目領域のビットレートが８Ｍｂｐｓ、周辺領域のビットレートが１Ｍｂｐｓの場合、着目領域に８、周辺領域に１という優先度を設定する。その他の領域には優先度０を設定する。また、ストリーム設定部３０９は、設定した優先度をＨＴＴＰ／２通信処理部３０８を介して、ＨＴＴＰのストリームに反映させる。ストリーム設定部３０９は、着目領域と周辺領域に設定した優先度の値をＨＴＴＰ／２のストリームに対して設定する。ＨＴＴＰ／２のストリームに対する優先度は、これに限定されない。これにより、着目領域のセグメントを優先して取得できる可能性が高まる。

次に、ストリーム設定部３０９は、一つ、または、複数のストリームに対して、プッシュポリシーの要求を行う。なお、着目領域に変更がなかった場合、この処理はスキップしてもよい。また、着目領域に変更がなかった場合であっても、ストリームのプッシュポリシーの設定を変更したい場合は本処理を行ってもよい。ストリーム設定部３０９は、サーバ１０２からの応答にもとづき、各ストリームにプッシュポリシーを設定する。プッシュポリシーを設定することにより、着目領域に対するプッシュは受信し、周辺領域に対するプッシュは受信しない、といったより詳細な制御を行うことができる。

クライアント１０１は、着目領域を高画質で取得するかどうかを判断する（Ｓ６０８）。着目領域を高画質で取得するかどうかを判断する処理の詳細は、図１０を参照して後述する。クライアント１０１が、着目領域を高画質で取得すると判断した場合（Ｓ６０８でＹＥＳ）、クライアント１０１は、着目領域の高画質のセグメントの取得を開始する（Ｓ６０９）。着目領域の高画質のセグメントを取得する処理の詳細は、図１１を参照して後述する。

次に、クライアント１０１は、周辺領域を高画質で取得するかを判断する（Ｓ６１０）。着目領域を高画質で取得するかどうかを判断する処理の詳細は、図１０を参照して後述する。なお、クライアント１０１は、周辺領域に複数のタイル含まれている場合、その一部を高画質で取得し、残りを低画質で取得するよう処理してもよい。例えば、着目領域が１つのタイルでその周囲に上、下、左、右、右上、右下、左下、左上に８つのタイルがある場合、上下左右に位置するタイルは高画質で取得し、その他の４つのタイルは低画質で取得してもよい。クライアント１０１が、周辺領域を高画質で取得すると判断した場合（Ｓ６１０でＹＥＳ）、クライアント１０１は、周辺領域の高画質のセグメントの取得を開始する（Ｓ６１１）。周辺領域の高画質のセグメントを取得する処理の詳細は、図１１で後述する。表示制御部３０２は、セグメント解析部３０６がデコードしたデータを、表示部２０５に表示する（Ｓ６１２）。

なお、本実施形態では、周辺領域のセグメントの取得（Ｓ６１０、Ｓ６１１、Ｓ６１５）を行ってから、着目領域のセグメント表示処理（Ｓ６１２）を行っているが、これらは並列に行ってもよい。すなわち、クライアント１０１が着目領域をサーバから取得したら、表示制御部３０２は表示処理を行うことができる。

クライアント１０１が、周辺領域を高画質で取得しないと判断した場合（Ｓ６１０でＮＯ）、クライアント１０１は、周辺領域を低画質で取得するかどうかを判断する（Ｓ６１４）。周辺領域を低画質で取得するかどうかを判断する処理の詳細は、図１０を参照して後述する。クライアント１０１が、周辺領域を低画質で取得すると判断した場合（Ｓ６１４でＹＥＳ）、クライアント１０１は、周辺領域の低画質のセグメントを取得する（Ｓ６１５）。周辺領域の低画質のセグメントを取得する処理の詳細は、図１１を参照して後述する。そして、注目領域のセグメントを表示する（Ｓ６１２）。クライアント１０１が、周辺領域を低画質で取得しないと判断した場合（Ｓ６１４でＮＯ）、クライアント１０１は着目領域の表示を行う（Ｓ６１２）。

Ｓ６１２の処理を終えると、クライアント１０１は、映像データ取得処理を終了するかを判断する（Ｓ６１３）。クライアント１０１が、映像データ取得処理を終了すると判断した場合（Ｓ６１３でＹＥＳ）、クライアント１０１は、本フローチャートに沿った処理を終了する。クライアント１０１が、映像データ取得処理を終了しないと判断した場合（Ｓ６１３でＮＯ）、クライアント１０１は、Ｓ６０６に進む。

クライアント１０１が、着目領域を高画質で取得しないと判断した場合（Ｓ６０８でＮＯ）、クライアント１０１は、着目領域を低画質で取得するかどうかを判断する（Ｓ６１６）。クライアント１０１が、着目領域を低画質で取得するかどうかを判断する処理は、図１０を参照して後述する。クライアント１０１が、着目領域を低画質で取得すると判断した場合（Ｓ６１６でＹＥＳ）、クライアント１０１は、着目領域の低画質のセグメントを取得する（Ｓ６１７）。クライアント１０１が、着目領域の低画質のセグメントを取得する処理の詳細は、図１１を参照して後述する。そして、Ｓ６１４へ進む。

クライアント１０１が、着目領域の低画質のセグメントを取得しないと判断した場合（Ｓ６１６でＮＯ）、エラー表示を行う（Ｓ６１８）。例えば、回線の状況により映像データの取得が遅れている、といった表示を行う。そして、Ｓ６１３へ進む。

上記のように、本実施形態では、クライアント１０１は、注目領域の映像データを注目領域以外の映像データよりも優先的に受信して取得する。具体的には、本実施形態では、以下のような手法を採用している。
・着目領域の映像データを受信してから着目領域以外の部分領域の映像データを受信するようにしている。
・サーバ１０２との間のネットワークの帯域を取得（帯域取得）するとともに、映像データの部分領域のビットレートを取得（ビットレート取得）する。そして、ネットワークの帯域と部分領域のビットレートとの比較に基づいて、受信する映像データの部分領域の画質を判定して、その画質の部分領域の映像データを受信している。
・受信する映像データの部分領域の画質を判定する際には、着目領域に対して、当該着目領域以外の部分領域よりもより高い画質で受信するように判定している。
・さらに、ネットワークの帯域と部分領域のビットレートとの比較に基づいて、当該部分領域の映像データを受信するか否かを判定している。ここで、着目領域の映像データを受信してなおネットワークの帯域に余力がある場合に、着目領域以外の部分領域の映像データを受信すると判定し、余力がない場合は着目領域以外の部分領域の映像データは受信しないようにしている。

これらの手法により、クライアント１０１はネットワークの帯域が限られた場合であっても、着目領域を優先的に取得することができ、全画像のうちより重要度の高い領域をスムーズに視聴することが可能である。

●注目領域変更時の処理
図７では、Ｓ６０６の処理で、周期的にユーザからの着目領域の取得を行う処理を行っている。次に、図９では、着目領域の変更が行われた時の処理について説明する。

着目領域取得部３１５は、着目領域が現在の着目領域から変更されたことを取得する（Ｓ７０１）。クライアント１０１は、変更後の着目領域のセグメントを取得済みかどうか判断する（Ｓ７０２）。クライアント１０１が、変更後の着目領域のセグメントを取得済みと判断した場合（Ｓ７０２でＹＥＳ）、表示制御部３０２は、表示部２０５に、変更後の着目領域の映像データを表示する（Ｓ７０３）。これによりクライアント１０１は、着目領域以外の周辺領域のセグメントや、画質の異なる同一の着目領域のセグメントを取得している場合、新たなセグメントの取得をせずに、映像データの表示を行うことができる。その結果、ユーザはシームレスに映像データの視聴を行うことができる可能性が高まる。クライアント１０１が、変更後の着目領域のセグメントを取得済みではないと判断した場合（Ｓ７０２でＮＯ）、及び、Ｓ７０３の処理を終えた場合、本フローチャートによる処理を終了する。

●セグメント取得判断処理
図１０は、図７のＳ６０８，Ｓ６１０，Ｓ６１４，Ｓ６１６のそれぞれから呼び出されるフローチャートである。ここでは、図１０の呼び出し元で指定された領域を指定された画質で取得するかどうかの判断を行う。

Ｓ６０８は、着目領域を領域として指定し、高画質を画質として指定し、図１０のフローチャートを呼び出す。Ｓ６１０は、周辺領域を領域として指定し、高画質を画質として指定し、図１０のフローチャートを呼び出す。Ｓ６１４は、周辺領域を領域として指定し、低画質を画質として指定し、図１０のフローチャートを呼び出す。Ｓ６１６は、着目領域を領域として指定し、低画質を画質として指定し、図１０のフローチャートを呼び出す。

クライアント１０１は、取得の判断を行う領域のビットレートを取得する（Ｓ８０１）。クライアント１０１は、指定された領域が複数の領域である場合、複数の領域のビットレートの合計を取得する。なお、クライアント１０１はＨＴＴＰ ＨＥＡＤリクエストを送信することで、該当する領域のセグメントのサイズを取得してもよい。クライアント１０１は、取得したセグメントサイズを、セグメントの時間で除算する（割る）ことで、ビットレートを取得してもよい。また、クライアント１０１がサーバ１０２に対して、プッシュポリシー（ｐｕｓｈ−ｈｅａｄ）を送信している場合、サーバ１０２からＨｅａｄリクエストのレスポンスに含まれるファイルサイズを取得してもよい。

帯域取得部３１４は、サーバ１０２との間のネットワークの帯域を取得する（Ｓ８０２）。クライアント１０１は、他の取得中のセグメントのビットレートを取得する（Ｓ８０３）
周辺領域を取得可能か判断するために図１０のフローチャートが呼び出された場合（Ｓ６１０、Ｓ６１４）、着目領域の取得のセグメントのビットレートを取得する（Ｓ６０９、Ｓ６１７）。なお、ビットレートに限らず、取得中のファイルサイズから、ビットレートを計算して取得してもよい。

クライアント１０１は、セグメントを取得するかどうかの判断を行う（Ｓ８０４）。例えば、利用可能な通信帯域が取得するセグメントのビットレート以上の場合はセグメントを取得すると判断し、帯域がビットレートを下回る場合は取得しないと判断することができる。具体的には、例えば、取得するセグメントのビットレートが８Ｍｂｐｓで、帯域が１０Ｍｂｐｓの場合、ビットレートよりも帯域幅が大きいので、セグメントを取得すると判断する。別の例として、取得するセグメントのビットレートが８Ｍｂｐｓで、帯域が６Ｍｂｐｓの場合、ビットレートよりも帯域幅が小さいので、取得しないと判断する。

クライアント１０１がセグメントを取得すると判断した場合（Ｓ８０４でＹＥＳ）、クライアント１０１は、セグメントを取得するための前処理を行う（Ｓ８０５）。具体的には、ＨＴＴＰ／２通信処理部３０８は、ＨＴＴＰ／２のコネクションと、該当する領域と紐づけられているストリームに対して、ＨＴＴＰ／２ウィンドウアップデート（ＷＵ：WINDOW_UPDATE）フレームの送信を行う。ここで、ウィンドウアップデートフレーム（ウィンドウ更新フレーム）において、加算するウィンドウサイズの値としてセグメント長×ビットレートを記述することができるが、これに限定されない。例えば、セグメントのファイルサイズを取得している場合、そのファイルサイズの値を、そのまま加算するウィンドウサイズとして、ウィンドウアップデートフレームに記述し、送信してもよい。また、ファイルサイズよりも大きな値をウィンドウアップデートフレームに記述してもよい。例えば、ファイルサイズの２倍の値や、３倍の値などが考えられる。これにより、複数のセグメントを取得するために必要なウィンドウアップデートを一つにまとめることができる。その結果、クライアントとサーバ間のデータのやり取りを削減することができる。

また、ウィンドウアップデートフレームを送らなくても、次のセグメントを受信可能である場合、ウィンドウアップデートフレームを送信しなくてもよい。なお、当該領域に紐づけられているＨＴＴＰ／２のストリームが閉じられている場合、新たにストリームを作成してもよい。

次に、クライアント１０１は、セグメントを取得すると判断した場合の処理に進む（Ｓ８０６）。例えば、本フローがＳ６０８より呼び出された場合、Ｓ６０９に進む。

一方、Ｓ８０４で、クライアント１０１がセグメントを取得しないと判断した場合（Ｓ８０４でＮＯ）、クライアントはセグメント取得の停止処理を行う（Ｓ８０７）。当該ストリームに対するウィンドウアップデートフレームの送信を停止する。例えば、当該ストリームに対して、ＧＯＡＷＡＹフレームを送信してストリームを閉じてもよい。この結果、使用していないストリームを閉じることで、処理負荷を軽減することができる。また、サーバに対してプッシュポリシーを送信し、当該領域に対応するストリームへのプッシュを送信しないように設定してもよい。これにより、サーバ１０２からの不要なプッシュの送信を停止し、ネットワークの帯域幅を節約できる。その結果、セグメントをスムーズに取得できる可能性が高まる。

クライアント１０１は、セグメントを取得しないと判断した場合の処理へ進む（Ｓ８０８）。例えば、本フローがＳ６０８より呼び出された場合、Ｓ６１６へ進む。図１０の処理によれば、着目領域の画像データを通信するためのストリームに割り当てられるバッファ容量が、当該着目領域以外の部分領域の画像データを通信するためのストリームに割り当てられるバッファ容量以上となる。このようにウィンドウサイズを制御することにより、着目領域の画像データを着目領域以外の部分領域の画像データよりも優先的に通信することができる。

●セグメント取得処理
図１１では、セグメントの取得処理について説明する。本フローは図７のＳ６０９、Ｓ６１１、Ｓ６１５、Ｓ６１７から呼び出される。図１１では、本フローチャートの呼び出し元で指定された領域を指定された画質で取得する処理を行う。

Ｓ６０９は、着目領域を領域として指定し、高画質を画質として指定し、本フローチャートを呼び出す。Ｓ６１１は、周辺領域を領域として指定し、高画質を画質として指定し、本フローチャートを呼び出す。Ｓ６１５は、周辺領域を領域として指定し、低画質を画質として指定し、本フローチャートを呼び出す。Ｓ６１７は、着目領域を領域として指定し、低画質を画質として指定し、本フローチャートを呼び出す。

クライアント１０１は、取得対象のセグメントが、サーバからプッシュされているかを判断する（Ｓ９０１）。クライアント１０１は、取得対象のセグメントが、サーバからプッシュされていると判断した場合（Ｓ９０１でＹＥＳ）、処理は行わずに本フローを終了する。この処理の結果、クライアントは、プッシュでセグメントを受信済みの場合、新たなＨＴＴＰリクエストを送信する処理を行わなくてもよい。したがって、クライアント１０１の処理負荷とネットワークの負荷を軽減することができる。クライアント１０１は、取得対象のセグメントがサーバからプッシュされていないと判断した場合（Ｓ９０１でＮＯ）、サーバ１０２に対して、ＨＴＴＰリクエストを送信し、セグメントを要求する（Ｓ９０２）。

（サーバの動作）
●サーバ全体処理
次に、図６のような構成をサーバ１０２の動作について、図１２のフローチャートを参照しながら詳細に説明を行う。図１２の各ステップは、サーバ１０２の制御部４０１（ＣＰＵ）の制御に基づき実行される。

ＨＴＴＰ／２通信処理部５０６は、クライアント１０１との間に、ＨＴＴＰ／２の接続を確立する（Ｓ１１０１）。サーバ１０２は、プレイリスト生成部５１５によって生成されたプレイリストを、ＨＴＴＰ／２通信処理部３０８を介して送信する（Ｓ１１０２）。

ＨＴＴＰ／２通信処理部５０６はストリームを作成する（Ｓ１１１６）。クライアント１０１が、各レイヤの各領域に対してＨＴＴＰ／２のストリームを作成する。ＨＴＴＰ／２通信処理部５０６は、サーバからプッシュ送信を行うためのストリームを作成する。サーバ１０２は、クライアント１０１が作成した一部、または、全部のストリームに対して、プッシュ用のストリームを予約する予約要求（ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム）を送信する。

なお、サーバ１０２が予約要求を出すストリームは、クライアント１０１のタイルに紐づけられているストリームと１対１対応でなくてもよい。例えば、クライアント１０１は各領域に対してストリームを作成するが、サーバ１０２はプッシュ用のストリームを１つだけ作成してもよい。これにより、サーバ１０２はストリーム数を削減し、処理負荷を軽減することができる。また、サーバ１０２は着目領域のセグメントをプッシュするストリームと、周辺領域のセグメントをプッシュするストリームを作成してもよい。これによりサーバ１０２はストリーム数を削減し、処理負荷を軽減することができる。また、サーバ１０２は、全ての領域に対するプッシュ用のストリームを作成しなくてもよい。プッシュ用のストリームを作成しなくてもよい。例えば、クライアント１０１から取得した着目領域と周辺領域のみに対してストリームを作成してもよい。これにより、サーバ１０２はストリーム数を削減し、処理負荷を軽減することができる。

ストリームＩＤ管理部５１２は、各レイヤの各領域と、ストリームのＩＤを紐づけて記憶する（Ｓ１１０３）。ストリームＩＤ管理部５１２は、サーバ１０２がプッシュ予約要求を送信して予約しているストリームＩＤについても、各レイヤの各領域と紐づけて記憶する。ストリームＩＤ管理部５１２の処理により、クライアント１０１が主導的にセグメントを取得するストリームと、サーバからプッシュされたセグメントを受信するためのストリームを別々に管理し制御可能になる。その結果、ストリームの細かな制御が可能になる。

着目領域取得部５１０は、クライアント１０１が着目している領域を取得する（Ｓ１１０４）。すなわち、画像データに対応する画像における着目領域の指定をクライアント１０１から受け付ける受付処理を行う。具体的には、着目領域取得部５１０は、クライアント１０１がＨＴＴＰのＧＥＴリクエストを送ってきたストリームに紐づいている領域を着目領域とする。これに限らず、サーバ１０２は別の方式でクライアント１０１が着目領域を取得することができる。例えば、サーバ１０２は、ＨＴＴＰヘッダフィールドの値から着目領域を取得してもよい。例えば、サーバ１０２は、クライアント１０１から、“ｓｅｔ−ｔｉｌｅ：ｐ”と書かれたヘッダフィールドを含むＨＴＴＰリクエストを受け取った場合、このストリームに紐づけられている領域を着目領域と判断する。サーバ１０２は、クライアント１０１から、“ｓｅｔ−ｔｉｌｅ：ｓ”と書かれたヘッダフィールドを含むＨＴＴＰリクエストを受け取った場合、このストリームに紐づけられている領域を周辺領域と判断する。サーバ１０２は、クライアント１０１から、“ｓｅｔ−ｔｉｌｅ：ｎ”と書かれたヘッダフィールドを含むＨＴＴＰリクエストを受け取った場合、このストリームに紐づけられている領域を着目領域でも周辺領域でもないと判断する。なお、クライアント１０１がサーバに対して、着目領域を通知するためのヘッダフィールドの記述方式は、本実施形態で紹介している方式に限定されない。

ストリーム設定部５０９は、ストリーム制御の設定をＨＴＴＰ／２のストリームに対して行う（Ｓ１１０５）。ストリーム設定部５０９は、クライアントから優先度を設定するためのプライオリティフレームが送信されてきた場合、その値に基づき、ストリームのプライオリティを設定する。

また、ストリーム設定部５０９は、クライアント１０１からプッシュポリシーを受け取った場合、該当するストリームに対してプッシュポリシーを設定する。サーバ１０２は設定したプッシュポリシーをクライアントに通知する、これにより、サーバ１０２は、それぞれのストリームに対してプッシュポリシーを設定することができる。この結果、サーバ１０２は、ストリームに対して、細かなプッシュ送信の制御を設定することができる。

サーバ１０２は、ネットワークの帯域に、着目領域を高画質で送信する余裕があるかを判断する（Ｓ１１０６）。具体的には、帯域取得部５１３は、クライアント１０１との間のネットワークの帯域幅を取得する。サーバ１０２は、着目領域の高画質のセグメントのビットレートを取得する。サーバ１０２は、指定された領域が複数のタイルである場合、複数のタイルのビットレートの合計を取得する。サーバ１０２は、着目領域の高画質のセグメントのサイズとセグメントの再生時間からビットレートを計算してもよい。

サーバ１０２は、ネットワークの帯域幅と、セグメントのビットレートを比較する。帯域取得部５１３で取得した帯域幅が、セグメントのビットレート以上の場合、サーバ１０２は、高画質で送信する余裕がある（Ｓ１１０６でＹＥＳ）と判断する。帯域取得部５１３で取得した帯域幅が、セグメントのビットレートよりも小さい場合、サーバ１０２は送信する余裕がない（Ｓ１１０６でＮＯ）と判断する。

例えば、セグメントのビットレートが８Ｍｂｐｓで、帯域が１０Ｍｂｐｓの場合、ビットレートよりも帯域幅が大きいので、セグメントを送信する余裕がある（Ｓ１１０６でＹＥＳ）と判断する。別の例として、セグメントのビットレートが８Ｍｂｐｓで、帯域が６Ｍｂｐｓの場合、ビットレートよりも帯域幅が小さいので、送信する余裕がない（Ｓ１１０６でＮＯ）と判断する。Ｓ１１０６の処理の詳細は、図１３を参照して後述する。

サーバ１０２が、Ｓ１１０６でＹＥＳと判断した場合、サーバ１０２は、クライアント１０１へ、着目領域の高画質のセグメントをプッシュで送信する（Ｓ１１０７）。Ｓ１１０７の処理の詳細は、図１４を参照して後述する。

サーバ１０２は、ネットワークの帯域に、周辺領域を高画質で送信する余裕があるかを判断する（Ｓ１１０８）。具体的には、帯域取得部５１３は、クライアント１０１との間のネットワークの帯域幅を取得する。サーバ１０２は、送信中または送信予定の着目領域のセグメントが存在する場合、そのビットレートも取得する。サーバ１０２は、周辺領域の高画質のセグメントのビットレートを取得する。サーバ１０２は、帯域幅と、着目領域と周辺領域のセグメントのビットレートの和を比較する。サーバ１０２は、帯域幅が、着目領域と周辺領域のセグメントのビットレートの和以上の場合、高画質で送信する余裕がある（Ｓ１１０８でＹＥＳ）と判断する。サーバ１０２は、帯域幅が、着目領域と周辺領域のセグメントのビットレートの和より小さい場合、送信する余裕がない（Ｓ１１０８でＮＯ）と判断する。周辺領域を高画質で送信するかどうかを判断する処理の詳細は図１３を参照して後述する。なお、サーバ１０２は、周辺領域に複数の領域が含まれている場合、その一部を高画質で送信し、残りを低画質で送信してもよい。例えば、着目領域が１つのタイルである場合、そのタイルの上下左右に位置するタイルは高画質で送信する。そして、右上、右下、左下、左上にある４つのタイルは低画質で送信してもよい。

サーバ１０２が、Ｓ１１０８で送信する余裕がある（Ｓ１１０８でＹＥＳ）と判断した場合、サーバ１０２は、クライアント１０１に、周辺領域の高画質のセグメントをプッシュで送信する（Ｓ１１０９）。Ｓ１１０９の処理の詳細は、図１４を参照して後述する。

サーバ１０２は、Ｓ１１０８で送信する余裕がない（Ｓ１１０８でＮＯ）と判断した場合、サーバ１０２はネットワークの帯域に、周辺領域を低画質で送信する余裕があるかを判断する（Ｓ１１１１）。具体的には、帯域取得部５１３は、クライアント１０１との間のネットワークの帯域幅を取得する。サーバ１０２は、送信中、または送信予定の着目領域のセグメントが存在する場合、そのビットレートも取得する。サーバ１０２は、周辺領域の低画質のセグメントのビットレートを取得する。サーバ１０２は、帯域幅と、着目領域と周辺領域のセグメントのビットレートの和を比較する。サーバ１０２は、帯域幅が、着目領域と周辺領域のセグメントのビットレートの和以上の場合、低画質で送信する余裕がある（Ｓ１１１１でＹＥＳ）と判断する。サーバ１０２は、帯域幅が、着目領域と周辺領域のセグメントのビットレートの和より小さい場合、送信する余裕がない（Ｓ１１１１でＮＯ）と判断する。周辺領域を低画質で送信するかどうかを判断する処理の詳細は図１３を参照して後述する。

サーバ１０２が、周辺領域を低画質で送信すると判断した場合（Ｓ１１１１でＹＥＳ）、サーバ１０２は、クライアント１０１へ、周辺領域の低画質のセグメントをプッシュで送信する（Ｓ１１１２）。

サーバ１０２が、Ｓ１１０６で注目領域を高画質で送信する余裕がない（Ｓ１１０６でＮＯ）と判断した場合、サーバ１０２は、ネットワークに帯域に、着目領域を低画質で送信する余裕があるかを判断する（Ｓ１１１３）。具体的には、帯域取得部５１３は、クライアント１０１との間のネットワークの帯域幅を取得する。サーバ１０２は、着目領域の低画質のセグメントのビットレートを取得する。サーバ１０２は、ネットワークの帯域幅と、着目領域のセグメントのビットレートを比較する。帯域取得部５１３で取得した帯域幅が、セグメントのビットレート以上の場合、サーバ１０２は、Ｓ１１１３でＹＥＳと判断する。帯域取得部５１３で取得した帯域幅が、セグメントのビットレートよりも小さい場合、サーバ１０２は低画質で送信する余裕がない（Ｓ１１１３でＮＯ）と判断する。Ｓ１１０６の処理の詳細は図１３を参照して後述する。

サーバ１０２が、着目領域を低画質で送信する余裕があると判断した場合（Ｓ１１１３でＹＥＳ）、サーバ１０２は、クライアント１０１に、着目領域の低画質のセグメントをプッシュで送信する（Ｓ１１１４）。Ｓ１１１４の処理の詳細は、図１４を参照して後述する。

上記処理を終えると、サーバ１０２は図１２のフローを終了するかを判断する（Ｓ１１１０）。終了する場合（Ｓ１１１０でＹＥＳ）はフローを終了し、終了しない場合（Ｓ１１１０でＮＯ）はＳ１１０４に戻る。

●セグメント送信判断処理
図１３は、図１２のＳ１１０６、Ｓ１１０８、Ｓ１１１１、Ｓ１１１３から呼び出されるフローチャートである。図１３では、図１３の呼び出し元で指定された領域を指定された画質で送信するかどうかの判断を行う。

Ｓ１１０６は、着目領域を領域として指定し、高画質を画質として指定し、図１３のフローチャートを呼び出す。Ｓ１１０８は、周辺領域を領域として指定し、高画質を画質として指定し、図１３のフローチャートを呼び出す。Ｓ１１１１は、周辺領域を領域として指定し、低画質を画質として指定し、図１３のフローチャートを呼び出す。Ｓ１１１３は、着目領域を領域として指定し、低画質を画質として指定し、図１３のフローチャートを呼び出す。

サーバ１０２は、指定されたレイヤの指定された領域のセグメントのビットレートを取得する（Ｓ１２０１）。サーバ１０２は、指定された領域が複数のタイルである場合、複数のタイルのビットレートの合計を取得する。サーバ１０２は、指定された領域の指定されたセグメントのサイズと、セグメントの再生時間から、ビットレートを計算してもよい。

帯域取得部５１３は、クライアント１０１との間のネットワークの帯域を取得する（Ｓ１２０２）。帯域取得部５１３は、ネットワークの帯域を計測する既存の手法を使用して帯域を取得してもよいし、クライアント１０１に過去の送信履歴から、帯域の値を計算して取得してもよい。

サーバ１０２は、他に送信中のセグメントがあれば、そのセグメントのファイルサイズを取得する（Ｓ１２０３）。例えば、周辺領域が指定されて図１３のフローチャートが呼び出された場合（Ｓ１１０８、Ｓ１１１３）、着目領域のセグメントのビットレートを取得する（Ｓ１２０３）
サーバ１０２は、セグメントを送信するかどうかの判断を行う（Ｓ１２０４）。例えば、帯域幅が送信するセグメントのビットレート以上の場合（Ｓ１２０４でＹＥＳ）はセグメントを送信すると判断し、帯域幅がビットレートを下回る場合（Ｓ１２０４でＮＯ）はセグメントを送信しないと判断する。具体的には、例えば、送信するセグメントのビットレートが８Ｍｂｐｓで、帯域が１０Ｍｂｐｓの場合、ビットレートよりも帯域幅が大きいので、セグメントを送信すると判断する。別の例として、送信するセグメントのビットレートが８Ｍｂｐｓで、帯域が６Ｍｂｐｓの場合、ビットレートよりも帯域幅が小さいので、送信しないと判断する。

サーバ１０２は、セグメントの送信をする場合の処理に進む（Ｓ１２０６）。例えば、本フローがＳ１１０６から呼び出された場合はＳ１１０７に進む。サーバは、セグメントの送信をしない場合の処理に進む（Ｓ１２０８）。例えば、本フローがＳ１１０６から呼び出された場合はＳ１１１３に進む。

●セグメント送信処理
図１４では、セグメントの送信処理について説明する。図１４では、図１４の呼び出し元で指定された領域を指定された画質で送信する処理を行う。

Ｓ１１０７は、着目領域を領域として指定し、高画質を画質として指定し、図１４のフローチャートを呼び出す。Ｓ１１０９は、周辺領域を領域として指定し、高画質を画質として指定し、図１４のフローチャートを呼び出す。Ｓ１１１２は、周辺領域を領域として指定し、低画質を画質として指定し、図１４のフローチャートを呼び出す。Ｓ１１１３は、着目領域を領域として指定し、低画質を画質として指定し、図１４のフローチャートを呼び出す。

サーバ１０２は、クライアントからセグメントの送信要求として、ＨＴＴＰリクエストを受信しているかを判断する（Ｓ１３０１）。サーバ１０２が、クライアントからＨＴＴＰリクエストを受信していないと判断した場合（Ｓ１３０１でＹＥＳ）、ＨＴＴＰリクエストで要求されたセグメントを、ＨＴＴＰレスポンスとして送信する（Ｓ１３０２）。

サーバ１０２が、クライアントからＨＴＴＰリクエストを受信していないと判断した場合（Ｓ１３０１でＮＯ）、Ｓ１３０４へ進む。Ｓ１３０４において、サーバ１０２は、指定された領域の指定された画質のセグメントと紐づけられているプッシュ用のストリームでプッシュが可能かを判断する。例えば、サーバ１０２とクライアント１０１の間で確立したＨＴＴＰ／２の接続がプッシュを送信できないように設定されている場合に、該当するストリームではプッシュ送信ができないと判断する。また、該当ストリームのプッシュポリシーとして、プッシュを送信しない設定がされている場合も、該当するストリームではプッシュできないと判断する。

サーバ１０２が、該当するストリームがプッシュ送信可能であると判断した場合（Ｓ１３０４でＹＥＳ）、サーバ１０２は、指定された領域の指定された画質のセグメントをプッシュで送信する（Ｓ１３０５）。サーバ１０２が、該当するストリームがプッシュ送信可能でないと判断した場合（Ｓ１３０４でＮＯ）、サーバ１０２は、クライアント１０１から、ＨＴＴＰリクエストを受信する（Ｓ１３０６）。

なお、本実施形態では、低画質と高画質の２つのレイヤがある場合について説明したが、これに限らず、領域分割された一つのレイヤであっても本実施形態を適用できる。その場合、クライアント１０１は図７のフローチャートのＳ６１６、Ｓ６１７、Ｓ６１４、Ｓ６１５などの低画質のセグメントに関連する処理をスキップすることで実現できる。サーバ１０２は図１２のＳ１１１１、Ｓ１１１２、Ｓ１１１３、Ｓ１１１４の低画質のセグメントに関連する処理をスキップすることで実現できる。

以上説明したように、本実施形態によれば、クライアント１０１は、論理的なストリームを用いて、着目領域と周辺領域の取得を制御する。具体的には、クライアント１０１は、サーバ１０２との間で、論理的な通信路である複数のストリームを確立し、映像データに対応する映像における着目領域を指定する。さらに、着目領域の映像データを受信するためのストリームと、着目領域以外の部分領域の映像データを受信するためのストリームとが異なるストリームとなるように、着目領域と着目領域以外の部分領域の映像データを受信するためのストリームを決定する。そして、決定したストリームをサーバ１０２へ通知する。サーバ１０２は、クライアント１０１から通知されたストリームを用いて、映像データをクライアント１０１へ送信する。ここで、サーバ１０２は、着目領域の映像データを優先的にクライアント１０１へ送信する。これにより、ネットワークの帯域を消費しないように、より詳細な制御が可能となり、その結果、ユーザが着目している領域の映像をシームレスに切り替えることができるようになる。したがって、画像データの領域ごとにストリームを確立し、着目領域を優先的に送受信することで、帯域が限られていても映像を可能な限りスムーズに視聴可能とすることが可能となる。

＜実施形態２＞
実施形態２には、サーバ１０２がクライアント１０１に対して、着目領域の変更を通知する例を説明する。本実施形態は、実施形態１との相違点を中心に説明し、実施形態１との共通する内容については説明を省略する。

（クライアントの動作）
図１５は、実施形態２に係るクライアント１０１のフローチャートである。図１５の各ステップは、クライアント１０１の制御部２０１（ＣＰＵ）の制御に基づき実行される。ここでは、図７との差分を説明する。

Ｓ１５０１〜Ｓ１５０５の処理は図７のＳ６０１〜Ｓ６０５と同様である。Ｓ６０５の処理を終えると、Ｓ１５１９で、クライアント１０１は、サーバ１０２から着目領域の変更通知を受信しているかを判断する（Ｓ１５１９）。クライアント１０１は、サーバ１０２からプッシュで着目領域の変更通知を受信する。クライアント１０１は、新しい着目領域に対応する変更通知を受信したストリームのＩＤと紐づけられている領域から、新しい着目領域を判断する。注目領域の変更通知を受信している場合（Ｓ１５１９でＹＥＳ）はＳ１５０７へ進み、受信していない場合（Ｓ１５１９でＮＯ）はＳ１５２０へ進む。

クライアント１０１は、新しい着目領域に対応するセグメントを受信済みの場合、Ｓ１５０７以下の処理により表示部２０５に新しい着目領域のセグメントを即時に表示することができる。また、クライアント１０１が着目領域のセグメントを受信する場合、クライアントは表示部２０５に受信した新しい着目領域のセグメントを、即時に表示することができる。これにより、ユーザはシームレスに視聴している領域を切り替えることができる可能性が高まる。

なお、注目領域の変更通知を受信していない場合（Ｓ１５１９でＮＯ）、クライアント１０１は、着目領域の変更通知を受信するためのストリームを作成してもよい。クライアント１０１は、表示部２０５に表示する映像データを、新しい着目領域に切り替える（Ｓ１５２０）。Ｓ１５０７〜Ｓ１５１８の処理は図７のＳ６０７〜Ｓ６１８と同様である。

上記のように、クライアント１０１は、サーバ１０２から着目領域の変更の通知を受信したことに応じて、着目領域の指定を更新する。このため、画像データの被写体が画像データにおいて占める位置の変化等に応じて、着目領域を更新して、より重要性の高い領域を優先的に視聴することが可能となる。

（サーバの動作）
図１６は、実施形態２に係るサーバ１０２のフローチャートである。図１６の各ステップは、サーバ１０２の制御部４０１（ＣＰＵ）の制御に基づき実行される。図１２との差分を説明する。

Ｓ１６０１、Ｓ１６０２、Ｓ１６１６、Ｓ１６０３の処理は図１２のＳ１１０１、Ｓ１１０２、Ｓ１１１６、Ｓ１１０３と同様である。Ｓ１１０３の処理を終えると、サーバ１０２は、着目領域を変更するかを判断する（Ｓ１６１７）。

ここで、着目領域を変更する判断を行う方式の例を説明するが、この方式に限定されない。サーバ１０２は、図１７で示すように、映像データ上の着目領域Ｓ１７０１にいる人物が、別の領域Ｓ１７０２に移動した場合に、着目領域を変更すると判断する（Ｓ１６１７でＹＥＳ）。サーバ１０２は、監視対象の人物の情報をクライアント１０１から受け取って、該当する人物が映っている領域を着目領域としてもよいし、映像データの解析を行い、不審な人物が映っている領域を、着目領域としてもよい。

注目領域を変更すると判断した場合（Ｓ１６１７でＹＥＳ）、サーバ１０２は、クライアント１０１に着目領域の変更を通知する（Ｓ１６１８）。サーバ１０２は、クライアント１０１は変更後の着目領域に紐づけられているプッシュ用のストリームを使用して、新しい着目領域を通知する。これにより、クライアント１０１は、着目領域の変更を受信したストリームのＩＤから、新しい着目領域を決定することができる。クライアント１０１は、着目領域の変更通知を送信するためのストリームを作成してもよい。クライアント１０１は、変更後の着目領域を示すＵＲＬを通知してもよいし、変更後の着目領域のセグメントを送信してもよい。サーバ１０２は、クライアント１０１に変更後の着目領域のセグメントを送信している場合は新しい着目領域の識別子だけ通知し、変更後の着目領域のセグメントを送信していない場合は、セグメントを送信してもよい。これにより、既に変更後の着目領域のセグメントを送信している場合は、セグメントを送る必要がなくなり、ネットワークの処理負荷を軽減できる。

上記のように、サーバ１０２は、画像データの被写体が画像データにおいて占める位置の変化に応じて着目領域の変更を検出し、着目領域の変更をクライアント１０１に通知する。その結果、クライアント１０１は着目領域をシームレスに切り替えることができる。 以上のように、本発明の各実施形態においては、映像データの領域と論理的ストリームを紐づけることで、詳細な取得制御を行う。このため、着目領域とその周辺領域の映像データを送信対象とする場合において、着目領域の映像データの遅れを低減できる。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１：クライアント、３０８：ＨＴＴＰ／２通信処理部、３０９：ストリーム設定部、３１０：動画情報管理部、３１１：ストリームＩＤ管理部、３１５：着目領域取得部、１０２：サーバ、５０６：ＨＴＴＰ／２通信処理部、５０９：ストリーム設定部、５１０：着目領域取得部、５１１：動画情報管理部、５１２：ストリームＩＤ管理部

Claims (10)

1. 複数の部分領域に空間的に分割された画像データをサーバ装置から受信する情報処理装置であって、
   前記画像データに対応する画像における着目領域を指定する指定手段と、
   前記サーバ装置との間で、論理的な通信路であるコネクションを確立すると共に、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームと、が異なるストリームとなるように、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームとを含む複数のストリームを、前記サーバ装置との間の前記コネクションに基づく複数のストリームとして確立する確立手段と、
   前記着目領域の画像データが前記部分領域よりも優先的に取得されるように前記複数のストリームを制御する制御手段と、
   前記制御手段により制御された前記複数のストリームを用いて前記サーバ装置からプッシュ通信により画像データを受信する受信手段と、
   前記サーバ装置との間のネットワークの帯域を取得する帯域取得手段と、
   前記サーバ装置に対してメタデータのみをプッシュするように要求することにより前記画像データの部分領域のビットレートを取得するビットレート取得手段と、
   前記ネットワークの帯域と前記部分領域のビットレートとの比較に基づいて、受信する前記画像データの部分領域の画質を判定する判定手段と
   を備え、
   前記受信手段は、前記判定手段により判定された画質の部分領域の画像データを受信することを特徴とする情報処理装置。
2. 前記受信手段は、前記着目領域の画像データを受信してから前記着目領域以外の部分領域の画像データを受信することを特徴とする請求項１に記載の情報処理装置。
3. 前記判定手段は、前記着目領域に対して、当該着目領域以外の部分領域よりもより高い画質を判定することを特徴とする請求項１に記載の情報処理装置。
4. 前記判定手段は、前記ネットワークの帯域と前記部分領域のビットレートとの比較に基づいて、当該部分領域の画像データを受信するか否かを判定することを特徴とする請求項１又は３に記載の情報処理装置。
5. 前記判定手段は、前記着目領域の画像データを受信してなお前記ネットワークの帯域に余力がある場合に、該着目領域以外の部分領域の画像データを受信すると判定することを特徴とする請求項４に記載の情報処理装置。
6. 前記指定手段は、前記サーバ装置が提供する画像データの空間的な分割構成を示すプレイリストに基づき前記着目領域を指定する
   ことを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記制御手段は、前記着目領域の画像データを通信するためのストリームの優先度が、前記着目領域以外の部分領域の画像データを通信するためのストリームの優先度以上となるように、前記複数のストリームの少なくとも１つに対して優先度を設定することを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 前記制御手段は、前記着目領域の画像データを通信するためのストリームに割り当てられるバッファ容量が、前記部分領域の画像データを通信するためのストリームに割り当てられるバッファ容量以上となるように、前記複数のストリームに対して割り当てるウィンドウサイズを制御することを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
9. 複数の部分領域に空間的に分割された画像データをサーバ装置から受信する情報処理装置の制御方法であって、
   前記画像データに対応する画像における着目領域を決定し、
   前記サーバ装置との間で、論理的な通信路であるコネクションを確立すると共に、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームと、が異なるストリームとなるように、前記着目領域の画像データを受信するためのストリームと、前記着目領域以外の部分領域の画像データを受信するためのストリームとを含む複数のストリームを、前記サーバ装置との間の前記コネクションに基づく複数のストリームとして確立し、
   前記着目領域の画像データが前記部分領域よりも優先的に取得されるように制御された前記複数のストリームを用いて前記サーバ装置からプッシュ通信により画像データを受信し、
   前記サーバ装置との間のネットワークの帯域を取得し、
   前記サーバ装置に対してメタデータのみをプッシュするように要求することにより前記画像データの部分領域のビットレートを取得し、
   前記ネットワークの帯域と前記部分領域のビットレートとの比較に基づいて、受信する前記画像データの部分領域の画質を判定し、
   前記判定により判定された画質の部分領域の画像データを受信することを特徴とする情報処理装置の制御方法。
10. コンピュータを請求項１から８のいずれか１項に記載の情報処理装置が備える各手段として機能させるためのコンピュータプログラム。

Images