JP7253940B2 - 受信装置、サーバシステム及び受信プログラム - Google Patents

Description

本発明は、動画の配信システムに関する。

従来、テレビで放送中の番組を、インターネット経由でモバイル端末又はＰＣ向けに同時に配信するサービスが研究されている。例えば、サッカーの試合をライブで放送し、同じ番組をネット配信する場合に、放送とネット配信とでユーザの端末での画面表示に時間差があった場合に、試合の途中経過又は結果をいずれか一方のユーザが先に知り、他方のユーザがＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）又は隣家で発せられた声で知ってしまう、いわゆるネタばれの問題がある。
この問題に対処するため、放送とネット配信とで同時に画面表示する技術の実現が望まれている。非特許文献１では、インターネットの回線状況に応じて視聴者毎の通信経由のデータの到着時刻を制御することで、放送とネット配信とで画面への提示時間を同期させる技術が提案されている。

「放送通信連携サービスのための同時受信型プッシュ配信制御方式の提案」、インターネット＜ｈｔｔｐｓ：／／ｗｗｗ．ｎｈｋ．ｏｒ．ｊｐ／ｓｔｒｌ／ｐｕｂｌｉｃａ／ｒｄ／ｒｄ１５７／ＰＤＦ／Ｐ１９－２５．ｐｄｆ＞、ＮＨＫ技研Ｒ＆Ｄ ２０１６年５月号 ｐｐ．１９－２５

ところで、インターネットを利用するネット配信では、輻輳が生じた場合に、パケットロスによる動画再生品質が低下する問題がある。
パケットロスが生じた場合には、一般にＡＲＱ（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）と呼ばれる再送要求方式により、誤り検出と自動再送要求を行うことで、動画再生品質の低下が抑えられる。ＡＲＱには、トランスポート層のプロトコルとしてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いる手法と、ＴＣＰを用いずにＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を用いてアプリケーション層で誤り検出と自動再送要求を行う手法とがある。

品質保証型のトランスポート層の通信プロトコルであるＴＣＰは、ＴＣＰセッションの確立のための３ウェイ・ハンドシェイク、及び送信パケットそれぞれに対するＡＣＫ応答が必要なためオーバヘッドが大きくなり、その結果、遅延量が増加するという原理的な傾向がある。
このため、低遅延が求められる通信ではＵＤＰが利用されることが多いが、ＵＤＰにはプロトコル自体に品質を保証する仕組みがないため、ＱＵＩＣ（Ｑｕｉｃｋ ＵＤＰ Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｏｎｓ）又はＳＲＴ（Ｓｅｃｕｒｅ Ｒｅｌｉａｂｌｅ Ｔｒａｎｓｐｏｒｔ）のようにアプリケーション層に独自実装することで品質を保証する技術が利用される。しかし、パケットロス又はエラーパケットの検出時に配信サーバに再送要求をしなくてはならないのはＴＣＰと同様であるため、再送要求に関する遅延は、端末と配信サーバとの間のネットワークにおけるＲＴＴ（Ｒｏｕｎｄ－Ｔｒｉｐ Ｔｉｍｅ）、帯域、及び配信サーバのプロセス時間に依存することとなる。
また、ＲＵＤＰ（Ｒｅｌｉａｂｌｅ ＵＤＰ）と呼ばれる品質保証型のトランスポート層のプロトコルにも、同じ問題が依然として残っている。

本発明は、再送要求の発生による配信の遅延を低減できる受信装置、サーバシステム及び受信プログラムを提供することを目的とする。

本発明に係る受信装置は、動画を構成するパケットを順次、受信する際に、前記パケットのロス又はエラーを検出するパケット監視部と、前記パケットのロス又はエラーが検出された場合に、当該パケットを、標準スライスを介した配信サーバに代えて、前記標準スライスより高速な高速スライスを介して、前記配信サーバと共通の前記パケットが格納されている再送サーバへ要求する再送要求部と、を備える。

前記受信装置は、第１の動作モードにおいて、前記高速スライスを介して前記再送サーバへ前記パケットを要求した際に、当該パケットのロス又はエラーが検出された場合、検出された頻度に応じて、前記高速スライスの利用を制限する第２の動作モードに切り替えるモード切替部を備えてもよい。

前記モード切替部は、前記第２の動作モードに切り替えた後、所定時間の間、前記高速スライスを介して前記再送サーバに対してテストパケットを複数回要求し、当該テストパケットのロス又はエラーが検出された頻度が閾値以下の場合、前記第１の動作モードに切り替えてもよい。

