JP6529299B2 - 送信装置、受信装置、方法及びプログラム - Google Patents

Description

本発明は、ストリームデータを送・受信する送信装置、受信装置、送信方法、受信方法、及びプログラムに関する。

近年、動画データのネットワーク伝送が世界的に利用されている。映像の高画素化とユーザの利用形態の多様化に伴い、今後は例えばＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｅｃ）技術を用いて、一つの映像データをユーザの要求に応じた解像度と品質でリアルタイム伝送することも要求されている。なお、ＳＶＣは、動画像データをフレームレートに関して階層符号化する（時間階層符号化）技術に関し、Ｈ．２６４／ＡＶＣの拡張方式として提案されている。

また、インターネット及びＬＡＮネットワークを介してリアルタイムに動画データをストリーム伝送する有力な標準技術にＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）がある。ＲＴＰは、いわゆるＯＳＩ参照モデルのセッション層のプロトコルに当たり、トランスポート層にはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が組み合わせて用いられることが一般的である。ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルは、国際標準化機構（ＩＳＯ）によって策定されたモデルであり、通信プロトコルを七つの階層に分けて定義している。なお、ＵＤＰは、動画データのリアルタイムストリーミングに有効な技術ではあるが、伝送中にパケット損失が発生して受信側で動画データが破損した場合、得られる映像の品質は低下してしまう。

このため、特許文献１には、ＵＤＰの上位プロトコルであるＲＴＰを用いた通信において、損失パケットを回復する際にＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ：前方誤り訂正）を用いる技術が開示されている。ＦＥＣは、動画データのパケットに加え、伝送エラーとなってしまった動画データパケットを復元するためのデータパケットを同時に送信する技術である。なお、以下の説明では、動画データのパケットをメディアパケットと呼び、そのメディアパケットを復元するためのデータパケットをＦＥＣパケットと呼ぶこととする。ＦＥＣパケットは、一つ以上のメディアパケットをグループ化し、それらメディアパケットに対しＦＥＣ生成演算を行って生成される。主に用いられているＦＥＣ生成演算にはＸＯＲ演算やリードソロモン演算がある。ＦＥＣパケットを生成する際のメディアパケットのグループを指定する方法は、「汎用前方誤り訂正用ＲＴＰペイロードフォーマット」のＲＦＣ５１０９で定義される。

また、メディアパケットが許容量以上に損失してしまい、ＦＥＣによる復元が不可能となる場合の解決策として、ＦＥＣと再送制御を併用するいわゆるハイブリッドＡＲＱという方法がある。特許文献１には、ＦＥＣパケットの送信と再送制御を併用することが記載されている。なお、再送制御とは、パケットの損失が発生した場合に、受信側が送信元に対して、その損失したパケットの再送信を要求し、送信元がそのパケットを受信側へ再送信する技術である。ハイブリッドＡＲＱでは、受信側は損失したパケットをＦＥＣでも復元できないと判断すると、送信元にそのパケットの再送信を要求する。

特開２０１０−１４１４１３号公報

ところで、動画データのリアルタイム伝送では、メディアパケットが正確に伝送されることと、伝送量が過大にならないこと、そしてメディアパケットの伝送から映像データおよび音声データの復号までの処理が可能な限り短い時間で実行されることが要求される。このような要求を満たすために、従来、映像，音声の両ストリームとそれらに付随するメタデータストリームのそれぞれにおいて、適切な量のＦＥＣパケットが生成されて伝送される。

また、ＳＶＣの場合、映像データは、基本レイヤーと一つ以上の拡張レイヤーの各データストリームとして伝送される。例えばユーザが要求する映像の解像度に応じて、基本レイヤーと拡張レイヤーのデータが伝送される。この場合、複数のユーザに対して異なる解像度のデータを同時に伝送することを考慮して、基本レイヤーと各拡張レイヤーのストリームは、それぞれ別のストリームとして伝送される。このように、ＳＶＣでは、一つの動画のデータ伝送は、複数のデータストリームで構成されることになるが、各ストリームのデータ量は大きく異なる。例えば、映像解像度の拡張性（Ｓｐａｃｉａｌ Ｓｃａｌａｂｌｅ）を採用した場合のＳＶＣの動画データの場合、各レイヤーのデータ量は、基本レイヤーから上位の拡張レイヤーへ上がるにしたがって増大する。なお、映像データと音声データを比べると、音声のほうが一般的にデータ量は少ない。

しかしながら、ストリームによってデータ量に大きな違いがあったとしても、全体の伝送量を大きく増大させないために、メディアパケット数に対するＦＥＣパケット数は大きく変化させることはできない。したがって、データ量が大きいストリームに比べてデータ量が小さいストリームは、ＦＥＣ生成のためのメディアパケットのグループが時間軸方向に広げられることになる。このことは、ＦＥＣ生成を遅らせることにつながり、更にハイブリッドＡＲＱによるエラー復元失敗時の再送要求の実行の遅延を招き、結果としてリアルタイム性を損ねることにつながる。また、ＳＶＣの下位レイヤーでは、データ量が少ないために、複数のフレームを横断してＦＥＣ生成のグループ化が行われ易い。この場合、エラーが発生したフレームのパケットだけでなく、その次のフレームのパケットの到着を待たなければエラー回復は実行できないことになり、このこともリアルタイム性を損なう要因となる。さらに、ＳＶＣでは、下位レイヤーの復号化が完了しなければ、その上位レイヤーの復号化も完了できない。したがって、例えば下位レイヤーの復号化が失敗、或いは遅延することは、ＳＶＣの映像品質に影響を与えてしまう。このように、データが複数のレイヤーに分けられてレイヤーごとにストリームデータを伝送するＳＶＣのような方式の場合、エラー回復の遅延によってリアルタイム性が損なわれる虞がある。

そこで、本発明は、エラー回復の遅延を防止可能にすることを目的とする。

本発明の送信装置は、送信データを構成するデータパケットであって第１のデータストリームによって送信される第１のデータパケットと、前記送信データを構成するデータパケットであって前記第１のデータストリームと異なる第２のデータストリームによって送信される第２のデータパケットとを用いて、損失データパケットを復元するための復元用データパケットを生成する生成手段と、前記第１のデータパケット及び前記第２のデータパケットの送信に応じて、前記生成手段によって生成された一つの復元用データパケットを送信する送信手段とを有する。

本発明によれば、エラー回復の遅延を防止することができる。

送信装置と受信装置とネットワークからなる全体構成を示す図である。 ＦＥＣパケットの送信と再送信要求タイミングの説明に用いる図である。 実施形態の送信装置の機能ブロック構成を示す図である。 ＦＥＣ生成処理のフローチャートである。 第１の実施形態におけるＲＴＰヘッダ部の拡張領域の構成を示す図である。 第１、第２の実施形態のＦＥＣ生成情報テーブルの説明に用いる図である。 第１、第２の実施形態のＦＥＣ演算処理のフローチャートである。 実施形態の受信装置の機能ブロック構成を示す図である。 ＦＥＣ復元処理のフローチャートである。 第１、第２の実施形態のＦＥＣ復元処理のフローチャートである。 第２の実施形態におけるＦＥＣヘッダの拡張領域の構成を示す図である。 実施形態の送信装置のハードウェア構成を示す図である。

＜第１の実施形態＞
以下、一例としてＳＶＣ技術を用い、動画像データと音声データをそれぞれ転送レートの異なる複数のストリームデータとして送・受信する例について説明する。ＳＶＣ技術を用いる場合に限られず、本発明は、動画像データや音声データなどのデータを複数のデータストリームを用いて送信する場合に適用可能である。たとえば、ＳＶＣ技術に代えて、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）技術を用いることとしてもよい。本実施形態では、特に動画像のストリームデータを例に挙げて説明する。動画像のストリームデータは、複数のデータパケットに分割される。以下、本実施形態では、動画像のデータストリームのデータパケットを、メディアパケットと表記する。また、本実施形態では、メディアパケットに加え、伝送エラーとなってしまったメディアパケットを復元するための復元用データのパケットを同時に送信する。本実施形態では、前方誤り訂正（ＦＥＣ）技術を用いた誤り訂正によるパケット復元を行う例を挙げる。なお、以下の説明では、ＦＥＣによる損失パケットの復元用データパケットをＦＥＣパケットと表記する。

図１には、本実施形態の動画像送信装置１０１（以下、送信装置１０１とする。）と動画像受信装置１０３（以下、受信装置１０３とする。）を含むシステムの全体の構成例を示す。送信装置１０１は、ネットワーク１０２を介して受信装置１０３と接続している。送信装置１０１は、例えば動画ストリーミングサーバである。送信装置１０１は、映像データと音声データのストリームをＲＴＰ方式のメディアパケットとして送信する機能と、それらメディアパケットに対して後述するようにして生成される本実施形態のＦＥＣパケットをＲＴＰ方式で送信する機能とを有する。また、送信装置１０１は、受信装置１０３からの再送信要求（ＲＴＣＰ否定応答）に応じて、再送指定されたメディアパケットを再送信するパケット再送機能をも有する。受信装置１０３は、動画ストリームを受信する例えばクライアント端末である。受信装置１０３は、送信装置１０１から送信されたメディアパケットとＦＥＣパケットを受信する機能と、損失データパケットがある場合には、ＦＥＣパケットと損失していないデータパケットとを用いて損失データパケットを復元する機能とを有する。また、受信装置１０３は、ストリーミング再生の際に、損失等により不足してしまうメディアパケットの再送信を、送信元である送信装置１０１に要求する機能を有する。

ここで、図１の送信装置１０１と受信装置１０３の詳細な説明を行う前に、本実施形態の送信装置１０１が生成するＦＥＣパケットの理解を容易にするために、先ず、ＳＶＣにおけるレイヤーとＦＥＣパケットについて簡単に説明する。

ＳＶＣでは、前述したように、複数のユーザに対して異なる解像度のデータを同時に伝送することを考慮して、基本レイヤーと各拡張レイヤーのデータストリームは、それぞれ別のストリームとして伝送される。送信データは、第１の解像度を有する画像を受信装置が表示するために用いる基本レイヤーのデータと、第１の解像度よりも解像度が高い第２の解像度を有する画像を受信装置が表示するために基本レイヤーのデータとともに用いる拡張レイヤーのデータとを含む。送信装置は、基本レイヤーのデータを第１のデータストリームによって送信する。また、拡張レイヤーのデータを第２のデータストリームによって送信する。前述したように、ＳＶＣでは、フレームごとに、下位レイヤーのデータがなければ、その上位レイヤーの復号化も完了できない。すなわち、ＳＶＣでは、上位レイヤーのデータは、下位レイヤーに対する差分データとなされているため、下位レイヤーのデータが先に伝送され、その後、上位レイヤーのデータが伝送される。そして、先に下位レイヤーのデータが復号化され、上位レイヤーのデータは下位レイヤーの復号データを元に復号化される。言い換えると、下位レイヤーは、上位レイヤーよりも伝送優先順位が高くなされている。このように、ＳＶＣでは、各レイヤーのストリームデータは互いに関連したデータとなっている。

また、前述したように、各レイヤーのデータ量は、基本レイヤーから上位の拡張レイヤーへ上がるにしたがって増大する。ただし、前述したように、全体の伝送量の制限から、メディアパケット数に対するＦＥＣパケット数は大きく変化させることができない。したがって、データ量の少ない下位レイヤーは、図２（ａ）を用いて後述するように、ＦＥＣ生成のためのメディアパケットのグループが時間軸方向に広げられる。特にＳＶＣの下位レイヤーでは、データ量が少ないために、複数のフレームを横断して（複数のフレームに跨った）ＦＥＣ生成のグループ化が行われ易い。

また、前述したように、ＦＥＣパケットは、一つ以上のメディアパケットをグループ化し、それらメディアパケットに対してＦＥＣ生成演算を行って生成される。以下、本実施形態では、ＦＥＣ演算の対象となる複数のメディアパケットのグループを、ＦＥＣグループと表記する。ＲＦＣ５１０９では、メディアパケットのストリームを識別可能とする識別情報（識別子）であるＳＳＲＣ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ）によりストリームが指定される。さらに、メディアパケットを特定可能とするパケット識別情報であるＲＴＰシーケンス番号を指定することにより、ストリームの中からＦＥＣグループの対象とするとメディアパケットが特定される。なお、一つのＦＥＣパケットが指定できるメディアパケット、すなわち一つのＦＥＣグループとして指定できるメディアパケットは、同一のＳＳＲＣを持ち、最大で４８個の連続したＲＴＰシーケンス番号を持つものである。

図２（ａ）には、ＳＶＣの規格において、３つのレイヤーによりストリームデータを送信する際の、ＦＥＣパケットの受信タイミングと、ＦＥＣ復元処理の失敗に対する再送信判断が可能となるタイミングの一例を示す。図２（ａ）では、一つのパケットを四角形で表現し、その中で特にＦＥＣパケットには「Ｆ」の文字を入れている。また、ＳＶＣの規格では、前述したように、下位レイヤーのデータがなければ、その上位レイヤーの復号化も完了できない。このため、ＳＶＣでは、フレームごとに、基本レイヤーのストリーム送信の完了後に第１拡張レイヤーのストリームの送信が行われ、第１拡張レイヤーのストリーム送信の完了後に第２拡張レイヤーのストリームの送信が行われる。

図２（ａ）の例では、ストリームデータにはＩＤＲフレームとＰフレームが含まれる。なお、ＩＤＲフレームとＰフレームは、ＡＶＣ規格により決められているフレームである。ＩＤＲフレームのデータ、および、Ｐフレームのデータは、それぞれ、基本レイヤーのデータ、第１拡張レイヤーのデータ、および、第２拡張レイヤーのデータを含んでいる。図２（ａ）の例では、基本レイヤー、第１拡張レイヤー、第２拡張レイヤーのそれぞれのレイヤーにおいて、１０個のメディアパケット１１００を含む一つのＦＥＣグループに対して一つのＦＥＣパケット１１０１が生成されて送信される。図２（ａ）の例では、ＩＤＲフレームを構成する基本レイヤーのメディアパケット数は６個である。基本レイヤーのメディアパケットを用いて一つのＦＥＣパケットを生成するためには、ＩＤＲフレームを構成する基本レイヤーのメディアパケット６個と、Ｐフレームを構成する基本レイヤーのメディアパケット４個の計１０個のメディアパケットを用いる必要がある。また、図２（ａ）の例では、ＩＤＲフレームを構成する第２拡張レイヤーのメディアパケット数は１４個である。したがって、１４個のうち１０個のメディアパケットを用いて一つのＦＥＣパケットを生成することになる。続いて、残りの４個のメディアパケットと、Ｐフレームを構成する第２拡張レイヤーのメディアパケット６個を用いて一つのＦＥＣパケットを生成することになる。このように、図２（ａ）の例では、基本レイヤーと第２拡張レイヤーに関してはＦＥＣグループが、ＩＤＲフレームとＰフレームに分かれている。このため、図２（ａ）の例の場合、基本レイヤーと第２拡張レイヤーに関しては、例えばＦＥＣ復元が失敗して再送信要求の必要があるか否かを判断可能となるタイミングは、ＩＤＲフレームの次のＰフレーム中のＦＥＣパケットの到着後となる。

すなわち、図２（ａ）に示したＦＥＣ生成の場合は、データ量の異なる複数のストリームで構成されるデータの伝送に対し、リアルタイム性を担保しながら、適切なＦＥＣパケット数でエラー回復を制御することが難しくなる虞がある。

このため、本実施形態の送信装置１０１は、各レイヤーのストリームに含まれる複数のメディアパケットのなかから、各メディアパケットが送信される際の時系列順に、設定された個数のメディアパケットを集めて、ＦＥＣグループを形成する。そして、送信装置１０１は、それら設定個数のメディアパケットのＦＥＣグループから、ＦＥＣパケットを生成する。

図２（ｂ）には、本実施形態において、３つのレイヤーによりストリームデータを送信する際に送信元で生成されるＦＥＣパケットと、受信側においてＦＥＣ復元処理の失敗に対する再送信判断が可能となるタイミングとを示す。この図２（ｂ）では、図２（ａ）の例と同様に、一つのパケットを四角形で表現し、その中で特にＦＥＣパケットには「Ｆ」の文字を入れている。また、図２（ｂ）においても図２（ａ）と同様に、各レイヤーにおけるストリーム送信は、フレームごとに、各レイヤーの伝送優先順位に応じて行われる。すなわち、フレームごとに、基本レイヤーのストリーム、次に第１拡張レイヤーのストリーム、その後、第２拡張レイヤーのストリームの順に、ストリームデータの伝送が行われる。

ただし、図２（ｂ）の場合は、送信データの送信期間のうち一部の期間内に送信される所定数のデータパケットを含むＦＥＣグループが形成され、ＦＥＣグループに含まれるデータパケットに基づいて前記復元用データのＦＥＣパケットが生成される。ＦＥＣグループは、各レイヤーの各ストリームに含まれている複数のメディアパケットのなかで、送信される際の時系列順に、設定された個数のメディアパケットが集められて形成される。すなわち、本実施形態の場合、ＦＥＣグループは、各レイヤーを横断するように、送信の時系列順に設定個数のメディアパケットが集められてＦＥＣグループが形成される。なお、図２（ｂ）の例では、ＦＥＣグループを形成するメディアパケットの設定個数として、１０個を例に挙げている。

そして、図２（ｂ）の場合、各レイヤーに含まれる複数のメディアパケットのなかから送信の際の時系列順に集められた１０個のメディアパケットを用いて、ＦＥＣ演算によるＦＥＣパケットが生成される。すなわち、図２（ｂ）の場合、ＩＤＲフレームでは、基本レイヤーの６個のメディアパケット１１１０と第１拡張レイヤーの４個のメディアパケット１１１１からなる送信時系列順の１０個のメディアパケットが一つのＦＥＣグループとなされる。そして、それら基本レイヤーと第１拡張レイヤーを跨いでＦＥＣグループに含められた送信時系列順の１０個のメディアパケットから、ＦＥＣパケット１１０２ａが生成される。次に、第１拡張レイヤーの６個のメディアパケット１１１２と第２拡張レイヤーの４個のメディアパケット１１１３からなる送信時系列順の１０個のメディアパケットが一つのＦＥＣグループとなされる。そして、それら第１拡張レイヤーと第２拡張レイヤーを跨いでＦＥＣグループに含められた送信時系列順の１０個のメディアパケットから、ＦＥＣパケット１１０２ｂが生成される。さらに、図２（ｂ）の例の場合、次の１０個の送信時系列順のメディアパケットは、第２拡張レイヤーの１０個のメディアパケット１１１４となる。このため、これら１０個のメディアパケット１１１４が一つのＦＥＣグループとなされてＦＥＣパケット１１０２ｃが生成される。Ｐフレームでは、基本レイヤーの４個のメディアパケット１１１５と第１拡張レイヤーの５個のメディアパケット１１１６と第２拡張レイヤーの１個のメディアパケット１１１７からなる時系列順の１０個のメディアパケットが一つのＦＥＣグループとなされる。そして、それら基本レイヤーと第１拡張レイヤーと第２拡張レイヤーを跨いでＦＥＣグループに含められた送信時系列順の１０個のメディアパケットから、ＦＥＣパケット１１０２ｄが生成される。以下、次のメディアパケット１１１８以降においても前述同様になされる。すなわち、この図２（ｂ）の例の場合は、前述の図２（ａ）のようにＩＤＲフレームとＰフレームとを跨ぐような（横断するような）ＦＥＣグループは、生成されていないことになる。このようにして、第１のデータパケットと第２のデータパケットとを用いて、損失データパケットを復元するための復元用データのパケットを生成する。第１のデータパケットとは、送信データを構成するデータパケットであって第１のデータストリームによって送信されるデータパケットである。また第２のデータパケットとは、送信データを構成するデータパケットであって第１のデータストリームと異なる第２のデータストリームによって送信されるデータパケットである。

