JP4282232B2 - メディア・データ伝送のための方法および装置 - Google Patents

Description

【０００１】
（発明の分野）
本発明は、メディア・データの時間に関係したシーケンスを伝送のために準備する方法および装置に関し、さらに詳細には、このようなメディア・データのパケット化伝送に関する。
【０００２】
（導入および背景）
ＡＩＦＦなどのオーディオ形式、ＡＶＩなどのビデオ形式、およびＲｅａｌＭｅｄｉａなどのストリーミング形式といった多種多様なファイル構造が、時間ベースのメディアを記憶するために現在使用されている。このようにファイル構造が様々である１つの理由は、それらの対象および適用性が様々であるからである。これらの形式のいくつかは、十分に比較的広く受け入れられ、適用分野が広く、ある程度実装が簡単であり、したがって、コンテンツの送達のためだけでなく、交換形式として使用することができる。こうした一般的な形式の中で第一に挙げられるのは、ＱｕｉｃｋＴｉｍｅファイル形式である。これは現在、時間ベースのデータを供給するウェブ・サイトの大部分、プロフェッショナル環境も含めたオーサリング環境の大部分、およびマルチメディアＣＤＲＯＭタイトルの大部分で使用されている。
【０００３】
ＱｕｉｃｋＴｉｍｅのメディア層は、時間ベースのマテリアル（ビデオやオーディオなど）を中心とする一般的なマルチメディア・データの効率的な表示および管理をサポートする。このメディア層では、メディア情報の記憶および交換の形式として、ＱｕｉｃｋＴｉｍｅファイル形式を使用している。この層のアーキテクチャ能力は、一般に現行の実施態様より広範であり、このファイル形式は、現行のＱｕｉｃｋＴｉｍｅの実施態様が現在必要としているより多くの情報を表現することができる。
【０００４】
一般に同期メディアのローカルなランダム・アクセスをサポートするように設計されるＡＶＩなどの形式とは異なり、ＱｕｉｃｋＴｉｍｅは、データ、関係、および一般的なマルチメディアの提示のタイミングをシステムが管理することができるようにする。詳細には、ＱｕｉｃｋＴｉｍｅファイル形式は、一般的な時間ベースのストリームの時間的な挙動を表すための構造、つまりネットワーク・パケットの時間ベースの放出、ならびにマルチメディア・データの時間ベースのローカルな提示をカバーする概念を有する。
【０００５】
現行のＱｕｉｃｋＴｉｍｅファイル形式は、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ社によって１９９６年５月のファイル形式仕様に公に記載されており、これはＱｕｉｃｋＴｉｍｅのサイト＜ｈｔｔｐ：／／ｗｗｗ．ａｐｐｌｅ．ｃｏｍ／ｑｕｉｃｋｔｉｍｅ＞で見ることができる。
【０００６】
ＱｕｉｃｋＴｉｍｅファイル形式の１つの側面として、メディア・データの物理構造（ディスク・レコード中のレイアウト）が、そのファイルについての論理構造から独立しており、かつそれによって記述されるという概念がある。このファイルは、「ムービー」メタ・データのセットによって完全に記述される。このメタ・データは、実際のメディア・データについての宣言的、構造的、および時間的な情報を提供する。
【０００７】
メディア・データは、記述データ（「ムービー」メタ・データ）と同じファイル中にあることも、その他の１つまたは複数のファイル中にあることもある。１つのファイルに構造化されたムービーは一般に「フラット」と呼ばれ、独立型である。非フラット・ムービーを構造化して、その他のファイル中のメディア・データの一部または全てを参照することもできる。
【０００８】
したがって、この形式は一般に、様々な応用分野での最適化に適している。例えば、編集（合成）するときには、編集が適用され、メディアが再度順序づけされるにつれてデータを再度書込みする必要がなく、メタ・データ・ファイルを拡張し、時間的マッピング情報を調整することができる。編集が完了すると、ローカルまたはネットワーク・アクセスのために、関連するメディア・データおよびメタ・データを単一のインタリーブ型の最適化されたファイル中に再度書込みすることができる。この構造化ファイルおよび最適化されたファイルはともに有効なＱｕｉｃｋＴｉｍｅファイルであり、どちらも検査、再生、および再加工することができる。
【０００９】
構造化（「非フラットの」）ファイルを使用することにより、同じ基本メディア・データを任意回数の提示で使用および再使用することが可能となる。以下で分かるように、供給するときにもこれと同じ利点がある。
【００１０】
編集および供給のいずれにおいても、これによって、その他のいくつかのファイルをメディア・データをコピーせずにムービーの一部分として扱うことが可能となる。したがって、編集および供給を、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍの「ａｕ」オーディオ形式やＡＶＩビデオ形式などのファイルから直接行うことができ、これらの形式の可用性が大幅に拡大される。
【００１１】
ＱｕｉｃｋＴｉｍｅファイルは、アトムと呼ばれるオブジェクトのセットに分割される。各オブジェクトはアトム・ヘッダから開始し、これは下記のようにそのサイズおよびタイプを宣言する。
class Atom {
int(32) size;
char type[4];
byte contents[];
}
【００１２】
サイズは、サイズおよびタイプのヘッダ・フィールドを含めて、バイトで表される。タイプ・フィールドは４つの文字（通常は印刷可能）であり、容易なドキュメンテーションおよび識別を可能にする。タイプ・フィールドの後のオブジェクト中のデータは、フィールド、または含まれるオブジェクトのシーケンス、あるいはその両方になることがある。
【００１３】
したがって、ファイルは、下記のように単純にオブジェクトのシーケンスである。
class File {
Atom[];
}
【００１４】
２つの重要な最上位のオブジェクトは、メディア・データ（ｍｄａｔ）およびメタ・データ（ｍｏｏｖ）である。
【００１５】
メディア・データ・オブジェクトは、実際のメディア（例えば音声サンプルのシーケンス）を含む。それらの形式はファイル形式によって制約されず、それらは通常はオブジェクトではない。それらの形式はメタ・データ中に記述され、物理的にそれらと隣接するいかなる宣言によっても記述されない。したがって、例えばモーションＪＰＥＧのみからなるムービーでは、ＪＰＥＧフレームは、余分なヘッダを介在させずに連続的にメディア・データ中に記憶される。メディア・データ・オブジェクト内のメディア・データは、複数のチャンクに論理的に分割されるが、メディア・データ内に明示的なチャンク・マーカは存在しない。
【００１６】
ＱｕｉｃｋＴｉｍｅファイルがその他のファイル中のメディア・データを参照するときには、このようなメディア・データ・ファイルはメディア・オブジェクトのコンテンツのようにフォーマットすることができるので、これらの「２次」ファイルをＱｕｉｃｋＴｉｍｅ仕様に従ってフォーマットする必要はない。ＱｕｉｃｋＴｉｍｅ形式は、メディア・データと物理的に隣接する任意のヘッダまたはその他の情報を必ずしも必要としないので、メディア・データを「外部」ヘッダを含むファイル（例えばＵＮＩＸ「ａｕ」ファイルやＡＶＩファイル）にすること、およびＱｕｉｃｋＴｉｍｅのメタ・データが適当な宣言情報を含み、「外部」ファイル中のメディア・データを参照することが可能である。このようにして、ＱｕｉｃｋＴｉｍｅファイル形式を使用して、異種形式の現行のマテリアルの本体をコピーせずに更新することができる。ＱｕｉｃｋＴｉｍｅファイル形式は、既成の形式であり、またその他の既成の形式とともに動作し、その他の既成の形式を含み、その他の既成の形式を提示する（bring forward）こともできる。
【００１７】
空きスペース（例えば編集操作によって削除された）も、オブジェクトによって記述することができる。空きスペース・オブジェクトを含むファイルを読み取るソフトウェアは、このような空きスペース・オブジェクト、ならびにそれが理解できない任意レベルのオブジェクトを無視しなければならない。これにより、新しいオブジェクトを導入することによって、実質的に任意のレベルでファイルの拡張が可能となる。
【００１８】
主要なメタ・データはムービー・オブジェクトである。ＱｕｉｃｋＴｉｍｅファイルは、下記のような、容易に位置決定することができるように通常はそのファイルの冒頭または末端にあるムービー・オブジェクトを正確に１つ有する。
class Movie {
int(32) size;
char type[4] = 'moov';
MovieHeader mh;
contents Atom[];
}
【００１９】
ムービー・ヘッダは、提示全体についての基本情報（その作成日付や、全体のタイムスケールなど）を提供する。含まれるオブジェクトのシーケンス中には、通常は、下記のような、時間的に提示されるデータを記述するトラックが少なくとも１つある。
class Track {
int(32) size;
char type[4] = 'trak';
TrackHeader th;
contents Atom[];
}
【００２０】
トラック・ヘッダは、そのトラックについての比較的基本的な情報（そのＩＤやタイムスケールなど）を提供する。トラックに含まれるオブジェクトは、その他のトラックへの参照（例えば複雑な合成のため）、または編集リストとなることもある。この含まれるオブジェクトのシーケンス中には、トラックが再生されるときに提示されるメディアを記述するメディア・オブジェクトがあることがある。
【００２１】
メディア・オブジェクトは、トラックが必要とする提示に関する宣言（例えば、それがサンプル・オーディオ、またはＭＩＤＩ、あるいは３Ｄシーンについての配向情報である）を含む。このトラックのタイプは、下記のようなそのハンドラによって宣言される。
class handler {
int(32) size;
char type[4] = 'hdlr';
int(8) version;
bit(24) flags;
char handlertype[4]; --mhlr for media handlers
char handlersubtype[4] --vide for video, soun for
audio
char manufacturer[4];
bit(32) handlerflags;
bit(32) handlerflagsmask;
string componentname;
}
【００２２】
メディア情報内にも同様に、（メディア・データをフェッチする）データ・ハンドラについてのハンドラ宣言、およびどのファイルが関連するトラックについてのメディア・データを含むかを定義するデータ情報宣言がある。この宣言を使用することにより、複数のファイルにまたがるムービーを構築することができる。
【００２３】
最低レベルでは、下記のような、トラックの時間的アスペクトをファイルに記憶されたデータと関係づけるサンプル・テーブルが使用される。
class sampletable {
int(32) size;
char type[4] = 'stbl';
sampledescription sd;
timetosample tts;
syncsampletable syncs;
sampletochunk stoc;
samplesize ssize;
chunkoffset coffset;
shadowsync ssync;
}
【００２４】
このサンプル記述は、メディアについての情報（例えばビデオで使用される圧縮形式）を含む。時間／サンプル・テーブルは、トラック中の時間を、その時間に表示すべきサンプルと（索引によって）関係づける。同期サンプル・テーブルは、これらのうちのどれがその他のサンプルに依存しない同期（キー）サンプルであるかを宣言する。
【００２５】
サンプル／チャンク・オブジェクトは、下記のように、所与のサンプルについてのメディア・データ、およびその索引が与えられたその記述をどのようにして発見するかを宣言する。
class sampletochunk {
int(32) size;
char type[4] = 'stsc';
int(8) virsion;
bits(24) flags;
int(32) entrycount;
for (int i=0; i<entrycount; i++) {
int(32) firstchunk;
int(32) samplesperchunk;
int(32) sampledescriptionindex;
}
}
【００２６】
サンプル・サイズ・テーブルは、各サンプルのサイズを示す。チャンクオフセット・テーブルは、各チャンクの冒頭の、その包含するファイル中へのオフセットを示す。
【００２７】
上述の構造をたどって所与の時間表示するための適当なデータを発見することはかなり簡単であり、一般に索引付けおよび追加（adding）を必要とする。同期テーブルを使用すると、その前の同期サンプルにバックアップすること、および「静かに」累算したデルタを所望の始点にロール・フォワードすることも可能である。
【００２８】
図１は、１つのトラックを有する単純なムービーの構造を示している。同様の図は、様々なオブジェクトのフィールドについての詳細な記述とともに、ＱｕｉｃｋＴｉｍｅファイル形式の文書に見ることができる。ＱｕｉｃｋＴｉｍｅのアトム（オブジェクト）は、ここでは灰色のボックス中のそれらの活字、およびその上の記述名で示してある。このムービーは、単一のビデオ・トラックを含む。ビデオの諸フレームは、同じファイル中にあり、単一のデータのチャンク中にある。「チャンク」は単なる論理上の構成体であり、オブジェクトではないことに留意されたい。チャンク内には、通常はそれら本来の形態で記憶されるビデオのフレームがある。ビデオ・フレーム自体の中には、ヘッダまたはフィールドは必要ない。
【００２９】
図２は、オーディオ・トラックおよびビデオ・トラックを両方とも備えた独立型ファイルを示す図である。分かりやすくするために、ここではより少数のアトムを示してあり、トラックからメディア・データ中に向かうポインタは、言うまでもなく、タイミング情報を含む通常のサンプル・テーブル宣言である。
【００３０】
ＱｕｉｃｋＴｉｍｅファイル形式は、下記を含めたいくつかの利点を有する。
１）サイズおよびビット・レートについてのスケーラビリティ。メタ・データがフレキシブルだが小型である。これにより、（例えばインターネット上の）小さなダウンロード・ムービー、ならびにいくつかのハイエンド編集システムについての基礎の提供に適するようになる。
２）物理構造が論理的および時間的構造から独立していること。これにより、そのファイルが有することになる用途に応じて様々に物理構造を最適化することが可能となる。詳細には、これは、単一のファイル形式で、オーサリングおよび編集、ダウンロードまたはＣＤＲＯＭへの配置、ならびにストリーミングに適することを意味する。
３）ファイル形式が、その形式が設計された時点では未知であった多くのタイプも含めて、非常に幅広い種類のコーデック・タイプおよびトラック・タイプを扱うことができることが分かっていること。上向き互換性がある形で発展することができるというこの分かっている能力は、記憶形式の成功に必須である。
【００３１】
ＱｕｉｃｋＴｉｍｅファイル形式では、スケーラブルな、または階層化されたコーデックをいくつかの方法で扱うことができる。スケーラビリティをサポートするストリーミング・プロトコルでは、層または帯域幅のしきい値をサンプルにタグ付けし、それらのサンプルの伝送に適するようにすることができる。
【００３２】
選択肢（alternative）（例えば様々な自然言語音声トラック）のセットを形成するトラックには、１つだけが再生のために選択されるようにタグ付けすることができる。同じ構造を使用して、ストリーミングのための選択肢を選択する（例えば言語選択）ことができる。この能力については、ＱｕｉｃｋＴｉｍｅファイル形式にさらに詳細に記述されている。
【００３３】
ＱｕｉｃｋＴｉｍｅがムービーまたはトラックを表示するときには、適当なメディア・ハンドラが特定の時間についてのメディア・データにアクセスする。メディア・ハンドラは、要求されたデータを取り出すために、データ・ストリームを正しく解釈しなければならない。例えば、ビデオ・メディアに関しては、メディア・ハンドラは、通常はいくつかのアトムを横断して、所与のメディア時間についてのサンプルの位置およびサイズを発見する。メディア・ハンドラは、
１．メディア時間座標系中の時間を決定すること、
２．時間／サンプル・アトムを検査して、指定された時間についてのデータを含むサンプルの番号を決定すること、
３．サンプル／チャンク・アトムを走査して、どのチャンクが当該のサンプルを含むかを発見すること、
４．そのチャンクへのオフセットを、チャンク・オフセット・アトムから抽出すること、ならびに
５．サンプル・サイズ・アトムを使用して、そのチャンク内のオフセットおよびサンプルのサイズを発見すること
を実行することができる。
【００３４】
ＱｕｉｃｋＴｉｍｅファイルまたはその他のタイプの時間に関係したメディア・データのシーケンスを、コンピュータ・ネットワーク（例えばインターネット）と関連づけることができるデータ通信媒体を介して伝送することがしばしば望ましい。多くのコンピュータ・ネットワークでは、ネットワーク中に伝送されるデータは、一般にパケット形態をとらなければならない。通常は、時間に関係したメディア・データのシーケンスは、ネットワークを介した伝送に適したパケット化形式にはなっていない。例えば、ＱｕｉｃｋＴｉｍｅ形式のメディア・データ・ファイルはパケット化形式ではない。したがって、ストリーミング・データと呼ばれることもあるデータを収集して、ネットワークを介して伝送するためのパケットにする必要がある。
【００３５】
時間に関係したメディア・データのシーケンスをネットワークを介して伝送する問題に対処する従来の１つの手法は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）などのネットワーク・プロトコルまたは伝送プロトコルを使用して、ネットワークを介してメディア・ファイルを送信するものである。したがって、メディア・ファイル自体が、１つのコンピュータ・システムから別のコンピュータ・システムにネットワークを介して送信される。しかし、受信側コンピュータ・システムでメディア・ファイルを保存したいという要望がないこともある。すなわち、例えば受信側コンピュータ・システムがネットワーク・コンピュータ、または記憶容量の少ないコンピュータである場合には、受信側コンピュータ・システムでメディア・ファイルが受信され、視聴されたときに、その受信側コンピュータ・システムのユーザが、そのファイルのコピーを記憶することを望まないこともある。
【００３６】
ネットワークを介してパケットで伝送するためにどのようにしてデータを収集するかという問題を解決するもう１つの代替手法は、ある特定の伝送プロトコルについてネットワーク・プロトコル・データ・ユニットをそのファイル中に含むファイルを準備するものである。ある意味では、このようなファイルは、その特定の伝送プロトコルに従って伝送されることになるのと基本的に同じ形式で記憶されたパケット化ファイルであると考えることができる。この操作を実行するには、一般に、特定のデータ伝送速度の特定のネットワーク・プロトコルおよび特定のメディア・ファイル形式についてのパケット化形態で、ファイルを記憶することが必要である。したがって、特定のデータ伝送速度の様々な伝送プロトコルそれぞれについて、ファイルは本質的にそのパケット化形態で複製されることになる。こうしたファイルの形態が固定されると、それらの適用性／互換性が制限され、それらのファイルをローカルに見ることが困難になることがある。したがって、このような手法は、様々に異なるデータ伝送速度の様々な伝送プロトコルでファイルを提供しようと試みる際の記憶要件を大幅に増加させることがある。さらに、この代替の従来の手法に従って生成された各パケット化ファイルは、一般に特定のメディア・ファイル形式に限定され、したがって、同じメディア・オブジェクト（例えばデジタル・ムービー）についてのその他のメディア・ファイル形式は、通常は送信側コンピュータ・システム上でパケット化され、記憶される。
【００３７】
時間に関係したメディア・データのシーケンスをどのようにしてストリーミングするかという問題を解決するさらに別の手法は、伝送側システムで必要となったときに、望ましい特定の伝送プロトコルに従ってメディア・データのパケット化を実行するものである。この処理は、多くの場合に、比較的長い時間を必要とし、したがって伝送側システムの性能を低下させることがある。
【００３８】
したがって、時間に関係したメディア・データのシーケンスを伝送するための改良された方法および装置が実現されることが望ましい。
【００３９】
（発明の概要）
本発明は、時間に関係したデータのデータ通信媒体を介した伝送を可能にする情報に関するものである。一実施態様では、データのセットは、時間に関係したメディア・データのシーケンスを表すパケットのセットをデジタル処理システムに生成させる少なくとも１つの命令を含む。このパケットのセットは、伝送プロトコルに関連する。このデータのセットは、時間に関係したメディア・データのシーケンスに関連する、時間に関係したデータのシーケンスを含む。
【００４０】
（詳細な説明）
本発明は、例えばビデオ、オーディオ、及びビデオとオーディオなどを含む時間に関係したメディア・データのシーケンスの、コンピュータ・ネットワーク中など通信メディアを介した伝送、特にそのパケット化伝送を可能にする方法および装置を提供するものである。
【００４１】
本発明の一実施形態では、デジタル処理システムは、時間に関係したメディア・データのシーケンスをある伝送プロトコルに従ってどのようにして伝送するかを示すデータのセットを作成する。通常は、このデータのセットは、デジタル処理システムに結合された記憶デバイスに記憶される。さらに、このデータのセットは、時間に関係したメディア・データのシーケンスに関連する、時間に関係したデータのシーケンスである。
【００４２】
本発明は、コンピュータ可読媒体に記憶される実行可能コンピュータ・プログラム命令として完全に実装することも、ソフトウェアとハードウェアの組合せとして実装することも、あるいはいくつかの実施形態では完全にハードウェアとして実装することもできる。通常は、ネットワークに結合されたサーバ・コンピュータ・システムが、ヒント・トラックと呼ばれることがあるデータのセットを作成し、このヒント・トラックをそのサーバ・コンピュータ・システムに結合された記憶デバイスに記憶することになる。クライアント・コンピュータ・システムがメディア・データ・ファイルの提示（例えばそれらを見るまたは聞くこと、あるいは視聴すること）を要求すると、サーバ・システムは、ヒント・トラックを使用して、クライアント・コンピュータ・システムに伝送するためにメディア・データをどのようにしてパケット化するかを決定する。本発明は時間に関係したメディア・データのシーケンス全般に適用可能であり、ＱｕｉｃｋＴｉｍｅは、この全般的な適用可能性の一例として本明細書に表したものであることを理解されたい。したがって、本発明は必ずしもＱｕｉｃｋＴｉｍｅに限定されるわけではないものとする。
【００４３】
図３は、本発明による方法の一例を示す図である。図３に示す方法３００は、伝送することが望ましい特定のメディア・データについてのメディア・ファイル形式を決定するステップ３０１から開始する。ステップ３０３で、使用することが望ましい１つまたは複数の特定の伝送プロトコルも決定される。ただし、ステップ３０１および３０３は、例えば常に同じメディア・ファイル形式が同じ伝送プロトコルを使用して伝送される場合には省略可能である。
【００４４】
ステップ３０５で、サーバ・コンピュータ・システムなどのデジタル処理システムが、メディア・ファイル中の時間に関係したメディア・データのシーケンスをパケット化するためのヒントを作成し、記憶する。別法として、１つのコンピュータ・システムがヒントを作成し、後に伝送プロセスで使用するためにそれらを記憶する別のシステム（サーバ・コンピュータ・システムなど）に提供することもできる。パケット化により、ステップ３０１で決定された所望の伝送プロトコルに従うネットワークまたは通信媒体を介した伝送が可能となる。本発明の一実施形態では、ヒントは、その他のトラックのメディア・データを参照するが一実施形態ではそれとは別個の、時間に関係したヒントのシーケンスのトラックとして記憶される。本発明の一実施形態では、ヒントのトラックは、それが参照するメディア・データとは別に記憶することができる。したがって、ヒントのトラックは、ヒントのトラックが参照するメディア・データを含むもう１つのファイルとは別個のファイルに記憶することも、そのメディア・データを含むファイル中の、実際のメディア・データを含むデータ領域から分離した別個のヒント領域に記憶することもできる。本発明の一実施形態では、ヒント・トラックまたはその一部分は、サーバが実行可能命令として解釈することがあり、この実行可能命令によって、サーバは、通常は時間ベースのメディア・データである（必ずしもそうであるわけではない）時間に関係したデータのシーケンスをパケット化する。本発明の一実施形態では、ヒントは、伝送側デジタル処理システムに結合された記憶デバイスに記憶される。
【００４５】
ステップ３０７で、ヒントに従ってパケット化されたデータが、サーバ・コンピュータ・システムなどの伝送側システムから受信側システムに伝送される。このメディア・データは、そのメディア・データをヒントに従ってパケット化することによって伝送される。本発明の代替の一実施形態では、サーバ・コンピュータ・システムは、ヒントを使用せず、代替のパケット化プロセスによってメディア・データを送信することにすることもできる。
【００４６】
ステップ３０９で、受信側システムが、メディア・データによって表されるメディア・オブジェクトを提示する。通常は、この提示（メディア・オブジェクトの視聴であることも、単にメディア・オブジェクトを見るだけ、または聞くだけであることもある）は、パケット化されたデータが受信側システムで受信されるにつれて実行される。パケット化されたデータは、本発明の一実施形態では受信側システムに記憶することができる（必ずしもそのようにする必要はない）。したがって、提示が終了した後で受信側システムにローカル・コピーが存在しないという点で、データの提示は短命（ephemeral）である。別の実施形態では、メディア・オブジェクトの提示は、そのメディア・オブジェクトを表すメディア・データについてのヒントを作成した後で、サーバ・システム上で行うことができる。本発明の一実施形態では、メディア・データは、ヒントに従ってパケット化するために、必ずしも（再）フォーマットやコピーなどが行われるわけではない。
【００４７】
ステップ３１１で、受信されたメディア・ファイルが受信側システムに記憶されている場合には、受信側システムは、任意選択でそのメディア・ファイルを再アセンブルすることができる。図３に示す方法の様々なステップは、上記で図示および記述した順序とは異なる順序で実行することも、それらのステップの一部を同時に実行することも、あるいはその両方を合わせて行うこともできることを理解されたい。例えば、一実施形態ではステップ３０９およびステップ３１１は、並行して行われる。
【００４８】
本発明の一実施形態による、ＱｕｉｃｋＴｉｍｅを用いた特定の実施態様について次に述べる。本発明の一実施形態では、そのファイルにローカルに（例えばサーバやジェネレータなどで）見ることも、ＱｕｉｃｋＴｉｍｅムービー内でネットワークを介してストリーミングすることもできる提示が行われる。一般に、ストリーミング・サーバ（または別のシステム）は、ストリーミングするデータ・ユニット、それらの組成およびタイミングについての情報を有さなければならない。このような情報は通常は時間的なものであるので、トラック中に記述することができる。サーバは、例えば提示を見るために使用されることになるのと同じ索引付け操作を使用することによって、パケット化を実行し、プロトコル情報を決定することができる。
【００４９】
サーバに対する命令を含むトラックは、パケットを形成および伝送するプロセス中にサーバに指示を出すデータのセットを表すので、「ヒント」トラックと呼ばれることがある。ＱｕｉｃｋＴｉｍｅファイル形式は、ネットワークを介したメディア・データのストリーミング、ならびにローカルな再生をサポートする。プロトコル・データ・ユニットを送信するプロセスは、時間ベースのデータの表示と同様に時間ベースであり、したがって時間ベースの形式で適切に記述される。ストリーミングをサポートするＱｕｉｃｋＴｉｍｅファイルまたは「ムービー」は、ストリーミングするデータ・ユニットについての情報を含む。この情報は、「ヒント」トラックと呼ばれるファイルの追加トラックに含まれる。
【００５０】
ヒント・トラックは、パケットの形成を助ける、ストリーミング・サーバ（またはその他のデジタル処理システム）に対する命令を含む。これらの命令は、サーバが（例えばヘッダ情報を）送信する、またはメディア・データのセグメントを参照するための即値データを含むことができる。本発明の一実施形態では、編集または提示情報がローカルな再生のためにＱｕｉｃｋＴｉｍｅファイル中でコード化されるのと同じ方法で、命令がＱｕｉｃｋＴｉｍｅファイル中でコード化される。編集または提示情報の代わりに、特定のネットワーク・トランスポートを使用したストリーミングに適した方法でサーバがメディア・データをパケット化できるようにすることができる情報を提供することができる。
【００５１】
本発明の一実施形態では、ローカルに再生されるか、いくつかの異なるトランスポート・タイプを介してストリーミングされるかに関わらず、同じメディア・データが、ヒントを含むＱｕｉｃｋＴｉｍｅファイル中で使用される。異なるトランスポート・タイプについての別個の「ヒント」トラックを同じファイル内に含むことができ、メディア自体の追加コピーを作成せずに、こうしたトランスポート・タイプの全てを介してメディアを再生することができる。さらに、特定のトランスポートについての適当なヒント・トラックを追加することによって、現行のメディアをストリーミングできるようにする。本発明の一態様によれば、メディア・データ自体を再キャストまたは再フォーマットする必要はない。
【００５２】
したがって、ヒント・トラック中のサンプルは一般に、パケットを形成するための命令を含む。これらの命令は、サーバが（例えばヘッダ情報を）送信する、または別のトラック中のメディア・データのセグメントを参照するための即値データを含むことができる。
【００５３】
本発明の一実施形態では、３レベル設計を利用し、下記のようになる。
１）メディア・データは、通常通りに再生や編集などを行うことができるネットワーク独立トラックのセットとして表される。
２）サーバ・ヒント・トラックについての共通の宣言および基礎構造がある。この共通の形式はプロトコル独立型であるが、どのプロトコルがサーバ・トラック中に記述されるかという宣言を含む。
３）伝送することができる各プロトコルについて、特定のサーバ・ヒント・トラックの設計がある。これらの設計は全て、同じ基本構造を使用する。例えば、ＲＴＰ（インターネット用）およびＭＰＥＧ−２トランスポート（同報通信用）、あるいは新しい標準の、またはベンダに特定のプロトコルについての設計がある。
【００５４】
本発明の一実施形態では、ヒント・トラックの指示でサーバから送信される結果生じるストリームは通常のストリームであり、必ずしもＱｕｉｃｋＴｉｍｅ情報のトレースを含まない。本発明のこの実施形態では、ＱｕｉｃｋＴｉｍｅ、あるいはその構造または宣言スタイルが、必ずしも伝送媒体（例えばネットワーク・ケーブル）上のデータ、または復号側ステーション中にある必要はない。例えば、ＲＴＰ下でストリーミングされたＨ．２６１のビデオおよびＤＶＩオーディオを使用したファイルは、本発明の一実施形態では、それらのコーディングをＲＴＰ中にパックするためのＩＥＴＦ仕様に完全に準拠したパケット・ストリームを生じることができる。
【００５５】
本発明の一実施形態では、ヒント・トラックは、提示がローカルに見られる時にヒント・トラックが基本的に受信側システムに無視されるように構築され、フラグを立てられる。
【００５６】
一実施形態では、例えばビデオやオーディオなどを含むことができる時間に関係したメディア・データのシーケンスを、デジタル処理システムによってパケット化し、その後、同じデジタル処理システム上で提示することができる。さらに、パケット化を短命にし、提示、記憶、読取りなどが行われている時間に関係したシーケンスも「実行中（ｏｎ ｔｈｅ ｆｌｙ）」にパケット化されるようにすることもできる。一実施形態では、ヒントは、コピーやフォーマットなどが行われていないメディア・データを参照することができる。例えば、ヒントが参照するメディア・データは、オリジナルの形式で読取り専用メモリなどに記憶することができる。
【００５７】
一実施形態では、パケット化を実現する同一のヒント・ルーチンが、パケット化を実行するにつれてメディアも提示する。本発明の代替実施形態では、時間に関係したメディアのパケット化ファイルは、ヒント・トラックに従って生成し、例えば後に伝送するために記憶することができる。
【００５８】
図４は、本発明の一実施形態による、メディア・データをトランスポートするためのヒント・トラックの利用方法を示している。図４では、ヒント・トラック４０１は、メディア・トラック４０３に対して示してある。どのようにしてＲＴＰパケットを形成するかを記述するヒント・トラック・サンプル４０５などの各ヒント・トラック・サンプルはヘッダを含むことができ、関連するメディア・トラック、この場合はビデオ・トラック４０３から、いくつかのデータを参照することができる。図４に示す実施形態では、メディア・データ（ビデオ・フレーム）およびＲＴＰヒントはインタリーブされており、関連するメディア・ファイルを比較的容易に読み取ることができるようになっている。この例では、各フレームは単一のＲＴＰパケットに組み込まれるものとして示してある。言うまでもなく、必要なときには、フレームをいくつかのパケットに分割することもできる。逆に、望ましい場合には、複数のフレームを単一のパケット中に置くこともでき、これは一般にオーディオ・データについて実行される。
【００５９】
上記で論じたように、上述の論理構造が物理構造を暗黙に定義する必要はない。メタ・データはメモリにキャッシュすることができ、ヒント・トラック・サンプルは、（図４に示すように）それらが参照するメディア・サンプルと物理的にインタリーブすることができる。
【００６０】
別法として、現行の提示中のメタ・データおよびメディア・データを参照および増補する、ヒント・トラックを含むメタ・データおよびメディア・データの新しいセットを書き込むこともできる。図５は、本発明の一実施形態による、別個のファイル中のメディア・データを参照するためのヒント・トラックの利用方法を示している。図５には、それ自体のメタ・データをそれぞれ備えた２つのムービー・ファイル５０２および５０４が示してある。第１のムービー・ファイル５０２はビデオ・トラックを含む。第２のムービー・ファイル５０４は、ビデオ・トラックおよびヒント・トラックを両方とも含むが、そのメタ・データは、そのビデオ・トラックについてのメディア・データが第１のムービー・ファイル５０２中にあることを宣言している。したがって、ムービー・ファイル５０４に関連するヒントも、第１のムービー５０２中のメディア・データを指している。
【００６１】
本発明の一実施形態では、メディア・ファイルは、複数のプロトコルについてのパケット化ヒント・トラックを含むことができる。したがって、各トラックは、ヒント・トラックが適しているプロトコルの宣言（および適当である場合にはプロトコルのパラメータ）を含むことができる。言うまでもなく、これらのトラックは全て、ファイル中の基本メディア・トラックからメディア・データを参照することができる。プロトコル独立性および拡張可能性を求める要望は、記載の方法で満たすことができる。
【００６２】
本発明の一実施形態では、ヒント・トラックは、メディア・トラック中の全てのデータを使用する必要はない。ヒント・トラックは、帯域幅のしきい値に達するため、またはその他の理由のために、（例えば一部のビデオ・フレームを省略することによって）データのサブセットを使用すればよい。同じプロトコルについて複数のヒント・トラックを設けることができるので、同じ基本メディア情報の様々な速度の異なるサブセットを提供することができる。したがって、本発明は、従来の方法および装置に優る改善されたスケーラビリティをもたらすことができる。
【００６３】
ヒント・トラック自体およびＱｕｉｃｋＴｉｍｅメタ・データは、一実施形態ではＱｕｉｃｋＴｉｍｅファイル中になければならないが、基本メディアは、ＱｕｉｃｋＴｉｍｅが適切にインポートおよび参照することができる任意のファイル・タイプ中に残ることができることを強調しておく。本発明の一実施形態では、ムービー・ファイル中のメタ・データは、メディア・データが別のファイル中にあることを宣言するデータ参照を含むことができる。したがって、サンプル・テーブルのオフセットおよびポインタが、この「外部」ファイル中のデータを指示することもある。したがって、本発明の一実施形態によれば、「ａｕ」オーディオ・ファイルや「ＡＶＩ」オーディオ／ビデオ・ファイル、ＭＩＤＩファイルなど、現行のレガシー形式を、基本メディア・データをコピーまたは再フォーマットする必要なく、ストリーミングすることができる。基本メディア・データが書き込まれず、単に別個のファイル中のＱｕｉｃｋＴｉｍｅ宣言およびヒント情報で増補されるだけであるので、基本メディア・データを、ＣＤＲＯＭなど読取り専用機械可読媒体上に与えることもできる。
【００６４】
本発明の一実施形態では、ヒント・トラックは、オフライン計算の結果を具現化し、通常は、パケット化、および必要なら多重化をサポートするための情報をサーバに提供するように最適化される。
【００６５】
例えばＲＴＰ（ＩＥＴＦ標準の実時間プロトコル）およびＭＰＥＧ−２トランスポートについてのヒントの例を、付録Ａ〜Ｃに示す。
【００６６】
本発明の一実施形態では、単一のファイルで、過度なスペースのオーバヘッドなしで、複数のプロトコル、またはそれらのプロトコルの複数の異なるパラメータ化についてのヒント・トラックをサポートすることができる。新しいプロトコルおよびそれらに関連するヒント・トラックは、現行のプロトコルに依拠するシステムを混乱させることなく、設計することができる。したがって、本発明は、少なくとも一実施形態では、プロトコル中立的（ｐｒｏｔｏｃｏｌ−ｎｅｕｔｒａｌ）である。
【００６７】
ＱｕｉｃｋＴｉｍｅファイル形式では、メタ・データを更新またはコピーおよび増補することによって、トラックをムービーに追加することができる。メディア・データがメタ・データとは別のファイル中にある、または最適化されたインタリーブが不要である場合には、これは比較的簡単かつ効率的な操作となることができる。
【００６８】
本発明の一実施形態では、トラックを１つしか含まず、望ましい場合にはオリジナル中のメディア・データを参照することができる新しいムービー・メタ・データのセットを構築することによって、トラックを抽出することができる。
【００６９】
例えば、本発明の一実施形態では、その他のオーディオ・トラックのセットの代替としてマークされた新しいオーディオ・トラックを追加することができる。それが言語コード（例えばフランス語やタガログ語）でもマークされている場合には、提示時に適当なトラックを選択することができる。
【００７０】
ＳＭＰＴＥ時間コード・トラックは、本発明の一実施形態による、必要が生じたときに提示、追加、または除去することができるエレメンタリ・ストリームの一例である。
【００７１】
本発明の一態様によれば、ヒント・トラックは、現行のサーバまたはローカルな再生についての互換性の問題を引き起こすことなく、新しいプロトコルのための新しい形式の開発を可能にすることができる。さらに、そのファイル形式の寿命にわたって、後方互換性を維持しながら、新しいメディア・トラックを追加することもできる。
【００７２】
本発明の一実施形態では、拡張可能性の領域としては下記が含まれる。
ａ）現在のＱｕｉｃｋＴｉｍｅファイル形式によってカバーされないメディア・タイプ（例えば実験室の機器の読み）について規定することができる新しいトラック・タイプ。
ｂ）規定することができる現行のトラックについての新しい符号化タイプ（例えばビデオまたはオーディオのコーデック）。コーデックに特定の初期化情報についての明確な備えがある。
ｃ）新しいプロトコルについて規定することができる新しいヒント・トラック・タイプ、およびメディア・データ自体についてスペースのオーバヘッドを招くことなく複数のプロトコルについてのヒント情報を含むことができるファイル。
【００７３】
読取り専用媒体上の現行のコンテンツ（例えばＣＤＲＯＭやＤＶＤなどに予めパッケージ化されたムービー）は、本発明とともに使用することができる。
【００７４】
さらに、本発明の一態様によれば、様々な「外部」ファイル形式を使用することができる。例えば、本発明の一実施形態では、現行のコンテンツがＱｕｉｃｋＴｉｍｅ形式である、またはインポートすることができる場合には、コピーまたは再フォーマットする必要なく、それを編集およびストリーミングすることができる。
【００７５】
本発明の一実施形態では、帯域幅のスケーラビリティを達成するためにコーデックがメディア・データのストライピングをサポートする場合には、これらのストライピングされた帯域幅は、複数のストリーム・トラックを使用して表すことができる。各トラックが異なる帯域幅を表すことができる。これらのトラックは、基本メディアの選択したサブセット中にグループ化することができる。
【００７６】
本発明の一実施形態では、プロトコルが帯域幅のスケーラビリティをサポートする場合には、ヒント・トラック自体が、各プロトコル・データ・ユニット（ヒント・トラック中のサンプル）についての情報を含むことができる。情報は、それを超えるとプロトコル・データ・ユニットをネットワークに送達しなければならない帯域幅のしきい値を含むことができる。したがって、ヒント・トラックは、利用可能な帯域幅を高いまたは低いなどとして示し、かつ／あるいはデータ伝送の帯域幅に関する情報を示すことができる。
【００７７】
本発明の一実施形態では、プロトコルが多重化プロトコル（例えばＭＰＥＧ−２トランスポート）である場合には、異なるデータ・レートを達成するために異なるエレメンタリ・ストリーム・トラックのサブセットを使用する、異なるヒント・トラックを構築することができる。したがって、ビット・レートの低い伝送では、一部のトラックが完全に省略されることもある。
【００７８】
本発明の一実施形態では、様々なコーデックを使用してベース・データを記録することが望ましい場合には、それらのトラックを選択肢のグループの形に形成し、１つだけを提示用に選択することができる。どのトラックを提示に使用するかを選ぶ選択は、通常はプロトコルに依存し、本明細書に記載のヒント・トラック手法を使用して達成することができる。
【００７９】
本発明の一実施形態では、暗号化をメディア・ファイルに事前に適用することもできる。この場合には、暗号化されたデータは、（ａ）オリジナルのメディア・データにリンクされた新しいエレメンタリ・ストリーム（新しいトラック）（すなわちオリジナルのメディア・データは、不要となった場合に除去することができる）、あるいは（ｂ）ヒント・トラック自体に記憶することができる。（ｂ）の場合には、実行中に、ヒント・トラックが暗号化されていないエレメンタリ・ストリームからいかなるデータも抽出しないことが可能である。このように、暗号化によってメディア・データを変形することができるので、全てのメディア・データが、ヒント・トラックならびにストリーミング・パケット・プロトコル・データ・ユニット情報中にあることもある。
【００８０】
組込み型オブジェクト・コンテンツ情報の一例として、ムービー全体および個々のトラックについてのＩＥＴＦセッション記述情報を、ＲＴＰヒント・トラックについてのメタ・データ中に、ユーザ・アトムとして記憶することができる。
【００８１】
本発明の一実施形態では、ファイル形式は、通常は、再生可能な形式のメディア・データ、およびストリーミング情報を両方とも含む。一実施形態では、メディア独立性、プロトコル独立性、およびメディアをローカルに提示する能力を保持しながら、比較的低いオーバヘッドでこの形式から直接ストリーミングすることができる。
【００８２】
本発明の一態様によれば、ヒント・トラックは、コーデック、タイミング、およびパケット化についての詳細な知識を要約して、オフライン準備プロセスにすることができる。したがって、ヒント・トラックをたどってデータ・ストリームを生成することは比較的簡単であり、ストリーミングされているメディアについての特殊な知識は必要ない。したがって、本発明の一態様によれば、例えばデータ・コンテンツの詳細からサーバを切り離すことができる。
【００８３】
本発明の一実施形態では、ヒント・トラックのセットを使用して、例えばネットワークＰＤＵを、それらを送信すべき時系列中にディスク上の論理ディスク境界にレイアウトすることによってストリーミングのために直接最適化されたファイルを構築することができる。このようなファイルは、もはや一般的な提示となることはできないが、ストリーミングすることはできる。一実施形態では、ヒント・トラックを用いて作成されたパケット化ファイルを記憶し、例えば後にストリーミングのために最適化することができる。
【００８４】
本発明の一実施形態では、外部ファイル形式をカプセル化することにより、メディア・データをその他の形式で保存しながら、依然としてＱｕｉｃｋＴｉｍｅで発行することができる。例えば、現行の形式は、適当なラッパを適用することによって新しいメディア・データ・ファイル中に直接カプセル化することも、そのまま残して、ヒント・トラックによってセグメントで、または全体として参照し、レガシー形式をコピーせずにストリーミングできるようにすることもできる。単一のムービーは、複数のレガシー形式から選択した断片（piece）を含むことができる。本発明は、ベース・メディア形式を制約しない。
【００８５】
一般的に、取込み、オーサリングおよび編集、ダウンロードおよびストリーミングに及ぶ共通の形式は、一般にフレキシビリティを有する。マテリアルは、コピーまたは再フォーマットせずに、使用後に再加工する、または複数の方法で使用することができる。本発明の一実施形態では、標準的なエディタを使用してヒント・トラックを除去し、次いで編集が完了した後で再度ヒントを付ける（re-hinting）ことによって、ヒントの付いた（hinted）マテリアルを再加工および再使用することができる。
【００８６】
ローカルに見るためにメディア・ファイルをダウンロードすることが望ましい場合には、その目的のために最適化されたインタリーブ型ファイルを構築することができ、別個の宣言ファイル中のストリーミング・メタ・データが、同じベース・メディア・データを参照する。したがって、このダウンロードはストリーミング情報を含まないことがあり、さらにメディア・データはストリーミング・サーバに一度しか存在することができない。
【００８７】
論理構造を物理構造から分離することにより、ファイルの物理構造をアプリケーション（例えば編集する、ローカルに見る、ストリーミングする）に応じて様々に最適化することができる。
【００８８】
各メディア・トラックについて複数のヒント・トラックが存在できるようにすることによって、本発明の一実施形態では、ファイルを、メディアの複数のコピーを必要とせずに、複数のプロトコルを介してストリーミングすることによって発行することができる。
【００８９】
図６は、本発明の一実施形態による、メディア・データを処理することができるコンピュータ・システムのネットワークを示す図である。図６に示すように、いくつかのクライアント・コンピュータ・システムがインターネット６２２を介して互いに結合されており、そのうちの１つまたは複数が、図３に関連して上述した一実施態様の受信側システムを表す。「インターネット」という用語は、諸ネットワークのうちのあるネットワークを指すことを理解されたい。このようなネットワークでは、情報を交換するために、ＴＣＰ／ＩＰやＡＴＭ、ＳＮＡ、ＳＤＩなど、様々なプロトコルを使用することができる。インターネットの物理的接続、ならびにインターネットのプロトコルおよび通信手続きは、当業者には周知である。インターネット６２２へのアクセスは、通常は、ＩＳＰ６２４やＩＳＰ６２６などのインターネット・サービス・プロバイダ（ＩＳＰ）によって提供される。クライアント・コンピュータ・システム６０２、６０４、６１８、６２０などのクライアント・システム上のユーザは、一般に、ＩＳＰ６２４や６２６などのインターネット・サービス・プロバイダを介してインターネットへのアクセス権を得る。インターネットにアクセスすると、クライアント・コンピュータ・システム６０２、６０４、６１８、６２０、および／またはウェブ・サーバ・システム６２８などの複数のデジタル処理システム間での情報（例えば電子メール、テキスト・ファイル、メディア・ファイルなど）の転送を容易にすることができる。例えば、クライアント・コンピュータ・システム６０２、６０４、６１８、６２０、および／またはウェブ・サーバ６２８のうちの１つあるいは複数が、クライアント・コンピュータ・システム６０２、６０４、６１８、６２０、および／またはウェブ・サーバ６２８のうちの別の１つあるいは複数に、メディア・データ（例えばビデオおよびオーディオ、あるいはビデオまたはオーディオ）を提供することができる。これは、要求に応答して実現することができる。本明細書に記述するように、このようなメディア・データは、システム６００中でヒントに従って転送することができる。このようなヒントは、本発明の一実施形態では、特定のメディア・データの形式および／または特定のデータ通信（例えばネットワーク）プロトコルに従って作成することができる。
【００９０】
ウェブ・サーバ６２８は、通常は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂのプロトコルなど、１つまたは複数のデータ通信プロトコルで動作するための少なくとも１つのコンピュータ・システムからなり、したがって、通常はインターネット６２２に結合される。任意選択で、ウェブ・サーバ６２８は、インターネットおよび／またはその他のネットワークへのアクセス権をクライアント・コンピュータ・システムに提供することができるＩＳＰの一部となることもある。クライアント・コンピュータ・システム６０２、６０４、６１８、および６２０はそれぞれ、適当なウェブ・ブライジング・ソフトウェアを用いて、ＨＴＭＬドキュメント（例えばウェブ・ページ）など、ウェブ・サーバ６２８が提供することができるデータにアクセスすることができる。このようなデータは、ＱｕｉｃｋＴｉｍｅムービーなど、クライアント・コンピュータ・システム６０２、６０４、６１８、および６２０が提示できるメディアを提供することができる。
【００９１】
ＩＳＰ６２４は、クライアント・コンピュータ・システム６０２の一部分とみなすこともできるモデム・インタフェース６０６を介して、クライアント・コンピュータ・システム６０２にインターネット接続性を与える。クライアント・コンピュータ・システムは、Ｍａｃｉｎｔｏｓｈコンピュータ、「ネットワーク」コンピュータ、ハンドヘルド／ポータブル・コンピュータ、ＷｅｂＴＶシステム、またはその他のタイプのデジタル処理システム（例えばデジタル処理能力を有するセルラ電話）など、従来のコンピュータ・システムでよい。同様に、ＩＳＰ６２６も、クライアント・コンピュータ・システム６０４、６１８、および６２０にインターネット接続性を提供するが、図６に示すように、この接続性は、クライアント・コンピュータ・システム６０２、６０４、６１８、および６２０などの様々なクライアント・コンピュータ・システム間で様々となることがある。例えば、図６に示すように、クライアント・コンピュータ・システム６０４はモデム・インタフェース６０８を介してＩＳＰ６２６に結合されるが、クライアント・コンピュータ・システム６１８および６２０はローカル・エリア・ネットワーク（ＬＡＮ）の一部分である。図６ではそれぞれモデム６０６および６０８として示すインタフェース６０６および６０８は、アナログ・モデム、ＩＳＤＮモデム、ケーブル・モデム、衛星伝送インタフェース（例えば「ＤｉｒｅｃｔＰＣ」）、無線インタフェース、またはその他の、クライアント・コンピュータ・システムなどのデジタル処理システムを別のデジタル処理システムに結合するためのインタフェースにすることができる。クライアント・コンピュータ・システム６１８および６２０は、それぞれネットワーク・インタフェース６１４および６１６を介してＬＡＮバス６１２に結合される。ネットワーク・インタフェース６１４および６１６は、イーサネット・タイプ、非同期転送モード（ＡＴＭ）、またはその他のタイプのネットワーク・インタフェースにすることができる。ＬＡＮバスは、ファイアウォールその他のインターネットに関係したサービスをＬＡＮに提供することができるゲートウェイ・デジタル処理システム６１０にも結合される。ゲートウェイ・デジタル処理システム６１０がＩＳＰ６２６に結合され、クライアント・コンピュータ・システム６１８および６２０にインターネット接続性を与える。ゲートウェイ・デジタル処理システム６１０は、例えば、従来のサーバ・コンピュータ・システムを含むことができる。同様に、ウェブ・サーバ６２８も、例えば、従来のサーバ・コンピュータ・システムを含むことができる。
【００９２】
システム６００により、クライアント・コンピュータ・システム６０２、６０４、６１８、６２０、および／またはウェブ・サーバ６２８のうちの１つあるいは複数が、クライアント・コンピュータ・システム６０２、６０４、６１８、６２０、および／またはウェブ・サーバ６２８のうちの別の１つあるいは複数に、メディア・データ（例えばビデオとオーディオ、あるいはビデオまたはオーディオ）を提供することができる。このようなデータは、例えば、クライアント・コンピュータ・システム６０２、６０４、６１８、および６２０のうちの１つまたは複数とすることができる受信側システムからの要求に応答して提供することができる。本明細書に記述するように、このようなメディア・データは、システム６００中でヒントまたはヒント・トラックに従って転送することができる。このようなヒントを、本発明の一実施形態では特定のメディア・データの形式および／または特定のデータ通信（例えばネットワーク）プロトコルに従って作成し、本発明の一態様によればメディア・データのパケット化を可能にすることができる。
【００９３】
図７は、本発明の一実施形態に従って使用することができるデジタル処理システムを示すブロック図である。例えば、図７に示すデジタル処理システム６５０は、クライアント・コンピュータ・システム、ウェブ・サーバ・システム、従来のサーバ・システムなどとして使用することができる。さらに、デジタル処理システム６５０を使用して、ＩＳＰ６２４や６２６などのインターネット・サービス・プロバイダの１つまたは複数の機能を実行することができる。デジタル処理システム６５０は、モデムまたはネットワーク・インタフェース６６８を介して外部システムとインタフェースをとられることができる。モデムまたはネットワーク・インタフェース６６８は、デジタル処理システム６５０の一部分とみることができることを理解されたい。モデムまたはネットワーク・インタフェース６６８は、アナログ・モデム、ＩＳＤＮモデム、ケーブル・モデム、トークン・リング・インタフェース、衛星伝送インタフェース、無線インタフェース、またはその他の、複数のデジタル処理システム間にデータ通信リンクをもたらすインタフェースにすることができる。
【００９４】
デジタル処理システム６５０はプロセッサ６５２を含み、これは、１つまたは複数のプロセッサを表すことができ、Ｍｏｔｏｒｏｌａ ｐｏｗｅｒＰＣプロセッサやＩｎｔｅｌ Ｐｅｎｔｉｕｍ（またはｘ８６）プロセッサなど、１つまたは複数の従来タイプのこのようなプロセッサを含むことができる。メモリ６５４は、バス６５６を介してプロセッサ６５２に結合される。メモリ１５５は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）となる、かつ／またはスタティックＲＡＭ（ＳＲＡＭ）を含むことができる。プロセッサは、メモリ６５４の一部分とみることも、メモリ６５４から分離しているとみなすこともできるその他のタイプの記憶領域／メモリ（例えばキャッシュ、フラッシュ・メモリ、ディスクなど）に結合することもできる。
【００９５】
バス６５６はさらに、プロセッサ６５２を、ディスプレイ制御装置６５８、マス・メモリ６６２、モデムまたはネットワーク・インタフェース６６８、および入出力（Ｉ／Ｏ）制御装置６６４に結合する。マス・メモリ６６２は、磁気式、光学式、光磁気式、テープ、および／またはその他のタイプの、情報を記憶するための機械可読媒体／デバイスを表すことができる。例えば、マス・メモリ６６２は、ハードディスク、読取り専用または書込み可能の光学ＣＤなどを表すことができる。ディスプレイ制御装置６５８は、陰極線管（ＣＲＴ）ディスプレイ、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ、またはその他のタイプのディスプレイ・デバイスを表すことができるディスプレイ６６０を、従来の方法で制御する。Ｉ／Ｏ制御装置６６４は、１つまたは複数のキーボード、マウス／トラックボールその他のポインティング・デバイス、磁気ディスク・ドライブおよび／または光ディスク・ドライブ、プリンタ、スキャナ、デジタル・カメラ、マイクロフォンなどを表すことができるＩ／Ｏデバイス６６６を制御する。
【００９６】
デジタル処理システム６５０は、システムの単なる一例を表すものであり、多数の様々な構成およびアーキテクチャを有することができ、本発明とともに利用することができることを理解されたい。例えば、ＭａｃｉｎｔｏｓｈおよびＩｎｔｅｌのシステムは、周辺バスや専用キャッシュ・バスなど、複数のバスをしばしば有する。一方、本発明のデジタル処理システムとして使用することができるネットワーク・コンピュータは、例えば、ハード・ディスクその他の大容量記憶デバイス含まないことがあるが、モデムまたはインタフェース６６８などのネットワーク接続から、プロセッサ６５２で処理すべきルーチンおよび／またはデータを受信することができる。同様に、当技術分野で既知のＷｅｂＴＶシステムは、本発明のデジタル処理システムとみることができるが、このシステムはＩ／Ｏデバイス６６６に関連して上述したデバイスなどの、１つまたは複数のＩ／Ｏデバイスを含まないことがある。さらに、セルラ電話および／またはページングの能力を利用することができる携帯用の通信およびデータ処理システムが、本発明とともに使用することができるデジタル処理システムとみることができる。
【００９７】
図７に示すシステム６５０では、マス・メモリ６６２（および／またはメモリ６５４）は、本発明に従って（例えばヒントを介して）処理することができるメディア（例えばビデオ、オーディオ、ムービーなど）を記憶することができる。別法として、メディア・データは、例えばモデムまたはネットワーク・インタフェース６６８を介してデジタル処理システム６５０によって受信し、ディスプレイ６６０および／またはＩ／Ｏデバイス６６６によって記憶および／または提示することこともできる。一実施形態では、パケット化されたメディア・データを、ＬＡＮおよび／またはインターネットなどのデータ通信ネットワークを介してヒント・トラックに従って伝送することができる。一方、プロセッサ６５２は、１つまたは複数のルーチンを実行して、１つまたは複数のヒント・トラックを有するファイルを使用する、あるいは別法として、１つまたは複数のヒント・トラックを作成し、ヒント・トラックに従って提示またはパケット化するためにメディア（例えば事前にパッケージ化されたムービー、オーディオ・ファイル、ビデオ・ファイルなど）を処理することができる。このようなルーチンは、マス・メモリ６６２、メモリ６６４、および／またはデジタル処理システム６５０がアクセスできる別の機械可読媒体に記憶することができる。一実施形態では、デジタル処理システム６５０は、ヒント・トラックが組み込まれたメディア・データを処理することができる。同様に、このような組込み型メディア・データは、マス・メモリ６６２、メモリ６６４、および／またはデジタル処理システム６５０がアクセスできる別の機械可読媒体に記憶することができる。
【００９８】
図８は、本発明の一実施形態による、ヒントを利用してメディア・データを転送するシステムを示すブロック図である。図８に示すシステム６８０は、データ通信リンク６８６を介してサーバ６９４に結合されたクライアント・データ処理システム６８２として示される受信側システムを含む。サーバ６９４および／またはクライアント・データ処理システムは、例えば図６および７に関連して述べたデバイス／システムの一方またはその組合せを表すことができる。
【００９９】
サーバ６９４は、ヒント生成および処理ユニット６８８と、メディア処理ユニット６９０と、データ通信ユニット６９２とを含み、これらはそれぞれ、ハードワイヤド回路または機械実行可能命令、あるいはそれらの組合せを含むことができる。さらに、このようなハードワイヤド回路および／または機械実行可能命令の少なくとも一部分は、ヒント生成および処理ユニット６８８、メディア処理ユニット６９０、ならびにデータ通信ユニット６９２の組合せの間で共用することができる。一実施形態では、少なくとも１つのプロセッサに結合された、適当なルーチンおよび／またはデータをその中に記憶した少なくとも１つの記憶領域／メモリ（例えば機械可読媒体）を利用して、少なくとも部分的には、ヒント生成および処理ユニット６８８、メディア処理ユニット６９０、ならびにデータ通信ユニット６９２の１つまたはその組合せを実装する。
【０１００】
一実施形態では、ヒント生成および処理ユニット６８８は、メディア処理ユニット６９０によって処理されるメディア・データをパケット化するためのヒントを作成し、記憶する。上述のように、ヒントは、メディア・ファイルに関連する別個のファイルとして生成および記憶することも、メディア・データに組み込むこともできる。複数のメディア形式が処理される場合には、ヒント生成および処理ユニット６８８は適当な形式を考慮してヒントを生成することができる。メディア形式についての情報は、メディア・データ（例えばビデオ、オーディオ、またはビデオおよびオーディオのメディア・ファイルなど）も与えることができるメディア処理ユニット６９０が提供することができる。同様に、データ通信ユニット６９２は、ヒントに従ってパケット化されたこのようなメディア・データをデータ通信リンク６８６を介して交換するための１つまたは複数のデータ通信（例えばネットワーク）プロトコルを提供することができる。したがって、ヒント生成および処理ユニットは、メディア処理ユニット６９０から提供されたメディア形式情報、およびデータ通信ユニット６９２から提供されたデータ通信プロトコル情報に基づいて、クライアント・データ処理システム６８２などの受信側デジタル処理システムに転送するための、適当なヒントと、メディアおよび／またはヒントのパケット化とを決定することができる。一実施形態では、メディアおよびヒントのストリーミングは、ＱｕｉｃｋＴｉｍｅ形式に従って行われる。
【０１０１】
データ通信リンク６８６を介してメディア・データおよびヒント・パケットを受信したのに応答して、クライアント・データ処理システム６８２は、そのメディア・データによって表されるメディア・オブジェクトを提示することができる。このような提示は、上述のように短命に実行することができる。本発明の一実施形態では、メディア・データは、任意選択で、クライアント・データ処理システム６８２が記憶し、後に例えば提示および／または伝送のためにクライアント・データ処理システム６８２が再アセンブルすることができる。
【０１０２】
図９は、本発明の一実施形態による、ヒントを利用してメディア・データを転送するシステムを示すブロック図である。詳細には、図９は、ジェネレータと呼ばれる別個のデジタル処理システムがヒント（またはヒント・トラック）を生成し、クライアント・コンピュータ・システムなど別のシステムに転送するためにヒントを使用してメディア・データをパケット化するサーバなど別のシステムに提供することができる、本発明の一実施形態を示している。データ通信リンク６８６を介してクライアント・データ処理システム６８２とデータを交換することができるサーバ７００を含むシステム６９６が示してある。ただし、図９に示す実施形態では、サーバ７００はヒントを生成しない。そうではなく、データ通信リンク７０８を介してサーバ７００に結合されたジェネレータ７１０が、ヒント生成ユニット７１２を含み、メディア・データをパケット化するために使用されるヒントを生成する。
【０１０３】
一実施形態では、システム６９６の動作は以下のようになる。サーバ７００が、メディア・データを含む１つまたは複数のメディア・ファイルについてのヒントを生成するようジェネレータ７１０に要求する。例えば、メディア・ファイルは、サーバ７００中の機械可読媒体上に記憶することができる。この要求は、メディア・ファイルの形式、ならびに／あるいはメディア・データおよび／またはその他のデータを伝送するためのデータ通信プロトコルを示す情報を含むことができる。データ通信プロトコルは、データ通信リンク６８６と関連づけることができ、データ通信リンクは、本発明の一実施形態では、サーバ７００とクライアント・データ処理システム６８２の間でのメディア・データおよび／またはその他のデータの交換を容易にするように、特定の物理的および論理的特性を有するネットワーク接続と関連づけることができる。要求に応答して、ヒント生成ユニット７１２は、時間に関係したヒント・トラックと関連づけることができる適当なヒントを生成し、そのヒントをサーバ７００に提供する。データ通信リンク７０８を介してジェネレータ７００からヒントを受信したのに応答して、サーバ７００、および詳細にはヒント処理ユニット７０２は、ヒントを使用して、クライアント・データ処理システム６８２に伝送するためにメディア・データをパケット化する。
【０１０４】
メディア・データおよびヒント・パケットをデータ通信リンク６８６を介して受信したのに応答して、クライアント・データ処理システム６８２は、メディア・データによって表されるメディア・オブジェクトを提示することができる。このような提示は、上述のように短命に実行することができる。本発明の一実施形態では、メディア・データは、任意選択でクライアント・データ処理システム６８２が記憶し、後に例えば提示および／または伝送のためにクライアント・データ処理システム６８２が再アセンブルすることができる。
【０１０５】
図１０は、本発明の一実施形態による、メディア・データ伝送を実現するためのヒントを生成する方法を示す流れ図である。ステップ７２０で、複数の形式が使用される場合には、伝送すべきメディア・データのメディア形式を決定する。形式が１つしか使用されない場合には、７２０は実行しなくてもよい。ステップ７２２で、やはり複数のプロトコルを使用することができるものと仮定して、適当なデータ通信プロトコルを決定する。ステップ７２４で、メディア形式およびデータ通信プロトコル（その一方または両方が選択／構成されている可能性がある）に基づいて、メディア・データ伝送に関係するヒント（例えばヒント・トラック）を作成し、記憶する。
【０１０６】
任意選択のステップ７２６で、別のデジタル処理システムにヒントを伝送することができる。本発明の一実施形態では、例えば、図１０の方法は、少なくとも部分的には、１つのデジタル処理システム（例えばサーバ）によって独占的に実行することができる。代替実施形態では、図１０の方法は、少なくとも部分的には、２つ以上のデジタル処理システムによって実行することができる。例えば、メディア・データの属性は、サーバまたはその他のシステムから、ジェネレータなど別のデジタル処理システムに提供することができる。これに応答して、ジェネレータは、その属性に基づいて、適当なメディア形式、データ通信プロトコル、およびメディア・データをパケット化するためのヒントを決定することができ、これらはサーバに記憶することができる。別法として、サーバは、適当なメディア形式およびプロトコルをジェネレータに提供することができ、次いでジェネレータがヒントを生成することもできる。ジェネレータは、サーバまたはその他のデジタル処理システムにヒントを伝送することができ、デジタル処理システムはそれらのヒントに従ってメディアをパケット化することができる。
【０１０７】
図１１は、本発明の一実施形態による、受信側システムが受信したメディア・データをヒントに従って処理する方法を示す流れ図である。ステップ７３０で、ヒントまたはヒント・トラックに従って受信側システムに伝送されたメディア・データを、受信側システムが受信する。一実施形態では、受信側システムは、パケット化されたメディア・データ、ならびにパケット化されたヒント・トラックを受信することができる。ヒント・トラックは、本発明の一実施形態では、メディア・データの少なくとも一部分と関連づけることができる。このようなデータは、受信側システムが行うことができる要求に応答して、受信側システムが受信することができる。例えば、一実施形態では、受信側システムは、クライアント・コンピュータ・システムであることがあり、メディア・データを求める要求はサーバまたはその他のデジタル処理システムに対して行われることがある。これに応答して、サーバは、メディア・データをパケット化するためのヒントを生成し（またはサーバの代わりに別のデジタル処理システムによって生成されていることもある）、ヒントを含むことができるパケット化されたメディア・データを受信側システムに伝送することができる。
【０１０８】
ステップ７３２で、受信側システムで受信されたメディア・データが表すメディア・オブジェクトが、受信側システムで提示される。例えば、メディア・データは、受信側システムで例えばディスプレイおよびスピーカによって「提示」されるビデオ、オーディオ、またはそれらの組合せを含むことができる。上述のように、メディア・データは、ＱｕｉｃｋＴｉｍｅムービーと関連することもある。
【０１０９】
任意選択で、ステップ７３４で、ヒントを含むことができるメディア・データは、メディア・ファイルとして受信側システムが記憶することができる。したがって、本発明の代替実施形態では、ステップ７３２は、メディア・データを受信するにつれて実行しなくてもよい、あるいはステップ７３４の前後に、またはそれと平行して実行することができる。
【０１１０】
ステップ７３４で、記憶されたメディア・ファイルを、任意選択で再アセンブルおよび／または提示することができる。したがって、ステップ７３２は、ステップ７３４の後で実行することができる。
【０１１１】
図１２は、本発明の一実施形態による、ジェネレータなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例である。図１２に示し、また図１２に関連して後述するエレメントを記憶する実際のメモリは、１つまたは複数のディスク（例えば磁気、光、光磁気など）、図７に関連して上述したメモリ６５４および／またはマス・メモリ６６２など、１つまたは複数のエレメントとなることがあることを理解されたい。さらに、図１２に示す機械可読記憶媒体と関連づけられたジェネレータがネットワーク・コンピュータである一実施形態では、機械可読記憶媒体のエレメントの１つまたは複数は、別のデジタル処理システムに記憶し、ジェネレータにダウンロードすることができる。さらに、機械可読記憶媒体に関連して述べるエレメントは、いずれかの時点で、不揮発性マス・メモリ（例えばハード・ディスク）に記憶することができる。逆に、その他の時点で、機械記憶媒体のエレメントは、ＤＲＡＭやＳＲＡＭ、ディスクなど様々な記憶領域の間で分配することもできる。
【０１１２】
図１２は、機械可読記憶媒体７４０を示している。一実施形態では、機械可読記憶媒体は、本発明の１つまたは複数の方法に従って、ヒントまたはヒント・トラックを生成するデジタル処理システム、すなわちジェネレータによって少なくとも部分的に利用される。ジェネレータは、図８に関連して述べたように、ヒント・トラックに従ってメディア・データを伝送するデジタル処理システム中に一体化することも、図９に関連して述べたように、ヒントを作成し、サーバなどヒントを利用してメディア・データをパケット化および伝送する別のデジタル処理システムに提供するデジタル処理システムであることもできる。
【０１１３】
図１２に示すように、機械可読記憶媒体７４０は、通常はいくつかのエレメントを含む。例えば、機械可読記憶媒体７４０は、ジェネレータ・オペレーティング・システム（ＯＳ）７４２で示すように、オペレーティング・システムの機能をジェネレータに提供するソフトウェアを含む。ネットワーク伝送ルーチン７４８は、ルーチンやプロトコルなど、ジェネレータがデータ通信リンクを介してデータを伝送および受信することができるようにするデータ通信機能を提供する。
【０１１４】
さらに、機械可読記憶媒体７４０は、メディア伝送に関連したヒントを作成するためのルーチンおよびデータを含む。したがって、機械可読記憶媒体７４０は、任意選択で、ヒント作成ルーチン７４４がヒントを作成するために必要となることがある１つまたは複数のデータ通信プロトコルおよびメディア形式に関係する情報を提供することができる情報７５０を含むことができる。例えば、情報７５０は、ＱｕｉｃｋＴｉｍｅムービー、ＲＴＰ、ＭＰＥＧなどに関係する情報を含むことができる。ただし、このような情報は、少なくとも部分的にヒント作成ルーチン７４４に一体化する、かつ／または遠隔のデジタル処理システムからジェネレータに提供することができる。
【０１１５】
ヒント作成ルーチン７４４によって作成されたヒントは、作成されたヒント７４６として記憶し、かつ／または他の箇所（例えばサーバであることもある遠隔のデジタル処理デバイス）に記憶／伝送することができる。ヒントは、やはり時間に関係したメディア・データ（例えばビデオ、オーディオ、ビデオとオーディオなど）をパケット化および伝送するための、時間に関係したヒント・トラックである。
【０１１６】
ジェネレータに関連して機械可読記憶媒体７４０について述べたが、媒体７４０は、少なくとも部分的には、いくつかのタイプのデジタル処理システムやデータ記憶媒体などの一部とすることもできる。例えば、機械可読記憶媒体７４０は、少なくとも部分的に、サーバまたはその他のデジタル処理システムの一部分として含まれることもある。さらに、機械可読記憶媒体７４０は、少なくとも部分的に、１つまたは複数のディスクその他の機械可読媒体上のソフトウェア・ユーティリティの一部分として含まれることもある。
【０１１７】
図１３は、本発明の一実施形態による、サーバなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例である。図１３に示し、また図１２に関連して後述するエレメントを記憶する実際のメモリは、１つまたは複数のディスク（例えば磁気、光、光磁気など）、図７に関連して上述したメモリ６５４および／またはマス・メモリ６６２など、１つまたは複数のエレメントとなることがあることを理解されたい。さらに、図１３に示す機械可読記憶媒体と関連づけられたサーバがネットワーク・コンピュータである一実施形態では、機械可読記憶媒体のエレメントの１つまたは複数は、別のデジタル処理システムに記憶し、ジェネレータにダウンロードすることができる。さらに、機械可読記憶媒体に関連して述べるエレメントは、いずれかの時点で、不揮発性マス・メモリ（例えばハード・ディスク）に記憶することができる。逆に、その他の時点で、機械記憶媒体のエレメントは、ＤＲＡＭやＳＲＡＭ、ディスクなど様々な記憶領域の間で分配することもできる。
【０１１８】
図１３は、機械可読記憶媒体７６０を示している。一実施形態では、機械可読記憶媒体は、本発明の１つまたは複数の方法に従って、データ通信陸上を伝送するためにメディア・データをパケット化するために少なくとも部分的に利用される。機械可読記憶媒体７６０は、図８に関連して述べたサーバ６９４などのサーバと関連し、ヒント・トラックに従ってヒント・トラックを作成し、メディア・データを伝送するためのルーチンを含むことができる。別の実施形態では、機械可読記憶媒体７６０は、図９に関連して述べたサーバ７００などのデジタル処理システムと関連することができ、ジェネレータなどのデジタル処理システムがヒントを作成するためのルーチンを含み、サーバは、機械可読記憶媒体７６０から提供されたルーチンによって処理されたヒントを使用して、メディア・データをパケット化し、伝送することができる。
【０１１９】
機械可読記憶媒体７６０は、いくつかのエレメントを含む。例えば、機械可読記憶媒体７６０は、サーバ・オペレーティング・システム（ＯＳ）７６２で示すように、オペレーティング・システムの機能をサーバに提供するソフトウェアを含む。ネットワーク伝送ルーチン７６８は、ルーチンやプロトコルなど、サーバがデータ通信リンクを介してデータを伝送および受信することができるようにするデータ通信機能を提供する。
【０１２０】
さらに、機械可読記憶媒体７６０は、メディア・データをパケット化するメディア・パケット化ルーチン７７０を含み、これは時間に関係し、ヒントに基づいており、やはりパケット化することができる。したがって、機械可読記憶媒体７６０は、メディア・データ（例えばＱｕｉｃｋＴｉｍｅムービーやその他のメディア・トラックとなることがある）およびヒント（例えばヒント・トラック）をそれぞれ記憶するために、メディア・データ記憶領域７６４およびヒント記憶領域７６６を含む。ヒントは、通常はやはり時間に関係しているメディア・データ（例えばビデオ、オーディオ、ビデオおよびオーディオ）をパケット化および伝送するための時間に関係したヒント・トラックを含むことができる。一実施形態では、ヒント・トラックは、メディア・データ・パケットとは別個にパケット化される。一実施形態では、ヒントは、別個のメディア・ファイル中にあることもあるメディア・データ（例えば特定のパケット）を識別するポインタ情報を含む。
【０１２１】
図１４は、本発明の一実施形態による、受信側システムやその他のデジタル処理システムなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例である。図１４に示し、また図１４に関連して後述するエレメントを記憶する実際のメモリは、１つまたは複数のディスク（例えば磁気、光、光磁気など）、図７に関連して上述したメモリ６５４および／またはマス・メモリ６６２など、１つまたは複数のエレメントとなることがあることを理解されたい。さらに、図１４に示す機械可読記憶媒体と関連づけられた受信側システムがネットワーク・コンピュータである一実施形態では、機械可読記憶媒体のエレメントの１つまたは複数は、別のデジタル処理システムに記憶し、受信側システムにダウンロードすることができる。さらに、機械可読記憶媒体に関連して述べるエレメントは、いずれかの時点で、不揮発性マス・メモリ（例えばハード・ディスク）に記憶することができる。逆に、その他の時点で、機械記憶媒体のエレメントは、ＤＲＡＭやＳＲＡＭ、ディスクなど様々な記憶領域の間で分配することもできる。
【０１２２】
図１４は、機械可読記憶媒体７８０を示している。一実施形態では、この機械可読記憶媒体は、本発明の１つまたは複数の方法に従ってパケット化されたメディア・データを処理するために少なくとも部分的には利用される。機械可読記憶媒体７８０は、図８および９に関連して述べたクライアント・データ処理システム６８２などの受信側システムと関連し、ヒントに従って伝送／受信されたメディア・データを提示するルーチンを含むことができる。別法として、機械可読記憶媒体７８０は、そこに組み込まれたヒント（例えばヒント・トラック）を有するメディア・データを含むことができる。このような組込み型のメディア・データは、機械可読記憶媒体７８０などの機械可読記憶媒体上に記憶されたルーチンによって事前にパッケージ化または生成することができる。
【０１２３】
機械可読記憶媒体７８０は、いくつかのエレメントを含むことができる。例えば、機械可読記憶媒体７８０は、サーバ・オペレーティング・システム（ＯＳ）７７２で示すように、オペレーティング・システムの機能を受信側システムに提供するソフトウェアを含む。ネットワーク伝送ルーチン７８２は、ルーチンやプロトコルなど、サーバがデータ通信リンクを介してデータを伝送および受信することができるようにするデータ通信機能を提供する。
【０１２４】
さらに、機械可読記憶媒体７８０は、ヒントに従ってパケット化されたメディア・データを提示するためのメディア提示ルーチン７７８を含む。したがって、機械可読記憶媒体７８０、および詳細にはメディア提示ルーチン７７８は、オーディオおよび／またはビデオ・データの圧縮解除、ビデオの表示、ならびに／あるいはオーディオの再生などのためのルーチンを含むことができる。さらに、メディア提示ルーチン７７８は、通常は、メディア・データに関連するヒントの処理を実現する。一実施形態では、ヒントは、メディアが提示される際に単純に無視される。
【０１２５】
任意選択で、機械可読記憶媒体７８０は、ヒントに従ってパケット化されているメディア・データをメディア・データ７７４として記憶し、記憶したメディア・データを（例えば提示または伝送するために）再アセンブルするためのメディア・データ再アセンブリ・ルーチン７７６を含むことができる。
【０１２６】
図１５は、本発明の一実施形態による、メディアおよびヒント情報が記憶／トランスポートされたデータ記憶および／または通信媒体を示す図である。本発明に従ってパケット化されたメディア・データ・パケット８０４およびヒント・パケット８０６を記憶およびトランスポートすることができる様々なタイプのトランスポートおよび／または記憶媒体を表す、データ記憶および／または通信媒体（媒体）８００が示してある。例えば、媒体８００は、図７に関連して上述したマス・メモリ６６２および／またはメモリ６５４を表すことができる。媒体８００は、図６に示すＬＡＮバス６１２や、メディアおよび／またはその他の情報を表すデータ／信号をトランスポートするためのデータ通信リンク６８６などの通信媒体を表すこともできる。
【０１２７】
ヒント・パケット８０６およびメディア・パケット８０４は、１つのパケットに一体化することも、図１５に示すように別々に記憶および／またはトランスポートすることもできる。さらに、ヒント・パケット８０６およびメディア・パケット８０４は、本明細書に記載の形式や、その他のメディア形式、ネットワーク・プロトコル、および／またはデジタル処理デバイスのアーキテクチャに関連する形式など、いくつかのタイプの形式を具現化することができる。
【０１２８】
以下に、いくつかのヒントの形式の例を与える。ただし、本発明は、時間に関係したデータの電送を実現するために、様々なタイプのネットワーク・プロトコル、デジタル処理システム・アーキテクチャ、メディア形式などとともに利用することができることを理解されたい。
【０１２９】
（代替実施形態）
いくつかの実施形態およびそれを図示する図に関連して本発明について述べたが、本発明は記載の実施形態または図に限定されないことを当業者なら理解されたい。詳細には、本発明は、時間に関係したメディア・データのパケット化を実現するいくつかの代替実施形態で実施することができる。
【０１３０】
したがって、本発明の方法および装置は、添付の特許請求の範囲の趣旨および範囲内で修正および改変を加えて実施することができることを理解されたい。したがって、本記述は、本発明を限定するものではなく、例示するものとしてみなすべきものである。
【０１３１】
付録Ａ−パケット化ヒントのサンプル記述
本発明の一実施形態では、各ヒント・トラックは、サンプル記述のテーブルを有する。ヒント・トラックは、通常は１つのサンプル記述を有する。本発明の一実施形態による、あるヒント・トラックについてのサンプル記述エントリそれぞれについての形式を、以下のテーブル１に記載する。
【表１】

【０１３２】
パケット化ヒント・ヘッダ・アトムは、以下のデータ・エレメントを含む。
フィールド記述；
サンプル記述サイズ：サンプル記述中のバイト数を指定する３２ビット整数。
データ形式：サンプル・データ中に記憶されたヒントの形式を指示する３２ビット整数。異なるヒント・タイプには異なる形式を定義することができる。以下のテーブルに定義された形式を列挙する。
予約：０にセットされる６バイト。
データ参照：このアンプル記述を使用するサンプルに関連するデータ索引の索引を含む１６ビット整数。データ参照はデータ参照アトムに記憶される。
最大パケット・サイズ：このトラック中で計算されるパケットの最大サイズを示す３２ビット整数。
追加データ・テーブル：トラックごとに必要とされる追加情報を含むテーブル。その値は、タグ付きのエントリである。必要なエントリはない。このテーブル中にエントリが存在しない場合には、妥当なデフォルトを使用することができる。
【０１３３】
追加データ・テーブルの構造をテーブル２に示す。
【表２】

【０１３４】
追加データ・テーブルのエントリは、以下のデータ・エレメントを含む。

【０１３５】
以下のデータ・タグは、いくつかの様々なタイプのデータ形式について定義することができる。必要に応じてその他のタグを作成することもできる。

【０１３６】
以下のデータ形式タイプが定義される。必要に応じて、新しいタイプを定義することができる。

【０１３７】
「ｒｔｐ」データについての一実施例では、以下のデータ・タグが利用される。

【０１３８】
以下のデータ・タグは「ｒｔｐ」データについて任意選択である。

【０１３９】
付録Ｂ−ＲＴＰについてのヒント・トラックの例
この節では、ＱｕｉｃｋＴｉｍｅムービーからＲＴＰをストリーミングするためのヒント・トラック形式の一例を与える。
【０１４０】
標準的なＲＴＰでは、各メディア・ストリームは、通常は別個のＲＴＰストリームとして送信される。多重化は、一般に、複数のストリームからのデータを単一のＲＴＰセッション中にインタリーブするのではなく、ＩＰのポート・レベルの多重化を使用することによって達成される。したがって、ムービー中の各メディア・トラックは、関連するＲＴＰヒント・トラックを有さなければならない。本発明の一実施例では、各ヒント・トラックは、それがストリーミングしているメディア・トラックへのトラック参照を含む。
【０１４１】
この例では、パケット・サイズは、ヒント・トラックが作成された時点で決定される。したがって、ヒント・トラック（「ｃｏｄｉｎｇ」に特有のフィールドを含むことができるデータ構造、この場合はプロトコル）についてのサンプル記述中に、選択されたパケット・サイズが示されている。本発明の一例では、様々なパケット・サイズを選択できるようにするために、各メディア・トラックごとにいくつかのＲＴＰヒント・トラックが提供される。その他のプロトコルも同様にパラメータ化することができる。同様に、ＲＴＰクロックについての適当なタイム・スケールが以下のサンプル記述中に設けられる。
【０１４２】
ヒント・トラックは、単一のトラック参照宣言によってそのベース・メディア・トラックと関係づけられる。（ＲＴＰでは、単一のＲＴＰストリーム内でのメディアの多重化を行うことができない。）ＲＴＰについてのサンプル記述は、このヒント・トラックが生成することになる最大パケット・サイズを宣言する。セッション記述（ＳＡＰ／ＳＤＰ）情報は、トラック中のユーザ・データ・アトム中に記憶される。
【０１４３】
ＲＴＰヒント・トラック中の各サンプルは、所与の時間に発信しなければならないパケットのセットを送信する命令を含む。ヒント・トラック中のこの時間は発信時間であり、必ずしも関連するメディアのメディア時間ではない。
【０１４４】
以下の記述では、オブジェクトとして構造化する必要のない、この例の用語で言うとメタ・データではなくメディア・データであるサンプルの内部構造について述べる。
【０１４５】
この例では、各サンプルは２つの領域、すなわちパケットを合成するための命令、およびこれらのパケットを送信するときに必要となる任意のエキストラ・データ（例えば暗号化したバージョンのメディア・データ）を含む。
struct RTPsample {
int(16) packetcount;
RTPpacket packets[packetcount];
byte[] extradata;
}
【０１４６】
各ＲＴＰヒント・パケットは、単一のパケットを送信するための情報を含む。一実施形態では、メディア時間を発信時間から分離するために、特にＲＴＰタイム・スタンプが、ＲＴＰヘッダを形成するために必要なデータとともに含まれる。ただし、代替実施形態では、このようにならない。その他のヘッダ情報が通常は供給される。構成体エントリのテーブルは以下のように構成される。
struct RTPpacket {
int(32) RTPtime;
int(16) partialRTPheader;
int(16) RTPsequenceseed;
int(16) entrycount;
dataentry constructors[entrycount];
}
【０１４７】
様々な形態の構成要素がある。各構成要素は１６バイトであり、これにより繰返しを比較的簡単にすることができる。第１のバイトは下記のような合併ディスクリミネータ（union discriminator）である。
struct dataentry {
int(8) entrytype;
switch entrytype {
case immediate:
int(8) bytecount;
int(8) bytestocopy[bytecount];
case mediasample:
int(8) reserved[5];
int(16) length;
int(32) mediasamplenumber;
int(32) mediasampleoffset;
case hintsample:
int(8) reserved[5];
int(16) length;
int(32) hintsamplenumber;
int(32) hintsampleoffset;
}
}
【０１４８】
即値モードでは、ペイロードに特有のヘッダ（例えばＲＴＰ Ｈ．２６１ヘッダ）の挿入が可能である。メディアが「明文で（in the clear）」送信されるヒント・トラックについては、メディアサンプル・エントリは、サンプル番号、データ・オフセット、およびコピーする長さを与えることによって、メディア・トラックからコピーするバイトを指定することができる。比較的複雑な場合（例えば暗号化または順方向誤り修正）には、その変形済みのデータをヒント・サンプル中に置くことができ、次いで、ＲＴＰサンプル自体の中のエキストラデータ・フィールドから提供されることになるヒントサンプル・モードを使用することができる
【０１４９】
本発明の一例では、連続したパケットがメディア・ストリームから連続したバイトを伝送する必要はない。例えば、Ｈ．２６１のＲＴＰ標準のパッキングに準拠するために、本発明の一例では、（マクロブロックの境界がバイト内にあるときには）、バイトは、１つのパケットの末端および次のパケットの冒頭で送信することができる。
【０１５０】
付録Ｃ−データ形式「ｒｔｐ」についてのパケット化ヒントのサンプル・データ
この付録では、本発明の一実施形態による、「ｒｔｐ」形式についてのサンプル・データの記述を与える。「ｒｔｐ」形式は、サーバがＲｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）を使用してデータを送信していることを前提とする。この形式は、サーバがＲＴＰヘッダについて知っているものと仮定するが、サーバが、様々なＩＥＴＦドラフト中で定義されたメディア・ヘッダを含めた特定のメディア・ヘッダについて知っていることは必要としない。
【０１５１】
本発明の一実施形態では、ヒント・トラック中の各サンプルは、１つまたは複数のＲＴＰパケットを生成することになる。ヒント・トラック・サンプル中のサンプル・データ・テーブル中の各エントリは、単一のＲＴＰパケットに対応する。ヒント・トラック中のサンプルは、メディア・トラック中のサンプルと正確に対応することも、対応しないこともある。本発明の一実施形態では、ヒント・トラック・サンプル中のデータは、３２ビット整合ではなく、バイト整合である。

【０１５２】
【表３】

【０１５３】
一実施形態では、パケット・エントリは下記のデータ・エレメントを含む。

【０１５４】
【表４】

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

【０１５７】
即値データ・モード
データ・テーブル・エントリは即値モードについて以下の形式を有する。

【０１５８】
サンプル・モード
データ・テーブル・エントリは、サンプル・モードについて以下の形式を有する。

【０１５９】
圧縮ブロック当たりのバイトおよび／または圧縮ブロック当たりのサンプルが１より大きい場合には、この比率を使用して、サンプル番号を実際のバイト・オフセットに変換する。この比率モードは、通常は、
ＣＢ＝ＮＳ＊ＢＰＣＢ／ＳＰＣＢ
のようにＱｕｉｃｋＴｉｍｅムービー中の圧縮オーディオ・トラックについて使用され、ここで
ＣＢ＝圧縮バイト、
ＮＳ＝サンプル数、
ＢＰＣＢ＝圧縮ブロック当たりのバイト、
ＳＰＣＢ＝圧縮ブロック当たりのサンプルである。
例えば、ＧＳＭ圧縮ブロックは、通常は３３バイトにパックされた１６０個のサンプルである。したがって、ＢＰＣＢ＝３３、およびＳＰＣＢ＝１６０である。ヒント・サンプルは、１６１番目のメディア・サンプルから始まる３３バイトのデータを要求する。第１のＱｕｉｃｋＴｉｍｅチャンクが少なくとも３２０個のサンプルを含むものと仮定し、このデータがチャンク１からのものであること、およびチャンク１がどこから開始するかを決定した後で、この比率を利用して、要求されたサンプルが発見されることになるファイル中へのオフセットを調節する。
チャンク番号＝１；／^*サンプル／チャンク・アトムをたどることによって計算される^*／
このチャンク中の第１のサンプル＝１；／^*やはりそのアトムから計算される^*／
チャンク・オフセット＝チャンク・オフセット［チャンク番号］；／^*ｓｔｃｏアトムから^*／
データ・オフセット＝（サンプル番号−このチャンク中の第１のサンプル）^*ＢＰＰ／ファイルから読み取ったＳＰＰ（チャンク・オフセット＋データ・オフセット、長さ）；／^*読出しデータ^*／
【０１６０】
サンプル記述モード
データ・テーブル・エントリは、サンプル記述モードについて以下の形式を有する。

【０１６１】
付録Ｄ−ＭＰＥＧ−２トランスポートについてのヒント・トラック形式の例
この節では、エレメンタリ・ストリームを保持するＱｕｉｃｋＴｉｍｅムービーからのＭＰＥＧ−２トランスポートをストリーミングするための簡単なトラック形式の一例を与える。
【０１６２】
ＭＰＥＧ−２トランスポート・ストリームは、１つまたは複数のエレメンタリ・ストリームの多重化に関連する。このため、ＭＰＥＧ−２トランスポートのヒント・トラックは、このような１つまたは複数のメディア・トラックからの多重化をどのようにして構築するかをを記述する。メディア・トラックとＭＰＥＧ−２トランスポートのヒント・トラックの間には、必ずしも１対１の関係があるわけではない。各ヒント・トラックは、それが表すエレメンタリ・ストリームへの参照を含むことができる。本発明の一例では、ＱｕｉｃｋＴｉｍｅファイルは、様々な多重化を記述するこのようなヒント・トラックを複数含むことができる。
【０１６３】
全てのＭＰＥＧ−２トランスポート・パケットのサイズは１８８バイトであるので、パケット・サイズは一般に問題にならない。本発明の一例では、各トランスポート・パケット（ＭＰＥＧ−２トランスポート・プロトコル）は、１つのメディア・トラックからのペイロード・データを含む。これにより、各トランスポート・パケットについて比較的簡単なヒント記述が可能となる。本発明の一例では、このような各ヒントは、各トランスポート・パケット上にどのヘッダ・データが現れるかを記述し、次いでそのトランスポート・パケットについて適当なメディア・トラック中のペイロードを指示する。ＰＳＩパケットなど、メディア・トラックと対応しないパケットについては、ヒントは、１８８バイトのヘッダ・データを記述することができ、任意のメディア・トラック参照は無関係とみなすことができる。メディア・トラックと対応するパケットについては、ヘッダ・データは、トランスポート・ヘッダ、可能な適合ヘッダ（ｐｏｓｓｉｂｌｅ ａｄａｐｔａｔｉｏｎ ｈｅａｄｅｒ）、ＰＥＳパケットを開始するトランスポート・パケットについてのＰＥＳヘッダなどの情報を反映することができる。
【０１６４】
（タイプ「ｓｔｓｄ」の）サンプル記述アトム中のＭＰＥＧ−２トランスポートのヒント・トラックを参照する。このアトムは、サンプル記述テーブルを含み、このテーブル中のエントリは、メディア・タイプに基づいて様々である。本発明の一例では、ヒント・トラックはテーブル１に示す構造から始まる。追加データ・テーブルは、テーブル２に示す構造を有するエントリを保持することができる。
【０１６５】
本発明の一例では、ヒント・トラックがＭＰＥＧ−２トランスポートのヒント・トラックである場合には、ヒント・トラックのサンプル記述エントリ中のデータ形式は「ｍ２ｔ」となり、最大パケット・サイズは常に１８８バイトとなる。このような記述エントリでは、以下のテーブル５〜７に示すタイプを、追加データ・テーブル中に見ることができる。
【表５】

【表６】

【表７】

【０１６６】
本発明の一例では、各ヒント・サンプルは、１つのトランスポート・パケットを記述する。各トランスポート・パケットは、１つのメディア・トラックからのある量のヘッダ・データとそれに続くある量のペイロードとして記述することができる。ＭＰＥＧ−２トランスポート・パケットは比較的小さいので、多数のヒント・サンプルを生成することができ、したがってこれらのサンプルは可能な限り小さくすることが好ましい。上記の追加データ・テーブル中のいくつかのエントリを使用してサンプルのサイズを最小限に抑えることができるが、このようなファクタにより、サンプル・エントリ中のフィールドのいくつかのサイズが可変となることがある。
【０１６７】
データ・テーブル中の「ｏｔｙｐ」エントリが値０を有する場合（ペイロード・データがメディア・サンプルに関連して記述されることを示す）には、ヒント・サンプルは、テーブル８に示す以下の形態となることができる。
【表８】

【０１６８】
本発明の一例では、パケットについてのペイロード・データの長さは、ＭＰＥＧ−２では１８８からパケットのヘッダ・データのサイズを引いたものに等しいので、この長さを示す必要はない。
【０１６９】
データ・テーブル中の「ｏｔｙｐ」エントリが値１を有する場合（ペイロード・データがファイル・オフセットに関連して記述されることを示す）には、ヒント・サンプルは、テーブル９に示す以下の形態となることができる。
【表９】

【０１７０】
本発明の一例では、ヒント・サンプルはそれらのオフセットをメディア・サンプルまたはファイル・オフセットに関連して記述することができる。これらにはそれぞれ利点および欠点がある。ヒント・サンプルは、メディア・サンプルに関連してペイロードを指定する場合には、メディア・トラックを含むファイルの追加編集に対してより弾性的（ｒｅｓｉｌｉｅｎｔ）になるが、送達のための追加処理を必要とすることがある。ヒント・サンプルは、ファイル・オフセットに関連してペイロードを指定する場合には、比較的迅速にペイロード・データにアクセスすることができるが、メディア・トラックを含むファイルを編集することでヒントが無効になることがある。
【０１７１】
付録Ｄ−ファイルの例
以下に、本発明の一実施形態による、比較的重要性の低いフィールドおよびオブジェクトの一部は省略し（ここでは省略記号“”でマークする）、またいくつかの架空の番号でＲＴＰを介したストリーミングに備えたファイルの全体的な構造を示す、比較的短い（６フレーム）サンプル・ファイルを与える。メディア・データは省略し、メタ・データのみを示す。
【０１７２】
【付表】

【図面の簡単な説明】
【図１】 従来技術の１つのトラックを有する単純なムービーの構造の一例を示す図である。
【図２】 従来技術の独立型ムービーの一例を示す図である。
【図３】 本発明による方法の一例を示す流れ図である。
【図４】 本発明のヒント・トラックの一例を示す図である。
【図５】 本発明のヒント・トラックのもう１つの例を示す図である。
【図６】 本発明の一実施形態による、メディア・データを交換および／または処理することができるコンピュータ・システムのネットワークを示す図である。
【図７】 本発明の一実施形態に従って使用することができるデジタル処理システムを示すブロック図である。
【図８】 本発明の一実施形態による、ヒントを利用してメディア・データを転送するシステムを示すブロック図である。
【図９】 本発明の一実施形態による、ヒントを利用してメディア・データを転送するシステムを示すブロック図である。
【図１０】 本発明の一実施形態による、メディア・データ伝送を実現するためにヒントを生成する方法を示す流れ図である。
【図１１】 本発明の一実施形態による、ヒントに従って受信側システムが受信したメディア・データを処理する方法を示す流れ図である。
【図１２】 本発明の一実施形態による、ジェネレータなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例を示す図である。
【図１３】 本発明の一実施形態による、サーバなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例を示す図である。
【図１４】 本発明の一実施形態による、受信側システムやその他のデジタル処理システムなどのデジタル処理システムがアクセスすることができる機械可読記憶媒体の一例を示す図である。
【図１５】 本発明の一実施形態による、メディアおよびヒント情報を記憶／トランスポートするデータ記憶および／または通信媒体を示す図である。

Claims (17)

1. 実行可能なコンピュータ・プログラム命令を有するコンピュータ可読記憶媒体であって、該プログラム命令が第１のデジタル処理システム上で実行されたときに当該第１のデジタル処理システムに、
   所定のパケット化特性に従って伝送すべき第１の時間に関係したデータ・シーケンスをどのようにしてパケット化するかを示す第２の時間に関係するデータ・シーケンス中において、前記第１の時間に関係するデータ・シーケンスを論理的に参照することを含む方法を
   実行させるコンピュータ可読記憶媒体であって、さらに、
   前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係するデータ・シーケンスへの論理リンクと前記第１の時間に関係するデータ・シーケンスをパケット化するための命令とを含むコンピュータ可読記憶媒体。
2. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスをパケット・セットとして伝送するタイミング・パラメータを含む請求項１に記載の媒体。
3. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスのパケット・セットへの多重化を提供する命令を含む請求項１に記載の媒体。
4. 前記パケット化特性が「特定のネットワークの伝送プロトコル」、「ネットワーク帯域幅」及び「転送レート」の少なくとも一つを含む請求項１に記載の媒体。
5. 前記第１、第２のシーケンスが互いに別途に記憶される請求項１に記載の媒体。
6. １つのデジタル処理システムから他のデジタル処理システムに伝送されるメディア・データの生成方法であって、
   所定のパケット化特性に従って伝送すべき第１の時間に関係したデータ・シーケンスをどのようにしてパケット化するかを示す第２の時間に関係するデータ・シーケンス中において、該第１の時間に関係するデータ・シーケンスを論理的に参照することを含み、さらに、
   前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係するデータ・シーケンスへの論理リンクと前記第１の時間に関係するデータ・シーケンスをパケット化するための命令とを含む方法。
7. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスをパケット・セットとして伝送するタイミング・パラメータを含む請求項６に記載の方法。
8. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスのパケット・セットへの多重化を提供する命令を含む請求項６に記載の方法。
9. 前記パケット化特性が「特定のネットワークの伝送プロトコル」、「ネットワーク帯域幅」及び「転送レート」の少なくとも一つを含む請求項６に記載の方法。
10. １つのデジタル処理システムから他のデジタル処理システムに伝送されるメディア・データの生成装置であって、
    所定のパケット化特性に従って伝送すべき第１の時間に関係したデータ・シーケンスをどのようにしてパケット化するかを示す第２の時間に関係するデータ・シーケンス中において、前記第１の時間に関係するデータ・シーケンスを論理的に参照する手段を含み、さらに、
    前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係するデータ・シーケンスへの論理リンクと前記第１の時間に関係するデータ・シーケンスとを含む装置。
11. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスをパケット・セットとして伝送するタイミング・パラメータを含む請求項１０に記載の装置。
12. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスのパケット・セットへの多重化を提供する命令を含む請求項１０に記載の装置。
13. 前記パケット化特性が「特定のネットワークの伝送プロトコル」、「ネットワーク帯域幅」及び「転送レート」の少なくとも一つを含む請求項１０に記載の装置。
14. １つのデジタル処理システムから他のデジタル処理システムに伝送されるメディア・データを生成するコンピュータ・システムであって、
    所定のパケット化特性に従って、伝送すべき第１の時間に関係したデータ・シーケンスをどのようにしてパケット化するかを示す第２の時間に関係するデータ・シーケンス中において、前記第１の時間に関係するデータ・シーケンスを論理的に参照する命令を実行する処理ユニットと、
    前記処理ユニットに結合して、前記第１、第２の時間に関係するデータ・シーケンスを提供するポートとを含み、さらに
    前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係するデータ・シーケンスへの論理リンクと前記第１の時間に関係するデータ・シーケンスをパケット化するための命令とを含むコンピュータ・システム。
15. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスをパケット・セットとして伝送するタイミング・パラメータを示す請求項１４に記載のコンピュータ・システム。
16. 前記第２の時間に関係したデータ・シーケンスが、前記第１の時間に関係したデータ・シーケンスのパケット・セットへの多重化を提供する命令を含む請求項１４に記載のコンピュータ・システム。
17. 前記パケット化特性が「特定のネットワークの伝送プロトコル」、「ネットワーク帯域幅」及び「転送レート」の少なくとも一つを含む請求項１４に記載のコンピュータ・システム。

Images