前記第１の動作モードは、ＵＤＰによる通信であり、前記第２の動作モードは、ＴＣＰによる通信であってもよい。

本発明に係るサーバシステムは、動画を構成するパケットを、標準スライスを介して受信装置へ送信する配信サーバと、前記配信サーバと共通の前記パケットを蓄積し、前記パケットのロス又はエラーを検出した前記受信装置からの再送要求に応じて、前記標準スライスよりも高速な高速スライスを介して前記受信装置へ前記パケットを送信する再送サーバと、前記動画をエンコードして生成した前記パケットにシーケンシャル番号を付加し、配信サーバ及び再送サーバの双方へ転送するライブエンコーダと、を備える。

本発明に係る受信プログラムは、前記受信装置としてコンピュータを機能させるためのものである。

本発明によれば、再送要求の発生による配信の遅延を低減できる。

実施形態に係る動画配信用のサーバシステム及び受信装置を含むシステムの全体構成を示す図である。 実施形態に係る動画データの、配信サーバ及び再送サーバへのインジェスト、及び受信装置への配信の処理を示す図である。 実施形態に係る受信装置の機能構成を示す図である。 実施形態に係る動作モード毎のプロトコル及びパケットの要求先を示す図である。 実施形態に係る受信装置における、第１の動作モードでのパケットの要求及び受信の処理を示すフローチャートである。 実施形態に係る第２の動作モードから第１の動作モードへの切り替えの処理を示すフローチャートである。

以下、本発明の実施形態の一例について説明する。
本実施形態では、例えば第５世代移動通信システム（５Ｇ）及びエッジコンピューティングなどによる広帯域かつ低遅延なネットワークが利用される。
広帯域かつ低遅延なネットワークを常に利用することにより、再送の処理時間を短くすることは可能であるが、このようなネットワークの利用は高価になることが予想されるため、常時このネットワークを利用することは費用対効果の面で多くのビジネスモデルにおいて困難であることが見込まれる。

また、ＡＲＱを用いて、再送要求が発生しても動画再生を継続させるためには、ユーザの端末側で再送による遅延を吸収するだけのバッファリング処理が必要となる。このバッファリングの量を大きく用意するほど、パケットが到着するまでの待ち時間の変動を吸収できるため、再生品質の低下を抑制する効果が高まるが、一方で画面提示時刻が遅れるというトレードオフの問題がある。
本実施形態では、再送要求が発生した場合の遅延を抑えることでバッファリングの量を減らすことができ、結果として画面提示時刻を早めることが可能となる。

図１は、本実施形態に係る動画配信用のサーバシステム１００及び受信装置１を含むシステムの全体構成を示す図である。
サーバシステム１００は、スイッチ２と、配信サーバ３と、再送サーバ４と、ライブエンコーダ５とを備える。

受信装置１は、インターネット経由で動画データを受信し再生する装置である。受信装置１は、スマートフォン、タブレット端末、パーソナルコンピュータ、テレビなどの情報処理装置であり、例えば、標準的なＨＴＭＬ５プラットフォームを搭載したＷｅｂブラウザを備え、配信サーバ３又は他のサーバからスクリプト類をダウンロードすることで動画プレーヤとして機能する。
受信装置１は、モバイルキャリアが設置する基地局を介してモバイルキャリア網（ネットワーク）に接続し、動画を構成するパケットを要求する。

スイッチ２は、インターネットと接続する通信経路である標準スライスと、インターネットと接続せずに再送サーバ４と接続する通信経路である高速スライスとを切り替える装置であり、モバイルキャリアにより設置される。
スイッチ２は、受信装置１がパケット要求時に指定した配信サーバ３又は再送サーバ４のいずれかのＩＰアドレスに基づいて、標準スライス、又は標準スライスよりも高速な高速スライスに通信経路を振り分ける。

配信サーバ３は、動画データを蓄積し、受信装置１から配信要求があった際にパケットを、標準スライスを介して送信するサーバである。

再送サーバ４は、配信サーバ３よりも受信装置１とネットワーク的に近い位置に設置され、広帯域かつ低遅延な高速スライスを介して受信装置１と接続される。本実施形態では、モバイルキャリア網に再送サーバ４が設置される構成を例示しているが、これには限られず、例えばモバイル基地局内のネットワークに設置されてもよい。
再送サーバ４は、配信サーバ３と同じパケット構成の動画データを蓄積し、受信装置１から再送要求があった際に該当のパケットを、高速スライスを介して送信する。

ライブエンコーダ５は、動画をエンコードした後、ＵＤＰで配信サーバ３及び再送サーバ４に動画データをインジェストする装置である。ライブエンコーダ５と、配信サーバ３及び再送サーバ４とは、専用線で接続される。

図２は、本実施形態に係る動画データの、配信サーバ３及び再送サーバ４へのインジェスト、及び受信装置１への配信の処理を示す図である。

ライブエンコーダ５は、動画をエンコードして生成したＵＤＰパケットにシーケンシャル番号を付加し、同一のパケットを配信サーバ３及び再送サーバ４の双方に逐次送信（インジェスト）する。このとき、パケットは、配信サーバ３よりも再送サーバ４に先に到着するものとする。
これにより、配信サーバ３及び再送サーバ４は、同一のシーケンシャル番号に対して同じペイロード（動画データ）を持ったパケットを共有する。

配信サーバ３は、ライブエンコーダ５からパケットがインジェストされると、すぐに受信装置１へ転送する。
再送サーバ４は、再送要求に備えてパケットを一定数キャッシュする。例えば、配信サーバ３と受信装置１との間の遅延量をａ、受信装置１のバッファ量ｂとした場合、再送サーバ４のキャッシュ量Ｃは、Ｃ＞ａ＋ｂと設定される。
これにより、再送要求の際に受信装置１がシーケンシャル番号を指定することによって、再送サーバ４は、該当するシーケンシャル番号を持ったパケットを再送できる。

図３は、本実施形態に係る受信装置１の機能構成を示す図である。
受信装置１は、所定の記憶部に格納されたソフトウェア（受信プログラム）をＣＰＵなどの制御部が実行することにより、次の各機能部を実現する。
受信装置１は、データ受信部１１と、バッファ管理部１２と、映像再生部１３と、パケット監視部１４と、パケット要求部１５と、再送要求部１６と、モード切替部１７とを備える。

データ受信部１１は、標準スライス又は高速スライスを介して、配信サーバ３又は再送サーバ４から送信されたデータを受信する。

バッファ管理部１２は、データ受信部１１で受信された動画のパケットをバッファに格納し、バッファが保持するパケットを管理する。

映像再生部１３は、バッファ管理部１２を介して、バッファに保持されている受信済みのパケットを順にロードし、動画をデコードした上で再生する。

パケット監視部１４は、データ受信部１１により動画を構成するパケットを順次、受信する際に、パケットのロス又はエラーを検出する。具体的には、パケット監視部１４は、例えば、パケットを要求してから所定時間が経過しても該当のパケットを受信できない場合をパケットロスと判定し、パリティチェックなどの誤り検出によりパケットエラーを検出する。

パケット要求部１５は、動画を構成するパケットを、パケットに予め付与されているシーケンシャル番号の順に、標準スライスを介して配信サーバ３へ要求する。

再送要求部１６は、パケット監視部１４によりパケットのロス又はエラーが検出された場合に、このパケットを、標準スライスを介した配信サーバ３に代えて、標準スライスより高速な高速スライスを介して、配信サーバと共通のパケットが格納されている再送サーバ４へ要求する。

モード切替部１７は、配信サーバ３又は再送サーバ４を選択してパケットを受信する第１の動作モードと、高速スライスを介した再送サーバ４の利用を制限する第２の動作モードとを切り替える。
第１の動作モードは、ＵＤＰによる通信であってよく、第２の動作モードは、ＴＣＰにより配信サーバ３からパケットを受信する通信モードであってよい。

具体的には、モード切替部１７は、第１の動作モードにおいて、再送要求部１６が高速スライスを介して再送サーバ４へパケットを要求した際に、このパケットのロス又はエラーが検出された場合、検出された頻度に応じて第２の動作モードに切り替える。具体的には、モード切替部１７は、パケットのロス又はエラーの累積回数をカウントし、累積回数が閾値に達すると、第２の動作モードに切り替えてもよい。この場合、モード切替部１７は、累積回数のカウントアップ後に所定時間が経過すると、累積回数をカウントダウンして調整してもよい。

また、モード切替部１７は、第２の動作モードに切り替えた後、所定時間の間、高速スライスを介して再送サーバ４に対してテストパケットを複数回要求し、テストパケットのロス又はエラーが検出された頻度が閾値以下の場合、第１の動作モードに切り替える。

図４は、本実施形態に係る動作モード毎のプロトコル及びパケットの要求先を示す図である。
第１の動作モードにおいて、受信装置１は、トランスポート層プロトコルとしてＵＤＰを使用し、通常時は、配信サーバ３から標準スライスを介してパケットを受信する。また、受信装置１は、パケットのロス又はエラーが検出された場合には、再送サーバ４から高速スライスを介してパケットを受信する。

パケットのロス又はエラーの検出回数（ロス回数）が閾値に達した場合の第２の動作モードでは、受信装置１は、トランスポート層プロトコルとしてＴＣＰを使用し、通常時及び再送時の両方において、配信サーバ３から標準スライスを介してパケットを受信する。

図５は、本実施形態に係る受信装置１における、第１の動作モードでのパケットの要求及び受信の処理を示すフローチャートである。
ここで、動画を構成する各パケットにはシーケンシャル番号が振られており、受信装置１は、シーケンシャル番号の順に本処理フローによりＮ番目のパケットを要求し、受信待機状態でパケットを監視する。なお、初期状態では、Ｎ＝０とする。

ステップＳ１において、パケット監視部１４は、シーケンシャル番号がＮのパケットの受信を待機し、タイマが満了（タイムアウト）するまでにパケットを受信したか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ２に移り、判定がＮＯの場合、パケットロスと判断し、処理はステップＳ１２に移る。

ステップＳ２において、パケット監視部１４は、受信したパケットからシーケンシャル番号ｋを抽出する。

ステップＳ３において、パケット監視部１４は、シーケンシャル番号ｋが受信待機中のものより過去、すなわちｋ＜Ｎか否かを判定する。この判定がＹＥＳの場合、パケット監視部１４は、既に受信済みの複製されたパケットを受信したと判断し、このパケットを破棄すると、処理はステップＳ１に戻る。一方、判定がＮＯの場合、待機中のシーケンシャル番号Ｎ以降のパケットを受信したので、処理はステップＳ４に移る。

ステップＳ４において、パケット監視部１４は、受信したパケットの次のシーケンシャル番号ｋ＋１用のタイマをセットする。

ステップＳ５において、パケット監視部１４は、受信したパケットのパリティチェックを行い、パケットが正常か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ６に移り、判定がＮＯの場合、パケットエラーと判断され、処理はステップＳ１２に移る。

ステップＳ６において、パケット監視部１４は、一時的な配列ｔｍｐ［］へ受信したパケットを追加して一時保存する。このとき、配列ｔｍｐ［］の要素は、シーケンシャル番号で昇順にソートされる。

ステップＳ７において、パケット監視部１４は、受信したパケットのシーケンシャル番号ｋと、受信待機していたＮとが等しいか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ８に移り、判定がＮＯ、すなわちｋ＞Ｎの場合、処理はステップＳ１に戻り、パケット監視部１４は、引き続き、シーケンシャル番号Ｎのパケットの受信を待機する。

ステップＳ８～Ｓ１１のループ処理において、バッファ管理部１２は、配列ｔｍｐ［］に一時保存された連続したパケットをバッファに追加する。
具体的には、ステップＳ９において、配列ｔｍｐ［ｉ］に保存されているシーケンシャル番号Ｎのパケットをバッファに追加し、ステップＳ１０において、シーケンシャル番号Ｎをインクリメントする。ステップＳ１１において、配列ｔｍｐ［ｉ＋１］にシーケンシャル番号Ｎのパケットが保存されていないことが検出されると、ループは終了し、受信済みの最大のシーケンシャル番号の次の番号をＮとして、処理は終了する。

ステップＳ１２において、再送要求部１６は、シーケンス番号Ｎのパケットを、高速スライスを介して再送サーバ４に要求する。

ステップＳ１３において、パケット監視部１４は、シーケンシャル番号がＮのパケットの受信を待機し、タイマが満了（タイムアウト）するまでにパケットを受信したか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１４に移り、判定がＮＯの場合、パケットロスと判断し、処理はステップＳ１５に移る。

ステップＳ１４において、パケット監視部１４は、受信したパケットのパリティチェックを行い、パケットが正常か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ６に移り、判定がＮＯの場合、パケットエラーと判断され、処理はステップＳ１５に移る。

ステップＳ１５において、モード切替部１７は、高速スライスに要求したパケットのロス回数Ｃをカウントアップする。
なお、モード切替部１７は、ロス回数Ｃをカウントアップすると、所定時間（例えば、１０秒）のタイマを設定し、タイマが満了（タイムアウト）すると、ロス回数をカウントダウンしてもよい。

