(57)【要約】【課題】  複数のストリームデータをデコードする際にも、バッファアンダフローやバッファオーバフローの発生を抑制させる。【解決手段】  時刻ｔ54において、クロック差は、３０／４０として計算される。時刻ｔ54において、デコードする時刻となった場合、次のデコード時刻ｔ５５’は、図１３の最下段で示されるように、ｔ55’＝（ｔ54＋１０／（３０／４０））となる。この処理が繰り返されることにより、配信サーバとクライアントPCのそれぞれのシステムクロックのクロック差が反映されたデコード時刻が設定される。結果として、双方のシステムクロックの差が考慮されたデコードタイミングが設定されるので、バッファオーバフローやバッファアンダフローを抑制することが可能となる。本発明は、ストリームデータ配信システムに適用することができる。【選択図】  図１３
2005027209.tif 000002
【特許請求の範囲】
【請求項１】
複数の送信装置より送信されてくる複数のストリームデータを受信する受信手段と、
前記受信手段により受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶手段と、
前記受信開始時刻に基づいて、前記複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択手段と、
前記選択手段により選択されたストリームデータのタイムスタンプと、前記選択手段により選択されたストリームデータの受信時刻に基づいて、前記選択手段により選択されたストリームデータの、前記送信装置とのクロック差を計算するクロック差計算手段と、
前記複数のストリームデータを前記クロック差計算手段により計算されたクロック差に基づいてデコードするデコード手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記選択手段は、前記複数のストリームデータのうち、前記受信開始時刻が最も早いストリームデータを選択する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記クロック差計算手段は、前記選択手段により選択されたストリームデータの受信開始時のパケットと現在受信しているパケットとのタイムスタンプの時刻差と、前記選択手段により選択されたストリームデータの受信開始時のパケットと現在受信しているパケットの受信時刻差の比を、前記選択手段により選択されたストリームデータの、前記送信装置とのクロック差として計算する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
複数の送信装置より送信されてくる複数のストリームデータを受信する受信ステップと、
前記受信ステップの処理で受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶ステップと、
前記受信開始時刻に基づいて、前記複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、
前記選択ステップの処理で選択されたストリームデータのタイムスタンプと、前記選択ステップの処理選択されたストリームデータの受信時刻に基づいて、前記選択ステップの処理で選択されたストリームデータの、前記送信装置とのクロック差を計算するクロック差計算ステップと、
前記複数のストリームデータを前記クロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップと
を含むことを特徴とする情報処理方法。
【請求項５】
受信された複数のストリームデータのそれぞれの受信開始時刻に基づいて、前記複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、
前記選択ステップの処理で選択されたストリームデータのタイムスタンプと、前記選択ステップの処理選択されたストリームデータの受信時刻に基づいて、前記選択ステップの処理で選択されたストリームデータの、前記送信装置とのクロック差を計算するクロック差計算ステップと、
前記複数のストリームデータを前記クロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項６】
受信された複数のストリームデータのそれぞれの受信開始時刻に基づいて、前記複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、
前記選択ステップの処理で選択されたストリームデータのタイムスタンプと、前記選択ステップの処理選択されたストリームデータの受信時刻に基づいて、前記選択ステップの処理で選択されたストリームデータの、前記送信装置とのクロック差を計算するクロック差計算ステップと、
前記複数のストリームを前記クロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップと
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、記録媒体、並びにプログラムに関し、特に、複数のストリームデータを受信する際、送信装置とのクロック差により生じるバッファアンダフローやバッファオーバフローを抑制するようにした情報処理装置および方法、記録媒体、並びにプログラムに関する。
【背景技術】
【０００２】
インターネットを介してストリームデータを配信する技術が一般に普及しつつある。
【０００３】
ストリームデータの配信において、送信装置は、ストリームデータをパケット化し、個々のパケットに送信装置自身のシステムクロックを用いてタイムスタンプを付して受信装置に送信する。そして、受信装置は、ストリームデータを受信すると、これらのタイムスタンプに基づいて、自らのシステムクロックを用いて個々のパケットをデコードし再生している。
【０００４】
しかしながら、実際には、インターネットにおいて、送信装置から受信装置に、ストリームデータを送信するとき、送信装置と受信装置のシステムクロックが同期していないと、送信装置での出力レートと受信装置での出力レートが異なるものとなってしまう。従って、受信装置のシステムクロックが送信装置に対して速い場合、バッファアンダフローが生じ、逆に、送信装置に対して遅い場合、バッファがあふれてしまう、いわゆるバッファオーバフローが生じる。
【０００５】
そこで、これらの回復のために、バッファアンダフローが生じた場合、受信装置は、同じ情報を再度表示する必要が生じてしまい、逆に、バッファオーバフローが生じた場合、その情報の再送を要求しなくてはならない状態に陥る。
【０００６】
この問題を解決するために受信装置が、パケットのタイムスタンプとそのパケットの到着時刻に基づいて、送信装置とのシステムクロックの差を検知し、再生時刻を制御することで、バッファアンダフロー、または、オーバフローを防ぐことができる。
【０００７】
例えば、図１で示されるように、各パケットの到着時刻とタイムスタンプから、システムクロックの差は、以下のように検知される。すなわち、送信装置は、送信装置自身のシステムクロックを用いて付したタイムスタンプ10，20，30、および、40のパケットを10クロックに1パケットのレートで（時刻ｔ1乃至ｔ4のタイミングで）送信するものとする。
【０００８】
受信装置は、これを受信するときに受信装置自身のシステムクロックで到着時刻ｔ11乃至ｔ14を測定する。例えば、図１で示されるように、タイムスタンプ10のパケット受信時刻ｔ11から、タイムスタンプ40のパケット受信時刻ｔ14まで35クロックかかったものとする。結果として、図１の場合、受信装置のシステムクロックの方が、送信装置のシステムクロックより、およそ35/30倍速いことになる。そこで、受信装置は、35/30倍だけ遅れてデコードするように自らのシステムクロックを用いて制御すれば、バッファアンダフローを起こすことなくデコードすることが可能になる。尚、図１において、時間ｔは、パケットの伝播遅延時間である。
【０００９】
また、受信装置が、直前フレームのタイムスタンプ情報と今回受信したフレームから抽出したタイムスタンプ情報との差分と、記憶されている直前のRTPフレーム受信時刻と内部タイマから得た現在時刻値との差分とを比較し、両差分の差が負の値である場合には当該フレームの送信優先度を高めるように制御し、負の値でなければ当該フレームに適宜遅延時間を付加するように制御するものがある（例えば、特許文献１参照）。
【特許文献１】特開２００２−３１４５９５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述の手法は１つのストリームデータが理想的な状態である場合に適用できるものであるが、実際には、ネットワーク上で複数のストリームデータにより生じる輻輳などの影響で、パケットの到着間隔が変動するため、システムクロックの差を正確に計測することは非常に困難である。
【００１１】
また、受信装置が１つの送信装置から複数のストリームデータを受信した場合、どのストリームデータを用いて、送信装置とのシステムクロックの差を検知すればよいのかを判断することができず、結果として、バッファアンダフローや、オーバフローを抑制するのが困難であるという課題があった。
【００１２】
本発明はこのような状況に鑑みてなされたものであり、特に、受信装置が、複数のストリームデータを受信している場合、最も長い時間受信を継続しているストリームデータを用いて、送信装置のシステムクロックとの差分を求めることで送信装置とのクロック差を求め、これをもって、デコードのタイミングを制御することで、バッファオーバフローやアンダフローを抑制できるようにするものである。
【課題を解決するための手段】
【００１３】
本発明の情報処理装置は、複数の送信装置より送信されてくる複数のストリームデータを受信する受信手段と、受信手段により受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶手段と、受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択手段と、選択手段により選択されたストリームデータのタイムスタンプと、選択手段により選択されたストリームデータの受信時刻に基づいて、選択手段により選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算手段と、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコード手段とを備えることを特徴とする。
【００１４】
前記選択手段には、複数のストリームデータのうち、受信開始時刻が最も早いストリームデータを選択させるようにすることができる。
【００１５】
前記クロック差計算手段には、選択手段により選択されたストリームデータの受信開始時のパケットと現在受信しているパケットとのタイムスタンプの時刻差と、選択手段により選択されたストリームデータの受信開始時のパケットと現在受信しているパケットの受信時刻差の比を、選択手段により選択されたストリームデータの、送信装置とのクロック差として計算させるようにすることができる。
【００１６】
本発明の情報処理方法は、複数の送信装置より送信されてくる複数のストリームデータを受信する受信ステップと、受信ステップの処理で受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶ステップと、受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、選択ステップの処理で選択されたストリームデータのタイムスタンプと、選択ステップの処理選択されたストリームデータの受信時刻に基づいて、選択ステップの処理で選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算ステップと、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップとを含むことを特徴とする。
【００１７】
本発明の記録媒体のプログラムは、受信された複数のストリームデータのそれぞれの受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、選択ステップの処理で選択されたストリームデータのタイムスタンプと、選択ステップの処理選択されたストリームデータの受信時刻に基づいて、選択ステップの処理で選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算ステップと、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップとを含むことを特徴とする。
【００１８】
本発明のプログラムは、受信された複数のストリームデータのそれぞれの受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップと、選択ステップの処理で選択されたストリームデータのタイムスタンプと、選択ステップの処理選択されたストリームデータの受信時刻に基づいて、選択ステップの処理で選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算ステップと、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップとをコンピュータに実行させることを特徴とする。
【００１９】
本発明の情報処理装置および方法、並びにプログラムにおいては、複数の送信装置より送信されてくる複数のストリームデータが受信され、受信された複数のストリームデータのそれぞれの受信開始時刻が記憶され、受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータが選択され、選択されたストリームデータのタイムスタンプと、選択されたストリームデータの受信時刻に基づいて、選択されたストリームデータの、送信装置とのクロック差が計算され、複数のストリームデータが計算されたクロック差に基づいてデコードされる。
【００２０】
本発明の情報処理装置は、独立した装置であっても良いし、情報処理を行うブロックであっても良い。
【発明の効果】
【００２１】
本発明によれば、複数のストリームデータをデコードする際にも、バッファアンダフローやバッファオーバフローを抑制することが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２３】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００２４】
即ち、本発明の情報処理装置は、複数の送信装置より送信されてくる複数のストリームデータを受信する受信手段（例えば、図４の通信部６１−１乃至６１−３）と、受信手段により受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶手段（例えば、図５のストリーム開始時刻保持部７３）と、受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択手段（例えば、図５の判定部）と、選択手段により選択されたストリームデータのタイムスタンプと、選択手段により選択されたストリームデータの受信時刻に基づいて、選択手段により選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算手段（例えば、図５のクロック差計算部）と、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコード手段（例えば、図５のデコーダ７２−１乃至７２−３）とを備えることを特徴とする。
【００２５】
本発明の情報処理方法は、複数の送信装置より送信されてくる複数のストリームデータを受信する受信ステップ（例えば、図８のフローチャートのステップＳ１１の処理）と、受信ステップの処理で受信された複数のストリームデータのそれぞれの受信開始時刻を記憶する記憶ステップ（例えば、図８のフローチャートのステップＳ１３の処理）と、受信開始時刻に基づいて、複数のストリームデータのうち、いずれか１つのストリームデータを選択する選択ステップ（例えば、図１０のフローチャートのステップＳ４３の処理）と、選択ステップの処理で選択されたストリームデータのタイムスタンプと、選択ステップの処理選択されたストリームデータの受信時刻に基づいて、選択ステップの処理で選択されたストリームデータの、送信装置とのクロック差を計算するクロック差計算ステップ（例えば、図１０のフローチャートのステップＳ４４の処理）と、複数のストリームデータをクロック差計算手段により計算されたクロック差に基づいてデコードするデコードステップ（例えば、図８のフローチャートのステップＳ６７の処理）とを含むことを特徴とする。
【００２６】
図１は、本発明を適用したストリームデータ配信システムの一実施の形態の構成を示す図である。
【００２７】
カメラ１１−１乃至１１−３は、CCD（Charge Coupled Devoce）などの撮像素子を用いた、いわゆるビデオカメラであり、撮像した画像データを配信サーバ１２に出力する。尚、カメラ１１−１乃至１１−３は、この例においては、監視カメラとして使用されるものである。従って、カメラ１１−１乃至１１−３は、ユーザにより予め所定の監視位置に設置されている。また、本発明においては、カメラ１１は、３台の場合について説明するが、言うまでもなく、それ以外の台数であってもよい。さらに、以降の説明において、カメラ１１−１乃至１１−３を特に区別する必要が無い場合、単に、カメラ１１と称するものとする。また、その他の装置についても同様とする。
【００２８】
配信サーバ１２は、カメラ１１より供給された画像データを所定の方式でエンコードし（圧縮し）、通信可能なパケット単位の情報に変換し、インターネット１３を介して、クライアントPC（Personal Computer）１４にストリームデータとして配信する。
【００２９】
クライアントPC１４は、インターネット１３を介して配信サーバ１２から配信されるストリームデータを受信し、所定の伸張処理を行ったのち、元の画像データを再生し、LCD（Liquid Crystal Display）やCRT（Cathode Ray Tube）などからなる表示部１５に出力して、表示させる。尚、図１の例においては、配信サーバ１２、および、クライアントPC１４が、インターネット１３を介して、それぞれ1台ずつ設けられている場合について示されているが、実際には、配信サーバ１２は、複数のクライアントPC１４に対してストリームデータを配信するので、クライアントPC１４は、インターネット１３を介して複数台数接続されていてもよい。また、同様にして、配信サーバ１２についても、複数台数接続されていてもよいが、個々の配信サーバ１２の動作は、いずれも同様のものである。
【００３０】
次に、図２を参照して、図１の配信サーバ１２の構成について説明する。
【００３１】
画像処理部３１−１乃至３１−３は、それぞれカメラ１１−１乃至１１−３より供給される画像データを、システムクロック３２より供給される時刻情報に基づいて、所定の形式でエンコードし、さらに、パケット化して通信部３３−１乃至３３−３に出力する。
【００３２】
システムクロック３２は、各種の処理の基準となる時刻情報（クロック信号）を発生し、画像処理部３１−１乃至３１−３のエンコーダ４１−１乃至４１−３、および、パケタイザ４２−１乃至４２−３に供給する。
【００３３】
通信部３３−１乃至３３−３は、いわゆる通信モデムなどであり、画像処理部３１より供給されたRTPパケットを、ストリームデータとしてインターネット１３を介してクライアントPC１４に配信する。
【００３４】
画像処理部３１−１乃至３１−３のエンコーダ４１−１乃至４１−３は、それぞれカメラ１１−１乃至１１−３より供給される画像データを、システムクロック３２からの時刻情報に基づいて、所定の形式（例えば、MPEG２（Moving Picture Experts Group）、MPEG４、または、Motion JPEG（Joint Photographic Experts Group）など）でエンコードし（圧縮し）、それぞれパケタイザ４２−１乃至４２−３に出力する。
【００３５】
パケタイザ４２−１乃至４２−３は、それぞれエンコーダ４１−１乃至４１−３より供給されたエンコードされている画像データを、システムクロック３２より供給される時刻情報に基づいてRTPパケットに変換し、それぞれ通信部３３−１乃至３３−３に出力する。
【００３６】
次に、図４を参照して、クライアントPC１４の構成について説明する。
【００３７】
通信部６１−１乃至６１−３は、図２を参照して説明した配信サーバ１２と同様のものであり、通信モデムなどから構成されており、インターネット１３を介して配信サーバ１２との間で、データの授受を行う。通信部６１−１乃至６１−３は、RTPパケットがクライアントPC１２から送信されてくると、画像処理部６２−１乃至６２−３にそれぞれ出力する。また、通信部６１−１乃至６１−３は、RTPパケットを受信すると、ストリーム管理部６４に出力する。
【００３８】
画像処理部６２−１乃至６２−３は、それぞれストリーム管理部６４より供給されるクロック差の情報に基づいて、システムクロック６３より供給される時刻に基づいて、タイミングを調整しつつ、通信部６１−１乃至６１−３より供給されるRTPパケットを、所定の形式でデコードし、図２の表示部１５に出力して表示させる。
【００３９】
システムクロック６３は、クライアントPC１４における基準となる時刻情報（クロック信号）を発生し、通信部６１−１乃至６１−３、ストリーム管理部６４、および、デコーダ７２−１乃至７２−３に供給する。
【００４０】
ストリーム管理部６４は、通信部６１−１乃至６１−３が、RTPパケットを受信した際、それぞれの受信時刻の情報と、各RTPパケットのタイムスタンプの情報から配信サーバ１２のシステムクロック３２と、自らのシステムクロック６４とのクロック差を求めて保持し、デコーダ７２−１乃至７２−３のそれぞれがストリームデータをデコードする際に供給する。
【００４１】
画像処理部６２−１乃至６２−３のバッファ７１−１乃至７１−３は、それぞれ通信部６１−１乃至６１−３より供給されたRTPパケットを一時的に記憶し、所定のデータ量になったとき、デコーダ７１−１乃至７１−３にそれぞれ供給する。デコーダ７２−１乃至７２−３は、バッファ７１−１乃至７１−３より供給されたRTPパケットを、システムクロック６３より供給される時刻情報に基づいて、タイムスタンプの情報をストリーム管理部６４のクロック差を用いて調整したタイミングで、所定の方式でデコードし（伸張処理し）、これをLCDやCRTからなる表示部１５に出力して、表示させる。
【００４２】
次に、図５を参照して、図４のストリーム管理部６４の詳細な構成について説明する。
【００４３】
データ検出部７１は、端子７１ａ乃至７１ｃのそれぞれに通信部６１−１乃至６１−３より供給されてくるRTPパケットを検出し、受信が開始されたとき、その端子７１ａ乃至７１ｃのいずれであるかを示す情報と共に、検出されたRTPパケットをストリーム開始時刻保持部７３に出力する。尚、データ検出部７１は、例えば、端子７１ａにおいて、ストリームデータの受信が一旦終了し、再び受信が開始された場合、この再び受信が開始されたタイミングで再びストリーム開始時刻保持部７３に、RTPパケットが検出されたことを通知する。尚、データ検出部７１は、通信部６１−１乃至６１−３のそれぞれに対応する数だけ設けるようにしてもよい。
【００４４】
ストリーム開始時刻保持部７３は、ストリーム開始時刻保持部７３は、データ検出部７１より供給される端子７１ａ乃至７１ｃのいずれかでRTPパケットの受信を開始したことを示す情報を受信すると、そのタイミングで、システムクロック６３より供給されてくる時刻情報と、そのRTPパケットのタイムスタンプの情報を端子７１ａ乃至７１ｃのいずれであるかの情報に対応付けて記憶させる。すなわち、ストリーム開始時刻保持部７３は、今現在通信部６１−１乃至６１−３のそれぞれでストリームデータの受信が開始された時刻と、そのときのタイムスタンプの情報をそれぞれ記憶する。
【００４５】
判定部７２は、端子７２ａ乃至７２ｃのそれぞれに通信部６１−１乃至６１−３から供給されてくるRTPパケットが受信されていて、かつ、ストリーム開始時刻保持部７３に保持されている開始時刻に基づいて、最も長く通信が継続している端子７２ａ乃至７２ｃに対応するストリームデータを判定し、判定結果をクロック差計算部７４に出力する。尚、判定部７２は、通信部６１−１乃至６１−３のそれぞれに対応する数だけ設けるようにしてもよい。
【００４６】
クロック差計算部７４は、判定部７２より供給された最も長く通信しているストリームデータの情報に基づいて、対応するストリームデータの受信開始時刻と、そのRTPパケットのタイムスタンプの情報をストリーム開始時刻保持部７３より読出すと共に、端子７４ａ乃至７４ｃのうち、最も長く通信しているストリームデータの今現在のRTPパケットの受信時刻をシステムクロック６３より読み出すと共に、そのRTPパケットのタイムスタンプを読み出す。さらに、クロック差計算部７４は、最も長いストリームデータの受信開始時のRTPパケットのタイムスタンプと、今現在受信しているRTPパケットのタイムスタンプの差分（タイムスタンプ時刻差分）と、最も長いストリームデータの受信開始時のRTPパケットを受信したストリーム開始時刻保持部７３に記憶された時刻と、今現在受信しているRTPパケットを受信したタイミングでのシステムクロック６４の時刻との差分（システムクロック時刻差分）との比を、クライアントPC１４のシステムクロック６３と、配信サーバ１２のシステムクロック３２のクロック差としてクロック差保持部７５に出力し、保持させる。
【００４７】
クロック差保持部７５は、クロック差計算部７４より供給されたクロック差を保持し、デコーダ７２−１乃至７２−３のそれぞれに対して供給する。
【００４８】
次に、図６のフローチャートを参照して、配信サーバ１２によるストリームデータの配信処理について説明する。尚、この処理は、画像処理部３１−１および通信部３３−１、画像処理部３１−２および通信部３３−２、並びに、画像処理部３１−３および通信部３３−３が、それぞれ独立に実行する処理である。
【００４９】
ステップＳ１において、例えば、図示せぬ入力装置がユーザにより操作されて、監視の開始が指示されたり、または、予め設定された監視開始時刻であるか否かが判定され、監視の開始が指示されるまでその処理を繰り返す。例えば、図示せぬ入力装置がユーザにより操作されたり、または、予め設定された監視時刻になり、監視の開始が指示されたと判定された場合、その処理は、ステップＳ２に進む。
【００５０】
ステップＳ２において、エンコーダ４１は、エンコードする時刻となったか否かを判定する。ここでいうエンコードする時刻とは、例えば、30fps（Frame per Sec）でエンコードする場合、33ms毎の時刻のことである。ステップＳ２において、エンコーダ４１は、カメラ１１が撮像している画像をエンコードすべき時刻になっていると判定するまで、同様の処理を繰り返す。そして、ステップＳ２において、例えば、エンコードすべき時刻であると判定された場合、その処理は、ステップＳ３に進む。
【００５１】
ステップＳ３において、エンコーダ３１は、カメラ１１より供給される画像データをキャプチャする。すなわち、エンコーダ３１は、カメラ１１より供給される画像データを取得して、蓄える。
【００５２】
ステップＳ４において、エンコーダ４１は、ステップＳ３の処理でキャプチャした画像データをエンコードし、パケタイザ４２に出力する。
【００５３】
ステップＳ５において、エンコーダ４１は、エンコードした画像に対応するRTPパケットのタイムスタンプをシステムクロック３２から供給される時刻に基づいて生成し、パケタイザ４２に供給する。
【００５４】
ステップＳ６において、パケタイザ４２は、エンコーダ４１より供給されたエンコードされている画像データと、システムクロック３２から供給された時刻情報に基づいて、RTPパケットを作成する。
【００５５】
ステップＳ７において、パケタイザ３２は、作成したRTPパケットを通信部３３に出力する。このとき、パケタイザ４２は、エンコーダ４１より供給されるエンコードされている画像データに基づいて、図７で示されるようなRTPパケットを作成する。
【００５６】
すなわち、パケタイザ４２は、エンコードされているデータ（ペイロードデータ）に対して、RTPヘッダを付加しパケット化する。RTPヘッダには、バージョン番号（ｖ）（２ビット）、パディング（Ｐ）（１ビット）、拡張ヘッダ（Ｘ）（１ビット）の有無、送信元数（Counter）（Ｃ）（４ビット）、マーカ情報（marker bit）（Ｍ）（１ビット）、ペイロードタイプ（Payload Type）（７ビット）、シーケンス番号（１６ビット）、タイムスタンプ（３２ビット）、同期ソース（送信元）識別子（SS（Synchronization Source）RC）（３２ビット）、および、貢献ソース（送信元）識別子（CS（Contributing Source）RC）（３２ビット）の各フィールドが設けられている。
【００５７】
クライアントPC１４は、RTPヘッダに付与されたタイムスタンプによりRTPパケットの展開時に処理時間を制御し、リアルタイム画像、または音声を再生する。なお、例えば動画像データの符号化データを格納したRTPパケットにおいては、１つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがRTPヘッダに格納される。
【００５８】
ステップＳ８において、通信部３４は、インターネット１３を介してRTPパケットをクライアントPC１４に送信する。
【００５９】
ステップＳ９において、エンコーダ４１は、次のエンコード時刻を決定する。より詳細には、エンコーダ４１は、上述したように、例えば、30fps（Frame per Sec）でエンコードする場合、次のエンコード時刻を、現在時刻の33ms後の時刻に決定する。
【００６０】
ステップＳ１０において、図示せぬ入力装置がユーザにより操作されて、監視の終了が指示されるか、または、予め設定された監視時刻が終了したか否かが判定される。ステップＳ１０において、監視の終了が指示されていないと判定された場合、その処理は、ステップＳ２に戻り、監視の終了が指示されたと判定された場合、その処理は、ステップＳ１に戻り、それ以降の処理が繰り返される。
【００６１】
以上の処理により、ストリームデータを送信する側である配信サーバ１２は、自らシステムクロック３２に基づいたタイムスタンプの情報を含むRTPパケットをカメラ１１−１乃至１１−３のそれぞれについてのストリームデータとして配信する。
【００６２】
次に、図８のフローチャートを参照して、クライアントPC１４による受信処理を説明する。
【００６３】
ステップＳ３１において、データ検出部７１は、端子７１ａ乃至７１ｃに入力される信号の状態から、通信部６１が（通信部６１−１乃至６１−３のそれぞれが）、インターネット１３を介して配信サーバ１２から送信されてきたRTPパケットを受信したか否かを判定し、RTPパケットが受信されたと判定されるまでその処理を繰り返す。例えば、図６のフローチャートを参照して説明した処理により、配信サーバ１２がストリームデータを配信している場合、ステップＳ３１において、通信部６１−１乃至６１−３のいずれかが、配信サーバ１２から送信されてきたRTPパケットを受信するので、RTPパケットが受信されたと判定し、その処理は、ステップＳ３２に進む。
【００６４】
ステップＳ３２において、ストリーム管理部５４のデータ検出部７１は、RTPパケットを受信している端子７１ａ乃至７１ｃの状態から、最初のRTPパケットであるか否かを判定する。すなわち、RTPパケットの受信開始直後のRTPパケットである場合、最初のRTPパケットであると判定され、ステップＳ３３において、データ検出部７１は、受信した端子７１ａ乃至７１ｃがいずれであって、どのストリームデータであるのかを識別する情報、および、受信開始時のRTPパケットを出力すると共に、そのタイミングでストリーム開始時刻保持部７３にストリーム開始時刻、並びに、その開始時刻に受信されたRTPパケットのタイムスタンプの時刻を保持するように指示する。データ検出部７１からの指示に基づいて、ストリーム開始時刻保持部７３は、そのタイミングでのシステムクロック６４の時刻と、開始時に受信されたRTPパケットのタイムスタンプの時刻情報を、ストリームデータを識別する情報に対応付けて保持する。
【００６５】
ステップＳ３４において、通信部３３は、受信したRTPパケットをバッファ７１に転送し、その処理は、ステップＳ３１に戻り、それ以降の処理が繰り返される。
【００６６】
以上の処理により、クライアントPC１４は、現在受信中のストリームデータの受信開始時刻とそのRTPパケットのタイムスタンプを順次、ストリーム管理部５４のストリーム開始時刻保持部７３に保持しつつ、受信したRTPパケットをバッファ７１に供給する。
【００６７】
次に、図９のフローチャートを参照して、ストリーム管理部５４によるストリーム管理処理について説明する。
【００６８】
ステップＳ４１において、判定部７２は、端子７２ａ乃至７２ｃに通信部６１−１乃至６１−３から供給される信号に基づいて、通信部６１−１乃至６１−３がRTPパケットを受信しているか否かを判定し、受信していると判定されるまで、その処理を繰り返す。ステップＳ４１において、端子７２ａ乃至７２ｃのうちのいずれか１つでもRTPパケットが受信されている場合、判定部７２は、通信部６１−１乃至６１−３がRTPパケットを受信しているとみなし、その処理は、ステップＳ４２に進む。
【００６９】
ステップＳ４２において、判定部７２は、同期の時刻になったか否かを判定し、同期の時刻になるまで、その処理を繰り返す。この同期の時刻は、後述するステップＳ４６の処理により決定されるものであるが、最初の処理では、決定された時刻が存在しないので、処理開始から所定の時刻がデフォルトとして設定されている。例えば、ステップＳ４２において、同期の時刻になったと判定された場合、その処理は、ステップＳ４３に進む。
【００７０】
ステップＳ４３において、判定部７２は、ストリーム開始時刻保持部７３にアクセスして、端子７２ａ乃至７２ｃのうち、今現在RTPパケットを受信している端子のそれぞれについて、受信しているRTPパケットの受信開始時刻が最も早いものであるかいなか、すなわち、端子７２ａ乃至７２ｃのうちの今現在RTPパケットを受信している端子のそれぞれについて、ストリームデータとして一番長いものを受信しているか否かを判定する。
【００７１】
ステップＳ４３において、最も長いストリームデータではないと判定された場合、その処理は、ステップＳ４１に戻る。すなわち、最も長いストリームデータであると判定されるまで、端子７２ａ乃至７２ｃのうちの、今現在RTPパケットを受信している端子について、ステップＳ４１乃至Ｓ４３の処理を繰り返す。
【００７２】
ステップＳ４３において、いずれかの端子７２ａ乃至７２ｃにおいて、最も長いストリームデータであると判定された場合、その処理は、ステップＳ４４に進む。
【００７３】
すなわち、例えば、図１０で示されるようなタイミングでRTPパケットが受信されたものとすると、ステップＳ４３における判定結果は以下のようになる。尚、図１０においては、上から順に端子７２ａ乃至７２ｃの順序で、それぞれの端子がRTPパケットを受信するタイミングを示している。従って、図１０においては、端子７２ａが、時刻ｔ20乃至ｔ23、および、時刻ｔ25乃至ｔ26、端子７２ｂが、時刻ｔ21乃至ｔ24、並びに、端子７２ｃが、時刻ｔ22乃至ｔ26の、それぞれのタイミングでRTPパケットを受信していることを示している。
【００７４】
従って、図１０においては、時刻ｔ20乃至ｔ23においては、端子７２ａについてのステップＳ４３の処理がなされたとき、最も長いストリームデータであると判定される。また、時刻ｔ23乃至ｔ24においては、端子７２ｂについてのステップＳ４３の処理がなされたとき、最も長いストリームデータであると判定される。同様に、時刻ｔ24乃至ｔ26においては、端子７２ｃについてのステップＳ４３の処理がなされたとき、最も長いストリームデータであると判定される。換言すれば、ステップＳ４３の処理は、最も長いストリームデータが選択される処理であるとも言える。
【００７５】
ステップＳ４４において、クロック差計算部７４は、配信サーバ１２とのシステムクロック３２のクロック差を計算する。より詳細には、クロック差計算部７４は、最も長いストリームデータを受信していると判定された端子に該当するストリーム開始時刻保持部７３に保持されているストリーム開始時刻と、その開始時に受信されたRTPパケットのタイムスタンプの時刻を読み出すと共に、今、最も長いストリームデータを受信していると判定されている端子で受信されているRTPパケットの受信時刻と、そのRTPパケットのタイムスタンプの時刻を読出し、以下の式（１）で示すような計算により、クロック差を求める。
【００７６】
D＝（TSP−TSS）／（CLP−CLS）
・・・（１）
【００７７】
ここで、Dは、クロック差を、TSPは、今受信されたRTPパケットのタイムスタンプの時刻、TSSは、受信開始時に受信されたRTPパケットのタイムスタンプの時刻、CLPは、今受信されたRTPパケットの受信時のシステムクロック６３の時刻、CLSは、受信開始時のシステムクロック６３の時刻である。すなわち、今受信されたRTPパケットのタイムスタンプの時刻TSPと、受信開始時に受信されたRTPパケットのタイムスタンプの時刻TSSは、配信サーバ１２のシステムクロック３２の時刻なので、式（１）で示されるクロック差は、クライアントPC１４のシステムクロック６３と配信サーバ１２のシステムクロック３２との相互のクロック差を、（タイムスタンプ時刻差分）／（システムクロック時刻差分）で示される比で表したものである。従って、式（１）で示されるクロック差Dが、１である場合、相互のクロックは同期しているが、クロック差Dが１よりも大きい場合、クライアントPC１４のシステムクロック６３は、配信サーバ１２のシステムクロック３２より遅いことが示されることになり、逆に、クロック差Dが１よりも小さい場合、クライアントPC１４のシステムクロック６３は、配信サーバ１２のシステムクロック３２より速いことが示されることになる。
【００７８】
ステップＳ４５において、クロック差計算部７４は、上記の式（１）で計算されたクロック差Ｄをクロック差保持部７５に保持するように書き込む。
【００７９】
ステップＳ４６において、判定部７２は、次の同期時刻を設定し、その処理は、ステップＳ４１に戻り、それ以降の処理が繰り替えされる。すなわち、同期を取るための処理は、所定の時間間隔でなされるものであるので、現在時刻に所定の時間（例えば、５分など）を加算した時刻を次の同期時刻として設定する。
【００８０】
以上の処理により、所定の時間間隔で、その時点で最も長いストリームデータに基づいて、クロック差Ｄが計算されて、クロック差保持部７５に保持される。すなわち、クロック差保持部７５に保持されるクロック差は、その時点で最も長いストリームデータに基づいて、所定の時間間隔で更新される。尚、最も長いストリームデータのクロック差Dを採用する理由については、後述する。
【００８１】
次に、図１１のフローチャートを参照して、デコード処理について説明する。
【００８２】
ステップＳ６１において、デコーダ７２は、バッファ７１のバッファリングが十分であるか否かを判定し、バッファリングが十分であると判定されるまでその処理を繰り返す。そして、ステップＳ６１において、図８のフローチャートを参照して説明した受信処理により、バッファ７１へのバッファリングが繰り返され、バッファリングが十分であると判定された場合、ステップＳ６２において、デコーダ７２は、デコードする時刻になったか否かを判定し、デコードする時刻になったと判定されない場合、その処理は、ステップＳ６１に戻る。ここで、デコードする時刻は、後述するステップＳ６７の処理で、前回の処理で決定された時刻である。しかしながら、最初の処理におけるデコードの開始時刻は、デフォルトの時刻が設定されている。
【００８３】
ステップＳ６２において、デコードする時刻になったと判定された場合、ステップＳ６３において、デコーダ７２は、バッファ７１から、バッファリングされたRTPパケットを取得する。
【００８４】
ステップＳ６４において、デコーダ７２は、取得したRTPパケットを順次デコードし、ステップＳ６５において、後段の表示部１５に出力し、表示させる。
【００８５】
ステップＳ６５において、デコーダ７２は、ストリーム管理部６４にアクセスし、クロック差保持部７５に保持されているそのときのクロック差Ｄを読み出す。
【００８６】
ステップＳ６７において、デコーダ７２は、クロック差Ｄに基づいて、次のデコード時刻を設定し、その処理は、ステップＳ６１に戻る。より詳細には、デコーダ７２は、以下の式（２）を計算することにより次のデコード時刻を設定する。
【００８７】
SCL＝PT+NCL／D
・・・（２）
【００８８】
ここで、SCLは、ステップＳ６７の処理により設定される次のデコード時刻であり、NCLは、タイムスタンプに基づいて設定される次のデコード時刻までの現在時刻からの時間であり、PTは、現在時刻である。すなわち、タイムスタンプに基づいた次のデコード時刻までの現在からの時間NCLは、例えば、図１２で示されるように、タイムスタンプが０，３３，６６で示されているRTPパケットの場合、３３msである。従って、図１２中において、タイムスタンプが０であるRTPパケットから右方向にデコードが進むとき、デコードされるべき時刻ｔ31，ｔ32，ｔ33は、それぞれ最初のデコード開始時刻である０msから３３ms後、および、６６ms後となる。従って、クロック差Dが１１／１０であった場合、例えば、図１２のタイムスタンプ３３のRTPパケットは、６３（＝３３＋３３／（１１／１０））ms後の時刻に、次のデコード時刻SCLが設定される。
【００８９】
以上の処理により、複数のストリームデータの全て次のデコード時刻は、タイムスタンプにより設定された時刻までの時間をクロック差D（システムクロック３２，６３の相互の1クロック分の時間の比）で割った時間を、現在時刻に加算した時刻であるので、システムクロック３２，６３の相互の１クロック分の時間差が調整されることにより、バッファアンダフローや、バッファオーバフローを抑制することが可能となる。
【００９０】
図１３を参照して、以上の処理をまとめると、以下のようになる。尚、以下においては、図１３の最上段で示すようなタイミングでRTPパケットが配信サーバ１２から配信され、図１３の中段で示すようにクライアントPC１４で受信され、図１３で示される最下段のようにデコードされるものとする。
【００９１】
より詳細には、図１３の最上段においては、タイムスタンプが１０乃至８０のRTPパケットが１０クロック（配信サーバ１２のシステムクロック３２の１０クロック）毎に、時刻ｔ41乃至ｔ48の時刻に配信されていることが示されており、時刻ｔ41乃至ｔ44の時間は３０クロック（配信サーバ１２のシステムクロック３２の３０クロック）であって、時刻ｔ41乃至ｔ47の時間は６０クロック（配信サーバ１２のシステムクロック３２の６０クロック）であることが示されている。
【００９２】
また、図１３の中段においては、最上段の時刻ｔ41より送信時間分だけ遅れた時刻ｔ51から、最上段で示されるタイミングで送信された、タイムスタンプが１０乃至８０のRTPパケットが、順次時刻ｔ51乃至ｔ58で受信されていることが示されている。この場合、時刻ｔ51乃至ｔ54の時間は、４０クロック（クライアントPC１４のシステムクロック６３の４０クロック）であって、時刻ｔ51乃至ｔ57の時間は８０クロック（クライアントPC１４のシステムクロック６３の８０クロック）であることが示されている。
【００９３】
従って、図１３の最上段のタイミングで配信サーバ１２がRTPパケットを配信し、図１３の中段のタイミングでクライアントPC１４がRTPパケットを受信し続けると、最終的には、バッファアンダフローが生じてしまう。
【００９４】
そこで、このような場合、図１３の中段で示されるストリームデータが、今現在受信されている複数のストリームデータの中で最も長いストリームデータであるとき、図９のフローチャートを参照して説明した処理により、例えば、時刻ｔ54において、クロック差Dが、３０／４０として計算されて、クロック差保持部７５に保持されることになる。
【００９５】
次に、例えば、時刻ｔ54において、デコードする時刻となった場合、上述した、図１１のフローチャートのステップＳ６７の処理で、次のデコード時刻ｔ55’は、図１３の最下段で示されるように、ｔ55’＝（ｔ54＋１０／（３０／４０））となる。このような処理が繰り返されることにより、配信サーバ１２とクライアントPC１４のそれぞれのシステムクロック３２，６３のそれぞれのクロック差（ここでは、D=３０／４０）が反映されたデコード時刻ｔ56’乃至ｔ58’が設定される。結果として、双方のシステムクロックの差が考慮されたデコードタイミングが設定されるので、バッファオーバフローやバッファアンダフローが抑制される。
【００９６】
また、システムクロックのクロック差を求めるにあたり、複数のストリームデータのうち、最も長いストリームデータを選択する理由は、以下の通りである。
【００９７】
すなわち、例えば、図１４の上段で示されるように、タイムスタンプ１０のRTPパケットが時刻ｔA1に配信され、タイムスタンプ４０のRTPパケットが、配信サーバ１２のシステムクロック３２で３０クロック後の時刻ｔA2に配信されたものとする。そして、このタイムスタンプ１０のRTPパケットが、クライアントPC１４において、時刻tA1’に受信され、そのタイムスタンプ４０のRTPパケットが、クライアントPC１４のシステムクロック６３で３５クロック後の時刻ｔA3に配信されたものとする。この場合、クロック差Dは、３０／３５となる。尚、図１４においては、時刻tA1’から３０クロック後の時刻として、時刻ｔA2'が示されている。
【００９８】
これに対して、例えば、図１５の上段で示されるように、タイムスタンプ１０のRTPパケットが時刻ｔA11に配信され、タイムスタンプ３１０のRTPパケットが、配信サーバ１２のシステムクロック３２で３１０クロック後の時刻ｔA12に配信されたものとする。そして、このタイムスタンプ１０のRTPパケットが、クライアントPC１４において、時刻tA11’に受信され、そのタイムスタンプ３１０のRTPパケットが、クライアントPC１４のシステムクロック６３で３０５クロック後の時刻ｔA13に配信されたものとする。この場合、クロック差Dは、３００／３０５となる。尚、図１４においては、時刻tA11’から３００クロック後の時刻として、時刻ｔA12’が示されている。
【００９９】
図１４，図１５の例においては、いずれにおいても、クロック数の差（いわゆるジッタ）は５クロック分だけであるが、図１５で示されるように、図１４で示されるストリームデータよりも長いストリームデータにおいては、ジッタにより生じるクロック数の差の割合を小さくできる（図１４においては、ジッタの割合は、１／６であるが、図１５においては、１／６０となる）ため、結果として、複数のストリームデータに対して、ジッタによる影響を最小にした状態で、システムクロックの差を反映して、デコードのタイミングを調整することが可能となり、複数のストリームデータをデコードしても、バッファアンダフローやバッファオーバフローを抑制することが可能となる。
【０１００】
以上によれば、複数のストリームデータのうち最も長いストリームデータを基準として、配信サーバ１２とクライアントPC１４のそれぞれのクロック差を求め、求められたクロック差に基づいて、再生するタイミングを調整するようにしたので、複数のストリームデータの再生を行うような場合でも、クロック差により生じるバッファアンダフローやバッファオーバフローを抑制することが可能となる。
【０１０１】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行させることが可能な、例えば汎用のパーソナルコンピュータなどに記録媒体からインストールされる。
【０１０２】
図１６は、図４のクライアントPC１４の電気的な内部構成をソフトウェアにより実現する場合のパーソナルコンピュータの一実施の形態の構成を示している。パーソナルコンピュータのCPU１０１は、パーソナルコンピュータの全体の動作を制御する。また、CPU１０１は、バス１０４および入出力インタフェース１０５を介してユーザからキーボードやマウスなどからなる入力部１０６から指令が入力されると、それに対応してROM(Read Only Memory) １０２に格納されているプログラムを実行する。あるいはまた、CPU１０１は、ドライブ１１０に接続された磁気ディスク１２１、光ディスク１２２、光磁気ディスク１２３、または半導体メモリ１２４から読み出され、記憶部１０８にインストールされたプログラムを、RAM(Random Access Memory) １０３にロードして実行する。これにより、上述した図４のクライアントPC１４の機能が、ソフトウェアにより実現されている。さらに、CPU１０１は、通信部１０９を制御して、外部と通信し、データの授受を実行する。
【０１０３】
プログラムが記録されている記録媒体は、図１６に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１２１（フレキシブルディスクを含む）、光ディスク１２２（CD-ROM(Compact Disc-Read Only Memory)，DVD（Digital Versatile Disk）を含む）、光磁気ディスク１２３（MD（Mini-Disc）を含む）、もしくは半導体メモリ１２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM１０２や、記憶部１０８に含まれるハードディスクなどで構成される。
【０１０４】
尚、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理は、もちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理を含むものである。
【０１０５】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【図面の簡単な説明】
【０１０６】
【図１】バッファオーバフロー、または、バッファアンダフローが生じる原理を説明する図である。
【図２】本発明を適用したストリームデータ配信システムの構成を示す図である。
【図３】図２の配信サーバの構成を示すブロック図である。
【図４】図２のクライアントPCの構成を示すブロック図である。
【図５】図４のストリーム管理部の構成を示すブロック図である。
【図６】配信処理を説明するフローチャートである。
【図７】RTPパケットを説明する図である。
【図８】受信処理を説明するフローチャートである。
【図９】ストリーム管理処理を説明するフローチャートである。
【図１０】ストリーム管理処理を説明する図である。
【図１１】デコード処理を説明するフローチャートである。
【図１２】デコード処理のタイミングを説明するタイミングチャートである。
【図１３】RTPパケットが配信されるタイミング、デコードされるタイミング、補正されるタイミングを説明するタイミングチャートである。
【図１４】最も長いストリームデータを用いてクロック差を求める理由を説明する図である。
【図１５】最も長いストリームデータを用いてクロック差を求める理由を説明する図である。
【図１６】記録媒体を説明する図である。
【符号の説明】
【０１０７】
１１，１１−１乃至１１−３  カメラ，  １２，１２−１乃至１２−３  配信サーバ，  １３  インターネット，  １４，１４−１乃至１４−３  クライアントPC，  ３２  システムクロック，  ３３，３３−１乃至３３−３  通信部，  ４１，４１−１乃至４１−３  エンコーダ，  ４２，４２−１乃至４２−３  パケタイザ，  ６１，６１−１乃至６１−３  通信部，  ６３  システムクロック，  ６４  ストリーム管理部，  ７１，７１−１乃至７１−３  バッファ，  ７２，７２−１乃至７２−３  デコーダ，  ７１  データ検出部，  ７２  判定部，  ７３  ストリーム開始時刻保持部，  ７４  クロック差計算部，  ７５  クロック差保持部
【図１】
2005027209.tif 000003
【図２】
2005027209.tif 000004
【図３】
2005027209.tif 000005
【図４】
2005027209.tif 000006
【図５】
2005027209.tif 000007
【図６】
2005027209.tif 000008
【図７】
2005027209.tif 000009
【図８】
2005027209.tif 000010
【図９】
2005027209.tif 000011
【図１０】
2005027209.tif 000012
【図１１】
2005027209.tif 000013
【図１２】
2005027209.tif 000014
【図１３】
2005027209.tif 000015
【図１４】
2005027209.tif 000016
【図１５】
2005027209.tif 000017
【図１６】
2005027209.tif 000018