JP4173755B2 - データ伝送サーバ - Google Patents
データ伝送サーバ Download PDFInfo
- Publication number
- JP4173755B2 JP4173755B2 JP2003080653A JP2003080653A JP4173755B2 JP 4173755 B2 JP4173755 B2 JP 4173755B2 JP 2003080653 A JP2003080653 A JP 2003080653A JP 2003080653 A JP2003080653 A JP 2003080653A JP 4173755 B2 JP4173755 B2 JP 4173755B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- transmission
- data
- rate
- 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.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、データの伝送システムに関し、特に符号化メディアデータをベストエフォートのインターネット網や無線伝送路で伝送するサーバに関する。
【０００２】
【従来の技術】
従来からインターネット網等のベストエフォートの伝送路環境でストリーミングやビデオ電話等により、動画像データを伝送してきた。この動画像データの伝送には、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と呼ばれるリアルタイム性を重視したプロトコルが多く使われる。
【０００３】
しかし、ＵＤＰは、ＨＴＴＰ等で使用されるＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のように、クライアント側からのフィードバック情報を利用して送信レートを変化させる機構を備えていない。そのために、ＵＤＰのトラフィックが増加すると伝送路の帯域を占有する現象がしばしば起こっていた。
【０００４】
一方、ＵＤＰと同じくリアルタイム性を重視するプロトコルとして、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）がある。このＲＴＰは、一定の間隔でクライアント側からＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれる伝送品質をフィードバックする機構を備える。そのため、現在では、このＲＴＣＰを利用して送信レートを制御するシステムが増加している。
【０００５】
このような技術として、データをパケット化し、ネットワークに送信するサーバが、クライアントから送信される受信状況に基づいて送信レートを決定しデータを送信するデータ通信装置が提供されている（特許文献１参照。）。
【０００６】
しかしながら、ＲＴＣＰ等のフィードバック情報を利用して送信レートを制御するシステムでは、伝送している動画像の品質が著しく低下する虞があった。つまり、ＴＣＰやＲＴＰ等他のトラフィックが伝送路上に混在する状態で、サーバが送信レートを増加したとき、輻輳（ｃｏｎｇｅｓｔｉｏｎ）によってパケット損失が発生する。そのため、伝送している動画像の品質が著しく低下する。
【０００７】
【特許文献１】
特開２００１−１４４８０２号公報（要約書）。
【０００８】
【発明が解決しようとする課題】
本発明は、このような従来技術の問題に鑑みてなされたものである。すなわち、本発明が解決しようとする課題は、冗長符号を送信する前後において伝送路に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができるデータ伝送サーバを提供することである。
【０００９】
【課題を解決するための手段】
本発明は、上記課題を解決するために以下の手段を採用した。
【００１０】
本発明に係るサーバは、ネットワークを介して端末にデータを送信するデータ送信手段と、前記データの伝送誤りを抑制する冗長符号を送信する冗長符号送信手段と、前記端末からフィードバック情報を受信する受信手段と、前記フィードバック情報に基づいて送信レートの増減を判断する判断手段と、前記判断手段が送信レートを増加すると判断した場合に前記冗長符号の増加により送信レートを増加するレート増加手段とを備えることを特徴とする。
【００１１】
送信レートを増加する場合、例えば輻輳が発生する可能性がある。このような構成にすると、送信レートの増加分を冗長符号で構成することによって伝送路の変化を探査できる。そのため、送信レートを増加した時にデータ損失が発生したとしても、伝送するデータの伝送誤りを抑えることができる。
【００１２】
また、本発明のサーバは、前記冗長符号を送信する前後において伝送路の状況を比較する比較手段と、前記比較手段が伝送路の状況に変化がないと判断した場合に、増加した前記冗長符号に換えて前記データ送信部から送信するデータを増加させるデータ増加手段とをさらに備えてもよい。また、本発明のサーバは、前記比較手段が伝送路の状況が悪化したと判断した場合に前記冗長符号の送信を停止する停止手段をさらに備えてもよい。
【００１３】
このような構成にすると、冗長符号を送信する前後において伝送路の状況に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができる。一方、冗長符号を送信する前後において伝送路の状況に悪化したと判断した場合に、以前の状態、つまりレート増加分の冗長符号を除いた状態に戻すことができる。
【００１４】
また、本発明のサーバは、前記比較手段が前記フィードバック情報に基づいて冗長符号を送信する前後における伝送路の状況を比較してもよい。そして、フィードバック情報はパケット損失率、パケットが到着した間隔に関する情報、あるいはラウンドトリップ時間を含んでもよい。
【００１５】
また、冗長符号はパケット間のパリティ情報を含むパケット間誤り訂正方式であってもよいし、冗長符号はデータの優先度に基づいて順番に生成されてもよい。
【００１６】
このような構成にすると、伝送路においてパケット損失が発生したとしても、冗長化符号を利用して、損失したパケットを復元することが可能になる。
【００１７】
また、例えば、ＭＰＥＧデータにおけるイントラフレーム（Ｉフレーム）の冗長符号を優先的に生成したとする。イントラフレームを優先すると、送信レートを増加した時にパケット損失が発生した場合であっても画質劣化を最小限に抑えることができる。
【００１８】
また、本発明は上記のようなプログラムを読み取り可能な記憶媒体に記憶したものであってもよい。
【００１９】
【発明の実施の形態】
以下に図面を参照して、本発明の好適な実施の形態を説明する。
【００２０】
図１は本発明の原理を示す図であり、図２は本実施の形態における伝送システムを示すブロック図である。図３はＦＥＣパケットの構成図であり、図４はＲＴＰヘッダの構成図であり、図５はＦＥＣヘッダの構成図である。図６はＦＥＣパリティ情報の生成方法を示す図である。図７から図９はレート制御部の処理フローを示す図である。
＜伝送システムの原理図＞
図１を参照して、本発明の伝送システムの原理をメディアデータの流れとともに各構成要素の機能について説明する。
【００２１】
この伝送システムは、ネットワーク２０を介して接続されるサーバ１０とクライアント３０とを含む。ここでネットワーク２０は、たとえば組織内で運営されるＬＡＮ、あるいは不特定多数のネットワークが結合したインターネットなどを含み、その形態について特定するものではない。
【００２２】
まず、メディアデータが入力された後のサーバ１０側の処理を説明する。
【００２３】
サーバ１０は、符号化部１１、パケッタイザ１２、データ送信部１３、レート制御部１４、フィードバック受信部１５、スイッチ１６、冗長符号生成部１７、及び冗長符号送信部１８を含む。
【００２４】
符号化部１１は、入力されたメディアデータを符号化する。そして、パケッタイザ１２は、符号化データをパケット化し、ヘッダを付加する。データ送信部１３は、ネットワーク２０を経由してクライアント３０に向けて、パケットとしてメディアデータを送信する。
【００２５】
フィードバック受信部１５は、クラインアント３０からパケットとしてフィードバック情報を受信する。このフィードバック情報は、パケット損失率、ジッタ、及びパリティ情報の受信時刻などを含む。そして、このフィードバック情報は、伝送路上の輻輳（ｃｏｎｇｅｓｔｉｏｎ）を察知するために利用される。
【００２６】
そして、レート制御部１４は、受信したフィードバック情報をもとに、送信レートを決定する。その後、レート制御部１４は、決定された送信レートになるように、符号化部１１、スイッチ１６、冗長符号生成部１７を制御する。ここで、レート制御部１４は、送信レートを増加すると判断した場合には、スイッチ１６に送信レートの増加制御を指示する。
【００２７】
スイッチ１６は、パケッタイザ１２で生成された符号化データパケットを複製する。そして、スイッチ１６は、複製した符号化データパケットを冗長符号生成部１７に送る。この符号化データパケットは、冗長符号生成部１７内のバッファ（図示せず）に記憶される。
【００２８】
そして、冗長符号生成部１７は、バッファ内の符号化データパケットが一定量蓄積されると、冗長符号としてパリティ情報を生成する。冗長符号送信部１８は、このパリティ情報にヘッダを付加してパケットを生成する。そして、冗長符号送信部１８は、ネットワーク２０を経由してクライアント３０に向けてパリティ情報を含む冗長符号を送信する。
【００２９】
次に、クライアント３０側の処理を説明する。
【００３０】
クライアント３０は、データ受信部３１、データ復元部３２、復号部３３、表示部３４、フィードバック情報生成部３５、フィードバック情報送信部３６、及び冗長符号受信部３７を含む。
【００３１】
データ受信部３１は、ネットワーク２０を経由して、パケットとしてメディアデータを受信する。そして、データ受信部３１は、受信したメディアデータをデータ復元部３２に送る。また、データ受信部３１は、パケット損失やパケットの受信間隔（以下、ジッタという）を測定し、測定した情報をフィードバック情報生成部３５に送る。
【００３２】
データ復元部３２はメディアデータを復元する。つまり、データ復元部３２は、パケット損失があった場合には、冗長符号受信部３７が受信したパリティ情報から損失したパケットを復元する。そして、復号部３３は符号化されたパケットデータを復号する。その後、表示部３４は復号したメディアデータを動画像として表示する。
【００３３】
一方、冗長化符号受信部３７は、冗長符号送信部１８からパリティ情報を冗長符号として受信する。そして、冗長化符号受信部３７は、パリティ情報をデータ復元部３２に送る。また冗長符号受信部３７は、パケット損失やパケットの受信間隔（以下、ジッタという）を測定し、測定した情報をフィードバック情報生成部３５に送る。
【００３４】
フィードバック情報生成部３５は、データ受信部３１と冗長符号受信部３７とから送られる情報を受信する。この情報は、パケット損失率、ジッタ、またはパリティ情報の受信時刻などを含む。また、この情報をフィードバック情報という。このフィードバック情報は、伝送路上の輻輳（ｃｏｎｇｅｓｔｉｏｎ）を察知するために必要な情報である。フィードバック情報生成部３５はフィードバック情報からパケットを生成する。
【００３５】
そして、フィードバック送信部３６は、生成されたパケットを一定時間毎にサーバ１０に送信する。その後、サーバ１０はフィードバック受信部１５でフィードバック情報をパケットとして受信する。
【００３６】
次に、レート制御部１４における送信レートの増加制御について説明する。まず、冗長符号送信部１８は、送信レートの増加分を冗長符号として送信する。ここで、冗長符号送信部１８が冗長符号を送信したデータ量に比例して、サーバ１０の送信レートは増加する。一方、フィードバック情報受信部１５は、クライアント３０からフィードバック情報を受信する。
【００３７】
そして、レート制御部１４は、このフィードバック情報からネットワークの状況を判断する。つまり、レート制御部１４は、冗長符号を送信して送信レートを増加させたことによるネットワークの伝送状況の変化を判断する。この伝送状況は、伝送路上の輻輳の有無や輻輳の割合などを意味する。
【００３８】
レート制御部１４は、ネットワークの状況に変化がないと判断した場合、今まで送信した冗長符号を符号化メディアデータに置き換えて、データ送信部１３から符号化メディアデータを更に送信する。つまり、このような場合には、サーバ１０は、送信レートの増加により、より多くの符号化メディアデータを送信できる。
【００３９】
一方、レート制御部１４は、ネットワークの状況に変化があったと判断した場合、冗長符号の送信を停止する。このような場合には、サーバ１０が送信するメディアデータのデータ量は変化しない。
【００４０】
ところが、送信レートを増加したことにより輻輳が発生し、メディアデータのパケット損失が生じる場合がある。そのためにメディアデータの品質が劣化するおそれがある。このような場合でも、クライアント３０は、送信した冗長符号を利用して損失したパケットを復元できる。そのため、送信レートを増加したことによりパケット損失が生じたとしても、メディアデータの品質の劣化を抑えることができる。
【００４１】
本実施の形態において、冗長符号は、複数のパケット間でパリティ情報を付加することができるパケット間ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）方式とする。ＦＥＣパケットについては図６で説明する。
【００４２】
また、本伝送システムは、符号化メディアデータの符号化方式に従って優先順位をつけることがきる。そして、伝送システムは、その順位に従って符号化メディアデータのパリティ情報の生成頻度を制御してもよい。
【００４３】
このようにパリティ情報を生成すると、送信レートを増加した際に輻輳が発生したとしても、優先的にＦＥＣパケットを割り当てて復元することができる。そのため、メディアデータ内の優先的な情報から順番に劣化を抑えることができる。
＜ＦＥＣパケットの構成図＞
ＦＥＣパケット２１は、ＲＴＰヘッダ２２、ＦＥＣヘッダ２３、ＦＥＣリカバリ２４から構成される。また、ＲＴＰヘッダ２２は、ＲＴＰの制御用のデータである。そして、ＦＥＣヘッダ２３は、ＦＥＣの制御用のデータである。ＦＥＣリカバリ２４には、図６に示すＲＴＰパケットのパリティ情報が含まれる。
【００４４】
このＦＥＣパケットのフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣの定義（ＲＦＣ２７３３：“Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）に従う。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケットを設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケットを使って損失したパケットを復元する。
【００４５】
サーバ１０は、送信レートを増加するとき、メディアデータの送信に先駆けて、冗長符号としてＦＥＣパケット２１を送信する。そして、送信レートを増加した場合の伝送路の輻輳状態を察知するためＦＥＣパケット２１は利用される。
【００４６】
次に図４を参照して、ＲＴＰヘッダ２２の構成を説明する。ＲＴＰヘッダ２２は、ＶＥＲフィールド４０、Ｐフィールド４１、Ｘフィールド４２、ＣＣフィールド４３、Ｍフィールド４４、ＰＴフィールド４５、Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ フィールド４６、Ｔｉｍｅ Ｓｔａｍｐフィールド４７、ＳＳＲＣフィールド４８、及びＣＳＲＣフィールド４９から構成される。このＲＴＰヘッダ２２は、ＲＴＰ制御のため、ＦＥＣパケットやメディアデータの符号化パケットに付加される。
【００４７】
２ビットのＶＥＲフィールド４０は、ＲＴＰバージョン番号を示す。現在は、バージョン２である。各パケットはこのＶＥＲフィールドで始まる。Ｐフィールド４１は、１ビットのパディングビットを含む。このバディングビットには、パケットの最後がパディングされているかを示す。
【００４８】
Ｘフィールド４２は、１ビットのエクステンションビットを含む。このエクステンションビットは、ＲＴＰヘッダの直後に拡張ヘッダを持つ場合には「１」となる。ＣＣ（ＣＳＲＣカウント）フィールド４３は、ＣＳＲＣ（寄与送信元識別子）の数を示す。
【００４９】
Ｍフィールド４４は、１ビットのマーカービットを含む。このマーカービットは、アプリケーションデータの境界を示す。７ビットのＰＴフィールド４５は、ペイロードタイプのアプリケーションデータの符号化方式を示す。１６ビットのＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒフィールド４６は、パケットのシーケンス番号を含む。このシーケンス番号は、パケットの送信順に割り振られる。
【００５０】
Ｔｉｍｅ Ｓｔａｍｐフィールド４７は３２ビットの値であり、このパケットの先頭バイトが送信された時刻を示す。ＳＳＲＣ（同期送信元識別子）フィールド４８は、３２ビットの値であり、パケットの送信元を示す。ＣＳＲＣ（寄与送信元識別子）フィールド４９は、混合されたストリームの同期を示す。このＣＳＲＣフィールド４９は可変長である。
【００５１】
次に図５を参照して、ＦＥＣヘッダの構成を説明する。ＦＥＣヘッダ２２は、ＳＮ Ｂａｓｅフィールド５０、Ｌｅｎｇｔｈ ｒｅｃｏｖｅｒｙフィールド５１、ＰＴ ｒｅｃｏｖｅｒｙフィールド５３、Ｍａｓｋフィールド５４、及びＴＳ ｒｅｃｏｖｅｒｙフィールド５５から構成される。ＦＥＣヘッダは、ＦＥＣリカバリのパリティ情報を制御するために付加される。
【００５２】
ＳＮ Ｂａｓｅフィールド５０は、ＦＥＣ処理の対象となるＲＴＰパケットのシーケンス番号のオフセットを示す。Ｌｅｎｇｔｈ ｒｅｃｏｖｅｒｙフィールド５１は、ＲＴＰパケットの長さのパリティ情報を示す。Ｅフィールド５２は、ヘッダの拡張を示す。ＰＴ ｒｅｃｏｖｅｒｙフィールド５３は、ペイロードタイプのパリティ情報を示す。Ｍａｓｋフィールド５４は、ＦＥＣ処理の対象となるＲＴＰパケットの番号を示す。ＴＳ ｒｅｃｏｖｅｒｙフィールド５５は、タイムスタンプのパリティ情報を示す。
＜伝送システムのブロック図＞
本実施の形態として、ＭＰＥＧ−４の動画像符号データをＲＴＰ・ＲＴＣＰを用いて伝送する場合について図２を参照して説明する。図２は本実施の形態の伝送システムのブロック図である。
【００５３】
この伝送システムは、インターネット網２００を介して接続されるサーバ１００とクライアント３００との間で、ＲＴＰ・ＲＴＣＰを用いてデータを伝送する。なお、ＲＴＣＰには、サーバ１００からクライアント３００に送信されるＳｅｎｄｅｒ Ｒｅｐｏｒｔ（ＳＲ）と、クライアント３００からサーバ１００に送信されるＲｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ（ＲＲ）がある。
【００５４】
まず、動画像データが入力された後のサーバ１００側の処理を説明する。
【００５５】
サーバ１００は、ＭＰＥＧ−４符号化部１０１、パケッタイザ１０２、ＲＴＰ送信部１０３、レート制御部１０４、ＳＲ送信部１０５、ＲＲ受信部１０９、スイッチ１０６、ＦＥＣ生成部１０７、ＦＥＣ送信部１０８、及びＲＲ送信部１０９を含む。
【００５６】
ＭＰＥＧ−４符号化部１０１は、入力された動画像データを符号化する。
【００５７】
そして、パケッタイザ１０２は、符号化されたデータをパケット化し、図４に示すＲＴＰヘッダを付加する。
【００５８】
ＲＴＰ送信部１０３は、インターネット網２００を経由してクライアント３００に向けて、符号化データパケットとして、動画像データを送信する。
【００５９】
次に、クライアント３００側の処理を説明する。クライアント３００は、ＲＴＰ受信部３０１、データ復元部３０２、ＭＰＥＧ−４復号部３０３、表示部３０４、フィードバック情報生成部３０５、ＳＲ受信部３０６、ＦＥＣ受信部３０７、及びＲＲ送信部３０８を含む。
【００６０】
ＲＴＰ受信部３０１は、インターネット網２００を経由して、符号化データパケットを受信する。そして、ＲＴＰ受信部３０１は、受信した符号化データパケットをデータ復元部３０２に送る。また、ＲＴＰ受信部３０１は、図４に示すＲＴＰヘッダのシーケンス番号４６を参照して、パケット損失やジッタを測定し、測定した情報をフィードバック情報生成部３０５に送る。
【００６１】
データ復元部３０２は符号化データパケットを復元する。つまり、パケット損失があった場合には、データ復元部３０２は損失したパケットを復元する。そして、ＭＰＥＧ−４復号部３０３は符号化されたパケットデータを復号する。その後、表示部３０４は復号したデータを動画像として表示する。
【００６２】
次にフィードバック情報の生成、送信、及び受信、並びに送信レートの制御について説明する。本実施の形態では、サーバ１００はＲＲ受信部１０９でＲＲパケットを受信したときに送信レートを制御する。
【００６３】
まずクライアント３００は、パケット損失率、ジッタ情報、及びＳＲパケット情報をもとに、フィードバック情報生成部３０５で、ＲＲパケットを生成する。このパケット損失率とジッタ情報は、ＦＥＣパケット２１を受信するＦＥＣ受信部３０７とＲＴＰパケット２１を受信するＲＴＰ受信部３０１とから送られる。なお、ＳＲパケット情報は、サーバ１００から一定時間毎に送信されるＳＲパケットを受信した時刻等である。そして、この受信時刻は、サーバ１００側でランドトリップ時間を算出する際に用いられる。ＳＲパケット及びＲＲパケットのフォーマットは、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）１８８９に記載のフォーマットに従う。このＲＦＣ１８８９は、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で記載されている。
【００６４】
そして、クライアント３００は、フィードバック情報として、ＲＲパケットをサーバ１００に送信する。
【００６５】
一方、サーバ１００は、ＲＲ受信部１０９でＲＲパケットを受信した場合、フィードバック情報をもとに、ラウンドトリップ時間を計算する。このラウンドトリップ時間は、サーバ１００側でのＳＲパケットの送信時刻とＲＲパケットの受信時刻、及びクライアント３００側でのＳＲパケット受信からＲＲパケット送信までの時間から計算できる。
【００６６】
本実施の形態では、レート制御部１０４は、このラウンドトリップ時間とパケット損失率に基づいて送信レートを制御する。
【００６７】
次に、パケット損失率とラウンドトリップ時間に従ったレート制御部１０４での送信レートの制御について説明する。レート制御部１０４は、パケット損失率が所定の閾値（例えば、５％）を越えた場合、またはラウンドトリップ時間が所定の閾値（例えば、２００ｍｓ）を越えた場合には、送信レートを減少する。
【００６８】
一方、レート制御部１０４は、パケット損失率とラウンドトリップ時間の両方が、閾値以下の場合には、送信レートを増加する。
【００６９】
また、レート制御部１０４は、パケット損失率が閾値以下でラウンドトリップ時間が閾値を越えた場合には、送信レートを固定する。つまりレート制御部１０４は、送信レートを現状のままにする。
【００７０】
次に、レート制御部１０４が送信レートを増加すると判断した場合の処理について説明する。レート制御部１０４は、伝送路上の輻輳の割合をもとに判断する。
【００７１】
まず、サーバ１００は、送信レートの増加分として冗長符号を送信する。ここで、送信される冗長符号のフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣ（ＲＦＣ２７３３：“Ａｎ ＲＴＰ ＰａｙｌｏａｄＦｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）を利用する。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケットを設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケットを使って損失したパケットを復元することができる。また、ＲＦＣ２７３３では、最低２４パケットのＲＴＰパケットに１パケットの割合でＦＥＣパケットを付加することを推奨している。
【００７２】
そして、レート制御部１０４は、送信レートを増加する判断をした後、ＦＥＣパケットの生成をスイッチ１０６に指示する。スイッチ１０６は、パケッタイザ１０２で生成される符号化データパケットを複製する。そして、スイッチ１０６はＦＥＣ生成部１０７内のＦＥＣ生成用バッファ（図示せず）に複製したパケットを送る。
【００７３】
ＦＥＣ生成部１０７は、複製したＦＥＣパケットがＦＥＣ生成用バッファに所定量（例えば２４パケット）蓄積されると、パリティ情報を生成する。また、レート制御部１０４は、符号化データパケットについて優先度を与え、ＦＥＣ生成部１０７に指示する。
【００７４】
ＦＥＣ生成部１０７は、この優先度に従ってパリティ情報を生成する。この優先度は、例えば符号化データパケットのＩフレームとＰフレームの割合を７対３とすることができる。ここで各パケットがＩ・Ｐフレームのどちらを含むかは、ＭＰＥＧ−４のビデオパケットヘッダのヘッダエクステンションコード内のｖｏｐ＿ｃｏｄｉｎｇ＿ｔｙｐｅを参照することで認識できる。また、このパリティ情報は、図６に示すように、優先度に従って選択された各ＲＴＰパケットについて、ビット単位で排他的論理和を求めることにより生成できる。
【００７５】
そして、ＦＥＣ送信部１０８は、生成されたパリティ情報に図５に示すようなＦＥＣヘッダ２３を付加する。さらにＦＥＣ送信部１０８は、ＲＴＰヘッダ２２を付加して、図４に示すようなＦＥＣパケット２１を生成する。
【００７６】
なお、符号化データバケットの数は、最大でデータパケットと同数である。その場合には、データパケットと同一のＦＥＣパケット２１が生成され、同一パケットが２度送信される。
【００７７】
一方、クライアント３００側では、図２に示すＦＥＣ受信部３０７でＦＥＣパケット２１を受信し、データ復元部３０２に送る。
【００７８】
データ復元部３０２は、ＦＥＣパケット２１の中から優先度に応じて選択されたパケットの損失を判断する。ここで、データ復元部３０２は、損失したパケットが「０」、または「２パケット」以上であると判断した場合は、データ復元処理を行わずに復号部３０３に送る。
【００７９】
一方、データ復元部３０２は、損失したパケットが「１パケット」であると判断した場合には、ＦＥＣパケット２１を使って、損失したパケットを復元する。その後、データ復元部３０２は、符号化データをＭＰＥＧ−４復号部３０３に送る。
【００８０】
ＲＴＰ受信部３０１は、受信したＲＴＰパケットの損失率を算出し、フィードバック情報生成部３０５に送る。また、ＦＥＣ受信部３０７は、受信したＦＥＣパケット２１の損失率を算出し、フィードバック情報生成部３０５に送る。
【００８１】
フィードバック情報生成部３０５は、ＲＲパケットを生成し、ＲＲ送信部３０８からサーバ１００にＲＲパケットを送信する。
【００８２】
次に、サーバ１００側では、ＲＲ受信部１０９で受信したＲＲパケットからパケット損失率を取得し、ラウンドトリップ時間を計算する。
【００８３】
そして、レート制御部１０４は、パケット損失率とラウンドトリップ時間を使って、レートの増減の判断を行う。
【００８４】
レート制御部１０４は、送信レートを増加すると判断した場合には、ＦＥＣパケットの生成を中止することをスイッチ１０６に対して指示する。ここで、サーバ１００は、ＦＥＣパケット２１の送信を停止する。
【００８５】
また、レート制御部１０４は、ＦＥＣパケット２１の増加分に相当する符号化データを送信することをＭＰＥＧ−４符号化部１０１に対して指示する。ここで、ＭＰＥＧ−４符号化部１０１は符号化レート増加するため、サーバ１００は増加した送信レートでＭＰＥＧ−４データを送信することができる。
【００８６】
一方、レート制御部１０４は、送信レートを減少すると判断した場合には、符号化パケットデータをＦＥＣ生成部１０７に送ることを中止することをスイッチ１０６に対して指示する。この場合には、レート制御部１０４は、符号化レート減少をＭＰＥＧ−４符号化部１０１に指示しない。
＜パリティ情報の生成方法＞
図６を参照して、ＲＴＰパケットのパリティ情報を生成する方法について説明する。
【００８７】
サーバは、損失したパケットを復元するため、パケット化されたＭＰＥＧ−４データについてのパリティ情報を生成する。このパリティ情報は、サーバ１００のＦＥＣ生成部１０７で生成される。
【００８８】
ここで生成されたパリティ情報は、ＦＥＣパケット２１として、クライアントに送信される。このＦＥＣパケット２１のフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣ（ＲＦＣ２７３３：“Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）に従う。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケット２１を設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケット２１を使って損失したパケットを復元する。
【００８９】
そして、ＦＥＣパケット２１を受信したクライアントは、パリティ情報をもとに、ＭＰＥＧ−４データを復元する。
【００９０】
本実施の形態では、ＦＥＣパケット２１は、ＲＴＰパケット１からＲＴＰパケット４についてのパリティ情報を有する。
【００９１】
ＦＥＣパケット２１の１ビット目（Ｆ１）は、各ＲＴＰパケットの１ビット目（ａ１、ｂ１、ｃ１、ｄ１）の排他的論理和を求めることにより生成できる。同様にして、それぞれのビット毎にＲＴＰパケットの排他的論理和をとることにより、ＦＥＣパケット２１は生成できる。
【００９２】
ここで、ＲＴＰパケット３が損失した例について説明する。
クライアントは、受信したＲＴＰパケット（ａ１、ｂ１、ｄ１）とＦＥＣパケット（Ｆ１）を使って、排他的論理和が一致するようにすることによって、ＲＴＰパケット３（ｃ１）を復元することができる。同様にして、クライアントはＲＴＰパケット３（ｃ２〜ｃ５）を復元できる。
＜レート制御部の処理フロー＞
図７を参照して、レート制御部の処理を説明する。図７は、レート制御部１０４の処理フローを示す図である。
【００９３】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ７０１）。そして、レート制御部１０４は、パケット損失率が閾値１より小さいか、ランドトリップ時間が閾値２より小さいかを判断する（Ｓ７０２）。
【００９４】
Ｓ７０２で、レート制御部１０４は、パケット損失率及びランドトリップ時間がともに閾値より小さいと判断した場合、スイッチ１０６を「ＯＮ」にする（Ｓ７０３）。ここで、スイッチ１０６を「ＯＮ」にするとは、ＦＥＣパケット２１を生成する制御を意味する。
【００９５】
そして、レート制御部１０４は、ＦＥＣ生成部１０７に対して送信レートの上昇幅、優先比率を通知する（Ｓ７０４）。そして、ＦＥＣ生成部１０７は、ＦＥＣパケット２１を生成する（Ｓ７０５）。そして、ＦＥＣ送信部１０８は、ＦＥＣパケット２１をクライアント３００へ送信する（Ｓ７０６）。
【００９６】
一方Ｓ７０２で、パケット損失率及びランドトリップ時間の一方または両方が閾値以上であると判断した場合、レート制御部１０４は、符号化レートを固定または減少させる（Ｓ７０７）。
【００９７】
次に図８を参照して、ＦＥＣパケット２１送信後に伝送路の状況に変化がなかった場合のレート制御部の処理を説明する。図８は、レート制御部１０４の処理フローを示す図である。
【００９８】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ８０１）。このフィードバック情報は、ＦＥＣパケット２１により送信レートが増加した場合の輻輳の割合に関する情報を含む。
【００９９】
そして、レート制御部１０４は、パケット損失率が閾値１より小さいか、ランドトリップ時間が閾値２より小さいかを判断する（Ｓ８０２）。
【０１００】
Ｓ８０２で、レート制御部１０４は、パケット損失率及びランドトリップ時間がともに閾値より小さいと判断した場合、スイッチ１０６を「ＯＦＦ」にする（Ｓ８０３）。スイッチ１０６は、ＦＥＣパケット２１の生成を中止する。つまり、サーバ１００はＦＥＣパケット２１の送信を停止する。
【０１０１】
そしてレート制御部１０４は、ＭＰＥＧ−４生成部１０１に符号化レートの上昇を指示する（Ｓ８０４）。ここで、ＭＰＥＧ−４符号化部１０１は符号化レート増加する。そして、サーバ１００は増加した送信レートでＭＰＥＧ−４データを送信することができる。
【０１０２】
一方Ｓ８０２で、パケット損失率及びランドトリップ時間の一方または両方が閾値以上であると判断した場合、レート制御部１０４は、符号化レートを固定または減少させる（Ｓ８０５）。
【０１０３】
次に図９を参照して、ＦＥＣパケット２１送信後に伝送路の状況に変化があった場合のレート制御部の処理を説明する。
【０１０４】
図９は、レート制御部１０４の処理フローを示す図である。
【０１０５】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ９０１）。そして、レート制御部１０４は、パケット損失率が閾値１より大きいか、またはランドトリップ時間が閾値２より大きいかを判断する（Ｓ９０２）。
【０１０６】
Ｓ９０２で、レート制御部１０４は、パケット損失率、またはランドトリップ時間の一方が閾値より大きいいと判断した場合、スイッチ１０６を「ＯＦＦ」にする（Ｓ９０３）。ここでスイッチ１０６は、ＦＥＣパケットの生成を中止する。つまり、サーバ１００はＦＥＣパケット２１の送信を停止する。
【０１０７】
一方Ｓ９０２で、パケット損失率及びランドトリップ時間の両方が閾値より大きいと判断した場合、レート制御部１０４は、符号化レートを固定または上昇させる（Ｓ９０４）。
＜実施形態の効果＞
本実施の形態に従うと、送信レートを増加した時にデータ損失が発生したとしても、伝送するデータの伝送誤りを抑えることができる。
【０１０８】
また、冗長符号を送信する前後において伝送路の状況に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができる。一方、冗長符号を送信する前後において伝送路の状況に悪化したと判断した場合に、以前の状態、つまりレート増加分の冗長符号を除いた状態に戻すことができる。
【０１０９】
また、伝送路においてパケット損失が発生したとしても、冗長化符号を利用して、損失したパケットを復元することが可能になる。
【０１１０】
さらに、例えば、ＭＰＥＧデータにおけるイントラフレーム（Ｉフレーム）の冗長符号を優先的に生成したとする。イントラフレームを優先すると、送信レートを増加した時にパケット損失が発生した場合であっても画質劣化を最小限に抑えることができる。
＜コンピュータ読み取り可能な記憶媒体＞
上記実施の形態のいずれかの処理をコンピュータに実行させるプログラムをコンピュータが読み取り可能な記憶媒体に記録することができる。そして、コンピュータに、この記憶媒体のプログラムを読み込ませて実行させることにより、上記実施の形態に示したシステムを提供することができる。
【０１１１】
ここで、コンピュータが読み取り可能な記憶媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記憶媒体をいう。このような記憶媒体のうちコンピュータから取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ＤＡＴ、８ｍｍテープ、メモリカード等がある。
【０１１２】
また、コンピュータに固定された記録媒体として、ハードディスクやＲＯＭ（リード・オンリー・メモリ）等がある。
【０１１３】
なお、上記実施の形態は本発明の範囲をなんら限定するものではなく、当業者が理解できる範囲において適宜、各種の変形の態様があり得る。
＜その他＞
さらに、本実施の形態は以下の発明を開示する。
（付記１）ネットワークを介して端末にデータを送信するデータ送信手段と、
前記データの伝送誤りを抑制する冗長符号を送信する冗長符号送信手段と、
前記端末からフィードバック情報を受信する受信手段と、
前記フィードバック情報に基づいて送信レートの増減を判断する判断手段と、
前記判断手段が送信レートを増加すると判断した場合に前記冗長符号の増加により送信レートを増加するレート増加手段とを備えることを特徴とするサーバ。
（付記２）前記冗長符号を送信する前後において伝送路の状況を比較する比較手段と、
前記比較手段が伝送路の状況に変化がないと判断した場合に、増加した前記冗長符号に換えて前記データ送信部から送信するデータを増加させるデータ増加手段とをさらに備える付記１に記載のサーバ。
（付記３）前記比較手段が伝送路の状況が悪化したと判断した場合に前記冗長符号の送信を停止する停止手段をさらに備える付記２に記載のサーバ。
（付記４）前記比較手段は前記フィードバック情報に基づいて冗長符号を送信する前後における伝送路の状況を比較する付記２または３に記載のサーバ。
（付記５）前記フィードバック情報はパケット損失率を含む付記４に記載のサーバ。
（付記６）前記フィードバック情報はパケットが到着した間隔に関する情報を含む付記４に記載のに記載のサーバ。
（付記７）前記フィードバック情報はラウンドトリップ時間を含む請求項４乃至６のいずれかに記載のに記載のサーバ。
（付記８）前記冗長符号はパケット間のパリティ情報を含むパケット間誤り訂正方式である付記４に記載のサーバ。
（付記９）前記冗長符号はデータの優先度に基づいて順番に生成される付記４に記載のサーバ。
【０１１４】
【発明の効果】
以上で説明したように、本発明は冗長符号を送信する前後において伝送路に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができるデータ伝送サーバを提供することができる。
【図面の簡単な説明】
【図１】本発明の原理を示す図である。
【図２】本実施の形態における伝送システムを示すブロック図である。
【図３】ＦＥＣパケットの構成図である。
【図４】ＲＴＰヘッダの構成図である。
【図５】ＦＥＣヘッダの構成図である。
【図６】ＦＥＣパリティ情報の生成方法を示す図である。
【図７】レート制御部の処理フローを示す図である。
【図８】レート制御部の処理フローを示す図である。
【図９】レート制御部の処理フローを示す図である。
【符号の説明】
１０、１００…サーバ
１１…符号化部
１２…パケッタイザ
１０２…パケッタイザ
１３…データ送信部
１４、１０４…レート制御部
１５…フィードバック情報受信部
１６、１０６…スイッチ
１７…冗長符号生成部
１８…冗長符号送信部
２０…ネットワーク
２１…RTPパケット
２２…RTPヘッダ
２３…FECヘッダ
２４…FECリカバリ
３０、３００…クライアント
３１…データ受信部
３２、３０２…データ復元部
３３…復号部
３４、３０４…表示部
３５、３０５…フィードバック情報生成部
３６…フィードバック送信部
３７…冗長符号受信部
４１…V
４２…P
４３…X
４４…C
４５…M
４５…PT
４６…Sequence Number
４７…Time Stamp
４８…SSRC
４９…CSRC
５１…SN base
５２…Length recovery
５３…E
５４…PT recovery
５５…TS recovery
１０１…MPEG-4符号化部
１０３…RTP送信部
１０５…SR送信部
１０７…FEC生成部
１０８…FEC送信部
１０９…RR受信部
２００…インターネット網
３０１…RTP受信部
３０３…MPEG-4復号部
３０６…SR受信部
３０７…FEC受信部
３０８…RR送信部
【発明の属する技術分野】
本発明は、データの伝送システムに関し、特に符号化メディアデータをベストエフォートのインターネット網や無線伝送路で伝送するサーバに関する。
【０００２】
【従来の技術】
従来からインターネット網等のベストエフォートの伝送路環境でストリーミングやビデオ電話等により、動画像データを伝送してきた。この動画像データの伝送には、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と呼ばれるリアルタイム性を重視したプロトコルが多く使われる。
【０００３】
しかし、ＵＤＰは、ＨＴＴＰ等で使用されるＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のように、クライアント側からのフィードバック情報を利用して送信レートを変化させる機構を備えていない。そのために、ＵＤＰのトラフィックが増加すると伝送路の帯域を占有する現象がしばしば起こっていた。
【０００４】
一方、ＵＤＰと同じくリアルタイム性を重視するプロトコルとして、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）がある。このＲＴＰは、一定の間隔でクライアント側からＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれる伝送品質をフィードバックする機構を備える。そのため、現在では、このＲＴＣＰを利用して送信レートを制御するシステムが増加している。
【０００５】
このような技術として、データをパケット化し、ネットワークに送信するサーバが、クライアントから送信される受信状況に基づいて送信レートを決定しデータを送信するデータ通信装置が提供されている（特許文献１参照。）。
【０００６】
しかしながら、ＲＴＣＰ等のフィードバック情報を利用して送信レートを制御するシステムでは、伝送している動画像の品質が著しく低下する虞があった。つまり、ＴＣＰやＲＴＰ等他のトラフィックが伝送路上に混在する状態で、サーバが送信レートを増加したとき、輻輳（ｃｏｎｇｅｓｔｉｏｎ）によってパケット損失が発生する。そのため、伝送している動画像の品質が著しく低下する。
【０００７】
【特許文献１】
特開２００１−１４４８０２号公報（要約書）。
【０００８】
【発明が解決しようとする課題】
本発明は、このような従来技術の問題に鑑みてなされたものである。すなわち、本発明が解決しようとする課題は、冗長符号を送信する前後において伝送路に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができるデータ伝送サーバを提供することである。
【０００９】
【課題を解決するための手段】
本発明は、上記課題を解決するために以下の手段を採用した。
【００１０】
本発明に係るサーバは、ネットワークを介して端末にデータを送信するデータ送信手段と、前記データの伝送誤りを抑制する冗長符号を送信する冗長符号送信手段と、前記端末からフィードバック情報を受信する受信手段と、前記フィードバック情報に基づいて送信レートの増減を判断する判断手段と、前記判断手段が送信レートを増加すると判断した場合に前記冗長符号の増加により送信レートを増加するレート増加手段とを備えることを特徴とする。
【００１１】
送信レートを増加する場合、例えば輻輳が発生する可能性がある。このような構成にすると、送信レートの増加分を冗長符号で構成することによって伝送路の変化を探査できる。そのため、送信レートを増加した時にデータ損失が発生したとしても、伝送するデータの伝送誤りを抑えることができる。
【００１２】
また、本発明のサーバは、前記冗長符号を送信する前後において伝送路の状況を比較する比較手段と、前記比較手段が伝送路の状況に変化がないと判断した場合に、増加した前記冗長符号に換えて前記データ送信部から送信するデータを増加させるデータ増加手段とをさらに備えてもよい。また、本発明のサーバは、前記比較手段が伝送路の状況が悪化したと判断した場合に前記冗長符号の送信を停止する停止手段をさらに備えてもよい。
【００１３】
このような構成にすると、冗長符号を送信する前後において伝送路の状況に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができる。一方、冗長符号を送信する前後において伝送路の状況に悪化したと判断した場合に、以前の状態、つまりレート増加分の冗長符号を除いた状態に戻すことができる。
【００１４】
また、本発明のサーバは、前記比較手段が前記フィードバック情報に基づいて冗長符号を送信する前後における伝送路の状況を比較してもよい。そして、フィードバック情報はパケット損失率、パケットが到着した間隔に関する情報、あるいはラウンドトリップ時間を含んでもよい。
【００１５】
また、冗長符号はパケット間のパリティ情報を含むパケット間誤り訂正方式であってもよいし、冗長符号はデータの優先度に基づいて順番に生成されてもよい。
【００１６】
このような構成にすると、伝送路においてパケット損失が発生したとしても、冗長化符号を利用して、損失したパケットを復元することが可能になる。
【００１７】
また、例えば、ＭＰＥＧデータにおけるイントラフレーム（Ｉフレーム）の冗長符号を優先的に生成したとする。イントラフレームを優先すると、送信レートを増加した時にパケット損失が発生した場合であっても画質劣化を最小限に抑えることができる。
【００１８】
また、本発明は上記のようなプログラムを読み取り可能な記憶媒体に記憶したものであってもよい。
【００１９】
【発明の実施の形態】
以下に図面を参照して、本発明の好適な実施の形態を説明する。
【００２０】
図１は本発明の原理を示す図であり、図２は本実施の形態における伝送システムを示すブロック図である。図３はＦＥＣパケットの構成図であり、図４はＲＴＰヘッダの構成図であり、図５はＦＥＣヘッダの構成図である。図６はＦＥＣパリティ情報の生成方法を示す図である。図７から図９はレート制御部の処理フローを示す図である。
＜伝送システムの原理図＞
図１を参照して、本発明の伝送システムの原理をメディアデータの流れとともに各構成要素の機能について説明する。
【００２１】
この伝送システムは、ネットワーク２０を介して接続されるサーバ１０とクライアント３０とを含む。ここでネットワーク２０は、たとえば組織内で運営されるＬＡＮ、あるいは不特定多数のネットワークが結合したインターネットなどを含み、その形態について特定するものではない。
【００２２】
まず、メディアデータが入力された後のサーバ１０側の処理を説明する。
【００２３】
サーバ１０は、符号化部１１、パケッタイザ１２、データ送信部１３、レート制御部１４、フィードバック受信部１５、スイッチ１６、冗長符号生成部１７、及び冗長符号送信部１８を含む。
【００２４】
符号化部１１は、入力されたメディアデータを符号化する。そして、パケッタイザ１２は、符号化データをパケット化し、ヘッダを付加する。データ送信部１３は、ネットワーク２０を経由してクライアント３０に向けて、パケットとしてメディアデータを送信する。
【００２５】
フィードバック受信部１５は、クラインアント３０からパケットとしてフィードバック情報を受信する。このフィードバック情報は、パケット損失率、ジッタ、及びパリティ情報の受信時刻などを含む。そして、このフィードバック情報は、伝送路上の輻輳（ｃｏｎｇｅｓｔｉｏｎ）を察知するために利用される。
【００２６】
そして、レート制御部１４は、受信したフィードバック情報をもとに、送信レートを決定する。その後、レート制御部１４は、決定された送信レートになるように、符号化部１１、スイッチ１６、冗長符号生成部１７を制御する。ここで、レート制御部１４は、送信レートを増加すると判断した場合には、スイッチ１６に送信レートの増加制御を指示する。
【００２７】
スイッチ１６は、パケッタイザ１２で生成された符号化データパケットを複製する。そして、スイッチ１６は、複製した符号化データパケットを冗長符号生成部１７に送る。この符号化データパケットは、冗長符号生成部１７内のバッファ（図示せず）に記憶される。
【００２８】
そして、冗長符号生成部１７は、バッファ内の符号化データパケットが一定量蓄積されると、冗長符号としてパリティ情報を生成する。冗長符号送信部１８は、このパリティ情報にヘッダを付加してパケットを生成する。そして、冗長符号送信部１８は、ネットワーク２０を経由してクライアント３０に向けてパリティ情報を含む冗長符号を送信する。
【００２９】
次に、クライアント３０側の処理を説明する。
【００３０】
クライアント３０は、データ受信部３１、データ復元部３２、復号部３３、表示部３４、フィードバック情報生成部３５、フィードバック情報送信部３６、及び冗長符号受信部３７を含む。
【００３１】
データ受信部３１は、ネットワーク２０を経由して、パケットとしてメディアデータを受信する。そして、データ受信部３１は、受信したメディアデータをデータ復元部３２に送る。また、データ受信部３１は、パケット損失やパケットの受信間隔（以下、ジッタという）を測定し、測定した情報をフィードバック情報生成部３５に送る。
【００３２】
データ復元部３２はメディアデータを復元する。つまり、データ復元部３２は、パケット損失があった場合には、冗長符号受信部３７が受信したパリティ情報から損失したパケットを復元する。そして、復号部３３は符号化されたパケットデータを復号する。その後、表示部３４は復号したメディアデータを動画像として表示する。
【００３３】
一方、冗長化符号受信部３７は、冗長符号送信部１８からパリティ情報を冗長符号として受信する。そして、冗長化符号受信部３７は、パリティ情報をデータ復元部３２に送る。また冗長符号受信部３７は、パケット損失やパケットの受信間隔（以下、ジッタという）を測定し、測定した情報をフィードバック情報生成部３５に送る。
【００３４】
フィードバック情報生成部３５は、データ受信部３１と冗長符号受信部３７とから送られる情報を受信する。この情報は、パケット損失率、ジッタ、またはパリティ情報の受信時刻などを含む。また、この情報をフィードバック情報という。このフィードバック情報は、伝送路上の輻輳（ｃｏｎｇｅｓｔｉｏｎ）を察知するために必要な情報である。フィードバック情報生成部３５はフィードバック情報からパケットを生成する。
【００３５】
そして、フィードバック送信部３６は、生成されたパケットを一定時間毎にサーバ１０に送信する。その後、サーバ１０はフィードバック受信部１５でフィードバック情報をパケットとして受信する。
【００３６】
次に、レート制御部１４における送信レートの増加制御について説明する。まず、冗長符号送信部１８は、送信レートの増加分を冗長符号として送信する。ここで、冗長符号送信部１８が冗長符号を送信したデータ量に比例して、サーバ１０の送信レートは増加する。一方、フィードバック情報受信部１５は、クライアント３０からフィードバック情報を受信する。
【００３７】
そして、レート制御部１４は、このフィードバック情報からネットワークの状況を判断する。つまり、レート制御部１４は、冗長符号を送信して送信レートを増加させたことによるネットワークの伝送状況の変化を判断する。この伝送状況は、伝送路上の輻輳の有無や輻輳の割合などを意味する。
【００３８】
レート制御部１４は、ネットワークの状況に変化がないと判断した場合、今まで送信した冗長符号を符号化メディアデータに置き換えて、データ送信部１３から符号化メディアデータを更に送信する。つまり、このような場合には、サーバ１０は、送信レートの増加により、より多くの符号化メディアデータを送信できる。
【００３９】
一方、レート制御部１４は、ネットワークの状況に変化があったと判断した場合、冗長符号の送信を停止する。このような場合には、サーバ１０が送信するメディアデータのデータ量は変化しない。
【００４０】
ところが、送信レートを増加したことにより輻輳が発生し、メディアデータのパケット損失が生じる場合がある。そのためにメディアデータの品質が劣化するおそれがある。このような場合でも、クライアント３０は、送信した冗長符号を利用して損失したパケットを復元できる。そのため、送信レートを増加したことによりパケット損失が生じたとしても、メディアデータの品質の劣化を抑えることができる。
【００４１】
本実施の形態において、冗長符号は、複数のパケット間でパリティ情報を付加することができるパケット間ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）方式とする。ＦＥＣパケットについては図６で説明する。
【００４２】
また、本伝送システムは、符号化メディアデータの符号化方式に従って優先順位をつけることがきる。そして、伝送システムは、その順位に従って符号化メディアデータのパリティ情報の生成頻度を制御してもよい。
【００４３】
このようにパリティ情報を生成すると、送信レートを増加した際に輻輳が発生したとしても、優先的にＦＥＣパケットを割り当てて復元することができる。そのため、メディアデータ内の優先的な情報から順番に劣化を抑えることができる。
＜ＦＥＣパケットの構成図＞
ＦＥＣパケット２１は、ＲＴＰヘッダ２２、ＦＥＣヘッダ２３、ＦＥＣリカバリ２４から構成される。また、ＲＴＰヘッダ２２は、ＲＴＰの制御用のデータである。そして、ＦＥＣヘッダ２３は、ＦＥＣの制御用のデータである。ＦＥＣリカバリ２４には、図６に示すＲＴＰパケットのパリティ情報が含まれる。
【００４４】
このＦＥＣパケットのフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣの定義（ＲＦＣ２７３３：“Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）に従う。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケットを設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケットを使って損失したパケットを復元する。
【００４５】
サーバ１０は、送信レートを増加するとき、メディアデータの送信に先駆けて、冗長符号としてＦＥＣパケット２１を送信する。そして、送信レートを増加した場合の伝送路の輻輳状態を察知するためＦＥＣパケット２１は利用される。
【００４６】
次に図４を参照して、ＲＴＰヘッダ２２の構成を説明する。ＲＴＰヘッダ２２は、ＶＥＲフィールド４０、Ｐフィールド４１、Ｘフィールド４２、ＣＣフィールド４３、Ｍフィールド４４、ＰＴフィールド４５、Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ フィールド４６、Ｔｉｍｅ Ｓｔａｍｐフィールド４７、ＳＳＲＣフィールド４８、及びＣＳＲＣフィールド４９から構成される。このＲＴＰヘッダ２２は、ＲＴＰ制御のため、ＦＥＣパケットやメディアデータの符号化パケットに付加される。
【００４７】
２ビットのＶＥＲフィールド４０は、ＲＴＰバージョン番号を示す。現在は、バージョン２である。各パケットはこのＶＥＲフィールドで始まる。Ｐフィールド４１は、１ビットのパディングビットを含む。このバディングビットには、パケットの最後がパディングされているかを示す。
【００４８】
Ｘフィールド４２は、１ビットのエクステンションビットを含む。このエクステンションビットは、ＲＴＰヘッダの直後に拡張ヘッダを持つ場合には「１」となる。ＣＣ（ＣＳＲＣカウント）フィールド４３は、ＣＳＲＣ（寄与送信元識別子）の数を示す。
【００４９】
Ｍフィールド４４は、１ビットのマーカービットを含む。このマーカービットは、アプリケーションデータの境界を示す。７ビットのＰＴフィールド４５は、ペイロードタイプのアプリケーションデータの符号化方式を示す。１６ビットのＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒフィールド４６は、パケットのシーケンス番号を含む。このシーケンス番号は、パケットの送信順に割り振られる。
【００５０】
Ｔｉｍｅ Ｓｔａｍｐフィールド４７は３２ビットの値であり、このパケットの先頭バイトが送信された時刻を示す。ＳＳＲＣ（同期送信元識別子）フィールド４８は、３２ビットの値であり、パケットの送信元を示す。ＣＳＲＣ（寄与送信元識別子）フィールド４９は、混合されたストリームの同期を示す。このＣＳＲＣフィールド４９は可変長である。
【００５１】
次に図５を参照して、ＦＥＣヘッダの構成を説明する。ＦＥＣヘッダ２２は、ＳＮ Ｂａｓｅフィールド５０、Ｌｅｎｇｔｈ ｒｅｃｏｖｅｒｙフィールド５１、ＰＴ ｒｅｃｏｖｅｒｙフィールド５３、Ｍａｓｋフィールド５４、及びＴＳ ｒｅｃｏｖｅｒｙフィールド５５から構成される。ＦＥＣヘッダは、ＦＥＣリカバリのパリティ情報を制御するために付加される。
【００５２】
ＳＮ Ｂａｓｅフィールド５０は、ＦＥＣ処理の対象となるＲＴＰパケットのシーケンス番号のオフセットを示す。Ｌｅｎｇｔｈ ｒｅｃｏｖｅｒｙフィールド５１は、ＲＴＰパケットの長さのパリティ情報を示す。Ｅフィールド５２は、ヘッダの拡張を示す。ＰＴ ｒｅｃｏｖｅｒｙフィールド５３は、ペイロードタイプのパリティ情報を示す。Ｍａｓｋフィールド５４は、ＦＥＣ処理の対象となるＲＴＰパケットの番号を示す。ＴＳ ｒｅｃｏｖｅｒｙフィールド５５は、タイムスタンプのパリティ情報を示す。
＜伝送システムのブロック図＞
本実施の形態として、ＭＰＥＧ−４の動画像符号データをＲＴＰ・ＲＴＣＰを用いて伝送する場合について図２を参照して説明する。図２は本実施の形態の伝送システムのブロック図である。
【００５３】
この伝送システムは、インターネット網２００を介して接続されるサーバ１００とクライアント３００との間で、ＲＴＰ・ＲＴＣＰを用いてデータを伝送する。なお、ＲＴＣＰには、サーバ１００からクライアント３００に送信されるＳｅｎｄｅｒ Ｒｅｐｏｒｔ（ＳＲ）と、クライアント３００からサーバ１００に送信されるＲｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ（ＲＲ）がある。
【００５４】
まず、動画像データが入力された後のサーバ１００側の処理を説明する。
【００５５】
サーバ１００は、ＭＰＥＧ−４符号化部１０１、パケッタイザ１０２、ＲＴＰ送信部１０３、レート制御部１０４、ＳＲ送信部１０５、ＲＲ受信部１０９、スイッチ１０６、ＦＥＣ生成部１０７、ＦＥＣ送信部１０８、及びＲＲ送信部１０９を含む。
【００５６】
ＭＰＥＧ−４符号化部１０１は、入力された動画像データを符号化する。
【００５７】
そして、パケッタイザ１０２は、符号化されたデータをパケット化し、図４に示すＲＴＰヘッダを付加する。
【００５８】
ＲＴＰ送信部１０３は、インターネット網２００を経由してクライアント３００に向けて、符号化データパケットとして、動画像データを送信する。
【００５９】
次に、クライアント３００側の処理を説明する。クライアント３００は、ＲＴＰ受信部３０１、データ復元部３０２、ＭＰＥＧ−４復号部３０３、表示部３０４、フィードバック情報生成部３０５、ＳＲ受信部３０６、ＦＥＣ受信部３０７、及びＲＲ送信部３０８を含む。
【００６０】
ＲＴＰ受信部３０１は、インターネット網２００を経由して、符号化データパケットを受信する。そして、ＲＴＰ受信部３０１は、受信した符号化データパケットをデータ復元部３０２に送る。また、ＲＴＰ受信部３０１は、図４に示すＲＴＰヘッダのシーケンス番号４６を参照して、パケット損失やジッタを測定し、測定した情報をフィードバック情報生成部３０５に送る。
【００６１】
データ復元部３０２は符号化データパケットを復元する。つまり、パケット損失があった場合には、データ復元部３０２は損失したパケットを復元する。そして、ＭＰＥＧ−４復号部３０３は符号化されたパケットデータを復号する。その後、表示部３０４は復号したデータを動画像として表示する。
【００６２】
次にフィードバック情報の生成、送信、及び受信、並びに送信レートの制御について説明する。本実施の形態では、サーバ１００はＲＲ受信部１０９でＲＲパケットを受信したときに送信レートを制御する。
【００６３】
まずクライアント３００は、パケット損失率、ジッタ情報、及びＳＲパケット情報をもとに、フィードバック情報生成部３０５で、ＲＲパケットを生成する。このパケット損失率とジッタ情報は、ＦＥＣパケット２１を受信するＦＥＣ受信部３０７とＲＴＰパケット２１を受信するＲＴＰ受信部３０１とから送られる。なお、ＳＲパケット情報は、サーバ１００から一定時間毎に送信されるＳＲパケットを受信した時刻等である。そして、この受信時刻は、サーバ１００側でランドトリップ時間を算出する際に用いられる。ＳＲパケット及びＲＲパケットのフォーマットは、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）１８８９に記載のフォーマットに従う。このＲＦＣ１８８９は、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で記載されている。
【００６４】
そして、クライアント３００は、フィードバック情報として、ＲＲパケットをサーバ１００に送信する。
【００６５】
一方、サーバ１００は、ＲＲ受信部１０９でＲＲパケットを受信した場合、フィードバック情報をもとに、ラウンドトリップ時間を計算する。このラウンドトリップ時間は、サーバ１００側でのＳＲパケットの送信時刻とＲＲパケットの受信時刻、及びクライアント３００側でのＳＲパケット受信からＲＲパケット送信までの時間から計算できる。
【００６６】
本実施の形態では、レート制御部１０４は、このラウンドトリップ時間とパケット損失率に基づいて送信レートを制御する。
【００６７】
次に、パケット損失率とラウンドトリップ時間に従ったレート制御部１０４での送信レートの制御について説明する。レート制御部１０４は、パケット損失率が所定の閾値（例えば、５％）を越えた場合、またはラウンドトリップ時間が所定の閾値（例えば、２００ｍｓ）を越えた場合には、送信レートを減少する。
【００６８】
一方、レート制御部１０４は、パケット損失率とラウンドトリップ時間の両方が、閾値以下の場合には、送信レートを増加する。
【００６９】
また、レート制御部１０４は、パケット損失率が閾値以下でラウンドトリップ時間が閾値を越えた場合には、送信レートを固定する。つまりレート制御部１０４は、送信レートを現状のままにする。
【００７０】
次に、レート制御部１０４が送信レートを増加すると判断した場合の処理について説明する。レート制御部１０４は、伝送路上の輻輳の割合をもとに判断する。
【００７１】
まず、サーバ１００は、送信レートの増加分として冗長符号を送信する。ここで、送信される冗長符号のフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣ（ＲＦＣ２７３３：“Ａｎ ＲＴＰ ＰａｙｌｏａｄＦｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）を利用する。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケットを設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケットを使って損失したパケットを復元することができる。また、ＲＦＣ２７３３では、最低２４パケットのＲＴＰパケットに１パケットの割合でＦＥＣパケットを付加することを推奨している。
【００７２】
そして、レート制御部１０４は、送信レートを増加する判断をした後、ＦＥＣパケットの生成をスイッチ１０６に指示する。スイッチ１０６は、パケッタイザ１０２で生成される符号化データパケットを複製する。そして、スイッチ１０６はＦＥＣ生成部１０７内のＦＥＣ生成用バッファ（図示せず）に複製したパケットを送る。
【００７３】
ＦＥＣ生成部１０７は、複製したＦＥＣパケットがＦＥＣ生成用バッファに所定量（例えば２４パケット）蓄積されると、パリティ情報を生成する。また、レート制御部１０４は、符号化データパケットについて優先度を与え、ＦＥＣ生成部１０７に指示する。
【００７４】
ＦＥＣ生成部１０７は、この優先度に従ってパリティ情報を生成する。この優先度は、例えば符号化データパケットのＩフレームとＰフレームの割合を７対３とすることができる。ここで各パケットがＩ・Ｐフレームのどちらを含むかは、ＭＰＥＧ−４のビデオパケットヘッダのヘッダエクステンションコード内のｖｏｐ＿ｃｏｄｉｎｇ＿ｔｙｐｅを参照することで認識できる。また、このパリティ情報は、図６に示すように、優先度に従って選択された各ＲＴＰパケットについて、ビット単位で排他的論理和を求めることにより生成できる。
【００７５】
そして、ＦＥＣ送信部１０８は、生成されたパリティ情報に図５に示すようなＦＥＣヘッダ２３を付加する。さらにＦＥＣ送信部１０８は、ＲＴＰヘッダ２２を付加して、図４に示すようなＦＥＣパケット２１を生成する。
【００７６】
なお、符号化データバケットの数は、最大でデータパケットと同数である。その場合には、データパケットと同一のＦＥＣパケット２１が生成され、同一パケットが２度送信される。
【００７７】
一方、クライアント３００側では、図２に示すＦＥＣ受信部３０７でＦＥＣパケット２１を受信し、データ復元部３０２に送る。
【００７８】
データ復元部３０２は、ＦＥＣパケット２１の中から優先度に応じて選択されたパケットの損失を判断する。ここで、データ復元部３０２は、損失したパケットが「０」、または「２パケット」以上であると判断した場合は、データ復元処理を行わずに復号部３０３に送る。
【００７９】
一方、データ復元部３０２は、損失したパケットが「１パケット」であると判断した場合には、ＦＥＣパケット２１を使って、損失したパケットを復元する。その後、データ復元部３０２は、符号化データをＭＰＥＧ−４復号部３０３に送る。
【００８０】
ＲＴＰ受信部３０１は、受信したＲＴＰパケットの損失率を算出し、フィードバック情報生成部３０５に送る。また、ＦＥＣ受信部３０７は、受信したＦＥＣパケット２１の損失率を算出し、フィードバック情報生成部３０５に送る。
【００８１】
フィードバック情報生成部３０５は、ＲＲパケットを生成し、ＲＲ送信部３０８からサーバ１００にＲＲパケットを送信する。
【００８２】
次に、サーバ１００側では、ＲＲ受信部１０９で受信したＲＲパケットからパケット損失率を取得し、ラウンドトリップ時間を計算する。
【００８３】
そして、レート制御部１０４は、パケット損失率とラウンドトリップ時間を使って、レートの増減の判断を行う。
【００８４】
レート制御部１０４は、送信レートを増加すると判断した場合には、ＦＥＣパケットの生成を中止することをスイッチ１０６に対して指示する。ここで、サーバ１００は、ＦＥＣパケット２１の送信を停止する。
【００８５】
また、レート制御部１０４は、ＦＥＣパケット２１の増加分に相当する符号化データを送信することをＭＰＥＧ−４符号化部１０１に対して指示する。ここで、ＭＰＥＧ−４符号化部１０１は符号化レート増加するため、サーバ１００は増加した送信レートでＭＰＥＧ−４データを送信することができる。
【００８６】
一方、レート制御部１０４は、送信レートを減少すると判断した場合には、符号化パケットデータをＦＥＣ生成部１０７に送ることを中止することをスイッチ１０６に対して指示する。この場合には、レート制御部１０４は、符号化レート減少をＭＰＥＧ−４符号化部１０１に指示しない。
＜パリティ情報の生成方法＞
図６を参照して、ＲＴＰパケットのパリティ情報を生成する方法について説明する。
【００８７】
サーバは、損失したパケットを復元するため、パケット化されたＭＰＥＧ−４データについてのパリティ情報を生成する。このパリティ情報は、サーバ１００のＦＥＣ生成部１０７で生成される。
【００８８】
ここで生成されたパリティ情報は、ＦＥＣパケット２１として、クライアントに送信される。このＦＥＣパケット２１のフォーマットは、インターネット（ＩＰ／ＵＤＰ）網におけるパケット間ＦＥＣ（ＲＦＣ２７３３：“Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ”）に従う。ＲＦＣ２７３３では、複数のＲＴＰパケットに対して、パケット全体のパリティを計算したＦＥＣパケット２１を設ける。こうすることによって、パケット損失が生じた時にＦＥＣパケット２１を使って損失したパケットを復元する。
【００８９】
そして、ＦＥＣパケット２１を受信したクライアントは、パリティ情報をもとに、ＭＰＥＧ−４データを復元する。
【００９０】
本実施の形態では、ＦＥＣパケット２１は、ＲＴＰパケット１からＲＴＰパケット４についてのパリティ情報を有する。
【００９１】
ＦＥＣパケット２１の１ビット目（Ｆ１）は、各ＲＴＰパケットの１ビット目（ａ１、ｂ１、ｃ１、ｄ１）の排他的論理和を求めることにより生成できる。同様にして、それぞれのビット毎にＲＴＰパケットの排他的論理和をとることにより、ＦＥＣパケット２１は生成できる。
【００９２】
ここで、ＲＴＰパケット３が損失した例について説明する。
クライアントは、受信したＲＴＰパケット（ａ１、ｂ１、ｄ１）とＦＥＣパケット（Ｆ１）を使って、排他的論理和が一致するようにすることによって、ＲＴＰパケット３（ｃ１）を復元することができる。同様にして、クライアントはＲＴＰパケット３（ｃ２〜ｃ５）を復元できる。
＜レート制御部の処理フロー＞
図７を参照して、レート制御部の処理を説明する。図７は、レート制御部１０４の処理フローを示す図である。
【００９３】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ７０１）。そして、レート制御部１０４は、パケット損失率が閾値１より小さいか、ランドトリップ時間が閾値２より小さいかを判断する（Ｓ７０２）。
【００９４】
Ｓ７０２で、レート制御部１０４は、パケット損失率及びランドトリップ時間がともに閾値より小さいと判断した場合、スイッチ１０６を「ＯＮ」にする（Ｓ７０３）。ここで、スイッチ１０６を「ＯＮ」にするとは、ＦＥＣパケット２１を生成する制御を意味する。
【００９５】
そして、レート制御部１０４は、ＦＥＣ生成部１０７に対して送信レートの上昇幅、優先比率を通知する（Ｓ７０４）。そして、ＦＥＣ生成部１０７は、ＦＥＣパケット２１を生成する（Ｓ７０５）。そして、ＦＥＣ送信部１０８は、ＦＥＣパケット２１をクライアント３００へ送信する（Ｓ７０６）。
【００９６】
一方Ｓ７０２で、パケット損失率及びランドトリップ時間の一方または両方が閾値以上であると判断した場合、レート制御部１０４は、符号化レートを固定または減少させる（Ｓ７０７）。
【００９７】
次に図８を参照して、ＦＥＣパケット２１送信後に伝送路の状況に変化がなかった場合のレート制御部の処理を説明する。図８は、レート制御部１０４の処理フローを示す図である。
【００９８】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ８０１）。このフィードバック情報は、ＦＥＣパケット２１により送信レートが増加した場合の輻輳の割合に関する情報を含む。
【００９９】
そして、レート制御部１０４は、パケット損失率が閾値１より小さいか、ランドトリップ時間が閾値２より小さいかを判断する（Ｓ８０２）。
【０１００】
Ｓ８０２で、レート制御部１０４は、パケット損失率及びランドトリップ時間がともに閾値より小さいと判断した場合、スイッチ１０６を「ＯＦＦ」にする（Ｓ８０３）。スイッチ１０６は、ＦＥＣパケット２１の生成を中止する。つまり、サーバ１００はＦＥＣパケット２１の送信を停止する。
【０１０１】
そしてレート制御部１０４は、ＭＰＥＧ−４生成部１０１に符号化レートの上昇を指示する（Ｓ８０４）。ここで、ＭＰＥＧ−４符号化部１０１は符号化レート増加する。そして、サーバ１００は増加した送信レートでＭＰＥＧ−４データを送信することができる。
【０１０２】
一方Ｓ８０２で、パケット損失率及びランドトリップ時間の一方または両方が閾値以上であると判断した場合、レート制御部１０４は、符号化レートを固定または減少させる（Ｓ８０５）。
【０１０３】
次に図９を参照して、ＦＥＣパケット２１送信後に伝送路の状況に変化があった場合のレート制御部の処理を説明する。
【０１０４】
図９は、レート制御部１０４の処理フローを示す図である。
【０１０５】
サーバ１００は、クライアント３００からフィードバック情報（ＲＲ）を受信する（Ｓ９０１）。そして、レート制御部１０４は、パケット損失率が閾値１より大きいか、またはランドトリップ時間が閾値２より大きいかを判断する（Ｓ９０２）。
【０１０６】
Ｓ９０２で、レート制御部１０４は、パケット損失率、またはランドトリップ時間の一方が閾値より大きいいと判断した場合、スイッチ１０６を「ＯＦＦ」にする（Ｓ９０３）。ここでスイッチ１０６は、ＦＥＣパケットの生成を中止する。つまり、サーバ１００はＦＥＣパケット２１の送信を停止する。
【０１０７】
一方Ｓ９０２で、パケット損失率及びランドトリップ時間の両方が閾値より大きいと判断した場合、レート制御部１０４は、符号化レートを固定または上昇させる（Ｓ９０４）。
＜実施形態の効果＞
本実施の形態に従うと、送信レートを増加した時にデータ損失が発生したとしても、伝送するデータの伝送誤りを抑えることができる。
【０１０８】
また、冗長符号を送信する前後において伝送路の状況に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができる。一方、冗長符号を送信する前後において伝送路の状況に悪化したと判断した場合に、以前の状態、つまりレート増加分の冗長符号を除いた状態に戻すことができる。
【０１０９】
また、伝送路においてパケット損失が発生したとしても、冗長化符号を利用して、損失したパケットを復元することが可能になる。
【０１１０】
さらに、例えば、ＭＰＥＧデータにおけるイントラフレーム（Ｉフレーム）の冗長符号を優先的に生成したとする。イントラフレームを優先すると、送信レートを増加した時にパケット損失が発生した場合であっても画質劣化を最小限に抑えることができる。
＜コンピュータ読み取り可能な記憶媒体＞
上記実施の形態のいずれかの処理をコンピュータに実行させるプログラムをコンピュータが読み取り可能な記憶媒体に記録することができる。そして、コンピュータに、この記憶媒体のプログラムを読み込ませて実行させることにより、上記実施の形態に示したシステムを提供することができる。
【０１１１】
ここで、コンピュータが読み取り可能な記憶媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記憶媒体をいう。このような記憶媒体のうちコンピュータから取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ＤＡＴ、８ｍｍテープ、メモリカード等がある。
【０１１２】
また、コンピュータに固定された記録媒体として、ハードディスクやＲＯＭ（リード・オンリー・メモリ）等がある。
【０１１３】
なお、上記実施の形態は本発明の範囲をなんら限定するものではなく、当業者が理解できる範囲において適宜、各種の変形の態様があり得る。
＜その他＞
さらに、本実施の形態は以下の発明を開示する。
（付記１）ネットワークを介して端末にデータを送信するデータ送信手段と、
前記データの伝送誤りを抑制する冗長符号を送信する冗長符号送信手段と、
前記端末からフィードバック情報を受信する受信手段と、
前記フィードバック情報に基づいて送信レートの増減を判断する判断手段と、
前記判断手段が送信レートを増加すると判断した場合に前記冗長符号の増加により送信レートを増加するレート増加手段とを備えることを特徴とするサーバ。
（付記２）前記冗長符号を送信する前後において伝送路の状況を比較する比較手段と、
前記比較手段が伝送路の状況に変化がないと判断した場合に、増加した前記冗長符号に換えて前記データ送信部から送信するデータを増加させるデータ増加手段とをさらに備える付記１に記載のサーバ。
（付記３）前記比較手段が伝送路の状況が悪化したと判断した場合に前記冗長符号の送信を停止する停止手段をさらに備える付記２に記載のサーバ。
（付記４）前記比較手段は前記フィードバック情報に基づいて冗長符号を送信する前後における伝送路の状況を比較する付記２または３に記載のサーバ。
（付記５）前記フィードバック情報はパケット損失率を含む付記４に記載のサーバ。
（付記６）前記フィードバック情報はパケットが到着した間隔に関する情報を含む付記４に記載のに記載のサーバ。
（付記７）前記フィードバック情報はラウンドトリップ時間を含む請求項４乃至６のいずれかに記載のに記載のサーバ。
（付記８）前記冗長符号はパケット間のパリティ情報を含むパケット間誤り訂正方式である付記４に記載のサーバ。
（付記９）前記冗長符号はデータの優先度に基づいて順番に生成される付記４に記載のサーバ。
【０１１４】
【発明の効果】
以上で説明したように、本発明は冗長符号を送信する前後において伝送路に変化がないと判断した場合に、レート増加分をデータに置き換えて送信することができるデータ伝送サーバを提供することができる。
【図面の簡単な説明】
【図１】本発明の原理を示す図である。
【図２】本実施の形態における伝送システムを示すブロック図である。
【図３】ＦＥＣパケットの構成図である。
【図４】ＲＴＰヘッダの構成図である。
【図５】ＦＥＣヘッダの構成図である。
【図６】ＦＥＣパリティ情報の生成方法を示す図である。
【図７】レート制御部の処理フローを示す図である。
【図８】レート制御部の処理フローを示す図である。
【図９】レート制御部の処理フローを示す図である。
【符号の説明】
１０、１００…サーバ
１１…符号化部
１２…パケッタイザ
１０２…パケッタイザ
１３…データ送信部
１４、１０４…レート制御部
１５…フィードバック情報受信部
１６、１０６…スイッチ
１７…冗長符号生成部
１８…冗長符号送信部
２０…ネットワーク
２１…RTPパケット
２２…RTPヘッダ
２３…FECヘッダ
２４…FECリカバリ
３０、３００…クライアント
３１…データ受信部
３２、３０２…データ復元部
３３…復号部
３４、３０４…表示部
３５、３０５…フィードバック情報生成部
３６…フィードバック送信部
３７…冗長符号受信部
４１…V
４２…P
４３…X
４４…C
４５…M
４５…PT
４６…Sequence Number
４７…Time Stamp
４８…SSRC
４９…CSRC
５１…SN base
５２…Length recovery
５３…E
５４…PT recovery
５５…TS recovery
１０１…MPEG-4符号化部
１０３…RTP送信部
１０５…SR送信部
１０７…FEC生成部
１０８…FEC送信部
１０９…RR受信部
２００…インターネット網
３０１…RTP受信部
３０３…MPEG-4復号部
３０６…SR受信部
３０７…FEC受信部
３０８…RR送信部
Claims (3)
- ネットワークを介して端末にデータを送信するデータ送信手段と、
前記データの伝送誤りを抑制する冗長符号を含むパケットを送信する冗長符号送信手段と、
前記端末からフィードバック情報を受信する受信手段と、
前記フィードバック情報に基づいて送信レートの増減を判断する判断手段と、
前記判断手段が送信レートを増加すると判断した場合、前記冗長符号送信手段に前記パケットを送信させることにより送信レートを増加するレート増加手段と、
送信レートを増加した後に受信する前記フィードバック情報に基づいて前記判断手段が送信レートを増加すると判断した場合、前記冗長符号送信手段に前記パケットの送信を停止させるとともに、前記データ送信手段に増加した送信レートで前記データを送信させるデータ増加手段とを備えることを特徴とするサーバ。 - 送信レートを増加した後に受信する前記フィードバック情報に基づいて前記判断手段が送信レートを減少すると判断した場合、前記冗長符号送信手段に前記パケットの送信を停止させる停止手段をさらに備える請求項１に記載のサーバ。
- 前記フィードバック情報はパケット損失率を含む請求項１又は２に記載のサーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080653A JP4173755B2 (ja) | 2003-03-24 | 2003-03-24 | データ伝送サーバ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080653A JP4173755B2 (ja) | 2003-03-24 | 2003-03-24 | データ伝送サーバ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004289621A JP2004289621A (ja) | 2004-10-14 |
| JP4173755B2 true JP4173755B2 (ja) | 2008-10-29 |
Family
ID=33294448
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003080653A Expired - Fee Related JP4173755B2 (ja) | 2003-03-24 | 2003-03-24 | データ伝送サーバ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4173755B2 (ja) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6307487B1 (en) | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
| US7068729B2 (en) | 2001-12-21 | 2006-06-27 | Digital Fountain, Inc. | Multi-stage code generator and decoder for communication systems |
| US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
| EP1552617A2 (en) | 2002-10-05 | 2005-07-13 | Digital Fountain, Inc. | Systematic encoding and decoding of chain reaction codes |
| CN1954501B (zh) | 2003-10-06 | 2010-06-16 | 数字方敦股份有限公司 | 通过通信信道接收从源发射的数据的方法 |
| JP4971144B2 (ja) | 2004-05-07 | 2012-07-11 | デジタル ファウンテン， インコーポレイテッド | ファイルダウンロードおよびストリーミングのシステム |
| JP5425397B2 (ja) * | 2004-12-02 | 2014-02-26 | トムソン ライセンシング | 適応型前方誤り訂正を行う装置及び方法 |
| JP4734970B2 (ja) * | 2005-03-09 | 2011-07-27 | ソニー株式会社 | 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム |
| JP4697525B2 (ja) * | 2005-04-20 | 2011-06-08 | ソニー株式会社 | 送受信システム、送信装置および送信方法、受信装置および受信方法、並びにプログラム |
| KR101292851B1 (ko) | 2006-02-13 | 2013-08-02 | 디지털 파운튼, 인크. | 가변적 ｆｅｃ 오버헤드 및 보호 구간을 이용하는 스트리밍및 버퍼링 |
| US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
| JP4808054B2 (ja) * | 2006-03-17 | 2011-11-02 | 富士通株式会社 | データ転送方法及び，これを適用する通信システム及びプログラム |
| US7971129B2 (en) | 2006-05-10 | 2011-06-28 | Digital Fountain, Inc. | Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems |
| US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
| US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
| US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
| US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
| US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
| US9419749B2 (en) | 2009-08-19 | 2016-08-16 | Qualcomm Incorporated | Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes |
| JP5239166B2 (ja) * | 2007-01-29 | 2013-07-17 | 日本電気株式会社 | データ通信装置および方法ならびにプログラム |
| EP2019522B1 (en) * | 2007-07-23 | 2018-08-15 | Polycom, Inc. | Apparatus and method for lost packet recovery with congestion avoidance |
| JP5027305B2 (ja) | 2007-09-12 | 2012-09-19 | デジタル ファウンテン， インコーポレイテッド | 信頼できる通信を可能にするためのソース識別情報の生成および伝達 |
| JP5102572B2 (ja) * | 2007-09-28 | 2012-12-19 | パナソニック株式会社 | 通信方式 |
| JP5397226B2 (ja) * | 2007-10-29 | 2014-01-22 | 日本電気株式会社 | 通信システム、データ送信装置、データ受信装置、通信方法および通信用プログラム |
| JP2009159368A (ja) * | 2007-12-27 | 2009-07-16 | Mitsubishi Electric Corp | データ伝送装置及び伝送可能帯域推測方法 |
| JP4834013B2 (ja) * | 2008-02-29 | 2011-12-07 | 日本放送協会 | 送信装置、送信プログラム、受信装置及び受信プログラム |
| JP5094546B2 (ja) * | 2008-05-16 | 2012-12-12 | キヤノン株式会社 | 通信装置、及び通信方法、プログラム |
| ATE549860T1 (de) * | 2009-01-13 | 2012-03-15 | Alcatel Lucent Espana S A | Verfahren und vorrichtung zur zuverlässigkeitssicherstellung während der übertragung von fernsehdaten in einem internetprotokoll basierendem fernsehsystem |
| GB2454606C (en) * | 2009-02-02 | 2017-01-25 | Skype Ltd | Method of transmitting data in a communication system |
| US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
| US9288010B2 (en) | 2009-08-19 | 2016-03-15 | Qualcomm Incorporated | Universal file delivery methods for providing unequal error protection and bundled file delivery services |
| JP5052578B2 (ja) * | 2009-09-18 | 2012-10-17 | シャープ株式会社 | 通信装置および通信装置としてコンピュータを機能させるためのプログラム |
| US9917874B2 (en) | 2009-09-22 | 2018-03-13 | Qualcomm Incorporated | Enhanced block-request streaming using block partitioning or request controls for improved client-side handling |
| US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
| US9319448B2 (en) | 2010-08-10 | 2016-04-19 | Qualcomm Incorporated | Trick modes for network streaming of coded multimedia data |
| US8958375B2 (en) | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
| US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
| US9253233B2 (en) | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
| US9843844B2 (en) | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
| US9294226B2 (en) | 2012-03-26 | 2016-03-22 | Qualcomm Incorporated | Universal object delivery and template-based file delivery |
| JP2013225761A (ja) * | 2012-04-20 | 2013-10-31 | Hitachi Ltd | 符号化装置、復号装置、通信システム及び通信制御方法 |
| US9998388B2 (en) * | 2014-02-06 | 2018-06-12 | Sony Interactive Entertainment LLC | Congestion control bitrate algorithm |
| JP2016005220A (ja) * | 2014-06-19 | 2016-01-12 | 株式会社Ｊｖｃケンウッド | 送信装置、送信方法、プログラム |
| US10104016B2 (en) | 2014-12-12 | 2018-10-16 | Hitachi, Ltd. | Communication device, communication device system, and communication method |
| US10447430B2 (en) | 2016-08-01 | 2019-10-15 | Sony Interactive Entertainment LLC | Forward error correction for streaming data |
-
2003
- 2003-03-24 JP JP2003080653A patent/JP4173755B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004289621A (ja) | 2004-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4173755B2 (ja) | データ伝送サーバ | |
| JP4454320B2 (ja) | 伝送装置、伝送制御プログラム、及び伝送方法 | |
| KR101449710B1 (ko) | 데이터 통신시스템, 데이터 송신장치, 데이터 송신방법 및패킷 사이즈 및 용장도 결정방법 | |
| Nguyen et al. | Distributed video streaming with forward error correction | |
| JP3967338B2 (ja) | 無線パケット転送装置 | |
| KR101242663B1 (ko) | 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체 | |
| KR100680671B1 (ko) | 에러 정정용 데이터의 생성 방법 및 생성 장치와 생성 프로그램을 저장한 컴퓨터 판독가능한 기록 매체 | |
| CN109923809B (zh) | 利用前向纠错的编码和解码方法、以及编码和解码系统 | |
| EP2312787B1 (en) | Method and device of data transmission | |
| CN111800218B (zh) | 一种数据流的传输方法和设备 | |
| US9525874B2 (en) | Transmitting apparatus and transmission method | |
| JP5094546B2 (ja) | 通信装置、及び通信方法、プログラム | |
| US8484540B2 (en) | Data transmitting device, control method therefor, and program | |
| JP4250036B2 (ja) | メディア伝送方法及びメディア伝送装置 | |
| JP2005033556A (ja) | データ送信装置、データ送信方法、データ受信装置、データ受信方法 | |
| JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
| Lecuire | Unequal error protection under bitrate constraint for video streaming over internet | |
| JP2012195864A (ja) | 伝送システム及び伝送装置、並びに伝送方法 | |
| JP2004120148A (ja) | マルチメディアコンテンツ送信装置およびマルチメディアコンテンツ受信装置 | |
| KR101700370B1 (ko) | 지터 보정 방법 및 장치 | |
| Hayasaka et al. | Referential Loss Recovery for Streaming Audio using Application Level Multicast | |
| Ben Halima et al. | Service-aware retransmission control in cellular networks | |
| Chilamkurti et al. | Video multicasting using layered FEC on split protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060202 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080423 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080507 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080707 |
|
| 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: 20080805 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080814 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110822 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120822 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120822 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130822 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |