JP2013017031A - 映像配信装置、再生装置及び映像通信システム - Google Patents

Abstract

【課題】情報通信サーバが配信するコンテンツを受信して再生する際のパケットロストを低減した映像通信システムを提供すること。
【解決手段】映像データパケットを生成するパケット化処理部１１１と、所定数の映像データパケットのまとまり毎に、ＦＥＣパケットを生成する誤り訂正処理部１１５と、映像データパケット及びＦＥＣパケットを送信するヘッダ処理部１１２とを含み、誤り訂正処理部１１５は、複数の異なる方式に対応するＦＥＣパケットを生成可能であり、ヘッダ処理部１１２は、映像データパケットのまとまり毎に、複数の異なるＦＥＣ復元方式すべてについてＦＥＣパケットが生成される度に、映像データパケット及び生成されたＦＥＣパケットの送信を開始し、生成されたＦＥＣパケットのうち再生装置によって指定されたＦＥＣ復元方式に係るＦＥＣパケットのみを送信することを特徴とする
【選択図】図２

Description

本発明は、映像配信装置、再生装置及び映像通信システムに関し、特に、受信側におけるネットワーク環境の違いに対応した映像配信に関する。

映像をリアルタイム生成する情報通信サーバとそれを受信し表示し、使用者からの入力を情報通信サーバへフィードバックする機能をもつ端末から構成される映像通信システムにおいて、通信に使用するプロトコルとしては、ＩＰ(Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)上に構成される一対一でコネクションを確立するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を基にしたＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等の通信プロトコルもしくは、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を利用することが考えられる。

ここで、ＲＴＰ通信は、相手に送信データが届かなくても再送しないので、ネットワーク上で転送データの一部が損失するパケットロストが発生した場合、映像や音声に乱れを生じることになり、そのための対処が必要になる。リアルタイムの応答が求められる映像通信の場合、ロストパケットをリアルタイムで復元しなくてはならないため、データパケットをデータ復元のための冗長パケットと一緒に送信することで、受信機がリアルタイムでエラー訂正できるＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）方法を用いてパケットを復元するのが一般的である。

パケットロストは、ネットワーク上に流れるデータ量が多くなり、ネットワーク負荷が、ネットワーク通信路の帯域の許容範囲を超える、所謂帯域不足になることが原因で起きることが多い。この問題を解決するため、ネットワークに繋がる各エンドホストが、それぞれ対応するＦＥＣプロキシ及び品質測定手段を有して誤り訂正の修復状態を測定しつつ、双方向リアルタイム通信を行うエンドホスト間のセッション単位の品質状態を判定し、ネットワークのエリア単位の輻輳状態を把握し、パケットロストの原因であるネットワークの過収容による輻輳状態を解消し、ネットワーク全体でパケットロストを低減する技術が提案されている（例えば、特許文献１参照）。

また、冗長パケットの割合を増やすことにより、ＦＥＣによるロストパケットの復元能力を高めることができるが、その分送信データ量が増えてネットワーク負荷が高くなり、ロストパケットの割合が増えてしまうことがある。そのようなことを回避するため、冗長性能を変化させた複数のＦＥＣ復元方法によりパケットを受信し、最適なＦＥＣ復元方法を適用する方法が開示されている（例えば、特許文献２参照）。

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

上述したように、ＦＥＣでは、誤り訂正の修復度は、データと共に送出する復元用の冗長パケット（以下ＦＥＣパケットと称する）の量により決まる。すなわちＦＥＣパケットを多く送れば送るほどロストパケットの復元率は大きくなるが、その分、送信データ量が増え、ネットワークに負荷がかかり帯域不足を起こしやすくなる問題がある。

そして、非業務用ネットワーク機器の場合、特許文献１のように受信機側から誤り訂正率を配信サーバに知らせることで、サーバにより経路を調整して輻輳状態を調整してもらえるのは、ローカルネットワークの入り口、即ちルータまでである。ローカルネットワーク内では一般的に経路調整などは出来ず、また外部のネットワークより許容帯域が小さいことが多いため、最終的にローカルの操作端末までＲＴＰデータが届いた際には、パケットロストを起こしていることになる。そのため、操作端末においては自身のデータ受信能力や、ローカルネットワークの許容帯域に応じて、ＦＥＣを使用したストリーミング品質保持の調整を行う方法を開発する必要がある。

特許文献２に開示された技術は、ネットワークによるテレビ放送のような形態が想定されたものであり、サーバから配信された映像データを複数のクライアントが受信することが前提となっている。そのため、予めローカルネットワークの入口であるルータに複数のＦＥＣ方式、即ち冗長性の異なるＦＥＣ方式によるＦＥＣパケットが届いており、ローカルネットワーク内の各端末は、ルータから取得するＦＥＣパケットを選択することにより、ＦＥＣ方式を変更する。

このような形態を、クライアントとサーバとが１対１でデータをやり取りする動画配信の形態に適用することも可能であるが、１のクライアントに映像を配信するために、複数のＦＥＣ方式によるＦＥＣパケットを配信することは非効率である。そのため、ローカルエリアネットワーク内に接続されたクライアントにおいて、最適なＦＥＣ方式を選択して受信する方法として、クライアントとサーバとが１対１でデータをやり取りする動画配信の形態に適した方法が求められる。

本発明の目的は前記した課題に鑑み、情報通信サーバが配信するコンテンツを受信して再生する際のパケットロストを低減した映像通信システムを提供することにある。

上記の目的を達成するために、本発明の一態様は、映像を再生する再生装置からのネットワークを介した要求に応じて映像情報を配信する映像配信装置であって、前記要求に係る映像情報に基づき、前記映像情報をネットワークを介して送信するための映像データパケットを生成して記憶媒体に記憶させる映像データパケット生成部と、前記生成された映像データパケットに基づき、予め定められた所定数の前記映像データパケットのまとまり毎に、パケット伝送におけるエラーを訂正するためのエラー訂正パケットを生成して記憶媒体に記憶させるエラー訂正パケット生成部と、前記生成された映像データパケット及びエラー訂正パケットをネットワークを介して前記再生装置に送信するパケット送信部とを含み、前記エラー訂正パケット生成部は、複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であり、前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記複数の異なるエラー訂正方式すべてについて前記エラー訂正パケットが生成される度に、前記エラー訂正パケットが生成された前記映像データパケット及び前記生成されたエラー訂正パケットの送信を開始することを特徴とする。

また、本発明の他の態様は、ネットワークを介して映像情報を受信して再生する再生装置であって、再生するべき映像情報に基づいて生成された複数の映像データパケット及びパケット伝送におけるエラーによって欠損した前記映像データパケットを復元するためのエラー訂正パケットを受信するパケット受信部と、前記受信されたエラー訂正パケットに基づき、パケット伝送におけるエラーによって欠損した前記映像データパケットを前記選択されたエラー訂正方式によって復元するパケット復元部と、前記受信された複数の映像データパケットに基づき、パケット伝送におけるエラーの発生割合であるエラー率を計算するエラー率計算部と、前記計算されたエラー率が予め定められた所定の閾値を超えている場合、前記エラー訂正方式の変更を前記映像配信装置に通知する方式変更通知部とを含むことを特徴とする。

また、本発明の更に他の態様は、映像通信システムであって、上述した映像配信装置と、上述した再生装置とを含むことを特徴とする。

本発明により、複数のユーザがホームネットワーク上の機器を利用する場合に、簡単にレジューム再生できる機能を提供することが可能となる。

本発明の実施形態に係る映像通信システムの運用形態を示す図である。 本発明の実施形態に係る情報通信サーバの機能構成を示す図である。 本発明の実施形態に係る操作端末の機能構成を示す図である。 本発明の実施形態に係るＦＥＣ復元方式を示す図である。 本発明の実施形態に係るＦＥＣ復元方式を示す図である。 本発明の実施形態に係るＦＥＣ復元方式を示す図である。 本発明の実施形態に係る映像通信システムの動作を示すシーケンス図である。 本発明の実施形態に係る情報通信サーバ２の動作を示すフローチャートである。 本発明の実施形態及び比較例に係るパケット送信態様を示す図である。 本発明の実施形態に係る操作端末の動作を示すフローチャートである。

