JP4109735B2 - パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 - Google Patents
パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 Download PDFInfo
- Publication number
- JP4109735B2 JP4109735B2 JP24067897A JP24067897A JP4109735B2 JP 4109735 B2 JP4109735 B2 JP 4109735B2 JP 24067897 A JP24067897 A JP 24067897A JP 24067897 A JP24067897 A JP 24067897A JP 4109735 B2 JP4109735 B2 JP 4109735B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- header
- network
- data
- protocol
- 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 - Lifetime
Links
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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
-
- 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
Description
【０００１】
【発明の属する技術分野】
本発明は、インタネットプロトコルを使ってＭＰＥＧ画像を伝送する方式およびそのシステムに関わり、特にＭＰＥＧ伝送プロトコルとインタネットプロトコルの変換処理を迅速に行う伝送方式変換装置を用いたネットワーク接続方式、および伝送するＭＰＥＧデータのカプセル化方式に関する。
【０００２】
【従来の技術】
映像をデジタル符号化して伝送するシステムの国際標準規格として、"GENERIC CODING OF MOVING PICTURES AND ASSOCIATED AUDIO: SYSTEMS"がＩＳＯ／ＩＥＣ１３８１８−１、ＩＴＵ−Ｔ(International Telecommunication Union) Ｈ．２２２．０勧告として規定されている。このＭＰＥＧシステム国際標準規格（以後、Ｈ．２２２．０と略記する）では、ＭＰＥＧ方式によって圧縮した画像信号を伝送する規格を定めている。Ｈ．２２２．０では、比較的ビットエラー発生の少ない蓄積媒体等からの伝送を想定したプログラムストリーム（以後、ＰＳと略記する）形式と、伝送ビットエラーの発生が予想される通信回線を想定したトランスポートストリーム（以後、ＴＳと略記する）形式の２種類のフォーマットを規定している。
【０００３】
本発明はＴＳ形式で圧縮映像信号を伝送する際の符号変換方式を対象とするため、ここで簡単にＴＳ形式による画像伝送方式について従来技術の説明を行う。映像・音響符号化と伝送を対象としたＭＰＥＧ方式では、入力されるテレビジョン等の映像信号をデジタル化し、このデジタル信号を離散コサイン変換、可変長符号化等の手法を用いてデータ圧縮を行う。また、音響信号に関しては、手法は異なるもののデジタル化した後、冗長なデータを取り除くことで圧縮を行っている。これらの圧縮された信号はエレメンタリーストリーム（以後、ＥＳと略記する）と呼ばれるもので、その言葉の通り画像・音響信号の要素となるデータである。なお、ＭＰＥＧにおいてはこの画像・音響データを（ビット）ストリームという言葉を用いて表している。
【０００４】
ＭＰＥＧ映像信号を伝送するケーブルテレビ、衛星通信回線、または非同期転送モード伝送路（以後、ＡＴＭ回線と略記する）等では、データ伝送の際に比較的ビット誤りが多く発生することが想定されるので、伝送エラーによる障害波及の範囲を狭くするためＥＳを小さなパケットに区切って伝送する。パケット化されたＥＳはパケッタイズドエレメンタリストリーム（以後、ＰＥＳと略記する）と呼ばれるものであり、ＥＳにＰＥＳヘッダと呼ばれるヘッダ情報が付加した形式となっている。上記に例示した通信回線の伝送では、このＰＥＳをさらに小さなトランスポートパケットと呼ばれる１８８バイトのパケットに区切って伝送する。ＴＳパケットは、図１３に示すように４バイトのヘッダと、データを格納するための１８４バイトのペイロードから構成されるパケットである。図１４はＴＳパケットのヘッダ構造を示す図である。TSヘッダは、1バイトの同期バイト（０ｘ４７）と、ＴＳパケットの属性を表すフラグ（本説明では重要でないので個々のフラグの内容については説明を省略する）、１３ビットのパケット識別子（以後PIDと略記する）、スクランブル制御識別子、アダプテーションフィールド識別子とパケットの連続性を検査するのに用いる４ビットの巡回カウンタから構成される。またトランスポートストリームでは、アダプテーションフィールドと呼ばれるフィールドを映像データを格納するペイロードと呼ばれるデータフィールドに先立って伝送することができ、このフィールドにはシステムのクロック同期を目的としたプログラムクロックリファレンス（以後、PCRと略記する）やプライベートデータを格納することが可能である。なおＴＳパケットでアダプテーションフィールドを伝送する際は、ＴＳヘッダのアダプテーションフィールド識別子にてその存在を指示することが規定されている。
【０００５】
ＭＰＥＧ方式はＣＡＴＶやデジタル衛星放送に対応して開発された方式であるが、最近ではコンピュータのデータ通信を主目的に発展を遂げてきたインターネットと呼ばれるネットワークにおいてもＭＰＥＧ画像を利用するサービスが提供されるようになってきた。インタネットにおける通信の相互接続性を確保するため、Internet Engineering Task Force(以後、ＩＥＴＦと略記する)が規格化を進めており、ＭＰＥＧ画像伝送フォーマットの規格はRequest for Comment N0。2038:“RTP Payload Format for MPEG1/MPEG2 Video”（以後、ＲＦＣ２０３８と略記する）により伝送方法やパケットのカプセル化方式が規格化されている。ＲＦＣ２０３８では、伝送するパケットのフォーマットとしてＭＰＥＧのＥＳ、ＴＳ、もしくはＰＳを利用して伝送すること、配送遅延により画質劣化が生じることを回避するためＲＦＣ１８８９により仕様化された“RTP: A Transport Protocol for Real-Time Applications”（以後、ＲＴＰと略記する）により伝送することを定めている。なお、ＲＴＰパケットはユーザデータグラムプロトコル（以後、ＵＤＰと略記する）によるパケットに格納し、さらにこのＵＤＰパケットをインタネットプロトコルパケット（以後、ＩＰパケットと略記する）により伝送することを規定している。以上説明した従来技術によれば、ＣＡＴＶ回線内部ではＭＰＥＧ−ＴＳパケットにより、またインタネット内部ではＩＰパケットによりＭＰＥＧ映像を伝送することが可能である。
【０００６】
【発明が解決しようとする課題】
ＭＰＥＧ−ＴＳ方式により映像伝送を行うのは前述の通りデジタル衛星放送やデジタルＣＡＴＶシステムである。これらのサービスのうち、デジタルＣＡＴＶシステムは地域密着型のサービスであり比較的狭い地域をサービス提供地域として構成されるのが一般的である。そのため各々のＣＡＴＶ事業者が番組を送出するためのＣＡＴＶセンター（以後、ヘッドエンドと略記する）と映像を伝送するためのアクセスネットワークを保有し、ヘッドエンドにおいて受信した地上／衛星放送番組を再送信したり、ヘッドエンドに貯えた番組を必要に応じて送信している。このような従来のＣＡＴＶサービスでは、放送されてきた番組以外の番組は、例えばVTR等に蓄積しておき番組編成に応じて再生する必要があった。近未来のＣＡＴＶサービスとして期待されているビデオオンデマンド等も上記と同様にヘッドエンドに番組のデジタル圧縮信号を保有する形式で構築するのが一般的である。ところでビデオオンデマンドサービスでは、その番組コンテンツを保有するために再放送権（著作権）の購入、番組のデジタル圧縮処理、圧縮映像の蓄積などサービスを維持するためのコストも高く、できるだけ同一番組（コンテンツ）に対するアクセス回数を多くしなければ採算が取れないといった課題がある。この課題を解決するには、例えば、複数のＣＡＴＶ事業者が共同でコンテンツを保有し、通信回線を使ってこのコンテンツを必要な時に伝送して利用する等の方法が効果的である。
【０００７】
このようなシステムを構築するには複数のCATV事業者のヘッドエンド、ネットワークを通信回線を使って接続する必要がある。例えば、米国のＣＡＴＶヘッドエンドと日本のＣＡＴＶ加入者の映像受信機であるセットトップ端末（以後、ＳＴＢと略記する）を接続するためには、少なくとも米国と日本の間の通信回線を利用して接続しなければならない。ところが、現状ではデジタルＣＡＴＶで一般的に利用されているＭＰＥＧ−ＴＳをそのままの形式で伝送することは現実的ではない。すなわちＭＰＥＧ−ＴＳの映像伝送では、ＡＴＭ回線や衛星回線等の専用通信回線を利用しなければならず、かつこの専用線は通信料金が高いといった問題がある。また専用線であるため、契約地点を常時接続して利用することが前提となっており、オンデマンドサービスのようにユーザの要求に応じてネットワークを占有するようなサービスに用いるにはコストパフォーマンスの点で大きな問題がある。
【０００８】
【課題を解決するための手段】
上記の課題を解決するため、本発明では複数のＣＡＴＶネットワークをインタネットにより接続する手段を用いる。インタネットは全世界に張り巡らされたネットワークであり、個々の端末やホストコンピュータに付与されたアドレスにより動的に接続変更が可能であるといった特徴をもつ。そのため予め接続地点を固定しておく必要もなく、映像を配信したい際にアドレスを使って接続するため、専用線では実現できない自由な接続設定、および低コストな映像通信が可能である。なお現状のインタネットでは伝送帯域幅等が狭いといった問題もあるが、ギガビットルータや帯域予約プロトコル（Resource reservation setup Protocol：ＲＳＶＰ）等により伝送帯域を確保することにより、帯域不足は近い将来問題とはならなくなり、グローバルなネットワーク環境がインタネットにより実現されることは容易に予想できる。
【０００９】
さらに上記のようにインターネットを用いてＣＡＴＶネットワークを接続する際に新たに発生する課題：“ＣＡＴＶネットワークで用いているＭＰＥＧ伝送プロトコルとインターネットで用いるＩＰプロトコルの間のプロトコル変換が必要である”に対して本発明では、ＭＰＥＧ−ＴＳプロトコルとインターネットプロトコルを変換するインタワークユニットを設けることで解決する。このインタワークユニットにおいて処理の高速化と低価格化を実現しなければならないといった課題に対しては、ＭＰＥＧネットワーク、ＩＰネットワーク内部で伝送するパケットの構成方法、変換方法を改良する手段を提供することによって解決する。
【００１０】
具体的には、１） ＭＰＥＧ−ＴＳ方式で規定されたアダプテーションフィールドのプライベートデータ領域にＩＰパケットのヘッダを格納して伝送し、インタワークユニットではこのアダプテーション領域のプライベートデータを解析することなくそのままＩＰパケットのヘッダとしてインタネット内部を伝送するパケットを構成する手段、２）インタネットからＭＰＥＧ映像信号を伝送する際には、送信するＩＰパケットの大きさをＭＰＥＧ−ＴＳに分割する時にあまることなくペイロードに収容可能なサイズの制約条件を設けて伝送するといった手段とを採用する。
【００１１】
【発明の実施の形態】
以下、本発明による実施例を図面を参照しながら詳細に説明する。
【００１２】
――第1実施形態――
図９は、本発明によるＣＡＴＶシステムの接続形態を示す実施例である。このＣＡＴＶシステムは、２個所のＣＡＴＶネットワーク６１、５６をインタネット５０で接続する点に特徴がある。図示するように本ＣＡＴＶシステムは、ビデオサーバ６０とそれに接続されたＣＡＴＶ ネットワーク６１、インタネット５０、インタネット５０とＣＡＴＶネットワーク６１を接続するためのインタワークユニット６２、さらに第２のＣＡＴＶネットワーク５６と、そのネットワーク５６とインタネット５０を接続するインタワークユニット５４から構成する。ＣＡＴＶネットワーク５６には、映像を受信するためのＳＴＢ５７が接続されている。 ビデオサーバ６０からの映像信号はインタワークユニット６２を介してインタネット５０に伝送され、ルータ網によりインタワークユニット５４に配送される。インタワークユニット５４はインタネットを使って伝送された映像信号をＣＡＴＶネットワーク５６に供給し、これによりＳＴＢ５７において映像受信を可能とする。
【００１３】
ここでインタワーキングユニットの機能を簡単に説明する。ＣＡＴＶネットワークにおいては、従来技術の項で説明した通りＭＰＥＧ−ＴＳ方式により映像信号を伝送している。これに対してインタネットではＲＦＣ２０３８に代表されるインタネットプロトコルによる画像伝送を行っている。異なるプロトコルを使用するネットワークを相互接続するインタワークユニット６２は、ＭＰＥＧ−ＴＳプロトコルからインタネットプロトコルに準拠した信号形式に変換する機能がある。一方、インタワークユニット５４は、インタネットプロトコルにより伝送された画像信号をＭＰＥＧ−ＴＳプロトコルに変換する機能を有する。このようなインタワークユニット６２、５４を用いて異なるＣＡＴＶネットワークをインタネットを介して接続することで、距離的に遠く離れたＣＡＴＶのビデオサーバとＳＴＢを容易に接続できるといったこれまでにない機能が実現できる。インタネットは全世界に発達したネットワークであり、この構成によれば全世界のビデオサーバとＳＴＢの接続性を確保できるといった絶大な効果が得られる。
【００１４】
なお、図９の実施例では映像信号を発生する装置としてビデオサーバを例にとり説明したが、本発明の趣旨はＭＰＥＧプロトコルで供給される映像信号をインタネットを介して配送することにあり、その信号供給源はビデオサーバのみに限定されるものではない。ビデオサーバ以外にＭＰＥＧ信号を供給する装置としてはリアルタイムのＭＰＥＧエンコーダや、衛星放送を受信してＭＰＥＧ信号を出力するような受信設備があり、これらの装置であっても本発明の趣旨が満足されることは言うまでもない。
【００１５】
さらに、本実施例では簡単のために２個所の異なるＣＡＴＶネットワークを相互接続する例を説明したが、インタネットに接続されるＣＡＴＶシステムは２個所以上であっても構わないことは言うに及ばない。本発明の趣旨は、インターワークユニットを用いてＭＰＥＧ―ＴＳ方式で伝送された信号をインタネットにより伝送可能な形式に変換しこの変換された映像信号をインタネットにより伝送すること、及びインタネットを使って伝送された信号をインタワークユニットにより再びＭＰＥＧ−ＴＳ信号に変換してＣＡＴＶネットワークに伝送する点にある。
【００１６】
――第２実施形態――
第２実施例では、第１実施例により説明したインタネット経由のＣＡＴＶ接続に加え、インタネット上のサーバからＣＡＴＶ上のＳＴＢへの映像送信、ＣＡＴＶ上の映像サーバからインタネット上のクライアントＰＣに対する映像送信をも考慮にいれた共用的な映像伝送プロトコルと、異なるネットワーク間のプロトコルを変換する方式を開示する。
【００１７】
図８はＣＡＴＶ上のビデオサーバ５５からインタネットのクライアント４への映像伝送と、インタネット上のサーバ５２からＣＡＴＶネットワーク上のＳＴＢ５７の映像伝送をともに可能とするネットワーク構成の接続図である。
【００１８】
まず、ＣＡＴＶネットワーク５６に接続されたビデオサーバ５５からインタネット上のクライアント４に映像を伝送する場合を説明する。なお、インタネット上のサーバからＣＡＴＶネットワーク上のＳＴＵに映像伝送する際のパケット化とプロトコル変換については第４実施例にて詳細に説明する。
【００１９】
ビデオサーバ５５からクライアント４に映像伝送する場合は、ビデオサーバ５５は図１に示すパケット構成により映像送信を行う。この映像信号は、ＣＡＴＶネットワーク５６によりＭＰＥＧ−ＴＳ方式によりインタワークユニット６２に達する。インタワークユニット６２は後述する変換方式によってＭＰＥＧ−ＴＳにより運ばれた映像信号をインタネットプロトコルにより伝送可能なパケットにプロトコル変換しインタネット５１に送信する。インタネット５１ではＩＰプロトコルを利用してクライアント４に映像信号を配送する。なお、この信号はクライアント４に送信するのと同様な方法によりインタワークユニット５４に送信することもできる。ＣＡＴＶネットワークの相互接続ではこのインタワークユニット５４にてＭＰＥＧ−ＴＳに再度プロトコルの変換を行う。
【００２０】
ここで図１に示したパケットのカプセル化の方法を詳細に説明する。図１は、図８のビデオサーバ５５からインタネット５０、およびＣＡＴＶ網５６に接続されたＳＴＢ５７、さらにはインタワークユニット５４を介して接続される別ＣＡＴＶネットワーク上のＳＴＢに送信するＭＰＥＧ−ＴＳ信号の構成を示した実施例である。ＭＰＥＧ−ＴＳでは、４バイトのＴＳヘッダー１に引き続き、データを格納するペイロードを伝送する場合と、アダプテーションフィールド２をペイロードに先立って伝送することが許容されている。本発明ではＩＰネットワークに信号を伝送する場合には、図１に示すように、ＩＰヘッダを送信するＴＳではＴＳヘッダの直後に必ずアダプテーションフィールド２を挿入し、このアダプテーションフィールド２を使ってＩＰヘッダを伝送する。アダプテーションフィールド２は、伝送するデータの内容を示す２バイトのフラグ４と、プライベートデータ５を格納する。なお、プライベートデータ５を伝送するため、アダプテーションフィールドの内容を指示するフラグ（transport_private_data_flag）によりプライベートデータ５を伝送することを指示し、かつそのプライベートデータ５のサイズをフラグ内にプライベートデータ長（transport_private_data_length）として設定する。このプライベートデータ５として２０バイトのＩＰパケットヘッダ６をそのままのビット配列で格納する。図７は、このプライベートデータ５に格納するＩＰパケットの内容を示した図である。ＩＰパケットヘッダは、バージョンを示す４ビットのフィールド、ヘッダ長、サービスタイプ、全パケット長、識別子や送信元ＩＰアドレス、宛先ＩＰアドレスから構成され、オプションがない場合では２０バイトから構成される。一般的な条件でオプションは使用しないので２０バイトのフィールドを含むデータをそのままプライベートデータ領域に格納して伝送する。
【００２１】
なお、アダプテーションフィールドに引き続いてＴＳのペイロードにはＰＥＳの形式でデータを格納する。ＰＥＳ形式で映像信号を伝送する理由については後に説明する。
【００２２】
図１の実施例では、プライベートデータとしてＩＰパケットヘッダのみを含めて伝送する例を示したが、ＩＰネットワークに接続される端末（クライアント）がサポートするプロトコルに応じて、UDPヘッダ、もしくはＵＤＰヘッダとＲＴＰヘッダの双方を包含する形式としても構わない。図２がプライベートデータとしてＩＰヘッダに引き続いてＵＤＰヘッダを収容する場合の実施例、図３はプライベートデータとしてＩＰヘッダ、ＵＤＰヘッダとＲＴＰヘッダを包含して伝送する場合の実施例である。本発明の特徴はＩＰネットワークにおいて使用されるプロトコルのパケットヘッダのデータをプライベートデータとして伝送することであり、特にＵＤＰ、ＲＴＰ等のプロトコルに限定されない。現状では、リアルタイムの映像信号をインタネットで送信するにはＲＴＰを利用するのが一番効果できであることから、図４に示したパケット構成が一番よい。また、図１、図２、図３の実施例では、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダをそのままプライベートデータとして伝送する場合を説明したが、例えばＩＰヘッダを構成するのに必要なデータを形を変形してプライベートデータとして伝送することももちろん可能である。ただし、この場合は、インタワークユニットにおいて伝送されたデータを元にＩＰヘッダ等を再構成する処理が必要となるので、そのままの形式で伝送することがもっとも効果的であることは容易に理解できる。
【００２３】
ここで簡単にデータ形式としてＰＥＳを使用する理由を説明する。図８に示したようにビデオサーバ５５はＣＡＴＶネットワークに接続されたＳＴＢ５７に対しても映像を送信する。インタネット５０に送信する映像とＳＴＢ５７に送信する映像は共用とすることがデータ作成コスト、システムコスト削減の観点から好ましく、従来のＣＡＴＶで用いられているＰＥＳ形式を採用するのが一番適している。なお、アダプテーションフィールドにカプセル化したＩＰヘッダの情報は、映像・音響信号とは個別に処理されるので従来のＳＴＢ５７の映像再生に対してなんら影響を及ぼさない。ＰＥＳ形式とすることで従来のＳＴＢとの信号互換性を保ちながらＩＰネットワークに映像信号を送信することが可能となる。なお、ＲＦＣ２０３８においてはＰＥＳ形式は規定されていないが、ＰＥＳはＥＳを複数のパケットに分割した後ＰＥＳヘッダを付加した構成であるため、容易にＥＳに変換できる。従ってＥＳを受信し復号できるクライアントにおいては、ほとんど機能追加なしで復号可能である。
【００２４】
ここでＩＰパケットの構成方法を補足する。イーサーネットでのＩＰパケットの最大サイズ（Maximum Transfer Unitサイズ） は１５００バイトとなっている。従って、ＭＰＥＧ−ＴＳの１８４バイトのペイロードは最大７個をパッキングできる。そこで、ＴＳパケットを送信する際は、７ＴＳ周期でＩＰヘッダを含むＴＳパケットを送信する。インタワークユニットは、図６に概念的に示したようにＩＰヘッダを含むパケットを受信してＩＰヘッダを構成し、その後引き続いて伝送されるＴＳパケットのペイロードのデータを接続してＩＰパケットを構成する。なお、イーサネットではＭＴＵが１５００バイトであるが、その外の物理ネットワークではＭＴＵサイズが異なる場合があり、そのような場合は、ＭＴＵサイズに応じてＩＰヘッダの送出する周期を変更することはもちろん可能である。本発明では、“ＩＰヘッダを含むＴＳパケットから次のＩＰヘッダを含むＴＳパケットを送信するまでの間のＴＳパケットペイロードの総合計バイトがＭＴＵバイト数を超えなければよい“ということが条件になる。
【００２５】
次に、図１、図２、図３に示したような構成でＭＰＥＧ−ＴＳパケットを構成し、それをインタワークユニットで処理してＩＰネットワークに伝送する方式について説明する。図１２が、インターワークユニットにおける処理の流れを示す実施例である。なお、ここではＣＡＴＶのビデオサーバは図２に示すようなカプセル化方式によりＭＰＥＧ−ＴＳ信号を伝送するものとする。インタワークユニットでは図１２の処理手順に示されるように、伝送されたＭＰＥＧ−ＴＳ信号（パケット）を入力し（手順１００）、この中からＩＰネットワークに送信すべき信号を抽出する。ＭＰＥＧ−ＴＳパケットの選択はＴＳパケットヘッダにあるＰＩＤを検査することで行う。（手順１０２）ＩＰネットワークに伝送するパケットでない場合はそのパケットを廃棄する(手順１１１)。ＩＰネットワークに伝送するパケットである場合は、そのＴＳパケットヘッダにあるアダプテーションフィールドの有無を指示するフラグの検査を行う（手順１０４、１０５）。このフラグの結果、アダプテーションフィールドがある場合は、そのパケットのＴＳヘッダを削除し（手順１０６）、さらに引き続いてアダプテーションフィールドのフラグ情報を削除する（手順１０７）。その結果、アダプテーションフィールドのプライベートデータ部分とそれに引き続くペイロードの部分のデータが出力される（手順１０８）。ＴＳヘッダのアダプテーションフィールドを指示するフラグを検査した結果（手順１０４、１０５）、アダプテーションフィールドがない場合には、そのＴＳパケットのＴＳヘッダのみを削除してペイロードデータを出力する（手順１１２）。この処理の結果、ＴＳヘッダが削除され、プライベートデータに格納していたＩＰパケットヘッダとそれに引き続きペイロードとして画像データがインタワークユニットから送信されることになる。上述のように本実施例のカプセル化によれば、２つのフラグの検査（ＰＩＤの検査、アダプテーションあり／なしの検査）と不要データ部分の廃棄といった極めて単純な処理のみによってＭＰＥＧ−ＴＳからＩＰパケットを生成することができ、インタワークユニットを処理能力の低い、すなわち低コストなプロセッサで構成できるといった絶大な効果が得られる。
【００２６】
次に図１１を用いて、ＩＰパケット化された映像信号を再度ＭＰＥＧ−ＴＳ信号に変換する処理について説明する。図８、図９に示すインタワークユニット５４にはＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダとＰＥＳからなるデータを含むＩＰパケットが入力される。そこで、2バイトのアダプテーション関連のフラグとＩＰ関連のヘッダ（ＩＰ、ＵＤＰ、ＲＴＰヘッダ）をまとめたプライベートデータをアダプテーションフィールドとしてＴＳに格納する。このＴＳの残りのペイロードにはＰＥＳデータを充填し、最終的に１８８バイトのＴＳパケットを構成する。残りのＩＰパケットのペイロードは、１８４バイト毎に区切ってそれぞれをＴＳのペイロードに収容していく。ＣＡＴＶネットワーク内部では、ＩＰヘッダを使うことはありえないが、ＩＰヘッダを廃棄してペイロード部分のみをＴＳペイロードに格納するとデータバイトの不足するＴＳが生じる。この場合不足したデータのパディング等の処理が必要になり、複雑化するので好ましくない。したがって、送信したＣＡＴＶネットワーク内部と同じパケット構成に復元するのが良い。なお、実際にはバイト数のみ合致していれば問題がないので、ＩＰヘッダと同バイト数のダミーデータを挿入することも可能である。前述したように、アダプテーションフィールド内のプライベートデータはＳＴＢにおいて無視することが可能なため、無効データであっても構わない。
【００２７】
――第３実施例――
図４は、本発明の第３の実施例を示す図である。本実施例を適用するネットワークの構成は第１の実施例と同様に図８、及び図９で示したネットワーク構成である。図４の実施例が図１、図２、図３の実施例と異なる点は、アダプテーションフィールドにプログラムクロックリファレンス（ＰＣＲ）を同時に含めて送信する点と、プライベートデータとして伝送するＩＰパケットにＲＴＰヘッダを含めて伝送する点である。ＲＴＰプロトコルでは、映像のようなリアルタイム性を必要とするデータ伝送を保証するためにパケットヘッダ内部に時刻情報（タイムスタンプ）を記録するフィールドが設けてある。ＭＰＥＧ−ＴＳを受信するＣＡＴＶの端末においても復号回路のシステムクロックを再生するためにＰＣＲを利用しており、かつＲＴＰのタイムスタンプはＰＣＲと同じく９０ｋＨｚの基本周波数による時刻をデジタル化したものであるため、ＲＴＰのタイムスタンプとして利用することが可能である。図４の実施例では、アダプテーションフィールドのＰＣＲフィールドで伝送されたＰＣＲをＲＴＰのタイムスタンプフィールドに使うことが特徴である。なお、ＲＴＰのタイムスタンプは３２ビット、ＰＣＲの基本部分は３３ビットのビット幅により時刻情報を表記しているので、ＰＣＲの下位３２ビットをＲＴＰのタイムスタンプとすれば、ビット幅を整合させることができる。このようにＰＣＲで配送された時刻情報をＲＴＰのタイムスタンプとして利用する利点としては、ＣＡＴＶネットワーク内部で発生したパケット配送ジッタを補正する目的からＰＣＲを付け替えられたような場合にも、最終的に補正された正確な時刻情報をＲＴＰヘッダに生め込むことが可能な点が挙げられる。
【００２８】
――第４実施例――
図１０はＩＰネットワークに接続されている図８のサーバ５２からＣＡＴＶネットワーク５６に向けて画像配信を行う時のデータのカプセル化を示す実施例である。この画像の送受信の場合は、インタワークユニット５４においてＩＰパケットで伝送されたＭＰＥＧ画像信号（ＰＥＳ）をＭＰＥＧ−ＴＳ信号に変換する操作が必要になる。この変換操作の処理を図１０により説明する。ＩＰパケットで画像を伝送する場合は、ＴＳへの変換を容易にするためＰＥＳ形式により映像データをカプセル化する。従ってこのＩＰパケットはＩＰヘッダとＰＥＳ形式のペイロードから構成する。この変換操作においては、ＩＰパケットの大きさ（ＩＰヘッダとペイロードを含むデータの大きさ）を、そのパケットサイズから２を減じた値が１８４の整数倍となるようにＩＰパケットを構成してＩＰネットワークにあるサーバから送信する。ＩＰパケットをＭＰＥＧ−ＴＳ化する際には、ＩＰパケットヘッダを含む先頭部分は、１８２バイトを取り出しそれにアダプテーションフィールドのフラグ（２バイト）を付加してＭＰＥＧ−ＴＳの１８４バイトのペイロードとして格納する。さらにこのペイロードにＭＰＥＧ−ＴＳヘッダを付与してＭＰＥＧ−ＴＳパケットを構成する。それ以後のＩＰパケットは１８４バイト毎に区切り、これにＴＳのパケットヘッダを付与してＭＰＥＧ−ＴＳ化する。ＩＰパケットのサイズが、１８４バイトの整数倍と１８２バイトの和となる条件があるので、ＩＰパケットをＭＰＥＧ−ＴＳパケットのペイロードに格納しても余りバイトが出ることなくＴＳのペイロードに格納することが可能となる。以上説明したように本実施例の特徴は、ＭＰＥＧ画像を送信するＩＰネットワークのサーバから送信するＩＰパケットの大きさに制限を設けることでインタワークユニットにおけるパケットの分割・再構成が極めて単純になるといった点にある。
【００２９】
なお、本実施例の変形としてＲＴＰプロトコルを利用し、ＲＴＰのタイムスタンプをＰＣＲとして挿入する場合には、アダプテーションフィールドに設けるＰＣＲフィールド（６バイト）の分を勘案し、ＩＰパケットの全体長を１８４バイトの整数倍に１７８バイトを加算した大きさとなるようにしておけば良い。
【００３０】
――第５実施例――
第５実施例は、第2実施例の変形である。第2の実施例で用いた図１のＩＰパケットのカプセル化ではＭＰＥＧ−ＴＳのプライベートデータにＩＰヘッダを直接マップしたが、本実施例では、図１５に示すように、プライベートデータの先頭バイトにプライベートデータの属性を示す領域１５０を設ける。この属性の領域にフラグを設けることで、プライベートデータとして送信している内容がＩＰヘッダであることを明示的に指示するようにする。インタワークユニットでは、このフラグを用いてＩＰパケットかの判定を行い、利用／廃棄の判断が可能となる。なお、属性領域のデータはＩＰネットワーク内では不要であるのでインタワークユニット内部でプロトコル変換の際に廃棄する必要がある。
【００３１】
なお図１５では、１バイトの属性領域を設ける例を説明したが、この領域は必ずしも1バイトである必要はなく、複数バイトであってもよいことは容易に理解できる。
【００３２】
【発明の効果】
以上、本発明によればＣＡＴＶネットワークをインタネットといったワールドワイドに接続されたネットワークを利用して相互接続することが可能となり、番組コンテンツの共同利用による運用コストの低減といった効果が得られる。また、インタネットとＣＡＴＶ回線を接続するために必要なプロトコル変換に必要な処理を大幅に削減することも達成でき、これにより低コストな処理装置でもインタワークユニットを構成することが可能となるといった絶大な効果が得られる。
【図面の簡単な説明】
【図１】ＩＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図２】ＩＰヘッダ、ＵＤＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図３】ＩＰヘッダ、ＵＤＰヘッダおよびＲＴＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図４】アダプテーションにＰＣＲを含んでカプセル化する方法の実施例。
【図５】図４で伝送されたＰＣＲをＲＴＰのタイムスタンプに格納する実施例を説明する図。
【図６】ＴＳパケットからＩＰパケットを構成する方法の実施例。
【図７】ＩＰパケットヘッダの構造を説明する図。
【図８】インタネットを利用してＣＡＴＶネットワークを接続するシステムの実施例。
【図９】２つのＣＡＴＶネットワークをインタネット接続するネットワーク構成の実施例。
【図１０】ＩＰネットワーク上のサーバから送出するＩＰパケットにより伝送された信号をＭＰＥＧ−ＴＳパケット化する実施例。
【図１１】インタワーク装置によりＩＰ化したパケットを再びＭＰＥＧ−ＴＳ化する実施例。
【図１２】インタワークユニットの信号処理のフローを説明するフローチャート。
【図１３】ＭＰＥＧ−ＴＳの構造を説明する図。
【図１４】ＭＰＥＧ−ＴＳのヘッダの構造を説明する図。
【図１５】プライベートデータにＩＰパケットを指示するフラグを設けた実施例を説明する図。
【符号の説明】
１…ＴＳヘッダ、２…アダプテーションフィールド、３…ペイロード（ＰＥＳ）、４…アダプテーションフィールドフラグ、５…プライベートデータ、６…ＩＰヘッダ、１０…ＵＤＰヘッダ、１４…ＲＴＰヘッダ、２３…ＰＣＲベース、２５…ＰＣＲ拡張、２６…ＲＴＰのタイムスタンプ、５２…インタネット、５１…インタネットルータ、５２…インタネット画像サーバ、５４…インタワークユニット、５５…ＣＡＴＶ画像サーバ、５６…ＣＡＴＶネットワーク、５７…ＳＴＢ、５８…インタネット画像クライアント、６２…インタワークユニット、８０…ＩＰパケットのペイロード、１３１…アダプテーションフィールド、１８０…フラグ。
【発明の属する技術分野】
本発明は、インタネットプロトコルを使ってＭＰＥＧ画像を伝送する方式およびそのシステムに関わり、特にＭＰＥＧ伝送プロトコルとインタネットプロトコルの変換処理を迅速に行う伝送方式変換装置を用いたネットワーク接続方式、および伝送するＭＰＥＧデータのカプセル化方式に関する。
【０００２】
【従来の技術】
映像をデジタル符号化して伝送するシステムの国際標準規格として、"GENERIC CODING OF MOVING PICTURES AND ASSOCIATED AUDIO: SYSTEMS"がＩＳＯ／ＩＥＣ１３８１８−１、ＩＴＵ−Ｔ(International Telecommunication Union) Ｈ．２２２．０勧告として規定されている。このＭＰＥＧシステム国際標準規格（以後、Ｈ．２２２．０と略記する）では、ＭＰＥＧ方式によって圧縮した画像信号を伝送する規格を定めている。Ｈ．２２２．０では、比較的ビットエラー発生の少ない蓄積媒体等からの伝送を想定したプログラムストリーム（以後、ＰＳと略記する）形式と、伝送ビットエラーの発生が予想される通信回線を想定したトランスポートストリーム（以後、ＴＳと略記する）形式の２種類のフォーマットを規定している。
【０００３】
本発明はＴＳ形式で圧縮映像信号を伝送する際の符号変換方式を対象とするため、ここで簡単にＴＳ形式による画像伝送方式について従来技術の説明を行う。映像・音響符号化と伝送を対象としたＭＰＥＧ方式では、入力されるテレビジョン等の映像信号をデジタル化し、このデジタル信号を離散コサイン変換、可変長符号化等の手法を用いてデータ圧縮を行う。また、音響信号に関しては、手法は異なるもののデジタル化した後、冗長なデータを取り除くことで圧縮を行っている。これらの圧縮された信号はエレメンタリーストリーム（以後、ＥＳと略記する）と呼ばれるもので、その言葉の通り画像・音響信号の要素となるデータである。なお、ＭＰＥＧにおいてはこの画像・音響データを（ビット）ストリームという言葉を用いて表している。
【０００４】
ＭＰＥＧ映像信号を伝送するケーブルテレビ、衛星通信回線、または非同期転送モード伝送路（以後、ＡＴＭ回線と略記する）等では、データ伝送の際に比較的ビット誤りが多く発生することが想定されるので、伝送エラーによる障害波及の範囲を狭くするためＥＳを小さなパケットに区切って伝送する。パケット化されたＥＳはパケッタイズドエレメンタリストリーム（以後、ＰＥＳと略記する）と呼ばれるものであり、ＥＳにＰＥＳヘッダと呼ばれるヘッダ情報が付加した形式となっている。上記に例示した通信回線の伝送では、このＰＥＳをさらに小さなトランスポートパケットと呼ばれる１８８バイトのパケットに区切って伝送する。ＴＳパケットは、図１３に示すように４バイトのヘッダと、データを格納するための１８４バイトのペイロードから構成されるパケットである。図１４はＴＳパケットのヘッダ構造を示す図である。TSヘッダは、1バイトの同期バイト（０ｘ４７）と、ＴＳパケットの属性を表すフラグ（本説明では重要でないので個々のフラグの内容については説明を省略する）、１３ビットのパケット識別子（以後PIDと略記する）、スクランブル制御識別子、アダプテーションフィールド識別子とパケットの連続性を検査するのに用いる４ビットの巡回カウンタから構成される。またトランスポートストリームでは、アダプテーションフィールドと呼ばれるフィールドを映像データを格納するペイロードと呼ばれるデータフィールドに先立って伝送することができ、このフィールドにはシステムのクロック同期を目的としたプログラムクロックリファレンス（以後、PCRと略記する）やプライベートデータを格納することが可能である。なおＴＳパケットでアダプテーションフィールドを伝送する際は、ＴＳヘッダのアダプテーションフィールド識別子にてその存在を指示することが規定されている。
【０００５】
ＭＰＥＧ方式はＣＡＴＶやデジタル衛星放送に対応して開発された方式であるが、最近ではコンピュータのデータ通信を主目的に発展を遂げてきたインターネットと呼ばれるネットワークにおいてもＭＰＥＧ画像を利用するサービスが提供されるようになってきた。インタネットにおける通信の相互接続性を確保するため、Internet Engineering Task Force(以後、ＩＥＴＦと略記する)が規格化を進めており、ＭＰＥＧ画像伝送フォーマットの規格はRequest for Comment N0。2038:“RTP Payload Format for MPEG1/MPEG2 Video”（以後、ＲＦＣ２０３８と略記する）により伝送方法やパケットのカプセル化方式が規格化されている。ＲＦＣ２０３８では、伝送するパケットのフォーマットとしてＭＰＥＧのＥＳ、ＴＳ、もしくはＰＳを利用して伝送すること、配送遅延により画質劣化が生じることを回避するためＲＦＣ１８８９により仕様化された“RTP: A Transport Protocol for Real-Time Applications”（以後、ＲＴＰと略記する）により伝送することを定めている。なお、ＲＴＰパケットはユーザデータグラムプロトコル（以後、ＵＤＰと略記する）によるパケットに格納し、さらにこのＵＤＰパケットをインタネットプロトコルパケット（以後、ＩＰパケットと略記する）により伝送することを規定している。以上説明した従来技術によれば、ＣＡＴＶ回線内部ではＭＰＥＧ−ＴＳパケットにより、またインタネット内部ではＩＰパケットによりＭＰＥＧ映像を伝送することが可能である。
【０００６】
【発明が解決しようとする課題】
ＭＰＥＧ−ＴＳ方式により映像伝送を行うのは前述の通りデジタル衛星放送やデジタルＣＡＴＶシステムである。これらのサービスのうち、デジタルＣＡＴＶシステムは地域密着型のサービスであり比較的狭い地域をサービス提供地域として構成されるのが一般的である。そのため各々のＣＡＴＶ事業者が番組を送出するためのＣＡＴＶセンター（以後、ヘッドエンドと略記する）と映像を伝送するためのアクセスネットワークを保有し、ヘッドエンドにおいて受信した地上／衛星放送番組を再送信したり、ヘッドエンドに貯えた番組を必要に応じて送信している。このような従来のＣＡＴＶサービスでは、放送されてきた番組以外の番組は、例えばVTR等に蓄積しておき番組編成に応じて再生する必要があった。近未来のＣＡＴＶサービスとして期待されているビデオオンデマンド等も上記と同様にヘッドエンドに番組のデジタル圧縮信号を保有する形式で構築するのが一般的である。ところでビデオオンデマンドサービスでは、その番組コンテンツを保有するために再放送権（著作権）の購入、番組のデジタル圧縮処理、圧縮映像の蓄積などサービスを維持するためのコストも高く、できるだけ同一番組（コンテンツ）に対するアクセス回数を多くしなければ採算が取れないといった課題がある。この課題を解決するには、例えば、複数のＣＡＴＶ事業者が共同でコンテンツを保有し、通信回線を使ってこのコンテンツを必要な時に伝送して利用する等の方法が効果的である。
【０００７】
このようなシステムを構築するには複数のCATV事業者のヘッドエンド、ネットワークを通信回線を使って接続する必要がある。例えば、米国のＣＡＴＶヘッドエンドと日本のＣＡＴＶ加入者の映像受信機であるセットトップ端末（以後、ＳＴＢと略記する）を接続するためには、少なくとも米国と日本の間の通信回線を利用して接続しなければならない。ところが、現状ではデジタルＣＡＴＶで一般的に利用されているＭＰＥＧ−ＴＳをそのままの形式で伝送することは現実的ではない。すなわちＭＰＥＧ−ＴＳの映像伝送では、ＡＴＭ回線や衛星回線等の専用通信回線を利用しなければならず、かつこの専用線は通信料金が高いといった問題がある。また専用線であるため、契約地点を常時接続して利用することが前提となっており、オンデマンドサービスのようにユーザの要求に応じてネットワークを占有するようなサービスに用いるにはコストパフォーマンスの点で大きな問題がある。
【０００８】
【課題を解決するための手段】
上記の課題を解決するため、本発明では複数のＣＡＴＶネットワークをインタネットにより接続する手段を用いる。インタネットは全世界に張り巡らされたネットワークであり、個々の端末やホストコンピュータに付与されたアドレスにより動的に接続変更が可能であるといった特徴をもつ。そのため予め接続地点を固定しておく必要もなく、映像を配信したい際にアドレスを使って接続するため、専用線では実現できない自由な接続設定、および低コストな映像通信が可能である。なお現状のインタネットでは伝送帯域幅等が狭いといった問題もあるが、ギガビットルータや帯域予約プロトコル（Resource reservation setup Protocol：ＲＳＶＰ）等により伝送帯域を確保することにより、帯域不足は近い将来問題とはならなくなり、グローバルなネットワーク環境がインタネットにより実現されることは容易に予想できる。
【０００９】
さらに上記のようにインターネットを用いてＣＡＴＶネットワークを接続する際に新たに発生する課題：“ＣＡＴＶネットワークで用いているＭＰＥＧ伝送プロトコルとインターネットで用いるＩＰプロトコルの間のプロトコル変換が必要である”に対して本発明では、ＭＰＥＧ−ＴＳプロトコルとインターネットプロトコルを変換するインタワークユニットを設けることで解決する。このインタワークユニットにおいて処理の高速化と低価格化を実現しなければならないといった課題に対しては、ＭＰＥＧネットワーク、ＩＰネットワーク内部で伝送するパケットの構成方法、変換方法を改良する手段を提供することによって解決する。
【００１０】
具体的には、１） ＭＰＥＧ−ＴＳ方式で規定されたアダプテーションフィールドのプライベートデータ領域にＩＰパケットのヘッダを格納して伝送し、インタワークユニットではこのアダプテーション領域のプライベートデータを解析することなくそのままＩＰパケットのヘッダとしてインタネット内部を伝送するパケットを構成する手段、２）インタネットからＭＰＥＧ映像信号を伝送する際には、送信するＩＰパケットの大きさをＭＰＥＧ−ＴＳに分割する時にあまることなくペイロードに収容可能なサイズの制約条件を設けて伝送するといった手段とを採用する。
【００１１】
【発明の実施の形態】
以下、本発明による実施例を図面を参照しながら詳細に説明する。
【００１２】
――第1実施形態――
図９は、本発明によるＣＡＴＶシステムの接続形態を示す実施例である。このＣＡＴＶシステムは、２個所のＣＡＴＶネットワーク６１、５６をインタネット５０で接続する点に特徴がある。図示するように本ＣＡＴＶシステムは、ビデオサーバ６０とそれに接続されたＣＡＴＶ ネットワーク６１、インタネット５０、インタネット５０とＣＡＴＶネットワーク６１を接続するためのインタワークユニット６２、さらに第２のＣＡＴＶネットワーク５６と、そのネットワーク５６とインタネット５０を接続するインタワークユニット５４から構成する。ＣＡＴＶネットワーク５６には、映像を受信するためのＳＴＢ５７が接続されている。 ビデオサーバ６０からの映像信号はインタワークユニット６２を介してインタネット５０に伝送され、ルータ網によりインタワークユニット５４に配送される。インタワークユニット５４はインタネットを使って伝送された映像信号をＣＡＴＶネットワーク５６に供給し、これによりＳＴＢ５７において映像受信を可能とする。
【００１３】
ここでインタワーキングユニットの機能を簡単に説明する。ＣＡＴＶネットワークにおいては、従来技術の項で説明した通りＭＰＥＧ−ＴＳ方式により映像信号を伝送している。これに対してインタネットではＲＦＣ２０３８に代表されるインタネットプロトコルによる画像伝送を行っている。異なるプロトコルを使用するネットワークを相互接続するインタワークユニット６２は、ＭＰＥＧ−ＴＳプロトコルからインタネットプロトコルに準拠した信号形式に変換する機能がある。一方、インタワークユニット５４は、インタネットプロトコルにより伝送された画像信号をＭＰＥＧ−ＴＳプロトコルに変換する機能を有する。このようなインタワークユニット６２、５４を用いて異なるＣＡＴＶネットワークをインタネットを介して接続することで、距離的に遠く離れたＣＡＴＶのビデオサーバとＳＴＢを容易に接続できるといったこれまでにない機能が実現できる。インタネットは全世界に発達したネットワークであり、この構成によれば全世界のビデオサーバとＳＴＢの接続性を確保できるといった絶大な効果が得られる。
【００１４】
なお、図９の実施例では映像信号を発生する装置としてビデオサーバを例にとり説明したが、本発明の趣旨はＭＰＥＧプロトコルで供給される映像信号をインタネットを介して配送することにあり、その信号供給源はビデオサーバのみに限定されるものではない。ビデオサーバ以外にＭＰＥＧ信号を供給する装置としてはリアルタイムのＭＰＥＧエンコーダや、衛星放送を受信してＭＰＥＧ信号を出力するような受信設備があり、これらの装置であっても本発明の趣旨が満足されることは言うまでもない。
【００１５】
さらに、本実施例では簡単のために２個所の異なるＣＡＴＶネットワークを相互接続する例を説明したが、インタネットに接続されるＣＡＴＶシステムは２個所以上であっても構わないことは言うに及ばない。本発明の趣旨は、インターワークユニットを用いてＭＰＥＧ―ＴＳ方式で伝送された信号をインタネットにより伝送可能な形式に変換しこの変換された映像信号をインタネットにより伝送すること、及びインタネットを使って伝送された信号をインタワークユニットにより再びＭＰＥＧ−ＴＳ信号に変換してＣＡＴＶネットワークに伝送する点にある。
【００１６】
――第２実施形態――
第２実施例では、第１実施例により説明したインタネット経由のＣＡＴＶ接続に加え、インタネット上のサーバからＣＡＴＶ上のＳＴＢへの映像送信、ＣＡＴＶ上の映像サーバからインタネット上のクライアントＰＣに対する映像送信をも考慮にいれた共用的な映像伝送プロトコルと、異なるネットワーク間のプロトコルを変換する方式を開示する。
【００１７】
図８はＣＡＴＶ上のビデオサーバ５５からインタネットのクライアント４への映像伝送と、インタネット上のサーバ５２からＣＡＴＶネットワーク上のＳＴＢ５７の映像伝送をともに可能とするネットワーク構成の接続図である。
【００１８】
まず、ＣＡＴＶネットワーク５６に接続されたビデオサーバ５５からインタネット上のクライアント４に映像を伝送する場合を説明する。なお、インタネット上のサーバからＣＡＴＶネットワーク上のＳＴＵに映像伝送する際のパケット化とプロトコル変換については第４実施例にて詳細に説明する。
【００１９】
ビデオサーバ５５からクライアント４に映像伝送する場合は、ビデオサーバ５５は図１に示すパケット構成により映像送信を行う。この映像信号は、ＣＡＴＶネットワーク５６によりＭＰＥＧ−ＴＳ方式によりインタワークユニット６２に達する。インタワークユニット６２は後述する変換方式によってＭＰＥＧ−ＴＳにより運ばれた映像信号をインタネットプロトコルにより伝送可能なパケットにプロトコル変換しインタネット５１に送信する。インタネット５１ではＩＰプロトコルを利用してクライアント４に映像信号を配送する。なお、この信号はクライアント４に送信するのと同様な方法によりインタワークユニット５４に送信することもできる。ＣＡＴＶネットワークの相互接続ではこのインタワークユニット５４にてＭＰＥＧ−ＴＳに再度プロトコルの変換を行う。
【００２０】
ここで図１に示したパケットのカプセル化の方法を詳細に説明する。図１は、図８のビデオサーバ５５からインタネット５０、およびＣＡＴＶ網５６に接続されたＳＴＢ５７、さらにはインタワークユニット５４を介して接続される別ＣＡＴＶネットワーク上のＳＴＢに送信するＭＰＥＧ−ＴＳ信号の構成を示した実施例である。ＭＰＥＧ−ＴＳでは、４バイトのＴＳヘッダー１に引き続き、データを格納するペイロードを伝送する場合と、アダプテーションフィールド２をペイロードに先立って伝送することが許容されている。本発明ではＩＰネットワークに信号を伝送する場合には、図１に示すように、ＩＰヘッダを送信するＴＳではＴＳヘッダの直後に必ずアダプテーションフィールド２を挿入し、このアダプテーションフィールド２を使ってＩＰヘッダを伝送する。アダプテーションフィールド２は、伝送するデータの内容を示す２バイトのフラグ４と、プライベートデータ５を格納する。なお、プライベートデータ５を伝送するため、アダプテーションフィールドの内容を指示するフラグ（transport_private_data_flag）によりプライベートデータ５を伝送することを指示し、かつそのプライベートデータ５のサイズをフラグ内にプライベートデータ長（transport_private_data_length）として設定する。このプライベートデータ５として２０バイトのＩＰパケットヘッダ６をそのままのビット配列で格納する。図７は、このプライベートデータ５に格納するＩＰパケットの内容を示した図である。ＩＰパケットヘッダは、バージョンを示す４ビットのフィールド、ヘッダ長、サービスタイプ、全パケット長、識別子や送信元ＩＰアドレス、宛先ＩＰアドレスから構成され、オプションがない場合では２０バイトから構成される。一般的な条件でオプションは使用しないので２０バイトのフィールドを含むデータをそのままプライベートデータ領域に格納して伝送する。
【００２１】
なお、アダプテーションフィールドに引き続いてＴＳのペイロードにはＰＥＳの形式でデータを格納する。ＰＥＳ形式で映像信号を伝送する理由については後に説明する。
【００２２】
図１の実施例では、プライベートデータとしてＩＰパケットヘッダのみを含めて伝送する例を示したが、ＩＰネットワークに接続される端末（クライアント）がサポートするプロトコルに応じて、UDPヘッダ、もしくはＵＤＰヘッダとＲＴＰヘッダの双方を包含する形式としても構わない。図２がプライベートデータとしてＩＰヘッダに引き続いてＵＤＰヘッダを収容する場合の実施例、図３はプライベートデータとしてＩＰヘッダ、ＵＤＰヘッダとＲＴＰヘッダを包含して伝送する場合の実施例である。本発明の特徴はＩＰネットワークにおいて使用されるプロトコルのパケットヘッダのデータをプライベートデータとして伝送することであり、特にＵＤＰ、ＲＴＰ等のプロトコルに限定されない。現状では、リアルタイムの映像信号をインタネットで送信するにはＲＴＰを利用するのが一番効果できであることから、図４に示したパケット構成が一番よい。また、図１、図２、図３の実施例では、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダをそのままプライベートデータとして伝送する場合を説明したが、例えばＩＰヘッダを構成するのに必要なデータを形を変形してプライベートデータとして伝送することももちろん可能である。ただし、この場合は、インタワークユニットにおいて伝送されたデータを元にＩＰヘッダ等を再構成する処理が必要となるので、そのままの形式で伝送することがもっとも効果的であることは容易に理解できる。
【００２３】
ここで簡単にデータ形式としてＰＥＳを使用する理由を説明する。図８に示したようにビデオサーバ５５はＣＡＴＶネットワークに接続されたＳＴＢ５７に対しても映像を送信する。インタネット５０に送信する映像とＳＴＢ５７に送信する映像は共用とすることがデータ作成コスト、システムコスト削減の観点から好ましく、従来のＣＡＴＶで用いられているＰＥＳ形式を採用するのが一番適している。なお、アダプテーションフィールドにカプセル化したＩＰヘッダの情報は、映像・音響信号とは個別に処理されるので従来のＳＴＢ５７の映像再生に対してなんら影響を及ぼさない。ＰＥＳ形式とすることで従来のＳＴＢとの信号互換性を保ちながらＩＰネットワークに映像信号を送信することが可能となる。なお、ＲＦＣ２０３８においてはＰＥＳ形式は規定されていないが、ＰＥＳはＥＳを複数のパケットに分割した後ＰＥＳヘッダを付加した構成であるため、容易にＥＳに変換できる。従ってＥＳを受信し復号できるクライアントにおいては、ほとんど機能追加なしで復号可能である。
【００２４】
ここでＩＰパケットの構成方法を補足する。イーサーネットでのＩＰパケットの最大サイズ（Maximum Transfer Unitサイズ） は１５００バイトとなっている。従って、ＭＰＥＧ−ＴＳの１８４バイトのペイロードは最大７個をパッキングできる。そこで、ＴＳパケットを送信する際は、７ＴＳ周期でＩＰヘッダを含むＴＳパケットを送信する。インタワークユニットは、図６に概念的に示したようにＩＰヘッダを含むパケットを受信してＩＰヘッダを構成し、その後引き続いて伝送されるＴＳパケットのペイロードのデータを接続してＩＰパケットを構成する。なお、イーサネットではＭＴＵが１５００バイトであるが、その外の物理ネットワークではＭＴＵサイズが異なる場合があり、そのような場合は、ＭＴＵサイズに応じてＩＰヘッダの送出する周期を変更することはもちろん可能である。本発明では、“ＩＰヘッダを含むＴＳパケットから次のＩＰヘッダを含むＴＳパケットを送信するまでの間のＴＳパケットペイロードの総合計バイトがＭＴＵバイト数を超えなければよい“ということが条件になる。
【００２５】
次に、図１、図２、図３に示したような構成でＭＰＥＧ−ＴＳパケットを構成し、それをインタワークユニットで処理してＩＰネットワークに伝送する方式について説明する。図１２が、インターワークユニットにおける処理の流れを示す実施例である。なお、ここではＣＡＴＶのビデオサーバは図２に示すようなカプセル化方式によりＭＰＥＧ−ＴＳ信号を伝送するものとする。インタワークユニットでは図１２の処理手順に示されるように、伝送されたＭＰＥＧ−ＴＳ信号（パケット）を入力し（手順１００）、この中からＩＰネットワークに送信すべき信号を抽出する。ＭＰＥＧ−ＴＳパケットの選択はＴＳパケットヘッダにあるＰＩＤを検査することで行う。（手順１０２）ＩＰネットワークに伝送するパケットでない場合はそのパケットを廃棄する(手順１１１)。ＩＰネットワークに伝送するパケットである場合は、そのＴＳパケットヘッダにあるアダプテーションフィールドの有無を指示するフラグの検査を行う（手順１０４、１０５）。このフラグの結果、アダプテーションフィールドがある場合は、そのパケットのＴＳヘッダを削除し（手順１０６）、さらに引き続いてアダプテーションフィールドのフラグ情報を削除する（手順１０７）。その結果、アダプテーションフィールドのプライベートデータ部分とそれに引き続くペイロードの部分のデータが出力される（手順１０８）。ＴＳヘッダのアダプテーションフィールドを指示するフラグを検査した結果（手順１０４、１０５）、アダプテーションフィールドがない場合には、そのＴＳパケットのＴＳヘッダのみを削除してペイロードデータを出力する（手順１１２）。この処理の結果、ＴＳヘッダが削除され、プライベートデータに格納していたＩＰパケットヘッダとそれに引き続きペイロードとして画像データがインタワークユニットから送信されることになる。上述のように本実施例のカプセル化によれば、２つのフラグの検査（ＰＩＤの検査、アダプテーションあり／なしの検査）と不要データ部分の廃棄といった極めて単純な処理のみによってＭＰＥＧ−ＴＳからＩＰパケットを生成することができ、インタワークユニットを処理能力の低い、すなわち低コストなプロセッサで構成できるといった絶大な効果が得られる。
【００２６】
次に図１１を用いて、ＩＰパケット化された映像信号を再度ＭＰＥＧ−ＴＳ信号に変換する処理について説明する。図８、図９に示すインタワークユニット５４にはＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダとＰＥＳからなるデータを含むＩＰパケットが入力される。そこで、2バイトのアダプテーション関連のフラグとＩＰ関連のヘッダ（ＩＰ、ＵＤＰ、ＲＴＰヘッダ）をまとめたプライベートデータをアダプテーションフィールドとしてＴＳに格納する。このＴＳの残りのペイロードにはＰＥＳデータを充填し、最終的に１８８バイトのＴＳパケットを構成する。残りのＩＰパケットのペイロードは、１８４バイト毎に区切ってそれぞれをＴＳのペイロードに収容していく。ＣＡＴＶネットワーク内部では、ＩＰヘッダを使うことはありえないが、ＩＰヘッダを廃棄してペイロード部分のみをＴＳペイロードに格納するとデータバイトの不足するＴＳが生じる。この場合不足したデータのパディング等の処理が必要になり、複雑化するので好ましくない。したがって、送信したＣＡＴＶネットワーク内部と同じパケット構成に復元するのが良い。なお、実際にはバイト数のみ合致していれば問題がないので、ＩＰヘッダと同バイト数のダミーデータを挿入することも可能である。前述したように、アダプテーションフィールド内のプライベートデータはＳＴＢにおいて無視することが可能なため、無効データであっても構わない。
【００２７】
――第３実施例――
図４は、本発明の第３の実施例を示す図である。本実施例を適用するネットワークの構成は第１の実施例と同様に図８、及び図９で示したネットワーク構成である。図４の実施例が図１、図２、図３の実施例と異なる点は、アダプテーションフィールドにプログラムクロックリファレンス（ＰＣＲ）を同時に含めて送信する点と、プライベートデータとして伝送するＩＰパケットにＲＴＰヘッダを含めて伝送する点である。ＲＴＰプロトコルでは、映像のようなリアルタイム性を必要とするデータ伝送を保証するためにパケットヘッダ内部に時刻情報（タイムスタンプ）を記録するフィールドが設けてある。ＭＰＥＧ−ＴＳを受信するＣＡＴＶの端末においても復号回路のシステムクロックを再生するためにＰＣＲを利用しており、かつＲＴＰのタイムスタンプはＰＣＲと同じく９０ｋＨｚの基本周波数による時刻をデジタル化したものであるため、ＲＴＰのタイムスタンプとして利用することが可能である。図４の実施例では、アダプテーションフィールドのＰＣＲフィールドで伝送されたＰＣＲをＲＴＰのタイムスタンプフィールドに使うことが特徴である。なお、ＲＴＰのタイムスタンプは３２ビット、ＰＣＲの基本部分は３３ビットのビット幅により時刻情報を表記しているので、ＰＣＲの下位３２ビットをＲＴＰのタイムスタンプとすれば、ビット幅を整合させることができる。このようにＰＣＲで配送された時刻情報をＲＴＰのタイムスタンプとして利用する利点としては、ＣＡＴＶネットワーク内部で発生したパケット配送ジッタを補正する目的からＰＣＲを付け替えられたような場合にも、最終的に補正された正確な時刻情報をＲＴＰヘッダに生め込むことが可能な点が挙げられる。
【００２８】
――第４実施例――
図１０はＩＰネットワークに接続されている図８のサーバ５２からＣＡＴＶネットワーク５６に向けて画像配信を行う時のデータのカプセル化を示す実施例である。この画像の送受信の場合は、インタワークユニット５４においてＩＰパケットで伝送されたＭＰＥＧ画像信号（ＰＥＳ）をＭＰＥＧ−ＴＳ信号に変換する操作が必要になる。この変換操作の処理を図１０により説明する。ＩＰパケットで画像を伝送する場合は、ＴＳへの変換を容易にするためＰＥＳ形式により映像データをカプセル化する。従ってこのＩＰパケットはＩＰヘッダとＰＥＳ形式のペイロードから構成する。この変換操作においては、ＩＰパケットの大きさ（ＩＰヘッダとペイロードを含むデータの大きさ）を、そのパケットサイズから２を減じた値が１８４の整数倍となるようにＩＰパケットを構成してＩＰネットワークにあるサーバから送信する。ＩＰパケットをＭＰＥＧ−ＴＳ化する際には、ＩＰパケットヘッダを含む先頭部分は、１８２バイトを取り出しそれにアダプテーションフィールドのフラグ（２バイト）を付加してＭＰＥＧ−ＴＳの１８４バイトのペイロードとして格納する。さらにこのペイロードにＭＰＥＧ−ＴＳヘッダを付与してＭＰＥＧ−ＴＳパケットを構成する。それ以後のＩＰパケットは１８４バイト毎に区切り、これにＴＳのパケットヘッダを付与してＭＰＥＧ−ＴＳ化する。ＩＰパケットのサイズが、１８４バイトの整数倍と１８２バイトの和となる条件があるので、ＩＰパケットをＭＰＥＧ−ＴＳパケットのペイロードに格納しても余りバイトが出ることなくＴＳのペイロードに格納することが可能となる。以上説明したように本実施例の特徴は、ＭＰＥＧ画像を送信するＩＰネットワークのサーバから送信するＩＰパケットの大きさに制限を設けることでインタワークユニットにおけるパケットの分割・再構成が極めて単純になるといった点にある。
【００２９】
なお、本実施例の変形としてＲＴＰプロトコルを利用し、ＲＴＰのタイムスタンプをＰＣＲとして挿入する場合には、アダプテーションフィールドに設けるＰＣＲフィールド（６バイト）の分を勘案し、ＩＰパケットの全体長を１８４バイトの整数倍に１７８バイトを加算した大きさとなるようにしておけば良い。
【００３０】
――第５実施例――
第５実施例は、第2実施例の変形である。第2の実施例で用いた図１のＩＰパケットのカプセル化ではＭＰＥＧ−ＴＳのプライベートデータにＩＰヘッダを直接マップしたが、本実施例では、図１５に示すように、プライベートデータの先頭バイトにプライベートデータの属性を示す領域１５０を設ける。この属性の領域にフラグを設けることで、プライベートデータとして送信している内容がＩＰヘッダであることを明示的に指示するようにする。インタワークユニットでは、このフラグを用いてＩＰパケットかの判定を行い、利用／廃棄の判断が可能となる。なお、属性領域のデータはＩＰネットワーク内では不要であるのでインタワークユニット内部でプロトコル変換の際に廃棄する必要がある。
【００３１】
なお図１５では、１バイトの属性領域を設ける例を説明したが、この領域は必ずしも1バイトである必要はなく、複数バイトであってもよいことは容易に理解できる。
【００３２】
【発明の効果】
以上、本発明によればＣＡＴＶネットワークをインタネットといったワールドワイドに接続されたネットワークを利用して相互接続することが可能となり、番組コンテンツの共同利用による運用コストの低減といった効果が得られる。また、インタネットとＣＡＴＶ回線を接続するために必要なプロトコル変換に必要な処理を大幅に削減することも達成でき、これにより低コストな処理装置でもインタワークユニットを構成することが可能となるといった絶大な効果が得られる。
【図面の簡単な説明】
【図１】ＩＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図２】ＩＰヘッダ、ＵＤＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図３】ＩＰヘッダ、ＵＤＰヘッダおよびＲＴＰヘッダをＭＰＥＧ−ＴＳパケットにカプセル化して伝送する方式の実施例。
【図４】アダプテーションにＰＣＲを含んでカプセル化する方法の実施例。
【図５】図４で伝送されたＰＣＲをＲＴＰのタイムスタンプに格納する実施例を説明する図。
【図６】ＴＳパケットからＩＰパケットを構成する方法の実施例。
【図７】ＩＰパケットヘッダの構造を説明する図。
【図８】インタネットを利用してＣＡＴＶネットワークを接続するシステムの実施例。
【図９】２つのＣＡＴＶネットワークをインタネット接続するネットワーク構成の実施例。
【図１０】ＩＰネットワーク上のサーバから送出するＩＰパケットにより伝送された信号をＭＰＥＧ−ＴＳパケット化する実施例。
【図１１】インタワーク装置によりＩＰ化したパケットを再びＭＰＥＧ−ＴＳ化する実施例。
【図１２】インタワークユニットの信号処理のフローを説明するフローチャート。
【図１３】ＭＰＥＧ−ＴＳの構造を説明する図。
【図１４】ＭＰＥＧ−ＴＳのヘッダの構造を説明する図。
【図１５】プライベートデータにＩＰパケットを指示するフラグを設けた実施例を説明する図。
【符号の説明】
１…ＴＳヘッダ、２…アダプテーションフィールド、３…ペイロード（ＰＥＳ）、４…アダプテーションフィールドフラグ、５…プライベートデータ、６…ＩＰヘッダ、１０…ＵＤＰヘッダ、１４…ＲＴＰヘッダ、２３…ＰＣＲベース、２５…ＰＣＲ拡張、２６…ＲＴＰのタイムスタンプ、５２…インタネット、５１…インタネットルータ、５２…インタネット画像サーバ、５４…インタワークユニット、５５…ＣＡＴＶ画像サーバ、５６…ＣＡＴＶネットワーク、５７…ＳＴＢ、５８…インタネット画像クライアント、６２…インタワークユニット、８０…ＩＰパケットのペイロード、１３１…アダプテーションフィールド、１８０…フラグ。
Claims (17)
- ＴＳパケットをＩＰパケットに変換するパケット変換方法であって、上記ＩＰパケットのＩＰアドレスに関する情報を持つＴＳパケットを受信するステップ、上記受信した１つのＴＳパケットのアダプテーション領域内の情報からＩＰパケットのＩＰアドレスを得るステップ、該ＴＳパケットのデータから上記ＩＰパケットのデータを得るステップ、上記得られたＩＰアドレスと上記得られた上記ＩＰパケットのデータとからＩＰパケットを得るステップ、及び、上記得られたＩＰパケットを送信するステップを有するパケット変換方法。
- 上記ＩＰパケットを得るステップは、複数のＩＰパケットのデータと上記得られたＩＰアドレスから得る請求項１記載のパケット変換方法。
- 上記ＩＰパケットのデータはＰＥＳ形式である請求項１または２記載のパケット変換方法。
- 上記ＩＰパケットのバイト数は、１８２バイトと１８４バイトの整数倍との和である請求項１ないし３のうちいずれかに記載のパケット変換方法。
- ＩＴＵ−Ｔ Ｈ．２２２．０勧告により規定されたＭＰＥＧ ＴＳパケットの伝送方法であって、該ＴＳパケットのアダプテーションフィールドのプライベートデータとしてＩＰパケットのヘッダ情報を構成するのに必要な情報をカプセル化し、そのデータカプセルを周期的に伝送することを特徴とする伝送方法。
- ＩＴＵ−Ｔ Ｈ．２２２．０勧告により規定されたＭＰＥＧ ＴＳパケットの伝送方法であって、該ＴＳパケットのアダプテーションフィールドのプライベートデータとしてＩＰパケットヘッダを格納し、そのＩＰパケットヘッダを含むＴＳパケットを周期的に伝送する伝送方法。
- 請求項１記載のパケット変換方法であって、上記ＩＰパケットの大きさが、該ＩＰパケットの大きさより２バイトを足した値が１８４バイトの整数倍であることを特徴とするパケット変換方法。
- 請求項１記載のパケット変換方法であって、上記ＩＰパケットの大きさが、該ＩＰパケットの大きさより８バイトを足した値が１８４バイトの整数倍であることを特徴とするパケット変換方法。
- アダプテーションのフィールドのプライベートデータフィールドによりＩＰパケットのヘッダ情報をカプセル化し、またプログラムクロックリファレンス（ＰＣＲ）信号をこのアダプテーションフィールド内に包含して伝送し、該ＩＰパケットは伝送プロトコルとしてＵＤＰプロトコルとＲＴＰプロトコルを使用しＲＴＰプロトコルヘッダの３２ビットのタイムスタンプ信号に上記ＰＣＲ信号の下位32ビットを複製するＭＰＥＧプロトコルとＩＰの変換方法。
- ＴＳパケットを転送する第１のネットワークと、該第１のネットワークに接続されたビデオ供給源と、上記第１のネットワークおよびＩＰパケットを転送する第２のネットワークの双方に接続されたプロトコル変換装置とを有し、上記ビデオ供給源から上記第１のネットワークを介して上記プロトコル変換装置にビデオデータを伝送する際に、上記ビデオ供給源が、同一ビデオデータから形成される複数のＴＳパケットのうち少なくとも１つのＴＳパケットについてアダプテーションフィールドを挿入し、挿入したアダプテーションフィールド内にＩＰヘッダを格納して、各ＴＳパケットを上記第１のネットワークに送出し、上記プロトコル変換装置が、アダプテーションフィールドが挿入されたＴＳパケットからＩＰヘッダを抽出し、抽出されたＩＰヘッダを用いてＴＳパケットをＩＰパケットに変換し、上記第２のネットワークに送出することを特徴とするＣＡＴＶシステム。
- 上記ビデオ供給源が、連続するＴＳパケットのＮ個に１個の割合で、アダプテーションフィールドを挿入しＩＰヘッダを格納することを特徴とする請求項１０に記載のＣＡＴＶシステム。
- 上記プロトコル変換装置が、連続するＮ個のＴＳパケットを１個のＩＰパケットに変換することを特徴とする請求項1１に記載のＣＡＴＶシステム。
- ＴＳパケットをＩＰパケットに変換するプロトコル変換方法であって、同一ＰＩＤ値を持つ複数のＴＳパケットのうちアダプテーションフィールドが挿入されたＴＳパケットからＩＰヘッダを抽出し、 抽出されたＩＰヘッダと、ＩＰヘッダが抽出されたＴＳパケットのペイロードのデータと、ＩＰヘッダが抽出されたＴＳパケットに後続する少なくとも１つのＴＳパケットのペイロードのデータとを用いて、１つのＩＰパケットを形成することを特徴とするプロトコル変換方法。
- ＴＳパケットを転送する第２ネットワークに接続され、かつ、上記第２のネットワークに接続されるＩＰパケットを転送する第１のネットワークに接続される装置へ向け、ＭＰＥＧ信号をＴＳパケットを用いて上記第２のネットワークを介して送信する映像供給装置のパケット送信方法であって、上記第２ネットワークへ送信するＴＳパケットのアダプテーションフィールドに上記第１のネットワークでのＩＰパケットのヘッダ情報を設定するステップ、及び、上記ヘッダ情報を設定した上記ＴＳパケットを上記第２ネットワークへ送信するステップを備える映像供給装置のパケット送信方法。
- 上記設定するステップは、上記第２ネットワークへ送信する複数の連続するＴＳパケットのうちの一つのＴＳパケットに対して実行する請求項１４記載の映像供給装置のパケット送信方法。
- ＴＳパケットをＩＰパケットに変換するパケット変換装置であって、
上記ＩＰパケットのＩＰアドレスに関する情報を持つＴＳパケットを受信する受信部と、
上記受信した１つのＴＳパケットのアダプテーション領域内の情報からＩＰパケットのＩＰアドレスを得る手段と、
該ＴＳパケットのデータから上記ＩＰパケットのデータを得る手段と、
上記得られたＩＰアドレスと上記得られた上記ＩＰパケットのデータとからＩＰパケットを得る手段と、
上記得られたＩＰパケットを送信する送信部を有するパケット変換装置。 - 請求項１６記載のパケット変換装置であって、
上記アダプテーション領域内には上記ＩＰアドレスを含むＩＰヘッダが含まれることを特徴とするパケット変換装置。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24067897A JP4109735B2 (ja) | 1997-09-05 | 1997-09-05 | パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 |
| EP98116657A EP0901261B1 (en) | 1997-09-05 | 1998-09-03 | Transport protocol conversion method and protocol conversion equipment |
| US09/148,326 US6557031B1 (en) | 1997-09-05 | 1998-09-04 | Transport protocol conversion method and protocol conversion equipment |
| US09/597,825 US6785733B1 (en) | 1997-09-05 | 2000-06-19 | Transport protocol conversion method and protocol conversion equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24067897A JP4109735B2 (ja) | 1997-09-05 | 1997-09-05 | パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1188856A JPH1188856A (ja) | 1999-03-30 |
| JP4109735B2 true JP4109735B2 (ja) | 2008-07-02 |
Family
ID=17063088
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24067897A Expired - Lifetime JP4109735B2 (ja) | 1997-09-05 | 1997-09-05 | パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4109735B2 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6611654B1 (en) * | 1999-04-01 | 2003-08-26 | Koninklijke Philips Electronics Nv | Time- and location-driven personalized TV |
| KR100872138B1 (ko) * | 2000-02-24 | 2008-12-08 | 오병석 | 주문형 멀티미디어 콘텐츠 제공 시스템 및 방법 |
| JP4519389B2 (ja) * | 2000-03-08 | 2010-08-04 | ゼネラル インスツルメント コーポレーション | パーソナル多機能レコーダ、並びにそれを実装及び使用する方法 |
| US6879581B1 (en) * | 2000-08-22 | 2005-04-12 | Qualcomm Incorporated | Method and apparatus for providing real-time packetized voice and data services over a wireless communication network |
| JP2002262264A (ja) * | 2001-03-01 | 2002-09-13 | Nippon Telegr & Teleph Corp <Ntt> | 伝送方式変換装置およびその変換方法 |
| US7389463B2 (en) | 2001-05-29 | 2008-06-17 | Thomson Licensing | Hierarchical block coding for a packet-based communications system |
| KR100442473B1 (ko) * | 2002-05-30 | 2004-07-30 | 주식회사 클릭티브이 | 네트워크를 통한 디지털 동영상제어장치 |
| EP1553774B1 (en) | 2002-07-16 | 2019-03-13 | Panasonic Corporation | Content receiving apparatus and content transmitting apparatus |
| JP4561822B2 (ja) * | 2002-07-16 | 2010-10-13 | パナソニック株式会社 | コンテンツ受信機 |
| JP4882213B2 (ja) * | 2003-09-02 | 2012-02-22 | ソニー株式会社 | コンテンツ受信装置、ビデオオーディオ出力タイミング制御方法及びコンテンツ提供システム |
| FR2861517B1 (fr) | 2003-10-23 | 2006-01-27 | Thomson Licensing Sa | Methode de reconstruction de paquets perdus et appareils implementant la methode |
| CN101036389B (zh) | 2004-09-02 | 2012-05-02 | 索尼株式会社 | 内容接收器、视频/音频输出定时控制方法和内容提供系统 |
| JP4868392B2 (ja) * | 2006-02-28 | 2012-02-01 | 独立行政法人 宇宙航空研究開発機構 | データにセッション識別符号を割り当てることによって、データとデータの間の分離を行うことを可能とする装置、方法、および、コンピュータプログラム |
| JP2007329606A (ja) * | 2006-06-07 | 2007-12-20 | Hitachi Ltd | 中継装置 |
| JP4597927B2 (ja) * | 2006-08-30 | 2010-12-15 | 日本テレビ放送網株式会社 | 放送中継システム及びその方法 |
| JP5819664B2 (ja) * | 2011-07-26 | 2015-11-24 | 西日本電信電話株式会社 | ゲートウェイ装置およびパケット変換システム |
| JP5479444B2 (ja) * | 2011-12-28 | 2014-04-23 | トムソン ライセンシング | 同期バイトを伝送パケットに挿入するシステム及び方法 |
-
1997
- 1997-09-05 JP JP24067897A patent/JP4109735B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1188856A (ja) | 1999-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6557031B1 (en) | Transport protocol conversion method and protocol conversion equipment | |
| US6785733B1 (en) | Transport protocol conversion method and protocol conversion equipment | |
| JP4109735B2 (ja) | パケット変換方法、伝送方法、ｍｐｅｇプロトコルとｉｐの変換方法、ｃａｔｖシステム、プロトコル変換方法およびパケット送信方法 | |
| CA2554712C (en) | System and method of supporting transport and playback of signals | |
| EP1965561B1 (en) | System and method for transmitting digital content using cable modem termination system (CMTS) bypass architecture | |
| JP4954471B2 (ja) | ネットワークに接続された装置から別の装置へのデータの配信を制御する方法 | |
| US6400720B1 (en) | Method for transporting variable length and fixed length packets in a standard digital transmission frame | |
| EP1623303B1 (en) | Information frame modifier | |
| US20030172386A1 (en) | System and method for sending and receiving information of digital cable broadcasting | |
| JP2003037623A (ja) | Ｍｐｅｇネットワーク上におけるダイレクトｒｔｐ伝送方法及びシステム | |
| US10887242B2 (en) | Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal | |
| JP2013504912A (ja) | Ｍｐｅｇ−２ｔｓ多重化マルチメディアストリームのエレメンタリパケットの選択による、ｍｐｅｇ−２ｔｓ多重化マルチメディアストリームの配信 | |
| KR100631758B1 (ko) | 멀티 스트리밍 포맷을 지원하는 네트워크 ｉ/ｆ 카드 및그 방법 | |
| JP2002152301A (ja) | データ通信システム、データ受信装置、データ通信方法、並びにプログラム記憶媒体 | |
| KR101112454B1 (ko) | 무선 네트워크를 통한 디지털 멀티미디어 제어장치 | |
| JP4154753B2 (ja) | データ受信装置及び方法 | |
| US20090158376A1 (en) | Method and apparatus of building ip-based video service system in hybrid fiber coax network | |
| Ewald-Arostegui et al. | A framework for an IP-based DVB transmission network | |
| US7949052B1 (en) | Method and apparatus to deliver a DVB-ASI compressed video transport stream | |
| EP4123967A1 (en) | Method and apparatus for processing multicast signal | |
| CA2371624A1 (en) | Method and apparatus for protocol conversion | |
| CA2621090C (en) | System and method for transmitting digital content using cable modem termination system (cmts) bypass architecture | |
| JP2006014153A (ja) | パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法 | |
| KR100442473B1 (ko) | 네트워크를 통한 디지털 동영상제어장치 | |
| CN117643060A (zh) | 处理多播信号的方法和设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040928 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041129 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050705 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060427 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080227 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080227 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080407 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110411 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110411 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120411 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120411 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130411 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130411 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140411 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |