図面 (/)

技術 高速インターネット・プロトコル・ネットワークでデータを伝送するためのデータ・トランスポート・コンテナ

出願人 トムソンライセンシング
発明者 ホイリー
出願日 2009年3月2日 (11年5ヶ月経過) 出願番号 2009-048419
公開日 2009年9月17日 (10年10ヶ月経過) 公開番号 2009-213138
状態 特許登録済
技術分野 広域データ交換
主要キーワード 多重ユニット 多重化段 データ伝送性能 実時間パケット 多重化ユニット サンプル音声 インターコム 立案者
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2009年9月17日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

本発明は、インターネットプロトコルネットワークでn個の異なる種類のデータを伝送するデータ・トランスポートコンテナを提供する。

解決手段

nは2以上の数である。データはイーサネット登録商標巨大パケットとして生成される。データ・トランスポート・コンテナはインターネット・プロトコル・パケットである。本発明は、それぞれデータ・トランスポート・コンテナを送信する送信元装置、及び受信する宛先装置にも関する。少なくとも、本発明は、ギガビット・イーサネット(登録商標)のRTP—UDP−IP巨大パケットとして生成されたn個の異なる種類のデータを伝送する方法に関する。上述の装置の両方は、上述の方法で用いられる。

概要

背景

本章では読者に、以下に記載され及び/又は請求される本発明の種々の態様に関連し得る技術の種々の態様を紹介する。この記載は読者に背景情報を提供し、本発明の種々の態様を一層理解するために有用であろう。従って、理解されるべき点は、これらの記述がこの観点から読まれるべきであり、従来技術の承認ではないことである。

ギガビットイーサネット登録商標)(GigE)は、ネットワーク進化の新たな段階として急速に有名になり、受け入れられている。比較的低価格、高速、且つ今日の事実上の業界標準である100Mbps高速イーサネット(登録商標)と相互運用可能であるのは、一握りのGigEだけである。多くのネットワークの立案者がGigEを採用するのは時間の問題である。

ギガビット・イーサネット(登録商標)は10/100Mbpsと相互運用可能であるが、熟慮を要するある重要な相違点がある。最も重要な相違点の1つは、最大伝送ユニット又はMTUの如何なる標準規格も存在しないことである。10及び100Mbpsネットワークの標準化された1500バイトのMTUは、全く標準化されていないものに置き換えられてしまう。ギガビット・イーサネット(登録商標)のパケットは、ネットワーク・ベンダーの対応する如何なるサイズであってもよく、1500バイトから16000バイト以上まで変化する。ベンダーは、標準的に対応する最大フレーム・サイズを約9000バイト程度に制限する構成機器製造業者により制約を受けている。

所謂、巨大パケットの利益は顕著であり、巨大パケットは、1500バイトより小さいパケットを用いる場合に比べ、今日のネットワークでアクセス可能帯域幅を2倍以上にする。しかしながら、幾つかの難点が隠されている。標準MTUが存在しないので、MTUは100Mbpsからギガビットへの移行障害になる。例えば、ブラックホールのような種々の形式のMTU衝突は、ネットワークの性能を壊滅的に低下させてしまう。

特大のパケットを末端ホストへ送信し、中間インターフェースから戻ってくるメッセージを受信することにより、送信側ホストは、特定の末端ホストへの経路MTUを発見でき、それに応じて自身のトラフィックパターンを調整できる。適切に設定されていない場合、又はメッセージがレイヤー3インターフェースで無差別遮断される場合、必要なメッセージは送信元インターフェースへの経路を見付けることができない。これらの装置は、ブラック・ホールと称される。

用語「巨大」は、標準的に10/100Mbpsイーサネット(登録商標)規格より大きい如何なるネットワーク・ユニット(フレーム、パケット、MTU)にも用いられる。レイヤー3(パケット及びMTU)では、標準サイズは1500バイトである。巨大パケットは、100MbpsとGigEとの間の明らかな相違点の1つである。

しかしながら、ギガビット・イーサネット(登録商標)規格は如何なる規定の最大伝送ユニット(MTU)も有さないという問題が浮上する。MTUは、レイヤー3のパラメータであり、ネットワークで許可される最大パケット・サイズを制御する。10及び100Mbpsイーサネット(登録商標)では、規格(RFC894、895)は、最大のMTUを1500バイトに明示的に規定し、殆ど全てのイーサネット(登録商標)・インターフェース・カードが当該規格に従っている。

しかし、現在の実装では、GigEのデータ伝送性能は、MTUに大きく依存する。最近の研究は、巨大パケットにより、殆どのホストが、1500バイトより小さいパケットの場合よりも遙かに高い伝送レートでデータを送信できることを示している。この状況では、異なる送信元により生成された巨大パケットをRTPパケット多重する必要がある。

従来、ヘッダーオーバーヘッド縮小するため、又は複数ユーザーのデータを単一のRTPセッション伝送する目的で複数のユーザー・データを単一のRTPパケットに包含させるために、複数のパケットを単一のRTPパケットに纏めることが良く知られている。しかし、これらの既存のRT多重化方法は、全て標準のパケットのRTPアプリケーションに基づく。これらの方法は、ビデオ・データ、音声データ、又はメタデータのような異なる種類のデータがイーサネット(登録商標)の巨大パケットで伝送される場合に使用することができない。

例えばHiPerNetカメラのような最近の用途は、DPX形式のビデオ、ビデオ・コンテンツとの時間的関係を維持しているAIFF音声信号AIFF音声としても提供され、ビデオ・コンテンツとの時間的関係のないインターコム音声、及び少なくともメタデータのような異なる種類のデータを有する種々の出力ストリームを生成する。これら全ての出力ストリームは、イーサネット(登録商標)のIP−UDP−RTP巨大パケットとして生成される。

概要

本発明は、インターネットプロトコルのネットワークでn個の異なる種類のデータを伝送するデータ・トランスポートコンテナを提供する。nは2以上の数である。データはイーサネット(登録商標)巨大パケットとして生成される。データ・トランスポート・コンテナはインターネット・プロトコル・パケットである。本発明は、それぞれデータ・トランスポート・コンテナを送信する送信元装置、及び受信する宛先装置にも関する。少なくとも、本発明は、ギガビット・イーサネット(登録商標)のRTP—UDP−IP巨大パケットとして生成されたn個の異なる種類のデータを伝送する方法に関する。上述の装置の両方は、上述の方法で用いられる。

目的

本発明の目的の1つは、高速IPネットワークでイーサネット(登録商標)のIP−UDP−RTP巨大パケットとして生成された、異なる種類に属するこれらのデータを同時に送信することである

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

データ・トランスポートコンテナであって、n個の異なる種類のデータを高速インターネットプロトコルネットワーク伝送し、前記nは2以上の数であり、データはイーサネット登録商標巨大パケットとして生成され、前記データ・トランスポート・コンテナはインターネット・プロトコル・パケットであり、連続するインターネット・プロトコル多重化論理ブロックを有し、各論理ブロックはデータの各種類に対応するn個のインターネット・プロトコル物理パケットの組み合わせを有し、各インターネット・プロトコル物理パケットは、前記物理パケットが有する前記データの種類に依存する所定数のイーサネット(登録商標)巨大パケットの集合である、データ・トランスポート・コンテナ。

請求項2

nは2に等しく、第1の種類のデータは送信元により生成されたDXPビデオコンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号であり、AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持している、請求項1に記載のデータ・トランスポート・コンテナ。

請求項3

nは3に等しく、第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号であり、AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持しており、第3の種類のデータは、AIFF音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号である、請求項1に記載のデータ・トランスポート・コンテナ。

請求項4

nは4に等しく、第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号であり、AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持しており、第3の種類のデータは、AIFF音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号であり、第4の種類のデータはメタデータである、請求項1に記載のデータ・トランスポート・コンテナ。

請求項5

前記第1の種類のデータに対応する巨大パケットの集合の中で、1つの巨大パケットがDPヘッダーを有する、請求項2乃至4の何れか一項に記載のデータ・トランスポート・コンテナ。

請求項6

請求項1乃至5の何れか一項に記載のデータ・トランスポート・コンテナを高速インターネット・プロトコル・ネットワークで送信する送信元装置であって、前記データ・トランスポート・コンテナはn個の異なる種類のデータを有し、前記nは2以上の数であり、各データの種類はイーサネット(登録商標)巨大パケットとして生成され、前記送信元装置は、−単一の種類のデータを有する所定数のイーサネット(登録商標)巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する手段、−各種類のデータに対応するn個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する手段、及び−前記インターネット・プロトコル多重化論理ブロックを有するストリームを前記ネットワークで伝送する手段、を有する送信元装置。

請求項7

請求項1乃至5の何れか一項に記載のデータ・トランスポート・コンテナを受信する宛先装置であって、前記データ・トランスポート・コンテナはn個の異なる種類のデータを有し、前記nは2以上の数であり、各種類のデータは、イーサネット(登録商標)巨大パケットとして生成され、前記宛先装置は、−前記ストリームを受信する手段、及び−各種類のデータに対応するイーサネット(登録商標)巨大パケットを復元するために、前記受信したストリームをフィルタリングする手段、を有する宛先装置。

請求項8

n個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送する方法であって、前記nは2以上の数であり、各データの種類はイーサネット(登録商標)巨大パケットとして生成され、前記方法は、−単一の種類のデータを有する所定数のイーサネット(登録商標)巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する段階、−各種類のデータに対応するn個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する段階、−前記インターネット・プロトコル多重化論理ブロックを有するストリームを前記ネットワークで伝送する段階、−前記ストリームを受信する段階、及び−各種類のデータに対応するイーサネット(登録商標)巨大パケットを復元するために、前記受信したストリームをフィルタリングする段階、を有する方法。

請求項9

第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは前記送信元により生成されたAIFF音声信号であり、前記AIFF音声信号は、前記ビデオ・コンテンツと時間的関係を維持している、請求項8に記載の方法。

請求項10

第3の種類のデータは、AIFF音声信号として提供され、前記ビデオ・コンテンツと時間的関係のないインターコム音声信号である、請求項8又は9の何れか一項に記載の方法。

請求項11

第4の種類のデータはメタデータである、請求項8乃至10の何れか一項に記載の方法。

技術分野

0001

本発明は、インターネットプロトコル(IP)ネットワークでデータを伝送するデータ・トランスポートコンテナに関する。データ・トランスポート・コンテナは、少なくとも2つの異なる種類のデータを、ギガビットイーサネット登録商標)(登録商標)のRTP−UDP−IP巨大パケットとして、同時に伝送することに特に関与する。例えば、2種類のデータは、加入者局のネットワークで送信される単一の送信元により生成される。

0002

更に、本発明は、それぞれデータ・トランスポート・コンテナを送信する送信元装置、及び受信する宛先装置に関する。

0003

少なくとも、本発明は、ギガビット・イーサネット(登録商標)のRTP—UDP−IP巨大パケットとして生成された異なる種類のデータを伝送する方法に関する。上述の装置の両方は、上述の方法で用いられる。

背景技術

0004

本章では読者に、以下に記載され及び/又は請求される本発明の種々の態様に関連し得る技術の種々の態様を紹介する。この記載は読者に背景情報を提供し、本発明の種々の態様を一層理解するために有用であろう。従って、理解されるべき点は、これらの記述がこの観点から読まれるべきであり、従来技術の承認ではないことである。

0005

ギガビット・イーサネット(登録商標)(GigE)は、ネットワークの進化の新たな段階として急速に有名になり、受け入れられている。比較的低価格、高速、且つ今日の事実上の業界標準である100Mbps高速イーサネット(登録商標)と相互運用可能であるのは、一握りのGigEだけである。多くのネットワークの立案者がGigEを採用するのは時間の問題である。

0006

ギガビット・イーサネット(登録商標)は10/100Mbpsと相互運用可能であるが、熟慮を要するある重要な相違点がある。最も重要な相違点の1つは、最大伝送ユニット又はMTUの如何なる標準規格も存在しないことである。10及び100Mbpsネットワークの標準化された1500バイトのMTUは、全く標準化されていないものに置き換えられてしまう。ギガビット・イーサネット(登録商標)のパケットは、ネットワーク・ベンダーの対応する如何なるサイズであってもよく、1500バイトから16000バイト以上まで変化する。ベンダーは、標準的に対応する最大フレーム・サイズを約9000バイト程度に制限する構成機器製造業者により制約を受けている。

0007

所謂、巨大パケットの利益は顕著であり、巨大パケットは、1500バイトより小さいパケットを用いる場合に比べ、今日のネットワークでアクセス可能帯域幅を2倍以上にする。しかしながら、幾つかの難点が隠されている。標準MTUが存在しないので、MTUは100Mbpsからギガビットへの移行障害になる。例えば、ブラックホールのような種々の形式のMTU衝突は、ネットワークの性能を壊滅的に低下させてしまう。

0008

特大のパケットを末端ホストへ送信し、中間インターフェースから戻ってくるメッセージを受信することにより、送信側ホストは、特定の末端ホストへの経路MTUを発見でき、それに応じて自身のトラフィックパターンを調整できる。適切に設定されていない場合、又はメッセージがレイヤー3インターフェースで無差別遮断される場合、必要なメッセージは送信元インターフェースへの経路を見付けることができない。これらの装置は、ブラック・ホールと称される。

0009

用語「巨大」は、標準的に10/100Mbpsイーサネット(登録商標)規格より大きい如何なるネットワーク・ユニット(フレーム、パケット、MTU)にも用いられる。レイヤー3(パケット及びMTU)では、標準サイズは1500バイトである。巨大パケットは、100MbpsとGigEとの間の明らかな相違点の1つである。

0010

しかしながら、ギガビット・イーサネット(登録商標)規格は如何なる規定の最大伝送ユニット(MTU)も有さないという問題が浮上する。MTUは、レイヤー3のパラメータであり、ネットワークで許可される最大パケット・サイズを制御する。10及び100Mbpsイーサネット(登録商標)では、規格(RFC894、895)は、最大のMTUを1500バイトに明示的に規定し、殆ど全てのイーサネット(登録商標)・インターフェース・カードが当該規格に従っている。

0011

しかし、現在の実装では、GigEのデータ伝送性能は、MTUに大きく依存する。最近の研究は、巨大パケットにより、殆どのホストが、1500バイトより小さいパケットの場合よりも遙かに高い伝送レートでデータを送信できることを示している。この状況では、異なる送信元により生成された巨大パケットをRTPパケット多重する必要がある。

0012

従来、ヘッダーオーバーヘッド縮小するため、又は複数ユーザーのデータを単一のRTPセッションで伝送する目的で複数のユーザー・データを単一のRTPパケットに包含させるために、複数のパケットを単一のRTPパケットに纏めることが良く知られている。しかし、これらの既存のRTP多重化方法は、全て標準のパケットのRTPアプリケーションに基づく。これらの方法は、ビデオ・データ、音声データ、又はメタデータのような異なる種類のデータがイーサネット(登録商標)の巨大パケットで伝送される場合に使用することができない。

0013

例えばHiPerNetカメラのような最近の用途は、DPX形式のビデオ、ビデオ・コンテンツとの時間的関係を維持しているAIFF音声信号AIFF音声としても提供され、ビデオ・コンテンツとの時間的関係のないインターコム音声、及び少なくともメタデータのような異なる種類のデータを有する種々の出力ストリームを生成する。これら全ての出力ストリームは、イーサネット(登録商標)のIP−UDP−RTP巨大パケットとして生成される。

発明が解決しようとする課題

0014

本発明の目的の1つは、高速IPネットワークでイーサネット(登録商標)のIP−UDP−RTP巨大パケットとして生成された、異なる種類に属するこれらのデータを同時に送信することである。

0015

開示される実施例の範囲と対応する特定の態様を以下に説明する。理解されるべき点は、これらの態様が単に読者に、本発明が取り得る特定の形式の概要を提供するために提示されること、及びこれらの態様が本発明の範囲を制限しないことである。実際に、本発明は以下に記載されない種々の態様を包含し得る。

0016

本発明が解決する技術的課題は、高速IPネットワークで生成された巨大パケットとして生成された異なる種類のデータを同時に送信することである。

課題を解決するための手段

0017

従って、本発明は、第1の態様によると、高速インターネット・プロトコルのネットワークでn個の異なる種類のデータを伝送するためのデータ・トランスポート・コンテナに関する。nは2以上の数である。データはイーサネット(登録商標)巨大パケットとして生成される。データ・トランスポート・コンテナはインターネット・プロトコル・パケットである。

0018

