JP4616343B2 - 送信システムにおけるパケット送信方法 - Google Patents

Description

発明の詳細な説明

文献ＲＦＣ２２５０［３］は、複数のＭＰＥＧ２トランスポートストリーム及びプログラムストリームパケットが、ＲＴＰパケットのペイロードの内部でどのように搬送されるか記載し、また１つのタイムスタンプが各ＲＴＰパケットに添付されることを示す。

ＭＰＥＧ−２仕様［１］は、タイムスタンプがＭＰＥＧ２ストリーム内部にどのように含まれるか、送信先において、異なるタイムスタンプが送信元のクロックと同期したクロックを復元するのにどのように利用されるか、異なるタイムスタンプがＭＰＥＧデコーダに供給し、送信されたストリームの要素を表示すべき時点を制御するのにどのように利用されるかについて記載している。

ＤＶＢ−ＩＰ仕様［４］は、ＩＰネットワークを介したマルチメディアサービスの提供のための汎用的なアーキテクチャを記載している。当該仕様は、ＲＴＰを介しＭＰＥＧ−２ストリームを送信するための機構としてＲＦＣ２２５０を採用している。これはおそらく、ＲＦＣ２２５０を用いた規格である。

複数のＭＰＥＧ２パケットが１つのＲＴＰパケットの内部において搬送されるため、すべてのＭＰＥＧ２パケットのタイミングが送信先において正確に再構成されようとする場合、いくつかの仮定が必要とされる。通常、ＭＰＥＧ２ストリーム全体は一定のビットレートのストリームであるか、又は少なくとも個別に一定である、すなわち、ビットレートは、ＰＣＲ又はＳＣＲタイムスタンプがストリーム内部に挿入される時点においてのみ変更されることが仮定される。これは必ずしも真ではなく、特に部分的なＭＰＥＧ２−ＴＳしか搬送されないとき（「ホール（ｈｏｌｅ）」のあるストリーム）、例えば、初期的には一定のビットレートストリームであったが、ある数の（おそらく多数の）パケットが削除されたストリームなどにおいては真ではない。

いくつかのＭＰＥＧ２パケットがこのようなＲＴＰパケットの内部において搬送される場合、ＲＴＰタイムスタンプは、ＲＴＰパケットの構成が終了される時点、すなわち、最後のＭＰＥＧ２パケットが送信者に到着する時点に生成される。図３に従って、部分的なＴＳからＲＴＰパケットの生成は行われる。

送信先では、これは、当該最後のパケットの時間しかわからないことを意味し、他のすべてのＭＰＥＧ２パケットの時間は、推定しか可能でない。パケットの再構成されたタイミングは、ＭＰＥＧ２パケットがＲＴＰバッファ内におかれた時点の不確定さにより与えられるジッターを含む。このジッターは、後続する２つのＲＴＰパケットの送信の時間差（すなわち、それらのタイムスタンプの相違）に等しい。ここでは、ＭＰＥＧ２クロックリカバリは、この「ジッター」のあるストリームからＰＣＲ又はＳＣＲタイムスタンプを抽出し、ＭＰＥＧクロックを再構成するため、それらをＰＬＬに供給する。ＲＴＰの送信によって導入される補完的なジッターは、当該ＰＬＬが直接的（ＲＴＰなしに）に送信されたＭＰＥＧストリームの場合より効率的である必要があるそれはまた、クロックが同期する前に長い時間がかかる。

本発明は、上記問題を認識し、請求項において規定されるような解決手段を提案することにある。

本発明は、第１パケットの一部が受信機のクロックの同期のための第１タイミングリファレンスを有し、第２パケットの少なくとも一部が前記受信機における前記第２パケットの送信ジッターを低減するための第２タイミングリファレンスを有する送信システムにおける前記第２パケットにカプセル化された前記第１パケットを送信する方法であって、
送信機において、
・第１パケットを収集するステップと、
・収集した第１パケットが第１タイミングリファレンスを有するか判断するステップと、
・肯定的な判定に応答して、前記第１タイミングリファレンスを有する前記第１パケットを含む収集された第１パケットをカプセル化する第２パケットの送信をトリガーするステップと、
から構成されることを特徴とする方法に関する。

本発明の実施例によると、本方法はさらに、収集された第１パケットの個数が所定の値に到達した場合、第２パケットの送信をトリガーするステップを有する。

