説明

映像配信装置及び映像配信方法

【課題】メモリを効率的に使用することで、データ落ちの少ない映像配信をより多くのクライアントへ提供できるようにする。
【解決手段】特定の相手装置への配信処理が映像フレームの生成より遅れていることを検出すると、前記配信制御手段が保持している一送信単位の映像フレーム数を減少し、その後、一定期間について前記配信処理の遅延が解消したことを検出すると前記配信制御手段が保持している一送信単位の映像フレーム数を増加するようにして、生成された画像データを一時的に保存できなくなって画像データを連続で送れなくなったり、配信するクライアント数を制限したりしなければならなくなってしまう不都合が発生しないようにする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は映像配信装置及び映像配信方法に関し、特に、搭載メモリが少ない組込み機器が多人数に映像を配信する際に、メモリを効率的に使用するために用いて好適な技術に関するものである。
【背景技術】
【0002】
近年、インターネットなどIP(Internet Protocol)ネットワークを利用した配信システムが増加してきている。例えば、スキー場や動物園の状況を配信するインターネットサイトに採用されており、他にも店舗・ビル監視などにも採用されている。前述の配信システムは、監視用途にも使用されるため、配信画像の遅延を小さく抑える必要があり、高いリアルタイム性が求められている。また、同時に多数のクライアントに配信することが求められている。
【0003】
従来、多人数に配信する際は、サーバ上のメモリにその時接続している全クライアントの配信データを一時的に保持しながら、各クライアントの配信速度に合わせて配信処理を行っていた。
【0004】
例えば、特許文献1ではネットワークの障害等が原因で送信の遅延や中断が発生した場合に、送信できなかった過去の映像フレーム群を破棄して、常に最新の映像フレーム群を送信する方法が開示されている。
また、特許文献2では音声とマルチメディアデータを伝送するネットワークにおいて、マルチメディアデータのフラグメントサイズを動的に変更する方法が開示されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2005−086362号公報
【特許文献2】特開2000−022749号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
前述の特許文献1に開示された従来技術では、多数のクライアントに映像配信する際に、ネットワーク帯域が狭い等の理由で配信処理が間に合わないクライアントが複数存在した場合、一時的に保持しなければならないデータ量が増えてしまう。このような場合には、配信サーバが使用できるメモリ容量が不足する。このため、生成された画像データを一時的に保存できなくなって画像データを連続で送れなくなったり、配信するクライアント数を制限したりしなければならなくなってしまう。
本発明は前述の問題点に鑑み、メモリを効率的に使用することで、データ落ちの少ない映像配信をより多くのクライアントへ提供できるようにすることを目的とする。
【課題を解決するための手段】
【0007】
本発明の映像配信装置は、映像フレームを生成して符号化する撮像処理手段と、前記撮像処理手段により符号化された映像フレームを一時保存する一時記憶部と、前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御手段と、前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理手段と、前記配信制御手段により行われる配信処理の遅延状況を監視する遅延監視手段とを有し、前記遅延監視手段は、前記配信制御手段により行われている特定の相手装置への配信処理が映像フレームの生成より遅れていることを検出すると、前記配信制御手段が保持している一送信単位の映像フレーム数を減少し、その後、一定期間について前記配信処理の遅延が解消したことを検出すると前記配信制御手段が保持している一送信単位の映像フレーム数を増加することを特徴とする。
【発明の効果】
【0008】
本発明によれば、配信処理が間に合わなくなったクライアントのフラグメントに含まれる画像フレーム数を減らすようにしたので、クライアントが送信するデータを新しいフレームに集中させることができる。これにより、一時的にメモリ上に保持しなければならないデータ量を減らすことができ、データ落ちの少ない映像配信をより多くのクライアントへ提供することができる。
【図面の簡単な説明】
【0009】
【図1】配信カメラサーバのハードウェア構成を説明するブロック図である。
【図2】配信カメラサーバのソフトウェア機能構成の概略を示すブロック図である。
【図3】撮像処理プログラムの動作手順を説明するフローチャートである。
【図4】配信制御プログラムの動作手順を説明するフローチャートである。
【図5】遅延監視プログラムの動作手順を説明するフローチャートである。
【図6】配信遅延が発生したクライアント情報の例を示す図である。
【図7】フラグメントサイズ5固定時のメモリ使用量を説明する図である。
【図8】第1の実施形態を適用時のメモリ使用量を説明する図である。
【図9】配信制御プログラムの第2の例を説明するフローチャートである。
【図10】メモリ監視プログラムの動作手順を説明するフローチャートである。
【図11】第2の実施形態を適用時の一時記憶部の使用量を説明する図である。
【発明を実施するための形態】
【0010】
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。
(第1の実施形態)
以下、本発明の実施に好適な配信システムの第1の構成例と動作について、図面を用いながら説明する。なお、音声データの配信は画像データの配信処理とデータの内容が異なるだけで同列に扱えるため、本実施形態では画像データの配信を中心に説明する。
【0011】
図1は、本発明の第1の実施形態を表す配信カメラサーバのハードウェア構成を説明するブロック図である。
図1に示すように、本実施形態の配信カメラサーバはCPU100、1次記憶装置110、2次記憶装置120、画像キャプチャI/F130、音声キャプチャI/F140、ネットワークI/F160が内部バス101を介して相互に接続されている。
【0012】
ここで、1次記憶装置110はRAMに代表される書き込み可能な高速の記憶装置で、OSや各種プログラム及び各種データがロードされ、またOSや各種プログラムの作業領域としても使用される。2次記憶装置120はFDDやHDD、フラッシュメモリ、CD−ROMドライブ等に代表される不揮発性を持った記憶装置で、OSや各種プログラム及び各種データの永続的な記憶領域として使用される他に、短期的な各種データの記憶領域としても使用される。カメラサーバの1次記憶装置110及び2次記憶装置120に置かれる各種プログラム等の詳細については後述する。
【0013】
画像キャプチャI/F130にはカメラ170が接続され、カメラ170が撮影した画像データを所定のフォーマットに変換・圧縮して1次記憶装置110に転送する。音声キャプチャI/F140にはマイク180が接続され、マイク180が集音した音データを所定のフォーマットに変換・圧縮して1次記憶装置110に転送する。ネットワークI/F160はEthernet(登録商標)等の通信媒体190と接続するためのI/Fであり、通信媒体190を介してクライアント等との通信を担う。カメラサーバとクライアント間のネットワークは通信規格を満足する複数のルータ、スイッチ、ケーブル等から構成される。本実施形態においては各サーバ・クライアント間の通信が支障なく行えるものであればその通信規格、規模、構成を問わない。故に、インターネットからLAN (Local Area Network)にまで適用可能である。
【0014】
図2(A)は、配信カメラサーバのソフトウェア機能構成の概略を示すブロック図である。
図2(A)に示すように、1次記憶装置110には、OS、撮像処理プログラム210、配信制御プログラム211、通信処理プログラム212、一時記憶部213、及び遅延監視プログラム214がロードされる。OSはカメラサーバ全体を制御する基本プログラムであり、本実施形態の映像配信装置200の主要な構成要件がOSによって構成される。
【0015】
撮像処理プログラム210は、カメラ170で生成された画像フレーム(映像フレーム)を画像キャプチャI/F130を経由して取得し符号化して、一時記憶部213に一時保存する。そして、不要になった画像フレームを一時記憶部213から削除する。配信制御プログラム211は、各種クライアントからのリクエストに応じ、一時記憶部213に保存されている単数または複数の画像フレームを一送信単位とし、通信処理プログラム212を通して配信する。本実施形態では理解しやすくするため、特に説明しない限り5フレームを1GOP(Group Of Pictures)とし、5フレームを一送信単位(以下、1フラグメント)として配信するものとする。
【0016】
通信処理プログラム212は、ネットワークI/F160を制御し、通信媒体190を介して通信の相手装置である各種クライアントへ配信データを送り届ける。遅延監視プログラム214は、画像フレームが一時記憶部213に保存された際に各種クライアントへの配信処理が遅延しているかどうかを判定し、配信処理の遅延状況を監視する。また、本実施形態では配信処理が遅延判定タイミングを画像フレームが一時記憶部213に保存されたタイミングで実施するが、クライアント毎(相手装置毎)にフラグメント分の画像フレームを送信完了したタイミング、または定期的なタイミングで実施してもよい。各プログラム同士の連携は、必要に応じてOSが提供する機能を用いることとする。
【0017】
図3は、配信カメラサーバの撮像処理プログラム210の動作手順を説明するフローチャートである。撮像処理プログラム210は、装置が電源投入された時に起動する。
起動されると、S300において画像キャプチャI/F130を初期化する。次に、S301においてカメラ170から画像フレームが供給されるのを待機する。
【0018】
S301の待機状態において、画像フレームが生成されるとS302に進んで符号化を行う。その後、S303に進み、一時記憶部213の空き容量をチェックする。このチェックの結果、一時記憶部213に空きがなければS301に戻る。この場合は、画像フレームは保存されず次の画像フレームの生成待ちとなる。また、S303のチェックの結果、バッファに空きがあれば、S304に進み、画像フレームを保存し、最新フレーム番号を更新する。
【0019】
次に、S305において、現在配信している特定のクライアントが存在するか判断する。この判断の結果、特定のクライアントが存在しない場合には待機状態となる。また、配信クライアントが存在する場合にはS306に進み、一時記憶部213に存在するクライアント情報に画像フレームを登録する。次に、S307において未送信フレーム数が次フラグメントサイズより多いかどうかを判断する。次フラグメントサイズとは、次の送信時に何枚の画像フレームを一送信単位としてクライアントに配信するかを示す値である。
【0020】
S307の判断の結果、未送信フレーム数の方が多い場合、S308に進んで未送信フレームの古いデータを次フラグメントサイズ以下になるまで登録解除する。その後、S309に進む。また、S307の判断の結果、未送信フレーム数の方が多くない場合は、S309に直接進む。
【0021】
S309においては、S306〜S308の処理を全ての配信クライアントに対して行ったか否かを判断する。この判断の結果、行っていない場合にはS306に戻り、前述した処理を実行する。また、行った場合にはS310に進む。S310においては、遅延監視プログラム214に画像生成通知メッセージを送信する。
次に、S311に進み、クライアントへの送信処理が完了し、どのクライアントにも登録されていない登録解除済み画像フレームを一時記憶部213から解放し、その後、S301の画像生成待ち処理に戻る。
【0022】
図4は、配信カメラサーバの配信制御プログラム211の動作手順を説明するフローチャートである。配信制御プログラム211は、クライアントから配信リクエストを受信した時に起動される。
起動されると、S400においてクライアント情報を生成し、一時記憶部213に保存する。本実施形態では、この時、何枚の画像フレームを一送信単位としてクライアントに配信するかという次フラグメントサイズを「5」に設定する。
【0023】
次に、S401に進み、遅延監視プログラム214からのメッセージ受信処理を行う。その後、S402において受信メッセージ毎に振り分けを行う。遅延監視プログラム214から配信遅延通知を受信していた場合は次フラグメントサイズを小さくし(S403)、配信復旧通知を受信していた場合は次フラグメントサイズを大きくする(S404)。本実施形態では、配信遅延通知を受信した場合は次フラグメントサイズを所定値(例えば「5」)から所定値(例えば「1」)に減少させ、一送信単位の映像フレーム数が減少する。また、配信復旧通知を受信した場合は次フラグメントサイズを「1」から「5」に増加させ、一送信単位の映像フレーム数を増加させる。また、配信遅延通知または配信復旧通知を遅延時間に応じて段階的に通知し、一送信単位の最大数を複数段階で変更することも可能である。また、S402の処理において、メッセージがない場合にはS403あるいはS404の処理を行わずにS406に進む。
【0024】
本実施形態においては、生成した画像フレームの情報は撮像処理プログラム210がクライアント情報に適宜書き込むので、S406においては、未送信フレームが次フラグメントサイズ分存在するかどうかを判断する。未送信フレームが次フラグメントサイズに満たない場合は一定時間の待機を行い(S405)、メッセージ受信処理(S401)に戻る。
【0025】
未送信フレームが次フラグメントサイズ以上存在している場合は、先頭フレームの連続性をチェックする(S407)。具体的には、未送信フレームの先頭が前回送信したデータの次フレームである、または先頭がフレーム内符号化された画像フレーム(以下、Iフレームと呼ぶ)であるかどうかをチェックする。
【0026】
S407のチェックの結果、連続性がない(どちらも満たさない)場合は、先頭の画像フレームはクライアント側で受信しても表示できないため一定時間の待機を行い(S405)、メッセージ受信処理(S401)に戻る。一定時間の待機を行うことで、撮像処理プログラム210が新たに画像フレームを生成し、未送信フレーム情報を書き換える。
【0027】
一方、S407のチェックの結果、連続性がある(どちらかを満たす)場合は、一時記憶部213に保存してあるクライアント情報を更新する(S408)。次に、未送信フレームの先頭から次フラグメントサイズ分の画像フレームとそのヘッダ情報を作成し、通信処理プログラム212を通してクライアントに送信する(S409)。
【0028】
S409の送信処理が完了したら、S410において次データを送信する必要があるかどうかを確認する。この確認の結果、次のデータを送信する場合はメッセージ受信処理(S401)に戻る。クライアントへの送信処理において通信の切断が検出された場合、またはクライアント要求分の画像フレームの配信が完了した場合は、S411に進み、一時記憶部213に保存しているクライアント情報を解放し、処理を終了する。
【0029】
図5は、配信カメラサーバの遅延監視プログラム214の動作手順を説明するフローチャートである。
遅延監視プログラム214は、装置が電源投入された時に起動する。
起動されると、S500において他のプログラムからメッセージを受信するまで待機状態になる。そして、メッセージを受信すると、S501に進み、それが遅延チェックするメッセージであるかを確認する。本実施形態では、撮像処理プログラム210からの画像生成通知を遅延チェックするメッセージとする。画像生成のタイミング以外にもクライアントの配信完了のタイミング、または一定時間の経過タイミング、またはこれらの組合せのタイミングで行うことも可能である。
【0030】
S501の確認の結果、画像生成通知でなかった場合は、S500に戻り、再度メッセージ受信待ちとなる。また、画像生成通知を受信した場合は、配信しているクライアント全員に対して以下の処理を繰り返す。まず、S502に進み、クライアントの状態を判断し、配信クライアントの状態により、処理を振り分ける。
【0031】
すなわち、S502の判断の結果、クライアントに配信遅延が発生していない場合(配信遅延なし)は、S503に進んで送信フレームの最終画像フレームと未送信フレームの先頭フレームが連続かどうかを判断する。この判断の結果、連続の場合は何もしない。非連続の場合、つまり撮像処理プログラム210のS308にて未送信フレームの登録解除が行われた場合は、配信制御プログラム211に配信遅延通知を送り(S504)、クライアントの状態を配信遅延中に変更する(S505)。
【0032】
クライアントに配信遅延が発生している場合(配信遅延中)は、まず一定時間以上データを破棄せずに送信できているかをチェックする(S506)。具体的には、連続送信フレーム数が配信遅延の復旧を示す一定フレーム数以上になったかどうかで判断する。この判断の結果、一定時間に達しない場合は、何もしない。一定時間に達した場合は、配信制御プログラム211に配信復旧通知を送り(S507)、クライアントの状態を配信遅延なしに変更する(S508)。S505またはS508の処理を終了したら、S509に進み、全てのクライアントについて配信状態の判断を行ったか否かを判断する。この判断の結果、行っていない場合にはS502に戻って前述の処理を行う。また、行ったS500に戻る。
【0033】
図6は、配信遅延が発生したクライアント情報の例を示す図である。
図6を用いて、クライアント情報に保持される情報がフレーム生成や配信処理の過程で変わっていく様子を説明する。ただし、図6はあくまで一例であり、必ずしも図中の変数を使用し、図通りの順序で処理が実行されるわけではない。
【0034】
送信フレーム番号は、配信制御プログラム211が変更する送信中の画像フレームの先頭番号であり、未送信状態は−1が設定される。
送信フラグメントサイズは、配信制御プログラム211が変更する送信中の画像フレーム数であり、未送信状態は0が設定される。
未送信フレーム番号は、撮像処理プログラム210が変更する送信待ち画像フレームの先頭番号であり、未送信状態は−1が設定される。
未送信フレーム数は、撮像処理プログラム210が変更する送信待ち画像フレーム数である。
次フラグメントサイズは、次に送信するフラグメントの画像フレーム数であり、配信制御プログラム211が配信遅延通知または配信復旧通知を受信した際に増減する。本実施形態では、配信遅延が発生すると次フラグメントサイズは「1」に変更され、配信復旧が発生すると次フラグメントサイズは「5」に変更される。
連続送信フレーム数は、連続で送信している画像フレーム数であり、一枚でも画像フレームを送信しなければ0に設定される。
【0035】
フレーム番号0(最初はIフレーム)が生成された時、未送信フレームに0が設定され、未送信フレーム数がインクリメントされて1に設定される。フレーム番号1,2,3が生成されると、未送信フレーム数が2,3,4に順番に増えていく。
【0036】
そして、フレーム番号4が生成された時、ちょうど次フラグメントサイズである5フレームになるので、配信制御プログラム211は送信処理を開始する。そして、送信フレーム番号を0、送信フラグメントサイズを5に変更、連続送信フレーム数に5を加算し、未送信フレーム番号と未送信フレーム数を初期状態に変更する。
【0037】
フレーム番号5が生成された時、未送信フレーム番号に5を登録し、未送信フレーム数をインクリメントし1に変更する。そして、フレーム番号0〜5の送信が完了する前に、フレーム番号6、7、8、9が生成されると、未送信フレーム数が2、3、4、5に順番に増えていく。フレーム番号9が生成された時は、本クライアントが使用するフレームは0〜9までの10フレームである。
【0038】
フレーム番号10が生成されると、撮像処理プログラム210にて未送信フレーム番号を10に変更し、フレーム番号5〜9の登録を解除する。そして、遅延監視プログラム214にて送信フレームの最終フレーム番号4と未送信フレームの先頭フレーム番号10から配信遅延を検出し、配信制御プログラム211にて次フラグメントサイズを「1」に変更する。
【0039】
フレーム番号11が生成されると、次フラグメントサイズは「1」なので未送信フレーム番号を1に更新し、未送信フレーム数を1に設定する。フレーム番号12が生成された時も同様に未送信フレーム番号を更新する。フレーム番号10、11、12では、クライアントが使用するフレームは、フレーム番号0〜4とフレーム10(または11、または12)の合計6フレームである。
【0040】
次に、送信処理が完了したとすると、未送信フレーム番号12の送信を試みるが、S407にて連続性がないと判断されるため(先頭がIフレームでないため)、送信処理が実行されない。
次のIフレームであるフレーム番号15が生成されると送信フレーム番号を15、送信フラグメントサイズを「1」、連続送信フレーム数を1に変更し、未送信フレーム番号と未送信フレーム数を初期状態に変更する。
【0041】
フレーム番号16が生成されると、未送信フレーム番号に16を保存し、未送信フレーム数をインクリメントして1に変更する。フレーム番号16以降では、クライアントが使用するフレームはフレーム番号15と未送信フレームの1フレームの合計2フレームになる。
【0042】
以上のように、フラグメントサイズが「5固定」であった期間は、1クライアントが使用するフレーム数は最小で5フレーム、最大で10フレームであったが、フラグメントサイズが1に変更された後は最小で1フレーム、最大で2フレームになる。
【0043】
図6は、配信処理が遅延した場合のクライアント情報の説明である。フレーム番号5〜9が生成される間に配信処理が完了するような充分な配信能力があるクライアントに対しては配信遅延を検出しない。このため、フラグメントサイズが「5」のままなので今までと変わりなく配信することができる。
【0044】
本実施形態では、リアルタイム性を高めるため、一時的に保持する画像フレームは次の1フラグメントのみとして説明しているが、複数フラグメントを一時的に保持しても構わない。また、次フラグメントを越えて次の画像フレームを生成した場合に配信遅延を検出しているが、実際はフレーム内符号化されたIフレームと、フレーム間符号化されたPフレーム/Bフレームとではデータサイズが異なる。このため、1GOP単位でデータサイズを計算し、そこから配信する次フラグメントのデータ量に応じた時間を算出し、その時間を超えた場合に遅延を検出するなどが有効である。
【0045】
図7は、フラグメントサイズが「5固定」で、複数クライアントに配信した際の一時記憶部213の状態を説明する図である。図7では、配信能力が画像生成の半分程度のクライアント701と配信能力が画像生成より充分高いクライアント702の例である。
【0046】
図7において、クライアント701は最初のフラグメント(フレーム番号0〜4)を配信している間に、フレーム番号12まで生成され、フレーム番号5〜9は登録解除されていることを示している。
クライアント702は、フレーム番号0〜4は送信済みで登録解除しており、フレーム番号5〜9を送信中で、フレーム番号10〜12は送信待ちになっていることを示している。
【0047】
配信カメラサーバの一時記憶部213の画像用メモリ領域は全クライアント共通で使用しており、最大で15フレーム分保持できるとすると、画像用メモリの使用量は86パーセント(13/15フレーム)となる。
【0048】
図8は、本実施形態を適用し、複数クライアントに配信した際の一時記憶部213の状態を説明する図である。本図では、配信能力が画像生成の半分程度のクライアント801と、配信能力が画像生成より充分高いクライアント802の例である。
【0049】
クライアント801は、遅延を検出してフラグメントサイズは1になっており、5フレーム中2フレームを毎回送信している状態である。この時使用しているフレームは2フレームである。
クライアント802は、図7と同様に充分な配信能力があるので、5フレーム単位で全てのフレームを送っていることを示している。この時使用しているフレームは8フレームである。
【0050】
配信カメラサーバの一時記憶部213の画像用メモリ領域は全クライアント共通で使用しており、最大で15フレーム分保持できるとすると、画像用メモリの使用量は53パーセント(8/15フレーム)となる。
【0051】
このように本実施形態を適用し、遅延クライアントのフラグメントサイズを減らすことで画像用メモリの参照を最近のデータに集中させることができ、メモリの使用効率を向上させることができる。また、メモリの使用効率を向上させることで、画像フレームを生成時に一時記憶部213に保存できなくなることが減り、画像フレーム落ちの少ない映像配信ができる。同時に、複数クライアントに配信してもメモリの使用量は大きく増えないので、より多くのクライアントへ配信することができる。
【0052】
(第2の実施形態)
以下、本発明の実施に好適な配信システム第2の構成と動作について、図面を用いながら説明する。なお、音声データの配信は画像データの配信処理とデータの内容が異なるだけで同列に扱えるため、本実施形態では画像データの配信を中心に説明する。また、本実施形態における配信カメラサーバのハードウェア構成は、図1と同じため省略する。
【0053】
図2(B)は、配信カメラサーバのソフトウェア機能構成を説明するブロック図である。
1次記憶装置110には、OS、撮像処理プログラム910、配信制御プログラム911、通信処理プログラム912、一時記憶部913、及びメモリ監視プログラム914がロードされる。
【0054】
OSはカメラサーバ全体を制御する基本プログラムであり、本実施形態の映像配信装置900の主要な構成要件がOSによって構成される。
撮像処理プログラム910は、カメラ170で生成された画像フレームを画像キャプチャI/F130を経由して取得し符号化して、一時記憶部913に保存する。そして、不要になった画像フレームを一時記憶部913から削除する。
配信制御プログラム911は、各種クライアントからのリクエストに応じ、一時記憶部913に保存されている単数または複数の画像フレームを一送信単位とし、通信処理プログラム912を通して配信する。
【0055】
本実施形態では理解しやすくするため、特に説明しない限り5フレームを1GOP(Group Of Pictures)とし、5フレームを一送信単位(以下、1フラグメント)として配信するものとする。
【0056】
通信処理プログラム912は、ネットワークI/F160を制御し、通信媒体190を介して各種クライアントへ配信データを送り届ける。
メモリ監視プログラム914は、画像フレームが一時記憶部913に保存された際にメモリの使用量を計算し、空き容量が充分かどうかを判定する。
また、本実施形態では配信処理が遅延判定タイミングを画像フレームが一時記憶部913に保存されたタイミングで実施するが、クライアント毎にフラグメント分の画像フレームを送信完了したタイミング、または定期的なタイミングで実施してもよい。
各プログラム同士の連携は、必要に応じてOSが提供する機能を用いることとする。
各プログラムは特に記述がない限り、図2の対応するプログラムと同じ処理を行うものとする。
【0057】
本実施形態における撮像処理プログラム910のフローチャートの説明は、図3と同じため省略する。
図9は、配信カメラサーバの配信制御プログラム911の動作手順を説明するフローチャートである。この配信制御プログラム911は、クライアントから配信リクエストを受信した時に起動される。なお、図9のフローチャート各ステップの処理において、図4のフローチャートで説明した処理と同様な処理を行うステップについては、図4のステップ番号と同一のステップ番号を付して説明を省略する。
【0058】
S402の受信メッセージ毎に振り分け処理の結果、メモリ監視プログラム914からメモリ逼迫通知を受信していた場合は次フラグメントサイズが逼迫時の最大フラグメントサイズを越えているかどうかを判定する(S903)。この判定の結果、越えていた場合は次フラグメントサイズを逼迫時の最大フラグメントサイズに変更する(S904)。メモリ監視プログラム914からメモリ復旧通知を受信していた場合は、次フラグメントサイズが逼迫時の最大フラグメントサイズと同じ、且つ連続で一定期間以上送信できているかどうかを判定する(S905)。この判定の結果、満たしている場合は遅延が解消したとして、次フラグメントサイズを増加させる(S906)。また、S402の振り分け処理において、メッセージがない場合にはS406に進む。
【0059】
本実施形態では、メモリ逼迫通知を受信した場合は次フラグメントサイズを所定値(例えば「5」)から所定値(例えば「2」)に減少させ(S904)、メモリ復旧通知を受信した場合は次フラグメントサイズを「2」から「5」に増加させる(S906)。しかし、メモリ逼迫通知またはメモリ復旧通知をメモリの使用量に応じて段階的に通知し、次フラグメントサイズを段階的に変更することも可能である。
S904またはS906の処理を終了した後の処理は、前述した図4のS406〜S411の各処理と同様であるので、詳細な説明を省略する。
【0060】
図10は、配信カメラサーバのメモリ監視プログラム914の動作手順を説明するフローチャートである。
【0061】
メモリ監視プログラム914は、装置が電源投入された時に起動する。
起動されると、他のプログラムからメッセージを受信するまで待機状態になる(S1000)。そして、メッセージを受信すると、それがメモリチェックするメッセージであるかを確認する(S1001)。本実施形態では、撮像処理プログラム910からの画像生成通知を遅延チェックするメッセージとする。なお、画像生成のタイミング以外にもクライアントの配信完了のタイミング、または一定時間の経過タイミング、またはこれらの組合せのタイミングで行うことも可能である。また、画像生成通知でなかった場合は、再度メッセージ受信待ち(S1000)に戻り、画像生成通知を受信した場合は、S1002に進む。
【0062】
S1002においては、画像用メモリの状態を判断する。この判断の結果、画像用メモリが通常(初期状態)の場合にはS1003に進む。S1003においては、現在の画像用メモリの使用量を測定し、使用量が上限の閾値以上かどうかを判定する。
【0063】
S1003の判定の結果、上限閾値に満たない場合は何もしない。上限閾値を上回った場合は、S1004において配信制御プログラム911にメモリ逼迫通知を送り、その後、S1005において画像用メモリの状態を逼迫中に変更する。本実施形態ではメモリ使用量の上限閾値を一時記憶部913に保持できる最大画像フレーム数の80パーセントとするが、単純に一時記憶部913内の画像用メモリ容量の80パーセントとすることも可能である。
【0064】
一方、S1002の判断の結果、画像用メモリの状態が逼迫中の場合は、S1006に進み、画像用メモリの使用量が復旧閾値(下限閾値)を下回ったかをチェックする。このチェックの結果、復旧閾値を下回らない場合は、何もしない。また、復旧閾値を下回った場合はS1007に進み、配信制御プログラム911にメモリ復旧通知を送る。その後、S1008に進み、画像用メモリの状態を通常に変更する。
【0065】
メモリ監視プログラム914は、一時記憶部913のメモリ使用量が上限閾値を上回ったことを検出すると、映像フレームの一送信単位が所定の上限値を超える相手装置への一送信単位(例えば「5」)を所定値(上限値未満、例えば「2」)に減少させる。
また、一時記憶部913のメモリ使用量が復旧閾値を下回ったことを検出すると、映像フレームの一送信単位を増加させる。一送信単位が所定値(例えば「2」)に減少するように設定されていた相手装置への一送信単位は、減少される前の値(例えば「5」)に増加させる。すなわち、本実施形態においては、下限閾値は複数の閾値を持ち、一送信単位に含まれる映像フレーム数の最大値を増減させるようにしている。
【0066】
本実施形態では、メモリ使用量の復旧閾値を一時記憶部913に保持できる最大画像フレーム数の30パーセントとするが、単純に一時記憶部913内の画像用メモリ容量の30パーセントとすることも可能である。また、下限閾値を段階的に複数設定して複数の閾値を保持しておき、次フラグメントサイズを段階的に変更したり、次フラグメントサイズを急激に何度も変更したりするようにすることもできる。そこで、次フラグメントサイズを小さくした場合は一定期間フラグメントサイズをその値にすることも有効である。
【0067】
図11は、本実施形態を適用し、複数クライアントに配信した際の一時記憶部913の状態である。
図11では、配信能力が画像生成の半分程度のクライアント1101と、配信能力が画像生成より充分高いクライアント1102の例である。
クライアント1101とクライアント1102に配信を開始した時は、フラグメントサイズが「5」のため、図7に示したようにメモリ使用量が80パーセントを越える。このため、逼迫時のフラグメントサイズが適用され、クライアント1101とクライアント1102のフラグメントは共に2フレームになっている。
【0068】
配信カメラサーバの一時記憶部913の画像用メモリ領域は全クライアント共通で使用しており、最大で15フレーム分保持できるとすると、画像用メモリの使用量は33パーセント(5/15フレーム)となる。このように、本実施形態を適用し、遅延クライアントのフラグメントサイズを減らすことで画像用メモリの参照を最近のデータに集中させることができ、メモリの使用効率を向上させることができる。
【0069】
また、メモリの使用効率を向上させることで、画像フレームを生成時に一時記憶部913に保存できなくなることが減り、画像フレーム落ちの少ない映像配信ができる。同時に、複数クライアントに配信してもメモリの使用量は大きく増えないので、より多くのクライアントへ配信することができる。また、第1の実施形態と一緒に適用することで、より効率よくメモリを使用することができる。
以上、本発明の好ましい実施形態について説明したが、本発明はこれらの実施形態に限定されず、その要旨の範囲内で種々の変形及び変更が可能である。
【0070】
(その他の実施形態)
また、本発明は、以下の処理を実行することによっても実現される。即ち、前述した実施形態の機能を実現するソフトウェア(コンピュータプログラム)を、ネットワーク又は各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
【符号の説明】
【0071】
200 映像配信装置、210、撮像処理プログラム、211 配信制御プログラム、212 通信処理プログラム、213 時記憶部、214 遅延監視プログラム、914 メモリ監視プログラム

【特許請求の範囲】
【請求項1】
映像フレームを生成して符号化する撮像処理手段と、
前記撮像処理手段により符号化された映像フレームを一時保存する一時記憶部と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御手段と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理手段と、
前記配信制御手段により行われる配信処理の遅延状況を監視する遅延監視手段と、
を有し、
前記遅延監視手段は、前記配信制御手段により行われている特定の相手装置への配信処理が映像フレームの生成より遅れていることを検出すると、前記配信制御手段が保持している一送信単位の映像フレーム数を減少し、その後、一定期間について前記配信処理の遅延が解消したことを検出すると前記配信制御手段が保持している一送信単位の映像フレーム数を増加することを特徴とする映像配信装置。
【請求項2】
前記遅延監視手段が検出する遅延時間は複数の閾値を持ち、一送信単位の最大数を複数段階で変更することを特徴とする請求項1に記載の映像配信装置。
【請求項3】
映像フレームを生成して符号化する撮像処理手段と、
前記撮像処理手段により符号化された映像フレームを一時保存する一時記憶部と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御手段と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理手段と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視手段と、
を有し、
前記メモリ監視手段は、前記一時記憶部のメモリ使用量が前記上限閾値を上回ったことを検出すると、前記配信制御手段が配信を行う映像フレームの送信単位を減少させ、
前記一時記憶部のメモリ使用量が前記復旧閾値を下回ったことを検出すると、前記配信制御手段が配信を行う映像フレームの送信単位を増加させることを特徴とする映像配信装置。
【請求項4】
前記メモリ監視手段が検出する下限閾値は複数の閾値を持ち、一送信単位に含まれる映像フレーム数の最大値を増減させることを特徴とする請求項3に記載の映像配信装置。
【請求項5】
映像フレームを生成して符号化する撮像処理手段と、
前記撮像処理手段により符号化された映像フレームを一時保存する一時記憶部と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御手段と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理手段と、
前記配信制御手段により行われる配信処理の遅延状況を監視する遅延監視手段と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視手段と、
を有し、
前記遅延監視手段により相手装置毎への一送信単位に含まれる映像フレーム数を増減させ、かつ前記メモリ監視手段により一送信単位に含まれる映像フレーム数を増減させることを特徴とする映像配信装置。
【請求項6】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記配信制御工程において行われる配信処理の遅延状況を監視する遅延監視工程と、
を有し、
前記遅延監視工程においては、前記配信制御工程において行われている特定の相手装置への配信処理が映像フレームの生成より遅れていることを検出すると、前記配信制御工程において保持している一送信単位の映像フレーム数を減少し、その後、一定期間について前記配信処理の遅延が解消したことを検出すると前記配信制御工程において保持している一送信単位の映像フレーム数を増加することを特徴とする映像配信方法。
【請求項7】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視工程と、
を有し、
前記メモリ監視工程においては、前記一時記憶部のメモリ使用量が前記上限閾値を上回ったことを検出すると、前記配信制御工程において配信を行う映像フレームの送信単位を減少させ、
前記一時記憶部のメモリ使用量が前記復旧閾値を下回ったことを検出すると、前記配信制御工程において配信を行う映像フレームの送信単位を増加させることを特徴とする映像配信方法。
【請求項8】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記配信制御工程において行われる配信処理の遅延状況を監視する遅延監視工程と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視工程と、
を有し、
前記遅延監視工程において相手装置毎への一送信単位に含まれる映像フレーム数を増減させ、かつ前記メモリ監視工程において一送信単位に含まれる映像フレーム数を増減させることを特徴とする映像配信方法。
【請求項9】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記配信制御工程において行われる配信処理の遅延状況を監視する遅延監視工程とをコンピュータに実行させ、
前記遅延監視工程においては、前記配信制御工程において行われている特定の相手装置への配信処理が映像フレームの生成より遅れていることを検出すると、前記配信制御工程において保持している一送信単位の映像フレーム数を減少し、その後、一定期間について前記配信処理の遅延が解消したことを検出すると前記配信制御工程において保持している一送信単位の映像フレーム数を増加するようコンピュータを制御することを特徴とするコンピュータプログラム。
【請求項10】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視工程とをコンピュータに実行させ、
前記メモリ監視工程においては、前記一時記憶部のメモリ使用量が前記上限閾値を上回ったことを検出すると、前記配信制御工程において配信を行う映像フレームの送信単位を減少させ、
前記一時記憶部のメモリ使用量が前記復旧閾値を下回ったことを検出すると、前記配信制御工程において配信を行う映像フレームの送信単位を増加させるようコンピュータを制御することを特徴とするコンピュータプログラム。
【請求項11】
映像フレームを生成して符号化する撮像処理工程と、
前記撮像処理工程において符号化された映像フレームを一時記憶部へ一時保存する一時記憶工程と、
前記一時記憶部に保存した単数または複数の映像フレームを一送信単位として配信を行う配信制御工程と、
前記一送信単位としてまとめられた映像フレームを実際に相手装置に送る通信処理工程と、
前記配信制御工程において行われる配信処理の遅延状況を監視する遅延監視工程と、
前記一時記憶部のメモリ使用量を上限閾値と復旧閾値とで監視するメモリ監視工程とをコンピュータに実行させ、
前記遅延監視工程において相手装置毎への一送信単位に含まれる映像フレーム数を増減させ、かつ前記メモリ監視工程において一送信単位に含まれる映像フレーム数を増減させるようコンピュータを制御することを特徴とするコンピュータプログラム。
【請求項12】
請求項9〜11の何れか1項に記載のコンピュータプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate


【公開番号】特開2011−234233(P2011−234233A)
【公開日】平成23年11月17日(2011.11.17)
【国際特許分類】
【出願番号】特願2010−104251(P2010−104251)
【出願日】平成22年4月28日(2010.4.28)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】