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

Abstract

【課題】コンテンツデータを伝送する際の当該コンテンツデータを構成するソースシンボルの欠落に対する耐性を高める。【解決手段】配信サーバ４のシンボル分割部４１は、セグメントファイルを分割して複数のソースシンボルを生成する。重要シンボル判定部４３は、生成された複数のソースシンボルの各々について、他のソースシンボルが伝送中に欠落した場合にセグメントファイルを復元する上での重要度を判定する。重要シンボル補完部４５は、重要シンボル判定部４３により判定された重要度の順にソースシンボルを選択する。送信部５０は、生成された複数のソースシンボルを送信するとともに、重要シンボル補完部４５により選択されたソースシンボルを送信する。【選択図】図５

Description

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

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

特表２０１２−５３１８７２号公報 特開２０１０−１２４４０１号公報

本発明は、このような事情に鑑みてなされたものであり、コンテンツデータを伝送する際の当該コンテンツデータを構成するソースシンボルの欠落に対する耐性を高めることを目的とする。

上記の課題を解決するため、本発明は、コンテンツデータを分割して複数のソースシンボルを生成する分割部と、前記分割部により生成された複数のソースシンボルの各々について、当該複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合に前記コンテンツデータを復元する上での重要度を判定する判定部と、前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを選択する選択部と、前記分割部により生成された複数のソースシンボルを送信するとともに、前記選択部により選択された１以上のソースシンボルを、前記複数のソースシンボルの送信先からの要求を待たずに、追加的に前記送信先に送信する送信部とを備える通信装置を提供する。

好ましい態様において、前記分割部により生成された複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合には、前記コンテンツデータは検査行列に基づいて復元され、前記判定部は、前記検査行列における一の列と他の列とを比較した場合に、前記一の列に含まれる非零要素の方が前記他の列よりも多いときには、前記一の列に対応するソースシンボルの重要度の方を、前記他の列に対応するソースシンボルよりも高く判定する。

さらに好ましい態様において、前記通信装置は、前記分割部により生成された複数のソースシンボルに基づいて１以上のパリティシンボルを生成する生成部と、前記コンテンツデータが伝送される際の単位時間あたりのデータ量から、前記複数のソースシンボルの各々を含むパケットのデータ量の合計と、前記１以上のパリティシンボルの各々を含むパケットのデータ量の合計とを減算することにより得られるデータ量に基づいて、前記選択部により選択されるソースシンボルのデータ量上限を計算する計算部とをさらに備え、前記選択部は、前記判定部により前記複数のソースシンボルの各々について判定された重要度の順に、前記計算部により計算されたデータ量上限に基づきソースシンボルを選択する。

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

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

また、本発明は、コンテンツデータを分割して複数のソースシンボルを生成するステップと、前記生成された複数のソースシンボルの各々について、当該複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合に前記コンテンツデータを復元する上での重要度を判定するステップと、前記複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを選択するステップと、前記生成された複数のソースシンボルを送信するとともに、前記選択された１以上のソースシンボルを、前記複数のソースシンボルの送信先からの要求を待たずに、追加的に前記送信先に送信するステップとを有する通信方法を提供する。

また、本発明は、コンピュータに、コンテンツデータを分割して複数のソースシンボルを生成するステップと、前記生成された複数のソースシンボルの各々について、当該複数のソースシンボルのうち１以上のソースシンボルが伝送中に欠落した場合に前記コンテンツデータを復元する上での重要度を判定するステップと、前記複数のソースシンボルの各々について判定された重要度の順に１以上のソースシンボルを選択するステップと、前記生成された複数のソースシンボルを送信するとともに、前記選択された１以上のソースシンボルを、前記複数のソースシンボルの送信先からの要求を待たずに、追加的に前記送信先に送信するステップとを実行させるためのプログラムを提供する。

本発明によれば、コンテンツデータを伝送する際の当該コンテンツデータを構成するソースシンボルの欠落に対する耐性を高めることができる。

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

１．実施形態
図１は、本発明の一実施形態に係るライブストリーミングシステム１の構成の一例を示す図である。同図に示されるように、ライブストリーミングシステム１は、ビデオカメラ２と、エンコーダ３と、配信サーバ４と、無線ＬＡＮ（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: 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パケットを復元する（処理１３）。具体的には、受信クライアント６は、ソースシンボル群を、例えばソースシンボルに付与されている識別番号を用いてソースブロック内での並び順に並べてソースブロックを復元し、その後、例えばソースブロックに付与されている識別番号を用いてソースブロックをセグメントファイル内での並び順に並べてセグメントファイルを復元する。

次に、受信クライアント６は、復元されたFLUTEパケットからソースシンボルを復元する（処理１４）。次に、受信クライアント６は、復元されたソースシンボル群からセグメントファイルを復元する（処理１５）。そして、受信クライアント６は、復元されたセグメントファイル群を順次再生する（処理１６）。

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

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

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

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

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

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

シンボル分割部４１は、エンコーダ３から出力されたセグメントファイルを複数のソースブロックに分割した上で、各ソースブロックを複数のソースシンボルに分割する。シンボル分割部４１は、本発明に係る「分割部」の一例である。なお、セグメントファイルは、本発明に係る「コンテンツデータ」の一例である。

FEC生成部４２は、シンボル分割部４１により生成された複数のソースシンボルに基づいて１以上の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パケットを受信クライアント６に送信する。また、送信部５０は、受信クライアント６において復号のための検査行列を生成することができるように、乱数生成のための初期値を示す初期値情報を受信クライアント６に送信する。
なお、配信サーバ４は、例えばシンボル送信の前に送信部５０を介して、これから送信するシンボル用の左側検査行列の生成に用いた乱数と次数とを示す情報を受信クライアント６に送信することとしてもよい。

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

また、本実施形態に係るライブストリーミングシステム１によれば、重要シンボル補完部４５により選択された、送信すべき情報（ソースシンボル及びFECシンボル）は、そのデータ量と、配信サーバ４において予め指定された帯域との間に差（空き、余り）が生じた場合に、復元に重要となるソースシンボルから順に送信されるため、受信クライアント６からの「要求を待たずに」、つまり配信サーバ４から受信クライアント６への片方向の通信形態を保ちつつ、重要シンボルを追加的に送信できることができる。

上記の特許文献１に記載の技術では、冗長符号を余剰帯域幅で搬送することで、パケットロスが発生する環境でもデータを復元できる可能性を向上させているが、元のデータの信号が大量に欠けてしまうと、冗長符号のみでは元のデータを復元することは難しい。これに対して、上記の本実施形態に係るライブストリーミングシステム１によれば、ソースシンボル（しかも、セグメントファイルの復元に重要なソースシンボル）が重畳的に受信クライアント６に送信されるため、特許文献１に記載の技術と比較してパケットロス耐性が向上する。

また、上記の特許文献２に記載の技術では、時間的に早い時刻に対応するデータが重要とのヒューリスティックを用いて、時間的に早い時刻に対応するデータに誤り訂正を強くかけているが、時間的に早い時刻に対応するデータが常に重要なデータであるとは限らない。また、当該技術では、誤り訂正を強くかけたデータの再生中に、欠落したデータを再送により取得することを想定しているため、リアルタイム性が求められるアプリケーションには適さない。これに対して、上記の本実施形態に係るライブストリーミングシステム１によれば、セグメントファイルの復元に重要なソースシンボルが判定され、当該ソースシンボルが重畳的に受信クライアント６に送信される。そのため、特許文献２に記載の技術と比較してパケットロス耐性が向上する。また、上記の本実施形態に係るライブストリーミングシステム１では完全片方向でデータ伝送を行うことを前提としており、かつ上記の重要なソースシンボルは、空き領域を利用して重要度の順に選択され送信される。そのため、特許文献２に記載の技術と比較して、リアルタイム性が求められるアプリケーションにも適する。

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

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

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

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

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

２−５．変形例５
上記の実施形態に係る重要シンボル補完処理（図９参照）では、シンボルのデータサイズが固定されている場合を想定しているが、当該データサイズは必ずしも固定されている必要はない。シンボルのデータサイズが固定されていない場合には、重要シンボル補完部４５は、重要度の順に空き領域にシンボルを追加可能かどうかを判定し、追加できる場合には追加可能となったシンボルのデータサイズに応じたサイズだけ空き領域を減算する処理を繰り返すことで、空き領域に入る分だけ重要度の順にシンボルを詰めていく処理を行ってもよい。

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

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

Claims (7)

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

Images