映像を再生する再生装置からのネットワークを介した要求に応じて映像情報を配信する映像配信装置であって、前記要求に係る映像情報に基づき、前記映像情報をネットワークを介して送信するための映像データパケットを生成して記憶媒体に記憶させる映像データパケット生成部と、前記生成された映像データパケットに基づき、予め定められた所定数の前記映像データパケットのまとまり毎に、パケット伝送におけるエラーを訂正するためのエラー訂正パケットを生成して記憶媒体に記憶させるエラー訂正パケット生成部と、前記生成された映像データパケット及びエラー訂正パケットをネットワークを介して前記再生装置に送信するパケット送信部とを含み、前記エラー訂正パケット生成部は、複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であり、前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記複数の異なるエラー訂正方式すべてについて前記エラー訂正パケットが生成される度に、前記エラー訂正パケットが生成された前記映像データパケット及び前記生成されたエラー訂正パケットの送信を開始し、前記生成されたエラー訂正パケットのうち前記再生装置によって指定されたエラー訂正方式に係るエラー訂正パケットのみを送信することを特徴とする映像配信装置。前記パケット送信部は、前記再生装置によってエラー訂正方式が指定された場合、前記予め定められた所定数の前記映像データパケットのまとまりの切り替わりに応じて、前記生成されたエラー訂正パケットのうち送信するエラー訂正パケットを変更することを特徴とする請求項1に記載の映像配信装置。前記パケット送信部は、前記再生装置による指定に応じて送信するエラー訂正パケットを変更する場合に、エラー訂正方式を変更することを示すパケットを送信することを特徴とする請求項1または2に記載の映像配信装置。前記パケット送信部は、前記再生装置による指定に応じて送信するエラー訂正パケットを変更する場合に、エラー訂正方式を変更することを示す情報を変更後に送信するパケットのヘッダ情報に挿入することを特徴とする請求項1または2に記載の映像配信装置。前記エラー訂正パケット生成部は、前記予め定められた所定数の前記映像データパケットのまとまり毎に、複数の異なる前記映像データパケットの組み合わせについて排他的論理和を計算することによって複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成することを特徴とする請求項1乃至4いずれか1項に記載の映像配信装置。前記エラー訂正パケット生成部は、前記再生装置に配信される映像がユーザインタフェースとなる画面の映像である場合、前記エラー訂正パケットを生成しないものであり、前記パケット送信部は、前記ユーザインタフェースとなる画面の映像に基づいて映像データパケットが生成された場合、前記予め定められた所定数の前記映像データパケットのまとまりとは無関係に前記映像データパケットの送信を開始することを特徴とする請求項1乃至5いずれか1項に記載の映像配信装置。前記パケット送信部は、前記映像データパケットよりも前記エラー訂正パケットを優先して送信することを特徴とする請求項1乃至6いずれか1項に記載の映像配信装置。前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記指定されたエラー訂正方式に係るエラー訂正パケットをすべて送信した後に前記映像データパケットを送信することを特徴とする請求項7に記載の映像配信装置。複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であって、選択された一のエラー訂正方式に係るエラー訂正パケットと共に映像情報に基づいて生成した映像データパケットを送信する映像配信装置から、ネットワークを介して映像情報を受信して再生する再生装置であって、再生するべき映像情報に基づいて生成された複数の映像データパケット及びパケット伝送におけるエラーによって欠損した前記映像データパケットを復元するためのエラー訂正パケットを受信するパケット受信部と、前記受信されたエラー訂正パケットに基づき、パケット伝送におけるエラーによって欠損した前記映像データパケットを前記選択されたエラー訂正方式によって復元するパケット復元部と、前記受信された複数の映像データパケットに基づき、パケット伝送におけるエラーの発生割合であるエラー率を計算するエラー率計算部と、前記計算されたエラー率が予め定められた所定の閾値を超えている場合、前記エラー訂正方式の変更を前記映像配信装置に通知する方式変更通知部とを含むことを特徴とする再生装置。前記閾値は、前記複数の異なるエラー訂正方式において、所定数の前記映像データパケットに対して復元可能な欠損したパケット数の割合を示す復元率のうち最も低い値を上限として定められることを特徴とする請求項9に記載の再生装置。前記方式変更通知部は、前記計算されたエラー率が予め定められた所定の閾値を超えている場合、異なる複数のエラー訂正方式のうち、現在選択されているエラー訂正方式の次にネットワーク負荷が高いエラー訂正方式を選択して前記映像配信装置に通知する事を特徴とする請求項9または10に記載の再生装置。前記映像配信装置は、予め定められた所定数の前記映像データパケットをデータが連続する順番に複数行に配置することによりマトリクス状に配置した上でその行方向及び列方向夫々について排他的論理和を計算することによって前記エラー訂正パケットを生成し、前記マトリクス状の配置態様を変更することによって複数の異なるエラー訂正方式を実現するものであり、前記方式変更通知部は、現在選択されているエラー訂正方式の次にネットワーク負荷が高いエラー訂正方式が複数ある場合には、前記映像データパケットのマトリクス状の配置において、列数が多い方式優先的に選択して前記映像配信装置に通知する事を特徴とする請求項11に記載の再生装置。前記パケット復元部は、前記エラー訂正方式の変更が通知された後、エラー訂正方式を変更することを示すパケットが受信された場合に、前記エラー訂正方式を切り替えることを特徴とする請求項9乃至12いずれか1項に記載の再生装置。前記パケット復元部は、前記エラー訂正方式の変更が通知された後、受信された前記映像データパケットまたは前記エラー訂正パケットのヘッダ情報にエラー訂正方式を変更することを示す情報が含まれていた場合に、前記エラー訂正方式を切り替えることを特徴とする請求項9乃至12いずれか1項に記載の再生装置。請求項1乃至8いずれか1項に記載の映像配信装置と、請求項9乃至14いずれか1項に記載の再生装置とを含むことを特徴とする映像通信システム。上述したように、FECでは、誤り訂正の修復度は、データと共に送出する復元用の冗長パケット以下FECパケットと称するの量により決まる。すなわちFECパケットを多く送れば送るほどロストパケットの復元率は大きくなるが、その分、送信データ量が増え、ネットワークに負荷がかかり帯域不足を起こしやすくなる問題がある。そして、非業務用ネットワーク機器の場合、特許文献1のように受信機側から誤り訂正率を配信サーバに知らせることで、サーバにより経路を調整して輻輳状態を調整してもらえるのは、ローカルネットワークの入り口、即ちルータまでである。ローカルネットワーク内では一般的に経路調整などは出来ず、また外部のネットワークより許容帯域が小さいことが多いため、最終的にローカルの操作端末までRTPデータが届いた際には、パケットロストを起こしていることになる。そのため、操作端末においては自身のデータ受信能力や、ローカルネットワークの許容帯域に応じて、FECを使用したストリーミング品質保持の調整を行う方法を開発する必要がある。特許文献2に開示された技術は、ネットワークによるテレビ放送のような形態が想定されたものであり、サーバから配信された映像データを複数のクライアントが受信することが前提となっている。そのため、予めローカルネットワークの入口であるルータに複数のFEC方式、即ち冗長性の異なるFEC方式によるFECパケットが届いており、ローカルネットワーク内の各端末は、ルータから取得するFECパケットを選択することにより、FEC方式を変更する。このような形態を、クライアントとサーバとが1対1でデータをやり取りする動画配信の形態に適用することも可能であるが、1のクライアントに映像を配信するために、複数のFEC方式によるFECパケットを配信することは非効率である。そのため、ローカルエリアネットワーク内に接続されたクライアントにおいて、最適なFEC方式を選択して受信する方法として、クライアントとサーバとが1対1でデータをやり取りする動画配信の形態に適した方法が求められる。本発明の目的は前記した課題に鑑み、情報通信サーバが配信するコンテンツを受信して再生する際のパケットロストを低減した映像通信システムを提供することにある。上記の目的を達成するために、本発明の一態様は、映像を再生する再生装置からのネットワークを介した要求に応じて映像情報を配信する映像配信装置であって、前記要求に係る映像情報に基づき、前記映像情報をネットワークを介して送信するための映像データパケットを生成して記憶媒体に記憶させる映像データパケット生成部と、前記生成された映像データパケットに基づき、予め定められた所定数の前記映像データパケットのまとまり毎に、パケット伝送におけるエラーを訂正するためのエラー訂正パケットを生成して記憶媒体に記憶させるエラー訂正パケット生成部と、前記生成された映像データパケット及びエラー訂正パケットをネットワークを介して前記再生装置に送信するパケット送信部とを含み、前記エラー訂正パケット生成部は、複数の異なるエラー訂正方式夫々に対応するエラー訂正パケットを生成可能であり、前記パケット送信部は、予め定められた所定数の前記映像データパケットのまとまり毎に、前記複数の異なるエラー訂正方式すべてについて前記エラー訂正パケットが生成される度に、前記エラー訂正パケットが生成された前記映像データパケット及び前記生成されたエラー訂正パケットの送信を開始することを特徴とする。また、本発明の他の態様は、ネットワークを介して映像情報を受信して再生する再生装置であって、再生するべき映像情報に基づいて生成された複数の映像データパケット及びパケット伝送におけるエラーによって欠損した前記映像データパケットを復元するためのエラー訂正パケットを受信するパケット受信部と、前記受信されたエラー訂正パケットに基づき、パケット伝送におけるエラーによって欠損した前記映像データパケットを前記選択されたエラー訂正方式によって復元するパケット復元部と、前記受信された複数の映像データパケットに基づき、パケット伝送におけるエラーの発生割合であるエラー率を計算するエラー率計算部と、前記計算されたエラー率が予め定められた所定の閾値を超えている場合、前記エラー訂正方式の変更を前記映像配信装置に通知する方式変更通知部とを含むことを特徴とする。また、本発明の更に他の態様は、映像通信システムであって、上述した映像配信装置と、上述した再生装置とを含むことを特徴とする。本発明により、複数のユーザがホームネットワーク上の機器を利用する場合に、簡単にレジューム再生できる機能を提供することが可能となる。以下、図面を参照して本発明の実施形態に係る映像通信システムについて説明する。図1は本実施形態に係るの映像通信システムの構成を示すブロック図である。図1に示すように、本実施形態に係る映像通信システムにおいては、情報通信サーバ2とサーバから配信された映像を受信、再生する再生装置としての機能を備える操作端末3が、ルータ41、43、44やスイッチ42などのネットワーク中継機器を経由して、映像データパケットやFECパケットを送受信している。ネットワーク1は、様々なネットワーク物理層例えば光、有線、または無線ネットワークを含むを使用して実現されるインターネットプロトコル通信ネットワークであり、ルータやスイッチ、ハブなど、データパケットを送信元から送信先へ正確に送り届けるための通信制御機器41~44も含む。情報通信サーバ2は、映像データをRTPReal-timeTransportProtocolプロトコルで配信することにより、映像送信サービスを行うためのサーバシステムである。CPUブレード6で生成された映像コンテンツもしくは、ストレージ7に蓄えられた映像コンテンツは、送信装置5で必要に応じて符号化されてデータ量の圧縮処理を施され、所定のデータパケットとされてFECパケットを伴って、ネットワーク1へ送信される。操作端末3は映像データを受信して、使用者のために映像を再生する映像受信再生装置である。ユーザは操作端末3の画面に表示されたユーザインタフェースを参照しつつ、タッチパネルインタフェースで各種の機能についての指示を入力する。図1に示すように、操作端末3はローカルネットワーク4に接続され、ローカルネットワーク4はルータ44を経由して、外部のネットワーク1と接続されている。なお、操作端末3は必ずしも表示装置やスピーカを備えている必要は無く、外部の表示装置やスピーカに接続される受信装置例えばセットトップボックスSTBであってもよい。次に、本実施形態に係る情報通信サーバ2及び操作端末3の機能構成について説明する。図2は、本実施形態に係る情報通信サーバ2の機能構成を示す図である。図2に示すように、情報通信サーバ2は送信装置5、CPUCentralProcessingUnitブレード6、コンテンツストレージ7から構成される。送信装置5とCPUブレード6は対を成しており、送信装置5とCPUブレード6の対を増設することにより、複数の操作端末3に対応できるようになる。コンテンツストレージ7は複数の送信装置5から参照可能である。情報通信サーバ2を構成する送信装置5は、制御部100、内部バス101、メモリ102、映像信号入力部103、音声信号入力部104、ファイバーチャネル接続部105、ファイバーチャネル接続インタフェース106、映像処理部107、映像エンコーダ108、音声処理部109、音声エンコーダ110、パケット化処理部111、ヘッダ処理部112、ネットワーク接続部113、ネットワークインタフェース114、誤り訂正処理部115を有している。制御部100、メモリ102、ネットワーク接続部113、ファイバーチャネル接続部105、映像処理部107、映像エンコーダ108、音声処理部109、音声エンコーダ110、パケット化処理部111、ヘッダ処理部112、ネットワーク接続部113、誤り訂正処理部115は内部バス101を介して接続されており、相互に情報を通信することが可能である。ネットワーク接続部113は、ネットワークインタフェース114を介してネットワーク1に接続されている。ファイバーチャネル接続部105は、ファイバーチャネル接続インタフェース106を介して、ファイバーチャネル115に接続されている。ファイバーチャネルには、動画コンテンツが蓄積されているコンテンツストレージ7が接続されており、送信装置5はファイバーチャネル123を介して、自由にコンテンツを参照し、データを得ることができる。情報通信サーバ2を構成するCPUブレード6は、CPU116、メモリ117、通信部118、映像信号出力部119、音声信号出力部120、制御通信部121、内部バス122を有している。CPU116、メモリ117、通信部118、映像信号出力部119、音声信号出力部120、制御通信部121は内部バス122を介して接続されており、相互に情報を通信することが可能である。通信部118はネットワーク1と接続されており、操作端末3に対して映像データ以外の制御情報を相互通信し、随時フィードバックを得ることができる。通信プロトコルには比較的確実に通信可能な方式を用いることができる。たとえばTCPTransmissionControlProtocolが考えられる。制御通信部121は、制御部100と接続されており、制御情報を相互通信可能である。CPUブレード6は、CPU116が、メモリ117にロードされたプログラムに従って演算を行うことにより、操作端末3上に表示するべき画面信号および音声信号を、メモリ117上に生成することが可能である。生成した画面信号および音声信号は、映像信号出力部119および音声信号出力部120から出力可能である。映像信号出力部119および音声信号出力部120はそれぞれ、映像信号入力部103と音声信号入力部104に接続されている。なお、画面信号及び音声信号を生成するための演算をCPU116に実行させるためのプログラムは、HDDHardDiskDriveや光学ディスク等の図示していない記憶媒体に記憶されており、その記憶媒体からメモリ117にロードされる。送信装置5は、制御部100が各接続部、エンコーダおよび処理部を制御し、CPUブレード6から入力された画面情報をエンコードして、映像データとしてネットワーク1へ送る機能がある。エンコード処理の際は、メモリ102が、映像信号入力部103および音声信号入力部104から入力された映像信号、音声信号をバッファリングする。そして、映像については、映像処理部107が映像信号に対して画質調整などを行い、映像エンコーダ108がエンコードしてパケット化処理部111へ送る。音声については、音声処理部109が音声信号に対して音声調整などを行い、音声エンコーダ110がエンコードしてパケット化処理部111へ送る。パケット化処理部111は、エンコードされた映像と音声を、リップシンクなどのタイミングを考慮しつつ所定のフォーマットの多重化された映像データパケットに変換し、ヘッダ処理部112および誤り訂正処理部115へ送る。即ち、パケット化処理部111が、映像データパケット生成部として機能する。誤り訂正処理部115は、FECパケット生成のために、送られたパケットをメモリ102に必要数バッファリングしてFECパケットを生成し、生成したFECパケットをヘッダ処理部112へ送る。即ち、FECパケットとは、パケット伝送におけるエラーを訂正するためのエラー訂正パケットであり、誤り訂正処理部115が、エラー訂正パケット生成部として機能する。ヘッダ処理部112は、送られた映像データパケットとFECパケットのヘッダにそれぞれに対応するシーケンス番号を付加し、ネットワーク接続部113を経由してネットワーク1へ送信する。即ち、ヘッダ処理部112が、パケット送信部として機能する。誤り訂正処理部115はひとつの映像データパケットのストリームに対して、複数方式のFECパケットを同時に生成することができる。どのようなFEC方式が提供されるかは、CPUブレード6が管理し、把握している。次に、本実施形態に係る操作端末3の機能構成について説明する。図3は、本実施形態に係る操作端末3の機能構成を示す図である。図3に示すように、操作端末3は、CPU10、RAMRandomAccessMemory11、ROMRead-OnlyMemory12、メモリカード13、メディア制御部14、DVDドライブ15、HDDハードディスクドライブ16、タッチパネル17、デスクランブラ18、デマルチプレクサ19、ビデオオーディオデコーダ20、映像表示制御部21、表示装置22、グラフィックオーディオエンジン23、オーディオ出力制御部24、スピーカ25、IP通信ポート26及びIPデータ処理部27を含む。CPU10は、操作端末3における情報処理や機器制御等を行う。RAM11は、CPU10が情報処理や危機制御等のための演算を行う際の作業領域となる記憶媒体であり、CPU10に演算を行わせるためのプログラムがロードされる。このような各種のプログラムは、ROM12、メモリカード13、DVDドライブ15及びHDD16等の不揮発性の記憶媒体に格納されている。メディア制御部14は、映像データの記録媒体への入出力を制御するタッチパネル17は、操作端末3の操作者であるユーザの操作を受け付ける。デスクランブラ18は、スクランブルされた信号を元に戻す。デマルチプレクサ19は、多重化された信号を分離する。ビデオオーディオデコーダ20は、符号化された映像データや音声データを復号する。映像表示制御部21は、液晶ディスプレイ等の表示装置22への映像表示を制御する。グラフィックオーディオエンジン23は、Webページの画面や静止画等を表示する処理を制御するブラウザソフトウェアである。オーディオ出力制御部24は、スピーカ25による音声出力を制御する。IP通信ポート26は、ネットワークを介したIPデータパケットを送受信する。IPデータ処理部27は、IP通信ポート26が受信したRTPパケットや他のHTTPプロトコルなどで受送信するHTMLHyperTextMarkupLanguage映像データなどを振り分け、各々に応じた処理を行う。なお、前述の通り、表示装置22やスピーカ25は必ずしも必要ではなく、映像表示制御部21やオーディオ出力制御部24からのデータを外部に出力する出力部映像については例えばS端子、D端子、コンポーネント映像端子等、音声については例えば光デジタル端子、同軸デジタル端子等、映像音声については例えばHDMI端子等であってもよい。また、DVDドライブ15、HDD16等の不揮発性記憶媒体は、必ずしも全て必要でなく、必要なプログラム及びデータを保存するための記憶領域が確保されれば良い。また、各々の記憶装置を複数設けてもよい。操作端末3は、IPデータパケットを送受信するIP通信ポート26、IPデータ処理部27を備え、例えばTCP、UDPUserDatagramProtocol、DHCPDynamicHostConfigurationProtocol、DNSdomainNameServer、HTTP、RTP、RTSPRealTimeStreamingProtocol、MLDMulticastListenerDiscovery、IGMPInternetGroupManagementProtocol等の各種通信プロトコルとブラウザなどのアプリケーションを搭載しており、該IP通信ポート26でルータ44等を介して外部のネットワーク1に接続し、情報通信サーバ2の配信する映像データを受信することができる。該IP通信ポート26で受信したRTPパケットは、IPデータ処理部27でFECによるデータ復元処理や、デスクランブラ18でデスクランブル処理を行ってTSTransportStreamデータに変換され、デマルチプレクサ19を介してビデオオーディオデコーダ20で復号されて伸張され、映像表示制御部21とオーディオ出力制御部24を経て、表示装置22とスピーカ25において再生される。なお、図3に示す各構成のうち、例えばデスクランブラ18、デマルチプレクサ19、ビデオオーディオデコーダー20等は、ソフトウェアによって実現されることもある。その場合、夫々の機能を実現するためのソフトウェアプログラムが、RAM11上にロードされ、CPU10がそれぞれのプログラムに従って演算を行うことにより、夫々の機能が実現される。本実施形態においては、情報通信サーバ2が送出する映像データを操作端末3が受信して表示装置22に表示し、ユーザが表示されたメニュー等をタッチパネル17で選択する。操作端末3はCPU10において、CPUブレード6との通信によって得られた情報に基づき、提供されているFEC復元方法にどのようなものがあるか把握できる。CPUブレード6の指示に従ってFECパケット受信要求の準備を行い、映像データ及びFECパケットを受信し、パケット復元処理を行った後、TSTransportStream信号に変換して再生させる。操作端末3は、図1に示すAのような映像データのデータパケットと、図1に示すA1、A2のようなFECForwardErrorCorrectionパケットを、異なるポートで受信することができる。即ち、データパケットとFECパケットは、物理的には同一のインタフェースで順番に受信されるが、情報通信における処理の概念としては並列して受信される。パケット復元のためのFEC復元方法は、例えば公開規格Pro-MPEGなどを基にして図4のように提供される。送受信される映像データパケットは、概念的に図4に示す1、2、3、M、M1、M2、のように、M行、N列の縦横のマトリクス状に配置され、連続するMパケット毎、即ち、マトリクス状に並べられたパケットの各行毎に、夫々のM個のパケットデータにおいて1つのパケットの欠損を復元するためのFECパケットが横方向FECパケットとして生成される。また、図4に示すように、マトリクス状に並べられたパケットの各列毎に、夫々のN個のパケットデータにおいて1つのパケットの欠損を復元するためのFECパケットが縦方向FECパケットとして生成される。この縦横FECパケットは、対応するM個又はN個のデータをXOR排他的論理和演算して作り出した復元用のデータを有している。また、映像データパケットAのRTPヘッダには連続したシーケンス番号が入っている。従って、操作端末3においては、シーケンス番号に抜けが見つかることでパケットロスト発生を検知できる。なお、これらのFECパケットの生成処理は、送信装置5の誤り訂正処理部115によって実行される。FECパケットのRTPヘッダには、そのFECパケットによるロストパケットの復元対象となるパケットのシーケンス番号、即ち、XOR演算の対象となったパケットのシーケンス番号を示すデータが入っており、操作端末3においては、パケットロストが起きた際に、どのFECパケットを用いて復元するかを判定することが出来る。図5にFEC復元方法の違いとロストパケット復元の例を示す。例えば、縦方向のパケットは映像データパケットN個FECパケット1個の計N1個であり、映像データパケットの1つがパケットロストにより消失しても、受信した映像データパケットとFECパケットの計N個をXOR演算することにより、消失した1個のパケットを復元することが可能である。2個以上消失していた場合は消失した全パケットとも復元不可能である。図5のようにパケットロストが5つ図中の×印起こっていた場合、もし横方向のFECパケットしか提供しないFEC方法であったとすると、復元できるのはMN-11で示すパケット一つだけである。また、縦方向のFECパケットのみ提供する方法であった場合、パケットMは復元できるが他のパケットは復元不可能である。しかし、縦横両方のFECパケットを提供する方法であれば、図5に番号で示す通りの順番で全てのパケットを復元することが可能である。尚、図5に示す順番は一例である。ネットワークによるコンテンツ配信において、受信できるコンテンツの品質は利用する通信回線や受信機の性能により制限される。映像コンテンツは配信サーバによりネットワーク上にデータパケットとして送出され、ルータやスイッチ等の機器を経由して受信機まで届き、受信機内に取り込まれる。その際の1秒当たりのデータ転送容量はビットレートと呼ばれ、各々のコンテンツに固有の値である。この値が大きいほど映像の解像度や滑らかさ等の品質が高くなるが、表示のためのデータ受信に必要な利用帯域は大きくなる。利用者の利用しているネットワークや受信機の利用可能な帯域が、受信しているコンテンツのビットレートの合計よりも大きければ、問題なくコンテンツの受信再生が可能だが、利用可能な帯域の方が小さい場合、データが受信機まで届かなかったり、受信機内部での再生処理が間に合わなかったりすることで、パケットロストが起こって映像が乱れ、酷い場合は表示不可能になることもある。FECパケットは数を増やすほど復元率が上がるが、映像データ以外にFECパケットを受信することにより、全体としての必要帯域が大きくなり、却ってFECパケットを含めた全体のパケットロストが増してしまう問題がある。この問題について、図6のFEC復元方法とFECパケット数を示す表に基づき説明する。図6のようにFEC復元方法が6つ用意されていた場合、例えばFEC復元方法Aでは、映像データパケット10個毎に縦方向FECパケット1個を受け取るようにしており、縦方向のコンテンツパケット10個に対して最大1個復元可能である。映像データ100個に対して10個のFECパケットを受け取るため、受信帯域としては10増しとなる。一方、FEC復元方法BからFにおいては、上述したとおりコンテンツパケットを復元できる可能性は大きくなるが、必要とする受信帯域は増加する。例えばFEC復元方法DやEの場合は、映像データ100個に対して25個のFECパケットを受け取るため、受信帯域が25増となる。この場合、元々は例えば16Mbpsの映像データのストリームを17Mbpsの許容帯域を持つローカルネットワークで受信して、ごく稀にバースト等でパケット落ちする程度であったとしても、FEC復元方法DやEを採用したがゆえに25増しの20Mbpsの帯域が必要になる。これでは許容帯域の17Mbpsを上回る帯域が必要となり、却って常時パケットロストが起こる可能性がある。そのため、使用しているローカルネットワークに最適な方法を取捨選択する仕組みが必要である。図1では、ネットワーク1を介して情報通信サーバ2から映像データが格納されているデータパケットA、横方向FECパケットA1と縦方向FECパケットA2が配信されている。本例の場合、データパケットA、縦方向のFECパケットA1、横方向A2のFECパケットを各々別のポートに送信するため、操作端末3はそれぞれのポートでパケットを受信する必要がある。FECを使用しない場合は、データパケットAのみを受信すればよい。操作端末3は、通常の場合は、情報通信サーバ2から映像データを含むデータパケットAを常時受信し、再生している。次に、本実施形態に係る映像通信システムの動作について説明する。図7は、本実施形態に係る映像通信システムの動作を示すシーケンス図である。例えば、ユーザが操作端末3を操作することにより、操作端末3が情報通信サーバ2から情報を受信して動作する場合、即ち、情報通信サーバ2との間で情報をやり取りする応答が必要な場合、情報通信サーバ2においては、使用者に待たせることが無いように、情報の送信を開始するまでの遅延を短くする必要がある。他方、使用者からの操作に対応する必要のない状態、例えば動画が表示されている状態においては特に遅延は問題にならない。そのため本実施形態に係る情報通信サーバ2は、動画の映像データ送信時のみFECを利用する。即ち、情報通信サーバ2においては、誤り訂正処理部115が、動画の映像データ送信時のみFECパケットを生成する。このようにすることで使用者へ遅延を意識させることなく情報を配信することが可能となる。また、本実施形態においては、操作端末3側において、動的にFEC方式を選択する。これにより、動画の品質を保障することが可能になる。図7に示すように、まず、操作端末3が、ユーザの操作に応じて情報通信サーバ2とネットワークを介して接続し、情報通信サーバ2から情報を取得することにより、メニュー画面のような比較的静的な画面を表示するS701。S701の処理においても、図2に示す送信装置5が上述したように機能し、メニュー画面を表示するための低ビットレートの映像データパケットを送信している。メニュー画面の映像データパケットとして、動画よりも低ビットレートの映像データパケットが送信される場合とは、情報通信サーバ2が動的ビットレートに対応しているエンコード方式を採用している場合である。また、メニュー画面のようなユーザインタフェースとなる画面はユーザの操作への早い応答が求めらるため、低遅延である必要がある。そのため、メニュー画面の映像データパケットの送信に際して、誤り訂正処理部115はFECパケットの生成を行わない。そのため、メニュー画面の映像データパケットを送信する場合、ヘッダ処理部112は、生成された映像データパケットを順次ヘッダ処理して送信する。ユーザが操作端末3を操作し、上記メニュー画面のような静的な画面と比較して、高ビットレートな動画を再生する機能を選択するとS702、操作端末3はユーザによる操作に応じた操作情報をCPUブレード6に送信するS703。CPUブレード6は、操作の内容を解析して操作端末3に配信する動画を判断しS704、送信装置5の制御部100に対して再生準備の命令を送るS705。送信装置5は、上記メニュー画面用の映像データのパケット化処理部111への入力を停止し、メモリ102にあらかじめ蓄積してあった動画再生待ち画面のエンコード済みデータをパケット化処理部111へ送る。動画再生待ち画面のエンコード済みデータがパケット化処理部111に入力されることにより、動画再生待ち画面の映像データパケットがヘッダ処理部112を経て操作端末3に送信され、操作端末3には動画再生待ちの画面が表示されるS706。次にCPUブレード6は、操作端末3に対して、FEC受信準備通知を送るS707。これにより、操作端末3においては、FECデータパケットを受信するためのソケットを開いてFEC受信の準備を始める。そしてCPUブレード6と送信装置5との間で、FEC付きの動画映像データを準備するS708。この際、動画映像データのソースはCPUブレード6が生成した画面データに限らず、コンテンツストレージ7から取得したものでもかまわない。処理詳細については後述する。FEC付きの動画映像データの準備ができると、再生待ち画面に代わって、FEC付きの動画映像データを操作端末3へ送る。これにより、情報通信サーバ2及び操作端末3夫々において、FEC付き動画コンテンツの再生処理が実行されるS709。なお、S709においては、操作端末3が最適なFEC方式を判断する処理や、情報通信サーバ2が、送信するFECパケットを取捨選択する処理が含まれる。これについては後に詳述する。その後、ユーザが動画再生の停止操作を操作端末3上で行うとS710、上記と同様に操作情報がCPUブレード6へ通知されるS711。CPUブレード6では、映像の再生処理を停止してS712、送信装置5に対しても再生停止命令を送るS713。操作端末3に対してはFEC送信を終了する通知を送るS714。これを受けて操作端末3ではFECパケットの受信を停止する。次に送信装置5では、再生停止命令受けたタイミングから一番近い時間の映像データの区切れGroupofPictureがパケット化処理部111に到達した時点で、ヘッダ処理部112が処理を停止して最後に送信したパケットのシーケンス番号を記憶する。また、制御部100は、映像処理部107、音声処理部109に入力するソースデータを、CPUブレード6が生成した静的画面のデータに切り替えるS715。同時に、誤り訂正処理部115へのデータ送信は停止し、動画映像データに関するメモリ102上のバッファを破棄するS716。その後、CPUブレード6が生成した画面は、エンコーダを経由してパケット処理部111によるパケット化処理及びヘッダ処理部112によるヘッダ処理を経て、操作端末3へ送信されるS717。この際、ヘッダ処理部112は、記録していたパケットのシーケンス番号を利用して、シーケンス番号が不連続にならないようにする。これにより、情報通信サーバ2から送られてくる映像データのパケットはシーケンス番号が連続した一つのストリームの状態を保つので、操作端末3では特にタイミング調整を行う必要はない。次に図8のフローチャートを用いて、FEC付き動画映像データ準備とその表示S708、S709の詳細について説明する。図8に示すように、まず、制御部100は、操作端末3から送信されたユーザの操作情報に基づき、CPUブレード6が生成した画面もしくは、コンテンツストレージ7に蓄積されたコンテンツのソースデータを映像処理部107及び音声処理部109へ夫々入力することにより、動画コンテンツの再生を開始するS801。この時点で、パケット化処理部111には、操作端末3に再生待ち画面を表示させるための再生待ち画面の映像ソースが入力されている。制御部100は、パケット化処理部111への入力をステップS801でエンコーダーに入力された映像ソースに切り替えて、パケット化の処理を開始するステップS802。このときすでにS706で再生待ち画面がヘッダ処理部112を経由してネットワーク1に送信中である。そのため、パケット化処理部111は、生成した映像データパケットをメモリ102上のバッファに一度格納するステップS803。メモリ102上のバッファに映像データパケットが格納されると、制御部100は、誤り訂正処理部115を制御し、FECパケットの生成処理を開始するステップS804。このときFECパケットは図6に示すような複数種類のFEC方式に対応したFECパケットを夫々生成する。そのため、FECパケットの生成を開始すると、制御部100は、FECパケットの生成処理に必要な映像データパケットがバッファに蓄積されるまで待機し、図5のように縦、横夫々について、図6のように複数種類のFEC方式に対応するFECパケットが生成可能となる度にFECパケットを生成していくS805/NO。S804、S805において蓄積する映像データパケット数の基準は生成するFECの種類のうち、もっともFEC生成に必要な映像データパケット数が多いものに合わせる。例えば、図6の例の場合、制御部100は、FEC復元方式FによるFECパケットを生成可能な映像データパケット、即ち、横25×縦4のマトリクス状に配置される100個の映像データパケットがバッファに蓄積され、誤り訂正処理部115が、図6に示す複数のFEC方式夫々によるFECパケットを全て生成するまで待機する。そして、図6に示すような複数のFEC方式について、もっともFEC生成に必要な映像データパケット数が多いものに合わせてのFECパケットの生成が完了するとS805/YES、制御部100は、パケット化処理部111によって処理中の再生待ち画面の映像データの切れ目を検知して画面の切り替えが可能かを判断し、切れ目に至るまで待機するS806/NO。S806において、制御部100は、例えば、映像データのGOPGroupofPicureを切り替えのポイントとする。画面切り替えが可能なポイントに達するとS806/YES、制御部100は、パケット化処理部111を制御し、その時点で未送信のパケット化処理済みのパケットを全て送信したのち、再生待ち画面の映像ソースのパケット化処理を停止するS807。そして、ヘッダ処理部112に入力して操作端末2に送信させるデータパケットを、誤り訂正処理部115を経由した再生対象の動画の映像データパケット及びその映像データパケットに基づいて生成されたFECパケットに切り替えるS808。その後、制御部100の制御に従い、パケット化処理部111によって上述したようにパケット化された映像データパケット及び誤り訂正処理部115によって生成されたFECパケットがヘッダ処理部112へ送られ、ヘッダ処理を施されたパケットが操作端末3へ送られるS809。ここで、S809においては、生成されたFECパケットが全てヘッダ処理部112に入力されるのではなく、操作端末3によって選択されたFEC復元方式に係るFECパケットのみがヘッダ処理部112に入力され、ヘッダ処理されてネットワーク上に創出される。これにより、操作端末3が含まれるユーザ側のローカルエリアネットワークにおいては、余計なFECパケットをやり取りする必要がなくなり、ローカルエリアネットワークのネットワーク負荷を低減することができる。これについては後に詳述する。ここで、S809における映像データパケット及びFECパケットの送信態様及び作用効果について、図9を参照して説明する。上述したように、S809においてヘッダ処理部112が映像データパケット及びFECデータパケットの送信を開始するタイミングにおいては、図6に示すような複数のFEC方式について、もっともFEC生成に必要な映像データパケット数が多いものに合わせてのFECパケットの生成が完了している。そのため、メモリ102に確保されているバッファ領域には、相当数の映像データパケット、横方向のFECパケット以降、FECパケット1とする及び縦方向のFECパケット以降、FECパケット2とするが格納されている。即ち、図9aに示すように、映像データパケット、FECパケット1及びFECパケット2夫々のポートから送信されるパケットは既に用意されている。従って、ヘッダ処理部112が映像データパケット、FECパケット1及びFECパケット2に対して順次ヘッダ処理を行って送信することにより、操作端末3には、映像データパケット、FECパケット1及びFECパケット2が平行して到達する。そのため、パケットロストが発生したとしても、FECパケットが既に到達しているため、操作端末3はロストパケットの復元を即座に行うことができる。図9bは、図8の動作のように、相当数のFECパケットの生成が完了してから映像データパケットの送信を開始する処理を行わず、生成されたパケットを順次送信すると共に、映像データパケットが順次生成されることにより生成が可能となったFECパケットを生成して、それも順次送信する場合の例を示す図である。図9bにおいては、5個のパケット毎に横方向のFECパケットが生成される場合を例としている。図9bの場合、図に示すパケットが欠損した場合、そのパケットを復元するためには、最初のFECパケット1の到達を待つ必要がある。そのため、図9bに示す待ち時間の間、動画の再生が停止してしまう。図9bのような横方向のFECパケットをを待つ場合の待ち時間であれば、許容範囲にもなり得るが、縦方向のFECパケットを待つ場合、その待ち時間は更に長くなり、動画再生の品質が損なわれることとなる。これに対して、本実施形態に係る情報通信サーバ2は、図4のマトリクス状の配置のような予め定められた所定数の映像データパケットのまとまり毎に、複数の異なるFEC復元方式すべてについてFECパケットが生成される度に、映像データパケット及びFECパケットの送信を開始するため、図9aに示すように、映像データパケット、FECパケット1及びFECパケット2を並列して送信開始する。パケットロストが発生したとしても、操作端末3は、FECパケットの到達を待つ必要がなく、動画再生の品質を保つことができる。なお、図9aに示す態様においても、操作端末3へのパケットの到達タイミングとロストパケットの発生態様によっては、パケットの復元のためにFECパケットの到達を待つ必要が生じる可能性もある。これに対して、ヘッダ処理部112が、FECパケット1、FECパケット2を映像データパケットよりも優先して送信することにより、そのような可能性を排除することができる。更には、図4のマトリクス状の配置のような予め定められた所定数の映像データパケットのまとまり毎にパケットの送信を開始する際、先にFECパケットを全て送信した後に映像データパケットを送信するようにしても良い。これにより、操作端末3において映像データパケットが受信された映像データの再生が開始された際には、既にFECパケットは全て揃っており、復元のためにFECパケットの到達を待つ必要がない。次に、操作端末3の動作について説明する。図10は、操作端末3において、情報通信サーバ2から映像データを受信再生する際、最適なFEC復元方法を適用して映像データのストリームを受信する処理を行うIPデータ処理部27における、データ修正処理の制御プログラムのフローチャートである。まず、操作端末3は、ユーザがタッチパネル17で、情報通信サーバ2から映像データを受信再生するための所定操作を行うことにより、映像データの受信処理を開始するS1000。すると、操作端末3は、情報通信サーバ2のCPUブレード6に対して、映像データ送信開始を依頼する。これにより、情報通信サーバ2において、映像データの送信処理が始まる。これにより、図7のS706のような再生待ち画面表示処理等が実行され、操作端末3において再生待ち画面が表示される。次に、IPデータ処理部27は、CPUブレード6に対して通信を行うことで、提供されるFECの方法とパラメータ、及びFECパケットのソースIPアドレスと配信ポート番号を得るS1001。この例では、図6に示したFEC復元方法A~Fの6種類の復元方法が選択的に利用できることを示す情報が、情報通信サーバ2から送信される。そして、IPデータ処理部27は、映像データの受信のための手続きに進む。最初に受信開始する際、IPデータ処理部27は、まずFECによるロストパケットを復元せずに受信処理を開始する。そして、パケットロストの発生状況を監視しながら、帯域増加の少ない順にFEC復元方法を順次試して、最適な方法を選ぶ。なお、本実施形態において、IPデータ処理部27は、サービスの種類や映像データのストリームのビットレート別に最適として利用したFEC復元方法の記録を蓄積し、次回同じサービスを利用する場合には、前回最も適していたと判定した方法を使用して映像データ受信を行うS1002。次いで、IPデータ処理部27は、新規データパケットをIP通信ポート26から装置内に取り込むためのソケットを準備し、映像データのパケットが到着し始めるのを待つ。このとき、操作端末3が情報通信サーバ2とネットワークセッションを確立して映像データの再生を開始した直後であるため、上述した通り、FECによるロストパケットの復元処理を実行しない。そして、映像データのパケットがIP通信ポート26まで届き始めたら、これを取り込んでIPデータ処理部27でIPパケットの形態からTS形式のデータに変換してデコーダ14に送る。この処理により、ユーザ指定の映像データの再生表示が行われるS1003。即ち、IPデータ処理部27が、パケット受信部として機能する。映像データの再生を開始すると、IPデータ処理部27は、IP通信ポート26でパケットを取り込む際に、映像データのパケットのロスト数をカウントしパケットロスト率を計算する。即ち、IPデータ処理部27が、エラー率計算部として機能する。そして、パケットロスト率が、所定の許容される率の閾値を超えているか否かを判定しS1005、超えている場合にはS1005/YES、FECによるデータ復元を開始、又はそれまで使っていたFEC復元方法の変更を行う。ここで、S1005における閾値について説明する。上述したパケットロスト率の閾値は、動画の再生品質のポリシによって予め設定される。もっとも保守的なポリシとしては、閾値を0パケットとして、パケットロストが1つでも発生したらFECを適用する態様がある。このようなポリシは、主にローカルエリアネットワークの回線品質が高い場合に適用する。一般的なローカルエリアネットワーク回線で、パケットロストが比較的多く発生する場合は、パケットロスト率の閾値を0パケットよりも高くする。このときの設定方法としては、パケットロスト率が映像の乱れにどの程度影響するか、予め目視により確認することにより許容可能な品質に対応するパケットロスト率を設定する。例えば、動画データには、敵的にデコードにとって重要な主フレームが挿入されている。その主フレームに対応する動画データについて頻繁にパケットロストが発生すると、画面が大きく崩れてしまう。従って、主フレームに対応するパケットがロストしないように閾値を設定することが好ましい。また、設定する閾値の上限としては、FECによって完全復元できるパケットロストの状態を想定して設定することが考えられる。図6の表によれば、もっとも復元率が低いFEC復元方式Aが復元可能なパケットロスト率の上限、即ち、10未満が閾値である必要がある。これは100パケットのうち横方向に10パケットが連続でロストした場合に相当する。IPデータ処理部27は、FEC復元方法の変更を行う場合、まず、それまでFECによる復元を行っていた場合には、そのFEC復元方法とパケットロスト率を一時記録するS1006。そして、前記ステップS1001で取得したFEC復元方法から、今まで使用していた方法に比べ最も帯域増加の少ない方法、即ち、現在選択されているエラー訂正方式の次にネットワーク負荷が高い方式を選択し適用する。S1007における、変更後のFEC復元方法を選択して適用する処理は、IPデータ処理部27がネットワークを介して情報通信サーバ2に変更後のFEC復元方法を通知する処理である。即ち、IPデータ処理部27が、方式変更通知部として機能する。これにより、情報通信サーバ2においては、制御部100が、通知されたFEC復元方法に基づいてヘッダ処理部112に入力するFECパケットを選択する。その結果、操作端末3によって選択されたFEC復元方法に応じたFECパケットが操作端末3に送信されることとなる。ここで、FEC復元パケットの選択ルールについて説明する。例えば、それまでFECによる復元をせずに映像データ受信していた場合、図6の6つの方法で最も帯域増加の少ないものは映像データの100個のパケットに対し10個のFECパケットを受け取る方法Aであるため、まずFEC復元方法Aを適用する。また、一般的にパケットロストは連続して起こることが多いため、本実施形態に係るIPデータ処理部27は、同じ帯域増加率であれば、Mの大きい方、すなわち縦方向のFECパケットの多い方を優先して採用する。例えば、FEC復元方法BとCではCを、FEC復元方法DとEではEを先に適用する。今まで受信していなかったFECパケットを新規に受信する手続きは、映像データパケット受信と同様、FECパケットをIP通信ポート26から装置内に取り込むためのソケットを準備し、FECパケットデータが到着し始めたら、該FECパケットを使って図4、図5において説明した方法でロストした映像データパケットの復元を開始するS1008。即ち、IPデータ処理部27が、パケット復元部として機能する。FECによるデータ復元を行っている場合、IPデータ処理部27は、データ復元後のパケットロスト率を計算するS1009。すなわち、受信時にロストしていたパケット数から、復元できたパケット数を引いた値の統計をとり、S1006で記録しておいた以前の方法のロスト率と比較しS1010、前よりもパケットロスト率が増加するようであればS1010/YES、ステップS1011に進んでFEC復元方法を以前のものに戻す。そして、IPデータ処理部27は、受信中の映像データについての最適なFEC復元方法として、選択中のFEC復元方法をFEC適用方法データベースに、サービス及び映像データのストリームのビットレートと共に記録するS1013。ステップS1010での比較結果が、以前より向上していた場合S1010/NO、IPデータ処理部27は、まだ試していないFEC復元方法があるかを判定するS1012。これは、現在の方法以上に復元率の大きい方法が有る可能性を判定することに相当する。復元率がさらに大きい方法が無い場合はS1012/YES、その方法を最適方法とし、S1013の処理を行う。まだ試していないFEC復元方法がある場合S1012/NO、IPデータ処理部27は、ステップS1005に戻る。そして、現在適用している方法のパケットロスト率がしきい値の範囲であればS1005/NO、ステップS1013に進み、IPデータ処理部27は、該方法を最適方法として記録する。閾値外であればS1005/YES、IPデータ処理部27は、ステップS1006からS1010を繰り返す。最適方法が定まると、IPデータ処理部27は、ユーザが情報通信サーバ2との接続を停止する操作を行うまでS1014、該方法を適用して映像データ受信処理を行うS1014/NO。接続を停止する場合S1014/YES、IPデータ処理部27は、データの復元とデコーダへの転送を中止し、CPUブレード6に接続停止通知を送信し、受信用のソケットを削除する処理を行うS1015。なお、提供されている全てのFEC復元方法を使用しても、ステップS1005において、パケットロスト率が前記しきい値を超える場合、IPデータ処理部27は、最もパケットロスト率の少ないFEC復元方法を選択して処理する。この場合は受信状況が良好でないため、画像や音声が乱れる恐れがある旨を表示装置22に表示しても良い。これにより、ユーザは、受信中の映像データに低解像度のものや低ビットレートのものがある場合には、それらを選択するという判断を行うことができる。本実施例においては、通常RTPでデータ送信する情報通信サーバ2は、FEC復元方法を複数用意しているので、操作端末3は、提供されたFEC復元方法を取捨選択し、常時最適な映像データ受信が行えるように調整することを特徴としている。以上のようにすることで、映像データをネットワークを介して受信して表示する場合に、ユーザのネットワークにおいて最適なFEC復元方法を合理的に採用して受信することができる。また、上述したように、本実施形態に係る情報通信サーバ2は、映像表示までの遅延が少ないことが求められる静的な画面から生成される映像の場合ではFECを用いないことで、遅延を減らし、かつビットレートが高くなるような動画映像では品質を保つために、動画再生の先頭に再生待ち画面を挿入して再生を待たせつつ複数の方式に対応したFECパケットを生成することで、複数の方式から成るFECを利用することが可能であり、ユーザによる操作に対する応答性能を向上すると共に、最適なFEC方法を選択させることができる。ここで、上述したように、本実施形態に係る映像通信システムにおいて、情報通信サーバ2は、複数の異なるFEC復元方法に対応したFECパケットを生成した上で、操作端末3により選択されたFEC復元方法に対応するFECパケットのみを選択して送出する。そして、上述したように、操作端末3は、映像データの再生開始当初は、FECによるロストパケットの復元を行わない。従って、情報通信サーバ2は、映像データの配信開始当初は、FECパケットを送出しない。これは、操作端末3が情報通信サーバ2に映像データの配信要求を行う度に、最初はFECパケットが不要であること、即ち、FEC復元方法をいずれも選択しないことを通知しても良いし、情報通信サーバ2において制御部100が、毎回の映像データの配信開始当初においては、FECパケットが不要であることを予め判断して、映像データパケットのみをヘッダ処理部112に入力するようにしても良い。また、情報通信サーバ2において、操作端末3からFEC復元方法を変更する通知を受信した場合、FEC復元方法を変更するタイミングが問題となる。これについては、図4において説明したような、マトリクス状に配置された映像データパケットのまとまりを利用することが好ましい。上述したように、本実施形態において、情報通信サーバ2は、もっともFEC生成に必要な映像データパケット数が多いものに合わせてFECパケットを生成する。即ち、図6の例の場合、情報通信サーバ2は、映像データパケット100個毎にA~FすべてのFEC復元方法によるFECパケットの生成する処理を繰り返す。そして、FECパケットは図4に示すようにマトリクス状に配置された映像データパケットに対して適用して初めて意味があり、マトリクス状に配置された映像データパケットの途中でFEC方式を変更しても意味がない。従って、情報通信サーバ2が、操作端末3からの通知に応じてFEC復元方式を変更する、即ち、ヘッダ処理部112に入力するFECパケットの取捨選択を変更するタイミングは、図4に示すようなマトリクス状に配置された映像データパケットのまとまり毎のタイミングとすることが好ましい。尚、異なるFEC復元方式の全てについてFECパケットを生成するということが可能となるのは、図6に示すように、本実施形態において適用されるFEC復元方式が、マトリクス状にまとめられるパケットデータの数として、100個という同一の数を採用しているからである。そして、これにより、上述したように、FECパケットの取捨選択を変更するタイミング、即ち、FEC復元方式を変更するタイミングとして、マトリクス状に配置された映像データパケットのまとまり毎のタイミングを容易に用いることができる。従って、情報通信サーバ2において選択可能な複数のFEC復元方式は、マトリクス状にまとめられるパケットデータの数として、いずれも同一数を採用することが好ましい。他方、操作端末3においては、FEC復元方式の変更を通知した後、情報通信サーバ2から送信されるFECパケットが通知した復元方式に変更されたタイミングを判断する必要がある。これは、上述したように、FECパケットのヘッダ情報において復元対象の映像データパケットが指定されているため、IPデータ処理部27は、その情報を参照することにより判断することが可能である。この他、より容易にFEC復元方式の変更を判断する方法として、情報通信サーバ2が、FEC復元方式を変更するタイミング、即ち、ヘッダ処理部112に入力するFECパケットを変更するタイミングにおいて、FEC復元方式が変更されることを示す情報を挿入する態様が考えられる。FEC復元方式が変更されることを示す情報を挿入する態様としては、映像データもFECデータも含まない空のパケットデータを所定数連続して送出する態様や、FEC復元方式が変更された後、最初に送出されるパケットのヘッダ情報として、FEC復元方式が変更されたことや変更後のFEC復元方式を示す情報を挿入する態様が考えられる。これにより、操作端末3においては、連続して受信された空パケットや受信されたパケットのヘッダ情報を確認することにより、容易にFEC復元方式が変更されたことを判断することができる。以上、本発明について詳細に説明したが、本発明は、ここに記載された映像通信システムの実施例に限定されるものではなく、他の映像通信システムにも広く適用できることは言うまでもない。