JP4277365B2 - 動画配信システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ビデオカメラから入力された動画データが、サーバによって複数のクライアントに配信される動画配信システムに関する。
【０００２】
【従来の技術】
近年、ビデオカメラ等で得た動画を、インターネット等を介して遠方へ送信する試みが多数なされている。こうような動画配信システムは、例えば、動画を入力するビデオカメラ、ビデオカメラから与えられた動画を配信する動画配信サーバ、動画配信サーバから配信された動画を受信する複数の受信クライアントからなるクライアント・サーバシステムとして構成することができる。この動画配信システムにおいては、動画配信サーバ及び受信クライアントは、インターネット等のネットワークによって接続される。
【０００３】
【発明が解決しようとする課題】
しかし、従来の動画配信システムにおいては、動画配信サーバは、動画データの単純変換及びそのクライアントへの配信に限定した、単純なクライアント・サーバシステムを採用していた。そのため、全てのクライアントに対し、同じ品質の動画データが配信されることになる。ここで、品質とは、動画フレームの大きさや、カラーやグレイスケール（gray scale）のような色、各フレームのデータ圧縮率、フレーム速度等を示す。すなわち、従来の動画配信システムにおいては、各クライアントの要求或いは状況に応じた動画データを個別に作成し、同時配信することはできない。
【０００４】
一方、クライアント側においては、全てが同じネットワーク及び受信環境にある場合は希である。この場合、従来の動画配信システムで安定した送信を実現するためには、動画データを受信環境が劣るクライアントの状況に対応するように配信せざるを得ない。
【０００５】
更に複数のクライアントが同様の受信環境にある場合も、例えばバンド幅のような限られたネットワーク資源の要求配分方法が、例えばフレーム速度重視或いは画質重視など、クライアントにより異なるという事態も有り得る。
【０００６】
このような問題点を解決する一つの方法として、主サーバとクライアントとの間に中間サーバを設置し、主サーバから送信された動画データを一旦中間サーバへ蓄積し、これをクライアントの要求或いは状況に応じて個別に加工し、各クライアントへ送信するというソリューションが考えられる。しかし、この場合には、中間サーバが一旦動画データを保持することから、リアルタイム性が損なわれる。
【０００７】
本発明は、上述の実情に鑑みてなされるものであって、各クライアントの要求或いは状況に応じた動画データを個別に生成して各クライアントに同時に配信すると共に、動画データをリアルタイムに配信するような動画配信システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上述の課題を解決するために、本発明に係る動画配信システムは、入力動画データが入力されるものであって、異なった品質の配信動画データを受信し、その品質の動画を表示する受信手段に対し、入力動画データを構成する単位画像に基づいて、上記品質の配信動画データに加工し、加工された配信動画データを一時的に蓄積し、蓄積された配信動画データを、上記単位画像ごとに配信するものであり、配信手段は、配信手段から受信手段に至る経路の伝送状況と、受信手段における受信状況とに基づいたデータ量の配信動画データを上記受信手段に対して配信し、受信手段に至る経路におけるパケット紛失が回復したときには、配信する配信動画データの品質を、受信手段に現在提供中の配信動画データの動画品質及び受信手段の品質である要求動画品質に対して、数Δ（０＜Δ＜１）について、品質＝現在提供中の動画品質×（１−Δ）＋要求動画品質×Δとして、数Δを漸近的に１に近づけることにより、配信する配信動画データの品質を上記要求動画品質に漸近的に近づける。
【０００９】
【発明の実施の形態】
以下、本発明に係る動画配信システムの実施の形態について、図面を参照して説明する。本実施の形態の動画配信システムは、ビデオカメラ、動画配信サーバ、受信クライアント及びこれらを接続するネットワークからなり、動画配信システムの最小単位を構成するものである。動画配信システムにおいては、一の動画配信サーバに複数の受信クライアントが接続される、いわゆるクライアント・サーバシステムを構成している。
【００１０】
動画配信システムは、図１に示すように、入力動画データを入力するビデオカメラ１と、ビデオカメラ１からの動画データに所定の処理を施す動画配信サーバ２と、動画配信サーバ２にて処理された配信動画データが伝送されるネットワーク４と、ネットワーク４に接続されて動画データが伝送される高速ＬＡＮ（local area network）５と、ネットワーク４に接続されて動画データが伝送される電話回線６と、高速ＬＡＮ５及び電話回線６を介して動画データを受信する受信クライアント３とを有している。
【００１１】
ビデオカメラ１は、被写体を撮像して動画データを出力するものである。ビデオカメラ１は、例えばＮＴＳＣ（national television system comitee）方式による動画データを出力する。
【００１２】
動画配信サーバ２は、ビデオカメラ１から与えられた動画データに対して変換を施し、変換した動画データをネットワーク４に送る。動画配信サーバ２は、ビデオカメラ１から例えばＮＴＳＣ方式の動画データが送られた場合は、例えば輝度信号及び２つの色差信号からなるＹＵＶ方式の動画データに変換する。
【００１３】
動画配信サーバ２は、複数の受信クライアント３から送られる動画配信要求を受ける。動画配信サーバ２は、複数の受信クライアント３の動画配信要求に基づいて、受信クライアント３の受信状況やネットワーク４の伝送状況に基づいて、異なった品質の動画データを各受信クライアント３にネットワーク４を介して実時間で同時に配信する。
【００１４】
ここで、動画データの品質とは、動画データを構成する単位画像であるフレームの大きさ(以後、画サイズと称する。)、カラー或いはグレイスケール（gray scale）のような色、各フレームのデータ圧縮率、フレーム速度等を示すものである。
【００１５】
ネットワーク４は、動画配信サーバ２から出力された動画データが伝送される通信路である。ネットワークの例としては、例えばいわゆるインターネットを挙げることができる。
【００１６】
高速ＬＡＮ５は、大容量のデータを高速に配信することができる局地的なネットワークである。高速ＬＡＮ５は、ネットワーク４と複数の受信クライアント３を接続している。
【００１７】
電話回線６は、データを音声信号に変調して伝送するものである。電話回線６は、ネットワーク４と受信クライアント３を接続している。電話回線６は、受信クライアント３に、端末の電話器６１を介して接続されている。
【００１８】
受信クライアント３は、動画を画面に表示する表示部を有し、配信された動画データを表示部の画面に表示する。受信クライアント３は、自己の受信環境に応じた品質の動画データを配信するように求める動画配信要求を動画配信サーバ２に送る。
【００１９】
このように、動画配信システムは、複数の受信クライアント３の異なる要求、状況に応じた動画データを、それぞれの受信クライアント３へリアルタイムで同時に提供することを可能にするものである。
【００２０】
ここで、参考のために従来の動画配信システムについて述べると、従来の動画配信システムの動画配信サーバは、動画データの単純変換及びその受信クライアントへの送信のみに機能が限定されていたので、一のビデオカメラから動画データが入力されるために、全ての受信クライアントに対し、同じ品質の動画データを提供していた。
【００２１】
また、従来の動画配信システムにおいては、最も環境の劣る受信クライアントに適合するように動画データを配信していた。これは、例えば、一方のクライアントは高速ＬＡＮを通じて動画配信サーバにアクセスしているのに対し、他方のクライアントは電話回線を通じてアクセスしているような状況である。この場合、後者のネットワーク環境は前者と比較すると劣ることになる。このため、動画データの安定した配信を実現するためには、後者の環境に対応するように動画データを配信せざるを得ない。
【００２２】
更に、従来の動画配信システムにおいては、複数の受信クライアントに対して品質が異なる動画データを同時に配信することができなかった。複数の受信クライアントが同様の環境にある場合も、例えばバンド幅のような限られたネットワーク資源の要求配分方法が受信クライアントにより異なるという事態も有り得る。つまり、ある受信クライアントは例えば一秒毎の更新のような低フレーム速度ながら低圧縮フレームの高品質の表示の擬似的な動画を要求するのに対し、別の受信クライアントは高圧縮フレームの低品質の表示ながら例えば１０フレーム毎秒（frame per sec; fps）の高フレーム速度の動画を要求するという場合もある。従来の動画配信システムは、このような要求に対応することができなかった。
【００２３】
従来の動画配信システムにおいては、主サーバである動画配信サーバと受信クライアントの間に中間サーバを設置し、主サーバが送信した動画データを中間サーバに一旦蓄積し、各受信クライアントの要求、状況に応じてこれを加工し、対応するクライアントに個別提供することがあった。この場合には、動画データは一旦中間サーバに蓄積されることから、ビデオカメラより動画データを取り込んだ時刻と、実際に受信クライアントが動画を受信、表示する時刻との間に大きなタイムラグが発生する。すなわち、中間サーバを設置した従来の動画配信システムにおいては、リアルタイム制を保持することができない。更に、中間サーバの導入によりシステムが複雑となり、ひいてはシステムの総コストも上昇する。
【００２４】
本実施の形態の動画配信システムは、上述したような従来の動画配信システムの問題点を解決するものである。
【００２５】
次に、本実施の形態の動画配信システムの動作について説明する。この動画配信システムの動作は、動画配信システムの動画配信サーバ２における処理を制御するフレーム資源割当アルゴリズムに基づいて実行される。
【００２６】
上述したように、動画配信サーバ２には、ビデオカメラ１にて取得された動画データが入力される。ここで、動画データは、一般に、複数の連続した静止画が高速に連続表示されることにより実現されている。例えば、いわゆるＮＴＳＣ規格の動画においては、フレーム速度は３０ｆｐｓであり、一秒間に３０枚のフレームを連続して表示することにより、画面内オブジェクトの動きを表現する。
【００２７】
今、動画配信サーバ２に、ビデオカメラ１で取り込まれたＮＴＳＣ方式の３０ｆｐｓのアナログ動画データが入力され、この動画データを各フレームが完全に独立したいわゆるイントラフレーム（intra frame）型のデジタル圧縮動画データに変換し、ネットワーク４を通じて受信クライアント３に提供する場合を考える。このデジタル圧縮動画データの具体的なフォーマット例としては、いわゆるｍｏｔｉｏｎ ＪＰＥＧ或いは家庭用デジタルビデオカメラ用途であるＤＶフォーマット等が挙げられる。
【００２８】
この様な動画データを提供する動画配信サーバ２に対して、今、受信クライアントＡ及び受信クライアントＢの２つの受信クライアント３が、フレーム速度は共通の１０ｆｐｓながら、受信クライアントＡが例えば６４０×４８０画素（pixel）の大画サイズ、クライアントＢが例えば１６０×１２０画素の小画サイズの動画データ送信を同時に要求したとしよう。
【００２９】
ビデオカメラ１から動画配信サーバ２に与えられ動画データは、３０ｆｐｓであり、一秒間に生成されるフレームは３０枚である。動画配信サーバ２は、３０枚のフレームからそれぞれ１０フレームずつ送信すればよいことになる。したがって、全３０フレームの生成フレームの中で、１／３を受信クライアントＡの大画サイズの要求に従って加工して送信し、別の１／３を受信クライアントＢの小画サイズの要求に従って加工して送信すれば、両クライアントの要求を同時に満たすことが可能となる。
【００３０】
更に、動画配信サーバ２は、各フレームの加工が１／３０秒（sec）内で完了すれば、動画入力時刻と受信クライアントＡ及び受信クライアントＢでの動画表示時刻とのタイムラグを最小に押さえることができる。すなわち、リアルタイム性を保持することができる。
【００３１】
さて、総フレーム資源を、動画データの入力手段であるビデオカメラ１より単位時間当たりに供給されるフレーム数と定義すれば、複数の受信クライアント３からの異なる動画品質要求を同時に満たすことは、受信クライアント３の要求に応じたフレーム資源の割当問題に帰着される。
【００３２】
フレーム資源の割当問題においては、可能な限り等時性を保持すること、及び総フレーム資源には上限があるという制限を満足する必要がある。ここで、等時性とは、連続するフレームを等時間間隔で割当ることをいう。総フレーム資源の上限とは、例えばいわゆるＮＴＳＣ方式に基づいた動画データにあっては、３０ｆｐｓである。
【００３３】
このようなフレーム資源の割当問題を解決するためのフレーム資源割当アルゴリズムについて説明する。フレーム資源アルゴリズムにおいては、生成される動画データは各フレームが完全に独立したイントラフレーム型であること、及び一のフレームは一の受信クライアント３に割当られることが前提となる。
【００３４】
フレーム資源の割当の際、各受信クライアント３に割当られたフレームは、その受信クライアントからの画面サイズ、色、圧縮率等のフレーム加工条件に応じて加工される。尚、複数の受信クライアント３が同じフレーム加工条件を供する場合には、一のフレームを複数の当該受信クライアント３に割当ることが許容される。なお、この場合、総フレーム資源の上限を超えた割当も可能となる。
【００３５】
上述のような構想に従い、フレーム資源を受信クライアントに割当るフレーム資源割当アルゴリズムについて、図２を参照して説明する。
【００３６】
ステップＳ１では、変換された動画データには、各フレーム毎に、シリアル番号（frameNum）を付加する。ステップＳ２では、フレーム割当スケジューラ７として、図３に示すようなリングバッファを準備する。なお、リングバッファの各要素８は、フレームのシリアル番号（frameNum）、フレーム加工条件、割当クライアントＩＤをプロパティとして保持する。
【００３７】
ステップＳ３では、新規動画送信要求に対し、次式
現在提供中のフレーム速度の総和 + 要求フレーム速度 < 総フレーム資源
によってフレーム資源の有無を確認後、フレーム割当スケジューラ７上を走査の上、未だクライアントへの割当のないフレームのシリアル番号（frameNum）を、そのクライアントの初期フレーム番号（initFrameNum）に格納する。
【００３８】
ステップＳ４では、要求されるフレーム速度を、その受信クライアントの割当番号間隔（frameIntvl）に変換し、格納する。ここで受信クライアントの割当番号間隔（frameIntvl）は、次式で算出される。
【００３９】
frameIntvl＝総フレーム資源（fps）／要求フレーム速度（fps）
そして、与えられたフレームのシリアル番号（frameNum）に対し、以下の条件を満たす場合、そのフレームのシリアル番号（frameNum）を持つフレームを当該クライアントに割当る。
（frameNum−initFrameNum）％frameIntvl＝0
ここで％は、剰余演算子を表す。
【００４０】
続いて、上述したフレーム資源の割当アルゴリズムを適用した具体例について、図３を参照して説明する。
【００４１】
この具体例においては、動画配信システムは、受信クライアント３として、受信クライアントＡ及び受信クライアントＢを有するものとする。この動画配信システムにおいては、既に受信クライアントＡに対して、画サイズ：１６０×１２０、色：グレースケール、圧縮率：１／２０、フレーム速度：１５ｆｐｓにてフレームが割当られている。
【００４２】
ここで、受信クライアントＢより、画サイズ：６４０×４８０、色：４．２．２、圧縮率：１／１０、フレーム速度：７．５ｆｐｓの条件で動画送信要求が出されたとしよう。なお、ここで、色に関する４．２．２は、例えばＹＵＶ信号の比率を示している。
【００４３】
受信クライアントＡへは、例えば、受信クライアントの初期フレーム番号
initFrameNum(A)＝1000
及び受信クライアントの割当番号間隔
frameIntvl(A)＝2
より、フレームのシリアル番号
frameNum＝1000, 1002, 1004, ...
なるフレームが割当られているから、受信クライアントＢの送信要求に対し、まずは上記アルゴリズムのステップＳ３より、受信クライアントの初期フレーム番号
initFrameNum(B)＝2501
を与えることが出来る。その後は、受信クライアントの割当番号間隔
frameIntvl(B)＝4
であるから、ステップＳ５より、フレームのシリアル番号
frameNum=2505, 2509, 2513, ...
なるフレームが、受信クライアントＢに割当られることとなる。
【００４４】
なお、受信クライアントＢがフレーム速度：１０ｆｐｓ等の動画を要求した場合、上記アルゴリズムでは、ひとつのフレーム(例えばフレームのシリアル番号frameNum=2504）が受信クライアントＡ及び受信クライアントＢともに割当られることとなる。フレーム加工条件が等しい場合は、このフレームを受信クライアントＡ及び受信クライアントＢの両者の受信クライアント３に割当ればよい。
【００４５】
一方、本具体例のように受信クライアントＡ及び受信クライアントＢの両者のフレーム加工条件が異なる場合、受信クライアントＡ及び受信クライアントＢのそれぞれのクライアントに"優先度"を示すプロパティを持たせ、優先度の低い受信クライアントには、例えば
frameNum＝2505
である次のフレームを割当ることで対処する。
【００４６】
次に、動画配信システムの動画配信サーバ２を中心とした動作について説明する。図４は、動画配信サーバ２及び周辺部の構成を示すものである。図中においては、動画データの流れを太い実線、受信クライアントからのフィードバック情報の流れを細い実線、動画配信サーバ内のシステム制御を破線で示している。なお、図における外部ビデオカメラ１０は、図１におけるビデオカメラに対応している。また、図１における高速ＬＡＮ５及び電話回線６は簡単のために省略し、ネットワーク４のみを示した。
【００４７】
まず、動画配信サーバ９から受信クライアント３に向かう動画データの流れに沿って説明する。
【００４８】
外部ビデオカメラ１０により取り込まれたいわゆるＮＴＳＣ方式による動画データは、動画配信サーバ２に送られる。動画配信サーバ２においては、動画データは、フレーム毎にフレームデータ変換／加工ブロック１１に入力される。フレームデータ変換／加工ブロック１１で各フレームは、いわゆるＮＴＳＣ方式からいわゆるＹＵＶ方式への変換のような適当なデータ変換の後、先に述べたフレーム資源割当アルゴリズムに基づいてそのフレームに割当てられた画サイズ、色についてのフレーム加工条件に従って加工される。
【００４９】
続いて、フレーム毎の動画データであるフレームデータは、フレーム圧縮ブロック１２に入力され、そのフレームに割当られた圧縮率についてのフレーム加工条件に従っていわゆるＪＰＥＧ規格に基づいて圧縮された後、一旦フレームバッファ１３に出力される。その後、フレームバッファ１３内に出力されたフレームデータは、受信クライアント３別に割当てられた複数のフレームメモリ１４に転送される。ここでフレームメモリ１４を準備したのは、フレームが生成される例えば３０ｆｐｓの表示速度と、受信クライアント３からの要求フレーム速度との間のギャップを埋めるためである。その後、フレームメモリ１４に保存されたフレームデータはパケットに分割され、ネットワークインターフェース（network interface）ブロック１５より外部ネットワーク４へとパケット送信される。
【００５０】
なお、以上のフレーム加工制御、パケット送信制御等を始め、各受信クライアント３へのセッション管理、システム資源管理等は全て、システム管理ブロック１６にて実施される。すなわち、システム管理ブロック１６は、外部ビデオカメラ１０に対するビデオカメラ制御、フレーム変換／加工ブロック１１に対するフレーム加工制御、フレーム圧縮ブロック１２に対する圧縮率制御、フレームバッファ１３からフレームメモリ１４へのデータ転送に対するクライアント別割当、フレームメモリ１４からネットワークインターフェースブロック１５へのデータ転送に対するフレームデータのパケット化、及びネットワークインターフェースブロック１５に対するパケット送信制御の各制御を行っている。
【００５１】
続いて、受信クライアント３から動画配信サーバ２に向かうフィードバック情報の流れに沿って説明する。
【００５２】
受信クライアント３から動画配信サーバ２に向かうフィードバック情報は、まずネットワークインターフェースブロック１５にて受信された後、直ちにシステム管理ブロック１６に送られる。ここでフィードバック情報としては、動画送信に対する動画送信開始、動画送信終了、提供動画品質の指示等の基本操作、パンチルト、ズーム等のビデオカメラ１０の操作の他、受信クライアント３のネットワーク４及び受信状況を動画配信サーバ９に伝える為のフィードバック情報を含む。この具体例としては、例えば、受信クライアント３での受信パケット紛失率、受信クライアント３での未表示フレーム数などが挙げられる。
【００５３】
ここで前者の受信クライアント３での受信パケット紛失率は、輻輳の発生等のネットワーク状況を示す指標である。後者の受信クライアント３での未表示フレーム数はネットワーク４を含めた受信クライアント４の受信状況及び画像表示状況を示す指標となる。後者については、例えばネットワーク４が安定状態にある一方、受信クライアント３の処理能力が供給される動画データ量の処理に追い付かない状況等を検出する際に重要な指標となる。
【００５４】
さて、受信クライアント３の要求する動画品質と、受信クライアント３へのネットワーク４及び受信状況に応じた動画品質との間に矛盾が生じる場合、これが定常的な要因に起因していれば、システム安定化の面からは後者を優先することになる。すなわち受信パケット紛失率δをフィードバック情報とした場合、これは、
提供動画品質＝要求動画品質×（１−δ）
等のアルゴリズムを導入することで実現される。なお、パケット紛失率δは、
０＜δ＜１
の範囲にある。
【００５５】
一方、これがネットワーク４の輻輳など一時的な要因に起因している場合、その要因が取り除かれた後には、例えば、
次回提供する動画品質＝現在提供中の動画品質×（１−Δ）＋要求動画 品質×Δ
等のアルゴリズムを用いて、本来提供すべき動画品質へと漸近的に戻していく。ここで、Δは定数であり、範囲
０＜Δ＜１
にある。このようなアルゴリズムを導入することにより、ネットワーク４の状況及び受信クライアント３の受信状況に対応しつつも、出来る限り受信クライアント３の要求に添った品質の動画を提供することが可能となる。
【００５６】
以上のように、受信クライアント３からのフィードバック情報を用いて受信クライアント３について、ネットワーク４の状況及び受信クライアント３の受信状況を動画配信サーバ２内のシステム管理ブロック１６でモニタリングすることにより、受信クライアント３の状況にきめ細やかに対応した動画の提供が実現できる。
【００５７】
次に、上述した本実施の形態に係る動画配信システムの応用例として、複数のビデオカメラ、クライアント及び、インターネット等のオープンネットワークからなる監視カメラシステムについて、図５を参照して説明する。
【００５８】
監視カメラシステムは、動画データを与える複数のビデオカメラ１７と、ビデオカメラ１７からの動画データを配信する動画配信サーバ１８と、動画データを取得すると共にこの動画データを配信するカメラサーバ１９と、動画データを伝送する伝送路であるインターネット２０と、動画データを受信する受信クライアント２１ａ，２１ｂとを有している。
【００５９】
複数のビデオカメラ１７には、それぞれこのビデオカメラ１７からの信号を処理する動画配信サーバ１８が対応している。動画配信サーバ１８は、インターネット２０に直接に接続されている。
【００６０】
複数のカメラサーバ１９は、ビデオカメラと小規模なハードウェアとして構成された動画配信サーバとが一体として構成されたものである。カメラサーバ１９も、インターネット１９に直接に接続されている。カメラサーバ１９は、動画配信サーバが小規模なハードウェアとして実現可能なことから、ビデオカメラと動画配信サーバとを一体化した形態としたものである。
【００６１】
一方、インターネット２０には、クライアントビューアソフトを搭載した受信クライアント２１のコンピュータが複数接続されている。複数の受信クライアント２１ａは、インターネット２０に直接に接続されている。
【００６２】
この受信クライアント２１ａにおいては、図６に模式的に示すようなクライアント画面が表示される。クライアント画面には、ビデオカメラ１７及びカメラサーバ１９にて撮像された映像がリアルタイムで同時に表示されている。
【００６３】
ここでは、各ビデオカメラ１７及びカメラサーバ１９が捉えた映像は小画サイズの動画２２ａ，２２ｂ，２２ｃとして表示されており、指定した映像を大画サイズの高精細な映像２２ｄとして表示する様子を示している。なお、本実施の形態においては、カメラサーバ１９のうちの一方にて捕らえた映像を指定した映像２２ｄとして大画サイズで高精細に表示している。
【００６４】
また、クライアント画面には、各種操作に対応する各種ボタン２２ｅが表示されている。クライアント画面の各種ボタンには、例えば、クライアント画面に表示されるカーソルを図示しない入力手段のマウスを操作することにより、入力を行うことができる。
【００６５】
また、監視カメラシステムにおいては、受信クライアント２１ｂで示すように、他とは異なるネットワーク及び受信環境にある場合も、他のクライアント２１ａに影響を与えることなく、そのクライアント２１ｂの環境に応じた動画データを提供することが可能となる。
【００６６】
すなわち、インターネット２０に接続された電話回線に端末の電話機２５を介して接続されている受信端末２１ｂは、インターネット２０に直接に接続された受信クライアント２１ａとは通信の環境が異なるが、上述したように、動画データはこれらの環境に適合するように配信される。
【００６７】
なお、監視カメラシステムにおけいては、ビデオカメラ１７、動画配信サーバ１８、インターネット、受信クライアント２１ａ，２１ｂは、図１に示した動画配信システムにおけるビデオカメラ１、動画配信サーバ２、受信クライアント３にそれぞれ対応している。また、カメラサーバ１９は、図１に示した動画配信システムにおけるビデオカメラ１及び動画配信サーバ２に対応している。
【００６８】
以上説明したように、本実施の形態は、動画入力装置としてのビデオカメラ、ビデオカメラより入力された動画データをクライアントからの要求に応じて送信する動画配信サーバ及び、これを受信、画面表示する複数のクライアントからなる動画配信システムにおいて、複数のクライアントに対し、クライアントの異なる動画品質要求に応じた動画データを、対応するクライアントへ同時に提供することを可能としたものである。
【００６９】
また、本実施の形態は、一つのカメラからの動画データより、受信クライアントの異なる動画品質要求に応じた複数の動画データをリアルタイムで生成し、これらを対応する品質要求の受信クライアントへ同時に提供することを可能としたものである。
【００７０】
さらに、本実施の形態は、動画入力装置としてのビデオカメラ、ビデオカメラより入力された動画データを受信クライアントからの要求に応じて送信する動画配信サーバ及び、これを受信して画面表示する複数の受信クライアントからなる動画配信システムにおいて、複数の受信クライアントに対し、受信クライアントのネットワーク及び受信状況に応じたデータ量を持つ動画データを、対応する受信クライアントへ同時に提供することを可能としたものである。
【００７１】
そして、本実施の形態は、一つのカメラからの動画データより、受信クライアントの異なるネットワーク及び受信状況に応じた複数の動画データをリアルタイムで生成し、これらを対応する受信クライアントへ同時に提供するものである。
【００７２】
更に、本実施の形態は、受信クライアントが受信或いは表示したデータに関する統計量をフィードバックとして得ることで、動画配信サーバが各受信クライアントのネットワーク及び受信状況を把握することを可能としたものである。
【００７３】
また、本実施の形態は、定期的に連続して生成される静止画データより、複数クライアントからの異なる動画品質要求、或いは受信クライアントのネットワーク及び受信状況に応じた複数の動画データをリアルタイムで生成するものである。
【００７４】
なお、上述の実施の形態においては、本発明の応用として、インターネットを用いた監視カメラシステムの例を挙げたが、その他の応用として、定点観測カメラシステム、交通モニタリングシステム、環境モニタリングシステム等、ビデオカメラを用いた様々な監視、モニタリングシステムへの展開が可能である。
【００７５】
【発明の効果】
上述のように、本発明によると、単一の入力手段から得られる動画データを、複数の受信手段に対し、異なる動画品質条件で送ることが可能となる。つまり、複数の受信手段からの異なる動画品質要求に対し、リアルタイムで同時に応えることが出来る。また、様々なネットワーク、受信受信にある複数の受信手段に対し、その受信手段の状況にきめ細やかに対応した品質の動画を、リアルタイムで同時に提供することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態としての動画配信システムの概略的な構成を示すブロック図である。
【図２】フレーム資源割当アルゴリズムを示すフローチャートである。
【図３】フレーム資源割当に用いるリングバッファを示す図である。
【図４】動画配信システムの要部を示すブロック図である。
【図５】監視カメラシステムの構成を示すブロック図である。
【図６】クライアント画面を模式的に示す図である。
【符号の説明】
１ ビデオカメラ、２ 動画配信サーバ、３ 受信クライアント、４ ネットワーク、５ 高速ＬＡＮ、６ 電話回線

Claims (6)

1. 入力動画データが入力される入力手段と、
   異なった品質の配信動画データを受信し、その品質の動画を表示する複数の受信手段と、
   上記入力手段からの入力動画データを、構成する単位画像に基づいて、上記受信手段に対応する品質の配信動画データに加工する加工手段と、
   上記加工手段で加工された配信動画データを一時的に蓄積するバッファと、
   上記バッファに蓄積された配信動画データを、上記受信手段に上記単位画像ごとに配信する配信手段とを有し、
   上記配信手段は、
   上記配信手段から上記受信手段に至る経路の伝送状況と、上記複数の受信手段における受信状況とに基づいたデータ量の配信動画データを上記受信手段に対して配信し、
   上記受信手段に至る経路におけるパケット紛失が回復したときには、配信する配信動画データの品質を、上記受信手段に現在提供中の配信動画データの動画品質及び上記受信手段の品質である要求動画品質に対して、数Δ（０＜Δ＜１）について、
   品質＝現在提供中の動画品質×（１−Δ）＋要求動画品質×Δ
   として、数Δを漸近的に１に近づけることにより、配信する配信動画データの品質を上記要求動画品質に漸近的に近づける動画配信システム。
2. 上記品質は、上記配信動画データを構成する単位画像の大きさ、カラー若しくはグレースケールの色、各単位画像のデータ圧縮率又は上記静止画の表示速度の少なくとも一である請求項１記載の動画配信システム。
3. 上記配信手段は、上記受信手段に至る経路におけるパケット紛失率δについて、配信する配信動画データの品質を、上記受信手段における配信動画データの品質である要求動画品質に対して、
   品質＝要求動画品質×（１−δ）
   にて与える請求項１記載の動画配信システム。
4. 上記入力手段は、一のビデオカメラである請求項１記載の動画配信システム。
5. 上記入力手段は、静止画データを入力し、上記配信手段は、上記入力手段から与えられた静止画データに基づいて、配信動画データを配信する請求項１記載の動画配信システム。
6. 入力動画データが入力される一のビデオカメラと、
   異なった品質の配信動画データを受信し、その品質の動画を表示する複数の受信手段と、
   入力手段である上記一のビデオカメラからの入力動画データを、構成する単位画像に基づいて、上記受信手段に対応する品質の配信動画データに加工する加工手段と、
   上記加工手段で加工された配信動画データを一時的に蓄積するバッファと、
   上記バッファに蓄積された配信動画データを、上記受信手段に上記単位画像ごとに配信する配信手段とを有し、
   上記配信手段は、
   上記配信手段から上記受信手段に至る経路の伝送状況と、上記複数の受信手段における受信状況とに基づいたデータ量の配信動画データを上記受信手段に対して配信し、
   上記受信手段に至る経路におけるパケット紛失が回復したときには、配信する配信動画データの品質を、上記受信手段に現在提供中の配信動画データの動画品質及び上記受信手段の品質である要求動画品質に対して、数Δ（０＜Δ＜１）について、
   品質＝現在提供中の動画品質×（１−Δ）＋要求動画品質×Δ
   として、数Δを漸近的に１に近づけることにより、配信する配信動画データの品質を上記要求動画品質に漸近的に近づける動画配信システム。

Images