コンテンツ配信システム、受信装置及び再生プログラム
【課題】バッファリングによる遅延を抑制でき、かつ、パケットロスによるコンテンツデータの抜けも抑制できるコンテンツ配信システムを提供する。
【解決手段】
受信装置１内の制御部１３は、ＦＥＣブロックを構成するパケットを受信バッファ１２に格納するごとに、パケットロスの有無を判断する。そして、パケットロスがなければ、格納されたパケットのデータブロックを再生バッファ１９に渡す。一方、パケットロスが発生していれば、再生バッファ１９に格納されているデータ量と、ＦＥＣブロックのうち受信装置１が今後受信する予定のパケット（未到着パケット）のデータ量とに基づいて、ロスパケットを復元するか否かを決める。復元する場合、未到着パケットを全て受信バッファ１２に格納した後、ロスパケットを復元し、復元されたロスパケット以降のパケットのデータブロックを順次再生バッファ１９に渡す。
【解決手段】
受信装置１内の制御部１３は、ＦＥＣブロックを構成するパケットを受信バッファ１２に格納するごとに、パケットロスの有無を判断する。そして、パケットロスがなければ、格納されたパケットのデータブロックを再生バッファ１９に渡す。一方、パケットロスが発生していれば、再生バッファ１９に格納されているデータ量と、ＦＥＣブロックのうち受信装置１が今後受信する予定のパケット（未到着パケット）のデータ量とに基づいて、ロスパケットを復元するか否かを決める。復元する場合、未到着パケットを全て受信バッファ１２に格納した後、ロスパケットを復元し、復元されたロスパケット以降のパケットのデータブロックを順次再生バッファ１９に渡す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システム、受信装置及び再生プログラムに関し、さらに詳しくは、コンテンツデータをパケット化及び冗長符号化してＦＥＣ（Forward Error Correction）ブロックを生成し、生成されたＦＥＣブロックを配信する送信装置と、ＦＥＣブロックを構成する複数のパケットを順次受信する受信装置とを備えたコンテンツ配信システム、そのコンテンツ配信システムを構成する受信装置及び受信装置に実装される再生プログラムに関する。
【背景技術】
【０００２】
近年、音声データや映像データ等のコンテンツデータをインターネットプロトコル（ＩＰ）を利用してネットワーク上でストリーミング配信するサービスが登場している。ストリーミング配信では、送信装置が、コンテンツデータをパケット化して複数のデータパケットを生成し、再生時間順にデータパケットを順次配信する。そして、受信装置がデータパケットを順次受信して再生する。
【０００３】
上述のストリーミング型伝送方式ではしばしばパケットロスが発生する。パケットロスとは、コンテンツデータを構成する複数のデータパケットのうち１又は複数のデータパケットが受信装置に届かないことをいう。このようなロスしたデータパケット（以下、ロスパケットという）を受信装置側で復元する技術として、前方誤り訂正（Forward Error Correction：以下、ＦＥＣという）がある。ＦＥＣでは、送信装置が複数のデータパケットを再生時間順に所定数ごとにグループ化する。そして、同じグループに属するデータパケットに対してＲＳ（Reed Solomon）符号やハミング（Hamming）符号等の誤り訂正符号を用いて冗長符号化し、グループごとに冗長パケットを生成する。送信装置は、グループ内の複数のデータパケットと、対応する冗長パケットとを１つのＦＥＣブロックとし、ＦＥＣブロックのデータパケット及び冗長パケットを順次送信する。
【０００４】
受信装置は、ＦＥＣブロック内の複数のパケット（データパケット及び冗長パケット）をバッファに格納する。そして、１つのＦＥＣブロック内の全てのパケットをバッファに格納した後、データパケット内のデータブロックを再生時間順に順次抽出してデコードする。データブロックはコンテンツデータの一部を構成するデータであり、受信装置はデータブロックを順次デコードすることでコンテンツを再生できる。さらに、ＦＥＣブロック内でパケットロスが発生した場合、つまり、受信装置がＦＥＣブロック内の一部のデータパケットを受信できなかった場合、受信装置は、同じＦＥＣブロックに属する他のデータパケット及び冗長パケットを用いてロスパケットを復元できる。つまり、送信装置にロスパケットの再送を要求することなく、受信装置でロスパケットを復元できる。
【０００５】
しかしながら、受信装置は、ＦＥＣブロックを構成する全てのパケットを受信した後でなければ、各データパケットのデータブロックを抽出して再生することができない。そのため、ＦＥＣブロック内にパケットロスが発生していない場合であっても、ＦＥＣブロック内の全てのパケットを受け取った後、データブロックが順次抽出される。ＦＥＣブロック内の複数のパケットのバッファリングにはある程度の時間が必要であるため、バッファリングに起因した遅延が発生する。
【０００６】
このようなＦＥＣ処理に起因した遅延を抑制するために、特開２００８−１６０４９９号公報では、転送データのデータレートに応じてパケットサイズを変更する技術が開示されている。しかしながら、パケットサイズを小さくしても、ＦＥＣブロック内の全てのパケットをバッファに格納する必要があるため、ある程度の遅延が発生する。
【特許文献１】特開２００８−１６０４９９号公報
【特許文献２】特開２００１−１８４８０８号公報
【特許文献３】特許第３７１５３３２号
【特許文献４】特表２００６−５２０９５４号公報
【特許文献５】特開２００６−１７８９８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、バッファリングによる遅延を抑制でき、かつ、パケットロスによるコンテンツデータの抜けも抑制できるコンテンツ配信システム及び受信装置を提供することである。
【課題を解決するための手段及び発明の効果】
【０００８】
本発明によるコンテンツ配信システムは、送信装置と、受信装置とを備える。送信装置は、ブロック生成手段と、送信手段とを備える。ブロック生成手段は、コンテンツデータをパケット化及び冗長符号化し、複数のＦＥＣ（Forward Error Correction)ブロックを生成する。ＦＥＣブロックは、コンテンツデータを分割した複数のデータブロックを含むデータパケットと冗長パケットとを含む。送信手段は、ＦＥＣブロックを構成する複数のパケットを順次送信する。受信装置は、受信手段と、受信バッファ手段と、再生バッファ手段と、再生手段と、パケットロス判断手段と、検知手段と、復元判断手段と、復元手段と、データ抽出手段とを備える。受信手段は、送信装置から送信されたパケットを受信する。受信バッファ手段は、受信手段により受信されたパケットを格納する。再生バッファ手段は、受信バッファ手段に格納されたデータパケットから抽出されたデータブロックを格納する。再生手段は、再生バッファ手段に格納された順に、データブロックを再生する。パケットロス判断手段は、パケットが受信バッファ手段に格納されるごとに、格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断する。検知手段は、再生バッファ手段に格納されているデータブロックのデータ量を検知する。復元判断手段は、パケットロスが発生したとき、再生バッファ手段のデータ量と、ＦＥＣブロック内のパケットのうち受信バッファ手段に格納されたパケット以降に受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する。復元手段は、ロスパケットを復元するとき、ＦＥＣブロックのロスパケット以外の他のパケットが受信バッファ手段に格納された後、他のパケットを用いてロスパケットを復元する。データ抽出手段は、パケットロスが発生していないとき、及び、ロスパケットを復元しないとき、受信バッファ手段に格納されたデータパケットのデータブロックを抽出して再生バッファ手段に出力する。また、ロスパケットを復元するとき、ロスパケットを復元した後、復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して再生バッファ手段に出力する。
【０００９】
本発明によるコンテンツ配信システムでは、受信装置は、パケットロスが発生していなければ、データパケットを受信バッファ手段に格納するごとに、格納されたデータパケットからデータブロックを抽出して再生する。そのため、従来のＦＥＣ処理のようなバッファリングによる遅延の発生を抑制できる。
【００１０】
また、受信装置は、パケットロスが発生している場合、再生バッファ手段が格納しているデータ量と、受信装置が受け取る予定のＦＥＣブロックの残りのパケット（以下、未到達パケットという）のデータ量とに基づいて、ロスパケットを復元するか否かを決める。そのため、パケットロスによるコンテンツの部分的な抜けを抑制でき、仮に、コンテンツの部分的な抜けが生じても、再生の中断時間を抑制できる。
【００１１】
好ましくは、受信装置はさらに、パケット消去手段を備える。パケット消去手段は、受信手段により受信されたパケットの属するＦＥＣブロックが受信バッファ手段に格納されているパケットの属するＦＥＣブロックと異なるとき、受信バッファ手段に格納されたパケットを消去する。
【００１２】
これにより、受信バッファ手段はＦＥＣブロック単位で複数のパケットを保持でき、異なるＦＥＣブロックのパケットが混在して格納されるのを防止できる。
【００１３】
好ましくは、受信装置はさらに、データブロック消去手段を備える。データブロック消去手段は、新たなコンテンツデータの再生指示を受けたとき、再生バッファ手段に格納されているデータブロックを消去する。
【００１４】
好ましくは、復元手段はさらに、検知手段により検知されたデータ量が基準値未満の場合、ロスパケットを復元しない。
【００１５】
たとえば、コンテンツデータの再生指示を受ければ、再生バッファ手段はリセットされるため、再生バッファ手段のデータ量は基準値未満となる。そのため、復元手段はロスパケットを復元せず、受信バッファ手段にデータパケットが格納されるごとに、データブロックを抽出して再生する。したがって、新たなコンテンツデータの再生指示を受けたとき、バッファリングによる遅延の発生を抑制でき、新たなコンテンツデータの再生を迅速に開始できる。
【００１６】
本発明による受信装置は、上述のコンテンツ配信システムに利用される。また、本発明による再生プログラムは、上述の受信装置内に格納されることにより、受信装置に上述の手段を実現させる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【００１８】
［全体構成］
図１に本実施の形態によるコンテンツ配信システムの機能ブロック図を示す。コンテンツ配信システムは、送信装置１００と受信装置１とを備える。受信装置１は送信装置１００とネットワークを介して接続される。送信装置１００は、映像データや音声データといったコンテンツデータを図示しないハードディスクドライブに蓄積する。以降の説明では、一例として、コンテンツデータを音声データとする。送信装置１００は、コンテンツデータをＦＥＣ符号化処理し、ＦＥＣ符号化されたコンテンツデータをストリーム配信する。受信装置１は、ストリーム配信されたコンテンツデータを順次受け取り、ＦＥＣ復号化して再生する。
【００１９】
［送信装置］
受信装置１の詳細を説明する前に、送信装置１００について説明する。送信装置１００は、ＦＥＣブロック生成部１０１と、通信部１０２とを備える。ＦＥＣブロック生成部１０１は、圧縮符号化されたコンテンツデータをパケット化して複数のパケットを生成する。具体的には、コンテンツデータを所定のデータ長の複数のデータブロックに分割する。そして、分割されたデータブロックにパケットヘッダを付与してデータパケットを生成する。パケットヘッダはデータブロックの位置情報を含む。位置情報は、データブロックのコンテンツデータにおける再生位置を示す。位置情報はたとえば、タイムスタンプである。
【００２０】
ＦＥＣブロック生成部１０１はさらに、再生位置順に配列されたＫ個のデータパケットを１つのグループとし、グループ化された複数のデータパケットに対して冗長符号化処理を実行する。冗長符号化処理は、たとえば、ＲＳ符号等の公知の誤り訂正符号を用いる。冗長符号化処理により、Ｎ−Ｋ個（Ｎ＞Ｋ）の冗長パケットが生成される。
【００２１】
送信装置１００は、グループ化したＫ個の分割パケットとＮ−Ｋ個の冗長パケットとを１つのＦＥＣブロックとして定義する。つまり、１つのＦＥＣブロックは、図２に示すとおり、Ｋ個のデータパケットとＮ−Ｋ個の冗長パケットとを含む。
【００２２】
パケットロスが発生している場合、受信装置１は、１つのＦＥＣブロックを構成するロスパケット以外の全てのパケットを受信した後、ＦＥＣ復号処理を実行する。このとき受信装置１は、１つのＦＥＣブロックを構成するＮ個のパケットのうち、Ｋ個のパケット（冗長パケットを含む）を受信していれば、全てのデータパケット（つまりＫ個）を復元することができる。
【００２３】
以降の説明では説明を容易にするために、一例として、Ｎ＝１０とし、Ｋ＝９とする。つまり、１つのＦＥＣブロックは、９個のデータパケットと、１個の冗長パケットとからなる。以降、１つのＦＥＣブロックを構成する１０個のパケット（データパケット及び冗長パケット）をパケットＰＴｎ（ｎ＝１〜１０）と称する。
【００２４】
図３にＦＥＣブロックを構成する各パケットＰＴｎ（ｎ＝１〜１０）のデータ構造を示す。パケットＰＴｎは、ヘッダ情報とペイロードとを含む。ペイロードには、データパケット又は冗長パケットが含まれる。ヘッダ情報は、ＦＥＣブロックＩＤと、位置情報とを含む。ＦＥＣブロックＩＤがそのパケットＰＴｎが属するＦＥＣブロックの識別子である。位置情報は、ＦＥＣブロック内でのパケットＰＴｎの配列位置を示す。本例では、位置情報は、ＦＥＣブロック内での先頭からの配列番号とする。図２に示すとおり、データパケットは、再生位置順に、ＦＥＣブロックの先頭から順に配列される。そして、データパケットの後に冗長パケットが配列される。したがって、ＦＥＣブロックの末尾のパケットＰＴ１０は冗長パケットである。本例では、パケットＰＴｎの配列番号は、ＦＥＣブロックの先頭から順に、１、２、３…と付与される。なお、位置情報は配列番号ではなく、たとえばＦＥＣブロックの先頭からのオフセットでもよい。
【００２５】
送信装置１００内の通信部１０２は、生成した複数のＦＥＣブロックを構成する複数のパケットを順次送信する。具体的には、あるＦＥＣブロックのパケットＰＴ１〜ＰＴ１０を先頭から順に送信する。送信が完了したのち、次のＦＥＣブロックのパケットを順次配信する。
【００２６】
本実施の形態による送信装置１００はインターリーブ処理を実行しない。そのため、パケットＰＴ１〜ＰＴ９に相当するデータパケットは、再生位置順に配列されており、再生位置順に順次送信される。
【００２７】
［受信装置］
次に、受信装置１について説明する。受信装置１は、通信部１０と、受付部１１と、受信バッファ１２と、制御部１３と、再生バッファ１９と、検知部２０と、再生部２１とを備える。
【００２８】
通信部１０は、送信装置１００から送信されるパケットを順次受信し、受信バッファ１２に渡す。受付部１１は、ユーザ所望のコンテンツデータの再生指示を受け付ける。通信部１０は、受付部１１が再生指示を受けたとき、所望のコンテンツデータのストリーミング配信要求を送信装置１００に送信する。送信装置１００は、新たなコンテンツデータのストリーミング配信要求を受けたとき、現在配信中のコンテンツデータのストリーミング配信を中止し、新たなコンテンツデータのストリーミング配信を開始する。
【００２９】
受信バッファ１２は、通信部１０から順次渡されるパケットＰＴｎを順次格納する。受信バッファ１２は、１つのＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０を格納できる容量を少なくとも有する。つまり、受信バッファ１２は、同じＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０を格納できる。
【００３０】
再生バッファ１９は、受信バッファ１２に格納されたパケットＰＴｎから抽出されたデータブロックを順次格納する。このとき、再生バッファ１９は、データブロックを再生位置順に順次格納する。再生部２１は、再生バッファ１９に格納されたデータブロックを格納時期が古い順に順次読み出す。データブロックは圧縮符号化されているため、再生部２１はデータブロックをデコードして出力する。これにより、データブロックは再生位置順にデコードされる。再生部２１から出力されたデータは、図示しないＤ／Ａ変換回路によりアナログ信号となり、図示しない出力端子を介して外部に出力される。出力された信号は図示しないスピーカにより音声として出力される。
【００３１】
検知部２０は、所定時間毎に、再生バッファ１９に格納されているデータブロックのデータ量（以下、バッファ量という）を検知する。
【００３２】
制御部１３は、パケットＰＴｎからのデータブロックの抽出処理と、ＦＥＣ復号処理とを実行する。制御部１３は、復元部１４と、パケットロス判断部１５と、復元判断部１６と、データ抽出部１７と、データ消去部１８とを含む。
【００３３】
データ抽出部１７は、受信バッファ１２に格納されたパケットＰＴｎを読み出してデータブロックを抽出する。そして、抽出されたデータブロックを再生バッファ１９に渡す。
【００３４】
パケットロス判断部１５は、受信バッファ１２がパケットＰＴｎを格納するごとに、対応するＦＥＣブロック内でパケットロスが発生しているか否かを判断する。復元部１４は、パケットロスが発生しているとき、ロスパケットを復元する。このとき、復元部１４は、ＦＥＣブロックを構成するロスパケット以外の他の全てのパケットＰＴｎが受信バッファ１２に格納された後、ロスパケット以外の他のデータパケット及び冗長パケットを利用してロスパケットを復元する。
【００３５】
データ消去部１８は、通信部１０が新たなＦＥＣブロックに属するパケットＰＴｎを受信したとき、受信バッファ１２に格納されているパケットＰＴｎを消去する。つまり、受信バッファ１２は、通信部１０が新たなＦＥＣブロックに属するパケットＰＴｎを受信するまで、格納したパケットＰＴｎを保持する。データ消去部１８はさらに、受付部１１が新たなコンテンツデータの再生指示を受けたとき、再生バッファ１９内に格納されたデータブロックを消去する。要するに、データ消去部１８は、受信バッファ１２及び再生バッファ１９をリセットする。
【００３６】
［受信装置のハードウェア構成］
図４に示すとおり、受信装置１は、中央演算処理装置（ＣＰＵ）７０と、メモリ８０と、受付部１１と、ハードディスクドライブ（ＨＤＤ）９０と、通信部１０とを備える。受付部１１は、マウスやキーボード、操作キー、リモコン受光器等である。ＨＤＤ９０には再生プログラムが格納されている。再生プログラムがメモリ８０にロードされ、ＣＰＵ７０で実行されることにより、受信装置１は上述及び以降に説明する動作を実行する。このとき、受信バッファ１２及び再生バッファ１９はメモリ８０に対応する。また、制御部１３、検知部２０及び再生部２１はＣＰＵ７０に対応する。なお、送信装置１００のハードウェア構成も図４と同様である。
【００３７】
［受信装置の動作概要］
受信装置１は、コンテンツデータを再生している間、原則として、パケットＰＴｎが受信バッファ１２に格納されるごとに、格納されたパケットＰＴｎのデータブロックを抽出して再生バッファ１９に出力する。図５に示すとおり、あるＦＥＣブロックの先頭のパケットＰＴ１が受信バッファ１２に格納されたとき、データ抽出部１７は、パケットＰＴ１のデータブロックを抽出する（図５（ａ））。同様に、パケットＰＴ２が受信バッファ１２に格納されたとき、データ抽出部１７はパケットＰＴ２のデータブロックを抽出し（図５（ｂ））、パケットＰＴ３が受信バッファ１２に格納されたとき、パケットＰＴ３のデータブロックを抽出する（図５（ｃ））。
【００３８】
つまり、受信装置１は、従来のＦＥＣ復号化処理のように、ＦＥＣブロック内の全てのパケットＰＴ１〜ＰＴ１０が受信バッファ１２に格納されるのを待ってから各パケットＰＴｎ（ｎ＝１〜Ｎ）のデータブロックを抽出するのではなく、パケットＰＴｎが受信バッファ１２に格納されるごとにデータブロックを抽出して再生する。そのため、従来のように、ＦＥＣブロック内の全パケットＰＴｎが到着するのを待ってからデータブロックを抽出する場合よりも、バッファリングによる遅延時間を短縮できる。
【００３９】
さらに、パケットロスが発生した場合、受信装置１は、再生バッファ１９に蓄積されたデータ量（バッファ量）に応じて、データブロックの抽出及びロスしたパケットＰＴｎの復元を実行する。
【００４０】
図６に示すように、受信バッファ１２がパケットＰＴ７を受信したときにパケットロス判断部１５が、パケットＰＴ６をロスしていると判断したと仮定する。この場合、制御部１３が採り得るパターンは２通りある。第１のパターンは、図７に示すように、復元部１４がロスパケットＰＴ６を復元することなく、パケットＰＴ７以降のパケットＰＴｎのデータブロックを抽出するパターンである。この場合、パケットＰＴ６のデータブロックがないままパケットＰＴ７のデータブロックが再生されるため、パケットＰＴ６のデータブロックが再生されず、音切れが発生する。
【００４１】
第２のパターンは、復元部１４が、パケットＰＴ６を復元するパターンである。この場合、図８に示すように、データ抽出部１７は、パケットＰＴ１０（冗長パケット）が受信バッファ１２に到達するまでパケットＰＴ７以降のデータパケット（パケットＰＴ７〜ＰＴ９）のデータ抽出を中止する。そして、パケットＰＴ１０を受信バッファ１２に格納した後、復元部１４が、ロスパケットＰＴ６以外の全てのパケットＰＴｎを利用してロスパケットＰＴ６を復元する。パケットＰＴ６を復元したのち、パケットＰＴ６のデータブロック以降のデータブロックを配列番号順に順次抽出して再生する。
【００４２】
第２のパターンを採用する場合、第１のパターンのようにロスパケットによる音切れは発生しない。しかしながら、ＦＥＣブロック内の末尾のパケットＰＴ１０が到着しなければ復元はできないため、パケットＰＴ１０が到着するまで、パケットＰＴ７以降のデータブロックを再生バッファ１９に渡せない。要するに、第２のパターンは、データブロックを再生バッファ１９に格納するまでに時間が掛かる。そのため、最後のパケットＰＴ１０が到着するまでの時間が長ければ、再生バッファ１９のバッファ量が低下してデータが枯渇し、無音時間が発生する。
【００４３】
そこで、可能な限り音切れや無音時間の発生を抑制するために、制御部１３は、再生バッファ１９のバッファ量に基づいて、第１及び第２のパターンのうちいずれのパターンを採用するか決定する。具体的には、検知部２０が所定時間ごとに検知するバッファ量に基づいて余裕度Ｙを算出する。本例では、余裕度Ｙはパケット数で示される。バッファ量が多いほど余裕度Ｙは大きく、バッファ量が少ないほど余裕度は小さくなる。
【００４４】
図６において、制御部１３内の復元判断部１６は、パケットＰＴ７より後で受信装置１が受信する予定のパケット（以下、未到達パケットという）のデータ量に関する情報を利用する。本例では、未到達パケットのデータ量に関する情報として、未到達パケット数Ｒを求める。本例では、未到達パケットはＰＴ８〜ＰＴ１０であるため、未到達パケット数Ｒは３である。
【００４５】
次に、復元判断部１６は、余裕度Ｙと未到達パケット数Ｒとを比較する。仮に、余裕度Ｙが４である場合、Ｙ＞Ｒとなる。この場合、第２パターンを採用しても、再生バッファ１９のバッファ量は枯渇する可能性が低い。そのため、復元判断部１６はロスパケットを復元すると判断する。つまり、制御部１３は第２パターンを採用する。一方、余裕度が２である場合、Ｙ＜Ｒとなる。この場合、第２パターンを採用すれば、再生バッファ１９のバッファ量が枯渇し、音切れ時間（無音時間）が長引く可能性が高い。そのため、復元判断部１６は、復元しないと判断する。その結果、制御部１３は第１パターンを採用する。
【００４６】
要するに、制御部１３は、パケットロスを発見したとき、再生バッファのバッファ量と未到達パケットのデータ量（未到達パケット数）とに基づいて、第１及び第２パターンのいずれを採用するかを決定する。これにより、パケットロスを発生した場合でも、音切れの発生を抑制でき、かつ、仮に音切れが発生しても、音切れ時間を短縮できる。
【００４７】
［受信装置の動作の詳細］
以下、上述した受信装置１の動作の詳細をフロー図を用いて説明する。受信装置１は、余裕度Ｙを決定する余裕度設定処理と、ユーザ操作により新たなコンテンツの再生指示を受けたときに実行されるコマンド処理と、送信装置１００から配信されるパケットＰＴｎを受信バッファ１２に格納するごとに実行されるデータブロック抽出処理とを実行する。以下、それぞれの処理について詳述する。
【００４８】
［余裕度実行処理］
図９を参照して、検知部２０は所定時間毎に再生バッファ１９のバッファ量ＢＭ（ｂｙｔｅｓ）を検出する（Ｓ１）。検知部２０はこのとき、１パケット当たりのデータブロックのデータ量ＤＢｒｅｆ（ｂｙｔｅｓ／個）に基づいて、以下の式（１）によりバッファ量ＢＭ（ｂｙｔｅｓ）をパケット数（個）に換算する（Ｓ２）。
【００４９】
バッファ量ＢＭ（個）＝ＢＭ（bytes）／ＤＢｒｅｆ（bytes／個） （１）
続いて、バッファ量ＢＭ（個）を用いて、以下の式（２）から余裕度Ｙ（個）を算出する（Ｓ２）。
【００５０】
余裕度Ｙ（個）＝ＢＭ（個）−Ｒｅｆ（個） （２）
ここで、Ｒｅｆは、コンテンツデータを再生するときに再生バッファ１９内に最低限格納されている必要のあるデータ量（以下、基準バッファ量という）である。基準バッファ量Ｒｅｆはパケット数（個）で定義される。基準バッファ量Ｒｅｆはメモリ８０又はＨＤＤ９０に予め格納されている。
【００５１】
検知部２０は、所定期間毎に上述の式（２）に基づいて余裕度Ｙ（個）を求め、メモリ８０に格納する。
【００５２】
［コマンド処理］
図１０を参照して、受信装置１がコンテンツデータを再生している途中で、受付部１１がユーザ操作に応じて新たな所望のコンテンツデータの再生指示を受けたとき（Ｓ１１でＹＥＳ）、データ消去部１８は、再生バッファ１９内に格納されているデータブロックを消去する（Ｓ１２）。再生バッファ１９に格納されているデータブロックは、新たなコンテンツデータと異なる他のコンテンツデータのデータブロックであるためである。制御部１３はさらに、ユーザ所望のコンテンツデータのストリーミング配信を送信装置１００に要求する（Ｓ１３）。送信装置１００は、ストリーミング配信要求を受けたとき、それまで配信していたコンテンツデータのストリーミング配信を中止し、所望のコンテンツデータの配信を開始する。
【００５３】
［データブロック抽出処理］
送信装置１００は受信装置１からの要求に応じて、所望のコンテンツデータのパケットＰＴｎを順次ストリーミング配信する。受信装置１は、パケットＰＴｎを受信するごとに、データブロック抽出処理を実行する。
【００５４】
図１１を参照して、通信部１０が送信装置１００から送信されたパケットＰＴｎを受信したとき、制御部１３はパケットＰＴｎのヘッダ情報を読み出す（Ｓ２１）。そして、読み出されたヘッダ情報内のＦＥＣブロックＩＤが、現在受信バッファ１２に格納されているパケットＰＴｎのＦＥＣブロックＩＤと同じであるか否かを判断する（Ｓ２２）。
【００５５】
受信したパケットＰＴｎのＦＥＣブロックＩＤが受信バッファ１２内のパケットＰＴｎのＦＥＣブロックＩＤと異なる場合（Ｓ２２でＹＥＳ）、受信したパケットＰＴｎは、受信バッファ１２に既に格納されている他のパケットＰＴｎと異なるＦＥＣブロックに属する。この場合、たとえば、受信バッファ１２には、既にデータ抽出が完了したＦＥＣブロックのパケットＰＴ１〜ＰＴ１０が格納されている。そのため、データ消去部１８は、受信バッファ１２をリセットし、受信バッファ１２内に格納されていたパケットＰＴｎを全て消去する（Ｓ２３）。そして、制御部１３は、受信したパケットＰＴｎをリセット後の受信バッファ１２内の対応する番地に格納する（Ｓ２４）。受信バッファ１２は、パケットＰＴｎの位置情報として登録された配列番号ｎ（ｎ＝１〜１０）に対応した番地（１〜１０）で区切られている。制御部１３は、受信したパケットＰＴｎ（ｎ＝１〜１０）を、その配列番号ｎに対応した番地ｎに格納する。たとえば、受信したパケットＰＴｎの配列番号が「１」である場合、受信バッファ１２内の番地「１」に格納する。
【００５６】
一方、ステップＳ２２で判断した結果、受信したパケットＰＴｎのＦＥＣブロックＩＤが受信バッファ１２に現在格納されているパケットＰＴｎのＦＥＣブロックＩＤと同じである場合（Ｓ２２でＮＯ）、制御部１３は、受信バッファ１２をリセットすることなく、受信した新たなパケットＰＴｎを対応する番地ｎに格納する（Ｓ２４）。
【００５７】
続いて、パケットロスの有無を確認する（Ｓ２５）。具体的には、制御部１３内のパケットロス判断部１５は、ステップＳ２４でパケットＰＴｎを格納した番地よりも番号が小さい番地のうち、パケットＰＴｎが格納されていない番地が存在するか否かを確認する。パケットＰＴｎが格納されていない番地が存在しなければ、パケットロスは発生していないと判断する（Ｓ２５でＮＯ）。一方、パケットＰＴｎが格納されていない番地が存在すれば、パケットロスが発生していると判断する（Ｓ２５でＹＥＳ）。以下、パケットロスが発生していない場合と、パケットロスが発生した場合とに分けて、それぞれ説明する。
【００５８】
［パケットロスが発生していない場合］
ステップＳ２５での判断の結果、パケットロスが発生していない場合（Ｓ２５でＮＯ）、データ抽出部１７は、ステップＳ２４で受信バッファ１２に格納されたパケットＰＴｎからデータブロックを抽出する。そして、抽出されたデータブロックを再生バッファ１９に出力する（Ｓ３０）。要するに、パケットロスが発生していない場合、データ抽出部１７は、パケットＰＴｎが格納されるごとに、格納されたパケットＰＴｎのデータブロックを抽出して再生バッファ１９に渡す。そのため、従来のＦＥＣブロックのように、ＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０の到着を待つことなく、再生を実行することができ、ＦＥＣブロックのバッファリングに伴う遅延を抑制できる。なお、抽出されたパケットＰＴｎの配列番号はメモリ８０に記録される。そのため、ＦＥＣブロック内のどのパケットＰＴｎまでデータブロックを抽出したかを確認できる。
【００５９】
データブロックを受けた再生バッファ１９は、データブロックを格納する。そして、再生部２１の要求に応じて、格納時期が古い順にデータブロックを順次再生部２１に出力する。そのため、再生部２１は、データブロックを欠落することなく再生位置順に順次再生することができる。
【００６０】
［パケットロスが発生した場合］
たとえば、図６に示すように、パケットＰＴ７を受信バッファ１２に格納したとき、制御部１３内のパケットロス判断部１５は、パケットＰＴ６が受信バッファ１２の第６番地に格納されておらず、パケットロスが発生していると判断する（Ｓ２５でＹＥＳ）。このとき、復元判断部１６は、ロスパケットの数を算出する。本例ではロスパケットはＰＴ６のみであるため、ロスパケット数は「１」である。
【００６１】
続いて、復元判断部１６は、ロスパケット数が、ＦＥＣブロックの冗長パケットＰＴ１０により復元できるパケット数（復元可能パケット数という）よりも大きいか否かを判断する（Ｓ２６）。復元可能パケット数はＦＥＣ処理方式により予め決定されており、メモリ８０又はＨＤＤ９０に予め登録されている。本例では復元可能パケット数を「１」とする。
【００６２】
ステップＳ２６の判断の結果、ロスパケット数が復元可能パケット数よりも大きい場合（Ｓ２６でＹＥＳ）、たとえば、ロスパケット数が２である場合、復元判断部は、もはやロスパケットを復元できないと判断する。このとき、制御部１３は復元をあきらめ、データ抽出部１７は、ステップＳ２４で受信バッファ１２に格納されたパケットＰＴ７のデータブロックを抽出して再生バッファ１９に手渡す。この場合、ロスパケットのデータブロックは欠落したまま再生が継続される。そのため、欠落したデータブロックに相当する音切れが発生する。
【００６３】
一方、図６の例のように、ロスパケット数（＝１）が復元可能パケット数（＝１）と同じである場合（Ｓ２６でＮＯ）、復元判断部１６は、ロスパケットＰＴ６を復元可能である判断する。この場合、復元判断部１６はさらに、未到達パケット数Ｒを算出する（Ｓ２７）。ＦＥＣブロック内のパケット数Ｎ＝１０であり、ステップＳ２４で格納したパケットはＰＴ７（ｎ＝７）であるため、未到達パケットは１０−７＝３となる。
【００６４】
未到達パケット数Ｒが０でないため（Ｓ２８でＮＯ）、同一ＦＥＣブロック内の最後のパケットＰＴ１０（冗長パケット）はまだ受信バッファ１２に格納されていない。そこで、復元判断部１６は、未到達パケット数Ｒと余裕度Ｙとを比較する（Ｓ２９）。未到達パケット数Ｒが余裕度Ｙよりも大きい場合（Ｓ２９でＹＥＳ）、たとえば、未到達パケット数Ｒが「３」であり、余裕度Ｙが「２」である場合、再生バッファ１９内のバッファ量が少な過ぎるため、ＦＥＣブロック内の最後のパケットＰＴ１０が受信バッファ１２に格納されるまで待って復元が実行される前に、再生バッファ１９のデータが枯渇する可能性が高い。このような場合、データの枯渇により発生する音切れ時間が長くなる可能性がある。そこで、復元判断部１６はロスパケットＰＴ６の復元を行わないと判断する。データ抽出部１７はステップＳ２９の判断結果に基づいて、ステップＳ２４で格納したパケットＰＴ７のデータブロックを抽出して再生バッファ１９に渡す。つまり、ロスパケットＰＴ６の復元をあきらめる。ロスパケットＰＴ６の復元をあきらめれば、そのデータブロック分の時間の音切れが発生する。しかしながら、復元するためにパケットＰＴ１０の到着を待つことにより音切れ時間が長くなるのを抑制できる。
【００６５】
一方、余裕度Ｙが４であれば、制御部１３はステップＳ２９で未到達パケット数Ｒが余裕度Ｙよりも小さいため、復元判断部１６は、復元処理を行うと判断する（Ｓ２９でＮＯ）。この場合、最後のパケットＴＰ１０の到着を待ってパケットＰＴ６を復元するまでに再生バッファ１９内のバッファ量が枯渇する可能性は低い。そのため、データ抽出部１７はパケットＰＴ７のデータブロックを抽出せずに動作を終了する。そして、パケットＰＴ１０を受信バッファ１２に格納したとき（Ｓ２４）、制御部１３は、未到達パケット数Ｒ＝０と判断する（Ｓ２８でＹＥＳ）。つまり、ＦＥＣブロックの末尾のパケットＰＴ１０を格納したと判断する。そのため、復元部１４はＦＥＣ処理を実行してロスパケットＰＴ６を復元する（Ｓ３１）。そして、パケットＰＴ６から配列番号順に、パケットＰＴ６〜ＰＴ９内のデータブロックを順次抽出して再生バッファ１９に順次渡す。この動作により、パケットＰＴ６のデータブロックは復元され、かつ、復元されたデータブロックから再生位置順にデータブロックが再生バッファ１９に順次格納される。そのため、再生部２１はデータブロックを再生位置順に順次デコードでき、音切れは発生しない。
【００６６】
［新たなコンテンツの再生指示を受けたときのデータブロック抽出処理］
ユーザ操作により新たなコンテンツデータの再生指示を受けたとき（Ｓ１１でＹＳ）、再生バッファ１９内に格納されていたデータブロックは削除される。つまり、再生バッファ１９はリセットされる。コンテンツの指定が切り換えられたためである。このとき、再生バッファ１９のバッファ量は０であるため、余裕度Ｙ＝−Ｒｅｆとなる（Ｓ３）。したがって、この場合、たとえパケットロスが発生しても、データ抽出処理におけるステップＳ２９で、復元判断部１６はロスパケットを復元しないと判断する（Ｓ２９でＹＥＳ）。つまり、バッファ量が基準バッファ量Ｒｅｆよりも小さい場合、データ抽出部１７は、パケットＰＴｎが受信バッファ１２に格納されるごとにデータブロックを抽出して再生バッファ１９に渡す。これにより、再生すべきコンテンツが切り換えされたときに新たなコンテンツが再生されるまでの遅延を短縮できる。
【００６７】
以上、本実施の形態によるコンテンツ配信システムでは、受信装置１は、パケットロスが発生していないときはパケットＰＴｎを受信するごとに、そのパケットＰＴｎからデータブロックを抽出して再生する。そのため、受信バッファでのバッファリングによる遅延は生じない。また、パケットロスが発生した場合、未到達パケット数と余裕度（バッファ量）とを比較する。これにより、バッファ量に余裕がある場合はＦＥＣブロックの末尾パケットＰＴ１０を受信するまでデータブロックの抽出を中止してロスパケットを復元することができ、バッファ量に余裕がない場合は、ロスパケットの復元をせずに受信したパケットＰＴｎのデータブロックを順次抽出することができる。そのため、受信装置１は、パケットロスが発生した場合であっても、音切れの発生を抑制でき、仮に発生しても音切れ時間を最小限に抑えることができる。
【００６８】
上述の本実施の形態では、再生バッファ１９のバッファ量をパケット相当数に換算し、未到達パケット数と比較したが、たとえば、未到達パケット数Ｒ、余裕度Ｙ、バッファ量ＢＭをそれぞれデータ量（ｂｙｔｅｓ）で定義してもよい。受信装置１は、ＦＥＣブロック当たりのデータ量に関する情報を予めＨＤＤ９０に格納している。受信装置１は、ステップＳ２７で、１ＦＥＣ当たりのデータ量から受信バッファ１２に格納済みのバッファ量（データ量）を差分して、未到達パケットのデータ量を算出する。そして、ステップＳ２９でデータ量と余裕度Ｙとを比較してもよい。この場合、余裕度Ｙはデータ量（ｂｙｔｅｓ）で示される。
【００６９】
さらに、受信装置１は、未到達パケットのデータ量に基づいて、受信装置１が未到達パケットを全て受信するまでに掛かる予想時間Ｔ１と、バッファ量ＢＭに基づいて再生バッファ１９に格納されているデータを再生し終えるまでに掛かる予想時間Ｔ２とを求め、予想時間Ｔ１及びＴ２に基づいて第１及び第２のパターンのいずれを採用するかを決定してもよい。具体的には、検知部２０はステップＳ３で予想時間Ｔ２から基準値Ｒｅｆ（ここでは時間）を差し引いて余裕度Ｙ（時間）を算出する。そして、復元判断部１６はステップＳ２９で、予想時間Ｔ１と余裕度Ｙとを比較し、第１及び第２のパターンのいずれを採用するかを決める。受信装置１は、バッファ量ＢＭと再生速度とに基づいて予想時間Ｔ２を算出する。
【００７０】
受信装置１は、送信装置１００と受信装置１との間の伝送レートに関する情報を保持しており、未到達パケットのデータ量と伝送レートとに基づいて予想時間Ｔ１を算出する。受信装置１は、他の方法で予想時間Ｔ１を求めてもよい。一般的に、パケットＰＴｎは等間隔で配信されるため、受信装置１も等間隔でパケットＰＴｎを受信する。そのため、受信装置１は、パケットＰＴｎの受信間隔に関する情報を持つ。この場合、受信装置１は、未到達パケットのデータ量に関する情報として未到達パケット数Ｒを用いて、未到達パケット数Ｒと受信間隔とに基づいて、予想時間Ｔ１を求めてもよい。なお、送信装置１００がデータパケットＰＴ９直後に間隔を空けずに冗長パケットＰＴ１０を送信する場合もある。この場合、受信装置１は、パケットＰＴ９を受信した後、受信間隔を空けずに冗長パケットＰＴ１０を受信するため、この点も考慮して予想時間Ｔ１を算出してもよい。
【００７１】
いずれにしても、本発明では、受信装置１は未到達パケットのデータ量に関する情報と、バッファ量に関する情報とに基づいて、第１及び第２のパターンのいずれを採用するかを決定する。
【００７２】
上述の例では、受信装置１がユーザ所望のコンテンツのストリーミング配信を送信装置１００に要求したが、送信装置１００がマルチキャスト配信を行っており、受信装置１が複数のチャンネルから所望のチャンネルに適宜切り換えるようにしてもよい。この場合であっても、チャンネルの切り換え時の動作は、上述の新たなコンテンツの再生指示を受けた場合の動作と同じである。
【００７３】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【００７４】
【図１】本発明の実施の形態にコンテンツ配信システムの全体構成を示す機能ブロック図である。
【図２】図１に示した送信装置で生成されるＦＥＣブロックのデータ構造を示す図である。
【図３】図１に示した送信装置で生成されるＦＥＣブロックを構成するパケットのデータ構造を示す図である。
【図４】図１に示した受信装置のハードウェア構成を示すブロック図である。
【図５】図１に示した受信装置の動作概要を説明するための図である。
【図６】図５に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図７】図６に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図８】図７に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図９】図１に示した受信装置の余裕度設定処理の詳細を示すフロー図である。
【図１０】図１に示した受信装置のコマンド処理の詳細を示すフロー図である。
【図１１】図１に示した受信装置のデータ抽出処理の詳細を示すフロー図である。
【符号の説明】
【００７５】
１ 受信装置
１０，１０２ 通信部
１１ 受付部
１２ 受信バッファ
１３ 制御部
１４ 復元部
１５ パケットロス判断部
１６ 復元判断部
１７ データ抽出部
１８ データ消去部
１９ 再生バッファ
２０ 検知部
２１ 再生部
１００ 送信装置
１０１ ブロック生成部
【技術分野】
【０００１】
本発明は、コンテンツ配信システム、受信装置及び再生プログラムに関し、さらに詳しくは、コンテンツデータをパケット化及び冗長符号化してＦＥＣ（Forward Error Correction）ブロックを生成し、生成されたＦＥＣブロックを配信する送信装置と、ＦＥＣブロックを構成する複数のパケットを順次受信する受信装置とを備えたコンテンツ配信システム、そのコンテンツ配信システムを構成する受信装置及び受信装置に実装される再生プログラムに関する。
【背景技術】
【０００２】
近年、音声データや映像データ等のコンテンツデータをインターネットプロトコル（ＩＰ）を利用してネットワーク上でストリーミング配信するサービスが登場している。ストリーミング配信では、送信装置が、コンテンツデータをパケット化して複数のデータパケットを生成し、再生時間順にデータパケットを順次配信する。そして、受信装置がデータパケットを順次受信して再生する。
【０００３】
上述のストリーミング型伝送方式ではしばしばパケットロスが発生する。パケットロスとは、コンテンツデータを構成する複数のデータパケットのうち１又は複数のデータパケットが受信装置に届かないことをいう。このようなロスしたデータパケット（以下、ロスパケットという）を受信装置側で復元する技術として、前方誤り訂正（Forward Error Correction：以下、ＦＥＣという）がある。ＦＥＣでは、送信装置が複数のデータパケットを再生時間順に所定数ごとにグループ化する。そして、同じグループに属するデータパケットに対してＲＳ（Reed Solomon）符号やハミング（Hamming）符号等の誤り訂正符号を用いて冗長符号化し、グループごとに冗長パケットを生成する。送信装置は、グループ内の複数のデータパケットと、対応する冗長パケットとを１つのＦＥＣブロックとし、ＦＥＣブロックのデータパケット及び冗長パケットを順次送信する。
【０００４】
受信装置は、ＦＥＣブロック内の複数のパケット（データパケット及び冗長パケット）をバッファに格納する。そして、１つのＦＥＣブロック内の全てのパケットをバッファに格納した後、データパケット内のデータブロックを再生時間順に順次抽出してデコードする。データブロックはコンテンツデータの一部を構成するデータであり、受信装置はデータブロックを順次デコードすることでコンテンツを再生できる。さらに、ＦＥＣブロック内でパケットロスが発生した場合、つまり、受信装置がＦＥＣブロック内の一部のデータパケットを受信できなかった場合、受信装置は、同じＦＥＣブロックに属する他のデータパケット及び冗長パケットを用いてロスパケットを復元できる。つまり、送信装置にロスパケットの再送を要求することなく、受信装置でロスパケットを復元できる。
【０００５】
しかしながら、受信装置は、ＦＥＣブロックを構成する全てのパケットを受信した後でなければ、各データパケットのデータブロックを抽出して再生することができない。そのため、ＦＥＣブロック内にパケットロスが発生していない場合であっても、ＦＥＣブロック内の全てのパケットを受け取った後、データブロックが順次抽出される。ＦＥＣブロック内の複数のパケットのバッファリングにはある程度の時間が必要であるため、バッファリングに起因した遅延が発生する。
【０００６】
このようなＦＥＣ処理に起因した遅延を抑制するために、特開２００８−１６０４９９号公報では、転送データのデータレートに応じてパケットサイズを変更する技術が開示されている。しかしながら、パケットサイズを小さくしても、ＦＥＣブロック内の全てのパケットをバッファに格納する必要があるため、ある程度の遅延が発生する。
【特許文献１】特開２００８−１６０４９９号公報
【特許文献２】特開２００１−１８４８０８号公報
【特許文献３】特許第３７１５３３２号
【特許文献４】特表２００６−５２０９５４号公報
【特許文献５】特開２００６−１７８９８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、バッファリングによる遅延を抑制でき、かつ、パケットロスによるコンテンツデータの抜けも抑制できるコンテンツ配信システム及び受信装置を提供することである。
【課題を解決するための手段及び発明の効果】
【０００８】
本発明によるコンテンツ配信システムは、送信装置と、受信装置とを備える。送信装置は、ブロック生成手段と、送信手段とを備える。ブロック生成手段は、コンテンツデータをパケット化及び冗長符号化し、複数のＦＥＣ（Forward Error Correction)ブロックを生成する。ＦＥＣブロックは、コンテンツデータを分割した複数のデータブロックを含むデータパケットと冗長パケットとを含む。送信手段は、ＦＥＣブロックを構成する複数のパケットを順次送信する。受信装置は、受信手段と、受信バッファ手段と、再生バッファ手段と、再生手段と、パケットロス判断手段と、検知手段と、復元判断手段と、復元手段と、データ抽出手段とを備える。受信手段は、送信装置から送信されたパケットを受信する。受信バッファ手段は、受信手段により受信されたパケットを格納する。再生バッファ手段は、受信バッファ手段に格納されたデータパケットから抽出されたデータブロックを格納する。再生手段は、再生バッファ手段に格納された順に、データブロックを再生する。パケットロス判断手段は、パケットが受信バッファ手段に格納されるごとに、格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断する。検知手段は、再生バッファ手段に格納されているデータブロックのデータ量を検知する。復元判断手段は、パケットロスが発生したとき、再生バッファ手段のデータ量と、ＦＥＣブロック内のパケットのうち受信バッファ手段に格納されたパケット以降に受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する。復元手段は、ロスパケットを復元するとき、ＦＥＣブロックのロスパケット以外の他のパケットが受信バッファ手段に格納された後、他のパケットを用いてロスパケットを復元する。データ抽出手段は、パケットロスが発生していないとき、及び、ロスパケットを復元しないとき、受信バッファ手段に格納されたデータパケットのデータブロックを抽出して再生バッファ手段に出力する。また、ロスパケットを復元するとき、ロスパケットを復元した後、復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して再生バッファ手段に出力する。
【０００９】
本発明によるコンテンツ配信システムでは、受信装置は、パケットロスが発生していなければ、データパケットを受信バッファ手段に格納するごとに、格納されたデータパケットからデータブロックを抽出して再生する。そのため、従来のＦＥＣ処理のようなバッファリングによる遅延の発生を抑制できる。
【００１０】
また、受信装置は、パケットロスが発生している場合、再生バッファ手段が格納しているデータ量と、受信装置が受け取る予定のＦＥＣブロックの残りのパケット（以下、未到達パケットという）のデータ量とに基づいて、ロスパケットを復元するか否かを決める。そのため、パケットロスによるコンテンツの部分的な抜けを抑制でき、仮に、コンテンツの部分的な抜けが生じても、再生の中断時間を抑制できる。
【００１１】
好ましくは、受信装置はさらに、パケット消去手段を備える。パケット消去手段は、受信手段により受信されたパケットの属するＦＥＣブロックが受信バッファ手段に格納されているパケットの属するＦＥＣブロックと異なるとき、受信バッファ手段に格納されたパケットを消去する。
【００１２】
これにより、受信バッファ手段はＦＥＣブロック単位で複数のパケットを保持でき、異なるＦＥＣブロックのパケットが混在して格納されるのを防止できる。
【００１３】
好ましくは、受信装置はさらに、データブロック消去手段を備える。データブロック消去手段は、新たなコンテンツデータの再生指示を受けたとき、再生バッファ手段に格納されているデータブロックを消去する。
【００１４】
好ましくは、復元手段はさらに、検知手段により検知されたデータ量が基準値未満の場合、ロスパケットを復元しない。
【００１５】
たとえば、コンテンツデータの再生指示を受ければ、再生バッファ手段はリセットされるため、再生バッファ手段のデータ量は基準値未満となる。そのため、復元手段はロスパケットを復元せず、受信バッファ手段にデータパケットが格納されるごとに、データブロックを抽出して再生する。したがって、新たなコンテンツデータの再生指示を受けたとき、バッファリングによる遅延の発生を抑制でき、新たなコンテンツデータの再生を迅速に開始できる。
【００１６】
本発明による受信装置は、上述のコンテンツ配信システムに利用される。また、本発明による再生プログラムは、上述の受信装置内に格納されることにより、受信装置に上述の手段を実現させる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【００１８】
［全体構成］
図１に本実施の形態によるコンテンツ配信システムの機能ブロック図を示す。コンテンツ配信システムは、送信装置１００と受信装置１とを備える。受信装置１は送信装置１００とネットワークを介して接続される。送信装置１００は、映像データや音声データといったコンテンツデータを図示しないハードディスクドライブに蓄積する。以降の説明では、一例として、コンテンツデータを音声データとする。送信装置１００は、コンテンツデータをＦＥＣ符号化処理し、ＦＥＣ符号化されたコンテンツデータをストリーム配信する。受信装置１は、ストリーム配信されたコンテンツデータを順次受け取り、ＦＥＣ復号化して再生する。
【００１９】
［送信装置］
受信装置１の詳細を説明する前に、送信装置１００について説明する。送信装置１００は、ＦＥＣブロック生成部１０１と、通信部１０２とを備える。ＦＥＣブロック生成部１０１は、圧縮符号化されたコンテンツデータをパケット化して複数のパケットを生成する。具体的には、コンテンツデータを所定のデータ長の複数のデータブロックに分割する。そして、分割されたデータブロックにパケットヘッダを付与してデータパケットを生成する。パケットヘッダはデータブロックの位置情報を含む。位置情報は、データブロックのコンテンツデータにおける再生位置を示す。位置情報はたとえば、タイムスタンプである。
【００２０】
ＦＥＣブロック生成部１０１はさらに、再生位置順に配列されたＫ個のデータパケットを１つのグループとし、グループ化された複数のデータパケットに対して冗長符号化処理を実行する。冗長符号化処理は、たとえば、ＲＳ符号等の公知の誤り訂正符号を用いる。冗長符号化処理により、Ｎ−Ｋ個（Ｎ＞Ｋ）の冗長パケットが生成される。
【００２１】
送信装置１００は、グループ化したＫ個の分割パケットとＮ−Ｋ個の冗長パケットとを１つのＦＥＣブロックとして定義する。つまり、１つのＦＥＣブロックは、図２に示すとおり、Ｋ個のデータパケットとＮ−Ｋ個の冗長パケットとを含む。
【００２２】
パケットロスが発生している場合、受信装置１は、１つのＦＥＣブロックを構成するロスパケット以外の全てのパケットを受信した後、ＦＥＣ復号処理を実行する。このとき受信装置１は、１つのＦＥＣブロックを構成するＮ個のパケットのうち、Ｋ個のパケット（冗長パケットを含む）を受信していれば、全てのデータパケット（つまりＫ個）を復元することができる。
【００２３】
以降の説明では説明を容易にするために、一例として、Ｎ＝１０とし、Ｋ＝９とする。つまり、１つのＦＥＣブロックは、９個のデータパケットと、１個の冗長パケットとからなる。以降、１つのＦＥＣブロックを構成する１０個のパケット（データパケット及び冗長パケット）をパケットＰＴｎ（ｎ＝１〜１０）と称する。
【００２４】
図３にＦＥＣブロックを構成する各パケットＰＴｎ（ｎ＝１〜１０）のデータ構造を示す。パケットＰＴｎは、ヘッダ情報とペイロードとを含む。ペイロードには、データパケット又は冗長パケットが含まれる。ヘッダ情報は、ＦＥＣブロックＩＤと、位置情報とを含む。ＦＥＣブロックＩＤがそのパケットＰＴｎが属するＦＥＣブロックの識別子である。位置情報は、ＦＥＣブロック内でのパケットＰＴｎの配列位置を示す。本例では、位置情報は、ＦＥＣブロック内での先頭からの配列番号とする。図２に示すとおり、データパケットは、再生位置順に、ＦＥＣブロックの先頭から順に配列される。そして、データパケットの後に冗長パケットが配列される。したがって、ＦＥＣブロックの末尾のパケットＰＴ１０は冗長パケットである。本例では、パケットＰＴｎの配列番号は、ＦＥＣブロックの先頭から順に、１、２、３…と付与される。なお、位置情報は配列番号ではなく、たとえばＦＥＣブロックの先頭からのオフセットでもよい。
【００２５】
送信装置１００内の通信部１０２は、生成した複数のＦＥＣブロックを構成する複数のパケットを順次送信する。具体的には、あるＦＥＣブロックのパケットＰＴ１〜ＰＴ１０を先頭から順に送信する。送信が完了したのち、次のＦＥＣブロックのパケットを順次配信する。
【００２６】
本実施の形態による送信装置１００はインターリーブ処理を実行しない。そのため、パケットＰＴ１〜ＰＴ９に相当するデータパケットは、再生位置順に配列されており、再生位置順に順次送信される。
【００２７】
［受信装置］
次に、受信装置１について説明する。受信装置１は、通信部１０と、受付部１１と、受信バッファ１２と、制御部１３と、再生バッファ１９と、検知部２０と、再生部２１とを備える。
【００２８】
通信部１０は、送信装置１００から送信されるパケットを順次受信し、受信バッファ１２に渡す。受付部１１は、ユーザ所望のコンテンツデータの再生指示を受け付ける。通信部１０は、受付部１１が再生指示を受けたとき、所望のコンテンツデータのストリーミング配信要求を送信装置１００に送信する。送信装置１００は、新たなコンテンツデータのストリーミング配信要求を受けたとき、現在配信中のコンテンツデータのストリーミング配信を中止し、新たなコンテンツデータのストリーミング配信を開始する。
【００２９】
受信バッファ１２は、通信部１０から順次渡されるパケットＰＴｎを順次格納する。受信バッファ１２は、１つのＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０を格納できる容量を少なくとも有する。つまり、受信バッファ１２は、同じＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０を格納できる。
【００３０】
再生バッファ１９は、受信バッファ１２に格納されたパケットＰＴｎから抽出されたデータブロックを順次格納する。このとき、再生バッファ１９は、データブロックを再生位置順に順次格納する。再生部２１は、再生バッファ１９に格納されたデータブロックを格納時期が古い順に順次読み出す。データブロックは圧縮符号化されているため、再生部２１はデータブロックをデコードして出力する。これにより、データブロックは再生位置順にデコードされる。再生部２１から出力されたデータは、図示しないＤ／Ａ変換回路によりアナログ信号となり、図示しない出力端子を介して外部に出力される。出力された信号は図示しないスピーカにより音声として出力される。
【００３１】
検知部２０は、所定時間毎に、再生バッファ１９に格納されているデータブロックのデータ量（以下、バッファ量という）を検知する。
【００３２】
制御部１３は、パケットＰＴｎからのデータブロックの抽出処理と、ＦＥＣ復号処理とを実行する。制御部１３は、復元部１４と、パケットロス判断部１５と、復元判断部１６と、データ抽出部１７と、データ消去部１８とを含む。
【００３３】
データ抽出部１７は、受信バッファ１２に格納されたパケットＰＴｎを読み出してデータブロックを抽出する。そして、抽出されたデータブロックを再生バッファ１９に渡す。
【００３４】
パケットロス判断部１５は、受信バッファ１２がパケットＰＴｎを格納するごとに、対応するＦＥＣブロック内でパケットロスが発生しているか否かを判断する。復元部１４は、パケットロスが発生しているとき、ロスパケットを復元する。このとき、復元部１４は、ＦＥＣブロックを構成するロスパケット以外の他の全てのパケットＰＴｎが受信バッファ１２に格納された後、ロスパケット以外の他のデータパケット及び冗長パケットを利用してロスパケットを復元する。
【００３５】
データ消去部１８は、通信部１０が新たなＦＥＣブロックに属するパケットＰＴｎを受信したとき、受信バッファ１２に格納されているパケットＰＴｎを消去する。つまり、受信バッファ１２は、通信部１０が新たなＦＥＣブロックに属するパケットＰＴｎを受信するまで、格納したパケットＰＴｎを保持する。データ消去部１８はさらに、受付部１１が新たなコンテンツデータの再生指示を受けたとき、再生バッファ１９内に格納されたデータブロックを消去する。要するに、データ消去部１８は、受信バッファ１２及び再生バッファ１９をリセットする。
【００３６】
［受信装置のハードウェア構成］
図４に示すとおり、受信装置１は、中央演算処理装置（ＣＰＵ）７０と、メモリ８０と、受付部１１と、ハードディスクドライブ（ＨＤＤ）９０と、通信部１０とを備える。受付部１１は、マウスやキーボード、操作キー、リモコン受光器等である。ＨＤＤ９０には再生プログラムが格納されている。再生プログラムがメモリ８０にロードされ、ＣＰＵ７０で実行されることにより、受信装置１は上述及び以降に説明する動作を実行する。このとき、受信バッファ１２及び再生バッファ１９はメモリ８０に対応する。また、制御部１３、検知部２０及び再生部２１はＣＰＵ７０に対応する。なお、送信装置１００のハードウェア構成も図４と同様である。
【００３７】
［受信装置の動作概要］
受信装置１は、コンテンツデータを再生している間、原則として、パケットＰＴｎが受信バッファ１２に格納されるごとに、格納されたパケットＰＴｎのデータブロックを抽出して再生バッファ１９に出力する。図５に示すとおり、あるＦＥＣブロックの先頭のパケットＰＴ１が受信バッファ１２に格納されたとき、データ抽出部１７は、パケットＰＴ１のデータブロックを抽出する（図５（ａ））。同様に、パケットＰＴ２が受信バッファ１２に格納されたとき、データ抽出部１７はパケットＰＴ２のデータブロックを抽出し（図５（ｂ））、パケットＰＴ３が受信バッファ１２に格納されたとき、パケットＰＴ３のデータブロックを抽出する（図５（ｃ））。
【００３８】
つまり、受信装置１は、従来のＦＥＣ復号化処理のように、ＦＥＣブロック内の全てのパケットＰＴ１〜ＰＴ１０が受信バッファ１２に格納されるのを待ってから各パケットＰＴｎ（ｎ＝１〜Ｎ）のデータブロックを抽出するのではなく、パケットＰＴｎが受信バッファ１２に格納されるごとにデータブロックを抽出して再生する。そのため、従来のように、ＦＥＣブロック内の全パケットＰＴｎが到着するのを待ってからデータブロックを抽出する場合よりも、バッファリングによる遅延時間を短縮できる。
【００３９】
さらに、パケットロスが発生した場合、受信装置１は、再生バッファ１９に蓄積されたデータ量（バッファ量）に応じて、データブロックの抽出及びロスしたパケットＰＴｎの復元を実行する。
【００４０】
図６に示すように、受信バッファ１２がパケットＰＴ７を受信したときにパケットロス判断部１５が、パケットＰＴ６をロスしていると判断したと仮定する。この場合、制御部１３が採り得るパターンは２通りある。第１のパターンは、図７に示すように、復元部１４がロスパケットＰＴ６を復元することなく、パケットＰＴ７以降のパケットＰＴｎのデータブロックを抽出するパターンである。この場合、パケットＰＴ６のデータブロックがないままパケットＰＴ７のデータブロックが再生されるため、パケットＰＴ６のデータブロックが再生されず、音切れが発生する。
【００４１】
第２のパターンは、復元部１４が、パケットＰＴ６を復元するパターンである。この場合、図８に示すように、データ抽出部１７は、パケットＰＴ１０（冗長パケット）が受信バッファ１２に到達するまでパケットＰＴ７以降のデータパケット（パケットＰＴ７〜ＰＴ９）のデータ抽出を中止する。そして、パケットＰＴ１０を受信バッファ１２に格納した後、復元部１４が、ロスパケットＰＴ６以外の全てのパケットＰＴｎを利用してロスパケットＰＴ６を復元する。パケットＰＴ６を復元したのち、パケットＰＴ６のデータブロック以降のデータブロックを配列番号順に順次抽出して再生する。
【００４２】
第２のパターンを採用する場合、第１のパターンのようにロスパケットによる音切れは発生しない。しかしながら、ＦＥＣブロック内の末尾のパケットＰＴ１０が到着しなければ復元はできないため、パケットＰＴ１０が到着するまで、パケットＰＴ７以降のデータブロックを再生バッファ１９に渡せない。要するに、第２のパターンは、データブロックを再生バッファ１９に格納するまでに時間が掛かる。そのため、最後のパケットＰＴ１０が到着するまでの時間が長ければ、再生バッファ１９のバッファ量が低下してデータが枯渇し、無音時間が発生する。
【００４３】
そこで、可能な限り音切れや無音時間の発生を抑制するために、制御部１３は、再生バッファ１９のバッファ量に基づいて、第１及び第２のパターンのうちいずれのパターンを採用するか決定する。具体的には、検知部２０が所定時間ごとに検知するバッファ量に基づいて余裕度Ｙを算出する。本例では、余裕度Ｙはパケット数で示される。バッファ量が多いほど余裕度Ｙは大きく、バッファ量が少ないほど余裕度は小さくなる。
【００４４】
図６において、制御部１３内の復元判断部１６は、パケットＰＴ７より後で受信装置１が受信する予定のパケット（以下、未到達パケットという）のデータ量に関する情報を利用する。本例では、未到達パケットのデータ量に関する情報として、未到達パケット数Ｒを求める。本例では、未到達パケットはＰＴ８〜ＰＴ１０であるため、未到達パケット数Ｒは３である。
【００４５】
次に、復元判断部１６は、余裕度Ｙと未到達パケット数Ｒとを比較する。仮に、余裕度Ｙが４である場合、Ｙ＞Ｒとなる。この場合、第２パターンを採用しても、再生バッファ１９のバッファ量は枯渇する可能性が低い。そのため、復元判断部１６はロスパケットを復元すると判断する。つまり、制御部１３は第２パターンを採用する。一方、余裕度が２である場合、Ｙ＜Ｒとなる。この場合、第２パターンを採用すれば、再生バッファ１９のバッファ量が枯渇し、音切れ時間（無音時間）が長引く可能性が高い。そのため、復元判断部１６は、復元しないと判断する。その結果、制御部１３は第１パターンを採用する。
【００４６】
要するに、制御部１３は、パケットロスを発見したとき、再生バッファのバッファ量と未到達パケットのデータ量（未到達パケット数）とに基づいて、第１及び第２パターンのいずれを採用するかを決定する。これにより、パケットロスを発生した場合でも、音切れの発生を抑制でき、かつ、仮に音切れが発生しても、音切れ時間を短縮できる。
【００４７】
［受信装置の動作の詳細］
以下、上述した受信装置１の動作の詳細をフロー図を用いて説明する。受信装置１は、余裕度Ｙを決定する余裕度設定処理と、ユーザ操作により新たなコンテンツの再生指示を受けたときに実行されるコマンド処理と、送信装置１００から配信されるパケットＰＴｎを受信バッファ１２に格納するごとに実行されるデータブロック抽出処理とを実行する。以下、それぞれの処理について詳述する。
【００４８】
［余裕度実行処理］
図９を参照して、検知部２０は所定時間毎に再生バッファ１９のバッファ量ＢＭ（ｂｙｔｅｓ）を検出する（Ｓ１）。検知部２０はこのとき、１パケット当たりのデータブロックのデータ量ＤＢｒｅｆ（ｂｙｔｅｓ／個）に基づいて、以下の式（１）によりバッファ量ＢＭ（ｂｙｔｅｓ）をパケット数（個）に換算する（Ｓ２）。
【００４９】
バッファ量ＢＭ（個）＝ＢＭ（bytes）／ＤＢｒｅｆ（bytes／個） （１）
続いて、バッファ量ＢＭ（個）を用いて、以下の式（２）から余裕度Ｙ（個）を算出する（Ｓ２）。
【００５０】
余裕度Ｙ（個）＝ＢＭ（個）−Ｒｅｆ（個） （２）
ここで、Ｒｅｆは、コンテンツデータを再生するときに再生バッファ１９内に最低限格納されている必要のあるデータ量（以下、基準バッファ量という）である。基準バッファ量Ｒｅｆはパケット数（個）で定義される。基準バッファ量Ｒｅｆはメモリ８０又はＨＤＤ９０に予め格納されている。
【００５１】
検知部２０は、所定期間毎に上述の式（２）に基づいて余裕度Ｙ（個）を求め、メモリ８０に格納する。
【００５２】
［コマンド処理］
図１０を参照して、受信装置１がコンテンツデータを再生している途中で、受付部１１がユーザ操作に応じて新たな所望のコンテンツデータの再生指示を受けたとき（Ｓ１１でＹＥＳ）、データ消去部１８は、再生バッファ１９内に格納されているデータブロックを消去する（Ｓ１２）。再生バッファ１９に格納されているデータブロックは、新たなコンテンツデータと異なる他のコンテンツデータのデータブロックであるためである。制御部１３はさらに、ユーザ所望のコンテンツデータのストリーミング配信を送信装置１００に要求する（Ｓ１３）。送信装置１００は、ストリーミング配信要求を受けたとき、それまで配信していたコンテンツデータのストリーミング配信を中止し、所望のコンテンツデータの配信を開始する。
【００５３】
［データブロック抽出処理］
送信装置１００は受信装置１からの要求に応じて、所望のコンテンツデータのパケットＰＴｎを順次ストリーミング配信する。受信装置１は、パケットＰＴｎを受信するごとに、データブロック抽出処理を実行する。
【００５４】
図１１を参照して、通信部１０が送信装置１００から送信されたパケットＰＴｎを受信したとき、制御部１３はパケットＰＴｎのヘッダ情報を読み出す（Ｓ２１）。そして、読み出されたヘッダ情報内のＦＥＣブロックＩＤが、現在受信バッファ１２に格納されているパケットＰＴｎのＦＥＣブロックＩＤと同じであるか否かを判断する（Ｓ２２）。
【００５５】
受信したパケットＰＴｎのＦＥＣブロックＩＤが受信バッファ１２内のパケットＰＴｎのＦＥＣブロックＩＤと異なる場合（Ｓ２２でＹＥＳ）、受信したパケットＰＴｎは、受信バッファ１２に既に格納されている他のパケットＰＴｎと異なるＦＥＣブロックに属する。この場合、たとえば、受信バッファ１２には、既にデータ抽出が完了したＦＥＣブロックのパケットＰＴ１〜ＰＴ１０が格納されている。そのため、データ消去部１８は、受信バッファ１２をリセットし、受信バッファ１２内に格納されていたパケットＰＴｎを全て消去する（Ｓ２３）。そして、制御部１３は、受信したパケットＰＴｎをリセット後の受信バッファ１２内の対応する番地に格納する（Ｓ２４）。受信バッファ１２は、パケットＰＴｎの位置情報として登録された配列番号ｎ（ｎ＝１〜１０）に対応した番地（１〜１０）で区切られている。制御部１３は、受信したパケットＰＴｎ（ｎ＝１〜１０）を、その配列番号ｎに対応した番地ｎに格納する。たとえば、受信したパケットＰＴｎの配列番号が「１」である場合、受信バッファ１２内の番地「１」に格納する。
【００５６】
一方、ステップＳ２２で判断した結果、受信したパケットＰＴｎのＦＥＣブロックＩＤが受信バッファ１２に現在格納されているパケットＰＴｎのＦＥＣブロックＩＤと同じである場合（Ｓ２２でＮＯ）、制御部１３は、受信バッファ１２をリセットすることなく、受信した新たなパケットＰＴｎを対応する番地ｎに格納する（Ｓ２４）。
【００５７】
続いて、パケットロスの有無を確認する（Ｓ２５）。具体的には、制御部１３内のパケットロス判断部１５は、ステップＳ２４でパケットＰＴｎを格納した番地よりも番号が小さい番地のうち、パケットＰＴｎが格納されていない番地が存在するか否かを確認する。パケットＰＴｎが格納されていない番地が存在しなければ、パケットロスは発生していないと判断する（Ｓ２５でＮＯ）。一方、パケットＰＴｎが格納されていない番地が存在すれば、パケットロスが発生していると判断する（Ｓ２５でＹＥＳ）。以下、パケットロスが発生していない場合と、パケットロスが発生した場合とに分けて、それぞれ説明する。
【００５８】
［パケットロスが発生していない場合］
ステップＳ２５での判断の結果、パケットロスが発生していない場合（Ｓ２５でＮＯ）、データ抽出部１７は、ステップＳ２４で受信バッファ１２に格納されたパケットＰＴｎからデータブロックを抽出する。そして、抽出されたデータブロックを再生バッファ１９に出力する（Ｓ３０）。要するに、パケットロスが発生していない場合、データ抽出部１７は、パケットＰＴｎが格納されるごとに、格納されたパケットＰＴｎのデータブロックを抽出して再生バッファ１９に渡す。そのため、従来のＦＥＣブロックのように、ＦＥＣブロックを構成する全てのパケットＰＴ１〜ＰＴ１０の到着を待つことなく、再生を実行することができ、ＦＥＣブロックのバッファリングに伴う遅延を抑制できる。なお、抽出されたパケットＰＴｎの配列番号はメモリ８０に記録される。そのため、ＦＥＣブロック内のどのパケットＰＴｎまでデータブロックを抽出したかを確認できる。
【００５９】
データブロックを受けた再生バッファ１９は、データブロックを格納する。そして、再生部２１の要求に応じて、格納時期が古い順にデータブロックを順次再生部２１に出力する。そのため、再生部２１は、データブロックを欠落することなく再生位置順に順次再生することができる。
【００６０】
［パケットロスが発生した場合］
たとえば、図６に示すように、パケットＰＴ７を受信バッファ１２に格納したとき、制御部１３内のパケットロス判断部１５は、パケットＰＴ６が受信バッファ１２の第６番地に格納されておらず、パケットロスが発生していると判断する（Ｓ２５でＹＥＳ）。このとき、復元判断部１６は、ロスパケットの数を算出する。本例ではロスパケットはＰＴ６のみであるため、ロスパケット数は「１」である。
【００６１】
続いて、復元判断部１６は、ロスパケット数が、ＦＥＣブロックの冗長パケットＰＴ１０により復元できるパケット数（復元可能パケット数という）よりも大きいか否かを判断する（Ｓ２６）。復元可能パケット数はＦＥＣ処理方式により予め決定されており、メモリ８０又はＨＤＤ９０に予め登録されている。本例では復元可能パケット数を「１」とする。
【００６２】
ステップＳ２６の判断の結果、ロスパケット数が復元可能パケット数よりも大きい場合（Ｓ２６でＹＥＳ）、たとえば、ロスパケット数が２である場合、復元判断部は、もはやロスパケットを復元できないと判断する。このとき、制御部１３は復元をあきらめ、データ抽出部１７は、ステップＳ２４で受信バッファ１２に格納されたパケットＰＴ７のデータブロックを抽出して再生バッファ１９に手渡す。この場合、ロスパケットのデータブロックは欠落したまま再生が継続される。そのため、欠落したデータブロックに相当する音切れが発生する。
【００６３】
一方、図６の例のように、ロスパケット数（＝１）が復元可能パケット数（＝１）と同じである場合（Ｓ２６でＮＯ）、復元判断部１６は、ロスパケットＰＴ６を復元可能である判断する。この場合、復元判断部１６はさらに、未到達パケット数Ｒを算出する（Ｓ２７）。ＦＥＣブロック内のパケット数Ｎ＝１０であり、ステップＳ２４で格納したパケットはＰＴ７（ｎ＝７）であるため、未到達パケットは１０−７＝３となる。
【００６４】
未到達パケット数Ｒが０でないため（Ｓ２８でＮＯ）、同一ＦＥＣブロック内の最後のパケットＰＴ１０（冗長パケット）はまだ受信バッファ１２に格納されていない。そこで、復元判断部１６は、未到達パケット数Ｒと余裕度Ｙとを比較する（Ｓ２９）。未到達パケット数Ｒが余裕度Ｙよりも大きい場合（Ｓ２９でＹＥＳ）、たとえば、未到達パケット数Ｒが「３」であり、余裕度Ｙが「２」である場合、再生バッファ１９内のバッファ量が少な過ぎるため、ＦＥＣブロック内の最後のパケットＰＴ１０が受信バッファ１２に格納されるまで待って復元が実行される前に、再生バッファ１９のデータが枯渇する可能性が高い。このような場合、データの枯渇により発生する音切れ時間が長くなる可能性がある。そこで、復元判断部１６はロスパケットＰＴ６の復元を行わないと判断する。データ抽出部１７はステップＳ２９の判断結果に基づいて、ステップＳ２４で格納したパケットＰＴ７のデータブロックを抽出して再生バッファ１９に渡す。つまり、ロスパケットＰＴ６の復元をあきらめる。ロスパケットＰＴ６の復元をあきらめれば、そのデータブロック分の時間の音切れが発生する。しかしながら、復元するためにパケットＰＴ１０の到着を待つことにより音切れ時間が長くなるのを抑制できる。
【００６５】
一方、余裕度Ｙが４であれば、制御部１３はステップＳ２９で未到達パケット数Ｒが余裕度Ｙよりも小さいため、復元判断部１６は、復元処理を行うと判断する（Ｓ２９でＮＯ）。この場合、最後のパケットＴＰ１０の到着を待ってパケットＰＴ６を復元するまでに再生バッファ１９内のバッファ量が枯渇する可能性は低い。そのため、データ抽出部１７はパケットＰＴ７のデータブロックを抽出せずに動作を終了する。そして、パケットＰＴ１０を受信バッファ１２に格納したとき（Ｓ２４）、制御部１３は、未到達パケット数Ｒ＝０と判断する（Ｓ２８でＹＥＳ）。つまり、ＦＥＣブロックの末尾のパケットＰＴ１０を格納したと判断する。そのため、復元部１４はＦＥＣ処理を実行してロスパケットＰＴ６を復元する（Ｓ３１）。そして、パケットＰＴ６から配列番号順に、パケットＰＴ６〜ＰＴ９内のデータブロックを順次抽出して再生バッファ１９に順次渡す。この動作により、パケットＰＴ６のデータブロックは復元され、かつ、復元されたデータブロックから再生位置順にデータブロックが再生バッファ１９に順次格納される。そのため、再生部２１はデータブロックを再生位置順に順次デコードでき、音切れは発生しない。
【００６６】
［新たなコンテンツの再生指示を受けたときのデータブロック抽出処理］
ユーザ操作により新たなコンテンツデータの再生指示を受けたとき（Ｓ１１でＹＳ）、再生バッファ１９内に格納されていたデータブロックは削除される。つまり、再生バッファ１９はリセットされる。コンテンツの指定が切り換えられたためである。このとき、再生バッファ１９のバッファ量は０であるため、余裕度Ｙ＝−Ｒｅｆとなる（Ｓ３）。したがって、この場合、たとえパケットロスが発生しても、データ抽出処理におけるステップＳ２９で、復元判断部１６はロスパケットを復元しないと判断する（Ｓ２９でＹＥＳ）。つまり、バッファ量が基準バッファ量Ｒｅｆよりも小さい場合、データ抽出部１７は、パケットＰＴｎが受信バッファ１２に格納されるごとにデータブロックを抽出して再生バッファ１９に渡す。これにより、再生すべきコンテンツが切り換えされたときに新たなコンテンツが再生されるまでの遅延を短縮できる。
【００６７】
以上、本実施の形態によるコンテンツ配信システムでは、受信装置１は、パケットロスが発生していないときはパケットＰＴｎを受信するごとに、そのパケットＰＴｎからデータブロックを抽出して再生する。そのため、受信バッファでのバッファリングによる遅延は生じない。また、パケットロスが発生した場合、未到達パケット数と余裕度（バッファ量）とを比較する。これにより、バッファ量に余裕がある場合はＦＥＣブロックの末尾パケットＰＴ１０を受信するまでデータブロックの抽出を中止してロスパケットを復元することができ、バッファ量に余裕がない場合は、ロスパケットの復元をせずに受信したパケットＰＴｎのデータブロックを順次抽出することができる。そのため、受信装置１は、パケットロスが発生した場合であっても、音切れの発生を抑制でき、仮に発生しても音切れ時間を最小限に抑えることができる。
【００６８】
上述の本実施の形態では、再生バッファ１９のバッファ量をパケット相当数に換算し、未到達パケット数と比較したが、たとえば、未到達パケット数Ｒ、余裕度Ｙ、バッファ量ＢＭをそれぞれデータ量（ｂｙｔｅｓ）で定義してもよい。受信装置１は、ＦＥＣブロック当たりのデータ量に関する情報を予めＨＤＤ９０に格納している。受信装置１は、ステップＳ２７で、１ＦＥＣ当たりのデータ量から受信バッファ１２に格納済みのバッファ量（データ量）を差分して、未到達パケットのデータ量を算出する。そして、ステップＳ２９でデータ量と余裕度Ｙとを比較してもよい。この場合、余裕度Ｙはデータ量（ｂｙｔｅｓ）で示される。
【００６９】
さらに、受信装置１は、未到達パケットのデータ量に基づいて、受信装置１が未到達パケットを全て受信するまでに掛かる予想時間Ｔ１と、バッファ量ＢＭに基づいて再生バッファ１９に格納されているデータを再生し終えるまでに掛かる予想時間Ｔ２とを求め、予想時間Ｔ１及びＴ２に基づいて第１及び第２のパターンのいずれを採用するかを決定してもよい。具体的には、検知部２０はステップＳ３で予想時間Ｔ２から基準値Ｒｅｆ（ここでは時間）を差し引いて余裕度Ｙ（時間）を算出する。そして、復元判断部１６はステップＳ２９で、予想時間Ｔ１と余裕度Ｙとを比較し、第１及び第２のパターンのいずれを採用するかを決める。受信装置１は、バッファ量ＢＭと再生速度とに基づいて予想時間Ｔ２を算出する。
【００７０】
受信装置１は、送信装置１００と受信装置１との間の伝送レートに関する情報を保持しており、未到達パケットのデータ量と伝送レートとに基づいて予想時間Ｔ１を算出する。受信装置１は、他の方法で予想時間Ｔ１を求めてもよい。一般的に、パケットＰＴｎは等間隔で配信されるため、受信装置１も等間隔でパケットＰＴｎを受信する。そのため、受信装置１は、パケットＰＴｎの受信間隔に関する情報を持つ。この場合、受信装置１は、未到達パケットのデータ量に関する情報として未到達パケット数Ｒを用いて、未到達パケット数Ｒと受信間隔とに基づいて、予想時間Ｔ１を求めてもよい。なお、送信装置１００がデータパケットＰＴ９直後に間隔を空けずに冗長パケットＰＴ１０を送信する場合もある。この場合、受信装置１は、パケットＰＴ９を受信した後、受信間隔を空けずに冗長パケットＰＴ１０を受信するため、この点も考慮して予想時間Ｔ１を算出してもよい。
【００７１】
いずれにしても、本発明では、受信装置１は未到達パケットのデータ量に関する情報と、バッファ量に関する情報とに基づいて、第１及び第２のパターンのいずれを採用するかを決定する。
【００７２】
上述の例では、受信装置１がユーザ所望のコンテンツのストリーミング配信を送信装置１００に要求したが、送信装置１００がマルチキャスト配信を行っており、受信装置１が複数のチャンネルから所望のチャンネルに適宜切り換えるようにしてもよい。この場合であっても、チャンネルの切り換え時の動作は、上述の新たなコンテンツの再生指示を受けた場合の動作と同じである。
【００７３】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【００７４】
【図１】本発明の実施の形態にコンテンツ配信システムの全体構成を示す機能ブロック図である。
【図２】図１に示した送信装置で生成されるＦＥＣブロックのデータ構造を示す図である。
【図３】図１に示した送信装置で生成されるＦＥＣブロックを構成するパケットのデータ構造を示す図である。
【図４】図１に示した受信装置のハードウェア構成を示すブロック図である。
【図５】図１に示した受信装置の動作概要を説明するための図である。
【図６】図５に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図７】図６に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図８】図７に引き続き、図１に示した受信装置の動作概要を説明するための図である。
【図９】図１に示した受信装置の余裕度設定処理の詳細を示すフロー図である。
【図１０】図１に示した受信装置のコマンド処理の詳細を示すフロー図である。
【図１１】図１に示した受信装置のデータ抽出処理の詳細を示すフロー図である。
【符号の説明】
【００７５】
１ 受信装置
１０，１０２ 通信部
１１ 受付部
１２ 受信バッファ
１３ 制御部
１４ 復元部
１５ パケットロス判断部
１６ 復元判断部
１７ データ抽出部
１８ データ消去部
１９ 再生バッファ
２０ 検知部
２１ 再生部
１００ 送信装置
１０１ ブロック生成部
【特許請求の範囲】
【請求項１】
送信装置と、受信装置とを備えたコンテンツ配信システムであって、
前記送信装置は、
コンテンツデータをパケット化及び冗長符号化し、前記コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックを生成するブロック生成手段と、
前記ＦＥＣブロックを構成する複数の前記パケットを順次送信する送信手段とを備え、
前記受信装置は、
前記送信装置から送信された前記パケットを受信する受信手段と、
前記受信手段により受信された前記パケットを格納する受信バッファ手段と、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを格納する再生バッファ手段と、
前記再生バッファ手段に格納された順に、前記データブロックを再生する再生手段と、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するパケットロス判断手段と、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知する検知手段と、
前記パケットロスが発生したとき、前記再生バッファ手段のデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファ手段に格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する復元判断手段と、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元する復元手段と、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するデータ抽出手段とを備えることを特徴とするコンテンツ配信システム。
【請求項２】
コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと、冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックの前記複数のパケットを順次受信する受信手段と、
前記受信手段により受信された前記パケットを格納する受信バッファ手段と、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを格納する再生バッファ手段と、
前記再生バッファ手段に格納された順に、前記データブロックを再生する再生手段と、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するパケットロス判断手段と、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知する検知手段と、
前記パケットロスが発生したとき、前記再生バッファ手段のデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファ手段に格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する復元判断手段と、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元する復元手段と、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するデータ抽出手段とを備えることを特徴とする受信装置。
【請求項３】
請求項２に記載の受信装置であってさらに、
前記受信手段により受信されたパケットの属するＦＥＣブロックが前記受信バッファ手段に格納されているパケットの属するＦＥＣブロックと異なるとき、前記受信バッファ手段に格納されたパケットを消去するパケット消去手段を備えることを特徴とする受信装置。
【請求項４】
請求項２又は請求項３に記載の受信装置であってさらに、
新たなコンテンツデータの再生指示を受けたとき、前記再生バッファ手段に格納されているデータブロックを消去するデータブロック消去手段を備えることを特徴とする受信装置。
【請求項５】
請求項２〜請求項４のいずれか１項に記載の受信装置であって、
前記復元手段はさらに、前記検知手段により検知されたデータ量が基準値未満の場合、ロスパケットを復元しないことを特徴とする受信装置。
【請求項６】
コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと、冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックの前記複数のパケットを順次受信する受信装置内のコンピュータに、
前記受信された前記パケットを受信バッファ手段に格納するステップと、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを再生バッファ手段に格納するステップと、
前記再生バッファ手段に格納された順に、前記データブロックを再生するステップと、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するステップと、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知するステップと、
前記パケットロスが発生したとき、前記検知されたデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファに格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断するステップと、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元するステップと、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するステップとを実行させる再生プログラム。
【請求項１】
送信装置と、受信装置とを備えたコンテンツ配信システムであって、
前記送信装置は、
コンテンツデータをパケット化及び冗長符号化し、前記コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックを生成するブロック生成手段と、
前記ＦＥＣブロックを構成する複数の前記パケットを順次送信する送信手段とを備え、
前記受信装置は、
前記送信装置から送信された前記パケットを受信する受信手段と、
前記受信手段により受信された前記パケットを格納する受信バッファ手段と、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを格納する再生バッファ手段と、
前記再生バッファ手段に格納された順に、前記データブロックを再生する再生手段と、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するパケットロス判断手段と、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知する検知手段と、
前記パケットロスが発生したとき、前記再生バッファ手段のデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファ手段に格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する復元判断手段と、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元する復元手段と、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するデータ抽出手段とを備えることを特徴とするコンテンツ配信システム。
【請求項２】
コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと、冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックの前記複数のパケットを順次受信する受信手段と、
前記受信手段により受信された前記パケットを格納する受信バッファ手段と、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを格納する再生バッファ手段と、
前記再生バッファ手段に格納された順に、前記データブロックを再生する再生手段と、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するパケットロス判断手段と、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知する検知手段と、
前記パケットロスが発生したとき、前記再生バッファ手段のデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファ手段に格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断する復元判断手段と、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元する復元手段と、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するデータ抽出手段とを備えることを特徴とする受信装置。
【請求項３】
請求項２に記載の受信装置であってさらに、
前記受信手段により受信されたパケットの属するＦＥＣブロックが前記受信バッファ手段に格納されているパケットの属するＦＥＣブロックと異なるとき、前記受信バッファ手段に格納されたパケットを消去するパケット消去手段を備えることを特徴とする受信装置。
【請求項４】
請求項２又は請求項３に記載の受信装置であってさらに、
新たなコンテンツデータの再生指示を受けたとき、前記再生バッファ手段に格納されているデータブロックを消去するデータブロック消去手段を備えることを特徴とする受信装置。
【請求項５】
請求項２〜請求項４のいずれか１項に記載の受信装置であって、
前記復元手段はさらに、前記検知手段により検知されたデータ量が基準値未満の場合、ロスパケットを復元しないことを特徴とする受信装置。
【請求項６】
コンテンツデータを分割した複数のデータブロックを含む複数のデータパケットと、冗長パケットとで構成される複数のＦＥＣ（Forward Error Correction)ブロックの前記複数のパケットを順次受信する受信装置内のコンピュータに、
前記受信された前記パケットを受信バッファ手段に格納するステップと、
前記受信バッファ手段に格納された前記データパケットから抽出された前記データブロックを再生バッファ手段に格納するステップと、
前記再生バッファ手段に格納された順に、前記データブロックを再生するステップと、
前記パケットが前記受信バッファ手段に格納されるごとに、前記格納されたパケットが属するＦＥＣブロックでパケットロスが発生しているか否かを判断するステップと、
前記再生バッファ手段に格納されているデータブロックのデータ量を検知するステップと、
前記パケットロスが発生したとき、前記検知されたデータ量と、前記ＦＥＣブロック内のパケットのうち前記受信バッファに格納されたパケット以降に前記受信装置が受信する予定のパケットのデータ量とに基づいて、ロスパケットを復元するか否か判断するステップと、
前記ロスパケットを復元するとき、前記ＦＥＣブロックのロスパケット以外の他のパケットが前記受信バッファ手段に格納された後、前記他のパケットを用いて前記ロスパケットを復元するステップと、
前記パケットロスが発生していないとき、及び、前記ロスパケットを復元しないとき、前記受信バッファ手段に格納されたデータパケットのデータブロックを抽出して前記再生バッファ手段に出力し、前記ロスパケットを復元するとき、前記ロスパケットを復元した後、前記復元されたロスパケット以降のデータパケットからデータブロックを順次抽出して前記再生バッファ手段に出力するステップとを実行させる再生プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−１１９００９（Ｐ２０１０−１１９００９Ａ）
【公開日】平成２２年５月２７日（２０１０．５．２７）
【国際特許分類】
【出願番号】特願２００８−２９２１２９（Ｐ２００８−２９２１２９）
【出願日】平成２０年１１月１４日（２００８．１１．１４）
【出願人】（００００００２７３）オンキヨー株式会社 (502)
【Ｆターム（参考）】
【公開日】平成２２年５月２７日（２０１０．５．２７）
【国際特許分類】
【出願日】平成２０年１１月１４日（２００８．１１．１４）
【出願人】（００００００２７３）オンキヨー株式会社 (502)
【Ｆターム（参考）】
[ Back to top ]