JP5785582B2 - メディアデータ送信方法及び装置 - Google Patents

Description

（関連出願）
本出願人は、２００５年７月１９日に出願した先の同時係属仮出願第６０／７００，９０８号の優先権に対する利益を主張する。
本発明は、送信用メディアデータの時間関連シーケンスを作成する方法及び装置に関し、更に詳細には、このようなメディアデータのパケット送信に関する。

時間ベースメディアを記憶するために、ＡＩＦＦなどのオーディオフォーマット、ＡＶＩなどのビデオフォーマット、及びＲｅａｌＭｅｄｉａなどのストリーミングフォーマットなど、様々な異なるファイル構造が今日使用されている。このようなファイル構造が異なっている１つの理由は、対象及び適用性が異なるためである。これらのフォーマットの一部は、比較的十分に広く受け入れられており、用途が広く、実装が幾らか容易であり、従って、コンテンツ配信用としてだけでなく、交換フォーマットとして使用することができる。これらの汎用フォーマットの最先端のものがＱｕｉｃｋＴｉｍｅファイルフォーマットである。このフォーマットは、時間ベースデータをサービスするウェブサイトの大部分、すなわち専門的なものを含めたオーサリング環境の大部分及びマルチメディアＣＤＲＯＭタイトルの大部分で今日使用されている。

ＱｕｉｃｋＴｉｍｅメディア層は、時間ベース素材（ビデオ、オーディオ、その他）に重点を置いて汎用マルチメディアデータの効率的な表示及び管理をサポートしている。メディア層は、メディア情報の記憶及び交換フォーマットとしてＱｕｉｃｋＴｉｍｅファイルフォーマットを使用する。メディア層のアーキテクチャ能力は、一般的に、既存の実施よりも広く、ファイルフォーマットは、既存のＱｕｉｃｋＴｉｍｅ実施が現在求める情報よりも多くの情報を表すことができる。

一般的に同期メディアのローカルランダムアクセスをサポートするように設計されたＡＶＩなどのフォーマットとは対照的に、ＱｕｉｃｋＴｉｍｅは、システムが汎用マルチメディアプレゼンテーションのデータ、関連性、及びタイミングを管理することを可能にする。詳細には、ＱｕｉｃｋＴｉｍｅファイルフォーマットは、汎用時間ベースストリーミングの一時的な動作、ネットワークパケットの時間ベース放出を対象とする概念、並びにマルチメディアデータの時間ベースローカルプレゼンテーションを表現する構造を有する。

既存のＱｕｉｃｋＴｉｍｅファイルフォーマットは、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒにより１９９６年５月ファイルフォーマット仕様書において正式に記載されており、これは、ＱｕｉｃｋＴｉｍｅサイト＜ｈｔｔｐ：／／．ｗｗｗ．ａｐｐｌｅ．ｃｏｍ／ｑｕｉｃｋｔｉｍｅ＞にて見ることができる。

ＱｕｉｃｋＴｉｍｅファイルフォーマットの１つの態様は、メディアデータの物理的構造（ディスクレコードにおけるレイアウト）がファイルの論理構造から独立しており且つ該ファイル論理構造によって記述される概念である。ファイルは、「ムービー」メタデータのセットによって完全に記述される。このメタデータは、実際のメディアデータに関する宣言的、構造的、及び時間情報を提供する。

メディアデータは、記述データ（「ムービー」メタデータ）と同じファイル又は他のファイル内に存在することができる。１つのファイルに構造化されたムービーは、一般に「フラット」と呼ばれ、自己完結型のものである。非フラットムービーは、他のファイル内のメディアデータの一部又は全てを参照するように構造化することができる。

従って、フォーマットは、一般に、異なる用途における最適化に適している。例えば、編集（構成）時には、エディットが適用されてメディアが再度順序付けされるので、データを書き換える必要がなく、メタデータファイルは、拡張されて一時的なマッピング情報を調整することができる。エディットが完了すると、関連のメディアデータ及びメタデータは、ローカル又はネットワークアクセス用の単一のインターリーブされた最適化ファイルに書き換えることができる。構造的ファイル及び最適化ファイルの両方は有効なＱｕｉｃｋＴｉｍｅファイルであり、両方とも検査、再生、及び再加工を行うことができる。

構造化（「非フラット」）ファイルを使用すると、同じ基本的なメディアデータを幾つかのプレゼンテーションにおいて使用及び再使用することが可能となる。この同じ利点は、以下でわかるようにサービス提供時にも当てはまる。

編集及びサービス提供の両方においてはまた、これによって、メディアデータをコピーすることなく幾つかの他のファイルをムービーの一部として処理することもできる。従って、編集及びサービス提供は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍの「ａｕ」オーディオフォーマット又はＡＶＩビデオフォーマットのようなファイルから直接行うことができ、これらのフォーマットの有用性が大幅に拡張される。

ＱｕｉｃｋＴｉｍｅファイルは、アトムと呼ばれるオブジェクトのセットに分割される。各オブジェクトは、アトムヘッダで始まり、該アトムヘッダは、サイズ及び形式を宣言するものである。
すなわち、

サイズは、サイズ及びタイプヘッダフィールドを含めバイト単位である。タイプフィールドは、文書化及び識別を容易にすることがきるように、４文字（通常印刷可能文字）である。タイプフィールドの後のオブジェクト内のデータは、フィールド、内包オブジェクトのシーケンス、又はその両方とすることができる。
従って、ファイルは単にオブジェクトのシーケンスである。

２つの重要な最上位オブジェクトは、メディアデータ（ｍｄａｔ）及びメタデータ（ｍｏｏｖ）である。

メタデータオブジェクトは、実際のメディア（例えば、音声サンプルのシーケンス）を含む。メディアのフォーマットは、ファイルフォーマットによって制約されず、通常はオブジェクトではない。メディアのフォーマットは、メタデータで記述され、メディアと物理的に連続したいずれかの宣言部によるものではない。よって、例えば、モーションＪＰＥＧのみから成るムービーにおいては、ＪＰＥＧフレームは、仲介する余剰なヘッダなしでメディアデータ内に連続して記憶される。メディアデータオブジェクト内のメディアデータは、論理的にチャンクに分割されるが、メディアデータ内には明示的なチャンクマーカーは存在しない。

ＱｕｉｃｋＴｉｍｅファイルが他のファイル内のメディアデータを参照する場合、当該メディアデータファイルはあたかもメディアオブジェクトのコンテンツであるかのようにフォーマットすることができるので、これらの「２次」ファイルをＱｕｉｃｋＴｉｍｅ仕様書に従ってフォーマットすることは必要ではない。ＱｕｉｃｋＴｉｍｅフォームは、必ずしもヘッダ又はメディアデータと物理的に連続する他の情報は必要ではないので、メディアデータが「外部」のヘッダ（例えば、ＵＮＩＸ（登録商標）「.ａｕ」ファイル又はＡＶＩファイル）を含むファイルであり、ＱｕｉｃｋＴｉｍｅメディアデータが適切な宣言情報を含み「外部」ファイル内のメディアデータを参照することが可能である。このようにして、ＱｕｉｃｋＴｉｍｅファイルフォーマットを使用して、異種のフォーマット内の既存の素材の本体をコピーすることなく更新することができる。ＱｕｉｃｋＴｉｍｅファイルフォーマットは、確立されたフォーマットであると共に、他の確立されたフォーマットと協働し且つ該フォーマットを含み、これによって他の確立されたフォーマットを進めることができる。

自由空間（例えば、編集作業によって削除されたもの）をオブジェクトで記述することもできる。自由空間オブジェクトを含むフィールドを読み取るソフトウェアは、このような自由空間オブジェクト、並びにソフトウェアが理解できないあらゆるレベルにあるオブジェクトを無視するはずである。これによって、新しいオブジェクトを導入することによって実質的にあらゆるレベルのファイルを拡張することが可能となる。

一次メタデータは、ムービーオブジェクトである。ＱｕｉｃｋＴｉｍｅファイルは、ロケーションを容易にすることができるように通常はファイルの初め又は終わりにある１つのムービーオブジェクトを正確に有する。

ムービーヘッダは、プレゼンテーション全体に関する基本的な情報（作成日、全体的な時間スケール、その他）を提供する。内包オブジェクトのシーケンスにおいては、通常、一時的に呈示されたデータを記述する少なくとも１つのトラックがある。

トラックヘッダは、トラックに関する比較的基本的な情報（ＩＤ、時間スケール、その他）を提供する。トラック内に内包されるオブジェクトは、他のトラック（例えば、複雑な構成用）又はエディットリストに対する参照事項とすることができる。内包オブジェクトのこのシーケンスにおいては、トラック再生時に呈示されるメディアを記述するメディアオブジェクトが存在することができる。

メディアオブジェクトは、トラックによって必要とされるプレゼンテーションに関する宣言（例えば、サンプリングオーディオ、又はＭＩＤＩ又は３Ｄｓｃｎｅの方位情報）を含む。このタイプのトラックは、ハンドラによって宣言される。

メディア情報内には、同様に、データハンドラ（メディアデータをフェッチする）のハンドラ宣言、及びどのファイルが関連のトラックに関するメディアデータを含むかを定義するデータ情報宣言がある。この宣言を用いることによって、幾つかのファイルにわたるムービーを構築することができる。

最低レベルでは、トラックの時間相をファイル内に記憶されたデータに関連付けるサンプルテーブルが使用される。

サンプル記述は、メディアに関する情報（例えば、ビデオで使用される圧縮フォーマット）を含む。時間対サンプルのテーブルは、トラックの時間をその時間に表示されるべきサンプル（インデックスによって）に関連付ける。ｓｙｎｃサンプルテーブルは、これらのうちのどれがｓｙｎｃ（キー）サンプルであるか、すなわち他のサンプルに依存していないかを宣言する。

サンプル対チャンクのオブジェクトは、所与のサンプルについてのメディアデータを見つける方法及びそのインデックスが与えられる記述を宣言する。

サンプルサイズテーブルは、各サンプルのサイズを示す。チャンクオフセットテーブルは、各チャンクの初めの内包ファイルへのオフセットを示す。

上述の構造を検討して所与の時間に表示するための適切なデータを見つけることは、かなり容易なことであり、一般に、インデックス作成及び追加を伴う。ｓｙｎｃテーブルを使用すると、前のｓｙｎｃサンプルをバックアップし、「静かに」蓄積しているデルタを所望の開始地点にロールフォワードさせることも可能である。

図１は、１つのトラックを有する単純なムービーの構造を示す。同様の図は、様々なオブジェクトのフィールドの詳細な説明と共にＱｕｉｃｋＴｉｍｅファイルフォーマット文書中に見ることができる。ＱｕｉｃｋＴｉｍｅアトム（オブジェクト）が灰色ボックス内のタイプ及び上記の記述名と共にここに図示される。このムービーは、単一のビデオトラックを含む。ビデオのフレームは、データの単一のチャンク内の同じファイル内にある。
「チャンク」は、論理的構造にすぎず、すなわちオブジェクトではない点に留意されたい。チャンクの内部には、通常はネイティブフォーマットで記憶されたビデオフレームがある。ビデオフレーム内には所要のヘッダ又はフィールドは存在しない。

図２は、オーディオ及びビデオトラックの両方を有する自己完結型ファイルの図である。簡潔にするために、ここでは少数のアトムが図示されており、トラックからメディアデータへのポインタは、勿論、タイミング情報を含む一般的なサンプルテーブル宣言である。

ＱｕｉｃｋＴｉｍｅファイルフォーマットは、以下を含む幾つかの利点を有する。
１）サイズ及びビットレートのスケーラビリティ。メタデータは柔軟性があり、しかもコンパクトである。これによって、小さなダウンロードムービー（例えば、インターネット上で）並びに幾つかのハイエンド編集システムのベースを提供するのに好適になる。
２）物理的構造は、論理的及び時間的構造から独立したものである。これによって、ファイルを有する用途に応じて、物理的構造を異なる方法で最適化することが可能になる。詳細には、単一のファイルフォーマットは、オーサリング及び編集；ＣＤ−ＲＯＭ上でのダウンロード又は設定；及びストリーミング用に好適であることを意味する。
３）ファイルフォーマットは、フォーマットが設計された時点では知られていない多くの形式を含め、極めて多様なコーデックタイプ及びトラックタイプを扱えることが証明されている。上位互換性のある様態で発展するこの証明済みの能力は、ストレージフォーマットの成功にとって重要なことである。

スケーラブルな又は階層化されたコーデックは、ＱｕｉｃｋＴｉｍｅファイルフォーマットで幾つかの方法で扱うことができる。スケーラビリティをサポートするストリーミングプロトコルの場合、サンプルには、そのサンプルを送信する上で満たすべき層又は帯域幅閾値をタグ付けすることができる。

代替形態のセットを形成するトラック（例えば、異なる自然言語音声トラック）は、再生用に１つのトラックのみが選択されるようにタグ付けすることができる。同じ構造を使用してストリーミング用の代替形態（例えば、言語選択用に）を選択することができる。この能力については、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいて更に詳細に説明されている。

ＱｕｉｃｋＴｉｍｅがムービー又はトラックを表示する場合、適切なメディアハンドラが特定の時間のメディアデータにアクセスする。メディアハンドラは、データストリーミングを正確に解釈して要求されたデータを取り出さなければならない。例えば、ビデオメディアに関しては、メディアハンドラは通常、幾つかのアトムを横断して所与のメディア時間用のサンプルのロケーション及びサイズを見つける。メディアハンドラは、以下のことを行なうことができる。
１．メディア時間座標系を決定する。
２．時間対サンプルアトムを調べて、所定時間のデータを含むサンプル番号を決定する。
３．サンプル対チャンクアトムをスキャンして、どのチャンクが問題のサンプルを含むかを発見する。
４．チャンクオフセットアトムからチャンクへのオフセットを抽出する。
５．サンプルサイズアトムを使用してチャンク内のオフセット及びサンプルのサイズを見つける。

ＱｕｉｃｋＴｉｍｅファイル又は他のタイプのメディアデータの時間関連シーケンスは、コンピュータネットワーク（例えば、インターネット）と関連付けることができるデータ通信媒体を介して送信されるのが望ましいことが多い。多くのコンピュータネットワークにおいては、ネットワーク内に送信されるデータは、一般に、パケット形式であるはずである。通常、メディアデータの時間関連シーケンスは、ネットワーク上での送信用に適切なパケット化フォーマットではない。例えば、ＱｕｉｃｋＴｉｍｅフォーマットでのメディアデータファイルは、パケット化フォーマットではない。従って、ストリーミングデータと呼ばれることもあるデータを収集してネットワーク上で送信するためにパケット化する必要がある。

ネットワークを介してメディアデータの時間関連シーケンスを送信することに関する問題に対処する従来技術の１つの方法は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）などのネットワーク又は送信プロトコルを使用して、ネットワーク経由でメディアファイルを送ることである。従って、メディアファイル自体は、１つのコンピュータシステムからネットワーク経由で別のコンピュータシステムに送られる。しかしながら、受信側コンピュータシステムでメディアファイルを保持する要求がない場合がある。すなわち、例えば、受信側コンピュータシステムが記憶容量の少ないネットワークコンピュータ又はコンピュータである場合、メディアファイルが受信側コンピュータシステムで受信、閲覧、又は聴取されるときには、その受信側コンピュータシステムのユーザによるファイルのコピーを記憶したいという要求がない可能性がある。

ネットワークを介したパケットによる送信用にデータを収集する方法に関する問題を解決する別の代替手法は、特定の送信プロトコル用ファイルにおいてネットワークプロトコルデータユニットを含むファイルを作成することである。ある意味では、このようなファイルは、特定の送信プロトコルに従って送信されるのと本質的に同じフォーマットで記憶されたパケット化ファイルと考えることができる。この作業の実施には通常、特定のデータ送信レート及び特定のメディアファイルフォーマットでの特定のネットワークプロトコル用にパケット化フォーマットのファイルを記憶することを伴う。従って、特定のデータ送信レートでの各異なる送信プロトコルについて、ファイルは本質的にパケット形式で複製されることになる。このようなファイルの固定形式は、ファイルの適用性／互換性を制限し、このようなファイルをローカルで閲覧することを困難にする可能性がある。従って、このような手法では、様々な送信プロトコルでの様々な異なるデータ送信レートでファイルを供給しようとする際に必要な記憶容量が大幅に増大する可能性がある。更に、この代替の従来的手法に従って生成された各パケットファイルは、一般的に特定のメディアファイルフォーマットに限定され、従って、同じメディアオブジェクト（例えばデジタルムービー）用の他のメディアファイルフォーマットは通常、パケット化されて送信側コンピュータシステム上に記憶される。

メディアデータの時間関連シーケンスをストリーミングする方法に関する問題を解決する更に別の手法は、要求された特定の送信プロトコルに従って送信側システム上で必要とされるときにメディアデータのパケット化を実施するものである。多くの場合、この処理には比較的かなりの時間量を必要とし、その結果、送信側システムの性能を低下させる可能性がある。

従って、メディアデータの時間関連シーケンスを送信するための改良された方法及び装置を提供することが望ましい。

本発明は、スケーラブルなコンテンツの複数のスケールでプレゼンテーションを提示するためのサンプルを含むデータの第１のセット内に記憶された読取り可能コンテンツを処理する方法及び装置を提供する。１つの実施形態において、第１のストリームは記憶され、第２のストリームは、第１のストリームから導出され、第２のストリームは、スケーラブルなコンテンツ内の動作点に対して、第１のストリームからデータを選択する際に使用される第１のストリームへの参照を含む。本発明の１つの態様によれば、記憶された第２のストリームに含まれる参照にアクセスされて、第１のストリームからデータを送信又は記憶する。多数の他の方法及び装置についても記載される。

従来技術における１つのトラックを備えた単純なムービーの構造の実施例の図である。 従来技術の自己完結型ムービーファイルの実施例の図である。 本発明による方法の１つの実施例を示すフローチャートである。 本発明のヒントトラックの実施例の図である。 本発明のヒントトラックの別の実施例の図である。 本発明の１つの実施形態による、媒体データを交換又は処理することができるコンピュータシステムのネットワークの図である。 本発明の１つの実施形態に従って使用することができるデジタル処理システムのブロック図である。 本発明の１つの実施形態による、ヒントを利用してメディアデータを転送するシステムのブロック図である。 発明の１つの実施形態による、ヒントを利用してメディアデータを転送するシステムのブロック図である。 本発明の１つの実施形態による、メディアデータ送信を可能にするヒントを生成するための方法を示すフロー図である。 本発明の１つの実施形態による、ヒントに従って受信側システムにより受信されたメディアデータを処理する方法を示すフロー図である。 本発明の１つの実施形態による、ジェネレータなどのデジタル処理システムがアクセス可能な機械可読記憶媒体の実施例の図である。 本発明の１つの実施形態による、サーバなどのデジタル処理システムがアクセス可能な機械可読記憶媒体の実施例の図である。 本発明の１つの実施形態による、受信側システムなどのデジタル処理システム又は他のデジタル処理システムがアクセス可能な機械可読記憶媒体の実施例の図である。 本発明の１つの実施形態による、メディア及びヒント情報が記憶／転送されたデータ記憶媒体及び／又は通信媒体の図である。 ＳＶＣコード化ビデオベーストラックの１つの実施形態の図である。 可変ビデオ解像度の１つの実施形態を示すブロック図である。 アグリゲータネットワーク抽象化層ユニットを利用するＳＶＣコード化ビデオベーストラックの１つの実施形態を示す図である。 ビデオストリームをＳＶＣコード化ベーストラックから抽出するのに使用されるエクストラクタ・トラックの１つの実施形態を示すブロック図である。 アグリゲータネットワーク抽象化層ユニットを含むＳＶＣコード化ベーストラックからビデオストリームを抽出するのに使用されるエクストラクタ・トラックの１つの実施形態を示すブロック図である。 エクストラクタ・トラックを組み込んだビデオファイルの１つの実施形態を示すブロック図である。 エクストラクタ・トラックを生成してＳＶＣベーストラックと共に使用するシステムの１つの実施形態を示すブロック図である。 ＳＶＣベーストラックからＳＶＣエクストラクタ・トラックを生成する方法２０００の１つの実施形態のフローチャートである。 対応するエクストラクタ・トラックを使用してＳＶＣベーストラックからビデオストリームを取り出す方法２１００の１つの実施形態のフローチャートである。 リモートクライアント向けに送信サーバによってＳＶＣベースからメディアストリームを取り出す方法２２００の１つの実施形態のフローチャートである。 リモートクライアントがエクストラクタ・トラックを使用してメディアストリームを要求する場合における、リモートクライアント向けに送信サーバによってＳＶＣベーストラックからメディアストリームを取り出す方法２３００の１つの実施形態のフローチャートである。 ＳＶＣベーストラックから抽出されたＳＶＣ専用コンテンツを保存する方法２４００の１つの実施形態のフローチャートである。

本発明は、コンピュータネットワークなどにおいて、通信媒体を介して、例えば、ビデオ、オーディオ、ビデオ及びオーディオ、その他を含むことができるメディアデータの時間関連シーケンスの送信、特にパケット送信を可能にする方法及び装置を提供する。

本発明の１つの実施形態において、デジタル処理システムは、送信プロトコルに従ってメディアデータの時間関連シーケンスを送信する方法を示すデータセットを作成する。通常、このデータセットは、デジタル処理システムに結合された記憶装置上に記憶される。更に、このデータセットは、メディアデータの時間関連シーケンスに関連付けられたデータの時間関連シーケンスである。

本発明は、コンピュータ可読媒体上に記憶された実行可能なコンピュータプログラム命令で全体的に実施することができ、又は、ソフトウェア及びハードウェアの組み合わせで、或いは特定の実施形態においては完全にハードウェア内で実施することができる。通常、ネットワークに結合されたサーバコンピュータシステムは、ヒントトラックと呼ぶことができるデータセットを作成し、このヒントトラックをサーバコンピュータシステムに結合される記憶装置内に記憶することになる。クライアントコンピュータシステムがメディアデータファイルのプレゼンテーション（例えば、閲覧又は聴取或いは閲覧及び聴取）を要求すると、サーバシステムは、ヒントトラックを使用して、クライアントコンピュータシステムへの送信用にメディアデータをパケット化する方法を決定する。本発明は、一般的にメディアデータの時間関連シーケンスに適用可能であり、ＱｕｉｃｋＴｉｍｅは、本明細書ではこの一般的な適用性の１つの実施例として示されている点は理解されるであろう。従って、本発明は、必ずしもＱｕｉｃｋＴｉｍｅに限定される必要はない。

図３は、本発明による方法の１つの実施例を示す。図３に示す方法３００は、段階３０１で始まり、ここでは送信されるべき特定のメディアデータのメディアファイルフォーマットが判断される。段階３０３において、使用されるべき１つ又は複数の特定の送信プロトコルも決定される。しかしながら、段階３０１及び３０３は、例えば、同じメディアファイルフォーマットが常に同じ送信プロトコルを使用して送信される場合には任意選択可能である。

段階３０５において、サーバコンピュータシステムなどのデジタル処理システムは、メディアファイルにおいてメディアデータの時間関連シーケンスをパケット化するためのヒントを作成し記憶する。或いは、１つのコンピュータシステムは、ヒントを作成し、サーバコンピュータシステムなど別のシステムに供給することができ、該サーバコンピュータシステムは、送信プロセスにおいてヒントを後で使用するために記憶する。パケット化によって、段階３０３で決定された所要の送信プロトコルに従ったネットワーク又は通信媒体を介した送信が可能になる。本発明の１つの実施形態において、ヒントは、メディアデータの他のトラックを参照するが、１つの実施形態においてはメディアデータの他のトラックとは別個のものであるヒントの時間関連シーケンスのトラックとして記憶される。ヒントのトラックは、本発明の１つの実施形態において、ヒットが参照するメディアデータとは別個に記憶することができる。従って、ヒントのトラックは、該ヒントのトラックが参照するメディアデータを含む別のファイルとは異なるファイル内に記憶することができ、又は、ヒントのトラックは、実際のメディアデータを含むデータ区域とは分離され且つ異なるメディアデータを含むファイル内のヒント区域に記憶することができる。本発明の１つの実施形態において、ヒントトラック又はその一部は、サーバによる実行可能命令と解釈することができ、この実行可能命令により、サーバは、一般的には時間ベースメディアデータであるが必ずしもそうとは限らないデータの時間関連シーケンスをパケット化する。本発明の１つの実施形態において、ヒントは、送信側デジタル処理システムに結合された記憶装置上に記憶される。

段階３０７においては、ヒントに従ってパケット化されるデータがサーバコンピュータシステムなどの送信システムから受信側システムに送信される。このメディアデータは、ヒントに従ってメディアデータにパケット化することによって送信される。本発明の１つの代替の実施形態において、サーバコンピュータシステムは、ヒントの使用、及び代替パケット化プロセスによるメディアデータの送信を行わないことを決定することができる。

段階３０９において、受信側システムは、メディアデータによって表されるメディアオブジェクトを提示する。通常、このプレゼンテーション（メディアオブジェクトの閲覧及び聴取、或いはメディアオブジェクトの単なる閲覧又は単なる聴取とすることができる）は、パケットデータが受信側システムで受け取られるときに実施される。パケットデータは、本発明の１つの実施形態において、必須ではないが、受信側システム上に記憶することができる。従って、データのプレゼンテーションは、プレゼンテーションが終わると受信側システムにはローカルコピーは存在しないという意味で一時性のものである。別の実施形態において、メディアオブジェクトのプレゼンテーションは、メディアオブジェクトを表すメディアデータのヒントを作成した後にサーバシステム上で行なうことができる。本発明の１つの実施形態において、メディアデータは、ヒントに従うパケットに対して必ずしもフォーマット、コピー、その他が行われるとは限らない。

段階３１１において、受信側システムは、任意選択的に、受信されたメディアファイルが既に受信側システム上に記憶されている場合には、メディアファイルを再アセンブルすることができる。図３に示す方法の様々な段階は、図示され上述された順番とは異なる順番で行うことができ、及び／又は段階の一部を同時に実行することができる点は理解されるであろう。例えば、１つの実施形態において、段階３０９及び３１１は並行して実行される。

次に、本発明の１つの実施形態によるＱｕｉｃｋＴｉｍｅでの特定の実施を説明する。本発明の１つの実施形態において、ファイルにローカル（例えばサーバ、ジェネレータ、その他）で閲覧し且つＱｕｉｃｋＴｉｍｅムービー内のネットワークを介してストリーミングすることができるプレゼンテーションが提供される。一般に、ストリーミングサーバ（又は別のシステム）は、ストリーミングするデータユニット、これらの構成、及びタイミングに関する情報を有するはずである。このような情報は通常時間情報であるので、トラックにおいて説明することができる。サーバは、例えばプレゼンテーションを閲覧するのに使用されるのと同じインデックス作成操作を利用することによって、パケット化を実施してプロトコル情報を決定することができる。

サーバ用の命令を含むトラックは、パケットの形成及び送信のプロセスにおいてサーバに指示するデータセットを表すので、該トラックは、「ヒント」トラックと呼ばれる場合がある。ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ネットワーク上でのメディアデータのストリーミング並びにローカル再生をサポートする。プロトコルデータユニットの送信プロセスは時間ベースであり、従って、時間ベースデータの表示と同様に時間ベースフォーマットにより適切に記述される。ストリーミングをサポートするＱｕｉｃｋＴｉｍｅファイル又は「ムービー」は、ストリーミングするデータユニットに関する情報を含む。この情報は、「ヒント」トラックと呼ばれるファイルの更なるトラック内に含まれる。

ヒントトラックは、パケット形成を支援するストリーミングサーバ（又は他のデータ処理システム）向けの命令を含む。これらの命令は、サーバが送る即時データ（例えば、ヘッダ情報）又はメディアデータの参照セグメントを含むことができる。本発明の１つの実施形態において、命令は、編集又はプレゼンテーション情報がローカル再生用ＱｕｉｃｋＴｉｍｅファイルで符号化される同じ方法でＱｕｉｃｋＴｉｍｅファイルにおいて符号化される。編集又はプレゼンテーション情報の代わりに、サーバが特定のネットワーク転送を使用してストリーミングに適切な方法でメディアデータをパケット化することができる情報を提供することができる。

本発明の１つの実施形態において、同じメディアデータは、ローカル再生用か又は幾つかの異なる転送タイプを介したストリーミング用であるかを問わず、ヒントを含むＱｕｉｃｋＴｉｍｅファイルにおいて使用される。異なる転送タイプ向けの別個の「ヒント」トラックは、同じファイル内に含むことができ、メディアは、メディア自体の何らかの追加のコピーを行うことなく、全てこうした転送タイプで再生することができる。更に、既存のメディアは、特定の転送用の適切なヒットトラックを追加することによってストリーミング可能にすることができる。本発明の１つの態様によれば、メディアデータ自体は、改変又は再フォーマットする必要はない。

従って、ヒントトラック内のサンプルは、一般に、パケットを形成する命令を含む。これらの命令は、サーバが送信する即時データ（例えば、ヘッダ情報）又は別のトラック内のメディアデータの参照セグメントを含むことができる。

本発明の１つの実施形態において、３つのレベルのデザインが以下であるように利用される。
１）メディアデータは、通常通り再生、編集、その他を行うことができるネットワークから独立したトラックのセットとして表される。
２）サーバヒットトラック用の共通の宣言及びベース構造がある。この共通フォーマットは、プロトコルに依存しないものであるが、どのプロトコルがサーバトラック内で記述されているかについての宣言部を含む。
３）送信することができる各プロトコルついてのサーバヒントトラックの特定のデザインがあり、全てのこれらのデザインは同じ基本構造を用いる。例えば、ＲＴＰ（インターネット用）及びＭＰＥＧ−２転送（ブロードキャスト用）、又は新しい標準プロトコル又はベンダー専用プロトコルについてのデザインが存在することができる。

本発明の１つの実施形態において、ヒントトラックの指示に基づいてサーバによって送られる結果として得られたストリームは通常のストリームであり、必ずしもＱｕｉｃｋＴｉｍｅ情報のトレースを含むとは限らない。本発明のこの実施形態では、ＱｕｉｃｋＴｉｍｅ又はその構造又は宣言スタイルは必ずしも送信媒体上のデータ（例えば、ネットワークケーブル）内又は復号局内にある必要はない。例えば、ＲＴＰに基づいてストリーミングされるＨ．２６１ビデオ及びＤＶＩオーディオを用いたファイルでは、本発明の１つの実施形態において、当該コーディングをＲＴＰにパックするＩＥＴＦ仕様に完全に準拠したパケットストリームを得ることができる。

本発明の１つの実施形態において、ヒントトラックは、プレゼンテーションがローカルで閲覧されるときにヒントトラックが本質的に受信側システムによって無視されるように、構築及びフラグが立てられる。

１つの実施形態において、例えばビデオ、オーディオ、その他を含むことができるメディアデータの時間関連シーケンスは、デジタル処理システムによりパケット化され、次いで、同じデジタル処理システム上に提示することができる。更に、パケット化は、一時性のものとすることができ、その結果、提示、記憶、読み取り、その他がなされる時間関連シーケンスはまた、「オンザフライ」でパケット化される。１つの実施形態において、ヒントは、コピー、フォーマット、その他が行われていないメディアデータを参照することができ、例えば、ヒットが参照するメディアデータは、読み出し専用メモリ上などに元のフォーマットで記憶することができる。

１つの実施形態において、パケット化を行う同じヒンティングルーチンはまた、パケット化が行われるときにメディアを提示する。本発明の代替の実施形態において、時間関連メディアデータのパケットファイルをヒントトラックに従って生成し、例えば後で送信するために記憶することができる。

図４は、本発明の１つの実施形態によるメディアデータを転送するためのヒントトラックの利用を示している。図４において、メディアトラック用のヒントトラック４０１が示されている。ＲＴＰパケットを形成する方法を記述するヒントトラックサンプル４０５などの各ヒントトラックサンプルはヘッダを含むことができ、関連のメディアトラック（この場合はビデオトラック４０３）からの一部のデータを参照することができる。図４に示す実施形態において、メディアデータ（ビデオフレーム）及びＲＴＰヒントは、関連のメディアファイルを比較的容易に読み取ることができるようにインターリーブされている。この実施例において、各フレームは、単一のＲＴＰパケットに適合するように示されている。言うまでもなく、必要に応じてフレームを幾つかのパケットに分割することが可能である。逆に、所望があれば、複数のフレームを単一のパケットに入れることができ、これはオーディオデータに対して一般的に行われている。

上で検討したように、上述の論理構造は、物理的構造を意味する必要はない。メタデータはメモリにキャッシュすることができ、ヒントトラックサンプルは、ヒントトラックサンプルが参照するメディアサンプルと物理的にインターリーブされる（図４に示すように）。

或いは、ヒントトラックを含むメタデータ及びメディアデータの新規のセットを書き込むことが可能であり、該セットは、既存のプレゼンテーションにおいてメタデータ及びメディアデータを参照し増補する。図５は、本発明の１つの実施形態による、別個のファイルのメディアデータを参照するためのヒントトラックの利用を示している。図５において、２つのムービーファイル５０２及び５０４が示され、各々が固有のメタデータを備える。第１のムービーファイル５０２はビデオトラックを含む。第２のムービーファイル５０４は、ビデオトラック及びヒントトラックの両方を含むが、メタデータは、ビデオトラックのメディアデータがムービーファイル５０２内にあると宣言している。従って、ムービーファイル５０４に関連するヒントはまた、ムービーファイル５０２のメディアデータを指す。

本発明の１つの実施形態において、メディアファイルは、複数のプロトコル用のパケット化ヒントトラックを含むことができる。従って、各トラックは、ヒントトラックが適切となるプロトコル（及び適切な場合にプロトコルパラメータ）の宣言部を含むことができる。勿論、これらのトラックは全て、ファイル内のベースメディアトラックからのメディアデータを参照することができる。プロトコルの非依存性及び拡張性に対する要望は、説明された方法で満たすことができる。

本発明の１つの実施形態において、ヒントトラックは、メディアトラック内の全てのデータを使用する必要はない。ヒントトラックは、帯域幅閾値を達成するため、或いは他の理由のためデータのサブセット（例えば、一部のビデオフレームを省略することによって）を使用することができる。同じプロトコル用に複数のヒントトラックを提供することができるので、同じベースメディア情報の異なるサブセットを異なるレートで提供することができる。従って、本発明は、従来の方法及び装置よりも優れたスケーラビリティを提供することができる。

ヒントトラック自体及びＱｕｉｃｋＴｉｍｅメタデータは、１つの実施形態においてＱｕｉｃｋＴｉｍｅファイル内にあるはずであるが、ベースメディアは、ＱｕｉｃｋＴｉｍｅがインポートし所定位置で参照することができるあらゆるファイルタイプに残すことができる点を強調すべきである。本発明の１つの実施形態において、ムービーファイル内のメタデータは、メディアデータが別のファイル内にあることを宣言するデータ参照を含むことができる。従って、サンプルテーブルオフセット及びポインタは、この「外部」ファイル内のデータを参照することができる。このように、本発明の１つの実施形態によれば、「ａｕ」オーディオファイル、「ＡＶＩ」オーディオ／ビデオファイル、及びＭＩＤＩファイルなどの既存のレガシーフォーマットは、ベースメディアデータのコピー及び再フォーマットを必要とすることなくストリーミングすることができる。ベースメディアデータは、別個のファイル内のＱｕｉｃｋＴｉｍｅ宣言部及びヒント情報に書き込まれずに、単にこれらによって増補されるだけであるので、ベースメディアデータは、ＣＤ−ＲＯＭなどの読み取り専用機械可読媒体上に備えることができる。

本発明の１つの実施形態において、ヒントトラックは、オフライン計算結果を具現化し、通常は、パケット化、及び必要に応じて多重化をサポートする情報をサーバに供給するように最適化される。

例として、ＲＴＰ（ＩＥＴＦ標準規格リアルタイムプロトコル）及びＭＰＥＧ−２転送用の例示的なヒントを付属書Ａ〜Ｃに示している。

本発明の１つの実施形態において、単一のファイルは、必要以上のスペースオーバーヘッドを有することなく、複数のプロトコル又は同じプロトコルの複数の異なるパラメータ化のヒントトラックをサポートすることができる。新しいプロトコル及び関連するヒントトラックは、既存のプロトコルに依存するシステムを混乱させることなく設計することができる。従って、本発明は、少なくとも１つの実施形態においてはプロトコル中立である。

ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいて、トラックは、メタデータを更新、コピー、及び増補することによってムービーに追加することができる。メディアデータがメタデータとは別個のファイル内にあるか、又は最適化されたインターリーブが不要である場合、これは、比較的簡単且つ効率的な操作となる可能性がある。

本発明の１つの実施形態において、トラックは、１つのトラックのみを含み、所望であればオリジナルでメディアデータを参照することができるムービーメタデータの新しいセットを構築することによって抽出することができる。

例えば、本発明の１つの実施形態において、他のオーディオトラックのセットに対する代替としてマークされる新しいオーディオトラックを追加することができる。新しいオーディオトラックが言語コード（例えば、フランス語又はタガログ語）でマークされている場合、プレゼンテーション時間に適切なトラックを選択することができる。

ＳＭＰＴＥタイムコードトラックは、本発明の１つの実施形態による、必要が生じたときに提示、追加、又は除去することができるエレメンタリ・ストリームの実施例である。

本発明の１つの態様によれば、ヒントトラックは、既存のサーバ又はローカルでの再生において互換性の問題を引き起こすことなく、新しいプロトコルのための新しいフォーマットの開発を可能にすることができる。更に、新しいメディアトラックは、後方互換性を維持しながらファイルフォーマットの有効期間にわたって追加することができる。

本発明の１つの実施形態において、拡張性の領域は、以下を含む。
ａ）現在のＱｕｉｃｋＴｉｍｅファイルフォーマットによりカバーされないメディアタイプ（例えば、実験室機器読取り）について定義することができる新しいトラックタイプ。
ｂ）定義することができる既存のトラックについての新しいコーディングタイプ（例えば、ビデオ又はオーディオコーデック）。これらのコーデック専用初期化情報についての明示的な規定がある。
ｃ）新しいプロトコルについて定義することができる新しいヒントトラックタイプ、及びメディアデータ自体についてスペースオーバーヘッドを発生することなく２つ以上のプロトコルに関するヒント情報を含むことができるファイル。

読み取り専用媒体上の既存のコンテンツ（例えば、ＣＤ−ＲＯＭ、ＤＶＤ、その他上の予めパッケージされたムービー）は、本発明と共に使用することができる。

更に、本発明の１つの態様によれば、様々な「外部」ファイルフォーマットを使用することができる。本発明の１つの実施形態において、例えば、既存のコンテンツがＱｕｉｃｋＴｉｍｅフォーマットであるか、又はインポートすることができる場合には、コピー又は再フォーマットを必要とせずに、編集及びストリーミングすることができる。

本発明の１つの実施形態において、帯域幅のスケーラビリティを達成するためにコーデックがメディアデータのストラピングをサポートする場合、これらのストラピングされた帯域幅は、複数のストリームトラックを使用して表すことができる。各トラックは異なる帯域幅を表すことができる。トラックは、ベースメディアの選択されたサブセット内で共にグループ化することができる。

本発明の１つの実施形態において、プロトコルが帯域幅のスケーラビリティをサポートする場合、ヒントトラック自体は、各プロトコルデータユニット（ヒントトラック内のサンプル）についての情報を含むことができる。情報は、プロトコルデータユニットをネットワークに配信する必要のある帯域幅閾値を含むことができる。従って、ヒントトラックは、有効帯域幅を高、低、その他として示し、及び／又はデータ送信用の帯域幅に関係する他の情報を表示することができる。

本発明の１つの実施形態において、プロトコルが多重化プロトコル（例えば、ＭＰＥＧ−２転送）である場合、異なるデータ転送速度を達成するためにエレメンタリ・ストリームトラックの異なるサブセットを使用する異なるヒントトラックを構築することができる。従って、ビットレートの低い送信では一部のトラックを完全に省く場合がある。

本発明の１つの実施形態において、異なるコーデックを使用してベースデータを記録することが望ましい場合には、当該トラックを代替形態のグループに形成して、１つだけをプレゼンテーション用に選択することができる。プレゼンテーション用にどのトラックを使用するかに関する選択は、通常はプロトコルに依存し、本明細書で説明するヒントトラック手法を用いて達成することができる。

本発明の１つの実施形態において、暗号化をメディアファイルに予め適用することもできる。この場合、暗号化データは、（ａ）元のメディアデータにリンクされた新しいエレメンタリ・ストリーム（新しいトラック）（すなわち、不要となった場合には元のメディアデータを除去することができる）、又は（ｂ）ヒントトラック自体に記憶することができる。ケース（ｂ）において、ヒントトラックは、オンザフライで暗号化されていないエレメンタリ・ストリームからデータを抽出しないことも可能である。従って、メディアデータは暗号化によって変形される可能性があるので、メディアデータの全ては、ヒントトラック並びにストリーミングパケットプロトコルデータユニット情報内にあるものとすることができる。

埋め込みオブジェクトコンテンツ情報の実施例として、ムービー全体及び個々のトラックについてのＩＥＴＦセッション記述情報をＲＴＰヒントトラック用メタデータ内にユーザアトムとして記憶することができる。

本発明の１つの実施形態において、ファイルフォーマットは通常、再生可能フォーマットのメディアデータとストリーミング情報との両方を含む。１つの実施形態において、メディア非依存、プロトコル非依存、及びメディアをローカルに提示する能力を保持しながら、比較的低いオーバーヘッドでこのフォーマットから直接ストリーミングすることができる。

本発明の１つの態様によれば、ヒントトラックは、コーデック、タイミング及びパケット化の詳細な知識をオフライン作成プロセスに抽象化することができる。従って、ヒントトラックを辿りデータストリームを生成することは、比較的簡単であり、ストリーミングされているメディアの特殊な知識は不要とすることができる。従って、本発明の１つの態様によれば、例えばデータコンテンツの詳細からサーバを切り離すことができる。

本発明の１つの実施形態において、ヒントトラックのセットを使用して、例えば、ネットワークＰＤＵが送信すべき時系列において、ディスク上で論理ディスク境界にネットワークＰＤＵをレイアウトすることによってストリーミング用に直接最適化されるファイルを構築することができる。このようなファイルは、もはや一般的なプレゼンテーションとなることはできないが、ストリーミングすることはできる。１つの実施形態において、ヒントトラックを用いて作成されたパケット化ファイルを記憶し、例えば、ストリーミング用に後で最適化することができる。

本発明の１つの実施形態において、外部ファイルフォーマットをカプセル化することによって、メディアデータを他のフォーマットで保存しながら、それでもＱｕｉｃｋＴｉｍｅで公開することができる。例えば、既存のフォーマットは、適切なラッパを適用することによって新しいメディアデータファイル内に直接カプセル化することができ、或いは、そのまま残して、ヒントトラックによってセグメントで又は全体として参照し、レガシー形式をコピーせずにストリーミング可能にすることができる。単一のムービーは、複数のレガシーフォーマットから選択された要素を含むことができる。本発明は、ベースメディアフォーマットを制約しない。

一般に、取り込み、オーサリング及び編集、ダウンロード並びにストリーミングに及ぶ共通のフォーマットは、一般的にフレキシビリティを提供する。素材は、コピー又は再フォーマットせずに、使用後に再加工するか、又は複数の方法で使用することができる。本発明の１つの実施形態において、標準的なエディタを使用してヒントトラックを除去し、次いで編集が完了した後に再度ヒンティングすることによって、ヒントされた素材を再加工及び再使用することができる。

ローカルで閲覧するためにメディアファイルをダウンロードすることが望ましい場合、その目的のために最適化されたインターリーブファイルを構築することができ、別個の宣言ファイル内のストリーミングメタデーは、同じベースメディアデータを参照する。従って、このダウンロードは、ストリーミング情報を含まない場合があり、更に、メディアデータは、ストリーミングサーバに一度しか存在することができない。

論理構造を物理的構造から分離することによって、ファイルの物理的構造をアプリケーション（例えば、編集、ローカル閲覧、ストリーミング）に応じて異なるように最適化することができる。

各メディアトラックについて複数のヒントトラックの存在を許容することによって、本発明の１つの実施形態において、ファイルは、メディアの複数のコピーを必要とせずに複数のプロトコルを介してストリーミングすることによって公開することができる。

図６は、本発明の１つの実施形態による、メディアデータを処理することができるコンピュータシステムのネットワークを示す図である。図６に示すように、幾つかのクライアントコンピュータシステムは、インターネット６２２を介して互いに結合されており、その１つ又はそれ以上は、図３を参照しながら上述された受信側システムの１つの実施を表す。用語「インターネット」とは、複数のネットワークのうちのあるネットワークを指すことは理解されるであろう。このようなネットワークでは、情報交換にＴＣＰ／ＩＰ、ＡＴＭ、ＳＮＡ、ＳＤＩ、その他のような様々なプロトコルを使用することができる。インターネットの物理的接続並びにインターネットのプロトコル及び通信手順は当業者には周知である。インターネット１０３へのアクセスは通常、ＩＳＰ６２４及びＩＳＰ６２６などのインターネットサービスプロバイダ（ＩＳＰ）によって提供される。クライアントコンピュータシステム６０２、６０４、６１８、６２０などのクライアントシステム上のユーザは、一般に、ＩＳＰ６２４及び６２６などのインターネットサービスプロバイダを介してインターネットにアクセスする。インターネットへのアクセスは、クライアントコンピュータシステム６０２、６０４、６１８、６２０、及び／又はウェブサーバシステム６２８などの２つ又はそれ以上のデジタル処理システム間での情報の転送（例えば、電子メール、テキストファイル、メディアファイル、その他）を容易にすることができる。例えば、クライアントコンピュータシステム６０２、６０４、６１８、６２０、及び／又はウェブサーバ６２８のうちの１つ又はそれ以上は、クライアントコンピュータシステム６０２、６０４、６１８、６２０、及び／又はウェブサーバ６２８のうちの別の１つ又はそれ以上にメディアデータ（例えば、ビデオ及びオーディオ、又はビデオもしくはオーディオ）を提供することができる。これは要求に応答して行うことができる。本明細書で説明するように、このようなメディアデータは、システム６００内でヒントに従って転送することができる。このようなヒントは、本発明の１つの実施形態において、メディアデータの特定のフォーマット及び／又は特定のデータ通信（例えば、ネットワーク）プロトコルに従って作成することができる。

ウェブサーバ６２８は通常、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂのプロトコルのような１つ又はそれ以上のデータ通信プロトコルで動作する少なくとも１つのコンピュータシステムから構成され、従って、通常はインターネット６２２に結合される。任意選択的に、ウェブサーバ６２８は、クライアントコンピュータシステムにインターネット及び／又は他のネットワークへのアクセスを提供することができるＩＳＰの一部とすることができる。クライアントコンピュータシステム６０２、６０４、６１８及び６２０は各々、適切なウェブブラウジングソフトウェアによりＨＴＭＬ文書（例えば、ウェブページ）など、ウェブサーバ６２８が提供することができるデータにアクセスすることができる。このようなデータは、ＱｕｉｃｋＴｉｍｅムービーなど、クライアントコンピュータシステム６０２、６０４、６１８及び６２０が提示することができるメディアを提供することができる。

ＩＳＰ６２４は、クライアントコンピュータシステム６０２の一部とみなすことができるモデムインタフェース６０６を介して、クライアントコンピュータシステム６０２とのインターネット接続性を提供する。クライアントコンピュータシステムは、Ｍａｃｉｎｔｏｓｈコンピュータ、「ネットワーク」コンピュータ、ハンドヘルド／携帯型コンピュータ、ウェブＴＶシステム、又は他のタイプのデジタル処理システム（例えば、デジタル処理能力を有する携帯電話）など、従来のコンピュータシステムとすることができる。同様に、ＩＳＰ６２６は、クライアントコンピュータシステム６０２、６０４、６１８及び６２０についてインターネット接続性を提供するが、図６に示すように、このような接続性は、クライアントコンピュータシステム６０２、６０４、６１８及び６２０など、様々なクライアントコンピュータシステム間で変わる可能性がある。例えば、図６に示すように、クライアントコンピュータシステム６０４は、モデムインタフェース６０８を介してＩＳＰ６２６に結合されており、一方、クライアントコンピュータシステム６１８及び６２０は、ローカルエリアネットワーク（ＬＡＮ）の一部である。図６で、それぞれモデム６０６及び６０８として示すインタフェース６０６及び６０８は、アナログモデム、ＩＳＤＮモデム、ケーブルモデム、衛星伝送インタフェース（例えば、「Ｄｉｒｅｃｔ ＰＣ」）、無線インタフェース、又はクライアントコンピュータシステムのようなデジタル処理システムを別のデジタル処理システムに結合する他のインタフェースとすることができる。クライアントコンピュータシステム６１８及び６２０は、それぞれネットワークインタフェース６１４及び１６１を介してＬＡＮバス６１２に結合されている。ネットワークインタフェース６１４及び６１６は、イーサネット（登録商標）タイプ、非同期転送モード（ＡＴＭ）又は他のタイプのネットワークインタフェースとすることができる。ＬＡＮバスは、ＬＡＮに対しファイアウォール及び他のインターネット関連サービスを提供することができるゲートウェイデジタル処理システム６１０にも結合されている。ゲートウェイデジタル処理システム６１０は、ＩＳＰ６２６に結合され、クライアントコンピュータシステム６１８及び６２０とのインターネット接続性を提供する。ゲートウェイデジタル処理システム６１０は、例えば従来のサーバコンピュータシステムを含むことができる。同様に、ウェブサーバ６２８は、例えば従来のサーバコンピュータシステムを含むことができる。

システム６００は、クライアントコンピュータシステム６０２、６０４、６１８及び６２０及び／又はウェブサーバ６２８のうちの１つ又はそれ以上が、クライアントコンピュータシステム６０２、６０４、６１８及び６２０及び／又はウェブサーバ６２８のうちの別の１つ又はそれ以上にメディアデータ（例えば、ビデオ及びオーディオ、又はビデオ、又はオーディオ）を提供することを可能にする。このようなデータは、例えば、受信側システムによる要求に応答して供給することができ、受信側システムは、例えば、クライアントコンピュータシステム６０２、６０４、６１８及び６２０の１つ又はそれ以上とすることができる。本明細書で説明するように、このようなメディアデータは、ヒント又はヒントトラックに従ってシステム６００において転送することができる。当該ヒントは、本発明の１つの実施形態において、メディアデータの特定のフォーマット及び／又は特定のデータ通信（例えば、ネットワーク）プロトコルに従って作成し、本発明の１つの態様によれば、メディアデータのパケット化を可能にすることができる。

図７は、本発明の１つの実施形態に従って使用することができるデータ処理システムのブロック図である。例えば、図７に示すデジタル処理システム６５０は、クライアントコンピュータシステム、ウェブサーバシステム、従来のサーバシステム、その他として使用することができる。更に、デジタル処理システム６５０を使用して、ＩＳＰ６２４又は６２４など、インターネットサービスプロバイダの１つ又はそれ以上の機能を実行することができる。デジタル処理システム６５０は、モデム又はネットワークインタフェース６６８を介して外部システムにインタフェース接続することができる。モデム又はネットワークインタフェース６６８は、デジタル処理システム６５０の一部とみなすことができる点は理解されるであろう。モデム又はネットワークインタフェース６６８は、アナログモデム、ＩＳＤＮモデム、ケーブルモデム、トークンリングインタフェース、衛星伝送インタフェース、無線インタフェース、又は２つ又はそれ以上のデジタル処理システム間のデータ通信リンクを実現する他のインタフェースとすることができる。

デジタル処理システム６５０はプロセッサ６５２を含み、１つ又はそれ以上のプロセッサを表すことができ、Ｍｏｔｏｒｏｌａ ＰｏｗｅｒＰＣプロセッサ、Ｉｎｔｅｌ Ｐｅｎｔｔｉｕｍ（又はｘ８６）プロセッサといった、１つ又はそれ以上の従来のタイプのこうしたプロセッサを含むことができる。メモリ１５５は、バス６５６によってプロセッサ６５２に結合される。メモリ１５５は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）とすることができ、及び／又は、スタティックＲＡＭ（ＳＲＡＭ）を含むことができる。このプロセッサはまた、メモリ１５５の一部又はメモリ１５５と別個のものとみなすことができる他のタイプの記憶領域／メモリ（例えば、キャッシュ、フラッシュメモリ、ディスク、その他）にも結合することができる。

バス６５６は更に、プロセッサ６５２をディスプレイ制御装置６５８、大容量メモリ６６２、モデム又はネットワークインタフェース６６８、及び入力／出力（Ｉ／Ｏ）制御装置６６４に結合する。大容量メモリ６６２は、情報を記憶するための磁気、光学、電磁光学、テープ、及び／又は他のタイプの機械可読媒体／デバイスを表すことができる。例えば、大容量メモリ６６２は、ハードディスク、読み取り専用又は書き込み可能光学ＣＤ、その他を表すことができる。ディスプレイ制御装置６５８は、従来の方法で、陰極線管（ＣＲＴ）ディスプレイ、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、又は他のタイプのディスプレイ装置を表すことができるディスプレイ６６０を制御する。Ｉ／Ｏ制御装置６６４は、Ｉ／Ｏデバイス６６６を制御し、該デバイスは、１つ又はそれ以上のキーボード、マウス／トラックボール、他のポインティングデバイス、磁気及び／又は光学ディスクドライブ、プリンタ、スキャナ、デジタルカメラ、マイク、その他を含むことができる。

デジタル処理システム６５０は、多くの異なる構成及びアーキテクチャを有することができ、本発明と共に利用することができるシステムの１つの実施例を表すことは理解されるであろう。例えば、Ｍａｃｉｎｔｏｓｈ及びＩｎｔｅｌシステムは、周辺バス、専用キャッシュバス、その他のような複数のバスを有することが多い。一方、本発明のデジタル処理デバイスとして使用することができるネットワークコンピュータは、例えば、ハードディスク又は他の大容量記憶装置を含まない場合があるが、モデム又はインタフェース６６８など、プロセッサ６５２によって処理されるネットワーク接続部からのルーチン及び／又はデータを受信することができる。同様に、当技術分野で公知であるウェブＴＶシステムは、本発明のデジタル処理システムとみなすことができるが、このようなシステムは、Ｉ／Ｏデバイス６６６を参照しながら上述されたような、１つ又はそれ以上のＩ／Ｏデバイスを含まない場合がある。更に、携帯電話能力及び／又はページング能力を利用することができる携帯型通信及びデータ処理システムは、本発明と共に使用することができるデジタル処理システムとみなすことができる。

図７に示すシステム６５０において、大容量メモリ６６２（及び／又はメモリ６５４）は、本発明に従って（例えば、ヒントによって）処理することができるメディア（例えば、ビデオ、オーディオ、ムービーなど）を記憶することができる。或いは、メディアデータは、例えば、モデム又はネットワークインタフェース６６８を介してデジタル処理システム６５０が受信して記憶し、及び／又はディスプレイ６６０及び／又はＩ／Ｏデバイス６６６によって提示することができる。１つの実施形態において、パケット化メディアデータは、ヒントトラックに従ってＬＡＮ及び／又はインターネットなどのデータ通信ネットワークにわたって送信することができる。一方、プロセッサ６５２は、１つ又はそれ以上のルーチンを実行して、１つ又はそれ以上のヒントトラックを有するファイルを使用するか、或いは１つ又はそれ以上のヒントトラックを作成し、ヒントトラックに従ってプレゼンテーション又はパケット化のためにメディア（例えば、予めパッケージされたムービー、オーディオファイル、ビデオファイルなど）を処理することができる。このようなルーチンは、大容量メモリ６６２、メモリ６６４、及び／又は、デジタル処理システム６５０がアクセス可能な別の機械可読媒体に記憶することができる。１つの実施形態において、デジタル処理システム６５０は、ヒントトラックが埋め込まれたメディアデータを処理することができる。同様に、このような埋め込まれたメディアデータは、大容量メモリ６６２、メモリ６６４、及び／又はデジタル処理システム６５０がアクセス可能な機械可読媒体内に記憶することができる。

図８は、本発明の１つの実施形態による、ヒントを利用してメディアデータを転送するシステムのブロック図である。図８に示すシステム６８０は、データ通信リンク６８６を介してサーバ６９４に結合されたクライアントデジタル処理システム６８２として示される受信側システムを含む。サーバ６９４及び／又はクライアントデジタル処理システムは、例えば、図６及び図７を参照しながら説明されたデバイス／システムの１つ又はその組み合わせを表すことができる。

サーバ６９４は、ヒット生成及び処理ユニット６８８、メディア処理ユニット６９０及びデータ通信ユニット６９２を含み、これらの各々が、ハードワイヤード回路又は機械実行可能命令、或いはこれらの組み合わせを含むことができる。更に、このようなハードワイヤード回路及び／又は機械実行可能命令の少なくとも一部は、ヒット生成及び処理ユニット６８８、メディア処理ユニット６９０、並びにデータ通信ユニット６９２の組み合わせの間で共有することができる。１つの実施形態において、少なくとも１つのプロセッサに結合された、適切なルーチン及び／又はデータが記憶された少なくとも１つの記憶領域／メモリ（例えば、機械可読媒体）を利用して、少なくとも部分的には、ヒット生成及び処理ユニット６８８、メディア処理ユニット６９０及びデータ通信ユニット６９２の１つ又はその組み合わせを実装する。

１つの実施形態において、ヒット生成及び処理ユニット６８８は、メディア処理ユニット６９０によって処理されたメディアデータのパケット化のためのヒントを作成し記憶する。上述したように、ヒントは、メディアファイルに対して別個のファイルとして生成し記憶することができ、或いはメディアデータに埋め込むことができる。２つ以上のメディアフォーマットが処理されることになる場合、ヒット生成及び処理ユニット６８８が適切なフォーマットを考慮して、ヒントを生成することができる。メディアフォーマットに関する情報は、メディアデータ（例えば、ビデオ、又はビデオ及びオーディオのメディアファイル）を提供することができるメディア処理ユニット６９０により与えられることができる。同様に、データ通信ユニット６９２は、データ通信リンク６８６を介して、ヒントに従ってパケット化されたこのようなメディアデータを交換するため１つ又はそれ以上のデータ通信（例えば、ネットワーク）プロトコルを提供することができる。従って、ヒント生成及び処理ユニットは、メディア処理ユニット６９０により提供されたメディアフォーマット情報、及びデータ通信ユニット６９２により提供されたプロトコル情報に基づいて、クライアントデジタル処理システム６８２のような受信側デジタル処理システムに転送するための適切なヒントと、メディア及び／又はヒントのパケット化とを求めることができる。１つの実施形態において、メディア及びヒントのストリーミングは、ＱｕｉｃｋＴｉｍｅフォーマットに従って行われる。

データ通信リンク６８６を介して受信されたメディアデータ及びヒントパケットに応答して、クライアントデジタル処理システム６８２は、メディアデータによって表されたメディアオブジェクトを提示することができる。このようなプレゼンテーションは、上述のように一時的に行うことができる。本発明の１つの実施形態において、メディアデータは、任意選択的に、クライアントデジタル処理システム６８２が記憶し、例えば、その後のクライアントデジタル処理システム６８２によるプレゼンテーション及び／又は送信のために再アセンブルすることができる。

図９は、本発明の１つの実施形態による、ヒントを利用してメディアデータを転送するシステムのブロック図である。詳細には、図９は、ジェネレータと呼ばれる別個のデジタル処理システムがヒント（又は、ヒントトラック）を生成して、クライアントコンピュータシステムなどの別のシステムに転送するために該ヒントを使用してメディアデータをパケット化するサーバのような別のシステムに提供することができる、本発明の実施形態を示している。データ通信リンク６８６を介してクライアントデジタル処理システム６８２とデータを交換することができるサーバ７００を含むシステム６９６が図９に示されている。しかしながら、図９に示す実施形態において、サーバ７００はヒントを生成しない。むしろ、データ通信リンク７０８によってサーバ７００に結合されたジェネレータ７１０が、メディアデータをパケット化するのに使用されるヒントを生成するヒント生成ユニット７１２を含む。

１つの実施形態において、システム６９６の動作は、以下の通りである。すなわち、サーバ７００は、メディアデータを含む１つ又はそれ以上のメディアファイルのヒントを生成するようジェネレータ７１０に要求する。例えば、メディアファイルは、サーバ７００内の機械可読媒体上に記憶することができる。要求は、メディアファイルのフォーマット及び／又はメディアデータ及び／又は他のデータを送信するためのデータ通信プロトコルを示す情報を含むことができる。データ通信プロトコルは、データ通信リンク６８６に関連付けることができ、データ通信リンク６８６は、本発明の１つの実施形態において、サーバ７００とクライアントデジタル処理システム６８２との間でのメディア及び／又は他のデータの交換を容易にするために、特定の物理的及び論理的特性を有するネットワーク接続と関連付けることができる。要求に応答して、ヒント生成ユニット７１２は、時間関連ヒントトラックに関連付けることができる適切なヒントを生成し、該ヒントをサーバ７００に提供する。データ通信リンク７０８を介してジェネレータ７１０から受信されたヒントに応答して、サーバ７００、及び詳細にはヒント処理装置７０２は、ヒントを使用してクライアントデジタル処理システム６８２に送信するためにメディアデータをパケット化する。

データ通信リンク６８６を介して受信されたメディアデータ及びヒントパケットに応答して、クライアントデジタル処理システム６８２は、メディアデータによって表されたメディアオブジェクトを提示することができる。このようなプレゼンテーションは、上述したように一時的に行うことができる。本発明の１つの実施形態において、メディアデータは、任意選択的に、クライアントデジタル処理システム６８２が記憶し、例えば、その後のクライアントデジタル処理システム６８２によるプレゼンテーション及び／又は送信のために再アセンブルすることができる。

図１０は、本発明の１つの実施形態による、メディアデータ送信を行うヒントを生成する方法を示すフローチャートである。段階７２０において、２つ以上のフォーマットが使用されることになる場合、送信されるメディアデータについてのメディアフォーマットが決定される。１つのフォーマットのみが使用される場合、７２０は実行されなくてもよい。段階７２２において、同様に２つ以上の（プロトコル）を使用することができると仮定して、適切なデータ通信プロトコルを決定する。段階７２４において、メディアフォーマット及びデータ通信プロトコル（その一方又は両方が選択／構成されている可能性がある）に基づいて、メディアデータ送信に関係するヒント（例えば、ヒントトラック）を作成し記憶する。

任意選択である段階７２６において、ヒントを別のデジタル処理システムに送信することができる。本発明の１つの実施形態において、例えば、図１０の方法は、少なくとも部分的には、１つのデジタル処理システム（例えば、サーバ）が単独で実行することができる。代替の実施形態において、図１０の方法は、少なくとも部分的には、２つ又はそれ以上のデジタル処理システムが実行してもよい。例えば、メディアデータの属性は、サーバ又は他のシステムがジェネレータなどの別のデジタル処理システムに提供することができる。これに応答して、ジェネレータは、その属性に基づいて、サーバで記憶することができる適切なメディアフォーマット、データ通信プロトコル、及びメディアデータパケット化のためのヒントを決定することができる。或いは、サーバは、適切なメディアフォーマット及びプロトコルをジェネレータに提供することができ、該ジェネレータは、次にヒントを生成することができる。ジェネレータは、ヒントをサーバ又は他のデジタル処理システムに送信することができ、サーバ又は他のデジタル処理システムは、ヒントに従ってメディアデータをパケット化することができる。

図１１は、本発明の１つの実施形態による、ヒントに従って受信側システムによって受信されたメディアデータを処理する方法を示すフローチャートである。段階７３０において、ヒント又はヒントトラックに従って受信側システムによって送信されるメディアデータが受信側システムにより受信される。１つの実施形態において、受信側システムは、パケット化メディアデータ並びにパケット化ヒントトラックを受信することができる。ヒントトラックは、本発明の１つの実施形態において、メディアデータの少なくとも一部と関連付けることができる。このようなデータは、受信側システムが行なうことができる要求に応答して、受信側システムが受信することができる。例えば、１つの実施形態において、受信側システムは、クライアントコンピュータシステムとすることができ、メディアデータを求めてサーバ又は他のデジタル処理システムに対して要求を行うことができる。これに応答して、サーバは、メディアデータをパケット化するヒントを生成（又は別個のデジタル処理システムによってサーバのために生成される）して、ヒントを含むことができるパケット化メディアデータを受信側システムに送信することができる。

段階７３２において、受信側システムによって受信されたメディアデータが表すメディアオブジェクトが受信側システムで提示される。例えば、メディアデータは、受信側システムによって、例えばディスプレイ及びスピーカにより「提示」されるビデオ、オーディオ、又はその組み合わせを含むことができる。上述したように、メディアデータは、ＱｕｉｃｋＴｉｍｅムービーに関連付けることができる。

任意選択的に、段階７３４において、ヒントを含むことができるメディアデータをメディアファイルとして受信側システムが記憶することができる。従って、本発明の代替の実施形態において、段階７３２は、メディアデータが受信されるときには実行しなくともよく、或いは、段階７３４の前、後、又は段階７３４と並行して実行することができる。

段階７３４において、記憶されたメディアファイルは、任意選択的に再アセンブル及び／又は提示することができる。従って、段階７３２は、段階７３４の後に実行することができる。

図１２は、本発明の１つの実施形態による、ジェネレータなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の実施例である。図１２に示され且つ図１２を参照しながら以下で説明する要素を記憶する実際のメモリは、１つ又はそれ以上のディスク（例えば、磁気、光学、磁気光学、その他とすることができる）、図７を参照して上述したメモリ６５４及び／又は大容量メモリ６６２など、１つ又は複数の要素とすることができることは理解されるであろう。更に、図１２に示す機械可読記憶媒体が関連付けられるジェネレータがネットワークコンピュータである１つの実施形態において、機械可読記憶媒体の要素の１つ又はそれ以上は別のデジタル処理システムに記憶し、ジェネレータにダウンロードすることができる。更に、機械可読記憶媒体に関連して説明した要素は、ある時点で、不揮発性大容量メモリ（例えば、ハードディスク）に記憶することができる。逆に、他の時点では、機械記憶媒体の要素は、ＤＲＡＭ、ＳＲＡＭ、ディスク、その他などの異なる記憶領域間に分散させることができる。

図１２は、機械可読記憶媒体７４０を示している。１つの実施形態において、この機械可読記憶媒体は、本発明の１つ又はそれ以上の方法に従ってヒント又はヒントトラックを生成するデジタル処理システム、すなわちジェネレータによって少なくとも部分的に利用される。図８を参照して説明されたジェネレータは、ヒントトラックに従ってメディアデータを送信するデジタル処理システムに一体化することができ、或いは、図９を参照して説明したように、ヒントを作成し、該ヒントを利用してメディアデータをパケット化し送信するサーバなどの別のデジタル処理システムに該ヒントを提供するデジタル処理システムとすることができる。

図１２に示すように、機械可読記憶媒体７４０は通常、幾つかの要素を含む。例えば、機械可読記憶媒体７４０は、サーバオペレーティングシステム（ＯＳ）７４２によって示されるように、ジェネレータにオペレーティングシステムの機能を提供するソフトウェアを含む。ネットワーク伝送ルーチン７４８は、ルーチン、プロトコル、その他など、ジェネレータがデータ通信リンクを介してデータを送受信することを可能にするデータ通信機能を提供する。

加えて、機械可読記憶媒体７４０は、メディア送信に関連したヒントを作成するためのルーチン及びデータを含む。従って、機械可読記憶媒体７４０は、任意選択的に、ヒット作成ルーチン７４４によるヒントの作成に必要とすることができる１つ又はそれ以上のデータ通信プロトコル及びメディアフォーマットに関係する情報を提供することができる情報７５０を含むことができる。例えば、情報７５０は、ＱｕｉｃｋＴｉｍｅムービー、ＲＴＰ、ＭＰＥＧ、その他に関係する情報を含むことができる。しかしながら、このような情報は、少なくとも部分的に、ヒット作成ルーチン７４４に一体化し、及び／又はリモートデジタル処理システムによってジェネレータに提供することができる。

ヒット作成ルーチン７４４によって作成されたヒントは、作成ヒントとして記憶され、及び／又は他の場所（例えば、サーバとすることができるリモートデジタル処理装置）に記憶／送信することができる。ヒントは、やはり時間に関連する（例えば、ビデオ、オーディオ、ビデオ及びオーディオなど）メディアデータのパケット化及び送信のための時間に関連したヒントトラックである。

機械可読記憶媒体７４０についてジェネレータに関連して説明したが、媒体７４０は、少なくとも部分的には、幾つかのタイプのデジタル処理システム、データ記憶媒体、その他の一部とすることができる。例えば、機械可読記憶媒体７４０は、少なくとも部分的には、サーバ又は他のデジタル処理システムの一部として含めることができる。更に、機械可読記憶媒体７４０は、少なくとも部分的には、１つ又はそれ以上のディスク又は他の機械可読媒体上のソフトウェアユーティリティの一部として含めることができる。

図１３は、本発明の１つの実施形態による、サーバなどのデジタル処理システムによってアクセスすることができる機械可読記憶媒体の実施例である。図１３に図示され且つ参照しながら以下で説明される要素を記憶する実際のメモリは、１つ又はそれ以上のディスク（例えば、磁気、光学、磁気光学、その他とすることができる）、図７を参照しながら上述されたメモリ６５４及び／又は大容量メモリ６６２など、１つ又は複数の要素とすることができる点は理解されるであろう。更に、図１３に示す機械可読記憶媒体が関連付けられるサーバがネットワークコンピュータである１つの実施形態において、機械可読記憶媒体の要素の１つ又はそれ以上は、別のデジタル処理システムに記憶され、サーバにダウンロードすることができる。更に、機械可読記憶媒体に関連して説明された要素は、ある時点で、不揮発性大容量メモリ（例えば、ハードディスク）に記憶することができる。逆に、他の時点で、機械記憶媒体の要素は、ＤＲＡＭ、ＳＲＡＭ、ディスク、その他などの異なる記憶領域間に分散させることができる。

図１３は、機械可読記憶媒体７６０を示している。１つの実施形態において、この機械可読記憶媒体は、本発明の１つ又はそれ以上の方法に従ってデータ通信リンク上で送信するためにメディアデータをパケット化するのに少なくとも部分的に利用される。機械可読記憶媒体７６０は、図８を参照して説明されるサーバ６９４のようなサーバに関連付けられ、ヒントトラックを作成して該ヒントトラックに従ってメディアデータを送信するためのルーチンを含めることができる。別の実施形態において、機械可読記憶媒体７６０は、図９を参照して説明されたサーバ７００のようなデジタル処理システムに関連付けることができ、ジェネレータなどのデジタル処理システムは、ヒントを作成するためのルーチンを含み、サーバは、機械可読記憶媒体７６０によって提供されるルーチンによって処理されるヒントを使用して、メディアデータをパケット化して送信することができる。

機械可読記憶媒体７６０は幾つかの要素を含む。例えば、機械可読記憶媒体７６０は、サーバオペレーティングシステム（ＯＳ）７６２によって示されるように、サーバにオペレーティングシステム機能を提供するソフトウェアを含む。ネットワーク通信ルーチン７６８は、サーバがデータ通信リンクを介してデータを送受信できるように、ルーチン、プロトコル、その他などデータ通信機能を提供する。

加えて、機械可読記憶媒体７６０は、メディアデータをパケット化するメディアパケット化ルーチン７７０を含み、該ルーチンは、時間に関連し、ヒントに基づき、更にパケット化することもできる。従って、機械可読記憶媒体７６０は、メディアデータ記憶領域７６４及びヒント記憶領域７６６を含み、メディアデータ（例えば、ＱｕｉｃｋＴｉｍｅムービー又は他のメディアトラックとすることができる）及びヒント（例えば、ヒントトラック）をそれぞれ記憶する。ヒントは、メディアデータのパケット化及び送信のための時間に関連するヒントトラックを含み、メディアデータもまた通常は時間に関連する（例えば、ビデオ、オーディオ、ビデオ及びオーディオ）。１つの実施形態において、ヒントトラックは、メディアデータパケットとは別個にパケット化される。１つの実施形態において、ヒントは、別個のメディアファイル内に存在することがあるメディアデータ（例えば、特定のパケット）を識別するポインタ情報を含む。

図１４は、本発明の１つの実施形態による、受信側システム又は他のデジタル処理システムのような、デジタル処理システムがアクセスできる機械可読記憶媒体の実施例である。図１４に示され且つ図１４を参照して以下で説明される要素を記憶する実際のメモリは、１つ又はそれ以上のディスク（例えば、磁気、光学、磁気光学、その他とすることができる）、図７を参照して上述したメモリ６５４及び／又は大容量メモリ６６２といった、１つ又は複数の要素とすることができる点は理解されるであろう。更に、図１４に示す機械可読記憶媒体が関連付けられる受信側システムがネットワークコンピュータである１つの実施形態において、機械可読記憶媒体の要素の１つ又はそれ以上は、別のデジタル処理システムに記憶されて、受信側システムにダウンロードすることができる。更に、機械可読記憶媒体に関連して説明された要素は、ある時点では、不揮発性大容量メモリ（例えば、ハードディスク）に記憶することができる。逆に、他の時点では、機械記憶媒体の要素は、ＤＲＡＭ、ＳＲＡＭ、ディスク、その他などの異なる記憶領域間に分散させることができる。

図１４は、機械可読記憶媒体７８０を示している。１つの実施形態において、この機械可読記憶媒体は、本発明の１つ又はそれ以上の方法に従ってパケット化されたメディアデータを処理するために、少なくとも部分的に利用される。機械可読記憶媒体７８０は、図８及び図９を参照して説明されるクライアントデジタル処理システム６８２などの受信側システムに関連付けられ、ヒントに従って送信／受信されたメディアデータを提示するためのルーチンを含むことができる。或いは、機械可読記憶媒体７８０は、ヒント（例えば、ヒントトラック）が埋め込まれたメディアデータを含むことができる。このような埋め込まれたメディアデータは、機械可読記憶媒体７８０のような機械可読記憶媒体上に記憶されたルーチンによって予めパッケージ化し、又は生成することができる。

機械可読記憶媒体７８０は、幾つかの要素を含むことができる。例えば、機械可読記憶媒体７８０は、サーバオペレーティングシステム（ＯＳ）７７２によって示されるように、受信側システムにオペレーティングシステム機能を提供するソフトウェアを含む。ネットワーク通信ルーチン７８２は、サーバがデータ通信リンクを介してデータを送受信できるように、ルーチン、プロトコル、その他のようなデータ通信機能を提供する。

加えて、機械可読記憶媒体７８０は、ヒントに従ってパケット化されたメディアデータを提示するメディアプレゼンテーションルーチン７７８を含む。従って、機械可読記憶媒体７８０、及び詳細にはメディアプレゼンテーションルーチン７７８は、オーディオ及び／又はビデオデータの圧縮解除、ビデオの表示、及び／又はオーディオの再生、その他を行うためのルーチンを含むことができる。更に、メディアプレゼンテーションルーチン７７８は通常、メディアデータに関連するヒントの処理を行う。１つの実施形態において、ヒントは、メディアが提示されるときに単純に無視される。

任意選択的に、機械可読記憶媒体７８０は、ヒントに従ってパケットされたメディアデータをメディアデータ７７４として記憶し、記憶されたメディアデータに（例えば、提示、送信、その他のために）再アセンブルするためのメディアデータ再アセンブルルーチン７７６を含むことができる。

図１５は、本発明の１つの実施形態による、メディア及びヒント情報が記憶／転送されたデータ記憶及び／又は通信媒体の図である。様々なタイプの転送及び／又は記憶媒体を表すデータ記憶及び／又は通信媒体８００が示されており、これらは本発明に従ってパケット化されたメディアデータパケット８０４及びヒントパケット８０６を記憶又は転送することができる。例えば、媒体８００は、図７を参照して説明された大容量メモリ６６２及び／又はメモリ６５４を表すことができる。媒体８００は、図６に示すＬＡＮバス６１２又はメディア及び／又は他の情報を表すデータ／信号を転送するためのデータ通信リンク６８６のような通信媒体も表すことができる。

ヒントパケット８０６及びメディアパケット８０４は、図１５に示すように、１つのパケット内に一体化するか、或いは別個に記憶又は転送することができる。更に、ヒントパケット８０６及びメディアパケット８０４は、本明細書で説明されたフォーマット、又は他のメディアフォーマット、ネットワークプロトコル、及び／又はデジタル処理デバイスアーキテクチャと関連付けられたフォーマットのような、幾つかのタイプのフォーマットを具現化することができる。

エクストラクタ・トラック
ヒントトラックは、パケット構築命令を含むことに加えて、スケーラブルなコード化されたメディアで利用可能な複数のメディアストリームを示すのに使用することができる。スケーラブルなコード化されたメディアは、同じビデオコンテンツの複数のバージョンを記憶するメディアである。例えば、スケーラブルなコード化されたメディアは、ハンドヘルドデバイス、コンピュータ、標準精細度デバイス、高精細度デバイス、その他に好適なビデオストリームを記憶することができる。スケーラブルなコード化されたメディアの１つの実施例は、図１６Ａに示すように、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣビデオコーデックと共に使用されるスケーラブルビデオコーディングである。ＳＶＣ（スケーラブルビデオコンテンツ）は、単一のＳＶＣベースビデオトラックにコード化された複数のビデオストリームを示すのに使用される。ＳＶＣは、本明細書では、スケーラブルなメディアコンテンツ又はスケーラブルコンテンツを表し且つその実施例となるように使用される。ＳＶＣベースビデオトラックから利用可能な各ビデオストリームは、ビデオ動作点に対応する。１つの実施形態において、ビデオ動作点は、時間属性（例えば、フレーム数／秒（ｆｐｓ））、空間属性（例えば、水平方向及び垂直方向の画素数）及び品質ビデオ属性（例えば、異なる信号対雑音比）に対応するが、ビデオ動作点の代替の実施形態は、より多くの、又はより少ない、及び／又は異なるビデオ属性（例えば、ビット深度、彩度サブサンプリング周波数、その他）を有することができる。時間ビデオ属性は、ビデオフレームレート（例えば、１５フレーム／秒（ｆｐｓ）、２４ｆｐｓ、３０ｆｐｓ、その他）を含む。一方、空間ビデオ属性は、ストリームのビデオ解像度を記述するものである。例えば例証として、ビデオストリームは、ｓｕｂ−ｑｕａｒｔｅｒ ｃｏｍｍｏｎ ｉｎｔｅｒｍｅｄｉａｔｅ ｆｏｒｍａｔ（ＳＱＣＩＦ、解像度１２８ｘ９６画素）、ｑｕａｒｔｅｒＣＩＦ（ＱＣＩＦ、解像度１７６ｘ１４４画素）、ＣＩＦ（解像度３５２ｘ２８８画素）、その他とすることができる。空間ビデオ属性は、以下の図１６Ｂで更に説明する。加えて、ビデオ品質属性は、信号対雑音比として品質ビデオを記述するものである。例えば、所与の解像度及びフレームレートのビデオは、異なる信号対雑音比に対応する可変ビットレート（例えば、１２８ｋｐｂｓ、１９２ｋｂｐｓなど）で送ることができる。

図１６Ａは、ＳＶＣコード化ビデオベーストラックの１つの実施形態を示す。図１６Ａにおいて、ＳＶＣベーストラック１６００は、別個のフレーム１６０２Ａ−Ｄに細分化される。各１６０２Ａ−Ｄは、１つ又はそれ以上のネットワーク抽象化層（ＮＡＬ）ユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄを含む。ＮＡＬユニットは、様々な通信チャンネル及び／又は記憶媒体に適切なユニットにするビデオベーストラックのパーティションである。ＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄの各セットは、解像度の異なるビデオストリームに使用することができる。例えば例証として、ＮＡＬユニット１６０４Ａ−Ｄは、ＳＱＣＩＦのような低解像度メディアストリームを含む。低解像度ビデオストリームは、図１６Ｂに示すように、小さなスクリーン及び／又は限られたリソース（メモリ、その他）を備えたデバイスに使用されるビデオストリームである。図１６Ｂは、様々なビデオ解像度の１つの実施形態を示すブロック図である。図１６Ｂでは、３つのビデオ解像度、すなわち第１のビデオ解像度１６５０、第２のビデオ解像度１６５２、及び第３のビデオ解像度１６５４が示されている。例えば例証として、低解像度ビデオストリームは、第１のビデオ解像度ビデオ１６５０である。

図１６Ａに戻り、ＮＡＬユニット１６０４Ａ−Ｄ及び１６０６Ａ−Ｄを組み合わせると、第２の解像度ビデオの別のビデオストリーム（例えば、ＱＣＩＦビデオストリーム）が得られる。図１６Ｂに示すように、第２の解像度ビデオ１６５２は、より高解像度のビデオ、すなわちより大きな画面表示又はより多くのリソースを備えたデバイスに好適なビデオのビデオストリームである。

図１６Ａに戻り、更にＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄの３つのセットを使用すると、第３のより高解像度のビデオストリーム（例えば、全ＣＩＦビデオストリーム）が得られる。図１６Ｂに示すように、ＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄからのビデオストリームでは、第３の解像度ビデオ１６５４が得られる。第１の解像度ビデオ１６５０及び第２の解像度ビデオ１６５２と比較すると、第３の解像度ビデオ１６５４はより大きな解像度を有する。例えば例証として、第３の解像度ビデオは、ＣＩＦフォーマットビデオ（３５２ｘ２８８画素）である。

従って、ＳＶＣベーストラック１６００では、単一のビデオベーストラックから少なくとも３つの別個のビデオストリームが得られる。これによって、１つのベースコード化ビデオトラックを異なるターゲットデバイス又は動作点に使用することが可能となる。例えば例証として、第１の解像度ビデオ１６５０は、ビデオを携帯電話にストリーミングするのに使用することができ、第２の解像度ビデオ１６５２は、ビデオを携帯ビューアにストリーミングするのに使用することができ、第３の解像度ビデオ１６５４は、ビデオを標準的テレビにストリーミングするのに使用されることになる。

ＳＶＣコード化ベーストラックは、時間ビデオ属性、空間ビデオ属性、及び品質ビデオ属性の複数の組み合わせに対するビデオストリームを含むので、各ビデオストリームのトラックは、１つのトラック又は別個のトラックとして記憶することができる。別個のトラックの場合、潜在的に多数の別個のトラックを管理することに関するオーバーヘッドが管理不能になる。例えば例証として、Ｌ個の時間属性、Ｍ個の空間属性、及びＮ個の異なる品質のビデオ属性がある場合、単一のＳＶＣベーストラック内には最大Ｌ＊Ｍ＊Ｎ個までの異なるビデオストリームが存在する可能性がある。ビデオ復号器を供給するためにストリームをアセンブルすることは、サンプル当たりのＬ＊Ｍ＊Ｎ回の論理付加演算を意味する。一方、図１６Ａに示すように、複数のビデオストリームが単一のベーストラック内に保持されている場合、ビデオストリームのサブセットを抽出するためには、ＳＶＣコード化ベーストラック内の各ビデオストリームを検討して、特定のビデオストリームサブセットの関連データを見つけなければならない。これは、特定のビデオストリームサブセットを求めるためには、Ｌ＊Ｍ＊Ｎ個のビデオストリームの全データにアクセスしなければならないことを意味する。更に、ＳＶＣコード化ベーストラックは通常、ＩＳＯファイル内に記憶されるので、１つのビデオＳＶＣベーストラックのデータは、フレーム内に近接して記憶される。従って、ＳＶＣベーストラックのフレームは、全てのデータを含み、復号器は、全てのデータを読み取って使用しないデータを破棄しなければならない。

全てを考慮すると、単一のＳＶＣベーストラック（又は、各々がスケーラブルなコンテンツを含むＳＶＣベーストラックの少なくとも１つのセット）を使用することは、ビデオ復号器がＬ＊Ｍ＊Ｎ個のビデオストリームを処理しなくて済むので好ましいことである。しかしながら、ビデオストリームの１つを別個の近接ストリームとして利用可能であることが有益となるときもある。必要とされるのは、ＳＶＣベーストラック全体を検討することなく、ＳＶＣベーストラックから利用可能なビデオストリームを抽出する機構である。ある形態のヒントトラック（例えば、エクストラクタ・トラック）を使用して、単一のＳＶＣベーストラックで利用可能な複数のビデオストリームを抽出することができる。各エクストラクタ・トラックは、提案された動作点（例えば、品質、時間スケール及び／又は空間サイズの固有の組み合わせ）を表し、ＳＶＣベーストラック内の残りのデータを無視しながら、ＳＶＣベーストラックからその動作点に必要とされるデータ（例えば、結果として得られるビデオストリーム）をアセンブルする方法に関する情報を含む。詳細には、エクストラクタ・トラックは、品質、時間スケール及び／又は空間サイズのビデオ属性のうちの２つ又はそれ以上の固有の組み合わせに使用することができる。例示的な実施形態において、エクストラクタ・トラックは、スケーラブルなコード化ビデオ（所定回数にある時間期間にわたって所定シーケンスで提示される一連の関連画像など）に使用されるが、代替の実施形態では、他の形態のスケーラブルなメディア（例えば、オーディオ、シーン、その他）に対してエクストラクタ・トラックを使用することができる。特定の実施形態において、エクストラクタ・トラックは、エクストラクタ・トラックによって参照されるベーストラックとは別個で且つ異なるデータ構造体とすることができ、他の実施形態では、エクストラクタ・トラックは、ベーストラック内にインターリーブすることができ、或いは、ベーストラックからのメディアデータのサンプルを含むこともできる。

図１６Ｃは、アグリゲータＮＡＬユニット１６６０Ａ−Ｂを利用するＳＶＣコード化ビデオベーストラックの１つの実施形態を示す。図１６Ｃにおいては、図１６Ａと同様に、ＳＶＣベーストラック１６６０は、別個のフレーム１６０２Ａ−Ｄに細分化される。各フレーム１６０２Ａ−Ｄは、１つ又はそれ以上のＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄを含む。ＮＡＬユニットは、様々な通信チャンネル及び／又は記憶媒体に適切なユニットにするビデオベーストラックのパーティションである。ＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄの各セットは、異なるビデオストリームに使用することができる。ビデオストリームは、解像度、品質、ビットレート、その他が異なる可能性がある。コンテンツのスケールは、解像度、品質、ビットレート（例えばデータ送信の）、その他が異なる可能性がある。例えば例証として、ＮＡＬユニット１６０４−Ｄは、ＳＱＣＩＦ、ＱＣＩＦ、ＣＩＦ、その他のような低解像度メディアストリームを含む。しかしながら、図１６Ａとは異なり、図１６Ｃでは、ＮＡＬユニット１６０４Ａ−Ｄ、１６０６Ａ−Ｄ、１６０８Ａ−Ｄの一部は、アグリゲータＮＡＬユニット１６６２Ａ−Ｂを使用して編成される。アグリゲータＮＡＬユニット１６６２Ａ−Ｂは、ＮＡＬユニットをＮＡＬユニットのグループに編成するのに使用される。

１つの実施形態において、アグリゲータＮＡＬユニットは、１つ又はそれ以上のＮＡＬユニット、長さ、タイプ、及び余剰なバイトを含む。長さとは、初期ＮＡＬユニットの長さである。タイプとは、ＮＡＬユニットのタイプである。余剰なバイトとは、初期ＮＡＬユニットの後の余剰なバイトを表し、アグリゲータＮＡＬユニットにおける追加のＮＡＬユニットに対するオフセットとして使用される。

１つの実施形態において、アグリゲータＮＡＬユニット１６６２Ａは、ＮＡＬユニット１６０４Ａ及び１６０６Ａを含む。この実施形態において、アグリゲータは、ビデオフレーム１６０２Ａの一部を含み、第１及び第２の解像度ビデオの抽出をサポートする。或いは、別の実施形態において、アグリゲータＮＡＬユニット１６６２Ｂは、フレーム全体のＮＡＬユニット、すなわちＮＡＬユニット１６０４Ｂ、１６０６Ｂ、１６０８Ｂを含む。この代替の実施形態において、アグリゲータＮＡＬユニット１６６２Ｂは、第１、第２及び第３の解像度ビデオをサポートする。

図１７Ａは、ＳＶＣコード化ベーストラックからビデオストリームを抽出するのに使用されるエクストラクタ・トラックの１つの実施形態を示すブロック図である。図１７Ａにおいて、ＳＶＣベーストラック１６００は、ビデオフレーム１６０２Ａ−Ｂを含み、各ビデオフレーム１６０２Ａ−Ｂは、異なるビデオストリームに使用することができるＮＡＬユニットＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂ、１６０８Ａ−Ｂを含む。図１６Ａと同様に、第１の解像度ビデオストリーム（例えば、ＳＱＣＩＦビデオストリームは、ＮＡＬユニット１６０４Ａ−Ｂからアセンブルされ、第２の解像度ビデオストリーム（例えば、ＱＣＩＦビデオストリーム）は、ＮＡＬユニット１６０４Ａ−Ｂからアセンブルされ、一方、第３のビデオストリーム（例えば、ＣＩＦビデオストリーム）は、ＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂ、１６０８Ａ−Ｂからアセンブルすることができる。図１６Ａとは異なり、エクストラクタ・トラック１７００及び１７１０は、ＳＶＣベーストラック１６００内で利用可能な異なるビデオストリームを抽出するのに使用される。エクストラクタ・トラック１７００は、エクストラクタ・トラック１７００が一連のＮＡＬユニットであるので、ＡＶＣ及びＳＶＣベーストラックと同様に構造化される。エクストラクタ・トラックＮＡＬユニットは、他のＮＡＬユニットと合わせることができる。更に、エクストラクタ・トラック１７００は、エクストラクタ・トラック１７００をＳＶＣベーストラック１６００にリンクするトラック参照「ｓｃａｌ」を有する。加えて、エクストラクタ・トラックは、ＳＶＣベーストラック１６００と同じトラックタイプを有する。