本発明によると、データ伝送は、インターネット・プロトコル多重化論理ブロックシーケンスを有し、各論理ブロックは各種類のデータに対応するn個のインターネット・プロトコル物理パケットの組み合わせを有し、各インターネット・プロトコル物理パケットは、当該物理パケットが有するデータの種類に依存する所定数のイーサネット(登録商標)巨大パケットを有する。

0019

本発明は、第2の態様によると、本発明によるデータ・トランスポート・コンテナを高速インターネット・プロトコル・ネットワークで送信する送信元装置S_DEVに関する。データ・トランスポート・コンテナは、n個の異なる種類のデータを有する。nは2以上の数である。各種類のデータは、イーサネット(登録商標)巨大パケットとして生成される。

0020

本発明によると、送信元装置は、
−単一の種類のデータを有する所定数のイーサネット(登録商標)巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する手段、
−各種類のデータに対応するn個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する手段、
−インターネット・プロトコル多重化論理ブロックを有するストリームをネットワークで伝送する手段、を有する。

0021

本発明は、第3の態様によると、本発明によるデータ・トランスポート・コンテナを受信する宛先装置D_DEVに関する。データ・トランスポート・コンテナは、n個の異なる種類のデータを有する。nは2以上の数である。各種類のデータは、イーサネット(登録商標)巨大パケットとして生成される。

0022

本発明によると、宛先装置は、
−各種類のデータに対応するイーサネット(登録商標)巨大パケットを復元するために、受信したストリームをフィルタリングする手段、を有する。

0023

本発明は、第4の態様によると、高速インターネット・プロトコルのネットワークでn個の異なる種類のデータを伝送する方法に関する。nは2以上の数である。各種類のデータは、イーサネット(登録商標)巨大パケットとして生成される。

0024

本発明によると、方法は、
−単一の種類のデータを有する所定数のイーサネット(登録商標)巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する段階、
−各種類のデータに対応するn個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する段階、
−インターネット・プロトコル多重化論理ブロックを有するストリームをネットワークで伝送する段階、
−ストリームを受信する段階、
−各種類のデータに対応するイーサネット(登録商標)巨大パケットを復元するために、受信したストリームをフィルタリングする段階、を有する。

0025

本発明の実施例は、以下の文章及び添付の図面を参照して説明される。

図面の簡単な説明

0026

本発明による、高速IPネットワークで異なる種類のデータを結合して伝送する方法の概略である。
専門のカメラにより生成された異なる種類のデータである。
IP多重化論理ブロックの構造の例である。
イーサネット(登録商標)IP−UDP−RTPパケットのカプセル化の例である。
イーサネット(登録商標)・オーバーIPのカプセル化の例である。
IPヘッダーである。
UDPヘッダーである。
DPXオーバーRTPのカプセル化である。
ビデオ・パケットのみのストリームのDPXフォーマットの構造である。
DPXヘッダー・ペイロードを有するイーサネット(登録商標)巨大パケットである。
DPXビデオ・ライン・ペイロードを有するイーサネット(登録商標)巨大パケットである。
AIFFファイルの構造である。
AIFFファイル・オーバーRTPのカプセル化である。
AIFFチャンク専用のRTPのカプセル化である。
AIFFチャンク・ペイロードを有するイーサネット(登録商標)・パケットである。
データ・トランスポート・コンテナ内の多重化レイアウトである。

実施例

0027

専門的用途のためのカメラは、以下の出力ストリームを、イーサネット(登録商標)IP−UDP−RTPの巨大パケットとして生成する。
−DPXビデオ。
−ビデオ・コンテンツと時間的関係を維持しているAIFF音声。
−ビデオ・コンテンツと如何なる時間的関係もない、AIFF音声としても提供されるインターコム音声。
−(適用可能な場合に)ビデオ・カメラにより生成されるメタデータ・パケット。

0028

メタデータ・ストリームは、カメラにより生成されたメタデータ、又は(任意のウェブサーバーにより生成されたメタデータのような)外部メタデータを有する。これらのコンテンツは、カメラ・ストリーム・コンテンツに関連し、後の編集のために有用である。

0029

遠隔の装置と高速で、これら全てのデータを結合して伝送する必要がある。この必要を満たすための方法は、これらのデータを高速IPネットワークで伝送することである。

0030

図1は、本発明の、n個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送する方法を示す。

0031

