JP2004343175A - 映像中継装置 - Google Patents

Abstract

【課題】ネットワーク上からソース映像データを取得し、携帯電話端末等の携帯情報端末向けに適切に提供可能とする。
【解決手段】ネットワーク９上に配置されたカメラサーバ１から送られるライブ映像を、映像変換サーバ５を介して携帯電話端末７向けに変換して中継する映像通信システムにあって、映像変換サーバ５が携帯電話端末７から映像クリップを要求される際に、併せてカメラサーバ１に接続されたカメラ装置（撮像装置）の操作（パン、チルト、ズーム、逆光補正、プリセット指定等）を指示するカメラ制御シーケンスを受取るとともに、そのＰＴＺシーケンスに従って、カメラサーバ１を操作して取得した映像情報を携帯電話端末７向けに変換して、その変換後の映像情報を適切な映像クリップに分割した上で、携帯電話端末７向けに提供する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、例えばインターネット上のカメラサーバからソース映像データを取得して、携帯電話端末等の携帯情報端末向けに配信するのに好適な映像中継装置に関する。
【０００２】
【従来の技術】
映像データを配信する既存の映像配信技術としては、以下に述べるようなものが知られている。
［ライブ映像通信システム］
撮影したライブ映像を、インターネット等の通信インフラストラクチャを使って配信するとともに、撮影のためのカメラ設定やカメラ操作等を指示する技術が確立され、製品が販売されている。例えば、キヤノン社の映像配信システムＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅ、及び、同社のライブネットワークカメラサーバＶＢ１０１、サーバ内蔵型ネットワークカメラＶＢ−Ｃ１０等である。
【０００３】
キヤノン社の映像配信システムＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅ、及び、同社のライブネットワークカメラサーバＶＢ１０１等では、映像配信に加えて、パン、チルト、ズーム、逆光補正といったカメラ制御をネットワークを介して提供可能となっている。また、カメラ制御による可視範囲に相当するパノラマ画像を生成する機能を備えている。これらの技術は、特許文献１、２等に開示されている。
【０００４】
［第三世代携帯電話技術］
従来の携帯電話サービスよりも高い電波利用効率と通信帯域を備えた携帯電話サービスとして、第三世代（３Ｇ）の携帯電話サービスが提供されるようになっている。例えば、ＮＴＴドコモ社の第三世代（３Ｇ）携帯電話サービスＦＯＭＡ（Ｒ）が知られている。第三世代（３Ｇ）の携帯電話では、電話通話しながらインターネットアクセス等のデータ通信が可能である、例えばインターネット上の画像データにアクセスしながら通話することができる。ＮＴＴドコモ社によるＦＯＭＡ（Ｒ）サービスでは、マルチアクセスと呼ばれる接続形態を用意しており、これを利用することで、ウェブブラウジング等のデータ通信を行いながら電話通話を可能にしている。
【０００５】
さらに、第三世代携帯電話端末では、端末自体の処理能力も強化されており、これまでパーソナルコンピュータ等で行っていた作業を携帯電話端末で処理可能になっている。例えば、メールやウェブブラウジング及び映像送受信等の機能を実装している携帯電話端末が提供されている。
【０００６】
また、３Ｇ−ＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、第三世代携帯電話向けの映像伝送規格として、３Ｇ−３２４Ｍ（回線交換用）等を策定して、携帯電話向け映像伝送技術の標準化を図っている。
【０００７】
［ＭＰＥＧ−４コーデック］
移動体通信網に接続する携帯情報端末から広帯域インターネットに接続するパーソナルコンピュータまでの映像送受信端末の広がりを受けて、数十ｋｐｂｓから数十Ｍｂｐｓの広いビットレートをカバーする高圧縮符号化効率、及び、無線やインターネット等の伝送路誤りに対する強い耐性等を備えた動画像圧縮符号化方式として、ＩＳＯで１９９９年にＭＰＥＧ−４が制定されている。
【０００８】
また、ＭＰＥＧ−４を用いた映像配信サービスが、個人情報端末ＰＤＡや携帯電話端末向けに提供されている。例えば、ＮＴＴドコモ社の第三世代（３Ｇ）携帯電話サービスＦＯＭＡ（Ｒ）では、携帯電話端末（ビジュアル端末）間でＭＰＥＧ−４を用いて相互に映像を送受信するサービスを提供している。
【０００９】
［ＲＴＰ／ＲＴＣＰ］
ネットワーク上で、リアルタイムに情報（特に映像や音声等を想定している）を受渡しするアプリケーションのための伝送用プロトコルとして、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が、ＩＥＴＦによってＲＦＣ１８８９ ”ＲＴＰ： ＡＴｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ”として勧告されている。ＲＴＰでは、情報を受渡しする端末のタイムスタンプを使って、通信路の状態を観察し、適切な状態で情報を受渡しできるよう調整する仕組みが盛り込まれている。
【００１０】
［ＲＴＳＰ］
ＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）が、ＩＥＴＦによってＲＦＣ２３２６”Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ （ＲＴＳＰ）”として勧告されている。リアルタイムに情報を伝送するに際して、ＲＴＰがサーバからクライアントへ一方向にブロードキャスト（或いはマルチキャスト）することを想定しているのに対して、ＲＴＳＰではサーバとクライアント間でユニキャストかつ双方向の伝送を想定している。つまり、ＲＴＳＰでは、ビューアがサーバと交信し、映像コンテンツ等を巻き戻したり、別のチャプタへスキップしたりすること等が可能となっている。
【００１１】
さらに、ＲＴＳＰでは、伝送レイヤーでＲＴＰ等を利用してリアルタイムに情報（特に映像や音声等を想定している）を受渡しするアプリケーションのための制御用プロトコルとして利用されることもある。
【００１２】
［携帯電話向け映像クリップサービス］
携帯電話端末に映像クリップ（ファイル）を表示する技術が提供されるようになってきている。例えば、ＮＴＴドコモ社のｉモーション（Ｒ）やＫＤＤＩ社のｅｚｍｏｖｉｅ（Ｒ）等がある。これらのサービスでは、ＭＰＥＧ−４コーデック等で圧縮符号化された映像データをサーバに保存し、携帯電話端末に内蔵するデータ通信機能を使ってサーバからダウンロードした上で、同じく携帯電話端末に内蔵するデコーダを使って映像を携帯電話端末の画面に表示する。なお、これらのサービスでは、いずれも映像クリップの上限が決められており、例えばＫＤＤＩ社のｅｚｍｏｖｉｅ（Ｒ）の場合、２４０ｋｂｙｔｅｓが上限となっている。
【００１３】
【特許文献１】
特開平１０−４２１８５号公報
【特許文献２】
特開２００１−２１８１９４号公報
【００１４】
【発明が解決しようとする課題】
しかしながら、携帯電話端末を使ったライブ映像通信システムのカメラ操作は、携帯電話端末の入力デバイスの制約から自由度が少ないという問題がある。
【００１５】
さらに、携帯電話向け映像クリップサービスでは、ダウンロード可能な映像クリップサイズに上限が設けられているという問題がある。
【００１６】
さらに、携帯電話端末を利用したデータ通信では、通信セッションのオーバヘッドが大きいため、細かい通信セッションの多用は通信全体のコストを引き上げるという問題がある。
【００１７】
本発明は上記のような問題に鑑みなされたものであり、ネットワーク上からソース映像データを取得し、携帯電話端末等の携帯情報端末向けに適切に提供可能とすることを目的とする。
【００１８】
【課題を解決するための手段】
本発明の映像中継装置は、ネットワークに接続される映像中継装置であって、上記ネットワーク上のカメラサーバからソース映像データを取得するための映像受信手段と、上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを変換する映像変換手段と、上記変換後の映像データを送信する映像送信手段とを備える点に特徴を有する。
【００１９】
【発明の実施の形態】
以下、図面を参照して、本発明の実施の形態を説明する。
（第１の実施形態）
図１は、本実施形態によるライブ映像通信システムの全体構成を示す。同図において、１はカメラサーバ、３はビューワがインストールされたパーソナルコンピュータＰＣ、４は中継サーバ、５は映像変換サーバ、６はネットワーク９と携帯電話回線網１０とを仲介するゲートウェイ、７はビューワが搭載された携帯電話端末である。また、９はネットワーク、１０は携帯電話回線網であり、これらネットワーク９に接続された各機器１〜５と携帯電話回線網１０を利用する携帯電話端末７とはゲートウェイ６を介して通信可能となる。
【００２０】
ＰＣ３のビューワからネットワーク９を介してリクエストがカメラサーバ１へ送られ、これが受け入れられると、カメラサーバ１からＰＣ３のビューワへ映像データが配送され、カメラ映像を表示することが可能となる。また、ＰＣ３のビューワからカメラ制御コマンドがカメラサーバ１へ送られ、カメラ装置のズーム、パン、チルト等の操作が可能となる。ネットワーク９上の中継サーバ４は、ＰＣ３のビューワとカメラサーバ１との通信を中継することがある。
【００２１】
また、映像変換サーバ５は、カメラサーバ１が提供する映像データを携帯電話端末向けに変換した上で、携帯電話端末７向けに中継する。なお、携帯電話端末７上のビューワプログラムは、典型的には工場出荷時にインストールされるが、Ｊａｖａ（Ｒ）プログラムのように実行時（利用時）にダウンロードされて実行される形態であっても良い。
【００２２】
ネットワーク９は、企業や組織内で運用されるイントラネットである場合もあり、広く世界をつないでいるインターネットである場合もある。また、中継サーバ４や映像変換サーバ５は、典型的にはインターネットイクスチェンジ（ＩＸ）やデータセンター（ＩＤＣ ： Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）に配置され、通信負荷の軽減を図るよう設計される。
【００２３】
このようにしたライブ映像通信システムでは、ネットワーク９上に配置されたカメラサーバ１から送られるライブ映像を、映像変換サーバ５を介して携帯電話端末７向けに変換して中継することができる。映像の変換と中継を行う映像変換サーバ５が携帯電話端末７から映像クリップを要求される際に、（１）併せてカメラサーバ１に接続されたカメラ装置（撮像装置）の操作（パン、チルト、ズーム、逆光補正、プリセット指定等）を指示するカメラ制御シーケンス（以下、「ＰＴＺシーケンス」と称する）を受取る点、及び、（２）そのＰＴＺシーケンスに従って、カメラサーバ１を操作して取得した映像情報を携帯電話端末７向けに変換して、その変換後の映像情報を適切な映像クリップに分割した上で、携帯電話端末７向けに提供する点に特徴がある。
【００２４】
図２は映像変換サーバ５のハードウェア構成の一例を示すものであり、サーバ向けコンピュータ、より詳細にはプログラムやデータを格納する記憶装置、ネットワーク９と接続するためのネットワークＩ／Ｆ２０１、プログラムによる各種の処理を実行するＣＰＵ２０２等により構成される。記憶装置は、主記憶装置となるＲＡＭ２０３、フラッシュメモリやＨＤ装置等からなる二次記憶装置２０４、及びプログラムを媒体からロードするためのＦＤ装置２０５等により構成される。また、図示しないが、設定等を行うための入出力装置、具体的にはディスプレイを接続する表示装置、キーボードやマウス等のコントローラ等を備えることもある。
【００２５】
図３はカメラサーバ１のハードウェア構成の一例を示すものであり、実際に撮像を行うカメラ装置３０１と、コンピュータ、より詳細にはプログラムやデータを格納する記憶装置、映像データを取り込むための映像キャプチャボード３０２、カメラ装置３０１にコマンドを送るためのシリアルＩ／Ｆ３０３、ネットワーク９と接続するためのネットワークＩ／Ｆ３０４、プログラムによる各種の処理を実行するＣＰＵ３０５等により構成される。記憶装置は、主記憶装置となるＲＡＭ３０６、フラッシュメモリやＨＤ装置等からなる二次記憶装置３０７、及びプログラムを媒体からロードするためのＦＤ装置３０８等により構成される。また、図示しないが、設定等を行うための入出力装置、具体的にはディスプレイを接続する表示装置、キーボードやマウス等のコントローラ等を備えることもある。なお、図示しないが、カメラサーバ１は、カメラ装置３０１とコンピュータとが一体化されたサーバ内蔵型ネットワークカメラで構成されても良い。
【００２６】
図４はビューワを動作させる携帯電話端末７のハードウェア構成の一例を示すものであり、より詳細にはプログラムやデータを格納する記憶装置４０１、携帯電話回線網１０と接続するための無線通信Ｉ／Ｆ４０２、プログラムによる各種の処理を実行するＣＰＵ４０３、周辺装置、及び周辺装置のコントローラ４０４、４０５等により構成される。記憶装置は、主記憶装置となるＲＡＭ、フラッシュメモリ等からなる。また、周辺装置は、携帯電話端末上に配置されたボタン類４０６やスイッチ類４０７等の入力装置、ディスプレイ等の表示出力装置４０８、及びマイクロフォンやスピーカ等の音声入出力装置４０９を含む。
【００２７】
図５はプログラムの構成する部分を模式化した図であり、カメラサーバ１には、カメラ装置の制御をつかさどるカメラ制御サーバ５０１と、映像の配送をつかさどる映像サーバ５０２の２つのモジュールを含む。また、携帯電話端末７上で動作するビューワには、ＰＴＺシーケンスからなるカメラ制御コマンドの発行やカメラ状態通知に対応するカメラ制御部５０３、映像クリップの表示を担当する映像表示部５０４を含む。さらに、映像変換サーバ５には、ＰＴＺシーケンスからなるカメラ制御コマンド列を解釈し、カメラサーバ１にカメラ制御命令を発行するカメラ制御部５０５、カメラサーバ１から映像を取得し、携帯電話端末向けに変換し、さらに、それを携帯電話網向け映像クリップに編集するモジュール（映像取得部５０６、映像変換部５０７、映像送信部５０８）がそれぞれ含まれる。
【００２８】
図６は携帯電話端末７上のビューワによる処理動作の流れを示すフローチャートである。ステップＳ６０１では、まず映像変換サーバ５の識別子を入手する。これは、ユーザが直接キー操作により識別子を入力するものであっても良いし、メールやウェブページに含まれる識別子を選択するのであっても良い。また、この場合の識別子は、典型的には映像変換サーバ５を識別するＵＲＬである。
【００２９】
ステップＳ６０２では、映像変換サーバ５が接続すべきカメラサーバ１の識別子、及び、そのカメラサーバ１に指示するカメラ制御用のＰＴＺシーケンスを入手する。カメラサーバ識別子やＰＴＺシーケンスは、ユーザが直接キー操作によりカメラ制御コマンドを構成するよう入力するものであっても良いし、メールやウェブページに含まれるカメラサーバ識別子やＰＴＺシーケンスを選択するものであっても良い。また、ＰＴＺシーケンスは空であっても構わない。この場合、カメラ制御を伴わないカメラサーバ１の現状の映像クリップを意味する。
【００３０】
ステップＳ６０３では、ゲートウェイ６を経由して、上記ステップＳにて入手した映像変換サーバ５の識別子に基づき映像変換サーバ５の映像送信部５０８に接続する。
【００３１】
さらにステップＳ６０４では、映像変換サーバ５に映像クリップを要求する。この要求は、要求する映像クリップの作成方法の指定等を含み、典型的にはＨＴＴＰプロトコルに則り送信される。この際、上記ステップＳ６０２にてＰＴＺシーケンスを入手している場合には、そのＰＴＺシーケンスを映像変換サーバ５に送信する。この要求及びＰＴＺシーケンスの送信は、ＨＴＴＰ接続のＧＥＴメソッドでＵＲＬに組み込んでも良いし、ＨＴＴＰ接続のＰＯＳＴメソッドで送信されても良い。ここでは、ＰＯＳＴメソッドで送信される場合について説明する。例えば、以下の通りである。なお、実際には、ＵＲＬエンコードが適用されるが、以下では、説明の都合上ＵＲＬエンコードを適用していない部分もある。
ＰＯＳＴ ／ｇｅｔｖｉｄｅｏｃｌｉｐ／ ＨＴＴＰ／１．１
Ｈｏｓｔ： ２０２．２８．３０．２０８：８０８０
Ｕｓｅｒ−Ａｇｅｎｔ： ＭｏｂｉｌｅＰｈｏｎｅ／２．０ Ｃ２１０１Ｖ（ｃ１００）
Ｐｒａｇｍａ： ｎｏ−ｃａｃｈｅ
ｖｉｄｅｏｅｎｃｏｄｅｐａｒａｍ＝ＱＣＩＦ：ｆｐｓ１５．０：ｂｐｓ６４０００：ｉｎｔｒａｆｒａｍｅ５：ｍｅ８
ｃａｍｅｒａｓｅｒｖｅｒｓ＝ｗｅｂｖｉｅｗ：／／ｖｂ１０１＿４．ｘ−ｚｏｎｅ．ｃａｎｏｎ．ｃｏ．ｊｐ：３４５６０＋３４５６１＋３４５６２
ＰＴＺ＝ＨＺ１５＿３０Ｓ３＿４０Ｓ４＿４０Ｐ−１０＿２０
ｍｏｖｉｅｓｉｚｅｍａｘ＝２４０ｋｂｙｔｅｓ
ｎｏｔｉｆｙｔｏ＝ｍａｉｌｔｏ：ｒｉｙｏｕｓｈａ３＠ｍａｉｌｓｅｒｖｅｒ．ｕｓｅｒｓｉｔｅ．ｃｏ．ｊｐ
【００３２】
ただし、『ｖｉｄｅｏｅｎｃｏｄｅｐａｒａｍ＝』に続く部分は、映像変換サーバ５がカメラサーバ１から受取ったソース映像を携帯電話向けにエンコードする際のパラメータ情報を指示するものである。また、『ｃａｍｅｒａｓｅｒｖｅｒｓ＝』に続く部分は、映像変換サーバ５が接続するカメラサーバ１を指定している。また、『ＰＴＺ＝』に続く部分は、映像変換サーバ５がカメラサーバ１に関して実行すべきカメラ制御のコマンドを並べたＰＴＺシーケンスを指定している。また、『ｍｏｖｉｅｓｉｚｅｍａｘ＝』に続く部分は、携帯電話端末７或いは携帯電話網１０が規定する映像クリップの最大サイズを指定している。また、『ｎｏｔｉｆｙｔｏ＝』に続く部分は、映像クリップ作成時に通知すべき連絡先であり、典型的には携帯電話端末ユーザのメールアドレスを指定する。
【００３３】
この中で、ＰＴＺシーケンスの構成要素は、以下のような意味を持つ。ｎは数値データ（正負あり）である。
Ｐｎ パン（水平方向カメラ制御）指定
Ｔｎ チルト（垂直方向カメラ制御）指定
Ｚｎ ズーム指定
Ｂｎ 逆光補正（逆光補正のＯＮ／ＯＦＦ）
Ｈ ホームポジション指定
Ｓｎ プリセット位置指定（ｎ番目のプリセット位置）
Ｃｎ カメラサーバ接続切換え指定（ｎ番目のカメラサーバ）
Ｋｎ カメラサーバ内カメラ切換え指定（ｎ番目のカメラ）
ｎ 時間経過指定（０．１秒単位）
【００３４】
ステップＳ６０５では、映像変換サーバ５からのレスポンスを待つ。ステップＳ６０６では、映像変換サーバ５から受取ったレスポンスを解釈して携帯電話端末７の表示装置に表示する。例えば、図１５（ａ）に示す通りである。もし、映像変換サーバ５からのレスポンスが、何らかの理由からすぐに映像を生成できないことを示す内容であった場合には、ステップＳ６０７に進む。逆に、すぐに映像を生成できたことを示す内容であった場合には、ステップＳ６０８に進む。
【００３５】
ステップＳ６０７では、映像変換サーバ５からのメール通知を待受ける。メール通知は、例えばＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によるが、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）であってもよい。メール通知を受取った場合には、その内容を映像変換サーバ５からのレスポンスとして表示し、ステップＳ６０８に進む。例えば、図１５（ｂ）に示す通りである。
【００３６】
ステップＳ６０８では、レスポンスに含まれる映像クリップの一つを選択し、ダウンロードして再生表示する。例えば、図１５（ｃ）に示す通りである。ここでは、ダウンロードしているが、映像クリップの再生表示処理は、ダウンロードの終了を待たず、再生表示処理を開始しても良い。
【００３７】
図７はカメラサーバ１内のカメラ制御サーバ５０１による処理動作の流れを示すフローチャートである。カメラ制御サーバ５０１は、まず起動時にステップＳ７０１で特定のファイル（ＯＳによってはレジストリ等のシステムデータベース）からカメラ制御サーバの動作設定情報を読み出して、それに基づき動作を開始する。ここで、クライアントであるビューワプログラムや映像変換サーバ５からのリクエストを受け付けるポートを開き、続いてステップＳ７０２のリクエスト受付状態に入る。
【００３８】
リクエスト（接続リクエストもしくは操作コマンドリクエスト）が受け付けられたら、ステップＳ７０２を抜け、接続リクエストならばステップＳ７０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ７０２に戻る。可ならば、ステップＳ７０４で接続処理として、クライアントからのコマンドの受付処理を行うスレッドを生成し、クライアントの登録を行ってから、ステップＳ７０２に戻る。
【００３９】
生成されたスレッドでは、ステップＳ７０７で対応するクライアントからのコマンドの受付を行う。コマンドが届いたならば、それを受け付け、カメラ操作を行う主プログラムへ受け渡す。主プログラムはステップＳ７０２でこれを受け、操作コマンドに対してはステップＳ７０５へ進み、カメラ操作を行って、その結果（操作が成功か失敗かを示すコード等）をカメラ操作要求を受け付けたクライアント対応のスレッドへ伝える。このクライアント対応のスレッドはステップＳ７０８で結果をクライアントへ送り返す。
【００４０】
主プログラム部分では、ステップＳ７０６でカメラの操作により変化した状態（例えば、パン・チルト・ズームの値）をすべてのクライアント対応のスレッドに伝える。各クライアント対応のスレッドはステップＳ７０９でカメラ制御状態の変化をクライアントへ通達する。クライアント対応のスレッドはクライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ７１０で自身のスレッドを終了する。
【００４１】
なお、操作コマンドの扱いにおいては、具体的な操作コマンドの発行の前に、カメラ操作権の割り当て要求を必要とすることも可能である。これは複数の人間がカメラの操作を要求するような状況での混乱を無くす。この場合、まず、クライアントからはカメラ操作権獲得の要求コマンドが発行され、これに対して、カメラ制御サーバは現在のカメラ制御権の割り当て状態から、拒絶・割り当て・順番待ちを選びクライアントへ返答する。カメラ制御権は前もって定められた特定の時間か、クライアントが接続を終了するまでの短いほうの時間で剥奪され、次の順番待ちの人に割り当てられる。順番待ち人数はやはり前もって定められた人数（例えば５人）に制限され、それ以上のリクエストは拒絶される。クライアントはカメラ制御権が獲得されてから剥奪されるまでの間だけ、操作コマンドを発行する。カメラ制御サーバ５０１はカメラ制御権が付与されているクライアントからの操作コマンドのみを受け付ける。
【００４２】
図８はカメラサーバ１内の映像サーバ５０２による処理動作の流れを示すフローチャートである。映像サーバ５０２は、まず起動時にステップＳ８０１で特定のファイル（ＯＳによってはレジストリ等のシステムデータベース）から映像サーバの動作設定情報を読み出して、それに基づき動作を開始する。ここで、映像の獲得と符号化と蓄積を行うスレッドを生成し（最初このスレッドは休止状態）、クライアントであるビューワプログラムや映像変換サーバ５からのリクエストを受け付けるポートを開き、続いてステップＳ８０２のリクエスト受付状態に入る。
【００４３】
リクエスト（接続リクエストもしくはコマンドリクエスト）が受け付けられたら、ステップＳ８０２を抜け、接続リクエストならばステップＳ８０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ８０２に戻る。可ならば、ステップＳ８０４で接続処理として、クライアントごとのセッションを識別するためのセッション識別子を生成し、クライアントからのコマンドの受付処理を行うスレッドを生成し、クライアントの登録を行い、ステップＳ８０２に戻る。この際、リクエスト内容がライブ映像への接続であり、かつ、映像の獲得と符号化を行うスレッドが休止状態ならば、ステップＳ８０２に戻る前に、動作開始を指示する。
【００４４】
生成されたクライアント対応のスレッドでは、ステップＳ８０７で対応するクライアントからのコマンドの受付を行う。コマンドが届いたならば、それを受け付け、映像処理を行う主プログラムへ受け渡す。主プログラムはステップＳ８０２でこれを受け、操作コマンドに対してはステップＳ８０５へ進み、映像の獲得や符号化・送信等に関する設定の変更操作を行って、その結果（操作の成功か失敗を示すコード）をコマンド要求を受け付けたクライアント対応のスレッドへ伝える。クライアント対応のスレッドはステップＳ８０８で、この結果をクライアントへ送り返す。
【００４５】
主プログラム部分では、ステップＳ８０４からの映像の獲得と符号化を行うスレッドへの動作開始の指示により、ステップＳ８０６では前もって設定された時間間隔で映像データを映像キャプチャボード３０２を使って獲得し、これを圧縮データに変換する。さらにこの圧縮データを、ライブ映像に接続しているすべてのクライアント対応のスレッドに伝える。各クライアント対応のスレッドはステップＳ８０９でクライアントからの次映像フレーム送信要求の有無を判定し、要求があるならば、圧縮データをクライアントへ配送する。ライブ映像に接続しているクライアント対応のスレッドが、クライアントからの次映像フレーム送信要求（これはクライアントでの圧縮映像データの受取り完了に対して、送り返されるのが一般的である）を受取った場合には映像フレーム送信要求のフラグを設定する。また、クライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ８１０で自身のスレッドを終了する。
【００４６】
図９はＰＴＺシーケンスを作成する時の携帯電話端末７の状態を例示した図である。ＰＴＺシーケンスを作成する際には、携帯電話端末のキーに図示のように、パン（カメラの横振り）、チルト（カメラの縦振り）、ズーム（拡大倍率変更）、逆光補正等の機能が割り当てられる。なお、この画面は図６のフローチャートで説明したＰＴＺシーケンス入手操作を行うためのユーザインタフェースであり、ここで作成されたＰＴＺシーケンスはステップＳ６０２での処理に用いられる。
【００４７】
ここで、図１６を参照して、ＰＴＺシーケンスの作成の流れについて述べる。まず、ステップＳ９０１で、事前に取得したカメラサーバの識別子を使って、カメラサーバのカメラ制御によって可視範囲に入る画像を合成したパノラマ画像、事前にカメラサーバに設定されているカメラ制御情報（プリセット情報）、及び、現在のカメラ状態パラメータ（パン角、チルト角、ズーム値等）を、カメラサーバ１から取得する。
【００４８】
次に、ステップＳ９０２で、ＰＴＺシーケンスの初期値として空データを設定し、また、表示用カメラ状態パラメータ及び設定用カメラ状態パラメータとして取得した現在のカメラ状態パラメータを設定する。
【００４９】
次に、ステップＳ９０３で、表示用カメラ状態パラメータに従って可視領域を計算し、可視領域に相当する画像をパノラマ画像から切り出して携帯電話端末７の画面に表示する。
【００５０】
次に、ステップＳ９０４で、ユーザからのキー入力を受取る。キー入力が、カーソルキーによる可視領域の変更、或いは、プリセット位置への移動の指示であった場合には、ステップＳ９０５で、表示用カメラ状態パラメータを変更し、ステップＳ９０３に進む。キー入力が、ＰＴＺシーケンスを追加／修正等の編集指示であった場合には、ステップＳ９０６で、ＰＴＺシーケンスの値を変更し、ステップＳ９０３に進む。ＰＴＺシーケンス追加の場合には、その時点の表示用カメラ状態パラメータと設定用カメラ状態パラメータとの差分から制御すべきカメラ制御値を計算し、そのカメラ制御値をＰＴＺシーケンスに追加する。そして、表示用カメラ状態パラメータを設定用カメラ状態パラメータの新しい値とする。キー入力が、ＰＴＺシーケンス作成の終了を指示する場合には、ステップＳ９０７に進んだ上で、決定やキャンセルを判定し、決定である場合には、ＰＴＺシーケンスをステップＳ６０２へ送り、処理を終了する。
【００５１】
図１０はカメラサーバ１の用いる設定値、すなわち、カメラ制御サーバ５０１や映像サーバ５０２が読み出す動作設定情報を特定のファイル（ＯＳによってはレジストリ等のシステムデータベース）に設定するカメラサーバ設定プログラムの表示画面の一例を示す図であり、カメラ制御サーバ５０１、映像サーバ５０２、動画品質、接続制限事項等に関する各種のパラメータ（後述）を設定できるようになっている。ＯＫボタンを押すと設定した値が特定のファイル或いはレジストリに書き込まれ、キャンセルすると書き込まれずに終了する。
【００５２】
図１１はカメラサーバ１の設定プログラムによる処理動作の流れを示すフローチャートである。設定プログラムは、まず起動時にステップＳ１１０１でカメラ制御サーバ及び映像サーバに関する設定情報を格納した特定のファイル（ＯＳによってはレジストリ等のシステムデータベース）から設定情報を読み出し、内部データに設定する。以降、ユーザの操作入力を受取り、実施するループを繰り返す。
【００５３】
ステップＳ１１０２でユーザの操作入力を待ち、入力があればそれを受取り、続いてステップＳ１１０３で入力された値が適正範囲内であるか否かを判定し、適正でなければステップＳ１１０４でエラーメッセージを出力して、値を戻して、ユーザの入力待ちステップＳ１１０２へ戻る。適正範囲内であるならば、内部データを更新して、ステップＳ１１０２に戻る。ここで設定できる値としては、カメラ制御の通信用のＴＣＰポート番号、カメラと接続するＣＯＭ（シリアル）ポート、シャッタースピード、カメラ制御関連のログ情報の有無とログファイル名、映像関連の通信用のＴＣＰポート番号、ログ情報の有無とログファイル名、映像をキャプチャする時間間隔を規定するフレームレートと圧縮の品質を決めるＱ−Ｆａｃｔｏｒ、圧縮の元データの画面サイズ、１つのクライアントビューワの最大接続時間、カメラ制御に関する制御権の順番待ち人数、１つのビューワの制御権保持占有時間、映像とカメラ制御に関する接続可能な最大クライアント数等の項目がある。
【００５４】
ユーザからの入力がＯＫボタンの場合には、ステップＳ１１０２からステップＳ１１０５に進み、更新された内部データをカメラ制御サーバ５０１及び映像サーバ５０２に関する設定情報を格納する特定のファイル等へ書き出し、ステップＳ１１０６で変更を反映するためにカメラサーバ１を再起動するかを尋ねるパネルを出す。再起動する場合にはステップＳ１１０７でカメラ制御サーバ５０１や映像サーバ５０２等を再起動して、ステップＳ１１０８で設定プログラムを終了する。再起動しない場合にはステップＳ１１０６から直接ステップＳ１１０８に進み、終了する。
【００５５】
また、ステップＳ１１０２でのユーザの入力がキャンセルボタンである場合には、ステップＳ１１０２から直接ステップＳ１１０８に進み、終了する。
【００５６】
図１２は映像変換サーバ５における映像データの大まかな流れを模式化した図である。カメラサーバ１から送信されたソース映像データ（Ｍｏｔｉｏｎ ＪＰＥＧ、ＱＶＧＡサイズ３２０ｘ２４０）は、映像変換サーバ５のカメラサーバ向け通信スタックを経由して受信され、ＪＰＥＧデコーダに渡され、続いて、携帯電話端末向けに設定されたＭＰＥＧ−４エンコーダに渡され、携帯電話向け映像データ（ＭＰＥＧ−４ ｓｉｍｐｌｅｐｒｏｆｉｌｅ、ＱＣＩＦサイズ１７６ｘ１４４、６４Ｋｂｐｓ）に加工された上で、映像クリップとして、携帯電話網１０向けの通信スタックを経由して、携帯電話端末７のビューワへと送信される。
【００５７】
図１３は映像変換サーバ５での処理動作の流れを示すフローチャートである。映像変換サーバ５は、まず起動時にステップＳ１３０１で特定のファイル（ＯＳによってはレジストリ等のシステムデータベース）から映像変換サーバの動作設定情報を読み出して、それに基づき動作を開始する。ここで、クライアントである携帯電話ビューワプログラムからのリクエストを受け付ける通信ポートを開き、続いてステップＳ１３０２のリクエスト受付状態に入る。
【００５８】
リクエスト（ＨＴＴＰリクエストのメッセージ等）が受け付けられたら、ステップＳ１３０２を抜け、ステップＳ１３０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ１３０２に戻る。可ならば、ステップＳ１３０４で接続処理として、クライアントとの情報の受渡しを行うクライアント対応スレッドを生成し、クライアントの登録を行い、ステップＳ１３０２に戻る。
【００５９】
生成されたクライアント対応スレッドでは、ステップＳ１３１１で対応するクライアントからのリクエストを読み込み、内容を解析する。リクエストは、典型的にはＨＴＴＰリクエストとして、映像変換サーバ５に渡される。なお、ＨＴＴＰリクエストには、ＰＯＳＴメソッドが使われる場合もあり、ＧＥＴメソッドが利用される場合もある。
【００６０】
次に、ステップＳ１３１２で、リクエスト内容からエンコードパラメータ情報（映像変換パラメータ）、カメラサーバ１への接続情報（ソース映像情報）、ＰＴＺシーケンス、映像クリップの最大サイズ（映像クリップ上限値）、及び、通知先情報（通知先アドレス）を取り出す。これらは、それぞれ『ｖｉｄｅｏｅｎｃｏｄｅｐａｒａｍ＝』『ｃａｍｅｒａｓｅｒｖｅｒｓ＝』『ＰＴＺ＝』『ｍｏｖｉｅｓｉｚｅｍａｘ＝』『ｎｏｔｉｆｙｔｏ＝』の値として指示されている。
【００６１】
映像変換パラメータは、変換用コーデックの選択やそのコーデックへのパラメータ、及び、コーデック入力用／出力用のデータ形式等を記述している。ソース映像情報とは、例えばライブ映像を提供するカメラサーバ１のネットワークアドレスとポート番号等の通信属性情報である。通知先アドレスとは、典型的にはユーザの携帯電話端末７を指定したメールアドレスである。
【００６２】
次に、ステップＳ１３１３で、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、『すぐに映像を生成できないので、しばらくしてメール連絡します』との旨を示す情報を返す。
【００６３】
次に、ステップＳ１３１４で、ソース映像情報に従って、映像取得部５０６を初期化する。具体的には、ソース映像を提供するカメラサーバ１に接続し、ソース映像取得を開始する。
【００６４】
そして、ステップＳ１３１５に進み、映像変換パラメータに従って映像変換部５０７を初期化する。この映像変換部５０７は、ＭＰＥＧ−４エンコーダ等から構成される。そして、ステップＳ１３１６に進み、映像送信部５０８を初期化する。この際、映像送信部５０８に映像クリップ上限値、及び、通知先アドレスを指示する。さらに、ステップＳ１３１７に進み、映像取得部５０６から映像変換部５０７へ、映像変換部５０７から映像送信部５０８へとそれぞれの処理データが受渡しされるように相互の関連付けを行った上で、カメラ制御部５０５がＰＴＺシーケンスに従ってカメラサーバ１のカメラ制御を行う。
【００６５】
そして、ステップＳ１３１８に進み、映像取得部５０６、映像変換部５０７、映像送信部５０８の後処理を行う。そして、ステップＳ１３１９に進み、クライアント対応スレッドを終了する。
【００６６】
次に、映像変換サーバ５の中で機能している映像取得部５０６、映像変換部５０７、映像送信部５０８、カメラ制御部５０５について順次説明する。映像取得部５０５は、まず初期化時に受取ったソース映像情報に従ってライブ映像を提供するカメラサーバ１に接続する。そして、カメラサーバ１から映像データを取得し、取得時のタイムスタンプを付与して映像データを映像変換部５０７へ渡す。本実施形態におけるカメラサーバ１は、映像データをＭｏｔｉｏｎ ＪＰＥＧ形式で提供するので、タイムスタンプが付与されるのは個々のＪＰＥＧデータである。
【００６７】
映像変換部５０７では、まず初期化時に受取ったコーデックへのパラメータ、及び、コーデック入力用／出力用のデータ形式等をＭＰＥＧ−４エンコーダに設定する。そして、映像取得部５０６から受取ったソース映像データを、コーデック入力用のデータ形式及び画像サイズに整えてからＭＰＥＧ−４エンコーダに入力し、その処理結果を映像送信部５０８へ渡す。本実施形態における映像変換部５０７では、ＪＰＥＧ形式のソース映像データを、予めＱＣＩＦサイズかつＹＵＶ４１１形式に整えてからＭＰＥＧ−４コーデックへ入力し、生成されたＭＰＥＧ−４データ（Ｉ−ｆｒａｍｅ又はＰ−ｆｒａｍｅ）を映像送信部５０８へ受け渡す。この際、映像取得部５０６で付与されたタイムスタンプも併せてＭＰＥＧ−４コーデックへ入力される。
【００６８】
映像送信部５０８では、まず初期化時に受取った映像クリップ上限値に従ってメモリ領域を確保する。そして、映像変換部５０７が生成した携帯電話向け映像データを受取り、確保したメモリ領域に保持する。映像送信部５０８では、カメラ制御部５０５から得られるＰＴＺシーケンスの指示内容等から現在得られている映像データの評価値（優先度）を計算し、メモリ領域の利用率をも加味して、映像クリップの分割点を決定する。そして、分割点と判断した場合には、メモリ領域に保持している映像クリップをファイルとして保存し、メモリ領域を再利用する。これによって、映像クリップが複数のファイルに分割保存される。そして、カメラ制御部５０５からＰＴＺシーケンスの終了を通知された時点で、メモリ領域に保持している映像クリップの残りを同様にファイルとして保存した上で、それまでに保存している複数の映像クリップへのリンク情報を埋め込んだ携帯電話端末７への通知情報を作成し、初期化時に受取った通知先アドレスへ通知する。これによって、通知情報を受取った携帯電話端末７から各映像クリップへのダウンロード要求を可能とする。なお、映像送信部５０８はＨＴＴＰサーバ機能を備えており、携帯電話端末７からのＨＴＴＰ利用の映像クリップのダウンロード要求に対応する。
【００６９】
また、映像送信部５０８における優先度の計算は、映像変換部５０７から映像データを取得した時点で行われ、例えば次のように計算される。その結果、時間経過に対して、図１４に示すように変化する優先度が得られる。
（０） 映像変換部５０７から得られた一つ前の映像データの優先度をｐｒｉとする。なお、ｐｒｉの初期値は０とする。
（１） もしもカメラ制御部５０５からプリセット指定（ホームポジション指定を含む）或いはカメラサーバ切換えを意味する指示内容が通知されているならば、ｐｒｉに３を加える。
（２） もしもカメラ制御部５０５から（カメラサーバ内の）カメラ切換えを意味する指示内容が通知されているならば、ｐｒｉに２を加える。
（３） もしもカメラ制御部５０５からパン／チルト／ズームを意味する指示内容が通知されているならば、ｐｒｉに１を加える。
（４） もしもカメラ制御部５０５からの通知がないならば、ｐｒｉに０．９を掛ける。
（５） ただし、計算の結果が３を越える場合には、優先度を３とする。
【００７０】
次に、カメラ制御部５０５では、ＰＴＺシーケンスを解釈して、カメラサーバ１に送るべきカメラ制御コマンドを作成し、ＰＴＺシーケンスに指示されたタイミングで作成したカメラ制御コマンドをカメラサーバ１に送信することで、カメラサーバ１のカメラ制御を行う。
【００７１】
また、ＰＴＺシーケンスの解釈に際して、プリセット位置への移動や変動量の多いパン／チルト／ズーム（例えば、制御可能量の２０％以上の変動）等を検出した場合には、分割可能ポイントを映像送信部５０８に伝える。そして、ＰＴＺシーケンスを解釈し終えた時点で、ＰＴＺシーケンスの終了を映像送信部５０８に通知する。
【００７２】
以上述べたように、携帯電話端末７上に実装された映像クリップビューワを使うユーザは、カメラ制御のためのＰＴＺシーケンスを指定した上で、映像変換サーバ５に映像クリップを要求することができる。そして、映像変換サーバ５の機能により、ネットワーク９上に配置された複数のカメラサーバ１について、ＰＴＺシーケンスによる制御の結果得られるソース映像内容を携帯電話端末７で処理可能な映像クリップとして受取ることができる。これにより、ネットワーク９上に配置されたカメラサーバ１から送られるライブ映像を、携帯電話端末７向けに変換して中継することができる。特に、本実施形態の映像変換サーバ５では、カメラサーバ１を制御するＰＴＺシーケンスを指定して映像クリップを生成する点と、携帯電話端末７向けに適切な映像クリップに分割して提供する点とに特徴がある。
【００７３】
なお、本実施形態では、携帯電話網１０とネットワーク９とを結ぶゲートウェイ６とは独立にネットワーク１０上に映像変換サーバ５が実装される例について説明したが、映像変換サーバ５がゲートウェイ６の一部として実装されても良い。また、映像変換サーバ５とゲートウェイ６とが、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等も含めて専用線で接続されるような接続形態も可能である。
【００７４】
本実施形態では、すべての携帯電話端末ユーザに同一の映像サービスを提供する例について説明しているが、ユーザの契約状況や課金の有無、或いは、携帯電話端末の性能等に応じて、異なった映像サービス適用するように映像変換サーバを設計しても良い。
【００７５】
本実施形態では、映像変換サーバ５が接続するカメラサーバ１を一つ指定しているが、複数のカメラサーバ１の指定も含めてＰＴＺシーケンスを構成しても良い。例えば、次のようなＰＴＺシーケンスが考えられる。ただし、ＰＴＺシーケンスに含まれる『Ｃｎ』は、ｎ番目のカメラサーバへの接続切換えを指定している。
ｃａｍｅｒａｓｅｒｖｅｒｓ＝（ｗｅｂｖｉｅｗ：／／ｃａｍ１．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）（ｗｅｂｖｉｅｗ：／／ｃａｍ２．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）（ｗｅｂｖｉｅｗ：／／ｃａｍ３．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）
ＰＴＺ＝Ｃ１ＨＺ１５＿３０Ｃ２Ｓ３＿４０Ｃ３Ｓ４＿４０Ｐ−１０＿２０
【００７６】
さらに、例えば次の通り、カメラサーバ１の指定をもＰＴＺシーケンスに織り込む実装も可能である。ただし、ＰＴＺシーケンスに含まれる『Ｃ（ｘ）』は、ｘで記述されるカメラサーバ１への接続切換えを指定している。
ｃａｍｅｒａｓｅｒｖｅｒｓ＝
ＰＴＺ＝Ｃ（ｗｅｂｖｉｅｗ：／／ｃａｍ１．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）ＨＺ１５＿３０Ｃ（ｗｅｂｖｉｅｗ：／／ｃａｍ２．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）Ｓ３＿４０Ｃ（ｗｅｂｖｉｅｗ：／／ｃａｍ３．ｕｎｉｖ．ａｃ．ｊｐ：３４５６０＋３４５６１＋３４５６２）Ｓ４＿４０Ｐ−１０＿２０
【００７７】
本実施形態では、映像変換サーバ５がステップＳ１３１３でＨＴＴＰレスポンスとして『すぐに映像を生成できないので、しばらくしてメール連絡します』旨を示すレスポンスに返しているが、ＰＴＺシーケンスを指定されなかった場合（空だった場合）には、定期的に作成しておいた映像クリップを添付してＨＴＴＰレスポンスを返すことも考えられる。
【００７８】
本実施形態では、カメラ制御部から通知されるＰＴＺシーケンスの指示内容に基づいて映像クリップの分割点を判断しているが、これは、カメラサーバ１から通知されるカメラ状態パラメータに基づいて分割を判断する方式であっても良い。また、カメラ制御権が取得できない場合や、カメラ制御中に映像データにブラー（パン／チルト時の画像の乱れ）が発生した場合には、一時的に優先度を下げるようにしても良い。
【００７９】
また、カメラ制御権が一定時間以上取得できない場合には、映像クリップの作成を断念し、その旨、携帯電話端末７に通知することも考えられる。逆に、本実施形態の映像変換サーバ５からカメラサーバ１への接続については、特権接続を適用して、常に要求した時点でカメラ制御権を取得するよう実装することも考えられる。
【００８０】
（第２の実施形態）
第２の実施形態では、上記第１の実施形態と同様、インターネット上に配置されたカメラサーバ１から送られるライブ映像を、携帯電話端末７向けに変換して中継する例について説明する。特に、第２の実施形態では、映像変換サーバ５が、映像クリップの分割を携帯電話端末７からの映像クリップのダウンロード要求がある時点まで遅らせる点に特徴がある。なお、システム全体の構成、各装置の構成等については上記第１の実施形態で説明したものと同様であり、図１３で示した映像変換サーバ５での処理動作の一部が相違する。以下では上記第１の実施形態との相違点を中心について説明する。
【００８１】
第２の実施形態の映像送信部５０８では、まず映像変換部５０７で生成される映像データを保存する映像ファイルｖｆｉｌｅ及び映像ファイルに関するインデックスファイルｉｆｉｌｅを用意する。そして、映像変換部５０７が生成した携帯電話向け映像データを受取り、順次映像ファイルｖｆｉｌｅに追加保存してゆく。
【００８２】
同時に、映像送信部５０８では、カメラ制御部５０５からの得られるＰＴＺシーケンスの指示内容等から現在得られている映像データの重要度（優先度）を計算し、映像ファイルの書き込み位置と優先度とからなるインデックス情報を順次インデックスファイルｉｆｉｌｅに追加保存してゆく。つまり、本実施形態の映像送信部５０８では、この時点での映像クリップの分割を行わない。
【００８３】
そして、カメラ制御部５０５からＰＴＺシーケンスの終了を通知された時点で、インデックスファイルｉｆｉｌｅをスキャンして、優先度の変化状況及び映像クリップ上限値とを加味して、映像クリップの分割点を決定する。そして、その分割に応じた複数の映像クリップへのリンク情報を埋め込んだ携帯電話端末への通知情報を作成し、初期化時に受取った通知先アドレスへ通知する。
【００８４】
さらに、映像送信部５０８に備えるＨＴＴＰサーバ機能では、上述の映像クリップへのダウンロード要求を、通常のファイルダウンロードとは区別し、携帯電話端末７からの映像クリップのダウンロード要求を受取った時点で、上記分割点に相当する映像クリップを映像ファイルｖｆｉｌｅから切り出し、携帯電話端末７へ送信する。
【００８５】
以上述べたように、インターネット上に配置されたカメラサーバ１から送られるライブ映像を、携帯電話端末７向けに変換して中継することができる。特に、本実施形態の映像変換サーバ５では、映像クリップの分割を、携帯電話端末７からの映像クリップのダウンロード要求がある時点まで遅らせる点に特徴がある。
【００８６】
本実施形態では、サイズの上限値を制約された映像クリップとして携帯電話端末７にカメラサーバ１の映像を提供する実装について説明しているが、必要なユーザに対しては、作成した映像ファイルｖｆｉｌｅの全体をストリーミング配送する実装も考えられる。
【００８７】
（その他の実施形態）
【００８８】
なお、本発明の目的は、上記実施形態のいずれかの装置又はシステムの機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、装置又はシステムに供給し、その装置又はシステムのコンピュータ（ＣＰＵ又はＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても、達成されることは言うまでもない。
【００８９】
この場合、記憶媒体から読み出されたプログラムコード自体が上記実施形態で説明した機能を実現することとなり、そのプログラムコードを記憶した記憶媒体及び当該プログラムコードは本発明を構成することとなる。
【００９０】
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フロッピー（Ｒ）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
【００９１】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施形態で説明した機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等を利用して実際の処理の一部又は全部が行われ、その処理によって上記実施形態で説明した機能が実現される場合も本発明の実施の態様に含まれることは言うまでもない。
【００９２】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上記実施形態で説明した機能が実現される場合も本発明の実施の態様に含まれることは言うまでもない。
【００９３】
このようなプログラム又は当該プログラムを格納した記憶媒体に本発明が適用される場合、当該プログラムは、例えば、上述したフローチャートに対応したプログラムコードから構成される。
【００９４】
なお、上記実施形態において示した各部の形状及び構造は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００９５】
以下、本発明の実施態様の例を列挙する。
（実施態様１） ネットワークに接続される映像中継装置であって、
上記ネットワーク上のカメラサーバからソース映像データを取得するための映像受信手段と、
上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを変換する映像変換手段と、
上記変換後の映像データを送信する映像送信手段とを備えることを特徴とする映像中継装置。
【００９６】
（実施態様２） 上記映像変換手段は、上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを携帯情報端末向けに変換し、上記映像送信手段は、携帯情報端末を通信相手として上記変換後の映像データを送信することを特徴とする実施態様１に記載の映像中継装置。
【００９７】
（実施態様３） 上記映像送信手段は、複数の映像データを取りまとめた映像ファイルを単位として送信する映像ファイル送信手段により構成されることを特徴とする実施態様１又は２に記載の映像中継装置。
【００９８】
（実施態様４） 上記映像ファイル送信手段は、標準化されているＨＴＴＰを使って映像ファイルを送信することを特徴とする実施態様３に記載の映像中継装置。
【００９９】
（実施態様５） クライアントからの要求に応じて映像ファイルを分割する映像ファイル分割手段を更に備え、
上記映像ファイル送信手段は、映像ファイルを分割した上で、分割後の映像ファイルの個別のダウンロード要求に応えることを特徴とする実施態様３又は４に記載の映像中継装置。
【０１００】
（実施態様６） 上記映像変換手段が生成する個々の映像データごとに優先度を計算する優先度評価手段を更に備え、
上記映像ファイル分割手段は、上記優先度評価手段の算出する優先度に基づいて映像ファイルを分割することを特徴とする実施態様５に記載の映像中継装置。
【０１０１】
（実施態様７） クライアントからの映像要求にはカメラ制御情報及びカメラサーバ切換え情報が含まれており、上記優先度評価手段は、上記カメラ制御情報及びカメラサーバ切換え情報に基づいて優先度を計算することを特徴とする実施態様６に記載の映像中継装置。
【０１０２】
（実施態様８） 上記優先度評価手段は、上記カメラサーバに対して要求したカメラ制御権が取得できなかった場合には、優先度を低く評価することを特徴とする実施態様６に記載の映像中継装置。
【０１０３】
（実施態様９） クライアントからの映像要求にはクライアントが受取り可能な映像ファイルの上限サイズが含まれており、上記優先度評価手段は、それまでに生成された映像ファイルのサイズとその上限サイズに基づいて優先度を計算することを特徴とする実施態様６に記載の映像中継装置。
【０１０４】
（実施態様１０） 上記カメラサーバの映像送出パラメータ及び撮像パラメータを制御するカメラ制御手段を更に備え、
上記映像受信手段は、上記ネットワーク上のカメラ制御可能なカメラサーバの映像をソース映像として受信することを特徴とする実施態様１〜９のいずれか１項に記載の映像中継装置。
【０１０５】
（実施態様１１） クライアントからの映像要求には、カメラ制御情報及びカメラサーバ切換え情報が含まれていることを特徴とする実施態様１〜１０のいずれか１項に記載の映像中継装置。
【０１０６】
（実施態様１２） 上記映像送信手段は、分割前の映像ファイルをストリーミングすることを特徴とする実施態様１〜１１のいずれか１項に記載の映像中継装置。
【０１０７】
（実施態様１３） 上記映像送信手段は、映像データを送信可能になった時点でクライアントにメール通知することを特徴とする実施態様１〜１２のいずれか１項に記載の映像中継装置。
【０１０８】
（実施態様１４） 携帯電話回線網とインターネットとを仲介するゲートウェイに実装されることを特徴とする実施態様１に記載の映像中継装置。
【０１０９】
（実施態様１５） 映像中継装置が接続されるネットワークと携帯情報端末が接続される携帯情報端末通信網とが仲介されている映像通信システムであって、上記映像中継装置は、上記ネットワーク上のカメラサーバからソース映像データを取得するための映像受信手段と、上記取得した映像データを上記携帯情報端末向けに変換する映像変換手段と、上記変換後の映像データを上記携帯情報端末に送信する映像送信手段とを備えることを特徴とする映像通信システム。
【０１１０】
（実施態様１６） ネットワーク上のカメラサーバからソース映像データを取得するための映像受信手順と、
上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを変換する映像変換手順と、
上記変換後の映像データを送信する映像送信手順とを有することを特徴とする映像中継方法。
【０１１１】
（実施態様１７） ネットワークに接続される映像中継装置を制御するためのコンピュータプログラムであって、
上記ネットワーク上のカメラサーバからソース映像データを取得するための映像受信処理と、
上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを変換する映像変換処理と、
上記変換後の映像データを送信する映像送信とを実行させることを特徴とするコンピュータ読み取り可能な記憶媒体。
【０１１２】
（実施態様１８） 実施態様１７に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【０１１３】
【発明の効果】
以上述べたように本発明によれば、ネットワーク上のカメラサーバからソース映像データを取得し、その取得した映像データを携帯情報端末向けに変換するようにしたので、ネットワーク上から取得した映像データを携帯電話端末等の携帯情報端末向けに適切に提供することができる。
【図面の簡単な説明】
【図１】本実施形態によるライブ映像通信システムの全体構成を示す図である。
【図２】映像変換サーバ５のハードウェア構成の一例を示す図である。
【図３】カメラサーバ１のハードウェア構成の一例を示す図である。
【図４】携帯電話端末７のハードウェア構成の一例を示す図である。
【図５】カメラサーバ１、映像変換サーバ５、携帯電話端末７上のプログラムの構成する部分を模式化した図である。
【図６】携帯電話端末７上のビューワによる処理動作の流れを示すフローチャートである。
【図７】カメラサーバ１内のカメラ制御サーバ５０１による処理動作の流れを示すフローチャートである。
【図８】カメラサーバ１内の映像サーバ５０２による処理動作の流れを示すフローチャートである。
【図９】ＰＴＺシーケンスを作成する時の携帯電話端末７の状態を例示した図である。
【図１０】カメラサーバ設定プログラムの表示画面の一例を示す図である。
【図１１】カメラサーバ１の設定プログラムによる処理動作の流れを示すフローチャートである。
【図１２】映像変換サーバ５における映像データの大まかな流れを模式化した図である。
【図１３】映像変換サーバ５での処理動作の流れを示すフローチャートである。
【図１４】映像変換サーバ５における映像データの優先度の推移について説明するための図である。
【図１５】携帯電話端末７での画面表示例を示す図である。
【図１６】ＰＴＺシーケンスの作成の流れを示すフローチャートである。
【符号の説明】
１ カメラサーバ
３ パーソナルコンピュータ
４ 中継サーバ
５ 映像変換サーバ
６ ゲートウェイ
７ 携帯電話端末
９ ネットワーク
１０ 携帯電話回線網
５０５ カメラ制御部
５０６ 映像取得部
５０７ 映像変換部
５０８ 映像送信部

Claims (1)

1. ネットワークに接続される映像中継装置であって、
   上記ネットワーク上のカメラサーバからソース映像データを取得するための映像受信手段と、
   上記取得した映像データの形式、画像サイズ、コーデックの少なくともいずれかを変換する映像変換手段と、
   上記変換後の映像データを送信する映像送信手段とを備えることを特徴とする映像中継装置。

Images