JP3802003B2 - Ｒｔｐパケット生成／復元装置及び方法 - Google Patents
Ｒｔｐパケット生成／復元装置及び方法 Download PDFInfo
- Publication number
- JP3802003B2 JP3802003B2 JP2003098388A JP2003098388A JP3802003B2 JP 3802003 B2 JP3802003 B2 JP 3802003B2 JP 2003098388 A JP2003098388 A JP 2003098388A JP 2003098388 A JP2003098388 A JP 2003098388A JP 3802003 B2 JP3802003 B2 JP 3802003B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- cts
- delta
- rtp
- dts
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 32
- 239000000203 mixture Substances 0.000 claims description 8
- 238000000605 extraction Methods 0.000 claims description 6
- 239000000284 extract Substances 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 12
- 102100025953 Cathepsin F Human genes 0.000 description 6
- 101000933218 Homo sapiens Cathepsin F Proteins 0.000 description 6
- 230000000295 complement effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はＭＰＥＧ-４ストリームを転送するためのＲＴＰパケット生成/復元装置及び方法に係り、さらに詳しくはＭＰＥＧ-４ストリームを転送する複数のＳＬパケットを一つのＲＴＰパケット内に効率的にカプセル化するための装置及び方法に関する。
【０００２】
【従来の技術】
【０００３】
【特許文献１】
日本特開平１３―１４８８５３
【０００４】
システムマルチプレクサーを用いて多数のシンクレイヤーパケット（ＳＬパケット）を生成し、これはＲＴＰヘッダとシンクレイヤーヘッダ、リシンクマーク、Payloadから構成され、ＲＴＰパケットのtimestampでＳＬパケットのtimestampを利用。
【０００５】
インターネットエンジニアリングタスクフォース(Internet Engineering TaskForce : IETF)はＴＣＰ/ＩＰのようなインターネット運営プロトコルの標準を定義する主体であって、技術分野別に区分された下位チームを有する。ＭＰＥＧ-４ストリームを多重同期層(Synchronization Layer : ＳＬ)パケット化して実時間転送プロトコル(Real-time Transport Protocol : ＲＴＰ)に転送するためのＲＴＰフォーマットはDraft-IETF-AVT-MPEG4-MULTISL-02．TXTに記述されている。
【０００６】
現在、タイムスタンプ及びランダムアクセスのような転送特性情報を保存するために概念的なＳＬ層が定義されている。ＭＰＥＧ-４基本ストリームが転送される際、ＳＬ層からの転送情報は通常に実質的な転送層にマッピングされる。
【０００７】
図１は複数のＳＬパケットが収容されたＲＴＰパケットを示す図である。図１を参照すれば、ＲＴＰパケット１００はＲＴＰパケットヘッダ１１０、マッピングされたＳＬヘッダ１２０、残余ＳＬヘッダ１３０、及びＳＬパケットペイロード１４０とから構成される。
【０００８】
ＲＴＰパケットヘッダ１１０は固定サイズを有しヘッダの後に特定情報及びデータが後続する。ＲＴＰパケットヘッダの各フィールドを簡単に説明すれば、Ｖフィールドはバージョンフィールドであり、Ｐフィールドは３２ビット単位でパケットを構成するために使われる。Ｘフィールドはヘッダを拡張するか否かを表示する。ＣＣフィールドはＣＳＲＣ識別子(contributing source identifier)の個数を指す。Ｍフィールドはマルチメディア情報に対するフレーム領域を示す。すなわちパケット内で音声と映像情報などを区別するのに使用される。ＰＴフィールドはＲＦＣ１８９０で定義されたプロファイルのＲＴＰペイロードのフォームを指し、応用プログラムによって解釈される。シーケンス番号フィールドはＲＴＰパケットの順序を示す。timestampフィールドはＲＴＰパケットの一番目オクテットがサンプリングされた時点を示す。ＳＳＲＣ(Synchronization source)フィールドはカメラまたはマイクなどのデータソースの識別子を意味する。ＣＳＲＣフィールドはＲＴＰパケットが中間システムで混合された場合にそのソースを区別できる識別子を示す。
【０００９】
図２はマッピングされたＳＬヘッダの構造を示す図である。
図２を参照すれば、マッピングされたＳＬヘッダ１２０はペイロードサイズフィールド２１０、インデックス/インデックスデルタフィールド２２０、コンポジションタイムスタンプフラグ(Composition Time Stamp Flag: ＣＴＳＦｌａｇ)フィールド２３０、コンポジションタイムスタンプデルタ(Composition Time Stamp Delta : ＣＴＳＤｅｌｔａ)フィールド２４０、デコーディングタイムスタンプフラグ(Decoding Time Stamp Flag: ＤＴＳＦｌａｇ)フィールド２５０、デコーディングタイムスタンプデルタ(Decoding Time Stamp Delta : ＤＣＴＳＤｅｌｔａ)フィールド２６０で構成される。
【００１０】
ペイロードサイズフィールド２１０には同一なＲＴＰパケットに存在する関連されているＳＬパケットのサイズがバイトで表示され記録される。ＳＬパケットが分割された場合にペイロードサイズは全体ＳＬパケットのサイズを意味する。
【００１１】
インデックス/インデックスデルタフィールド２２０には分割されたＳＬデータのシリアルナンバーが記録される。ＳＬパケットのシリアルナンバーは１ずつ増加される。シリアルナンバーは最初のＳＬヘッダにだけ記録され、後続するＳＬヘッダには記録されない。最初ＳＬヘッダではなくＳＬヘッダにシリアルナンバーをエンコーディングするためインデックス/インデックスデルタフィールド２２０が使用される。インデックス/インデックスデルタフィールド２２０には以前ＳＬパケットとのシリアルナンバーの差が記録される。従って、ｎ番目ＳＬパケットのシリアルナンバーはｎ-１番目ＳＬパケットのインデックスとｎ番目ＳＬパケットのインデックスデルタを足した値に１を足すことによって求められる。それぞれのインデックス/インデックスデルタフィールド２２０が０にセッティングされている場合はＳＬパケットのシリアルナンバーは特定されていないことから、受信機はインデックス/インデックスデルタフィールド２２０を無視する。
【００１２】
ＣＴＳＦｌａｇフィールド２３０にはＣＴＳデルタの存否が記録される。ＣＴＳＦｌａｇが１ならＣＴＳデルタが存在することを意味し、ＣＴＳＦｌａｇが０ならＣＴＳデルタが存在しないことを意味する。もしＣＴＳデルタ長さが０でなければ、ＳＬパケットが接続ユニットの開始か否かを問わずＣＴＳデルタフィールド２４０が存在する。この場合、ＣＴＳＦｌａｇフィールド２３０の値は最初のＳＬヘッダについては０であり、以降のＳＬヘッダについては１になる。ＣＴＳＦｌａｇフィールド２３０の大きさは１ビットである。
【００１３】
ＣＴＳデルタフィールド２４０にはＲＴＰパケットのＲＴＰヘッダ内に存在するタイムスタンプに対する２の補数で示したＣＴＳ値が記録される。各ＣＴＳデルタフィールド２４０のビット数はＣＴＳデルタ長さパラメータによって特定される。ＲＴＰパケット内の最初ＳＬパケットのＣＴＳはＲＴＰタイムスタンプにマッピングされるのでそれぞれのＲＴＰパケットの最初多重ＳＬパケットヘッダのＣＴＳＦｌａｇは常に０である。
【００１４】
ＤＴＳＦｌａｇフィールド２５０にはＤＴＳデルタの存否が記録される。ＤＴＳＦｌａｇが１ならＤＴＳデルタが存在することを意味し、ＤＴＳＦｌａｇが０ならばＤＴＳデルタが存在しないことを意味する。受信機はＳＬヘッダのデコーディングタイムスタンプを再構成するためにＤＴＳＦｌａｇを必要とする。もしＤＴＳデルタ長さが０でなければ、ＳＬパケットが接続ユニットの開始か否かを問わずＤＴＳデルタフィールド２６０が存在する。この場合、ＤＴＳＦｌａｇフィールド２５０の値は最初のＳＬヘッダについては０であり、以降のＳＬヘッダについては１になる。ＤＴＳＦｌａｇフィールド２５０の大きさは１ビットである。
【００１５】
ＤＴＳデルタフィールド２６０には生成時間からデコーディング時間を減じた値であるＤＴＳデルタが記録される。ＤＴＳデルタは同一なＳＬパケットをエンコーディングし常に正数である。各ＤＴＳデルタフィールド２６０のビット数はＤＴＳデルタ長さパラメータによって特定される。ＤＴＳデルタが０なら、すなわち生成時間とデコーディング時間が同一ならばＤＴＳＦｌａｇは０でありＤＴＳデルタフィールド２６０が存在しない。送信側でＤＴＳデルタの計算はロールオーバを考慮して行われる。例えば、タイムスタンプ長さが３である(４、３)、(５、４)、(６、５)、(７、６)、(０、７)のような(ＣＴＳ、ＤＴＳ)対を有するＳＬストリームについて、最後対に対するＤＴＳデルタは、-７ではなく１になるべきである。
【００１６】
残余ＳＬパケットヘッダ１３０は前述したペイロードフォーマットにマッピングするためにＳＬパケットヘッダに修正を加えた後残された部分である。残余ＳＬパケットヘッダ１３０にはＲＴＰヘッダ１１０またはマッピングされたＳＬパケットヘッダ１２０にマッピングされない情報が記録される。例えば、ＣＴＳＦｌａｇ、ＣＴＳ、ＤＴＳＦｌａｇ、ＤＴＳ、シリアル番号は除去されるが、接続ユニット終端フラグ(Access Unit End Flag : ＡＵＥＦ)はそれぞれの接続ユニットの終端を知らせる有用な情報なので除去されない。また、ＳＬパケットヘッダがＯＣＲを含めば、ＯＣＲは２の補数差と表現され残余ＳＬパケット１３０に記録される。もしＯＣＲを有するＳＬパケットについてＣＴＳが存在しなければ、ＯＣＲはＲＴＰタイムスタンプとの差としてエンコーディングされる。ＳＬパケットヘッダ内に付加的な下向優先順位フィールドを使用するストリームについては適切なＱｏＳによってＲＴＰパケットを転送するために同一な下向優先順位を有するＳＬパケットだけ一つのＲＴＰパケットによって転送される。しかも、一つのＲＴＰパケットの一番目残余ＳＬヘッダだけ下向優先順位フィールドを有する。ＳＬパケットペイロード１４０にはＲＴＰパケットを通して転送されるＭＰＥＧ-４ストリームが収容される。
【００１７】
以上のように複数のＳＬパケットを一つのＲＴＰパケットにマッピングする場合、不要なオーバーヘッドを避けるためにＳＬパケットヘッダとＲＴＰパケットヘッダで重複される部分は除去されることが望ましい。従来のＭＰＥＧ-４転送システムではＲＴＰヘッダによって提供されるパラメータによって同期を取得する。ＳＬヘッダが使用される場合に重複されるフィールドはＳＬヘッダから除去される。重複されるフィールドが除去されたＳＬヘッダの残り情報はＲＴＰパケットのペイロード内にＳＬパケットのペイロードと共に収容される。
【００１８】
参考に、前述した標準によって生成された多重ＳＬパケットを復元するための従来の多重ＳＬパケット復元方法は次の通りである。
多重ＳＬパケットの一番目パケットのパケットシーケンス番号は０でありこの値がインデックスになる。残りＳＬパケットのパケットシーケンス番号は以前ＳＬパケットのパケットシーケンス番号と該当ＳＬパケットのインデックスデルタ値を足した値に１を足した値になる。
【００１９】
ＣＴＳ及びＤＴＳは差異値が記録されるので、その復元のためにタイムスタンプフラグが使用される。ＲＴＰタイムスタンプは３２ビットであり、ＲＴＰタイムスタンプは多様な値のＳＬタイムスタンプ値にマッピングされる。ＳＬタイムスタンプが３２ビットを超えればＲＴＰタイムスタンプの最下位ビットがＳＬタイムスタンプになる。これとは違って、ＳＬタイムスタンプが３２ビット未満ならばＲＴＰタイムスタンプに０から整数単位に増加する値を順次に足した値がＳＬタイムスタンプになる。もし、ＳＬタイムスタンプが３２ビットならばＲＴＰタイムスタンプがそのままマッチングされる。
【００２０】
ＣＴＳデルタ長さが定義されておらずタイムスタンプが使用される場合ＲＴＰパケット内で一番目ＳＬパケットのＣＴＳＦｌａｇは１になり、ＲＴＰタイムスタンプは、ＣＴＳにマッピングされる。一方、ＣＴＳデルタ長さが定義されておらず、タイムスタンプが使用されなければ一番目ＳＬパケットのＣＴＳＦｌａｇ及びＣＴＳは無視される。この際、残りＳＬパケットのＣＴＳＦｌａｇ及びＣＴＳフィールドは空きにする。
【００２１】
これとは違って、ＣＴＳデルタ長さが定義されておりタイムスタンプが使用される場合、接続ユニット開始フラグが１ならば多重ＳＬパケットのタイムスタンプがＣＴＳＦｌａｇになり、多重ＳＬパケットのＣＴＳデルタとＳＬパケットのタイムスタンプを合した値がＣＴＳになる。ＣＴＳデルタ長さが定義されており、タイムスタンプが使用される場合、接続ユニット開始フラグが１でなければＣＴＳＦｌａｇは無視される。一方、ＣＴＳデルタ長さが定義されておりタイムスタンプが使用されなければ、受信側はＣＴＳＦｌａｇを無視する。
【００２２】
ＤＴＳデルタ長さが定義されていない場合、タイムスタンプを使用し接続ユニット開始フラグが１ならばＤＴＳＦｌａｇは０である。これとは違って、ＤＴＳデルタ長さが定義されていない場合、タイムスタンプを使用し接続ユニット開始フラグが１でなければＤＴＳＦｌａｇは無視される。一方、ＤＴＳデルタ長さが定義されている場合、タイムスタンプを使用し接続ユニット開始フラグが１ならばＤＴＳＦｌａｇは多重ＳＬパケットヘッダのＤＴＳフラグになり、ＤＴＳはＣＴＳから多重ＳＬパケットヘッダのＤＴＳデルタを減じた値になる。これとは違って、ＤＴＳデルタ長さが定義されている場合、タイムスタンプを使用し接続ユニット開始フラグが１でなければＤＴＳＦｌａｇは無視される。ＤＴＳデルタ長さは定義されているがタイムスタンプを使用していなければ、受信側はＤＴＳＦｌａｇを無視する。
【００２３】
しかし、従来の多重ＳＬパケット生成方法はタイムスタンプの長さが３２未満の場合はＲＴＰタイムスタンプの長さである３２ビットを十分に活用できない問題点がある。またＣＴＳの値がロールオーバ(roll-over)する場合、ＣＴＳデルタ値が大きくなってＣＴＳデルタ値を使用する目的であるビット数の節減効果を達成することができない。一方、タイムスタンプの長さが３２以上であるＳＬパケットについては従来の多重ＳＬパケット生成方法が使用できないという短所がある。また、従来の方法はＣＴＳやＤＴＳのロールオーバ発生時負数が現れ、その値が大きくなる場合もあるという問題がある。
【００２４】
【発明が解決しようとする課題】
本発明は前述した問題点を解決するために案出されたもので、その目的はＲＴＰタイムスタンプの長さが効率的に使用でき、規定されたＲＴＰタイムスタンプの長さを超えるＳＬパケットも多重ＳＬパケット化の可能なＲＴＰパケット生成装置及び方法を提供するところにある。
本発明の他の目的は、複数のＳＬパケットを収容するＲＴＰパケットの復元装置及び方法を提供するところにある。
【００２５】
【課題を解決するための手段】
前述した技術的課題を達成するための本発明に係るＲＴＰパケット生成装置は、複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number : ＰＳＮ)を付与し、前記ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor :ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する設定部及び前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成するパケット生成部を有する。
【００２６】
前記設定部は、前記ＳＬパケットそれぞれについてパケット生成順序に基づき１から順次に増加する前記ＣＴＳを付与するＣＴＳ生成部、前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＤＴＳを付与するＤＴＳ生成部、前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＰＳＮを付与するＰＳＮ生成部、及び前記ＳＬパケット内のＳＬ設定記述子から前記タイムスタンプ長さ及び前記パケットシーケンス番号長さを抽出する抽出部を備える。
【００２７】
前記パケット生成部は、前記ＣＴＳに基づき算出されたＲＴＰタイムスタンプを含むＲＴＰパケットヘッダを生成するＲＴＰパケットヘッダ生成部、前記ＣＴＳ及び前記ＲＴＰタイムスタンプに基づきＣＴＳデルタを生成するＣＴＳデルタ生成部、前記ＣＴＳ及び前記ＤＴＳに基づきＤＴＳデルタを生成するＤＴＳデルタ生成部、及び前記ＰＳＮ、前記インデックス長さ、及び前記インデックスデルタ長さを入力されインデックス/インデックスデルタを生成するインデックス/インデックスデルタ生成部を備える。
【００２８】
本発明に係るＲＴＰパケット生成方法は、複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number : ＰＳＮ)を付与する段階、前記ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor :ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する段階及び前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成する段階と、を含む。
【００２９】
前記付与段階は、前記ＲＴＰパケットに最初に収容される前記ＳＬパケットの前記ＣＴＳに基づき前記ＲＴＰパケットのヘッダに記録されるＲＴＰタイムスタンプを決める第１決定段階及び決定された前記ＲＴＰタイムスタンプ、前記ＣＴＳ、前記ＤＣＴ、前記ＰＳＮ、及びインデックスデルタ長さに基づき前記ＳＬパケットのヘッダに記録されるＣＴＳデルタ、ＤＴＳデルタ、及びインデックス/インデックスデルタを決定する第２決定段階を有する。
望ましくは、前記第１決定段階は次の式によって前記ＲＴＰタイムスタンプを決定する。
ＲＴＰタイムスタンプ＝（最初ＳＬパケットのＣＴＳ）％（ＲＴＰタイムスタンプの長さ）
望ましくは、前記第２決定段階は次の式によって前記ＣＴＳデルタ、前記ＤＴＳデルタ、前記インデックス、及び前記インデックスデルタを決定する。
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＲＴＰタイムスタンプ、
ＤＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＤＴＳ（ｉ）、
インデックス（０）＝ＰＳＮ（０）％２インデックス長さ
インデックスデルタ（ｉ）＝（ＰＳＮ（ｉ）-ＰＳＮ（ｉ−１）％２インデックスデルタ長さ
但し、ｉは前記ＳＬパケットのパケットシーケンス番号である。
【００３０】
一方、本発明に係るＲＴＰパケット復元装置は、ＲＴＰタイムスタンプを復元する第１復元部と、前記ＲＴＰタイムスタンプ及び一番目ＳＬパケットのＣＴＳデルタから一番目ＳＬパケットのＣＴＳを復元し、復元された一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳデルタから残りＳＬパケットのＣＴＳを復元する第２復元部、ＣＴＳ及びＤＴＳデルタから前記ＳＬパケットそれぞれのＤＴＳを復元する第３復元部及び一番目ＳＬパケットのインデックスから一番目ＳＬパケットのＰＳＮを復元し、復元された一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのインデックスデルタから残りＳＬパケットのＰＳＮを復元する第４復元部を有する。
望ましくは、前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更部及び前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する第２変更部をさらに備える。
【００３１】
本発明に係るＲＴＰパケット復元方法は、受信されたＲＴＰパケットからＲＴＰタイムスタンプを抽出し、前記ＲＴＰパケットのペイロード内のそれぞれのＳＬパケットに対するＣＴＳを復元する段階と、前記ＣＴＳ及びそれぞれの前記ＳＬパケットから抽出されたＤＴＳデルタからＤＴＳを復元する段階及び前記ＳＬパケットから抽出されたインデックス及びインデックスデルタに基づきＰＳＮを復元する段階と、を備える。
望ましくは、前記ＣＴＳ復元段階は次の式によって前記ＣＴＳを復元する。
ＣＴＳ(１)=ＲＴＰタイムスタンプ
ＣＴＳ(ｉ)=ＣＴＳ(１)+ＣＴＳデルタ(ｉ)
望ましくは、前記ＤＴＳ復元段階は次の式によって前記ＤＴＳを復元する。
ＤＴＳ(ｉ)=ＣＴＳ(ｉ)-ＤＴＳデルタ(ｉ)
望ましくは、前記ＰＳＮ復元段階は次の式によって前記ＰＳＮを復元する。
ＰＳＮ(０)=インデックス
ＰＳＮ(ｉ)=ＰＳＮ(ｉ-１)＋インデックスデルタ(ｉ)＋１
前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更段階、及び前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する段階をさらに含むことが望ましい。
望ましくは、前記第１変更段階は次の式によって前記ＣＴＳ及び前記ＤＴＳを変更する。
ＣＴＳ'(ｉ)=ＣＴＳ(ｉ)％タイムスタンプ長さ
ＤＴＳ'(ｉ)=ＤＴＳ(ｉ)％タイムスタンプ長さ
望ましくは、前記第２変更段階は次の式によって前記ＰＳＮを変更する。
ＰＳＮ'(ｉ)=ＰＳＮ(ｉ)％パケットシーケンス番号長さ
以上の式において、ｉは前記ＳＬパケットのパケットシーケンス番号である。
【００３２】
【発明の実施の形態】
以下、添付した図面に基づき本発明の望ましい実施例を詳述する。それぞれの図面において同一な参照番号は同一な構成要素を付する。
図３は本発明に係るＲＴＰパケット生成装置の一実施例に対する構成を示すブロック図であり、図４は本発明に係るＲＴＰパケット生成方法の一実施例の流れ図である。
【００３３】
図３及び図４を参照すれば、本発明に係るＲＴＰパケット生成装置は設定部３００及びパケット生成部３３０を有する。
設定部３００は複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number: ＰＳＮ)を付与し、ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor:ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する。
【００３４】
設定部３００はＣＴＳ生成部３０５、ＤＴＳ生成部３１０、ＰＳＮ生成部３１５、及びインデックス長さ及びインデックスデルタ長さ抽出部３２０を有する。通常、ＳＬパケット内のＳＬ設定記述子のタイムスタンプ長さに定められた長さほどエンコーディングされたＣＴＳ、ＤＴＳ、及びＰＳＮをそれぞれＥＣＴＳ、ＥＤＴＳ、及びＥＰＳＮとし、タイムスタンプ長さ、インデックス長さ、インデックスデルタ長さ、及びパケットシーケンス番号長さが次のように与えられる時、各ＳＬパケットに対するＥＴＣＳ、ＥＤＴＳ、及びＥＰＳＮは次の通りである。
タイムスタンプ長さ=３、インデックス長さ=２、インデックスデルタ長さ=２、パケットシーケンス番号長さ=４
ＥＣＴＳ(１〜１５)={１、２、３、４、５、６、７、０、１、２、３、４、５、６、７}
ＥＤＴＳ(１〜１５)={０、１、２、３、４、５、６、７、０、１、２、３、４、５、６}
ＥＰＳＮ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
この値がＳＬパケット内のタイムスタンプとして適用される。ここで、ＥＣＴＳ(ｊ)、ＥＤＴＳ(ｊ)及びＥＳＰＮ(ｊ)のｊはパケット番号を意味する。しかし、このような方式で定められたＣＴＳ、ＤＴＳ、及びＰＳＮは本発明に適用するのに不向きな値である。
【００３５】
従って、ＣＴＳ生成部３０５はＥＴＣＳから正確度が無限なＣＴＳを生成する。また、ＤＴＳ生成部３１０はＥＤＴＳから正確度が無限なＤＴＳを生成する。また、ＰＳＮ生成部３１５はＥＰＳＮから正確度が無限なＰＳＮを付与する(Ｓ４００)。
【００３６】
ＣＴＳ生成部３０５、ＤＴＳ生成部３１０、及びＰＳＮ生成部３１５で付与したそれぞれの値をＯＣＴＳ、ＯＤＴＳ、及びＯＰＳＮとすれば、それぞれのＳＬパケットに対する値は次の通りである。ここで、１〜１０はそれぞれＳＬパケットの番号に該当する。
ＯＣＴＳ(１〜１５)={１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５}
ＯＤＴＳ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
ＯＰＳＮ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
【００３７】
抽出部３２０はＳＬパケット内のＳＬ設定記述子からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する。
【００３８】
パケット生成部３３０はＣＴＳ、ＤＴＳ、ＰＳＮ、タイムスタンプ長さ、及びパケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つのＲＴＰパケットに収容されるＳＬパケットのヘッダを生成する。
パケット生成部３３０はＲＴＰパケットヘッダ生成部３４０及びＳＬパケットヘッダ生成部３５０を有する。
【００３９】
ＲＴＰパケットヘッダ生成部３４０はＣＴＳ生成部３０５で生成されたＯＣＴＳ値に基づきＲＴＰタイムスタンプを生成し(Ｓ４１０)、生成されたＲＴＰタイムスタンプを含むＲＴＰパケットヘッダを生成する(Ｓ４２０)。もし一つのＲＴＰパケットに５個のＳＬパケットが収容されれば、ＲＴＰパケット内の一番目ＳＬパケットのＯＣＴＳをＲＴＰタイムスタンプ長さである３２で割った残りがＲＴＰタイムスタンプと決定される。これを式で表現すれば次の通りである。
[式６]
ＲＴＰタイムスタンプ＝（最初ＳＬパケットのＣＴＳ）％（ＲＴＰタイムスタンプの長さ）
従って、それぞれのＲＴＰパケットのＲＴＰタイムスタンプは１、６、１１になる。
【００４０】
ＳＬパケットヘッダ生成部３５０はＣＴＳデルタ生成部３５５、ＤＴＳデルタ生成部３６０、及びインデックス/インデックスデルタ生成部３６５を有する。ＣＴＳデルタ生成部３５５はＣＴＳ生成部３０５から入力されたそれぞれのＳＬパケットに対するＣＴＳ値及びＲＴＰパケットヘッダ生成部３４０で生成されたＲＴＰタイムスタンプに基づき次の式によってそれぞれのＳＬパケットに対するＣＴＳデルタ値を生成する(Ｓ４３０)。
[式７]
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）-ＲＴＰタイムスタンプ
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットに収容されるＳＬパケットに対するＣＴＳデルタ値は次の通りである。
ＣＴＳデルタ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＣＴＳデルタ(６〜１０)={０、１、２、３、４} : 二番目ＲＴＰパケット
ＣＴＳデルタ(１１〜１５)={０、１、２、３、４} : 三番目ＲＴＰパケット
【００４１】
ＤＴＳデルタ生成部３５５はＣＴＳ生成部３０５から入力されたそれぞれのＳＬパケットに対するＣＴＳ値及びＤＴＳ生成部３４０から入力されたそれぞれのＳＬパケットに対するＤＴＳ値に基づき、次の式によってそれぞれのＳＬパケットに対するＤＴＳデルタ値を生成する(Ｓ４４０)。
[式８]
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）-ＤＴＳ（ｉ）
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
【００４２】
それぞれのＲＴＰパケットに収容されるＳＬパケットに対するＤＴＳデルタ値は次の通りである。
ＤＴＳデルタ(１〜５)={１、１、１、１、１} : 一番目ＲＴＰパケット
ＤＴＳデルタ(６〜１０)={１、１、１、１、１} : 二番目ＲＴＰパケット
ＤＴＳデルタ(１１〜１５)={１、１、１、１、１} : 三番目ＲＴＰパケット
【００４３】
インデックス/インデックスデルタ生成部３６５はＰＳＮ生成部３１５で入力されたそれぞれのＳＬパケットに対するＰＳＮ値及びインデックス長さ及びインデックスデルタ長さ抽出部３４０から入力されたそれぞれのＳＬパケットに対するインデックス長さまたはインデックスデルタ長さに基づき、次の式によってそれぞれのＳＬパケットに対するインデックス/インデックスデルタ値を生成する(Ｓ４５０)。
[式９]
インデックス（０）＝ＰＳＮ（０）％２インデックス長さ
[式１０]
インデックスデルタ（ｉ）＝（ＰＳＮ（ｉ）-ＰＳＮ（ｉ−１））％２インデックスデルタ長さ
式９は各ＲＴＰパケットの一番目ＳＬパケットに対するインデックスを求めるための式であり、[数５]は各ＲＴＰパケットの二番目以上のＳＬパケットに対するインデックスデルタを求めるための式である。
式１０において、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。それぞれのＲＴＰパケットに収容されるＳＬパケットに対するインデックス及びインデックスデルタ値は次の通りである。
インデックス=０、インデックスデルタ(２〜５)={０、０、０、０} : 一番目ＲＴＰパケット
インデックス=１、インデックスデルタ(７〜１０)={０、０、０、０} : 二番目ＲＴＰパケット
インデックス=２、インデックスデルタ(１２〜１５)={０、０、０、０} : 三番目ＲＴＰパケット
【００４４】
以上のＣＴＳデルタ、ＤＴＳデルタ、及びインデックス/インデックスデルタは生成されたＳＬパケットヘッダに記録され(Ｓ４６０)、最終的に複数のＳＬパケットを収容するＲＴＰパケットが生成される。
【００４５】
図５は本発明に係るＲＴＰパケット復元装置の一実施例に対する構成を示すブロック図であり、図６は本発明に係るＲＴＰパケット復元方法の流れ図である。図５及び図６を参照すれば、本発明に係るＲＴＰパケット復元装置は、ＲＴＰタイムスタンプ復元部５１０、ＣＴＳ復元部５２０、ＤＴＳ復元部５３０、及びＰＳＮ復元部５４０を有する。
【００４６】
ＲＴＰタイムスタンプ復元部５１０は受信されたＲＴＰパケットヘッダからＲＴＰタイムスタンプを抽出する(Ｓ６００)。従って、図３及び図４を参照して説明したＲＴＰパケット生成装置及び方法によって生成されたＲＴＰパケットを受信した場合に、それぞれのＲＴＰパケットについてＲＴＰタイムスタンプ復元部５１０で抽出されたＲＴＰタイムスタンプはそれぞれ１、６、１１になる。
【００４７】
ＣＴＳ復元部５２０はＲＴＰタイムスタンプ復元部５１０から入力されたＲＴＰタイムスタンプ及び一番目ＳＬパケットのＣＴＳデルタから一番目ＳＬパケットのＣＴＳを復元し、復元された一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳデルタから残りＳＬパケットのＣＴＳを復元する(Ｓ６１０)。一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳは次の式によって復元される。
[式１１]
ＣＴＳ(１)=ＲＴＰタイムスタンプ
ＣＴＳ(ｉ)=ＣＴＳ(１)+ＣＴＳデルタ(ｉ)
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＣＴＳは次の通りである。
ＣＴＳ(１〜５)={１、２、３、４、５} : 一番目ＲＴＰパケット
ＣＴＳ(６〜１０)={６、７、８、９、１０} : 二番目ＲＴＰパケット
ＣＴＳ(１１〜１５)={１１、１２、１３、１４、１５} : 三番目ＲＴＰパケット
【００４８】
ＤＴＳ復元部５３０は次の式によってＣＴＳ及びＤＴＳデルタからＳＬパケットそれぞれのＤＴＳを復元する(Ｓ６２０)。
[式１２]
ＤＴＳ(ｉ)=ＣＴＳ(ｉ)-ＤＴＳデルタ(ｉ)
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＤＴＳは次の通りである。
ＤＴＳ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＤＴＳ(６〜１０)={５、６、７、８、９} : 二番目ＲＴＰパケット
ＤＴＳ(１１〜１５)={１０、１１、１２、１３、１４} : 三番目ＲＴＰパケット
【００４９】
ＰＳＮ復元部５４０は一番目ＳＬパケットのインデックスから一番目ＳＬパケットのＰＳＮを復元し、復元された一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのインデックスデルタから残りＳＬパケットのＰＳＮを復元する(Ｓ６３０)。一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのＰＳＮは次の式によって復元される。
[式１３]
ＰＳＮ(１)=インデックス
ＰＳＮ(ｉ)=ＰＳＮ(ｉ-１)+インデックスデルタ(ｉ)+１
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＰＳＮは次の通りである。
ＰＳＮ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＰＳＮ(６〜１０)={５、６、７、８、９} : 二番目ＲＴＰパケット
ＰＳＮ(１１〜１５)={１０、１１、１２、１３、１４} : 三番目ＲＴＰパケット
【００５０】
一方、復元されたＣＴＳ及びＤＴＳは設定されているタイムスタンプ長さと一致するよう変更されることが望ましい(Ｓ６４０)。この場合、本発明に係るＲＴＰパケット復元装置はタイムスタンプ変更部(図示せず)をさらに備える。タイムスタンプ変更部は次の式によって復元されたＣＴＳ及びＤＴＳを変更する。
[式１４]
ＣＴＳ'(ｉ)=ＣＴＳ(ｉ)％タイムスタンプ長さ
ＤＴＳ'(ｉ)=ＤＴＳ(ｉ)％タイムスタンプ長さ
【００５１】
また、復元されたＰＳＮも設定されているパケットシーケンス番号長さと一致するよう変更されることが望ましい。この場合、本発明に係るＲＴＰパケット復元装置はパケットシーケンス番号変更部(図示せず)をさらに備える。パケットシーケンス変更部は次の式によって復元されたＰＳＮを変更する。
[式１５]
ＰＳＮ'(ｉ)=ＰＳＮ(ｉ)％パケットシーケンス番号長さ、
[式１４]及び[式１５]において、ｉはＳＬパケットのパケットシーケンス番号である。
以上の変更過程を通して変更されたそれぞれのＲＴＰパケットに対するＣＴＳ、ＤＴＳ、及びＰＳＮは次の通りである。
一番目ＲＴＰパケット:
ＣＴＳ'(１〜５)={１、２、３、４、５}
ＤＴＳ'(１〜５)={０、１、２、３、４}
ＰＳＮ'(１〜５)={０、１、２、３、４}
二番目ＲＴＰパケット:
ＣＴＳ'(６〜１０)={６、７、０、１、２}
ＤＴＳ'(６〜１０)={５、６、７、０、１}
ＰＳＮ'(６〜１０)={５、６、７、８、９}
三番目ＲＴＰパケット:
ＣＴＳ'(１１〜１５)={３、４、５、６、７}
ＤＴＳ'(１１〜１５)={２、３、４、５、６}
ＰＳＮ'(１１〜１５)={１０、１１、１２、１３、１４}
【００５２】
図７はＳＬパケットから多重ＳＬ ＲＴＰパケットを生成する過程を示す図であり、図８は受信された多重ＳＬ ＲＴＰパケットからＣＴＳ、ＤＴＳ、ＰＳＮを復元する過程を示す図である。
図７及び図８を参照すれば、ＳＬパケット層はＳＬ設定記述子のタイムスタンプ長さによる長さを有するＣＴＳ、ＤＴＳ及びＳＬ設定記述子のタイムスタンプ長さによる長さを有するＰＳＮがそれぞれＥＣＴＳ、ＥＤＴＳ、及びＥＰＳＮと表現されている。ＳＬパケット層に存在するそれぞれの要素は生成値階層の生成されたＣＴＳ、生成されたＤＴＳ、及び生成されたＰＳＮに対応される。そして、ＳＬパケット階層の要素は生成値階層の要素に基づき多重ＳＬ階層の要素で表現されＲＴＰパケット内に収容される。ＲＴＰパケットにカプセル化された複数のＳＬパケットは受信端で生成時の階層順序とは逆に各階層を進んで最終的にそれぞれのＳＬパケットに分離され、受信端はＳＬパケットに転送されたＭＰＥＧ-４ストリームを復元できるようになる。
【００５３】
以上で代表的な実施例を通して本発明について詳細に説明したが、本発明の属する技術分野において通常の知識を有する者は前述した実施例について本発明の範疇から逸脱しない限度内で多様な変形が可能なことを理解できろう。従って、本発明の権利範囲は説明された実施例に限って定められてはいけなく、特許請求の範囲だけではなく本特許請求の範囲と均等なものによって定められるべきである。
【００５４】
【発明の効果】
以上述べた通り、本明に係るＲＴＰパケット生成装置及び方法によれば、複数のＳＬパケットを一つのＲＴＰパケットに転送する場合、それぞれのＳＬパケットに対するＣＴＳ、ＤＴＳ、及びＰＳＮ情報を以前ＳＬパケットとの差異値だけを記録するので、ＣＴＳ値がロールオーバする場合にもビット数を減らせることができ、タイムスタンプ長さが３２以上であるＳＬパケットも多重ＳＬパケット化できるようになる。また、ＤＴＳデルタの値は常に正数になるべきであるところ、本発明に係るＲＴＰパケット生成装置及び方法によれば、ＤＴＳデルタ値が常に正数になり、大きい値のＤＴＳデルタが発生することを防止することができる。しかも、ＰＳＮについてロールオーバが発生する場合も割当てられたインデックスデルタ値に適した値を生成することができる。また、送信端でロールオーバ発生有無に対する検査を行なう必要がなく、受信端においてはロールオーバ回数だけ検査すればそれぞれの情報をそのまま使用できるため、送信端におけるエンコーディング及び受信端におけるデコーディング過程が簡単になる。
【図面の簡単な説明】
【図１】 複数のＳＬパケットが収容されたＲＴＰパケットを示す図、
【図２】 マッピングされたＳＬヘッダの構造を示す図、
【図３】 本発明に係るＲＴＰパケット生成装置の一実施例に対する構成を示すブロック図、
【図４】 本発明に係るＲＴＰパケット生成方法の一実施例の流れ図、
【図５】 本発明に係るＲＴＰパケット復元装置の一実施例に対する構成を示すブロック図、
【図６】 本発明に係るＲＴＰパケット復元方法の流れ図、
【図７】 ＳＬパケットから多重ＳＬ ＲＴＰパケットを生成する過程を示す図、
【図８】 受信された多重ＳＬ ＲＴＰパケットからＣＴＳ、ＤＴＳ、ＰＳＮを復元する過程を示す図である。
【符号の説明】
３００:設定部
３０５:ＣＴＳ生成部
３１０:ＤＴＳ生成部
３１５:ＰＳＮ生成部
３２０:インデックス長さ、インデックスデルタ長さ抽出部
３３０:パケット生成部
３４０:ＲＴＰパケットヘッダ生成部
３５５:ＣＴＳデルタ生成部
３６０:ＤＴＳデルタ生成部
３６５:インデックス/インデックスデルタ生成部
【発明の属する技術分野】
本発明はＭＰＥＧ-４ストリームを転送するためのＲＴＰパケット生成/復元装置及び方法に係り、さらに詳しくはＭＰＥＧ-４ストリームを転送する複数のＳＬパケットを一つのＲＴＰパケット内に効率的にカプセル化するための装置及び方法に関する。
【０００２】
【従来の技術】
【０００３】
【特許文献１】
日本特開平１３―１４８８５３
【０００４】
システムマルチプレクサーを用いて多数のシンクレイヤーパケット（ＳＬパケット）を生成し、これはＲＴＰヘッダとシンクレイヤーヘッダ、リシンクマーク、Payloadから構成され、ＲＴＰパケットのtimestampでＳＬパケットのtimestampを利用。
【０００５】
インターネットエンジニアリングタスクフォース(Internet Engineering TaskForce : IETF)はＴＣＰ/ＩＰのようなインターネット運営プロトコルの標準を定義する主体であって、技術分野別に区分された下位チームを有する。ＭＰＥＧ-４ストリームを多重同期層(Synchronization Layer : ＳＬ)パケット化して実時間転送プロトコル(Real-time Transport Protocol : ＲＴＰ)に転送するためのＲＴＰフォーマットはDraft-IETF-AVT-MPEG4-MULTISL-02．TXTに記述されている。
【０００６】
現在、タイムスタンプ及びランダムアクセスのような転送特性情報を保存するために概念的なＳＬ層が定義されている。ＭＰＥＧ-４基本ストリームが転送される際、ＳＬ層からの転送情報は通常に実質的な転送層にマッピングされる。
【０００７】
図１は複数のＳＬパケットが収容されたＲＴＰパケットを示す図である。図１を参照すれば、ＲＴＰパケット１００はＲＴＰパケットヘッダ１１０、マッピングされたＳＬヘッダ１２０、残余ＳＬヘッダ１３０、及びＳＬパケットペイロード１４０とから構成される。
【０００８】
ＲＴＰパケットヘッダ１１０は固定サイズを有しヘッダの後に特定情報及びデータが後続する。ＲＴＰパケットヘッダの各フィールドを簡単に説明すれば、Ｖフィールドはバージョンフィールドであり、Ｐフィールドは３２ビット単位でパケットを構成するために使われる。Ｘフィールドはヘッダを拡張するか否かを表示する。ＣＣフィールドはＣＳＲＣ識別子(contributing source identifier)の個数を指す。Ｍフィールドはマルチメディア情報に対するフレーム領域を示す。すなわちパケット内で音声と映像情報などを区別するのに使用される。ＰＴフィールドはＲＦＣ１８９０で定義されたプロファイルのＲＴＰペイロードのフォームを指し、応用プログラムによって解釈される。シーケンス番号フィールドはＲＴＰパケットの順序を示す。timestampフィールドはＲＴＰパケットの一番目オクテットがサンプリングされた時点を示す。ＳＳＲＣ(Synchronization source)フィールドはカメラまたはマイクなどのデータソースの識別子を意味する。ＣＳＲＣフィールドはＲＴＰパケットが中間システムで混合された場合にそのソースを区別できる識別子を示す。
【０００９】
図２はマッピングされたＳＬヘッダの構造を示す図である。
図２を参照すれば、マッピングされたＳＬヘッダ１２０はペイロードサイズフィールド２１０、インデックス/インデックスデルタフィールド２２０、コンポジションタイムスタンプフラグ(Composition Time Stamp Flag: ＣＴＳＦｌａｇ)フィールド２３０、コンポジションタイムスタンプデルタ(Composition Time Stamp Delta : ＣＴＳＤｅｌｔａ)フィールド２４０、デコーディングタイムスタンプフラグ(Decoding Time Stamp Flag: ＤＴＳＦｌａｇ)フィールド２５０、デコーディングタイムスタンプデルタ(Decoding Time Stamp Delta : ＤＣＴＳＤｅｌｔａ)フィールド２６０で構成される。
【００１０】
ペイロードサイズフィールド２１０には同一なＲＴＰパケットに存在する関連されているＳＬパケットのサイズがバイトで表示され記録される。ＳＬパケットが分割された場合にペイロードサイズは全体ＳＬパケットのサイズを意味する。
【００１１】
インデックス/インデックスデルタフィールド２２０には分割されたＳＬデータのシリアルナンバーが記録される。ＳＬパケットのシリアルナンバーは１ずつ増加される。シリアルナンバーは最初のＳＬヘッダにだけ記録され、後続するＳＬヘッダには記録されない。最初ＳＬヘッダではなくＳＬヘッダにシリアルナンバーをエンコーディングするためインデックス/インデックスデルタフィールド２２０が使用される。インデックス/インデックスデルタフィールド２２０には以前ＳＬパケットとのシリアルナンバーの差が記録される。従って、ｎ番目ＳＬパケットのシリアルナンバーはｎ-１番目ＳＬパケットのインデックスとｎ番目ＳＬパケットのインデックスデルタを足した値に１を足すことによって求められる。それぞれのインデックス/インデックスデルタフィールド２２０が０にセッティングされている場合はＳＬパケットのシリアルナンバーは特定されていないことから、受信機はインデックス/インデックスデルタフィールド２２０を無視する。
【００１２】
ＣＴＳＦｌａｇフィールド２３０にはＣＴＳデルタの存否が記録される。ＣＴＳＦｌａｇが１ならＣＴＳデルタが存在することを意味し、ＣＴＳＦｌａｇが０ならＣＴＳデルタが存在しないことを意味する。もしＣＴＳデルタ長さが０でなければ、ＳＬパケットが接続ユニットの開始か否かを問わずＣＴＳデルタフィールド２４０が存在する。この場合、ＣＴＳＦｌａｇフィールド２３０の値は最初のＳＬヘッダについては０であり、以降のＳＬヘッダについては１になる。ＣＴＳＦｌａｇフィールド２３０の大きさは１ビットである。
【００１３】
ＣＴＳデルタフィールド２４０にはＲＴＰパケットのＲＴＰヘッダ内に存在するタイムスタンプに対する２の補数で示したＣＴＳ値が記録される。各ＣＴＳデルタフィールド２４０のビット数はＣＴＳデルタ長さパラメータによって特定される。ＲＴＰパケット内の最初ＳＬパケットのＣＴＳはＲＴＰタイムスタンプにマッピングされるのでそれぞれのＲＴＰパケットの最初多重ＳＬパケットヘッダのＣＴＳＦｌａｇは常に０である。
【００１４】
ＤＴＳＦｌａｇフィールド２５０にはＤＴＳデルタの存否が記録される。ＤＴＳＦｌａｇが１ならＤＴＳデルタが存在することを意味し、ＤＴＳＦｌａｇが０ならばＤＴＳデルタが存在しないことを意味する。受信機はＳＬヘッダのデコーディングタイムスタンプを再構成するためにＤＴＳＦｌａｇを必要とする。もしＤＴＳデルタ長さが０でなければ、ＳＬパケットが接続ユニットの開始か否かを問わずＤＴＳデルタフィールド２６０が存在する。この場合、ＤＴＳＦｌａｇフィールド２５０の値は最初のＳＬヘッダについては０であり、以降のＳＬヘッダについては１になる。ＤＴＳＦｌａｇフィールド２５０の大きさは１ビットである。
【００１５】
ＤＴＳデルタフィールド２６０には生成時間からデコーディング時間を減じた値であるＤＴＳデルタが記録される。ＤＴＳデルタは同一なＳＬパケットをエンコーディングし常に正数である。各ＤＴＳデルタフィールド２６０のビット数はＤＴＳデルタ長さパラメータによって特定される。ＤＴＳデルタが０なら、すなわち生成時間とデコーディング時間が同一ならばＤＴＳＦｌａｇは０でありＤＴＳデルタフィールド２６０が存在しない。送信側でＤＴＳデルタの計算はロールオーバを考慮して行われる。例えば、タイムスタンプ長さが３である(４、３)、(５、４)、(６、５)、(７、６)、(０、７)のような(ＣＴＳ、ＤＴＳ)対を有するＳＬストリームについて、最後対に対するＤＴＳデルタは、-７ではなく１になるべきである。
【００１６】
残余ＳＬパケットヘッダ１３０は前述したペイロードフォーマットにマッピングするためにＳＬパケットヘッダに修正を加えた後残された部分である。残余ＳＬパケットヘッダ１３０にはＲＴＰヘッダ１１０またはマッピングされたＳＬパケットヘッダ１２０にマッピングされない情報が記録される。例えば、ＣＴＳＦｌａｇ、ＣＴＳ、ＤＴＳＦｌａｇ、ＤＴＳ、シリアル番号は除去されるが、接続ユニット終端フラグ(Access Unit End Flag : ＡＵＥＦ)はそれぞれの接続ユニットの終端を知らせる有用な情報なので除去されない。また、ＳＬパケットヘッダがＯＣＲを含めば、ＯＣＲは２の補数差と表現され残余ＳＬパケット１３０に記録される。もしＯＣＲを有するＳＬパケットについてＣＴＳが存在しなければ、ＯＣＲはＲＴＰタイムスタンプとの差としてエンコーディングされる。ＳＬパケットヘッダ内に付加的な下向優先順位フィールドを使用するストリームについては適切なＱｏＳによってＲＴＰパケットを転送するために同一な下向優先順位を有するＳＬパケットだけ一つのＲＴＰパケットによって転送される。しかも、一つのＲＴＰパケットの一番目残余ＳＬヘッダだけ下向優先順位フィールドを有する。ＳＬパケットペイロード１４０にはＲＴＰパケットを通して転送されるＭＰＥＧ-４ストリームが収容される。
【００１７】
以上のように複数のＳＬパケットを一つのＲＴＰパケットにマッピングする場合、不要なオーバーヘッドを避けるためにＳＬパケットヘッダとＲＴＰパケットヘッダで重複される部分は除去されることが望ましい。従来のＭＰＥＧ-４転送システムではＲＴＰヘッダによって提供されるパラメータによって同期を取得する。ＳＬヘッダが使用される場合に重複されるフィールドはＳＬヘッダから除去される。重複されるフィールドが除去されたＳＬヘッダの残り情報はＲＴＰパケットのペイロード内にＳＬパケットのペイロードと共に収容される。
【００１８】
参考に、前述した標準によって生成された多重ＳＬパケットを復元するための従来の多重ＳＬパケット復元方法は次の通りである。
多重ＳＬパケットの一番目パケットのパケットシーケンス番号は０でありこの値がインデックスになる。残りＳＬパケットのパケットシーケンス番号は以前ＳＬパケットのパケットシーケンス番号と該当ＳＬパケットのインデックスデルタ値を足した値に１を足した値になる。
【００１９】
ＣＴＳ及びＤＴＳは差異値が記録されるので、その復元のためにタイムスタンプフラグが使用される。ＲＴＰタイムスタンプは３２ビットであり、ＲＴＰタイムスタンプは多様な値のＳＬタイムスタンプ値にマッピングされる。ＳＬタイムスタンプが３２ビットを超えればＲＴＰタイムスタンプの最下位ビットがＳＬタイムスタンプになる。これとは違って、ＳＬタイムスタンプが３２ビット未満ならばＲＴＰタイムスタンプに０から整数単位に増加する値を順次に足した値がＳＬタイムスタンプになる。もし、ＳＬタイムスタンプが３２ビットならばＲＴＰタイムスタンプがそのままマッチングされる。
【００２０】
ＣＴＳデルタ長さが定義されておらずタイムスタンプが使用される場合ＲＴＰパケット内で一番目ＳＬパケットのＣＴＳＦｌａｇは１になり、ＲＴＰタイムスタンプは、ＣＴＳにマッピングされる。一方、ＣＴＳデルタ長さが定義されておらず、タイムスタンプが使用されなければ一番目ＳＬパケットのＣＴＳＦｌａｇ及びＣＴＳは無視される。この際、残りＳＬパケットのＣＴＳＦｌａｇ及びＣＴＳフィールドは空きにする。
【００２１】
これとは違って、ＣＴＳデルタ長さが定義されておりタイムスタンプが使用される場合、接続ユニット開始フラグが１ならば多重ＳＬパケットのタイムスタンプがＣＴＳＦｌａｇになり、多重ＳＬパケットのＣＴＳデルタとＳＬパケットのタイムスタンプを合した値がＣＴＳになる。ＣＴＳデルタ長さが定義されており、タイムスタンプが使用される場合、接続ユニット開始フラグが１でなければＣＴＳＦｌａｇは無視される。一方、ＣＴＳデルタ長さが定義されておりタイムスタンプが使用されなければ、受信側はＣＴＳＦｌａｇを無視する。
【００２２】
ＤＴＳデルタ長さが定義されていない場合、タイムスタンプを使用し接続ユニット開始フラグが１ならばＤＴＳＦｌａｇは０である。これとは違って、ＤＴＳデルタ長さが定義されていない場合、タイムスタンプを使用し接続ユニット開始フラグが１でなければＤＴＳＦｌａｇは無視される。一方、ＤＴＳデルタ長さが定義されている場合、タイムスタンプを使用し接続ユニット開始フラグが１ならばＤＴＳＦｌａｇは多重ＳＬパケットヘッダのＤＴＳフラグになり、ＤＴＳはＣＴＳから多重ＳＬパケットヘッダのＤＴＳデルタを減じた値になる。これとは違って、ＤＴＳデルタ長さが定義されている場合、タイムスタンプを使用し接続ユニット開始フラグが１でなければＤＴＳＦｌａｇは無視される。ＤＴＳデルタ長さは定義されているがタイムスタンプを使用していなければ、受信側はＤＴＳＦｌａｇを無視する。
【００２３】
しかし、従来の多重ＳＬパケット生成方法はタイムスタンプの長さが３２未満の場合はＲＴＰタイムスタンプの長さである３２ビットを十分に活用できない問題点がある。またＣＴＳの値がロールオーバ(roll-over)する場合、ＣＴＳデルタ値が大きくなってＣＴＳデルタ値を使用する目的であるビット数の節減効果を達成することができない。一方、タイムスタンプの長さが３２以上であるＳＬパケットについては従来の多重ＳＬパケット生成方法が使用できないという短所がある。また、従来の方法はＣＴＳやＤＴＳのロールオーバ発生時負数が現れ、その値が大きくなる場合もあるという問題がある。
【００２４】
【発明が解決しようとする課題】
本発明は前述した問題点を解決するために案出されたもので、その目的はＲＴＰタイムスタンプの長さが効率的に使用でき、規定されたＲＴＰタイムスタンプの長さを超えるＳＬパケットも多重ＳＬパケット化の可能なＲＴＰパケット生成装置及び方法を提供するところにある。
本発明の他の目的は、複数のＳＬパケットを収容するＲＴＰパケットの復元装置及び方法を提供するところにある。
【００２５】
【課題を解決するための手段】
前述した技術的課題を達成するための本発明に係るＲＴＰパケット生成装置は、複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number : ＰＳＮ)を付与し、前記ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor :ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する設定部及び前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成するパケット生成部を有する。
【００２６】
前記設定部は、前記ＳＬパケットそれぞれについてパケット生成順序に基づき１から順次に増加する前記ＣＴＳを付与するＣＴＳ生成部、前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＤＴＳを付与するＤＴＳ生成部、前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＰＳＮを付与するＰＳＮ生成部、及び前記ＳＬパケット内のＳＬ設定記述子から前記タイムスタンプ長さ及び前記パケットシーケンス番号長さを抽出する抽出部を備える。
【００２７】
前記パケット生成部は、前記ＣＴＳに基づき算出されたＲＴＰタイムスタンプを含むＲＴＰパケットヘッダを生成するＲＴＰパケットヘッダ生成部、前記ＣＴＳ及び前記ＲＴＰタイムスタンプに基づきＣＴＳデルタを生成するＣＴＳデルタ生成部、前記ＣＴＳ及び前記ＤＴＳに基づきＤＴＳデルタを生成するＤＴＳデルタ生成部、及び前記ＰＳＮ、前記インデックス長さ、及び前記インデックスデルタ長さを入力されインデックス/インデックスデルタを生成するインデックス/インデックスデルタ生成部を備える。
【００２８】
本発明に係るＲＴＰパケット生成方法は、複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number : ＰＳＮ)を付与する段階、前記ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor :ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する段階及び前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成する段階と、を含む。
【００２９】
前記付与段階は、前記ＲＴＰパケットに最初に収容される前記ＳＬパケットの前記ＣＴＳに基づき前記ＲＴＰパケットのヘッダに記録されるＲＴＰタイムスタンプを決める第１決定段階及び決定された前記ＲＴＰタイムスタンプ、前記ＣＴＳ、前記ＤＣＴ、前記ＰＳＮ、及びインデックスデルタ長さに基づき前記ＳＬパケットのヘッダに記録されるＣＴＳデルタ、ＤＴＳデルタ、及びインデックス/インデックスデルタを決定する第２決定段階を有する。
望ましくは、前記第１決定段階は次の式によって前記ＲＴＰタイムスタンプを決定する。
ＲＴＰタイムスタンプ＝（最初ＳＬパケットのＣＴＳ）％（ＲＴＰタイムスタンプの長さ）
望ましくは、前記第２決定段階は次の式によって前記ＣＴＳデルタ、前記ＤＴＳデルタ、前記インデックス、及び前記インデックスデルタを決定する。
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＲＴＰタイムスタンプ、
ＤＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＤＴＳ（ｉ）、
インデックス（０）＝ＰＳＮ（０）％２インデックス長さ
インデックスデルタ（ｉ）＝（ＰＳＮ（ｉ）-ＰＳＮ（ｉ−１）％２インデックスデルタ長さ
但し、ｉは前記ＳＬパケットのパケットシーケンス番号である。
【００３０】
一方、本発明に係るＲＴＰパケット復元装置は、ＲＴＰタイムスタンプを復元する第１復元部と、前記ＲＴＰタイムスタンプ及び一番目ＳＬパケットのＣＴＳデルタから一番目ＳＬパケットのＣＴＳを復元し、復元された一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳデルタから残りＳＬパケットのＣＴＳを復元する第２復元部、ＣＴＳ及びＤＴＳデルタから前記ＳＬパケットそれぞれのＤＴＳを復元する第３復元部及び一番目ＳＬパケットのインデックスから一番目ＳＬパケットのＰＳＮを復元し、復元された一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのインデックスデルタから残りＳＬパケットのＰＳＮを復元する第４復元部を有する。
望ましくは、前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更部及び前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する第２変更部をさらに備える。
【００３１】
本発明に係るＲＴＰパケット復元方法は、受信されたＲＴＰパケットからＲＴＰタイムスタンプを抽出し、前記ＲＴＰパケットのペイロード内のそれぞれのＳＬパケットに対するＣＴＳを復元する段階と、前記ＣＴＳ及びそれぞれの前記ＳＬパケットから抽出されたＤＴＳデルタからＤＴＳを復元する段階及び前記ＳＬパケットから抽出されたインデックス及びインデックスデルタに基づきＰＳＮを復元する段階と、を備える。
望ましくは、前記ＣＴＳ復元段階は次の式によって前記ＣＴＳを復元する。
ＣＴＳ(１)=ＲＴＰタイムスタンプ
ＣＴＳ(ｉ)=ＣＴＳ(１)+ＣＴＳデルタ(ｉ)
望ましくは、前記ＤＴＳ復元段階は次の式によって前記ＤＴＳを復元する。
ＤＴＳ(ｉ)=ＣＴＳ(ｉ)-ＤＴＳデルタ(ｉ)
望ましくは、前記ＰＳＮ復元段階は次の式によって前記ＰＳＮを復元する。
ＰＳＮ(０)=インデックス
ＰＳＮ(ｉ)=ＰＳＮ(ｉ-１)＋インデックスデルタ(ｉ)＋１
前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更段階、及び前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する段階をさらに含むことが望ましい。
望ましくは、前記第１変更段階は次の式によって前記ＣＴＳ及び前記ＤＴＳを変更する。
ＣＴＳ'(ｉ)=ＣＴＳ(ｉ)％タイムスタンプ長さ
ＤＴＳ'(ｉ)=ＤＴＳ(ｉ)％タイムスタンプ長さ
望ましくは、前記第２変更段階は次の式によって前記ＰＳＮを変更する。
ＰＳＮ'(ｉ)=ＰＳＮ(ｉ)％パケットシーケンス番号長さ
以上の式において、ｉは前記ＳＬパケットのパケットシーケンス番号である。
【００３２】
【発明の実施の形態】
以下、添付した図面に基づき本発明の望ましい実施例を詳述する。それぞれの図面において同一な参照番号は同一な構成要素を付する。
図３は本発明に係るＲＴＰパケット生成装置の一実施例に対する構成を示すブロック図であり、図４は本発明に係るＲＴＰパケット生成方法の一実施例の流れ図である。
【００３３】
図３及び図４を参照すれば、本発明に係るＲＴＰパケット生成装置は設定部３００及びパケット生成部３３０を有する。
設定部３００は複数の同期層(Synchronization Layer : ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number: ＰＳＮ)を付与し、ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor:ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する。
【００３４】
設定部３００はＣＴＳ生成部３０５、ＤＴＳ生成部３１０、ＰＳＮ生成部３１５、及びインデックス長さ及びインデックスデルタ長さ抽出部３２０を有する。通常、ＳＬパケット内のＳＬ設定記述子のタイムスタンプ長さに定められた長さほどエンコーディングされたＣＴＳ、ＤＴＳ、及びＰＳＮをそれぞれＥＣＴＳ、ＥＤＴＳ、及びＥＰＳＮとし、タイムスタンプ長さ、インデックス長さ、インデックスデルタ長さ、及びパケットシーケンス番号長さが次のように与えられる時、各ＳＬパケットに対するＥＴＣＳ、ＥＤＴＳ、及びＥＰＳＮは次の通りである。
タイムスタンプ長さ=３、インデックス長さ=２、インデックスデルタ長さ=２、パケットシーケンス番号長さ=４
ＥＣＴＳ(１〜１５)={１、２、３、４、５、６、７、０、１、２、３、４、５、６、７}
ＥＤＴＳ(１〜１５)={０、１、２、３、４、５、６、７、０、１、２、３、４、５、６}
ＥＰＳＮ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
この値がＳＬパケット内のタイムスタンプとして適用される。ここで、ＥＣＴＳ(ｊ)、ＥＤＴＳ(ｊ)及びＥＳＰＮ(ｊ)のｊはパケット番号を意味する。しかし、このような方式で定められたＣＴＳ、ＤＴＳ、及びＰＳＮは本発明に適用するのに不向きな値である。
【００３５】
従って、ＣＴＳ生成部３０５はＥＴＣＳから正確度が無限なＣＴＳを生成する。また、ＤＴＳ生成部３１０はＥＤＴＳから正確度が無限なＤＴＳを生成する。また、ＰＳＮ生成部３１５はＥＰＳＮから正確度が無限なＰＳＮを付与する(Ｓ４００)。
【００３６】
ＣＴＳ生成部３０５、ＤＴＳ生成部３１０、及びＰＳＮ生成部３１５で付与したそれぞれの値をＯＣＴＳ、ＯＤＴＳ、及びＯＰＳＮとすれば、それぞれのＳＬパケットに対する値は次の通りである。ここで、１〜１０はそれぞれＳＬパケットの番号に該当する。
ＯＣＴＳ(１〜１５)={１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５}
ＯＤＴＳ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
ＯＰＳＮ(１〜１５)={０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４}
【００３７】
抽出部３２０はＳＬパケット内のＳＬ設定記述子からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する。
【００３８】
パケット生成部３３０はＣＴＳ、ＤＴＳ、ＰＳＮ、タイムスタンプ長さ、及びパケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つのＲＴＰパケットに収容されるＳＬパケットのヘッダを生成する。
パケット生成部３３０はＲＴＰパケットヘッダ生成部３４０及びＳＬパケットヘッダ生成部３５０を有する。
【００３９】
ＲＴＰパケットヘッダ生成部３４０はＣＴＳ生成部３０５で生成されたＯＣＴＳ値に基づきＲＴＰタイムスタンプを生成し(Ｓ４１０)、生成されたＲＴＰタイムスタンプを含むＲＴＰパケットヘッダを生成する(Ｓ４２０)。もし一つのＲＴＰパケットに５個のＳＬパケットが収容されれば、ＲＴＰパケット内の一番目ＳＬパケットのＯＣＴＳをＲＴＰタイムスタンプ長さである３２で割った残りがＲＴＰタイムスタンプと決定される。これを式で表現すれば次の通りである。
[式６]
ＲＴＰタイムスタンプ＝（最初ＳＬパケットのＣＴＳ）％（ＲＴＰタイムスタンプの長さ）
従って、それぞれのＲＴＰパケットのＲＴＰタイムスタンプは１、６、１１になる。
【００４０】
ＳＬパケットヘッダ生成部３５０はＣＴＳデルタ生成部３５５、ＤＴＳデルタ生成部３６０、及びインデックス/インデックスデルタ生成部３６５を有する。ＣＴＳデルタ生成部３５５はＣＴＳ生成部３０５から入力されたそれぞれのＳＬパケットに対するＣＴＳ値及びＲＴＰパケットヘッダ生成部３４０で生成されたＲＴＰタイムスタンプに基づき次の式によってそれぞれのＳＬパケットに対するＣＴＳデルタ値を生成する(Ｓ４３０)。
[式７]
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）-ＲＴＰタイムスタンプ
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットに収容されるＳＬパケットに対するＣＴＳデルタ値は次の通りである。
ＣＴＳデルタ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＣＴＳデルタ(６〜１０)={０、１、２、３、４} : 二番目ＲＴＰパケット
ＣＴＳデルタ(１１〜１５)={０、１、２、３、４} : 三番目ＲＴＰパケット
【００４１】
ＤＴＳデルタ生成部３５５はＣＴＳ生成部３０５から入力されたそれぞれのＳＬパケットに対するＣＴＳ値及びＤＴＳ生成部３４０から入力されたそれぞれのＳＬパケットに対するＤＴＳ値に基づき、次の式によってそれぞれのＳＬパケットに対するＤＴＳデルタ値を生成する(Ｓ４４０)。
[式８]
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）-ＤＴＳ（ｉ）
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
【００４２】
それぞれのＲＴＰパケットに収容されるＳＬパケットに対するＤＴＳデルタ値は次の通りである。
ＤＴＳデルタ(１〜５)={１、１、１、１、１} : 一番目ＲＴＰパケット
ＤＴＳデルタ(６〜１０)={１、１、１、１、１} : 二番目ＲＴＰパケット
ＤＴＳデルタ(１１〜１５)={１、１、１、１、１} : 三番目ＲＴＰパケット
【００４３】
インデックス/インデックスデルタ生成部３６５はＰＳＮ生成部３１５で入力されたそれぞれのＳＬパケットに対するＰＳＮ値及びインデックス長さ及びインデックスデルタ長さ抽出部３４０から入力されたそれぞれのＳＬパケットに対するインデックス長さまたはインデックスデルタ長さに基づき、次の式によってそれぞれのＳＬパケットに対するインデックス/インデックスデルタ値を生成する(Ｓ４５０)。
[式９]
インデックス（０）＝ＰＳＮ（０）％２インデックス長さ
[式１０]
インデックスデルタ（ｉ）＝（ＰＳＮ（ｉ）-ＰＳＮ（ｉ−１））％２インデックスデルタ長さ
式９は各ＲＴＰパケットの一番目ＳＬパケットに対するインデックスを求めるための式であり、[数５]は各ＲＴＰパケットの二番目以上のＳＬパケットに対するインデックスデルタを求めるための式である。
式１０において、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。それぞれのＲＴＰパケットに収容されるＳＬパケットに対するインデックス及びインデックスデルタ値は次の通りである。
インデックス=０、インデックスデルタ(２〜５)={０、０、０、０} : 一番目ＲＴＰパケット
インデックス=１、インデックスデルタ(７〜１０)={０、０、０、０} : 二番目ＲＴＰパケット
インデックス=２、インデックスデルタ(１２〜１５)={０、０、０、０} : 三番目ＲＴＰパケット
【００４４】
以上のＣＴＳデルタ、ＤＴＳデルタ、及びインデックス/インデックスデルタは生成されたＳＬパケットヘッダに記録され(Ｓ４６０)、最終的に複数のＳＬパケットを収容するＲＴＰパケットが生成される。
【００４５】
図５は本発明に係るＲＴＰパケット復元装置の一実施例に対する構成を示すブロック図であり、図６は本発明に係るＲＴＰパケット復元方法の流れ図である。図５及び図６を参照すれば、本発明に係るＲＴＰパケット復元装置は、ＲＴＰタイムスタンプ復元部５１０、ＣＴＳ復元部５２０、ＤＴＳ復元部５３０、及びＰＳＮ復元部５４０を有する。
【００４６】
ＲＴＰタイムスタンプ復元部５１０は受信されたＲＴＰパケットヘッダからＲＴＰタイムスタンプを抽出する(Ｓ６００)。従って、図３及び図４を参照して説明したＲＴＰパケット生成装置及び方法によって生成されたＲＴＰパケットを受信した場合に、それぞれのＲＴＰパケットについてＲＴＰタイムスタンプ復元部５１０で抽出されたＲＴＰタイムスタンプはそれぞれ１、６、１１になる。
【００４７】
ＣＴＳ復元部５２０はＲＴＰタイムスタンプ復元部５１０から入力されたＲＴＰタイムスタンプ及び一番目ＳＬパケットのＣＴＳデルタから一番目ＳＬパケットのＣＴＳを復元し、復元された一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳデルタから残りＳＬパケットのＣＴＳを復元する(Ｓ６１０)。一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳは次の式によって復元される。
[式１１]
ＣＴＳ(１)=ＲＴＰタイムスタンプ
ＣＴＳ(ｉ)=ＣＴＳ(１)+ＣＴＳデルタ(ｉ)
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＣＴＳは次の通りである。
ＣＴＳ(１〜５)={１、２、３、４、５} : 一番目ＲＴＰパケット
ＣＴＳ(６〜１０)={６、７、８、９、１０} : 二番目ＲＴＰパケット
ＣＴＳ(１１〜１５)={１１、１２、１３、１４、１５} : 三番目ＲＴＰパケット
【００４８】
ＤＴＳ復元部５３０は次の式によってＣＴＳ及びＤＴＳデルタからＳＬパケットそれぞれのＤＴＳを復元する(Ｓ６２０)。
[式１２]
ＤＴＳ(ｉ)=ＣＴＳ(ｉ)-ＤＴＳデルタ(ｉ)
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＤＴＳは次の通りである。
ＤＴＳ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＤＴＳ(６〜１０)={５、６、７、８、９} : 二番目ＲＴＰパケット
ＤＴＳ(１１〜１５)={１０、１１、１２、１３、１４} : 三番目ＲＴＰパケット
【００４９】
ＰＳＮ復元部５４０は一番目ＳＬパケットのインデックスから一番目ＳＬパケットのＰＳＮを復元し、復元された一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのインデックスデルタから残りＳＬパケットのＰＳＮを復元する(Ｓ６３０)。一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのＰＳＮは次の式によって復元される。
[式１３]
ＰＳＮ(１)=インデックス
ＰＳＮ(ｉ)=ＰＳＮ(ｉ-１)+インデックスデルタ(ｉ)+１
ここで、ｉはそれぞれのＳＬパケットのパケットシーケンス番号である。
それぞれのＲＴＰパケットについて復元されたＰＳＮは次の通りである。
ＰＳＮ(１〜５)={０、１、２、３、４} : 一番目ＲＴＰパケット
ＰＳＮ(６〜１０)={５、６、７、８、９} : 二番目ＲＴＰパケット
ＰＳＮ(１１〜１５)={１０、１１、１２、１３、１４} : 三番目ＲＴＰパケット
【００５０】
一方、復元されたＣＴＳ及びＤＴＳは設定されているタイムスタンプ長さと一致するよう変更されることが望ましい(Ｓ６４０)。この場合、本発明に係るＲＴＰパケット復元装置はタイムスタンプ変更部(図示せず)をさらに備える。タイムスタンプ変更部は次の式によって復元されたＣＴＳ及びＤＴＳを変更する。
[式１４]
ＣＴＳ'(ｉ)=ＣＴＳ(ｉ)％タイムスタンプ長さ
ＤＴＳ'(ｉ)=ＤＴＳ(ｉ)％タイムスタンプ長さ
【００５１】
また、復元されたＰＳＮも設定されているパケットシーケンス番号長さと一致するよう変更されることが望ましい。この場合、本発明に係るＲＴＰパケット復元装置はパケットシーケンス番号変更部(図示せず)をさらに備える。パケットシーケンス変更部は次の式によって復元されたＰＳＮを変更する。
[式１５]
ＰＳＮ'(ｉ)=ＰＳＮ(ｉ)％パケットシーケンス番号長さ、
[式１４]及び[式１５]において、ｉはＳＬパケットのパケットシーケンス番号である。
以上の変更過程を通して変更されたそれぞれのＲＴＰパケットに対するＣＴＳ、ＤＴＳ、及びＰＳＮは次の通りである。
一番目ＲＴＰパケット:
ＣＴＳ'(１〜５)={１、２、３、４、５}
ＤＴＳ'(１〜５)={０、１、２、３、４}
ＰＳＮ'(１〜５)={０、１、２、３、４}
二番目ＲＴＰパケット:
ＣＴＳ'(６〜１０)={６、７、０、１、２}
ＤＴＳ'(６〜１０)={５、６、７、０、１}
ＰＳＮ'(６〜１０)={５、６、７、８、９}
三番目ＲＴＰパケット:
ＣＴＳ'(１１〜１５)={３、４、５、６、７}
ＤＴＳ'(１１〜１５)={２、３、４、５、６}
ＰＳＮ'(１１〜１５)={１０、１１、１２、１３、１４}
【００５２】
図７はＳＬパケットから多重ＳＬ ＲＴＰパケットを生成する過程を示す図であり、図８は受信された多重ＳＬ ＲＴＰパケットからＣＴＳ、ＤＴＳ、ＰＳＮを復元する過程を示す図である。
図７及び図８を参照すれば、ＳＬパケット層はＳＬ設定記述子のタイムスタンプ長さによる長さを有するＣＴＳ、ＤＴＳ及びＳＬ設定記述子のタイムスタンプ長さによる長さを有するＰＳＮがそれぞれＥＣＴＳ、ＥＤＴＳ、及びＥＰＳＮと表現されている。ＳＬパケット層に存在するそれぞれの要素は生成値階層の生成されたＣＴＳ、生成されたＤＴＳ、及び生成されたＰＳＮに対応される。そして、ＳＬパケット階層の要素は生成値階層の要素に基づき多重ＳＬ階層の要素で表現されＲＴＰパケット内に収容される。ＲＴＰパケットにカプセル化された複数のＳＬパケットは受信端で生成時の階層順序とは逆に各階層を進んで最終的にそれぞれのＳＬパケットに分離され、受信端はＳＬパケットに転送されたＭＰＥＧ-４ストリームを復元できるようになる。
【００５３】
以上で代表的な実施例を通して本発明について詳細に説明したが、本発明の属する技術分野において通常の知識を有する者は前述した実施例について本発明の範疇から逸脱しない限度内で多様な変形が可能なことを理解できろう。従って、本発明の権利範囲は説明された実施例に限って定められてはいけなく、特許請求の範囲だけではなく本特許請求の範囲と均等なものによって定められるべきである。
【００５４】
【発明の効果】
以上述べた通り、本明に係るＲＴＰパケット生成装置及び方法によれば、複数のＳＬパケットを一つのＲＴＰパケットに転送する場合、それぞれのＳＬパケットに対するＣＴＳ、ＤＴＳ、及びＰＳＮ情報を以前ＳＬパケットとの差異値だけを記録するので、ＣＴＳ値がロールオーバする場合にもビット数を減らせることができ、タイムスタンプ長さが３２以上であるＳＬパケットも多重ＳＬパケット化できるようになる。また、ＤＴＳデルタの値は常に正数になるべきであるところ、本発明に係るＲＴＰパケット生成装置及び方法によれば、ＤＴＳデルタ値が常に正数になり、大きい値のＤＴＳデルタが発生することを防止することができる。しかも、ＰＳＮについてロールオーバが発生する場合も割当てられたインデックスデルタ値に適した値を生成することができる。また、送信端でロールオーバ発生有無に対する検査を行なう必要がなく、受信端においてはロールオーバ回数だけ検査すればそれぞれの情報をそのまま使用できるため、送信端におけるエンコーディング及び受信端におけるデコーディング過程が簡単になる。
【図面の簡単な説明】
【図１】 複数のＳＬパケットが収容されたＲＴＰパケットを示す図、
【図２】 マッピングされたＳＬヘッダの構造を示す図、
【図３】 本発明に係るＲＴＰパケット生成装置の一実施例に対する構成を示すブロック図、
【図４】 本発明に係るＲＴＰパケット生成方法の一実施例の流れ図、
【図５】 本発明に係るＲＴＰパケット復元装置の一実施例に対する構成を示すブロック図、
【図６】 本発明に係るＲＴＰパケット復元方法の流れ図、
【図７】 ＳＬパケットから多重ＳＬ ＲＴＰパケットを生成する過程を示す図、
【図８】 受信された多重ＳＬ ＲＴＰパケットからＣＴＳ、ＤＴＳ、ＰＳＮを復元する過程を示す図である。
【符号の説明】
３００:設定部
３０５:ＣＴＳ生成部
３１０:ＤＴＳ生成部
３１５:ＰＳＮ生成部
３２０:インデックス長さ、インデックスデルタ長さ抽出部
３３０:パケット生成部
３４０:ＲＴＰパケットヘッダ生成部
３５５:ＣＴＳデルタ生成部
３６０:ＤＴＳデルタ生成部
３６５:インデックス/インデックスデルタ生成部
Claims (9)
- 複数の同期層(Synchronization Layer :ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(Composition Time Stamp : ＣＴＳ)、デコーディングタイムスタンプ(Decoding Time Stamp : ＤＴＳ)、パケットシーケンス番号(Packet Sequence Number : ＰＳＮ)を付与し、前記ＳＬパケット内のＳＬ設定記述子(SL Config Discriptor :ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する設定部と、
前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成するパケット生成部と、を備え、
前記パケット生成部は、
前記ＣＴＳに基づき算出されたＲＴＰタイムスタンプを含むＲＴＰパケットヘッダを生成するＲＴＰパケットヘッダ生成部と、
前記ＣＴＳ及び前記ＲＴＰタイムスタンプに基づきＣＴＳデルタを生成するＣＴＳデルタ生成部と、
前記ＣＴＳ及び前記ＤＴＳに基づきＤＴＳデルタを生成するＤＴＳデルタ生成部と、
前記ＰＳＮ、前記インデックス長さ、及び前記インデックスデルタ長さを入力されインデックス / インデックスデルタを生成するインデックス / インデックスデルタ生成部と、を備えることを特徴とする請求項１に記載のＲＴＰパケット生成装置。 - 前記設定部は、
前記ＳＬパケットそれぞれについてパケット生成順序に基づき１から順次に増加する前記ＣＴＳを付与するＣＴＳ生成部と、
前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＤＴＳを付与するＤＴＳ生成部と、
前記ＳＬパケットそれぞれについてパケット生成順序に基づき０から順次に増加する前記ＰＳＮを付与するＰＳＮ生成部と、
前記ＳＬパケット内のＳＬ設定記述子から前記タイムスタンプ長さ及び前記パケットシーケンス番号長さを抽出する抽出部と、を備えることを特徴とする請求項１に記載のＲＴＰパケット生成装置。 - 複数の同期層(ＳＬ)パケットそれぞれについてパケット生成順序に基づき順次に増加するコンポジションタイムスタンプ(ＣＴＳ)、デコーディングタイムスタンプ(ＤＴＳ)、パケットシーケンス番号(ＰＳＮ)を付与する段階と、
前記ＳＬパケット内のＳＬ設定記述子(ＬＳＣＤ)からタイムスタンプ長さ及びパケットシーケンス番号長さを抽出する段階と、
前記ＣＴＳ、前記ＤＴＳ、前記ＰＳＮ、前記タイムスタンプ長さ、及び前記パケットシーケンス番号長さに基づきＲＴＰパケットのヘッダ及び一つの前記ＲＴＰパケットに収容される前記ＳＬパケットのヘッダを生成する段階と、を備え、
前記付与段階は、
前記ＲＴＰパケットに最初に収容される前記ＳＬパケットの前記ＣＴＳに基づき前記ＲＴＰパケットのヘッダに記録されるＲＴＰタイムスタンプを決定する第１決定段階と、
決定された前記ＲＴＰタイムスタンプ、前記ＣＴＳ、前記ＤＣＴ、前記ＰＳＮ、及びインデックスデルタ長さに基づき前記ＳＬパケットのヘッダに記録されるＣＴＳデルタ、ＤＴＳデルタ、及びインデックス / インデックスデルタを決定する第２決定段階と、を備えることを特徴とするＲＴＰパケット生成方法。 - 前記第１決定段階は次の式により前記ＲＴＰタイムスタンプを決定することを特徴とする請求項３に記載のＲＴＰパケット生成方法。
ＲＴＰタイムスタンプ＝（最初ＳＬパケットのＣＴＳ）％（ＲＴＰタイムスタンプの長さ） - 前記第２決定段階は次の式によって前記ＣＴＳデルタ、前記ＤＴＳデルタ、前記インデックス、及び前記インデックスデルタを決定することを特徴とする請求項４に記載のＲＴＰパケット生成方法。
ＣＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＲＴＰタイムスタンプ、
ＤＴＳデルタ（ｉ）＝ＣＴＳ（ｉ）−ＤＴＳ（ｉ）、
インデックス（０）＝ＰＳＮ（０）％２インデックス長さ
インデックスデルタ（ｉ）＝（ＰＳＮ（ｉ）-ＰＳＮ（ｉ−１）％２インデックスデルタ長さ
但し、ｉは前記ＳＬパケットのパケットシーケンス番号である。 - ＲＴＰタイムスタンプを復元する第１復元部と、
前記ＲＴＰタイムスタンプ及び一番目ＳＬパケットのＣＴＳデルタから一番目ＳＬパケットのＣＴＳを復元し、復元された一番目ＳＬパケットのＣＴＳ及び残りＳＬパケットのＣＴＳデルタから残りＳＬパケットのＣＴＳを復元する第２復元部と、
ＣＴＳ及びＤＴＳデルタから前記ＳＬパケットそれぞれのＤＴＳを復元する第３復元部と、
一番目ＳＬパケットのインデックスから一番目ＳＬパケットのＰＳＮを復元し、復元された一番目ＳＬパケットのＰＳＮ及び残りＳＬパケットのインデックスデルタから残りＳＬパケットのＰＳＮを復元する第４復元部と、
前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更部と、
前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する第２変更部とを備えることを特徴とするＲＴＰパケット復元装置。 - 受信されたＲＴＰパケットからＲＴＰタイムスタンプを抽出し、前記ＲＴＰパケットのペイロード内のそれぞれのＳＬパケットに対するＣＴＳを復元する段階と、
前記ＣＴＳ及びそれぞれの前記ＳＬパケットから抽出されたＤＴＳデルタからＤＴＳを復元する段階と、
前記ＳＬパケットから抽出されたインデックス及びインデックスデルタに基づきＰＳＮを復元する段階と、を備え、
前記ＣＴＳ及び前記ＤＴＳを設定されているタイムスタンプ長さに基づき変更する第１変更段階と、
前記ＰＳＮを設定されているパケットシーケンス番号長さに基づき変更する段階をさらに備えることを特徴とするＲＴＰパケット復元方法。 - 前記ＣＴＳ復元段階は、式１によって前記ＣＴＳを復元し、
前記ＤＴＳ復元段階は式２によって前記ＤＴＳを復元し、
前記ＰＳＮ復元段階は式３によって前記ＰＳＮを復元することを特徴とする請求項７に記載のＲＴＰパケット復元方法。
[式１]
ＣＴＳ(１)=ＲＴＰタイムスタンプ、
ＣＴＳ(ｉ)=ＣＴＳ(１)+ＣＴＳデルタ(ｉ)、
[式２]
ＤＴＳ(ｉ)=ＣＴＳ(ｉ)-ＤＴＳデルタ(ｉ)、
[式３]
ＰＳＮ(１)=インデックス、
ＰＳＮ(ｉ)=ＰＳＮ(ｉ-１)＋インデックスデルタ(ｉ)＋１、
但し、ｉは前記ＳＬパケットのパケットシーケンス番号である。 - 前記第１変更段階は、式４によって前記ＣＴＳ及び前記ＤＴＳを変更し、前記第２変更段階は式５によって前記ＰＳＮを変更することを特徴とする請求項７に記載のＲＴＰパケット復元方法。
[式４]
ＣＴＳ'(ｉ)=ＣＴＳ(ｉ)％タイムスタンプ長さ、
ＤＴＳ'(ｉ)=ＤＴＳ(ｉ)％タイムスタンプ長さ、
[式５]
ＰＳＮ'(ｉ)=ＰＳＮ(ｉ)％パケットシーケンス番号長さ、
但し、ｉは前記ＳＬパケットのパケットシーケンス番号である。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR2002-017833 | 2002-04-01 | ||
| KR10-2002-0017833A KR100441589B1 (ko) | 2002-04-01 | 2002-04-01 | Ｒｔｐ패킷 생성/복원 장치 및 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003304288A JP2003304288A (ja) | 2003-10-24 |
| JP3802003B2 true JP3802003B2 (ja) | 2006-07-26 |
Family
ID=28036193
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003098388A Expired - Fee Related JP3802003B2 (ja) | 2002-04-01 | 2003-04-01 | Ｒｔｐパケット生成／復元装置及び方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7366204B2 (ja) |
| EP (1) | EP1351472B1 (ja) |
| JP (1) | JP3802003B2 (ja) |
| KR (1) | KR100441589B1 (ja) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7136577B1 (en) * | 2000-06-29 | 2006-11-14 | Tandberg Telecom As | RTP-formated media clips |
| US6649567B2 (en) * | 2001-10-11 | 2003-11-18 | Isp Investments Inc. | Controlled release microbiocide for porous surfaces |
| US7451235B2 (en) * | 2000-10-11 | 2008-11-11 | Broadcom Corporation | Dynamic delta encoding for cable modem header suppression |
| CN100397847C (zh) * | 2003-04-14 | 2008-06-25 | 华为技术有限公司 | 一种实时传输协议时间戳的生成方法 |
| KR101029808B1 (ko) * | 2004-01-27 | 2011-04-20 | 엘지전자 주식회사 | 싱크 레이어 패킷의 패킷화 방법 |
| KR100619034B1 (ko) * | 2004-06-19 | 2006-08-31 | 삼성전자주식회사 | 디지털 멀티미디어 데이터 수신기에서 송수신 데이터 동기방법 및 장치 |
| EP1613016A1 (en) * | 2004-07-01 | 2006-01-04 | Thomson Licensing | Method for transmitting packets in a transmission system |
| US7792158B1 (en) * | 2004-08-18 | 2010-09-07 | Atheros Communications, Inc. | Media streaming synchronization |
| US8149880B1 (en) | 2004-08-18 | 2012-04-03 | Qualcomm Atheros, Inc. | Media streaming synchronization |
| CN100377537C (zh) * | 2005-08-09 | 2008-03-26 | 华为技术有限公司 | 报文生成方法 |
| US9198084B2 (en) * | 2006-05-26 | 2015-11-24 | Qualcomm Incorporated | Wireless architecture for a traditional wire-based protocol |
| US20080045149A1 (en) * | 2006-05-26 | 2008-02-21 | Dinesh Dharmaraju | Wireless architecture for a traditional wire-based protocol |
| EP1936908A1 (en) * | 2006-12-19 | 2008-06-25 | Deutsche Thomson OHG | Method, apparatus and data container for transferring high resolution audio/video data in a high speed IP network |
| US8667144B2 (en) * | 2007-07-25 | 2014-03-04 | Qualcomm Incorporated | Wireless architecture for traditional wire based protocol |
| US9112632B2 (en) | 2008-01-25 | 2015-08-18 | Cisco Technology, Inc. | Supporting efficient and accurate sync/followup timestamps |
| US8139923B2 (en) * | 2008-03-19 | 2012-03-20 | Seiko Epson Corporation | Playback of recorded streaming delta-encoded data |
| US8811294B2 (en) * | 2008-04-04 | 2014-08-19 | Qualcomm Incorporated | Apparatus and methods for establishing client-host associations within a wireless network |
| EP2124449A1 (en) | 2008-05-19 | 2009-11-25 | THOMSON Licensing | Device and method for synchronizing an interactive mark to streaming content |
| US9398089B2 (en) * | 2008-12-11 | 2016-07-19 | Qualcomm Incorporated | Dynamic resource sharing among multiple wireless devices |
| CN105898857B (zh) * | 2009-06-23 | 2021-05-07 | 北京三星通信技术研究有限公司 | 一种数据同步方法和*** |
| US9264248B2 (en) * | 2009-07-02 | 2016-02-16 | Qualcomm Incorporated | System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment |
| JP5564853B2 (ja) * | 2009-08-14 | 2014-08-06 | ソニー株式会社 | 受信装置および方法、プログラム、並びに受信システム |
| US9582238B2 (en) * | 2009-12-14 | 2017-02-28 | Qualcomm Incorporated | Decomposed multi-stream (DMS) techniques for video display systems |
| CN102143527B (zh) * | 2010-02-03 | 2013-09-11 | 华为技术有限公司 | 嵌套协议包头的压缩方法及装置 |
| EP2362654A1 (en) * | 2010-02-26 | 2011-08-31 | Panasonic Corporation | Short baseband frame headers |
| US10135900B2 (en) | 2011-01-21 | 2018-11-20 | Qualcomm Incorporated | User input back channel for wireless displays |
| US8964783B2 (en) | 2011-01-21 | 2015-02-24 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9413803B2 (en) | 2011-01-21 | 2016-08-09 | Qualcomm Incorporated | User input back channel for wireless displays |
| US20130013318A1 (en) * | 2011-01-21 | 2013-01-10 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9065876B2 (en) | 2011-01-21 | 2015-06-23 | Qualcomm Incorporated | User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays |
| US9787725B2 (en) | 2011-01-21 | 2017-10-10 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9503771B2 (en) | 2011-02-04 | 2016-11-22 | Qualcomm Incorporated | Low latency wireless display for graphics |
| US8674957B2 (en) | 2011-02-04 | 2014-03-18 | Qualcomm Incorporated | User input device for wireless back channel |
| US10108386B2 (en) | 2011-02-04 | 2018-10-23 | Qualcomm Incorporated | Content provisioning for wireless back channel |
| US9525998B2 (en) | 2012-01-06 | 2016-12-20 | Qualcomm Incorporated | Wireless display with multiscreen service |
| JP6126583B2 (ja) | 2012-03-28 | 2017-05-10 | 日本放送協会 | 符号化装置、復号装置及びこれらのプログラム |
| US9413787B2 (en) * | 2012-08-06 | 2016-08-09 | Blackberry Limited | Real-time delivery of location/orientation data |
| CN106603518B (zh) * | 2016-12-05 | 2019-08-20 | 深圳市泛海三江科技发展有限公司 | 一种实时传输协议***的时间戳生成方法及装置 |
| US10129014B2 (en) * | 2017-01-25 | 2018-11-13 | Samsung Electronics Co., Ltd. | System and method of performing initial timing synchronization of receivers of modulated signals |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60031063T2 (de) * | 1999-04-20 | 2007-05-03 | Koninklijke Philips Electronics N.V. | Vorverarbeitungsverfahren zum anpassen von mpeg-4 datenströmen an das internetnetzwerk |
| KR20020031457A (ko) * | 2000-10-20 | 2002-05-02 | 오길록 | 멀티미디어 데이터의 내용표현방식 및 미디어와의 연동을고려한 전송방법 |
| US7136395B2 (en) * | 2000-11-30 | 2006-11-14 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for transmission of headerless data packets over a wireless link |
| KR100428736B1 (ko) * | 2001-04-26 | 2004-04-27 | 주식회사 현대시스콤 | 이동통신망 및 그의 운용방법 |
| KR20030042487A (ko) * | 2001-11-22 | 2003-06-02 | 에스케이 텔레콤주식회사 | 주문형 비디오 서비스 프로토콜 스택의 구조 |
-
2002
- 2002-04-01 KR KR10-2002-0017833A patent/KR100441589B1/ko not_active IP Right Cessation
-
2003
- 2003-03-27 EP EP20030251930 patent/EP1351472B1/en not_active Expired - Fee Related
- 2003-03-31 US US10/401,752 patent/US7366204B2/en not_active Expired - Fee Related
- 2003-04-01 JP JP2003098388A patent/JP3802003B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1351472A2 (en) | 2003-10-08 |
| EP1351472A3 (en) | 2007-11-21 |
| US7366204B2 (en) | 2008-04-29 |
| EP1351472B1 (en) | 2012-05-09 |
| US20030185245A1 (en) | 2003-10-02 |
| KR20030079069A (ko) | 2003-10-10 |
| KR100441589B1 (ko) | 2004-07-23 |
| JP2003304288A (ja) | 2003-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3802003B2 (ja) | Ｒｔｐパケット生成／復元装置及び方法 | |
| CN101517553B (zh) | 用于对内容进行包化以经由网络传输的方法和设备 | |
| US6233251B1 (en) | Multiplex transmission method and system, and audio jitter absorbing method used therein | |
| US7372858B2 (en) | Data transmission device and data transmission method | |
| US6959020B1 (en) | Error detection in receiving multiplex signals | |
| JP2004096738A (ja) | ヘッダ圧縮／復元装置及びヘッダ圧縮／復元方法 | |
| CN105847873B (zh) | 面向监控应用的高清视频码流与数据复用***及方法 | |
| KR101151390B1 (ko) | 송신 시스템에서 패킷을 송신하기 위한 방법 | |
| KR101200070B1 (ko) | 네트워크 시간표시정보를 삽입하거나 추출하기 위한 장치 및 방법 | |
| JP3342704B2 (ja) | マルチメディア多重化方法 | |
| JP2005218090A (ja) | 放送／通信融合システム及び放送／通信融合システムにおけるイーサネット（登録商標、以下同じ）データの送受信方法 | |
| EP1936908A1 (en) | Method, apparatus and data container for transferring high resolution audio/video data in a high speed IP network | |
| WO2011131043A1 (zh) | Sdh/sonet段开销字节的传递方法、装置及*** | |
| Vainshtein et al. | Structure-agnostic time division multiplexing (TDM) over packet (SAToP) | |
| WO2010049312A1 (en) | Data container for transferring high resolution audio/video data in a high speed ip network | |
| WO2008151989A2 (en) | System and method for transport of a constant bit rate stream | |
| US20030193940A1 (en) | Apparatus and method of packetizing data stream | |
| JP2001148853A (ja) | 動画像符号化装置および復号化装置 | |
| JP4192766B2 (ja) | 受信装置および方法、記録媒体、並びにプログラム | |
| JP2008245061A (ja) | Ｉｐストリーム伝送におけるｐｃｒ再生方式 | |
| Begen | RTP payload format for 1-D interleaved parity forward error correction (FEC) | |
| EP2188973B1 (en) | Method, server and client apparatuses for transferring high resolution multimedia data in a high speed network | |
| KR20060089508A (ko) | 타이밍정보의 효율적 전송을 위한 전송스트림 생성 장치및 그 방법과, 그를 이용한 디엠비 전송 시스템 | |
| US7949052B1 (en) | Method and apparatus to deliver a DVB-ASI compressed video transport stream | |
| JP4190428B2 (ja) | データ伝送方法およびデータ伝送機 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051213 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060313 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060418 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060426 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100512 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110512 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120512 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130512 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |