JP2006505024A - データ処理方法及び装置 - Google Patents

Abstract

マルチメディアデータに関係する１つ以上の記述が特定され（図１）、マルチメディアデータに関連付けられる補足的拡張情報（ＳＥＩ）に含められる（図２４）。記述を含むＳＥＩは、後に、復号システムに送信され、マルチメディアデータの復号処理において、任意に使用される（図２）。

Description

関連出願

この出願は、２００２年４月２９日に出願された米国特許仮出願番号６０／３７６，６５１号及び２００２年４月２９日に出願された米国特許仮出願番号６０／３７６，６５２号に関連し、これらに対する優先権を主張する。これらの文献は、引用により本願に援用される。更に、この出願は、２００３年２月２１日に出願された米国特許出願番号１０／３７１．４６４号に関連する。

本発明は、マルチメディアファイル形式のオーディオビジュアルコンテンツのストレージ及び検索に関し、詳しくは、ＩＳＯメディアファイル形式と互換性があるファイルフォーマットに関する。

著作権表示／許諾

この明細書の開示内容の一部は、著作権保護の対象となるマテリアルを含む。著作権所有者は、この明細書が特許商標庁への特許出願であると認められる複製に対しては異議を唱えないが、この他のあらゆる全ての著作権を主張する。以下の表示は、後述するソフトウェア及びデータ、並びに添付の図面に適用される。：著作権（ｃ）２００３：全ての著作権はソニーエレクトロニクスインク社に帰属する（Copyright (c) 2003, Sony Electronics, Inc., All Rights Reserved）。

ネットワーク、マルチメディア、データベース及び他のデジタル容量に対する要求が急速に高まり、多くのマルチメディア符号化及びストレージ法が開発されている。オーディオビジュアルのデータを符号化して、保存するためのよく知られているファイル形式の１つとして、アップルコンピーター社によって開発されたクイックタイムファイルフォーマットがある。クイックタイムファイルフォーマットは、国際標準化機構（International Organization for Standardization：以下、ＩＳＯという。）マルチメディアファイル形式ＩＳＯ／ＩＥＣ１４４９６−１２オーディオビジュアルオブジェクトの情報技術符号化−パート１２（Multimedia file format, ISO/IEC 14496-12, Information Technology-Coding of audio-visual objects-Part 12）の基礎技術として用いられた。ＩＳＯメディアファイルフォーマット（ＩＳＯファイルフォーマットとも呼ばれる。）は、次のような２つの標準ファイルフォーマットのためのテンプレートとして用いられる。（１）モーションピクチャエキスパートグループ（ＭＰＥＧ）によって開発されたＭＰ４と呼ばれる（ＩＳＯ／ＩＥＣ１４４９６−１４、情報技術、オーディオビジュアルオブジェクトの符号化、パート１４（ISO/IEC 14496-14, Information Technology--Coding of audio-visual objects--Part 14）：ＭＰ４ファイルフォーマット）ＭＰＥＧ−４ファイルフォーマット。（２）ジョイントフォトグラフィックエキスパートグループ（ＪＰＥＧ）によって開発されたＪＰＥＧ２０００（ＩＳＯ／ＩＥＣ１５４４４−１）のためのファイルフォーマット。

ＩＳＯメディアファイルフォーマットはボックス（アトム又はオブジェクトとも呼ばれる。）と呼ばれるオブジェクト指向構造によって構成される。２つの重要なトップレベルのボックスは、メディアデータ又はメタデータを含んでいる。ほとんどのボックスは、実際のメディアデータに関する、叙述的情報、構造的情報及び時間的情報を提供するメタデータの階層を記述する。このボックスのコレクションは、ムービーボックスとして知られているボックスに含まれている。メディアデータ自体は、メディアデータボックス内に含まれていてもよく、外部に存在してもよい。特定のメディアデータに関して情報を提供するメタデータボックスの集団的な階層は、トラックと呼ばれる。

主のメタデータは、ムービーオブジェクトである。ムービーボックスは、時間的に表現されたメディアデータを記述するトラックボックスを含んでいる。トラックのためのメディアデータには、様々な種類（例えば、ビデオデータ、オーディオデータ、バイナリ形式スクリーン表示（format screen representations：ＢＩＦＳ）等）がある。各トラックは更にサンプル（アクセスユニット又はピクチャとも呼ばれる。）に分割される。サンプルは、特定の時刻におけるメディアデータのユニットを表している。サンプルメタデータは、一組のサンプルボックスに含まれている。各トラックボックスは、各サンプルのための時間、バイトで表現される等を提供するボックスを含むサンプルテーブルボックスメタデータボックスを含んでいる。サンプルは、タイミング、位置及び他のメタデータ情報を表すことができる最も小さいデータ構成要素である。サンプルは、連続したサンプルの組を含むチャンクにグループ化できる。各チャンクは、それぞれ異なるサイズを有していてもよく、異なるサイズのサンプルを含んでいてもよい。

近年、ＭＰＥＧの国際電気通信連合（ＩＴＵ）のビデオグループと画像符号化エキスパートグループ（ＶＣＥＧ）とは、ジョイントビデオチームとして（ＪＶＴ）、ＩＴＵ勧告Ｈ．２６４又はＭＰＥＧ４パート１０、高度動画像符号化／復号標準（Advanced Video Codec：以下、ＡＶＣという。）又はＪＶＴコーデックと呼ばれる新しい画像符号化／復号（コーデック）標準を開発するために共同標準化作業を始めた。これらの用語及びＨ．２６４や、ＪＶＴや、ＡＶＣ等の略語は、ここでは交換可能に用いる。

ＪＶＴコーデック設計では、画像符号化レイヤ（ＶＣＬ）とネットワーク抽象化レイヤ（ＮＡＬ）の２つの異なる概念的なレイヤを区別する。ＶＣＬは、動き補償や、係数の変換符号化や、エントロピ符号化等の符号化に関連するコーデックの部分を含んでいる。ＶＣＬの出力はスライスであり、各スライスは、一連のマクロブロックと、関連するヘッダ情報とを含んでいる。ＮＡＬは、ＶＣＬデータを伝送するために用いられたトランスポートレイヤの詳細からＶＣＬを抜き取る。ＶＣＬは、スライスより高いレベルの情報について、包括的な、伝送から独立した表現を定義する。ＮＡＬは、ビデオコーデック自体と、外部世界とのインタフェースを定義する。内部的には、ＮＡＬは、ＮＡＬパケットを用いる。ＮＡＬパケットは、ペイロードのタイプを示すタイプフィールドと、ペイロード内のビットセットとを含んでいる。単一のスライス内のデータは、更に異なるデータ部分に分割できる。

多くの既存のビデオ符号化形式では、符号化されたストリームデータは、復号処理を制御するパラメータを含む様々な種類のヘッダを含んでいる。例えば、ＭＰＥＧ−２ビデオ規格は、シーケンスヘッダ、拡張されたグループオブピクチャ（group of pictures：以下、ＧＯＰという。）及びピクチャヘッダを、それらのアイテムに対応するビデオデータの前に設けている。ＪＶＴでは、ＶＣＬデータを復号するために必要な情報は、パラメータセットにグループ化される。各パラメータセットには、後にスライスからの参照情報として用いられる識別子が与えられている。パラメータセットは、ストリーム内（帯域内）で送信する代わりに、ストリーム外（帯域外）で送信してもよい。

既存のファイルフォーマットは、符号化されたメディアデータに関連しているパラメータセットを保存する機能を有しておらず、また、パラメータセットを効率的に検索して、伝送できるように、効率的にメディアデータ（すなわち、サンプル又はサブサンプル）をパラメータセットにリンクするための機能も有していない。

ＩＳＯメディアファイルフォーマットにおいては、構文解析メディアデータを用いることなくアクセスできる最小単位は、サンプル、すなわちＡＶＣ全体である。多くの符号化フォーマットでは、サンプルは、更にサブサンプル（サンプルフラグメント又はアクセスユニットフラグメントとも呼ばれる。）と呼ばれるより小さい単位に分割できる。ＡＶＣでは、サブサンプルは、スライスに対応している。しかしながら、既存のファイルフォーマットは、サンプルのサブパーツへのアクセスをサポートしていない。ファイルに保存されたデータに基づき、ストリーミングのためのパケットを柔軟に生成する必要があるシステムでは、サブサンプルにアクセスできないと、ストリーミングのためのＪＶＴメディアデータを柔軟にパケット化することができない。

既存のストレージフォーマットでは、メディアデータをストリーミングする際のネットワーク状態の変化に応じて、異なる帯域幅で保存されたストリーム間を切り換えることに関する制約がある。典型的なストリーミングのシナリオにおける主要な要求の１つは、ネットワーク状態の変化に応じて圧縮データのビット伝送速度をスケーリングすることである。これは、通常、異なる帯域幅及び代表的なネットワーク状態のための品質設定を有する複数のストリームを符号化し、１つ以上のファイルにこれらを保存することによって実現される。サーバは、ネットワーク状態に応じて、予め符号化されたこれらのストリームを切り換えることができる。既存のファイルフォーマットでは、ストリームの切換は、先行するサンプルに依存することなくサンプルを再構築できる場合にのみ可能である。このようなサンプルは、Ｉフレームと呼ばれる。現在、先のサンプルに依存して再構築されるサンプル（すなわち、複数のサンプルを参照して再構築されるＰフレーム又はＢフレーム）の場合、ストリームの切換はサポートされていない。

ＡＶＣ規格は、ストリーム間の効率的な切換、ランダムアクセスと、エラー回復、及びこの他の特徴を提供する切換ピクチャ（switching picture）と呼ばれるツールを提供する（ＳＩピクチャ及びＳＰピクチャと呼ばれる）。切換ピクチャは、再構築される値が切り換えようとしているピクチャと正確に等しい特別な種類のピクチャである。切換ピクチャは、対応するピクチャを予測するために用いられた参照ピクチャとは異なる参照ピクチャを用いることができ、この結果、Ｉ−フレームを用いるより効率的に符号化を行うことができる。ファイルに保存された切換ピクチャを効率的に利用するためには、どのセットのピクチャが同等であるか及びどのピクチャが予測に用いられるかを知る必要がある。既存のファイルフォーマットでは、この情報は提供されず、したがって、この情報は、符号化されたを解析することによって、抽出する必要がある（このような処理は非効率的で時間がかかる）。

したがって、新しいビデオコード化規格によって提供される新しい能力に対応し、既存のストレージ方法における制約をなくすようにストレージ方法を改善することが望まれる。

マルチメディアデータに関係する１つ以上の記述が特定され、マルチメディアデータに関連付けられる補足的拡張情報（supplemental enhancement information：ＳＥＩ）に含められる。記述を含むＳＥＩは、後に、復号システムに送信され、マルチメディアデータの復号処理において、任意に使用される。

以下、添付の図面を用いて、本発明の実施例を詳細に説明する。添付の図面においては、類似する要素には、類似する参照符号を付す。添付の図面は、本発明を実現する特定の実施例を例示的に示している。これらの実施例については、当業者が本発明を実施することができるよう、詳細に説明するが、この他の実施例も可能であり、本発明の範囲から逸脱することなく、論理的、機械的、電気的、機能的及びこの他の変更を行うことができる。したがって、以下の詳細な説明は、限定的には解釈されず、本発明の範囲は、添付の請求の範囲によってのみ定義される。

概観
まず、本発明の動作の概観を説明するために、図１に符号化システム１００の一実施例を示す。符号化システム１００は、メディアエンコーダ１０４、メタデータ生成器１０６及びファイル作成器（file creator）１０８を備える。メディアエンコーダ１０４は、例えば、ビデオデータ（例えば、自然映像（natural source video scene）と他の外部の映像オブジェクトから作成されたビデオオブジェクト）、音声データ（例えば、自然音声（natural source audio scene）及び他の外部のオーディオオブジェクトから作成された音声オブジェクト）、合成オブジェクト、又はこれらの任意の組合せ組合せを含むメディアデータを受け取る。メディアエンコーダ１０４は、様々な種類のメディアデータを処理するために、複数の別個のエンコーダを備えていてもよく、サブエンコーダを備えていてもよい。メディアエンコーダ１０４は、メディアがデータを符号化して、メタデータ生成器１０６に渡す。メタデータ生成器１０６は、メディアファイルフォーマットに基づいて、メディアデータに関する情報を提供するメタデータを生成する。メディアファイルフォーマットは、ＩＳＯメディアファイルフォーマット（又は、これに由来するＭＰＥＧ−４、ＪＰＥＧ２０００等）、クイックタイム、又は他の任意のメディアファイルフォーマットに基づいていてもよく、幾つかの追加的データ構造を含んでいてもよい。一実施例では、メディアデータ内においてサブサンプルに関係するメタデータを保存するための追加的データ構造を定義する。他の実施例においては、従来ではメディアデータに保存されていた復号情報を含んでいる対応するパラメータセットにメディアデータの部分（例えば、サンプル又はサブサンプル）をリンクするメタデータを保存するための追加的データ構造を定義する。更に他の実施例ではメディアデータ内のサンプルの相互依存性に基づいて作成された、メタデータデータ内のサンプルの様々なグループに関係するメタデータを保存するための追加的データ構造を定義する。更に他の実施例では、メディアデータに関連している切換サンプルセット（switch sample set）に関係するメタデータを保存するための追加的データ構造を定義する。切換サンプルセットとは、同じ復号値を有するが、異なるサンプルに依存していてもよいサンプルの組を指す。更に他の実施例では、使用されているファイルフォーマットにおいて、追加的データ構造の様々な組合せを定義する。これらの追加的データ構造とその機能については、後に詳細に説明する。

