JP2001197120A

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

Info

Publication number: JP2001197120A
Application number: JP2000215937A
Authority: JP
Inventors: Anne Jones; ジョーンズ，アン; Jay Geagan; ジーガン，ジェイ; Kevin L Gong; ゴン，ケヴィン・エル; Alagu Periyannan; ペリヤナン，アラグ; David W Singer; シンガー，デイビッド・ダブリュ
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 2000-07-17
Filing date: 2000-07-17
Publication date: 2001-07-19

Abstract

(57)【要約】【課題】データ通信媒体中で伝送するメディア・デー
タを処理する方法および装置を提供する。【解決手段】データのセットが時間に関係したメディ
ア・データのシーケンスをある伝送プロトコルに従って
どのようにして伝送するかを示す。このデータのセット
は、その時間に関係したメディア・データのシーケンス
に関連する、時間に関係したデータのシーケンスを含
む。このデータのセットをデジタル処理システムが利用
して、時間に関係したメディア・データのシーケンスを
（例えばその伝送プロトコルおよびそのデータのセット
に従って生成されたパケットによって）伝送することが
できる。

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）（例えば様々な自
然言語音声トラック）のセットを形成するトラックに
は、１つだけが再生のために選択されるようにタグ付け
することができる。同じ構造を使用して、ストリーミン
グのための選択肢を選択する（例えば言語選択）ことが
できる。この能力については、ＱｕｉｃｋＴｉｍｅファ
イル形式にさらに詳細に記述されている。

【００３３】ＱｕｉｃｋＴｉｍｅがムービーまたはトラ
ックを表示するときには、適当なメディア・ハンドラが
特定の時間についてのメディア・データにアクセスす
る。メディア・ハンドラは、要求されたデータを取り出
すために、データ・ストリームを正しく解釈しなければ
ならない。例えば、ビデオ・メディアに関しては、メデ
ィア・ハンドラは、通常はいくつかのアトムを横断し
て、所与のメディア時間についてのサンプルの位置およ
びサイズを発見する。メディア・ハンドラは、１．メディア時間座標系中の時間を決定すること、２．時間／サンプル・アトムを検査して、指定された時
間についてのデータを含むサンプルの番号を決定するこ
と、３．サンプル／チャンク・アトムを走査して、どのチャ
ンクが当該のサンプルを含むかを発見すること、４．そのチャンクへのオフセットを、チャンク・オフセ
ット・アトムから抽出すること、ならびに５．サンプル・サイズ・アトムを使用して、そのチャン
ク内のオフセットおよびサンプルのサイズを発見するこ
とを実行することができる。

【００３４】ＱｕｉｃｋＴｉｍｅファイルまたはその他
のタイプの時間に関係したメディア・データのシーケン
スを、コンピュータ・ネットワーク（例えばインターネ
ット）と関連づけることができるデータ通信媒体を介し
て伝送することがしばしば望ましい。多くのコンピュー
タ・ネットワークでは、ネットワーク中に伝送されるデ
ータは、一般にパケット形態をとらなければならない。
通常は、時間に関係したメディア・データのシーケンス
は、ネットワークを介した伝送に適したパケット化形式
にはなっていない。例えば、ＱｕｉｃｋＴｉｍｅ形式の
メディア・データ・ファイルはパケット化形式ではな
い。したがって、ストリーミング・データと呼ばれるこ
ともあるデータを収集して、ネットワークを介して伝送
するためのパケットにする必要がある。

【００３５】時間に関係したメディア・データのシーケ
ンスをネットワークを介して伝送する問題に対処する従
来の１つの手法は、ハイパーテキスト転送プロトコル
（ＨＴＴＰ）などのネットワーク・プロトコルまたは伝
送プロトコルを使用して、ネットワークを介してメディ
ア・ファイルを送信するものである。したがって、メデ
ィア・ファイル自体が、１つのコンピュータ・システム
から別のコンピュータ・システムにネットワークを介し
て送信される。しかし、受信側コンピュータ・システム
でメディア・ファイルを保存したいという要望がないこ
ともある。すなわち、例えば受信側コンピュータ・シス
テムがネットワーク・コンピュータ、または記憶容量の
少ないコンピュータである場合には、受信側コンピュー
タ・システムでメディア・ファイルが受信され、視聴さ
れたときに、その受信側コンピュータ・システムのユー
ザが、そのファイルのコピーを記憶することを望まない
こともある。

【００３６】ネットワークを介してパケットで伝送する
ためにどのようにしてデータを収集するかという問題を
解決するもう１つの代替手法は、ある特定の伝送プロト
コルについてネットワーク・プロトコル・データ・ユニ
ットをそのファイル中に含むファイルを準備するもので
ある。ある意味では、このようなファイルは、その特定
の伝送プロトコルに従って伝送されることになるのと基
本的に同じ形式で記憶されたパケット化ファイルである
と考えることができる。この操作を実行するには、一般
に、特定のデータ伝送速度の特定のネットワーク・プロ
トコルおよび特定のメディア・ファイル形式についての
パケット化形態で、ファイルを記憶することが必要であ
る。したがって、特定のデータ伝送速度の様々な伝送プ
ロトコルそれぞれについて、ファイルは本質的にそのパ
ケット化形態で複製されることになる。こうしたファイ
ルの形態が固定されると、それらの適用性／互換性が制
限され、それらのファイルをローカルに見ることが困難
になることがある。したがって、このような手法は、様
々に異なるデータ伝送速度の様々な伝送プロトコルでフ
ァイルを提供しようと試みる際の記憶要件を大幅に増加
させることがある。さらに、この代替の従来の手法に従
って生成された各パケット化ファイルは、一般に特定の
メディア・ファイル形式に限定され、したがって、同じ
メディア・オブジェクト（例えばデジタル・ムービー）
についてのその他のメディア・ファイル形式は、通常は
送信側コンピュータ・システム上でパケット化され、記
憶される。

【００３７】時間に関係したメディア・データのシーケ
ンスをどのようにしてストリーミングするかという問題
を解決するさらに別の手法は、伝送側システムで必要と
なったときに、望ましい特定の伝送プロトコルに従って
メディア・データのパケット化を実行するものである。
この処理は、多くの場合に、比較的長い時間を必要と
し、したがって伝送側システムの性能を低下させること
がある。

【００３８】

【発明が解決しようとする課題】したがって、時間に関
係したメディア・データのシーケンスを伝送するための
改良された方法および装置が実現されることが望まし
い。

【００３９】

【課題を解決するための手段】本発明は、データ通信媒
体中で伝送するためにメディア・データを処理する方法
および装置を提供するものである。一実施態様では、デ
ータのセットは、時間に関係したメディア・データのシ
ーケンスをある伝送プロトコルに従ってどのようにして
伝送するかを示す。一実施態様によれば、このデータの
セットは、時間に関係したメディア・データのシーケン
スに関連する時間に関係したデータのシーケンスを含
む。本発明の一態様によれば、このデータのセットをデ
ジタル処理システムが利用して、時間に関係したメディ
ア・データのシーケンスを（例えばその伝送プロトコル
およびデータのセットに従って生成されたパケットによ
って）伝送することができる。

【００４０】

【発明の実施の形態】本発明は、例えばビデオ、オーデ
ィオ、及びビデオとオーディオなどを含む時間に関係し
たメディア・データのシーケンスの、コンピュータ・ネ
ットワーク中など通信メディアを介した伝送、特にその
パケット化伝送を可能にする方法および装置を提供する
ものである。

【００４１】本発明の一実施形態では、デジタル処理シ
ステムは、時間に関係したメディア・データのシーケン
スをある伝送プロトコルに従ってどのようにして伝送す
るかを示すデータのセットを作成する。通常は、このデ
ータのセットは、デジタル処理システムに結合された記
憶デバイスに記憶される。さらに、このデータのセット
は、時間に関係したメディア・データのシーケンスに関
連する、時間に関係したデータのシーケンスである。

【００４２】本発明は、コンピュータ可読媒体に記憶さ
れる実行可能コンピュータ・プログラム命令として完全
に実装することも、ソフトウェアとハードウェアの組合
せとして実装することも、あるいはいくつかの実施形態
では完全にハードウェアとして実装することもできる。
通常は、ネットワークに結合されたサーバ・コンピュー
タ・システムが、ヒント・トラックと呼ばれることがあ
るデータのセットを作成し、このヒント・トラックをそ
のサーバ・コンピュータ・システムに結合された記憶デ
バイスに記憶することになる。クライアント・コンピュ
ータ・システムがメディア・データ・ファイルの提示
（例えばそれらを見るまたは聞くこと、あるいは視聴す
ること）を要求すると、サーバ・システムは、ヒント・
トラックを使用して、クライアント・コンピュータ・シ
ステムに伝送するためにメディア・データをどのように
してパケット化するかを決定する。本発明は時間に関係
したメディア・データのシーケンス全般に適用可能であ
り、ＱｕｉｃｋＴｉｍｅは、この全般的な適用可能性の
一例として本明細書に表したものであることを理解され
たい。したがって、本発明は必ずしもＱｕｉｃｋＴｉｍ
ｅに限定されるわけではないものとする。

【００４３】図３は、本発明による方法の一例を示す図
である。図３に示す方法３００は、伝送することが望ま
しい特定のメディア・データについてのメディア・ファ
イル形式を決定するステップ３０１から開始する。ステ
ップ３０３で、使用することが望ましい１つまたは複数
の特定の伝送プロトコルも決定される。ただし、ステッ
プ３０１および３０３は、例えば常に同じメディア・フ
ァイル形式が同じ伝送プロトコルを使用して伝送される
場合には省略可能である。

【００４４】ステップ３０５で、サーバ・コンピュータ
・システムなどのデジタル処理システムが、メディア・
ファイル中の時間に関係したメディア・データのシーケ
ンスをパケット化するためのヒントを作成し、記憶す
る。別法として、１つのコンピュータ・システムがヒン
トを作成し、後に伝送プロセスで使用するためにそれら
を記憶する別のシステム（サーバ・コンピュータ・シス
テムなど）に提供することもできる。パケット化によ
り、ステップ３０１で決定された所望の伝送プロトコル
に従うネットワークまたは通信媒体を介した伝送が可能
となる。本発明の一実施形態では、ヒントは、その他の
トラックのメディア・データを参照するが一実施形態で
はそれとは別個の、時間に関係したヒントのシーケンス
のトラックとして記憶される。本発明の一実施形態で
は、ヒントのトラックは、それが参照するメディア・デ
ータとは別に記憶することができる。したがって、ヒン
トのトラックは、ヒントのトラックが参照するメディア
・データを含むもう１つのファイルとは別個のファイル
に記憶することも、そのメディア・データを含むファイ
ル中の、実際のメディア・データを含むデータ領域から
分離した別個のヒント領域に記憶することもできる。本
発明の一実施形態では、ヒント・トラックまたはその一
部分は、サーバが実行可能命令として解釈することがあ
り、この実行可能命令によって、サーバは、通常は時間
ベースのメディア・データである（必ずしもそうである
わけではない）時間に関係したデータのシーケンスをパ
ケット化する。本発明の一実施形態では、ヒントは、伝
送側デジタル処理システムに結合された記憶デバイスに
記憶される。

【００４５】ステップ３０７で、ヒントに従ってパケッ
ト化されたデータが、サーバ・コンピュータ・システム
などの伝送側システムから受信側システムに伝送され
る。このメディア・データは、そのメディア・データを
ヒントに従ってパケット化することによって伝送され
る。本発明の代替の一実施形態では、サーバ・コンピュ
ータ・システムは、ヒントを使用せず、代替のパケット
化プロセスによってメディア・データを送信することに
することもできる。

【００４６】ステップ３０９で、受信側システムが、メ
ディア・データによって表されるメディア・オブジェク
トを提示する。通常は、この提示（メディア・オブジェ
クトの視聴であることも、単にメディア・オブジェクト
を見るだけ、または聞くだけであることもある）は、パ
ケット化されたデータが受信側システムで受信されるに
つれて実行される。パケット化されたデータは、本発明
の一実施形態では受信側システムに記憶することができ
る（必ずしもそのようにする必要はない）。したがっ
て、提示が終了した後で受信側システムにローカル・コ
ピーが存在しないという点で、データの提示は短命（ep
hemeral）である。別の実施形態では、メディア・オブ
ジェクトの提示は、そのメディア・オブジェクトを表す
メディア・データについてのヒントを作成した後で、サ
ーバ・システム上で行うことができる。本発明の一実施
形態では、メディア・データは、ヒントに従ってパケッ
ト化するために、必ずしも（再）フォーマットやコピー
などが行われるわけではない。

【００４７】ステップ３１１で、受信されたメディア・
ファイルが受信側システムに記憶されている場合には、
受信側システムは、任意選択でそのメディア・ファイル
を再アセンブルすることができる。図３に示す方法の様
々なステップは、上記で図示および記述した順序とは異
なる順序で実行することも、それらのステップの一部を
同時に実行することも、あるいはその両方を合わせて行
うこともできることを理解されたい。例えば、一実施形
態ではステップ３０９およびステップ３１１は、並行し
て行われる。

【００４８】本発明の一実施形態による、ＱｕｉｃｋＴ
ｉｍｅを用いた特定の実施態様について次に述べる。本
発明の一実施形態では、そのファイルにローカルに（例
えばサーバやジェネレータなどで）見ることも、Ｑｕｉ
ｃｋＴｉｍｅムービー内でネットワークを介してストリ
ーミングすることもできる提示が行われる。一般に、ス
トリーミング・サーバ（または別のシステム）は、スト
リーミングするデータ・ユニット、それらの組成および
タイミングについての情報を有さなければならない。こ
のような情報は通常は時間的なものであるので、トラッ
ク中に記述することができる。サーバは、例えば提示を
見るために使用されることになるのと同じ索引付け操作
を使用することによって、パケット化を実行し、プロト
コル情報を決定することができる。

【００４９】サーバに対する命令を含むトラックは、パ
ケットを形成および伝送するプロセス中にサーバに指示
を出すデータのセットを表すので、「ヒント」トラック
と呼ばれることがある。ＱｕｉｃｋＴｉｍｅファイル形
式は、ネットワークを介したメディア・データのストリ
ーミング、ならびにローカルな再生をサポートする。プ
ロトコル・データ・ユニットを送信するプロセスは、時
間ベースのデータの表示と同様に時間ベースであり、し
たがって時間ベースの形式で適切に記述される。ストリ
ーミングをサポートするＱｕｉｃｋＴｉｍｅファイルま
たは「ムービー」は、ストリーミングするデータ・ユニ
ットについての情報を含む。この情報は、「ヒント」ト
ラックと呼ばれるファイルの追加トラックに含まれる。

【００５０】ヒント・トラックは、パケットの形成を助
ける、ストリーミング・サーバ（またはその他のデジタ
ル処理システム）に対する命令を含む。これらの命令
は、サーバが（例えばヘッダ情報を）送信する、または
メディア・データのセグメントを参照するための即値デ
ータを含むことができる。本発明の一実施形態では、編
集または提示情報がローカルな再生のためにＱｕｉｃｋ
Ｔｉｍｅファイル中でコード化されるのと同じ方法で、
命令がＱｕｉｃｋＴｉｍｅファイル中でコード化され
る。編集または提示情報の代わりに、特定のネットワー
ク・トランスポートを使用したストリーミングに適した
方法でサーバがメディア・データをパケット化できるよ
うにすることができる情報を提供することができる。

【００５１】本発明の一実施形態では、ローカルに再生
されるか、いくつかの異なるトランスポート・タイプを
介してストリーミングされるかに関わらず、同じメディ
ア・データが、ヒントを含むＱｕｉｃｋＴｉｍｅファイ
ル中で使用される。異なるトランスポート・タイプにつ
いての別個の「ヒント」トラックを同じファイル内に含
むことができ、メディア自体の追加コピーを作成せず
に、こうしたトランスポート・タイプの全てを介してメ
ディアを再生することができる。さらに、特定のトラン
スポートについての適当なヒント・トラックを追加する
ことによって、現行のメディアをストリーミングできる
ようにする。本発明の一態様によれば、メディア・デー
タ自体を再キャストまたは再フォーマットする必要はな
い。

【００５２】したがって、ヒント・トラック中のサンプ
ルは一般に、パケットを形成するための命令を含む。こ
れらの命令は、サーバが（例えばヘッダ情報を）送信す
る、または別のトラック中のメディア・データのセグメ
ントを参照するための即値データを含むことができる。

【００５３】本発明の一実施形態では、３レベル設計を
利用し、下記のようになる。１）メディア・データは、通常通りに再生や編集などを
行うことができるネットワーク独立トラックのセットと
して表される。２）サーバ・ヒント・トラックについての共通の宣言お
よび基礎構造がある。この共通の形式はプロトコル独立
型であるが、どのプロトコルがサーバ・トラック中に記
述されるかという宣言を含む。３）伝送することができる各プロトコルについて、特定
のサーバ・ヒント・トラックの設計がある。これらの設
計は全て、同じ基本構造を使用する。例えば、ＲＴＰ
（インターネット用）およびＭＰＥＧ−２トランスポー
ト（同報通信用）、あるいは新しい標準の、またはベン
ダに特定のプロトコルについての設計がある。

【００５４】本発明の一実施形態では、ヒント・トラッ
クの指示でサーバから送信される結果生じるストリーム
は通常のストリームであり、必ずしもＱｕｉｃｋＴｉｍ
ｅ情報のトレースを含まない。本発明のこの実施形態で
は、ＱｕｉｃｋＴｉｍｅ、あるいはその構造または宣言
スタイルが、必ずしも伝送媒体（例えばネットワーク・
ケーブル）上のデータ、または復号側ステーション中に
ある必要はない。例えば、ＲＴＰ下でストリーミングさ
れたＨ．２６１のビデオおよびＤＶＩオーディオを使用
したファイルは、本発明の一実施形態では、それらのコ
ーディングをＲＴＰ中にパックするためのＩＥＴＦ仕様
に完全に準拠したパケット・ストリームを生じることが
できる。

【００５５】本発明の一実施形態では、ヒント・トラッ
クは、提示がローカルに見られる時にヒント・トラック
が基本的に受信側システムに無視されるように構築さ
れ、フラグを立てられる。

【００５６】一実施形態では、例えばビデオやオーディ
オなどを含むことができる時間に関係したメディア・デ
ータのシーケンスを、デジタル処理システムによってパ
ケット化し、その後、同じデジタル処理システム上で提
示することができる。さらに、パケット化を短命にし、
提示、記憶、読取りなどが行われている時間に関係した
シーケンスも「実行中（ｏｎｔｈｅｆｌｙ）」にパ
ケット化されるようにすることもできる。一実施形態で
は、ヒントは、コピーやフォーマットなどが行われてい
ないメディア・データを参照することができる。例え
ば、ヒントが参照するメディア・データは、オリジナル
の形式で読取り専用メモリなどに記憶することができ
る。

【００５７】一実施形態では、パケット化を実現する同
一のヒント・ルーチンが、パケット化を実行するにつれ
てメディアも提示する。本発明の代替実施形態では、時
間に関係したメディアのパケット化ファイルは、ヒント
・トラックに従って生成し、例えば後に伝送するために
記憶することができる。

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

【００５９】上記で論じたように、上述の論理構造が物
理構造を暗黙に定義する必要はない。メタ・データはメ
モリにキャッシュすることができ、ヒント・トラック・
サンプルは、（図４に示すように）それらが参照するメ
ディア・サンプルと物理的にインタリーブすることがで
きる。

【００６０】別法として、現行の提示中のメタ・データ
およびメディア・データを参照および増補する、ヒント
・トラックを含むメタ・データおよびメディア・データ
の新しいセットを書き込むこともできる。図５は、本発
明の一実施形態による、別個のファイル中のメディア・
データを参照するためのヒント・トラックの利用方法を
示している。図５には、それ自体のメタ・データをそれ
ぞれ備えた２つのムービー・ファイル５０２および５０
４が示してある。第１のムービー・ファイル５０２はビ
デオ・トラックを含む。第２のムービー・ファイル５０
４は、ビデオ・トラックおよびヒント・トラックを両方
とも含むが、そのメタ・データは、そのビデオ・トラッ
クについてのメディア・データが第１のムービー・ファ
イル５０２中にあることを宣言している。したがって、
ムービー・ファイル５０４に関連するヒントも、第１の
ムービー５０２中のメディア・データを指している。

【００６１】本発明の一実施形態では、メディア・ファ
イルは、複数のプロトコルについてのパケット化ヒント
・トラックを含むことができる。したがって、各トラッ
クは、ヒント・トラックが適しているプロトコルの宣言
（および適当である場合にはプロトコルのパラメータ）
を含むことができる。言うまでもなく、これらのトラッ
クは全て、ファイル中の基本メディア・トラックからメ
ディア・データを参照することができる。プロトコル独
立性および拡張可能性を求める要望は、記載の方法で満
たすことができる。

【００６２】本発明の一実施形態では、ヒント・トラッ
クは、メディア・トラック中の全てのデータを使用する
必要はない。ヒント・トラックは、帯域幅のしきい値に
達するため、またはその他の理由のために、（例えば一
部のビデオ・フレームを省略することによって）データ
のサブセットを使用すればよい。同じプロトコルについ
て複数のヒント・トラックを設けることができるので、
同じ基本メディア情報の様々な速度の異なるサブセット
を提供することができる。したがって、本発明は、従来
の方法および装置に優る改善されたスケーラビリティを
もたらすことができる。

【００６３】ヒント・トラック自体およびＱｕｉｃｋＴ
ｉｍｅメタ・データは、一実施形態ではＱｕｉｃｋＴｉ
ｍｅファイル中になければならないが、基本メディア
は、ＱｕｉｃｋＴｉｍｅが適切にインポートおよび参照
することができる任意のファイル・タイプ中に残ること
ができることを強調しておく。本発明の一実施形態で
は、ムービー・ファイル中のメタ・データは、メディア
・データが別のファイル中にあることを宣言するデータ
参照を含むことができる。したがって、サンプル・テー
ブルのオフセットおよびポインタが、この「外部」ファ
イル中のデータを指示することもある。したがって、本
発明の一実施形態によれば、「ａｕ」オーディオ・ファ
イルや「ＡＶＩ」オーディオ／ビデオ・ファイル、ＭＩ
ＤＩファイルなど、現行のレガシー形式を、基本メディ
ア・データをコピーまたは再フォーマットする必要な
く、ストリーミングすることができる。基本メディア・
データが書き込まれず、単に別個のファイル中のＱｕｉ
ｃｋＴｉｍｅ宣言およびヒント情報で増補されるだけで
あるので、基本メディア・データを、ＣＤＲＯＭなど読
取り専用機械可読媒体上に与えることもできる。

【００６４】本発明の一実施形態では、ヒント・トラッ
クは、オフライン計算の結果を具現化し、通常は、パケ
ット化、および必要なら多重化をサポートするための情
報をサーバに提供するように最適化される。

【００６５】例えばＲＴＰ（ＩＥＴＦ標準の実時間プロ
トコル）およびＭＰＥＧ−２トランスポートについての
ヒントの例を、付録Ａ〜Ｃに示す。

【００６６】本発明の一実施形態では、単一のファイル
で、過度なスペースのオーバヘッドなしで、複数のプロ
トコル、またはそれらのプロトコルの複数の異なるパラ
メータ化についてのヒント・トラックをサポートするこ
とができる。新しいプロトコルおよびそれらに関連する
ヒント・トラックは、現行のプロトコルに依拠するシス
テムを混乱させることなく、設計することができる。し
たがって、本発明は、少なくとも一実施形態では、プロ
トコル中立的（ｐｒｏｔｏｃｏｌ−ｎｅｕｔｒａｌ）で
ある。

【００６７】ＱｕｉｃｋＴｉｍｅファイル形式では、メ
タ・データを更新またはコピーおよび増補することによ
って、トラックをムービーに追加することができる。メ
ディア・データがメタ・データとは別のファイル中にあ
る、または最適化されたインタリーブが不要である場合
には、これは比較的簡単かつ効率的な操作となることが
できる。

【００６８】本発明の一実施形態では、トラックを１つ
しか含まず、望ましい場合にはオリジナル中のメディア
・データを参照することができる新しいムービー・メタ
・データのセットを構築することによって、トラックを
抽出することができる。

【００６９】例えば、本発明の一実施形態では、その他
のオーディオ・トラックのセットの代替としてマークさ
れた新しいオーディオ・トラックを追加することができ
る。それが言語コード（例えばフランス語やタガログ
語）でもマークされている場合には、提示時に適当なト
ラックを選択することができる。

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

【００７１】本発明の一態様によれば、ヒント・トラッ
クは、現行のサーバまたはローカルな再生についての互
換性の問題を引き起こすことなく、新しいプロトコルの
ための新しい形式の開発を可能にすることができる。さ
らに、そのファイル形式の寿命にわたって、後方互換性
を維持しながら、新しいメディア・トラックを追加する
こともできる。

【００７２】本発明の一実施形態では、拡張可能性の領
域としては下記が含まれる。ａ）現在のＱｕｉｃｋＴｉｍｅファイル形式によってカ
バーされないメディア・タイプ（例えば実験室の機器の
読み）について規定することができる新しいトラック・
タイプ。ｂ）規定することができる現行のトラックについての新
しい符号化タイプ（例えばビデオまたはオーディオのコ
ーデック）。コーデックに特定の初期化情報についての
明確な備えがある。ｃ）新しいプロトコルについて規定することができる新
しいヒント・トラック・タイプ、およびメディア・デー
タ自体についてスペースのオーバヘッドを招くことなく
複数のプロトコルについてのヒント情報を含むことがで
きるファイル。

【００７３】読取り専用媒体上の現行のコンテンツ（例
えばＣＤＲＯＭやＤＶＤなどに予めパッケージ化された
ムービー）は、本発明とともに使用することができる。

【００７４】さらに、本発明の一態様によれば、様々な
「外部」ファイル形式を使用することができる。例え
ば、本発明の一実施形態では、現行のコンテンツがＱｕ
ｉｃｋＴｉｍｅ形式である、またはインポートすること
ができる場合には、コピーまたは再フォーマットする必
要なく、それを編集およびストリーミングすることがで
きる。

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

【００７６】本発明の一実施形態では、プロトコルが帯
域幅のスケーラビリティをサポートする場合には、ヒン
ト・トラック自体が、各プロトコル・データ・ユニット
（ヒント・トラック中のサンプル）についての情報を含
むことができる。情報は、それを超えるとプロトコル・
データ・ユニットをネットワークに送達しなければなら
ない帯域幅のしきい値を含むことができる。したがっ
て、ヒント・トラックは、利用可能な帯域幅を高いまた
は低いなどとして示し、かつ／あるいはデータ伝送の帯
域幅に関する情報を示すことができる。

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

【００７８】本発明の一実施形態では、様々なコーデッ
クを使用してベース・データを記録することが望ましい
場合には、それらのトラックを選択肢のグループの形に
形成し、１つだけを提示用に選択することができる。ど
のトラックを提示に使用するかを選ぶ選択は、通常はプ
ロトコルに依存し、本明細書に記載のヒント・トラック
手法を使用して達成することができる。

【００７９】本発明の一実施形態では、暗号化をメディ
ア・ファイルに事前に適用することもできる。この場合
には、暗号化されたデータは、（ａ）オリジナルのメデ
ィア・データにリンクされた新しいエレメンタリ・スト
リーム（新しいトラック）（すなわちオリジナルのメデ
ィア・データは、不要となった場合に除去することがで
きる）、あるいは（ｂ）ヒント・トラック自体に記憶す
ることができる。（ｂ）の場合には、実行中に、ヒント
・トラックが暗号化されていないエレメンタリ・ストリ
ームからいかなるデータも抽出しないことが可能であ
る。このように、暗号化によってメディア・データを変
形することができるので、全てのメディア・データが、
ヒント・トラックならびにストリーミング・パケット・
プロトコル・データ・ユニット情報中にあることもあ
る。

【００８０】組込み型オブジェクト・コンテンツ情報の
一例として、ムービー全体および個々のトラックについ
てのＩＥＴＦセッション記述情報を、ＲＴＰヒント・ト
ラックについてのメタ・データ中に、ユーザ・アトムと
して記憶することができる。

【００８１】本発明の一実施形態では、ファイル形式
は、通常は、再生可能な形式のメディア・データ、およ
びストリーミング情報を両方とも含む。一実施形態で
は、メディア独立性、プロトコル独立性、およびメディ
アをローカルに提示する能力を保持しながら、比較的低
いオーバヘッドでこの形式から直接ストリーミングする
ことができる。

【００８２】本発明の一態様によれば、ヒント・トラッ
クは、コーデック、タイミング、およびパケット化につ
いての詳細な知識を要約して、オフライン準備プロセス
にすることができる。したがって、ヒント・トラックを
たどってデータ・ストリームを生成することは比較的簡
単であり、ストリーミングされているメディアについて
の特殊な知識は必要ない。したがって、本発明の一態様
によれば、例えばデータ・コンテンツの詳細からサーバ
を切り離すことができる。

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

【００８４】本発明の一実施形態では、外部ファイル形
式をカプセル化することにより、メディア・データをそ
の他の形式で保存しながら、依然としてＱｕｉｃｋＴｉ
ｍｅで発行することができる。例えば、現行の形式は、
適当なラッパを適用することによって新しいメディア・
データ・ファイル中に直接カプセル化することも、その
まま残して、ヒント・トラックによってセグメントで、
または全体として参照し、レガシー形式をコピーせずに
ストリーミングできるようにすることもできる。単一の
ムービーは、複数のレガシー形式から選択した断片（pi
ece）を含むことができる。本発明は、ベース・メディ
ア形式を制約しない。

【００８５】一般的に、取込み、オーサリングおよび編
集、ダウンロードおよびストリーミングに及ぶ共通の形
式は、一般にフレキシビリティを有する。マテリアル
は、コピーまたは再フォーマットせずに、使用後に再加
工する、または複数の方法で使用することができる。本
発明の一実施形態では、標準的なエディタを使用してヒ
ント・トラックを除去し、次いで編集が完了した後で再
度ヒントを付ける（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）」送信され
るヒント・トラックについては、メディアサンプル・エ
ントリは、サンプル番号、データ・オフセット、および
コピーする長さを与えることによって、メディア・トラ
ックからコピーするバイトを指定することができる。比
較的複雑な場合（例えば暗号化または順方向誤り修正）
には、その変形済みのデータをヒント・サンプル中に置
くことができ、次いで、ＲＴＰサンプル自体の中のエキ
ストラデータ・フィールドから提供されることになるヒ
ントサンプル・モードを使用することができる

【０１４９】本発明の一例では、連続したパケットがメ
ディア・ストリームから連続したバイトを伝送する必要
はない。例えば、Ｈ．２６１のＲＴＰ標準のパッキング
に準拠するために、本発明の一例では、（マクロブロッ
クの境界がバイト内にあるときには）、バイトは、１つ
のパケットの末端および次のパケットの冒頭で送信する
ことができる。

【０１５０】付録Ｃ−データ形式「ｒｔｐ」についての
パケット化ヒントのサンプル・データこの付録では、本
発明の一実施形態による、「ｒｔｐ」形式についてのサ
ンプル・データの記述を与える。「ｒｔｐ」形式は、サ
ーバがＲｅａｌＴｉｍｅＴｒａｎｓｐｏｒｔＰｒｏ
ｔｏｃｏｌ（ＲＴＰ）を使用してデータを送信している
ことを前提とする。この形式は、サーバがＲＴＰヘッダ
について知っているものと仮定するが、サーバが、様々
なＩＥＴＦドラフト中で定義されたメディア・ヘッダを
含めた特定のメディア・ヘッダについて知っていること
は必要としない。

【０１５１】本発明の一実施形態では、ヒント・トラッ
ク中の各サンプルは、１つまたは複数のＲＴＰパケット
を生成することになる。ヒント・トラック・サンプル中
のサンプル・データ・テーブル中の各エントリは、単一
のＲＴＰパケットに対応する。ヒント・トラック中のサ
ンプルは、メディア・トラック中のサンプルと正確に対
応することも、対応しないこともある。本発明の一実施
形態では、ヒント・トラック・サンプル中のデータは、
３２ビット整合ではなく、バイト整合である。フィールド記述：エントリ・カウントテーブル中のパケット・エントリ
の数を示す１６ビットの符号のない整数。テーブル中の
各エントリは１つのパケットに対応する。単一サンプル
中に複数のエントリがあることは、メディア・サンプル
を複数のパケットに分割しなければならないことを示
す。エントリ・カウントがゼロであるサンプルは予約さ
れており、これに遭遇した場合にはスキップしなければ
ならない。パケット・エントリ・テーブルパケット・エントリを
含む可変長テーブル。パケット・エントリは以下に定義
する。追加データ以下のテーブル３で示すデータ・テ
ーブル中のエントリによって指示されるデータを含む可
変長フィールド。

【０１５２】

【表３】

