JP2007515096A - サーバからクライアントへのストリーミング - Google Patents

Abstract

本発明は，メタデータとメディアデータとを含むストリーミング可能なファイルを，サーバとクライアントとの間のネットワークを通じて，ストリーミング又はダウンロードするために構成する方法に関する。ここで，ファイルのメタデータの少なくとも一部がクライアントに送信され，その送信されたメタデータは，少なくともファイル中のメディアデータ範囲の位置情報を含む。ファイル中の所望のメディアデータ部分の位置は，受信したメタデータに基づいて判定される。要求がサーバに送られ，クライアントに転送されるべきメディアデータ範囲をサーバに知らせる。それにより，要求されたメディアデータ範囲がクライアントに送信される。

Description

本発明は，サーバからクライアントにストリーミング可能なファイルをストリーミングまたはダウンロードする構成に関する。

ストリーミングとは，音声ストリームとビデオストリームとのように同期した複数のメディアストリームを，それらストリームがデータネットワークを通じてクライアントに送信されている間，連続的に再生することができるアプリケーション能力を指す。マルチメディアストリーミングシステムは，ストリーミングサーバおよびいくつかのクライアント（プレイヤ）から成り，クライアントは，（おそらくはネットワークコネクションである）コネクションメディアを介してサーバにアクセスする。クライアントは，事前に格納されたマルチメディアコンテンツ，またはサーバからのライブマルチメディアコンテンツを取得し，コンテンツがダウンロードされている間，実質上実時間でそれを再生する。マルチメディア提示全体はムービーと呼んでもよく，論理的には複数のトラックに分割することができる。各トラックは単一メディア種別（例えば，ビデオのフレーム）の時系列を表現する。各トラック内の各時間ユニットはメディアサンプルと呼ばれる。

ストリーミングシステムは，サーバ側技術に基づいて２つのカテゴリに分けることができる。ここでこれらのカテゴリを，ノーマルストリーミングおよびプログレッシブダウンロードと呼ぶことにする。ノーマルストリーミングでは，サーバは送信ストリームのビットレートを制御するために，アプリケーションレベルの手段を用いる。目標は，その再生レートにほぼ等しくなるようなレートでストリームを送信することである。いくつかのサーバは，利用可能なネットワークに合わせるため，またネットワークの輻輳を避けるために，その場でマルチメディアファイルの内容を調整することができる。高信頼の，または信頼できないトランスポートプロトコルおよびネットワークを利用することができる。もし信頼できないトランスポートプロトコルが使われるならば，ノーマルストリーミングサーバは，典型的には，マルチメディアファイルにある情報を，ネットワークトランスポートパケットにカプセル化する。これは，特定のプロトコルおよびフォーマット，典型的にはＲＴＰ／ＵＤＰ（リアルタイムトランスポートプロトコル／ユーザデータグラムプロトコル）プロトコルおよびＲＴＰペイロードフォーマット，に従って実行することができる。

プログレッシブダウンロードは，ＨＴＴＰ（ハイパテキスト転送プロトコル）ストリーミング，ＨＴＴＰファストスタート，または擬似ストリーミングとも呼ばれ，高信頼トランスポートプロトコル上で動作する。サーバは，送信ストリームのビットレートを制御するために，どんなアプリケーションレベルの手段も用いてはならない。その代わり，サーバは，下位の高信頼転送プロトコルが提供するフロー制御メカニズムに頼ることができる。高信頼トランスポートプロトコルは，典型的にはコネクション指向である。例えば，フィードバックに基づくアルゴリズムを使って送信ビットレートを制御するために，ＴＣＰ（トランスポート制御プロトコル）が用いられる。その結果，アプリケーションはどんなデータもトランスポートパケットにカプセル化する必要がなく，擬似ストリーミングシステムにおいてマルチメディアファイルはそのまま送信される。このようにして，クライアントはサーバ側にあるファイルの正確な写しを受信する。これによってデータを再送信することなく，ファイルを複数回再生することができるようになる。

マルチメディアストリーミングのためのコンテンツを作成するとき，各メディアのサンプルは特定の圧縮方法を使って圧縮され，特定フォーマットに適合したビットストリームになる。メディア圧縮形式に加え，圧縮されたメディアサンプルを互いに関連付けるファイル形式であるコンテナ形式がとりわけ必要である。さらにファイル形式は，例えば，ファイルのインデクス付けに関する情報，どうやってメディアをトランスポートパケットにカプセル化するかに関するヒント，およびどうやってメディアトラックを同期させるかについてのデータを含んでもよい。マルチメディアコンテナファイル内のすべての付加情報はメタデータと呼ぶことができるが，メディアビットストリームはメディアデータとも呼ぶことができる。もしサーバからクライアントへ，ファイルをデータパイプ上でそのままストリーミングできるならば，そのファイル形式はストリーミング形式と呼ばれる。その結果，ストリーミング形式は複数メディアトラックをインタリーブして単一ファイルにし，メディアデータは復号順または再生順に現れる。下位のネットワークサービスが各メディア種別に対して別個の伝送チャンネルを提供しないときは，ストリーミング形式を使わなければならない。ストリーミング可能ファイル形式は，ストリーミングサーバがデータをストリーミングしている間に容易に利用できる情報を含む。例えば，ファイル形式はさまざまなネットワーク帯域幅用に複数版のメディアビットストリームを格納できるものであってもよく，それによりストリーミングサーバはクライアントとサーバとの間のコネクションに応じて，どのビットレートを使うか決めることができる。ストリーミング可能形式はそのままでストリーミングされることはまれであり，それ故，インタリーブするか，または個別メディアトラックへのリンクを持つことができる。

クイックタイム（ＱｕｉｃｋＴｉｍｅ）ファイル形式，ＩＳＯ基本メディアファイル形式，ＭＰＥＧ（動画専門家グループ）のＭＰ４ファイル形式，３ＧＰＰ（第三世代パートナシッププロジェクト）の３ＧＰファイル形式は擬似ストリーム可能ファイルを生成することができる。擬似ストリーミングが動作するように，これらストリーミング可能ファイルは特別なやり方で生成する必要がある。第１に，ファイル内のメディアデータ特性を定義するメタデータをファイル先頭に置かなければならない。少なくともいくつかのメタデータ，例えばファイルレベルメタデータは，クライアントがメディアデータを受信できるように，セッションの始めにクライアントに提供しなければならない。第２に，メディアデータはファイル内にインタリーブ形式で存在しなければならない。これは，メディアデータがファイル内で，例えばオーディオデータ，ビデオデータ，オーディオデータ，ビデオデータのように，時間軸順に格納されていなければならないことを意味する。第３に，ファイルはメタデータ中に，擬似ストリーミング可能であるとはっきりと印されていなければならない。

本発明の目的は，上記の制約のうち少なくともいくつかを避けることができるストリーミングの構成を提供することである。本発明のその目的は，本願の独立請求項に記載されたように特徴付けられた方法，システム，クライアント，通信デバイス，サーバおよび計算機プログラム製品によって達成される。本発明のいくつかの好ましい実施例は，本願の従属請求項に明らかにされている。

本発明によれば，少なくともファイルのメタデータの一部がクライアントに送信され，その送信されたメタデータは，少なくともファイル内のメディアデータ範囲の位置情報を有する。ファイル中の所望のメディアデータ部分の位置は，受信されたメタデータに基づいて判定される。サーバに要求が送信され，クライアントに転送すべきメディアデータ範囲をサーバに知らせる。要求されたメディアデータ範囲が次にクライアントに送信される。

クライアントとサーバとの間のセッションとは，ストリーミング可能なファイルを転送するためのクライアントとサーバとの間の任意の論理的関係すなわちコネクションを指す。ファイルという用語は，メタデータと，おそらくは複数のメディア源からのメディアデータとの双方を有する任意のデータグループを指す。所望のメディアデータは，例えばユーザのコマンドまたは提示順序情報に基づいて判定される。

本発明は，ファイル形式およびストリーミングの構成の点で特に柔軟性があり，特にマルチメディアコンテンツのストリーミングに利点がある。クライアントがファイル中のデータ範囲の位置を知っているので，メディアデータ範囲の前の部分がストリーミングまたはダウンロードされたか否かに関わらず，クライアントは基本的にファイルのどの部分でも要求することができる。例えば，ユーザはオーディオを消音することができ，その場合，ファイルのビデオメディアデータだけを要求するようにクライアントを構成することができる。このようにして，クライアントのユーザが前方探索または後方探索をするとき，クライアントは単純に後または前のバイトにジャンプすることができる。本発明はまた，取得されたメディアデータをファイルとして格納する必要がなく，クライアントが利用できるメモリを効率的な方法で使うことができるようにする。既に再生されたメディアデータ部分は取っておく必要がないので，メディアデータは再生−廃棄法で利用することができる。ファイル形式に関しては，クライアントがメディアデータの別々の範囲を所望の順序で要求することができるので，本発明はメディアデータをファイル中に任意の順序で置くことができる。

次に，本発明を，好ましい実施例を用い，また添付の図面を参照して，さらに詳細に説明する。図１はマルチメディアコンテンツストリーミングのための伝送システムを示す。このシステムは，エディタとも呼ばれ，典型的には複数のメディア源ＭＳから送信のためにメディアコンテンツデータを準備するエンコーダＥＮＣと，ネットワークＮＷを介して符号化されたマルチメディアファイルを送信するストリーミングサーバＳＳと，ファイルを受信する複数のクライアントＣと，を備える。コンテンツは，例えばビデオカメラのようなライブの提示を録画する録画機からでもよいし，ビデオテープ，ＣＤ，ＤＶＤ，ハードディスク，などの記録デバイスに事前に格納されていてもよい。コンテンツは，例えばビデオ，オーディオ，静止画であり，またデータファイルを構成していてもよい。エンコーダＥＮＣからのマルチメディアファイルはサーバＳＳへ送信される。サーバＳＳは複数のクライアントＣにサービスを提供することができ，マルチメディアファイルをサーバのデータベースから，またはエンコーダＥＮＣから直接に，ユニキャストまたはマルチキャスト経路を使ってマルチメディアファイルを送信することによって，クライアントの要求に応答する。ネットワークＮＷは，例えば移動体通信ネットワーク，ローカルエリアネットワーク，放送ネットワークまたはゲートウェイによって分離された複数の異なるネットワークであり得る。図１においてはコンテンツ作成機能（ＥＮＣによる）とストリーミング機能（ＳＳによる）とが分離されているが，それらは同じデバイスによって，または２以上のデバイスによって実行されてもよいことに注意すべきである。

次の実施例は，ストリーミング可能ファイルをストリーミングまたはダウンロードすることができる任意の無線及び／又は有線通信システムに適用し得る。下位伝送レイヤは，回線交換またはパケット交換のデータコネクションを利用することができる。そのような通信ネットワークの一例は，３ＧＰＰによって開発された第三世代移動体通信システムである。次の実施例においては，ＨＴＴＰプロトコルが少なくともストリーミング可能ファイルの一部を転送するために適用されることが想定されている。ＨＴＴＰ／ＴＣＰのほか，他のトランスポートレイヤプロトコルもまた利用できる。例えば，ＦＴＰ（ファイル転送プロトコル）またはＷＡＰ（無線アプリケーションプロトコル）群の中のＷＴＰ（無線トランザクションプロトコル）がトランスポート機能を提供することができる。

ストリーム可能ファイルに含まれるメタデータは次のように分類できる。典型的には，メタデータの一部の適用範囲はそのファイル全体である。そのようなメタデータは，使用されているメディアコーデックの識別情報または正しい表示長方形サイズの識別情報を含むことができる。この種のメタデータは，ファイルレベルメタデータ（または提示レベルメタデータ）と呼ぶことができる。もう１つのメタデータ部分は特定のメディアサンプルに関連する。そのようなメタデータは，サンプルの種別およびバイトで示されるサイズの指示を含むことができる。そのようなメタデータは，サンプル特定メタデータと呼ぶことができる。

メディアの復号および再生は，典型的にはファイルレベルメタデータなしでは不可能なため，そのようなメタデータはファイルをストリーミングする際，始めにファイルヘッダセクションとして現れる。実施例においては，少なくともメディアデータのオフセット位置を判定するための情報は，ファイル先頭でファイルレベルメタデータとして判定される。サンプル特定のメタデータはメディアデータとインタリーブしてもよいし，ファイル先頭でファイルレベルメタデータの直後またはそれとインタリーブして，統合セクションとして現れてもよい。

図２は，図１におけるクライアントＣのようなストリーミングクライアントの機能を示す。ステップ２０１において，クライアントは，ストリーム可能ファイルのストリーミングまたはダウンロードのためにサーバとセッションを確立する。このステップの間，伝送リソースは予約され，図１のネットワークＮＷを経由してサーバとクライアントとの間に論理的コネクションが確立されている。ステップ２０２において，実際のストリーミングまたはダウンロードは，クライアントがサーバに，少なくともメタデータ部分のサイズを表すファイルの一部を要求したときに起動される。この情報は典型的にはファイル先頭にあり，当然に適用されるファイル形式に依存する。例えば，３ＧＰファイル形式では，この情報は「ｍｏｏｖ」ボックスに先立つ４バイトによって特定され，このファイル形式が適用されたとき，クライアントはこれら４ビットを要求し（ステップ２０２），後にチェックする（ステップ２０４）ように構成される。クライアントは，問題のファイルを例えばＵＲＩ（統一リソース識別子）によって表す。クライアントはこのようにして，この情報を含むファイルの範囲すなわち部分を表すことによってファイルの特定部分を要求する。

ステップ２０３において，クライアントは少なくともメタデータのサイズを表すファイルの一部を受信する。受信した情報に基づいて，クライアントはファイル中のメタデータの位置を判定し，特定されたメタデータ範囲の要求を形成する（ステップ２０４）。クライアントは，メタデータ全部を要求してもよいし，一部だけを要求してもよい。この要求はステップ２０５においてサーバに送信される。

ステップ２０６において，クライアントはメタデータを受信し，好ましくはそれをストリーミングまたはダウンロードセッションのために格納する。受信したメタデータは，少なくともファイル中のメディアデータ範囲の位置情報を有する。これらメディアデータ範囲は適用するファイル形式によって変わる。メディアデータ範囲は，例えば，１メディアサンプルだけ決めるものや，トラックのようなメディアサンプルのグループを決めるものがあり，１以上のメディア種別を有する。この情報に基づいて，クライアントはメディアデータのバイトオフセット位置を判定することができる。クライアントが異なるメディアデータ範囲すなわち部分の位置を知ったとき，どのメディアデータ範囲がストリーミングまたはダウンロードを要望されているかを判定することができる。これには，ユーザへのプロンプトを含んでもよい。典型的には，既に受信したメタデータはファイルレベルの提示順序情報及び／又は復号順序情報を含んでおり，それに基づいて要求するメディアデータ範囲が判定される。クライアントが所望の１以上のメディアデータ範囲に気付いたとき，クライアントは受信した位置特定のメタデータに基づいてファイル内のそれらの位置を判定する（ステップ２０７）。次に，クライアントに転送すべき少なくとも１のメディアデータ範囲を表す要求を形成し（ステップ２０８），サーバにこの要求を送信する（ステップ２０９）。このメディアデータ範囲は要求において（メタデータにおいても）バイト範囲値として指定され，少なくとも要求される最初と最後のバイト値を決定する。実装および下位転送プロトコルに依存して，１以上のメディアデータ範囲を指定することができる。

例えば，３ＧＰ，ＩＳＯおよびＭＰ４ファイル形式を適用したときは，メディアデータ範囲すなわち部分の位置は，メタデータ内にあるサンプル−ツ−チャンクボックスおよびチャンクオフセットボックスによって識別することができる。これらの情報フィールドを調べることにより，クライアントは各サンプルのバイト範囲をファイル先頭からの相対値として識別することができる。ＩＳＯ適合ファイル形式のこれらフィールドおよび他の部分の更なる情報については，ＩＳＯ／ＩＥＣ／ＪＴＣ１／ＳＣ２９／ＷＧ１１の仕様「ISO Media File format specification MP4 Technology under consideration for ISO/IEC 14496-1:2001 Amd 3」（２００１年７月２０日）を参照されたい。より特定するならば，5.3章がボックスの定義を述べている。

ステップ２１０において，クライアントは要求２０８，２０９で指示された範囲に見つかった要求されたメディアデータを受信する。メディアデータは次に，適切に利用される。典型的には，（十分なメディアデータが受信されたときに）それはパースされ，ユーザのために再生されるが，さらに後の利用のために格納してもよい。１実施例では，ステップ２１０においてクライアントＣは，サーバＳＳから圧縮され多重化されたマルチメディアファイルの一部を受信する。クライアントＣは，個別メディアトラックを得るためにその部分をパースし，多重化を解く。これらメディアトラックは次に伸張され，ユーザインタフェースの出力デバイスを使って再生できる再構築されたメディアトラックとなる。これらの機能に加え，クライアントに最終ユーザの操作，すなわち最終ユーザの入力に応じた再生の制御およびクライアント・サーバ制御の操作，を取り入れるためのコントローラユニットが提供される。独立したメディア再生アプリケーションまたはブラウザのプラグインが再生機能を提供する。

特にストリーミングの目的には，ステップ２０８，２０９においてメディアデータの比較的小さな部分だけを要求することが非常に役に立つことに注意することが重要である。したがって１実施例では，クライアントは，例えば時間軸上の復号順および表示順に，提示のさまざまな部分に対する連続的な要求を形成し送信するように構成される。しかし，メディアデータ部分に対する要求順序は，例えばユーザがある部分を飛ばしたいかもしれないので異なることがある。したがって，クライアントは，ユーザからのコマンドに基づいて，若しくは特定の時限後に，若しくはファイルの提示の状態またはいくつかの他の基準に基づいて，ステップ２０７，または２０８に戻るように構成することができる。

既に述べたようにクライアントは，メディアデータ部分の順序，すなわちステップ２０８においてどのメディアデータが要求されるかを，典型的には，受信したメタデータにあるディスプレイ順序および復号順序情報フィールドに基づいて判定するように構成される。例えば，３ＧＰ，ＩＳＯおよびＭＰ４ファイル形式では，タイム−ツーサンプルアトムが提示時刻からメディアサンプルへのマッピングをする。クライアントは，この情報を使ってサンプルの要求順序を理解し，バイト位置に関連するメタデータを使ってサンプルをバイト範囲にマップするように構成することができる。

図３はストリーミング可能ファイルを転送するサーバの機能を示している。図３に示す機能が適用されるサーバは，図１におけるＳＳのようなストリーミングサーバでもよいし，クライアントからの要求に基づいてストリーミング可能ファイルをパースし転送することのできるどんなサーバでもよい。要求されたファイルはサーバデバイスに格納されてもよいし，要求への応答として，ある他のエンティティへアクセスし，及び／又はそこからダウンロードしてもよい。ステップ３０１において，サーバはストリーミング可能ファイルをストリーミング又はダウンロードするためにクライアントとセッションを確立する。ステップ３０２において，サーバは少なくともメタデータ部分のサイズを表すファイルの一部に対する要求をクライアントから受信する。サーバは，指示された範囲に基づいて参照されているファイル内の当該範囲のコンテンツを判定する，すなわち，少なくともメタデータ部分のサイズを決定するフィールド値を判定するように構成される。サーバは，少なくともメタデータサイズを表すファイルの一部を有する応答メッセージを形成し（ステップ３０３），それをクライアントに送信する。

ステップ３０４において，サーバは，クライアントに転送すべきメタデータ範囲についての指示を有する要求を受信する。上記と類似の方法で，サーバは次にファイルの要求された範囲を判定して応答メッセージを形成し，それが次にクライアントに送信される（ステップ３０５）。

ステップ３０６において，サーバは，クライアントに転送すべき少なくとも１のメディアデータ範囲を表す要求をクライアントから受信する。サーバは，ファイル中の要求された少なくとも１のメディアデータ範囲を判定し，要求されたメディアデータ範囲を有する応答を形成する（ステップ３０７）。次に，サーバはその応答をクライアントに送信する（ステップ３０８）。上記のように，クライアントは多数の要求を起動してもよく，その場合，プロセスはステップ３０６に戻る。

本発明の機能性をどのように実行するかについては，他の実施例も存在する。１実施例においては，ステップ２０２〜２０６および３０２〜３０３は不必要であり，どんな範囲指定もない要求か，または予め（大きな）範囲が定められた要求により，ステップ２０１の後，クライアントは単にストリーミングまたはダウンロードを開始する。クライアントがさまざまなメディアデータ範囲すなわち部分の位置，例えばバイトオフセット位置，を記述するメタデータ部分を受信したとき，ステップ２０７に入ることができる。

要求および応答は，任意の高信頼トランスポートプロトコルを使ってクライアントとサーバとの間で転送することができる。そのような１プロトコルはＨＴＴＰである。実施例では，ＨＴＴＰ１．１版の範囲指定機能を，図２および３に関連して前に示したように，要求されたメタデータ範囲及び／又はメディアデータ範囲を表す目的に使うことができる。このようにして実施例のクライアントはＨＴＴＰ ＧＥＴ要求を形成するように構成され，その要求は，ファイルおよびおそらくはある他の情報のＵＲＩに加えて，ファイル内のメディアデータ／メタデータの１以上の範囲をバイト範囲パラメータに有する。ＨＴＴＰの機能性についての更なる情報については，ＩＥＴＦ ＲＦＣ２６１６，「ハイパテキスト転送プロトコル −− ＨＴＴＰ／１．１」，１９９９年６月，を参照されたい。特に範囲の利用法については，３．１２，１３．５．４，１４．３５．１の各章節に記載されている。クライアントがＨＴＴＰ仕様に従ってＨＴＴＰ ＧＥＴ要求を形成するように構成されていれば，ＨＴＴＰ１．１版に適合するどのサーバでも，１以上の範囲を有する要求に応答することができる。このように，好ましい実施例ではＨＴＴＰサーバに変更が不要である。上記のように，１実施例においてはメディアデータ部分に対する連続的な要求をおそらくは短い時間間隔で送信する必要がある。実施例では，この目的のためにＨＴＴＰパイプライン技術を適用する。この技術により，クライアントは応答を待たずに複数の要求を送信することができ，単一のＴＣＰコネクションはより短時間，より効率的になる。このようにクライアントは，ステップ２０９においてパイプライン化されたＨＴＴＰ ＧＥＴ要求を送信するように構成され，往復時間を短縮することができる。既に述べたように，上記の代替案は，要求内に複数のバイト範囲を組み込むことである。

実施例では，ステップ２０４および２０５において，メタデータの一部だけが要求される。したがって，少なくともある他のメタデータ部分は，例えばメディアデータ受信フェーズなど後で要求するようにクライアントを構成してもよい。クライアントはメタデータのどの部分がまだ受信されていないか判定でき，それを即時に，または１以上のメディアデータ範囲の要求（ステップ２０７〜２０９）に関連した別個の要求と共に要求することができる。サーバはそれによりファイル内の指示された範囲を判定し，次にそれらをクライアントに送信するように構成される。１つのさらなる実施例では，サーバは要求されたメタデータとメディアデータとを応答の中でインタリーブさせるように構成され，クライアントもまた応答をパースし，メタデータからメディアデータを分離するように構成される。

上記の特徴は，どのストリーミング可能ファイル形式にも実施できる。利用できるファイル形式のいくつかの例は，ＭＰＥＧ−４（ＭＰ４）ファイル形式，クイックタイム形式，ＩＳＯ基本メディアファイル形式および３ＧＰファイル形式である。

セッションの始めで受信され格納されるメタデータは，引き続くメディアデータ部分に必要なすべてのメタデータからなる。メディアデータサンプルと，該メディアデータサンプルに関連するメタデータとが独立したセグメントとしてグループ化されているセグメント化ファイル形式を利用することも可能である。これらのセグメントは，必要なメディアデータが取得され，符号化された直後に作成し，格納することができる。セグメントを持つこの種のファイル形式をどのようにして形成し，利用するかについての更なる情報については，国際特許出願公報ＷＯ０３／０２８２９３を参照されたい。

上記のファイル形式は，ファイルのどの部分も，どのような所望の順序ででも再生することができる。メディアデータ部分は，受信デバイスＣにおいてパースされた後，消去（一時メモリから削除）することができる。これにより，ファイルのパース中はメタデータのみ，あるいはセグメント化手法ではファイルレベルメタデータのみ，を維持すればよいので，一時記録スペースをより少なくすることができる。もし，ファイルをパースしているデバイスがマルチメディアファイルの再生も行うならば，メディアデータ（およびセグメント化手法ではメディアデータに直接関連したメタデータ）は，その再生後永久に消去してもよい。これにより所要メモリリソース量はさらに削減される。

本発明は既存の通信デバイスに実装することができる。それらはすべて，本発明の機能性を実装することができるプロセッサおよびメモリを備えている。特定のプログラムコードをプロセッサで実行すれば，通信デバイスに上記の本発明に係るクライアント及び／又はサーバの機能の少なくとも一部を実装することができる。そのプログラムコードは通信デバイスに組み込まれていてもよいし，外部記憶媒体又は通信デバイスから当該デバイスにロードしてもよい。個別論理部品又は１以上のアプリケーション特定集積回路（ＡＳＩＣ）からなる回路のような，さまざまなハードウェア実装もまた可能である。

本技術の当業者にとって，技術の進展に伴い，本発明の思想が多くの異なる方法で実装できることは明らかである。それ故，本発明およびその実施例は上記の例に限定されず，本願請求項の範囲内および精神内で変形し得るものである。

マルチメディアコンテンツのストリーミングのための伝送システムを示すブロック図である。 本発明の実施例のクライアントの機能を示す図である。 本発明の実施例のサーバの機能を示す図である。

Claims (17)

1. サーバとクライアントとの間のネットワークを通じて，メタデータとメディアデータとを有するストリーミング可能なファイルを，ストリーミング又はダウンロードするように構成する方法であって，
   クライアントとサーバとの間にセッションを確立するステップと，
   前記クライアントに，前記ファイル中の少なくともいくつかの前記メディアデータ範囲について少なくとも位置情報を有する，前記ファイルの前記メタデータの少なくとも一部を送信するステップと，
   前記の受信したメタデータに基づいて，前記ファイル中の所望のメディアデータ部分の位置を判定するステップと，
   要求を前記サーバに送信して，前記クライアントに転送すべきメディアデータ範囲を前記サーバに知らせるステップと，
   その要求されたメディアデータ範囲を前記クライアントに送信するステップと，
   を有する方法。
2. 少なくとも前記メタデータのサイズを表す前記ファイルの一部を前記サーバに要求することによって，ストリーミング又はダウンロードを開始するステップと，
   前記クライアントに，少なくとも前記メタデータのサイズを表す前記ファイルの前記一部を送信するステップと，
   その受信したサイズ情報に基づいて，前記ファイル中の前記メタデータ部分の位置を判定するステップと，
   前記サーバに要求を送信して，前記クライアントに転送すべき前記メタデータ範囲を前記サーバに知らせるステップと，
   このストリーミングセッションのために前記メタデータを格納するステップと，
   前記メタデータを使って前記所望のメディアデータの位置を判定するステップと，
   を有する請求項１に記載の方法。
3. 前記メタデータ範囲要求においては前記メタデータの一部だけを要求し，メディアデータの受信中には前記メタデータの少なくともいくつかの他の部分を要求する請求項２に記載の方法。
4. 前記の要求されたメタデータと前記メディアデータとをインタリーブさせる請求項３に記載の方法。
5. 前記要求をＨＴＴＰ ＧＥＴ要求とする請求項１または２に記載の方法。
6. 前記ファイル中の前記所望の１以上のメディアデータ範囲またはメタデータ範囲に対応して，前記のＨＴＴＰ ＧＥＴ要求が１以上のバイト範囲を有する請求項４に記載の方法。
7. サーバとクライアントとを備える通信システムであって，
   前記サーバと前記クライアントとが，メタデータとメディアデータとを有するストリーミング可能なファイルをストリーミングまたはダウンロードするためのセッションを確立し，
   前記サーバが前記クライアントに，前記ファイルの前記メタデータの少なくとも一部を送信し，その送信されたメタデータが，前記ファイル中の少なくともいくつかのメディアデータ範囲の少なくとも位置情報を有し，
   前記クライアントがその受信されたメタデータに基づいて，前記ファイル中の所望のメディアデータ範囲の位置を判定し，
   前記クライアントが前記サーバに要求を送信し，前記クライアントに送信されるべき前記メディアデータ範囲を前記サーバに知らせ，
   前記サーバが前記クライアントに，前記の要求されたメディアデータ範囲を送信する，
   ように構成する通信システム。
8. ストリーミングシステムのためのクライアントであって，
   メタデータとメディアデータとを有するストリーミング可能なファイルをストリーミングまたはダウンロードするためにサーバとセッションを確立し，
   前記サーバから前記ファイルの前記メタデータの少なくとも一部を受信し，その受信したメタデータが前記ファイル中の少なくともいくつかのメディアデータ範囲の少なくとも位置情報を有し，
   前記の受信したメタデータに基づいて，前記ファイル中の所望のメディアデータ部分の位置を判定し，
   前記サーバに要求を送信し，前記クライアントに転送すべき前記メディアデータ範囲をサーバに知らせる，
   ように構成するクライアント。
9. 少なくとも前記ファイル中の前記メタデータのサイズを表す前記ファイルの一部を前記サーバに要求し，
   少なくとも前記メタデータのサイズを表す前記ファイルの前記の一部を受信し，
   その受信したサイズ情報に基づいて，前記ファイル中の前記メタデータ部分の位置を判定し，
   前記サーバに要求を送信し，前記クライアントに転送すべき前記メタデータ範囲を前記サーバに知らせ，
   このストリーミングセッションために前記メタデータを格納し，
   前記メタデータを使って，前記所望のメディアデータの位置を判定する，
   ように構成する請求項８に記載のクライアント。
10. 前記メタデータ範囲要求においては，前記メタデータの一部だけを要求し，
    メディアデータ受信中には，前記メタデータの少なくともいくつかの他の部分を要求する，
    ように構成する請求項９に記載のクライアント。
11. 前記クライアントが，前記サーバからの応答をパースするように構成され，前記要求されたメタデータと前記メディアデータとをインタリーブさせる請求項１０に記載のクライアント。
12. 前記メタデータ範囲または前記メディアデータ範囲を要求するために，ＨＴＴＰ ＧＥＴ要求を形成するように構成する請求項８または９に記載のクライアント。
13. 前記ファイル中の前記の所望の１以上のメディアデータ範囲またはメタデータ範囲に対応して，前記ＨＴＴＰ ＧＥＴ要求に１以上のバイト範囲を加えるように構成する請求項１２に記載のクライアント。
14. さまざまなメディアデータ範囲を持つＨＴＴＰ ＧＥＴ要求を，パイプラインするように構成する請求項１２に記載のクライアント。
15. 前記の受信されたメタデータにおいて，要求されることになる少なくとも１つのメディアデータ部分をファイルレベルの表示順序情報及び／又は復号順序情報から判定し，
    前記の受信したメタデータに基づいて，前記ファイル中の選択されたメディアデータ部分の位置を判定するように構成する請求項８に記載のクライアント。
16. 請求項８〜１５のいずれか一項に記載のクライアントを備える通信デバイス。
17. 通信デバイスを制御するための計算機プログラム製品であって，前記通信デバイスに対して，
    メタデータとメディアデータとを有するストリーミング可能なファイルをストリーミングまたはダウンロードするために，サーバとセッションを確立させ，
    前記サーバから前記ファイルの前記メタデータの少なくとも一部を受信し，その受信したメタデータが少なくとも前記ファイル中のメディアデータ範囲の位置情報を有し，
    前記の受信されたメタデータに基づいて，前記ファイル中の所望のメディアデータ部分の位置を判定し，
    前記サーバに要求を送信し，前記クライアントに転送すべき前記メディアデータ範囲を前記サーバに知らせる，
    ように作用するプログラムコードを有する通信デバイスを制御するための計算機プログラム製品。

Images