JP3976864B2 - 映像サーバ及びその制御方法及び記憶媒体 - Google Patents
映像サーバ及びその制御方法及び記憶媒体 Download PDFInfo
- Publication number
- JP3976864B2 JP3976864B2 JP36123497A JP36123497A JP3976864B2 JP 3976864 B2 JP3976864 B2 JP 3976864B2 JP 36123497 A JP36123497 A JP 36123497A JP 36123497 A JP36123497 A JP 36123497A JP 3976864 B2 JP3976864 B2 JP 3976864B2
- Authority
- JP
- Japan
- Prior art keywords
- video
- video data
- image
- client
- delivery
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークを介してクライアントに向けて映像データを配送する映像サーバ及びその制御方法及び記憶媒体に関するものである。
【０００２】
【従来の技術】
近年、ネットワークを介して映像信号を伝送するシステムが一般に普及し始めている。これは、ビデオカメラなどにより撮影された映像や音声などのメディアデータを、ネットワークに接続されたコンピュータを介して、複数のクライアントに送信する伝送システムである。より詳細には、この種のシステムは、予め蓄積された映像ファイルから映像データを読み出しながら伝送するビデオオンデマンド型のシステムと、カメラなどからの映像をその場で圧縮符号化して伝送するリアルタイム放送型のシステムに分けられる。ここでインターネットなどを介してサービスを受けるユーザは、それぞれの接続環境などの違いにより、許容される通信帯域などが異なってる。
【０００３】
ビデオオンデマンド型のシステムにおいては、複数の通信レートに応じるべく、個々に画像サイズやフレームレート、圧縮パラメータの異なる複数の蓄積ファイルを生成し、これを選択してデータ配送を行っている。
一方、リアルタイム放送型、特にカメラで撮影した映像をリアルタイムで転送する場合には、複数の圧縮工程を１つの映像入力に対して実施するとその処理負荷が大きすぎて十分な最高レートが得られないといった理由から、１つのエンコーダマシンでは単一の画像サイズ、圧縮パラメータで伝送データを作成して全ユーザ（クライアント）に転送するようにしている。
【０００４】
技術的観点からは、複数の解像度の画像を１つの圧縮データから提供する方法として、静止画像用にはプログレッシブJPEGやインターレースGIFを用いる方法があり、動画においてもWavelet形式で圧縮されたデータの部分伝送で複数の解像度を提供するシステムが存在するが、これらの方法においても、圧縮方式への依存性が高く多様な圧縮標準に対応できない点、通信レートと画像サイズが独立に設定できない点等の利用上の制約が大きい。
【０００５】
【発明が解決しようとする課題】
このように、従来のリアルタイム放送型の映像伝送システムでは、映像サーバ側で用意した１系列のデータをすべてのクライアントが見るために、個々のクライアントの要望に応じた画像サイズのデータをサービスすることができない。また、小サイズの映像を多数利用したいといった場合、これまでの方式では一般のサイズの映像データを受信した後にクライアント側プログラムがその縮小を行うことが必要であり、通信容量の多さからネットワークへの負担がかかり転送に時間がかかる点、或いは、クライアントでの処理負荷の大きさ等の点で、クライアント側で多数の映像が表示できないなどといった問題が発生する。
【０００６】
これらの点は複数のクライアントに同時にデータを送信する場合、例えばインターネットを介してデータを転送する場合に特に効果が大きい。本発明はかかる問題点に管がみなされたものであり、クライアント毎に異なる方式の映像データを供給し得る映像サーバ及びその制御方法及び記憶媒体を提供しようとするものである。
【０００７】
【課題を解決するための手段】
この課題を解決するため、例えば本発明の映像サーバは以下の構成を備える。すなわち、
ネットワークを介して複数のクライアントにビデオカメラの映像データをリアルタイムに配送する映像サーバであって、
前記ビデオカメラの共通の映像データから、リアルタイムに配送するための複数の互いに異なる画面サイズの映像データを生成する生成手段と、
前記複数のクライアントに対し、前記生成手段によって生成される映像データのうち、配送を要求する映像データの画面サイズを問い合わせるための情報を前記複数のクライアントに向けて通知する通知手段と、
各クライアントが要求する画面サイズに応じて、前記生成手段によって生成された映像データをそれぞれリアルタイムに配送する配送手段とを備える。
【０００８】
【発明の実施の形態】
以下、添付図面に従って本発明に係る実施形態を詳細に説明する。
図１は、実施形態における全体の構成を示している。
図中、１０１は、ビデオカメラ等の画像入力装置である。この画像入力装置１０１は、コンピュータに接続可能であり、NTSC及びS-Videoなどの画像信号を出力するものとする。１０２は、画像キャプチャの取り込み手段を示している。コンピュータ内の画像取り込み装置により、画像入力装置１０１からの画像を取り込む。１０３は画像変倍手段、１０４は画像圧縮手段、１０５は配送手段である。１０６は、接続しているクライアントプログラムを示す。１０７は、要求受付手段である。１０８は、チャンネル管理手段である。
【０００９】
図示において、１０１〜１０５及び１０７、１０８がカメラサーバを構成し、１０６がそのカメラサーバから転送されてくる映像を受信し表示するクライアントを示すことになる。但し、これらの間は、ネットワークによって接続されていることになる。
また、図中の大矢印は、画像データの流れを示している。画像入力装置１０１にて取り込まれ画像データは、画像キャプチャ手段１０２により画像データをコンピュータに取り込むためにデジタルデータに変換される。そして、画像変倍手段１０３にて各種画像サイズを作り出す。尚、この画像変倍手段１０３は、その時点でクライアントに供給されている全画像サイズの画像データを作り出す。作り出された各サイズの画像データは、画像圧縮手段１０４により圧縮される。圧縮の方法は、各種方法が選択可能になっている。例えば、JpegやMpegその他、今後予想される新しいフォーマットにも対応出来るように、この画像圧縮手段は独立している。画像圧縮手段１０４にて、圧縮された画像データは、配送手段１０５にて、接続している各クライアントへ送信される。
【００１０】
クライアントは、この圧縮画像データを受信し、クライアントプログラムで復調され、画像として表示することになる。また、クライアントプログラムは、画像データを受信すると、そのアクノリッジを返し、次の画像データの要求を促す。
この要求を受けるのは、要求受付手段１０７である。チャネル管理手段１０８は、各クライアント（図面では１つのクライアント）それぞれの要求画像サイズを把握していて、この要求受付手段１０７からの通知を受け、１０２〜１０５を制御する。特に、画像変倍手段１０３に対しては全クライアントが要求しているサイズの画像を生成するように指示し、処理の能率向上の為に動作をする。
【００１１】
図２に実施形態における画像変倍手段１３０及び画像圧縮手段１０４の詳細ブロック構成図を示す。
図中、２０１ａ〜２０１ｄは画像メモリであり、キャプチャ手段１０２からのデジタル映像データ（以下、単に画像データという）を一時的に記憶する。２０２ａ〜２０２ｄはそれぞれ画像データを示しており、図示では、それぞれがオリジナル画像データに対するサイズを示している。２０３ａ〜２０３ｃはそれぞれ入力画像を１／２倍にする画像１／２処理部である。
【００１２】
図示の様にこれらの画像１／２処理部をカスケード接続することで、画像メモリ２０１ａにはキャプチャしたオリジナル画像データが、画像メモリ２０１ｂにはオリジナル画像データの縦横とも１／２サイズにした画像データが格納され、以下、画像メモリ２０１ｃは１／４、画像メモリ２０１ｄには１／８に縮小された画像データが格納されることになる。従って、画像メモリ２０１ｂ、ｃ、ｄはその順に従ってその記憶容量は少ないもので良い（画像メモリ２０１ａを１としたとき、１／４、１／１６、１／６４の容量）。
【００１３】
画像圧縮手段１０４は、上記のようにして生成された画像データを圧縮符号化することになる。
尚、画像１／２処理部２０３ａについては、画像メモリ２０１中の２×２の画素ブロック単位に読み込み、その総和を１／４、すなわち、平均値を画像メモリ２０１ｂに書き込むことで実現した。総和は加算器（もしくは加算演算）で実現でき、平均値は加算結果を単純に２ビットだけ下位方向にシフトすることで実現できるので、処理速度の問題はない。他の画像１／２処理部２０３ｂ、２０３ｃも同様である。
【００１４】
尚、この際、近傍画素による画素処理、例えば、黒強調や、輪郭強調方法などを適用することも可能である。このようにして作成されたオリジナル画像及び各縮小画像データは画像圧縮手段１０４にて圧縮処理される。尚、この処理の際、チャネル管理手段１０８からの情報を読み取り、不必要な処理を省くことを可能としている。つまり、その時点で接続しているクライアントのいずれもが１／８サイズの画像データを要求していない場合には、画像データ２０２ｄに対する処理は行なわない。
【００１５】
また、縮小手段と同様に、画像を拡大する拡大手段を組み合わせることで、図２に示される過程で、拡大図を作ることが可能となる。拡大画像を生成するためには、補間処理を行なえば容易に実現できるのは理解できよう。更に、上記以外の如何なる変倍技術を用いても構わないのは勿論である。
図３は、実施形態におけるシステム構成、特にネットワーク関連の構成を示している。
【００１６】
図中、３０１、３０４は、映像サーバ（カメラサーバ）であり（図１参照）、３０２は、映像サーバに接続されている画像入力装置としてのカメラである。３０３はネットワークを示す。このネットワークは、インターネット、イントラネットや、モデムを用いたアナログ回線及び、ISDN網など、その他コンピュータの接続可能とされる全てのネットワークを示している。そして、３０５はクライアントを示している。
【００１７】
カメラ３０２にて入力された画像データは、映像サーバ３０１を通じてネットワーク３０３へ送信される。送信されたデータは、クライアント３０５で受信され画像として表示される。また、映像サーバ３０１から送信される画像データは、ネットワークに接続しているクライアントであれば、同時に複数のクライアントで受信可能である。これは、例えば、放送的に使用可能であることを示している。つまり、複数のクライアントで、１台の映像サーバの画像を同時に閲覧出来るわけである。また、１台のクライアントは、同時、または、順番に、複数の映像サーバと接続でき、画像を同時、または、順番に、閲覧可能である。これは、例えば、監視カメラ的に使用する際等に有用である。
【００１８】
図４は、映像サーバ装置の具体的な構成を示している。
映像サーバは、カメラ３０２、そのカメラ３０２で撮像された映像データをキャプチャする映像キャプチャボード、及び、ネットワークと接続するためのネットワークインタフェースを有する。それ以外は、一般的なパーソナルコンピュータ等の構成と同じである。ＨＤ装置には、ＯＳや以下に説明するカメラサーバとして機能するサーバプログラムが格納されており、起動後、メモリにＯＳやサーバプログラムをロードし実行することになる。
【００１９】
図５は、サーバプログラムの構成図を示している。これは、図１に示される図を更に詳しく示したものでもある。
図中、５００は画像取り込み手段（映像キャプチャボードから映像データを取り込む処理）を示している。また、５０１は画像縮小および画像圧縮手段、５０２は配送手段、５０８は各クライアントを示している。５１０は要求受付手段を、５０５はチャンネル制御手段をしめしている。５０６は、画像圧縮を作成する為の画像チャンネル情報を提供する手段を示している。５１２、５１３、５１４、５１５、５０７は、処理の過程を流れる画像情報を示している。５０９、５１１、５１７、５１６は、画像送信要求を示している。
【００２０】
画像取り込み手段５００にて取り込まれた画像データは、画像変倍・圧縮手段（図１の１０３、１０４に対応する）５０１によって各種画像サイズに作成される。この際、この手段５０１は、処理５０６より指示された各画像サイズ（以降、チャンネルと呼ぶ）を作成する。またこの際に、チャネル制御手段５０５から要求されていない画像サイズの情報を受け取り、余分な処理を省くようにしている。画像変倍・圧縮手段５０１で、作成、圧縮された画像情報は、配送手段５０２へ渡され、各クライアントへ、要求している画像サイズを送信する。
【００２１】
各クライアントはこの送信されてきた画像データを伸張（復号化）し、表示するが、受信した際（もしくは表示した際）、次の画像送信要求をサーバの受付手段５１０に向けて転送する。受付手段５１０は、さらに、その情報をチャンネル制御手段５０５に供給し、チャンネル毎に、画像の供給状況を集計し、画像変倍・圧縮手段５０１および画像取り込み手段５００へ、画像の取り込みおよび、処理の指示を与える。このような処理を繰り返すことにより実現させる。
【００２２】
図６は、映像サーバにおけるクライアントからの接続が行なわれる場合の処理内容を示している。
先ず、ステップＳ６００でシステムスタートが行われると、ステップＳ６０１は、システム全体の初期化を示す。そして、ステップＳ６０２は、クライアントの接続要求を待つ処理を示す。ステップＳ６０３は、クライアントの接続を判断する処理を示しており、ここで接続要求があると、そのクライアントとの接続処理を行なう。
【００２３】
図７は、システム初期化の処理のフローを示す。
ステップＳ７００でシステム初期化がなされると、初期化中に３つのスレッドを作成する。具体的には、ステップＳ７０１における映像取り込み処理のためのスレッド、ステップＳ７０２における画像変倍・圧縮処理のためのスレッド、ステップＳ７０４におけるデータ配送処理、及びステップＳ７０４におけるデータ受付処理のスレッドである。
【００２４】
図８は上記図７において起動された映像取り込みスレッドの処理内容を示している。
先ず、ステップＳ８００にて初期化されると、ステップＳ８０１に進み、画像の取り込み要求が来るのを待つ。この取り込み要求は、後述する受付処理（図１１）で生成されるものである。
【００２５】
この要求がくると、処理はステップＳ８０２に進み、映像キャプチャボードより画像データを取り込み、それを画像変倍・圧縮手段へ渡すことを繰り返す。
図９は画像要求情報をもとにして、複数の画像サイズを作成し、圧縮する処理を示している。
先ず、ステップＳ９０１でチャンネル制御手段５０５から画像要求がなされているかどうかを判別し、その要求を待つ。そして、その要求があると、ステップＳ９０２に進んで、キャプチャした画像情報からチャンネル毎の画像情報を作成する。そして、ステップＳ９０３で、作成された画像データを圧縮する。圧縮された画像データは、ステップＳ９０４において、配送手段１０５へ渡す。そして、ステップＳ９０５でチャンネル全てに対して処理を行ったかを判断し、否の場合にはステップＳ９０１に戻り処理を繰り返す。
【００２６】
ここで、チャネル制御手段５０５（チャネル管理手段１０８）は、各チャネルに対する個々のクライアントの要求情報を以下のようにまとめあげる。
まず後述するクライアント接続時の処理により個々のクライアントがどのチャネルのユーザであるかが決まっているので、個々のクライアントの要求する通信レートをそのチャネルで利用する画像データの圧縮後の平均サイズで割ることにより個々のクライアントの要求フレームレートを決める。その上で、第１に各チャネル内のクライアントの要求フレームレートの最大値を求め、これをそのチャネルに対する画像圧縮手段１０４の動作のレートとする。第２に小さい順に各画像サイズ以下の全てのチャネルの要求フレームレートの最大値を求め、これをその画像サイズを生成する画像縮小手段１０３の動作レートとする。第３にすべてのチャネルの要求フレームレートの最大値（これは要求のあった最大サイズの映像チャネルの要求フレームレートと同じになる）を画像獲得手段１０２の動作レートとする。
【００２７】
尚、実際の動作上、上記の値はすべてのクライアントの要望にこたえるための処理レートの最小値となるので、これ以上のレートで処理を行えば固定レートであっても良い。
図１０は各クライアントへそれぞれ選択した画像を送信（配送）する配送手段の処理のフローチャートである。
【００２８】
先ず、ステップＳ１００１で、画像データの受信処理のスレッドが起動すると、次のステップＳ１００２において、圧縮画像データ（各サイズの画像データの圧縮データ）を画像変倍圧縮手段から受信するのを待つ。この受信があると、ステップＳ１００２において、受信した圧縮画像データの１つに着目し、それがクライアント（複数の場合もあり得る）が要求しているものかどうかを判断する。少なくとも１つのクライアントが要求しているサイズの圧縮画像データであると確認されると、ステップＳ１００３にて該当するクライアントに向けて送信（配送）する。また、ステップＳ１００２において、要求されていないサイズの画像データであると判断した場合には、ステップＳ１００３の処理をスキップする。ステップＳ１００４では、接続されている全クライアントに対して送信処理が完了したか否かを判断する。否の場合には、画像変倍圧縮手段から受信した他のサイズの画像に対する処理を行なうため、ステップＳ１００２に戻り、次のサイズの画像データに対する配送処理を行なう。
【００２９】
図１１は各クライアントからの画像送信要求を受け取る処理（要求受付手段）のフローチャートである。
ステップＳ１１００で要求受け付けのスレッドが起動すると、次のステップＳ１１０１においてクライアントからの受信を待つ。クライアントからの要求があると、次のステップＳ１１０２において、その要求を行ったクライアントに次の画像データを送信すべき旨の情報（チャンネル毎に管理されている）を作成する処理を行なう（実際は後述する如くそのクライアントに画像データを転送することを示すフラグをセットする処理である）。そして、ステップＳ１１０３では、各クライアントの画像要求をチャンネル毎に集計し、画像要求状況をまとめる処理を行ない、それをチャネル制御手段に渡して、ステップＳ１１０１に戻る。
【００３０】
ここで注目する点は、１つのクライアントから次画像転送要求があると、その都度、チャネル制御手段にその情報を伝える点である。すなわち、次の画像データのキャプチャするタイミングになっても、或る１つのクライアントからの次画像データの転送要求がない場合（そのクライアントとの通信経路が混雑している場合等）、そのクライアントについては転送は行なわず、要求があったクライアントに対して転送する。これにより、少なくとも転送要求があったクライアントについては実時間の画像データの転送を保証する。
【００３１】
図１２はそのチャンネル制御手段の処理内容を示すフローチャートである。
ステップＳ１２００でチャネル制御手段のスレッドが起動すると、ステップＳ１２０１で画像取り込みのための所定時間待機する。ステップＳ１２０２では、この待機時間中に要求受付手段からの配送要求情報を獲得する。そして、ステップＳ１２０３において、各チャンネル毎に集計する。そして、ステップＳ１２０４において、その時点でのチャンネル画像要求情報を作成する。
【００３２】
以上の各スレッドを映像サーバ（カメラサーバ）で行なうことで、カメラから所定時間毎に画像データとしてキャプチャすることを繰り替えしている最中に、異なるサイズの画像（図２では４種類）を作成し、その周期で各クライアントからの要求を各チャンネル毎に集計し、その集計結果に基づいて各サイズの画像データ（圧縮画像データ）を、各チャネル毎の各クライアントに向けて送信することが可能になる。その際、各サイズの画像データの転送レートは、各クライアントと本映像サーバの間の送信経路中の通信状態に最適なものとすることができる。
【００３３】
次に、クライアントからの接続要求があった場合の処理について図１３のフローチャートに従い説明する。同図の処理は、各クライアントから接続要求がある度に起動するものである。
先ず、本処理がステップＳ１３００で起動すると、ステップＳ１３０１に進み、そのクライアントが指定した画像サイズ情報を受信する。そして、ステップＳ１３０２に進み、クライアントが要求している画像圧縮形式を示す情報を得る。そして、ステップＳ１３０３で、映像データの配送を開始する旨を通知し、ステップＳ１３０４でクライアントから受信準備完了を示す情報を受信する。この受信があると、そのクライアントに最初の画像データをおくべく、画像要求フラグをセットし、本処理を終了する。
【００３４】
説明が前後するが、映像サーバ側における圧縮符号化方法の種類が１つである場合には、ステップＳ１３０３の処理は不要となる。
また、映像サーバが、クライアントの要求するすべての映像サイズ及び映像圧縮方式に答えると、非常に処理が重くなる為、本実施形態では各チャネル毎に圧縮符号化の種類を割り当てる。
【００３５】
例えば、図１３で示されるクライアント接続時処理において、映像サーバから、クライアントへ映像サーバがどのようなチャンネルを持っているかという情報を送信することにより、それをクライアント側のユーザーが選択出来るようにするというものである。具体的には、映像サーバは、クライアントからの接続要求があった場合に、そのクライアントに対して、どのチャンネルデータを選択するかを示すメニュー情報を転送し、表示させる。クライアント側のユーザーは、この表示メニューを見て、いずれかを選択する。これの利点は、クライアントを操作するユーザーが映像サーバの持っているチャンネルを把握できることにあり、最適なチャンネルを選択できるようになる。
【００３６】
もう１つの解決手段としては、図１３で示されるクライアント接続時処理フロー内において、クライアント側から、要求される画像サイズ及び、圧縮処理にもっとも近似していると思われるチャンネルを映像サーバ側で、自動的に選択することである。具体的には、指定された圧縮方式で指定されたサイズより大きく、かつ、その画像サイズに適用した最適なチャンネルを選択する。また、より大きいものがなければ、同圧縮方式で、最大サイズのチャンネルを選択する。この利点は、クライアントを操作するユーザーに、余分な情報を開示しなくてよく、自動的にチャンネルが選択されるためユーザーの操作を簡単にすることが出来ることである。又、クライアント側が、映像サーバ側の状況を気にする必要性が低くなる為、システムに柔軟的になる。
【００３７】
図１４は、チャンネル制御手段が有しているチャンネル情報の一部を示している（実際は、これ以外に各チャネル毎に接続ユーザのアドレス等も管理している）。
図示の如く、各チャンネルは、画像の圧縮率あるいは、品質パラメータ、圧縮方式、画像のサイズの情報を持っている。この情報は、システムを管理するユーザーが自由に設定可能である。
【００３８】
この情報は、画像縮小圧縮手段等で、使用されることにより、サーバから提供する画像のサイズなどが決まる。
図示の場合には、６つのチャンネルが用意されており、画像サイズは３種類、圧縮率が２種類の中から選択できる例を示している。
図１５は、実際に、このサーバを利用した場合のクライアント側の画面を示している。
【００３９】
図中、１５００は、ディスプレイ画面を示しており、１５０１、１５０２、１５０５は、映像サーバの画像を示している。１５０３、１５０４は、画面に表示されるウィンドウを示している。
特にこの図１５に示されるような状態において、本件は、非常に効果がある。ウインドウ１５０３内には、非常に多くの映像サーバの画像を表示する必要がある。このような場合、大きな画像データは不要であり、むしろ、サイズの小さいデータが大量に必要になる。このようにする場合、それぞれ（例えば、１５０１、１５０２など）の映像サーバの映像をクライアントから、画像のサイズの小さいものを要求すれば、ネットワークに負荷を与えることなく、高速に全ての画面を動画として再生が可能となる。
【００４０】
又、そのうちの一つの画面に関し、高画質の画像が、欲しい場合（例えば、その小画像部分をマウス等でダブルクリックする）、ウインドウ１５０４が表示され、そこに該当する映像サーバからの画像１５０５を表示させる。
このように、システムを作ることにより、各クライアントは、各クライアント毎に必要とされる画質及び画像サイズ、圧縮方式等を選択的に使うことが出来るようになる。これにより、低いレートでも、高フレームレートの動画を再生可能となる。また、低フレームレートではあるが、非常に高画質な画像を得ることが出来るようになる。しかも、それを提供するサーバは、たった１台で、効率的に行うことが出来る。
【００４１】
本実施形態に開示された発明は、インターネット等の複数クライアントに同時に映像データを送信する場合に特に効果が大きい。
以上説明したように本実施形態によれば、複数の画面サイズを同時に扱うことが可能となり、各クライアントからの画像サイズ、及び、画像圧縮方式の要求に対して、解決することが可能となる。これにより、低画質の画像を高フレームレートにて転送が、可能となると同時に、高画質を要求するクライアントに関しては、低レートながらも、高品質の画像を送ることが可能となる。
【００４２】
また、映像サーバを実現させる手段として、多画面生成を能率的に行うことが可能になる。
更に、複数のクライアントの要求を合理的にまとめることによって、映像サーバを実現させる手段として能率の向上に効果がある。
また、クライアント側での操作向上に効果があり、ユーザーの操作性向上に効果がある。
【００４３】
尚、実施形態では、１つの共有の映像データ（カメラより撮像された映像データ）に基づいて複数の異なるサイズの映像データを生成する例を説明したが、例えば、同じ画像でありながらも、異なるサイズの画像データを予め記憶しておき、それを各クライアントが要求した画像を転送するようにしてもよい。従って、上記実施形態で説明した変倍処理は必ずしも必須ではない。
【００４４】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用しても良い。
また、本発明の目的は、ネットワークに接続する為のハードウェア（特に映像サーバでは映像入力する手段であるカメラ等）を必要とするものの、それらハードウェアを使用するソフトウェアによって実現できる。従って、ソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出して実行することによっても、達成されることは言うまでのもない。
【００４５】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００４６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行ない、その処理によって実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４７】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４８】
【発明の効果】
以上説明したように本発明によれば、クライアント毎に異なるサイズの映像データを供給することが可能となる。
【図面の簡単な説明】
【図１】実施形態における映像サーバの機能ブロック構成図である。
【図２】実施形態における画像変倍処理手段のブロック構成図である。
【図３】実施形態におけるシステム構成図である。
【図４】実施形態におけるサーバ装置の具体的なブロック構成図である。
【図５】実施形態におけるサーバプログラムの構成図である。
【図６】サーバプログラムの初期状態における処理を示すフローチャートである。
【図７】サーバプログラムにおけるシステム初期化のフローチャートである。
【図８】サーバ装置における画像データ取り込み処理を示すフローチャートである。
【図９】サーバ装置における画像変倍圧縮手段の処理を示すフローチャートである。
【図１０】サーバ装置における配送手段の処理を示すフローチャートである。
【図１１】サーバ装置における要求受付手段の処理を示すフローチャートである。
【図１２】サーバ装置におけるチャンネル制御手段の処理を示すフローチャートである。
【図１３】サーバ装置におけるクライアント接続時の処理を示すフローチャートである。
【図１４】サーバ装置におけるチャンネル情報の一例を示す図である。
【図１５】クライアント側の表示画面の表示例を示す図である。
【 符号の説明 】
１０２ 画像キャプチャ手段
１０３ 画像変倍手段
１０４ 画像圧縮手段
１０５ 配送手段
１０７ 要求受付手段
１０８ チャンネル管理手段
【発明の属する技術分野】
本発明はネットワークを介してクライアントに向けて映像データを配送する映像サーバ及びその制御方法及び記憶媒体に関するものである。
【０００２】
【従来の技術】
近年、ネットワークを介して映像信号を伝送するシステムが一般に普及し始めている。これは、ビデオカメラなどにより撮影された映像や音声などのメディアデータを、ネットワークに接続されたコンピュータを介して、複数のクライアントに送信する伝送システムである。より詳細には、この種のシステムは、予め蓄積された映像ファイルから映像データを読み出しながら伝送するビデオオンデマンド型のシステムと、カメラなどからの映像をその場で圧縮符号化して伝送するリアルタイム放送型のシステムに分けられる。ここでインターネットなどを介してサービスを受けるユーザは、それぞれの接続環境などの違いにより、許容される通信帯域などが異なってる。
【０００３】
ビデオオンデマンド型のシステムにおいては、複数の通信レートに応じるべく、個々に画像サイズやフレームレート、圧縮パラメータの異なる複数の蓄積ファイルを生成し、これを選択してデータ配送を行っている。
一方、リアルタイム放送型、特にカメラで撮影した映像をリアルタイムで転送する場合には、複数の圧縮工程を１つの映像入力に対して実施するとその処理負荷が大きすぎて十分な最高レートが得られないといった理由から、１つのエンコーダマシンでは単一の画像サイズ、圧縮パラメータで伝送データを作成して全ユーザ（クライアント）に転送するようにしている。
【０００４】
技術的観点からは、複数の解像度の画像を１つの圧縮データから提供する方法として、静止画像用にはプログレッシブJPEGやインターレースGIFを用いる方法があり、動画においてもWavelet形式で圧縮されたデータの部分伝送で複数の解像度を提供するシステムが存在するが、これらの方法においても、圧縮方式への依存性が高く多様な圧縮標準に対応できない点、通信レートと画像サイズが独立に設定できない点等の利用上の制約が大きい。
【０００５】
【発明が解決しようとする課題】
このように、従来のリアルタイム放送型の映像伝送システムでは、映像サーバ側で用意した１系列のデータをすべてのクライアントが見るために、個々のクライアントの要望に応じた画像サイズのデータをサービスすることができない。また、小サイズの映像を多数利用したいといった場合、これまでの方式では一般のサイズの映像データを受信した後にクライアント側プログラムがその縮小を行うことが必要であり、通信容量の多さからネットワークへの負担がかかり転送に時間がかかる点、或いは、クライアントでの処理負荷の大きさ等の点で、クライアント側で多数の映像が表示できないなどといった問題が発生する。
【０００６】
これらの点は複数のクライアントに同時にデータを送信する場合、例えばインターネットを介してデータを転送する場合に特に効果が大きい。本発明はかかる問題点に管がみなされたものであり、クライアント毎に異なる方式の映像データを供給し得る映像サーバ及びその制御方法及び記憶媒体を提供しようとするものである。
【０００７】
【課題を解決するための手段】
この課題を解決するため、例えば本発明の映像サーバは以下の構成を備える。すなわち、
ネットワークを介して複数のクライアントにビデオカメラの映像データをリアルタイムに配送する映像サーバであって、
前記ビデオカメラの共通の映像データから、リアルタイムに配送するための複数の互いに異なる画面サイズの映像データを生成する生成手段と、
前記複数のクライアントに対し、前記生成手段によって生成される映像データのうち、配送を要求する映像データの画面サイズを問い合わせるための情報を前記複数のクライアントに向けて通知する通知手段と、
各クライアントが要求する画面サイズに応じて、前記生成手段によって生成された映像データをそれぞれリアルタイムに配送する配送手段とを備える。
【０００８】
【発明の実施の形態】
以下、添付図面に従って本発明に係る実施形態を詳細に説明する。
図１は、実施形態における全体の構成を示している。
図中、１０１は、ビデオカメラ等の画像入力装置である。この画像入力装置１０１は、コンピュータに接続可能であり、NTSC及びS-Videoなどの画像信号を出力するものとする。１０２は、画像キャプチャの取り込み手段を示している。コンピュータ内の画像取り込み装置により、画像入力装置１０１からの画像を取り込む。１０３は画像変倍手段、１０４は画像圧縮手段、１０５は配送手段である。１０６は、接続しているクライアントプログラムを示す。１０７は、要求受付手段である。１０８は、チャンネル管理手段である。
【０００９】
図示において、１０１〜１０５及び１０７、１０８がカメラサーバを構成し、１０６がそのカメラサーバから転送されてくる映像を受信し表示するクライアントを示すことになる。但し、これらの間は、ネットワークによって接続されていることになる。
また、図中の大矢印は、画像データの流れを示している。画像入力装置１０１にて取り込まれ画像データは、画像キャプチャ手段１０２により画像データをコンピュータに取り込むためにデジタルデータに変換される。そして、画像変倍手段１０３にて各種画像サイズを作り出す。尚、この画像変倍手段１０３は、その時点でクライアントに供給されている全画像サイズの画像データを作り出す。作り出された各サイズの画像データは、画像圧縮手段１０４により圧縮される。圧縮の方法は、各種方法が選択可能になっている。例えば、JpegやMpegその他、今後予想される新しいフォーマットにも対応出来るように、この画像圧縮手段は独立している。画像圧縮手段１０４にて、圧縮された画像データは、配送手段１０５にて、接続している各クライアントへ送信される。
【００１０】
クライアントは、この圧縮画像データを受信し、クライアントプログラムで復調され、画像として表示することになる。また、クライアントプログラムは、画像データを受信すると、そのアクノリッジを返し、次の画像データの要求を促す。
この要求を受けるのは、要求受付手段１０７である。チャネル管理手段１０８は、各クライアント（図面では１つのクライアント）それぞれの要求画像サイズを把握していて、この要求受付手段１０７からの通知を受け、１０２〜１０５を制御する。特に、画像変倍手段１０３に対しては全クライアントが要求しているサイズの画像を生成するように指示し、処理の能率向上の為に動作をする。
【００１１】
図２に実施形態における画像変倍手段１３０及び画像圧縮手段１０４の詳細ブロック構成図を示す。
図中、２０１ａ〜２０１ｄは画像メモリであり、キャプチャ手段１０２からのデジタル映像データ（以下、単に画像データという）を一時的に記憶する。２０２ａ〜２０２ｄはそれぞれ画像データを示しており、図示では、それぞれがオリジナル画像データに対するサイズを示している。２０３ａ〜２０３ｃはそれぞれ入力画像を１／２倍にする画像１／２処理部である。
【００１２】
図示の様にこれらの画像１／２処理部をカスケード接続することで、画像メモリ２０１ａにはキャプチャしたオリジナル画像データが、画像メモリ２０１ｂにはオリジナル画像データの縦横とも１／２サイズにした画像データが格納され、以下、画像メモリ２０１ｃは１／４、画像メモリ２０１ｄには１／８に縮小された画像データが格納されることになる。従って、画像メモリ２０１ｂ、ｃ、ｄはその順に従ってその記憶容量は少ないもので良い（画像メモリ２０１ａを１としたとき、１／４、１／１６、１／６４の容量）。
【００１３】
画像圧縮手段１０４は、上記のようにして生成された画像データを圧縮符号化することになる。
尚、画像１／２処理部２０３ａについては、画像メモリ２０１中の２×２の画素ブロック単位に読み込み、その総和を１／４、すなわち、平均値を画像メモリ２０１ｂに書き込むことで実現した。総和は加算器（もしくは加算演算）で実現でき、平均値は加算結果を単純に２ビットだけ下位方向にシフトすることで実現できるので、処理速度の問題はない。他の画像１／２処理部２０３ｂ、２０３ｃも同様である。
【００１４】
尚、この際、近傍画素による画素処理、例えば、黒強調や、輪郭強調方法などを適用することも可能である。このようにして作成されたオリジナル画像及び各縮小画像データは画像圧縮手段１０４にて圧縮処理される。尚、この処理の際、チャネル管理手段１０８からの情報を読み取り、不必要な処理を省くことを可能としている。つまり、その時点で接続しているクライアントのいずれもが１／８サイズの画像データを要求していない場合には、画像データ２０２ｄに対する処理は行なわない。
【００１５】
また、縮小手段と同様に、画像を拡大する拡大手段を組み合わせることで、図２に示される過程で、拡大図を作ることが可能となる。拡大画像を生成するためには、補間処理を行なえば容易に実現できるのは理解できよう。更に、上記以外の如何なる変倍技術を用いても構わないのは勿論である。
図３は、実施形態におけるシステム構成、特にネットワーク関連の構成を示している。
【００１６】
図中、３０１、３０４は、映像サーバ（カメラサーバ）であり（図１参照）、３０２は、映像サーバに接続されている画像入力装置としてのカメラである。３０３はネットワークを示す。このネットワークは、インターネット、イントラネットや、モデムを用いたアナログ回線及び、ISDN網など、その他コンピュータの接続可能とされる全てのネットワークを示している。そして、３０５はクライアントを示している。
【００１７】
カメラ３０２にて入力された画像データは、映像サーバ３０１を通じてネットワーク３０３へ送信される。送信されたデータは、クライアント３０５で受信され画像として表示される。また、映像サーバ３０１から送信される画像データは、ネットワークに接続しているクライアントであれば、同時に複数のクライアントで受信可能である。これは、例えば、放送的に使用可能であることを示している。つまり、複数のクライアントで、１台の映像サーバの画像を同時に閲覧出来るわけである。また、１台のクライアントは、同時、または、順番に、複数の映像サーバと接続でき、画像を同時、または、順番に、閲覧可能である。これは、例えば、監視カメラ的に使用する際等に有用である。
【００１８】
図４は、映像サーバ装置の具体的な構成を示している。
映像サーバは、カメラ３０２、そのカメラ３０２で撮像された映像データをキャプチャする映像キャプチャボード、及び、ネットワークと接続するためのネットワークインタフェースを有する。それ以外は、一般的なパーソナルコンピュータ等の構成と同じである。ＨＤ装置には、ＯＳや以下に説明するカメラサーバとして機能するサーバプログラムが格納されており、起動後、メモリにＯＳやサーバプログラムをロードし実行することになる。
【００１９】
図５は、サーバプログラムの構成図を示している。これは、図１に示される図を更に詳しく示したものでもある。
図中、５００は画像取り込み手段（映像キャプチャボードから映像データを取り込む処理）を示している。また、５０１は画像縮小および画像圧縮手段、５０２は配送手段、５０８は各クライアントを示している。５１０は要求受付手段を、５０５はチャンネル制御手段をしめしている。５０６は、画像圧縮を作成する為の画像チャンネル情報を提供する手段を示している。５１２、５１３、５１４、５１５、５０７は、処理の過程を流れる画像情報を示している。５０９、５１１、５１７、５１６は、画像送信要求を示している。
【００２０】
画像取り込み手段５００にて取り込まれた画像データは、画像変倍・圧縮手段（図１の１０３、１０４に対応する）５０１によって各種画像サイズに作成される。この際、この手段５０１は、処理５０６より指示された各画像サイズ（以降、チャンネルと呼ぶ）を作成する。またこの際に、チャネル制御手段５０５から要求されていない画像サイズの情報を受け取り、余分な処理を省くようにしている。画像変倍・圧縮手段５０１で、作成、圧縮された画像情報は、配送手段５０２へ渡され、各クライアントへ、要求している画像サイズを送信する。
【００２１】
各クライアントはこの送信されてきた画像データを伸張（復号化）し、表示するが、受信した際（もしくは表示した際）、次の画像送信要求をサーバの受付手段５１０に向けて転送する。受付手段５１０は、さらに、その情報をチャンネル制御手段５０５に供給し、チャンネル毎に、画像の供給状況を集計し、画像変倍・圧縮手段５０１および画像取り込み手段５００へ、画像の取り込みおよび、処理の指示を与える。このような処理を繰り返すことにより実現させる。
【００２２】
図６は、映像サーバにおけるクライアントからの接続が行なわれる場合の処理内容を示している。
先ず、ステップＳ６００でシステムスタートが行われると、ステップＳ６０１は、システム全体の初期化を示す。そして、ステップＳ６０２は、クライアントの接続要求を待つ処理を示す。ステップＳ６０３は、クライアントの接続を判断する処理を示しており、ここで接続要求があると、そのクライアントとの接続処理を行なう。
【００２３】
図７は、システム初期化の処理のフローを示す。
ステップＳ７００でシステム初期化がなされると、初期化中に３つのスレッドを作成する。具体的には、ステップＳ７０１における映像取り込み処理のためのスレッド、ステップＳ７０２における画像変倍・圧縮処理のためのスレッド、ステップＳ７０４におけるデータ配送処理、及びステップＳ７０４におけるデータ受付処理のスレッドである。
【００２４】
図８は上記図７において起動された映像取り込みスレッドの処理内容を示している。
先ず、ステップＳ８００にて初期化されると、ステップＳ８０１に進み、画像の取り込み要求が来るのを待つ。この取り込み要求は、後述する受付処理（図１１）で生成されるものである。
【００２５】
この要求がくると、処理はステップＳ８０２に進み、映像キャプチャボードより画像データを取り込み、それを画像変倍・圧縮手段へ渡すことを繰り返す。
図９は画像要求情報をもとにして、複数の画像サイズを作成し、圧縮する処理を示している。
先ず、ステップＳ９０１でチャンネル制御手段５０５から画像要求がなされているかどうかを判別し、その要求を待つ。そして、その要求があると、ステップＳ９０２に進んで、キャプチャした画像情報からチャンネル毎の画像情報を作成する。そして、ステップＳ９０３で、作成された画像データを圧縮する。圧縮された画像データは、ステップＳ９０４において、配送手段１０５へ渡す。そして、ステップＳ９０５でチャンネル全てに対して処理を行ったかを判断し、否の場合にはステップＳ９０１に戻り処理を繰り返す。
【００２６】
ここで、チャネル制御手段５０５（チャネル管理手段１０８）は、各チャネルに対する個々のクライアントの要求情報を以下のようにまとめあげる。
まず後述するクライアント接続時の処理により個々のクライアントがどのチャネルのユーザであるかが決まっているので、個々のクライアントの要求する通信レートをそのチャネルで利用する画像データの圧縮後の平均サイズで割ることにより個々のクライアントの要求フレームレートを決める。その上で、第１に各チャネル内のクライアントの要求フレームレートの最大値を求め、これをそのチャネルに対する画像圧縮手段１０４の動作のレートとする。第２に小さい順に各画像サイズ以下の全てのチャネルの要求フレームレートの最大値を求め、これをその画像サイズを生成する画像縮小手段１０３の動作レートとする。第３にすべてのチャネルの要求フレームレートの最大値（これは要求のあった最大サイズの映像チャネルの要求フレームレートと同じになる）を画像獲得手段１０２の動作レートとする。
【００２７】
尚、実際の動作上、上記の値はすべてのクライアントの要望にこたえるための処理レートの最小値となるので、これ以上のレートで処理を行えば固定レートであっても良い。
図１０は各クライアントへそれぞれ選択した画像を送信（配送）する配送手段の処理のフローチャートである。
【００２８】
先ず、ステップＳ１００１で、画像データの受信処理のスレッドが起動すると、次のステップＳ１００２において、圧縮画像データ（各サイズの画像データの圧縮データ）を画像変倍圧縮手段から受信するのを待つ。この受信があると、ステップＳ１００２において、受信した圧縮画像データの１つに着目し、それがクライアント（複数の場合もあり得る）が要求しているものかどうかを判断する。少なくとも１つのクライアントが要求しているサイズの圧縮画像データであると確認されると、ステップＳ１００３にて該当するクライアントに向けて送信（配送）する。また、ステップＳ１００２において、要求されていないサイズの画像データであると判断した場合には、ステップＳ１００３の処理をスキップする。ステップＳ１００４では、接続されている全クライアントに対して送信処理が完了したか否かを判断する。否の場合には、画像変倍圧縮手段から受信した他のサイズの画像に対する処理を行なうため、ステップＳ１００２に戻り、次のサイズの画像データに対する配送処理を行なう。
【００２９】
図１１は各クライアントからの画像送信要求を受け取る処理（要求受付手段）のフローチャートである。
ステップＳ１１００で要求受け付けのスレッドが起動すると、次のステップＳ１１０１においてクライアントからの受信を待つ。クライアントからの要求があると、次のステップＳ１１０２において、その要求を行ったクライアントに次の画像データを送信すべき旨の情報（チャンネル毎に管理されている）を作成する処理を行なう（実際は後述する如くそのクライアントに画像データを転送することを示すフラグをセットする処理である）。そして、ステップＳ１１０３では、各クライアントの画像要求をチャンネル毎に集計し、画像要求状況をまとめる処理を行ない、それをチャネル制御手段に渡して、ステップＳ１１０１に戻る。
【００３０】
ここで注目する点は、１つのクライアントから次画像転送要求があると、その都度、チャネル制御手段にその情報を伝える点である。すなわち、次の画像データのキャプチャするタイミングになっても、或る１つのクライアントからの次画像データの転送要求がない場合（そのクライアントとの通信経路が混雑している場合等）、そのクライアントについては転送は行なわず、要求があったクライアントに対して転送する。これにより、少なくとも転送要求があったクライアントについては実時間の画像データの転送を保証する。
【００３１】
図１２はそのチャンネル制御手段の処理内容を示すフローチャートである。
ステップＳ１２００でチャネル制御手段のスレッドが起動すると、ステップＳ１２０１で画像取り込みのための所定時間待機する。ステップＳ１２０２では、この待機時間中に要求受付手段からの配送要求情報を獲得する。そして、ステップＳ１２０３において、各チャンネル毎に集計する。そして、ステップＳ１２０４において、その時点でのチャンネル画像要求情報を作成する。
【００３２】
以上の各スレッドを映像サーバ（カメラサーバ）で行なうことで、カメラから所定時間毎に画像データとしてキャプチャすることを繰り替えしている最中に、異なるサイズの画像（図２では４種類）を作成し、その周期で各クライアントからの要求を各チャンネル毎に集計し、その集計結果に基づいて各サイズの画像データ（圧縮画像データ）を、各チャネル毎の各クライアントに向けて送信することが可能になる。その際、各サイズの画像データの転送レートは、各クライアントと本映像サーバの間の送信経路中の通信状態に最適なものとすることができる。
【００３３】
次に、クライアントからの接続要求があった場合の処理について図１３のフローチャートに従い説明する。同図の処理は、各クライアントから接続要求がある度に起動するものである。
先ず、本処理がステップＳ１３００で起動すると、ステップＳ１３０１に進み、そのクライアントが指定した画像サイズ情報を受信する。そして、ステップＳ１３０２に進み、クライアントが要求している画像圧縮形式を示す情報を得る。そして、ステップＳ１３０３で、映像データの配送を開始する旨を通知し、ステップＳ１３０４でクライアントから受信準備完了を示す情報を受信する。この受信があると、そのクライアントに最初の画像データをおくべく、画像要求フラグをセットし、本処理を終了する。
【００３４】
説明が前後するが、映像サーバ側における圧縮符号化方法の種類が１つである場合には、ステップＳ１３０３の処理は不要となる。
また、映像サーバが、クライアントの要求するすべての映像サイズ及び映像圧縮方式に答えると、非常に処理が重くなる為、本実施形態では各チャネル毎に圧縮符号化の種類を割り当てる。
【００３５】
例えば、図１３で示されるクライアント接続時処理において、映像サーバから、クライアントへ映像サーバがどのようなチャンネルを持っているかという情報を送信することにより、それをクライアント側のユーザーが選択出来るようにするというものである。具体的には、映像サーバは、クライアントからの接続要求があった場合に、そのクライアントに対して、どのチャンネルデータを選択するかを示すメニュー情報を転送し、表示させる。クライアント側のユーザーは、この表示メニューを見て、いずれかを選択する。これの利点は、クライアントを操作するユーザーが映像サーバの持っているチャンネルを把握できることにあり、最適なチャンネルを選択できるようになる。
【００３６】
もう１つの解決手段としては、図１３で示されるクライアント接続時処理フロー内において、クライアント側から、要求される画像サイズ及び、圧縮処理にもっとも近似していると思われるチャンネルを映像サーバ側で、自動的に選択することである。具体的には、指定された圧縮方式で指定されたサイズより大きく、かつ、その画像サイズに適用した最適なチャンネルを選択する。また、より大きいものがなければ、同圧縮方式で、最大サイズのチャンネルを選択する。この利点は、クライアントを操作するユーザーに、余分な情報を開示しなくてよく、自動的にチャンネルが選択されるためユーザーの操作を簡単にすることが出来ることである。又、クライアント側が、映像サーバ側の状況を気にする必要性が低くなる為、システムに柔軟的になる。
【００３７】
図１４は、チャンネル制御手段が有しているチャンネル情報の一部を示している（実際は、これ以外に各チャネル毎に接続ユーザのアドレス等も管理している）。
図示の如く、各チャンネルは、画像の圧縮率あるいは、品質パラメータ、圧縮方式、画像のサイズの情報を持っている。この情報は、システムを管理するユーザーが自由に設定可能である。
【００３８】
この情報は、画像縮小圧縮手段等で、使用されることにより、サーバから提供する画像のサイズなどが決まる。
図示の場合には、６つのチャンネルが用意されており、画像サイズは３種類、圧縮率が２種類の中から選択できる例を示している。
図１５は、実際に、このサーバを利用した場合のクライアント側の画面を示している。
【００３９】
図中、１５００は、ディスプレイ画面を示しており、１５０１、１５０２、１５０５は、映像サーバの画像を示している。１５０３、１５０４は、画面に表示されるウィンドウを示している。
特にこの図１５に示されるような状態において、本件は、非常に効果がある。ウインドウ１５０３内には、非常に多くの映像サーバの画像を表示する必要がある。このような場合、大きな画像データは不要であり、むしろ、サイズの小さいデータが大量に必要になる。このようにする場合、それぞれ（例えば、１５０１、１５０２など）の映像サーバの映像をクライアントから、画像のサイズの小さいものを要求すれば、ネットワークに負荷を与えることなく、高速に全ての画面を動画として再生が可能となる。
【００４０】
又、そのうちの一つの画面に関し、高画質の画像が、欲しい場合（例えば、その小画像部分をマウス等でダブルクリックする）、ウインドウ１５０４が表示され、そこに該当する映像サーバからの画像１５０５を表示させる。
このように、システムを作ることにより、各クライアントは、各クライアント毎に必要とされる画質及び画像サイズ、圧縮方式等を選択的に使うことが出来るようになる。これにより、低いレートでも、高フレームレートの動画を再生可能となる。また、低フレームレートではあるが、非常に高画質な画像を得ることが出来るようになる。しかも、それを提供するサーバは、たった１台で、効率的に行うことが出来る。
【００４１】
本実施形態に開示された発明は、インターネット等の複数クライアントに同時に映像データを送信する場合に特に効果が大きい。
以上説明したように本実施形態によれば、複数の画面サイズを同時に扱うことが可能となり、各クライアントからの画像サイズ、及び、画像圧縮方式の要求に対して、解決することが可能となる。これにより、低画質の画像を高フレームレートにて転送が、可能となると同時に、高画質を要求するクライアントに関しては、低レートながらも、高品質の画像を送ることが可能となる。
【００４２】
また、映像サーバを実現させる手段として、多画面生成を能率的に行うことが可能になる。
更に、複数のクライアントの要求を合理的にまとめることによって、映像サーバを実現させる手段として能率の向上に効果がある。
また、クライアント側での操作向上に効果があり、ユーザーの操作性向上に効果がある。
【００４３】
尚、実施形態では、１つの共有の映像データ（カメラより撮像された映像データ）に基づいて複数の異なるサイズの映像データを生成する例を説明したが、例えば、同じ画像でありながらも、異なるサイズの画像データを予め記憶しておき、それを各クライアントが要求した画像を転送するようにしてもよい。従って、上記実施形態で説明した変倍処理は必ずしも必須ではない。
【００４４】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用しても良い。
また、本発明の目的は、ネットワークに接続する為のハードウェア（特に映像サーバでは映像入力する手段であるカメラ等）を必要とするものの、それらハードウェアを使用するソフトウェアによって実現できる。従って、ソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出して実行することによっても、達成されることは言うまでのもない。
【００４５】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００４６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行ない、その処理によって実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４７】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４８】
【発明の効果】
以上説明したように本発明によれば、クライアント毎に異なるサイズの映像データを供給することが可能となる。
【図面の簡単な説明】
【図１】実施形態における映像サーバの機能ブロック構成図である。
【図２】実施形態における画像変倍処理手段のブロック構成図である。
【図３】実施形態におけるシステム構成図である。
【図４】実施形態におけるサーバ装置の具体的なブロック構成図である。
【図５】実施形態におけるサーバプログラムの構成図である。
【図６】サーバプログラムの初期状態における処理を示すフローチャートである。
【図７】サーバプログラムにおけるシステム初期化のフローチャートである。
【図８】サーバ装置における画像データ取り込み処理を示すフローチャートである。
【図９】サーバ装置における画像変倍圧縮手段の処理を示すフローチャートである。
【図１０】サーバ装置における配送手段の処理を示すフローチャートである。
【図１１】サーバ装置における要求受付手段の処理を示すフローチャートである。
【図１２】サーバ装置におけるチャンネル制御手段の処理を示すフローチャートである。
【図１３】サーバ装置におけるクライアント接続時の処理を示すフローチャートである。
【図１４】サーバ装置におけるチャンネル情報の一例を示す図である。
【図１５】クライアント側の表示画面の表示例を示す図である。
【 符号の説明 】
１０２ 画像キャプチャ手段
１０３ 画像変倍手段
１０４ 画像圧縮手段
１０５ 配送手段
１０７ 要求受付手段
１０８ チャンネル管理手段
Claims (7)
- ネットワークを介して複数のクライアントにビデオカメラの映像データをリアルタイムに配送する映像サーバであって、
前記ビデオカメラの共通の映像データから、リアルタイムに配送するための複数の互いに異なる画面サイズの映像データを生成する生成手段と、
前記複数のクライアントに対し、前記生成手段によって生成される映像データのうち、配送を要求する映像データの画面サイズを問い合わせるための情報を前記複数のクライアントに向けて通知する通知手段と、
各クライアントが要求する画面サイズに応じて、前記生成手段によって生成された映像データをそれぞれリアルタイムに配送する配送手段と
を備えることを特徴とする映像サーバ。 - 前記生成手段は、複数の互いに異なる画面サイズの映像データを生成するためのカスケード接続された複数の変倍処理手段を含むことを特徴とする請求項第１項に記載の映像サーバ。
- 前記変倍処理手段のそれぞれは変倍率が２のべき乗の変倍率で、変倍率の大きさ順にカスケード接続されることを特徴とする請求項第２項に記載の映像サーバ。
- 前記配送手段は、前記生成手段によって生成された映像データのうち、各クライアントが要求した画面サイズに近似している画面サイズの映像データをそれぞれ配送することを特徴とする請求項第１項に記載の映像サーバ。
- 前記通知手段は、さらに、要求する映像データの圧縮率、圧縮方式のうち少なくとも１つを問い合わせるための情報を前記複数のクライアントに向けて通知することを特徴とする請求項第１項に記載の映像サーバ。
- ネットワークを介して複数のクライアントにビデオカメラの映像データをリアルタイムに配送する映像サーバの制御方法であって、
前記ビデオカメラの映像データから、リアルタイムに配送するための複数の互いに異なる画面サイズの映像データを生成する生成工程と、
前記複数のクライアントに対し、前記生成工程において生成される映像データのうち、配送を要求する映像データの画面サイズを問い合わせるための情報を前記複数のクライアントに向けて通知する通知工程と、
各クライアントが要求する画面サイズに応じて、前記生成工程において生成された映像データをそれぞれリアルタイムに配送する配送工程と
を備えることを特徴とする映像サーバの制御方法。 - コンピュータが読込み実行することで、ネットワークを介して複数のクライアントにビデオカメラの映像データをリアルタイムに配送する映像サーバとして機能するプログラムを格納したコンピュータ可読記憶媒体であって、
前記ビデオカメラの共通の映像データから、リアルタイムに配送するための複数の互いに異なる画面サイズの映像データを生成する生成手段と、
前記複数のクライアントに対し、前記生成手段によって生成される映像データのうち、配送を要求する映像データの画面サイズを問い合わせるための情報を前記複数のクライアントに向けて通知する通知手段と、
各クライアントが要求する画面サイズに応じて、前記生成工程において生成された映像データをそれぞれリアルタイムに配送する配送手段
として機能するコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36123497A JP3976864B2 (ja) | 1997-12-26 | 1997-12-26 | 映像サーバ及びその制御方法及び記憶媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36123497A JP3976864B2 (ja) | 1997-12-26 | 1997-12-26 | 映像サーバ及びその制御方法及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11196379A JPH11196379A (ja) | 1999-07-21 |
| JP3976864B2 true JP3976864B2 (ja) | 2007-09-19 |
Family
ID=18472750
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP36123497A Expired - Fee Related JP3976864B2 (ja) | 1997-12-26 | 1997-12-26 | 映像サーバ及びその制御方法及び記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3976864B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1131930B1 (en) * | 1999-09-27 | 2007-01-17 | Koninklijke Philips Electronics N.V. | Partitioning of file for emulating streaming |
| JP2002077859A (ja) * | 2000-09-04 | 2002-03-15 | Digitalact:Kk | コンテンツ配信システム |
| CN1327705C (zh) * | 2001-10-16 | 2007-07-18 | 精工爱普生株式会社 | 文件生成装置及数据输出装置 |
| JP4603947B2 (ja) * | 2004-09-03 | 2010-12-22 | キヤノン株式会社 | 画像通信システム、サーバ装置およびその制御方法、並びにコンピュータプログラム |
| JP4926601B2 (ja) | 2005-10-28 | 2012-05-09 | キヤノン株式会社 | 映像配信システム、クライアント端末及びその制御方法 |
| JP4902326B2 (ja) * | 2006-11-29 | 2012-03-21 | 富士フイルム株式会社 | 動画送信サーバおよびその制御方法 |
| JP5401103B2 (ja) | 2009-01-21 | 2014-01-29 | 日立コンシューマエレクトロニクス株式会社 | 動画情報管理装置、および方法 |
| JP5675164B2 (ja) * | 2010-05-11 | 2015-02-25 | キヤノン株式会社 | 送信装置、送信方法、並びにプログラム |
| CN102857667B (zh) * | 2012-09-12 | 2018-10-12 | 康佳集团股份有限公司 | 实现对多媒体播放设备的图片处理的方法及系统 |
| CN114245173B (zh) * | 2021-12-17 | 2023-04-25 | 中国平安财产保险股份有限公司 | 一种图像压缩方法、装置、终端设备和存储介质 |
-
1997
- 1997-12-26 JP JP36123497A patent/JP3976864B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11196379A (ja) | 1999-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113395478B (zh) | 用于提供高分辨率视频流的方法、系统和存储介质 | |
| JP2792454B2 (ja) | 動画検索システム | |
| EP2408196B1 (en) | A method, server and terminal for generating a composite view from multiple content items | |
| EP3804349B1 (en) | Adaptive panoramic video streaming using composite pictures | |
| US8259788B2 (en) | Multimedia stream compression | |
| US8189662B2 (en) | Selection compression | |
| US7359980B2 (en) | Progressive streaming media rendering | |
| US20190364205A1 (en) | Adaptive panoramic video streaming using overlapping partitioned sections | |
| JP2002170113A (ja) | データ通信網を介したディジタル拡大イメージ提供方法およびディジタル拡大イメージ提供装置 | |
| JP3976864B2 (ja) | 映像サーバ及びその制御方法及び記憶媒体 | |
| CN113141352B (zh) | 多媒体数据的传输方法、装置、计算机设备和存储介质 | |
| KR100841412B1 (ko) | 사용자 단말기에 따른 최적의 멀티미디어 서비스 제공 방법및 이를 구현하는 시스템 | |
| JPH09116759A (ja) | 画像復号化装置および画像符号化・復号化システム | |
| CN112738565B (zh) | 互动带宽优化方法、装置、计算机设备和存储介质 | |
| JP2003304525A (ja) | データ配信再生システム、データ配信再生方法、プログラム及び記憶媒体 | |
| CN114501048A (zh) | 以大屏显示为中心的跨屏实时通信交互方法及系统 | |
| Xie et al. | Adapting images on proxies for small form factor devices | |
| IL141104A (en) | Remote computer access | |
| IL173676A (en) | Manipulating a compressed video system | |
| IL173678A (en) | Remote computer access | |
| IL173679A (en) | Providing compressed video |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041118 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041118 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7426 Effective date: 20041118 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20041118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061027 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070312 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070511 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070611 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070620 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100629 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110629 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120629 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120629 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130629 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |