JP2012134758A - 映像配信装置及び映像配信方法 - Google Patents

Abstract

【課題】映像データを効率よく再送することを課題とする。
【解決手段】エンコーダ１０は、マルチキャストアドレスが設定された映像ストリームを送信する。また、エンコード１０は、マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得する。また、エンコーダ１０は、複数の端末から映像ストリームに含まれるデータパケットの再送要求を受け付ける。さらに、エンコーダ１０は、再送要求が受け付けられたデータパケットの送信時刻から、先に取得した往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、端末で映像ストリームを再現するのに必要なパケットを送信する。
【選択図】図２

Description

本発明は、映像配信装置及び映像配信方法に関する。

映像データをリアルタイムで配信する場合には、パケットロスによる再送を抑制するエラー訂正方法が用いられる。誤り訂正方法の一例としては、送信時に冗長なデータを付加した上で送信することにより、受信側で未到着となったデータを冗長なデータから復元する前方誤り訂正、いわゆるＦＥＣ（Forward Error Correction）が使用される。

かかるＦＥＣを用いる技術の一例としては、ネットワークを介して端末に送信するデータに付加するＦＥＣを送信レートの増加に伴って増加させるデータ伝送サーバが挙げられる。他の一例としては、再送方式による使用帯域と冗長符号方式による使用帯域とメディアデータの使用帯域との和の送信帯域が一定となるように、各使用帯域を適応的に制御するメディア伝送装置が挙げられる。

このようにデータパケットにＦＥＣパケットを付加して配信する技術の他、データパケットを先行して配信した上でＦＥＣパケットを後続して送信する技術もある。一例としては、データ配信端末がリターンを伴わない片方向の同報配信を複数の受信端末に実行する場合に用いられるデータ同報配信方法が挙げられる。このデータ同報配信方法では、データ配信端末が配信データに続けて誤り訂正用チェックデータを同報配信する。一方、受信端末は、データ配信端末から受信した受信データを誤り訂正用チェックデータと結合した上で誤り訂正を実行する。

特開２００１−３３３０６１号公報 特開２００４−２８９６２１号公報 特開２００５−０６４６４８号公報

しかしながら、上記の従来技術では、映像データのリアルタイム配信にマルチキャスト（multicast）を使用する場合に、映像データを効率よく再送することができないという問題がある。

例えば、上記のデータ伝送サーバ及びメディア伝送装置の場合には、受信端末から再送要求を受け付ける度に、映像データがマルチキャストグループに含まれる全ての受信端末に再送される。このため、上記のデータ伝送サーバ及びメディア伝送装置では、エラーが発生していない受信端末にも映像データを重複して再送することになる。よって、上記のデータ伝送サーバ及びメディア伝送装置では、映像データを重複して再送することにより、送信端末及びネットワークのリソースが無駄に消費されてしまう。

また、上記のデータ同報配信方法の場合には、データ配信端末によって生成された誤り訂正用チェックデータが受信端末におけるエラーの有無によらず、受信端末に同報配信される。このため、上記のデータ同報配信方法では、受信端末でエラーが発生していない場合にも、配信データが受信端末に重複して同報配信される。さらに、上記のデータ同報配信方法では、誤り訂正用チェックデータだけで映像データが復元できない場合に、誤り訂正用チェックデータに加えて、配信データを改めて再送せねばならない。よって、上記のデータ同報配信方法においても、上記のデータ伝送サーバ及びメディア伝送装置と同様に、送信端末及びネットワークのリソースが無駄に消費されてしまう。

開示の技術は、上記に鑑みてなされたものであって、映像データを効率よく再送できる映像配信装置及び映像配信方法を提供することを目的とする。

本願の開示する映像配信装置は、マルチキャストアドレスが設定された映像ストリームを送信する第１の送信部を有する。さらに、前記映像配信装置は、前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得する取得部を有する。さらに、前記映像配信装置は、前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付ける受付部を有する。さらに、前記映像配信装置は、前記再送要求が受け付けられたデータパケットの送信時刻から前記往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する第２の送信部を有する。

本願の開示する映像配信装置の一つの態様によれば、映像データを効率よく再送できるという効果を奏する。

図１は、実施例１に係る映像配信システムの構成を示す図である。 図２は、実施例１に係るエンコーダの構成を示すブロック図である。 図３は、ＦＥＣ情報記憶部に記憶される情報の構成例を示す図である。 図４は、ＦＥＣ情報記憶部に記憶される情報の構成例を示す図である。 図５は、ＲＴＴ記憶部に記憶される情報の構成例を示す図である。 図６は、ＲＴＴ記憶部に記憶される情報の構成例を示す図である。 図７は、再送要求記憶部に記憶される情報の構成例を示す図である。 図８は、受付状況記憶部に記憶される情報の構成例を示す図である。 図９は、再送要求合計値のデクリメントを説明するための図である。 図１０は、実施例１に係る第１の送信処理の手順を示すフローチャートである。 図１１は、実施例１に係る第２の送信処理の手順を示すフローチャートである。 図１２は、デコーダにおけるパケットの受信順序の一例を示す図である。 図１３は、デコーダにおけるパケットの受信順序の一例を示す図である。 図１４は、デコーダにおけるパケットの受信順序の一例を示す図である。 図１５は、実施例２に係る映像配信プログラムを実行するコンピュータの一例について説明するための図である。

以下に、本願の開示する映像配信装置及び映像配信方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
図１は、実施例１に係る映像配信システムの構成を示す図である。図１に示すように、映像配信システム１は、エンコーダ１０と、カメラ２０と、デコーダ３０Ａ〜３０Ｃと、表示装置４０Ａ〜４０Ｃとが収容される。なお、図１の例では、カメラ２０によって撮像された映像データをエンコーダ１０からデコーダ３０Ａ〜３０Ｃへリアルタイムで配信する場合を想定する。

これらエンコーダ１０及びデコーダ３０Ａ〜３０Ｃの間は、ネットワーク３を介して互いに通信可能に接続される。かかるネットワーク３の一態様としては、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの通信網が挙げられる。なお、図１の例では、デコーダ３０Ａ〜３０Ｃを３つ収容する場合を例示したが、少なくともデコーダを１つ収容していればよく、任意の数のデコーダが収容される場合に適用できる。

このうち、カメラ２０は、映像を撮像する撮像装置である。かかるカメラ２０の一例としては、ＣＣＤ（Charge Coupled Device）やＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像装置が挙げられる。このカメラ２０によって撮像された映像データはエンコーダ１０へ出力される。

エンコーダ１０は、カメラ２０によって出力された映像データをエンコードする装置である。このエンコーダ１０は、エンコード後の映像データをデコーダ３０Ａ〜３０Ｃに配信する。このとき、エンコーダ１０は、デコーダ３０Ａ〜３０Ｃが参加するマルチキャストグループに付与されるマルチキャストアドレスが設定された映像ストリームをネットワーク３へ送信することにより、映像データをデコーダ３０Ａ〜３０Ｃへマルチキャストする。なお、図１の例では、メディアデータの伝送方式としてＲＴＰ（Realtime Transport Protocol）を採用する場合を説明するが、他の伝送方式を採用することとしてもかまわない。

このようにしてエンコーダ１０が配信する映像は、予め指定された領域を監視するために撮像された監視映像であってもよいし、また、視聴者に向けて発せられる放送であってもよい。また、図１の例では、カメラ２０がエンコーダ１０に映像データを供給する場合を例示したが、必ずしも映像データがカメラ２０によって供給される必要はない。例えば、所定の読取装置を介して、フレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの記録媒体から、映像データを取得することとしてもよい。

デコーダ３０Ａ〜３０Ｃは、エンコーダ１０によって配信された映像データをデコードする装置である。このデコーダ３０Ａ〜３０Ｃは、デコード後の映像データを表示装置４０Ａ〜４０Ｃで再生させる。なお、以下では、デコーダ３０Ａ〜３０Ｃを区別せずに総称する場合に「デコーダ３０」と総称することとする。

これらエンコーダ１０のエンコード機能及びデコーダ３０Ａ〜３０Ｃのデコード機能は、ソフトウェアによって実現してもよいし、また、ＬＳＩ（Large Scale Integration）等の集積回路によって実現することとしてもよい。

表示装置４０Ａ〜４０Ｃは、デコーダから供給される映像を表示する表示デバイスである。かかる表示装置４０Ａ〜４０Ｃの一例としては、モニタ（monitor）、ディスプレイ（display）やタッチパネル（touch panel）などの表示デバイス全般を適用できる。なお、以下では、表示装置４０Ａ〜４０Ｃを区別せずに総称する場合に「表示装置４０」と総称することとする。

ここで、本実施例に係るエンコーダ１０は、マルチキャストアドレスが設定された映像ストリームを送信する。また、本実施例に係るエンコーダ１０は、マルチキャストアドレスに含まれる複数のデコーダ３０Ａ〜３０Ｃと自装置との間における往復遅延時間を取得する。また、本実施例に係るエンコーダ１０は、複数のデコーダ３０Ａ〜３０Ｃから映像ストリームに含まれるデータパケットの再送要求を受け付ける。さらに、本実施例に係るエンコーダ１０は、再送要求が受け付けられたデータパケットの送信時刻から最大の往復遅延時間が少なくとも経過した後に、デコーダ３０Ａ〜３０Ｃで映像ストリームを再現するのに必要なパケットを送信する。

このように、本実施例に係るエンコーダ１０は、映像ストリームをマルチキャストする場合にデータパケットのみを先行して配信し、映像ストリームの再現に必要なパケットを再送する。このため、本実施例に係るエンコーダ１０では、映像ストリームの再現にエンコーダ１０から再送されるパケットが必要ない場合には、配信先のデコーダ３０Ａ〜３０Ｃにパケットは送信しない。よって、本実施例に係るエンコーダ１０によれば、映像データを効率よく再送することが可能になる。

さらに、本実施例に係るエンコーダ１０は、配信先のデコーダ３０Ａ〜３０Ｃとの間の最大往復遅延時間を待ってから映像ストリームの再現に必要なパケットを再送する。このため、本実施例に係るエンコーダ１０では、デコーダ３０Ａ〜３０Ｃの再送要求が全て届いたと推定される時点で再送できる。それゆえ、本実施例に係るエンコーダ１０によれば、デコーダ３０Ａ〜３０Ｃから再送要求が届ききらずにパケットを再送することにより、一部のデコーダ３０でパケットの再送漏れが発生する事態を防止できる。また、本実施例に係るエンコーダ１０によれば、デコーダ３０Ａ〜３０Ｃから再送要求を受け付けてからパケットを再送するまでの時間が過度に引き延ばされることにより、パケットの再送に遅延が生じる事態も防止できる。

［エンコーダ１０の構成］
続いて、本実施例に係るエンコーダ１０の構成について説明する。図２は、実施例１に係るエンコーダの構成を示すブロック図である。図２に示すように、エンコーダ１０は、映像バッファ１１ａと、符号化部１１と、ＦＥＣバッファ１２ａと、ＦＥＣ情報記憶部１２ｂと、生成部１２と、ＲＴＴ記憶部１３ａと、取得部１３と、再送要求記憶部１４ａと、受付部１４とを有する。さらに、エンコーダ１０は、受付状況記憶部１５ａと、判定部１５と、第１の送信部１６と、第２の送信部１７とを有する。

このうち、映像バッファ１１ａは、後述の符号化部１１によって符号化された映像データを蓄積するバッファ（buffer）である。このようにして映像バッファ１１ａに蓄積された映像データは、後述の第１の送信部１６によってデコーダ３０Ａ〜３０Ｃにマルチキャストされる。なお、映像バッファ１１ａに蓄積された映像データは任意の契機で削除できる。例えば、映像データが全てのデコーダ３０Ａ〜３０Ｃに受信されたことが確認された時点で削除することとしてもよいし、また、タイマーにより所定の時間が計測された時点で削除することとしてもよい。

かかる映像バッファ１１ａの一例としては、ＶＲＡＭ（Video Random Access Memory）、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子を採用できる。他の一例として、映像バッファ１１ａには、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。

符号化部１１は、カメラ２０によって出力された映像データを符号化する処理部である。この符号化部１１は、符号化した映像データを映像バッファ１１ａに格納する。かかる圧縮符号化方式の一例としては、ＭＰＥＧ（Moving Picture Experts Group phase）２やＭＰＥＧ４などの任意の圧縮方式を採用できる。

ＦＥＣバッファ１２ａは、後述の生成部１２によって符号化データから生成されたＦＥＣ（Forward Error Correction）データを蓄積するバッファである。このようにしてＦＥＣバッファ１２ａに蓄積されたＦＥＣデータは、後述の判定部１５による指示の下、後述の第２の送信部１７によってデコーダ３０Ａ〜３０Ｃにマルチキャストされる。

かかるＦＥＣバッファ１２ａの一例としては、ＶＲＡＭ（Video Random Access Memory）、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子を採用できる。他の一例として、ＦＥＣバッファ１２ａには、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。

ＦＥＣ情報記憶部１２ｂは、後述の生成部１２によって生成されたＦＥＣデータに関する管理情報を記憶する記憶部である。一例として、ＦＥＣ情報記憶部１２ｂは、再送の要否を判定するタイミングが適切であるか否かを判断するために、後述の判定部１５によって参照される。

かかる管理情報の一態様としては、ＦＥＣ番号、開始映像番号、終了映像番号、ＦＥＣデータの生成時刻及びＦＥＣパケットの判定時刻が対応付けられたデータを採用できる。ここで言う「ＦＥＣ番号」とは、ＦＥＣデータに付与されたシーケンス番号を指す。また、「映像番号」とは、映像ストリームに含まれる１フレームの映像データに付与されたシーケンス番号を指す。また、「開始映像番号」とは、ＦＥＣデータを生成するのに使用された映像データの映像番号のうち最も小さい映像番号を指す。また、「終了映像番号」とは、ＦＥＣデータを生成するのに使用された映像データの映像番号のうち最も大きい映像番号を指す。また、「生成時刻」とは、ＦＥＣデータが生成された時刻を指す。また、「判定時刻」とは、後述の第２の送信部１７によってＦＥＣデータをデコーダ３０Ａ〜３０Ｃに送信させる必要があるか否かを後述の判定部１５に判定させる時刻を指す。

図３及び図４は、ＦＥＣ情報記憶部に記憶される情報の構成例を示す図である。図３の例では、映像番号１〜映像番号４の映像データを使用して生成されたＦＥＣ番号１のＦＥＣデータに関する管理情報が登録された場合を示す。また、図４の例では、映像番号５〜映像番号８の映像データを使用して生成されたＦＥＣ番号２のＦＥＣデータに関する管理情報がさらに追加して登録された場合を示す。これら図３及び図４の例では、４つの映像データにつき１つのＦＥＣデータが生成され、ＦＥＣデータが１つの映像データを復元可能である場合を想定する。なお、図３及び図４の例では、４つの映像データにつき１つのＦＥＣデータを生成する場合を例示するが、ＦＥＣデータの生成に使用する映像データの数は任意であってもよい。

図３に示す例では、ＦＥＣ番号１のＦＥＣデータが生成時刻「2010/06/01 10:00:00.123」に映像番号１〜映像番号４の映像データから生成されたことを示す。さらに、ＦＥＣ番号１のＦＥＣデータの場合には、後述の第２の送信部１７によってＦＥＣ番号１のＦＥＣデータをデコーダ３０Ａ〜３０Ｃに送信させる必要があるか否かを判定時刻「2010/06/01 10:00:00.243」に後述の判定部１５に判定させることを示す。図４に示す例では、ＦＥＣ番号２のＦＥＣデータが生成時刻「2010/06/01 10:00:00.678」に映像番号５〜映像番号８の映像データから生成されたことを示す。さらに、ＦＥＣ番号２のＦＥＣデータの場合には、後述の第２の送信部１７によってＦＥＣ番号２のＦＥＣデータをデコーダ３０Ａ〜３０Ｃに送信させる必要があるか否かを判定時刻「2010/06/01 10:00:00.751」に後述の判定部１５に判定させることを示す。なお、後述の判定部１５による送信要否の判定が終了したレコードの値はゼロに初期化される。また、上記の管理情報は、必ずしもテーブル形式で格納される必要はなく、他の形式で格納することとしてもかまわない。

生成部１２は、映像ストリームのうち所定のフレーム数にわたって連続する映像データからＦＥＣデータを生成する処理部である。一例としては、生成部１２は、映像ストリームのうち連続する４フレームの映像データのビット単位で排他的論理和（ＸＯＲ：eXclusive OR）を算出することにより、ＦＥＣデータのパリティ情報を生成する。

例えば、映像番号１〜映像番号４の映像データを用いてＦＥＣ番号１のＦＥＣデータを生成する場合を想定する。この場合には、ＦＥＣ番号１のＦＥＣデータの先頭ビットは、映像番号１の映像データの先頭ビット、映像番号２の映像データの先頭ビット、映像番号３の映像データの先頭ビット及び映像番号４の映像データの先頭ビットをそれぞれ加算することにより算出される。同様にして、ＦＥＣデータの２番目のビットからＮ番目のビットが算出される。このようにして、生成部１２は、映像番号１〜映像番号４の映像データからＦＥＣ番号１のＦＥＣデータを生成する。

ＲＴＴ記憶部１３ａは、往復遅延時間、いわゆるＲＴＴ（Round Trip Time）を記憶する記憶部である。一例として、ＲＴＴ記憶部１３ａは、ＦＥＣデータの生成時刻からＦＥＣデータの判定時刻を決定するために生成部１２によって参照される。なお、ＲＴＴ記憶部１３ａには、後述の取得部１３によって取得された往復遅延時間が登録される。

一態様として、ＲＴＴ記憶部１３ａは、自装置と各デコーダ３０との間における往復遅延時間を記憶する。図５及び図６は、ＲＴＴ記憶部に記憶される情報の構成例を示す図である。図５の例では、ＦＥＣ番号１のＦＥＣデータが生成された時点における往復遅延時間を示す。また、図６の例では、ＦＥＣ番号２のＦＥＣデータが生成された時点における往復遅延時間を指す。なお、図５及び図６の例では、デコーダ３０ＡのＩＰアドレスが「10.0.0.1」であり、デコーダ３０ＢのＩＰアドレスが「10.0.0.2」であり、また、デコーダ３０ＣのＩＰアドレスが「10.0.0.3」であるものとする。

図５に示す例で言えば、エンコーダ１０とデコーダ３０Ａとの間における往復遅延時間が「98(ms)」であることを示す。さらに、エンコーダ１０とデコーダ３０Ｂとの間における往復遅延時間が「71(ms)」であることを示す。さらに、エンコーダ１０とデコーダ３０Ｃとの間における往復遅延時間が「120(ms)」であることを示す。また、図６に示す例で言えば、エンコーダ１０とデコーダ３０Ａとの間における往復遅延時間が「66(ms)」であることを示す。さらに、エンコーダ１０とデコーダ３０Ｂとの間における往復遅延時間が「73(ms)」であることを示す。さらに、エンコーダ１０とデコーダ３０Ｃとの間における往復遅延時間が「69(ms)」であることを示す。

取得部１３は、自装置と各デコーダ３０との間における往復遅延時間を取得する処理部である。一例としては、取得部１３は、所定の期間、例えば５分間が経過する度に、往復遅延時間の計測を指示するパケットを各デコーダ３０に送信する。その上で、取得部１３は、デコーダ３０Ａ〜３０Ｃによってそれぞれ計測された往復遅延時間を受信し、各デコーダ３０Ａ〜３０Ｃの往復遅延時間をＲＴＴ記憶部１３ａの該当フィールドに上書きする。これによって、取得部１３は、ＲＴＴ記憶部１３ａに記憶される各デコーダ３０の往復遅延時間を更新する。なお、ここでは、取得部１３が往復遅延時間を主体的に収集する場合を例示したが、デコーダ３０がエンコーダ１０から再送されたパケットの往復遅延時間を計測してエンコーダ１０にアップロードすることとしてもよい。

ここで、図３〜図６を用いて、生成部１２によるＦＥＣデータの判定時刻の決定方法を説明する。生成部１２は、映像データからＦＥＣデータを生成する度に、ＦＥＣデータの生成時刻と、ＲＴＴ記憶部１３ａに記憶された往復遅延時間とを用いて、ＦＥＣデータの判定時刻を決定する。なお、図５及び図６に示した往復遅延時間の網掛け部分は、デコーダ３０Ａ〜３０Ｃの中で最大の往復遅延時間を示す。

図３に示すように、ＦＥＣ番号１のＦＥＣデータが生成時刻「2010/06/01 10:00:00.123」に生成された場合には、生成部１２は、図５に示した各デコーダ３０の往復遅延時間のうち最大値を持つデコーダ３０Ｃの往復遅延時間「120(ms)」を生成時刻に加算する。これによって、生成部１２は、図３に示した判定時刻「2010/06/01 10:00:00.243」を算出する。また、図４に示すように、ＦＥＣ番号２のＦＥＣデータが生成時刻「2010/06/01 10:00:00.678」に生成された場合には、生成部１２は、図６に示した各デコーダ３０の往復遅延時間のうち最大値を持つデコーダ３０Ｂの往復遅延時間「73(ms)」を生成時刻に加算する。これによって、生成部１２は、図４に示した判定時刻「2010/06/01 10:00:00.751」を算出する。

このように、生成部１２は、ＲＴＴ記憶部１３ａに記憶された各デコーダ３０の往復遅延時間のうち最大の往復遅延時間をＦＥＣデータの生成時刻に加算することにより、ＦＥＣデータの判定時刻を決定する。これによって、生成部１２は、デコーダ３０Ａ〜３０Ｃから再送要求が届ききらいない段階で後述の第２の送信部１７によってパケットが再送されることを防止する。さらに、生成部１２は、デコーダ３０Ａ〜３０Ｃから再送要求を受け付けてからパケットを再送するまでの時間が過度に引き延ばされることを防止する。

図２の説明に戻り、再送要求記憶部１４ａは、デコーダ３０ごとにＦＥＣデータが復元対象とする映像データに関する再送要求の有無を記憶する記憶部である。一例として、再送要求記憶部１４ａは、後述の第２の送信部１７に送信させるパケットの有無、さらに、送信させる場合にはパケットの内訳を決定するための後述の受付状況記憶部１５ａを生成するために、後述の判定部１５によって参照される。なお、再送要求記憶部１４ａには、デコーダ３０から再送要求が受け付けられた場合にその旨を示す情報が後述の受付部１４によって登録される。

一態様として、再送要求記憶部１４ａは、デコーダ３０のＩＰアドレスと、各映像番号の再送要求の有無とが対応付けられたデータを記憶する。図７は、再送要求記憶部に記憶される情報の構成例を示す図である。この図７の例では、映像番号のフィールドに記憶されている「０」は、デコーダ３０から再送要求が受け付けられていないことを示し、映像番号のフィールドに記憶される「１」は、デコーダ３０から再送要求が受け付けられたことを示す。また、図７の例では、図５及び図６と同様に、デコーダ３０ＡのＩＰアドレスが「10.0.0.1」であり、デコーダ３０ＢのＩＰアドレスが「10.0.0.2」であり、また、デコーダ３０ＣのＩＰアドレスが「10.0.0.3」であるものとする。

図７に示す例で言えば、デコーダ３０Ａから映像番号１及び映像番号３の映像データの再送要求を受け付けたことを示す。さらに、デコーダ３０Ｂから映像番号２の映像データの再送要求を受け付けたことを示す。さらに、デコーダ３０Ｃから映像番号１の映像データの再送要求を受け付けたことを示す。なお、各映像番号のフィールドの初期値は、「０」であり、後述の受付部１４によって再送要求が受け付けられた場合に「０」が「１」に更新される。

受付部１４は、デコーダ３０Ａ〜３０Ｃから映像データの再送要求を受け付ける処理部である。一例として、受付部１４は、デコーダ３０から再送要求を受け付けた場合に、再送要求記憶部１４ａに記憶されたフィールドのうち、再送要求を行ったデコーダ３０及び再送要求が行われた映像データの映像番号に該当するフィールドを「０」から「１」に更新する。

