JP7269112B2 - 受信装置及びプログラム - Google Patents

Description

本発明は、ＦＴＴＨ（Fiber To The Home）、ＬＴＥ（Long Term Evolution）等のＩＰ（Internet Protocol）回線によるＩＰ放送、地上放送または衛星放送のＩＰ再送信、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）等のモバイル通信の放送モードによるＩＰ放送及びＩＰ再送信、ＶＯＤ（Video On Demand）サービスによるＵＤＰ（User Datagram Protocol）／ＩＰマルチキャスト及びＵＤＰ／ＩＰユニキャストでの映像配信等に用いる送信装置、受信装置及びプログラムに関し、特に、伝送路上で損失したパケットを復元する誤り訂正技術に関する。

従来、デジタル放送で用いられるＭＰＥＧ－２ ＴＳ（Transport Stream：トランスポートストリーム）に代わるＩＰベースの新たなメディアトランスポート方式の国際標準規格として、ＭＭＴ（MPEG Media Transport）が知られている（非特許文献１を参照）。また、デジタル放送サービスにおけるＭＭＴの利用方法が規格化されている（非特許文献２を参照）。２０１８年１２月には、ＭＭＴを採用した新４Ｋ８Ｋ衛星放送が開始された。

デジタル放送では、ＭＰＥＧ－２ Ｖｉｄｅｏ、ＭＰＥＧ－４ ＡＶＣ（Advanced Video Coding）、ＭＰＥＧ－Ｈ ＨＥＶＣ（High Efficiency Video Coding）等の映像符号化方式を用いて映像信号を情報圧縮して伝送する。

一般に、映像符号化における情報圧縮は、単一フレーム内の小領域の近傍類似性による情報圧縮と、時間方向に連続するフレーム間の近傍類似性による情報圧縮を組み合わせて行われる。

ただし、任意のタイミングから再生を開始可能なランダムアクセス性を確保するために、一定周期で、時間方向のフレーム間での情報圧縮を使用せず、単一フレーム内で完結した情報圧縮を行うフレームの挿入が必要である。一般に、このようなフレームを「Ｉ（Intra）フレーム」という。また、符号化順でＩフレームから次のＩフレームの前のフレームまでの間の複数のフレームの集合を、「ＧＯＰ（Group of Picture）」という。

ＧＯＰ内の符号化順において、Ｉフレームより後方に位置するフレームは、Ｉフレームからの差分情報を符号化することで、高効率な情報圧縮が可能である。その反面、伝送路上のパケット損失等によりＩフレームのデータが破損した場合には、該当するＩフレームだけでなく、依存関係にあるＧＯＰ内の全てのフレームに映像破綻等の影響が生じる。一方、Ｉフレーム以外のフレーム（Ｐフレーム、Ｂフレーム）のパケット損失等による映像破綻の影響は、そのフレームとそのフレームを参照する一部のフレームに留まる。

例えば、デジタル放送におけるＨＥＶＣ映像符号化では、４階層のフレーム間参照構造が用いられる（非特許文献３を参照）。尚、ＨＥＶＣ規格ではスライス単位で符号化モードを決定するため、厳密にはＩ，Ｐ，Ｂフレームは定義されないが、便宜上、ＭＰＥＧ－２ Ｖｉｄｅｏ等の従来の符号化方式に倣い、フレーム内符号化のみを行うＩスライスからなるフレームをＩフレーム、表示順で前方のフレームを参照するＰスライスを含むフレームをＰフレーム、表示順で前方及び後方のフレームを参照するＢスライスを含むフレームをＢフレームと呼ぶこととする。ＰフレームはＩスライスを含む場合があり、ＢフレームはＩスライス及びＰスライスも含む場合がある。

図１８は、ＨＥＶＣ映像符号化における４階層のフレーム間参照構造の例を示す図である。横軸は表示時間を示し、縦軸は階層を示し、四角はＩフレーム等のフレームを示し、四角内の数字は符号化順を示す。また、矢印は、復号の際のフレームの参照関係を示す。具体的には、矢印の先のフレームは、矢印の元のフレームを参照して復号されることを示している。例えば符号化順１１のフレームは、符号化順１及び１０のフレームを参照して復号される。

図１８におけるＧＯＰは、符号化順１から３２までの３２枚のフレームにより構成され、各階層は、Temporal IDで識別される。符号化順でＧＯＰの先頭（符号化順１）のＩフレームは、Temporal ID=0に属する。Ｉフレーム以外のTemporal ID=0に属するフレームは、表示順で前方直近の復号済みのTemporal ID=0のフレームを参照するＰフレームである。

Temporal ID=1のフレームは、横軸の表示順において前後直近に位置する復号済みのTemporal ID=0のフレームを参照するＢフレームである。Temporal ID=2のフレームは、表示順において前後直近に位置する復号済みのTemporal ID=0または1のフレームを参照するＢフレームである。Temporal ID=3のフレームは、表示順において前後直近に位置する復号済みのTemporal ID=0,1または2のフレームを参照するＢフレームである。

つまり、Temporal ID=0のＩまたはＰフレームのデータが破損した場合には、そのフレームが属するＧＯＰ内の復号順で後方に位置する全てのフレーム、及び次のＧＯＰに属するフレームのうちそのＧＯＰのＩフレームよりも表示順が早いフレームまで映像破綻等の影響が生じる。

一方、Temporal ID=1のＢフレームのデータが破損した場合には、そのフレームと前後３フレームの計７フレームに映像破綻等の影響が生じる。また、Temporal ID=2のＢフレームのデータが破損した場合には、そのフレームと前後１フレームの計３フレームに映像破綻等の影響が生じる。また、Temporal ID=3のＢフレームのデータが破損した場合には、そのフレームのみに映像破綻等の影響が生じる。

一般に、ＩＰ回線を用いたＩＰ放送またはＩＰ再送信では、伝送路上でＩＰパケットの損失が生じると、映像破綻が生じる等、サービス品質に影響を与える可能性がある。このため、サービス品質の確保を目的として、伝送路上で損失したＩＰパケットを受信装置が復元することを可能とするＦＥＣ（Forward Error Correction：前方誤り訂正）が一般的に使用される。

ＦＥＣには様々なアルゴリズムがあり、一例として、ProMPEG FECがある（非特許文献４を参照）。ProMPEG FECでは、一定数のＩＰパケットの横１次元または縦横２次元のＦＥＣブロックを構成し、横１行または縦１列に並ぶパケットの排他的論理和（ＸＯＲ）演算によって、１つのリペアパケットを生成する。例えば、１０×１０の２次元ＦＥＣブロックを用いた場合、最大１００個のソースパケットに対して合計２０個のリペアパケットが生成される。

ＴＳを用いる従来のデジタル放送では、映像符号化によるＥＳ（Elementary Stream：エレメンタリストリーム）の出力ビットレートの時間変動を、ヌルＴＳパケットの挿入によって一定のビットレートに平滑化する。ＩＰ放送またはＩＰ再送信のＩＰパケットには、固定数のＴＳパケットが格納されるため、結果としてＩＰパケットの送出間隔が一定となり、ＦＥＣブロックの時間周期も一定となる。

一方、新４Ｋ８Ｋ放送等のＭＭＴ／ＩＰを用いる新しい放送では、ヌルＭＭＴＰパケットが規定されていないため、映像符号化によるＥＳの出力ビットレートの時間変動がそのままＩＰパケットの送出間隔に影響する。

このため、新４Ｋ８Ｋ放送等ではＩＰパケットの送出間隔が一定でないことから、ＩＰ再送信等のためにＦＥＣ付加を行ったとき、ＦＥＣブロックの時間周期が一定ではなくなる。つまり、映像符号化によるＥＳの出力ビットレートが低下したとき、ＦＥＣブロックが完成するまでの時間が長くなり、ＩＰパケットが後段に送出されない状態が生じ得る。

このとき、受信装置では、ＦＥＣ復号部の後段に設けられた映像復号部にてバッファアンダーフローが発生し、映像破綻や表示のカクつきを生じる可能性がある。受信装置の受信バッファを大きくすることにより、映像復号部におけるバッファアンダーフローの発生を防ぐことが可能である。しかし、映像の表示遅延時間及びメモリコストの増大につながる。

ISO/IEC 23008-1、"High efficiency coding and media delivery in heterogeneous environments：MPEG media transport" ARIB STD-B60、"デジタル放送におけるMMTによるメディアトランスポート方式" ARIB STD-B32、"デジタル放送における映像符号化、音声符号化及び多重化方式" "Pro-MPEG Forum Code of Practice 3 Release 2"、Transmissions of Professional MPEG-2 Transport Streams Over IP Networks（2004）

符号化された映像を伝送するＩＰパケットフローにおいて、ＩＰパケットのペイロードに格納された映像データのフレームの種別（フレーム種別）によっては、１個のＩＰパケットの損失により最悪でＧＯＰ長の映像破綻が生じる可能性がある。

パケット損失による映像破綻を防ぐためには、元の信号であるソースパケットに対し、誤り耐性を加えるリペアパケットを追加して送信する誤り訂正手法が用いられる。しかしながら、従来の誤り訂正手法では、フレーム種別等を考慮することなく、全てのＩＰパケットを等しい誤り訂正強度で保護している。つまり、常に等しい比率でリペアパケットが追加される。この場合の伝送路全体の伝送帯域に対するリペアパケットの伝送に用いられる伝送帯域は、フレーム種別に関わることなく一定である。一方で、図１８に示したとおり、ＩＰパケットのフレーム種別または階層によっては、ＩＰパケットの損失に伴う影響が異なるものとなる。このため、従来の誤り訂正手法では、フレーム種別等に応じた伝送帯域を、効果的に活用していないという問題があった。

リペアパケットの伝送に用いる伝送帯域を効果的に活用するためには、ＩＰパケットは、フレーム種別等に応じた誤り訂正強度で保護されることが望ましい。例えば、重要度の高いフレームのＩＰパケットについては、リペアパケットの伝送に用いられる伝送帯域を広くし、重要度の低いフレームのＩＰパケットについては、リペアパケットの伝送に用いられる伝送帯域を狭くする。これにより、映像破綻を効果的に防ぎつつ、空いた伝送帯域を別の用途に用いることができ、伝送路全体の伝送帯域を効率よく活用することができる。

また、符号化された映像を伝送するＩＰパケットフローにおいて、ＥＳの瞬時的なビットレート低下によりＩＰパケットの送出間隔が長くなると、送信装置のＦＥＣ符号化部及び受信装置のＦＥＣ復号部において、ＦＥＣブロックが完成してからＩＰパケットが後段に出力されるまでの間の待ち時間が長くなる。この場合、特に受信装置の映像復号部では、バッファアンダーフローが発生し易くなり、映像破綻や表示のカクつきが生じる可能性がある。

そこで、本発明は前記課題を解決するためになされたものであり、その目的は、符号化された映像を伝送するＩＰパケットフローにおいて、伝送帯域の有効活用を可能とし、かつ映像破綻が生じ難い受信装置及びプログラムを提供することにある。

前記課題を解決するために、請求項１の受信装置は、映像データが格納されたＩＰパケットをソースパケットとし、当該ソースパケットに対するＦＥＣ符号化により生成されたＩＰパケットをリペアパケットとして、前記ソースパケット及び前記リペアパケットを受信し、前記ソースパケット及び前記リペアパケットを用いてＦＥＣ復号を行う受信装置において、前記ソースパケットには、前記ソースパケット毎にインクリメントされたカウンタ値を示すパケットカウンタ値が含まれており、前記リペアパケットには、ＦＥＣブロックを構成する前記ソースパケットの行列の次元を示す次元フラグ、フレーム種別毎に設定された前記ＦＥＣブロックの行列サイズ、前記ＦＥＣブロックの先頭に位置する前記ソースパケットの前記パケットカウンタ値を示す開始パケットカウンタ値、及び、前記ＦＥＣブロックに含まれる前記ソースパケットの数を示す有効パケット数が含まれており、受信した前記ソースパケット及び前記リペアパケットを入力し、前記フレーム種別毎に、前記行列サイズまたは前記行列サイズ未満の前記ソースパケット、及び前記リペアパケットを含む前記ＦＥＣブロックを構成し、前記ソースパケットが損失した場合、前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットに基づいて前記ＦＥＣ復号を行い、損失した前記ソースパケットを復元するＦＥＣ復号部を備え、前記ＦＥＣ復号部が、前記ソースパケットから前記パケットカウンタ値を抽出すると共に、前記リペアパケットから、前記次元フラグ、前記行列サイズ、前記開始パケットカウンタ値及び前記有効パケット数を抽出し、入力した前記ソースパケット及び前記リペアパケットを入力パケットとして、前記次元フラグが１次元を示している場合、前記入力パケットが前記ＦＥＣブロックの最終パケットであると判定し、または、前記次元フラグが２次元を示している場合、前記開始パケットカウンタ値及び前記行列サイズに基づいて、前記入力パケットが前記ＦＥＣブロックの最終パケットであるか否かを判定し、前記入力パケットが前記ＦＥＣブロックの最終パケットであると判定した場合、前記入力パケットを含む前記ＦＥＣブロックを構成し、当該ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを出力し、前記入力パケットが前記ＦＥＣブロックの最終パケットでないと判定した場合、前記パケットカウンタ値、及び前記開始パケットカウンタ値に前記有効パケット数を加算した結果の値に基づいて、前記入力パケットが、次の前記ＦＥＣブロックに属するパケットであるか否かを判定し、前記入力パケットが、次の前記ＦＥＣブロックに属する前記パケットでないと判定した場合、前記入力パケットを、構成中の前記ＦＥＣブロックに追加し、前記入力パケットが、次の前記ＦＥＣブロックに属する前記パケットであると判定した場合、構成中の前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを出力するＦＥＣブロック処理部と、前記ＦＥＣブロック処理部により出力された前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを入力し、前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを用いて、前記フレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強い前記ＦＥＣ復号を行い、前記フレーム種別が前記Ｂフレームの場合、前記Ｉフレームよりも前記誤り訂正強度の弱い前記ＦＥＣ復号を行い、前記フレーム種別がＰフレームの場合、前記Ｉフレーム及び前記Ｂフレームのいずれかと等しいか、または前記Ｉフレームと前記Ｂフレームの間の前記誤り訂正強度の前記ＦＥＣ復号を行うＦＥＣ復号処理部と、を備えたことを特徴とする。

また、請求項２のプログラムは、コンピュータを、請求項１に記載の受信装置として機能させることを特徴とする。

以上のように、本発明によれば、符号化された映像を伝送するＩＰパケットフローにおいて、伝送帯域を有効活用することができる。また、映像破綻が生じ難くなり、サービス品質を確保することが可能となる。

実施例１の映像配信システムの構成例を示す概略図である。 実施例２の映像配信システムの構成例を示す概略図である。 実施例１の送信装置の構成例を示すブロック図である。 実施例１の受信装置の構成例を示すブロック図である。 実施例２の送信装置の構成例を示すブロック図である。 実施例２の受信端末の構成例を示すブロック図である。 ＦＥＣ符号化部の構成例を示すブロック図である。 ＦＥＣ符号化部の処理例を示すフローチャートである。 図８に示したステップＳ８０７，Ｓ８０８の処理におけるＦＥＣブロックの構成例を説明する図である。 ＦＥＣ符号化処理部の処理例（ステップＳ８０５，Ｓ８０７，Ｓ８０８）を示すフローチャートである。 ＩＰパケット（リペア）の生成処理を説明する図である。 ＩＰパケット（リペア）に含まれるＦＥＣヘッダの各データを説明する図である。 図１０に示したステップＳ１００４～Ｓ１００９の処理を説明する図である。 ＦＥＣ復号部の構成例を示すブロック図である。 ＦＥＣ復号部の処理例を示すフローチャートである。 ＩＰパケット（リペア）に含まれるＦＥＣヘッダの構造例を示す図である。 ＦＥＣヘッダの具体例を示す図である。 ＨＥＶＣ映像符号化における４階層のフレーム間参照構造の例を説明する図である。

以下、本発明を実施するための形態について図面を用いて詳細に説明する。本発明は、映像データのフレーム種別に応じて、適応的に誤り訂正強度の異なるＦＥＣを用いることを特徴とする。

これにより、符号化された映像を伝送するＩＰパケットフローにおいて、フレーム種別に応じた伝送帯域（損失による影響が大きいフレームほど誤り訂正用に広い伝送帯域、損失による影響が小さいフレームほど誤り訂正用に狭い伝送帯域を使用）となり、伝送帯域を有効活用することができる。また、受信側では、伝送路上でＩＰパケットが損失したときに、損失による映像品質への影響が大きいＩＰパケットほど復元できる可能性が高くなり、映像破綻が生じ難くなるため、サービス品質を確保することができる。

また、本発明は、映像データのフレーム境界を判定し、そのときまでにＦＥＣブロックを構成したフレーム境界以前のＩＰパケットを強制的に出力することを特徴とする。

これにより、ＦＥＣブロックの構成に伴う遅延を、常に１フレーム以内に収めることができ、短遅延化を実現することができる。そして、受信側では、ＩＰパケットの受信待ちによるバッファアンダーフローの発生を抑えることができる。

〔映像配信システム〕
まず、本発明の実施形態による送信装置及び受信装置を含む映像配信システムについて説明する。図１は、実施例１の映像配信システムの構成例を示す概略図である。この映像配信システム１－１は、送信装置２－１及び受信装置３を備えて構成される。送信装置２－１及び受信装置３はＩＰ回線４を介して接続され、映像配信システム１－１には、符号化された映像を伝送するＩＰパケットフローが構成される。

送信装置２－１は、図示しない単体の符号化装置等から送信されたＭＭＴのパケット（ＭＭＴＰ／ＵＤＰ／ＩＰのレイヤ構造のパケット、ＭＭＴを含むＩＰパケット）を受信する。

送信装置２－１は、ＩＰパケットに含まれる映像データのフレーム種別を判定し、ＩＰパケットに対し、フレーム種別に応じて誤り訂正強度の異なるＦＥＣ符号化を行う。送信装置２－１は、元のＩＰパケット、及びＦＥＣ符号化にて生成したＩＰパケットを、ＩＰ回線４を介して受信装置３へ送信する。

受信装置３は、送信装置２－１から送信されたＩＰパケットを、ＩＰ回線４を介して受信する。そして、受信装置３は、ＩＰパケットが損失した場合、フレーム種別に応じて誤り訂正強度の異なるＦＥＣ符号化に対応するＦＥＣ復号を行い、損失したＩＰパケットを復元する。受信装置３は、ＭＭＴを含むＩＰパケットを送信する。

図２は、実施例２の映像配信システムの構成例を示す概略図である。この映像配信システム１－２は、送信装置２－２及び受信端末５を備えて構成される。送信装置２－２及び受信端末５はＩＰ回線４を介して接続され、映像配信システム１－２には、符号化された映像を伝送するＩＰパケットフローが構成される。

送信装置２－２は、映像信号を入力し、映像信号を符号化してＭＭＴを含むＩＰパケットを生成する。そして、送信装置２－２は、図１に示した送信装置２－１と同様に、ＩＰパケットに含まれる映像データのフレーム種別を判定し、ＩＰパケットに対し、フレーム種別に応じて誤り訂正強度の異なるＦＥＣ符号化を行う。送信装置２－２は、元のＩＰパケット、及びＦＥＣ符号化にて生成したＩＰパケットを、ＩＰ回線４を介して受信端末５へ送信する。

受信端末５は、スマートフォン、小型ノートパソコン、タブレット型端末等のモバイル端末であり、携帯型の受信装置、またはテレビ、ＳＴＢ（Set Top Box）、メディアプレイヤ、デジタルサイネージ等の固定型の受信装置である。

受信端末５は、送信装置２－２から送信されたＩＰパケットを、ＩＰ回線４を介して受信する。そして、受信端末５は、図１に示した受信装置３と同様に、ＩＰパケットが損失した場合、フレーム種別に応じて誤り訂正強度の異なるＦＥＣ符号化に対応するＦＥＣ復号を行い、損失したＩＰパケットを復元する。受信端末５は、ＩＰパケットからＭＭＴを分離して復号し、映像信号を外部へ出力するか、または内蔵のディスプレイに表示する。

尚、映像配信システムは、図１に示した送信装置２－１及び図２に示した受信端末５を備えて構成されるようにしてもよいし、図２に示した送信装置２－２及び図１に示した受信装置３を備えて構成されるようにしてもよい。

〔実施例１〕
まず、図１に示した実施例１の送信装置２－１及び受信装置３について説明する。実施例１は、送信装置２－１が、ＭＭＴを含むＩＰパケットを入力してＦＥＣ符号化を行い、元のＩＰパケット及びＦＥＣ符号化にて生成したＩＰパケットを送信し、受信装置３が、ＩＰパケットを受信してＦＥＣ復号を行い、ＭＭＴを含むＩＰパケットを送信する例である。

（送信装置２－１）
図３は、実施例１の送信装置２－１の構成例を示すブロック図である。この送信装置２－１は、ＩＰパケット受信部１０、フレーム境界・種別判定部１１、ＦＥＣ符号化部１２及びＩＰパケット送信部１３を備えている。

ＩＰパケット受信部１０は、図示しない単体の符号化装置等から送信されたＭＭＴを含むＩＰパケットを受信し、ＩＰパケットに対して所定の受信処理を行う。そして、ＩＰパケット受信部１０は、受信処理後のＩＰパケットをフレーム境界・種別判定部１１及びＦＥＣ符号化部１２に出力する。

ＩＰパケット受信部１０が出力するＩＰパケットは、ＦＥＣ符号化により生成されるＩＰパケットと区別して、「ＩＰパケット（ソース）」という。ソースは、ソースパケットであることを意味する。

フレーム境界・種別判定部１１は、ＩＰパケット受信部１０からＩＰパケット（ソース）を入力し、ＩＰパケット（ソース）のペイロード（有効ペイロード）からＭＭＴＰヘッダ等を抽出する。ＩＰパケット（ソース）のペイロード、ＭＭＴＰヘッダ等については、後述する図１１にて説明する。

フレーム境界・種別判定部１１は、ＩＰパケット（ソース）に格納された映像データについて、ＭＭＴＰヘッダ等のデータに基づき、フレーム境界（フレームの先頭）及びフレームの種別（Ｉ，Ｐ，Ｂの種別）を判定し、フレーム境界・種別情報を生成する。フレーム境界・種別判定部１１は、入力したＩＰパケット（ソース）に対応するフレーム境界・種別情報をＦＥＣ符号化部１２に出力する。

ここで、ＩＰパケット（ソース）には、Ｉ，Ｐ，Ｂフレームのうちのいずれかのフレームの映像データが格納されている。また、フレーム境界情報は、当該ＩＰパケット（ソース）に格納されている映像データがフレーム境界であるフレームの先頭部分のデータであるか否かを示す（当該ＩＰパケット（ソース）に、Ｉ，Ｐ，Ｂフレームのいずれかのフレームについての最初の映像データが含まれているか否かを示す）情報である。種別情報は、当該ＩＰパケット（ソース）に格納されている映像データの属するフレームの種別を示す情報である。

ＭＭＴ／ＩＰを用いる新しい放送では、システムレイヤで映像符号化を意識した多重化処理が行われるため、ＴＳを用いる場合と比較して、ＩＰパケットのペイロードに対する解析が容易である。このため、ＩＰパケットのペイロードに格納されたデータに基づいて、フレーム境界・種別情報を生成することができる。

例えば、フレーム境界・種別判定部１１は、ＩＰパケット（ソース）に含まれるＭＭＴＰヘッダからＲＡＰ（Random Access Point）フラグを抽出し、ＲＡＰフラグに基づいて、当該ＩＰパケット（ソース）に、ＧＯＰの先頭のＩフレームにおける先頭部分（先頭の映像データ）が格納されているか否かを判定する。そして、フレーム境界・種別判定部１１は、当該ＩＰパケット（ソース）に、ＧＯＰの先頭のＩフレームにおける先頭部分（先頭の映像データ）が格納されていると判定した場合、Ｉフレームの境界を示すフレーム境界情報を生成する。

また、ＭＭＴでは、映像符号化の処理単位を、ＭＭＴＰにおいてＤＵ（Data Unit）として取り扱う。映像符号化がＨＥＶＣである場合、フレーム境界・種別判定部１１は、ＭＭＴＰペイロード（ＭＭＴＰペイロードのうちヘッダ以外の部分、後述する図１１を参照）に格納されているＮＡＬユニットの先頭位置を検出する。ＮＡＬユニットには、フレームの映像データが格納されている。

フレーム境界・種別判定部１１は、ＮＡＬユニットヘッダからnal_unit_type領域を抽出し、nal_unit_type領域のデータに基づいて、ＮＡＬユニットの映像データにおけるフレームの種別を特定する。

この場合、フレーム境界・種別判定部１１は、ＮＡＬユニットヘッダのnal_unit_type領域のデータがＡＵＤ（Access Unit Delimiter）である場合、当該ＩＰパケットにはフレームの先頭部分のデータが格納されていると判断することができる。ＲＡＰフラグが０のパケットに対してこの判定を行うことで、ＰフレームまたはＢフレームの先頭データを含むＩＰパケットであることがわかる。

さらに、ＡＵＤにはpic_type（ピクチャタイプ）領域が格納されており、そのフレームに含まれるスライスの符号化モードを識別することができる。これにより、pic_type=0（Ｉスライスのみ）の場合はＩフレーム、pic_type=1（ＩまたはＰスライス）の場合はＰフレーム、pic_type=2（Ｉ、ＰまたはＢスライス）の場合はＢフレームであると判別することができる。つまり、フレーム境界・種別判定部１１は、Ｐ，Ｂフレームの境界及び種別を示すフレーム境界・種別情報を生成することができる。

このように、フレーム境界・種別判定部１１により、入力したＩＰパケット（ソース）に格納された映像データのフレームについて、当該ＩＰパケット（ソース）のペイロードに格納されたデータ（ＲＡＰフラグ、ＮＡＬユニットヘッダ、ＡＵＤ等）に基づき、フレーム境界及びフレーム種別が判定され、フレーム境界・種別情報が生成される。

尚、フレーム境界・種別判定部１１は、ＩＰパケット（ソース）のペイロードからＤＵを抽出し、ＤＵからＤＵヘッダを抽出し、ＤＵヘッダに含まれるsample_numberの変化によってフレーム境界を判定するようにしてもよい。

ここで、以下の非特許文献によれば、新４Ｋ８Ｋ衛星放送の運用では、sample_numberは０に固定されている。このため、この非特許文献の規定に準拠する場合、sample_numberの変化からフレーム境界を判定することができない。
ＡＲＩＢ ＴＲ－Ｂ３９、“高度広帯域衛星デジタル放送運用規定（第三分冊）”

ＦＥＣ符号化部１２は、ＩＰパケット受信部１０からＩＰパケット（ソース）を入力すると共に、フレーム境界・種別判定部１１から、当該ＩＰパケット（ソース）に対応するフレーム境界・種別情報を入力する。そして、ＦＥＣ符号化部１２は、フレーム境界・種別情報に基づき、フレーム種別毎に、ＩＰパケット（ソース）を含む所定の行列サイズのＦＥＣブロックを構成する。

ここで、ＦＥＣ符号化部１２は、フレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強いＦＥＣ符号化を行うために、所定の行列サイズのＦＥＣブロックを構成する。また、ＦＥＣ符号化部１２は、フレーム種別がＢフレームの場合、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ符号化を行うために、Ｉフレームの場合とは異なる所定の行列サイズのＦＥＣブロックを構成する。また、ＦＥＣ符号化部１２は、フレーム種別がＰフレームの場合、Ｉフレーム及びＢフレームのいずれかに等しいか、または両者の間の所定の行列サイズのＦＥＣブロックを構成する。

すなわち、Ｉフレームの誤り訂正強度をＩｐ、Ｂフレームの誤り訂正強度をＢｐ、及びＰフレームの誤り訂正強度をＰｐとすると、Ｉｐ，Ｂｐについては以下の式が成り立つ。
［数1］
Ｉｐ＞Ｂｐ ・・・（１）
また、Ｉｐ，Ｐｐ，Ｂｐについては以下の式が成り立つ。
［数２］
Ｉｐ＝Ｐｐ＞Ｂｐ または
Ｉｐ＞Ｐｐ＝Ｂｐ または
Ｉｐ＞Ｐｐ＞Ｂｐ ・・・（２）

ＦＥＣ符号化部１２は、ＩＰパケット（ソース）が所定の行列サイズに満たない場合、ダミーデータを生成してＦＥＣブロックに含める。

ＦＥＣ符号化部１２は、ＦＥＣブロックを単位としてＦＥＣ符号化を行い、後述するＦＥＣヘッダ等を生成し、ＦＥＣヘッダ等を含むリペアパケットを生成する。以下、リペアパケットを「ＩＰパケット（リペア）」という。

ＦＥＣ符号化部１２は、ＦＥＣブロックを構成するＩＰパケット（ソース）及びＩＰパケット（リぺア）をＩＰパケット送信部１３に出力する。この場合、ＦＥＣ符号化部１２は、ダミーデータをＩＰパケット送信部１３に出力しない。ＦＥＣ符号化部１２の詳細については後述する。

ＩＰパケット送信部１３は、ＦＥＣ符号化部１２からＩＰパケット（ソース）及びＩＰパケット（リペア）を入力し、これらに対して所定の送信処理を行う。そして、ＩＰパケット送信部１３は、送信処理後のＩＰパケット（ソース）及びＩＰパケット（リペア）をＩＰパケットとして、ＩＰ回線４を介して受信装置３へ送信する。

（受信装置３）
図４は、実施例１の受信装置３の構成例を示すブロック図である。この受信装置３は、ＩＰパケット受信部２０、ＦＥＣ復号部２１及びＩＰパケット送信部２２を備えている。

ＩＰパケット受信部２０は、送信装置２－１により送信されたＩＰパケットを、ＩＰ回線４を介して受信し、ＩＰパケットに対して所定の受信処理を行う。そして、ＩＰパケット受信部２０は、受信処理後のＩＰパケットであるＩＰパケット（ソース）及びＩＰパケット（リペア）をＦＥＣ復号部２１に出力する。

ＦＥＣ復号部２１は、ＩＰパケット受信部２０からＩＰパケット（ソース）及びＩＰパケット（リペア）を入力し、ＩＰパケット（リペア）からＦＥＣヘッダを抽出し、ＦＥＣヘッダのデータに基づいて、フレーム種別毎にＦＥＣブロックの行列サイズを特定する。そして、ＦＥＣ復号部２１は、フレーム種別毎にＦＥＣブロックを構成する。

ＦＥＣ復号部２１は、ＩＰパケット（ソース）が損失している場合、ＩＰパケット（リペア）を用いてＦＥＣ復号を行い、損失したＩＰパケット（ソース）を復元する。ＦＥＣ復号部２１は、ＩＰパケット（ソース）をＩＰパケット送信部２２に出力する。ＦＥＣ復号部２１の詳細については後述する。

ＩＰパケット送信部２２は、ＦＥＣ復号部２１からＩＰパケット（ソース）を入力し、ＩＰパケット（ソース）に対して所定の送信処理を行う。そして、ＩＰパケット送信部２２は、送信処理後のＩＰパケット（ソース）を、ＭＭＴを含むＩＰパケットとして出力する。

〔実施例２〕
次に、図２に示した実施例２の送信装置２－２及び受信端末５について説明する。実施例２は、送信装置２－２が、映像信号を入力して映像符号化を行い、ＭＭＴを含むＩＰパケットを生成してＦＥＣ符号化を行い、元のＩＰパケット及びＦＥＣ符号化にて生成したＩＰパケットを送信し、受信端末５が、ＩＰパケットを受信してＦＥＣ復号を行い、ＩＰパケットからＭＭＴを分離して映像復号を行い、映像信号を出力する例である。

（送信装置２－２）
図５は、実施例２の送信装置２－２の構成例を示すブロック図である。この送信装置２－２は、映像入力部１４、映像符号化部１５、ＭＭＴ多重化部１６、フレーム境界・種別判定部１１、ＦＥＣ符号化部１２及びＩＰパケット送信部１３を備えている。送信装置２－２は、これらの構成部に加え、図示しない音声入力部、音声符号部等を備えるようにしてもよい。

映像入力部１４は、映像信号を入力し、映像信号に対して所定の入力処理を行い、入力処理後の映像信号を映像符号化部１５に出力する。

映像符号化部１５は、映像入力部１４から映像信号を入力し、映像信号に対して映像符号化処理を行い、映像符号化処理後の映像信号をＭＭＴ多重化部１６に出力する。

ＭＭＴ多重化部１６は、映像符号化部１５から映像符号化処理後の映像信号を入力し、映像信号に対して多重化処理を行うことでＭＭＴを生成し、ＭＭＴを含むＩＰパケット（ソース）を生成する。そして、ＭＭＴ多重化部１６は、ＩＰパケット（ソース）をフレーム境界・種別判定部１１及びＦＥＣ符号化部１２に出力する。

フレーム境界・種別判定部１１は、ＭＭＴ多重化部１６からＩＰパケット（ソース）を入力し、図３に示したフレーム境界・種別判定部１１と同様の処理を行う。

ＦＥＣ符号化部１２は、ＭＭＴ多重化部１６からＩＰパケット（ソース）を入力し、図３に示したＦＥＣ符号化部１２と同様の処理を行う。また、ＩＰパケット送信部１３は、図３に示したＩＰパケット送信部１３と同様の処理を行う。

（受信端末５）
図６は、実施例２の受信端末５の構成例を示すブロック図である。この受信端末５は、ＩＰパケット受信部２０、ＦＥＣ復号部２１、ＭＭＴ分離部２３、映像復号部２４及び映像出力部２５を備えている。

ＩＰパケット受信部２０は、送信装置２－２により送信されたＩＰパケットを、ＩＰ回線４を介して受信し、図４に示したＩＰパケット受信部２０と同様の処理を行う。

ＦＥＣ復号部２１は、図４に示したＦＥＣ復号部２１と同様の処理を行い、ＩＰパケット（ソース）をＭＭＴ分離部２３に出力する。

ＭＭＴ分離部２３は、ＦＥＣ復号部２１からＩＰパケット（ソース）を入力し、ＩＰパケット（ソース）に含まれるＭＭＴに対して分離処理を行い、分離処理後の映像信号を映像復号部２４に出力する。

映像復号部２４は、ＭＭＴ分離部２３から映像信号を入力し、映像信号に対して映像復号処理を行い、映像復号後の映像信号を映像出力部２５に出力する。

映像出力部２５は、映像復号部２４から映像復号後の映像信号を入力し、映像信号に対して所定の映像出力処理を行い、映像出力処理後の映像信号を外部へ出力するか、または内蔵するディスプレイに表示する。

〔ＦＥＣ符号化部１２〕
次に、図３及び図５に示したＦＥＣ符号化部１２について詳細に説明する。図７は、ＦＥＣ符号化部１２の構成例を示すブロック図である。このＦＥＣ符号化部１２は、ＦＥＣブロック処理部３０、メモリ３１及びＦＥＣ符号化処理部３２を備えている。

図８は、ＦＥＣ符号化部１２の処理例を示すフローチャートである。以下、図７及び図８を参照して、ＦＥＣ符号化部１２の処理について説明する。

ＦＥＣ符号化部１２のＦＥＣブロック処理部３０は、ＩＰパケット受信部１０からＩＰパケット（ソース）を入力すると共に、フレーム境界・種別判定部１１から、当該ＩＰパケット（ソース）に対応するフレーム境界・種別情報を入力する（ステップＳ８０１）。

ＦＥＣブロック処理部３０は、フレーム境界情報がフレーム境界（フレームの先頭）を示しているか否かを判定する（ステップＳ８０２）。

ＦＥＣブロック処理部３０は、ステップＳ８０２において、フレーム境界情報がフレーム境界を示していると判定した場合（ステップＳ８０２：Ｙ）、ステップＳ８０７へ移行する。

これにより、フレーム境界情報に対応するＩＰパケット（ソース）は、新たなフレームの開始点であると判断され、現在のＦＥＣブロックの構成処理は締め切られる。ＦＥＣブロック処理部３０は、メモリ３１からＦＥＣブロックを構成するＩＰパケット（ソース）を読み出し、ＩＰパケット（ソース）をＦＥＣ符号化処理部３２に出力する。そして、後述するステップＳ８０７～Ｓ８１０の処理により、メモリ３１から読み出されたＩＰパケット（ソース）に対してＦＥＣ符号化処理が行われ、次にフレーム種別に応じたＦＥＣブロックの行列サイズにて、メモリ３１の初期化をした上で、新たなフレームの開始点であると判断されたＩＰパケット（ソース）をメモリ３１に格納する。ステップＳ８０７～Ｓ８１０の処理については後述する。

一方、ＦＥＣブロック処理部３０は、ステップＳ８０２において、フレーム境界情報がフレーム境界を示していないと判定した場合（ステップＳ８０２：Ｎ）、入力したＩＰパケット（ソース）をＦＥＣブロックに追加する（ステップＳ８０３）。具体的には、ＦＥＣブロック処理部３０は、ＩＰパケット（ソース）をメモリ３１に格納する。これにより、メモリ３１には、ＦＥＣブロックを構成するＩＰパケット（ソース）が格納される。

ＦＥＣブロック処理部３０は、フレーム種別情報に基づいて、当該ＩＰパケット（ソース）に含まれる映像データのフレーム種別を特定する。そして、ＦＥＣブロック処理部３０は、メモリ３１に格納されたＦＥＣブロックを構成するＩＰパケット（ソース）の行列サイズＳ１と、特定したフレーム種別についての予め設定されたＦＥＣブロックの行列サイズＳ２とを比較することで、ＦＥＣブロックが完成されたか否かを判定する（ステップＳ８０４）。

ここで、予め設定されたＦＥＣブロックの行列サイズＳ２は、フレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強いＦＥＣ符号化が行われるサイズとする。具体的には、ＦＥＣブロックを構成するＩＰパケット（ソース）の数に対するＩＰパケット（リペア）の割合いが、Ｂフレームよりも高くなるように、行列サイズＳ２が設定される。

また、フレーム種別がＢフレームの場合、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ符号化が行われるサイズとする。具体的には、その割合いが、Ｉフレームよりも低くなるように、行列サイズＳ２が設定される。また、フレーム種別がＰフレームの場合、Ｉフレームの行列サイズ及びＢフレームの行列サイズのいずれかと同じ行列サイズとするか、またはＩフレームの行列サイズとＢフレームの行列サイズとの間に位置する行列サイズとする。

ＦＥＣブロック処理部３０は、ステップＳ８０４において、ＦＥＣブロックが完成されていないと判定した場合（ステップＳ８０４：Ｎ）、すなわちＳ１＜Ｓ２を判定した場合、ステップＳ８０１へ移行し、新たなＩＰパケット（ソース）等を入力する。

一方、ＦＥＣブロック処理部３０は、ステップＳ８０４において、ＦＥＣブロックが完成されたと判定した場合（ステップＳ８０４：Ｙ）、すなわち行列サイズＳ１＝行列サイズＳ２を判定した場合、メモリ３１からＩＰパケット（ソース）を読み出す。メモリ３１から読み出された全てのＩＰパケット（ソース）の行列サイズは、予め設定された行列サイズＳ２である。そして、ＦＥＣブロック処理部３０は、予め設定された行列サイズＳ２のＦＥＣブロックを構成するＩＰパケット（ソース）をＦＥＣ符号化処理部３２に出力する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０から、予め設定された行列サイズＳ２のＦＥＣブロックを構成するＩＰパケット（ソース）を入力する。そして、ＦＥＣ符号化処理部３２は、ＩＰパケット（ソース）を用いてＦＥＣ符号化を行うことで、ＩＰパケット（リペア）を生成し、ＩＰパケット（ソース）及びＩＰパケット（リペア）をＩＰパケット送信部１３に出力する（ステップＳ８０５）。この場合、ＦＥＣ符号化処理部３２は、ＦＥＣヘッダ等を生成し、ＦＥＣヘッダ等を含むＩＰパケット（リペア）を生成する。ＩＰパケット（リペア）の詳細については後述する。

これにより、予め設定された行列サイズＳ２のＦＥＣブロックを構成する全てのＩＰパケット（ソース）、及びＩＰパケット（リペア）が出力される。

ＦＥＣブロック処理部３０は、現在のフレーム種別に応じたＦＥＣブロックの初期化を行い（ステップＳ８０６）、ステップＳ８１１へ移行する。具体的には、ＦＥＣブロック処理部３０は、メモリ３１をクリアし、ステップＳ８０４の処理に伴って特定したフレーム種別の行列サイズＳ２につき、領域を確保する。

一方、ＦＥＣブロック処理部３０は、ステップＳ８０２（Ｙ）から移行して、すなわち、フレーム境界情報がフレーム境界を示していると判定した場合、メモリ３１からＩＰパケット（ソース）を読み出す。メモリ３１から読み出されたＩＰパケット（ソース）の行列サイズは、予め設定された行列サイズＳ２またはこれ未満である。そして、ＦＥＣブロック処理部３０は、予め設定された行列サイズＳ２またはこれ未満のＦＥＣブロックを構成するＩＰパケット（ソース）をＦＥＣ符号化処理部３２に出力する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０から、予め設定された行列サイズＳ２またはこれ未満のＦＥＣブロックを構成するＩＰパケット（ソース）を入力する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックに空きがある場合、空きの数分のダミーデータを生成する（ステップＳ８０７）。ダミーデータは、有効ペイロード長０であり、先頭から最大長の位置まで全て値０のバイトが設定されたデータである。

具体的には、ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成する（構成中のＦＥＣブロックの）ＩＰパケット（ソース）の行列サイズＳ１が、特定したフレーム種別についての予め設定された行列サイズＳ２未満の場合（Ｓ１＜Ｓ２）、その差分（Ｓ２－Ｓ１）に相当する数のダミーデータを生成する。尚、直前に入力されたＩＰパケット（ソース）が、フレームの最終パケットであり、かつＦＥＣブロックの最終のＩＰパケット（ソース）であった場合には、ステップＳ８０７において構成中のＦＥＣブロックは空（Ｓ１＝０）である。このため、ステップＳ８０７でダミーデータを生成せずにステップＳ８０８をスキップして、ステップＳ８０９に遷移する。

ＦＥＣ符号化処理部３２は、ＩＰパケット（ソース）及びダミーデータを用いてＦＥＣ符号化を行うことで、ＩＰパケット（リペア）を生成し、ＩＰパケット（ソース）及びＩＰパケット（リペア）をＩＰパケット送信部１３に出力する（ステップＳ８０８）。この場合、ＦＥＣ符号化処理部３２は、ダミーデータを出力しない。また、ＦＥＣ符号化処理部３２は、ＩＰパケット（リペア）を生成する際に、ＦＥＣヘッダ等を生成し、ＩＰパケット（リペア）にＦＥＣヘッダ等を含める。

これにより、予め設定された行列サイズＳ２未満のＦＥＣブロックを構成する全てのＩＰパケット（ソース）、及びＩＰパケット（リペア）が出力される。尚、ダミーデータのみから生成されたＩＰパケット（リペア）は出力しなくてもよい。

図９は、図８に示したステップＳ８０７，Ｓ８０８の処理におけるＦＥＣブロックの構成例を説明する図である。図９（１）は、予め設定されたＦＥＣブロックの行列サイズＳ２が１行×５列＝５の場合における１次元のＦＥＣブロックの構成例を示す。図９（２）は、予め設定されたＦＥＣブロックの行列サイズＳ２が５行×５列＝２５の場合における２次元のＦＥＣブロックの構成例を示す。

また、ＳはＩＰパケット（ソース）を示し、０はダミーデータを示し、ＲはＩＰパケット（リペア）を示す。

図９（１）を参照して、ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成するＩＰパケット（ソース）の行列サイズＳ１（１行×４列＝４）が、予め設定された行列サイズＳ２（１行×５列＝５）未満であると判断する（Ｓ１＜Ｓ２）。そして、ＦＥＣ符号化処理部３２は、ＦＥＣブロックに空きがあると判定し、空きの数分（１個）のダミーデータを生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成する４個のＩＰパケット（ソース）及び１個のダミーデータを用いて、１個のＩＰパケット（リペア）を生成する。

図９（２）を参照して、ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成するＩＰパケット（ソース）の行列サイズＳ１（３行×５列＋１行×３列＝１８）が、予め設定された行列サイズＳ２（５行×５列＝２５）未満であると判断する（Ｓ１＜Ｓ２）。そして、ＦＥＣ符号化処理部３２は、ＦＥＣブロックに空きがあると判定し、空きの数分（７個）のダミーデータを生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成する１８個のＩＰパケット（ソース）及び７個のダミーデータを用いて、行方向（横方向）及び列方向（縦方向）にそれぞれ５個、合計１０個のＩＰパケット（リペア）を生成する。

図７及び図８に戻って、ＦＥＣ符号化処理部３２は、ステップＳ８０７において、ＦＥＣブロックに空きがない場合、ダミーデータの生成を行わず、ステップＳ８０８に移行してＦＥＣ符号化を行う。

これにより、予め設定された行列サイズＳ２のＦＥＣブロックを構成する全てのＩＰパケット（ソース）、及びＩＰパケット（リペア）が出力される。

ＦＥＣブロック処理部３０は、入力したＩＰパケット（ソース）に対応するフレーム種別情報に基づいて、当該ＩＰパケット（ソース）に含まれる映像データのフレーム種別を特定する。そして、ＦＥＣブロック処理部３０は、特定した新たなフレーム種別に応じたＦＥＣブロックの初期化を行う（ステップＳ８０９）。これにより、メモリ３１はクリアされ、特定した新たなフレーム種別の行列サイズＳ２の領域が確保される。

ＦＥＣブロック処理部３０は、入力したＩＰパケット（ソース）をＦＥＣブロックに追加し（ステップＳ８１０）、ステップＳ８１１へ移行する。具体的には、ＦＥＣブロック処理部３０は、ＩＰパケット（ソース）をメモリ３１に格納する。これにより、メモリ３１には、新たなＦＥＣブロックを構成する最初のＩＰパケット（ソース）が格納される。

ＦＥＣ符号化部１２は、ステップＳ８０６またはステップＳ８１０から移行して、当該処理が終了しない限り（ステップＳ８１１：Ｎ）、ステップＳ８０１へ移行し、新たなＩＰパケット（ソース）等を入力する。一方、ＦＥＣ符号化部１２は、ユーザによる終了操作等に従い、当該処理を終了させる（ステップＳ８１１：Ｙ）。

（ＦＥＣ符号化処理部３２）
図１０は、図７に示したＦＥＣ符号化処理部３２の処理例（ステップＳ８０５，Ｓ８０７，Ｓ８０８）を示すフローチャートである。

ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０から、ＦＥＣブロックを構成する１または複数のＩＰパケット（ソース）を入力する（ステップＳ１００１）。具体的には、ＦＥＣ符号化処理部３２は、図８に示したステップＳ８０５の処理の場合、フレーム種別に応じて予め設定された行列サイズＳ２のＩＰパケット（ソース）を入力する。一方、ＦＥＣ符号化処理部３２は、図８に示したステップＳ８０７，Ｓ８０８の処理の場合、行列サイズＳ２未満のサイズのＩＰパケット（ソース）を入力する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成する１または複数のＩＰパケット（ソース）のうち最大長（最大のデータ長）のＩＰパケット（ソース）を特定する（ステップＳ１００２）。そして、ＦＥＣ符号化処理部３２は、最大長から最大長未満のＩＰパケット（ソース）の長さを減算し、最大長未満のＩＰパケット（ソース）に対し、末尾に減算結果の長さ分の値０を付加する（ステップＳ１００３）。これにより、入力した全てのＩＰパケット（ソース）の長さを揃えることができ、その長さは同じになる。尚、末尾に追加した値０は、ＩＰパケット（リペア）の生成のために用いられるものであり、ＩＰパケット（ソース）として出力されるときには除外される。

ＦＥＣ符号化処理部３２は、入力したＦＥＣブロックを構成する１または複数のＩＰパケット（ソース）について空きがあるか否かを判定する（ステップＳ１００４）。具体的には、ＦＥＣ符号化処理部３２は、前述のとおり、ＦＥＣブロックを構成する１または複数のＩＰパケット（ソース）の行列サイズＳ１が、予め設定された行列サイズＳ２未満の場合（Ｓ１＜Ｓ２）、ＦＥＣブロックに空きがあると判定する。一方、ＦＥＣ符号化処理部３２は、行列サイズＳ１が行列サイズＳ２と同じ場合（Ｓ１＝Ｓ２）、ＦＥＣブロックに空きがないと判定する。

ＦＥＣ符号化処理部３２は、ステップＳ１００４において、ＦＥＣブロックに空きがあると判定した場合（ステップＳ１００４：Ｙ）、行列サイズＳ１と行列サイズＳ２の差分（Ｓ２－Ｓ１）を求め、差分に相当する数（空き分）のダミーデータを生成する（ステップＳ１００５）。ダミーデータは、ＦＥＣ符号化処理のＸＯＲ演算に影響しないデータであり、前述のとおり、有効ペイロード長０であり、先頭から最大長の位置まで全て値０のバイトが設定されたデータである。

一方、ＦＥＣ符号化処理部３２は、ステップＳ１００４において、ＦＥＣブロックに空きがないと判定した場合（ステップＳ１００４：Ｎ）、ステップＳ１００６へ移行する。

ＦＥＣ符号化処理部３２は、ステップＳ１００５またはステップＳ１００４（Ｎ）から移行して、ＩＰパケット（ソース）、またはＩＰパケット（ソース）及びダミーデータを用いて、ＦＥＣブロックの行毎及び列毎に、有効ペイロード部分のＸＯＲ演算を行うことでＦＥＣ符号化を行う（ステップＳ１００６）。

ＦＥＣ符号化処理部３２は、予め設定された行列サイズＳ２等を含むＦＥＣヘッダ、及びその他のデータを生成する（ステップＳ１００７）。具体的には、ＦＥＣ符号化処理部３２は、後述する図１２に示すＦＥＣヘッダを生成すると共に、ＭＭＴＰヘッダの一部のデータとして、FEC_type（ＦＥＣタイプ）及びpkt_seq_num（packet_sequence_number：パケットシーケンス番号）を生成する。また、ＦＥＣ符号化処理部３２は、バイト長ＸＯＲ値を算出する。

FEC_typeは、ＭＭＴＰパケットがＩＰパケット（ソース）であるか、またはＩＰパケット（リペア）であるかを識別する領域である。FEC_typeの値により、ＩＰパケット（ソース）とＩＰパケット（リペア）を区別することができる。

ＩＰパケット（リペア）に格納されるpkt_seq_numは、ＦＥＣブロックにおいてＩＰパケット（リペア）に順番に付与される番号である。このpkt_seq_numにより、ＦＥＣブロックにおけるＩＰパケット（リペア）の位置を特定することができる。

バイト長ＸＯＲ値は、それぞれのＩＰパケット（ソース）のうち、ＦＥＣによる保護の対象となる有効ペイロードのバイト長をＸＯＲ演算した結果の値である。このとき、ダミーデータについては、有効ペイロードのバイト長を０としてＸＯＲ演算を行う。

ＦＥＣ符号化処理部３２は、バイト長ＸＯＲ値及びＸＯＲ演算結果をＦＥＣペイロードのデータとして、ＦＥＣヘッダ、ＭＭＴＰヘッダ、ＦＥＣペイロード等を格納したＩＰパケット（リペア）を生成する（ステップＳ１００８）。

このように、ＦＥＣ符号化処理部３２により、フレーム種別毎に、ＦＥＣブロックを単位としたＦＥＣ符号化が行われ、ＩＰパケット（リペア）が生成される。

ＦＥＣ符号化処理部３２は、ＩＰパケット（ソース）及びＩＰパケット（リペア）をＩＰパケット送信部１３に出力する（ステップＳ１００９）。

ここで、ＦＥＣ符号化処理部３２は、ステップＳ１００５にてダミーデータを生成した場合、ＦＥＣブロックに対応するＩＰパケット（ソース）、ダミーデータ及びＩＰパケット（リペア）のうち、ＩＰパケット（ソース）及びＩＰパケット（リペア）のみを出力し、ダミーデータを出力しない。

これにより、ＦＥＣブロックの構成及び符号化処理に伴う遅延を小さくすることができ、受信側では、バッファアンダーフローの発生を抑えることができる。

また、ステップＳ１００６におけるＦＥＣ符号化処理において、前述のとおり、予め設定されたＦＥＣブロックの行列サイズＳ２は、フレーム種別がＩフレームの場合、ＦＥＣブロックを構成するＩＰパケット（ソース）の数に対するＩＰパケット（リペア）の割り合いが、Ｂフレームよりも高いサイズである。したがって、その割り合いがＢフレームよりも高くなることで、Ｂフレームよりも強いＦＥＣ符号化が行われ、所定数のＩＰパケット（リペア）が生成される。

また、ＦＥＣブロックの行列サイズＳ２は、フレーム種別がＢフレームの場合、その割り合いがＩフレームよりも低いサイズである。したがって、その割り合いがＩフレームよりも低くなることで、Ｉフレームよりも弱いＦＥＣ符号化が行われ、所定数のＩＰパケット（リペア）が生成される。

また、ＦＥＣブロックの行列サイズＳ２は、フレーム種別がＰフレームの場合、その割り合いがＩフレーム及びＢフレームのいずれかと等しいか、または両者の間に位置するサイズである。したがって、その割り合いがＩフレーム及びＢフレームのいずれかと等しい場合、その等しいＩフレームまたはＢフレームと同じＦＥＣ符号化が行われ、所定数のＩＰパケット（リペア）が生成される。また、その割り合いがＩフレームよりも低くＢフレームよりも高い場合、Ｉフレームよりも弱く、Ｂフレームより強いＦＥＣ符号化が行われ、所定数のＩＰパケット（リペア）が生成される。

（ＩＰパケット（リペア）の生成処理）
ＩＰパケット（リペア）の生成処理について詳細に説明する。図１１は、ＩＰパケット（リペア）の生成処理を説明する図である。ａ_1～ａ_nは、ＦＥＣブロックにおいて行方向または列方向に並ぶＩＰパケット（ソース）であり、ｂは、ａ_1～ａ_nのＩＰパケット（ソース）を用いて生成されたＩＰパケット（リペア）である。

ａ_1～ａ_nを参照して、ＩＰパケット（ソース）は、ＩＰヘッダ、ＵＤＰヘッダ、ＭＭＴＰヘッダ、ＭＭＴＰペイロードヘッダ、並びにＤＵヘッダ及びＮＡＬユニットの組から構成される。ａ_1，ａ_nのＩＰパケット（ソース）は、さらに、図１０に示したステップＳ１００３の処理により値０が付加されている。

ＩＰヘッダ及びＵＤＰヘッダは、ＩＰパケット（ソース）のヘッダであり、ＭＭＴＰヘッダ、ＭＭＴＰペイロードヘッダ、並びにＤＵヘッダ及びＮＡＬユニットの組は、ＩＰパケット（ソース）の有効ペイロードである。このうち、ＭＭＴＰペイロードヘッダ、並びにＤＵヘッダ及びＮＡＬユニットの組は、ＭＭＴＰペイロードである。前述のとおり、ＮＡＬユニットには、フレームの映像データが格納されている。

また、図１１には示していないが、ＩＰパケット（ソース）のＭＭＴＰヘッダには、packet_id（パケットＩＤ）、pkt_seq_num（packet_sequence_number：パケットシーケンス番号）及びpacket_counter（パケットカウンタ）が含まれる。尚、ＭＭＴＰヘッダのpacket_counterは、packet_counter_flag（パケットカウンタフラグ）が１の場合に存在し、０の場合には存在しない。

packet_idは、映像及び音声等を区別する識別子である。pkt_seq_numは、ＩＰパケット（ソース）毎に、packet_idが異なる映像及び音声等のそれぞれを区別してインクリメントされたカウント値であり、全ての映像のＩＰパケット（ソース）を対象に設定され、全ての音声のＩＰパケット（ソース）を対象に設定される。

packet_counterは、ＩＰパケット（ソース）毎に、映像及び音声等を区別することなくインクリメントされたカウント値（パケットカウンタ値）であり、全てのＩＰパケット（ソース）を対象にして設定される。

これらのpacket_id、pkt_seq_num及びpacket_counterは、図１の実施例１において、図１には示していない符号化装置等により設定され、図２の実施例２において、図５に示した送信装置２－２のＭＭＴ多重化部１６により設定される。

図１１のｂを参照して、ＩＰパケット（リペア）は、ＩＰヘッダ、ＵＤＰヘッダ、ＭＭＴＰヘッダ、ＦＥＣヘッダ及びＦＥＣペイロードから構成される。

ＦＥＣペイロードにおける先頭のバイト長ＸＯＲは、ａ_1～ａ_nのＩＰパケット（ソース）のＦＥＣによる保護の対象とする有効ペイロード（図１０のステップＳ１００３においてパケット末尾に追加した値０の部分を含まない）のバイト長をＸＯＲ演算した結果のデータである。また、ＦＥＣペイロードのバイト長ＸＯＲ以外のデータは、ａ_1～ａ_nのＩＰパケット（ソース）の有効ペイロード部分（パケット末尾に追加した値０の部分を含む）をＸＯＲ演算して得られたデータである。

また、図１１には示していないが、ＩＰパケット（リペア）のＭＭＴＰヘッダには、前述のとおり、FEC_type及びpkt_seq_numが含まれる。これらのFEC_type及びpkt_seq_numは、前述のとおり、送信装置２－１，２－２に備えたＦＥＣ符号化部１２のＦＥＣ符号化処理部３２により設定される。

（ＦＥＣヘッダ）
次に、ＩＰパケット（リペア）に含まれるＦＥＣヘッダについて詳細に説明する。図１２は、ＩＰパケット（リペア）に含まれるＦＥＣヘッダの各データを説明する図である。以下では、ＭＭＴＰヘッダのpacket_counter_flagが１、つまりpacket_counterが存在する場合とする。

ＦＥＣヘッダは、2d_flag（次元フラグ）、start_packet_counter（開始パケットカウンタ）、num_column_packets（列方向パケット数）、num_row_packets（行方向パケット数）及びnum_valid_packets（有効パケット数）から構成される。

2d_flagは、ＦＥＣブロックの次元を示すフラグであり、０の場合、１次元のＦＥＣブロックを示し、１の場合、２次元のＦＥＣブロックを示す。start_packet_counterは、ＦＥＣブロックにおいて、先頭に位置するＩＰパケット（ソース）のpacket_counterの値（開始パケットカウンタ値）である。

num_column_packetsは、ＦＥＣブロックにおける列方向のパケット数を示し、予め設定されたＦＥＣブロックの行列サイズＳ２における行サイズに相当する。num_row_packetsは、ＦＥＣブロックにおける行方向のパケット数を示し、予め設定されたＦＥＣブロックの行列サイズＳ２における列サイズに相当する。

num_valid_packetsは、ＦＥＣブロックにおける有効なＩＰパケット（ソース）の数（有効パケット数）を示し、メモリ３１から読み出されたＦＥＣブロックを構成するＩＰパケット（ソース）の行列サイズＳ１に相当する。例えば、ダミーデータが生成されないＦＥＣブロックでは、この値は、予め設定されたＦＥＣブロックの行列サイズＳ２に相当する。

ＦＥＣ符号化部１２のＦＥＣ符号化処理部３２は、ＩＰパケット（リペア）を生成する際に、図１０に示したステップＳ１００７の処理において、予め設定されたＦＥＣブロックの行列サイズＳ２に基づいて、ＦＥＣブロックの次元フラグ、列方向パケット数及び行方向パケット数を特定し、それぞれ2d_flag、num_column_packets及びnum_row_packetsを生成する。

また、ＦＥＣ符号化処理部３２は、ＦＥＣブロックの先頭に位置するＩＰパケット（ソース）のＭＭＴＰヘッダからpacket_counterを抽出し、抽出したpacket_counterの値を開始パケットカウンタとして、start_packet_counterを生成する。

また、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０から入力したＦＥＣブロックを構成するＩＰパケット（ソース）をカウントし、その数を有効パケット数として、num_valid_packetsを生成する。つまり、有効パケット数は、メモリ３１から読み出されたＦＥＣブロックを構成するＩＰパケット（ソース）の行列サイズＳ１に相当する。

このようにして、ＦＥＣ符号化処理部３２は、2d_flag、start_packet_counter、num_column_packets、num_row_packets及びnum_valid_packetsからなるＦＥＣヘッダを生成し、ＦＥＣヘッダを含むＩＰパケット（リペア）を生成する。

（ステップＳ１００４～Ｓ１００９の処理）
次に、図１０に示したステップＳ１００４～Ｓ１００９の処理について具体例を挙げて説明する。図１３は、図１０に示したステップＳ１００４～Ｓ１００９の処理を説明する図である。

図１３（１）は、予め設定されたＦＥＣブロックの行列サイズＳ２が１行×５列＝５の場合における１次元のＦＥＣブロックの構成例を示す。図１３（２）は、予め設定されたＦＥＣブロックの行列サイズＳ２が５行×５列＝２５の場合における２次元のＦＥＣブロックの構成例を示す。図１３（１）（２）は、それぞれ図９（１）（２）に対応する。

また、ＳはＩＰパケット（ソース）を示し、０はダミーデータを示し、ＲはＩＰパケット（リペア）を示す。

図１３（１）を参照して、予め設定されたＦＥＣブロックの行列サイズＳ２が１行×５列＝５であるため、ＦＥＣブロックは１次元であり、行方向パケット数は５である。このため、ＦＥＣ符号化処理部３２は、2d_flag＝０及びnum_row_packets＝５を生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成するＩＰパケット（ソース）をカウントして４を求め、その数を有効パケット数として、num_valid_packets＝４を生成する。この場合、ＦＥＣ符号化処理部３２は、１個のダミーデータを生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックの先頭に位置するＩＰパケット（ソース）のＭＭＴＰヘッダからpacket_counterを抽出し、packet_counterの値を開始パケットカウンタとして、start_packet_counterを生成する。

ＦＥＣ符号化処理部３２は、ＩＰパケット（リペア）について、パケットシーケンス番号を０として、pkt_seq_num＝０を生成する。

ＦＥＣ符号化処理部３２は、2d_flag＝０、num_row_packets＝５、num_valid_packets＝４及びstart_packet_counterを含むＦＥＣヘッダを生成する。そして、ＦＥＣ符号化処理部３２は、ＩＰパケット（リペア）であることを示すFEC_type及びpkt_seq_num＝０をＭＭＴＰヘッダに格納し、ＦＥＣヘッダ、FEC_type及びpkt_seq_num＝０を含むＩＰパケット（リペア）を生成する。

このように、１次元のＦＥＣブロックの場合、最大でnum_row_packets個のＩＰパケット（ソース）を用いて、１個のＩＰパケット（リペア）が生成される。本例では、４個のＩＰパケット（ソース）が用いられる。

図１３（２）を参照して、予め設定されたＦＥＣブロックの行列サイズＳ２が５行×５列＝２５であるため、ＦＥＣブロックは２次元、列方向のパケット数は５、行方向のパケット数は５である。このため、ＦＥＣ符号化処理部３２は、2d_flag＝１、num_column_packets＝５及びnum_row_packets＝５を生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成するＩＰパケット（ソース）をカウントして１８を求め、その数を有効パケット数として、num_valid_packets＝１８を生成する。この場合、ＦＥＣ符号化処理部３２は、７個のダミーデータを生成する。

ＦＥＣ符号化処理部３２は、ＦＥＣブロックの先頭に位置するＩＰパケット（ソース）のＭＭＴＰヘッダからpacket_counterを抽出し、packet_counterの値を開始パケットカウンタとして、start_packet_counterを生成する。

この例では、ＦＥＣ符号化処理により、１０個のＩＰパケット（リペア）が生成される。ＦＥＣ符号化処理部３２は、生成されるべき１０個のＩＰパケット（リペア）について、図１３（２）に示すように、パケットシーケンス番号０，１，・・，９を順番に付与し、pkt_seq_num＝０，１，・・・，９を設定する。

ここで、ＩＰパケット（リペア）のpkt_seq_num は、ＦＥＣブロックを跨いで連続性を持たせる必要がないため、ＦＥＣブロックの最上行のＩＰパケット（リペア）について、pkt_seq_numを０とする。pkt_seq_numにより、ＦＥＣブロックにおいて各ＩＰパケット（リペア）の位置を特定することができる。

ＦＥＣ符号化処理部３２は、2d_flag＝1、num_column_packets＝５、num_row_packets＝５、num_valid_packets＝１８及びstart_packet_counterを含むＦＥＣヘッダを生成する。そして、ＦＥＣ符号化処理部３２は、ＩＰパケット（リペア）であることを示すFEC_type及びpkt_seq_numをＭＭＴＰヘッダに格納し、ＦＥＣヘッダを含むＩＰパケット（リペア）を生成する。

このように、２次元のＦＥＣブロックの場合、行毎に、最大でnum_row_packets個のＩＰパケット（ソース）を用いて、１個のＩＰパケット（リペア）が生成される。本例の場合、５個のＩＰパケット（リペア）が生成される。また、列毎に、最大でnum_column_packets個のＩＰパケット（ソース）を用いて、１個のＩＰパケット（リペア）が生成される。本例では、５個のＩＰパケット（リペア）が生成される。したがって、このＦＥＣブロックにおいて、１０個のＩＰパケット（リペア）が生成される。

また、ＦＥＣブロックは、最大でnum_row_packets×num_column_packets個のＩＰパケット（ソース）により構成されるが、この数に満たない場合は、num_valid_packets＜num_row_packets×num_column_packetsとなる。本例では、（num_valid_packets＝１８）＜（num_row_packets＝５）×（num_column_packets＝５）＝２５となる。

尚、図１３（２）において、ＦＥＣ符号化処理部３２は、１８個のＩＰパケット（ソース）、及び１０個のpkt_seq_num＝０～９のＩＰパケット（リペア）をＩＰパケット送信部１３に出力する。この場合、ＦＥＣ符号化処理部３２は、pkt_seq_num＝４のＩＰパケット（リペア）を出力しなくてもよい。

これは、pkt_seq_num＝４のＩＰパケット（リペア）は、５個のダミーデータを用いて生成されるため、受信側では、pkt_seq_num＝４のＩＰパケット（リペア）を用いて復元されるＩＰパケット（ソース）が存在しないからである。

つまり、ＦＥＣ符号化処理部３２は、ＦＥＣブロックにおいて、１行または１列の全てにＩＰパケット（ソース）が存在しない場合（１行または１列の全てがダミーデータである場合）、その１行または１列について、ＸＯＲ演算によるＦＥＣ符号化を行わなくてもよいし、ＩＰパケット（リペア）を生成しなくてもよい。または、ＦＥＣ符号化処理部３２は、その１行または１列について、ＸＯＲ演算によるＦＥＣ符号化を行い、ＩＰパケット（リペア）を生成するが、ＩＰパケット（リペア）を出力しなくてもよい。

これにより、ＦＥＣ復号処理に不要なＩＰパケット（リペア）が送信されないから、伝送帯域を一層有効に活用することができる。

以上のように、本発明の実施例１，２の送信装置２－１，２－２によれば、フレーム境界・種別判定部１１は、ＩＰパケット（ソース）のＭＭＴＰヘッダ等のデータに基づいて、当該ＩＰパケット（ソース）に格納された映像データが、フレーム境界にあるか否かを判定すると共に、当該映像データのフレーム種別を判定し、フレーム境界・種別情報を生成する。

ＦＥＣ符号化部１２は、フレーム境界・種別情報に基づき、フレーム種別毎に、ＩＰパケット（ソース）を含む所定の行列サイズのＦＥＣブロックを構成する。そして、ＦＥＣ符号化部１２は、ＦＥＣブロックを単位としてＦＥＣ符号化を行い、ＦＥＣブロックの行列サイズ等が格納されたＦＥＣヘッダを生成し、ＦＥＣヘッダ等を含むＩＰパケット（リペア）を生成する。

ここで、ＦＥＣ符号化部１２は、Ｉフレームについて、Ｂフレームよりも誤り訂正強度の強いＦＥＣ符号化を行うために、所定の行列サイズのＦＥＣブロックを構成する。一方、ＦＥＣ符号化部１２は、Ｂフレームについて、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ符号化を行うために、Ｉフレームとは異なる所定の行列サイズのＦＥＣブロックを構成する。また、ＦＥＣ符号化部１２は、Ｐフレームについて、ＩフレームまたはＢフレームと同じ誤り訂正強度のＦＥＣ符号化を行うために、ＩフレームまたはＢフレームと同じ所定の行列サイズのＦＥＣブロックを構成する。または、ＦＥＣ符号化部１２は、Ｐフレームについて、ＩフレームとＢフレームの間に位置する誤り訂正強度のＦＥＣ符号化を行うために、ＩフレームとＢフレームの間に位置する所定の行列サイズのＦＥＣブロックを構成する。

ＦＥＣ符号化部１２は、ＩＰパケット（ソース）が所定の行列サイズに満たない場合、ダミーデータを生成してＦＥＣブロックに含める。ＦＥＣ符号化部１２は、ＩＰパケット（ソース）及びＩＰパケット（リぺア）を出力し、ダミーデータを出力しない。

これにより、送信装置２－１，２－２からＩＰパケット（ソース）及びＩＰパケット（リぺア）が送信される。これらのＩＰパケットの伝送帯域は、Ｉフレームが他のフレームよりも広くなる。そして、受信側では、フレーム種別毎に、ＩＰパケット（リペア）のＦＥＣヘッダのデータに基づき、ＦＥＣブロックを構成して復号することができる。

このように、映像データのフレーム種別に応じたＦＥＣブロックのサイズの変化に対応して、適応的に誤り訂正強度の異なるＦＥＣ符号化が行われる。従来のＦＥＣブロックは、フレーム種別に関係なく一定サイズであったが、本発明の実施例１，２では、フレーム種別に応じて、ＦＥＣブロックのサイズが動的に変化することとなる。つまり、パケット損失により映像破綻等の影響が大きいＩフレームについては、他のフレームよりも伝送路上において損失したＩＰパケットを受信側で復元できる可能性が高まり、映像破綻が生じ難くなるため、サービス品質を確保することができる。また、Ｂフレームについては、他のフレームよりも誤り訂正に用いる伝送帯域を狭くするようにしたため、空いた伝送帯域を他の用途に用いる等有効に活用することができる。

また、ＦＥＣ符号化部１２は、ＩＰパケット（ソース）のフレーム境界であるフレームの先頭を判定した場合、そのときまでにＦＥＣブロックを構成したフレーム境界以前のＩＰパケット（ソース）及びダミーデータを用いてＦＥＣ符号化を行い、ＩＰパケット（ソース）及びＩＰパケット（リペア）を出力するようにした。

これにより、ビットレートが変動するＩＰパケットフローにおいて、必ず１フレーム以下の時間周期でＦＥＣ処理が行われるため、ＦＥＣブロックの構成に伴う遅延を短くすることができ、受信側では、バッファアンダーフローの発生を抑えることができる。

〔ＦＥＣ復号部２１〕
次に、図４及び図６に示したＦＥＣ復号部２１について詳細に説明する。図１４は、ＦＥＣ復号部２１の構成例を示すブロック図である。このＦＥＣ復号部２１は、ＦＥＣブロック処理部４０、メモリ４１及びＦＥＣ復号処理部４２を備えている。

図１５は、ＦＥＣ復号部２１の処理例を示すフローチャートである。以下、図１４及び図１５を参照して、ＦＥＣ復号部２１の処理について説明する。

ＦＥＣ復号部２１のＦＥＣブロック処理部４０は、ＩＰパケット受信部２０からＩＰパケット（ＩＰパケット（ソース）及びＩＰパケット（リペア））を入力する（ステップＳ１５０１）。

ＦＥＣブロック処理部４０は、入力したＩＰパケット（ソース）及びＩＰパケット（リペア）について、ＭＭＴＰヘッダのFEC_typeの値を参照することで、ＩＰパケット（ソース）及びＩＰパケット（リペア）を区別する。

具体的には、ＦＥＣブロック処理部４０は、ＭＭＴＰヘッダのFEC_typeの値がＩＰパケット（リペア）を示す値ではないと判定した場合、入力したＩＰパケットはＩＰパケット（ソース）であると判定する。一方、ＦＥＣブロック処理部４０は、ＭＭＴＰヘッダのFEC_typeの値がＩＰパケット（リペア）を示す値であると判定した場合、入力したＩＰパケットはＩＰパケット（リペア）であると判定する。

ＦＥＣブロック処理部４０は、入力したＩＰパケットが、構成中のＦＥＣブロックについての最終パケット（最終のＩＰパケット（リペア））であるか否かを判定する（ステップＳ１５０２）。

最終のＩＰパケット（リペア）とは、１次元のＦＥＣブロックの場合、当該ＦＥＣブロックのＩＰパケット（リペア）であり、２次元のＦＥＣブロックの場合、複数のＩＰパケット（リペア）のうち最大のpkt_seq_numが格納されたＩＰパケット（リペア）である。

具体的には、ＦＥＣブロック処理部４０は、まず入力したＩＰパケットがＩＰパケット（ソース）である場合、入力したＩＰパケットは最終のＩＰパケット（リペア）でないと判定する。

その上で、ＦＥＣブロック処理部４０は、入力したＩＰパケットがＩＰパケット（リペア）である場合、当該ＩＰパケット（リペア）のＦＥＣヘッダから2d_flag、num_column_packets及びnum_row_packetsを抽出する。また、ＦＥＣブロック処理部４０は、当該ＩＰパケット（リペア）のＭＭＴＰヘッダからpkt_seq_numを抽出する。

ＦＥＣブロック処理部４０は、2d_flag＝０（１次元のＦＥＣブロック）である場合、当該ＩＰパケット（リペア）は最終のＩＰパケット（リペア）であると判定する。

また、ＦＥＣブロック処理部４０は、2d_flag＝１（２次元のＦＥＣブロック）である場合、num_column_packetsにnum_row_packetsを加算し、加算結果から１を減算し、pkt_seq_numが減算結果に等しいか否かを判定する。つまり、ＦＥＣブロック処理部４０は、条件式（pkt_seq_num＝num_column_packets＋num_row_packets－１）が成立するか否かを判定する。

ＦＥＣブロック処理部４０は、pkt_seq_numが減算結果に等しい（pkt_seq_num＝num_column_packets＋num_row_packets－１）と判定した場合、当該ＩＰパケット（リペア）は最終のＩＰパケット（リペア）であると判定する。一方、ＦＥＣブロック処理部４０は、pkt_seq_numが減算結果に等しくない、すなわちpkt_seq_numが減算結果未満である（pkt_seq_num＜num_column_packets＋num_row_packets－１）と判定した場合、当該ＩＰパケット（リペア）は最終のＩＰパケット（リペア）でないと判定する。

図１３（２）の例において、前記条件式の右辺は、num_column_packets＋num_row_packets－１＝５＋５－１＝９である。pkt_seq_num＝９のＩＰパケット（リペア）の場合、前記条件式が成立するため、当該ＩＰパケット（リペア）は最終のＩＰパケット（リペア）であると判定される。一方、pkt_seq_num＝０～８のＩＰパケット（リペア）の場合、前記条件式が成立しないため、当該ＩＰパケット（リペア）は最終のＩＰパケット（リペア）でないと判定される。

ＦＥＣブロック処理部４０は、ステップＳ１５０２において、入力したＩＰパケットが最終のＩＰパケット（リペア）でないと判定した場合（ステップＳ１５０２：Ｎ）、ＦＥＣブロックの構成の途中であると判断し、ステップＳ１５０３へ移行する。

ＦＥＣブロック処理部４０は、ステップＳ１５０２（Ｎ）から移行して、入力したＩＰパケットが、次のＦＥＣブロックに属するＩＰパケット（ＩＰパケット（ソース）またはＩＰパケット（リペア））であるか否かを判定する（ステップＳ１５０３）。すなわち、ＦＥＣブロック処理部４０は、現在構成中のＦＥＣブロックの末尾にパケット損失が生じたか否かを判断する。

具体的には、ＦＥＣブロック処理部４０は、まず入力したＩＰパケットが、ＩＰパケット（ソース）であるか、またはＩＰパケット（リペア）であるかを判定する。

ＦＥＣブロック処理部４０は、ステップＳ１５０３で入力したＩＰパケットがＩＰパケット（ソース）である場合、当該ＩＰパケット（ソース）のＭＭＴＰヘッダからpacket_counterを抽出する。また、ＦＥＣブロック処理部４０は、現在構成中のＦＥＣブロックに属するＩＰパケット（リペア）のＦＥＣヘッダから抽出されたstart_packet_counter及びnum_valid_packetsを参照する。

ＦＥＣブロック処理部４０は、start_packet_counterにnum_valid_packetsを加算し、packet_counterが加算結果よりも大きいか否かを判定する。ＦＥＣブロック処理部４０は、packet_counterが加算結果よりも大きいと判定した場合（packet_counter＞start_packet_counter＋num_valid_packets）、入力したＩＰパケット（ソース）が、次のＦＥＣブロックに属するＩＰパケット（ソース）であると判定する。この場合、ＦＥＣブロック処理部４０は、現在構成途中のＦＥＣブロックの末尾にパケット損失が生じＦＥＣブロックの末尾が埋まらずに終了したことを判断し、ステップＳ１５０９に遷移する。

一方、ＦＥＣブロック処理部４０は、packet_counterが加算結果よりも大きくないと判定した場合（packet_counter≦start_packet_counter＋num_valid_packets）、入力したＩＰパケット（ソース）が、次のＦＥＣブロックに属するＩＰパケット（ソース）でないと判定する。この場合、ＦＥＣブロック処理部４０は、当該ＩＰパケット（ソース）は現在構成の途中であるＦＥＣブロックのＩＰパケット（ソース）であることを判断し、ステップＳ１５０４に遷移する。

また、ＦＥＣブロック処理部４０は、ステップＳ１５０３で入力したＩＰパケットがＩＰパケット（リペア）である場合、現在構成途中のＦＥＣブロックに属するＩＰパケット（リペア）のＦＥＣヘッダから抽出されたstart_packet_counterを参照する。これが、入力したＩＰパケット（リペア）のstart_packet_counterと異なれば、入力したＩＰパケットは次のＦＥＣブロックに属するＩＰパケット（リペア）と判定する。この場合、ＦＥＣブロック処理部４０は、現在構成途中のＦＥＣブロックの末尾にパケット損失が生じＦＥＣブロックの末尾が埋まらずに終了したことを判断し、ステップＳ１５０９に遷移する。

このように、ステップＳ１５０２，Ｓ１５０３によるＦＥＣ復号の前段処理では、ＦＥＣヘッダの情報を用いることができるため、ＦＥＣ符号化の前段処理と異なり、ＩＰパケット（ソース）のペイロードに格納された映像データに基づき、フレーム境界及びフレーム種別を判定する必要がない。このため、ＦＥＣ復号処理では、ＦＥＣ符号化処理に比べ、処理負荷を低減することができる。

ＦＥＣブロック処理部４０は、ステップＳ１５０３において、入力したＩＰパケットが、次のＦＥＣブロックに属するＩＰパケットでないと判定した場合（ステップＳ１５０３：Ｎ）、ステップＳ１５０４へ移行する。つまり、入力したＩＰパケットが現在構成中のＦＥＣブロックのＩＰパケットである場合、ステップＳ１５０４へ移行することとなる。

ＦＥＣブロック処理部４０は、ステップＳ１５０３（Ｎ）から移行して、入力したＩＰパケット（ＩＰパケット（ソース）またはＩＰパケット（リペア））をＦＥＣブロックに追加し（ステップＳ１５０４）、ステップＳ１５１３へ移行する。具体的には、ＦＥＣブロック処理部４０は、ＩＰパケット（ソース）またはＩＰパケット（リペア）をメモリ４１に格納する。これにより、メモリ４１にはＩＰパケット（ソース）またはＩＰパケット（リペア）が格納される。

ＦＥＣブロック処理部４０は、ステップＳ１５０２において、入力したＩＰパケットが最終のＩＰパケット（リペア）であると判定した場合（ステップＳ１５０２：Ｙ）、ステップＳ１５０５へ移行する。後述するステップＳ１５０５～Ｓ１５０８により、構成済みのＦＥＣブロックに対する復号処理が行われ、ＦＥＣブロックを構成するＩＰパケット（ソース）が出力される。構成済みのＦＥＣブロックは、フレーム種別毎に、所定の行列サイズまたは所定の行列サイズ未満のＩＰパケット（ソース）、及びＩＰパケット（リペア）で構成される。

ＦＥＣブロック処理部４０は、ステップＳ１５０２（Ｙ）から移行して、入力したＩＰパケット（リペア）をＦＥＣブロックに追加する（ステップＳ１５０５）。具体的には、ＦＥＣブロック処理部４０は、入力したＦＥＣブロックの最終のＩＰパケット（リペア）をメモリ４１に格納する。

ＦＥＣブロック処理部４０は、メモリ４１からＦＥＣブロックを構成する全てのＩＰパケット（ソース）及び全てのＩＰパケット（リペア）を読み出し、これらをＦＥＣ復号処理部４２に出力する。

ＦＥＣ復号処理部４２は、ＦＥＣブロック処理部４０から、ＦＥＣブロックを構成する全てのＩＰパケット（ソース）及び全てのＩＰパケット（リペア）を入力し、ＩＰパケット（ソース）の損失の有無を判定する。ＩＰパケット（ソース）の損失の有無は、ＩＰパケット（ソース）のＭＭＴＰヘッダに格納されたpkt_seq_num、及びＩＰパケット（リペア）のＦＥＣヘッダに格納されたnum_column_packets及びnum_row_packetsに基づいて判定される。

ＦＥＣ復号処理部４２は、ＩＰパケット（ソース）の損失がある場合、損失したＩＰパケット（ソース）に対応する行及び／または列における損失していないＩＰパケット（ソース）及びＩＰパケット（リペア）を用いて、ＦＥＣ復号を行い、損失したＩＰパケット（ソース）を復元する（ステップＳ１５０６）。このように、ＦＥＣブロックを単位として復号が行われる。

ここで、ＦＥＣ復号処理部４２は、構成するＦＥＣブロックのフレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強いＦＥＣ復号を行う。つまり、フレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強いＦＥＣ復号が行われるように、ＦＥＣブロック処理部４０は、ＦＥＣブロックの初期化を行い、所定の行列サイズのＦＥＣブロックを構成する。

また、ＦＥＣ復号処理部４２は、構成するＦＥＣブロックのフレーム種別がＢフレームの場合、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ復号を行う。つまり、フレーム種別がＢフレームの場合、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ復号が行われるように、ＦＥＣブロック処理部４０は、ＦＥＣブロックの初期化を行い、所定の行列サイズのＦＥＣブロックを構成する。

また、ＦＥＣ復号処理部４２は、構成するＦＥＣブロックのフレーム種別がＰフレームの場合、Ｉフレーム及びＢフレームのいずれかと等しい誤り訂正強度のＦＥＣ復号を行うか、またはＩフレームとＢフレームの間の誤り訂正強度のＦＥＣ復号を行う。つまり、フレーム種別がＰフレームの場合、Ｉフレーム及びＢフレームのいずれかと等しい誤り訂正強度のＦＥＣ復号が行われるように、またはＩフレームとＢフレームの間の誤り訂正強度のＦＥＣ復号が行われるように、ＦＥＣブロック処理部４０は、ＦＥＣブロックの初期化を行い、所定の行列サイズのＦＥＣブロックを構成する。

ＦＥＣ復号処理部４２は、ＦＥＣブロックを構成する全てのＩＰパケット（ソース）を、ＩＰパケット送信部２２（図４に示した実施例１の場合）またはＭＭＴ分離部２３（図６に示した実施例２の場合）に出力する（ステップＳ１５０７）。

ＦＥＣブロック処理部４０は、次に構成するＦＥＣブロックの初期化を行い（ステップＳ１５０８）、ステップＳ１５１３へ移行する。具体的には、ＦＥＣブロック処理部４０は、メモリ４１をクリアする。尚、次のＦＥＣブロックのＩＰパケット（リペア）を受信するまで、次のＦＥＣブロックの行列サイズは確定しない。後述するステップＳ１５１１についても同様である。

ＦＥＣブロック処理部４０は、ステップＳ１５０３において、入力したＩＰパケットが、次のＦＥＣブロックに属するＩＰパケットであると判定した場合（ステップＳ１５０３：Ｙ）、ステップＳ１５０９へ移行する。後述するステップＳ１５０９～Ｓ１５１２により、現在構成中のＦＥＣブロックの末尾のパケット損失が生じＦＥＣブロックの末尾が埋まらずに終了した場合の処理が行われる。

ＦＥＣブロック処理部４０は、ステップＳ１５０３（Ｙ）から移行して、メモリ４１から、現在構成中のＦＥＣブロックにおける全てのＩＰパケット（ソース）及び全てのＩＰパケット（リペア）を読み出し、これらをＦＥＣ復号処理部４２に出力する。

ＦＥＣ復号処理部４２は、ＦＥＣブロック処理部４０から、現在構成中のＦＥＣブロックにおける全てのＩＰパケット（ソース）及び全てのＩＰパケット（リペア）を入力する。そして、ＦＥＣ復号処理部４２は、ステップＳ１５０６の処理と同様に、ＩＰパケット（ソース）の損失がある場合、損失したＩＰパケット（ソース）に対応する行及び／または列における損失していないＩＰパケット（ソース）及びＩＰパケット（リペア）を用いて、ＦＥＣ復号を行い、損失したＩＰパケット（ソース）を復元する（ステップＳ１５０９）。このように、ＦＥＣブロックを単位として復号が行われる。

ＦＥＣ復号処理部４２は、現在構成中のＦＥＣブロックにおける全てのＩＰパケット（ソース）を、ＩＰパケット送信部２２（図４に示した実施例１の場合）またはＭＭＴ分離部２３（図６に示した実施例２の場合）に出力する（ステップＳ１５１０）。

ＦＥＣブロック処理部４０は、ステップＳ１５０８の処理と同様に、次に構成するＦＥＣブロックの初期化を行う（ステップＳ１５１１）。

ＦＥＣブロック処理部４０は、入力したＦＥＣブロックのＩＰパケット（ＩＰパケット（ソース）またはＩＰパケット（リペア））をＦＥＣブロックに追加し（ステップＳ１５１２）、ステップＳ１５１３へ移行する。具体的には、ＦＥＣブロック処理部４０は、入力したＩＰパケットをメモリ４１に格納する。入力したＩＰパケットがＩＰパケット（リペア）であれば、この時点で行列サイズが確定し、所定の位置に格納される。一方、入力したＩＰパケットがＩＰパケット（ソース）であれば、この時点で行列サイズは確定しないため、仮の位置に一時格納される。これにより、メモリ４１には、ＦＥＣブロックを構成するＩＰパケットが格納される。

尚、図１５には示してないが、現在構成中のＦＥＣブロックにおける最初のＩＰパケット（リペア）を受信し、ＦＥＣブロックの行列サイズが確定したタイミングで、それまでメモリ４１上で仮の位置に格納していたＩＰパケット（ソース）を、行列サイズに応じて所定の位置に移動してもよい。

ＦＥＣ復号部２１は、ステップＳ１５０４、ステップＳ１５０８またはステップＳ１５１２から移行して、当該処理が終了しない限り（ステップＳ１５１３：Ｎ）、ステップＳ１５０１へ移行し、新たなＩＰパケット（ソース）及びＩＰパケット（リペア）を入力する。一方、ＦＥＣ復号部２１は、ユーザによる終了操作等に従い、当該処理を終了させる（ステップＳ１５１３：Ｙ）。

尚、ステップＳ１５０２では、現在構成中のＦＥＣブロックの最終のＩＰパケット（リペア）が正常に受信されＦＥＣブロックが終了した場合を判定しているが、ステップＳ１５０２及びステップＳ１５０５～Ｓ１５０８を省略し、ステップＳ１５０１からステップＳ１５０３に直接遷移する構成としてもよい。このような構成であっても、ＦＥＣブロックの終了を判定することができる。ただし、この場合には、最終のＩＰパケット（リペア）に損失がない場合にも、ＦＥＣブロックの終了判断が次のＩＰパケットを受信するまで遅延することとなる。

以上のように、本発明の実施例１，２の受信装置３及び受信端末５によれば、ＦＥＣ復号部２１は、ＩＰパケット（リペア）のＦＥＣヘッダに格納されたデータに基づいて、フレーム種別毎のＦＥＣブロックの行列サイズを特定し、フレーム種別毎にＦＥＣブロックを構成する。

ＦＥＣ復号部２１は、ＩＰパケット（ソース）が損失している場合、ＩＰパケット（リペア）等を用いてＦＥＣ復号を行い、損失したＩＰパケット（ソース）を復元する。

このように、映像データのフレーム種別に応じたＦＥＣブロックのサイズの変化に対応して、適応的に誤り訂正強度の異なるＦＥＣ復号が行われる。従来のＦＥＣブロックは、フレーム種別に関係なく一定サイズであったが、本発明の実施例１，２では、フレーム種別に応じて、ＦＥＣブロックのサイズが動的に変化することとなる。つまり、パケット損失により映像破綻等の影響が大きいＩフレームについては、他のフレームよりも伝送路上において損失したＩＰパケットを受信側で復元できる可能性が高まり、映像破綻が生じ難くなるため、サービス品質を確保することができる。また、Ｂフレームについては、他のフレームよりも誤り訂正に用いる伝送帯域を広く狭くするようにしたため、空いた伝送帯域を他の用途に用いる等有効に活用することができる。また、フレーム種別毎に変化するＦＥＣブロックのサイズに応じて、適用的にＦＥＣ復号を行うことができる。

また、受信装置３及び受信端末５は、ビットレートが変動するＩＰパケットフローにおいて、必ず１フレーム以下の時間周期でＦＥＣ処理が行われるため、ＦＥＣブロックの構成に伴う遅延を短くすることができ、バッファアンダーフローの発生を抑えることができる。

〔符号化された映像及び音声を伝送するＩＰパケットフロー〕
以上、符号化された映像を伝送するＩＰパケットフローについて説明したが、本発明は、符号化された映像に加え、音声を伝送するＩＰパケットフローにも適用がある。

ＩＰパケット（ソース）のＭＭＴＰヘッダに格納されたpacket_counterを用いることにより、符号化された映像及び音声を伝送するＩＰパケットフローにおいて、実施例１，２を適用することができる。前述のとおり、packet_counterは、ＩＰパケット（ソース）毎に、映像及び音声を区別することなくインクリメントされたカウント値である。

packet_counterを用いることにより、映像信号を含むＩＰパケット（ソース）及び音声信号を含むＩＰパケット（ソース）の集合におけるパケットの連続性を検知することができる。このため、音声信号を含むＩＰパケット（ソース）の有無に関わらず、映像のフレーム境界を基準として、前述の処理を行うことができる。この場合、映像データを含むＩＰパケット（ソース）が多数に対し、音声データを含むＩＰパケット（ソース）は少数である。例えば、音声のＩＰパケット（ソース）は、その中身を問わず、直前の映像のＩＰパケット（ソース）と同じフレーム種別でありフレーム境界ではないパケットとして扱うことができる。

一方、音声データを含むＩＰパケット（ソース）をＦＥＣ符号化の対象としない場合、または、映像データを含むＩＰパケット（ソース）と音声データを含むＩＰパケット（ソース）とで独立した異なるＦＥＣ符号化及び復号処理を行う場合には、packet_counter ではなくpkt_seq_numを用いる。前述のとおり、pkt_seq_numは、ＩＰパケット（ソース）毎に、packet_idが異なる映像及び音声等のそれぞれを区別してインクリメントされたカウント値である。

pkt_seq_numを用いることにより、映像データを含むＩＰパケット（ソース）と音声データを含むＩＰパケット（ソース）とを区別して、それぞれのパケットの連続性を検知することができる。

尚、パケットの連続性検知のために、packet_counterを用いるか、またはpkt_seq_numを用いるかの識別データは、送信装置２－１，２－２のＦＥＣ符号化部１２のＦＥＣ符号化処理部３２により、ＩＰパケット（リペア）のＦＥＣヘッダに格納される。この場合、受信装置３及び受信端末５のＦＥＣ復号部２１は、ＩＰパケット（リペア）のＦＥＣヘッダに格納された識別データに基づいて、パケットの連続性検出のためのpacket_counterまたはpkt_seq_numを判断する。

pkt_seq_numはpacket_id毎に独立してインクリメントされる値が設定されるから、ＦＥＣによる保護の対象とする映像及び音声等を区別するため、その識別子であるpacket_idも識別データとして、ＦＥＣヘッダに格納される必要がある。

図１６は、ＩＰパケット（リペア）に含まれるＦＥＣヘッダの構造例を示す図であり、図１７は、ＦＥＣヘッダの具体例を示す図である。

図１６を参照して、ＦＥＣヘッダは、counter_select_flag（カウンタ選択フラグ、１ビット）、2d_flag（１ビット）、Ｌ１（１ビット）、Ｌ２（２ビット）、Ｌ３（１ビット）、reserved（予備、２ビット）、num_row_packets（（L1＋1）×8ビット）、start_packet_counter（（L2＋1）×8ビット）及びnum_valid_packets（（L3＋1）×8ビット）により構成される。さらに、ＦＥＣヘッダは、counter_select_flag＝１の場合、packet_idも含み、2d_flag＝１の場合、num_column_packetsも含んで構成される。Ｌ１，Ｌ２，Ｌ３はフラグである。

ＦＥＣヘッダは、図１７に示す（１）～（４）の構成となる。図１７（１）は、１次元ＦＥＣブロックの場合の第１例である。このＦＥＣヘッダは、counter_select_flag＝０、2d_flag＝０、Ｌ１、Ｌ２、Ｌ３、reserved、num_row_packets、start_packet_counter及びnum_valid_packetsにより構成される。

図１７（２）は、１次元ＦＥＣブロックの場合の第２例である。このＦＥＣヘッダは、図１７（１）のＦＥＣヘッダに加え、packet_idを含んで構成される。この場合、counter_select_flag＝１、2d_flag＝０である。

図１７（３）は、２次元ＦＥＣブロックの場合の第１例である。このＦＥＣヘッダは、counter_select_flag＝０、2d_flag＝１、Ｌ１、Ｌ２、Ｌ３、reserved、num_column_packets、num_row_packets、start_packet_counter及びnum_valid_packetsにより構成される。

図１７（４）は、２次元ＦＥＣブロックの場合の第２例である。このＦＥＣヘッダは、図１７（３）のＦＥＣブロックに加え、packet_idを含んで構成される。この場合、counter_select_flag＝１、2d_flag＝１である。

図３に示した送信装置２－１のＩＰパケット受信部１０が受信するＩＰパケットにおいて、ＭＭＴＰヘッダにpacket_counterが含まれていない場合、packet_counterを連続性検知に使用したいときは、ＦＥＣ符号化部１２は、その入力段にてpacket_counter_flag＝１を設定し、ＭＭＴＰヘッダにpacket_counter領域を追加するようにしてもよい。

ＦＥＣブロックのサイズによっては、num_column_packets及びnum_row_packets領域に必要なバイト数が変化する。このため、Ｌ１のフラグを用いることで、num_column_packets、num_row_packets領域に必要なバイト数を指定することができる。num_column_packets及びnum_row_packetsが共に２５５以下である場合、Ｌ１＝０で十分である。一方、num_column_packets及びnum_row_packetsのいずれかが２５６以上である場合、Ｌ１＝１とする必要がある。

同様に、num_valid_packets領域もＦＥＣブロックのサイズに応じて必要なバイト数が変化する。このため、何バイトで記述するかをＬ３のフラグで指定する。例えば、１００×１００のＦＥＣブロックの場合、Ｌ１＝０で十分であるが、Ｌ３＝１とする必要がある。

ＭＭＴＰヘッダのpacket_counter及びpkt_seq_num領域は４バイトであるが、ＦＥＣブロックのサイズに対し、４バイトで表現可能な整数は一般に過大である場合が多い。このため、ＦＥＣブロックを構成する先頭のＩＰパケット（ソース）のpacket_counterまたはpkt_seq_numの４バイト全てを、start_packet_counterとして記載することは冗長と言える。

そこで、Ｌ２のフラグを用いて、start_packet_counter領域のバイト数を１バイトから４バイトの範囲で指定する。start_packet_counterが４バイトよりも小さい場合、図４に示した受信装置３及び図６に示した受信端末５のＦＥＣ復号部２１によりＦＥＣブロックの境界の判定（図１５に示したステップＳ１５０２，Ｓ１５０３）の処理において、ＩＰパケット（ソース）のpacket_counter及びpkt_seq_numについてもstart_packet_counter領域と同じバイト数にクリップして、ＦＥＣブロックの最終のＩＰパケット（リペア）の判定を行う必要がある。

また、ＩＰパケット（リペア）において、ＦＥＣブロック内での位置情報を示すだけにpkt_seq_numの４バイトの領域は過大であるため、上位バイトをＦＥＣブロック毎にインクリメントする値とする等して、ＦＥＣブロックを跨いで一意の値としてもよい。この場合、図４に示した受信装置３及び図６に示した受信端末５のＦＥＣ復号部２１によりＦＥＣブロックの終了判定（図１５に示したステップＳ１５０２）の処理において、pkt_seq_numのうちＦＥＣブロック内での位置情報を示す下位バイトをクリップして判定を行う必要がある。

以上、実施例１，２を挙げて本発明を説明したが、本発明は前記実施例１，２に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。

例えば、前記実施例１，２では、送信装置２－１，２－２のＦＥＣ符号化部１２は、フレーム種別毎に、誤り訂正強度の異なるＦＥＣ符号化を行うようにした。これに対し、ＦＥＣ符号化部１２は、ＩフレームについてＦＥＣ符号化を行い、Ｐ，ＢフレームのそれぞれについてＦＥＣ符号化を行わないようにしてもよい。また、ＦＥＣ符号化部１２は、Ｉ，ＰフレームについてＦＥＣ符号化を行い、ＢフレームについてＦＥＣ符号化を行わないようにしてもよい。

また、前記実施例１，２では、送信装置２－１，２－２に備えたＦＥＣ符号化部１２のＦＥＣブロック処理部３０は、ＡＵＤのpic_type領域に基づいてフレーム種別を判定し、Ｉフレームについて、Ｂフレームよりも誤り訂正強度の強いＦＥＣ符号化が行われるように、所定の行列サイズのＦＥＣブロックを構成し、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０により構成されたＦＥＣブロックを単位として、ＦＥＣ符号化を行う。また、ＦＥＣブロック処理部３０は、Ｂフレームについて、Ｉフレームよりも誤り訂正強度の弱いＦＥＣ符号化が行われるように、所定の行列サイズのＦＥＣブロックを構成し、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０により構成されたＦＥＣブロックを単位として、ＦＥＣ符号化を行う。また、ＦＥＣブロック処理部３０は、Ｐフレームについて、Ｉフレーム及びＢフレームのいずれかと等しい誤り訂正強度のＦＥＣ符号化が行われるように、またはＩフレームとＢフレームの間の誤り訂正強度のＦＥＣ符号化が行われるように、所定の行列サイズのＦＥＣブロックを構成し、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０により構成されたＦＥＣブロックを単位として、ＦＥＣ符号化を行う。

これに対し、ＦＥＣ符号化部１２は、図１８に示したTemporal IDが示す階層のスライス毎に、誤り訂正強度の異なるＦＥＣ符号化を行うようにしてもよい。具体的には、ＦＥＣ符号化部１２のＦＥＣブロック処理部３０は、ＩＰパケット（ソース）に含まれるＮＡＬユニットの先頭に格納されたＮＡＬユニットヘッダからnuh_temporal_id_plus1領域を抽出し、nuh_temporal_id_plus1領域のデータに基づいて、当該ＩＰパケット（ソース）に格納された映像データについて、そのスライスのTemporal IDを特定する。尚、フレーム内をスライスによって領域分割しない場合には、一般にフレームとスライスは同等である。

ＦＥＣブロック処理部３０は、Temporal IDが所定値以下の階層に含まれるスライス（低い階層のスライス）について、当該Temporal IDが所定値よりも大きい階層に含まれるスライス（高い階層のスライス）よりも誤り訂正強度の強いＦＥＣ符号化が行われるように、所定の行列サイズのＦＥＣブロックを構成し、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０により構成されたＦＥＣブロックを単位として、ＦＥＣ符号化を行う。

一方、ＦＥＣブロック処理部３０は、Temporal IDが所定値よりも大きい階層に含まれるスライス（高い階層のスライス）について、当該Temporal IDが所定値以下の階層に含まれるスライス（低い階層のスライス）よりも誤り訂正強度の弱いＦＥＣ符号化が行われるように、所定の行列サイズのＦＥＣブロックを構成し、ＦＥＣ符号化処理部３２は、ＦＥＣブロック処理部３０により構成されたＦＥＣブロックを単位として、ＦＥＣ符号化を行う。この場合、ＦＥＣ符号化部１２は、Temporal ID＝３の階層に含まれるスライスについて、ＦＥＣ符号化を行わないようしてもよい。

また、前記実施例１，２では、送信装置２－１，２－２のＦＥＣ符号化部１２のＦＥＣ符号化処理部３２は、ＦＥＣブロックを構成するＩＰパケット（ソース）がＦＥＣブロックの所定の行列サイズに満たない場合に、ダミーデータ（値０）を生成するようにした。また、行方向または列方向にＸＯＲ演算を行う際に、対象のＩＰパケット（ソース）のパケット長を揃えるために最大のパケット長を決定し、それ未満のパケットの末尾に値０を追加した。これらは、ＸＯＲ演算を行う際に対象のパケット数や各パケットの有効バイト長を考慮せずに高速に演算を行うことを目的としている。

これに対し、ＦＥＣ符号化処理部３２は、行方向及び列方向のＦＥＣ符号化処理の実装が、対象のＩＰパケット（ソース）のみを１パケット毎等で逐次的にＸＯＲ演算を行うような実装手法である場合、ダミーデータを生成しなくてもよい。また、行方向及び列方向のＦＥＣ符号化処理の実装が、有効データの範囲内を１バイト毎等で逐次的にＸＯＲ演算を行うような実装手法である場合、パケット末尾に値０を追加してパケット長を揃えなくてもよい。なぜならば、値０とＸＯＲ演算を行っても結果が変わらないため、ダミーデータの生成やパケット末尾に値０を追加してＸＯＲ演算をせずとも、等価な演算となるからである。

また、ＦＥＣの符号化方式は、行方向及び列方向のＸＯＲ演算によるProMPEG FECが簡便であるが、ＬＤＧＭ ＦＥＣ（Low Density Generator Matrix Forward Error Correction）符号等より高度なＦＥＣ符号化を用いるようにしてもよい。

尚、実施例１による送信装置２－１及び受信装置３、並びに実施例２による送信装置２－２及び受信端末５のハードウェア構成としては、通常のコンピュータを使用することができる。送信装置２－１，２－２、受信装置３及び受信端末５は、ＣＰＵ、ＲＡＭ等の揮発性の記憶媒体、ＲＯＭ等の不揮発性の記憶媒体、及びインターフェース等を備えたコンピュータによって構成される。

送信装置２－１に備えたＩＰパケット受信部１０、フレーム境界・種別判定部１１、ＦＥＣ符号化部１２及びＩＰパケット送信部１３の各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。

また、受信装置３に備えたＩＰパケット受信部２０、ＦＥＣ復号部２１及びＩＰパケット送信部２２の各機能も、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。

また、送信装置２－２に備えた映像入力部１４、映像符号化部１５、ＭＭＴ多重化部１６、フレーム境界・種別判定部１１、ＦＥＣ符号化部１２及びＩＰパケット送信部１３の各機能も、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。

また、受信端末５に備えたＩＰパケット受信部２０、ＦＥＣ復号部２１、ＭＭＴ分離部２３、映像復号部２４及び映像出力部２５の各機能も、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。

これらのプログラムは、前記記憶媒体に格納されており、ＣＰＵに読み出されて実行される。また、これらのプログラムは、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記憶媒体に格納して頒布することもでき、ネットワークを介して送受信することもできる。

１－１，１－２ 映像配信システム
２－１，２－２ 送信装置
３ 受信装置
４ ＩＰ回線
５ 受信端末
１０，２０ ＩＰパケット受信部
１１ フレーム境界・種別判定部
１２ ＦＥＣ符号化部
１３，２２ ＩＰパケット送信部
１４ 映像入力部
１５ 映像符号化部
１６ ＭＭＴ多重化部
２１ ＦＥＣ復号部
２３ ＭＭＴ分離部
２４ 映像復号部
２５ 映像出力部
３０，４０ ＦＥＣブロック処理部
３１，４１ メモリ
３２ ＦＥＣ符号化処理部
４２ ＦＥＣ復号処理部
2d_flag 次元フラグ
start_packet_counter 開始パケットカウンタ
num_column_packets 列方向パケット数
num_row_packets 行方向パケット数
num_valid_packets 有効パケット数
packet_id パケットＩＤ
packet_counter パケットカウンタ
pkt_seq_num（packet_sequence_number） パケットシーケンス番号
FEC_type ＦＥＣタイプ
counter_select_flag カウンタ選択フラグ
reserved 予備

Claims (2)

1. 映像データが格納されたＩＰパケットをソースパケットとし、当該ソースパケットに対するＦＥＣ符号化により生成されたＩＰパケットをリペアパケットとして、前記ソースパケット及び前記リペアパケットを受信し、前記ソースパケット及び前記リペアパケットを用いてＦＥＣ復号を行う受信装置において、
   前記ソースパケットには、前記ソースパケット毎にインクリメントされたカウンタ値を示すパケットカウンタ値が含まれており、
   前記リペアパケットには、ＦＥＣブロックを構成する前記ソースパケットの行列の次元を示す次元フラグ、フレーム種別毎に設定された前記ＦＥＣブロックの行列サイズ、前記ＦＥＣブロックの先頭に位置する前記ソースパケットの前記パケットカウンタ値を示す開始パケットカウンタ値、及び、前記ＦＥＣブロックに含まれる前記ソースパケットの数を示す有効パケット数が含まれており、
   受信した前記ソースパケット及び前記リペアパケットを入力し、前記フレーム種別毎に、前記行列サイズまたは前記行列サイズ未満の前記ソースパケット、及び前記リペアパケットを含む前記ＦＥＣブロックを構成し、前記ソースパケットが損失した場合、前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットに基づいて前記ＦＥＣ復号を行い、損失した前記ソースパケットを復元するＦＥＣ復号部を備え、
   前記ＦＥＣ復号部は、
   前記ソースパケットから前記パケットカウンタ値を抽出すると共に、前記リペアパケットから、前記次元フラグ、前記行列サイズ、前記開始パケットカウンタ値及び前記有効パケット数を抽出し、
   入力した前記ソースパケット及び前記リペアパケットを入力パケットとして、前記次元フラグが１次元を示している場合、前記入力パケットが前記ＦＥＣブロックの最終パケットであると判定し、または、前記次元フラグが２次元を示している場合、前記開始パケットカウンタ値及び前記行列サイズに基づいて、前記入力パケットが前記ＦＥＣブロックの最終パケットであるか否かを判定し、
   前記入力パケットが前記ＦＥＣブロックの最終パケットであると判定した場合、前記入力パケットを含む前記ＦＥＣブロックを構成し、当該ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを出力し、
   前記入力パケットが前記ＦＥＣブロックの最終パケットでないと判定した場合、前記パケットカウンタ値、及び前記開始パケットカウンタ値に前記有効パケット数を加算した結果の値に基づいて、前記入力パケットが、次の前記ＦＥＣブロックに属するパケットであるか否かを判定し、
   前記入力パケットが、次の前記ＦＥＣブロックに属する前記パケットでないと判定した場合、前記入力パケットを、構成中の前記ＦＥＣブロックに追加し、
   前記入力パケットが、次の前記ＦＥＣブロックに属する前記パケットであると判定した場合、構成中の前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを出力するＦＥＣブロック処理部と、
   前記ＦＥＣブロック処理部により出力された前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを入力し、前記ＦＥＣブロックに含まれる前記ソースパケット及び前記リペアパケットを用いて、前記フレーム種別がＩフレームの場合、Ｂフレームよりも誤り訂正強度の強い前記ＦＥＣ復号を行い、前記フレーム種別が前記Ｂフレームの場合、前記Ｉフレームよりも前記誤り訂正強度の弱い前記ＦＥＣ復号を行い、前記フレーム種別がＰフレームの場合、前記Ｉフレーム及び前記Ｂフレームのいずれかと等しいか、または前記Ｉフレームと前記Ｂフレームの間の前記誤り訂正強度の前記ＦＥＣ復号を行うＦＥＣ復号処理部と、を備えたことを特徴とする受信装置。
2. コンピュータを、請求項１に記載の受信装置として機能させるためのプログラム。

Images