JP4181789B2 - 映像変換装置およびその方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して映像データを配信する映像配信技術に関するものである。
【０００２】
【従来の技術】
撮影したライブ映像を，インターネットなどの通信インフラストラクチャを使って配信するとともに，撮影のためのカメラ設定やカメラ操作などを指示するシステムが本出願人によって提案されている。
【０００３】
また、従来の携帯電話サービスよりも高い電波利用効率と通信帯域を備えることにより、電話通話しながらインターネットアクセスなどのデータ通信が可能なサービスが普及しつつある。このようなサービスでは、マルチアクセスと呼ばれる接続形態を用意しており、これを利用することで、ウェブブラウジングなどのデータ通信を行いながら、電話通話を可能にしている。
【０００４】
さらに、携帯端末自体の処理能力も強化されており、これまでＰＣ（パーソナルコンピュータ）などで行っていた作業を携帯電話端末で処理可能になっている。例えば、メイルやウェブブラウジングおよび映像送受信などの機能を実装している携帯電話端末が提供されている。また、３Ｇ−ＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、第三世代携帯電話向けの映像伝送規格として、３Ｇ−３２４Ｍ（回線交換用）などを策定して、携帯電話向け映像伝送技術の標準化を図っている。
【０００５】
【発明が解決しようとする課題】
しかしながら、インターネット上でサービスされている映像情報を携帯電話端末へサービスする場合、携帯電話サービスの狭い通信帯域や画面サイズなどの特性を把握して映像情報の変換ならびに送信制御を行わなければ、適切な映像サービスを携帯電話端末に提供することはできないという問題がある。
【０００６】
本発明は、このような問題に鑑みなされたものであり、インターネット上に流通している映像情報を携帯電話向けに適切に提供するものである。
【０００７】
【課題を解決するための手段】
上述した目的を達成するために、本願発明によれば、撮像装置から得られた映像データをリアルタイムに配信する映像変換装置において、前記撮像装置と接続されたサーバからフレーム内圧縮を用いて圧縮された第１の映像データ方式の映像データを受信する受信手段と、前記受信手段によって受信された前記第１の映像データ方式の映像データをフレーム内圧縮およびフレーム間圧縮を用いて圧縮された第２の映像データ方式の映像データに変換し、変換された映像データを端末に配信するための制御手段とを有し、前記制御手段は、前記受信手段によって受信される映像データが所定のフレームレート以下の場合、前記サーバに対して排他的に前記第１の映像データ方式の映像データを配信することを要求することを特徴とする。
【０００８】
また、撮像装置から得られた映像データをリアルタイムに配信する映像変換方法において、前記撮像装置と接続されたサーバからフレーム内圧縮を用いて圧縮された第１の映像データ方式の映像データを受信する受信ステップと、受信された前記第１の映像データ方式の映像データをフレーム内圧縮およびフレーム間圧縮を用いて圧縮された第２の映像データ方式の映像データに変換する変換ステップと、変換された映像データを前記第２のネットワーク上の端末に配信する配信ステップと、前記受信ステップにおいて受信される映像データが所定のフレームレート以下の場合、前記サーバに対して排他的に前記第１の映像データ方式の映像データを配信することを要求する要求ステップとを有することを特徴とする。
【０００９】
【発明の実施の形態】
以下、添付の図面に沿って本発明の実施の形態を説明する。ここで、予め以下に本実施の形態の説明において用いる用語を予め説明する。
【００１０】
・ＭＰＥＧ−４コーデック
フレーム内で圧縮を行うとともに、動きベクトルを探索することによって画像内での物体の動く方向を予測し、そのベクトルだけを保存するなどして、データを圧縮する方式。言い換えると、フレーム自身の画像をオブジェクト（例えば、映像を構成する背景や人物、建物）に映像を分解しそれぞれのオブジェクトに応じてフレーム間で差分した信号を用いて圧縮する方式である。
【００１１】
加えて、移動体通信網に接続する携帯情報端末から広帯域インターネットに接続するＰＣまでの映像送受信端末の広がりを受けて、数十ｋｐｂｓから数十Ｍｂｐｓの広いビットレートをカバーする高圧縮符号化効率、および、無線やインターネットなどの伝送路誤りに対する強い耐性などを備えた動画像圧縮符号化方式として、ＩＳＯで１９９９年にＭＰＥＧ−４が制定された。このＭＰＥＧ−４を用いた映像配信サービスは、個人情報端末ＰＤＡや携帯電話端末向けに提供されている。例えば、携帯電話端末間でＭＰＥＧ−４を用いて相互に映像を送受信するサービスを提供している。
【００１２】
・ＲＴＰ／ＲＴＣＰ
ネットワーク上で、リアルタイムに情報（特に、映像や音声などを想定している）を受渡しするアプリケーションのための伝送用プロトコルとしてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が、ＩＥＴＦによってＲＦＣ１８８９¨ＲＴＰ：Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ¨として勧告されている。ＲＴＰでは、情報を受渡しする端末のタイムスタンプを使って、通信路の状態を観察し、適切な状態で情報を受渡しできるよう調整する仕組みが盛り込まれたプロトコルである。
【００１３】
・ＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ＩＥＴＦによって ＲＦＣ２３２６¨Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）¨として勧告されている。リアルタイムに情報を伝送するに際して、ＲＴＰがサーバからクライアントへ一方向にブロードキャスト（あるいはマルチキャスト）することを想定しているのに対して、ＲＴＳＰでは、サーバとクライアント間でユニキャストかつ双方向の伝送を想定している。つまり、ＲＴＳＰでは、クライアントがサーバと交信し、映像コンテンツなどを巻き戻したり、別のチャプタへスキップしたりすることなどが可能となっている。
【００１４】
さらに、ＲＴＳＰでは、伝送レイヤーでＲＴＰなどを利用してリアルタイムに情報（特に、映像や音声などを想定している）を受渡しするアプリケーションのための制御用プロトコルとして利用されることもある。
【００１５】
（第１の実施の形態）
ネットワーク上に配置されたカメラサーバから送られるライブ映像を、携帯電話端末向けに変換して中継する画像配信システムの形態について説明する。
【００１６】
本実施の形態は、映像の変換と中継を行う映像変換サーバにおいて中継されたライブ映像を携帯電話端末向けの映像形式（コーデックや画面サイズなど）および通信方法（プロトコル）を変換する。そして、本実施の形態の映像変換サーバでは、その特徴として、（１）カメラ制御を伴うソース映像を用いる点、（２）連続するＪＰＥＧデータ（Ｍｏｔｉｏｎ ＪＰＥＧ方式：フレーム内で映像データを圧縮（各フレームを静止画として圧縮）する方式）をＭＰＥＧ−４データに変換をする点が上げられる。
【００１７】
図１は、本実施の形態における映像配信システムの一例を示した図である。
【００１８】
図１において、カメラサーバ１０１，１０２は、接続されているカメラによって撮像された映像を動画像としてＭｏｔｉｏｎ ＪＰＥＧ方式でネットワーク上にリアルタイムに配信する。ＰＣ（パーソナルコンピュータ）２００は、Ｍｏｔｉｏｎ ＪＰＥＧ方式で配信された画像を受信するためのクライアントである。
【００１９】
映像変換サーバ４００は、カメラサーバ１０１，１０２が提供する映像データを携帯電話端末向けに変換し、携帯電話端末に配信する。また、ゲートウェイ５００はネットワーク網と前記ネットワーク網よりデータ通信速度の制限された携帯電話回線網（６４ｋｂｐｓ）とを仲介するゲートウェイであり、携帯電話端末６０１，６０２は映像変換サーバによって変換された映像を受信するクライアントである。なお、携帯電話端末６０１，６０２上のビューワプログラムは、典型的には、工場出荷時にインストールされるが、Ｊａｖａプログラムなどが実行時（利用時）にダウンロードされて実行される形態であっても良い。
【００２０】
カメラサーバ１０１，１０２と、クライアントとしてのＰＣ２００あるいは携帯電話端末６０１，６０２との間では、クライアントからネットワークを介してリクエストがカメラサーバへ送られ、これが受け入れられるとカメラサーバからクライアントへ映像データが配送され、クライアントでカメラ映像を見ることが可能となる。またクライアントからカメラ制御コマンドがカメラサーバへ送られ、カメラのズーム、パン、チルトなどの操作が可能となる。
【００２１】
図１のネットワークは企業あるいは組織内で運用されるイントラネットである場合もあり、広く世界をつないでいるインターネットである場合もある。また、映像変換サーバは、インターネットイクスチェンジ （ＩＸ）やデータセンター（ＩＤＣ：Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）に配置され、通信負荷の軽減を図るよう設計される。
【００２２】
図２は、映像変換サーバ４００を動作させるハードウェア構成の一例を示したものである。より詳細には、プログラムによる各種の処理を実行するＣＰＵ２０１，主記憶装置となるＲＡＭ２０２、プログラムを外部の記録媒体からロードするためのＦＤ装置２０３，二次記憶装置としてのＨＤ装置２０４，ネットワークと接続するためのネットワークＩ／Ｆ２０５などからなる。また、図示しないが、操作性の向上のため、設定などを行うためのキーボードやマウスなどのコントローラなどの入力装置、あるいはディスプレイなどの表示装置を有してもよい。
【００２３】
図３はカメラサーバ１０１，１０２のハードウェア構成の一例を示したものである。より詳細には、プログラムによる各種の処理を実行するＣＰＵ３０１，主記憶装置となるＲＡＭ３０２、プログラムを外部の記録媒体からロードするためのＦＤ装置３０３，二次記憶装置としてのＨＤ装置３０４，ネットワークと接続するためのネットワークＩ／Ｆ３０５，被写体を撮像するカメラ３０５，カメラからの映像を取得する映像キャプチャボード３０６，カメラ３０５に対して制御コマンドを出力するシリアルＩ／Ｆ３０７によって構成される。また、図示しないが、操作性の向上のため、設定などを行うためのキーボードやマウスなどのコントローラなどの入力装置、あるいはディスプレイなどの表示装置を有してもよい。
【００２４】
図４はクライアントとして動作する携帯電話端末６０１，６０２のハードウェア構成の一例を示したものである。より詳細には、携帯電話網と接続するための無線通信Ｉ／Ｆ４０１、プログラムやデータを格納するためのＲＡＭ、フラッシュメモリなどからなる記憶装置４０２、プログラムによる各種の処理を実行するＣＰＵ４０３、携帯電話端末上に配置されたボタンやスイッチ類などの操作部材、ディスプレイ４０４、ディスプレイの表示を制御する表示コントローラ４０５、マイクロフォンやスピーカを含む音声入出力装置４０８によって構成される。
【００２５】
図５は、本実施の形態の画像配信システムにおいて、携帯電話端末６０１，６０２、映像変換サーバ４００、カメラサーバ１０１，１０２のソフトウェア的な処理の流れの概略を模式化した図である。本実施の形態の画像配信システムでは、携帯電話端末６０１，６０２によってカメラサーバ１０１，１０２に接続されているカメラを制御する処理と、カメラサーバ１０１，１０２から携帯電話端末６０１，６０２にカメラによって撮影された映像を配信する処理との処理からなる。
【００２６】
カメラサーバ１０１，１０２内にはカメラの制御をつかさどるカメラ制御サーバ５０３と映像の配送をつかさどる映像サーバ５０８の２つのモジュールを含む。
【００２７】
また、携帯電話端末６０１，６０２においてカメラ制御の指令やカメラの状態通知に対応するカメラ操作部５０１、受信したカメラ映像を表示する映像表示部５０４の２つのモジュールを含む。
【００２８】
さらに、映像変換サーバ４００には、カメラ制御を中継あるいはカメラ制御命令を発行するカメラ制御部５０２、ならびに、カメラサーバから映像を取得し、取得した映像の映像方式を携帯電話端末向けに変換し、さらに、それを携帯電話網向けに送出するモジュール（映像取得部５０７、映像変換部５０６、映像送信部５０５）がそれぞれ含まれる。
【００２９】
図６は携帯電話端末６０１，６０２におけるクライアントとしての動作処理フローチャートである。
【００３０】
ステップＳ６０１において、まず、映像変換サーバ４００の識別子を入手する。これは、ユーザが直接操作部４０７のキー操作により識別子を入力するのでも良いし、メイルやウェブページに含まれる識別子を選択するのであっても良い。また、この場合の識別子は、典型的には、携帯電話網内で映像変換サーバ４００を特定する電話番号であるが、映像変換サーバ４００を識別するＵＲＬであっても良い。
【００３１】
次に、ステップＳ６０２において、ゲートウェイ５００を経由して、入手した識別子に基づいて映像変換サーバ４００の映像送信部５０５にアクセスする。
【００３２】
そして、さらにステップＳ６０３で、映像変換サーバ４００が提供する映像データの属性情報を取得する。これは、例えばＲＴＳＰの¨ＤＥＳＣＲＩＢＥ¨メッセージの送受信による。
【００３３】
ステップＳ６０４において、映像変換サーバ４００に映像送信の準備を要求し、映像受信に必要な情報を得る。これは、例えば、ＲＴＳＰの¨ＳＥＴＵＰ¨メッセージの送受信による。ここで得られた受信情報とは、映像の伝送プロトコルや伝送レベルのパラメータを含む。
【００３４】
また、ステップＳ６０４で、映像表示スレッドを生成する。映像表示スレッドは、得られた受信情報に基づいて映像データ受け取りポートを開くとともに映像変換サーバに映像送信開始を要求する（ステップＳ６１１）。そして、ステップＳ６１２において映像変換サーバ４００から映像データ受け取りポートを介して映像データを受取り、ステップＳ６１３で映像データのデコードを行い、ステップＳ６１４で携帯電話端末のディスプレイ装置４０４に表示する。そして、映像変換サーバからの映像を連続的に表示するために、このステップＳ６１１〜ステップＳ６１４までの動作を供述するステップＳ６０７からステップＳ６１０の期間中繰り返す。
【００３５】
ステップＳ６０５において、映像の表示が開始されるとともに、ゲートウェイ５００を経由して、入手した識別子に基づき映像変換サーバ４００のカメラ制御部５０２に接続する。そして、これ以降の動作処理はユーザからの操作要求を受け付け実行するメインループへ続く。
【００３６】
まず、メインループの処理として、ステップＳ６０６においてユーザの命令を操作部４０７から受け取る。これがカメラ制御に関する場合にはステップＳ６０７で映像変換サーバ４００のカメラ制御部５０２へコマンドを発し、映像データに関する場合にはステップＳ６０８で映像変換サーバ４００の映像送信部５０５へコマンドを発する。また、ユーザの操作が携帯電話端末６０１，６０２自身の状態を変更する（例えば、バックライトを点灯する、あるいは、クライアントを終了する）ものの場合にはステップＳ６０９で内部状態を更新する。Ｓ６０９〜Ｓ６１１の処理が完了するとＳ６０８へ戻り、ユーザの操作入力を再び待つ。
【００３７】
そして、Ｓ６０７において、ユーザ操作がクライアントとしての映像受信動作の終了の場合には、その動作に関連するプログラムを順次終了する。
【００３８】
図７は、カメラサーバ１０１，１０２におけるカメラ制御サーバ５０３の動作処理フローチャートである。
【００３９】
ステップＳ７０１において、カメラ制御サーバ５０３は、まず起動時に特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）からカメラ制御サーバ５０３の動作設定情報を読み出して、それに基づき動作を開始する。ここでクライアントであるＰＣ２００や映像変換サーバ４００（携帯電話端末６０１，６０２）からのリクエストを受け付けるポートを開き、続いて、ステップＳ７０２に進み、クライアント（ＰＣ２００や映像変換サーバ４００）からのリクエスト受付状態に入る。
【００４０】
リクエスト（接続リクエストもしくは操作コマンドリクエスト）が受信された場合、接続リクエストならばステップＳ７０３に進み接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ７０２に戻る。可ならば、ステップＳ７０４に進み、接続処理として、クライアントからのコマンドの受付処理を行う受付スレッドを生成し、接続を要求したクライアントの登録を行ってからステップＳ７０２に戻る。
【００４１】
上記のごとく生成された操作受付スレッドにおいて、対応するクライアントからのコマンドの受付を行う（ステップＳ７０７）。コマンドが届いたならば、それを受け付け、カメラ操作を行う主プログラムへ受け渡す。主プログラムはステップＳ７０２でこれを受け、カメラ操作コマンドに対してはステップＳ７０５へ進み、そのコマンドに対応するカメラ制御（カメラのパン，チルト，ズームなど）を行って、その結果（操作が成功か失敗かを示すコードなど）をカメラ操作要求を受け付けた操作受付スレッドへ伝える。ステップＳ７０８に進み、このクライアント対応のスレッドは制御結果をカメラ操作コマンドを出力したクライアントへ送り返す。
【００４２】
なお、操作受付スレッドは、ステップＳ７０４において登録されたクライアントごとに生成される。そして、主プログラムの動作処理において、ステップＳ７０６のカメラの制御により変化した状態（たとえば、パン・チルト・ズームの値）をすべての受付スレッドに伝え、接続しているすべてのクライアントに出力する（ステップＳ７０９）。クライアント対応の各操作受付スレッドは、クライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ７１０に進み、自身の受付スレッドを終了する。
【００４３】
なお、操作コマンドの扱いにおいては、具体的な操作コマンドの発行の前に、カメラ操作権の割り当て要求を必要とすることも可能である。これは複数の人間がカメラの操作を要求するような状況での混乱を無くす。
【００４４】
この場合、まず、クライアントからはカメラ操作権獲得の要求コマンドが発行され、これに対して、カメラ制御サーバ５０３は現在のカメラ制御権の割り当て状態から、拒絶・割り当て・順番待ちを選びクライアントへ返答する。カメラ制御権は前もって定められた特定の時間か、クライアントが接続を終了するまでの短いほうの時間で剥奪され、次の順番待ちの人に割り当てられる。順番待ち人数はやはり前もって定められた人数（たとえば５人）に制限され、それ以上のリクエストは拒絶される。クライアントは、カメラ制御権が獲得されてから剥奪されるまでの間だけ、操作コマンドを発行することができる。そして、カメラ制御サーバはカメラ制御権が付与されているクライアントからの操作コマンドのみを受け付ける。このような処理によってカメラ操作権の割り当て要求を行うことができる。
【００４５】
次に、カメラサーバ１０１，１０２における映像サーバ５０８の動作処理を図８のフローチャートを用いて説明する。
【００４６】
ステップＳ８０１において、まず起動時に特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から映像サーバ５０８の動作設定情報を読み出して、それに基づき動作を開始する。ここで、映像の獲得・符号化・蓄積を行うスレッドを生成し（最初このスレッドは休止状態である）、ＰＣ２００および映像変換サーバ４００（携帯電話端末６０１，６０２）からのリクエストを受け付けるポートを開き、続いて、ステップＳ８０２のリクエスト受付状態に入る。
【００４７】
リクエスト（接続リクエストもしくはコマンドリクエスト）が受け付けられたら、そのリクエストが接続リクエストであるかどうか判断し、接続リクエストならばステップＳ８０３で接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ８０２に戻る。可ならば、ステップＳ８０４で接続処理として、クライアントごとのセッションを識別するためのセッション識別子を生成し、クライアントからの映像に関するコマンドの受付処理を行う映像受付スレッドを生成し、クライアントの登録を行い、Ｓ８０２に戻る。なお、この際、リクエスト内容がライブ映像への接続要求であり、かつ、映像の獲得と符号化を行うスレッドが休止状態ならば、Ｓ８０２に戻る前に、それらのスレッドの動作開始を指示する。
【００４８】
生成されたクライアント対応の映像受付スレッドにおいて、まずステップＳ８０７で対応するクライアントからのコマンドの受付を行う。コマンドが届いたならば、それを受け付け、映像処理を行う主プログラムへ受け渡す。
【００４９】
主プログラムにおいて、ステップＳ８０２で映像処理を行うコマンドを受け、ステップＳ８０５へ進み、映像の獲得や符号化・送信などに関する設定の変更操作を行う。変更した結果（操作の成功か失敗を示すコード）をコマンド要求を受け付けたクライアント対応の映像受付スレッドへ伝える。クライアント対応のスレッドはステップＳ８０８で、この結果をクライアントへ送り返す。
【００５０】
主プログラムにおいて、ステップＳ８０４からの映像の獲得と符号化を行うスレッドへの動作開始の指示により、ステップＳ８０６では前もって設定された時間間隔で映像データを映像キャプチャボード３０６から獲得し、これを圧縮データに変換する。さらにこの圧縮データを、ライブ映像に接続しているすべてのクライアント対応のスレッドに伝える。
【００５１】
各クライアント対応のスレッドはステップＳ８０９で、クライアントからの次映像フレーム送信要求の有無を判定し、要求があるならば、圧縮データをクライアントへ配送する。このとき、配送される映像データはＱＶＧＡサイズ（３２０ｘ２４０）のＭｏｔｉｏｎ ＪＰＥＧ圧縮方式である。ライブ映像に接続しているクライアント対応のスレッドが、クライアントからの次映像フレーム送信要求（これはクライアントでの圧縮映像データの受け取り完了に対して、送り返されるのが一般的である）を受け取った場合には映像フレーム送信要求のフラグを設定する。
【００５２】
また、クライアントから接続終了のコマンドを受けたならば、それを主プログラムへ通達し、さらにステップＳ８１０で自身のスレッドを終了する。
【００５３】
図９は、カメラサーバ１０１，１０２のいずれかのクライアントとして動作している場合の携帯電話端末６０１，６０２の操作部４０７の割り当てを例示した図である。
【００５４】
クライアントが動作している際には、携帯電話端末の操作部４０７にはカメラに対するパン、チルト、ズーム、カメラ制御権の要求、逆光補正、接続終了などの機能が割り当てられる。
【００５５】
この画面は、図６において示した携帯端末６０１，６０２の動作処理においてユーザが入力操作を行うためのＵＩであり、ステップＳ６１４で表示する映像データは、携帯電話端末のディスプレイ装置４０４に表示され、操作部４０７からの指示はＳ６０６で受け取られるとともに、Ｓ６０９〜Ｓ６１１でコマンドが生成されてこれらのコマンドが映像変換サーバ４０４送られることになる。
【００５６】
図１０はカメラサーバ１０１，１０２の用いる設定値、すなわち、ステップＳ７０１およびステップＳ８０１でカメラ制御サーバ５０３や映像サーバ５０８が起動するときに読み出される動作設定情報を特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）に設定するカメラサーバ設定プログラムの表示画面の一例を示した図であり、カメラ制御サーバ５０３、映像サーバ５０８、動画品質、接続制限事項などに関する各種のパラメータ（後述）を設定できるようになっている。ＯＫボタンを押すと設定した値が特定のファイルあるいはレジストリに書き込まれ、キャンセルすると書き込まれずに終了する。
【００５７】
図１１は図１０のカメラサーバの設定プログラムの動作を示す流れ図である。
【００５８】
設定プログラムは起動時にまずステップＳ１１０１でカメラ制御サーバ５０３および映像サーバ５０８に関する設定情報を格納した特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から設定情報を読み出し、内部データに設定する。以降、ユーザの操作入力を受け取り、実施するループを繰り返す。ステップ１１０２でユーザの操作入力を待ち、入力があればそれを受け取り、続いてステップ１１０３で入力された値が適正範囲内であるか否かを判定し、適正でなければステップ１１０４でエラーメッセージを出力して、値を戻して、ユーザの入力待ちＳ１１０２へ戻る。適正範囲内であるならば、内部データを更新して、Ｓ１１０２に戻る（ここで設定できる値には次の項目がある。カメラ制御の通信用のＴＣＰポート番号、カメラと接続するＣＯＭ（シリアル）ポート、シャッタースピード、カメラ制御関連のログ情報の有無とログファイル名、映像関連の通信用のＴＣＰポート番号、ログ情報の有無とログファイル名、映像をキャプチャする時間間隔を規定するフレームレートと圧縮の品質を決めるＱ−Ｆａｃｔｏｒ、圧縮の元データの画面サイズ、１つのクライアントクライアントの最大接続時間、カメラ制御に関する制御権の順番待ち人数、１つのクライアントの制御権保持占有時間、映像とカメラ制御に関する接続可能な最大クライアント数など）。
【００５９】
ユーザからの入力がＯＫボタンの場合には、Ｓ１１０２からステップＳ１１０５に進み、更新された内部データをカメラ制御サーバおよび映像サーバに関する設定情報を格納する特定のファイルなどへ書き出し、ステップＳ１１０６で変更を反映するためにカメラサーバを再起動するかを尋ねるパネルを出す。再起動する場合にはステップＳ１１０７でカメラ制御サーバや映像サーバなどを再起動して、ステップＳ１１０８で設定プログラムを終了する。再起動しない場合にはＳ１１０６から直接Ｓ１１０８に進み、終了する。また、Ｓ１１０２でのユーザの入力がキャンセルボタンである場合には、Ｓ１１０２から直接Ｓ１１０８に進み、終了する。
【００６０】
図１２は、映像変換サーバ４００における映像データの変換を模式化した図である。カメラサーバ１０１，１０２から送信された映像データ（Ｍｏｔｉｏｎ ＪＰＥＧ、ＱＶＧＡサイズ３２０ｘ２４０）は、映像変換サーバ４００のカメラサーバ１０１，１０２向けの通信スタックを経由して受信され、ＪＰＥＧデコーダにおいて直交変換処理が行われる。そして、直交変換処理された映像データは携帯電話向けに設定されたＭＰＥＧ−４エンコーダにより、携帯電話向け映像データ（ＭＰＥＧ−４ ｓｉｍｐｌｅ−ｐｒｏｆｉｌｅ、ＱＣＩＦサイズ１７６ｘ１４４、６４Ｋｂｐｓ）に加工される。そして、携帯電話網向けの通信スタックを経由して、携帯電話クライアントへと送信される。
【００６１】
図１３は映像変換サーバ４００の動作処理を示したフローチャートである。なお、本実施の形態では、クライアントの登録の管理を集約する構成とするために変換処理の必要のないＰＣ２００もクライアントとして映像サーバ５０８に接続できるものとする。
【００６２】
ステップＳ１３０１において、映像変換サーバ４００はまず起動時に特定のファイル（ＯＳによってはレジストリなどのシステムデータベース）から映像変換サーバの動作設定情報を読み出して、それに基づき動作を開始する。ここで、クライアントである携帯電話端末６０１，６０２からのリクエストを受け付ける通信ポートを開き、ステップＳ１３０２に進みリクエスト受付状態に入る。
【００６３】
ステップＳ１３０２ａにおいてリクエスト（ＲＴＳＰのメッセージなど）が受け付けられたら、ステップＳ１３０３に進み、リクエストしたクライアント（ＰＣ端末もしくは携帯電話端末）の接続の可否の判定を行う。否ならば接続拒否のエラーコードを返し、ステップＳ１３０２に戻る。可ならば、ステップＳ１３０４に進み、接続処理として、接続したクライアントとの映像データなどの情報の受渡しを行うクライアント対応スレッドを生成し、クライアントの登録を行い、ステップＳ１３０２に戻る。
【００６４】
生成されたクライアント対応スレッドでは、ステップ１３０２ａにおいて受け付けられたリクエストが接続リクエスト以外である場合にステップＳ１３１０で対応するクライアントからのリクエスト内容を解析する。
【００６５】
リクエスト内容が、映像データの属性情報を要求するリクエスト（例えば、ＲＴＳＰの¨ＤＥＳＣＲＩＢＥ¨メッセージ）である場合には、ステップＳ１３１１に進み、リクエストに付随する映像データの名前や識別子などの情報を取り出し、それらに応じた映像データの属性情報を映像変換サーバ４００内のデータベース部（ＨＤ装置２０４）から取り出し、それを適切なフォーマット（例えば、ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に編集した上で、クライアントに返答する。
【００６６】
また、リクエスト内容が、映像送信の準備を要求するリクエスト（例えば、ＲＴＳＰの¨ＳＥＴＵＰ¨メッセージ）である場合には、ステップＳ１３２１に進み、まず、リクエストで要求された映像データのソース映像情報を映像変換サーバ４００内のデータベースから取り出す。ソース映像情報とは、例えば、図１４に示すようなライブ映像を提供するカメラサーバのネットワークアドレスとポート番号などの通信属性情報およびカメラ制御用のパラメータ情報などである。
【００６７】
続いて、ステップＳ１３２２に進み、ソース映像情報に従って、映像取得部５０７を初期化する。具体的には、ソース映像を提供するカメラサーバ１０１または１０２に接続し、ソース映像取得を開始する。そして、ステップＳ１３２３に進み、映像変換パラメータを映像変換サーバ４００内のデータベースから取り出す。映像変換パラメータは、変換用コーデックの選択やそのコーデックへのパラメータ、および、コーデック入力用／出力用のデータ形式などを記述している。
【００６８】
続いて、ステップＳ１３２４に進み、映像変換パラメータに従って映像変換部５０６を初期化する。この映像変換部５０６は、ＪＰＥＧデコーダおよびＭＰＥＧ−４エンコーダなどから構成される。さらに、ステップＳ１３２５に進み、映像送信パラメータ情報を映像変換サーバ４００内のデータベースから取り出す。映像送信パラメータ情報では、送信タイムアウトや送信ビットレート範囲などが記述されている。
【００６９】
そして、ステップＳ１３２６に進み、映像送信パラメータ情報に従って携帯電話端末向け映像送信部５０５を設定し、映像送信部５０５から配信される映像情報をクライアントが受取るのに必要な情報（通信ポート情報など）をリクエストしたクライアント（携帯電話端末）に返答する。
【００７０】
また、リクエスト内容が、映像送信開始を要求するリクエスト（例えば、ＲＴＳＰの¨ＰＬＡＹ¨メッセージ）である場合には、ステップＳ１３３１に進み、映像変換ドライブスレッドを生成し、映像変換ドライブスレッド実行の可否をクライアントに返答する。この映像変換ドライブスレッドでは、先に準備されている映像取得部５０７、映像変換部５０６、映像送信部５０５を駆動するように動作する。
【００７１】
もしも、映像取得部５０７、映像変換部５０６、映像送信部５０５の何れかの準備が整っていなかった場合には、映像変換ドライブスレッドを終了し、映像変換ドライブスレッド実行ができない理由をクライアントに返答する。
【００７２】
準備が整った場合には、映像変換ドライブスレッドは、映像取得部５０７から映像変換部５０６へ、映像変換部５０６から映像送信部５０５へとそれぞれにおいて処理された映像データが受渡しされるように設定する。このような設定を行った後、カメラサーバ１０１または１０２から映像を受取り、映像変換部５０６で変換した結果を映像送信部５０５からクライアントへ送り出すことを繰り返す。なお、映像変換ドライブスレッドは、登録（接続）しているクライアントが映像変換部５０６において映像の変換処理が必要な携帯端末（６０１，６０２）であるかもしくはＰＣ２００であるかを判断しＰＣ２００である場合は、映像変換部５０６において変換処理をせずにＭｏｔｉｏｎ−ＪＰＥＧの映像データ形式のままクライアント（ＰＣ２００）に配信する。この処理によってＰＣ２００に対しては処理スピードを早くすることができる。
【００７３】
また、リクエスト内容が、映像送信一時停止を要求するリクエスト（例えば、ＲＴＳＰの¨ＰＡＵＳＥ¨メッセージ）である場合には、ステップＳ１３４１に進み、映像変換ドライブスレッドを一時停止する。
【００７４】
また、リクエスト内容が、映像送信中断を要求するリクエスト（例えば、ＲＴＳＰの¨ＴＥＡＲＤＯＷＮ¨メッセージ）である場合には、ステップＳ１３５１に進み、映像変換ドライブスレッドを終了する。そして、ステップＳ１３５２に進み、映像取得部５０７、映像変換部５０６、映像送信部５０５の後処理を行い、ステップＳ１３５３に進み、クライアントとの接続終了を主プログラムへ通知し、クライアント対応スレッドを終了する。
【００７５】
次に、映像変換サーバ４００の中で機能している映像取得部５０７、映像変換部５０６、映像送信部５０５について順次説明する。
【００７６】
映像取得部５０７は、まず、初期化時に受取ったソース映像情報に従って、ライブ映像を取得する対象のカメラサーバに接続する。そして、映像変換ドライブスレッドの要求に応じて、カメラサーバから映像データを取得し、取得時のタイムスタンプを付与して映像データを映像変換部へ渡す。本実施の形態におけるカメラサーバは、映像データをＭｏｔｉｏｎ ＪＰＥＧ形式で提供するので、タイムスタンプが付与されるのは、個々のＪＰＥＧデータである。
【００７７】
次に映像変換部５０６について説明する。まず、初期化時に受取ったコーデックへのパラメータ、および、コーデック入力用／出力用のデータ形式などをＭＰＥＧ−４エンコーダに設定する。そして、映像変換ドライブスレッドの要求に応じて、映像取得部５０７から受取ったソース映像データを、コーデック入力用のデータ形式および画像サイズに整えてからＭＰＥＧ−４エンコーダに入力し、その処理結果を、映像送信部５０５へ渡す。
【００７８】
そして、映像変換部５０６は、ＪＰＥＧ形式のソース映像データを、予め、ＱＣＩＦサイズかつＹＵＶ４１１形式に変換し、ＭＰＥＧ−４コーデックへ入力ＭＰＥＧ−４データ（Ｉ−ｆｒａｍｅまたはＰ−ｆｒａｍｅ）を生成した後、映像送信部５０５へ受け渡す。この際、映像取得部５０７で付与されたタイムスタンプも併せてＭＰＥＧ−４コーデックへ入力される。
【００７９】
なお、本実施の形態における映像変換部５０６では、各フレームのソース映像に付与されたタイムスタンプを観察し、ソース映像の受信間隔が所定時間以上開いた場合には、ＭＰＥＧ−４ の動き補償メカニズムを抑制する（例えば、動きベクトル探索を禁止し、オブジェクトに分解せずにフレームそのものを差分する）ようＭＰＥＧ−４エンコーダに指示する。これは、受信間隔が所定時間以上（例えば、１秒以上）開いた場合には、前のフレームとの相関が低くなるためである。なお、所定時間は、映像変換サーバ４００の設定情報として設定される。
【００８０】
さらに、この映像変換部４００では、ＭＰＥＧ−４エンコーダの出力をモニターして、出力データが携帯電話端末側の仕様に照らして過剰に生成される場合には、入力するソース映像をフレーム単位で間引いて、映像ストリーム全体の情報量を削減するよう映像取得部５０７に指示する処理を行ってもよい。
【００８１】
次に、映像送信部５０５に関して説明する。まず、初期化時に受取った送信パラメータ情報に従って、通信チャネルを準備し、クライアントが接続するのに必要な情報を提供する。そして、映像変換ドライブスレッドの要求に応じて、映像変換部５０６が生成した映像データをクライアント（携帯電話端末）宛に送信する。本実施の形態において、クライアントは処理能力の高くない携帯電話端末であり、かつ、映像データは、映像内容およびＩ／Ｐ−ｆｒａｍｅによってデータレートが変動するＭＰＥＧ−４データであることを想定している。そのため、映像送信部では、クライアントへの送信の伝送状態をモニターし、それを映像変換部に通知することにより適切なフレームレートで送信を行うようにしている。
【００８２】
以上の構成で、携帯電話端末（６０１，６０２）において、従来から設置されていたサーバ（１０１，１０２）から出力されるＭｏｔｉｏｎ−ＪＰＥＧ方式の映像データをＭＰＥＧ方式の携帯電話向け映像データに変換するための映像変換サーバを設置することにより、携帯電話端末においてもカメラからのライブ映像を表示させることができる。そして、映像変換サーバの映像変換部の機能により、ネットワーク上に配置されたカメラサーバが生成するソース映像内容やネットワークの通信状況などの変動を吸収して、適切な映像ストリームを携帯電話端末に安定供給することが可能となる。
【００８３】
なお、本実施の形態では、携帯電話網とネットワークとを結ぶゲートウェイとは独立に、ネットワーク上に映像変換サーバが実装される例について説明しているが、映像変換サーバが、ゲートウェイの一部として実装されても良い。また、映像変換サーバとゲートウェイとが、ＶＰＮ（Ｖｉｒｔｕａｌ ＰｒｉｖａｔｅＮｅｔｗｏｒｋ）なども含めて専用線で接続されるような接続形態も容易に想像できる。
【００８４】
また、本実施の形態では、すべての携帯電話ユーザに同一の映像データを配信する形態について説明しているが、ユーザの契約状況や課金の有無、あるいは、携帯電話端末の性能などに応じて、例えば解像度の異なった映像変換パラメータを使用するように設計しても良い。
【００８５】
（第１の実施の形態の変形例）
第１の実施の形態における映像変換サーバ４００の一部の動作を以下のように変更してもよい。すなわち、映像変換サーバ４００がカメラサーバ１０１，１０２に対して能動的に要求を行う。
【００８６】
本実施の形態の変形例では、映像変換サーバ４００の映像取得部５０７が以下のように動作する。
【００８７】
映像取得部５０７は、まず、初期化時に受取ったソース映像情報に従って、ライブ映像を提供するカメラサーバ１０１または１０２に接続する。そして、映像変換ドライブスレッドの要求に応じて、カメラサーバから映像データを取得し、映像取得時のタイムスタンプを付与して映像データを映像変換部５０６へ出力する。この際、映像取得部５０７は、接続先のカメラサーバから取得する映像データの画像サイズやデータサイズ、および、付与したタイムスタンプなどを観察し、例えば、映像中継サーバに初期設定されたフレームレート以下のソース映像データしか受信できなかった場合、接続先のカメラサーバに対して、特権接続（ＰＣ２００など他の端末に対する映像の配送を排除させた接続）による排他的な映像データの配信を要求する。
【００８８】
以上説明したように、インターネット上に配置されたカメラサーバから送られるライブ映像を、携帯電話端末に対して優先して中継することができる。そして、映像変換サーバ４００では、接続先のカメラサーバに対して、能動的なカメラ制御を行う事で、より良質なソース映像を取得する点に特徴がある。
【００８９】
なお、上記の特権接続の要求を行うタイミングは、例えば、他のクライアントによって、カメラサーバに対するカメラのパン，チルト制御などの要求が行われている際には、映像のブラーなどから一時的にフレームレートの低下が発生し得るので、カメラ制御の前後では、特権接続要求を抑制するよう制御する事が考えられる。
【００９０】
また、上記では、特権接続による排他的な映像配送について説明しているが、映像配信を、映像変換サーバ４００以外の他のクライアントに対しても提供してもよい。これによって、映像変換サーバ４００が、カメラサーバの全リソースを利用することはできなくなるものの、他のクライアントに対しても限定的ながら映像配信サービスを継続可能となる。
【００９１】
また、上記では、カメラサーバの特権接続による排他的な映像データ配送による良質なソース映像を取得する他に、例えば、画質よりも映像の動きを優先したい場合には、カメラサーバが供給する映像の画面サイズを１レベル小さく（ＱＶＧＡの３２０ｘ２４０からｓｕｂＱＶＧＡの１６０ｘ１２０へ）するようカメラサーバに要求してもよい。また、映像の動きよりも画質を優先したい場合には、カメラサーバがＪＰＥＧデータを作成する際の画像品質値（Ｑ値）を上げるようカメラサーバに要求してもよい。
【００９２】
本実施例では、カメラサーバのプリセット情報を利用していないが、カメラサーバに他クライアントへのサービス状況を問い合わせて、本実施例の映像変換サーバが唯一のクライアントである場合には、カメラサーバのホームポジションやプリセットを順次あるいは選択的に巡回する事も考えられる。
【００９３】
本発明は、上述したように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを、インターネットなどのネットワークを介して映像変換装置に供給し、映像変換装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによって達成できる。
【００９４】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態のＣＰＵ５０の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００９６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００９７】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示にもとづき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。
【００９８】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードを格納することになるが、簡単に説明すると、本発明の撮像装置に不可欠なモジュールを、記憶媒体に格納することになる。
【００９９】
【発明の効果】
以上説明したように、本願発明によれば、携帯情報端末上のクライアントに表示される映像を適切な状態でユーザに提供可能となる。
【図面の簡単な説明】
【図１】映像配信システムの一例を示す図。
【図２】映像変換サーバ４００を動作させるハードウェア構成の一例を示す図。
【図３】カメラサーバ１０１，１０２のハードウェア構成の一例を示す図。
【図４】携帯電話端末６０１，６０２のハードウェア構成の一例を示す図。
【図５】画像配信システムのソフトウェア的な処理の流れの概略を模式化した図。
【図６】携帯電話端末６０１，６０２の動作処理フローチャート。
【図７】カメラサーバ１０１，１０２におけるカメラ制御サーバ５０３の動作処理フローチャート。
【図８】カメラサーバ１０１，１０２における映像サーバ５０８の動作処理フローチャート。
【図９】携帯電話端末６０１，６０２の操作部４０７の割り当てを例示した図。
【図１０】カメラサーバ設定プログラムの表示画面の一例を示した図。
【図１１】カメラサーバの設定プログラムの動作を示す流れ図。
【図１２】映像変換サーバ４００における映像データの変換を模式化した図。
【図１３】映像変換サーバ４００の動作処理を示したフローチャート。
【図１４】ソース映像情報の一例を示す図。
【符号の説明】
１０１，１０２ カメラサーバ
２００ パーソナルコンピュータ
２０１ ＣＰＵ
２０２ ＲＡＭ
２０４ ＨＤ装置
４００ 映像変換サーバ
５００ ゲートウエイ
６０１，６０２ 携帯電話端末

Claims (8)

1. 撮像装置から得られた映像データをリアルタイムに配信する映像変換装置において、
   前記撮像装置と接続されたサーバからフレーム内圧縮を用いて圧縮された第１の映像データ方式の映像データを受信する受信手段と、
   前記受信手段によって受信された前記第１の映像データ方式の映像データをフレーム内圧縮およびフレーム間圧縮を用いて圧縮された第２の映像データ方式の映像データに変換し、変換された映像データを端末に配信するための制御手段とを有し、
   前記制御手段は、前記受信手段によって受信される映像データが所定のフレームレート以下の場合、前記サーバに対して排他的に前記第１の映像データ方式の映像データを配信することを要求することを特徴とする映像変換装置。
2. 請求項１において、前記第２の映像データ形式は、１フレーム内の画像を複数のオブジェクトに分解し、それぞれのオブジェクトにおいてフレーム間の差分を取る分解処理を行うことにより圧縮処理を行うことを特徴とする映像変換装置。
3. 請求項２において、前記制御手段は、１フレーム間隔が所定時間以上経過した場合、前記分解処理を禁止することを特徴とする映像変換装置。
4. 撮像装置から得られた映像データをリアルタイムに配信する映像変換方法において、
   前記撮像装置と接続されたサーバからフレーム内圧縮を用いて圧縮された第１の映像データ方式の映像データを受信する受信ステップと、
   受信された前記第１の映像データ方式の映像データをフレーム内圧縮およびフレーム間圧縮を用いて圧縮された第２の映像データ方式の映像データに変換する変換ステップと、
   変換された映像データを前記第２のネットワーク上の端末に配信する配信ステップと、
   前記受信ステップにおいて受信される映像データが所定のフレームレート以下の場合、前記サーバに対して排他的に前記第１の映像データ方式の映像データを配信することを要求する要求ステップとを有することを特徴とする映像変換方法。
5. 請求項４において、前記第２の映像データ形式は、１フレーム内の画像を複数のオブジェクトに分解し、それぞれのオブジェクトにおいてフレーム間の差分を取る分解処理を行うことにより圧縮処理を行うことを特徴とする映像変換方法。
6. 請求項５において、１フレーム間隔が所定時間以上経過した場合、前記分解処理を禁止することを特徴とする映像変換方法。
7. 請求項４ないし請求項６のいずれか１項に記載の映像変換方法の処理をコンピュータに実行させるための動作処理プログラム。
8. 請求項７に記載の動作処理プログラムを記憶した記憶媒体。

Images