本発明の実施例によると、前記第１パケットは、ＭＰＥＧ２トランスポートストリームパケットであり、前記第１タイミングリファレンスは、ＰＣＲである。

本発明の実施例によると、前記第２パケットは、ＲＴＰパケットであり、前記第２タイミングリファレンスは、個別のＲＴＰパケットに組み込むため、前記送信機によって決定されたタイムスタンプである。

本発明の実施例によると、本方法はさらに、２つの連続するＲＴＰパケットの送信の間の最大時間インターバルを尊重するステップを有する。

本発明のさらなる効果は、本発明の非限定的な実施例の記載を通じて明らかになるであろう。

本実施例は、パーシャルＭＰＥＧ２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）に関する。しかしながら、本発明はパーシャルＭＰＥＧ２ ＴＳストリームに限定されるものではない。それは、フルＭＰＥＧ２ ＴＳストリームにも適用可能であり、また同様の同期処理及びジッターの問題が存在する他のタイプのパケット送信にも適用可能である。

図１は、ジッター導入現象を示す。図の先頭のラインは、個別のＭＰＥＧ２ ＴＳパケットから構成されるフルマルチプレックスＭＰＥＧ２ ＴＳストリームを示す。パーシャルストリームは、フルストリームから抽出される。ＭＰＥＧ２システムのＰＣＲタイムスタンプを有するパケットが、図示されるように示されている。ここで、ＲＴＰパケットペイロードは、４つのＭＰＥＧ２ ＴＳパケットから構成され、ＲＴＰパケットは、４つのＭＰＥＧ２ ＰＳパケットが送信機のバッファに存在するときは常に送信されることが仮定される。ｄＴＡ及びｄＴＢはそれぞれ、図示されるように、送信機のレベルにおける以降のＲＴＰパケット間のリアルタイムインターバルを表す。これらはまた、各ＲＴＰパケットのペイロードを充填するのに十分なＭＰＥＧ２ ＴＳパケットを収集するのに要求されるインターバルである。これらのパケットが送信された後、このタイミング関係は、ネットワークにより導入されるジッターにより変更される。受信すると、ＲＴＰタイムスタンプは、ｄＴＡ及びｄＴＢを復元するのに利用される。しかしながら、本発明者によって、１つのＲＴＰパケットのすべてのＭＰＥＧ２ ＴＳパケットが同時に受信されることが受信機により想定されているということが認識された（すなわち、それらは、ＲＴＰパケットヘッダのＲＴＰタイムスタンプが受信機のＲＴＰクロックに一致するとき、バーストとして受信機バッファに供給される）。この結果、もとのストリームの連続する２つのＭＰＥＧ２ ＴＳパケットは、受信機デコーダのバッファへの上記各パケットの書き込みの間の時間インターバルと異なる可能性があるため、補完的なジッターが導入される。

ＭＰＥＧ２ ＰＣＲを有するＭＰＥＧ２ ＴＳパケットが存在するとすぐに、ＲＴＰパケットを送信し、ＲＴＰパケットがそれの最大サイズ（典型的には、７つのＭＰＥＧ２ ＴＳパケットのペイロードに対応する）に到達するまで、ＲＴＰパケットを送信することをシステマティックに待機しないことが提案される。従って、ＲＴＰタイムスタンプは、時間リファレンスを有するＭＰＥＧ２パケットの受信と比較して、固定された遅延により生成される。

パーシャルＭＰＥＧ２ ＴＳは、送信機においてフルＴＳから抽出される。すべてのＴＳパケットのヘッダが解析され、それらがＰＣＲタイムスタンプを有するか決定される（それはヘッダにおいて通知されるため、これは容易に実行される）。このケースでないとき、ＴＳパケットがＲＴＰバッファにおかれる。バッファがフルになると（最大イーサネット（登録商標）ペイロードを超えないように、通常は７つのＴＳパケットの後であるが、他の基準又は最大サイズが存在するかもしれない）、ＲＴＰパケットは、通常のフリーランニング（ｆｒｅｅ ｒｕｎｎｉｎｇ）である９０ｋＨｚのクロックによりタイムスタンプされ、通常通りに送出される。ＴＳパケットがＰＣＲを有するとき、それはまたＲＴＰバッファにおかれるが、このとき、ＲＴＰパケットは、他の状態を待機することなく（例えば、バッファフルなど）、即座にタイムスタンプされ、送出される。これにより、タイムスタンプされたＭＰＥＧ２パケットは、ＲＴＰパケットペイロードのエンドに常に配置される。

