JP2001502503A

JP2001502503A - ビットストリーム解析のための装置及び方法

Info

Publication number: JP2001502503A
Application number: JP10518653A
Authority: JP
Inventors: ディートリッヒ，チャールズ，ベンジャミン; ヨンソン，ラグナー，ヒリヌア
Original assignee: サーノフコーポレイション
Priority date: 1996-10-11
Filing date: 1997-10-10
Publication date: 2001-02-20
Also published as: EP0932949A1; EP0932949B1; WO1998017024A1; US6208643B1; EP0932949A4; DE69732041T2; DE69732041D1

Abstract

(57)【要約】時間基準とプログラム特定情報との不一致等のビットストリーム内のエラーをリアルタイムに検出し検証する（３００）ビットストリーム解析器（２００）を開示する。周波数トラッキング（４１０、４２０、４２５、４３０）は、種々の時間要素の受信時間のトラッキングを行うことによって、時間基準を１つだけ備える。

Description

【発明の詳細な説明】ビットストリーム解析のための装置及び方法本願は、米国仮出願第６０／０２７，９３８号（１９９６年１０月１１日出願）及び米国仮出願第６０／０２８，３６９号（１９９６年１月１５日出願）の利益を主張する。本発明は、受信したディジタルビットストリームのパラメータを測定する装置及びそれに付随した方法に関する。特に、この発明は、ビットストリームを「リアルタイム」で評価し、ビットストリーム内の種々の時間要素を検証する装置及び方法に関する。発明の背景一般に、データストリーム（ビットストリーム）は種々のデータ要素を含んでいる。これらのデータ要素はビデオデータ、音声データ、タイミングデータ、プログラム特定情報データ及び制御データを含み、これらのデータは種々の「パケット」にパッケージ化されている。パケットは、全部まとめて交換及び送信される種々のデータ要素を含む２進数字群である。データ要素及び他の情報は、種々の特定フォーマット、例えば、ＩＳＯ／ＩＥＣ国際規格１１１７２−^*（ＭＰＥＧ−１）、１３８１８−^*（ＭＰＥＧ２）、ＡＴＳＣ規格及びディジタルビデオ放送（ＤＶＢ）仕様ｐｒＥＴＳ３００−４６８に従って配列され、これらの規格は全て本明細書の一部と見なされる。一般に、ＭＰＥＧでは、パケットが「基本データストリーム」から多数の連続バイトの前にあるヘッダからなると定義している。基本ストリームとは、単に、コード化ビデオビットストリーム、コード化音声ビットストリーム又は他のコード化ビットストリームのうちの１つの総称である。特に、ＭＰＥＧ２の「トランスポートストリーム」パケットは、長さが４バイト以上、ペイロードの最大長が１８４バイトのヘッダから構成される。トランスポートストリームパケットは、トランスポートストリームにアセンブルされた１以上プログラムの一部である。そして、トランスポートストリームは、特定送速度でチャネルで送信される。トランスポートストリームの重要な構成要素は、種々の時間要素、即ち、プログラムクロック参照（ＰＣＲ）データとプログラム特定情報（ＰＳＩ）と呼ばれる記述データとを含む。尚、ＭＰＥＧ２によって、別個の情報システムをＰＳＩ、例えば、ＤＶＢ仕様に準拠するサービス情報（ＳＩ）とともに用いることができる。要するに、ＰＣＲはビットストリーム自身のタイミングを符号化するタイムスタンプであり、このＰＣＲを用いてデコーダタイミングを導出し、ここで、ＳＩは提供されたサービスアレイに関するデコーダに情報を提供する。ＳＩによって、デコーダは特定のサービスに自動的に同調することができるとともに、サービスを関連するスケジュール情報を持つカテゴリにグループ化することができる。このため、これらの時間要素及びプログラム特定情報を適正に受信したかどうか、それらが関連する規格によって定義された制約の範囲内であるかどうかを監視及び検証することが重要である。更に、これらの時間要素及びプログラム特定情報が許容範囲外の場合、復号化システムにリアルタイムで知らせることも重要である。このような規格からの逸脱を検出することによって、復号化システムは、複数のチャネルに影響を及ぼすおそれがあるパケットフレーミングエラー、ジッタ、一致しない時間基準情報又はネットワーク全体のエラーを考慮することができる。トランスポートストリーム内のデータを記憶装置に取り込んだ後、そのデータを解析することはコスト効率が高いかもしれないが、リアルタイム解析の利益が失われてしまう。ＰＣＲ処理については、システム仕様のパート９及びパート１の付記Ｄにジッタ測定の非常に一般的な記述が一組の仕様１３８１８に２つ含まれているが、これらの２つの方法は多くのパラメータをユーザに一任し、また、欠陥を幾つか含み、リアルタイムの用途において実用的ではない。従って、本技術において、リアルタイムのビットストリーム解析を行う方法及び装置が必要である。具体的には、時間基準情報とプログラム特定情報との不一致等のビットストリーム内のエラー検出及び検証を行う方法及び装置が必要である。発明の概要本発明は、時間基準情報とプログラム特定情報との不一致等のビットストリーム内のエラーをリアルタイムに検出し検証するビットストリーム解析器である。本発明において、周波数トラッキングは時間基準を１つだけ備え、この時間基準は２７ＭＨｚの内部発振器又は２７ＭＨｚの外部ＴＴＬ入力であるのが好ましい。ＰＩＤの時間基準で時間を連続的に測定する必要はないので、本発明は、その特定ＰＩＤのＰＣＲ及びパケットの受信時間のみをトラッキングする。本発明は個々の「システム時間クロック」（ＳＴＣ）を作成し、これらのクロックは、デコーダが特定のＰＩＤで送信されたＰＣＲを用いている場合のシステム時間クロックの状態を見失わないように追跡する。２７ＭＨｚの内部基準カウンタを用いて、ＰＣＲ受信時間を測定する。受信時間を２７ＭＨｚの１サイクル以内で測定する。入力の１８８バイトモード又は２０４バイトモードの仕様を受信時間の計算に用いる。実際、測定はパケット開始着信時間である。ＰＣＲの着信を、ＰＣＲパケットの着信及びそのパケットの後続のパケットの着信時間に基づいて計算する。どのバイトがＰＣＲ及び２つのパケット開始時間の間のバイト数を保持しているかについての知識を用いて、ＰＣＲ着信時間をこれら２つの値の間に補間する。計算したＰＣＲｎの受信時間をｔＰＣＲ（ｎ）と定義する。この値を用いて、ＰＣＲを受信したとき、ＰＩＤのシステム時間クロック（ＳＴＣ）を変更する。ＳＴＣを、以下に定義するように、係数「ｆ_pid」によって修正する。このため、周波数毎に修正した測定時間間隔、即ち、下式の値によって、ＰＣＲ（ｎ）受信時の新しいＳＴＣをその前の値から更新すべきである。 STC(n)=STC(n-1)+(tPCR(n)-tPCR(n-1))^*(1+f_pid) システム時間クロックを設定していない場合(ＳＴＣ（ｎ−１）を定義していない場合)、又は、ＳＴＣ（ｎ）の計算値がＰＣＲ（ｎ）とかなり異なる場合、ＳＴＣをＰＣＲ値とともにロードする。これが既知の不連続状態でない場合、エラーメッセージを発行する。一実施形態では、（ｔＰＣＲ（ｎ）−ｔＰＣＲ（ｎ＝１））＞０．１秒の場合のすべてのイベントを不連続状態として扱い、エラーメッセージを出し、ＳＴＣを受信したＰＣＲ値とともに再びロードする。図面の簡単な説明本発明の教示内容は、添付図面に照らし合わせて以下の詳細な説明を考慮することによって容易に理解することができる。図１は、簡略化した従来のパケットストリームシステムのブロック図である。図２は、リアルタイムビットストリーム解析を行う本発明のビットストリーム解析器を示した図である。図３は、リアルタイムビットストリーム解析を行う方法のフロー図である。図４は、連続ＰＣＲ処理方法のフロー図である。図５は、エラー「ｅ」を周波数オフセット「ｆ」に変換するフィルタのブロック図である。図６は、エラー「ｅ」を周波数オフセット「ｆ」に変換するフィルタの別の実施形態のブロック図である。図７は、ＰＣＲ＿ジッタ処理方法のフロー図である。図８は、ＰＣＲ＿ギャップ処理方法のフロー図である。図９は、不連続ＰＣＲ処理方法のフロー図である。図１０は、リアルタイムシステムにおいてＳＩの関連セクションの着信間時間の一致を測定する方法のフロー図である。理解を容易にするため、可能な場合は同一の符号を用いて、各図面に共通する同一の構成要素を示した。詳細な説明図１に、従来のパケットストリームシステム１００の簡略化した構造のブロック図を示す。より具体的には、ＭＰＥＧ規格に準拠して定義された「トランスポートストリーム」を図１に示すパケットストリームシステムに用いる。ＭＰＥＧのトランスポートストリームを一例として用いて本発明を以下に説明するが、当業者であれば、本発明をいかなるビットストリーム、即ち、ＭＰＥＧの「プログラムストリーム」又は他のフォーマットに準拠する他のパケットストリームに適用できることは分かるであろう。システム１００は、パス１１０上のビデオデータを受信し、そのビデオデータを基本ビデオビットストリームに符号化するビデオエンコーダ１２０を備えている。同様に、本システムは、パス１１２上の音声データを受信し、その音声データを基本音声ビットストリームに符号化する音声エンコーダ１２２も備えている。次に、これらのビットストリームをパケット化器１３０及び１３２に送り、ここで、基本ビットストリームをパケットに変換する。パケットをパケット化器で形成するとき、トランスポートストリームとは無関係にパケットを用いる情報を追加してもよい。このため、音声データ／ビデオデータ以外のデータ、例えば、ＳＩもトランスポートストリームにパケット化するが、これらの音声データ／ビデオデータ以外のデータ源は図１に図示していない。トランスポートストリームマルチプレクサ１４０によって、パケットの受信及び多重化を行い、パス１４５上のトランスポートストリームを生成する。プログラム（関連するビデオデータ及び音声データを持つ「パケット識別子」（ＰＩＤ）群）を形成する基本ストリームから構成されるパケットは、一般に、共通の時間基準を共有する。このため、トランスポートストリームは１以上の独立した時間基準を有する１以上のプログラムを含むことができ、この場合、その時間基準を同期化表現に用いる。１つのトランスポートストリーム内の異なるプログラムの時間基準は異なってもよい。パス１４５上のトランスポートストリームを送信チャネル１５０で送信し、このチャネル１５０は、更に、別個のチャネル特定エンコーダ及びデコーダ（図示されていない）を備えてもよい。次に、トランスポートストリームデマルチプレクサ１６０によって、トランスポートストリームの多重化の解除及び復号を行い、ここで、基本ストリームはビデオデコーダ１７０及び音声デコーダ１９０に対する入力として機能し、各デコーダ１７０及び１９０の出力は、それぞれ、パス１７５上の復号化ビデオ信号及びパス１９５上の復号化音声信号となる。更に、トランスポートストリームデマルチプレクサ１６０によってタイミング情報の抽出も行い、そのタイミング情報を、ビデオデコーダと音声デコーダを互いに同期させるとともにこれらのデコーダをチャネルと同期させるクロック制御部１８０に送る。デコーダとチャネルとの同期化はトランスポートストリーム内のＰＣＲを用いることによって行われ、この場合、ＰＣＲを用いてデコーダタイミングを導出する。図２は、ＭＰＥＧ２のトランスポートストリーム等の多重化ビットストリームに対するリアルタイムビットストリーム解析を監視し実行する本発明のビットストリーム解析器２００のブロック図を示す。ビットストリーム解析器２００は、別個の装置としてトランスポートストリームデマルチプレクサ１６０の前に実装するか、又は、図１に示すようなトランスポートストリームデマルチプレクサ１６０の機能と一体化することができる。このため、本発明のビットストリーム解析器は、多重化ビットストリームに対するリアルタイムビットストリーム解析を行うことができるより大型の復号化システム内に実装することができる。ビットストリーム解析器２００を用いて、ビットストリーム内の種々の時間要素、例えば、ＰＣＲデータの正確度と正当性及びＳＩの着信間（inter arrival ）時間を検証し監視する。ビットストリーム解析器は基本ストリーム毎に時間基準を抽出して、ＰＣＲに違反しない制約を検証する。同様に、ビットストリーム解析器は、トランスポートストリーム内のＳＩ情報を含むパケットを処理する。その処理では、同一のタイプ群（以下に定義する）からの連続「セクション」が指定時間間隔内、例えば、互いの２５ｍｓｅｃ以内で発生していないかどうかを検証する。図２に戻ると、ビットストリーム解析器２００は、入力バッファ２１０と、バッファコントローラ２２０と、カウンタ２３０と、プロセッサ２４０と、メモリ２５０と、ディスプレイ２６０とを備える。より具体的には、ビットストリーム解析器は、クロック情報をＰＣＲデータ及び「パケット開始」標識の形で伝える、ＭＰＥＧのトランスポートストリーム等のパス２０５上のリアルタイムディジタルビットストリームを入力として受信し、例えば、ＭＰＥＧは各パケットの最初のバイトが「４７」(１６進法)の値であると規定している。この所定の値によって、デコーダはパケットの開始を検出することができる。代替例として、パケット開始標識をパス２０７上の別個の外部信号として受信することができる。特定の用途によって、復号化システムは追加処理を用い、パケット開始標識を予め検出しビットストリームから抽出した後、その標識をパス２０７でビットストリーム解析器２００に提供してもよい。ビットストリームのパケットをＦＩＦＯ（先入れ先出し）メモリ２１０内に受け入れ、このメモリ２１０は少なくとも幾つかのデータパケットを格納するのに適した容量を有する。一実施形態では、ＦＩＦＯの深さは２１パケット分である。パケットの開始を検出すると、リアルタイムで動作しているカウンタ２３０は、パケット開始受信時間（パケット開始のタイムスタンプ）をレジスタ２３２に記録する。即ち、リアルタイムカウンタ２３０は、標準クロック、例えば、２７ＭＨｚの周波数で動作するクロックのサイクルをカウントする。パケットの開始を検出すると、カウンタ２３０の現在値をレジスタ２３２に複写する。レジスタ２３２をロードすると、割込コントローラ２３４はプロセッサ２４０に対して割込を発行し、別のパケット開始を検出したことを示す。レジスタ２３２及び割込コントローラ２３４はカウンタ２３０内にあるように図示されているが、これらはカウンタ２３０の外部に実装することができることは理解されるはずである。好適な実施形態において、プロセッサ２４０はマイクロプロセッサ、例えば、ＴＭＳ３２０Ｃ３１、即ち、「Ｃ３１」マイクロプロセッサ（テキサスインスツルメント(Texas Instruments)社製）である。割込コントローラ２３４からの割込に応じて、プロセッサ２４０はレジスタ２３２を読み出し、レジスタ値をタイムスタンプ記憶装置に記憶する。即ち、プロセッサはレジスタ内のタイムスタンプの直接記憶アクセス（ＤＭＡ）転送を行い、タイムスタンプはメモリ２５０内のテーブルの値としてプロセッサアドレス空間にメモリマッピングされる。メモリ２５０は、タイムスタンプテーブル（パケット受信時間のリスト）及び以下に説明する他のテーブルからなる種々のテーブル２５２Ａ及び２５２ｎを含む。ある数のＤＭＡ、例えば、２１個のＤＭＡが発生したとき、プロセッサは自身に割り込み、アドレスポインタをリセットする。また、プロセッサはＦＩＦＯ２１０からパケットを読み出し、パケットを読み出しながらパケットの構文解析を行う。パケットデータ及びパケットデータの着信を示すタイムスタンプを用いて、プロセッサはＰＣＲデータの正確度と正当性及びＳＩの着信間時間を検証することができる。プロセッサはリアルタイムに動作することができる、即ち、プロセッサは受信時間に対して一定遅延以内に各データパケットを処理することができる。リアルタイムの用途において、プロセッサ２４０が前のパケットを処理しディスプレイ２６０のリフレッシュ等の他のタスクを行うために必要な時間によって、バッファ２１０内のパケット数を時々変更することができる。プロセッサは、パケットデータをバッファ２１０から、受信時間をタイムスタンプテーブル２５２から読み出す。プロセッサ２４０で実行されるソフトウェアアプリケーション又は方法はタイムスタンプテーブル２５２の値を用いて、バッファ２１０に記憶されているパケットデータを処理し、パケットデータの受信時間の文脈内の時間要素を評価する。好適な実施形態では、他のタスクが２１個のパケットの時間を超える時間分パケット処理を遅延させない範囲でマイクロプロセッサに他のタスクを実行させながらリアルタイム動作に備える。ＦＩＦＯ（バッファ）コントローラ２２０は、再スタート時にＦＩＦＯをリセットし、ＦＩＦＯがいっぱいになった状態を測定してアンダフローを防ぎ、データからプロセッサ２４０へのクロック処理を制御することによって、ＦＩＦＯ２１０を制御する。即ち、プロセッサとＦＩＦＯの不一致をアドレス指定する潜在的なメモリのため、ＦＩＦＯコントローラはＦＩＦＯとプロセッサのインタフェースとして機能し、例えば、プロセッサからの読み出し許可信号（制御信号）をＦＩＦＯのサイクル外で適正なクロックに変換する。しかしながら、ＦＩＦＯコントローラ２２０が実行する機能をプロセッサ２４０内に実装することができることは理解されるはずである。最後に、ディスプレイ２６０をプロセッサに接続し、ビットストリーム解析器からの結果を表示する。ディスプレイによって、ユーザは多重化ビットストリームに対するリアルタイムビットストリーム解析を監視し実行することができる。図３は、リアルタイムビットストリーム解析を行う方法３００のフロー図を示す。より具体的には、方法３００は、ビットストリーム内の種々の時間要素、例えば、ＰＣＲデータの正確度と正当性及びＳＩの着信間時間を検証し監視する。一般に、信号のクロック基準を表すＰＣＲデータ（値）はビットストリームに定期的に現れる、例えば、ＰＣＲ値は０．１秒毎に約１回の割合でビットストリームに現れる場合がある。ビットストリームがＭＰＥＧのトランスポートストリームである好適な実施形態では、ＰＣＲ値は２７ＭＨｚの基準クロックの時を刻む。復号化システムは、ＰＣＲ値を適用してその「システム時間クロック」（ＳＴＣ）を導出することが期待され、ＰＣＲ値で表される符号化システムの時間クロックのトラッキングを行う。このため、本発明の方法が監視する幾つかの重要な側面は、パケットの不連続状態、ＰＣＲデータの時間ジッタ及びＰＣＲデータの着信間時間（ＰＣＲギャップ）を含む。更に、本発明の方法はＳＩの着信間時間の監視も行う。各側面については以下に詳細に検討する。図３を参照すると、方法３００はステップ３０５から始まり、ステップ３１０に進み、ここで、方法３００は、パケットデータを受信しＦＩＦＯ２１０で利用可能かどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法３００は現パケットのパケット識別子（ＰＩＤ）を示し、ステップ３１５に進む。ステップ３１０の問いの答えがＮＯの場合、方法３００はパケットを受信するまで待機する。ステップ３１５で、方法３００は、ＰＣＲデータを現パケット内で検出したかどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法３００はステップ３２０に進み、ここで、受信したパケットデータ内のＰＣＲがエンコーダからの連続するＰＣＲ列の一部かどうか、又は、そのＰＣＲがストリーム内の不連続＿標識ビットによって示される新しいＰＣＲ列の開始を示すかどうかを判断するため、問い合わせる。その問いの答えがＮＯの場合、方法３００はステップ３３５に進み、ここで、現パケットのＰＩＤがＳＩを搬送するパケットと相関関係があるかどうかを判断するため問い合わせる。ステップ３２０で、方法３００は現ＰＣＲが不連続状態かどうかを判断する。ＰＣＲ処理は、ＰＣＲフィールドを含むトランスポートパケットが不連続状態かどうかに依存する。ＰＣＲ処理を行う前、パケット及び適応フィールドのヘッダの読み出し及び解釈を行うことによって、各パケットが不連続状態かどうかを判断する。トランスポートパケットが不連続状態かどうかは、パラメータ「不連続＿標識」によって適応フィールド内で報告する。不連続状態が真の場合(ＰＣＲの不連続状態を許可する場合)、方法３００はステップ３３０に進み、ここで、不連続ＰＣＲ処理を行う。不連続状態が真でない場合(ＰＣＲの不連続状態を許可しない場合)、方法３００はステップ３２５に進み、ここで、通常の連続ＰＣＲ処理を行う。ステップ３２５で、パケット着信時間を現ＰＩＤのＰＣＲ時間基準を更新するための基準として用いる。この更新処理では、位相同期ループ（ＰＬＬ）の動作をシミュレートする。ＰＣＲ値と現ＰＩＤのＰＣＲ時間基準の差（時間ジッタ）を用いて、ＰＣＲ値が連続しているか、ＰＣＲ値が仕様（以下に検討するＰＣＲジッタ試験）の範囲内かを検証し、計算した着信時間を用いて、ビットストリーム内のＰＣＲフィールドの間隔が仕様（以下に検討するＰＣＲギャップ試験）の範囲内かどうかを試験する。ステップ３３０で、ＰＣＲ処理をシミュレートされたＰＬＬ動作の種々のパラメータのリセット処理に限定し、ＰＣＲギャップ試験のみを行う。不連続ＰＣＲ処理ではＰＣＲジッタ試験を行わない。ステップ３３５で、方法３００は、現パケットのＰＩＤがＳＩを搬送するパケットと相関関係があるかどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法３００はステップ３４０に進み、ここで、ＳＩ処理を行う。好適な実施形態では、ＳＩを搬送するパケットと相関関係があるＰＩＤ値は、ＤＶＢ規格に準拠するＰＩＤ１６、１７、１８、１９及び２０である。尚、他のＰＩＤ値が他の規格、例えば、ＡＴＳＣに基づいてＳＩを搬送してもよいことは理解されるはずである。このため、ＳＩパケットに関連するＰＩＤ値の設定を特定の実行に基づいて調整することができる。ステップ３３５の問いの答えがＮＯの場合、方法３００はステップ３５０に進む。一実施形態では、ＰＣＲデータ又はＳＩを搬送しないパケットをＦＩＦＯ２１０から読み出し破棄するだけである。ステップ３５０で、方法３００は、次のパケットを受信しそのパケットは処理の準備ができているかどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法３００はステップ３１５に戻る。問いの答えがＮＯの場合、方法３００は任意のステップ３６０に進み、ここで、１回の「走査」（又は次の走査）に対してバックグラウンド処理を行い、メモリ２５０に記憶されている種々のテーブルのエントリを１以上選択的に除去する。バックグラウンド処理方法を用いて、以下に検討するＰＣＲギャップ解析時に連続するすべてのＰＩＤのＰＣＲギャップを検証することもできる。例えば、ＰＩＤ値の範囲は８０００個を上回る場合がある。このようなＰＩＤ値の大幅な変動には、各ＰＩＤ値毎に関連するすべてのパラメータを記憶する大容量のメモリを必要とする。同一のＰＩＤ値のパケット受信間で長時間の遅延又は中止が生じる可能性があるので、バックグラウンド処理を用いて現ＰＩＤ値以外の値に関連するパラメータを除去することによって、プロセッサの計算オーバヘッド及びメモリ２５０のサイズ要求を低減することはコスト効率が高い。方法３００がバックグラウンド処理を完了すると、方法３００はステップ３５０に戻り、次のパケットを受信したかどうかを判断する。次のパケットを受信していなかった場合、方法３００は、次のパケットを受信するまで、次の走査等でバックグラウンド処理を続ける。図４は、連続ＰＣＲ処理方法３２５のフロー図を示す。即ち、方法３２５は図３のステップ３２５と関連する。図４を参照すると、方法３２５はステップ４０５から始まり、ステップ４１０に進み、ここで、方法３２５はＰＩＤに関連するパラメータを計算する。即ち、パラメータｔＰＣＲ、ｄＰＣＲ＿ＨＷ及びｄＰＣＲを計算又は設定する。パラメータｔＰＣＲは、現パケット又は現ＰＩＤの場合の現ＰＣＲの受信のタイムスタンプ値とする(各パケットは固有のＰＩＤによって定義されるから)。このため、ｔＰＣＲは下式（１）で表すことができる。 tPCR=BOP_CURRENT （１）ここで、ＢＯＰ_CURRENTは、現パケットの開始の着信時間（受信時間）のタイムスタンプと相関関係がある。しかしながら、数式（１）は推定値にすぎない。パラメータｔＰＣＲは下式（２）によってより正確に表すことができる。 tPCR=BOP_CURRENT+(BOP_LAST-BOP_CURRENT)^*(6/Packet_Length) （２）ここで、（ＢＯＰ_LAST−ＢＯＰ_CURRENT）は、パケット受信に必要な時間量、即ち、最後のパケットの開始と現パケットの開始の受信時間のタイムスタンプ値の差を示す。更に、Ｐａｃｋｅｔ＿Ｌｅｎｇｔｈは、パケット長、即ち、パケット内のバイト数、例えば、ＭＰＥＧの場合は１８８バイトを示す。ＭＰＥＧはパケットの６番目のバイトを受信した時間であるＰＣＲの時間を定義するため、数式（２）は必要である。しかしながら、多くの用途の場合、数式（１）による推定値で十分である。数式（２）を特にＭＰＥＧに合わせて調整することは理解されるはずである。このように、数式（２）を完全に調整又は置換し、他のビットストリーム規格を考慮することができる。パラメータｄＰＣＲ＿ＨＷは、現ｔＰＣＲとメモリに記憶されているのと同じＰＩＤ値の前のｔＰＣＲ＿ｌａｓｔ_pidの受信のタイムスタンプ値の差とする。このため、ｄＰＣＲ＿ＨＷは下式（３）で表すことができる。 dPCR_HW=tPCR-tPCR_last_pid （３）即ち、ｄＰＣＲ＿ＨＷは、同じＰＩＤ値のＰＣＲの連続受信の時聞（デコーダの局所時間）の差を示す。しかしながら、ｄＰＣＲ＿ＨＷは、デコーダクロックとエンコーダクロックの不一致を考慮しない。このように、パラメータｄＰＣＲは、現ｔＰＣＲと係数「ｆ_pid」によって調整された同じＰＩＤ値の前のｔＰＣＲ＿ｌａｓｔ_pidの受信タイムスタンプ値の差とし、尚、係数「ｆ_pid」は、エンコーダクロックとデコーダクロックの速度差の測定値である。「ｆ_pid」によって調整される周波数はＭＰＥＧの限界値内に制限される。このため、「ｆ_pid」は、局所時間基準とエンコーダの時間基準のクロック周波数差である。より具体的には、周波数オフセット値「ｆ_pid」は単位がなく、入力ＰＣＲ− 内部基準周波数／内部基準周波数で示される周波数で表される。これは、エンコーダクロックとデコーダクロックの比から１を引いた値に等しい。係数「ｆ」は公称で０になる。このため、ｄＰＣＲは下式(４)で表すことができる。 dPCR=dPCR_HW^*(1+f_pid) （４）項ｆ_pidを更に以下に定義する。このため、ｄＰＣＲは、同じＰＩＤ値の連続するＰＣＲの「修正」時間差である。図４に戻ると、ステップ４１５で、方法３２５は、計算したｄＰＣＲがしきい値、例えば、好適な実施形態では１ｍｓｅｃ未満かどうかを問い合わせる。問いの答えがＮＯの場合、方法３２５はステップ４２０に進む。問いの答えがＹＥＳの場合、方法３２５はステップ４６０に進み、ここでは、ＰＣＲ処理を行わない。即ち、ステップ４１５で、同じＰＩＤのＰＣＲの時間間隔が狭すぎる場合、方法３２５はこれらのＰＣＲを避け、プロセッサの計算オーバヘッドを低減させるだけである。プロセッサの計算オーバヘッドによって、しきい値を特定の実行に合わせて調整したり、ハードウェアの能力に同調させることができる。ステップ４２０で、方法３２５は、ＳＴＣ_pid、即ち、ｄＰＣＲを持つ特定のＰＩＤのシステム時間クロックを更新する。その結果生じる更新されたＳＴＣ_pi _d は現ＰＩＤの時間を示す。次に、更新されたＳＴＣ_pidを用いて、エラーパラメータ「ｅ」を計算し、ここで、エラ−ｅは、ＳＴＣ_pidと実際の現ＰＣＲ_CURRENT値、即ち、ビットストリームから読み出した現ＰＣＲの実際の数値の差を示す。このため、エラーｅは下式（５）で表すことができる。 e=PCR_CURRENT-STC_pid （５）尚、どのＰＣＲのジッタもＰＣＲを受信したときに測定した値「ｅ」で定義する場合がよくある。「ｅ」の単位は２７ＭＨｚのシステムクロックのカウントである。ｅが０の場合、デコーダクロックはエンコーダクロックと同期する。しかしながら、ｅが０でない場合、デコーダクロックはエンコーダクロックと同期せず、周波数オフセットｆ_pidをステップ４２５で計算し、不一致を考慮する。このため、ｆ_pidを下式（６）で表すことができる。 f_pid=(k^*e)+(G^*PLLstate_pid) （６）ここで、ｋ及びＧは定数であり、ＰＬＬｓｔａｔｅ_pidは積分器を示す。より具体的には、数式（６）は、図５に示すように、フィルタ５００によって表すことができる。フィルタは、定数乗算器ｋ５３０と、定数乗算器Ｇ５４０と、総和器５５０と、遅延５２２及び総和器５２４を有する積分器５２０とを備える。パス５１０上の値ｅ（０）〜ｅ（ｎ）をパス５９０上のｆ（０）〜ｆ（ｎ）に変換するフィルタ５００は、ＰＬＬ設計上の変形である。フィルタ５００は、ＰＣＲ同士の時間の長さが分からない点で、時間サンプルフィルタとは異なる。ｋ及びＧの値を選択し、ＭＰＥＧ２の最大ＰＣＲ間隔０．１秒までのすべての間隔に対して安定したフィルタを作成する。遅延の周囲に純粋な積分器を用いることによって、デコーダシステムとエンコーダシステムの間隔測定毎のクロック周波数が異なっていてもループが同様に動作することを保証する。但し、「ｋ」及び「Ｇ」はカウント^-1の単位を有さなければならず、この場合、一実施形態では、ｋを１／（２７，０００，０００^*０．１）に設定する。定数Ｇを０．１／（２７，０００，０００^*０．１）に設定する。このフィルタによって、「ＰＬＬトラッキング」動作を１秒以内で１％に安定させることができる。ＰＣＲ正確度試験を各不連続状態後の期間にマスクし、ＰＬＬを安定させてもよい。これらのｋ及びＧの特定の定数値をＭＰＥＧ２モード及びＭＰＥＧ２＋ＤＶＢモードの両方とともに用いることができる。しかしながら、異なる用途を考慮して他の定数値を用いることもできる。図６は、エラー「ｅ」を周波数オフセット「ｆ_pid」に変換するフィルタ６００の別の実施形態のブロック図を示す。この「ＰＬＬトラッキング」動作の第２の実施形態は、リミッタ又はクリッパ６１０を除いて、図５に示す実施形態とほぼ同じである。リミッタを統合ループに追加し、ＭＰＥＧ仕様に基づいて周波数オフセットを８１０Ｈｚ以内に維持する(即ち、エンコーダクロックとデコーダクロックの周波数差を３０ｐｐｍ以内に保つ)。「ｆ_pid」の正方向送り部（即ち、ｅ^*ｋ）は「時間不連続部」であり、好適な実施形態では、リミッタによってクリップされない。これによって、統合ループの安定性を向上させる。更に、外部クロックを用いる場合、一般に、外部クロックの正確度を絶対とすることによって、リミッタ６１０を３０ｐｐｍに設定することができる。しかしながら、一実施形態では３０ｐｐｍの正確度しか持たない内部クロックを用いる場合(即ち、外部クロックの正確度を絶対としない場合)、リミッタ６１０を少なくとも＋−６０ｐｐｍ（局所発振器の不正確度とＭＰＥＧの不正確度の和）に設定しなければならない。しかしながら、クロックの不正確度及び関連する規格が示す制約を考慮して、リミッタの設定を特定の用途に従って調整することができることは理解されるはずである。好適な実施形態では、遅延フィードバックのクリッピング値を、ｅ＝０の場合にｆ_pidが１００万当たりわずか６０部以下になるようにする。このため、クリッピングしきい値Ｃは下式（７）で表すことができる。 C=(許容限界/ゲイン_〜_f)=(60/1000000)/G （７）このため、Ｇ＝０．１／２７０００００の場合、Ｃ＝６００^*２７０００００／１００００００又は６０^*２７／１又は１６２０．０になる。しかしながら、外部クロックを用いる場合、その値は８１０．０になる。図４に戻ると、いったんｆ_pidを現ＰＩＤについて計算すると、方法３２５はステップ４３０に進み、ここで、現ＰＩＤに関連する種々のパラメータの現在の状態をメモリで更新する。例えば、今、現ＰＣＲの受信時間（即ち、ｔｐｃＲ）を最後のＰＣＲの受信時間（即ち、ｔＰＣＲ＿ｌａｓｔ_pid）として記憶する。他の記憶された状態はｆ_pid及びＰＬＬｓｔａｔｅ_pidを含む。ステップ４１０、４２０、４２５及び４３０をまとめて、ＰＩＤ毎に行われるシミュレートＰＬＬ動作（又は周波数トラッキング動作）と呼ぶことができる。即ち、周波数補正をＰＩＤ毎に計算しトラッキングする。ステップ４３５で、方法３２５はＰＣＲ＿ジッタ処理又は試験方法を行う。ＰＣＲ＿ジッタ処理では、現ＰＩＤのＰＣＲ値が連続しているか、関連する規格が定める制約の範囲内かどうかを検証する。ＰＣＲ＿ジッタ処理については以下に図７で説明する。ステップ４４０で、方法３２５はＰＣＲ＿ギャップ処理又は試験方法を行う。ＰＣＲ＿ギャップ処理では、同じＰＩＤの連続するＰＣＲ値の時間間隔（着信時間）が関連する規格が定める制約の範囲内かどうかを検証する。ＰＣＲ＿ギャップ処理については以下に図８で説明する。次に、方法３２５はステップ４４５から４５５に進み、これらのステップを用いて、統計解析を行う。即ち、ステップ４４５で、方法３２５は、ステップ４５０でジッタ及びＰＣＲ間隔（例えば、ｄＰＣＲ）のヒストグラムを更新するために特定のＰＩＤを選択するかどうかを問い合わせる。ジッタヒストグラムは種々の「ビン」を含み、この場合、各ビンは「ｅ」の値から求められたＰＣＲジッタのある値を表す。同様に、ＰＣＲ間隔ヒストグラムは種々の「ビン」を含み、この場合、各ビンはＰＣＲ間隔のある値を表す。ステップ４４５の問いの答えがＹＥＳの場合、方法３２５はステップ４５０に進み、ここで、ステップ４５５で指定した最後のＰＣＲのうち「ｘ」個、例えば、最後の５０個のＰＣＲに基づいてヒストグラムを更新する。ユーザはヒストグラムを再び呼び出し、特定のＰＩＤのジッタパターンやＰＣＲ間隔パターンを見ることができる。その後、方法３２５はステップ４６０で終了する。図７は、ＰＣＲ＿ジッタ処理方法４３５のフロー図を示す。即ち、方法４３５は図４のステップ４３５と関連する。図７を参照すると、方法４３５はステップ７０５から始まり、ステップ７１０に進み、ここで、方法４３５は絶対値ｅが０．７秒より大きいかどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法４３５はステップ７１５〜７４５に進み、ここで、方法４３５は、検出されていない不連続が発生したかどうかを判断する。問いの答えがＮＯの場合、方法４３５はステップ７２０に進み、ここで、方法４３５は、ＰＣＲジッタ処理の開始を保証するのに必要な数の現ＰＩＤの記憶ＰＣＲ値を受け取ったかどうかを判断する。ステップ７１５で、方法４３５は、「最後の不連続カウント」パラメータ（「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid」）が０に設定されているかどうかを問い合わせる。「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid」が０に設定されている場合、「ｅ」の計算に用いられた現ＰＣＲ値は現ＰＩＤの最初のＰＣＲ値である。即ち、問いの答えがＹＥＳの場合、方法４３５は、１つのＰＣＲ値がエラー係数「ｅ」を適正に生成することができないので不連続状態はないと判断する。このようにして、方法４３５はステップ７４５に進み、ここで、種々のパラメータ又は変数をリセットする。即ち、ＳＴＣ_pidを現ＰＣＲ値に設定し、エラー係数「ｅ」を０に設定し、ｆ_pidを０に設定し、ＰＬＬｓｔａｔｅ_pidを０に設定し、「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid」を１に増分する(不連続状態のない現ＰＩＤに対して少なくとも１つのＰＣＲ値を受け取ったことを示す)。問いの答えがＮＯの場合、方法４３５はステップ７２５に進み、ここで、方法４３５は、現ＰＩＤに対応する最後のパケットを受信してから「ドロップアウト」を検出したかどうかを問い合わせる。即ち、方法４３５は、ドロップアウトが発生した後、又は、例えば特にノイズの多い送信チャネルが被送信ビットストリームを干渉した期間の後、現ＰＣＲ値を受信したかどうかを判断する。換言すれば、報告されたドロップアウトによって、現ＰＣＲを最後のＰＣＲから分離する。通常、訂正方式、例えば、ブロック符号化又はたたみ込み符号化によってビットストリームの符号化を行うので、復号化システムは相補デコーダを用いてビットストリーム内のデータの誤り訂正を行う。誤り訂正方式がビットストリームを訂正することができない場合、復号化システムは、特定のＰＩＤに対して、エラーの影響を受けたパケット及びドロップアウト後のフラグにドロップアウト（不連続）が発生したと宣言する場合がよくある。このため、ステップ７２５の問いの答えがＹＥＳの場合、方法４３５はステップ７４５に進み、ここで、パラメータをいったん再びリセットする。ドロップアウトは既に予め報告されているので、方法４３５は不測の不連続状態を報告しない。しかしながら、ステップ７２５の問いの答えがＮＯの場合、方法４３５はステップ７３５に進み、ここで、ビットストリーム解析器によって、例えば、ディスプレイ２６０を介して不測の不連続状態を報告する。方法４３５は上記のイベントの１つが原因で「ｅ」の値が高くなったと判断することができないので、不測の不連続状態が発生したに相違ない。不連続状態を報告した後、方法４３５はステップ７４５に進み、ここで、パラメータをいったん再びリセットする。ステップ７２０で、方法４３５は、パラメータ「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid」が所定のしきい値、例えば、同じＰＩＤの１０個の連続するＰＣＲ値未満であるかどうかを問い合わせる。このようなしきい値を設定する目的は、ジッタ解析を行う前に、十分なＰＣＲ値を受信してＰＬＬトラッキング動作が信頼性の高い計算を行っているに相違ないことを確実に保証するためである。即ち、ＰＬＬ周波数トラッキング状態が正確であると判断することができるまでに、１０個のＰＣＲの待機時間を発生させる。尚、本発明は１０個のＰＣＲ値のしきい値に限定されず、特定の実施に合わせてこのしきい値を変更することができることは分かる。このため、ステップ７２０の問いの答えがＹＥＳの場合、方法４３５はステップ７３３に進み、ここで、パラメータ「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid 」を１だけ増加させ、方法はステップ７６０に進む。ステップ７２０の問いの答えがＮＯの場合、方法４３５はステップ７３０に進む。ステップ７３０で、方法４３５は、エラー係数「ｅ」がしきい値、例えば、６２０ｎｓｅｃより大きいかどうかを問い合わせる。尚、ＭＰＥＧではＰＣＲ許容限界を５００ｎｓｅｃより大きくないと規定しているのが分かる。しかしながら、本発明の一実施形態では、１２０ｎｓｅｃの測定の不正確度をＭＰＥＧの規定許容限界に加え、本発明のビットストリーム解析器の範囲内の不正確度を考慮に入れることができる。この追加した１２０ｎｓｅｃの不正確度を特定の実施によって変更することができることが分かる。ステップ７３０の問いの答えがＮＯの場合、方法４３５は、ＰＣＲ不正確エラーを報告することなく、ステップ７６０に進む。ステップ７３０の問いの答えがＹＥＳの場合、方法４３５はステップ７４０に進み、現ＰＩＤに対応する最後のパケットを受信してから「ドロップアウト」を検出したかどうかを問い合わせる。この問いはステップ７２５と同じ目的を果たす。ステップ７４０の問いの答えがＹＥＳの場合、方法４３５はステップ７６０に進む。ＰＣＲジッタに寄与する可能性がもっとも高いドロップアウトは既に予め報告されているので、方法４３５はＰＣＲ不正確エラーを報告しない。しかしながら、ステップ７４０の問いの答えがＮＯの場合、方法４３５はステップ７５０に進み、ここで、ビットストリーム解析器によって、例えば、ディスプレイ２６０を介してＰＣＲ不正確エラーを報告する。方法４３５は上記のイベントの１つが原因で「ｅ」の値が高くなったと判断することができないので、ＰＣＲ不正確エラーが発生したに相違ない。ＰＣＲ不正確エラーを報告した後、方法４３５はステップ７６０に進む。図８は、ＰＣＲ＿ギャップ処理方法４４０のフロー図を示す。即ち、方法４４０は図４のステップ４４０と関連する。図８を参照すると、方法４４０はステップ８０５から始まり、ステップ８１０に進み、ここで、方法４４０はｄＰＣＲ（ＰＣＲギャップ）が所定のしきい値未満かどうかを問い合わせる。即ち、ＭＰＥＧ規格は、ＰＣＲ値が１００ｍｓｅｃ毎に１回発生しなければならないという制約を規定している。しかしながら、他の規格に準拠するビットストリームに合わせてこの制約を変更することができる。好適な実施形態では、１ｍｓｅｃをＭＰＥＧの制約に追加し、数値の正確度の不正確度、例えば、丸め処理を考慮した。問いの答えがＮＯの場合、方法４４０は、ＰＣＲ＿ギャップエラーを報告することなく、ステップ８７０に進む。問いの答えがＹＥＳの場合、方法４４０はステップ８２０に進む。ステップ８２０で、方法４４０は、パラメータＰＣＲ＿Ｇａｐ＿ｆｏｕｎｄ_pi _d を設定するかどうかを問い合わせる。一般に、パラメータＰＣＲ＿Ｇａｐ＿ｆｏｕｎｄ_pidは「バックグラウンドＰＣＲギャップ処理」方法によって設定される。即ち、方法４４０は、一般に、特定のＰＩＤに対してＰＣＲを受信することによって生じる。このため、エンコーダが特定のＰＩＤに対する次のＰＣＲを長時間送らない場合、ビットストリーム解析器はその特定のＰＩＤに対するＰＣＲギャップエラーがあるかどうか調べない。このように、特定のＰＩＤに対してＰＣＲギャップが発生したが、長時間発生しないかもしれない次の遅延ＰＣＲを受信するまで、ビットストリーム解析器はエラーを検出することはできない。このため、バックグラウンドＰＣＲギャップ処理方法を用いて、すベてのＰＩＤを検証し、各ＰＩＤ毎に最後のＰＣＲが存在するかどうかを判断する。ＰＩＤ毎に最後のＰＣＲが存在する場合、バックグラウンドＰＣＲギャップ処理方法はその最後のＰＣＲを現在時間と比較する。その差が１０１ｍｓｅｃより大きい場合、そのＰＩＤが次のＰＣＲを更に受信しなければならないときでもＰＣＲギャップが発生したことを示すように、ＰＣＲ＿Ｇａｐ＿ｆｏｕｎｄ_pid を設定する。このため、ステップ８２０の問いの答えがＹＥＳの場合、エラーは既に報告されているので、方法４４０はＰＣＲギャップエラーを報告することなくステップ８３０に進む。しかしながら、ステップ８２０の問いの答えがＮＯの場合、方法４４０はステップ８４０に進み、現ＰＩＤに対応する最後のパケットを受信してから「ドロップアウト」を検出したかかどうかを問い合わせる。この問いは図７のステップ７２５と同じ目的を果たす。ステップ８４０の問いの答えがＹＥＳの場合、方法４４０はステップ８７０に進む。ＰＣＲギャップエラーに寄与する可能性がもっとも高いドロップアウトは既に予め報告されているので、即ち、不連続ストリームを検出しているので、方法４４０はＰＣＲギャップエラーを報告しない。しかしながら、ステップ８４０の問いの答えがＮＯの場合、方法４４０はステップ８５０に進み、ここで、ビットストリーム解析器によって、例えば、ディスプレイ２６０を介してＰＣＲギャップエラーを報告する。ステップ８３０で、方法４４０はＰＣＲ＿ＧＡＰＥＮＤを報告する。ステップ８３０で、実際のＰＣＲギャップを報告する、例えば、ＰＩＤ「ｘ」等に対して「ｘ」期間のＰＣＲギャップを検出した。即ち、方法４４０は、方法４４０を引き起こした次のＰＣＲを今受信してから、ＰＣＲギャップが終了したばかりであることも報告する。このため、ステップ８６０で、方法４４０はＰＣＲ＿Ｇａｐ＿ｆｏｕｎｄ_pidをリセットし、少なくともその瞬間ＰＣＲギャップエラーを解決したことを示す。その後、ステップ８７０で、方法４４０は終了する。図９は、連続しない（不連続）ＰＣＲ処理方法３３０のフロー図を示す。即ち、方法３３０は図３のステップ３３０と関連する。不連続状態を検出するが、ＰＣＲギャップエラーがないかどうか監視することにも有益である。図９を参照すると、方法３３０はステップ９０５から始まり、ステップ９１０に進み、ここで、方法３３０は種々のパラメータをリセットする。即ち、ｄＰＣＲ＿ＨＷをｔＰＣＲ−ｔＰＣＲ＿ｌａｓｔ_pidに等しく設定し、ｔＰＣＲをＢＯＰ_CURRENTに等しく設定し、ＳＴＣ_pidを現ＰＣＲ値に設定し、エラー係数「ｅ」を０に設定し、ｆ_pidを０に設定し、ＰＬＬｓｔａｔｅ_pidを０に設定し、「ｌａｓｔ＿ｄｉｓｃｏｎｔ＿ｃｎｔ_pid」を１に増分する(不連続状態のない現ＰＩＤに対して少なくとも１つのＰＣＲ値を受け取ったことを示す)。ステップ９２０で、方法３３０は、メモリ内の現ＰＩＤに関連する種々のパラメータの現在の状態を更新する。例えば、現ＰＣＲの受信時間（即ち、ｔＰＣＲ）を最後のＰＣＲの受信時間（即ち、ｔＰＣＲ＿ｌａｓｔ_pid）として記憶する。ステップ９３０で、方法３３０は、上記図８のＰＣＲギャップ処理又は試験方法を行う。ＰＣＲギャップ処理では、同じＰＩＤの連続するＰＣＲ値の時間間隔（着信時間）が関連する規格が規定する制約の範囲内かどうかを検証する。最後に、方法３３０は、上記のステップ４４５〜４５５と同じ任意のステップ９４０〜９６０に進む。再び、これらのステップは、ユーザが見ることができるヒストグラムを提供する。図３に示す本発明は、サービス情報「ＳＩ」処理方法を含む。即ち、ＤＶＢ（ディジタルビデオ放送）信号は、ビデオデータ及び音声データを含む幾つかの多重化情報ストリームからなる。また、この信号は、これらの情報ストリームの復号化の定義及び制御に用いられる幾つかのストリームも含む。これらの制御ストリームを２つのグループに分ける。即ち、プログラム特定情報「ＰＳＩ」をＭＰＥＧ規格で定義し、情報ストリームの基本的定義を下す。一方、サービス情報「ＳＩ」をＤＶＢ規格で定義し、ユーザにとって使い易い情報ストリームに関する情報を提供する。ＳＩ情報は、ネットワーク構成、ネットワーク上のサービス、イベントの説明及びイベントの実行状態（例えば、「午後７時３５分から始まり６０分続く」）に関する情報を含む。他のより曖昧な構造はチャネルの「格付け」を含み、時間帯オフセットも送ることができる。多重化情報ストリームは数百のプログラムを含むこともでき、各プログラムは、それぞれ、ＰＳＩ情報テーブル及びＳＩ情報テーブルにそれ自身のエントリを有する。セットトップボックスのオーバロードを防ぐため、システム設計者は、制御ストリームの情報の関連するサブセットを選択する方法を指定することができる。データストリームを「フィルタ」で処理し、ストリームの一部のみがフィルタを通過し、セットトップボックスのマイクロプロセッサによって処理される。フィルタリング方法によって、デコーダボックスは、ストリームのどの部分（即ち「セクション」）でも選択し、解釈することができる。このように、デコーダボックスのマイクロプロセッサは、現在興味のないチャネルの制御情報を処理する必要はない。しかしながら、どんなセットトップボックスもいつでもいかなるプログラムの制御情報も処理することができることは重要である。このため、各規格はＰＳＩ及びＳＩの送信速度に関する制約を規定している。これらの制約によって、フィルタリング回路及びマイクロプロセッサが情報のオーバロード状態になることを防ぐ。ＭＰＥＧ委員会は、バッファに関する制約によってＰＳＩのオーバロードを防ぐことを決定した。ＤＶＢ組織は異なる手法を採用し、反復速度、より正確には、ＳＩ情報の関連セクションの着信間時間を制限することによって、ＳＩのオーバロード防止を行う。具体的には、ＤＶＢ仕様ｐｒＥＴＳ３００〜４６８の５．１．４（１９９６年５月）の（一部）には、「このＥＴＳの範囲内で規定したＳＩの場合、同じＰＩＤｔａｂｌｅ＿ｉｄ及びｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎと同じ又は異なるｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒを持つ次の送信セクションの最初のバイトに対するセクションの最後のバイトの着信の最小時間間隔は２５ｍｓｅｃである」と言及している。図１０は、リアルタイムシステム、例えば、上記図２に示すビットストリーム解析器においてＳＩの関連セクションの着信間時間の一致を測定する方法３４０のフロー図を示す。即ち、方法３４０は図３のステップ３４０と関連する。但し、ＥＴＳ又はＭＰＥＧのＰＳＩテーブルで指定したＳＩを、トランスポートストリームパケットに挿入する前に、１以上の「セクション」にセグメント化する。「セクション」とは、このＥＴＳで指定したＭＰＥＧ２テーブル及びＳＩテーブルのすべてをトランスポートストリームパケットにマッピングするために用いられる構文構造である。本発明の方法が検証するＳＩテーブルは、ネットワーク情報テーブル(ＮＩＴ、ＰＩＤ１６で示される)、サービス説明テーブル／格付け関連テーブル(ＳＤＴ／ＢＡＴ、ＰＩＤ１７で示される)、イベント情報テーブル(ＥＩＴ、ＰＩＤ１８で示される)、実行状態テーブル（ＲＳＴ、ＰＩＤ１９で示される）及び時間日付テーブル／時間オフセットテーブル（ＴＤＴ／ＴＯＴ、ＰＩＤ２０で示される）を含む。但し、セクションは、１つのパケット内に多くのセクションを受け取ることができるように、逆に言えば、１つのセクションが多くのパケットにわたってまたがるように種々の長さを有する。事が更に面倒になると、各ＳＩテーブルは多くの異なる種類のセクションを搬送する可能性があり、例えば、ＥＩＴは最大１１８万種類のセクションを搬送することができる。各セクションを識別するため、「特定子」の組み合わせを用いて、各種類のセクションを独自に識別する。例えば、「ｔａｂｌｅ＿ｉｄ」及び「ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ」は２つの例である。図１０を参照すると、方法３４０はステップ１００５から始まり、ステップ１０１０に進み、ここで、方法３４０は現ＰＩＤ値が何かについて問い合わせる。この時点で、現パケットは既に読み出されている、即ち、図３のステップ３１０でパケットを受信したと仮定する。このステップで、５つの考え得るＰＩＤ値１６〜２０は、これらの値が５つのＳＩテーブルと相関関係がある場合、求めることができる。このため、ステップ１０１０で、方法３４０は１０１２〜１０１６の５つのパスのうちの１つに進むことができる。図１０は１つの完全なパス１０１２を図示しているにすぎないが、すべてのパスが異なる種類のセクションが各パスで進むことを除いて同じであることが分かる。ステップ１０２０で、方法３４０は現ＰＩＤの現在の状態について問い合わせる。３つの状態が考えられ、これらは「処理中」１０２２、「処理を行っていない」１０２４及び「部分的なヘッダ処理」１０２６である。要するに、「処理中」状態１０２２は、現ＰＩＤのセクションが現在処理されていることを示す。即ち、このＰＩＤの前のパケットに対するパケット終わり標識に出会う前に、「セクションの終わり」（ＥＯＳ）を検出しなかった。このように、関連するＥＯＳを走査するまで、方法３４０はＳＩ処理を続ける。「処理を行っていない」状態１０２４は、現在、現ＰＩＤのセクションは１つも処理されていないことを示す。即ち、このＰＩＤの前のパケットに対するパケット終わり標識に出会う前に、「セクションの終わり」（ＥＯＳ）を検出した。「部分的なヘッダ処理」状態１０２６は、あるセクションが処理中であるとともに、このＰＩＤの前のパケットに対するパケット終わり標識に出会う前に、そのセクションの特定子を完全に得たわけではないことを示す。このようにして、方法３４０は、残りのセクションのヘッダを走査することによって、ＳＩ処理を開始する。ステップ１０５０で、方法３４０はセクションの開始を測定する。あるセクションがあるパケットの最初の１つである場合、パラメータ「ｐｏｉｎｔｅｒ＿ｆｉｅｌｄ」を用いてそのセクションを見つけることができる。このパラメータは、パケット内に存在する最初のセクションの最初のバイトの位置を示す。ステップ１０５１で、方法３４０はセクション開始受信時間Ｔ_sosを計算する。具体的には、図２の本発明のビットストリーム解析器は、トランスポートパケットＴ_BOP(n)の開始着信時間及び次のパケットＴ_BOP(n+1)の着信時間を与える。これによって、「セクション開始時間」Ｔ_sosと、セクション終わり時間Ｔ_Eosと、これらの間のバイト時間数とを知ることによって、パケット内のどのバイトの到着時間も推定することができる。２０４バイト／パケット間隔モードにおいて、バイトｋは下式（８）で着信する。 T_k=T_BOP(n)+(k/204)^*(T_BOP(n+1)-T_BOP(n)) （８）本システムは、２つの異なるモード、１８８バイト／パケットモード又は２０４バイト／パケットモードで動作することができる。何れかのモードにおいて、ｋを下式（９）によって求めることもできる。 k=188-(パケットに残ったバイト) （９）ＳＩ情報をセクションに分割し、これらのセクションはパケットと一致していない。ＳＩのセクションを以下のように処理する（すべてのセクションがｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ＝＝１を有すると仮定する）。ステップ１０５２で、方法３４０はセクション特定子全体を現パケットから抽出することができるかどうかを問い合わせる。この問いの答えがＹＥＳの場合、方法３４０はステップ１０５４に進み、ここで、セクション特定子、例えば、「ｔａｂｌｅ＿ｉｄ」及び「ｔａｂｌｅ＿ｉｄ＿ｅｘｔ」を、それぞれ、メモリ内の「ｌａｓｔｔａｂｌｅ＿ｉｄｆｏｕｎｄ」及び「ｌａｓｔｔａｂｌｅ＿ｉｄ＿ｅｘｔｆｏｕｎｄ」に記憶する。問いの答えがＮＯの場合、方法３４０はステップ１０６８に進み、ここで、関連するセクション特定子又はその部分、例えば、「ｔａｂｌｅ＿ｉｄ」及び「ｔａｂｌｅ＿ｉｄ＿ｅｘｔ」(Ｔ_sosを含む)を、それぞれ、メモリ内の「ｌａｓｔｔａｂｌｅ＿ｉｄｆｏｕｎｄ」及び「ｌａｓｔｔａｂｌｅ＿ｉｄ＿ｅｘｔｆｏｕｎｄ」に記憶する。方法３４０がセクション特定子の全体を読み出すことができない主な理由は、セクションヘッダを２つのパケットに分割したからである。即ち、方法３４０がステップ１０７０でパケット終わり標識にである前に、セクション特定子を一部だけ読み出した。ステップ１０５８で、方法３４０は、メモリ２５０内部に格納されているテーブルから前のセクションのＴ_Eosを得る。ステップ１０６０で、方法３４０は、Ｔ_Eos−Ｔ_sosが２５ｍｓｅｃより大きいかどうか問い合わせる。問いの答えがＹＥＳの場合、方法３４０はステップ１０３０に進む。問いの答えがＮＯの場合、方法３４０はステップ１０６２に進み、ここで、ビットストリーム解析器によってＳＩ間隔エラーを報告する。方法３４０はステップ１０３０に進み、現在のセクションの終わり又はパケットの終わりを走査する。ステップ１０３２で、方法３４０パケット終わり標識に出会ったかどうかを問い合わせる。問いの答えがＹＥＳの場合、方法３４０はステップ１０４６に進み、ここで、現ＰＩＤの状態を「処理中」に設定し、方法３４０はステップ１０４２で終了するか、パケット終わり標識に出会う。問いの答えがＹＥＳの場合、方法３４０はステップ１０３４に進み、ここで、方法３４０はｋを用いてＴ_Eosを計算し、ステップ１０３６で、Ｔ_Eos、を「ｌａｓｔｔａｂｌｅ＿ｉｄ及びｌａｓｔ＿ｔａｂｌｅ＿ｉｄ＿ｅｘｔ」に基づいたテーブルに記憶する。ステップ１０３８で、方法３４０は現パケット内にこれ以上セクションがあるかどうかを問い合わせる。問いの答えがＮＯの場合、方法３４０はステップ１０４０に進み、このステップでは、状態を「処理を行っていない」に設定し、すべての詰め込みビットを破棄した後、ステップ１０４２に進み、ここで、方法３４０は終了するか、パケット終わり標識に出会う。問いの答えがＹＥＳの場合、方法３４０はステップ１０５０に進み、ここで、パケット終わり標識に出会うまで処理を再び繰り返す。ステップ１０２６に戻ると、方法３４０がＰＩＤ状態を「部分的なヘッダ処理」状態と判断すると、方法３４０はステップ１０８０に進み、ここで、セクションヘッドの残りを読み出す。次に、方法３４０はステップ１０５６に進み、ここで、Ｔ_sosを計算し、方法３４０は上記のように進む。図１０は５つ全てのＳＩテーブルに適合可能な一般的なフロー図として示されているが、以下、各ＳＩテーブルに関する特定のＳＩセクション要件を指摘する。尚、ＮＩＴテーブル（ＰＩＤ１６）は以下の３種類のセクションしか許容しない。ネットワーク＿情報＿セクション−実際のネットワーク（ｔａｂｌｅ＿ｉｄ＝０ｘ４０）ネットワーク＿情報＿セクション−他のネットワーク（ｔａｂｌｅｉｄ＝０ｘ４１）詰め込み＿セクション（ｔａｂｌｅ＿ｉｄ＝０ｘ７２）ＳＩの場合、詰め込み＿セクションを調べる必要はない(これはすべてのＳＩＰＩＤに当てはまる)。「ｎｅｔｗｏｒｋ＿ｉｄ」と呼ばれるｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎの値は０〜０ｘＦＦＦＦまでのどの値も取ることができる。ｔａｂｌｅ＿ｉｄとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎのあり得る組み合わせは１２８ｋであるが、ｎｅｔｗｏｒｋ＿ｉｄは実際のネットワークと他のネットワークの両方にあり得ない。このため、６４ｋのＴ_Eos及び１つのＴ_sosだけをトラッキングしなければならない。尚、テーブルＳＤＴ／ＢＡＴ（ＰＩＤ１７）は以下の種類のセクションを許容する。サービス＿説明＿セクション−実際の＿トランスポート＿ストリーム（ｔａｂｌｅ＿ｉｄ＝０ｘ４２）サービス＿説明＿セクション−他の＿トランスポート＿ストリーム（ｔａｂｌｅ＿ｉｄ＿０ｘ４６）格付け＿関連＿セクション（ｔａｂｌｅ＿ｉｄ＝０ｘ４Ａ）詰め込み＿セクション（我々は無視している）(ｔａｂｌｅ＿ｉｄ＝０ｘ７２) このため、２つのテーブル、ＳＤＴ及びＢＡＴはこのＰＩＤを共有する。これらのテーブルは、それぞれ、６４ｋのエントリを有しうる。ＮＩＴの場合のように、２種類のＳＤＴが重なり合うことはあり得ない。ＳＤＴの場合、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎはｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄである。ＢＡＴの場合、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎはｂｏｕｑｕｅｔ＿ｉｄである。これらの２つのテーブルを見失わないようにトラッキングするため、メモリの１２８ｋを割り当て、Ｔ_Eos値を保存する。尚、テーブルＥＩＴ（ＰＩＤ１８）は以下の種類のセクションを許容する。イベント＿情報＿セクション−実際の＿トランスポート＿ストリーム，現在の／以下の（ｔａｂｌｅ＿ｉｄ＝０ｘ４Ｅ）イベント＿情報＿セクション−他の＿トランスポート＿ストリーム，現在の／以下の（ｔａｂｌｅ＿ｉｄ＝０ｘ４Ｆ）イベント＿情報＿セクション−実際の＿トランスポート＿ストリーム，スケジュール（ｔａｂｌｅ＿ｉｄ＝０ｘ５０−０ｘ５Ｆ）イベント＿情報＿セクション−他の＿トランスポート＿ストリーム，スケジュール（ｔａｂｌｅ＿ｉｄ＝０ｘ６０−０ｘ６Ｆ）詰め込み＿セクション（我々は無視している）(ｔａｂｌｅ＿ｉｄ＝０ｘ７２) ＥＩＴセクションでは、ｔａｂｌｅ＿ｉｄは最大１８個の異なる値を取ることができる。ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎは、ｓｅｒｖｉｃｅ＿ｉｄと呼ばれる最大６４ｋの値を取ることができる。ｓｅｒｖｉｃｅ＿ｉｄは所定のｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍのプログラムマップテーブル（ＰＭＴ）のｐｒｏｇｒａｍ＿ｎｕｍｂｅｒと同じである。ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒは各ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ毎に固有でなければならないが、その番号は幾つかのストリームで再利用することができる。ＮＩＴ又はＳＤＴ等の直接テーブルを維持する場合、メモリの１８^*６４ｋ又は１．１８メガワード必要である。一実施形態では、図３で説明したバックグラウンド処理３６０（アドレス指定）方法を用いて、６４０ｋワードしか使わず、利用可能な全部で１．１８メガワードをアドレス指定した。バックグラウンド処理方法は以下の特徴を有する。第１に、最近の１０２４個のｓｅｒｖｉｃｅ＿ｉｄしか監視しない。即ち、所定の時間、例えば、１０秒以内に特定のｓｅｒｖｉｃｅ＿ｉｄに対して情報が送られない場合、バックグラウンド処理方法は監視したｓｅｒｖｉｃｅ＿ｉｄのリストからｓｅｒｖｉｃｅ＿ｉｄを除去する。第２に、各ｓｅｒｖｉｃｅ＿ｉｄはどんな有効なｔａｂｌｅ＿ｉｄも持つセクションを含むことができる。他のｔａｂｌｅ＿ｉｄに関係なく、各ｔａｂｌｅ＿ｉｄのＴ_Eopを監視する。第３に、バックグラウンド処理方法は、２つの構造及び幾つかの変数を維持することによって、テーブルに対して３２ｋ＋３５^*１ｋのメモリ位置しか必要としない。具体的には、３２ｋのメモリ位置は６４ｋの指数値のパックアレイであり(即ち、ｓｅｒｖｉｃｅ＿ｉｄに対して６４ｋの値)、指数は０〜１０２３の間の値であり、２を３２ビットのワードにパックしたものである(Ｄワード)。このアレイはｓｅｒｖｉｃｅ＿ｉｄと構造名のリンクを提供する。それはＳｔｒｕｃＮｕｍ［ｓｅｒｖｉｃｅ＿ｉｄ］と呼ばれる。アレイ内で使用されていない値をＮＯＴ＿ＩＮ＿ＬＩＳＴに設定する。構造の１０２４要素アレイは、所定のｓｅｒｖｉｃｅ＿ｉｄに対して各ｔａｂｌｅ＿ｉｄ毎にＴ_Eosを保持する。この第２のアレイはＳｔｒｕｃ［ｉｎｄｅｘ］と呼ばれる。この構造の部分をＳｔｒｕｃ［ｉ］部と呼ぶ。「部」とは、「Ｃプログラム言語」の場合と同様に、構造エントリである。このアレイ内で使用されていない構造はリンクリストを形成し、「第１の自由構造」変数はリストの先頭を示し、「ｆｉｒｓｔ＿ｆｒｅｅ」と呼ばれ、指数として機能する。即ち、リンクリストをＳｔｒｕｃＮｕｍ［ｓｅｒｖｉｃｅ＿ｉｄ］アレイ内で作成し、次の自由構造を示す。バックグラウンドでは、構造アレイを検索し、もう使用されていないセクションをクリアする。この検索で示すべき場所を決定する変数はｎｅｘｔ＿ｓｃａｎ＿ｖａｌｕｅである。これも指数である。一時的な変数を１つ記憶し、幾つかの処理の高速化に用いる。これは、ハードウェアアドレスである「ＴｅｍｐＰｏｉｎｔｅｒ」である。尚、「ＴＩＭＥ」はバイトの着信時間のフォーマットである。それは２７ＭＨｚのクロックで表される。「ＳＥＲＶＩＣＥ＿ＩＤ」は１６ビットの数であり、３２ビットのＤワードの底部の１６ビットに記憶される。「ＩＮＤＥＸ」は構造アレイ内の構成要素を示す数である。システムが上記図３のような実行すべきタスクをこれ以上持たないときはいつでも、例えば、入力ＦＩＦＯが処理すべきトランスポートパケットを含まないときはいつでも、バックグラウンド処理方法を行ってよい。このバックグラウンド処理方法は「ｗｈｉｌｅループ」を持たないので、リアルタイムシステムで機能する。また、この方法は、直接的手法と比較して、メモリ使用率の大きな利点も備えている。尚、テーブルＲＳＴ（ＰＩＤ１９）は以下の２種類のセクションしか許容しない。実行＿状態＿セクション（ＲＳＴ）（ｔａｂｌｅ＿ｉｄ＝０ｘ７１）詰め込み＿セクション（我々は無視している）(ｔａｂｌｅ＿ｉｄ＝０ｘ７２) 実行＿状態＿セクションはｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを持たないので、すべてのＲＳＴセクションに対してＴ_Eosの値を１つだけ維持すればよい。それが詰め込み＿セクションでない場合、受信した前のセクションを調べる。尚、テーブルＴＤＴ（ＰＩＤ２０）は以下の種類のセクションを許容する。時間＿日付＿セクション（ＴＤＴ）(ｔａｂｌｅ＿ｉｄ＝０ｘ７０) 詰め込み＿セクション（我々は無視している）(ｔａｂｌｅ＿ｉｄ＝０ｘ７２) 時間＿オフセット＿セクション（ＴＯＴ）(ｔａｂｌｅ＿ｉｄ＝０ｘ７３) ＴＯＴもＴＤＴも１つしかセクションを含まない。ＴＤＴに１つ、ＴＯＴに１つで、Ｔ_Eosの値を２つ維持しなければならない。ＳＩ試験システムの全メモリ要件を以下の表にまとめる。本発明の教示を含む種々の実施形態を図示し詳細に説明してきたが、当業者であれば、これらの教示をまだ含む他の多くの変更した実施形態を容易に考案することができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＪＰ，ＫＲ

Claims

【特許請求の範囲】１.複数のパケットを有するビットストリームを評価する装置であって、前記パケットが時間要素を搬送し、前記装置が、前記複数のパケットのうちの１以上のパケットを受信するバッファと、前記バッファに接続された、受信したパケットに対して複数のタイムスタンプを記録するカウンタであって、前記タイムスタンプが各々前記パケットのうちの１つのパケット受信時間を記録するカウンタと、前記バッファに接続されて、前記カウンタからの前記タイムスタンプを用いて、前記パケットが搬送した時間要素を評価するプロセッサと、を備えたビットストリーム評価装置。２．前記プロセッサに接続された、前記カウンタからの前記複数のタイムスタンプを記憶するためのメモリを更に備えた請求項１記載の装置。３．前記タイムスタンプの各々が、前記パケットのうちの１つのパケットの開始の受信時間を記録する請求項１記載の装置。４．前記プロセッサが前記時間要素を解析して、サービス情報（ＳＩ）の着信間時間を検出する請求項３記載の装置。５.複数のパケットを有するビットストリームを評価する方法であって、前記パケットが時間要素を搬送し、前記方法が、ａ）前記複数のパケットのうちの１以上のパケットをバッファに受信するステップと、ｂ)前記受信したパケットに対して複数のタイムスタンプを記録して、前記タイムスタンプの各々が前記パケットのうちの１つのパケットの受信時間を記録するステップと、ｃ）プロセッサを使用して、前記タイムスタンプを用いて前記パケットが搬送した時間要素を評価するステップと、を備えるビットストリーム評価方法。６．ｄ）前記複数のタイムスタンプをメモリ内のテーブルに記憶するステップを更に備える請求項５記載の方法。７．前記タイムスタンプの各々が、前記パケットのうちの１つのパケットの開始の受信時間を記録する請求項５記載の方法。８．前記プロセッサは前記時間要素を解析し、プログラムクロック基準（ＰＣＲ）ジッタを検出する請求項５記載の方法。９．前記プロセッサは前記時間要素を解析し、サービス情報（ＳＩ）の着信間時間を検出する請求項５記載の方法。１０．複数のパケットを有するビットストリームの復号及び評価を行うための復号化システムにおいて、前記パケットが時間要素を搬送し、前記システムがは、デコーダと、前記デコーダに接続されたビットストリーム解析器と、を備え、前記ビットストリーム解析器が、前記複数のパケットのうちの１以上のパケットを受信するバッファと、前記バッファに接続され、受信したパケットに対して複数のタイムスタンプを記録するカウンタであって、前記タイムスタンプの各々が前記パケットのうちの１つのパケットの受信時間を記録する、カウンタと、前記バッファに接続されて、前記カウンタからの前記タイムスタンプを用いて、前記パケットが搬送した時間要素を評価するプロセッサと、を備えた復号化システム。