JP2014197879A - プログレッシブ再生を含む映像分配システム - Google Patents

Abstract

【課題】 リモートコンテンツを再生するためのレシーバによる方法が記載される。【解決手段】 一実施形態は、リモートサーバからメディアファイルのコンテンツに関する情報を取得するステップを含み、メディア・シーケンスの中で開始位置を識別するステップと、開始位置からメディア・シーケンスを再生するために要求されるメディアに対応するバイト範囲を識別するステップと、開始位置からメディア・シーケンスを再生するように要求されるバイト範囲を要求するステップと、再生開始の待機中情報の受信されたバイトをバッファリングするステップと、情報のうち、バッファリングされたバイトを再生するステップと、ユーザ命令を受信するステップと、ユーザ命令に従ってメディア・シーケンスを再生するように要求されるメディアに対応するメディアファイルのバイト範囲を識別するステップと、以前のバイト範囲の要求をフラッシュするステップと、ユーザ命令に従い、メディアを再生するために要求されるバイト範囲を要求するステップとを含む。【選択図】図１

Description

本発明は、一般的に、ネットワークを通じてマルチメディアのファイルを再生することに関し、より詳細には、ネットワークを通じてダウンロードされる際のマルチメディアファイルのプログレッシブ再生に関する。

プログレッシブ再生は、リモートコンテンツがダウンロードされている最中にそれを再生するという考えである。
この特徴を用いて、ユーザは、リモートの映画を選択することができ、それが完全にダウンロードされる前に観ることを開始できる。
高速インターネット接続をもってしても、映画が完全にダウンロードされるのを待つには、メディアファイルのサイズに応じて、数分から数時間に及ぶ可能性がある。
プログレッシブ再生では、ユーザは、再生が開始できるまで、数秒を待つのみである。

レシーバまたはプレーヤによるプログレッシブ再生の現在の様々な実装は、現在の主な用途において優勢であるショートビデオクリップに適切である一方、それらが提供するプログレッシブ再生の範囲および柔軟性において制限されるのが普通である。
プレーヤは、通常、最初から最後まで直線的にファイルをダウンロードする。
そして、プレーヤが、メディアが途切れず再生できる程度まで十分なデータをバッファリングしたときに、再生を開始する。
バッファリングの要求条件は、大部分のコンテンツに適切な一定した量でもよく、または変動する量でもよく、プレーヤは、バッファ・アンダー・ランを被らずに、コンテンツ全体を再生するためにどの程度のデータが要求されるかについて推量する。
ショートビデオクリップを再生するには適しているが、これらの方法は、ランダム捜索、リモートで格納された、より長いコンテンツ（例えば長編映画など）のトリック再生および再生をサポートしないのが通常である。

一部のシステムは、サーバによる方法で実施される。
サーバによる方法の例は特許文献１、特許文献２、特許文献３、特許文献４に記載のシステムを含み、それらの開示はそれらの全体において参照することにより援用される。
これらのシステムにおいて、サーバは、データファイルを解析して、どちらのデータを送信するべきかについて決定する。
再生中のネットワーク効率および柔軟性は、さらに容易なものとなる。
しかしながら、標準的なＨＴＴＰウェブサーバは、通常はこの機能を提供していないので、多数のプレーヤに一斉にコンテンツを配信するように求められる場合、しばしばこの機能を提供しているカスタムメイドのウェブサーバは、不完全に規模を縮小している。

ブラウザ型のプレーヤは、直線的にビデオファイルがダウンロードされている間、そのビデオファイルを解析することによって、しばしばレシーバによる再生を実施する。
長いクリップが開始されると、まだダウンロードが終わっていないファイルの位置に、捜索または早送りすることは不可能である。
Ｓａｍｂａ（ｈｔｔｐ：／／ｕｓ２．ｓａｍｂａ．ｏｒｇ．ｓａｍｂａで利用可能なオープンソースソフトウェア）は、あたかもそれがローカルファイルであるかのように、任意のアプリケーションにリモートファイルへのアクセスを与えるために用いることができる。
ランダムに設定されているファイルの現在位置からデータをプレキャッシュすることによって、アクセス待ち時間を最小化しようと試みる。
これは、「トリック再生」機能（例えば、巻き戻し、早送り、メディア内容のノンシーケンシャルのアクセスを要求する場面間のスキッピングのような機能を実行する場合など）の実行を試みる場合には不十分である場合がある。
これらのシナリオ中でプレーヤに配信されるビデオフレームは、遠く離れた間隔を置かれ得るかまたはさらに複雑な順位付けを要求することとなり、視聴される次のビデオフレームに関する推測に基づいて、従来のプレキャッシング方法の有用性を大幅に減少させてしまう。

米国特許出願第１１／３２３，０４４号明細書 米国特許出願第１１／３２３，０６２号明細書 米国特許出願第１１／３２７，５４３号明細書 米国特許出願第１１／３２２，６０４号明細書

部分的にダウンロードされたメディアファイルに、プログレッシブ再生および「トリック再生」機能を実行するシステムおよび方法を記載する。

本発明の多数の実施形態は、所定のバイト範囲のデータ、以前の要求の放棄、および最優先でデータに対する新しい要求を発行することを含む、所定の要求されたデータのみでの全容量のダウンロードストリームを常に維持するなどの、レシーバまたはプレーヤによるシステムサポート機能を含む。
加えて、発明の様々な実施形態は、機能として、例えばファイルの任意の位置でのランダムファイル・アクセス、および、ファイル再生におけるユーザ柔軟性を提供する非同期要求を含む。
多数の実施形態において、システムおよびプロセスは、複数のタイトルを含むことができるファイルを格納するインターネットサーバ上での実施のための拡張性をサポートし、それらのタイトルは、複数の音声トラックを含むタイトル、および／または１つ以上のサブタイトル・トラックを含む。

いくつかの実施形態において、フル機能のプログレッシブ再生を提供する能力は、リモートファイルにランダムアクセスを提供するトランスポートプロトコルを用いて、メディア・シーケンス（すなわち、符合化されたメディアをデコードして、再生するシステム）に対する再生エンジン部の密接な連結に、ある程度、起因する。
ファイル・パーサ部を介した、再生エンジン部とトランスポートプロトコルとのインターフェース接続によって、待ち時間を低減でき、クライアントおよびメディアサーバが、同時に、ダウンロード効率化およびやり取りを改善することができる。
多数の実施形態において、システムおよびプロセスは、ファイル内のデータに対してインデックスを含むためにフォーマットされるファイル、およびファイル内において特定のバイト範囲をダウンロードできるトランスポートプロトコルを用いて使用するために構成される。

本発明の方法の一実施例は、リモートサーバからメディアファイルのコンテンツに関する情報を取得するステップと、メディア・シーケンス中で開始位置を識別するステップと、上記開始位置から上記メディア・シーケンスを再生するために必要とされるメディアに対応する上記メディアファイルのバイト範囲を識別するステップと、上記開始位置から上記メディア・シーケンスを再生するために必要とされる上記バイト範囲を要求するステップと、再生開始の待機中情報の受信されたバイトをバッファリングするステップと、情報のうち、上記バッファリングされたバイトを再生するステップと、ユーザ命令を受信するステップと、上記ユーザ命令に従い、上記メディア・シーケンスを再生するために必要とされるメディアに対応する上記メディアファイルのバイト範囲を識別するステップと、以前のバイト範囲要求をフラッシングするステップと、上記ユーザ命令に従い、上記メディアを再生するために必要とされる上記バイト範囲を要求するステップと、を含む。

本発明の方法の更なる実施形態は、ダウンロードされた上記メディアファイルの上記部分のマスクを維持するステップと、上記ユーザ命令に従い、上記メディアを再生するために必要とされるバイト範囲の少なくとも一部が、上記マスクを用いて、既にダウンロードされたかどうかを識別するステップと、上記メディアサーバから、まだダウンロードされていないバイト範囲の上記部分のみを要求するステップと、をさらに含む。

本発明の方法の他の実施形態は、データファイル中のダウンロードされたバイトを格納するステップと、上記メディアファイルの全てのバイトがダウンロードされた場合に、上記ダウンロードされたメディアファイルを出力するステップと、をさらに含む。

本発明の方法の更なる実施形態において、データファイルは、疎データファイルである。

本発明の方法の更に別の実施形態において、上記メディアファイルは、複数のメディア・シーケンスおよびメニュー情報を含み、上記メディア・シーケンス内で開始位置を識別するステップは、メニュー情報を表示するステップと、上記メディア・シーケンスの上記選択を示すユーザ命令を受信するステップと、上記メディア・シーケンス内で開始位置を示すユーザ命令を受信するステップと、を更に含む。

本発明の方法の更なる他の実施形態において、上記メディア・シーケンスは、複数の交換可能な音声トラックを含み、上記メディア・シーケンスの中で開始位置を識別するステップは、音声トラックを選択するステップを更に含み、上記開始位置から上記メディア・シーケンスを再生するために必要とされるメディアに対応する上記メディアファイルのバイト範囲を識別するステップは、選択されなかった上記音声トラックを含まないバイト範囲を選択するステップを更に含む。

本発明の方法のさらにもう一つの実施形態において、上記メディア・シーケンスは、複数の交換可能なサブタイトル・トラックを含み、上記メディア・シーケンスの中で開始位置を識別するステップは、サブタイトル・トラックを選択するステップを更に含み、上記開始位置から上記メディア・シーケンスを再生するために必要とされるメディアに対応する上記メディアファイルのバイト範囲を識別するステップは、選択されなかった上記サブタイトル・トラックを含まないバイト範囲を選択するステップを更に含む。

さらにまた、本発明の方法の更なる実施形態において、シーケンスは、キー・フレームを含み、上記ユーザ命令に従い、上記メディアを再生するために必要とされるメディアに対応する上記メディアファイルのバイト範囲を識別するステップは、所定のユーザ命令に応答して一連のキー・フレームを識別するステップと、上記識別されたキー・フレームに対応する上記メディアファイルのバイト範囲を識別するステップと、を更に含む。

本発明の一実施形態は、メディアサーバと、クライアントと、ネットワークとを備える。
さらに、上記クライアントおよび上記メディアサーバは、上記ネットワークを介して通信するように構成され、上記クライアントは、上記メディアサーバに、上記メディアファイルの少なくとも一部分に対する要求を送信するように構成され、上記サーバは、上記クライアントに、上記メディアファイルの要求された部分を提供するように構成され、上記クライアントは、上記メディアファイルの上記再生に関するユーザ命令を受信するように構成され、かつ、ダウンロードされておらず、上記メディアサーバから上記再生命令に適合するように要求されている上記メディアファイルの部分を要求するように構成される。

本発明の別の実施例において、上記メディアファイルに近接する部分はグループ化され、上記グループは、最も初期の最終期限第１ベース上において要求される。

本発明の他の一実施例において、上記クライアントは、上記メディアファイルの要求された部分のキューを維持するように構成される。

本発明の更なる実施形態において、上記クライアントおよび上記サーバは、少なくとも１つの接続を介して通信するように構成され、上記クライアントは、上記メディアファイルの要求された部分の上記キューをフラッシュし、所定のユーザ命令の上記受信に応答して、上記接続のうちの少なくとも１つを切断するように構成される。

本発明のさらに別の実施形態において、上記クライアントは、ファイル・マップおよびデータファイルを格納するように構成され、上記ファイル・マップは、ダウンロードされた上記メディアファイルの上記部分を示すマスクを含み、上記データファイルは、上記メディアファイルの上記ダウンロードされた部分を含む。

本発明の更に他の実施形態において、データ・ファイルは、疎ファイルである。

本発明の更にもう一つの実施形態において、上記メディアファイルは、メディア・シーケンスおよびインデックスを含み、上記クライアントは、上記インデックスを取得して、ユーザ再生命令に適合するように要求される上記メディア・シーケンスの上記部分を決定するように構成される再生エンジン部と、上記メディア・シーケンスの上記部分を上記メディアファイルの部分にマップするために上記インデックスを用いるように構成されるファイル・パーサ部と、上記メディアファイルの部分をダウンロードするために上記メディアサーバと通信するように構成されるダウンロード管理部と、を備える。

再び、本発明のさらなる実施形態は、ユーザ命令を受信するように構成されるユーザインターフェース部と、少なくとも１つのメディアファイルを格納するように構成される記憶装置と、ネットワーク接続部と、上記ネットワーク接続部を介してリモートで格納されたメディアファイルからファイルの少なくとも１つのバイト範囲を非同期で要求するように構成されるダウンロード管理部と、上記ユーザインターフェースを介して受信されるユーザ命令に応答してダウンロードされる、リモートで格納されたメディアファイルの部分を決定するように構成される再生エンジン部と、バイト範囲に、リモートで格納されたメディアファイルの部分に対する要求を中継して、上記ダウンロード管理部に上記バイト範囲を提供するように構成されるファイル・パーサ部と、を備える。

さらにまた、本発明の他の実施例において、上記ダウンロード管理部は、ダウンロードされたメディアファイルのブロックのマップを含むステータスファイルを作成するように構成され、上記ダウンロード管理部は、ダウンロードされたメディアファイルのブロックを格納するデータファイルを作成するように構成される。

本発明の更に新たな実施形態において、上記ダウンロード管理部は、要求されたバイト範囲のキューを維持するように構成される。

本発明の他の新たな実施形態において、上記ダウンロード管理部は、上記キューをフラッシュするように構成される。

本発明の更に他の実施形態において、上記再生エンジン部は、リモートメディアファイルから取得されるメニューを用いて、メニューを生成するように構成される。

更に本発明の更に他の実施形態において、上記再生エンジン部は、上記メニューを介して、リモートメディアファイル中の複数のメディア・シーケンスの１つの選択を受信するように構成される。

さらに加えて、本発明のまた更な実施形態において、上記再生エンジン部は、上記メニューを介して、リモートメディアファイル中のメディア・シーケンスのための複数の音声トラックの１つの選択を受信するように構成される。

さらに加えて、本発明の更に他の実施形態において、上記再生エンジン部は、上記メニューを介して、リモートメディアファイル中のメディア・シーケンスのためのサブタイトルトラックの選択を受信するように構成される。

本発明の実施形態に従うプログレッシブ再生システムの半概略的なネットワーク図である。 本発明の実施形態に従う、リモートで格納されたメディアファイルのプログレッシブ再生のための処理を示すフローチャートである。 本発明の実施形態に従う、リモートサーバからバイト範囲を要求し、「トリック再生」機能をサポートするように構成されるクライアント・アプリケーションの概念図である。 本発明の実施形態に従うダウンロード管理部の概念図である。 本発明の実施形態に従う、メディアサーバからバイト範囲を要求するための処理を示すフローチャートである。 本発明の実施形態に従う、メディアサーバを用いた接続をフラッシュするための処理を示すフローチャートである。 本発明の実施形態に従う、データファイルのバイト範囲のノンシーケンシャルでのダウンロードの間、データファイルを構築するための処理を示すフローチャートである。 本発明の実施形態に従う、リモートメディアファイル中のメニュー情報およびメディア・シーケンスを識別するために、かつ、ファイルから情報を抽出するために、ファイル・パーサ部により用いられることができる処理を示すフローチャートである。 本発明の実施形態に従う、チャンクを利用するコンテナフォーマットを用いてフォーマットされるリモートメディアファイルからデータチャンクを取得するために再生エンジン部により用いられる処理を示すフローチャートである。

図面に戻り、プログレッシブでメディアをダウンロードおよび再生するシステムを示す。
多くの実施形態において、メディアは、リモートサーバ上のファイルに格納され、クライアント・アプリケーションにより構成される装置は、そのメディアファイルの部分を取り出し、そのメディアを再生する。
クライアント・アプリケーションは、再生を開始するとき、完全なメディアファイルを有してないのが通常であり、メディアファイルのノンシーケンシャルの部分を要求することができる。
このように、クライアント・アプリケーションは、「トリック再生」機能をサポートすることができる。
「トリック再生」機能は、一時停止、巻き戻し、早送り、および場面間のスキッピングを含むノンシーケンシャル機能などのメディアファイルの再生に影響を与える。
シーケンシャルにメディアファイルをダウンロードし、その要求された情報がダウンロードされて「トリック再生」機能を実行するまで待機する代わりに、本発明の実施形態に従うクライアント・アプリケーションは、特定の「トリック再生」機能をサポートし、リモートサーバからファイルの部分を要求することを必要とされるメディアファイルの部分を決定することができる。
「トリック再生」機能が、ダウンロードされていないメディアの部分のスキッピングを伴う場合、例えば、チャプタ間の早送りやスキッピングを伴う場合、待ち時間は、シーケンシャルのダウンロードと比較して著しく削減できる。

本発明の実施形態に従うプログレッシブ再生システムの構成は、プログレッシブ再生システムによってサポートされるコンテナフォーマットに依存してもよい。
コンテナ・フォーマットの例は、ワシントン州、レドモンドのマイクロソフト社によって指定されたＡＶＩ １．０ファイルフォーマット、ＯｐｅｎＤＭＬ ＡＶＩまたはＡＶＩ ２．０フォーマット、米国特許出願第１１／０１６，１８４号および１１／１９８，１４２号明細書において指定されたフォーマットに類似するコンテナフォーマット（その開示はその全体において参照することにより援用される）、ＭＰＥＧ−４ Ｐａｒｔ １５（ＭＰ４）、およびＭａｔｒｏｓｋａ（ｗｗｗ．ｍａｔｒｏｓｋａ．ｏｒｇを参照）として公知のオープンソースフォーマットを含む。
使用されるコンテナファイルフォーマットに依存して、メディアファイルは、複数のタイトル（すなわちメディア・シーケンス）を含むことができ、各タイトルは、複数の音声トラックおよび／または１つ以上のサブタイトル・トラックを含むことができる。
メディアファイルのコンテナフォーマットは、メディアファイル中のメディア情報が位置する仕方に影響を与える。
それゆえ、プログレッシブ再生システムの構成は、特定のアプリケーションでサポートされるコンテナフォーマットに基づいて決定されるのが通常である。
多数の実施形態を以下で後述するが、異なるコンテナフォーマットに適切である他の変形も、本発明の実施形態に従って構成可能である。

図１に、本発明の実施形態に従うプログレッシブ再生システムを示す。
プログレッシブ再生システム１０は、ネットワーク１４に接続されるメディアサーバ１２を備える。
メディアファイルは、メディアサーバ１４に格納され、クライアント・アプリケーションにより構成される装置によって、アクセス可能である。
図に示す実施形態において、メディアサーバ上のメディアファイルにアクセスする装置は、パーソナル・コンピュータ１６、再生装置（例えばテレビ２０）に接続されたセットトップボックス１８などの家庭用電化製品装置、およびＰＤＡ（携帯情報端末）または携帯電話などの携帯機器を備える。
装置およびメディアサーバ１２は、ゲートウェイ２６を介してインターネット２４に接続されたネットワーク１４を介して通信できる。
他の実施形態において、メディアサーバ１４および装置は、インターネット介して通信する。

上記の装置は、再生するためのメディアサーバ１２からメディアファイルの部分を要求できるクライアント・アプリケーションにより構成される。
クライアント・アプリケーションは、ソフトウェア、ファームウェア、ハードウェア、または、それらの組合せにおいて実施できる。
多数の実施形態において、上記の装置は、ダウンロードされたメディアファイルからメディアを再生する。
様々な実施形態において、装置は、他の装置がメディアを再生することを可能にする１つ以上の出力を提供する。
メディアファイルがインデックスを含む場合、本発明の実施形態に従うクライアント・アプリケーションにより構成される装置は、メディアの種々の部分の位置を決定するために、インデックスを用いることができる。
その結果、インデックスは、「トリック再生」機能をユーザに提供するために使用できる。
ユーザが「トリック再生」指示を提供すると、その装置は、「トリック再生」機能を実行するために要求されるメディアファイルの部分または複数の部分を決定するために、インデックスを使用し、サーバからそれらの部分を要求する。
多数の実施形態において、クライアント・アプリケーションは、メディアファイル内の特定のバイト範囲のダウンロードを可能にするトランスポート・プロトコルを使用しているメディアファイルの部分を要求する。
そのようなプロトコルは、ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇより入手可能な、Ｔｈｅ Ｉｎｔｅｒｎｅｔ ＳｏｃｉｅｔｙまたはＢｉｔＴｏｒｒｅｎｔにより発行されるＨＴＴＰ １．１プロトコルである。
他の実施形態において、他のプロトコルおよび／または機能は、メディアサーバからメディアファイルの特定部分を取得するために使用できる。

本発明の実施形態に従うメディアサーバからメディアを要求するための処理を示すフローチャートを図２に示す。
処理４０は、メディアサーバからメディアファイルのインデックスを取得する（４２）を含む。
メディアファイルを再生する位置を決定する（４４）。
多数の実施形態において、全てのファイルは、メディア・シーケンスの開始時に再生を開始する。
様々な実施形態において、メディアファイルは、１つ以上メディア・シーケンスの閲覧を開始する、異なる位置をユーザが選択可能な１つ以上のメニューを含むことができる。
一旦、位置が決定されると、決定された位置からメディアの再生を開始するために要求されるメディア情報が要求され（４６）、受取りに応じて再生される（４８）。
その処理は、ユーザ命令を聴取する（５０）ことを含む。
ユーザが命令を提供しない場合には、システムは、ユーザから受信される以前の命令に従ってメディアを再生し続ける。
ユーザが命令を提供する場合、処理は、その命令が再生中止であるかどうかを判定する（５２）。
そうでない場合、処理は、その命令に適合するように要求されるメディアを決定する（５４）こと、および、必要とされるメディアを要求すること（４６）を含む。
ユーザがメディアを再生するのを中止するために命令を与えるまで、または、メディア・シーケンスが最後に到達するまで、処理は継続する。

本発明の実施形態に従うメディアサーバは、単にメディアファイルを格納し、メディアファイル内で特定のバイト範囲に対する要求を受信することによって、プログレッシブ再生およびトリック再生機能をサポートすることができる。
クライアント・アプリケーションは、適切なバイト範囲を決定することができ、メディアサーバは、単にバイト範囲要求に応答する。
ユーザ命令に応答して適切なバイト範囲を決定するように構成されるクライアント・アプリケーションは、さまざまな方法で実施できる。

本発明の実施形態に従う３つの抽象概念層を用いて実施されるクライアント・アプリケーションを図３に示す。
クライアント・アプリケーション６０は、リモートサーバからファイルの特定のバイト範囲のダウンロードを調整する役割を果たすダウンロード管理部６２を備える。
再生エンジン部６４は、ユーザとのやり取りに応答してメディアファイルの再生を調整するハイレベル処理である。
メディアファイルが再生されている場合、再生エンジン部は、メディアの再生を継続するために、および／またはユーザ命令に応答するために要求されるメディアファイルの部分を決定するために、メディアファイルのインデックスを使用する。
ファイル・パーサ部６６は、再生エンジン部６４とダウンロード管理部６２との間をインターフェース接続する。
ファイル・パーサ部は、再生エンジン部からのハイレベル・データ要求を、ダウンロード管理部を用いて要求される特定のバイト範囲に対してマッピングする。
本発明の実施形態に従うダウンロード管理部、ファイル・パーサ部、および再生エンジン部の実施を以下に述べる。
多数の実施形態において、クライアント・アプリケーションは、代替アーキテクチャを使用して構成され、これらの代替アーキティチャは、ユーザ命令を、リモートメディアサーバに提供されるバイト要求に変換するために、メディアファイルに対してインデックスを使用するように構成される。

本発明の実施形態に従うダウンロード管理部を図４に示す。
上記のように、ダウンロード管理部は、１つ以上のメディアサーバと通信して、メディアサーバに格納されるメディアファイルからメディアの特定のバイト範囲を取得する役割を果たす。
図４に示すダウンロード管理部７０は、メディアファイルのダウンロードに役立つために、リモート・ファイル・オブジェクト７２およびパーシャル・ファイル・オブジェクト７４のインスタンスを作成するように構成される。
リモート・ファイル・オブジェクト７２は、メディアサーバからファイルのバイト範囲を要求することに関連した通信を処理し、要求されているバイト範囲のキューを保持する。
パーシャル・ファイル・オブジェクト７４は、メディアサーバからダウンロードされたデータの保管を処理する。
パーシャル・ファイル・オブジェクト７４は、ダウンロード管理部によって、ダウンロードされるファイルの一時データパス７５を定める。

一時データパス７５は、データファイル７８およびステータスファイル７６を含む。
データファイル７６は、メディアサーバから受信されるデータを含む。
ステータスファイルはデータファイルのマスクを含む。ここで、マスク内の各ビットはデータファイル中の一定のサイズのブロックに対応する。
ブロックがダウンロードされると、マスク内のビットが設定される。
ステータスファイルは、例えば最終修正時のサーバ・タイムスタンプなどの情報を含む外部データのための領域も含むことができ、それは、ダウンロード管理部によって、任意の一部分だけダウンロードされたデータが期限切れになったかどうかを決定するために使用可能である。
完全なメディアファイルがダウンロードされた場合、ダウンロード管理部は出力ファイルパス８０を作成し、リモート・ファイル８２の完全にダウンロードされたバージョンはダウンロード・パスへ出力される。
この時点で、クライアント・アプリケーションは、従来の方法においてメディアを再生し、「トリック再生」機能をサポートするために、ローカルファイルを使用できる。

ダウンロードされるファイルのサイズに依存して、データファイルは、長さが数ギガバイトの場合がある。
通常のファイル配分の仕方は、ファイル内の各バイトに対してゼロを割り当てるが、これは大きいファイルに完成するために数分を必要とする場合がある。
データファイル配分の間の待ち時間は、実際にファイルに書き込まれるバイト数を使用するのみである疎ファイルとしてファイルを配分することにより低減可能である。
疎ファイルが使用される場合、ファイル配分処理は非常に少ない時間のみを要求する。
他の実施形態においては、ダウンロード管理部の必要性に対して、待ち時間を重み付けする他のファイル配分の仕方が使用される。

データファイル（ステータスファイル内に示されるように）のブロック・サイズは、データがダウンロード可能である粒度を決定する。
小さいブロックサイズは、通常は、必要とされたバイトだけをダウンロードする点に関して、より効率的である。
しかしながら、小さいブロックサイズはマスクのサイズを大きくする結果を生じることがある。
多数の実施形態において、１２８のブロックサイズは、効率性とマスクのサイズとの間で調整するために用いられる。
他の実施形態において、アプリケーションの要求条件に基づいて決定される他のブロックサイズが利用される。

本発明の実施形態に従うダウンロード管理部を使用してデータを要求するための処理を図５に示す。
リモートサーバに格納されるメディアファイルからバイト範囲をダウンロードするために要求が受信された場合（９１）、処理９０が開始する。
図４に示すダウンロード管理部に類似したダウンロード管理部が使用される場合、ダウンロード管理部は、リモート・ファイル・オブジェクトおよびパーシャル・ファイル・オブジェクトのインスタンスを作成して、必要なサポート用ファイルを作成する。
接続は、リモートサーバにより確立され（９２）、要求されたバイト範囲は、要求キュー内に配置され（９４）、次いで要求される（９６）。
さらなるバイト範囲が受信されると、処理は、要求されたバイト範囲内のバイトのいずれかが以前にダウンロードされたかどうかを決定し、要求キューに、以前にダウンロードされなかったバイト範囲の部分のみを配置する。

図４に示すダウンロード管理部に類似したダウンロード管理部が、図５の処理９０を実施するために使用される場合、ステータスファイル７６におけるマスクは、データファイル７８にすでに格納された要求されたバイト、および要求されるべき残りのバイトを決定するために使用される。
各バイト範囲要求はオーバヘッドを関連付けており、それゆえ、本発明の多数の実施形態は、バイト範囲要求において複数のバイト範囲を含み、および／または、キューの先頭のバイト範囲のすぐ近くのバイト範囲に対して、要求キューを検索し、そのすぐ近くのバイト範囲の全てを含む、大きいバイト範囲を要求する。
いくつかの実施形態において、処理は、ダウンロード・データレートを上昇させ、および／または、接続を介してなされ得るバイト要求の数を制限するサーバを収容するために、複数の接続をオープンにする。
また、接続をオープンにすることは、オーバーヘッドを関連付ける。
それゆえ、接続の数は、特定の用途に適切な制限に基づいて制限可能である（例えば５つ）。

要求キューに、もはやバイト範囲がないと判定される場合（１００）、処理は、ファイルが完全にダウンロードされたかどうか判定する（１０２）。
ファイルが完全にダウンロードされなかった場合、処理は、一部分だけダウンロードされたファイル・オブジェクトから、失われているバイトを要求する。
一旦、ファイルが完全にダウンロードされると、そのダウンロードされたファイルはその出力ディレクトリに対してエクスポートされ、リモートサーバとの接続が閉じられ（１０４）、処理が完了する。
多数の実施形態において、再生が完了した後で、データファイルがエクスポートされる。

バイト範囲のダウンロードのための特定の処理を図５に示し、この処理および／または、特定のバイト範囲のダウンロードおよびデータ・ファイルの組立を可能にする代替処理は、本発明の実施形態に従って使用できる。
加えて、処理は、メディア再生上の通信オーバヘッドの影響を最小化するために、様々な最適化のいずれかを含むことができる。

ユーザが「トリック再生」命令を提供する場合、前もって要求されたバイト範囲はユーザによって命令される仕方でメディアの再生を継続するために要求されなくてもよい。
本発明の多数の実施形態に従うダウンロード管理部は、待機中のバイト範囲要求のキューをフラッシュし、バイト範囲要求の新しいキューを確立する能力を有する。
要求キューをフラッシュする利点は、現在のより高い優先順位のバイト範囲をダウンロードするのに先立って、以前に要求されたバイト範囲が要求されるまで待機することに関連する待ち時間がないことである。
多数の実施形態において、リモートサーバとの接続を閉じること、および新しい接続をオープンにすることは、更に待ち時間を低減する。
接続を閉じることで、新しいダウンロード要求に応答するメディア・サーバに先立って、メディア・サーバが待機中のダウンロード要求に応答するのを待つことに関連した待ち時間を除去できる。

本発明の一実施形態に従う要求キューをフラッシュするための処理を図６に示す。
処理１１０は、フラッシュ要求を受信すること（１１２）、要求キューをフラッシングすること（１１４）、メディアサーバとの接続を閉じること（１１６）を含む。
多数の実施形態において、「トリック再生」要求が受信された場合、他の処理は、待ち時間を低減するために使用することができ、以前要求されたメディアファイルの部分に対する早急な処理の必要性を除去し、以前に要求されなかったリモートメディアファイルの部分に対する早急な処理の必要性を作成する。

データがダウンロード管理部により受信される場合、ステータスファイルおよびデータファイルは、受信されたバイトを反映するために両方とも更新される。
本発明の実施形態に従うリモートメディアサーバからバイトの受信を処理するための処理を図７に示す。
処理１３０は、バイトを受信すること（１３２）、ステータスファイル中のマスクを更新すること（１３４）、およびデータファイルを更新すること（１３６）を含む。
次いで、ファイルが完全にダウンロードされたかどうかについての判定がなされる（１３８）。
ファイルが完全にダウンロードされていない場合、処理は、追加のバイトを受信するために待機する。
ファイルが完全にダウンロードされた場合、ダウンロードされたメディアファイルは、その出力ディレクトリにエクスポートされる（１４０）。
他の実施形態において、他の処理は、受信されたバイト範囲を編成するために使用される。

本発明の実施形態に従うファイル・パーサ部は、ダウンロード管理部に対して、バイト範囲要求に、再生エンジン部からのハイレベル要求を変換し、そのダウンロード管理部によってダウンロードされたバイト範囲を再生エンジン部に送るために使用される。
装置が、リモートメディアサーバに格納したメディアファイルをプログレッシブに再生することを開始する場合、ファイル・パーサ部はファイルにアクセスし、メディアファイルのコンテンツに関する情報をダウンロードする。
上述で、参照することにより援用される、米国特許出願第１１／０１６，１８４号および１１／１９８，１４２号明細書に記載されるメディアファイルは、メニュー情報および／または複数のメディア・シーケンスからの情報（すなわち、別個のメディア表示（ｄｉｓｔｉｎｃｔ ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎｓ））を含む。
ファイル・パーサ部は、メニュー情報およびメディア・シーケンスに関する情報を取得する。
メディア・シーケンスがユーザにより選択された場合、ファイル・パーサ部は選択されたメディア・シーケンスに対してインデックスを取得し、そのインデックスは、メディア・シーケンスが再生されると、リモートメディアファイル内のバイト範囲を識別するために使用される。

本発明の一実施形態に従い、リモートメディアファイル内に含まれるメディア・シーケンスを決定し、選択されたメディアを抽出するために、本発明の一実施形態に係る処理を図８に示す。
処理１５０は、ファイル内に含まれる任意のメッセージニュー情報、およびメディアファイル内における異なるメディア・シーケンスの数に関する情報を取得すること（１５２）を含む。
ファイル・パーサ部がダウンロード管理部と連動して使用される実施形態において、ファイル・パーサ部は、ダウンロード管理部を使用しているメディアファイルから要求に対する情報のバイトを選択するために、メディア形式に関する情報を使用する。
メニュー情報および／またはメディア・シーケンスの番号に関する情報は、各々のメディア・シーケンスに関する情報を取得する（１５４）ために使用できる。
役立つ情報は、メディア・シーケンスのタイトルに関する情報、メディア・シーケンスのフォーマット、メディア・シーケンスの交替の音声トラックの数、メディア・シーケンスにおける１つ以上のサブタイトル・トラックの有無、および／または、メディア・シーケンスの選択中のユーザまたはメディア・シーケンスの復号中のデコーダにとって有用な任意の追加情報を含む。
メディアが、ＡＶＩフォーマットにおいて、または、米国特許出願第１１／０１６，１８４号および第１１／１９８，１４２号明細書に記載されているファイルフォーマットのいずれかに類似したフォーマットでフォーマットされる場合、メディア・シーケンスの各々に関する情報は、各々のメディア・シーケンスごとにＲＩＦＦヘッダをダウンロードすることによって、ダウンロード可能である。
一旦、メディア・シーケンスに関する情報が取得されると、再生されることになっているメディア・シーケンスに関して選択がなされ得る（１５４）。
メディアファイルが単一のメディア・シーケンスを含む場合、その決定は自動的である。
メディアファイルがマルチプル・シーケンスを含む場合に、決定は、ファイル・パーサ部によって、リモートメディアファイルから取得されるメニュー情報を使用して生成されるメニューインターフェースを介して取得されるユーザ命令に基づいて行うことができる。
ファイル・パーサ部は、メディア・シーケンスのためのインデックス（１５６）に相当するバイト範囲をダウンロードするためにダウンロード管理部を導くためのメディア・シーケンスに関して取得される情報を使用する。
ファイル・パーサ部は、リモート・ファイルからデータを抽出する（１５８）ために、インデックスを使用できることができる。
プレーヤのエンジン部は、ファイル・パーサ部により抽出されるデータを決定する。
データが抽出される仕方は、メディアファイルのフォーマットに依存する。
メディアファイルがチャンクを利用するメディア・フォーマットにおいて、フォーマットされる場合、ファイル・パーサ部は、チャンク参照（ｃｈｕｎｋ ｒｅｆｅｒｅｎｃｅ）を、ダウンロード管理部を使用して取り出すことができる特定のバイト範囲に変換するために、インデックスを使用する。
他のフォーマットが使用される場合に、ファイル・パーサ部は、ファイル・パーサ部に利用可能であるファイル記述情報に対して適切なバイト・マッピングを使用する。
バイト範囲を要求することに加えて、本発明の実施形態に従うファイル・パーサ部は、特定の要求の状態をチェックするためにダウンロード管理部と通信することができ、ダウンロードされたバイトを再生エンジン部に提供できる。

再生エンジン部の第一の目的は、リモート・ファイルをプログレッシブで再生する場合、常に、ユーザにより要求される仕方でファイルを再生するために必要とされるメディア情報のキューを保持することである。
メディアファイルがインデックスを含む場合、再生エンジン部は、ユーザにより要求される仕方のメディアファイルを再生するために要求されるメディア情報を判定するために、インデックスを参照できる。
情報のチャンクとしてメディアを表示するためにフォーマットされたファイルから、メディアを取得するために用いられる発明の実施形態に従う処理を図９に示す。
処理１９０は、リモートメディアファイルからインデックスを取得すること（１９２）を含む。
再生エンジン部がファイル・パーサ部を介して情報を要求する実施形態において、再生エンジン部は、インデックスを取得するために命令をファイル・パーサ部に提供することができ、ファイル・パーサ部は、ダウンロード管理部を使用して、必要な情報を抽出できる。
次いで、再生エンジン部は、「トリック再生」命令を含み、ユーザから受信された命令に基づいて、チャンクを選択し（１９４）、選択されたチャンクをダウンロードする（１９６）ためにファイル・パーサ部に命令を提供する。
多数の実施形態において、再生エンジン部は、最も初期の最終期限第１選択戦略に基づいてチャンクを選択する。
使用していない音声トラックからのチャンク、およびメディア・シーケンス中で多重化された、使用されていないサブタイトル・トラックからのチャンクは、無視可能である。
多数の実施形態において、メディアのチャンクは、完全なインデックスのダウンロードに先立って要求される。
メディアは、通常、メディア・シーケンスの開始部分から再生され、それゆえ、インデックスがダウンロードされると、メディア・シーケンスの開始部分からのチャンクがダウンロードされる。
再生エンジン部がファイル・パーサ部からチャンクを受信した場合、チャンクはキューに入れられ（ｑｕｅｕｅｄ）、メディアの再生（１９８）を可能にする適切なデコーダに提供される。
映画の再生は、一旦、映画の十分な量がダウンロードされると、開始できる。
バッファリングされた全長は、チャンク・ダウンロード構成要素と共有される再生リストの全長によって、決定できる。

図９に関して上述されたチャンク選択処理は、要求されたチャンクのキューを維持する。
キューは、要求されたチャンクのためのインデックスエントリのリストとして維持できる。
チャンク・ダウンロード処理は、要求されたチャンクのダウンロード状態をポーリングする。
一旦ダウンロードされると、チャンクは、要求されたチャンクのキューから除去され、ダウンロードされたチャンクは、チャンク再生処理に送られる。

「トリック再生」命令が受信された場合、再生エンジン部は、「トリック再生」命令に適切なメディア情報を選択する。
例えば、早送りまたは巻戻し命令を受信した再生エンジン部は、トリック再生機能のレートにより決定されるタイミングで、メディア・シーケンスの全体を通じて、間隔を置かれたキー・フレーム（すなわち完全なフレーム）のみを要求できる。
多数の実施形態において、時間の間隔は、１０キー・フレーム／秒のトリックプレイ中に、再生レートを提供するために、０．１×トリックフレームレートである。
他の実施形態において、様々な他のアルゴリズムが、要求するメディアを決定するために使用される。
一旦、キー・フレームを含んだチャンクが識別されると、再生エンジン部は、ファイル・パーサ部およびダウンロード管理部を使用してチャンクを要求する。

上述が本発明の多数の特定の実施形態を含む一方で、これらは本発明の範囲の限定条件として解釈されるべきでなく、むしろその一実施形態の例として解釈されるべきである。
上述で提供された説明の多くは、メディアファイル内のメディア情報の異なる部分の位置を識別するインデックスを有しているメディアファイルを想定している。
多数の実施形態において、階層的なインデックスおよび／または他のインデックス・フォーマットは、メディアファイルに含まれ、再生エンジン部およびファイル・パーサ部は特定のインデックス構造を収容するように構成される。
様々な実施形態において、クライアント・アプリケーションは、インデックスを備えていないファイルフォーマットを含む複数のファイルフォーマットを収容するように構成されるが、メディアファイルのコンテンツを記載するために、他の情報を利用する。
従って、本発明の範囲は、図示された実施形態によって限定されるべきでなく、添付の特許請求の範囲およびそれらの均等物により限定されるべきである。

Claims (23)

1. リモートサーバ上のメディアファイルとして格納されたメディア・シーケンスをプログレッシブ再生する方法であって、
   前記リモートサーバから前記メディアファイルのコンテンツに関する情報を取得するステップと、
   前記メディア・シーケンス中で開始位置を識別するステップと、
   前記開始位置から前記メディア・シーケンスを再生するために必要とされるメディアに対応する前記メディアファイルのバイト範囲を識別するステップと、
   前記開始位置から前記メディア・シーケンスを再生するために必要とされる前記バイト範囲を要求するステップと、
   再生開始の待機中情報の受信されたバイトをバッファリングするステップと、
   情報のうち、前記バッファリングされたバイトを再生するステップと、
   ユーザ命令を受信するステップと、
   前記ユーザ命令に従い、前記メディア・シーケンスを再生するために必要とされるメディアに対応する前記メディアファイルのバイト範囲を識別するステップと、
   以前のバイト範囲要求をフラッシングするステップと、
   前記ユーザ命令に従い、前記メディアを再生するために必要とされる前記バイト範囲を要求するステップと、を含むことを特徴とする方法。
2. ダウンロードされた前記メディアファイルの前記部分のマスクを維持するステップと、
   前記ユーザ命令に従い、前記メディアを再生するために必要とされるバイト範囲の少なくとも一部が、前記マスクを用いて、既にダウンロードされたかどうかを識別するステップと、
   メディアサーバから、まだダウンロードされていないバイト範囲の前記部分のみを要求するステップと、をさらに含むことを特徴とする請求項１に記載の方法。
3. データファイル中のダウンロードされたバイトを格納するステップと、
   前記メディアファイルの全てのバイトがダウンロードされた場合に、前記ダウンロードされたメディアファイルを出力するステップと、をさらに含むことを特徴とする請求項２に記載の方法。
4. 前記データファイルは、疎データファイルであることを特徴とする請求項３に記載の方法。
5. 前記メディアファイルは、複数のメディア・シーケンスおよびメニュー情報を含み、
   前記メディア・シーケンス内で開始位置を識別するステップは、
   メニュー情報を表示するステップと、
   前記メディア・シーケンスの前記選択を示すユーザ命令を受信するステップと、
   前記メディア・シーケンス内で開始位置を示すユーザ命令を受信するステップと、を更に含むことを特徴とする請求項１に記載の方法。