また、本実施形態において前述のようにして生成されたＦＥＣパケットは、一例として、ＦＥＣパケットの伝送のために別途用意したレイヤーにより送信することができる。また、ＦＥＣパケットは、例えば、基本レイヤーのメディアパケットのストリームに付加されて送信されてもよい。その他にも、ＦＥＣパケットは、例えば音声データ用のストリームに付加して送信されてもよい。そして、詳細は後述するが、本実施形態では、後述するような各メディアパケットとＦＥＣグループとストリームをそれぞれ識別可能な識別情報が、ＲＴＰのメディアパケットのヘッダの拡張領域内に記述される。これにより、本実施形態によれば、何れのストリームに含まれるメディアパケットによってＦＥＣグループが形成されているのかを特定可能となっている。

本実施形態の図２（ｂ）の例と、前述したＳＶＣの規定によるＦＥＣパケットの図２（ａ）の例とを比較すると、図２（ａ）の場合は、基本レイヤーと第２拡張レイヤーにおいて、一つのＦＥＣグループがＩＤＲフレームとＰフレームを跨いでしまっている。したがって、図２（ａ）の例の場合、前述したように、基本レイヤーと第２拡張レイヤーに関しては、受信側でＦＥＣ復元の失敗による再送信要求の判断が可能となるタイミングはＩＤＲフレームの次のＰフレーム中のＦＥＣパケットの到着後になってしまう。これに対して本実施形態の図２（ｂ）の場合、受信側では、各レイヤーのストリームを区別せずに、送信の際の時系列順の設定個数のメディアパケットからなるＦＥＣグループごとに、再送信要求の可否判断が行われる。すなわち、図２（ｂ）の例の場合、受信側におけるＦＥＣ復元失敗と再送信要求の可否判断は、本実施形態のＦＥＣグループの対象となっている送信時系列順の設定個数のメディアパケットの受信直後のタイミングで可能となる。図２（ｂ）の例の場合、ＦＥＣ復元失敗と再送信要求の可否判断のタイミングは、ＩＤＲフレーム内となっており、図２（ａ）のように次のＰフレームまで遅延してしまうことはない。このように、図２（ｂ）の例では、リアルタイム性が求められるストリーム伝送において例えばエラー回復が失敗してパケットの再送信要求が行われる場合に、受信側は、図２（ａ）の例よりも早く再送信要求を行える。また、図２（ｂ）の例では、データ量の異なる複数のストリームを伝送する場合に、ＦＥＣデータ量（ＦＥＣパケット数）の割合を略々一定に保ちながらも、エラー回復に必要なメディアパケットの時間的なばらつきが抑えられている。したがって、本実施形態では、エラー回復が容易で、且つ迅速なリアルタイムストリーム伝送が可能となる。以上のように、本実施形態によれば、レイヤーごとにデータ量の異なるストリームデータを伝送する場合において、リアルタイム性を担保しながら、適切なデータ量のＦＥＣによるエラー回復制御を実現することが可能となっている。すなわち、本実施形態では、ＦＥＣによるエラー回復の遅延防止と、伝送データ全体の量をより効率的に制御可能としている。

次に、図２（ｂ）に示したようなＦＥＣパケット生成を可能とする、本実施形態の送信装置１０１の詳細な構成を図３に示す。図３の各ブロックの機能の一部又は全体は、一例としてハードウェアにより実現することができる。なお、図３のパケットバッファ２０７（以下、バッファ２０７とする。）は、例えばＨＤＤや大容量半導体メモリとなされる。ＦＥＣ生成情報格納部２０８（以下、格納部２０８とする。）は、後述するＦＥＣ生成情報テーブルを格納するメモリ等である。また、図３に示した各ブロックの機能の一部又は全体は、記録媒体に記録されたプログラムをプロセッサが実行することにより実現されてもよい。プロセッサがプログラムを実行して図３の各ブロックの機能を実現する場合の構成例の図と説明については後述する。

図３に示す送信装置１０１において、映像入力部２０１は、例えば図示しないデータストレージ装置などから映像データを取得する。映像入力部２０１に入力された映像データは、映像符号化部２０２へ送られる。映像符号化部２０２は、映像データを圧縮符号化して、前述したような複数のレイヤーでストリーム伝送される、複数のストリームデータを形成する。映像符号化部２０２は、複数のストリームデータをパケット生成部２０３へ出力する。パケット生成部２０３は、圧縮符号化された映像データからなるストリームデータを、ＲＴＰ送信用のパケットデータに分割して、バッファ２０７へ出力する。なお、以下の説明では、記載を簡略にするため、パケットデータを「パケット」と表記する。バッファ２０７は、パケットを格納する。音声入力部２０４は、図示しないデータストレージ装置などから音声データを取得する。音声入力部２０４に入力された音声データは、音声符号化部２０５へ送られる。音声符号化部２０５は、音声データを圧縮符号化してパケット生成部２０６へ出力する。パケット生成部２０６は、圧縮符号化された音声データからなるストリームデータを、ＲＴＰ送信用のパケットに分割して、バッファ２０７へ出力する。バッファ２０７は、パケットを格納する。図３において、バッファ２０７に保持されているパケットが、前述のメディアパケットに相当する。

ＦＥＣパケット生成部２０９は、バッファ２０７に保持されているメディアパケットの中から、格納部２０８の後述するＦＥＣ生成情報テーブルを参照してＦＥＣグループの対象となる各メディアパケットを順次読み出してＦＥＣパケットを生成する。なお、ＦＥＣ生成情報テーブルの詳細については後述する。そして、ＦＥＣパケット生成部２０９は、ＦＥＣ生成処理が行われた後のメディアパケットをパケット送信部２１０へ渡す。送信部２１０は、メディアパケットを受信装置１０３へ送信する。また、ＦＥＣパケット生成部２０９は、ＦＥＣ生成処理による生成が完了したＦＥＣパケットを、送信部２１０に渡す。送信部２１０は、ＦＥＣパケットを受信装置１０３へ送信する。また、ＦＥＣパケット生成部２０９は、ＦＥＣパケットをバッファ２０７へ送る。バッファ２０７は、ＦＥＣパケットを格納する。ＦＥＣパケット生成部２０９が行うＦＥＣパケット生成処理の詳細については後述する。

パケット受信部２１３は、受信装置１０３からパケットが送られてきた場合、そのパケットを受信する。受信部２１３は、受信したパケットがＲＴＣＰパケットである場合、ＲＴＣＰ解析部２１２に対して、そのＲＴＰＣパケットの解析処理を依頼する。解析部２１２は、ＲＴＣＰパケットを解析する。解析部２１２は、解析したＲＴＣＰパケットが再送信要求（ＲＴＣＰ否定応答）のパケットである場合、再送部２１１に対して、再送信要求されたメディアパケットの再送信を依頼する。再送部２１１は、再送信依頼されたメディアパケットを、バッファ２０７から読み出し、送信部２１０に対して、受信装置１０３への送信を依頼する。これにより、送信部２１０は、再送信依頼されたメディアパケットを受信装置１０３へ送信する。

次に、本実施形態の送信装置１０１において、ＦＥＣパケット生成部２０９がＦＥＣパケットを生成して送信するまでの処理の流れを、図４のフローチャートを参照しながら説明する。

図４において、ＦＥＣパケット生成部２０９は、ステップＳ３０１として、バッファ２０７を監視している。そして、ＦＥＣパケット生成部２０９は、ステップＳ３０２として、パケット生成部２０３、２０６からバッファ２０７へのメディアパケットの入力があったか否かを判断する。ＦＥＣパケット生成部２０９は、ステップＳ３０２においてメディアパケットの入力がないと判断した場合、処理をステップＳ３０１へ戻し、バッファ２０７を監視する。一方、ＦＥＣパケット生成部２０９は、ステップＳ３０２においてメディアパケットの入力があったと判断した場合、処理をステップＳ３０３へ進める。

ステップＳ３０３では、ＦＥＣパケット生成部２０９は、そのメディアパケットをバッファ２０７から読み込む。ステップＳ３０３の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３０４へ進める。ステップＳ３０４では、ＦＥＣパケット生成部２０９は、メディアパケットのヘッダの拡張領域から、メディアパケット識別情報であるＲＴＰシーケンス番号とストリーム識別情報であるＳＳＲＣを取り出す。なお、ヘッダの拡張領域の詳細については後述する。ステップＳ３０４の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３０５へ進める。

