JP3647366B2

JP3647366B2 - Data processing apparatus, data processing method, and computer-readable recording medium

Info

Publication number: JP3647366B2
Application number: JP2000255865A
Authority: JP
Inventors: 章佳浜中
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-08-25
Filing date: 2000-08-25
Publication date: 2005-05-11
Anticipated expiration: 2020-08-25
Also published as: JP2002077292A

Description

【０００１】
【発明の属する技術分野】
本発明は、データ処理装置、データ処理方法及びコンピュータ読み取り可能な記録媒体に関するものであり、特に符号化されたデータの送信処理或いは受信処理に関するものである。
【０００２】
【従来の技術】
近年において、例えば、「ＩＳＯ／ＩＥＣ１４４９６（ＭＰＥＧｐｈａｓｅ４）」規格では、マルチメディアの符号化の標準化（圧縮フォーマットの標準化）が進められている。
【０００３】
本規格では、従来のビデオデータやオーディオデータの符号化の他に、各メディアの空間や時間的配置を定義することが可能であり、これを「シーン記述」と呼称し、各々のメディアを「オブジェクト」と呼称している。
【０００４】
図９は、本規格でのシーンの一例を示したものである。
上記図９では、グラフィックオブジェクトとしてＢＯＸ（箱）４０１及びＣｙｌｉｎｄｅｒ（円柱）４０２が定義されている。また、ＢＯＸ４０１に貼付されるイメージテクスチャ４０１ａ、Ｃｙｌｉｎｄｅｒ４０２に貼付されるビデオテクスチャ４０２ａ、及びそれらと同時に再生されるオーディオ４０３が定義されている。
【０００５】
シーン記述自体の手法としては、例えば、ＶＲＭＬ（ＶｉｒｔｕａｌＲｅａｌｉｔｙＭａｒｋｕｐＬａｎｇｕａｇｅ)に基づき機能拡張及びバイナリ化を行ったＢＩＦＳ（ＢｉｎａｒｙＦｏｒｍａｔｆｏｒＳｃｅｎｅｄｅｓｃｒｉｐｔｉｏｎ）が採用されている。
【０００６】
また、本規格では、上記図９に示したようなシーン記述とは別に、オブジェクトディスクリプタ（以下、「ＯＤ」と言う）と呼ばれる、各オブジェクトの属性を示すデータが定義される。
ここでの属性とは、メディアの属性（ビデオ、オーディオ、イメージ等）や、著作権者情報、ＱｏＳ（ＱｕａｌｉｔｙＯｆＳｅｒｖｉｃｅ）情報、コンテンツのレーティング情報等を示す。
このような属性自体が、それぞれ個々のディスクリプタとして、ＯＤの中に内包される。
【０００７】
図１０は、本規格に従ったビットストリーム全体の一例を示したものである。上記図１０において、“５０１”は、初期オブジェクトディスクリプタであり、ビットストリーム全体のプロパティ（ビットストリームのプロファイル等）が格納される。
“５０２”は、ＢＩＦＳストリームであり、シーン情報が格納される。
【０００８】
“５０３”及び“５０６は、ＯＤであり、上記図１０でのビットストリームでは、２つのＯＤ１（５０３），ＯＤ２（５０６）を有するものとしている。
ＯＤ５０３，５０６の後には、オブジェクトの属性が記述される。すなわち、ＯＤ１（５０３），ＯＤ２（５０６）に続いて、各メディアストリーム（以下、「エレメンタリーストリーム」とも言う）ＥＳ１，ＥＳ２の属性を示すエレメンタリーストリームディスクリプタ（以下、「ＥＳＤ」と言う）が複数記述可能となっている。
上記図１０では、ＯＤ１（５０３）の後にＥＳＤ１（５０４）が記述され、ＯＤ２（５０６）の後にＥＳＤ２（５０７）が記述されている。
【０００９】
また、エレメンタリーストリームＥＳ１，ＥＳ２については、実際にはパケッタイズされ、「ＳｙｎｃＬａｙｅｒＰａｃｋｅｔ」（以下、「ＳＬパケット」と言う）として扱われるため、上記図１０に示すように、当該ＳＬパケットの構造を記述するためのＳＬＣｏｎｆｉｇのディスクリプタ５０５，５０８がＥＳＤ１（５０４），ＥＳＤ２（５０７）のそれぞれに対して付加される。
【００１０】
上述したＯＤ及びＥＳＤのディスクリプタはそれぞれ、上記図１０に示したビットストリームにおいて、各エレメンタリーストリームＥＳ１，ＥＳ２の前の先頭に設置する必要がある。
ただし、ＯＤ及びＥＳＤはそれぞれ、ビットストリームの途中にアップデートコマンドを挿入することによって、追加、削除、及び変更が可能となっている。
【００１１】
また、本規格では、ＯＤ及びＥＳごとに、著作権管理情報やアクセス制御情報等のセキュリティ情報を付加することが可能になっている。この情報は、ＩＰＭＰ（ＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙＭａｎａｇｅｍｅｎｔａｎｄＰｒｏｔｅｃｔｉｏｎ）情報と呼ばれている。
ＩＰＭＰ情報についても、ＩＰＭＰディスクリプタと称されるディスクリプタにおいてその詳細が記述される。
実際には、アクセス制御として暗号が使用される場合が多いが、ＩＰＭＰの方式（ディスクリプタのシンタックス）は特定されておらず、フリーシンタックスとなっている。また、ＲＡ（ＲｅｇｉｓｔｒａｔｉｏｎＡｕｔｈｏｒｉｔｙ)に登録されたＩＰＭＰのセキュリティのタイプ番号のみを記述するようになっている。
【００１２】
ＩＰＭＰディスクリプタによって記述されたＩＰＭＰ情報自体は、ＩＰＭＰのセキュリティのタイプ番号でリンクすることによって、ＩＰＭＰ用のエレメンタリーストリームＥＳ（以下、「ＩＰＭＰ−ＥＳ」と言う）を付加することが可能となっている。
図１１は、この場合のビットストリーム全体の一例を示したものである。
上記図１１では、ＩＰＭＰ１（５１０）及びＩＰＭＰ２（５１２）がそれぞれ、エレメンタリーストリームＥＳ１（５０９），ＥＳ２（５１１）に対するＩＰＭＰ−ＥＳとなっている。
【００１３】
図１２は、ＩＰＭＰディスクリプタの一例を示したものである。
上記図１２において、“６０１”は、ディスクリプタ・タグ（ＴＡＧ）であり、ディスクリプタの種類を示す。
“６０２”は、レングスフィールド（ＬＥＮＧＴＨ）であり、ディスクリプタ全体の長さ（バイト数）を示す。
“６０３”は、ディスクリプタＩＤであり、ディスクリプタ自体の識別子が格納される。
“６０４”は、上述したセキュリティのタイプ番号（ＩＰＭＰＳ＿ｔｙｐｅ）である。
“６０５”は、オプションフィールド（Ｏｐｔｉｏｎ）であり、ＩＰＭＰに付随するデータを適宜挿入することができるようになされている。また、オプションフィールド６０５内のシンタックスが自由になっている。また、上記付随データは、オプションフィールド６０５にＵＲＬで示すことも可能となっている。
【００１４】
上述したＩＰＭＰのディスクリプタについても、上記図１１に示したビットストリームにおいて、各エレメンタリーストリームＥＳ１，ＥＳ２の前の先頭に設置する必要がある。
ただし、ＩＰＭＰのディスクリプタは、ビットストリームの途中にアップデートコマンドを挿入することによって、追加、削除、及び変更が可能となっている。
上記図１１では、ＩＰＭＰ情報をアップデートする場合のコマンド５１３を１ヶ所含んだビットストリームの一例を示している。
【００１５】
図１３は、上述したようなビットストリームを生成するためのエンコーダ７００の一例を示したものである。
上記図１３において、“７０１”は、オブジェクトディスクリプタ生成器であり、上述したようなディスクリプタをビットストリームのプロパティに応じて適宜生成する。
“７０２”は、メディアエンコーダであり、ビデオやオーディオ等のデータをエンコード（符号化）する。
“７０３”は、ＩＰＭＰコントローラである。
“７０４”は、ＢＩＦＳエンコーダであり、シーン情報をバイナリ化する。
“７０５”は、必要に応じて設けられるアップデートコントローラであり、ＯＤ、ＥＳＤ、及びＩＰＭＰのディスクリプタ等のプロパティを更新するためのコマンドを挿入する。
“７０６”は、マルチプレクサであり、各ディスクリプタや、メディアストリームを最終的に１つのＳＬパケットとしてマルチプレクスする。
【００１６】
図１４は、上記図１３のエンコーダ７００で得られたビットストリームをデコード（再生）するデコーダ８００の一例を示したものである。
上記図１４において、“８０１”は、デマルチプレクサであり、入力されたビットストリームから各ディスクリプタ及びＥＳ等を分離する。
“８０３”は、ディスクリプタパーサであり、ディスクリプタのタグ情報によって当該ディスクリプタの種類を判別し、当該ディスクリプタの内容を解読し、適宜各部に設定する。
“８０４”は、ＢＩＦＳデコーダであり、バイナリ化されたＢＩＦＳをデコードし、シーン構造を再構築する。
“８０５”は、メディアデコーダであり、ビデオやオーディオ、或はイメージ等のメディアデコーダをデコードする。
“８０７”は、レンダラであり、シーン構造に従って各オブジェクトを適宜表示、又は再生する。
“８０６”は、ＩＰＭＰコントローラであり、ＩＰＭＰディスクリプタ及びＩＰＭＰ＿ＥＳの情報に従って、メディアの再生制御（再生制限、効果制御等）を行う。例えば、データに暗号がかけられているような場合には、当該暗号を解読してから、メディアデコーダ８０５にデータを転送する。
“８０２”は、同期コントローラであり、各メディア間の同期制御を行う。
【００１７】
尚、上記図１３のエンコーダ７００側から上記図１４のデコーダ８００側へのデータ転送方法については特記しないが、ネットワーク上の伝送の場合には、全て１本のビットストリームとして、同一セッションにて送受信されるのが一般的である。
【００１８】
【発明が解決しようとする課題】
しかしながら、上記図１３に示した従来のエンコーダ７００側から、上記図１４に示した従来のデコーダ（再生器）８００側に対して、例えば、ネットワークを介してデータを送信する場合、全て１本のビットストリームとして同一セッションで送信され、当該ビットストリームの通信路又は通信手段としてのネットワーク以外に、他の通信路又は通信手段が存在しないため、ビットストリームの受信側であるデコーダ８００の能力（受信可能なビットレートの上限に代表される処理能力）のネゴシエーションや、伝送課程で生じたエラーに起因する不具合の通知、ビットストリームの再送要求、随時変化する通信路又は通信手段のトラフィックによりデコーダ８００側で生じるバッファーアンダーラン等の不具合の通知、再送要求等を行うことが不可能であった。
また、上述したＩＰＭＰディスクリプタを含むＩＰＭＰ＿ＥＳには、エラー訂正機能がないため、任意の有償コンテンツ（ビデオやオーディオ等の有償のメディアデータ）に伴うＩＰＭＰ＿ＥＳ（上記図１２参照）にエラーが生じた場合、ＩＰＭＰディスクリプタ以降のデータが全て無効となり、この状態が次のＩＰＭＰディスクリプタを受信するまで続くという致命的な問題があった。
【００１９】
そこで、本発明は、前記の欠点を除去するために成されたもので、データ伝送と共に、当該データ伝送で生じる要求及び応答等をデータの送信側と受信側の間で行えるように構成することで、効率的なデータ伝送が行えるデータ処理装置、データ処理方法及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体を提供することを目的とする。
【００２０】
【課題を解決するための手段】
斯かる目的下において、本発明のデータ処理方法は、それぞれが任意のサイズに分割された符号化データと、前記符号化データに関する任意の固有情報を含むヘッダとを連結して、一連のビットストリームを構成し、前記ビットストリームを第１の通信路を介して伝送するデータ処理方法であって、少なくとも前記ビットストリームの伝送に関する情報を第２の通信路を介して受信側から受信する受信ステップと、前記受信ステップにより得られた受信情報に基づいて、前記ビットストリームの伝送を制御する制御ステップとを含むことを特徴とする。
【００２１】
また、本発明のデータ処理方法は、複数の伝送プロトコルの中の任意の伝送プロトコルによって、少なくとも１つ以上の相互に独立な複数の符号化データを内包した任意のビットストリームを第１の通信路を介して受信して、前記相互に独立な複数の符号化データをそれぞれ独立に復号するためのデータ処理方法であって、少なくとも前記ビットストリームの伝送に関する情報を第２の通信路を介して前記ビットストリームの送信側へ送信する送信ステップを含むことを特徴とする。
【００２２】
また、本発明のデータ処理方法は、複数の相互に異なる伝送プロトコルの中の任意の伝送プロトコルによって、連続したビットストリームを送信するためのデータ処理方法であって、前記ビットストリームの任意の領域を任意の伝送プロトコルに従ってエンコードして送信する送信ステップと、前記ビットストリームの通信路とは独立した通信路を介して外部より受信した情報に応じて前記ビットストリームにおける任意の部分の伝送プロトコルを変更する変更ステップと、前記外部より受信した情報に応じて前記ビットストリームの既に送信済みの部分を次のビットストリームに結合して再送する再送ステップとを含むことを特徴とする。
【００２３】
また、本発明のデータ処理装置は、それぞれが任意のサイズに分割された符号化データと、前記符号化データに関する任意の固有情報を含むヘッダとを連結して、一連のビットストリームを構成し、前記ビットストリームを第１の通信路を介して伝送するデータ処理装置であって、少なくとも前記ビットストリームの伝送に関する情報を第２の通信路を介して受信側から受信する受信手段と、前記受信手段により得られた受信情報に基づいて、前記ビットストリームの伝送を制御する制御手段とを有することを特徴とする。
【００２４】
また、本発明のデータ処理装置は、複数の伝送プロトコルの中の任意の伝送プロトコルによって、少なくとも１つ以上の相互に独立な複数の符号化データを内包した任意のビットストリームを第１の通信路を介して受信する受信手段と、前記受信手段により受信されたビットストリーム中の前記相互に独立な複数の符号化データをそれぞれ独立に復号する復号手段と、少なくとも前記ビットストリームの伝送に関する情報を第２の通信路を介して前記ビットストリームの送信側へ送信する送信手段とを有することを特徴とする。
【００２５】
また、本発明のデータ処理装置は、複数の相互に異なる伝送プロトコルの中の任意の伝送プロトコルによって、連続したビットストリームを送信するためのデータ処理装置であって、前記ビットストリームの任意の領域を任意の伝送プロトコルに従ってエンコードして送信する送信手段と、前記ビットストリームの通信路とは独立した通信路を介して外部より受信した情報に応じて前記ビットストリームにおける任意の部分の伝送プロトコルを変更する変更手段と、前記外部より受信した情報に応じて前記ビットストリームの既に送信済みの部分を次のビットストリームに結合して再送する再送手段とを有することを特徴とする。
【００３４】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００３５】
（第１の実施の形態）
本発明は、例えば、図１に示すようなエンコーダ１００、及び図２に示すようなデコーダ２００を含むデータ処理システムに適用される。
本実施の形態のデータ処理システムは、上記図９〜図１２を用いて説明したような「ＩＳＯ／ＩＥＣ１４４９６（ＭＰＥＧｐｈａｓｅ４）」規格に準拠してデータ伝送を行うようになされている。
尚、本実施の形態では、その一例として、エンコーダ１００からデコーダ２００へのデータ伝送方法は任意であり、ネットワークを介して伝送する場合は、全て１本のビットストリームとして同一セッションにて伝送されるものとする。
【００３６】
エンコーダ１００は、上記図１に示すように、ＯＤ生成部１０１、メディアエンコーダ１０２、ＩＰＭＰ制御部１０３、ＢＩＦＳエンコーダ１０４、アップデートコントローラ１０５、及びマルチプレクサ１０６を備えている。
【００３７】
メディアエンコーダ１０２は、イメージやビデオ、オーディオ、及びその他のマルチメディア等のメディアデータ（コンテンツ）を符号化（圧縮）して出力する。
ＯＤ生成部１０１は、メディアエンコーダ１０２で処理対象となっているメディアデータの属性情報を符号化して、当該符号化データをＯＤとして出力する。ＢＩＦＳエンコーダ１０４は、メディアエンコーダ１０５で処理対象となっているメディアデータで構成されるシーン（上記図４参照）の情報を符号化して出力する。
【００３８】
ＩＰＭＰコントローラ１０３は、メディアエンコーダ１０２で符号化される各種メディアデータ（コンテンツ）に対するＩＰＭＰディスクリプタ及びＩＰＭＰ＿ＥＳ等のセキュリティ情報を生成すると共に、当該コンテンツに対して独立に暗号化処理を施す。
尚、メディアエンコーダ１０２で取り扱うコンテンツに対する著作権保護を必要としない場合は、この限りではない。
【００３９】
アップデートコントローラ１０５は、必要に応じて設けられるアップデートコントローラであり、ＯＤ、ＥＳＤ、及びＩＰＭＰのディスクリプタ等のプロパティを更新するためのコマンドをビットストリーム内に挿入する。
【００４０】
マルチプレクサ１０６は、ＯＤ生成部１０１、ＢＩＦＳエンコーダ１０４、ＩＰＭＰ制御部１０３、及びメディアエンコーダ１０２の各出力をマルチプレクスして、上記図１０や図１１に示したような１本のビットストリームへとまとめて出力する。
このとき、マルチプレクサ１０６は、マルチプレクスするデータの同期制御も行う。具体的には例えば、タイプスタンプやクロックリファレンスを、ビットストリームのパケットの中に埋めこむ。これにより、ＳＬパケッタイズされたビットストリームが完成する。
【００４１】
一方、デコーダ２００は、上記図２に示すように、デマルチプレクサ２０１、同期制御部２０２、ディスクリプタパーサ２０３、ＢＩＦＳデコーダ２０４、メディアデコーダ２０５、ＩＰＭＰコントローラ２０６、及びレンダラ２０７を備えている。
【００４２】
デマルチプレクサ２０１は、エンコーダ１００から送信されてきたビットストリームから、ＩＰＭＰディスクリプタ、ＩＰＭＰ＿ＥＳ、ＯＤ、ＢＩＦＳ、及びＡ／Ｖ（オーディオ／ビデオ）のビットストリーム等の各ディスクリプタ及び各ビットストリームを分離する。
【００４３】
ディスクリプタパーサ２０３は、デマルチプレクサ２０１により得られた各ディスクリプタのそれぞれについて、そのタグ情報によりディスクリプタの種類を判別してディスクリプタの内容を解読し、その解読結果に基づいて、デコーダ２００に必要な各情報を適宜セットする。
メディアデコーダ２０５は、デマルチプレクサ２０１で得られたＡ／Ｖのビットストリーム（イメージやビデオ、オーディオ等のメディアストリーム）をデコードする。
このとき、同期制御部２０２は、メディアデコーダ２０５で処理される各種メディア間の同期を司る。
ＢＩＦＳデコーダ２０４は、デマルチプレクサ２０１で得られたＢＩＦＳのビットストリームをデコードして、ＢＩＦＳの情報に基づいて、メディアデコーダ１１７で得られた各種メディアデータからシーンを再構築する。
【００４４】
レンダラ２０７は、ＢＩＦＳデコーダ２０４により得られたシーン構造に従って各オブジェクトを適宜表示したり再生したりする。
【００４５】
ＩＰＭＰコントローラ２０６は、デマルチプレクサ２０１で得られたＩＰＭＰディスクリプタ及びＩＰＭＰ＿ＥＳに基づいて、メディアデコーダ２０５やレンダラ２０７を制御（メディアの再生制限や効果制御等）する。
例えば、データに暗号がかけられているような場合には、当該暗号を解読してから、メディアデコーダ２０５にデータを転送する。
【００４６】
ここで、本実施の形態の最も特徴とする構成は、上記図１及び図２に示すように、エンコーダ１００とデコーダ２００間のハンドシェイク専用の外部通信路（バック・チャネル）３００を設けた構成にある。
また、エンコーダ１００のＩＰＭＰコントローラ１０３と、デコーダ２００のＩＰＭＰコントローラ２０６とのそれぞれにハンドシェイク機能を持たせている。
【００４７】
そこで、まず、エンコーダ１００のＩＰＭＰコントローラ１０３は、外部通信路３００と接続されており、例えば、ネットワーク上の外部装置（ここでは、デコーダ２００とする）との双方向通信機能を有し、次の機能１〜３を発揮することが可能なように構成されている。
【００４８】
（機能１）
デコーダ２００（受信側）に対して性能情報送信リクエストを外部通信路３００を介して送信することで、デコーダ２００の処理能力に関する情報（性能情報）を外部通信路３００を介して取得し、当該性能情報に基づき、メディアエンコーダ１０２に対して、その符号化レートを外部装置の処理能力に適合するレートとするための制御信号を出力する。
【００４９】
（機能２）
デコーダ２００から、デコーダ２００におけるエラー情報（欠落した受信データに関する情報）を外部通信路３００を介して受信し、又はデコーダ２００でのエラーにより欠落した受信データの再送要求信号を外部通信路３００を介して受信し、当該受信信号に対する任意の処理命令を出力する。
例えば、デコーダ２００からの再送要求信号により示されるデータの再送命令を、メディアエンコーダ１２０に対して出力する。これにより、欠落したデータが補間される。
【００５０】
（機能３）
デコーダ２００に対してビットストリームを送信するための通信路のトラフィックやエラー率に関する情報を外部通信路３００を介してデコーダ２００から受信して、当該情報を総合的に判断して、伝送プロトコルの選択信号を出力する。
【００５１】
例えば、上記機能２により、次のような動作が実現される。
デコーダ２００において、受信したビットストリームのＩＰＭＰ＿ＥＳ（上記図１２参照）の一部（ディスクリプタ・タグ（ＴＡＧ）等）がエラーであった場合、これ以降の情報（ＥＳ１，ＥＳ２等）が正常であっても無効（デコード不能）となるため、ＩＰＭＰコントローラ２０６は、エンコーダ１００のＩＰＭＰコントローラ１０３に対して、ＩＰＭＰ＿ＥＳの再送要求信号を外部通信路３００を介して発信する。
これを受けたエンコーダ１００のＩＰＭＰコントローラ１０３は、デコーダ２００のＩＰＭＰコントローラ２０６からの再送要求信号に対する処理命令（再送命令）を出力する。これにより、メディアエンコーダ１０２は、ＩＰＭＰ＿ＥＳを再送するための処理を行う。
したがって、デコーダ２００に対してＩＰＭＰ＿ＥＳが再送（Ｕｐｄａｔｅ）され、上記エラーによるデコード不能が回避されることになる。
【００５２】
尚、ＩＰＭＰ＿ＥＳの再送方法としては、当該ＩＰＭＰ＿ＥＳを次のビットストリームに結合して再送する方法等が挙げられる。
【００５３】
また、エンコーダ１００のＩＰＭＰコントローラ１０３は、上述したようなＩＰＭＰ＿ＥＳ等の欠落が許されない重要なデータに関しては、ＴＣＰ／ＩＰ等のような伝送速度を犠牲にしても見かけ上がエラーフリーとなる伝送プロトコルを選択し、その他のデータに関しては、伝送速度重視のＲＴＰ等の伝送プロトコルを選択する、という一連のビットストリーム（上記図１１参照）を部分的に異なる複数の伝送プロトコルを使用することも可能なように構成されている。
【００５４】
また、例えば、ＩＰＭＰコントローラ１０３は、ＩＰＭＰ＿ＥＳをＴＣＰ／ＩＰによって伝送し、その他をＲＴＰで固定して伝送するという伝送方式や、通常はビットストリーム全体をＲＴＰで伝送し、上述したようなエラーの発生頻度に応じてＩＰＭＰ＿ＥＳのみ伝送プロトコルをＴＣＰ／ＩＰに変更するという伝送方式をとることも可能なように構成されている。
【００５５】
一方のデコーダ２００のＩＰＭＰコントローラ２０６は、ビットストリームの送信側（ここでは、エンコーダ１００とする）からの要求に対して、デコーダ２００の処理能力に関する情報を、外部通信路３００を介して返信する。
また、ＩＰＭＰコントローラ２０６は、デコーダ２００でエラーが発生した場合、エンコーダ１００に対してエラー発生の通知を外部通信路３００を介して行う。
また、ＩＰＭＰコントローラ２０６は、エンコーダ１００に対して、上記エラー発生に対応したエラー部分の再送要求信号を、外部通信路３００を介して送信する。
【００５６】
上述のように、本実施の形態では、エンコーダ１００とデコーダ２００間に、エンコーダ１００とデコーダ２００間のハンドシェイク専用の外部通信路（バック・チャネル）３００を設け、エンコーダ１００とデコーダ２００のそれぞれにハンドシェイク機能を持たせるように構成したので、デコーダ２００は、デコーダ２００にて発生したエラー（ビットレートの過不足等）をエンコーダ１００へ通知することができ、また、デコーダ２００が有するバッファの空き容量等を通知することもでき、さらにはエンコーダ１００から受信したデータのエラー検出情報やエラー部分の再送要求や、送受信相互のネゴシエーションを行うためのデコーダ２００の処理能力に関する情報等をエンコーダ１００へ送信することができる。一方、エンコーダ１００は、デコーダ２００に対する処理能力情報の要求や、当該要求に対する応答（デコーダ２００の処理能力情報）を受信し、この受信情報に基づいて、ビットレートや伝送プロトコル等の条件を設定したり、デコーダ２００からのエラー情報や特定部分の再送要求を受信して、当該受信情報に基づいて、任意の処理（対処）を行う等の対応をとることができる。
したがって、エンコーダ１００とデコーダ２００間で、ビットストリームの伝送速度を低下させることなく、ビットストリームに含まれる全ての情報を
破綻することなく、ネットワークを介して伝送することができる。
【００５７】
（他の実施の形態）
本発明は、第１の実施の形態に限られることはなく、次のような実施の形態（１）〜（４）にも含まれる。
【００５８】
（１）第１の実施の形態において、エンコーダ１００のＩＰＭＰコントローラ１０３による複数の伝送プロトコルの中からの実際に用いる伝送プロトコルの選択については、例えば、ビットストリームを構成する各パケットのヘッダ部に優先度を設定し、当該優先度に基づいて、複数の伝送プロトコルの中から実際に用いる伝送プロトコルを選択するように構成してもよい。
この場合、エンコーダ１００のＩＰＭＰコントローラ１０３は、図３に示すように、ビットストリームを構成する各パケットのそれぞれについてそのヘッダ部にパケット内容に応じて優先度を設定する優先度設定部１１２と、優先度設定部１１２を介したビットストリームを構成する各パケットのヘッダ部に設定された優先度に基づき複数の伝送プロトコル１１１（１），１１１（２），…，１１１（ｎ）…の中から１つの伝送プロトコルを選択するプロトコル選択部１１３とを備えることになる。
【００５９】
（２）例えば、デコーダ２００のＩＰＭＰコントローラ２０６の構成を、図４に示すように、受信ビットストリームのエラー発生頻度（エラー率）を管理するエラー管理部２２１と、受信ビットストリームに関するビットレート（単位時間あたりの符号量又はその変化）を管理するレート管理部２２２と、エラー管理部２２１及びレート管理部２２２の管理情報をエンコーダ１００に対して外部通信部３００を介して送信したり、エラー管理部２２１及びレート管理部２２２の管理情報に基づきビットストリームの任意の一部分に対する伝送プロトコルを変更又は指定するためのリクエスト情報（指定情報）をエンコーダ１００に対して外部通信部３００を介して送信したりする送信部２２３とを備える構成とし、エンコーダ１００のプロトコル選択部１１３（上記図３参照）が、デコーダ２００のリクエスト送信部２２３からのリクエスト情報に基づき複数の伝送プロトコル１１１（１），１１１（２），…，１１１（ｎ）…の中から１つの伝送プロトコルを選択するように構成してもよい。
【００６０】
具体的には、デコーダ２００のＩＰＭＰコントローラ２０６の構成が上記図４の構成である場合、エンコーダ１００は、例えば、図５に示すフローチャートに従って動作することになる。
【００６１】
先ず、ＩＰＭＰコントローラ１０３は、デコーダ２００からのデータの受信があるか否か、当該受信があれば当該受信情報がコンディション情報（エラー率の情報や、再送要求等）であるか指定情報（伝送プロトコルの指定の情報）であるかを判別する（ステップＳ３０１）。
この判別の結果、受信無しの場合は次のステップＳ３０２に進み、指定情報が受信された場合は後述するステップＳ３０３へ進み、コンディション情報が受信入力された場合は後述するステップＳ３０５へ進む。
【００６２】
ステップＳ３０１の判別の結果、デコーダ２００からのデータの受信が無い場合、ＩＰＭＰコントローラ１０３は、複数の伝送プロトコルの中から、デコーダ２００へのビットストリームの伝送に用いる伝送プロトコルとして、デフォルトの伝送プロトコルを選択して設定する（ステップＳ３０２）。
その後、後述するステップＳ３１０へ進む。
【００６３】
ステップＳ３０１の判別の結果、デコーダ２００からの指定情報が受信された場合、ＩＰＭＰコントローラ１０３は、当該指定情報に従って、デコーダ２００へ伝送するビットストリームを分割し（ステップＳ３０３）、当該分割データ毎に、複数の伝送プロトコルの中から該当する伝送プロトコルを選択して設定する（ステップＳ３０４）。
その後、後述するステップＳ３１０へ進む。
【００６４】
ステップＳ３０１の判別の結果、デコーダ２００からのコンディション情報が受信された場合、ＩＰＭＰコントローラ１０３は、当該コンディション情報が、エラー率情報であるか再送要求であるかを判別する（ステップＳ３０５）。
この判別の結果、エラー率情報である場合には次のステップＳ３０６へ進み、再送要求である場合には後述するステップＳ３０７へ進む。
【００６５】
ステップＳ３０５の判別の結果、エラー率情報である場合、ＩＰＭＰコントローラ１０３は、当該エラー率（ＥｒｒｏｒＲａｔｅ）が、予め設定されたしきい値（ＴＨ）よりも大きいか否かを判別する（ステップＳ３０６）。
この判別の結果、「ＥｒｒｏｒＲａｔｅ＞ＴＨ」である場合、上述したステップＳ３０３へ進み、「ＥｒｒｏｒＲａｔｅ＞ＴＨ」でない場合、上述したステップＳ３０２へ進む。
【００６６】
ステップＳ３０５の判別の結果、再送要求である場合、ＩＰＭＰコントローラ１０３は、当該再送要求により示されるデータを再度取得し（ステップＳ３０７）、当該データをビットストリームに組み込む（ステップＳ３０８）。
そして、ＩＰＭＰコントローラ１０３は、ステップＳ３０８での再送用のデータの伝送プロトコルとして、複数の伝送プロトコルの中から該当する伝送プロトコルを選択して設定する（ステップＳ３０９）。
その後、次のステップＳ３１０へ進む。
【００６７】
ステップＳ３１０では、ステップＳ３０２、又はステップＳ３０４、又はステップＳ３０９にて設定された伝送プロトコルに従ったビットストリームの送信が行われる。
【００６８】
（３）第１の実施の形態では、エンコーダ１００に対する各種要求をデコーダ２００としているが、これに限られることはなく、任意の外部からの要求であってもよい。
【００６９】
（４）例えば、図６に示すように、エンコーダ１００に端末装置１０９を更に設けると共に、図７に示すように、デコーダ２００に端末装置２０９を更に設ける構成としてもよい。
この場合、エンコーダ１００のＩＰＭＰコントローラ１０３は、端末装置１０９からの入力に従って動作し、デコーダ２００のＩＰＭＰコントローラ２０６も同様に端末装置２０９からの入力に従って動作することになる。
【００７０】
尚、本発明の目的は、第１及び他の実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が第１及び他の実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
また、コンピュータが読みだしたプログラムコードを実行することにより、第１及び他の実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって第１及び他の実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって第１及び他の実施の形態の機能が実現される場合も含まれることは言うまでもない。
【００７１】
図８は、上記コンピュータ９００の構成の一例を示したものである。
コンピュータ９００は、上記図８に示すように、ＣＰＵ９０１と、ＲＯＭ９０２と、ＲＡＭ９０３と、キーボード（ＫＢ）９０９のキーボードコントローラ（ＫＢＣ）９０５と、表示部としてのＣＲＴディスプレイ（ＣＲＴ）９１０のＣＲＴコントローラ（ＣＲＴＣ）９０６と、ハードディスク（ＨＤ）９１１及びフロッピーディスク（ＦＤ）９１２のディスクコントローラ（ＤＫＣ）９０７と、インターネット等のネットワーク９２０を介した伝送を行うためのネットワークインターフェースカード（ＮＩＣ）９０８とが、システムバス９０４を介して互いに通信可能に接続された構成としている。
【００７２】
ＣＰＵ９０１は、ＲＯＭ９０２或いはＨＤ９１１に記憶されたソフトウェア、或いはＦＤ９１２より供給されるソフトウェアを実行することで、システムバス９０４に接続された各構成部を総括的に制御する。
すなわち、ＣＰＵ９０１は、所定の処理プログラムを、ＲＯＭ９０２、或いはＨＤ９１１、或いはＦＤ９１２から読み出して実行することで、上述した第１及び他の実施の形態での動作を実施するための制御を行う。
【００７３】
ＲＡＭ９０３は、ＣＰＵ９０１の主メモリ或いはワークエリア等として機能する。
ＫＢＣ９０５は、ＫＢ９０９や図示していないポインティングデバイス等からの指示入力を制御する。
ＣＲＴＣ９０６は、ＣＲＴ９１０の表示を制御する。
ＤＫＣ９０７は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、及び上記処理プログラム等を記憶するＨＤ９１１及びＦＤ９１２とのアクセスを制御する。
ＮＩＣ９０８は、ネットワーク９２０上の各種装置或はシステムと双方向にデータをやりとりする。
【００７４】
【発明の効果】
以上説明したように本発明では、送信側と受信側間で、符号化データの伝送用の通信路（第１の通信路）とは異なる第２の通信路（送信側と受信側間のハンドシェイク専用のバックチャネル等）を介して、符号化データの伝送に関する情報を送受信するように構成した。
これにより、例えば、受信側は、受信側で発生したエラー（ビットレートの過不足等）を送信側へ通知することがき、また、受信側が有するバッファの空き容量等を通知することもでき、さらには送信側から受信した符号化データのエラー検出情報やエラー部分の再送要求や、送受信相互のネゴシエーションを行うための受信側の処理能力に関する情報等を送信側へ送信することができる。また、送信側は、受信側に対する処理能力情報の要求や、当該要求に対する応答（受信側の処理能力情報）を受信し、この受信情報に基づいて、ビットレートや伝送プロトコル等の条件を設定したり、受信側からのエラー情報や特定部分の再送要求を受信して、当該受信情報に基づいて、任意の処理（対処）を行う等の対応をとることができる。
したがって、本発明によれば、例えば、ＭＰＥＧ−４に於いてエラー訂正機能を持たないＩＰＭＰ＿ＥＳにエラーが生じた場合でも、第２の通信路としてのバックチャネルという双方向専用回線等を用いて、伝送プロトコルの選択やエラーデータの再送要求等が可能となるため、伝送速度を著しく低下させることなしに、ビットストリームに含まれる全データを第１の通信路（任意のネットワーク等）を介して破綻なしに伝送することが可能となる。
【図面の簡単な説明】
【図１】第１の実施の形態において、本発明を適用したエンコーダ（送信側）の構成を示すブロック図である。
【図２】第１の実施の形態において、本発明を適用したデコーダ（受信側）の構成を示すブロック図である。
【図３】他の実施の形態（１）において、上記エンコーダの主な構成の一例を示すブロック図である。
【図４】他の実施の形態（２）において、上記デコーダの主な構成の一例を示すブロック図である。
【図５】他の実施の形態（２）において、上記エンコーダの動作の一例を説明するための図ローチャートである。
【図６】他の実施の形態（４）において、上記エンコーダの構成を示すブロック図である。
【図７】他の実施の形態（４）において、上記デコーダの構成を示すブロック図である。
【図８】第１及び他の実施の形態の機能を実施するための処理プログラムを実行するコンピュータの構成の一例を示すブロック図である。
【図９】「ＩＳＯ／ＩＥＣ１４４９６（ＭＰＥＧｐｈａｓｅ４）」規格でのシーンの一例を説明するための図である。
【図１０】上記規格に準拠したビットストリームの一例を説明するための図である。
【図１１】上記ビットストリームのセキュリティ情報（ＩＰＭＰ）を説明するための図である。
【図１２】上記ＩＰＭＰディスクリプタを説明するための図である。
【図１３】従来のエンコーダの構成を示すブロック図である。
【図１４】従来のデコーダの構成を示すブロック図である。
【符号の説明】
１００エンコーダ
１０１オブジェクトディスクリプタ（ＯＤ）生成部
１０２メディアエンコーダ
１０３ＩＰＭＰコントローラ
１０４ＢＩＦＳエンコーダ
１０５アップデートコントローラ
１０６マルチプレクサ
２００デコーダ
２０１デマルチプレクサ
２０２同期制御部
２０３ディスクリプタパーサ
２０４ＢＩＦＳデコーダ
２０５メディアデコーダ
２０６ＩＰＭＰコントローラ
２０７レンダラ
３００外部通信部（バックチャネル）[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data processing apparatus, a data processing method, and a computer-readable recording medium, and more particularly to transmission processing or reception processing of encoded data.
[0002]
[Prior art]
In recent years, for example, in the “ISO / IEC 14496 (MPEG phase 4)” standard, standardization of multimedia encoding (standardization of compression format) has been advanced.
[0003]
In this standard, in addition to the conventional encoding of video data and audio data, it is possible to define the space and temporal arrangement of each medium. This is called a “scene description”, and each medium is called “ It is called “object”.
[0004]
FIG. 9 shows an example of a scene in this standard.
In FIG. 9, a BOX (box) 401 and a cylinder (cylinder) 402 are defined as graphic objects. In addition, an image texture 401a to be pasted on the BOX 401, a video texture 402a to be pasted on the Cylinder 402, and an audio 403 to be played back simultaneously are defined.
[0005]
As a method of the scene description itself, for example, BIFS (Binary Format for Scene description) that has been expanded and binarized based on VRML (Virtual Reality Markup Language) is adopted.
[0006]
Further, in this standard, apart from the scene description as shown in FIG. 9, data indicating the attribute of each object, which is called an object descriptor (hereinafter referred to as “OD”), is defined.
Here, the attributes indicate media attributes (video, audio, image, etc.), copyright holder information, QoS (Quality Of Service) information, content rating information, and the like.
Such attributes themselves are included in the OD as individual descriptors.
[0007]
FIG. 10 shows an example of the entire bit stream according to this standard. In FIG. 10, “501” is an initial object descriptor and stores the properties of the entire bitstream (bitstream profile and the like).
“502” is a BIFS stream in which scene information is stored.
[0008]
“503” and “506” are ODs, and the bit stream in FIG. 10 has two OD1 (503) and OD2 (506).
After OD503 and 506, the attribute of the object is described. That is, following OD1 (503) and OD2 (506), there are elementary stream descriptors (hereinafter referred to as “ESD”) indicating attributes of the respective media streams (hereinafter also referred to as “elementary streams”) ES1 and ES2. Multiple descriptions are possible.
In FIG. 10, ESD1 (504) is described after OD1 (503), and ESD2 (507) is described after OD2 (506).
[0009]
Also, since the elementary streams ES1 and ES2 are actually packetized and handled as “Sync Layer Packet” (hereinafter referred to as “SL packet”), the structure of the SL packet is shown in FIG. SLCConfig descriptors 505 and 508 for describing the above are added to each of ESD1 (504) and ESD2 (507).
[0010]
Each of the OD and ESD descriptors described above must be placed at the head of each of the elementary streams ES1 and ES2 in the bitstream shown in FIG.
However, OD and ESD can be added, deleted, and changed by inserting an update command in the middle of the bitstream.
[0011]
In this standard, security information such as copyright management information and access control information can be added for each OD and ES. This information is called IPMP (Intellectual Property Management and Protection) information.
Details of the IPMP information are also described in a descriptor called an IPMP descriptor.
In practice, encryption is often used for access control, but the IPMP method (descriptor syntax) is not specified and is a free syntax. Also, only the IPMP security type number registered in RA (Registration Authority) is described.
[0012]
The IPMP information itself described by the IPMP descriptor can be linked with an IPMP security type number to add an IPMP elementary stream ES (hereinafter referred to as “IPMP-ES”). Yes.
FIG. 11 shows an example of the entire bit stream in this case.
In FIG. 11, IPMP1 (510) and IPMP2 (512) are IPMP-ES for the elementary streams ES1 (509) and ES2 (511), respectively.
[0013]
FIG. 12 shows an example of the IPMP descriptor.
In FIG. 12, “601” is a descriptor tag (TAG) indicating the type of descriptor.
“602” is a length field (LENGTH) and indicates the length (number of bytes) of the entire descriptor.
“603” is a descriptor ID, and an identifier of the descriptor itself is stored.
“604” is the above-described security type number (IPMPS_type).
“605” is an option field (Option), in which data accompanying IPMP can be appropriately inserted. Also, the syntax in the option field 605 is free. The accompanying data can also be indicated by a URL in the option field 605.
[0014]
The IPMP descriptor described above also needs to be placed at the head of each elementary stream ES1, ES2 in the bitstream shown in FIG.
However, IPMP descriptors can be added, deleted, and changed by inserting an update command in the middle of the bitstream.
FIG. 11 shows an example of a bitstream including one command 513 for updating IPMP information.
[0015]
FIG. 13 shows an example of an encoder 700 for generating a bitstream as described above.
In FIG. 13, “701” is an object descriptor generator, which appropriately generates the descriptor as described above according to the property of the bit stream.
“702” is a media encoder that encodes data such as video and audio.
“703” is an IPMP controller.
“704” is a BIFS encoder, which binarizes scene information.
“705” is an update controller provided as necessary, and inserts a command for updating properties such as OD, ESD, and IPMP descriptors.
“706” is a multiplexer, and each descriptor and media stream are finally multiplexed as one SL packet.
[0016]
FIG. 14 shows an example of a decoder 800 that decodes (reproduces) the bit stream obtained by the encoder 700 of FIG.
In FIG. 14, “801” is a demultiplexer that separates each descriptor, ES, and the like from the input bit stream.
“803” is a descriptor parser, which determines the type of the descriptor based on the tag information of the descriptor, decodes the content of the descriptor, and appropriately sets the descriptor.
“804” is a BIFS decoder, which decodes the binarized BIFS and reconstructs the scene structure.
“805” is a media decoder, which decodes a media decoder such as video, audio, or image.
“807” is a renderer that appropriately displays or reproduces each object according to the scene structure.
“806” is an IPMP controller, which performs media playback control (playback restriction, effect control, etc.) according to the information of the IPMP descriptor and IPMP_ES. For example, when the data is encrypted, the data is transferred to the media decoder 805 after the encryption is decrypted.
“802” is a synchronization controller that performs synchronization control between media.
[0017]
Note that the data transfer method from the encoder 700 side in FIG. 13 to the decoder 800 side in FIG. 14 is not specifically mentioned. However, in the case of transmission on a network, all data is transmitted and received as one bit stream in the same session. It is common to be done.
[0018]
[Problems to be solved by the invention]
However, when data is transmitted from the conventional encoder 700 shown in FIG. 13 to the conventional decoder (regenerator) 800 shown in FIG. Since the bit stream is transmitted in the same session and there is no other communication path or communication means other than the communication path or communication means of the bit stream, the capability of the decoder 800 on the bit stream receiving side (reception is possible) (Determination of processing capacity represented by the upper limit of the bit rate), notification of defects caused by errors in the transmission process, bit stream retransmission request, communication channel or communication means traffic changing at any time on the decoder 800 side. Notification of malfunctions such as buffer underruns, requests for retransmission, etc. Theft was impossible.
In addition, since the IPMP_ES including the above-described IPMP descriptor does not have an error correction function, when an error occurs in IPMP_ES (see FIG. 12 above) associated with any paid content (paid media data such as video or audio), There is a fatal problem that all data after the IPMP descriptor becomes invalid and this state continues until the next IPMP descriptor is received.
[0019]
Accordingly, the present invention is made to eliminate the above-mentioned drawbacks, and is configured so that requests and responses generated in the data transmission can be performed between the data transmission side and the data reception side together with the data transmission. SUMMARY OF THE INVENTION An object of the present invention is to provide a data processing apparatus capable of efficient data transmission, a data processing method, and a storage medium in which processing steps for implementing the data are stored in a computer-readable manner.
[0020]
[Means for Solving the Problems]
Under such a purpose, the data processing method according to the present invention includes a series of bit streams obtained by concatenating encoded data, each of which is divided into arbitrary sizes, and a header including arbitrary specific information related to the encoded data. A data processing method for transmitting the bitstream via a first communication path, wherein at least information relating to the transmission of the bitstream is received from a receiving side via a second communication path; And a control step of controlling transmission of the bit stream based on the reception information obtained by the reception step.
[0021]
Further, the data processing method of the present invention is configured such that an arbitrary bit stream including at least one or more mutually encoded data is included in the first communication path by an arbitrary transmission protocol among the plurality of transmission protocols. Is a data processing method for independently decoding a plurality of mutually independent encoded data, wherein at least information relating to transmission of the bitstream is transmitted via a second communication path. A transmission step of transmitting to the transmission side of the bit stream is included.
[0022]
The data processing method of the present invention is a data processing method for transmitting a continuous bit stream by an arbitrary transmission protocol among a plurality of mutually different transmission protocols, wherein an arbitrary area of the bit stream is defined. A transmission step of encoding and transmitting according to an arbitrary transmission protocol, and changing a transmission protocol of an arbitrary part in the bitstream according to information received from the outside via a communication path independent of the communication path of the bitstream A changing step and a retransmission step of retransmitting the already transmitted portion of the bitstream by combining it with the next bitstream according to the information received from the outside.
[0023]
Further, the data processing apparatus of the present invention comprises a series of bitstreams by concatenating encoded data each divided into an arbitrary size and a header including arbitrary specific information related to the encoded data, A data processing apparatus for transmitting the bitstream via a first communication path, wherein at least information relating to transmission of the bitstream is received from a receiving side via a second communication path, and the receiving means And control means for controlling the transmission of the bit stream based on the reception information obtained by the above.
[0024]
In addition, the data processing apparatus of the present invention uses the arbitrary transmission protocol among the plurality of transmission protocols to transmit an arbitrary bit stream containing a plurality of mutually independent encoded data to the first communication path. Receiving means for receiving via the decoding means, decoding means for independently decoding the plurality of mutually independent encoded data in the bitstream received by the receiving means, and at least information relating to transmission of the bitstream Transmission means for transmitting to the transmission side of the bit stream via two communication paths.
[0025]
The data processing apparatus of the present invention is a data processing apparatus for transmitting a continuous bit stream by an arbitrary transmission protocol among a plurality of mutually different transmission protocols, wherein an arbitrary area of the bit stream is recorded. Transmission means for encoding and transmitting in accordance with an arbitrary transmission protocol, and changing the transmission protocol of an arbitrary part in the bitstream according to information received from the outside via a communication path independent of the communication path of the bitstream And changing means and resending means for retransmitting the already transmitted portion of the bitstream by combining it with the next bitstream according to the information received from the outside.
[0034]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0035]
(First embodiment)
The present invention is applied to, for example, a data processing system including an encoder 100 as shown in FIG. 1 and a decoder 200 as shown in FIG.
The data processing system according to the present embodiment is configured to perform data transmission in accordance with the “ISO / IEC 14496 (MPEG phase 4)” standard as described with reference to FIGS.
In the present embodiment, as an example, the data transmission method from the encoder 100 to the decoder 200 is arbitrary, and when transmitting via a network, all are transmitted as one bit stream in the same session. Shall.
[0036]
The encoder 100 includes an OD generation unit 101, a media encoder 102, an IPMP control unit 103, a BIFS encoder 104, an update controller 105, and a multiplexer 106, as shown in FIG.
[0037]
The media encoder 102 encodes (compresses) media data (contents) such as images, video, audio, and other multimedia and outputs the encoded data.
The OD generation unit 101 encodes attribute information of media data to be processed by the media encoder 102, and outputs the encoded data as OD. The BIFS encoder 104 encodes and outputs information of a scene (see FIG. 4 above) composed of media data to be processed by the media encoder 105.
[0038]
The IPMP controller 103 generates security information such as an IPMP descriptor and IPMP_ES for various media data (contents) encoded by the media encoder 102 and independently performs encryption processing on the content.
Note that this is not the case when copyright protection is not required for the content handled by the media encoder 102.
[0039]
The update controller 105 is an update controller provided as necessary, and inserts a command for updating properties such as OD, ESD, and IPMP descriptors into the bitstream.
[0040]
The multiplexer 106 multiplexes the outputs of the OD generation unit 101, the BIFS encoder 104, the IPMP control unit 103, and the media encoder 102, and combines them into one bit stream as shown in FIG. 10 or FIG. Output.
At this time, the multiplexer 106 also performs synchronization control of data to be multiplexed. Specifically, for example, a type stamp or a clock reference is embedded in a packet of a bit stream. This completes the SL packetized bitstream.
[0041]
On the other hand, the decoder 200 includes a demultiplexer 201, a synchronization control unit 202, a descriptor parser 203, a BIFS decoder 204, a media decoder 205, an IPMP controller 206, and a renderer 207, as shown in FIG.
[0042]
The demultiplexer 201 separates each descriptor and each bitstream such as an IPMP descriptor, IPMP_ES, OD, BIFS, and A / V (audio / video) bitstream from the bitstream transmitted from the encoder 100.
[0043]
For each descriptor obtained by the demultiplexer 201, the descriptor parser 203 determines the type of descriptor based on the tag information and decodes the contents of the descriptor. Based on the decoding result, each piece of information necessary for the decoder 200 is obtained. Set as appropriate.
The media decoder 205 decodes the A / V bit stream (media stream of an image, video, audio, etc.) obtained by the demultiplexer 201.
At this time, the synchronization control unit 202 controls synchronization between various media processed by the media decoder 205.
The BIFS decoder 204 decodes the BIFS bit stream obtained by the demultiplexer 201 and reconstructs a scene from various media data obtained by the media decoder 117 based on the BIFS information.
[0044]
The renderer 207 displays or reproduces each object as appropriate according to the scene structure obtained by the BIFS decoder 204.
[0045]
The IPMP controller 206 controls the media decoder 205 and the renderer 207 based on the IPMP descriptor and IPMP_ES obtained by the demultiplexer 201 (media playback restriction, effect control, etc.).
For example, when the data is encrypted, the data is transferred to the media decoder 205 after the encryption is decrypted.
[0046]
Here, the most characteristic configuration of the present embodiment is a configuration in which an external communication path (back channel) 300 dedicated for handshaking between the encoder 100 and the decoder 200 is provided as shown in FIGS. It is in.
Each of the IPMP controller 103 of the encoder 100 and the IPMP controller 206 of the decoder 200 has a handshake function.
[0047]
Therefore, first, the IPMP controller 103 of the encoder 100 is connected to the external communication path 300, and has, for example, a bidirectional communication function with an external device on the network (here, the decoder 200). It is comprised so that the functions 1-3 can be exhibited.
[0048]
(Function 1)
By transmitting a performance information transmission request to the decoder 200 (reception side) via the external communication path 300, information (performance information) regarding the processing capability of the decoder 200 is acquired via the external communication path 300, and the performance Based on the information, a control signal is output to the media encoder 102 so that the encoding rate matches the processing capability of the external device.
[0049]
(Function 2)
Error information in the decoder 200 (information regarding missing received data) is received from the decoder 200 via the external communication path 300, or a retransmission request signal for received data that is missing due to an error in the decoder 200 is received via the external communication path 300. And outputs an arbitrary processing command for the received signal.
For example, a data retransmission command indicated by a retransmission request signal from the decoder 200 is output to the media encoder 120. Thereby, the missing data is interpolated.
[0050]
(Function 3)
Information on the communication path traffic and error rate for transmitting the bit stream to the decoder 200 is received from the decoder 200 via the external communication path 300, and the information is comprehensively determined to select a transmission protocol. Output a signal.
[0051]
For example, the following operation is realized by the function 2 described above.
In the decoder 200, when a part of the IPMP_ES (see FIG. 12) of the received bitstream (descriptor tag (TAG), etc.) is an error, the subsequent information (ES1, ES2, etc.) is normal. Therefore, the IPMP controller 206 transmits an IPMP_ES retransmission request signal to the IPMP controller 103 of the encoder 100 via the external communication path 300.
Upon receiving this, the IPMP controller 103 of the encoder 100 outputs a processing command (retransmission command) for the retransmission request signal from the IPMP controller 206 of the decoder 200. Thereby, the media encoder 102 performs a process for retransmitting the IPMP_ES.
Therefore, IPMP_ES is retransmitted (updated) to the decoder 200, and the inability to decode due to the error is avoided.
[0052]
An IPMP_ES retransmission method includes a method of retransmitting the IPMP_ES by combining it with the next bit stream.
[0053]
In addition, the IPMP controller 103 of the encoder 100 transmits a transmission protocol that is apparently error-free at the expense of transmission speed, such as TCP / IP, with respect to important data that is not allowed to be lost, such as IPMP_ES as described above. For other data, it is also possible to use a plurality of transmission protocols that are partially different from each other in a series of bitstreams (see FIG. 11 above) in which a transmission protocol such as RTP that emphasizes transmission speed is selected. It is configured as follows.
[0054]
In addition, for example, the IPMP controller 103 transmits IPMP_ES by TCP / IP and transmits the others fixed by RTP, or normally transmits the entire bitstream by RTP, and the above-described error occurs. It is also possible to adopt a transmission method in which only the IPMP_ES is changed to TCP / IP according to the frequency.
[0055]
The IPMP controller 206 of one decoder 200 returns information regarding the processing capability of the decoder 200 via the external communication path 300 in response to a request from the transmission side of the bitstream (here, the encoder 100).
Further, when an error occurs in the decoder 200, the IPMP controller 206 notifies the encoder 100 of the error occurrence via the external communication path 300.
Also, the IPMP controller 206 transmits an error part retransmission request signal corresponding to the error occurrence to the encoder 100 via the external communication path 300.
[0056]
As described above, in the present embodiment, an external communication path (back channel) 300 dedicated for handshaking between the encoder 100 and the decoder 200 is provided between the encoder 100 and the decoder 200, and each of the encoder 100 and the decoder 200 is provided. Since the decoder 200 is configured to have a handshake function, the decoder 200 can notify the encoder 100 of an error (such as an excess or deficiency in the bit rate) that has occurred in the decoder 200, and a buffer available in the decoder 200 is available. The capacity can be notified, and further, error detection information of the data received from the encoder 100, a retransmission request for the error part, information on the processing capability of the decoder 200 for performing negotiation between transmission and reception, and the like are transmitted to the encoder 100. can do. On the other hand, the encoder 100 receives a request for processing capability information to the decoder 200 and a response to the request (processing capability information of the decoder 200), and sets conditions such as a bit rate and a transmission protocol based on the received information. Or receiving error information from the decoder 200 or a retransmission request for a specific part, and taking an appropriate process (coping) based on the received information.
Therefore, all the information included in the bit stream can be transmitted between the encoder 100 and the decoder 200 without reducing the bit stream transmission speed.
It can be transmitted over the network without failure.
[0057]
(Other embodiments)
The present invention is not limited to the first embodiment, and is also included in the following embodiments (1) to (4).
[0058]
(1) In the first embodiment, the IPMP controller 103 of the encoder 100 selects a transmission protocol to be actually used from among a plurality of transmission protocols. For example, priority is given to the header portion of each packet constituting the bit stream. It is also possible to set a degree and select a transmission protocol to be actually used from a plurality of transmission protocols based on the priority.
In this case, the IPMP controller 103 of the encoder 100 includes, as shown in FIG. 3, a priority setting unit 112 that sets a priority for each packet constituting the bitstream in the header portion according to the packet contents, 1 out of a plurality of transmission protocols 111 (1), 111 (2),..., 111 (n)... Based on the priority set in the header part of each packet constituting the bit stream via the degree setting unit 112. And a protocol selection unit 113 for selecting one transmission protocol.
[0059]
(2) For example, as shown in FIG. 4, the configuration of the IPMP controller 206 of the decoder 200 includes an error management unit 221 that manages the error occurrence frequency (error rate) of the received bitstream, and the bit rate (unit) A rate management unit 222 that manages a code amount per time or a change thereof), and management information of the error management unit 221 and the rate management unit 222 is transmitted to the encoder 100 via the external communication unit 300, or an error management unit Request information (designation information) for changing or designating a transmission protocol for an arbitrary part of the bitstream based on the management information of 221 and the rate management unit 222 is transmitted to the encoder 100 via the external communication unit 300. A transmission unit 223, and a prototype of the encoder 100 1 is selected from the plurality of transmission protocols 111 (1), 111 (2),..., 111 (n)... Based on the request information from the request transmission unit 223 of the decoder 200. One transmission protocol may be selected.
[0060]
Specifically, when the configuration of the IPMP controller 206 of the decoder 200 is the configuration shown in FIG. 4, the encoder 100 operates according to the flowchart shown in FIG. 5, for example.
[0061]
First, the IPMP controller 103 determines whether or not data has been received from the decoder 200, and if there is such reception, specifies whether the received information is condition information (error rate information, retransmission request, etc.) or designation information (transmission protocol). In step S301).
As a result of the determination, if there is no reception, the process proceeds to the next step S302. If the designation information is received, the process proceeds to step S303 described later. If the condition information is received and input, the process proceeds to step S305 described later.
[0062]
As a result of the determination in step S301, when no data is received from the decoder 200, the IPMP controller 103 selects a default transmission protocol as a transmission protocol used for transmitting a bit stream to the decoder 200 from a plurality of transmission protocols. Select and set (step S302).
Then, it progresses to step S310 mentioned later.
[0063]
When the designation information from the decoder 200 is received as a result of the determination in step S301, the IPMP controller 103 divides the bit stream to be transmitted to the decoder 200 according to the designation information (step S303), and for each piece of the divided data, A corresponding transmission protocol is selected from a plurality of transmission protocols and set (step S304).
Then, it progresses to step S310 mentioned later.
[0064]
If the condition information from the decoder 200 is received as a result of the determination in step S301, the IPMP controller 103 determines whether the condition information is error rate information or a retransmission request (step S305).
As a result of the determination, if it is error rate information, the process proceeds to the next step S306, and if it is a retransmission request, the process proceeds to step S307 described later.
[0065]
If the error rate information is the error rate information as a result of the determination in step S305, the IPMP controller 103 determines whether the error rate (ErrorRate) is larger than a preset threshold value (TH) (step S306). .
As a result of the determination, if “ErrorRate> TH”, the process proceeds to step S303 described above, and if not “ErrorRate> TH”, the process proceeds to step S302 described above.
[0066]
If the result of determination in step S305 is a retransmission request, the IPMP controller 103 obtains again the data indicated by the retransmission request (step S307) and incorporates the data into the bitstream (step S308).
Then, the IPMP controller 103 selects and sets a corresponding transmission protocol from a plurality of transmission protocols as the transmission protocol of the data for retransmission in step S308 (step S309).
Thereafter, the process proceeds to the next step S310.
[0067]
In step S310, a bit stream is transmitted according to the transmission protocol set in step S302, step S304, or step S309.
[0068]
(3) In the first embodiment, various requests for the encoder 100 are the decoder 200, but the present invention is not limited to this, and may be requests from any outside.
[0069]
(4) For example, as shown in FIG. 6, the encoder 100 may be further provided with a terminal device 109, and the decoder 200 may be further provided with a terminal device 209 as shown in FIG. 7.
In this case, the IPMP controller 103 of the encoder 100 operates in accordance with the input from the terminal device 109, and the IPMP controller 206 of the decoder 200 also operates in accordance with the input from the terminal device 209.
[0070]
An object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the host and terminal according to the first and other embodiments to a system or apparatus, and a computer ( Needless to say, this can also be achieved by the CPU or MPU) reading and executing the program code stored in the storage medium.
In this case, the program code itself read from the storage medium realizes the functions of the first and other embodiments, and the storage medium storing the program code constitutes the present invention.
A ROM, floppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, nonvolatile memory card, or the like can be used as a storage medium for supplying the program code.
Further, by executing the program code read by the computer, not only the functions of the first and other embodiments are realized, but also an OS or the like running on the computer based on the instruction of the program code Needless to say, the present invention includes a case where the functions of the first and other embodiments are realized by performing part or all of the actual processing.
Further, after the program code read from the storage medium is written to the memory provided in the extension function board inserted in the computer or the function extension unit connected to the computer, the function extension is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the functions of the first and other embodiments are realized by the processing.
[0071]
FIG. 8 shows an example of the configuration of the computer 900.
As shown in FIG. 8, the computer 900 includes a CPU 901, a ROM 902, a RAM 903, a keyboard controller (KBC) 905 of a keyboard (KB) 909, and a CRT controller (CRTC) of a CRT display (CRT) 910 as a display unit. ) 906, a disk controller (DKC) 907 of a hard disk (HD) 911 and a floppy disk (FD) 912, and a network interface card (NIC) 908 for performing transmission via a network 920 such as the Internet. A configuration in which communication is possible with each other via the network 904 is employed.
[0072]
The CPU 901 generally controls each component connected to the system bus 904 by executing software stored in the ROM 902 or the HD 911 or software supplied from the FD 912.
That is, the CPU 901 performs control for performing the operations in the first and other embodiments described above by reading a predetermined processing program from the ROM 902, the HD 911, or the FD 912 and executing it.
[0073]
The RAM 903 functions as a main memory or work area for the CPU 901.
The KBC 905 controls an instruction input from the KB 909 or a pointing device (not shown).
The CRTC 906 controls the display of the CRT 910.
The DKC 907 controls access to the HD 911 and the FD 912 that store a boot program, various applications, an edit file, a user file, a network management program, the processing program, and the like.
The NIC 908 exchanges data bidirectionally with various devices or systems on the network 920.
[0074]
【The invention's effect】
As described above, in the present invention, the second communication path (the hand between the transmission side and the reception side) different from the communication path (first communication path) for transmitting the encoded data between the transmission side and the reception side. Information related to transmission of encoded data is transmitted / received via a back channel dedicated to shaking.
As a result, for example, the receiving side can notify the transmitting side of errors (such as excess or deficiency in bit rate) that occurred on the receiving side, and can also notify the buffer capacity of the receiving side, etc. Can transmit error detection information of encoded data received from the transmission side, a retransmission request of an error part, information on processing capability of the reception side for performing negotiation between transmission and reception, and the like to the transmission side. In addition, the transmission side receives a request for processing capability information to the receiving side and a response to the request (processing capability information on the receiving side), and sets conditions such as a bit rate and a transmission protocol based on this reception information. Or receiving error information from the receiving side or a retransmission request for a specific part, and taking an appropriate process (coping) based on the received information.
Therefore, according to the present invention, for example, even when an error occurs in IPMP_ES that does not have an error correction function in MPEG-4, a bidirectional dedicated line such as a back channel as the second communication path is used. Since it is possible to select a transmission protocol and request retransmission of error data, all data contained in the bitstream fails via the first communication path (arbitrary network, etc.) without significantly reducing the transmission speed. Without transmission.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of an encoder (transmission side) to which the present invention is applied in a first embodiment.
FIG. 2 is a block diagram showing a configuration of a decoder (receiving side) to which the present invention is applied in the first embodiment.
FIG. 3 is a block diagram showing an example of a main configuration of the encoder in another embodiment (1).
FIG. 4 is a block diagram showing an example of a main configuration of the decoder in another embodiment (2).
FIG. 5 is a flowchart for explaining an example of the operation of the encoder in another embodiment (2).
FIG. 6 is a block diagram showing a configuration of the encoder in another embodiment (4).
FIG. 7 is a block diagram showing a configuration of the decoder in another embodiment (4).
FIG. 8 is a block diagram illustrating an example of a configuration of a computer that executes a processing program for executing the functions of the first and other embodiments.
FIG. 9 is a diagram for explaining an example of a scene according to the “ISO / IEC 14496 (MPEG phase 4)” standard.
FIG. 10 is a diagram for explaining an example of a bitstream compliant with the standard.
FIG. 11 is a diagram for explaining security information (IPMP) of the bit stream.
FIG. 12 is a diagram for explaining the IPMP descriptor.
FIG. 13 is a block diagram showing a configuration of a conventional encoder.
FIG. 14 is a block diagram showing a configuration of a conventional decoder.
[Explanation of symbols]
100 encoder
101 Object descriptor (OD) generator
102 Media encoder
103 IPMP controller
104 BIFS encoder
105 Update controller
106 Multiplexer
200 decoder
201 Demultiplexer
202 Synchronization control unit
203 Descriptor parser
204 BIFS decoder
205 Media decoder
206 IPMP Controller
207 renderer
300 External communication unit (back channel)

Claims

Each of the encoded data divided into an arbitrary size and a header including specific information related to the encoded data are connected to form a series of bit streams, and the bit streams are transmitted via the first communication path. A data processing method for transmission,
A transmission / reception step of transmitting / receiving at least information relating to transmission of the bitstream to / from the reception side via a second communication path;
And a control step of controlling transmission of the bit stream based on the reception information obtained in the transmission / reception step.

The control step includes
A setting step for setting a priority for each of the encoded data and the header;
A selection step of selecting a corresponding transmission protocol from a plurality of transmission protocols based on the priority setting in the setting step;
The data processing method according to claim 1, further comprising a transmission control step of controlling transmission of the bitstream based on the transmission protocol selected in the selection step.

The data processing method according to claim 1, wherein the second communication path includes one or more sub communication lines independent of the first communication path.

An arbitrary bit stream including at least one or more mutually independent encoded data is received via the first communication path by an arbitrary transmission protocol of the plurality of transmission protocols, and the mutual A data processing method for independently decoding a plurality of independent encoded data,
A data processing method comprising: a transmission / reception step of transmitting / receiving at least information relating to transmission of the bit stream to / from a transmission side of the bit stream via a second communication path.

A first management step for managing an error occurrence frequency of the received bitstream;
A second management step for managing a bit rate for the bitstream being received;
The transmission step includes at least management information in the first management step, management information in the second management step, and request information for changing or specifying a transmission protocol for an arbitrary part of the received bitstream. 5. The data processing method according to claim 4, further comprising a step of transmitting any one to a transmission source of the bit stream.

