JP6415302B2 - 通信装置、通信方法及びプログラム - Google Patents

Description

本発明は、コンテンツデータを伝送する技術に関する。

従来、データ伝送中のパケット損失に対する耐性を高めるための技術が種々提案されている。例えば、特許文献１には、レートレス符号化技術により伝送データを符号化する符号化装置において、誤り耐性を向上させるソースシンボルに対応して定められた所定の範囲において非零要素を多く配置した検査行列を生成し、この検査行列を用いてソースシンボルを符号化するという符号化方法が開示されている。ここで、所定の範囲において非零要素を多く配置した検査行列とは、例えば、時間的に早い時刻に対応するデータが重要とのヒューリスティッを採用し、検査行列のうち、早い時刻に対応する要素に、遅い時刻に対応する要素よりも１を多く配置した検査行列のことである。

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

レートレス符号化技術としてLDPC（Low Density Parity Check Code）符号が採用された場合、復号装置の側では、受信したFEC（Forward Error Correction）シンボルのデータ量が所定の閾値を超えるとFECデコード処理が実行される。FECデコード処理に失敗した場合には、追加のFECシンボルを受信してから再度FECデコード処理が実行される。閾値を設けることで復号までの時間が短縮される一方で、その分FECデコード処理の処理負荷が復号装置にはかかり、復号装置のリソースや電池消費量に影響する。

本発明は、このような事情に鑑みてなされたものであり、コンテンツデータを伝送する際に当該コンテンツデータを構成するソースシンボルが欠落した場合に、当該コンテンツデータを復元する処理負荷を低減することを目的とする。

上記の課題を解決するため、本発明は、コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとを受信する受信部と、前記複数のソースシンボルのうち、欠落したソースシンボルを特定する欠落シンボル特定部と、前記欠落シンボル特定部により特定されたソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定する判定部と、前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算する計算部と、前記判定部により判定された重要度と、前記計算部により計算された空きデータ量とに基づいて、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるか否かを判定する補完可能シンボル判定部と、前記補完可能シンボル判定部により、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが前記受信部により受信されるのを待ってから、前記コンテンツデータの復元を開始する復号部とを備える通信装置を提供する。

好ましい態様において、前記判定部は、前記複数のソースシンボルの各々について、前記コンテンツデータを復元する上での重要度を判定し、前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に、前記計算部により計算された空きデータ量に基づき、前記複数のソースシンボルのうち追加的に送信されてくるソースシンボルを特定する追加シンボル特定部をさらに備え、前記補完可能シンボル判定部は、前記追加シンボル特定部により特定されたソースシンボルに前記欠落シンボル特定部により特定されたソースシンボルが含まれるか否かを判定することにより、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるソースシンボルであるか否かを判定する。

さらに好ましい態様において、前記復号部は、前記補完可能シンボル判定部により、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるソースシンボルではないと判定された場合には、当該ソースシンボルが前記受信部により受信されるのを待たずに、前記コンテンツデータの復元を開始する。

さらに好ましい態様において、前記復号部は、検査行列に基づいて前記コンテンツデータを復元し、前記判定部は、前記検査行列における一の列と他の列とを比較した場合に、前記一の列に含まれる非零要素の方が前記他の列よりも多いときには、前記一の列に対応するソースシンボルの重要度の方を、前記他の列に対応するソースシンボルよりも高く判定する。

さらに好ましい態様において、前記判定部は、前記検査行列において前記一の列に含まれる非零要素の数と前記他の列に含まれる非零要素の数とが等しい場合であって、前記一の列に対応するソースシンボルの方が前記他の列に対応するソースシンボルよりも古いデータであるときには、前記一の列に対応するソースシンボルの重要度の方を、前記他の列に対応するシースシンボルよりも高く判定する。

さらに好ましい態様において、前記追加シンボル特定部は、前記判定部により判定された重要度が閾値以上であるソースシンボルの中から、前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを特定し、前記閾値は、前記コンテンツデータのデータ量に基づいて決定される。

また、本発明は、コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとが送信元から送信された場合に、前記複数のソースシンボルのうち、欠落したソースシンボルを特定するステップと、前記特定したソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定するステップと、前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算するステップと、前記判定された重要度と、前記計算された空きデータ量とに基づいて、前記欠落したソースシンボルが追加的に送信されてくるか否かを判定するステップと、前記欠落したソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが受信されるのを待ってから、前記コンテンツデータの復元を開始するステップとを有する通信方法を提供する。

また、本発明は、コンピュータに、コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとが送信元から送信された場合に、前記複数のソースシンボルのうち、欠落したソースシンボルを特定するステップと、前記特定したソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定するステップと、前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算するステップと、前記判定された重要度と、前記計算された空きデータ量とに基づいて、前記欠落したソースシンボルが追加的に送信されてくるか否かを判定するステップと、前記欠落したソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが受信されるのを待ってから、前記コンテンツデータの復元を開始するステップとを実行させるためのプログラムを提供する。

本発明によれば、コンテンツデータを伝送する際に当該コンテンツデータを構成するソースシンボルが欠落した場合に、当該コンテンツデータを復元する処理負荷を低減することができる。

ライブストリーミングシステム１の構成の一例を示す図である。 ライブストリーミングシステム１のプロトコルスタックを示す図である。 ライブストリーミングの処理手順を示す図である。 セグメントファイルの送出時間とビットレートとの関係の一例を示す図である。 ライブストリーミングシステム１の機能ブロック図である。 検査行列の一例を示す図である。 重要シンボル判定処理の一例を示すフローチャートである。 空き領域計算処理の一例を示すフローチャートである。 重要シンボル補完処理の一例を示すフローチャートである。 受信クライアント６の機能ブロック図である。 FECデコード実施判定処理の一例を示すフローチャートである。 重要シンボル判定処理の一例を示すフローチャートである。 空き領域計算処理の一例を示すフローチャートである。 追加シンボル判定処理の一例を示すフローチャートである。 補完可能シンボル判定処理の一例を示すフローチャートである。 補完可能シンボル選別処理の一例を示すフローチャートである。

１．実施形態
図１は、本発明の一実施形態に係るライブストリーミングシステム１の構成の一例を示す図である。同図に示されるように、ライブストリーミングシステム１は、ビデオカメラ２と、エンコーダ３と、配信サーバ４と、無線ＬＡＮ（Local Area Network）５と、複数の受信クライアント６とにより構成される。ビデオカメラ２はエンコーダ３と例えばケーブルにより接続され、エンコーダ３は配信サーバ４と例えばケーブルにより接続される。配信サーバ４は複数の受信クライアント６と無線ＬＡＮ５を介して接続される。

本ライブストリーミングシステム１では、MPEG-DASH（Dynamic Adaptive Streaming over HTTP）がサポートする数秒単位のセグメント形式の動画や音声のファイルをIPDC（IP DataCast）で送受信することで、ライブストリーミングが実現される。ここで、MPEG-DASHとは、各種のデバイス端末に向けてHTTPプロトコルによる動画や音声のストリーミング配信を実現する国際標準規格である。また、IPDCとは、放送や通信にIPパケットを載せて、各種デバイス端末へ一斉同報でマルチメディアファイル（テキスト、画像、音声、映像など）を伝送する技術である。

従来のストリーミング技術では映像をパケット単位に分割して送出するため、パケットが欠落すると完全に元の映像を復元することができず、ノイズ等の映像の乱れが発生する。一方、MPEG-DASHとIPDCとを組み合わせたストリーミング技術では、映像の再生単位であるファイル毎に処理が行われるといった特性上、映像の再生中に画面にノイズが発生しにくい。加えて、パケット単位よりもデータ量の多いファイル単位でFEC処理を行うため、データの損失時にもファイルを復元しやすく映像が途切れにくいといった、既存のストリーミング技術と比較して再生品質面でのメリットがある。

図２は、本ライブストリーミングシステム１のプロトコルスタックを示す図である。IPDCでは、完全片方向でファイルを受信クライアント６に送り届ける必要がある。これを実現するために、本ライブストリーミングシステム１では、同図に示されるように、FLUTE（File Delivery over Unidirectional Transport: RFC3926）プロトコルによる伝送に加えて、AL-FEC（Application Layer Forward Error Correction）の適用により、伝送中にパケットが消失してもファイルを受信クライアント６にて復元することが可能になっている。また、UDP（User Datagram Protocol）/IPを用いたマルチキャスト配信を行うことで、伝送路の帯域が狭い場合であっても多数の受信クライアント６が同時に映像を受信、再生することが可能になる。伝送路としては、放送波、通信網のどちらも利用することが可能である。
なお、本実施形態では、AL-FEC符号化方式としてLDPC（Low Density Parity Check Code: RFC5170）-Staircaseが使用される。

図３は、本ライブストリーミングシステム１において実行されるライブストリーミングの処理手順を示す図である。本処理手順においてビデオカメラ２がエンコーダ３に対して一の映像データを出力すると（処理１）、エンコーダ３は当該映像データを数秒単位のセグメントファイルに分割して圧縮する（処理２）。そして、圧縮したセグメントファイル群を配信サーバ４に出力する。

配信サーバ４は、エンコーダ３から出力された各セグメントファイルをソースブロックに分割した上で、各ソースブロックをソースシンボルに分割する（処理３）。例えば、配信サーバ４は、各セグメントファイルを、予め定めたサイズのソースブロックに分割し、さらに、各ソースブロックを、予め定めたサイズのソースシンボルに分割する。ここで、ソースブロックは、本発明に係る「コンテンツデータ」の一例である。なお、セグメントファイルをソースブロックに分割する際、セグメントファイルのデータの先頭から順にソースブロックに識別番号を付与するなどして、セグメントファイル内でのソースブロックの並び順を復元できるようにしておく。また、ソースブロックをソースシンボルに分割する際にも、ソースブロックのデータの先頭から順にソースシンボルに識別番号（例えば、図６に示される、ソースシンボルを示す符号「Ｓ１」の添え字「１」）を付与するなどして、ソースブロック内でのソースシンボルの並び順を復元できるようにしておく。

次に、配信サーバ４は、各ソースブロックにつき、生成したソースシンボル群に基づいて１以上のFECシンボルを生成し、生成した各シンボルにFLUTEヘッダを付与してFLUTEパケットを生成する（処理４）。なお、配信サーバ４は、各FECシンボルに対して、識別番号（例えば、図６に示される、FECシンボルを示す符号「Ｐ１」の添え字「１」）を付与するなどして、並び順を復元できるようにしておく。この処理４では、配信サーバ４は、後述する重要シンボル判定処理と、空き領域計算処理と、重要シンボル補完処理とを実行する。なお、ここで、FECシンボル（または、パリティシンボル）とは、誤り訂正用のデータである。FECシンボルの生成方法については後述する。

次に、配信サーバ４は、各ソースブロックに対して生成されたFECシンボル内でインターリーブを行う（処理５）。すなわち、配信サーバ４は、FECシンボルについては先頭から順に送るのではなく、乱数等を使って送信順序を入れ替える。一方、ソースシンボルについては、ソースブロック内でのソースシンボルの並び順に従って送信する。次に、配信サーバ４は、各FLUTEパケットにUDP/IPヘッダを付与してUDPパケットを生成する（処理６）。次に、配信サーバ４は、各UDP/IPパケットにULE（Unidirectional Lightweight Encapsulation: RFC4326）ヘッダとCRC（Cyclic Redundancy Check）32とを付与してカプセル化する（処理７）。次に、配信サーバ４は、各ULEパケットをTSパケットに分割して（処理８）、所定の伝送レートで受信クライアント６に送信する。

受信クライアント６は、配信サーバ４からTSパケット群を受信すると（処理９）、TSパケットのペイロード部分を結合する（すなわち、ULEでカプセル化された情報を復元する）（処理１０）。次に、受信クライアント６は、ULEのデキャプスレーション処理（すなわち、カプセル化をほどく処理）を行い、UDPパケットを取り出す（処理１１）。次に、受信クライアント６は、復元されたUDPパケットからFLUTEパケットを復元する（処理１２）。

次に、受信クライアント６は、FECデコードを行い、消失したFLUTEパケットを復元する（処理１３）。このFECデコードを行うにあたり、受信クライアント６は、後述するFECデコード実施判定処理と、重要シンボル判定処理と、空き領域計算処理と、追加シンボル判定処理と、補完可能シンボル判定処理と、補完可能シンボル選別処理とを実行する。

次に、受信クライアント６は、復元されたFLUTEパケットからソースシンボルを復元する（処理１４）。次に、受信クライアント６は、復元されたソースシンボル群からセグメントファイルを復元する（処理１５）。具体的には、受信クライアント６は、ソースシンボル群を、例えばソースシンボルに付与されている識別番号を用いてソースブロック内での並び順に並べてソースブロックを復元し、その後、例えばソースブロックに付与されている識別番号を用いてソースブロックをセグメントファイル内での並び順に並べてセグメントファイルを復元する。そして、受信クライアント６は、復元されたセグメントファイル群を順次再生する（処理１６）。

以上説明した処理手順においては、処理４により送出側でFECシンボルを生成することにより、伝送路にて消失したFLUTEパケットの復元が可能となる。しかし、消失したFLUTEパケットの数が多い場合には、復元できない場合もある。

また、以上説明した処理手順においては、処理２により映像データは数秒単位のセグメントファイルに分割されて圧縮されるが、この際、動きの多いシーンほど圧縮後のファイルサイズが大きくなり、動きの少ないシーンほど圧縮後のファイルサイズが小さくなる。動画を構成する各映像シーンの動きは非一定であるため、各セグメントファイルのサイズにはばらつきが生じる。したがって、ファイルサイズによっては何もパケットが送信されない時間が発生することがある。図４は、各セグメントファイルの送出時間とビットレートとの関係の一例を示す図である。同図に示される例では、例えば、経過時間７７秒から７８秒にかけて空き領域（ビットレート）Ｒが生じている。なお、図４ではセグメント間隔Tが１秒の例を示している。

そこで、本実施形態では、パケットが送信されていない時間に、誤り訂正に重要なソースシンボルを補完的に送信することにより、従来の送信方式ではFLUTEパケットを復元できない場合でも復元できる確率を高める手法が採用されている。

図５は、本ライブストリーミングシステム１の機能ブロック図である。特に、ビデオカメラ２と、エンコーダ３と、配信サーバ４の機能ブロック図である。
ビデオカメラ２は映像撮影部２１を有する。この映像撮影部２１は、映像データを生成してエンコーダ３に出力する。

エンコーダ３は、映像分割部３１と、映像圧縮部３２とを有する。映像分割部３１は、ビデオカメラ２から出力された映像データを数秒単位のセグメントファイルに分割する。映像圧縮部３２は、映像分割部３１により生成された各セグメントファイルを圧縮する。

配信サーバ４は、シンボル分割部４１と、FEC生成部４２と、重要シンボル判定部４３と、空き領域計算部４４と、重要シンボル補完部４５と、FLUTEパケット生成部４６と、UDPパケット生成部４７と、ULE部４８と、TSパケット生成部４９と、送信部５０とを有する。これらの機能は、ＣＰＵ等の演算装置によりプログラムが実行されることにより実現される。