ステップＳ３０５では、ＦＥＣパケット生成部２０９は、取り出したＲＴＰシーケンス番号とストリーム識別子を検索キーとして、格納部２０８のＦＥＣ生成情報テーブルを検索する。ステップＳ３０５の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３０６へ進める。

ステップＳ３０６では、ＦＥＣパケット生成部２０９は、ＦＥＣ生成情報テーブルの検索結果から、ステップＳ３０３で読み込んだメディアパケットの属するＦＥＣグループのＦＥＣパケットが、既に作成されてバッファ２０７に保持されているか否かを判断する。ＦＥＣパケット生成部２０９は、ステップＳ３０６において、該当するＦＥＣパケットが作成済みでバッファ２０７に保持されていると判断した場合には、処理をステップＳ３０７へ進める。

ステップＳ３０７では、ＦＥＣパケット生成部２０９は、バッファ２０７からＦＥＣパケットを読み出す。ステップＳ３０７の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３０８へ進める。

一方、ＦＥＣパケット生成部２０９は、ステップＳ３０６において該当するＦＥＣパケットがないと判断した場合には、処理をステップＳ３０９へ進める。すなわち、ステップＳ３０６で該当するＦＥＣパケットがないと判断された場合、ステップＳ３０３で読み込まれたメディアパケットは、作成済みのＦＥＣパケットのＦＥＣグループの対象になっていないメディアパケットということになる。ステップＳ３０９では、ＦＥＣパケット生成部２０９は、新たにＦＥＣパケットを生成した後、処理をステップＳ３１０へ進める。ステップＳ３１０では、ＦＥＣパケット生成部２０９は、新たに生成したＦＥＣパケットに関する情報を、ＦＥＣ生成情報テーブルへ登録する。このステップＳ３１０の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３０８へ進める。

ステップＳ３０８では、ＦＥＣパケット生成部２０９は、ステップＳ３０３で読み込まれたメディアパケットを参照して、ＦＥＣデータの生成演算を行う。このステップＳ３０８の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３１１へ進める。

ステップＳ３１１では、ＦＥＣパケット生成部２０９は、ステップＳ３０８でのＦＥＣ演算が終わったメディアパケットを送信部２１０へ出力する。またこのときのＦＥＣパケット生成部２０９は、後述するように、メディアパケットのヘッダ部の拡張領域に、ＦＥＣグループの識別情報、ストリーム識別情報、パケット識別情報等を記述する。その後、メディアパケットは、送信部２１０から受信装置１０３へ送信されることになる。ステップＳ３１１の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３１２へ進める。

ステップＳ３１２では、ＦＥＣパケット生成部２０９は、ＦＥＣグループの対象となっている全てのメディアパケットに対するＦＥＣ演算が完了したか否かを判断する。そして、ＦＥＣパケット生成部２０９は、ＦＥＣグループの対象となっている全てのメディアパケットに対するＦＥＣ演算が完了したと判断した場合には、処理をステップＳ３１３へ進める。一方、ＦＥＣパケット生成部２０９は、ＦＥＣグループの対象となっている全てのメディアパケットに対するＦＥＣ演算が完了していないと判断した場合には、処理をステップＳ３１５へ進める。

ステップＳ３１５では、ＦＥＣパケット生成部２０９は、ステップＳ３０８のＦＥＣ生成演算によるＦＥＣデータのＦＥＣパケットを、バッファ２０７へ保持させる。このステップＳ３１５の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３１０へ戻す。

一方、ステップＳ３１３では、ＦＥＣパケット生成部２０９は、ＦＥＣパケットを送信部２１０へ出力する。これにより、ＦＥＣパケットは、送信部２１０から受信装置１０３へ送信されることになる。すなわち、ＦＥＣパケットは、ＦＥＣグループの対象となっている各メディアパケットの送信が終わった直後に、受信装置１０３へ送信されることになる。ステップＳ３１３の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３１４へ進める。

ステップＳ３１４では、ＦＥＣパケット生成部２０９は、格納部２０８のＦＥＣ生成情報テーブルから該当するＦＥＣパケットの登録を削除する。ステップＳ３１４の後、ＦＥＣパケット生成部２０９は、処理をステップＳ３１６へ進める。

ステップＳ３１６では、ＦＥＣパケット生成部２０９は、全てのストリームの全てのメディアパケットに対するＦＥＣ演算が終わり、それらＦＥＣ演算が終わった全てのメディアパケットとＦＥＣパケットの送信が完了したか否か判断する。そして、ＦＥＣパケット生成部２０９は、全ての送信が完了しておらず、未処理のメディアパケットが残っていると判断した場合には、ステップＳ３０１へ処理を戻す。一方、ＦＥＣパケット生成部２０９は、全ての送信が完了したと判断した場合には、パケット生成処理を終了する。

次に、図５（ａ）、図５（ｂ）、図６（ａ）、図７（ａ）を参照して、図４のステップＳ３０８でＦＥＣパケット生成部２０９が行うＦＥＣ演算処理の詳細を説明する。

図５（ａ）、図５（ｂ）は、本実施形態におけるメディアパケットのＲＴＰパケットヘッダ４００のフォーマットを示す図である。なお、図５（ａ）と図５（ｂ）に示している各フィールドは同じであるが、特に図５（ｂ）の例は、各フィールドに具体的な数値が記述された例を示している。図５（ｂ）の場合、図５（ａ）と区別するために、各フィールドには各参照番号に「ｂ」が付加されている。以下、図５（ａ）の例を挙げて説明する。

図５（ａ）は、標準ＲＴＰパケットのヘッダ拡張領域を示しており、ＳＳＲＣフィールド４０５にはＳＳＲＣが記述され、シーケンス番号フィールド４０４にはＲＴＰシーケンス番号が記述される。ＳＳＲＣは前述したように、メディアパケットのストリーム識別情報（識別子）であり、このＳＳＲＣによりストリームが特定される。また前述したように、パケット識別情報となされているＲＴＰシーケンス番号により、メディアパケットが特定される。すなわち、標準ＲＴＰパケットのヘッダ拡張領域を利用することで、前述の図２（ｂ）に示したような各メディアパケットを特定するＲＴＰシーケンス番号の指定が可能となる。また、各メディアパケットが属するストリームを特定するＳＳＲＣの指定が可能となる。

さらに、本実施形態では、ＲＴＰパケットのヘッダ拡張領域の一部を、ＦＥＣ用拡張フィールド４０１として使用する。本実施形態において、ＦＥＣ用拡張フィールド４０１は、ＦＥＣ拡張用識別子フィールド４１０と、バイト数フィールド４１１と、ＦＥＣグループシーケンス番号フィールド４１２と、非使用フィールド４１３とが、それぞれ２バイトで構成される。なお、非使用フィールド（ｎ／ａ）４１３は、便宜上ヘッダ拡張領域の全体サイズが４の倍数であることが好まれるため挿入されている。ペイロード部４２０は、データ本体が記述される領域である。

ＦＥＣグループシーケンス番号（ＦＥＣ ｇｒｏｕｐ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）は、ＲＴＰストリームのシーケンス番号とは異なり、同じＦＥＣグループに属する各レイヤーのストリームのメディアパケットで共用される連続番号である。すなわち、ＦＥＣグループシーケンス番号は、ＦＥＣグループを識別するためのグループ識別情報となされている。このＦＥＣグループシーケンス番号により、前述の図２（ｂ）に示したような各レイヤーのストリームを横断するようなＦＥＣグループの各メディアパケットが何れのＦＥＣグループに属しているのかをそれぞれ一意に特定可能となる。なお、本実施形態におけるＦＥＣパケットのフォーマットは、ＲＦＣ５１０９の定義と同一であるためここでは説明を省略する。

ＦＥＣ拡張用識別子（ｐｒｏｆｉｌｅ ＩＤ ｆｏｒ ＦＥＣ ｅｘｔｅｎｓｉｏｎ）は、ヘッダ拡張領域が、本実施形態のＦＥＣ用拡張フィールドとして使用されていることを識別するための識別情報（識別子）である。バイト数（ｌｅｎｇｔｈ）は、ＦＥＣ用拡張フィールド４０１のデータ部のバイト数である。

図６（ａ）は、本実施形態におけるＦＥＣ生成情報テーブルの記述内容の一例を示した図である。ＦＥＣ生成情報テーブルは、ＦＥＣグループＩＤとグループ最大パケット数とＦＥＣグループシーケンス番号とグループ残り数とストリーム１選択フラグとストリーム２選択フラグとストリーム３選択フラグが一つのエントリーとして登録されている。なお、図６（ａ）では、ストリーム１，２，３の選択フラグの数値のみ２進数表記であり、他の数値は全て１０進数表記である。

図６（ａ）の例において、グループ最大パケット数は、該当するエントリーのＦＥＣグループに属するメディアパケットの数を示している。図６（ａ）のＦＥＣグループＩＤが「１」のエントリーの場合、グループ最大パケット数として「１０」が登録されているため、ＦＥＣグループに属するメディアパケット数は１０個となる。

