JP2014171018A - 映像処理装置及び映像処理システム - Google Patents

Abstract

【課題】映像送信装置が映像を送信してから表示までに遅延があっても、映像送信装置の操作にかかわらず、遅延のない映像処理及び表示を実現できるようにする。
【解決手段】映像に関する操作要求を送信してから実際に操作要求の結果が反映された映像データを受信するまでの期間、映像に関する操作要求を送信した装置側の映像変更手段により作成された映像を表示することにより、映像に関する操作要求を送信してから、操作要求の結果が反映された映像を表示するまでの時間差を可及的に減少させることができるようにする。
【選択図】図３

Description

本発明は映像処理装置及び映像処理システムに関し、特に、映像の拡大縮小や回転あるいは変換などの映像に関する操作を映像送信装置に対して指示するとともに、映像送信装置より受信した映像の処理および表示を行うために用いて好適な技術に関する。

映像配信機能を備えたウェブカメラやネットワーク上に置かれた映像伝送サーバーを利用して、パーソナルコンピュータやいわゆるスマートフォンなどに映像をライブ配信する機能が利用されている。このようなライブ映像配信においては、ネットワーク上を流れる映像の通信パケットの遅延や通信パケットのジッタを吸収するための受信バッファの存在により、一般に遅延が発生する。すなわち、映像を撮影してから再生して表示されるまでの時間的差異が発生することが一般的である。これを再生遅延、あるいは、プレイアウト時間と呼んでいる。

また、映像を受信しているクライアントから、映像を撮影するカメラを操作するといったことも行われている。具体的には、映像を受信しているパーソナルコンピュータよりカメラのズーム操作を行うといった例である。これにより、配信される映像メディアの状態を変更することが可能である。

しかしながら、再生遅延が発生している状態でズーム操作のような映像メディアの状態を変更した場合、再生されている映像の撮影時間は過去のものであるため、映像と操作のずれが発生してしまう。

従来、このような再生遅延とメディアの状態の変更のずれを解決するものとして、映像を受信しているクライアントなどで直接メディアの状態を変更した新たなメディアを生成する技術が提案されている（たとえば、特許文献１参照）。

より詳細に説明すると、第１のデバイス（受信クライアント）から、遠隔配置された第２のデバイス（伝送サーバー）への変更メディアストリーム要求を行い、要求処理時と変更メディアストリーム配信の遅延期間を求め、遅延期間の間、第１のデバイス（受信クライアント）で変更メディアストリームを作成するといった技術である。

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

しかしながら、従来技術では、主として音声データに関する巻き戻しといった受信クライアントが代替可能な方法については開示されているものの、ライブ映像に関するメディア変更の具体的な方法については知られていなかった。このため、結果として、ライブ映像のズーム処理などでは、遅延のない映像処理を行うことができないといった課題があった。
本発明は前述の問題に鑑み、映像送信装置が映像を送信してから表示までに遅延があっても、映像送信装置の操作にかかわらず、遅延のない映像処理及び表示を実現できるようにすることを目的とする。

本発明の映像処理装置は、映像送信装置から映像データを受信するとともに、映像に関する操作を映像送信装置に対して指示する映像処理装置において、前記映像送信装置から映像データを受信する映像受信手段と、前記映像受信手段が受信した映像データを表示する映像表示手段と、前記映像表示手段に表示する映像に関する操作要求を前記映像送信装置に送信する映像操作指示手段とを有し、前記映像表示手段は、映像に関する操作要求を送信してから実際に操作要求に応じて変更された映像データを受信するまでの期間、操作要求の結果と同様となるよう映像を変更する映像変更手段を有し、前記映像表示手段は、前記映像変更手段により変更された映像を表示することを特徴とする。

本発明によれば、映像に関する操作要求を前記映像送信装置に送信した際に、映像送信装置が映像を送信してから表示までに遅延があっても、遅延のない映像処理を行い表示することが可能となる。

実施形態における映像処理装置の一例としてのデジタルビデオカメラとビューアからなる映像処理システムの構成を概念的に示すブロック図である。 カメラの内部構成を示すブロック図である。 プレイアウト時間とズーム操作に関する遅延の影響を説明するタイミング図である。 第１の実施形態における処理の一例を示すフローチャートである。 ビューアにおいて行われるレンダリングにおける拡大処理の概念を説明する図である。 第２の実施形態における処理の一例を示すフローチャートである。 コマンドの一例を示す図である。

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
（第１の実施形態）
最初に、本実施形態の映像処理装置の構成について、その概要をデジタルビデオカメラの例を用いて説明する。

図１は、本発明の実施形態における映像処理装置の一例としてのデジタルビデオカメラとビューアからなる映像処理システムの構成を概念的に示すブロック図である。なお、ここでは、デジタルビデオカメラを単にカメラと呼ぶことにする。

図１において、１０１は、本実施形態に好適なカメラである。
カメラ１０１は、利用者がカメラ１０１を操作するためのカメラユーザインターフェース１０２を備える。また、利用者がカメラユーザインターフェース１０２を介してカメラの様々な機能を操作したり、あるいはカメラ１０１自体の動作を行ったりするためのカメラアプリケーションモジュール１０３を備える。

ここに、カメラアプリケーションモジュール１０３は、たとえばデジタルデータを記録する最適な形式に成形するといった処理を行ってもよい。あるいは、撮像モジュール１０４を制御して、撮影の開始や終了を制御するといった処理を行なってもよい。すなわち、カメラアプリケーションモジュール１０３は、図１で例示するカメラ１０１の制御アプリケーションとなるものである。

撮像モジュール１０４は、実際に映像を撮影するための機能を担うモジュールである。撮像モジュール１０４は、たとえばレンズを通して得た光学的な映像をデジタルデータに変換する。ここにデジタルデータは、静止画像であってもよいし、動画像であってもよい。あるいはまた、マイクロフォンを通して得られた音響データが含まれていてもよい。

カメラ記録モジュール１０５は、必要に応じて撮影された映像をカメラ記録ユニット１０６に記録する。
カメラ通信モジュール１０７は、ネットワーク回線１０８を通じて様々なデータを送受信する機能を担うモジュールである。ネットワーク回線１０８は、有線LANや無線LANであってもよいし、携帯電話網などの公衆無線通信であってもよい。

一方、図１において、１０９は、本実施形態に好適なビューアである。ビューア１０９は、より具体的には、カメラ１０１が撮影した映像を表示したり、カメラ１０１を操作する命令を発行したりする機能を有し、一般的には、パーソナルコンピュータやテレビ、あるいは、スマートフォンといった装置が典型的な例である。

ビューア１０９は、映像を表示したり利用者が操作したりするためのビューアユーザインターフェース１１０を備える。また、利用者がビューアユーザインターフェース１１０を介してビューアの様々な機能を操作したり、あるいは映像やユーザインターフェースの表示を行ったり、ビューア１０９そのものの制御を行ったりするためのビューアアプリケーションモジュール１１１を備える。

ビューアアプリケーションモジュール１１１は、前述した操作を行ったり、ビューア１０９そのものの制御を行ったりするために、ＣＰＵ、ＲＯＭ及びＲＡＭなどからなるコンピュータシステムを有している。

ビューア通信モジュール１１２は、ネットワーク回線１０８を通じて様々なデータを送受信する機能を担うモジュールである。本実施形態においてはカメラ１０１から操作要求に従った処理を開始もしくは終了したことを示す操作要求の処理状況の通知を受信する処理状況通知受信、映像受信を行う。
ビューア記録モジュール１１３は、必要に応じてカメラ１０１から受け取った映像をビューア記録ユニット１１４に記録する。

なお、本実施形態を構成するにあたり、たとえばカメラ記録モジュール１０５とカメラ記録ユニット１０６は、必ずしも必須のものではない。このような選択的に利用される部分については、実施する際のアプリケーションに依存するため今後の説明の中でいちいち明言はしないが、必要に応じて言及する。具体的には、図１のブロック図に関する説明をより具体的に示すため、次に、映像の撮影からビューアでの表示までの一連の流れについて、従来の処理の一例を簡単に説明する。

カメラ１０１の利用者は、最初に、カメラユーザインターフェース１０２を操作し、撮影およびビューア１０９への配信準備の指示を行う。カメラアプリケーションモジュール１０３は、この指示を感知し、該当するアプリケーションを起動する。アプリケーションは、たとえば撮像モジュール１０４へのレンズ駆動指示や撮像データの符号化を開始する。アプリケーションによっては、カメラ記録モジュール１０５を操作して撮像データの記録を開始してもよい。

一方、ビューア１０９の利用者は、ビューアユーザインターフェース１１０を操作してカメラ１０１からの映像取得の指示を行う。これに従って、ビューアアプリケーションモジュール１１１は、ビューア通信モジュール１１２を介して、カメラ１０１に対する映像送信の依頼を行う。

カメラ１０１のカメラアプリケーションモジュール１０３は、これを検知して、ビューア１０９への映像配信を開始する。配信された映像は、ビューア通信モジュール１１２を介してビューア１０９に送られ、ビューアアプリケーションモジュール１１１がビューアユーザインターフェース１１０に映像を出力する。この時、ビューアアプリケーションモジュール１１１は、アプリケーションによっては、ビューア記録モジュール１１３を操作して撮像データの記録を開始してもよい。

ここに、前述した説明においては、具体的な通信手順や通信アドレスの取得方法などの説明を省略した。これらは、どのような方法であってもよいが、たとえば通信手順においては、インターネット上で広く利用されているHTTP（Hyper Text Transfer Protocol）やRTP（Real-time Transport Protocol）およびRTSP（Real Time Streaming Protocol）の組み合わせなどを利用することができる。

加えて、ビューア１０９からカメラ１０１の操作を行うことも考えられる。これは、典型的には、パーソナルコンピュータと監視カメラなどから構成される監視システムなどで広く利用されている方法である。すなわち、前述したような、カメラ１０１の映像をネットワーク回線１０８を介してビューア１０９に転送し、ビューア１０９で再生する形態がこれにあたる。

そのような例では、ビューアユーザインターフェース１１０にカメラのズーム操作を行うようなインターフェースを表示し、利用者がこれでズーム操作を指示する。ビューアアプリケーションモジュール１１１は、これを通信プロトコルに変換し、カメラ１０１上のカメラアプリケーションモジュール１０３に通知する。

カメラアプリケーションモジュール１０３は、通信プロトコルを解釈して、たとえば撮像モジュール１０４の光学系を操作してズーム処理を行う。このような流れに従って、利用者は、ビューア１０９上でカメラ１０１の映像を確認しながらカメラ１０１のズーム処理などを行うことができる。
以上が、図１のブロックを用いた従来の流れの一例である。

本発明に特徴的なカメラの操作と映像を一致させる処理の説明を行う前に、さらに詳細なブロック図を用いて具体的な装置構成例について説明しておく。
図２は、本発明の一例としてのカメラ１０１の内部構成を示すブロック図である。
撮影しようとする被写体の画像は、光学系からなる撮影レンズユニット２０１を通って光学センサ２０５に結像する。

撮影レンズユニット２０１は、たとえば焦点を合わせるためにモーターなどによりレンズ群を移動する仕組みになっており、その直接の制御は、撮影レンズユニット駆動回路２０２によって行われる。この時、絞りを含む絞りユニット２０３が絞りユニット駆動回路２０４によって操作され、結像する光は適切に光量調整されるようになっている。

光学センサ２０５は、固体撮像素子（CCDやCMOSなど）によって構成され、入射した光を光学量に応じて電荷に変換、蓄積する機能をもっている。この電荷を読み出し、A/Dコンバータ２０７でデジタル化することにより、圧縮されていないデジタル画像が生成される。

光学センサ２０５は、光学センサ駆動回路２０６の出力するパルス信号などによって適切に制御されており、指示されたタイミングで指示された時間の間に蓄積された電荷を読み出す一連の動作を連続することによって、連続したデジタル画像が得られることになる。このようにして取得された連続画像は、言うまでもなく動画像である。

次に、連続して取得されるデジタル画像は、圧縮符号化を行うために、画像信号処理回路２０８に受け渡され、ホワイトバランス補正やガンマ補正といった画像の補正を行った上で、圧縮符号化回路２０９に受け渡される。このような処理間のデジタル画像の受け渡しは、たとえばDMA（Direct Memory Access）回路を利用した高速なメモリ２１０のアクセスにより行われる。

圧縮符号化回路２０９内では、符号化のアルゴリズムが実装され、動画像が圧縮処理される。たとえば、連続したJPEG（ISO/IEC 10918）符号化によるいわゆるモーションJPEG画像では、画像信号処理回路２０８の入力でデジタル画像がＲＧＢ信号である場合、輝度信号Yとクロマ信号CbCrからなるYC信号化され、これらを8ｘ8画素のブロックに分割する。その後、離散コサイン変換、量子化、ハフマン符号化といった処理が行われて最終的な圧縮画像が出力される。

あるいは、圧縮符号化方式がMPEG-2（ISO/IEC 13818）やMPEG-4（ISO/IEC 14496）などのフレーム間予測を行う形式である場合、圧縮しようとする特定の１枚の画像（フレーム）に対し、前後のフレームを参照しながら、動き補償予測、マクロブロック処理などを行って、前後が相互に依存した圧縮画像（ビットストリーム）が出力される。
このようにして出力された動画の圧縮画像は、メモリ２１０に一時保管され、通信回路２１３を介してビューア１０９に送信されていく。

また、アプリケーションによっては、外部記憶I/F回路２１２を介してメモリーカードのような記録媒体に出力されてもよい。すなわち、先に説明したように、カメラ記録モジュール１０５が、必要に応じて撮影された映像をカメラ記録ユニット１０６に記録する形態であってもよい。

この一連の動作をリアルタイムに制御し、各ブロックの処理を最適化する役割は、ＣＰＵ２１５によって行われる。すなわち、一般的な表現で言われる制御プログラム（ファームウェア）によるプログラム動作である。制御プログラム（ファームウェア）は、静的な情報として、通常はＲＯＭ２１４に格納されている。本実施形態のカメラ１０１は、起動時から必要に応じて、このＲＯＭ２１４より制御プログラム（ファームウェア）を読み出し、ＣＰＵ２１５で処理することにより、全体の動作が行われる。

ＣＰＵ２１５で処理される制御プログラム（ファームウェア）は、これ以外にもいくつかの処理機能を担っており、たとえば、先に説明した撮影レンズユニット２０１の動作の指示を行って、ズーム動作（焦点距離の移動）やオートフォーカスといった処理を行う。
また、図１を用いて説明したように、カメラユーザインターフェース１０２である録画の開始や停止を操作するボタンが押されたことを検知し、動画撮影のための一連の処理を開始するといった処理もＣＰＵ２１５で処理される。
不揮発性メモリ２１１は、たとえば、撮影パラメータを保管する目的で利用される。
通信回路２１３は、図１におけるカメラ通信モジュール１０７に相当する回路である。

さて、ここまでカメラ１０１の映像をビューア１０９に表示しながらビューア１０９よりカメラ１０１の操作を行う流れを説明してきた。しかしながら、ここまでの説明では、撮像から表示までの時間的なずれについては、一切言及していない。実際には、様々な理由により、この時間的なずれが発生する。撮像から表示までの時間的なずれの発生要因は、主に、次の様な点である。

第１に、ネットワークによる伝送遅延が発生する。ネットワーク的に近い距離にカメラ１０１とビューア１０９が存在する場合、このような伝送遅延は映像フレームに比較して小さなものとなるが、インターネットなどを介した通信の場合には、伝送遅延は、無視できない大きさとなる場合がある。

第２に、ネットワークによるデータ遅延や揺らぎに合わせて、送信・受信側共に一定の映像データをバッファリングする必要があるということも遅延の原因となる。

第３に、映像の符号化処理に伴う遅延が発生する場合がある。映像圧縮・伸長・符号化は、先に例示したMPEG-2のような予測符号化形式の場合には特に時間がかかる方法である。もちろん、JPEGのような形式であっても一定の処理時間を必要とする。加えて、予測符号化形式では、予測フレームと呼ばれる前または後ろの映像フレームデータを用いた処理を行うため、その利用する映像フレームデータがなければ処理できない。こうしたことも、遅延の原因となる。

第４に、映像データの記録形式や伝送形式（一般には、これらは広くコンテナ形式とも呼ばれることがある）に映像を加工する時間も遅延の原因となる。すなわち、処理がしやすいように、一定のデータ量を塊としてひとつのデータにまとめるための時間が必要な場合がある。

このような背景により、撮像から表示までの時間的なずれが発生する。こうした時間をここではプレイアウト時間と呼ぶことにする。プレイアウト時間は、狭義には、再生開始から表示までの時間を意味する場合が多いが、ここではネットワーク伝送に伴う時間も含めた時間として定義する。

図３は、プレイアウト時間とズーム操作に関する遅延の影響を説明するタイミング図である。左から右への２つの矢印は、それぞれ、カメラ１０１とビューア１０９の時間の経過を示す。

カメラ１０１は、ビューア１０９からの指示を受けてTc(0)の時間に映像の送信を開始する。先に示したプレイアウト時間により、ビューア１０９でTc(0)の時間の映像が表示されるのは、Tv(0)の時間である。ここに、カメラ１０１とビューア１０９の時間が異なることに注意されたい。実時間におけるTc(0)とTv(0)の時間差がプレイアウト時間である。
図３には、便宜上、カメラ１０１の時間を用いて定期的な時間間隔の目安としてのTc(15)、Tc(30)、Tc(45)を記載した。これらの括弧の中に示した番号がフレーム番号と考えてもよい。

ここで、本発明が解決する課題を図３を用いて簡潔に説明しておく。
ビューア１０９におけるカメラ１０１へのズーム指示がTv(14)に発生したと仮定する。ズーム指示は、カメラ１０１の時間であるTc(18)に通知される。図３では、Tc(18)がTv(14)より実時間で後となることを仮定している。

これは、一般的なネットワークの遅延が発生していることを仮定したものである。ネットワークが充分に高速であれば、Tc(18)はTv(14)に極めて近い時間であり、映像のフレーム間隔からは無視できる小さな量となる可能性もある。カメラ１０１は、ズーム開始の指示を受けてTc(18)にズーム操作を開始し、この例では、Tc(33)にズームを終了している。

一方、ビューア１０９においては、プレイアウト時間が存在するため、ズームされた映像は、Tv(18)から再生されることになる。Tc(18)からTc(33)のズーム区間は、ビューア１０９においては、Tv(18)からTv(33)に相当する。

