JP4813001B2 - ストリーミング中のメディアの再同期化 - Google Patents

Description

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

Claims (19)

1. メディア・プログラムを表すメディア・ストリームを同期化する方法であって、
   前記メディア・プログラムを表すメディア・データをサーバからクライアントへストリーミングすること、
   前記サーバにおいて、前記メディア・ストリームの現在のメディア時間指標において、前記メディア・ストリームにおける同期の損失を検出し、ここで、前記現在のメディア時間指標は現在ストリーミングされているべきメディア・データに対応するメディア時間指標であり、同期の損失が検出されるのは、実際にストリーミングされている前記メディア・データのメディア時間指標が前記メディア・ストリームの現在のメディア時間指標より遅れている場合、または、前記メディア・プログラムの、前記現在のメディア時間指標に対応する部分がストリーミングのために使用可能でない場合である、こと、
   前記サーバにおいて、前記メディア・データ内の、前記現在のメディア時間指標よりも後の第２のメディア時間指標を選択すること、および
   前記サーバにおいて、前記第２のメディア時間指標における前記メディア・プログラムをストリーミングすることを試行することによって、前記第２のメディア時間指標において前記メディア・データの同期化を試行することを含む方法。
2. 前記同期化の試行が成功しなかった場合、前記選択および前記試行を高々所定の回数まで繰り返し、前記同期化の試行が成功しなかったと判定されるのは、前記現在のメディア時間指標が前記第２のメディア時間指標に到達したときに、前記第２のメディア時間指標に対応するメディア・データがストリーミングのために使用可能でない場合である、請求項１に記載の方法。
3. 前記所定回数の同期化の試行がそれぞれ成功しなかった場合に、前記サーバにおいて、前記メディア・ストリームを終了することをさらに含む請求項２に記載の方法。
4. 前記第２のメディア時間指標を選択することが、前記現在のメディア時間指標に所定の時間量を加えることを含む請求項１に記載の方法。
5. 前記第２のメディア時間指標を選択することが、実際にストリーミングされている前記メディア・データの前記メディア時間指標に所定の時間量を加えることを含む請求項１に記載の方法。
6. 前記同期化の試行が、
   前記第２のメディア時間指標に対応する前記メディア・プログラムの一部が、前記第２のメディア時間指標でのストリーミングに使用できるかどうかを判定することと、
   前記メディア・プログラム部分がストリーミングに使用できる場合、前記第２のメディア時間指標において前記メディア・プログラムのストリーミングを再開することを含む請求項１に記載の方法。
7. メディア・サーバからクライアントにストリーミングされるメディア・プログラムを再同期化する、前記メディア・サーバにおいて実行される方法であって、
   （ａ）メディア・プログラムの、前記メディア・プログラムの第１のメディア時間指標に対応する第１の部分をクライアントにストリーミングすることを試行することを含み、
   （ｂ）前記第１のメディア部分が前記第１のメディア時間指標でのストリーミングに使用できない場合、
   （ｃ）前記第１のメディア時間指標よりも後の前記メディア・プログラムの第２のメディア時間指標を選択すること、
   （ｄ）前記第２のメディア時間指標に対応する前記メディア・プログラムの第２の部分を取得すること、
   （ｅ）前記第２のメディア時間指標まで前記メディア・プログラムのストリーミングを中止すること、および
   （ｆ）前記第２のメディア時間指標において前記第２のメディア部分が使用可能であれば、前記第２の時間指標から前記メディア・プログラムのストリーミングを開始することによって、
   前記メディア・プログラムの再同期化を試行することをさらに含む方法。
8. （ｇ）前記第２のメディア部分が前記第２のメディア時間指標において使用不可能であれば、その後のメディア時間指標および前記その後のメディア時間指標に対応する他のメディア部分について前記（ｂ）〜（ｆ）を繰り返すことをさらに含む請求項７に記載の方法。
9. 前記（ｂ）〜（ｆ）が高々所定回数まで繰り返され、前記再同期化の試行が前記所定回数の各々で成功しなかった場合、前記ストリーミングを終了し、前記再同期化の試行が成功しなかったと判定されるのは、前記第２のメディア時間指標において、前記第２のメディア部分が使用可能でない場合である、請求項８に記載の方法。
10. 前記メディア・プログラムが事前に記録されたメディア・プログラムであり、前記要求することが、記憶デバイスからの前記メディア・プログラムの一部の取出しをスケジューリングすることを含む請求項７に記載の方法。
11. 前記第２のメディア時間指標を選択することが、第１の再同期化試行については、
    現在のメディア時間指標を決定することと、
    前記現在のメディア時間指標に所定の時間増分を加えて前記第２のメディア時間指標を得ることを含む請求項７に記載の方法。
12. 前記第２のメディア時間指標を選択することが、後続の再同期化試行については、
    第２の現在のメディア時間指標を決定することと、
    前記第２の現在のメディア時間指標に、前記所定の時間増分の倍数を加えて前記第２のメディア時間指標を得ることを含む請求項１１に記載の方法。
