JP2008048182A - 通信処理装置、および通信制御方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】受信データの再生処理、または記録と再生処理の各処理態様に適応した再送制御を行う構成を提供する。
【解決手段】ストリーミングデータ受信を実行する通信処理装置において、通信処理装置の処理状態が（１）「再生のみ」を実行する状態、または、（２）「再生＋記録」を実行する状態、これらのいずれの状態にあるかに応じて、ロスパケットに対応する再送要求を実行するか否かの判定態様を変更して制御を行なう。本構成により、再生処理のみの場合にはリアルタイム再生の実現、記録処理を行なう場合には、記録データの完全性の向上が実現される。
【選択図】図３

Description

本発明は、通信処理装置、および通信制御方法、並びにコンピュータ・プログラムに関する。特に、受信データの再生処理や記録処理を実行する装置において、実行する処理が再生処理のみであるか、記録処理を伴う再生処理であるか等の処理状況に応じて最適な通信制御を実行する通信処理装置、および通信制御方法、並びにコンピュータ・プログラムに関する。

ブロードバンドネットワークの普及とともに、画像データ等データ量の大きいデータ通信もリアルタイム再生が可能となってきている。例えば、ＩＰ電話やＴＶ電話などでは、音声に併せて画像データを送信し、双方でリアルタイム再生を行ない、双方向コミュニケーションが実現される。

データを実時間（リアルタイム）で通信する通信手法は、ストリーミング通信と呼ばれる。ストリーミングを行うためのプロトコルとしては、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ストリーミングなどのＴＣＰ上でのストリーミング・プロトコルがある。このＴＣＰ通信では、途中のネットワークでパケットロスが発生した場合、受信側から再送要求が自動的に実行され、確実なパケットの送受信が実現される。すなわち、ＴＣＰを利用した通信では、自動的に再送要求を行い、確実に正しい順序で受信アプリケーションにパケットが届く設定となっている。

しかし、このＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による通信は、再送要求が頻繁に発生すると大きな遅延が発生してしまうので、リアルタイム性の必要なストリーミング配信には適さない。

一方、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、ＲＦＣ３５５０）ストリーミングなどＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上でのストリーミング配信は、途中のネットワークでパケットロスが発生しても、原則としてデータ受信側からの再送要求は行なわない。従って、遅延の発生が少なく、リアルタイム性が必要な場合には、ＵＤＰ上でのストリーミングが用いられることが多い。しかし、ＲＴＰやＵＤＰを適用した通信ではパケットロスによる消失データが受信アプリケーションに届かないという問題がある。

このＲＴＰやＵＤＰにおける問題を解決する構成として、受信データの処理を実行するアプリケーションの判断で、例えば安定した再生を行うためにデータが必要と判断した場合、ストリーミング送信側に対してパケット再送を要求する構成がある。しかし、このような再送要求を行うと、上述したＴＣＰと同じように遅延が発生することになる。

例えばストリーミング再生のパケット消失が発生し、再送要求がなされた後、遅延して受信しパケットが再生処理に間に合わない場合は、結果としてデータ送受信双方での処理が増え、ネットワークに無駄なパケットを流すというデメリットを発生させるのみとなる。このような問題を解決する手法として、特許文献１（特許第３７５７８５７）には、必要に応じて「再生に間に合うと思われるパケット」だけを受信側から再送要求を行なう構成を開示している。

例えば、インターネットを介して動画データを受信して記録（保存）する場合には、リアルタイム性が必要ではないこともある。このような場合、一般的には確実にデータが届くＨＴＴＰ（ＴＣＰ）によるダウンロードが用いられる。一方、ストリーミング再生を行い、かつそのストリーミング受信データの記録も行なう場合には、再生処理におけるリアルタイム性が優先され、リアルタイム再生の妨げとなるＨＴＴＰによるダウンロードは適用されないのが一般的である。

このように、遅延の発生が許容されないストリーミング再生処理と、遅延の発生が許容される受信データ記録処理には、それぞれに適した通信プロトコルが利用される。これらの処理、すなわち、ストリーミング再生処理と、データ記録処理の処理態様に応じた要求を同時に満たし、再生および記録の双方に適応する処理を実現する構成はこれまでに提案されていない。

例えば特許文献２（特開２００５−８６３６２）には、ストリーミングを行う際の記録方法についての構成が開示されている。しかし、この開示手法ではＨＴＴＰを用い、再送要求がなされ遅延が発生する場合は、再生スキップを行なう構成であり、再生品質の低下が発生することになる。
特許３７５７８５７ 特開２００５−８６３６２号公報

本発明は、上述の状況に鑑みてなされたものであり、受信データの再生処理や記録処理を実行する装置において、実行する処理が再生処理のみであるか、記録処理を伴う再生処理であるか等の処理状況に応じて最適な通信制御を実行する通信処理装置、および通信制御方法、並びにコンピュータ・プログラムを提供することを目的とする。

本発明の第１の側面は、
ネットワークを介するデータ受信を行なう通信処理装置であり、
通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態管理を行なう状態管理部と、
受信データ中の損失データを検出するデータ損失検出部と、
損失データに対する再送要求を出力するか否かの決定処理を実行する再送要求制御部とを有し、
前記再送要求制御部は、
通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定し、
通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行する構成であることを特徴とする通信処理装置にある。

さらに、本発明の通信処理装置の一実施態様において、前記受信データはパケット単位で受信されるデータであることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記再送要求制御部は、通信処理装置が、再生のみを実行する再生状態にある場合は、予め測定されたデータ送信装置との間の往復遅延時間に基づいて、再送要求を行うか否かを決定する処理を実行する構成であることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信処理装置は、再生処理に適用するデータを蓄積するデコードバッファと、記録処理に適用するデータを蓄積する記録バッファに対するデータ格納制御を行う再生・記録判別部を有し、前記再生・記録判別部は、前記状態管理部から、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態情報を入力して、バッファへのデータ蓄積処理様を変更する構成であることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記再送要求制御部に対して、再生処理を実行している受信データに対応する再生時刻情報を通知し、前記再送要求制御部は、前記再生・記録判別部から入力する情報、すなわち、再生処理を実行している受信データに対応する再生時刻情報を適用して、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定を実行する構成であることを特徴とする。

さらに、本発明の第２の側面は、
ネットワークを介するデータ受信を行なう通信処理装置における通信制御方法であり、
状態管理部において、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの判別を行なう状態管理ステップと、
データ損失検出部が、受信データ中の損失データを検出する損失データ検出ステップと、
再送要求制御部が、損失データに対する再送要求を出力するか否かの決定処理を実行する再送要求制御ステップとを有し、
前記再送要求制御ステップは、
通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定し、
通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行するステップであることを特徴とする通信制御方法にある。

さらに、本発明の通信制御方法の一実施態様において、前記受信データはパケット単位で受信されるデータであることを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記再送要求制御ステップは、通信処理装置が、再生のみを実行する再生状態にある場合は、予め測定されたデータ送信装置との間の往復遅延時間に基づいて、再送要求を行うか否かを決定する処理を実行することを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信制御方法は、さらに、再生・記録判別部において、再生処理に適用するデータを蓄積するデコードバッファと、記録処理に適用するデータを蓄積する記録バッファに対するデータ格納制御を行う再生・記録制御ステップを有し、前記再生・記録判別部は、前記再生・記録制御ステップにおいて、前記状態管理部から、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態情報を入力して、バッファへのデータ蓄積処理様を変更することを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記再生・記録判別部は、前記再送要求制御部に対して、再生処理を実行している受信データに対応する再生時刻情報を通知し、前記再送要求制御部は、前記再生・記録判別部から入力する情報、すなわち、再生処理を実行している受信データに対応する再生時刻情報を適用して、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定を実行することを特徴とする。

さらに、本発明の第３の側面は、
ネットワークを介するデータ受信を行なう通信処理装置において、通信制御を実行させるコンピュータ・プログラムであり、
状態管理部において、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの判別を行なわせる状態管理ステップと、
データ損失検出部に、受信データ中の損失データを検出させる損失データ検出ステップと、
再送要求制御部に、損失データに対する再送要求を出力するか否かの決定処理を実行させる再送要求制御ステップとを有し、
前記再送要求制御ステップは、
通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定させ、
通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行させるステップであることを特徴とするコンピュータ・プログラムにある。

なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記憶媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づく、より詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本発明の一実施例の構成によれば、例えばリアルタイムストリーミング再生処理を行うためのストリーミングデータ受信を実行する通信処理装置において、通信処理装置の処理状態が以下の状態のいずれであるか、すなわち、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態にあるかに応じて、ロスパケットに対応する再送要求を実行するか否かの判定態様を変更して制御を行なう構成としたので、再生処理のみの場合にはリアルタイム再生の実現、記録処理を行なう場合には、記録データの完全性の向上といった、それぞれの目的とするデータ態様を実現した再生処理および記録処理が実現される。