A data processing method for transmitting a continuous bit stream by an arbitrary transmission protocol among a plurality of different transmission protocols,
A transmission step of encoding and transmitting an arbitrary area of the bitstream according to an arbitrary transmission protocol;
A changing step of changing a transmission protocol of an arbitrary part in the bitstream according to information received from the outside via a communication path independent of the communication path of the bitstream;
A data processing method comprising: a retransmission step of retransmitting a portion of the bitstream that has already been transmitted in accordance with information received from the outside and combining it with the next bitstream.

The data processing method according to claim 1, wherein the bit stream is a bit stream compliant with the MPEG-4 standard.

A computer-readable recording medium having recorded thereon a computer program for causing a computer to execute the processing steps of the data processing method according to claim 1.

Each of the encoded data divided into an arbitrary size and a header including specific information related to the encoded data are connected to form a series of bit streams, and the bit streams are transmitted via the first communication path. A data processing device for transmission,
Transmitting and receiving means for transmitting and receiving at least information relating to transmission of the bitstream to and from the receiving side via a second communication path;
A data processing apparatus comprising: control means for controlling transmission of the bit stream based on reception information obtained by the transmission / reception means.

Receiving means for receiving, via the first communication path, an arbitrary bit stream including a plurality of mutually independent encoded data by an arbitrary transmission protocol among the plurality of transmission protocols;
Decoding means for independently decoding the plurality of mutually independent encoded data in the bitstream received by the receiving means;
A data processing apparatus comprising: transmission / reception means for transmitting / receiving at least information relating to transmission of the bit stream to / from a transmission side of the bit stream via a second communication path.

A data processing apparatus for transmitting a continuous bit stream by an arbitrary transmission protocol among a plurality of different transmission protocols,
Transmitting means for encoding and transmitting an arbitrary area of the bitstream according to an arbitrary transmission protocol;
Changing means for changing a transmission protocol of an arbitrary part in the bitstream according to information received from the outside via a communication path independent of the communication path of the bitstream;
A data processing apparatus comprising: a retransmission unit configured to combine and retransmit the already transmitted portion of the bitstream to a next bitstream in accordance with information received from the outside.