JP6002191B2 - 全周動画配信システム、全周動画配信方法、通信端末装置およびそれらの制御方法と制御プログラム - Google Patents

Description

本発明は、全周カメラで取得した全周動画の配信を可能とする技術に関する。

上記技術分野において、特許文献１には、複数のカメラからなる全周カメラで撮影した映像に基づいて、全周ビデオを生成するための技術が開示されている。また、特許文献２には、１つの撮像センサからなる全周カメラから全周動画を再生するための技術が開示されている。

特開２０１２−１８９５５１号公報 特開２００４−０１２７１７号公報

しかしながら、上記文献に記載の技術では、ユーザが追跡操作することなく全周動画から追跡対象物を見付けて視聴することができなかった。

本発明の目的は、上述の課題を解決する技術を提供することにある。

上記目的を達成するため、本発明に係る通信端末装置は、
ユーザによる追跡対象物の指示を受け付ける受付手段と、
全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信手段と、
前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生手段と、
を備え、
前記全周動画データ受信手段は、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択手段を備える。

上記目的を達成するため、本発明に係る通信端末装置の制御方法は、
通信端末装置の受付手段が、ユーザによる追跡対象物の指示を受け付ける受付ステップと、
前記通信端末装置の全周動画データ受信手段が、全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信ステップと、
前記通信端末装置の全周動画再生手段が、前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生ステップと、
を含み、
前記全周動画データ受信ステップは、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択ステップを含む。

上記目的を達成するため、本発明に係る通信端末装置の制御プログラムは、
ユーザによる追跡対象物の指示を受け付ける受付ステップと、
全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信ステップと、
前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生ステップと、
を通信端末装置が有するコンピュータに実行させる通信端末装置の制御プログラムであって、
前記全周動画データ受信ステップは、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択ステップを含む。

上記目的を達成するため、本発明に係る全周動画配信システムは、
少なくとも２つの全周カメラと、
前記全周カメラで撮影された全周動画を取得して時系列の全周フレーム画像データを生成する全周画像生成手段と、
前記時系列の全周フレーム画像データに対して符号化を行なって全周動画データを生成する全周動画データ生成手段と、
前記少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する第１選択手段と、
前記全周動画データを再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択する第２選択手段と、
前記追跡対象物を含む動画映像を表示する動画再生手段と、
を備える。

上記目的を達成するため、本発明に係る全周動画配信方法は、
全周画像生成手段が、全周カメラで撮影された全周動画を取得して時系列の全周フレーム画像データを生成する全周画像生成ステップと、
全周動画データ生成手段が、前記時系列の全周フレーム画像データに対して符号化を行なって全周動画データを生成する全周動画データ生成ステップと、
第１選択手段が、前記少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する第１選択ステップと、
第２選択手段が、前記全周動画データを再生し、再生された前記全周動画から、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択する第２選択ステップと、
動画再生手段が、前記追跡対象物を含む動画映像を表示する動画再生ステップと、
を含む。

本発明によれば、ユーザが追跡操作することなく全周動画から追跡対象物を見付けて視聴することができる。

本発明の第１実施形態に係る全周動画ライブ配信システムの構成を示すブロック図である。 本発明の第２実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第２実施形態に係る全周動画ライブ配信システムの動作の概要を示す図である。 本発明の第２実施形態に係る全周動画ライブ配信システムの構成を示すブロック図である。 本発明の第２実施形態に係る全周動画ライブ配信システムの動作例を示す図である。 本発明の第２実施形態に係る全周動画ライブ配信システムの動作手順を示すシーケンス図である。 本発明の第２実施形態に係る全周カメラの機能構成を示すブロック図である。 本発明の第２実施形態に係る全周カメラの構造例を説明する図である。 本発明の第２実施形態に係る全周カメラのデータ構成を示す図である。 本発明の第２実施形態に係る撮影配信用ＰＣの機能構成を示すブロック図である。 本発明の第２実施形態に係る撮影配信用ＰＣの映像データ構成を示す図である。 本発明の第２実施形態に係る撮影配信用ＰＣの音声データ構成を示す図である。 本発明の第２実施形態に係る撮影配信用ＰＣのライブ配信用データ形式およびライブ配信用データを示す図である。 本発明の第２実施形態に係るライブ映像配信サーバの機能構成を示すブロック図である。 本発明の第２実施形態に係るライブ映像配信サーバへのＵＲＬの構成例およびデータ変換例を示す図である。 本発明の第２実施形態に係る通信端末の機能構成を示すブロック図である。 本発明の第２実施形態に係る通信端末における全周ライブ映像の展開を説明する図である。 本発明の第２実施形態に係る通信端末の全周動画のライブ再生用情報、映像データ構成および音声データ構成を示す図である。 本発明の第２実施形態に係る撮影配信用ＰＣのハードウェア構成を示すブロック図である。 本発明の第２実施形態に係る撮影配信用ＰＣの処理手順を示すフローチャートである。 本発明の第２実施形態に係るライブ映像配信サーバのハードウェア構成を示すブロック図である。 本発明の第２実施形態に係るライブ映像配信サーバの処理手順を示すフローチャートである。 本発明の第２実施形態に係る通信端末のハードウェア構成を示すブロック図である。 本発明の第２実施形態に係る通信端末の処理手順を示すフローチャートである。 本発明の第２実施形態に係る全周動画ライブ再生プレーヤの処理手順を示すフローチャートである。 本発明の第３実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第３実施形態に係る通信端末の処理データの構成を示す図である。 本発明の第３実施形態に係る全周動画ライブ再生プレーヤの処理手順を示すフローチャートである。 本発明の第４実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第４実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第４実施形態に係る通信端末の処理データの構成を示す図である。 本発明の第４実施形態に係る全周動画ライブ再生プレーヤの処理手順を示すフローチャートである。 本発明の第５実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第５実施形態に係る通信端末の処理データの構成を示す図である。 本発明の第５実施形態に係る全周動画ライブ再生プレーヤの処理手順を示すフローチャートである。 本発明の第６実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第６実施形態に係る全周動画ライブ配信システムの動作の概要を示す図である。 本発明の第６実施形態に係る通信端末の処理データの構成を示す図である。 本発明の第６実施形態に係る全周動画ライブ再生プレーヤの処理手順を示すフローチャートである。 本発明の第７実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。 本発明の第７実施形態に係るテレビ局における処理データの変換を示す図である。 本発明の第８実施形態に係る全周動画ライブ配信システムの処理の概要を示す図である。

以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。

本明細書において、「データ」は、装置間の通信用に処理をされていない生の情報を示し、例えば、「映像データ」は、カメラで撮像してデジタル量子化し、画素処理や画像処理、あるいはベクトル化などをした映像の情報である。また、「音声データ」は、マイクで集音してデジタル量子化し、音声処理、あるいはベクトル化などをした音声の情報である。そして、「動画データ」は、「映像データ」と「音声データ」を時系列に同期して含む動画の情報である。また、「メッセージ」は、これら「データ」を装置間で通信するために、装置間の通信を規定する所望のプロトコルが許容する所定のフォーマット化（通信元／通信先を含むヘッダと通信するデータ、必要であれば、圧縮符号化や暗号化を含む）を施した情報である。なお、本明細書における「メッセージ」は、１つのまとまった映像コンテンツや画像あるいは動画コンテンツを表現する、いわゆる「ファイル」とは異なり、ライブ配信を提供するための断片的な実時間のデータをフォーマット化した情報を示す。また、「全周カメラ」「全周動画」「全周フレーム」などで使用する「全周」は、視点（撮像位置）を囲む全域を表わす。

［第１実施形態］
本発明の第１実施形態としての情報処理装置１００について、図１を用いて説明する。情報処理装置１００は、全周動画をライブ再生する装置である。

図１に示すように、情報処理装置１００は、全周カメラ１１０と、全周画像生成部１２１と、全周動画データ生成部１２２と、ライブ配信用サーバ１３０と、動画ライブ再生部１４０と、を含む。全周カメラ１１０は、全周映像を撮影する。全周画像生成部１２１は、全周カメラ１１０で撮影された全周動画を取得して時系列の全周フレーム画像データを生成する。全周動画データ生成部１２２は、時系列の全周フレーム画像データに対して符号化を行なって、通信端末装置１５０において実時間でストリーミング再生可能なフォーマットの全周動画データを生成する。ライブ配信用サーバ１３０は、全周動画データ生成部１２２からアップロードされた全周動画データを、通信端末装置１５０に配信する。動画ライブ再生部１４０は、ライブ配信用サーバ１３０から配信された全周動画データを実時間でストリーミング再生し、ユーザによる視線の指示に応じた範囲の動画映像を表示する。

本実施形態によれば、全周カメラからの全周動画をライブ配信可能に構成したことにより、ユーザが全周動画をライブで視聴することができる。

［第２実施形態］
次に、本発明の第２実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態の全周動画ライブ配信システムは、全周カメラで撮影した動画からフレーム単位の全周画像データを生成して、通信端末において動画ライブ再生が可能なフォーマットのデータを生成して、動画ライブ配信サーバにアップロードする。動画ライブ配信サーバは、通信端末が受信可能なプロトコルでメッセージを実時間に配信する。通信端末は、配信されたメッセージから全周動画をライブ再生し、ユーザの指示に従って所望の方向の全周動画をライブ表示する。また、全周動画の表示方向に対応する音声を立体音声でライブ再生する。なお、全周動画のライブ表示に対応する立体音声は、ステレオマイクで集音したライブ音声に限定されず、ライブ表示された全周動画に関連する他の立体音声や人工的に生成した立体音声であってもよい。また、本実施形態では立体音声として、ステレオ音声データに基づくステレオ音声の出力例を示すが、５．１チャネルの立体音声データに基づく立体音声であってもよい。

《全周動画ライブ配信システム》
図２Ａ乃至図３Ｃを参照して、本実施形態の全周動画ライブ配信システムの処理を説明する。

（処理の概要）
図２Ａは、本実施形態に係る全周動画ライブ配信システム２００の処理の概要を示す図である。

全周動画ライブ配信システム２００においては、全周の５方向の映像を撮影する５つの撮像センサと、真上の映像を撮影する１つの撮像センサからなる全周カメラにより、６方向の動画を同時に撮影する。したがって、この全周カメラを全天空カメラとも言う。なお、全周カメラの撮像センサの数は本例に限定されない。図２Ａにおいて、映像２１０は真上の映像、映像２１１〜２１５は全周をカバーする映像である。本実施形態においては、映像２１０〜２１５に基づいて、各映像の重なり部分を整合する画像調整を行なって全周を結合した全周画像フレーム２２０を生成する。なお、全周画像フレーム２２０の下辺２２２から所定距離領域２２５の画像データは、全周カメラの下方の撮影不可能な直下領域を補完するデータである。

この全周画像フレーム２２０からなるライブ動画は、全周動画が通信端末２４０においてライブ再生可能なフォーマットのデータに変換される。例えば、ＦＬＶ(Flash Video)フォーマットが使用されるのが望ましいが、限定されるわけではない。また、送信するデータ（いわゆる、ストリームデータ）のパターンによっては、ＦＬＶフォーマットへの変換が必ず必要なわけではなく、その場合はＦＬＶフォーマットへの変換は削除されてもよい。

ＦＬＶフォーマットに変換された全周動画は、所定の動画配信プロトコルに従ってライブ映像配信サーバを中継して、本実施形態の全周動画ライブ再生プレーヤが動作する通信端末２４０で再生される。図２Ａの通信端末２４０において、まず、全周画像フレーム２２０が、球体２３０に投影される。全周画像フレーム２２０の上辺２２１は、球体の頂点２３１に投影される。全周画像フレーム２２０の下辺２２２は、球体の底２３２に投影される。なお、切断円２３５から下方の底２３２までは、全周カメラでは撮影できない直下領域に相当する。球体２３０に投影された全周動画を球体２３０の中心２３３から平面２３４に投射すると、通信端末２４０に全周動画中の視線に応じた領域の動画がライブ再生される。ライブ再生された全周動画はユーザのタッチ２５１〜２５４のスライドに従って、映像２４１〜２４４のように全周動画の方向が回転する。図２Ａでは視点を球体２３０の中心２３３として説明したが、視点の位置を変えることにより、ライブ再生する領域やサイズを変更できる。

なお、図２Ａには、ステレオ音響については図示されていない。例えは、全周カメラと同じ位置にステレオマイクを配置して、全周動画と同期してステレオ音響を集音して、全周動画のライブ配信および再生に同期してステレオ音響を出力する。かかる、全周動画とステレオ音響とを同期させてライブ再生すれば、野外でのお祭りなどのイベント、あるいは屋内でのライブコンサートや展示会場などで、視線を変えることで音声も変化するのでより臨場感にあふれたライブ動画を視聴できる。また、ライブ音声とは異なる美術館の絵画の解説などのステレオ音響を、全周動画のライブ再生と同期させることもできる。

（動作の概要）
図２Ｂは、本実施形態に係る全周動画ライブ配信システム２００の動作の概要を示す図である。

通信端末２４０において、画面２６１では、サービスメニューからユーザが所望するサービスを選択する。本例では、「全周動画ライブ視聴」のサービスを選択する。画面２６２には、「全周動画ライブ視聴」のホームページが立ち上がり、複数の全周動画ライブの番組が表示されている。本例では、複数の全周動画ライブの番組から野球中継が選択されている。通信端末２４０は、データ配信サーバから野球中継のＨＴＭＬタグに基づいて、ライブ映像配信サーバから全周動画ライブを得るＵＲＬ(Uniform Resource Locator)を取得して、ライブ映像配信サーバ上の野球中継の全周動画ライブにアクセスする。通信端末２４０には、全周ライブ開始の画面２６３が表示される。全周ライブ開始の指示に応じて、全周ライブの動画と全周カメラの位置２６４が表示される。なお、図２Ｂの動作の概要は、一例であってこれに限定されない。

（システム構成）
図３Ａは、本実施形態に係る全周動画ライブ配信システム２００の構成を示すブロック図である。

全周動画ライブ配信システム２００は、全周カメラ３１０と、オプションとしてのステレオマイク３７０と、撮影配信用パーソナルコンピュータ（以降、ＰＣ）３２０と、ライブ映像配信サーバ３３０と、通信端末３４１〜３４３と、を含む。また、全周動画ライブ配信システム２００は、データ配信サーバ３５０を含む。なお、ライブ映像配信サーバ３３０やデータ配信サーバ３５０は、ネットワーク３６０を介して、撮影配信用ＰＣ３２０や通信端末３４１〜３４３と通信接続する。

全周カメラ３１０は、前述のように６つの撮像センサにより全天動画を撮影する。レンズなどによる歪みや明暗などの調整は、全周カメラ３１０で行なわれて、各デジタル画像フレームを撮影配信用ＰＣ３２０に出力する。ステレオマイク３７０は、全周カメラ３１０で撮影する動画に同期した立体音声を集音する。なお、図３Ａでは、ステレオマイク３７０の音声は１つのデータストリームに結合されて撮影配信用ＰＣ３２０に入力されているが、撮影配信用ＰＣ３２０において結合処理がされてもよい。また、音声が必要なければ、ステレオマイク３７０は接続しなくてもよい。

撮影配信用ＰＣ３２０では、まず、全周カメラ３１０からの６つの撮像センサの動画データに基づいて、各画像の境の整合性を取ってそれぞれ全周画像データをフレーム単位で生成する。次に、全周画像データに対して圧縮符号化を行なって、全周動画がライブ再生可能なＦＬＶフォーマットのデータに変換される。同期するステレオ音響があれば、圧縮符号化を行なって、ＦＬＶフォーマットのデータに追加される。

次に、ＦＬＶフォーマットのデータは、ＲＴＭＰ(Real Time Messaging Protocol)に従って、ライブ映像配信サーバ３３０にアップロードされる。ライブ映像配信サーバ３３０においては、例えば、あらかじめＨＴＭＬ(Hyper Text Markup Language)タグでＷｅｂページに埋め込まれたものから、ＵＲＬで参照できるように確保された格納位置に格納される。ライブ映像配信サーバ３３０は、必要であれば、各通信端末３４１〜３４３で復号可能な符号化あるいは暗号化を行なう。

一方、全周動画のライブ再生を視聴する通信端末３４１〜３４３からは、まず、データ配信サーバ（Ｗｅｂサーバ）３５０とＨＴＴＰ(Hypertext Transfer Protocol)に従い全周動画のライブ再生の視聴サービスを提供するＷｅｂページを開く。そのＷｅｂページに埋め込まれた全周動画ライブ配信タグが指示されると、ライブ映像配信サーバ３３０の該当ＩＰアドレスにアクセスする。ライブ映像配信サーバ３３０は、確保された格納位置に順次に格納される全周動画をライブ配信する。ただし、全周動画のライブ配信先が携帯端末３４２や３４３のスマートフォンやタブレットの場合は、配信規格をＨＬＳ(HTTP Live Streaming)に変換することにより配信する。一方、全周動画のライブ配信先が通信端末３４１のＰＣの場合は、ＲＴＭＰのまま配信、あるいは配信規格をＨＬＳやＨＤＳ(HTTP Dynamic Streaming)に変換することにより配信する。

（動作例）
図３Ｂは、本実施形態に係る全周動画ライブ配信システム２００の動作例を示す図である。なお、図３Ｂは、図３ＡにおけるＨＴＭＬタグを埋め込む操作を可視的に図示したものである。

図３Ｂにおいて、データ変換部とフラッシュメディアサーバとが、図３Ａのライブ映像配信サーバ３３０に相当する。ホームページ３７１、３７２にライブコンテンツごとあるいはイベントごとのＨＴＭＬタグを貼り付け、ここからライブ映像配信サーバ３３０にアクセスして、全周カメラからのライブデータをアクセスし、通信端末３４０で全周動画のライブ再生を視聴する。

なお、本実施形態においては、ホームページ３７１、３７２にライブコンテンツごとあるいはイベントごとのＨＴＭＬタグを貼り付けて、全周動画をライブ再生する例を示したが、ライブ映像配信サーバ３３０に通信端末３４１〜３４３から直接アクセスして、全周動画のライブ再生を視聴することも可能である。

（動作手順）
図３Ｃは、本実施形態に係る全周動画ライブ配信システム２００の動作手順を示すシーケンス図である。なお、図３Ｃにおいては、ユーザＰＣ３４１と携帯端末３４２、３４３とのステップを同じボックスで図示した部分があるが、煩雑さを避けるためであって別のステップである。また、図３Ｃにおいては、ユーザ認証などの処理は省略している。ユーザ認証を行なうためには、他に認証サーバを設けてユーザあるいは通信端末を登録しておき、認証を行なう。

撮影配信用ＰＣ３２０は、ステップＳ３１１において、カメラあるいはマイクの調整制御を行なう。全周カメラ３１０は、ステップＳ３０１において、撮影配信用ＰＣ３２０の制御に従って、カメラの調整を行なう。そして、全周カメラ３１０は、ステップＳ３０３において、６つの撮影センサにより全周映像を取得して、撮像センサの位置ＩＤを付加して撮影配信用ＰＣ３２０に送信する。なお、ステレオマイク３７０においても、ステップＳ３０５において、マイクが調整され、ステップＳ３０７において、立体音声を取得して、マイクＩＤを付加して撮影配信用ＰＣ３２０に送信する。

撮影配信用ＰＣ３２０は、ステップＳ３１３において、全周カメラ３１０から６つの撮影センサが撮影した映像データを取得する。そして、撮影配信用ＰＣ３２０は、ステップＳ３１５において、取得した映像データを結合して全周画像フレームを生成する。次に、撮影配信用ＰＣ３２０は、ステップＳ３１７において、ライブ配信するための全周動画データを作成する。この時に、例えば、Ｈ．２６４による動画圧縮を行なう。なお、動画圧縮はＨ．２６４に限定されない。しかしながら、多くの通信端末のプレーヤで伸張可能な圧縮方式が望ましい。動画圧縮方式としては、H.264の外に、H.263、WMV、DivX、VP6、VP7、VP8、VP9、Theora、WebM、MPEG1、MPEG2、MPEG4、DV等が使用可能である。

一方、音声について、撮影配信用ＰＣ３２０は、ステップＳ３１９において、ステレオマイクから音声データを取得する。次に、撮影配信用ＰＣ３２０は、ステップＳ３２１において、ライブ配信するための音声データを作成する。この時に、例えば、ＭＰ３による音声圧縮を行なう。なお、音声圧縮はＭＰ３に限定されない。しかしながら、多くの通信端末のプレーヤで伸張可能な圧縮方式が望ましい。音声圧縮方式としては、MP3の外に、AAC、HE-AAC、Vorbis、FLAC、Nellymoser、Speex、Apple Lossless、非圧縮のWAV等が使用可能である。

撮影配信用ＰＣ３２０は、ステップＳ３２３において、所望の圧縮処理をされた全周動画データと音声データとを同期再生可能に、ライブ映像配信用データを生成する。本例では、前述のＦＬＶフォーマットのデータを生成する。生成したＦＬＶフォーマットのデータは、撮影配信用ＰＣ３２０により、ステップＳ３２５において、本例では、ＲＴＭＰに従ったライブ映像配信メッセージによりライブ映像配信サーバ３３０にアップロードされる。

一方、ライブ映像配信サーバ３３０は、ステップＳ３３１において、ライブ映像配信ＵＲＬを決定してライブ映像配信エリアを確保する。データ配信サーバ３５０では、ステップＳ３５１において、Ｗｅｂページに全周動画ライブ配信用タグが貼り付けられる。そして、通信端末３４１〜３４３から、ステップＳ３６１またはＳ３８１において、Ｗｅｂページから全周動画ライブ視聴の指示があるとする。データ配信サーバ３５０は、ステップＳ３５３において、通信端末３４１〜３４３からの視聴指示を取得して、ステップＳ３５５において、ライブ映像配信元を通信端末３４１〜３４３に通知する。この時に、全周動画をライブ再生するための全周動画ライブ再生プレーヤが、通信端末３４１〜３４３に送信される。すなわち、実際はプレーヤＵＲＬを、全周動画ライブ配信用タグで指定し、ライブ映像配信ＵＲＬはプレーヤ自体に埋め込まれたり、プレーヤが別途取得したり、あるいは、全周動画ライブ配信用タグに含ませることもできる。

通信端末３４１〜３４３は、ステップＳ３６３またはＳ３８３において、ライブ映像配信元を取得すると共に、全周動画ライブ再生プレーヤを受信して、ステップＳ３６５またはＳ３８５において、全周動画ライブ再生プレーヤを起動させる。そして、通信端末３４１〜３４３は、ステップＳ３６７またはＳ３８７において、通信端末ごとに対応したＵＲＬを指定することで全周動画のライブ再生の視聴をライブ映像配信サーバ３３０に要求する。

ＲＴＭＰに従った撮影配信用ＰＣ３２０からの全周ライブ映像配信用データのアップロードがあると、ライブ映像配信サーバ３３０は、ステップＳ３３５において、全周ライブ映像配信用データを取得してライブ動画記憶領域に一時保持する。そして、ライブ映像配信サーバ３３０は、ステップＳ３３７において、全周ライブ動画配信用メッセージをスマートフォンやタブレット用のフォーマット（例えば、ＨＬＳ）に変換して一時保持する。さらに他のフォーマットが必要であれば、フォーマット変換して一時保持しておく。

全周ライブ映像の配信先が通信端末３４１のＰＣであれば、ライブ映像配信サーバ３３０は、ステップＳ３３９において、全周動画をＲＴＭＰに従って配信先の通信端末３４１にライブ配信する。この場合に、複数の配信先があればユニキャストにより同時に配信される。通信端末３４１は、ステップＳ３６９において、全周ライブ動画配信用メッセージを受信し、ステップＳ３７１において、全周動画をライブ再生する。なお、ＰＣ向けには、ＲＴＭＦＰ(Real Time Media Flow Protocol)プロトコルによるマルチキャストも可能である。

一方、全周ライブ映像の配信先が携帯端末３４２または３４３のスマートフォンやタブレットであれば、ライブ映像配信サーバ３３０は、ステップＳ３４１において、全周動画をＨＬＳにより配信先の携帯端末３４２または３４３にライブ配信する。この場合に、複数の配信先があればユニキャストにより順次に配信される。携帯端末３４２または３４３は、ステップＳ３８９において、全周ライブ動画配信用メッセージを受信し、ステップＳ３９１において、全周動画をライブ再生する。

上記例では、スマートフォン、タブレット向けの変換はライブ映像配信サーバ３３０にアップロードされた段階で行われる手順を説明したが、携帯端末３４２または３４３からアクセスされてから変換を行なうことも可能である。この場合には、再生が開始されるまでに余分に時間がかかるが、スマートフォン、タブレットからのアクセスがない場合に処理負荷を押さえることができる。また、ライブ映像配信サーバ３３０から通信端末３４１〜３４３へのライブ映像配信メッセージとしては、一般的に、RTMP、HLS、HDS、RTSP、MMS、Microsoft Smooth Streaming、MPEG-DASHのプロトコルが用いられることが多い。しかし、これらとは異なるプロトコルや、独自開発のプロトコルを利用することも可能である。

《全周カメラの機能構成》
図４Ａは、本実施形態に係る全周カメラ３１０の機能構成を示すブロック図である。

全周カメラ３１０は、複数の撮像センサ４１１と、Ａ／Ｄ変換およびゲイン調整部４１２と、画素処理部４１３と、画像処理部４１４と、オプションとしての転送用圧縮部４１５と、を有する。

複数の撮像センサ４１１は、本例では前述の６つの撮像センサである。Ａ／Ｄ変換およびゲイン調整部４１２は、複数の撮像センサ４１１から出力される映像のアナログ信号をデジタルデータに変換すると共に、アナログ信号が飽和しないように適切なゲインに調整する。画素処理部４１３は、画素単位の調整を行なう。画像処理部４１４は、画像全体の明暗などの調整を行なう。オプションとしての転送用圧縮部４１５は、全周カメラ３１０から出力される複数の撮像センサ４１１からの映像データを実時間で高速に転送するための圧縮部である。全周カメラ３１０の構成部品や構造により歪みを補償された映像データは、例えば、IEEE-1394bケーブルやＵＳＢケーブルなどにより外部に出力される。本実施形態においては、撮影配信用ＰＣ３２０に接続されて映像データが送信される。

図４Ｂは、本実施形態に係る全周カメラ３１０の構造例を説明する図である。

図４Ｂの全周カメラ外観４２０は、全周カメラ３１０の具体的な構造を示している。また、図４Ｂの撮像センサの撮像位置４３０は、全周カメラ３１０の６つの撮像センサの位置関係と、それらが撮像する方向とを示したものである。

（データ構成）
図５は、本実施形態に係る全周カメラ３１０のデータ構成５００を示す図である。図５のデータ構成５００は、全周カメラ３１０から外部に出力される撮像データの構成である。なお、データ構成は、図５に限定されない。

データ構成５００は、どの撮像センサで撮影した撮像データかを識別するセンサ番号５０１と、撮像した時刻を示すタイムスタンプ５０２と、映像データ５０３と、を有し、全周カメラ３１０に記憶される（図２Ａの２１０〜２１５参照）。なお、映像データ５０３は、圧縮されたデータであってもよい。

《撮影配信用ＰＣの機能構成》
図６は、本実施形態に係る撮影配信用ＰＣ３２０の機能構成を示すブロック図である。なお、撮影配信用ＰＣ３２０は、本実施形態の撮影配信のためのソフトウェアを搭載する一般的なＰＣである。

撮影配信用ＰＣ３２０は、通信制御部６０１と、入力インタフェース６０２とを備える。また、撮影配信用ＰＣ３２０は、全周映像データ取得部６０３と、全周画像生成部６０４と、全周動画圧縮部６０５と、立体音声データ取得部６０６と、立体音声圧縮部６０７、とを備える。また、撮影配信用ＰＣ３２０は、ライブ映像配信用データ生成部６０８と、ライブ映像配信用メッセージ送信部６０９と、表示部６１０と、操作部６１１と、を備える。

通信制御部６０１は、ネットワークを介してライブ映像配信サーバ３３０および外部通信機器と通信する。入力インタフェース６０２は、全周カメラ３１０からの映像データおよび／またはステレオマイクからの音声データを入力制御する。

全周映像データ取得部６０３は、全周カメラ３１０から全周を撮像した映像データを取得する。全周画像生成部６０４は、全周映像データ取得部６０３が取得した６つの映像データの境界領域の歪みを補償し、お互いに調整して、１フレームごとの全周画像を生成する（図２Ａの２２０参照）。そして、全周動画圧縮部６０５は、全周画像生成部６０４で生成された１フレームごとの全周画像からなる全周ライブ動画データを配信して全周動画がライブ再生できる形式の、全周画像圧縮データを生成する。この場合に、全周ライブ動画データは所定長単位に所望方式で圧縮符号化される。本例では、動画圧縮方式としてＨ．２６４を使用しているが、これに限定されない。他の使用可能な動画圧縮方式については、前述した。

立体音声データ取得部６０６は、ステレオマイクからの立体音声データを取得する。そして、立体音声圧縮部６０７は、立体音声データ取得部６０６が取得した立体音声データを配信してステレオ音響が再生できる形式の、立体音声圧縮データを生成する。この場合に、立体音声データは所定長単位に所望方式で圧縮符号化される。本例では、音声圧縮方式としてＭＰ３を使用しているが、これに限定されない。他の使用可能な音声圧縮方式については、前述した。かかる立体音声データ取得部６０６と立体音声圧縮部６０７とが、立体音声データ生成部として機能する。

ライブ映像配信用データ生成部６０８は、全周動画圧縮部６０５が生成した全周動画圧縮データと、立体音声圧縮部６０７が生成した立体音声圧縮データとを、ライブ配信するためのライブ配信用データを生成する。この時に、全周動画と立体音声とが同期再生できるようにする。本例では、ＦＬＶフォーマットを使用するが、これに限定されない。例えば、Windows（登録商標） Media、Real Media（登録商標）、Quick Time（登録商標）などであってもよい。ライブ映像配信用メッセージ送信部６０９は、ライブ映像配信用データ生成部６０８が生成したライブ映像配信用データを、ライブ映像配信用メッセージによりライブ映像配信サーバ３３０にアップロードする。

表示部６１０は、撮影配信用ＰＣ３２０の動作状況を表示する。また、操作部６１１は、上記各記憶構成部の起動や制御などを指示する。

（データ構成）
図７Ａは、本実施形態に係る撮影配信用ＰＣ３２０の映像データ構成７１０を示す図である。図７Ａの映像データ構成７１０は、全周カメラ３１０から取得した映像データから全周画像データを生成する記憶構成である。

映像データ構成７１０においては、映像センサのセンサ番号７１１に対応付けて、撮影時刻のタイムスタンプ７１２と、全周カメラ３１０から取得した映像データ７１３と、全周画像に結合するために処理された全周処理データ７１４と、を記憶する。そして、６つの撮像センサの映像データを結合した全周画像データ７１５を記憶する（図２Ａの２２０参照）。

図７Ｂは、本実施形態に係る撮影配信用ＰＣ３２０の音声データ構成７２０を示す図である。図７Ｂの音声データ構成７２０は、ステレオマイクから取得した音声データを記憶する構成である。

音声データ構成７２０においては、マイク番号７２１に対応付けて、集音時刻のタイムスタンプ７２２と、音声データ７２３とを記憶する。

図７Ｃは、本実施形態に係る撮影配信用ＰＣ３２０のライブ配信用データ形式７３０およびライブ映像配信用データ７４０を示す図である。ライブ配信用データ形式７３０は、生成するライブ配信用データ形式を指定するテーブルである。ライブ映像配信用データ７４０は、ライブ配信用データ形式７３０に従って生成されたデータである。

ライブ配信用データ形式７３０は、ライブ動画配信フォーマット７３１に対応して、使用する動画圧縮方式７３２と音声圧縮方式７３３とを記憶する。ライブ映像配信用データ７４０は、ライブ配信用データ形式７３０に従って圧縮生成された全周動画圧縮データ７４１と立体音声圧縮データ７４２とを同期再生可能に含むライブ動画配信用データを記憶する。本例では、ライブ動画配信用メッセージ形式としてＦＬＶを使用する。

《ライブ映像配信サーバの機能構成》
図８は、本実施形態に係るライブ映像配信サーバ３３０の機能構成を示すブロック図である。

ライブ映像配信サーバ３３０は、通信制御部８０１と、ライブ映像配信メッセージ受信部８０２と、配信データフォーマット変換部８０３と、ライブ映像配信用データ格納部８０４と、を備える。また、ライブ映像配信サーバ３３０は、ライブ映像配信要求受信部８０５と、配信データ取得部８０６と、ライブ映像配信メッセージ送信部８０７と、を備える。

通信制御部８０１は、ネットワークを介して、撮影配信用ＰＣ３２０からアップロードされたライブ配信用メッセージの受信、および、通信端末３４１〜３４３に対するライブ配信用メッセージの送信を制御する。ライブ映像配信メッセージ受信部８０２は、撮影配信用ＰＣ３２０からアップロードされたライブ配信用メッセージを受信する。配信データフォーマット変換部８０３は、ライブ配信用メッセージを、配信先がスマートフォン・タブレットの場合のためにＨＬＳフォーマットに変換する。さらに他のフォーマットが必要であれば、フォーマット変換する。ライブ映像配信用データ格納部８０４は、ライブ配信用データを、フォーマット変換されないものと変換されたものとを識別可能に一時保持する。それぞれのライブ配信用データは、配信元および配信要求先からのＵＲＬに対応付けられる。なお、ライブ映像配信用データ格納部８０４は、一時記憶のメモリ内であってもディスクなどの記憶媒体であってもよい。

ライブ映像配信要求受信部８０５は、通信端末からのライブ配信用メッセージの要求を受信して、配信データ取得部８０６の取得領域とライブ映像配信メッセージ送信部８０７の送信先とを通知する。配信データ取得部８０６は、通信端末からのＵＲＬに対応してライブ映像配信用データ格納部８０４の格納領域からライブ配信用データを取得する。ライブ映像配信メッセージ送信部８０７は、ライブ配信用データをライブ映像配信メッセージで要求した通信端末にユニキャストで送信する。なお、配信先がＰＣである場合に、マルチキャストも可能であることは前述した。

（ＵＲＬおよびデータ変換）
図９は、本実施形態に係るライブ映像配信サーバ３３０へのＵＲＬの構成９００およびデータ変換９１０を示す図である。

本実施形態のＵＲＬの構成９００は、基本的に、ライブ映像配信サーバ３３０のＩＰアドレスと、配信元（あるいはイベント）識別子と、ライブ動画記憶領域識別子と、データフォーマット識別子と、を有している。

さらに具体的に、本実施形態のライブ映像配信サーバ３３０におけるデータ変換９１０を説明する。なお、ライブ映像配信サーバ３３０におけるデータ変換は本例に限定されない。なお、ライブ映像配信サーバ３３０のサーバ名またはＩＰアドレスを192.0.2.1として説明する。また、複数の全周動画ライブの配信元あるいはイベントを“eventX”で識別し、元の全周動画ライブデータを“live”、変換により派生した全周動画ライブデータを“liveX”で識別し、ＲＴＭＰ形式を“stream”、ＨＬＳ形式を“stream.m3u8”で識別する。

＜配信元の認証を行い、受信したライブ動画データをバッファに格納する手順＞
（１）撮影配信用ＰＣ３２０からライブ映像配信サーバ３３０上のＵＲＬ“rtmp://192.0.2.1/event1/live/stream”に対して、ライブ動画データを送信する。
（２）ライブ映像配信サーバ３３０は、受信したライブ動画データが正規の配信元からのものであることを確認し、バッファ領域に格納する。

＜各端末で再生可能な形式にバッファのライブ動画データを変換する手順＞
（３）ライブ映像配信サーバ３３０内にて、“rtmp://192.0.2.1/event1/live/stream”からライブ動画データを読み込み、ライブ映像配信サーバ３３０のＵＲＬ“rtmp://192.0.2.1/event1/live1/stream”に再入力する。
（４）ライブ映像配信サーバ３３０内にて“rtmp://192.0.2.1/event1/live/stream”からライブ動画データを読み込み、コード変換を行って動画解像度を縮小し、ライブ映像配信サーバ３３０上のＵＲＬ“rtmp://192.0.2.1/event1/live2/stream”に再入力する。
（５）上記（３）（４）に対し、ライブ映像配信サーバ３３０は、受信したライブ動画データが正規の配信元（＝ライブ映像配信サーバ３３０自身）からのものであることを確認し、バッファ領域に格納する。
（６）上記（３）（４）に対し、ライブ映像配信サーバ３３０は、バッファ領域のライブ動画データからＨＬＳ形式のファイル（連番ファイル）を順次作成し、ＨＤＤ上の一時領域に保存する。この一時領域には、ＵＲＬ“http://192.0.2.1/event1/live1/stream.m3u8”、または、“http://192.0.2.1/event1/live2/stream.m3u8”等でアクセス可能である。

＜通信端末からの配信要求に対してバッファのライブ動画データをＲＴＭＰ形式で配信する手順＞
（７）ＲＴＭＰ形式にてライブ動画データを受信する通信端末は、ライブ映像配信サーバ３３０上のＵＲＬ“rtmp://192.0.2.1/event1/live1/stream”、または、“rtmp://192.0.2.1/event1/live2/stream”にアクセスする。
（８）ライブ映像配信サーバ３３０は、通信端末に対して、上記（５）によるバッファ領域のライブ動画データを配信する。

＜通信端末からの配信要求に対してバッファのライブ動画データをＨＬＳ形式で配信する手順＞
（９）ＨＬＳ形式にてライブ動画データを受信する通信端末は、データ配信サーバ３５０にアクセスし、“master.m3u8”ファイルを取得する。このファイルには、ライブ映像配信サーバ３３０上のＨＬＳ向け一時領域のファイルを指し示すＵＲＬが記載されている。
（１０）ＨＬＳ形式にてデータを受信する通信端末は、通常のＨＬＳ形式の動画再生手順に従い、取得した“master.m3u8”ファイルを解析し、ライブ映像配信サーバ３３０上のＨＬＳ向け一時領域に、ＵＲＬ“http://192.0.2.1/event1/live1/stream.m3u8”、または、“http://192.0.2.1/event1/live2/stream.m3u8”のファイルにアクセスする。
（１１）ライブ映像配信サーバ３３０は、通信端末からの要求ＵＲＬに応じて、一時領域のファイルを配信する。

＜配信後の手順＞
（１２）ライブ映像配信サーバ３３０は、一定時間経過したライブ動画データをバッファ領域から削除する。
（１３）ライブ映像配信サーバ３３０は、一定時間経過したＨＬＳ形式のファイルを一時領域から削除する。

なお、動画解像度やコーデック等の変換を行なわず、単にＲＴＭＰ形式をＨＬＳ形式に変換するだけであれば、上記（３）〜（５）の処理は不要である。この場合、上記（６）の処理は、上記（２）に対するものとなる。ここで、複数の全周ライブ動画を、ライブ映像配信サーバ３３０を介して配信する場合は、各ＵＲＬの“eventX”の部分を変更することでそれぞれを区別することができる。

《通信端末の機能構成》
図１０は、本実施形態に係る通信端末３４１〜３４３の機能構成を示すブロック図である。以下、通信端末３４１〜３４３を総称して、通信端末３４０として説明する。なお、通信端末３４０は、一般的なＰＣやスマートフォン・タブレットである。

通信端末３４０は、通信制御部１００１と、全周動画ライブ再生プレーヤ１０１０と、表示部１０２１と、操作部１０２２と、音声出力部１０２３と、を備える。

通信制御部１００１は、ネットワークを介して、ライブ映像配信サーバ３３０やデータ配信サーバ（Ｗｅｂサーバ）３５０などとの通信を制御する。全周動画ライブ再生プレーヤ１０１０は、配信された画像あるいは動画メッセージから画像あるいは動画を再生するアプリケーションである。本実施形態においては、全周動画をライブ再生するアプリケーションである。全周動画ライブ再生プレーヤ１０１０は、全周動画メッセージ受信部１０１１と、全周動画展開部１０１２と、表示範囲制御部１０１３と、表示方向指示受付部１０１４と、立体音声制御部１０１５と、を有する。

全周動画データ受信のための全周動画メッセージ受信部１０１１は、ライブ映像配信サーバ３３０から配信された全周動画メッセージを受信する。全周動画展開部１０１２は、配信された全周動画メッセージの全周動画データから全周動画をライブ展開する。表示範囲制御部１０１３は、全周動画展開部１０１２がライブ展開した全周動画から指定を受けた方向の動画を表示するように制御する。表示方向指示受付部１０１４は、ユーザによる全周動画の表示方向の指示を受け付ける。立体音声制御部１０１５は、全周動画の表示方向に応じたステレオ音響を出力するように制御する。

表示部１０２１は、全周動画のライブ表示を含むデータを表示する。操作部１０２２は、各機能構成部の駆動あるいは制御を指示する。音声出力部１０２３は、ステレオ音響を出力する。

（全周ライブ映像の展開）
図１１Ａは、本実施形態に係る通信端末３４０における全周ライブ映像の展開を説明する図である。

図１１Ａにおいて、球体１１００には、配信された全周動画データが含む全周動画の、各全周画像フレームを、球体面を覆うように順次に貼り付ける。そして、内部の視点１１０１から球体１１００を覆った全周画像フレームを、通信端末の画面を示す表示平面に投影した画像１１０２、１１０３および１１０５が、通信端末の表示画面に表示される。視点１１０１からの視線方向が球体１１００の軸を中心に回転すれば、画像１１０２も視線方向の回転につれて回転する。また、視点１１０１が上下に移動すれば、画像１１０２の範囲も視点１１０１の上下に応じて上下する。また、視線方向が上向き／下向きになると、見上げた画面／見下ろした画面となる。また、視点１１０１が球体の中心から視点１１０４に離れると、球体１１００に近づいた方向ではズームインとなり、球体１１００から離れた方向ではズームアウトとなる。

このように、視点位置と視線方向とを変化させることで、全周動画のライブ再生を見渡すことができて、臨場感にあふれる全周動画のライブ視聴が可能となる。なお、立体音声との再生方向の同期は、図１１Ａの視線ベクトルと球体１１００の交点に基づいて実現できる。また、ライブ映像とは異なる人工的な映像を合成するには、他の球体を設けてその球体に画像を貼り付ければよい。例えば、ライブ映像の上に人工画像を表示する場合は、球体１１００の内部に他の球体を設ければよい。一方、人工背景を付加する場合には、球体１１００の外に他の球体を設ければよい。３次元映像においては、視点から球体への距離の違いを奥行きとして表現することができる。

（データ構成）
図１１Ｂは、本実施形態に係る通信端末３４０の全周動画のライブ再生用情報１１１０、映像データ構成１１２０および音声データ構成１１３０を示す図である。図１１Ｂのライブ再生用情報１１１０は、ホームページから全周動画ライブ再生を実現するための情報である。また、図１１Ｂの映像データ構成１１２０は、全周ライブ映像の記憶構成である。また、図１１Ｂの音声データ構成１１３０は、立体音声の記憶構造である。

ライブ再生用情報１１１０は、ホームページに貼り付けられたＨＴＭＬタグ１１１１と、ＨＴＭＬタグ１１１１に基づいてデータ配信サーバ３５０から取得したライブ動画データにアクセスするためのＵＲＬ１１１２と、を記憶する。ライブ再生用情報１１１０は、さらに、通信端末３４０において全周動画ライブ再生するために使用する全周動画ライブ再生プレーヤ１１１３、を記憶する。映像データ構成１１２０は、図１１Ａの球体１１００に貼り付けられた全周ライブ映像１１２１から、ユーザ指示方向（視線方向）１１２２に対応して選択された、ライブ表示データ１１２３を記憶する。音声データ構成１１３０は、配信されたステレオライブ音声１１３１から、ユーザ指示方向（視線方向）１１２２に対応して混合比率を変えた、ライブ音声データ１１３３を記憶する。

なお、詳細な説明は省略するが、ライブ映像表示とライブ音声出力との同期は、タイムスタンプを使用すれば実現できる。

《撮影配信用ＰＣのハードウェア構成》
図１２は、本実施形態に係る撮影配信用ＰＣ３２０のハードウェア構成を示すブロック図である。

図１２で、ＣＰＵ１２１０は演算制御用のプロセッサであり、プログラムを実行することで図６の撮影配信用ＰＣ３２０の機能構成部を実現する。ＲＯＭ(Read Only Memory)１２２０は、初期データおよびプログラムなどの固定データを記憶する。また、通信制御部６０１は、ネットワークを介して他の通信端末や各サーバと通信する。なお、ＣＰＵ１２１０は１つに限定されず、複数のＣＰＵであっても、あるいは画像処理用のＧＰＵを含んでもよい。また、通信制御部６０１は、ＣＰＵ１２１０とは独立したＣＰＵを有して、ＲＡＭ１２４０の領域に送受信データを書き込みあるいは読み出しするのが望ましい。また、ＲＡＭ１２４０とストレージ１２５０との間でデータを転送するＤＭＡＣを設けるのが望ましい（図示なし）。さらに、入出力インタフェース１２６０は、ＣＰＵ１２１０とは独立したＣＰＵを有して、ＲＡＭ１２４０の領域に入出力データを書き込みあるいは読み出しするのが望ましい。したがって、ＣＰＵ１２１０は、ＲＡＭ１２４０にデータが受信あるいは転送されたことを認識してデータを処理する。また、ＣＰＵ１２１０は、処理結果をＲＡＭ１２４０に準備し、後の送信あるいは転送は通信制御部６０１やＤＭＡＣ、あるいは入出力インタフェース１２６０に任せる。

ＲＡＭ１２４０は、ＣＰＵ１２１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ１２４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。全周映像データ１２４１は、全周カメラ３１０から取得した６つの撮像センサからの映像データである。全周画像データ７１５は、全周映像データ１２４１から生成された１フレームの全周データである。全周動画圧縮データ７４１は、全周画像データ７１５をライブ再生が可能な所定の圧縮符号化した動画データである。立体音声データ１２４４は、複数のマイクから取得した音声データである。立体音声圧縮データ７４２は、立体音声データ１２４４をライブ再生が可能な所定の圧縮符号化した音声データである。ライブ映像配信用データ７４０は、全周動画圧縮データ７４１と立体音声圧縮データ７４２とを含み、ライブ配信可能なフォーマットの配信用データである。送受信メッセージ１２４７は、通信制御部６０１を介して送受信されるメッセージである。入出力データ１２４８は、入出力インタフェース１２６０を介して入出力されるデータである。

ストレージ１２５０には、データベースや各種のパラメータ、あるいは本実施形態の実現に必要な以下のデータまたはプログラムが記憶されている。ライブ映像配信用データ格納部１２５１は、ライブ映像配信サーバ３３０にアップロードするためのライブ映像配信用データ７４０をそれぞれ識別可能に格納するデータベースである。ライブ映像アップロード先サーバ１２５２は、撮影配信用ＰＣ３２０がライブ映像配信用データ７４０をアップロードする先のライブ映像配信サーバ３３０のアドレスである。

ストレージ１２５０には、以下のプログラムが格納される。撮影配信用ＰＣ制御プログラム１２５３は、本撮影配信用ＰＣ３２０の全体を制御する制御プログラムである。全周映像データ取得モジュール１２５４は、全周カメラ３１０から全周映像データ１２４１を取得するモジュールである。全周画像データ生成モジュール１２５５は、取得した全周映像データ１２４１に基づいてフレーム単位の全周画像データを生成するモジュールである。全周動画圧縮モジュール１２５６は、全周画像データからなる全周動画を圧縮するモジュールである。立体音声圧縮モジュール１２５７は、ステレオマイクから取得した立体音声データ１２４４に基づいて立体音声圧縮データ７４２を生成するモジュールである。ライブ映像配信用データ生成モジュール１２５８は、全周動画圧縮データ７４１と立体音声圧縮データ７４２とを含む、ライブ配信可能なライブ映像配信用データ７４０を生成するモジュールである。ライブ映像配信用メッセージ送信モジュール１２５９は、生成されたライブ映像配信用データ７４０を、ライブ映像配信用メッセージでライブ映像アップロード先サーバ１２５２の情報を使用して、ライブ映像配信サーバ３３０にアップロードするモジュールである。

入出力インタフェース１２６０は、入出力機器との入出力データをインタフェースする。入出力インタフェース１２６０は、全周カメラ３１０と接続するためのIEEE-1394b用コネクタあるいはＵＳＢコネクタや、ステレオマイクを接続可能なコネクタを有する。入出力インタフェース１２６０には、表示部６１０、操作部６１１、が接続される。また、ＧＰＳ位置判定部１２６５や、例えば、全周カメラ３１０が移動して撮影配信用ＰＣ３２０も移動する場合に、移動速度を測定する速度センサ１２６６を接続してもよい。

なお、図１２においては、全周カメラ３１０からの映像データやステレオマイクからの音声データ、あるいは、ＧＰＳ位置情報や速度センサなどの情報を、入出力インタフェース１２６０を介して取得する構成を示した。しかし、これらの情報を、通信制御部６０１を介して通信により取得する構成であってもよい。また、図１２のＲＡＭ１２４０やストレージ１２５０には、撮影配信用ＰＣ３２０が有する汎用の機能や他の実現可能な機能に関連するプログラムやデータは図示されていない。

《撮影配信用ＰＣの処理手順》
図１３は、本実施形態に係る撮影配信用ＰＣ３２０の処理手順を示すフローチャートである。このフローチャートは、図１２のＣＰＵ１２１０がＲＡＭ１２４０を使用しながら実行し、図６の機能構成部を実現する。

撮影配信用ＰＣ３２０は、ステップＳ１３１１において、全周カメラ３１０からの映像データの受信か否かを判定する。映像データの受信であれば、撮影配信用ＰＣ３２０は、ステップＳ１３１３において、受信した６つの映像データから１フレームの全周画像データを生成する。そして、撮影配信用ＰＣ３２０は、ステップＳ１３１５において、全周画像データのライブ配信可能な長さをフレーム順に全周動画として保持する。全周カメラ３１０からの映像データの受信がなければ、撮影配信用ＰＣ３２０は、ステップＳ１３２１に進んで、音声入力の判定を行なう。

次に、撮影配信用ＰＣ３２０は、ステップＳ１３２１において、ステレオマイク３７０からの音声データの受信か否かを判定する。音声データの受信であれば、撮影配信用ＰＣ３２０は、ステップＳ１３２３において、受信した立体音声データをライブ配信可能な長さ保持する。なお、保持する長さは、全周画像データのフレーム長に対応する長さとするのが望ましい。音声データの受信がなければ、撮影配信用ＰＣ３２０は、ステップＳ１３３１に進む。

そして、撮影配信用ＰＣ３２０は、ステップＳ１３３１において、ライブ動画配信用メッセージの送信タイミングであるか否かを判定する。ライブ動画配信を可能とするライブ動画配信用メッセージの送信タイミングでなければ、撮影配信用ＰＣ３２０は、ステップＳ１３１１に戻って、映像データまたは音声データを受信して保持する。ライブ動画配信を可能とするライブ動画配信用メッセージの送信タイミングであれば、撮影配信用ＰＣ３２０は、ステップＳ１３３３において、保持した全周動画データから全周動画メッセージを生成する。次に、撮影配信用ＰＣ３２０は、ステップＳ１３３５において、保持した立体音声データから立体音声メッセージを生成する。次に、撮影配信用ＰＣ３２０は、ステップＳ１３３７において、全周動画メッセージと立体音声メッセージとを含む、ライブ動画配信用メッセージを生成する。そして、撮影配信用ＰＣ３２０は、ステップＳ１３３９において、生成したライブ動画配信用メッセージをライブ映像配信サーバ３３０にアップロードする。撮影配信用ＰＣ３２０は、ステップＳ１３４１において、ライブ配信の終了か否かを判定する。ライブ配信の終了でなければ、撮影配信用ＰＣ３２０は、ステップＳ１３１１に戻って、全周カメラデータの受信とライブ動画配信を繰り返す。

《ライブ映像配信サーバのハードウェア構成》
図１４は、本実施形態に係るライブ映像配信サーバ３３０のハードウェア構成を示すブロック図である。

図１４で、ＣＰＵ１４１０は演算制御用のプロセッサであり、プログラムを実行することで図８のライブ映像配信サーバ３３０の機能構成部を実現する。ＲＯＭ１４２０は、初期データおよびプログラムなどの固定データを記憶する。また、通信制御部８０１は、ネットワークを介して通信端末や撮影配信用ＰＣと通信する。なお、ＣＰＵ１４１０は１つに限定されず、複数のＣＰＵであっても、あるいは画像処理用のＧＰＵを含んでもよい。また、通信制御部８０１は、ＣＰＵ１４１０とは独立したＣＰＵを有して、ＲＡＭ１４４０の領域に送受信データを書き込みあるいは読み出しするのが望ましい。また、ＲＡＭ１４４０とストレージ１４５０との間でデータを転送するＤＭＡＣを設けるのが望ましい（図示なし）。したがって、ＣＰＵ１４１０は、ＲＡＭ１４４０にデータが受信あるいは転送されたことを認識してデータを処理する。また、ＣＰＵ１４１０は、処理結果をＲＡＭ１４４０に準備し、後の送信あるいは転送は通信制御部８０１やＤＭＡＣに任せる。

ＲＡＭ１４４０は、ＣＰＵ１４１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ１４４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。ＰＣ向けライブ映像配信用データ１４４１は、撮影配信用ＰＣ３２０からアップロードされて、ＰＣ向けに配信されるデータである。携帯端末向けライブ映像配信用データ１４４２は、撮影配信用ＰＣ３２０からアップロードされて、携帯端末向けに配信されるデータである。本実施形態においては、ＰＣ向けライブ映像配信用データ１４４１は、撮影配信用ＰＣ３２０からアップロードされたそのままであり、携帯端末向けライブ映像配信用データ１４４２は、ＨＬＳフォーマットに変換されたものである。ＵＲＬ（配信元／配信先）１４４３は、撮影配信用ＰＣ３２０である配信元からのＵＲＬ、通信端末３４１〜３４３である配信先からのＵＲＬを、ライブ映像配信用データ１４４１あるいは１４４２の格納位置と関連付ける情報である。送受信メッセージ１４４４は、通信制御部８０１を介して送受信されるメッセージである。

ストレージ１４５０には、データベースや各種のパラメータ、あるいは本実施形態の実現に必要な以下のデータまたはプログラムが記憶されている。ライブ映像配信用データ格納部１４５１は、撮影配信用ＰＣ３２０からアップロードされたライブ映像配信用データをそれぞれＵＲＬでアクセス可能に格納する領域である。配信用データ変換アルゴリズム１４５２は、ライブ映像配信用データをＨＬＳフォーマットに変換するアルゴリズムである。

ストレージ１４５０には、以下のプログラムが格納される。ライブ映像配信サーバ制御プログラム１４５５は、本ライブ映像配信サーバ３３０の全体を制御する制御プログラムである。配信用データ変換モジュール１４５６は、配信先がスマートフォンやタブレットなどの携帯端末の場合に、ライブ映像配信用データの圧縮符号化方式を変更し、ＨＬＳフォーマットに変換するモジュールである。ライブ映像配信モジュール１４５７は、ライブ映像配信用メッセージを配信先に配信するためのモジュールである。

なお、図１４のＲＡＭ１４４０やストレージ１４５０には、ライブ映像配信サーバ３３０が有する汎用の機能や他の実現可能な機能に関連するプログラムやデータは図示されていない。

《ライブ映像配信サーバの処理手順》
図１５は、本実施形態に係るライブ映像配信サーバ３３０の処理手順を示すフローチャートである。このフローチャートは、図１４のＣＰＵ１４１０がＲＡＭ１４４０を使用しながら実行し、図８の機能構成部を実現する。

ライブ映像配信サーバ３３０は、ステップＳ１５１１において、配信元の撮影配信用ＰＣ３２０からのライブ映像配信用データのアップロード要求か否かを判定する。配信元からのライブ映像配信用データのアップロード要求であれば、ライブ映像配信サーバ３３０は、ステップＳ１５１３において、ライブ映像配信用メッセージを取得する。そして、ライブ映像配信サーバ３３０は、ステップＳ１５１５において、ＵＲＬに基づいてそのままのライブ映像配信用データをＰＣ向けライブ映像配信用データとして保持する。次に、ライブ映像配信サーバ３３０は、ステップＳ１５１７において、他の機種に対応する異なるフォーマットのライブ映像配信用データを生成する。そして、ＵＲＬに基づいて生成したライブ映像配信用データを携帯端末向けライブ映像配信用データとして保持する。

配信元の撮影配信用ＰＣ３２０からのライブ映像配信用メッセージの受信でない場合、ライブ映像配信サーバ３３０は、ステップＳ１５２１において、配信先の通信端末３４０からのライブ映像配信用メッセージの配信要求か否かを判定する。配信先の通信端末３４０からのライブ映像配信用メッセージの配信要求であれば、ライブ映像配信サーバ３３０は、ステップＳ１５２３において、ＵＲＬからライブ映像配信用データの格納場所を取得する。ライブ映像配信サーバ３３０は、ステップＳ１５２５において、ライブ映像配信用データを読み出す。そして、ライブ映像配信サーバ３３０は、ステップＳ１５２７において、ライブ映像配信用メッセージを配信先にユニキャストで配信する。

《通信端末のハードウェア構成》
図１６は、本実施形態に係る通信端末３４０のハードウェア構成を示すブロック図である。

図１６で、ＣＰＵ１６１０は演算制御用のプロセッサであり、プログラムを実行することで図１０の通信端末３４０の機能構成部を実現する。ＲＯＭ１６２０は、初期データおよびプログラムなどの固定データを記憶する。また、通信制御部１００１は、ネットワークを介して他の通信端末や各サーバと通信する。なお、ＣＰＵ１６１０は１つに限定されず、複数のＣＰＵであっても、あるいは画像処理用のＧＰＵを含んでもよい。また、通信制御部１００１は、ＣＰＵ１６１０とは独立したＣＰＵを有して、ＲＡＭ１６４０の領域に送受信データを書き込みあるいは読み出しするのが望ましい。また、ＲＡＭ１６４０とストレージ１６５０との間でデータを転送するＤＭＡＣを設けるのが望ましい（図示なし）。さらに、入出力インタフェース１６６０は、ＣＰＵ１６１０とは独立したＣＰＵを有して、ＲＡＭ１６４０の領域に入出力データを書き込みあるいは読み出しするのが望ましい。したがって、ＣＰＵ１６１０は、ＲＡＭ１６４０にデータが受信あるいは転送されたことを認識してデータを処理する。また、ＣＰＵ１６１０は、処理結果をＲＡＭ１６４０に準備し、後の送信あるいは転送は通信制御部１００１やＤＭＡＣ、あるいは入出力インタフェース１６６０に任せる。

ＲＡＭ１６４０は、ＣＰＵ１６１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ１６４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。ライブ映像配信用データ１６４１は、ライブ映像配信サーバ３３０から配信されたデータである。再生した全周ライブ映像１１２１は、ライブ映像配信用データ１６４１から再生したライブ映像であり、図１１Ｂの全周ライブ映像に相当する。再生したステレオライブ音声１１３１は、ライブ映像配信用データ１６４１から再生したライブ音声である。ユーザ指示方向１１２２は、操作部１０２２から指示されたユーザの全周動画の視聴方向である。指示方向のライブ表示データ１１２３は、再生した全周ライブ映像１１２１からユーザ指示方向１１２２に従い選択表示された表示データである。指示方向のライブ音声データ１１３３は、再生したステレオライブ音声１１３１からユーザ指示方向１１２２に従い混合変更された音声データである。送受信メッセージ１６４８は、通信制御部１００１を介して送受信されるメッセージである。入出力データ１６４９は、入出力インタフェース１６６０を介して入出力されるデータである。

ストレージ１６５０には、データベースや各種のパラメータ、あるいは本実施形態の実現に必要な以下のデータまたはプログラムが記憶されている。ユーザ認証データ１６５１は、本通信端末３４０から全周動画ライブ再生プレーヤを起動させるため、あるいは、ライブ映像自体へのアクセス可否にも利用されるユーザの認証データである。端末認証データ１６５２は、本通信端末３４０から全周動画ライブ再生プレーヤを起動させるための端末の認証データである。

ストレージ１６５０には、以下のプログラムが格納される。通信端末制御プログラム１６５３は、本通信端末３４０の全体を制御する制御プログラムである。全周動画ライブ再生プレーヤ１６５５は、ライブ映像配信サーバ３３０から配信された全周動画をライブ再生するためのアプリケーションである。全周動画ライブ再生プレーヤ１６５５は、配信用データ取得モジュール１６５６と、全周動画再生モジュール１６５７と、立体音声再生モジュール１６５８と、ユーザ指示制御モジュール１６５９と、を含む。配信用データ取得モジュール１６５６は、ライブ映像配信サーバ３３０から配信されたデータを取得するモジュールである。全周動画再生モジュール１６５７は、配信されたデータから全周動画をライブ再生するモジュールである。立体音声再生モジュール１６５８は、配信されたデータから、全周動画のライブ再生に同期して立体音声を再生するモジュールである。ユーザ指示制御モジュール１６５９は、ユーザの指示に応じて全周動画の表示方向を制御するモジュールである。

入出力インタフェース１６６０は、入出力機器との入出力データをインタフェースする。入出力インタフェース１６６０には、表示部１０２１、操作部１０２２、音声出力部１０２３が接続される。また、音声入力部１６６４や、ＧＰＳ位置判定部１６６５が接続される。

なお、図１６のＲＡＭ１６４０やストレージ１６５０には、通信端末３４０が有する汎用の機能や他の実現可能な機能に関連するプログラムやデータは図示されていない。

《通信端末の処理手順》
図１７Ａは、本実施形態に係る通信端末３４０の処理手順を示すフローチャートである。このフローチャートは、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行し、図１０の機能構成部を実現する。

通信端末３４０は、ステップＳ１７１１において、ホームページのアクセスか否かを判定する。ホームページのアクセスであれば、通信端末３４０は、ステップＳ１７１３において、ブラウザを起動する。そして、通信端末３４０は、ステップＳ１７１５において、データ配信サーバ３５０と接続する。

ホームページのアクセスでない場合、通信端末３４０は、ステップＳ１７２１において、ＨＴＭＬタグの取得であるか否かを判定する。本例においては、所望サイトのホームページに貼り付けられたＨＴＭＬタグをクリックしたものとするが、再生要求の操作は限定されない。

ＨＴＭＬタグの取得であれば、通信端末３４０は、ステップＳ１７２３において、ＨＴＭＬタグに対応するコンテンツを取得する。次に、通信端末３４０は、ステップＳ１７２５において、取得したコンテンツが全周ライブ動画コンテンツであるか否かを判定する。全周ライブ動画コンテンツであれば、通信端末３４０は、ステップＳ１７２７において、全周ライブ動画コンテンツを実時間再生するために適切なプレーヤの有無を判定する。適切なプレーヤを有する場合は、通信端末３４０は、ステップＳ１７３１に進んで、全周動画ライブ再生プレーヤを起動する。一方、適切なプレーヤを持たない場合は、通信端末３４０は、ステップＳ１７２９において、再生する全周ライブ動画コンテンツに対応する機能を持った全周動画ライブ再生プレーヤを取得する。なお、全周ライブ動画コンテンツとプレーヤとの対応は１つに限定されるのもではない。当該通信端末において、全周ライブ動画コンテンツの情報が最大限に使用可能なプレーヤが対応付けられるのが望ましい。ただし、上述のように、最適なプレーヤが端末内にインストールされているものである場合は、プレーヤを新たに取得する必要はない。また、使用するプレーヤをユーザに選択させてもよい。

そして、通信端末３４０は、ステップＳ１７３１において、取得した全周動画ライブ再生プレーヤを起動する。そして、通信端末３４０で起動した全周動画ライブ再生プレーヤは、ＨＴＭＬタグに基づきライブ映像配信サーバ３３０およびデータ配信サーバ３５０から所望の全周ライブ動画コンテンツの配信を受けて、ライブ再生された全周動画からユーザの指示に対応する方向の動画を出力する。

ホームページのアクセスでなくＨＴＭＬタグの取得でなければ、あるいは、全周ライブ動画コンテンツでなければ、通信端末３４０は、ステップＳ１７４１において、他の処理を行なう。

（全周動画ライブ再生プレーヤの処理手順）
図１７Ｂは、本実施形態に係る全周動画ライブ再生プレーヤ１０１０の処理Ｓ１７３１の詳細な手順を示すフローチャートである。このフローチャートも、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行するものであるが、以下、全周動画ライブ再生プレーヤ１０１０の処理手順として説明する。

全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４１において、ライブ映像配信サーバ３３０から全周ライブ映像データを取得する。そして、全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４３において、取得した全周ライブ映像データ中の全周動画の各フレームの全周画像を、ユーザ視点を３６０度取り巻く球体上に展開する。次に、全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４５において、ユーザから指示された全周動画の表示方向を取得する。そして、全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４７において、球体上に展開された全周画像列のユーザから指示された表示方向のライブ映像を表示する。また、立体音声の同期出力があれば、全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４９において、ユーザから指示された表示方向のライブ映像に同期して、表示方向に向いた場合の立体音声に調整して出力する。

全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７５１において、ライブ終了（プレーヤ停止）か否かを判定する。ライブ終了でなければ、全周動画ライブ再生プレーヤ１０１０は、ステップＳ１７４１に戻って、全周動画のライブ再生を繰り返す。

本実施形態によれば、全周カメラからの全周動画をライブ配信可能に構成し、ユーザの視線方向指示に応じて表示方向を変更することにより、ユーザが全周動画を視線方向に応じてライブで視聴することにより、臨場感にあふれた映像視聴ができる。

［第３実施形態］
次に、本発明の第３実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態と比べると、全周カメラと撮影配信用ＰＣとが移動しながら全周動画をライブ配信する点で異なる。なお、本実施形態では、例えば、マラソン競技でランナーを追いかける伴走車に、全周カメラを設置して撮影配信用ＰＣから配信する例を説明する。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
図１８は、本実施形態に係る全周動画ライブ配信システム１８００の処理の概要を示す図である。なお、図１８において、図３Ａまたは図１０と同様な構成要素には同じ参照番号を付して、説明は省略する。

図１８においては、全周カメラ３１０および撮影配信用ＰＣ３２０は、車両に配備されて移動している。図１８では、マラソンランナーに伴走してライブ撮影している例を示す。なお、図１８にはマイクは図示していないが、ステレオマイクによるライブ音声を収集してもよい。

全周動画ライブ再生プレーヤ１８１０は、図１０の全周動画ライブ再生プレーヤ１０１０に代わるプレーヤである。なお、図１８の全周動画ライブ再生プレーヤ１８１０には、本実施形態に特有の処理に関連する機能構成部を図示しており、煩雑さを回避するために、図１０の全周動画ライブ再生プレーヤ１０１０の機能構成部などの図示は省かれている。また、通信端末の各々は、ユーザの選択あるいは視聴する全周動画コンテンツに対応して、全周動画ライブ再生プレーヤ１０１０と、全周動画ライブ再生プレーヤ１８１０とを選択する。あるいは、全周動画ライブ再生プレーヤ１０１０と、図１８の機能のみを有する全周動画ライブ再生プレーヤ１８１０とを共に起動し、協働させてもよい。

全周動画ライブ再生プレーヤ１８１０は、映像マッチング処理部１８１１と表示画面生成部１８１２とを含む。映像マッチング処理部１８１１は、データ配信サーバ３５０から全周カメラ３１０の移動経路である既知のマラソンコースの映像を取得する。そして、映像マッチング処理部１８１１は、全周カメラ３１０により撮影されて、ライブ映像配信サーバ３３０を介して配信された全周ライブマラソン映像を、マラソンコースの映像とマッチングして、全周カメラ３１０の現在位置を判定する。表示画面生成部１８１２は、データ配信サーバ３５０からマラソンコースの地図データを取得する。そして、表示画面生成部１８１２は、映像マッチング処理部１８１１からの現在位置の情報に基づいて、マラソンコースの地図データに現在位置と、ユーザにより指示されて表示されたライブ動画の視線方向とを付加する。

ライブ動画１８４１は、伴走車から前方の動画である。ライブ動画１８４２は、伴走車からランナー越しの沿道の動画である。ライブ動画１８４３は、伴走車の後方を追走する次のランナーの動画である。

（通信端末の処理データ）
図１９は、本実施形態に係る通信端末の処理データ１９００の構成を示す図である。処理データ１９００は、全周ライブ映像を撮像している現在位置を判定して、地図上にその現在位置と視線方向とを表示するためのデータである。なお、通信端末は、図１１Ｂに図示したデータも使用する。

処理データ１９００は、ライブ映像配信サーバ３３０から配信されたライブ映像配信用メッセージから再生された全周ライブ映像１９０１と、その全周ライブ映像１９０１の特徴量１９０２と、データ配信サーバ３５０から配信されたマラソンコース映像の特徴量１９０３と、を記憶する。また、処理データ１９００は、全周ライブ映像１９０１の特徴量１９０２とマラソンコース映像の特徴量１９０３とのマッチングから判定された、現在位置１９０４と、ユーザが指示した視線方向１９０５と、を記憶する。さらに、処理データ１９００は、ユーザが指示した視線方向１９０５のライブ表示データ１９０６と、現在位置１９０４を地図上に表示したコース地図表示データ１９０７と、を記憶する。

《全周動画ライブ再生プレーヤの処理手順》
図２０は、本実施形態に係る全周動画ライブ再生プレーヤ１８１０の処理Ｓ１７３１の詳細手順を示すフローチャートである。このフローチャートも、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行するものであるが、以下、全周動画ライブ再生プレーヤ１８１０の処理手順として説明する。

全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００１において、データ配信サーバ３５０からマラソンコースの地図データを取得する。次に、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００３において、データ配信サーバ３５０からマラソンコースの映像を取得する。なお、あらかじめデータ配信サーバ３５０で算出された特徴量を取得しても、映像を取得して通信端末で特徴量を算出してもよい。

全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００５において、ライブ映像配信サーバ３３０から全周ライブ映像データを取得する。次に、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００７において、取得した全周ライブ映像データ中の全周動画の各フレームの全周画像を、ユーザ視点を３６０度取り巻く球体上に展開する。また、全周動画ライブ再生プレーヤ１８１０は、取得した全周ライブ映像データ中の全周動画の各フレームの全周画像の特徴量を抽出する。次に、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００９において、マラソンコースの映像の特徴量と、全周画像の特徴量とをマッチングして、全周カメラ３１０が撮影している現在位置を判定する。なお、現在位置の判定は全ての通信端末で行うのではなく、現在位置の判定を撮影配信用ＰＣまたは現在位置判定用プレーヤで行い、取得した位置とタイムスタンプを紐付けたデータを、データ配信サーバから各通信端末に配信してもよい。

次に、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２０１１において、ユーザから指示された全周動画の表示方向を取得する。そして、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２０１３において、球体上に展開された全周画像列のユーザから指示された表示方向のライブ映像を表示する。同時に、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２０１５において、全周カメラ３１０の現在位置と視線指示方向とを表示したマラソンコース地図を表示する。

全周動画ライブ再生プレーヤ１８１０は、ステップＳ２０１７において、ライブ終了（プレーヤ停止）か否かを判定する。ライブ終了でなければ、全周動画ライブ再生プレーヤ１８１０は、ステップＳ２００５に戻って、全周動画のライブ再生を繰り返す。

本実施形態によれば、移動する全周カメラの現在位置を判定して、地図上に表示することにより、臨場感にあふれた映像視聴ができる上に、ＧＰＳなどがなくてもライブ動画の視聴位置と視聴方向とを知ることができる。

［第４実施形態］
次に、本発明の第４実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態および第３実施形態と比べると、複数地点に配置された複数の全周カメラからユーザが所望の全周カメラからの全周動画を選択できる点で異なる。その他の構成および動作は、第２実施形態、第３実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
図２１Ａは、本実施形態に係る全周動画ライブ配信システム２１０１の処理の概要を示す図である。なお、図２１Ａにおいて、図３Ａ、図１０または図１８と同様な構成要素には同じ参照番号を付して、説明は省略する。また、通信端末の各々は、ユーザの選択あるいは視聴する全周動画コンテンツに対応して、全周動画ライブ再生プレーヤ１０１０と、全周動画ライブ再生プレーヤ１８１０と、全周動画ライブ配信システム２１０１とを選択する。あるいは、全周動画ライブ再生プレーヤ１０１０と、図１８の機能のみを有する全周動画ライブ再生プレーヤ１８１０と、図２１Ａの機能のみを有する全周動画ライブ配信システム２１０１とを組み合わせて起動し、協働させてもよい。

図２１Ａにおいては、複数の全周カメラ３１１〜３１３および全周カメラに対応する複数の撮影配信用ＰＣ３２１〜３２３を、複数地点に配置してユーザが複数の全周動画の選択視聴を可能としている。図２１Ａでは、カヌー競技をコースの複数地点でライブ撮影している例を示す。なお、図２１Ａにはマイクは図示していないが、ステレオマイクによるライブ音声を収集してもよい。

全周動画ライブ再生プレーヤ２１１０は、図１０の全周動画ライブ再生プレーヤ１０１０や図１８の全周動画ライブ再生プレーヤ１８１０に代わるプレーヤである。なお、図２１Ａの全周動画ライブ再生プレーヤ２１１０には、本実施形態に特有の処理に関連する機能構成部を図示しており、煩雑さを回避するために、図１０の全周動画ライブ再生プレーヤ１０１０や図１８の全周動画ライブ再生プレーヤ１８１０の機能構成部などの図示は省かれている。

全周動画ライブ再生プレーヤ２１１０は、映像選択部２１１１を含む。映像選択部２１１１は、全周ライブカヌー映像Ａと、全周ライブカヌー映像Ｂと、全周ライブカヌー映像Ｃと、をユーザの選択指示に従って選択して通信端末に配信する。全周ライブカヌー映像Ａは、全周カメラ３１１が撮像してライブ映像配信サーバ３３０を介して配信されるライブ映像である。全周ライブカヌー映像Ｂは、全周カメラ３１２が撮像してライブ映像配信サーバ３３０を介して配信される映像である。全周ライブカヌー映像Ｃは、全周カメラ３１３が撮像してライブ映像配信サーバ３３０を介して配信される映像である。

ライブ動画２１４１は、全周カメラ３１１から撮像したカヌー選手２１５１の方向の動画である。ライブ動画２１４２は、全周カメラ３１２から撮像したカヌー選手２１５２の方向の動画である。ライブ動画２１４３は、全周カメラ３１３から撮像したカヌー選手２１５３の方向の動画である。ユーザは、視聴したい全周動画を３つのライブ動画から選択可能である。

図２１Ｂは、本実施形態に係る全周動画ライブ配信システム２１０２の処理の概要を示す図である。なお、図２１Ｂにおいて、図３Ａ、図１０、図１８または図２１Ａと同様な構成要素には同じ参照番号を付して、説明は省略する。また、通信端末の各々は、ユーザの選択あるいは視聴する全周動画コンテンツに対応して、全周動画ライブ再生プレーヤ１０１０と、全周動画ライブ再生プレーヤ１８１０と、全周動画ライブ配信システム２１０２とを選択する。あるいは、全周動画ライブ再生プレーヤ１０１０と、図１８の機能のみを有する全周動画ライブ再生プレーヤ１８１０と、図２１Ｂの機能のみを有する全周動画ライブ配信システム２１０２とを組み合わせて起動し、協働させてもよい。

図２１Ｂにおいては、複数の全周カメラ３１１〜３１３を複数地点に配置してユーザが複数の全周動画の選択視聴を可能としている。図２１Ｂでは、野球場での試合を複数地点でライブ撮影している例を示す。なお、図２１Ｂでは、撮影配信用ＰＣの図示は省略している。また、図２１Ｂにはマイクは図示していないが、ステレオマイクによるライブ音声を収集してもよい。

全周動画ライブ再生プレーヤ２１１０は、図１０の全周動画ライブ再生プレーヤ１０１０や図１８の全周動画ライブ再生プレーヤ１８１０に代わるプレーヤである。なお、図２１Ｂの全周動画ライブ再生プレーヤ２１１０には、本実施形態に特有の処理に関連する機能構成部を図示しており、煩雑さを回避するために、図１０の全周動画ライブ再生プレーヤ１０１０や図１８の全周動画ライブ再生プレーヤ１８１０の機能構成部などの図示は省かれている。

全周動画ライブ再生プレーヤ２１１０は、映像選択部２１１１を含む。映像選択部２１１１は、全周ライブ野球映像Ａと、全周ライブ野球映像Ｂと、全周ライブ野球映像Ｃと、をユーザの選択指示に従って選択して通信端末に配信する。全周ライブ野球映像Ａは、全周カメラ３１１が撮像してライブ映像配信サーバ３３０を介して配信される、バックネット裏からのライブ映像である。全周ライブ野球映像Ｂは、全周カメラ３１２が撮像してライブ映像配信サーバ３３０を介して配信される、バックスクリーンからの映像である。全周ライブ野球映像Ｃは、全周カメラ３１３が撮像してライブ映像配信サーバ３３０を介して配信される、ドーム天井からの映像である。

ライブ動画２１４４は、全周カメラ３１１から撮像した動画である。ライブ動画２１４５は、全周カメラ３１２から撮像した動画である。ライブ動画２１４６は、全周カメラ３１３から撮像した動画である。ユーザは、視聴したい全周動画を３つのライブ動画から選択可能である。

（通信端末の処理データ）
図２２は、本実施形態に係る通信端末の処理データ２２００の構成を示す図である。処理データ２２００は、図２１Ａのカヌー競技に使用する複数の全周映像を選択するデータを示す。

処理データ２２００は、全周映像の取得元２２０１と、ユーザが取得元を選択した選択フラグ２２０２と、を記憶する。また、処理データ２２００は、ライブ映像配信サーバ３３０から配信されたライブ映像配信用メッセージから再生された全周ライブ映像２２０３と、ユーザが指示した視線方向２２０４と、を記憶する。また、処理データ２２００は、ユーザが指示した視線方向２２０４のライブ表示データ２２０５と、選択した全周カメラ位置を地図上に表示したコース地図表示データ２２０６と、を記憶する。

《全周動画ライブ再生プレーヤの処理手順》
図２３は、本実施形態に係る全周動画ライブ再生プレーヤ２１１０の処理Ｓ１７３１の詳細手順を示すフローチャートである。このフローチャートも、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行するものであるが、以下、全周動画ライブ再生プレーヤ２１１０の処理手順として説明する。なお、図２３は、図２１Ａのカヌー競技におけるフローチャートを示す。

全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０１において、データ配信サーバ３５０からカヌー競技コースの地図データを取得する。

全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０３において、ユーザによる全周映像の配信元の選択指示を取得する。全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０５において、選択指示された配信元からのライブ映像に接続する。

全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０７において、ライブ映像配信サーバ３３０から選択配信元の全周ライブ映像データを取得して球体上に展開する。次に、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０９において、ユーザから指示された全周動画の表示方向を取得する。そして、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３１１において、球体上に展開された全周画像列のユーザから指示された表示方向のライブ映像を表示する。同時に、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３１３において、選択された全周カメラと視線指示方向とを表示したカヌーコース地図を表示する。

全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３１５において、ユーザから全周映像の配信元の変更指示があったか否かを判定する。全周映像の配信元の変更指示があった場合、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０３に戻って、新たな配信元からの全周映像を表示する。

全周映像の配信元の変更指示がなかった場合、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３１７において、ライブ終了（プレーヤ停止）か否かを判定する。ライブ終了でなければ、全周動画ライブ再生プレーヤ２１１０は、ステップＳ２３０７に戻って、全周動画のライブ再生を繰り返す。

本実施形態によれば、複数の全周カメラから選択して、撮像位置を地図上に表示することにより、ユーザの所望の位置からの臨場感にあふれた全周映像を視聴ができる。

［第５実施形態］
次に、本発明の第５実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態乃至第４実施形態と比べると、全周動画のライブ再生に対して所望の情報を付加する点で異なる。本実施形態においては、ライブ再生中の全周動画内の対象を見付けてテロップを付加する例を示す。なお、本実施形態はテロップの付加に限定されず、全周動画ライブ再生に他の情報を付加表示する技術として種々適用が可能である。その他の構成および動作は、第２実施形態から第４実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
図２４は、本実施形態に係る全周動画ライブ配信システム２４００の処理の概要を示す図である。なお、図２４において、図３Ａ、図１０、図１８、図２１Ａまたは図２１Ｂと同様な構成要素には同じ参照番号を付して、説明は省略する。また、通信端末の各々は、ユーザの選択あるいは視聴する全周動画コンテンツに対応して、全周動画ライブ再生プレーヤ１０１０と、全周動画ライブ再生プレーヤ１８１０と、全周動画ライブ配信システム２１０１や２１０２と、全周動画ライブ配信システム２４００とを選択する。あるいは、全周動画ライブ再生プレーヤ１０１０と、図１８の機能のみを有する全周動画ライブ再生プレーヤ１８１０と、図２１Ａや図２１Ｂの機能のみを有する全周動画ライブ配信システム２１０１や２１０２と、図２４の機能のみを有する全周動画ライブ配信システム２４００とを組み合わせて起動し、協働させてもよい。例えば、特徴点との判定は全ての通信端末で行なうのではなく、撮影配信用ＰＣまたは判定用プレーヤで行い、検索対象の有無とタイムスタンプとを紐付けたデータを、データ配信サーバから各通信端末に配信してもよい。

図２４においては、全周カメラ３１０および撮影配信用ＰＣ３２０は、車両に配備されて移動している。図２４では、街中を移動しながらライブ撮影している例を示す。なお、図２４にはマイクは図示していないが、ステレオマイクによるライブ音声を収集してもよい。

全周動画ライブ再生プレーヤ２４１０は、上記実施形態の各全周動画ライブ再生プレーヤに代わるプレーヤである。なお、図２４の全周動画ライブ再生プレーヤ２４１０には、本実施形態に特有の処理に関連する機能構成部を図示しており、煩雑さを回避するために、上記実施形態の全周動画ライブ再生プレーヤの機能構成部などの図示は省かれている。

全周動画ライブ再生プレーヤ２４１０は、テロップ挿入部２４１１を含む。テロップ挿入部２４１１は、データ配信サーバ３５０から全周動画ライブ再生に付加するテロップデータを取得する。そして、テロップ挿入部２４１１は、全周カメラ３１０により撮影されて、ライブ映像配信サーバ３３０を介して配信された全周街中のライブ映像の所定位置に、データ配信サーバ３５０から取得したテロップを重ねて表示する。なお、所望の位置にテロップを付加するために、データ配信サーバ３５０からテロップ付加の対象物の特徴量を取得して、全周映像の特徴量とマッチングして、対象物を見つけ出してもよい。

ライブ動画２４４１は、店舗Ａのためのテロップ２４５１が付加表示される。ライブ動画２４４２は、店舗Ｂのためのテロップ２４５２が付加表示される。ライブ動画２４４３は、店舗Ｃのためのテロップ２４５３が付加表示される。なお、図２４には、店舗の説明が付加表示されたが、付加情報に制限はない。例えば、付加情報は、表示情報に限定されず音声情報であってもよい。

（通信端末の処理データ）
図２５は、本実施形態に係る通信端末の処理データ２５００の構成を示す図である。処理データ２５００は、全周ライブ映像にテロップなどの付加用データを付加するために使用する。

処理データ２５００は、ライブ映像配信サーバ３３０から配信されたライブ映像配信用メッセージから再生された全周ライブ映像２５０１と、ユーザが指示した視線方向２５０２と、ユーザが指示した視線方向２５０２のライブ表示データ２５０３と、を記憶する。また、処理データ２５００は、各全周ライブ映像２５０１に対して、１つまたは複数の検索対象物の特徴量２５０４と、付加用データ２５０５と、付加位置２５０６と、を記憶する。そして、処理データ２５００は、特徴量の合致フラグ２５０７と、付加用データを付加した全周ライブ付加表示データ２５０８と、を記憶する。

《全周動画ライブ再生プレーヤの処理手順》
図２６は、本実施形態に係る全周動画ライブ再生プレーヤ２４１０）の処理Ｓ１７３１の詳細手順を示すフローチャートである。このフローチャートも、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行するものであるが、以下、全周動画ライブ再生プレーヤ２４１０の処理手順として説明する。

全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０１において、データ配信サーバ３５０から検索対象物の情報を取得する。情報は対象物の特徴量であってもよい。

全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０３において、ライブ映像配信サーバ３３０から選択配信元の全周ライブ映像データを取得して球体上に展開する。次に、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０５において、ユーザから指示された全周動画の表示方向を取得する。

全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０７において、ユーザの指示した方向に対象物があるか否かを特徴量のマッチングで判定する。対象物があると判定した場合、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０９において、指示方向の全周ライブ表示データの対象物に関連情報（テロップ）を付加する。そして、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６１１において、球体上に展開された全周画像列のユーザから指示された表示方向のライブ映像を、添付されたテロップと共に表示する。ステップＳ２６０７において対象物がないと判定した場合、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６１１に進む。

全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６１３において、検索対象物の変更があったか否かを判定する。検索対象物の変更があった場合、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０１に戻って、新たな検索対象物を付加した全周映像を表示する。

検索対象物の変更がなかった場合、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６１５において、ライブ終了（プレーヤ停止）か否かを判定する。ライブ終了でなければ、全周動画ライブ再生プレーヤ２４１０は、ステップＳ２６０３に戻って、全周動画のライブ再生を繰り返す。

本実施形態によれば、全周カメラで撮像した全周動画の表示に、対象物に対応する情報を付加することにより、ユーザの所望の位置からの臨場感にあふれた全周映像を対象物の情報を含めて視聴ができる。

［第６実施形態］
次に、本発明の第６実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態乃至第５実施形態と比べると、全周動画のライブ再生から所望の対象物を選別して表示する点で異なる。本実施形態においては、サッカーの全周動画から対象選手を選別してライブ再生する。なお、対象者（物）の特徴は、人物であれば顔や服装、装飾品、模様（スポーツ選手の背番号などを含む）を含み、物体であれば、形状、色、模様などを含むが、これに限定されない。その他の構成および動作は、第２実施形態から第５実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
（処理の概要）
図２７Ａは、本実施形態に係る全周動画ライブ配信システム２７００の処理の概要を示す図である。なお、図２７Ａにおいて、図３Ａ、図１０、図１８、図２１Ａ、図２１Ｂまたは図２４と同様な構成要素には同じ参照番号を付して、説明は省略する。また、通信端末の各々は、ユーザの選択あるいは視聴する全周動画コンテンツに対応して、全周動画ライブ再生プレーヤ１０１０と、全周動画ライブ再生プレーヤ１８１０と、全周動画ライブ配信システム２１０１や２１０２と、全周動画ライブ配信システム２４００と、全周動画ライブ配信システム２７００を選択する。あるいは、全周動画ライブ再生プレーヤ１０１０と、図１８の機能のみを有する全周動画ライブ再生プレーヤ１８１０と、図２１Ａや図２１Ｂの機能のみを有する全周動画ライブ配信システム２１０１や２１０２と、図２４の機能のみを有する全周動画ライブ配信システム２４００と、図２７Ａの機能のみを有する全周動画ライブ配信システム２７００とを組み合わせて起動し、協働させてもよい。例えば、特徴点との判定は全ての通信端末で行なうのではなく、撮影配信用ＰＣまたは判定用プレーヤで行い、全選手分のデータとタイムスタンプとを紐付けたデータを、データ配信サーバから各視聴端末に配信してもよい。

図２７Ａにおいては、複数の全周カメラ３１４〜３１７を複数地点に配置してユーザが複数の全周動画の選択視聴を可能としている。図２７Ａでは、サッカー場での試合を複数地点でライブ撮影している例を示す。なお、図２７Ａでは、撮影配信用ＰＣの図示は省略している。また、図２７Ａにはマイクは図示していないが、ステレオマイクによるライブ音声を収集してもよい。

全周動画ライブ再生プレーヤ２７１０は、上記実施形態の全周動画ライブ再生プレーヤに代わるプレーヤである。なお、図２７Ａの全周動画ライブ再生プレーヤ２７１０には、本実施形態に特有の処理に関連する機能構成部を図示しており、煩雑さを回避するために、上記実施形態の全周動画ライブ再生プレーヤの機能構成部などの図示は省かれている。

全周動画ライブ再生プレーヤ２７１０は、選手識別部２７１１を含む。選手識別部２７１１は、データ配信サーバ３５０から取得した選手選択用データと、全周カメラ３１４〜３１７が撮像した全周映像とのマッチングにより、選手を見つけて、その選手が映っている全周動画の所定方向を、望ましくはズームイン／ズームアウトして表示する。

本実施形態において、サッカー場には、全周カメラ３１４〜３１７が設置されている。全周カメラ３１４は、正面スタンドに配置されている。全周カメラ３１５は、一方のゴール背後に設置されている。全周カメラ３１６は、他方のゴール背後に配置されている。全周カメラ３１７は、競技場中空からサッカー場全体を撮像している。

ライブ動画２７４１は、全周カメラ３１４から対象選手２７５１をズームインして撮像した動画である。ライブ動画２７４２は、全周カメラ３１７から対象選手２７５１をズームインして撮像した動画である。ライブ動画２７４３は、全周カメラ３１６から対象選手２７５１をズームアウトして撮像した動画である。ユーザは、視聴したい選手の全周動画を自動選択して追跡することが可能である。

（動作の概要）
図２７Ｂは、本実施形態に係る全周動画ライブ配信システム２７００の動作の概要を示す図である。図２７Ｂの左図には、全周動画ライブ再生プレーヤ２７１０において、追跡選手を選択する操作の画面遷移を示す。また、図２７Ｂの右図には、全周動画ライブ再生を画面全体ではなく、画面の一部に再生表示する例を示す。なお、図２７Ｂの画面遷移や一部表示は、他の実施形態においても同様である。

＜画面遷移＞
（１）図２７Ｂの左最上段は、図２７Ａのライブ動画２７４１を示す画面である。
（２）マウス、タッチパネル、端末のボタン等ユーザによる規定の操作により、左図２段目のように、操作用ＵＩ２７６１および２７６２を表示する。操作用ＵＩ２７６１および２７６２には、追跡対象選択メニュー表示/非表示ボタン２７６２が含まれている。操作用ＵＩ２７６１は、全周カメラと視線との選択・表示である。
（３）操作用ＵＩ上の追跡対象選択メニュー表示/非表示ボタン２７６２のクリックにより、左図３段目のように、追跡対象選択メニュー２７６３を表示する。追跡対象選択メニュー表示/非表示ボタン２７６２は、ボタンが押され、メニューが表示されている状態であることを示す。この状態に遷移するための、特別なショートカット操作を用意してもよい。追跡対象選択メニュー２７６３には、選択可能な対象（この場合は選手、監督、審判等）の一覧が表示される。既に追跡対象が選択されている場合は、該当項目を選択状態とする。
（４）ユーザ操作により追跡対象を選択する。選択された項目は、左図最下段のように、色を変更する、特別なマークを表示する等して、選択状態であることがわかるようにする。また、操作用ＵＩ上に、選択された追跡対象の画像、番号、名前等を簡易表示してもよい。自動追跡機能を有効とし、結果を動画エリアで再生中の映像に反映させる。これにより、ユーザはテレビのチャンネルを切り替えるのと同様の感覚で、順次追跡対象を切り替えながら、好みのアングルを探すことが可能となる。
（５）ユーザ操作により選択状態にある追跡対象を解除する場合、（２）〜（４）とは逆に、対象項目の表示を通常に戻し、操作用ＵＩ上から追跡対象の表示を消去する。自動追跡機能を無効とし、結果を動画エリアで再生中の映像に反映させる。
（６）操作用ＵＩ上の追跡対象選択メニュー表示/非表示ボタン２７６２が操作された場合、追跡対象選択メニュー２７６３を消去する。追跡対象選択メニュー表示/非表示ボタン２７６２は解除され、メニューが表示されていない状態であることを示す。ユーザによる操作が一定時間ない場合、操作用ＵＩ２７６１および２７６２を消去する。

＜部分表示＞
図２７Ｂの右図には、動画を通信端末の全画面に表示しない場合に、動画エリアの外部に追跡対象選択メニュー２７６３を表示する例が示されている。

（通信端末の処理データ）
図２８は、本実施形態に係る通信端末の処理データ２８００の構成を示す図である。処理データ２８００は、ユーザが望む対象者（物）を追跡して、全周映像を選択してその表示方向を決定し、必要であればズームイン／ズームアウトをして、対象者（物）を追跡表示するために使用される。