例えば例証として、エクストラクタ・トラック１７００は、ＳＶＣベーストラック１６００において、ＮＡＬユニットＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂをそれぞれ参照するＮＡＬユニット１７０４Ａ−Ｂ、１７０６Ａ−Ｂを含む。ＮＡＬユニット１７０４Ａ−Ｂ、１７０６Ａ−Ｂは、ＳＶＣベーストラック１６００内で時間的に整合されたＮＡＬユニットを見つけて、細粒度スケーラビリティ（ＦＧＳ）ＮＡＬユニットの一部などとして、そのＮＡＬユニットの全て又は一部を抽出するようにビデオ復号器に指示する。例えば例証として、ＮＡＬユニット１７０４Ａは、ＮＡＬユニット１６０４Ａを見つけて、ＮＡＬユニット１６０４Ａの一部又は全てを抽出するように復号器に指示する。ＮＡＬユニット１７０４Ａが、ＮＡＬユニット１６０４Ａの一部を抽出するように復号器に指示する場合、ＮＡＬユニット１７０４Ａは、取り出すバイトの数及びＮＡＬユニット１６０４Ａへのオフセットに関する命令を含む。ＳＶＣベーストラックＮＡＬユニットの一部のみを取り出すことは、ＳＶＣベーストラック１６００から様々なレベルのビデオ品質を抽出する１つの実施形態である。１つの実施形態において、部分的なＮＡＬユニットの抽出は、ＦＧＳスライスなどの漸進的な改善スライスを含むＮＡＬユニットと共に行われる。

更に、一定レベルの品質を維持するために、エクストラクタ・トラック１７００ＮＡＬユニットは、異なる量のベーストラックＮＡＬユニットを抽出することができる。例示的な実施形態において、エクストラクタ・トラックは、一定のビデオ品質を維持するために正しいカットポイントを算出する。例えば例証として、ＮＡＬユニット１７０４Ａは、ＮＡＬユニット１６０４Ａからより多く抽出するように復号器に指示することができ、一方、ＮＡＬユニット１７０４Ｂは、全体的なビデオ品質を維持するためにＮＡＬユニット１６０４Ｂからより少ない抽出を指示することができる。エクストラクタ・トラック１７００はＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂを参照するので、エクストラクタ・トラック１７００は、第２の解像度ビデオストリームを表す。従って、ビデオ復号器は、ＳＶＣベーストラック１６００全体を処理する必要がなく、エクストラクタ・トラック１７００を読み取ることによって第２の解像度ビデオストリームを抽出することができる。

エクストラクタ・トラック１７００と同様に、エクストラクタ・トラック１７１０は、ＮＡＬユニット１７１４Ａ−Ｂを含む。しかしながら、ＮＡＬユニット１７１４Ａ−ＢがＳＶＣベーストラック１６００内の対応するＮＡＬユニットを参照するのではなく、ＮＡＬユニット１７１４Ａ−Ｂは、ＮＡＬユニット１６０４Ａ−Ｂの少なくとも一部のコピーである。従って、エクストラクタ・トラック１７１０は、このビデオストリームに必要とされるＮＡＬユニットを含むことによって第１のビデオ解像度ストリームを表す。更に、エクストラクタ・トラック２００、２１０は、ビデオファイル内の他のトラックと同様にヒントすることができる。しかしながら、参照エクストラクタＮＡＬユニットを含むヒントトラックは、参照ＮＡＬユニットに含まれるバイトを抽出する必要がある。例えば例証として、参照エクストラクタＮＡＬユニット１７０４Ａ−Ｂを含むヒントトラックは、参照ベースＮＡＬユニット１６０４Ａ−Ｂからバイトを抽出する必要がある。

更に、１つの実施形態において、エクストラクタ・トラック１７００、１７１０は更に、ＮＡＬ参照ユニットでもなくベーストラックからのＮＡＬユニットのコピーでもないＮＡＬユニットを含むことができる。この実施形態において、これらのＮＡＬユニットは、ＳＶＣベーストラック１６００とは異なるビデオベーストラックのパーティションである。この実施形態を使用して、ＳＶＣベーストラック１６００からの抽出ＮＡＬユニットを異なるＮＡＬユニットと組み合わせて第２のビデオストリームを形成することができる。例えば例証として、１つのエクストラクタ・トラックは、低解像度の１５フレーム／秒（ｆｐｓ）ＳＶＣベーストラックから抽出されたトラックを追加のＮＡＬユニットと組み合わせて、１５ｆｐｓ高解像度ビデオストリームを表す。従って、エクストラクタ・トラックを使用して、低品質ビデオストリームから高品質ビデオストリームを構築することができる。加えて、別の抽出トラックは、低解像度１５ｆｐｓＳＶＣベーストラックからの抽出トラックを追加のＮＡＬユニットと組み合わせて、３０ｆｐｓ高解像度ビデオストリームを表す。この実施例は、エクストラクタ・トラックを使用して低フレーム率ビデオストリームから高フレーム率ビデオストリームを構築することを示している。従って、エクストラクタ・トラックを使用して高品質ビデオストリームから低品質ビデオストリームを抽出するか、又は、低品質なビデオストリームから高品質ビデオストリームを構築することができる。より低品質なビデオを作成するためにエクストラクタ・トラック又は他のデータセットを使用することは、ある時間期間後に記憶されたビデオをシニングする（例えば、ある時間期間後に記憶された監視ビデオをシニングする）際に特に有用とすることができる。この場合、エクストラクタ・トラック自体の中にビデオデータを含めることが有用とすることができる。

図１７Ｂは、アグリゲータネットワーク抽象化層ユニットを含むＳＶＣコード化ベーストラックからビデオストリームを抽出するのに使用されるエクストラクタ・トラックの１つの実施形態を示すブロック図である。図１７Ａと同様に、ＳＶＣベーストラック１６６０は、ビデオフレーム１６０２Ａ−Ｂを含み、各ビデオフレーム１６０４Ａ−Ｂは、異なるビデオストリームに使用することができるＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂ、１６０８Ａ−Ｂを含む。ＳＶＣベーストラック１６６０は更に、アグリゲータＮＡＬユニット１６６０Ａ−Ｂを含む。アグリゲータＮＡＬユニット１６６０Ａは、ＮＡＬユニット１６０４Ａ、１６０６Ａをグループ化し、アグリゲータＮＡＬユニット１６６０Ｂは、ＮＡＬユニット１６０４Ｂ、１６０６Ｂをグループ化する。図１６Ａと同様に、第１の解像度ビデオストリームは、ＮＡＬユニット１６０４Ａ−Ｂ（例えば、ＳＱＣＩＦビデオストリーム）からアセンブルされ、第２の解像度ビデオストリームは、ＮＡＬユニット１６０４Ａ−Ｂ及び１６０６Ａ−Ｂ（例えば、ＱＣＩＦビデオストリーム）からアセンブルされ、一方、第３のビデオストリームは、ＮＡＬユニット１６０４Ａ−Ｂ、１６０６Ａ−Ｂ、１６０８Ａ−Ｂ（例えばＣＩＦビデオストリーム）からアセンブルすることができる。図１7Ａと同様に、抽出トラック１７００及び１７６０は、ＳＶＣベーストラック１６６０で利用可能な異なるビデオストリームを抽出するのに使用される。エクストラクタ・トラック１７５０は、一連のＮＡＬユニットであるので、エクストラクタ・トラック１７５０はＡＶＣ及びＳＶＣベーストラックと同様に構造化される。エクストラクタ・トラックＮＡＬユニットは、他のＮＡＬユニットと合わせることができる。更に、エクストラクタ・トラック１７００は、エクストラクタ・トラック１７５０をＳＶＣベーストラック１６６０にリンクするトラック参照「ｓｅａｌ」を有する。加えて、エクストラクタ・トラックは、ＳＶＣベーストラック１６００と同じトラックタイプを有する。加えて、エクストラクタ・トラックは、アグリゲータＮＡＬユニットを参照するか、又はアグリゲータＮＡＬユニットからコピーすることができる。

１つの実施形態において、抽出トラック１７５０は、ＮＡＬユニット１７５４Ａ−Ｂ、１７５６Ａ−Ｂを使用してアグリゲータＮＡＬユニット１６６０Ａ−Ｂを参照する。アグリゲータＮＡＬユニット１６６０Ａ−Ｂを参照することによって、抽出トラック１７５０は、アグリゲータＮＡＬユニットを含む全てのＮＡＬユニットを参照する。別の実施形態（図示せず）においては、抽出トラック１７５０の一部であるＮＡＬユニットは、集約ＮＡＬユニット内の特定のＮＡＬユニットを参照することができる。特定のユニットを参照することによって、参照側ＮＡＬユニットは、特定のＮＡＬユニットを参照し、アグリゲータＮＡＬユニットの一部である他のＮＡＬユニットは参照しない。図１７Ａと同様に、ＮＡＬユニット１７５４Ａ−Ｂは、単一のＮＡＬユニットを参照するＮＡＬユニットに対する類似の特性を有する。例えば例証として、抽出トラック１７５０は、ＳＶＣベーストラック１６６０内のアグリゲータＮＡＬユニット１６６０Ａ−Ｂを参照するＮＡＬユニット１７５４Ａ−Ｂ、１７５６Ａ−Ｂを含む。ＮＡＬユニット１７５４Ａ−Ｂは、アグリゲータＮＡＬユニット１６６０Ａにおいて時間的に整合されたＮＡＬユニットを見つけ、集約されたＮＡＬユニットの全部又は一部を抽出するようにビデオ復号器に指示する。例えば例証として、ＮＡＬユニット１７５４Ａは、アグリゲータＮＡＬユニット１６６０Ａを見つけ、アグリゲータＮＡＬユニット１６６０Ａを含むＮＡＬユニットの一部又は全てを抽出するように復号器に指示する。ＮＡＬユニット１７５４Ａが、アグリゲータＮＡＬユニット１６６０Ａの一部を抽出するように復号器に指示した場合、ＮＡＬユニット１７５４Ａは、取り出すバイトの数及びアグリゲータＮＡＬユニット１６６０Ａに対するオフセットに関する命令を含む。ＳＶＣベーストラックＮＡＬユニットの一部だけを取り出すことは、ＳＶＣベーストラック１６６０から様々なレベルのビデオ品質を抽出する１つの実施形態である。更に、一定レベルの品質を維持するために、エクストラクタ・トラック１７５０ＮＡＬユニットは、異なる量のベーストラックＮＡＬユニットを抽出することができる。例示的な実施形態において、エクストラクタ・トラックは、一定のビデオ品質を維持するために正しいカットポイントを算出する。

抽出トラック１７５０と同様に、抽出トラック１７６０は、ＮＡＬユニット１７６４Ａ−Ｂを含む。しかしながら、ＮＡＬユニット１７６４Ａ−ＢがＳＶＣベーストラック１６００内の対応するアグリゲータＮＡＬユニットを参照するのではなく、ＮＡＬユニット１７６４Ａ−Ｂは、ＮＡＬユニット１６０４Ａ−Ｂの少なくとも一部のコピーである。更に、エクストラクタ・トラック１７５０、１７６０は、ビデオファイル内の他のトラックと同様にヒントすることができる。

図１８は、エクストラクタ・トラックを組み込んだビデオファイルの１つの実施形態を示すブロック図である。図１８においては、ビデオファイル１８００は、ムービーヘッダ１８０２、ビデオメタデータ１８０４−１８１０及びデータ１８１２を含む。ビデオメタデータ１８０４−１８１０は、オーディオトラック１８０４及びビデオトラック１８０６−１８１０を含む。トラック１８０４−１８１０の各々は、どのビデオ/オーディオトラックがビデオファイル１８００において利用可能であるかを記述するものである。例えば、３つのタイプのビデオ、すなわちＳＱＣＩＦ ＡＶＣビデオトラック１８０６、ＱＣＩＦ ＳＶＣビデオトラック１８０８及びＳＱＣＩＦ ＳＶＣビデオトラック１８１０がビデオファイル１８００内で利用可能である。ビデオ復号器は、どのタイプのビデオ／オーディオストリームがビデオファイル１８００内で利用可能であるかを判断するためにメタデータ１８０４−１８１０に問合わせることができる。データ１８１２は、ビデオフレーム（例えば、図１６Ａに示すようなＮＡＬユニット１６０４Ａ−Ｄ、その他）、オーディオフレーム、及びエクストラクタ・トラックを含む。

図１９は、エクストラクタ・トラックを生成してＳＶＣベーストラックと共に使用するシステムの１つの実施形態を示すブロック図である。図１９においては、ベーストラック作成器１９０２は、ＳＶＣベーストラックを含むメディアを作成する。ベーストラックは、記憶装置１９１０内に記憶される。加えて、ＳＶＣエクストラクタ・トラック作成器１９１６は、ベーストラック作成器１９０２からのベーストラックを使用して、各動作点に対してエクストラクタ・トラックを作成する。各動作点のエクストラクタ・トラックは通常、対応するベーストラックから導出される。動作点は、時間ビデオ属性、空間ビデオ属性、及び品質ビデオ属性のビデオスケーラビリティの固有の組み合わせである。例えば例証として、ＳＶＣエクストラクタ・トラック作成器１９１６は、低品質８ｆｐｓＳＱＣＩＦビデオストリーム、２４ｆｐｓ中品質ＱＣＩＦビデオストリーム、高品質３０ｆｐｓＣＩＦビデオストリーム、その他であるビデオストリームのエクストラクタ・トラックを作成することができる。一般に、ＳＶＣエクストラクタ・トラック作成器１９１６は、入力ＳＶＣベーストラックによってサポートされるあらゆるビデオストリーム用のエクストラクタ・トラックを作成することができる。１つの実施形態において、作成ＳＶＣエクストラクタ・トラックは、記憶装置１９１０内に記憶されるが、代替の実施形態において、エクストラクタ・トラックは、対応するＳＶＣベーストラックから別個に記憶することができる。エクストラクタ・トラックは、全ての可能な動作点に対してではなく、動作点の適切なサブセットに対してのみ存在し、ユーザ（例えば、クライアントシステム）は、このサブセットから使用可能な動作点を選択することができる点は理解されるであろう。或いは、ＳＶＣエクストラクタ・トラック１９１６は、ビデオストリームの不要な又は冗長な部分を除去しながら、２つ又はそれ以上のビデオストリームから単一のＳＶＣトラックを形成することができる。例えば例証として、ＳＶＣエクストラクタ・トラック１９１６は、２４ｆｐｓ中品質ＱＣＩＦビデオストリーム及び高品質３０ｆｐｓＣＩＦビデオストリームからＳＶＣベーストラックを含むＳＶＣメディアを作成することができる。ＳＶＣエクストラクタ・トラック１９１６は、２つのビデオストリームをＣＩＦベーストラック及びＱＣＩＦビデオストリーム用エクストラクタ・トラックに処理する。

作成されたＳＶＣベーストラック及びエクストラクタ・トラックは、様々な方法で使用することができる。１つの実施形態において、ローカルクライアント１９０４は、記憶装置１９１０からＳＶＣベーストラック及びエクストラクタ・トラックを読み込んで、どのビデオストリームがＳＶＣベーストラック及びエクストラクタ・トラック内で利用可能であるかを判断する。利用可能なビデオストリームに基づいて、ローカルクライアントは、対応するエクストラクタ・トラックを使用して、ＳＶＣベーストラックから所望のビデオストリームを抽出する。１つの実施形態において、ローカルクライアントは、ベーストラック及びエクストラクタ・トラックを読み取り処理することができる記憶装置１９１０に対しローカルのマシン上で実行するプログラムの単一のインスタンスであるが、代替の実施形態において、ローカルクライアントは、同じタイプのプログラムの２つ以上のインスタンスとすることができる。以下では、ローカルクライアントによるＳＶＣベーストラック及びエクストラクタ・トラックの処理について図２１で更に説明する。

代替の実施形態において、送信サーバ１９０６は、リモートクライアント１９０８Ａ−Ｂ用にＳＶＣベーストラック及びエクストラクタ・トラックを処理する。このクライアント−サーバ構成においては、リモートクライアント１９０８Ａ−Ｂは、ＳＶＣベーストラック及びエクストラクタ・トラックから利用可能なビデオに対する要求を送信サーバ１９０６に送信する。クライアント−サーバの実施形態の１つにおいて、リモートクライアント１９０８Ａ−Ｂは、送信サーバ１９０６に直接ビデオストリームを要求することによってビデオを要求する。これに応答して、送信サーバ１９０６は、対応するエクストラクタ・トラックにアクセスして、エクストラクタ・トラックを使用して要求されたビデオストリームをＳＶＣベーストラックから取り出す。送信サーバ１９０６は、ビデオストリームをアセンブルして、ビデオストリームを要求側リモートクライアントに送る。このクライアント−サーバの実施形態は、図２２において以下に更に説明される。この手法において、送信サーバ１９０６は、エクストラクタ・トラックを使用して、ＳＶＣベーストラック全体を解析するのではなく、要求側リモートクライアント４０８Ａ−Ｂによって使用されている動作点の一部であるベーストラックの部分だけを取り出して送信する。

クライアント−サーバの代替の実施形態において、リモートクライアント１９０８Ａ−Ｂは、利用可能なビデオストリームを送信サーバ１９０６に要求する。これに応答して、送信サーバ１９０６は、利用可能なビデオストリームのリストを要求中のリモートクライアント１９０８Ａ−Ｂに返す。１つの実施形態において、送信サーバ１９０６は、メタデータ１８０４−１８１０をリモートクライアント１９０８Ａ−Ｂに返送し、代替の実施形態では、送信サーバ１９０６は、他の手段（例えば、単純なリスト、そのリストを含む共通ゲートウェイインタフェース（ＣＧＩ）形式、その他）で利用可能なビデオストリームのリストを返送する。リモートクライアント１９０８Ａ−Ｂは、送信サーバ１９０６に対して所望のビデオストリームを要求し、送信サーバは、要求されたビデオストリームを送る。例示的な実施形態において、リモートクライアント１９０８Ａ−Ｂは、所望のビデオストリームに対応するエクストラクタ・トラックを送信サーバ１９０６に要求する。エクストラクタ・トラックの受信に応答して、リモートクライアント１９０８Ａ−Ｂは、適切な指令を送信サーバ１９０６に送ることによって、ビデオストリームを要求する（例えば、リモートクライアント１９０８Ａ−Ｂは、ＨＴＴＰバイト要求などを使用して、ビデオストリーム１６０２Ａ−ＢをＳＶＣベーストラックに要求する）。このクライアント−サーバの実施形態について、以下において図２３で更に説明する。

ＳＶＣベーストラック及びエクストラクタ・トラックは、ローカル１９０４及びリモートクライアント１９０８Ａ−Ｂによって使用されることに加えて、ＡＶＣ専用コンテンツジェネレータ１９１２が処理することができる。ＡＶＣ専用コンテンツジェネレータ１９１２は、ＳＶＣエクストラクタ・トラックにアクセスしてエクストラクタ・トラックを使用してＡＶＣ専用コンテンツを対応するＳＶＣベーストラックからアセンブルすることによって、ＡＶＣ専用コンテンツ（例えば、特定の動作点でのＨ．２６４／ＡＶＣビデオコンテンツ）を作成する。ＡＶＣ専用コンテンツジェネレータ１９１２は、ＡＶＣ専用コンテンツを記憶装置１９１４に記憶する。リモートクライアント１９０８Ａ−Ｂは、記憶装置１９１４からＡＶＣ専用コンテンツ（例えば、特定の動作点でのＨ．２６４／ＡＶＣビデオコンテンツ）にアクセスすることができる。

図２０は、ＳＶＣベーストラックからＳＶＣエクストラクタ・トラックを生成する方法２０００の１つの実施形態のフローチャートである。ブロック２００２で、方法２０００は、生成される動作点の数を決定する。上述のように、各動作点は、動作点に関連したビデオ属性に基づいて１つのビデオストリームを記述するものである。１つの実施形態において、各動作点は、時間ビデオ属性、空間ビデオ属性、及び品質ビデオ属性の固有の組み合わせであるが、代替の実施形態は、より多い、又はより少ない、及び／又は異なるビデオ属性（例えば、ビット深度、彩度サブサンプリング周波数、その他）を含む動作点を有することができる。例えば例証として、時間ビデオ属性は、ビデオストリームフレームレート（例えば、８、１５、３０ｆｐｓ、その他）を記述するものであり、空間ビデオ属性は、ビデオストリーム解像度（例えば、ＳＱＣＩＦ、ＱＣＩＦ、ＣＩＦ、その他）を記述するものであり、品質ビデオ属性は、通常は信号対雑音比で記述されるビデオストリーム品質を記述するものである。

ブロック２００４で、方法２０００は、動作点の少なくともサブセットに対してＳＶＣベーストラックに対応するエクストラクタ・トラックをコード化する。方法２０００は、サブセット内の動作点に対して１つのエクストラクタ・トラックを作成する。上述のように、エクストラクタ・トラックは、ＳＶＣベーストラック内のＮＡＬユニットに対する参照であるか、又はベーストラック内のＮＡＬユニットのコピーであるＮＡＬユニットを含む。ブロック２００６で、方法２０００は、エクストラクタ・トラックを記憶する。加えて、方法２０００は、ビデオファイル３００を再レイアウトすることによって記憶エクストラクタ・トラックを含むビデオファイル３００の一部を最適化することができる。これは、詳細には、ＮＡＬユニットのコピーを含むエクストラクタ・トラックに有用である。

図２１は、対応するエクストラクタ・トラックを使用してＳＶＣベーストラックからビデオストリームを取り出す方法２１００の１つの実施形態のフローチャートである。ブロック２１０２で、方法２１００は、クライアント能力を判断する。クライアント能力は、限定ではないが、ディスプレイサイズ、ディスプレイグラフィックス能力、メモリ、ビデオバッファ、処理能力、その他に依存する。例えば例証として、小型ディスプレイ及び低電力ＣＰＵを有するハンドヘルドデバイスは、１５ｆｐｓＳＱＣＩＦビデオストリームを処理できる場合があり、一方、より優れたＣＰＵ及びグラフィックス能力を有するデスクトップコンピュータは、３０ｆｐｓＣＩＦビデオストリームを扱う必要がある場合がある。

ブロック２１０４で、方法２１００は、どの動作点が判断されたクライアント能力及び利用可能なエクストラクタ・トラックに適合するかを示すメディアエクストラクタ・トラック（又は他のデータ）に問合わせることによって、利用可能なメディアストリームを判断する。１つの実施形態において、方法２１００は、適合性を判断するために利用可能なメディアエクストラクタ・トラックに問合わせを行うが、代替の実施形態において、方法２１００は、異なる手段（例えば、メディアメタデータ１８０４−１８１０に問合わせる、その他）で適合性を判断することができる。例えば例証として、ターゲットデバイスがハンドヘルドデバイスである場合、方法２１００は、低解像度低ビットレートメディアストリーム（例えば、１５ｆｐｓＳＱＣＩＦビデオストリーム）が利用可能であるかどうかを判断する。

ブロック２１０６で、方法２１００は、クライアント能力に適合する適切なエクストラクタ・トラックを選択する。例えば例証として、クライアントがデスクトップコンピュータである場合、方法２１００は、解像度又はｆｐｓが低いビデオストリームに優る３０ｆｐｓＣＩＦビデオストリームを選び出すことになる。ブロック２１０８で、方法２１００は、選択したメディアストリームに関連したエクストラクタ・トラックにアクセスする。

ブロック２１１０で、方法２１００は、エクストラクタ・トラックを使用してエクストラクタ・トラックに関連したビデオストリームを取り出す。方法２１００は、エクストラクタ・トラックを使用して、（ｉ）エクストラクタ・トラックがビデオデータをベーストラックＮＡＬユニットからエクストラクタＮＡＬユニットにコピーした場合にはＮＡＬユニット内のデータを読み取るか、又は（ｉｉ）ＳＶＣベーストラック内に含まれたビデオストリーム用データの参照としてエクストラクタ・トラックＮＡＬユニットを使用することによってビデオストリームを取り出す。これらのタイプのエクストラクタ・トラックのいずれかによって、方法２１００は、ＳＶＣコード化ベーストラックからビデオストリームを取り出すことが可能となる。例えば例証として、参照側エクストラクタ・トラックＮＡＬユニットは、方法２１００が（ｉ）ＳＶＣベーストラック内の適切なＮＡＬユニットの位置、（ｉｉ）被参照ＮＡＬユニットからのオフセット、及び（ｉｉｉ）被参照ＮＡＬユニットからコピーするバイト数を求めるための情報を含む。

図２２は、リモートクライアントに対して送信サーバがＳＶＣベースからメディアストリームを取り出す方法２２００の１つの実施形態のフローチャートである。ブロック２２０２で、方法２２００は、メディアストリーム要求を受信する。１つの実施形態において、メディアストリーム要求は、ＨＴＴＰプロトコルによるものとすることができるが、代替の実施形態では、当技術分野で公知の異なるプロトコル（例えば、ＲＴＰ、ＲＴＳＰなど）を使用することができる。ブロック２２０４で、方法２２００は、要求されたメディアストリームに対応するエクストラクタ・トラックを選択する。例えば例証として、リモートクライアントが３０ｆｐｓＣＩＦビデオストリームを要求した場合、方法２２００は、そのメディアストリームに対応するエクストラクタ・トラックを選択する。

ブロック２２０６で、方法２３００は、選択したエクストラクタ・トラックに基づいてメディアストリームを送信する。例えば例証として、方法２２００は、ブロック２１１０で説明したようにエクストラクタを使用してメディアストリームをアセンブルし、結果として得られるビデオストリームを送信する。

図２３は、エクストラクタ・トラックを使用してメディアストリームを要求するリモートクライアントに関して、リモートクライアントに対して送信サーバがＳＶＣベーストラックからメディアストリームを取り出す方法２３００の１つの実施形態のフローチャートである。方法２３００は、ビデオストリームを記述する詳細情報が、送信サーバでなくリモートクライアントによって処理される点で方法２２００と異なる。図２３においては、リモートクライアントは、エクストラクタ・トラックを使用してＳＶＣベーストラックからビデオストリームを抽出する。ブロック２３０２で、方法２３００は、ＳＶＣベーストラックから利用可能なビデオストリームに対する要求を受信する。これに応答してブロック２３０４で、方法２３００は、ＳＶＣベーストラックビデオメタデータを送信する。１つの実施形態において、方法２３００は、図１８に示すようにビデオメタデータ１８０４−１８１０を送信するが、代替の実施形態では、ＳＶＣベーストラック内でコード化された利用可能なビデオストリームを記述する他のデータを送信する（例えば、ビデオストリームリストなどを送る）ことができる。

ブロック２３０６で、方法２３００は、エクストラクタ・トラックに対する要求を受信する。これに応答してブロック２３０８で、方法２３００は、要求されたエクストラクタ・トラックを要求側リモートクライアントに送信する。リモートクライアントは、エクストラクタ・トラックを使用して、エクストラクタ・トラックが参照側ＮＡＬユニットを含む場合、ビデオフレーム（例えば、ベーストラックからのＮＡＬユニット）を抽出する。或いは、エクストラクタ・トラックがＮＡＬユニットのコピーを含む場合、リモートクライアントは、ビデオストリームを有し、必要に応じてビデオストリームを処理することができる。

ブロック２３１０で、方法２３００は、送信されたエクストラクタ・トラックに基づいてビデオストリームフレーム要求を受信する。これに応答してブロック２３１２で、方法２３００は、要求されたビデオフレームを送信する。

図２４は、ＳＶＣベーストラックから抽出されたＳＶＣ専用コンテンツを保存する方法２４００の１つの実施形態のフローチャートである。ＳＶＣ専用コンテンツは、ＳＶＣ専用コンテンツが１つのビデオストリームを含み、ＳＶＣベーストラックが複数のビデオストリームを含むことができるという点でＳＶＣベーストラックとは異なる。ブロック２４０２で、方法２４００は、利用可能なビデオストリームのどれをＳＶＣ専用コンテンツとして保存すべきかを判断する。選択したビデオストリームに基づいて、方法２４００は、選択したビデオストリームに関連するエクストラタを決定する。ブロック２４０６で、方法２４００は、関連するエクストラクタ・トラックを使用してビデオストリームを抽出する。例えば例証として、方法２４００は、ブロック２１１０と同様にビデオストリームを抽出する。ビデオストリームを抽出した後、方法２４００は、ビデオストリームをＳＶＣ専用コンテンツとして記憶する。

ヒントのある例示的なフォーマットを以下に提供する。しかしながら、本発明は、様々なタイプのネットワークプロトコル、デジタル処理システムアーキテクチャ、メディアフォーマット、その他と共に利用して時間ベースデータの送信を行うことができる点は理解されるであろう。

代替の実施形態
本発明を幾つかの実施形態及び例示的な図に関して説明したが、当業者であれば、本発明が記載された実施形態又は図に限定されないことを理解するであろう。詳細には、本発明は、時間関連メディアデータのパケット化を可能にする幾つかの代替の実施形態において実施することができる。

従って、本発明の方法及び装置は、添付の特許請求の範囲の精神及び範囲内で修正及び改変を行い実施することができる点を理解されたい。従って、本明細書は、本発明を限定するものではなく、例示するものとみなすべきである。

付録Ａ−パケット化ヒントサンプル記述
本発明の１つの実施形態において、各ヒントトラックは、サンプル記述のテーブルを有する。ヒントトラックは通常、１つのサンプル記述を有する。本発明の１つの実施形態による、ヒントトラックについての各サンプル記述エントリのフォーマットを以下のテーブル１に記載する。

テーブル１：ヒントトラックサンプル記述フォーマット

パケット化ヒットヘッダアトムは、以下のデータ要素を含む。
フィールド記述
サンプル記述サイズ：サンプル記述内でのバイト数を指定する３２ビット整数
データフォーマット：サンプルデータ内に記憶されるヒントのフォーマットを示す３２ビット整数。ヒント形式が異なれば、異なるフォーマットを定義することができる。以下のテーブルには、定義されたフォーマットを列挙する。
予約：０にセットされる６バイト。
データ参照：このサンプル記述を使用するサンプルに関連したデータインデックスのインデックスを含む１６ビット整数。データ参照は、データ参照アトム内に記憶される。
最大パケットサイズ：このトラック内で算出されたパケットの最大サイズを示す３２ビット整数。
追加データテーブル：トラック当たりに必要とされる追加情報を含むテーブル。値は、タグ付きのエントリである。必要なエントリはない。エントリがテーブル中にない場合、適切なデフォルトを使用することができる。

追加データテーブルエントリの構造をテーブル２に示す。
テーブル２：追加データテーブルフォーマット

追加データテーブルエントリは、以下のデータ要素を含む。
フィールド記述
エントリ長：エントリ全体の長さ（長さフィールド及びタイプフィールド用８バイトを含む）をバイト単位で示す３２ビット整数。
データ形式：エントリ内のデータの意味を示す３２ビット整数。
データ：このエントリについてのデータ。データ長は、テーブルのデータ長フィールドによって示される。

以下のデータタグは、幾つかの様々なタイプのデータフォーマットタイプについて定義することができる。必要に応じて他のタグを作成することもできる。

以下のデータフォーマットタイプが定義される。新しいタイプを必要に応じて定義することができる。

以下のデータタグは「ｒｔｐ」データの１つの実施形態において利用される。

以下のデータタグは「ｒｔｐ」データについて任意選択である。

付録Ｂ−ＲＴＰについての例示的ヒントトラック
このセクションでは、ＱｕｉｃｋＴｉｍｅムービーからＲＴＰをストリーミングするためのヒントトラックフォーマットの１つの実施例を提示する。

標準ＲＴＰにおいて、各メディアストリームは通常、別個のＲＴＰストリームとして送信される。多重化は、一般に、複数のストリームから単一のＲＴＰセッションにデータをインターリーブすることによってではなく、ＩＰポートレベル多重化を用いて達成される。従って、ムービー内の各メディアトラックは、関連のＲＴＰヒントトラックを有するべきである。本発明の１つの実施形態において、各ヒントトラックは、ストリーミングしているメディアトラックに戻るトラック参照を含む。

この実施例において、パケットサイズは、ヒントトラックが作成される時点で決定される。従って、ヒントトラックのサンプル記述（この場合はプロトコルである、「コード化」に固有のフィールドを含むことができるデータ構造）において、選ばれたパケットサイズが表示される。本発明の１つの実施例において、異なるパケットサイズの選択を可能にするように、各メディアトラックについて幾つかのＲＴＰヒントトラックが提供される。他のプロトコルをパラメータ化することもできる。同様に、ＲＴＰクロック用の適切なタイムスケールが以下のサンプル記述で提供される。

ヒントトラックは、単一のトラック参照宣言によってそのベースメディアトラックと関連付けられる（ＲＴＰは、単一のＲＴＰストリーミング内のメディアの多重化を可能にするものではない）。ＲＴＰ用サンプル記述では、このヒントトラックが生成することになる最大パケットサイズが宣言される。セッション記述（ＳＡＰ／ＳＤＰ）情報は、トラック内のユーザデータアトムに記憶される。

ＲＴＰヒントトラック内の各サンプルは、所与の時間に放出されなければならないパケットのセットを送出する命令を含む。ヒントトラック内の時間は、放出時間であり、必ずしも、関連メディアのメディア時間であるとは限らない。

以下の記述においては、オブジェクトとして構造化する必要のない、この実施例の用語においてメタデータではなくメディアデータであるサンプルの内部構造を記載する。

この実施例において、各サンプルは、２つの領域、すなわちパケットを構成する命令と、これらのパケットを送るときに必要とされるあらゆる余剰データ（例えば、メディアデータの暗号化されたバージョン）とを含む。

各ＲＴＰヒントパケットは、単一のパケットを送るための情報を含む。１つの実施形態において、メディア時間を放出時間から分離するために、ＲＴＰタイムスタンプが、ＲＴＰヘッダを形成するのに必要されるデータと共に特に含まれる。しかしながら、代替の実施形態において、これは当てはまらない。他のヘッダ情報が通常は供給される。構造エントリのテーブルは、以下のように構築される。

様々な形態の構成子がある。各構成子は１６バイトであり、これは、反復を比較的簡単なものにすることができる。第１のバイトは、合併ディスクリミネータである。

即値モードでは、ペイロードに特有のヘッダ（例えばＲＴＰ Ｈ．２６１ヘッダ）の挿入が可能である。メディアが「平文で」送られるヒントトラックについては、メディアサンプルエントリは、サンプル番号、データオフセット、及びコピーする長さを与えることによって、メディアトラックからコピーするバイトを指定することができる。比較的複雑な場合（例えば、暗号化又は順方向誤り訂正）には、変形データをヒントサンプル中に置くことができ、次いで、ＲＴＰサンプル自体中のエキストラデータフィールドから提供されることになるヒントサンプルモードを使用することができる。

本発明の１つの実施例において、連続したパケットがメディアストリームから連続したバイトを送信する必要はない。例えば、Ｈ．２６１のＲＴＰ標準のパッキングに準拠するために、本発明の１つの実施例において、バイトは、１つのパケットの終わりと次のパケットの初めに送信することができる（マクロブロックの境界がバイト内にあるとき）。

