(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された受信装置から、前記ネットワークの輻輳状況を示す輻輳情報を受信する受信手段と、
複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成可能であり、かつ、前記各行及び各列をまたがる第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理を施して、それぞれ第２の誤り訂正パケットを生成可能であり、前記輻輳情報に基づいて、前記データパケットに前記第１の誤り訂正パケットのみを付加して送信する第１のレベルと、前記データパケットに前記第１の誤り訂正パケット及び前記第２の誤り訂正パケットを付加して送信する第２のレベルとを設定可能な生成手段と、
前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットとを、前記設定されているレベルを示すレベル情報とともに前記受信装置へ送信可能な送信手段と
を具備する送信装置。
【請求項２】
ネットワークを介して送信装置と接続された受信装置であって、
複数のデータパケットと、複数の行及び列に構成された前記各データパケットに前記行毎及び列毎にそれぞれ所定の演算処理が施されて生成された第１の誤り訂正パケットと、前記各行及び各列をまたがる第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理が施されてそれぞれ生成された第２の誤り訂正パケットとを前記送信装置から受信可能であり、かつ、前記送信装置において、前記データパケットに前記第１の誤り訂正パケットのみを付加して送信する第１のレベルと、前記データパケットに前記第１の誤り訂正パケット及び前記第２の誤り訂正パケットを付加して送信する第２のレベルとのいずれが設定されているかを示すレベル情報を前記送信装置から受信可能な受信手段と、
前記データパケットの受信前に前記送信装置から受信された所定のパケットの受信状況を基に、前記ネットワークの輻輳状況を示す輻輳情報を生成する生成手段と、
前記生成された輻輳情報を前記送信装置へ送信する送信手段と、
前記各データパケットのうち損失された損失データパケットを特定する特定手段と、
前記特定された損失データパケットを、前記レベル情報により示されるレベルに応じて、前記第１及び第２の誤り訂正パケットのうち少なくとも一方を用いて復元する復元手段と
を具備する受信装置。
【請求項３】
請求項２に記載の受信装置であって、
前記復元手段は、
前記受信された各データパケットを前記各行及び各列に構成する手段と、
前記各行方向、各列方向及び斜め方向における前記損失データパケットの数をそれぞれ検出する手段と、
前記各行方向または各列方向において検出された前記数が１つである場合に、当該各行方向または各列方向における前記損失データパケット以外のデータパケットと前記第１の誤り訂正パケットとに前記所定の演算処理を施して前記損失データパケットを復元する手段と、
前記斜め方向において検出された前記数が１つである場合に、当該斜め方向における前記損失データパケット以外のデータパケットと前記第２の誤り訂正パケットとに前記所定の演算処理を施して前記損失データパケットを復元する手段と
を有する受信装置。
【請求項４】
請求項３に記載の受信装置であって、
前記第１及び第２の誤り訂正パケットを用いて前記損失データパケットを復元する第１のモードと、前記第１の誤り訂正パケットを用いて前記損失データパケットを復元する第２のモードと、前記損失データパケットを復元しない第３のモードのいずれかを選択するユーザの操作を入力する入力手段と、
前記入力に応じて前記第１乃至第３のモードのいずれかを設定する設定手段と
を更に具備する受信装置。
【請求項５】
ネットワークを介して接続された受信装置から、前記ネットワークの輻輳状況を示す輻輳情報を受信する受信手段と、
複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成可能であり、かつ、前記各行及び各列をまたがる第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理を施して、それぞれ第２の誤り訂正パケットを生成可能であり、前記輻輳情報に基づいて、前記データパケットに前記第１の誤り訂正パケットのみを付加して送信する第１のレベルと、前記データパケットに前記第１の誤り訂正パケット及び前記第２の誤り訂正パケットを付加して送信する第２のレベルとを設定可能な生成手段と、
前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットとを、前記設定されているレベルを示すレベル情報とともに前記受信装置へ送信可能な送信手段と
を有する送信装置と、
前記送信された各データパケットと、前記第１及び第２の誤り訂正パケットと、前記レベル情報とを前記送信装置から受信可能な受信手段と、
前記データパケットの受信前に前記送信装置から受信された所定のパケットの受信状況を基に、前記ネットワークの輻輳状況を示す輻輳情報を生成する生成手段と、
前記生成された輻輳情報を前記送信装置へ送信する送信手段と、
前記各データパケットのうち損失された損失データパケットを特定する特定手段と、
前記特定された損失データパケットを、前記レベル情報により示されるレベルに応じて、前記第１及び第２の誤り訂正パケットのうち少なくとも一方を用いて復元する復元手段と
を有する受信装置と
を具備する誤り訂正システム。
【請求項６】
ネットワークを介して接続された受信装置から、前記ネットワークの輻輳状況を示す輻輳情報を受信し、
前記輻輳情報に基づいて、複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成して、前記データパケットに当該第１の誤り訂正パケットを付加して送信する第１のレベルと、前記各行及び各列をまたがる第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理を施して、それぞれ第２の誤り訂正パケットを生成して、前記データパケットに前記第１の誤り訂正パケット及び前記第２の誤り訂正パケットを付加して送信する第２のレベルとのいずれかを設定し、
前記設定されたレベルに基づいて、前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットとを生成し、
前記生成された第１及び第２の誤り訂正パケットを、前記設定されているレベルを示すレベル情報とともに前記受信装置へ送信する
送信方法。
【請求項７】
複数のデータパケットと、複数の行及び列に構成された前記各データパケットに前記行毎及び列毎にそれぞれ所定の演算処理が施されて生成された第１の誤り訂正パケットと、前記各行及び各列をまたがる第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理が施されてそれぞれ生成された第２の誤り訂正パケットとを、ネットワークを介して接続された送信装置から受信するとともに、前記送信装置において、前記データパケットに前記第１の誤り訂正パケットのみを付加して送信する第１のレベルと、前記データパケットに前記第１の誤り訂正パケット及び前記第２の誤り訂正パケットを付加して送信する第２のレベルとのいずれが設定されているかを示すレベル情報を前記送信装置から受信し、
前記データパケットの受信前に前記送信装置から受信された所定のパケットの受信状況を基に、前記ネットワークの輻輳状況を示す輻輳情報を生成し、
前記生成された輻輳情報を前記送信装置へ送信し、
前記各データパケットのうち損失された損失データパケットを特定し、
前記特定された損失データパケットを、前記レベル情報により示されるレベルに応じて、前記第１及び第２の誤り訂正パケットのうち少なくとも一方を用いて復元する
誤り訂正方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データパケットに誤り訂正パケットを付加して送信する送信装置、当該データパケット及び誤り訂正パケットを受信する受信装置、当該送信装置を用いた送受信システム、上記送信装置における送信方法、上記受信装置における誤り訂正方法に関する。
【背景技術】
【０００２】
近年、放送電波ではなくＩＰ（Internet Protocol）を利用してコンテンツを提供するテレビ放送サービス（ＩＰＴＶ）が注目されている。このＩＰＴＶでは、受信装置がダウンロードするタイプの放送コンテンツのほか、受信装置へストリーミングにより配信するタイプの放送コンテンツが存在する。ストリーミングにおいては、リアルタイム性を求められるため、ＩＰＴＶでは、信頼性を重視したＴＣＰ（Transmission Control Protocol）ではなく、リアルタイム性を重視したＲＴＰ（Real-time Transport Protocol）が用いられ、またマルチキャスト伝送に対応するためにＵＤＰ（User Datagram Protocol）が用いられている。
【０００３】
ＲＴＰを用いると、ＴＣＰのように、コンテンツデータのストリームを構成するパケット（以下、メディアパケットと称する）のうち、受信できなかったメディアパケットに対してＡＣＫ（ACKnowledgement）を返して再送するということはできなくなる。したがって、受信装置は、メディアパケットを損失してしまうと、その部分を隠蔽したままデータのデコードを行うため、映像や音声が乱れてしまう。特に近年では、ネットワークの普及率が非常に高くなっており、通信が混雑してメディアパケットを損失してしまうことが大いに想定される。そこで、送信サーバ側でメディアパケットを送信する際に、ある一定数のメディアパケットを保護するＦＥＣ（Forward Error Correction）パケットを冗長パケットとしてメディアパケットと共に送信し、受信装置側で当該ＦＥＣパケットを用いて損失したメディアパケットを復元する誤り訂正技術が存在する。
【０００４】
このＦＥＣパケットは、複数のメディアパケットを例えばＸＯＲ（eXclusive OR；排他的論理和）演算することで得られる。具体的には、例えば、複数の隣接する（シーケンス番号が連続する）メディアパケットを全てＸＯＲ演算してＦＥＣパケットを生成する手法がある。すなわち、この手法は、１次元方向（線形）におけるメディアパケットのＦＥＣ処理と言える。しかし、この１次元の処理では、ＸＯＲ演算の対象となった複数のメディアパケットのうち、２つ以上のメディアパケットにバースト的に誤りが発生した場合には復元することができなくなる。
【０００５】
そこで、Pro-MPEG Forumは、Pro-MPEG COP(Code of Practice) #3 release 2において、複数のメディアパケットをＤ行及びＬ列に配置して２次元で捉え、行方向（横方向）及び列方向（横方向）の各メディアパケットについてそれぞれＸＯＲ演算することで行数（Ｄ）＋列数（Ｌ）分のＦＥＣパケットを生成する手法が提案されている。これにより、例えば１つの行（列）に属するメディアパケットにバースト誤りが生じても、列（行）方向のＦＥＣパケットにより復元することが可能となる。下記特許文献１にも、このPro-MPEG COP #3 release 2の手法が記載されている。  
【特許文献１】特表２００７−５０９５５７号公報（図１等）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１に記載の２次元処理においては、例えば行方向及び列方向において、矩形の各頂点を形成するような４つの損失パケットが発生した場合には、行方向及び列方向でそれぞれ２つの損失パケットが発生しているため、どのＦＥＣパケットを用いていもそれらの損失パケットを復元することはできない。すなわち、少なくとも４つのメディアパケットの損失によりそれらのメディアパケット全てを復元できなくなる場合がある。
【０００７】
以上のような事情に鑑み、本発明の目的は、損失パケットの復元率を向上させることが可能な送信装置、受信装置、誤り訂正システム、送信方法及び誤り訂正方法を提供することにある。
【課題を解決するための手段】
【０００８】
上述の課題を解決するため、本発明の主たる観点に係る送信装置は、複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成し、かつ、前記各行及び各列をまたがる斜め方向に存在する前記各データパケットに前記所定の演算処理を施して、少なくとも１つの第２の誤り訂正パケットを生成する生成手段と、前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットとを送信する送信手段とを具備する。
【０００９】
ここでデータパケットとは、例えば映像コンテンツ、音声コンテンツ、テキストコンテンツ、Ｗｅｂコンテンツ等のマルチメディアデータを構成するメディアパケットである。第１及び第２の誤り訂正パケットとは例えばＦＥＣパケットであり、所定の演算処理とは、例えばＸＯＲ演算処理であるが、リードソロモン符号やハミング符号等の他の関数を適用しても構わない。この送信装置は、例えば上記各種コンテンツを配信するネットワーク上のサーバ装置として機能する。
【００１０】
この構成により、第１の誤り訂正パケットに加えて斜め方向の第２の誤り訂正パケットを付加することで、誤り訂正パケットのデータ量の増加を極力抑えながらも、受信装置において損失データパケットを復元できるパターン数を飛躍的に増加させることができる。
【００１１】
上記送信装置において、前記生成手段は、前記各データパケットのうち、第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理を施して、それぞれ前記第２の誤り訂正パケットを生成するようにしてもよい。
【００１２】
これにより、受信装置において損失データパケットを復元できるパターン数を更に増加させることができる。
【００１３】
上記送信装置において、前記各データパケットは、Ｄ行及びＬ列に構成されており、前記生成手段は、前記各データパケットを、前記斜め方向に前記Ｄ個ずつ抽出して前記Ｌ個のグループを形成し、当該Ｌ個のグループ毎に前記所定の演算処理を施して、前記Ｌ個の前記第２の誤り訂正パケットを生成するようにしても構わない。
【００１４】
これにより、Ｄ行及びＬ列に構成される全てのデータパケットを用いて第２の誤り訂正パケットを生成するため、受信装置において損失データパケットを復元できるパターン数を更に格段に増加させることができる。
【００１５】
上記送信装置は、ネットワークを介して接続された受信装置から、前記ネットワークの輻輳状況を示す輻輳情報を受信する受信手段を更に具備し、前記生成手段は、前記輻輳情報に基づいて、前記第２の誤り訂正パケットの生成を規制する手段を有していてもよい。
【００１６】
これにより、ネットワークの輻輳状況に応じて第２の誤り訂正パケットの生成を規制して、当該生成により生じる送信装置への負荷を軽減することができる。
【００１７】
本発明の他の観点に係る受信装置は、ネットワークを介して送信装置と接続された受信装置であって、複数のデータパケットと、複数の行及び列に構成された前記各データパケットに前記行毎及び列毎にそれぞれ所定の演算処理が施されて生成された第１の誤り訂正パケットと、前記各行及び各列をまたがる斜め方向に存在する前記各データパケットに前記所定の演算処理が施されて生成された少なくとも１つの第２の誤り訂正パケットとを前記送信装置から受信する受信手段と、前記各データパケットのうち損失された損失データパケットを特定する特定手段と、前記特定された損失データパケットを、前記第１及び第２の誤り訂正パケットを用いて復元する復元手段とを具備する。
【００１８】
ここで受信装置としては、例えばテレビジョン装置、ＰＣ（Personal Computer）、ＨＤＤ（Hard Disk Drive）／ＤＶＤ（Digital Versatile Disk）／ＢＤ（Blu-ray Disc）レコーダ等の記録再生装置、ゲーム機器、携帯電話機、その他のＡＶ（Audio / Video）機器等のあらゆる電子機器が挙げられる。この構成により、データパケットの損失が発生した場合でも、第１の誤り訂正パケットのみならず第２の誤り訂正パケットも用いることで、損失データパケットを高い確率で復元することができる。
【００１９】
上記受信装置において、前記復元手段は、前記受信された各データパケットを前記各行及び各列に構成する手段と、前記各行方向、各列方向及び斜め方向における前記損失データパケットの数をそれぞれ検出する手段と、前記各行方向または各列方向において検出された前記数が１つである場合に、当該各行方向または各列方向における前記損失データパケット以外のデータパケットと前記第１の誤り訂正パケットとに前記所定の演算処理を施して前記損失データパケットを復元する手段と、前記斜め方向において検出された前記数が１つである場合に、当該斜め方向における前記損失データパケット以外のデータパケットと前記第２の誤り訂正パケットとに前記所定の演算処理を施して前記損失データパケットを復元する手段とを有していてもよい。
【００２０】
例えば、損失データパケットが、上記行及び列において矩形の各頂点を形成するように４つ発生したような場合、上記第１の誤り訂正パケットのみでは当該損失データパケットを復元することはできないが、そのうちの１つの損失データパケットが上記斜め方向に存在している場合には、上記構成により、当該１つの損失データパケットを上記第２の誤り訂正パケットにより復元し、残りの損失データパケットは上記第１の誤り訂正パケットにより順次復元することで、全ての損失データパケットを復元することが可能となる。
【００２１】
上記受信装置において前記受信された第２の誤り訂正パケットは、前記送信装置において、前記各行及び列に構成された各データパケットのうち、第１の斜め方向に存在する複数の第１のデータパケットと、前記第１の斜め方向に直交する第２の斜め方向に存在する複数の第２のデータパケットとにそれぞれ前記所定の演算処理が施されてそれぞれ生成されたものであってもよい。
【００２２】
これにより、受信装置は、更に多くのパターンの損失データパケットを復元することが可能となる。
【００２３】
また前記受信装置おいて前記受信された第２の誤り訂正パケットは、前記送信装置において、Ｄ行及びＬ列に構成された各データパケットが、前記斜め方向に前記Ｄ個ずつ抽出されて前記Ｌ個のグループに形成され当該Ｌ個のグループ毎に前記所定の演算処理が施されることで、前記Ｌ個生成されたものであっても構わない。
【００２４】
これにより、格段に多くのパターンの損失データパケットを復元することができる。
【００２５】
上記受信装置において、前記受信手段は、前記データパケットの受信前に前記送信装置から所定のパケットを受信し、当該受信装置は、前記受信された所定のパケットの受信状況を基に、前記ネットワークの輻輳状況を示す輻輳情報を生成する生成手段と、前記生成された輻輳情報を前記送信装置へ送信する送信手段とを更に具備し、前記復元手段は、前記送信装置が、前記輻輳情報に基づいて前記第２の誤り訂正パケットの生成及び送信を規制した場合に、前記斜め方向における前記損失データパケットの数の検出を規制する手段を有していてもよい。
【００２６】
これにより、上記輻輳情報を送信することで、ネットワークの輻輳度が低い場合には、上記第２の誤り訂正パケットの生成に係る送信装置の負荷を軽減させることができ、それとともに、第２の誤り訂正パケットを用いて上記損失データパケットを復元する際の受信装置の負荷を軽減させることができる。また、それと同時に、送信パケット量を極力削減することもできる。上記輻輳情報は、例えば、上記所定のパケットの損失率やパケットの遅延やジッタ等を計測することで生成される。所定のパケットとは、例えばＲＴＣＰ（RTP Control Protocol）におけるＳＲ（Sender Report）パケットであり、この場合上記輻輳情報は、ＲＲ（Receiver Report）パケットとして送信される。
【００２７】
上記受信装置は、前記第１及び第２の誤り訂正パケットを用いて前記損失データパケットを復元する第１のモードと、前記第１の誤り訂正パケットを用いて前記損失データパケットを復元する第２のモードと、前記損失データパケットを復元しない第３のモードのいずれかを選択するユーザの操作を入力する入力手段と、前記入力に応じて前記第１乃至第３のモードのいずれかを設定する設定手段とを更に具備していても構わない。
【００２８】
これにより、上記第１乃至第３のモードのいずれかをユーザに選択させて設定することで、必要に応じて上記復元手段による処理の負荷を軽減させることができる。また、再生データの質や再生の即時性等、ユーザの要求に応じて損失データパケットの復元処理を可変することで、ユーザの利便性を向上させることができる。
【００２９】
本発明のまた別の観点に係る誤り訂正システムは、送信装置と受信装置とからなる誤り訂正システムであり、前記送信装置は、複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成し、かつ、前記各行及び各列をまたがる斜め方向に存在する前記各データパケットに前記所定の演算処理を施して、少なくとも１つの第２の誤り訂正パケットを生成する生成手段と、前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットを送信する送信手段とを有し、前記受信装置は、前記送信された各データパケットと、前記第１及び第２の誤り訂正パケットとを前記送信装置から受信する受信手段と、前記各データパケットのうち損失された損失データパケットを特定する特定手段と、前記特定された損失データパケットを、前記第１及び第２の誤り訂正パケットを用いて復元する復元手段とを有する。
【００３０】
本発明のまた別の観点に係る送信方法は、複数の行及び列に構成された複数のデータパケットに、前記行毎及び列毎にそれぞれ所定の演算処理を施して第１の誤り訂正パケットを生成し、前記各行及び各列をまたがる斜め方向に存在する前記各データパケットに前記所定の演算処理を施して、少なくとも１つの第２の誤り訂正パケットを生成し、前記各データパケットと、前記生成された第１及び第２の誤り訂正パケットとを送信するものである。
【００３１】
本発明のまた別の観点に係る誤り訂正方法は、複数のデータパケットと、複数の行及び列に構成された前記各データパケットに前記行毎及び列毎にそれぞれ所定の演算処理が施されて生成された第１の誤り訂正パケットと、前記各行及び各列をまたがる斜め方向に存在する前記各データパケットに前記所定の演算処理が施されて生成された少なくとも１つの第２の誤り訂正パケットとを、ネットワークを介して接続された送信装置から受信し、前記各データパケットのうち損失された損失データパケットを特定し、前記特定された損失データパケットを、前記第１及び第２の誤り訂正パケットを用いて復元するものである。
【発明の効果】
【００３２】
以上のように、本発明によれば、損失パケットの復元率を向上させることができる。
【発明を実施するための最良の形態】
【００３３】
以下、本発明の実施の形態を図面に基づき説明する。
【００３４】
（第１実施形態）  
図１は、本発明の第１の実施形態に係る誤り訂正システムの構成を示した図である。  
同図に示すように、この誤り訂正システムは、送信装置としてのサーバ１０と、受信装置としてのテレビジョン装置（以下、ＴＶと称する）２０とから構成され、両者は例えばインターネット、専用回線網、ＬＡＮ（Local Area Network）等のネットワーク３０に接続されている。
【００３５】
サーバ１０は、ビデオＴＳ（Transport Stream）エンコーダ１１、オーディオＴＳエンコーダ１２、ＴＳ−ＭＵＸ（Multiplexer）１３、ＲＴＰ処理部１４、ＦＥＣ処理部１５、ＵＤＰ処理部１６及びネットワークインタフェース１７を有する。
【００３６】
ビデオＴＳエンコーダ１１は、コンテンツを構成する映像信号を、例えばMPEG(Moving Picture Expert Group)-2等の形式でビデオＴＳとして圧縮符号化する。オーディオＴＳエンコーダ１２は、コンテンツを構成する音声信号を、例えばMPEG-2等の形式でオーディオＴＳとして圧縮符号化する。ＴＳ−ＭＵＸ１３は、上記圧縮符号化されたビデオＴＳとオーディオＴＳとを多重化する。
【００３７】
ＲＴＰ処理部１４は、ＲＴＰに基づいて、上記多重化されたＴＳに、ＲＴＰヘッダを付加してＲＴＰパケット（以下、メディアパケットともいう）を生成する。ＦＥＣ処理部１５は、上記生成されたＲＴＰパケットを用いて、誤り訂正パケットとしてのＦＥＣパケットを生成する。ＵＤＰ処理部１６は、ＵＤＰに基づいて、上記ＲＴＰパケットとＦＥＣパケットとにＵＤＰヘッダを付加してそれぞれＵＤＰパケット化する。
【００３８】
ネットワークインタフェース１７は、上記ＲＴＰパケット及びＦＥＣパケットとしてのＵＤＰパケットを、ネットワーク３０を介してＴＶ２０へ送信する。
【００３９】
ＴＶ２０は、ネットワークインタフェース２１、ＵＤＰ処理部２２、ＦＥＣ処理部２３、ＲＴＰ処理部２４、ＴＳ−ＤＥＭＵＸ２５、ビデオＴＳデコーダ２６、オーディオＴＳデコーダ２７を有し、またディスプレイ２８及びスピーカ２９と接続されている。
【００４０】
ネットワークインタフェース２１は、サーバ１０から送信された上記ＵＤＰパケットを、ネットワーク３０を介して受信する。
【００４１】
ＵＤＰ処理部２２は、ＵＤＰに基づいて、上記受信されたＵＤＰパケットのＵＤＰヘッダを解析して、ＦＥＣパケットとＲＴＰパケットとを抽出する。ＦＥＣ処理部２３は、ＲＴＰパケットのＲＴＰヘッダに記載されているシーケンス番号を基に、ネットワーク３０上で損失されたＲＴＰパケットを特定し、当該損失されたＲＴＰパケットを上記ＦＥＣパケットを用いて復元する。ＲＴＰ処理部２４は、上記受信及び復元されたＲＴＰパケットのＲＴＰヘッダを解析し、ＲＴＰヘッダに記載されたタイムスタンプやシーケンス番号により、コンテンツの再生のタイミングを調整する。
【００４２】
ＴＳ−ＤＥＭＵＸ２５は、上記ＲＴＰパケットをビデオＴＳとオーディオＴＳとに分離し、ビデオＴＳをビデオＴＳデコーダ２６へ、オーディオＴＳをオーディオＴＳデコーダ２７へ出力する。
【００４３】
ビデオＴＳデコーダ２６は、ＴＳ−ＤＥＭＵＸ２５から入力されたビデオＴＳを、例えばMPEG-2等の圧縮符号化形式に従ってデコードし、ディスプレイ２８へ出力して表示させる。オーディオＴＳデコーダ２７は、ＴＳ−ＤＥＭＵＸ２５から入力されたオーディオＴＳを、例えばMPEG-2等の圧縮符号化形式に従ってデコードし、スピーカ２９へ出力して再生させる。
【００４４】
なお、図示しないが、サーバ１０及びＴＶ２０は、上記各部以外にも、例えばＣＰＵ（Central Processing Unit）等の制御部や、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等の内部記憶装置、操作ボタン等の入力装置を備えている。また、ダウンロード型のサービスを使用する場合には、ＴＶ２０は、ＨＤＤ等の外部記憶装置を備える。
【００４５】
次に、以上のように構成された誤り訂正システムの動作について説明する。
【００４６】
まず、サーバ１０の動作について説明する。図２は、サーバ１０の動作の流れを示したフローチャートである。  
同図に示すように、まず、サーバ１０は、ネットワークインタフェース１７により、ＴＶ２０から、動画像コンテンツ等のコンテンツのストリーミング要求信号を、ネットワーク３０を介して受信する（ステップ３１）。サーバ１０のＣＰＵは、当該要求に応じて、コンテンツを構成するフレームのフレーム番号ｎを１に設定し（ステップ３２）、ビデオＴＳエンコーダ１１及びオーディオＴＳエンコーダ１２により、そのフレームに対応する映像信号及び音声信号をそれぞれ圧縮符号化し、ＴＳ−ＭＵＸ１３により両者を多重化する（ステップ３３）。
【００４７】
続いて、サーバ１０のＣＰＵは、上記圧縮符号化及び多重化されたフレーム番号１の映像信号及び音声信号を基に、ＲＴＰ処理部１４によりＲＴＰパケット（メディアパケット）を生成する（ステップ３４）。そしてＣＰＵは、当該メディアパケットを基に、ＦＥＣ処理部１５によりＦＥＣパケットを生成する（ステップ３５）。さらに、ＣＰＵは、当該メディアパケット及びＦＥＣパケットをＵＤＰパケット化し（ステップ３６）、ネットワークインタフェース１７によりネットワーク３０を介してＴＶ２０へ送信する（ステップ３７）。当該送信が完了すると、フレーム番号ｎをインクリメントしてｎ＝ｎ＋１に設定する（ステップ３８）。ＣＰＵは、以上の処理を、コンテンツを構成する全フレーム数ＮがＮ<ｎとなるまで繰り返す（ステップ３９）。
【００４８】
図３は、上記メディアパケットとＦＥＣパケットとの関係を示した図である。  
同図に示すように、メディアパケット４０は、ＩＰヘッダ４１、ＵＤＰヘッダ４２、ＲＴＰヘッダ４３及びＲＴＰペイロード４４から構成される。具体的には、メディアパケット４０は、ＲＴＰ処理部１４が、圧縮符号化された映像信号及び音声信号の実データであるＲＴＰペイロード４４にＲＴＰヘッダ４３を付加し、その下位層であるＵＤＰ処理部１６がＵＤＰヘッダ４２を付加し、その下位層であるネットワークインタフェース１７がＩＰヘッダ４１を付加することでネットワーク３０へ送信可能な状態となる。
【００４９】
また、ＦＥＣパケット５０は、ＩＰヘッダ５１、ＵＤＰヘッダ５２、ＲＴＰヘッダ５３、ＦＥＣヘッダ５４及びＦＥＣペイロード５５から構成される。具体的には、ＦＥＣ処理部１５は、複数のメディアパケット４０のＲＴＰヘッダ４３をＸＯＲ演算することでＦＥＣヘッダ５４を生成し、各メディアパケット４０の各ＲＴＰペイロード４４をＸＯＲ演算することでＦＥＣペイロード５５を生成する。このＦＥＣヘッダ５４及びＦＥＣペイロード５５にＵＤＰヘッダ５２及びＩＰヘッダ５１が付加されることでネットワーク３０へ送信可能な状態となる。
【００５０】
なお、図示しないが、ＦＥＣパケット５０のＩＰヘッダ５１には、送信元であるサーバ１０と送信先であるＴＶ２０の各ＩＰアドレスが含まれ、ＵＤＰヘッダ５２には、送信元であるサーバ１０と送信先であるＴＶ２０の各ＵＤＰポート番号が含まれ、ＦＥＣヘッダ５４には、メディアパケット４０の数（行数及び列数）やＦＥＣ方式（後述する斜め方向のＦＥＣパケットを付加する方式）が記述される。これらの情報が、ＴＶ２０において損失したメディアパケット４０を復元してデコードする際に用いられる。
【００５１】
図４は、サーバ１０のＦＥＣ処理部１５がＦＥＣパケット５０を生成する様子を示した図である。  
同図に示すように、ＦＥＣ処理部１５は、メディアパケット４０をＤ行×Ｌ列に配置する。同図においては、Ｄ＝４、Ｌ＝４とされ、ｐ０１〜ｐ１６までの計１６個のメディアパケットが配置されているが、この行数及び列数に限られるものではない。
【００５２】
ＦＥＣ処理部１５は、このＤ行×Ｌ列のメディアパケット４０を、行毎及び列毎にＸＯＲ演算することにより、複数のＦＥＣパケット５０を生成する。同図においては、例えば１行目に属するメディアパケットｐ０１、ｐ０２、ｐ０３及びｐ０４を順にＸＯＲ演算することで、行方向（row）のＦＥＣパケットｒ１が生成され、２行目に属するメディアパケットｐ０２、ｐ０６、ｐ１０及びｐ１４を順にＸＯＲ演算することで、列方向（column）のＦＥＣパケットｃ１が生成される。
【００５３】
更に、本実施形態においては、ＦＥＣ処理部１５は、行方向及び列方向のＦＥＣパケット５０に加えて、斜め方向のＦＥＣパケット５０も生成する。すなわち、ＦＥＣ処理部１５は、最上段及び最右列のＦＥＣパケットｐ０４から、左斜め下方向（同図矢印Ａ１方向）に存在するメディアパケットｐ０７、ｐ１０及びｐ１３を順にＸＯＲ演算することで、斜め方向（diagonal）のＦＥＣパケットｄ１を生成する。
【００５４】
なお、同図においては説明の便宜上、Ｄ＝４、Ｌ＝４としているが、ＩＰＴＶにおいては、通常、行方向及び列方向におけるメディアパケット４０を１０個単位で保護する。例えば、従来のPro-MPEG COP #3 release 2（以下、Pro-MPEG 2D FEC）では、１０行×１０列＝１００個のメディアパケット４０について、行方向のＦＥＣパケット５０が１０個、列方向のＦＥＣパケット５０が１０個生成される。したがって、本実施形態において、Pro-MPEG 2D FECを拡張して上記斜め方向のＦＥＣパケット５０を追加する場合には、斜め方向の１０個のメディアパケット４０をＸＯＲ演算することで１個のＦＥＣパケット５０が生成される。これら１００個のメディアパケット４０と、１０個（行）＋１０個（列）＋１個（斜め）＝２１個のＦＥＣパケット５０とが合わされた計１２１個のパケットが１単位として送信され、ＴＶ２０に受信される。
【００５５】
次に、ＴＶ２０の動作について説明する。図５は、ＴＶ２０の動作の流れを示したフローチャートである。  
同図に示すように、まず、ＴＶ２０のＣＰＵは、例えば操作入力部等から、コンテンツの視聴を要求する操作が入力された場合、ネットワークインタフェース２１により、コンテンツのストリーミング要求信号を送信し（ステップ６１）、この要求に応じてサーバ１０から送信されたメディアパケット４０及びＦＥＣパケット５０をストリーミング受信する（ステップ６２）。続いて、ＣＰＵは、ＵＤＰ処理部２２により受信したパケットのＵＤＰヘッダを解析してメディアパケット４０とＦＥＣパケット５０とに分類し、ＦＥＣ処理部２３により、メディアパケット４０のＲＴＰヘッダ４３に記載されたシーケンス番号を基に、損失したメディアパケット４０を検索する（ステップ６３）。
【００５６】
このとき、ＦＥＣ処理部２３は、例えば受信されたＦＥＣパケット５０のＦＥＣヘッダ５４を参照することで、ＦＥＣパケット５０により保護される各メディアパケットの行数及び列数の各パラメータ（Ｄ×Ｌ）を取得し、当該パラメータに従い、メディアパケット４０を行及び列に構築する。本実施形態においては、このパラメータは例えば１０行×１０列とする。
【００５７】
そして、ＦＥＣ処理部２３は、メディアパケット４０の全損失数ｅｎ、各行における損失数ｅｒｏｗ［ｉ］、各列における損失数ｅｃｏｌ［ｉ］、及び斜め方向（図４のＡ１方向）における損失数ｅｄｉａｇの値をそれぞれ求める。ｅｒｏｗ［ｉ］及びｅｃｏｌ［ｉ］の［ｉ］には、１〜１０行目及び１〜１０列目まで、順に０，１，・・・９が代入される。
【００５８】
ｅｎの値が０である場合（ステップ６４のＹｅｓ）には、メディアパケット４０の損失は無いということであるので、ＦＥＣ処理部２３は、受信したメディアパケット４０をＴＳ−ＤＥＭＵＸにより映像信号及び音声信号に分離し、ビデオＴＳデコーダ２６及びオーディオＴＳデコーダ２７によりデコードして、ディスプレイ２８及びスピーカ２９から再生させる（ステップ６８）。
【００５９】
ｅｎの値が０でない場合（ステップ６４のＮｏ）には、ＦＥＣ処理部２３は、上記ｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇの各値が２以上であるか否かを確認する（ステップ６５）。各値が全て２以上である場合には、ＦＥＣパケット５０によるメディアパケット４０の復元は不可能であるため、ＦＥＣ処理部２３は、損失したメディアパケット４０は隠蔽したままデコード処理を行わせる（ステップ６８）。
【００６０】
ｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇの各値が１以下の場合（ステップ６５のＮＯ）には、ＦＥＣ処理部２３は、各値が１である箇所から、ＦＥＣパケット５０によるメディアパケット４０の復元処理（以下、ＦＥＣ処理ともいう）を実行する（ステップ６６）。以下、この処理を具体的に説明する。
【００６１】
図６は、メディアパケット４０が損失した様子を示した図であり、図７は、その損失したメディアパケット４０を復元する様子を示した図である。なお、これらの図では、メディアパケット４０は、説明の便宜上、上記図４の場合と同様、４行×４列に構築される場合を示しているが、図５のフローチャートでは、１０行×１０列に構築されるものとして説明する。
【００６２】
図６に示すように、例えば、メディアパケットｐ１０、ｐ１１、ｐ１４及びｐ１５の４つのメディアパケット４０が損失した場合を想定する。この場合、ｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇのうち、値が１となるのはｅｄｉａｇであるため、ＦＥＣ処理部２３はまず、このｅｄｉａｇ＝１とカウントされたメディアパケットｐ１０を復元する。具体的には、図７（ａ）に示すように、メディアパケットｐ０４、ｐ０７、ｐ１３及び斜め方向のＦＥＣパケットｄ１を順にＸＯＲ演算することにより、メディアパケットｐ１０を復元する。  
次に、ＦＥＣ処理部２３は、ｅｃｏｌ［１］＝１としてカウントされたメディアパケットｐ１４を、図７（ｂ）に示すように、メディアパケットｐ０２、ｐ０６、ｐ１０及び列方向のＦＥＣパケットｃ２をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｒｏｗ［２］＝１としてカウントされたメディアパケットｐ１１を、図７（ｃ）に示すように、メディアパケットｐ０９、ｐ１０、ｐ１２及び行方向のＦＥＣパケットｒ３をＸＯＲ演算することで復元する。  
そして、ＦＥＣ処理部２３は、ｅｒｏｗ［３］＝１としてカウントされたメディアパケットｐ１５を、図７（ｄ）に示すように、メディアパケットｐ１３、ｐ１４、ｐ１６及び行方向のＦＥＣパケットｒ４をＸＯＲ演算することで復元する。  
これにより、損失した４つのメディアパケット４０が全て復元される。
【００６３】
このように各メディアパケット４０を１つずつ復元する際、ＦＥＣ処理部２３は、上記ＦＥＣ処理により復元されたメディアパケット４０が属する行、列及び斜め方向の損失数ｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇの各値をデクリメントし、それに応じてｅｎの値もデクリメントする（ステップ６７）。この処理をｅｎの値が０になるまで繰り返すことで、損失した全てのメディアパケット４０を復元し、復元後のメディアパケット４０をデコードして再生させる（ステップ６８）。
【００６４】
以上のように、本実施形態によれば、サーバ１０からＴＶ２０へメディアパケット４０を送信する際、行方向及び列方向のみならず斜め方向のＦＥＣパケット５０も付加して送信するため、ＴＶ２０において復元できるメディアパケット４０のパターンの数を格段に増加させることができる。
【００６５】
（第２実施形態）  
次に、本発明の第２の実施形態について説明する。なお、本実施形態において、上述の第１の実施形態と同一の構成及び機能を有する箇所については同一の符号を付し、説明を省略または簡略化する。また、本実施形態においても、第１の実施形態と同様、サーバ１０とＴＶ２０とで誤り訂正システム１００が構成されており、以下の説明では、サーバ１０及びＴＶ２０の動作を中心に説明する。
【００６６】
図８は、本実施形態において、サーバ１０のＦＥＣ処理部１５がＦＥＣパケット５０を生成する様子を示した図である。なお、本実施形態においては、説明の便宜上、メディアパケット４０を、５行×５列に構成した場合を示すが、上記第１実施形態と同様、実際には１０行×１０列のメディアパケット４０を１つの単位としてＦＥＣパケット５０を生成するものとする。もちろん、これらの行数及び列数に限られるものではない。
【００６７】
同図に示すように、サーバ１０のＦＥＣ処理部１５は、上記第１実施形態と同様の処理により、行方向の各ＦＥＣパケットｒ１〜ｒ５、列方向の各ＦＥＣパケットｃ１〜ｃ５及び左斜め下方向（矢印Ａ１方向）の１つのＦＥＣパケットｄ１を生成する。更に、ＦＥＣ処理部１５は、それらに加えて、上記矢印Ａ１方向に直交する右斜め下方向（矢印Ａ２方向）に存在するメディアパケットｐ０１、ｐ０７、ｐ１３、ｐ１９及びｐ２５の５つのメディアパケット４０を順にＸＯＲ演算することにより、新たに１つのＦＥＣパケットｄ２を生成する。
【００６８】
サーバ１０は、１０行×１０列の１００個のメディアパケット４０に対して、行方向及び列方向の各１０個のＦＥＣパケット５０と、上記２つの斜め方向のＦＥＣパケット５０とを含む２２個のＦＥＣパケット５０を加えてＴＶ２０へ送信する。
【００６９】
図９は、サーバ１０から送信されたメディアパケット４０が、ＴＶ２０において損失した様子を示した図であり、図１０は、その損失したメディアパケット４０をＴＶ２０が復元する様子を示した図である。  
図９に示すように、例えば、メディアパケットｐ０３、ｐ０４、ｐ１３、ｐ１４、ｐ１７、ｐ１８、ｐ２２及びｐ２３の８つのメディアパケット４０が損失した場合を想定する。この場合、ＴＶ２０のＦＥＣ処理部２３は、第１実施形態と同様、行方向、列方向及び斜め方向におけるメディアパケットの損失数ｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇをそれぞれ求める。本実施形態においては、斜め方向はＡ１とＡ２の２つ（以下、斜めＡ１方向及び斜めＡ２方向という）が存在するため、各斜め方向の損失数をそれぞれｅｄｉａｇ［１］、ｅｄｉａｇ［２］とする。
【００７０】
これらｅｒｏｗ［ｉ］、ｅｃｏｌ［ｉ］及びｅｄｉａｇのうち、値が１となるのはｅｄｉａｇ［２］であるため、ＦＥＣ処理部２３はまず、このｅｄｉａｇ［２］＝１とカウントされたメディアパケットｐ１３を復元する。具体的には、図１０（ａ）に示すように、メディアパケットｐ０１、ｐ０７、ｐ１９、ｐ２５及び斜めＡ２方向のＦＥＣパケットｄ２を順にＸＯＲ演算することにより、メディアパケットｐ１３を復元する。  
次に、ＦＥＣ処理部２３は、ｅｄｉａｇ［１］＝１としてカウントされたメディアパケットｐ１７を、図１０（ｂ）に示すように、メディアパケットｐ０５、ｐ０９、ｐ１３、ｐ２１及び斜めＡ１方向のＦＥＣパケットｄ１をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｒｏｗ［２］＝１としてカウントされたメディアパケットｐ１４を、図１０（ｃ）に示すように、メディアパケットｐ１１、ｐ１２、ｐ１３、ｐ１５及び行方向のＦＥＣパケットｒ３をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｃｏｌ［３］＝１としてカウントされたメディアパケットｐ０４を、図１０（ｄ）に示すように、メディアパケットｐ０９、ｐ１４、ｐ１９、ｐ２４及び列方向のＦＥＣパケットｃ４をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｒｏｗ［０］＝１としてカウントされたメディアパケットｐ０３を、図１０（ｅ）に示すように、メディアパケットｐ０１、ｐ０２、ｐ０４、ｐ０５及び行方向のＦＥＣパケットｒ１をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｒｏｗ［３］＝１としてカウントされたメディアパケットｐ２２を、図１０（ｆ）に示すように、メディアパケットｐ１６、ｐ１７、ｐ１９、ｐ２０及び行方向のＦＥＣパケットｒ４をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｃｏｌ［１］＝１としてカウントされたメディアパケットｐ２２を、図１０（ｇ）に示すように、メディアパケットｐ０２、ｐ０７、ｐ１２、ｐ１７及び列方向のＦＥＣパケットｃ２をＸＯＲ演算することで復元する。  
そして、ＦＥＣ処理部２３は、ｅｃｏｌ［２］＝１としてカウントされたメディアパケットｐ２３を、図１０（ｈ）に示すように、メディアパケットｐ０３、ｐ０８、ｐ１３、ｐ１８及び列方向のＦＥＣパケットｃ３をＸＯＲ演算することで復元する。
【００７１】
以上の処理により、第１の実施形態における行方向、列方向及び斜めＡ１方向のＦＥＣパケットｄ１のみでは復元できなかった８つのメディアパケット４０を全て復元することが可能となる。すなわち、本実施形態によれば、第１実施形態に比べて、損失されたメディアパケット４０の復元率を更に向上させることができる。
【００７２】
ここで、メディアパケット４０を復元不可となるパターン数について、以上説明した第１及び第２実施形態と、従来のPro-MPEG 2D FECとを比較して考察する。
【００７３】
上述したように、従来のPro-MPEG 2D FEC（以下、従来技術）においては、メディアパケット４０及びＦＥＣパケット５０を合わせた送信パケットの総数は１２０個であるのに対し、上記第１実施形態により斜めＡ１方向のＦＥＣパケットｄ１を１つ追加した場合には、送信パケットの総数は１２１個であり、本実施形態により更に斜めＡ２方向のＦＥＣパケットｄ２を１つ追加した倍には、送信パケットの総数は１２２個であり、いずれも従来技術に比べて送受信パケット量の増加はわずか約１％となる。
【００７４】
また、従来技術、第１実施形態及び本実施形態における各ＦＥＣ処理において、損失したメディアパケット４０を復元できなくなるパターンは、理論式で表すことができる。
【００７５】
従来技術では、少なくとも４つのメディアパケット４０が、矩形の各頂点となるように各行及び各列で２つずつ損失した場合に復元不可となる。したがって、メディアパケット４０の行数及び列数をｘ行×ｘ列とすると、従来技術において、４つのメディアパケット４０の損失により復元不可となるパターン数は、以下の理論式で表される。  
ｘＣ２×ｘＣ２・・・（１）
【００７６】
一方、第１実施形態における復元不可のパターン数は、上記従来技術におけるパターン数から、斜め方向におけるＦＥＣパケット５０で復元可能となるパターンを除く必要がある。斜めＡ１方向におけるＦＥＣパケットｄ１で復元できるパターンは、まず斜めＡ１方向のＦＥＣパケットｄ１で保護された１つのメディアパケット４０に注目し、そのメディアパケット４０と同じ列のメディアパケット４０が選択される組み合わせがｘ−１Ｃ１通りあり、それら２つのメディアパケット４０とそれぞれ同じ行で矩形を形成するような２つのメディアパケット４０が選択される組み合わせがｘ−１Ｃ１通りあり、これらの組み合わせが斜め方向のメディアパケット４０の数だけ存在するので、それらを乗ずるとｘ−１Ｃ１×ｘ−１Ｃ１×ｘ通りとなる。ただし、この中に重複する組み合わせがｘＣ２通りある。また斜め方向からメディアパケット４０が２つ選択されると復元不可となり、その組み合わせはｘＣ２通りある。以上より、第１実施形態における復元不可のパターン数は、以下の理論式で表される。  
ｘＣ２×ｘＣ２−（ｘ−１Ｃ１×ｘ−１Ｃ１×ｘ−ｘＣ２×２）・・・（２）
【００７７】
また、第２実施形態における復元不可のパターン数は、上記式（２）から、斜めＡ２方向のＦＥＣパケットｄ２で復元できるパターン数であるｘ−１Ｃ１×ｘ−１Ｃ１×ｘ−ｘＣ２×２を更に減ずることで求められる。ただし、斜めＡ１方向のＦＥＣパケットｄ１により復元できるパターンと重複するパターンが存在するため、その重複パターンは除く必要がある。
【００７８】
図１１は、これらの理論式（１）及び（２）を、１０行×１０列のメディアパケットに適用して、従来技術、第１実施形態及び第２実施形態とで、メディアパケット４０を復元不可となるパターン数を比較した表を示した図である。  
同図に示すように、損失パケット数が４つの場合、従来技術では、復元不可のパターン数は２０２５通りであるのに対して、第１実施形態における復元不可のパターン数は１３０５通りとなり、第２実施形態における復元不可のパターン数は７４７通りとなる。すなわち、第１実施形態によれば、復元不可のパターン数を、従来技術に比べて約６４％まで低減することができ、第２実施形態によれば、復元不可のパターン数を、従来技術に比べて約３７％まで低減することができる。また、損失パケット数が５以上の場合でも、各実施形態において、損失パケット数が４つの場合とそれぞれ同一の低減率を得ることができる。すなわち、第１及び第２実施形態によれば、送受信パケット量をほとんど増加させることなく、損失されたメディアパケット４０の復元率を大幅に向上させることができる。
【００７９】
（第３の実施形態）  
次に、本発明の第３の実施形態について説明する。なお、本実施形態において、上述の第１及び第２の実施形態と同一の構成及び機能を有する箇所については同一の符号を付し、説明を省略または簡略化する。また、本実施形態においても、第１及び第２の実施形態と同様、サーバ１０とＴＶ２０とで誤り訂正システム１００が構成されており、以下の説明では、サーバ１０及びＴＶ２０の動作を中心に説明する。
【００８０】
上述の第１及び第２実施形態においては、それぞれ１つ及び２つのＦＥＣパケット５０によりメディアパケット４０を保護していた。しかし、これらの場合でも、依然として保護しきれないメディアパケット４０が存在する。そこで本実施形態においては、更に多くのＦＥＣパケット５０によりメディアパケット４０を保護することとしている。
【００８１】
図１２は、本実施形態において、サーバ１０のＦＥＣ処理部１５がＦＥＣパケット５０を生成する様子を示した図である。なお、本実施形態においては、説明の便宜上、メディアパケット４０を、４行×４列に構成した様子を示すが、上記第１及び第２の実施形態と同様、実際には１０行×１０列のメディアパケット４０を１つの単位としてＦＥＣパケット５０を生成するものとする。もちろん、これらの行数及び列数に限られるものではない。
【００８２】
同図に示すように、本実施形態においては、サーバ１０のＦＥＣ処理部１５は、第１及び第２実施形態と同様の処理により、行方向の各ＦＥＣパケットｒ１〜ｒ４、列方向の各ＦＥＣパケットｃ１〜ｃ４を生成する。更に、ＦＥＣ処理部１５は、それらに加えて、各メディアパケット４０を斜め方向の４つのグループ（グループ１〜４）に分け、それらグループ毎にＦＥＣパケット５０を生成する。
【００８３】
具体的には、ＦＥＣ処理部１５は、メディアパケットｐ０４、ｐ０７、ｐ１０及びｐ１３をグループ１とし、メディアパケットｐ０１、ｐ０８、ｐ１１及びｐ１４をグループ２とし、メディアパケットｐ０２、ｐ０５、ｐ１２及びｐ１５をグループ３とし、メディアパケットｐ０３、ｐ０６、ｐ０９及びｐ１６をグループ４として分類する。そして、ＦＥＣ処理部１５は、各グループに属するメディアパケット４０にそれぞれＸＯＲ演算を施し、グループ毎にＦＥＣパケットｄ１〜ｄ４を生成する。
【００８４】
これにより、各行及び各列に属するメディアパケット４０が全て斜め方向のＦＥＣパケット５０によっても保護されることとなる。サーバ１０は、上記メディアパケット４０と、行方向及び列方向のＦＥＣパケット５０と、上記斜め方向のＦＥＣパケット５０とをＴＶ２０へ送信する。図１２においては、メディアパケット４０は４行×４列に構成されるが、Ｄ行×Ｌ列に構成される場合には、各グループに属するメディアパケット４０の数はＬ個となり、グループの数、すなわち斜め方向のＦＥＣパケット５０の数はＤ個となる。メディアパケット４０が１０行×１０列で構成される場合には、グループの数、各グループに属するメディアパケット４０の数及び斜め方向のＦＥＣパケット５０の数は１０個となり、送信パケットの総数は、１３０個となる。
【００８５】
図１３は、本実施形態において、ＴＶ２０がコンテンツを受信してデコードする際の動作の流れを示したフローチャートである。なお、同図において、上記第１実施形態の図５と同様の処理となる箇所については説明を省略または簡略化する。
【００８６】
同図に示すように、第１実施形態の図５で示した場合と同様に、ＴＶ２０のＣＰＵは、コンテンツのストリーミング要求信号を送信し（ステップ１３１）、この要求に応じてサーバ１０から送信されたメディアパケット４０及びＦＥＣパケット５０をストリーミング受信し（ステップ１３２）、受信したメディアパケット４０のＲＴＰヘッダ４３に記載されたシーケンス番号を基に、損失したメディアパケット４０を検索する（ステップ１３３）。
【００８７】
そして、ＦＥＣ処理部２３は、メディアパケット４０の全損失数ｅｎ、各行における損失数ｅｃｏｌ［ｉ］、各列における損失数ｅｒｏｗ［ｉ］、及び斜め方向のグループ毎の損失数ｅｄｉａｇ［ｉ］の値をそれぞれ求める。ｅｄｉａｇ［ｉ］においてｉはグループ番号を示す。
同図においては、メディアパケット４０は１０行×１０列に構築されるものとする。したがって、［ｉ］には０〜９が代入される。
【００８８】
ｅｎの値が０である場合（ステップ１３４のＹｅｓ）には、メディアパケット４０の損失は無いということであるので、ＦＥＣ処理部２３は、受信したメディアパケット４０をそのままデコードさせ再生させる（ステップ１３８）。
【００８９】
ｅｎの値が０でない場合（ステップ１３４のＮｏ）には、ＦＥＣ処理部２３は、上記ｅｃｏｌ［ｉ］、ｅｒｏｗ［ｉ］及びｅｄｉａｇ［ｉ］の各値が２以上であるか否かを確認する（ステップ）。各値が全て２以上である場合には、ＦＥＣパケット５０によるメディアパケット４０の復元は不可能であるため、ＦＥＣ処理部２３は、損失したメディアパケット４０は隠蔽したままデコード処理を行わせる（ステップ１３８）。
【００９０】
ｅｃｏｌ［ｉ］、ｅｒｏｗ［ｉ］及びｅｄｉａｇ［ｉ］の各値が１以下の場合（ステップ６５のＮＯ）には、ＦＥＣ処理部２３は、各値が１である行、列またはグループからメディアパケット４０の復元処理を実行する（ステップ１３６）。以下、この処理を具体的に説明する。
【００９１】
図１４は、本実施形態においてメディアパケット４０が損失した様子を示した図であり、図１５は、その損失したメディアパケット４０を復元する様子を示した図である。なお、これらの図では、メディアパケット４０は、説明の便宜上、上記図１２の場合と同様、４行×４列に構築される場合を示しているが、上述したように、図１３のフローチャートでは、１０行×１０列に構築されるものとして説明する。
【００９２】
図１４に示すように、例えば、メディアパケットｐ０９、ｐ１０、ｐ１３及びｐ１４の４つのメディアパケット４０が損失した場合を想定する。この場合、ｅｃｏｌ［ｉ］、ｅｒｏｗ［ｉ］及びｅｄｉａｇ［ｉ］のうち、値が１となるのはｅｄｉａｇ［３］であるため、ＦＥＣ処理部２３はまず、このｅｄｉａｇ［３］＝１とカウントされた、グループ４に属するメディアパケットｐ０９を復元する。具体的には、図１５（ａ）に示すように、メディアパケットｐ０３、ｐ０６、ｐ１６及び斜め方向のＦＥＣパケットｄ４を順にＸＯＲ演算することにより、メディアパケットｐ０９を復元する。  
次に、ＦＥＣ処理部２３は、ｅｃｏｌ［０］＝１としてカウントされたメディアパケットｐ１３を、図１５（ｂ）に示すように、メディアパケットｐ０１、ｐ０５、ｐ０９及び列方向のＦＥＣパケットｃ１をＸＯＲ演算することで復元する。  
次に、ＦＥＣ処理部２３は、ｅｒｏｗ［２］＝１としてカウントされたメディアパケットｐ１０を、図１５（ｃ）に示すように、メディアパケットｐ０９、ｐ１１、ｐ１２及び行方向のＦＥＣパケットｒ３をＸＯＲ演算することで復元する。  
そして、ＦＥＣ処理部２３は、ｅｒｏｗ［３］＝１としてカウントされたメディアパケットｐ１４を、図１５（ｄ）に示すように、メディアパケットｐ１３、ｐ１５、ｐ１６及び行方向のＦＥＣパケットｒ４をＸＯＲ演算することで復元する。
【００９３】
以上の処理により、本実施形態によれば、上記第１実施形態においては復元不可能であったメディアパケット４０でも復元することが可能となる。例えば、上記第１の実施形態においては、損失したメディアパケットが矩形の各頂点を構成しており、かつ、そのうち２つのメディアパケット４０が斜め方向のＦＥＣパケット５０により保護されている場合にはそれらのメディアパケット４０を復元することはできなかった。しかし、本実施形態においては、各メディアパケット４０を複数のグループに分け、グループ毎のＦＥＣパケット５０により全て保護することとしたため、上記第１及び第２の実施形態に比べて、損失したメディアパケット４０の復元率を格段に向上させることができる。
【００９４】
（他の実施形態）  
本発明は上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【００９５】
上述の第１実施形態においては、斜めＡ１方向の１つのＦＥＣパケット５０を付加し、第３の実施形態においては、更にＦＥＣパケット５０による保護のレベルを上げて、複数のグループ毎に複数のＦＥＣパケット５０を付加していた。しかし、この複数のレベルのＦＥＣパケット５０を共存させて、ＴＶ２０側で複数レベルのＦＥＣ処理を選択して設定できるようにしても構わない。
【００９６】
図１６は、ＦＥＣ処理のレベルをＴＶ２０のユーザが選択するための設定画面を示した図である。  
同図に示すように、ＴＶ２０のＣＰＵは、例えば操作入力部に対するユーザ操作の入力に応じて、ディスプレイ２８にＦＥＣ機能設定画面１６０を表示させる。このＦＥＣ機能設定画面においては、ＦＥＣ機能のＯＮ／ＯＦＦを設定するためのラジオボタン１６１と、ＦＥＣ機能のＯＮにした場合にＦＥＣ機能のレベルを設定するためのラジオボタン１６２とが表示される。
【００９７】
ラジオボタン１６１において、ユーザが操作入力部を介してＦＥＣ機能のＯＮ／ＯＦＦを選択することで、ＴＶ２０においてＦＥＣ処理を行って損失したメディアパケット４０を復元してコンテンツのデコード処理を行うか、それともＦＥＣ処理を行わずに、損失したメディアパケット４０は隠蔽したままデコードを行うかを選択することができる。
【００９８】
また、ＦＥＣ機能をＯＮに設定した場合には、ラジオボタン１６２において、操作入力部を介して例えば３つのレベルのＦＥＣ処理を設定可能となる。例えばレベル１では、従来のPro-MPEG 2D FECにおける行方向及び列方向のみのＦＥＣ処理を行うように設定され、レベル２では、上記第１実施形態に示した斜めＡ１方向のＦＥＣパケット５０によるＦＥＣ処理を行うように設定され、レベル３では、上記第３実施形態に示した複数グループ毎の複数のＦＥＣパケット５０によるＦＥＣ処理を行うように設定される。
【００９９】
なお、この場合、サーバ１０は、常に上記第３実施形態に示した、グループ毎の複数のＦＥＣパケット５０を付加してメディアパケット４０をＴＶ２０へ送信する。
【０１００】
これにより、多少のパケット損失はあってもリアルタイムにコンテンツを視聴したい場合や、多少の遅延はあっても画質の高いコンテンツを視聴したい場合、それらの両方を求める場合等、ユーザの要求に応じて複数レベルのＦＥＣ処理を切り替えることができ、ユーザの利便性が向上する。
【０１０１】
また、上記ＦＥＣ機能設定画面１６０によらずに、例えばＴＶ２０のＣＰＵが、時間帯に応じて上記複数レベルのＦＥＣ処理を切り替えるようにしてもよい。例えば、ネットワーク３０の輻輳が予想される時間帯（例えば夜間）にはメディアパケット４０の損失が多くなることも予想されるため、その時間帯には、上記斜め方向のブロック毎の、複数のＦＥＣパケット５０を用いたＦＥＣ処理を行うように設定し、ネットワーク３０の輻輳が比較的緩和されると予想される時間帯（例えば早朝）には、従来のPro-MPEG 2D FECにおける行方向及び列方向のみのＦＥＣパケット５０によるＦＥＣ処理を行うように設定することができる。
【０１０２】
更に、上記複数レベルのＦＥＣパケット５０を、例えばネットワーク３０の輻輳状況に応じてサーバ１０側が制御するようにしても構わない。すなわち、ＴＶ２０からサーバ１０へ、ネットワーク３０の輻輳状況を示す輻輳情報を予め送信し、サーバ１０は、当該輻輳情報に応じて上記複数レベルのＦＥＣパケット５０を生成して送信する。
【０１０３】
この輻輳状況に応じたＦＥＣ処理は、例えば、ＲＴＰの制御用プロトコルであるＲＴＣＰによるセッション制御技術を用いることで実現可能である。以下、この動作の詳細について説明する。図１７は、この輻輳状況に応じたＦＥＣ処理の流れを示したシーケンス図である。  
同図に示すように、まず、サーバ１０は、ＲＴＣＰにおけるＳＲ（Sender Report）パケットをＴＶ２０へ送信する（ステップ１７１）。このＳＲパケットには、例えば送信元であるサーバ１０のこれまでの送信パケットの総数等の送信状態が記述される。ＴＶ２０は、このＳＲパケットの受信に応じて、ＲＲ（Receiver Report）パケットを生成してサーバ１０へ送信する（ステップ１７２）。このＲＲパケットには、上記ＳＲパケットから得られるパケット損失率、これまでの累積パケット損失数、直前に受信したＳＲパケットの到着間隔のジッタ、直前に受信したＳＲパケットの受信から当該ＲＲパケットの送信までの遅延時間等が記述される。続けて、ＴＶ２０は、コンテンツのストリーミング要求信号をサーバ１０へ送信する（ステップ１７３）。なお、ストリーミング要求信号の送信のタイミングで輻輳情報を送信するようにしても構わない。
【０１０４】
サーバ１０は、上記ＲＲパケット及びストリーミング要求信号を受信すると、ＲＲパケットに記述されたパケット損失率やジッタ等の情報と、上記ＳＲの送信からＲＲの到着までの時間（同図（ａ）の時間）から、上記ＲＲに記述された遅延時間（同図（ｂ）の時間）を引いて算出したＲＴＴ（Round Trip Time）等の情報を、ネットワーク３０の輻輳情報として解析し、この輻輳情報を基に、上記複数レベルのＦＥＣパケット５０の生成処理を行う（ステップ１７４）。
具体的には、サーバ１０のＦＥＣ処理部１５は、輻輳度の高い順に例えば３つのレベル（レベル１〜３）を設定しておき、上記輻輳情報により輻輳度が例えばレベル１であると判断された場合には、行方向及び列方向のＦＥＣパケット５０に加えて上記第３実施形態で示した斜め方向のブロック毎の複数のＦＥＣパケット５０を生成し、レベル２であると判断された場合には、行方向及び列方向のＦＥＣパケット５０に加えて上記第１実施形態で示した斜めＡ１方向の１つのＦＥＣパケット５０を生成し、レベル３であると判断された場合には、従来のPro-MPEG 2D FECにおける行方向及び列方向のみのＦＥＣパケット５０を生成する。なお、このとき、ＦＥＣパケット５０のＦＥＣヘッダ５４には、ＦＥＣパケット５０の上記レベルを示す情報も記述されるようにする。そして、サーバ１０は、この生成されたＦＥＣパケット５０及びメディアパケット４０をＴＶ２０へ送信する（ステップ１７５）。
【０１０５】
ＴＶ２０は、このＦＥＣパケット５０及びメディアパケット４０を受信し、メディアパケット４０の損失が発生した場合には、ＦＥＣ処理部２３により、上記レベルに応じたＦＥＣ処理を行う（ステップ１７６）。すなわち、上記ＦＥＣヘッダ５４に記述されたレベルに応じて、行方向及び列方向のＦＥＣパケット５０及び斜め方向の１つまたは複数のＦＥＣパケット５０を用いたメディアパケット４０の復元処理を行う。復元後のメディアパケット４０はデコードされ再生される。
【０１０６】
以上の動作により、ネットワーク３０の輻輳状況に応じたＦＥＣパケット５０の生成処理及びそれを用いたメディアパケット４０の復元処理を行うことができる。したがって、斜め方向のＦＥＣパケット５０の生成処理に係るサーバ１０の負荷や、それを用いたメディアパケット４０の復元処理に係るＴＶ２０の負荷を極力軽減し、また、斜め方向のＦＥＣパケット５０の送信による送信パケット量の増加を極力防ぎながらも、効率よくメディアパケット４０を復元することが可能となる。
【０１０７】
なお、上記ＦＥＣレベルは、３つに限られず、例えば上記第２実施形態で示した斜めＡ２方向も加えた２つのＦＥＣパケット５０を生成する場合を更なるレベルとして加えて、計４つのレベルでＦＥＣ処理を切り替えるようにしても構わない。
【０１０８】
また、上記第３の実施形態における斜め方向のブロック毎のＦＥＣパケット５０の生成処理を、それに直交する斜め方向においても同様に行って、更なるＦＥＣパケット５０を生成するようにしても構わない。またこの両斜め方向におけるブロック毎のＦＥＣパケット５０によるＦＥＣ処理を、新たなレベルとして設定できるようにしても構わない。
【０１０９】
上述の各実施形態においては、メディアパケット４０の行数と列数が同一である例を示した。しかし、もちろん、行数と列数とが異なっていても構わない。図１８は、行数と列数とが異なる場合に、上記第３実施形態における斜め方向のグループ毎のＦＥＣパケット５０をサーバ１０が生成する様子を示した図である。
【０１１０】
同図に示すように、メディアパケット４０は、例えば６行×４列に構成されている。サーバ１０のＦＥＣ処理部１５は、これらのメディアパケット４０のうち、６つ（行数と等しい数）のメディアパケットｐ０２、ｐ０５、ｐ１２、ｐ１５、ｐ１８及びｐ２１をグループ１とし、６つのメディアパケットｐ０３、ｐ０６、ｐ０９、ｐ１６、ｐ１９及びｐ２２をグループ２とし、６つのメディアパケットｐ０４、ｐ０７、ｐ１０、ｐ１３、ｐ２０及びｐ２３をグループ３とし、６つのメディアパケットｐ０１、ｐ０８、ｐ１１、ｐ１４、ｐ１７及びｐ２４をグループ４として、４つ（列数と等しい数）のグループに分類する。そして、ＦＥＣ処理部１５は、各グループに属するメディアパケット４０にそれぞれＸＯＲ演算を施し、グループ毎にＦＥＣパケットｄ１〜ｄ４を生成する。これらのＦＥＣパケット５０が、行方向及び列方向の他のＦＥＣパケット５０及びメディアパケットと共にＴＶ２０へ送信される。
【０１１１】
そして、ＴＶ２０は、受信したメディアパケット４０を上記６行×４列に構成し、これらのＦＥＣパケット５０を用いて、上記グループ毎のＦＥＣ処理を行う。
【０１１２】
上述の実施形態においては、ＦＥＣパケット５０の生成処理及びそれを用いたメディアパケット４０の復元処理にはＸＯＲ演算処理を用いていたが、例えばリードソロモン符号やハミング符号等の他の関数による演算処理を適用しても構わない。
【０１１３】
上述の実施形態においては、送信装置としてサーバ１０を、受信装置としてＴＶ２０を適用した例を示したが、当該送信装置及び受信装置としては、他にも、例えばＰＣ、ＨＤＤ／ＤＶＤ／ＢＤ（Blu-ray Disc）レコーダ等の記録再生装置、ゲーム機器、携帯電話機、その他のＡＶ機器等のあらゆる電子機器から選択して適用することが可能である。
【図面の簡単な説明】
【０１１４】
【図１】本発明の第１実施形態に係る誤り訂正システムの構成を示した図である。
【図２】本発明の第１実施形態において、サーバがコンテンツを送信する際の動作の流れを示したフローチャートである。
【図３】本発明の第１実施形態におけるメディアパケットとＦＥＣパケットとの関係を示した図である。
【図４】本発明の第１実施形態において、サーバのＦＥＣ処理部がＦＥＣパケットを生成する様子を示した図である。
【図５】本発明の第１実施形態において、ＴＶがコンテンツを受信してデコードする際の動作の流れを示したフローチャートである。
【図６】本発明の第１実施形態において、メディアパケットが損失した様子を示した図である。
【図７】本発明の第１実施形態において、損失したメディアパケットを復元する様子を示した図である。
【図８】本発明の第２実施形態において、サーバのＦＥＣ処理部がＦＥＣパケットを生成する様子を示した図である。
【図９】本発明の第２実施形態において、メディアパケットが損失した様子を示した図である。
【図１０】本発明の第２実施形態において、損失したメディアパケットを復元する様子を示した図である。
【図１１】従来技術、第１実施形態及び第２実施形態とで、メディアパケットを復元不可となるパターン数を比較した表を示した図である。
【図１２】本発明の第３の実施形態において、サーバのＦＥＣ処理部がＦＥＣパケットを生成する様子を示した図である。
【図１３】本発明の第３実施形態において、ＴＶがコンテンツを受信してデコードする際の動作の流れを示したフローチャートである。
【図１４】本発明の第３実施形態において、メディアパケットが損失した様子を示した図である。
【図１５】本発明の第３実施形態において、損失したメディアパケットを復元する様子を示した図である。
【図１６】本発明の他の実施形態において、ＦＥＣ処理のレベルをＴＶのユーザが選択するための設定画面を示した図である。
【図１７】本発明の他の実施形態において、輻輳状況に応じたＦＥＣ処理の流れを示したシーケンス図である。
【図１８】行数と列数とが異なる場合に、斜め方向のグループ毎のＦＥＣパケットをサーバが生成する様子を示した図である。
【符号の説明】
【０１１５】
１０…サーバ
１１…ビデオＴＳエンコーダ
１２…オーディオＴＳエンコーダ
１３…ＭＵＸ
１４、２４…ＲＴＰ処理部
１５、２３…ＦＥＣ処理部
１６、２２…ＵＤＰ処理部
１７、２１…ネットワークインタフェース
２０…テレビジョン装置（ＴＶ）
２５…ＤＥＭＵＸ
２６…ビデオＴＳデコーダ
２７…オーディオＴＳデコーダ
２８…ディスプレイ
２９…スピーカ
３０…ネットワーク
４０…メディアパケット
５０…ＦＥＣパケット
１００…誤り訂正システム
１６０…ＦＥＣ機能設定画面
【図１】
0004434242.tif 000002
【図２】
0004434242.tif 000003
【図３】
0004434242.tif 000004
【図４】
0004434242.tif 000005
【図５】
0004434242.tif 000006
【図６】
0004434242.tif 000007
【図７】
0004434242.tif 000008
【図８】
0004434242.tif 000009
【図９】
0004434242.tif 000010
【図１０】
0004434242.tif 000011
【図１１】
0004434242.tif 000012
【図１２】
0004434242.tif 000013
【図１３】
0004434242.tif 000014
【図１４】
0004434242.tif 000015
【図１５】
0004434242.tif 000016
【図１６】
0004434242.tif 000017
【図１７】
0004434242.tif 000018
【図１８】
0004434242.tif 000019