JP2010531087A - 一定のビットレートのストリームの伝送のためのシステム及び方法 - Google Patents

Abstract

本発明は、受信機が一定のビットレートによりストリームを再構成することを可能にするための送信機、受信機及びこれらの方法に関する。本発明は、特に送信システムにおける第２パケットにカプセル化された第１パケットを送信する方法であって、送信機において、所定数の前記第１パケットを収集するステップと、前記収集された第１パケットをカプセル化した前記第２パケットの送信をトリガーするステップとを有し、前記第２パケットは、前記第１パケットのそれぞれに対するタイムスタンプを有する方法に関する。

Description

本発明は、一般に可変的なビットレートのストリームの伝送に関し、特にインターネットプロトコルを介したＶＢＲ ＭＰＥＧ−２ ＴＳの時間に正確な伝送に関する。

本セクションは、読者に様々な技術的特徴を紹介するためのものであり、これらの技術的特徴は、以下に説明及び／又は請求される本発明の各種態様に関するものであるかもしれない。この説明は、本発明の各種態様のより良い理解を実現するため、読者に背景情報を提供するのに役立つと考えられる。従って、これらの説明はこの観点で参照されるべきであり、先行技術の自認としてみなされるべきでないことが理解されるべきである。

ＭＰＥＧ−２仕様書［１］及び［２］は、ＭＰＥＧ−２ストリーム内でタイムスタンプがどのように含まれるか、デスティネーションにおいて異なるタイムスタンプがソースサイドにおけるクロックと同期してクロックを復元するのにどのように使用されるか、及び異なるタイムスタンプがＭＰＥＧデコーダに提供し、送信ストリームの各要素を表示する時点を制御するのにどのように使用されるかについて記載している。

ＩＥＴＦ ＲＦＣ ２２５０［４］の文献は、複数のＭＰＥＧ−２トランスポートストリーム、ＭＰＥＧ−２ ＴＳ、プログラムストリーム、ＭＰＥＧ−２ ＰＳ、パケットがＲＴＰパケットのペイロード内でどのように搬送されるかについて記載し、さらに１つのタイムスタンプが各ＲＴＰパケットに添付されることを規定している。ＤＶＢ−ＩＰ仕様書［５］は、ＩＰネットワークを介したマルチメディアサービスの配信のための汎用的なアーキテクチャについて記載している。この仕様書は、ＲＴＰを介しＭＰＥＧ−２ストリームを伝送するための機構としてＲＦＣ ２２５０を採用している。

グループ化されたＭＰＥＧ−２ ＴＳパケットは、ＩＰ送信ネットワークにおいてジッタ、すなわち、送信遅延の変動を被る。ジッタは、ＲＦＣ ２２５０によりカプセル化スキームによるものである。すなわち、送信機において、ＭＰＥＧ−２ ＴＳパケットがグループ化され、これにより時間に関してそれらの相対的なポジションが失われる。送信ネットワークもまたジッタをもたらす。このジッタは、受信機がＭＰＥＧ−２ ＴＳパケットの間の当初の時間間隔を正確かつ容易に再生することを許さない。複数のＭＰＥＧ−２パケットが１つのＲＴＰパケット内に搬送されるため、すべてのＭＰＥＧ−２パケットのタイミングがデスティネーション側において正しく再構成されるべき場合、いくつかの仮定が必要とされる。通常、ＭＰＥＧ−２ストリーム全体が一定のビットレートのストリームであることが仮定される。これは必ずしも正しくなく、特に部分的なＭＰＥＧ−２ ＴＳ、例えば、最初は一定のビットレートのストリームであったが、パケット量が削除されたストリームなどしか搬送されないときである。さらに、複数のＭＰＥＧ−２パケットがＲＴＰパケット内で搬送される場合、ＲＴＰパケットの構築が終了した時点、すなわち、最後のＭＰＥＧ−２パケットが送信機に到着した時点で、ＲＴＰタイムスタンプが生成される。デスティネーション側では、これは、この最後のパケットの時間のみが知られることになることを意味し、他のすべてのＭＰＥＧ−２パケットの時間しか推定できない。パケットの再構成されたタイミングは、ＭＰＥＧ−２パケットがＲＴＰバッファ内に配置された時間の不確実性により与えられるジッタを含む。このジッタは、２つの後続するＲＴＰパケットの送信の時間差、すなわち、それらのタイムスタンプの差に等しい。ＭＰＥＧ−２クロックリカバリは、このジッタのあるストリームからＰＣＲ又はＳＣＲタイムスタンプを抽出し、ＭＰＥＧクロックを再構成するため、それらをＰＬＬに供給する。ＲＴＰ送信により生じる補完的なジッタは、このＰＬＬが、ＲＴＰなしに直接送信されるＭＰＥＧストリームの場合より効率的である必要があるはずである。それはまた、クロックが同期するまでより長い時間となる。