図４は、送信機の関連するコンポーネントを示すブロック図である。

ＲＴＰパケットが他方の側で受信されると、それはバッファされる。パケットは、それらのＲＴＰタイムスタンプがローカルな９０ｋＨｚクロック＋固定された遅延に一致するとき、バッファから解放される。ローカルな９０ｋＨｚクロックは、何れかの手段によって送信者の９０ｋＨｚクロックに同期され、例えば、ネットワークインタフェースにおけるＰＬＬは、到着時にＲＴＰパケットのタイムスタンプを調べ、送信者クロックとの同期を維持するため、ローカルクロックの値を調整する。図５に記載されるこの機構の全体の出力において、ＭＰＥＧ２デコーダは、ＲＴＰパケットが送信されたものとほぼ近いリズムによりＭＰＥＧ２ ＴＳパケットを供給される。ＰＣＲを搬送するＭＰＥＧ２ ＴＳパケットが、常にＲＴＰパケット内の最後のパケットであるという事実により、ＲＴＰタイムスタンプは、ＭＰＥＧ２ ＴＳ ＰＣＲパケットのリズムにほとんど等しいリズムを構築する。ＰＣＲを保持するＭＰＥＧ２ ＴＳパケットと、それを送信するＲＴＰパケットのスタートとの間の時間インターバルは固定されているため、図１に関しい説明されたジッターは解消される。本実施例では、ＰＣＲを保持するＭＰＥＧ２ ＴＳパケットが常にＲＴＰパケットの最後のパケットとなるが、それが存在する各ＲＴＰの分割パケットのそれのポジションは固定されることが十分である。受信機側では、ＲＴＰリズムが再構築されるとき、ＭＰＥＧ２ ＴＳ ＰＣＲパケットのリズムは、図１の処理がされないパケット化においてより高い精度により再構築される。図２は、各ＲＴＰパケットに対して４つのＭＰＥＧ２ ＴＳパケットの最大値のＲＴＰカプセル化による本実施例のスキームの一例を与える。このケースでは、受信機側での２つのＭＰＥＧ２ ＴＳパケットの間の時間差は、送信機側のものと極めて近く、このため、ＭＰＥＧデコーダのクロック再同期は、より迅速なものとなる。

これはさらなる条件と組み合わせることが可能であることに留意されたい。変形された実施例によると、受信機におけるＲＴＰクロックのリカバリを実現するため、例えば、連続するＲＴＰパケットの間の最大となる時間インターバルを制限することに興味があるかもしれない。

本発明はまた、可能な最も高い優先度を有するＰＣＲ又はＳＣＲを含むＩＰパケットを設定することによって、向上させることが可能である。例えば、ＤＶＢ−ＩＰ（本明細書の最後にあるリファレンスを参照されたい）のフレームでは、あるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を提供するため、各パケットの優先度を設定することが可能である（例えば、パケットのヘッダのＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔを利用して）。これは、ＩＰパケットが他のネットワークトラフィックにより生成される可能性のあるルータ混雑からの影響を可能な限り被らないことを保証し、これにより、ソースサーバからクライアントボックスにこのようなＩＰパケットを送信するのに使用される時間についてさらなる安定性を追加するであろう。

本発明は、ＲＦＣ２２５０に準拠しながら、ＭＰＥＧクロックリカバリにおけるジッターを低減する。また、標準的なＭＰＥＧ２デコーダは、デコーダ内のバッファが１つのＲＴＰパケットのコンテンツを保持するのに十分である場合、パーシャルトランスポートストリームのためにさえ利用可能である（通常は、７つのＭＰＥＧ２ ＴＳパケット＝７＊１８８バイト）。

これは、例えば、ＭＰＥＧ４ Ｐａｒｔ１０［２］などの圧縮された映像を搬送する場合にも、ＭＰＥＧ２システムに適用される。

