JP5341631B2 - 送信装置、受信装置、及び方法、プログラム - Google Patents

送信装置、受信装置、及び方法、プログラム Download PDF

Info

Publication number
JP5341631B2
JP5341631B2 JP2009143531A JP2009143531A JP5341631B2 JP 5341631 B2 JP5341631 B2 JP 5341631B2 JP 2009143531 A JP2009143531 A JP 2009143531A JP 2009143531 A JP2009143531 A JP 2009143531A JP 5341631 B2 JP5341631 B2 JP 5341631B2
Authority
JP
Japan
Prior art keywords
event
data
event data
specific information
packet
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
Application number
JP2009143531A
Other languages
English (en)
Other versions
JP2011003993A (ja
JP2011003993A5 (ja
Inventor
由香 歌川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2009143531A priority Critical patent/JP5341631B2/ja
Priority to US12/814,370 priority patent/US8713396B2/en
Publication of JP2011003993A publication Critical patent/JP2011003993A/ja
Publication of JP2011003993A5 publication Critical patent/JP2011003993A5/ja
Application granted granted Critical
Publication of JP5341631B2 publication Critical patent/JP5341631B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/006Identification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1443Transmit or communication errors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045Arrangements at the receiver end

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Communication Control (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、定期的に送信されるデータとイベントの発生に応じて送信されるデータの送信方法に関する。
定期的に連続して送信される定期パケットのパケットロスの判定方法として、パケットに付けられたシーケンス番号を確認する方法が知られている。受信装置は、シーケンス番号の抜けを見つけることにより、パケットロスを検知することができる。
一方、イベントの発生に応じて送信されるイベントパケットのパケットロスを判定するための方法が、特許文献1に開示されている。特許文献1において、送信装置は不定期に送信されるテロップに関するパケット群の先頭パケットと最後尾パケットにそれぞれ異なるマーカービットを付加する。受信装置は、先頭パケットの受信から所定時間内に最後尾パケットを受信しなかった場合、最後尾パケットがロスしたと判定する。
特開2005−328131号公報
しかしながら、イベントデータによっては、イベントデータのロスを検知するまでに時間がかかってしまう場合があった。
このような場合の例として、イベントデータのパケット群に属するパケット数が変動する場合が挙げられる。イベントデータのパケット群に属するパケット数が変動すると、先頭パケットを受信してから最後尾パケットを受信するまでの実際の時間と、予測時間が異なってしまう。特に、パケット群のパケット数が、これまでのイベントデータのパケット群よりも少なくなると、先頭パケットを受信してから最後尾パケットを受信するまでの予測時間が、実際の時間間隔よりも長くなる。このため、予測時間が経過するまで待つと、最後尾パケットのロスの検知までに時間がかかってしまうことになる。従って、イベントによってイベントデータのパケット数が異なる場合、イベントデータのロスを検知するまでに時間がかかってしまう場合があった。
また、イベントデータのパケットが1つしかない場合は、先頭パケットと最後尾パケットに異なるマーカービットを付加できないので、例えば、次のイベントデータを受信するまで、イベントデータのパケットロスを検知することができなかった。
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、イベントの発生に応じて送信されるイベントデータのロスをより早く検知できるようにすることである。
上記の問題点を解決するために、本発明の送信装置は、例えば、以下の構成を有する。すなわち、所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信する送信装置であって、前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成手段と、前記生成された特定情報を前記定期データに含める制御手段と、複数のイベントデータの組み合わせに基づいて、前記複数のイベントデータ中のエラーを前記受信装置が訂正するための冗長データを生成する冗長データ生成手段を有し、前記特定情報生成手段は、前記冗長データを生成するために組み合わせた前記複数のイベントデータが、前記組み合わせたイベントデータであることを示す特定情報を生成する。
本発明によれば、イベントの発生に応じて送信されるイベントデータのロスをより早く検知できるようになる。
実施形態1における送信装置と受信装置の機能構成例を示すブロック図である。 実施形態1のパケット送信処理を説明するためのフローチャートである。 実施形態1の受信装置によるイベントデータのロスの検知処理を説明するためのフローチャートである。 イベントデータの特定情報の一例を示す図である。 実施形態2において送信されるパケットを説明するための図である。 実施形態2における、送信装置と受信装置の処理を説明するための図である。 実施形態2の受信装置の処理を説明するためのフローチャートである。 実施形態1における、定期データとイベントデータの送信タイミングの一例を示す図である。 実施形態3における、定期データとイベントデータの送信タイミングの一例を示す図である。 実施形態3における特定情報の例を示す図である。
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
<実施形態1>
以下、本発明の実施形態について、図面を参照しながら説明する。
本実施形態では、動画像ファイルをRTP(A Transport Protocol for Real−Time Applications)で送信する装置に適用した好適な実施形態について詳細に説明する。
図1は、本実施形態の送信装置100と受信装置110の機能構成例を示すブロック図である。
送信装置100は、データ生成部103、情報生成部104、情報記録部105、送受信部106を備えている。また、本形態の送信装置100は、検知部101、撮影部102と別の装置として構成する例を示しているが、送信装置100がこれらを含むように構成されていても良い。すなわち、送信装置100は、例えば、ネットワークカメラなどの撮像装置で実現しても良いし、撮像装置によって撮像された映像データを配信する1台又は複数台のコンピュータで実現しても良い。
検知部101は、映像データやユーザからの入力に基づいてイベントを検知する。検知部101は、例えば、映像データからの人物検知や、動き検知結果に基づいてイベントを検知する。また、検知部101は、例えば、音や温度変化の検知結果に基づいてイベントを検知する。また、検知部101は、例えば、受信装置110のユーザや、送信装置100に接続されるほかの受信装置のユーザが、撮影部102のパラメータを変更する指示を行ったことに基づいてイベントを検知する。ユーザの操作により変更されるパラメータとして、撮像エリアに関する操作(パン、チルト、ズーム操作)や、映像データの解像度の変更操作、撮影部102の制御権の取得に係る操作などがある。ただし、これらに限らない。検知部101は、検知したイベントを情報生成部104に通知する。また、撮影部102は、撮影によって得られた映像データをデータ生成部103に送信する。
データ生成部103は、撮影部102から得られた映像データをネットワークを介して受信装置110に送信するためにパケット化し、得られた映像パケットを情報記録部105に渡す。映像パケットは、所定の間隔で送信される定期データである。
情報生成部104は、検知部101から通知されたイベントの情報を受信装置110に通知するためにパケット化し、得られたイベントパケットを情報記録部105に渡す。イベントパケットは、イベントの発生に応じて送信されるイベントデータである。本形態のイベントは、不定期に発生する。また、情報生成部104は、イベントパケットを特定するための特定情報を生成し、情報記録部105に渡す。受信装置110は、特定情報に基づいて、送信装置100が送信したイベントパケットを特定できる。即ち、情報生成部104は、送信されたイベントデータ(イベントパケット)を受信装置110が特定するための特定情報を生成する。特定情報の詳細は、後述する。
情報記録部105は、情報生成部104から渡されたイベントパケットと、データ生成部103から渡された映像パケットに基づいて、各パケットの送信順序を決定する。そして、情報記録部105は、決定した送信順序に基づいて、イベントパケットの送信後に送信される映像パケットのヘッダに、情報生成部104から渡された特定情報を付加する。即ち、情報記録部105は、映像パケット(定期データ)に、生成された特定情報を含める。情報記録部105は、決定した送信順序に基づいて、イベントパケットと、特定情報を含む映像パケットを送受信部106に渡す。
図4に、映像パケット(定期データ)にイベントパケット(イベントデータ)を特定するための特定情報を含める場合の例を示す。尚、本形態では、RTP形式の映像パケットのヘッダ(RTPヘッダ)に、特定情報を含める場合の例について説明する。図4に示すように、特定情報403は、RTPヘッダの拡張領域402に記録される。情報記録部105は、RTPヘッダの拡張領域を有効にするために、RTPヘッダの拡張ビット401をセットする。このようにすることにより、RTPヘッダの拡張領域に特定情報を記録することができるようになる。図4に示すように、本形態の情報記録部105は、イベントパケットの特定情報として、イベントパケットのシーケンスナンバーと、イベントの種類に応じた識別情報(stream ID)を記録する。Stream IDを記録することにより、複数種類のイベントのイベントパケットが同じ期間に送信される場合にも、イベントパケットを特定することができる。ただし、シーケンスナンバーのみでイベントパケットを特定できる場合は、stream IDを記録しなくても良い。また、本形態では特定情報としてイベントパケットのシーケンスナンバーを用いる例を説明しているが、例えば、イベントパケットが送信されたタイムスタンプ情報などを用いても良い。
送受信部106は、情報記録部105から渡されたイベントパケットと映像パケットをネットワークを介して受信装置110に送信する。即ち、送信装置100は、所定の間隔で送信される映像パケット(定期データ)と、イベントの発生に応じて送信されるイベントパケット(イベントデータ)を受信装置110に対して送信する。
本形態の受信装置110は、送受信部111、解析部112、回復部113、表示部114を備えている。送受信部111は、送信装置100によって送信された映像パケットとイベントパケットを受信し、それらを解析部112に渡す。
解析部112は、送受信部111で受信された映像パケットの特定情報を解析する。そして、解析部112は、特定情報の解析結果に基づいて、送信装置100によって送信されたイベントパケットのうち、受信していないイベントパケットを特定する。尚、解析部112は、送信装置100によって送信された映像パケットのうち受信していない映像パケットを、映像パケットのシーケンスナンバーに基づいて特定する。解析部112は、送信装置100によって送信された映像パケットやイベントパケットのうち、受信していないパケットの情報を回復部113に渡す。
回復部113は、送信装置100から送信されたにも関わらず、受信していないパケット(ロスパケット)を回復する。回復部113によるロスパケットの回復方法として、解析部112から渡された情報を含むロスパケットの再送要求パケットを生成し、送受信部111から送信装置100に送信する方法がある。また、ロスパケットのほかの回復方法として、正常に受信された他のパケットと、ロスパケットを回復するために用いる冗長パケットを用いる方法がある。本形態では、再送要求することによってロスパケットを回復する場合について説明する。回復部113は、送受信部111によって受信されたパケットと、回復させたロスパケットを表示部114に渡す。そして表示部114は、回復部113から渡されたパケットに基づく映像を表示させる。
図2は、本形態の送信装置100がイベントの検知に応じて行う、映像パケット(定期データ)とイベントパケット(イベントデータ)の送信処理の流れを示すフローチャートである。
ステップS201において、情報生成部104は、検知部101から通知されたイベントの情報を受け取る。情報生成部104がイベントの情報を受け取ると、ステップS202に進む。
ステップS202(特定情報生成手順)において、情報生成部104は、イベントの情報に基づいてイベントパケットを生成する。また、ステップS202において、情報生成部104は、生成したイベントパケットを受信装置110が特定するための特定情報を生成する。本形態では、特定情報としてイベントパケットのシーケンスナンバーを用いる例について説明する。情報生成部104が、イベントパケットと特定情報を情報記録部105に渡すと、ステップS203に進む。
ステップS203(制御手順)において、情報記録部105は、データ生成部103から渡された映像パケットに、情報生成部104から渡された特定情報を記録する。より詳細には、情報記録部105は、映像パケットとイベントパケットの送信順序を決定し、イベントパケットの後に送信される映像パケットに、該イベントパケットを特定するための特定情報を含める。即ち、ステップS203において、情報記録部105は、生成された特定情報を映像パケット(定期データ)に含める。
尚、本形態の情報記録部105は、あるイベントパケットの送信から、次のイベントパケットの送信までに送信される映像パケットのすべてに特定情報を含める。本形態で送信される映像パケットとイベントパケットの例を図8に示す。同図に示すように、情報記録部105は、イベントパケットM1を送信してから、次のイベントパケットM2を送信するまでに送信される映像パケットV1〜V6に、イベントパケットM1を特定するための特定情報を含める。また、情報記録部105は、イベントパケットM2を送信してから、イベントパケットM3を送信するまでに送信される映像パケットV7、V8に、イベントパケットM2を特定するための特定情報を含める。
即ち、情報記録部105は、送信されたイベントパケットM1(第1のイベントデータ)を受信装置110が特定するための特定情報を、次のイベントパケットM2(第2のイベントデータ)の送信までに送信される定期データ(映像パケットV1〜V6)に含める。
このようにすることで、イベントパケットと共に、その直後に送信される映像パケットがロスした場合であっても、より早く、イベントパケットのロスを検知することができる。ただし、この例に限らず、例えば、イベントパケットの次に送信される映像パケットにのみ、特定情報を含めるようにしても良い。また、イベントパケットの送信後に送信される所定数の映像パケットにのみ、特定情報を含めるようにしても良い。情報記録部105が、イベントパケットと、特定情報を含めた映像パケットを送受信部106に渡すとステップS204に進む。
ステップS204において、送受信部106は、イベントパケットと映像パケットを順次、受信装置110に対して送信する。
図3は、受信装置110によるパケットの受信処理の流れを示すフローチャートである。
ステップS301において、送受信部111は、送信装置100によって送信されたパケットを受信する。即ち、受信装置110は、送信装置100によって、所定の間隔で送信される映像パケット(定期データ)と、イベントの発生に応じて送信されるイベントパケット(イベントデータ)を受信する。送受信部111が映像パケットを受信すると、ステップS302に進む。
ステップS302において、解析部112は、ステップS301で受信した映像パケットに特定情報が含まれているか否かを判定する。特定情報は、送信装置100が送信したイベントパケットを特定するための情報である。ステップS302において特定情報が含まれていると判定された場合はステップS303、特定情報が含まれていないと判定された場合はステップS304に進む。
ステップS303(特定手順)において、解析部112は、特定情報を解析し、ステップS301で受信された映像パケットの前に送信されたイベントパケットを特定する。本形態の特定情報には、映像パケットの前に送信されたイベントパケットのシーケンスナンバーが含まれている。解析部112は、送信されたイベントパケットとして、特定情報に含まれるシーケンスナンバーに対応するイベントパケットを特定する。即ち、ステップS303において、解析部112は、受信した映像パケット(定期データ)に含まれる特定情報に基づいて、送信装置100によって送信されたイベントパケット(イベントデータ)を特定する。解析部112がイベントパケットのシーケンスナンバーを回復部113に渡すと、ステップS304に進む。
ステップS304(判定手順)において、回復部113は、解析部112から渡されたシーケンスナンバーに対応するイベントパケットを受信しているか否かを判定する。すなわち、回復部113は、ステップS303で得られたシーケンスナンバーに一致するシーケンスナンバーが、送受信部111によって受信されたイベントパケットのシーケンスナンバーの中に存在するか否かを判定する。即ち、ステップS304において、回復部113は、特定されたイベントパケット(イベントデータ)を受信したか否かを判定する。特定されたイベントパケットを受信していると判定された場合はステップS305に進み、特定されたイベントパケットを受信していないと判定された場合はステップS306に進む。
ステップS305において、回復部113は、ステップS301で受信した映像パケットが最後のパケットであるか否かを判定する。例えば、ユーザの操作によって、映像パケットの受信を終了する指示が入力された場合、回復部113は、ステップS301で受信したパケットが最後のパケットであると判定し、それを表示部114に渡し、処理を終了する。一方、ステップS301で受信した映像パケットが最後のパケットではないと判定されると、受信したパケットを表示部114に渡し、ステップS301に戻る。
ステップS306(送信手順)において、回復部113は、映像パケットに含まれる特定情報によって特定されるイベントパケットの再送要求を、送受信部111を介して送信装置100に送信する。即ち、ステップS306において、回復部113は、ステップS304により受信していないと判定されたイベントパケット(イベントデータ)の再送要求を送信装置100に対して送信する。
以上説明したように、送信装置100の情報生成部104は、検知されたイベントに応じてイベントパケット(イベントデータ)を生成すると共にイベントパケットを特定するための特定情報を生成する。そして、情報記録部105は、情報生成部104によって生成された特定情報を、対応するイベントパケットの後に送信される映像パケット(定期データ)に含める。そして、送受信部106は、イベントパケットと、特定情報を含む映像パケットを受信装置110に送信する。
受信装置110の解析部112は、受信した映像パケットに含まれる特定情報によって特定されるイベントパケットが受信されたか否かを判定する。そして、回復部113は、解析部112によって受信されていないと判定されたイベントパケットの再送要求を送信装置100に対して送信する。
このようにすることで、受信装置110が、イベントの発生に応じて送信されるイベントデータのロスをより早く検知できるようになる。尚、本実施形態の情報記録部105は、イベントパケット(イベントデータ)の後に送信される映像パケット(定期データ)に、イベントパケットの特定情報を含める例について説明したが、この例に限らない。例えば、特定情報を、イベントパケットの直前に送信される映像パケットに含めるようにしても良い。
また、本形態では、情報記録部105が、データ生成部103によって生成された映像パケットに、特定情報を含めるようにする例について説明した。しかし、撮影部102から得られた映像データと、検知部101によって検知されたイベントの情報に基づいて、特定情報を含む映像パケットを生成するようにしても良い。
また、本形態の回復部113は、映像パケット(定期データ)のロスを、シーケンスナンバーに基づいて検知する。そして、映像パケットのロスを検知すると、送信装置100に対して再送要求を送信する。このとき、送信装置100の送受信部106は、再送要求に対応する映像パケットを読み出すと共に、読み出した映像パケットに対応するイベントパケット(イベントデータ)を読み出す。そして、送受信部106は、読み出された映像パケットとイベントパケットを再送する。即ち、送信装置100の送受信部106は、映像パケットの再送要求を受信する。そして、送受信部106は、再送要求された映像パケットに対応するイベントパケットを特定する。そして、再送要求された映像パケットと共に、特定されたイベントパケットを受信装置110に再送する。
このようにすることにより、受信装置110が、映像パケットの再送要求をして、再送された映像パケットの特定情報に対応するイベントパケットの再送要求をするよりも、早くイベントパケットを受信することができる。
また、本実施形態では、定期データの例として映像パケットを挙げているが、これに限らず、例えば、音声パケットなどのように定期的に送信されるパケットに適用することが可能である。すなわち、音声パケットに、イベントパケットの特定情報を含めるようにしても、受信装置110は、イベントパケットが送信されたか否かを判定することができる。
<実施形態2>
次に、ロスしたイベントパケット(イベントデータ)に応じて、回復方法を切り替える例について、実施形態1との差異を中心に説明する。
図5は、本実施形態において送信装置100から受信装置110に送信される映像パケット(定期データ)とイベントパケット(イベントデータ)の例を示している。送信装置100は、図5の上側に示すように、映像パケットを所定の間隔で受信装置110に対して送信する。そして、図5の下側に示すように、送信装置100は、イベントの発生に応じて送信されるイベントパケットM1〜M20を受信装置110に対して送信する。本形態では、イベントは、不定期に発生する。ここで、イベントパケットM1〜M10は、1つのイベントに応じて送信されるイベントパケットである。また、イベントパケットM11は、1つのイベントに応じて送信されるイベントパケットである。同様に、イベントパケットM12は、1つのイベントに応じて送信されるイベントパケットであり、イベントパケットM13〜M20は、1つのイベントに応じて送信されるイベントパケットである。すなわち、本形態では、発生するイベントによって、生成されるイベントパケットの数が異なる。図5では、4つのイベントが発生し、イベントパケットM1〜M20が送信される。
本形態の情報生成部104は、1つのイベントに対して複数のイベントパケットを生成する場合、複数のイベントパケットを用いてFEC(Forward Error Correction)パケットを生成する。FECパケットは、複数のイベントパケットのうちの一部がエラーしても、そのエラーを受信装置110が回復できるようにするための冗長パケット(冗長データ)である。本形態の情報生成部104は、複数のイベントパケットを排他的論理和演算することによってFECパケットを生成し、それを冗長パケットとして用いる。従って、本形態の受信装置110は、1つのイベントに応じて送信される複数のイベントパケットのうちの1つがロスしても、それを回復することができる。
即ち、情報生成部104は、複数のイベントパケット(イベントデータ)の組み合わせに基づいて、複数のイベントデータ中のエラーを受信装置110が訂正するための冗長データを生成する。尚、冗長パケットの生成方法は、排他的論理和演算による方法に限らない。
図5の例において、送信装置100は、イベントパケットM1〜M10の10個のイベントパケットを用いてFECパケットを生成し、イベントパケットM10の次に送信する。また、送信装置100は、イベントパケットM13〜M20の8個のイベントパケットを用いてFECパケットを生成し、イベントパケットM20の次に送信する。尚、送信装置100は、イベントパケットM11と、M12がロスしたときのためのFECパケットは送信しない。
図6は、本形態における送信装置100と受信装置110の処理の例を示している。同図において、送信側(送信装置100)は、イベントパケットM1〜M10を受信側(受信装置110)に対して送信する(601)。上述のように、10個のイベントパケットM1〜M10は、1つのイベントに対して生成されたイベントパケットである。また、送信装置100は、イベントパケットM1〜M10の組み合わせに基づいて生成したFECパケットを映像パケットM10の後に送信する。
図6の例において、受信装置110は、イベントパケットM1〜M10のうち、イベントパケットM5を受信していない。この場合、受信装置110は、送信装置100によって送信されたイベントパケットM5を受信できなかったことを、イベントパケットM5の後に送信された映像パケットの特定情報に基づいて検知する。しかし、受信装置110は、ロスしたイベントパケットM5を、イベントパケットM10の後に送信されるFECパケットを用いて回復することができるので、送信装置100に対して再送要求を行わない。
ロス(エラー)したイベントパケットに対応するFECパケットが存在するか否かを判定するための方法として、例えば、以下の方法がある。第1の方法として、イベントパケットのロスを検知してから所定時間内に次のイベントパケットを受信したか否かに基づいて判定する方法がある。つまり、受信装置110は、イベントパケットを短い間隔で連続して受信している場合は、それらが1つのイベントに対応するイベントパケットであるため、FECパケットが送信されてくると判断する。
図6の例では、受信装置110の解析部112は、イベントパケットM5に対応する特定情報を含む映像パケットの受信から所定時間内に、イベントパケットM6を受信したか否かを判定する。そして、回復部113は、イベントパケットM6を受信した場合は、再送要求を送信しない。そして、回復部113は、受信していないと判定されたイベントパケットM5を、対応するFECパケット(冗長データ)を用いてエラー訂正する。このFECパケットは、イベントパケットM10の後に受信される。
一方、図6に示すように、受信装置110は、イベントパケットM11を受信していない。イベントパケットM11は、1つのイベントに応じて1つだけ生成されたイベントパケットである。従って、受信装置110は、イベントパケットM11に対応する特定情報を含む映像パケットの受信から所定時間内に、次のイベントパケットM12を受信しない。そこで、回復部113は、イベントパケットM11の再送要求を送信装置100に対して送信する。
即ち、解析部112は、受信していないと判定したイベントパケットM11(第1のイベントデータ)の特定情報を含む定期データの受信から所定時間内にイベントパケットM12(第2のイベントデータ)を受信したか否かを判定する。そして、回復部113は、解析部112によってイベントパケットM12を受信していないと判定されるとイベントパケットM11の再送要求を送信する。
尚、本形態の回復部113は、ロスしたイベントパケットに対応する映像パケットの受信から所定時間内に、FECパケットを受信した場合も、ロスしたイベントパケットに対応するFECパケットが存在すると判定する。
ロス(エラー)したイベントパケットに対応するFECパケットが存在するか否かを判定するための第2の方法として、以下の方法がある。すなわち、情報生成部104がFECパケット(冗長データ)を生成したときに、FECパケットを生成したことを示す特定情報を生成する方法である。受信装置110は、特定情報を参照してイベントパケットのロスを検知すると共に、ロスしたイベントパケットがFECパケットを生成するために用いられたイベントパケットであるか否かを判定する。即ち、送信装置100の情報生成部104は、FECパケット(冗長データ)を生成するために組み合わせた複数のイベントパケット(イベントデータ)が、組み合わせたイベントパケットであることを示す特定情報を生成する。つまり、特定情報は、該特定情報に基づいて特定されるイベントパケットがFECパケットを生成するために用いられたか否かを示す情報を含む。
この場合、受信装置110の解析部112は、ロスしたイベントパケットが、FECパケットを生成するために用いられたか否かを、特定情報に基づいて判定する。そして、ロスしたイベントパケットがFECパケットを生成するために用いられたと判定された場合、回復部113は、ロスしたイベントパケットの再送要求を行わない。一方、ロスしたイベントパケットがFECパケットを生成するために用いられていないと判定されると、ロスしたイベントパケットの再送要求を送信する。
即ち、解析部112は、受信していないと判定したイベントパケットがFECパケットを生成するために用いられたか否かを、特定情報に基づいて判定する。そして、回復部113は、解析部112によりFECパケットを生成するために用いられていないと判定されたイベントパケットの再送要求を送信する。このようにしても、受信装置110が受信しなかったイベントパケットに対応するFECパケットが存在するか否かを判定し、イベントパケットを回復するための処理を切り替えることができる。
また、本形態の受信装置110は、1つのイベントに対応する複数のイベントパケットのうちの1つがロスした場合は、そのロスパケットの再送要求を行わないが、2つ以上のイベントパケットがロスした場合は、ロスパケットの少なくとも一部を再送要求する。尚、本形態では、排他的論理和演算によってFECパケットを生成するが、より誤り訂正能力の高いFECパケットの生成方法を用いている場合は、2つのイベントパケットがロスしても、回復できる場合がある。即ち、回復部113は、FECパケット(冗長データ)を生成するために用いられた複数のイベントパケット(イベントデータ)のうち所定数以上、受信していないと判定された場合、受信していないと判定されたイベントデータの再送要求を送信する。
尚、受信装置110が再送要求をするか否かを切り替える代わりに、送信装置100が、受信した再送要求に応じて、再送するか否かを切り替えるようにしても良い。つまり、送信装置100の情報生成部104は、複数のイベントパケットの組み合わせに基づいて、当該複数のイベントパケット中のエラーを訂正するためのFECパケットを生成している。従って、送受信部106は、FECパケットの生成のために組み合わせられた複数のイベントパケットのうちの1つのイベントパケットの再送要求を受信しても、再送要求に応じたイベントパケットを再送しない。一方、同じ組み合わせのイベントパケットの再送要求を複数パケット分、受信した場合、ロスパケットをFECパケットで回復することができないので、再送要求に応じたイベントパケットのうち、少なくとも一部の再送を行う。尚、再送要求をするか否かを判定するための閾値は、FECパケット(冗長データ)の生成方法に応じて異なる。
即ち、送受信部106は、受信装置110から、再送要求を受信する。そして、送受信部106は、同じ組み合わせのイベントパケット(イベントデータ)の再送要求が所定数以上、受信されたことに応じて、該再送要求に対応するイベントパケットを再送する。
このようにすれば、受信装置110が、ロスしたイベントパケットに応じて、回復方法を切り替える機能を持っていなくても、本実施形態のような処理を行うことができる。
次に、本実施形態における受信装置110の処理の流れについて、図7を用いて説明する。図7のステップS701において、送受信部111は、映像パケット(定期データ)を受信する。そして、解析部112は、送受信部111によって受信された映像パケットに特定情報が含まれているか否かを判定する。つまり、図7のステップS701は、図3のステップS301とS302の処理を含んでいる。ステップS701で特定情報が含まれていると判定された場合はステップS702に進む。
ステップS702において、解析部112は、特定情報を解析することにより、直前に送信されたイベントパケットを特定し、ステップS703に進む。
ステップS703において、解析部112は、ステップS702で特定されたイベントパケットがロスしたか否かを判定する。本形態では、特定されたイベントパケットがロスしたとして、ステップS704に進む。
ステップS704において、回復部113は、イベントパケットを連続受信しているか否かを判定する。即ち、回復部113は、第1のイベントパケットの特定情報を含む映像パケットの受信から所定時間内に第2のイベントパケットを受信したか否かを判定する。所定時間内に第2のイベントパケットを受信したと判定された場合はステップS701に戻り、受信しなかったと判定された場合はステップS705に進む。
ステップS705において、回復部113は、次のイベントパケットの待機中であるか否かを判定する。つまり、回復部113は、ステップS704において、ロスしたイベントパケットの次のイベントパケットを受信していないと判定されても、次のイベントパケットを受信する予定がある(待機中である)か否かを判定する。そして、回復部113は、次のイベントパケットを受信する予定があると判定した場合は再送要求を行わず、FECパケットによる回復を行う。
次のイベントパケットを受信する予定があるか否かの判定方法として、例えば、以下の方法がある。すなわち、特定情報に、FECパケットを生成するために複数のイベントパケットを組み合わせたことを示す情報が含まれている場合、特定情報に基づいて、次のイベントパケットの待機中であるか否かを判定する。また、別の判定方法として、回復部113は、これまでに受信したイベントパケットの内容に基づいて、ロスしたイベントパケットが、1つのイベントに対応する複数のイベントパケットのうちの1つであるのか判定するようにしても良い。ステップS705で次のイベントパケットの待機中であると判定された場合は、ステップS707に進み、待機中でないと判定された場合はステップS706に進む。
ステップS706において、回復部113は、ロスしたイベントパケットの再送要求を、送信装置100に対して送信する。また、ステップS707において、回復部113は、後で受信したFECパケットを用いて、ロスしたイベントパケットを回復する。ただし、上述のように、回復部113は、FECパケットを生成するために組み合わせた複数のイベントパケットのうち、所定数以上のイベントパケットがロスした場合、ロスしたイベントパケットの再送要求を送信する。
以上説明したように、本形態の受信装置110の解析部112は、ロスしたイベントパケットが、FECパケットを生成するために組み合わせられたイベントパケットのうちの1つであるか否かに応じて、ロスしたイベントパケットの回復方法を切り替える。すなわち、ロスしたイベントパケットが、FECパケットを生成するために組み合わせられたイベントパケットのうちの1つである場合は、ロスしたイベントパケットの再送要求を行わず、FECパケットにより回復させる。一方、ロスしたイベントパケットが、FECパケットを生成するために用いられたイベントパケットでない場合は、ロスしたイベントパケットを再送させることにより回復させる。
このようにすることで、1つのイベントに対応する複数のイベントパケットのうちの一部のロスパケットを回復させるまでにかかる時間を、再送によって回復する場合よりも短くすることができる。
尚、本実施形態では、1つのイベントに対応する複数のイベントパケットを組み合わせてFECパケットを生成する場合の例について説明したが、この例に限らない。例えば、所定時間内に複数のイベントが発生した場合、複数のイベントに対応するイベントパケットを組み合わせてFECパケットを生成するようにしても良い。また、例えば、1つのイベントに対応するイベントパケットの数が所定数以上の場合は、イベントパケットを複数の組に分けて、それぞれの組でFECパケットを生成するようにしても良い。このようにすることにより、より早くロスパケットを回復させることができるようになる。
<実施形態3>
次に、複数の異なるイベントに対応するイベントパケットを同じ期間に送信する場合の例について、実施形態1との差異を中心に説明する。
図9は、1種類の映像パケット(定期データ)と2種類のイベントパケット(イベントデータ)が送信されている場合の例を示したものである。このような例として、送信装置100による映像パケットの送信中に、撮影部102の撮影方向が変更され、さらに、同じタイミングで、検知部101が、撮影画像内に人物を検知した場合がある。このとき、送信装置100は、撮影方向の変更を通知するためのイベントパケット(イベントデータ1)と、人物検知を通知するためのイベントパケット(イベントデータ2)を受信装置110に対して送信する。
図9において、イベントデータ1のイベントパケットM1−1の送信直後の映像パケットと、イベントデータ2のイベントパケットM2−1の送信直後の映像パケットは、共に映像パケットV1である。そこで、情報記録部105は、映像パケットV1に、イベントパケットM1−1とM2−1を、それぞれ特定するための特定情報を含める。
図10は、本形態の情報記録部105によって記録される特定情報の例を示している。同図に示すように、特定情報には、IPアドレス、ストリームID、シーケンスナンバーが含まれる。ストリームIDは、イベントデータの種類に対応している。例えば、図9のイベントデータ1とストリームID:A1が対応し、イベントデータ2とストリームID:B1が対応する。受信装置110は、ストリームIDとシーケンスナンバーにより、送信装置100から送信されたイベントパケットを特定することができる。
即ち、第1の種類のイベントの発生に応じて第1の種類のイベントデータ(イベントパケットM1−1)が送信され、第2の種類のイベントの発生に応じて第2の種類のイベントデータ(イベントパケットM2−1)が送信される場合、次のような特定情報が生成される。すなわち、情報生成部104は、第1の種類のイベントデータを受信装置110が特定可能な第1の特定情報と、第2の種類のイベントデータを受信装置110が特定可能な第2の特定情報を生成する。そして、情報記録部105は、第1、第2のイベントデータの送信後の定期データ(映像パケットV1)に、生成された第1、第2の特定情報を含める。
そして、受信装置110の解析部112は、受信した映像パケットV1に含まれる特定情報に基づいて、複数のイベントパケット(イベントパケットM1−1、M2−1)が特定された場合、複数のイベントパケットのそれぞれを受信したか否かを判定する。
このようにすることで、同じ期間中に複数のイベントに応じたイベントパケットを送信する場合にも、イベントパケットを特定することができる。
また、受信装置110が複数の送信装置からイベントパケットを受信する場合、IPアドレスに基づいてイベントパケットの送信元を特定することが可能である。また、ストリームIDに送信装置のIPアドレスなどの送信装置の識別情報を含めるようにしても良い。
複数の送信装置から送信されるイベントパケットを特定できるようにストリームIDを生成する場合、ストリームIDに送信装置のIPアドレスを含める方法の他に、全ストリームを管理するサーバからストリームIDを取得する方法がある。また、サーバが送信装置ごとに識別情報を割り当て、各送信装置が送信する特定情報のストリームIDに、送信装置の識別情報を含めるようにしても良い。
<その他の実施形態>
本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体(記憶媒体)等としての実施態様をとることが可能である。具体的には、複数の機器(例えば、ホストコンピュータ、インタフェース機器、撮像装置、webアプリケーション等)から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
尚本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される。なお、この場合のプログラムとは、コンピュータ読取可能であり、実施形態において図に示したフローチャートに対応したプログラムである。
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

Claims (11)

  1. 所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信する送信装置であって、
    前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成手段と、
    前記生成された特定情報を前記定期データに含める制御手段と、
    複数のイベントデータの組み合わせに基づいて、前記複数のイベントデータ中のエラーを前記受信装置が訂正するための冗長データを生成する冗長データ生成手段を有し、
    前記特定情報生成手段は、前記冗長データを生成するために組み合わせた前記複数のイベントデータが、前記組み合わせたイベントデータであることを示す特定情報を生成することを特徴とする送信装置。
  2. 前記制御手段は、前記イベントデータを特定するための特定情報を、前記イベントデータの送信後に送信される所定数の定期データにのみ、含める
    ことを特徴とする請求項1記載の送信装置。
  3. 所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信する送信装置であって、
    前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成手段と、
    前記生成された特定情報を前記定期データに含める制御手段を有し、
    第1の種類のイベントの発生に応じて第1の種類のイベントデータが送信され、第2の種類のイベントの発生に応じて第2の種類のイベントデータが送信される場合、前記特定情報生成手段は、前記第1の種類のイベントデータの種類を示すストリームIDと前記第1の種類のイベントデータのシーケンスナンバーを含み、前記第1の種類のイベントデータを前記受信装置が特定可能な第1の特定情報と、前記第2の種類のイベントデータの種類を示すストリームIDと前記第2の種類のイベントデータのシーケンスナンバーを含み、前記第2の種類のイベントデータを前記受信装置が特定可能な第2の特定情報を生成し、
    前記制御手段は、前記第1、第2のイベントデータの送信後に送信される定期データに、前記生成された前記第1、第2の特定情報を含める
    ことを特徴とする送信装置。
  4. 前記制御手段は、前記イベントデータを特定するための特定情報を、前記イベントデータの送信後に送信される所定数の定期データにのみ、含める
    ことを特徴とする請求項3記載の送信装置。
  5. 所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信する送信装置であって、
    前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成手段と、
    前記生成された特定情報を前記定期データに含める制御手段と、
    前記受信装置から定期データの再送要求を受信する受信手段と、
    前記再送要求された定期データに対応するイベントデータを特定する特定手段と、
    前記再送要求された定期データと共に、前記特定手段によって特定されたイベントデータを、前記受信装置に再送する再送手段と
    を有することを特徴とする送信装置。
  6. 前記制御手段は、前記イベントデータを特定するための特定情報を、前記イベントデータの送信後に送信される所定数の定期データにのみ、含める
    ことを特徴とする請求項5記載の送信装置。
  7. 送信装置によって、所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信する受信装置であって、
    前記受信した定期データに含まれる特定情報に基づいて、前記送信装置によって送信されたイベントデータを特定する特定手段と、
    前記特定されたイベントデータを受信したか否かを判定する判定手段と、
    前記判定手段により受信していないと判定されたイベントデータの再送要求を前記送信装置に対して送信する送信手段と、
    前記送信装置によって送信された冗長データを受信する受信手段と、
    前記判定手段によって受信していないと判定されたイベントデータを、当該イベントデータに対応する冗長データを用いてエラー訂正する訂正手段を有し、
    前記特定情報は、当該特定情報に基づいて特定されるイベントデータが冗長データを生成するために用いられたか否かを示す情報を含み、
    前記判定手段は、受信していないと判定したイベントデータが冗長データを生成するために用いられたか否かを前記特定情報に基づいて判定し、
    前記送信手段は、前記判定手段により冗長データを生成するために用いられていないと判定されたイベントデータの再送要求を送信する
    ことを特徴とする受信装置。
  8. 所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信する送信装置が行う送信方法であって、
    前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成工程と、
    前記生成された特定情報を前記定期データに含める制御工程と
    前記受信装置から定期データの再送要求を受信する受信工程と、
    前記再送要求された定期データに対応するイベントデータを特定する特定工程と、
    前記再送要求された定期データと共に、前記特定工程によって特定されたイベントデータを、前記受信装置に再送する再送工程と
    を有することを特徴とする送信方法。
  9. 所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信装置に対して送信するコンピュータに、
    前記受信装置が受信したデータのうち前記イベントデータを特定するための特定情報を生成する特定情報生成手順と、
    前記生成された特定情報を前記定期データに含める制御手順と
    前記受信装置から定期データの再送要求を受信する受信手順と、
    前記再送要求された定期データに対応するイベントデータを特定する特定手順と、
    前記再送要求された定期データと共に、前記特定手順によって特定されたイベントデータを、前記受信装置に再送する再送手順と
    を実行させることを特徴とするプログラム。
  10. 送信装置によって、所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信する受信装置が行う制御方法であって、
    前記受信した定期データに含まれる特定情報に基づいて、当該定期データの前に送信されたイベントデータを特定する特定工程と、
    前記特定されたイベントデータを受信したか否かを判定する判定工程と、
    前記判定工程により受信していないと判定されたイベントデータの再送要求を前記送信装置に対して送信する送信工程と
    前記送信装置によって送信された冗長データを受信する受信工程と、
    前記判定工程によって受信していないと判定されたイベントデータを、当該イベントデータに対応する冗長データを用いてエラー訂正する訂正工程を有し、
    前記特定情報は、当該特定情報に基づいて特定されるイベントデータが冗長データを生成するために用いられたか否かを示す情報を含み、
    前記判定工程は、受信していないと判定したイベントデータが冗長データを生成するために用いられたか否かを前記特定情報に基づいて判定し、
    前記送信工程は、前記判定工程により冗長データを生成するために用いられていないと判定されたイベントデータの再送要求を送信することを特徴とする制御方法。
  11. 送信装置によって、所定の間隔で送信される定期データと、イベントの発生に応じて送信されるイベントデータを受信するコンピュータに、
    前記受信した定期データに含まれる特定情報に基づいて、当該定期データの前に送信されたイベントデータを特定する特定手順と、
    前記特定されたイベントデータを受信したか否かを判定する判定手順と、
    前記判定手順により受信していないと判定されたイベントデータの再送要求を前記送信装置に対して送信する送信手順と
    前記送信装置によって送信された冗長データを受信する受信手順と、
    前記判定手順によって受信していないと判定されたイベントデータを、当該イベントデータに対応する冗長データを用いてエラー訂正する訂正手順を実行させ、
    前記特定情報は、当該特定情報に基づいて特定されるイベントデータが冗長データを生成するために用いられたか否かを示す情報を含み、
    前記判定手順は、受信していないと判定したイベントデータが冗長データを生成するために用いられたか否かを前記特定情報に基づいて判定させ、
    前記送信手順は、前記判定手順により冗長データを生成するために用いられていないと判定されたイベントデータの再送要求を送信させることを特徴とするプログラム。
JP2009143531A 2009-06-16 2009-06-16 送信装置、受信装置、及び方法、プログラム Expired - Fee Related JP5341631B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009143531A JP5341631B2 (ja) 2009-06-16 2009-06-16 送信装置、受信装置、及び方法、プログラム
US12/814,370 US8713396B2 (en) 2009-06-16 2010-06-11 Transmission apparatus, receiving apparatus, method, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009143531A JP5341631B2 (ja) 2009-06-16 2009-06-16 送信装置、受信装置、及び方法、プログラム

Publications (3)

Publication Number Publication Date
JP2011003993A JP2011003993A (ja) 2011-01-06
JP2011003993A5 JP2011003993A5 (ja) 2012-08-02
JP5341631B2 true JP5341631B2 (ja) 2013-11-13

Family

ID=43307473

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009143531A Expired - Fee Related JP5341631B2 (ja) 2009-06-16 2009-06-16 送信装置、受信装置、及び方法、プログラム

Country Status (2)

Country Link
US (1) US8713396B2 (ja)
JP (1) JP5341631B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5857388B2 (ja) * 2011-09-12 2016-02-10 富士通株式会社 伝送装置および伝送方法
IL217307A (en) * 2012-01-01 2015-09-24 Video Flow Ltd Continuous error correction (fec) system and method
EP2672386A3 (en) * 2012-06-08 2016-07-20 Samsung Electronics Co., Ltd Apparatus and method for processing asynchronous event information
US10341047B2 (en) * 2013-10-31 2019-07-02 Hewlett Packard Enterprise Development Lp Method and system for controlling the forwarding of error correction data
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10567102B2 (en) * 2017-02-06 2020-02-18 Valens Semiconductor Ltd. Efficient double parity forward error correction on a communication network
CN107766508B (zh) * 2017-10-23 2021-06-15 深圳市中润四方信息技术有限公司 一种数据文件采集分发的方法、系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5196842A (en) * 1991-07-22 1993-03-23 Motorola, Inc. Pager capable of operating in multiple paging systems
JP4187940B2 (ja) * 2001-03-06 2008-11-26 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法及びシステム、並びにパケット送信装置、受信装置、及び送受信装置
US6951305B2 (en) * 2001-11-21 2005-10-04 Goliath Solutions, Llc. Advertising compliance monitoring system
US7374096B2 (en) * 2001-11-21 2008-05-20 Goliath Solutions, Llc Advertising compliance monitoring system
JP2003308260A (ja) * 2002-04-15 2003-10-31 Canon Inc ネットワーク機器およびサーバ装置およびデータ処理方法および記憶媒体
US6830515B2 (en) * 2002-09-10 2004-12-14 Igt Method and apparatus for supporting wide area gaming network
US7765280B2 (en) * 2002-11-06 2010-07-27 Scientific-Atlanta, Llc Downloadable remotely stored device drivers for communication with set-top box peripherals
JP4340134B2 (ja) * 2003-12-02 2009-10-07 日本放送協会 コンテンツ加工装置、コンテンツ加工方法、及びコンテンツ加工プログラム
JP2005328131A (ja) * 2004-05-12 2005-11-24 Toshiba Corp リアルタイムデータ受信装置
US7756539B2 (en) * 2005-05-27 2010-07-13 Microsoft Corporation Push-to-talk event notification
JP4710719B2 (ja) * 2006-06-01 2011-06-29 株式会社明電舎 通信異常時の再送装置
WO2008023638A1 (fr) * 2006-08-21 2008-02-28 Panasonic Corporation Système de communication sans fil, procédé de commande de communication et nœud de communication
JP2008270931A (ja) * 2007-04-16 2008-11-06 Nakayo Telecommun Inc 無線アクセスポイントおよびリアルタイム通信パケットの無線中継方法

Also Published As

Publication number Publication date
US20100318870A1 (en) 2010-12-16
US8713396B2 (en) 2014-04-29
JP2011003993A (ja) 2011-01-06

Similar Documents

Publication Publication Date Title
JP5341631B2 (ja) 送信装置、受信装置、及び方法、プログラム
US7386872B2 (en) Network storage type video camera system
US9191158B2 (en) Communication apparatus, communication method and computer readable medium
US8312352B2 (en) Communication apparatus and communication method
US7663665B2 (en) Communication device and method for transferring video-stream data to a display device and a storage device
JP5677070B2 (ja) 受信装置及び、受信装置による処理方法
EP2978171A1 (en) Communication method, communication device, and communication program
JP2010183439A (ja) 送信装置、及び、方法、プログラム
JP2020184805A (ja) ビデオサービス品質の評価方法及び装置
JP5523130B2 (ja) 通信装置、通信方法、及びプログラム
JP2007208541A (ja) 管理装置及びプログラム
JP2013051565A (ja) 通信端末装置、通信制御方法、及び通信制御プログラム
WO2015147610A2 (ko) 통신 시스템에서 패킷 송수신 방법 및 장치
JP2008131599A (ja) キャスト伝送装置及びキャスト伝送方法
JP2009188674A (ja) 送信装置、受信装置、動画音声伝送品質評価方法および動画音声伝送品質評価プログラム
CN101589570B (zh) 媒体数据的分组交换传送的方法和处理媒体数据的设备
JP6740002B2 (ja) 制御装置、制御方法及びプログラム
JP5506362B2 (ja) 送信装置、送信方法
JP2011211616A (ja) 動画像伝送装置、動画像伝送システム、動画像伝送方法およびプログラム
CN116582700B (zh) 实时视频监控篡改检测方法、装置及设备
JP2009206608A (ja) 通信装置
US8499223B2 (en) Receiving apparatus, receiving method and non-transitory computer readable recording medium for recording receiving program
JP6237367B2 (ja) データ伝送システム、送信装置、受信装置、送信プログラム、受信プログラムおよびデータ伝送方法
JP2005175993A (ja) ワーム伝播監視システム
JP5966502B2 (ja) データ受信方法及び装置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120615

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120615

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130418

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130423

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130624

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: 20130716

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130808

R151 Written notification of patent or utility model registration

Ref document number: 5341631

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees