(57)【特許請求の範囲】
【請求項１】
パケットタイプを識別するパケット・アイデンティティ（ＰＩＤ）を含むパケットのヘッダデータからデータ部分を抽出し，データ入力ストリームから更なるデータ（データ１）を抽出するシフトレジスタと，
シフトレジスタに接続され，前記データ部分によってアドレス指定される連想メモリであって，該連想メモリは，前記データ部分に対応するパケットタイプがパケットタイプの所定の部分集合と一致するかどうかを示す一致データ（ＶＡＬＩＤ−ＰＩＤ）を格納し，前記一致データが一致を示すなら，対応するパケットタイプに対する基準データ（ＣＡＭ−ＡＤ）をさらに格納し，前記データ部分によってアドレス指定された時，もし前記一致データが一致を示すなら，前記一致データと前記基準データを出力するために前記データ部分を出力する，連想メモリと，
前記連想メモリと接続され，該連想メモリが基準データを出力するなら，前記基準データに応答して，前記基準データに対応するアドレス（ＳＲＡＭ−ＡＤ）を発生するアドレス・ゼネレータと，
前記アドレス・ゼネレータと接続され，前記基準データの各々に対する属性データ（データ２）を格納するメモリ（ＳＲＡＭ）と，
前記メモリと前記シフトレジスタとに接続され，前記一致した基準データに関連して選択された属性データ（データ２）と前記シフトレジスタにより供給される更なるデータ（データ１）に応答して前記パケットを処理する方法を決定する論理回路
とを含むパケット認識処理回路。
【請求項２】
前記シフトレジスタから前記論理回路へのデータパス（データ１，パケット・アナライザ制御レジスタ）を含み，前記基準データに応答して前記更なるデータを前記論理回路に供給する請求項１に記載のパケット認識処理回路。
【請求項３】
前記データパスが，シフトレジスタに接続されたデータ入力と前記連想メモリに接続された負荷イネーブル入力（ＡＦ−ロード）とを有する更なるレジスタ（パケット・アナライザ制御レジスタ）を含み，前記基準データおよび負荷イネーブル信号に応答して前記更なるデータ（データ１）をロードし，前記更なるレジスタは前記論理回路に接続されたデータ出力を有する，請求項２に記載のパケット認識処理回路。
【請求項４】
前記更なるレジスタは前記メモリと接続された更なるデータ入力（データ２）を有し，前記選択された属性データを受け取る，請求項３に記載のパケット認識処理回路。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＭＰＥＧ２デコーダに関し、特に、デコーダなどの中で使うためのＩＭＰＥＧ２トランスポート・ストリーム・パケット・パーザ（ｐａｒｓｅｒ）に関する。
【０００２】
【従来の技術、及び、発明が解決しようとする課題】
ディジタルＴＶデコーダは次の５つのモジュールに分割することができる。
復調
ＭＰＥＧトランスポート・パケット・パーザ（ＴＰＰ）
ＭＰＥＧオーディオ
ＭＰＥＧビデオ
ＲＩＳＣマイクロコントローラ
ＭＰＥＧ２トランスポート・ストリーム・パーザ（ＴＰＰ）はＭＰＥＧのトランスポート・ストリームを受信し、ビデオ、オーディオまたはサービス情報のパケットを選択する。デコードの後、そのパケットはメモリ・バッファに格納されてデータ・ストリームを形成する。オーディオ・デコーダはＭＰＥＧのオーディオ・ストリームを処理し、アナログのオーディオ信号を生成する。ビデオ・デコーダはＭＰＥＧのビデオを復元（ｄｅｃｏｍｐｒｅｓｓ）し、ビデオ・シーケンスを発生する。
【０００３】
＜トランスポート・パケットのフォーマット＞
トランスポート・パケット（図１）は１８８個のバイトを含む。このパケツトは２つの部分、すなわち、３２ビットのヘッダおよび１８４バイトのペイロード（ｐａｙｌｏａｄ）に分けられる。トランスポート・ヘッダは異なるフィールド（ＰＩＤ、ペイロード・ユニット・スタート・インジケータ、アダプテーション・フィールド・フラグ、連続性カウンタのインデックス）を含み、それによってトランスポート・パケットのパーザが粗いフィルタリングを行う。トランスポート・ヘッダの後、パケットは可変長のアダプテーション・フィールドまたはペイロードを含む可能性がある。これらのペイロードのいくつかはそれ自身ヘッダ（ＰＥＳヘッダ）から始まり、それも可変長である（図１参照）。ＭＰＥＧ２の標準規格におけるＰＥＳヘッダは１つのパケットより大きくなる可能性がある（次のパケットの上にオーバフローする）。
【０００４】
現代水準のＭＰＥＧ２トランスポート・ストリーム・システム・アナライザは完全なトランスポート・ストリーム・ハードウェア・アナライザおよびマイクロプロセッサを含んでいるチップ・セット・ソリューションから構成される。ビデオおよびオーディオのデコーダは、図２に示されているように別のデバイスの中にある。トランスポート・ストリーム・パーザは現在の方式によってトランスポート・ストリームのフル解析（約７０ｋゲート）を担当し、ＣＰＵに対してはデータを正しい方向に向けるタスクおよび異なるモジュールを制御するタスクを残している。もう１つのソリューションはすべてのトランスポート解析をソフトウェアで実装することである。これはずっと高いＣＰＵパワーの処理を必要とする。
【０００５】
【課題を解決するための手段】
プリプロセッシングの後に関連するフラグが付いているパケットを含めるための中間バッファと、送信フラグによって選択されたパケットをさらにソフトウェアで処理するためのプロセッサとを含んでいる、トランスポート・ストリーム・パーザ・システム。
【０００６】
【発明の実施の形態】
本発明のトランスポート・ストリーム・パーザは解析をより効果的にするために、トランスポート・ストリームおよびＭＰＥＧ２の解析の負荷をハードウェアとソフトウェアとの間で分割する。ハードウェアのフィルタリングによってＰＩＤの認識に基づいて早期の決定ができるので、データ・ストリームを非常に効果的に削減することができ、一方、ファームウェアはその削減されたデータ・ストリーム上で、より複雑なフィルタリングのアルゴリズムを実行する。この方式はリソースを最適化する。ハードウェアは単純になり、一方、ファームウェアはＣＰＵパワーがより少なくて済む。というのは、受け取るビット・レートがハードウェアによってあらかじめ処理されているからである。
パケットのパーシング（ｐａｒｓｉｎｇ）およびルーティングは、各ＰＩＤに対してローカル・メモリの中に格納されている一組の属性と結合されているＰＩＤ認識機構によって行われる。これらの属性によって異なるヘッダから受信された情報が完成される。
【０００７】
＜トランスポート・パケット・パーザの機能＞
このモジュールの機能はアプリケーションによって選択されないすべてのパケットを即時に捨てることであり、そして組み込みのソフトウェアからの「リアル・タイム」の支援なしに、できるだけ多くのパケットを回送することである。
有効なＰＩＤを持つパケットが検出されると、パーザはそのパケットがＣＰＵによってさらに処理される必要があるかどうかを決定する条件の集合をチェックする（「ＥＯＰ割込み発生」の詳細説明参照）。これらの条件の１つが満足されていた場合、そのパケットは付加されたフラグと一緒に一時バッファへ送られ（さらに処理が必要である）、そしてＥＯＰ割込みがＣＰＵへ送られて新しいパケットが受信されていることを示す。この一時バッファの中に記憶されたデータは、図３のパス（２）の中で示されているように回送されるか、あるいは捨てられるかが行われる前に、組込みソフトウェアによって処理される。データが処理されると、ＲＩＳＣはそれらを自分自身で転送するか、あるいはシステム・バスへのＤＭＡ転送を起動する。また、そのソフトウェアは或る場合においてＰＩＤ属性（例えば、ストリーム−ｉｄフィルタ）のいくつかを変更し、それに続くパケット（同じＰＩＤの）のルーティングを変更しようとする。どの条件も満足されなかった場合、付加されたフラグは追加の処理が不要であることを示す。そのパケットは自動のＤＭＡ転送を経由してその最終の宛先へ自動的に転送される（パス（１））。例えば、圧縮されたビデオ情報を含んでいるパケットは直接システム・ビデオ・バスへ送ることができる．．．）。この場合、ＥＯＰ割込みがＲＩＳＣへ送られることなく、パケットの最終宛先に対する転送はＣＰＵのリソースを必要としない。
【０００８】
図３は２つのデータ・フローを示している。
【０００９】
このメカニズム（図３）はハードウェア／ソフトウェア解析の間のトレードオフのためのキーである。トランスポート・ストリーム・パーザは非常に容易にそのパケットを回送することができ、そして「トランスポート・ストリーム・ソフトウェア解析」の説明の中で示されているように、そのビット・ストリームの或る部分についてＣＰＵにより複雑な解析を行わせることができる。
その選択はヘッダ（ＰＩＤ、ＡＦフラグ、ＰＥＳ／ＰＳＩスタート・フラグ［ペイロード・ユニット・スタート・インジケータ］、トランスポート・エラー・フラグ、カウンタの連続性インデックス）を解析することおよび、ＰＩＤ属性を解析することによって行われる。というのは、その選択はパケット自身から情報を抽出することによって必ずしも常に行われるとは限らないからである（図４）。場合によっては、以前のパケット（同じＰＩＤの）の性質によって、そのパケットが追加の処理（ＰＥＳヘッダが２つのパケットの間で分離する）を必要とするかどうかが決定される。場合によっては、それはＰＩＤ番号にリンクされる。ＰＩＤが、例えば、常にＣＰＵの処理を必要とするテーブル情報を含んでいる場合、その属性Ｓｐｅｉがセットされる（このＰＩＤを持つパケットは常にＣＰＵへ送られることを意味する）。ＥＯＰ割込みを発生するために使われる情報のリストが以下の図４の中に要約されている。
この図は情報がどこから来るかを示している。ＥＯＰを発生するための条件は後で詳細に説明される。
【００１０】
＜パケット・アナライザ制御レジスタのビットの説明＞
Ｖａｌｉｄ ＰＩＤ（有効ＰＩＤ）：このビットはＰＩＤ認識機能の結果を示す。そのＰＩＤ番号は各パケットのトランスポート・ストリーム・ヘッダの中で受信されたパケット識別番号である。それはパケットがシステムに対して転送されなければならないかどうかを決定する。ＰＩＤ番号が選択された場合、このＶａｌｉｄ ＰＩＤビットはこのＰＩＤ番号を持つパケットが受信された時にアクティブ「１」になる。それは第１レベルのパケット・フィルタリングであり、そして他の解析ステップに対する必要条件である。
【００１１】
Ｔｅ（トランスポート・エラー・インジケータ）：これはトランスポート・ストリーム・パケット・ヘッダから検索される。トランスポート・エラー指示ビットは受信されたパケットが何らかのエラーを含んでいる時にアクティブになる。
Ｐｅｓ／Ｐｓｉ ｓｔａｒｔフラグ（トランスポート・ストリーム・ペイロードのスタート・ユニット・インジケータ）：これはトランスポート・ストリーム・パケットのヘッダから検索される。
トランスポート・ストリームのペイロードがＰＥＳパケット・データを含んでいる時。「１」はこのトランスポート・ストリーム・パケットのペイロードがＰＥＳパケットの第１バイト（ＰＥＳヘッダ）から始まることを示し、「０」はトランスポート・ストリーム・パケットの中でＰＥＳパケットが開始しないことを示す。
【００１２】
トランスポート・ストリーム・パケットのペイロードがＰＳＩデータを含んでいる時。「１」はそのペイロードが少なくとも１つのＰＳＩセクションの先頭を含んでいることを意味し、そして「０」はこのトランスポート・ストリーム・パケットの中でＰＳＩセクションのスタートが含まれていないことを意味する。
ＡＦ ｆｒａｇ（トランスポート・ストリーム・アダプテーション・フィールド）：トランスポート・ストリーム・ヘッダの中のこの２ビットのフィールドは、そのトランスポート・ストリーム・ヘッダの後にアダプテーション・フィールドが続いているかどうかを示す。
【表１】
0004049863.tif 000002
【００１３】
ＣＣ−ｅｒｒｏｒ（ＣＣのエラー）：このビットは連続性カウンタ（ＣＣ）におけるハードウェアの不連続性カウンタ検出機能の結果である。その検出はＣｕｒｒｅｎｔ ＣＣ（現在のＣＣ）と呼ばれるＣＣ（４ビットがトランスポート・ストリーム・ヘッダの中に含まれている）と同じＰＩＤ（Ｐｒｅｖｉｏｕｓ ＣＣ（前のＣＣ）と呼ばれる）の前のパケットからのＣＣとの間の比較によって行われる。Ｐｒｅｖｉｏｕｓ ＣＣはハードウェアによって変更された属性である。その比較が行われると、ハードウェアはそのＰｒｅｖｉｏｕｓ ＣＣを次のパケットの受信のためにＣｕｒｒｅｎｔ ＣＣで書き換える。以下同様に行われる。その比較が、Ｃｕｒｒｅｎｔ ＣＣ＝Ｐｒｅｖｉｏｕｓ ＣＣまたはＣｕｒｒｅｎｔ ＣＣ＝Ｐｒｅｖｉｏｕｓ ＣＣ＋１の条件にマッチしなかった場合、ＣＣ ｅｒｒｏｒビットがアクティブになる。
【００１４】
Ｄｕｐｌｉｃａｔｅ−ｐａｃｋｅｔ（パケット複製）フラグ：比較がｃｕｒｒｅｎｔ ＣＣ＝Ｐｒｅｖｉｏｕｓ ＣＣであることを示した場合、このＤｕｐｌｉｃａｔｅ−ｐａｃｋｅｔフラグがアクティブになる。
Ｈｐｅｉ（ハードウェアのパケット・エンド・イネーブル割込み）。これはハードウェアによってセットされる属性ビットである。新しいパケットの受信時（パケット・ユニット・スタート・インジケータがアクティブである時およびそれがプログラム・サービス情報ＰＳＩを持つパケットでない時）、Ｈｐｅｉがアクティブになり、同じＰＩＤの次のパケットにおいてリセットされる。それはＰＥＳヘッダが２つのパケット間で分割される場合に、さらに解析されるようにＰＥＳヘッダを持つパケットに続くパケットを一時的にバッファの中に記憶させる。このビットは入力ビット・ストリームのビット・レートが高過ぎてＥＯＰサービス・ルーチンのラテンシー（ｌａｔｅｎｃｙ）の範囲内にフィットしない時に必要である。
【００１５】
Ｓｐｅｉ（ソフトウェアのパケットの終りイネーブル割込み）：この属性ビットはソフトウェアによってセットされ、２つの異なる目的をカバーする。第１の使用では、このビットはＣＰＵ処理を常に必要とするＰＩＤに対して初期化時にセットされる（例えば、テーブル情報を持つＰＩＤ）。それはそのケースにおいてはこのＰＩＤのすべてのパケットがＣＰＵによって解析されるように強制するために単純に使われる。
第２の使用法はＰＥＳヘッダが２つのパケット間で分割されるオーディオおよびビデオのパケットに対する場合である。これはソフトウェアがそのビット・ストリーム・レートとそのラテンシー応答がコンパチブルであると判定した時にいくつかの与えられたシステムに対してだけ有効である。その場合、ソフトウェアはＰＥＳヘッダを含んでいるパケットのＥＯＰ割込みを受け取ると直ぐにＳｐｅｉをセットする。後でソフトウェアはその次のパケットにおいてＰＥＳヘッダがオーバフローするかどうかを判定する。オーバフローしない場合、ソフトウェアはＳｐｅｉ属性ビットをリセットする。この場合、Ｓｐｅｉは効率を良くするためにディスエーブルされるＨｐｅｉを置き換えることができる（Ｅｎ Ｈｐｅｉ参照）。
【００１６】
ＰＳＩ（プログラム・サービス情報パケット・フラグ）：ＭＰＥＧ２のトランスポート・ストリームにおいて、トランスポート・ストリーム・ヘッダの中の１つのフラグ（ペイロード・ユニット・スタート・インジケータ）が新しいＰＥＳパケットのスタートまたはプログラム・サービス情報のセクションのスタートを示す。これらの２つのタイプのデータを区別するために、別の属性（ＰＳＩ）が必要である。この属性はプログラム・サービス情報（ＰＳＩ）を含んでいるＰＩＤに対する初期化時に、ファームウェアによってセットされる。
それはＨｐｅｉを発生するために使われるが、さらに重要なことは、暗号化されたバイト／クリーンなバイトの間の境界の検出のために使われる。ＰＩＤに密に結合されているこの情報なしでは、コントローラは暗号化フラグを見つけることができず、あるいはビット・ストリーム・インターフェース上で意味のあるいくつかの入力バッファなしでオン・タイムで、暗号化されたバイト／クリーンなバイトの間の境界を見つけることもできない。
Ｓｔｒｅａｍ−ｉｄ−ｆｉｌｔｅｒ（ストリームｉｄフィルタ）；このソフトウェア属性ビットはソフトウェアが選択されていないストリームｉｄを持つＰＥＳヘッダを含んでいるパケットを受信した時に、ソフトウェアによってセットされる。この属性がセットされると、ハードウェアは新しいＰＥＳヘッダに達するまでペイロードを含んでいるこのＰＩＤ（ＡＦ＝“１ｘ”のすべてのパケットを捨てる。そのパケットはＣＰＵへ送られ、ＣＰＵはＰＥＳヘッダを解析して、その新しいストリームｉｄが有効であるかどうかを判定する。有効であった場合、ＣＰＵはそれに続くパケットに対するストリームｉｄフィルタをリセットする。
【００１７】
＜グローバル制御ビットの説明＞
Ｅｎ Ｈｐｅｉ：Ｈｐｅｉのメカニズムはシステムの制約によってスイッチ・オフ／オンすることができる。次のパケットを受信する前にソフトウェアが反応してＳｐｅｉ属性ビットを変更するのに十分な時間があると判定した場合、Ｈｐｅｉ属性をディスエーブルすることができる。その場合にはそのビット・ストリームのパーシングはより効率的である。というのは、ＰＥＳヘッダが付いているパケットに続くパケットは、ＰＥＳヘッダが１つのパケットの中に完全には含まれていない時にＣＰＵにさらに解析させるためにＣＰＵへ送られるだけだからである。
Ｅｎ ｅｒｒｏｎｅｏｕｓ ｐ：このグローバル制御ビットはエラーのあるパケットを一時バッファへ転送することができる。これは将来において何らかの新しいエラー隠蔽（ｃｏｎｃｅａｌｍｅｎｔ）対策が発見される可能性がある場合において、或る程度に柔軟性を追加するのが主な目的である。
Ｅｎ ｄｕｐｌｉｃａｔｅ ｐ：このグローバル制御ビットはペイロードだけを含んでいる複製パケットを送信できるようにする。これはテストの目的のためだけに使われる。
【００１８】
＜ＴＰＰハードウェアの実装＞
次の図（５）はＰＩＤの認識に基づいたハードウェアの実装を示す。トランスポート・パケットのヘッダからのＰＩＤは連想メモリの中にある一組のＰＩＤ（３２）と並列に比較される。ヘッダの中のＰＩＤが連想メモリの中のＰＩＤに格納されているＰＩＤに対応している場合、ＣＡＭエンコーダは単独のシステム・クロック期間において「マッチ」信号（Ｖａｌｉｄ−ＰＩＤ）およびＣＡＭアドレス（ｃａｍ−ａｄ）を出力する。ｖａｌｉｄ−ＰＩＤはトランスポート・システム・パケットの解析を開始するために使われ、それによってプロセスがトランスポート・ストリーム・ヘッダから入ってくる他のビット、ＡＦ−ｌｏａｄ（トランスポート・エラー、ペイロード・ユニット・スタート・インジケータ、アダプテーション・フィールド・フラグ、連続性カウンタ・インデックスおよび他の同様な暗号化フラグが解読モジュールの制御のために予約されている）をロードすることができる。有効なＰＩＤが検出されると直ぐに、ｃａｍ−ａｄがその関連する属性を探すために使われる。シーケンサがＲｅａｄ−ＳＲＡＭ属性を発生してＳＲＡＭのアドレス・ゼネレータを制御するステート・マシンをさせる。そのステート・マシンはｃａｍ−ａｄからＳＲＡＭのアドレスを生成し、そのＳＲＡＭを二度読む。一度はハードウェア属性を検索し、そして二度目はソフトウェア属性（スプリットしているハードウェアによって修正された属性およびソフトウェアによって修正された属性は複雑な保護メカニズムを使うことを避ける）を読む。両方から、ＥＯＰ割込みを発生するための条件である属性およびビット・ストリーム情報（ヘッダからのビット）が評価される。ハードウェア属性はその後、次のパケット（同じＰＩＤの）を受信するために更新される。ソフトウェア属性はＥＯＰ割込みサービス・ルーチンの一部として更新することができるが、それは或る非常に正確な機能（例えば、ストリームｉｄフィルタ）のためだけである。次のパケットのスタートの前に属性が変更される必要がある場合、ビット・レート、パケット間のギャップおよび割込みサービス・ルーチンのラテンシーがその変更を許すためのいくつかの制約条件を満足していなければならない。
パケット・アナライザの制御ビット（図４）に依存して、パケットは捨てられるか、自動的にその最終の宛先へ送信されるか、あるいは組み込まれているソフトウェアによって事前に処理される。ＥＯＰ割込みを発生するためのこれらの条件の１つが満足された時、その割込みを制御しているビットがアクティブになり、そして次のパケットの第１バイトにおいてリセットされる。ＥＯＰ割込みによって、パケットの終りに対して相対的な割込みの位置を制御することができる。ＥＯＰ割込みを発生する各種の条件（図５：論理ブロック）が説明される。
【００１９】
＜１−エラーのパケット＞
Ｉｆ（Ｔｅ＝１）
ｉｆ（Ｅｎ ｅｒｒｏｎｅｏｕｓ ｐ＝１）
それをＥＯＰする
ｅｌｓｅ
「パケットを捨てる」
ｅｎｄ  ｉｆ
普通はエラーを含んでいるパケットは捨てられるが、或る場合には完全なパケットを削除するよりも小さなエラーを許容するほうがシステムにとって妨害が少なくなる可能性がある。その場合、そのパケットはバッファへ転送され、ファームウェアがそのパケットのタイプ（ビデオ、オーディオなど．．．）によって変わる最終の決定を行う。
【００２０】
＜２−不連続性の検出＞
ｅｌｓｉｆ（Ｃｕｒｒｅｎｔ ＣＣ＝Ｐｒｅｖｉｏｕｓ ＣＣ）
「パケットを複製する」
ｉｆ（（ＡＦ＝“０１”）ａｎｄ（Ｅｎ ｄｕｐｌｉｃａｔｅ ｐ＝０）
「パケットを捨てる」
ｅｌｓｅ
それをＥＯＰする
ｅｎｄ  ｉｆ
ｅｌｓｉｆ（Ｃｕｒｒｅｎｔ ＣＣ／＝Ｐｒｅｖｉｏｕｓ ＣＣ＋１）
それをＥＯＰする
ＥＯＰパケット割込みは不連続性カウンタ検出の後に発生される。ＭＰＥＧ２においては、ＣＣの不連続性はアダプテーション・フィールドの中の不連続性フラグがセットされている時に可能である。後で示されるように、アダプテーション・フィールド付きのパケットはすべてＥＯＰ割込みを発生する。普通はペイロードだけを含んでいる（ＡＦ＝“０１”）の複製パケットは捨てられる。グローバル制御ビットＥｎ ｄｕｐｌｉｃａｔｅ ｐがセットされている場合は、それらを組込みのソフトウェアへ転送してに最終の決定を行わせることができる。
【００２１】
＜３−他の条件のリスト＞
ｅｌｓｉｆ（ＡＦ＝“１ｘ”）
それをＥＯＰする
ｅｌｓｉｆ（Ｐａｙｌｏａｄ ｕｎｉｔ ｓｔａｒｔ ｉｎｄｉｃａｔｏｒ＝１）
それをＥＯＰする
ｅｌｓｉｆ（Ｈｐｅｉ＝１）ａｎｄ（Ｅｎ Ｈｐｅｉ＝１）
それをＥＯＰする
ＥＯＰ割込みは次の場合に発生される。
−アダプテーション・フィールドを含んでいるすべてのパケット
−ペイロード・ユニット・スタート・インジケータがセットされているすべてのパケット
−ペイロード・ユニット・スタート・インジケータがセットされているパケットに続くすべてのパケット。これはＰＥＳヘッダが２つ以上のパケットを取ることができるので重要である。Ｓｐｅｉを十分早期ににセットできる場合、この機能をイネーブルまたはディスエーブルすることができる（以下の図６参照）。
ｅｌｓｉｆ（Ｓｐｅｉ＝１）
それをＥＯＰする
−組み込まれているソフトウェアがさらに解析が必要と判断したすべてのパケット
ｅｌｓｉｆ（ＡＦ＝“０１”ａｎｄ（（（Ｈｐｅｉ＝０）ａｎｄ（Ｅｎ Ｈｐｅｉ＝１））ｏｒ（Ｓｐｅｉ＝０））ａｎｄ（ｓｔｒｅａｍ−ｉｄ＝１））
「パケットを捨てる」
ｅｌｓｅ
「パケットは自動的に転送される」
ｅｎｄ  ｉｆ
−組み込まれているソフトウェアによってパケットが解析されることを強制する属性がセットされていない限り、ストリームｉｄがアクティブである場合は、ペイロードだけを含んでいるすべてのパケットが捨てられる（前のケース）。
注：このアルゴリズムの中で順次に評価されているこれらの条件は、実際にはすべてハードウェアによって並列に計算される。
ＥＯＰの割込み条件が満足されると、組み込まれているＲＩＳＣプロセッサがその解析のタスクを行う。
【００２２】
＜トランスポート・ストリームのソフトウェア解析＞
マイクロプロセッサはトランスポート・パケット・パーザのハードウェア・モジュールよりさらに複雑な解析を実行することができ、ハードウェアのプリプロセッシングを完成する。さらに、その処理はそのパケットに対応するデータのタイプにしたがって異なる可能性がある。実際に、使われるべき特定のアルゴリズムにそのパケットを関連付けるソフトウェア・テーブルを、ＰＩＤの値に基づいて定義することは非常に簡単である。
トランスポート・パケットのソフトウェア処理は割込みによって駆動される。ＥＯＰ割込みが発行されると、そのパケットを解析するプロセスが開始される。ＣＰＵのラテンシー応答およびビット・ストリームのレートにしたがって、２種類の処理を選択することができる。
第１のケースにおいてソフトウェアはＰＥＳヘッダを含んでいるパケットのＥＯＰ割込みを受信するとすぐに、ＴＰＰハードウェア・モジュールの中のＳｐｅｉフラグをセットする。そのパケットを処理した後、ソフトウェアはそのＰＥＳヘッダがその次のトランスポート・パケットの中に続いているかどうかを検出することができる。ＰＥＳヘッダが現在のパケットで終っている場合、ＣＰＵはパケット・アナライザの制御レジスタの中のＳｐｅｉビットをリセットする。というのは、次のパケットを解析する必要がないからである。それ以外の場合、Ｓｐｅｉビットはそのまま変わらずに残される。この方法が使えるのは、入力のビット・レートと比較してＣＰＵのラテンシーに余裕があって、次のパケットが到着する前にＳｐｅｉをセットできる場合だけである。
【００２３】
反対に、第２の方法はどんな場合においても使うことができる。Ｅｎ Ｈｐｅｉビットがパケット・アナライザの制御レジスタの中でセットされている場合、ＣＰＵは各ＰＥＳヘッダの後のＳｐｅｉビットをセットする必要はない。というのは、ＰＥＳヘッダの連続性を含んでいるパケットをＴＰＰのハードウェアが既にＡＲＭプロセッサに対して送信することを提供しているからである。
その後、ＴＰＰハードウェア・モジュールのレジスタの中のフラグを読むことによってその割込みの理由が調べられる。その場合、アダプテーション・フィールドが処理される。
アダプテーション・フィールドの解析の後、そのペイロードのうちのどのペイロードも前のパケットからの複製されたものでない場合に、そのパケットを捨てることができる。
この時点で、ソフトウェア・プロセスの実行はバケットのタイプ（オーディオ、ビデオ、プライベート・データ、サービス情報、．．．）にしたがって、別のルーチンへ分岐する。次に、そのデータがＤＭＡチャネルを経由して特定のバッファヘ転送される。
これはパケットを解析するために使うことができるアルゴリズムである（図６参照）。次のリストの中の最初のポイント（Ｐｅｓ／Ｐｓｉスタート・フラグのチェックおよびＳｐｅｉフラグのセット）はオプションである。
【００２４】
実際、前に説明されたように、ソフトウェアのラテンシーが十分に短くて、ＴＰＰハードウェア・モジュールが次のトランスポート・パケットを解析する前にソフトウェアがＳｐｅｉビットをセットすることができる場合、この動作によってＣＰＵの介入が最小化される。ＰＥＳヘッダの開始に続くパケットが実際に処理されなければならない場合だけ、マイクロプロセッサに対してＥＯＰ割込みが送られる。
それ以外の場合、到着しているストリームのビット・レートとＣＰＵのラテンシーが高過ぎる場合、Ｈｐｅｉメカニズムをイネーブルすることができる（Ｅｎ Ｈｐｅｉ＝１）。ＰＥＳヘッダの開始点に続く同じＰＩＤの次のパケットは常にＣＰＵへ転送される。
【００２５】
パケット・アナライザ制御レジスタ：パケット・ステータス・ワード（図４参照）の中のＰｅｓ／Ｐｓｉスタート・フラグを読むことによって、現在のトランスポート・パケットの中でＰＥＳヘッダがスタートするかどうかチェックする。ＰＥＳヘッダが現在のトランスポート・パケットの中でスタートする場合、パケット・アナライザ制御レジスタの中のＳｐｅｉビットが、同じＰＩＤの次のパケットを割り込ませるためにＣＰＵによってセットされなければならない。実際問題として、ＰＥＳヘッダは次のトランスポート・パケットの中に継続する可能性がある。
【００２６】
パケット・アナライザ制御レジスタ：パケット・ステータス・ワード（図４参照）の中のＡＦフラグを読むことによって、アダプテーション・フィールドの存在をチェックする。
アダプテーション・フィールドがそのパケットの中に転送される場合、その関連するデータが処理されなければならない。特に、基準クロックの再構築を制御するためにＰＣＲが抽出されてフィルタされなければならない。別の重要な部分は不連続性ステータスの解析から構成される。アダプテーション・フィールドの中の不連続性ステータス・ビットがセットされていた場合、その連続性カウンタの値における不連続性は欠落しているパケットには対応しない。不連続性のステータスがセットされていた場合、ＰＣＲの値（存在している場合）に対してローカル・クロックを初期化し直さなければならない。
【００２７】
パケツト・アナライザ制御レジスタ（図４参照）の中の複製パケット・フラグを読むことによって、そのパケットが複製されているかどうかをチェックする。
そのパケットが複製されていた場合、それは捨てられる。というのは、他の処理は不要だからである。ＰＥＳヘッダが存在していてＨｐｅｉの方法が使われないのでパケットの開始時点でＳｐｅｉビットが変更されていた場合、Ｓｐｅｉビットはそのプロセスの終る前にクリアされなければならない。
【００２８】
パケット・アナライザ制御レジスタ（図４参照）の中のＡＦフラグ読むことによって、そのパケットがトランスポート・ペイロードを含んでいるかどうかチェックする。
ペイロードがない場合（アダプテーション・フィールドだけの場合）そのパケットは捨てられる。というのは、他の処理は不要だからである。
【００２９】
＜パケット・タイプをチェックする＞
この部分のアルゴリズムは、実行されるべき特定の処理に対して選択された各ＰＩＤを関連付けるテーブルに基づいている。この方法で、そのパケットは関連のルーチンによって処理される。そのテーブルは３２個のエントリーを含んでいる。それぞれが可能な選択された各ＰＩＤに対応している各エントリーによって、そのパケットのタイプ（すなわち、オーディオ・パケット、ビデオ・パケット、ＰＥＳプライベート・デート、ＰＳＩなど）およびそのデータが格納されなければならないメモリのアドレスを識別することができる。特に、そのパケットのタイプがビデオ・ストリームまたはオーディオ・ストリームに対応していて（一般に自動ＤＭＡ転送に対応していて）、Ｈｐｅｉのメカニズムが使われない場合、そのパケットを処理した後、ＳｐｅｉビットはＰＥＳヘッダが終了している場合はクリアされなければならない。
【００３０】
＜ＤＭＡ転送を開始する＞
処理後のデータは最後に特定のメモリ・バッファへ転送される。
完全なアルゴリズムが図６に示されている。黒のモジュールはＨｐｅｉメカニズムがディスエーブルされている場合にだけ実行されるアルゴリズムの論理ブロックに対応している。
例：ＰＥＳシンタックスを解析しないビデオ・デコーダに対するトランスポート・ストリーム。
【００３１】
この場合、ビデオのエレメンタリ・ストリームだけがビデオ・デコーダへ送られる。ＰＴＳの値が抽出されて、ビデオ・デコーダのレジスタの中に書き込まれる。ＰＥＳヘッダの中に含められている可能性がある他のフィールドはどれも考慮されない。というのは、それはＤＶＢ勧告によって許されているからである。図７はＰＥＳパケットの構造を示している。
次のアルゴリズムはＰＥＳパケットを処理するために使われる。ＰＥＳヘッダの最初の部分はその対象とするフィールドを処理するために一時バッファの中に格納される。異なるパケットの中にヘッダが分割されている場合、第２のパケットが受信された後そのプロセスは継続し、そしてそのヘッダの最初のバイトが一時バッファの中に書き込まれなければならない。
【００３２】
この例はＰＥＳ解析に関連する部分だけを説明する。ＣＰＵ処理の他の部分については、上記のアルゴリズムが適用される。
ＴＰＰハードウェア・モジュールのＰＩＤ選択をイネーブルする前に、ＴＰＰ制御レジスタのフラグが次のように初期化される。
Ｅｎ ｅｒｒｏｎｅｏｕｓ ｐ＝０  エラーを含んでいるパケットが捨てられる。
Ｅｎ ｄｕｐｌｉｃａｔｅ ｐ＝０  アダプテーション・フィールドを含んでいない複製されたパケットが捨てられる。この場合、そのペイロードは前のパケットのペイロードと同じである。
Ｓｐｅｉ＝０  ＣＰＵの介入なしの自動転送：そのパケットは前のセクションの中で説明された条件が発生した時だけ、ＣＰＵによって横取りされる。
ｓｔｒｅａｍ−ｉｄ  ｆｉｌｔｅｒフラグ＝０  ストリームｉｄフィールドについてのフィルタは不要である。
ＰＳＩフラグ＝０  ビデオ・ストリームはＰＳＩセクションによって転送される、ＰＥＳシンタックスを使うことによって転送される。
Ｅｎ Ｈｐｅｉ＝１  Ｈｐｅｉメカニズムがイネーブルされている。
【００３３】
このアルゴリズムは次の擬似コードによって説明することができる。
ＰｅｓＳｔａｔｕｓは前のステータスのＰＥＳヘッダ処理のステータスを示す（０＝ＰＥＳヘッダが終了している；１＝ＰＥＳヘッダが前のパケットから継続していて、まだ解析されていない；２＝ＰＥＳヘッダは前のパケットから継続していて、すべての有用なフィールドは既に解析されている）。
ＰｒｅｖｉｏｕｓＳｉｚｅは前のパケットの中で解析されたＰＥＳヘッダの長さを示し、そして更新の後、前のパケットの中で解析されたＰＥＳパケットのサイズに現在のトランスポート・パケットの中に含まれているＰＥＳパケットのサイズを加えたサイズを示す。
ｉｆ（ＣＣ−ｅｒｒｏｒフラグ＝１）ａｎｄ
（不連続性ステータス＝ＴＲＵＥ）
「エラーの隠蔽（ｃｏｎｃｅａｌｍｅｎｔ）を開始する」
【００３４】
連続性カウンタのエラーがあるが、その不連続性は許されない。前のパケットのいくつかが欠落している。この場合、エラーの隠蔽の適切な方法が開始されなければならない。
ｉｆ（ＰＥＳ／ＰＳＩ  ｓｔａｒｔフラグ＝０）ａｎｄ
（ＰｅｓＳｔａｔｕｓ＝０）
「転送されるデータの開始点をアレンジする」
このパケットの中にはＰＥＳヘッダはない：すべてのペイロードが転送されなければならない。
ｅｌｓｉｆ（ＰｅｓＳｔａｔｕｓ＝２）
ＰＥＳヘッダの連続性があるが、すべての有用なフィールドが前のパケットの中で解析されている。
ＰａｙｌｏａｄＬｅｎｇｔｈ＝１８４−Ａｆｌｅｎｇｔｈ
バイト単位でのペイロードの長さを計算する：ペイロード・サイズはトランスポート・パケット・サイズ（１８４バイト）からアダプテーション・フィールドの長さを引いた値である。
ＰｒｅｖｉｏｕｓＳｉｚｅ＝ＰｒｅｖｉｏｕｓＳｉｚｅ＋ＰａｙｌｏａｄＬｅｎｇｔｈ
サイズを更新する。
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜ＰＥＳパケットの長さ）
「ノー・オペレーション」
ＰＥＳヘッダはこのパケットの中では終了しない：というのは、ＰＥＳペイロードがまだ始まっておらず、データが転送される必要がないからである。
ｅｌｓｅ
ＰｅｓＳｔａｔｕｓ＝０
「転送されるべきデータの開始点をアレンジする」
ＰＥＳヘッダはこのパケットにおいて終了する；ＰＥＳペイロードが転送されなければならない。
ｅｌｓｅ  ＰｅｓＳｔａｔｕｓは２に等しくない：ＰＥＳヘッダはまだ解析されていない。
ＰａｙｌｏａｄＬｅｎｇｔｈ＝１８４−Ａｆｌｅｎｇｔｈ
バイト単位でペイロードの長さを計算する：ペイロードのサイズはトランスポート・パケットのサイズ（１８４バイト）からアダプテーション・フィールドの長さを引いた値である。
【００３５】
「一時バッファへＮバイトを付加する」（Ｎ＝１４−ＰｒｅｖｉｏｕｓＳｉｚｅ）
ＰｒｅｖｉｏｕｓＳｉｚｅ＝ＰｒｅｖｉｏｕｓＳｉｚｅ＋ＰａｙｌｏａｄＬｅｎｇｔｈ
サイズを更新する。
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜９）
ＰｅｓＳｔａｔｕｓ＝１；
ＰＥＳヘッダの固定部分はこのパケットの中には完全には含まれていない。
ｅｌｓｅ  ＰｒｅｖｉｏｕｓＳｉｚｅは９より大きいかまたは等しい：ＰＥＳヘッダの固定部分のすべてのフラグがこのパケットの中にある。
ｉｆ（ｐｔｓ ｆｌａｇ＝０）  ＰＴＳはＰＥＳへッダの中にない
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜ＰＥＳヘッダの長さ）
ＰｅｓＳｔａｔｕｓ＝２；有用なフィールドはこれ以上ないが、ＰＥＳヘッダはこのパケットの中では終了しない。
ｅｌｓｅ
ＰｅｓＳｔａｔｕｓ＝０；
「転送されるべきデータの開始点をアレンジする」
ＰＥＳヘッダはこのパケットの中で終了する；ＰＥＳペイロードが転送されなければならない。
ｅｌｓｅ  ＰＥＳヘッダはＰＴＳを含んでいる。
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜１４）  ＰＴＳは次のパケットの中にある。
ＰｒｓＳｔａｔｕｓ＝１；
ｅｌｓｅ  ＰＴＳはこのパケットの中にある。
「ＰＴＳをビデオ・デコーダへ書き込む」
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜ＰＥＳヘッダの長さ）
ヘッダはこのパケットの中では終了しない。
ＰｅｓＳｔａｔｕｓ＝２；
ｅｌｓｅ  ヘッダは終了している。
ＰｅｓＳｔａｔｕｓ＝０；
「転送されるべきデータの開始点をアレンジする。
ＰＥＳヘッダはこのパケットの中で終了する：ＰＥＳペイロードが転送されなければならない。
【００３６】
この場合、パケットはＰＥＳヘッダが存在している陵だけＣＰＵへ送られる。その発生はトランスポート・パケット・ヘッダの中のＰＥＳインジケータの値をチェックすることによって簡単に知ることができる。
ビデオ・ストリームが１５Ｍｂｐｓのビット・レートでフレームにコード化されていると仮定する。ＣＰＵが各パケットを処理しなければならない場合、ＣＰＵは約１００μＳごとに割り込まれる。
反対に、ＴＰＰハードウェアによって実行される事前のフィルタおよびルーティングを使うことによって、ＣＰＵはＰＥＳパケットごとに割り込まれる。そのＰＥＳパケットの長さが少なくともフレーム・サイズに等しい場合、割込みは最悪の場合４０ｍｓごとに発生される。
例：ＰＥＳシンタックスを解析するオーディオ・デコーダに対するトランスポート・ストリーム、ストリームｉｄフィールドについてのフィルタが実行される。
この例では、オーディオ・デコーダはＰＥＳパケットを解析することができるが、ＣＰＵは特定の値とは異なるストリームｉｄを持つすべてのＰＥＳパケットをフィルタしなければならない（そのストリームｉｄが同じである場合）。
【００３７】
図６に示されていて前のページで説明された一般的なアルゴリズムが使われる。次の部分はオーディオのＰＥＳパケットに関連している処理の特定の部分だけを説明する。特に、Ｈｐｅｉメカニズムはディスエーブルされていて、したがって、ＣＰＵはＰＥＳヘッダの開始点を含んでいるトランスポート・パケットが受信されるたびにＳｐｅｉフラグをセットする。
ＴＰＰハードウェア・モジュールのＰＩＤ選択をイネーブルする前に、ＴＰＰ制御レジスタのフラグが次のように初期化される。
Ｅｎ ｅｒｒｏｎｅｏｕｓ ｐ＝０  エラーを含んでいるパケットが捨てられる。
Ｅｎ ｄｕｐｌｉｃａｔｅ ｐ＝０  アダプテーション・フィールドを含んでいない複製されたパケットが捨てられる：この場合、そのペイロードは前のパケットのペイロードと同じである。
Ｓｐｅｉ＝０  ＣＰＵの介入なしの自動転送：そのパケットは前のセクションで説明されている条件が発生した時だけＣＰＵによって横取りされる。
ｓｔｒｅａｍ−ｉｄフィルタ・フラグ＝１  ストリームｉｄフィールドについてのフィルタが必要である。
ＰＳＩフラグ＝０  オーディオ・ストリームはＰＳＩセクションによってではなく、ＰＥＳシンタックスを使うことによって転送される。
Ｅｎ Ｈｐｅｉ＝０  Ｈｐｅｉメカニズムがディスエーブルされており、ＣＰＵはＳｐｅｉをセットおよびリセットしなければならない。
初期化後、ＴＰＰハードウェア・モジュールは最初のＰＥＳヘッダが受信されるまで、すべてのパケットを捨てる。この時点で、ＥＯＰ割込みが発行され、ＣＰＵがそのパケットを解析する。
ストリームｉｄの値が特定のパターンにマッチした場合、すべてのＰＥＳパケットはオーディオ・デコーダへ送られなければならない。結果として、マイクロプロセッサはパケット・アナライザ制御レジスタの中のストリームｉｄフィルタ・フラグをクリアし、すべてのトランスポート・パケットはオーディオ・デコーダへ自動的に転送される。別のＰＥＳヘッダがＴＰＰハードウェアによって見つけられると（そのトランスポート・ヘッダの中パケット・ユニット・スタート・インジケータがセットされている）、割込みが発生され、そしてＣＰＵはその新しいＰＥＳパケットのストリームｉｄ値について別のフィルタ操作を実行することができる。
ストリームｉｄの値が特定のパターンにマッチしなかった場合、ＣＰＵはＴＰＰモジュールの中のストリームｉｄフラグをセットし、その同じＰＩＤを持つそれ以降のすべてのトランスポート・パケットは、次のＰＳヘッダまでハードウエアによって自動的に捨てられる。
【００３８】
このアルゴリズムは次の擬似コードによって説明することができる。ＣＰＵはすべてのＰＥＳヘッダを解析せず、ストリームｉｄフィールドだけを解析する。ＰｅｓＳｔａｔｕｓは前のステータスのＰＥＳヘッダ処理のステータスを示す（０＝ＰＥＳヘッダが終了しているか、あるいはＰＥＳヘッダは前のパケットから継続しているが、ストリームｉｄ値が既にフィルタされている；１＝そのＰＥＳヘッダが前のパケットから継続していて、そのストリームｉｄ値がまだフィルタされていない）。
ＰｒｅｖｉｏｕｓＳｉｚｅは前のパケットの中で読まれたＰＥＳヘッダの長さを示す。
ｉｆ（ストリームｉｄフィルタ・フラグ＝０）ａｎｄ
（ＰＥＳ／ＰＳＩスタート・フラグ＝０）
「そのパケットを捨てる」
現在のパケットはストリームｉｄフィルタ・パターンにマッチせず、そしてＰＥＳヘッダがない：そのパケットは捨てられなければならない。
ｅｌｓｅ
ｉｆ（ＣＣ−ｅｒｒｏｒフラグ＝１）ａｎｄ
（不連続性ステータス＝ＴＲＵＥ）
「エラーの隠蔽を開始する」
連続性カウンタのエラーが存在するが、その不連続性は許されない。前のパケットのいくつかが欠落している。この場合、エラー隠蔽の適切な方法が開始されなければならない。
ｉｆ（ＰＥＳ／ＰＳＩスタート・フラグ＝０）ａｎｄ
（ＰｅｓＳｔａｔｕｓ＝０）
「転送されるべきデータの開始点をアレンジする」
このパケットにはＰＥＳヘッダがない；すべてのペイロードが転送されなければならない。
ｅｌｓｅ  ＰＥＳヘッダまたはＰＥＳの継続がある。
ＰａｙｌｏａｄＬｅｎｇｔｈ＝１８４−Ａｆｌｅｎｇｔｈ
バイト単位でペイロードの長さを計算する；ペイロード・サイズはトランスポート・パケットのサイズ（１８４バイト）からアダプテーション・フィールドの長さを引いた値である。
【００３９】
ＰｒｅｖｉｏｕｓＳｉｚｅ＝ＰｒｅｖｉｏｕｓＳｉｚｅ＋ＰａｙｌｏａｄＬｅｎｇｔｈ
サイズを更新する。
ｉｆ（ＰｒｅｖｉｏｕｓＳｉｚｅ＜４）
ＰｅｓＳｔａｔｕｓ＝１；
ストリームｉｄはこのパケットには含まれていない。次のトランスポート・パケットが解析されなければならない。
ｅｌｓｅ  ＰｒｅｖｉｏｕｓＳｉｚｅが４より大きいかまたは４に等しい：ストリームｉｄフィールドがこのパケットの中に含まれている。
ＰｅｓＳｔａｔｕｓ＝０；  ＣＰＵは次のバケットを解析する必要はない。
ｉｆ（ストリームｉｄ＝「パターン」）  ストリームｉｄフィールドをフィルタする；その値が特定のパターンに等しかった場合、ＰＥＳパケットが選択される。
「ストリームｉｄフィルタ・フラグをクリアする」  ＴＰＰハードウェアによるパケットの自動棄却をディスエーブルする。
「転送されるべきデータの開始点をアレンジする」
ＰＥＳヘッダはこのパケットで終了する；ＰＥＳペイロードが転送されなければならない。
ｅｌｓｅ  ストリームｉｄフィールドが指定されたパターンと異なっている；ＰＥＳパケットは捨てられなければならない。
「ストリームｉｄフィルタ・フラグをセットする」  ＴＰＰハードウェアによるパケットの自動棄却をイネーブルする。
「パケットを捨てる」
【００４０】
この時点でＳｐｅｉビットはＰｅｓＳｔａｔｕｓが０に等しい場合だけクリアされる。というのは、ＰＥＳヘッダの考慮される部分が既に処理されているからである。
この場合、ストリームｉｄ値をフィルタするためにＰＥＳヘッダが存在する時だけＣＰＵに対して割込みが送られる。ストリームｉｄが選択された値とマッチした場合、次のパケットは宛先のバッファへ自動的に転送される。反対に、ストリームｉｄがその選択された値とマッチしなかった場合、次のＰＥＳヘッダまで、それに続くすべてのパケットはＴＰＰハードウェア・モジュールによって捨てられる。
このメカニズムなしでは、ＣＰＵはストリームｉｄの値が望ましくないＰＥＳパケットの中に含まれているすべてのトランスポート・パケットを捨てるための割込みを強制的に受信させられる。
【００４１】
以上の説明に関して更に以下の項を開示する。
（１）          トランスポート・ストリーム・パーザ・システムであって、１つの関連するフラグによって事前処理された後のパケットを含めるための中間バッファと、送信フラグによって選択されたバケットをさらにソフトウェアで処理するためのプロセッサとを含むシステム。
【図面の簡単な説明】
【図１】１８８個のバイトを含んでいるトランスポート・パケットを示す図。
【図２】従来技術のデコーダ・システムを示す図。
【図３】入力データ・パケットに対する２つのデータ・フロー・パスを示す図。
【図４】割込みを発生するための情報および条件を示す図。
【図５】本発明のシステムのブロック図を示す図。
【図６】パケットを解析するために使われるフロー・チャート
【図７】ＰＥＳパケットの構造を示す図。
【図１】
0004049863.tif 000003
【図２】
0004049863.tif 000004
【図３】
0004049863.tif 000005
【図４】
0004049863.tif 000006
【図５】
0004049863.tif 000007
【図６】
0004049863.tif 000008
【図７】
0004049863.tif 000009