受付状況記憶部１５ａは、ＦＥＣデータごとにそのＦＥＣデータが復元対象とする映像データに関するデコーダ３０からの再送要求の受付状況を記憶する記憶部である。一例として、受付状況記憶部１５ａは、後述の第２の送信部１７に送信させるパケットの有無、さらに、送信させる場合にはパケットの内訳を決定するために、後述の判定部１５によって参照される。なお、受付状況記憶部１５ａは、再送要求記憶部１４ａによってデコーダ３０ごとに記憶された各映像番号の再送要求の有無を用いて後述の判定部１５によって生成される。

一態様として、受付状況記憶部１５ａは、ＦＥＣデータのＦＥＣ番号と、ＦＥＣデータが復元対象とする映像データ別の再送要求合計値とが対応付けられたデータを記憶する。ここで言う「再送要求合計値」とは、１つの映像データに関し、デコーダ３０Ａ〜３０Ｃから受け付けた再送要求の合計値を指す。

図８は、受付状況記憶部に記憶される情報の構成例を示す図である。図８に示す映像番号のフィールドに記憶されている値は、上記の再送要求合計値を指す。図８に示す例で言えば、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号１〜４の映像データのうち、エンコーダ１０が映像番号１の再送要求を２つのデコーダ３０から受け付けていることを示す。さらに、エンコーダ１０が映像番号２の再送要求を１つのデコーダ３０から受け付けていることを示す。さらに、エンコーダ１０が映像番号３の再送要求を１つのデコーダ３０から受け付けていることを示す。

判定部１５は、後述の第１の送信部１６によってマルチキャストされた映像データのうち、後述の第２の送信部１７に再送させるパケットの有無、さらに、再送させる場合にはそのパケットの内訳を決定する処理部である。

これを説明すると、判定部１５は、図示しないタイムスタンプから得られる現時刻がＦＥＣ情報記憶部１２ｂに記憶されたＦＥＣデータの判定時刻に至ったか否かを監視する。図３に示す例で言えば、判定部１５は、ＦＥＣ番号１のＦＥＣデータの判定時刻「2010/06/01 10:00:00.243」になるまで待機し、現時刻が判定時刻「2010/06/01 10:00:00.243」に至った段階で次のような処理を起動する。

すなわち、判定部１５は、図示しないタイムスタンプから得られる現時刻がＦＥＣデータの判定時刻になった場合に、再送要求記憶部１４ａを用いて、受付状況記憶部１５ａ内における各映像番号ごとの再送要求合計値を生成する。

ここで、図７及び図８を用いて、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号１〜４の再送要求合計値を生成する場合を説明する。このうち、映像番号１の映像データについては、デコーダ３０Ａ及びデコーダ３０Ｃから再送要求を受け付けている一方で、デコーダ３０Ｂからは再送要求を受け付けていない。よって、判定部１５は、デコーダ３０Ａ〜３０Ｃの再送要求を合計することにより算出した映像番号１の再送要求合計値「２」を受付状況記憶部１５ａに書き込む。また、映像番号２の映像データについては、デコーダ３０Ｂから再送要求を受け付けている一方で、デコーダ３０Ａ及びデコーダ３０Ｃからは再送要求を受け付けていない。よって、判定部１５は、デコーダ３０Ａ〜３０Ｃの再送要求を合計することにより算出した映像番号２の再送要求合計値「１」を受付状況記憶部１５ａに書き込む。また、映像番号３の映像データについては、デコーダ３０Ａから再送要求を受け付けている一方で、デコーダ３０Ｂ及びデコーダ３０Ｃからは再送要求を受け付けていない。よって、判定部１５は、デコーダ３０Ａ〜３０Ｃの再送要求を合計することにより算出した映像番号３の再送要求合計値「１」を受付状況記憶部１５ａに書き込む。また、映像番号４の映像データについては、デコーダ３０Ａ〜３０Ｃのいずれからも再送要求を受け付けていない。よって、判定部１５は、デコーダ３０Ａ〜３０Ｃの再送要求を合計することにより算出した映像番号４の再送要求合計値「０」を受付状況記憶部１５ａに書き込む。

そして、判定部１５は、各映像番号の再送要求合計値の論理和がゼロよりも大きいか否かを判定する。つまり、判定部１５は、各映像番号の再送要求合計値のうち少なくともいずれか１つがゼロよりも大きいか否かを判定する。図８の例で言えば、映像番号１、映像番号２及び映像番号３の再送要求合計値がいずれもゼロより大きいので、判定部１５によって各映像番号の再送要求合計値の論理和がゼロよりも大きいと判定される。

このとき、判定部１５は、各映像番号の再送要求合計値の論理和がゼロよりも大きい場合に、各映像番号の再送要求合計値を１つずつデクリメントする。図９は、再送要求合計値のデクリメントを説明するための図である。図９に示すように、判定部１５は、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号１の再送要求合計値「２」を１つデクリメントして「１」に更新する。さらに、判定部１５は、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号２の再送要求合計値「１」を１つデクリメントして「０」に更新する。さらに、判定部１５は、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号３の再送要求合計値「１」を１つデクリメントして「０」に更新する。さらに、判定部１５は、ＦＥＣ番号１のＦＥＣデータが復元対象とする映像番号４の再送要求合計値「０」を１つデクリメントして「−１」に更新する。

その後、判定部１５は、デクリメント後の各映像番号の再送要求合計値の論理和がゼロであるか否かを判定する。つまり、判定部１５は、デクリメント後の各映像番号の再送要求合計値すべてがゼロであるか否かを判定する。図９の例で言えば、映像番号１の再送要求合計値がゼロよりも大きいので、判定部１５によってデクリメント後の各映像番号の再送要求合計値の論理和がゼロよりも大きいと判定される。

第１の送信部１６は、映像バッファ１１ａに蓄積された符号化データをデコーダ３０Ａ〜３０Ｃに送信する処理部である。かかる第１の送信部１６は、デコーダ３０Ａ〜３０Ｃが参加するマルチキャストグループに付与されるマルチキャストアドレスを映像データのヘッダに設定した上でその映像データをネットワーク３へ送信する。これによって、第１の送信部１６は、映像データをデコーダ３０Ａ〜３０Ｃへマルチキャストする。

第２の送信部１７は、映像バッファ１１ａ及びＦＥＣバッファ１２ａを用いて、デコーダ３０で映像ストリームを再現するのに必要なパケットを送信する処理部である。