以下、図面を参照しながら、本発明の通信処理装置、および通信制御方法、並びにコンピュータ・プログラムの詳細について説明する。

本発明の通信処理装置は、例えばリアルタイムストリーミング再生処理を行うためにストリーミングデータ受信を行なう際、通信処理装置が受信するデータを、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態であっても、
各状態に対応する態様でのパケット取得制御を行い、処理状態に適したデータ取得に基づく再生または記録を行なう構成を有する。

本発明の通信処理装置の構成および処理についての説明の前に、ＲＴＰやＵＤＰプロトコルを適用した通信構成において、「再生に間に合うと思われるパケット」だけを受信側から再送要求を行なう構成例の概要について説明する。なお、この処理例は、例えば本出願人と同一出願に係る特許（特許第３７５７８５７）に記載されている。通信処理装置は、通信プロトコルとして、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、ＲＦＣ３５５０）や、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を適用し、リアルタイムストリーミング再生を行なう。

リアルタイムストリーミング再生を行なう機器では、リアルタイム性の確保、すなわち、受信データの遅延を小さくして再生することが重要とされる。この低遅延再生を実現するため、通信処理装置のパケットロス検出部では、受信パケットのロス（消失）を検出し、以下のような処理を行う。

（ステップ１）
「パケットロスが検知されたパケットに付加されていたはずの再生時刻」を判定、
（ステップ２）
ステップ１で判定したロスパケットの「再生時刻」と、「現在の再生時刻＋Ｔ（猶予時間）」を比較、
（ステップ３）
（３ａ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも大きい（遅い）場合は、
受信したパケットを再生するまでにＴ以上の余裕があるので、再生までに再送が間に合うと判断して、送信側に「再送要求部」より再送要求を送る。
（３ｂ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも小さい（早い）場合は、
再生までにロスパケットの再送要求に基づく受信が間に合わないと判断して再送要求を送らない。

このような処理によって、「再生に間に合うと思われるパケット」だけを受信側から再送要求を行なう構成が実現される。パケットには、受信側において、データ再生を順番に間違いなく実行可能とするため再生時刻が付与されている。例えばＲＴＰパケットのタイムスタンプである。ＲＴＰのタイムスタンプは、例えばビデオデータならば同じフレームのデータを含んだ複数のパケットに、同じタイムスタンプが付けられている。

図１にＲＴＰパケットの構成を示す。図１に示すように、ＲＴＰパケットは、動画データ等の実データに想到するペイロードの他、各プロトコル対応のヘッダとしてＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダが設定される。ＲＴＰヘッダには、
シーケンスナンバー（16ビット）：パケット毎に１つずつ増えるカウンタ
タイムスタンプ（32ビット）：再生時刻を示す
送信元識別子（SSRC）（32ビット）：送信者を示す
マーカー（1ビット）：ビデオフレームの最後のパケットかなどの識別情報
これらの情報が含まれる。

再送要求の実行可否の判定は、このＲＴＰヘッダの再生時刻を示すタイムスタンプを参照して行なわれることになる。データ受信再生を行なう通信処理装置のパケットロス検出部（データ損失検出部）において、パケットロスを検知した場合、そのロスしたパケットに付加されていたタイムスタンプを前後のパケットのタイムスタンプから推定する。なお、連続的にパケットロスがある場合や、フレームの最初／最後のパケットがロスした場合にも、そのタイムスタンプの範囲を、前後のパケットに基づいて推定する。

通信処理装置では、ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも大きい（遅い）か、小さい（早い）かによって、再送要求を行うか否かを決定することになる。ここでＴ（猶予時間）は、ストリーミング送信側に再送要求を送出し、要求したそのパケットが再生までに間に合うように再送されてくると判断する基準値であり、例えば送信側と受信側のデータ往復遅延時間であるＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）の値が用いられる。

データ送受信処理およびＲＴＴを適用した再送要求の判定処理および再送処理、受信処理のシーケンスについて、図２を参照して説明する。図２は、左側にストリーミングデータの送信処理を実行する送信装置、右側にストリーミングデータの受信および再生処理を実効する受信装置を示している。

