(57)【特許請求の範囲】
【請求項１】
複数のクライアントにメディアをストリーミングする方法であって、
メディア・トラックから第１のクライアントにメディアをストリーミングするための要求を受け取ること、
メディア・トラックからのメディアの識別および取出しを容易にするメタデータのセットをメディア・トラックから抽出すること、
前記抽出されたメタデータのセットをメモリに格納すること、
前記格納されたメタデータを第１のファイル・トラック・ハンドルを使用してアクセスして、第１のストリーミングで第１のクライアントにメディアをストリーミングすること、および
前記格納されたメタデータを第２のファイル・トラック・ハンドルを使用してアクセスして、第２のストリーミングで第２のクライアントにメディアをストリーミングすること
を含み、
前記メタデータは前記要求が最初に行われた時に１回だけ抽出されて前記メモリへ格納され、前記第１、第２のクライアントがそのメモリに格納されたメタデータを共有する方法。
【請求項２】
前記第１のストリーム用のメディア・トラックからメディアを取り出すための第１のファイル記述子を維持すること、および 前記第２のストリーム用のメディア・トラックからメディアを取り出すための第２のファイル記述子を維持することをさらに含む請求項１に記載の方法。
【請求項３】
メディア・トラックがライブ・メディア・イベントのトラックである請求項１に記載の方法。
【請求項４】
メディア・トラックが事前に記録されたメディア・プログラムのトラックである請求項１に記載の方法。
【請求項５】
メディアを複数のクライアントへストリーミングするために単一セットのメディア・メタデータを使用する方法であって、
メディアに対応するメタデータを含む第１のメディア・トラックから、第１のクライアントにメディアをストリーミングするための要求を受け取ること、
前記メタデータの１つのコピーをメモリ内に維持するように構成されたトラック・モジュールを呼び出すこと、および 第１のクライアントにメディアをストリーミングするために第１のトラック・ハンドルを動作させることを含み、前記第１のトラック・ハンドルが前記ストリーミングするために前記メタデータにアクセスするものであって、
さらに前記方法が、
前記第１のクライアントへのメディアの前記ストリーミングが終了する前に、第２のクライアントへのメディアのストリーミングのための要求を受け取ること、および
第２のクライアントにメディアをストリーミングするために第２のトラック・ハンドルを動作させることを含み、
前記第２のトラック・ハンドルが前記ストリーミングするために前記メタデータにアクセスするものであって、
前記メタデータは、第１のメディア・トラックからのメディアの取り出しを容易にするものであるとともに、前記要求が最初に行われた時に１回だけ前記メモリへコピーされ、このコピーされたメタデータが前記第１、第２のクライアントに共有される方法。
【請求項６】
前記第１のトラック・ハンドルの動作が、第１のファイル・トラックからメディアを取り出すために第１のファイル記述子を使用することを含み、
前記第２のトラック・ハンドルの動作が、第１のファイル・トラックからメディアを取り出すために第２のファイル記述子を使用することを含む請求項５に記載の方法。
【請求項７】
前記第１のトラック・ハンドルの動作が、
前記メタデータへの第１の参照セットを確立すること、
第１の時間指標に関して第１のクライアントにストリーミングされるメディアの第１の部分を識別するために、前記第１の参照セットを使用すること、および
第１のメディア・トラックの中で前記第１のメディア部分を見つけ出すために、前記第１の参照セットを使用すること
を含む請求項５に記載の方法。
【請求項８】
前記第２のトラック・ハンドルの動作が、
前記メタデータへの第２の参照セットを確立すること、
第２の時間指標に関して第２のクライアントにストリーミングされる第２のメディア部分を識別するために、前記第２の参照セットを使用すること、および
第１のメディア・トラックで前記第２のメディア部分を見つけ出すために、前記第２の参照セットを使用すること
を含む請求項７に記載の方法。
【請求項９】
前記第１の参照セットおよび前記第２の参照セットが、前記メタデータに同時にアクセスするために使用される請求項８に記載の方法。
【請求項１０】
前記第１のストリーミングおよび前記第２のストリーミングが終了した後に、前記メタデータをメモリから除去することをさらに含む請求項１に記載の方法。
【請求項１１】
コンピュータによって実行されたときに、複数のクライアントにメディアをストリーミングする方法をコンピュータに実行させる命令を格納する、コンピュータ読取り可能記憶メディアであって、前記方法が、
メディア・トラックから第１のクライアントにメディアをストリーミングするための要求を受け取ること、
メディア・トラックからのメディアの識別および取出しを容易にするメタデータのセットをメディア・トラックから抽出すること、
前記抽出されたメタデータのセットをメモリに格納すること、
前記格納されたメタデータを第１のファイル・トラック・ハンドルを使用してアクセスして、第１のストリーミングで第１のクライアントにメディアをストリーミングすること、および
前記格納されたメタデータを第２のファイル・トラック・ハンドルを使用してアクセスして、第２のストリーミングで第２のクライアントにメディアをストリーミングすること
を含み、
前記メタデータは前記要求が最初に行われた時に１回だけ抽出されて前記メモリへ格納され、前記第１、第２のクライアントがそのメモリに格納されたメタデータを共有する、コンピュータ読取り可能記憶メディア。
【請求項１２】
メディア・トラックから複数のクライアントへメディアを同時にストリーミングするように構成されたデータ構造を含むコンピュータ読取り可能記憶メディアであって、前記データ構造が、
メディア・トラックの時間指標とメディアの対応する部分とを関連付け、メディア・トラックの中で前記対応する部分を見つけ出すように構成された、前記複数のクライアントに共有されるメタデータのセットであって最初のストリーミング要求の際に１回だけ作成されるメタデータのセットを含み、
前記メタデータのセットが、複数のクライアント・ストリーム・ハンドルそれぞれによって同時にアクセスされ、それぞれのクライアントへのストリーミングのためにメディアの異なる部分を取り出すため、各ストリーム・ハンドルが異なるクライアントに関連付けられる、コンピュータ読取り可能記憶メディア。
【請求項１３】
メディアをクライアントにストリーミングするための装置であって、
第１の記憶デバイスに格納されたメディア・プログラムの第１のトラックであってメディアと、このメディアへのアクセスを容易にするためのメタデータとを含んだ第１のトラックと、
第１のメモリと、
異なるクライアントへメディアをストリーミングするようにそれぞれが構成されたトラック・ハンドル・モジュールのセットと、
前記トラック・ハンドル・モジュールによる共用アクセスのために、前記第１のメモリ内に前記メタデータを最初のストリーミング要求の際に１回だけ前記第１のトラックから抽出して格納するように構成されたトラック・モジュールと
を含み、前記トラック・ハンドル・モジュールがメディアの部分を識別するために前記格納されたメタデータにアクセスし、第１の記憶デバイス上にある前記部分を見つけ出す装置。
【請求項１４】
前記トラック・ハンドル・モジュールそれぞれに、第１の記憶デバイスからメディアを取り出すための別々のファイル記述子が割り当てられる請求項１３に記載の装置。
【請求項１５】
前記トラック・ハンドル・モジュールそれぞれが、前記第１のメモリ内の前記メタデータに同時にアクセスする請求項１３に記載の装置。
【請求項１６】
前記メタデータへの前記同時アクセスが、メディアの異なる部分を識別するように構成された請求項１５に記載の装置。
【請求項１７】
前記メディア部分が前記第１のメディア・トラック内の時間指標に関連付けられ、前記メタデータが、所与の時間指標について前記関連付けられたメディア部分を識別するように構成された請求項１３に記載の装置。
【請求項１８】
さらに前記メタデータが、所与のメディア部分について、前記第１の記憶デバイスの前記所与のメディア部分が格納された場所を識別するように構成された請求項１７に記載の装置。
【発明の詳細な説明】
【０００１】
（背景）
本発明は、コンピュータ・システムの分野に関する。より詳細には、メディアのトラックがタイミング、オフセット、および他の情報を提供するメタデータを関連付けたメディア・ストリーミング・システムで、トラック・メタデータのコピーを１つだけ使用して複数のクライアントにメディア・トラックをストリーミングするための装置および方法が提供される。
【０００２】
メディア・ストリーミング・システムは、部分的に記録されたかまたはライブのメディア・プログラムやイベントをクライアント・デバイス（たとえば、コンピュータ、メディア・プレーヤなど）へストリーミングするように設計されている。クライアントは、メディア・ストリームを受け取りながら（すなわち、ストリーミングが完了する前に）再生することができるため、メディア・プログラムまたはイベントを高速で、またはリアルタイムで楽しむことができる。
【０００３】
ストリーミングされたメディアは複数のトラックからなる場合が多い。たとえばオーディオビジュアル・プログラムは、一般に、少なくとも１つのオーディオ・トラックおよび少なくとも１つのビデオ・トラックを含む。各トラックは、適切なタイプ（たとえば、オーディオ、ビデオ）のメディアを含み、メディアを正しくストリーミングするのに使用されるメタデータも含むことができる。トラックのメタデータは、プログラム内の所与の時間指標に再生されるはずのメディア・セグメントまたはサンプルがファイルのどこに配置されているかを特定するためなど、メディア・セグメントまたはサンプル（または他のメディア・ユニット）を識別する情報を含む。したがってメディア・トラックのメタデータは、メディア・ストリーミング・サーバなどが正しいシーケンス、適切なタイミングなどで、メディア・トラックをストリーミングするために使用することができる。
【０００４】
メディア・トラックまたはプログラムを複数のクライアントにストリーミングする場合、既存のシステムは通常、各クライアントに対して各トラックのメタデータのコピーを別々に格納する。より具体的に言えば、これらのシステムは、新しいクライアントがメディアを要求するたびに、ストリーミングされるメディアを含むメディア・ファイルからメタデータを繰返し抽出し格納する。多数のクライアントにサービスを提供している場合、サーバのリソース（たとえばメモリ、処理装置、ディスク使用など）が大量に要求される可能性があり、サーバがサポートできるクライアントの数が制限される場合がある。
【０００５】
また、既存のシステムの中には、典型的には、ストリーミングされるメディアを含むメディア・ファイルにアクセスするためのファイル記述子を１つしか割り振らないものがある。その記述子は特定のメディア・ストリームを受け取るすべてのクライアント間で共有しなければならない。これによって、各クライアントが異なるメディア・セグメントまたはサンプルをシークして（すなわち見つけて）抽出しようとするたびにクライアント・ストリーミングの間で多くの争いが発生することになる。
【０００６】
さらに、マルチトラックのメディア・プログラムをクライアントにストリーミングする場合、既存のメディア・ストリーミング・システムは、適切な対応するトラック・メディアがプログラムの時間単位ごとにストリーミングまたは再生されるように、トラック間での同期を維持しようとする。しかし、同期が失われると回復できない場合がある。たとえば、１つのトラックのメディアを、他のトラックのメディアよりも低速で（たとえば記憶デバイスから）受け取する場合、既存のメディア・ストリーミング・システムは、たとえトラックが同期からさらに外れるようになっても、単にメディア・ストリーミングだけを続行することがある。他のシステムでは、同期が失われた場合、その状況の修正を試みることなく、単にメディア・ストリーミングを中止するだけのこともある。
【０００７】
（概要）
したがって、本発明の一実施態様では、メディア・トラックを複数のクライアントにストリーミングするための、メディア・トラックのメタデータの１つのコピーを共用する装置および方法が提供される。
【０００８】
この実施態様では、単一のメディア・トラックのメタデータを格納するために１つのファイル・トラックが生成される。複数のトラックを含むメディア・プログラムの場合、それぞれのトラックに別々のファイル・トラックが生成される。メディアの各クライアント・ストリーミングには、別々のファイル・トラック・ハンドルが確立される。各ファイル・トラック・ハンドルは、そのクライアント・ストリームと、メディア・メタデータの単一のインスタンスとの間でインターフェースとしての役割を果たす。その際、異なるクライアント・ストリームがメディア内の異なる時間指標に存在してもよい。
【０００９】
本発明の他の実施態様では、トラックのメディアを格納しているファイルにアクセスするために、単一のメディア・トラックに関連付けられたすべてのファイル・トラック・ハンドル間で、単一のファイル記述子が共用される。
【００１０】
（詳細な説明）
以下の説明は、当分野の任意の技術者が本発明を作成および使用できるようにするために提示され、本発明の特定の応用例およびその要件という状況で提供される。当分野の技術者であれば、開示された実施形態に対する様々な修正が容易に明らかとなり、本明細書に定義された一般的な原理は、本発明の精神および範囲を逸脱することなく他の実施形態および応用例に適用することができる。したがって本発明は、例示された実施形態に限定されるものではなく、本明細書に開示された原理および特徴に適合する最も広い範囲が与えられる。
【００１１】
本発明の実施形態が実行されるプログラム環境は、ほぼすべての構成のコンピュータまたは通信デバイス（たとえば、有線、無線、携帯用、デスクトップなど）にデータまたはメディア・ストリーミング・サービスを提供するように構成されたコンピュータ・サーバなどの汎用コンピュータまたは、特定用途向けデバイスを例示的に含んでいる。こうしたコンピュータおよび他のデバイス（たとえば処理装置、メモリ、データ記憶装置、ディスプレイなど）の詳細はよく知られているため、理解しやすいように省略されている。さらに本発明は、オブジェクト指向プログラミング環境で実施できるものとして記載されている。当分野の技術者であれば理解されるように、実施形態の好適な変形形態は、他のプログラミング・モデルまたはフレームワークを使用して実施することが可能である。
【００１２】
本発明の一実施形態では、メディアまたはデータ・ストリーミング・サーバが、複数のクライアントにメディアまたはデータをストリーミングするように構成されている。複数のクライアントにストリーミングされることになっているメディア・プログラムまたはイベントには、１つまたは複数のトラック（たとえば、オーディオ、ビデオ）が含まれ、そのそれぞれを１つまたは複数のメディア・ファイルに格納することができる。メディア・プログラムに対する第１の要求が受け取られると、トラックのメタデータが取り出され、ファイル・トラックに格納される。メタデータは、（たとえばトラックのメディアと他のプログラム・トラックとの同期を取るための）タイミング、メディア・セグメントまたはメディア・サンプル（または他のメディア・ユニット）のメディア・ファイル内の位置、メディア・ユニットの階層（たとえば、まとまり、まとまりを含むサンプル）、編集テーブル、などに関する情報を含むことができる。
【００１３】
メディア・トラックがストリーミングされる各クライアントについて、ファイル・トラック内のメタデータを参照するために別々のファイル・トラック・ハンドルが確立される。したがって、各クライアント・ストリームについてトラックのメタデータの別々のコピーを格納する代わりに、各クライアントのファイル・トラック・ハンドルは、タイミングの位置を取り出し、メディア・ファイル内のメディア・セグメントを探し出すなどのために、単一のファイル・トラックを（たとえばポインタを使用して）参照する。さらに、各ファイル・トラック・ハンドルには、メディアを探して取り出すために、トラックのメディア・ファイルにファイル記述子が割り振られる。
【００１４】
本発明特有の実施形態について、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，ＩｎｃのＳｏｌａｒｉｓ（商標）オペレーティング・システムを実行中のシステムなどの、ＵＮＩＸ（登録商標）ベースのコンピュータ・システムからＱｕｉｃｋＴｉｍｅメディアをストリーミングするために実施可能なものとして以下に説明する。以下の説明からわかるように、こうした実施形態は、他のタイプのメディアおよび他のコンピュータ・システムで使用するように修正することができる。
【００１５】
例示的なメディア・ストリーミング・サーバ
メディア・ストリーミングとは、ユーザがプログラムまたはプレゼンテーション全体を自分のクライアント・デバイスにダウンロードしてしまうまで待つ必要なしに、メディア・コンテンツを受け取って楽しむことができるようにするものである。たとえばユーザは、プログラム全体を受け取るまで待つことなく、部分的に記録されたプログラムを楽しむか、またはライブ・イベントをリアルタイムで体験することができる。
【００１６】
メディアは、ユニキャスト・モードまたはマルチキャスト・モードでストリーミング可能である。ユニキャスト・モードの場合、ストリーミング・サーバはそれぞれの受取側クライアント・デバイスへの専用接続を維持し、ユーザに自分のストリーミングに対してかなりの制御権を認める。たとえばユーザは、ストリーミングの一時停止、ストリーミングされたメディアの巻戻しまたは早送り、あるいは他の制御機能の実行が可能である。ただし、これによって、多数のユーザが十分な帯域幅を使用できなくなる可能性がある。マルチキャスト・モードの場合、メディア・ストリーミング・サーバは、より少ない帯域幅を使用して、複数のユーザにプログラムを同時にストリーミングする。したがってこのタイプのストリーミングは、従来の同報通信に類似しており、ユーザは個々のストリーミングを介した制御権をほとんど持たない。ライブ・イベントは、多数のユーザにサービスを提供するために効率が良いことから、通常はマルチキャスト・モードでストリーミングされる。また、ライブ・イベントはリアルタイムで楽しむものであることから、ストリーミングされたメディアを操作する必要もほとんどない。
【００１７】
本発明の実施形態によるメディア・ストリーミング・サーバは、「反射」モード・オペレーションで動作することが可能であり、サーバは、メディア・ストリームを別のストリーミング・システムまたはサーバから（通常はマルチキャスト・モードで）受け取り、そのメディアを１人または複数のユーザに（ユニキャストまたはマルチキャスト・モードで）転送する。
【００１８】
リアルタイム・メディア・ストリーミングは、メディアの各フレームまたは他のユニットの配布が指定された順序および一定の時間枠内で実行されなければならないため、発行元サーバに制約を与える。したがってメディア・ストリーミング・サーバは、サービスを提供するクライアントの数にかかわらず、ユーザに提供するサービスの質が許容できないレベルまで下がることのないように、リアルタイム・メディア・ストリーミングの要求に合わせるよう努力しなければならない。たとえば、プログラムのタイプ（すなわちライブまたは事前記録済み）およびストリーミングのモード（すなわちユニキャストまたはマルチキャスト）にかかわらず、ストリーミングされるメディアは、一般に、移行時に消費する帯域幅を減らすために圧縮される。それにより、クライアントへのタイムリーなメディアの配布を確実にすることができる。
【００１９】
本発明の一実施形態に従ったメディア・ストリーミング・サーバは、ＱｕｉｃｋＴｉｍｅメディアおよび／または他の形式のメディアを、ユニキャストまたはマルチキャスト・モードで、私用のネットワークまたはインターネットなどの公衆がアクセス可能なネットワークを介してストリーミングするように構成されている。メディア・ストリームは、伝送メディアに適合するプロトコル・セットに従ってフォーマット化される。具体的に言えば、ＱｕｉｃｋＴｉｍｅメディアをストリーミングする場合、サーバは、クライアントのメディア・ストリーミング制御を容易にするためのＲＴＳＰ（Real-Time Streaming Protocol）用、クライアントへのストリームの配布および／または他のソースからのメディアの受取のためのＲＴＰ（Real-Time Transport Protocol）、ストリームの品質に関する情報の受取または交換のためのＲＴＣＰ（Real-Time Transport Control Protocol）、クライアントにメディアを記述するためのＳＤＰ（Session Description Protocol）などのために構成することができる。他の実施形態を他のメディア・プロトコルのために構成することもできる。
【００２０】
図１は、本発明の実施形態に従ってＱｕｉｃｋＴｉｍｅメディアをストリーミングするように構成されたメディア・ストリーミング・サーバ１０２を示す図である。図１では、メディア・ストリーミング・サーバ１０２がクライアント１１０、１１２にサービスを提供する。クライアントにストリーミングされるメディアは、記憶デバイス１０４から取り出される部分的に記録されたプログラム、またはサーバ１３０から（たとえばマルチキャスト同報通信１３０ａの一部として）受け取るリアルタイム・プログラムを含むことができる。したがってメディア・ストリーミング・サーバ１０２は、ライブ・イベント（たとえばコンサート、ニュース放送、スポーツ・イベント）、映画、ドキュメンタリ、トレーニング・ビデオ、教育用の番組またはクラスなどをストリーミングすることができる。
【００２１】
メディア・ストリーミングは、メディア・ストリーミング・サーバ１０２とクライアントとの間に複数の接続を必要とする場合がある。図１に示された実施形態では、第１の接続はクライアントがメディア・ストリーミングを制御できるようにするＲＴＳＰ（たとえば接続１１０ａ、接続１１２ａ）である。具体的に言えば、クライアントはＲＴＳＰ接続を使用してコマンドをメディア・ストリーミング・サーバに送信する。この実施形態でクライアントがサーバに提示できるメディア・ストリーム・コマンドには、サポートされているコマンドのリストを受け取るためのＯｐｔｉｏｎｓ、メディア・プログラムを記述するようにサーバにプロンプトを出すＤｅｓｃｒｉｂｅ、受け取りたい所望のトラック（各トラックはビデオ、オーディオなどの異なるメディア形式であってよい）を識別するためのＳｅｔｕｐ、メディア・トラックまたはプログラムを再生するためのＰｌａｙ、ストリーミングを一時的に停止するためのＰａｕｓｅ、ストリーミングを終了させるためのＴｅａｒｄｏｗｎ、などのコマンドが含まれる。したがってクライアント１１０は、たとえばサーバ１０２とのＲＴＳＰ接続１１０ａを確立し、Ｄｅｓｃｒｉｂｅコマンドを発行して、ストリーミングに使用可能なコンテンツおよびトラックの記述を受け取ることができる。その後クライアント１１０は、１つまたは複数のトラックに対してＳｅｔｕｐ要求を提示することができる。
【００２２】
クライアントがサーバに対してＳｅｔｕｐコマンドを発行すると、サーバは、選択されたトラックに対してＲＴＰ接続（たとえば接続１１０ｂ、接続１１２ｂ）およびＲＴＣＰ接続（たとえば接続１１０ｃ、接続１１２ｃ）を確立する。Ｐｌａｙコマンドを受け取ると、サーバはＲＴＰ接続を介してクライアントへのメディア・パケットのストリーミングを開始する。サーバおよびクライアントは、ＲＴＣＰ接続を介して、ストリームの品質を記述したＲＴＣＰパケットを交換することができる。Ｔｅａｒｄｏｗｎコマンドが発行されると、サーバは、発行元クライアントとの関連するストリーミング接続を閉じる。
【００２３】
メディア・ストリーミング・サーバによって使用される様々な接続は、サーバおよびクライアントが通信する通信メディア（たとえばインターネット）用のＴＣＰ（Transport Control Protocol）ソケットを使用することができる。本発明の他の実施形態では、ソケットを異なるプロトコル（たとえば、HTTP-HyperText Transport Protocol、FTP-File Transfer Protocol）に従って構成することができる。
【００２４】
すでに述べたように、図１のメディア・ストリーミング・サーバ１０２は、リアルタイムまたはライブのメディアをクライアントにストリーミングすることが可能であり、記録されたメディアをストリーミングすることも可能である。さらに、反射モード・オペレーションでは、メディア・ストリーミング・サーバは、他のサーバ（たとえばサーバ１３０）からのライブ・イベント、ビデオ・カメラ、同報通信など、他のエンティティから受け取ったメディアをクライアントに転送することができる。この状況では、メディア・ストリーミング・サーバ１０２はクライアントとして動作し、エンティティとの間で確立されたＲＴＰ接続を介してメディア・パケットを受け取る。
【００２５】
クライアント１１０、１１２は、メディア・ストリーミング・サーバ１０２からストリーミングされたメディアを再生するのに好適な、メディア・プレーヤを備える。ＱｕｉｃｋＴｉｍｅメディア・ストリーミングの場合、クライアントは、Ａｐｐｌｅ  Ｃｏｍｐｕｔｅｒ，Ｉｎｃから入手可能なものと同様に、ＱｕｉｃｋＴｉｍｅプレーヤを操作することができる。クライアント・コンピューティング・デバイスは、好適なメディアプレーヤが使用可能なほぼすべてのオペレーティング・システム（たとえば、Ｓｏｌａｒｉｓ、Ｍａｃ  ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ）を動作させることができる。クライアント・デバイスは、比較的低い帯域幅の通信機能（たとえば５６Ｋモデム）を備えることができるため、メディア・ストリームは、比較的遅いビット・レートで送信することができる。もちろん、より堅固なクライアントに対しては、より速いビット・レートも実施可能である。クライアントは、ＵＲＬ（Uniform Resource Locator）、ファイル名、プログラム名（たとえば映画の名前、歌の題名）などを提示することによって、ストリーミングされてくるメディアを識別することができる。
【００２６】
参照により本明細書に組み込まれた２００１年４月６日付出願の「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｈａｎｄｌｉｎｇ  Ｅｖｅｎｔｓ  Ｒｅｃｅｉｖｅｄ  ａｔ  ａ  Ｓｅｒｖｅｒ  Ｓｏｃｋｅｔ」という名称の米国特許出願第０９／ｘｘｘｘｘｘ号は、数の限られた通信ソケットを介して複数のクライアントに対してメディアをストリーミングするためのメディア・ストリーミング・サーバ１０２の構成を開示している。
【００２７】
単一のファイル・トラックを使用した複数クライアントへのメディア・ストリーミング
本発明の一実施形態では、メディア・ストリーミング・サーバは、ストリーミング・プロセスを容易にするためにメタデータを伴ったメディアをストリーミングする。たとえば、ＱｕｉｃｋＴｉｍｅメディア・トラックに関するメタデータは、メディアのどのユニットまたはどの部分（たとえば、オーディオ・サンプル、映画のセグメントなど）が、メディアのプログラム内の所与の時間指標に対応するか、およびメディア・ファイル内のどこにそれがあるかを示すことができる。この実施形態では、メタデータは１回だけアセンブルする（たとえば、所与のメディア・トラックについて１つまたは複数のメディア・ファイルから抽出する）ことができるが、これを使用して、そのトラックを複数のクライアントにストリーミングするのを容易にすることができる。したがってこの方式は、メタデータの別々のコピーがそれぞれ個々のクライアント・ストリーミングに対してアセンブルされる既存のストリーミング・システムよりは効率的である。
【００２８】
メタデータの助けを借りていったん抽出されたメディア・データは、ＲＴＰパケットに配置され、クライアントにストリーミングされる。メディア・データは、クライアントが処理できるほぼすべての形式でのストリーミングに備えることができる。具体的に言えば、メディアはその符号化、圧縮、または他の属性を変更せずに、パケットに配置することができる。
【００２９】
例示的に言えば、クライアントは、複数のトラックを含むメディア・ストリームを要求するか、または特定のトラックを個々に要求することができる。各トラックは独自のメタデータを有し、別々のストリームとしてクライアントに送信することができる（すなわち、複数のトラックを単一のストリームに組み合わせても組み合わせなくてもよい）。前述のように、本発明の一実施形態では、メディアはＲＴＰパケットで送信され、この場合、ストリーミングはＲＴＳＰコマンドを介してクライアントが制御可能であり、ストリームの品質はＲＴＣＰを介して報告可能である。本発明の他の実施形態では、他の好適なプロトコルが使用される。
【００３０】
メディア・ストリーミング・サーバがソースからのメディアを（ＲＴＰパケットとして）受け取り、それをクライアントにストリーミングするという反射モードで動作している場合、そのサーバはメディアのメタデータをメディアと一緒にまたはメディアに先立って受け取ることができる。
【００３１】
図２は、本発明の一実施形態により、トラックのメタデータの別々のコピーを別々に抽出または作成することなく、単一のファイル・トラックおよび複数のファイル・トラックを使用して、メディア・トラックを複数のクライアントにストリーミングする処理を示す図である。
【００３２】
例示された実施形態では、メディア・プログラム２００がオーディオ・トラック２０２およびビデオ・トラック２０４を含む。各トラックは、プログラムに関する指示されたメディアのタイプ（すなわちオーディオ、ビデオ）および、とりわけ、どのメディア・ユニット（たとえばオーディオ・サンプル、ビデオ・フレーム）がメディア・プログラム内の所与の時間指標に対応するかを識別し、所与のユニットがどのまとまり（たとえばメディア・ユニットのコレクション）に属するかまたは含まれるかを識別し、所与のまとまり内にあるメディア・ユニットをリスト表示し、所与のまとまりまたはメディア・ユニットがメディア・プログラム・ファイル２００内のどこに格納されるかを識別し、コンテンツ・ツールがトラック全体をコピーまたは圧縮することなくトラックの一部を挿入または削除できるようにする（たとえば、トラックを断片化できるようにする）編集テーブルを含む、などのメタデータを含む。例示的に言えば、オーディオ・トラック２０２およびビデオ・トラック２０４は、別々のファイル（またはファイルのセット）として格納される。ただし、別法として、異なるタイプのトラックまたは異なるタイプのトラックの一部を単一のファイルに格納することもできる。
【００３３】
メディア・トラックのメタデータは、トラックのメディアを含むファイル内に隣接して格納すること、トラックのメディア・ファイル全体に分配すること、または別々のトラックとして格納することもできる。
【００３４】
本発明のこの実施形態によれば、各トラックのメタデータは、抽出された後、別々のファイル・トラックに格納される。したがって、オーディオ・トラック２０２のメタデータはファイル・トラック２１２としてアセンブルされ、ビデオ・トラック２０４のメタデータはファイル・トラック２１４に格納される。トラック内の異なるタイプのメタデータは、別々のテーブル、リスト、または他のデータ構造として格納することができる。
【００３５】
メディア・プログラムのトラックがストリーミングされる各クライアントについて、別々のファイル・トラック・ハンドルが確立される。したがって、クライアント２３０ａの場合、それぞれファイル・トラック２１２および２１４のメタデータにアクセスするために、ファイル・トラック・ハンドル２２２ａ、２２４ａが確立される。同様に、クライアント２３０ｂの場合、オーディオ・トラック２０２用のファイル・トラック２１２に格納されたメタデータにはファイル・トラック・ハンドル２２２ｂがアクセスし、ビデオ・トラック２０４用のファイル・トラック２１４のメタデータにはファイル・トラック・ハンドル２２４ｂがアクセスする。例示的に言えば、各ファイル・トラック・ハンドルは、様々なタイプの情報にアクセスする際に使用する、１つまたは複数のポインタまたは関連付けられたファイル・トラックへの他の参照を含む。
【００３６】
さらに、所与のクライアント・ストリーミングに対する各ファイル・トラック・ハンドルまたはファイル・トラック・ハンドルのセットに、トラックのメディアを格納するメディア・ファイルにアクセスするための別々のファイル記述子を割り振ることもできる。したがって、オーディオ・トラック２０２およびビデオ・トラック２０４が別々のファイルに格納されている図２の実施形態では、ファイル・トラック・ハンドル２２２ａ、２２２ｂ、２２４ａ、２２４ｂそれぞれに、ストリーミング用のメディアを見つけ出して抽出するための独自のファイル記述子が割り振られる。
【００３７】
メディアをクライアントにストリーミングする間（たとえば、クライアントがトラックまたはプログラムの再生を要求した後）、クライアントのストリーミング用のファイル・トラック・ハンドルは、メディア固有のシーケンス（すなわち、メディアの各時間指標についてストリーミングするためのメディア・ユニット）を決定するためにファイル・トラックにアクセスする。この情報を使用して、ファイル・トラック・ハンドルはメディア・ファイルからメディアを抽出し、それがＲＴＰパケット（または他の好適なプロトコルに従って構成されたパケット）に配置され、ＲＴＰ接続を介してクライアントにストリーミングされる。クライアントがストリーミングを終了すると、ファイル・トラック・ハンドルは削除される。
【００３８】
本発明の一実施形態では、ファイル・トラックが、それへの参照を維持しているファイル・トラック・ハンドルの数を監視するように構成される。この実施形態では、関連するメディア・トラックのすべてのクライアントのストリーミングが終了すると、ファイル・トラックはそれ自体を削除し、他のプロセスまたはメディア・トラック用の追加のリソースを解放することができる。
【００３９】
図３は、本発明の一実施形態で使用されるいくつかのプログラムのオブジェクトを示す図である。例示されたプログラム・オブジェクトと同様に動作するように構成された、適切な対応するプログラムのモジュールを、オブジェクト指向でないプログラミング方法を備えたコンピュータ・システム用に生成することができる。
【００４０】
この実施形態では、Ｔｒａｃｋ  ３０２が、メディア・トラック用のメタデータをアセンブルし、複数のファイル・トラック・ハンドルが様々なクライアント・ストリームの代わりにメタデータを使用することができるように構成されたオブジェクトのクラスを表す。ライブまたはリアルタイムのイベント・メディアをストリーミングするためにメタデータをアセンブルするためのＬｉｖｅＴｒａｃｋ  ３２０、格納または部分的に記録されたメディア用のメタデータをアセンブルするためのＦｉｌｅＴｒａｃｋ  ３２２などの、複数タイプのトラック・オブジェクトをＴｒａｃｋ  ３０２から生成することができる。本発明の一代替実施形態では、１タイプのトラック・オブジェクト（たとえばＦｉｌｅＴｒａｃｋ  ３２２）を、部分的に記録されたメディアとライブ・メディアの両方を容易にストリーミングするように構成することができる。他の代替実施形態では、ライブ・メディアがトラックの形式ではないため、何らかの他の方式でクライアントに提供される場合がある。
【００４１】
ＱｕｉｃｋＴｉｍｅ  ＦｉｌｅＴｒａｃｋ  ３２２ａおよびＭＰＥＧ  ＦｉｌｅＴｒａｃｋ  ３２２ｂは、２つの特有のメディア形式（すなわちＱｕｉｃｋＴｉｍｅおよびＭＰＥＧ）用のメタデータを処理するように構成されたＦｉｌｅＴｒａｃｋオブジェクトを表す。Ｔｒａｃｋ  ３０２から生成されるオブジェクトは、ライブ・メディア、部分的に記録されたメディア、および／または他のメディアを処理するのに役立つ属性および方法を引き継ぐことができる。引き継がれた属性の中には、たとえば、所与のトラックを参照するトラック・ハンドルのカウントを維持するものもある。
【００４２】
ＴｒａｃｋＨａｎｄｌｅ  ３０４は、トラック・メタデータの共用コレクションを使用するクライアントへのトラック・メディア・ストリーミングを容易にするように構成されたオブジェクトのクラスを表す。例示的に言えば、ＬｉｖｅＴｒａｃｋＨａｎｄｌｅ  ３４０は、ライブ・メディア・ストリーミング用に構成されたＴｒａｃｋＨａｎｄｌｅオブジェクトのクラスを表し、ＦｉｌｅＴｒａｃｋＨａｎｄｌｅ  ３４２は、部分的に記録されたかまたは他に格納されたメディア用に構成されたＴｒａｃｋＨａｎｄｌｅオブジェクトのクラスを表す。本発明の一代替実施形態では、１タイプのトラック・ハンドル・オブジェクト（たとえば、ＦｉｌｅＴｒａｃｋＨａｎｄｌｅ  ３４２）を、部分的に記録されたメディアとライブ・メディアの両方をストリーミングするように構成することができる。他の代替実施形態では、ライブ・メディアがトラックの形式を取らないようにすることが可能であるため、本明細書に記載された以外の何らかの他の方式で、クライアントにサービスを提供することができる。
【００４３】
ＱｕｉｃｋＴｉｍｅメディア用のＱｕｉｃｋＴｉｍｅ  ＦｉｌｅＴｒａｃｋＨａｎｄｌｅ  ３４２ａおよびＭＰＥＧメディア用のＭＰＥＧ  ＦｉｌｅＴｒａｃｋＨａｎｄｌｅ  ３４２ｂなどのように、ＦｉｌｅＴｒａｃｋＨａｎｄｌｅ  ３４２から、様々なタイプのＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトを特定形式のメディア用にインスタンス化することが可能である。
【００４４】
本発明のこの実施形態では、ＴｒａｃｋＨａｎｄｌｅ  ３０４から導出されたそれぞれのＴｒａｃｋＨａｎｄｌｅオブジェクトが、メディア・プログラムまたはトラックの一定の時間指標に移動するため、（クライアントへのストリーミングの際に）メディア・データをバッファに読み込むためなどに好適な方法を含む。したがって、ＴｒａｃｋＨａｎｄｌｅオブジェクトは、メディア・トラックにおけるクライアントの現在の再生位置に関する状態情報を維持し、メディアパケットをクライアントに送信するための１つまたは複数のバッファ、およびメタデータにアクセスするための対応するＴｒａｃｋオブジェクトを指す１つまたは複数のポインタまたは参照を含むことができる。
【００４５】
ＦｉｌｅＴｒａｃｋオブジェクトが所与のメディア・トラック用にいったん確立されると、そのトラックに関する後続のクライアント要求は、トラックのメタデータを再度アセンブルするのではなく、確立されたＦｉｌｅＴｒａｃｋを使用する。したがって、ＦｉｌｅＴｒａｃｋオブジェクトは、新しいクライアント・ストリーミング用に新しいＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトをインスタンス化するように構成することができる。
【００４６】
図４は、本発明の一実施形態に従い、メディアのメタデータのコピーを１つだけ維持しながら、１つのトラックから複数のクライアントへのメディア・ストリーミングを処理する方法を実証する図である。この方法では、同じメディアを、異なるタイミングで各クライアントにストリーミングすることができる。すなわち、異なるクライアントは、任意の所与の時間に、メディア・トラック内の異なる時間指標からメディアをストリーミングすることができる。
【００４７】
例示された手順の状態４０２では、まだストリーミングされていない何らかの部分的に記録されたメディアをストリーミングするための要求が受け取られる。たとえば要求は、特定のメディア・トラックをセットアップおよび再生するためのＲＴＳＰコマンドとして受け取ることができる。他の形式の要求元メディアは、メディアの他のプロトコルまたは形式で使用することができる。
【００４８】
状態４０４では、要求されたメディアのメタデータへの共用アクセスを管理するために、メディア・ストリーミング・サーバがＴｒａｃｋオブジェクトを作成する。例示された手順は、ＦｉｌｅＴｒａｃｋオブジェクトの作成を示し、前述のように部分的に記録されたメディア・プログラムおよびトラック用に構成することができる。
【００４９】
状態４０６では、ＦｉｌｅＴｒａｃｋオブジェクトがメディア・トラックからメタデータを抽出して格納する。ＦｉｌｅＴｒａｃｋオブジェクトは、メタデータをアセンブルするために、メディア・トラックを含む１つまたは複数のファイルを解析しなければならない。
【００５０】
状態４０８では、ストリーム特有のクライアント・コンテキストとＦｉｌｅＴｒａｃｋオブジェクトによって保持されるトラック特有のメタデータとの間をマッピングまたはインターフェースするために、新しいクライアント・ストリーム用にＦｉｌｅＴｒａｃｋＨａｎｄｌｅが生成される。ＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトには、アセンブルされたメタデータへの１つまたは複数の参照（たとえば、異なるテーブルまたは異なるタイプのメタデータに対する異なる参照）を提供することができる。さらに、ＦｉｌｅＴｒａｃｋＨａｎｄｌｅには、（たとえば、ストリーミングされるメディアを見つけ出して抽出するための）メディアを含むファイルへのアクセスを容易にするために、ファイル記述子または同様のリソースが割り振られる。
【００５１】
状態４１０では、要求されたメディアが新しいクライアントにストリーミングされる。クライアントは、たとえば、メディアの特定部分を探すための巻戻しまたは早送り、ストリーミングの一時停止など、ストリーミングを制御するためのコマンドを発行することができる。
【００５２】
状態４１２では、メディアが１人または複数のクライアントにストリーミングされている間に、メディア・ストリーミング・サーバは同じメディアに関する任意の新しい要求がないかどうかを見守る。新しい要求が受け取られると、例示された手順では、状態４０８に戻って、新しいＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトおよび新しいストリームをセットアップする。それ以外の場合は、手順は状態４１４に進む。
【００５３】
状態４１４では、メディア・ストリーミング・サーバが、メディアのすべてのクライアントのストリーミングが終了したかどうかを判定する。サーバは、たとえば１つのクライアントのストリーミングが終了すると必ずこの判定を下すことができる。例示的に言えば、クライアントのストリーミングが終了すると、関連付けられたＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトが削除される。いずれかのストリーミングが依然として使用中または確立されている場合、あるいはいずれかの新しいストリーミングがセットアップ処理中である場合、手順は状態４１０に戻る。それ以外の場合は、手順４１６に進む。
【００５４】
状態４１６では、すべてのクライアントのストリーミングが終了した後、ＦｉｌｅＴｒａｃｋオブジェクトは削除され、メタデータはメモリから除去される。
【００５５】
当分野の技術者であれば、図４に示された手順が、複数のクライアントのメディア・ストリーミングに対して単一のメディア・トラック・メタデータ・セットを共用する単なる１つの方法であることを理解されよう。本発明の範囲を逸脱することなく、前述の説明から他の好適な方法を導出することができる。
【００５６】
ストリーミング中のメディアの再同期化
本発明の一実施形態では、メディア・ストリーミングを再同期化するためのシステムおよび方法が提供される。この実施形態では、ストリーミングされるプログラムまたはイベント内の１つまたは複数のトラック用のメディアが、ストリーミングの時間指標とペースを合わせられるだけの十分な速度でストリーミングされていない場合、メディア・ストリーミングは同期が取れていないとみなされる。言い換えれば、ストリーミングされるメディア・プログラムの現在の時間指標は、すべてのトラックが対応するメディアを送信していなければならない時間指標である。特定トラック用のメディアが現在の時間指標から遅れている場合、またはそのトラック用に何のメディアもまったくストリーミングされていない場合、ストリーミングは同期が取れていないとみなすことができる。たとえば、トラックのメディアのソース（たとえば記憶デバイス、ライブ・メディア・フィード）が十分な速度でメディアを供給できない場合に、同期の損失が発生することがある。
【００５７】
同期が失われると、メディア・ストリーミング・サーバは、ストリーミングを再開するための新しいその後のメディア時間指標を選択することで、メディア・ストリーミングの再同期化を試みることができる。その後サーバは、新しい時間指標に対応するメディアを要求するかまたは新しい時間指標に達するまで待機し、サーバは、ストリーミングを中止するか、または伝送の準備ができている（たとえば、依然として同期しているトラック用の）メディア・ストリーミングを続行することができる。
【００５８】
新しい時間指標に達し、必要なメディアが受け取られた場合、メディア・ストリーミング・サーバは対応するメディア・ストリーミングを開始する。ただし、新しい時間指標に達したときに新しい時間指標に対応するメディアが使用不可能な場合、サーバは、他のその後の新しい時間指標での再同期化を試みることが可能であり、対応するメディアを取り出すための時間がさらに与えられる。メディア・ストリーミングを再同期化するための試行は設定可能な回数だけ実行可能であり、すべての試行が失敗した場合、サーバはストリーミングを終了することができる。
【００５９】
図５は、本発明の一実施形態で、メディア・ストリーミングの再同期化を容易にするために協働可能ないくつかのプログラム・オブジェクトを示す図である。例示されたプログラム・オブジェクトと同様に動作するように構成された適切な対応するプログラム・モジュールを、オブジェクト指向でないプログラミング方法を使用するコンピュータ・システム用に確立することができる。
【００６０】
図５では、ＴｒａｃｋＳｔｒｅａｍ  ５０２は、クライアントへのストリーミング用にメディア・トラックのデータを処理するように構成されたオブジェクトのクラスを表す。ＬｉｖｅＴｒａｃｋＳｔｒｅａｍ  ５２０は、ライブ・メディア・ストリーミング用に構成されたオブジェクトのＴｒａｃｋＳｔｒｅａｍクラスを表し、ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２は、部分的に記録されたかまたは他の格納されたメディア用に構成されたオブジェクトのＴｒａｃｋＳｔｒｅａｍクラスを表す。Ｔｒａｃｋストリーミング・オブジェクトは、（たとえば指定された時間指標に関する）特定のトラック・メディアを取り出すためのインターフェースを含むことができる。ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２からは、ＱｕｉｃｋＴｉｍｅメディア用のＱｕｉｃｋＴｉｍｅ  ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２ａおよびＭＰＥＧメディア用のＭＰＥＧ  ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２ｂなど、異なるタイプのＦｉｌｅＴｒａｃｋストリーミング・オブジェクトを特定形式のメディア用にインスタンス化または呼び出すことが可能である。
【００６１】
本発明の一実施形態では、図５に示されたプログラム・オブジェクトは、図３に関して図示および説明されたオブジェクトなどのオブジェクトと協働することができる。具体的に言えば、この実施形態では、ＦｉｌｅＴｒａｃｋストリーミング・オブジェクトは、メディア・ファイル内の特定位置を探す、ファイルからデータを読み取るなどのために、ＦｉｌｅＴｒａｃｋＨａｎｄｌｅオブジェクトを含むかまたは参照することができる。
【００６２】
ストリーム５０４は、クライアントへのメディア・ストリームのアブストラクションである。異なるタイプのメディア・ストリームを、たとえばライブ・メディア・ストリーミングはＬｉｖｅＳｔｒｅａｍ  ５４０、部分的に記録されたメディア・ストリーミングはＦｉｌｅＳｔｒｅａｍ  ５４２で表すことができる。異なるメディア・プロトコルまたは形式について、ストリーミングを処理するために異なるタイプのストリーミング・オブジェクトを作成することができる。したがって、図５では、ＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａはＲＴＰを介してクライアントにメディアをストリーミングするように構成され、ＦｉｌｅＨＴＴＰＳｔｒｅａｍ  ５４２ｂはＨＴＴＰを介してメディアをストリーミングするように構成される。
【００６３】
本発明の例示的な実施形態では、各ストリーミング・オブジェクトが、（たとえば、クライアント・コマンドに応答して）開始、停止、一時停止、およびその他の方法でメディア・ストリーミングを制御するための方法を含む。ストリーミング・オブジェクトは、クライアントとの通信に使用する１つまたは複数のソケットを有し、ストリーミング用のメディア・データを取り出すためのＴｒａｃｋストリーミング・オブジェクトと対話するかまたはこれを含むことも可能である。例示的に言えば、メディアのストリームは複数のトラックを含むことができるため、各ストリーミング・オブジェクトは複数のＴｒａｃｋストリーミング・オブジェクトに関連付けられるかまたはこれを含むことができる。たとえば、１つのオーディオ・トラックおよび１つのビデオ・トラックからなる基本的なオーディオ・ビジュアル・メディア・プログラムをクライアントにストリーミングするために、ＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａが作成されると、ＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａは、各トラック用に別々のＦｉｌｅＴｒａｃｋストリーミング・オブジェクトと対話するか、またはこれを含むことができる。以下で説明するように、メディアのストリーム内のトラックが同期を取れなくなると、ストリーミングを制御しているストリーミング・オブジェクトは、手順の再同期化を開始することができる。
【００６４】
本発明の一実施形態では、部分的に記録されたメディア・プログラムを要求するためにクライアントがメディア・ストリーミング・サーバに接続し、メディア・ストリーミングを制御するためにＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａなどの適切なタイプまたは構成のストリーミング・オブジェクトが生成される。ＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａは、ＱｕｉｃｋＴｉｍｅ  ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２ａなどの適切なタイプの１つまたは複数のＴｒａｃｋストリーミング・オブジェクトを開始するかまたは呼び出す。その後、ＦｉｌｅＴｒａｃｋストリーミング・オブジェクトは、プログラムのトラックにアクセスしてメディアを取り出すために、（たとえば図３に示したような）適切なタイプまたは構成のＴｒａｃｋまたはＴｒａｃｋＨａｎｄｌｅオブジェクトを作成するかまたは呼び出す。この実施形態では、ストリーミング・オブジェクトがストリーミング（たとえば開始、停止、一時停止）を制御し、必要であればストリーミングを再同期化する。Ｔｒａｃｋストリーミング・オブジェクトは、適切なタスクの開始ならびに／あるいは（たとえばメディア・データを見つけ出し、メディア・ファイルからデータを読み取るための）ＴｒａｃｋまたはＴｒａｃｋＨａｎｄｌｅオブジェクトが提供するインターフェースの呼出しによって、トラック・メディアの取出しを制御する。
【００６５】
図６は、本発明の一実施形態に従ったメディア・ストリーミングの再同期化を実証する図である。例示された手順でストリーミングされるメディアは部分的に記録されているため、１つまたは複数の記憶デバイスから取り出されるが、ライブ・イベントまたは他のサーバから受け取られるライブ・メディアの場合は、この手順を容易に修正することができる。状態６０２では、複数のトラックを含む部分的に記録されたメディア・プログラムが、割り当てられたストリーミング・オブジェクト（たとえば、図５のＦｉｌｅＲＴＰＳｔｒｅａｍ  ５４２ａ）によってクライアントにストリーミングされる。
【００６６】
状態６０４では、プログラムのトラックのうち１つについてメディア・ファイルからメディア・データを読み取るために、（たとえば図５のＱｕｉｃｋＴｉｍｅ  ＦｉｌｅＴｒａｃｋＳｔｒｅａｍ  ５２２ａによって）要求が実行またはスケジューリングされる。例示的に言えば、要求されたメディア・データは、次のメディア時間指標（たとえば映画の時間）に対応する。要求されたデータを待つ間、ストリーミング・オブジェクトは（以前に取り出されたために）すでに使用可能なメディア・データを同じかまたは異なるトラックに対してストリーミングするか、あるいは要求されたデータが使用可能になるまで待つことができる。
【００６７】
状態６０６では、ストリーミング・オブジェクトは、要求されたデータが使用可能かどうかを判定するか、あるいはデータが受け取られたときに自動的に気付かされるかまたは他の方法で警告されることができる。要求されたデータが受け取られると、次に手順は適切なメディア時間指標でメディア・データをストリーミングするために状態６０２に戻る。具体的に言えば、プログラムのトラック用のメディア・データがタイムリーな方法で受け取られると、ストリーミング・オブジェクトは対応するメディア時間指標でデータをストリーミングすることができるため、メディア・プログラムの同期が維持される。ストリーミング・オブジェクトが状態６０６で、要求されたデータが使用できない（たとえば、記憶デバイスに負荷がかかりすぎている）と判定すると、同期の損失が示され、手順は状態６０８に進む。
【００６８】
状態６０８では、ストリーミング・オブジェクトは現在のメディア時間指標を将来の時間指標まで進めるかまたは増分し、状態６１０では、その将来の指標に対応するメディア・データを要求する。したがって、本発明のこの実施形態では、メディア・ストリーミング・サーバは、現在と将来の時間指標間のメディア時間に対応して、データのドロップまたは無視を選択する。例示的に言えば、任意のこうしたデータ（たとえば、同期を失っていないトラック用）を廃棄することができる。その後ストリーミング・オブジェクトは、要求されたメディアが受け取られるための適切な時間だけスリープまたは待機する。
【００６９】
状態６１２では、ストリーミング・オブジェクトは、新しいメディア時間指標に対応するメディア・データが受け取られたかどうか、およびストリーミングに使用できるかどうかを判定する。受け取られて使用できる場合、ストリーミング・オブジェクトは状態６０２に戻り、メディアをストリーミングしてメディアの次の部分を取り出す。
【００７０】
ただし、メディア・データが受け取られておらず、新しい時間指標でストリーミングに使用できない場合、状態６１４でストリーミング・オブジェクトは、しきい値回数（たとえば３回）の再同期化に失敗したかどうかを判定する。失敗していない場合、例示された手順は状態６０８に戻り、再度、メディア時間指標を進める。時間指標が連続して進められていくごとに、進められる時間を増やしていくことができる。たとえば、最初は時間指標が期間Ｔだけ進められた場合、次は２＊Ｔ、次は４＊Ｔ、次は８＊Ｔというように進めることができる。再同期化がしきい値回数だけ失敗すると、ストリーミング・オブジェクトはストリーミングを中止し、手順は終了する。
【００７１】
当分野の技術者であれば、図６に示された手順が、その後の時間指標で同期を回復させるために古いメディアをドロップすることによって、メディア・ストリーミングを再同期化する１つの方法に過ぎないことを理解されよう。本発明の範囲を逸脱することなく、前述の説明から他の好適な方法を導出することができる。
【００７２】
必要となるごとに要求されるかまたは取り出されるメディア・データの量は、使用可能なデータ・バッファのサイズまたは数、データ要求が発行される頻度、メディアがクライアントにストリーミングされるビット・レートなどによって、部分的に決めることができる。
【００７３】
本発明の実施形態の前述の説明は、例示および説明のためのみに示されたものである。本発明を開示された形式を網羅するかまたはこれに限定することを意図するものではない。当分野の技術者であれば、多くの修正および変形が明らかであろう。したがって、上記の開示は本発明を限定するものではなく、本発明の範囲は添付の特許請求の範囲によって定義される。
【図面の簡単な説明】
【図１】  本発明の一実施形態により、メディアをストリーミングするように構成されたサーバを示す構成図である。
【図２】  本発明の一実施形態により、メディアを複数のクライアントにストリーミングするためのメディア・トラック・メタデータの単一のコピーの使用を示す構成図である。
【図３】  本発明の一実施形態により、トラックのメタデータの単一のコピーを使用して、複数のクライアントにメディア・トラックをストリーミングするように協働する、プログラム・オブジェクトの一構成を示す図である。
【図４】  本発明の一実施形態により、トラックのメタデータの単一のコピーを使用して、複数のクライアントにメディア・トラックをストリーミングする一方法を実証する流れ図である。
【図５】  本発明の一実施形態により、メディア・ストリーミング内のメディアを再同期化するためのプログラム・オブジェクトの一構成を示す図である。
【図６】  本発明の一実施形態により、メディア・ストリーミング内のメディアを再同期化する一方法を実証する流れ図である。
【図１】
0004640723.tif 000002
【図２】
0004640723.tif 000003
【図３】
0004640723.tif 000004
【図４】
0004640723.tif 000005
【図５】
0004640723.tif 000006
【図６】
0004640723.tif 000007