シンボル分割部４１は、エンコーダ３から出力されたセグメントファイルを複数のソースブロックに分割した上で、各ソースブロックを複数のソースシンボルに分割する。

FEC生成部４２は、シンボル分割部４１により生成された複数のソースシンボルに基づいて１以上のFECシンボルを生成する。FECシンボルが生成される際には、各ソースブロック毎に一の検査行列が生成されて使用される。

図６は、検査行列の一例を示す図である。検査行列は左側検査行列と右側検査行列とにより構成される。左側検査行列は、各検査式に含まれるソースシンボルを示し、右側検査行列は、各検査式に含まれるFECシンボルを示す。左側検査行列は、乱数系列により非零要素「１」を挿入する行列要素が選択され、各列、各行ともに次数で指定された数以上の「１」が挿入されて構成される。具体的には、所定の関数や規則（例えば、LDPC-staircaseで指定された規則）に基づき、乱数と予め定めた次数を指定すると、左側検査行列の中で非零要素「１」を挿入する行列要素が決定される。左側検査行列の１つの行に含まれる「１」の個数は、次数で指定された個数となる。乱数と次数が同じであれば、常に同じ左側検査行列が生成される。なお、図６に示される例では、次数は「３」である。

右側検査行列は、単位行列において、（ｉ，ｉ−１）（ただし、ｉは１以上の整数）の要素にも非零要素「１」が挿入されることにより構成される。符号Ｓ１〜Ｓ６は各々ソースシンボルを示し、符号Ｐ１〜Ｐ６は各々FECシンボルを示す。
なお、左側検査行列は固定的に設定されてもよい。

FECシンボルＰ１〜Ｐ６は、検査行列の各行の検査式が成立するように生成される。なお、この検索式で用いられる加算は全て排他的論理和である。例えば、FECシンボルＰ１は、第１行目の検査式「Ｓ１＋Ｓ４＋Ｓ６＋Ｐ１＝０」が成立するように生成される。別の例として、FECシンボルＰ２は、第２行目の検査式「Ｓ３＋Ｓ４＋Ｓ６＋Ｐ１＋Ｐ２＝０」が成立するように生成される。

次に、重要シンボル判定部４３は、シンボル分割部４１により生成された複数のソースシンボルの各々について、当該複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合にセグメントファイルを復元する上での重要度を判定する。その際、重要シンボル判定部４３は、検査行列における一の列と他の列とを比較した場合に、一の列に含まれる非零要素の方が他の列よりも多いときには、その一の列に対応するソースシンボルの重要度の方を、他の列に対応するシースシンボルよりも高く判定する。

図７は、重要シンボル判定部４３により実行される重要シンボル判定処理の一例を示すフローチャートである。本処理のステップＳａ１において重要シンボル判定部４３は、処理対象となるソースシンボル群に対して生成された検査行列を取得する。次に、重要シンボル判定部４３は、処理対象となる各ソースシンボルの重要度を計算する（ステップＳａ２）。具体的には、重要シンボル判定部４３は、ステップＳａ１において取得した検査行列に基づいて各ソースシンボルの重要度を計算する。

上記の図６に示される検査行列において、左側検査行列の各列の「１」の数は、当該列に対応するソースシンボルが検査式に登場する回数を示している。例えば、ソースシンボルＳ３に対応する列Ｃには「１」が５個含まれており、これは第２行目から第６行目までの検査式においてソースシンボルＳ３が登場することを示している。

検査式に登場する回数の多いソースシンボルは、FECシンボルを生成するために利用された回数が多いソースシンボルであり、また、誤り訂正の際に他のソースシンボルを復元するために利用される可能性が高いソースシンボルでもある。すなわち、左側検査行列の各列の「１」の数が多いソースシンボルは、誤り訂正に際して重要度が高いソースシンボルであると言える。よって、重要シンボル判定部４３は、左側検査行列の各列の「１」の数が多いソースシンボルほどその重要度が高くなるように、各ソースシンボルの重要度を計算する。ここで、重要シンボル判定部４３は、例えば、左側検査行列の各列の「１」の数を、対応するソースシンボルの重要度としてもよい。これは、検査式は、左側検査行列とソースシンボルの列とを行列計算して生成されるわけであるが、このとき、各ソースシンボルが検査式に含まれるか否かは、行列計算時に左側検査行列の中でソースシンボルと掛け合わされる要素となる列の値が非零要素「１」であるか否かに依存するからである。よって、各左側検査行列の各列で「１」が発生する数を、対応するソースシンボルの重要度としてもよい。
なお、図６に示される左側検査行列において、全てのソースシンボルＳ１〜Ｓ６の重要度を計算すると、その重要度の順序は、「Ｓ３＞Ｓ４＞Ｓ６＞Ｓ１＝Ｓ２＝Ｓ５」のようになる。

各ソースシンボルについて重要度を計算すると、重要シンボル判定部４３は、ソースシンボル毎の重要度を示す情報を重要シンボル補完部４５に送る（ステップＳａ３）。
以上が、重要シンボル判定処理についての説明である。

次に、空き領域計算部４４は、セグメントファイルが伝送される際の単位時間あたりのデータ量（換言すると、配信サーバ４によりパケットが送信される所定の伝送レートで特定される、単位時間あたりのデータ量）から、当該セグメントファイルが分割されて生成される複数のソースシンボルの各々を含むパケットのデータ量の合計と、当該複数のソースシンボルに基づいて生成される１以上のFECシンボルの各々を含むパケットのデータ量の合計とを減算することにより得られるデータ量に基づいて、重要シンボル補完部４５により選択されるソースシンボルのデータ量上限を計算する。

図８は、空き領域計算部４４により実行される空き領域計算処理の一例を示すフローチャートである。本処理のステップＳｂ１において空き領域計算部４４は、エンコーダ３により生成されたセグメントファイルに基づいて、セグメントファイルサイズを特定する。ここで、当該セグメントファイルは、重要シンボル判定部４３の処理対象となったソースシンボル群により構成されていたセグメントファイルである。

次に、空き領域計算部４４は、配信サーバ４に記憶される設定ファイルに基づいて、IPビットレートと、セグメント間隔と、パケットサイズと、シンボルサイズと、FEC付与率とを特定する（ステップＳｂ２）。ここで、パケットサイズは、セグメントファイルサイズと、シンボルサイズと、FEC付与率とに基づいて次式により求められる。
パケット数＝セグメントファイルサイズ（KB）×（100＋FEC付与率（％））÷100÷シンボルサイズ（KB）（小数点以下切り上げ）
なお、FEC付与率は、ソースシンボルに対するFECシンボルの割合を示す。FEC付与率は任意に設定されてよい。

次に、空き領域計算部４４は、ステップＳｂ１及びＳｂ２で特定した情報に基づいて空き領域を計算する（ステップＳｂ３）。ここで空き領域は次式により求められる。
空き領域（KB）＝IPビットレート（kbps）×セグメント間隔T（sec）÷8（bit）−（パケット数×パケットサイズ（KB））

そして、空き領域計算部４４は、ステップＳｂ３で求めた空き領域を示す情報を重要シンボル補完部４５に送る（ステップＳｂ４）。
以上が、空き領域計算処理についての説明である。

以上説明した空き領域計算処理によれば、仮に受信したセグメントファイルサイズが100KB、IPビットレートが1400kbps、セグメント間隔Tが1sec、シンボルサイズが1000bytes、パケットサイズが1044bytes、FEC付与率が50％である場合には、空き領域は以下のように求められる。
パケット数＝100×1.5÷1.000＝150個
空き領域（KB）＝1400（kbps）×1（sec）÷8−(1.044×150)＝18.4（KB）

次に、重要シンボル補完部４５は、重要シンボル判定部４３により複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを選択する。より具体的には、重要シンボル補完部４５は、重要シンボル補完部４５により複数のソースシンボルの各々について判定された重要度の順に、空き領域計算部４４により計算されたデータ量上限に基づきソースシンボルを選択する。

図９は、重要シンボル補完部４５により実行される重要シンボル補完処理の一例を示すフローチャートである。本処理のステップＳｃ１において重要シンボル補完部４５は、空き領域計算部４４より、空き領域を示す情報を取得する。

次に、重要シンボル補完部４５は、ステップＳｃ１において取得した情報により示される空き領域に基づいて、追加で付与可能なソースシンボル数を計算する（ステップＳｃ２）。ここで追加で付与可能なソースシンボル数は次式により求められる（なお、本実施形態では、シンボルサイズが固定されている場合を想定している）。
追加ソースシンボル数＝空き領域（KB）÷パケットサイズ（KB）（小数点以下切り下げ）
仮に、空き領域が18.4（KB）、パケットサイズが1044bytes（1.044KB）である場合には、追加ソースシンボル数は以下のように求められる。
追加ソースシンボル数＝18.4（KB）÷1.044（KB）＝17個

なお、本実施形態では、１つのセグメント間隔において１つのソースブロックを構成するソースシンボル群が送信される場合を想定しているため、重要シンボル補完部４５は、１つのセグメント間隔当たりの空き領域に基づいて、追加で付与可能なソースシンボル数を計算している。しかし、仮に１つのセグメント間隔において複数のソースブロックを構成するソースシンボル群が送信される場合には、重要シンボル補完部４５は、ステップＳｃ１において取得した情報により示される空き領域を、当該複数のソースブロックの数で除算して求めた値に基づいて、追加で付与可能なソースシンボル数を計算する。

次に、重要シンボル補完部４５は、重要シンボル判定部４３より、複数のソースシンボルについてその重要度を示す情報を取得する（ステップＳｃ３）。

次に、重要シンボル補完部４５は、ステップＳｃ２で求めた追加で付与可能なソースシンボル数が０より大きいか否かについて判断する（ステップＳｃ４）。この判断の結果、追加で付与可能なソースシンボル数が０より大きい場合には（ステップＳｃ４：ＹＥＳ）、重要シンボル補完部４５はステップＳｃ５に進む。一方、この判断の結果、追加で付与可能なソースシンボル数が０である場合には（ステップＳｃ４：ＮＯ）、重要シンボル補完部４５は、本重要シンボル補完処理を終了する。

ステップＳｃ５において重要シンボル補完部４５は、実際に追加するソースシンボル数を計算する。ここで、実際に追加するソースシンボル数は、ステップＳｃ２で求めた追加で付与可能なソースシンボル数と、全ソースシンボル数（一のセグメントファイルから生成された全ソースシンボル数）のうちの小さい値となる。そして、重要シンボル補完部４５は、計算した数のソースシンボルを、ステップＳｃ３で取得した情報に示される重要度の順に選択して、FLUTEパケット生成部４６に送る（ステップＳｃ６）。その際、重要度の同じ複数のソースシンボルの中から１つを選択しなければならない場合には、重要シンボル補完部４５はランダムに選択してよい。

次に、重要シンボル補完部４５は、追加で付与可能なソースシンボル数を再計算する（ステップＳｃ７）。具体的には、重要シンボル補完部４５は、ステップＳｃ２で求めた追加で付与可能なソースシンボル数から、ステップＳｃ６でFLUTEパケット生成部４６に送ったソースシンボル数を減算することで、追加で付与可能なソースシンボル数を再計算する。その後、重要シンボル補完部４５はステップＳｃ４に戻り、追加で付与可能なソースシンボル数が零になるまでステップＳｃ５〜Ｓｃ７を繰り返す。

次に、FLUTEパケット生成部４６は、シンボル分割部４１により生成された各ソースシンボルと、FEC生成部４２により生成された各FECシンボルと、重要シンボル補完部４５から渡された各ソースシンボルに対してFLUTEヘッダを付与してFLUTEパケットを生成する。FLUTEヘッダは各シンボルに対して付与され、シンボル毎にFLUTEパケットが生成される。

UDPパケット生成部４７は、FLUTEパケット生成部４６により生成された各FLUTEパケットにUDP/IPヘッダを付与して複数のUDPパケットを生成する。

ULE部４８は、UDPパケット生成部４７により生成された各UDPパケットにULEヘッダとCRC32とを付与して複数のULEパケットを生成する。

TSパケット生成部４９は、ULE部４８により生成された各ULEパケットをTSパケットに分割する。

送信部５０は、シンボル分割部４１により生成された複数のソースシンボルを送信するとともに、重要シンボル補完部４５により選択された１以上のソースシンボルを、当該複数のソースシンボルの送信先からの要求を待たずに、追加的に当該送信先に送信する。具体的には、送信部５０は、TSパケット生成部４９により生成された複数のTSパケットを受信クライアント６に送信する。また、送信部５０は、セグメントファイル単位で、ＦＤＴ（File Delivery Table）を受信クライアント６に送信する。このＦＤＴには、受信クライアント６において復号のための検査行列を生成することができるように、乱数生成のための初期値を示す初期値と次数とが記述される。また、ＦＤＴには、セグメントファイルサイズと、IPビットレートと、セグメント間隔と、パケットサイズと、シンボルサイズと、FEC付与率とが記述される。

図１０は、受信クライアント６の機能ブロック図である。受信クライアント６は、TSパケット受信部６１と、ULE復号部６２と、UDPパケット復号部６３と、FLUTEパケット復号部６４と、FECデコード実施判定部６５と、重要シンボル判定部６６と、空き領域計算部６７と、追加シンボル判定部６８と、補完可能シンボル判定部６９と、補完可能シンボル選別部７０と、FECデコード部７１と、ソースブロック再構築部７２と、セグメントファイル再構築部７３と、映像再生部７４とを有する。これらの機能は、ＣＰＵ等の演算装置によりプログラムが実行されることにより実現される。この受信クライアント６は、本発明に係る「通信装置」の一例である。

TSパケット受信部６１は、配信サーバ４から送信されたTSパケットを受信する。このTSパケット受信部６１は、本発明に係る「受信部」の一例に相当し、TSパケット受信部６１は、コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとを受信する。

ULE復号部６２は、TSパケット受信部６１により受信された一連のTSパケット群のペイロード部分を結合してULEパケットを復元する（すなわち、ULEでカプセル化された情報を復元する）。

UDPパケット復号部６３は、ULE復号部６２により復元されたULEパケットに対してULEのデキャプスレーション処理（すなわち、カプセル化をほどく処理）を行い、UDPパケットを取り出す。

FLUTEパケット復号部６４は、UDPパケット復号部６３により取り出されたUDPパケットからFLUTEパケットを復元する。

FECデコード実施判定部６５は、FLUTEパケット復号部６４により復元されたFLUTEパケットを確認し、ソースシンボルの欠落の有無を判断することにより、FECデコードを実施すべきか否かについて判断する。また、FECデコード実施判定部６５は、本発明に係る「欠落シンボル特定部」の一例に相当し、複数のソースシンボルの伝送中にソースシンボルが欠落した場合に、当該欠落したソースシンボルを特定する。

ＦＤＴに記述されるセグメントファイルサイズとシンボルサイズから、ソースシンボルの総数を求めることができる。ソースシンボルのヘッダであるFLUTEヘッダには、各ソースシンボルの通番情報が入っている。したがって、FECデコード実施判定部６５は、ソースシンボルの総数の情報とソースシンボルの通番情報から欠落したソースシンボルの通番番号を特定することができる。なお、FECシンボルについては、ＦＤＴに記述されるセグメントファイルサイズとFEC付与率から、FECシンボルの総数がわかり、FECシンボルのFLUTEヘッダにはFECシンボルの通番情報が入っている。したがって、FECデコード実施判定部６５は、FECシンボルの総数の情報とFECシンボルの通番情報から欠落したFECシンボルの通番番号を特定することができる。

図１１は、FECデコード実施判定部６５により実行されるFECデコード実施判定処理の一例を示すフローチャートである。本処理のステップＳｄ１においてFECデコード実施判定部６５は、FLUTEパケット復号部６４から、受信したソースシンボルに関する情報を取得する。この情報の中には、例えば、全ソースシンボルを受信したかどうかを判定するために必要となる、受信したソースシンボルの合計数や、受信したソースシンボル各々の通番情報が含まれてもよい。次に、FECデコード実施判定部６５は、ステップＳｄ１で取得した情報に基づいて、全てのソースシンボルが受信されているか否かについて判断する（ステップＳｄ２）。具体的には、FECデコード実施判定部６５は、ソースシンボルの受信が終了し、FECシンボルの受信が開始されると（すなわち、１つのソースブロックを構成するソースシンボルの受信が完了すると）、当該ソースブロックを構成するソースブロックが全て受信されているか否かについて判断する。なお、ソースシンボルとFECシンボルの判別は、例えばFLUTEヘッダを参照することにより行われる。

この判断の結果、全てのソースシンボルが受信されている場合には（ステップＳｄ２：ＹＥＳ）、FECデコードは不要であるので、当該ソースシンボルの処理はソースブロック再構築部７２に移り（ステップＳｄ３）、本処理は終了する。一方、この判断の結果、全てのソースシンボルが受信されていない場合には（すなわち、１以上のソースシンボルが欠落している場合には）（ステップＳｄ２：ＮＯ）、FECデコードが必要であるので、FECデコード実施判定部６５は、処理対象となっているソースシンボル群に対応するFECシンボルを受信する（ステップＳｄ５）。これと同時に、後述する重要シンボル判定処理と空き領域計算処理とが並列して実行される（ステップＳｄ４）。

FECシンボルの受信開始後、FECデコード実施判定部６５は、FECデコードに必要な所定の閾値分以上のシンボル（ソースシンボル、FECシンボルの区別を問わず。）が受信されたか否かについて判断する（ステップＳｄ６）。なおここで、所定の閾値は、上述のFEC付与率に基づいて任意に設定されてよい。この判断の結果、所定の閾値分以上のシンボルが受信された場合には（ステップＳｄ６：ＹＥＳ）、本処理は終了する。一方、この判断の結果、所定の閾値分以上のシンボルが受信されていない場合には（ステップＳｄ６：ＮＯ）、FECデコード実施判定部６５は、全てのFECシンボルの送信が終了したか否かについて判断する（ステップＳｄ７）。具体的には、次のソースブロックの受信が開始されたか否かについて判断する。ここで、ソースシンボルとFECシンボルの判別は、上述のように、例えばFLUTEヘッダを参照することにより行われる。この判断の結果、全てのFECシンボルの送信が終了していない場合には（ステップＳｄ７：ＮＯ）、FECデコード実施判定部６５は、ステップＳｄ６を再び実行し、一方、全てのFECシンボルの送信が終了した場合には（ステップＳｄ７：ＹＥＳ）、本処理を終了する。
以上が、FECデコード実施判定処理についての説明である。

次に、重要シンボル判定部６６は、FECデコード実施判定部６５によりFECデコードが必要であると判断された場合に（図１１のステップＳｄ２：ＮＯ）、処理対象の各ソースシンボルについて重要度を判定する。ここで、FECデコードが必要と判断される場合とは、ソースシンボルの中で欠落しているものがある場合であり、全ソースシンボルを受信できた場合にはFECデコードは不要である。この重要シンボル判定部６６は、本発明に係る「判定部」の一例に相当し、複数のソースシンボルの各々について、当該複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合にそのコンテンツデータを復元する上での重要度を判定する。コンテンツデータを復元する上で重要なソースシンボルは、そのソースシンボルを受信できると、コンテンツデータを復元できる可能性が、他のソースシンボルを受信した場合よりも相対的に上昇するソースシンボルである。

図１２は、重要シンボル判定部６６により実行される重要シンボル判定処理の一例を示すフローチャートである。本処理のステップＳｅ１において重要シンボル判定部６６は、処理対象のソースシンボル群に対応する検査行列を取得する。具体的には、重要シンボル判定部６６は、配信サーバ４から受信されたＦＤＴに記述された乱数生成のための初期値及び次数と、所定の関数や規則（例えば、LDPC-staircaseで指定された規則）に基づいて左側検査行列を生成する。ここで参照されるＦＤＴは、処理対象のソースシンボル群により構成されるセグメントファイルに対応するＦＤＴである。また、重要シンボル判定部６６は、単位行列において、（ｉ，ｉ−１）（ただし、ｉは１以上の整数）の要素にも非零要素「１」が挿入することにより右側検査行列を生成する。

次に、重要シンボル判定部６６は、処理対象となる各ソースシンボルの重要度を計算する（ステップＳｅ２）。具体的には、重要シンボル判定部６６は、ステップＳｅ１において取得した検査行列に基づいて各ソースシンボルの重要度を計算する。ここで、重要度の計算方法は、上述の重要シンボル判定部４３と同様である（図７のステップＳａ２参照）。
重要シンボル判定部６６は、検査行列における一の列と他の列とを比較した場合に、一の列に含まれる非零要素の方が他の列よりも多いときには、その一の列に対応するソースシンボルの重要度の方を、その他の列に対応するソースシンボルよりも高く判定する。よって、仮に図６に示される検査行列がステップＳｅ１において取得された場合には、各ソースシンボルの重要度の順序は、「Ｓ３＞Ｓ４＞Ｓ６＞Ｓ１＝Ｓ２＝Ｓ５」のようになる。

各ソースシンボルについて重要度を計算すると、重要シンボル判定部６６は、ソースシンボル毎の重要度を示す情報を追加シンボル判定部６８に送る（ステップＳｅ３）。
以上が、重要シンボル判定処理についての説明である。

次に、空き領域計算部６７は、FECデコード実施判定部６５によりFECデコードが必要であると判断された場合に（図１１のステップＳｄ２：ＮＯ）、配信サーバ４から追加的にソースシンボルが送信されてくる空き領域を計算する。ここで、FECデコードが必要と判断される場合とは、ソースシンボルの中で欠落しているものがある場合であり、全ソースシンボルを受信できた場合にはFECデコードは不要である。この空き領域計算部６７は、本発明に係る「計算部」の一例に相当し、コンテンツデータが伝送される際の単位時間あたりのデータ量から、複数のソースシンボルの各々を含むパケットのデータ量の合計と、１以上のパリティシンボルの各々を含むパケットのデータ量の合計とを減算することにより得られるデータ量に基づいて、空きデータ量を計算する。ここで、コンテンツデータが伝送される際の単位時間あたりのデータ量とは、例えばデータ送信に割り当てられている伝送帯域である。この伝送帯域の情報は、コンテンツ伝送を開始する際の配信サーバ４と受信クライアント６間での手順の冒頭部分で、例えばメタデータとして配信サーバ４から受信クライアント６に通知されてもよい。

図１３は、空き領域計算部６７により実行される空き領域計算処理の一例を示すフローチャートである。本処理のステップＳｆ１において空き領域計算部６７は、配信サーバ４から受信されたＦＤＴに基づいて、セグメントファイルサイズと、IPビットレートと、セグメント間隔と、パケットサイズと、シンボルサイズと、FEC付与率とを特定する。ここで参照されるＦＤＴは、処理対象のソースシンボル群により構成されるセグメントファイルに対応するＦＤＴである。

次に、空き領域計算部６７は、ステップＳｆ１で特定した情報に基づいて空き領域を計算する（ステップＳｆ２）。空き領域の計算方法は空き領域計算部４４と同様であり（図８のステップＳｂ３参照）、次式により求められる。
空き領域（KB）＝IPビットレート（kbps）×セグメント間隔T（sec）÷8（bit）−（パケット数×パケットサイズ（KB））

空き領域を計算すると、空き領域計算部６７は、計算した空き領域を示す情報を追加シンボル判定部６８に送る（ステップＳｆ３）。
以上が、空き領域計算処理についての説明である。

次に、追加シンボル判定部６８は、FECデコード実施判定部６５によりFECデコードが必要であると判断された場合に（図１１のステップＳｄ２：ＮＯ）、配信サーバ４から追加的に送信されてくるソースシンボルを特定する。この追加シンボル判定部６８は、本発明に係る「追加シンボル特定部」の一例に相当し、重要シンボル判定部６６により複数のソースシンボルの各々について判定された重要度の順に、空き領域計算部６７により計算された空きデータ量に基づき、その複数のソースシンボルのうち追加的に送信されてくるソースシンボルを特定する。

図１４は、追加シンボル判定部６８により実行される追加シンボル判定処理の一例を示すフローチャートである。本処理のステップＳｇ１において追加シンボル判定部６８は、重要シンボル判定部６６より、処理対象となるソースシンボル群について各シンボルの重要度を示す情報を取得する。

次に、追加シンボル判定部６８は、空き領域計算部６７より、処理対象となるソースシンボル群について計算された空き領域を示す情報を取得する（ステップＳｇ２）。

次に、追加シンボル判定部６８は、ステップＳｇ２において取得した情報に基づいて、配信サーバ４から追加で送信されるソースシンボル数を計算する（ステップＳｇ３）。
このソースシンボル数の計算方法は、重要シンボル補完部４５と同様であり（図９のステップＳｃ２参照）、次式により求められる（なお、本実施形態では、シンボルサイズが固定されている場合を想定している）。
追加ソースシンボル数＝空き領域（KB）÷パケットサイズ（KB）（小数点以下切り下げ）

なお、本実施形態では、１つのセグメント間隔において１つのソースブロックを構成するソースシンボル群が送信される場合を想定しているため、追加シンボル判定部６８は、１つのセグメント間隔当たりの空き領域に基づいて、配信サーバ４から追加で送信されるソースシンボル数を計算している。しかし、仮に１つのセグメント間隔において複数のソースブロックを構成するソースシンボル群が送信される場合には、追加シンボル判定部６８は、ステップＳｇ２において取得した情報により示される空き領域を、当該複数のソースブロックの数で除算して求めた値に基づいて、追加で送信されるソースシンボル数を計算する。

次に、追加シンボル判定部６８は、ステップＳｇ１において取得した各ソースシンボルの重要度を示す情報と、ステップＳｇ３において計算した追加ソースシンボル数とに基づいて、配信サーバ４から追加で送信されるソースシンボルを特定する（ステップＳｇ４）。具体的には、追加シンボル判定部６８は、ステップＳｇ１において取得した情報に示される重要度の順に、ステップＳｇ３において計算した追加ソースシンボル数の分だけ、ソースシンボルを選択する。その際、追加シンボル判定部６８は、重要度の同じ複数のソースシンボルの中から１つを選択しなければならない場合には、シンボルＩＤの小さいソースシンボルを選択してもよい。例えば、各ソースシンボルの重要度の順序が「Ｓ３＞Ｓ４＞Ｓ２＞Ｓ１＝Ｓ５」であって、計算された追加ソースシンボル数が「４」である場合には、追加シンボル判定部６８は、ソースシンボル「Ｓ３」、「Ｓ４」、「Ｓ２」及び「Ｓ１」を選択する。

次に、追加シンボル判定部６８は、ステップＳｇ４において特定したソースシンボルの情報を補完可能シンボル判定部６９に送る（ステップＳｇ５）。
以上が、追加シンボル判定処理についての説明である。

次に、補完可能シンボル判定部６９は、FECデコード実施判定部６５により特定された欠落したソースシンボルの情報と、追加シンボル判定部６８より特定された、配信サーバ４から追加で送信されるソースシンボルの情報とに基づいて、欠落したソースシンボルのうち、追加的に送信されてくるソースシンボルにより補完可能なソースシンボルを特定する。この補完可能シンボル判定部６９は、本発明に係る「補完可能シンボル判定部」の一例であり、重要シンボル判定部６６により判定された重要度と、空き領域計算部６７により計算された空きデータ量とに基づいて、FECデコード実施判定部６５により特定されたソースシンボルが追加的に送信されてくるソースシンボルであるか否かを判定する。より具体的には、当該判定を、追加シンボル判定部６８により特定されたソースシンボルにFECデコード実施判定部６５により特定されたソースシンボルが含まれるか否かを判定することにより行う。

図１５は、補完可能シンボル判定部６９より実行される補完可能シンボル判定処理の一例を示すフローチャートである。本処理のステップＳｈ１において補完可能シンボル判定部６９は、FECデコード実施判定部６５より、処理対象となるソースシンボル群のうち伝送途中で欠落したソースシンボルの情報を取得する。

次に、補完可能シンボル判定部６９は、追加シンボル判定部６８より、配信サーバ４から追加で送信されるソースシンボルの情報を取得する（ステップＳｈ２）。

次に、補完可能シンボル判定部６９は、ステップＳｈ１において取得した情報と、ステップＳｈ２において取得した情報とに基づいて、欠落したソースシンボルのうち、配信サーバ４から追加で送信されるソースシンボルを特定する（ステップＳｈ３）。具体的には、補完可能シンボル判定部６９は、ステップＳｈ１において取得した情報に示される欠落したソースシンボルと、ステップＳｈ２において取得した情報に示される、配信サーバ４から追加で送信されるソースシンボルとを比較して、一致したソースシンボルを、補完可能なソースシンボルとして特定する。例えば、欠落したソースシンボルが「Ｓ１」、「Ｓ３」及び「Ｓ６」であり、配信サーバ４から追加で送信されるソースシンボルが「Ｓ３」、「Ｓ５」及び「Ｓ６」である場合には、補完可能シンボル判定部６９は、補完可能なソースシンボルとして、「Ｓ３」と「Ｓ６」とを特定する。

次に、補完可能シンボル判定部６９は、ステップＳｈ３において特定した補完可能なソースシンボルの情報を補完可能シンボル選別部７０に送る（ステップＳｈ４）。
以上が、補完可能シンボル判定処理についての説明である。

次に、補完可能シンボル選別部７０は、補完可能シンボル判定部６９による判定結果に基づいて、配信サーバ４から送信されてくるソースシンボルの受信を待ってからFECデコードを実行すべきか否かについて判断する。

図１６は、補完可能シンボル選別部７０より実行される補完可能シンボル選別処理の一例を示すフローチャートである。本処理のステップＳｉ１において補完可能シンボル選別部７０は、補完可能シンボル判定部６９より、処理対象のソースシンボル群について補完可能なソースシンボルの情報を取得する。

次に、補完可能シンボル選別部７０は、ステップＳｉ１において取得した情報に基づいて、補完可能なソースシンボルが存在するか否かについて判断する（ステップＳｉ２）。この判断の結果、補完可能なソースシンボルが存在しない場合には（ステップＳｉ２：ＮＯ）、補完可能シンボル選別部７０は本処理を終了する。一方、この判断の結果、補完可能なソースシンボルが存在する場合には（ステップＳｉ２：ＹＥＳ）、補完可能シンボル選別部７０は、補完可能なソースシンボルが全て受信されたか、又は配信サーバ４から追加で送信されるソースシンボルの受信が終了したかについて判断する（ステップＳｉ３）。ここで、後者の判断については、例えば、後続するセグメントファイルのＦＤＴパケットが受信されたか否かを判断することにより判断される。この判断は、追加的に送信されるソースシンボルも欠落する可能性があるため実行される。なお、ステップＳｉ２で参照される閾値は、「０」以外の任意の数であってもよい。

ステップＳｉ３の判断の結果、補完可能なソースシンボルが全て受信されておらず、且つ配信サーバ４から追加で送信されるソースシンボルの受信が終了していない場合には（ステップＳｉ３：ＮＯ）、補完可能シンボル選別部７０は待機する。一方、この判断の結果、補完可能なソースシンボルが全て受信されたか、又は配信サーバ４から追加で送信されるソースシンボルの受信が終了した場合には（ステップＳｉ３：ＹＥＳ）、補完可能シンボル選別部７０は本処理を終了する。

次に、FECデコード部７１は、FECデコード実施判定部６５によりソースシンボルの欠落が検出された場合に、FECデコードを実行する。その際、FECデコード部７１は、補完可能シンボル選別部７０により補完可能なソースシンボルが存在すると判断された場合には、そのソースシンボルの受信を待ってからFECデコードを実行する。なお、ソースシンボルを受信した結果、欠落したソースシンボルが全て補完された場合には、FECデコード部７１はFECデコードの実行を省略する。一方、補完可能シンボル選別部７０により補完可能なソースシンボルが存在しないと判断された場合には、配信サーバ４から追加で送信されるソースシンボルの受信を待たずにFECデコードを実行する。

FECデコードにおいてFECデコード部７１は、欠落したソースシンボルを、重要シンボル判定部６６により取得された検査行列（図１２のステップＳｅ１参照）に基づいて復元する。例えば、図６に示す検査行列を用いる場合において、ソースシンボル「Ｓ１」〜「Ｓ６」のうち「Ｓ１」及び「Ｓ６」が欠落し、且つFECシンボル「Ｐ３」が欠落した場合には、例えば、左側検査行列の第６行目の検査式「Ｓ１＋Ｓ３＋Ｓ４＋Ｐ５＋Ｐ６＝０」からソースシンボル「Ｓ１」を復元する。また、例えば、左側検査行列の第１行目の検査式「Ｓ１＋Ｓ４＋Ｓ６＋Ｐ１＝０」からソースシンボル「Ｓ６」を復元する。なお、これらの検査式で用いられている加算は全て排他的論理和である。

このFECデコード部７１は、本発明に係る「復号部」の一例に相当し、補完可能シンボル判定部６９により、FECデコード実施判定部６５により特定されたソースシンボルが追加的に送信されてくるソースシンボルであると判定された場合に（具体的には、追加シンボル判定部６８により特定されたソースシンボルにFECデコード実施判定部６５により特定されたソースシンボルが含まれる場合に）、FECデコード実施判定部６５により特定されたソースシンボルがTSパケット受信部６１により受信されるのを待ってから、コンテンツデータの復元を開始する。また、FECデコード部７１は、補完可能シンボル判定部６９により、FECデコード実施判定部６５により特定されたソースシンボルが追加的に送信されてくるソースシンボルではないと判定された場合に（具体的には、追加シンボル判定部６８により特定されたソースシンボルにFECデコード実施判定部６５により特定されたソースシンボルが含まれない場合に）、追加的に送信されてくるソースシンボルがTSパケット受信部６１により受信されるのを待たずに、コンテンツデータの復元を開始する。

ソースブロック再構築部７２は、FLUTEパケット復号部６４により復元された各FLUTEパケットからソースシンボルを復元し、復元されたソースシンボル群を、そのソースシンボルに付与されている識別番号に基づいて、ソースブロック内での並び順に並べてソースブロックを復元する。なお、ソースブロック再構築部７２は、FECデコード部７１により一部のソースシンボルが復元されている場合には、各FLUTEパケットから復元されたソースシンボルと、FECデコード部７１により復元されたソースシンボルとに基づいてソースブロックを復元する。

セグメントファイル再構築部７３は、ソースブロック再構築部７２により復元され複数のソースブロックを、そのソースブロックに付与されている識別番号に基づいて、セグメントファイル内での並び順に並べてセグメントファイルを復元する。

映像再生部７４は、セグメントファイル再構築部７３により復元されたセグメントファイル群を順次再生する。

以上説明した本実施形態に係るライブストリーミングシステム１によれば、セグメントファイルを構成するソースシンボルのうち、当該セグメントファイルの復元に重要なソースシンボルが重畳的に受信クライアント６に送信されるため、パケットロス耐性が向上する。換言すると、復元にあたっての重要度が高いソースシンボルを優先的に付加的に送信することにより、復元のロバスト性を高めることができる。また、その際、当該重要なソースシンボルは、空き領域を利用して重要度の順に選択され送信されるため、映像データのリアルタイム性が損なわれることはない。

また、本実施形態に係るライブストリーミングシステム１によれば、伝送中にソースシンボルが欠落した場合に、当該ソースシンボルの全部又は一部が配信サーバ４から追加的に送信されてくるか否かを予測し、その予測の結果、追加的に送信されてくることがわかった場合には、その追加的に送信されてくるソースシンボルについてはFECデコード処理が省略される。すなわち、FECデコードの処理負荷が軽減される。

より具体的に説明すると、現在、一定数以上のシンボルを受信するとFECシンボルを使って高い確率で復元が成功することを利用して、シンボル受信率が一定値以上になった場合に（まだ受信していないシンボルがあるにも関わらず）FECシンボルを使った復元処理を開始することが多い。しかし、電池消費量の観点では復元処理を実施せずに済む割合を増やした方が望ましい。そこで、ソースシンボルの受信の際に欠損が発生し、FECデコード（復元処理）が必要となった場合に、付加的に送信されるシンボルの到着を待つことで計算量を減らしている。

また、本実施形態に係るライブストリーミングシステム１によれば、上記の欠落ソースシンボルが追加的に送信されてくるか否かの予測の結果、追加的に送信されないことがわかった場合には、配信サーバ４から追加的に送信されてくるソースシンボルを待たずにFECデコード処理が実行されるため、ソースシンボルを待った場合のタイムロスが回避される。

２．変形例
上記の実施形態は、以下のように変形してもよい。また、以下の変形例は互いに組み合わせてもよい。

２−１．変形例１
上記の実施形態において重要シンボル判定部６６は、検査行列において一の列に含まれる非零要素の数と他の列に含まれる非零要素の数とが等しい場合であって、その一の列に対応するソースシンボルの方がその他の列に対応するソースシンボルよりも古いデータであるときには、その一の列に対応するソースシンボルの重要度の方を、その他の列に対応するシースシンボルよりも高く判定するようにしてもよい。これは、古いソースシンボルの方が早く再生されるため、早く受信クライアント６に到達した方がよいからである。

２−２．変形例２
上記の実施形態において追加シンボル判定部６８は、重要シンボル判定部６６により判定された重要度が閾値以上であるソースシンボルの中から、重要シンボル判定部６６により複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを選択するようにしてもよい。より具体的には、追加シンボル判定部６８は、検査行列において、対応する列内の非零要素の数が閾値以上であるソースシンボルの中から、ソースシンボルを選択するようにしてもよい。ここで、当該閾値は、例えば、セグメントファイルのサイズに基づいて決定されてもよい。

２−３．変形例３
上記の実施形態において、FECデコード実施判定部６５により特定された欠落したソースシンボルについてのみ重要度の判定を行い、この重要度と所定の閾値との比較に基づいて、当該ソースシンボルが追加的に送信されてくるか否かを判定するようにしてもよい。