図６（ａ）のＦＥＣグループシーケンス番号は、図５（ａ）に示したＦＥＣ用拡張フィールド４０１のＦＥＣグループシーケンス番号フィールド４１２に記述される番号が登録されている。図６（ａ）のグループ最大パケット数は、一つのＦＥＣグループに含まれるメディアパケットの数を示す。図６（ａ）の例では、ＩＤが「１」のＦＥＣグループは、１０個のメディアパケットを含むことを示している。また、図６（ａ）のＦＥＣグループシーケンス番号の欄には、同じＦＥＣグループに含まれる各メディアパケットを区別するためシーケンス番号が記載される。図６（ａ）のＦＥＣグループシーケンス番号の欄に記載されるシーケンス番号は、メディアパケットに対するＦＥＣ演算処理が行われる度に更新される。すなわち、ＦＥＣグループシーケンス番号の欄に記載されるシーケンス番号は、新たにＦＥＣ演算処理が完了したメディアパケットのシーケンス番号で上書きされる。図６（ａ）のＦＥＣグループＩＤが「１」のエントリーの場合、ＦＥＣグループシーケンス番号は「３４５６」の値となされている。この場合、図５（ｂ）のＦＥＣグループシーケンス番号フィールド４１２には、十進法の「３４５６」を二進法で表現した「００００１１０１１０００００００」の値が記述されることになる。

図６（ａ）のグループ残り数は、そのエントリーのＦＥＣグループにおいてＦＥＣ演算処理が未処理となっている残りのメディアパケット数を示している。図６（ａ）のＦＥＣグループＩＤが「１」のエントリーの場合、グループ残り数が「５」となっているため、ＦＥＣ演算処理が未処理のメディアパケットは残り５個となる。

図６（ａ）のストリーム１選択フラグは、例えば図２（ｂ）の基本レイヤーのストリームに対応している。このストリーム１選択フラグに「１」が立てられている場合、エントリーのＦＥＣグループに属するメディアパケットは、基本レイヤーのストリームに含まれていることを示している。ストリーム２選択フラグは、例えば図２（ｂ）の第１拡張レイヤーのストリームに対応している。このストリーム２選択フラグに「１」が立てられている場合、エントリーのＦＥＣグループに属するメディアパケットは、第１拡張レイヤーのストリームに含まれていることを示している。ストリーム３選択フラグは、例えば図２（ｂ）の第２拡張レイヤーのストリームに対応している。このストリーム３選択フラグに「１」が立てられている場合、エントリーのＦＥＣグループに属するメディアパケットは、第２拡張レイヤーのストリームに含まれていることを示している。図６（ａ）のＦＥＣグループＩＤが「１」のエントリーの場合、各フラグに「１」が立てられているため、このエントリーのＦＥＣグループは、基本レイヤー、第１拡張レイヤー、第２拡張レイヤーのメディアパケットを含んでいることになる。

図６（ａ）のＦＥＣグループＩＤが「１」のエントリーの場合、ＲＴＰヘッダ部のＦＥＣ用拡張フィールドには、図５（ｂ）に示すヘッダ４００ｂのＦＥＣ用拡張フィールド４０１ｂのような各値が記述される。すなわち、図５（ｂ）において、ＦＥＣ拡張用識別子フィールド４１０ｂには、拡張フィールドの使用を明示する拡張フラグとして１６ビット分の「１」の値が記述される。また、ＦＥＣグループシーケンス番号フィールド４１２ｂには、図６（ａ）のＦＥＣグループシーケンス番号「３４５６」を表す１６ビットの「００００１１０１１０００００００」の値が記述される。また、バイト数フィールド４１１ｂには、バイト数が「４」を表す１６ビットの「０００００００００００００１００」の値が記述される。なお、非使用フィールド４１３ｂは全て「０」となされる。

図７（ａ）は、図４のステップＳ３０８のＦＥＣ演算処理の詳細な処理の流れを示すフローチャートである。以下、図７（ａ）のフローチャートを参照しながら、本実施形態のＦＥＣパケット生成部２０９によるＦＥＣ演算処理について説明する。

図７（ａ）において、本実施形態のＦＥＣパケット生成部２０９は、先ず、ステップＳ６０１として、図６（ａ）のＦＥＣ生成情報テーブルから、該当するエントリーの情報を読み込む。ステップＳ６０１の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０２へ進める。

ステップＳ６０２では、ＦＥＣパケット生成部２０９は、ＦＥＣパケットのヘッダ部とペイロード部に対してＦＥＣ演算（ＸＯＲ演算）を行う。ステップＳ６０２の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０３へ進める。

ステップＳ６０３では、ＦＥＣパケット生成部２０９は、図６（ａ）のＦＥＣ生成情報テーブルのＦＥＣグループシーケンス番号の値を更新する。ステップＳ６０３の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０４へ進める。

ステップＳ６０４では、ＦＥＣパケット生成部２０９は、メディアパケットのＦＥＣ用拡張フィールドにＦＥＣ情報（ＦＥＣ拡張用識別子、バイト数、ＦＥＣグループシーケンス番号）を記述する。ステップＳ６０４の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０５へ進める。

ステップＳ６０５では、ＦＥＣパケット生成部２０９は、図６（ａ）のＦＥＣ生成情報テーブルの該当するエントリーの情報を更新する。このステップＳ６０５の処理の完了により、ＦＥＣパケット生成部２０９は、図４のフローチャートのステップＳ３０８のＦＥＣ演算処理を終えて、処理を図４のステップＳ３０９へ進める。

以上の処理により、本実施形態の送信装置１０１は、前述したような、複数のストリームを横断するようなＦＥＣグループのメディアパケットを用いて生成されたＦＥＣパケットと、各メディアメディパケットを、受信装置１０３へ送信することができる。

なお、本実施形態では、ＲＴＰパケットのヘッダ部の拡張領域の一部をＦＥＣ用拡張フィールドとして用い、そのフィールドにＦＥＣグループシーケンス番号等を追加している。このため、ペイロード長が減少してネットワークの利用効率への影響が出ることが懸念されるが、ＲＴＰのメディアパケットのペイロード長は、ＦＥＣパケットの最大ペイロード長に対応するために、１４バイトから１８バイトの縮小が行われる。本実施形態で用いるＦＥＣ用拡張フィールド分の８バイトは、その縮小分より小さいため、本実施形態によるメディアパケットのペイロード長の縮小はない。したがって、本実施形態のように、ＲＴＰパケットのヘッダ部の拡張領域の一部をＦＥＣ用拡張フィールドとして用いたとしても、ネットワークの利用効率に対して影響が出ることはない。また、ＲＴＰの規格によれば、ＲＴＰパケットのヘッダ部の拡張フィールドは、未対応であればそれを無視して良い仕様となされている。このため、メディアパケットのヘッダ部のＦＥＣ用拡張フィールドにＦＥＣグループシーケンス番号等を追加することは仕様上問題がない。

次に、本実施形態の送信装置１０１から送信された各レイヤーのストリームデータを受信する本実施形態の受信装置１０３の詳細を説明する。図８は、本実施形態の受信装置１０３の詳細な構成を示す図である。図８の各ブロックの機能の一部又は全体は、一例としてハードウェアにより実現することができる。なお、図８のパケットバッファ７０７（以下、バッファ７０７とする。）、復号化情報格納部７０８（以下、格納部７０８とする。）は、例えばＨＤＤや大容量半導体メモリとなされる。また、図８に示した各ブロックの機能の一部又は全体は、記録媒体に記録されたプログラムをプロセッサが実行することにより実現されてもよい。プロセッサがプログラムを実行して図８の各ブロックの機能を実現する場合の構成例の図と説明については後述する。

図８に示す受信装置１０３において、パケット受信部７１０は、送信装置１０１から前述したような時系列の順に送信されてきたメディアパケットとＦＥＣパケットを受信する。受信部７１０は、それらメディアパケットとＦＥＣパケットの各受信パケットデータをバッファ７０７へ出力する。バッファ７０７は、受信部７１０から送られてきたメディアパケットとＦＥＣパケットの受信パケットデータを格納する。バッファ７０７は、格納したメディアパケットのうち、映像のパケットをパケット結合部７０３へ出力し、音声のパケットをパケット結合部７０６へ出力する。

パケット結合部７０３は、ストリームごとに、各映像のパケットを結合して映像符号化データを生成して映像復号化部７０２へ出力する。映像復号化部７０２は、ストリームごとの映像符号化データを復号化する。映像復号化部７０２は、復号化した映像データを映像表示部７０１へ出力する。映像表示部７０１は、映像データを図示しないディスプレイ装置等へ出力する。また、映像復号化部７０２は、復号のために読み込んだ映像符号化データのタイムスタンプ情報を格納部７０８に格納させる。

パケット結合部７０６は、ストリームの各音声のパケットを結合して音声符号化データを生成して音声復号化部７０５へ出力する。音声復号化部７０５は、音声符号化データを復号化する。音声復号化部７０５は、復号化した音声データを音声出力部７０４へ出力する。音声出力部７０４は、音声データを図示しないスピーカ等へ出力する。また、音声復号化部７０５は、復号のために読み込んだ音声符号化データのタイムスタンプ情報を格納部７０８に格納させる。

ＦＥＣ復元部７０９は、バッファ７０７を監視し、損失データパケット（メディアパケットの損失）を検知すると、ＦＥＣパケットを用いて、その損失データパケット（損失メディアパケット）の復元を試みる。ＦＥＣ復元部７０９は、損失したメディアパケットが、何れのストリームに属し、何れのＦＥＣグループに属しているかについては、前述したトリーム識別情報とパケット識別情報、グループ識別情報に基づいて識別する。ＦＥＣ復元部７０９における復元処理の詳細は後述する。ＦＥＣ復元部７０９は、メディアパケットの復元が成功すると、その復元したメディアパケットをバッファ７０７へ保持させる。

