JP2005136545A - 送信装置および方法、プログラム格納媒体、並びにプログラム - Google Patents
送信装置および方法、プログラム格納媒体、並びにプログラム Download PDFInfo
- Publication number
- JP2005136545A JP2005136545A JP2003368417A JP2003368417A JP2005136545A JP 2005136545 A JP2005136545 A JP 2005136545A JP 2003368417 A JP2003368417 A JP 2003368417A JP 2003368417 A JP2003368417 A JP 2003368417A JP 2005136545 A JP2005136545 A JP 2005136545A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- retransmission
- transmission
- time
- streaming data
- 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.)
- Withdrawn
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 169
- 238000000034 method Methods 0.000 title claims description 85
- 238000012545 processing Methods 0.000 claims abstract description 96
- 238000004891 communication Methods 0.000 claims description 90
- 230000004044 response Effects 0.000 claims description 23
- 238000012790 confirmation Methods 0.000 claims description 6
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 abstract description 91
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 abstract description 91
- 230000007423 decrease Effects 0.000 abstract description 2
- 238000005259 measurement Methods 0.000 description 71
- 238000010586 diagram Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 6
- 239000000284 extract Substances 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 3
- 239000004065 semiconductor Substances 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 101000969688 Homo sapiens Macrophage-expressed gene 1 protein Proteins 0.000 description 1
- 102100021285 Macrophage-expressed gene 1 protein Human genes 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Landscapes
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】不要になった再送パケットを消去し、再送用バッファの記憶領域をより少なくする。
【解決手段】 パケタイザ84は、相手に送信した送信パケットに対応する再送パケットを再送用バッファ85に記憶させる。送信部101は、相手からの再送要求に対して記憶されている再送パケットを相手に送信する。受信部102は最終再送要求を受信する。最終再送要求が受信された場合、NACK処理部86は、最終再送要求に含まれるシーケンス番号以下の再送パケットを再送用バッファ85から消去する。本発明は、遠隔テレビ会議システムに適用できる。
【選択図】図4
【解決手段】 パケタイザ84は、相手に送信した送信パケットに対応する再送パケットを再送用バッファ85に記憶させる。送信部101は、相手からの再送要求に対して記憶されている再送パケットを相手に送信する。受信部102は最終再送要求を受信する。最終再送要求が受信された場合、NACK処理部86は、最終再送要求に含まれるシーケンス番号以下の再送パケットを再送用バッファ85から消去する。本発明は、遠隔テレビ会議システムに適用できる。
【選択図】図4
Description
本発明は送信装置および方法、プログラム格納媒体、並びにプログラムに関し、特に、不要になったデータを消去することによって、再送用バッファの記憶領域をより少なくすることができるようにした送信装置および方法、プログラム格納媒体、並びにプログラムに関する。
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の伝送方式のサービスに加えて、ストリーム型の伝送方式のサービスがより多く提供されるようになってきた。
ダウンロード型の伝送方式のサービスにおいては、受信装置が、送信装置から送信された画像または音声のデータを格納するファイルを受信し、受信したファイルを自分の記録媒体に記録する。受信装置は、ファイルの記録が完了した後、記録したファイルを基に、画像または音声を再生する。ダウンロード型の伝送方式のサービスにおいては、ファイルの記録が完了するまでは、再生することができないので、ダウンロード型の伝送方式のサービスは、長時間の再生またはリアルタイムの再生には適さない。
一方、ストリーム型の伝送方式のサービスにおいては、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般にストリーミングデータと称する。
より具体的な例として、ストリーム型の伝送方式は、画像データにMPEG(Moving Picture Experts Group)符号化処理を適用することにより生成されるMPEGストリームを格納する、IP(Internet Protocol)パケットをインターネットを介して伝送するシステムで使用される。このシステムにおいて、受信装置である、PC(Personal Computer)、PDA(Personal Digital Assistance)、または携帯電話機は、IPパケットを受信し、画像を再生する。
ストリーム型の伝送方式は、ビデオオンデマンド若しくはライブ映像のストリーミング配信、ビデオ会議、またはテレビ電話などのリアルタイム通信に適している。
このようなストリーム型の伝送方式の技術の1つとして、IETF RFC(Internet Engineering Task Force Request For Comments)1889で規定されているプロトコルであるRTP(Real time Transport Protocol)がある。
RTPに基づくデータ転送においては、生成された時刻を示すタイムスタンプがパケットに付加され、タイムスタンプの参照により送信側と受信側の時間的関係が把握されるので、受信側において、パケット伝送の遅延ゆらぎ(ジッタ−)などの影響が排除され、同期した再生が可能になる。
しかし、RTPにおいて、実時間のデータの伝送は保証されない。すなわち、パケット配信の優先度や設定、管理などは、RTPによって提供されるトランスポートサービスの範疇ではないため、他の方式のパケットと同様、ネットワーク上での遅延やパケットロスが生じる可能性がある。
遅延やパケットロスが生じても、受信側は、再生時刻までに受信されたパケットだけを利用してデータを再生することができる。すなわち、受信装置は、データに多少の損失や誤りが発生しても、品質を落として再生するか、またはデータの損失や誤りを訂正して再生する。
この場合、再生に間に合わず遅延して配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、高品質なデータ配信処理を行おうとしても、パケットロスやエラーが発生したときは、受信側の再生の品質は保証されない。
このようなRTPに従ったデータ伝送における問題を解決する案として、データ転送の信頼性のより高い転送プロトコルであるTCP(Transmission Control Protocol)に従ってパケットの再送要求およびパケットの再送を行う方法が考えられる。
しかしながら、TCPにおいて、パケットロスが生じた場合、パケットが再送されるので、エラーには強いが、受信側において、再送されたパケットの受信が再生時刻に間に合わない可能性があり、リアルタイム通信には不向きである。
したがって、送信と受信の遅延が少ないARQ(Automatic Repeat Request)などの技術が必要とされる。
この問題の解決方法として、パケットロスが生じた場合、受信装置は、後述する往復遅延時間(RTT(Round Trip Time))を基に、再送されるパケットの受信が再生処理に間に合わないと判定されたときは、サーバに再送を要求しないという方法が提案されている。(例えば、特許文献1参照)。再送の要求はNACK(Negative Acknowledement)パケットの送信によって行われる。
従来のARQにおいて、図1で示されるように、サーバ(送信装置)がクライアント(受信装置)あてにストリーミングデータを送る。図1における横方向は、時間を示す。図1において、フレーム1−1を再生するための画像データであるストリーミングデータは送信パケット11−1乃至送信パケット11−3、フレーム1−2を再生するための画像データであるストリーミングデータは送信パケット11−4乃至送信パケット11−6、フレーム1−3を再生するための画像データであるストリーミングデータは送信パケット11−7乃至送信パケット11−9に格納されて送信される。図1において、時刻t70から時刻t71までのT1−1、時刻t71から時刻t72までのT1−2、および時刻t72から時刻t73までのT1−3は、それぞれフレーム1−1、フレーム1−2、およびフレーム1−3のそれぞれの再生時間である。
時刻t0においてサーバはクライアントあてに送信パケット11−1を送信するとともに、再送パケット12−1を再送用バッファに格納する。クライアントは時刻t40にサーバから送信された送信パケット11−1を受信する。同様に、時刻t1および時刻t2のそれぞれにおいて、サーバはクライアントあてに送信パケット11−2および11−3を送信するとともに再送パケット12−2および12−3を再送用バッファに格納する。
さらにサーバは、クライアントあてに送信パケット11−4乃至送信パケット11−9を送信するとともに、再送パケット12−4乃至再送パケット12−9を再送用バッファに格納する。また、クライアントはサーバから送信された送信パケット11−2乃至送信パケット11−9を受信する。
ここで、再送パケット12−1乃至再送パケット12−9のそれぞれには、送信パケット11―1乃至送信パケット11−9のそれぞれに含まれるストリーミングデータが格納されている。換言すれば、再送パケット12−1には、送信パケット11−1に含まれるストリーミングデータが格納され、再送パケット12−2には、送信パケット11−2に含まれるストリーミングデータが格納され、同様に、再送パケット12−3乃至再送パケット12−9のそれぞれには順に対応する送信パケット11−3乃至送信パケット11−9のそれぞれに含まれるストリーミングデータが格納される。
以下、送信パケット11−1乃至送信パケット11−9を個々に区別する必要がないとき、単に送信パケット11と称する。同様に、以下、再送パケット12−1乃至再送パケット12−9を個々に区別する必要がないとき、単に再送パケット12と称する。
実際には、送信パケット11と再送パケット12は同じパケットであるため、特に区別する必要はないが、本明細書中では説明を分かり易くするため、再送用として再送用バッファに記憶されたパケットを特に再送パケットと称する。なお、送信パケットと再送パケットの区別をしない場合には単にパケットと称する。
時刻t41においてクライアントは、通信網における往復遅延時間を計測するため、RTT計測パケット2をサーバあてに送信する。時刻t3にRTT計測パケット2を受信したサーバは、クライアントあてにRTT計測パケット2を返送する。時刻t42においてRTT計測パケット2を受信したクライアントは、RTT計測パケット2を受信した時刻t42から送信された時刻t41を引き算することにより往復遅延時間T2を算出する。クライアントは算出された往復遅延時間T2に基づき、ロスパケットの再送を要求するか否かを判定する。
時刻t43において、送信パケット11−5のパケットロスを検知したクライアントは、時刻t43に再送を要求した場合、時刻t44における再送パケット12−5の受信がフレーム1−2の再生開始時刻t71に間に合うと判定し、サーバあてに再送を要求する。
また、時刻t45において、送信パケット11−9のパケットロスを検知したクライアントは、時刻t45に再送を要求しても、フレーム1−3の再生開始時刻t72までに再送パケット12−9を受信することができないと判定し、再送を要求しない。
以上のようにして、再生処理に間に合わない再送パケットの送信を無くすことができる。
また、送信されるパケットのうち、優先度が高いパケットのみを再送しているものもある(例えば、特許文献2参照)。
しかしながら、上述した特許文献1および特許文献2に開示されている技術においては、再送パケットの受信が再生時刻に間に合わない場合には、再送を要求しないため、リアルタイムの再生に適したデータの伝送を行うことはできるが、送信装置の再送用バッファとしてより大きな記憶領域が必要とされる。
また、送信から一定の時間が経過した、再送用バッファに格納されている再送パケットを自動的に消去するという方法も考えられるが、通信網におけるパケットの伝送には通信状態によって変化する遅延ゆらぎがあるため、いつ消去してよいかが明確ではなかった。
本発明の送信装置は、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御手段と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御手段と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御手段と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御手段とを備えることを特徴とする。
受信制御手段は、相手から送信されてきた、ストリーミングデータの再生の終了を示す確認応答信号の受信をさらに制御し、消去制御手段は、確認応答信号が受信された場合、再生を終了したストリーミングデータを格納する再送パケットの消去をさらに制御するようにすることができる。
送信装置は、再生される順番を示す再生順番情報を含む送信パケットを生成する生成手段をさらに設け、記憶制御手段は、送信パケットに対応する、再生順番情報を含む再送パケットの記憶を制御し、消去制御手段は、再生順番情報を基に再送パケットの消去を制御するようにすることができる。
送信装置は、生成された時刻を示す時刻情報を含む送信パケットを生成する生成手段をさらに設け、記憶制御手段は、送信パケットに対応する、時刻情報を含む再送パケットの記憶を制御し、消去制御手段は、時刻情報を基に再送パケットの消去を制御するようにすることができる。
本発明の送信方法は、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップとを含むことを特徴とする。
本発明の記録媒体のプログラムは、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御テップを含むことを特徴とする。
本発明のプログラムは、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御テップをコンピュータに実行させることを特徴とする。
送信装置は、独立した装置であってもよいし、通信装置の送信処理を行うブロックであってもよい。
本発明の送信装置および方法、記録媒体、並びにプログラムにおいては、相手に送信した送信パケットに対応する再送パケットが記憶され、相手からの再送要求に対応して記憶されている再送パケットが相手に送信される。そして、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求が受信される。さらに、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットが消去される。
本発明によれば、再送用バッファの記憶容量をより少なくすることが可能となる。
以下に本発明の最良の形態を説明するが、本明細書に記載の発明と、発明と実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現し、追加される発明の存在を否定するものではない。
本発明によれば、送信装置が提供される。この送信装置(例えば、図2のサーバ22)は、相手に送信した送信パケット(例えば、図6の送信パケット181)に対応する再送パケット(例えば、図6の再送パケット182)の記憶を制御する記憶制御手段(例えば、図4の再送用バッファ85)と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御手段(例えば、図4の送信部101)と、相手が再送要求(例えば、図10で示されるNACKパケット)を送信してから再送パケットを受信するまでに必要とされる遅延時間(例えば、図6の往復遅延時間T12)より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求(例えば、図12で示されるNACKパケット)の受信を制御する受信制御手段(例えば、図4の受信部102)と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御手段(例えば、図4のNACK処理部86)とを備える。
この送信装置は、受信制御手段(例えば、図4の受信部102)が、相手から送信されてきた、ストリーミングデータの再生の終了を示す確認応答信号(例えば、図11で示されるACK(Acknowledgement)パケット)の受信をさらに制御し、消去制御手段(例えば、図4のNACK処理部86)が、確認応答信号が受信された場合、再生を終了したストリーミングデータを格納する再送パケット(例えば、図6の再送パケット182)の消去をさらに制御するようにすることができる。
この送信装置は、再生される順番を示す再生順番情報(例えば、シーケンス番号)を含む送信パケットを生成する生成手段(例えば、図4のパケタイザ84)をさらに備え、記憶制御手段(例えば、図4の再送用バッファ85)が、送信パケットに対応する、再生順番情報を含む再送パケットの記憶を制御し、消去制御手段(例えば、図4のNACK処理部86)が、再生順番情報を基に再送パケットの消去を制御するようにすることができる。
この送信装置は、生成された時刻を示す時刻情報(例えば、タイムスタンプ)を含む送信パケットを生成する生成手段(例えば、図4のパケタイザ84)をさらに備え、記憶制御手段(例えば、図4の再送用バッファ85)が、送信パケットに対応する、時刻情報を含む再送パケットの記憶を制御し、消去制御手段(例えば、図4のNACK処理部86)が、時刻情報を基に再送パケットの消去を制御するようにすることができる。
また、本発明によれば、送信方法が提供される。この送信方法は、相手に送信した送信パケット(例えば、図6の送信パケット181)に対応する再送パケット(例えば、図6の再送パケット182)の記憶を制御する記憶制御ステップ(例えば、図7のステップS7の処理)と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップ(例えば、図15のステップS92の処理)と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間(例えば、図6の往復遅延時間T12)より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求(例えば、図12で示されるNACKパケット)の受信を制御する受信制御ステップ(例えば、図15のステップS93の処理)と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップ(例えば、図15のステップS94の処理)とを含む。
また、本発明によれば、プログラムが提供される。このプログラムは、相手に送信した送信パケット(例えば、図6の送信パケット181)に対応する再送パケット(例えば、図6の再送パケット182)の記憶を制御する記憶制御ステップ(例えば、図7のステップS7の処理)と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップ(例えば、図15のステップS92の処理)と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間(例えば、図6の往復遅延時間T12)より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップ(例えば、図15のステップS93の処理)と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップ(例えば、図15のステップS94の処理)とをコンピュータに実行させる。
このプログラムは記録媒体(例えば、図3の磁気ディスク61)に記録することができる。
本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システム、またはテレビ電話などのリアルタイムにストリーミングデータを伝送する通信システムに適用できる。
図2は本発明を適用したストリーミング配信システムの一実施の形態を示す図である。このストリーミング配信システムにおいては、インターネットなどの通信網23に、サーバ22およびクライアント24が接続されている。
カメラ21は、画像を撮像して、撮像した画像に対応する画像データをサーバ22に供給する。例えば、カメラ21は、動画像を撮像して、動画像に対応する画像データをサーバ22に供給する。
画像データは、ストリーミングデータの一例である。ストリーミングデータは、音声のデータ、またはリアルタイム制御データなど、時間の経過に対応して順次送信または受信が要求されるデータであればよい。
サーバ22は、例えば、PCまたは専用サーバなどにより構成され、クライアント24からストリーミングデータの配信が要求された場合、カメラ21から供給された画像データをパケットに格納して、パケットを通信網23を介して、クライアント24に送信する。
通信網23は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、所定の遅延時間で、サーバ22から送信されてきたパケットをクライアント24まで伝送する。
クライアント24は、例えば、PC、PDA、あるいは携帯電話機などにより構成され、通信網23を介してサーバ22から送信されてきたパケットを受信する。クライアント24は、受信したパケットから画像データを抽出し、出力装置25に出力する。
クライアント24は、ストリーミングデータが格納されているパケットを正常に受信できなかった場合、再送パケットの受信がストリーミングデータの再生時刻に間に合うと判定されたときには、サーバ22に再送を要求する。サーバ22はクライアント24から再送が要求された場合、ストリーミングデータが格納されているパケットを再送する。
出力装置25は、クライアント24から供給された画像データを基に、画像を表示する。
なお、出力装置25は、クライアント24とは別の装置として設けるようにしてもよく、クライアント24に内蔵するようにしてもよい。
図2で示されるストリーミング配信システムの例においては、サーバ22およびクライアント24が、それぞれ1台ずつ設けられているが、実際には、サーバ22は複数のクライアント24に対してストリーミングデータを配信するので、クライアント24は、通信網23を介して複数台接続されている。また、同様に、複数のサーバ22を設けるようにしてもよい。
図3は、サーバ22の構成の例を示すブロック図である。
サーバ22のCPU(Central Processing Unit)41は、ROM(Read Only Memory)42、または記録部48に記憶されているプログラムに従って各種の処理を実行する。RAM(Random Access Memory)43には、CPU41が実行するプログラムやデータなどが適宜記憶される。これらのCPU41、ROM42、およびRAM43は、バス44により相互に接続されている。
CPU41にはまた、バス44を介して入出力インタフェース45が接続されている。入出力インタフェース45には、キーボード、マウス、スイッチなどよりなる入力部46、ディスプレイ、スピーカ、ランプなどによる出力部47が接続されている。CPU41は、入力部46から入力される指令に対応して各種の処理を実行する。
入出力インタフェース45に接続されている記録部48は、例えばハードディスクなどで構成され、CPU41が実行するプログラムや各種のデータを記録する。通信部49は、インターネット、その他のネットワークなどの通信網23を介して、クライアント24などの外部装置と通信する。
また、通信部49を介してプログラムを取得し、記録部48に記録してもよい。
入出力インタフェース45に接続されているドライブ50は、磁気ディスク61、光ディスク62、光磁気ディスク63、或いは半導体メモリ64などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部48に転送され、記録される。
なお、クライアント24は、サーバ22と同様に構成されるので、その記載および説明は省略する。サーバ22およびクライアント24は、図3に示した内部構成に限らず、必要に応じ、機能を追加したり削除したりすることは可能であり、その機能に対応した構成をもつことが可能である。
図4は、サーバ22の機能の構成を示すブロック図である。
サーバ22は、通信部49、制御部81、エンコーダ82、バッファ83、パケタイザ84、再送用バッファ85、NACK処理部86、およびタイマ87を含む。
制御部81は、サーバプログラムを実行するCPU41によって実現され、サーバ22全体を制御する。
エンコーダ82は、カメラ21から供給されたストリーミングデータの一例である画像データをエンコード(符号化)し、エンコードされた画像データをバッファ83に供給する。
バッファ83は、エンコーダ82から供給された画像データを一時的に記憶する。
パケタイザ84は、バッファ83からエンコードされた画像データを取得する。また、パケタイザ84は、取得した画像データを所定の方式のパケットに格納することにより、パケットを生成する。パケタイザ84は、生成されたパケットを再送用バッファ85および通信部49へ供給する。
再送用バッファ85は、パケタイザ84から供給されたパケットを再送パケットとして一時的に記憶し、NACK処理部86の制御に基づいて、記憶されている再送パケットを通信部49に供給する。
通信部49は各種のデータを送信する送信部101、および各種のデータを受信する受信部102を備えており、通信網23を介してデータの送受信を行う。通信部49の送信部101は、パケタイザ84から供給されたパケットを送信パケットとして、通信網23を介して、クライアント24に送信する。通信部49の送信部101は、再送用バッファ85から供給された再送パケットを、通信網23を介して、クライアント24に送信する。
さらに、通信部49の受信部102は、通信網23を介して、クライアント24から送信されてきた各種パケットを受信し、受信したパケットを制御部81またはNACK処理部86に供給する。
NACK処理部86は、通信部49が受信し、通信部49から供給されたRTT計測パケット、確認応答信号、再送要求および最終再送要求の処理を行う。受信された各種パケットに対応する処理の詳細は後述する。
タイマ87は、制御部81の制御のもと、エンコーダ82にエンコードする時間の間隔を管理するためのタイマ値を供給する。
図5は、クライアント24の機能の構成を示すブロック図である。
クライアント24は、制御部121、通信部122、RTP処理部123、バッファ124、デコーダ125、ACKモード設定部126、タイマ127、RTT計測部128、RTT保持部129、RTC(Real Time Clock)130、タイマ131、およびNACK処理部132を含む。
制御部121は、クライアントプログラムを実行するクライアント24のCPU41によって実現され、クライアント24全体を制御する。
通信部122は、クライアント24の通信部49に対応し、データの受信を制御する受信部151および、データの送信を制御する送信部152を備えている。受信部151は、通信網23を介して送信されてきた各種データを受信する。送信部152は、通信網23を介して、各種のデータを送信する。通信部122は、受信したパケットをRTP処理部123またはRTT計測部128に供給する。
RTP処理部123は、通信部122が受信し、通信部122から供給された送信パケット181または再送パケット182であるRTPパケットを検査する。RTP処理部123は、正常なRTPパケットが受信された場合、RTPパケットをバッファ124に供給する。RTP処理部123は、正常なRTPパケットが受信されなかった場合、NACK処理部132に再送要求を指示する。例えば、RTP処理部123は、正常なRTPパケットが受信されなかった場合、RTPパケットのヘッダ情報をNACK処理部132に供給すると共に、NACK処理部132に再送要求を指示する。
バッファ124は、RTP処理部123から供給されたRTPパケットを一時的に記憶する。
デコーダ125は、バッファ124に記憶されているRTPパケットを順に取得して、取得したRTPパケットから画像データを抽出する。そして、デコーダ125は、エンコーダ82に対応する復号方式で、抽出された画像データをデコード(復号)して、デコードされた画像データを出力装置25に出力する。デコーダ125は、デコードされた画像データを格納していたRTPパケットのヘッダ情報をACKモード設定部126に供給する。
なお、RTP処理部123は、RTPパケットから画像データを抽出して、抽出した画像データをバッファ124に供給するようにしてもよい。この場合、RTP処理部123は、通信部122から供給されたRTPパケットのヘッダ情報を抽出して、抽出したヘッダ情報をバッファ124に供給する。バッファ124は、画像データおよびヘッダ情報を対応させて、それぞれに記憶する。デコーダ125は、画像データを復号する場合、バッファ124から対応するヘッダ情報を読み出して、読み出したACKモード設定部126に供給する。
ACKモード設定部126は、デコーダ125から供給されたヘッダ情報をNACK処理部132に供給する。
タイマ127は、制御部121の制御のもと、デコーダ125に、デコードする間隔を示すタイマ値を供給する。
RTT計測部128は、RTC130から現在時刻を取得し、RTT計測パケット172を生成する。RTT計測部128は、生成されたRTT計測パケット172を通信部122に供給する。通信部122は供給されたRTT計測パケット172を通信網23を介してサーバ22に送信する。
また、RTT計測部128は、通信部122が受信し、通信部122から供給されたRTT計測パケット172を取得する。RTT計測部128は、RTT計測パケット172を取得した場合、RTC130から現在時刻を取得し、往復遅延時間を算出する。RTT計測部128は、算出した往復遅延時間をRTT保持部129に供給する。往復遅延時間の詳細は後述する。
RTT保持部129は、RTT計測部128から供給された往復遅延時間をNACK処理部132に供給し、供給された往復遅延時間を一時的に記憶する。RTT保持部は、記憶している往復遅延時間をNACK処理部132に供給する。
RTC130は、現在時刻をRTT計測部128に供給する。
タイマ131は、制御部121の制御のもと、RTT計測部128にRTT計測パケット172を生成する間隔を示すタイマ値を供給する。
NACK処理部132は、RTP処理部123から供給された信号をもとに、正常にRTPパケットを受信できなかったか、すなわち、パケットロスが発生したか否かを判定する。パケットロスが発生したと判定された場合、NACK処理部132は、パケットロスが発生した送信パケット181の再送を要求する再送要求としてのNACKパケットを生成し、生成したNACKパケットを通信部122に供給する。
NACK処理部132は、RTT保持部129から供給された往復遅延時間、およびACKモード設定部126から供給されたヘッダ情報をもとに最終処理期限のフレームを計算する。最終処理期限のフレームの中にロスパケットがある場合には、NACK処理部132は、再送を要求するロスパケットの最終再送要求としてのNACKパケットを生成し、生成したNACKパケットを通信部122に供給する。
また、NACK処理部132は、ACKモード設定部126から供給されたヘッダ情報をもとに、ACKモードであるか否かを判定し、ACKモードであると判定された場合には、確認応答信号を生成し、通信部122に供給する。
ここで、ACKモードとは、クライアント24がデコードし終わったフレームの最後のシーケンス番号をサーバ22に通知するモードである。例えば、ACKモードは、使用者の操作に対応した入力部46からの信号を基に、設定されるか解除される。
NACK処理部132によって実行される各種パケットの処理の詳細は後述する。
なお、図4または図5で示されるサーバ22またはクライアント24の機能は、ハードウェアにより実現するようにしてもよく、ソフトウェア(プログラム)により実現するようにしてもよい。
次に、図6のタイムチャートを参照して、サーバ22における再送要求および最終再送要求の処理を説明する。
図6における横方向は、時間を示す。図6において、フレーム171−1を再生するための画像データであるストリーミングデータは、送信パケット181−1乃至送信パケット181−3に格納されて送信され、フレーム171−2を再生するための画像データであるストリーミングデータは、送信パケット181−4乃至送信パケット181−6に格納されて送信され、フレーム171−3を再生するための画像データであるストリーミングデータは、送信パケット181−7乃至送信パケット181−9に格納されて送信される。
図6において、時刻t150から時刻t151までのT11−1、および時刻t151から時刻t152までのT11−2は、それぞれフレーム171−1、およびフレーム171−2のそれぞれの再生時間である。
時刻t80において、サーバ22は、通信網23を介して、クライアント24あてに送信パケット181−1を送信するとともに、再送パケット182−1を再送用バッファ85に格納する。クライアント24は、通信網23を介して、サーバ22から送信されてきた送信パケット181−1を時刻t120に受信する。同様に、時刻t81および時刻t82のそれぞれにおいて、サーバ22は、通信網23を介して、クライアント24あてに送信パケット181−2および181−3をそれぞれ送信するとともに、再送パケット182−2および182−3を再送用バッファ85に格納する。
さらに、サーバ22は、通信網23を介して、クライアント24あてに送信パケット181−4乃至送信パケット181−9を送信するとともに、再送パケット182−4乃至再送パケット182−9を再送用バッファ85に格納する。また、クライアント24は、通信網23を介して、サーバ22から送信されてきた送信パケット181−2乃至送信パケット181−9を受信する。
ここで、再送パケット182−1乃至再送パケット182−9のそれぞれには、送信パケット181―1乃至送信パケット181−9のそれぞれに含まれるストリーミングデータが格納されている。換言すれば、再送パケット182−1には、送信パケット181−1に含まれるストリーミングデータが格納され、再送パケット182−2には、送信パケット181−2に含まれるストリーミングデータが格納され、同様に、再送パケット182−3乃至再送パケット182−9のそれぞれには順に対応する送信パケット181−3乃至送信パケット181−9のそれぞれに含まれるストリーミングデータが格納される。
以下、送信パケット181−1乃至送信パケット181−9を個々に区別する必要がないとき、単に送信パケット181と称する。同様に、以下、再送パケット182−1乃至再送パケット182−9を個々に区別する必要がないとき、単に再送パケット182と称する。
時刻t121において、クライアント24は、通信網23における往復遅延時間を計測するため、通信網23を介して、RTT計測パケット172をサーバ22あてに送信する。クライアント24から送信されてきたRTT計測パケット172を、時刻t83において受信したサーバ22は、通信網23を介して、クライアント24あてにRTT計測パケット172を返送する。サーバ22から送信されてきたRTT計測パケット172を、時刻t122において受信したクライアント24は、RTT計測パケット172を受信した時刻t122から送信された時刻t121を引き算することにより往復遅延時間T12を算出する。クライアント24は、算出された往復遅延時間T12に基づき、サーバ22に、ロスパケットの再送を要求するか否かを判定する。
時刻t123において送信パケット181−5のパケットロスを検知したクライアント24は、時刻t123に再送を要求した場合、時刻t123に往復遅延時間T12を加算して求められる時刻t125における再送パケット182−5の受信が、フレーム171−2の再生開始時刻t151に間に合うと判定し、通信網23を介して、サーバ22あてに再送を要求する。
同様にクライアント24は、時刻t124に検知した送信パケット181−6のロスパケットについても、時刻t124において再送を要求した場合、時刻t124に往復遅延時間T12を加算して求められる時刻t126における再送パケット182−6の受信が、フレーム171−2の再生開始時刻t151に間に合うと判定し、通信網23を介して、サーバ22あてに再送を要求する。
時刻t126において、クライアント24は、サーバ22から再送されてきた再送パケット182−5のパケットロスを検知する。時刻t127に再送パケット182−5が最終処理期限となったので、クライアント24は、最終再送要求としてのNACKパケットを、通信網23を介して、サーバ22あてに送信する。最終処理期限については、後述する。再送パケット182−5の最終再送要求としてのNACKパケットを時刻t84において受信したサーバ22は、通信網23を介して、要求された再送パケット182−5をクライアント24あてに再送するとともに、再送用バッファ85に格納されている、以後の処理においてクライアント24に送信されることのない再送パケット182−1乃至再送パケット182−5を消去する。
以上のようにして、サーバ22は再送要求および最終再送要求を示すNACKパケットの処理するとともに必要のなくなった再送用パケット182を再送用バッファ85から消去する。
図7のフローチャートを参照して、サーバプログラムを実行するサーバ22によるストリーミングデータの送信処理を説明する。
ステップS1において、制御部81は、送信の処理に必要なデータを初期化する。例えば、ステップS1において、制御部81は、パケタイザ84に、シーケンス番号およびタイムスタンプを初期化させ、タイマ87のタイマの値を0msにセットする。
ステップS2において、制御部81は、タイマ87の値を基に、タイマ87が終了したか否かを判定し、タイマ87が終了していない場合、ステップS2に戻り、タイマ87が終了したと判定されるまで、判定の処理を繰り返す。
ステップS2において、タイマ87が終了したと判定された場合、処理は、ステップS3に進む。
例えば、画像データのフレームの数が1秒当たり30である場合、タイマ87が時間の経過に対応して値を増加させるとき、ステップS2において、制御部81は、33msなどの所定の値とタイマ87の値を比較することによりタイマ87が終了したか否かを判定する。
例えば、ステップS1において、タイマ87の値を33msにセットし、タイマ87の値が時間の経過に対応して減少するとき、制御部81は、タイマ87の値と、0msとを比較することによりタイマ87が終了したか否かを判定する。
この場合における、タイマ87の値と比較される0msまたは33msは、フレームの数が1秒当たり30である場合の例であり、本発明を限定するものではない。
以下に説明するタイマに関する処理において、同様である。
ステップS3において、制御部81は、エンコーダ82に、カメラ21から供給された画像データを1フレーム分キャプチャさせる。例えば、ステップS3において、エンコーダ82は、カメラ21から供給された画像データを順次取得して、取得した画像データのうち、1フレーム分をキャプチャする。
ステップS4において、制御部81は、エンコーダ82に、キャプチャされた画像データをエンコードさせる。例えば、ステップS4において、制御部81は、エンコーダ82に、キャプチャされた画像データをMPEG1,2,4,7、若しくは21、JPEG(Joint Photographic Experts Group)、JPEG2000、またはモーションJPEGなどの方式によりエンコードさせる。
ステップS5において、エンコーダ82は、エンコードされた画像データをバッファ83に供給して、バッファ83にエンコードされた画像データを格納(記憶)させる。
ステップS6において、制御部81は、パケタイザ84にデコードされた画像データを格納するRTPパケットを生成させる。RTPパケットは、送信パケット181の一例である。
図8はRTPパケットを説明する図である。RTPパケットの先頭には、図8において“V”で表される、2ビットのバージョン情報が配置される。バージョン情報は、RTPパケットのバージョンを示す。
バージョン情報の次に図8中の“P”で表される1ビットのパディングが配置され、パディングに続いて、1ビットの拡張情報がRTPパケット181に配置される。拡張情報は図8において、“X”で表される。拡張情報は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。
拡張情報に続いて、CSRC(Contributing Source)カウントがRTPパケットに配置される。CSRCカウントは、図8中において、“CC”で表される。CSRCカウントは、CSRC識別子の数を表す。
CSRCカウントに続いて配置される、1ビットのメーカー情報は、プロファイルによって定義される。メーカー情報は、図8中において“m”で表される。
メーカー情報に続いて配置される、7ビットのペイロードタイプは、RTPパケットのフォーマットを定義するための情報である。ペイロードタイプは、図8中において、“PT”で表される。RTPパケットにおいて、ペイロードタイプは、33とされる。
シーケンス番号は、ペイロードタイプの次に配置される、16ビットの情報である。シーケンス番号は、RTPパケットの再生の順番を示す番号であり、送信の度に、1ずつ増える。シーケンス番号は、パケットロスを検出し、RTPパケットの順序を修復するために使用される。
シーケンス番号の次に配置される、32ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。
SSRC(Synchronization Source)識別子は、タイムスタンプの次に配置される、32ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。
RTPパケットにおいて、SSRC識別子の次には、ストリーミングデータが格納される。図8において、“Original Data”は、ストリーミングデータを示す。
図7に戻り、ステップS7において、制御部81は、パケタイザ84に、生成されたRTPパケットを再送用バッファ85に供給させて、再送用バッファ85にRTPパケットを格納させる。
ステップS8において、制御部81は、パケタイザ84に、生成されたRTPパケットを通信部49に供給させ、通信部49に、通信網23を介して、RTPパケットをクライアント24あてに送信させる。
ステップS9において、パケタイザ84は、RTPパケットに付加するRTPタイムスタンプを更新する。
ステップS10において、制御部81は、タイマ87をセットし、ステップS2に戻り、上述した処理を繰り返す。例えば、ステップS10において、制御部81はタイマ87の値を0msにセットする。
以上の処理により、サーバ22は、通信網23を介して、例えば、画像であるストリーミングデータが格納されている送信パケット181をクライアント24あてに送信する。
次に、図9のフローチャートを参照して、クライアントプログラムを実行するクライアント24による応答の処理について説明する。
ステップS31において、制御部121は、デコードの処理に必要なデータを初期化する。例えば、ステップS31において、制御部121は、デコーダ125を500msの期間、待ち状態として待機させ、バッファ124が、所定の量の画像データを記憶するまで待たせる。制御部121は、デコーダ125を500msの期間、待機させることによってバッファ124に常時500ms分のストリーミングデータを格納させるようにする。
また、例えば、画像データのフレームの数が1秒当たり30である場合、ステップS31において、制御部121は、タイマ127の値を0msにセットし、33msなどの所定の値と比較することによりタイマ127が終了したか否かを判定する。
ステップS32において、制御部121は、タイマ127の値を基に、タイマ127が終了したか否かを判定し、タイマ127が終了していないと判定された場合、処理はステップS33に進む。
ステップS33において、制御部121は、RTP処理部123がRTPパケットを受信したか否かを判定し、RTPパケットを受信していないと判定された場合、処理はステップS32に戻り、判定の処理を繰り返す。
一方、ステップS33において、RTPパケットを受信したと判定された場合、ステップS34に進み、制御部121は、RTPパケットを正常に受信できなかったか否か、すなわち、パケットロスが発生したか否かを判定する。例えば、ステップS33において、制御部121は、RTP処理部123に受信したRTPパケットを検査させ、RTP処理部123から供給される検査の結果を示す信号を基に、パケットロスが発生したか否かを判定する。
ステップS34において、パケットロスが発生したと判定された場合、処理はステップS35に進み、制御部121は、NACK処理部132に、再送要求としてのNACKパケットを生成させ、生成させたNACKパケットを通信部122に供給させる。制御部121は、通信部122に、通信網23を介して、NACKパケットをサーバ22あてに送信させる。ステップS35の処理が終了すると、処理はステップS32に戻る。
図10は、再送要求としてのNACKパケットを説明する図である。バージョン情報、パディング、およびSSRC識別子は、図8で示されるRTPパケットの場合と同様であるので、その説明は省略する。
NACKパケットにおいて、パディングに続いて5ビットのサブタイプが配置される。
NACKパケットにおいて、ペイロードタイプは204とされる。ペイロードタイプの次に配置される、16ビットのメッセージ長は、NACKパケットの長さ(サイズ)を示す情報である。
32ビットのSSRC識別子に続いて、32ビットの名前が配置される。名前は、例えば、NACKパケットを取り扱うアプリケーションプログラムの名前である。
名前に続いて配置される32ビットの要求シーケンス番号は、パケットロスが発生したRTPパケット、すなわち、クライアント24によって再送が要求されるパケットを特定するシーケンス番号を示す。
一方、ステップS34において、パケットロスが発生していないと判定された場合、NACKパケットを送信する必要がないので、ステップS35の処理はスキップされ、手続きは、ステップS32に戻る。
ステップS32において、タイマ127が終了したと判定された場合、ステップS36に進み、制御部121は、デコーダ125にバッファ124からRTPパケットを1フレーム分取得させる。
ステップS37において、制御部121は、デコーダ125に、取得させたRTPパケットから画像データを抽出させ、抽出された画像データをデコードさせる。そして、制御部121は、デコーダ125に、デコードされた画像データを出力装置25に供給させる。
ステップS38において、制御部121は、デコーダ125に、デコードされた画像データを格納するRTPパケットのヘッダ情報をACKモード設定部126に供給させる。ACKモード設定部126は、デコードされた画像データを格納するRTPパケットのヘッダ情報を格納する。ACKモード設定部126は、RTPヘッダ情報をNACK処理部132に供給する。
なお、ACKモード設定部126は、使用者の操作に対応してクライアント24の入力部46から所定の信号が提供された場合、デコーダ125が復号する画像データが所定のビットレート以上である場合、またはサーバ22から指示された場合、ACKモードに設定する。ACKモード設定部126は、NACK処理部123を介して、ACKモードであるか否かを示す信号を制御部121に供給する。
スッテップS39において、制御部121は、ACKモード設定部126から供給された信号を基に、ACKモードであるか否かを判定する。
ステップS39において、ACKモードでないと判定された場合、手続きは、ステップS41に進み、ACKモードであると判定された場合、手続きは、ステップS40に進む。
ステップS40において、制御部121は、NACK処理部132に、ACKモード設定部126から供給されたヘッダ情報を基に、サーバ22に通知すべきシーケンス番号を含む確認応答信号を生成させ、通信部122に供給させる。制御部121は、通信部122に、通信網23を介して、応答確認信号をサーバ22あてに送信させる。
確認応答信号は、例えば、ACKパケットとすることができる。
図11は、ACKパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図10で示されるNACKパケットの場合と同様であるので、その説明は省略する。
ACKパケットにおいて、ペイロードタイプは206とされる。
ACKパケットにおいて、名前の次に配置されるシーケンス番号は、デコードが終了した画像データが格納されたRTPパケットに含まれるシーケンス番号である。
次に、ステップS41において、制御部121は、NACK処理部132に、最終処理期限のフレームを計算させる。最終処理期限のフレームとは、式(1)を満たすフレームのうち最も後に再生されるフレームの次に再生されるフレームを言う。
往復遅延時間>フレームの再生までの時間 ・・・(1)
ここで、往復遅延時間の値は、現時刻における、クライアント24が、サーバ22にロスパケットの再送を要求してから、クライアント24が再送されたパケットを受信するまでに必要とされる時間である。
最終処理期限のフレームは、再送要求をして、再送が間に合うフレームのうち、最も先に再生されるフレームであるとも言える。
往復遅延時間は、式(2)により算出される。
往復遅延時間=
(RTT計測パケットの受信時刻)−(RTT計測パケットの送信時刻)
・・・(2)
(RTT計測パケットの受信時刻)−(RTT計測パケットの送信時刻)
・・・(2)
ここで、RTT計測パケット172の受信時刻は、RTT計測部128が通信部122からRTT計測パケット172を供給されたときに、RTT計測部128がRTC130から取得した時刻(例えば、図6の時刻t122)である。また、RTT計測パケット172の送信時刻は、受信したRTT計測パケット172を相手に送信させるためのRTT計測パケット172を相手に宛てて送信した時刻(例えば、図6の時刻t121)である。
例えば、図6の時刻t127においては、RTT保持部129に保持されている往復遅延時間は、T12であり、式(1)を満たすフレームのうち最も後に再生されるフレームが、再生時間T11−1において再生されるフレーム171−1なので、最終処理期限のフレームは、フレーム171−2である。
図9のフローチャートの説明に戻り、ステップS42において、制御部121は、NACK処理部132に、バッファ124に格納されているRTPパケットを検査させ、その結果を示す信号を基に、算出された最終処理期限のフレームの中にロスパケットがあるか否かを判定する。
ステップS42において、ロスパケットがあると判定された場合は、ステップS43に進み、制御部121は、NACK処理部132に、最終処理期限にあるフレームのロスパケットの再送要求、すなわち最終再送要求としてのNACKパケットを生成させ、通信部122に供給させる。制御部121は、通信部122に、通信網23を介して、NACKパケットをサーバ22あてに送信させる。
最終再送要求は、例えば、図12で示されるNACKパケットである。
図12は、最終再送要求としてのNACKパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図10で示されるNACKパケットの場合と同様であるので、その説明は省略する。
最終再送要求を示すNACKパケットにおいて、ペイロードタイプは、207とされる。
名前の次に配置される要求シーケンス番号は、最終処理期限のフレームのロスパケットすなわち、クライアント24によって最終再送要求がなされるパケットを特定するシーケンス番号を示す。
図9に戻り、ステップS42において、最終処理期限のフレームの中にロスパケットがないと判定された場合、最終再送要求を行う必要がないので、ステップS43の処理はスキップされ、処理はステップS44に進む。ステップS44において、制御部121はタイマ127を更新して、処理は、ステップS32に戻り、上述した処理を繰り返す。
例えば、ステップS44において、制御部121は、タイマ127の値を0msにセットする。
以上のように、クライアント24は応答の処理として、サーバ22に、最終再送要求を行うか、または応答確認信号を送信する。
次に、図13のフローチャートを参照して、クライアントプログラムを実行するクライアント24によるRTT計測パケット172の送信処理について説明する。
ステップS61において、制御部121は、タイマ131の初期化を行う。例えば、ステップS61において、制御部121は、タイマ131の値を0sにセットし、10sなどの所定の値と比較することによりタイマ131が終了したか否かを判定する。
ステップS62において、制御部121は、RTT計測部128に、タイマ131の値を基に、タイマが終了したか否かを判定させる。
ステップS62において、タイマ131が終了したと判定された場合、処理はステップS63に進み、制御部121は、RTT計測部128に、RTC130から現在時刻を取得させる。
次に、ステップS64において、制御部121は、RTT計測部128に、RTT計測パケット172を生成させる。例えば、RTT計測部128は、図14で示されるRTT計測パケット172を生成する。
図14は、RTT計測パケット172を説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図10で示されるNACKパケットの場合と同様であるので、その説明は省略する。
RTT計測パケット172において、ペイロードタイプは205とされる。
RTT計測パケット172において、名前の次に配置される送信時刻は、サーバ22がクライアント24に、そのRTT計測パケット172を送信した時刻を示す。
図13のフローチャートに戻り、ステップS65において、制御部121は、RTT計測部128に、生成されたRTT計測パケット172を通信部122に供給させ、通信部122に、通信網23を介して、RTT計測パケット172をサーバ22あてに送信させる。
ステップS66において、制御部121はタイマ131の値をセットして、処理はステップS62に戻り、上述した処理を繰り返す。
例えば、ステップS66において、制御部121は、タイマ131の値を0sにセットする。
一方、ステップS62において、タイマ131が終了していないと判定された場合、ステップS67に進む。
ステップS67において、制御部121は、通信部122に、サーバ22から返送されてくるRTT計測パケット172を受信したか否かを判定させる。RTT計測パケット172を受信していないと判定された場合、処理はステップS62に戻る。
ステップS67において、RTT計測パケット172を受信したと判定された場合は、ステップS68に進み、制御部121は、通信部122に、受信されたRTT計測パケット172をRTT計測部128に供給させる。そして、制御部121は、RTT計測部128に、RTC130から現在時刻を取得させる。このときに取得された現在時刻が、RTT計測パケット172の受信時刻となる。
ステップS69において、制御部121は、RTT計測部128に、往復遅延時間を算出させる。例えば、ステップS69において、RTT計測部128は、往復遅延時間を、式(2)を基に算出する。
ステップS70において、制御部121は、RTT計測部128に、算出させた往復遅延時間をRTT保持部129に供給させる。RTT保持部129は、往復遅延時間を保持(記憶)する。ステップS70の処理の後、手続きは、ステップS62に戻り、上述した処理を繰り返す。
以上のようにして、クライアント24は、往復遅延時間を算出して、記憶することが出来る。
次に、図15のフローチャートを参照して、サーバプログラムを実行するサーバ22による再送パケット消去の処理について説明する。
ステップS91において、制御部81は、NACK処理部86から供給される信号を基に、NACKパケットを受信したか否かを判定する。例えば、ステップS91において、通信部49の受信部102は、NACKパケットを含む各種のパケットを受信し、受信したパケットをNACK処理部86に供給する。NACK処理部86は、受信部102から供給されたパケットのペイロードタイプの値に対応する信号を制御部81に供給する。制御部81は、受信されたパケットのペイロードタイプの値に対応する信号を基に、NACKパケットを受信したか否かを判定する。
ステップS91において、NACKパケットを受信したと判定された場合、処理はステップS92に進み、制御部81は、NACK処理部86に、再送要求のあったシーケンス番号の再送パケットを再送させる。例えば、NACK処理部86は、受信したNACKパケットから、要求シーケンス番号を抽出する。そして、NACK処理部86は、再送用バッファ85に、抽出されたシーケンス番号の値と同じ値のシーケンス番号を格納するRTPパケットを通信部49に供給させる。制御部81は、通信部49に、通信網23を介して、再送パケットであるRTPパケットをクライアント24あてに送信させる。
ステップS93において、制御部81は、受信したNACKパケットが最終処理期限のフレームのロスパケットを示すNACKパケットであるか否かを判定する。例えば、制御部81は、NACK処理部86から供給されたパケットのペイロードタイプの値に対応する信号を基に、ペイロードタイプの値と、207とを比較することにより、NACKパケットであるか否かを判定する。
ステップS93において、受信されたNACKパケットが、最終処理期限のフレームのロスパケットを示すNACKパケット、つまり最終再送要求としてのNACKパケットであると判定された場合は、処理はステップS94に進み、制御部81は、NACK処理部86に、再送を要求されたシーケンス番号以下のシーケンス番号を格納するRTPパケットを再送用バッファ85から消去させ、ステップS91に戻り、データ消去の処理を繰り返す。
例えば、図6の時刻t84において、最終再送要求としてのNACKパケットを受信したサーバ22は、時刻t84より後には、再送パケット182−1乃至再送パケット182−5の再送を要求されることはないので、サーバ22は、再送パケット182−5をクライアント24に送信するとともに、再送用バッファ85に格納されている再送パケット182−1乃至再送パケット182−5を消去する。
ステップS93において、受信されたNACKパケットが最終処理期限のフレームのロスパケットを示すNACKパケットではない、すなわち最終再送要求としてのNACKパケットではないと判定された場合、再送パケットを消去することはできないので、ステップS94の処理は、スキップされ、ステップS91に戻り、データ消去の処理を繰り返す。
次に、ステップS91において、NACKパケットを受信していないと判定された場合、ステップS95に進み、制御部81は、RTT計測パケット172を受信したか否かを判定する。ステップS96において、RTT計測パケット172を受信したと判定された場合、ステップS96に進み、制御部81は、NACK処理部86に、受信されたRTT計測パケット172をクライアント24に返送させ、処理はステップS91に戻り、データ消去の処理を繰り返す。
より詳細には、例えば、ステップS96において、NACK処理部86は、受信されたRTT計測パケット172のデータ部(ヘッダを除く部分)と同様のデータ部を有する新たなRTT計測パケット172を生成し、生成したRTT計測パケット172を通信部49に供給する。通信部49は、NACK処理部86から供給されたRTT計測パケット172を通信網23を介してクライアント24に送信する。
一方、ステップS95において、RTT計測パケット172を受信していないと判定された場合、ステップS97に進み、制御部81は、確認応答信号を受信したか否かを判定する。例えば、制御部81は、NACK処理部86から供給されたパケットのペイロードタイプの値に対応する信号を基に、ペイロードタイプの値と、206とを比較することにより、NACKパケットであるか否かを判定する。
ステップS97において、確認応答信号を受信したと判定された場合、ステップS98に進み、制御部81は、NACK処理部86に、受信された確認応答信号に含まれるシーケンス番号以下のシーケンス番号を格納するRTPパケット、すなわち、再生の終了したストリーミングデータが格納されたRTPパケットを再送用バッファ85から消去させ、ステップS91に戻り、上述した処理を繰り返す。
ステップS97において、応答確認信号を受信していないと判定された場合、RTPパケットを消去することはできないので、処理はステップS91に戻り、上述した処理を繰り返す。
以上のようにして、サーバ22は再送用バッファ85から不要になった再送パケットを消去する。
このように、サーバがクライアントから送信されたNACKパケットおよびACKパケットを受信することによって、再生が終了して不要になった再送パケットを再送用バッファから消去する。このことにより、サーバは、再送用バッファの記憶領域をより少なくすることができる。
なお、パケットに含まれるシーケンス番号をNACKパケットおよびACKパケットに格納し、シーケンス番号を基に、不要になった再送パケットを消去すると説明したが、シーケンス番号に限らず、再生の順番を示す再生順番情報や、タイムスタンプなどの時刻情報など他の情報を用いるようにしても良い。
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
この記録媒体は、図3に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク61(フレキシブルディスクを含む)、光ディスク62(CD-ROM(Compact Disc-Read Only Memory)、DVD(Digital Versatile Disc)を含む)、光磁気ディスク63(MD(Mini-Disc)(商標)を含む)、若しくは半導体メモリ64などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM42や、記録部48に含まれるハードディスクなどで構成される。
なお、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインタフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
また、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
22 サーバ, 23 通信網, 24 クライアント, 41 CPU, 42 ROM, 43 RAM, 48 記録部, 61 磁気ディスク, 62 光ディスク, 63 光磁気ディスク, 64 半導体メモリ, 81 制御部, 82 エンコーダ, 84 パケタイザ, 85 再送用バッファ, 86 NACK処理部, 101 送信部, 102 受信部, 121 制御部, 122 通信部, 123 RTP処理部, 125 デコーダ, 126 ACKモード設定部, 128 RTT計測部, 129 RTT保持部, 151 受信部, 152 送信部
Claims (7)
- 伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置において、
相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御手段と、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御手段と、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御手段と、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御手段と
を備えることを特徴とする送信装置。 - 前記受信制御手段は、前記相手から送信されてきた、前記ストリーミングデータの再生の終了を示す確認応答信号の受信をさらに制御し、
前記消去制御手段は前記確認応答信号が受信された場合、再生を終了した前記ストリーミングデータを格納する前記再送パケットの消去をさらに制御する
ことを特徴とする請求項1に記載の送信装置。 - 再生される順番を示す再生順番情報を含む前記送信パケットを生成する生成手段をさらに備え、
前記記憶制御手段は、前記送信パケットに対応する、前記再生順番情報を含む前記再送パケットの記憶を制御し、
前記消去制御手段は、前記再生順番情報を基に前記再送パケットの消去を制御する
ことを特徴とする請求項1に記載の送信装置。 - 生成された時刻を示す時刻情報を含む前記送信パケットを生成する生成手段をさらに備え、
前記記憶制御手段は、前記送信パケットに対応する、前記時刻情報を含む前記再送パケットの記憶を制御し、
前記消去制御手段は、前記時刻情報を基に前記再送パケットの消去を制御する
ことを特徴とする請求項1に記載の送信装置。 - 伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置の送信方法において、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御ステップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御ステップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御ステップと
を含むことを特徴とする送信方法。 - 伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理用のプログラムであって、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御テップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御テップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御テップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - 伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理をコンピュータに行わせるプログラムにおいて、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御テップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御テップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御テップと
を含むことを特徴とするプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003368417A JP2005136545A (ja) | 2003-10-29 | 2003-10-29 | 送信装置および方法、プログラム格納媒体、並びにプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003368417A JP2005136545A (ja) | 2003-10-29 | 2003-10-29 | 送信装置および方法、プログラム格納媒体、並びにプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005136545A true JP2005136545A (ja) | 2005-05-26 |
Family
ID=34646088
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003368417A Withdrawn JP2005136545A (ja) | 2003-10-29 | 2003-10-29 | 送信装置および方法、プログラム格納媒体、並びにプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005136545A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007088585A (ja) * | 2005-09-20 | 2007-04-05 | Tdk Corp | 撮影データ記録方法、撮影データ記録システム、及び撮影装置 |
JP2007124496A (ja) * | 2005-10-31 | 2007-05-17 | Sony Corp | 通信装置およびデータ削除方法 |
JP2008283421A (ja) * | 2007-05-10 | 2008-11-20 | Casio Hitachi Mobile Communications Co Ltd | 通信装置およびプログラム |
JP2014520443A (ja) * | 2011-06-07 | 2014-08-21 | ノルディック セミコンダクタ アーエスアー | 自動再送要求および選択的パケット大量再送が可能なストリーミング無線通信 |
JP2019146032A (ja) * | 2018-02-21 | 2019-08-29 | パナソニックIpマネジメント株式会社 | 無線通信システム |
-
2003
- 2003-10-29 JP JP2003368417A patent/JP2005136545A/ja not_active Withdrawn
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007088585A (ja) * | 2005-09-20 | 2007-04-05 | Tdk Corp | 撮影データ記録方法、撮影データ記録システム、及び撮影装置 |
JP4548285B2 (ja) * | 2005-09-20 | 2010-09-22 | Tdk株式会社 | 撮影データ記録方法、撮影データ記録システム、及び撮影装置 |
JP2007124496A (ja) * | 2005-10-31 | 2007-05-17 | Sony Corp | 通信装置およびデータ削除方法 |
JP2008283421A (ja) * | 2007-05-10 | 2008-11-20 | Casio Hitachi Mobile Communications Co Ltd | 通信装置およびプログラム |
JP2014520443A (ja) * | 2011-06-07 | 2014-08-21 | ノルディック セミコンダクタ アーエスアー | 自動再送要求および選択的パケット大量再送が可能なストリーミング無線通信 |
US9954655B2 (en) | 2011-06-07 | 2018-04-24 | Nordic Semiconductor Asa | Streamed radio communication with ARQ and selective retransmission of packets in bursts |
JP2019146032A (ja) * | 2018-02-21 | 2019-08-29 | パナソニックIpマネジメント株式会社 | 無線通信システム |
JP7117494B2 (ja) | 2018-02-21 | 2022-08-15 | パナソニックIpマネジメント株式会社 | 無線通信システム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106686438B (zh) | 一种跨设备的音频图像同步播放的方法、装置及系统 | |
KR100954253B1 (ko) | 데이터 전송 시스템, 동작 방법 및 디지털 미디어 캐리어 | |
KR100967377B1 (ko) | 데이터 통신 시스템, 데이터 송신 장치, 데이터 수신 장치, 데이터 통신 방법, 및 컴퓨터 프로그램을 기록한 매체 | |
JP4513725B2 (ja) | パケット送信装置、通信システム及びプログラム | |
US20020181506A1 (en) | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications | |
US9363480B2 (en) | Obtaining replay of audio during a conference session | |
JP4850932B2 (ja) | 画像伝送装置 | |
US8806048B2 (en) | Method and apparatus for transmitting and receiving streaming data based on real-time streaming protocol (RTSP) session | |
JP2004502359A (ja) | ビデオ誤り回復方法 | |
CN107819809B (zh) | 对内容进行同步操作的方法及装置 | |
JP2004007823A (ja) | データ伝送方法および装置 | |
JP2005151600A (ja) | データ伝送装置、データ伝送方法及びプログラム | |
JP4362761B2 (ja) | 送信装置および方法、記録媒体、並びにプログラム | |
JP4406816B2 (ja) | 受信装置および受信方法、記録媒体、並びにプログラム | |
JP2005322995A (ja) | リアルタイム映像転送におけるバッファ制御方法、送信端末、受信端末、映像配信システム、およびプログラム | |
US20020122434A1 (en) | Data transmitting apparatus and data receiving apparatus | |
JP2005051299A (ja) | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 | |
JP2005136545A (ja) | 送信装置および方法、プログラム格納媒体、並びにプログラム | |
JP2003179662A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
JP4367287B2 (ja) | 受信装置および方法、記録媒体、プログラム、並びに通信システム | |
JP4433281B2 (ja) | 受信装置および方法、記録媒体、並びにプログラム | |
JP2005136547A (ja) | 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム | |
JP4876427B2 (ja) | 通信システム、送信装置、送信方法、受信装置、受信方法、およびプログラム | |
JP4506222B2 (ja) | 通信システム、送信装置および方法、並びにプログラム | |
JP2003163691A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20070109 |