ファイル作成器１０８は、符号化されたメディアデータとメタデータを保存する。一実施例では、符号化されたメディアデータと関係するメタデータ（例えば、サブサンプルメタデータ、パラメータセットメタデータ、グループサンプルメタデータ又は、切換サンプルメタデータ）は、同じファイルに保存される。このファイルの構造は、メディアファイルフォーマットによって定義されている。

他の実施例においては全ての種類又は幾つか種類のメタデータは、メディアデータとは別個に保存される。例えば、パラメータセットメタデータをメディアデータとは別個に保存してもよい。具体的には、ファイル作成器１０８は、符号化されたメディアデータのファイルを作成するメディアデータファイル作成器１１４と、メタデータのファイルを作成するメタデータファイル作成器１１２と、対応するメタデータとメディアデータを同期させるシンクロナイザ１１６とを備えていてもよい。メタデータを別個に保存する手法及びこれらのメタデータとメディアデータとの同期については、後により詳細に説明する。

一実施例において、メタデータファイル作成器１１２は、メディアデータから独立して保存されたメタデータとして、メディアデータに関連付けられた補足的拡張情報（supplemental enhancement information：以下、ＳＥＩという。）メッセージを保存する。ＳＥＩデータがなくても、復号処理を行うことができるので、デコーダは、ＳＥＩデータを使用する必要はない。一実施例では、ＳＥＩメッセージは、メディアデータの記述を含ませるために使用される。この記述は、ＭＰＥＧ−７規格に従って定義され、記述子と記述スキームから構成される。記述子は、オーディオビジュアルのコンテンツの特徴を表し、各特徴の表現の構文ととセマンティクスを定義する。記述子の具体例としては、カラー記述子、テクスチャ記述子、動き記述子等がある。記述スキーム（Description scheme：ＤＳ）は、それらのコンポーネントの間の関係の構造とセマンティクスを特定する。これらのコンポーネントとは、記述子と記述スキームのいずれであってもよい。この記述を用いることにより、メディアデータが復号された後のメディアデータの検索性と視覚的性能が向上する。ＳＥＩメッセージのオプションの性質のため、デコーダがＳＩＥメッセージを使用するための特定の能力と特定の構成を備えていない場合、そのデコーダは、ＳＥＩメッセージの使用を強制されるわけではないので、ＳＥＩメッセージに記述を含めても、復号処理に悪い影響はない。ＳＥＩメッセージのメタデータとしての保存については、後により詳細に説明する。ファイル作成器１０８によって作成されたファイルは、チャンネル１１０を介して保存し又は伝送することができる。

図２は、復号システム２００の一実施例を示している。復号システム２００は、メタデータ抽出器２０４、メディアデータストリームプロセッサ２０６、メディアデコーダ２１０、合成器（compositor）２１２及びレンダリング器（renderer）２１４を備える。復号システム２００をクライアント機器内に設け、ローカルな再生に用いてもよい。これに代えて、復号システム２００は、データのストリーミングに用いてもよく、ネットワーク（例えば、インターネット）２０８を介して互いに通信を行うサーバ機器及びクライアント機器を備えていてもよい。サーバ機器は、メタデータ抽出器２０４とメディアデータストリームプロセッサ２０６を備えていてもよい。クライアント機器は、メディアデコーダ２１０、合成器２１２及びレンダリング器２１４を備えていてもよい。

メタデータ抽出器２０４は、データベース２１６に保存されている又は（例えば符号化システム１００から）ネットワークを介して受信したファイルからメタデータを抽出する機能を担う。このファイルは、抽出されるメタデータに関連しているメディアデータを含んでいてもよく、含んでいなくてもよい。ファイルから抽出されたメタデータは、上述した追加的データ構造の１つ以上を含んでいる。

抽出されたメタデータは、メディアデータストリームプロセッサ２０６に渡される。このメディアデータストリームプロセッサ２０６は、関連する符号化されたメディアデータも受け取る。メディアデータストリームプロセッサ２０６は、メタデータを用いて、メディアデータストリームを生成し、これをメディアデコーダ２１０に供給する。一実施例では、メディアデータストリームプロセッサ２０６は、（例えば、パケット化のために）サブサンプルに関係するメタデータを用いて、メディアデータ内のサブサンプルの位置を特定する。他の実施例においては、メディアデータストリームプロセッサ２０６は、パラメータセットに関係するメタデータを用いて、メディアデータの一部を対応するパラメータセットにリンクさせる。更に他の実施例では、メディアデータストリームプロセッサ２０６は、メタデータを用いて、所定のグループ内のサンプルにアクセスするために、メタデータ内のサンプルの様々なグループを定義する（例えば、スケーラビリティのために、伝送条件に応じて、他のサンプルが依存していないサンプルのグループを除外して伝送ビットレートを低減する）。更に他の実施例では、メディアデータストリームプロセッサ２０６は、切換サンプルセットを定義するメタデータを用いて、切り換えるべきサンプルであって、導出されるサンプルが依存するサンプルに依存しないサンプルと同じ復号値を有する切換サンプルを特定する（例えば、Ｐフレーム又はＢフレームにおいて、異なるビットレートを有するストリームへの切換を可能にする）。

作成されたメディアデータストリームは、直接（例えば、ローカル再生のために）又はネットワーク２０８を介して（例えばデータのストリーミングのために）、メディアデコーダ２１０に供給され、復号される。合成器２１２は、メディアデコーダ２１０の出力を受け取ってシーンを合成（compose）し、合成されたシーンは、ユーザディスプレイ装置内のレンダリング器２１４によってレンダリングされる。

以下に示す図３を参照した説明は、本発明の実施に適したコンピュータハードウェア及び他の操作コンポーネントに関する概要を明らかにするためのものであるが、これは、適用可能な環境を制限するものではない。図３は、図１に示すメタデータ生成器１０６及び／又はファイル作成器１０８、又は図２に示すメタデータ抽出器２０４及び／又はメディアデータストリームプロセッサ２０６の実現に好適なコンピュータシステムを示している。

コンピュータシステム３４０は、それぞれがシステムバス３６５に接続されたプロセッサ３５０と、メモリ３５５と、入出力装置（input/output capability）３６０とを備える。メモリ３５５は、プロセッサ３５０によって実行されることにより、ここに説明する処理を実現する命令を格納するよう構成されている。入出力装置３６０は、プロセッサ３５０によってアクセス可能なあらゆる種類のストレージ装置を含む、様々な種類の、コンピュータにより読取可能な媒体を含んでいる。なお、「コンピュータにより読取可能な媒体」という用語は、デジタル信号がエンコードされた搬送波をも含むことは、当業者にとって明らかである。コンピュータシステム３４０は、メモリ３５５において実行されるオペレーティングシステムソフトウェアによって制御される。入出力装置３６０及びこれに関連する媒体は、このオペレーティングシステムソフトウェアと、本発明に基づく処理とに関する命令と、アクセスユニットとを格納している。図１及び図２に示すメタデータ生成器１０６、ファイル作成器１０８、メタデータ抽出器２０４及びメディアデータストリームプロセッサ２０６は、プロセッサ３５０に接続されたそれぞれ独立した要素であってもよく、プロセッサ３５０によって実行される、コンピュータにより実行可能な命令として実現してもよい。一実施例においては、コンピュータシステム３４０は、インターネットサービスプロバイダ（Internet Service Provider：以下、ＩＳＰという。）の一部であってもよく、或いは、入出力装置３６０を介してＩＳＰに接続され、インターネットを介してアクセスユニットを送受信してもよい。なお、本発明は、インターネットアクセス及びインターネットウェブサイトに限定されるものではなく、直接接続されたコンピュータシステム及びプライベートネットワークに適用してもよいことは明らかである。

なお、コンピュータシステム３４０は、異なるアーキテクチャを有する様々な可能なコンピュータシステムの一例に過ぎないことは明らかである。一般的なコンピュータシステムは、少なくともプロセッサと、メモリと、及びプロセッサとメモリを接続するバスとを備えている場合が多い。なお、本発明は、マルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ等を含む、他のコンピュータシステム構成によっても実現できることは当業者にとって明らかである。更に、本発明は、通信ネットワークを介してリンクされたリモートの処理装置によってタスクが実行される分散型コンピュータシステム環境によっても実現することができる。

サブサンプルのアクセス可能性（Sub-Sample Accessibility）
図４及び図５は、それぞれ符号化システム１００及び復号システム２００において実行されるサブサンプルメタデータの保存及び検索のための処理の具体例を示している。この処理は、ハードウェア（例えば回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステム又は専用マシン上で実行されるソフトウェア）又はこれらの両方の組合せを含む処理ロジックによって実行してもよい。ソフトウェアによって実現できる処理については、これらのフローチャートを用いて本発明を説明することにより、当業者は、適切に構成されたコンピュータによってこの処理を実行するための命令を含むプログラムを開発することができる（コンピュータのプロセッサは、メモリを含むコンピュータにより読取可能な媒体から命令を読み出し、実行する）。コンピュータにより実行可能な命令は、コンピュータプログラミング言語として書いてもよく、ファームウェアロジックとして実現してもよい。一般的に認知されている規格に準拠するプログラミング言語で書いた場合、このような命令は、様々なオペレーティングシステムにインタフェースされ、様々な種類のハードウェアプラットホームで実行できる。更に、本発明では、如何なる特定のプログラミング言語にも基づくことなく、本発明を説明する。ここに開示する本発明の処理を実現するために、様々なプログラミング言語を用いてることができることは明らかである。更に、当分野においては、動作を行い又は結果を生じるものとして、ソフトウェアを様々な呼び方で呼ぶことがある（例えば、プログラム、手続き、プロセス、アプリケーション、モジュール、ロジック等）。これらの表現は、コンピュータによるソフトウェアの実行によって、コンピュータのプロセッサが動作を実行し又は結果を生じるということを単に簡略的に表現しているに過ぎない。また、本発明の範囲から逸脱することなく、図４及び図５に示す処理ステップを省略してもよく、他のステップを追加してもよく、更に、ここで説明する処理ステップの実行順序を変更してもよい。

図４は、符号化システム１００において、サブサンプルメタデータを作成する処理４００の一実施例を示すフローチャートである。まず、処理４００は、処理ロジックが符号化されたメディアデータを含むファイルを受け取る（処理ブロック４０２）ことによって開始される。次に、処理ロジックは、メディアデータ内のサブサンプルの境界を特定する情報を抽出する（処理ブロック４０４）。用いられているファイルフォーマットに応じて、時間的属性を与えることができるデータストリームの最小単位は、サンプル（ＩＳＯメディアファイルフォーマット又はクイックタイムにおいて定義されている）、アクセスユニット（ＭＰＥＧ−４において定義されている）又はピクチャ（ＪＶＴにおいて定義されている）等と呼ばれる。サブサンプルは、サンプルのレベルより下位のデータストリームの連続する部分を表す。サブサンプルの定義は、符号化フォーマットに依存するが、包括的に言えば、サブサンプルとは、単一のエンティティ又はサブユニットの組合せとして復号でき、サンプルの部分的な再構築を可能にする、サンプルの重要なサブユニットである。また、サブサンプルは、アクセスユニットフラグメントとも呼ばれる。サブサンプルは、多くの場合、サンプルのデータストリームの部分（division）を表すので、各サブサンプルは、同じサンプル内の他のサブサンプルに対して依存関係をほとんど又は全く有していない。例えば、ＪＶＴでは、サブサンプルは、ＮＡＬパケットである。同様に、ＭＰＥＧ−４ビデオでは、サブサンプルは、ビデオパケットである。

一実施例では、符号化システム１００は、上述のように、ＪＶＴにおいて定義されているネットワーク抽象化レイヤで動作する。ＪＶＴメディアデータストリームは、一連のＮＡＬパケットから構成され、各ＮＡＬパケット（また、ＮＡＬユニットと呼ばれる）は、ヘッダ部とペイロード部分を含んでいる。ある種のＮＡＬパケットは、各スライスについて符号化されたＶＣＬデータ又は１つのスライスの単一のデータ分割を格納するために用いられる。更に、ＮＡＬパケットは、ＳＥＩメッセージを含む情報パケットであってもよい。ＪＶＴでは、サブサンプルは、ヘッダとペイロードの両方を有する完全なＮＡＬパケットであってもよい。

処理ブロック４０６において、処理ロジックは、メディアデータ内のサブサンプルを定義するサブサンプルメタデータを作成する。一実施例では、サブサンプルメタデータは、予め定義されたデータ構造の組（例えば、一組のボックス）として組織化される。予め定義されたデータ構造の組には、各サブサンプルのサイズに関する情報を含むデータ構造、各サンプルのサブサンプルの総数に関する情報を含むデータ構造、各サブサンプルを説明する情報（例えば、何がサブサンプルとして定義されているか）を含むデータ構造、各チャンク内のサブサンプルの総数に関する情報を含むデータ構造、各サブサンプルの優先順位に関する情報を含むデータ構造、又はサブサンプルに関係する任意のデータを含む他のデータ構造を含めることができる。

次に、一実施例において、処理ロジックは、データの繰り返しシーケンス（repeated sequence of data）を含むデータ構造が存在するか否かを判定する（デシジョンボックス４０８）。この判定の結果が肯定的である場合、処理ロジックは、データの各繰り返しシーケンスをシーケンス出現への参照情報（a reference to a sequence occurrence）及び繰り返しシーケンスの出現回数を表す情報に変換する（処理ブロック４１０）。

次に、処理ブロック４１２において、処理ロジックは、特定のメディアファイルフォーマット（例えば、ＪＶＴファイルフォーマット）を用いて、メディアデータに関連するファイルの中にサブサンプルメタデータを含める。メディアファイルフォーマットにより、サブサンプルメタデータは、サンプルメタデータとともに保存してもよく（例えば、サンプルデータ構造を含むサンプルテーブルボックスにサブサンプルデータ構造を含むことができる）、サンプルメタデータとは別に保存してもよい。

図５は、復号システム２００においてサブサンプルメタデータを利用するための処理５００の一具体例のフローチャートである。まず、処理５００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック５０２）。ファイルは、データベース（ローカル又は外部の）、符号化システム１００又はネットワーク上の他の如何なる機器から供給してもよい。ファイルは、メディアデータ内のサブサンプルを定義するサブサンプルメタデータを含んでいる。

次に、処理ロジックは、ファイルからサブサンプルメタデータを抽出する（処理ブロック５０４）。上述のように、サブサンプルメタデータは、データ構造の組（例えば、一組のボックス）に保存してもよい。

更に、処理ブロック５０６において、処理ロジックは、抽出されたメタデータを用いて、（同じファイル又は異なるファイルに保存されている）符号化されたメディアデータのサブサンプルを特定し、メディアデコーダに供給するために、複数のサブサンプルを結合してパケットを生成し、これにより、ストリーミングのためのメディアデータの柔軟なパケット化が可能となる（例えば、エラー回復、スケーラビリティ等をサポートできる）。

以下、拡張ＩＳＯメディアファイルフォーマット（拡張ＭＰ４と呼ばれる）に基づいて、サブサンプルメタデータ構造の具体例について説明する。なお、他のメディアファイルフォーマットを拡張して、サブサンプルメタデータを保存するための同様のデータ構造を組み込むことができることは当業者にとって明らかである。

サブサンプルを含む拡張ＭＰ４メディアストリームモデルを図６に示す。プレゼンテーションデータ（例えば、同期されたオーディオ及びビデオを含むプレゼンテーション）は、ムービー６０２として表されている。ムービー６０２は、一組のトラック６０４を含む。各トラック６０４は、メディアデータストリームを表している。各トラック６０４は、サンプル６０６に分割される。各サンプル６０６は、特定の時刻におけるメディアデータのユニットを表している。サンプル６０６は、更にサブサンプル６０８に分割される。ＪＶＴ規格では、サブサンプル６０８は、ＮＡＬパケット又は単一のピクチャのスライス、複数のデータ部分を含むスライスの１つのデータ部分、帯域内パラメータセット又はＳＥＩ情報パケット等のユニットを表すことができる。これに代えて、サブサンプル６０６は、例えば、メディアにおける空間的領域又は時間的領域を表すコードデータ等、サンプルにおける他の如何なる構造的要素を表していてもよい。一実施例においては、何らかの構造的基準又は意味的基準に基づく、符号化されたメディアデータの如何なる部分もサブサンプルとして扱うことができる。

トラック拡張ボックスは、トラックフラグメントにおけるサンプルを特定するためにムービーフラグメントが使用されている場合、各サンプルの所要時間とサイズに関する情報を提供し、各サンプルの劣化優先順位（degradation priority）及び他のサンプル情報を指定するために用いられる。劣化優先順位とは、サンプルの重要度を定義し、すなわち、（例えば、伝送時の損失のため）そのサンプルが失われた場合、映像の品質にどのような影響があるかを示している。一実施例においては、トラック拡張ボックスは、トラックフラグメントボックス内のサブサンプルのデフォルト情報を含むように拡張される。この情報は、例えば、サブサンプル記述のサブサンプル記述への参照情報とを含むことができる。

トラックは、複数のフラグメントに分割できる。各フラグメントは、０個以上の連続するサンプルのランを含むことができる。トラックフラグメントランボックスは、トラックフラグメント内のサンプルを特定し、トラックフラグメントに保存されたサンプルに関するトラックフラグメントのそれぞれのサンプルの所要時間とサイズに関する情報及びこの他の情報を提供する。トラックフラグメントヘッダボックスは、トラックフラグメントランボックスにおいて用いられるデフォルトデータ値を特定する。一実施例では、トラックフラグメントランボックス及びトラックフラグメントヘッダボックスは、トラックフラグメント内のサブサンプルに関する情報を含むように拡張される。トラックフラグメントランボックス内の拡張された情報としては、例えば、各サンプルのトラックフラグメントに保存されたサブサンプルの数、各サブサンプルのサイズ、サブサンプル記述への参照情報、一組のフラグ等を含めることができる。一組のフラグにより、トラックフラグメントがサンプルのチャンク又はサブサンプルにメディアデータを保存するか否か、サブサンプルデータがトラックフラグメントランボックスに存在しているか否か、各サブサンプルが、トラックフラグメントランボックス内にサイズデータ及び／又は記述参照情報データを有しているか否か等を示すことができる。トラックフラグメントヘッダボックスの拡張情報は、例えば、各サブサンプルが、サイズデータ及び／又は記述参照データを提供しているか否かを示すフラグのデフォルト値等の情報を含むことができる。

サブサンプルメタデータを保存するためのデータ構造の具体例を図７Ａ〜図７Ｌに示す。

図７Ａに示すように、ＩＳＯメディアファイルフォーマットによって定義されたサンプルメタデータボックスを含むサンプルテーブルボックス７００は、サブサンプルサイズボックス（sub-sample size box）７０２、サブサンプル記述関連付けボックス（sub-sample description association box）７０４、サブサンプル−サンプルボックス（sub-sample to sample box）７０６、サブサンプル記述ボックス（sub-sample description box）７０８等のサブサンプルアクセスボックスを含むように拡張される。一実施例では、サブサンプルアクセスボックスは、サブサンプル−チャンク（sub-sample to chunk box）ボックス及び優先度ボックス（priority box）も含んでいる。一実施例では、サブサンプルアクセスボックスを用いるか否かは任意である。

図７Ｂに示すように、サンプル７１０は、例えば、スライス７１２等のスライスと、データ部分（data partition）７１４等のデータ部分と、ＲＯＩ７１６等の重要な領域（regions of interest：ＲＯＩ）とに分割することができる。これらの各実施例は、サンプルをサブサンプルに分割する様々な例を表している。単一のサンプル内の各サブサンプルは、互いに異なるサイズを有することができる。

サブサンプルサイズボックス７１８は、サブサンプルサイズボックス７１８のバージョンを指定するバージョンフィールドと、デフォルトサブサンプルサイズを指定するサブサンプルサイズフィールドと、トラック内のサブサンプルの数を表すサブサンプルカウントフィールドと、各サブサンプルのサイズを指定するエントリサイズフィールドとを含んでいる。サブサンプルサイズフィールドに０が設定されている場合、サブサンプルサイズテーブル７２０内に格納されているサブサンプルは異なるサイズを有する。サブサンプルサイズフィールドの値が０に設定されない場合、このフィールドは、サブサンプルサイズが一定であることを表し、サブサンプルサイズテーブル７２０が空であることを示す。テーブル７２０は、サブサンプルサイズを表すための３２ビット固定長フィールド又は可変長フィールドを有していてもよい。フィールドが可変長である場合、サブサンプルテーブルは、サブサンプルサイズフィールドの長さをバイト単位で表現するフィールドを含んでいる。

図７Ｃに示すように、サブサンプル−サンプルボックス７２２は、サブサンプル−サンプルボックス７２２のバージョンを特定するバージョンフィールドと、テーブル７２３内のエントリの数を示すエントリカウントフィールドとを含んでいる。サブサンプル−サンプルテーブルにおける各エントリは、同数の１サンプルあたりのサブサンプルを共有するサンプルのラン（run）における第１のサンプルのインデクスを提供する第１のサンプルフィールドと、サンプルのランにおける各サンプルのサブサンプルの数を提供するサンプル毎サブサンプル（sub-samples-per-sample）フィールドとを含んでいる。

テーブル７２３を用いることにより、ランに幾つのサンプルがあるかを算出し、この数と適切な１サンプル毎のサブサンプルの数とを乗算し、全てのランの結果を合計することによって、トラックのサブサンプルの総数を算出することができる。

他の実施例では、サブサンプルは、サンプルではなくチャンクとしてグループ化する。そして、サブサンプル−チャンクボックス（sub-sample to chunk box）を用いて、チャンク内のサブサンプルが特定される。サブサンプル−チャンクボックスは、同じ数のサブサンプルと、各チャンク内のサブサンプルの数と、サブサンプル記述のためのインデクスとを共有するチャンクのランにおける第１のチャンクのインデクスに情報を保存する。サブサンプル−チャンクボックスを用いて、特定のサブサンプル、チャンク内のサブサンプルの位置及びこのサブサンプルの記述を含むチャンクを検出することができる。一実施例において、サブサンプルがチャンクとしてグループ化される場合、サブサンプル−サンプルボックス７２２は、存在しない。一方、サブサンプルがサンプルとしてグループ化される場合、サブサンプル−チャンクボックスは、存在しない。

上述のように、サブサンプルアクセスボックスは、各サブサンプルの劣化優先順位を指定する優先順位ボックスを含むことができる。劣化優先順位とは、サンプルの重要度を定義し、すなわち、（例えば、伝送時の損失のため）そのサンプルが失われた場合、復号されたメディアデータにどのような影響があるかを示している。優先順位ボックスのサイズは、サブサンプル−サンプルボックス７２２又はサブサンプル−チャンクボックスから判定さすることができるトラック内のサブサンプルの数によって定義される。

図７Ｄに示すように、サブサンプル記述関連付けボックス７２４は、サブサンプル記述関連付けボックス７２４のバージョンを指定するバージョンフィールドと、記述されるサブサンプルのタイプ（例えばＮＡＬパケット、関心領域）を示す記述タイプ識別子と、テーブル７２６内のエントリの数を提供するエントリカウントフィールドとを含んでいる。テーブル７２６内の各エントリは、サブサンプル記述ＩＤを示すサブサンプル記述タイプ識別子フィールドと、同じサブサンプル記述ＩＤを共有するサブサンプルのランにおける第１のサブサンプルへのインデクスを提供する第１のサブサンプルフィールドとを含んでいる。

サブサンプル記述タイプ識別子は、サブサンプル記述ＩＤフィールドの使用を制御する。すなわち記述タイプ識別子において特定されたタイプに応じて、サブサンプル記述ＩＤフィールド自体が記述ＩＤ自体の中のサブサンプル記述を直接符号化する記述ＩＤを特定し、又は、サブサンプル記述ＩＤフィールドは、異なるテーブル（すなわち、後述するサブサンプル記述テーブル）へのインデクスとして機能できる。例えば、記述タイプ識別子がＪＶＴ記述を指示する場合、サブサンプル記述ＩＤフィールドは、ＪＶＴサブサンプルの特性を指定するコードを含むことができる。この場合、サブサンプル記述ＩＤフィールドは、サブサンプル内に予め定義されたデータ部分が存在することを表すビットマスクとして用いられる下位８ビットと、ＮＡＬパケットタイプを表すための、又は将来の拡張のための上位２４ビットとを含む３２ビットのフィールドであってもよい。

図７Ｅに示すように、サブサンプル記述ボックス７２８は、サブサンプル記述ボックス７２８のバージョンを指定するバージョンフィールドと、テーブル７３０内のエントリの数を示すエントリカウントフィールドと、サブサンプルの特性に関する情報を表すサブサンプル記述フィールドの記述タイプを示す記述タイプ識別子フィールドと、１つ以上のサブサンプル記述エントリ７３０を含むテーブルとを含む。サブサンプル記述タイプは、記述情報（descriptive information）が関係するタイプを特定し、サブサンプル記述関連付けテーブル７２４内の同じフィールドに対応している。テーブル７３０内の各エントリは、関連するサブサンプルの特性に関する情報を含むサブサンプル記述エントリを含んでいる。記述エントリの情報とフォーマットは、記述タイプフィールドに依存する。例えば、そして、記述タイプがパラメータセットである場合、各記述エントリは、パラメータセットの値を含む。

記述情報は、パラメータセット情報、ＲＯＩに関係する情報又はサブサンプルを特徴付けるために必要な他のあらゆる情報に関連付けることができる。パラメータセットについては、サブサンプル記述関連付けテーブル７２４は、各サブサンプルに関連するパラメータセットを示す。このような場合、サブサンプル記述ＩＤは、パラメータセット識別子に対応している。同様に、サブサンプルは、以下のように異なる関心領域を表すことができる。まず、サブサンプルを１つ以上の符号化されたマクロブロックとして定義し、次に、サブサンプル記述関連付けテーブルを用いて、ビデオフレーム又は画像の符号化されたミクロブロックの異なる領域への分割を表現する。例えば、２つのサブサンプル記述ＩＤ（例えば、サブサンプル記述ＩＤ１、２）によって、フレーム内の符号化されたマクロブロックを、それぞれ前景領域及び背景領域への割当を示す前景マクロブロックと背景マクロブロックに分割できる。

異なる種類のサブサンプルを図７Ｆに示す。サブサンプルは、分割されていないスライス７３２、複数のデータに分割されたスライス７３４、スライス内のヘッダ７３６。１つのスライスの中央のデータ部分７３８、１つのスライスの最後のデータ部分７４０、ＳＥＩ情報パケット７４２等を表すことができる。これらの各サブサンプルタイプは、図７Ｇに示す８ビットマスク７４４の特定の値に関連付けてもよい。８ビットマスクは、上述のように、３２ビットのサブサンプル記述ＩＤフィールドの最下位８ビットを構成してもよい。図７Ｈは、「ｊｖｔｄ」に等しい記述タイプ識別子を有するサブサンプル記述関連付けボックス７２４を示す。テーブル７２６は、図７Ｇに示した値を格納する３２ビットのサブサンプル記述ＩＤフィールドを有している。

図７Ｈ〜図７Ｋを用いて、サブサンプル記述関連付けテーブルにおけるデータの圧縮を説明する。

図７Ｉに示すように、圧縮されていないテーブル７２６は、シーケンス７４８を繰り返すサブサンプル記述ＩＤのシーケンス７５０を含んでいる。圧縮されたテーブル７４６内では、繰り返しシーケンス７５０は、シーケンス７４８への参照情報と、このシーケンスが出現する回数を表す情報に圧縮されている。

図７Ｊに示す一実施例においては、サブサンプル記述ＩＤフィールドにおいて、最上位ビットをシーケンスフラグのラン７５４として用い、次の２３ビットを出現インデクス７５６として用い、これより下位のビットを出現長（occurrence length）７５８として用いることによって、シーケンス出現（sequence occurrence）を符号化することができる。シーケンスフラグのラン７５４に１が設定されている場合、これは、当該エントリが繰り返しシーケンスの出現を含んでいることを示している。シーケンスフラグのラン７５４に０が設定されている場合、このエントリは、サブサンプル記述ＩＤであることを示している。出現インデクス７５６は、シーケンスの第１の出現のサブサンプル記述関連付けボックス７２４内の指標であり、出現長７５８は、繰り返しシーケンス出現の長さを示す。

図７Ｋに示す他の実施例においては、繰り返しシーケンス出現テーブル７６０は、繰り返しシーケンスの出現を表すために用いられる。サブサンプル記述ＩＤフィールドの最上位ビットは、エントリがサブサンプル記述ＩＤであるか否かを示すシーケンスフラグ７６２のランとして、又は、サブサンプル記述関連付けボックス７２４の一部である繰り返しシーケンス出現テーブル７６０内のエントリのシーケンスインデクス７６４として用いられる。繰り返しシーケンス出現テーブル７６０は、繰り返しシーケンスにおける最初のアイテムのサブサンプル記述関連付けボックス７２４におけるインデクスを特定するための出現インデックスフィールドと、繰り返しシーケンスの長さを指定するためのシーケンス長領域とを含んでいる。

パラメータセット
ＪＶＴ等の所定のメディアフォーマットでは、メディアデータを適切に復号するために必要である基準制御値（critical control value）を含む「ヘッダ」情報が、符号化されたデータの残りの部分から分離され／切り離され、パラメータセット内に保存される。これにより、ストリームにおけるこれらの制御値を符号化されたデータに混在させるのではなく、一意的識別子等のメカニズムを用いて、符号化されたデータにより必要なパラメータセットを示すことができる。この手法により、符号化されたデータから、より高レベルの符号化パラメータの伝送を分離することができる。また、同時に、制御値の共通の組をパラメータセットとして共有することによって、冗長度を低下させることができる。

パラメータセットを用いる保存されたメディアストリームの効率的な送信をサポートするためには、送信側又はプレーヤは、パラメータセットを伝送し又はパラメータセットにアクセスする時刻及び場所を知るために、符号化されたデータを対応するパラメータに高速にリンクする必要がある。本発明の一実施例では、メディアデータのパラメータセットと対応する部分の間の関係を特定するデータをメディアファイルフォーマット内のパラメータセットメタデータとして格納することによりこの機能を実現する。

図８及び図９は、それぞれ符号化システム１００及び復号システム２００によって実行されるパラメータセットメタデータの保存及び検索のための処理を示している。この処理は、ハードウェア（例えば回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステム又は専用マシン上で実行されるソフトウェア）又はこれらの両方の組合せを含む処理ロジックによって実行してもよい。

図８は、符号化システム１００において、パラメータセットメタデータを作成するための処理８００の一実施例を示すフローチャートである。まず、処理８００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック８０２）。このファイルは、メディアデータの一部をどのように復号するかを指定する符号化パラメータの組を含んでいる。次に、処理ロジックは、パラメータセットと呼ばれる符号化パラメータの組と、メディアデータの対応する部分と間の関係を調べ（処理ブロック８０４）、パラメータセットと、このパラメータセットとメディアデータ部分との関係を定義するパラメータセットメタデータを作成する（処理ブロック８０６）。メディアデータ部分は、サンプル又はサブサンプルによって表してもよい。

一実施例では、パラメータセットメタデータは、一組の予め定義されたデータ構造（例えば、一組のボックス）に組織化される。予め定義されたデータ構造の組は、パラメータセットに関する記述的な情報を含むデータ構造と、サンプルとこれに対応するパラメータセットの間の関係を定義する情報を含むデータ構造とを含むことができる。一実施例においては、予め定義されたデータ構造の組は、サブサンプルとこれに対応するパラメータセットの間の関係を定義する情報を含むデータ構造を含んでいる。サブサンプル−パラメータセット関係情報（sub-sample to parameter set association information）を含むデータ構造は、サンプル−パラメータセット関係情報（sample to parameter set association information）を含むデータ構造に優先されてもよく、優先されなくてもよい。

次に、一実施例では、処理ロジックは、データの繰り返しシーケンスを含むパラメータセットデータ構造が存在するか否かを判定する（デシジョンボックス８０８）。この判定の結果が肯定的である場合、処理ロジックは、データの各繰り返しシーケンスをシーケンスの出現への参照情報及びシーケンスの出現回数を表す情報に変換する（処理ブロック８１０）。

次に、処理ブロック８１２において、処理ロジックは、特定のメディアファイルフォーマット（例えば、ＪＶＴファイルフォーマット）を用いて、メディアデータに関連するファイル内にパラメータセットメタデータを含める。メディアファイルフォーマットに応じて、パラメータセットメタデータは、トラックメタデータ及び／又はサンプルメタデータとともに保存してもよく（例えば、パラメータセットに関する記述的情報を含むデータ構造をトラックボックスに含めてもよく、関連付け情報を含むデータ構造をサンプルテーブルボックスに含めてもよい。）、トラックメタデータ及び／又はサンプルメタデータとは別に保存してもよい。

図９は、復号システム２００においてパラメータセットメタデータを利用するための処理９００の一実施例を示すフローチャートであるである。まず、処理９００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック９０２）。ファイルは、データベース（ローカル又は外部のデータベース）、符号化システム１００又はネットワーク内の他の如何なる機器から受け取ってもよい。ファイルは、メディアデータのためのパラメータセット及びこのメディアデータのパラメータセットと対応する部分（例えば、対応するサンプル又はサブサンプル）の間の関係を定義するパラメータセットメタデータを含んでいる。

次に、処理ロジックは、ファイルからパラメータセットメタデータを抽出する（処理ブロック９０４）。上述のように、パラメータセットメタデータは、一組のデータ構造（例えば、一組のボックス）に保存できる。

更に、処理ブロック９０６では、処理ロジックは、抽出されたメタデータを用いて、どのパラメータセットが特定のメディアデータ部分（例えば、サンプル又はサブサンプル）に関連するかを判定する。この情報は、メディアデータ部分とこれに対応するパラメータセットの伝送時刻を制御するために用いることができる。すなわち、特定のサンプル又はサブサンプルを復号するために用いるべきパラメータセットは、サンプル又はサブサンプルを含むパケットより先に、又はサンプル又はサブサンプルを含むパケットと共に送信する必要がある。

このように、パラメータセットメタデータを用いることにより、より信頼性が高いチャンネルを介して、パラメータセットを別個に送信することが可能となり、伝送エラー又はデータ損失によってメディアストリームの一部が欠落する可能性を低減することができる。

以下、拡張ＩＳＯメディアファイルフォーマット（拡張ＩＳＯと呼ばれる）について、例示的なパラメータセットメタデータ構造を用いて説明する。但し、パラメータセットメタデータを格納するための様々なデータ構造を組み込むように、この他のファイルフォーマットを拡張してもよいことは明らかである。

パラメータセットメタデータを保存するための例示的なデータ構造を図１０Ａ〜図１０Ｅに示す。

図１０Ａに示すように、ＩＳＯファイルフォーマットによって定義されているトラックメタデータボックスを含むトラックボックス１００２は、パラメータセット記述ボックス１００４を含むように拡張される。更に、ＩＳＯファイルフォーマットによって定義されているサンプルメタデータボックスを含むサンプルテーブルボックス１００６は、サンプル−パラメータセットボックス１００８を含むように拡張される。一実施例においては、サンプルテーブルボックス１００６は、サブサンプル−パラメータセットボックスを含んでいてもよく、これは、後に詳細に説明するように、サンプル−パラメータセットボックス１００８へのサンプルに優先させることができる。

一実施例では、パラメータセットメタデータボックス１００４、１００８は、必須要件である。他の実施例においては、パラメータセット記述ボックス１００４のみが必須要件である。更に他の実施例では、全てのパラメータセットメタデータボックスの全てが任意の要件である。

図１０Ｂに示すように、パラメータセット記述ボックス１０１０は、パラメータセット記述ボックス１０１０のバージョンを指定するバージョンフィールドと、テーブル１０１２内のエントリの数を示すパラメータセット記述カウントフィールドと、パラメータセット自体のためのエントリを含むパラメータセットエントリフィールドとを含んでいる。

パラメータセットは、サンプルレベル又はサブサンプルレベルから参照することができる。図１０Ｃに示すように、サンプル−パラメータセットボックス１０１４は、サンプルレベルからパラメータセットへの参照情報を提供する。サンプル−パラメータセットボックス１０１４は、サンプル−パラメータセットボックス１０１４のバージョンを指定するバージョンフィールドと、デフォルトパラメータセットＩＤを指定するデフォルトパラメータセットＩＤフィールドと、テーブル１０１６内のエントリの数を示すエントリカウントフィールドとを含んでいる。テーブル１０１６内の各エントリは、同じパラメータセットを共有するサンプルのランにおける第１のサンプルのインデクスを提供する第１のサンプルフィールドと、パラメータセット記述ボックス１０１０へのインデクスを指定するパラメータセットインデクスとを含んでいる。デフォルトパラメータセットＩＤが０のときは、テーブル１０１６内に格納されているサンプルは、異なるパラメータセットを有する。デフォルトパラメータセットＩＤが１のときは、各サンプルに対して、一定のパラメータセットが１つのみ用いられる。

一実施例では、サブサンプル記述関係テーブルに関連して上述したように、テーブル１０１６内のデータは、各繰り返しシーケンスを最初のシーケンスへの参照情報と、このシーケンスが出現する回数を表す情報に変換することによって圧縮される。

パラメータセットとサブサンプルの間の関係を定義することによって、サブサンプルレベルからパラメータセットを参照することができる。一実施例では、パラメータセットとサブサンプルの間の関係は、上述したサブサンプル記述関連付けボックスを用いて定義される。図１０Ｄは、パラメータセットを識別する記述タイプ識別子を有するサブサンプル記述関連付けボックス１０１８を示す。（例えば、記述タイプ識別子は、「ｐａｒｓ」に等しい）。テーブル１０２０内のサブサンプル記述ＩＤは、この記述タイプ識別子に基づき、パラメータセット記述ボックス１０１０内のインデクスを示す。

一実施例では、パラメータセットを識別する記述タイプ識別子を含むサブサンプル記述関連付けボックス１０１８が存在している場合、これは、サンプル−パラメータセットボックス１０１４に優先される。

パラメータセットは、パラメータセットが作成された時点と、パラメータセットがメディアデータの対応する部分を復号するために用いられる時点との間で変更してもよい。このような変更が行われる場合、復号システム２００は、パラメータセットの変更を示すパラメータ更新パケットを受け取る。パラメータセットメタデータは、更新前と更新後の両方のパラメータセットの状態を特定するデータを含んでいる。

