図1は、本実施例における映像表示システムの構成模式図である。なお、本発明は、複数のユーザが存在する場合に適用するが、説明を簡単にするため、本実施例では、図1に示すように、二人のユーザ(第1のユーザ10Aと、第2のユーザ10B)に限定して説明する。
図1において、映像表示装置であるHMD11Aを装着した第1のユーザ10Aと、HMD11Bを装着した第2のユーザ10Bは、それぞれ無線ルータ12Aと無線ルータ12Bを介して、ネットワーク網13に接続している。ネットワーク網13には、配信サーバ14と、管理サーバ15が接続されている。
配信サーバ14は、ライブコンテンツをライブストリーミング(live streaming)で、ネットワーク網13上に、ライブ配信する。配信サーバ14から配信されたライブストリーミングのライブコンテンツは、ネットワーク網13を介して、無線ルータ12A経由でHMD11Aと、無線ルータ12B経由でHMD11Bに、それぞれ配信される。配信されたライブコンテンツは、映像はHMDの表示画面に表示し、音声はHMDのスピーカから出力する。
管理サーバ15は、ネットワーク網13を介して取得した、複数の情報を管理する。管理サーバ15が管理する情報は、例えば、コンテンツの情報や、ユーザに関する情報、無線ルータ12Aを介して取得したHMD11Aの動作情報(第1のユーザ10Aの動作情報)や音声情報、無線ルータ12Bを介して取得したHMD11Bの動作情報(第2のユーザ10Bの動作情報)や音声情報、などである。
コンテンツの情報には、ライブのタイトル情報、演奏者や歌手などのアーティスト情報、ライブコンテンツの開始時刻及び終了時刻などの時間情報、楽曲の拍子やテンポなどの楽譜情報などがある。
ユーザに関する情報には、氏名を含むニックネームやハンドルネームなどのユーザ情報(ユーザ識別情報)、ユーザ固有のアバター情報、ライブコンテンツを同時に視聴する複数ユーザを管理する管理情報、などがある。
動作情報は、手を叩く、首や手を振る、手を上下する、立つ、座る、ステップ、ジャンプ、などの動作を、アバターの各関節等を動かすベクトル情報として保持している。
このようなシステム構成により、ユーザは、ライブコンテンツを視聴しながら、視聴するユーザとは異なる他者の分身でありコンピュータ生成画像であるアバターを、他者の動作情報を付加して、ライブコンテンツに重畳して表示することができ、アバターを介して友人との楽しい状況を共有することができる。
図2は、第1のユーザ10Aが、ライブコンサートを視聴している状態を説明するための模式図である。図2において、配信サーバ14は、アーティストが演じているライブコンサート全体の映像21を配信している。
ライブコンサート全体の映像21は、例えば、複数台のカメラで撮影した映像を合成することや、360度カメラで撮影することなどで実現することができる。
このライブコンサート全体の映像21が配信されることにより、第1のユーザ10Aが装着するHMD11Aの向いている方向の変化に応じたライブコンサートの映像を、HMD11Aの表示画面上に表示することができる。例えば、HMD11Aの向きを、後ろ向きに転じると、観客席の映像が表示される。
第1のユーザ10Aが装着するHMD11Aの表示画面22には、配信されたライブ会場全体の映像21から、HMD11Aの向いている方向に応じて切り出した映像が表示されている。また、その視聴位置は、ライブ会場全体の映像21の中心の最も良い視聴位置と思われるライブ会場の中央位置23で視聴している状態を想定している。勿論、第2のユーザ10Bが装着するHMD11Bの表示画面には、ライブ会場全体の映像21の中心の最も良い視聴位置と思われるライブ会場の中央位置23で視聴している状態を想定している。
本実施例で表示する第2のユーザ10Bの分身であるアバター24は、管理サーバ15に格納されている第2のユーザ10Bのユーザ固有のアバター情報を用いている。
第2のユーザ10Bの分身であるアバター24の表示位置は、任意で良いが、本実施例では、第1のユーザ10Aと第2のユーザ10Bの相対位置を維持している。例えば、第1のユーザ10Aの右隣に第2のユーザ10Bが存在し、第2のユーザ10Bの左隣に第1のユーザ10Aが存在している状態を、第1のユーザ10Aと第2のユーザ10Bが、相互に認識していることを意味している。本実施例における図2の模式図では、第2のユーザ10Bの分身であるアバター24は、第1のユーザ10Aの視聴位置の右側に存在するように設定している。なお、第3のユーザが存在した場合も同様に、3者のユーザの相対位置は維持される。
また、後ろを含む他の観客席には、一般的な任意のアバターを配置することもできるが、ネットワーク等を介して、外部のサーバから入手した多種のアバターを配置することもできる。
HMD11Aは、ライブコンサートで演奏される音楽のリズムを検出し、そのリズムに同期して第2のユーザ10Bの分身であるアバター24を動かす。さらに、管理サーバ15から入手した第2のユーザ10Bの動作情報を、第2のユーザ10Bの分身であるアバター24に反映させている。
次に、本実施例における頭部装着型映像表示装置であるHMDを、図面を用いて説明する。図3は、本実施例におけるHMDの内部構成の一例を示すハードウェア構成図である。図3において、HMD1は、主制御装置2、システムバス3、記憶装置4、センサ装置5、通信処理装置6、映像処理装置7、音声処理装置8、操作入力装置9で構成される。
主制御装置2は、所定の動作プログラムに従ってHMD1全体を制御するマイクロプロセッサユニットである。システムバス3は、主制御装置2とHMD1内の各構成ブロックとの間で各種コマンドやデータなどの送受信を行うためのデータ通信路である。
記憶装置4は、HMD1の動作を制御するためのプログラムなどを記憶するプログラム部41、動作設定値や後述するセンサ部からの検出値やコンテンツを含むオブジェクトなどの各種データを記憶する各種データ部42、各種プログラム動作で使用するワークエリアなどの書き替え可能なプログラム機能部43から構成している。また、記憶装置4は、ネットワーク上からダウンロードした動作プログラムや前記動作プログラムで作成した各種データ等を記憶可能である。また、ネットワーク上からダウンロードした動画や静止画や音声等のコンテンツを記憶可能である。また、カメラ機能を使用して撮影した動画や静止画等のデータを記憶可能である。また、記憶装置4は、HMD1に外部から電源が供給されていない状態であっても記憶している情報を保持する必要がある。したがって、例えば、フラッシュROMやSSD(Solid State Drive)などの半導体素子メモリ、HDD(Hard Disc Drive)などの磁気ディスクドライブ等のデバイスが用いられる。なお、記憶装置4に記憶された前記各動作プログラムは、ネットワーク上の各サーバ装置からのダウンロード処理により更新及び機能拡張することが可能である。
センサ装置5は、HMD1の状態を検出するための各種センサのセンサ群である。センサ装置5は、GPS(Global Positioning System)受信部51、地磁気センサ部52、距離センサ部53、加速度センサ部54、ジャイロセンサ部55で構成される。これらのセンサ群により、HMD1の位置、傾き、方角、動き等を検出することが可能となる。また、HMD1が、照度センサ、近接センサ等、他のセンサを更に備えていても良い。更に、手や腕に、それらのセンサと対をなす装置を装着すれば、手や腕の動きを検出することができる。これらのセンサ群を総合的に活用することにより、手を叩く、首や手を振る、手を上下する、立つ、座る、ステップ、ジャンプ、などの動作を検出することができる。
通信処理装置6は、LAN(Local Area Network)通信部61、電話網通信部62、で構成される。LAN通信部61は、アクセスポイント等を介してインターネット等のネットワークと接続され、前記ネットワーク上の各サーバ装置とデータの送受信を行う。アクセスポイント等との接続はWi-Fi(登録商標)等の無線接続で行われて良い。電話網通信部62は、移動体電話通信網の基地局等との無線通信により、電話通信(通話)及びデータの送受信を行う。基地局等との通信はW-CDMA(Wideband Code Division Multiple Access)(登録商標)方式やGSM(登録商標)(Global System for Mobile communications)方式、LTE(Long Term Evolution)方式、或いはその他の通信方式によって行われて良い。LAN通信部61と電話網通信部62は、それぞれ符号化回路や復号化回路やアンテナ等を備える。また、通信処理装置6が、BlueTooth(登録商標)通信部や赤外線通信部等、他の通信部を更に備えていても良い。
映像処理装置7は、撮像部71、表示部72で構成される。撮像部71は、CCD(Charge Coupled Device)やCMOS(Complementary Metal Oxide Semiconductor)センサ等の電子デバイスを用いてレンズから入力した光を電気信号に変換することにより、周囲や対象物の画像データを入力するカメラユニットである。表示部72は、例えば液晶パネル等の表示デバイスであり、画像データをHMD1のユーザに提供する。表示部72は図示を省略したビデオRAMを備える。そして、ビデオRAMに入力された画像データに基づいて表示画面上に表示される。
音声処理装置8は、音声入出力部81、音声認識部82、音声復号部83とで構成される。音声入出力部81の音声入力はマイクであり、ユーザの声などを音声データに変換して入力する。また、音声入出力部81の音声出力はスピーカであり、ユーザに必要な音声情報等を出力する。音声認識部82は、入力された音声情報を解析し、指示コマンド等を抽出する。音声復号部83は、必要に応じて、符号化音声信号の復号処理(音声合成処理)等を行う機能を有する。
操作入力装置9は、HMD1に対する操作指示の入力を行う指示入力部である。操作入力装置9は、ボタンスイッチ等を並べた操作キー、等で構成される。その他の操作デバイスを更に備えても良い。また、通信処理装置6を利用し、有線通信または無線通信により接続された別体の携帯端末機器を用いてHMD1の操作を行っても良い。また、音声処理装置8の音声認識部82を利用して、操作指示の音声コマンドによりHMD1の操作を行なっても良い。
なお、図3に示したHMD1の構成例は、本実施例に必須ではない構成も多数含んでいるが、これらが備えられていない構成であっても本実施例の効果を損なうことはない。また、デジタル放送受信機能や電子マネー決済機能等、図示していない構成が更に加えられていても良い。
図4は、本実施例におけるHMD1の機能ブロック構成図である。図4において、制御部30は、主に、図3における主制御装置2と記憶装置4のプログラム部41及びプログラム機能部43で実行される。
各種センサ情報取得部31は、センサ装置5の各種センサからの情報を取得する機能であり、自己の動作状態を把握する機能である。
通信処理部32は、主に、図3における通信処理装置6のLAN通信部61で実行され、HMD1の各種情報を、管理サーバ15へアップロードしたり、管理サーバ15からの各種情報をダウンロードしたりする機能である。また通信処理部32は、配信サーバ14からのライブコンテンツをダウンロードする機能である。
他者動作情報保存部33は、管理サーバ15が取得したHMD1を視聴するユーザとは異なる他のユーザの動作情報及び音声情報を、通信処理部32により入手し、記憶装置4の各種データ部42に保存する機能である。
アバター情報保存部34は、管理サーバ15が管理している他のユーザ固有のアバター情報を、通信処理部32により入手し、記憶装置4の各種データ部42に保存する機能である。
アバター生成処理部35は、主に、図3における主制御装置2で実行され、アバター情報保存部34により保存されたアバターに、他者動作情報保存部33により保存された他者の動作情報を加味して、アバターを生成する機能である。
アバター表示処理部36は、図3における映像処理装置7の表示部72により実行され、アバター生成処理部35で生成されたアバターを表示する機能である。但し、後ほど説明するが、HMD1の位置や方向により、HMD1の表示画面上からアバターが逸脱する場合があるので、アバターの表示可否を判断する必要がある。
リズム検出処理部37は、主に、図3における主制御装置2と音声処理装置8で実行され、ライブコンテンツにおける楽曲のリズム(拍子)を検出する機能である。管理サーバ15で管理しているコンテンツ情報(楽譜情報)があれば、通信処理部32により管理サーバ15から入手し、リズム(拍子)情報として利用する。番組表などにより、演奏される楽曲が判明している場合は、インターネット等により、その楽曲に関するリズムやテンポなどの楽譜情報を入手することもできる。
管理サーバ15、もしくはインターネット等から楽譜情報が入手できなかった場合は、配信サーバ14からのライブコンテンツを再生しながら、音の強弱の繰り返しパターンにより、リズム(拍子)を検出する。
次に、制御部30により実行される本実施例におけるHMD1での全体の処理フローチャートを図5に示す。図5において、HMD1における処理は、起動開始(S100)後、準備処理S200を行なう。準備処理S200は、ライブコンテンツを受信する前に、行なう処理であり、一緒にライブコンテンツを視聴するユーザの設定などを行なう。
準備処理S200が終了した後、ライブコンテンツの開始を待つ。そして、ライブコンテンツの受信動作(ライブコンテンツ処理S300)と同時に、アバター表示処理S400を行なう。
ライブコンテンツ処理S300では、送られてきたコンテンツを表示するとともに、リズム同期に関する情報をアバター表示処理S400に伝達し、リズムに同期したリズム動作情報を生成し、アバターにリズムに合わせた動作をさせる。
アバター表示処理S400では、他者の動作があった場合は、他者動作情報として、アバター表示処理S400に入力され、アバター表示に反映させる。
ライブコンテンツが終了すると、ライブコンテンツ処理S300と、アバター表示処理S400が終了し、全体の処理を終了する(S500)。
図6は、図5の全体の処理フローチャートにおける準備処理S200のフローチャートである。図6において、準備処理S200が開始(S210)されると、先ず、ライブコンテンツを検索し設定する(S211)。ライブコンテンツは、管理サーバ15が既に管理しているライブコンテンツ、もしくは、配信サーバ14が提供する番組表などから選択し、設定する。
次にステップS212で、設定したライブコンテンツの情報を、管理サーバ15や配信サーバ14もしくはネットワーク網13を介して他のサーバなどから入手し、記憶装置4の各種データ部42に保存する。なお、入手したライブコンテンツの情報は、単独で視聴する場合でも有効に活用できる。そして、ステップS213で、管理サーバ15から、管理サーバ15に登録されているユーザリスト(他者リスト)を入手する。
そして、ステップS214で、入手したユーザリスト(他者リスト)の中に、一緒に視聴したいユーザが存在するかどうかを判断する。S214で、一緒に視聴したいユーザが存在した場合は、一緒に視聴したいユーザ(他者)に対して、設定したライブコンテンツを開示して、一緒に視聴するかどうかの承認伺いを行なう(S215)。
そして、ステップS216で、一緒に視聴したいユーザ(他者)から承認が得られたかどうかを判断する。S216で、一緒に視聴したいユーザ(他者)から承認が得られなかった場合は、S214の処理に戻り、他の選択すべきユーザを検索する。
S216の処理で、一緒に視聴したいユーザ(他者)から承認が得られた場合は、管理サーバ15に、一緒に視聴するユーザとして、一緒に視聴したいユーザ(他者)を登録する(S217)。そして、ステップS218で、管理サーバ15から、一緒に視聴したいユーザの固有アバターデータ(友達アバター)を入手し、記憶装置4の各種データ部42に保存し、S214の処理に戻る。
S214で、入手したユーザリストの中に、一緒に視聴したいユーザが存在しなかった場合は、準備処理S200を終了する(S219)。
図7は、図5の全体の処理フローチャートにおけるライブコンテンツ処理S300のフローチャートである。図7において、ライブコンテンツ処理S300が開始(S310)されると、ライブコンテンツの開始を待ち、ライブコンテンツを受信する(S311)。続いて、受信したライブコンテンツを再生する(S312)。
そして、ステップS313で、ライブコンテンツを再生しながら、そのライブコンテンツのリズムを検出する。なお、管理サーバ15のコンテンツ情報に楽譜データがあれば、拍子とテンポ(拍の長さ)が分かるので、特にリズム検出処理は行なわない。
リズム検出は、通常、1個の強拍と1個以上の弱拍とからなるパターン(リズム区間)を、繰り返すことにより認識する。従って、リズムを認識するには、最低2個のリズム区間を必要とする。リズム検出の具体例としては、例えば、サウンドデータを適切なフレーム長ごとに分割し、フレーム内での音量を計算し、フレーム間の音量増加量を計算する。そして、音量増加量を周波数解析して、ピーク周波数をbpm(Beats Per Minute)に変換することで、リズムを検出する。
次に、ステップS314で、ライブコンテンツの楽曲がリズム区間の先頭に到達したかどうかを判断する。そして、ライブコンテンツの楽曲がリズム区間の先頭に到達するまでS314の処理を繰り返す。
次に、ステップS315で、ライブコンテンツの楽曲がリズム区間の先頭に到達したら、リズム区間先頭タイミングをアバター表示処理に通知する。
次に、ステップS316で、ライブコンテンツの楽曲がリズム区間の終端に到達したかどうかを判断する。そして、ライブコンテンツの楽曲がリズム区間の終端に到達するまで、S316の処理を繰り返す。
次に、ステップS317で、ライブコンテンツの楽曲がリズム区間の終端に到達したら、ライブコンテンツの楽曲が、終了したかどうかを判断する。S317で、ライブコンテンツの楽曲が終了していない場合は、リズム区間の終端は、次のリズム区間の先頭と同一タイミングなので、S315の処理に戻る。
S317の処理で、ライブコンテンツの楽曲が終了した場合は、ライブコンテンツの楽曲が終了したことを、アバター表示処理に通知し(S318)、ライブコンテンツ処理S300を終了する(S319)。
図8は、図5の全体の処理フローチャートにおけるアバター表示処理S400のフローチャートである。図8において、アバター表示処理S400が開始(S410)されると、先ず、管理サーバ15から、一緒にライブコンテンツを視聴する選択したユーザの固有アバターデータ(友達アバター)を入手し、所定の位置に表示する(S411)。
友達アバターは、選択したユーザの固有のアバターであり、身長や体形などの、その選択したユーザを彷彿させるイメージを有するアバターである。友達アバターは、ユーザ(もしくはユーザ以外の他人)が管理サーバ15に登録したユーザ固有のアバターである。勿論、選択したユーザの固有のアバターデータを使用せずに、一般的な特徴の無い汎用のアバターを使用することもできることは言うまでも無い。友達アバターは、選択したユーザのHMDの各種センサの情報から、例えば、座った状態や立った状態などの静止状態や、動きの動作情報を入手し、動作情報を生成して動作させる。
次に、ステップS412で、リズム区間の先頭タイミングかどうかを判断する。具体的には、ライブコンテンツ処理S300におけるS315の処理からのリズム区間先頭タイミングを待つ。リズム区間の先頭タイミングに到達するまで、S412の処理を繰り返す。
次に、ステップS413で、1個前のリズム区間(直前のリズム区間)経過中に、管理サーバ15から、一緒にライブコンテンツを視聴する選択したユーザの連続した動作情報及び音声情報が有ったかどうかを判断する。そして、連続した動作情報及び音声情報が無かった場合は、後ほど説明するS418の処理に移行する。また、連続動作情報が有った場合は、ステップS414でアバターの動作にリズム動作情報を加味する。また、音声情報が有った場合は、音声情報の出力を開始し、その音声情報がなくなるまで音声出力を継続する。
次に、ステップS415で、連続した動作情報の有無で動作アバターの表示の終了を判断する。動作アバターの表示が終了するまで、S414の処理を繰り返す。そして、S415の処理で動作アバターの表示が終了した場合は、友達アバターのリズム動作を停止する(S416)。
次に、リズム区間が終端に到達したかどうかを判断する(S417)。リズム区間が終端に到達していなければ、S415の処理に戻る。S417の処理で、リズム区間が終端に到達した場合は、楽曲が終了したかどうかを判断する(S418)。具体的には、ライブコンテンツ処理S300におけるS318の処理からの楽曲終了通知があるかどうかで判断する。
S418の処理で、楽曲が終了していない場合は、リズム区間の終端は次のリズム区間の先頭と同一タイミングなので、S413の処理に戻る。S418の処理で、楽曲が終了した場合は、アバターのリズム動作処理を終了する(S419)。
ここで、図8のアバター表示処理S411の詳細フローチャートを図9に示す。図9は、アバターが表示範囲に入っているか否かを判断してその表示を制御する処理である。
図9において、処理が開始(S420)されると、表示すべきアバターの位置を確認する(S421)。次に、HMD1の位置・方向が、前回と同じかどうかを判断する(S422)。
S422の処理で、HMD1の位置・方向が、変化したと判断した場合は、変化後のHMD1の位置や方向を検出する(S423)。初期では、前回のHMD1の位置や方向に関する情報が無いので、HMD1の位置や方向が、変化したと判断する。
次に、変化後のHMD1の位置や方向におけるHMD1の表示画面上に、S421の処理で確定したアバターの位置で、アバターが完全に逸脱しているかどうかを判断する(S424)。S424の処理で、アバターが完全に逸脱している場合は、アバターを表示しない(S425)。その後、このアバター表示可否ルーチンを終了する(S429)。
S424の処理で、アバターが完全に逸脱していない場合、アバターの一部が逸脱したかどうか判断する(S426)。S426で、アバターが少しも逸脱していない場合は、完全なアバターを表示する(S427)。その後、このアバター表示可否ルーチンを終了する(S429)。
S426の処理で、アバターが一部逸脱している場合は、HMD1の表示画面上に逸脱していない残りのアバターを表示する(S428)。その後、このアバター表示可否ルーチンを終了する(S429)。
このような手順で、アバターの表示可否を判断して実行する。アバターの表示可否は、アバターを表示する度に、実行されることが望ましい。
以上のように、本実施例は、視聴する音楽のリズムを検出し、表示される他のユーザの分身であるアバターの動作を、その検出したリズムと同期した動作で表示させる。これにより、他のユーザの分身であるアバターの動作がリズムと同期した動作となるので、音楽ライブ等で、臨場感溢れる視聴効果をもたらすことができる。
なお、本実施例は、楽曲のリズムについて説明したが、これに限定されるものでなく、スポーツ観戦、舞台観戦などに対する反応である、応援、歓声、掛け声等の動作や、映像と一緒に行なう合奏や合唱などの動作を含む、連続する動作でよい。その場合、リズム検出処理部37は、動き情報検出処理部と置き換えればよい。これにより、本実施例によれば、連続する動作に同期した動作でアバターを表示させることで、空間を共有する際のアバターを介した違和感を低減することが可能となる。