送信側で、送信元装置S_DEVは、カメラにより生成された全ての異なるストリームをパケットに結合し、全てのパケットを単一の物理IP伝送リンクを用いて伝送する。

0032

図2に示されるように、チャネル多重化のみがIPパケット層で行われる。これは、異なるメディアにより生成された全ての元のIP−UDP−RTPパケットが変更されないことを意味する。

0033

受信側で、宛先装置D_DEVは、IPパケットをフィルタリングし、関連するスタンドアロン処理又は記憶装置転送する。IPトランスポート・ストリームは、伝送用パイプラインと考えられるので、当該パイプライン内の物理的なデータ・フローは単一の次元を有する。各プログラムタイミング同期を維持しながら、1以上のプログラムのトランスポート・ストリーム・パケットを、単一の統一ビット・ストリームに交互に配置する処理は、「IP多重化」として知られている。IP多重化処理は、物理的に一次元のパイプライン内に、仮想的に複数のサブパイプラインを作成するようなものである。

0034

以下では、このような仮想サブパイプラインを、巨大パケットを用いて単一の物理パイプライン内に実現する、可能な方法を説明する。

0035

物理的には、物理パイプライン内には、1つのトランスポート・ストリームのパイプライン・リンクのみが存在し、サブパイプラインは存在しない。仮想サブパイプラインは、一次元のトランスポート・ストリーム・パイプライン内でのサブストリーム多重化を通じて実現されなければならない。このような多重化を行うために、トランスポート・ストリームは、図3に示すような多重化論理ブロックのシーケンスを有する。各ブロックは、現在の物理パイプライン内の全仮想サブパイプラインの最小ストリーム単位を意味する。

0036

図3の各IP多重化論理ブロックは、IP物理パケットを有する。IP物理パケットは、ビデオ、音声、インターコム、及び他のデータの多重化されたトランスポート・パケットである。本例では、ビデオ、音声、及びインターコムのストリームは、実時間トランスポート・パケットなので、それらのストリームのために多重化論理ブロック内の固定ビットが予約されている。更に、多重化論理ブロック内には、カメラが生成したメタデータ・パケット及び外部パケットのような非実時間パケットのためのビットがある。

0037

本発明のデータ・トランスポート・コンテナは、n個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送するために用いられる。

0038

有利なことに、nは2に等しく、第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号である。AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持している。

0039

有利なことに、nは3に等しく、第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号である。AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持している。第3の種類のデータは、AIFF音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号である。

0040

有利なことに、nは4に等しく、第1の種類のデータは送信元により生成されたDXPビデオ・コンテンツであり、第2の種類のデータは送信元により生成されたAIFF音声信号である。AIFF音声信号は、ビデオ・コンテンツと時間的関係を維持している。第3の種類のデータは、AIFF音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号である。第4の種類のデータは、メタデータである。

0041

例として、先ず、DPXフォーマット専用のRTPカプセル化を説明する。次に、AIFFフォーマット専用のRTPカプセル化を説明する。そして、多重化段階を説明する。

0042

[ビデオ・パケットのカプセル化]
図3は、多重化ブロックのデータ構造を示す。多重化論理ブロックは、ビデオ部、音声部、インターコム部、及びメタデータ部を有する。ソースの各部分は、ソース・ストリームの最小多重ユニット(MMU)である1つのIPパケット又はIPパケットのグループを有する。MMUは、各ソース・パケットの最小伝送可能ユニットであり一緒に送信されなければならない1つのIPパケット又はIPパケットのグループである。MMUの構造は、現在のアプリケーションのバッファの制限に適合する。各ソース・ストリームのMMUのデータ構造を以下に説明する。

0043

図4は、パケットのデータ構造を示す。例として考えるアプリケーションでは、データはDPXデータ、AIFFデータである。

0044

図5、6、7は、イーサネット(登録商標)、IP、UDPフォーマットの関連するヘッダー及びカプセル化データ構造を示す。これらのデータ構造に示されるように、イーサネット(登録商標)のヘッダーは14バイトを有し、イーサネット(登録商標)・トレイラは4バイトであり、標準のIPヘッダーは20バイトであり、UDPヘッダーは8バイトである。

0045

図8は、DPXフォーマット専用のRTPのカプセル化を示す。この場合には、標準のRTPヘッダー(12バイト)の次にDPXペイロード・ヘッダー(12バイト)がある。RTPパケットは、同一のタイムスタンプを有するDPXフレームを有する。RTP毎に1つのDPXフレームのデータのみが許可される。

0046

SMPTE268M−2003で規定されるように、各DPXファイルは4つのセクションを有する。最初の3つのセクションは、ヘッダー情報である。4番目のセクションはビデオ・データを有する。通常、3番目のセクションは、ユーザーが定義するデータを有し、カスタマイズしたメタデータ情報のための拡張領域を提供する。この3番目のセクションは、例として挙げるアプリケーションで用いられない。このアプリケーションでは、ビデオ情報をDPXパケット内の全てのメタデータと結合しないが、2つの別個のストリームを作成することを提案する。1つのストリームは、全体のヘッダー情報及びビデオ情報のみを有するDPXパケットを有する。また、メタデータは、別のメタデータのみのストリーム内に読み込まれる。

0047

標準的なビデオ・フレームが1920*1080ピクセルであり、各ピクセルが36ビット毎に符号化される場合を検討する。従って、ビデオ・フレームの重みは、1920*1080*36ビット、又は74649600ビット、又は9.3312Mバイト表現される。DPXビデオ・ストリームは、DPXヘッダーを有するビデオ・データのみを有する。DPXヘッダーは、ヘッダー情報である2つのセクション、空の3番目のセクション、及びビデオ・フレームを有する4番目のセクションを有する。図9に示される例では、3番目のセクションは現れない。

0048

上述のヘッダー構造を検討する。イーサネット(登録商標)巨大パケット(MTU:9018バイト)がDPXビデオを伝送するために用いられる場合、図10に示されるDPXビデオのカプセル化データ構造が生成される。

0049

イーサネット(登録商標)巨大パケットを用い、IP−UDP−RTP−DPXパケットを伝送する場合、最大の利用可能なDPXペイロード・データは8948バイトである。ビデオDPXパケット(図11)を伝送するために、元のDPXパケット(9.3312Mバイト)を、一連の小さいイーサネット(登録商標)巨大パケット(9018バイト)に分割しなければならない。簡易なフィルタリングのため、図9に示されるDPXヘッダーのデータは、図11に示されるような1つの別個の巨大パケットで伝送される。DPXヘッダーの巨大パケットの合計サイズは、2118バイトである。

0050

ビデオ・フレームの各ビデオ・ラインを単一の巨大パケットにパケット化することが選択される。各ビデオ・ラインは、1920*36ビット、又は8640バイトである。図12に示されるように、ビデオ・フレームの全体は、1080個のパケットに読み込まれる。DPXビデオ・ラインの巨大パケットの合計サイズは、8710バイトである。上述の説明によると、DPXビデオ・フレームは1081個のイーサネット(登録商標)巨大パケットとして伝送される。最初に伝送されたパケットは、DPXヘッダー・ペイロード(2118バイト)を有する。更に1080個の伝送パケットは、DPXビデオ・ライン・ペイロード(各8710バイト)を有する。

0051

有利なことに、第1の種類のデータに対応する巨大パケットの集合の中で、1つの巨大パケットがDPXヘッダーを有する。

0052

音声パケットのカプセル化]
音声交換ファイル・フォーマット(AIFF)規格は、RTPにする前にサンプル音声チャネルを格納するために用いられる。図13に示されるように、AIFFファイルは、異なる種類のチャンクを有する。ヘッダー・コンテンツ、共通チャンク・サイズ、及び音声記録チャンクが定められている。音声データ・チャンク・サイズは、伝送されるパケットのサイズに依存する。

0053

図13に示す例では、1チャンネル音声サンプルエンコードするために3バイトが用いられる。また、6個の音声チャンネルが用いられ、サンプル・フレームのサイズは18バイトである。音声周波数は48kHzであり、ビデオ・レートは24フレーム毎秒である。1ビデオ・フレーム中に、2000個の音声サンプル・フレームが生成される。これらの音声サンプル・フレームを、それぞれ等しいサイズの5個のパケットに分割する場合、各パケットは、400個のサンプル・フレームを有する。1ビデオ・フレーム中に合計で36kバイトの音声サンプル・フレームがあるので、各パケット内の音声ペイロードは、7.2kバイトに等しい。図13に示したAIFFフォームによると、音声データ・チャンクは7216バイトであり、全AIFFフォームは7286バイトである。