送信装置は、シーケンスナンバー［ｎ］と、タイムスタンプ［ｔ］が付与されたパケットを順次送信する。前述したように、シーケンスナンバー［ｎ］は各パケットに設定されるカウンタであり、１つのパケット毎に１増分される設定となっている。タイムスタンプ［ｔ］は、再生時刻を示している。図に示す例では、３つのパケットが１つの再生時刻用のデータを格納したパケットとして設定された例である。

送信装置は、まず、再生時刻ｔ＝０の３つのパケットｎ＝１〜３を送信装置に送信し、送信装置は、これらのパケットを受信して再生を行なう。再生タイミングは、図に示す時間［Ｔａ］であるとする。

さらに、送信装置は継続的にパケット送信を実行し、受信装置は、受信および再生処理を実行する。この処理の実行中、シーケンスナンバー：ｎ＝４、タイムスタンプ：ｔ＝１００のパケットが受信装置において受信できなかったとする。この場合、受信装置は、前後の受信パケットのシーケンスナンバーやタイムスタンプ情報から、ロスパケットを特定する。すなわち、ロスパケットのシーケンスナンバーが、ｎ＝４であり、タイムスタンプがｔ＝１００であると推定する。

受信装置は、この推定に基づいて、ロスパケット［ｎ＝４，Ｔ＝１００］の再送要求を実行するか否かを決定する。すなわち、前述したように、
（ａ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも大きい（遅い）場合は、
受信したパケットを再生するまでにＴ以上の余裕があるので、再生までに再送が間に合うと判断して、送信側に「再送要求部」より再送要求を送る。
（ｂ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも小さい（早い）場合は、
再生までにロスパケットの再送要求に基づく受信が間に合わないと判断して再送要求を送らない。
このような処理によって、「再生に間に合うと思われるパケット」だけを受信側から再送要求を行なう。

図２に示す例では、
現在の再生時刻は、［Ｔｂ］であり、
猶予時間は［Ｔ］である。この猶予時間［Ｔ］は、データ送受信装置間の往復遅延時間であるＲＴＴが適用可能であり、予め計測された時間である。
また、ロスパケット［ｎ＝４，Ｔ＝１００］の再生時刻は、［Ｔｄ］である。

この場合、受信装置は、
ロスパケット［ｎ＝４，Ｔ＝１００］の「再生時刻（Ｔｄ）」が、「現在の再生時刻（Ｔｂ）＋Ｔ（猶予時間）」よりも大きいか否か、すなわち、
Ｔｄ＞Ｔｂ＋Ｔ
が成立するか否かを判定する。

Ｔｄ＞Ｔｂ＋Ｔ
上記式が成立する場合は、受信したパケットを再生するまでにＴ以上の余裕があるので、再生までに再送が間に合うと判断して、送信側に「再送要求部」より再送要求を送る。
一方、上記式が成立しない場合は、再生までにロスパケットの再送要求に基づく受信が間に合わないと判断して再送要求を送らない。

受信装置は、これらの処理によって、「再生に間に合うと思われるパケット」だけを選別して再送要求を行なう構成としている。

図２を参照して説明した方法は、再生のみを行うための方法であるが、先にも述べたように、ストリーミング受信した動画データの記録も同時に行う場合は、再生処理に間に合わなくても、再送要求によりロスパケットを受信して、完全性の高いデータ記録を行なうことが好ましい。

しかし、データ受信側において、再生処理のみを実行し記録処理を行なわない場合は、再生に間に合わないパケットを何度も再送要求することは、結果的に再生に間に合わないパケットの受信をもたらすのみで、無駄な処理が発生するとともに、ネットワーク上の無駄なデータ転送を増大させるという問題も発生させる。

本発明の通信処理装置は、例えばリアルタイムストリーミング再生処理を行うためのストリーミングデータ受信に際して、通信処理装置の状態が、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態であるかを判別し、判別した状態に応じて、ロスパケットの再送処理要求の態様を変更して、各状態に応じた最適な再送制御を実現するものである。

以下、本発明の通信処理装置の構成および実行する処理について、図３以下を参照して説明する。図３は、本発明の通信処理装置の構成を示すブロック図である。図３に示す通信処理装置１００は、ＲＴＰやＵＤＰプロトコルを適用した通信により、図示しないデータ送信装置の送信するパケットを、ネットワークインタフェース１０１を介して受信する。受信パケットは、先に図１を参照して説明した構成を有し、
シーケンスナンバー（16ビット）：パケット毎に１つずつ増えるカウンタ
タイムスタンプ（32ビット）：再生時刻を示す
送信元識別子（SSRC）（32ビット）：送信者を示す
マーカー（1ビット）：ビデオフレームの最後のパケットかなどの識別情報
これらの情報が含まれるパケットである。

通信処理装置１００は、ネットワークインタフェース１０１を介してパケット受信部１０２においてパケットを受信し、データ損失検出部として機能するパケットロス検出部１０３において、ロスパケットの検出を実行する。この処理は、受信パケットに設定されたシーケンスナンバー、タイムスタンプから、受信できなかったロスパケットのシーケンスナンバー、タイムスタンプを特定する処理として実行される。

パケットロス検出部１０３においてロスパケットの検出された後、受信パケットは、パケット受信バッファ１０４に蓄積され、その後、フレーム構成部１０５において、パケットから実データ（ペイロード）を取り出して、再生データ（フレーム画像など）を生成する処理が実行される。

その後、再生・記録判別部１０６は、自装置である通信処理装置１００が、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態にあるかを判別し、判別状態に応じて、フレーム構成部１０５において生成されたフレームデータを再生処理部を構成するデコードバッファ１０７、または記録処理を実行する記録バッファ１２１のいずれか、または双方に供給する。
（１）「再生のみ」を実行する状態にある場合は、再生処理部を構成するデコードバッファ１０７に供給し、
（２）「再生＋記録」を実行する状態にある場合は、再生処理部を構成するデコードバッファ１０７と、記録処理を実行する記録バッファ１２１の双方に供給する。

再生処理においては、デコードバッファ１０７に蓄積されたデータを、ビデオデコーダ１０８、オーディオデコーダ１１０が取得して、デコード処理を行い、それぞれ映像出力部１０９、音声出力部１１１に出力して再生処理が実行される。

記録処理を実行する場合は、記録バッファ１２１に蓄積されたデータを記録管理部１２２が取得して、所定の記録フォーマットへの変換処理などを実行し、ＨＤＤなどの記憶装置１２３に記録する処理が実行される。

図４に示すフローを参照して、再生・記録判別部１０６の実行する処理の詳細を説明する。再生・記録判別部１０６は、まず、ステップＳ１０１において、パケット受信バッファ１０４を検証して、フレーム構成データが到着しているか否かを判定し、到着している場合、ステップＳ１０２において、自装置が、再生処理のみを実行している状態であるか、再生と記録処理を併せて実行している状態であるかを判別する。図３に示す再生・記録判別部１０６は、状態管理部１３１から、状態情報を入力して装置の状態を判別する。

再生と記録を併せて実行している場合は、ステップＳ１０３に進み、再生処理における再生時刻情報と、パケット受信バッファ１０４から取得したパケットの再生時刻とを対比し、ステップＳ１０４において、再生時刻に間に合う処理のタイミングで、パケットから取得した実データをデコードバッファ１０７に転送する。

次に、再生・記録判別部１０６は、ステップＳ１０５において、再生時刻情報を再送制御部１３２に出力する。この情報は、再送要求制御部１３２において再送要求を実行するか否かを判定する処理に利用される。この処理については、後段で詳細に説明する。

さらに、ステップＳ１０６において、再生・記録判別部１０６は、パケット受信バッファ１０４から取得したパケットの実データを記録処理側の記録バッファ１２１に転送し、ステップＳ１０７において、転送済みのフレーム構成データをパケット受信バッファ１０４から消去する。

一方、記録処理を実行することなく、再生のみを実行している場合は、ステップＳ１０２からステップＳ１１１に進む。ステップＳ１１１では、再生処理における再生時刻情報と、パケット受信バッファ１０４から取得したパケットの再生時刻とを対比し、ステップＳ１１２において、再生時刻に間に合う処理のタイミングで、パケットから取得した実データをデコードバッファ１０７に転送する。

次に、再生・記録判別部１０６は、ステップＳ１１３において、再生時刻情報を再送制御部１３２に出力する。この情報は、再送要求制御部１３２において再送要求を実行するか否かを判定する処理に利用される。この処理については、後段で詳細に説明する。最後に、ステップＳ１１４において、転送済みのフレーム構成データをパケット受信バッファ１０４から消去する。

再生・記録判別部１０６は、図４に示すフローに従った処理を再生処理の終了、あるいは再生と記録処理の終了するまで継続して実行する。

次に、通信処理装置１００の実行するロスパケットに対する再送要求制御について図３を参照して説明する。パケットロス検出部１０３は、受信パケットに設定されたシーケンスナンバー、タイムスタンプから、受信できなかったロスパケットのシーケンスナンバー、タイムスタンプを特定し、このロスパケット情報を再送要求制御部１３２に出力する。また、再生・記録判別部１０６は、実行中の再生処理における再生時刻情報、すなわち、実際に再生されているデータに対応するパケットに設定されている再生時刻を再送制御部１３２に入力する。

再送制御部１３２は、さらに、状態管理部１３１から、通信処理装置の実行状態、すなわち、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態に設定されているかの情報を入力する。なお、この状態設定は、ユーザ入力部１４１からのユーザ入力に応じて切り替えが可能な構成となっている。

再送制御部１３２は、これらの情報、すなわち、
（ａ）通信処理装置の状態（再生のみ、または再生＋記録）
（ｂ）ロスパケット情報（ロスパケットのシーケンスナンバー、タイムスタンプ）
（ｃ）再生時刻情報（再生処理の行なわれているパケットの再生時刻）
これらの情報をそれぞれ状態管理部１３１、パケットロス検出部１０３、再生・記録判別部１０６から入力する。
さらに、再送要求制御部１３２は、予め、計測済みのデータ往復遅延時間としてのＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）の値、すなわち、送信側と受信側の装置間で計測したデータ往復遅延時間としてのＲＴＴを保持している。

再送要求制御部１３２は、通信処理装置１００が、
（１）「再生のみ」を実行する状態にある場合は、
ＲＴＴを、Ｔ（猶予時間）として、ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも大きい（遅い）か、小さい（早い）かによって、再送要求を行うか否かを決定する。すなわち、再生に間に合う再送パケットの受信が可能と判断された場合にのみ、再送要求を実行する。

一方、通信処理装置１００が、
（２）「再生＋記録」を実行する状態にある場合は、
再送要求制御部１３２は、再生に間に合う再送パケットの受信が可能か否かの判断を実行することなく、予め定めた上限回数に至るまで、繰り返し再送要求を実行する。

再送要求制御部１３２の実行する再送要求制御処理について、図５を参照して説明する。再送要求制御部１３２は、ステップＳ２０１において、パケットロスが検出されたか否かを判定する。これは、図３に示すパケットロス検出部１０３からの入力情報によって判定される。

次に、再送要求制御部１３２は、ステップＳ２０２において、自装置が再生のみを実行しているか、再生と記録を併せて実行しているかの状態判別処理を実行する。この状態判別処理は、図３に示す状態管理部１３１からの入力情報に基づいて行なわれる。自装置が再生のみを実行している場合は、ステップＳ２０３に進み、自装置が再生と記録を併せて実行している場合は、ステップＳ２１１に進む。

まず、自装置が再生と記録処理を併せて実行している場合の処理について説明する。自装置が再生と記録処理を併せて実行している場合、再送要求制御部１３２は、ステップＳ２０３において、再送要求回数のカウント値が、予め設定された上限回数を超えているか否かを判定する。再送要求制御部１３２は、ある１つの特定パケットに対応する再送要求処理回数をカウントし、このカウント値が予め設定された上限回数を超えているか否かを判定する処理を実行する。

設定回数（上限）を超えている場合は、ステップＳ２２１に進み、新たな再送要求を実行することなく処理を終了する。一方、設定回数（上限）を超えていない場合は、ステップＳ２０４に進み、再送要求パケットを生成して、パケット送信部１３３を介して再送要求パケットを出力する。

次に、ステップＳ２０５において、予め定めた設定時間内での再送パケットの受信に成功したか否かを判定し、受信されていない場合は、ステップＳ２０３に戻り、さらに、設定回数に基づいて再度の再送要求を行うか否かを判定する。制限時間内に受信されている場合は、ステップＳ２０６に進み、再送パケットの受信を完了する。

このように記録処理が実行されている場合は、予め定めた上限回数に至るまで、差異層要求を繰り返し実行する。すなわち、記録処理が実行されている場合は、再送パケットが再生に間に合うか否かについての判定は行なわない。

一方、再生処理のみが実効されている場合は、ステップＳ２０２からステップＳ２１１に進む。自装置が再生処理のみを実行している場合、再送要求制御部１３２は、ステップＳ２１１において、再生に間に合う再送パケットの受信が可能か否かの判断を実行する。この処理は、
（ａ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも大きい（遅い）場合は、
受信したパケットを再生するまでにＴ以上の余裕があるので、再生までに再送が間に合うと判断して、送信側に再送要求を送る。
（ｂ）ロスパケットの「再生時刻」が、「現在の再生時刻＋Ｔ（猶予時間）」よりも小さい（早い）場合は、
再生までにロスパケットの再送要求に基づく受信が間に合わないと判断して再送要求を送らない。
このように、ステップＳ２１１の判定処理は、「再生に間に合うと思われるパケット」だけを受信側から再送要求を行なうための判定処理として実行される。

再生に間に合うパケット受信が不可能と判断した場合は、ステップＳ２２１に進み、再送要求を断念し、再送要求は実行しない。一方、再生に間に合うパケット受信が可能と判断した場合は、ステップＳ２１２に進み、再送要求パケットを生成して、パケット送信部１３３を介して再送要求パケットを出力する。

次に、ステップＳ２１３において、予め定めた設定時間内での再送パケットの受信に成功したか否かを判定し、受信されていない場合は、ステップＳ２１１に戻り、さらに、再度の再送要求を行うか否かを、再生に間に合うか否かに基づいて判定する処理を繰り返す。ステップＳ２１３において、制限時間内に受信されたことが確認された場合は、ステップＳ２１４に進み、再送パケットの受信を完了する。

このように記録処理が実行されず、再生のみが実行されている場合は、再送要求を行うか否かを、再送要求パケットの受信が、再生に間に合うか否かに基づいて判定する処理を行なう。

このように、本発明の通信処理装置は、例えばリアルタイムストリーミング再生処理のためのストリーミングデータ受信を行なう通信処理装置において、通信処理装置の処理状態が以下の状態のいずれであるか、すなわち、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態にあるかに応じて、ロスパケットに対応する再送要求を実行するか否かの判定態様を変更して制御を行なう構成としたので、再生処理のみの場合にはリアルタイム再生の実現、記録処理を行なう場合には、記録データの完全性の向上といった、それぞれの目的とするデータ態様を実現した再生処理および記録処理が実現される。

なお、状況によっては、ストリーミング再生した映像・音声の動画データを再生した通りにそのまま記録したいという場合もあるので、ユーザがその選択をできることが望ましい。このような場合は、再生処理用のデコードバッファに格納したデータと同じものを記録処理用の記録バッファ１２１に記録する設定とすればよい。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本発明の一実施例の構成によれば、例えばリアルタイムストリーミング再生処理を行うためのストリーミングデータ受信を実行する通信処理装置において、通信処理装置の処理状態が以下の状態のいずれであるか、すなわち、
（１）「再生のみ」を実行する状態、または、
（２）「再生＋記録」を実行する状態、
これら（１），（２）のいずれの状態にあるかに応じて、ロスパケットに対応する再送要求を実行するか否かの判定態様を変更して制御を行なう構成としたので、再生処理のみの場合にはリアルタイム再生の実現、記録処理を行なう場合には、記録データの完全性の向上といった、それぞれの目的とするデータ態様を実現した再生処理および記録処理が実現される。

通信処理に適用するパケット構成例を示す図である。 ＲＴＴに基づく再送制御シーケンスについて説明する図である。 本発明の一実施例に係る通信処理装置の構成を示すブロック図である。 本発明の一実施例に係る通信処理装置の再生・記録判別部の実行する処理シーケンスについて説明するフローチャートを示す図である。 本発明の一実施例に係る通信処理装置の再送要求制御部の実行する処理シーケンスについて説明するフローチャートを示す図である。

符号の説明

１００ 通信処理装置
１０１ ネットワークインタフェース
１０２ パケット受信部
１０３ パケットロス検出部
１０４ パケット受信バッファ
１０５ フレーム構成部
１０６ 再生・記録判別部
１０７ デコードバッファ
１０８ ビデオデコーダ
１０９ 映像出力部
１１０ オーディオデコーダ
１１１ 音声出力部
１２１ 記録バッファ
１２２ 記録管理部
１２３ 記憶装置
１３１ 状態管理部
１３２ 再送要求制御部
１３３ パケット送信部
１４１ ユーザ入力部

Claims (11)

1. ネットワークを介するデータ受信を行なう通信処理装置であり、
   通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態管理を行なう状態管理部と、
   受信データ中の損失データを検出するデータ損失検出部と、
   損失データに対する再送要求を出力するか否かの決定処理を実行する再送要求制御部とを有し、
   前記再送要求制御部は、
   通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定し、
   通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行する構成であることを特徴とする通信処理装置。
2. 前記受信データはパケット単位で受信されるデータであることを特徴とする請求項１に記載の通信処理装置。
3. 前記再送要求制御部は、
   通信処理装置が、再生のみを実行する再生状態にある場合は、
   予め測定されたデータ送信装置との間の往復遅延時間に基づいて、再送要求を行うか否かを決定する処理を実行する構成であることを特徴とする請求項１に記載の通信処理装置。
4. 前記通信処理装置は、
   再生処理に適用するデータを蓄積するデコードバッファと、記録処理に適用するデータを蓄積する記録バッファに対するデータ格納制御を行う再生・記録判別部を有し、
   前記再生・記録判別部は、
   前記状態管理部から、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態情報を入力して、バッファへのデータ蓄積処理様を変更する構成であることを特徴とする請求項１に記載の通信処理装置。
5. 前記再生・記録判別部は、
   前記再送要求制御部に対して、再生処理を実行している受信データに対応する再生時刻情報を通知し、
   前記再送要求制御部は、前記再生・記録判別部から入力する情報、すなわち、再生処理を実行している受信データに対応する再生時刻情報を適用して、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定を実行する構成であることを特徴とする請求項４に記載の通信処理装置。
6. ネットワークを介するデータ受信を行なう通信処理装置における通信制御方法であり、
   状態管理部において、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの判別を行なう状態管理ステップと、
   データ損失検出部が、受信データ中の損失データを検出する損失データ検出ステップと、
   再送要求制御部が、損失データに対する再送要求を出力するか否かの決定処理を実行する再送要求制御ステップとを有し、
   前記再送要求制御ステップは、
   通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定し、
   通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行するステップであることを特徴とする通信制御方法。
7. 前記受信データはパケット単位で受信されるデータであることを特徴とする請求項６に記載の通信制御方法。
8. 前記再送要求制御ステップは、
   通信処理装置が、再生のみを実行する再生状態にある場合は、
   予め測定されたデータ送信装置との間の往復遅延時間に基づいて、再送要求を行うか否かを決定する処理を実行することを特徴とする請求項６に記載の通信制御方法。
9. 前記通信制御方法は、さらに、
   再生・記録判別部において、再生処理に適用するデータを蓄積するデコードバッファと、記録処理に適用するデータを蓄積する記録バッファに対するデータ格納制御を行う再生・記録制御ステップを有し、
   前記再生・記録判別部は、前記再生・記録制御ステップにおいて、
   前記状態管理部から、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの状態情報を入力して、バッファへのデータ蓄積処理様を変更することを特徴とする請求項６に記載の通信制御方法。
10. 前記再生・記録判別部は、前記再送要求制御部に対して、再生処理を実行している受信データに対応する再生時刻情報を通知し、
    前記再送要求制御部は、前記再生・記録判別部から入力する情報、すなわち、再生処理を実行している受信データに対応する再生時刻情報を適用して、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定を実行することを特徴とする請求項９に記載の通信制御方法。
11. ネットワークを介するデータ受信を行なう通信処理装置において、通信制御を実行させるコンピュータ・プログラムであり、
    状態管理部において、通信処理装置の処理状態が、受信データの再生のみを実行する再生状態にあるか、受信データの再生と記録を併せて実行する再生記録状態にあるかの判別を行なわせる状態管理ステップと、
    データ損失検出部に、受信データ中の損失データを検出させる損失データ検出ステップと、
    再送要求制御部に、損失データに対する再送要求を出力するか否かの決定処理を実行させる再送要求制御ステップとを有し、
    前記再送要求制御ステップは、
    通信処理装置が、再生のみを実行する再生状態にある場合は、再送要求データに基づく再送データの受信が再生処理に間に合うか否かの判定に基づいて、再送要求を行なうか否かを決定させ、
    通信処理装置が、再生と記録を併せて実行する再生記録状態にある場合は、１つの損失データに対する再送要求の送信回数が、予め設定された上限回数に至ったか否かの判定に基づいて、再送要求を行なうか否かを決定する処理を実行させるステップであることを特徴とするコンピュータ・プログラム。