以下、図面を参照して本発明の実施形態に係る映像通信システムについて説明する。図１は本実施形態に係るの映像通信システムの構成を示すブロック図である。図１に示すように、本実施形態に係る映像通信システムにおいては、情報通信サーバ２とサーバから配信された映像を受信、再生する再生装置としての機能を備える操作端末３が、ルータ４１、４３、４４やスイッチ４２などのネットワーク中継機器を経由して、映像データパケットやＦＥＣパケットを送受信している。

ネットワーク１は、様々なネットワーク物理層（例えば光、有線、または無線ネットワークを含む）を使用して実現されるインターネットプロトコル通信ネットワークであり、ルータやスイッチ、ハブなど、データパケットを送信元から送信先へ正確に送り届けるための通信制御機器４１〜４４も含む。

情報通信サーバ２は、映像データをＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）プロトコルで配信することにより、映像送信サービスを行うためのサーバシステムである。ＣＰＵブレード６で生成された映像コンテンツもしくは、ストレージ７に蓄えられた映像コンテンツは、送信装置５で必要に応じて符号化されてデータ量の圧縮処理を施され、所定のデータパケットとされてＦＥＣパケットを伴って、ネットワーク１へ送信される。

操作端末３は映像データを受信して、使用者のために映像を再生する映像受信・再生装置である。ユーザは操作端末３の画面に表示されたユーザインタフェースを参照しつつ、タッチパネルインタフェースで各種の機能についての指示を入力する。図１に示すように、操作端末３はローカルネットワーク４に接続され、ローカルネットワーク４はルータ４４を経由して、外部のネットワーク１と接続されている。なお、操作端末３は必ずしも表示装置やスピーカを備えている必要は無く、外部の表示装置やスピーカに接続される受信装置（例えばセットトップボックス（ＳＴＢ））であってもよい。

次に、本実施形態に係る情報通信サーバ２及び操作端末３の機能構成について説明する。図２は、本実施形態に係る情報通信サーバ２の機能構成を示す図である。図２に示すように、情報通信サーバ２は送信装置５、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）ブレード６、コンテンツストレージ７から構成される。送信装置５とＣＰＵブレード６は対を成しており、送信装置５とＣＰＵブレード６の対を増設することにより、複数の操作端末３に対応できるようになる。コンテンツストレージ７は複数の送信装置５から参照可能である。

情報通信サーバ２を構成する送信装置５は、制御部１００、内部バス１０１、メモリ１０２、映像信号入力部１０３、音声信号入力部１０４、ファイバーチャネル接続部１０５、ファイバーチャネル接続インタフェース１０６、映像処理部１０７、映像エンコーダ１０８、音声処理部１０９、音声エンコーダ１１０、パケット化処理部１１１、ヘッダ処理部１１２、ネットワーク接続部１１３、ネットワークインタフェース１１４、誤り訂正処理部１１５を有している。

制御部１００、メモリ１０２、ネットワーク接続部１１３、ファイバーチャネル接続部１０５、映像処理部１０７、映像エンコーダ１０８、音声処理部１０９、音声エンコーダ１１０、パケット化処理部１１１、ヘッダ処理部１１２、ネットワーク接続部１１３、誤り訂正処理部１１５は内部バス１０１を介して接続されており、相互に情報を通信することが可能である。

ネットワーク接続部１１３は、ネットワークインタフェース１１４を介してネットワーク１に接続されている。ファイバーチャネル接続部１０５は、ファイバーチャネル接続インタフェース１０６を介して、ファイバーチャネル１１５に接続されている。ファイバーチャネルには、動画コンテンツが蓄積されているコンテンツストレージ７が接続されており、送信装置５はファイバーチャネル１２３を介して、自由にコンテンツを参照し、データを得ることができる。

情報通信サーバ２を構成するＣＰＵブレード６は、ＣＰＵ１１６、メモリ１１７、通信部１１８、映像信号出力部１１９、音声信号出力部１２０、制御通信部１２１、内部バス１２２を有している。ＣＰＵ１１６、メモリ１１７、通信部１１８、映像信号出力部１１９、音声信号出力部１２０、制御通信部１２１は内部バス１２２を介して接続されており、相互に情報を通信することが可能である。

通信部１１８はネットワーク１と接続されており、操作端末３に対して映像データ以外の制御情報を相互通信し、随時フィードバックを得ることができる。通信プロトコルには比較的確実に通信可能な方式を用いることができる。たとえばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が考えられる。制御通信部１２１は、制御部１００と接続されており、制御情報を相互通信可能である。

ＣＰＵブレード６は、ＣＰＵ１１６が、メモリ１１７にロードされたプログラムに従って演算を行うことにより、操作端末３上に表示するべき画面信号および音声信号を、メモリ１１７上に生成することが可能である。生成した画面信号および音声信号は、映像信号出力部１１９および音声信号出力部１２０から出力可能である。映像信号出力部１１９および音声信号出力部１２０はそれぞれ、映像信号入力部１０３と音声信号入力部１０４に接続されている。なお、画面信号及び音声信号を生成するための演算をＣＰＵ１１６に実行させるためのプログラムは、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や光学ディスク等の図示していない記憶媒体に記憶されており、その記憶媒体からメモリ１１７にロードされる。

送信装置５は、制御部１００が各接続部、エンコーダおよび処理部を制御し、ＣＰＵブレード６から入力された画面情報をエンコードして、映像データとしてネットワーク１へ送る機能がある。エンコード処理の際は、メモリ１０２が、映像信号入力部１０３および音声信号入力部１０４から入力された映像信号、音声信号をバッファリングする。そして、映像については、映像処理部１０７が映像信号に対して画質調整などを行い、映像エンコーダ１０８がエンコードしてパケット化処理部１１１へ送る。音声については、音声処理部１０９が音声信号に対して音声調整などを行い、音声エンコーダ１１０がエンコードしてパケット化処理部１１１へ送る。

パケット化処理部１１１は、エンコードされた映像と音声を、リップシンクなどのタイミングを考慮しつつ所定のフォーマットの多重化された映像データパケットに変換し、ヘッダ処理部１１２および誤り訂正処理部１１５へ送る。即ち、パケット化処理部１１１が、映像データパケット生成部として機能する。誤り訂正処理部１１５は、ＦＥＣパケット生成のために、送られたパケットをメモリ１０２に必要数バッファリングしてＦＥＣパケットを生成し、生成したＦＥＣパケットをヘッダ処理部１１２へ送る。即ち、ＦＥＣパケットとは、パケット伝送におけるエラーを訂正するためのエラー訂正パケットであり、誤り訂正処理部１１５が、エラー訂正パケット生成部として機能する。

ヘッダ処理部１１２は、送られた映像データパケットとＦＥＣパケットのヘッダにそれぞれに対応するシーケンス番号を付加し、ネットワーク接続部１１３を経由してネットワーク１へ送信する。即ち、ヘッダ処理部１１２が、パケット送信部として機能する。誤り訂正処理部１１５はひとつの映像データパケットのストリームに対して、複数方式のＦＥＣパケットを同時に生成することができる。どのようなＦＥＣ方式が提供されるかは、ＣＰＵブレード６が管理し、把握している。

次に、本実施形態に係る操作端末３の機能構成について説明する。図３は、本実施形態に係る操作端末３の機能構成を示す図である。図３に示すように、操作端末３は、ＣＰＵ１０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、メモリカード１３、メディア制御部１４、ＤＶＤドライブ１５、ＨＤＤ（ハードディスクドライブ）１６、タッチパネル１７、デスクランブラ１８、デマルチプレクサ１９、ビデオ・オーディオデコーダ２０、映像表示制御部２１、表示装置２２、グラフィック・オーディオエンジン２３、オーディオ出力制御部２４、スピーカ２５、ＩＰ通信ポート２６及びＩＰデータ処理部２７を含む。

ＣＰＵ１０は、操作端末３における情報処理や機器制御等を行う。ＲＡＭ１１は、ＣＰＵ１０が情報処理や危機制御等のための演算を行う際の作業領域となる記憶媒体であり、ＣＰＵ１０に演算を行わせるためのプログラムがロードされる。このような各種のプログラムは、ＲＯＭ１２、メモリカード１３、ＤＶＤドライブ１５及びＨＤＤ1６等の不揮発性の記憶媒体に格納されている。メディア制御部１４は、映像データの記録媒体への入出力を制御する

タッチパネル１７は、操作端末３の操作者であるユーザの操作を受け付ける。デスクランブラ１８は、スクランブルされた信号を元に戻す。デマルチプレクサ１９は、多重化された信号を分離する。ビデオ・オーディオデコーダ２０は、符号化された映像データや音声データを復号する。映像表示制御部２１は、液晶ディスプレイ等の表示装置２２への映像表示を制御する。グラフィック・オーディオエンジン２３は、Ｗｅｂページの画面や静止画等を表示する処理を制御するブラウザ・ソフトウェアである。オーディオ出力制御部２４は、スピーカ２５による音声出力を制御する。ＩＰ通信ポート２６は、ネットワークを介したＩＰデータパケットを送受信する。ＩＰデータ処理部２７は、ＩＰ通信ポート２６が受信したＲＴＰパケットや他のＨＴＴＰプロトコルなどで受送信するＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）映像データなどを振り分け、各々に応じた処理を行う。

なお、前述の通り、表示装置２２やスピーカ２５は必ずしも必要ではなく、映像表示制御部２１やオーディオ出力制御部２４からのデータを外部に出力する出力部（映像については例えばＳ端子、Ｄ端子、コンポーネント映像端子等、音声については例えば光デジタル端子、同軸デジタル端子等、映像・音声については例えばＨＤＭＩ端子等）であってもよい。また、ＤＶＤドライブ１５、ＨＤＤ１６等の不揮発性記憶媒体は、必ずしも全て必要でなく、必要なプログラム及びデータを保存するための記憶領域が確保されれば良い。また、各々の記憶装置を複数設けてもよい。

操作端末３は、ＩＰデータパケットを送受信するＩＰ通信ポート２６、ＩＰデータ処理部２７を備え、例えばＴＣＰ、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＤＮＳ（ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）、ＨＴＴＰ、ＲＴＰ、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）等の各種通信プロトコルとブラウザなどのアプリケーションを搭載しており、該ＩＰ通信ポート２６でルータ４４等を介して外部のネットワーク１に接続し、情報通信サーバ２の配信する映像データを受信することができる。

該ＩＰ通信ポート２６で受信したＲＴＰパケットは、ＩＰデータ処理部２７でＦＥＣによるデータ復元処理や、デスクランブラ１８でデスクランブル処理を行ってＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）データに変換され、デマルチプレクサ１９を介してビデオ・オーディオデコーダ２０で復号されて伸張され、映像表示制御部２１とオーディオ出力制御部２４を経て、表示装置２２とスピーカ２５において再生される。

なお、図３に示す各構成のうち、例えばデスクランブラ１８、デマルチプレクサ１９、ビデオ・オーディオデコーダー２０等は、ソフトウェアによって実現されることもある。その場合、夫々の機能を実現するためのソフトウェア・プログラムが、ＲＡＭ１１上にロードされ、ＣＰＵ１０がそれぞれのプログラムに従って演算を行うことにより、夫々の機能が実現される。

本実施形態においては、情報通信サーバ２が送出する映像データを操作端末３が受信して表示装置２２に表示し、ユーザが表示されたメニュー等をタッチパネル１７で選択する。操作端末３はＣＰＵ１０において、ＣＰＵブレード６との通信によって得られた情報に基づき、提供されているＦＥＣ復元方法にどのようなものがあるか把握できる。ＣＰＵブレード６の指示に従ってＦＥＣパケット受信要求の準備を行い、映像データ及びＦＥＣパケットを受信し、パケット復元処理を行った後、ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）信号に変換して再生させる。

操作端末３は、図１に示す“Ａ”のような映像データのデータパケットと、図１に示す“Ａ１”、“Ａ２”のようなＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）パケットを、異なるポートで受信することができる。即ち、データパケットとＦＥＣパケットは、物理的には同一のインタフェースで順番に受信されるが、情報通信における処理の概念としては並列して受信される。

パケット復元のためのＦＥＣ復元方法は、例えば公開規格Ｐｒｏ−ＭＰＥＧなどを基にして図４のように提供される。送受信される映像データパケットは、概念的に図４に示す“１、２、３、・・・Ｍ、Ｍ＋１、Ｍ＋２、・・・”のように、Ｍ行、Ｎ列の縦横のマトリクス状に配置され、連続するＭパケット毎、即ち、マトリクス状に並べられたパケットの各行毎に、夫々のＭ個のパケットデータにおいて１つのパケットの欠損を復元するためのＦＥＣパケットが横方向ＦＥＣパケットとして生成される。

また、図４に示すように、マトリクス状に並べられたパケットの各列毎に、夫々のＮ個のパケットデータにおいて１つのパケットの欠損を復元するためのＦＥＣパケットが縦方向ＦＥＣパケットとして生成される。この縦横ＦＥＣパケットは、対応するＭ個又はＮ個のデータをＸＯＲ（排他的論理和）演算して作り出した復元用のデータを有している。また、映像データパケットＡのＲＴＰヘッダには連続したシーケンス番号が入っている。従って、操作端末３においては、シーケンス番号に抜けが見つかることでパケットロスト発生を検知できる。なお、これらのＦＥＣパケットの生成処理は、送信装置５の誤り訂正処理部１１５によって実行される。

ＦＥＣパケットのＲＴＰヘッダには、そのＦＥＣパケットによるロストパケットの復元対象となるパケットのシーケンス番号、即ち、ＸＯＲ演算の対象となったパケットのシーケンス番号を示すデータが入っており、操作端末３においては、パケットロストが起きた際に、どのＦＥＣパケットを用いて復元するかを判定することが出来る。

図５にＦＥＣ復元方法の違いとロストパケット復元の例を示す。例えば、縦方向のパケットは映像データパケットＮ個＋ＦＥＣパケット1個の計Ｎ＋１個であり、映像データパケットの1つがパケットロストにより消失しても、受信した映像データパケットとＦＥＣパケットの計Ｎ個をＸＯＲ演算することにより、消失した1個のパケットを復元することが可能である。２個以上消失していた場合は消失した全パケットとも復元不可能である。

図５のようにパケットロストが５つ（図中の×印）起こっていた場合、もし横方向のＦＥＣパケットしか提供しないＦＥＣ方法であったとすると、復元できるのはＭ＊（Ｎ−１）＋１で示すパケット一つだけである。また、縦方向のＦＥＣパケットのみ提供する方法であった場合、パケットＭは復元できるが他のパケットは復元不可能である。しかし、縦横両方のＦＥＣパケットを提供する方法であれば、図５に番号で示す通りの順番で全てのパケットを復元することが可能である。尚、図５に示す順番は一例である。

ネットワークによるコンテンツ配信において、受信できるコンテンツの品質は利用する通信回線や受信機の性能により制限される。映像コンテンツは配信サーバによりネットワーク上にデータパケットとして送出され、ルータやスイッチ等の機器を経由して受信機まで届き、受信機内に取り込まれる。その際の１秒当たりのデータ転送容量はビットレートと呼ばれ、各々のコンテンツに固有の値である。この値が大きいほど映像の解像度や滑らかさ等の品質が高くなるが、表示のためのデータ受信に必要な利用帯域は大きくなる。

利用者の利用しているネットワークや受信機の利用可能な帯域が、受信しているコンテンツのビットレートの合計よりも大きければ、問題なくコンテンツの受信再生が可能だが、利用可能な帯域の方が小さい場合、データが受信機まで届かなかったり、受信機内部での再生処理が間に合わなかったりすることで、パケットロストが起こって映像が乱れ、酷い場合は表示不可能になることもある。

ＦＥＣパケットは数を増やすほど復元率が上がるが、映像データ以外にＦＥＣパケットを受信することにより、全体としての必要帯域が大きくなり、却ってＦＥＣパケットを含めた全体のパケットロストが増してしまう問題がある。この問題について、図６のＦＥＣ復元方法とＦＥＣパケット数を示す表に基づき説明する。

図６のようにＦＥＣ復元方法が６つ用意されていた場合、例えばＦＥＣ復元方法Ａでは、映像データパケット１０個毎に縦方向ＦＥＣパケット１個を受け取るようにしており、縦方向のコンテンツパケット１０個に対して最大1個復元可能である。映像データ１００個に対して１０個のＦＥＣパケットを受け取るため、受信帯域としては１０％増しとなる。

一方、ＦＥＣ復元方法ＢからＦにおいては、上述したとおりコンテンツパケットを復元できる可能性は大きくなるが、必要とする受信帯域は増加する。例えばＦＥＣ復元方法ＤやＥの場合は、映像データ１００個に対して２５個のＦＥＣパケットを受け取るため、受信帯域が２５%増となる。この場合、元々は例えば１６Ｍｂｐｓの映像データのストリームを１７Ｍｂｐｓの許容帯域を持つローカルネットワークで受信して、ごく稀にバースト等でパケット落ちする程度であったとしても、ＦＥＣ復元方法ＤやＥを採用したがゆえに２５％増しの２０Ｍｂｐｓの帯域が必要になる。これでは許容帯域の１７Ｍｂｐｓを上回る帯域が必要となり、却って常時パケットロストが起こる可能性がある。そのため、使用しているローカルネットワークに最適な方法を取捨選択する仕組みが必要である。

図１では、ネットワーク１を介して情報通信サーバ２から映像データが格納されているデータパケットＡ、横方向ＦＥＣパケットＡ１と縦方向ＦＥＣパケットＡ２が配信されている。本例の場合、データパケットＡ、縦方向のＦＥＣパケットＡ１、横方向Ａ２のＦＥＣパケットを各々別のポートに送信するため、操作端末３はそれぞれのポートでパケットを受信する必要がある。ＦＥＣを使用しない場合は、データパケットＡのみを受信すればよい。操作端末３は、通常の場合は、情報通信サーバ２から映像データを含むデータパケットＡを常時受信し、再生している。

次に、本実施形態に係る映像通信システムの動作について説明する。図７は、本実施形態に係る映像通信システムの動作を示すシーケンス図である。例えば、ユーザが操作端末３を操作することにより、操作端末３が情報通信サーバ２から情報を受信して動作する場合、即ち、情報通信サーバ２との間で情報をやり取りする応答が必要な場合、情報通信サーバ２においては、使用者に待たせることが無いように、情報の送信を開始するまでの遅延を短くする必要がある。他方、使用者からの操作に対応する必要のない状態、例えば動画が表示されている状態においては特に遅延は問題にならない。

そのため本実施形態に係る情報通信サーバ２は、動画の映像データ送信時のみＦＥＣを利用する。即ち、情報通信サーバ２においては、誤り訂正処理部１１５が、動画の映像データ送信時のみＦＥＣパケットを生成する。このようにすることで使用者へ遅延を意識させることなく情報を配信することが可能となる。また、本実施形態においては、操作端末３側において、動的にＦＥＣ方式を選択する。これにより、動画の品質を保障することが可能になる。

図７に示すように、まず、操作端末３が、ユーザの操作に応じて情報通信サーバ２とネットワークを介して接続し、情報通信サーバ２から情報を取得することにより、メニュー画面のような比較的静的な画面を表示する（Ｓ７０１）。Ｓ７０１の処理においても、図２に示す送信装置５が上述したように機能し、メニュー画面を表示するための低ビットレートの映像データパケットを送信している。メニュー画面の映像データパケットとして、動画よりも低ビットレートの映像データパケットが送信される場合とは、情報通信サーバ２が動的ビットレートに対応しているエンコード方式を採用している場合である。

また、メニュー画面のようなユーザインタフェースとなる画面はユーザの操作への早い応答が求めらるため、低遅延である必要がある。そのため、メニュー画面の映像データパケットの送信に際して、誤り訂正処理部１１５はＦＥＣパケットの生成を行わない。そのため、メニュー画面の映像データパケットを送信する場合、ヘッダ処理部１１２は、生成された映像データパケットを順次ヘッダ処理して送信する。

ユーザが操作端末３を操作し、上記メニュー画面のような静的な画面と比較して、高ビットレートな動画を再生する機能を選択すると（Ｓ７０２）、操作端末３はユーザによる操作に応じた操作情報をＣＰＵブレード６に送信する（Ｓ７０３）。ＣＰＵブレード６は、操作の内容を解析して操作端末３に配信する動画を判断し（Ｓ７０４）、送信装置５の制御部１００に対して再生準備の命令を送る（Ｓ７０５）。送信装置５は、上記メニュー画面用の映像データのパケット化処理部１１１への入力を停止し、メモリ１０２にあらかじめ蓄積してあった動画再生待ち画面のエンコード済みデータをパケット化処理部１１１へ送る。

動画再生待ち画面のエンコード済みデータがパケット化処理部１１１に入力されることにより、動画再生待ち画面の映像データパケットがヘッダ処理部１１２を経て操作端末３に送信され、操作端末３には動画再生待ちの画面が表示される（Ｓ７０６）。

次にＣＰＵブレード６は、操作端末３に対して、ＦＥＣ受信準備通知を送る（Ｓ７０７）。これにより、操作端末３においては、ＦＥＣデータパケットを受信するためのソケットを開いてＦＥＣ受信の準備を始める。そしてＣＰＵブレード６と送信装置５との間で、ＦＥＣ付きの動画映像データを準備する（Ｓ７０８）。この際、動画映像データのソースはＣＰＵブレード６が生成した画面データに限らず、コンテンツストレージ７から取得したものでもかまわない。処理詳細については後述する。ＦＥＣ付きの動画映像データの準備ができると、再生待ち画面に代わって、ＦＥＣ付きの動画映像データを操作端末３へ送る。これにより、情報通信サーバ２及び操作端末３夫々において、ＦＥＣ付き動画コンテンツの再生処理が実行される（Ｓ７０９）。なお、Ｓ７０９においては、操作端末３が最適なＦＥＣ方式を判断する処理や、情報通信サーバ２が、送信するＦＥＣパケットを取捨選択する処理が含まれる。これについては後に詳述する。

その後、ユーザが動画再生の停止操作を操作端末３上で行うと（Ｓ７１０）、上記と同様に操作情報がＣＰＵブレード６へ通知される（Ｓ７１１）。ＣＰＵブレード６では、映像の再生処理を停止して（Ｓ７１２）、送信装置５に対しても再生停止命令を送る（Ｓ７１３）。操作端末３に対してはＦＥＣ送信を終了する通知を送る（Ｓ７１４）。これを受けて操作端末３ではＦＥＣパケットの受信を停止する。

次に送信装置５では、再生停止命令受けたタイミングから一番近い時間の映像データの区切れ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）がパケット化処理部１１１に到達した時点で、ヘッダ処理部１１２が処理を停止して最後に送信したパケットのシーケンス番号を記憶する。また、制御部１００は、映像処理部１０７、音声処理部１０９に入力するソースデータを、ＣＰＵブレード６が生成した静的画面のデータに切り替える（Ｓ７１５）。同時に、誤り訂正処理部１１５へのデータ送信は停止し、動画映像データに関するメモリ１０２上のバッファを破棄する（Ｓ７１６）。

その後、ＣＰＵブレード６が生成した画面は、エンコーダを経由してパケット処理部１１１によるパケット化処理及びヘッダ処理部１１２によるヘッダ処理を経て、操作端末３へ送信される（Ｓ７１７）。この際、ヘッダ処理部１１２は、記録していたパケットのシーケンス番号を利用して、シーケンス番号が不連続にならないようにする。これにより、情報通信サーバ２から送られてくる映像データのパケットはシーケンス番号が連続した一つのストリームの状態を保つので、操作端末３では特にタイミング調整を行う必要はない。

次に図８のフローチャートを用いて、ＦＥＣ付き動画映像データ準備とその表示（Ｓ７０８、Ｓ７０９）の詳細について説明する。図８に示すように、まず、制御部１００は、操作端末３から送信されたユーザの操作情報に基づき、ＣＰＵブレード６が生成した画面もしくは、コンテンツストレージ７に蓄積されたコンテンツのソースデータを映像処理部１０７及び音声処理部１０９へ夫々入力することにより、動画コンテンツの再生を開始する（Ｓ８０１）。

この時点で、パケット化処理部１１１には、操作端末３に再生待ち画面を表示させるための再生待ち画面の映像ソースが入力されている。制御部１００は、パケット化処理部１１１への入力をステップＳ８０１でエンコーダーに入力された映像ソースに切り替えて、パケット化の処理を開始する（ステップＳ８０２）。このときすでにＳ７０６で再生待ち画面がヘッダ処理部１１２を経由してネットワーク１に送信中である。そのため、パケット化処理部１１１は、生成した映像データパケットをメモリ１０２上のバッファに一度格納する（ステップＳ８０３）。

メモリ１０２上のバッファに映像データパケットが格納されると、制御部１００は、誤り訂正処理部１１５を制御し、ＦＥＣパケットの生成処理を開始する（ステップＳ８０４）。このときＦＥＣパケットは図６に示すような複数種類のＦＥＣ方式に対応したＦＥＣパケットを夫々生成する。そのため、ＦＥＣパケットの生成を開始すると、制御部１００は、ＦＥＣパケットの生成処理に必要な映像データパケットがバッファに蓄積されるまで待機し、図５のように縦、横夫々について、図６のように複数種類のＦＥＣ方式に対応するＦＥＣパケットが生成可能となる度にＦＥＣパケットを生成していく（Ｓ８０５／ＮＯ）。

Ｓ８０４、Ｓ８０５において蓄積する映像データパケット数の基準は生成するＦＥＣの種類のうち、もっともＦＥＣ生成に必要な映像データパケット数が多いものに合わせる。例えば、図６の例の場合、制御部１００は、ＦＥＣ復元方式ＦによるＦＥＣパケットを生成可能な映像データパケット、即ち、横２５×縦４のマトリクス状に配置される１００個の映像データパケットがバッファに蓄積され、誤り訂正処理部１１５が、図６に示す複数のＦＥＣ方式夫々によるＦＥＣパケットを全て生成するまで待機する。

そして、図６に示すような複数のＦＥＣ方式について、もっともＦＥＣ生成に必要な映像データパケット数が多いものに合わせてのＦＥＣパケットの生成が完了すると（Ｓ８０５／ＹＥＳ）、制御部１００は、パケット化処理部１１１によって処理中の再生待ち画面の映像データの切れ目を検知して画面の切り替えが可能かを判断し、切れ目に至るまで待機する（Ｓ８０６／ＮＯ）。Ｓ８０６において、制御部１００は、例えば、映像データのＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｕｒｅ）を切り替えのポイントとする。

画面切り替えが可能なポイントに達すると（Ｓ８０６／ＹＥＳ）、制御部１００は、パケット化処理部１１１を制御し、その時点で未送信のパケット化処理済みのパケットを全て送信したのち、再生待ち画面の映像ソースのパケット化処理を停止する（Ｓ８０７）。そして、ヘッダ処理部１１２に入力して操作端末２に送信させるデータパケットを、誤り訂正処理部１１５を経由した再生対象の動画の映像データパケット及びその映像データパケットに基づいて生成されたＦＥＣパケットに切り替える（Ｓ８０８）。

その後、制御部１００の制御に従い、パケット化処理部１１１によって上述したようにパケット化された映像データパケット及び誤り訂正処理部１１５によって生成されたＦＥＣパケットがヘッダ処理部１１２へ送られ、ヘッダ処理を施されたパケットが操作端末３へ送られる（Ｓ８０９）。ここで、Ｓ８０９においては、生成されたＦＥＣパケットが全てヘッダ処理部１１２に入力されるのではなく、操作端末３によって選択されたＦＥＣ復元方式に係るＦＥＣパケットのみがヘッダ処理部１１２に入力され、ヘッダ処理されてネットワーク上に創出される。これにより、操作端末３が含まれるユーザ側のローカルエリアネットワークにおいては、余計なＦＥＣパケットをやり取りする必要がなくなり、ローカルエリアネットワークのネットワーク負荷を低減することができる。これについては後に詳述する。

ここで、Ｓ８０９における映像データパケット及びＦＥＣパケットの送信態様及び作用効果について、図９を参照して説明する。上述したように、Ｓ８０９においてヘッダ処理部１１２が映像データパケット及びＦＥＣデータパケットの送信を開始するタイミングにおいては、図６に示すような複数のＦＥＣ方式について、もっともＦＥＣ生成に必要な映像データパケット数が多いものに合わせてのＦＥＣパケットの生成が完了している。そのため、メモリ１０２に確保されているバッファ領域には、相当数の映像データパケット、横方向のＦＥＣパケット（以降、ＦＥＣパケット１とする）及び縦方向のＦＥＣパケット（以降、ＦＥＣパケット２とする）が格納されている。

即ち、図９（ａ）に示すように、映像データパケット、ＦＥＣパケット１及びＦＥＣパケット２夫々のポートから送信されるパケットは既に用意されている。従って、ヘッダ処理部１１２が映像データパケット、ＦＥＣパケット１及びＦＥＣパケット２に対して順次ヘッダ処理を行って送信することにより、操作端末３には、映像データパケット、ＦＥＣパケット１及びＦＥＣパケット２が平行して到達する。そのため、パケットロストが発生したとしても、ＦＥＣパケットが既に到達しているため、操作端末３はロストパケットの復元を即座に行うことができる。

図９（ｂ）は、図８の動作のように、相当数のＦＥＣパケットの生成が完了してから映像データパケットの送信を開始する処理を行わず、生成されたパケットを順次送信すると共に、映像データパケットが順次生成されることにより生成が可能となったＦＥＣパケットを生成して、それも順次送信する場合の例を示す図である。図９（ｂ）においては、５個のパケット毎に横方向のＦＥＣパケットが生成される場合を例としている。

図９（ｂ）の場合、図に示すパケットが欠損した場合、そのパケットを復元するためには、最初のＦＥＣパケット１の到達を待つ必要がある。そのため、図９（ｂ）に示す待ち時間の間、動画の再生が停止してしまう。図９（ｂ）のような横方向のＦＥＣパケットをを待つ場合の待ち時間であれば、許容範囲にもなり得るが、縦方向のＦＥＣパケットを待つ場合、その待ち時間は更に長くなり、動画再生の品質が損なわれることとなる。

これに対して、本実施形態に係る情報通信サーバ２は、図４のマトリクス状の配置のような予め定められた所定数の映像データパケットのまとまり毎に、複数の異なるＦＥＣ復元方式すべてについてＦＥＣパケットが生成される度に、映像データパケット及びＦＥＣパケットの送信を開始するため、図９（ａ）に示すように、映像データパケット、ＦＥＣパケット１及びＦＥＣパケット２を並列して送信開始する。パケットロストが発生したとしても、操作端末３は、ＦＥＣパケットの到達を待つ必要がなく、動画再生の品質を保つことができる。

なお、図９（ａ）に示す態様においても、操作端末３へのパケットの到達タイミングとロストパケットの発生態様によっては、パケットの復元のためにＦＥＣパケットの到達を待つ必要が生じる可能性もある。これに対して、ヘッダ処理部１１２が、ＦＥＣパケット１、ＦＥＣパケット２を映像データパケットよりも優先して送信することにより、そのような可能性を排除することができる。更には、図４のマトリクス状の配置のような予め定められた所定数の映像データパケットのまとまり毎にパケットの送信を開始する際、先にＦＥＣパケットを全て送信した後に映像データパケットを送信するようにしても良い。これにより、操作端末３において映像データパケットが受信された映像データの再生が開始された際には、既にＦＥＣパケットは全て揃っており、復元のためにＦＥＣパケットの到達を待つ必要がない。

次に、操作端末３の動作について説明する。図１０は、操作端末３において、情報通信サーバ２から映像データを受信再生する際、最適なＦＥＣ復元方法を適用して映像データのストリームを受信する処理を行うＩＰデータ処理部２７における、データ修正処理の制御プログラムのフローチャートである。

まず、操作端末３は、ユーザがタッチパネル１７で、情報通信サーバ２から映像データを受信再生するための所定操作を行うことにより、映像データの受信処理を開始する（Ｓ１０００）。すると、操作端末３は、情報通信サーバ２のＣＰＵブレード６に対して、映像データ送信開始を依頼する。これにより、情報通信サーバ２において、映像データの送信処理が始まる。これにより、図７のＳ７０６のような再生待ち画面表示処理等が実行され、操作端末３において再生待ち画面が表示される。

次に、ＩＰデータ処理部２７は、ＣＰＵブレード６に対して通信を行うことで、提供されるＦＥＣの方法とパラメータ、及びＦＥＣパケットのソースＩＰアドレスと配信ポート番号を得る（Ｓ１００１）。この例では、図６に示したＦＥＣ復元方法Ａ〜Ｆの６種類の復元方法が選択的に利用できることを示す情報が、情報通信サーバ２から送信される。そして、ＩＰデータ処理部２７は、映像データの受信のための手続きに進む。

最初に受信開始する際、ＩＰデータ処理部２７は、まずＦＥＣによるロストパケットを復元せずに受信処理を開始する。そして、パケットロストの発生状況を監視しながら、帯域増加の少ない順にＦＥＣ復元方法を順次試して、最適な方法を選ぶ。なお、本実施形態において、ＩＰデータ処理部２７は、サービスの種類や映像データのストリームのビットレート別に最適として利用したＦＥＣ復元方法の記録を蓄積し、次回同じサービスを利用する場合には、前回最も適していたと判定した方法を使用して映像データ受信を行う（Ｓ１００２）。

次いで、ＩＰデータ処理部２７は、新規データパケットをＩＰ通信ポート２６から装置内に取り込むためのソケットを準備し、映像データのパケットが到着し始めるのを待つ。このとき、操作端末３が情報通信サーバ２とネットワークセッションを確立して映像データの再生を開始した直後であるため、上述した通り、ＦＥＣによるロストパケットの復元処理を実行しない。そして、映像データのパケットがＩＰ通信ポート２６まで届き始めたら、これを取り込んでＩＰデータ処理部２７でＩＰパケットの形態からＴＳ形式のデータに変換してデコーダ１４に送る。この処理により、ユーザ指定の映像データの再生表示が行われる（Ｓ１００３）。即ち、ＩＰデータ処理部２７が、パケット受信部として機能する。

映像データの再生を開始すると、ＩＰデータ処理部２７は、ＩＰ通信ポート２６でパケットを取り込む際に、映像データのパケットのロスト数をカウントしパケットロスト率を計算する(Ｓ１００４)。即ち、ＩＰデータ処理部２７が、エラー率計算部として機能する。そして、パケットロスト率が、所定の許容される率の閾値を超えているか否かを判定し（Ｓ１００５）、超えている場合には（Ｓ１００５／ＹＥＳ）、ＦＥＣによるデータ復元を開始、又はそれまで使っていたＦＥＣ復元方法の変更を行う。

ここで、Ｓ１００５における閾値について説明する。上述したパケットロスト率の閾値は、動画の再生品質のポリシによって予め設定される。もっとも保守的なポリシとしては、閾値を０パケットとして、パケットロストが１つでも発生したらＦＥＣを適用する態様がある。このようなポリシは、主にローカルエリアネットワークの回線品質が高い場合に適用する。

一般的なローカルエリアネットワーク回線で、パケットロストが比較的多く発生する場合は、パケットロスト率の閾値を０パケットよりも高くする。このときの設定方法としては、パケットロスト率が映像の乱れにどの程度影響するか、予め目視により確認することにより許容可能な品質に対応するパケットロスト率を設定する。

例えば、動画データには、敵的にデコードにとって重要な主フレームが挿入されている。その主フレームに対応する動画データについて頻繁にパケットロストが発生すると、画面が大きく崩れてしまう。従って、主フレームに対応するパケットがロストしないように閾値を設定することが好ましい。

また、設定する閾値の上限としては、ＦＥＣによって完全復元できるパケットロストの状態を想定して設定することが考えられる。図６の表によれば、もっとも復元率が低いＦＥＣ復元方式Ａが復元可能なパケットロスト率の上限、即ち、１０％未満が閾値である必要がある。これは１００パケットのうち横方向に１０パケットが連続でロストした場合に相当する。

ＩＰデータ処理部２７は、ＦＥＣ復元方法の変更を行う場合、まず、それまでＦＥＣによる復元を行っていた場合には、そのＦＥＣ復元方法とパケットロスト率を一時記録する（Ｓ１００６）。そして、前記ステップＳ１００１で取得したＦＥＣ復元方法から、今まで使用していた方法に比べ最も帯域増加の少ない方法、即ち、現在選択されているエラー訂正方式の次にネットワーク負荷が高い方式を選択し適用する(Ｓ１００７)。

Ｓ１００７における、変更後のＦＥＣ復元方法を選択して適用する処理は、ＩＰデータ処理部２７がネットワークを介して情報通信サーバ２に変更後のＦＥＣ復元方法を通知する処理である。即ち、ＩＰデータ処理部２７が、方式変更通知部として機能する。これにより、情報通信サーバ２においては、制御部１００が、通知されたＦＥＣ復元方法に基づいてヘッダ処理部１１２に入力するＦＥＣパケットを選択する。その結果、操作端末３によって選択されたＦＥＣ復元方法に応じたＦＥＣパケットが操作端末３に送信されることとなる。

ここで、ＦＥＣ復元パケットの選択ルールについて説明する。例えば、それまでＦＥＣによる復元をせずに映像データ受信していた場合、図６の６つの方法で最も帯域増加の少ないものは映像データの１００個のパケットに対し１０個のＦＥＣパケットを受け取る方法Ａであるため、まずＦＥＣ復元方法Ａを適用する。また、一般的にパケットロストは連続して起こることが多いため、本実施形態に係るＩＰデータ処理部２７は、同じ帯域増加率であれば、Ｍの大きい方、すなわち縦方向のＦＥＣパケットの多い方を優先して採用する。例えば、ＦＥＣ復元方法ＢとＣではＣを、ＦＥＣ復元方法ＤとＥではＥを先に適用する。

今まで受信していなかったＦＥＣパケットを新規に受信する手続きは、映像データパケット受信と同様、ＦＥＣパケットをＩＰ通信ポート２６から装置内に取り込むためのソケットを準備し、ＦＥＣパケットデータが到着し始めたら、該ＦＥＣパケットを使って図４、図５において説明した方法でロストした映像データパケットの復元を開始する（Ｓ１００８）。即ち、ＩＰデータ処理部２７が、パケット復元部として機能する。