付録Ｃ−データフォーマット「ｒｔｐ」についてパケット化ヒントサンプルデータ
この付録においては、本発明の１つの実施形態による、「ｒｔｐ」フォーマットについてのサンプルデータの記述を行う。「ｒｔｐ」フォーマットは、サーバがＲｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）を使用してデータを送信していると仮定している。このフォーマットでは、サーバがＲＴＰヘッダについて認知しているものと仮定するが、サーバが様々なＩＥＴＦ起案中で定義されたメディアヘッダを含む特定のメディアヘッダについて何かを認知していることは必要ではない。

本発明の１つの実施形態において、ヒントトラック中の各サンプルは、１つ又はそれ以上のＲＴＰパケットを生成することになる。ヒントトラックサンプル内のサンプルデータテーブル中の各エントリは、単一のＲＴＰパケットに対応する。ヒントトラック中のサンプルは、メディアトラック中のサンプルと正確に対応することも、対応しないこともある。本発明の１つの実施形態において、ヒントトラックサンプル中のデータは、３２ビット整合ではなく、バイト整合である。
フィールド記述

テーブル３−追加データ

１つの実施形態において、パケットエントリは、以下のデータ要素を含む。
フィールド記述

ＲＴＰヘッダ情報は、以下の要素を含む。

ＲＴＰヘッダ情報フィールドは、以下の要素を含む。

全ての未定義ビット（０から１及び４から７）は、予約されており、０にセットされる。定義されたビットの位置は、ＲＴＰヘッダ内と同じビット位置である。

テーブル４ データテーブル

エントリテーブルのデータソースフィールドは、他の１５バイトのエントリをどのように解釈すべきかを示している。値０から４が定義される。様々なデータテーブルフォーマットを以下で定義する。様々な方式があるが、様々な方式のエントリは通常、１６バイト長である。
Ｎｏ−Ｏｐデータモード
データテーブルエントリは、ｎｏ−ｏｐモードについて以下のフォーマットを有する。
フィールド記述

即値データモード
データテーブルエントリは、即値モードにおいて以下のフォーマットを有する。
フィールド記述

サンプルモード
データテーブルエントリは、サンプルモードについて以下のフォーマットを有する。
フィールド記述

圧縮ブロック当たりのバイト及び／又は圧縮ブロック当たりのサンプルが１よりも大きい場合、この比率を使用して、サンプル番号を実際のバイトオフセットに変換する。この比率モードは通常、以下のように、ＱｕｉｃｋＴｉｍｅムービー内の圧縮オーディオトラック用に使用される。
ＣＢ＝ＮＳ＊ＢＰＣＢ／ＳＰＣＢ
ここで、
ＣＢ＝圧縮バイト、
ＮＳ＝サンプル数、
ＢＰＣＢ＝圧縮ブロック当たりのバイト、
ＳＰＣＢ＝圧縮ブロック当たりのサンプル
である。
例えば、ＧＳＭ圧縮ブロックは通常、３３バイトにパックされた１６０個のサンプルである。従って、ＢＰＣＢ＝３３、及び、ＳＰＣＢ＝１６０である。ヒントサンプルは、１６１番目のメディアサンプルから始まる３３バイトのデータを要求する。第１のＱｕｉｃｋＴｉｍｅチャンクは少なくとも３２０個のサンプルを含むものと想定し、よって、このデータがチャンク１からのものであること、及びチャンク１がどこから開始するかを判断した後で、この比率を利用して、要求されたサンプルが見つけられるファイルへのオフセットを調節する。

サンプル記述モード
データテーブルエントリは、サンプル記述モードについて以下のフォーマットを有する。
フィールド記述

付録Ｄ−ＭＰＥＧ−２転送に関する例示的なヒントトラックフォーマット
このセクションでは、エレメンタリ・ストリームを保持するＱｕｉｃｋＴｉｍｅムービーからのＭＰＥＧ−２転送をストリーミングする単純なトラックフォーマットの１つの実施例を示す。

ＭＰＥＧ−２転送ストリームは、１つ又はそれ以上のエレメンタリ・ストリームの多重に関連する。このような理由から、ＭＰＥＧ−２転送のヒントトラックは、１つ又はそれ以上のメディアトラックからのこうした多重を構築する方法を記述するものである。メディアトラックとＭＰＥＧ−２転送のヒントトラックとの間は、必ずしも１対１の関係であるわけではない。各ヒントトラックは、ヒントトラックが表すエレメンタリ・ストリームに対する参照を含むことができる。本発明の１つの実施例において、ＱｕｉｃｋＴｉｍｅファイルは、様々な多重を記述する複数のこのようなヒントトラックを含むことができる。

全てのＭＰＥＧ−２転送パケットサイズは１８８バイトであるので、パケットのサイズは一般には問題にならない。本発明の１つの実施例において、各転送パケット（ＭＰＥＧ−２転送プロトコル）は、１つのメディアトラックからのペイロードデータを含む。これは、各転送パケットについての比較的簡単なヒント記述を可能にする。本発明の１つの実施例において、このような各ヒントは、どのヘッダデータが各転送パケット上に現れるかを記述し、次いで、転送パケットについて適切なメディアトラック内のペイロードを示す。ＰＳＩパケットなど、メディアトラックと対応しないパケットについては、ヒントは、１８８バイトのヘッダデータを記述することができ、あらゆるメディアトラック参照は、無関係のものとみなすことができる。メディアトラックに対応するパケットについては、ヘッダデータは、転送ヘッダ、可能な適合ヘッダ、ＰＥＳパケットを開始する転送パケットに関するＰＥＳヘッダなどの情報を考慮することができる。

（タイプ「ｓｔｓｄ」の）サンプル記述アトム内のＭＰＥＧ−２転送のヒントトラックを参照する。このアトムは、サンプル記述テーブルを含み、このテーブルのエントリは、メディアタイプに基づいて異なる。本発明の１つの実施例において、ヒントトラックは、テーブル１に示す構造から始まる。追加データテーブルは、テーブル２に示す構造を有するエントリを保持することができる。

本発明の１つの実施例において、ヒントトラックがＭＰＥＧ−２転送ヒントトラックである場合、ヒントトラックサンプル記述エントリ内のデータフォーマットは、「ｍ２ｔ」となり、最大パケットサイズは、常に１８８バイトとなる。このような記述エントリでは、以下のテーブル５から７に示すタイプを追加データテーブルで見つけることができる。

テーブル５−追加データテーブルエントリ

テーブル６−追加データテーブル内の「ｏｔｐｙ」

テーブル７−「ｔｍａｐ」追加データ内のエントリのフォーマット

本発明の１つの実施例において、各ヒントサンプルは、１つの転送パケットを記述する。各転送パケットは、ある量のヘッダデータ、次に、１つのメディアトラックからのある量のペイロードとして記述することができる。ＭＰＥＧ−２転送パケットは比較的小さいので、多数のヒントサンプルを生成することができ、従って、これらのサンプルは、できるだけ小さいことが好ましい。上記の追加データテーブルの幾つかのエントリを使用して、サンプルのサイズを最小限に抑えることができるが、このようなファクタは、サンプルエントリ内のフィールドの一部を可変のサイズとすることができる。

ペイロードデータがメディアサンプルに関して記述されることを示す、データテーブルの「ｏｔｙｐ」エントリが値０を有する場合、ヒントサンプルは、テーブル８に示す以下の形態のものとすることができる。

テーブル８−メディアサンプル参照を使用したヒントサンプルフォーマット

本発明の１つの実施例において、パケットについてのペイロードデータの長さは、ＭＰＥＧ−２では１８８からパケットのヘッダデータサイズを差し引いたものに等しいので、この長さを示す必要はない。

ペイロードデータがファイルオフセットに関して記述されることを示す、データテーブルの「ｏｔｙｐ」エントリの値が１である場合、ヒントサンプルは、テーブル９に示される以下の形態とすることができる。

テーブル９

本発明の１つの実施例において、ヒントサンプルは、これらのオフセットをメディアサンプルに関して、又はファイルオフセットに関して記述することができる。これらの各々には利点と欠点がある。ヒントサンプルがメディアサンプルに関してペイロードを指定する場合には、メディアトラックを含むファイルの追加編集に対してより弾力的であることができるが、配信には追加の処理が必要になる場合がある。ヒントサンプルがファイルオフセットに関してペイロードを指定する場合、ペイロードデータには相対的に迅速にアクセスすることができるが、メディアトラックを含むファイルを何か編集することで、ヒントが無効になることがある。

付録Ｅ−例示的なファイル
本発明の１つの実施形態による比較的短い（６フレーム）サンプルファイルを以下に提供する。ここでは、比較的重要度の低いフィールド及びオブジェクトの一部が省略され（ここでは省略記号「．．．」でマークされる）、ＲＴＰを介したストリーミングに備えたファイルの全体的構造を幾つかの架空番号で示している。メディアデータは省略され、メタデータのみが示されている。

４０１ メディアトラック用のヒントトラック
４０３ ビデオトラック
４０５ ヒントトラックサンプル

Claims (24)

1. スケーラブルなコンテンツを処理する方法であって、
   複数の動作点で前記スケーラブルなコンテンツを提示するためのサンプルを含むデータの第１のセットを記憶する段階と、
   それぞれが前記複数の動作点の１つに対応する複数のエクストラクタトラックを導出する段階と、
   前記複数の動作点に対応する利用可能なビデオストリームのリストの要求を受信する段階と、
   前記複数の動作点に対応する利用可能なビデオストリームの前記リストを送信する段階と、
   利用可能なビデオストリームの前記リストに基づいて前記複数のエクストラクタトラックの少なくとも１つの要求を受信する段階と、
   前記複数のエクストラクタトラックの前記少なくとも１つを、前記データの第１のセットと別に送信する段階であって、前記複数のエクストラクタトラックの前記少なくとも１つは前記データの第１のセットから導出されたデータの第２のセットを含み、前記データの第２のセットは前記複数の動作点の内の第１の動作点のための第１の動作点データのビデオフレームへの参照の順序付けされたリストを含み、前記第１の動作点データは前記データの第１のセットのサブセットである段階と、
   前記少なくとも１つのエクストラクタトラックにおいて識別された前記第１の動作点データの前記ビデオフレームの要求を受信する段階と、
   前記第１の動作点データの前記要求されたビデオフレームを送信する段階と、
   を含む、
   ことを特徴とする方法。
2. 前記少なくとも１つのエクストラクタトラックは、前記少なくとも１つのエクストラクタトラックの前記要求に応じて送信される、ことを特徴とする請求項１に記載の方法。
3. 前記第１の動作点データの前記ビデオフレームを送信する段階は、前記第１の動作点データの前記ビデオフレームの前記要求に応答するものである、請求項２に記載の方法。
4. 前記少なくとも１つのエクストラクタトラック及び前記第１の動作点データの前記ビデオフレームの前記要求は、リモートクライアントからメディアサーバで受信される、請求項３に記載の方法。
5. 前記複数の動作点は、前記スケーラブルなコンテンツの複数の空間解像度、または前記スケーラブルなコンテンツの複数の品質レベル、の少なくとも１つを含む、請求項１に記載の方法。
6. 前記スケーラブルなコンテンツはオーディオコンテンツ又はビデオコンテンツの少なくとも１つを含む、請求項１に記載の方法。
7. スケーラブルなコンテンツを処理する装置であって、
   複数の動作点で前記スケーラブルなコンテンツを提示するためのサンプルを含むデータの第１のセットを記憶する手段と、
   それぞれが前記複数の動作点の１つに対応する複数のエクストラクタトラックを導出する手段と、
   前記複数の動作点に対応する利用可能なビデオストリームのリストの要求を受信する手段と、
   前記複数の動作点に対応する利用可能なビデオストリームの前記リストを送信する手段と、
   利用可能なビデオストリームの前記リストに基づいて前記複数のエクストラクタトラックの少なくとも１つの要求を受信する手段と、
   前記複数のエクストラクタトラックの前記少なくとも１つを、前記データの第１のセットと別に送信する手段であって、前記複数のエクストラクタトラックの前記少なくとも１つは前記データの第１のセットから導出されたデータの第２のセットを含み、前記データの第２のセットは前記複数の動作点の内の第１の動作点のための第１の動作点データのビデオフレームへの参照の順序付けされたリストを含み、前記第１の動作点データは前記データの第１のセットのサブセットである手段と、
   前記少なくとも１つのエクストラクタトラックにおいて識別された前記第１の動作点データの前記ビデオフレームの要求を受信する手段と、
   前記第１の動作点データの前記要求されたビデオフレームを送信する手段と、
   を含む、
   ことを特徴とする装置。
8. 前記少なくとも１つのエクストラクタトラックは、前記少なくとも１つのエクストラクタトラックの前記要求に応じて送信される、ことを特徴とする請求項７に記載の装置。
9. 前記第１の動作点データの前記ビデオフレームを送信する手段は、前記第１の動作点データの前記ビデオフレームの前記要求に応答するものである、請求項８に記載の装置。
10. 前記少なくとも１つのエクストラクタトラック及び前記第１の動作点データの前記要求は、リモートクライアントからメディアサーバで受信される、請求項９に記載の装置。
11. 前記複数の動作点は、前記スケーラブルなコンテンツの複数の空間解像度、または前記スケーラブルなコンテンツの複数の品質レベル、の少なくとも１つを含む、請求項７に記載の装置。
12. 前記スケーラブルなコンテンツはオーディオコンテンツ又はビデオコンテンツの少なくとも１つを含む、請求項７に記載の装置。
13. スケーラブルなコンテンツを処理する方法であって、
    データの第１のセットの複数の動作点に対応する利用可能なビデオストリームのリストを要求する段階と、
    前記複数の動作点に対応する利用可能なビデオストリームの前記リストを受信する段階と、
    利用可能なビデオストリームの少なくとも１つに対応する複数のエクストラクタトラックの少なくとも１つを要求する段階と、
    複数の前記エクストラクタトラックの前記少なくとも１つを、データの第１のセットとは別に受信する段階であって、前記データの第１のセットは前記複数の動作点で前記スケーラブルなコンテンツを提示するためのサンプルを有し、前記受信されたエクストラクタトラックはデータの第１のセットから導出されたデータの第２のセットを含み、前記データの第２のセットは前記複数の動作点の内の第１の動作点のための第１の動作点データのビデオフレームへの参照の順序付けされたリストを含み、前記複数のエクストラクタトラックのそれぞれは前記スケーラブルなコンテンツ内の前記複数の動作点の１つに対応するものである段階と、
    前記複数の動作点の第１の動作点のための第１の動作点データであって、前記データの第１のセットのサブセットである第１の動作点データの前記ビデオフレームを、前記データの第２のセット内の参照を使用して要求する段階と、
    前記第１の動作点データの前記要求されたビデオフレームを受信する段階と、
    を含む、
    ことを特徴とする方法。
14. 前記少なくとも１つのエクストラクタトラックは、前記少なくとも１つのエクストラクタトラックの前記要求に応じて受信される、ことを特徴とする請求項１に記載の方法。
15. 利用可能なエクストラクタトラックを記述するメタデータを要求する段階、をさらに含む、
    請求項１３に記載の方法。
16. 前記少なくとも１つのエクストラクタトラック及び前記第１の動作点データの前記ビデオフレームは、メディアサーバからリモートクライアントで受信される、請求項１３に記載の方法。
17. 前記複数の動作点は、前記スケーラブルなコンテンツの複数の空間解像度、または前記スケーラブルなコンテンツの複数の品質レベル、の少なくとも１つを含む、請求項１３に記載の方法。
18. 前記スケーラブルなコンテンツはオーディオコンテンツ又はビデオコンテンツの少なくとも１つを含む、請求項１３に記載の方法。
19. スケーラブルなコンテンツを処理する装置であって、
    データの第１のセットの複数の動作点に対応する利用可能なビデオストリームのリストを要求する手段と、
    前記複数の動作点に対応する利用可能なビデオストリームの前記リストを受信する手段と、
    利用可能なビデオストリームの少なくとも１つに対応する複数のエクストラクタトラックの少なくとも１つを要求する手段と、
    複数の前記エクストラクタトラックの前記少なくとも１つを、データの第１のセットとは別に受信する手段であって、前記データの第１のセットは前記複数の動作点で前記スケーラブルなコンテンツを提示するためのサンプルを有し、前記受信されたエクストラクタトラックはデータの第１のセットから導出されたデータの第２のセットを含み、前記データの第２のセットは前記複数の動作点の内の第１の動作点のための第１の動作点データのビデオフレームへの参照の順序付けされたリストを含み、前記複数のエクストラクタトラックのそれぞれは前記スケーラブルなコンテンツ内の前記複数の動作点の１つに対応するものである手段と、
    前記複数の動作点の第１の動作点のための第１の動作点データであって、前記データの第１のセットのサブセットである第１の動作点データの前記ビデオフレームを、前記データの第２のセット内の参照を使用して要求する手段と、
    前記第１の動作点データの前記要求されたビデオフレームを受信する手段と、
    を含む、
    ことを特徴とする方法。
20. 前記少なくとも１つのエクストラクタトラックは、前記少なくとも１つのエクストラクタトラックの前記要求に応じて受信される、ことを特徴とする請求項１９に記載の装置。
21. 利用可能なエクストラクタトラックを記述するメタデータを要求する手段、をさらに含む、
    請求項１９に記載の装置。
22. 前記少なくとも１つのエクストラクタトラック及び前記第１の動作点データの前記ビデオフレームは、メディアサーバからリモートクライアントで受信される、請求項１９に記載の装置。
23. 前記複数の動作点は、前記スケーラブルなコンテンツの複数の空間解像度、または前記スケーラブルなコンテンツの複数の品質レベル、の少なくとも１つを含む、請求項１９に記載の装置。
24. 前記スケーラブルなコンテンツはオーディオ又はビデオコンテンツの少なくとも１つを含む、請求項１９に記載の装置。

Images