処理データ２８００は、追跡対象物の特徴量２８０１と、マッチングの結果、対象者が見付かった全周ライブ映像２８０２と、対象者が見付かった方向２８０３と、を記憶する。また、処理データ２８００は、全周ライブ映像２８０２内の方向２８０３の全周ライブ表示データ２８０４と、ズームイン／ズームアウト２８０５と、を記憶する。

《全周動画ライブ再生プレーヤの処理手順》
図２９は、本実施形態に係る全周動画ライブ再生プレーヤ２７１０）の処理Ｓ１７３１の詳細手順を示すフローチャートである。このフローチャートも、図１６のＣＰＵ１６１０がＲＡＭ１６４０を使用しながら実行するものであるが、以下、全周動画ライブ再生プレーヤ２７１０の処理手順として説明する。

全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０１において、データ配信サーバ３５０から追跡対象物の情報を取得する。情報は対象物の特徴量であってもよい。

全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０３において、ライブ映像配信サーバ３３０から複数の選択配信元の全周ライブ映像データを取得して球体上に展開する。

全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０５において、全周動画に対象物があるか否かを特徴量のマッチングで判定する。対象物があると判定した場合、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０７において、追跡対象物が映っている全周ライブの配信元を選択する。次に、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０９において、追跡対象物が映っている全周ライブの方向を選択する。そして、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９１１において、追跡対象物の映っている全周ライブの選択方向を表示する。その時に、必要であれば、ズームイン／ズームアウトの処理を行なう。ステップＳ２９０５において対象物がないと判定した場合、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９１７において、今まで出力中の全周ライブ映像データと、現在の表示方向とを維持して、全周ライブの出力を継続する。そして、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９１３に進む。

全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９１３において、追跡対象物の変更があったか否かを判定する。追跡対象物の変更があった場合、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０１に戻って、新たな追跡対象物が映った全周映像を表示する。

追跡対象物の変更がなかった場合、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９１５において、ライブ終了（プレーヤ停止）か否かを判定する。ライブ終了でなければ、全周動画ライブ再生プレーヤ２７１０は、ステップＳ２９０３に戻って、全周動画のライブ再生を繰り返す。

本実施形態によれば、全周カメラで撮像した全周動画の内で、追跡対象物が映っている動画をライブ再生することにより、ユーザの所望の追跡対象者（物）を含む臨場感にあふれた全周映像を視聴ができる。

［第７実施形態］
次に、本発明の第７実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態乃至第６実施形態と比べると、全周動画をテレビにライブ配信して視聴可能とする点で異なる。その他の構成および動作は、第２実施形態から第６実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
図３０は、本実施形態に係る全周動画ライブ配信システム３０００の処理の概要を示す図である。なお、図３０において、図３Ａ、図１０、図１８、図２１Ａ、図２１Ｂ、図２４または図２７Ａと同様な構成要素には同じ参照番号を付して、説明は省略する。

ライブ映像配信サーバ３３０は、テレビ局３０７０に対して全周動画をライブ配信し、テレビ局３０７０は、テレビ受像機３０４０に対して全周動画をライブ放送する。テレビ受像機３０４０は、テレビ放送信号により本実施形態の全周動画を受信する。

テレビ局３０７０は、テレビ映像送信部３０７１と、テレビ画面変換部３０７２と、を有する。テレビ画面変換部３０７２は、ライブ映像配信サーバ３３０から配信された全周ライブ動画データを、全周ライブ放送可能なテレビ画面データに変換する。そして、テレビ映像送信部３０７１は、変換された全周ライブ放送可能なテレビ画面データを送信する。

テレビ受像機３０４０には、データ量により必要であれば全周映像を間引きして、テレビ放送信号により全周映像を送信する。テレビ受像機３０４０では、受信したテレビ放送信号の映像データから全周映像を復元する。そして、復元された全周映像を球体３０３０に投影する。そして、球体３０３０に投影された全周映像のユーザの視線方向指示に応じた映像を選択して、テレビ画面に投射して走査出力する。

テレビ映像画面３０４１〜３０４３は、全周動画のユーザ指示方向の選択表示を示す。

（テレビ局における処理データ）
図３１は、本実施形態に係るテレビ局３０７０における処理データの変換を示す図である。

全周カメラで撮像された全周映像が、例えば、１５フレーム／秒であれば、ライブ映像配信サーバ３３０からテレビ局３０７０へも１５フレーム／秒で配信される。全周カメラで撮像された全周映像は半分に分割されて、現在のデジタル放送における３０フレーム／秒で放送される。また、全周カメラで撮像された全周映像は１／４に分割されて、現在のデジタル放送における６０フレーム／秒で放送される。ただし、放送ビットレートおよび対応解像度が全周ライブ動画データの転送に十分であれば、全周映像の分割を行なう必要はなくフレーム補完処理（同じフレームを繰り返す、または、中間フレームを合成する）によって、３０フレーム／秒または６０フレーム／秒またはその他放送で使用されるフレームレートへの変換を行ってもよい。なお、フレームレートの変換処理は、撮影配信用ＰＣ、ライブ映像配信サーバ、テレビ局のいずれでも行なうことが可能であるが、テレビ局内設備において行なうことが最も効率的だと思われる。

テレビ受像機３０４０においては、全周映像が復元されると共に、間のフレームが補完される。そして、再生した全周ライブ画像から、ユーザの指示に応じて視線を変化させ、テレビ映像画面３０４１〜３０４３がそれぞれ表示される。

本実施形態によれば、全周カメラで撮像した全周動画をテレビ放送によりテレビ受像機にライブ再生することにより、ユーザが臨場感にあふれた全周映像をテレビ視聴できる。

［第８実施形態］
次に、本発明の第８実施形態に係る全周動画ライブ配信システムについて説明する。本実施形態に係る全周動画ライブ配信システムは、上記第２実施形態乃至第７実施形態と比べると、全周動画のライブ再生をヘッドマウンティングディスプレイ（以下、ＨＭＤ）で視聴する、特に３次元視聴する点で異なる。その他の構成および動作は、第２実施形態から第７実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

《全周動画ライブ配信システム》
図３２は、本実施形態に係る全周動画ライブ配信システム３２００の処理の概要を示す図である。なお、図３２において、図３Ａ、図１０、図１８、図２１Ａ、図２１Ｂ、図２４および図２７Ａと同様な構成要素には同じ参照番号を付して、説明は省略する。

全周動画ライブ配信システム３２００は、図１８のマラソンの全周動画の例を示している。図３２において、ユーザ３２４１はＨＭＤ３２４０によって全周動画を視聴している。そして、その視線方向は、ＨＭＤ３２４０が有する加速度センサによるユーザ３２４１の頭の向きの変化に応じて変更される。したがって、ユーザ３２４１が１回転すると全周動画全体を視聴できることとなる。

本実施形態によれば、全周カメラで撮像した全周動画を頭の回転を検知するセンサを有するＨＭＤで視聴することにより、ユーザが指の指示でなく自分の動きに合致した臨場感にあふれた全周映像をテレビ視聴できる。

［他の実施形態］
なお、上記実施形態では、全周カメラを、周囲３６０度を撮影する５つのカメラと天空を撮影する１つのカメラとを有するカメラとして、説明した。しかしながら、カメラの数は本例に限定されない。映像の精度（解像度）やライブのための処理速度などから決定されればよい。また、全周カメラのレンズが１つの超広角レンズ等からなる場合は、全周画像の合成処理が不要となる。また、全周カメラのレンズが１つで鏡面撮影方式により円錐状の鏡面を撮影して、全周動画を取得する場合は、全周画像の生成処理は本実施形態と異なったものとなる。本発明は、全周カメラの構造によらず適用が可能であり、それらも本発明の範疇に含まれる。

また、上記実施形態においては、プレーヤにおけるマッピング用立体上への展開として、球体マッピングを行なう例を示したが、マッピング用立体は球体に限定されず、円筒マッピングや多面体マッピングであってもよい。そして、多面体マッピングの場合には、各面に対応する画像を、配信側またはサーバ側（またはプレーヤ側）で切り出すことになる。

また、上記実施形態においては、全周カメラの撮像位置や全周動画中から対象者（物）
を見付けるためのマッチング、あるいは、再生する全周動画にテロップや音声などを付加するためのマッチングを、全周動画ライブ再生プレーヤで実現する例を示した。しかしながら、撮影配信用ＰＣがデータ配信サーバから映像や画像、その特徴量を取得して、全周カメラの選択や、対象者（物）の追跡、テロップや音声などの付加を実行して、その結果を、ライブ映像配信サーバまたはデータ配信サーバを介してユーザの通信端末に配信する構成であってもよい。その場合には、図３Ａ、図１８、図２１Ａおよび図２１Ｂ（データ配信サーバは省略）、図２４、図２７Ａ、図３０および図３２に破線で示したように、影配信用ＰＣがデータ配信サーバから映像や画像、その特徴量を取得する。

以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。

また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるＷＷＷ(World Wide Web)サーバも、本発明の範疇に含まれる。特に、少なくとも、上述した実施形態に含まれる処理ステップをコンピュータに実行させるプログラムを格納した非一時的コンピュータ可読媒体（non-transitory computer readable medium）は本発明の範疇に含まれる。

Claims (11)

1. ユーザによる追跡対象物の指示を受け付ける受付手段と、
   全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信手段と、
   前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生手段と、
   を備え、
   前記全周動画データ受信手段は、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択手段を備える通信端末装置。
2. 前記全周動画再生手段は、受信した前記全周動画データから前記全周動画を、全周フレーム画像の単位で、視点を内部に含むマッピング用立体上に展開する全周動画展開手段を有し、前記視点からの視線方向を前記追跡対象物に向けた範囲の動画映像を表示する、請求項１に記載の通信端末装置。
3. 前記全周動画再生手段は、前記視点を前記マッピング用立体に近づけて前記追跡対象物へのズームインを行ない、前記視点を前記マッピング用立体から遠ざけて前記追跡対象物からのズームアウトを行なう、請求項２に記載の通信端末装置。
4. 前記全周動画の特徴量と、既知の位置からあらかじめ撮影された画像の特徴量とのマッチングに基づいて、前記全周動画を撮影した全周カメラの位置を判定する位置判定手段、をさらに備え、
   前記全周動画再生手段は、前記選択された動画映像と、前記位置判定手段が決定した位置とを表示する請求項１乃至３のいずれか１項に記載の通信端末装置。
5. 前記全周動画データに対応する立体音声データを受信する立体音声データ受信手段をさらに備え、
   前記全周動画再生手段は、前記立体音声データから、前記動画映像の表示範囲に応じた立体音声を再生して出力する、請求項１乃至４のいずれか１項に記載の通信端末装置。
6. 前記追跡対象物に対応する表示情報および音声情報の少なくともいずれかを含む情報を取得する取得手段をさらに備え、
   前記全周動画再生手段は、前記追跡対象物に対応する前記情報を合成して、前記動画映像を出力する請求項１乃至５のいずれか１項に記載の通信端末装置。
7. 前記通信端末装置はテレビ受像機であって、
   前記全周動画再生手段は、前記全周動画データからテレビ用映像データを生成するテレビ局から送信された前記テレビ用映像データに基づいて再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して走査表示する、請求項１乃至６のいずれか１項に記載の通信端末装置。
8. 通信端末装置の受付手段が、ユーザによる追跡対象物の指示を受け付ける受付ステップと、
   前記通信端末装置の全周動画データ受信手段が、全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信ステップと、
   前記通信端末装置の全周動画再生手段が、前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生ステップと、
   を含み、
   前記全周動画データ受信ステップは、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択ステップを含む通信端末装置の制御方法。
9. ユーザによる追跡対象物の指示を受け付ける受付ステップと、
   全周カメラで撮影された全周動画から生成された全周動画データを受信する全周動画データ受信ステップと、
   前記全周動画データから全周動画を再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択して表示する全周動画再生ステップと、
   を通信端末装置が有するコンピュータに実行させる通信端末装置の制御プログラムであって、
   前記全周動画データ受信ステップは、少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、前記追跡対象物を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する映像選択ステップを含む通信端末装置の制御プログラム。
10. 少なくとも２つの全周カメラと、
    前記全周カメラで撮影された全周動画を取得して時系列の全周フレーム画像データを生成する全周画像生成手段と、
    前記時系列の全周フレーム画像データに対して符号化を行なって全周動画データを生成する全周動画データ生成手段と、
    前記少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する第１選択手段と、
    前記全周動画データを再生し、再生された前記全周動画から、前記追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択する第２選択手段と、
    前記追跡対象物を含む動画映像を表示する動画再生手段と、
    を備える全周動画配信システム。
11. 全周画像生成手段が、全周カメラで撮影された全周動画を取得して時系列の全周フレーム画像データを生成する全周画像生成ステップと、
    全周動画データ生成手段が、前記時系列の全周フレーム画像データに対して符号化を行なって全周動画データを生成する全周動画データ生成ステップと、
    第１選択手段が、前記少なくとも２つの全周カメラからの全周動画に基づいて生成された少なくとも２つの全周動画データから、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む全周動画データであって、かつ、前記追跡対象物を撮影する視線方向の表示に基づき前記ユーザにより選択指示された前記全周動画データを選択する第１選択ステップと、
    第２選択手段が、前記全周動画データを再生し、再生された前記全周動画から、ユーザにより指示された追跡対象物の特徴量にマッチングする特徴量を含む範囲の動画映像を選択する第２選択ステップと、
    動画再生手段が、前記追跡対象物を含む動画映像を表示する動画再生ステップと、
    を含む全周動画配信方法。

Images