0054

図14は、AIFFチャンク専用のRTPのカプセル化を示す。この場合には、標準のRTPヘッダー(12バイト)の次にAIFFペイロード・ヘッダー(8バイト)がある。AIFFチャンクは、新しいRTPパケットから開始しなければならない。上述のAIFFフォームは、巨大イーサネット(登録商標)・パケット(MTU9018バイト)でカプセル化される。

0055

図15は、イーサネット(登録商標)IP—UDP−RTP−AIFFパケットの構造を示す。全パケット長は、7352バイトである。

0056

[多重化]
ビデオ・パケット及び音声パケットの多重化を説明する。DPXファイルは分割され、イーサネット(登録商標)IP−UDP−RTPパケットに埋め込まれる。DPXヘッダー(ユーザー定義データの部分を除く)は1つの別個の巨大パケットとして伝送される。その後、一式の1080個の巨大パケットが生成される。各巨大パケットは、ビデオ・フレームの1つのビデオ・ラインを有する。これらの1081個の巨大パケットは、DPXビデオ・ストリームの最小多重化ユニットに相当する。音声及びインターコムのソース・ストリームの最小多重化ユニットは、AIFFフォーム・ペイロードを有する5個のイーサネット(登録商標)巨大パケットを有する。メタデータ及び外部データの場合には、最小多重化ユニットは、単一のイーサネット(登録商標)巨大IPパケットを有する。

0057

図16は、トランスポート・ストリーム内の多重化論理ブロックの詳細な構造を示す。
多重化ブロックの最初の部分は、メタデータ部である。メタデータ部は、巨大IPメタデータ・パケットである。メタデータ部の最大サイズは9kBである。メタデータ部のペイロードは、内部及び外部で生成された任意のメタデータである。大きいメタデータを単一の巨大パケットに完全に読み込むことができない場合、メタデータは分割され、次の多重化ブロックのメタデータ・パケットに読み込まれる。多重化ブロック内のメタデータ・パケットは任意である。メタデータが存在しない場合、メタデータ・パケットは省略される。

0058

多重化ブロック内の2番目及び3番目の部分は、インターコム部及び音声部である。インターコム部は、5個のインターコム・パケットを有し、音声部は5個の音声パケットを有する。インターコム及び音声パケットは、両方とも巨大イーサネット(登録商標)IPパケットである。巨大イーサネット(登録商標)IPパケットは、7352バイトであり、AIFFペイロードを有する。インターコム・パケットは任意であり、音声パケットは必須である。

0059

4番目の部分(ビデオ部)で、1081個の巨大ビデオ・パケットが伝送される。多重化ブロックの平均サイズは、9.485Mバイトである。

0060

図16は、本発明によるデータ・トランスポート・コンテナの最終的なIP多重化レイアウトを示す。このデータ・トランスポート・コンテナでは、IPパケットとして提供されるソース・ストリーム又はパケットは、イーサネット(登録商標)IPトランスポート・ストリームに多重化される。IPトランスポート・ストリームは、ソース・パケットのグループの最小伝送ユニット、つまりビデオ最小多重化ユニット(MMU)、音声MMU、インターコムMMU、及びメタデータ/外部データMMUの集合である一連の多重化論理ブロックを有する。各ソース信号のMMUは、最小の伝送可能且つ読み出し可能な、ソース・ストリームのパケットである。各MMTは、各MMUのソース信号フォーマットの要件に従い設計される。

0061

本願明細書に開示された参考文献、請求項及び図面は、独立に又は如何なる適切な組み合わせで提供されても良い。特徴は、必要に応じてハードウェアソフトウェア、又はそれらの組み合わせで実施されて良い。本願明細書中の「実施例」の語は、当該実施例と関連して記載された特定の機能、構造、又は特徴が本発明の少なくとも1つの実施例に含まれることを意味する。本願明細書を通じて各所に現れる「ある実施例では」のは、必ずしも全て同一の実施例を参照するものではなく、又は他の実施例と相互排他的な実施例を分離若しくは置き換えるものではない。請求項内の参照符合は、単に説明のためであり、請求項の範囲を制限するものではない。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