図１は、ＲＦＣ ２２５０によるＭＰＥＧ−２ ＴＳ伝送を表す。図１の第１ラインは、いくつかのパケットがＰＣＲ情報を搬送するパケット、オーディオビデオ情報のみを搬送するパケット又は対象とされるサービスに属さない単なるパケットとして特定される一定のビットレートのＭＰＥＧ−２ ＴＳを表す。

第２ラインは、伝送される特定のサービスに関係しないパケットがストリームから削除された際に取得される可変的なビットレートのＭＰＥＧ−２ ＴＳを表す。

第３ラインは、ＲＦＣ ２２５０によりＭＰＥＧ−２ ＴＳを伝送するＲＴＰストリームを表す。このため、４つのＭＰＥＧ−２ ＴＳパケットが各ＲＴＰパケットのペイロードにカプセル化される。

第４ラインは、ＲＴＰパケットがＩＰネットワークを介し伝送され、これによりジッタを被った際に受信機側で行われることを表す。ｄＴＡとｄＴＢにより表されるＲＴＰパケットの間の当初のタイミングが失われている。

第５ラインは、ＲＴＰのタイミングリカバリが利用されるときに行われることを表す。実際、ＲＴＰタイミングリカバリの後、ＲＴＰパケットの間の時間間隔は１１μｓの精度により再生可能であるため、第３ラインとほとんど同じストリームを再生可能である。ＲＴＰタイムスタンプは、９０ｋＨｚのクロックに基づく。

最後のラインは、ＴＳパケットがＲＴＰパケットのペイロードから抽出されるときに行われることを表す。ＴＳパケットの間の時間間隔は、処理中に失われている。通常、受信機は、最後のラインに示されるように、パケットが規則的に配置された抽出されたストリームを生成する。

ＭＰＥＧ−２ ＴＳパケットの間の当初の時間間隔の不正確な再生は問題となるかもしれない。なぜなら、一部のアプリケーションは、受信機におけるパケットの当初の時間シーケンシングを再生可能である必要があるためである。いくつかのパケットは、プログラムクロックリファレンス（ＰＣＲ）などのタイミング情報を搬送し、これらのＰＣＲが過大なジッタを被らないことを確実にすることが非常に重要である。他のアプリケーションについては、各パケットのポジションを正確に示すことができることが重要である。パケット間の時間間隔は、実際には他のサービスのためのパケットの挿入に使用されるかもしれない。

本発明は、インターネットプロトコルを介したＭＰＥＧ−２ ＴＳの正確な伝送を可能にする方法を提供することによって、従来技術におけるＲＦＣ ２２５０に関する問題の少なくとも一部を解消しようとするものである。

本発明は、送信システムにおける第２パケットにカプセル化された第１パケットを送信する方法であって、送信機において、所定数の前記第１パケットを収集するステップと、前記収集された第１パケットをカプセル化した前記第２パケットの送信をトリガーするステップとを有し、前記第２パケットは、前記第１パケットのそれぞれに対するタイムスタンプを有する方法に関する。

一実施例によると、本方法は、関連のない第１パケットを特定するステップと、関連のない第１パケットを排除するステップと、前記第２パケットにおける前記関連のない第１パケットのポジションを示すステップとを有する。

一実施例によると、本方法は、前記関連のないパケットに対するタイムスタンプを示さないステップを有する。

一実施例によると、前記第１パケットは、ＭＰＥＧ−２トランスポートストリームパケットである。

一実施例によると、前記第２パケットは、ＲＴＰパケットである。

一実施例によると、前記関連のないパケットは、ＮＵＬＬ ＴＳパケットである。

本発明の他の課題は、送信システムにおいて第２パケットにカプセル化された第１パケットのストリームを受信する方法であって、受信機において、前記第２パケットにおける前記第１パケットに対するタイムスタンプの有無を特定するステップ及び／又は関連のないパケットの有無の表示を特定するステップと、前記タイムスタンプに従って設定された前記第１パケットの間の時間間隔及び／又は関連のないパケットの特定を備える前記第１パケットによりストリームを構成するステップとを有する方法である。

本発明の他の課題は、本発明による方法のステップを、コンピュータ上での実行時に実行するためのプログラムコード命令を有するコンピュータプログラムである。“コンピュータプログラム”によって、コンピュータプログラムが、ディスケットやカセットなどのプログラムを含む格納スペースだけでなく、電気又は光信号などの信号に構成されるもとをサポートすることを意図する。

開示される実施例による範囲に相当する特定の態様が、以下に与えられる。これらの態様は、読者に本発明がとりうる特定の形態の概略を提供するために提示されるにすぎず、これらの態様が本発明の範囲を限定することを意図していないことが理解されるべきである。実際、本発明は、以下に与えられない各種態様を含むかもしれない。

本発明は、限定的なものでない添付図面を参照して以下の実施例と実行例によってよりよく理解及び説明される。

図１は、ＭＰＥＧ−２ ＴＳパケットのカプセル化から生じるジッタ問題を示す図である。 図２は、一実施例によるオリジナルストリームの再構成を示す図である。 図３は、第１実施例によるＲＴＰパケットである。 図４は、第２実施例によるＲＴＰパケットである。 図５は、第３実施例によるＲＴＰパケットである。 図６は、本実施例による送信機のブロック図である。 図７は、本実施例による受信機のブロック図である。

図６及び７において、表示されたブロックは純粋に機能的なエンティティであり、必ずしも物理的に別々のエンティティに対応するとは限らない。すなわち、それらは、ソフトウェアの形態により開発可能であるか、又は１以上の集積回路により実現可能である。

一実施例は、ＩＰを介したＭＰＥＧ−２ ＴＳの送信のフレームワーク内のものであるが、本発明は、この実施例に限定されず、送信がジッタを発生させる他のフレームワークに適用可能である。

第１実施例によると、図３に示されるように、送信機は、ＲＴＰペイロードの各ＴＳパケットに対して１つのタイムスタンプを付加する。ＲＦＣ ２２５０によると、ＲＴＰパケット毎に１〜７個のＴＳパケットが存在する可能性があるため、同数のタイムスタンプ表示１〜７が、ＲＴＰペイロードのエンドにおいてＴＳパケットの後に付加される。タイムスタンプ情報は、ＭＰＥＧ−２ ＴＳと同じクロックである２７ＭＨｚクロックに基づく。１つのタイムスタンプについて、３２ビットが使用され、２７ＭＨｚのクロックのレゾリューションによると、３２ビットは依然として１５９秒のタイムウィンドウを提供する。１５９秒は、２^３２／２７Ｅ６に対応する。

タイムスタンプは、各ＴＳパケットが受信すると時間に関して正確に配置されることを可能にする。これは、受信機が連続するＴＳパケットの間の時間間隔を正確に再生することを可能にする。もちろん、第１タイムスタンプはペイロードの第１ＴＳパケットに対応し、第２タイムスタンプはペイロードの第２ＴＳパケットに対応し、以下同様に対応する。

ＲＴＰパケットでは、ＲＦＣ ２２５０に従ってほとんどすべてのフィールドが充填される。第１の相違は、ペイロードの最後のＴＳパケットの後に、送信機がタイムスタンプを導入するということである。他の相違は、ＲＴＰヘッダの長さフィールドに置かれる値がより大きなものであるということである。それは、ＴＳパケットのタイムスタンプの長さもまた含む。

受信機側では、タイムスタンプの有無は、ＩＰ長フィールドにおいて検出される。タイムスタンプの有無が検出されると、受信機は、これらのタイムスタンプを利用して、パケットが配置されるＶＢＲ ＭＰＥＧ−２ ＴＳを、これらのタイムスタンプ情報に従って生成する。もちろん、これはオリジナルのＶＢＲストリームを再生する。

以下のテーブルは、第１実施例によるＩＰ長フィールドの値であるＩＰ長（ｔｓモード）を示す。ＴＳはトランスポートストリームであり、ｔｓはタイムスタンプである。第１カラムでは、１ＴＳび伝送のためのＲＴＰのＩＰ長は２２８ビットである。１ＴＳと１ｔｓの伝送のためのＲＴＰのＩＰ長は２３２ビットである。受信機が２３２のＩＰ長を読むと、それは１つのタイムスタンプの有無を検出する。

第２実施例によると、送信機はストリームにＮＵＬＬパケットの有無に関する表示を付加する。

多くのＶＢＲ ＭＰＥＧ−２ ＴＳは、ＣＢＲストリームから関係のないパケットを排除することによって生成される。より詳細には、ＶＢＲ ＭＰＥＧ−２ ＴＳは、ＮＵＬＬ ＴＳパケットがＣＢＲストリームから排除された場合に生成される。これは、典型的には、大部分のＭＰＥＧ−２ ＶＢＲエンコーダが生成するタイプのストリームである。このようなケースでは、受信機はＴＳパケット間の時間間隔を知る必要はない。オリジナルストリームを再生するためには、ＴＳパケットの間のいくつのＮＵＬＬパケットがあったか知ってさえすればよい。従って、図４に示されるように、ＲＴＰペイロードのエンドには１バイトが付加される。最上位の７ビットは、ＮＵＬＬパケットが存在するか示し、１に設定されたビットは、ＮＵＬＬパケットが存在することを意味する。

送信機では、ＮＵＬＬパケットが検出されるときは常に、対応するビットは１に設定され、ＮＵＬＬパケットはＲＴＰペイロードには置かれない。送信機の一例は以下のとおりである。すなわち、送信機は、７つのＴＳパケットによりＲＴＰパケットを構成するよう設定される。送信機は、７つのＴＳパケットを受信する。最初と最後のパケットは、ＡＶコンテンツを有し、ＮＵＬＬパケットでない。その他のパケットは、５つのＮＵＬＬパケットである。送信機は、０ｘ０１１１１１００バイトが後続するＡＶコンテンツを有する２つのＴＳパケットしか含まないペイロードを有するＲＴＰパケットを構成する。

第２実施例によると、ＮＵＬＬ存在ビットは、ＮＵＬＬパケットが検出される場合かつその場合に限って１に設定される。送信機がＲＴＰパケット毎に４つのＴＳパケットを送信するよう構成されるとき、バイトの最下位の４ビットは常に０に設定される。

受信機側では、送信機のコンフィグレーションはＩＰ長フィールドにより検出される。余分なバイトの存在が検出されると、ＮＵＬＬパケットの存在が通知されるときは常に、受信機はＮＵＬＬパケットを生成する。受信機は、当初のＣＢＲに対応するレートによりパケットを生成する。それは、２つの連続するＰＣＲの間で送信されるパケットの個数を確認することによって、当該レートを知る。

以下のテーブルは、第２実施例によるＩＰ長フィールドの値を示す（ＮＵＬＬモード）。ＴＳはトランスポートストリームであり、ｂはＮＵＬＬパケットの識別情報に対応するビットである。第１カラムにおいて、１ＴＳの伝送のためのＲＴＰのＩＰ長は２２８ビットである。１ＴＳと１ｂとを伝送するためのＲＴＰのＩＰ長は２２９ビットである。

第３実施例によると、図５に示されるように、送信機は、各ＴＳパケットに対して１つのタイムスタンプと、ストリームにおけるＮＵＬＬパケットの有無に関する表示とを付加する。第１実施例と同様に、送信機は、ＲＴＰペイロードに各パケットに対して１つのタイムスタンプを付加する。タイムスタンプの個数はまた７以下である。タイムスタンプは、３０ビット長である。これは、７つの連続するＴＳパケットについて十分な約４０秒のウィンドウをもたらす。

送信機はまた、各タイムスタンプの前にＮビットとＴビットの２ビットを付加する。Ｎビットは、ＮＵＬＬパケットの存在がマーク付けされる必要があるときは常に１に設定される。Ｔビットは、次の３０ビットが関連するタイムスタンプを表すことを通知するよう１に設定される。

Ｎビットは、第２実施例のビットと同じ意味を有する。それは、ＴＳからＮＵＬＬパケットを排除することを可能にし、受信機がＮＵＬＬパケットを再導入することによってＣＢＲストリームを再構成することができるように、それらの存在を示す。

Ｔビットが０に設定されているとき、受信機は、次の３０ビットにおいて何れが格納されていても、それが関連するタイムスタンプでないことを通知される。それは、オリジナルストリームを再構成するため、受信機により使用されない。

すべてのＴビットが０に設定されているとき、ＮＵＬＬパケットの存在しか、オリジナルストリームを再生するのに利用可能でない。

Ｔビットが１に設定されているとき、受信機は、タイムスタンプを使用して、オリジナルストリームを再生することができる。

このようなタイムスタンプ情報の処理方法を知らない受信機は、いくつかのケースではおそらくより低い精度となるかもしれないが、依然としてＮＵＬＬ有無情報を利用することができる。

図６において、一実施例による送信機１が示される。ＮＵＬＬ検出モジュール１３は、ストリームにおけるＮＵＬＬパケット、より一般には無関係なパケットを検出するよう構成される。タイムスタンプモジュール１１は、ＭＰＥＧ−２ ＴＳに従ってタイムスタンプを示すよう構成される。パケット化手段１２は、タイムスタンプ及び／又はＮＵＬＬ情報によって、本実施例によるＲＴＰパケットを構成する。このとき、ＲＴＰパケットは、ＲＦＣ ２２５０に従って生成される。送信機は、インターネットネットワーク（図示せず）を介し受信機２に接続される通信モジュール（図示せず）を有する。

図７において、一実施例による受信機２が示される。それは、ＲＴＰパケットを受信するよう構成されるパケット解除モジュール２２を有する。タイムスタンプモジュール２１は、ＲＴＰパケットからタイムスタンプを抽出する。ＮＵＬＬ検出手段は、ＲＴＰパケットにおけるＮＵＬＬパケット表示を読む。タイムスタンプとＮＵＬＬ表示は、その後に上述されるようにしてオリジナルストリームを構成するのに利用される。

上記実施例は、レガシー受信機に準拠する。ＲＦＣ ２２５０に準拠するが、上記実施例を実現しない受信機は、実施例により埋め込まれた情報の最後のビット又はバイトを無視する。

明細書、請求項及び図面に開示されたリファレンスは、独立して又は何れか適切な組み合わせにより提供されてもよい。必要に応じて、各特徴はハードウェア、ソフトウェア又はこれらの組み合わせにより実現可能である。

“一実施例”又は“ある実施例”という表現は、当該実施例に関して説明される特定の機能、構成又は特徴が本発明の少なくとも１つの実現形態に含まれうることを意味する。明細書の各所における“一実施例では”というフレーズの出現は、必ずしも同一の実施例を参照しているとは限らず、他の実施例から相互に背反する別の又は他の実施例であるとは限らない。

請求項に現れる参照番号は、単なる例示であって、請求項の範囲に対して限定的な効果を有するものでない。
［リファレンス］
［１］ＩＳＯ／ＩＥＣ １３８１８−１：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ：Ｓｙｓｔｅｍｓ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ
［２］ＩＳＯ／ＩＥＣ １３８１８−２：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ：Ｖｉｄｅｏ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ
［３］ＭＰＥＧ−４ Ｖｉｄｅｏ：ＩＴＵ−Ｔ Ｒｅｃ Ｈ．２６４｜ＩＳＯ／ＩＥＣ １４４９６−１０ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−ｃｏｄｉｎｇ ｏｆ ａｕｄｉｏ−ｖｉｓｕａｌ ｏｂｊｅｃｔｓ−Ｐａｒｔ １０：Ｖｉｓｕａｌ
［４］ＩＥＴＦ ＲＦＣ ２２５０，ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＰＥＧ１／ＭＰＥＧ−２ Ｖｉｄｅｏ，Ｄ．Ｈｏｆｆｍａｎ ｅｔ ａｌ．，Ｊａｎｕａｒｙ １９９８
［５］ＤＶＢ ＴＭ ３０２２，Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）−Ｔｒａｎｓｐｏｒｔ ｏｆ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ，ＥＴＳＩ，ＲＴＳ／ＪＴＣ−ＤＶＢ−９３，２００４−０３−２６
ＭＰＥＧ−２ビデオ及びＭＰＥＧシステムに関するさらなる情報は、ＩＳＯ／ＩＥＣ １３８１８−１：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ：Ｓｙｓｔｅｍｓ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ及びＩＳＯ／ＩＥＣ １３８１８−２：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ：Ｖｉｄｅｏ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎに見つけることができる。

Claims (9)

1. 送信システムにおける第２パケットにカプセル化された第１パケットを送信する方法であって、
   送信機において、
   所定数の前記第１パケットを収集するステップと、
   前記収集された第１パケットをカプセル化した前記第２パケットの送信をトリガーするステップと、
   を有し、
   前記第２パケットは、前記第１パケットのそれぞれに対するタイムスタンプを有する方法。
2. 関連のない第１パケットを特定するステップと、
   関連のない第１パケットを排除するステップと、
   前記第２パケットにおける前記関連のない第１パケットのポジションを示すステップと、
   を有する、請求項１記載の方法。
3. 前記関連のないパケットに対するタイムスタンプを示さないステップを有する、請求項２記載の方法。
4. 前記第１パケットは、ＭＰＥＧ−２トランスポートストリームパケットである、請求項１乃至３何れか一項記載の方法。
5. 前記第２パケットは、ＲＴＰパケットである、請求項１乃至４何れか一項記載の方法。
6. 前記関連のないパケットは、ＮＵＬＬ ＴＳパケットである、請求項１乃至５何れか一項記載の方法。
7. 送信システムにおいて第２パケットにカプセル化された第１パケットのストリームを受信する方法であって、
   受信機において、
   前記第２パケットにおける前記第１パケットに対するタイムスタンプの有無を特定するステップ及び／又は関連のないパケットの有無の表示を特定するステップと、
   前記タイムスタンプに従って設定された前記第１パケットの間の時間間隔及び／又は関連のないパケットの特定を備える前記第１パケットによりストリームを構成するステップと、
   を有する方法。
8. 請求項１記載のセキュリティ処理のステップを、コンピュータ上での実行時に実行するためのプログラムコード命令を有するコンピュータプログラム。
9. 請求項７記載のセキュリティ処理のステップを、コンピュータ上での実行時に実行するためのプログラムコード命令を有するコンピュータプログラム。

Images