JP2003199075A - データ伝送方法、データ伝送装置及びデータ受信装置 - Google Patents
データ伝送方法、データ伝送装置及びデータ受信装置Info
- Publication number
- JP2003199075A JP2003199075A JP2001396387A JP2001396387A JP2003199075A JP 2003199075 A JP2003199075 A JP 2003199075A JP 2001396387 A JP2001396387 A JP 2001396387A JP 2001396387 A JP2001396387 A JP 2001396387A JP 2003199075 A JP2003199075 A JP 2003199075A
- Authority
- JP
- Japan
- Prior art keywords
- data
- application
- packet
- transmission
- packets
- 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.)
- Pending
Links
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】
【課題】 あらかじめ送信側と交渉を行わなくても受信
端末で伝送方法を検出可能とする。 【解決手段】 伝送パケット中にマトリックス構造を構
成して伝送されるか否かを示すマトリックス情報、固定
長であるか可変長であるかを示すパケット長情報、アプ
リケーションデータの境界とアプリケーションパケット
の境界が同期するか否かを示す同期情報を格納して伝送
する。
端末で伝送方法を検出可能とする。 【解決手段】 伝送パケット中にマトリックス構造を構
成して伝送されるか否かを示すマトリックス情報、固定
長であるか可変長であるかを示すパケット長情報、アプ
リケーションデータの境界とアプリケーションパケット
の境界が同期するか否かを示す同期情報を格納して伝送
する。
Description
【０００１】
【発明の属する技術分野】本発明は映像データや音声デ
ータ等のアプリケーションデータを複数のパケット（ア
プリケーションパケット）に分割して、さらに各アプリ
ケーションパケットにヘッダを付加して伝送パケットを
構成して伝送するデータ伝送方法、データ伝送装置、デ
ータ受信装置に関する。
ータ等のアプリケーションデータを複数のパケット（ア
プリケーションパケット）に分割して、さらに各アプリ
ケーションパケットにヘッダを付加して伝送パケットを
構成して伝送するデータ伝送方法、データ伝送装置、デ
ータ受信装置に関する。
【０００２】
【従来の技術】インターネットに代表されるネットワー
クの爆発的な発展に伴い、ネットワークの伝送容量が格
段に増加し、映像データ等の情報量の多いデータを伝送
することが可能となりつつある。
クの爆発的な発展に伴い、ネットワークの伝送容量が格
段に増加し、映像データ等の情報量の多いデータを伝送
することが可能となりつつある。
【０００３】一般的に、映像伝送にはストリーミング伝
送と呼ばれる、送信側から受信側への一方向のデータの
流れで伝送を行うコネクションレスの伝送方法が用いら
れる。一般的に、インターネット上でのストリーミング
伝送にはＵＤＰ／ＩＰのプロトコルが使用される。
送と呼ばれる、送信側から受信側への一方向のデータの
流れで伝送を行うコネクションレスの伝送方法が用いら
れる。一般的に、インターネット上でのストリーミング
伝送にはＵＤＰ／ＩＰのプロトコルが使用される。
【０００４】図６はストリーミング伝送の模式図であ
る。６００は映像サーバであり映像データを送信する。
６０１はネットワークの模式図であり、送信された映像
データを映像端末まで伝送する。６０２、６０３および
６０４は映像端末であり、ネットワークを介して伝送さ
れた映像データを受信して表示する。図６は映像端末が
３台の場合を示しており、ネットワーク内で映像データ
をコピーして複数台（図６では３台）に分配する、いわ
ゆるマルチキャストの場合を示している。
る。６００は映像サーバであり映像データを送信する。
６０１はネットワークの模式図であり、送信された映像
データを映像端末まで伝送する。６０２、６０３および
６０４は映像端末であり、ネットワークを介して伝送さ
れた映像データを受信して表示する。図６は映像端末が
３台の場合を示しており、ネットワーク内で映像データ
をコピーして複数台（図６では３台）に分配する、いわ
ゆるマルチキャストの場合を示している。
【０００５】図６の矢印に示すように、映像データは映
像サーバ６０１から３台の映像端末に一方向に流れてお
り、コントロール信号以外は逆方向に伝送されない。
像サーバ６０１から３台の映像端末に一方向に流れてお
り、コントロール信号以外は逆方向に伝送されない。
【０００６】コントロール信号の代表例としては映像端
末がマルチキャストに参加するとき、つまり映像端末６
０２を例にとると、映像端末がネットワーク６０１に対
して映像データを配信されるグループに参加（join）す
るためのコマンドを発行する。
末がマルチキャストに参加するとき、つまり映像端末６
０２を例にとると、映像端末がネットワーク６０１に対
して映像データを配信されるグループに参加（join）す
るためのコマンドを発行する。
【０００７】この時、映像端末６０２は映像サーバ６０
０と交渉しないので、どのような伝送形式で映像データ
が配信されているかという情報は映像端末６０２には知
らされない。したがって、受信される伝送パケットの情
報だけから伝送方法を判定して映像を再構成しなければ
ならない。
０と交渉しないので、どのような伝送形式で映像データ
が配信されているかという情報は映像端末６０２には知
らされない。したがって、受信される伝送パケットの情
報だけから伝送方法を判定して映像を再構成しなければ
ならない。
【０００８】図６ではマルチキャストの例を示したが、
例えば１対１の伝送において映像端末６０２が映像サー
バ６００に直接映像データ配信を依頼する場合でも伝送
形式を通知されない場合が多い。この場合も上記と同様
に、受信される伝送パケットの情報だけから伝送方法を
判定して映像を再構成しなければならない。
例えば１対１の伝送において映像端末６０２が映像サー
バ６００に直接映像データ配信を依頼する場合でも伝送
形式を通知されない場合が多い。この場合も上記と同様
に、受信される伝送パケットの情報だけから伝送方法を
判定して映像を再構成しなければならない。
【０００９】ネットワークで伝送される映像データの例
としては、ＨＤディジタルＶＣＲ協議会で合意された民
生用ディジタルＶＴＲの規格である「ＤＶ規格」に基づ
くものがある。
としては、ＨＤディジタルＶＣＲ協議会で合意された民
生用ディジタルＶＴＲの規格である「ＤＶ規格」に基づ
くものがある。
【００１０】ＤＶ規格については、「Specifications o
f Consumer-Use Digital VCRs using 6.3mm magnetic t
ape」December,1994 HD DIGITAL VCR CONFERENCE、に記
載されており、またそのディジタルインターフェースに
ついては、「Specificationsof Digital Interface for
Consumer Electric Audio/Video Equipment」Decembe
r,1995 HD DIGITAL VCR CONFERENCE、に記載されてい
る。このディジタルインターフェースは８０バイトのＤ
ＩＦブロックと呼ばれるブロックを基準とするものであ
り、このディジタルインターフェース形式によるデータ
を伝送に使用する。
f Consumer-Use Digital VCRs using 6.3mm magnetic t
ape」December,1994 HD DIGITAL VCR CONFERENCE、に記
載されており、またそのディジタルインターフェースに
ついては、「Specificationsof Digital Interface for
Consumer Electric Audio/Video Equipment」Decembe
r,1995 HD DIGITAL VCR CONFERENCE、に記載されてい
る。このディジタルインターフェースは８０バイトのＤ
ＩＦブロックと呼ばれるブロックを基準とするものであ
り、このディジタルインターフェース形式によるデータ
を伝送に使用する。
【００１１】本願ではＤＶ規格に基づく映像（以下Ｄ
Ｖ）を伝送する場合を例として説明を行う。なお、ＤＶ
規格には映像の他に音声および付加データも重畳されて
いるが本願の説明においては映像データとして説明す
る。ＤＶではビデオフレーム内で映像圧縮が行われ、１
フレームのデータレートは１２０，０００バイトとな
る。
Ｖ）を伝送する場合を例として説明を行う。なお、ＤＶ
規格には映像の他に音声および付加データも重畳されて
いるが本願の説明においては映像データとして説明す
る。ＤＶではビデオフレーム内で映像圧縮が行われ、１
フレームのデータレートは１２０，０００バイトとな
る。
【００１２】ＤＶのアプリケーションデータ（以下、Ｄ
Ｖデータ）をインタネットプロトコルのネットワークで
伝送する方式としては、The Internet Engineering Tas
k Force (IETF)に提案されている、INTERNET-DRAFT dra
ft-ietf-avt-dv-video-04.txt "RTP Payload Format fo
r DV Format for DV Format Video" August 7, 2001
（以下、DV over RTP）がある。
Ｖデータ）をインタネットプロトコルのネットワークで
伝送する方式としては、The Internet Engineering Tas
k Force (IETF)に提案されている、INTERNET-DRAFT dra
ft-ietf-avt-dv-video-04.txt "RTP Payload Format fo
r DV Format for DV Format Video" August 7, 2001
（以下、DV over RTP）がある。
【００１３】DV over RTPは映像データ等のリアルタイ
ム性を必要とするデータを伝送するReal Time Protocol
(RTP)上で伝送するものである。RTPはIETFのRFC1889 "R
TP :A Transport Protocol for Real-Time Application
s" に規定されている。
ム性を必要とするデータを伝送するReal Time Protocol
(RTP)上で伝送するものである。RTPはIETFのRFC1889 "R
TP :A Transport Protocol for Real-Time Application
s" に規定されている。
【００１４】図８はDV over RTPの伝送方法で使用され
る伝送パケットの模式図である。本願発明の説明に関連
する部分は、シーケンス番号８００、タイムスタンプ８
０１およびペイロード８０２である。
る伝送パケットの模式図である。本願発明の説明に関連
する部分は、シーケンス番号８００、タイムスタンプ８
０１およびペイロード８０２である。
【００１５】タイムスタンプ８０１は90kHzのタイムス
タンプを格納する領域であり、同一ビデオフレームでは
同じ値となる、シーケンス番号８００はビデオフレーム
内でのパケットの順序を格納する。ペイロード８０２
は、ＤＶデータは８０バイト単位で扱われるので８０バ
イトの倍数、例えば１２００バイトとなる。DV over RT
Pにより伝送されるパケットには伝送形式に関する情報
は格納されない。
タンプを格納する領域であり、同一ビデオフレームでは
同じ値となる、シーケンス番号８００はビデオフレーム
内でのパケットの順序を格納する。ペイロード８０２
は、ＤＶデータは８０バイト単位で扱われるので８０バ
イトの倍数、例えば１２００バイトとなる。DV over RT
Pにより伝送されるパケットには伝送形式に関する情報
は格納されない。
【００１６】図７は映像端末の一般的な構成図である。
図７ではイーサネット（登録商標）を用いる場合を例と
している。イーサネットはインターネットプロトコル
（ＩＰ）を伝送するためのデータリンク層のプロトコル
として頻繁に用いられるプロトコルである。
図７ではイーサネット（登録商標）を用いる場合を例と
している。イーサネットはインターネットプロトコル
（ＩＰ）を伝送するためのデータリンク層のプロトコル
として頻繁に用いられるプロトコルである。
【００１７】図７において、７００はイーサネット・ネ
ットワークインタフェースカード、７０１はＰＣＩバ
ス、７０２はメモリ、７０３はＣＰＵ、７０４は映像処
理カードである。
ットワークインタフェースカード、７０１はＰＣＩバ
ス、７０２はメモリ、７０３はＣＰＵ、７０４は映像処
理カードである。
【００１８】イーサネット経由で伝送されたＤＶデータ
の伝送パケットはイーサネットネットワークインタフェ
ースカード７００で受信されＰＣＩバス７０１経由でメ
モリ７０２に格納される。メモリ７０２内に格納された
伝送パケットは、ＣＰＵ７０３での処理を行った後にＰ
ＣＩバス７０１経由で映像処理カード７０４に転送さ
れ、圧縮映像の伸張の処理等を行われて映像出力され映
像表示される。
の伝送パケットはイーサネットネットワークインタフェ
ースカード７００で受信されＰＣＩバス７０１経由でメ
モリ７０２に格納される。メモリ７０２内に格納された
伝送パケットは、ＣＰＵ７０３での処理を行った後にＰ
ＣＩバス７０１経由で映像処理カード７０４に転送さ
れ、圧縮映像の伸張の処理等を行われて映像出力され映
像表示される。
【００１９】
【発明が解決しようとする課題】しかしながら上記従来
の伝送方法では以下のような問題点を有していた。
の伝送方法では以下のような問題点を有していた。
【００２０】伝送開始時に伝送方法が映像端末に通知さ
れない場合、伝送パケット中に伝送方法を示す情報が格
納されていないので、受信方法の確定に時間がかかると
共に、受信端末のリソースを有効に使用できないという
問題点があった。以下、この問題点を具体的に説明す
る。
れない場合、伝送パケット中に伝送方法を示す情報が格
納されていないので、受信方法の確定に時間がかかると
共に、受信端末のリソースを有効に使用できないという
問題点があった。以下、この問題点を具体的に説明す
る。
【００２１】例えば、受信する全ての伝送パケットが全
て同じ大きさ、すなわち固定長である場合は、受信端末
は次に受信する伝送パケットのためにメモリ７０２上に
固定長の伝送パケット格納領域を確保して受信を待てば
よいが、上記従来の伝送方法では伝送パケット中に伝送
方法を示す情報が入っておらず、ストリーミング伝送時
に固定長で伝送されるかどうかは判定できないので、受
信可能性のある最大長のメモリ領域を常に確保しておか
なければならず、受信端末のリソースを無駄に使用する
ため、常時大規模なメモリを伝送用に確保しなければな
らないという問題点があった。
て同じ大きさ、すなわち固定長である場合は、受信端末
は次に受信する伝送パケットのためにメモリ７０２上に
固定長の伝送パケット格納領域を確保して受信を待てば
よいが、上記従来の伝送方法では伝送パケット中に伝送
方法を示す情報が入っておらず、ストリーミング伝送時
に固定長で伝送されるかどうかは判定できないので、受
信可能性のある最大長のメモリ領域を常に確保しておか
なければならず、受信端末のリソースを無駄に使用する
ため、常時大規模なメモリを伝送用に確保しなければな
らないという問題点があった。
【００２２】例えばイーサネットを使用する場合は、ペ
イロードの最大長は１５００バイトであるが、実際の伝
送パケットが１２００バイトであった場合は、一パケッ
ト当たり３００バイトの無駄なメモリ領域を確保するこ
とになる。通常メモリ７０２には複数個の伝送パケット
を格納するので無駄に確保するメモリ領域はかなり大き
くなる。また、伝送目的のみに大きなメモリ領域を確保
すると、他の処理用に割り当てているメモリ領域が小さ
くなり、他の処理が遅くなるあるいは他の処理が全くで
きなくなるなどの問題点があった。
イロードの最大長は１５００バイトであるが、実際の伝
送パケットが１２００バイトであった場合は、一パケッ
ト当たり３００バイトの無駄なメモリ領域を確保するこ
とになる。通常メモリ７０２には複数個の伝送パケット
を格納するので無駄に確保するメモリ領域はかなり大き
くなる。また、伝送目的のみに大きなメモリ領域を確保
すると、他の処理用に割り当てているメモリ領域が小さ
くなり、他の処理が遅くなるあるいは他の処理が全くで
きなくなるなどの問題点があった。
【００２３】逆に、固定長であると仮定して受信を行
い、実際に受信するパケットより小さい領域しかメモリ
を確保しなかった場合は、確保した領域を越える長さの
伝送パケットを受信した場合に、当該パケットを廃棄せ
ざるを得ず、映像が破綻して品質が悪くなるという問題
点を有していた。
い、実際に受信するパケットより小さい領域しかメモリ
を確保しなかった場合は、確保した領域を越える長さの
伝送パケットを受信した場合に、当該パケットを廃棄せ
ざるを得ず、映像が破綻して品質が悪くなるという問題
点を有していた。
【００２４】これらの問題はマトリックス構造でアプリ
ケーションデータを伝送する場合にも同じ問題点が生じ
る。ここでマトリックス構造とは、誤り訂正や誤り分散
を行うために、行、列の概念的な二次元構造を生成して
伝送する方式を意味する。
ケーションデータを伝送する場合にも同じ問題点が生じ
る。ここでマトリックス構造とは、誤り訂正や誤り分散
を行うために、行、列の概念的な二次元構造を生成して
伝送する方式を意味する。
【００２５】上記問題はストリーミング伝送時に伝送パ
ケットに伝送形式の情報が格納されていないために、受
信端末のリソースが適切に確保できないために発生する
問題である。
ケットに伝送形式の情報が格納されていないために、受
信端末のリソースが適切に確保できないために発生する
問題である。
【００２６】特に、図７に示したパソコン（以下、Ｐ
Ｃ）を基本としたシステムで受信端末を構築する場合
は、搭載メモリ等のリソースには限りがあり、リソース
を有効に使用しなければならないので上記問題点は重大
である。
Ｃ）を基本としたシステムで受信端末を構築する場合
は、搭載メモリ等のリソースには限りがあり、リソース
を有効に使用しなければならないので上記問題点は重大
である。
【００２７】また、上記問題点とは別に、以下のような
問題点も有していた。
問題点も有していた。
【００２８】映像データ伝送の場合は、例えばアプリケ
ーションデータの境界としてビデオフレームの境界を挿
入して伝送し、受信端末ではビデオフレームの境界を検
出して映像圧縮の伸張処理を行う。ＤＶデータの場合は
圧縮された映像データのビデオフレーム先頭には８０バ
イトのヘッダブロックがある。
ーションデータの境界としてビデオフレームの境界を挿
入して伝送し、受信端末ではビデオフレームの境界を検
出して映像圧縮の伸張処理を行う。ＤＶデータの場合は
圧縮された映像データのビデオフレーム先頭には８０バ
イトのヘッダブロックがある。
【００２９】受信端末では映像処理カード７０４での圧
縮復号化のためにまずビデオフレームの境界（先頭）を
検出しなければならない。この時、伝送パケットとＤＶ
データのフレーム境界が同期していれば各伝送パケット
の先頭のみ検査すればよく処理が簡易になる。しかしな
がら、伝送パケットがＤＶデータ（アプリケーションデ
ータ）と同期しているかどうかわからない場合は、常に
全データを検査しなければならない。ＤＶデータと伝送
パケットが同期していない場合に、各伝送パケットの先
頭しか検出しなければ、ビデオフレーム境界が検出され
ず、圧縮された映像の伸張処理が正常に行われないので
映像が破綻し、品質が劣化する。
縮復号化のためにまずビデオフレームの境界（先頭）を
検出しなければならない。この時、伝送パケットとＤＶ
データのフレーム境界が同期していれば各伝送パケット
の先頭のみ検査すればよく処理が簡易になる。しかしな
がら、伝送パケットがＤＶデータ（アプリケーションデ
ータ）と同期しているかどうかわからない場合は、常に
全データを検査しなければならない。ＤＶデータと伝送
パケットが同期していない場合に、各伝送パケットの先
頭しか検出しなければ、ビデオフレーム境界が検出され
ず、圧縮された映像の伸張処理が正常に行われないので
映像が破綻し、品質が劣化する。
【００３０】つまり、従来の伝送方法ではＤＶデータと
伝送パケットと同期であるか非同期であるかの判断が、
伝送パケットからでは判断できないという問題点を有し
ていた。
伝送パケットと同期であるか非同期であるかの判断が、
伝送パケットからでは判断できないという問題点を有し
ていた。
【００３１】
【課題を解決するための手段】上記課題を解決するため
に、本願第１の発明は、アプリケーションデータを複数
のアプリケーションパケットに分割し、前記アプリケー
ションパケットの各々にヘッダを付加して伝送パケット
を構成して伝送するデータ伝送方法、伝送装置、受信装
置であって、前記ヘッダ中に前記伝送パケットがマトリ
ックス構造を構成して伝送されるか否かを示すマトリッ
クス情報を有することを特徴とする。
に、本願第１の発明は、アプリケーションデータを複数
のアプリケーションパケットに分割し、前記アプリケー
ションパケットの各々にヘッダを付加して伝送パケット
を構成して伝送するデータ伝送方法、伝送装置、受信装
置であって、前記ヘッダ中に前記伝送パケットがマトリ
ックス構造を構成して伝送されるか否かを示すマトリッ
クス情報を有することを特徴とする。
【００３２】また、本願第２の発明は、アプリケーショ
ンデータを複数のアプリケーションパケットに分割し、
前記アプリケーションパケットの各々にヘッダを付加し
て伝送パケットを構成して伝送するデータ伝送方法、伝
送装置、受信装置であって、前記ヘッダ中に前記伝送パ
ケットが固定長であるか可変長であるかを示すパケット
長情報を有することを特徴とする。
ンデータを複数のアプリケーションパケットに分割し、
前記アプリケーションパケットの各々にヘッダを付加し
て伝送パケットを構成して伝送するデータ伝送方法、伝
送装置、受信装置であって、前記ヘッダ中に前記伝送パ
ケットが固定長であるか可変長であるかを示すパケット
長情報を有することを特徴とする。
【００３３】また、本願第３の発明は、アプリケーショ
ンデータを複数のアプリケーションパケットに分割し、
前記アプリケーションパケットの各々にヘッダを付加し
て伝送パケットを構成して伝送するデータ伝送方法、伝
送装置、受信装置であって、前記ヘッダ中に前記アプリ
ケーションデータの境界と前記アプリケーションパケッ
トの境界が同期するか否かを示す同期情報を有すること
を特徴とする。
ンデータを複数のアプリケーションパケットに分割し、
前記アプリケーションパケットの各々にヘッダを付加し
て伝送パケットを構成して伝送するデータ伝送方法、伝
送装置、受信装置であって、前記ヘッダ中に前記アプリ
ケーションデータの境界と前記アプリケーションパケッ
トの境界が同期するか否かを示す同期情報を有すること
を特徴とする。
【００３４】さらに、前記アプリケーションデータの境
界はビデオフレームまたはビデオフィールドまたはビデ
オラインの境界であることを特徴とする。
界はビデオフレームまたはビデオフィールドまたはビデ
オラインの境界であることを特徴とする。
【００３５】
【発明の実施の形態】図１は本願発明に係る伝送パケッ
トを示す図である。図１において、１００は伝送パケッ
ト、１０１は伝送パケット中の伝送モードを格納するオ
クテット（８ビット長）である。１０２は伝送モードの
オクテット（８ビット長）の内訳を示す。１０３はマト
リックス情報であり、マトリックス構造で伝送されるか
否かを示す。１０４はパケット長情報であり、伝送パケ
ットが固定長で伝送されるかあるいは可変長で伝送され
るかを示す。さらに１０５は同期情報であり、アプリケ
ーションパケットの境界とアプリケーションデータの境
界が同期するかあるいは同期しないか（非同期）を示
す。１０６は予約領域であり、将来の拡張の為に予約さ
れている。なお、タイムスタンプは当該フレームのタイ
ムスタンプを示し、同一ビデオフレームでは同一の値を
取り、シーケンス番号はビデオフレーム内での伝送パケ
ットの順序を示す。
トを示す図である。図１において、１００は伝送パケッ
ト、１０１は伝送パケット中の伝送モードを格納するオ
クテット（８ビット長）である。１０２は伝送モードの
オクテット（８ビット長）の内訳を示す。１０３はマト
リックス情報であり、マトリックス構造で伝送されるか
否かを示す。１０４はパケット長情報であり、伝送パケ
ットが固定長で伝送されるかあるいは可変長で伝送され
るかを示す。さらに１０５は同期情報であり、アプリケ
ーションパケットの境界とアプリケーションデータの境
界が同期するかあるいは同期しないか（非同期）を示
す。１０６は予約領域であり、将来の拡張の為に予約さ
れている。なお、タイムスタンプは当該フレームのタイ
ムスタンプを示し、同一ビデオフレームでは同一の値を
取り、シーケンス番号はビデオフレーム内での伝送パケ
ットの順序を示す。
【００３６】以下の本願の実施の形態ではＤＶデータを
伝送する場合を例とする。ＤＶデータの一フレームのデ
ータ量は１２０，０００バイトである。
伝送する場合を例とする。ＤＶデータの一フレームのデ
ータ量は１２０，０００バイトである。
【００３７】（実施の形態１）本実施の形態では、本願
第１の発明について説明する。本願第１の発明はアプリ
ケーションデータのマトリックス構成での伝送に関す
る。図２に本願第１の発明で生成されるマトリックス構
成を示す。
第１の発明について説明する。本願第１の発明はアプリ
ケーションデータのマトリックス構成での伝送に関す
る。図２に本願第１の発明で生成されるマトリックス構
成を示す。
【００３８】本実施の形態では、一例としてＤＶの１フ
レームの情報を１，２００バイトのアプリケーションパ
ケットに分割して伝送する。したがって、 １２０，０００ ／ １，２００ ＝ １００ １００個のアプリケーションパケットに分割される。本
実施の形態ではこれを更に２つのマトリックスに分け
る。つまり５０個のアプリケーションパケットでマトリ
ックスを構成する。さらに５０個のアプリケーションパ
ケットに対して４個の誤り訂正用のパリティを格納する
パケットを付加したマトリックスを構成する。
レームの情報を１，２００バイトのアプリケーションパ
ケットに分割して伝送する。したがって、 １２０，０００ ／ １，２００ ＝ １００ １００個のアプリケーションパケットに分割される。本
実施の形態ではこれを更に２つのマトリックスに分け
る。つまり５０個のアプリケーションパケットでマトリ
ックスを構成する。さらに５０個のアプリケーションパ
ケットに対して４個の誤り訂正用のパリティを格納する
パケットを付加したマトリックスを構成する。
【００３９】マトリックス伝送時には図１のマトリック
ス情報１０３を“１”とし、マトリックスで伝送しない
場合には“０”としたヘッダを付加した伝送パケットを
構成して伝送する。
ス情報１０３を“１”とし、マトリックスで伝送しない
場合には“０”としたヘッダを付加した伝送パケットを
構成して伝送する。
【００４０】受信端末ではメモリ７０２に格納された受
信伝送パケットからＣＰＵ７０３がマトリックス情報を
検知し、マトリックス構造で伝送される場合には、図２
に示すマトリックスの大きさである。 １２００＊５４＝６４８００ バイト のメモリ領域を確保する。
信伝送パケットからＣＰＵ７０３がマトリックス情報を
検知し、マトリックス構造で伝送される場合には、図２
に示すマトリックスの大きさである。 １２００＊５４＝６４８００ バイト のメモリ領域を確保する。
【００４１】マトリックス構造で伝送されることを検知
し適切なメモリ領域を確保することで、無駄なメモリ領
域を使用せずかつ伝送パケットの廃棄も起こらない。
し適切なメモリ領域を確保することで、無駄なメモリ領
域を使用せずかつ伝送パケットの廃棄も起こらない。
【００４２】次にＣＰＵ７０３は、映像処理カード７０
４にメモリ７０２内の伝送パケットを転送して伝送パケ
ットの廃棄のない高画質な映像通信を可能とする。
４にメモリ７０２内の伝送パケットを転送して伝送パケ
ットの廃棄のない高画質な映像通信を可能とする。
【００４３】マトリックス構造で伝送されない場合は後
述する固定長／可変長の情報を検知することにより、固
定長の場合はその長さのメモリ領域を確保し、可変長の
場合はデータリンク層のデータサイズ（この場合はイー
サネットの１５００バイト）を確保することにより受信
した伝送パケットの廃棄をなくして高品質な伝送を可能
とする。この場合マトリックスによる伝送よりも更に少
ないメモリ領域の使用で処理を行えることはいうまでも
ない。
述する固定長／可変長の情報を検知することにより、固
定長の場合はその長さのメモリ領域を確保し、可変長の
場合はデータリンク層のデータサイズ（この場合はイー
サネットの１５００バイト）を確保することにより受信
した伝送パケットの廃棄をなくして高品質な伝送を可能
とする。この場合マトリックスによる伝送よりも更に少
ないメモリ領域の使用で処理を行えることはいうまでも
ない。
【００４４】即ち、本願第１の発明では伝送パケットに
応じた最適な量のメモリ領域を確保して高品質な映像伝
送が可能となる。
応じた最適な量のメモリ領域を確保して高品質な映像伝
送が可能となる。
【００４５】なお、誤り訂正のパケットは必須のもので
はなく誤り訂正を行わない場合でも本願発明の範囲から
排除するものではない。その場合、本実施の形態の例で
は５０個の伝送パケット分のみメモリ領域を確保すれば
よい。
はなく誤り訂正を行わない場合でも本願発明の範囲から
排除するものではない。その場合、本実施の形態の例で
は５０個の伝送パケット分のみメモリ領域を確保すれば
よい。
【００４６】また、誤り訂正を行う場合、誤り訂正用の
パリティを格納するパケットの数の情報は（本実施の形
態の場合は４）あらかじめアプリケーションデータに固
有とするか、あるいは予約領域１０６にその情報を格納
するなどとすればよい。
パリティを格納するパケットの数の情報は（本実施の形
態の場合は４）あらかじめアプリケーションデータに固
有とするか、あるいは予約領域１０６にその情報を格納
するなどとすればよい。
【００４７】また、本実施の形態では伝送パケット５４
個分のメモリ上の領域を確保したが、映像処理カード側
に十分なメモリが具備されている場合は、メモリを確保
する領域を更に少なくしてもよい、つまり確保されるメ
モリ領域は必ずしもマトリックスの大きさに限るもので
はなく、映像端末のその他の部分の構成により更に小さ
くすることも可能である。この場合でもマトリックス形
式に応じて最適なメモリ領域を確保するという本願第１
の発明の特徴が失われるわけではなく、更に効果が大き
くなる。したがって本願発明の範囲から排除するもので
はない。
個分のメモリ上の領域を確保したが、映像処理カード側
に十分なメモリが具備されている場合は、メモリを確保
する領域を更に少なくしてもよい、つまり確保されるメ
モリ領域は必ずしもマトリックスの大きさに限るもので
はなく、映像端末のその他の部分の構成により更に小さ
くすることも可能である。この場合でもマトリックス形
式に応じて最適なメモリ領域を確保するという本願第１
の発明の特徴が失われるわけではなく、更に効果が大き
くなる。したがって本願発明の範囲から排除するもので
はない。
【００４８】また、本実施の形態では１２００＊５４の
マトリックスを例としたが、その他の大きさでも本願発
明の効果を得ることができ、本願発明の範囲から排除す
るものではない。
マトリックスを例としたが、その他の大きさでも本願発
明の効果を得ることができ、本願発明の範囲から排除す
るものではない。
【００４９】（実施の形態２）本実施の形態では、本願
第２の発明について説明する。本願第２の発明は伝送パ
ケットの固定長伝送、可変長伝送に関する。
第２の発明について説明する。本願第２の発明は伝送パ
ケットの固定長伝送、可変長伝送に関する。
【００５０】図１の１０４は伝送パケットが固定長で伝
送されるか可変長で伝送されるかを示すパケット長情報
であり、このビットが“１”であれば固定長、“０”は
可変長とする。つまりこのビットはアプリケーションデ
ータであるＤＶデータの伝送において、一連の伝送パケ
ットが常に固定長で伝送されるか、可変長で伝送される
かを示す。
送されるか可変長で伝送されるかを示すパケット長情報
であり、このビットが“１”であれば固定長、“０”は
可変長とする。つまりこのビットはアプリケーションデ
ータであるＤＶデータの伝送において、一連の伝送パケ
ットが常に固定長で伝送されるか、可変長で伝送される
かを示す。
【００５１】固定長で伝送される場合は固定長分のメモ
リ領域を確保すればよく、メモリ領域を無駄に使用しな
い。例えば、ＤＶの１フレームの情報を１，２００バイ
トのアプリケーションパケットに分割して伝送する場合
は、一つの伝送パケット当たり、１，２００バイトのア
プリケーションパケット用の領域を確保すればよい。な
お、実際にはヘッダ分も同時に格納するので若干領域は
増える。
リ領域を確保すればよく、メモリ領域を無駄に使用しな
い。例えば、ＤＶの１フレームの情報を１，２００バイ
トのアプリケーションパケットに分割して伝送する場合
は、一つの伝送パケット当たり、１，２００バイトのア
プリケーションパケット用の領域を確保すればよい。な
お、実際にはヘッダ分も同時に格納するので若干領域は
増える。
【００５２】受信された伝送パケットはメモリ７０２に
格納され、ＣＰＵ７０３の処理により、ＰＣＩバス７０
１を経由して映像処理カード７０４に転送され、映像処
理カード７０４で圧縮映像の伸張処理が行われ映像出力
される。
格納され、ＣＰＵ７０３の処理により、ＰＣＩバス７０
１を経由して映像処理カード７０４に転送され、映像処
理カード７０４で圧縮映像の伸張処理が行われ映像出力
される。
【００５３】なお、実際には受信パケットの受信の揺ら
ぎが発生すること、および映像処理カードへの転送のタ
イミングの関係上、メモリ上で廃棄が起こらないように
複数の伝送パケット分はメモリ上に格納領域を確保する
が、伝送パケット長が固定長であるとわかっているので
無駄にはメモリ領域を使用しないという本願発明の特徴
が失われるわけではない。
ぎが発生すること、および映像処理カードへの転送のタ
イミングの関係上、メモリ上で廃棄が起こらないように
複数の伝送パケット分はメモリ上に格納領域を確保する
が、伝送パケット長が固定長であるとわかっているので
無駄にはメモリ領域を使用しないという本願発明の特徴
が失われるわけではない。
【００５４】可変長の場合は、例えばデータリンク層が
イーサネットの場合であればイーサネットのペイロード
の最大長である１５００バイトを確保することにより、
受信パケットのデータを廃棄することがなく高品質な映
像伝送が可能となる。
イーサネットの場合であればイーサネットのペイロード
の最大長である１５００バイトを確保することにより、
受信パケットのデータを廃棄することがなく高品質な映
像伝送が可能となる。
【００５５】以上の説明したように、伝送パケット中に
固定長／可変長の情報を格納することにより、最初に受
信された伝送パケットで固定長であるか可変長であるか
判断可能であり、固定長の場合は最小限のリソース（メ
モリ領域）を使用して高品質なストリーム伝送が可能と
なる。また可変長の場合も伝送パケットの廃棄が生じな
いようにリソースを確保して高品質な映像伝送が可能と
なる。
固定長／可変長の情報を格納することにより、最初に受
信された伝送パケットで固定長であるか可変長であるか
判断可能であり、固定長の場合は最小限のリソース（メ
モリ領域）を使用して高品質なストリーム伝送が可能と
なる。また可変長の場合も伝送パケットの廃棄が生じな
いようにリソースを確保して高品質な映像伝送が可能と
なる。
【００５６】（実施の形態３）本実施の形態では、本願
第３の発明について説明する。本願第３の発明は、アプ
リケーションデータの境界とアプリケーションパケット
の境界が同期するか否かを示す同期情報を伝送パケット
中に格納することにより、受信端末での処理を簡易化
し、さらに高品質な映像伝送を提供する。
第３の発明について説明する。本願第３の発明は、アプ
リケーションデータの境界とアプリケーションパケット
の境界が同期するか否かを示す同期情報を伝送パケット
中に格納することにより、受信端末での処理を簡易化
し、さらに高品質な映像伝送を提供する。
【００５７】図３はＤＶデータとアプリケーションパケ
ットが同期している場合の模式図である。図３にはフレ
ーム先頭を黒塗りで示している。各アプリケーションパ
ケットは１，２００バイト長の固定長である。したがっ
て、 １２０，０００ ／ １，２００ ＝ １００ なので、フレーム先頭は伝送パケット１００個毎に先頭
に現れ、伝送パケットのペイロードであるアプリケーシ
ョンパケットと同期している。この場合、アプリケーシ
ョンパケットの先頭のみ検査すればフレーム先頭を検出
可能となる。
ットが同期している場合の模式図である。図３にはフレ
ーム先頭を黒塗りで示している。各アプリケーションパ
ケットは１，２００バイト長の固定長である。したがっ
て、 １２０，０００ ／ １，２００ ＝ １００ なので、フレーム先頭は伝送パケット１００個毎に先頭
に現れ、伝送パケットのペイロードであるアプリケーシ
ョンパケットと同期している。この場合、アプリケーシ
ョンパケットの先頭のみ検査すればフレーム先頭を検出
可能となる。
【００５８】これに対し、図４はＤＶデータと伝送パケ
ットが同期していない（非同期）場合の模式図である。
伝送パケットは１，１００バイトである。したがって、 １２０，０００ ＝ １，１００ ＊ １０９ ＋ １
００ なので各フレームは１０９個のパケットと１００バイト
で構成される。したがって図４に示すように１００バイ
トずつアプリケーションパケットの先頭からフレーム先
頭がずれるので、この場合アプリケーションパケット全
体にわたってフレーム先頭を検査しなければならない。
ットが同期していない（非同期）場合の模式図である。
伝送パケットは１，１００バイトである。したがって、 １２０，０００ ＝ １，１００ ＊ １０９ ＋ １
００ なので各フレームは１０９個のパケットと１００バイト
で構成される。したがって図４に示すように１００バイ
トずつアプリケーションパケットの先頭からフレーム先
頭がずれるので、この場合アプリケーションパケット全
体にわたってフレーム先頭を検査しなければならない。
【００５９】本願第３の発明では伝送パケット中に同期
であるか非同期であるかの情報が格納されているので、
メモリ７０２に格納された伝送パケットをＣＰＵ７０３
で検査することにより、同期あるいは非同期が確定し、
映像処理カード７０４でのビデオフレーム先頭の検査方
法を決定することができる。
であるか非同期であるかの情報が格納されているので、
メモリ７０２に格納された伝送パケットをＣＰＵ７０３
で検査することにより、同期あるいは非同期が確定し、
映像処理カード７０４でのビデオフレーム先頭の検査方
法を決定することができる。
【００６０】同期で伝送される場合であれば、伝送パケ
ット中のペイロードであるアプリケーションパケットの
先頭のみを検査すればビデオフレーム先頭を検出するこ
とが可能であり、簡易な方法で高品質な映像伝送が可能
となる。簡易な処理を行う場合は処理回路の消費電力が
小さくなるという効果も同時に有する。
ット中のペイロードであるアプリケーションパケットの
先頭のみを検査すればビデオフレーム先頭を検出するこ
とが可能であり、簡易な方法で高品質な映像伝送が可能
となる。簡易な処理を行う場合は処理回路の消費電力が
小さくなるという効果も同時に有する。
【００６１】非同期の場合にも映像処理カード７０４に
対してアプリケーションパケットを全部検査することで
ビデオフレーム境界を検出可能となるので高品質な映像
伝送が可能となる。
対してアプリケーションパケットを全部検査することで
ビデオフレーム境界を検出可能となるので高品質な映像
伝送が可能となる。
【００６２】つまり、同期あるいは非同期を最初の伝送
パケット到着時に瞬時に判定し、適切な処理を行うこと
により、高品質な映像伝送を可能とし、同期の場合は簡
易な処理方法で消費電力が少ないという効果も有する。
パケット到着時に瞬時に判定し、適切な処理を行うこと
により、高品質な映像伝送を可能とし、同期の場合は簡
易な処理方法で消費電力が少ないという効果も有する。
【００６３】なお、本実施の形態ではビデオフレーム当
たりのデータ量が一定であるＤＶデータの場合を例とし
たが、例えばＭＰＥＧ１、ＭＰＥＧ２あるいはＭＰＥＧ
４のような、ＧＯＰ(Group of Picture)あたりのデータ
量が一定でない場合でもアプリケーションデータの境界
がアプリケーションパケットの境界と一致する場合は同
期として処理を行う。この場合について図面を用いて説
明する。
たりのデータ量が一定であるＤＶデータの場合を例とし
たが、例えばＭＰＥＧ１、ＭＰＥＧ２あるいはＭＰＥＧ
４のような、ＧＯＰ(Group of Picture)あたりのデータ
量が一定でない場合でもアプリケーションデータの境界
がアプリケーションパケットの境界と一致する場合は同
期として処理を行う。この場合について図面を用いて説
明する。
【００６４】図５はＭＰＥＧのアプリケーションデータ
の模式図である。図５の黒塗りの部分はシーケンスヘッ
ダである。ＧＯＰ毎にデータ量が異なり、伝送パケット
長も固定長ではないがＧＯＰの先頭ではアプリケーショ
ンパケットの先頭とシーケンスヘッダが一致しているの
で、この場合は同期とすればよい。
の模式図である。図５の黒塗りの部分はシーケンスヘッ
ダである。ＧＯＰ毎にデータ量が異なり、伝送パケット
長も固定長ではないがＧＯＰの先頭ではアプリケーショ
ンパケットの先頭とシーケンスヘッダが一致しているの
で、この場合は同期とすればよい。
【００６５】なお、同期とする対象はシーケンスヘッダ
だけではなく、ＧＯＰヘッダ、ピクチャヘッダあるいは
スライスヘッダ等、アプリケーションデータの境界を表
すものであればどのようなものでもよい。
だけではなく、ＧＯＰヘッダ、ピクチャヘッダあるいは
スライスヘッダ等、アプリケーションデータの境界を表
すものであればどのようなものでもよい。
【００６６】また、ＭＰＥＧ以外にも非圧縮映像や音声
等のアプリケーションデータでも本願発明の範囲から排
除するものではない。
等のアプリケーションデータでも本願発明の範囲から排
除するものではない。
【００６７】なお、本実施の形態では伝送パケット（ア
プリケーションパケット）単位でフレーム先頭が同期す
る場合を例としたが、実施の形態１に示したようにマト
リックスの先頭とフレーム先頭が同期する場合に本願第
３の発明を適応しても効果が得られるので本願発明の範
囲から排除するものではない。その場合、伝送パケット
単位で同期するか、あるいはマトリックス単位で同期す
るかの情報は図１の予約領域を使用するなどとして判定
すればよい。
プリケーションパケット）単位でフレーム先頭が同期す
る場合を例としたが、実施の形態１に示したようにマト
リックスの先頭とフレーム先頭が同期する場合に本願第
３の発明を適応しても効果が得られるので本願発明の範
囲から排除するものではない。その場合、伝送パケット
単位で同期するか、あるいはマトリックス単位で同期す
るかの情報は図１の予約領域を使用するなどとして判定
すればよい。
【００６８】また、本実施の形態ではアプリケーション
データの境界はビデオフレームとしたが、これに限らず
ビデオフレームあるいはビデオ（映像）の走査線（ライ
ン）単位でも本願発明は効果を有し、本願発明の範囲か
ら排除するものではない。
データの境界はビデオフレームとしたが、これに限らず
ビデオフレームあるいはビデオ（映像）の走査線（ライ
ン）単位でも本願発明は効果を有し、本願発明の範囲か
ら排除するものではない。
【００６９】また、本実施の形態ではアプリケーション
データの境界がアプリケーションパケットの先頭にある
場合を例としたが、例えばアプリケーションデータの境
界がアプリケーションパケットの先頭から固定長のオフ
セットがかかった位置に配置される場合等、アプリケー
ションパケットの固定位置にアプリケーションデータの
境界が現れる場合は、アプリケーションデータの境界を
検出する位置は固定されているので本願発明の効果を有
し、本願発明の範囲から排除するものではない。
データの境界がアプリケーションパケットの先頭にある
場合を例としたが、例えばアプリケーションデータの境
界がアプリケーションパケットの先頭から固定長のオフ
セットがかかった位置に配置される場合等、アプリケー
ションパケットの固定位置にアプリケーションデータの
境界が現れる場合は、アプリケーションデータの境界を
検出する位置は固定されているので本願発明の効果を有
し、本願発明の範囲から排除するものではない。
【００７０】なお、本願発明において伝送パケットの長
さの情報については図１に示す伝送パケット中のヘッダ
に追加の情報を格納してもよい。例えば、予約領域１０
６中あるいは予約領域１０６とペイロードの間に追加す
るなどとすればよい。あるいは伝送プロトコルにＵＤＰ
／ＩＰを使用する場合はＵＤＰあるいはＩＰの長さ情報
から伝送パケットの情報を得てもよい。
さの情報については図１に示す伝送パケット中のヘッダ
に追加の情報を格納してもよい。例えば、予約領域１０
６中あるいは予約領域１０６とペイロードの間に追加す
るなどとすればよい。あるいは伝送プロトコルにＵＤＰ
／ＩＰを使用する場合はＵＤＰあるいはＩＰの長さ情報
から伝送パケットの情報を得てもよい。
【００７１】また、本願では実施の形態の例としてＤＶ
データを例としたが、これに限るものではなくその他の
映像データあるいは音声データなどの場合でも本願発明
は効果を有し、本願発明の範囲から排除するものではな
い。
データを例としたが、これに限るものではなくその他の
映像データあるいは音声データなどの場合でも本願発明
は効果を有し、本願発明の範囲から排除するものではな
い。
【００７２】なお、本願発明の伝送装置は伝送パケット
のヘッダは毎伝送パケットで同じであるので、ハードウ
ェアで実現する場合およびソフトウェアで実現する場合
共に生成したヘッダをＲＡＭ等のメモリ装置に記憶して
おき、パケット毎に付加すれば容易に実現可能である。
のヘッダは毎伝送パケットで同じであるので、ハードウ
ェアで実現する場合およびソフトウェアで実現する場合
共に生成したヘッダをＲＡＭ等のメモリ装置に記憶して
おき、パケット毎に付加すれば容易に実現可能である。
【００７３】
【発明の効果】本願第１の発明によれば、マトリックス
構成で伝送するか否かを示すマトリックス情報を全ての
伝送パケットのヘッダに格納して伝送することにより、
最初の伝送パケットの受信時に上記判定が可能であり、
マトリックス構成で伝送する場合には最小限のメモリ領
域で高品質な伝送が可能であり、マトリックス構成で伝
送しない場合には必要なメモリ領域を確保し、アプリケ
ーションデータの破綻がない高品質な伝送が可能とな
る。
構成で伝送するか否かを示すマトリックス情報を全ての
伝送パケットのヘッダに格納して伝送することにより、
最初の伝送パケットの受信時に上記判定が可能であり、
マトリックス構成で伝送する場合には最小限のメモリ領
域で高品質な伝送が可能であり、マトリックス構成で伝
送しない場合には必要なメモリ領域を確保し、アプリケ
ーションデータの破綻がない高品質な伝送が可能とな
る。
【００７４】また、本願第２の発明によれば、伝送パケ
ットが可変長であるか否かを示すパケット長情報を全て
の伝送パケットに格納して伝送することにより、最初の
伝送パケットの受信時に上記判定が可能であり、固定長
の場合、長さフィールドと合わせて、必要なメモリ領域
が確定し、最小限のリソースの使用で高品質な伝送が可
能となる。可変長の場合も、データリンク層の最大長に
合わせてメモリ確保することでアプリケーションデータ
の破綻がない高品質な伝送が可能となる。
ットが可変長であるか否かを示すパケット長情報を全て
の伝送パケットに格納して伝送することにより、最初の
伝送パケットの受信時に上記判定が可能であり、固定長
の場合、長さフィールドと合わせて、必要なメモリ領域
が確定し、最小限のリソースの使用で高品質な伝送が可
能となる。可変長の場合も、データリンク層の最大長に
合わせてメモリ確保することでアプリケーションデータ
の破綻がない高品質な伝送が可能となる。
【００７５】さらに、本願第３の発明によれば、アプリ
ケーションデータの境界とアプリケーションパケットの
境界が同期であるか否かを示す同期情報を全ての伝送パ
ケットに格納して伝送することにより、最初の伝送パケ
ットの受信時に同期か否かの判定が可能であり、同期の
場合、アプリケーションの先頭バイトをアプリケーショ
ンパケットの先頭のみサーチして簡易な構成（処理）で
消費電力も少なく高品質な伝送が可能となる。また、非
同期の場合にも全てのアプリケーションパケットを検査
することによりアプリケーションデータの境界を見逃す
ことなくアプリケーションデータの破綻がない高品質な
伝送が可能となる。
ケーションデータの境界とアプリケーションパケットの
境界が同期であるか否かを示す同期情報を全ての伝送パ
ケットに格納して伝送することにより、最初の伝送パケ
ットの受信時に同期か否かの判定が可能であり、同期の
場合、アプリケーションの先頭バイトをアプリケーショ
ンパケットの先頭のみサーチして簡易な構成（処理）で
消費電力も少なく高品質な伝送が可能となる。また、非
同期の場合にも全てのアプリケーションパケットを検査
することによりアプリケーションデータの境界を見逃す
ことなくアプリケーションデータの破綻がない高品質な
伝送が可能となる。
【００７６】また、本願第１、２、３の発明では、全て
のパケットに上記情報が格納されるので、映像受信端末
が受信した最初のパケットで伝送方法が判明し、受信端
末のリソースをどのくらい確保すればよいかを瞬時に見
積もることが可能であり、最初の受信パケットから映像
の出力を始められるので、受信開始から映像出力までの
時間が短く、ユーザにレスポンスの遅さに起因するスト
レスを感じさせず快適な映像伝送が可能となる。
のパケットに上記情報が格納されるので、映像受信端末
が受信した最初のパケットで伝送方法が判明し、受信端
末のリソースをどのくらい確保すればよいかを瞬時に見
積もることが可能であり、最初の受信パケットから映像
の出力を始められるので、受信開始から映像出力までの
時間が短く、ユーザにレスポンスの遅さに起因するスト
レスを感じさせず快適な映像伝送が可能となる。
【００７７】また、本願第１、２、３の発明では、伝送
パケット中に受信処理に必要が情報か格納されているの
で、あらかじめ取り決めがなくても伝送可能であり、交
渉を行うプロトコル処理が必要なく単純な手順で伝送可
能となる。
パケット中に受信処理に必要が情報か格納されているの
で、あらかじめ取り決めがなくても伝送可能であり、交
渉を行うプロトコル処理が必要なく単純な手順で伝送可
能となる。
【００７８】また、本願第１、２、３の発明では、必要
最小限のリソースしか使用しないので、伝送以外の他の
アプリケーションの処理が遅くなるあるいは処理できな
くなる等の弊害もなく、他のアプリケーションと共存可
能であるという効果も有する。
最小限のリソースしか使用しないので、伝送以外の他の
アプリケーションの処理が遅くなるあるいは処理できな
くなる等の弊害もなく、他のアプリケーションと共存可
能であるという効果も有する。
【００７９】また、本願第１、２、３の発明を用いれ
ば、例えば固定長の伝送パケットしか受信せず、その他
の受信パケットは無視するというような最小限の構成の
安価な受信端末を作ることが可能となる。これはマトリ
ックス、同期の場合、あるいはそれらの組み合わせでも
同様である。
ば、例えば固定長の伝送パケットしか受信せず、その他
の受信パケットは無視するというような最小限の構成の
安価な受信端末を作ることが可能となる。これはマトリ
ックス、同期の場合、あるいはそれらの組み合わせでも
同様である。
【図１】本願第１、２、３の実施形態に係る伝送パケッ
トを示す図
トを示す図
【図２】本願第１の実施形態に係るマトリックス構成図
【図３】ＤＶデータと伝送パケットが同期している場合
の模式図
の模式図
【図４】ＤＶデータと伝送パケットが同期していない
（非同期）場合の模式図
（非同期）場合の模式図
【図５】ＭＰＥＧのアプリケーションデータの模式図
【図６】ストリーミング伝送の模式図
【図７】映像端末の一般的な構成図
【図８】DV over RTPの伝送方法の模式図
【符号の説明】
１００ 伝送パケット
１０１ 伝送パケット中の伝送モードを格納するオクテ
ット １０２ 伝送モードのオクテットの内訳 １０３ マトリックス情報 １０４ パケット長情報 １０５ 同期情報 １０６ 予約領域
ット １０２ 伝送モードのオクテットの内訳 １０３ マトリックス情報 １０４ パケット長情報 １０５ 同期情報 １０６ 予約領域
フロントページの続き
Ｆターム(参考） 5B089 GA21 GB01 JA33 JB04 JB23
KA11
5C064 BA01 BB05 BC10 BC16 BC23
BD02 BD08 BD13
5K030 GA08 GA11 HA08 HB02 HC01
JA05
Claims (14)
- 【請求項１】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送方法であって、前記ヘッダ中に前
記伝送パケットがマトリックス構造を構成して伝送され
るか否かを示すマトリックス情報を付加して伝送するこ
とを特徴とするデータ伝送方法。 - 【請求項２】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送方法であって、前記ヘッダ中に前
記伝送パケットが固定長であるか可変長であるかを示す
パケット長情報を付加して伝送することを特徴とするデ
ータ伝送方法。 - 【請求項３】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送方法であって、前記ヘッダ中に前
記アプリケーションデータの境界と前記アプリケーショ
ンパケットの境界が同期するか否かを示す同期情報を付
加して伝送することを特徴とするデータ伝送方法。 - 【請求項４】 前記アプリケーションデータの境界はビ
デオフレームまたはビデオフィールドまたはビデオライ
ンの境界であることを特徴とする請求項３記載のデータ
伝送方法。 - 【請求項５】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送装置であって、前記ヘッダ中に前
記伝送パケットがマトリックス構造を構成して伝送され
るか否かを示すマトリックス情報を付加して伝送するこ
とを特徴とするデータ伝送装置。 - 【請求項６】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送装置であって、 前記ヘッダ中に前記伝送パケットが固定長であるか可変
長であるかを示すパケット長情報を付加して伝送するこ
とを特徴とするデータ伝送装置。 - 【請求項７】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して伝送パケットを構成し
て伝送するデータ伝送装置であって、 前記ヘッダ中に前記アプリケーションデータの境界と前
記アプリケーションパケットの境界が同期するか否かを
示す同期情報を付加して伝送することを特徴とするデー
タ伝送装置。 - 【請求項８】 前記アプリケーションデータの境界はビ
デオフレームまたはビデオフィールドまたはビデオライ
ンの境界であることを特徴とする請求項７記載のデータ
伝送装置。 - 【請求項９】 アプリケーションデータを複数のアプリ
ケーションパケットに分割し、前記アプリケーションパ
ケットの各々にヘッダを付加して構成された伝送パケッ
トを受信するデータ受信装置であって、 前記伝送パケットを格納する格納手段を備え、 前記ヘッダ中の前記伝送パケットがマトリックス構造を
構成して伝送されるか否かを示すマトリックス情報を基
に前記格納手段の格納サイズを決定することを特徴とす
るデータ受信装置。 - 【請求項１０】 アプリケーションデータを複数のアプ
リケーションパケットに分割し、前記アプリケーション
パケットの各々にヘッダを付加して構成された伝送パケ
ットを受信するデータ受信装置であって、 前記ヘッダ中の前記伝送パケットが固定長であるか可変
長であるかを示すパケット長情報を基に前記格納手段の
格納サイズを決定することを特徴とするデータ受信装
置。 - 【請求項１１】 アプリケーションデータを複数のアプ
リケーションパケットに分割し、前記アプリケーション
パケットの各々にヘッダを付加して構成された伝送パケ
ットを受信するデータ受信装置であって、 前記ヘッダ中の前記アプリケーションデータの境界と前
記アプリケーションパケットの境界が同期するか否かを
示す同期情報を基に、フレーム先頭の検出方法を決定す
ることを特徴とするデータ受信装置。 - 【請求項１２】 フレーム先頭の検出方法は、同期情報
が同期を示す場合には、アプリケーションパケットの先
頭位置からの所定量のみ検査してフレーム先頭を検出す
ることを特徴とする請求項１１に記載のデータ受信装
置。 - 【請求項１３】 フレーム先頭の検出方法は、同期情報
が同期を示す場合には、アプリケーションパケットの先
頭位置に所定オフセットを加えた位置からの所定量のみ
検査してフレーム先頭を検出することを特徴とする請求
項１１に記載のデータ受信装置。 - 【請求項１４】 前記アプリケーションデータの境界は
ビデオフレームまたはビデオフィールドまたはビデオラ
インの境界であることを特徴とする請求項１１から１３
のいずれかに記載のデータ受信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001396387A JP2003199075A (ja) | 2001-12-27 | 2001-12-27 | データ伝送方法、データ伝送装置及びデータ受信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001396387A JP2003199075A (ja) | 2001-12-27 | 2001-12-27 | データ伝送方法、データ伝送装置及びデータ受信装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003199075A true JP2003199075A (ja) | 2003-07-11 |
Family
ID=27602498
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001396387A Pending JP2003199075A (ja) | 2001-12-27 | 2001-12-27 | データ伝送方法、データ伝送装置及びデータ受信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003199075A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100959225B1 (ko) | 2007-03-07 | 2010-05-19 | 캐논 가부시끼가이샤 | 통신 시스템, 통신 장치, 및 그 제어 방법 |
| WO2014057610A1 (ja) * | 2012-10-09 | 2014-04-17 | 日本電気株式会社 | 通信装置 |
| JP2014528682A (ja) * | 2011-10-13 | 2014-10-27 | サムスン エレクトロニクス カンパニー リミテッド | 移動通信システムにおける順方向誤り訂正パケットを送受信する装置及び方法 |
| JP2014532371A (ja) * | 2011-10-13 | 2014-12-04 | サムスン エレクトロニクス カンパニー リミテッド | データ通信システムにおける符号化装置及び方法 |
-
2001
- 2001-12-27 JP JP2001396387A patent/JP2003199075A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100959225B1 (ko) | 2007-03-07 | 2010-05-19 | 캐논 가부시끼가이샤 | 통신 시스템, 통신 장치, 및 그 제어 방법 |
| JP2014528682A (ja) * | 2011-10-13 | 2014-10-27 | サムスン エレクトロニクス カンパニー リミテッド | 移動通信システムにおける順方向誤り訂正パケットを送受信する装置及び方法 |
| JP2014532371A (ja) * | 2011-10-13 | 2014-12-04 | サムスン エレクトロニクス カンパニー リミテッド | データ通信システムにおける符号化装置及び方法 |
| WO2014057610A1 (ja) * | 2012-10-09 | 2014-04-17 | 日本電気株式会社 | 通信装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8345668B2 (en) | Video delivering system, video delivering device, and synchronization correcting device | |
| US9641588B2 (en) | Packets recovery system and method | |
| EP2062399B1 (en) | Method and apparatus for transmitting transport stream packets | |
| JPH06237451A (ja) | 動画通信方式および端末装置 | |
| US9577682B2 (en) | Adaptive forward error correction (FEC) system and method | |
| EP0828394B1 (en) | A device and method for converting data transfer rate in communication of digital audio/video data | |
| CA2522877C (en) | Performing compression of user datagram protocol packets | |
| US7995590B2 (en) | Method and system for communicating H.263 macroblock boundaries using H.221 BAS for RFC2190-compliant fragmentation | |
| US7065087B2 (en) | Performing compression of user datagram protocol packets | |
| JP2003199075A (ja) | データ伝送方法、データ伝送装置及びデータ受信装置 | |
| US8218548B2 (en) | Information processing apparatus, method, and program | |
| JP2002152301A (ja) | データ通信システム、データ受信装置、データ通信方法、並びにプログラム記憶媒体 | |
| JP2002281077A (ja) | 信号受信装置及び信号受信方法 | |
| JP2008245061A (ja) | Ｉｐストリーム伝送におけるｐｃｒ再生方式 | |
| JP3419607B2 (ja) | クロック再生装置 | |
| JP4491290B2 (ja) | パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法 | |
| WO2001033809A1 (fr) | Appareil et procede de communication | |
| KR100962083B1 (ko) | 제 1 데이터 스트림을 제 2 데이터 스트림으로 변환하기 위한 방법 및 시스템 | |
| JP3827297B2 (ja) | 送信装置、受信装置、ネットワーク、送信方法、及び受信方法 | |
| JP3801043B2 (ja) | データ受信装置及び方法 | |
| JP5159973B1 (ja) | 伝送パケットの配信方法 | |
| KR0138123B1 (ko) | 엠피이지-2(mpeg-2) 시스템에서 타임 스템프를 코팅하는 장치 | |
| JP2005519541A5 (ja) | ||
| JPH09270994A (ja) | ストリーム制御方式 | |
| JP4193856B2 (ja) | データ送信装置及び方法 |