Data processing device, data processing method and data processing program

本発明は、ネットワークを介して受信されたデータを処理するデータ処理装置、データ処理方法、およびデータ処理プログラムに関する。

従来、複数の装置の間で各種データを送受信する技術が知られている。 例えば、映像データを送受信する場合、送信側の装置（以下、「送信装置」という。）は、撮影手段から取得した映像データを順に符号化してパケット化し、受信側の装置（以下、「受信装置」という。）に送信する。 受信装置は、ネットワークを介してパケットを受信し、受信したパケットに含まれる符号化データを復号部に出力する。

ネットワークの輻輳による遅延、経路変更等の影響で、送信時と受信時のパケットの順序が入れ替わる場合がある。 パケットロスが生じる場合もある。 受信装置は、パケットの受信順の入れ替わりまたはパケットロスが生じた場合でも、適切にデータを処理できることが望ましい。 特許文献１が開示している受信装置は、受信したパケットをバッファに格納する。 受信装置は、受信したパケットに付されているシーケンス番号の順序に入れ替わりが生じると、タイマを起動する。 タイムアウトする前に、受信順が遅れたパケットの受信を完了すると、バッファに格納したパケットをシーケンス番号順に出力する。 一方、受信装置は、受信順が遅れたパケットを受信せずにタイムアウトとなると、その時点でバッファに格納されているパケットのみをシーケンス番号順に出力する。

パケットの再送処理を行わずに、パケットの送受信の不具合を解消する方法として、前方誤り訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ、以下「ＦＥＣ」という）がある。 ＦＥＣでは、送信装置はパケット内のデータに冗長性を付与する。 その結果、受信装置は、パケットの送信、破壊等によって受信に失敗したデータを冗長データから復元することができる。 よって、パケットを再送する場合に比べて、送信から受信完了までの時間差を短縮することができる。 そのため、ストリーミング放送等、パケットの再送を行いにくい状況で利用されている。

ＦＥＣを適用してデータを送受信する場合、受信装置は、復元単位となる一群のパケット（例えば、１つのフレームのパケット群、１つのスライスのパケット群等。以下、「復元グループ」という。）に属する全てのパケットを受信していなくても、一定量以上のパケットを受信していれば、復元グループに含まれるデータを復元できる。 つまり、受信装置は、仮にパケットの受信順に入れ替わりが生じた場合でも、１つの復元グループに属する複数のパケットを順調に一定量以上受信できれば、復元グループに含まれるデータを円滑に復元できる。 しかし、特許文献１に記載の方法では、１つの復元グループに属する複数のパケットが順調に受信された場合でも、受信順が入れ替わっていれば、受信順が遅れてタイムアウトとなったパケットは出力されない。 その結果、必要以上にパケットが破棄されてしまい、データを正確に復号できない場合が生じる。 従って、従来の受信装置は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することはできなかった。

本発明は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することができるデータ処理装置、データ処理方法、およびデータ処理プログラムを提供することを目的とする。

本発明の第一態様に係るデータ処理装置は、各々が一群のパケットからなり損失パケットを復元する単位となる複数の復元グループのうち、いずれの復元グループに属するかを示すグループ識別情報と、ＦＥＣ（前方誤り訂正）によって符号化されたデータとを含むパケットを、ネットワークを介して受信する受信手段と、前記受信手段によって一のパケットが受信されてから、前記一のパケットに含まれるグループ識別情報が示す復元グループと同じ復元グループに属する他のパケットを受信せずに経過した未受信時間を計測する計測手段と、前記計測手段によって計測された前記未受信時間が待機時間以上であるか否かを判断する経過判断手段と、前記経過判断手段によって前記未受信時間が前記待機時間以上であると判断された場合に、前記受信手段によって受信されたパケットのうち、前記未受信時間が前記待機時間以上となった復元グループに属するパケットのＦＥＣ復号を回避する回避手段とを備えている。

第一態様に係るデータ処理装置は、同じ復元グループに属するパケット同士の受信間隔を計測することで、復元グループ毎にタイムアウトを判断する。 従って、同じ復元グループに属するパケットの受信間隔が待機時間内であれば、受信順が入れ替わった場合でも、受信順が遅れたパケットが破棄されることも、復号されずにそのまま放置されることもない。 一方、同じ復元グループに属するパケットの受信間隔が待機時間以上となれば、その復元グループに含まれるデータのＦＥＣ復号は回避され、他の処理が迅速に行われる。 従って、データ処理装置は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することができる。

前記データ処理装置は、前記受信手段によってパケットが受信され、且つ前記経過判断手段によって前記未受信時間が前記待機時間以上でないと判断された場合に、受信されたパケットが属する復元グループにおいて受信が完了したデータのデータ量が、損失パケットを復元可能な一定量以上であるか否かを判断するデータ量判断手段と、前記データ量判断手段によってデータ量が一定量以上であると判断された時点で、前記受信されたパケットが属する復元グループのデータに対してＦＥＣ復号を行う復号手段とをさらに備えてもよい。

この場合、データ処理装置は、損失パケットを復元可能な一定量以上のデータを受信した時点で、復元グループに属する全てのパケットを受信したか否かに関わらず、ＦＥＣ復号を行うことができる。 従って、データ処理装置は、処理を迅速に行うことができ、データ処理の効率をさらに高めることができる。 パケットロス等が生じた場合には、一定量以上のデータを受信するまで待機することで、損失パケットを復元することができる。

前記データ処理装置は、前記受信手段によって受信されたパケットに含まれるデータにおけるフレーム種別およびフレームレートの少なくともいずれかの情報を取得する情報取得手段と、前記情報取得手段によって取得された情報に従って、前記経過判断手段によって判断される前記待機時間を設定する第一設定手段とをさらに備えてもよい。 この場合、データ処理装置は、フレーム種別およびフレームレートの少なくともいずれかに応じて、受信を待機する待機時間を適切な長さに設定することができる。 従って、データ処理装置は、さらに効率よく処理を行うことができる。

前記データ処理装置は、パケットが送信されてから前記受信手段によって受信されるまでに要する時間のゆらぎを取得するゆらぎ取得手段と、前記ゆらぎ取得手段によって取得されたゆらぎに応じて、前記経過判断手段によって判断される前記待機時間を設定する第二設定手段とをさらに備えてもよい。 この場合、データ処理装置は、パケットの送信に要する時間のゆらぎに応じて、受信を待機する待機時間を適切な長さに設定することができる。 従って、データ処理装置は、さらに効率よく処理を行うことができる。

本発明の第二態様に係るデータ処理方法は、ネットワークを介して受信されたデータを処理するデータ処理装置によって実行されるデータ処理方法であって、各々が一群のパケットからなり損失パケットを復元する単位となる複数の復元グループのうち、いずれの復元グループに属するかを示すグループ識別情報と、ＦＥＣ（前方誤り訂正）によって符号化されたデータとを含むパケットを、ネットワークを介して受信する受信ステップと、前記受信ステップにおいて一のパケットが受信されてから、前記一のパケットに含まれるグループ識別情報が示す復元グループと同じ復元グループに属する他のパケットを受信せずに経過した未受信時間を計測する計測ステップと、前記計測ステップにおいて計測された前記未受信時間が待機時間以上であるか否かを判断する経過判断ステップと、前記経過判断ステップにおいて前記未受信時間が前記待機時間以上であると判断された場合に、前記受信ステップにおいて受信されたパケットのうち、前記未受信時間が前記待機時間以上となった復元グループに属するパケットのＦＥＣ復号を回避する回避ステップとを含む。

第二態様に係るデータ処理方法によると、データ処理装置は、同じ復元グループに属するパケット同士の受信間隔を計測することで、復元グループ毎にタイムアウトを判断する。 従って、同じ復元グループに属するパケットの受信間隔が待機時間内であれば、受信順が入れ替わった場合でも、受信順が遅れたパケットが破棄されることも、復号されずにそのまま放置されることもない。 一方、同じ復元グループに属するパケットの受信間隔が待機時間以上となれば、その復元グループに含まれるデータのＦＥＣ復号は回避され、他の処理が迅速に行われる。 従って、データ処理装置は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することができる。

本発明の第三態様に係るデータ処理プログラムは、ネットワークを介して受信されたデータを処理するデータ処理装置で用いられるデータ処理プログラムであって、各々が一群のパケットからなり損失パケットを復元する単位となる複数の復元グループのうち、いずれの復元グループに属するかを示すグループ識別情報と、ＦＥＣ（前方誤り訂正）によって符号化されたデータとを含むパケットを、ネットワークを介して受信する受信ステップと、前記受信ステップにおいて一のパケットが受信されてから、前記一のパケットに含まれるグループ識別情報が示す復元グループと同じ復元グループに属する他のパケットを受信せずに経過した未受信時間を計測する計測ステップと、前記計測ステップにおいて計測された前記未受信時間が待機時間以上であるか否かを判断する経過判断ステップと、前記経過判断ステップにおいて前記未受信時間が前記待機時間以上であると判断された場合に、前記受信ステップにおいて受信されたパケットのうち、前記未受信時間が前記待機時間以上となった復元グループに属するパケットのＦＥＣ復号を回避する回避ステップとを前記データ処理装置のコントローラに実行させるための指示を含む。

第三態様に係るデータ処理プログラムによると、データ処理装置は、同じ復元グループに属するパケット同士の受信間隔を計測することで、復元グループ毎にタイムアウトを判断する。 従って、同じ復元グループに属するパケットの受信間隔が待機時間内であれば、受信順が入れ替わった場合でも、受信順が遅れたパケットが破棄されることも、復号されずにそのまま放置されることもない。 一方、同じ復元グループに属するパケットの受信間隔が待機時間以上となれば、その復元グループに含まれるデータのＦＥＣ復号は回避され、他の処理が迅速に行われる。 従って、データ処理装置は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することができる。

通信システム１００のシステム構成を示す図である。

ＰＣ１の電気的構成を示すブロック図である。

ＰＣ１が実行する送信処理のフローチャートである。

送信処理によって送信されるパケットのデータ構成の概略を説明するための説明図である。

ＰＣ１が実行する受信処理のフローチャートである。

受信処理中に実行されるパケット振り分け処理のフローチャートである。

受信処理中に実行されるタイムアウト判定処理のフローチャートである。

タイムアウト判定処理中に実行される待機時間設定処理のフローチャートである。

シーケンス番号に従ってタイムアウト判定を行う場合の処理結果を説明するための説明図である。

本実施形態のＰＣ１による処理結果を説明するための説明図である。

変形例１における待機時間設定処理のフローチャートである。

変形例２における待機時間設定処理のフローチャートである。

以下、本発明のデータ処理装置を具現化した一実施形態であるパーソナルコンピュータ（以下、「ＰＣ」という。）１について、図面を参照して説明する。 参照する図面は、本発明が採用し得る技術的特徴を説明するために用いられるものである。 図面に記載されている装置の構成、各種処理のフローチャート等は、それのみに限定する趣旨ではなく、単なる説明例である。

図１を参照して、ＰＣ１を備えた通信システム１００のシステム構成について説明する。 通信システム１００は、複数のＰＣ１を備える。 以下では、説明を簡略化するために、２つのＰＣ１を備えた通信システム１００を例示して説明を行う。 しかし、通信システム１００が備えるＰＣ１の数は２つに限られず、３つ以上であってもよい。 各ＰＣ１は、インターネット等のネットワーク８を介して、他のＰＣ１との間でデータを送受信する。 通信システム１００は、サーバ（図示外）等を経てデータが送受信されるサーバ型の通信システムでもよいし、各ＰＣ１の間でデータが直接送受信されるＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）型の通信システムでもよい。

本発明におけるデータ処理装置として用いることができるのは、ＰＣ１に限られない。 例えば、テレビ会議を実行するために各拠点に配置される専用のテレビ会議端末等を、本発明におけるデータ処理装置として用いることも可能である。 データ処理装置は、ネットワーク８を介してデータを受信し、受信したデータを処理できる装置であればよい。

本実施形態で例示する通信システム１００は、音声および映像を用いた遠隔会議を実行するためのテレビ会議システムである。 各ＰＣ１は、自拠点のマイク３１（図２参照）によって入力した音声のデータ、およびカメラ３３によって入力した映像のデータを、通信システム１００内の他のＰＣ１に送信する。 各ＰＣ１は、他のＰＣ１の各々から受信したデータに基づいて、他の拠点の音声をスピーカ３２（図２参照）から出力し、且つ他の拠点の映像を表示装置３４に表示させる。 その結果、複数の拠点の音声および映像が、通信システム１００内で共有される。 さらに、各ＰＣ１は、会議中に閲覧する資料（文書、図面、写真等）のデータ、表示されている画面内の位置を指し示すためのポインタのデータ等を、音声および映像のデータと共に相互に送受信することができる。 よって、通信システム１００によると、全てのユーザが同一の拠点にいない場合でも、ユーザは円滑に会議を実行することができる。

通信システム１００におけるデータの送受信方法の概要について説明する。 通信システム１００内の各ＰＣ１は、音声、映像、資料、ポインタ等の各データをパケット化して送受信する。 以下では、ＰＣ１が映像のデータをパケット化して送受信する場合を例示して説明を行う。 データを送信するＰＣ１（以下、「送信装置」という。）は、自拠点のカメラ３３から映像のデータをフレーム単位で取得する。 取得した映像のデータを符号化して符号化データを生成する。 生成した１フレーム分の符号化データを、１または複数のパケットに含めて送信する。

本実施形態に係る送信装置は、複数のフレームのデータに対して周知の画像圧縮符号化を行う。 画像圧縮符号化には、フレーム内符号化とフレーム間符号化とがある。 フレーム内符号化とは、カメラ３３によって入力された連続する複数フレーム分の映像データのうちの１フレーム分のデータ内で、画面内予測によって行われる符号化である。 フレーム内符号化によって生成される符号化データであるＩピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ Ｐｉｃｔｕｒｅ）は、他のフレームを参照することなく単独で復号できる。 一方、フレーム間符号化では、連続するフレームのデータのうち、符号化するフレームのデータとは異なるフレームのデータが参照されて予測誤差が計算され、計算された予測誤差が符号化される。 フレーム間符号化によって生成される符号化データには、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ Ｐｉｃｔｕｒｅ）およびＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ−ｃｏｄｅｄ Ｐｉｃｔｕｒｅ）がある。 ＰピクチャおよびＢピクチャを正確に復号するには、符号化時に参照されたフレームが必要となる。 しかし、ＰピクチャおよびＢピクチャのデータ量は、単独で復号できるＩピクチャに比べて少ない。 送信装置は、画像圧縮符号化を行うことで、映像のデータを効率よく送信することができる。

本実施形態に係る送信装置は、周知のＦＥＣ（前方誤り訂正）による符号化を行う。 ＦＥＣ符号化では、送信装置は、データの誤りを検出し復元するために用いられる冗長データを、各パケットに含める。 受信側の装置（以下、「受信装置」という。）は、復元単位に含まれるデータのうち一定量のデータ（映像の符号化データ＋冗長データ）の受信が完了すると、受信したデータを用いて、復元単位中の損失パケットを復元することができる。 従って、送信時と受信時のパケットの順序が入れ替わった場合、パケットロスが生じた場合等でも、受信装置は、損失パケットを復元して適切にデータを処理することができる。 受信装置は、パケットの再送を送信装置に要求する必要が無いため、映像等のデータをリアルタイムで再生することも可能である。 特に、本実施形態に係る受信装置は、復号に必要なパケットを無駄にすることなく、ＦＥＣ符号化によって生成・送信されたデータを処理することができるが、この詳細は後述する。 なお、ＦＥＣには、リード・ソロモン符号、ターボ符号、低密度パリティ検査（ＬＤＰＣ）符号等の種々の方式が存在するが、本発明ではいずれの方式を用いることもできる。

図２を参照して、ＰＣ１の電気的構成について説明する。 ＰＣ１は、ＰＣ１の制御を司るＣＰＵ１０を備えている。 ＣＰＵ１０には、ＲＯＭ１１、ＲＡＭ１２、ハードディスクドライブ（以下、「ＨＤＤ」という。）１３、および入出力インターフェース１９が、バス１８を介して接続されている。

ＲＯＭ１１は、ＰＣ１を動作させるためのプログラムおよび初期値等を記憶している。 ＲＡＭ１２は、受信したパケット等の各種の情報を一時的に記憶する。 ＨＤＤ１３は、制御プログラム等の各種の情報を記憶する不揮発性の記憶装置である。 具体的には、ＨＤＤ１３は、送信処理（図３参照）および受信処理（図５参照）を実行するためのデータ処理プログラムを記憶する。 ＨＤＤ１３の代わりに、ＥＥＰＲＯＭ等の他の不揮発性メモリを用いてもよい。

入出力インターフェース１９には、音声入力処理部２１、音声出力処理部２２、映像入力処理部２３、映像出力処理部２４、操作入力処理部２５、および外部通信Ｉ／Ｆ２６が接続されている。 音声入力処理部２１は、音声を入力するマイク３１からの音声データの入力を処理する。 音声出力処理部２２は、音声を出力するスピーカ３２の動作を処理する。 映像入力処理部２３は、映像を撮影するカメラ３３からの映像データの入力を処理する。 映像出力処理部２４は、映像を表示する表示装置３４の動作を処理する。 操作入力処理部２５は、キーボードおよびマウス等の操作部３５から入力されるデータを処理する。 外部通信Ｉ／Ｆ２６は、ＰＣ１をネットワーク８に接続する。

図３から図８を参照して、ＰＣ１が通信を行うために実行する処理について説明する。 ＰＣ１のＣＰＵ１０は、ＨＤＤ１３に記憶されているデータ処理プログラムに従って、以下の送信処理（図３参照）および受信処理（図５参照）を実行する。 ＣＰＵ１０は、送信処理および受信処理を並行して実行することも、いずれか一方のみを実行することも可能である。

図３を参照して、送信処理について説明する。 ＰＣ１のＣＰＵ１０は、接続しているカメラ３３（図１および図２参照）から映像フレームを１つ入力する毎に送信処理を実行する。 まず、ＣＰＵ１０は、カメラ３３から入力した映像フレームを取得する（Ｓ１）。 ＣＰＵ１０は、取得したフレームの順番を識別するためのフレーム番号を採番（選択）する（Ｓ２）。 ＣＰＵ１０は、取得したフレームに対するＦＥＣ符号化を実行する（Ｓ３）。 詳細には、Ｓ３では、取得されたフレームに対して画像圧縮符号化が行われて、Ｉピクチャ、Ｐピクチャ、およびＢピクチャのいずれかが生成される。 さらに、生成された符号化データを復元するために用いられる冗長データが生成される。

ＣＰＵ１０は、ＦＥＣ符号化によって生成した符号化データおよび冗長データのうちの一定量をパケット化する（Ｓ４）。 生成したパケットのヘッダに、Ｓ２で採番したフレーム番号を付与する（Ｓ５）。

図４に、生成されたパケットのデータ構成の一例を示す。 パケットのヘッダ部分には、フレーム番号、復元可能なデータ量の情報、およびフレーム情報等が含まれる。 復元可能なデータ量の情報とは、１つのフレームのデータのうち、損失パケットを復元する際に必要となるデータ（符号化データおよび冗長データ）のデータ量を示す情報である。 フレーム情報とは、パケットに含まれる符号化データによって構成されるフレームの情報である。 本実施形態のフレーム情報は、フレーム種別（Ｉピクチャ／Ｐピクチャ／Ｂピクチャ）を示す情報と、フレームレートを示す情報とを含む。 復元可能なデータ量の情報およびフレーム情報は、Ｓ４でパケットが生成される際に、各パケットのヘッダに付与される。 パケットのデータ部分には、映像の符号化データと、損失パケットを復元するための冗長データとが含まれる。

図３の説明に戻る。 ＣＰＵ１０は、パケットを生成すると、生成したパケットを受信装置に送信する（Ｓ６）。 ＣＰＵ１０は、ＦＥＣ符号化（Ｓ３）によって生成したデータのうち未送信のデータがあるか否かを判断する（Ｓ７）。 未送信のデータがあれば（Ｓ７：ＹＥＳ）、処理はＳ４へ戻り、１つのフレームに関するデータが複数のパケットによって送信される（Ｓ４〜Ｓ６）。 未送信のデータが無くなると（Ｓ７：ＮＯ）、送信処理は終了する。 送信処理は、次のフレームのデータがカメラ３３から入力されると再び実行される。 以上のように、送信装置は、フレーム単位でＦＥＣ符号化を行い、生成した１つのフレームのデータを、１または複数のパケットによって受信装置に送信する。 従って、受信装置は、冗長データを用いて損失パケットを復元する場合、フレーム単位で復元処理（ＦＥＣ復号）を行う。 つまり、本実施形態では、損失パケットを復元する単位となる一群のパケット（以下、「復元グループ」という。）は、同一のフレームのデータを含む一群のパケットとなる。

図５から図８を参照して、受信処理について説明する。 ＰＣ１のＣＰＵ１０は、通信システム１００内の他のＰＣ１（送信装置）からパケットを１つ受信する毎に受信処理を実行する。 まず、ＣＰＵ１０は、ネットワーク８を介してパケットを受信する（Ｓ１１）。 受信したパケットのヘッダを参照し、パケット内のデータによって構成されるフレームのフレーム番号を取得する（Ｓ１２）。

ＣＰＵ１０は、受信したパケットが復号済みのフレームのパケットであるか否かを、Ｓ１２で取得したフレーム番号を用いて判断する（Ｓ１３）。 詳細は後述するが、復号済みのフレームはＲＡＭ１２に記憶されている（Ｓ２０）。 復号済みのフレームのパケットであれば（Ｓ１３：ＹＥＳ）、ＣＰＵ１０は、受信したパケットを破棄し（Ｓ１５）、処理は終了する。

復号済みのフレームのパケットでなければ（Ｓ１３：ＮＯ）、ＣＰＵ１０は、受信したパケットがデータ破棄済みのフレームのパケットであるか否かを判断する（Ｓ１４）。 詳細は後述するが、ＣＰＵ１０は、フレームを構成するパケットを円滑に受信できず、損失パケットを復元可能な一定量のデータを所定時間内に得られなければ、そのフレームに関する受信済みのデータを全て破棄する。 その結果、ＣＰＵ１０は、次のフレームの処理を迅速に行うことができる。 既にデータが破棄されたフレームのパケットを遅れて受信した場合（Ｓ１４：ＹＥＳ）、ＣＰＵ１０は、受信したパケットを破棄し（Ｓ１５）、処理は終了する。 データ破棄済みのフレームのパケットでなければ（Ｓ１４：ＮＯ）、パケット振り分け処理（Ｓ１６）、およびタイムアウト判定処理（Ｓ１７）が行われる。

図６を参照して、パケット振り分け処理について説明する。 パケット振り分け処理では、フレーム毎にデータプールが作成され、受信されたパケットがそれぞれのデータプールに記憶される。 まず、ＣＰＵ１０は、受信したパケットが属するフレームのデータプールが既に作成されているか否かを判断する（Ｓ２１）。 未だ作成されていなければ（Ｓ２１：ＮＯ）、ＣＰＵ１０は、受信したパケットが属するフレームのデータプールを、ＲＡＭ１２の記憶領域内に作成する（Ｓ２２）。 作成したデータプールに、受信したパケットを記憶させる（Ｓ２３）。 処理は受信処理へ戻る。 一方、データプールが既に作成されていれば（Ｓ２１：ＹＥＳ）、受信したパケットが属するフレームのデータテーブルに、パケットが追加される（Ｓ２３）。 処理は受信処理（図５参照）へ戻る。 パケット振り分け処理（Ｓ１６）が終了すると、タイムアウト判定処理（Ｓ１７）が行われる。

図７を参照して、タイムアウト判定処理について説明する。 タイムアウト判定処理では、パケットの受信間隔が待機時間以上であるか否かが判断される。 待機時間とは、同一フレームを構成する複数のパケットのうち、一のパケットを受信してから次のパケットを受信するまで待機する最大の時間である。 受信装置は、パケットの受信を長時間待機すると、映像をリアルタイムで再生することができない。 映像が途中で途切れる場合もある。 従って、受信装置は、パケットの受信を一定時間待機した時点で、次のフレームの処理を行うのが望ましい。 しかし、パケットの受信の待機時間が短すぎると、十分な量のデータが受信されないまま映像が再生されるため、映像品質の低下等の問題が生じる。 従って、タイムアウト判定処理では、フレーム情報に基づいて適切な待機時間が設定される。 受信間隔が、設定された待機時間以上となった場合にのみ、受信遅延が生じたフレームのパケットが破棄される。

まず、ＣＰＵ１０は、受信したパケットが属するフレームのデータテーブルの情報を取得する（Ｓ３１）。 データテーブルに記憶されているパケットのうち、最後に受信されたパケットの受信時間（最終受信時間ｔ１）を取得する（Ｓ３２）。 ＣＰＵ１０は、Ｓ１１（図５参照）で受信したパケットの受信時間ｔ２を取得する（Ｓ３３）。 次いで、ＣＰＵ１０は待機時間設定処理を行う（Ｓ３４）。