本変形例が採用された場合、重要シンボル判定部６６は、上記の重要シンボル判定処理のＳｅ２において、FECデコード実施判定部６５により特定された欠落したソースシンボルの重要度を判定する。また、受信クライアント６は、追加シンボル判定部６８に代えて、重要度閾値判定部を有する。重要度閾値判定部は、空き領域計算部６７より、処理対象となるソースシンボル群について計算された空き領域を示す情報を取得して、この情報に基づいて重要度閾値を特定する。重要度閾値判定部は、例えば、空き領域の大きさが大きいほど低い値、空き領域の大きさが小さいほど高い値となるよう、予め定めたテーブルや閾値算出式を用いて重要度閾値を特定する。

また、補完可能シンボル判定部６９は、上記の補完可能シンボル判定処理の実行に代えて、FECデコード実施判定部６５により特定された欠落したソースシンボルの各々について、その重要度と、重要度閾値判定部により特定された重要度閾値とを比較することにより、欠落したソースシンボルのうち、追加的に送信されてくるソースシンボルにより補完可能なソースシンボルを特定する。補完可能シンボル判定部６９は、例えば、重要度閾値を超える重要度のソースシンボルを、補完可能なソースシンボルとして特定する。そして、補完可能シンボル判定部６９は、特定した補完可能なソースシンボルの情報を補完可能シンボル選別部７０に送る。以降の処理は上記の実施形態の通りである。

２−４．変形例４
上記の実施形態又は変形例に係る受信クライアント６において実行されるプログラムは、コンピュータ装置が読み取り可能な記録媒体を介して提供されてもよい。ここで、記録媒体とは、例えば、磁気テープや磁気ディスクなどの磁気記録媒体や、光ディスクなどの光記録媒体や、光磁気記録媒体や、半導体メモリ等である。また、このプログラムは、インターネット等のネットワークを介して提供されてもよい。

２−５．変形例５
上記の実施形態は、映像データがリアルタイムで再生されるライブストリーミングシステムに本発明を適用した場合の例であるが、本発明は、必ずしもストリーミング方式のシステムに適用されなくてもよい。例えば、マルチメディアファイルがダウンロードされてから再生されるシステムに適用されてもよい。

２−６．変形例６
上記の実施形態では空き領域計算部６７において空き領域（KB）が算出されているが、空き領域計算部６７において算出される値は空き領域に限られない。空き領域計算部６７は空き帯域（kbps）を算出して追加シンボル判定部６８に渡し、追加シンボル判定部６８はセグメント間隔T（sec）に基づいて空き帯域から空き領域を算出し、この空き領域に基づいて追加シンボル判定処理を実行するようにしてもよい。

１…ライブストリーミングシステム、２…ビデオカメラ、３…エンコーダ、４…配信サーバ、５…無線ＬＡＮ、６…受信クライアント、２１…映像撮影部、３１…映像分割部、３２…映像圧縮部、４１…シンボル分割部、４２…FEC生成部、４３…重要シンボル判定部、４４…空き領域計算部、４５…重要シンボル補完部、４６…FLUTEパケット生成部、４７…UDPパケット生成部、４８…ULE部、４９…TSパケット生成部、５０…送信部、６１…TSパケット受信部、６２…ULE復号部、６３…UDPパケット復号部、６４…FLUTEパケット復号部、６５…FECデコード実施判定部、６６…重要シンボル判定部、６７…空き領域計算部、６８…追加シンボル判定部、６９…補完可能シンボル判定部、７０…補完可能シンボル選別部、７１…FECデコード部、７２…ソースブロック再構築部、７３…セグメントファイル再構築部、７４…映像再生部

Claims (8)

1. コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとを受信する受信部と、
   前記複数のソースシンボルのうち、欠落したソースシンボルを特定する欠落シンボル特定部と、
   前記欠落シンボル特定部により特定されたソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定する判定部と、
   前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算する計算部と、
   前記判定部により判定された重要度と、前記計算部により計算された空きデータ量とに基づいて、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるか否かを判定する補完可能シンボル判定部と、
   前記補完可能シンボル判定部により、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが前記受信部により受信されるのを待ってから、前記コンテンツデータの復元を開始する復号部と
   を備える通信装置。
2. 前記判定部は、前記複数のソースシンボルの各々について、前記コンテンツデータを復元する上での重要度を判定し、
   前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に、前記計算部により計算された空きデータ量に基づき、前記複数のソースシンボルのうち追加的に送信されてくるソースシンボルを特定する追加シンボル特定部をさらに備え、
   前記補完可能シンボル判定部は、前記追加シンボル特定部により特定されたソースシンボルに前記欠落シンボル特定部により特定されたソースシンボルが含まれるか否かを判定することにより、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるソースシンボルであるか否かを判定する
   ことを特徴とする請求項１に記載の通信装置。
3. 前記復号部は、前記補完可能シンボル判定部により、前記欠落シンボル特定部により特定されたソースシンボルが追加的に送信されてくるソースシンボルではないと判定された場合には、当該ソースシンボルが前記受信部により受信されるのを待たずに、前記コンテンツデータの復元を開始することを特徴とする請求項１又は２に記載の通信装置。
4. 前記復号部は、検査行列に基づいて前記コンテンツデータを復元し、
   前記判定部は、前記検査行列における一の列と他の列とを比較した場合に、前記一の列に含まれる非零要素の方が前記他の列よりも多いときには、前記一の列に対応するソースシンボルの重要度の方を、前記他の列に対応するソースシンボルよりも高く判定する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記判定部は、前記検査行列において前記一の列に含まれる非零要素の数と前記他の列に含まれる非零要素の数とが等しい場合であって、前記一の列に対応するソースシンボルの方が前記他の列に対応するソースシンボルよりも古いデータであるときには、前記一の列に対応するソースシンボルの重要度の方を、前記他の列に対応するシースシンボルよりも高く判定することを特徴とする請求項４に記載の通信装置。
6. 前記追加シンボル特定部は、前記判定部により判定された重要度が閾値以上であるソースシンボルの中から、前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを特定し、
   前記閾値は、前記コンテンツデータのデータ量に基づいて決定される
   ことを特徴とする請求項２に記載の通信装置。
7. コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとが送信元から送信された場合に、前記複数のソースシンボルのうち、欠落したソースシンボルを特定するステップと、
   前記特定したソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定するステップと、
   前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算するステップと、
   前記判定された重要度と、前記計算された空きデータ量とに基づいて、前記欠落したソースシンボルが追加的に送信されてくるか否かを判定するステップと、
   前記欠落したソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが受信されるのを待ってから、前記コンテンツデータの復元を開始するステップと
   を有する通信方法。
8. コンピュータに、
   コンテンツデータを分割することにより生成された複数のソースシンボルと、当該複数のソースシンボルに基づいて生成された１以上のパリティシンボルとが送信元から送信された場合に、前記複数のソースシンボルのうち、欠落したソースシンボルを特定するステップと、
   前記特定したソースシンボルについて、前記コンテンツデータを復元する上での重要度を判定するステップと、
   前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルと前記１以上のパリティシンボルのデータ量の合計を減算することにより得られるデータ量に基づいて、空きデータ量を計算するステップと、
   前記判定された重要度と、前記計算された空きデータ量とに基づいて、前記欠落したソースシンボルが追加的に送信されてくるか否かを判定するステップと、
   前記欠落したソースシンボルが追加的に送信されてくると判定された場合に、当該ソースシンボルが受信されるのを待ってから、前記コンテンツデータの復元を開始するステップと
   を実行させるためのプログラム。

Images