(57)【特許請求の範囲】
【請求項１】
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得手段と、
前記メディアパケット取得手段により取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信手段と、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間の経過前までに規定個数のメディアパケットが取得されたとき、前記規定個数のメディアパケットを用いてＦＥＣ演算処理を行って、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成手段と、
前記ＦＥＣパケット生成手段により生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記規定個数のメディアパケットの取得に要した時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信手段と、
を備えたＦＥＣ送信処理装置。
【請求項２】
前記ＦＥＣパケット生成手段は、前記あらかじめ定めたＦＥＣ時間の経過前までに前記規定個数のメディアパケットが取得されなかったときは、前記あらかじめ定めたＦＥＣ時間の経過前までに取得したメディアパケットから前記ＦＥＣ演算処理を行って複数のＦＥＣパケットを生成し、
前記ＦＥＣパケット送信手段は、当該複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記あらかじめ定められたＦＥＣ時間内で前記メディアパケット受信処理装置に送信する
請求項１に記載のＦＥＣ送信処理装置。
【請求項３】
前記規定個数は、前記ＦＥＣ演算処理可能なメディアパケットの最大個数であることを特徴とする請求項１または２に一項に記載の送信処理装置。
【請求項４】
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得ステップと、
前記メディアパケット取得ステップにより取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信ステップと、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間の経過前までに規定個数のメディアパケットが取得されたとき、前記規定個数のメディアパケットを用いてＦＥＣ演算処理を行って、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成ステップと、
前記ＦＥＣパケット生成ステップにより生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記規定個数のメディアパケットの取得に要した時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信ステップと、
を備えたＦＥＣ送信処理方法。
【請求項５】
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得ステップと、
前記メディアパケット取得ステップにより取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信ステップと、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間の経過前までに規定個数のメディアパケットが取得されたとき、前記規定個数のメディアパケットを用いてＦＥＣ演算処理を行って、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成ステップと、
前記ＦＥＣパケット生成ステップにより生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記規定個数のメディアパケットの取得に要した時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信ステップと、
をコンピュータに実行させるためのＦＥＣ送信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＦＥＣ送信処理装置、ならびにＦＥＣ送信処理のための方法およびプログラムに関する。
【背景技術】
【０００２】
ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ：リアルタイムトランスポートプロトコル）は、伝送するデータパケットについて、順序や処理タイミングなどの付加情報を併記することが可能な伝送プロトコルである。受信側で付加情報に基づき受信処理を実行することにより、受信したデータパケット（メディアパケット）は、伝送中に受ける擾乱の影響に関わらず、送信時と同一の状態を再現されたものとなる。ただし、ＲＴＰでは、順序の入れ替えや伝送間隔の揺らぎを回復することは可能であるが、損失については検出のみ可能であり回復することはできない。
【０００３】
動画や音声などのリアルタイム・ストリーミングでは、データの損失が動画や音声の再生品質を劣化させる要因となるため、適切に回復措置を講じることが望ましい。このための手法で一般的なものとして、再送を用いるものと誤り訂正符号を用いるものがある。
【０００４】
最も単純な回復措置として、欠損パケットが生じた場合に再送を要求する手法があるが、リアルタイム・ストリーミング伝送での適用は必ずしも適さない。この原因として、上位アプリに対するデータの配送を一定とするため再送データを受信するまでにその前後のデータを滞留させる必要があり、伝搬時間が長ければ大きな遅延が生ずることや、欠損が生じる伝送路では再送データすらも確実に受信できる保証がないことがある。また、放送型の伝送など単一方向の通信である場合など、受信側のフィードバックが不能ならば、そもそも再送を要求することができない。
【０００５】
一方、誤り訂正符号を用いる手法があり、実用的なものとしてＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ：前方向誤り訂正）符号化伝送による回復措置が知られている。ＦＥＣでは、元データをグループ化し、予め決められた手法で演算して各グループ（演算単位）に対する冗長データ生成し、ＦＥＣパケットに冗長データを格納して元データと並列に伝送する。受信側では、各グループ内で一部の元データが欠損した場合に、残りの元データと対応する冗長データから予め決められた手法で演算し、欠損した元データを回復することが可能となる。この場合、冗長データと元データがほとんど遅滞なく伝送されるため受信側では即時に回復が可能となり、処理にかかる遅延は再送と比べて小さくなる。
【０００６】
従来、ＲＴＰに適用する一般的なＦＥＣ方式として、ＲＦＣ２７３３で規定された方式がある。また、この方式を映像伝送向けに改善したＰｒｏ−ＭＰＥＧフォーラムで規定された方式がある（非特許文献１）。これは、レートが低い場合には高々１つの欠損しか生じない程度の擾乱であっても、レートが高い場合に複数の連続した欠損が生ずることとなる現象を踏まえ、複数の連続した欠損に対する回復性能の向上を図ったものである。具体的には、複数のデータパケットをマトリクス上に整列させた後、各行列でグループ化してＦＥＣ符号化を実施し、各グループからそれぞれＦＥＣパケットを生成する。この場合、各行と列がＦＥＣの１つのグループ（演算単位）となるため、たとえば、ある横一行にわたって連続する欠損は複数の縦列グループの各々で高々１つの欠損として処理できる。
【０００７】
ここでＰｒｏ−ＭＰＥＧのＦＥＣ方式では、符号化ブロック（マトリクス）に対する複数のＦＥＣパケットの伝送を、次のマトリクスが伝送される範囲内で送出するものと規定している。つまり受信側では、ＦＥＣパケットを受信するまでにマトリクス１つ分の待機遅延が必要となるが、この遅延時間はレートが高い場合に極めて小さなものとなり、他の方式と比べれば問題とならない程度である。また、データパケットとＦＥＣパケットの伝送ずれにより伝送中の擾乱で両者を同時に欠損することの回避を期待できる上、データパケットの滞留なく送出時の符号化を実施可能となるため遅延が発生しないこと、ＦＥＣパケットの伝送レートを一定に平滑化しやすくすること等の利点が大きい。ＦＥＣパケットの送出範囲が守られなければ、ＦＥＣパケットの伝送レートが一時的でも想定よりも増大し、帯域予約による制約を受けているネットワーク上での伝送に支障をきたしてしまう。この場合、予約帯域を超過したＦＥＣパケットは破棄されるか、強制的にレート低下されることで全体的に遅延する等の問題が発生し、受信装置で正常にＦＥＣ符号化処理が出来なくなってしまう。
【０００８】
このように、総合的に見れば合理的なＦＥＣパケットの送出規定であると言えるが、そもそもＰｒｏ−ＭＰＥＧのＦＥＣ方式では固定レート（ＣＢＲ）のストリームのみを対象としており、変動レート（ＶＢＲ）のストリームは対象としていなかった。よって、変動レート（ＶＢＲ）のストリームにおいて、ＦＥＣパケットの送出範囲とその伝送レート制限を同時に満たし効率的にマトリクスを形成するＦＥＣ方式は存在しなかった。
【非特許文献１】“Ｐｒｏ−ＭＰＥＧ  Ｃｏｄｅ  ｏｆ  Ｐｒａｃｔｉｃｅ  ＃３  ｒｅｌｅａｓｅ  ２”，  Ｐｒｏ−ＭＰＥＧ  Ｆｏｒｕｍ，  Ｊｕｌｙ  ２００４
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、メディアパケットのレートが変動する場合においても、１つの符号化ブロックから複数のＦＥＣパケットを効率的に生成および送信するＦＥＣ方式を用いることを可能としたＦＥＣ送信処理装置、ならびにＦＥＣ送信処理のための方法およびプログラムを提供する。
【課題を解決するための手段】
【００１０】
本発明の一態様としてのＦＥＣ送信処理装置は、
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得手段と、
前記メディアパケット取得手段により取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信手段と、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間内に取得されたメディアパケット群を用いてＦＥＣ演算処理を行うことにより、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成手段と、
生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記あらかじめ定められたＦＥＣ時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信手段と、
を備える。
【００１１】
本発明の一態様としてのＦＥＣ送信処理方法は、
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得ステップと、
前記メディアパケット取得ステップにより取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信ステップと、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間内に取得されたメディアパケット群を用いてＦＥＣ演算処理を行うことにより、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成ステップと、
生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記あらかじめ定められたＦＥＣ時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信ステップと、
を備える。
【００１２】
本発明の一態様としてのＦＥＣ送信処理プログラムは、
メディアパケットを生成するメディアパケット生成装置からメディアパケットを逐次取得するメディアパケット取得ステップと、
前記メディアパケット取得ステップにより取得されたメディアパケットを、メディアパケットを受信処理するメディアパケット受信処理装置にネットワークを介して送信するメディアパケット送信ステップと、
直前に処理したメディアパケット群の後最初に取得されたメディアパケットの取得からあらかじめ定めたＦＥＣ時間内に取得されたメディアパケット群を用いてＦＥＣ演算処理を行うことにより、前記メディアパケット受信処理装置において損失メディアパケットを回復するための複数のＦＥＣパケットを生成するＦＥＣパケット生成ステップと、
生成された複数のＦＥＣパケットを、前記最初に取得されたメディアパケットを取得してから前記あらかじめ定められたＦＥＣ時間の経過後、前記あらかじめ定められたＦＥＣ時間内で前記メディアパケット受信処理装置に送信するＦＥＣパケット送信ステップと、
をコンピュータに実行させる。
【発明の効果】
【００１３】
本発明により、メディアパケットのレートが変動する場合においても、１つの符号化ブロックから複数のＦＥＣパケットを効率的に生成および送信するＦＥＣ方式を用いることが可能となる。
【発明を実施するための最良の形態】
【００１４】
本発明者らが本発明を着想するに至った技術的背景について説明する。
【００１５】
背景技術の欄で述べたように、Ｐｒｏ−ＭＰＥＧのＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ：前方向誤り訂正）方式では固定レート（ＣＢＲ：Ｃｏｎｓｔａｎｔ  Ｂｉｔ  Ｒａｔｅ）のストリームのみを対象としており、変動レート（ＶＢＲ：Ｖａｒｉａｂｌｅ  Ｂｉｔ  Ｒａｔｅ）のストリームは対象としていなかった。この理由として、マトリクスを形成するＦＥＣ方式において、固定レートで適用可能な条件が変動レートでは適用できないことがある。すなわちデータレートが変動する場合に通常考えられる対処方法では、次に述べる問題が発生する。
【００１６】
データレートが変動する場合に、各マトリクスを構成するデータパケット数を一定に保つとする。この場合、マトリクス毎で符号化にかかる時間が変動する結果となるため、ＦＥＣパケットの送出範囲に対応する時間も変動することとなり、ＦＥＣパケットの伝送レートが一定とならない。この場合に受信側では、最低レートの場合の送出範囲に対応するつまり最大の符号化時間を遅延時間として設定しておかなければ、受信処理においてデータパケットの枯渇（アンダーフロー）が発生する。このため、一部のデータが原因で全てのデータに関するＦＥＣ処理に要する遅延時間が必要以上に長くなってしまう。ＦＥＣパケットの伝送レートを単純に平滑化した場合は、想定よりも高いレートの場合に低いレートとして伝送されることになるため、さらに遅延時間が長くなってしまい予測不能ともなりうる。
【００１７】
これに対し、不足数をパディングデータ等で補充することにより、全てのマトリクスで構成するデータパケット数を一定とする方法がある。例えばデジタル放送において、無線上を一定レートで伝送する必要があるため、パディングと同等のＮＵＬＬ−ＴＳパケットを用い元の変動レートのストリームを固定レート化した後に伝送するものがある。これをＩＰ上で伝送する際、ネットワーク帯域の有効利用という点から見ればパディングの様な無駄な帯域の消費は望ましくない。このため、不要であるＮＵＬＬ−ＴＳパケットは除き変動レートとして伝送することが望ましい。この変動ストリームにパディングをすると、変動ストリームの最大レートにあわせた固定レートとなるため、ＮＵＬＬ−ＴＳパケットを除いた効果が小さくなり、帯域の有効利用を実現できない。
【００１８】
以上のように、変動レートに上記ＦＥＣ方式を適用する手法として、固定レートの場合と同様にしてマトリクスを構成するデータパケット数を一定に保つことが考えられるが、遅延時間の長大化および帯域の無駄な消費のため、適用は現実的でない。
【００１９】
本発明は、このような問題を発生させることなく、変動レートの場合に、マトリクスを形成するＦＥＣ方式（１つの符号化ブロックから複数のＦＥＣパケットを生成するＦＥＣ方式）を適用可能にするものである。以下、本発明の実施形態について説明する。
【００２０】
（第１の実施形態）
図１は、本発明の第１の実施形態に係わるＦＥＣ送信処理装置の構成を示すブロック図である。
【００２１】
ＦＥＣ符号化手段１１は、変動レート（ＶＢＲ）でＲＴＰデータパケット（メディアパケット）を生成するＲＴＰデータパケット生成装置２１により生成されたＲＴＰデータパケットを逐次取得する。ＦＥＣ符号化手段１１は、あらかじめ定めた固定の符号化時間（ＦＥＣ時間）α内に取得（入力）されるＲＴＰデータパケットを対象に、ＲＴＰデータパケットを取得するごとに、逐次、ＦＥＣ符号化処理を行う。より詳細には、直前に処理したＲＴＰデータパケット群の後最初に取得されたＲＴＰデータパケットの取得からあらかじめ定めた符号化時間α内に取得された複数のＲＴＰデータパケット（これら複数のＲＴＰデータパケットの集合を符号化ブロック、マトリクス、あるいはメディアパケット群と称する）を対象として、ＲＴＰデータパケットが取得されるごとに、ＦＥＣ符号化処理を行う。これにより１つの符号化ブロックから複数の冗長データを生成する。またＦＥＣ符号化処理手段１１は、ＲＴＰデータパケットを取得するごとに、またはＲＴＰデータパケットに対するＦＥＣ符号化処理を行うごとに、ＲＴＰデータパケットをＲＴＰデータパケット送信手段１３に渡す。ＲＴＰデータパケットは、ＦＥＣ符号化手段１１を経由せず、ＲＴＰデータパケット生成装置２１から直接、ＲＴＰデータパケット送信手段１３に渡すようにしてもよい。
【００２２】
ここでＲＴＰデータパケットには受信側のＦＥＣ受信処理装置４１で再生するべきメディアデータ、順序番号、タイムスタンプ等が含まれている。ＲＴＰデータパケット生成装置２１は、ＦＥＣ送信処理装置と同一装置に含まれていてもよいし、ＦＥＣ送信処理装置と異なる装置に含まれていても良い。
【００２３】
ＲＴＰデータパケット送信手段１３は、ＦＥＣ符号化処理手段から渡されたＲＴＰデータパケットを、ＲＴＰデータパケットを受信処理するＦＥＣ受信処理装置４１にネットワーク３１を介して送信する。
【００２４】
ＦＥＣパケット生成手段１４は、ＦＥＣ符号化手段１１により生成された冗長データと、冗長データを生成するもととなったＲＴＰデータパケットを特定する情報等を含むＦＥＣパケットを、各生成された冗長データ毎に、生成する（ＦＥＣパケット生成処理）。すなわち冗長データの個数と同数のＦＥＣパケットを生成する。ＦＥＣパケットは、ＦＥＣ受信処理装置（メディアパケット受信処理装置）４１において、ネットワーク３１等で損失した損失メディアパケットを回復するためのものである。ＦＥＣ符号化処理と、ＦＥＣパケット生成処理とを合わせて、ＦＥＣ演算処理と称するものとする。
【００２５】
ＦＥＣパケットバッファリング手段１５は、ＦＥＣパケット生成手段１４により生成されたＦＥＣパケットをバッファリングする。
【００２６】
演算開始時刻記録手段１２は、符号化ブロック（マトリクス）内で、最初に取得されたＲＴＰデータパケットが取得された時刻（演算開始時刻）Ｔを記録する。
【００２７】
ＦＥＣパケット送信手段１６は、符号化ブロックに対して生成された複数のＦＥＣパケットを、この符号化ブロックにおいて最初に取得されたメディアパケットの時刻（演算開始時刻）Ｔに符号化時間αを加算した時刻から、当該符号化時間α内で分散してＦＥＣ受信処理装置４１に送信する。つまり、最初にメディアパケットを取得してから符号化時間α経過後、符号化時間α内でＦＥＣパケットを送信する。符号化ブロック毎にＦＥＣパケットを生成および送信する様子を図５に一例として示す。符号化ブロックごとに符号化時間αをかけて符号化処理を行い、演算開始時刻Ｔから符号化時間αの経過後、符号化時間α内で、ＦＥＣパケットを分散して送信している。
【００２８】
図２は、ＦＥＣ演算処理（ＦＥＣ符号化処理およびＦＥＣパケット生成処理）の例を説明する図である。
【００２９】
ここでは１００個のＲＴＰデータパケット（符号化ブロック）を用いた例が示される。ＦＥＣ符号化手段１１は、これらのＲＴＰデータパケットを正方形状に整列させてマトリクスを形成し、１０行の横列グループと、１０列の縦列グループとを形成する。縦列グループ（演算単位）ごとにＲＴＰデータパケット群を演算（ここではＸＯＲ）して冗長データを計算する。ＦＥＣパケット生成手段１４は、各縦列グループから計算した冗長データを用いてＦＥＣパケットＦ１〜Ｆ１０を生成する。ＦＥＣパケットには、冗長データと、冗長データを生成する元となったＲＴＰデータパケット（冗長データに対応する縦列グループ内のＲＴＰデータパケット）を特定する情報と、ＲＴＰデータパケットとは異なる系列の順序番号などが含まれる。例えばＦＥＣパケットＦ１には冗長データと、この冗長データに関連づけられるＲＴＰデータパケット１、１１、２１、３１、・・・、８１、９１を特定する情報などが含まれる。本実施形態では縦列グループからのみ冗長データおよびＦＥＣパケットを生成することとするが、縦列グループに加え、横列グループからも冗長データおよびＦＥＣパケットを生成することも可能である。
【００３０】
図３は、図１のＦＥＣ送信処理装置の動作例を示すフローチャートである。図４は、ＦＥＣ送信処理装置における特にＦＥＣパケット送信手段１６の動作例を説明するフローチャートである。
【００３１】
図３において、ＦＥＣ符号化手段１１は、ＲＴＰデータパケット生成装置２１から、送信するＲＴＰデータパケットの入力を受け、受け取ったＲＴＰデータパケットを一時的に記録する（Ｓ１）。
【００３２】
続いて、ＦＥＣ符号化手段１１は、取得したＲＴＰデータパケットが符号化ブロックの最初にあたる場合は（Ｓ２のＹＥＳ）、演算開始時刻記録手段１２にＲＴＰデータパケットを受け取った時刻（演算開始時刻）Ｔを記録させる（Ｓ３）。取得したＲＴＰデータパケットが符号化ブロックの最初に当たらない場合は（Ｓ２のＮＯ）、ステップＳ３を行わずに、ステップＳ４に進む。
【００３３】
ＦＥＣ符号化手段１１は、受け取ったＲＴＰデータパケットを用いてＦＥＣ符号化処理を実施する（Ｓ４）。先に示した図２の例では、受け取ったＲＴＰデータパケットが縦列ブロックの先頭である場合は、ステップＳ４ではそのＲＴＰデータパケットを保持する。ＲＴＰデータパケットが縦列ブロックにおける先頭から２番目のときは、１番目のＲＴＰデータパケットと演算（たとえばＸＯＲ）を行って、演算値を得る。ＲＴＰデータパケットが縦列ブロックにおける先頭から３番目のときは、１番目と２番目のＲＴＰデータパケットから得られた演算値との演算（たとえばＸＯＲ）を行う。このようにしてＦＥＣ符号化手段１１は、ＲＴＰデータパケットを受け取るごとに、ＦＥＣ符号化処理を行う。
【００３４】
ＦＥＣ符号化手段１１は、該当の符号化ブロックについて、最初に取得したＲＴＰデータパケットの演算開始時刻Ｔから、あらかじめ定めた符号化時間αが経過したかを、判定する（Ｓ５）。
【００３５】
演算開始時刻Ｔから符号化時間αが経過していない場合（Ｓ５のＮＯ）ステップＳ９に進む。
【００３６】
一方、演算開始時刻Ｔから符号化時間αが経過した場合（Ｓ５のＹＥＳ）、ＦＥＣパケット生成手段１４は、ステップＳ４のＦＥＣ符号化処理により得られた複数の冗長データ、および複数の冗長データを生成する元となったＲＴＰデータパケットの識別子等を用いて、複数のＦＥＣパケットを生成する（Ｓ６）。
【００３７】
ＦＥＣパケットバッファリング手段１５は、ＦＥＣパケット生成手段１４により生成された複数のＦＥＣパケットを、実際に送信されるまでバッファリングする（Ｓ７）。
【００３８】
ＦＥＣ符号化手段１１は、次の符号化ブロックに処理を移行するように（次に入力されるＲＴＰデータパケットが符号化ブロックの最初のＲＴＰデータパケットとして取り扱われるように）、構成を切り替える（Ｓ８）。
【００３９】
ＲＴＰデータパケット送信手段１３は、ステップＳ１で入力されたＲＴＰデータパケットを送信する（Ｓ９）。このＲＴＰデータパケットの送信は、ステップＳ４の直後に行っても良い。
【００４０】
終了指示が入力されたかどうかを判定し（Ｓ１０）、入力されていないときは（Ｓ１０のＮＯ）ステップＳ１に戻り、入力されたときは（Ｓ１０のＹＥＳ）本処理を終了する。
【００４１】
図４において、ＦＥＣパケット送信手段１６は、ＦＥＣパケットバッファリング手段１５にＦＥＣパケットがある場合に（Ｓ２１のＹＥＳ）、現在時刻が送信タイミングであれば（Ｓ２２のＹＥＳ）、ＦＥＣパケットバッファリング手段１５からＦＥＣパケットを取り出し（Ｓ２３）、取り出したＦＥＣパケットを送信する（Ｓ２４）。
【００４２】
このときの送信タイミングは、たとえば
演算開始時刻Ｔ＋符号化時間α＋符号化時間α×（該当符号化ブロック内の先頭からの個数／該当符号化ブロック内の全個数）で決定される。あるいは、演算開始時刻Ｔ＋符号化時間αから、あらかじめ定めた一定のタイミングで、演算開始時刻Ｔ＋符号化時間αから、符号化時間α内に送信する。
【００４３】
図４のＦＥＣパケットの送信フローは、定期的に呼び出されるか、あるいは図３のステップＳ９またはＳ１０の後に呼び出される。
【００４４】
このように、本実施の形態では、各符号化ブロック（マトリクス）に対する符号化時間（ＦＥＣ時間）を一定に保つとともに、符号化ブロックにおける最初のＲＴＰデータパケットの取得時刻から符号化時間α後に符号化時間α内でＦＥＣパケットを送信するようにしたことにより、変動レートの場合においても遅延をできるだけ生じさせずにＦＥＣパケットを送信することができ、また各符号化ブロック間でＦＥＣパケットの送信が重複することを防ぐことができる（図５参照）。
【００４５】
（第２の実施形態）
第１の実施形態では、各マトリクスに対する符号化時間を一定に保つようにしたため、マトリクス毎のＲＴＰデータパケット数が変動し得る。このため、符号化時間の長さによっては、ＦＥＣ符号化処理可能なＲＴＰデータパケットの最大数（１つのマトリクスに含めることのできるＲＴＰデータパケットの最大数）を超過したＲＴＰデータパケット数が入力されることもあり得る。
【００４６】
そこで、本実施形態では、ＲＴＰデータパケット送信手段１３により最大の送信レートでＲＴＰデータパケットが送信される（ＲＴＰデータパケット生成装置２１によりＲＴＰデータパケットが最大レートで生成される）ときに、ＦＥＣ符号化処理可能なＲＴＰデータパケットの最大数（規定個数）のＲＴＰデータパケットが入力（取得）されるのに要される時間（最小符号化時間）を、符号化時間αとして設定する。これにより、符号化時間α内に、ＲＴＰデータパケットが最大数を超過して取得されることを防ぐことができる。
【００４７】
（第３の実施形態）
本実施形態では、第２の実施形態と異なる手法（第１の方式および第２の方式）で、第１の実施形態の問題点を解決する。
【００４８】
（第１の方式）１つの符号化ブロックに含めることのできる最大数（あるいは規定個数。以下最大数に統一）のＲＴＰデータパケットが取得されたときは、取得された時点で、符号化時間αの経過を待つことなく、取得された最大数のＲＴＰデータパケットから複数のＦＥＣパケットを生成する。そして、生成した複数のＦＥＣパケットを、最大数のＲＴＰデータパケットが取得された時刻、すなわち符号化ブロックの中で最初に入力されたＲＴＰデータパケットの演算開始時間ＴにＲＴＰデータパケットの取得（符号化処理）に要した時間（経過時間）βを加算した時刻、から、符号化時間α内で分散して送信する。なお、符号化時間α内に最大数のＲＴＰデータパケットが取得されない場合は、第１の実施形態と同様に、符号化時間α内に取得されたＲＴＰデータパケットを用いてＦＥＣパケットを生成し、次の符号化時間α内で、生成されたＦＥＣパケットを分散して送信する。したがって、本方式では、ＦＥＣパケットの送信タイミングは以下のようになる。
【００４９】
演算開始時刻Ｔ＋経過時間β＋符号化時間α×（該当符号化ブロック内の先頭からの個数／該当符号化ブロック内の全個数）で決定する。あるいは、開始時刻Ｔ＋経過時間βから、あらかじめ定めた一定のタイミングで、開始時刻Ｔ＋経過時間βから経過時間αで送信する。ここで経過時間βは、最大数のＲＴＰデータパケットの取得に要した時間あるいは符号化時間αで、符号化時間αに一致するとき（たとえば符号化時間α内に最大数のＲＴＰデータパケットが取得されない場合）が最大値である。
【００５０】
本方式を適用してＦＥＣパケットを生成および送信する様子を図６に示す。ここでは上から２番目の符号化ブロックに関して、符号化時間αより短い３α／４（＝β）で最大数のＲＴＰデータパケットが取得されたため、これらのＲＴＰデータからＦＥＣパケットを生成し、時刻（Ｔ＋３α／４）から、符号化時間α内で分散して、生成したＦＥＣパケットを送信する例が示されている。
【００５１】
本方式によれば、第２の実施形態の様に符号化時間αを最小符号化時間とする必要がなくなり、レートが低くなった場合にＦＥＣの冗長度が過剰となることを防ぐことができる。
【００５２】
（第２の方式）第１の方式では、ＦＥＣパケットを送信する時間は、演算開始時刻Ｔ＋経過時間βから符号化時間αとしたが、本方式では、演算開始時刻Ｔ＋経過時間βから経過時間βとする。なお、符号化時間α内に最大数のＲＴＰデータパケットが取得されない場合は、したがって、本方式では、ＦＥＣパケットの送信タイミングは以下の通りになる。
【００５３】
開始時刻Ｔ＋経過時間β＋経過時間β×（該当符号化ブロック内の先頭からの個数／該当符号化ブロック内の全個数）で決定する。あるいは、開始時刻Ｔ＋経過時間αから、あらかじめ定めた一定のタイミングで、開始時刻Ｔ＋経過時間βから経過時間βで送信する。ここで経過時間βは、最大数のＲＴＰデータパケットの取得に要した時間あるいは符号化時間αで、符号化時間αに一致するときが最大値である。
【００５４】
本方式を適用してＦＥＣパケットを生成および送信する様子を図７に示す。ここでは上から２番目の符号化ブロックに関して、符号化時間αより短い３α／４（＝β）で最大数のＲＴＰデータパケットが取得されたため、演算開始時刻Ｔから３α／４（＝β）が経過した時点で、最大数のＲＴＰデータからＦＥＣパケットを生成し、時刻（Ｔ＋３α／４）から、符号化時間α内で分散して、生成したＦＥＣパケットを送信する例が示されている。
【００５５】
本方式によれば、第１の方式の効果に加え、受信側ではＦＥＣ符号化処理を早いタイミングで処理できるようになるため、複数のＦＥＣ符号化処理を組み合わせている場合などに、回復率の向上を期待することができる。
【００５６】
ここで第１および第２の方式を実現する具体的構成としては図８に示すように、図１の装置に対し、経過時間βを記録する経過時間記録手段１７を追加する。経過時間記録手段１７は、最大数のＲＴＰデータパケットに対する符号化処理を完了したときまたは符号化時間αが経過したときに、完了時刻と演算開始時刻Ｔとの差または符号化時間αを、経過時間βとして記録する。ＦＥＣパケット送信手段１６がこの経過時間βを利用して送信タイミングを計算し、送信動作を行う。
【００５７】
図９は、本実施形態に関わる動作の流れを示すフローチャートである。図３のフローチャートのステップＳ５が、ステップＳ１１に代わり、また、新たなステップＳ１２が追加されている。以下、図３との差分についてのみ説明する。
【００５８】
ステップＳ１１では、該当の符号化ブロックについて、入力された（あるいは符号化された）ＲＴＰデータパケットの個数が最大数Ｎに達したか、あるいは演算開始時刻Ｔから符号化時間αが経過したかを判定する。いずれかが成立した場合（Ｓ１１のＹＥＳ）、開始時刻Ｔからの経過時間βを、経過時間記録手段１７に記録させる（Ｓ１２）。いずれも成立しない場合は（Ｓ１１のＮＯ）、ステップＳ９に進む。
【００５９】
ＦＥＣパケット送信手段１６の動作フローは図４と同じであるが、ステップＳ２２で行う送信タイミングの判定が第１の実施形態と異なる。本実施形態では、送信タイミングは方式１か方式２からに応じて前述した通りに決定される決定される。
【００６０】
（第４の実施形態）
第３の実施形態では、生成したＦＥＣパケットを、上記演算開始時刻Ｔに経過時間βを加算した時刻から、符号化時間αまたは経過時間β内で分散して送信するため、ある符号化ブロックから生成されたＦＥＣパケットの送出時間と、次の符号化ブロックから生成されたＦＥＣパケットの送出時間が重複する場合も当然生じる（図６および図７参照）。このとき、ネットワーク３１上においてＦＥＣパケットのレートが一時的に増大し、帯域予約による制約を受けているネットワーク上での伝送に支障をきたしてしまい、受信装置で正常にＦＥＣ符号化処理が出来なくなってしまう。
【００６１】
一方、第２の実施形態では、ＲＴＰデータパケットの最大の送信レート（生成レート）に対応して上記最小符号化時間を符号化時間αとして設定したが、この場合、送信レート（生成レート）が最大もしくはこれに近い場合はよいが、送信レート（生成レート）が低くなった場合に、過剰な符号化処理が実行される問題がある。すなわち、ＲＴＰデータパケットの送信レートが低い場合も、ＦＥＣパケットが常にＲＴＰデータパケットの最大レートのときと同一レートで送出されることになり、ＦＥＣ演算処理の冗長度が必要以上に大きくなってしまう。さらに、極端にＲＴＰデータパケットの送信レートが低下した場合には、ＦＥＣパケットの伝送レートが一時的に増大してしまい、帯域予約するネットワーク３１での運用に支障をきたす。
【００６２】
たとえばデジタル放送では、番組の内容やデータ放送の内容、まだら運用などの結果、データパケットの平均的なレートが大きく変動する。この場合に、小さなレートで伝送されるデータに対し、大きなレートの場合と同一の符号化時間を単純に適用すると、データパケットに対するＦＥＣパケットの割合すなわち冗長度が必要以上に大きくなってしまい効率が悪く、帯域の有効利用を実現できない。また、デジタルシネマなどさらにレートが高いストリームが出現してきているが、この場合は常に最大レートでの伝送が必要とはならない場合も考えられる。この場合、現在のエンコーダでは見られない、極めて一時的にレートが増大することもあるが、通常はある程度のレートで一定という運用も考慮する必要がある。
【００６３】
本実施形態は、このような第２および第３の実施形態で生じうる問題点を解決する。本実施形態は、ＦＥＣパケットの生成については第２および第３の実施形態と同一であるが、ＦＥＣパケットの送信時間（送信タイミング）がこれらの実施形態と異なる。
【００６４】
すなわち、本実施形態では、第２および第３の実施形態と同様に、符号化時間α内に最大数のＲＴＰデータパケットが取得されたときは、取得された時点で（符号化時間αの経過を待たずに）、取得された最大数のＲＴＰデータパケットからＦＥＣパケットを生成する。また、符号化時間α内に最大数のＲＴＰデータパケットが取得されない場合は符号化時間α内で取得されたＲＴＰデータパケットからＦＥＣパケットを生成する。ただし、ＦＥＣパケットの送信は、本実施形態では、演算開始時刻Ｔに符号化時間αを加算した時刻から経過時間β内で分散して行う。したがって、送信タイミングはたとえば以下のようにして決定する。
【００６５】
演算開始時刻Ｔ＋符号化時間α＋経過時間β×（該当符号化ブロック内の先頭からの個数／該当符号化ブロック内の全個数）で決定する。あるいは、開始時刻Ｔ＋符号化時間αから、あらかじめ定めた一定のタイミングで、開始時刻Ｔ＋符号化時間αから経過時間βで送信する。
【００６６】
本実施形態に従ってＦＥＣパケットを生成および送信する様子を図１０に示す。図６および図７と比較して分かるように、演算開始時刻Ｔから符号化時間αを待った後、経過時間β内でＦＥＣパケットを送信するため、各符号化ブロックから生成されたＦＥＣパケットの送出時間が重複することはない。したがってＦＥＣパケットのレートが一時的に増大して、帯域予約による制約を受けているネットワーク上での伝送に支障をきたすこともない。また符号化時間αとして適度な値を設定（第２の実施形態での最小符号化時間より大きい値）を設定することで、ＦＥＣパケットの送信レートが想定外に増大する問題も解消され、帯域の有効な利用が可能となる。これは、帯域予約を行うが空き帯域は別の通信で利用可能という運用において、通信帯域の利用効率性を一段と向上させるものである。また、ＦＥＣ処理の冗長度を必要量に抑え、伝送レートが一時的に想定外に増大する問題を解決し、帯域の有効な利用を可能とする。
【００６７】
本実施形態のブロック図は、第３の実施形態で用いた図８と同じであり、また動作フローも第３の実施形態で用いた図９および図４と同じであるが、図４のステップＳ２２で行う送信タイミングの判定のみが第３の実施形態と異なり、本実施形態では、上記した式にしたがう。
【００６８】
なお、このＦＥＣ送信処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、ＦＥＣ符号化手段１１、演算開始時刻記録手段１２、経過時間記録手段１７、ＦＥＣパケット生成手段１４、ＦＥＣパケットバッファリング手段１５、ＦＥＣパケット送信手段１６、ＲＴＰデータパケット送信手段１３は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、ＦＥＣ送信処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。
【００６９】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００７０】
【図１】本発明の第１の実施形態に係わるＦＥＣ送信処理装置の構成を示すブロック図。
【図２】ＦＥＣ演算処理（ＦＥＣ符号化処理およびＦＥＣパケット生成処理）の例を説明する図。
【図３】図１のＦＥＣ送信処理装置の動作例を示すフローチャートである。
【図４】ＦＥＣ送信処理装置におけるＦＥＣパケット送信手段の動作例を説明するフローチャート。
【図５】符号化ブロック毎にＦＥＣパケットを生成および送信する様子を示す図。
【図６】本発明の第３の実施形態における第１の方式を適用してＦＥＣパケットを生成および送信する様子を示す図。
【図７】本発明の第３の実施形態における第２の方式を適用してＦＥＣパケットを生成および送信する様子を示す図。
【図８】本発明の第３の実施形態に係わるＦＥＣ送信処理装置の構成を示すブロック図。
【図９】本発明の第３の実施形態に関わる動作の流れを示すフローチャート。
【図１０】第４の実施形態に従ってＦＥＣパケットを生成および送信する様子を示す図。
【符号の説明】
【００７１】
１１：ＦＥＣ符号化手段
１２：演算開始時刻記録手段
１３：ＲＴＰデータパケット送信手段
１４：ＦＥＣパケット生成手段
１５：ＦＥＣパケットバッファリング手段
１６：ＦＥＣパケット送信手段
１７：経過時間記録手段
２１：ＲＴＰデータパケット生成装置
３１：ネットワーク
４１：ＦＥＣ受信処理装置
【図１】
0005075536.tif 000002
【図２】
0005075536.tif 000003
【図３】
0005075536.tif 000004
【図４】
0005075536.tif 000005
【図５】
0005075536.tif 000006
【図６】
0005075536.tif 000007
【図７】
0005075536.tif 000008
【図８】
0005075536.tif 000009
【図９】
0005075536.tif 000010
【図１０】
0005075536.tif 000011