一方、ＦＥＣ復元部７０９は、バッファ７０７を監視するとともに、格納部７０８を参照して符号化データの復号化が間に合わなくなる虞がある損失メディアパケットを検出する。ＦＥＣ復元部７０９は、復号化が間に合わなくなる損失パケットが検出された場合、再送要求部７１１に対し、該当するメディアパケットの再送信を依頼する。

再送要求部７１１は、ＦＥＣ復元部７０９から再送信依頼を受けると、その再送信依頼で指定されたメディアパケットに関するＲＴＣＰ否定応答のＲＴＣＰパケットを生成し、送信部７１２を介して送信元である送信装置１０１に送信する。

次に、本実施形態の受信装置１０３のＦＥＣ復元部７０９における復元処理の流れを、図９のフローチャートを参照しながら説明する。

図９において、ＦＥＣ復元部７０９は、ステップＳ８０１として、バッファ７０７を監視している。そして、ＦＥＣ復元部７０９は、ステップＳ８０２として、バッファ７０７に保持されるメディアパケットのＲＴＰシーケンス番号及び到着時間からメディアパケットの損失が発生したか否かを判断する。ＦＥＣ復元部７０９は、メディアパケットの損失が発生したと判断した場合には、処理をステップＳ８０３へ進め、一方、メディアパケットの損失が発生していないと判断した場合には、処理をステップＳ８０４へ進める。

ステップＳ８０３では、ＦＥＣ復元部７０９は、損失メディアパケットのＦＥＣ復元処理を試みる。なお、ステップＳ８０３におけるＦＥＣ復元処理の詳細は後述する。ステップＳ８０３の後、ＦＥＣ復元部７０９は、処理をステップＳ８０４へ進める。

ステップＳ８０４では、ＦＥＣ復元部７０９は、格納部７０８に格納されているタイムスタンプに基づいて、符号化データの復号期限を取得する。ステップＳ８０４の後、ＦＥＣ復元部７０９は、処理をステップＳ８０５へ進める。

ステップＳ８０５では、ＦＥＣ復元部７０９は、復号期限の情報から、直近の復号期限に間に合わないと予測される損失メディアパケットがあるか否かを判断する。ＦＥＣ復元部７０９は、直近の復号期限に間に合わないと予測される損失メディアパケットがあると判断した場合は、処理をステップＳ８０６へ進める。一方、ＦＥＣ復元部７０９は、直近の復号期限に間に合わないと損失メディアパケットが無いと判断した場合は、処理をステップＳ８０７へ進める。

ステップＳ８０６では、ＦＥＣ復元部７０９は、再送要求部７１１に対し、該当するメディアパケットの再送信を依頼する。ステップＳ８０６の後、ＦＥＣ復元部７０９は、処理をステップＳ８０１へ戻す。

ステップＳ８０７では、ＦＥＣ復元部７０９は、全てのストリームの全てのメディアパケットが受信されて復号化も完了したか否か判断する。そして、ＦＥＣ復元部７０９は、全てのメディアパケットの受信と復号化が完了しておらず、未処理のメディアパケットが残っていると判断した場合には、ステップＳ８０１へ処理を戻す。一方、ＦＥＣ復元部７０９は、全てのメディアパケットの受信と復号化が完了したと判断した場合には、処理を終了する。

次に、図１０（ａ）は、図９のステップＳ８０３でのＦＥＣ復元処理の詳細な処理の流れを示すフローチャートである。以下、図１０（ａ）のフローチャートを参照しながら、本実施形態のＦＥＣ復元部７０９による詳細なＦＥＣ復元処理について説明する。

図１０（ａ）において、本実施形態のＦＥＣ復元部７０９は、先ず、ステップＳ９０１として、損失したメディアパケットのＲＴＰシーケンス番号と到着時間、その前後に到着したメディアパケットのＦＥＣグループシーケンス番号を取得する。なお、損失メディアパケットのＲＴＰシーケンス番号と到着時間が取得できない場合、ＦＥＣ復元部７０９は、その前後に到着したメディアパケットのＦＥＣグループシーケンス番号から、損失メディアパケットのＲＴＰシーケンス番号と到着時間を予測する。そして、ＦＥＣ復元部７０９は、それら損失メディアパケットのＲＴＰシーケンス番号と到着時間、その前後に到着したメディアパケットのＦＥＣグループシーケンス番号から、損失メディアパケットのＦＥＣグループシーケンス番号を求める。ステップＳ９０１の後、ＦＥＣ復元部７０９は、処理をステップＳ９０２へ進める。

ステップＳ９０２では、ＦＥＣ復元部７０９は、損失メディアパケットのＦＥＣグループシーケンス番号から、復元対象としているＦＥＣパケットを検索する。ステップＳ９０２の後、ＦＥＣ復元部７０９は、処理をステップＳ９０３へ進める。

ステップＳ９０３では、ＦＥＣ復元部７０９は、ステップＳ９０２での検索により該当するＦＥＣパケットがあったか否か判断する。ＦＥＣ復元部７０９は、該当するＦＥＣパケットが無いと判断した場合には、ＦＥＣ復元処理を終了して、図９のステップＳ８０４へ処理を進める。一方、ＦＥＣ復元部７０９は、該当するＦＥＣパケットが有ると判断した場合には、処理をステップＳ９０４へ進める。

ステップＳ９０４では、ＦＥＣ復元部７０９は、ＦＥＣグループシーケンス番号により該当するＦＥＣパケットがＦＥＣグループの対象としているメディアパケットをバッファ７０７から検索する。ステップＳ９０４の後、ＦＥＣ復元部７０９は、処理をステップＳ９０５へ進める。

ステップＳ９０５では、ＦＥＣ復元部７０９は、損失メディアパケットを復元できるだけの各メディアパケットが揃っているか否かを判断する。ＦＥＣ復元部７０９は、損失メディアパケットを復元できるだけのメディアパケットが揃わず、復元が不可能であると判断した場合には、ＦＥＣ復元処理を終了して、図９のステップＳ８０４へ処理を進める。一方、ＦＥＣ復元部７０９は、損失メディアパケットを復元できるだけのメディアパケットがあり、復元が可能であると判断した場合には、処理をステップＳ９０６へ進める。

ステップＳ９０６では、ＦＥＣ復元部７０９は、損失メディアパケットを、ＦＥＣグループのＦＥＣパケットとメディアパケットを用いた復元演算（ＸＯＲ演算）を行う。ステップＳ９０６の後、ＦＥＣ復元部７０９は、処理をステップＳ９０７へ進める。

ステップＳ９０７では、ＦＥＣ復元部７０９は、復元されたメディアパケットをバッファ７０７に保持して、ＦＥＣ復元処理を終了し、図９のステップＳ８０４へ処理を進める。

以上の処理により、本実施形態の受信装置１０３は、複数のストリームを横断するようにしてＦＥＣグループが構成されたメディアパケットとＦＥＣパケットを用いて、損失したメディアパケットを復元することができる。

なお、本実施形態では、受信装置１０３のＦＥＣ復元部７０９は、メディアパケットの損失判断をＲＴＰシーケンス番号により行い、その後、対応するＦＥＣグループシーケンス番号を検索している。その他の例として、ＦＥＣ復元部７０９は、メディアパケットの損失判断を、ＦＥＣグループシーケンス番号を参照することで行ってもよい。

以上、説明したように、第１の実施形態の送信装置１０１、受信装置１０３によれば、エラー回復の遅延を防止可能である。

＜第２の実施形態＞
次に、第１の実施形態とは一部の処理が異なる第２の実施形態について説明する。なお、第２の実施形態の送信装置１０１、受信装置１０３の構成は前述の第１の実施形態の場合と同じである。第２の実施形態の場合、ＦＥＣ情報、図４のステップＳ３０８のＦＥＣ演算処理、図９のステップＳ８０３のＦＥＣ復元処理が、第１の実施形態とは異なる。ここでは、第１の実施形態とは異なる部分についてのみ説明する。以下、図６（ｂ）、図７（ｂ）、図１１（ａ）、図１１（ｂ）を参照して、第２の実施形態の場合の図４のステップＳ３０８のＦＥＣ演算処理の詳細について説明する。

図１１（ａ）は、第２の実施形態におけるＦＥＣパケットのヘッダ１０００のフォーマットを示す図である。図１１（ａ）に示す本実施形態のＦＥＣパケットのヘッダ１０００は、ＲＦＣ５１０９で定義されているＦＥＣパケットフォーマットとは一部異なっている。第２の実施形態の場合のＦＥＣパケットのヘッダ１０００は、ヘッダ拡張領域の一部が、ストリーム用拡張フィールド１００１，１００２として用いられる。

ストリーム用拡張フィールド１００１は、ＳＳＲＣフィールド１０１０とベースシーケンス番号（ｂａｓｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）フィールド１０１１とマスク（ｍａｓｋ）フィールド１０１２により構成される。同様に、ストリーム用拡張フィールド１００２は、ＳＳＲＣフィールド１０１３とベースシーケンス番号フィールド１０１４とマスクフィールド１０１５により構成される。ストリーム用拡張フィールド１００１はストリーム１用の拡張フィールドであり、ストリーム用拡張フィールド１００２はストリーム２用の拡張フィールドである。なお、図１１（ａ）の例は、ストリーム１，２の二つのストリームのみを挙げているが、これは一例であり、三つ以上であってもよい。ストリーム１は例えば基本レイヤーのストリーム、ストリーム２は例えば第１拡張ストリームのように、各レイヤーのストリームに関連付けられる。ストリーム用拡張フィールドに記述されるストリーム数は、ｎｕｍｂｅｒ ｏｆ ｓｏｕｒｃｅｓフィールド１０２０に記述される。すなわち、ＳＳＲＣフィールドとベースシーケンス番号フィールド及びマスクフィールドは、ＦＥＣグループの対象となるメディアパケットが属しているストリーム数に対応した数だけ連なるように、ＦＥＣパケットのヘッダ拡張領域内に記述される。なお、ｂａｓｅ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒフィールドは、ＲＦＣ５１０９に定義されているＳＮ ｂａｓｅフィールドであり、また、ｍａｓｋフィールドもＲＦＣ５１０９に定義されているフィールドである。

ＦＥＣパケットのヘッダ部のＳＳＲＣフィールドは、ＦＥＣグループの対象となるメディアパケットが属するストリームを識別するストリーム識別情報（識別子）が記述されるフィールドである。ベースシーケンス番号フィールドは、ＳＳＲＣにより特定されるストリーム内で、ＦＥＣグループの対象となっているメディアパケットのうちで、先頭のメディアパケットを表すシーケンス番号が記述されるフィールドである。マスクフィールドは、ＳＳＲＣにより特定されるストリーム内で、ベースシーケンス番号フィールドに記述された先頭のパケットに続く何れのメディアパケットが、ＦＥＣグループの対象になされているかを表す情報が記述されるフィールドである。マスクフィールドに記述される１６ビットの値は、それぞれの値が、ＦＥＣグループの対象になされているメディアパケットの並び順に対応している。すなわち、マスクフィールドの１６ビットのうち「１」のビットが立てられている順番に対応したメディアパケットが、ＦＥＣパケットの生成に関連付けられている（ＦＥＣグループの対象になっている）ことを示している。これらベースシーケンス番号フィールド及びマスクフィールドの値により、ＳＳＲＣフィールドで識別されるストリーム内でＦＥＣグループの対象となっているメディアパケットが特定される。すなわち、ベースシーケンス番号フィールド及びマスクフィールドの値は、ＦＥＣグループの対象となるメディアパケットが、ＳＳＲＣで特定されたストリーム内の、何れのメディアパケットであるかを特定するためのパケット識別情報となっている。

図６（ｂ）は、第２の実施形態におけるＦＥＣ生成情報テーブルの記述内容の一例を示した図である。第２の実施形態の場合のＦＥＣ生成情報テーブルは、ＦＥＣパケットＩＤと各ストリームのベースシーケンス番号と選択マスクの各値が、一つのエントリーとして登録されている。図６（ｂ）のベースシーケンス番号は図１１（ａ）のベースシーケンス番号フィールドに記述される情報であり、図６（ｂ）の選択マスクの値は図１１（ａ）のマスクフィールドに記述される情報である。なお、図６（ｂ）では、ストリーム１，２の選択マスクの数値のみ２進数表記であり、他の数値は全て１０進数表記である。

また、図６（ｂ）のＦＥＣパケットＩＤが「１」のエントリーの場合、ＦＥＣパケットのヘッダ部の拡張フィールドには、図１１（ｂ）に示すヘッダ部１０５０のストリーム用拡張フィールド１０５１のような各値が記述される。すなわち、図６（ｂ）の例において、ＦＥＣパケットＩＤが「１」のエントリーでは、ストリーム１のベースシーケンス番号が「１０００」となされている。また、ストリーム１の選択マスクは「１０１０１０１０１０１０１０１０」、ストリーム２のベースシーケンス番号は「４５００」、ストリーム２の選択マスクは「０１０１０１０１０１０１０１０１」となされている。したがって、図６（ｂ）のＦＥＣパケットＩＤが「１」のエントリーの場合、図１１（ｂ）のストリーム用拡張フィールド１０５１のＳＳＲＣフィールド１０６０には「１」が記述される。また、ベースシーケンス番号フィールド１０６１には「１０００」を２進数で表した「００００００１１１１１０１０００」が、マスクフィールド１０６２には「１０１０１０１０１０１０１０１０」が記述される。同様に、図６（ｂ）のＦＥＣパケットＩＤが「２」のエントリーの場合、図１１（ｂ）のストリーム用拡張フィールド１０５２のＳＳＲＣフィールド１０６３には「２」が記述される。また、ベースシーケンス番号フィールド１０６４には「４５００」を２進数で表した「０００１０００１１００１０１００」が、マスクフィールド１０６５には「０１０１０１０１０１０１０１０１」が記述される。

図７（ｂ）は、第２の実施形態における図４のステップＳ３０８のＦＥＣ演算処理の詳細な処理の流れを示すフローチャートである。以下、図７（ｂ）のフローチャートを参照しながら、第２の実施形態の場合のＦＥＣパケット生成部２０９によるＦＥＣ演算処理について説明する。

図７（ｂ）において、第２の実施形態のＦＥＣパケット生成部２０９は、先ず、ステップＳ６０６として、図７（ｂ）のＦＥＣ生成情報テーブルから、該当するエントリーの情報を読み込む。ステップＳ６０６の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０７へ進める。

ステップＳ６０７では、ＦＥＣパケット生成部２０９は、図１１（ａ）、図１１（ｂ）に示したようなＦＥＣパケットのヘッダ部のフィールドとペイロード部のデータに対して、前述同様にＦＥＣ演算（ＸＯＲ演算）を行う。ステップＳ６０７の後、ＦＥＣパケット生成部２０９は、処理をステップＳ６０８へ進める。

ステップＳ６０８では、ＦＥＣパケット生成部２０９は、ＦＥＣパケットのストリーム用拡張フィールドであるＳＳＲＣフィールド、ベースシーケンス番号フィールド、マスクフィールドに、それぞれストリームとメディアパケットの各識別情報を書き込む。

以上の処理により、第２の実施形態の送信装置１０１は、複数のストリームを横断するようなＦＥＣグループのメディアパケットを用いて生成されたＦＥＣパケットと、各メディアパケットを、受信装置１０３へ送信する。

次に、第２の実施形態の受信装置１０３のＦＥＣ復元部７０９の復元処理は概ね図９のフローチャートの流れに沿って行われるが、第２の実施形態の場合は、ステップＳ８０３における処理が第１の実施形態とは異なる。第２の実施形態のＦＥＣ復元部７０９におけるステップＳ８０３のＦＥＣ復元処理の詳細な流れを図１０（ｂ）のフローチャートを参照しながら説明する。

ＦＥＣ復元部７０９は、先ずステップＳ９０８として、損失したメディアパケットのＲＴＰシーケンス番号と、各ＦＥＣパケットのヘッダ部のＳＳＲＣフィールド、ベースシーケンスフィールド、マスクフィールドを参照する。そして、ＦＥＣ復元部７０９は、それら参照した値を検索キーとして、損失メディアパケットを復元可能なＦＥＣパケットを、バッファ７０７から検索する。ステップＳ９０８の後、ＦＥＣ復元部７０９は、処理をステップＳ９０９へ進める。

ステップＳ９０９では、ＦＥＣ復元部７０９は、ステップＳ９０８での検索処理で該当するＦＥＣパケットが検索できたか否かを判断する。ＦＥＣ復元部７０９は、該当するＦＥＣパケットがないと判断した場合には、復元処理を終了して、図９のステップＳ８０４へ処理を進める。一方、ＦＥＣ復元部７０９は、該当するＦＥＣパケットがあると判断した場合には、処理をステップＳ９１０へ進める。

ステップＳ９１０では、ＦＥＣ復元部７０９は、該当するＦＥＣパケットのヘッダ部のＳＳＲＣフィールド、ベースシーケンス番号フィールド、マスクフィールドの各値を参照して、復元に必要なメディアパケットを、バッファ７０７から検索する。ステップＳ９１０の後、ＦＥＣ復元部７０９は、処理をステップＳ９１１へ進める。

ステップＳ９１１では、ＦＥＣ復元部７０９は、損失メディアパケットを復元可能なメディアパケットが揃っているか否かを判断する。ＦＥＣ復元部７０９は、損失メディアパケットを復元できるだけのメディアパケットが揃わず、復元が不可能であると判断した場合には、ＦＥＣ復元処理を終了して、図９のステップＳ８０４へ処理を進める。一方、ＦＥＣ復元部７０９は、損失メディアパケットを復元可能なメディアパケットが揃っていて、復元が可能であると判断した場合には、処理をステップＳ９１２へ進める。

ステップＳ９１２では、ＦＥＣ復元部７０９は、損失メディアパケットを、ＦＥＣパケットと、ステップＳ９０１で検索されたメディアパケットのヘッダ部及びペイロード部を用いた復元演算（ＸＯＲ演算）を行う。ステップＳ９１２の後、ＦＥＣ復元部７０９は、処理をステップＳ９１３へ進める。

ステップＳ９１３では、ＦＥＣ復元部７０９は、復元されたメディアパケットをバッファ７０７に保持して、ＦＥＣ復元処理を終了し、図９のステップＳ８０４へ処理を進める。

前述した処理により、第２の実施形態の受信装置１０３は、複数のストリームを横断するようにして構成されたＦＥＣグループのＦＥＣパケットを用いて、損失したメディアパケットを復元する。

以上説明したように、第２の実施形態の送信装置１０１、受信装置１０３によれば、エラー回復の遅延を防止可能である。

次に、記録媒体に記録されたプログラムをプロセッサが実行することにより、前述した図３に示した各ブロックの機能を実現する送信装置１２００の一例を、図１２に示す。

図１２に示す送信装置１２００において、映像入力部１２０１は、映像データが入力され、前述した図３の映像入力部２０１に対応している。音声入力部１２０４は、音声データが入力され、前述した図３の音声入力部２０４に対応している。

プロセッサ１２０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２０５に記録されたプログラムを読み出して実行する。プロセッサ１２０２は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等とすることができる。ＲＡＭ１２０６は、プロセッサ１２０２がＲＯＭ１２０５から読み出したプログラムが展開される。また、ＲＡＭ１２０６は、プロセッサ１２０２のワークスペースとして用いられる。また、ＲＡＭ１２０６は、図３のバッファ２０７としても機能する。ＲＯＭ１２０５は、前述した図３に示した各ブロックの機能をプロセッサ１２０２が実行するためのプログラムを記録した記録媒体である。

プロセッサ１２０２は、ＲＯＭ１２０５から読み出されてＲＡＭ１２０６に展開されたプログラムを実行することにより、前述した図３に示した各ブロックの機能を実現する。すなわち、プロセッサ１２０２は、例えば、映像又は音声の符号化処理、メディアパケットの生成処理、ＦＥＣパケットの生成処理、メディアパケットの再送制御処理、ＲＴＣＰの解析処理、パケットバッファ制御処理等を行う。なお、プロセッサ１２０２は、複数設けられていてもよく、図３に示した各ブロックの機能を、各プロセッサがそれぞれ分担して実行してもよい。

通信部１２０３は、パケットを送受信するための通信インタフェースである。通信部１２０３は、図３に示したパケット送信部２１０及びパケット受信部２１３の機能を実現する構成である。

次に、記録媒体に記録されたプログラムをプロセッサが実行することにより、前述した図８に示した各ブロックの機能を実現する受信装置は、基本的な構成は図１２と略々同じである。但し、受信装置の場合は、図１２の映像入力部１２０１に代えて映像表示部が設けられ、また図１２の音声入力部１２０４に代えて音声出力部が設けられる。以下、図１２を参照しながら、受信装置について説明する。

受信装置の場合、映像表示部は、映像データをディスプレイ装置等に表示させるための構成であり、前述した図８の映像表示部７０１に対応する。音声出力部は、音声データをスピーカ等に出力させるための構成であり、前述した図８の音声出力部７０４に対応する。

また、受信装置の場合のＲＡＭ１２０６は、図８のバッファ７０７として機能する。受信装置の場合のＲＯＭ１２０５は、前述した図８に示した各ブロックの機能をプロセッサ１２０２が実行するためのプログラムを記録した記録媒体である。

受信装置の場合のプロセッサ１２０２は、ＲＯＭ１２０５から読み出されてＲＡＭ１２０６に展開されたプログラムを実行することにより、前述した図８に示した各ブロックの機能を実現する。すなわち、受信装置の場合のプロセッサ１２０２は、例えば、映像又は音声の復号化処理、メディアパケットの結合処理、ＦＥＣ復元処理、メディアパケットの再送要求制御処理、パケットバッファ制御処理等を行う。なお、受信装置の場合においても、プロセッサ１２０２は、複数設けられていてもよく、図８に示した各ブロックの機能を、各プロセッサがそれぞれ分担して実行してもよい。

受信装置の場合の通信部１２０３は、パケットを送受信するための通信インタフェースである。すなわち、通信部１２０３は、図８に示したパケット受信部７１０及びパケット送信部７１２の機能を実現する構成である。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

また、前述した実施形態では、ＳＶＣを例に挙げたが、例えばＨ．２６５（ＩＳＯ／ＩＥＣ２３００８−２ ＨＥＶＣ）等のフォーマットのストリームデータに対しても本実施形態は適用可能である。

以上、本発明の好ましい実施形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０１ 送信装置、１０２ 受信装置、２０８ ＦＥＣ生成情報格納部、２０９ ＦＥＣ生成部、２１１ パケット再送部、２１２ ＲＴＣＰ解析部、７０８ ＦＥＣ復号化情報格納部、７０９ ＦＥＣ復元部、７１１ パケット再送要求部

Claims (15)

1. 送信データを構成するデータパケットであって第１のデータストリームによって送信される第１のデータパケットと、前記送信データを構成するデータパケットであって前記第１のデータストリームと異なる第２のデータストリームによって送信される第２のデータパケットとを用いて、損失データパケットを復元するための復元用データパケットを生成する生成手段と、
   前記第１のデータパケット及び前記第２のデータパケットの送信に応じて、前記生成手段によって生成された一つの復元用データパケットを送信する送信手段と
   を有する送信装置。
2. 前記生成手段は、前記第１のデータパケット及び前記第２のデータパケットを含むグループを形成し、前記グループに含まれる複数のデータパケットに基づいて前記復元用データパケットを生成する請求項１に記載の送信装置。
3. 前記生成手段は、前記送信データの送信期間のうち一部の期間内に送信される所定数のデータパケットを含む前記グループを形成し、前記グループに含まれるデータパケットに基づいて前記復元用データパケットを生成する請求項２に記載の送信装置。
4. 前記生成手段は、データパケットが属する前記グループを識別するための識別情報を該データパケットに含める請求項２に記載の送信装置。
5. 前記生成手段は、一つの前記グループに含まれる各データパケットを各々識別するための識別情報を生成して、前記復元用データパケットに含める請求項２に記載の送信装置。
6. 前記生成手段は、前記データパケットまたは前記復元用データパケットのヘッダ部の拡張領域のなかに、前記識別情報を書き込む請求項４又は５に記載の送信装置。
7. 前記生成手段は、前方誤り訂正の演算により前記復元用データパケットを生成し、
   前記送信手段は、前記グループに含まれるデータパケットが送信されたタイミングで前記前方誤り訂正の演算による前記復元用データパケットを送信する請求項２〜６の何れか１項に記載の送信装置。
8. 前記送信データは、第１の解像度を有する画像を受信装置が表示するために用いる基本レイヤーのデータと、前記第１の解像度よりも解像度が高い第２の解像度を有する画像を前記受信装置が表示するために前記基本レイヤーのデータとともに用いる拡張レイヤーのデータとを含み、
   前記送信手段は、前記基本レイヤーのデータを前記第１のデータストリームによって送信し、前記拡張レイヤーのデータを前記第２のデータストリームによって送信する請求項１に記載の送信装置。
9. 送信データを構成するデータパケットであって第１のデータストリームによって送信される第１のデータパケットと前記送信データを構成するデータパケットであって前記第１のデータストリームと異なる第２のデータストリームによって送信される第２のデータパケットとを用いて生成された一つの復元用データパケットを受信する受信手段と、
   前記第１のデータパケット及び前記第２のデータパケットを含むグループのなかで損失していないデータパケットと前記一つの復元用データパケットとを用いて、該グループのなかの損失データパケットの復元処理を行う復元手段と
   を有する受信装置。
10. 前記復元手段は、前記データパケットのヘッダ部の拡張領域に書き込まれている、前記データパケットが属する前記データストリームを識別するためのストリーム識別情報と、前記データストリームのなかで前記データパケットを識別するためのパケット識別情報と、前記グループを識別するためのグループ識別情報に基づいて、前記データパケットが属するデータストリームと前記データパケットが属するグループと前記データパケットとを特定する請求項９に記載の受信装置。
11. 前記復元手段は、前記復元用データパケットのヘッダ部の拡張領域に書き込まれている、前記グループの対象となされている各データパケットが属する各データストリームを各々識別するためのストリーム識別情報と、前記データストリームのなかで前記グループの対象となされている各データパケットを各々識別するためのパケット識別情報とに基づいて、前記復元用データパケットに対応したグループに属するデータパケットと前記データパケットが属するデータストリームとを特定する請求項９に記載の受信装置。
12. データストリームを送信する送信装置が実行する送信方法であって、
    送信データを構成するデータパケットであって第１のデータストリームによって送信される第１のデータパケットと、前記送信データを構成するデータパケットであって前記第１のデータストリームと異なる第２のデータストリームによって送信される第２のデータパケットとを用いて、損失データパケットを復元するための復元用データパケットを生成する生成ステップと、
    前記第１のデータパケット及び前記第２のデータパケットの送信に応じて、前記生成ステップによって生成された一つの復元用データパケットを送信する送信ステップと
    を含む送信方法。
13. データストリームを受信する受信装置が実行する受信方法であって、
    送信データを構成するデータパケットであって第１のデータストリームによって送信される第１のデータパケットと前記送信データを構成するデータパケットであって前記第１のデータストリームと異なる第２のデータストリームによって送信される第２のデータパケットとを用いて生成された一つの復元用データパケットを受信する受信ステップと、
    前記第１のデータパケット及び前記第２のデータパケットを含むグループのなかで損失していないデータパケットと前記一つの復元用データパケットとを用いて、該グループのなかの損失データパケットの復元処理を行う復元ステップと
    を含む受信方法。
14. コンピュータを、請求項１〜８の何れか１項に記載の送信装置の各手段として機能させるためのプログラム。
15. コンピュータを、請求項９〜１１の何れか１項に記載の受信装置の各手段として機能させるためのプログラム。

Images