6. 前記メディア・シーケンスは、複数の交換可能な音声トラックを含み、
   前記メディア・シーケンスの中で開始位置を識別するステップは、音声トラックを選択するステップを更に含み、
   前記開始位置から前記メディア・シーケンスを再生するために必要とされるメディアに対応する前記メディアファイルのバイト範囲を識別するステップは、選択されなかった前記音声トラックを含まないバイト範囲を選択するステップを更に含む、ことを特徴とする請求項１に記載の方法。
7. 前記メディア・シーケンスは、複数の交換可能なサブタイトル・トラックを含み、
   前記メディア・シーケンスの中で開始位置を識別するステップは、サブタイトル・トラックを選択するステップを更に含み、
   前記開始位置から前記メディア・シーケンスを再生するために必要とされるメディアに対応する前記メディアファイルのバイト範囲を識別するステップは、選択されなかった前記サブタイトル・トラックを含まないバイト範囲を選択するステップを更に含む、ことを特徴とする請求項１に記載の方法。
8. 前記シーケンスは、キー・フレームを含み、
   前記ユーザ命令に従い、前記メディアを再生するために必要とされるメディアに対応する前記メディアファイルのバイト範囲を識別するステップは、
   所定のユーザ命令に応答して一連のキー・フレームを識別するステップと、
   前記識別されたキー・フレームに対応する前記メディアファイルのバイト範囲を識別するステップとを更に含む、ことを特徴とする請求項１に記載の方法。
9. メディアファイルをプログレッシブ再生するシステムであって、
   メディアサーバと、
   クライアントと、
   ネットワークとを備え、
   前記クライアントおよび前記メディアサーバは、前記ネットワークを介して通信するように構成され、
   前記クライアントは、前記メディアサーバに、前記メディアファイルの少なくとも一部分に対する要求を送信するように構成され、
   前記サーバは、前記クライアントに、前記メディアファイルの要求された部分を提供するように構成され、
   前記クライアントは、前記メディアファイルの前記再生に関するユーザ命令を受信するように構成され、かつ、ダウンロードされておらず、前記メディアサーバから前記再生命令に適合するように要求されている前記メディアファイルの部分を要求するように構成される、ことを特徴とするシステム。
10. 前記メディアファイルに近接する部分はグループ化され、前記グループは、最も初期の最終期限第１ベース上において要求される、請求項９に記載のシステム。
11. 前記クライアントは、前記メディアファイルの要求された部分のキューを維持するように構成されることを特徴とする請求項９に記載のシステム。
12. 前記クライアントおよび前記サーバは、少なくとも１つの接続を介して通信するように構成され、
    前記クライアントは、前記メディアファイルの要求された部分の前記キューをフラッシュし、所定のユーザ命令の前記受信に応答して、前記接続のうちの少なくとも１つを切断するように構成されることを特徴とする請求項１１に記載のシステム。
13. 前記クライアントは、ファイル・マップおよびデータファイルを格納するように構成され、
    前記ファイル・マップは、ダウンロードされた前記メディアファイルの前記部分を示すマスクを含み、
    前記データファイルは、前記メディアファイルの前記ダウンロードされた部分を含むことを特徴とする請求項９に記載のシステム。
14. 前記データファイルは、疎ファイルであることを特徴とする請求項１３に記載のシステム。
15. 前記メディアファイルは、メディア・シーケンスおよびインデックスを含み、
    前記クライアントは、
    前記インデックスを取得して、ユーザ再生命令に適合するように要求される前記メディア・シーケンスの前記部分を決定するように構成される再生エンジン部と、
    前記メディア・シーケンスの前記部分を前記メディアファイルの部分にマップするために前記インデックスを用いるように構成されるファイル・パーサ部と、
    前記メディアファイルの部分をダウンロードするために前記メディアサーバと通信するように構成されるダウンロード管理部と、を備えることを特徴とする請求項９に記載のシステム。
16. ユーザ命令を受信するように構成されるユーザインターフェース部と、
    少なくとも１つのメディアファイルを格納するように構成される記憶装置と、
    ネットワーク接続部と、
    前記ネットワーク接続部を介してリモートで格納されたメディアファイルからファイルの少なくとも１つのバイト範囲を非同期で要求するように構成されるダウンロード管理部と、
    前記ユーザインターフェースを介して受信されるユーザ命令に応答してダウンロードされる、リモートで格納されたメディアファイルの部分を決定するように構成される再生エンジン部と、
    バイト範囲に、リモートで格納されたメディアファイルの部分に対する要求を中継して、前記ダウンロード管理部に前記バイト範囲を提供するように構成されるファイル・パーサ部と、を備えることを特徴とするメディアプレーヤ。
17. 前記ダウンロード管理部は、ダウンロードされたメディアファイルのブロックのマップを含むステータスファイルを作成するように構成され、
    前記ダウンロード管理部は、ダウンロードされたメディアファイルのブロックを格納するデータファイルを作成するように構成されることを特徴とする請求項１６に記載のメディアプレーヤ。
18. 前記ダウンロード管理部は、要求されたバイト範囲のキューを維持するように構成されることを特徴とする請求項１７に記載のメディアプレーヤ。
19. 前記ダウンロード管理部は、前記キューをフラッシュするように構成されることを特徴とする請求項１８に記載のメディアプレーヤ。
20. 前記再生エンジン部は、リモートメディアファイルから取得されるメニューを用いて、メニューを生成するように構成されることを特徴とする請求項１６に記載のメディアプレーヤ。
21. 前記再生エンジン部は、前記メニューを介して、リモートメディアファイル中の複数のメディア・シーケンスの１つの選択を受信するように構成されることを特徴とする請求項２０に記載のメディアプレーヤ。
22. 前記再生エンジン部は、前記メニューを介して、リモートメディアファイル中のメディア・シーケンスのための複数の音声トラックの１つの選択を受信するように構成されることを特徴とする請求項２０のメディアプレーヤ。
23. 前記再生エンジン部は、前記メニューを介して、リモートメディアファイル中のメディア・シーケンスのためのサブタイトルトラックの選択を受信するように構成されることを特徴とする請求項２０に記載のメディアプレーヤ。

Images