図１０Ｅに示すように、パラメータセット記述ボックス１０１０は、時刻ｔ０において作成された初期パラメータセット１０２２のエントリと、時刻ｔ１において受け取られたパラメータ更新パケット１０２６に応じて作成された更新パラメータセット１０２４のエントリとを含んでいる。サブサンプル記述関連付けボックス１０１８は、これらの２つのパラメータセットを対応するサブサンプルに関連付ける。

サンプルグループ
トラック内のサンプルは、メディアデータ内のハイレベルの構造を表すシーケンス（不連続であってもよい）に論理的にグループ化（区分）することができるが既存のファイルフォーマットは、このようにグループ化されたデータを表現及び保存する好適なメカニズムを有していない。例えば、ＪＶＴ等の高度な符号化形式は、単一のトラック内のサンプルを、それらの相互依存性に基づいて複数のグループに組織化する。これらのグループ（ここでは、シーケンス又はサンプルグループとも呼ぶ。）を用いて、除外可能な一連のサンプルを特定することができ、ネットワーク状態によって必要とされた場合に、これにより、時間的なスケーラビリティをサポートすることができる。ファイルフォーマットにおいて、サンプルグループを定義するメタデータを保存することにより、メディアの送信側は、上述した特徴を容易且つ効率的に実現することができる。

サンプルグループの具体例としては、例えば、フレーム間の依存関係によって、それらのサンプルが他のサンプルに依存することなく復号できる組がある。ＪＶＴでは、このようなサンプルグループは、拡張グループオブピクチャ（enhanced group of pictures：以下、拡張ＧＯＰという。）と呼ばれる。拡張ＧＯＰでは、サンプルは、サブシーケンスに分割できる。各サブシーケンスは、互いに依存し、１つの単位として処理できる一組のサンプルを含んでいる。更に拡張ＧＯＰのサンプルは、より上位のレイヤのサンプルがより下位のレイヤのサンプルのみから予測され、これにより、他のサンプルを復号する能力に影響を与えることなく、最上位のレイヤのサンプルを除外できるように、複数のレイヤに階層的に構造化できる。他の如何なるレイヤのサンプルにも依存しないサンプルを含んでいる最下位のレイヤは、ベースレイヤと呼ばれる。ベースレイヤ以外の他の全てのレイヤは、エンハンスメントレイヤ（enhancement layer）と呼ばれる。

図１１は、サンプルが２つのレイヤ、ベースレイヤ１１０２及びエンハンスメントレイヤ１１０４、及び２つのサブシーケンス１１０６、１１０８に分割される例示的な拡張ＧＯＰを示している。２つのサブシーケンス１１０６と１１０８は、互いに依存することなく破棄することができる。

図１２及び図１３は、それぞれ符号化システム１００及び復号システム２００によって実行されるサンプルグループメタデータの保存及び検索のための処理を示している。この処理は、ハードウェア（例えば回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステム又は専用マシン上で実行されるソフトウェア）又はこれらの両方の組合せを含む処理ロジックによって実行してもよい。

図１２は、符号化システム１００においてサンプルグループメタデータを作成するための処理１２００の一実施例を示すフローチャートである。まず、処理１２００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック１２０２）。メディアデータのトラック内のサンプルは、ある種の相互依存性を有する。例えば、トラックは、他の如何なるサンプルにも依存しないＩフレーム、先行する単一のサンプルに依存するＰフレーム及びＩフレーム、Ｐフレーム及びＢフレームのあらゆる組合せを含む先行する２つのサンプルに依存するＢフレームを含んでいてもよい。トラックのサンプルは、それらの相互依存性に基づいて、サンプルグループ（例えば、拡張ＧＯＰ、レイヤ、サブシーケンス等）に論理的に結合できる。

次に、処理ロジックは、各トラック内のサンプルグループを特定するためにメディアデータを調べ（処理ブロック１２０４）、サンプルグループについて記述し、どのサンプルがどのサンプルグループに含まれているかを定義するサンプルグループメタデータを作成する（処理ブロック１２０６）。一実施例では、サンプルグループメタデータは、一組の予め定義されたデータ構造（例えば、一組のボックス）に組織化される。予め定義されたデータ構造の組は、各サンプルグループに関する記述的な情報を含むデータ構造と、各サンプルグループに含まれたサンプルを特定する情報を含むデータ構造と、サブシーケンスを記述する情報を含むデータ構造と、レイヤを記述する情報を含むデータ構造とを含むことができる。次に、一実施例では、処理ロジックは、データの繰り返しシーケンスを含むサンプルグループデータ構造が存在するか否かを判定する（デシジョンボックス１２０８）。この判定の結果が肯定的である場合、処理ロジックは、データの各繰り返しシーケンスをシーケンスの出現への参照情報及びシーケンスの出現回数を表す情報に変換する（処理ブロック１２１０）。

次に、処理ブロック１２１２において、処理ロジックは、特定のメディアファイルフォーマット（例えば、ＪＶＴファイルフォーマット）を用いて、メディアデータに関連するファイル内にサンプルグループメタデータを含める。メディアファイルフォーマットに応じて、サンプルグループメタデータは、サンプルメタデータとともに保存してもよく（サンプルグループデータ構造をサンプルテーブルボックスに含めてもよい。）、サンプルメタデータとは別に保存してもよい。

図１３は、復号システム２００においてサンプルグループメタデータを利用するための処理１３００の一実施例を示すフローチャートである。まず、処理１３００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック１３０２）。ファイルは、データベース（ローカル又は外部のデータベース）、符号化システム１００又はネットワーク内の他の如何なる機器から受け取ってもよい。ファイルは、メディアデータ内のサンプルグループを定義するサンプルグループメタデータを含んでいる。

次に、処理ロジックは、ファイルからサンプルグループメタデータを抽出する（処理ブロック１３０４）。上述のように、サンプルグループメタデータは、一組のデータ構造（例えば、一組のボックス）に保存できる。

更に、処理ブロック１３０６では、処理ロジックは、抽出されたメタデータを用いて、他のサンプルを復号する能力に影響することなく除外でる一連のサンプルを特定する。一実施例では、この情報を用いて、特定のサンプルグループにおけるサンプルにアクセスし、ネットワーク容量の変化に応じてどのサンプルを破棄することができるかを判定することができる。他の実施例では、サンプルグループメタデータは、トラック内のサンプルの一部だけが処理又はレンダリングされるように、サンプルをフィルタリングするために用いられる。

このように、サンプルグループメタデータにより、サンプルへの選択的なアクセスと、スケーラビリティが容易に実現される。

以下、サンプルグループメタデータ構造の具体例について、拡張ＩＳＯメディアファイルフォーマット（拡張ＭＰ４とも呼ばれる。）に関連して説明する。但し、サンプルグループメタデータを格納するための様々なデータ構造を組み込むように、この他のファイルフォーマットを拡張してもよいことは明らかである。

サンプルグループメタデータを保存するための例示的なデータ構造を図１４Ａ〜図１４Ｅに示す。

図１４Ａに示すように、ＭＰ４によって定義されたサンプルメタデータボックスを含むサンプルテーブルボックス１４００は、サンプルグループボックス１４０２とサンプルグループ記述ボックス１４０４を含むように拡張される。一実施例では、サンプルグループメタデータボックス１４０２、１４０４は、任意の要素とする。一実施例（図示せず）では、サンプルテーブルボックス１４００は、サブシーケンス記述エントリボックス及びレイヤ記述エントリボックス等の追加的な任意のサンプルグループメタデータボックスを含んでいる。

図１４Ｂに示すように、サンプルグループボックス１４０６は、特定のサンプルグループに含まれるサンプルの組を検出するために用いられる。サンプルグループボックス１４０６の複数のインスタンスが異なる種類のサンプルグループ（例えば、拡張ＧＯＰ、サブシーケンス、レイヤ、パラメータセット等）に対応できる。サンプルグループボックス１４０６は、サンプルグループボックス１４０６のバージョンを特定するバージョンフィールドと、テーブル１４０８内のエントリの数を示すエントリカウントフィールドと、サンプルグループの種類を特定するサンプルグループ識別子フィールドと、同じサンプルグループに含まれているサンプルのランにおける第１のサンプルへのインデクスを提供する第１のサンプルフィールドと、サンプルグループ記述ボックスへのインデクスを指定するサンプルグループ記述インデクスとを含んでいる。

図１４Ｃに示すように、サンプルグループ記述ボックス１４１０は、サンプルグループの特性に関する情報を提供する。サンプルグループ記述ボックス１４１０は、サンプルグループ記述ボックス１４１０のバージョンを特定するバージョンフィールドと、テーブル１４１２内のエントリの数を示すエントリカウントフィールドと、サンプルグループの種類を特定するサンプルグループ識別子フィールドと、サンプルグループ記述子を提供するサンプルグループ記述フィールドとを含んでいる。

図１４Ｄは、レイヤ（ｌａｙｒ）サンプルグループタイプに関するサンプルグループボックス１４１６の使用を説明する図である。サンプル１〜１１は、サンプルの相互依存性に基づいて、３個のレイヤに分割される。レイヤ０（ベース層）では、サンプル（サンプル１、６、１１）は、相互に依存するのみであり、他の如何なるレイヤ内のサンプルにも依存しない。レイヤ１では、サンプル（サンプル２、５、７、１０）は、下位のレイヤ（すなわち、レイヤ０）内のサンプル及びこのレイヤ１内のサンプルに依存する。レイヤ２では、サンプル（サンプル３、４、８、９）は、下位のレイヤ（すなわち、レイヤ０及びレイヤ１）内のサンプル及びこのレイヤ２内のサンプルに依存する。したがって、レイヤ２のサンプルは、下位のレイヤ０及びレイヤ１からのサンプルを復号する能力に影響することなく除外することができる。

サンプルグループボックス１４１６におけるデータは、上述したようなサンプルとレイヤの間の関係を示す。ここに示すように、このデータは、繰り返しレイヤパターン１４１４を含んでいる。この繰り返しレイヤパターン１４１４は、上述のように、各繰り返しレイヤパターン１４１４を最初のレイヤパターンへの参照情報と、このパターンが出現する回数を表す情報に変換することによって圧縮される。

図１４Ｅは、サブシーケンス（ｓｓｅｑ）サンプルグループタイプに関するサンプルグループボックス１４１８の使用を説明する図である。サンプル１〜１１は、サンプルの相互依存性に基づいて、４個のサブシーケンスに分割される。レイヤ０におけるサブシーケンス０を除く各サブシーケンスは、他のサブシーケンスが依存しないサンプルを含んでいる。したがって、サブシーケンスにおけるサンプルは、必要に応じて、一括して除外できる。

サンプルグループボックス１４１８内のデータは、サンプルとサブシーケンスの間の関係を示している。このデータにより、対応するサブシーケンスの最初のサンプルにランダムアクセスすることができる。

一実施例では、サブシーケンス記述エントリボックスは、ＧＯＰ内のサンプルの各サブシーケンスについて説明するために使用されている。サブシーケンス記述エントリボックスは、サブシーケンス識別子データ、平均ビットレートデータ、平均フレームレートデータ、参照番号データ及び参照されたデータに関する情報を含むアレーに関係する依存関係情報を提供する。

依存関係情報は、このエントリにおいて記述されるサブシーケンスへの参照情報として用いられるサブシーケンスを特定する。サブシーケンス識別子データは、このエントリにおいて記述するサブシーケンスの識別子を提供する。平均ビットレートデータは、このサブシーケンスの平均ビットレートを示す情報（例えば、ビット又は秒によって表される）を含んでいる。一実施例においては、平均ビットレートは、ペイロードとペイロードヘッダを考慮に入れて算出される。一実施例においては、平均ビットレートが未定義である場合、平均ビットレートは、０となる。

平均フレームレートデータは、エントリのサブシーケンスのフレームにおける平均フレームレートを示す情報を含んでいる。一実施例においては、平均フレームレートが未定義である場合、平均フレームレートは、０となる。

参照番号データは、エントリのサブシーケンスにおける、直接参照されたサブシーケンスの数を示す情報を提供する。参照されたデータのアレーは、参照されたサブシーケンスに関する識別情報を提供する。

一実施例においては、追加的な層記述エントリボックスを用いて、層情報を提供する。層記述エントリボックスは、層の数、層の平均ビットレート及び平均フレームレートに関する情報を提供する。ベース層及び１以上の各エンハンスメント層については、層の数は、０となる。平均ビットレートが未定義である場合、平均ビットレートは、０となり、平均フレームレートが未定義である場合、平均フレームレートは、０となる。

ストリーム切換
典型的なストリーミングのシナリオにおける主要な要求の１つは、ネットワーク状態の変化に応じて圧縮データのビット伝送速度をスケーリングすることである。これを実現する最も単純な手法は、代表的なネットワーク状態に対応する異なるビットレート及び品質設定で複数のストリームを符号化することである。これにより、サーバは、ネットワーク状態に応じて、これらの予め符号化されたストリーム間を切り換えることができる。

ＪＶＴ規格は、２つのピクチャのそれぞれが予測に同じフレームを用いることなく一方のピクチャを他方のピクチャと同様に再構築できる切換ピクチャと呼ばれる新しい種類のピクチャを提供する。特に、ＪＶＴは、Ｉフレームと同様に、他の如何なるピクチャにも依存せずに符号化されるＳＩピクチャと、他のピクチャを参照して符号化されるＳＰピクチャの２つのタイプの切換ピクチャを提供する。切換ピクチャを用いることにより、伝送条件の変化に対応して、異なるビット伝送速度と品質設定を有するストリーム間で切換を行い、エラー回復及び早送り及び巻戻し等のトリックモードを実現することができる。

ここで、ＪＶＴ切換ピクチャを有効に活用するためには、ストリーム切換、エラー回復、トリックモード及び他の特徴を実現する場合、プレーヤは、保存されたメディアデータのどのサンプルが代替的な表現を有するか及びこれらのサンプルの依存関係は如何なるものであるかを知る必要がある。既存のファイルフォーマットは、このような機能を提供しない。

本発明の一実施例では、切換サンプルセットを定義することによってこの問題を解決する。切換サンプルセットは、復号値が同じであるが、異なる参照サンプルを用いることができるサンプルの組を表す。参照サンプルは、他のサンプルの値を予測するために用いられるサンプルである。切換サンプルセットの各要素は、切換サンプルと呼ばれる。図１５Ａは、切換サンプルセットを用いたビットストリーム切換を説明する図である。

図１５Ａに示すように、ストリーム１及びストリーム２は、異なる品質及びビットレートパラメータを有する同じコンテンツの２つの符号化データ（encodings）を表している。サンプルＳ１２は、どちらのストリームにも出現せず、ストリーム１からストリーム２への切換（切換は、方向的性質を有する）を実現するために用いられるＳＰピクチャである。サンプルのＳ１２、Ｓ２は、切換サンプルセットに含まれている。Ｓ１とＳ１２は、いずれもトラック１のサンプルＰ１２から予測され、Ｓ２は、トラック２のサンプルＰ２２から予測される。サンプルのＳ１２とＳ２は、異なる参照サンプルを用いるが、これらの復号値は同一である。したがって、ストリーム１からストリーム２への（ストリーム１内のサンプルＳ１とストリーム２内のサンプルＳ２における）切換は、切換サンプルＳ１２を介して行うことができる。

図１６及び図１７は、それぞれ符号化システム１００及び復号システム２００によって実行される切換サンプルメタデータの保存及び検索のための処理を示している。この処理は、ハードウェア（例えば回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステム又は専用マシン上で実行されるソフトウェア）又はこれらの両方の組合せを含む処理ロジックによって実行してもよい。

図１６は、符号化システム１００において、切換サンプルメタデータを作成するための処理１６００の一実施例を示すフローチャートである。まず、処理１６００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック１６０２）。このファイルは、メディアデータに関する１以上の代替的な符号化データ（例えば、代表的なネットワーク状態に対応する異なる帯域幅及び品質設定を有する。）を含んでいる。代替的な符号化データは、１つ以上の切換ピクチャを含んでいる。このようなピクチャは、代替的なメディアデータストリーム内に含めてもよく、エラー回復又はトリックモード等の特別な特徴を実現する個別のエンティティとして作成してもよい。本発明では、これらのトラック及び切換ピクチャを作成する手法を特に限定しないが、当業者にとって、様々な手法を用いることができることは明らかである。例えば、代替的符号化データを含む各トラックの対の間に切換サンプルを周期的に（例えば、１秒毎に）挿入してもよい。

次に、処理ロジックは、異なる参照サンプルを用いて、同じ復号値が導出されるサンプルを含む切換サンプルセットを作成するためにファイルを調べ（処理ブロック１６０４）、メディアデータに関する切換サンプルセットを定義し、切換サンプルセット内のサンプルを記述する切換サンプルメタデータを作成する（処理ブロック１６０６）。一実施例では、切換サンプルメタデータは、ネスト化されたテーブルの組を含むテーブルボックス等の予め定義されたデータ構造に組織化される。

次に、一実施例において、処理ロジックは、切換サンプルメタデータ構造がデータの繰り返しシーケンスを含むか否かを判定する（デシジョンボックス１６０８）。この判定の結果が肯定的である場合、処理ロジックは、データの各繰り返しシーケンスをシーケンスの出現への参照情報及びシーケンスの出現回数を表す情報に変換する（処理ブロック１６１０）。

次に、処理ブロック１６１２において、処理ロジックは、特定のメディアファイルフォーマット（例えば、ＪＶＴファイルフォーマット）を用いて、メディアデータに関連するファイル内に切換サンプルメタデータを含める。一実施例においては、切換サンプルメタデータは、ストリーム切換のために指定された別のトラックに保存してもよい。他の実施例においては、切換サンプルメタデータは、サンプルメタデータとともに保存される（例えば、シーケンスデータ構造は、サンプルテーブルボックスに含めてもよい）。

図１７は、復号システム２００において切換サンプルメタデータを利用するための処理１７００の一実施例を示すフローチャートであるである。まず、処理１７００は、処理ロジックが符号化されたメディアデータに関連するファイルを受け取ることにより開始される（処理ブロック１７０２）。ファイルは、データベース（ローカル又は外部のデータベース）、符号化システム１００又はネットワーク内の他の如何なる機器から受け取ってもよい。ファイルは、メディアデータに関連する切換サンプルセットを定義する切換サンプルメタデータを含んでいる。

次に、処理ロジックは、ファイルからサンプルグループメタデータを抽出する（処理ブロック１７０４）。上述のように、切換サンプルメタデータは、例えば、ネスト化されたテーブルの組を含むテーブルボックス等のデータ構造に保存できる。

更に処理ブロック１７０６において、処理ロジックは、抽出されたメタデータを用いて、特定のサンプルを含む切換サンプルセットを検出し、切換サンプルセットからの代替のサンプルを選択する。初期サンプルと同じ復号値を有する代替のサンプルを用いて、ネットワーク状態の変化に応じて、異なる符号化処理が施された２つのビットストリームを切り換えてもよく、これにより、ビットストリーム内にランダムアクセスエントリポイントを提供でき、エラー回復が容易になる。

以下、切換サンプルメタデータ構造の具体例について、拡張ＩＳＯメディアファイルフォーマット（拡張ＭＰ４とも呼ばれる。）に関連して説明する。但し、切換サンプルメタデータを格納するための様々なデータ構造を組み込むように、この他のファイルフォーマットを拡張してもよいことは明らかである。

図１８は、切換サンプルメタデータを保存するための例示的なデータ構造を示している。例示的なデータ構造は、一組のネスト化されたテーブルを含む切換サンプルテーブルボックスの形式を有している。テーブル１８０２内の各エントリは、１つの切換サンプルセットを特定する。各切換サンプルセットは、再構築の結果が客観的に同じである（又は、知覚的に同じである）が、切換サンプルと同じ又は異なるトラック（ストリーム）内の異なる参照サンプルから予測される場合もある切換サンプルのグループからなる。テーブル１８０２内の各エントリは、対応するテーブル１８０４にリンクされる。テーブル１８０４は、切換サンプルセットに含まれる各切換サンプルを特定する。テーブル１８０４内の各エントリは、更に切換サンプルの位置（すなわち、そのトラックとサンプル番号）を定義する対応するテーブル１８０６にリンクされ、トラックは、切換サンプルによって用いられる参照サンプルと、切換サンプルによって用いられる参照サンプルの総数と、切換サンプルによって用いられる各切換サンプルとを含んでいる。

図１５Ａに示すように、一実施例では、切換サンプルメタデータは、同じコンテンツの異なる符号化が施されたされたバージョンを切り換えるために用いることができる。ＭＰ４では、各代替的な符号化データは、別々のＭＰ４トラックとして保存され、トラックヘッダ内の「代替グループ（alternate group）」は、そのデータが特定のコンテンツを代替的な符号化データであることを示す。

図１５Ｂは、図１５Ａに示すサンプルＳ２、Ｓ１２からなる切換サンプルセット１５０２を定義するメタデータを含むテーブルを示している。

図１５Ｃは、２つのビットストリーム間の切替を行うポイントを決定するための処理１５１０の一実施例を示すフローチャートである。ストリーム１からストリーム２への切換を行う場合、処理１５１０は、まず、切換サンプルメタデータを検索し、そしてストリーム１の参照トラックを有する切換サンプル及びストリーム２の切換サンプルトラックを有する切換サンプルを含む全ての切換サンプルセットを検出する（処理ブロック１５１２）。次に、検出された切換サンプルセットを評価し、ストリーム１の参考トラックを有する切換サンプルの全ての参照サンプルが利用可能である切換サンプルセットを選択する（処理ブロック１５１４）。例えばストリーム１の参照トラックを有する切換サンプルがＰフレームである場合、切換を行う前に、１つのサンプルが利用可能である必要がある。更に、選択された切換サンプルセットにおけるサンプルは、切換ポイントを特定するために用いられる（処理ブロック１５１６）。すなわちストリーム１の参照トラックを有する切換サンプルを介して、ストリーム１の参照トラックを有する切換サンプルの最も高い参照サンプル（highest reference sample）の直後及びストリーム２の切換サンプルトラックを有する切換サンプルの直後のサンプルが切換ポイントであるとみなされる。

他の実施例においては、切換サンプルメタデータを用いて、図１９Ａ〜図１９Ｃに示すように、ビットストリームにおけるエントリポイントへのランダムアクセスを容易に行うことができる。

図１９Ａ及び図１９Ｂに示すように、切換サンプル１９０２は、サンプルＳ２、Ｓ１２を含む。Ｓ２は、Ｐ２２から予測され、通常のストリーム再生時に用いられるＰフレームである。Ｓ１２は、（例えばスプライスのために）ランダムアクセスポイントとして用いられる。Ｓ１２が一旦復号されると、Ｐ２４の復号を含むストリーム再生は、Ｐ２４がＳ２の後に復号されているかのようにして続行される。

図１９Ｃは、サンプルに関するランダムアクセスポイント（例えば、トラックＴにおけるサンプルＳ）を決定するための処理１９１０の一実施例を示すフローチャートである。処理１９１０は、切換サンプルメタデータを検索し、切換サンプルトラックＴを有する切換サンプルを含む全ての切換サンプルセットを検出することによって開始される（処理ブロック１９１２）。次に、検出された切換サンプルセットを評価し、切換サンプルトラックＴを有する切換サンプルが、復号順序において、サンプルＳに先行する最も近いサンプルである切換サンプルセットを選択する（処理ブロック１５１４）。更に選択された切換サンプルセットから、サンプルＳへのランダムアクセスポイントとして、切換サンプルトラックＴを有する切換サンプル以外の切換サンプル（サンプルＳＳ）を選択する（処理ブロック１９１６）。ストリーム再生時には、サンプルＳの代わりに（サンプルＳＳのためのエントリにおいて特定された全ての参照サンプルを復号することによって）サンプルＳＳが復号される。

更に別の実施例では図２０Ａ〜２０Ｃに示すように、切換サンプルメタデータを用いて、エラー回復を容易に行うことができる。

図２０Ａ及び図２０Ｂに示すように、切換サンプル２００２は、サンプルＳ２、Ｓ１２、Ｓ２２を含む。サンプルＳ２は、サンプルＰ４から予測される。サンプルＳ１２は、サンプルＳ１から予測される。サンプルのＰ２とＰ４の間にエラーが発生した場合、サンプルＳ２の代わりに切換サンプルＳ１２を復号できる。これに続いて、ストリーミングは、通常通りサンプルＰ６から続行される。また、エラーがサンプルＳ１に影響を与えた場合、同様に、サンプルＳ２の代わりに切換サンプルＳ２２を復号でき、これに続いて、ストリーミングは、通常通りサンプルＰ６から続行される。

図２０Ｃは、サンプル（例えば、サンプルＳ）を送信する際のエラー回復を容易にするための処理２０１２の一実施例を示すフローチャートである。処理２０１２は、切換サンプルメタデータを検索し、サンプルＳに等しい切換サンプルを含む全ての切換サンプルセットを検出することによって開始される（処理ブロック２０１０）。次に、検出された切換サンプルセットを評価し、サンプルＳに最も近く、参照サンプル値が正しいことが既知である（フィードバック又は他の情報源を介して）切換サンプルＳＳを有する切換サンプルを選択する（処理ブロック２０１４）。そして、サンプルＳの代わりに切換サンプルＳＳを送信する（処理ブロック２０１６）。

パラメータセット及び補足的拡張情報の保存
上述のように、パラメータセットメタデータ等の幾つかのメタデータは、関連するメディアデータから独立して保存できる。図２１は、本発明の一実施例に基づいて、パラメータセットメタデータを別個に保存する手法を説明する図である。図２１に示すように、メディアデータは、ビデオトラック２１０２に保存され、パラメータセットメタデータは、独立したパラメータトラック２１０４に保存される。このパラメータトラック２１０４には、メディアデータが保存されていないことを示すために、「非アクティブ（inactive）」のマークを付してもよい。タイミング情報２１０６は、ビデオトラック２１０２とパラメータトラック２１０４の間の同期に用いられる。一実施例においては、タイミング情報は、ビデオトラック２１０２とパラメータセットトラック２１０４のそれぞれのサンプルテーブルボックス内に保存される。一実施例においては、各パラメータセットは、１個のパラメータセットサンプルによって表され、同期は、メディアサンプルのタイミング情報がパラメータセットサンプルのタイミング情報と等しい場合に実現される。

他の実施例においては、オブジェクト記述子（object descriptor：ＯＤ）メッセージを用いて、パラメータセットメタデータが含められる。ＭＰＥＧ−４規格では、オブジェクト記述子は、単一のオブジェクト（メディアオブジェクト又はシーン記述）に関連するストリームの構成及びこの他の情報を提供する１つ以上のエレメンタリストリーム記述子を表す。オブジェクト記述子メッセージは、オブジェクト記述子ストリームを介して送信される。図２２に示すように、パラメータセットは、オブジェクト記述子メッセージ２２０４としてオブジェクト記述子ストリーム２２０２に含まれている。オブジェクト記述子ストリーム２２０２は、メディアデータを搬送するビデオエレメンタリストリームと同期する。

ＳＥＩの保存について、更に詳細に説明する。

一実施例においては、ＳＥＩデータは、メディアデータとともに、エレメンタリストリームに保存される。図２３は、メディアデータと共にエレメンタリストリームデータ２３０２に直接埋め込まれているＳＥＩメッセージ２３０４を示す。

他の実施例においてはＳＥＩメッセージは、サンプルとして独立したＳＥＩトラックに保存される。

本発明の幾つかの実施例における、独立したトラックにおけるＳＥＩメッセージの保存の手法を図２４及び図２５に示す、
図２４に示す具体例では、メディアデータは、ビデオトラック２４０２に保存され、ＳＥＩメッセージは、サンプルとして、独立したＳＥＩトラック２４０４に保存される。タイミング情報２４０６は、ビデオトラック２４０２とＳＥＩトラック２４０４との間の同期に用いられる。

図２５に示す具体例では、メディアデータは、ビデオトラック２５０２に保存され、ＳＥＩメッセージは、オブジェクトコンテンツ情報（object content information：以下、ＯＣＩという。）トラック２５０４に保存される。タイミング情報２５０６は、ビデオトラック２５０２とＯＣＩトラック２５０４の間の同期に用いられる。ＭＰＥＧ−４規格では、ＯＣＩトラック２５０４は、シーンイベントに関する記述的なテキスト情報を提供するために共通に使用されるＯＣＩデータを保存するために用いられる。各ＳＥＩメッセージは、オブジェクト記述子としてＯＣＩトラック２５０４に保存される。一実施例においては、多くの場合、ＯＣＩトラックに格納されているデータのタイプを指定するＯＣＩ記述子エレメントフィールドは、ＳＥＩメッセージを搬送するために使用される。

更に別の実施例では、ＳＥＩデータは、メディアデータから独立したメタデータとして保存される。図２６は、本発明の一実施例に従ってメタデータとして保存されたＳＥＩデータを示している。

図２６に示すように、ＩＳＯメディアファイルフォーマットによって定義されているユーザデータボックス２６０２は、ＳＥＩメッセージを保存するために使用されている。具体的には、各ＳＥＩメッセージは、トラック又はムービーボックスに含まれているユーザデータボックス２６０２内のＳＥＩユーザデータボックス２６０４に保存される。

一実施例においては、ＳＥＩメッセージに含まれているメタデータは、メディアデータの記述を含んでいる。これらの記述は、ＭＰＥＧ−７規格よって定義されている記述子と記述スキームを表していてもよい。一実施例においては、ＳＥＩメッセージは、ＸＭＬに基づく記述等のＸＭＬベースのデータの包含をサポートする。更に、ＳＥＩメッセージは、異なる種類のエンハンス情報の登録をサポートする。例えば、ＳＥＩメッセージは、新たな種類の登録を必要とすることなく、匿名のユーザデータをサポートできる。このようなデータは、特定の用途又は組織に限定して用いられることを意図するデータであってもよい。一実施例においては、ＳＥＩの存在は、ビットストリーム環境において、指定された開始コードによって示される。

一実施例においては、ＳＥＩメッセージにおいて記述されている拡張された能力の一部又は全てを提供するデコーダの能力は、外部の手法（例えば、Ｈ．２４５又はＳＤＰ勧告）によって示される。拡張された能力を有さないデコーダでは、単に、ＳＥＩメッセージを削除してもよい。

一実施例においては、後に詳細に説明するように、ＳＥＩメッセージのペイロードヘッダにおける指定されたフィールドを用いることにより、メディアデータ（例えば、画像符号化レイヤデータ）及びメディアデータの記述を含んでいるＳＥＩメッセージを同期させる。

一実施例においては、ネットワークアダプテーション層は、基本的なトランスポートシステムにおける補足的拡張情報メッセージの伝送をサポートする。ネットワークアダプテーション層は、容認することができる帯域内（画像符号化層と同じトランスポートストリーム）又は帯域外のいずれによってＳＥＩメッセージをシグナリングしてもよい。

一実施例においては、ＭＰＥＧ−７メタデータのＳＥＩメッセージへの組込みは、ＭＰＥＧ−７メタデータのデリバリ層としてＳＥＩを用いることによって実現される。詳しくは、ＳＥＩメッセージは、１つ以上の記述フラグメントを表すＭＰＥＧ−７システムアクセスユニット（フラグメント）をカプセル化する。ＭＰＥＧ−７アクセスユニットとメディアデータとの同期は、ＳＥＩメッセージのペイロードヘッダにおいて、指定されたフィールドを用いることによって実現される。

他の実施例においては、ＭＰＥＧ−７メタデータのＳＥＩメッセージへの組込みは、テキスト符号化又はバイナリの符号化のいずれかに基づいて、記述ユニットによってＳＥＩメッセージを送信することによって実現される。記述ユニットは、単一のＭＰＥＧ−７記述子であってもよく、記述スキームであってもよく、完全な記述からの部分的な情報を表すために用いることができる。スケーラブルなカラー記述子のためのＸＭＬ構文の具体例を以下に示す。

記述子又は記述スキームインスタンスは、後に詳細に説明するように、ＳＥＩメッセージヘッダを介して、メディアデータの対応する部分（例えば、サブサンプル、サンプル、フラグメント等）に関連付けることができる。この実施例では、例えば、単一のフレームのためのバイナリ符号化又はテキスト符号化されたカラー記述子をＳＥＩメッセージとして送ることができる。ＳＥＩメッセージを用いることにより、画像符号化ストリームの潜在的な記述を提供できる。潜在的な記述とは、記述ユニットが潜在的に含まれている画像符号化ストリームの完全な記述である。潜在的な記述は、以下のような形式を有していてもよい。

一実施例においては、記述のＳＥＩメッセージへの組込みをサポートするためにＳＥＩのフォーマットを改訂する。具体的には、ＳＥＩをＳＥＩメッセージのグループとして表す。一実施例においては、ＳＥＩをデータのチャンクにカプセル化する。各ＳＥＩチャンクは、１つ以上のＳＥＩメッセージを含むことができる。各ＳＥＩメッセージは、ＳＥＩヘッダとＳＥＩペイロードを含む。ＳＥＩヘッダは、バイト列において、ＳＥＩチャンクの最初のバイトから又は先のＳＥＩメッセージに続く最初の第１バイトから開始される。ペイロードは、ＳＥＩヘッダの直後に続き、ＳＥＩヘッダに続くバイトから開始される。

ＳＥＩヘッダは、メッセージの種類、メディアデータ部分の任意の識別子（例えば、サブサンプル、サンプル、フラグメント）、ペイロード長に関する情報を含んでいる。ＳＥＩヘッダの構文は、例えば、以下の通りである。

ＭｅｓｓａｇｅＴｙｐｅフィールドは、ペイロードのメッセージの種類を示す。ＳＥＩメッセージタイプコードの具体例を以下の表１に示す。

ＰａｙｌｏａｄＬｅｎｇｔｈフィールドは、バイトで表現されるＳＥＩメッセージペイロードの長さを指定する。また、ＳＥＩヘッダは、このＳＥＩメッセージが特定のサンプルに関連付けられているか否かをを示すサンプル同期フラグと、このＳＥＩメッセージが特定のサブサンプルに関連付けられているか否かをを示すサブサンプル同期フラグと（サブサンプル同期フラグが設定されている場合、サンプル同期フラグも設定される）とを含んでいる。更に、ＳＥＩペイロードは、このメッセージが関連付けられているサンプルを指定するオプションのサンプル識別子フィールドと、メッセージが関連付けられているサブサンプルを指定するオプションのサブサンプル識別子フィールドとを含んでいる。サンプル識別子フィールドは、サンプル同期フラグが設定される場合にのみ存在する。同様に、サブサンプル識別子フィールドは、サブサンプル同期フラグが設定される場合にのみ存在する。サンプル識別子とサブサンプル識別子フィールドにより、ＳＥＩメッセージをメディアデータに同期させることができる。

一実施例においては、各ＳＥＩメッセージは、ＳＥＩメッセージ記述子によって送信される。ＳＥＩ記述子は、１つ以上のＳＥＩメッセージを含むＳＥＩユニットにカプセル化される。ＳＥＩメッセージユニットの構文は、以下の通りである。

ＳＥＩメッセージ記述子の構文は、以下の通りである。

タイプフィールドは、ＳＥＩメッセージの種類を示す。ＳＥＩメッセージの具体例を以下の表２に示す。

以下、表２に示す様々な種類のＳＥＩメッセージについて、詳細に説明する。

ＳＥＩＸＭＬＤｅｓｃｒｉｐｔｏｒタイプは、例えば、完全なＸＭＬ文書又はより大きい文書からのＸＭＬフラグメントを含むことができるＸＭＬベースのデータをカプセル化する記述子を示す。ＳＥＩＸＭＬＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ＳＥＩＭｅｔａｄａｔａＤｅｓｃｒｉｐｔｏｒタイプは、メタデータを含む記述子を示す。ＳＥＩＭｅｔａｄａｔａＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ｍｅｔａｄａｔａＦｏｒｍａｔフィールドは、メタデータのフォーマットを特定する。メタデータフォーマットの値の具体例を以下の表３に示す。

値０ｘ１０は、ＭＰＥＧ−７によって定義されているデータを示す。０ｘ４０〜０ｘＦＦまでの包括的な範囲に属する値は、独自のフォーマット（private format）の使用を示すために利用可能である。

ｍｅｔａｄａｔａＣｏｎｔｅｎｔフィールドは、ｍｅｔａｄａｔａＦｏｒｍａｔフィールドによって特定されたフォーマットによるメタデータの表現を含んでいる。

ＳＥＩＭｅｔａｄａｔａＲｅｆＤｅｓｃｒｉｐｔｏｒタイプは、メタデータの位置を示すＵＲＬを指定する記述子を示す。ＳＥＩＭｅｔａｄａｔＲｅｆＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ＵＲＬＳｔｒｉｎｇフィールドは、メタデータの位置を示すＵＴＦ−８符号化されたＵＲＬを含んでいる。

ＳＥＩＴｅｘｔＤｅｓｃｒｉｐｔｏｒタイプは、ビデオコンテンツを説明する又はビデオコンテンツに関係するテキストを含む記述子を示す。ＳＥＩＴｅｘｔＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ｌａｎｇｕａｇｅＣｏｄｅフィールドは、これに続くテキストフィールドの言語に関する言語コードを含んでいる。テキストフィールドは、ＵＴＦ−８符号化されたテキストデータを含んでいる。

ＳＥＩＵＲＩＤｅｓｃｒｉｐｔｏｒタイプは、ビデオコンテンツに関連するユニフォームリソース識別子（uniform resource identifier：ＵＲＩ）を含む記述子を示す。ＳＥＩＵＲＩＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ｕｒｉＳｔｒｉｎｇフィールドは、ビデオコンテンツのＵＲＩを含んでいる。

ＳＥＩＯＣＬＤｅｓｃｒｉｐｔｏｒタイプは、オブジェクトコンテンツ情報（Object Content Information：ＯＣＩ）記述子を表すＳＥＩメッセージを含む記述子を示す。ＳＥＩＯＣＬＤｅｓｃｒｉｐｔｏｒの構文は、以下の通りである。

ｏｃｉＤｅｓｃｒフィールドは、ＯＣＩ記述子を含んでいる。

ＳＥＩＳｔａｒｔＳｅｇｍｅｎｔＤｅｓｃｒｉｐｔｏｒタイプは、後に他のＳＥＩメッセージに参照されることができるセグメントの最初を示す記述子を示す。セグメントの開始は、このＳＥＩ記述子が適用されるあるレイヤ（例えば、サンプルのグループ、セグメント、サンプル又はサブサンプル）に関連付けられる。ＳＥＩＳｔａｒｔＳｅｇｍｅｎｔＤｅｃｒｉｐｔｏｒの構文は、以下の通りである。

ｓｅｇｍｅｎｔＩＤフィールドは、このセグメントを含むストリーム内における固有のバイナリ識別子（unique binary identifier）を示す。この値を用いて、他のＳＥＩメッセージのセグメントを参照することができる。