13. 前記中止することが、前記第２のメディア時間指標より前のメディア時間指標に対応するメディア・データを廃棄することを含む請求項７に記載の方法。
14. 前記メディア・プログラムが複数のトラックを含み、前記第２のメディア時間指標から前記メディア・プログラムをストリーミングすることが、前記メディア・プログラムの複数のトラックからのメディア・データをクライアントに伝送することを含み、前記伝送されたメディア・データが前記第２のメディア時間指標に対応する請求項７に記載の方法。
15. コンピュータによって実行されたときにメディア・プログラムを表すメディア・ストリームの同期化方法をコンピュータに実行させる命令を格納する、コンピュータ読取り可能記憶メディアであって、前記方法が、
    前記メディア・プログラムを表すメディア・データをサーバからクライアントへストリーミングすること、
    前記サーバにおいて、前記メディア・ストリームの現在のメディア時間指標において、前記メディア・ストリームの同期の損失を検出し、ここで、前記現在のメディア時間指標は現在ストリーミングされているべきメディア・データに対応するメディア時間指標であり、同期の損失が検出されるのは、実際にストリーミングされている前記メディア・データのメディア時間指標が前記メディア・ストリームの現在のメディア時間指標より遅れている場合、または、前記メディア・プログラムの、前記現在のメディア時間指標に対応する部分がストリーミングのために使用可能でない場合である、こと、
    前記サーバにおいて、前記メディア・データ内の、前記現在のメディア時間指標よりも後の第２のメディア時間指標を選択すること、および
    前記サーバにおいて、前記第２のメディア時間指標における前記メディア・プログラムをストリーミングすることを試行することによって、前記第２のメディア時間指標において前記メディア・データの再同期化を試行することを含む、コンピュータ読取り可能記憶メディア。
16. コンピュータによって実行されたときに、メディア・サーバからクライアントにストリーミングされるメディア・プログラムを再同期化する方法を前記メディア・サーバに実行させる命令を格納する、コンピュータ読取り可能記憶メディアであって、メディア・サーバによって実行される前記方法が、
    （ａ）メディア・プログラムの、前記メディア・プログラムの第１のメディア時間指標に対応する第１の部分をクライアントにストリーミングすることを試行することを含み、
    （ｂ）前記第１のメディア部分が前記第１のメディア時間指標でのストリーミングに使用できない場合、
    （ｃ）前記第１のメディア時間指標よりも後の前記メディア・プログラムの第２のメディア時間指標を選択すること、
    （ｄ）前記第２のメディア時間指標に対応する前記メディア・プログラムの第２の部分を取得すること、
    （ｅ）前記第２のメディア時間指標まで前記メディア・プログラムのストリーミングを中止すること、および
    （ｆ）前記第２のメディア時間指標において前記第２のメディア部分が使用可能であれば、前記第２のメディア時間指標から前記メディア・プログラムのストリーミングを開始することによって、
    前記メディア・プログラムの再同期化を試行することをさらに含む、コンピュータ読取り可能記憶メディア。
17. クライアントへのメディア・プログラムを表すメディア・ストリームを同期化するサーバ装置であって、
    クライアントへの前記メディア・プログラムを表すメディア・データのストリーミングを制御するように構成されたストリーム・モジュールと、
    メディア時間指標とを含み、ここで、各メディア時間指標についてメディア・プログラムの対応する部分がストリーミングされるべきものであり、現在のメディア時間指標は前記メディア・プログラムの現在ストリーミングされているべきメディア・データに対応し、
    さらに当該サーバ装置が、前記メディア・プログラムの第１のトラック用のメディア・データをメディア・ソースから取り出すように構成された第１のトラック・ストリーム・モジュールを含み、
    前記メディア・プログラムの第１の部分が第１の現在のメディア時間指標でのストリーミングに使用できない場合、前記ストリーム・モジュールが、
    前記メディア時間指標を、前記現在のメディア時間指標から将来のメディア時間指標まで進め、
    前記将来のメディア時間指標に対応する前記メディア・プログラムの部分を要求し、
    前記要求されたメディア・プログラム部分が前記将来のメディア時間指標でのストリーミングに使用できる場合、前記将来のメディア時間指標で前記ストリーミングを再開する、サーバ装置。
18. クライアントへのメディア・データを表すメディア・ストリームを同期化するサーバ装置であって、当該サーバ装置は
    メディア・プログラムの第１のトラックを格納する第１の記憶デバイスと、
    前記第１のトラックからメディア・データを取り出すように構成された第１のトラック・ストリーム・モジュールとを含み、前記メディア・データが、一連の時間指標に対応する複数のメディア部分を含み、一連の各時間指標で対応するメディア部分が再生されるべきであって、
    さらに当該サーバ装置が、現在のメディア時間指標に対応するメディア・データをクライアントに伝送することによって、クライアントへのメディアのストリーミングを制御するように構成されたストリーム・モジュールと、
    前記メディア・データの、第１の現在のメディア時間指標に対応する部分が、前記第１の現在のメディア時間指標でのストリーミングに使用できない場合、前記第１の現在のメディア時間指標よりも後の第２のメディア時間指標における前記メディア・データをストリーミングすることを試行することによって、前記メディア・ストリーミングを同期化するように構成された同期化モジュールとを含む、
    サーバ装置。
19. 前記同期化が、
    前記第１の現在のメディア時間指標よりも後の前記第２のメディア時間指標を選択すること、
    前記第２のメディア時間指標に対応するメディア・データの部分を要求すること、
    前記第２のメディア時間指標まで、前記メディア・ストリーミングを中断すること、および
    前記要求されたメディア部分が、前記第２のメディア時間指標でのストリーミングに使用できる場合、前記メディア・ストリーミングを再開することを含む、
    請求項１８に記載の装置。

Images