ステップＳ１６において、モード切替部１７は、ロス回数Ｃが閾値ｔｈ未満か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ８に移り、パケットが欠けた状態のまま動画品質の不良を許容する。一方、判定がＮＯの場合、処理はステップＳ１７に移る。

ステップＳ１７において、モード切替部１７は、受信装置１を高速スライスから切り離し、常に標準スライスを介して配信サーバ３からパケットを受信する第２の動作モードに切り替える。
すなわち、ロス回数が多い（閾値ｔｈに達した）場合、基地局と受信装置１との間の無線回線の通信状況が不良である可能性があるため、モード切替部１７は、リソースの節約の観点で高速スライスからの再送手段を止め、インターネットを介して接続された配信サーバ３とのＴＣＰを利用した通信にプロトコルを変更する。

しかしながら、無線回線の通信状況が回復する場合があるため、モード切替部１７は、第２の動作モードに切り替えた後、再送サーバ４にテストパケットの転送要求を行い、無線回線が回復したと判断できれば、第１の動作モードに切り替える。

図６は、本実施形態に係る第２の動作モードから第１の動作モードへの切り替えの処理を示すフローチャートである。

ステップＳ２１において、モード切替部１７は、第２の動作モードに切り替わってからの時間を計測するためのタイマを開始する。

ステップＳ２２において、モード切替部１７は、タイマにより経過時間ｔを計測する。
ステップＳ２３において、モード切替部１７は、経過時間ｔがＴ１（例えば、６０秒）を超えたか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ２４に移り、判定がＮＯの場合、処理はステップＳ２２に戻る。

ステップＳ２４において、モード切替部１７は、再送サーバ４にテストパケットの送信を要求する。なお、テストパケットは、再送サーバ４に予めキャッシュされたテスト用データであってよい。
ステップＳ２５において、モード切替部１７は、テストパケットの受信を監視し、ロス又はエラーの回数をカウントする。

ステップＳ２６において、モード切替部１７は、タイマにより経過時間ｔを計測する。
ステップＳ２７において、モード切替部１７は、経過時間ｔがＴ２（例えば、１２０秒）を超えたか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ２８に移る。一方、判定がＮＯの場合、処理はステップＳ２４に戻り、テストパケットの要求を繰り返す。なお、テストパケットの要求は所定周期（例えば、１０秒間隔）で行われてよい。

ステップＳ２８において、モード切替部１７は、Ｔ１からＴ２までの間にカウントしたロス回数が閾値以下であるか否か（例えば、０回か１回でもあったか）を判定する。この判定がＹＥＳの（例えば、ロスが１度もなかった）場合、処理はステップＳ２９に移り、判定がＮＯの場合、処理はステップＳ２１に戻る。

ステップＳ２９において、モード切替部１７は、受信装置１とモバイル基地局との間の通信品質が回復したと判断し、第１の動作モードに切り替える。

本実施形態によれば、受信装置１は、動画を構成するパケットを順次、受信する際に、パケットのロス又はエラーを検出すると、該当のパケットを、標準スライスを介した配信サーバ３に代えて、標準スライスより高速な高速スライスを介して、配信サーバと共通のパケットが格納されている再送サーバ４へ要求する。

これにより、受信装置１は、バッファリングによる再生待ち時間を減らすために、バッファリング時間を小さく（例えば１００ｍｓｅｃ程度に）した場合に、ＡＲＱにより再送するパケットのみを高速スライスから受信することで、再送要求の発生による配信の遅延を低減し動画再生の待ち時間を減らせる。したがって、受信装置１は、テレビ放送とインターネット配信とで画面提示の時間差を低減すると同時に、高速スライスの利用に応じたコストの増加を抑えつつ、インターネット配信される動画の品質低下を抑制できる。

また、受信装置１は、第１の動作モードにおいて、高速スライスを介して再送サーバ４へパケットを要求した際に、パケットのロス又はエラーが検出された場合、検出された累積回数をカウントし、累積回数が閾値に達すると、高速スライスの利用を制限する第２の動作モードに切り替える。
したがって、受信装置１は、通信品質などの原因によりパケットのロス又はエラーが頻発した場合、再送処理を依頼し続けると、高速スライスの処理負荷が増大してしまうが、高速スライスから切り離すことで高速スライスのパフォーマンスを維持できる。