ＳＥＩＥｎｄＳｅｇｍｅｎｔＤｅｃｒｉｐｔｏｒタイプは、セグメントの最後を示す記述子を示す。これに先行して、同じｓｅｇｍｅｎｔＩＤ値を含むＳＥＩＳｔａｒｔＳｅｇｍｅｎｔメッセージが存在する必要がある。ここで不一致が発生した場合、デコーダは、このメッセージを無視する必要がある。セグメントの最後は、このＳＥＩ記述子が適用されるあるレイヤ（例えば、サンプルのグループ、セグメント、サンプル又はサブサンプル）に関連付けられる。ＳＥＩＥｎｄＳｅｇｍｅｎｔＤｅｃｒｉｐｔｏｒの構文は以下の通りである。

ｓｅｇｍｅｎｔＩＤフィールドは、このセグメントを含むストリーム内における固有のバイナリ識別子を示す。この値を用いて、他のＳＥＩメッセージのセグメントを参照することができる。

オーディオビジュアルメタデータのストレージ及び検索について説明した。ここでは、特定の実施の形態を示したが、ここに示した特定の実施の形態に代えて、同じ目的を達成する如何なる構成を用いてもよいことは当業者にとって明らかである。したがって、本出願は、本発明のあらゆる適応例及び変形例を包含するものとする。

符号化システムの一実施例のブロック図である。 復号システムの一実施例のブロック図である。 本発明の実現に好適なコンピュータ環境のブロック図である。 符号化システムにおいて、サブサンプルメタデータを保存するための処理に関するフローチャートである。 復号システムにおいて、サブサンプルメタデータを使用するための処理に関するフローチャートである。 サブサンプルを有する拡張ＭＰ４メディアストリームモデルを説明する図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 サブサンプルメタデータを保存するための例示的なデータ構造を示す図である。 符号化システムにおいてパラメータセットメタデータを保存するための処理に関するフローチャートである。 復号システムにおいて、パラメータセットメタデータを利用するための処理に関するフローチャートである。 パラメータセットメタデータを保存するための例示的なデータ構造を示す図である。 パラメータセットメタデータを保存するための例示的なデータ構造を示す図である。 パラメータセットメタデータを保存するための例示的なデータ構造を示す図である。 パラメータセットメタデータを保存するための例示的なデータ構造を示す図である。 パラメータセットメタデータを保存するための例示的なデータ構造を示す図である。 例示的な拡張グループオブピクチャ（ＧＯＰ）を示す図である。 符号化システムにおいて、シーケンスメタデータを保存するための処理に関するフローチャートである。 復号システムにおいて、シーケンスメタデータを使用するための処理に関するフローチャートである。 シーケンスメタデータを保存するために例示的なデータ構造を示す図である。 シーケンスメタデータを保存するために例示的なデータ構造を示す図である。 シーケンスメタデータを保存するために例示的なデータ構造を示す図である。 シーケンスメタデータを保存するために例示的なデータ構造を示す図である。 シーケンスメタデータを保存するために例示的なデータ構造を示す図である。 ビットストリーム切換のための切換サンプルセットの使用法を示す図である。 ビットストリーム切換のための切換サンプルセットの使用法を示す図である。 ２つのビットストリームの間の切換を行うポイントを判定するための処理の一実施例を示すフローチャートである。 符号化システムにおいて、切換サンプルメタデータを保存するための処理に関するフローチャートである。 復号システムにおいて、切換サンプルメタデータを使用するための処理に関するフローチャートである。 切換サンプルメタデータを保存するための例示的なデータ構造を示す図である。 ランダムアクセスエントリポイントを実現するための切換サンプルセットの使用法を示す図である。 ランダムアクセスエントリポイントを実現するための切換サンプルセットの使用法を示す図である。 サンプルのランダムアクセスポイントを判定するための処理の一実施例に関するフローチャートである。 エラー回復を実現するための切換サンプルセットの使用法を示す図である。 エラー回復を実現するための切換サンプルセットの使用法を示す図である。 サンプル送信時のエラー回復を実現するための処理の一実施例に関するフローチャートである。 本発明の幾つかの実施例に基づくパラメータセットメタデータの保存を説明する図である。 本発明の幾つかの実施例に基づくパラメータセットメタデータの保存を説明する図である。 本発明の幾つかの実施例に基づく補足的拡張情報（supplemental enhancement information：ＳＥＩ）の保存を説明する図である。 本発明の幾つかの実施例に基づく補足的拡張情報（supplemental enhancement information：ＳＥＩ）の保存を説明する図である。 本発明の幾つかの実施例に基づく補足的拡張情報（supplemental enhancement information：ＳＥＩ）の保存を説明する図である。 本発明の幾つかの実施例に基づく補足的拡張情報（supplemental enhancement information：ＳＥＩ）の保存を説明する図である。

Claims (34)

1. マルチメディアデータの複数の部分の１つ以上のパラメータセットを定義するパラメータセットメタデータを特定するステップと、
   マルチメディアデータを復号するために復号システムに送信されるパラメータセットメタデータをマルチメディアデータとは別に保存するステップとを有するデータ処理方法。
2. 上記マルチメディアデータの複数の部分は、該マルチメディアデータ内のサンプルであることを特徴とする請求項１記載のデータ処理方法。
3. 上記マルチメディアデータの複数の部分は、該マルチメディアデータの部分内のサブサンプルであることを特徴とする請求項１記載のデータ処理方法。
4. 上記マルチメディアデータは、ビデオトラックに保存され、
   上記パラメータセットメタデータは、パラメータトラックに保存されることを特徴とする請求項１記載のデータ処理方法。
5. 上記パラメータトラックを上記ビデオトラックと同期させるステップを更に有する請求項４記載のデータ処理方法。
6. 上記パラメータトラックは、非アクティブであることを特徴とする請求項４記載のデータ処理方法。
7. 上記各パラメータセットは、パラメータセットサンプルとして、上記パラメータトラックに保存されることを特徴とする請求項４記載のデータ処理方法。
8. ビデオエレメンタリストリームを介して上記マルチメディアデータを送信するステップと、
   上記パラメータセットメタデータをオブジェクト記述子ストリームとして送信するステップとを更に有する請求項１記載のデータ処理方法。
9. 上記各パラメータセットは、オブジェクト記述子メッセージとして、オブジェクト記述子ストリームを介して送信されることを特徴とする請求項８記載のデータ処理方法。
10. 上記オブジェクト記述子ストリームを上記ビデオエレメンタリストリームに同期させるステップを更に有する請求項８記載のデータ処理方法。
11. 復号システムにおいて、マルチメディアデータ及び独立したパラメータセットメタデータを受信するステップを更に有し、該独立したパラメータセットメタデータは、少なくともマルチメディアデータの一部を復号するために必要である１つ以上のパラメータセットのどれかを特定するために用いられることを特徴とする請求項１記載のデータ処理方法。
12. マルチメディアデータに関係する１つ以上の記述を特定するステップと、
    後に復号システムに送信され、上記マルチメディアデータの復号において任意に使用される補足的拡張情報（supplemental enhancement information：ＳＥＩ）に上記マルチメディアデータに関連する１つ以上の記述を含めるステップとを有するデータ処理方法。
13. 上記ＳＥＩは、マルチメディアデータとは別にＳＥＩメタデータとして保存されることを特徴とする請求項１２記載のデータ処理方法。
14. 上記ＳＥＩメタデータは、複数のＳＥＩメッセージを含んでいることを特徴とする請求項１３記載のデータ処理方法。
15. 上記複数のＳＥＩメッセージのそれぞれは、ムービーボックスのトラックのボックスとして保存されることを特徴とする請求項１４記載のデータ処理方法。
16. 上記マルチメディアデータは、ビデオトラックに保存され、上記ＳＥＩメタデータは、ＳＥＩトラックに保存されることを特徴とする請求項１３記載のデータ処理方法。
17. 上記ＳＥＩトラックをビデオトラックに同期させるステップを更に有する請求項１６記載のデータ処理方法。
18. 上記ＳＥＩトラックは、サンプル内に複数のＳＥＩメッセージを含んでいることを特徴とする請求項１７記載のデータ処理方法。
19. ビデオエレメンタリストリームを介して上記マルチメディアデータを送信するステップと、
    オブジェクトコンテンツ情報（object content information：ＯＣＩ）ストリームを介して、上記ＳＥＩメタデータを送信するステップとを更に有する請求項１３記載のデータ処理方法。
20. 上記複数のＳＥＩメッセージのそれぞれは、ＯＣＩ記述子として、ＯＣＩストリームを介して送信されることを特徴とする請求項１９記載のデータ処理方法。
21. 上記１つ以上の記述のそれぞれは、記述子及び記述子スキームのいずれかであることを特徴とする請求項１２記載のデータ処理方法。
22. 上記複数のＳＥＩメッセージのそれぞれは、該複数のＳＥＩメッセージのそれぞれをマルチメディアデータの対応する部分に関連付けるデータを有するペイロードヘッダを含んでいることを特徴とする請求項１４記載のデータ処理方法。
23. 上記マルチメディアデータの対応する部分は、サンプル、サブサンプル、サンプルのグループのうちのいずれか１つであることを特徴とする請求項２２記載のデータ処理方法。
24. 上記１つ以上の記述をＳＥＩに含めるステップは、ＭＰＥＧ−７システムアクセスユニットを複数のＳＥＩメッセージの１つにカプセル化するステップを含むことを特徴とする請求項１２記載のデータ処理方法。
25. 上記１つ以上の記述のそれぞれを複数のＳＥＩメッセージの１つによって送信するステップを更に有する請求項１２記載のデータ処理方法。
26. 上記１つ以上の記述は、テキスト的に又はバイナリ的に符号化されることを特徴とする請求項２５記載のデータ処理方法。
27. マルチメディアデータを含む第１のファイルを作成するメディアファイル作成器と、
    マルチメディアデータの複数の部分と１つ以上のパラメータセットを定義するパラメータセットメタデータを特定し、後に復号システムにおいて、マルチメディアデータを復号するときに使用される、パラメータセットメタデータを含む第２のファイルを作成するメタデータファイル作成器とを備えるデータ処理装置。
28. マルチメディアデータを含む第１のファイルを作成するメディアファイル作成器と、
    マルチメディアデータに関係する１つ以上の記述を特定し、後に復号システムに送信され、上記マルチメディアデータの復号において任意に使用される補足的拡張情報（supplemental enhancement information：ＳＥＩ）に上記マルチメディアデータに関連する１つ以上の記述を含めるメタデータ作成器とを備えるデータ処理装置。
29. マルチメディアデータの複数の部分の１つ以上のパラメータセットを定義するパラメータセットメタデータを特定する特定手段と、
    マルチメディアデータを復号するために復号システムに送信されるパラメータセットメタデータをマルチメディアデータとは別に保存する保存手段とを備えるデータ処理装置。
30. マルチメディアデータに関係する１つ以上の記述を特定する特定手段と、
    後に復号システムに送信され、上記マルチメディアデータの復号において任意に使用される補足的拡張情報（supplemental enhancement information：ＳＥＩ）に上記マルチメディアデータに関連する１つ以上の記述を含める記述追加手段とを備えるデータ処理装置。
31. メモリと、
    上記メモリに接続され、一組の命令を実行する少なくとも１つのプロセッサとを備え、
    上記少なくとも１つのプロセッサは、上記一組の命令を実行することにより、
    マルチメディアデータの複数の部分の１つ以上のパラメータセットを定義するパラメータセットメタデータを特定し、
    マルチメディアデータを復号するために復号システムに送信されるパラメータセットメタデータをマルチメディアデータとは別に保存するデータ処理システム。
32. メモリと、
    上記メモリに接続され、一組の命令を実行する少なくとも１つのプロセッサとを備え、
    上記少なくとも１つのプロセッサは、上記一組の命令を実行することにより、
    マルチメディアデータに関係する１つ以上の記述を特定し、
    後に復号システムに送信され、上記マルチメディアデータの復号において任意に使用される補足的拡張情報（supplemental enhancement information：ＳＥＩ）に上記マルチメディアデータに関連する１つ以上の記述を含めるデータ処理システム。
33. プロセッサにより実行され、該プロセッサにデータ処理方法を実行させるコンピュータにより読取可能な媒体であって、該データ処理方法は、
    マルチメディアデータの複数の部分の１つ以上のパラメータセットを定義するパラメータセットメタデータを特定するステップと、
    マルチメディアデータを復号するために復号システムに送信されるパラメータセットメタデータをマルチメディアデータとは別に保存するステップとを有するコンピュータにより読取可能な媒体。
34. プロセッサにより実行され、該プロセッサにデータ処理方法を実行させるコンピュータにより読取可能な媒体であって、該データ処理方法は、
    マルチメディアデータに関係する１つ以上の記述を特定するステップと、
    後に復号システムに送信され、上記マルチメディアデータの復号において任意に使用される補足的拡張情報（supplemental enhancement information：ＳＥＩ）に上記マルチメディアデータに関連する１つ以上の記述を含めるステップとを有するコンピュータにより読取可能な媒体。

Images