JP2005051299A - パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 - Google Patents
パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 Download PDFInfo
- Publication number
- JP2005051299A JP2005051299A JP2003202981A JP2003202981A JP2005051299A JP 2005051299 A JP2005051299 A JP 2005051299A JP 2003202981 A JP2003202981 A JP 2003202981A JP 2003202981 A JP2003202981 A JP 2003202981A JP 2005051299 A JP2005051299 A JP 2005051299A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- retransmission
- data
- time
- unit
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
【課題】誤りが混入する可能性のあるネットワークでマルチメディアコンテンツを効率よく伝送するパケット送信装置、パケット受信装置、パケット送信方法、パケット受信方法及びプログラムを提供することを目的とする。
【解決手段】再送要求受信部１０７が受信装置から再送要求を受信した場合、再送制御部１０９は、該要求に係るパケットの再送に関する重要度を、該パケットを再送したときに、該パケットのデータの受信装置での利用時刻に間に合うかどうかに照らし合わせて、該要求の重要度を決定する。該要求は重要度とともに再送要求キュー部１１０に蓄積される。再送制御部１０９は、再送すべきパケットが複数ある場合には重要度に基づいて再送すべきパケットを選択する。選択されたパケットは、再送パケット化部１１１で再送パケットにされ、再送パケットキュー部１１２を介して再送パケット送信部１１３から受信装置へ送信される。
【選択図】 図１
【解決手段】再送要求受信部１０７が受信装置から再送要求を受信した場合、再送制御部１０９は、該要求に係るパケットの再送に関する重要度を、該パケットを再送したときに、該パケットのデータの受信装置での利用時刻に間に合うかどうかに照らし合わせて、該要求の重要度を決定する。該要求は重要度とともに再送要求キュー部１１０に蓄積される。再送制御部１０９は、再送すべきパケットが複数ある場合には重要度に基づいて再送すべきパケットを選択する。選択されたパケットは、再送パケット化部１１１で再送パケットにされ、再送パケットキュー部１１２を介して再送パケット送信部１１３から受信装置へ送信される。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、符号化された動画像／静止画像に係るパケットをＩＳＤＮやインターネット等の有線通信網あるいは携帯電話や無線ＬＡＮ等の無線通信網を用いて送信するパケット送信装置、該パケットを受信するパケット受信装置、パケット送信方法及びパケット受信方法に関する。
【０００２】
【従来の技術】
近年、画像等の各種情報のデジタル符号化技術や広帯域ネットワーク技術の進展により、これらを利用したアプリケーションの開発が盛んになっており、圧縮符号化した画像等を通信網を利用して伝送するシステムが開発されている。
【０００３】
特に、インターネット・イントラネットの普及により、データをパケット化して送受信するアプリケーションやシステムが増加している。パケット化は通信路の帯域を効率良く複数のユーザで共有するのに有効な手段である。パケットデータを送受信するプロトコルとしてＴＣＰ／ＩＰやＵＤＰ／ＩＰなどが存在する。ＴＣＰ／ＩＰは再送などの枠組みが組み込まれていることから誤りなどに強く、多少時間がかかっても正しくデータを受信したいダウンロード型のアプリケーションに有効である。ＵＤＰ／ＩＰは再送の枠組みがない反面、再送などにかかる遅延がなく、リアルタイム性を求められるアプリケーションに有効である。
【０００４】
動画像通信では、通常、画像データは非常に膨大なデータ量であり、ネットワークの帯域に収まらない場合が多い。この場合、画像データを符号化しデータ量を小さくして伝送する手法が用いられる。動画像信号の圧縮符号化技術としては動き補償、離散コサイン変換（ＤＣＴ）、サブバンド符号化、ピラミッド符号化、可変長符号化等の技術やこれらを組み合わせた方式が開発されている。動画像符号化の国際標準方式としてはＩＳＯ ＭＰＥＧ−１， ＭＰＥＧ−２， ＩＴＵ−Ｔ Ｈ．２６１， Ｈ．２６２， Ｈ．２６３が存在し、動画像、音声・オーディオ信号を圧縮した符号列や他のデータを多重化する国際標準方式としてはＩＳＯ ＭＰＥＧシステム、ＩＴＵ−Ｔ Ｈ．２２１， Ｈ．２２３が存在する。
【０００５】
インターネット等は無数のネットワークを介して繋がっており、どのネットワークがどういう状況になっているかわからないのが通常である。また、そこに流れているデータ量が時々刻々と変動するため、どのくらいのデータがリアルタイムで通信できるかを判定する仕組みが必要である。そこで、ＵＤＰ／ＩＰを利用したリアルタイムアプリケーションから一歩進み、パケットに時間情報等を付加して伝送するＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）というパケットフォーマットを使用するアプリケーションが増えてきている。ＲＴＰを利用することで、パケットに時間情報及びパケット番号が付加され、受信側では正しい時間情報を用いて音声や画像を表示することが出来たり、ネットワークで順番が入れ替わったパケットなどを判定したり、パケット番号を見ることでパケットが損失していることを検出すること等が出来る。しかも、ＲＴＰには送信側や受信側から補足情報としてジッタやパケット損失率などを通知する仕組み（ＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ））も備わっている。また、ＲＴＰパケットの再送を行う仕組み等も現在議論されている。例えば、パケットに優先順位等を付加し、全てを再送しないようトラフィックの制御ができるような機能が知られている。ただし、この利用法について規定はなされていない。
【０００６】
また、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）では、上記のような画像通信を確立するための送信端末・受信端末間のセッション管理プロトコルとしてＲＴＳＰが規定されているとともに、画像コンテンツの内容を記述するための言語仕様であるＳＤＰが規定されている。これにより、サーバ・クライアント間では、ＲＴＳＰによりセッションの開始や、マルチメディアコンテンツの送信開始、一時停止やセッションの終了等の制御が可能となる。
【０００７】
ここで、画像をインターネット等で伝送する場合、インターネット等では生の画像伝送分の帯域を確保できないので、画像信号をＭＰＥＧなどの符号化方式で圧縮して送ることが行われる。これはデータ量の減少には効果があるが、不安定なインターネット等にデータを流すことでのパケット損失や誤りの混入に対して非常に脆くなる。動画像符号化方式では、前のフレームとの差分のみを送信することから、データの一部が欠落することが問題となる。ＵＤＰやＲＴＰでは、基本的にデータの再送をしないことから、該問題への対策が必要となる。このために、ＲＴＰの再送に関する規格制定がＩＥＴＦで行われている。簡単に言うと、ＡＶＰＦというプロトコルを使い、受信できなかったパケット番号をＮＡＣＫというコマンドで送信側に通知する。送信側では、ＮＡＣＫから消失したパケットを特定し、ＲＴＰ再送の規格に準じてヘッダを構成し、受信側へ送信する。さらに、ＲＴＰは主にリアルタイム通信に利用されることから、再送しても表示に間に合わないパケットは再送しないように制御する技術も提案されている（例えば、特許文献１参照）。また、再送パケットが到着するまでに遅延があり、リアルタイム再生に間に合わない可能性があるため、再送を記録用途に利用することも提案されている。その際、再送パケットをリアルタイムと同じ信頼性の低いＵＤＰで伝送するのではなく、信頼性のあるＴＣＰで伝送するようにする等の工夫がなされている（例えば、特許文献２参照）。
【０００８】
【特許文献１】
井戸 大治， 他， “データ送信装置、データ受信装置、およびデータ通信システム”， Ｐ２００２−８４３３８， Ｍａｒ． ２００２．
【０００９】
【特許文献２】
小林 誠， “通信制御装置、通信制御方法、及び通信制御プログラムが記録された記録媒体”， Ｐ２００２−１９９０１９， Ｊｕｌｙ ２００２．
【００１０】
【発明が解決しようとする課題】
従来の技術では、ネットワークのプロトコルとして、ＲＴＰのフィードバック情報（ＲＴＣＰ）や、再送制御（ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ）等が提案され規格化されてきたが、ＲＴＣＰや再送をどのように使用すべきかは提示されていない。記録用途に限定しＴＣＰで再送したり、リアルタイム再生に間に合わない再送パケットは伝送しないようにしたりする技術は知られているが、これらは単機能であり再生しながらの記録等で再生品質及び記録品質双方に効果があるような方式は存在しない。また、再送時の伝送帯域消費に関しては、再送した分を、通常の伝送で重要度の低いものの伝送を行わないことで補う技術が知られているが、これでは元のデータに欠落が出来てしまい、再生品質の低下や、記録コンテンツの品質も上がらないなどの問題が発生する。
【００１１】
本発明は、上記事情を考慮してなされたもので、誤りが混入する可能性のあるネットワークでマルチメディアコンテンツを効率よく伝送するパケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明に係るパケット送信装置は、マルチメディアコンテンツデータから生成された複数のパケットを順次ネットワークを介して受信装置へ送信する第１の送信手段と、前記受信装置から前記ネットワークを介して、再送すべきパケットを特定する情報を含む再送要求を受信する受信手段と、前記再送要求に係るパケットの再送に関する重要度を、該パケットに係るデータが前記受信装置で利用される予定の第１の時刻及び該パケットに対応する再送パケットに係るデータが前記受信装置で利用可能になると予想される第２の時刻に基づいて決定する決定手段と、前記重要度に基づいて再送すべきパケットを選択する選択手段と、選択されたパケットに対応する再送パケットを前記ネットワークを介して前記受信装置へ送信する第２の送信手段とを備えたことを特徴とする。
【００１３】
また、本発明に係るパケット受信装置は、マルチメディアコンテンツデータから生成された複数のパケット又はこれに対応する再送のパケットを順次ネットワークを介して送信装置から受信する第１の受信手段と、前記第１の受信手段により受信したパケットを解析し、その結果に基づいて再送すべきパケットを特定する特定手段と、再送すべきパケットを特定する情報を含む再送要求を前記ネットワークを介して前記送信装置へ送信する送信手段と、前記パケットに係るデータを利用するデータ利用手段と、前記パケットに係るデータを記録する記録手段とを備えたことを特徴とする。
【００１４】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００１５】
本発明では、パケットロスなどの誤りに対し再送を使ってデータを復元するシステムにおいて、リアルタイム再生と記録保存とを効率的に両立することが可能になる。
【００１６】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００１７】
本実施形態では、画像データや音声データを実時間転送するためのプロトコルであるＲＴＰ（リアルタイムトランスポートプロトコル）を利用する場合を例にとって説明する（なお、ＲＴＰの詳細は例えば「Ｓｃｈｕｌｚｒｉｎｎｅ， Ｈ．， Ｃａｓｎｅｒ， Ｓ．， Ｆｒｅｄｅｒｉｃｋ， Ｒ． ａｎｄ Ｖ． Ｊａｃｏｂｓｏｎ “ＲＴＰ： Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ”， ＲＦＣ １８８９， Ｊａｎｕａｒｙ １９９６．」に開示されている）。
【００１８】
（第１の実施形態）
図１に、本発明の第１の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００１９】
図１に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３を備えている。
【００２０】
なお、図１において、ａで示した範囲が、パケット送信に係る部分であり、ｂで示した範囲が、再送に関する制御に係る部分であり、ｃで示した範囲が、再送パケット送信に係る部分である（後に参照する各構成図おいても、ａ、ｂ、ｃを同様の意味で用いている）。
【００２１】
以下、本マルチメディアコンテンツ配信装置（送信側装置とも呼ぶ）がネットワーク（図示せず）を介してマルチメディアコンテンツ受信装置（受信側装置とも呼ぶ）（図示せず）へマルチメディアコンテンツを送信する場合の動作について説明する。マルチメディアコンテンツ受信装置としては、特に限定されるもんではなく、例えば既存のものでもよいし、第６の実施形態で説明するものでもよい。
【００２２】
マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信される。一方、ＲＴＰパケットデータ（１３２）は、パケットバッファ部１０８に蓄積され、伝送したパケットが受信側装置に届かなかった場合の再送用に保存される。
【００２３】
図２に、ＲＴＰパケットのヘッダ部分の構成を示す。図２の通り、ヘッダ中には、ＲＴＰのバージョン情報（Ｖ）、パディング情報（Ｐ）、拡張ヘッダの有無（Ｘ）、ＣＳＲＣの数（ＣＣ）、データの種類（ＰＴ）、送信元の識別子（ＳＳＲＣ）、関連した送信元の識別子（ＣＲＳＣ）と共に、パケットの番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）とパケットの時刻情報（タイムスタンプ（ｔｉｍｅｓｔａｍｐ））が含まれている。
【００２４】
受信側装置からは、通信路の状態を示す情報（以下、通信路状態情報）がＲＴＣＰ等を使い送信側装置へ送られてくる。通信路状態情報受信部１０５では、この通信路状態情報（１３４）を受信し、往復時間算出部１０６に送る。送信側装置と受信側装置との間でデータ転送にかかった時間（以下、往復時間）（１３８）を往復時間算出部１０６で決定し、再送制御部１０９に入力する。通信路状態情報の他に、受信側装置からは、届いていないパケットの番号を通知する情報を含む再送要求が送られてくる。再送要求受信部１０７では、この再送要求（１３５）を受信し、再送制御部１０９に送る。
【００２５】
再送制御部１０９では、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。再送制御部１０９では、現在時刻と、往復時間算出部１０６で決定した往復時間（１３８）と、再送要求キュー部１１０に蓄えられている未処理の再送要求のうち重要度の高いものを処理するのに要する時間（以下、所要処理時間）（１４０）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。ここで判断された結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、再送要求キュー部１１０に一時格納される。再送制御部１０９では、上記の判断に加え、再送要求キュー部１１０から重要度の高い順に再送要求を選択し、パケットバッファ部１０８に再送するよう指示を行うことも併せて行う。
【００２６】
パケットバッファ部１０８では、指示されたパケットデータ（１４１）を再送パケット化部１１１に送り、再送パケット化部１１１では、このパケットデータ（１４１）をもとに、再送用パケットフォーマットに従って、再送パケット（１４２）を生成する。
【００２７】
生成された再送パケット（１４２）は、再送パケットキュー部１１２に一時保管され、再送パケット送信部１１３から受信側へ送信される。
【００２８】
図３に、再送制御部１０９で再送要求されたパケットに対する重要度の判定の概略的な処理手順の一例を示す。
【００２９】
再送制御部１０９は、再送パケットが間に合うか否かを判定し（ステップＳ２０１）、間に合うと判定された場合には、重要度を“高”に設定し（ステップＳ２０２）、間に合わないと判定された場合には、重要度を“低”に設定する（ステップＳ２０３）。この判定結果に基づき、再送要求キュー部１１０に再送要求（１３９）が保管される。
【００３０】
図４に、再送要求キュー部１１０に保管される再送要求のデータ構造例を示す。この例では、各再送要求についての再送すべきパケットの番号とその重要度とを組にして保管し、再送制御部１０９が重要度の高いものから処理できるように構成する。もちろん、図４は一例であり、この他にも、種々のバリエーションが可能である。例えば、パケットの時刻情報や、パケットバッファ部１０８内やマルチメディアコンテンツ保存部１０１内での位置情報等の情報を保持させることも可能である。また、重要度に応じてリストを分割したり、ポインタを利用して各重要度の先頭データを指し示したりという手法を利用し効率的にデータを格納することも可能である。また、重要度情報も“高”・“低”の２値だけでなく、多値で記録することも可能である。
【００３１】
図５に、再送制御部１０９で再送要求されたパケットに対する重要度の判定のより詳細な処理手順の一例を示す。
【００３２】
再送制御部１０９は、再送要求（１３５）から、再送すべきパケット番号を特定する（ステップＳ４０１）。なお、再送要求（１３５）には、パケット不着を知らせるＮＡＣＫ情報等を利用することが出来る。
【００３３】
ステップＳ４０１で特定されたパケット番号を使い、パケットバッファ部１０８よりパケットの時刻情報（再生予定時刻）を取得する（ステップＳ４０２）。
【００３４】
パケットの時刻情報および通信路状態情報より算出した往復時間情報（１３８）に加え、受信側装置において用意してある初期バッファの量を示す初期バッファ量情報、送信開始時刻、現在時刻等の情報をシステムから取得し、該パケットを再送した場合の到着予想時刻を算出する（ステップＳ４０３）。
【００３５】
ステップＳ４０２で取得したパケットの再生予定時刻がステップＳ４０３で算出した到着予測時刻よりも後ならば（早急に再送すれば再生に間に合うと予測されるので）、早急に再送する価値のあるパケットと判定し、到着予想時刻が再生予定時刻よりも後ならば（早急に再送しても再生に間に合わないと予測されるので）、早急に再送しなくてもよいパケットと判定する（ステップＳ４０４）。
【００３６】
早急に再送すべきパケットと判定された場合は、該パケットの再送要求を重要度“高”に設定し、再送要求キュー部１１０に保管し（ステップＳ４０５）、早急に再送しなくてもよいと判定された場合には、該パケットの再送要求を重要度“低”に設定し、再送要求キュー部１１０に保管する（ステップＳ４０６）。
【００３７】
ここで、図５のステップＳ４０３およびステップＳ４０４での到着予想時刻と再生予定時刻との間の関係を図６および図７に示す。図６は到着予想時刻が再生予定時刻よりも前になり重要度が“高”に設定される場合の例であり、図７は逆に到着予想時刻が再生予定時刻よりも後になり重要度が“低”に設定される場合の例である。
【００３８】
ここで、送信側装置につき、送信開始時刻をＴＳＴＡＲＴ、パケットの送信時刻をＴＳＥＮＤ、パケットのタイムスタンプをＰＴＳ、受信側装置からの再送要求を受信した時刻をＴＲＲＥＱ、再送要求キュー部１１０等に蓄えられている処理待ちの重要度の高い再送要求を処理するのにかかる時間をＤＱＵＥと定義すると共に、受信側装置につき、送信側装置から送信を開始してから受信側装置が再生動作を開始するまでの初期応答遅延をα、再生動作を開始した時刻をＴＣＳＴＡＲＴ、受信バッファによる最初のデータを表示するまでの初期遅延時間をＤＩＮＩＴ、往復のパケット伝送にかかる往復時間をＲＴＴ、再送要求に基づいた再送パケットが到着する時刻をＴＲＲＣＶ、パケットの再生予定時刻をＴＰＬＡＹ、パケット処理にかかる時間をＤＬＳＲと定義する。
【００３９】
図６および図７からわかるように、再送パケット到着時刻（すなわち、再送パケットが再生可能になる時刻）ＴＲＲＣＶがパケット再生予定時刻ＴＰＬＡＹよりも前になれば、早急に再送すべきパケットということになる。これを数式で示すと数式（１）のようになる。数式（１）が真になる場合は、再送パケットが再生までに間に合うということになり、重要度を高く設定することになり、数式（１）が偽になる場合は、再送パケットが間に合わないことになり、重要度を低く設定する。
（ＴＲＲＥＱ−ＴＳＴＡＲＴ）＋ＤＱＵＥ＋ＲＴＴ／２≦ＤＩＮＩＴ＋ＰＴＳ …（１）
該判定の数式は、上記の数式（１）だけではなく、以下に例示する数式（２）、数式（３）、数式（４）のような方式で判定することや、これ以外の方式で行うことも可能である。
（ＴＲＲＥＱ−ＴＳＴＡＲＴ）＋ＤＱＵＥ＋ＲＴＴ／２≦ＤＩＮＩＴ＋ＰＴＳ＋α …（２）
（３／２）×ＲＴＴ≦ＤＩＮＩＴ …（３）
（３／２）×ＲＴＴ＋ＤＬＳＲ≦ＤＩＮＩＴ …（４）
数式（２）は、初期応答遅延αを考慮に入れて判定を行っている例であり、数式（３）は、初期遅延や累積遅延の影響を無視し、単純にＲＴＴと受信側のバッファ量ＤＩＮＩＴからだけで判定を行う例である。数式（４）は、受信側装置で到着したパケットを処理し、再送要求を出すまでのパケット処理時間ＤＬＳＲを考慮した判定条件式であり、ＤＬＳＲを計算するには、数式（５）のような式を利用することが出来る。
ＤＬＳＲ＝ＴＲＲＥＱ−ＴＳＥＮＤ−ＲＴＴ …（５）
送信側装置の再送制御部１０９で該判定を行うため、上記のような数式を利用するためには、受信側装置の時刻情報やバッファ量情報等を取得する必要がある。初期遅延時間ＤＩＮＩＴはセッション開始時のＳＤＰ（例えば「Ｍ． Ｈａｎｄｌｅｙ， ｅｔ ａｌ， “ＳＤＰ： Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ”， ＩＥＴＦ ＲＦＣ２３２７， Ａｐｒｉｌ １９９８．」参照）や端末の能力交換等で送信側装置へ通知したり、あらかじめシステムで初期値を決定したりしておくことで、送信側装置はそれらを知ることができる。また、往復時間などはＲＴＣＰを利用することで知ることが出来る。標準の方式によっては通知できない情報等は、ＲＴＣＰのＡＰＰパケット（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｐａｃｋｅｔ）によるアプリケーション依存の独自フォーマットを利用して伝送するなどの対策をとればよい。
【００４０】
本実施形態は、種々変形して実施することが可能である。その幾つかの例を以下に示す。
【００４１】
次に、図８に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。
【００４２】
図１の構成例では、再送制御部１０９が、再送用パケットデータ（１４１）を再送パケット化部１１１へ送るよう指示を出したが、図８の構成例では、この指示を再送要求キュー部１１０が行うようにしたものである。この場合、再送制御部１０９には、再送要求の重要度判定だけを行わせ、再送要求キュー部１１０が再送要求に応じた送信間隔の制御などを実行することになる。これにより、再送制御部１０９の構成が複雑になるのを防ぐことが出来る。
【００４３】
次に、図９に、本実施形態のマルチメディアコンテンツ配信装置のさらに他の構成例を示す。
【００４４】
図９は、ＲＴＰパケット化をリアルタイムで行うのではなく、予めＲＴＰ化されたデータをＲＴＰマルチメディアコンテンツ保存部８０１に保持するようにしたものである。ＲＴＰマルチメディアコンテンツ保存部８０１には、予めＲＴＰパケット化された形でまたはＲＴＰパケット化するための付加情報が付け加えられた形でコンテンツが保存されており、ＲＴＰマルチメディアコンテンツ保存部８０１からＲＴＰパケット化されたデータ（８３１）が出力される。これにより、リアルタイムにパケット生成を行わなくて済むという利点が得られる。
【００４５】
さらに、再送制御部１０９が直接ＲＴＰマルチメディアコンテンツ保存部８０１にアクセスすることで、パケットバッファ部１０８を省略することもできる。その他、パケットバッファ部１０８が実際のデータを保持するのではなく、ＲＴＰマルチメディアコンテンツ保存部８０１にあるデータへのポインタだけを保持しておくことも可能である。このような変形を行うことで、パケットバッファ部を省略して配信装置や配信プログラムを簡略化したり、ポインタを利用することでパケットバッファ部に必要なメモリ量を削減したりすることが可能となる。
【００４６】
なお、これらの場合、ＲＴＰパケット化部を備えなくて構わない。
【００４７】
また、マルチメディアコンテンツ保存部１０１及びＲＴＰパケット化部１０２と、ＲＴＰマルチメディアコンテンツ保存部８０１とを全て備え、ＲＴＰパケット化をリアルタイムで行って送信する機能と、予め保持されているＲＴＰパケットを送信する機能との両機能を適宜使用できるようにしてもよい。
【００４８】
ところで、本実施形態では、ネットワークの遅延時間、パケット時刻情報、受信側バッファ情報、送信開始時間、初期遅延時間等から到着予想時刻を算出している。
【００４９】
送信側装置において到着予想時刻を算出する場合、パケットバッファ部１０８に保存されているパケットデータからパケット時刻情報を得ることが出来る。また、受信側バッファ量に関する情報および初期遅延時間は、例えば、システムの規定値として送信側装置で予め知っている値である。送信開始時刻も送信側装置が有している。また、ネットワークの遅延時間情報は、受信側装置との間のパケットデータのやり取りから得られる値である。
【００５０】
このネットワークの遅延時間情報は、例えば、ＲＴＣＰという制御パケットを利用して、その中に含まれる時刻情報を利用して計算することができる。
【００５１】
図１０および図１１に、ＲＴＣＰのパケットの構成を示す。図１０は、送信側装置から受信側装置に送られる送信側レポートを示したものであり、図１１は受信側装置から送信側装置に送られる受信側レポートを示したものである。
【００５２】
ここで、ＲＴＣＰを用いてネットワークの遅延時間を求める方法について説明する。
【００５３】
受信側レポートを受信した送信側装置は、その受信側レポートを受信したＮＴＰ時刻Ｔｒ−ｒｅｃｖと、受信側レポート内にある“最後の送信側レポートのＮＴＰ ｔｉｍｅｓｔａｍｐ”ＴＬＳＲおよび“最後の送信側レポートが到着してから受信側レポートを送信するまでの時間”ＴＤＬＳＲとを用いて、数式（５）のように計算を行う。
Ｔｄｅｌａｙ＝Ｔｒ−ｒｅｃｖ−ＴＬＳＲ−ＴＤＬＳＲ …（５）
ここで求められた値が往復のネットワーク遅延時間Ｔｄｅｌａｙである。
【００５４】
受信側バッファ量に関する情報および初期遅延時間は、前述したように規定値を用いる他に、受信側装置からセッションを確立する際のネゴシエーションで通知する方法もある。
【００５５】
一方、受信装置側で到着予想時刻を判定する場合も同様の判定方法で行うことができる。パケット時刻情報は、パケットが失われているため正確な時刻が判明しない。この場合、対象となるパケットロスしたパケットに一番近いまたは前後どちらか一方向で一番近いパケットの時刻情報を代替して利用する方法や、近いパケットの時刻情報とパケット番号などからパケットロスしたパケットの時刻情報を推定する方式などを利用することが可能である。受信側装置のバッファ量や初期遅延時間は、受信側装置で保持してある値であり、これをそのまま利用することができる。
【００５６】
ネットワークの遅延時間は、図１０に示した送信側レポートを受け取ることにより算出することができる。送信側レポートを受信したＮＴＰ時刻をＴｓ−ｒｅｃｖとし、送信側レポートに含まれる“ＮＴＰ ｔｉｍｅｓｔａｍｐ”Ｔｓ−ｓｅｎｄとする。これから片道のネットワーク遅延時間Ｔｄｅｌａｙ＿ｏｎｅｗａｙは、数式（６）で求めることが可能である。
Ｔｄｅｌａｙ＿ｏｎｅｗａｙ＝Ｔｓ−ｒｅｃｖ−Ｔｓ−ｓｅｎｄ …（６）
往復のネットワーク遅延時間を求める場合は、簡易的に２倍する方法や、送信側装置から受信側装置への方向での遅延と、受信側装置から送信側装置への方向での遅延とが均一でない場合を考慮して、係数を乗じるまたは値を加えるなどして対応させる方法などがある。
【００５７】
また、送信開始時間は、既存のＲＴＣＰでは通知することはできないため、例えば０とするなどの代替値で置き換えるなどの対応を行えばよい。その他に、ＲＴＰ・ＲＴＣＰとは別にセッション確立の際のネゴシエーションで送信側装置から受信側装置へ通知する方法をとることも可能である。
【００５８】
（第２の実施形態）
図１２に、本発明の第２の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００５９】
図１２に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送パケット化部１１１、再送パケット送信部１１３、再送待ちパケットバッファ部９０１を備えている。
【００６０】
本実施形態は、第１の実施形態の再送要求キュー部１１０と再送パケットキュー部１１２とを、再送待ちパケットバッファ部９０１で置き換えたものである。
【００６１】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００６２】
マルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信されるとともに、パケットバッファ部１０８に再送のために保存される。
【００６３】
通信路状態情報受信部１０５では、受信側装置から送られてきた通信路状態情報（１３４）を受信し、往復時間算出部１０６に送る。往復時間算出部１０６は、往復時間（１３８）を決定し、再送制御部１０９に入力する。
【００６４】
再送要求受信部１０７では、受信側装置から送られてきた再送要求（１３５）を受信し、再送制御部１０９に送る。
【００６５】
再送制御部１０９では、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。再送制御部１０９では、現在時刻と、往復時間（１３８）と、再送待ちパケットバッファ部９０１に蓄えられている未処理の再送要求のうち重要度の高いものを処理するのに要する所要処理時間（９３２）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。ここで判断された結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、パケットバッファ部１０８に対し再送すべきパケットの指定情報に重要度を付加した再送パケット指定情報（１３６）が送られる。
【００６６】
パケットバッファ部１０８では、再送パケット指定情報（１３６）に基づき再送用のパケットデータ（９３３）を再送待ちパケットバッファ部９０１に送る。この際、再送パケット指定情報（１３６）に付加されている重要度情報も併せて送る。
【００６７】
再送待ちパケットバッファ部９０１では、再送するパケットデータが重要度に応じた形で順序付けられ一時保管され、再送制御部１０９からの指示により順次パケットデータ（９３４）を出力する。
【００６８】
再送パケット化部１１１では、パケットデータ（９３４）をもとに、再送用パケットフォーマットに従って、再送パケット（１４３）を生成する。
【００６９】
再送パケット（１４３）は、再送パケット送信部１１３から受信側装置へ送信される。
【００７０】
図１３に、再送待ちパケットバッファ部９０１での重要度情報に対応した格納処理の手順の一例を示す。ここでは、重要度が２値で示される場合を例にとって説明する。
【００７１】
入力されたパケットデータ（９３３）について、付加された重要度情報が高いか否かの判定を行う（ステップＳ１００１）。重要度が“高”の場合は、重要度“高”のパケットデータリストの中でパケットのタイムスタンプに準じた順序位置にパケットデータ（９３３）が挿入される（ステップＳ１００２）。重要度が“低”の場合は、重要度“低”のパケットデータリストの中でパケットのタイムスタンプに準じた順序位置にパケットデータ（９３３）が挿入される（ステップＳ１００３）。
【００７２】
なお、重要度が２値以外の多値を持っている場合も、同様に、夫々の値に準じた順序位置にパケットデータを挿入するように構成すればよい。
【００７３】
次に、再送待ちパケットバッファ部９０１の構成例について説明する。
【００７４】
図１４に、重要度とパケット番号と再送待ちパケットデータとをセットで再送待ちパケットバッファ部９０１に格納するリスト方式の例を示す。この例では、重要度“高”のパケットが入ってきた場合には、重要度“高”でパケット番号が順番通りになるようにパケットデータが挿入されることになる。なお、図１４の例では、パケット番号を順序管理用の情報として利用しているが、例えばパケットのタイムスタンプなど、他の情報を利用したりすることも可能である。この方式は、データを直接順番に並べるため構成を簡単にすることが可能である。また、データの挿入に伴いそれ以降のデータを再度書き直すことがシステム的に負荷になる場合は、例えば重要度“高”のものと“低”のもののリストを分割しておき、夫々の後ろにデータを追加していく形を取ることで効率化することが可能である。
【００７５】
図１５に、途中への挿入もデータの書き換えがなく、重要度の高い方から低い方へ一列に並べることができる再送待ちパケットバッファ部９０１の構成例を示す。この例では、各パケットデータは、重要度、パケット番号、パケットデータ等前述したデータの他に、各パケットデータに対し順番が一つ前のものと一つ後ろのものへのポインタを有する構造になっている。これと、先頭データへのポインタ、最後尾データへのポインタを有することで、先頭から順にデータを検索し、挿入すべき位置が見つかったところで、その前後のデータのポインタを挿入するパケットデータを指し示すように修正し、さらに自分自身のポインタを前後のパケットを示すように設定する。このようにポインタを利用することにより、データの追加書き込みだけで、順番を考慮した記憶が可能になる。なお、図１５の具体例において、（ａ）の状態で、重要度“高”、パケット番号“＃４２”のパケットデータを挿入すると、（ｂ）の通りになる。
【００７６】
なお、これらは一例であり、重要度に応じてパケットデータを再送パケット化部１１１に出力可能であれば、どのような方式でも対応可能である。また、第１の実施形態の変形例として説明したように、図９で示したようなＲＴＰマルチメディアコンテンツ保存部８０１を使うことで、パケットデータ自身をバッファに保管するのではなく、コンテンツ保存部８０１にあるデータへのポインタだけを保管し、再送パケット化部１１１でパケット化する場合に取り出すようにすることも可能である。
【００７７】
また、第１の実施形態では、再送パケット化されたデータを一旦再送パケットキュー部１１２で保管し、その後に再送パケット送信部１１３で送信していたが、本実施形態でも同様の構成をとることも可能である（図１２の構成例では、再送制御部１０９と再送待ちパケットバッファ部９０１が送信帯域を考慮したデータの出力を行う機能を有していると考えて、再送パケットキュー部を省いた形で説明したものである）。
【００７８】
（第３の実施形態）
図１６に、本発明の第３の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００７９】
図１６に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１を備えている。
【００８０】
なお、図１６において、ｂで示した範囲が、前述のように再送に関する制御に係る部分であり、ｄで示した範囲が、パケット送信及び再送パケット送信に係る部分である（後に参照する各構成図おいても、ｄを同様の意味で用いている）。
【００８１】
本実施形態は、第１の実施形態のパケット送信に係る構成と再送パケット送信に係る構成とを統合化したものである。
【００８２】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００８３】
マルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信されるとともに、パケットバッファ部１０８に再送のために保存される。
【００８４】
通信路状態情報受信部１０５は、受信側装置からの通信路状態情報（１３４）を受信する。往復時間算出部１０６は、往復時間（１３８）を決定する。再送要求受信部１０７は、受信側装置からの再送要求（１３５）を受信する。
【００８５】
再送制御部１０９は、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。また、現在時刻と、往復時間（１３８）と、所要処理時間（１４０）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。この判断結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、再送要求キュー部１１０に一時格納される。また、再送要求キュー部１１０から重要度の高い順に再送要求を選択し、パケットバッファ部１０８に再送するよう指示を行う。
【００８６】
パケットバッファ部１０８では、指示されたパケットデータ（１４１）を再送パケット化部１１１に送り、再送用パケットフォーマットに従って再送パケット（１４２）を生成する。
【００８７】
再送パケット（１４２）は、送信キュー部１０３において元のパケットデータと共存する形で一時保管され、送信部１０４により受信側装置へ送信される。送信キュー部１０３では、元のパケットデータと再送用のパケットデータを一元的に管理し、送信タイミングを調整する。
【００８８】
本実施形態によれば、送信部分を一つにすることが可能となり、装置の構成を簡略化することが可能となる。また、携帯端末等の少ないリソースで本方式を実現するのに役立つ。
【００８９】
また、本実施形態では、第１の実施形態や第２の実施形態で示した構成例や変形例等を利用することももちろん可能である。
【００９０】
一例として、図１７に、再送待ちパケットバッファ部９０１（図１２参照）を利用した場合の構成例を示す。この場合、パケットバッファ部１０８から出力された重要度を付加された再送用パケットデータ（９３３）は、再送待ちパケットバッファ部９０１に入力され、再送待ちパケットバッファ部９０１では、再送するパケットデータが重要度に応じた形で順序付けられ一時保管され、再送制御部１０９からの指示により順次パケットデータ９３４を出力する。再送パケット化部１１１では、パケットデータ（９３４）をもとに、再送用パケットフォーマットに従って、再送パケット（１４２）を生成する。再送パケット（１４２）は、送信キュー部１０３に元のパケットデータと共存する形で一時保管され、送信部１０４により受信側へ送信される。ここで、再送制御部１０９は、再送待ちパケットバッファ部９０１から、どのくらい処理待ちの再送要求があるかの情報を取り出して、再送制御の判定材料として利用している。
【００９１】
続いて、図１８に、もう一つの構成例を示す。図１８は、図１７の変形例と同様の考え方であるが、再送待ちパケットバッファ部９０１を用いるのではなく、送信キュー部１０３を代わりに利用するものである。この場合、パケットバッファ部１０８から出力された再送用パケットデータ（１４１）は、再送パケット化部１１１に入力され、再送パケットデータ（１４２）が生成された後に送信キュー部１０３に入力される。再送パケット（１４２）は、送信キュー部１０３に元のパケットデータと共存する形で一時保管され、送信部１０４により受信側装置へ送信される。ここで、再送制御部１０９は、送信キュー部１０３内に保管されているパケットデータ量等の情報（１５３２）を受け取り、再送制御の判定材料として利用する。これにより、非常に簡易なモジュール構成で実施することが可能となる。
【００９２】
（第４の実施形態）
第１〜第３の実施形態では、再送制御という部分について種々の構成例を示してきたが、第４の実施形態では、再送制御に、再送分を考慮に入れた通信帯域制御（レート制御）を組み合わせた場合について説明する。
【００９３】
図１９に、本実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００９４】
図１９に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３、セッション制御部１６０１を備えている。すなわち、図１９の構成例は、図１の構成例にセッション制御部１６０１を付加したものである。
【００９５】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００９６】
セッション制御部１６０１以外の各部は基本的には第１の実施形態と同様である。
【００９７】
セッション制御部１６０１では、ＳＤＰやＲＴＳＰ（例えば「Ｈ． Ｓｃｈｕｌｚｒｉｎｎｅ， ｅｔ ａｌ， “Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ （ＲＴＳＰ）”， ＩＥＴＦ ＲＦＣ２３２６， Ａｐｒｉｌ １９９８．」参照）等を使い、受信側装置とのセッションの要求・許可等を管理を行っている。ここで、受信側装置と送信側装置との間での交渉の結果決定した伝送帯域情報を使い、送信キュー部１０３、送信部１０４、再送制御部１０９、再送パケットキュー部１１２、再送パケット送信部１１３を制御する。具体的には、指定された帯域を守る形で各部がデータを送信する。伝送路の帯域を指定する方式としては、元データが使用する伝送帯域に再送で使用する伝送帯域を予め上乗せした形で受信側装置に通知しておく方式や、元データの伝送帯域と再送用の伝送帯域を別々に通知する方式等を利用する。
【００９８】
次に、図２０に、ストリーム切替機能を併せ持つことで、動的な帯域変動に追従することを容易にした構成例を示す。
【００９９】
この構成例においては、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１の代わりに、コンテンツ切替用に同じコンテンツを複数のパラメータで符号化し格納してある切替対応複数マルチメディアコンテンツ保存部１７０２を備え、これをレート制御部１７０１で管理する構成をとる。レート制御部１７０１に対しては、送信キュー部１０３、再送パケットキュー部１１２、通信路状態情報受信部１０５から送信待ち状態のパケットがどのくらい残っているかの情報（１７３１および１７３３）、通信路の誤りや遅延情報（１７３４）などが入力される。これらの情報をもとに、元データの伝送帯域やパラメータが最適になるコンテンツを、切替対応複数マルチメディアコンテンツ保存部１７０２から選択する。また、再送制御部１０９もレート制御部１７０１から現在の送信状況やコンテンツ切替情報１７３２を通知し、再送パケットの重要度判定に利用する。このような構成をとることで、通信路の帯域変動や環境変動に対応したレート制御が可能となる。
【０１００】
（第５の実施形態）
第１〜第４の実施形態は、予め作成されたコンテンツデータから配信するものであったが、第５の実施形態では、リアルタイムに入力されるライブ映像等にも対応することを可能としたものである。
【０１０１】
図２１に、本発明の第５の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【０１０２】
図２１に示されるように、本マルチメディアコンテンツ配信装置は、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３、符号化部１８０１、レート制御部１８０２を備えている。すなわち、図２１の構成例は、図１の構成例のマルチメディアコンテンツ保存部１０１の代わりに、符号化部１８０１とレート制御部１８０２を備えたものである。
【０１０３】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【０１０４】
第１の実施形態の図１の構成例では、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）を、ＲＴＰパケット化部１０２でＲＴＰパケット化していたのに対し、図２１の構成例では、入力されたリアルタイム映像データ（１８３１）を符号化部１８０１で符号化し、符号化データ（１８３２）をＲＴＰパケット化部１０２でＲＴＰパケット化する。
【０１０５】
また、レート制御部１８０２は、送信キュー部１０３、再送パケットキュー部１１２および通信路状態情報受信部１０５から、送信待ちパケットのデータ量（１８３５および１８３３）、通信路状態情報（１８３４）を取得する。これらの情報をもとに、符号化部１８０１の符号化パラメータ（１８３６）を決定し、符号化部１８０１に通知する。符号化パラメータの制御は、例えば、送信キュー部１０３や再送パケットキュー部１１２に送信待ちパケットデータが多く存在している場合には、発生符号量を抑えるように量子化幅を大きくしたり、フレームレートを下げたりという制御を行う。また、通信路の状態も考慮し、遅延が大きくなった場合には同様の制御を行ったりすることも可能である。送信待ちのデータ量が少なくなった場合は、逆に発生符号量が多くなってもかまわないような制御を行うことも出来る。
【０１０６】
次に、図２２に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。図２２に示されるように、再送制御部１０９から判定結果や再送要求キュー部１１０に一時保管されている再送要求数などの情報（１９３１）をレート制御部１８０２に入力することで、さらに詳細なレート制御を行うことも可能である。これにより、伝送帯域を有効に利用した配信を実施することが可能となる。
【０１０７】
なお、マルチメディアコンテンツ保存部１０１と、符号化部１８０１及びレート制御部１８０２とを全て備え、予め作成されたコンテンツデータを配信する機能と、リアルタイムに入力されるライブ映像等を配信する機能との両機能を適宜使用できるようにしてもよい。
【０１０８】
次に、第３の実施形態で示した送信部分の共通化の考え方を、リアルタイムデータ入力の場合に適用した例を示す。図２３に、この場合の一構成例を示す。
【０１０９】
第３の実施形態の図１６の構成例では、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）を、ＲＴＰパケット化部１０２でＲＴＰパケット化していたのに対し、図２３の構成例では、入力されたリアルタイム映像データ（１８３１）を符号化部１８０１で符号化し、符号化データ（１８３２）をＲＴＰパケット化部１０２でＲＴＰパケット化する。
【０１１０】
また、レート制御部１８０２は、送信キュー部１０３および通信路状態情報受信部１０５から、送信待ちパケットのデータ量（１８３５）および通信路状態情報（１８３４）を取得する。これらの情報をもとに、符号化部１８０１の符号化パラメータ（１８３６）を決定し、符号化部１８０１に通知する。
【０１１１】
なお、第１〜第４の実施形態で説明した各種構成例のうち、ここで説明したもの以外にも、本実施形態のリアルタイムに入力されるライブ映像等に対応する構成は適用可能である。
【０１１２】
（第６の実施形態）
図２４に、本発明の第６の実施形態に係るマルチメディアコンテンツ受信装置の構成例を示す。
【０１１３】
図２４に示されるように、本マルチメディアコンテンツ受信装置は、受信部２１０１、パケット解析部２１０２、通信路状態算出部２１０３、通信路状態情報送信部２１０４、再送制御部２１０５、再送要求送信部２１０６、パケットバッファ部２１０７、復号化部２１０８、表示部２１０９、記録用バッファ部２１１０、記録部２１１１を備えている。
【０１１４】
なお、図２４において、ｅで示した範囲が、ＲＴＰに係る部分であり、ｆで示した範囲が、ＲＴＣＰに係る部分である（後に参照する各構成図おいても、ｅ、ｆを同様の意味で用いている）。
【０１１５】
以下、本マルチメディアコンテンツ受信装置（受信側装置とも呼ぶ）がマルチメディアコンテンツ配信装置（送信側装置とも呼ぶ）（図示せず）からネットワーク（図示せず）を介してマルチメディアコンテンツを受信する場合の動作について説明する。マルチメディアコンテンツ送信装置としては、特に限定されるもんではなく、例えば既存のものでもよいし、第１〜第５の実施形態で説明したものでもよい。
【０１１６】
送信側装置から送信されたパケットデータは、受信部２１０１で受信され、パケット解析部２１０２で、パケットヘッダ等を読み取り、パケット番号、タイムスタンプ等が取得される。これらのパケット解析情報（２１３２）は、通信路状態算出部２１０３でパケットロスや遅延量などが計算され、通信路状態情報送信部２１０４によりＲＴＣＰ等を利用して送信側装置へ送信される。
【０１１７】
また、パケット解析情報（２１３２）と通信路状態情報（２１３４）は、再送制御部２１０５に入力され、再送要求するか否かの判定が行われる。パケットロスが発生したパケット番号等から、例えばＮＡＣＫ情報等を利用した再送要求（２１３５）を生成し、再送要求送信部２１０６で送信側装置へ通知する。
【０１１８】
一方、受信されたパケットデータ（２１３６）は、パケットバッファ部２１０７へ一時保管され、再送等で送られてくるパケットと併せて順番を調整した後、再生に間に合うデータだけが選択され、復号化部２１０８へ送られる。
【０１１９】
復号化部２１０８では、入力されたコンテンツデータ（２１３７）に応じた復号処理を行い、表示部２１０９で再生を行う。一方、パケットバッファ部２１０７からは、再生に間に合わないデータも含めた形でコンテンツデータ２１３９が、記録用バッファ部２１１０に出力される。記録用バッファ部２１１０で再生に間に合わなかった再送データも併せた形で順番を調整した後、記録部２１１１へ記録される。
【０１２０】
記録用バッファ部２１１０では、先頭からデータに抜けがない部分に関しては順次記録部２１１１へ出力し、出力し終わったデータ領域を開放し新たなデータの書き込み領域として使用することにより、メモリを効率的に利用することが可能である。
【０１２１】
このようにパケットバッファ部２１０７では、再生時刻に間に合うデータを選択し再生を行う一方、記録用データとして再生に間に合わないデータをも併せて記録する処理を行っている。これによって、再生時には、（誤りが存在する場合もあるが）リアルタイムでマルチメディアデータを再生することができ、かつ記録用データとしては誤りのないデータを記録することが可能となる。その際、第１の実施形態〜第５の実施形態の各種構成例や変形例等のいずれかを利用して配信することにより、リアルタイム再生時に再送パケットが効果的に働くよう順番を制御することが可能となっている。
【０１２２】
次に、図２５に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。
【０１２３】
コンテンツの全体サイズが非常に大きい場合等は、図２４の構成例のように記録用バッファ部２１１０でデータを一時保管していては、仮に上記のように抜けがない部分のデータを逐次記録部２１１１へ出力していたとしても、メモリが大量に必要になる場合が発生する可能性がある。特に、再生に間に合わないデータの再送が配信側で後回しになった場合、いつまでたってもデータがそろわず記録部２１１１へ出力することができなくなる。そこで、図２５の構成例では、パケットバッファ部２１０７から記録部２１１１へ直接データを書き込み、後から記録制御部２２０１によって、記録部２１１１内部のデータを並べ替える方式を利用することも可能である。
【０１２４】
なお、この際、記録部２１１１に書き込むデータを図１５で説明したようなポインタを利用する形で記録しておくことにより、記録部２１１１内のデータ書き換えを最小限にとどめる拡張も可能である。
【０１２５】
さらに、第１〜第５の実施形態では、送信側装置において再送要求の重要度を判定し、順番を制御する場合について説明してきたが、これら方式を受信側装置に応用することも可能である。
【０１２６】
図２６には、その一例として、第１の実施形態で採用した方式を適用した場合のマルチメディアコンテンツ配信装置の構成例を示す。
【０１２７】
この場合、再送制御部２１０５は、該再送要求の重要度判定も行い、再送要求キュー部２３０１は、再送制御部２１０５で生成された重要度情報が付加された再送要求（２３３１）を一時保管する。重要度情報を使い順序付けられた再送要求情報（２３３２）は、再送制御部２１０５が要求送信タイミングを考慮しながら再送要求送信部２１０６に送られ、送信側装置に送られる。
【０１２８】
もちろん、この場合も、図２５のように、パケットバッファ部２１０７から記録部２１１１へ直接データを書き込み、後から記録制御部２２０１によって、記録部２１１１内部のデータを並べ替える方式を利用することも可能である。
【０１２９】
また、第１〜第５の実施形態で説明した各種構成例のうち、ここで説明したもの以外についても同様に適用可能である。
【０１３０】
なお、第１〜第６の実施形態においては、ＲＴＰを利用する場合を例にとって説明してきたが、プロトコルはこれに限定されるものではなく、再送が可能な様々なプロトコルを利用することが可能である。また、第１〜第６の実施形態においては、コンテンツデータとして動画や静止画等の映像信号を主に説明してきたが、データの種類について制限されるものではなく、音声データやテキストデータ等でも実施可能である。
【０１３１】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１３２】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１３３】
【発明の効果】
本発明によれば、誤りが混入する可能性のあるネットワークでマルチメディアコンテンツを効率よく伝送することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２】ＲＴＰパケットのヘッダ部分の構成を示す図
【図３】同実施形態における再送要求重要度判定の処理の概略的な手順の一例を示すフローチャート
【図４】同実施形態における再送要求キューの構成例を示す図
【図５】同実施形態における再送要求重要度判定の処理の詳細な手順の一例を示すフローチャート
【図６】同実施形態における再送パケットが再生予定時刻に間に合う場合の送受信時刻について説明するための図
【図７】同実施形態における再送パケットが再生予定時刻に間に合わない場合の送受信時刻について説明するための図
【図８】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図９】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図１０】送信側から受信側に送られるＲＴＣＰの送信側レポートのパケットの構成を示す図
【図１１】受信側から送信側に送られるＲＴＣＰの送信側レポートのパケットの構成を示す図
【図１２】本発明の第２の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図１３】同実施形態における再送パケットバッファ部での重要度に応じた処理手順の一例を示すフローチャート
【図１４】同実施形態における再送待ちパケットバッファ部の構成例を示す図
【図１５】同実施形態における再送待ちパケットバッファ部の他の構成例を示す図
【図１６】本発明の第３の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図１７】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図１８】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図１９】本発明の第４の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２０】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図２１】本発明の第５の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２２】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図２３】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図２４】本発明の第６の実施形態に係るマルチメディアコンテンツ受信装置の構成例を示す図
【図２５】同実施形態におけるマルチメディアコンテンツ受信装置の他の構成例を示す図
【図２６】同実施形態におけるマルチメディアコンテンツ受信装置のさらに他の構成例を示す図
【符号の説明】
１０１…マルチメディアコンテンツ保存部、１０２…ＲＴＰパケット化部、１０３…送信キュー部、１０４…送信部、１０５…通信路状態情報受信部、１０６…往復時間算出部、１０７…再送要求受信部、１０８…パケットバッファ部、１０９…再送制御部、１１０…再送要求キュー部、１１１…再送パケット化部、１１２…再送パケットキュー部、１１３…再送パケット送信部、８０１…ＲＴＰマルチメディアコンテンツ保存部、９０１…再送待ちパケットバッファ部、１６０１…セッション制御部、１７０１…レート制御部、１７０２…切替対応複数マルチメディアコンテンツ保存部、１８０１…符号化部、１８０２…レート制御部、２１０１…受信部、２１０２…パケット解析部、２１０３…通信路状態算出部、２１０４…通信路状態情報送信部、２１０５…再送制御部、２１０６…再送要求送信部、２１０７…パケットバッファ部、２１０８…復号化部、２１０９…表示部、２１１０…記録用バッファ部、２１１１…記録部、２２０１…記録制御部、２３０１…再送要求キュー部
【発明の属する技術分野】
本発明は、符号化された動画像／静止画像に係るパケットをＩＳＤＮやインターネット等の有線通信網あるいは携帯電話や無線ＬＡＮ等の無線通信網を用いて送信するパケット送信装置、該パケットを受信するパケット受信装置、パケット送信方法及びパケット受信方法に関する。
【０００２】
【従来の技術】
近年、画像等の各種情報のデジタル符号化技術や広帯域ネットワーク技術の進展により、これらを利用したアプリケーションの開発が盛んになっており、圧縮符号化した画像等を通信網を利用して伝送するシステムが開発されている。
【０００３】
特に、インターネット・イントラネットの普及により、データをパケット化して送受信するアプリケーションやシステムが増加している。パケット化は通信路の帯域を効率良く複数のユーザで共有するのに有効な手段である。パケットデータを送受信するプロトコルとしてＴＣＰ／ＩＰやＵＤＰ／ＩＰなどが存在する。ＴＣＰ／ＩＰは再送などの枠組みが組み込まれていることから誤りなどに強く、多少時間がかかっても正しくデータを受信したいダウンロード型のアプリケーションに有効である。ＵＤＰ／ＩＰは再送の枠組みがない反面、再送などにかかる遅延がなく、リアルタイム性を求められるアプリケーションに有効である。
【０００４】
動画像通信では、通常、画像データは非常に膨大なデータ量であり、ネットワークの帯域に収まらない場合が多い。この場合、画像データを符号化しデータ量を小さくして伝送する手法が用いられる。動画像信号の圧縮符号化技術としては動き補償、離散コサイン変換（ＤＣＴ）、サブバンド符号化、ピラミッド符号化、可変長符号化等の技術やこれらを組み合わせた方式が開発されている。動画像符号化の国際標準方式としてはＩＳＯ ＭＰＥＧ−１， ＭＰＥＧ−２， ＩＴＵ−Ｔ Ｈ．２６１， Ｈ．２６２， Ｈ．２６３が存在し、動画像、音声・オーディオ信号を圧縮した符号列や他のデータを多重化する国際標準方式としてはＩＳＯ ＭＰＥＧシステム、ＩＴＵ−Ｔ Ｈ．２２１， Ｈ．２２３が存在する。
【０００５】
インターネット等は無数のネットワークを介して繋がっており、どのネットワークがどういう状況になっているかわからないのが通常である。また、そこに流れているデータ量が時々刻々と変動するため、どのくらいのデータがリアルタイムで通信できるかを判定する仕組みが必要である。そこで、ＵＤＰ／ＩＰを利用したリアルタイムアプリケーションから一歩進み、パケットに時間情報等を付加して伝送するＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）というパケットフォーマットを使用するアプリケーションが増えてきている。ＲＴＰを利用することで、パケットに時間情報及びパケット番号が付加され、受信側では正しい時間情報を用いて音声や画像を表示することが出来たり、ネットワークで順番が入れ替わったパケットなどを判定したり、パケット番号を見ることでパケットが損失していることを検出すること等が出来る。しかも、ＲＴＰには送信側や受信側から補足情報としてジッタやパケット損失率などを通知する仕組み（ＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ））も備わっている。また、ＲＴＰパケットの再送を行う仕組み等も現在議論されている。例えば、パケットに優先順位等を付加し、全てを再送しないようトラフィックの制御ができるような機能が知られている。ただし、この利用法について規定はなされていない。
【０００６】
また、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）では、上記のような画像通信を確立するための送信端末・受信端末間のセッション管理プロトコルとしてＲＴＳＰが規定されているとともに、画像コンテンツの内容を記述するための言語仕様であるＳＤＰが規定されている。これにより、サーバ・クライアント間では、ＲＴＳＰによりセッションの開始や、マルチメディアコンテンツの送信開始、一時停止やセッションの終了等の制御が可能となる。
【０００７】
ここで、画像をインターネット等で伝送する場合、インターネット等では生の画像伝送分の帯域を確保できないので、画像信号をＭＰＥＧなどの符号化方式で圧縮して送ることが行われる。これはデータ量の減少には効果があるが、不安定なインターネット等にデータを流すことでのパケット損失や誤りの混入に対して非常に脆くなる。動画像符号化方式では、前のフレームとの差分のみを送信することから、データの一部が欠落することが問題となる。ＵＤＰやＲＴＰでは、基本的にデータの再送をしないことから、該問題への対策が必要となる。このために、ＲＴＰの再送に関する規格制定がＩＥＴＦで行われている。簡単に言うと、ＡＶＰＦというプロトコルを使い、受信できなかったパケット番号をＮＡＣＫというコマンドで送信側に通知する。送信側では、ＮＡＣＫから消失したパケットを特定し、ＲＴＰ再送の規格に準じてヘッダを構成し、受信側へ送信する。さらに、ＲＴＰは主にリアルタイム通信に利用されることから、再送しても表示に間に合わないパケットは再送しないように制御する技術も提案されている（例えば、特許文献１参照）。また、再送パケットが到着するまでに遅延があり、リアルタイム再生に間に合わない可能性があるため、再送を記録用途に利用することも提案されている。その際、再送パケットをリアルタイムと同じ信頼性の低いＵＤＰで伝送するのではなく、信頼性のあるＴＣＰで伝送するようにする等の工夫がなされている（例えば、特許文献２参照）。
【０００８】
【特許文献１】
井戸 大治， 他， “データ送信装置、データ受信装置、およびデータ通信システム”， Ｐ２００２−８４３３８， Ｍａｒ． ２００２．
【０００９】
【特許文献２】
小林 誠， “通信制御装置、通信制御方法、及び通信制御プログラムが記録された記録媒体”， Ｐ２００２−１９９０１９， Ｊｕｌｙ ２００２．
【００１０】
【発明が解決しようとする課題】
従来の技術では、ネットワークのプロトコルとして、ＲＴＰのフィードバック情報（ＲＴＣＰ）や、再送制御（ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ）等が提案され規格化されてきたが、ＲＴＣＰや再送をどのように使用すべきかは提示されていない。記録用途に限定しＴＣＰで再送したり、リアルタイム再生に間に合わない再送パケットは伝送しないようにしたりする技術は知られているが、これらは単機能であり再生しながらの記録等で再生品質及び記録品質双方に効果があるような方式は存在しない。また、再送時の伝送帯域消費に関しては、再送した分を、通常の伝送で重要度の低いものの伝送を行わないことで補う技術が知られているが、これでは元のデータに欠落が出来てしまい、再生品質の低下や、記録コンテンツの品質も上がらないなどの問題が発生する。
【００１１】
本発明は、上記事情を考慮してなされたもので、誤りが混入する可能性のあるネットワークでマルチメディアコンテンツを効率よく伝送するパケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明に係るパケット送信装置は、マルチメディアコンテンツデータから生成された複数のパケットを順次ネットワークを介して受信装置へ送信する第１の送信手段と、前記受信装置から前記ネットワークを介して、再送すべきパケットを特定する情報を含む再送要求を受信する受信手段と、前記再送要求に係るパケットの再送に関する重要度を、該パケットに係るデータが前記受信装置で利用される予定の第１の時刻及び該パケットに対応する再送パケットに係るデータが前記受信装置で利用可能になると予想される第２の時刻に基づいて決定する決定手段と、前記重要度に基づいて再送すべきパケットを選択する選択手段と、選択されたパケットに対応する再送パケットを前記ネットワークを介して前記受信装置へ送信する第２の送信手段とを備えたことを特徴とする。
【００１３】
また、本発明に係るパケット受信装置は、マルチメディアコンテンツデータから生成された複数のパケット又はこれに対応する再送のパケットを順次ネットワークを介して送信装置から受信する第１の受信手段と、前記第１の受信手段により受信したパケットを解析し、その結果に基づいて再送すべきパケットを特定する特定手段と、再送すべきパケットを特定する情報を含む再送要求を前記ネットワークを介して前記送信装置へ送信する送信手段と、前記パケットに係るデータを利用するデータ利用手段と、前記パケットに係るデータを記録する記録手段とを備えたことを特徴とする。
【００１４】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００１５】
本発明では、パケットロスなどの誤りに対し再送を使ってデータを復元するシステムにおいて、リアルタイム再生と記録保存とを効率的に両立することが可能になる。
【００１６】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００１７】
本実施形態では、画像データや音声データを実時間転送するためのプロトコルであるＲＴＰ（リアルタイムトランスポートプロトコル）を利用する場合を例にとって説明する（なお、ＲＴＰの詳細は例えば「Ｓｃｈｕｌｚｒｉｎｎｅ， Ｈ．， Ｃａｓｎｅｒ， Ｓ．， Ｆｒｅｄｅｒｉｃｋ， Ｒ． ａｎｄ Ｖ． Ｊａｃｏｂｓｏｎ “ＲＴＰ： Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ”， ＲＦＣ １８８９， Ｊａｎｕａｒｙ １９９６．」に開示されている）。
【００１８】
（第１の実施形態）
図１に、本発明の第１の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００１９】
図１に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３を備えている。
【００２０】
なお、図１において、ａで示した範囲が、パケット送信に係る部分であり、ｂで示した範囲が、再送に関する制御に係る部分であり、ｃで示した範囲が、再送パケット送信に係る部分である（後に参照する各構成図おいても、ａ、ｂ、ｃを同様の意味で用いている）。
【００２１】
以下、本マルチメディアコンテンツ配信装置（送信側装置とも呼ぶ）がネットワーク（図示せず）を介してマルチメディアコンテンツ受信装置（受信側装置とも呼ぶ）（図示せず）へマルチメディアコンテンツを送信する場合の動作について説明する。マルチメディアコンテンツ受信装置としては、特に限定されるもんではなく、例えば既存のものでもよいし、第６の実施形態で説明するものでもよい。
【００２２】
マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信される。一方、ＲＴＰパケットデータ（１３２）は、パケットバッファ部１０８に蓄積され、伝送したパケットが受信側装置に届かなかった場合の再送用に保存される。
【００２３】
図２に、ＲＴＰパケットのヘッダ部分の構成を示す。図２の通り、ヘッダ中には、ＲＴＰのバージョン情報（Ｖ）、パディング情報（Ｐ）、拡張ヘッダの有無（Ｘ）、ＣＳＲＣの数（ＣＣ）、データの種類（ＰＴ）、送信元の識別子（ＳＳＲＣ）、関連した送信元の識別子（ＣＲＳＣ）と共に、パケットの番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）とパケットの時刻情報（タイムスタンプ（ｔｉｍｅｓｔａｍｐ））が含まれている。
【００２４】
受信側装置からは、通信路の状態を示す情報（以下、通信路状態情報）がＲＴＣＰ等を使い送信側装置へ送られてくる。通信路状態情報受信部１０５では、この通信路状態情報（１３４）を受信し、往復時間算出部１０６に送る。送信側装置と受信側装置との間でデータ転送にかかった時間（以下、往復時間）（１３８）を往復時間算出部１０６で決定し、再送制御部１０９に入力する。通信路状態情報の他に、受信側装置からは、届いていないパケットの番号を通知する情報を含む再送要求が送られてくる。再送要求受信部１０７では、この再送要求（１３５）を受信し、再送制御部１０９に送る。
【００２５】
再送制御部１０９では、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。再送制御部１０９では、現在時刻と、往復時間算出部１０６で決定した往復時間（１３８）と、再送要求キュー部１１０に蓄えられている未処理の再送要求のうち重要度の高いものを処理するのに要する時間（以下、所要処理時間）（１４０）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。ここで判断された結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、再送要求キュー部１１０に一時格納される。再送制御部１０９では、上記の判断に加え、再送要求キュー部１１０から重要度の高い順に再送要求を選択し、パケットバッファ部１０８に再送するよう指示を行うことも併せて行う。
【００２６】
パケットバッファ部１０８では、指示されたパケットデータ（１４１）を再送パケット化部１１１に送り、再送パケット化部１１１では、このパケットデータ（１４１）をもとに、再送用パケットフォーマットに従って、再送パケット（１４２）を生成する。
【００２７】
生成された再送パケット（１４２）は、再送パケットキュー部１１２に一時保管され、再送パケット送信部１１３から受信側へ送信される。
【００２８】
図３に、再送制御部１０９で再送要求されたパケットに対する重要度の判定の概略的な処理手順の一例を示す。
【００２９】
再送制御部１０９は、再送パケットが間に合うか否かを判定し（ステップＳ２０１）、間に合うと判定された場合には、重要度を“高”に設定し（ステップＳ２０２）、間に合わないと判定された場合には、重要度を“低”に設定する（ステップＳ２０３）。この判定結果に基づき、再送要求キュー部１１０に再送要求（１３９）が保管される。
【００３０】
図４に、再送要求キュー部１１０に保管される再送要求のデータ構造例を示す。この例では、各再送要求についての再送すべきパケットの番号とその重要度とを組にして保管し、再送制御部１０９が重要度の高いものから処理できるように構成する。もちろん、図４は一例であり、この他にも、種々のバリエーションが可能である。例えば、パケットの時刻情報や、パケットバッファ部１０８内やマルチメディアコンテンツ保存部１０１内での位置情報等の情報を保持させることも可能である。また、重要度に応じてリストを分割したり、ポインタを利用して各重要度の先頭データを指し示したりという手法を利用し効率的にデータを格納することも可能である。また、重要度情報も“高”・“低”の２値だけでなく、多値で記録することも可能である。
【００３１】
図５に、再送制御部１０９で再送要求されたパケットに対する重要度の判定のより詳細な処理手順の一例を示す。
【００３２】
再送制御部１０９は、再送要求（１３５）から、再送すべきパケット番号を特定する（ステップＳ４０１）。なお、再送要求（１３５）には、パケット不着を知らせるＮＡＣＫ情報等を利用することが出来る。
【００３３】
ステップＳ４０１で特定されたパケット番号を使い、パケットバッファ部１０８よりパケットの時刻情報（再生予定時刻）を取得する（ステップＳ４０２）。
【００３４】
パケットの時刻情報および通信路状態情報より算出した往復時間情報（１３８）に加え、受信側装置において用意してある初期バッファの量を示す初期バッファ量情報、送信開始時刻、現在時刻等の情報をシステムから取得し、該パケットを再送した場合の到着予想時刻を算出する（ステップＳ４０３）。
【００３５】
ステップＳ４０２で取得したパケットの再生予定時刻がステップＳ４０３で算出した到着予測時刻よりも後ならば（早急に再送すれば再生に間に合うと予測されるので）、早急に再送する価値のあるパケットと判定し、到着予想時刻が再生予定時刻よりも後ならば（早急に再送しても再生に間に合わないと予測されるので）、早急に再送しなくてもよいパケットと判定する（ステップＳ４０４）。
【００３６】
早急に再送すべきパケットと判定された場合は、該パケットの再送要求を重要度“高”に設定し、再送要求キュー部１１０に保管し（ステップＳ４０５）、早急に再送しなくてもよいと判定された場合には、該パケットの再送要求を重要度“低”に設定し、再送要求キュー部１１０に保管する（ステップＳ４０６）。
【００３７】
ここで、図５のステップＳ４０３およびステップＳ４０４での到着予想時刻と再生予定時刻との間の関係を図６および図７に示す。図６は到着予想時刻が再生予定時刻よりも前になり重要度が“高”に設定される場合の例であり、図７は逆に到着予想時刻が再生予定時刻よりも後になり重要度が“低”に設定される場合の例である。
【００３８】
ここで、送信側装置につき、送信開始時刻をＴＳＴＡＲＴ、パケットの送信時刻をＴＳＥＮＤ、パケットのタイムスタンプをＰＴＳ、受信側装置からの再送要求を受信した時刻をＴＲＲＥＱ、再送要求キュー部１１０等に蓄えられている処理待ちの重要度の高い再送要求を処理するのにかかる時間をＤＱＵＥと定義すると共に、受信側装置につき、送信側装置から送信を開始してから受信側装置が再生動作を開始するまでの初期応答遅延をα、再生動作を開始した時刻をＴＣＳＴＡＲＴ、受信バッファによる最初のデータを表示するまでの初期遅延時間をＤＩＮＩＴ、往復のパケット伝送にかかる往復時間をＲＴＴ、再送要求に基づいた再送パケットが到着する時刻をＴＲＲＣＶ、パケットの再生予定時刻をＴＰＬＡＹ、パケット処理にかかる時間をＤＬＳＲと定義する。
【００３９】
図６および図７からわかるように、再送パケット到着時刻（すなわち、再送パケットが再生可能になる時刻）ＴＲＲＣＶがパケット再生予定時刻ＴＰＬＡＹよりも前になれば、早急に再送すべきパケットということになる。これを数式で示すと数式（１）のようになる。数式（１）が真になる場合は、再送パケットが再生までに間に合うということになり、重要度を高く設定することになり、数式（１）が偽になる場合は、再送パケットが間に合わないことになり、重要度を低く設定する。
（ＴＲＲＥＱ−ＴＳＴＡＲＴ）＋ＤＱＵＥ＋ＲＴＴ／２≦ＤＩＮＩＴ＋ＰＴＳ …（１）
該判定の数式は、上記の数式（１）だけではなく、以下に例示する数式（２）、数式（３）、数式（４）のような方式で判定することや、これ以外の方式で行うことも可能である。
（ＴＲＲＥＱ−ＴＳＴＡＲＴ）＋ＤＱＵＥ＋ＲＴＴ／２≦ＤＩＮＩＴ＋ＰＴＳ＋α …（２）
（３／２）×ＲＴＴ≦ＤＩＮＩＴ …（３）
（３／２）×ＲＴＴ＋ＤＬＳＲ≦ＤＩＮＩＴ …（４）
数式（２）は、初期応答遅延αを考慮に入れて判定を行っている例であり、数式（３）は、初期遅延や累積遅延の影響を無視し、単純にＲＴＴと受信側のバッファ量ＤＩＮＩＴからだけで判定を行う例である。数式（４）は、受信側装置で到着したパケットを処理し、再送要求を出すまでのパケット処理時間ＤＬＳＲを考慮した判定条件式であり、ＤＬＳＲを計算するには、数式（５）のような式を利用することが出来る。
ＤＬＳＲ＝ＴＲＲＥＱ−ＴＳＥＮＤ−ＲＴＴ …（５）
送信側装置の再送制御部１０９で該判定を行うため、上記のような数式を利用するためには、受信側装置の時刻情報やバッファ量情報等を取得する必要がある。初期遅延時間ＤＩＮＩＴはセッション開始時のＳＤＰ（例えば「Ｍ． Ｈａｎｄｌｅｙ， ｅｔ ａｌ， “ＳＤＰ： Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ”， ＩＥＴＦ ＲＦＣ２３２７， Ａｐｒｉｌ １９９８．」参照）や端末の能力交換等で送信側装置へ通知したり、あらかじめシステムで初期値を決定したりしておくことで、送信側装置はそれらを知ることができる。また、往復時間などはＲＴＣＰを利用することで知ることが出来る。標準の方式によっては通知できない情報等は、ＲＴＣＰのＡＰＰパケット（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｐａｃｋｅｔ）によるアプリケーション依存の独自フォーマットを利用して伝送するなどの対策をとればよい。
【００４０】
本実施形態は、種々変形して実施することが可能である。その幾つかの例を以下に示す。
【００４１】
次に、図８に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。
【００４２】
図１の構成例では、再送制御部１０９が、再送用パケットデータ（１４１）を再送パケット化部１１１へ送るよう指示を出したが、図８の構成例では、この指示を再送要求キュー部１１０が行うようにしたものである。この場合、再送制御部１０９には、再送要求の重要度判定だけを行わせ、再送要求キュー部１１０が再送要求に応じた送信間隔の制御などを実行することになる。これにより、再送制御部１０９の構成が複雑になるのを防ぐことが出来る。
【００４３】
次に、図９に、本実施形態のマルチメディアコンテンツ配信装置のさらに他の構成例を示す。
【００４４】
図９は、ＲＴＰパケット化をリアルタイムで行うのではなく、予めＲＴＰ化されたデータをＲＴＰマルチメディアコンテンツ保存部８０１に保持するようにしたものである。ＲＴＰマルチメディアコンテンツ保存部８０１には、予めＲＴＰパケット化された形でまたはＲＴＰパケット化するための付加情報が付け加えられた形でコンテンツが保存されており、ＲＴＰマルチメディアコンテンツ保存部８０１からＲＴＰパケット化されたデータ（８３１）が出力される。これにより、リアルタイムにパケット生成を行わなくて済むという利点が得られる。
【００４５】
さらに、再送制御部１０９が直接ＲＴＰマルチメディアコンテンツ保存部８０１にアクセスすることで、パケットバッファ部１０８を省略することもできる。その他、パケットバッファ部１０８が実際のデータを保持するのではなく、ＲＴＰマルチメディアコンテンツ保存部８０１にあるデータへのポインタだけを保持しておくことも可能である。このような変形を行うことで、パケットバッファ部を省略して配信装置や配信プログラムを簡略化したり、ポインタを利用することでパケットバッファ部に必要なメモリ量を削減したりすることが可能となる。
【００４６】
なお、これらの場合、ＲＴＰパケット化部を備えなくて構わない。
【００４７】
また、マルチメディアコンテンツ保存部１０１及びＲＴＰパケット化部１０２と、ＲＴＰマルチメディアコンテンツ保存部８０１とを全て備え、ＲＴＰパケット化をリアルタイムで行って送信する機能と、予め保持されているＲＴＰパケットを送信する機能との両機能を適宜使用できるようにしてもよい。
【００４８】
ところで、本実施形態では、ネットワークの遅延時間、パケット時刻情報、受信側バッファ情報、送信開始時間、初期遅延時間等から到着予想時刻を算出している。
【００４９】
送信側装置において到着予想時刻を算出する場合、パケットバッファ部１０８に保存されているパケットデータからパケット時刻情報を得ることが出来る。また、受信側バッファ量に関する情報および初期遅延時間は、例えば、システムの規定値として送信側装置で予め知っている値である。送信開始時刻も送信側装置が有している。また、ネットワークの遅延時間情報は、受信側装置との間のパケットデータのやり取りから得られる値である。
【００５０】
このネットワークの遅延時間情報は、例えば、ＲＴＣＰという制御パケットを利用して、その中に含まれる時刻情報を利用して計算することができる。
【００５１】
図１０および図１１に、ＲＴＣＰのパケットの構成を示す。図１０は、送信側装置から受信側装置に送られる送信側レポートを示したものであり、図１１は受信側装置から送信側装置に送られる受信側レポートを示したものである。
【００５２】
ここで、ＲＴＣＰを用いてネットワークの遅延時間を求める方法について説明する。
【００５３】
受信側レポートを受信した送信側装置は、その受信側レポートを受信したＮＴＰ時刻Ｔｒ−ｒｅｃｖと、受信側レポート内にある“最後の送信側レポートのＮＴＰ ｔｉｍｅｓｔａｍｐ”ＴＬＳＲおよび“最後の送信側レポートが到着してから受信側レポートを送信するまでの時間”ＴＤＬＳＲとを用いて、数式（５）のように計算を行う。
Ｔｄｅｌａｙ＝Ｔｒ−ｒｅｃｖ−ＴＬＳＲ−ＴＤＬＳＲ …（５）
ここで求められた値が往復のネットワーク遅延時間Ｔｄｅｌａｙである。
【００５４】
受信側バッファ量に関する情報および初期遅延時間は、前述したように規定値を用いる他に、受信側装置からセッションを確立する際のネゴシエーションで通知する方法もある。
【００５５】
一方、受信装置側で到着予想時刻を判定する場合も同様の判定方法で行うことができる。パケット時刻情報は、パケットが失われているため正確な時刻が判明しない。この場合、対象となるパケットロスしたパケットに一番近いまたは前後どちらか一方向で一番近いパケットの時刻情報を代替して利用する方法や、近いパケットの時刻情報とパケット番号などからパケットロスしたパケットの時刻情報を推定する方式などを利用することが可能である。受信側装置のバッファ量や初期遅延時間は、受信側装置で保持してある値であり、これをそのまま利用することができる。
【００５６】
ネットワークの遅延時間は、図１０に示した送信側レポートを受け取ることにより算出することができる。送信側レポートを受信したＮＴＰ時刻をＴｓ−ｒｅｃｖとし、送信側レポートに含まれる“ＮＴＰ ｔｉｍｅｓｔａｍｐ”Ｔｓ−ｓｅｎｄとする。これから片道のネットワーク遅延時間Ｔｄｅｌａｙ＿ｏｎｅｗａｙは、数式（６）で求めることが可能である。
Ｔｄｅｌａｙ＿ｏｎｅｗａｙ＝Ｔｓ−ｒｅｃｖ−Ｔｓ−ｓｅｎｄ …（６）
往復のネットワーク遅延時間を求める場合は、簡易的に２倍する方法や、送信側装置から受信側装置への方向での遅延と、受信側装置から送信側装置への方向での遅延とが均一でない場合を考慮して、係数を乗じるまたは値を加えるなどして対応させる方法などがある。
【００５７】
また、送信開始時間は、既存のＲＴＣＰでは通知することはできないため、例えば０とするなどの代替値で置き換えるなどの対応を行えばよい。その他に、ＲＴＰ・ＲＴＣＰとは別にセッション確立の際のネゴシエーションで送信側装置から受信側装置へ通知する方法をとることも可能である。
【００５８】
（第２の実施形態）
図１２に、本発明の第２の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００５９】
図１２に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送パケット化部１１１、再送パケット送信部１１３、再送待ちパケットバッファ部９０１を備えている。
【００６０】
本実施形態は、第１の実施形態の再送要求キュー部１１０と再送パケットキュー部１１２とを、再送待ちパケットバッファ部９０１で置き換えたものである。
【００６１】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００６２】
マルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信されるとともに、パケットバッファ部１０８に再送のために保存される。
【００６３】
通信路状態情報受信部１０５では、受信側装置から送られてきた通信路状態情報（１３４）を受信し、往復時間算出部１０６に送る。往復時間算出部１０６は、往復時間（１３８）を決定し、再送制御部１０９に入力する。
【００６４】
再送要求受信部１０７では、受信側装置から送られてきた再送要求（１３５）を受信し、再送制御部１０９に送る。
【００６５】
再送制御部１０９では、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。再送制御部１０９では、現在時刻と、往復時間（１３８）と、再送待ちパケットバッファ部９０１に蓄えられている未処理の再送要求のうち重要度の高いものを処理するのに要する所要処理時間（９３２）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。ここで判断された結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、パケットバッファ部１０８に対し再送すべきパケットの指定情報に重要度を付加した再送パケット指定情報（１３６）が送られる。
【００６６】
パケットバッファ部１０８では、再送パケット指定情報（１３６）に基づき再送用のパケットデータ（９３３）を再送待ちパケットバッファ部９０１に送る。この際、再送パケット指定情報（１３６）に付加されている重要度情報も併せて送る。
【００６７】
再送待ちパケットバッファ部９０１では、再送するパケットデータが重要度に応じた形で順序付けられ一時保管され、再送制御部１０９からの指示により順次パケットデータ（９３４）を出力する。
【００６８】
再送パケット化部１１１では、パケットデータ（９３４）をもとに、再送用パケットフォーマットに従って、再送パケット（１４３）を生成する。
【００６９】
再送パケット（１４３）は、再送パケット送信部１１３から受信側装置へ送信される。
【００７０】
図１３に、再送待ちパケットバッファ部９０１での重要度情報に対応した格納処理の手順の一例を示す。ここでは、重要度が２値で示される場合を例にとって説明する。
【００７１】
入力されたパケットデータ（９３３）について、付加された重要度情報が高いか否かの判定を行う（ステップＳ１００１）。重要度が“高”の場合は、重要度“高”のパケットデータリストの中でパケットのタイムスタンプに準じた順序位置にパケットデータ（９３３）が挿入される（ステップＳ１００２）。重要度が“低”の場合は、重要度“低”のパケットデータリストの中でパケットのタイムスタンプに準じた順序位置にパケットデータ（９３３）が挿入される（ステップＳ１００３）。
【００７２】
なお、重要度が２値以外の多値を持っている場合も、同様に、夫々の値に準じた順序位置にパケットデータを挿入するように構成すればよい。
【００７３】
次に、再送待ちパケットバッファ部９０１の構成例について説明する。
【００７４】
図１４に、重要度とパケット番号と再送待ちパケットデータとをセットで再送待ちパケットバッファ部９０１に格納するリスト方式の例を示す。この例では、重要度“高”のパケットが入ってきた場合には、重要度“高”でパケット番号が順番通りになるようにパケットデータが挿入されることになる。なお、図１４の例では、パケット番号を順序管理用の情報として利用しているが、例えばパケットのタイムスタンプなど、他の情報を利用したりすることも可能である。この方式は、データを直接順番に並べるため構成を簡単にすることが可能である。また、データの挿入に伴いそれ以降のデータを再度書き直すことがシステム的に負荷になる場合は、例えば重要度“高”のものと“低”のもののリストを分割しておき、夫々の後ろにデータを追加していく形を取ることで効率化することが可能である。
【００７５】
図１５に、途中への挿入もデータの書き換えがなく、重要度の高い方から低い方へ一列に並べることができる再送待ちパケットバッファ部９０１の構成例を示す。この例では、各パケットデータは、重要度、パケット番号、パケットデータ等前述したデータの他に、各パケットデータに対し順番が一つ前のものと一つ後ろのものへのポインタを有する構造になっている。これと、先頭データへのポインタ、最後尾データへのポインタを有することで、先頭から順にデータを検索し、挿入すべき位置が見つかったところで、その前後のデータのポインタを挿入するパケットデータを指し示すように修正し、さらに自分自身のポインタを前後のパケットを示すように設定する。このようにポインタを利用することにより、データの追加書き込みだけで、順番を考慮した記憶が可能になる。なお、図１５の具体例において、（ａ）の状態で、重要度“高”、パケット番号“＃４２”のパケットデータを挿入すると、（ｂ）の通りになる。
【００７６】
なお、これらは一例であり、重要度に応じてパケットデータを再送パケット化部１１１に出力可能であれば、どのような方式でも対応可能である。また、第１の実施形態の変形例として説明したように、図９で示したようなＲＴＰマルチメディアコンテンツ保存部８０１を使うことで、パケットデータ自身をバッファに保管するのではなく、コンテンツ保存部８０１にあるデータへのポインタだけを保管し、再送パケット化部１１１でパケット化する場合に取り出すようにすることも可能である。
【００７７】
また、第１の実施形態では、再送パケット化されたデータを一旦再送パケットキュー部１１２で保管し、その後に再送パケット送信部１１３で送信していたが、本実施形態でも同様の構成をとることも可能である（図１２の構成例では、再送制御部１０９と再送待ちパケットバッファ部９０１が送信帯域を考慮したデータの出力を行う機能を有していると考えて、再送パケットキュー部を省いた形で説明したものである）。
【００７８】
（第３の実施形態）
図１６に、本発明の第３の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００７９】
図１６に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１を備えている。
【００８０】
なお、図１６において、ｂで示した範囲が、前述のように再送に関する制御に係る部分であり、ｄで示した範囲が、パケット送信及び再送パケット送信に係る部分である（後に参照する各構成図おいても、ｄを同様の意味で用いている）。
【００８１】
本実施形態は、第１の実施形態のパケット送信に係る構成と再送パケット送信に係る構成とを統合化したものである。
【００８２】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００８３】
マルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）は、ＲＴＰパケット化部１０２でＲＴＰパケット化される。ＲＴＰパケットデータ（１３２）は、送信キュー部１０３で一時保管された後、送信部１０４からネットワークの帯域に沿った形で順次受信側に送信されるとともに、パケットバッファ部１０８に再送のために保存される。
【００８４】
通信路状態情報受信部１０５は、受信側装置からの通信路状態情報（１３４）を受信する。往復時間算出部１０６は、往復時間（１３８）を決定する。再送要求受信部１０７は、受信側装置からの再送要求（１３５）を受信する。
【００８５】
再送制御部１０９は、再送要求（１３５）から、再送すべきパケット番号を特定し、パケットバッファ部１０８から該当するパケットデータ（１３７）を取得する。また、現在時刻と、往復時間（１３８）と、所要処理時間（１４０）とを考慮して、再送要求（１３５）で指定されたパケットが再生時間に間に合うように受信側装置に到着するか否かの判断を行う。この判断結果は、再送要求（１３５）で指定されたパケットの重要度として設定され、再送要求キュー部１１０に一時格納される。また、再送要求キュー部１１０から重要度の高い順に再送要求を選択し、パケットバッファ部１０８に再送するよう指示を行う。
【００８６】
パケットバッファ部１０８では、指示されたパケットデータ（１４１）を再送パケット化部１１１に送り、再送用パケットフォーマットに従って再送パケット（１４２）を生成する。
【００８７】
再送パケット（１４２）は、送信キュー部１０３において元のパケットデータと共存する形で一時保管され、送信部１０４により受信側装置へ送信される。送信キュー部１０３では、元のパケットデータと再送用のパケットデータを一元的に管理し、送信タイミングを調整する。
【００８８】
本実施形態によれば、送信部分を一つにすることが可能となり、装置の構成を簡略化することが可能となる。また、携帯端末等の少ないリソースで本方式を実現するのに役立つ。
【００８９】
また、本実施形態では、第１の実施形態や第２の実施形態で示した構成例や変形例等を利用することももちろん可能である。
【００９０】
一例として、図１７に、再送待ちパケットバッファ部９０１（図１２参照）を利用した場合の構成例を示す。この場合、パケットバッファ部１０８から出力された重要度を付加された再送用パケットデータ（９３３）は、再送待ちパケットバッファ部９０１に入力され、再送待ちパケットバッファ部９０１では、再送するパケットデータが重要度に応じた形で順序付けられ一時保管され、再送制御部１０９からの指示により順次パケットデータ９３４を出力する。再送パケット化部１１１では、パケットデータ（９３４）をもとに、再送用パケットフォーマットに従って、再送パケット（１４２）を生成する。再送パケット（１４２）は、送信キュー部１０３に元のパケットデータと共存する形で一時保管され、送信部１０４により受信側へ送信される。ここで、再送制御部１０９は、再送待ちパケットバッファ部９０１から、どのくらい処理待ちの再送要求があるかの情報を取り出して、再送制御の判定材料として利用している。
【００９１】
続いて、図１８に、もう一つの構成例を示す。図１８は、図１７の変形例と同様の考え方であるが、再送待ちパケットバッファ部９０１を用いるのではなく、送信キュー部１０３を代わりに利用するものである。この場合、パケットバッファ部１０８から出力された再送用パケットデータ（１４１）は、再送パケット化部１１１に入力され、再送パケットデータ（１４２）が生成された後に送信キュー部１０３に入力される。再送パケット（１４２）は、送信キュー部１０３に元のパケットデータと共存する形で一時保管され、送信部１０４により受信側装置へ送信される。ここで、再送制御部１０９は、送信キュー部１０３内に保管されているパケットデータ量等の情報（１５３２）を受け取り、再送制御の判定材料として利用する。これにより、非常に簡易なモジュール構成で実施することが可能となる。
【００９２】
（第４の実施形態）
第１〜第３の実施形態では、再送制御という部分について種々の構成例を示してきたが、第４の実施形態では、再送制御に、再送分を考慮に入れた通信帯域制御（レート制御）を組み合わせた場合について説明する。
【００９３】
図１９に、本実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【００９４】
図１９に示されるように、本マルチメディアコンテンツ配信装置は、マルチメディアコンテンツ保存部１０１、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３、セッション制御部１６０１を備えている。すなわち、図１９の構成例は、図１の構成例にセッション制御部１６０１を付加したものである。
【００９５】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【００９６】
セッション制御部１６０１以外の各部は基本的には第１の実施形態と同様である。
【００９７】
セッション制御部１６０１では、ＳＤＰやＲＴＳＰ（例えば「Ｈ． Ｓｃｈｕｌｚｒｉｎｎｅ， ｅｔ ａｌ， “Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ （ＲＴＳＰ）”， ＩＥＴＦ ＲＦＣ２３２６， Ａｐｒｉｌ １９９８．」参照）等を使い、受信側装置とのセッションの要求・許可等を管理を行っている。ここで、受信側装置と送信側装置との間での交渉の結果決定した伝送帯域情報を使い、送信キュー部１０３、送信部１０４、再送制御部１０９、再送パケットキュー部１１２、再送パケット送信部１１３を制御する。具体的には、指定された帯域を守る形で各部がデータを送信する。伝送路の帯域を指定する方式としては、元データが使用する伝送帯域に再送で使用する伝送帯域を予め上乗せした形で受信側装置に通知しておく方式や、元データの伝送帯域と再送用の伝送帯域を別々に通知する方式等を利用する。
【００９８】
次に、図２０に、ストリーム切替機能を併せ持つことで、動的な帯域変動に追従することを容易にした構成例を示す。
【００９９】
この構成例においては、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１の代わりに、コンテンツ切替用に同じコンテンツを複数のパラメータで符号化し格納してある切替対応複数マルチメディアコンテンツ保存部１７０２を備え、これをレート制御部１７０１で管理する構成をとる。レート制御部１７０１に対しては、送信キュー部１０３、再送パケットキュー部１１２、通信路状態情報受信部１０５から送信待ち状態のパケットがどのくらい残っているかの情報（１７３１および１７３３）、通信路の誤りや遅延情報（１７３４）などが入力される。これらの情報をもとに、元データの伝送帯域やパラメータが最適になるコンテンツを、切替対応複数マルチメディアコンテンツ保存部１７０２から選択する。また、再送制御部１０９もレート制御部１７０１から現在の送信状況やコンテンツ切替情報１７３２を通知し、再送パケットの重要度判定に利用する。このような構成をとることで、通信路の帯域変動や環境変動に対応したレート制御が可能となる。
【０１００】
（第５の実施形態）
第１〜第４の実施形態は、予め作成されたコンテンツデータから配信するものであったが、第５の実施形態では、リアルタイムに入力されるライブ映像等にも対応することを可能としたものである。
【０１０１】
図２１に、本発明の第５の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す。
【０１０２】
図２１に示されるように、本マルチメディアコンテンツ配信装置は、ＲＴＰパケット化部１０２、送信キュー部１０３、送信部１０４、通信路状態情報受信部１０５、往復時間算出部１０６、再送要求受信部１０７、パケットバッファ部１０８、再送制御部１０９、再送要求キュー部１１０、再送パケット化部１１１、再送パケットキュー部１１２、再送パケット送信部１１３、符号化部１８０１、レート制御部１８０２を備えている。すなわち、図２１の構成例は、図１の構成例のマルチメディアコンテンツ保存部１０１の代わりに、符号化部１８０１とレート制御部１８０２を備えたものである。
【０１０３】
以下、本マルチメディアコンテンツ配信装置がネットワークを介してマルチメディアコンテンツ受信装置へマルチメディアコンテンツを送信する場合の動作について説明する。以下では、第１の実施形態で説明したものと相違する点を中心に説明する。
【０１０４】
第１の実施形態の図１の構成例では、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）を、ＲＴＰパケット化部１０２でＲＴＰパケット化していたのに対し、図２１の構成例では、入力されたリアルタイム映像データ（１８３１）を符号化部１８０１で符号化し、符号化データ（１８３２）をＲＴＰパケット化部１０２でＲＴＰパケット化する。
【０１０５】
また、レート制御部１８０２は、送信キュー部１０３、再送パケットキュー部１１２および通信路状態情報受信部１０５から、送信待ちパケットのデータ量（１８３５および１８３３）、通信路状態情報（１８３４）を取得する。これらの情報をもとに、符号化部１８０１の符号化パラメータ（１８３６）を決定し、符号化部１８０１に通知する。符号化パラメータの制御は、例えば、送信キュー部１０３や再送パケットキュー部１１２に送信待ちパケットデータが多く存在している場合には、発生符号量を抑えるように量子化幅を大きくしたり、フレームレートを下げたりという制御を行う。また、通信路の状態も考慮し、遅延が大きくなった場合には同様の制御を行ったりすることも可能である。送信待ちのデータ量が少なくなった場合は、逆に発生符号量が多くなってもかまわないような制御を行うことも出来る。
【０１０６】
次に、図２２に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。図２２に示されるように、再送制御部１０９から判定結果や再送要求キュー部１１０に一時保管されている再送要求数などの情報（１９３１）をレート制御部１８０２に入力することで、さらに詳細なレート制御を行うことも可能である。これにより、伝送帯域を有効に利用した配信を実施することが可能となる。
【０１０７】
なお、マルチメディアコンテンツ保存部１０１と、符号化部１８０１及びレート制御部１８０２とを全て備え、予め作成されたコンテンツデータを配信する機能と、リアルタイムに入力されるライブ映像等を配信する機能との両機能を適宜使用できるようにしてもよい。
【０１０８】
次に、第３の実施形態で示した送信部分の共通化の考え方を、リアルタイムデータ入力の場合に適用した例を示す。図２３に、この場合の一構成例を示す。
【０１０９】
第３の実施形態の図１６の構成例では、マルチメディアコンテンツを保持するマルチメディアコンテンツ保存部１０１から出力されたコンテンツデータ（１３１）を、ＲＴＰパケット化部１０２でＲＴＰパケット化していたのに対し、図２３の構成例では、入力されたリアルタイム映像データ（１８３１）を符号化部１８０１で符号化し、符号化データ（１８３２）をＲＴＰパケット化部１０２でＲＴＰパケット化する。
【０１１０】
また、レート制御部１８０２は、送信キュー部１０３および通信路状態情報受信部１０５から、送信待ちパケットのデータ量（１８３５）および通信路状態情報（１８３４）を取得する。これらの情報をもとに、符号化部１８０１の符号化パラメータ（１８３６）を決定し、符号化部１８０１に通知する。
【０１１１】
なお、第１〜第４の実施形態で説明した各種構成例のうち、ここで説明したもの以外にも、本実施形態のリアルタイムに入力されるライブ映像等に対応する構成は適用可能である。
【０１１２】
（第６の実施形態）
図２４に、本発明の第６の実施形態に係るマルチメディアコンテンツ受信装置の構成例を示す。
【０１１３】
図２４に示されるように、本マルチメディアコンテンツ受信装置は、受信部２１０１、パケット解析部２１０２、通信路状態算出部２１０３、通信路状態情報送信部２１０４、再送制御部２１０５、再送要求送信部２１０６、パケットバッファ部２１０７、復号化部２１０８、表示部２１０９、記録用バッファ部２１１０、記録部２１１１を備えている。
【０１１４】
なお、図２４において、ｅで示した範囲が、ＲＴＰに係る部分であり、ｆで示した範囲が、ＲＴＣＰに係る部分である（後に参照する各構成図おいても、ｅ、ｆを同様の意味で用いている）。
【０１１５】
以下、本マルチメディアコンテンツ受信装置（受信側装置とも呼ぶ）がマルチメディアコンテンツ配信装置（送信側装置とも呼ぶ）（図示せず）からネットワーク（図示せず）を介してマルチメディアコンテンツを受信する場合の動作について説明する。マルチメディアコンテンツ送信装置としては、特に限定されるもんではなく、例えば既存のものでもよいし、第１〜第５の実施形態で説明したものでもよい。
【０１１６】
送信側装置から送信されたパケットデータは、受信部２１０１で受信され、パケット解析部２１０２で、パケットヘッダ等を読み取り、パケット番号、タイムスタンプ等が取得される。これらのパケット解析情報（２１３２）は、通信路状態算出部２１０３でパケットロスや遅延量などが計算され、通信路状態情報送信部２１０４によりＲＴＣＰ等を利用して送信側装置へ送信される。
【０１１７】
また、パケット解析情報（２１３２）と通信路状態情報（２１３４）は、再送制御部２１０５に入力され、再送要求するか否かの判定が行われる。パケットロスが発生したパケット番号等から、例えばＮＡＣＫ情報等を利用した再送要求（２１３５）を生成し、再送要求送信部２１０６で送信側装置へ通知する。
【０１１８】
一方、受信されたパケットデータ（２１３６）は、パケットバッファ部２１０７へ一時保管され、再送等で送られてくるパケットと併せて順番を調整した後、再生に間に合うデータだけが選択され、復号化部２１０８へ送られる。
【０１１９】
復号化部２１０８では、入力されたコンテンツデータ（２１３７）に応じた復号処理を行い、表示部２１０９で再生を行う。一方、パケットバッファ部２１０７からは、再生に間に合わないデータも含めた形でコンテンツデータ２１３９が、記録用バッファ部２１１０に出力される。記録用バッファ部２１１０で再生に間に合わなかった再送データも併せた形で順番を調整した後、記録部２１１１へ記録される。
【０１２０】
記録用バッファ部２１１０では、先頭からデータに抜けがない部分に関しては順次記録部２１１１へ出力し、出力し終わったデータ領域を開放し新たなデータの書き込み領域として使用することにより、メモリを効率的に利用することが可能である。
【０１２１】
このようにパケットバッファ部２１０７では、再生時刻に間に合うデータを選択し再生を行う一方、記録用データとして再生に間に合わないデータをも併せて記録する処理を行っている。これによって、再生時には、（誤りが存在する場合もあるが）リアルタイムでマルチメディアデータを再生することができ、かつ記録用データとしては誤りのないデータを記録することが可能となる。その際、第１の実施形態〜第５の実施形態の各種構成例や変形例等のいずれかを利用して配信することにより、リアルタイム再生時に再送パケットが効果的に働くよう順番を制御することが可能となっている。
【０１２２】
次に、図２５に、本実施形態のマルチメディアコンテンツ配信装置の他の構成例を示す。
【０１２３】
コンテンツの全体サイズが非常に大きい場合等は、図２４の構成例のように記録用バッファ部２１１０でデータを一時保管していては、仮に上記のように抜けがない部分のデータを逐次記録部２１１１へ出力していたとしても、メモリが大量に必要になる場合が発生する可能性がある。特に、再生に間に合わないデータの再送が配信側で後回しになった場合、いつまでたってもデータがそろわず記録部２１１１へ出力することができなくなる。そこで、図２５の構成例では、パケットバッファ部２１０７から記録部２１１１へ直接データを書き込み、後から記録制御部２２０１によって、記録部２１１１内部のデータを並べ替える方式を利用することも可能である。
【０１２４】
なお、この際、記録部２１１１に書き込むデータを図１５で説明したようなポインタを利用する形で記録しておくことにより、記録部２１１１内のデータ書き換えを最小限にとどめる拡張も可能である。
【０１２５】
さらに、第１〜第５の実施形態では、送信側装置において再送要求の重要度を判定し、順番を制御する場合について説明してきたが、これら方式を受信側装置に応用することも可能である。
【０１２６】
図２６には、その一例として、第１の実施形態で採用した方式を適用した場合のマルチメディアコンテンツ配信装置の構成例を示す。
【０１２７】
この場合、再送制御部２１０５は、該再送要求の重要度判定も行い、再送要求キュー部２３０１は、再送制御部２１０５で生成された重要度情報が付加された再送要求（２３３１）を一時保管する。重要度情報を使い順序付けられた再送要求情報（２３３２）は、再送制御部２１０５が要求送信タイミングを考慮しながら再送要求送信部２１０６に送られ、送信側装置に送られる。
【０１２８】
もちろん、この場合も、図２５のように、パケットバッファ部２１０７から記録部２１１１へ直接データを書き込み、後から記録制御部２２０１によって、記録部２１１１内部のデータを並べ替える方式を利用することも可能である。
【０１２９】
また、第１〜第５の実施形態で説明した各種構成例のうち、ここで説明したもの以外についても同様に適用可能である。
【０１３０】
なお、第１〜第６の実施形態においては、ＲＴＰを利用する場合を例にとって説明してきたが、プロトコルはこれに限定されるものではなく、再送が可能な様々なプロトコルを利用することが可能である。また、第１〜第６の実施形態においては、コンテンツデータとして動画や静止画等の映像信号を主に説明してきたが、データの種類について制限されるものではなく、音声データやテキストデータ等でも実施可能である。
【０１３１】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１３２】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１３３】
【発明の効果】
本発明によれば、誤りが混入する可能性のあるネットワークでマルチメディアコンテンツを効率よく伝送することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２】ＲＴＰパケットのヘッダ部分の構成を示す図
【図３】同実施形態における再送要求重要度判定の処理の概略的な手順の一例を示すフローチャート
【図４】同実施形態における再送要求キューの構成例を示す図
【図５】同実施形態における再送要求重要度判定の処理の詳細な手順の一例を示すフローチャート
【図６】同実施形態における再送パケットが再生予定時刻に間に合う場合の送受信時刻について説明するための図
【図７】同実施形態における再送パケットが再生予定時刻に間に合わない場合の送受信時刻について説明するための図
【図８】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図９】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図１０】送信側から受信側に送られるＲＴＣＰの送信側レポートのパケットの構成を示す図
【図１１】受信側から送信側に送られるＲＴＣＰの送信側レポートのパケットの構成を示す図
【図１２】本発明の第２の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図１３】同実施形態における再送パケットバッファ部での重要度に応じた処理手順の一例を示すフローチャート
【図１４】同実施形態における再送待ちパケットバッファ部の構成例を示す図
【図１５】同実施形態における再送待ちパケットバッファ部の他の構成例を示す図
【図１６】本発明の第３の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図１７】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図１８】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図１９】本発明の第４の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２０】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図２１】本発明の第５の実施形態に係るマルチメディアコンテンツ配信装置の構成例を示す図
【図２２】同実施形態におけるマルチメディアコンテンツ配信装置の他の構成例を示す図
【図２３】同実施形態におけるマルチメディアコンテンツ配信装置のさらに他の構成例を示す図
【図２４】本発明の第６の実施形態に係るマルチメディアコンテンツ受信装置の構成例を示す図
【図２５】同実施形態におけるマルチメディアコンテンツ受信装置の他の構成例を示す図
【図２６】同実施形態におけるマルチメディアコンテンツ受信装置のさらに他の構成例を示す図
【符号の説明】
１０１…マルチメディアコンテンツ保存部、１０２…ＲＴＰパケット化部、１０３…送信キュー部、１０４…送信部、１０５…通信路状態情報受信部、１０６…往復時間算出部、１０７…再送要求受信部、１０８…パケットバッファ部、１０９…再送制御部、１１０…再送要求キュー部、１１１…再送パケット化部、１１２…再送パケットキュー部、１１３…再送パケット送信部、８０１…ＲＴＰマルチメディアコンテンツ保存部、９０１…再送待ちパケットバッファ部、１６０１…セッション制御部、１７０１…レート制御部、１７０２…切替対応複数マルチメディアコンテンツ保存部、１８０１…符号化部、１８０２…レート制御部、２１０１…受信部、２１０２…パケット解析部、２１０３…通信路状態算出部、２１０４…通信路状態情報送信部、２１０５…再送制御部、２１０６…再送要求送信部、２１０７…パケットバッファ部、２１０８…復号化部、２１０９…表示部、２１１０…記録用バッファ部、２１１１…記録部、２２０１…記録制御部、２３０１…再送要求キュー部
Claims (15)
- マルチメディアコンテンツデータから生成された複数のパケットを順次ネットワークを介して受信装置へ送信する第１の送信手段と、
前記受信装置から前記ネットワークを介して、再送すべきパケットを特定する情報を含む再送要求を受信する受信手段と、
前記再送要求に係るパケットの再送に関する重要度を、該パケットに係るデータが前記受信装置で利用される予定の第１の時刻及び該パケットに対応する再送パケットに係るデータが前記受信装置で利用可能になると予想される第２の時刻に基づいて決定する決定手段と、
前記重要度に基づいて再送すべきパケットを選択する選択手段と、
選択されたパケットに対応する再送パケットを前記ネットワークを介して前記受信装置へ送信する第２の送信手段とを備えたことを特徴とするパケット送信装置。 - 前記処理手段は、前記第１の時刻が前記第２の時刻より後の時刻である場合に、前記重要度を高い値に設定し、前記第１の時刻が前記第２の時刻以前の時刻である場合に、前記重要度を低い値に設定することを特徴とする請求項１に記載のパケット送信装置。
- 前記処理手段は、前記再送要求に係る再送パケットが前記第２の送信手段により送信されるまでの処理に要する第１の時間及び前記第２の送信手段により送信された再送パケットが前記受信装置へ到着するまでに要する第２の時間に基づいて、前記第２の時刻を予想することを特徴とする請求項２に記載のパケット送信装置。
- 前記処理手段は、前記再送要求に係る再送パケットよりも先に送信すべき他の再送要求に係る再送パケットの送信を済ませるまでに要する時間をもとに前記第１の時間を求め、前記受信装置との間でパケットが往復するのに要する時間をもとに前記第２の時間を求めることを特徴とする請求項３に記載のパケット送信装置。
- 前記決定手段は、前記第１の時刻が前記第２の時刻より後の時刻である場合には、前記再送要求に係る再送パケットを前記受信装置で前記第１の時刻に利用可能とする重要度を設定し、前記第１の時刻が前記第２の時刻以前の時刻である場合には、前記再送要求に係るパケットが前記選択手段により劣後的に選択される重要度を設定することを特徴とする請求項１に記載のパケット送信装置。
- マルチメディアコンテンツデータを記憶する記憶手段と、
前記マルチメディアコンテンツデータから前記複数のパケットを生成する生成手段とを更に備えたことを特徴とする請求項１に記載のパケット送信装置。 - 前記マルチメディアコンテンツデータから生成された複数のパケットに関するデータを記憶する記憶手段を更に備えたことを特徴とする請求項１に記載のパケット送信装置。
- マルチメディアコンテンツデータから生成された複数のパケット又はこれに対応する再送のパケットを順次ネットワークを介して送信装置から受信する第１の受信手段と、
前記第１の受信手段により受信したパケットを解析し、その結果に基づいて再送すべきパケットを特定する特定手段と、
再送すべきパケットを特定する情報を含む再送要求を前記ネットワークを介して前記送信装置へ送信する送信手段と、
前記パケットに係るデータを利用するデータ利用手段と、
前記パケットに係るデータを記録する記録手段とを備えたことを特徴とするパケット受信装置。 - 前記パケットに係るデータ及び前記再送のパケットに係るデータの全てを対象として、それらが利用される順番に並べ替えて保持する保持手段を更に備え、
前記記録手段は、前記保持手段に保持された、並べ替えられた後のデータを記録することを特徴とする請求項８に記載のパケット受信装置。 - 前記パケットに係るデータ及び前記再送のパケットに係るデータの全てを対象として、それらを蓄積するとともに、前記記録手段へ直接書き込む蓄積手段と、
前記記録手段に記録されたデータを、それらが利用される順番に並べ替える手段とを更に備えたことを特徴とする請求項８に記載のパケット受信装置。 - 前記データ利用手段は、前記パケットに係るデータ及び前記再送のパケットに係るデータのうち、これを利用すべき時刻より前に利用可能になったもののみを利用することを特徴とする請求項８に記載のパケット受信装置。
- 前記再送要求を蓄積する蓄積手段と、
前記特定手段により特定されたパケットに係る再送要求及び前記蓄積手段に蓄積された再送要求のうち重要度の高いものを選択して、前記送信手段へ渡す手段を更に備えたことを特徴とする請求項８に記載のパケット受信装置。 - 前記データ利用手段は、前記データを復号化する手段と、復号されたデータを表示する手段とを含むことを特徴とする請求項８に記載のパケット受信装置。
- マルチメディアコンテンツデータから生成された複数のパケットを順次ネットワークを介して受信装置へ送信するステップと、
前記受信装置から前記ネットワークを介して、再送すべきパケットを特定する情報を含む再送要求を受信するステップと、
前記再送要求に係るパケットの再送に関する重要度を、該パケットに係るデータが前記受信装置で利用される予定の第１の時刻及び該パケットに対応する再送パケットに係るデータが前記受信装置で利用可能になると予想される第２の時刻に基づいて決定するステップと、
前記重要度に基づいて再送すべきパケットを選択するステップと、
選択されたパケットに対応する再送パケットを前記ネットワークを介して前記受信装置へ送信するステップとを備えたことを特徴とするパケット送信方法。 - マルチメディアコンテンツデータから生成された複数のパケット又はこれに対応する再送のパケットを順次ネットワークを介して送信装置から受信するステップと、
受信したパケットを解析し、その結果に基づいて再送すべきパケットを特定するステップと、
再送すべきパケットを特定する情報を含む再送要求を前記ネットワークを介して前記送信装置へ送信するステップと、
前記パケットに係るデータを利用するステップと、
前記パケットに係るデータを記録するステップとを備えたことを特徴とするパケット受信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003202981A JP2005051299A (ja) | 2003-07-29 | 2003-07-29 | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003202981A JP2005051299A (ja) | 2003-07-29 | 2003-07-29 | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005051299A true JP2005051299A (ja) | 2005-02-24 |
Family
ID=34262503
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003202981A Pending JP2005051299A (ja) | 2003-07-29 | 2003-07-29 | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005051299A (ja) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011015214A (ja) * | 2009-07-02 | 2011-01-20 | Canon Inc | 送信装置、送信方法、及びコンピュータプログラム |
| JP2013078126A (ja) * | 2007-06-29 | 2013-04-25 | Toshiba Corp | 複数のインターフェースを介するビデオストリーム |
| US8860040B2 (en) | 2012-09-11 | 2014-10-14 | Dow Corning Corporation | High voltage power semiconductor devices on SiC |
| JP2015012306A (ja) * | 2013-06-26 | 2015-01-19 | 三菱電機株式会社 | 映像送受信システム、送信装置、および、受信装置 |
| US8940614B2 (en) | 2013-03-15 | 2015-01-27 | Dow Corning Corporation | SiC substrate with SiC epitaxial film |
| US9018639B2 (en) | 2012-10-26 | 2015-04-28 | Dow Corning Corporation | Flat SiC semiconductor substrate |
| US9017804B2 (en) | 2013-02-05 | 2015-04-28 | Dow Corning Corporation | Method to reduce dislocations in SiC crystal growth |
| US9279192B2 (en) | 2014-07-29 | 2016-03-08 | Dow Corning Corporation | Method for manufacturing SiC wafer fit for integration with power device manufacturing technology |
| US9738991B2 (en) | 2013-02-05 | 2017-08-22 | Dow Corning Corporation | Method for growing a SiC crystal by vapor deposition onto a seed crystal provided on a supporting shelf which permits thermal expansion |
| US9797064B2 (en) | 2013-02-05 | 2017-10-24 | Dow Corning Corporation | Method for growing a SiC crystal by vapor deposition onto a seed crystal provided on a support shelf which permits thermal expansion |
| WO2017199913A1 (ja) * | 2016-05-18 | 2017-11-23 | 日本電気株式会社 | 送信装置、方法、プログラムおよび記録媒体 |
| CN112416408A (zh) * | 2020-12-08 | 2021-02-26 | 金卡智能集团股份有限公司 | 固件升级方法、装置、设备及计算机可读存储介质 |
| CN114584844A (zh) * | 2020-11-30 | 2022-06-03 | 青岛海信宽带多媒体技术有限公司 | 一种rtp包丢包重传方法、装置及播放终端 |
| CN116865915A (zh) * | 2023-07-06 | 2023-10-10 | 中国工商银行股份有限公司 | 数据包重传方法和装置、存储介质及电子装置 |
-
2003
- 2003-07-29 JP JP2003202981A patent/JP2005051299A/ja active Pending
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013078126A (ja) * | 2007-06-29 | 2013-04-25 | Toshiba Corp | 複数のインターフェースを介するビデオストリーム |
| JP2011015214A (ja) * | 2009-07-02 | 2011-01-20 | Canon Inc | 送信装置、送信方法、及びコンピュータプログラム |
| US8860040B2 (en) | 2012-09-11 | 2014-10-14 | Dow Corning Corporation | High voltage power semiconductor devices on SiC |
| US9337277B2 (en) | 2012-09-11 | 2016-05-10 | Dow Corning Corporation | High voltage power semiconductor device on SiC |
| US9165779B2 (en) | 2012-10-26 | 2015-10-20 | Dow Corning Corporation | Flat SiC semiconductor substrate |
| US9018639B2 (en) | 2012-10-26 | 2015-04-28 | Dow Corning Corporation | Flat SiC semiconductor substrate |
| US9738991B2 (en) | 2013-02-05 | 2017-08-22 | Dow Corning Corporation | Method for growing a SiC crystal by vapor deposition onto a seed crystal provided on a supporting shelf which permits thermal expansion |
| US9797064B2 (en) | 2013-02-05 | 2017-10-24 | Dow Corning Corporation | Method for growing a SiC crystal by vapor deposition onto a seed crystal provided on a support shelf which permits thermal expansion |
| US9017804B2 (en) | 2013-02-05 | 2015-04-28 | Dow Corning Corporation | Method to reduce dislocations in SiC crystal growth |
| US8940614B2 (en) | 2013-03-15 | 2015-01-27 | Dow Corning Corporation | SiC substrate with SiC epitaxial film |
| JP2015012306A (ja) * | 2013-06-26 | 2015-01-19 | 三菱電機株式会社 | 映像送受信システム、送信装置、および、受信装置 |
| US10002760B2 (en) | 2014-07-29 | 2018-06-19 | Dow Silicones Corporation | Method for manufacturing SiC wafer fit for integration with power device manufacturing technology |
| US9279192B2 (en) | 2014-07-29 | 2016-03-08 | Dow Corning Corporation | Method for manufacturing SiC wafer fit for integration with power device manufacturing technology |
| WO2017199913A1 (ja) * | 2016-05-18 | 2017-11-23 | 日本電気株式会社 | 送信装置、方法、プログラムおよび記録媒体 |
| JPWO2017199913A1 (ja) * | 2016-05-18 | 2019-03-22 | 日本電気株式会社 | 送信装置、方法およびプログラム |
| RU2715016C1 (ru) * | 2016-05-18 | 2020-02-21 | Нек Корпорейшн | Передающее устройство, способ, программа и носитель записи |
| CN114584844A (zh) * | 2020-11-30 | 2022-06-03 | 青岛海信宽带多媒体技术有限公司 | 一种rtp包丢包重传方法、装置及播放终端 |
| CN114584844B (zh) * | 2020-11-30 | 2023-09-22 | 青岛海信宽带多媒体技术有限公司 | 一种rtp包丢包重传方法、装置及智能机顶盒 |
| CN112416408A (zh) * | 2020-12-08 | 2021-02-26 | 金卡智能集团股份有限公司 | 固件升级方法、装置、设备及计算机可读存储介质 |
| CN116865915A (zh) * | 2023-07-06 | 2023-10-10 | 中国工商银行股份有限公司 | 数据包重传方法和装置、存储介质及电子装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4414311B2 (ja) | マルチメディアストリーミングサービスシステム及びその方法 | |
| US7164680B2 (en) | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications | |
| CN108141455B (zh) | 用于媒体数据的流式发射的期限信令 | |
| US7290058B2 (en) | Video mail server with reduced frame loss | |
| JP4949591B2 (ja) | ビデオ誤り回復方法 | |
| US20050254508A1 (en) | Cooperation between packetized data bit-rate adaptation and data packet re-transmission | |
| JP5207895B2 (ja) | 送信装置、受信装置、及び方法、プログラム | |
| EP2129126A1 (en) | Transmission apparatus, transmission method, and reception apparatus | |
| KR20040009928A (ko) | 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법 | |
| US8990407B2 (en) | Fast setup response prediction | |
| KR20100083233A (ko) | 휴대용 단말기에서 멀티미디어 파일 스트리밍을 위한 장치 및 방법 | |
| KR20060114080A (ko) | 멀티미디어 스트리밍 서비스 시스템 및 방법 | |
| Raman et al. | ITP: An image transport protocol for the internet | |
| JP2005051299A (ja) | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 | |
| CN105897687A (zh) | 一种传输数据的方法和设备 | |
| US20060291468A1 (en) | Selective re-transmission of lost multi-media data packets | |
| TWI401918B (zh) | 傳送指示接收器緩衝架構之緩衝參數信號的通訊方法 | |
| JP3871661B2 (ja) | マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法 | |
| TW202448163A (zh) | 從媒體應用向網路元件發信令通知媒體時序資訊 | |
| JP5031230B2 (ja) | データ送信装置及び方法 | |
| KR100624854B1 (ko) | 미디어 재전송 장치 및 방법 | |
| EP1647145A1 (en) | Method and system for uneven distribution of data | |
| JP2005136547A (ja) | 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム | |
| KR20080062692A (ko) | 스트림 녹화 방법, 장치 및 시스템 | |
| Handley | Applying real-time multimedia conferencing techniques to the Web |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060421 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060516 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060919 |