リファレンス：
［１］ＩＳＯ／ＩＥＣ １３８１８−１：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｉｏｎ：Ｓｙｓｔｅｍｓ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｉｓｏ．ｏｒｇ／ｉｓｏ／ｅｎ／ＣａｔａｌｏｇｕｅＤｅｔａｉｌＰａｇｅ．ＣａｔａｌｏｇｕｅＤｅｔａｉｌ？ＣＳＮＵＭＢＥＲ＝３１５３７
ＩＳＯ／ＩＥＣ １３８１８−２：２０００ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｉｏｎ：Ｖｉｄｅｏ，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｉｓｏ．ｏｒｇ／ｉｓｏ／ｅｎ／ＣａｔａｌｏｇｕｅＤｅｔａｉｌＰａｇｅ．ＣａｔａｌｏｇｕｅＤｅｔａｉｌ？ＣＳＮＵＭＢＥＲ＝３１５３９
［２］ＭＰＥＧ−４ Ｖｉｄｅｏ：ＩＴＵ−Ｔ Ｒｅｃ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−ｃｏｄｉｎｇ ｏｆ ａｕｄｉｏ−ｖｉｓｕａｌ ｏｂｊｅｃｔｓ−Ｐａｒｔ １０：Ｖｉｓｕａｌ
［３］ＩＥＴＦ ＲＦＣ２２５０，ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＰＥＧ１／ＭＰＥＧ２ Ｖｉｄｅｏ，Ｄ．Ｈｏｆｆｍａｎ ｅｔ ａｌ．，Ｊａｎｕａｒｙ １９９８
例えば、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２５０．ｔｘｔにおいて利用可能である。
［４］ＤＶＢ ＴＭ３０２２，Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）−Ｔｒａｎｓｐｏｒｔ ｏｆ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ，ＥＴＳＩ，ＲＴＳ／ＪＴＣ−ＤＶＢ−９３，２００４−０３−２６
ＭＰＥＧ２ビデオ及びＭＰＥＧシステムに関するさらなる情報は、以下の文献、すなわち、ＩＳＯ／ＩＥＣ １３８１８−１：２０００“Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｉｏｎ：Ｓｙｓｔｅｍｓ，ＩＳＯ”とＩＳＯ／ＩＥＣ １３８１８−２：２０００ “Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｉｏｎ：Ｖｉｄｅｏ，ＩＳＯ”に見つけることが可能である。

図１は、ＭＰＥＧ２ ＴＳパケットのカプセル化から生じるジッター問題を示す図である。 図２は、本発明の実施例がジッターを低減するのに利用される図１と同様の図である。 図３は、従来技術による送信機のブロック図である。 図４は、本実施例による送信機のブロック図である。 図５は、ＭＰＥＧ２ ＴＳパケットをカプセル化するＲＴＰパケットのデコーダ及び受信機のブロック図である。

Claims (5)

1. 第１パケットの一部が受信機のクロックの同期のための第１タイミングリファレンスを有し、第２パケットの少なくとも一部が前記受信機における前記第２パケットの送信ジッターを低減するための第２タイミングリファレンスを有する送信システムにおける前記第２パケットにカプセル化された前記第１パケットを送信する方法であって、
   送信機において、
   第１パケットを収集するステップと、
   収集した第１パケットが第１タイミングリファレンスを有するか判断するステップと、
   もし前記収集された前記第１パケットが、第１のタイミングリファレンスを有する場合、前記第１タイミングリファレンスを有する前記第１パケットを含む収集された第１パケットをカプセル化する第２パケットの送信をトリガーするステップと、
   を有することを特徴とする方法。
2. 請求項１記載の方法であって、さらに、
   収集された第１パケットの個数が所定の値に到達した場合、第２パケットの送信をトリガーするステップを有することを特徴とする方法。
3. 請求項１又は２記載の方法であって、
   前記第１パケットは、ＭＰＥＧ２トランスポートストリームパケットであり、
   前記第１タイミングリファレンスは、ＰＣＲである、
   ことを特徴とする方法。
4. 請求項１乃至３何れか一項記載の方法であって、
   前記第２パケットは、ＲＴＰパケットであり、
   前記第２タイミングリファレンスは、個別のＲＴＰパケットに組み込むため、前記送信機によって決定されたタイムスタンプである、
   ことを特徴とする方法。
5. 請求項４記載の方法であって、さらに、
   ２つの連続するＲＴＰパケットの送信の間の最大時間インターバルを尊重するステップを有することを特徴とする方法。

Images