JP5522987B2 - 送信装置、送信方法、及びコンピュータプログラム - Google Patents

送信装置、送信方法、及びコンピュータプログラム Download PDF

Info

Publication number
JP5522987B2
JP5522987B2 JP2009157911A JP2009157911A JP5522987B2 JP 5522987 B2 JP5522987 B2 JP 5522987B2 JP 2009157911 A JP2009157911 A JP 2009157911A JP 2009157911 A JP2009157911 A JP 2009157911A JP 5522987 B2 JP5522987 B2 JP 5522987B2
Authority
JP
Japan
Prior art keywords
packet
transmission
time
packets
receiving device
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.)
Active
Application number
JP2009157911A
Other languages
English (en)
Other versions
JP2011015214A5 (ja
JP2011015214A (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 JP2009157911A priority Critical patent/JP5522987B2/ja
Publication of JP2011015214A publication Critical patent/JP2011015214A/ja
Publication of JP2011015214A5 publication Critical patent/JP2011015214A5/ja
Application granted granted Critical
Publication of JP5522987B2 publication Critical patent/JP5522987B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、受信装置に対してパケットを送信する送信装置に関する。
近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となる動画像データを、インターネット等の通信回線を通して送信することが一般に行われるようになっている。
このような動画像データの送信、特にライブ映像等のリアルタイム性を必要とする動画像データの長時間にわたる送信のために、RTPと呼ばれるプロトコルが一般的に用いられる。RTPは、A Transport Protocol for Real−Time Applicationsである。
また、RTPによる通信に代表されるリアルタイム通信においては、必ずしもデータの信頼性が高いとは言えないが、比較的単純に通信速度の改善が期待できるUDP/IP等の低層プロトコルが一般的に用いられる。
UDP/IP等のプロトコルを用いた通信においてパケットロスなどのエラーが発生した場合に、そのエラーを回復するための方法として、例えば、再送制御が知られている。再送制御では、受信装置が受信できなかったパケット(ロスパケット)の再送要求を送信装置に対して送信し、送信装置は、再送要求に対応するパケットを再送する。
また、パケットロス等のエラーの発生を抑制させる技術が特許文献1に開示されている。すなわち、特許文献1には、短い送信間隔でパケットが送信されないように、パケットの送信間隔を制御することが開示されている。
特開2002−77260号公報
しかしながら、パケットの送信間隔によっては、再生できないパケットが発生してしまう恐れがあった。
例えば、パケットの送信間隔を広げると、その分、受信装置がパケットロスを検知する時刻が遅くなる。従って、受信装置がロスしたパケットの再送要求を行っても、再送パケットが受信装置における再生時刻に間に合わないと、再送パケットを再生できない恐れがあった。
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、再生できないパケットを少なくすることである。
上記目的を達成するための一手段として、本発明の通信制御装置は以下の構成を備える。すなわち、信装置であって、受信装置にパケットを送信する送信手段と、前記送信装置と前記受信装置との間のパケットの往復時間を取得する取得手段と、前記受信装置において第1の映像フレームのパケットが正常に受信されなかった場合に再送される再送パケットが、前記受信装置における前記第1の映像フレームの再生間に合うように、前記往復時間に基づいて前記第1の映像フレームのパケットの送信期限を決定する決定手段と、 前記決定手段によって決定された送信期限までに、前記第1の映像フレームのパケットの送信を行うように前記送信手段を制御する制御手段とを有する。
本発明によれば、再生できないパケットを少なくすることができる。
実施形態の送信装置の構成を示す図である。 実施形態の送信装置におけるデータの流れを説明するための図である。 実施形態1におけるパケットの送信間隔の例を示す図である。 実施形態2の送信装置によるパケット送信に関する処理の流れを説明するためのフローチャートである。 実施形態2におけるパケットの送信間隔の例を示す図である。 実施形態1の送信装置によるパケット送信に関する処理の流れを説明するためのフローチャートである。
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
<実施形態1>
以下に、図面を参照しながら、本発明の第1の実施形態について説明する。尚、以下の実施形態では、送信装置が、通信機能を備えたネットワークカメラである場合を例に挙げて説明を行う。
図1は、送信装置のシステム構成の一例を示すブロック図である。図1において、ストリーム取得部101は、撮像部を備え、映像のストリームデータを取得する。尚、ストリームデータは、映像データに限らず、音声データやグラフィックデータなどのストリームデータであっても良い。
符号化部102は、ストリーム取得部101で取得されたストリームデータを符号化する。そして、パケット化部103は、符号化されたストリームデータを通信に適したサイズに分割してパケット化する。すなわち、パケット化部103は、受信装置に送信するパケットを生成する。パケット化部103によって生成されたパケットは、一旦、バッファメモリ108に保管される。
ストリーム情報取得部106は、ストリーム情報を取得する。また、通信情報取得部107は、通信情報を取得する。ストリーム情報と通信情報の詳細は、後述する。
スケジューリング部104は、ストリーム情報と通信情報とに基づいて、バッファメモリ108に保管されたパケットの送信タイミングを決定する。送信部105は、スケジューリング部104で決定された送信タイミングに従って、バッファメモリ108からパケットを読み出し、受信装置へ送信する。即ち、送信部105は、受信装置にパケットを送信する。
システムコントローラ110は、ストリームデータの取得からパケットを送信するまでの一連の処理において、図1に示したシステムの統括的な制御を行う。メインメモリ109は、システムコントローラ110が制御を行う上で必要に応じて記憶領域を提供する。
次に、本形態の送信装置の動作をデータの流れと共に図2を用いて説明する。図2の符号化部102は、ストリーム取得部101によって取得された映像ストリームデータを符号化し、パケット化部103に渡す。パケット化部103は、符号化された映像ストリームデータを分割してパケットを生成して、バッファメモリ108に渡すと共に、パケットを生成したことをシステムコントローラに通知する。また、スケジューリング部104は、通信情報取得部107から通信情報を取得すると共に、ストリーム情報取得部106からストリーム情報を取得する。そして、スケジューリング部104は、取得された通信情報、ストリーム情報を用いてフレームごとのパケットの送信期限を決定すると共に、その送信期限までにパケットが送信されるように、パケットの送信間隔を決定する。送信部105は、スケジューリング部104によって決定された送信間隔に基づいて、バッファメモリ108からパケットを読み出して、受信装置に送信する。
次に本形態の送信装置によるパケットの送信間隔の決定方法について、図3を用いて説明する。図3において、Iフレームは1つのフレーム内の情報で圧縮符号化処理されたフレームである。また、Pフレームは、時間軸上で前方のフレームの情報を用いて動き補償予測をして圧縮符号化処理されたフレームである。尚、所定数のフレームの集合を動画データの圧縮規格であるMPEG−2ではGOP(Group Of Picture)、MPEG−4ではGOV(Group Of Video Object Plane)と呼ぶが、本形態では、GOPと呼ぶ。MPEGは、Moving Picture Expert Groupの略である。
また、図3の「I」はIフレーム、「P」はPフレームを表している。図3に示すように、本形態では、1枚のIフレームとn枚のPフレームが1つのGOPに属している。ただし、GOPに、時間軸上で前のフレームと後のフレームを用いて動き補償予測をして圧縮符号化処理されたBフレームを含むようにしても良い。
図3(a)(b)(c)のうち、図3(c)は、本形態の送信装置により送信されるパケットの送信間隔の例を示す。また、図3(a)と(b)は、本形態の送信装置により送信されるパケットの送信間隔を説明するための送信間隔の比較例を示す。
図3(a)の「平準化無し」で示しているパケット送信間隔は、パケット送信間隔に関する制御を行っていない場合のパケットの送信間隔である。図3(a)からわかるように、一般に、Iフレームのパケット数は、Pフレームのパケット数よりも多い。
また、図3(b)の「GOP単位平準化」で示しているパケット送信間隔は、GOPごとにパケットの送信間隔を決定する例を示している。つまり、図3(b)では、同じGOPに属するパケットの送信間隔が同じ間隔になるように、パケットの送信間隔が決定される。このようにすることで、例えば、パケットを中継するルータ等においてバッファ溢れが発生することによるパケットのロスを少なくすることができる。しかしながら、図3(b)のように送信間隔を広げた場合、例えば、Iフレームに対応する複数のパケットのうちの最後のパケットがロスした場合、受信装置がそのパケットの再送要求をしても、その再送パケットが再生に間に合わない場合がある。これは、特に、GOPに属するIフレームのパケット数が非常に多く、Pフレームのパケット数が少ないときに起こり得る。これに対し、本形態のスケジューリング部104は、図3(c)の「再送可能期限内平準化」で示すような送信間隔でパケットが送信されるように送信スケジュールを決定する。図3(c)では、各フレームに、再送可能期限が設定されている。本形態のスケジューリング部104は、各パケットが、フレームごとに決定される再送可能期限までに送信されるように、送信タイミングを決定する。
ここで、再送可能期限は、再送パケットを正常に再生するための送信期限を示している。つまり、図3(c)のIフレームのパケットは、Iフレーム再送可能期限までに送信されているので、この中で受信装置が正常に受信しなかったパケットがあったとしても、再送要求することによって再送パケットに応じたコンテンツを再生することができる。一方、もしIフレームのパケットをIフレーム再送可能期限よりも後に送信し、そのパケットを受信装置が正常に受信できなかった場合、受信装置が再送要求しても、再送パケットがコンテンツの再生に間に合わない。この再送可能期限は、ストリーム情報、及び通信情報に基づいて、スケジューリング部104が決定する。尚、本形態では、再送要求を1回行う場合の再送可能期限について説明するが、同じパケットが2回以上ロスすることを想定して再送可能期限を決定することも可能である。
次に、スケジューリング部104による再送可能期限の決定方法について説明する。
まず、スケジューリング部104は、許容遅延時間を取得する。許容遅延時間は、ストリーム取得部101が映像のストリームデータを取得してから、そのストリームデータを受信装置が再生するまでの時間である。許容遅延時間は、予め設定されている。許容遅延時間は、各フレームに対し共通である。
また、スケジューリング部104は、取得した許容遅延時間と、各フレームのデータの取得時刻に基づいて、各フレームの再生時刻を特定する。そして、スケジューリング部104は、特定した各フレームの再生時刻と、受信装置が再送パケットを再生するために必要な時間に基づいて、各フレームのパケットの再送可能期限を決定する。
再送パケットを受信装置で再生するためには、以下に示す時間が必要になる。まず、送信装置によって送信されたパケットが受信装置に到着するまでに要する時間(下り通信時間)と、受信装置によるパケットロスの検知処理と再送要求パケットの生成、送信処理に要する時間(再送要求時間)が必要になる。さらに、受信装置によって送信された再送要求パケットが送信装置に到着するまでに要する時間(上り通信時間)と、送信装置による再送パケットの送信処理に要する時間(再送処理時間)が必要になる。さらに、送信装置によって送信された再送パケットが受信装置に到着するまでにかかる時間(下り通信時間)、受信装置による再送パケットの復号処理に要する時間(復号処理時間)が必要になる。
本形態のスケジューリング部104は、各フレームの再生時刻よりも、各処理時間(再送要求時間、再送処理時間、復号処理時間)と通信時間(上り通信時間と2回分の下り通信時間)の合計分だけ前の時刻になるように、送信期限(再送可能期限)を決定する。
つまり、スケジューリング部104は、ストリームデータの取得からパケットが生成されるまでの時間と、上記の各処理時間と通信時間(上り通信時間と2回分の下り通信時間)の合計を、許容遅延時間から差し引くことによって、最大遅延時間を決定する。最大遅延時間は、生成したパケットを送信せずにバッファメモリ108に蓄えておくことができる時間の上限値である。従って、本形態において、パケットをバッファメモリ108に記憶させてから最大遅延時間が経過するまでにパケットを送信することと、再送可能期限までにパケットを送信することは、同じことを意味している。
尚、上記の処理時間のうち、他の処理時間、通信時間と比べて十分に小さいと予測される場合は、その時間を無視して再送可能期限を決定するようにしても良い。また、上り通信時間と下り通信時間の違いが大きくないと予測される場合は、どちらか一方だけを取得し、その結果を他方に用いるようにしても良い。
スケジューリング部104は、下り通信時間を、通信情報取得部107から通知される通信情報に基づいて決定する。すなわち、通信情報取得部107は、これまでに送信した各パケットが受信装置によって受信されるまでにかかった下り通信時間を、通信情報としてスケジューリング部104に通知する。本形態では、下り通信時間の情報は、受信装置からの通知パケット(例えばレシーバーレポート)に含まれている。そして、スケジューリング部104は、通信情報取得部107から通知された下り通信時間に基づいて、現在の下り通信時間を決定する。すなわち、本形態のスケジューリング部104は、徐々に下り通信時間が長くなっている状況であると判断した場合は、通知された下り通信時間よりも長い時間を現在の下り通信時間として決定する。また、スケジューリング部104は、下り通信時間が時間的に激しく変動している状況であると判断される場合は、その中で最も長い下り通信時間を下り通信時間として決定する。このようにすることで、よりネットワークの状態に応じたくだり通信時間を決定することができる。ただし、通信情報取得部107から通知された下り通信時間を、現在の下り通信時間としても良い。
また、スケジューリング部104は、上り通信時間を、通信情報取得部107から通知される通信情報に基づいて決定する。すなわち、通信情報取得部107は、受信装置からの通知パケット(例えばレシーバーレポート)を受信すると、通知パケットの送信時刻と受信時刻に基づいて上り通信時間を算出し、通信情報としてスケジューリング部104に通知する。尚、通知パケットの送信時刻は、通知パケットに含まれている。そして、スケジューリング部104は、通知された上り通信時間に基づいて、現在の上り通信時間を決定する。例えば、スケジューリング部104は、徐々に上り通信時間が長くなっている状況であると判断した場合は、通信情報取得部107から通知された上り通信時間よりも長い時間(例えば、通知された上り通信時間の1割増)を現在の上り通信時間として決定する。ただし、通信情報取得部107から通知された上り通信時間を、現在の上り通信時間としても良い。
即ち、スケジューリング部104は、送信装置がパケットを送信してから該パケットを受信手段が受信するまでの下り通信時間(第1の時間)と、受信装置がパケットを送信してから該パケットを送信装置が受信するまでの上り通信時間(第2の時間)を取得する。そして、スケジューリング部104は、取得した上り通信時間と下り通信時間に基づいて往復時間を取得する。ただし、上り通信時間と下り通信時間の違いが小さいと予測される場合は、いずれかの通信時間から往復時間を求めても良い。
また、スケジューリング部104は、再送要求時間を、再送要求パケットの受信時刻と再送要求されたロスパケットの送信時刻に基づいて決定する。すなわち、スケジューリング部104は、パケットの送信時刻と、該パケットの再送要求パケットの受信時刻の時間差から、上り通信時間と下り通信時間の合計を差し引いた時間を、再送要求時間とする。
また、スケジューリング部104は、再送処理時間を、過去の再送処理時間に基づいて決定する。すなわち、スケジューリング部104は、これまでに再送パケットを生成するために要した時間を、再送処理時間として決定する。上述のように、再送処理時間は、再送要求パケットを受信してから再送パケットを送信するまでにかかる時間を示している。即ち、スケジューリング部104は、一のパケットの再送要求を受信してから、該一のパケットの再送パケットを送信するまでにかかる処理時間(再送処理時間)を取得する。
また、スケジューリング部104は、復号処理時間を、過去の復号処理時間に基づいて決定する。すなわち、通信情報取得部107は、受信装置におけるこれまでのパケットの復号処理に要した時間をスケジューリング部104に通知する。この復号時間の情報は、受信装置からの通知パケットに含まれている。そして、スケジューリング部104は、通知された過去の復号処理時間を現在の復号処理時間として決定する。
スケジューリング部104は、上記のようにして決定した各処理時間と通信時間に基づいてフレームごとに、パケットの送信期限(再送可能期限)を決定する。そして、スケジューリング部104は、各パケットを再送可能期限までに送信するようにパケットの送信タイミングを決定する。
尚、上り通信時間と下り通信時間と再送要求時間を、パケットの送信時刻と、該パケットの再送要求パケットの受信時刻の時間差に基づいて取得しても良い。このようにすれば、上り通信時間と下り通信時間の差が大きくない場合に、より容易に通信時間と処理時間を取得することができる。
次に、本形態のスケジューリング部104によるパケットの送信タイミングの決定方法について説明する。本形態のスケジューリング部104は、フレームごとに決定した送信期限(再送可能期限)までに、該フレームのパケットがすべて送信されるように、各パケットの送信間隔を決定する。すなわち、ストリーム情報取得部106は、ストリーム情報として、各フレームのデータサイズを取得し、スケジューリング部104に通知する。そして、スケジューリング部104は、通知されたフレームのデータサイズSfrmとパケットのペイロードサイズPfrmに基づいて1フレームのパケット数を算出する。そして、スケジューリング部104は、前述の最大遅延時間Tfrmを、算出したパケット数で割ることでパケットの送信間隔ΔTを決定する。
ΔT=Tfrm/(Sfrm/Pfrm)
スケジューリング部104は、算出した送信間隔ΔTでパケットを送信させるための送信指示を送信部105に対して行う。これにより、スケジューリング部104により決定された送信間隔でパケットが受信装置に送信される。
次に、本形態の送信装置のスケジューリング部104による処理について、図6のフローチャートを用いて説明する。
ステップS601(取得手順)において、スケジューリング部104は、通信情報とストリーム情報を取得する。本形態では、通信情報として、上り通信時間と下り通信時間、ストリーム情報として、送信するフレームのデータサイズを取得する。即ち、スケジューリング部104は、送信装置と受信装置との間のパケットの往復時間を取得する。また、スケジューリング部104は、過去の処理時間に基づいて、再送要求時間、再送処理時間、復号処理時間を決定する。
ステップS602(決定手順)において、スケジューリング部104は、ステップS601で取得した各処理時間と通信時間に基づいて、送信期限(再送可能期限)を決定する。上述のように、再送可能期限は、それまでに送信されたパケットを受信装置が正常に受信しなかったとしても、再送要求によって再送された再送パケットを正常に再生できる期限である。即ち、スケジューリング部104は、一のパケットに応じたコンテンツの再生時刻に、受信装置において一のパケットの再送パケットに応じた再生が間に合うように、往復時間に基づいて一のパケットの送信期限を決定する。
ステップS603(制御手順)において、スケジューリング部104は、ステップS602で決定された送信期限までに1フレーム分のパケットが送信されるように、送信間隔を決定する。本形態のスケジューリング部104は、1フレーム分のパケットの送信間隔が一定になるように送信間隔を決定する。そして、スケジューリング部104は、決定した送信間隔でパケットが送信されるように、送信部105を制御する。即ち、スケジューリング部104は、ステップS602で決定された送信期限までに、一のパケットの送信を行うように送信部105を制御する。
尚、スケジューリング部104は、受信装置からの再送要求パケットの受信に応じて、送信間隔を変更する。すなわち、再送要求パケットの受信に応じて、対応するパケットを再送すると、送信中のフレームのパケットのうちの一部が、再送可能期限よりも後に送信されてしまう可能性がある。そこで、スケジューリング部104は、再送パケットの送信時に送信しているフレームのすべてのパケットが、再送可能期限までに送信されるように、パケットの送信間隔を変更する。
ステップS604において、スケジューリング部104は、映像データの送信処理を終了するか否かを判定する。映像データの送信処理を終了すると判定される場合として、例えば、受信装置から映像の再生を終了することを示す通知を受けた場合などがある。映像データの送信処理を終了しないと判定された場合は、ステップS601に戻って次のフレームの送信処理を実行する。一方、映像データの送信処理を終了すると判定された場合は図6の処理を終了する。
以上のように本実施形態のスケジューリング部104は、ストリーム情報と通信情報に基づいて、ロスしたパケットの再送パケットが受信装置において正常に再生(表示)できるような送信期限を決定する。そして、スケジューリング部104は、決定した送信期限までにパケットが送信されるように送信部105を制御する。
これにより、パケットの送信間隔を広がると共に、受信装置が正常に受信しなかったパケットを再送制御によって回復させることができるので、再生できないパケットを少なくすることができる。
尚、MPEG−2やMPEG−4だけでなく、MPEG−4 AVC(H.264)やMotionJPEG等、同様の符号化方式やフレーム構成を持つものについても、本発明を適用することが可能である。
また、本実施形態では、ストリーム情報として、フレームごとのデータサイズを取得する例について説明したが、受信装置のバッファ容量などに応じて、例えば、GOPごとなどのデータサイズを取得するようにしても良い。
<実施形態2>
次に、第2の実施形態について実施形態1との差異を中心に説明する。実施形態1では、パケットの送信期限として、再送可能期限を用いていた。本形態では、再送可能期限と共に復号可能期限を求め、ネットワークの状況に応じて、復号可能期限までにパケットが送信されるように送信間隔を決定する。
尚、再送可能期限までの期間(再送可能期間)に送信されたパケットは、それがもしロスしても、再送パケットが再生に間に合う。また、再送可能期限から復号可能期限までの期間(復号可能期間)に送信されたパケットは、受信装置における再生には間に合うが、もしロスすると再送パケットが受信装置におけるコンテンツの再生に間に合わない。即ち、スケジューリング部104は、一のパケットの再送パケットが再生時刻に再生されるための再送可能期限(第1の送信期限)と共に、一のパケットが再生時刻に再生されるための復号可能期限(第2の送信期限)を決定する。
本形態の送信装置によるパケットの送信間隔について図5を用いて説明する。図5の(a)及び(b)は、実施形態1で図3を用いて説明したので、説明を省略する。図5の(c)「復号可能期間を含めた平準化」では、Iフレームのパケットが、Iフレームの再送可能期間と共に、Iフレームの復号可能期間においても送信される。このように、本形態のスケジューリング部104は、ネットワークの状況に応じて、再送可能期間だけでなく、復号可能期間においてもパケットを送信させる。
本形態のスケジューリング部104は、各フレームの送信開始時は、すべてのパケットが再送可能期間に送信されるようにパケットの送信間隔を決定するが、輻輳の発生を検知すると、一部のパケットが復号可能期間で送信されるように、送信間隔を変更する。つまり、輻輳が発生していないときは、ロスしたパケットが確実に再送制御できるように再送可能期間で送信し、輻輳が発生したときは、パケットの送信間隔をより広げることで、パケットロスしにくくする。尚、輻輳の発生は、受信装置からの通知パケット(レシーバーレポート)に基づいて判定する。
即ち、スケジューリング部104は、受信装置からの通知パケット(受信情報)に基づいて、送信済みのパケットのエラー状況を判定する。そして、スケジューリング部104は、エラー状況に応じて、一のパケットを再送可能期限(第1の送信期限)までに送信するか、復号可能期限(第2の送信期限)までに送信するか決定する。
尚、再送可能期限の決定方法は、実施形態1で説明した通りである。すなわち、スケジューリング部104は、再送制御する場合に必要な各処理に要する時間と通信時間の合計と、受信装置における各フレームの再生時刻に基づいて、各フレームの再送可能期限を決定する。尚、再送制御する場合に必要な各処理に要する時間は、再送要求時間、再送処理時間、復号処理時間であり、通信時間は、上り通信時間と、2回分の下り通信時間である。また、各フレームの再生時刻は、各フレームのデータの取得時刻と許容遅延時間から特定される。
また、本形態のスケジューリング部104は、復号可能期限を以下のように決定する。すなわち、スケジューリング部104は、再送制御しない場合に必要な各処理(復号処理時間)と通信時間(下り通信時間)の合計と、各フレームの再生時刻に基づいて、各フレームの復号可能期限を決定する。
図4は、本形態の送信装置によるパケットの送信処理に関する処理手順を説明するためのフローチャートである。本形態では、送信装置のストリーム取得部101によって撮影されたライブ映像を受信装置に送信する場合の例について説明する。
ステップS401において、スケジューリング部104は、送信するフレームの2つのパケット送信間隔T1、T2を算出する。送信間隔T1は、再送可能期間内に送信されるパケットの送信間隔を示している。また、送信間隔T2は、復号可能期間に送信されるパケットの送信間隔を示している。本形態のスケジューリング部104は、各フレームの送信開始時は、すべてのパケットが再送可能期間内に送信されるようにパケットの送信間隔を決定する。従って、送信間隔T1は、再送可能期間をフレームのパケット数で割った値となる。また、送信間隔T2は、復号可能期間と同じ値となる。すなわち、送信間隔T2の初期値は、復号可能期限から再送可能期限を引いた値となる。パケットの送信間隔T1、T2を決定すると、ステップS402に進む。
ステップS402において、スケジューリング部104は、決定されたパケットの送信間隔で、パケットを送信させる。つまり、送信部105は、スケジューリング部104で決定された送信タイミングに従って、バッファメモリ108からパケットを読み出し、受信装置へ送信する。スケジューリング部104が1パケット、送信させると、ステップS403に進む。
ステップS403において、スケジューリング部104は、1フレーム分のパケットが送信完了したか否かを判定する。1フレーム分のパケットを送信完了したと判定した場合は、ステップS401に戻り、次のフレームの送信間隔T1、T2を決定する。1フレーム分のパケットを送信完了していないと判定されると、ステップS404に進む。
ステップS404において、スケジューリング部104は、受信装置からの通知パケット(レシーバーレポート)を受信したか否かを判定する。スケジューリング部104は、通知パケットを受信したと判定した場合はステップS405へ進む。一方、スケジューリング部104は、通知パケットを受信していないと判定した場合はステップS402に戻り、次のパケットを送信する。
ステップS405において、スケジューリング部104は、受信装置からの通知パケットに基づいて、輻輳が発生しているか否かを判定する。尚、通知パケット(レシーバーレポート)には、受信装置が正常に受信しなかったパケットのシーケンスナンバーや、通知パケットの送信時刻などの時間情報が含まれている。スケジューリング部104は、通知パケットの情報に基づいて、エラーレートやRTT(Round Trip Time)を算出する。
そして、スケジューリング部104は、算出したエラーレートが閾値よりも大きく、RTTがこれまでの通知パケットから算出されたRTTよりも閾値以上、長くなっている場合、輻輳が発生したと判定する。ただし、エラーレートとRTTのいずれか一方から輻輳を判断しても良い。
また、本形態では、エラーレートに基づいて輻輳の発生を判定する例について説明したが、輻輳の発生検知の方法は、これに限らない。例えば、レシーバーレポートに含まれるロスしたパケットのシーケンスナンバーに基づいて、受信装置が連続して受信に失敗したパケット数(バーストエラー数)を算出し、それに基づいて輻輳を判定することも可能である。
スケジューリング部104が輻輳が発生したと判定するとステップS406に進み、輻輳が発生してないと判定されるとステップS408に進む。
ステップS406において、スケジューリング部104は、送信間隔T1とT2を比較する。送信間隔T1がT2よりも小さい(送信間隔が狭い)と判定された場合はステップS407に進み、送信間隔T1がT2よりも小さくないと判定された場合はステップS409に進む。
ステップS407において、スケジューリング部104は、ステップS401で決定された送信間隔T1を大きくし、送信間隔T2を小さくするように、送信間隔T1、T2を変更する。ステップS407により、再送可能期間におけるパケットの送信間隔が長くなると共に、復号可能期間でもパケットが送信されるようになる。ステップS407で送信間隔T1、T2が変更されると、ステップS402に戻り、次のパケットが送信される。
即ち、スケジューリング部104は、ステップS405で、送信済みのパケットのうち受信装置が正常に受信しなかったパケット数が所定数以上であることに対応する第1のエラー状況であるか、所定数以上でないことに対応する第2のエラー状況であるか判定する。そして、スケジューリング部104は、第1のエラー状況であると判定された場合、一のパケットを復号可能期限(第2の送信期限)までに送信することを決定する。一方、第2のエラー状況であると判定された場合、一のパケットを再送可能期限(第1の送信期限)までに送信することを決定する。
尚、本形態では、エラーレートとRTTの変動量に応じて、送信間隔T1、T2の変化量を変動させる。このようにすることで、輻輳の深刻さに、より適した送信間隔でパケットを送信することができる。ただし、ステップS407における送信間隔T1、T2の変化量を一定にしても良い。
また、上述のように、バーストエラー数に基づいて輻輳の判断をしても良い。その場合、スケジューリング部104は、ステップS405で、送信済みのパケットのうち受信装置が連続して受信に失敗したパケット数(バーストエラー数)が所定数以上であるか否かを判定する。そして、スケジューリング部104は、連続して受信に失敗したパケット数が所定数以上であると判定された場合、一のパケットを復号可能期限(第2の送信期限)までに送信することを決定する。一方、連続して受信に失敗したパケット数が所定数以上でないと判定された場合、一のパケットを再生可能期限(第1の送信期限)までに送信することを決定する。
尚、ステップS405で輻輳が発生してないと判定された場合、スケジューリング部104は、ステップS408で、現在の送信レートが目標レート未満であるか否かを判定する。目標レートは、例えば、TFRC(TCP Friendly Rate Control)やAIMD(Additive Increase and Multiplicative Decrease)を用いて求める。現在の送信レートが目標レート未満であると判定された場合はステップS409に進み、目標レートに達していると判定された場合はステップS402に戻る。
ステップS409において、スケジューリング部104は、レート制御を行う。つまり、ステップS408で、現在の送信レートが目標レート以下であると判定された場合、送信する映像データの画質を上げる。このようにすると、フレーム当たりのパケット数が多くなり、送信間隔が短くなるが、より高画質の映像データを送信することができるようになる。
また、ステップS406で送信間隔T1がT2よりも小さくないと判定された場合、ステップS409において、スケジューリング部104は、映像データの画質を下げる。このようにすることで、フレーム当たりのパケット数が少なくなるので、輻輳の状態を緩和することができる。
また、スケジューリング部104は、再送要求パケットを受信すると、送信間隔T1、T2を変更する。すなわち、再送要求パケットの受信に応じて、パケットを再送すると、送信中のフレームのパケットのうちの一部が、復号可能期限よりも後に送信されてしまう可能性がある。そこで、スケジューリング部104は、再送パケットの送信時に送信しているフレームのすべてのパケットが、復号可能期限までに送信されるように、パケットの送信間隔を変更する。
以上説明したように、本形態の送信装置は、再送可能期限までの期間(再送可能期間)と、再送可能期限から復号可能期限までの期間(復号可能期間)を決定する。そして、ネットワークで輻輳が発生していない場合は、すべてのパケットを再送可能期間に送信する。そして、輻輳の発生を検知すると、パケットの一部を復号可能期限で送信されるようにする。
このようにすることで、ネットワークで輻輳が発生していないときはすべてのパケットが再送制御可能となり、輻輳が発生しているときはパケットの送信間隔を広げることにより、パケットロスを少なくすることができる。
<その他の実施形態>
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体(記憶媒体)等としての実施態様をとることが可能である。
また、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される。なお、この場合のプログラムとは、コンピュータ読取可能であり、実施形態において図に示したフローチャートに対応したプログラムである。

Claims (15)

  1. 信装置であって、
    受信装置にパケットを送信する送信手段と、
    前記送信装置と前記受信装置との間のパケットの往復時間を取得する取得手段と、
    前記受信装置において第1の映像フレームのパケットが正常に受信されなかった場合に再送される再送パケットが、前記受信装置における前記第1の映像フレームの再生間に合うように、前記往復時間に基づいて前記第1の映像フレームのパケットの送信期限を決定する決定手段と、
    前記決定手段によって決定された送信期限までに、前記第1の映像フレームのパケットの送信を行うように前記送信手段を制御する制御手段と
    を有することを特徴とする送信装置。
  2. 送信装置であって、
    受信装置にパケットを送信する送信手段と、
    前記送信装置と前記受信装置との間のパケットの往復時間を取得する取得手段と、
    前記受信装置からの受信情報に基づいて、送信済みパケットのエラー状況を判定する判定手段
    前記受信装置においてパケットが正常に受信されなかった場合に再送される再送パケットが、前記受信装置における前記パケットに対応するコンテンツの再生に間に合うための前記パケットの送信期限である第1の送信期限と、前記パケットが前記受信装置における前記コンテンツの再生に間に合うための前記パケットの送信期限である第2の送信期限とのうち、いずれの送信期限に基づいて前記パケットを送信するかを、前記エラー状況に応じて決定する決定手段と、
    前記決定手段により決定された送信期限に従って前記パケットの送信が行われるように前記送信手段を制御する制御手段とを有する
    ことを特徴とする送信装置。
  3. 前記判定手段は、前記受信情報に基づいて、送信済みのパケットのうち前記受信装置が正常に受信しなかったパケット数が所定数以上であることに対応する第1のエラー状況であるか、前記正常に受信しなかったパケット数が前記所定数以上でないことに対応する第2のエラー状況であるかを判定し、
    前記決定手段は、前記判定手段により前記第1のエラー状況であると判定された場合、前記パケットを前記第2の送信期限までに送信することを決定し、
    前記判定手段により前記第2のエラー状況であると判定された場合、前記パケットを前記第1の送信期限までに送信することを決定する
    ことを特徴とする請求項2記載の送信装置。
  4. 前記判定手段は、前記受信情報に基づいて、送信済みのパケットのうち前記受信装置が連続して受信に失敗したパケット数が所定数以上であるか否かを判定し、
    前記決定手段は、前記判定手段により前記連続して受信に失敗したパケット数が前記所定数以上であると判定された場合、前記パケットを前記第2の送信期限までに送信することを決定し、
    前記判定手段により前記連続して受信に失敗したパケット数が前記所定数以上でないと判定された場合、前記パケットを前記第1の送信期限までに送信することを決定することを特徴とする請求項2記載の送信装置。
  5. 前記決定手段は、前記エラー状況に応じて、動画データのフレームのうち、前記パケットを含む一のフレームに対応する複数のパケットを、前記第1の送信期限までに送信するか、前記第2の送信期限までに送信するか決定する
    ことを特徴とする請求項2記載の送信装置。
  6. 前記取得手段は、前記送信装置がパケットを送信してから当該パケットを前記受信装置が受信するまでの第1の時間と、前記受信装置がパケットを送信してから当該パケットを前記送信装置が受信するまでの第2の時間に基づいて前記往復時間を取得する
    ことを特徴とする請求項1記載の送信装置。
  7. 前記取得手段は、前記送信装置が再送要求を受信してから再送パケットを送信するまでにかかる処理時間を取得し、
    前記決定手段は、前記往復時間と前記処理時間に基づいて、前記第1の映像フレームのパケットの送信期限を決定する
    ことを特徴とする請求項1記載の送信装置。
  8. 前記制御手段は、前記第1の映像フレームのパケット数が多いほうが、前記パケット数が少ない場合よりもパケットの送信間隔が短くなるように、前記送信手段による前記第1の映像フレームのパケットの送信間隔を制御することを特徴とする請求項1に記載の送信装置。
  9. 受信装置にパケットを送信する送信装置が行う送信方法であって、
    前記送信装置と前記受信装置との間のパケットの往復時間を取得する取得工程と、
    前記受信装置において前記第1の映像フレームのパケットが正常に受信されなかった場合に再送される再送パケットが、前記受信装置における前記第1の映像フレームの再生に間に合うように、前記往復時間に基づいて前記第1の映像フレームのパケットの送信期限を決定する決定工程と、
    前記決定工程によって決定された送信期限までに、前記第1の映像フレームのパケットの送信を行うように制御する制御工程と
    を有することを特徴とする送信方法。
  10. 受信装置に対してパケットを送信する送信装置が行う送信方法であって、
    前記送信装置と前記受信装置との間のパケットの往復時間を取得する取得手段と、 前記受信装置からの受信情報に基づいて、送信済みパケットのエラー状況を判定する判定工程と、前記受信装置においてパケットが正常に受信されなかった場合に再送される再送パケットが、前記受信装置における前記パケットに対応するコンテンツの再生に間に合うための前記パケットの送信期限である第1の送信期限と、前記パケットが前記受信装置における前記コンテンツの再生に間に合うための前記パケットの送信期限である第2の送信期限とのうち、いずれの送信期限に基づいて前記パケットを送信するかを、前記エラー状況に応じて決定する決定工程と、
    前記決定工程により決定された送信期限に従って前記パケットの送信が行われるように制御する制御工程とを有する
    ことを特徴とする送信方法。
  11. 前記取得工程は、前記送信装置が再送要求を受信してから再送パケットを送信するまでにかかる処理時間を取得し、
    前記決定工程は、前記往復時間と前記処理時間に基づいて、前記第1の映像フレームのパケットの送信期限を決定する
    ことを特徴とする請求項9記載の送信方法。
  12. 前記制御工程は、前記第1の映像フレームに対応するパケット数が多いほうが、前記パケット数が少ない場合よりもパケットの送信間隔が短くなるように、前記送信手段による前記第1の映像フレームのパケットの送信間隔を制御することを特徴とする請求項9に記載の送信方法。
  13. 前記判定工程は、前記受信情報に基づいて、送信済みのパケットのうち前記受信装置が正常に受信しなかったパケット数が所定数以上であることに対応する第1のエラー状況であるか、前記正常に受信しなかったパケット数が前記所定数以上でないことに対応する第2のエラー状況であるかを判定し、
    前記決定工程は、前記判定工程により前記第1のエラー状況であると判定された場合、前記パケットを前記第2の送信期限までに送信することを決定し、
    前記判定工程により前記第2のエラー状況であると判定された場合、前記パケットを前記第1の送信期限までに送信することを決定する
    ことを特徴とする請求項10記載の送信方法。
  14. 前記判定工程は、前記受信情報に基づいて、送信済みのパケットのうち前記受信装置が連続して受信に失敗したパケット数が所定数以上であるか否かを判定し、
    前記決定工程は、前記判定工程により前記連続して受信に失敗したパケット数が前記所定数以上であると判定された場合、前記パケットを前記第2の送信期限までに送信することを決定し、
    前記判定工程により前記連続して受信に失敗したパケット数が前記所定数以上でないと判定された場合、前記パケットを前記第1の送信期限までに送信することを決定する
    ことを特徴とする請求項10記載の送信方法。
  15. コンピュータを、請求項1乃至8のうちいずれか1項に記載の送信装置として動作させるためのプログラム。
JP2009157911A 2009-07-02 2009-07-02 送信装置、送信方法、及びコンピュータプログラム Active JP5522987B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009157911A JP5522987B2 (ja) 2009-07-02 2009-07-02 送信装置、送信方法、及びコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009157911A JP5522987B2 (ja) 2009-07-02 2009-07-02 送信装置、送信方法、及びコンピュータプログラム

Publications (3)

Publication Number Publication Date
JP2011015214A JP2011015214A (ja) 2011-01-20
JP2011015214A5 JP2011015214A5 (ja) 2012-08-16
JP5522987B2 true JP5522987B2 (ja) 2014-06-18

Family

ID=43593646

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009157911A Active JP5522987B2 (ja) 2009-07-02 2009-07-02 送信装置、送信方法、及びコンピュータプログラム

Country Status (1)

Country Link
JP (1) JP5522987B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013123980A1 (en) 2012-02-21 2013-08-29 Telefonaktiebolaget L M Ericsson (Publ) Processing-time dependent control of data block transmission

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09191314A (ja) * 1996-01-10 1997-07-22 Mitsubishi Electric Corp 連続データ伝送方法および連続データ伝送装置
JP3912091B2 (ja) * 2001-12-04 2007-05-09 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP3927486B2 (ja) * 2002-11-29 2007-06-06 株式会社エヌ・ティ・ティ・ドコモ ストリーミング配信装置、ストリーミング配信システム、及びストリーミング配信方法
JP2004289711A (ja) * 2003-03-25 2004-10-14 Toshiba Corp 送信装置及び受信装置
JP2005051299A (ja) * 2003-07-29 2005-02-24 Toshiba Corp パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法
JP2005136547A (ja) * 2003-10-29 2005-05-26 Sony Corp 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム
JP2007086484A (ja) * 2005-09-22 2007-04-05 Brother Ind Ltd コンテンツ配信システム及びコンテンツ配信方法並びにそれに用いる配信装置、端末装置及びそのプログラム
JP2009071537A (ja) * 2007-09-12 2009-04-02 Toshiba Corp データ転送システム及びデータ転送方法

Also Published As

Publication number Publication date
JP2011015214A (ja) 2011-01-20

Similar Documents

Publication Publication Date Title
US11503307B2 (en) System and method for automatic encoder adjustment based on transport data
US9585062B2 (en) System and method for implementation of dynamic encoding rates for mobile devices
US9042444B2 (en) System and method for transmission of data signals over a wireless network
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
JP3598110B2 (ja) データ伝送方法および装置
US10033779B2 (en) Multipath data streaming over multiple wireless networks
US7320099B2 (en) Method and apparatus for generating error correction data, and a computer-readable recording medium recording an error correction data generating program thereon
AU2020201920B2 (en) Multipath data streaming over multiple wireless networks
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
JP4936542B2 (ja) 通信制御装置、通信制御方法、及びコンピュータプログラム
US8185792B2 (en) Data-transmission device data-reception device and data-transmission-and-reception system
JP5207895B2 (ja) 送信装置、受信装置、及び方法、プログラム
US8873590B2 (en) Apparatus and method for correcting jitter
US8811180B2 (en) Communication apparatus and communication method
AU2021200428B2 (en) System and method for automatic encoder adjustment based on transport data
JP2005322995A (ja) リアルタイム映像転送におけるバッファ制御方法、送信端末、受信端末、映像配信システム、およびプログラム
JP5522987B2 (ja) 送信装置、送信方法、及びコンピュータプログラム
JP2010041326A (ja) データ送信装置、データ受信装置及びデータ送受信システム
JP2005348015A (ja) リアルタイム・ストリーミングデータ受信装置
CA2528331A1 (en) Medium signal reception device, transmission device, and transmission/reception system
JP5523163B2 (ja) 送信装置、送信方法、プログラム
KR100782343B1 (ko) 영상 스트리밍 방법
WO2016203870A1 (ja) 送信装置、送信方法、及び通信システム
EP2337257A1 (en) Method and apparatus of sending encoded multimedia digital data taking into account sending deadlines
Bortoleto et al. Large-scale media delivery using a semi-reliable multicast protocol

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120629

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120629

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130703

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130820

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131021

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140408

R151 Written notification of patent or utility model registration

Ref document number: 5522987

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151