(57)【特許請求の範囲】
【請求項１】
ビデオデータを用いてイベントを検知する検知手段と、
前記ビデオデータに基づくビデオパケットと、前記ビデオデータを用いて前記検知手段により検知されたイベントに対応するイベントパケットとを受信装置へ送信すると共に、前記受信装置へ送信したパケット数に関する情報を含むレポートパケットを前記受信装置へ送信する送信手段と、
前記送信手段による第１のレポートパケットの送信から所定時間内に前記イベントパケットが送信された場合、前記第１のレポートパケットの送信から前記所定時間内に前記イベントパケットが送信されなかった場合よりも早いタイミングで第２のレポートパケットが送信されるように、前記ビデオパケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記レポートパケットの送信タイミングを決定する決定手段と、
を有することを特徴とする送信装置。
【請求項２】
前記決定手段は、前記イベントパケットを送信したあと、次のイベントパケットを送信せずに経過した経過時間に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項３】
前記決定手段は、第１のイベントの発生に応じて送信される第１及び第２のイベントパケットのうち、先に送信される前記第１のイベントパケットの送信からの経過時間に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項４】
前記決定手段は、前記第１のレポートパケットの送信後において送信されたイベントデータのデータ量に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項５】
発生したイベントに応じたイベントデータのデータ量を取得する取得手段を有し、
前記決定手段は、前記取得手段によって取得されたデータ量のイベントデータの送信完了に応じて前記第２のレポートパケットが送信されるように、前記レポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項６】
前記決定手段は、第１のイベントに対応する第１のイベントパケットを送信開始してから前記第２のレポートパケットを送信する前までに、第２のイベントに対応する第２のイベントパケットの送信が開始され、且つ、前記第２のイベントパケットの送信完了が、前記第１のイベントパケットの送信完了よりも後である場合、前記第２のイベントパケットの送信完了後に、前記第２のレポートパケットを送信するように、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項７】
発生したイベントの優先度を判定する優先度判定手段を有し、
前記決定手段は、前記優先度判定手段により第１の優先度と判定される第１のイベントに対応する第１のイベントパケットを送信してから次のイベントパケットを送信せずに第１の所定時間が経過すると前記第２のレポートパケットを送信し、
前記優先度判定手段により前記第１の優先度よりも高い第２の優先度と判定される第２のイベントに対応する第２のイベントパケットを送信してから次のイベントパケットを送信せずに前記第１の所定時間よりも短い第２の所定時間が経過すると前記第２のレポートパケットを送信するように、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項８】
発生したイベントの優先度を判定する優先度判定手段を有し、
前記決定手段は、前記優先度判定手段により第１の優先度と判定される第１のイベントに対応する第１のイベントパケットの送信開始から第１の所定時間が経過後に、前記第２のレポートパケットを送信し、
前記優先度判定手段により前記第１の優先度よりも高い第２の優先度と判定される第２のイベントに対応する第２のイベントパケットの送信開始から前記第１の所定時間よりも短い第２の所定時間が経過後に、前記第２のレポートパケットを送信するように、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１記載の送信装置。
【請求項９】
発生したイベントが、前記受信装置でイベント画像を表示させるべきイベントであるか否かを判定する判定手段を有し、
前記決定手段は、前記発生したイベントが前記イベント画像を表示させるべきイベントであると判定された場合、前記イベント画像を表示させるべきイベントでないと判定された場合よりも、前記第２のレポートパケットの送信タイミングが早くなるように、前記第２のレポートパケットの送信タイミングを決定することを特徴とする請求項１に記載の送信装置。
【請求項１０】
前記発生したイベントが、前記受信装置で前記イベント画像を表示させるべきイベントであると前記判定手段により判定された場合、当該イベント画像を表示させるべきビデオフレームを判定する関連性判定手段を有し、
前記決定手段は、前記発生したイベントが、第１のビデオフレーム内にイベント画像を表示させるべきイベントであると前記関連性判定手段により判定された場合、当該イベントに対応するイベントパケットの送信が開始され、かつ、前記第１のビデオフレームのビデオパケットの送信完了に基づくタイミングで、前記第２のレポートパケットが送信されるように、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項９記載の送信装置。
【請求項１１】
前記送信手段は、前記受信装置に対して音声パケットを送信し、
前記決定手段は、前記受信装置へ送信する前記ビデオパケットと前記音声パケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記第２のレポートパケットの送信タイミングを決定することを特徴とする請求項１乃至１０のうち、何れか１項に記載の送信装置。
【請求項１２】
前記送信手段は、前記第１及び第２のレポートパケットとしてＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）で規定するＳＲ（Ｓｅｎｄｅｒ  Ｒｅｐｏｒｔ）を送信することを特徴とする請求項１乃至１１のうち、何れか１項に記載の送信装置。
【請求項１３】
前記検知手段は、前記ビデオデータを用いてイベント検知の検知を行うと共に、外部センサーからの信号に基づいてイベントの検知を行い、
前記送信手段は、前記ビデオデータを用いて検知されたイベントに対応するイベントパケットを受信装置へ送信すると共に、前記外部センサーからの信号に基づいて検知された前記イベントに対応するイベントパケットを送信し、
前記決定手段は、前記第２のレポートパケットの送信タイミングを、前記ビデオデータを用いて検知されたイベントに対応するイベントパケット、及び、前記外部センサーからの信号に基づいて検知された前記イベントに対応するイベントパケットの送信タイミングに基づいて決定することを特徴とする請求項１乃至１２のうち、何れか１項に記載の送信装置。
【請求項１４】
送信装置が行う送信方法であって、
ビデオデータを用いてイベントを検知する検知工程と、
前記ビデオデータに基づくビデオパケットと、前記ビデオデータを用いて前記検知工程により検知されたイベントに対応するイベントパケットとを受信装置へ送信すると共に、前記受信装置へ送信したパケット数に関する情報を含むレポートパケットを前記受信装置へ送信する送信工程と、
前記送信工程による第１のレポートパケットの送信から所定時間内に前記イベントパケットが送信された場合、前記第１のレポートパケットの送信から前記所定時間内に前記イベントパケットが送信されなかった場合よりも早いタイミングで第２のレポートパケットが送信されるように、前記ビデオパケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記レポートパケットの送信タイミングを決定する決定工程と、
を有することを特徴とする送信方法。
【請求項１５】
前記決定工程は、前記イベントパケットを送信したあと、次のイベントパケットを送信せずに経過した経過時間に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１４記載の送信方法。
【請求項１６】
前記決定工程は、第１のイベントの発生に応じて送信される第１及び第２のイベントパケットのうち、先に送信される前記第１のイベントパケットの送信からの経過時間に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１４記載の送信方法。
【請求項１７】
前記決定工程は、前記第１のレポートパケットの送信後において送信されたイベントデータのデータ量に基づいて、前記第２のレポートパケットの送信タイミングを決定する
ことを特徴とする請求項１４記載の送信方法。
【請求項１８】
発生したイベントに応じたイベントデータのデータ量を取得する取得工程を有し、
前記決定工程は、前記取得工程によって取得されたデータ量のイベントデータの送信完了に応じて前記第２のレポートパケットが送信されるように、前記レポートパケットの送信タイミングを決定する
ことを特徴とする請求項１４記載の送信方法。
【請求項１９】
発生したイベントの優先度を判定する優先度判定工程を有し、
前記決定工程は、前記優先度判定工程により第１の優先度と判定される第１のイベントに対応する第１のイベントパケットを送信してから次のイベントパケットを送信せずに第１の所定時間が経過すると前記第２のレポートパケットを送信し、
前記優先度判定工程により前記第１の優先度よりも高い第２の優先度と判定される第２のイベントに対応する第２のイベントパケットを送信してから次のイベントパケットを送信せずに前記第１の所定時間よりも短い第２の所定時間が経過すると前記第２のレポートパケットを送信するように、前記レポートパケットの送信タイミングを決定する
ことを特徴とする請求項１４記載の送信方法。
【請求項２０】
請求項１〜１３の何れか１項に記載の送信装置の各手段として、コンピュータを機能させるためのプログラム。
【請求項２１】
送信装置と受信装置とを有するシステムであって、
前記送信装置は、
ビデオデータを用いてイベントを検知する検知手段と、
前記ビデオデータに基づくビデオパケットと、前記ビデオデータを用いて前記検知手段により検知されたイベントに対応するイベントパケットとを前記受信装置へ送信すると共に、前記受信装置へ送信したパケット数に関する情報を含むレポートパケットを前記受信装置へ送信する送信手段と、
前記送信手段による第１のレポートパケットの送信から所定時間内に前記イベントパケットが送信された場合、前記第１のレポートパケットの送信から前記所定時間内に前記イベントパケットが送信されなかった場合よりも早いタイミングで第２のレポートパケットが送信されるように、前記ビデオパケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記レポートパケットの送信タイミングを決定する決定手段とを有し、
前記受信装置は、
前記送信装置によって送信された前記ビデオパケットと前記イベントパケットと前記レポートパケットとを受信する受信手段と、
前記受信手段によって受信済みの前記ビデオパケット及び前記イベントパケットのパケット数と、前記レポートパケットに含まれる前記パケット数に関する情報とに基づいて、パケットロスを検知する検知手段とを有することを特徴とするシステム。
【請求項２２】
ビデオデータを用いてイベントを検知する検知手段と、
前記ビデオデータに基づくビデオパケットと、前記ビデオデータを用いて前記検知手段により検知されたイベントに対応するイベントパケットとを受信装置へ送信すると共に、前記受信装置がパケットロスを検知するために用いるレポートパケットを前記受信装置へ送信する送信手段と、
前記送信手段による第１のレポートパケットの送信から所定時間内に前記イベントパケットが送信された場合、前記第１のレポートパケットの送信から前記所定時間内に前記イベントパケットが送信されなかった場合よりも早いタイミングで第２のレポートパケットが送信されるように、前記ビデオパケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記レポートパケットの送信タイミングを決定する決定手段と、
を有することを特徴とする送信装置。
【請求項２３】
前記送信手段は、前記第１及び第２のレポートパケットとしてＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）で規定するＳＲ（Ｓｅｎｄｅｒ  Ｒｅｐｏｒｔ）を送信することを特徴とする請求項２２に記載の送信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベントの発生に応じて送信されるイベントデータを送信したことを示す通知データの送信方法に関する。
【背景技術】
【０００２】
定期的に送信される定期パケット（例えばビデオデータパケット）のパケットロス判定方法として、パケットに付けられたシーケンス番号を確認する方法が知られている。受信装置は、シーケンス番号の抜けを見つけることにより、パケットロスを検知することができる。
【０００３】
一方、イベントの発生に応じて送信されるイベントパケットのパケットロスを判定するための方法が、特許文献１に開示されている。特許文献１において、送信装置は不定期に送信されるテロップに関するパケット群の先頭パケットと最後尾パケットにそれぞれ異なるマーカービットを付加する。受信装置は、先頭パケットの受信から所定時間内に最後尾パケットを受信しなかった場合、最後尾パケットがロスしたと判定する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３２８１３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、発生するイベントデータによっては、イベントデータのロスを検知するまでに時間がかかってしまう場合があった。
【０００６】
このような場合の例として、発生するイベントによって、送信されるイベントデータのパケット数が変動する場合が挙げられる。特に、送信されるイベントデータのパケット数が少ないイベントが発生した場合、先頭パケットを受信してから最後尾パケットを受信するまでの予測時間が、実際の時間よりも長くなる。このため、予測時間が経過するまで待つと、最後尾パケットのロスの検知までに時間がかかってしまうことになる。
【０００７】
また、イベントの発生に応じて送信されるイベントデータのパケットが１つの場合は、先頭パケットと最後尾パケットに異なるマーカービットを付加できない。従って、次のイベントデータのパケットを受信するまで、イベントデータのパケットロスを検知することができない恐れがあった。
【０００８】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、イベントの発生に応じて送信されるイベントデータのロスをより早く検知できるようにすることである。
【課題を解決するための手段】
【０００９】
上記の問題点を解決するために、本発明の送信装置は、例えば、以下の構成を有する。すなわち、ビデオデータを用いてイベントを検知する検知手段と、前記ビデオデータに基づくビデオパケットと、前記ビデオデータを用いて前記検知手段により検知されたイベントに対応するイベントパケットとを受信装置へ送信すると共に、前記受信装置へ送信したパケット数に関する情報を含むレポートパケットを前記受信装置へ送信する送信手段と、前記送信手段による第１のレポートパケットの送信から所定時間内に前記イベントパケットが送信された場合、前記第１のレポートパケットの送信から前記所定時間内に前記イベントパケットが送信されなかった場合よりも早いタイミングで第２のレポートパケットが送信されるように、前記ビデオパケットと前記イベントパケットとのうち、前記イベントパケットの送信タイミングに基づいて、前記レポートパケットの送信タイミングを決定する決定手段とを有する。
【発明の効果】
【００１０】
本発明によれば、イベントの発生に応じて送信されるイベントデータのロスをより早く検知できるようになる。
【図面の簡単な説明】
【００１１】
【図１】実施形態１における送信装置と受信装置の構成例を示すブロック図である
【図２】実施形態１における送信装置の処理を説明するためのフローチャートである
【図３】従来のＳＲの送信タイミングの一例を示す図である
【図４】実施形態１のＳＲの送信タイミングの一例を示す図である
【図５】実施形態１におけるＳＲの送信タイミングの別の例を示す図である
【図６】実施形態２におけるＳＲの送信タイミングの一例を示す図である
【図７】実施形態２における送信装置の処理を説明するためのフローチャートである
【図８】ＲＴＣＰのパケット構成例を示すための図である
【発明を実施するための形態】
【００１２】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。
【００１３】
＜実施形態１＞
図１は、本実施形態の送信装置１００と受信装置１０６の機能構成例を示すブロック図である。
【００１４】
送信装置１００は、イベントデータ生成部１０１、イベントデータ送信部１０２、タイミング決定部１０３、ＲＴＣＰ生成部１０４、ＲＴＣＰ送信部１０５を備えている。なお、本形態の送信装置１００は、ビデオデータをＲＴＰ（Ａ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｒｅａｌ−Ｔｉｍｅ  Ａｐｐｌｉｃａｔｉｏｎ）で受信装置１０６に対して送信する。また、ＲＴＣＰは、ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌである。本形態の送信装置１００は、イベントデータの送信を通知するために、ＲＴＣＰのＳＲ（Ｓｅｎｄｅｒ  Ｒｅｐｏｒｔ）を受信装置１０６に送信するが、他のプロトコルを用いることも可能である。
【００１５】
イベントデータ生成部１０１は、イベントの発生に応じてイベントデータを生成する。検知されるイベントには、例えば、人物検知、物体の動き検知、外部センサーによる異常検知、ユーザ端末からのカメラ制御権の変更などがある。また、生成されるイベントデータには、例えば、検知されたイベントの種別を示す情報や、イベントの詳細情報などがある。イベントの詳細情報には、例えば、人物が検知された場合、人物が検知された時刻、検知された人物の数、人物の画面内における位置などがある。
【００１６】
イベントデータ送信部１０２は、イベントデータ生成部１０１で生成されたイベントデータを受信装置１０６に対して送信する。すなわち、イベントデータ送信部１０２は、イベントの発生に応じてイベントデータを受信装置１０６に送信する。
【００１７】
タイミング決定部１０３は、イベントデータ送信部１０２によるイベントデータの送信状況に応じて、イベントデータを送信したことを受信装置１０６に通知するための通知データ（ＳＲ）の送信タイミングを決定する。
【００１８】
ＲＴＣＰ生成部１０４は、ＲＴＣＰのＳＲ（通知データ）を生成する。ＲＴＣＰ送信部１０５は、ＲＴＣＰ生成部１０４が生成したＳＲをタイミング決定部１０３によって決定されたタイミングで受信装置１０６に対して送信する。なお、本形態では、イベントデータ送信部１０２とＲＴＣＰ送信部１０５を別の送信部として説明しているが、同じ送信部を用いることも可能である。
【００１９】
図８はＲＴＣＰパケット（ＳＲ１１００）の図の一部を示したものである。受信装置１０６は、ＳＲに記録されている送信者パケットカウント１１０１に基づいてパケットロスを検知できる。送信者パケットカウント１１０１には、送信装置１００が受信装置１０６とセッションを確立してから送った総パケット数が記録されている。例えば、ＳＲの送信者パケットカウントに９０と記録されていた場合、送信装置１００は、受信装置１０６に対して９０個のパケットを送信したことになる。そして、次のＳＲの送信者パケットカウントに１００と記録されていた場合、送信装置１００は、前のＳＲの送信後に１０個のパケットを送信したことになる。
【００２０】
このとき、受信装置１０６が実際に受け取ったパケット数が９個だった場合、１つのパケットがロスしたことを検知できる。例えば、受信装置１０６は、受信した最後のイベントパケットのシーケンスナンバーが９９だった場合、シーケンスナンバーが１００のイベントパケットをロスしたことを検知する。
【００２１】
また、例えば、シーケンスナンバーが９８、９９、１００番のイベントパケットをロスした場合でも、送信総パケット数と受信したパケット数に基づいて、受信装置１０６はイベントパケットのロスを検知できる。すなわち、受信装置１０６は、これまでに受信したイベントパケットのパケット数と、ＳＲに含まれる送信パケット数とに基づいて、受信できなかったイベントパケットを特定できる。なお、本形態の受信装置１０６は、例えば、シーケンスナンバーが９７番のイベントパケットをロスし、９８番のイベントパケットを正常に受信した場合、９７番のイベントパケットをロスしたことを検知できる。
【００２２】
図２は、本形態の送信装置１００の処理を説明するためのフローチャートである。
【００２３】
ステップＳ２０１において、タイミング決定部１０３は、イベントデータ送信部１０２によるイベントデータの送信を検知する。
【００２４】
ステップＳ２０２（決定手順）において、タイミング決定部１０３は、イベントデータを送信したことを受信装置１０６に通知するための通知データ（ＳＲ）の送信タイミングを、イベントデータの送信タイミングに応じて決定する。タイミング決定部１０３によるＳＲの送信タイミングの決定方法については、後述する。
【００２５】
ステップＳ２０３（送信手順）において、ＲＴＣＰ送信部１０５は、ＲＴＣＰ生成部１０４により生成されたＳＲを、タイミング決定部１０３により決定された送信タイミングで送信する。
【００２６】
図３は、ＳＲが一定間隔で送信される場合のＳＲとイベントデータの送信タイミングの例を示している。図３では、イベントデータ１０と１２がロスしている。受信装置１０６は、イベントデータ１０のロスをＳＲ−５、イベントデータ１２のロスをＳＲ−６の受信に応じて検知する。
【００２７】
受信装置１０６は、イベントデータ１０を受信できなかった（ロスした）ことを、ＳＲ−５の受信に応じて検知する。また、受信装置１０６は、イベントデータ１２のロスを、ＳＲ−６の受信に応じて検知する。図３に示すように、ロスしたイベントデータ１０が受信されるべきタイミングから、ＳＲ−５を受信するまでの時間が長いと、イベントデータのロスの検知が遅れてしまう。
【００２８】
図４は、本実施形態のＳＲとイベントデータの送信タイミングの一例を示している。図４でも、図３と同様に、イベントデータ１０と１２がロスしている。この例において、受信装置１０６は、イベントデータ１０のロスをＳＲ−２の受信に応じて検知する。また、受信装置１０６は、イベントデータ１２のロスをＳＲ−３の受信に応じて検知する。このように、本形態のタイミング決定部１０３は、イベントデータのロスをより早く検出できるように、イベントデータの送信状況に応じて、ＳＲの送信タイミングを決定する。
【００２９】
また、本形態の受信装置１０６は、イベントデータが送信されていない期間は、イベントデータを送信したことを示すＳＲを受信装置１０６に送信させない。このようにすることで、ＳＲの生成にかかる負荷や、ネットワークの負荷を低減できる。
【００３０】
次に、本形態のタイミング決定部１０３によるＳＲの送信タイミングの決定方法について説明する。タイミング決定部１０３は、イベントデータ送信部１０２が最後にイベントデータを送信した時刻（最終送信時刻）を保持している。また、タイミング決定部１０３は、ＲＴＣＰ送信部１０５が最後に送信したＳＲの後に、イベントデータ送信部１０２が送信したイベントデータのうち、最初に送信されたイベントデータの送信時刻（送信開始時刻）、及び、現在時刻を保持している。タイミング決定部１０３は、最終送信時刻、送信開始時刻、現在時刻を用いて、ＳＲの送信タイミングを決定する。
【００３１】
具体的には、タイミング決定部１０３は、現在時刻と最終送信時刻との差が、所定時間に達したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する（第１の方法）。すなわち、タイミング決定部１０３は、イベントデータを送信したあと、次にイベントデータを送信せずに第１の所定時間が経過したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する。なお、ＳＲは、イベントデータを送信したことを受信装置１０６に通知するための通知データである。
【００３２】
また、タイミング決定部１０３は、送信開始時刻と現在時刻との差分が、所定時間に達したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する（第２の方法）。すなわち、タイミング決定部１０３は、ＳＲを送信したあとのイベントデータの送信開始から第２の所定時間が経過したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する。
【００３３】
なお、本実施形態のタイミング決定部１０３は、上記の第１の方法で決定された送信タイミングでＳＲを送信すると共に、第２の方法で決定された送信タイミングでＳＲを送信する。このようにすることで、どちらか一方の方法でＳＲを送信する場合よりも、早いタイミングでイベントデータのロスを検知できる可能性が向上する。
【００３４】
この理由について、第１の所定時間が１００ｍｓｅｃ、第２の所定時間が２００ｍｓｅｃとした場合を例にあげて説明する。このとき、発生したイベントに応じて送信されるイベントパケットの数が、例えば１個のみで、それがロスした場合、第１の方法で決定されたタイミングでＳＲを送信したほうが、第２の方法で決定されたタイミングでＳＲを送信するよりも、早くロスを検知できる。
【００３５】
一方、発生したイベントに応じて送信されるイベントパケットの数が、例えば３０個で、第１の方法で決定されたタイミングでＳＲを送信すると、３０個目のイベントパケットが送信された１００ｍｓｅｃ後にＳＲが送信される。これに対し、第２の方法で決定されたタイミングでＳＲを送信すると、１個目のイベントパケットが送信された２００ｍｓｅｃ後にＳＲが送信される。このとき、３０個のイベントパケットのすべてがロスし、第１の方法で決定されたタイミングよりも第２の方法で決定されたタイミングのほうが早ければ、より早く、イベントパケットのロスを検知できる。
【００３６】
なお、タイミング決定部１０３は、第１、第２の方法のうち、いずれか一方のみを用いてＳＲの送信タイミングを決定することも可能である。また、第１、第２の所定時間は、上記の長さに限らない。
【００３７】
本形態のタイミング決定部１０３により第１、第２の方法で決定された送信タイミングでＳＲが送信される例を図５に示す。同図に示すように、タイミング決定部１０３は、イベントデータ７の送信から第１の所定時間が経過したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する。また、タイミング決定部１０３は、イベントデータ８の送信から第２の所定時間、及び、イベントデータ１６の送信から第１の所定時間が経過したことに応じて、それぞれＳＲが送信されるように、ＳＲの送信タイミングを決定する。
【００３８】
なお、図５に示すように、イベントデータ１の送信から第２の所定時間が経過したタイミングでは、ＳＲは送信されない。これは、ＳＲ−１が送信されたことにより、送信開始時刻がリセットされるためである。送信開始時刻とは、上述のように、最後に送信したＳＲの後に送信されたイベントデータのうち、最初に送信されたイベントデータの送信時刻である。
【００３９】
なお、本形態では、ＳＲの送信タイミングを、現在時刻と最終送信時刻との比較、及び、現在時刻と送信開始時刻との比較に基づいて決定する例について説明したが、例えば、イベントデータのデータ量に基づいて決定することも可能である。
【００４０】
すなわち、タイミング決定部１０３は、ＳＲを送信したあとに送信されたイベントデータのデータ量が所定のデータ量に達したか否かを判定するデータ量判定処理を行う。そして、タイミング決定部１０３は、イベントデータのデータ量が所定のデータ量に達したことに応じて、ＳＲが送信されるように、ＳＲの送信タイミングを決定する。このようにすれば、現在時刻などの時刻情報を用いることなく、ＳＲの送信タイミングを決定できる。
【００４１】
また、ＳＲの送信タイミングの決定方法の別の方法として、発生したイベントに応じて送信されるイベントデータのデータ量がわかる場合は、そのデータ量を用いて決定する方法がある。すなわち、タイミング決定部１０３は、イベントに応じて送信されるイベントデータのデータ量をイベントデータ生成部１０１から取得する。そして、タイミング決定部１０３は、取得されたデータ量のイベントデータの送信が完了したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する。このようにしても、時刻情報を用いることなくＳＲの送信タイミングを決定できる。
【００４２】
また、本形態のタイミング決定部１０３は、あるイベントの発生に応じた第１のイベントデータの送信中に、別のイベントの発生に応じた第２のイベントデータを送信することになった場合、第１、第２のイベントデータを送信したことを、１つのＳＲで通知する。即ちタイミング決定部１０３は、第１のイベントデータに対応するＳＲの送信前に第２のイベントデータの送信が開始され、第２のイベントデータの送信完了が第１のイベントデータの送信完了より後の場合、第２のイベントデータの送信完了後にＳＲを送信させる。なお、第１のイベントデータは、第１のイベントが発生したことを通知するためのイベントデータ、第２のイベントデータは、第２のイベントが発生したことを通知するためのイベントデータである。
【００４３】
このようにすることで、第１のイベントデータに対応するＳＲと第２のイベントデータに対応するＳＲをそれぞれ送信するよりも、ＳＲの生成にかかる処理、及び、ネットワークの負荷を低減することができる。また、受信装置１０６は、第２のイベントデータのシーケンスナンバーに基づいて第１のイベントデータのロスを検知することができる。
【００４４】
また、本形態では、発生したイベントに関わらず、イベントデータの送信タイミングに応じてＳＲの送信タイミングが決定される例について説明したが、発生したイベントの優先度を考慮してＳＲの送信タイミングを決定することも可能である。
【００４５】
例えば、タイミング決定部１０３は、侵入者検知のイベントを優先度が高いイベントと判定し、カメラ制御権の変更を優先度が低いイベントと判定する。そして、タイミング決定部１０３は、カメラ制御権の変更のイベント（第１のイベント）が発生した場合よりも、侵入者検知のイベント（第２のイベント）が発生した場合のほうが、上述の第１の方法における第１の所定時間を短く設定する。第１の方法とは、現在時刻と最終送信時刻との差が、第１の所定時間に達したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する方法である。
【００４６】
この場合、ステップＳ２０１において、タイミング決定部１０３は、発生したイベントの優先度を判定する優先度判定処理を行う。
【００４７】
ステップＳ２０２において、タイミング決定部１０３は、第１の優先度と判定されるカメラ制御権の変更のイベントの発生を通知するための第１のイベントデータを送信してから次のイベントデータを送信せずに第１の時間経過したことに応じて、ＳＲを送信させる。また、ステップＳ２０２において、タイミング決定部１０３は、第２の優先度と判定される侵入者検知のイベントの発生を通知するための第２のイベントデータを送信してから次のイベントデータを送信せずに第２の時間経過したことに応じて、ＳＲを送信させる。なお、第２の優先度は第１の優先度よりも高く、第２の時間は第１の時関よりも短い。
【００４８】
なお、各イベントの優先度は、上記の例に限らず、任意に設定可能である。また、上記の第２の方法に、イベントの優先度に応じたＳＲの送信タイミングの決定方法を適用することも可能である。
【００４９】
この場合、ステップＳ２０２において、タイミング決定部１０３は、第１の優先度と判定されるカメラ制御権の変更のイベントの発生を通知するための第１のイベントデータの送信開始から第１の時間経過後に、ＳＲを送信させる。また、ステップＳ２０２において、タイミング決定部１０３は、第２の優先度と判定される侵入者検知のイベントの発生を通知するための第２のイベントデータの送信開始から第２の時間経過後に、ＳＲを送信させる。なお、第２の優先度は第１の優先度よりも高く、第２の時間は第１の時間よりも短い。このようにすることで、優先度の高いイベントに関するイベントデータのロスを、受信装置１０６がより早く検知できる。
【００５０】
＜実施形態２＞
次に、第２の実施形態について、第１の実施形態との差異を中心に説明する。本形態のタイミング決定部１０３は、ＳＲの送信タイミングを、発生したイベントがメディアデータに関係するか否かに基づいて決定する。メディアデータとは、例えばビデオデータや音声データである。本形態では、送信装置１００がビデオデータを送信する場合について、主に説明する。また、本形態では、受信装置１０６が再生するビデオデータのフレーム内にイベント画像（例えば枠）を表示させる必要があるイベント（侵入者検知や物体の動き検知）を、メディアデータにイベントとする例を説明する。ただし、これらの例に限らない。
【００５１】
図６は、イベントデータとそれに関連づけられたビデオデータとＲＴＣＰパケット（ＳＲ）の送信タイミングを示した図である。
【００５２】
ＳＲ−１は、実施形態１の第１の方法によるイベントデータの送信タイミングを示している。第１の方法は、現在時刻と最終送信時刻との差が、所定時間に達したことに応じてＳＲが送信されるように、ＳＲの送信タイミングを決定する方法である。本形態のタイミング決定部１０３は、イベントデータ１−３に対応するイベントが、イベント画像を表示させるべきイベントでないと判定した場合、ＳＲ−１のタイミングでＳＲを送信することを決定する。
【００５３】
一方、ＳＲ−２は、イベントデータ１−３に対応するイベントが、受信装置１０６でイベント画像を表示させるべきイベントであった場合のＳＲの送信タイミングを示している。図６に示すように、ＳＲ−２は、ＳＲ−１よりもタイミングが早い。このようにすることで、ビデオデータに関連するイベントデータのロスを受信装置１０６がより早く検知できる。
【００５４】
図７は、本形態の送信装置１００の処理を説明するためのフローチャートである。なお、本形態の送信装置１００は、受信装置１０６に対してビデオデータを送信すると共に、イベントの発生に応じてイベントデータを送信する。
【００５５】
ステップＳ９０１において、タイミング決定部１０３は、イベントデータ送信部１０２によるイベントデータの送信を検知する。
【００５６】
ステップＳ９０２において、タイミング決定部１０３は、発生したイベントが、受信装置１０６が再生するビデオデータのフレーム内にイベント画像を表示させるべきイベントであるか否かを判定する関連性判定処理を行う。また、タイミング決定部１０３は、イベント画像を表示させるべきイベントであると判定した場合、イベント画像を表示させるべきフレームを判定する。なお、イベント画像とは、例えば、侵入者の位置を示す枠や、侵入者が検知されたことを示す文字を含む画像である。
【００５７】
ステップＳ９０２においてイベント画像を表示させるべきイベントでないと判定された場合はステップＳ９０３に進み、イベント画像を表示させるべきイベントであると判定された場合はステップＳ９０５に進む。
【００５８】
ステップＳ９０５において、タイミング決定部１０３は、イベントデータの送信が開始され、かつ、イベント画像を表示させるフレーム（第１のフレーム）のビデオデータが送信完了したタイミングで、ＳＲが送信されるように送信タイミングを決定する。なお、ステップＳ９０５で決定された送信タイミングで送信されるＳＲは、発生したイベントに応じたイベントデータのうち、送信済のイベントデータを送信したことを示す通知データである。
【００５９】
ステップＳ９０６において、タイミング決定部１０３は、ステップＳ９０５で決定された送信タイミングと、実施形態１で説明した第１、第２の方法で決定された送信タイミングとのうちで、最も早い送信タイミングを特定する。
【００６０】
ステップＳ９０３において、タイミング決定部１０３は、ＳＲの送信タイミングを決定する。すなわち、タイミング決定部１０３は、発生したイベントがイベント画像を表示させるべきイベントであると判定された場合、ステップＳ９０６で特定された送信タイミングを、ＳＲの送信タイミングとして決定する。一方、タイミング決定部１０３は、発生したイベントがイベント画像を表示させるべきイベントでないと判定された場合、第１、第２の方法で決定された送信タイミングを、ＳＲの送信タイミングとして決定する。
【００６１】
ステップＳ９０４において、タイミング決定部１０３は、ステップＳ９０３で決定された送信タイミングで、ＳＲを送信する。
【００６２】
以上説明したように、本形態のタイミング決定部１０３は、発生したイベントが、受信装置１０６が再生するビデオデータの第１のフレーム内にイベント画像を表示させるべきイベントである場合、以下のようにＳＲの送信タイミングを決定する。すなわち、タイミング決定部１０３は、イベントデータの送信が開始され、かつ、第１のフレームのビデオデータの送信が完了したタイミングで、ＳＲを送信させる。
【００６３】
なお、本形態では、送信されるメディアデータがビデオデータである場合について説明したが、例えば音声データを送信する場合にも適用可能である。例えば、タイミング決定部１０３は、発生したイベントが、閾値以上の音声を検知したことを示すイベントである場合に、イベント画像を表示すべきイベントが発生したと判定する。そして、タイミング決定部１０３は、イベントデータの送信が開始され、かつ、閾値以上の音声を検知したタイミングに対応する第１のフレームの送信が完了したタイミングで、ＳＲを送信させる。
【００６４】
このようにすることで、受信装置１０６は、例えば、イベント画像を表示させるイベントデータがすべてロスした場合であっても、イベント画像を表示させるべきフレームの再生までにそのロスを検知できる可能性が向上する。これにより、受信装置１０６は、イベント画像を表示させるべきフレーム内に、ビデオデータ（音声データ）に関する何らかのイベントが発生したことを表示できる。
【００６５】
なお、本形態の送信装置１００は、ステップＳ９０６で特定された送信タイミングでＳＲを送信する例について説明したが、第１、第２の方法で決定された送信タイミングと、ステップＳ９０５で決定された送信タイミングのそれぞれでＳＲを送信しても良い。また、本形態の送信装置１００は、複数のメディアデータを受信装置１０６に送信することも可能である。
【００６６】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図６】
0005506362.tif 000002
【図１】
0005506362.tif 000003
【図２】
0005506362.tif 000004
【図３】
0005506362.tif 000005
【図４】
0005506362.tif 000006
【図５】
0005506362.tif 000007
【図７】
0005506362.tif 000008
【図８】
0005506362.tif 000009