(57)【要約】【課題】誤りを訂正するためのパケットのパケットロスをより少なくすることができる。【解決手段】  通信部３９は、１または複数のRTPパケットを含むバースト送信ユニットをクライアントに送信する。FECパケット生成部７４は、バースト送信ユニットに属するRTPパケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されているFECパケットを生成する。通信部３９は、さらに、第１のバースト送信ユニットに属するRTPパケットの次の１または複数のRTPパケットを含む第２のバースト送信ユニットであって、送信の順番を基準として前半に、FECパケットが配置されている第２のバースト送信ユニットをクライアントに送信する。本発明は、ストリーミングデータを提供するサーバに適用できる。【選択図】図６
2005136546.tif 000002
【特許請求の範囲】
【請求項１】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置において、
１または複数の前記送信パケットを含む第１の集合の相手への送信を制御する送信制御手段と、
前記第１の集合に属する前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段と
を含み、
前記送信制御手段は、さらに、前記第１の集合に属する前記送信パケットの次の１または複数の前記送信パケットを含む第２の集合であって、送信の順番を基準として前半に、前記誤り訂正パケットが配置されている前記第２の集合の相手への送信を制御する
ことを特徴とする送信装置。
【請求項２】
前記第１の集合および前記第２の集合は、それぞれバースト送信ユニットである
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
前記送信制御手段は、送信の順番を基準として先頭に前記誤り訂正パケットが配置されている前記第２の集合の相手への送信を制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項４】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信方法において、
１または複数の前記送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、
前記第１の集合に属する前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと
を含み、
前記送信制御ステップにおいて、さらに、前記第１の集合に属する前記送信パケットの次の１または複数の前記送信パケットを含む第２の集合であって、送信の順番を基準として前半に、前記誤り訂正パケットが配置されている前記第２の集合の相手への送信が制御される
ことを特徴とする送信方法。
【請求項５】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理用のプログラムであって、
１または複数の前記送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、
前記第１の集合に属する前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと
を含み、
前記送信制御ステップにおいて、さらに、前記第１の集合に属する前記送信パケットの次の１または複数の前記送信パケットを含む第２の集合であって、送信の順番を基準として前半に、前記誤り訂正パケットが配置されている前記第２の集合の相手への送信が制御される
ことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項６】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理を、コンピュータに行わせるプログラムにおいて、
１または複数の前記送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、
前記第１の集合に属する前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと
を含み、
前記送信制御ステップにおいて、さらに、前記第１の集合に属する前記送信パケットの次の１または複数の前記送信パケットを含む第２の集合であって、送信の順番を基準として前半に、前記誤り訂正パケットが配置されている前記第２の集合の相手への送信が制御される
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信装置および方法、記録媒体、並びにプログラムに関し、特に、誤り訂正データを送信できるようにした送信装置および方法、記録媒体、並びにプログラムに関する。
【背景技術】
【０００２】
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の伝送方式のサービスに加えて、ストリーム型の伝送方式のサービスがより多く提供されるようになってきた。
【０００３】
ストリーム型の伝送方式のサービスにおいては、送信装置が、データを順次送信し、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
【０００４】
ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般に、ストリーミングデータと称する。
【０００５】
しかしながら、インターネットなどのデータの到達が保証されない伝送路を介して、動画像または音声のストリーミングデータを伝送すると、伝送負荷の増大により、パケットロスが生じる場合がある。
【０００６】
パケットロスが生じると、受信側において、再生される動画像が乱れたり、音声が途切れたりしてしまう。
【０００７】
この問題を解決するために、ストリーミングデータと共に冗長データを送信し、受信側でロスしたパケットのエラーを訂正する方法が用いられている。その一例として、FEC（Forward Error Correction）方式がある。FEC方式においては、複数のパケットからなる集合に対して、冗長パケットを複数生成して、集合と共に冗長パケットが送信される。受信側においては、集合に属するパケットにパケットロスが生じた場合、冗長パケットを用いて、ロスしたパケットのエラーが訂正される。
【０００８】
例えば、図１で示されるように、送信側は、データパケット１−１乃至データパケット１−５の５つのパケットからなる集合に、FECパケット２−１およびFECパケット２−２の２つの冗長パケットを付加して、受信側に送信する。FECパケット２−１およびFECパケット２−２は、データパケット１−１乃至データパケット１−５の所定の組み合わせに対して排他的論理和（exclusive-OR）の演算を適用することにより生成される。
【０００９】
例えば、伝送路において、データパケット１−２がロスされた場合、受信側において、データパケット１−１とFECパケット２−１とに排他的論理和の演算が適用されることにより、データパケット１−２が復元される。
【００１０】
図１で示される例において、FECパケット２−１およびFECパケット２−２の数と同じ数のロスしたパケットのエラーを訂正することができる。すなわち、データパケット１−１乃至データパケット１−５のうち、１つまたは２つがロスされても、そのパケットを回復することができる。
【００１１】
FEC方式によって、１フレームの集合に対して、冗長データを生成することが考えられるが、冗長データの生成をソフトウェアで行うと、非常に負荷の高い処理になってしまうという問題がある。
【００１２】
図２は、データパケット１−１乃至データパケット１−５からなる集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信の順序を説明する図である。図２の横方向は、時間を示す。
【００１３】
データパケット１−１乃至データパケット１−５の集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信において、最初に、データパケット１−１乃至データパケット１−５が順に送信され、その後、FECパケット２−１およびFECパケット２−２が順に送信される。
【００１４】
図３は、従来のFECパケットを付加した送信の処理を説明するフローチャートである。ステップＳ１１において、送信装置は、内蔵しているタイマを初期化する。
【００１５】
ステップＳ１２において、送信装置は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ１２に戻り、タイマが終了するまで、判定の処理を繰り返す。
【００１６】
ステップＳ１２において、タイマが終了したと判定された場合、１つのフレームに対応する期間が経過したので、ステップＳ１３に進み、送信装置は、供給された画像データをキャプチャする。ステップＳ１４において、送信装置は、キャプチャされた画像データを、エンコード（符号化）する。
【００１７】
ステップＳ１５において、送信装置は、符号化された画像データを格納するデータパケットであるRTP（Real-time Transport Protocol）パケットを生成する。ステップＳ１６において、送信装置は、RTPパケットを相手に送信する。
【００１８】
ステップＳ１７において、送信装置は、RTPパケットを基に、FECパケットを生成する。ステップＳ１８において、送信装置は、FECパケットを相手に送信する。
【００１９】
ステップＳ１９において、送信装置は、RTPパケットに付加するタイムスタンプを更新する。ステップＳ２０において、送信装置は、内蔵しているタイマをセットして、ステップＳ１２に戻り、上述した処理を繰り返す。
【００２０】
また、送信側では、各パケットの情報ブロックを、先行パケットおよび後続パケットの情報ブロックとの共通部分を持つように構成し、誤り訂正符号にて符号化して送信し、共通部分の大きさは伝送路状態に応じて変化させ、一方、受信側では、その情報ブロックを復号および誤り訂正符号の機能によって誤り訂正し、復号に失敗した場合には、情報ブロックの共通部分を先行パケットのものと置換して、この共通部分が置換された情報ブロックを、再度、復号および誤り訂正するようにしているものもある（特許文献１参照）。
【００２１】
さらに、パケット伝送において、ネットワーク監視部によって監視されるネットワーク状況に基づいてエラー訂正制御を行なうシステムもある（特許文献２参照）。このシステムにおいては、FECによるエラー制御、再送要求処理（ARQ）に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行し、RTT（Round-Trip Time）が短いならば、ARQによるエラー訂正選択、RTTが長い状況である場合には、ARQではなくFECによるエラー訂正を選択するといった動的なエラー訂正制御が可能となる。
【００２２】
【特許文献１】特開２０００−２２４２２６号公報
【００２３】
【特許文献２】特開２００３−１７９５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
しかしながら、始めに、データパケットを送信し、その後に、冗長パケットを送信すると、伝送路を構成するネットワークに輻輳が生じた場合、冗長パケットにパケットロスが発生する可能性は、データパケットにパケットロスが発生する可能性より高くなる。冗長パケットにパケットロスが発生すると、受信側で、パケットロスしたデータパケットを復元することができなくなってしまう。
【００２５】
これは、図２で示されるように、データパケットおよび冗長パケットが連続的に順に送信されると、パケットの後ろになるにつれて、パケットロスが発生する確率が高くなるためである。このような、パケットロスは、ネットワークを構成するルータの、パケットのキューを格納するバッファにおけるあふれなどによって生じる。
【課題を解決するための手段】
【００２６】
本発明の送信装置は、１または複数の送信パケットを含む第１の集合の相手への送信を制御する送信制御手段と、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段とを含み、送信制御手段は、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信を制御することを特徴とする。
【００２７】
第１の集合および第２の集合は、それぞれバースト送信ユニットとすることができる。
【００２８】
送信制御手段は、送信の順番を基準として先頭に誤り訂正パケットが配置されている第２の集合の相手への送信を制御するようにすることができる。
【００２９】
本発明の送信方法は、１または複数の送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップとを含み、送信制御ステップにおいて、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信が制御されることを特徴とする。
【００３０】
本発明の記録媒体のプログラムは、１または複数の送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップとを含み、送信制御ステップにおいて、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信が制御されることを特徴とする。
【００３１】
本発明のプログラムは、コンピュータに、１または複数の送信パケットを含む第１の集合の相手への送信を制御する送信制御ステップと、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップとを実行させ、送信制御ステップにおいて、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信が制御されることを特徴とする。
【００３２】
送信装置は、独立した装置であっても良いし、通信装置の送信処理を行うブロックであっても良い。
【００３３】
本発明の送信装置および方法、記録媒体、並びにプログラムにおいては、１または複数の送信パケットを含む第１の集合が相手に送信され、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットが生成され、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合が相手に送信される。
【発明の効果】
【００３４】
誤りを訂正するためのパケットのパケットロスをより少なくすることができる。
【発明を実施するための最良の形態】
【００３５】
以下に本発明の実施の形態を説明するが、本明細書に記載の発明と、発明の実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
【００３６】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現、追加される発明の存在を否定するものではない。
【００３７】
本発明に寄れば送信装置が提供される。この送信装置は、１または複数の送信パケット（例えば、RTPパケット）を含む第１の集合（例えば、図１１のRTPパケット１０１−１乃至１０１−４からなるバースト送信ユニット）の相手への送信を制御する送信制御手段（例えば、図６の通信部３９）と、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、FECパケット）を生成する生成手段（例えば、図６のFECパケット生成部７４）とを含み、送信制御手段は、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合（例えば、図１１のRTPパケット１０１−５乃至１０１−８からなるバースト送信ユニット）であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信を制御する。
【００３８】
第１の集合および第２の集合は、それぞれバースト送信ユニットとすることができる。
【００３９】
送信制御手段は、送信の順番を基準として先頭に誤り訂正パケットが配置されている第２の集合の相手への送信を制御するようにすることができる。
【００４０】
本発明によれば、送信方法が提供される。この送信方法は、１または複数の送信パケット（例えば、RTPパケット）を含む第１の集合（例えば、図１１のRTPパケット１０１−１乃至１０１−４からなるバースト送信ユニット）の相手への送信を制御する送信制御ステップ（例えば、図８のステップＳ４９の処理）と、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、FECパケット）を生成する生成ステップ（例えば、図８のステップＳ５０の処理）とを含み、送信制御ステップにおいて、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合（例えば、図１１のRTPパケット１０１−５乃至１０１−８からなるバースト送信ユニット）であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信が制御される（例えば、図８のステップＳ４６およびステップＳ４９の処理）。
【００４１】
本発明によれば、プログラムが提供される。このプログラムは、コンピュータに、１または複数の送信パケット（例えば、RTPパケット）を含む第１の集合（例えば、図１１のRTPパケット１０１−１乃至１０１−４からなるバースト送信ユニット）の相手への送信を制御する送信制御ステップ（例えば、図８のステップＳ４９の処理）と、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、FECパケット）を生成する生成ステップ（例えば、図８のステップＳ５０の処理）とを実行させ、送信制御ステップにおいて、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合（例えば、図１１のRTPパケット１０１−５乃至１０１−８からなるバースト送信ユニット）であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信が制御される（例えば、図８のステップＳ４６およびステップＳ４９の処理）。
【００４２】
このプログラムは、記録媒体（例えば、図５の磁気ディスク５１）に記録することができる。
【００４３】
本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システム、またはテレビ電話などのリアルタイムにストリーミングデータを伝送する通信システムに適用できる。
【００４４】
図４は、本発明に係る通信システムの一実施の形態を示す図である。カメラ１１は、画像を撮像して、撮像した画像に対応する画像データをサーバ１２に供給する。例えば、カメラ１１は、動画像を撮像して、動画像に対応する画像データをサーバ１２に供給する。
【００４５】
画像データは、ストリーミングデータの一例である。ストリーミングデータは、音声のデータ、またはリアルタイム制御データなど、時間の経過に対応して順次送信または受信が要求されるデータであればよい。
【００４６】
サーバ１２は、カメラ１１から供給された画像データをパケットに格納して、パケットを通信網１３を介して、クライアント１４に送信する。サーバ１２は、画像を格納したパケットを訂正するための冗長データを生成して、冗長データを格納したパケットを通信網１３を介して、クライアント１４に送信する。
【００４７】
通信網１３は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、サーバ１２から送信されたパケットをクライアント１４まで伝送する。
【００４８】
クライアント１４は、通信網１３を介してサーバ１２から送信されてきた各種のパケットを受信する。
【００４９】
クライアント１４は、ストリーミングデータが格納されているパケットを正常に受信できなかった場合、冗長データを格納したパケットを基に、正常に受信できなかった画像データを格納するパケットのエラーを訂正する。
【００５０】
図５は、サーバ１２の構成の例を示すブロック図である。CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２、または記録部３８に記録されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）３３には、CPU３１が実行するプログラムやデータなどが適宜記憶される。これらのCPU３１、ROM３２、およびRAM３３は、バス３４により相互に接続されている。
【００５１】
CPU３１にはまた、バス３４を介して入出力インタフェース３５が接続されている。入出力インタフェース３５には、キーボード、マウス、スイッチなどよりなる入力部３６、ディスプレイ、スピーカ、ランプなどよりなる出力部３７が接続されている。CPU３１は、入力部３６から入力される指令に対応して各種の処理を実行する。
【００５２】
入出力インタフェース３５に接続されている記録部３８は、例えばハードディスクなどで構成され、CPU３１が実行するプログラムや各種のデータを記録する。通信部３９は、インターネット、その他のネットワークなどの通信網１３を介して、クライアント１４などの外部の装置と通信する。
【００５３】
また、通信部３９を介してプログラムを取得し、記録部３８に記録してもよい。
【００５４】
入出力インタフェース３５に接続されているドライブ４０は、磁気ディスク５１、光ディスク５２、光磁気ディスク５３、或いは半導体メモリ５４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部３８に転送され、記録される。
【００５５】
なお、クライアント１４は、サーバ１２と同様に構成されるので、その説明は省略する。
【００５６】
図６は、サーバ１２の機能の構成を示すブロック図である。
【００５７】
サーバ１２は、エンコーダ７１、バッファ７２、RTPパケット生成部７３、FECパケット生成部７４を含む。
【００５８】
エンコーダ７１は、所定の符号化方式で、供給されたストリーミングデータの一例である画像データを符号化し、符号化された画像データをバッファ７２に供給する。
【００５９】
バッファ７２は、エンコーダ７１から供給された、符号化されている画像データを一時的に記憶する。バッファ７２は、記憶している画像データをRTPパケット生成部７３に供給する。
【００６０】
RTPパケット生成部７３は、バッファ７２から供給された、符号化されている画像データをRTPパケットに格納して、RTPパケットを通信部３９に供給する。
【００６１】
RTPパケットは、IETF RFC（Internet Engineering Task Force Request For Comments）1889で規定されているプロトコルであるRTP（Real time Transport Protocol）に基づく方式のパケットである。
【００６２】
通信部３９は、RTPパケット生成部７３から供給されたRTPパケットを、通信網１３を介して、相手であるクライアント１４に送信する。
【００６３】
RTPパケット生成部７３は、パケットバッファ８１を含む。パケットバッファ８１は、RTPパケット生成部７３によって生成された、１または複数のパケットからなる、１つの集合を記憶する。例えば、集合は、メディア（データ）同期のための処理の単位であるメディアユニットであって、１つのフレームの画像データを格納するパケットからなる。
【００６４】
例えば、集合は、バースト送信の単位であるバースト送信ユニットであって、複数のパケットからなる。この場合、１つのフレームの画像データは、１または複数のバースト送信ユニットに属するパケットに格納される。
【００６５】
なお、パケットの集合は、メディアユニットまたはバースト送信ユニットとは限らず、１つのフィールドの画像データを格納するパケットなど、集合に含まれるパケットに何らかの関係があれば足りる。
【００６６】
FECパケット生成部７４は、RTPパケット生成部７３のパケットバッファ８１に記憶されている、１つの集合に属する１または複数のパケットを基に、その集合に属するパケットの誤りを訂正するためのFECパケットを生成する。FECパケット生成部７４は、生成したFECパケットを、内部のパケットバッファ８２に記憶する。
【００６７】
この発明において、パケットの誤りとは、受信側において、正常に受信できなかったパケットの状態を広く示し、いわゆる、エラーに限らず、パケットそのものを受信できなかったこと、すなわち、パケットロスも示すものとする。
【００６８】
FECパケット生成部７４は、所定のタイミングで、パケットバッファ８２に記憶されているFECパケットを通信部３９に供給する。
【００６９】
通信部３９は、FECパケット生成部７４から供給されたFECパケットを、通信網１３を介して、相手に送信する。
【００７０】
このように、サーバ１２は、通信網１３を介して、クライアント１４に、画像データを格納するパケットを送信する。また、サーバ１２は、通信網１３を介して、クライアント１４に、画像データを格納するパケットの誤りを訂正するためのFECパケットを送信する。
【００７１】
図７は、クライアント１４の機能の構成を示すブロック図である。
【００７２】
クライアント１４は、通信部９１、バッファ９２、誤り訂正部９３、およびデコーダ９４を含む。
【００７３】
通信部９１は、クライアント１４の図５における通信部３９に相当し、通信網１３を介してサーバ１２から送信されてきた各種のパケットを受信する。通信部９１は、受信したパケットをバッファ９２に供給する。例えば、通信部９１は、受信したRTPパケットおよびFECパケットをバッファ９２に供給する。
【００７４】
バッファ９２は、通信部９１から供給されたパケットを記憶する。例えば、バッファ９２は、RTPパケットおよびFECパケットを記憶する。
【００７５】
誤り訂正部９３は、バッファ９２に記憶されているRTPパケットを検査する。誤り訂正部９３は、正常にRTPパケットを受信できなかった場合、正常に受信されなかったRTPパケットの誤りを、バッファ９２に記憶されているFECパケットを基に、訂正する。例えば、誤り訂正部９３は、RTPパケットにパケットロスが発生した場合、パケットロスが発生したRTPパケットを、バッファ９２に記憶されている他のRTPパケットおよびFECパケットを基に、復元する。
【００７６】
デコーダ９４は、バッファ９３に記憶されている、誤りが訂正されたRTPパケットから画像データを抽出して、エンコーダ７１の符号化方式に対応する復号方式で、抽出された画像データを復号して、復号された画像データを出力する。
【００７７】
このように、クライアント１４は、FECパケットを基に、RTPパケットの誤りを訂正する。
【００７８】
なお、図６または図７で示されるサーバ１２またはクライアント１４の機能は、ハードウェアにより実現するようにしてもよく、ソフトウェア（プログラム）により実現するようにしてもよい。
【００７９】
次に、図８のフローチャートを参照して、送信プログラムを実行するサーバ１２による、送信の処理を説明する。ステップＳ４１において、サーバ１２は、送信の処理に必要なデータを初期化する。例えば、ステップＳ４１において、サーバ１２のエンコーダ７１は、内蔵しているタイマを初期値に設定する。より具体的には、例えば、エンコーダ７１は、タイマの値を０に設定する。
【００８０】
ステップＳ４２において、エンコーダ７１は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ４２に戻り、タイマが終了するまで、判定の処理を繰り返す。
【００８１】
例えば、ステップＳ４２において、エンコーダ７１は、タイマの値と、予め定めた33msの時間を示す値とを比較することにより、タイマが終了したか否かを判定する。この場合における、タイマの値と比較される33msの時間を示す値は、フレームの数が１秒当たり３０である場合の例であり、本発明を限定するものではない。
【００８２】
なお、初期化の処理において、タイマの値を33msなどの所定の時間の値に設定して、時間の経過に対応してタイマの値が減少するようにして、比較の処理において、タイマの値が０であるか否かを判定するようにしてもよい。以下に説明するタイマに関する処理において、同様である。
【００８３】
ステップＳ４２において、エンコーダ７１は、タイマが終了したと判定された場合、ステップＳ４３に進み、カメラ１１から供給された画像データをキャプチャする。ステップＳ４３において、例えば、エンコーダ７１は、カメラ１１から供給された画像データのうち、１フレーム分をキャプチャする。
【００８４】
ステップＳ４４において、エンコーダ７１は、キャプチャされた画像データを、エンコード（符号化）する。例えば、ステップＳ４４において、エンコーダ７１は、キャプチャされた画像データを、MPEG（Moving Pictures Experts Group）１，２，４，７、若しくは２１、JPEG（Joint Photographic Experts Group）、JPEG2000、またはモーションJPEGなどの方式により符号化する。
【００８５】
ステップＳ４５において、FECパケット生成部７４は、パケットバッファ８２にFECパケットがあるか否かを判定する。例えば、最初に実行されるステップＳ４５の処理においては、まだ、FECパケットが生成されていないので、FECパケットがないと判定される。
【００８６】
後述するように、一度、ステップＳ４７乃至ステップＳ５３の処理が実行された後の、２回目以降のステップＳ４５においては、FECパケットが生成されて、生成されたFECパケットがパケットバッファ８２に格納されているので、FECパケットがあると判定される。
【００８７】
ステップＳ４５において、FECパケットがあると判定された場合、ステップＳ４６に進み、FECパケット生成部７４は、パケットバッファ８２に記憶されているFECパケットを通信部３９に供給して、通信部３９に、通信網１３を介して、クライアント１４宛てにFECパケットを送信させ、ステップＳ４７に進む。
【００８８】
ステップＳ４５において、FECパケットがないと判定された場合、FECパケットを送信することはできないので、ステップＳ４６の処理はスキップされ、手続きは、ステップＳ４７に進む。
【００８９】
ステップＳ４７において、エンコーダ７１は、エンコードされた画像データをバッファ７２に供給して、バッファ７２に画像データを記憶させる。
【００９０】
ステップＳ４８において、RTPパケット生成部７３は、バッファ７２に記憶されている符号化されている画像データから、符号化された画像データを格納するRTP（Real-time Transport Protocol）パケットを生成する。例えば、RTPパケット生成部７３は、バッファ７２から、１フレーム分の、符号化されている画像データを読み出す。そして、RTPパケット生成部７３は、読み出した画像データを適当なデータ量に分割して、分割された画像データのそれぞれに所定のヘッダを付加することにより、１つの集合に属する、１または複数のRTPパケットを生成する。
【００９１】
図９は、RTPパケットを説明する図である。RTPパケットの先頭には、図９において”v”で表される、２ビットのバージョン情報が配置される。バージョン情報は、RTPパケットのバージョンを示す。
【００９２】
バージョン情報の次に１ビットのパディングが配置され、パディングに続いて、１ビットの拡張情報がRTPパケットに配置される。拡張情報は、図９において、”x”で表される。拡張情報は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。
【００９３】
拡張情報に続いて、CSRC（Contributing Source）カウントがRTPパケットに配置される。CSRCカウントは、図９中において、”cc”で表される。CSRCカウントは、CSRC識別子の数を表す。
【００９４】
CSRCカウントに続いて配置される、１ビットのメーカー情報は、プロファイルによって定義される。メーカー情報は、図９中において、”m”で表される。
【００９５】
メーカー情報に続いて配置される、７ビットのペイロードタイプは、RTPパケットのフォーマットを定義するための情報である。ペイロードタイプは、図９中において、”Pt”で表される。RTPパケットにおいて、ペイロードタイプは、３３とされる。
【００９６】
シーケンス番号は、ペイロードタイプの次に配置される、１６ビットの情報である。シーケンス番号は、RTPパケットの送信の度に、１ずつ増える。シーケンス番号は、パケットロスを検出し、RTPパケットの順序を修復するために使用される。
【００９７】
シーケンス番号の次に配置される、３２ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。
【００９８】
SSRC（Synchronization source）識別子は、タイムスタンプの次に配置される、３２ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。
【００９９】
RTPパケットにおいて、SSRC識別子の次には、ストリーミングデータが格納される。図９において、”データ”は、ストリーミングデータを示す。
【０１００】
図８に戻り、ステップＳ４８において、RTPパケット生成部７３は、さらに、生成されたRTPパケットを通信部３９に供給すると共に、内部のパケットバッファ８１にRTPパケットを記憶させる。
【０１０１】
ステップＳ４９において、信部３９は、通信網１３を介して、RTPパケット生成部７３から供給されたRTPパケットを相手であるクライアント１４に送信する。
【０１０２】
ステップＳ５０において、FECパケット生成部７４は、パケットバッファ８１に記憶されている１つの集合に属するRTPパケットを基に、FECパケットを生成する。例えば、FECパケット生成部７４は、パケットバッファ８１に記憶されている１つの集合に属するRTPパケットから２つのRTPパケットを選択して、選択されたRTPパケットのデータに排他的論理和の演算を適用することにより、FECパケットのデータを生成し、生成されたデータに所定のヘッダを付加することにより、FECパケットを生成する。
【０１０３】
図１０は、FECパケットを説明する図である。バージョン情報乃至メーカ情報、およびシーケンス番号乃至SSRC識別子は、図９に示すRTPパケットの場合と同様なので、その説明は省略する。
【０１０４】
FECパケットにおいて、ペイロードタイプは、３４とされる。
【０１０５】
FECパケットにおいて、SSRC識別子の次には、誤り訂正のための冗長データが格納される。図１０において、”データ”は、冗長データを示す。
【０１０６】
なお、FECパケット生成部７４によって生成されるFECパケットの誤り訂正方式（冗長データの方式）は、排他的論理和の演算によるものに限らず、例えば、ハミング符号などの線形符号、巡回符号、BCH（Bose-Chaudhuri-Hocquenghem）符号若しくはリードソロモン（Reed-Solomon）符号などの代数的符号、または多数決論理符号などいずれの方式であってもよい。
【０１０７】
ステップＳ５１において、FECパケット生成部７４は、ステップＳ５０の処理で生成したFECパケットをパケットバッファ８２に記憶する。
【０１０８】
なお、ステップＳ５０の処理で生成されたFECパケットは、即座に、クライアント１４に送信されることはなく、ステップＳ５１の処理の後に実行されるステップＳ４６の処理において、パケットバッファ８２に記憶されたFECパケットが、通信網１３を介して、クライアント１４に送信される。
【０１０９】
従って、ステップＳ４９の処理において、RTPパケットが送信されてから、ステップＳ４２において判定されるタイマの終了に要する期間を経過した後、ステップＳ４６において、そのRTPパケットを訂正するためのFECパケットが送信されることになる。
【０１１０】
また、FECパケットを送信するまでに、時間的な余裕ができるので、高速な処理のために、必ずしもFECパケットを生成するための専用のハードウェアを設ける必要がなくなり、また、ステップＳ５０に処理の実行のために、一時に、より多くのCPU３１の資源が必要とされない。
【０１１１】
より詳細には、ステップＳ４９の処理において、１つのフレームの画像データを格納するRTPパケットが送信されてから、次のフレームの画像データを格納するRTPパケットを送信する時刻であって、次のフレームの画像データを格納するRTPパケットを送信する前に、前のフレームのRTPパケットを訂正するためのFECパケットが送信されることになる。
【０１１２】
ステップＳ５２において、RTPパケット生成部７３は、RTPパケットに付加するタイムスタンプを更新する。ステップＳ５３において、エンコーダ７１は、内蔵しているタイマをセットして、ステップＳ４２に戻り、上述した処理を繰り返す。
【０１１３】
例えば、ステップＳ４９において、エンコーダ７１は、タイマの値を０にセットする。
【０１１４】
このように、サーバ１２は、通信網１３を介して、例えば、画像であるストリーミングデータが格納されているRTPパケットをクライアント１４に送信し、一定期間が経過した後、RTPパケットを訂正するためのFECパケットをクライアント１４に送信する。従って、ネットワークを構成するルータの、パケットのキューを格納するバッファにおけるあふれなどによって生じる、FECパケットのパケットロスをより少なくすることができる。
【０１１５】
図１１は、サーバ１２によって送信され、クライアント１４によって受信されるRTPパケットおよびFECパケットの順序を説明する図である。
【０１１６】
図１１において、RTPパケット１０１−１乃至１０１−４は、１つのフレームの画像データを分割して格納し、それぞれ３０００であるタイムスタンプが付されている。RTPパケット１０１−１乃至１０１−４は、１つのバースト送信ユニットを構成する。
【０１１７】
RTPパケット１０１−５乃至１０１−８は、RTPパケット１０１−１乃至１０１−４に格納されている画像データのフレームの、次の１つのフレームの画像データを分割して格納し、それぞれ６０００であるタイムスタンプが付されている。RTPパケット１０１−５乃至１０１−８は、１つのバースト送信ユニットを構成する。
【０１１８】
RTPパケット１０１−９乃至１０１−１２は、RTPパケット１０１−５乃至１０１−８に格納されている画像データのフレームの、次の１つのフレームの画像データを分割して格納し、それぞれ９０００であるタイムスタンプが付されている。RTPパケット１０１−９乃至１０１−１２は、１つのバースト送信ユニットを構成する。
【０１１９】
なお、図１１で示されるバースト送信ユニットは、メディアユニットでもある。
【０１２０】
すなわち、RTPパケット１０１−１乃至１０１−４は、１つの集合に属するパケットの一例である。同様に、RTPパケット１０１−５乃至１０１−８は、１つの集合に属するパケットの一例であり、RTPパケット１０１−９乃至１０１−１２は、１つの集合に属するパケットの一例である。
【０１２１】
FECパケット１０２−１は、RTPパケット１０１−１乃至１０１−４のエラーを訂正するための冗長データを格納する。FECパケット１０２−２は、RTPパケット１０１−５乃至１０１−８のエラーを訂正するための冗長データを格納する。
【０１２２】
図１１で示されるように、FECパケット１０２−１は、RTPパケット１０１−１乃至１０１−４からなるバースト送信ユニットのエラーを訂正するための冗長データを格納し、RTPパケット１０１−１乃至１０１−４とは別に（時間的に離れて）、RTPパケット１０１−５乃至１０１−８からなるバースト送信ユニットの前側に配置されて、RTPパケット１０１−５乃至１０１−８と共にバースト送信により送信される。
【０１２３】
同様に、FECパケット１０２−２は、RTPパケット１０１−５乃至１０１−８からなるバースト送信ユニットのエラーを訂正するための冗長データを格納し、RTPパケット１０１−５乃至１０１−８とは別に、RTPパケット１０１−９乃至１０１−１２からなるバースト送信ユニットの前側に配置されて、RTPパケット１０１−９乃至１０１−１２と共にバースト送信により送信される。
【０１２４】
このように、FECパケット１０２−１および１０２−２は、エラー訂正の対象となるバースト送信ユニットと時間的に離れて、他のバースト送信ユニットと共に送信される。FECパケット１０２−１および１０２−２は、他のバースト送信ユニットの前側に配置されて送信される。
【０１２５】
次に、図１２のフローチャートを参照して、クライアント１４の受信の処理を説明する。ステップＳ６１において、クライアント１４は、受信の処理に必要なデータを初期化する。例えば、ステップＳ６１において、クライアント１４のデコーダ９４は、内蔵しているタイマを初期値に設定する。より具体的には、例えば、デコーダ９４は、タイマの値を０に設定する。さらに、ステップＳ６１において、クライアント１４は、例えば、200ms程度の期間、数フレーム分の画像データを格納したパケットが受信されるまで、待機する。
【０１２６】
ステップＳ６２において、通信部９１は、通信網１３を介して、サーバ１２から送信されてきたパケットを受信する。例えば、通信部９１は、通信網１３を介して、バースト送信により、サーバ１２から送信されてきたFECパケットおよびRTPパケットを受信する。
【０１２７】
なお、より正確には、ステップＳ６２において、通信網１３を介して、サーバ１２からパケットが送信されてきたとき、通信部９１は、送信されてきたそのパケットを受信し、サーバ１２からパケットが送信されてこないとき、受信するパケットがないので、パケットを受信しないで（送信されてくるまで待機することなく）、ステップＳ６３に進む。
【０１２８】
ステップＳ６３において、通信部９１は、サーバ１２から送信されてきたパケットを受信したか否かを判定し、パケットを受信したと判定された場合、ステップＳ６４に進み、受信したパケットをバッファ９２に供給する。バッファ９２は、通信部９１から供給されたパケットを記憶し、ステップＳ６５に進む。
【０１２９】
ステップＳ６２乃至ステップＳ６４の処理により、１つのフレームの画像データを分割して格納する１または複数のパケットが、フレームを単位として、フレームの順に、バッファ９２に順次記憶されることになる。
【０１３０】
ステップＳ６３において、パケットを受信していないと判定された場合、ステップＳ６４の処理はスキップされ、処理は、ステップＳ６５に進む。
【０１３１】
ステップＳ６５において、デコーダ９４は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していないと判定された場合、ステップＳ６２に戻り、受信の処理を繰り返す。
【０１３２】
例えば、ステップＳ６５において、デコーダ９４は、タイマの値と、予め定めた33msとを比較することにより、タイマが終了したか否かを判定する。
【０１３３】
ステップＳ６５において、タイマが終了したと判定された場合、ステップＳ６６に進み、誤り訂正部９３は、ステップＳ６４の処理でバッファ９２に記憶された、１つのフレームの画像データを分割して格納するRTPパケットに誤りがあるか否かを判定する。例えば、ステップＳ６６において、誤り訂正部９３は、パケットロスがあるか否かを判定する。
【０１３４】
さらに詳細には、誤り訂正部９３は、バッファ９２に記憶されているRTPパケットのシーケンス番号から、飛んでいるシーケンス番号が検出して、パケットロスがあるか否かを判定する。
【０１３５】
すなわち、ステップＳ６６において、パケットを正常に受信できなかったか否かが判定される。
【０１３６】
ステップＳ６６において、パケットに誤りがあると判定された場合、ステップＳ６７に進み、誤り訂正部９３は、FECパケットを基に、RTPパケットの誤りを訂正し、ステップＳ６８に進む。
【０１３７】
ステップＳ６６において、パケットに誤りがないと判定された場合、誤りを訂正する必要はないので、ステップＳ６７の処理はスキップされ、手続きは、ステップＳ６８に進む。
【０１３８】
ステップＳ６８において、デコーダ９４は、バッファ９２から１フレーム分のRTPパケットを抽出して、抽出したRTPパケットから画像データをさらに抽出する。そして、デコーダ９４は、抽出された画像データを復号して、復号された画像データを出力する。
【０１３９】
ステップＳ６９において、デコーダ９４は、内蔵しているタイマをセットして、ステップＳ６２に戻り、上述した処理を繰り返す。
【０１４０】
このように、クライアント１４は、サーバ１２から送信されてきたRTPパケットおよびFECパケットを受信して、RTPパケットにパケットロスがあるとき、誤りを訂正して、誤りが訂正されたパケットを基に、画像データを復号することができる。
【０１４１】
FECパケットは、他のバースト送信ユニットの前側に配置されて送信されてくるので、パケットロスがよりすくなくなり、クライアント１４は、より確実にFECパケットを受信することができるので、より確実にRTPパケットの誤りを訂正することができるようになり、その結果、より確実に、より正確に、より高画質に、画像データを復号することができるようになる。
【０１４２】
なお、FECパケットは、他のバースト送信ユニットの直前に配置するだけでなく、他のバースト送信ユニットの前半に配置して、送信することができる。
【０１４３】
図１３は、FECパケットを他のバースト送信ユニットの前半に配置して送信する、サーバ１２による、送信の他の処理を説明するフローチャートである。
【０１４４】
ステップＳ８１乃至ステップＳ８４の処理のそれぞれは、図８のステップＳ４１乃至ステップＳ４４の処理のそれぞれと同様なので、その説明は省略する。
【０１４５】
ステップＳ８５およびステップＳ８６の処理のそれぞれは、図８のステップＳ４７およびステップＳ４８の処理のそれぞれと同様なので、その説明は省略する。
【０１４６】
ステップＳ８７において、FECパケット生成部７４は、ステップＳ５１の処理と同様の処理で、パケットバッファ８１に記憶されているRTPパケットを基に、FECパケットを生成する。
【０１４７】
ステップＳ８８において、FECパケット生成部７４は、ステップＳ８７の処理で生成したFECパケットをパケットバッファ８２に記憶する。
【０１４８】
ステップＳ８９において、RTPパケット生成部７３は、パケットバッファ８１に格納されている、１フレームの画像データを格納する所定の数のRTPパケットのうち、前半のRTPパケットを読み出して、読み出したRTPパケットを通信部３９に供給する。通信部３９は、RTPパケット生成部７３から供給された、前半のRTPパケットを通信網１３を介して、クライアント１４に送信する。
【０１４９】
ここで、前半のRTPパケットとは、パケットバッファ８１に格納されている、１フレームの画像データを格納する所定の数のRTPパケットの順序を基準として、パケットバッファ８１の前半分に格納されているRTPパケットを言うが、ステップＳ８９においては、１フレームの画像データを格納する所定の数のRTPパケットうち、半数以下のRTPパケットが、通信網１３を介して、クライアント１４に送信されるようにしてもよい。
【０１５０】
ステップＳ９０において、FECパケット生成部７４は、パケットバッファ８２に格納されている、１つ前のフレームを訂正するためのFECパケットを読み出して、読み出したFECパケットを通信部３９に供給する。通信部３９は、FECパケット生成部７４から供給された、１つ前のフレームを訂正するためのFECパケットを通信網１３を介して、クライアント１４に送信する。
【０１５１】
ステップＳ９１において、RTPパケット生成部７３は、パケットバッファ８１に格納されている、残りのRTPパケットを読み出して、読み出したRTPパケットを通信部３９に供給する。通信部３９は、RTPパケット生成部７３から供給された、残りのRTPパケットを通信網１３を介して、クライアント１４に送信する。
【０１５２】
ステップＳ９２およびステップＳ９３の処理のそれぞれは、図８のステップＳ５２およびステップＳ５３の処理のそれぞれと同様なので、その説明は省略する。
【０１５３】
このように、サーバ１２は、FECパケットを、他のバースト送信ユニットの前半、すなわち時間的に前側に配置して、送信することができる。
【０１５４】
以上のように、本発明においては、誤りを訂正するためのデータを格納する誤り訂正パケットが、誤りの訂正の対象となるデータを格納したパケットとは別に、時間的に離れて送信される。また、誤り訂正パケットは、バースト送信される、１群のパケットの前半に配置されて送信されるので、誤り訂正パケット自身のパケットロスの発生が抑制される。
【０１５５】
このように、誤り訂正パケットを送信するようにした場合には、誤りを訂正することができる。また、１または複数の送信パケットを含む第１の集合の相手への送信を制御し、第１の集合に属する送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成し、さらに、第１の集合に属する送信パケットの次の１または複数の送信パケットを含む第２の集合であって、送信の順番を基準として前半に、誤り訂正パケットが配置されている第２の集合の相手への送信を制御するようにした場合には、誤りを訂正するためのパケットのパケットロスをより少なくすることができる。
【０１５６】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１５７】
この記録媒体は、図５に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク５１（フレキシブルディスクを含む）、光ディスク５２（CD-ROM(Compact Disc-Read Only Memory)、ＤＶＤ(Digital Versatile Disc)を含む）、光磁気ディスク５３（ＭＤ(Mini-Disc)（商標）を含む）、若しくは半導体メモリ５４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM３２や、記憶部３８に含まれるハードディスクなどで構成される。
【０１５８】
なお、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインタフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
【０１５９】
また、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１６０】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【図面の簡単な説明】
【０１６１】
【図１】従来のFECパケットの送信を説明する図である。
【図２】従来のFECパケットの送信の順序を説明する図である。
【図３】従来のFECパケットを付加した送信の処理を説明するフローチャートである。
【図４】本発明に係る通信システムの一実施の形態を示す図である。
【図５】サーバの構成の例を示すブロック図である。
【図６】サーバの機能の構成を示すブロック図である。
【図７】クライアントの機能の構成を示すブロック図である。
【図８】送信の処理を説明するフローチャートである。
【図９】RTPパケットを説明する図である。
【図１０】FECパケットを説明する図である。
【図１１】サーバ１２によって送信され、クライアント１４によって受信されるRTPパケットおよびFECパケットの順序を説明する図である。
【図１２】クライアント１４の受信の処理を説明するフローチャートである。
【図１３】送信の他の処理を説明するフローチャートである。
【符号の説明】
【０１６２】
１２  サーバ，  １３  通信網，  １４  クライアント，  ３１  CPU，  ３２  ROM，  ３３  RAM，  ３８  記録部，  ５１  磁気ディスク，  ５２  光ディスク，  ５３  光磁気ディスク，  ５４  半導体メモリ，  ７１  エンコーダ，  ７２  バッファ，  ７３  RTPパケット生成部，  ７４  FECパケット生成部，  ８１  パケットバッファ，  ８２  パケットバッファ，  ９１  通信部，  ９２  バッファ，  ９３  誤り訂正部，  ９４  デコーダ
【図１】
2005136546.tif 000003
【図２】
2005136546.tif 000004
【図３】
2005136546.tif 000005
【図４】
2005136546.tif 000006
【図５】
2005136546.tif 000007
【図６】
2005136546.tif 000008
【図７】
2005136546.tif 000009
【図８】
2005136546.tif 000010
【図９】
2005136546.tif 000011
【図１０】
2005136546.tif 000012
【図１１】
2005136546.tif 000013
【図１２】
2005136546.tif 000014
【図１３】
2005136546.tif 000015