この時、ビューア１０９の利用者は、ズーム指示をTv(14)に行ったにも関わらず、実際にズームが開始されるのはTv(18)の時刻である。すなわち、ここに、プレイアウト時間もしくはそれ以上のタイムラグが発生する。換言すれば、Tc(15)の時間の映像をTv(14)の時間で見ながらズーム操作を行ったにも関わらず、実際にズーム処理が行われた映像は、Tc(18)ということになる。

ここで、この課題に対するビューア１０９の処理の一例を、フローチャートを用いて説明する。
図４は、第１の実施形態におけるひとつの処理例を示すフローチャートである。このフローチャートの各処理は、映像に関する操作要求をビューアユーザインターフェース１１０がカメラ１０１に映像操作指示を送信することに応じて実行される。本実施形態においては、ビューアアプリケーションモジュール１１１が有するＲＯＭに格納されているプログラムをＲＡＭに展開し、ＣＰＵが実行することにより実現する。

最初に、プレイアウト時間取得処理を行う（Ｓ４０１）。プレイアウト時間の取得は、あらかじめ設定しておいてもよいし、以前の実際の計測された時間を保存しておいたデータから取得してもよい。あるいは、映像データを受信しながら実際のネットワーク遅延時間やカメラ１０１の特性に合わせて動的に取得するようにしてもよい。ビューア１０９から送信される要求は、映像データの部分領域の拡大または縮小を行うことを指示する映像拡大縮小要求がある。

次に、ズーム速度を取得する処理を行う（Ｓ４０２）。本実施形態では、ビューア１０９からカメラ１０１に対してズーム開始および終了のコマンドを発行し、ズーム中にはコマンドを発行しないものと仮定する。もちろん、ズームコマンドを発行し続けている間のみズーム動作を行うように設計してもよい。また、ズーム速度が可変であってもよい。ズーム速度が動的に変化する場合においても、その変化を含めてズーム速度が取得できればよい。

本説明においては、説明の複雑さを回避するため、あらかじめプレイアウト時間やズーム速度が一定値として取得できるものとして説明を行う。また、対象となる映像フレームの番号、映像フレームの位置、映像フレームの時間、プレイアウト時間の一部もしくはすべての情報をビューア１０９からカメラ１０１に送信するようにしてもよい。
また、プレイアウト時間の取得（Ｓ４０１）とズーム速度の取得（Ｓ４０２）の順番が逆であってもよい。これらの順序やタイミングは、本実施形態の説明において、便宜上設定したものである。本実施形態において、操作要求に従ってカメラ１０１が操作に要する時間、もしくは速度を取得する処理を操作処理速度取得処理とする。

ビューア１０９は、続いて映像データの取得（Ｓ４０３）と、映像データのデコード（Ｓ４０４）を行う。これらの処理を行うことにより、ビューア１０９において、映像を表示する準備ができたことになる。

次のステップは、ズーム中であるか否かの判断（Ｓ４０５）である。ビューア１０９は、ズームコマンドを発行しているため、ズーム開始を行ったか否かを知ることができる。すなわち、図３で示した、Tv(14)以降であるか否かを判断する。
ズーム中であれば、次にズーム開始状態か否かを判断する（Ｓ４０６）。すなわち、ズーム中となった最初の状態か否かの判断である。
ズーム開始状態であれば、ここで、ズーム開始の時間を記憶する（Ｓ４０７）。この開始時間は、後のステップで利用する。

同様に、次に、ズーム終了状態か否かを判断する（Ｓ４０８）。ここで注意すべき点は、前述で仮定したように、ズームの開始と終了のコマンドのみを発行して操作している点である。ズームの終了は、図３に明示していないが、カメラ１０１の時間におけるTc(33)に対応するビューア１０９側の時間である。
もちろん、便宜上、ズーム開始判断（Ｓ４０６）とズーム終了判断（Ｓ４０８)を逐次実行するように説明しているが、分岐判断の実際的な実装は異なっていてもよいことは言うまでもない。

一方、ズーム中であるか否かの判断（Ｓ４０５）でズームしていない状態と判断した場合には、これら開始時間と終了時間をリセットして初期値に戻す（Ｓ４１０）。
次は、時間比較計算（Ｓ４１１）を実行する。この時間比較計算（Ｓ４１１）は、具体的には、次の４つの状態を得るための時間比較計算処理である。

すなわち、第１の状態は、ズーム開始時間からプレイアウト時間経過までの区間の状態である。第２の状態は、前述したズーム開始時間からプレイアウト時間経過までの区間以降からズーム終了時間までの区間の状態である。第３の状態は、ズーム終了時間からプレイアウト時間経過までの区間の状態である。第４の状態は、第１から第３の何れの状態でもない状態である。

別な表現をするならば、第１の状態は、ズーム開始コマンドを発行してから実際にカメラ１０１でズーム動作が行われ、プレイアウト時間が経過してズームされた映像がビューア１０９で表示可能となるまでの状態である。この状態は、ズーム開始後の遅延時間の区間の状態に相当する。

また、第３の状態は、ズーム終了コマンドを発行してから実際にカメラ１０１でズーム動作を停止し、その後プレイアウト時間が経過してズーム動作が終了した映像がビューア１０９で表示可能となるまでの状態である。この状態は、ズーム終了後の遅延時間の区間の状態に相当する。

これらの時間比較計算（Ｓ４１１）の結果を元に、第１の状態であるか否かを判断する（Ｓ４１２）。これは、ズーム開始後の遅延時間内であるか否かを判断することである。
ズーム開始後の遅延時間内であれば、ズーム速度を元に映像の拡大倍率（１）を設定する（Ｓ４１３）。

ここまでズーム速度の詳細については、何ら説明してこなかった。ズーム速度は、たとえば、１秒あたり３倍の拡大率といった拡大率の時間経過に従った変化量（微分）と定義してもよい。従って、たとえば、ズームコマンド発行後３３ミリ秒経過した時点での拡大率を1.１倍とするような計算を行い、倍率を設定する。あるいは、あらかじめ速度と経過時間と倍率の対応表を内部に保持し、所定の時間経過した時点でその倍率を設定してもよい。

また、同様に、時間比較計算Ｓ４１１の結果を元に、第３の状態であるか否かを判断する（Ｓ４１４）。これは、ズーム終了後の遅延時間内であるか否かを判断することである。
ズーム終了後の遅延時間内であれば、ズーム速度を元に映像の拡大倍率（２）を設定する（Ｓ４１５）。ここでの拡大倍率は、Ｓ４１３で設定した倍率設定(１)と類似ではあるが異なるものである。Ｓ４１５における倍率設定(２)では、ズーム速度がマイナスであるとして拡大率を計算する。この詳細例については、後に説明する。

なお、ここでは、第２の状態と第４の状態に対する倍率設定は行っていないが、これは次のような実装を行ったものと仮定しているからである。すなわち、Ｓ４１３で設定された倍率が第２の状態では維持され、Ｓ４１５で設定された倍率は最終的に１倍と変化し、第４の状態で維持されている。従って、時間比較計算（Ｓ４１１）の結果を元に前述した４つの状態を設定し、それらの状態に従って倍率設定を行うよう実装してもよい。この点についても、後に説明する。

これらの処理の後、映像のレンダリング処理（表示処理）を行う（Ｓ４１６）。レンダリング（Ｓ４１６）においては、Ｓ４０４でデコードされた映像に対し、設定された倍率で映像の拡大・縮小を行い、表示用映像データを作成する。これにより、ビューアユーザインターフェース１１０に映像が表示される。
最後に、映像取得処理が終了したか否かを判断し（Ｓ４１７）、まだ継続していれば（ＮＯ）、再び映像データ取得（Ｓ４０３）を行う。

続いて、図５を用いて、ビューア１０９におけるレンダリング（Ｓ４１６）における拡大処理の様子を示す。
図５においては、図３と同様に、左から右への２つの矢印で、カメラ１０１とビューア１０９の時間の経過を示している。ただし、簡略化のため、ズーム開始コマンドの遅延は無視できるほど小さいとして記載した。

カメラ１０１の時間軸において、１点鎖線で記載したグラフは、送信データの拡大率を示す。ここで縦軸は、拡大率であって、ズーム速度ではないことに注意されたい。すなわち、初期状態からの拡大率を縦軸にとっている。また、縦軸の原点は１倍（拡大しない）であることにも注意されたい。

ここでは、送信データの拡大率は、ズーム指示の時点からズーム終了の時点まで大きくなり、ズーム終了後は一定としている。その後、再びズーム指示（ズームアウトによる拡大率縮小）により拡大率が低下し、最終的には、初期の状態より小さな状態（光学的にはより焦点距離が短い広角の状態）となって、ズーム終了となっている。

一方、ビューア１０９の時間軸においては、先に説明したプレイアウト時間が発生しているため、カメラ１０１で１点鎖線に対応した映像は遅れて受信されている。この遅延した状態でビューア１０９の時間軸にはグラフを記載した。なお、ビューア１０９の時間軸上にある破線は、プレイアウト時間がない場合の映像であって、比較用に参考として記載しているものである。ビューア１０９の時間軸に実線で示したグラフは、送信データの倍率である。この倍率は、図４のフローチャート内で、Ｓ４１３の倍率設定(１)やＳ４１５の倍率設定(２)で設定する倍率に他ならない。

送信データの倍率を示す特性図における最初の上昇区間５０１は、図４のフローチャートの説明における第１の状態となっている区間である。この上昇区間５０１は、ズーム（ここでは拡大）コマンドをカメラ１０１に送信したものの、実際のズーム処理を行った映像が送られてくる以前の状態である。このため、カメラ１０１のズーム速度に等しい速度で拡大するよう倍率を設定し、レンダリング時に拡大処理を行う。

区間５０２は、第２の状態であり、カメラ１０１において実際にズーム処理が開始されている状態であるため、倍率は一定に維持される。
最初の下降区間５０３は、ズーム終了をカメラ１０１に指示したものの、プレイアウト時間により、依然としてズーム処理を行った映像が送られて来ている状態である。すなわち、図４のフローチャートの説明における第３の状態となっている区間である。この下降区間５０３においては、ビューア１０９が受信している映像データは依然として拡大している一方、ズーム終了を指示しているため、上昇区間５０１とは逆に拡大率が低減するよう設定される。

区間５０４は、図４のフローチャートの説明における第４の状態となっている区間である。
区間５０５は、上昇区間５０１と同等の処理を行う区間であるが、拡大率が１倍より小さなズームアウト処理の区間となっている。この区間５０５は、一見すると区間５０３と等価に見えるが、拡大率が１倍より小さいという点を除けば、図４のフローチャートの説明における第１の状態であることは明白である。同様に、区間５０６は、図４のフローチャートの説明における第２の状態となっている。

ここで、ズームアウト時（区間５０５などの領域）における画像処理について、付加的な説明を加えておく。
ズームイン、すなわち映像拡大の場合には、映像を拡大した結果フレームの外となった領域の映像は、単に廃棄してよい。この領域は表示外であり、ビューア１０９の利用者はこれを見る必要がない。一方、ズームイン、すなわち画像縮小の場合には、表示フレーム内に元映像が縮小されるため、周辺領域に映像が存在しない領域が発生する。

このような場合には、画像補完といった手法を用いることができる。映像が存在しない領域の補完処理の詳細については、様々な手法があるが、映像処理手法そのものは本技術の本質ではないため、ここでは詳しい説明を省略する。
一例をあげるならば、元映像の外縁領域にある映像ピクセルを用いて、表示領域に合わせた補完映像を作成したり、画像ぼかしや外挿を行ったりする方法がある。また、プレイアウト時間を積極的に用いて、処理中の映像フレームの後の映像を用いることも可能である。

本実施形態においては、カメラ１０１での映像生成からビューア１０９での映像表示までに要する時間をプレイアウト時間として定義し、その遅延を課題のひとつとしている。プレイアウト時間が発生する要因については先に説明した通りであるが、たとえばＮフレームに相当する時間をプレイアウト時間に追加してもよい。この場合は、実際の不可避な遅延時間に加え、Ｎフレームに相当する時間が遅延として加わることになる。

区間５０６の領域においては、受信データの倍率は一定となるが、追加した遅延時間分の映像データはすでにビューア１０９で取得済みである。このため、欠けた周辺領域の映像の補完を行うために前のＮフレーム分の映像を用いることができる。
なお、本実施形態においては、MPEG-2のような圧縮映像（動画）を中心に説明を行ってきた。しかしながら、たとえばJPEGのような静止画についても同様に処理が可能なことは明らかである。

さらに、カメラ１０１で生成されるライブ映像を主体に説明してきたが、蓄積映像についても適用が可能である。すでにデジタルズームといった光学系によらない映像ズーム処理は広く利用されている。蓄積された画像の一部空間領域（映像フレームの空間的な一部）を伝送するような例においては、本発明の適用は特に容易である。
以上説明してきたように、本実施形態によれば、操作要求をしてから実際に操作要求の結果が反映された映像データを受信するまでの期間、ビューア１０９側で操作要求の結果と同様となるように映像変更を行うようにした。これにより、プレイアウト時間のような遅延となる時間が発生していても、ズーム指示のような映像変更をリアルタイムに行うことができる。

（第２の実施形態）
前述した第１の実施形態の説明においては、プレイアウト時間の取得（Ｓ４０１）に関し、３つの方法を例示した。すなわち、あらかじめ設定しておく、以前の実際に計測された時間を用いる、実際のネットワーク遅延時間やカメラ１０１の特性に合わせて動的に取得する、といった方法である。

本実施形態においては、このプレイアウト時間の取得（Ｓ４０１）を行わない形態について説明する。なお、全体のシステム的な構成は第１の実施形態と同様であるため、その説明は省略する。

図６は、第２の実施形態におけるひとつの処理例を示すフローチャートである。このフローチャートは、ビューアアプリケーションモジュール１１１が有するＲＯＭに格納されたプログラムをＲＡＭに展開し、ＣＰＵが実行することにより実現する。
最初に、ズーム速度を取得する処理を行う（Ｓ４０２）。このステップは第１の実施形態で説明した内容と同様である。このステップは、本実施形態においては必ずしも必須のステップではないが、典型的な例のひとつとして記載した。後の説明では、このステップを用いない場合についても言及する。

次に、ズームデータ取得（Ｓ６０１）を実行する。ここでのズームデータとは、ビューア１０９からのズームコマンドを受信したカメラ１０１が生成するズーム状態を示す情報である。本実施形態においては、カメラ１０１は、ズームコマンドを受けてズームを開始すると映像データとともに、ズームの状態をビューア１０９に通知する。通知の手段は、専用の通信パケットを用いてもよいし、映像データの一部に付与してもよい。

続いて、ビューア１０９は、映像データの取得（Ｓ４０３）と映像データのデコード（Ｓ４０４）を行う。これらの処理は、第１の実施形態で説明した内容と同様である。ただし、先に説明したズームデータ取得（Ｓ６０１）において、ズームデータが映像データに付与される場合には、映像データの取得（Ｓ４０３）とズームデータ取得（Ｓ６０１）は同時に行われてもよい。

ズーム状態計算（Ｓ６０２）は、ズームデータ取得（Ｓ６０１）で取得したズームデータとビューア１０９から発行したズームコマンドの情報からズーム状態を計算するステップである。ズーム開始コマンドをカメラ１０１に向けて発行したがズームデータにズーム動作が記録されていない場合。あるいは、ズーム開始コマンドをカメラ１０１に向けて発行したがカメラ１０１からのズームデータを受信していない場合、ズーム状態は、第１の実施形態で説明した第１の状態である。つまり、ズーム開始コマンドを発行してから実際にカメラ１０１でズーム動作が行われ、ズームされた映像がビューア１０９で表示可能となるまでの状態である。

もし、ズーム開始コマンドをカメラ１０１に向けて発行し、ズームデータにズーム動作が記録されている場合、ズーム状態は、第１の実施形態で説明した第２の状態である。
また、ズーム終了コマンドをカメラ１０１に向けて発行し、ズームデータにズーム動作が記録されている場合、ズーム状態は、第１の実施形態で説明した第３の状態である。
その他の場合は、第１の実施形態で説明した第４の状態である。このようにして、ズーム状態を計算する。

得られたズーム状態に対し、次に、開始遅延状態か否かを判定する（Ｓ６０３）。この判定は、第１の実施形態で説明した第１の状態であるか否かの判定（Ｓ４１２）に等価である。開始遅延状態であれば（ＹＥＳ）、Ｓ６０４で倍率設定(３)を実行する。

同様に、終了遅延か否かを判定し（Ｓ６０５）、終了遅延状態であれば（ＹＥＳ）、Ｓ６０６で倍率設定(４)を実行する。しかる後に、レンダリングＳ４１６および終了判定Ｓ４１７を実行する。

ところで、Ｓ６０４の倍率設定(３)とＳ６０６の倍率設定(４)については、詳しく説明しなかった。これらは、ズーム速度取得（Ｓ４０２）を実行した場合には、それぞれ、第１の実施形態に示したＳ４１３の倍率設定(１)とＳ４１５の倍率設定(２)と同等であればよい。

一方、ズーム速度取得（Ｓ４０２）を実行しない場合でも、異なる方法で倍率設定を行うことが可能である。たとえば、先に説明したカメラ１０１が生成するズーム状態を示す情報に、ズーム速度もしくは倍率が含まれていればよい。また、ズーム状態を示す情報に含まれる情報が倍率である場合、たとえば起動時を1として、起動時からの変化で倍率を表現してもよいし、前の状態からの変化率で表現してもよい。
このように、本実施形態では、プレイアウト時間の取得（Ｓ４０１）をせずとも第１の実施形態と同様の結果を得ることができる。

（第３の実施形態）
第１の実施形態と第２の実施形態では、カメラ１０１で映像を同時に記録することについて言及していなかったが、本発明は、ビューア１０９に適用するとともに、カメラ１０１への映像記録についても適用することが可能である。本実施形態では、この点を中心に説明する。

ビューア１０９で受信映像の拡大処理を行った場合、ビューア１０９では、厳密に拡大処理を適用した映像フレームを特定することが可能である。たとえば、図３に示したTv(14)の時間は、再生中のフレーム番号と紐付けることができる。Tv(14)のフレーム番号を１４とするようにTv(N)のNをフレーム番号と仮定すれば、フレーム番号１４から拡大処理を開始し、フレーム番号１８までが第１の実施形態および第２の実施形態で記載した第１の状態である。

従って、プレイアウト時間もしくは、プレイアウト時間に相当するフレーム数をズームコマンドに付与する。そして、カメラ１０１側でこれを記録することで、カメラ１０１上に記録された映像に対し、第１の実施形態や第２の実施形態で説明したビューア１０９と同じ効果を得ることができる。

図７は、コマンドの一例を示す図である。
最初のカラム７０１は、コマンドそのものを表している。この図においては、ズーム機能を指示するZOOMのみが表現されている。
カラム７０２は、コマンドに対する動作機能を表している。
カラム７０３は、コマンドの対象となったフレーム番号を表している。フレーム番号の代わりに時間を用いてもよい。時間を用いる場合には、あらかじめカメラ１０１とビューア１０９の時間を一致させておくか、あらかじめ時間の差異を交換しておくことが望ましい。
カラム７０４は、コマンドや機能に付随するパラメータである。

最初の行７０５は、カメラ１０１に対するズーム開始を支持するコマンドの例である。コマンドはZOOMであり、機能として、ズームを開始するSTARTが記載されている。フレームに記載した１４は、対象となったフレーム番号である。パラメータに記載した５は、プレイアウト時間に対応するフレーム数である。

行７０５は、次のような内容をカメラ１０１に通知する。すなわち、ズームを開始すること、開始フレーム番号は１４であること、ビューア１０９が使用するプレイアウト時間に相当するフレーム数は５であることなどである。
同様に、行７０６は、ズームの終了を示すコマンドの例である。機能には終了を示すSTOPが記載されており、対象となったフレーム番号は１９である。

行７０７は、第２の実施形態で説明した、ズームの状態を示すデータである。コマンドZOOMに対して、開始されたことを示すSTARTEDが記録されている。実際に開始したフレーム番号は１８である。また、この例では、実際の遅延が４フレームであったことをパラメータに記録している。この行７０７は、カメラ１０１からビューア１０９に送信される情報であることに注意されたい。

カメラ１０１は、このようなコマンドを受送信することで、ビューア１０９が、実際にズームされた映像の受信より先に拡大処理を行っていることを知ることができる。また、これらのコマンドから得られたデータを映像とともにカメラ１０１内で記録しておくことで、実際のズーム処理とは異なるビューア側の時間で映像の拡大処理などを行うことができる。

もちろん、カメラ１０１側では、単にコマンドを記録するだけでなく、コマンドに従った映像拡大処理などを行った結果として、映像をトランスコード（transcode）するなどして記録してもよい。

（第４の実施形態）
第４の実施形態では、カメラ１０１が回転雲台などに搭載されており、ビューア１０９からの映像移動要求の指示で回転動作や移動動作を行う場合について説明する。
回転動作は、たとえば、パンやチルトといった横方向や縦方向などのカメラの回転を伴う動作である。

移動動作は、たとえば、カメラがレールなどの上を移動することにより、結果として映像が移動する動作である。また、これらは、広い領域を撮影する高精細センサと、高精細センサから得られた映像の一部を切り出して符号化を行う、所謂デジタル・パン・チルトといった機能で実現される場合もある。

このような場合でも、第１の実施形態から第３の実施形態で説明したズームと同様の課題が発生する。パン動作（横方向回転動作）であってもプレイアウト時間は発生するため、たとえば右３０度回転を角速度15度毎秒といったパン動作指示を行った場合、明らかに角度ずれが発生する。この例では、プレイアウト時間が0.5秒であれば、7.5度のずれが発生することは容易に計算できる。

ズーム動作の場合の例では、拡大率で映像の処理を行うことを説明したが、パン動作の場合には、角度ずれ量から得られる画素ずらし量として移動量計算を行えばよい。回転角と画素の関係は、たとえば、特許文献２に記載された方法などを用いることができる。また、回転などにより、映像が存在していない領域が発生する可能性があるが、その領域については、画素補完などを行ってもよい。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、前述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１ カメラ
１０２ カメラユーザインターフェース
１０３ カメラアプリケーションモジュール
１０４ 撮像モジュール
１０５ カメラ記録モジュール
１０６ カメラ記録ユニット
１０７ カメラ通信モジュール
１０８ ネットワーク回線
１０９ ビューア
１１０ ビューアユーザインターフェース
１１１ ビューアアプリケーションモジュール
１１２ ビューア通信モジュール
１１３ ビューア記録モジュール
１１４ ビューア記録ユニット

Claims (17)

1. 映像送信装置から映像データを受信するとともに、映像に関する操作を映像送信装置に対して指示する映像処理装置において、
   前記映像送信装置から映像データを受信する映像受信手段と、
   前記映像受信手段が受信した映像データを表示する映像表示手段と、
   前記映像表示手段に表示する映像に関する操作要求を前記映像送信装置に送信する映像操作指示手段とを有し、
   前記映像表示手段は、映像に関する操作要求を送信してから実際に操作要求に応じて変更された映像データを受信するまでの期間、操作要求の結果と同様となるよう映像を変更する映像変更手段を有し、
   前記映像表示手段は、前記映像変更手段により変更された映像を表示することを特徴とする映像処理装置。
2. 前記操作要求に従って映像送信装置が操作に要する時間もしくは速度を取得する操作処理速度取得手段をさらに有し、
   前記映像変更手段は、前記操作処理速度取得手段により取得された操作に要する時間もしくは速度に合わせて映像を変更することを特徴とする請求項１に記載の映像処理装置。
3. 前記映像送信装置が映像を送信してから映像を表示するまでの遅延時間を取得するプレイアウト時間取得手段をさらに有し、
   前記映像変更手段は、
   前記映像に関する操作要求の送信から遅延時間が経過するまでは映像操作に要する時間もしくは速度に従って映像を変更し、遅延時間が経過した後は映像操作を適用する量を一定とし、映像操作してから所定の時間が経過した後は、映像操作に要する時間もしくは速度の逆となるように映像の変更を行うことを特徴とする請求項１または２に記載の映像処理装置。
4. 映像送信装置から操作要求に従った処理を開始もしくは終了したことを示す操作要求の処理状況通知を受信する処理状況通知受信手段をさらに有し、
   前記映像変更手段は、
   操作要求の送信から前記処理状況通知受信手段が処理の開始を示す操作要求の処理状況通知を受信するまでは、操作に要する時間もしくは速度に合わせて映像を変更し、処理の開始を示す操作要求の処理状況通知を受信した後は、映像操作を適用する量を一定とし、
   前記映像操作の終了を指示する操作要求の送信から処理状況通知受信手段が処理の終了を示す操作要求の処理状況通知を受信するまでは、操作に要する時間もしくは速度の逆となるように映像変更を行うことを特徴とする請求項１〜３の何れか１項に記載の映像処理装置。
5. 前記映像に関する操作要求は、映像の拡大または縮小を行うことを指示する映像拡大縮小要求であって、
   前記映像変更手段は、映像の拡大を指示する場合には、受信した映像データの部分領域を拡大するよう処理を行い、映像の縮小を指示する場合には、受信した映像データを縮小するとともに、映像データの外縁領域の映像データを用いて表示領域に合わせて補完映像を生成することを特徴とする請求項１〜４の何れか１項に記載の映像処理装置。
6. 前記映像に関する操作要求は、映像の領域の移動を行うことを指示する映像移動要求であって、
   前記映像変更手段は、映像の領域の移動量を計算する移動量計算手段をさらに有し、
   前記移動量計算手段により計算された移動量に従って映像を移動させるよう処理を行うことを特徴とする請求項１〜４の何れか１項に記載の映像処理装置。
7. 前記映像操作指示手段は、映像に関する操作要求に加えて、対象となる映像フレームの番号、映像フレームの位置、映像フレームの時間、プレイアウト時間の一部もしくはすべての情報を前記映像送信装置に送信することを特徴とする請求項１〜６の何れか１項に記載の映像処理装置。
8. 請求項１〜７の何れか１項に記載の映像処理装置と映像送信装置とから構成される映像処理システムであって、
   前記映像送信装置は、請求項７に記載の操作要求の情報を映像とともに記録することを特徴とする映像処理システム。
9. 映像送信装置から映像データを受信するとともに、映像に関する操作を映像送信装置に対して指示する映像処理方法において、
   前記映像送信装置から映像データを受信する映像受信工程と、
   前記映像受信工程において受信した映像データを表示装置に表示する映像表示工程と、
   前記表示装置に表示する映像に関する操作要求を前記映像送信装置に送信する映像操作指示工程とを有し、
   前記映像表示工程は、映像に関する操作要求を送信してから実際に操作要求に応じて変更された映像データを受信するまでの期間、操作要求の結果と同様となるよう映像を変更する映像変更工程を有し、
   前記映像表示工程は、映像変更工程において変更された映像を表示することを特徴とする映像処理方法。
10. 前記操作要求に従って映像送信装置が操作に要する時間もしくは速度を取得する操作処理速度取得工程をさらに有し、
    前記映像変更工程は、前記操作処理速度取得工程において取得した操作に要する時間もしくは速度に合わせて映像を変更することを特徴とする請求項９に記載の映像処理方法。
11. 前記映像送信装置が映像を送信してから映像を表示するまでの遅延時間を取得するプレイアウト時間取得工程をさらに有し、
    前記映像変更工程は、
    前記映像に関する操作要求の送信から遅延時間が経過するまでは映像操作に要する時間もしくは速度に従って映像を変更し、遅延時間が経過した後は映像操作を適用する量を一定とし、映像操作してから所定の時間が経過した後は、映像操作に要する時間もしくは速度の逆となるように映像の変更を行うことを特徴とする請求項９または１０に記載の映像処理方法。
12. 映像送信装置から操作要求に従った処理を開始もしくは終了したことを示す操作要求の処理状況通知を受信する処理状況通知受信工程をさらに有し、
    前記映像変更工程は、
    操作要求の送信から、前記処理状況通知受信工程において、処理の開始を示す操作要求の処理状況通知を受信するまでは、操作に要する時間もしくは速度に合わせて映像を変更し、処理の開始を示す操作要求の処理状況通知を受信した後は、映像操作を適用する量を一定とし、
    前記映像操作の終了を指示する操作要求の送信から、前記処理状況通知受信工程において、処理の終了を示す操作要求の処理状況通知を受信するまでは、操作に要する時間もしくは速度の逆となるように映像変更を行うことを特徴とする請求項９〜１１の何れか１項に記載の映像処理方法。
13. 前記映像に関する操作要求は、映像の拡大または縮小を行うことを指示する映像拡大縮小要求であって、
    前記映像変更工程は、映像の拡大を指示する場合には、受信した映像データの部分領域を拡大するよう処理を行い、映像の縮小を指示する場合には、受信した映像データを縮小するとともに、映像データの外縁領域の映像データを用いて表示領域に合わせて補完映像を生成することを特徴とする請求項９〜１２の何れか１項に記載の映像処理方法。
14. 前記映像に関する操作要求は、映像の領域の移動を行うことを指示する映像移動要求であって、
    前記映像変更工程は、映像の領域の移動量を計算する移動量計算工程をさらに有し、
    前記移動量計算工程において計算された移動量に従って映像を移動させるよう処理を行うことを特徴とする請求項９〜１２の何れか１項に記載の映像処理方法。
15. 前記映像操作指示工程は、映像に関する操作要求に加えて、対象となる映像フレームの番号、映像フレームの位置、映像フレームの時間、プレイアウト時間の一部もしくはすべての情報を前記映像送信装置に送信することを特徴とする請求項９〜１４の何れか１項に記載の映像処理方法。
16. 映像送信装置から映像データを受信するとともに、映像に関する操作を映像送信装置に対して指示する映像処理方法をコンピュータに実行させるプログラムにおいて、
    前記映像送信装置から映像データを受信する映像受信工程と、
    前記映像受信工程において受信した映像データを表示装置に表示する映像表示工程と、
    前記表示装置に表示する映像に関する操作要求を前記映像送信装置に送信する映像操作指示工程とをコンピュータに実行させ、
    前記映像表示工程は、映像に関する操作要求を送信してから実際に操作要求に応じて変更された映像データを受信するまでの期間、操作要求の結果と同様となるよう映像を変更する映像変更工程を有し、
    前記映像表示工程は、前記映像変更工程において変更された映像を表示することを特徴とするプログラム。
17. 請求項１６に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。

Images