例えば、デクリメント後の各映像番号の再送要求合計値の論理和がゼロである場合には、デコーダ３０Ａ〜３０ＣにＦＥＣデータさえ送信すればデコーダ３０側でエラーが検出された映像データを復元できる。よって、第２の送信部１７は、ＦＥＣバッファ１２ａからＦＥＣデータだけを取り出してデコーダ３０にマルチキャストする。

また、デクリメント後の各映像番号の再送要求合計値の論理和がゼロよりも大きい場合には、デコーダ３０Ａ〜３０ＣにＦＥＣデータだけを送信したとしてもデコーダ３０側でエラーが検出された映像データ全て復元できない。よって、第２の送信部１７は、ＦＥＣデータをデコーダ３０にマルチキャストするとともに符号化データをデコーダ３０にマルチキャストする。このとき、第２の送信部１７は、デクリメント後の再送要求合計値がゼロよりも大きい映像番号に対応する符号化データを映像バッファ１１ａから取り出して送信すればよい。

また、デクリメント前の各映像番号の再送要求合計値の論理和がゼロである場合には、デコーダ３０側でエラーが検出された映像データがない。よって、第２の送信部１７は、ＦＥＣデータ及び符号化データともに送信しない。

このように、映像ストリームをマルチキャストする場合にデータパケットのみを先行して配信し、映像ストリームの再現に必要なパケットを後続して再送させた場合でも、ＦＥＣデータや再送の符号化データがデコード３０の再成に間に合わない事態は防止できる。一例として、エンコーダ１０がデータパケットにＦＥＣパケットを挿入する間隔やデコーダ３０Ａ〜３０Ｃが映像データを受信してから再生するまでにバッファリングする時間などのパラメータをデコーダ３０側又はエンコーダ１０側で適切に設定すればよい。

なお、符号化部１１、生成部１２、取得部１３、受付部１４、判定部１５、第１の送信部１６及び第２の送信部１７には、各種の集積回路や電子回路を採用できる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。

また、ＦＥＣ情報記憶部１２ｂ、ＲＴＴ記憶部１３ａ、再送要求記憶部１４ａ及び受付状況記憶部１５ａには、半導体メモリ素子や記憶装置を採用できる。例えば、半導体メモリ素子としては、ＶＲＡＭ（Video Random Access Memory）、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などが挙げられる。また、記憶装置としては、ハードディスク、光ディスクなどの記憶装置が挙げられる。

［処理の流れ］
次に、本実施例に係るエンコーダ１０の処理の流れについて説明する。なお、ここでは、第１の送信部１６によって実行される（１）第１の送信処理について説明した後に、第２の送信部１７によって実行される（２）第２の送信処理について説明することとする。

（１）第１の送信処理
図１０は、実施例１に係る第１の送信処理の手順を示すフローチャートである。この第１の送信処理は、エンコーダ１０の電源がＯＮ状態である場合に繰り返し実行される処理であり、カメラ２０から映像データが入力される度に処理が起動する。

図１０に示すように、カメラ２０から映像データが入力されると（ステップＳ１０１肯定）、符号化部１１は、カメラ２０から入力された映像データを符号化する（ステップＳ１０２）。続いて、符号化部１１は、映像データを符号化した符号化データを映像バッファ１１ａに蓄積させる（ステップＳ１０３）。

このとき、映像バッファ１１ａに所定のフレーム数の符号化データが蓄積されると（ステップＳ１０４肯定）、生成部１２は、所定のフレーム数にわたって連続する映像データを映像バッファ１１ａから取り出してＦＥＣデータを生成する（ステップＳ１０５）。なお、映像バッファ１１ａに所定のフレーム数の符号化データが蓄積されていない場合（ステップＳ１０４否定）には、ＦＥＣデータの生成を実行せずに、ステップＳ１０８に移行する。

そして、生成部１２は、ステップＳ１０５で生成したＦＥＣデータのＦＥＣ番号、ＦＥＣデータの生成に使用された映像データの開始映像番号、終了映像番号とともに、ＦＥＣデータの生成時刻をＦＥＣ情報記憶部１２ｂに設定する（ステップＳ１０６）。

続いて、生成部１２は、ＦＥＣデータの生成時刻と、ＲＴＴ記憶部１３ａに記憶された最大の往復遅延時間とをもとに決定したＦＥＣデータの判定時刻をＦＥＣ情報記憶部１２ｂに設定する（ステップＳ１０７）。

そして、第１の送信部１６は、映像バッファ１１ａに蓄積された符号化データをデコーダ３０Ａ〜３０Ｃにマルチキャストし（ステップＳ１０８）、上記のステップＳ１０１に移行する。その後、エンコーダ１０は、カメラ２０から映像データが入力される度に、上記のステップＳ１０２〜ステップＳ１０８の処理を再帰的に繰り返し実行する。

（２）第２の送信処理
図１１は、実施例１に係る第２の送信処理の手順を示すフローチャートである。この第２の送信処理は、エンコーダ１０の電源がＯＮ状態である場合に繰り返し実行される処理であり、時刻がＦＥＣ情報記憶部１２ｂに記憶されたＦＥＣデータの判定時刻に至る度に処理が起動する。

図１１に示すように、時刻がＦＥＣデータの判定時刻になると（ステップＳ３０１肯定）、判定部１５は、再送要求記憶部１４ａを用いて、受付状況記憶部１５ａ内における各映像番号ごとの再送要求合計値を生成する（ステップＳ３０２）。

そして、判定部１５は、各映像番号の再送要求合計値の論理和がゼロよりも大きいか否かを判定する（ステップＳ３０３）。このとき、各映像番号の再送要求合計値の論理和がゼロである場合（ステップＳ３０３否定）には、デコーダ３０側でエラーが検出された映像データがない。よって、ＦＥＣデータ及び符号化データともに送信されずに、ステップＳ３０１に移行する。

一方、各映像番号の再送要求合計値の論理和がゼロよりも大きい場合（ステップＳ３０３肯定）には、判定部１５は、各映像番号の再送要求合計値を１つずつデクリメントする（ステップＳ３０４）。続いて、判定部１５は、デクリメント後の各映像番号の再送要求合計値の論理和がゼロであるか否かを判定する（ステップＳ３０５）。

ここで、デクリメント後の各映像番号の再送要求合計値の論理和がゼロである場合（ステップＳ３０５肯定）には、デコーダ３０Ａ〜３０ＣにＦＥＣデータさえ送信すればデコーダ３０側でエラーが検出された映像データを復元できる。よって、第２の送信部１７は、ＦＥＣバッファ１２ａからＦＥＣデータだけを取り出してデコーダ３０にマルチキャストし（ステップＳ３０６）、再送要求記憶部１４ａ及び受付状況記憶部１５ａを初期化した上で（ステップＳ３０７）ステップＳ３０１に移行する。

一方、デクリメント後の各映像番号の再送要求合計値の論理和がゼロよりも大きい場合（ステップＳ３０５否定）には、デコーダ３０Ａ〜３０ＣにＦＥＣデータだけを送信したとしてもデコーダ３０側でエラーが検出された映像データ全て復元できない。よって、第２の送信部１７は、ＦＥＣデータをデコーダ３０にマルチキャストするとともに符号化データをデコーダ３０にマルチキャストする（ステップＳ３０８）。その後、第２の送信部１７は、再送要求記憶部１４ａ及び受付状況記憶部１５ａを初期化した上で（ステップＳ３０７）ステップＳ３０１に移行する。

［実施例１の効果］
上述してきたように、本実施例に係るエンコーダ１０は、映像ストリームをマルチキャストする場合にデータパケットのみを先行して配信し、映像ストリームの再現に必要なパケットを再送する。このため、本実施例に係るエンコーダ１０では、映像ストリームの再現にエンコーダ１０から再送されるパケットが必要ない場合には、配信先のデコーダ３０Ａ〜３０Ｃにパケットは送信しない。よって、本実施例に係るエンコーダ１０によれば、映像データを効率よく再送することが可能である。

さらに、本実施例に係るエンコーダ１０は、配信先のデコーダ３０Ａ〜３０Ｃとの間の最大往復遅延時間を待ってから映像ストリームの再現に必要なパケットを再送する。このため、本実施例に係るエンコーダ１０では、デコーダ３０Ａ〜３０Ｃの再送要求が全て届いたと推定される時点で再送することが可能である。それゆえ、本実施例に係るエンコーダ１０によれば、デコーダ３０Ａ〜３０Ｃから再送要求が届ききらずにパケットを再送することにより、一部のデコーダ３０でパケットの再送漏れが発生する事態を防止できる。また、本実施例に係るエンコーダ１０によれば、デコーダ３０Ａ〜３０Ｃから再送要求を受け付けてからパケットを再送するまでの時間が過度に引き延ばされることにより、パケットの再送に遅延が生じる事態も防止できる。

また、本実施例に係るエンコーダ１０は、ＦＥＣパケットが復元対象とするデータパケットの再送要求が受け付けられなかった場合にはパケットを送信しない。図１２は、デコーダにおけるパケットの受信順序の一例を示す図である。図１２の例では、エンコーダ１０が映像番号１〜映像番号Ｎの順に映像データのデータパケットを送信する場合を想定する。図１２に示すように、デコーダ３０Ａ〜３０Ｃは、ＦＥＣ番号１のＦＥＣパケットが復元対象とする映像番号１〜映像番号４のデータパケットを全て正常に受信する。この場合には、エンコーダ１０の第２の送信部１７によってＦＥＣパケットもデータパケットも再送されない。よって、ＦＥＣパケットやデータパケットにより、ネットワーク３のリソース、エンコーダ１０及びデコーダ３０Ａ〜３０Ｃのリソースが無駄に消費されることを防止できる。

また、本実施例に係るエンコーダ１０は、再送要求を受け付けたデータパケットの数がＦＥＣパケットを用いて復元可能な数である場合にはそのＦＥＣパケットを送信する。図１３は、デコーダにおけるパケットの受信順序の一例を示す図である。図１３の例では、図１２の例と同様に、エンコーダ１０が映像番号１〜映像番号Ｎの順に映像データのデータパケットを送信する場合を想定する。なお、図１３の例では、デコーダ３０でエラーが検出されたパケットを斜線の塗りつぶしで表記し、第２の送信部１７によって送信されるＦＥＣパケットを黒の塗り潰しで表記する。図１３に示すように、デコーダ３０Ａでは、ＦＥＣ番号１のＦＥＣパケットが復元対象とする映像番号１〜映像番号４のデータパケットのうち映像番号３のデータパケットにエラーが検出される。また、デコーダ３０Ｂでは、映像番号２のデータパケットにエラーが検出される。また、デコーダ３０Ｃでは、映像番号１のデータパケットにエラーが検出される。この場合には、各デコーダ３０でＦＥＣ番号１のＦＥＣパケットが復元可能な数しかデータパケットのエラーが検出されない。このため、エンコーダ１０の第２の送信部１７によってＦＥＣ番号１のＦＥＣパケットだけが各デコーダ３０にマルチキャストされる。よって、ネットワーク３に送出するパケットを最小限に留めることができる。

また、本実施例に係るエンコーダ１０は、再送要求を受け付けたデータパケットの数がＦＥＣパケットを用いて復元不能な数である場合にはそのＦＥＣパケットを送信するとともにデータパケットを再送する。図１４は、デコーダにおけるパケットの受信順序の一例を示す図である。図１４の例では、図１３の例と同様に、エンコーダ１０が映像番号１〜映像番号Ｎの順に映像データのデータパケットを送信する場合を想定する。なお、図１４の例では、デコーダ３０でエラーが検出されたパケットを斜線の塗りつぶしで表記し、第２の送信部１７により送信されるＦＥＣパケットを黒の塗り潰しで表記し、第２の送信部１７により再送されるデータパケットを点による塗りつぶしで表記する。図１４に示すように、デコーダ３０Ａでは、ＦＥＣ番号１のＦＥＣパケットが復元対象とする映像番号１〜映像番号４のデータパケットのうち映像番号１及び映像番号３のデータパケットにエラーが検出される。また、デコーダ３０Ｂでは、映像番号２のデータパケットにエラーが検出される。また、デコーダ３０Ｃでは、映像番号１のデータパケットにエラーが検出される。この場合には、デコーダ３０ＡでＦＥＣ番号１のＦＥＣパケットが復元不能な数のエラーが検出される。このため、エンコーダ１０の第２の送信部１７によってＦＥＣ番号１のＦＥＣパケットとともに映像番号１のデータパケットが各デコーダ３０にマルチキャストされる。よって、デコーダ３０Ａでエラーが検出された映像番号１及び映像番号３のデータパケットを再現できる。