ＦＥＣによるデータ復元を行っている場合、ＩＰデータ処理部２７は、データ復元後のパケットロスト率を計算する（Ｓ１００９）。すなわち、受信時にロストしていたパケット数から、復元できたパケット数を引いた値の統計をとり、Ｓ１００６で記録しておいた以前の方法のロスト率と比較し（Ｓ１０１０）、前よりもパケットロスト率が増加するようであれば（Ｓ１０１０／ＹＥＳ）、ステップＳ１０１１に進んでＦＥＣ復元方法を以前のものに戻す。そして、ＩＰデータ処理部２７は、受信中の映像データについての最適なＦＥＣ復元方法として、選択中のＦＥＣ復元方法をＦＥＣ適用方法データベースに、サービス及び映像データのストリームのビットレートと共に記録する（Ｓ１０１３）。

ステップＳ１０１０での比較結果が、以前より向上していた場合（Ｓ１０１０／ＮＯ）、ＩＰデータ処理部２７は、まだ試していないＦＥＣ復元方法があるかを判定する（Ｓ１０１２）。これは、現在の方法以上に復元率の大きい方法が有る可能性を判定することに相当する。復元率がさらに大きい方法が無い場合は（Ｓ１０１２／ＹＥＳ）、その方法を最適方法とし、Ｓ１０１３の処理を行う。

まだ試していないＦＥＣ復元方法がある場合（Ｓ１０１２／ＮＯ）、ＩＰデータ処理部２７は、ステップＳ１００５に戻る。そして、現在適用している方法のパケットロスト率がしきい値の範囲であれば（Ｓ１００５／ＮＯ）、ステップＳ１０１３に進み、ＩＰデータ処理部２７は、該方法を最適方法として記録する。閾値外であれば（Ｓ１００５／ＹＥＳ）、ＩＰデータ処理部２７は、ステップＳ１００６からＳ１０１０を繰り返す。

最適方法が定まると、ＩＰデータ処理部２７は、ユーザが情報通信サーバ２との接続を停止する操作を行うまで（Ｓ１０１４）、該方法を適用して映像データ受信処理を行う（Ｓ１０１４／ＮＯ）。接続を停止する場合（Ｓ１０１４／ＹＥＳ）、ＩＰデータ処理部２７は、データの復元とデコーダへの転送を中止し、ＣＰＵブレード６に接続停止通知を送信し、受信用のソケットを削除する処理を行う（Ｓ１０１５）。

なお、提供されている全てのＦＥＣ復元方法を使用しても、ステップＳ１００５において、パケットロスト率が前記しきい値を超える場合、ＩＰデータ処理部２７は、最もパケットロスト率の少ないＦＥＣ復元方法を選択して処理する。この場合は受信状況が良好でないため、画像や音声が乱れる恐れがある旨を表示装置２２に表示しても良い。これにより、ユーザは、受信中の映像データに低解像度のものや低ビットレートのものがある場合には、それらを選択するという判断を行うことができる。

本実施例においては、通常ＲＴＰでデータ送信する情報通信サーバ２は、ＦＥＣ復元方法を複数用意しているので、操作端末３は、提供されたＦＥＣ復元方法を取捨選択し、常時最適な映像データ受信が行えるように調整することを特徴としている。以上のようにすることで、映像データをネットワークを介して受信して表示する場合に、ユーザのネットワークにおいて最適なＦＥＣ復元方法を合理的に採用して受信することができる。

また、上述したように、本実施形態に係る情報通信サーバ２は、映像表示までの遅延が少ないことが求められる静的な画面から生成される映像の場合ではＦＥＣを用いないことで、遅延を減らし、かつビットレートが高くなるような動画映像では品質を保つために、動画再生の先頭に再生待ち画面を挿入して再生を待たせつつ複数の方式に対応したＦＥＣパケットを生成することで、複数の方式から成るＦＥＣを利用することが可能であり、ユーザによる操作に対する応答性能を向上すると共に、最適なＦＥＣ方法を選択させることができる。

ここで、上述したように、本実施形態に係る映像通信システムにおいて、情報通信サーバ２は、複数の異なるＦＥＣ復元方法に対応したＦＥＣパケットを生成した上で、操作端末３により選択されたＦＥＣ復元方法に対応するＦＥＣパケットのみを選択して送出する。そして、上述したように、操作端末３は、映像データの再生開始当初は、ＦＥＣによるロストパケットの復元を行わない。従って、情報通信サーバ２は、映像データの配信開始当初は、ＦＥＣパケットを送出しない。

これは、操作端末３が情報通信サーバ２に映像データの配信要求を行う度に、最初はＦＥＣパケットが不要であること、即ち、ＦＥＣ復元方法をいずれも選択しないことを通知しても良いし、情報通信サーバ２において制御部１００が、毎回の映像データの配信開始当初においては、ＦＥＣパケットが不要であることを予め判断して、映像データパケットのみをヘッダ処理部１１２に入力するようにしても良い。

また、情報通信サーバ２において、操作端末３からＦＥＣ復元方法を変更する通知を受信した場合、ＦＥＣ復元方法を変更するタイミングが問題となる。これについては、図４において説明したような、マトリクス状に配置された映像データパケットのまとまりを利用することが好ましい。上述したように、本実施形態において、情報通信サーバ２は、もっともＦＥＣ生成に必要な映像データパケット数が多いものに合わせてＦＥＣパケットを生成する。即ち、図６の例の場合、情報通信サーバ２は、映像データパケット１００個毎にＡ〜ＦすべてのＦＥＣ復元方法によるＦＥＣパケットの生成する処理を繰り返す。

そして、ＦＥＣパケットは図４に示すようにマトリクス状に配置された映像データパケットに対して適用して初めて意味があり、マトリクス状に配置された映像データパケットの途中でＦＥＣ方式を変更しても意味がない。従って、情報通信サーバ２が、操作端末３からの通知に応じてＦＥＣ復元方式を変更する、即ち、ヘッダ処理部１１２に入力するＦＥＣパケットの取捨選択を変更するタイミングは、図４に示すようなマトリクス状に配置された映像データパケットのまとまり毎のタイミングとすることが好ましい。

尚、異なるＦＥＣ復元方式の全てについてＦＥＣパケットを生成するということが可能となるのは、図６に示すように、本実施形態において適用されるＦＥＣ復元方式が、マトリクス状にまとめられるパケットデータの数として、１００個という同一の数を採用しているからである。そして、これにより、上述したように、ＦＥＣパケットの取捨選択を変更するタイミング、即ち、ＦＥＣ復元方式を変更するタイミングとして、マトリクス状に配置された映像データパケットのまとまり毎のタイミングを容易に用いることができる。従って、情報通信サーバ２において選択可能な複数のＦＥＣ復元方式は、マトリクス状にまとめられるパケットデータの数として、いずれも同一数を採用することが好ましい。

他方、操作端末３においては、ＦＥＣ復元方式の変更を通知した後、情報通信サーバ２から送信されるＦＥＣパケットが通知した復元方式に変更されたタイミングを判断する必要がある。これは、上述したように、ＦＥＣパケットのヘッダ情報において復元対象の映像データパケットが指定されているため、ＩＰデータ処理部２７は、その情報を参照することにより判断することが可能である。

この他、より容易にＦＥＣ復元方式の変更を判断する方法として、情報通信サーバ２が、ＦＥＣ復元方式を変更するタイミング、即ち、ヘッダ処理部１１２に入力するＦＥＣパケットを変更するタイミングにおいて、ＦＥＣ復元方式が変更されることを示す情報を挿入する態様が考えられる。ＦＥＣ復元方式が変更されることを示す情報を挿入する態様としては、映像データもＦＥＣデータも含まない空のパケットデータを所定数連続して送出する態様や、ＦＥＣ復元方式が変更された後、最初に送出されるパケットのヘッダ情報として、ＦＥＣ復元方式が変更されたことや変更後のＦＥＣ復元方式を示す情報を挿入する態様が考えられる。これにより、操作端末３においては、連続して受信された空パケットや受信されたパケットのヘッダ情報を確認することにより、容易にＦＥＣ復元方式が変更されたことを判断することができる。

以上、本発明について詳細に説明したが、本発明は、ここに記載された映像通信システムの実施例に限定されるものではなく、他の映像通信システムにも広く適用できることは言うまでもない。

１ ネットワーク
２ 情報通信サーバ
３ 操作端末
４１、４３、４４ ルータ、
４２ スイッチ
５ 送信装置
６ ＣＰＵブレード
７ コンテンツストレージ
１０ ＣＰＵ
１１ ＲＡＭ
１２ メモリ
１３ メモリカード
１４ メディア制御部
１５ ＤＶＤドライブ
１６ ＨＤＤ
１７ タッチパネル
１８ デスクランブラ
１９ デマルチプレクサ
２０ ビデオ・オーディオデコーダ
２１ 映像表示制御部
２２ 表示装置
２３ グラフィック・オーディオエンジン
２４ オーディオ出力制御部
２５ スピーカ
２６ ＩＰ通信ポート
２７ ＩＰデータ処理部
１００ 制御部
１０１ バス
１０２ メモリ
１０３ 映像信号入力部
１０４ 音声信号入力部
１０５ ファイバーチャネル接続部
１０６ ファイバーチャネルＩ／Ｆ
１０７ 映像処理部
１０８ 映像エンコーダ
１０９ 音声処理部
１１０ 音声エンコーダ
１１１ パケット化処理部
１１２ ヘッダ処理部
１１３ ネットワーク接続部
１１４ ネットワークＩ／Ｆ
１１５ 誤り訂正処理部
１１６ ＣＰＵ
１１７ メモリ
１１８ 通信部
１１９ 映像信号出力部
１２０ 音声信号出力部
１２１ 制御通信部

Claims (15)

1. 映像を再生する再生装置からのネットワークを介した要求に応じて映像情報を配信する映像配信装置であって、
   前記要求に係る映像情報に基づき、前記映像情報をネットワークを介して送信するための映像データパケットを生成して記憶媒体に記憶させる映像データパケット生成部と、
   前記生成された映像データパケットに基づき、予め定められた所定数の前記映像データパケットのまとまり毎に、パケット伝送におけるエラーを訂正するためのエラー訂正パケットを生成して記憶媒体に記憶させるエラー訂正パケット生成部と、
   前記生成された映像データパケット及びエラー訂正パケットをネットワークを介して前記再生装置に送信するパケット送信部とを含み、
   前記エラー訂正パケット生成部は、複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であり、
   前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記複数の異なるエラー訂正方式すべてについて前記エラー訂正パケットが生成される度に、前記エラー訂正パケットが生成された前記映像データパケット及び前記生成されたエラー訂正パケットの送信を開始し、前記生成されたエラー訂正パケットのうち前記再生装置によって指定されたエラー訂正方式に係るエラー訂正パケットのみを送信することを特徴とする映像配信装置。
2. 前記パケット送信部は、前記再生装置によってエラー訂正方式が指定された場合、前記予め定められた所定数の前記映像データパケットのまとまりの切り替わりに応じて、前記生成されたエラー訂正パケットのうち送信するエラー訂正パケットを変更することを特徴とする請求項１に記載の映像配信装置。
3. 前記パケット送信部は、前記再生装置による指定に応じて送信するエラー訂正パケットを変更する場合に、エラー訂正方式を変更することを示すパケットを送信することを特徴とする請求項１または２に記載の映像配信装置。
4. 前記パケット送信部は、前記再生装置による指定に応じて送信するエラー訂正パケットを変更する場合に、エラー訂正方式を変更することを示す情報を変更後に送信するパケットのヘッダ情報に挿入することを特徴とする請求項１または２に記載の映像配信装置。
5. 前記エラー訂正パケット生成部は、前記予め定められた所定数の前記映像データパケットのまとまり毎に、複数の異なる前記映像データパケットの組み合わせについて排他的論理和を計算することによって複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成することを特徴とする請求項１乃至４いずれか１項に記載の映像配信装置。
6. 前記エラー訂正パケット生成部は、前記再生装置に配信される映像がユーザインタフェースとなる画面の映像である場合、前記エラー訂正パケットを生成しないものであり、
   前記パケット送信部は、前記ユーザインタフェースとなる画面の映像に基づいて映像データパケットが生成された場合、前記予め定められた所定数の前記映像データパケットのまとまりとは無関係に前記映像データパケットの送信を開始することを特徴とする請求項１乃至５いずれか１項に記載の映像配信装置。
7. 前記パケット送信部は、前記映像データパケットよりも前記エラー訂正パケットを優先して送信することを特徴とする請求項１乃至６いずれか１項に記載の映像配信装置。
8. 前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記指定されたエラー訂正方式に係るエラー訂正パケットをすべて送信した後に前記映像データパケットを送信することを特徴とする請求項７に記載の映像配信装置。
9. 複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であって、選択された一のエラー訂正方式に係るエラー訂正パケットと共に映像情報に基づいて生成した映像データパケットを送信する映像配信装置から、ネットワークを介して映像情報を受信して再生する再生装置であって、
   再生するべき映像情報に基づいて生成された複数の映像データパケット及びパケット伝送におけるエラーによって欠損した前記映像データパケットを復元するためのエラー訂正パケットを受信するパケット受信部と、
   前記受信されたエラー訂正パケットに基づき、パケット伝送におけるエラーによって欠損した前記映像データパケットを前記選択されたエラー訂正方式によって復元するパケット復元部と、
   前記受信された複数の映像データパケットに基づき、パケット伝送におけるエラーの発生割合であるエラー率を計算するエラー率計算部と、
   前記計算されたエラー率が予め定められた所定の閾値を超えている場合、前記エラー訂正方式の変更を前記映像配信装置に通知する方式変更通知部とを含むことを特徴とする再生装置。
10. 前記閾値は、前記複数の異なるエラー訂正方式において、所定数の前記映像データパケットに対して復元可能な欠損したパケット数の割合を示す復元率のうち最も低い値を上限として定められることを特徴とする請求項９に記載の再生装置。
11. 前記方式変更通知部は、前記計算されたエラー率が予め定められた所定の閾値を超えている場合、異なる複数のエラー訂正方式のうち、現在選択されているエラー訂正方式の次にネットワーク負荷が高いエラー訂正方式を選択して前記映像配信装置に通知する事を特徴とする請求項９または１０に記載の再生装置。
12. 前記映像配信装置は、予め定められた所定数の前記映像データパケットをデータが連続する順番に複数行に配置することによりマトリクス状に配置した上でその行方向及び列方向夫々について排他的論理和を計算することによって前記エラー訂正パケットを生成し、前記マトリクス状の配置態様を変更することによって複数の異なるエラー訂正方式を実現するものであり、
    前記方式変更通知部は、現在選択されているエラー訂正方式の次にネットワーク負荷が高いエラー訂正方式が複数ある場合には、前記映像データパケットのマトリクス状の配置において、列数が多い方式優先的に選択して前記映像配信装置に通知する事を特徴とする請求項１１に記載の再生装置。
13. 前記パケット復元部は、前記エラー訂正方式の変更が通知された後、エラー訂正方式を変更することを示すパケットが受信された場合に、前記エラー訂正方式を切り替えることを特徴とする請求項９乃至１２いずれか１項に記載の再生装置。
14. 前記パケット復元部は、前記エラー訂正方式の変更が通知された後、受信された前記映像データパケットまたは前記エラー訂正パケットのヘッダ情報にエラー訂正方式を変更することを示す情報が含まれていた場合に、前記エラー訂正方式を切り替えることを特徴とする請求項９乃至１２いずれか１項に記載の再生装置。
15. 請求項１乃至８いずれか１項に記載の映像配信装置と、請求項９乃至１４いずれか１項に記載の再生装置とを含むことを特徴とする映像通信システム。

Images