さらに、受信装置１は、第２の動作モードに移行した後、高速スライスからテストパケットの受信を試行し、ロス又はエラーの頻度が所定以下になると、第１の動作モードに復帰する。
したがって、受信装置１は、通信状況に応じて、適切に動作モードを切り替え、動画再生の品質低下を抑制できる。

受信装置１は、第１の動作モードにおいてはＵＤＰにより通信し、第２の動作モードにおいてはＴＣＰにより通信する。
これにより、受信装置１は、通常はＵＤＰによりパケット受信時の遅延を低減し、通信状況の悪化に応じて、より信頼性の高いＴＣＰにより、動画再生の品質を安定させることができる。

サーバシステム１００は、標準スライスを介して受信装置１へパケットを送信する配信サーバ３に加えて、配信サーバ３と共通のパケットを蓄積し、パケットのロス又はエラーを検出した受信装置１からの再送要求に応じて、高速スライスを介して受信装置１へパケットを送信する再送サーバ４を用いて動画配信を行う。また、動画をエンコードして生成したパケットには、シーケンシャル番号が付加され、ライブエンコーダ５から配信サーバ３及び再送サーバ４の双方へ転送される。
したがって、サーバシステム１００は、標準スライスと高速スライスとの双方に、シーケンシャル番号で対応付けられたペイロードが同じパケットを共通してインジェストできる。この結果、標準スライスを用いた通常配信に不具合が生じた際に、高速スライスにキャッシュされている同一のデータを受信装置１に高速転送できる。

本実施形態では、主に受信装置１及びサーバシステム１００の構成と動作について説明したが、本発明はこれに限られず、各構成要素を備え、動画を配信するための方法、又はプログラムとして構成されてもよい。

さらに、受信装置１及びサーバシステム１００の機能を実現するためのプログラムをコンピュータで読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。

ここでいう「コンピュータシステム」とは、ＯＳや周辺機器などのハードウェアを含むものとする。また、「コンピュータで読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭなどの可搬媒体、コンピュータシステムに内蔵されるハードディスクなどの記憶装置のことをいう。

さらに、「コンピュータで読み取り可能な記録媒体」とは、インターネットなどのネットワークや電話回線などの通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでもよい。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

１ 受信装置
２ スイッチ
３ 配信サーバ
４ 再送サーバ
５ ライブエンコーダ
１１ データ受信部
１２ バッファ管理部
１３ 映像再生部
１４ パケット監視部
１５ パケット要求部
１６ 再送要求部
１７ モード切替部
１００ サーバシステム

Claims (6)

1. 動画を構成するパケットを順次、受信する際に、前記パケットのロス又はエラーを検出するパケット監視部と、
   前記パケットのロス又はエラーが検出された場合に、当該パケットを、標準スライスを介した配信サーバに代えて、前記標準スライスより高速な高速スライスを介して、前記配信サーバと共通の前記パケットが格納されている再送サーバへ要求する再送要求部と、を備える受信装置。
2. 第１の動作モードにおいて、前記高速スライスを介して前記再送サーバへ前記パケットを要求した際に、当該パケットのロス又はエラーが検出された場合、検出された頻度に応じて、前記高速スライスの利用を制限する第２の動作モードに切り替えるモード切替部を備える請求項１に記載の受信装置。
3. 前記モード切替部は、前記第２の動作モードに切り替えた後、所定時間の間、前記高速スライスを介して前記再送サーバに対してテストパケットを複数回要求し、当該テストパケットのロス又はエラーが検出された頻度が閾値以下の場合、前記第１の動作モードに切り替える請求項２に記載の受信装置。
4. 前記第１の動作モードは、ＵＤＰによる通信であり、前記第２の動作モードは、ＴＣＰによる通信である請求項２又は請求項３に記載の受信装置。
5. 動画を構成するパケットを、標準スライスを介して受信装置へ送信する配信サーバと、
   前記配信サーバと共通の前記パケットを蓄積し、前記パケットのロス又はエラーを検出した前記受信装置からの再送要求に応じて、前記標準スライスよりも高速な高速スライスを介して前記受信装置へ前記パケットを送信する再送サーバと、
   前記動画をエンコードして生成した前記パケットにシーケンシャル番号を付加し、配信サーバ及び再送サーバの双方へ転送するライブエンコーダと、を備えるサーバシステム。
6. 請求項１から請求項４のいずれかに記載の受信装置としてコンピュータを機能させるための受信プログラム。

Images