【０１５３】一実施形態では、パケット・エントリは下
記のデータ・エレメントを含む。フィールド記述：相対パケット伝送時間このパケットを送信するための
時間を、ヒント・サンプルの実際の時間に対して相対的
にヒント・トラックのタイムスケールで示す、３２ビッ
トの符号付き整数値。負の値は、パケットが実時間より
早く送信されることを意味し、これはデータ・レートを
平滑化するのに有効である。正の値は後にパケットを繰
り返すのに有効である。各ヒント・サンプル・トラック
内で、各パケットのタイム・スタンプは減少しない。フラグこのパケットについてのいくつ
かの属性を示す３２ビット・フィールド。ＲＴＰヘッダ情報フィールドは下記のエレメントを含
む。フィールドビット＃記述Ｒ３１これが繰返しパケット、つまり以前のパケット中で定義されているデータであることを示す１ビット数。サーバは、パケットの伝送が遅れているときには、遅れを挽回するために繰返しパケットをスキップすることを選ぶことができる。所与のパケットについての全ての繰返しパケットは同一のヒント・サンプルに関する（ｃａｒｅｉｎ）。未定義の全てのビット（０〜３０）は予約されており、ゼロにセットされる。ＲＴＰヘッダ情報ＲＴＰヘッダ中でセットされる様々な値を指定する１６ビット整数。ＲＴＰヘッダ情報フィールドは、以下のエレメントを含む。フィールドビット＃記述Ｐ２ＲＴＰヘッダ中のパディング（Ｐ）ビットに対応する１ビット数。異なるパケット・パディングを必要としたサーバが、一般にそのパケット自体をアンパッド（ｕｎ−ｐａｄ）およびリパッド（ｒｅ−ｐａｄ）する必要があることもあるので、このビットはセットされないこともある。Ｘ３ＲＴＰヘッダ中の拡張（Ｘ）ビットに対応する１ビット数。それ自体のＲＴＰ拡張子を送信する必要のあるサーバが、ヒント・トラックからの任意の拡張子に取って代わることができないことも、または取って代わらざるを得ないこともあるので、このビットはセットされないこともある。Ｍ８ＲＴＰヘッダ中のマーカ（Ｍ）ビットに対応する１ビット数。ペイロード９〜１５ＲＴＰヘッダのペイロード・タイプ（ＰＴ）フィー・タイプルドに対応する７ビット数。未定義の全てのビット（０〜１および４〜７）は予約されており、ゼロにセットされる。定義されたビットの位置は、ＲＴＰヘッダ中と同じビット位置である。ＲＴＰシーそのパケットについてのＲＴＰシーケンス番号を指定すケンス番号る１６ビット整数。ＲＴＰサーバは、パケットを伝送する前に、ランダム・オフセットをこのシーケンス番号に追加する。このフィールドにより、パケットの再伝送が可能となる。例えば、同じパケットを、同じシーケンス番号および異なる（後の）パケット伝送時間でアセンブルすることができる。例えば、持続時間が５分のテキスト・サンプルを１０秒ごとに再伝送し、オリジナルのサンプルの伝送をミスしたクライアント（おそらくはその最中にムービーの再生を開始した）が、最大でも１０秒後には「リフレッシュ」されるようにすることができる。エントリ・カウントデータ・テーブル中のエントリ数を指定する１６ビットの符号のない整数。データ・テーブルＲＴＰパケットのペイロード部分に置かれるデータを定義するテーブル。このテーブルは、データを取り出すことができる様々な箇所を定義するものであり、テーブル４に示す。

【０１５４】

【表４】

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

【０１５６】Ｎｏ−Ｏｐデータ・モードデータ・テーブル・エントリは、ｎｏ−ｏｐモードにつ
いて以下の形式を有する。フィールド記述：データ・ソース＝０値ゼロは、このデータ・テーブル
・エントリが無視されることを示す。

【０１５７】即値データ・モードデータ・テーブル・エントリは即値モードについて以下
の形式を有する。フィールド記述：データ・ソース＝１値１は、そのデータが、それに続
くデータのバイトから直ちにとられることを示す。即値長さそれに続くデータからとられるバ
イト数を示す８ビット整数。正当な値の範囲は０から１
４である。即値データパケットのペイロード部分に置か
れる１４バイトのデータ。即値長さによって示される第
１のバイト数だけが使用される。

【０１５８】サンプル・モードデータ・テーブル・エントリは、サンプル・モードについて以下の形式を有する。フィールド記述：データ・ソース＝２値２は、そのデータがトラックのサンプル・データから取られることを示す。トラック参照索引サンプル・データがどのトラックからのものであるかを示す値。値ゼロは、使用されるメディア・トラックが正確に１つ参照されることを意味する。値１から１２７は、ヒント・トラック参照アトム・エントリへの索引であり、どのオリジナル・メディア・トラックからそのサンプルが読み取られるかを示す。値−１は、ヒント・トラック自体、すなわち現在解析されているヒント・サンプルと同じトラックからのサンプルが使用されることを意味する。圧縮ブロック当圧縮ブロック当たりのサンプルフィールド中のサンプたりのバイトル数を圧縮することによって生じるバイト数を指定する１６ビットの符号のない整数。値ゼロは値１と等価である。圧縮ブロック当圧縮ブロック当たりの未圧縮サンプルを指定する１６たりのサンプルビットの符号のない整数。値ゼロは値１と等価である。長さコピーするサンプル中のバイト数を指定する１６ビット整数。サンプル番号トラックのサンプル番号を指定する３２ビット整数。オフセットコピーを開始するサンプルの冒頭からのオフセットを指定する３２ビット整数。ヒント・トラック中のサンプルを参照する場合には、これが一般に追加データ領域を指すことになる。

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

【０１６０】サンプル記述モードデータ・テーブル・エントリは、サンプル記述モードに
ついて以下の形式を有する。フィールド記述：データ・ソース＝３値３は、そのデータがメディア・
トラックのサンプル記述テーブルから取られることを示
す。トラック参照索引サンプル・データがどのトラック
からのものであるかを示す値。値ゼロは、使用されるメ
ディア・トラックが正確に１つ参照されることを意味す
る。値１から１２７は、ヒント・トラック参照アトム・
エントリへの索引であり、どのオリジナル・メディア・
トラックからそのサンプルが読み取られるかを示す。値
−１は、ヒント・トラック自体、すなわち現在解析され
ているヒント・サンプルと同じトラックからのサンプル
記述が使用されることを意味する。予約ゼロにセットされる４バイト。長さコピーされるサンプル中のバイト
数を指定する１６ビット整数。サンプル記述索引メディアのサンプル記述テーブル
中への索引を指定する３２ビット整数。オフセットコピーを開始するサンプルの冒頭
からのオフセットを指定する３２ビット３２ビット整
数。追加データデータ・テーブル中のヒント・ト
ラック・サンプル・モードのエントリによって指示され
るデータを含む可変長フィールド

【０１６１】付録Ｄ−ＭＰＥＧ−２トランスポートにつ
いてのヒント・トラック形式の例この節では、エレメン
タリ・ストリームを保持するＱｕｉｃｋＴｉｍｅムービ
ーからのＭＰＥＧ−２トランスポートをストリーミング
するための簡単なトラック形式の一例を与える。

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

【０１６３】全てのＭＰＥＧ−２トランスポート・パケ
ットのサイズは１８８バイトであるので、パケット・サ
イズは一般に問題にならない。本発明の一例では、各ト
ランスポート・パケット（ＭＰＥＧ−２トランスポート
・プロトコル）は、１つのメディア・トラックからのペ
イロード・データを含む。これにより、各トランスポー
ト・パケットについて比較的簡単なヒント記述が可能と
なる。本発明の一例では、このような各ヒントは、各ト
ランスポート・パケット上にどのヘッダ・データが現れ
るかを記述し、次いでそのトランスポート・パケットに
ついて適当なメディア・トラック中のペイロードを指示
する。ＰＳＩパケットなど、メディア・トラックと対応
しないパケットについては、ヒントは、１８８バイトの
ヘッダ・データを記述することができ、任意のメディア
・トラック参照は無関係とみなすことができる。メディ
ア・トラックと対応するパケットについては、ヘッダ・
データは、トランスポート・ヘッダ、可能な適合ヘッダ
（ｐｏｓｓｉｂｌｅａｄａｐｔａｔｉｏｎｈｅａｄ
ｅｒ）、ＰＥＳパケットを開始するトランスポート・パ
ケットについてのＰＥＳヘッダなどの情報を反映するこ
とができる。

【０１６４】（タイプ「ｓｔｓｄ」の）サンプル記述ア
トム中のＭＰＥＧ−２トランスポートのヒント・トラッ
クを参照する。このアトムは、サンプル記述テーブルを
含み、このテーブル中のエントリは、メディア・タイプ
に基づいて様々である。本発明の一例では、ヒント・ト
ラックはテーブル１に示す構造から始まる。追加データ
・テーブルは、テーブル２に示す構造を有するエントリ
を保持することができる。

【０１６５】本発明の一例では、ヒント・トラックがＭ
ＰＥＧ−２トランスポートのヒント・トラックである場
合には、ヒント・トラックのサンプル記述エントリ中の
データ形式は「ｍ２ｔ」となり、最大パケット・サイズ
は常に１８８バイトとなる。このような記述エントリで
は、以下のテーブル５〜７に示すタイプを、追加データ
・テーブル中に見ることができる。

【表５】

【表６】

【表７】

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

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

【表８】

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

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

【表９】

【０１７０】本発明の一例では、ヒント・サンプルはそ
れらのオフセットをメディア・サンプルまたはファイル
・オフセットに関連して記述することができる。これら
にはそれぞれ利点および欠点がある。ヒント・サンプル
は、メディア・サンプルに関連してペイロードを指定す
る場合には、メディア・トラックを含むファイルの追加
編集に対してより弾性的（ｒｅｓｉｌｉｅｎｔ）になる
が、送達のための追加処理を必要とすることがある。ヒ
ント・サンプルは、ファイル・オフセットに関連してペ
イロードを指定する場合には、比較的迅速にペイロード
・データにアクセスすることができるが、メディア・ト
ラックを含むファイルを編集することでヒントが無効に
なることがある。

【０１７１】付録Ｄ−ファイルの例以下に、本発明の一実施形態による、比較的重要性の低
いフィールドおよびオブジェクトの一部は省略し（ここ
では省略記号“”でマークする）、またいくつかの架空
の番号でＲＴＰを介したストリーミングに備えたファイ
ルの全体的な構造を示す、比較的短い（６フレーム）サ
ンプル・ファイルを与える。メディア・データは省略
し、メタ・データのみを示す。

【０１７２】

【付表】

【図面の簡単な説明】

【図１】従来技術の１つのトラックを有する単純なムー
ビーの構造の一例を示す図である。

【図２】従来技術の独立型ムービーの一例を示す図であ
る。

【図３】本発明による方法の一例を示す流れ図である。

【図４】本発明のヒント・トラックの一例を示す図であ
る。

【図５】本発明のヒント・トラックのもう１つの例を示
す図である。

【図６】本発明の一実施形態による、メディア・データ
を交換および／または処理することができるコンピュー
タ・システムのネットワークを示す図である。

【図７】本発明の一実施形態に従って使用することがで
きるデジタル処理システムを示すブロック図である。

【図８】本発明の一実施形態による、ヒントを利用して
メディア・データを転送するシステムを示すブロック図
である。

【図９】本発明の一実施形態による、ヒントを利用して
メディア・データを転送するシステムを示すブロック図
である。

【図１０】本発明の一実施形態による、メディア・デー
タ伝送を実現するためにヒントを生成する方法を示す流
れ図である。

【図１１】本発明の一実施形態による、ヒントに従って
受信側システムが受信したメディア・データを処理する
方法を示す流れ図である。

【図１２】本発明の一実施形態による、ジェネレータな
どのデジタル処理システムがアクセスすることができる
機械可読記憶媒体の一例を示す図である。

【図１３】本発明の一実施形態による、サーバなどのデ
ジタル処理システムがアクセスすることができる機械可
読記憶媒体の一例を示す図である。

【図１４】本発明の一実施形態による、受信側システム
やその他のデジタル処理システムなどのデジタル処理シ
ステムがアクセスすることができる機械可読記憶媒体の
一例を示す図である。

【図１５】本発明の一実施形態による、メディアおよび
ヒント情報を記憶／トランスポートするデータ記憶およ
び／または通信媒体を示す図である。

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１３年３月７日（２００１．３．７）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１】

【図２】

【図３】

【図６】

【図４】

【図５】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

───────────────────────────────────────────────────── フロントページの続き (72)発明者ジーガン，ジェイアメリカ合衆国・95129・カリフォルニア州・サンホゼ・プロスペクトロード 212番・5475 (72)発明者ゴン，ケヴィン・エルアメリカ合衆国・94086・カリフォルニア州・サニーベイル・エスカロンアベニュ 515番・955 (72)発明者ペリヤナン，アラグアメリカ合衆国・94555・カリフォルニア州・フレモント・フィンニガンテラス・ 34113 (72)発明者シンガー，デイビッド・ダブリュアメリカ合衆国・94127・カリフォルニア州・サンフランシスコ・ワウォナストリート・268 Ｆターム(参考） 5K030 HA08 HB01 HB02 HB15 HB28 HB29 JA05 KA04 5K034 CC02 CC05 HH01 HH12 HH14 HH15 HH17 HH18 HH42 MM18 MM25 MM31 MM39

Claims

【特許請求の範囲】

【請求項１】デジタル処理システムによって実施され
る、メディア・データを処理する方法であって、時間に関係したメディア・データのシーケンスをある伝
送プロトコルに従ってどのようにして伝送するかを示す
データのセットを、デジタル記憶システムから取り出す
ことを含み、前記データのセットが、前記時間に関係し
たメディア・データのシーケンスに関連するがそれとは
別個の、時間に関係したデータのシーケンスである方
法。
【請求項２】前記時間に関係したメディア・データの
シーケンスを表すデータのパケットを前記伝送プロトコ
ルに従って伝送することさらに含む請求項１に記載の方
法。
【請求項３】前記パケットのそれぞれについて、前記
データのセットが、前記時間に関係したメディア・デー
タのシーケンスに関連した画像データのシーケンスまた
はオーディオ・データのシーケンスの少なくとも一方の
中のデータを参照する請求項１に記載の方法。
【請求項４】前記時間に関係したメディア・データの
シーケンスを前記データのセットに従ってパケット化す
ることをさらに含む請求項１に記載の方法。
【請求項５】実行可能プログラム命令を含む機械可読
媒体であって、この実行可能プログラム命令が、デジタ
ル処理システム上で実行されたときにそのデジタル処理
システムに、時間に関係したメディア・データのシーケンスをある伝
送プロトコルに従ってどのようにして伝送するかを示す
データのセットを取り出すことを含む方法であり、前記
データのセットが、前記時間に関係したメディア・デー
タのシーケンスに関連するがそれとは別個の、時間に関
係したデータのシーケンスである方法を実行させる機械
可読媒体。
【請求項６】前記時間に関係したメディア・データの
シーケンスを表すデータを前記データのセットに従って
伝送することをさらに含む請求項５に記載の機械可読媒
体。
【請求項７】前記データのセットが指示するデータの
トラックとして記憶される請求項５に記載の機械可読媒
体。
【請求項８】前記伝送プロトコルがパケット・データ
・プロトコルを含む請求項５に記載の機械可読媒体。
【請求項９】前記方法が、前記時間に関係したメディア・データのシーケンスの形
式を決定すること、および前記時間に関係したメディア
・データを前記データのセットに従ってパケット化する
ことをさらに含み、前記伝送プロトコルが、前記形式を有する前記時間に関
係したメディア・データのシーケンスを伝送するために
使用され、前記パケット化で、前記形式および前記プロ
トコルを使用して、前記時間に関係したメディア・デー
タのシーケンスをパケット化する請求項５に記載の機械
可読媒体。
【請求項１０】前記方法が、前記時間に関係したメディア・データのシーケンスを表
すデータのパケットを前記伝送プロトコルに従って伝送
することをさらに含む請求項９に記載の機械可読媒体。
【請求項１１】前記パケットのそれぞれについて、前
記データのセットが、前記時間に関係したメディア・デ
ータのシーケンスに関連した画像データのシーケンスま
たはオーディオ・データのシーケンスの少なくとも一方
の中のデータを参照する請求項１０に記載の機械可読媒
体。
【請求項１２】ある伝送プロトコルに従う時間に関係
したメディア・データのシーケンスの伝送に関連するデ
ータのセットを受信するように構成されたポートであっ
て、前記データのセットが前記時間に関係したメディア
・データのシーケンスに関連するがそれとは別個の、時
間に関係したデータのシーケンスであるポートと、前記データのセットを受信するように前記ポートに結合
された、前記時間に関係したメディア・データのシーケ
ンスを前記データのセットに従ってパケット化する処理
ユニットとを含む装置。
【請求項１３】前記処理ユニットに結合された、前記
時間に関係したメディア・データのシーケンスを表すデ
ータのパケットを前記伝送プロトコルに従って伝送する
送信機をさらに含む請求項１２に記載の装置。
【請求項１４】前記パケットのそれぞれについて、前
記データのセットが、前記時間に関係したメディア・デ
ータのシーケンスに関連した画像データのシーケンスま
たはオーディオ・データのシーケンスの少なくとも一方
の中のデータを参照する請求項１３に記載の装置。
【請求項１５】メディア・データを処理する装置であ
って、時間に関係したメディア・データのシーケンスをある伝
送プロトコルに従ってどのようにして伝送するかを示す
データのセットを取り出す手段であり、前記データのセ
ットが、前記時間に関係したメディア・データのシーケ
ンスに関連するがそれとは別個の、時間に関係したデー
タのシーケンスである手段と、前記データのセットに従って前記時間に関係したメディ
ア・データのシーケンスをパケット化する手段とを含む
装置。
【請求項１６】前記時間に関係したメディア・データ
のシーケンスを表すデータのパケットを伝送する手段を
さらに含む請求項１５に記載の装置。
【請求項１７】前記パケットのそれぞれについて、前
記データのセットが、前記時間に関係したメディア・デ
ータのシーケンスに関連した画像データのシーケンスま
たはオーディオ・データのシーケンスの少なくとも一方
の中のデータを参照する請求項１６に記載の装置。
【請求項１８】デジタル処理システムによって実施さ
れる、メディア・データを処理する方法であって、第２の時間に関係したデータのシーケンスをある伝送プ
ロトコルに従ってどのようにして伝送するかを示す第１
の時間に関係したデータのシーケンスを取り出すこと、
および前記第１の時間に関係したデータのシーケンスに
従って前記第２の時間に関係したデータのシーケンスを
パケット化することを含み、前記第２の時間に関係した
データのシーケンスが時間ベースのメディアに関連し、
前記第１の時間に関係したデータのシーケンスが前記第
２の時間に関係したデータのシーケンスに関連する方
法。
【請求項１９】前記伝送プロトコルに従って、前記第
２の時間に関係したデータのシーケンスを表すデータの
パケットを伝送することをさらに含む請求項１８に記載
の方法。
【請求項２０】前記パケットのそれぞれについて、前
記第１の時間に関係したデータのシーケンスが、前記第
２の時間に関係したデータのシーケンスに関連した画像
データのシーケンスまたはオーディオ・データのシーケ
ンスの少なくとも一方を参照する請求項１９に記載の方
法。
【請求項２１】前記第２の時間に関係したデータのシ
ーケンスが読取り専用メモリ（ＲＯＭ）に記憶される請
求項２０に記載の方法。
【請求項２２】実行可能プログラム命令を含む機械可
読媒体であって、この実行可能プログラム命令が、デジ
タル処理システム上で実行されたときにそのデジタル処
理システムに、時間に関係したメディア・データのシーケンスをある伝
送プロトコルに従ってどのようにして伝送するかを示す
データのセットを取り出すことを含む方法であり、前記
データのセットが前記時間に関係したメディア・データ
のシーケンスに関連する時間に関係したデータのシーケ
ンスである方法を実行させる機械可読媒体。
【請求項２３】前記時間に関係したメディア・データ
のシーケンスを表すデータを前記データのセットに従っ
て伝送することをさらに含む請求項２２に記載の機械可
読媒体。
【請求項２４】前記データのセットが指示するデータ
のトラックとして記憶される請求項２２に記載の機械可
読媒体。
【請求項２５】前記伝送プロトコルがパケット・デー
タ・プロトコルを含む請求項２２に記載の機械可読媒
体。
【請求項２６】前記方法が、前記時間に関係したメディア・データのシーケンスの形
式を決定すること、および前記時間に関係したメディア
・データを前記データのセットに従ってパケット化する
ことをさらに含み、前記伝送プロトコルが、前記形式を有する前記時間に関
係したメディア・データのシーケンスを伝送するために
使用され、前記パケット化で、前記形式および前記プロ
トコルを使用して、前記時間に関係したメディア・デー
タのシーケンスをパケット化する請求項２２に記載の機
械可読媒体。
【請求項２７】前記方法が、前記時間に関係したメディア・データのシーケンスを表
すデータのパケットを前記伝送プロトコルに従って伝送
することをさらに含む請求項２６に記載の機械可読媒
体。
【請求項２８】前記パケットのそれぞれについて、前
記データのセットが、前記時間に関係したメディア・デ
ータのシーケンスに関連した画像データのシーケンスま
たはオーディオ・データのシーケンスの少なくとも一方
の中のデータを参照する請求項２７に記載の機械可読媒
体。