したがって、本実施例に係るエンコーダ１０によれば、上記の３つの状況に応じてパケットの再送を適切に実行できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［機能の分散及び統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、符号化部１１、生成部１２、取得部１３、受付部１４、判定部１５、第１の送信部１６又は第２の送信部１７をエンコーダ１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、符号化部１１、生成部１２、取得部１３、受付部１４、判定部１５、第１の送信部１６又は第２の送信部１７を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のエンコーダ１０の機能を実現するようにしてもよい。

［映像配信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記の実施例と同様の機能を有する映像配信プログラムを実行するコンピュータの一例について説明する。

図１５は、実施例２に係る映像配信プログラムを実行するコンピュータの一例について説明するための図である。図１５に示すように、実施例２におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１５に示すように、上記の実施例１で示した符号化部１１と、生成部１２と、取得部１３と、受付部１４と、判定部１５と、第１の送信部１６と、第２の送信部１７と同様の機能を発揮する映像配信プログラム１７０ａが予め記憶される。この映像配信プログラム１７０ａについては、図２に示した各々の符号化部１１、生成部１２、取得部１３、受付部１４、判定部１５、第１の送信部１６及び第２の送信部１７の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。

そして、ＣＰＵ１５０が、映像配信プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これにより、図１５に示すように、映像配信プログラム１７０ａは、映像配信プロセス１８０ａとして機能する。この映像配信プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、映像配信プロセス１８０ａは、例えば、図２に示した符号化部１１、生成部１２、取得部１３、受付部１４、判定部１５、第１の送信部１６及び第２の送信部１７にて実行される処理、例えば図１０に示す処理を含む。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の映像配信プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）マルチキャストアドレスが設定された映像ストリームを送信する第１の送信部と、
前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得する取得部と、
前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付ける受付部と、
前記受付部によって再送要求が受け付けられたデータパケットの送信時刻から前記取得部によって取得された往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する第２の送信部と
を有することを特徴とする映像配信装置。

（付記２）前記映像ストリームのうち所定のパケット数にわたって連続するデータパケットから前方誤り訂正用のパケットを生成する生成部をさらに有し、
前記第２の送信部は、前記前方誤り訂正用のパケットが復元対象とするデータパケットの再送要求が受け付けられなかった場合にはパケットを送信せず、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元可能な数である場合には当該前方誤り訂正用のパケットを送信し、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元不能な数である場合には当該前方誤り訂正用のパケットを送信するとともにデータパケットを再送することを特徴とする付記１に記載の映像配信装置。

（付記３）コンピュータが、
マルチキャストアドレスが設定された映像ストリームを送信し、
前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得し、
前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付け、
前記再送要求が受け付けられたデータパケットの送信時刻から前記往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する処理
を実行することを特徴とする映像配信方法。

（付記４）コンピュータが、
前記映像ストリームのうち所定のパケット数にわたって連続するデータパケットから前方誤り訂正用のパケットを生成する処理をさらに実行し、
前記前記端末で映像ストリームを再現するのに必要なパケットを送信する処理として、前記前方誤り訂正用のパケットが復元対象とするデータパケットの再送要求が受け付けられなかった場合にはパケットを送信せず、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元可能な数である場合には当該前方誤り訂正用のパケットを送信し、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元不能な数である場合には当該前方誤り訂正用のパケットを送信するとともにデータパケットを再送する処理を実行することを特徴とする付記３に記載の映像配信方法。

（付記５）コンピュータに、
マルチキャストアドレスが設定された映像ストリームを送信し、
前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得し、
前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付け、
前記再送要求が受け付けられたデータパケットの送信時刻から前記往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する処理
を実行させることを特徴とする映像配信プログラム。

１ 映像配信システム
３ ネットワーク
１０ エンコーダ
１１ａ 映像バッファ
１１ 符号化部
１２ａ ＦＥＣバッファ
１２ｂ ＦＥＣ情報記憶部
１２ 生成部
１３ａ ＲＴＴ記憶部
１３ 取得部
１４ａ 再送要求記憶部
１４ 受付部
１５ａ 受付状況記憶部
１５ 判定部
１６ 第１の送信部
１７ 第２の送信部
２０ カメラ
３０Ａ，３０Ｂ，３０Ｃ デコーダ
４０Ａ，４０Ｂ，４０Ｃ 表示装置

Claims (3)

1. マルチキャストアドレスが設定された映像ストリームを送信する第１の送信部と、
   前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得する取得部と、
   前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付ける受付部と、
   前記受付部によって再送要求が受け付けられたデータパケットの送信時刻から前記取得部によって取得された往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する第２の送信部と
   を有することを特徴とする映像配信装置。
2. 前記映像ストリームのうち所定のパケット数にわたって連続するデータパケットから前方誤り訂正用のパケットを生成する生成部をさらに有し、
   前記第２の送信部は、前記前方誤り訂正用のパケットが再現対象とするデータパケットの再送要求が受け付けられなかった場合にはパケットを送信せず、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元可能な数である場合には当該前方誤り訂正用のパケットを送信し、前記再送要求が受け付けられたデータパケットの数が前記前方誤り訂正用のパケットを用いて復元不能な数である場合には当該前方誤り訂正用のパケットを送信するとともにデータパケットを再送することを特徴とする請求項１に記載の映像配信装置。
3. コンピュータが、
   マルチキャストアドレスが設定された映像ストリームを送信し、
   前記マルチキャストアドレスに含まれる複数の受信端末と自装置との間における往復遅延時間を取得し、
   前記複数の端末から前記映像ストリームに含まれるデータパケットの再送要求を受け付け、
   前記再送要求が受け付けられたデータパケットの送信時刻から前記往復遅延時間のうち最大の往復遅延時間が少なくとも経過した後に、前記端末で映像ストリームを再現するのに必要なパケットを送信する処理
   を実行することを特徴とする映像配信方法。

Images