(57)【要約】データを他のマテリアルに結合する方法は、他のマテリアルにデータを繰り返し分散させるステップを有する。データは、例えば、他のマテリアルに関連付けられたメタデータである。他のマテリアルは、ビデオ、オーディオ及び／又はデータマテリアルであってもよく、例えばＭＸＦ等の所定のファイルフォーマットを有する。ファイルからのマテリアル及びデータは、ＳＤＩ、ＳＤＴＩ及びＡＥＳ３等の信号インタフェースの１つにマッピングされ、ファイルメタデータは、複数の多重化法の１つにより、ストリーム信号インタフェースに亘って、繰り返し分散される。
2004508777.tif 000002
【特許請求の範囲】
【請求項１】
デジタルデータを他のデジタルマテリアルに結合するデータ結合方法において、
上記デジタルデータを所定のデータ構造に組織化するステップと、
データ記録装置に互換性を有するとともに、各繰返しが少なくとも１つの上記他のマテリアル用のデータ空間と他のデータ用のデータ空間を含む所定の繰返しフォーマットを有するデジタルビットストリームを生成するステップと、
上記データ構造を上記他のデータ空間又は上記他のマテリアルのデータ空間の一部において、上記フォーマットの複数の繰返しに亘って繰り返し格納するステップとを有するデータ結合方法。
【請求項２】
上記デジタルデータは、上記他のマテリアルに関連付けられたメタデータであることを特徴とする請求項１記載のデータ結合方法。
【請求項３】
上記他のマテリアルは、ビデオマテリアルを含むことを特徴とする請求項１又は２記載のデータ結合方法。
【請求項４】
上記他のマテリアル用の少なくとも１つのデータ空間は、ビデオデータ空間を含むことを特徴とする請求項３記載のデータ結合方法。
【請求項５】
上記他のマテリアルは、オーディオマテリアルを含むことを特徴とする請求項１乃至３いずれか１項記載のデータ結合方法。
【請求項６】
上記他のマテリアル用の少なくとも１つのデータ空間は、オーディオデータ空間を含むことを特徴とする請求項５記載のデータ結合方法。
【請求項７】
上記デジタルデータは、オーディオデータ空間に格納されることを特徴とする請求項６記載のデータ結合方法。
【請求項８】
上記デジタルデータは、上記他のデータ空間に格納されることを特徴とする請求項１乃至８いずれか１項記載のデータ結合方法。
【請求項９】
上記他のデータ空間は、補助データ空間であることを特徴とする請求項１乃至８いずれか１項記載のデータ結合方法。
【請求項１０】
上記データ構造は、上記データと、キーフィールドと、値フィールドのデータ量を示すレングスフィールドとを含む値フィールドを有することを特徴とする請求項１乃至９いずれか１項記載のデータ結合方法。
【請求項１１】
上記フォーマットは、複数フレーム内で繰り返され、上記デジタルデータの各繰返しは、上記データ構造の先の繰返し分のデータを含まないフレームから開始されることを特徴とする請求項１乃至１０いずれか１項記載のデータ結合方法。
【請求項１２】
上記データ構造は、整数個のフレームに亘って分散して格納されていることを特徴とする請求項１１記載のデータ結合方法。
【請求項１３】
上記データ構造は、データパケットを備え、該データ構造の繰返しは、先の繰返し分のデータを含まないパケットから開始されることを特徴とする請求項１１又は１２記載のデータ結合方法。
【請求項１４】
上記パケットは、連続的に番号付けされ、上記データ構造の各繰返しは、所定の番号を有するパケットから開始されることを特徴とする請求項１２記載のデータ結合方法。
【請求項１５】
上記各フレームは、データパケットのセットを含み、各セットは、整数個の完全なパケットから構成されることを特徴とする請求項１３又は１４記載のデータ結合方法。
【請求項１６】
上記繰返しフォーマットは、シリアルデジタルインタフェース（ＳＤＩ）ビットストリームのフォーマットであることを特徴とする請求項１１乃至１５いずれか１項記載のデータ結合方法。
【請求項１７】
上記データ構造は、非オーディオモードで動作するオーディオフレームに繰り返し格納されることを特徴とする請求項１６記載のデータ結合方法。
【請求項１８】
上記パケットのセットは、ガードバンドを介してフレーム境界から離間したオーディオフレーム内のウィンドウに格納されることを特徴とする請求項１２又は１３に従属する請求項１７記載のデータ結合方法。
【請求項１９】
上記データ構造は、上記シリアルデジタルインタフェース（ＳＤＩ）ビットストリームの垂直補助データ空間（ＶＡＮＣ）に格納されることを特徴とする請求項１７記載のデータ結合方法。
【請求項２０】
上記シリアルデジタルインタフェース（ＳＤＩ）ビットストリームのコンテンツからシリアルデータトランスポートインタフェース（ＳＤＴＩ）ビットストリームを生成するステップを有する請求項１６乃至１９いずれか１項記載のデータ結合方法。
【請求項２１】
上記オーディオフレームは、シリアルデータトランスポートインタフェース（ＳＤＴＩ）データ構造に格納されることを特徴とする請求項１０又は１１記載のデータ結合方法。
【請求項２２】
上記他のマテリアルは、少なくともビデオマテリアルを含み、上記繰返しフォーマットは、少なくともオーディオアイテムとピクチャアイテムとを有するシリアルデータトランスポートインタフェース（ＳＤＴＩ）ビットストリームのフォーマットであることを特徴とする請求項１１乃至１５いずれか１項記載のデータ結合方法。
【請求項２３】
上記データ構造は、非オーディオモードで動作するオーディオフレームに繰り返し格納されることを特徴とする請求項２１記載のデータ結合方法。
【請求項２４】
上記パケットのセットは、ガードバンドを介してフレーム境界から離間したオーディオフレーム内のウィンドウに格納されることを特徴とする請求項１２又は１３に従属する請求項２２記載のデータ結合方法。
【請求項２５】
上記データ構造は、上記シリアルデジタルインタフェース（ＳＤＩ）ビットストリームの垂直補助データ空間（ＶＡＮＣ）に格納されることを特徴とする請求項２１記載のデータ結合方法。
【請求項２６】
上記パケットの１セットは、垂直補助データ空間の１ラインに格納されることを特徴とする請求項１２又は１３に従属する請求項２１記載のデータ結合方法。
【請求項２７】
上記シリアルデータトランスポートインタフェース（ＳＤＴＩ）ビットストリームは、システムアイテムを有し、上記データ構造は、該システムアイテムに格納されることを特徴とする請求項２１記載のデータ結合方法。
【請求項２８】
それぞれ識別子を有する複数の異なるデータ構造が上記フォーマットに亘って繰り返し分散されていることを特徴とする請求項１乃至２７いずれか１項記載のデータ結合方法。
【請求項２９】
上記繰返しフォーマットからの結合されたデータ及び他のマテリアルをファイルにマッピングするステップを有し、
上記ファイルにおいて、上記データ構造は、該ファイルの所定の部分に格納され、上記他のマテリアルは、該ファイルの他の部分に格納されることを特徴とする請求項１乃至２８記載のデータ結合方法。
【請求項３０】
上記ファイルは、ファイルヘッダと、上記他のマテリアルを格納するファイルボディと、ファイルフッタとを有することを特徴とする請求項２９記載のデータ結合方法。
【請求項３１】
上記ファイルはＭＸＦファイルであり、上記データはヘッダメタデータであることを特徴とする請求項２９又は３０記載のデータ結合方法。
【請求項３２】
上記ファイルからのデータ構造及び他のマテリアルを、データ記録装置に互換性を有するとともに、各繰返しが少なくとも１つの上記他のマテリアル用のデータ空間と他のデータ用のデータ空間を含む所定の繰返しフォーマットを有するデジタルビットストリームにマッピングするステップと、
上記データ構造を上記他のデータ空間又は上記他のマテリアルのデータ空間の一部において、上記フォーマットの複数の繰返しに亘って繰り返し格納するステップとを有する請求項２９乃至３１いずれか１項記載のデータ結合方法。
【請求項３３】
所定のデータ構造を有するデジタルデータと他のデジタルマテリアルを含み、データ記録装置に互換性を有するとともに、各繰返しが少なくとも１つの上記他のマテリアル用のデータ空間と他のデータ用のデータ空間を含む所定の繰返しフォーマットを有し、上記データ構造が上記他のデータ空間又は上記他のマテリアルのデータ空間の一部において、上記フォーマットの複数の繰返しに亘って繰り返し格納されているデジタルビットストリームを受信するステップと、
上記他のマテリアルから上記データ構造を分離するステップとを有するデータ受信方法。
【請求項３４】
上記データ構造及び他のマテリアルがマッピングされ、上記データ構造が所定の部分に格納され、上記他のマテリアルが他の部分に格納されたファイルから該データ構造及び上記他のマテリアルを逆マッピングすることにより、該ファイルから信号を生成するステップを有する請求項３３記載のデータ受信方法。
【請求項３５】
添付の図１乃至図１３を用いて実質的に以下に説明する方法。
【請求項３６】
請求項１乃至３５いずれか１項記載の方法を実現する信号処理装置。
【請求項３７】
請求項１乃至３５いずれか１項記載の方法を実現するコンピュータプログラム製品。
【請求項３８】
所定のデータ構造を有するデジタルデータ及び他のデジタルマテリアルを含み、データ記録装置に互換性を有するとともに、各繰返しが少なくとも１つの上記他のマテリアル用のデータ空間と他のデータ用のデータ空間を含む所定の繰返しフォーマットを有し、
上記データ構造が上記他のデータ空間又は上記他のマテリアルのデータ空間の一部において、上記フォーマットの複数の繰返しに亘って繰り返し格納されているデジタルビットストリーム。
【請求項３９】
請求項１乃至３５いずれか１項記載の方法により生成された請求項３８記載のデジタルビットストリーム。
【請求項４０】
添付の図面を用いて実質的に以下に説明する請求項３９記載のデジタルビットストリーム。
【発明の詳細な説明】
【０００１】
本発明は、データを他のマテリアルに結合する結合方法及び装置に関する。さらに、本発明は、この結合方法を実現する信号処理装置、デジタルビットストリーム及びコンピュータプログラム製品に関する。
【０００２】
「マテリアル」は、ビデオ、オーディオ及びデータエッセンのいずれか又はこれらの組合せを意味する用語とする。
【０００３】
本発明の実施の形態ではメタデータをマテリアルに結合する。本発明の好ましい実施の形態では、メタデータをビデオ及びオーディオマテリアルに結合する。本発明及びその背景を明瞭にするために、この好ましい実施の形態に即して本発明を例示的に説明するが、本発明はこのような形態に限定されるものではない。
【０００４】
メタデータは、ビデオ及びオーディオ等のマテリアルに関連する情報である。幾つかの種類のメタデータは、例えば圧縮ビデオ信号の符号化の形式を記述し、このメタデータに基づいて圧縮ビデオ信号の復号を行うことができる。また、他の種類のメタデータとして、ビデオのコンテンツを記述するメタデータもある。例えば、このような記述的メタデータは、ビデオのタイトルや、そのビデオがいつ、どこで撮影されたかを示すその他の情報を記述する。さらに、アスペクト比、使用されたレンズ、ビデオフォーマット等の技術的情報を記述するメタデータもある。さらに、グッドショットマーカ（Ｇｏｏｄ Ｓｈｏｔ Ｍａｒｋｅｒｓ）、著作権情報及びビデオに登場する人物に関する情報等を記述するメタデータもある。これらの他に、様々な種類のメタデータが存在する。
【０００５】
従来、メタデータは、そのメタデータが関連するマテリアルとは分離して保存されていた。メタデータは、データベースに保存してもよく、この場合、何らかの手法でそのメタデータとマテリアルとを関連付けていた。このような手法の一例として、メタデータをビデオカセット上のコードとして記録する手法がある。ここで、リンクが失われると、メタデータはマテリアルに関連付けられなくなる。また、データベースが壊れると、メタデータが消失する。したがって、少なくとも幾つかのメタデータは、マテリアルに結合することが望ましい。
【０００６】
マテリアルは、デジタルビデオテープレコーダ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｔａｐｅ Ｒｅｃｏｒｄｅｒ：以下、ＤＶＴＲという）やデジタルディスクレコーダ等の記録装置で記録する必要がある。ここで、例えば、テープを最初に巻き戻すことなく、容易にメタデータにアクセスするために、メタデータを繰り返し記録することが望ましい。しかしながら、ＤＶＴＲやディスクレコーダは、デジタルビットストリームにおいて、周期的にメタデータを繰り返すための専用の空間を提供するフォーマットを有していない。
【０００７】
そこで、本発明に係るデータ結合方法は、デジタルデータを他のデジタルマテリアルに結合するデータ結合方法において、デジタルデータをキーフィールドと、レングスフィールドと、データを格納する値フィールドとを有する所定のデータ構造に組織化するステップと、データ記録装置に互換性を有するとともに、各繰返しが少なくとも１つの上記他のマテリアル用のデータ空間と他のデータ用のデータ空間を含む所定の繰返しフォーマットを有するデジタルビットストリームを生成するステップと、データ構造を他のデータ空間又は他のマテリアルのデータ空間の一部において、フォーマットの複数の繰返しに亘って繰り返し格納するステップとを有する。
【０００８】
データ構造をこのようなフォーマットに含めることにより、データ構造をデータレコーダに対応するフォーマットに格納することができる。データ構造の繰返しにより、例えば、レコーダがテープレコーダである場合、テープの最初に戻ることなく、データ構造にアクセスすることができる。
【０００９】
さらに、本発明に係るデータ結合方法は、結合されたデータ及び他のマテリアルをファイルにマッピングするステップを有し、ファイルにおいて、データ構造は、ファイルの所定の部分に格納され、他のマテリアルは、ファイルの他の部分に格納される。
【００１０】
ここで、好ましくは、ファイルは、ファイルヘッダと、他のマテリアルを格納するファイルボディと、ファイルフッタとを有する。さらに好ましくは、このファイルは、ＭＸＦファイルであり、データはこのＭＸＦファイルにおけるヘッダメタデータであるとよい。
【００１１】
例えばビデオ及びオーディオマテリアルは、テープレコーダ及びファイルサーバを含む様々な異なる種類のデータ記録装置で記録され、これらのデータ記録装置間を伝送される。したがって、結合されたデータ及び他のマテリアルを組織化することにより、このような伝送が容易になる。
【００１２】
このフォーマットは、シリアルデジタルインタフェース（ＳＤＩ）ビットストリーム又はシリアルデータトランスポートインタフェース（ＳＤＴＩ）ビットストリームのフォーマットであってもよく、他のマテリアルは、ＳＤＩの場合は、少なくとも、非圧縮ビデオマテリアルであり、ＳＤＴＩの場合は、圧縮ビデオマテリアルである。圧縮ビデオマテリアルは、ＳＤＴＩビットストリームのピクチャアイテムに格納される。いずれのフォーマットもビデオフレームに基づいている。
【００１３】
いずれのフォーマットもオーディオモード及び非オーディオモードで動作するオーディオフレームを含むことができる。本発明の一具体例においては、データ構造は、非オーディオモードで動作するオーディオフレームに格納される。
【００１４】
ＳＤＩは、垂直補助データ空間（Ｖｅｒｔｉｃａｌ Ａｎｃｉｌｌａｒｙ Ｄａｔａ：ＶＡＮＣ）を有する。本発明の一具体例においては、データ構造は、ＶＡＮＣに格納される。
【００１５】
ＳＤＴＩにおいては、ＶＡＮＣは、ピクチャアイテムデータ空間に含まれる。本発明の一具体例においては、データ構造は、ＶＡＮＣ空間に格納される。
【００１６】
さらに、ＳＤＴＩは、システムアイテムを有する。本発明の一具体例においては、データ構造はシステムアイテムに格納される。
【００１７】
本発明の好適な具体例においては、データ構造は、パケットセットと呼ばれるパケットのグループに符号化される。各セットは、１を含む整数個のパケットを含む。パケットは、整数個の完全なＫＬＶ符号化されたアイテムを含み、このアイテムは、データを格納する値フィールドＶと、値フィールドの長さを示すレングスフィールドと、パケットのタイプを示すキーフィールドとを備えるデータ構造を有する。
【００１８】
ＳＤＩにおいて、パケットセットは、好ましくは、ＶＡＮＣ空間内の１つの垂直ブランキング期間（Ｖｅｒｔｉｃａｌ Ｂｌａｎｋｉｎｇ Ｉｎｔｅｒｖａｌ：ＶＢＩ）のビデオラインを占有する。パケットによりＶＢＩビデオラインを占有させるために、残りの部分をｎｕｌｌで満たしてもよい。
【００１９】
ＳＤＩにおいて、各繰返しは、好ましくは、新たなフレームにおいて、新たなパケットセットの新たなパケットにおいて開始される。
【００２０】
ＳＤＴＩにおいては、１つのパケットセットは、ＶＡＮＣ空間内の１つの非圧縮ビデオラインを占有する。パケットにより１つのラインを占有させるために、残りの部分をｎｕｌｌで満たしてもよい。
【００２１】
これに代えて、ＳＤＩ又はＳＤＴＩにおいて、１つのパケットセットが非オーディオモードで動作する１つのオーディオフレームを占有してもよい。パケットにより１つのオーディオフレームを占有させるために、残りの部分をｎｕｌｌで満たしてもよい。
【００２２】
これに代えて、ＳＤＴＩ−ＣＰにおいて、１つのパケットセットによりシステムアイテムデータ空間のメタデータ領域を占有してもよい。
【００２３】
また、本発明に係るコンピュータプログラム製品は、適切な信号又はデータプロセッサにより実行されて、上述した方法を実現する。
【００２４】
ＭＸＦファイル
ファイル全体のデータ構造を図１に示す。このようなファイルを、ここでは、マテリアル交換フォーマット（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ ｆｏｒｍａｔ：以下、ＭＸＦという。）のファイルと呼ぶ。ＭＸＦの目的は、プログラムマテリアルをマテリアルボディ（本体）に関する添付されたメタデータと共に交換することである。すなわち、ＭＸＦファイルは、例えばディスクを用いたファイルサーバ間でプログラムマテリアル及びメタデータを送受するためのファイルである。
【００２５】
ＭＸＦファイルは、キー−レングス（長さ）−値（Ｋｅｙ， Ｌｅｎｇｔｈ，Ｖａｌｕｅ：以下、ＫＬＶという。）符号化されたデータパケットのシーケンスにより定義される。
【００２６】
ヘッダメタデータは、以下のような構造を有する。
【００２７】
ＫＬＶにより符号化された各メタデータアイテム。
【００２８】
ＫＬＶによりメタデータセットとして符号化されたメタデータアイテムの論理的グループ。ここで、値はＫＬＶ符号化されたメタデータアイテムの集合である。
【００２９】
ＫＬＶにより符号化されたメタデータセットの論理的グループ。ここで、値はＫＬＶ符号化されたメタデータセットの集合である。
【００３０】
ここで、最上位のレベルは、最外部レベル（ｏｕｔｅｒｍｏｓｔ ｌｅｖｅｌ）におけるヘッダメタデータである。ファイルは、ファイルヘッダ、ファイルボディ（本体）及びファイルフッタから構成される。ボディは「エッセンス」、すなわち、この具体例においてはビデオ及び／又はオーディオエッセンスデータを含む。エッセンスは、これに代えて又はこれに加えてエッセンスデータを含んでいてもよい。以下では、説明を簡潔にするために、ビデオ及びオーディオデータについてのみ説明する。
【００３１】
なお、図１は、実際のスケールを表しているわけではない。ボディは、プリアンブル及びポストアンブルより遙かに大きい。ボディは、ファイルのデータコンテンツの９９％或いはそれ以上を占める。
【００３２】
ファイルヘッダ
ファイルヘッダは、プリアンブルと、これに続くヘッダメタデータと任意項目（オプション）としてインデックステーブルを有する。
【００３３】
プリアンブルは、好ましくは、例えば８バイトといった固定長のラン−インバイト（Ｒｕｎ−ｉｎ ｂｙｔｅ）から開始される。次ぎに、ＫＬＶ符号化されたプリアンブルデータパックが続く。このプリアンブルデータパックは、以下の情報を有する。
【００３４】
１２バイトのＳＭＰＴＥパックラベル（キー）
これに続く１バイト以上（この具体例では４バイト）のレングスバイト
この具体例では、これに続くｎｕｌｌが満たされた値フィールド。レングスバイトは、値フィールド内のデータ量を示す。
【００３５】
ＳＭＰＴＥパックラベルは、ファイルをＭＸＦファイルとして定義する。
【００３６】
ファイルフッタ
ＭＸＦファイルは、ファイルフッタにより終了する。ファイルフッタは、任意項目であるインデックステーブルと、これに続くポストアンブルを有する。
【００３７】
ポストアンブルは、ＫＬＶ符号化されたポストアンブルデータパックを有する。ポストアンブルデータパックは、１２バイトのＳＭＰＴＥパックラベルと、１バイト以上（この具体例では４バイト）のレングスバイトを含む。この具体例では、値フィールドは存在せず、レングスバイトは、長さ０を示す。他の具体例として、値フィールド内に値が存在又は付加されてもよく、ＭＸＦデコーダは、この値を無視してもよい。
【００３８】
インデックステーブル
インデックステーブルにより、例えば、ファイルボディにおけるビデオフレームの開始点等、特定のデータの位置を素早く特定することができる。
【００３９】
インデックステーブルは、任意のメタデータセットであり、個々のビデオエッセンス及び関連するオーディオ及びデータエッセンスの位置を特定するために使用できる。インデックスファイルは、ボディの直前に配置してもよく、ボディの直後に配置してもよく、或いはボディ全体に亘って分散させてもよい。
【００４０】
インデックステーブルは、ストリーム入力時からファイル生成の間に「オンザフライ（ｏｎ ｔｈｅ ｆｌｙ）」方式で生成することもでき、記録の際、概念的にファイルの最後に記録してもよい。実際には、インデックステーブルは、記録処理の都合に応じて、サーバファイルシステム内のどの位置に記録してもよい。完全なファイルを伝送する場合、インデックステーブルは、ＭＸＦファイルヘッダに格納される。
【００４１】
インデックステーブルは、フレーム毎の固定バイト数と伴に定義されているボディコンテナ仕様（ｂｏｄｙ ｃｏｎｔａｉｎｅｒ ｓｐｅｃｉｆｉｃａｔｉｏｎ）に対しては必ずしも必要ではなく、すなわち、ＭＸＦファイルにインデックステーブルを含めるか否かは任意である。
【００４２】
ヘッダメタデータ
プリアンブルは、ヘッダメタデータを有する。メタデータは、ファイルボディに含まれるエッセンスに関連するいかなる情報であってもよい。メタデータは、エッセンスを記述するものであってもよく、エッセンスに関する技術的データであってもよく、他のいかなる情報であってもよい。
【００４３】
例えば、記述的メタデータは、以下に限定されるものではないが、プログラムＩＤ（ＰＩＤ）等のビデオマテリアルの製作に関するデータ、タイトル、ワーキングタイトル（Ｗｏｒｋｉｎｇ Ｔｉｔｌｅ）、ジャンルＩＤ、概要（Ｓｙｎｏｐｓｉｓ）、ディレクタＩＤ、ピクチャスタンプ（Ｐｉｃｔｕｒｅｓｔａｍｐ）、キーワード、スクリプト、人物、例えば役者及び製作スタッフの名前及び詳細等を含む。
【００４４】
また、技術的メタデータは、以下に限定されるものではないが、表示アスペクト比、ピクチャの画素数、ピクチャレート、カメラタイプ、レンズ識別情報及び他のあらゆる技術的データを含む。
【００４５】
メタデータは、マテリアルの編集に関するデータを含んでいてもよい。このようなデータは、そのマテリアルに対して実行すべき単なる編集又はその他の処理を定義するインストラクションであってもよい。
【００４６】
プリアンブルのヘッダメタデータを図２に示す。ヘッダメタデータは、１６バイトのヘッダメタデータ汎用ラベル（Ｕｎｉｖｅｒｓａｌ Ｌａｂｅｌ：以下、ＵＬという。）と、これに続くレングスバイトと、これに続く値フィールド（Ｖ）のデータからなるＫＬＶ符号化されたメタデータセット１〜ｎを有する。
【００４７】
ＵＬは、ＵＬに続くデータ値（Ｖ）をＭＸＦヘッダメタデータとして定義する。
【００４８】
ＫＬＶ符号化された各メタデータセットｎは、セットを固有に識別する１６バイトのセットＵＬと、１バイト以上のレングスバイトと、セットの値フィールドＶ内のデータからなるＫＬＶ符号化されたメタデータアイテムのセットとを有する。レングスバイトは、値フィールドの長さを示す。ＵＬは、セットｎ内に存在するメタデータアイテムの完全なリストを定義する。
【００４９】
各アイテムはＫＬＶ符号化され、１６バイトのアイテムＵＬと、１バイト以上のレングスバイトと、値フィールドＶ内のデータとを有する。ＵＬは、値フィールドＶ内のコンテンツの種類を定義する。
【００５０】
ここで、セットｎが複数のＫＬＶ符号化されたデータセットを含んでもよいことは明らかである。アイテムは、１又は複数のＫＬＶ符号化されたデータのセットを含んでいてもよい。
【００５１】
ファイルボディ
ボディの具体例について説明する。この具体例では、ボディは、ＭＰＥＧ符号化ビデオを含むＳＤＴＩ−ＣＰコンテンツパッケージである。この他のコンテナ（ｃｏｎｔａｉｎｅｒ）を用いてもよい。
【００５２】
ファイルボディのコンテンツは、ファイルボディに含まれるビデオ及び／又はオーディオ及び／又はデータエッセンスに応じて、及びこのエッセンスの符号化方法に応じて異なる。例えば、ビデオデータは圧縮されていても圧縮されていなくてもよい。また、圧縮は、複数の異なる形式で行うことができる。
【００５３】
各エッセンスフレームは、ボディ内において、ＫＬＶ符号化されている。異なるタイプのエッセンスを収容するＳＤＴＩ−ＣＰコンテンツパッケージの場合、各タイプは、別々にＫＬＶ符号化される。
【００５４】
各コンテナタイプは、ＫＬＶコーディングにおけるキーとして、固有の登録された汎用ラベルＵＬを有している。
【００５５】
コンテナ内の各エッセンスタイプも固有のキーを有していてもよい。
【００５６】
ファイルボディ内のデータ量は、無制限であり、ファイルボディは、ファイルヘッダとファイルフッタによってのみ区切られる。ファイルボディ内のデータ量は、例えば数ギガバイトであってもよい。
【００５７】
ＭＸＦヘッダメタデータの繰返し
ヘッダメタデータは、ファイルボディに亘って、繰り返し分散されていてもよい。ファイルボディ内のヘッダメタデータは、プリアンブル内のヘッダメタデータに追加して設けられる。この手法には、以下のような利点がある。
【００５８】
ファイルの伝送が中断されたとき、メタデータを回復（ｒｅｃｏｖｅｒｙ）することができる。
【００５９】
ＭＸＦファイルでは、ファイルボディ内のデータへのランダムアクセスを行うことができる。繰り返し挿入されたメタデータにより、ファイルの最初又は最後にスクロールすることなく、ランダムアクセスされたデータに関連するメタデータに容易且つ高速にアクセスすることができる。
【００６０】
ヘッダメタデータのファイルボディ内における繰返しは、任意（オプション）であり、本発明の具体例におけるメタデータの繰返しとは、何ら関係ない。
【００６１】
以上、ＭＸＦファイルの基礎的な特徴について説明した。ＭＸＦファイルには、この他にも様々な特徴があるが、これらは本発明に関係しないため、説明を省略する。
【００６２】
システム概観
図４に示す信号処理及びマテリアル伝送システムは、ソースコードのソース１０と、オプションであるエンコーダ１２と、ソースコード又は符号化されたソースコードをコンテナにフォーマットするインタフェース１６と、コンテナをＭＸＦファイルのボディにカプセル化するインタフェース１８とを備える。ＭＸＦファイルは、インタフェース２０に伝送され、インタフェース２０は、ＭＸＦを非カプセル化し、すなわち、ボディからコンテナを取り出す。インタフェース２２は、コンテナからソースコード又は符号化されたソースコードを取り出す。ソースコードが符号化されている場合は、デコーダ２６がこのソースコードを復号する。ソースコードは、使用装置（ｕｔｉｌｉｓｅｒ）２８により使用される。使用装置２８は、例えば表示装置であってもよく、ソースコードを処理し又はソースコードを要求する他のいかなるプロセッサであってもよい。
【００６３】
インタフェース１８からインタフェース２０への伝送は、例えばコンピュータデータディスク等のディスクにデータを記録することにより行ってもよく、例えばインターネットプロトコルパケット等を用いて、通信ネットワークを介してデータを送信することにより行ってもよい。この他、イーサネット（登録商標）やファイバチャンネル（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）を用いてデータを伝送してもよい。
【００６４】
エンコーダ１４は、ＭＰＥＧ２エンコーダ等の圧縮エンコーダであってもよい。また、この他の圧縮形式を用いてもよい。デコーダ２６は、エンコーダ１４に対応するデコーダである。
【００６５】
インタフェース２０は、少なくとも以下のＭＸＦファイルを復号するＭＸＦデコーダである。
・ファイルの全ての部分のＫＬＶコンテナ構造（あらゆるタイプのボディのデータ構造を含む）
・ヘッダメタデータ構造を含むヘッダ
・フッタ
【００６６】
非圧縮マテリアル用ストリームインタフェース
非圧縮デジタルビデオ及びオーディオマテリアル用のストリームインタフェースとしては、例えばＳＭＰＴＥ２５９Ｍに定義されているシリアルデジタルインタフェース（又はインタコネクト）（Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ （ｏｒ Ｉｎｔｅｒｃｏｎｎｅｃｔ）：以下、ＳＤＩという。）がある。ＳＤＩは、当分野で周知のインタフェースであり、ここでは詳細には説明しない。図５は、ＳＤＩ構造にビデオ及びオーディオをマッピングしたモデルを示す図である。ＳＤＩは、図５に示すインタレースされたフィールドを使用し、ここで、ＳＡＶはスタートアクティブビデオ（Ｓｔａｒｔ Ａｃｔｉｖｅ Ｖｉｄｅｏ）を表し、ＥＡＶはエンドアクティブビデオ（Ｅｎｄ Ａｃｔｉｖｅ Ｖｉｄｅｏ）を表し、Ｈは走査線方向を表し、Ｆは垂直走査方向を表す。
【００６７】
ＳＤＩトランスポート（ＳＤＩ ｔｒａｎｓｐｏｒｔ）は、ビデオフレームを含み、ここで、データはフレームの走査線として伝送される。フィールドは、本質的に同じ構造を有している。フレームは、垂直ブランキング期間（Ｖｅｒｔｉｃａｌ Ｂｌａｎｋｉｎｇ Ｉｎｔｅｒｖａｌ：以下、ＶＢＩという。）、水平ブランキング期間（Ｈｏｒｉｚｏｎｔａｌ Ｂｌａｎｋｉｎｇ Ｉｎｔｅｒｖａｌ）及びアクティブビデオ空間を有する。ＳＤＩにおいては、ＶＢＩは、垂直補助データ（Ｖｅｒｔｉｃａｌ Ａｎｃｉｌｌａｒｙ Ｄａｔａ：以下、ＶＡＮＣという。）を伝送するために使用することができ、水平ブランキング期間は、水平補助データ（Ｈｏｒｉｚｏｎｔａｌ Ａｎｃｉｌｌａｒｙ ｄａｔａ：以下、ＨＡＮＣという。）を伝送するために使用することができる。アクティブビデオ空間は、例えばデジタルビデオ等のメインデータのための空間である。ＳＭＰＴＥ２７２Ｍに定義されているように、ＨＡＮＣにＡＥＳ／ＥＢＵデジタルオーディオチャンネルを含めてもよい。このようなオーディオチャンネルは、オーディオフレーム（後に詳細に説明する）を含む。
【００６８】
本発明の具体例においては、ＶＡＮＣは、上述したヘッダメタデータを含む。
【００６９】
変形例として、ヘッダメタデータは、オーディオチャンネルのオーディオフレームにマッピングしてもよい。各オーディオチャンネルは、オーディオデータ又は非オーディオデータのいずれを伝送してもよく、非オーディオデータは、例えばメタデータ等、いかなるデータであってもよい。オーディオフレーム内のデータがオーディオデータであるか、非オーディオデータであるかは、例えばフラッグを用いて、周知の手法で示すことができる。
【００７０】
圧縮マテリアルのストリームインタフェース
ＭＰＥＧ２等の圧縮データ用のストリームインタフェースとしては、例えばＳＭＰＴＥ３２６Ｍに定義されているＳＤＴＩ ＣＰがある。
【００７１】
図６は、２つのフィールドを有するＳＤＴＩ−ＣＰフレームの構造を示す図である。ＳＤＴＩ−ＣＰフィールドは、垂直補助データＶＡＮＣに対応していない。アクティブビデオ空間は、「アイテム」、すなわちシステムアイテム、ピクチャアイテム、オーディオアイテム及び予備アイテム（Ａｕｘｉｌｉａｒｙ Ｉｔｅｍ）に割り当てられたラインを含んでいる。図７に示すように、アイテムは１以上のエレメントを含む。図７では、例示的にピクチャアイテムに関連させてエレメントを示している。アイテムは１以上のエレメントを含む。エレメントは、図８に示すように、ＫＬＶ符号化されたデータブロックを含む。圧縮ビデオデータは、ピクチャアイテム内のピクチャエレメントに格納されている。ＳＤＴＩデータストリームは、周知の手法により、ＳＤＩデータストリームに含まれるデータを圧縮ビデオデータとともにＳＤＴＩデータストリームにマッピングすることにより得られる。
【００７２】
ＭＰＥＧ２エレメンタリストリーム（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ：以下、ＥＳという。）は、ＳＭＰＴＥ規格のＳＭＰＴＥ３２８Ｍに基づいて、ＥＳ内に垂直補助データＶＡＮＣを組み込む。ＳＤＩからＳＤＴＩ−ＣＰストリームが生成され、ＶＡＮＣデータが存在する場合、ＶＡＮＣデータは、ＭＰＥＧ２ＥＳ補助データ空間にマッピングされる（ＭＰＥＧ２ ＥＳ Ａｎｃｉｌｌａｒｙ Ｄａｔａ ｓｐａｃｅ）。本発明の具体例においては、ＶＡＮＣデータは、ヘッダメタデータである。補助データ空間は、１以上の非圧縮ビデオラインを使用する。非圧縮ビデオラインを補助データに使用することにより、ビデオデータに使用できるデータ空間（帯域幅）が減少する。
【００７３】
ＳＤＴＩ−ＣＰオーディオアイテムは、それぞれが１〜８個のオーディオチャンネルを含む１以上のオーディオエレメントを含む。エレメント内の各オーディオチャンネルは、オーディオデータ又は非オーディオデータのいずれを伝送してもよく、非オーディオデータは、例えばメタデータ等、いかなるデータであってもよい。オーディオフレーム内のデータがオーディオデータであるか、非オーディオデータであるかは、例えばフラッグを用いて、周知の手法で示すことができる。ヘッダメタデータは、本発明に基づき、オーディオフレームにマッピングすることができる。
【００７４】
パケットストリームに亘るヘッダメタデータのマッピング
本発明では、ヘッダメタデータを図３に示すように組織化する。図３のＡは、ヘッダメタデータの全体の構造を単一のエンティティとして示しており、このエンティティは、図２に示すものと同じである。ヘッダメタデータ構造は、図２に示し、図２を用いて説明したように、ＫＬＶ符号化されている。ヘッダメタデータ構造は、１６バイトの汎用ラベル（Ｕｎｉｖｅｒｓａｌ Ｌａｖｅｌ：ＵＬ）と、これに続く１バイト以上のレングスバイトと、これに続く値フィールドにおけるｎ個のメタデータセットとを有する。
【００７５】
図３のＢに示すように、図３のＡに示すデータ構造全体は、Ｐ個のパケットセットに分割される。
【００７６】
図３のＣに示すように、各パケットセットは、ｍ個のパケットを有する。さらに、図３のＤに示すように、各パケットは、ＫＬＶ符号化される。この図３のＤに示すように、パケットは、
パケットスタートシーケンスと、
データタイプバイトと、
レングスバイトと、
１バイトチャンネルＩＤと、
２バイトのパケットカウント値と、
完全なメタデータＫＬＶブロックのセットと、
ＣＲＣコードとを備える。
【００７７】
この具体例では、チャンネルＩＤと、パケットカウント値と、ＫＬＶブロックの合計値は、最大２５５バイトである。
【００７８】
チャンネルＩＤは、異なるチャンネルのエッセンスに関するメタデータの多くの異なるチャンネルをインタリーブするために使用される。チャンネルＩＤは、メタデータが属するチャンネルを識別する。
【００７９】
理想的には、パケットの値フィールドは、図２に示すように、ＫＬＶ符号化された完全なメタデータアイテムのセットを含む。しかしながら、１つのアイテムが２５２バイト以上から構成されていてもよい。この場合、メタデータアイテムの値フィールドは、パケットシーケンス内の連続する２以上のパケット内に格納してもよい。シーケンスの最初のパケットは、例えば１６バイトのキーであり、これによりシーケンス内のパケットが識別され、メタデータアイテムのデータの連続性が維持される。
【００８０】
フレーム内の最初のパケットも、そのパケットが複数のパケットのシーケンスの一部である場合、このようなキーを格納する。
【００８１】
パケットカウント値は、定義されたチャンネル番号におけるパケット番号を識別する。このカウント値は、通常、２バイトを使用し、これにより最大６５５３６パケットまでのシーケンスに対応できる。パケットカウント値「０」は、常にメッセージ内の最初のパケットである。すなわち、例えばｐ＝１のパケットセットにおいて、パケットカウント値は、パケット０から開始され、パケット値は、ｐパケットセットに亘って、順次インクリメントされる。
【００８２】
本発明の具体例におけるパケットのマッピング
ヘッダメタデータのパケットは、以下のように、ＳＤＩ又はＳＤＴＩデータストリームに繰り返しマッピングされ、組み込まれる。
【００８３】
ａ）ＳＤＩに非圧縮ビデオデータを組み込む場合、ヘッダメタデータのパケットは、ＶＡＮＣデータとして、１以上のＶＢＩラインにマッピングされる。
【００８４】
ｂ）圧縮ビデオストリームをＳＤＴＩに組み込む場合、ヘッダメタデータのパケットは、ペイロードデータ空間（ｐａｙｌｏａｄ ｄａｔａ ｓｐａｃｅ）における１以上の圧縮ビデオフレームにマッピングされ、圧縮ビデオフレームは、（ＳＭＰＴＥ規格のＳＭＰＴＥ３２８Ｍにより規定されている）ＭＰＥＧ２ＥＳシンタクスの拡張により提供される補助データ空間等のデータ空間にマッピングされる。
【００８５】
ｃ）ａ）及び）ｂに代えて、ヘッダメタデータのパケットは、非オーディオモードで動作するＡＥＳ３チャンネル等の１以上のオーディオチャンネルの１以上のオーディオフレームにマッピングしてもよい。このようなチャンネルは、ＳＤＩにもＳＤＴＩ−ＣＰにも設けられている。
【００８６】
ｄ）ヘッダメタデータを整数個のフレームに埋め込み、ヘッダメタデータが繰り返されるとき、ヘッダメタデータが新たなフレームにおいて常に同じ位置から開始されるようにする。新たなフレームにおいて、それぞれ完全なヘッダメタデータ構造を開始することにより、編集処理の中断回数を低減又は最小化することができる。
【００８７】
ｅ）少なくともパケットチャンネル識別子（チャンネルＩＤ）を含むパケット構造に、ヘッダメタデータをパケット化し、他のパケット化されたメタデータとパケットシーケンスカウント値とを多重化する（これにより、最初のパケットの検出が容易となる）。
【００８８】
ｆ）繰り返される完全なヘッダメタデータデータ構造は、新たなパケット毎に、好ましくはパケット０において開始され、これによりデータの解析が容易となる。
【００８９】
ｇ）図９に示すように、ヘッダメタデータをＡＥＳ３非オーディオフレームにマッピングする場合、メタデータは、ガードバンドを介してオーディオフレームの最初と最後から離間されたウィンドウにマッピングされ、これにより、タイミングエラーに対する又は編集時の信頼性が向上する。
【００９０】
オーディオフレームは、ビデオフレームに同期する一定量のオーディオデータを格納する。例えば、アナログオーディオが４８ｋＨｚでサンプリングされ、ビデオのフレームレートが２５Ｈｚである場合、オーディオフレームは、４８０００／２５バイト＝１９２０バイトのデータからなる。
【００９１】
図３のＢに示すように、
ａ）ＳＤＩにおいては、パケットセット１〜ｐは、ＳＤＩ内の各ＶＢＩラインに割り当てられ、１フレーム毎に３以上のラインを使用することもできるが、好ましくは、ＳＤＩフレーム毎に２つのみのＶＢＩライン（すなわち、１フィールド毎に１ライン）が使用される。
【００９２】
ｂ）ＳＤＴＩにおいては、パケットセット１〜ｐは、ＭＰＥＧ２ＥＳデータストリーム内の補助データ空間に割り当てられる。
【００９３】
ｃ）これに代えて、ＳＤＩ及びＳＤＴＩにおいて、パケットセット１〜ｐを各オーディオフレームに割り当ててもよい。１オーディオフレームは、１パケットセットのみを格納する。
【００９４】
各パケットセットは、１ライン又は１オーディオフレーム毎に１パケットセットの割合で、ＳＤＩ ＶＢＩライン又はオーディオフレーム全体を占有する。ライン又はオーディオフレームの全ての予備データ空間（ｓｐａｒｅ ｄａｔａ ｓｐａｃｅ）は、ｎｕｌｌで満たされる（ｎｕｌｌ ｆｉｌｌｅｄ）。本発明の具体例においては、１ライン又は１オーディオフレームは、通常、約１４００バイトで構成され、すなわち、図３のＣに示すように、ＶＡＮＣを用いたｍ＝５パケットに相当する。１つの完全なヘッダメタデータデータ構造は、１フレーム内で使用可能なデータ空間より大きくなることが多いため、完全なヘッダメタデータ構造は、複数のパケットセット１〜ｐに亘って分散して格納される。このため、パケットカウント値を用いて、１つの完全なヘッダメタデータ構造に対応する分散された全てのパケットを連続的に識別する。全てのフレーム内の全てのパケットセット内の全ての予備空間は、ｎｕｌｌにより満たされているため、完全なヘッダメタデータデータ構造は、整数個のフレームを占有する。完全なヘッダメタデータデータ構造がパケットセットのグループに亘って分散されると、次のｐ個のパケットセットにおいて、ヘッダメタデータデータ構造が繰り返される。
【００９５】
完全なヘッダメタデータデータ構造の繰返しは、新たなフレームのパケットセット１のパケット０から開始される。
【００９６】
複数の異なる完全なヘッダメタデータデータ構造をチャンネルＩＤにより識別される各チャンネルにインタリーブしてもよい。
【００９７】
このように、完全なヘッダメタデータデータ構造は、整数個のパケットセットに亘って分散される。各パケットセットは、整数個のパケットから構成されている。好ましくは、１パケットセットは、ＳＤＩにおける１ＶＢＩライン又は１オーディオフレームのみを占有し、このライン又はフレームにおいて使用されないデータ空間は、全てｎｕｌｌで満たされる。完全なヘッダメタデータデータ構造の各繰返しは、新たなビデオ又はオーディオフレームにおいて、例えばパケット０等、所定の番号の新たなパケットから開始される。これにより、各完全なヘッダメタデータデータ構造を容易に識別することができ、また、ヘッダメタデータデータ構造の開始点は、ＳＤＩのビデオフレーム又はＳＤＩ及びＳＤＴＩのオーディオフレームに一致するため、この開始点を容易に検出することができる。
【００９８】
ヘッダメタデータがＳＤＴＩピクチャアイテムのＭＰＥＧ２ＥＳデータストリームに組み込まれているＳＤＴＩにおいて、パケットは、ＳＭＰＴＥ３２８Ｍに基づく補助データラインに格納される。
【００９９】
本発明の具体例
図１０〜図１２は、図４を用いて説明した本発明に基づくヘッダメタデータの繰返しを実現する装置の構成を示すブロック図である。図１０〜図１２において、共通の構成要素には共通の符号を付している。以下に示す具体例では、ヘッダメタデータの格納にオーディオチャンネルを使用しないため、オーディオチャンネルに関する説明は省略する。
【０１００】
図１０において、ヘッダメタデータは、メタデータ生成器３０により生成される。ヘッダメタデータは、図２に示すデータ構造を有し、このメタデータデータ構造は、図３に示すように、パケットにマッピングされる。先に「本発明の具体例におけるパケットのマッピング」の章で説明したように、ヘッダメタデータは、ＳＤＩインタフェース３２内の適切なマルチプレクサ９０を用いて、ＳＤＩデータ構造のＶＡＮＣに挿入され、ヘッダメタデータは繰り返され、繰り返される各ヘッダメタデータは、新たなフレームのＶＢＩラインの最初の新たなパケット（パケットｍ＝０）から開始され、各完全なヘッダメタデータデータ構造は、整数個のフレームを占有する。好ましくは、上述のように、１つのフレームは、１つのＶＢＩラインに１つのパケットセットｐのみを格納する。
【０１０１】
ＳＤＩデータ構造は、アクティブビデオデータ空間に非圧縮ビデオデータを格納する。ＭＰＥＧエンコーダ３４は、デジタルビデオデータをＭＰＥＧ２ＥＳに圧縮し、ヘッダメタデータを格納するＳＤＩ ＶＡＮＣをエレメンタリストリームＥＳの補助データ空間にマッピングする。
【０１０２】
ＳＤＴＩ−ＣＰインタフェースは、繰り返されたヘッダメタデータを格納するＭＰＥＧ２ＥＳをＳＤＴＩ−ＣＰコンテンツパッケージのピクチャアイテムにマッピングする。ＳＤＴＩ−ＣＰパッケージのピクチャアイテム内におけるヘッダメタデータの位置又はタイミングは特に定められていない。
【０１０３】
ＳＤＴＩ−ＣＰコンテンツパッケージを記録するように設計されているデジタルビデオテープレコーダ又はデジタルディスクレコーダ等のデジタルデータレコーダ３８は、ＳＤＴＩ−ＣＰコンテンツパッケージを記録する。ヘッダメタデータは、ピクチャアイテム内のＭＰＥＧ２ＥＳに格納されているため、レコーダ３８は、そのフォーマット規則に違反することなく、繰り返されているメタデータを記録することができる。
【０１０４】
ビデオデータ及びヘッダメタデータは、コンピュータネットワーク又はコンピュータファイル記録装置４６に伝送する必要がある場合がある。このため、この具体例では、ビデオデータ及びヘッダメタデータをＭＸＦファイルに変換する。ＳＤＴＩ−ＣＰビットストリームは、レコーダ３８により再生され、抽出器（ｄｅ−ｅｍｂｅｄｄｅｒ）４０に供給される。抽出器４０は、ＳＤＴＩ−ＣＰコンテンツパッケージの圧縮ＭＰＥＧ２ＥＳからヘッダメタデータを分離し、ＭＸＦファイル生成器４２に供給する。ＳＤＴＩ−ＣＰビットストリームが１つのヘッダメタデータデータ構造及びその繰返しを含む場合、抽出器４０は、１つの完全なヘッダメタデータデータ構造（その繰返しは、含まない）のみをＸＭＦファイル生成器４２に供給する。ＭＸＦファイル生成器４２は、図２に示すように、ヘッダメタデータをＭＸＦファイルのファイルヘッダにマッピングし、ＭＰＥＧ２ＥＳストリームをＭＸＦファイルのボディにマッピングする。
【０１０５】
ＭＸＦファイルは、コンピュータネットワーク及び／又はコンピュータファイル記録装置４６に伝送してもよい。ＭＸＦファイルは、コンピュータネットワーク及び／又はコンピュータファイル記録装置４６から、レコーダ３８と同様なレコーダ５４に伝送することもできる。ＭＸＦファイルは、デマルチプレクサ４８に供給され、デマルチプレクサ４８は、ＭＸＦファイルのファイルボディからヘッダメタデータを分離する。ファイルボディである圧縮ＭＰＥＧ２ＥＳストリームとヘッダメタデータは、エンコーダ５０の独立した入力端子にそれぞれ供給され、エンコーダ５０は、ヘッダメタデータをＭＰＥＧ２ＥＳストリームの補助データ空間に組み込み、ＳＤＴＩエンコーダは、ＭＰＥＧ２ＥＳストリームをＳＤＴＩ−ＣＰコンテンツパッケージのピクチャアイテムに組み込む。レコーダ５４は、このＳＤＴＩ−ＣＰビットストリームを記録する。さらに、レコーダ５４は、このＳＤＴＩ−ＣＰストリームを再生することができ、再生したＳＤＴＩ−ＣＰストリームをＳＤＴＩデコーダ５６に供給し、ＳＤＴＩデコーダ５６は、補助データ空間内に繰り返されたヘッダメタデータを格納するＭＰＥＧ２ＥＳストリームを出力する。ＭＰＥＧ２デコーダ５８は、ビデオデータを伸長し、ヘッダメタデータは、ＶＢＩ又はＳＤＩストリームにマッピングされ、伸長ビデオデータは、ＳＤＩストリームのアクティブビデオ空間にマッピングされる。伸長ビデオデータ及びヘッダメタデータは、ＳＤＩインタフェース６０から取り出すことができる。
【０１０６】
図１１に示す具体例では、ヘッダメタデータの格納にオーディオチャンネルを使用する。図１１に示すように、ヘッダメタデータは、メタデータ生成器３０により生成される。ヘッダメタデータは、図２及び図３に示すデータ構造を有している。ヘッダメタデータは、オーディオインタフェース４４内の適切なマルチプレクサ９２を用いて、図８に示すように、オーディオフレームに挿入され、ヘッダメタデータは繰り返され、繰り返される各ヘッダメタデータは、新たなフレームの最初の新たなパケット（パケットｍ＝０）から開始され、各完全なヘッダメタデータデータ構造は、整数個のフレームを占有する。好ましくは、上述のように、１つのフレームは、１つのパケットセットｐのみを格納し、各パケットセットは、１つのパケットのみを格納する。
【０１０７】
ＳＤＩビットストリームは、アクティブビデオデータ空間に非圧縮デジタルビデオデータを格納する。ＭＰＥＧエンコーダ３４は、デジタルビデオデータをＭＰＥＧ２ＥＳに圧縮する。
【０１０８】
ＳＤＴＩ−ＣＰインタフェース３６は、ＭＰＥＧ２ＥＳをＳＤＴＩ−ＣＰコンテンツパッケージのピクチャアイテムにマッピングする。ヘッダメタデータを格納するオーディオチャンネルは、ＳＤＴＩ−ＣＰコンテンツパッケージのオーディオアイテムにマッピングされる。
【０１０９】
図１１の具体例におけるブロック３８〜４８は、図１０の具体例と同様であるため、説明は省略する。
【０１１０】
エンコーダ５０は、オーディオフレームにヘッダメタデータを繰り返し組み込み、ＳＤＴＩ−ＣＰエンコーダ５２は、オーディオフレームをＳＤＴＩコンテンツパッケージのオーディオアイテムにマッピングし、圧縮ビデオデータをピクチャアイテムにマッピングする。ＳＤＴＩビットストリームは、レコーダ５４で記録され、デコーダ５６において再生及び復号され、デコーダ５４は、ＭＰＥＧ２ＥＳストリームからオーディオを分離する。オーディオデコーダ６２は、ヘッダメタデータ及びオーディオデータを分離して出力する。
【０１１１】
図１２に示す具体例は、図１０に示す具体例と略々同様であるが、この具体例では、ヘッダメタデータ生成器３０により生成されたヘッダメタデータは、ＳＤＴＩエンコーダ３６内のマルチプレクサ９４により、ＳＤＴＩ−ＣＰコンテンツパッケージのシステムアイテム（図６に示す）に組み込まれる点が異なっている。図６に示すように、ヘッダメタデータのヘッダＵＬは、システムアイテム内のＳＡＶの直後に設けられている。ブロック３８〜５４は、図１０に示す具体例と同様に動作する。ＳＤＴＩデコーダ５６は、システムアイテムからヘッダメタデータを分離する。
【０１１２】
なお、本出願の優先日において、システムアイテムを有するＳＤＴＩは、関連するＳＭＰＴＥ規格において定義されているが、例えばレコーダ３８、５４で例示した多くのデータレコーダは、システムアイテムの使用をサポートしていないことは、当業者に周知である。
【０１１３】
ネットワークの具体例
図１３は、ＳＤＩやＳＤＴＩ等のストリーミングフォーマット信号とＭＸＦファイルを使用するネットワークの具体例を示す図である。ＳＤＩビットストリームは、ＭＰＥＧデジタルビデオテープレコーダ１００に供給される。レコーダ１００は、ＳＤＩビットストリームのビデオ及びオーディオ成分をＭＰＥＧ符号化し、符号化された成分を記録する。この具体例においては、レコーダ１００は、符号化された成分を含むＳＤＴＩ−ＣＰ又はＳＤＴＩ−ＤＶビットストリームを出力し、ビデオファイルサーバ１０２に供給し、ビデオファイルサーバ１０２は、ストリーミングフォーマット信号を記録する。ビデオファイルサーバ１０２は、ＭＸＦファイルを生成するインタフェースを備え、ＭＸＦファイルをファイルサーバ１０４、ルータ１０８、制御コンピュータ１１０及びテープアーカイブ１１２を備えるコンピュータネットワーク１０６に配信する。ＭＸＦファイルにより、ファイルサーバ１０４、テープアーカイブ１１２及びビデオファイルサーバ１０２間でマテリアルを交換することができる。
【０１１４】
ヘッダメタデータは、上述のように、ＳＤＩ及びＳＤＴＩビットストリームにマッピングされる。ＭＸＦファイルは、上述のように、サーバ１０２により生成される。
【０１１５】
変形例
以上、ＭＰＥＧ２圧縮方式を適用した具体例により本発明を説明したが、本発明は、他の圧縮方式とともに実現することもできる。
【０１１６】
また、ＸＭＦファイルに基づいて本発明の具体例を説明したが、他の種類のファイルを用いて、上述のようにヘッダメタデータを繰り返し、ファイルにマッピングしてもよい。
【０１１７】
また、ＳＤＩ及びＳＤＴＩに基づいて本発明を説明したが、上述のようにヘッダメタデータをパケット化し、繰り返し、ビデオ又はオーディオフレームにマッピングすることができれば、他のフォーマットを用いてもよい。
【０１１８】
図１０〜図１２に示す具体例では、ＳＤＩをＳＤＴＩにマッピングし、続いてＳＤＴＩをＭＸＦファイルにマッピングした。変形例においては、ファイルボディが非圧縮ビデオデータを格納するＳＤＩをＭＸＦファイルに直接マッピングしてもよい。ヘッダメタデータは、オーディオフレームに格納され、又はファイルボディのＶＢＩラインに格納される。図１４に示す変形例では、ヘッダメタデータは、ヘッダメタデータ生成器３０により生成される。エンコーダ４４は、オーディオデータを符号化する。ＳＤＩエンコーダ３２は、非圧縮ビデオデータをアクティブデータ空間に挿入する。ヘッダメタデータは、上述と同様、非オーディオモードで動作するオーディオフレーム又はＶＢＩフレームのいずれかに挿入される。メタデータは、上述と同様、ＶＢＩ又はオーディオフレームにおいて、ＳＤＩビデオフレームに亘って繰り返される。レコーダ３８１は、圧縮ビデオデータを除くＳＤＩビットストリームを記録する。レコーダ３８１は、ディスクレコーダであっても、テープレコーダであってもよい。ＳＤＩビットストリームは、レコーダ３８１により再生され、抽出器４０は、ビデオ及びオーディオデータからヘッダメタデータを分離する。ＭＸＦファイル生成器４２は、図１に示すように、ヘッダメタデータをファイルヘッダにマッピングし、ビデオデータ及びオーディオデータをファイルボディにマッピングする。ＭＸＦファイルは、コンピュータネットワーク及び／又はコンピュータファイル記録装置４６に伝送してもよい。ＭＸＦファイルは、コンピュータネットワーク及び／又はコンピュータファイル記録装置４６から、レコーダ３８１と同様のレコーダ５４１に伝送できる。すなわち、ＭＸＦファイルは、コンピュータネットワーク及び／又はコンピュータファイル記録装置４６からＳＤＩエンコーダに供給され、ＳＤＩエンコーダは、上述のようにヘッダメタデータを繰り返すとともに、ＭＸＦファイルをＳＤＩビットストリームにマッピングする。レコーダ５４１は、ＳＤＩビットストリームを記録し、ＳＤＩビットストリームは、このレコーダ５４１から再生され、ＳＤＩデコーダ６０は、ヘッダメタデータ、ビデオデータ及びオーディオデータを分離する。
【０１１９】
本発明は、プログラミング可能なデジタル信号又はデータ処理装置により実現してもよい。また、本発明は、このようなプログラミング可能なデジタル信号又はデータ処理装置において実行され、本発明を実現するインストラクションを有するコンピュータプログラム製品として実現してもよい。
【図面の簡単な説明】
【図１】
ＭＸＦファイルの全体のデータ構造を示す図である。
【図２】
図１に示すヘッダメタデータの構造を示す図である。
【図３】
Ａ〜Ｄは、パケットストリームに亘るヘッダメタデータのマッピングを説明する図である。
【図４】
信号処理及びマテリアル伝送システムを示すブロック図である。
【図５】
ＳＤＩフィールドを示す図である。
【図６】
ＳＤＴＩ−ＣＰフレームを示す図である。
【図７】
ＳＤＴＩ−ＣＰコンテンツパッケージのデータ構造を示す図である。
【図８】
ＳＤＴＩ−ＣＰコンテンツパッケージに使用されるエレメントのモデルを示す図である。
【図９】
オーディオパケットを示す図である。
【図１０】
図４に示すシステムを実現するシステムの具体的構成を示す図である。
【図１１】
図４に示すシステムを実現するシステムの具体的構成を示す図である。
【図１２】
図４に示すシステムを実現するシステムの具体的構成を示す図である。
【図１３】
ＳＤＩ／ＳＤＴＩインタフェースを介してビデオ及びオーディオマテリアルをストリーミングし、及びコンピュータネットワークインタフェースを介してファイルを伝送するネットワークの構成を示す図である。
【図１４】
図４に示すシステムの変形例を示す図である。
【図１】
2004508777.tif 000003
【図２】
2004508777.tif 000004
【図３】
2004508777.tif 000005
【図４】
2004508777.tif 000006
【図５】
2004508777.tif 000007
【図６】
2004508777.tif 000008
【図７】
2004508777.tif 000009
【図８】
2004508777.tif 000010
【図９】
2004508777.tif 000011
【図１０】
2004508777.tif 000012
【図１１】
2004508777.tif 000013
【図１２】
2004508777.tif 000014
【図１３】
2004508777.tif 000015
【図１４】
2004508777.tif 000016
【国際公開パンフレット】
2004508777.tif 000017
2004508777.tif 000018
2004508777.tif 000019
2004508777.tif 000020
2004508777.tif 000021
2004508777.tif 000022
2004508777.tif 000023
2004508777.tif 000024
2004508777.tif 000025
2004508777.tif 000026
2004508777.tif 000027
2004508777.tif 000028
2004508777.tif 000029
2004508777.tif 000030
2004508777.tif 000031
2004508777.tif 000032
2004508777.tif 000033
2004508777.tif 000034
2004508777.tif 000035
2004508777.tif 000036
2004508777.tif 000037
2004508777.tif 000038
2004508777.tif 000039
2004508777.tif 000040
2004508777.tif 000041
2004508777.tif 000042
2004508777.tif 000043
2004508777.tif 000044
2004508777.tif 000045
2004508777.tif 000046
2004508777.tif 000047
2004508777.tif 000048
2004508777.tif 000049
2004508777.tif 000050
【国際調査報告】
2004508777.tif 000051
2004508777.tif 000052
2004508777.tif 000053