(57)【要約】  複数のレイヤを含むメディア・エンティティを複数のコンポーネント・ファイルにカプセル化する（レイヤごとに１つのコンポーネント・ファイルにカプセル化する）方法および装置について、それに対応するコンポーネント・ファイルを読み取る方法および装置とともに説明する。ＩＳＯ  ＢＭＦＦの新たなボックス、およびＳＶＣ／ＭＶＣファイル・フォーマットの抽出器データ構造の拡張を、提案する。この新たなボックスにより、参照したコンポーネント・ファイルに対するアクセスを、現在のコンポーネント・ファイルの処理と並行して行うことが可能になる。本発明の抽出器の拡張により、異なるコンポーネント・ファイルにまたがるＮＡＬユニットの参照が可能になる。本発明は、メディア・ファイルの適応型ＨＴＴＰストリーミングを可能にする。
2013532441.tif 000002
【特許請求の範囲】
【請求項１】
複数のレイヤを含むメディア・エンティティからコンポーネント・ファイルを作成する方法であって、
前記メディア・エンティティから各レイヤのメタデータを抽出するステップと、
前記メディア・エンティティから、前記メディア・エンティティの各レイヤの前記抽出したメタデータに対応するメディア・データを抽出するステップと、
前記抽出したメディア・データを前記抽出したメタデータと関連付けて、前記抽出したメタデータおよび前記抽出したメディア・データを含むコンポーネント・ファイルを前記各レイヤに作成することを可能にするステップと、を含む、前記方法。
【請求項２】
前記コンポーネント・ファイルが、動画ボックス、動画フラグメント、セグメントおよびファイルのうちの少なくとも１つである、請求項１に記載の方法。
【請求項３】
前記各レイヤに、前記メディア・エンティティから、前記各レイヤの前記抽出したメディア・データに関係する追加メディア・データを抽出するステップと、
対応するコンポーネント・ファイルの作成のため、各レイヤの前記抽出したメディア・データと前記追加メディア・データとを関連付けるステップと、をさらに含む、請求項１に記載の方法。
【請求項４】
各レイヤの前記抽出したメディア・データに関係する追加メディア・データの参照を識別するステップと、
対応するコンポーネント・ファイルの作成のため、前記参照を、各レイヤの前記抽出したメタデータおよび前記抽出したメディア・データと関連付けるステップと、をさらに含む、請求項１に記載の方法。
【請求項５】
前記メディア・データおよび前記追加メディア・データが、データ・サンプルを含む、請求項４に記載の方法。
【請求項６】
データ・サンプルが、ネットワーク抽象化レイヤ・ユニットを含む、請求項５に記載の方法。
【請求項７】
前記参照が、前記追加メディア・データ中の前記ネットワーク抽象化レイヤ・ユニットの統一資源ロケータおよび統一資源名のうちの少なくとも１つを含む、請求項６に記載の方法。
【請求項８】
前記参照を各レイヤの前記抽出したメタデータに埋め込むステップと、
前記参照の指標を前記抽出したメディア・データに付加するステップと、をさらに含む、請求項４に記載の方法。
【請求項９】
前記参照が、各レイヤの前記コンポーネント・ファイルの冒頭に配置される、請求項８に記載の方法。
【請求項１０】
前記参照が、メディア参照ボックスに記入され、前記指標が、抽出器に記入される、請求項８に記載の方法。
【請求項１１】
複数のレイヤを含むメディア・エンティティからコンポーネント・ファイルを作成するファイル・カプセル化装置であって、
前記メディア・エンティティから各レイヤのメタデータを抽出し、前記メディア・エンティティから前記メディア・エンティティの各レイヤの前記抽出したメタデータに対応するメディア・データを抽出する抽出器と、
前記抽出したメディア・データを前記抽出したメタデータと関連付けて、前記抽出したメタデータおよび前記抽出したメディア・データを含むコンポーネント・ファイルを前記各レイヤに作成することを可能にする相関器とを含む、前記ファイル・カプセル化装置。
【請求項１２】
前記コンポーネント・ファイルが、動画ボックス、動画フラグメント、セグメントおよびファイルのうちの少なくとも１つである、請求項１１に記載のファイル・カプセル化装置。
【請求項１３】
前記抽出器が、さらに、前記各レイヤに、前記メディア・エンティティから、前記各レイヤの前記抽出したメディア・データに関係する追加メディア・データを抽出し、
前記相関器が、さらに、各レイヤの前記抽出したメディア・データと前記追加メディア・データとを関連付けて、対応するコンポーネント・ファイルを作成する、請求項１１に記載のファイル・カプセル化装置。
【請求項１４】
前記メディア・エンティティから、各レイヤの前記抽出したメディア・データに関係する追加メディア・データの参照を識別する参照識別器をさらに含み、前記相関器によって、前記参照を、各レイヤの前記抽出したメタデータおよび前記抽出したメディア・データと関連付けて、対応するコンポーネント・ファイルを作成する、請求項１１に記載のファイル・カプセル化装置。
【請求項１５】
前記メディア・データおよび前記追加メディア・データが、データ・サンプルを含む、請求項１４に記載のファイル・カプセル化装置。
【請求項１６】
データ・サンプルが、ネットワーク抽象化レイヤ・ユニットを含む、請求項１５に記載のファイル・カプセル化装置。
【請求項１７】
前記参照が、前記追加メディア・データ中の前記ネットワーク抽象化レイヤ・ユニットの統一資源ロケータおよび統一資源名のうちの少なくとも１つを含む、請求項１６に記載のファイル・カプセル化装置。
【請求項１８】
前記相関器が、さらに、前記参照を、各レイヤの前記抽出したメタデータに埋め込み、前記参照の指標を、前記抽出したメディア・データに付加する、請求項１４に記載のファイル・カプセル化装置。
【請求項１９】
前記相関器が、前記参照を、各レイヤの前記コンポーネント・ファイルの冒頭に配置する、請求項１８に記載のファイル・カプセル化装置。
【請求項２０】
前記参照が、メディア参照ボックスに記入され、前記指標が、抽出器に記入される、請求項１９に記載のファイル・カプセル化装置。
【請求項２１】
コンポーネント・ファイルを読み取る方法であって、
前記コンポーネント・ファイルを構文解析して、メタデータ、メディア・データおよび参照を取得するステップと、
前記参照によれば、前記コンポーネント・ファイルの前記メディア・データがその他のコンポーネント・ファイルのメディア・データに関係している場合に、前記参照を用いて前記その他のコンポーネント・ファイルから前記関係するメディア・データを取り出すステップと、を含む、方法。
【請求項２２】
前記コンポーネント・ファイルの前記メディア・データが、符号化依存性に従ってその他のコンポーネント・ファイルのメディア・データに関係付けられる、請求項２１に記載の方法。
【請求項２３】
前記メディア・データおよび前記関係するメディア・データが、データ・サンプルを含む、請求項２１に記載の方法。
【請求項２４】
データ・サンプルが、ネットワーク抽象化レイヤ・ユニットを含む、請求項２３に記載の方法。
【請求項２５】
前記メタデータを構文解析して前記参照を取得するステップをさらに含む、請求項２１に記載の方法。
【請求項２６】
前記メディア・データを構文解析して、その中に埋め込まれた参照指標を取得するステップと、
前記参照指標に従って対応する参照を取得するステップと、をさらに含む、請求項２５に記載の方法。
【請求項２７】
前記取り出すステップが、
前記参照に従って、前記その他のコンポーネント・ファイルを並列に取り出すステップを含む、請求項２５に記載の方法。
【請求項２８】
前記取り出すステップが、
ローカルなファイル記憶装置を確認するステップと、
前記ローカルなファイル記憶装置が前記その他のコンポーネント・ファイルを含む場合に、前記ローカルな記憶装置から前記その他のコンポーネント・ファイルを取り出すステップと、をさらに含む、請求項２７に記載の方法。
【請求項２９】
コンポーネント・ファイルを構文解析して、メタデータ、メディア・データおよび参照を取得するパーサと、
前記参照に従って、その他のコンポーネント・ファイルから前記メディア・データに関係するメディア・データを取り出すリトリーバと、
前記メタデータ、前記メディア・データ、および前記その他のコンポーネント・ファイルから取り出したメディア・データを処理するプロセッサと、を含む、ファイル読取り装置。
【請求項３０】
前記コンポーネント・ファイルの前記メディア・データが、符号化依存性の観点でその他のコンポーネント・ファイルのメディア・データに関係付けられる、請求項２９に記載のファイル読取り装置。
【請求項３１】
前記メディア・データおよび前記関係するメディア・データが、データ・サンプルを含む、請求項２９に記載のファイル読取り装置。
【請求項３２】
データ・サンプルが、ネットワーク抽象化レイヤ・ユニットを含む、請求項３１に記載のファイル読取り装置。
【請求項３３】
前記プロセッサが、ビデオ・デコーダを含む、請求項２９に記載のファイル読取り装置。
【請求項３４】
前記パーサが、前記参照を取得する手段をさらに含む、請求項２９に記載のファイル読取り装置。
【請求項３５】
前記パーサが、さらに、前記メディア・データを構文解析して、その中に埋め込まれた参照指標を取得し、前記参照指標に従って対応する参照を取得する、請求項３４に記載のファイル読取り装置。
【請求項３６】
前記リトリーバが、さらに、前記取得した参照に従って、前記その他のコンポーネント・ファイルを並列に取り出す、請求項３４に記載のファイル読取り装置。
【請求項３７】
前記リトリーバが、さらに、ローカルなファイル記憶装置を確認し、前記ローカルなファイル記憶装置が前記その他のコンポーネント・ファイルを含む場合には、前記ローカルな記憶装置から前記その他のコンポーネント・ファイルを取り出す、請求項３６に記載のファイル読取り装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本特許出願は、２０１０年６月１４日出願の「Ｅｘｔｅｎｓｉｏｎ  ｔｏ  ｔｈｅ  Ｅｘｔｒａｃｔｏｒ  ｄａｔａ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＳＶＣ／ＭＶＣ  ｆｉｌｅ  ｆｏｒｍａｔｓ」と題する米国仮特許出願第６１／３５４，４２２号、および２０１０年６月１４日出願の「Ｓｏｍｅ  ｅｘｔｅｎｓｉｏｎｓ  ｆｏｒ  ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ  ｆｏｒ  ＨＴＴＰ  ｓｔｒｅａｍｉｎｇ」と題する米国仮特許出願第６１／３５４，４２４号の優先権の利益を主張するものである。
【０００２】
本願は、本願と同時に出願された「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｅｎｃａｐｓｕｌａｔｉｎｇ  Ｃｏｄｅｄ  Ｍｕｌｔｉ−ｃｏｍｐｏｎｅｎｔ  Ｖｉｄｅｏ」と題する、同時係属の所有者が共通の米国特許出願第＿／＿号（代理人番号ＰＵ１００１４０）に関連するものである。
【０００３】
本発明は、一般に、ＨＴＴＰストリーミングに関する。さらに詳細には、本発明は、ＨＴＴＰストリーミングのスケーラブル・ビデオ符号化（ＳＶＣ）ストリームやマルチビュー符号化（ＭＶＣ）ストリームなどの符号化マルチコンポーネント・ビデオ・ストリームのメディア・エンティティのカプセル化に関する。
【背景技術】
【０００４】
ＨＴＴＰストリーミングの分野では、サーバ側で、ＭＰ４ファイルなどのＢＭＦＦに準拠したファイルとして、符号化ビデオをカプセル化して記憶することが多い。さらに、適応型ＨＴＴＰストリーミングを実現するために、通常は、ファイルは、複数の動画フラグメントに分割され、これらのフラグメントが、さらに、クライアントＵＲＬ要求によってアドレス可能な複数のセグメントにグループ化される。実際には、これらのセグメントには、ビデオ・コンテンツの様々な符号化表現が記憶され、クライアントが、所望の表現を動的に選択して、セッション中にダウンロードして再生することができるようになっている。
【０００５】
ＳＶＣやＭＶＣのビットストリームなど、符号化された階層型ビデオは、ビットストリームの様々なサブセットを復号することによって、時間的／空間的解像度、画質、ビューなどに関して様々な動作点すなわち表現を可能にすることにより、このようなビットレート適応の自然なサポートを実現する。しかし、ＭＰ４ファイル・フォーマットなど、既存のＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ（ＢＭＦＦ）規格は、各レイヤまたは表現への個別アクセスに対応していないので、ＨＴＴＰストリーミング分野に適用することができない。図１に示すように、ＭＰ４ファイル・フォーマットでは、１つのメディア・ファイルの全てのレイヤまたは表現のメタデータは、ｍｏｏｖ動画ボックスに記憶され、一方、全てのレイヤまたは表現のメディア・コンテンツ・データは、ｍｄａｔ動画ボックスに記憶される。ＨＴＴＰストリーミングでは、クライアントが１つのレイヤを要求したとき、全てのレイヤまたは表現が混ざった状態であり、所要のレイヤまたは表現がどこで見つかるのかクライアントには分からないので、ファイル全体を送信しなければならない。
【０００６】
後述のように、適応型ＨＴＴＰストリーミングの分野では、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットなどのメディア・データ・サンプルを、動画フラグメントまたはコンポーネント・ファイルの境界をまたいで参照することができることが望ましい。ＳＶＣ／ＭＶＣの状況では、このような参照は、「抽出器」などの機構を用いることによって実現することができる。「抽出器」は、以下のＢＭＦＦのＡＶＣファイル・フォーマット拡張に対するＳＶＣ／ＭＶＣ補正に定義される、内部ファイル・データ構造である。Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  −  ｃｏｄｉｎｇ  ｏｆ  ａｕｄｉｏ−ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ  −  Ｐａｒｔ  １５：Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  （ＡＶＣ）  Ｆｉｌｅ  ｆｏｒｍａｔ，  Ａｍｅｎｄｍｅｎｔ  ２：Ｆｉｌｅ  ｆｏｒｍａｔ  ｓｕｐｐｏｒｔ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ，２００８，１５〜１７ページ。抽出器は、コピーを行わずに、参照によってその他のトラックからＮＡＬユニットを抽出することを可能にするように設計されている。ここで、トラックとは、ＩＳＯベース・メディア・ファイル中の関連するサンプルの時限シーケンスである。メディア・データでは、トラックは、画像またはサンプリングした音声のシーケンスに対応する。抽出器のシンタックスを、以下に示す。
class aligned(8) Extractor () {
NALUnitHeader( );
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_length;
}
【０００７】
抽出器データ構造のセマンティクスは、以下の通りである。
ＮＡＬＵｎｉｔＨｅａｄｅｒ：タイプ２０のＮＡＬユニットのＩＳＯ／ＩＥＣ  １４４９６−１０  Ａｎｎｅｘ  Ｇに指定されるＮＡＬユニット構造：
ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、抽出器ＮＡＬユニット・タイプ（タイプ３１）に設定されるものとする。
ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ、ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔおよびｒｅｓｅｒｖｅｄ＿ｔｈｒｅｅ＿２ｂｉｔｓは、ＩＳＯ／ＩＥＣ  １４４９６−１０  Ａｎｎｅｘ  Ｇに指定されるように設定されるものとする。
その他のフィールド（ｎａｌ＿ｒｅｆ＿ｉｄｃ、ｉｄｒ＿ｆｌａｇ、ｐｒｉｏｒｉｔｙ＿ｉｄ、ｎｏ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｆｌａｇ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｕｓｅ＿ｒｅｆ＿ｂａｓｅ＿ｐｉｃ＿ｆｌａｇ、ｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇおよびｏｕｔｐｕｔ＿ｆｌａｇ）は、Ｂ．４  ｏｆ  Ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ  −  Ｃｏｄｉｎｇ  ｏｆ  ａｕｄｉｏ−ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ  −  ｐａｒｔ  １５：Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  （ＡＶＣ）  ｆｉｌｅ  ｆｏｒｍａｔ，Ａｍｅｎｄｍｅｎｔ  ２：Ｆｉｌｅ  ｆｏｒｍａｔ  ｓｕｐｐｏｒｔ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ，ＩＳＯ／ＩＥＣ  １４４９６−１５：２００４／Ａｍｄ．２：２００８，１７ページに指定されるように設定されるものとする。
【０００８】
ｔｒａｃｋ＿ｒｅｆ＿ｉｎｄｅｘは、データを抽出するトラックを発見するために使用するタイプ「ｓｃａｌ」のトラック参照の指標を指定する。データが抽出されるトラック中のサンプルは、メディア復号タイムライン中で、すなわち時間／サンプル・テーブルのみを使用して、抽出器を含むサンプルと時間的に整列される、またはそれより先行する最も近い位置に位置し、ｓａｍｐｌｅ＿ｏｆｆｓｅｔによって指定されるオフセットだけ調節される。第１のトラック参照は、指標値１を有する。値０は予約される。
【０００９】
ｓａｍｐｌｅ＿ｏｆｆｓｅｔは、情報源として使用すべきリンクされたトラック中のサンプルの相対指標を与える。サンプル０（ゼロ）は、抽出器を含むサンプルの復号時間と比較して、同じ復号時間またはそれより先行する最も近い復号時間を有するサンプルである。サンプル１（イチ）は、次のサンプルであり、サンプル−１（マイナス１）は、前のサンプルである。以下同様に続く。
【００１０】
ｄａｔａ＿ｏｆｆｓｅｔ：コピーする参照サンプル内の最初のバイトのオフセットである。サンプル中のデータの最初のバイトから抽出が開始される場合には、オフセットは、値０をとる。オフセットは、ＮＡＬユニット長さフィールドの冒頭を参照するものとする。
【００１１】
ｄａｔａ＿ｌｅｎｇｔｈ：コピーするバイト数である。このフィールドが値０をとる場合には、参照した１つのＮＡＬユニットの全体がコピーされる（すなわち、コピーする長さは、データ・オフセットによって参照した長さフィールドからとり、Ａｇｇｒｅｇａｔｏｒの場合にはａｄｄｉｔｉｏｎａｌ＿ｂｙｔｅｓフィールドで増補する）。
【００１２】
さらなる詳細は、Ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ  −  Ｃｏｄｉｎｇ  ｏｆ  ａｕｄｉｏ−ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ  −  ｐａｒｔ  １５：Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  （ＡＶＣ）  ｆｉｌｅ  ｆｏｒｍａｔ，Ａｍｅｎｄｍｅｎｔ  ２：Ｆｉｌｅ  ｆｏｒｍａｔ  ｓｕｐｐｏｒｔ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ，ＩＳＯ／ＩＥＣ  １４４９６−１５：２００４／Ａｍｄ．２：２００８に見ることができる。
【００１３】
現在のところ、抽出器は、参照によってＮＡＬユニットを他のトラックから抽出することはできるが、同じ動画ボックス／フラグメント内から抽出することしかできない。換言すれば、抽出器を使用しても、別のセグメントまたはファイルからＮＡＬユニットを抽出することはできない。この制約により、抽出器の使用は上記の使用事例に制限されている。
【００１４】
クライアントがサーバから１つのメディア・コンテンツの１つまたは複数のコンテンツ・コンポーネントを既にダウンロードしており、別のコンテンツ・コンポーネントをダウンロードするプロセスに入っている場合、クライアントは、必要に応じて完全なコンポーネント・セットをダウンロードするその他の要求を行うことができるように、以前にダウンロードしたコンテンツ・コンポーネントが、新たなコンテンツ・コンポーネントの依存性コンポーネントのセットの中に含まれるかどうかを知る必要がある。この使用事例でも、外部依存性コンテンツ・コンポーネントおよびその位置情報を信号通信する機構が必要である。
【００１５】
ＢＭＦＦでは、提示中の含んでいるトラックから別のトラックへの参照を実現するために使用される、「ｔｒｅｆ」と呼ばれるボックス・タイプがある。このボックスを使用して、トラック間の依存性を記述することができるが、その依存性は、同じメディア・ファイル内のトラックに限定される。
【００１６】
１つの手法は、何らかの帯域外機構を用いてこの情報を信号通信するものである。例えば、ＨＴＴＰストリーミングの分野では、サーバは、セッションの開始前に、クライアントにマニフェスト・ファイルを送信することができる。マニフェスト・ファイルは、要求されたメディア・コンテンツの各コンテンツ・コンポーネントの依存性および位置情報を含むファイルである。この場合、クライアントは、必要な全てのコンポーネント・ファイルを要求することができる。ただし、この帯域外手法は、マニフェスト・ファイルが利用できないローカルなファイル再生には適用することができない。
【００１７】
上述の問題に対する従来の解決策は、当技術分野ではまだ十分に確立されていない。速度およびトランスポート効率を犠牲にすることなく、複数のレイヤを構文解析してカプセル化することができるようになれば、望ましいであろう。このような成果は、当技術分野では、これまでのところまだ達成されていない。
【００１８】
本発明は、複数のレイヤを含むメディア・エンティティからコンポーネント・ファイルをカプセル化し、コンポーネント・ファイルを読み取る、方法および装置に関する。
【００１９】
本発明の１つの態様によれば、複数のレイヤを含むメディア・エンティティからコンポーネント・ファイルをカプセル化して作成する方法が提供される。この方法では、メディア・エンティティから、各レイヤに、メタデータを抽出し、その抽出したメタデータに対応するメディア・データを抽出する。抽出したメディア・データとメタデータとを関連付けて、抽出したメタデータおよび抽出したメディア・データを含むコンポーネント・ファイルを各レイヤに作成することを可能にする。
【００２０】
本発明の別の態様によれば、ファイル・カプセル化装置が提供される。このファイル・カプセル化装置は、メディア・エンティティから各レイヤにメタデータを抽出し、且つ抽出したメタデータに対応するメディア・データを抽出する抽出器と、抽出したメディア・データを抽出したメタデータと関連付けて、各レイヤにコンポーネント・ファイルを作成することを可能にする相関器とを含む。
【００２１】
本発明の上記の特徴は、添付の図面を参照しながらその例示的な実施例について詳細に説明することにより、さらに明らかになるであろう。
【図面の簡単な説明】
【００２２】
【図１】例示的なＭＰ４ファイル・フォーマットを示す図である。
【図２】メディア・エンティティをカプセル化する本発明の一実施例を示す図である。
【図３】複数のレイヤ／表現を含むメディア・エンティティからコンポーネント・ファイルをカプセル化または作成するために使用されるカプセル化装置の構造を示す図である。
【図４】依存関係に基づいて追加メディア・データをコンポーネント・ファイルと関連付ける一例を示す図である。
【図５】抽出器が存在する動画ボックス／フラグメントとは異なる動画ボックス／フラグメントから参照によってＮＡＬユニットを抽出する一例を示す図である。
【図６】本発明の新たな抽出器データ構造の１つを用いた、ＳＶＣ／ＭＶＣタイプ・ビデオ・ビットストリームから複数のコンポーネント・ファイルへの関連するカプセル化動作を示す図である。
【図７】コンポーネント・ファイルを読み取るために使用されるファイル読取り装置の構造を示す図である。
【図８】本発明の一実施例を含むビデオ・デコーダの、カプセル化されたコンポーネント・ファイルを読み取るプロセスを示す図である。
【図９】別の好ましい新たな抽出器データ構造を用いた、ＳＶＣ／ＭＶＣタイプ・ビデオ・ビットストリームから複数の動画フラグメントへのカプセル化動作を示す図である。
【図１０】本発明の別の実施例を含むビデオ・デコーダの、カプセル化されたコンポーネント・ファイルを読み取るプロセスを示す図である。
【発明を実施するための形態】
【００２３】
本発明では、メディア・ファイルもしくはメディア・ファイル・セットまたはストリーミング・メディアなどのメディア・エンティティを、クライアントＵＲＬ要求によってアドレス可能な複数の動画コンポーネント・ファイルに分割またはカプセル化する。ここでは、コンポーネント・ファイルは、フラグメント、セグメント、ファイル、およびその他のそれらと等価な用語を表す広い意味で用いられる。
【００２４】
本発明の一実施例では、複数の表現またはコンポーネントを含むメディア・エンティティを構文解析して、各表現／コンポーネントのメタデータおよびメディア・データを抽出する。この表現／コンポーネントの例としては、様々な時間的／空間的解像度を有するレイヤなどのレイヤ、ＳＶＣの画質レイヤなどのレイヤ、およびＭＶＣのビューなどがある。以下では、レイヤも、表現／コンポーネントを指すために使用され、これらの用語は、入れ替え可能である。メタデータは、例えば、各表現のメディア・エンティティに何が含まれているか、またそこに含まれるメディア・データをどのように使用するかを記述している。メディア・データは、例えばコンテンツの復号など、メディア・データの目的を実施するのに必要なメディア・データ・サンプル、または所要のデータ・サンプルを取得する方法に関する任意の必要な情報を含む。各表現またはレイヤの抽出されたメタデータおよびメディア・データは、関連付け／相関付けされ、ユーザのアクセスに備えて一緒に記憶される。記憶動作は、ハード・ドライブまたはその他の記憶媒体上で物理的に行ってもよいし、あるいは、メタデータおよびメディア・データが実際には記憶媒体上の異なる場所に位置しているときでも、その他のアプリケーションまたはモジュールとのインタフェースをとったときに、それらが一緒に記憶されているように見えるように、関係管理機構を介して仮想的に実行してもよい。図２は、この実施例の例を示す。図２では、メディア・エンティティは、ベース・レイヤ、エンハンスメント・レイヤ１、およびエンハンスメント・レイヤ２の３つのレイヤを含む。メディア・エンティティを構文解析して、３つのレイヤそれぞれのメタデータおよびメディア・データを抽出し、これらのデータを、関連付けられたメタデータと対応するメディア・データとを備えるコンポーネント・ファイルとして、別々に記憶する。
【００２５】
図３は、ＳＶＣ符号化ビデオなど、複数のレイヤを含むメディア・エンティティからコンポーネント・ファイルをカプセル化して作成するために使用される好ましいカプセル化装置３００の構造を示す。入力メディア・エンティティ３１０は、メタデータ抽出器３２０およびメディア・データ抽出器３４０に渡される。メタデータ抽出器３２０は、各レイヤのメタデータ３３０を抽出する。メディア・データ抽出器３４０は、メタデータ３３０を取り込み、対応するメディア・データ３５０を抽出する。なお、別の実施例では、メタデータ抽出器３２０およびメディア・データ抽出器３４０は、１つの抽出器として実施されることに留意されたい。メタデータ３３０およびメディア・データ３５０の両データは、これら２つのタイプのデータを関連付けて出力コンポーネント・ファイル３９０を作成する相関器３８０に送られる。コンポーネント・ファイルは、各レイヤに１つ作成される。
【００２６】
ＳＶＣまたはＭＶＣのＡＶＣ拡張によって符号化されたビデオなど、階層型ビデオは、複数のメディア・コンポーネント（スケーラブルなレイヤまたはビュー）を含む。このような符号化ビットストリームは、ビットストリームの様々なサブセットを復号することによって、時間的／空間的解像度、画質、ビューなどに関して様々な動作点すなわち表現またはレイヤを提供することができる。さらに、ビットストリームのレイヤ間には、符号化依存性がある、すなわち、１つのレイヤの復号が、他のレイヤに依存する場合がある。従って、このようなビットストリームの表現のうちの１つを要求する際には、カプセル化ビデオ・ファイルから１つまたは複数のコンポーネントまたはメディア・データを取り出して復号する必要がある場合がある。様々な表現の抽出プロセスを容易にするために、符号化階層型ビデオは、各レイヤが異なるセグメントまたはコンポーネント・ファイルに別々に記憶されるような方法でＭＰ４ファイルにカプセル化されることが多い。この場合には、上述の復号依存性またはアプリケーションによるその他の依存性によって、ＮＡＬユニットなど、ビットストリームの特定のメディア・データ・サンプルが、複数のセグメントまたはコンポーネント・ファイルによって必要とされる、またはそれらと関係付けられることを考慮する必要がある。
【００２７】
本発明の別の実施例では、セグメントまたはコンポーネント・ファイルによって必要とされる追加メディア・データを抽出して、当該セグメントまたはコンポーネント・ファイルと関連付ける。図４は、この実施例の例を示す。この図では、ＳＶＣビットストリームは、３つの空間レイヤ、ＨＤ１０８０ｐ、ＳＤおよびＱＶＧＡを有する。３つの動画フラグメントまたはコンポーネント・ファイルは、これら３つの動作点に対応して形成され、それぞれが異なるＵＲＬによってアドレス可能である。各動画フラグメントまたはコンポーネント・ファイル内で、復号に必要な全てのメディア・データ・サンプル（この例ではＮＡＬユニット）がコピーされ、「ｍｄａｔ」ボックスに収納されるメディア・サンプルとして記憶される。そのため、クライアントが適切なＵＲＬを用いて特定の動作点または表現を要求したとき、サーバは、対応する動画フラグメントまたはコンポーネント・ファイルを取り出して、クライアントに転送することができる。この実施例では、図３のメディア・データ抽出器３４０は、さらに各レイヤに、入力メディア・エンティティ３１０から、各レイヤに抽出したメディア・データに関係する追加メディア・データを抽出する。相関器３８０は、さらに、この各レイヤの追加の抽出メディア・データを関連付けて、対応するコンポーネント・ファイルを作成する。
【００２８】
記憶スペースを節約するために、各コンポーネント・ファイル内の同じデータを実際に複製することなく、複数の動画フラグメントまたはコンポーネント・ファイルの境界をまたいで、ＮＡＬユニットなどのメディア・データ・サンプルを参照することができることが望ましい。しかし、ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ（ＢＭＦＦ）およびその拡張では、現在のところこの機能に対応していない。この問題を解決するために、本発明のさらに別の実施例では、動画フラグメントまたはコンポーネント・ファイルのメディア・データと関係付けられる、またはこれによって必要とされる追加メディア・データについて、参照を識別して構築する。これらの追加メディア・データではなく、この参照を、そのメタデータおよびメディア・データとともにコンポーネント・ファイルと関連付ける。参照は、各レイヤの抽出メディア・データに埋め込むことができ、その後、各レイヤの抽出メタデータおよび抽出メディア・データを関連付けて、対応するコンポーネント・ファイルを作成することができる。
【００２９】
この実施例では、カプセル化装置３００の構造に参照識別器３６０が追加される。参照識別器３６０は、入力メディア・エンティティ３１０から、各レイヤの抽出メディア・データ３５０に関係するそれらの追加メディア・データに対する参照３７０を識別する。次いで、相関器３８０により、例えば参照３７０を抽出メディア・データ３５０に埋め込むことによって、参照３７０を各レイヤの抽出メタデータ３３０および抽出メディア・データ３５０と関連付けて、対応するコンポーネント・ファイル３９０を作成する。
【００３０】
上述のように、ＳＶＣ／ＭＶＣの状況では、このような参照は、「抽出器」などの機構を用いることによって構築することができる。現在のところ、抽出器は、参照によってＮＡＬユニットを他のトラックから抽出することはできるが、同じ動画ボックス／フラグメント内から抽出することしかできない。換言すれば、抽出器を使用しても、別のセグメントまたはファイルからＮＡＬユニットを抽出することはできない。この制約により、他のケースの抽出器の使用は制限されている。以下、抽出器データ構造の拡張を開示するが、この拡張は、上述したＳＶＣ／ＭＶＣタイプの階層型ビデオ・コンテンツから複数のコンポーネント・ファイルへの効率的なカプセル化をサポートすることを目的とするものである。
【００３１】
この拡張は、抽出器が存在する動画ボックス／フラグメントまたはコンポーネント・ファイルとは異なる動画ボックス／フラグメントまたはコンポーネント・ファイルに存在するＮＡＬユニットを参照する追加機能を有する抽出器データ構造を提供するために追加されるものである。
【００３２】
拡張された抽出器は、以下のように定義される。
【００３３】
シンタックス：
aligned (8) class DataEntryUrlBox (bit  (24)  flags)
extends FullBox ('url', version = 0,  flags) {
string location;
}
aligned (8) class DataEntryUrnBox (bit  (24)  flags)
extends FullBox ('urn', version = 0,  flags) {
string name;
string location;
}
class aligned (8) Extractor () {
NALUnitHeader ( );
DataEntryBox (entry_version, entry_flags)  data_entry;// added extension
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_length;
}
【００３４】
セマンティクス：
ｄａｔａ＿ｅｎｔｒｙは、統一資源ロケータ（ＵＲＬ）または統一資源名（ＵＲＮ）エントリである。名称はＵＲＮであり、ＵＲＮエントリで必要である。位置はＵＲＬであり、ＵＲＬエントリで必要であるが、ＵＲＮエントリでは任意選択であり、所与の名称を有する資源が見つかる位置を与える。それぞれはＵＴＦ−８文字を用いたナル終了文字列である。自立フラグがセットされた場合には、ＵＲＬフォームを使用し、文字列は存在せず、ボックスはエントリ・フラグ・フィールドで終了する。ＵＲＬタイプは、ファイルを配信するサービスのものとする。相対ＵＲＬは許容されるが、抽出器が属するトラックを含む動画ボックス／フラグメントを含むファイルに関するものである。
【００３５】
その他のフィールドは、前述の元の抽出器と同じセマンティクスを有する。
【００３６】
拡張された抽出器では、参照によって、抽出器が存在する動画ボックス／フラグメントとは異なる動画ボックス／フラグメントから、ＮＡＬユニットを抽出することができる。図５は、このような例を示し、ＳＶＣビットストリームは図４と同じであるが、新たな拡張された抽出器データ構造を用いている。この図から分かるように、ＳＤの動画フラグメントは、ＱＶＧＡの動画フラグメントのＮＡＬユニットを参照することができる。同様に、ＨＤ１０８０ｐの動画フラグメントは、抽出器を使用して、ＱＶＧＡおよびＳＤの両方の動画フラグメントのＮＡＬユニットを参照することができる。図４と比較すると、これらの動画フラグメントをまたいで複製されるＮＡＬユニットは存在せず、従って、記憶スペースが節約される。
【００３７】
図６は、本発明の新しい抽出器データ構造を用いた、ＳＶＣ／ＭＶＣタイプのビデオ・ビットストリームから複数の動画フラグメントまたはコンポーネント・ファイルへの関連するカプセル化動作を示す。このプロセスは、ステップ６０１で開始される。ステップ６１０で、各ＮＡＬユニットを１つ１つ読み込む。ステップ６２０で、ビットストリームの末尾に到達した場合には、プロセスは、６９０で停止し、そうでない場合には、プロセスは、次のステップ６３０に進む。判断ステップ６３０では、現在のＮＡＬユニットが復号に際して他のトラックのＮＡＬユニットに依存するかどうかを判定する。この判定の結果が、現在のＮＡＬユニットが復号に際して他のトラックのＮＡＬユニットに依存しない場合には、制御はステップ６４０に移り、現在のＮＡＬユニットを用いてサンプルが形成され、現在のトラック中に配置される。ステップ６３０の判定の結果、現在のＮＡＬユニットと他のトラックのＮＡＬユニットの間に依存性がある場合には、プロセスは、ステップ６５０に進む。判断ステップ６５０では、現在のＮＡＬユニットによって必要とされるＮＡＬユニットのトラックが同じ動画フラグメント内に存在するかどうかをさらに判定する。この判定の結果、トラックが同じ動画フラグメント内に存在する場合には、ステップ６７０を利用して、拡張された抽出器に記入（ｆｉｌｌ  ｉｎ）して、当該他のトラックのＮＡＬユニットを参照する。判定の結果、トラックが別の動画フラグメント内に存在する場合には、ステップ６６０で、この動画フラグメントのＵＲＬまたはＵＲＮを識別し、この識別したＵＲＬおよびＵＲＮを拡張された抽出器に記入するものとして、プロセスは、ステップ６７０に進む。この拡張された抽出器は、記入後に、ステップ６８０で現在のトラックに埋め込まれる。その後、ステップ６１０で、次のＮＡＬユニットのプロセスが開始される。
【００３８】
別の実施例では、相関器３８０によって、参照３７０が抽出メタデータ３３０に埋め込まれ、参照３７０の指標が抽出メディア・データ３５０に付加される。相関器３８０は、さらに、各レイヤのメタデータとメディア・データを関連付けて、対応するコンポーネント・ファイル３９０を作成する。ＩＳＯ  Ｍｅｄｉａ  Ｂａｓｅ  Ｆｉｌｅ  Ｆｏｒｍａｔの状況では、ＨＴＴＰストリーミング情報ボックスと呼ばれるボックスが開示されている。このボックスは、ＩＳＯファイルのＨＴＴＰストリーミングを補助することができる情報を含む。ＨＴＴＰストリーミング情報ボックスは、例えばファイルの冒頭など、できる限り早い段階でコンポーネント・ファイル中に配置されることが好ましい。このボックスは、サーバがクライアントに対するマニフェスト・ファイルを形成するときのソースとして機能することもできる。ＨＴＴＰストリーミング情報ボックスに含まれる、メディア参照ボックスと呼ばれる別のタイプのボックスも、開示されている。このボックスは、外部依存ファイルに関する情報を含む。抽出器構造は、さらに、異なるコンポーネント・ファイルをまたいで複数のメディア・サンプルを参照することができるように拡張される。メディア参照ボックスに含まれる情報は、抽出器が信号通信のオーバヘッドを節約するために利用することができる。
【００３９】
提案したＨＴＴＰストリーミング情報ボックス、メディア参照ボックスおよびさらに改良された抽出器の詳細な定義は、以下の通りである。
【００４０】
ＨＴＴＰストリーミング情報ボックス
定義：
ボックス・タイプ：'hsin'
コンテナ：ファイル
必須：いいえ
量：０または１
【００４１】
ＨＴＴＰストリーミング情報ボックスは、ＩＳＯメディア・ファイルのＨＴＴＰストリーミング動作を補助する。ＨＴＴＰストリーミング情報ボックスは、考えられる他のタイプのボックスの中でも特に、以下に定義するメディア参照ボックスを含む、ファイルのＨＴＴＰストリーミング配信に関する関連情報を含む。ＨＴＴＰストリーミング情報ボックスは、可用性を最大限に高めるために、できる限り早い段階でファイル中に配置することが好ましい。
【００４２】
シンタックス：
aligned(8) class HTTPStreamingInfoBox  extends Box ('hsin') {
}
【００４３】
メディア参照ボックス
定義：
ボックス・タイプ：'mref'
コンテナ：'hsin'
必須：いいえ
量：０または１
【００４４】
メディア参照ボックスは、ＨＴＴＰストリーミング情報ボックスに含まれ、当該ボックス内に含まれる各トラックが依存する外部ファイルの位置を宣言するＵＲＬの形態をしたデータ参照のテーブルを含む。このボックスを読み取ることにより、ファイル読取り装置は、外部コンポーネント・ファイルなど、ファイル中のトラックの外部依存ファイル・ソースと、それらを取り出すための手段とを識別することができる。
【００４５】
シンタックス：
aligned(8) class DataEntryUrlBox ( bit(24)  flags ) extends Box ( 'url') {
string location;
}
aligned(8) class MediaReferenceBox  extends  Box ('mref' ) {
unsigned int(16) entry_count;
for ( i = 1;i <= entry_count;i++) {
unsigned int(32) track_ID;
unsigned int(16) dependent_source_count;
for ( j = 1;j <=  dependent_source_count;j++){
DataEntryUrlBox data_entry;
}
}
}
【００４６】
セマンティクス：
ｅｎｔｒｙ＿ｃｏｕｎｔは、実際のエントリをカウントした整数である。
ｔｒａｃｋ＿ＩＤは、ボックスが適用されるファイル中のトラックを一意に識別する整数である。
ｄｅｐｅｎｄｅｎｔ＿ｓｏｕｒｃｅ＿ｃｏｕｎｔは、ｔｒａｃｋ＿ＩＤを有するファイル中のトラックが依存する外部メディア・ソースをカウントした整数である。
ｄａｔａ＿ｅｎｔｒｙは、指定されたトラックが依存する１つの外部メディア・ソースを指すＵＲＬエントリである。それぞれは、ＵＴＦ−８文字を用いたナル終了文字列である。ＵＲＬタイプは、ファイルを配信するサービスのものとする。相対ＵＲＬは許容されるが、このメディア参照ボックスを含むファイルに関するものである。
【００４７】
上記で定義したメディア参照ボックスは、複数のレイヤを含むメディア・エンティティのＨＴＴＰストリーミングをいくつかの方法で容易にするように設計される。
【００４８】
第１に、メディア参照ボックスは、参照テーブルによってコンポーネント・ファイルの冒頭でコンポーネント・ファイル間の依存関係を明示的に信号通信することができる。従って、クライアントは、コンポーネント・ファイルのわずかな部分を一度ダウンロードした後は、その１つまたは複数のトラックの関連する外部コンポーネント・ファイルを全て知ることができ、必要に応じて、テーブルに含まれる参照により、対応する要求を行って、１つまたは複数の完全なセットを再生のために取得することができる。
【００４９】
第２に、このボックスのファイル内情報は、容易に抽出して、マニフェスト・ファイルに含めることができる。この情報をマニフェスト中に含めることで、クライアントが実際のＨＴＴＰストリーミングより前に、関連サービス情報を発見し、例えば全ての関連コンポーネント・ファイルの要求や必要なバッファ資源の割当てなど対応するサービス初期化を実行するのを助けることができる。
【００５０】
第３に、クライアントは、コンポーネント・ファイルとして既に配信されている別の表現を有する、表現の異なる何らかのマルチコンポーネント・メディア・コンテンツを要求するときに、ファイル中の対応するメディア参照ボックスを確認して、そのファイルが再利用可能な新たな表現の任意の依存性コンポーネントを含むかどうかを調べることができる。
【００５１】
最後に、このボックスは、以下のように定義された拡張された抽出器構造の信号通信のオーバヘッドを低減するのに役立つ。
【００５２】
抽出器
抽出器は、さらに、外部メディア・ファイルのトラックのデータを参照する機能を拡張することが提案されている。
【００５３】
拡張シンタックス：
class aligned(8) Extractor ( ) {
NALUnitHeader ( );
unsigned int(16) media_reference_index;
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_offset;
unsigned int ((lengthSizeMinusOne + 1) *  8)
data_length;
}
【００５４】
セマンティクス：
ｍｅｄｉａ＿ｒｅｆｅｒｅｎｃｅ＿ｉｎｄｅｘ：抽出器を含むトラックと同じ関連するｔｒａｃｋ＿ＩＤの値を有するメディア参照ボックスに含まれる参照テーブルのエントリの指標を指定する。ｍｅｄｉａ＿ｒｅｆｅｒｅｎｃｅ＿ｉｎｄｅｘが０に等しい場合には、抽出器は、別のトラックのデータではあるが、抽出器と同じファイル内のデータを参照する。この場合には、このトラックと同じｔｒａｃｋ＿ＩＤの値を有するメディア参照ボックス内の参照テーブルは存在しないものとする。ｍｅｄｉａ＿ｒｅｆｅｒｅｎｃｅ＿ｉｎｄｅｘが、１から、メディア参照ボックスのトラックと関連付けられた参照テーブルのｄｅｐｅｎｄｅｎｔ＿ｓｏｕｒｃｅ＿ｃｏｕｎｔの値までの間である場合には、参照テーブルのｍｅｄｉａ＿ｒｅｆｅｒｅｎｃｅ＿ｉｎｄｅｘによって参照されるＵＲＬが外部ファイルを指し、この外部ファイルが、抽出器がデータを抽出するトラックを含む。
【００５５】
他のフィールドのセマンティクスは、元の抽出器の定義と同じままである。
【００５６】
このさらに拡張された抽出器構造では、抽出器を使用して、外部コンポーネント・ファイルに属するトラックのデータにリンクしてこれを抽出することができる。これは、ＳＶＣやＭＶＣで符号化されたものなど、１つの符号化されたマルチコンポーネント・メディア・コンテンツからのコンテンツ・コンポーネントを異なるコンポーネント・ファイルにカプセル化するときに、特に有用である。この拡張された抽出器では、ファイルの境界をまたいで抽出を行うことができる。これにより、異なるコンポーネント・ファイル中の同じデータを複製しなくても済む。
【００５７】
図９は、開示したＨＴＴＰストリーミング情報ボックスおよびメディア参照ボックスならびに上記のさらに拡張された抽出器データ構造を用いた、ＳＶＣ／ＭＶＣタイプのビデオ・ビットストリームから複数の動画フラグメントまたはコンポーネント・ファイルへの関連するカプセル化動作を示す。このプロセスは、上述のボックスおよび抽出器のさらなる拡張によるいくつかの修正点を除けば、図６に示すプロセスと同様である。ステップ６６０で位置情報ＵＲＬ／ＵＲＮが識別された後で、ステップ９６５で、この位置情報を使用して、ｍｒｅｆボックス（メディア参照ボックス）中の参照テーブルに記入を行う。ステップ９７０で、さらに、参照テーブルの位置情報の指標を抽出器に記入する。次いで、抽出器を現在のトラックに埋め込む。ステップ６２０でビットストリームの末尾に到達している場合には、ｍｒｅｆボックスおよびそのコンテナｈｓｉｎボックス（ＨＴＴＰストリーミング情報ボックス）を、コンポーネント・ファイルのメタデータに埋め込む。
【００５８】
コンポーネント・ファイルを読み取るために、図７に示すファイル読取り装置７００を利用する。パーサ７１０が、最初に、コンポーネント・ファイルを構文解析して、メタデータおよびメディア・データを取得し、入手可能であれば参照を取得する。復号した参照から、メディア・データが復号依存性などによって他のコンポーネント・ファイルのメディア・データに関係していることが分かった場合には、リトリーバ（ｒｅｔｒｉｅｖｅｒ）７２０が、この関連するメディア・データを、参照に示されている他のコンポーネント・ファイルから取り出す。さらに、プロセッサ７３０は、コンポーネント・ファイルから取得したメタデータおよびメディア・データを処理し、入手可能であれば追加メディア・データも処理する。パーサ７１０による構文解析動作は、プロセッサ７３０のために用意されたメタデータおよびメディア・データ、ならびにリトリーバ７２０のために用意された参照を取得するために必要な様々な動作を含む。この構文解析動作は、必要に応じて、メタデータおよび／またはメディア・データをさらに構文解析することを含む。一実施例では、参照は、メディア・データに埋め込まれるので、メディア・データを構文解析することによって取得される。参照が入手可能である場合には、構文解析ステップは、参照のシンタックスを分析すること、および参照を復号することをさらに含む。プロセッサ７３０は、コンポーネント・ファイルがビデオ・コンテンツを含む場合には、ビデオ・デコーダを含むことができる。別の実施例では、パーサおよびリトリーバをプロセッサに組み込むこともできる。
【００５９】
図８は、本発明を含むビデオ・デコーダのＳＶＣ／ＭＶＣタイプ・ビデオ・ビットストリームを読み取るプロセスを示す。ステップ８０１で、コンポーネント・ビデオ・ファイルにアクセスし、ステップ８０５で、当該コンポーネント・ビデオ・ファイルの各レイヤのメタデータおよびメディア・データを識別する。ステップ８１０で、識別したメタデータおよびメディア・データを構文解析し、ステップ８１５で、メディア・データの各ＮＡＬユニットを１つ１つ読み込む。現在のＮＡＬユニットについて、ステップ８２０で最初に判断を行い、ビットストリームの末尾に到達しているかどうかを判定し、その結果が「はい」である場合には、プロセスは、ステップ８２５で終了する。そうでない場合には、プロセスは、判断ステップ８３０に進み、現在のＮＡＬユニットが抽出器であるかどうかを判定する。現在のＮＡＬユニットが抽出器ではない場合には、それは現在のＮＡＬユニットが復号用データを含む通常のＮＡＬユニットであることを意味するので、ステップ８３５で、このＮＡＬユニットをデコーダに送信する。現在のＮＡＬユニットが抽出器である場合には、ステップ８４０で、現在のＮＡＬユニットが同じコンポーネント・ファイル外のＮＡＬユニットに依存するかどうかを判定する。必要とされるＮＡＬユニットが同じコンポーネント・ファイル内にある場合には、ステップ８４５で、そのＮＡＬユニットを現在のファイルから取り出し、ステップ８３５で、デコーダに送信する。必要とされるＮＡＬユニットが別のコンポーネント・ファイルのものである場合には、ステップ８５０で、抽出器中の参照情報Ｄａｔａ＿ｅｎｔｒｙを用いてそのＮＡＬユニットを突き止め、ステップ８５５で遠隔ファイルから取り出し、その後、ステップ８３５でデコーダに送信する。
【００６０】
別の実施例では、パーサ７１０がメディア・データを構文解析することによって参照を識別して、埋め込まれた参照指標を得、これらの参照指標に従って対応する参照を取得する。ビデオ・デコーダのＳＶＣ／ＭＶＣタイプ・ビデオ・ビットストリームを読み取る対応するプロセスを、図１０に示す。これは、図８のプロセスと同様である。好ましい実施例ではコンポーネント・ファイルの冒頭に参照が配置されるので、ステップ８１０のメタデータの構文解析により、その中に含まれる参照の分析をメディア・データの構文解析と並行して行うことが可能になる。参照を分析するときには、ステップ１０１４で、参照されたその他のコンポーネント・ファイルを識別する。これらのその他のコンポーネント・ファイルの取出しは、ステップ１０１２で、このプロセスの残りのステップと並行して開始される。ステップ８５０で、現在のＮＡＬユニットが依存するコンポーネント・ファイルの位置情報にアクセスした後で、このコンポーネント・ファイルを入手することができるかどうか、メディア・バッファなどのローカル記憶装置を確認する。必要なコンポーネント・ファイルがローカルで入手できる場合には、そのローカル・コピーのＮＡＬユニットを取り出し、そうでない場合には、遠隔ファイルのＮＡＬユニットを取り出す。なお、このコンポーネント・ファイルのローカル・コピーは、ステップ１０１２で並行取出しによって取得してもよいし、このコンポーネント・ファイルの以前の要求から取得してもよいことに留意されたい。
【００６１】
本明細書では、本発明の好ましい実施例について詳細に説明したが、本発明はこれらの実施例に限定されるわけではないこと、および当業者なら、添付の特許請求の範囲に定義する本発明の範囲を逸脱することなく、その他の修正形態および変形形態を実施することができることを理解されたい。
【図１】
2013532441.tif 000003
【図２】
2013532441.tif 000004
【図３】
2013532441.tif 000005
【図４】
2013532441.tif 000006
【図５】
2013532441.tif 000007
【図６】
2013532441.tif 000008
【図７】
2013532441.tif 000009
【図８】
2013532441.tif 000010
【図９】
2013532441.tif 000011
【図１０】
2013532441.tif 000012
【国際調査報告】
2013532441.tif 000013
2013532441.tif 000014