JP2004304651A - 情報処理装置、携帯情報端末、情報処理方法、プログラム及び記録媒体 - Google Patents

Abstract

【課題】カメラサーバによって取得された画像データに、その画像データに付帯するカメラサーバの制御情報を反映させ、携帯情報端末に対して適切に提供することを可能とする。
【解決手段】映像変換サーバ４００は、カメラサーバ１０１、１０２より画像データを取得し、取得した画像データにその画像データに付帯するカメラサーバ１０１、１０２の制御情報を反映させ、携帯情報端末６０１、６０２に対して送信する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、通信によって映像データを配信する映像配信技術に関し、特に、多数のカメラ装置などのライブ映像ソースの制御情報を反映して、携帯電話端末など携帯情報端末向けに映像データ（映像クリップ）を提供する場合の映像変換技術に関するものである。
【０００２】
【従来の技術】
本発明に関係する従来の技術は、以下の通りである。
［ライブ映像通信システム］
撮影したライブ映像を、インターネットなどの通信インフラストラクチャを使って配信するとともに、撮影のためのカメラ設定やカメラ操作などを指示する技術が確立され、製品が販売されている。例えば、本願出願人が提案する映像配信システムＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅ、および、同じく本願出願人が提案するライブネットワークカメラサーバＶＢ１０１やネットワークカメラＶＢ−Ｃ１０などである。
【０００３】
また、ネットワークカメラについては特開２００２−０８４４４５号公報にも開示されており、本従来例においては、ネットワークカメラの端末として、携帯電話が使用されている。
【０００４】
本願出願人が提案する映像配信システムなどでは、映像配信に加えて、パン、チルト、ズーム、逆光補正といったカメラ制御をネットワークを介して提供可能となっている。また、アクセス制御機能を備え、利用者のアクセス権限に応じて、カメラ制御や映像配信の制限を行うことができる。
【０００５】
さらに、カメラ制御によって撮像される領域に関しても制限することが可能になっている。例えば、特権ユーザでは、カメラに備わるズーム機能の全てを利用できるが、通常ユーザは、ズーム機能の一部（たとえば、テレ端を使い切れない）のみ利用可能とするような制限である。パン機能やチルト機能についても同様である。
【０００６】
［第三世代携帯電話技術］
従来の携帯電話サービスよりも高い電波利用効率と通信帯域を備えた携帯電話サービスとして、第三世代（３Ｇ）の携帯電話サービスが提供されるようになっている。例えば、ＮＴＴドコモ社の第三世代（３Ｇ）携帯電話サービスＦＯＭＡやＫＤＤＩ社のｃｄｍａ２０００ １ｘがある。
【０００７】
第三世代（３Ｇ）の携帯電話では、電話通話しながらインターネットアクセスなどのデータ通信が可能となっている。例えば、ＮＴＴドコモ社によるＦＯＭＡサービスでは、マルチアクセスと呼ばれる接続形態を用意しており、これを利用することで、ウェブブラウジングなどのデータ通信を行いながら、電話通話を可能にしている。
【０００８】
さらに、第三世代携帯電話端末では、端末自体の処理能力も強化されており、これまでＰＣ（パーソナルコンピュータ）などで行っていた作業を携帯電話端末で処理可能になっている。例えば、メイルやウェブブラウジングおよび映像送受信などの機能を実装している携帯電話端末が提供されている。
【０００９】
また、第三世代携帯電話サービスでは、映像配信のサービスも行われており、ドコモ社のｉモーションやＭ−ｓｔａｇｅ Ｖｉｓｕａｌあるいは、ＫＤＤＩ社のｅｚｍｏｖｉｅなどのサービスが行われている。
【００１０】
［ＭＰＥＧ−４コーデック］
移動体通信網に接続する携帯情報端末から広帯域インターネットに接続するＰＣまでの映像送受信端末の広がりを受けて、数十ｋｐｂｓから数十Ｍｂｐｓの広いビットレートをカバーする高圧縮符号化効率、および、無線やインターネットなどの伝送路誤りに対する強い耐性などを備えた動画像圧縮符号化方式として、ＩＳＯで１９９９年にＭＰＥＧ−４が制定されている。
【００１１】
また、ＭＰＥＧ−４を用いた映像配信サービスが、個人情報端末（ＰＤＡ）や携帯電話端末向けに提供されている。例えば、ＮＴＴドコモ社やＫＤＤＩ社の第三世代（３Ｇ）携帯電話サービスでは、携帯電話端末（ビジュアル端末）間でＭＰＥＧ−４を用いて相互に映像を送受信するサービスを提供している。
【００１２】
［携帯電話向けＭＰＥＧ−４クリップ技術］
携帯電話端末に映像クリップ（ファイル）を表示する技術が提供されている。例えば、ＮＴＴドコモ社のｉモーションやＭ−ｓｔａｇｅ ｖｉｓｕａｌ、あるいは、ＫＤＤＩ社の ｅｚｍｏｖｉｅなどがある。
【００１３】
これらのサービスでは、ＭＰＥＧ−４コーデックなどで圧縮符号化された映像データ（映像クリップあるいは映像ファイル）をサーバに保存し、携帯電話端末に内蔵するデータ通信機能を使ってサーバからダウンロードした上で、同じく携帯電話端末に内蔵するデコーダを使って映像を携帯電話端末の画面に表示する。
【００１４】
また、これらの映像クリップのデータフォーマットは、マイクロソフト社のＡＳＦ （Ａｄｖａｎｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｆｏｒｍａｔ）形式や、ＩＳＯ標準のＭＰ４形式（ＩＳＯ／ＩＥＣ１４４９６−１ Ａｍｄ１ ＭＰＥＧ−４システム Ｖｅｒｓｉｏｎ２）など、インターネットやＰＣなどで広く普及している形式に準拠している。
【００１５】
さらに、これらのサービスでは、いずれも映像クリップの上限が決められており、例えば、ＫＤＤＩ社のｅｚｍｏｖｉｅの場合、２４０ｋｂｙｔｅｓが上限となっている。
【００１６】
［映像クリップへのリンクやコマンドの関連付け技術］
マイクロソフト社のＡＳＦ （Ａｄｖａｎｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｆｏｒｍａｔ）形式やＡｐｐｌｅ社のＱｕｉｃｋＴｉｍｅ Ｆｉｌｅ Ｆｏｒｍａｔなどでは、映像クリップにＵＲＬなどのハイパーリンク機能を関連付けることができる。例えば、ＡＳＦでは、”Ｓｃｒｉｐｔ Ｃｏｍｍａｎｄ Ｏｂｊｅｃｔ”を定義することが可能であり、このオブジェクト内に、ＡＳＦファイル再生時のタイムラインに同期するように設定したリンク情報をリストできる。さらに、ＡＳＦでは、Ｓｃｒｉｐｔ Ｃｏｍｍａｎｄ Ｏｂｊｅｃｔの名前のとおり、リンク情報ばかりでなく、スクリプトなどのコマンド情報も記述可能となっている。
【００１７】
また、ＫＤＤＩ社のｅｚｍｏｖｉｅ仕様にも、映像クリップにハイパーリンク機能付きのテキストテロップ（字幕）を追加する機能が備わっている。このテロップ記述言語には、ＫＤＤＩ社のＳＴＭＬ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｔｅｌｏｐ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅの略）を利用する。この機能により、ユーザは、音声通話やメール送信やホームページリンクなどを、映像クリップと関連付けることができる。
【００１８】
【特許文献１】
特開２００２−０８４４４５号公報
【００１９】
【発明が解決しようとする課題】
しかしながら、インターネット上でサービスされている膨大な数のカメラ制御可能なカメラサーバの映像情報を携帯電話端末へサービスする場合、映像情報に付帯するカメラ制御情報（パン、チルト、ズーム、あるいは、制御権などの情報）が適切に利用できないという問題があった。あるいは、利用できた場合でも、ＰＣ上などで実行される専用ビューワの利用に比べて、携帯電話向けの映像サービスでは、カメラ制御情報の利用が制限される問題があった。
【００２０】
本発明は、上記問題点に鑑みてなされたものであり、例えばカメラサーバ等の撮像装置によって取得された画像データに、その画像データに付帯する例えば撮像装置の制御情報等の前記撮像装置の状態情報を反映させ、携帯情報端末に対して適切に提供することを可能とする。
【００２１】
【課題を解決するための手段】
斯かる目的を達成するために、本発明の情報処理装置は、一又は複数の撮像装置より画像データを取得する画像取得手段と、前記画像取得手段にて取得された前記画像データに、前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段と、前記処理手段により生成された前記画像データを一又は複数の携帯情報端末に対して送信する画像送信手段とを有することを特徴とする。
【００２２】
また、本発明の携帯情報端末は、一又は複数の撮像装置より画像データを取得する画像取得手段と、前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段とを含む情報処理装置から、前記処理手段にて生成された前記画像データを受信する画像受信手段を有することを特徴とする。
【００２３】
また、本発明の情報処理方法は、一又は複数の撮像装置より画像データを画像取得手段にて取得し、前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させた画像データを処理手段にて生成し、前記処理手段により生成された前記画像データを一又は複数の携帯情報端末に対して送信することを特徴とする。
【００２４】
また、本発明の情報処理方法は、一又は複数の撮像装置より画像データを取得する画像取得手段と、前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段とを含む情報処理装置から、前記処理手段にて生成された前記画像データを受信することを特徴とする。
【００２５】
また、本発明のプログラムは、前記情報処理方法をコンピュータに実行させることを特徴とする。さらに、本発明のコンピュータ読み取り可能な記録媒体は、前記プログラムを記録したことを特徴とする。
【００２６】
【発明の実施の形態】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
＜第１の実施形態＞
第１の実施形態では、ネットワーク上に配置された多数のカメラサーバから取得したライブ映像を、携帯電話端末向けに変換して送信する例について説明する。
この中で、映像の変換を行い映像クリップを生成する映像変換サーバが、映像に付帯するカメラ制御状態情報（パン、チルト、ズーム、あるいは、制御権などの情報）を反映して、適切な映像クリップを生成する例についても説明する。特に、本実施形態の映像変換サーバでは、映像クリップが作成された時点のカメラ制御状態情報を使って、映像クリップ再生時点のカメラサーバに選択的にアクセスできるよう映像クリップを作成する点に特徴がある。
【００２７】
さらに、映像変換サーバは、携帯電話端末に備わる標準的な映像ビューワ（以下、カメラ制御機能などを備えない意味で「非専用ビューワ」と称する）を用いて再生表示可能な映像クリップを生成した上で、その映像クリップ中に適切なリンク情報を組み込むことで、リンク情報を参照した場合に、カメラ制御機能などを備える専用ビューワ（以下、専用ビューワと称する）に、適切なカメラ制御情報を引き渡すことを可能とする。
【００２８】
図１は、本発明の第１の実施形態に係るライブ映像通信システムの構成を概略的に示した図であり、１０１および１０２はライブ映像通信システムによるカメラサーバ、２００はネットワークに接続されたＰＣなどにインストールされたビューワである。カメラサーバとビューワとはそれぞれネットワークに接続され、ビューワからネットワークを介してリクエストがカメラサーバへ送られ、これが受け入れられるとカメラサーバ１０１、１０２からビューワ２００へ映像データが配送され、ビューワ２００でカメラ映像を表示することが可能となる。またビューワ２００からカメラ制御コマンドがカメラサーバ１０１、１０２へ送られ、カメラのズーム、パン、チルトなどの操作が可能となる。さらに、ネットワーク上には、中継サーバ３００が置かれビューワ２００とカメラサーバ１０１、１０２との通信を中継することがある。
【００２９】
さらに、４００は映像変換サーバであり、カメラサーバ１０１、１０２が提供する映像データを携帯電話端末向けに変換した上で、携帯電話６０１、６０２向けに中継する。また、５００はネットワークと携帯電話回線網とを仲介するゲートウェイであり、６０１および６０２は、ビューワを搭載した携帯電話端末である。このゲートウェイ５００を介して、ネットワークに接続された機器と携帯電話端末６０１および６０２とが通信可能となる。なお、携帯電話端末６０１、６０２上のビューワプログラムは、典型的には、工場出荷時にインストールされるが、Ｊａｖａ（Ｒ）プログラムのように実行時（利用時）にダウンロードされて実行される形態であっても良い。
【００３０】
図１のネットワークは企業あるいは組織内で運用されるイントラネットである場合もあり、広く世界をつないでいるインターネットである場合もある。また、中継サーバ３００や映像変換サーバ４００は、典型的には、インターネットイクスチェンジ（ＩＸ）やデータセンター（ＩＤＣ ： Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）に配置され、通信負荷の軽減を図るよう設計される。
【００３１】
図２は、映像変換サーバ４００を動作させるハードウェア構成の一例を示したものであり、サーバ向けコンピュータ、より詳細には、プログラムやデータを格納する記憶装置４０１、ネットワークと接続するためのネットワークＩ／Ｆ４０２、プログラムによる各種の処理を実行するＣＰＵ４０３、などからなる。記憶装置４０１は、主記憶装置となるＲＡＭ、フラッシュメモリやＨＤ装置などからなる二次記憶装置、および、プログラムを媒体からロードするためのＦＤ装置などから構成される。また、図示しないが、設定などを行うための入出力装置を備える場合もある。具体的には、ディスプレイを接続する表示装置、キーボードやマウスなどのコントローラなどである。
【００３２】
図３はカメラサーバ１０１、１０２のハードウェア構成の一例を示したものであり、実際に撮像を行うカメラ装置とコンピュータ、より詳細には、プログラムやデータを格納する記憶装置１０１１、映像データを取り込むための映像キャプチャボード１０１２、カメラ装置にコマンドを送るためのシリアルＩ／Ｆ１０１３、ネットワークと接続するためのネットワークＩ／Ｆ１０１４、プログラムによる各種の処理を実行するＣＰＵ１０１５、などからなる。記憶装置１０１１は、主記憶装置となるＲＡＭ、フラッシュメモリやＨＤ装置などからなる二次記憶装置、および、プログラムを媒体からロードするためのＦＤ装置などから構成される。
【００３３】
また、図示しないが、設定などを行うための入出力装置を備える場合もある。具体的には、ディスプレイを接続する表示装置、キーボードやマウスなどのコントローラなどである。さらに、図示しないが、カメラサーバは、カメラ装置とコンピュータとが一体化されたサーバ内蔵型ネットワークカメラで構成されても良い。
【００３４】
図４はビューワを動作させるハードウェア構成の一例を示したものであり、携帯電話端末を使ってビューワを動作させる場合について説明している。より詳細には、プログラムやデータを格納する記憶装置６０１１、携帯電話網と接続するための無線通信Ｉ／Ｆ６０１２、プログラムによる各種の処理を実行するＣＰＵ６０１３、および、周辺装置などからなる。記憶装置６０１１は、主記憶装置となるＲＡＭ、フラッシュメモリなどからなる。周辺装置は、携帯電話端末上に配置されたボタンやスイッチ類などの入力装置、ディスプレイなどの表示出力装置、および、マイクロフォンやスピーカなどの音声入出力装置を含む。
【００３５】
図５はプログラムを構成する部分を模式化した図であり、カメラサーバ１０１内にはカメラの制御を司るカメラ制御サーバ１０１ａと映像の配送を司る映像サーバ１０１ｂの２つのモジュールを含む。同様に、携帯電話端末上で動作するビューワ内にはカメラ制御コマンドの発行やカメラ状態通知に対応するカメラ制御部６０１ａ、映像クリップの表示を担当する映像表示部６０１ｂを含む。
【００３６】
さらに、映像変換サーバ４００には、カメラ制御コマンド列（以下、ＰＴＺシーケンスと称す）を解釈し、カメラサーバ１０１にカメラ制御命令を発行するカメラ制御部４００ａ、ならびに、カメラサーバ１０１から映像を取得し、携帯電話向けに変換し、さらに、それを携帯電話網向け映像クリップに編集するモジュール（映像取得部４００ｂ、映像変換部４００ｃ、映像送信部４００ｄ）、がそれぞれ含まれる。
【００３７】
図６は、携帯電話上で映像クリップを再生表示する非専用ビューワの動作の流れを示す図である。
ステップＳ６０１で、まず、映像変換サーバ４００の識別子を入手する。これは、ユーザが直接キー操作により識別子を入力するのでも良いし、メイルやウェブページに含まれる識別子を選択するのであっても良い。また、この場合の識別子は、典型的には映像変換サーバ４００を識別するＵＲＬである。
【００３８】
続いて、ステップＳ６０２で、映像変換サーバ４００が接続すべきカメラサーバ１０１、１０２の識別子、そのカメラサーバ１０１、１０２に指示するカメラ制御用のＰＴＺシーケンス、および、ユーザ識別子やパスワードなどアクセス制御用のユーザ識別情報を入手する。カメラサーバ識別子やＰＴＺシーケンスは、ユーザが直接キー操作によりカメラ制御コマンドを構成するよう入力する方法でも良いし、メイルやウェブページに含まれるカメラサーバ識別子やＰＴＺシーケンスから選択する方法であっても良い。また、ＰＴＺシーケンスは、空であっても構わない。この場合、カメラ制御を伴わないカメラサーバ１０１、１０２の現状の映像クリップを意味する。また、ユーザ識別情報は、通常、ユーザが直接キー操作により入力するが、空であっても構わない。この場合、通常ユーザとしてのカメラサーバ１０１、１０２への接続を意味する。
【００３９】
続いてステップＳ６０３で、ゲートウェイ５００を経由して、入手した映像変換サーバ４００の識別子に基づき映像変換サーバ４００の映像送信部に接続する。さらにステップＳ６０４で、携帯電話ビューワは、映像変換サーバ４００に映像クリップを要求する。この要求は、要求する映像クリップの作成方法の指定などを含み、例えば、ＨＴＴＰプロトコルに則り送信される。この際、ＰＴＺシーケンスを入手している場合には、そのＰＴＺシーケンスを映像変換サーバ４００に送信する。この要求およびＰＴＺシーケンスの送信は、ＨＴＴＰ接続のＧＥＴメソッドでＵＲＬに組み込んでも良いし、ＨＴＴＰ接続のＰＯＳＴメソッドで送信されても良い。
【００４０】
ここでは、ＰＯＳＴメソッドで送信される場合について説明する。例えば、以下の通りである。なお、実際には、ＵＲＬエンコードが適用されるが、以下では、説明の都合上ＵＲＬエンコードを適用していない部分もある。

【００４１】
ただし、「ｖｉｄｅｏｅｎｃｏｄｅｐａｒａｍ＝」に続く部分は、映像変換サーバ４００がカメラサーバ１０１、１０２から受取ったソース映像を携帯電話向けにエンコードする際のパラメータ情報を指示するものである。また、「ｃａｍｅｒａｓｅｒｖｅｒｓ＝」に続く部分は、映像変換サーバ４００が接続するカメラサーバ１０１、１０２を指定している。また、「ＰＴＺ＝」に続く部分は、映像変換サーバ４００がカメラサーバ１０１、１０２に関して実行すべきカメラ制御のコマンドを並べたＰＴＺシーケンスを指定している。また、「ｍｏｖｉｅｓｉｚｅｍａｘ＝」に続く部分は、携帯電話端末あるいは携帯電話網が規定する映像クリップの最大サイズを指定している。また、「ｎｏｔｉｆｙｔｏ＝」に続く部分は、映像クリップ作成時に通知すべき連絡先である、例えば、携帯電話端末ユーザのメイルアドレスを指定する。また、「ｕｓｅｒｉｄ＝」と「ｕｓｅｒｐｗ＝」とに続く部分は、それぞれ、ユーザ識別子とパスワードとである。
【００４２】
この中で、ＰＴＺシーケンスの構成要素は、以下のような意味を持つ。ｎは、数値データ（正負あり）である。
Ｐｎ パン（水平方向カメラ制御）指定
Ｔｎ チルト（垂直方向カメラ制御）指定
Ｚｎ ズーム指定
Ｂｎ 逆光補正。逆光補正のＯＮ／ＯＦＦ
Ｈ ホームポジション指定
Ｓｎ プリセット位置指定。ｎ番目のプリセット位置
Ｃｎ カメラサーバ接続切換え指定。ｎ番目のカメラサーバ
Ｋｎ カメラサーバ内カメラ切換え指定。ｎ番目のカメラ
＿ｎ 時間経過指定。０．１秒単位
【００４３】
続いて、ステップＳ６０５で、映像変換サーバ４００からのレスポンスを待つ。続いて、ステップＳ６０６で、映像変換サーバ４００から受取ったレスポンスを解釈して携帯電話端末の表示装置に表示する。例えば、図１５（ａ）の通りである。もしも、映像変換サーバ４００からのレスポンスが、何らかの理由からすぐに映像を生成できないことを示す内容であった場合には、ステップＳ６０７に進む。反対に、映像をすぐに生成できたことを示す内容であった場合には、ステップＳ６０８に進む。
【００４４】
ステップＳ６０７では、映像変換サーバ４００からのメイル通知を待受ける。メイル通知は、例えば、ＳＭＴＰ （Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によるが、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）であってもよい。メイル通知を受取った場合には、そのメイル内容を映像変換サーバ４００からのレスポンスとして表示し、ステップＳ６０８に進む。例えば、図１５（ｂ）の通りである。
【００４５】
ステップＳ６０８では、レスポンスに含まれる映像クリップの一つを選択し、ダウンロードして再生表示する。例えば、図１５（ｃ）の通りである。ここでは、ダウンロード完了を待っているが、映像クリップの再生表示処理は、ダウンロード完了を待たず、表示再生可能な映像クリップデータが揃った時点で、再生表示処理を開始しても良い。
【００４６】
なお、携帯電話ビューワでの映像クリップ表示中に、携帯電話端末ユーザがクリックした場合には、クリック時点に表示中の映像データ（映像区間、または、映像セグメントと呼ぶ事がある）に対応するリンク情報が映像クリップから抽出され、携帯電話端末に備わるブラウザ機能を使って、そのリンク情報が示すリンク先情報にアクセスする。リンク先情報へのアクセスでは、カメラ制御を可能とする専用ビューワを起動するが、携帯電話端末の設定によっては、設定されたアクションを行う場合もある。例えば、アクセスされたリンク情報をメイル添付したメイルの発信である。
【００４７】
図１９は、専用ビューワの動作の流れを示した図である。
ステップＳ６５１で起動時に指示されたカメラサーバ１０１を構成する映像サーバ１０１ｂのアドレスおよび接続ポートの情報に従い、映像サーバ１０１ｂへ接続する。この時、複数のカメラサーバ１０１、１０２が指示されている場合には、ダイアログをポップアップ表示して、いずれのカメラサーバに接続すべきかユーザに問合せる。
【００４８】
ここで、接続以降の処理を行うための動作プログラム（実現方法としては、スレッドあるいはプロセスの起動となる）が起動され、このプログラムは終了までステップＳ６６１を繰り返す。ステップＳ６６１では、映像サーバ１０１ｂからの映像データが届くたびにそれを受け取り表示する。
【００４９】
さらにメインのプログラムはステップＳ６５２で、同じく起動時に指示されたカメラ制御サーバ１０１ａのアドレスおよび接続ポートの情報に従い、カメラ制御サーバ１０１ａへ接続する。そして、これ以降メインプログラムはユーザからの操作要求を受け付け、実行するメインループへ続く。
【００５０】
まず、ステップＳ６５３でユーザの操作をキーボタン操作などから受け取る。これがカメラ制御に関する場合にはステップＳ６５４でカメラ制御サーバ１０１ａへコマンドを発行する。また、映像サーバ１０１ｂに関する場合にはステップＳ６５５で映像サーバ１０１ｂへコマンドを発する。
【００５１】
また、ユーザの操作がビューワの状態を変更する操作（例えば、表示サイズの変更操作など）の場合にはステップＳ６５６で内部状態を更新する。そして、ユーザの操作が終了の場合には、ステップＳ６５７でビューワの動作に関連する各プログラムを順次終了する。Ｓ６５４〜Ｓ６５７の処理が完了するとＳ６５３へ戻り、ユーザの操作入力を待つ。
【００５２】
携帯電話端末上で動作する専用ビューワは、携帯電話端末の出荷時に備わるソフトウェアとして実装される場合もあるが、Ｊａｖａ（Ｒ）プログラムのようにネットワークからダウンロードして実装されるソフトウェアである場合もある。
【００５３】
図７は、カメラサーバ１０１内のカメラ制御サーバ１０１ａの動作の流れを示した図である。カメラ制御サーバ１０１ａはまず起動時にステップＳ７０１で特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）からカメラ制御サーバ１０１ａの動作設定情報を読み出して、それに基づき動作を開始する。ここでクライアントであるビューワプログラムや映像変換サーバ４００からのリクエストを受け付けるポートを開き、続いて、ステップＳ７０２のリクエスト受付状態に入る。リクエスト（接続リクエストもしくは操作コマンドリクエスト）が受け付けられたら、Ｓ７０２を抜け、接続リクエストならばステップＳ７０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、Ｓ７０２に戻る。可ならば、ステップＳ７０４で接続処理として、クライアントからのコマンドの受付処理を行うスレッドを生成し、クライアントの登録を行ってから、Ｓ７０２に戻る。
【００５４】
生成されたスレッドでは、ステップＳ７０７で対応するクライアントからのコマンドの受付を行う。コマンドが届いたならば、それを受け付け、カメラ操作を行う主プログラムへ受け渡す。主プログラムはステップＳ７０２でこれを受け、操作コマンドに対してはステップＳ７０５へ進み、操作コマンドを発行したスレッドが接続しているクライアントの権限に応じてカメラ操作を行って、その結果（操作が成功か失敗かを示すコードなど）をカメラ操作要求を受け付けたクライアント対応のスレッドへ伝える。このクライアント対応のスレッドはステップＳ７０８で結果をクライアントへ送り返す。主プログラム部分では、ステップＳ７０６でカメラの操作により変化した状態（たとえば、パン・チルト・ズームの値、および、禁止エリア検出の有無などを含むカメラ状態情報など）を全てのクライアント対応のスレッドに伝える。
【００５５】
各クライアント対応のスレッドは、ステップＳ７０９でカメラ制御状態の変化をクライアントへ通達する。クライアント対応のスレッドはクライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ７１０で自身のスレッドを終了する。尚、操作コマンドの扱いにおいては、具体的な操作コマンドの発行の前に、カメラ操作権の割り当て要求を必要とすることも可能である。これは複数の人間がカメラの操作を要求するような状況での混乱を無くす。この場合、まず、クライアントからはカメラ操作権獲得の要求コマンドが発行され、これに対して、カメラ制御サーバ１０１ａは現在のカメラ制御権の割り当て状態から、拒絶・割り当て・順番待ちを選びクライアントへ返答する。
【００５６】
カメラ制御権は前もって定められた特定の時間か、クライアントが接続を終了するまでの短いほうの時間で剥奪され、次の順番待ちの人に割り当てられる。順番待ち人数はやはり前もって定められた人数（たとえば５人）に制限され、それ以上のリクエストは拒絶される。クライアントはカメラ制御権が獲得されてから剥奪されるまでの間だけ、操作コマンドを発行する。カメラ制御サーバ１０１ａはカメラ制御権が付与されているクライアントからの操作コマンドのみを受け付ける。
【００５７】
また、特権ユーザからの接続に関しては、優先的にカメラ操作権を割り当てられる点、および、操作コマンドが禁止エリアを含む撮像領域へのカメラ制御であっても許可される点などが、通常ユーザからの接続とは異なる。
【００５８】
図８はカメラサーバ内の映像サーバの動作の流れを示した図である。
映像サーバ１０１ｂは、まず起動時にステップＳ８０１で特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から映像サーバ１０１ｂの動作設定情報を読み出して、それに基づき動作を開始する。ここで、映像の獲得と符号化と蓄積を行うスレッドを生成し（最初このスレッドは休止状態）、クライアントであるビューワプログラムや映像変換サーバからのリクエストを受け付けるポートを開き、続いて、ステップＳ８０２のリクエスト受付状態に入る。
【００５９】
リクエスト（接続リクエストもしくはコマンドリクエスト）が受け付けられたら、Ｓ８０２を抜け、接続リクエストならばステップＳ８０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、Ｓ８０２に戻る。可ならば、ステップＳ８０４で接続処理として、クライアントごとのセッションを識別するためのセッション識別子を生成し、クライアントからのコマンドの受付処理を行うスレッドを生成し、接続リクエストを発行したクライアントのアクセス権情報などに則してクライアントの登録を行い、Ｓ８０２に戻る。なお、この際、リクエスト内容がライブ映像への接続であり、かつ、映像の獲得と符号化を行うスレッドが休止状態ならば、Ｓ８０２に戻る前に、動作開始を指示する。
【００６０】
生成されたクライアント対応のスレッドでは、ステップＳ８０７で対応するクライアントからのコマンドの受付を行う。コマンドが届いたならば、それを受け付け、映像処理を行う主プログラムへ受け渡す。主プログラムはステップＳ８０２でこれを受け、操作コマンドに対してはステップＳ８０５へ進み、映像の獲得や符号化・送信などに関する設定の変更操作を行って、その結果（操作の成功か失敗を示すコード）をコマンド要求を受け付けたクライアント対応のスレッドへ伝える。
【００６１】
クライアント対応のスレッドはステップＳ８０８で、この結果をクライアントへ送り返す。主プログラム部分では、ステップＳ８０４からの映像の獲得と符号化を行うスレッドへの動作開始の指示により、ステップＳ８０６では前もって設定された時間間隔で映像データを映像キャプチャボードを使って獲得し、これを圧縮データに変換する。さらにこの圧縮データを、ライブ映像に接続している全てのクライアント対応のスレッドに伝える。
【００６２】
各クライアント対応のスレッドはステップＳ８０９で、クライアントからの次映像フレーム送信要求の有無を判定し、要求があるならば、圧縮データをクライアントへ配送する。この際、禁止エリアが検出されている場合には、登録されているクライアント情報に照らして、特権ユーザの接続以外には、禁止エリアに該当しているため圧縮データを配信しない旨（禁止エリア検出通知）を通知する。
【００６３】
そして、ライブ映像に接続しているクライアント対応のスレッドが、クライアントからの次映像フレーム送信要求（これはクライアントでの圧縮映像データの受け取り完了に対して、送り返されるのが一般的である）を受け取った場合には映像フレーム送信要求のフラグを設定する。また、クライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ８１０で自身のスレッドを終了する。
【００６４】
図９は、ＰＴＺシーケンスを作成する時の携帯電話の様子を例示した図である。 ＰＴＺシーケンスを作成する際には、携帯電話端末のキーに図示のように、パン（カメラの横振り）、チルト（カメラの縦振り）、ズーム（拡大倍率変更）、逆光補正などの機能が割り当てられる。なお、この画面は図６を用いて説明したＰＴＺシーケンス入手操作を行うためのＵＩ（ユーザインタフェース）であり、ここで作成されたＰＴＺシーケンスは、Ｓ６０２へ送られる。
【００６５】
次に、ＰＴＺシーケンスの作成の流れを図１６に示す。
まず、ステップＳ９０１で、事前に取得したカメラサーバの識別子を使って、カメラサーバのカメラ制御によって可視範囲に入る画像を合成したパノラマ画像、事前にカメラサーバに設定されているカメラ制御情報（プリセット情報）、および、現在のカメラ状態パラメータ（パン角、チルト角、ズーム値など）を、カメラサーバから取得する。
【００６６】
次に、ステップＳ９０２で、ＰＴＺシーケンスの初期値として空データを設定し、また、表示用カメラ状態パラメータおよび設定用カメラ状態パラメータとして取得した現在のカメラ状態パラメータを設定する。次に、ステップＳ９０３で、表示用カメラ状態パラメータに従って、可視領域を計算し、可視領域に相当する画像をパノラマ画像から切り出して携帯電話端末の画面に表示する。
【００６７】
次に、ステップＳ９０４で、ユーザからのキー入力を受取る。キー入力が、カーソルキーによる可視領域の変更、あるいは、プリセット位置への移動の指示であった場合には、ステップＳ９０５で、表示用カメラ状態パラメータを変更し、ステップＳ９０３に進む。キー入力が、ＰＴＺシーケンスを追加／修正などの編集指示であった場合には、ステップＳ９０６で、ＰＴＺシーケンスの値を変更し、ステップＳ９０３に進む。ＰＴＺシーケンス追加の場合には、その時点の表示用カメラ状態パラメータと設定用カメラ状態パラメータとの差分から制御すべきカメラ制御値を計算し、そのカメラ制御値をＰＴＺシーケンスに追加する。そして、表示用カメラ状態パラメータを設定用カメラ状態パラメータの新しい値とする。
【００６８】
キー入力が、ＰＴＺシーケンス作成の終了を指示する場合には、ステップＳ９０７に進んだ上で、決定やキャンセルを判定し、決定である場合には、ＰＴＺシーケンスをＳ６０２へ送り、処理を終了する。
【００６９】
図１０は、カメラサーバの用いる設定値、すなわちカメラ制御サーバや映像サーバが読み出す動作設定情報を特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）に設定するカメラサーバ設定プログラムの表示画面の一例を示した図であり、カメラ制御サーバ、映像サーバ、動画品質、接続制限事項などに関する各種のパラメータ（後述）を設定できるようになっている。ＯＫボタンを押すと設定した値が特定のファイルあるいはレジストリに書き込まれ、キャンセルすると書き込まれずに終了する。
【００７０】
図１１は、図１０のカメラサーバの設定プログラムの動作を示す流れ図である。
設定プログラムは起動時にまずステップＳ１１０１でカメラ制御サーバおよび映像サーバに関する設定情報を格納した特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から設定情報を読み出し、内部データに設定する。以降、ユーザの操作入力を受け取り、実施するループを繰り返す。
【００７１】
ステップＳ１１０２でユーザの操作入力を待ち、入力があればそれを受け取り、続いてステップＳ１１０３で入力された値が適正範囲内であるか否かを判定し、適正でなければステップＳ１１０４でエラーメッセージを出力して、値を戻して、ユーザの入力待ちＳ１１０２へ戻る。適正範囲内であるならば、内部データを更新して、Ｓ１１０２に戻る。ここで設定できる値には次の項目がある。カメラ制御の通信用のＴＣＰポート番号、カメラと接続するＣＯＭ（シリアル）ポート、シャッタースピード、カメラ制御関連のログ情報の有無とログファイル名、映像関連の通信用のＴＣＰポート番号、ログ情報の有無とログファイル名、映像をキャプチャする時間間隔を規定するフレームレートと圧縮の品質を決めるＱ−Ｆａｃｔｏｒ、圧縮の元データの画面サイズ、１つのクライアントビューワの最大接続時間、カメラ制御に関する制御権の順番待ち人数、１つのビューワの制御権保持占有時間、映像とカメラ制御に関する接続可能な最大クライアント数などである。
【００７２】
ユーザからの入力がＯＫボタンの場合には、ステップＳ１１０２からステップＳ１１０５に進み、更新された内部データをカメラ制御サーバおよび映像サーバに関する設定情報を格納する特定のファイルなどへ書き出し、ステップＳ１１０６で変更を反映するためにカメラサーバを再起動するかを尋ねるパネルを出す。再起動する場合にはステップＳ１１０７でカメラ制御サーバや映像サーバなどを再起動して、ステップＳ１１０８で設定プログラムを終了する。再起動しない場合にはステップＳ１１０６から直接ステップＳ１１０８に進み、終了する。また、ステップＳ１１０２でのユーザの入力がキャンセルボタンである場合には、ステップＳ１１０２から直接ステップＳ１１０８に進み、終了する。
【００７３】
図１２は、映像変換サーバにおける映像データの大まかな流れを、模式的に示した図である。
カメラサーバから送信されたソース映像データ（Ｍｏｔｉｏｎ ＪＰＥＧ、ＱＶＧＡサイズ３２０ｘ２４０）は、映像変換サーバのカメラサーバ向け通信スタックを経由して受信され、ＪＰＥＧデコーダに渡され、続いて、携帯電話向けに設定されたＭＰＥＧ−４ エンコーダに渡され、携帯電話向け映像データ（ＭＰＥＧ−４ ｓｉｍｐｌｅｐｒｏｆｉｌｅ， ＱＣＩＦサイズ１７６ｘ１４４， ６４Ｋｂｐｓ）に加工された上で、映像クリップとして、携帯電話網向けの通信スタックを経由して、携帯電話ビューワへと送信される。
【００７４】
図１３は、映像変換サーバ４００の動作を示した流れ図である。
映像変換サーバ４００は、まず起動時にステップＳ１３０１で特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から映像変換サーバの動作設定情報を読み出して、それに基づき動作を開始する。ここで、クライアントである携帯電話ビューワプログラムからのリクエストを受け付ける通信ポートを開き、続いて、ステップＳ１３０２のリクエスト受付状態に入る。
【００７５】
リクエスト（ＨＴＴＰリクエストのメッセージなど）が受け付けられたら、Ｓ１３０２を抜け、ステップＳ１３０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、Ｓ１３０２に戻る。可ならば、ステップＳ１３０４で接続処理として、クライアントとの情報の受渡しを行うクライアント対応スレッドを生成し、クライアントの登録を行い、Ｓ１３０２に戻る。
【００７６】
生成されたクライアント対応スレッドでは、ステップＳ１３１１で対応するクライアントからのリクエストを読み込み、内容を解析する。リクエストは、例えばＨＴＴＰリクエストとして映像変換サーバ４００に渡される。なお、ＨＴＴＰリクエストには、ＰＯＳＴメソッドが使われる場合もあり、ＧＥＴメソッドが利用される場合もある。
【００７７】
次に、ステップＳ１３１２で、リクエスト内容からエンコードパラメータ情報（映像変換パラメータ）、カメラサーバへの接続情報（ソース映像情報）、ＰＴＺシーケンス、映像クリップの最大サイズ（映像クリップ上限値）、通知先情報（通知先アドレス）、および、ユーザ識別子やパスワードなどユーザ識別情報を取り出す。これらは、それぞれ「ｖｉｄｅｏｅｎｃｏｄｅｐａｒａｍ＝」、「ｃａｍｅｒａｓｅｒｖｅｒｓ＝」、「ＰＴＺ＝」、「ｍｏｖｉｅｓｉｚｅｍａｘ＝」、「ｎｏｔｉｆｙｔｏ＝」、「ｕｓｅｒｉｄ＝」、「ｕｓｅｒｐｗ＝」の値として指示されている。
【００７８】
映像変換パラメータは、変換用コーデックの選択やそのコーデックへのパラメータ、および、コーデック入力用／出力用のデータ形式などを記述している。ソース映像情報とは、例えば、ライブ映像を提供するカメラサーバのネットワークアドレスとポート番号などの通信属性情報である。通知先アドレスとは、例えば、ユーザの携帯電話端末を指定したメイルアドレスである。
【００７９】
次に、ステップＳ１３１３で、リクエストに対するレスポンスとして、「すぐに映像を生成できないので、しばらくしてメイル連絡します」との旨を示す情報を返す。次に、ステップＳ１３１４で、ソース映像情報およびユーザ識別情報に従って、映像取得部を初期化する。具体的には、ソース映像を提供するカメラサーバに接続し、ソース映像取得を開始する。
【００８０】
そして、ステップＳ１３１５に進み、映像変換パラメータに従って映像変換部を初期化する。この映像変換部は、ＭＰＥＧ−４エンコーダなどから構成される。そして、ステップＳ１３１６に進み、映像送信部を初期化する。この際、映像送信部に映像クリップ上限値、および、通知先アドレスを指示する。
【００８１】
さらに、ステップＳ１３１７に進み、映像取得部から映像変換部へ、映像変換部から映像送信部へとそれぞれの処理データが受渡しされるように相互の関連付けを行った上で、カメラ制御部がＰＴＺシーケンスに従ってカメラサーバのカメラ制御を行う。そして、ステップＳ１３１８に進み、映像取得部、映像変換部、映像送信部の後処理を行う。そして、ステップＳ１３１９に進み、クライアント対応スレッドを終了する。
【００８２】
次に、映像変換サーバの中で機能している映像取得部、映像変換部、映像送信部、カメラ制御部について順次説明する。
映像取得部は、まず、初期化時に受取ったソース映像情報およびユーザ識別情報に従って、ライブ映像を提供するカメラサーバに接続する。そして、カメラサーバから映像データを取得し、取得時のタイムスタンプを付与して映像データを映像変換部へ渡す。本実施形態におけるカメラサーバは、映像データをＭｏｔｉｏｎ ＪＰＥＧ形式で提供するので、タイムスタンプが付与されるのは、個々のＪＰＥＧデータである。
【００８３】
また、カメラ制御部からカメラサーバ接続切換え指定を受けた場合には、指示内容に従って、接続先カメラサーバを切り換える。また、カメラサーバから禁止エリア検出を通知された場合には、映像データに代えて禁止エリア検出通知を映像変換部へ渡す。
【００８４】
次に、映像変換部では、まず、初期化時に受取ったコーデックへのパラメータ、および、コーデック入力用／出力用のデータ形式などをＭＰＥＧ−４エンコーダに設定する。そして、映像取得部から受取ったソース映像データを、コーデック入力用のデータ形式および画像サイズに整えてからＭＰＥＧ−４エンコーダに入力し、その処理結果を映像送信部へ渡す。本実施形態における映像変換部では、ＪＰＥＧ形式のソース映像データを予めＱＣＩＦサイズかつＹＵＶ４１１形式に整えてからＭＰＥＧ−４コーデックへ入力し、生成されたＭＰＥＧ−４データ（Ｉ−ｆｒａｍｅまたはＰ−ｆｒａｍｅ）を映像送信部へ受け渡す。この際、映像取得部で付与されたタイムスタンプも併せてＭＰＥＧ−４コーデックへ入力される。
【００８５】
なお、映像取得部から禁止エリア検出が通知されている場合には、カメラ制御を制限された領域であって映像を表示できない旨を示す合成画面を、ソース映像データに代えて、ＭＰＥＧ−４コーデックへ入力する。
【００８６】
次に、映像送信部では、まず、初期化時に受取った映像クリップ上限値に従ってメモリ領域を確保する。そして、映像変換部が生成した携帯電話向け映像データを受取り、確保したメモリ領域に保持する。さらに、映像送信部では、禁止エリア検出通知を受け取った時点で、メモリ領域の利用率をも加味した上で、映像クリップの分割点を決定する。そして、分割点と判断した場合には、携帯電話向け映像クリップのデータフォーマットに準拠したヘッダ情報を前置して、メモリ領域に保持している映像データをファイルとして保存し、メモリ領域を再利用する。これによって、映像クリップが複数のファイルに分割保存される。
【００８７】
また、映像送信部では、映像取得部で得られるカメラ制御状態情報を受け取り、時間軸に沿って保持する。そして、予め設定されている時間周期でカメラ制御状態情報から、カメラ制御状態情報に相当するカメラ制御シーケンス（ＰＴＺシーケンス）を生成して、そのＰＴＺシーケンスをパラメータとする専用ビューワの起動指示をリンク情報として映像クリップに組み込む。例えば、隣接するカメラ制御状態情報の差分からＰＴＺシーケンスを構成するが、ＰＴＺシーケンス初期値を指定する場合やプリセット位置やホームポジションなどと一致する場合には、絶対値指定を指示する。この際、図１４に示すように、ある映像データの区間（映像セグメント）に対応するリンク情報には、時間軸を逆方向に過剰な長さのカメラ制御シーケンスを割当てる。すなわち、映像クリップ中で隣接するリンク情報には、重複したカメラ制御シーケンスが冗長に割当てられることになる。
【００８８】
また、映像送信部は、一定周期のタイミングで映像データを区分分割し、複数の映像区間を順番に連結した上で、それぞれの映像区間にＰＴＺシーケンスを関連付ける。複数の映像区間を順番に連結する際には、各映像区間の時間、優先度及び関連性等を反映させる。尚、映像データを区分分割するタイミングは、カメラサーバの所定事象の発生時としても良い。ここで、映像区間の優先度及び関連性は、例えば、カメラサーバに対する制御頻度、制御回数及びカメラサーバにおける発生事象内容等のカメラサーバ側の属性、或いは、例えば、携帯電話ユーザの個人情報及び好み設定等の携帯側の属性に基づいて決定される。
【００８９】
さらに、カメラサーバ切り換えが行われた直後の映像区間に対応するリンク情報では、カメラサーバ切り換え前後のカメラサーバ接続情報の指定を追加する。そして、カメラ制御部からＰＴＺシーケンスの終了を通知された時点で、メモリ領域に保持している映像データの残りを同様にファイルとして保存した上で、それまでに保存している複数の映像クリップへのリンク情報を埋め込んだ携帯電話端末への通知情報を作成し、初期化時に受取った通知先アドレスへ通知する。これによって、通知情報を受取った携帯電話端末から各映像クリップへのダウンロード要求を可能とする。なお、映像送信部は、ＨＴＴＰサーバ機能を備えており、携帯電話端末からのＨＴＴＰ利用の映像クリップのダウンロード要求に対応する。
【００９０】
次に、カメラ制御部では、ＰＴＺシーケンスを解釈して、カメラサーバに送るべきカメラ制御コマンドを作成し、ＰＴＺシーケンスに指示されたタイミングで作成したカメラ制御コマンドをカメラサーバに送信することで、カメラサーバのカメラ制御を行う。また、ＰＴＺシーケンス中にカメラサーバ接続切換え指定を見つけた場合には、映像取得部にその旨を指示する。そして、ＰＴＺシーケンスを解釈し終えた時点で、ＰＴＺシーケンスの終了を映像送信部に通知する。
【００９１】
以上の構成で、携帯電話端末上に実装された映像クリップビューワを使うユーザは、映像変換サーバに映像クリップを要求することができる。そして、映像変換サーバの機能により、映像クリップが作成された時点のカメラ制御状態情報を、映像クリップ再生ユーザが利用可能となる。特に、膨大な数のカメラサーバが存在する際に、ユーザの求めるカメラ制御およびその結果得られた映像を提供することが可能となる。
【００９２】
以上で、ネットワーク上に配置されたカメラサーバから送られるライブ映像を、携帯電話端末向け映像クリップに変換してユーザに提供することができる。特に、本実施形態の映像変換サーバでは、カメラサーバのカメラ制御状態情報を反映した映像クリップを生成する点に特徴がある。
【００９３】
本実施形態では、携帯電話網とネットワークとを結ぶゲートウェイとは独立にネットワーク上に映像変換サーバが実装される例について説明しているが、映像変換サーバがゲートウェイの一部として実装されても良い。また、映像変換サーバとゲートウェイとがＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）なども含めて専用線で接続されるような接続形態も容易に想像できる。
【００９４】
また、本実施形態では、ＨＴＴＰ通信を用いて携帯電話ビューワと映像変換サーバとが通信する例について説明しているが、この通信は、ＳＭＴＰ（Ｓｉｍｐｌｅ ＭａｉｌＴｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いた通信であっても良い。また、携帯電話ビューワと映像変換サーバとのＨＴＴＰ通信やＳＭＴＰ通信は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）などの併用により、安全な通信経路を利用しても良い。
【００９５】
本実施形態では、電話ビューワがカメラ制御コマンド列（ＰＴＺシーケンス）を発行することで、カメラ制御を行うユーザと映像クリップ要求するユーザとが同一である例について説明しているが、カメラ制御コマンドを発行するユーザは別のユーザであっても良い。例えば、あるユーザがＰＣ上の専用ビューワなどを利用してカメラ制御を行っている際に、別のユーザが映像クリップを要求するような事例である。
【００９６】
さらに、ＳＭＴＰ通信などを利用して映像クリップを要求する場合には、映像クリップ要求ユーザと映像クリップ受信ユーザとが異なっていることも考えられる。この場合には、映像クリップ要求ユーザのアクセス権限と映像クリップ受信ユーザのアクセス権限との何れか一方あるいは両方を評価して、映像クリップ生成に反映することが考えられる。
【００９７】
本実施形態では、設定された一定の周期でカメラ制御シーケンスを含むリンク情報を生成し、映像クリップに組み込む例について説明しているが、リンク情報の生成のタイミングは、一定周期に限定されない。例えば、カメラ制御状態情報の変化値の累積値が所定の条件を満たしたタイミングであっても良い。また、映像データ自体の変化値（例えば、画像認識されるオブジェクトの個体数の変
化）が所定の条件を満たしたタイミングであっても良い。
【００９８】
また、本実施形態の映像送信部で生成しているカメラ制御シーケンスは、映像取得部から得られるカメラ状態情報に基づき生成しているが、これは、カメラ制御部が解釈しているＰＴＺシーケンスから部分シーケンスを切り出すことで生成しても良い。この方法の場合、映像クリップ作成を要求したユーザの意図に一層近いカメラ制御シーケンスが得られる一方で、禁止エリアへのカメラ制御などを含む場合には、映像データと同期しないカメラ制御シーケンスが生成されるという得失がある。
【００９９】
本実施形態の映像送信部では、映像クリップ中のある映像データ区間に対応するリンク情報に、隣接する映像データ区間の時間中のカメラ制御シーケンスを割当てられる例について説明しているが、割当てられるカメラ制御シーケンスの長さ（あるいは時間）は、映像データ区間の時間と従属する必要は無い。典型的には、映像変換サーバに事前設定された固定長（時間）であっても良い。また、
割当てられるカメラ制御シーケンスの長さ（時間）は、各種の事象の発生に依存することも容易に想像できる。
【０１００】
本実施形態では、カメラサーバから取得した映像を携帯電話向け映像クリップに変換して送信する例について説明したが、映像クリップの形式は、携帯電話向け映像クリップに限定されない。例えば、マイクロソフト社のＷｉｎｄｏｗｓ（Ｒ） ＭｅｄｉａＰｌａｙｅｒでは、ＩＳＯ標準のＭＰＥＧ−４コーデックにも対応するため、本実施形態の映像送信部が映像クリップを生成する時点で、マイクロソフト社のＡＳＦ形式に準拠したデータフォーマットに整形し、かつ、そのフォーマットの中でＭＰＥＧ−４コーデックを指定することで、Ｗｉｎｄｏｗｓ（Ｒ） ＭｅｄｉａＰｌａｙｅｒでの再生が可能となる。同様にして、Ａｐｐｌｅ社 ＱｕｉｃｋＴｉｍｅ Ｆｉｌｅ Ｆｏｒｍａｔに準拠することで、ＱｕｉｃｋＴｉｍｅＰｌａｙｅｒにも対応可能である。
【０１０１】
また、映像クリップへのリンク情報組込みとして、本実施形態では、カメラ制御情報を組み込む例について説明しているが、例えば、映像クリップの末尾では、カメラ制御情報の如何に関わらず、現在のカメラサーバに接続するリンク情報を組み込むことも容易に想像できる（図１７（ａ））。また、カメラ制御コマンドをリンク情報として組み込む場合、そのカメラ制御コマンドが行おうとしている制御を説明するテロップを映像に挿入することも考えられる（図１７（ｂ））。また、映像変換サーバに事前設定されたリンク情報（例えば、広告情報へのリンク情報）を組み込むことも容易に想像できる。さらに、これらの複数種類のリンク情報が混在していても良い。
【０１０２】
本実施形態では、携帯電話端末のユーザが非専用ビューワを使って映像クリップ再生中にクリックを検出すると、その時点で、専用ビューワを起動する例について説明したが、クリック時のアクションは、これに限定されない。例えば、リンク情報中に指定されたカメラ制御情報を使って制御した映像クリップを再生成するアクションであっても良い。
【０１０３】
＜第２の実施形態＞
（サーバ側に制御識別子の管理表を保持、間接制御）
本発明の第２の実施形態では、第１の実施形態同様、インターネット上に配置された多数のカメラサーバから取得したライブ映像を、携帯電話端末向け映像クリップに変換して送信する例について説明する。特に、本実施形態では、映像変換サーバがカメラ制御情報履歴の管理表を保持する点に特徴がある。
【０１０４】
本実施形態では、ネットワークの接続形態やハードウェア構成、および、各ソフトウェアの動作の多くは、第１の実施形態で説明した通りである。ただし、図１３で示した映像変換サーバの一部の動作が第１の実施形態とは異なる。
【０１０５】
本実施形態では、映像変換サーバの映像送信部が次のように動作する。本実施形態の映像送信部は、映像クリップへ組み込むリンク情報の記述が映像変換サーバ内部に管理するカメラ制御情報履歴の管理表を参照する専用ビューワの起動となる点で、第１の実施形態の映像送信部と異なる。
【０１０６】
第２の実施形態の映像送信部では、まず、第１の実施形態と同様、受け取ったカメラ状態情報を時間軸に沿って保持し、そこからカメラ制御状態情報に相当するカメラ制御シーケンス（ＰＴＺシーケンス）を生成するが、この際、生成したＰＴＺシーケンスやカメラサーバ接続情報を直接リンク情報として映像クリップに組み込む事をしない。代わりに、生成したＰＴＺシーケンスやカメラサーバ接続情報を映像変換サーバ内の管理表（以下、制御履歴管理表と称す。図１８）に格納し、その制御履歴管理表への参照情報をリンク情報として映像クリップに組み込む。
【０１０７】
制御履歴管理表への参照情報としては、制御履歴管理表の各項目に識別子を割当て、その識別子を参照情報とする。割当てる識別子は、例えば、カメラサーバ識別子（典型的には、ＩＰアドレス）とＰＴＺシーケンスの生成時刻とから合成することができる。あるいは、順番に割当てたシリアル番号であっても良い。
【０１０８】
そして、携帯電話端末で実行される専用ビューワからのカメラ制御情報参照要求があった場合には、識別子をキーとして制御履歴管理表内で検索し、見つかったＰＴＺシーケンスやカメラサーバ接続情報を携帯電話端末で実行される専用ビューワに返答するよう動作する。
【０１０９】
以上の構成で、携帯電話端末上に実装された映像クリップビューワを使うユーザは、映像変換サーバに映像クリップを要求することができる。そして、映像変換サーバの機能により、映像クリップが作成された時点のカメラ制御状態情報を、映像クリップ再生ユーザが利用可能となる。
【０１１０】
特に、本実施形態では、映像変換サーバ内に蓄積されたカメラ制御情報を参照して、実際のカメラサーバを制御する。これにより、映像クリップ生成時点ではなく、映像クリップ再生時点でのカメラ制御パラメータなどをも反映した処理が可能となる。例えば、映像クリップ生成を要求したユーザと映像クリップを再生しているユーザとが異なったアクセス権限を設定されている場合に、再生ユーザの権限を反映してカメラ制御することが可能となる。これは、映像クリップが複数のユーザ間でメイルなどで受渡しされる状況下で効果がある。
【０１１１】
また、映像変換サーバ内に管理される制御履歴管理表を参照することによって、生成された映像クリップの時間枠に隣接する時間枠のカメラ制御情報を参照することも可能となる。すなわち、映像クリップに含まれる識別子（制御履歴管理表への参照情報）をたどる事によって、映像クリップの前後で行われたカメラ制御を、芋づる式に取得することが可能となる。
【０１１２】
本実施形態では、携帯電話端末で実行される専用ビューワが、映像クリップ中に組み込まれた識別子を使って、映像変換サーバにカメラ制御情報を問い合わせ、カメラ制御情報を取得し、カメラを制御する例について説明しているが、カメラ制御を実行するのは、携帯電話端末で実行される専用ビューワに限定されない。例えば、映像クリップ中に組み込まれた識別子を指定した上で、映像変換サーバにカメラサーバのカメラ制御を委譲するよう実施しても良い。
【０１１３】
尚、本実施形態では、映像変換サーバ自身が制御履歴管理表を管理する例について説明しているが、制御履歴管理表は、別のデータベースサーバなどが管理しても良い。
【０１１４】
＜第３の実施形態＞
（映像クリップ中に連結するカメラサーバの選択と割当ての工夫）
本発明の第３の実施形態では、第１の実施形態と同様、インターネット上に配置された多数のカメラサーバから取得したライブ映像を、携帯電話端末向け映像クリップに変換して送信する例について説明する。特に、本実施形態では、事前に複数のカメラサーバの映像ストリームを映像クリップに変換しておき、それらを適切に編集（切り出しと連結）する点に特徴がある。
【０１１５】
本実施形態では、ネットワークの接続形態やハードウェア構成、および、各ソフトウェアの動作の多くは、第１の実施形態で説明した通りである。ただし、図１３で示した映像変換サーバの一部の動作が第１の実施形態とは異なる。
【０１１６】
本実施形態では、映像変換サーバがステップＳ１３１２のリクエスト内容から、複数台のカメラサーバへの接続情報を取り出した時点で、各カメラサーバに対応する映像取得部、映像変換部、カメラ制御部を用意し、各カメラサーバからの映像ストリームを並行して映像クリップへと変換する点で、第１の実施形態の映像変換サーバと異なる。
【０１１７】
そして、リクエスト元が指定する基準に従って、それぞれの映像クリップから適切な長さの映像区間を切り出し、第１の実施形態の映像送信部と同様に、カメラ制御情報やカメラサーバ接続情報を含むリンク情報を組み込んだ映像クリップを作成し、リクエスト元に送信する。
【０１１８】
この中で、リクエスト元が指定する基準には、映像ストリーム取得中の各カメラサーバでのカメラ制御量、カメラ制御頻度、動き検知や接点などイベント発生の有無や発生順序、あるいは、取得された映像のフレームレートや画質などが用いられる。
【０１１９】
以上の構成で、携帯電話端末上に実装された専用ビューワが、映像クリップ内に組み込まれたカメラ状態情報を抽出して、カメラサーバのカメラ制御することができる。特に、本実施形態では、複数のカメラサーバから得られる映像データを映像区間単位で編集し、適切な長さ（時間）の映像クリップをユーザに提供することが可能となる。
【０１２０】
本実施形態では、カメラサーバ側の属性（カメラ制御量やイベント発生など）を基準として映像クリップの切り出しと連結を行っているが、この基準は、映像クリップのリクエスト元である携帯電話端末側の属性であっても良い。例えば、携帯電話端末の端末識別子に対応して携帯電話キャリアが管理している個人情報（性別、年齢、職業、地域など）や、事前に収集したユーザの好み情報などが
考えられる。
【０１２１】
＜第４の実施形態＞
（カメラサーバ一体型の映像変換サーバ（ＶＢ組み込み例））
本発明の第４の実施形態では、第１の実施形態と同様、インターネット上に配置されたカメラサーバから取得したライブ映像を、携帯電話端末向け映像クリップに変換して送信する例について説明する。特に、本実施形態では、映像変換サーバがカメラサーバと一体化している点に特徴がある。
【０１２２】
本実施形態では、ネットワークの接続形態やハードウェア構成、および、各ソフトウェアの動作の多くは、第１の実施形態で説明した通りである。ただし、図１の利用形態、図２の映像変換サーバのハードウェア構成、および、図１３で示した映像変換サーバの一部の動作が第１の実施形態とは、異なる。
【０１２３】
まず、本実施形態では、映像変換サーバとカメラサーバとが一体化しているため、利用形態は、図２０の通りである。また、映像変換サーバのハードウェア構成も図３のカメラサーバのハードウェア構成の通りである。さらに、映像変換サーバの映像取得部は映像サーバのステップＳ８０６と同様に、ハードウェア構成の映像キャプチャボードを使って映像データを獲得する。
【０１２４】
本実施形態では、映像変換サーバが、ハードウェア構成の映像キャプチャボードを使って映像データを獲得する例について説明したが、カメラサーバと一体化した映像変換サーバであっても、第１の実施形態と同様に、他のカメラサーバの映像サーバからも映像データを取得できるよう設計することも容易に想像できる。これによって、カメラサーバのエンコード処理の負荷分散、配送処理の負荷分散、および、ネットワーク通信インフラにおける輻輳防止などの効果がある。
【０１２５】
以上説明したように、上記実施形態によれば、カメラサーバに装備されたカメラ制御機能を適切に反映して映像クリップを生成する事で、携帯電話端末に広く実装されている映像クリップ再生表示機能とカメラ制御機能付きカメラサーバとの連携を向上させることが可能となる。
【０１２６】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１２７】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２８】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１２９】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３０】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３１】
【発明の効果】
本発明によれば、例えばカメラサーバ等の撮像装置によって取得された画像データに、その画像データに付帯する例えば撮像装置の制御情報等の前記撮像装置の状態情報を反映させ、携帯情報端末に対して適切に提供することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るライブ映像通信システムの構成を概略的に示した図である。
【図２】映像変換サーバを動作させるハードウェア構成の一例を示した図である。
【図３】カメラサーバのハードウェア構成の一例を示した図である。
【図４】ビューワを動作させるハードウェア構成の一例を示した図である。
【図５】プログラムを構成する部分を模式化した図である。
【図６】携帯電話上で映像クリップを再生表示する非専用ビューワの動作の流れを示した図である。
【図７】カメラサーバのカメラ動作サーバの動作の流れを示した図である。
【図８】カメラサーバ内の映像サーバの動作の流れを示した図である。
【図９】ＰＴＺシーケンスを作成する時の携帯電話の様子を例示した図である。
【図１０】カメラ制御サーバや映像サーバが読み出す動作設定情報を特定のファイルに設定するカメラサーバ設定プログラムの表示画面の一例を示した図である。
【図１１】カメラサーバの設定プログラムの動作を示した図である。
【図１２】映像変換サーバにおける映像データの大まかな流れを模式的に示した図である。
【図１３】映像変換サーバの動作の流れを示した図である。
【図１４】映像データに対して時間軸を逆方向に過剰な長さのカメラ制御シーケンスを割当てた様子を模式的に示した図である。
【図１５】携帯電話端末の表示装置上における表示例を示した図である。
【図１６】ＰＴＺシーケンスの作成の流れを示した図である。
【図１７】映像クリップの表示例を示した図である。
【図１８】本発明の第２の実施形態における制御履歴管理表を説明するための図である。
【図１９】本発明の第１の実施形態における専用ビューワの流れを示した図である。
【図２０】本発明の第４の実施形態における典型的な利用形態を示した図である。
【符号の説明】
１０１、１０２ カメラサーバ
２００ ビューワ
３００ 中継サーバ
４００ 映像変換サーバ
５００ ゲートウェイ
６０１、６０２ 携帯電話端末
４０１、１０１１、６０１１ 記憶装置
４０２、１０１４ ネットワークＩ／Ｆ
４０３、１０１５、６０１３ ＣＰＵ
１０１２ 映像キャプチャボード
１０１３ シリアルＩ／Ｆ
６０１２ 無線通信Ｉ／Ｆ
１０１ａ カメラ制御サーバ
１０１ｂ 映像サーバ
４００ａ カメラ制御部
４００ｂ 映像取得部
４００ｃ 映像変換部
４００ｄ 映像送信部
６０１ａ カメラ制御部
６０１ｂ 映像表示部

Claims (24)

1. 一又は複数の撮像装置より画像データを取得する画像取得手段と、
   前記画像取得手段にて取得された前記画像データに、前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段と、
   前記処理手段により生成された前記画像データを一又は複数の携帯情報端末に対して送信する画像送信手段とを有することを特徴とする情報処理装置。
2. 前記画像取得手段は、前記撮像装置から送信された画像データをネットワークを介して取得することを特徴とする請求項１に記載の情報処理装置。
3. 前記画像取得手段は、前記撮像装置の前記状態情報を取得し、前記画像送信手段は、前記状態情報に基づいて前記撮像装置の制御指示データを生成し、前記画像変換手段により変換された前記画像データに組み込むことを特徴とする請求項１に記載の情報処理装置。
4. 前記画像送信手段は、前記画像データの一部区間或いは全体に前記制御指示データを関連付けて組み込むことを特徴とする請求項３に記載の情報処理装置。
5. 前記画像送信手段は、前記携帯情報端末に搭載される前記撮像装置を制御可能なソフトウェアの起動の指示情報を、前記画像データに組み込むことを特徴とする請求項１、３、４の何れか１項に記載の情報処理装置。
6. 前記指示情報は、画像情報の取得先の切り換え前後における撮像装置を指定する情報を含むことを特徴とする請求項５に記載の情報処理装置。
7. 前記画像送信手段は、前記撮像装置において所定事象が発生したタイミングで前記画像データを区分分割し、複数の画像区間を順番に連結した上で、それぞれの画像区間に前記制御指示データを関連付けることを特徴とする請求項４に記載の情報処理装置。
8. 前記画像送信手段は、一定周期のタイミングで前記画像データを区分分割し、複数の画像区間を順番に連結した上で、それぞれの画像区間に前記制御指示データを関連付けることを特徴とする請求項４に記載の情報処理装置。
9. 前記画像送信手段は、各画像区間の時間、各画像区間の優先度及び各画像区間の関連性のうちの少なくとも何れか１つを反映させて、前記複数の画像区間を順番に連結することを特徴とする請求項７又は８に記載の情報処理装置。
10. 前記画像送信手段は、隣接する画像区間に組み込む前記制御指示データと一部重複するように各画像区間に前記制御指示データを冗長に組み込むことを特徴とする請求項７〜９の何れか１項に記載の情報処理装置。
11. 前記各画像区間の優先度及び前記各画像区間の関連性は、前記撮像装置側の属性に基づいて決定されることを特徴とする請求項９に記載の情報処理装置。
12. 前記撮像装置側の属性は、前記撮像装置に対する制御頻度、前記撮像装置に対する制御回数、及び、前記撮像装置における発生事象内容のうちの少なくとも何れか１つを含むことを特徴とする請求項１１に記載の情報処理装置。
13. 前記各画像区間の優先度及び前記各画像区間の関連性は、前記携帯情報端末側の属性に基づいて決定されることを特徴とする請求項９に記載の情報処理装置。
14. 前記携帯情報端末側の属性は、前記携帯情報端末の利用者の個人情報及び好み設定のうちの少なくとも何れか１つを含むことを特徴とする請求項１３に記載の情報処理装置。
15. 前記画像送信手段は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によるセッション指向の情報送信処理を実行することを特徴とする請求項１に記載の情報処理装置。
16. 前記画像送信手段は、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による非セッション指向の情報送信処理を実行することを特徴とする請求項１に記載の情報処理装置。
17. 一又は複数の撮像装置より画像データを取得する画像取得手段と、前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段とを含む情報処理装置から、前記処理手段にて生成された前記画像データを受信する画像受信手段を有することを特徴とする携帯情報端末。
18. 前記情報処理装置が前記撮像装置の前記状態情報に基づいて生成した前記撮像装置の制御指示データを取得する取得手段と、
    前記制御指示データに基づいて生成された前記撮像装置に対する制御コマンドを発行するコマンド発行手段とを有することを特徴とする請求項１７に記載の携帯情報端末。
19. 前記コマンド発行手段は、前記情報処理装置から取得される接続情報にて示される前記撮像装置に対して前記制御コマンドを発行することを特徴とする請求項１８に記載の携帯情報端末。
20. 前記情報処理装置から取得された前記接続情報が複数の撮像装置を示す場合、前記複数の撮像装置から実際の接続先となる前記撮像装置を選択する選択手段を更に有し、
    前記コマンド発行手段は、前記選択手段にて選択された撮像装置に対する制御コマンドを発行することを特徴とする請求項１９に記載の携帯情報端末。
21. 一又は複数の撮像装置より画像データを画像取得手段にて取得し、
    前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させた画像データを処理手段にて生成し、
    前記処理手段により生成された前記画像データを一又は複数の携帯情報端末に対して送信することを特徴とする情報処理方法。
22. 一又は複数の撮像装置より画像データを取得する画像取得手段と、前記画像取得手段にて取得された前記画像データに前記画像データに付帯する前記撮像装置の状態情報を反映させる処理手段とを含む情報処理装置から、前記処理手段にて生成された前記画像データを受信することを特徴とする情報処理方法。
23. 請求項２１又は２２に記載の情報処理方法をコンピュータに実行させるためのプログラム。
24. 請求項２３に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images