図８に示すように、ＣＰＵ１０は、待機時間設定処理を開始すると、受信したパケットのヘッダからフレーム情報を取得する（Ｓ４１）。 前述したように、フレーム情報には、パケットが属するフレームのフレーム種別を示す情報が含まれる。 ＣＰＵ１０は、受信したパケットが属するフレームの種別がＩピクチャであるか否かを判断する（Ｓ４２）。 Ｉピクチャであれば（Ｓ４２：ＹＥＳ）、ＣＰＵ１０は、後述するＴｂよりも長いＴａを待機時間に設定し（Ｓ４３）、処理はタイムアウト判定処理へ戻る。 Ｉピクチャは、ＰピクチャおよびＢピクチャを復号する際に参照される。 従って、Ｉピクチャを正確に復号できなければ、ＰピクチャおよびＢピクチャの品質も低下する。 受信装置は、Ｉピクチャのパケットを受信する際の待機時間を長くすることで、Ｉピクチャに加えてＰピクチャおよびＢピクチャの品質に悪影響が生じることを防止することができる。 フレーム種別がＩピクチャでなく、ＰピクチャまたはＢピクチャであれば（Ｓ４２：ＮＯ）、ＣＰＵ１０は、Ｔａよりも短いＴｂを待機時間に設定し（Ｓ４４）、処理はタイムアウト判定処理へ戻る。

図７の説明に戻る。 待機時間設定処理（Ｓ３４）が終了すると、受信間隔（未受信時間）である「ｔ２−ｔ１」が待機時間以上であるか否かが判断される（Ｓ３５）。 受信間隔が待機時間よりも短く、同一フレームに関するパケットが円滑に受信されていれば（Ｓ３５：ＮＯ）、パケットの破棄等の処理が行われることは無い。 この場合、ＣＰＵ１０は、データプール内のパケットの最終受信時間ｔ１をｔ２で更新し（Ｓ３６）、処理は受信処理へ戻る。

受信間隔「ｔ２−ｔ１」が待機時間以上であれば（Ｓ３５：ＹＥＳ）、ＣＰＵ１０は、受信したパケットが属するフレームのデータプールに記憶されているパケットを、全て破棄する（Ｓ３７）。 データプールも破棄する（Ｓ３８）。 つまり、ＣＰＵ１０は、受信間隔が待機時間以上となったフレームのＦＥＣ復号を回避し、次のフレームの処理を行う。 ＣＰＵ１０は、データを破棄したフレームを、データ破棄済みのフレームとしてＲＡＭ１２に記憶し（Ｓ３９）、処理は受信処理へ戻る。

図５の説明に戻る。 タイムアウト判定処理（Ｓ１７）が終了すると、ＣＰＵ１０は、損失パケットを復元可能なデータ量を既に受信したか否かを判断する（Ｓ１８）。 復元可能なデータ量の情報は、前述したように、各パケットのヘッダに含まれている（図４参照）。 受信したパケットが属するフレームのデータプール内に、復元可能なデータ量が未だ記憶されていない場合、またはデータプールが破棄されている場合には（Ｓ１８：ＮＯ）、処理はそのまま終了する。 復元可能なデータ量が既にデータプール内に記憶されていれば（Ｓ１８：ＹＥＳ）、ＣＰＵ１０は、データプール内に記憶されているパケットに対してＦＥＣ復号を行う（Ｓ１９）。 ＦＥＣ復号を行ったフレームを、復号済みフレームとして記憶し（Ｓ２０）、受信処理は終了する。 つまり、ＣＰＵ１０は、復元可能な量のデータの受信が完了した時点で、受信したデータに含まれる冗長データを用いて、未だ受信していないパケットを損失パケットとして復元する。 ＣＰＵ１０は、復元可能な量のデータを受信すると、残りのパケットを受信するか否かに関わらずＦＥＣ復号を行うので、処理を迅速に行うことができる。 なお、図示しないが、ＣＰＵ１０は、復号するフレームの順が入れ替わらないように、Ｓ１９およびＳ２０の処理をフレーム番号に従って実行する。 つまり、Ｓ１９およびＳ２０の処理対象となるフレームの前のフレームに、復号およびデータ破棄のいずれも行われていないフレームがあれば、Ｓ１９およびＳ２０の処理は待機される。

図９および図１０を参照して、従来の処理の結果と本実施形態の処理の結果との比較を行う。 図９は、シーケンス番号に従ってタイムアウト判定を行う従来の処理の結果を示す。 従来の受信装置は、各パケットの送信順を示すシーケンス番号を参照し、一のパケットを受信してから次のシーケンス番号のパケットを受信するまでの時間を計測する。 シーケンス番号に従ってタイムアウト判定を行う場合、同一フレームに属するパケットが順調に受信されていてもタイムアウトと判定される場合がある。 図９に示す例では、フレーム番号「１」の複数のパケットの受信間隔は、全て一定時間内に収まっている。 よって、受信装置は、フレーム番号「１」のフレームを問題なく復号できる。 しかし、フレーム番号「１」における４番目のパケット「１−４」の受信順と、パケット「１−５」・「１−６」の受信順とが入れ替わっている。 その結果、パケット「１−３」を受信してからパケット「１−４」を受信するまでの時間が待機時間以上となり（図中「×」で示す）、従来の処理ではパケット「１−４」が破棄される。 また、パケット「１−７」の受信タイミングは、パケット「１−４」の受信直後ではあるが、シーケンス番号が１つ若いパケット「１−６」の受信時との間隔は待機時間以上となっている。 その結果、パケット「１−７」も破棄される。 ２つのパケットが破棄された結果、フレーム番号「１」のフレームは正確に復号されない。

図１０は、本実施形態のＰＣ１による処理の結果を示す。 本実施形態のＰＣ１は、同じ復元グループ（本実施形態ではフレーム）に属するパケット同士の受信間隔（未受信時間）によってタイムアウト判定を行う。 従って、図１０に示すように、パケット「１−４」の受信順が遅れても、直前に受信されたパケット「１−６」との間の受信間隔が待機時間内であれば、パケット「１−４」は破棄されることも、復号されずにそのまま放置されることもない。 つまり、同じ復元グループに属するパケットの受信間隔が待機時間内であれば、受信順が入れ替わっても影響はない。 一方、図示しないが、同じ復元グループに属するパケットの受信間隔が待機時間以上となれば、その復元グループに含まれるデータのＦＥＣ復号は回避され、他の処理が迅速に行われる。 従って、ＰＣ１は、ＦＥＣを適用して送信された連続したパケットに、受信順の誤りまたはパケットロスが生じた場合、復号に必要なパケットを無駄にすることなく効率よくデータを処理することができる。

図１０に示す例では、パケット「１−４」を受信した時点で、フレーム番号「１」に関する損失パケットを復元可能な一定量以上のデータが受信されている。 ＰＣ１は、復元可能な一定量以上のデータを受信した時点で、復元グループ（フレーム番号「１」のフレーム）に属する全てのパケットを受信したか否かに関わらず、ＦＥＣ復号を行う。 その結果、パケット「１−７」は、受信される前に損失パケットとして復元され、フレーム番号「１」のフレームが正確に復号される。 従って、受信装置は、処理を迅速に行うことができ、データ処理の効率をさらに高めることができる。 パケットロス等が生じた場合には、一定量以上のデータを受信するまで待機することで、損失パケットを復元することができる。

さらに、本実施形態の受信装置は、受信したパケットに含まれるフレーム情報に従って待機時間を設定する（図８参照）。 従って、受信装置は、待機時間を適切な長さに設定して効率よく処理を行うことができる。 詳細には、受信装置は、Ｉピクチャのパケットの待機時間を、ＰピクチャおよびＢピクチャの待機時間よりも長く設定する。 よって、Ｉピクチャに加えてＰピクチャおよびＢピクチャの品質に悪影響が生じることを防止することができる。

上記実施形態において、ＰＣ１（受信装置）が本発明の「データ処理装置」に相当する。 パケットのヘッダに含まれるフレーム番号が本発明の「グループ識別情報」に相当する。 図５のＳ１１でパケットを受信するＣＰＵ１０が、本発明の「受信手段」として機能する。 図７のＳ３２，Ｓ３３で受信間隔（未受信時間）を計測するＣＰＵ１０が「計測手段」として機能する。 図７のＳ３５で受信間隔が待機時間以上であるか否かを判断するＣＰＵ１０が「経過判断手段」として機能する。 図７のＳ３７〜Ｓ３９でＦＥＣ復号を回避するＣＰＵ１０が「回避手段」として機能する。 図５のＳ１８で復元可能なデータ量を受信済みであるか否かを判断するＣＰＵ１０が「データ量判断手段」として機能する。 図５のＳ１９でＦＥＣ復号を行うＣＰＵ１０が「復号手段」として機能する。 図８のＳ４１でフレーム情報を取得するＣＰＵ１０が「情報取得手段」として機能する。 図８のＳ４２〜Ｓ４４で待機時間を設定するＣＰＵ１０が「第一設定手段」として機能する。

図５のＳ１１でパケットを受信する処理が、本発明の「受信ステップ」に相当する。 図７のＳ３２，Ｓ３３で受信間隔（未受信時間）を計測する処理が「計測ステップ」に相当する。 図７のＳ３５で受信間隔が待機時間以上であるか否かを判断する処理が「経過判断ステップ」に相当する。 図７のＳ３７〜Ｓ３９でＦＥＣ復号を回避する処理が「回避ステップ」に相当する。

本発明は上記実施形態に限定されることはなく、様々な変形が可能であることは言うまでも無い。 図１１を参照して、上記実施形態の変形例１について説明する。 変形例１では、待機時間設定処理（図７のＳ３４）の処理内容が上記実施形態と異なるのみであり、他の構成および処理は上記実施形態と同一である。 図１１に示すように、変形例１のＣＰＵ１０は、待機時間設定処理を開始すると、受信したパケットが送信されてから受信に至るまでに要した時間（以下、「送信所要時間」という。）を計測する（Ｓ５１）。 本変形例では、パケットの送信時間を示す識別子がパケットのヘッダに付与されている。 ＣＰＵ１０は、識別子が示す時間と受信時間との差を算出することで、送信所要時間を計測する。 しかし、送信所要時間の計測方法はこれに限られず、種々の方法を用いることができる。

ＣＰＵ１０は、複数の送信所要時間の計測結果から、送信所要時間のゆらぎを算出する（Ｓ５２）。 詳細には、所定数の送信所要時間の標準偏差が、ゆらぎとして算出される。 算出されたゆらぎが閾値より大きいか否かが判断される（Ｓ５３）。 ゆらぎが閾値よりも大きければ（Ｓ５３：ＹＥＳ）、後述する時間Ｔｄよりも長い時間Ｔｃが待機時間に設定されて（Ｓ５４）、処理はタイムアウト判定処理（図７参照）へ戻る。 送信所要時間のゆらぎが大きい場合に短い待機時間を設定すると、パケットを十分に受信する前にタイムアウトとなり、映像品質が低下する場合がある。 変形例１のＣＰＵ１０は、送信所要時間のゆらぎが閾値よりも大きい場合に長い待機時間を設定することで、映像品質の低下を抑制しつつ、処理の効率を向上させることができる。 ゆらぎが閾値以下である場合には（Ｓ５３：ＮＯ）、Ｔｃよりも短いＴｄが待機時間に設定されて（Ｓ５５）、処理はタイムアウト判定処理へ戻る。 よって、ゆらぎが小さい場合には迅速に処理が行われる。

なお、変形例１において、図１１のＳ５１，Ｓ５２で送信所要時間のゆらぎを取得するＣＰＵ１０が本発明の「ゆらぎ取得手段」として機能する。 図１１のＳ５３〜Ｓ５５で待機時間を設定するＣＰＵ１０が「第二設定手段」として機能する。

図１２を参照して、上記実施形態の変形例２について説明する。 変形例２も変形例１と同様に、待機時間設定処理（図７のＳ３４）の処理内容が上記実施形態と異なるのみである。 図１２に示すように、変形例２のＣＰＵ１０は、待機時間設定処理を開始すると、受信したパケットのヘッダからフレーム情報を取得する（Ｓ６１）。 前述したように、フレーム情報にはフレームレートの情報が含まれる。 ＣＰＵ１０は、フレームレートが閾値より大きいか否かを判断する（Ｓ６２）。 フレームレートが小さければ、フレームを表示させる間隔が長くなるため、待機時間を長く設定しても影響は少ない。 フレームレートが大きければ、フレームを表示させる間隔が短くなるため、待機時間を長く設定するとフレームを円滑に表示できない可能性がある。 従って、ＣＰＵ１０は、フレームレートが閾値以下であれば（Ｓ６２：ＮＯ）、長い時間Ｔｅを待機時間に設定し（Ｓ６３）、処理はタイムアウト判定処理へ戻る。 一方、ＣＰＵ１０は、フレームレートが閾値よりも大きければ（Ｓ６２：ＹＥＳ）、Ｔｅよりも短い時間Ｔｆを待機時間に設定し（Ｓ６４）、処理はタイムアウト判定処理へ戻る。 以上のように、変形例２に係るＰＣ１は、フレームレートに応じた適切な待機時間を設定することができる。

なお、変形例２において、図１２のＳ６１でフレーム情報を取得するＣＰＵ１０が、本発明の「情報取得手段」として機能する。 図１２のＳ６２〜Ｓ６４で待機時間を設定するＣＰＵ１０が「第一設定手段」として機能する。

上記実施形態はその他の変形も可能である。 上記実施形態のＰＣ１は、音声、映像、資料、ポインタ等のデータをパケット化して送受信するが、主に説明した処理は映像データを送受信する場合の処理であった。 しかし、本発明は、音声、資料、ポインタ等の他のデータを受信する場合にも、映像データの場合と同様に適用できる。

上記実施形態のＰＣ１は、同一のフレームのデータを含む一群のパケットを復元グループとして、ＦＥＣ符号化、タイムアウト判定、およびＦＥＣ復号等の処理を行う。 しかし、フレーム単位で復元グループを設定する必要は無い。 例えば、１つのフレームを複数のスライスに分割し、スライス単位で復元グループを設定してもよい。 複数のフレームを１つの単位として復元グループを設定してもよい。 資料のデータを処理する場合には、ファイル単位、ページ単位等で復元グループを設定すればよい。

上記実施形態のＰＣ１は、送信処理（図３参照）および受信処理（図５参照）を共に実行できる。 従って、通信システム１００（図１参照）内のＰＣ１は、データを相互に送受信することができる。 しかし、本発明は、データの送信を実行せずに受信処理のみを行うデータ処理装置にも適用できる。

上記実施形態のＰＣ１は、タイムアウトとなったフレームのパケットを全て破棄することでＦＥＣ復号を回避し、処理の効率を向上させる（Ｓ３７〜Ｓ３９、図７参照）。 しかし、ＦＥＣ復号を回避する方法は、パケットを記憶手段から破棄する（消去する）方法に限られない。 例えば、パケットを記憶手段に記憶させたまま、ＦＥＣ復号を実行せずに放置することで、ＦＥＣ復号を回避してもよい。 この場合、記憶手段に残存したパケットは、処理の終了時に破棄してもよいし、定期的に破棄してもよい。

上記実施形態では、タイムアウト判定処理（図７参照）は、パケットを受信することを契機として実行される。 従って、パケットがネットワーク８で消失してタイムアウトとなった場合には、図示しない処理において、消失したパケットが属するフレームのデータプールが破棄される。 しかし、ＰＣ１は、パケットの受信時でなく、常時または定期的にタイムアウト判定処理を実行してもよい。 この場合、ＰＣ１は、同一フレームに属するパケットの受信間隔（未受信時間）が待機時間以上となった時点で、タイムアウト判定処理の処理内でデータプールを破棄してもよい。

１ ＰＣ
８ ネットワーク１０ ＣＰＵ
１２ ＲＡＭ
１３ ＨＤＤ
１００ 通信システム