(57)【要約】【課題】  実時間性を維持しながら映像配信サービスを提供できるようにすること。【解決手段】  現在複数の画像処理が要求されている場合において、当該複数の画像処理のうちの一の画像処理に係るパラメータを画像処理手段に供給し、当該一の画像処理に要した処理能力を計測する（Ｓ５０４）。次に、前記計測の結果に基づいて、他の画像処理に要する処理能力を予測し（Ｓ５０５）、その予測結果に基づいて、所定の単位時間内に処理を完了可能な画像処理を前記他の画像処理から選択し（Ｓ５０７）、選択した各画像処理に係るパラメータを画像処理手段に順次供給する（Ｓ５０８〜Ｓ５１０）。【選択図】  図５
2005318411.tif 000002
【特許請求の範囲】
【請求項１】
画像データの画像処理を行う画像処理手段と、
現在複数の画像処理が要求されている場合において、当該複数の画像処理のうちの一の画像処理に要した処理能力を計測する計測手段と、
前記計測の結果に基づいて、前記複数の画像処理のうちの前記一の画像処理を除く他の画像処理に要する処理能力を予測する予測手段とを有し、
前記画像処理手段は、前記予測の結果に基づいて、所定の単位時間内に処理を完了可能な画像処理を前記他の画像処理から選択し、前記選択した各画像処理を実行することを特徴とする画像処理装置。
【請求項２】
前記予測手段による予測の結果に対する実際の計測結果との誤差に応じて、前記予測手段の予測条件を修正する手段を更に有することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
画像データの画像処理を行う画像処理手段と、
現在要求されている一の画像処理に要した処理能力を計測する計測手段と、
前記計測の結果に基づいて、現在要求されている他の画像処理に要する処理能力を予測するとともに、新たな画像処理の要求を更に受けた際に、当該新たな画像処理に要する処理能力を予測する予測手段と、
前記計測手段による計測の結果および前記予測手段による予測の結果に基づいて、前記一の画像処理および前記他の画像処理に加え前記新たな画像処理を所定の単位時間内に処理可能かどうかを判断し、その判断結果に応じて当該新たな画像処理の要求の許否を決定する制御手段と、
を有することを特徴とする画像処理装置。
【請求項４】
前記制御手段の処理によって前記新たな画像処理の要求を受け入れた場合、前記制御手段は、当該新たな画像処理に係る画像データの解像度が前記一の画像処理に係る画像データの解像度よりも小さいときは、当該新たな画像処理を前記一の画像処理に変更することを特徴とする請求項３に記載の画像処理装置。
【請求項５】
前記所定の単位時間は、１フレームの画像データの入力に要する時間であることを特徴とする請求項１から４までのいずれかに記載の画像処理装置。
【請求項６】
前記制御手段は、処理速度が低下した場合、画像処理の優先度に関する情報に基づいて、処理すべき画像処理を選択することを特徴とする請求項１または２に記載の画像処理装置。
【請求項７】
請求項１から６までのいずれかに記載の画像処理装置を含み、前記所定の単位時間内に複数の映像ストリームをネットワークを介しクライアントに配信する映像配信システム。
【請求項８】
画像データの画像処理を行う画像処理装置の制御方法であって、
現在複数の画像処理が要求されている場合において、当該複数の画像処理のうちの一の画像処理に要した処理能力を計測するステップと、
前記計測の結果に基づいて、前記複数の画像処理のうちの前記一の画像処理を除く他の画像処理に要する処理能力を予測するステップと、
前記予測の結果に基づいて、所定の単位時間内に処理を完了可能な画像処理を前記他の画像処理から選択し、選択した各画像処理に係るパラメータに基づいて画像処理を行うステップと、
を有することを特徴とする画像処理装置の制御方法。
【請求項９】
画像データの画像処理を行う画像処理装置の制御方法であって、
現在要求されている一の画像処理に要した処理能力を計測するステップと、
前記計測の結果に基づいて、現在要求されている他の画像処理に要する処理能力を予測するステップと、
新たな画像処理の要求を更に受けた際に、当該新たな画像処理に要する処理能力を予測するステップと、
計測された前記一の画像処理に要した処理能力、予測された前記他の画像処理に要する処理能力、および、予測された前記新たな画像処理に要する処理能力に基づいて、前記一の画像処理および前記他の画像処理に加え前記新たな画像処理を所定の単位時間内に処理可能かどうかを判断し、その判断結果に応じて当該新たな画像処理の要求の許否を決定するステップと、
を有することを特徴とする画像処理装置の制御方法。
【請求項１０】
請求項８または９に記載の画像処理装置の制御方法を実現するためのプログラム。
【請求項１１】
請求項１０に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置およびその制御方法に関し、例えば、ネットワークを利用して映像ストリームを配信する画像配信システムに適用されるものである。
【背景技術】
【０００２】
近年、インターネットが普及し、WWW ( World Wide Web ) 等による情報発信が一般的に行なわれるようになってきた。その様な中で、映像を撮影し、その映像をリアルタイムにネットワーク上に発信する機能を持つシステムが出現している。
【０００３】
一方、ネットワークを利用した画像の配信を行うにあたっては、様々な圧縮方式が用いられている。例えば、広く一般的に用いられているものでは静止画像の圧縮方式としてはJPEG（Joint Photograph coding Experts Group）がある。また動画像の圧縮方式としては、このJPEG方式を動画像の配信に応用したM-JPEG(Motion-JPEG)や、MPEG2及びMPEG4（Moving Picture Experts Group phase 2 / 4）などが存在する。これらのうち、どの方式を用いて画像の配信を行うかは、映像配信側のシステム構成、及びユーザの選択などによって様々に考えられる。
【０００４】
更に、最近では、様々なデータ転送速度の異なる複数種類の通信回線が提供されている。また、配信された映像を見るための端末も、携帯電話クラスの比較的小さな画面のものから、PCを用いてその表示画面の一部を利用するもの、専用端末を用いるものなど様々である。画像データを配信するシステムを構築する側は、これらユーザの多種多様な要求に応えてサービスを提供することが求められる。なおかつ、カメラの遠隔からの操作を実現したネットワークカメラサーバにおいては、リアルタイムかつ低遅延であることが求められる。
【０００５】
ここで、ユーザの多種多様な要求に応じてサービスを提供するような仕組みを持った従来の映像配信システムの第１の例としては、図１７に示すような画像処理装置２００を持つように構成されたものがある。
【０００６】
図１７に示すような画像処理装置２００では、ビデオカメラなどから供給される画像データが画像処理ユニット２１０ａ，ｂ，ｃのそれぞれにフレーム単位で与えられる。画像処理ユニット２１０ａ，ｂ，ｃはそれぞれ、解像度変換部２０１ａ，ｂ，ｃ、コーデック処理部２０２ａ，ｂ，ｃ、ＦＩＦＯ２０３ａ，ｂ，ｃを含む構成である。画像処理ユニット２１０ａ，ｂ，ｃのそれぞれでは、ユーザの要求に応じてユニットごとに異なる処理パラメータが与えられており、そのパラメータに応じた処理がそれぞれ独立して行われるが、それぞれのコーデックはある特定の符号化方式にのみ対応している。
【０００７】
この従来の映像配信システムの第１の例では、画像処理装置２００に含まれる画像処理ユニットの数が３であり、ユーザの要求する画像処理の種類がその数を超える場合には、それに対応することができない。一般に、従来の映像配信システムのように、画像処理ユニットを複数持つことで複数の画像処理の要求に対応しようとする場合は、その処理ユニット数によってサービスできる内容が制限を受けることになる。処理ユニットの数を増やせば制限は緩くなるが、映像配信システムの撮影機能をもつネットワークカメラサーバなどは一般に小型化を要求されるものであり、そこに実装できる処理ユニットの数は基板面積や発熱量などによって制限を受けるので、実際には処理ユニットの数は限られたものになる。
【０００８】
この処理ユニット数の制限を外すためには、画像処理をプログラマブルに変えることのできる画像処理部を持つシステムが必要になる。
【０００９】
そのようにした従来の映像配信システムとして、画像処理装置は予めＲＯＭに格納している各種変換アルゴリズムを必要に応じて読み出し、ＤＳＰにそのアルゴリズムの処理を行わせることによってユーザの多様な要求に答えようとするものが存在する（例えば特許文献１参照。）。
【００１０】
【特許文献１】特開平６−１２５４１１号公報（第８頁、第１図、及び第１０頁、第４図）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
一方、リアルタイムに映像を撮影し、その映像を監視用途などに蓄積及び配信に利用する場合には、撮像装置から入ってくる映像を取りこぼすことは許されない。例えば、１秒間に３０フレームの映像を撮影するＮＴＳＣ準拠のビデオカメラ入力から映像入力を得る場合、１フレームの処理に許される時間は原則１／３０秒に過ぎず、その中で先に述べた多種多様なユーザの要求に応えることがシステムに求められる。
【００１２】
また、とりわけ映像撮影部を遠隔から操作できることのできるネットワークカメラサーバにおいては、リアルタイムかつ低遅延であることが求められる。
【００１３】
しかしながら、特許文献１に記載の技術では、単純に複数の画像処理がアルゴリズムに従って時分割的に並行して処理されるのみであり、それによって実時間で処理が完了するという保証はない。たとえば、複数の処理を同時に行っている場合に、入力される画像信号などの変動に伴う画像処理部の処理に要する処理時間の変動などを検出することができず、実時間性を保ちながらサービスを実現することの保証ができなかった。また、新規にユーザからサービスの要求が発生した場合に、その要求に対して全て応じてよいかどうかを実時間性の保証の面から判断することができなかった。
【００１４】
本発明は、少なくとも上記の課題を解決するためになされたもので、例えば実時間性を維持しながら映像配信サービスを提供できるようにすることを目的としている。
【課題を解決するための手段】
【００１５】
上記した課題は、本発明の画像処理装置およびその制御方法によって解決される。本発明の一側面に係る画像処理装置は、画像データの画像処理を行う画像処理手段と、現在複数の画像処理が要求されている場合において、当該複数の画像処理のうちの一の画像処理に要した処理能力を計測する計測手段と、前記計測の結果に基づいて、前記複数の画像処理のうちの前記一の画像処理を除く他の画像処理に要する処理能力を予測する予測手段とを有し、前記画像処理手段は、前記予測の結果に基づいて、所定の単位時間内に処理を完了可能な画像処理を前記他の画像処理から選択し、前記選択した各画像処理を実行することを特徴とする。
【００１６】
本発明の別の側面に係る画像処理装置は、画像データの画像処理を行う画像処理手段と、現在要求されている一の画像処理に要した処理能力を計測する計測手段と、前記計測の結果に基づいて、現在要求されている他の画像処理に要する処理能力を予測するとともに、新たな画像処理の要求を更に受けた際に、当該新たな画像処理に要する処理能力を予測する予測手段と、前記計測手段による計測の結果および前記予測手段による予測の結果に基づいて、前記一の画像処理および前記他の画像処理に加え前記新たな画像処理を所定の単位時間内に処理可能かどうかを判断し、その判断結果に応じて当該新たな画像処理の要求の許否を決定する制御手段とを有することを特徴とする。
【００１７】
本発明の更に別の側面は、画像データの画像処理を行う画像処理装置の制御方法に係り、現在複数の画像処理が要求されている場合において、当該複数の画像処理のうちの一の画像処理に要した処理能力を計測するステップと、前記計測の結果に基づいて、前記複数の画像処理のうちの前記一の画像処理を除く他の画像処理に要する処理能力を予測するステップと、前記予測の結果に基づいて、所定の単位時間内に処理を完了可能な画像処理を前記他の画像処理から選択し、選択した各画像処理に係るパラメータに基づいて画像処理するステップとを有することを特徴とする。
【００１８】
本発明の更に別の側面は、画像データの画像処理を行う画像処理装置の制御方法に係り、現在要求されている一の画像処理に要した処理能力を計測するステップと、前記計測の結果に基づいて、現在要求されている他の画像処理に要する処理能力を予測するステップと、新たな画像処理の要求を更に受けた際に、当該新たな画像処理に要する処理能力を予測するステップと、計測された前記一の画像処理に要した処理能力、予測された前記他の画像処理に要する処理能力、および、予測された前記新たな画像処理に要する処理能力に基づいて、前記一の画像処理および前記他の画像処理に加え前記新たな画像処理を所定の単位時間内に処理可能かどうかを判断し、その判断結果に応じて当該新たな画像処理の要求の許否を決定するステップとを有することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、リアルタイム性に重点をおいたモニタリングシステムに利用されるネットワークカメラサーバのような映像配信システムにおいて、ユーザから要求されている画像処理装置に対する処理が、所定の単位時間内に終了するかどうかを判断することが可能になり、映像配信システムにおいて、複数のユーザからの様々な解像度・圧縮方式・品質での接続要求が重なった場合に、どの処理であれば実時間内に処理を終わらせることができるかの判断をすることができるようになる。その結果、実時間性を失うことなく、複数のユーザに映像配信サービスを提供することが可能になる。
【００２０】
更に、複数の処理ユニットを並列に実装すること無しにサービスを実現するので、実時間性を失わない範囲でサービスの内容（映像圧縮方式の種類・解像度・Ｑ値・フレームレート）を予め処理ユニット数などで制限すること無しにサービスの提供をすることが可能になる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
【００２２】
（第１の実施形態）
図１は、本実施形態に係る画像処理装置を示す構成図である。図１において、画像処理装置１０には処理制御部１００と画像処理部２００の大きく分けて２つの構成要素が存在する。
【００２３】
画像処理部２００には、まず、 処理順序制御部１０１により、処理制御部１００内部のパラメータレジスタ１０４に保存されているパラメータの値がパラメータ設定信号１５２として与えられる。次いで画像処理部２００には、処理順序制御部１０１によって処理開始信号１５４が与えられる。ここで指示された処理が画像圧縮処理であった場合には、入力された画像データ１５０を設定されたパラメータの値に基づいて処理し、符号化データ１５１を出力する。一方、指示された処理が画像伸張処理であった場合には、入力された符号化データ１５１を設定されたパラメータに基づいて伸張し、画像データ１５０として出力する。これらの処理を実施している期間、画像処理部２００は処理ビジー信号１５３をアサートする。処理能力計測部１０２は処理ビジー信号１５３がアサートされている時間を計測する。
【００２４】
処理能力計測部１０２は、その計測結果を処理能力予測部１０３に提供する。処理能力予測部１０３はその処理を実施した際のパラメータと、処理能力計測結果から、処理を要求されている後続の画像処理に関してどのくらいの処理時間が必要になるかを予測して、処理順序制御部１０１に提示する。その提示を受けた処理順序制御部１０１は、要求されている処理の優先順位とその処理に必要になる画像処理部２００の処理能力から、次にどの処理を実施するかを決定して、画像処理部２００に次の処理を指示する。
【００２５】
図２に画像処理部２００の詳細な構成を示す。
【００２６】
図２において、画像処理部２００は解像度変換部２０１、コーデック処理部２０２、ＦＩＦＯ２０３、バッファ２０４を有する。入力された画像データ１５０は、一旦バッファ２０４に例えばフレーム単位で蓄積される。解像度変換部２０１より先の部分は、与えられたパラメータに基づく画像処理を１つの映像入力データ単位（例えば１フレーム単位）で取り扱う。解像度変換部２０１は、指示された処理が画像圧縮処理であった場合には、まず、入力された画像データ１５０をバッファ２０４より読み出し、パラメータレジスタ１０４より与えられたパラメータ設定信号１５２に基づいて、必要に応じて解像度変換処理を行う。このバッファ２０４への画像データ１５０の入力は画像処理部２００の外部からの入力の速度に支配されるのに対して、バッファから解像度変換部２０１以降への画像データの転送におけるｂｉｔ幅及び転送速度を画像データ１５０の入力速度に比べて大きくすることができる。よって、画像処理部２００は画像データ１５０の１フレームを入力するのために必要となる時間の間に、解像度変換部２０１、コーデック処理部２０２、ＦＩＦＯ２０３を処理能力の限界まで利用して、同じ入力データフレーム画像を用いて複数回の異なるパラメータに基づく画像圧縮処理が可能である。
【００２７】
解像度変換部２０１は、解像度変換が終わったデータをコーデック処理部２０２に、パラメータによって指定されている符号化形式に応じた単位で渡す。コーデック処理部２０２は、入力されたデータを画像処理用メモリ１２を必要に応じて用いながら圧縮処理し、作成した圧縮済データをＦＩＦＯ２０３に出力する。ＦＩＦＯ２０３は一定量以上の圧縮済データが溜まるなどのイベントを契機にそのデータを符号化データ１５１として画像処理部２００の外に送出する。
【００２８】
なお、解像度変換された画像データはコーデック処理部２０２へ送られる以外に、画像処理用メモリ１２に一時的に蓄えられる。これは、後続の処理で同一の入力画像データに対して同じ解像度変換処理を求められる場合に備えるものである。もし、後続の処理で先に実施したものと同一の解像度処理を求められた場合には、解像度変換部２０１は画像処理用メモリ１２から先に実施した解像度変換処理の結果を読み出し、それをコーデック処理部２０２に供給する。
【００２９】
一方、指示された処理が画像伸張処理であった場合には、データの流れる方向が逆になる。入力された符号化データ１５１は、まずＦＩＦＯ２０３ に蓄えられる。コーデック処理部２０２は、パラメータレジスタ１０４より与えられたパラメータ設定信号１５２に基づいて、入力される符号化データの符号化形式を判断し、ＦＩＦＯ２０３からそのデータを順次読み出して伸張処理を実施する。伸張処理された画像データは、表示用に求められている解像度に解像度変換部２０１で必要に応じて変換され、バッファ２０４に蓄積される。バッファ２０４に蓄積された画像データ１５０は、画像を出力するのにふさわしいデータレートの画像として画像処理部２００の外に出力される。
【００３０】
ここでは、バッファ２０４は画像処理部の内部に存在するものとして記述したが、場合によっては画像処理用メモリ１２と同じメモリを使用することも可能である。図示はしないが、その場合は、入力される画像データ１５０は解像度変換部２０１を経由せず、直接画像処理用メモリ１２に一旦蓄えられ、解像度変換部２０１は蓄えられたデータを画像用メモリ１２から読み出しながら処理をすることになる。
【００３１】
なお、これらの圧縮もしくは伸張処理を実施している期間、画像処理部２００のコーデック処理部２０２が処理ビジー信号１５３をアサートする。
【００３２】
図３は、図１に示した画像処理装置１０を内蔵する映像配信サーバと、その映像配信サーバを用いて構成されるモニタリングシステムの構成例を示したものである。
【００３３】
１は映像配信サーバであり、カメラ６、もしくは映像配信サーバ１に付属するレンズ及びＣＣＤ等によって構成されるカメラ１８から入力された映像信号をキャプチャ・圧縮して、公衆回線網４やＬＡＮ回線網５等のネットワーク上に送出する。送出された映像データは公衆回線網４に接続される携帯端末３もしくはＬＡＮ回線網５に接続される端末２（例えば２ａ〜２ｃ）等のクライアントによって受信され、それぞれのビューワ３１もしくは２１によって表示される。また、場合によっては、相手側端末から送信された映像データを受信、伸張して接続されるモニタ７によって表示をする。
【００３４】
以下、映像配信サーバ１の内部構成とその基本動作等について詳細に説明する。
【００３５】
まず、カメラ６、もしくは映像配信サーバ１に付属するレンズ及びＣＣＤ等によって構成されるカメラ１８から映像信号が入力画像変換装置１１によって取り込まれる。このとき、カメラ６から与えられるデータはＮＴＳＣ／ＰＡＬ／ＳＥＣＡＭなどの方式に基づいたアナログ映像信号であるとする。このようなアナログ映像信号は入力画像変換装置１１でＡ／Ｄ変換した後、画像処理装置１０の入力として適当なディジタルデータ形式、例えばＹ：Ｕ：Ｖ＝４：２：２の形式に変換される。また、映像入力部１８から出力される映像データは、既にディジタル形式になっているものの、カメラ１８から映像データが出力される信号線がＬＶＤＳ（Low Voltage Differential Signaling）形式に準拠するものであるため、入力画像変換装置１１で一旦受信し、画像処理装置１０が扱いやすいパラレルデータの形式に変換される。そして、画像処理装置１０に対して画像データ１５０として入力される。
【００３６】
画像データ１５０を取得した画像処理装置１０は一旦バッファ２０４で画像データを保持した後、その映像をユーザによって指示された方式に基づいて圧縮する。例えば、Ｍ−ＪＰＥＧ方式やＭＰＥＧ４方式に基づいて圧縮をかける。圧縮後の符号化データ１５１はマイクロプロセッサ１３を経由してマイクロプロセッサ１３に接続されている演算用ＲＡＭ１５に格納される。
【００３７】
符号化データが演算用ＲＡＭ１５に転送されると、マイクロプロセッサ１３は、ＦｌａｓｈＲＯＭ１４に格納されたプログラムに従って、演算用ＲＡＭ１５から符号化データを取り出し、ネットワークに向けて配送するために適当な大きさに分割する、ヘッダを付けるなどの処理を行う。そして、ＰＣカードＩ／Ｆ１７に挿された通信用ＰＣカード１７１（モデムカードやＩＳＤＮカードなど）を介して公衆回線網４上の携帯端末などへ、もしくはＬＡＮインタフェース１６を介してＬＡＮ回線網５上の他の端末等へ符号化データを送信する。
【００３８】
また、マイクロプロセッサ１３は符号化データをネットワーク上に配信するだけでなく、蓄積することも可能である。例えば、ＰＣカードスロット１７に蓄積用ＰＣカード１７２（ハードディスクカードもしくはＦｌａｓｈＲＯＭカードなど）を挿せば、その蓄積用ＰＣカード１７２上に映像データを記録することが可能になる。また、蓄積先としては、ＦｌａｓｈＲＯＭ１４や維持的な蓄積としては演算用ＲＡＭ１５を選択することも可能である。
【００３９】
なお、映像配信サーバ１は商用ＡＣ電源９１からＡＣ−ＤＣアダプタ９０を介して直流にされた電力を電力供給部９において取得し、それをさらに装置内部のＩＣなどが動作するに相応しい電圧と安定度に電力供給部９で変換したうえで、システム全体に電力を供給している。
【００４０】
まず、この映像配信サーバ１が、画像処理装置１０の性能を予測しながら、複数のユーザに対して映像を配信する場合の動作について図１から３を参照しながら図４から６を用いて説明する。
【００４１】
図４は、この映像配信サーバ１が現在要求されている処理のパラメータリストの一例を示す図である。このパラメータリストは図示のように、処理番号、優先度、処理種別、符号化方式、解像度、品質１および２、接続数に関するパラメータが記述される。なおここでは、優先度を示す値が小さいものほど優先度が高いとする。また、このパラメータリストの内容は画像処理装置１０のパラメータレジスタ１０４内部にもコード化して含有されているものとする。本実施形態では、図４のパラメータリストに示されているとおり、処理番号０〜５の６つの処理が要求されていることとし、各処理番号と優先度とが一致しているものとする。
【００４２】
図４では、優先度０の処理が存在している（処理番号０）。この処理は基準処理として取り扱われ、ユーザからの処理要求の有無にかかわらず、全ての処理に先立ってまずこの画像の処理が実施される。その上で、この基準処理を行うのに要した画像処理部の処理量が測定され、それに基づき実時間内の処理が可能になるように後続の処理１から５の実施が検討されることになる。
【００４３】
図５は、画像処理装置１０における処理を示すフローチャートである。
【００４４】
映像配信サーバ１にはカメラ１８から連続的に画像データがフレーム単位で入力されており、フレームの更新間隔は１／３０秒、入力される画像の解像度はＳＶＧＡ（８００ｘ６００）であるとする。まず、入力画像変換装置１１から、画像処理装置１０ にフレーム単位の画像が入力される。バッファ２０４に１フレーム分のフレーム画像データが蓄積された段階で、そのタイミングに同期した新しい単位時間の開始が示される（ステップＳ５０１）。
【００４５】
本実施形態では、上記のとおり優先度０の処理０が存在する。この処理は全ての画像処理に先立って実施されることが決まっているので、予め ［Ｍｏｔｉｏｎ−ＪＰＥＧによる圧縮、解像度３２０ｘ２４０、品質Ｑ＝５０］等の処理０に関するパラメータ情報が、パラメータレジスタ１０４からパラメータ設定信号１５２として、解像度変換部２０１、及びコーデック処理部２０２に与えられる（ステップＳ５０２）。
【００４６】
これにより、まず解像度変換部２０１は、処理開始信号１５４によって処理開始の指示が与えられると、バッファ２０４に蓄えられた画像データに対して、８００ｘ６００から３２０ｘ２４０への解像度変換の処理を実施し、解像度変換した結果の画像をコーデック処理部２０２に送り出す。この場合はＭｏｔｉｏｎ−ＪＰＥＧの処理であるので、８ｘ８ｂｉｔのブロックの単位で順次コーデック処理部２０２に入力していく。コーデック処理部２０２は、ブロック化されたデータ解像度変換部２０１から受け取って処理を開始すると、処理ビジー信号１５３をアサートする。そして、与えられた品質パラメータＱ＝５０を用いてＭｏｔｉｏｎ−ＪＰＥＧ符号化を実施し、加工した符号化データをＦＩＦＯ２０３に入力する。ＦＩＦＯ２０３に入力された符号化データは演算用ＲＡＭ１５宛に転送される（ステップＳ５０３）。
【００４７】
処理番号０で予定された３２０ｘ２４０の画面全てに対応する画像データの処理が終了すると、処理ビジー信号１５３がネゲートされる。これに応じて処理能力計測部１０２は、処理ビジー信号１５３がアサートされていた時間を計測し、この処理番号０の画像処理に必要だった時間を算出する（ステップＳ５０４）。
【００４８】
処理番号０の画像処理に要した時間がｔ０であったとする。その計測結果を受けて予測性能計算部１３２は、後続に要求されている処理１〜５の内容をパラメータレジスタ１０４から取り出して、それらにかかる処理時間の予測を行う（ステップＳ５０５）。
【００４９】
たとえば、優先度０である基準処理の符号化処理がＭｏｔｉｏｎ−ＪＰＥＧの圧縮であるとする。その処理の解像度をＲ０、その処理に要した時間をｔ０とするとき、解像度Ｒｎである処理ｎの処理の処理時間ｔｎは以下のようにして求めることができる。
【００５０】
ｔｎ ＝ (Ｒｎ ／ Ｒ０) ×ｔ０ × Ｍ × Ｑ      （１−１）
ただし、Ｍ：経験的に求められる符号化方式における要因ファクタ、
Ｍ＝１（符号化方式がＭｏｔｉｏｎ−ＪＰＥＧである場合）、
Ｍ＝１．０５（符号化方式がＭＰＥＧ４、処理フレームがＩフレームのとき）、
Ｍ＝１．７５（符号化方式がＭＰＥＧ４、処理フレームがＰフレームのとき）、
Ｑ：品質ファクタ （ここでは簡略化のために全ての場合において１とする）
【００５１】
ｎ＝１〜５について、上式を計算すると、処理１〜５のそれぞれにかかる処理時間が予測される。次いで、このようにして予測した処理時間がすべて単位時間内に処理可能かどうかを判断する（ステップＳ５０６）。この場合のステップＳ５０６の判断は例えば次式によって行われる。
【００５２】
（ｔ０＋Ｐ）＋（ｔ１＋Ｐ）＋…＋（ｔｎ＋Ｐ） ＜  処理単位時間    （１−２）
ただし、Ｐ：画像処理部へのパラメータ設定等に必要となる時間、
ｎ：要求されている処理の処理番号
【００５３】
本実施形態では、フレームの更新間隔が１／３０秒であるので、処理単位時間は１／３０秒となり、その時間内に全ての処理を終える必要がある。ｎを順に増やして行き、現在要求を受け付けているところまで増やしても式１−２が成立した場合にはステップＳ５０６の条件が成立してＹＥＳの分岐に進むが、ｎの数を最後まで増やさないうちにこの式が成立しなくなった場合には、ＮＯの分岐へと進む。
【００５４】
この処理の予測の様子を図６に示す。図６の第１のフレーム時間の処理では、処理性能予測の結果、処理４の処理までが処理単位時間内に処理されることが予測される（すなわち式１−２が成立する）が、処理５の処理まで実施すると所定の時間内に全ての処理が終了しないと判断されている（ステップＳ５０６→ＮＯ）。
【００５５】
このような場合には、ポリシーに基づく処理優先度の決定が行われる（ステップＳ５０７）。仮に、ここでの映像配信サーバのサービスポリシーが優先度優先ポリシーであり、実時間処理に間に合わない処理は実施しないというものであった場合には、処理優先度の一番低い５の処理が第１のフレーム時間では実施しないという決定がなされる。そして、その結果を受けて処理５を除いた残りの処理について、順次処理が行われていくことになる（ステップＳ５０８〜Ｓ５１０）。そして、処理４の処理が終了した時点で画像処理部２００は次の新しい単位時間が始まるまで待機状態に入ることになる（ステップＳ５１１）。
【００５６】
なお、図６の第２のフレーム時間の処理では、処理３の圧縮処理がＭＰＥＧ４のＩフレーム処理であったため、第１のフレーム時間に比べて処理時間が短くなり、処理５までの処理を全て実施することが可能と判断され（Ｓ５０６→ＹＥＳ）、全ての要求された処理が実施されている。
【００５７】
また、図４において処理２はＭ−ＪＰＥＧの伸張処理であるが、その処理が行われる際の処理の流れを、再び図２及び図３を参照して説明する。
【００５８】
図３において、端末２Ｃに取り付けられているカメラ２２によって映像が撮影され、それがＭｏｔｉｏｎ−ＪＰＥＧ方式によって圧縮され、端末２ＣからＬＡＮ回線網５を経由して映像配信システム１に入力されているものとする。映像配信システム１はＬＡＮ Ｉ／Ｆ １６を介してＭｏｔｉｏｎ−ＪＰＥＧ形式で符号化された映像データを受け取り演算用ＲＡＭ１５に格納する。マイクロプロセッサ１３はネットワーク通信用のヘッダを取り除いた後、画像処理装置１０が符号化データ入力として受入可能な形に整えてから、符号化データを画像処理部２００のＦＩＦＯ２０３ に対して送り込み、同時にパラメータレジスタ１０４に対して要求する処理の内容を伝達する。画像処理部２００は所定の処理の順番が来ると、コーデック処理部２０２を伸張処理に利用して符号化データ１５１を伸張して解像度変換部２０１に出力する。本実施形態ではそのまま解像度は変換せずに出力されるので、伸張された画像データ１５０はバッファ２０４を介して出力画像変換装置１９に対して渡され、そこでＤ／Ａ変換された後、外部接続モニタ７に表示される。
【００５９】
以上のようにして、一連の処理が行われる。
【００６０】
なお、本実施形態においては、画像処理装置１０における処理制御部１００の各構成要素はそれぞれ独立した制御部として記述したが、この処理制御部１００として専用のコントローラ等を準備して、ソフトウェアによって実現する方法を取ることも可能である。更に言えば、処理制御部１００として専用のコントローラを準備せずに、処理制御部の全ての処理をマイクロプロセッサ１３上で専用のソフトウェアを用いる形で実現することも可能である。
【００６１】
（第２の実施形態）
第１の実施形態においては、処理能力予測部における予測性能の計算は式１−１、１−２に示したような固定された予測式によって行われていた。しかし現実には撮影する映像の内容等によってその予測結果と実際の処理時間に食い違いが生じてくることもあり得る。
【００６２】
そこで、本実施形態では、撮影対象の変化等による予測結果と実際の処理時間の相違を検出し、その差異を小さくするようにフィードバック系を入れた場合の例を、図１〜５を援用しつつ図７、図８を用いて説明する。図１〜５に関しては第１の実施形態と共通であるので、ここでは説明を省略する。
【００６３】
図７は、本実施形態における処理能力予測部１０３の構成例である。処理能力予測部１０３は予測結果比較部１３１、予測性能計算部１３２、及び予測用条件変数格納部１３３から構成されている。
【００６４】
図８Ａ、図８Ｂは、本実施形態における画像処理装置１０における処理を示すフローチャートである。
【００６５】
このフローチャートの「Ａ」で示された箇所は、本処理の初めに、図５の「Ａ」で示された箇所までのステップ（すなわち、ステップＳ５０１〜Ｓ５０７）と同様の処理が行われることを示している。したがってここではこれらの処理についての説明は省略し、ステップＳ８０１以降の処理から説明を始める。
【００６６】
図５の「Ａ」まで（すなわち、ステップＳ５０１〜Ｓ５０７）で次に処理するべき処理の内容が決まるので、その内容に従って画像処理部２００に対してパラメータレジスタ１０４からパラメータを設定する（ステップＳ８０１）。パラメータ設定が終了すると、 処理順序制御部１０１は、処理開始信号１５４を用いて画像処理部２００に対して次の処理を実施するように指示をする。
【００６７】
その指示を受けた画像処理部２００は画像処理を開始し、その処理を行っている間処理ビジー信号１５３をアサートする（ステップＳ８０２） 。処理能力計測部１０２は、処理ビジー信号１５３がアサートされている時間を計測する（ステップＳ８０３）。そしてその計測された処理時間と、その前にステップＳ５０５において予測性能計算部１３２によって予測されていた処理時間を、予測結果比較部１３１において比較する（ステップＳ８０４）。
【００６８】
予測された時間内に処理が終了していた場合には（ステップＳ８０４→ＹＥＳ）、処理はそのまま継続される。すなわち、予定された画像処理がすべて終了しているかどうかを確認し（ステップＳ８０７）、未実施の処理があるような場合には（ステップＳ８０７→ＮＯ）、次の処理を実施するために次の画像処理のパラメータ設定（ステップＳ８０１）に戻る。全ての予定された処理が実施されていた場合には、次の新しい単位時間が始まるまで待機状態に入ることになる（ステップＳ８０８）。
【００６９】
一方、予測された時間内に処理が終了していなかった場合には（ステップＳ８０４→ＮＯ）、まず、後続で要求されている処理が次の単位時間の開始までに処理可能かどうかの検討を行う（ステップＳ８０５）。処理可能であった場合には（ステップＳ８０５→ＹＥＳ）、以前にスケジューリングされたとおりの処理の流れに戻って処理を実施していく（ステップＳ８０７）。一方、後続で要求されている処理が次の単位時間の開始までに処理可能でなかった場合には（ステップＳ８０５→ＮＯ）、ポリシーに基づく処理優先度の決定が再度実施されることになる（ステップＳ８０６）。これは、優先度の低い処理が長期間処理されないことを防ぐためである。
【００７０】
画像処理部２００の処理の流れは概ね上記のようなものであるが、処理能力予測部１０３としては、同時に予測用条件変数の確認作業を実施する必要がある。このため、処理はステップＳ８０３から図８ＢのステップＳ８０９にも分岐し、処理能力計測部１０２が処理ビジー信号１５３のアサートされている時間を計測した結果を受けて、計測された処理時間が予測性能計算部１３２において先に計算した結果と一定誤差の範囲内で一致したかどうかを判断する（ステップＳ８０９）。実測値と予測値とが一定誤差の範囲内で一致していた場合には（ステップＳ８０９→ＹＥＳ）、予測用条件変数には修正を加えないで終了する（Ｓ８１１）。一方、実測値と予測値とが食い違っていた場合には（ステップＳ８０９→ＮＯ）、その差異を小さくするように予測用条件変数に修正が加えられる。修正を加える方法としては、例えば以下のようなものが考えられる。
【００７１】
まず、第１の実施形態における処理時間の予測式を以下のように変更する。優先度０である基準処理の符号化処理をＭｏｔｉｏｎ−ＪＰＥＧであるとする。その処理の解像度をＲ０、その処理に要した時間をｔ０とするとき、解像度Ｒｎである処理ｎの処理の処理時間ｔｎは以下のようにする。
【００７２】
ｔｎ ＝ (Ｒｎ ／ Ｒ０) × ｒ × ｔ０ × Ｍ × ｍ× Ｑ ×Ｃ    （２−１）
ただし、Ｍ：符号化方式における要因ファクタ、
Ｍ＝１（符号化方式がＪＰＥＧである場合）、
Ｍ＝１．０５＋ｉ（符号化方式がＭＰＥＧ４、処理フレームがＩフレームのとき）、
Ｍ＝１．７５＋ｐ（符号化方式がＭＰＥＧ４、処理フレームがＰフレームのとき）、
ｒ：解像度の比に関する処理時間の補正項、
ｉ：ＭＰＥＧ４，Ｉフレーム処理時の処理時間の補正項、
ｐ：ＭＰＥＧ４，Ｐフレーム処理時の処理時間の補正項、
ｍ：ＭＰＥＧ４，Ｐフレーム処理時における動きベクトルの検索範囲制限などに関する処理時間の補正項、
Ｑ：品質ファクタ （Ｍｏｔｉｏｎ−ＪＰＥＧのＱ値などの違いによる補正項）、
Ｃ：圧縮処理と伸張処理の違いに基づく補正項
【００７３】
第１の実施形態の式１−１は、式２−１においてｉ＝ｐ＝０、ｒ＝Ｍ＝ｍ＝Ｑ＝Ｃ＝１であり、これが固定であったと考えることができる。
【００７４】
上記補正項のうちｍは、カメラの首振りなどの指示により撮影対象の画像に動きがあると予測される場合に、動きベクトルの検索範囲を制限することで処理速度を上げることができるが、その要素を加味するための補正項である。
【００７５】
上記補正項の内容を予測値と実測値との差異が小さくなるように補正をかけることで、予測用条件変数の修正が実施される。
【００７６】
（第３の実施形態）
上述の第１及び第２の実施形態は現在処理要求を受け付けている処理に関するものであったが、映像のリアルタイム性を保った配信という観点から、新規の処理要求に対してどのようにサービス要求に対して対応するべきかという観点からも考える必要がある。
【００７７】
また、第１の実施形態のように、基準処理として優先度０のユーザからの処理要求の有無にかかわらず特定の決め打ちの処理を実施するということは、場合によっては資源の有効利用に繋がらない場合もある。
【００７８】
これに対し本実施形態では、新規のサービス要求への対応の仕方に関して、処理能力の予測処理を判断基準に利用した場合の例と、受け入れた新規の処理によって基準処理を変更する場合の例を図９、図１０、図１１を用いて示す。それ以外の図は第１及び第２の実施形態と共通であるので、それらに対する説明は省略する。ただし、ここではカメラ１８から入力されている入力画像の解像度はＸＧＡサイズ（１０２４×７６８）であるとする。
【００７９】
図９Ａは、ある時刻１において映像配信サーバ１が要求されている処理のパラメータリストである。時刻１の時点では、処理０〜２までの３つの処理が画像処理装置１０上で実施されている。ここに、新規の処理３の要求がユーザから発生した場合の処理を図１０のフローチャートを用いて説明する。
【００８０】
図１０において、新規処理サービスの要求が発生すると（ステップＳ１００１）、まず、画像処理装置１０では、現在受け付けている画像処理全体に要する処理能力の計測および／または予測を実施する（ステップＳ１００２）。これは、基準処理（時刻１の時点では処理０）の実測結果と、そこから導き出される他の処理の予測結果でも構わないし、新規サービス要求が待てるようであれば、現在受け付けている画像処理の全てについて実測した結果を用いてもよい。
【００８１】
一方、処理能力予測部１０３は、新規に処理を要求されている処理のパラメータと基準処理の実測結果とから、新規に要求された処理に要する画像処理部１０の処理能力の見積りを行う（ステップＳ１００３）。
【００８２】
その上で、新規に要求されている処理を受け入れても全ての処理を単位時間内に処理することが可能かどうかの見積りを行う（ステップＳ１００４）。本実施形態の場合は、比較的処理時間に余裕があるのと、要求された新規処理の解像度が小さいものであり、画像処理部の処理能力にあまり影響を与えないものであったことから（ステップＳ１００４→ＹＥＳ）、新規サービスの要求は受け入れられる（ステップＳ１００５）。
【００８３】
新規サービス要求が受け入れられると、優先度０の絶対的な基準処理が存在しない場合には、今度は新規に受け入れた処理（この場合は処理３）が基準処理としてふさわしいかどうかを判断する（ステップＳ１００６）。時刻１時点での基準処理は処理０が選定され、他の処理１，２に比べて１段高い優先度１が与えられていた。処理０と処理３を比較すると、同じＭｏｔｉｏｎ−ＪＰＥＧ処理であるが、処理０に比べて処理３の方が解像度が小さいことがわかる。ここで、この映像配信システム１の基準処理の選定ポリシーとして、解像度が小さいものの方が基準として好ましいというポリシーがあった場合には、処理３を基準処理として採用するべきであるという判断が下される（ステップＳ１００６→ＹＥＳ）。その場合、基準処理の変更が行われ（ステップＳ１００７）、処理の優先度も変更される。基準が変わったために、それと同時に予測用条件変数の修正も実施される（ステップＳ１００８）。そして、一連の新規処理サービスへの対応が終了することになる（Ｓ１００９）。
【００８４】
次いで、時刻１よりしばらく経過した時刻２時点において、映像配信サーバ１に３つの新規の処理要求が与えられた場合を考える。図９Ｂは時刻２において映像配信システム１が要求されている処理のパラメータリストである。時刻２の時点において処理としては処理０から処理３までの４つの処理が画像処理装置１０上で実施されている。図９Ａと比較して、基準処理が処理０から処理３に変更になったため、処理３の優先度が１、それ以外の処理の優先度が２に変更されている。
【００８５】
ここで、新規の処理４から６の要求がユーザから発生した場合の処理について図１０及び図１１を用いて説明する。
【００８６】
図１０のＳ１００１〜Ｓ１００３のステップを経て、新規に処理要求されたものの処理に要する時間の予測結果を図１１に示す。図９Ｂ及び図１１からわかるように、新規に処理を要求されたもののうち、処理４に関してはそれを実施することにより、単位時間内での処理が不可能になるので（ステップＳ１００４→ＮＯ）、新規処理サービスの要求は拒否される（ステップＳ１０１０）。一方、処理５に関してはその処理を追加して実施しても単位時間内での処理が可能であるという判断が図１１から下されるので（ステップＳ１００４→ＹＥＳ）、新規処理サービスとしての要求が受け入れられる。ただし、処理４は時刻２時点における基準処理である処理３に比べて解像度が大きいので、基準処理の変更は発生しない（ステップＳ１００６→ＮＯ）。
【００８７】
また、処理６に関しては、圧縮方式、解像度及び品質が処理０と同一であり、異なるのは要求フレームレートだけであるので、この場合、処理０で実施された画像圧縮処理の出力結果である符号化データを演算用ＲＡＭ１５の上でコピーしてネットワークに出力することで要求が満たされることがわかる。そのため、新規に画像処理装置に処理を設定しなくてもサービスが追加できるので、この処理６も新規処理サービスとして追加される。ただし、処理６はパラメータリストの上では処理０にマージされて、処理０の接続数が１０．５と示されることになり、処理６のエントリは消去される。
【００８８】
（第４の実施形態）
第１から第３の実施形態では、性能予測を行う際の基準処理として、実際の配信に用いられている画像圧縮処理が用いられていたが、基準処理の選び方にも様々な方法が考えられる。
【００８９】
例えば、この映像配信サーバ１において監視用の画像蓄積も同時に行っていた場合には、その処理を基準処理として採用することも可能である。監視用の映像蓄積を実施する際には、特に映像の取りこぼしを無くすために、実時間内に処理が終了することが必要であり、本提案における処理時間の予測による画像処理装置の負荷の制限は効果が大きい。そのような場合の例を図１２に示す。
【００９０】
図１２は本実施形態における要求されている処理のパラメータリストである。この例では処理１が監視用の映像蓄積ということで最優先の処理を実施されている。そのため、接続数が０であるにもかかわらず優先度０として取り扱われている。このような場合には、この処理１を性能予測の基準処理として取り扱うことがシステムの処理性能を有効に利用することになる。処理１によって処理された画像は蓄積用ＰＣカード１７２上に蓄積される。
【００９１】
なお、この例では、現在処理１は画像蓄積のみに利用されているが、この映像を配信に利用することが可能であることは言うまでも無い。
【００９２】
（第５の実施形態）
画像処理装置の処理性能が可変である場合にも、処理性能の予測機能は非常に有効である。そのような場合の例を図１３及び図１４を用いて説明する。
【００９３】
図１３は、画像処理装置の処理性能が可変である場合の映像配信サーバ１の構成例を示したものである。図１３の構成要素で図３と異なるのは、電源供給部にバッテリ９２が接続されており、電力供給部９に処理速度制御部９３が接続され、処理速度制御部９３から画像処理装置１０に対して画像処理部の処理速度を制御するための信号線が接続されていることである。
【００９４】
図１３において、電力供給部９は、映像配信サーバ１に関する電力供給がどのように実現されているかを監視している。そして、その電力が主としてバッテリ９２から供給されている場合には、バッテリ９２の消耗を抑えるべく映像配信システム１の消費電力を下げるため、処理速度制御部９３を用いて、画像処理装置１０に供給しているクロックの周波数を落とす等の制御を実施する。
【００９５】
画像処理装置１０は処理速度制御部９３によって供給されるクロックの周波数が落とされると画像処理能力が低下して、周波数が落とされる前に実施することが可能であった処理も全てを実施することが難しくなってくる。そのような場合を考慮した処理のパラメータリストを図１４に示す。ここでは、品質３のパラメータに実時間性への考慮を要求される処理かどうかのフラグを立てている。本実施形態では処理０と１に実時間性要求のパラメータが設定されている。処理の優先度としては処理０と処理２は同等であるが、さらにこのパラメータの存在により、画像処理装置１０の処理性能が低下しているような場合には、処理０と処理１が優先的に処理能力を分配されることになる。具体的には、まず、基準処理としての処理１の処理が行われ、その処理能力の測定結果から、処理１から処理５までの処理時間が予測され、実時間でのサービスができる範囲で処理０、２、３、４、５の順に画像処理装置１０の処理能力が分配されていくことになる。（処理４と５のどちらが優先されるかはこのパラメータリストの情報からだけでは判断できず、他の優先度ポリシーが利用される。）
【００９６】
（第６の実施形態）
第１〜５の実施形態においては主としてコーデック処理部２０２の処理が実施されていることを示す処理ビジー信号１５３を処理性能判断の基準としていたが、画像処理部２００の処理性能を決めるものはコーデック処理部２０２の利用状況だけとは限らない。そのような場合の例を図１５に示す。
【００９７】
図１５は本実施形態における画像処理部２００の構成を示したものである。図２と比較するとわかるように、図１５ではコーデック処理部２０２から出力される処理ビジー信号１５３以外に、ＦＩＦＯ２０３から出力されるＦＩＦＯビジー信号１５５が処理能力計測部１０２に入力されている。
【００９８】
ＦＩＦＯビジー信号１５５は、コーデック処理部２０２から出力された符号化データ１５１をマイクロプロセッサ１３に接続される演算用ＲＡＭ１５に対して転送する際に利用する内部バスの混み具合等を通知する信号線である。一般的にＭｏｔｉｏｎ−ＪＰＥＧ等の圧縮方法を用いる場合、圧縮後の画像の品質を調整するために品質パラメータであるＱ値を変化させると、コーデック処理部２０２から出力される符号化データ量もそれに伴って大きく変化する。そのため、符号化データを転送する際のバスの込み具合等もそのデータ転送量に応じて変化するが、場合によってはデータを１単位処理時間中に転送しきれない場合も発生し得る。そのような場合、コーデック処理部２０２での処理能力が十分であっても、結果的に処理の実時間性が失われることになる。ＦＩＦＯビジー信号１５５はそのような観点から、ＦＩＦＯ２０３と演算用ＲＡＭ１５との間の転送処理能力を示すために用いられる信号である。この信号はＦＩＦＯ２０３と演算用ＲＡＭ１５との間でのデータ転送が順調に行われているかどうか、ＦＩＦＯ２０３と演算用ＲＡＭの間で転送されているデータ量はどのくらいかなどの情報を処理能力計測部１０２に対して通知する。処理能力計測部１０２はこれらのデータ転送にかかわる処理情報とコーデック処理部２０２の利用状況を示す処理ビジー信号１５３の両方から、実際に処理に要している画像処理部２００の全体としての処理能力を判断し、その結果を処理能力予測部１０３に渡して利用することになる。
【００９９】
（第７の実施形態）
先に述べた実施形態では圧縮処理されるべく入力画像変換装置１１から画像処理装置１０に入力された画像データ１５１は全て一旦バッファ２０４に１フレーム分蓄積され、そこからデータを高速に読み出して処理することによって複数の画像処理を１フレーム分の画像を入力するのに要する単位時間内に実現していた。
【０１００】
これに対し本実施形態では、バッファ２０４に１フレーム分の画像蓄積を行うこと無しに、同等の処理を実現する場合の例として図１６を用いて示す。
【０１０１】
図１６では、図２及び図１５と異なり、バッファ２０４の代わりにラインバッファ２０５ａ及び２０５ｂが準備されている。これらのラインバッファ２０５ａ、２０５ｂは例えばＹ：Ｕ：Ｖ＝４：２：２のフォーマットに応じて入力される画像サイズの横方向最大値の２倍幅をもち、１６ライン分のデータを保存できるものである。本実施形態においてＸＧＡサイズのデータが画像データとして入力されるとすると、ラインバッファの大きさは１０２４×２＝２０４８であることから、２０４８ｂｙｔｅ×１６ライン分ということになる。
【０１０２】
画像データ１５０は映像データを１６ラインごとにラインバッファ２０５ａ、２０５ｂに交互に入力する。１６ライン分のデータがラインバッファにたまると、解像度変換部２０１はそのデータを高速に読み出し、圧縮処理に応じたブロック単位に変換してコーデック処理部２０２に与えると同時に、解像度変換処理を実施して要求されている圧縮処理用の解像度に変換する。解像度処理変換結果は画像処理メモリ１２に蓄積される。
【０１０３】
この場合、基準処理としては、データの読み出しの負荷を最小化するために、なるべく解像度の大きい処理を用いることが、全体の処理性能最適化の面から望ましい。また、このような処理を行う場合には、基準処理に基づく処理性能の予測等はこのラインバッファ単位で実施される。そして、ラインバッファ単位での基準処理が終了した段階で、予測した結果に応じて、画像用メモリ１２からコーデック変換部２０２は必要に応じた解像度のデータを読み出し、順次次の圧縮処理を行っていく。この場合、先頭のラインバッファで予測を行った結果が、同一フレームの他のラインバッファ単位での処理にも適用されることになる。もし、先頭のラインバッファでの予測した結果で同一フレームの他のラインバッファの処理をしている際に不都合が発生した場合には、不都合が発生した時点で処理の予測結果が見直され、その結果がそれ以降の同一フレームの処理に適用されることになる。
【０１０４】
（他の実施形態）
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【０１０５】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。
【０１０６】
従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。
【０１０７】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１０８】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１０９】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０１１０】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１１１】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１１２】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１１３】
【図１】本発明の実施形態に係る画像処理装置の構成を示す図である。
【図２】本発明の第１の実施形態に係る画像処理装置における画像処理部の詳細な構成を示す図である。
【図３】本発明の第１の実施形態における映像配信システムを用いたモニタリングシステムを示す図である。
【図４】本発明の第１の実施形態における映像配信システムに要求されている処理のパラメータリストの一例を示す図である。
【図５】本発明の第１の実施形態における画像処理装置における処理を示すフローチャートである。
【図６】本発明の第１の実施形態における処理性能予測処理を説明する図である。
【図７】本発明の第２の実施形態における処理能力予測部の構成を示す図である。
【図８Ａ】、
【図８Ｂ】本発明の第２の実施形態における画像処理装置における処理を示すフローチャートである。
【図９Ａ】、
【図９Ｂ】本発明の第３の実施形態における映像配信システムに要求されている処理のパラメータリストの例を示す図である。
【図１０】本発明の第３の実施形態における新規要求処理の受け入れの可否を判断する際の処理の流れを示すフローチャートである。
【図１１】本発明の第３の実施形態における処理性能予測の結果を示す図である。
【図１２】本発明の第４ の実施形態における映像配信システムに要求されている処理のパラメータリストの一例を示す図である。
【図１３】本発明の第５の実施形態における映像配信システムの構成を示す図である。
【図１４】本発明の第５の実施形態における映像配信システムに要求されている処理のパラメータリストの例を示す図である。
【図１５】本発明の第６の実施形態に係る画像処理装置における画像処理部の詳細な構成を示す図である。
【図１６】本発明の第７の実施形態に係る画像処理装置における画像処理部の詳細な構成を示す図である。
【図１７】従来の映像配信システムにおける画像処理装置の構成を示す図である。
【図１】
2005318411.tif 000003
【図２】
2005318411.tif 000004
【図３】
2005318411.tif 000005
【図４】
2005318411.tif 000006
【図５】
2005318411.tif 000007
【図６】
2005318411.tif 000008
【図７】
2005318411.tif 000009
【図８Ａ】
2005318411.tif 000010
【図８Ｂ】
2005318411.tif 000011
【図９Ａ】
2005318411.tif 000012
【図９Ｂ】
2005318411.tif 000013
【図１０】
2005318411.tif 000014
【図１１】
2005318411.tif 000015
【図１２】
2005318411.tif 000016
【図１３】
2005318411.tif 000017
【図１４】
2005318411.tif 000018
【図１５】
2005318411.tif 000019
【図１６】
2005318411.tif 000020
【図１７】
2005318411.tif 000021