JP5296859B2 - リアルタイム又はほぼリアルタイムのストリーミング - Google Patents

Description

本発明は、データ送信技術に係る。より詳細には、本発明は、例えば、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）のような非ストリーミングプロトコルを使用してデータのストリーミングを行えるようにする技術に係る。

関連出願：本出願は、次の米国プロビジョナル特許出願の出願日の利益を主張する。
（１）２００８年１２月３１日に出願された特許出願第６１／１４２，１１０号（管理番号Ｐ７４３７Ｚ）；
（２）２００９年３月１６日に出願された特許出願第６１／１６０，６９３号（管理番号Ｐ７４３７Ｚ２）；
（３）２００９年３月１７日に出願された特許出願第６１／１６１，０３６号（管理番号Ｐ７４３７Ｚ３）；
（４）２００９年４月７日に出願された特許出願第６１／１６７，５２４号（管理番号Ｐ７４３７Ｚ４）；
（５）２００９年９月８日に出願された特許出願第６１／２４０，６４８号（管理番号Ｐ７４３７Ｚ５）；及び
（６）２００９年１２月２１日に出願された特許出願第６１／２８８，８２８号（管理番号Ｐ７４３７Ｚ６）。これら米国プロビジョナル特許出願は、全て、本開示と矛盾しない程度に参考としてここに援用する。

本米国特許出願は、参考としてここに各々援用する次の米国特許出願に関連している。
（１）２００９年６月５日に出願された“REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第１２／４７９，６９０号（管理番号Ｐ７４３７ＵＳ１）；
（２）２００９年６月５日に出願された“VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第１２／４７９，６９８号（管理番号Ｐ７４３７ＵＳ２）；
（３）２００９年６月５日に出願された“UPDATABLE REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第１２／４７９，７３２号（管理番号Ｐ７４３７ＵＳ３）； （４）２００９年６月５日に出願された“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第１２／４７９，７３５号（管理番号Ｐ７４３７ＵＳ４）。

コンテンツのストリーミングとは、一般的に、サーバー装置により常時送信されてクライアント装置により受信されるマルチメディアコンテンツを指す。コンテンツは、通常、エンドユーザがストリーミングサーバーにより配信されている間に、エンドユーザに提示される。ネームとは、メディアそれ自身ではなく、メディアの配信方法を指す。

現在のストリーミングサービスは、一般に、エンドユーザに「生」のコンテンツを配布するために特殊なサービスを要求する。大規模な配備では、これが多大なコストを招き、設定及び運転のために特殊なスキルを必要とする。その結果、ストリーミングに利用できるコンテンツのライブラリーは、望ましいライブラリーには至らない。

一実施形態において、サーバー装置は、ストリーミングされるべきコンテンツの少なくとも一部分を記憶する。コンテンツは、典型的に、画像又は音声（例えば、サウンド又は音楽）或いはその両方の時間ベースストリームであり、時間ベースストリームの一例は、画像の順序及び提示が時間に基づいていて、従って、時間ベースストリームと考えられる映画である。サーバーは、ストリーミングされるべきコンテンツをネットワークプロトコルに基づいてパケットを経て送信されるべきセグメントへと分解するためのセグメントエージェントと、セグメント化されたユーザデータをクライアントが提示するのを容易にすることのできる１つ以上のプレイリストファイルを発生するためのインデクサエージェントとを備えている。クライアント装置は、ネットワークを経てサーバー装置（或いはセグメント及びプレイリストを記憶してそれらを送信するが、発生はしない別のサーバー）に結合される。クライアント装置は、１つ以上のプレイリストファイルを受け取り、そしてその１つ以上のプレイリストファイルに基づいてコンテンツへのセグメント化メディアファイルの検索を容易にするためのアッセンブラーエージェントを有している。又、クライアント装置は、そのクライアント装置の１つ以上の出力コンポーネントを経てコンテンツを出力するための出力ジェネレータエージェントも有している。

一実施形態において、サーバー装置は、クライアント装置へ送信されるべきデータを取得する。サーバー装置は、送信されるべきデータをセグメンタエージェントで複数のメディアファイルに分割する。又、サーバー装置は、複数のセグメントをメモリに個々のメディアファイルとして記憶する。更に、サーバー装置は、複数のメディアファイルへのリファレンスを有する１つ以上のプレイリストファイルを発生する。クライアント装置からのデータの要求に応答して、サーバー装置（又は別のサーバー装置）は、ネットワークを経てクライアント装置へ１つ以上のプレイリストファイル及び少なくとも複数のメディアファイルのサブセットを送信する。複数のメディアファイルは、クライアント装置からの要求に応答して非ストリーミング転送プロトコルを使用して送信することができ、このプロトコルは、例えば、ＨＴＴＰである。

一実施形態において、クライアント装置は、１つ以上のプレイリストファイルを受け取って記憶することができる。次いで、クライアントは、プレイリストファイルにおいて識別されたセグメント化されたメディアファイルを要求し、そしてリンクされたメディアファイルをダウンロードすることができる。次いで、クライアント装置（又は別のクライアント装置）は、コンテンツのストリームを表すオーディオ及び／又はビデオ出力を発生することができる。

一実施形態において、更新されたプレイリストを、サーバーによって動的に発生して、クライアントにより検索することができる。更新されたプレイリストは、オリジナルのプレイリストにおける番組に加えて示された付随的資料（例えば、サイドバーユーザインターフェイスにおける広告、関連コンテンツ、別のバージョン、等）を含むか、又は番組の付加的な部分（例えば、オリジナルのプレイリストにおいて識別された第１の半分を越える番組の第２の半分）を含むことができる。１つの具現化において、サーバーは、ここに述べるローリング方法を使用して、プレイリストを更新し、これを、次いで、クライアントにより更新されたプレイリストとして検索することができる。

一実施形態において、プレイリストは、同じコンテンツを表す複数の代替えストリームを特定することができ、これら代替えストリームは、異なる視覚解像度で送信される（ひいては、異なるビットレートで送信される）同じ番組でもよいし、或いは他の異なる属性を伴う同じ番組でもよい。サーバーは、代替えストリームごとに１つづつ、複数のプレイリストを発生することができ、又、代替えストリームを指すかさもなければそれを特定する変形プレイリストを発生することができる。次いで、サーバー（又は別のサーバー）は、変形プレイリストをクライアント装置へ送信することができ、そしてクライアント装置は、現在ネットワーク条件（例えば、メディアファイルを転送するのに使用されるネットワークの現在スループットレート）に基づいて、変形プレイリストからどのプレイリストを選択すべきか判断することができ、そしてクライアント装置は、選択されたプレイリストをダウンロードすることができる（更に、その選択されたプレイリストにより特定されたメディアファイルをダウンロードすることができる）。

一実施形態において、クライアント装置は、コンテンツを受け取って提示する間に変形プレイリストにおける第１のプレイリストからその変形プレイリストにおける第２のプレイリストへスイッチすることができる。例えば、クライアント装置は、第１のプレイリスト及び第１のビットレートを使用して番組を受け取ることができ、そしてネットワークのスループットレートの測定を通して、第２のプレイリストによりコンテンツが特定されるところの同じ番組のコンテンツをより高い第２のビットレートで受信できると決定することができる。この場合に、クライアント装置は、第２のプレイリストを要求し、第２のプレイリストを受け取り、そして第１のプレイリストにより特定されたコンテンツを提示し続けながら第２のプレイリストにおいて特定されたメディアファイルの検索を開始することができる。クライアント装置は、メディアファイル及び結果的に得られる解凍されたコンテンツを両プレイリストのバッファに記憶することができ、そしてクライアント装置は、自動的なオペレーションを遂行して、いつ、どのように、コンテンツの２つのバージョン間をスイッチ又は遷移すべきか決定することができる。例えば、クライアント装置は、コンテンツの２つのバージョンにおけるオーディオコンテンツのパターンマッチングを使用して、２つのバージョンにおける一致点を見出し、次いで、第２のプレイリストから新たなコンテンツの遷移を識別した後にスイッチを行わせることができる。

一実施形態において、方法は、代替えストリームを使用してメディアコンテンツをクライアント装置に与える複数の冗長位置を設けることを含む。フェイルオーバー保護を具現化するため、第１のサーバー装置又は第１のコンテンツ配布サービスは、ストリーム又は複数の代替え帯域巾ストリームを生成し、そしてプレイリストファイル（１つ又は複数）を作成する。第２のサーバー装置又は第２のコンテンツ配布サービスは、並列ストリーム又はストリームのセットを生成する。クライアントは、第１のサーバー装置又は第１のコンテンツ配布サービスに関連した第１のストリームを使用して第１のユニフォームリソースロケーター（ＵＲＬ）からプレイリストファイル（１つ又は複数）をダウンロードするよう試みる。クライアントは、第１のＵＲＬからプレイリストファイルをダウンロードできない場合に、別のＵＲＬに関連した代替えストリームへスイッチするよう試みる。

一実施形態において、方法は、プレイリストの要求を発し、その要求においてプレイリストを圧縮できることを特定し、そしてその要求に応答して、サーバーがプレイリストを圧縮形態で与えることができる場合にプレイリストを圧縮形態で受け取ることを含む（さもなければ、プレイリストは、サーバーにより非圧縮形態で与えることができる）。プレイリストは、デフレート又はｇｚｉｐのような既存のＨＴＴＰ標準圧縮技術によりサポートされる圧縮技術又はフォーマットを使用して圧縮（エンコードとも称される）することができる。圧縮形態でのプレイリストの送信及び受信は、特に、プレイリストが時間と共に成長するときに（例えば、プレイリストが長いベースボールゲーム用のものであるときに）、送信及び受信されるデータのサイズを著しく減少することができる。一実施形態において、プレイリストに圧縮を使用することは、クライアント（プレイリストを要求するシステム）及びサーバー（プレイリストを送信することにより要求に応答するシステム）の両方にとって任意である。ＨＴＴＰ規格の一部分である圧縮技術又はフォーマットを使用することは、適合するウェブサーバーが圧縮されたプレイリストを供給できるようにすると共に、適合するクライアントがプレイリストを解凍して使用できるようにもする。

本発明は、同様の要素が同じ参照番号で示された添付図面に、一例として、非限定的に示されている。

リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。 １つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。 １つ以上のサーバー装置が１つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。 １つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートである。 クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。 クライアント装置が複数のビットレートを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。 サーバーストリームエージェントの一実施形態のブロック図である。 クライアントストリームエージェントの一実施形態のブロック図である。 複数のタグを伴うプレイリストファイルの一実施形態を示す図である。 ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。 電子システムの一実施形態のブロック図である。 クライアント装置が変形プレイリスト内の代替えコンテンツ間をどのようにスイッチできるかの一例を示すフローチャートである。 クライアント装置が２つのプレイリストのコンテンツ間をどのようにスイッチできるかを示す更に別のフローチャートである。 クライアント装置がオーディオパターンマッチングを使用してコンテンツ間をどのようにスイッチできるかの一例を示す更に別のフローチャートである。 図９Ｃの方法がオーディオパターンマッチングでどのように具現化されるか概略的に示す。 代替えストリームを使用してクライアント装置へメディアコンテンツを与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。 一実施形態によりクライアント１１０２が１つ以上のＵＲＬと両方向に通信するネットワークを示す。

以下の説明では、多数の特定の細部について述べる。しかしながら、本発明の実施形態は、これらの特定の細部を伴わずに実施されてもよい。他の点については、良く知られた回路、構造及び技術は、説明の理解を妨げないために詳細に示さない。

この説明は、版権で保護される資料、例えば、グラフィックユーザインターフェイスの画像の例示を含む。本発明の譲受人を含む版権所有者は、これら資料において版権を含む権利を所有している。版権所有者は、特許商標庁の特許ファイル又は記録に現れるように特許文書又は特許開示を誰かが複写再現することに異議を唱えるものではなく、著作権の全ての権利は何であれ保存されるものとする。版権アップル社２００９年。

一実施形態において、ここに述べる技術及びコンポーネントは、非ストリーミングプロトコル（例えば、ＨＴＴＰ）及び他のテクノロジー（例えば、モーションピクチャーエクスパートグループ（ＭＰＥＧ）ストリーム）を使用してストリーミングの経験を配信するためのメカニズムを含むことができる。例えば、「生」のミュージカル又はスポーツ行事、生のニュース、ウェブカメラフィード、等を放送するために、ＨＴＴＰを使用してほぼリアルタイムのストリーミング経験を提供することができる。一実施形態では、プロトコルは、到来するメディアデータを複数のメディアファイルにセグメント化し、そしてそれらのセグメント化されたメディアファイルをサーバーに記憶することができる。又、プロトコルは、サーバーに記憶されたセグメント化されたメディアファイルにクライアントを向けるユニフォームリソースアイデンティファイア（ＵＲＩ）を含むプレイリストファイルを構築することもできる。セグメント化されたメディアファイルがプレイリストファイル（１つ又は複数）に基づいて再生されるときには、クライアントは、「生」の事象のほぼリアルタイムの放送をユーザに提供することができる。予め記録されたコンテンツを同様に提供することもできる。

一実施形態において、サーバーは、補足的又は代替え的メディアコンテンツ（例えば、広告、スポーツ行事に関連した統計情報、主たる提示に対する付加的なメディアコンテンツ）を放送事象に動的に導入することができる。例えば、メディア事象のクライアント再生中に、サーバーは、付加的なＵＲＩをプレイリストファイルに追加することができ、ＵＲＩは、クライアントが補足的メディアファイルをダウンロードできるところの位置を識別する。クライアントは、サーバーが導入した補足的又は付加的（又は両方の）メディアコンテンツにアクセスするために１つ以上の更新されたプレイリストファイルをサーバーから周期的に検索するように命令される。

一実施形態において、サーバーは、累積モード又はローリングモードのいずれかで動作することができる。累積モードでは、サーバーは、プレイリストファイルを生成し、そしてプレイリストファイルの終わりにメディアファイル識別子を添付することができる。次いで、クライアントは、ダウンロード時に単一のプレイリストファイルからストリームの全ての部分にアクセスすることができる（例えば、ユーザは、ショーの中間でスタートすることができる）。ローリングモードでは、サーバーは、ローリングベースでプレイリストファイルの始めからメディアファイル識別子を除去して、クライアント装置にアクセスできるメディアコンテンツのスライディングウインドウを設けることにより、メディアファイルの利用性を制限することができる。又、サーバーは、プレイリストにメディアファイル識別子を追加することもでき、そしてローリングモードでは、サーバーは、メディアファイルの利用性を、プレイリストに最新に追加されたものに制限することができる。次いで、クライアントは、プレイリストファイルの更新コピーを繰り返しダウンロードして見続ける。プレイリストダウンロードのためのローリングベースは、コンテンツが潜在的に時間的に無限である（例えば、連続的に動作されるウェブからコンテンツが到来する）ときに有用である。クライアントは、プレイリストに終了タグを見つけるまでローリングモードにおいてプレイリストを繰り返し要求し続けることができる。

一実施形態において、このメカニズムは、同じ提示の変形ストリームを与えることによりビットレートスイッチングをサポートする。例えば、サービスされるべき提示の多数のバージョンをサーバーに記憶することができる。各バージョンは、実質的に同じコンテンツを有するが、異なるビットレートでエンコードすることができる。これは、クライアント装置が、再生の連続性を妥協することなく、例えば、利用可能な帯域巾の検出に基づいて、ビットレート間をスイッチできるようにする。

一実施形態において、無断使用に対してコンテンツを保護するために保護特徴を設けることができる。例えば、予想を防止するために、非順次メディアファイルナンバリングを使用してもよい。又、メディアファイルの暗号化を使用してもよい。更に、部分メディアファイルリストを使用してもよい。又、付加的な及び／又は異なる保護特徴を設けてもよい。

図１は、リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。図１の例は、２つのクライアントがネットワークを経てサーバーに結合された簡単なサーバー／クライアント接続を示す。ここに述べる技術及びメカニズムを使用して、いかなる数のクライアントもサポートすることができる。更に、ここに述べる技術及びメカニズムに基づき、複数のサーバーがコンテンツを与えてもよく、及び／又はそれらが一緒に動作してコンテンツを与えてもよい。例えば、１つのサーバーがコンテンツを生成し、プレイリストを生成し、そして複数のメディア（例えば、ファイル）を生成すると共に、他のサーバーがその生成されたコンテンツを記憶し送信してもよい。

ネットワーク１１０は、ワイヤードであるか、ワイヤレス（例えば、ＩＥＥＥ８０２．１１、８０２．１６）であるか、又はその組み合わせであるかに関わらず、いかなる形式のネットワークでもよい。例えば、ネットワーク１１０は、インターネット又はイントラネットでよい。別の例として、ネットワーク１１０は、セルラーネットワーク（例えば、３Ｇ、ＣＤＭＡ）でもよい。一実施形態において、クライアント装置１５０及び１８０は、複数のネットワーク形式を経て通信することができる（例えば、各装置は、ＷｉＦｉワイヤレスＬＡＮを経て及びワイヤレスセルラー電話ネットワークも経て通信することができる）。例えば、クライアント装置１５０及び１８０は、セルラー無線電話ネットワーク及びデータネットワークを経て通信できるスマートホン又はセルラーイネーブル型パーソナルデジタルアシスタントでもよい。これらの装置は、いずれかの形式のネットワークを経てここに述べるストリーミングメカニズムを使用することもできるし、又は必要に応じてネットワーク間をスイッチすることもできる。

サーバー１２０は、この技術で良く知られたように、ＨＴＴＰサーバーとして動作してもよい。即ち、サーバー１２０は、ＨＴＴＰプロトコルを使用してコンテンツを与えるＨＴＴＰサーバーエージェント１４５を備えている。図１の例は、ＨＴＴＰに関して説明するが、他のプロトコルを同様に利用することができる。セグメンタ１３０及びインデクサ１３５は、ここに述べるようにメディアファイルのコンテンツにプレイリストファイルを与えるためにサーバー１２０（又は複数のサーバー）上に存在するエージェントである。これらのメディアファイル及びプレイリストファイルは、ＨＴＴＰプロトコルを使用してＨＴＴＰサーバーエージェント１４５を経て（又は他のサーバーを経て）ネットワーク１１０にわたり送ることができる。ここに述べるエージェントは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせとして具現化することができる。

セグメント１３０は、メディアデータのストリームを、ＨＴＴＰプロトコルを経て送信できる複数のメディアファイルへ分割するように機能する。インデクサ１３５は、セグメント化されたメディアファイルに対応するプレイリストファイルを生成するように機能して、クライアント装置がメディアファイルを再アッセンブルし、サーバー１２０により与えられたコンテンツをリアルタイム又はほぼリアルタイムで送信できるようにする。クライアント装置からの１つ以上の要求に応答して、ＨＴＴＰサーバーエージェント１４５（又は他のサーバー）は、インデクサ１３５により発生される１つ以上のプレイリストファイル及びセグメンタ１３０により発生されるコンテンツのメディアファイルを送信することができる。サーバー１２０は、更に、ここに述べるセキュリティ機能の１つ以上（例えば、暗号化）を与える任意のセキュリティエージェント１４０を備えている。又、サーバー１２０は、図１に示されていない付加的なコンポーネントを含んでもよい。

クライアント装置１５０及び１８０は、サーバー１２０からネットワーク１１０を経てプレイリストファイル及びメディアファイルを受け取る。クライアント装置は、ネットワークを経て送信されたデータを受け取ることができ、そしてネットワークを経て受け取ったデータ使用して出力を発生できる任意の形式の電子装置、例えば、ワイヤレス移動装置、ＰＤＡ、娯楽装置、消費者向け電子装置、等でよい。その出力は、任意のメディア形式又はメディア形式の組み合わせで、例えば、オーディオ、ビデオ、又はその組み合わせを含む。

クライアント装置１５０は、アッセンブラーエージェント１６０及び出力ジェネレータエージェント１６５を含むことができる。同様に、クライアント装置１８０は、アッセンブラーエージェント１９０及び出力ジェネレータエージェント１９５を含むことができる。アッセンブラーエージェント１６０及び１８０は、サーバー１２０からプレイリストファイルを受け取り、そしてそのプレイリストファイルを使用して、サーバー１２０にアクセスし、そこからメディアファイルをダウンロードする。出力ジェネレータエージェント１６５及び１９５は、ダウンロードされたメディアファイルを使用して、各々、クライアント装置１５０及び１６０から出力を発生することができる。出力は、１つ以上のスピーカ、１つ以上のディスプレイスクリーン、スピーカ及びディスプレイスクリーンの組み合わせ、或いは他の入力又は出力装置により発生することができる。又、クライアント装置は、メディアファイル（例えば、圧縮されたメディアファイル又は解凍されたメディアファイル）が受け取られたときにそれらを記憶するためのバッファとして作用するメモリ（例えば、フラッシュメモリ又はＤＲＡＭ、等）を含むこともでき、このバッファは、現在提示されているコンテンツの時間を越えて何秒にも値する提示可能なコンテンツを与え、新たなコンテンツがダウンロードされる間にそのバッファされたコンテンツを後で表示できるようにする。このバッファは、クライアント装置が間欠的な低速のネットワーク接続を通してコンテンツを検索するよう試みる間に提示可能なコンテンツを与えることができ、ひいては、このバッファは、ネットワークの待ち時間又は接続の問題を隠すことができる。

更に、クライアント装置１５０及び１８０は、各々、ここに述べるセキュリティ機能の１つ以上を与える任意のセキュリティエージェント１７０及び１８５を備えている。又、クライアント装置１５０及び１８０は、図１には示されていない付加的なコンポーネントを含んでもよい。

一実施形態において、本出願に述べる技術は、非ストリーミングプロトコル（例えば、ＨＴＴＰ）を経てマルチメディアデータの無限のストリームを送信するのに使用されてもよい。又、実施形態は、メディアデータを暗号化し及び／又はストリームの代替えバージョンを与える（例えば、代替えビットレートを与える）ことも含み得る。メディアデータは、生成後に直ちに送信できるので、ほぼリアルタイムで受け取ることができる。マルチメディアデータのストリームのサーバー（送信者）及びクライアント（受信者）によってとられるべきアクション及びファイルの規範的なデータフォーマットが与えられるが、他のフォーマットをサポートすることもできる。

シミュレーションされたリアルタイムストリーム（又はほぼリアルタイムのストリーム）として送信できるメディア提示は、プレイリストファイルを指示するユニバーサルリソースインジケータ（ＵＲＩ）により特定される。一実施形態において、プレイリストファイルは、付加的なＵＲＩの順序付けされたリストである。プレイリストファイルにおける各ＵＲＩは、特定番組に対するメディアデータの単一隣接ストリームであるストリームのセグメントであるメディアファイルを指す。

メディアデータのストリームを再生するため、クライアント装置は、サーバーからプレイリストファイルを得る。又、クライアントは、プレイリストファイルにより指示された各メディアデータファイルを得て再生する。一実施形態において、クライアントは、付加的な及び／又は異なるメディアセグメントを発見するためにプレイリストファイルを動的に又は繰り返し再ロードすることができる。

プレイリストファイルは、例えば、拡張Ｍ３Ｕプレイリストファイルでよい。一実施形態において、Ｍ３Ｕフォーマットを効果的に拡張する付加的なタグが使用される。Ｍ３Ｕは、ムービングピクチャーエクスパーツグループオーディオレイヤ３ユニフォームリソースロケーター（ＭＰ３ ＵＲＬ）を指すもので、マルチメディアプレイリストを記憶するのに使用されるフォーマットである。Ｍ３Ｕファイルは、メディアプレーヤが再生するための１つ以上のメディアファイルの位置を含むテキストファイルである。

プレイリストファイルは、一実施形態では、個々のラインより成る拡張型Ｍ３Ｕフォーマットテキストファイルである。それらのラインは、単一のＬＦキャラクタにより終了するか、又はＣＲキャラクタ及びそれに続くＬＦキャラクタにより終了することができる。各ラインは、ＵＲＩ、ブランクライン、又はコメントキャラクタ（例えば、‘＃’）でのスタートである。ＵＲＩは、再生されるべきメディアファイルを識別する。ブランクラインは、無視することができる。

コメントキャラクタでスタートするラインは、コメント又はタグである。タグは、＃ＥＸＴで開始し、一方、コメントラインは、＃で開始することができる。コメントラインは、通常、サーバー及びクライアントにより無視することができる。一実施形態において、プレイリストファイルは、ＵＴＦ−８フォーマットでエンコードされる。ＵＴＦ−８（８ビットのユニコードトランスフォーメーションフォーマット）は、可変長さのキャラクタエンコーディングフォーマットである。別の実施形態では、他のキャラクタエンコーディングフォーマットを使用することができる。

以下の例では、２つのタグ、ＥＸＴＭ３Ｕ及びＥＸＴＩＮＦを含む拡張型Ｍ３Ｕフォーマットが使用される。拡張型Ｍ３Ｕファイルは、“＃ＥＸＴＭ３Ｕ”を含む第１のラインにより基本的Ｍ３Ｕファイルから区別される。

ＥＸＴＩＮＦは、タグに続くＵＲＩにより識別されるメディアファイルを示すレコードマーカーである。一実施形態において、各メディアファイルの前には、ＥＸＴＩＮＦタグ、例えば、
＃ＥＸＴＩＮＦ：＜duration＞、＜title＞
があり、“duration”は、メディアファイルの期間を特定し、そして“title”は、ターゲットメディアファイルのタイトルである。

一実施形態において、次のタグは、メディアファイルの転送及び再生を管理するのに使用される。
ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
ＥＸＴ−Ｘ−ＫＥＹ
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ

これらのタグは、各々、以下で詳細に述べる。各新たなタグについて特定のフォーマット及び属性を説明するが、異なる属性、ネーム、フォーマット、等を伴う別の実施形態をサポートすることもできる。

ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグは、提示に追加される次のメディアファイルのおおよその期間を指示することができる。これは、再生ファイルに含まれ、そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：＜seconds＞
但し、“seconds”は、メディアファイルの期間を指示する。一実施形態において、実際の期間は、タグによって指示されるターゲット期間とは若干相違することがある。一実施形態において、セグメントを指示する各ＵＲＩは、セグメントのおおよその期間に関連付けられ、例えば、セグメントのＵＲＩの前に、そのセグメントのおおよその期間を指示するタグが付けられる。

プレイリストファイルにおける各メディアファイルＵＲＩは、独特のシーケンス番号をもつことができる。ＵＲＩのシーケンス番号は、もしそれが存在する場合は、一実施形態では、それに先行するＵＲＩのシーケンス番号＋１に等しくなる。ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグは、プレイリストファイルに現れる第１のＵＲＩのシーケンス番号を指示することができ、そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：＜number＞
但し、“number”は、ＵＲＩのシーケンス番号である。プレイリストファイルが＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合には、プレイリスト内の第１のＵＲＩのシーケンス番号が１であると考えられる。一実施形態において、シーケンス番号は、非順次でよく、例えば、１、５、７、１７、等の非順次のシーケンス番号は、シーケンスにおける次の番号の予想を困難にし、これは、コンテンツを海賊版作成から保護する上で助けとなる。コンテンツを保護する上で助けとなる別のオプションは、所与の時間にプレイリストの一部分だけを露呈することである。

あるメディアファイルは、暗号化することができる。ＥＸＴ−Ｘ−ＫＥＹタグは、それに続くメディアファイルを解読するために使用できる情報を与え、そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＫＥＹ：ＭＥＴＨＯＤ＝＜method＞［，ＵＲＩ＝“＜ＵＲＩ＞”］
ＭＥＴＨＯＤパラメータは、暗号化方法を特定し、そしてＵＲＩパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。

ＮＯＮＥの暗号化方法は、暗号化しないことを指示する。種々の暗号化方法を使用することができ、例えば、ＡＥＳ−１２８は、１２８ビットキー及びＰＫＣＳ７パッディング（ＲＦＣ３８５２を参照）を伴う「アドバンスエンクリプションスタンダード」暗号化を使用する暗号化を指示する。新規なＥＸＴ−Ｘ−ＫＥＹタグは、従来のＥＸＴ−Ｘ−ＫＥＹタグに取って代わるものである。

ＵＲＩパラメータを伴うＥＸＴ−Ｘ−ＫＥＹタグは、キーファイルを識別する。このキーファイルは、プレイリストファイルに載せられた後続メディアファイルを解読するのに使用される暗号キーを含む。例えば、ＡＥＳ−１２８暗号化方法は、１６オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおける１６オクテットのパックアレイである。

ＡＥＳ−１２８の使用は、通常、暗号化及び解読時に同じ１６オクテットの初期化ベクトル（ＩＶ）を供給することを要求する。ＩＶの変更を使用して、暗号化の強度を高めることができる。ＡＥＳ−１２８暗号化を使用するときに、メディアファイルのシーケンス番号は、メディアファイルの暗号化又は解読時にＩＶとして使用することができる。

ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグは、次のメディアファイルの開始を絶対的日付及び／又は時刻に関連付けできるもので、時間ゾーンを含むか又は指示することができる。一実施形態において、日付／時刻表現は、ＩＳＯ／ＩＥＣ８６０１：２００４である。タグのフォーマットは、次の通りである。
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ：＜YYY-MM-DDThh:mm:ssZ＞

ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグは、クライアントがダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶できるかどうか指示するのに使用することができる。タグのフォーマットは、次の通りである。
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ：＜ＹＥＳ｜ＮＯ＞

ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグは、一実施形態では、それ以上のメディアファイルをプレイリストファイルに追加しないことを指示する。タグのフォーマットは、次の通りである。
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
一実施形態において、プレイリストが最終的セグメント又はメディアファイルを含む場合には、プレイリストがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグをもつことになる。

ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、プレイリストファイルにおける次のＵＲＩが別のプレイリストファイルを識別することを指示するのに使用できる。タグのフォーマットは、一実施形態では、次の通りである。
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：[attribute=value］[,attribute=value]＊
＜ＵＲＩ＞
ここで、次の属性が使用される。属性ＢＡＮＤＷＩＤＴＨ＝＜ｎ＞は、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。属性ＰＲＯＧＲＡＭ−ＩＤ＝＜ｉ＞は、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。プレイリストファイルは、同じ提示の変形ストリームを記述するために同じＰＲＯＧＲＡＭ−ＩＤを伴う複数のＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ ＵＲＩを含む。この開示では、変形ストリーム及び変形プレイリストについて更に説明する（例えば、図９Ａ−９Ｄを参照）。

以上のタグ及び属性は、オリジナルメディアコンテンツを表すメディアファイルを編成し、送信しそして処理するために、サーバー装置により使用することができる。クライアント装置は、この情報を使用して、リアルタイム又はほぼリアルタイムのストリーミング経験（例えば、音楽又はスポーツ行事のような生放送を見ること）をクライアント装置のユーザに与えるようにメディアファイルを再アッセンブルし、提示する。

プレイリストファイルにおける各メディアファイルＵＲＩは、オリジナル提示（即ち、オリジナルメディアコンテンツ）のセグメントであるメディアを識別する。一実施形態において、各メディアファイルは、ＭＰＥＧ−２トランスポートストリーム、ＭＰＥＧ−２番組ストリーム、又はＭＰＥＧ−２オーディオ基本的ストリームとしてフォーマットされる。このフォーマットは、ＣＯＤＥＣを特定することにより特定することができ、そしてプレイリストは、ＣＯＤＥＣを特定することによりフォーマットを特定することができる。一実施形態では、提示における全てのメディアファイルが同じフォーマットを有するが、他の実施形態では、複数のフォーマットをサポートできる。トランスポートストリームファイルは、一実施形態では、単一のＭＰＥＧ−２番組を含まねばならず、各ファイルの開始に番組アソシエーションテーブル及び番組マップテーブルがなければならない。ビデオを含むファイルは、少なくとも１つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない。クライアントは、合理的なサブセットを選択することにより特定形式（例えば、オーディオ又はビデオ）の複数のトラックを取り扱うように準備しなければならない。クライアントは、一実施形態では、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない。メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したものでなければならない。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない。

図２Ａは、１つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。図２Ａの例は、ＨＴＴＰに関して与えられるが、他の非ストリーミングプロトコルを同様に使用することもできる。図２Ａの例は、単一のサーバーが幾つかのタスクを遂行することに関して与えられる。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でもよい。

サーバー装置は、オペレーション２００において、与えられるべきコンテンツを受け取る。コンテンツは、生のオーディオ及び／又はビデオ（例えば、スポーツ行事、生のニュース、ウェブカメラのフィード）を表す。又、コンテンツは、予め記録されたコンテンツ（例えば、記録されたコンサート、トレーニングセミナー、等）を表してもよい。コンテンツは、ストリーム型であるかどうかに関わらず、この技術で知られたフォーマット及びプロトコルに基づいてサーバーにより受け取られる。一実施形態では、コンテンツは、ＭＰＥＧ−２ストリームの形態でサーバーにより受け取られるが、他のフォーマットをサポートすることもできる。

次いで、サーバーは、オペレーション２１０において、コンテンツの少なくとも一部分を一時的に記憶する。コンテンツ又はコンテンツの少なくとも一部分は、例えば、記憶装置（例えば、記憶エリアネットワークのハードディスク、等）又はメモリに一時的に記憶される。或いは又、コンテンツは、記憶メディア（例えば、コンパクトディスク、フラッシュドライブ）を経て受け取られ、そこから記憶装置又はメモリへコンテンツを転送してもよい。一実施形態では、サーバーは、必要に応じてコンテンツを１つ以上のストリーム（例えば、ＭＰＥＧ−２）へ変換するエンコーダを有する。この変換は、受け取ったコンテンツを永久的に記憶せずに行うことができ、ある実施形態では、記憶オペレーション２１０を省略してもよいし、又は他の実施形態では、それが長期間記憶（例えば、アーカイブ記憶）であってもよい。

与えられるべきコンテンツは、オペレーション２２０において、複数のメディアファイルへとセグメント化される。一実施形態では、サーバーは、ストリームを、別々の個別のメディアファイル（即ち、セグメント）へと変換し、これらファイルは、標準ウェブサーバーを使用して配布することができる。一実施形態では、サーバーは、個々のメディアファイルの有効なデコードをサポートするポイントにおいて（例えば、ＰＥＳパケット境界及びｉ−フレーム境界のようなパケット及びキーフレーム境界において）メディアストリームをセグメント化する。メディアファイルは、ほぼ等しい期間を伴うオリジナルストリームの一部分である。又、サーバーは、メディアファイルごとにＵＲＩを生成する。これらのＵＲＩは、クライアント装置がメディアファイルにアクセスできるようにする。

セグメントは、本来的に全ファイルを配信するＨＴＴＰサーバーを使用してサービスされるので、サーバーは、クライアントにサービスできるまでに完全なセグメント化メディアファイルが得られねばならない。従って、クライアントは、少なくとも１つのメディアファイル長さだけ放送が（時間的に）遅れることがある。一実施形態において、メディアファイルサイズは、時間の遅れとファイル数が多過ぎることとのバランスに基づいたものになる。

一実施形態では、２つのセッション形式（生のセッション及びイベントセッション）がサポートされる。生のセッションでは、ストリームの固定サイズ部分だけが保存される。一実施形態では、時代遅れのコンテンツメディアファイルが番組プレイリストファイルから除去され、そしてサーバーからも除去される。第２の形式のセッションは、クライアントが放送の任意のポイントへ同調できる（例えば、初めからスタートするか、中間点からスタートする）イベントセッションである。この形式のセッションは、例えば、再放送に使用することができる。

オペレーション２３０では、メディアファイルがサーバーメモリに記憶される。メディアファイルは、オペレーション２３０において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。メディアファイルは、サーバー装置においてウェブサーバーアプリケーションによりサポートされる（又は送信を行う別の装置によりサポートされる）ネットワークプロトコル（例えば、ＨＴＴＰ又はＨＴＴＰＳ）を使用して送信の準備ができたファイルとして記憶される。

オペレーション２４０において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように１つ以上のプレイリストファイルが発生される。プレイリストファイルは、拡張型Ｍ３Ｕタグ及びここに述べるタグを使用して、クライアント装置がメディアファイルにアクセスしてそれを再アッセンブルし、クライアント装置にストリーミング経験を与えるための情報を発生できるようにする。各メディアファイルのＵＲＩは、メディアファイルを再生すべき順序でプレイリストファイルに含まれる。又、サーバーは、クライアント装置がプレイリストファイルにアクセスできるようにプレイリストファイルの１つ以上のＵＲＩを生成することもできる。

オペレーション２５０において、プレイリストファイルをサーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図２Ａにおいて、特定の順序で提示されるが、異なる順序を使用してもよい。例えば、プレイリストファイルは、メディアファイルが生成され又は記憶される前に生成されてもよい。別の例として、プレイリストファイル及びメディアファイルは、そのいずれかが記憶される前に生成される。

メディアファイルを暗号化すべき場合には、プレイリストファイルは、許可されたクライアント装置がメディアファイル解読のための暗号キーを含むキーファイルを得ることができるようにするＵＲＩを定義することができる。暗号キーは、セキュアな接続（例えば、ＨＴＴＰＳ）を使用して送信することができる。別の例として、プレイリストファイルは、ＨＴＴＰＳを使用して送信することができる。更に別の例として、メディアファイルは、クライアントがプレイリストファイルなしにストリームを再生成できないように予想不能な順序で配列することができる。

暗号化方法がＡＥＳ−１２８である場合には、例えば、ＡＥＳ−１２８ ＣＢＣ暗号化が個々のメディアファイルに適用される。一実施形態において、ファイル全体が暗号化される。一実施形態では、暗号ブロックチェーンが、通常、メディアファイルにわたって適用されない。メディアファイルのシーケンスが、上述したように、ＩＶとして使用される。一実施形態では、サーバーは、キーＵＲＩを伴うＥＸＴ−Ｘ−ＫＥＹタグをプレイリストファイルの終わりに追加する。次いで、サーバーは、暗号構成に変更がなされるまで、全ての後続メディアファイルをそのキーで暗号化する。

新たな暗号キーへスイッチするために、サーバーは、提示に使用された全ての以前のキーＵＲＩとは個別の新たなＵＲＩを経て新たなキーを利用できるようにする。又、サーバーは、プレイリストファイルの終わりに新たなキーＵＲＩを伴うＥＸＴ−Ｘ−ＫＥＹタグも追加し、そしてその新たなキーで全ての後続メディアファイルを暗号化する。

暗号化を終了するために、サーバーは、プレイリストファイルの終わりに暗号化方法ＮＯＮＥを伴うＥＸＴ−Ｘ−ＫＥＹタグを追加することができる。このタグ（“ＮＯＮＥ”を方法として伴う）は、一実施形態では、ＵＲＩパラメータを含まない。全ての後続メディアファイルは、上述したように暗号構成に変更がなされるまで、暗号化されない。サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルに対するＵＲＩを含む場合には、ＥＸＴ−Ｘ−ＫＥＹタグをプレイリストファイルから除去しない。サーバーは、図３Ａを参照して詳細に述べるように、オペレーション２７０において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。

一実施形態において、サーバーは、プレイリストファイルについての要求をクライアント装置から受け取るのに応答してクライアント装置へプレイリストファイルを送信する。クライアント装置は、クライアント装置に与えられたＵＲＩを使用してプレイリストファイルにアクセスし／それを要求することができる。ＵＲＩは、サーバーにおけるプレイリストファイルの位置を指示する。それに応答して、サーバーは、プレイリストファイルをクライアント装置へ与えることができる。クライアント装置は、プレイリストファイルにおけるタグ及びＵＲＩ（又は他の識別子）を使用して、複数のメディアファイルにアクセスすることができる。

一実施形態において、サーバーは、メディアファイルの利用性を、プレイリストファイルに最新に追加されたものに限定することができる。これを行うために、各プレイリストファイルは、１つのＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグしか含むことができず、そしてメディアファイルＵＲＩがプレイリストファイルから除去されるたびに値を１だけインクリメントすることができる。メディアファイルＵＲＩは、それらが追加された順序でプレイリストファイルから除去することができる。一実施形態において、サーバーがプレイリストファイルからメディアファイルＵＲＩを除去するときに、メディアファイルは、メディアファイルの期間と、メディアファイルが現れた最も長いプレイリストファイルの期間との和に等しい期間中、クライアントに利用可能なままとなる。

プレイリストファイルの期間は、そのプレイリストファイル内のメディアファイルの期間の和である。又、他の期間を使用することもできる。一実施形態において、サーバーは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない限り、少なくとも３つの主提示のメディアファイルを常にプレイリストに維持することができる。

図２Ｂは、１つ以上のサーバー装置が１つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。プレイリストは、ここに述べる累積モード又はローリングモードのいずれかを使用して更新することができる。図２Ｂの例は、ＨＴＴＰに関して示すが、他の非ストリーミングプロトコル（例えば、ＨＴＴＰＳ、等）も、同様に使用することができる。図２Ｂの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。

サーバー装置は、オペレーション２０５において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション２１５において、コンテンツの少なくとも一部分を一時的に記憶する。オペレーション２１５は、図２Ａのオペレーション２１０と同様である。与えられるべきコンテンツは、オペレーション２２５において、複数のメディアファイルへとセグメント化される。メディアファイルは、オペレーション２３５においてサーバーメモリに記憶することができる。メディアファイルは、オペレーション２３５において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。

オペレーション２４５において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように１つ以上のプレイリストファイルが発生される。プレイリストファイルは、オペレーション２５５において、サーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図２Ｂでは特定の順序で表されるが、異なる順序が使用されてもよい。

サーバー（又は別のサーバー）は、図３Ａ−３Ｂを参照して詳細に述べるように、オペレーション２７５において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。

プレイリストファイルは、種々の理由で、サーバーによって更新される。サーバーは、オペレーション２８５において、クライアント装置に与えられるべき付加的なデータを受け取ることができる。付加的なデータは、オペレーション２５５においてプレイリストファイルが記憶された後に受け取ることができる。付加的なデータは、例えば、生の提示の付加的な部分、又は既存の提示の付加的な部分である。付加的なデータは、広告又は統計情報（例えば、スポーツ行事に関するスコア又はデータ）を含む。又、付加的なデータは、提示上に（半透明体を通して）オーバーレイすることもできるし、又はサイドバーユーザインターフェイスに提示することもできる。付加的なデータは、最初に受け取られたデータと同様に、セグメント化することができる。付加的なデータが、広告を構成するか、又はプレイリストにより表された番組に挿入されるべき他のコンテンツを構成する場合には、付加的なデータは、オペレーション２１５において（少なくとも一時的に）記憶することができ、オペレーション２２５においてセグメント化することができ、そしてオペレーション２３５において記憶することができ、又、セグメント化された付加的なデータを記憶する前に、付加的なデータのセグメントを暗号化することができる。次いで、オペレーション２４５において、番組及び付加的なデータを含む更新されたプレイリストが発生される。そのプレイリストは、オペレーション２５５において、付加的なデータに基づいて更新されて、再び記憶される。プレイリストファイルに対する変更は、クライアント装置の観点から原子的に行わねばならない。更新されたプレイリストは、一実施形態では、以前のプレイリストに置き換わる。以下に詳細に述べるように、クライアント装置は、プレイリストを何回も要求することができる。これらの要求は、クライアント装置が最新のプレイリストを利用できるようにする。一実施形態では、付加的なデータがメタデータであり、この場合、プレイリストは、更新する必要がないが、セグメントは、メタデータを含むように更新することができる。例えば、メタデータは、セグメントのタイムスタンプと一致させることのできるタイムスタンプを含み、そしてメタデータは、一致するタイムスタンプを有するセグメントに追加することができる。

又、更新されたプレイリストは、メディアファイルの除去を生じてもよい。一実施形態では、サーバーは、プレイリストから、メディアファイルに対し、ＵＲＩを、それらがプレイリストに追加された順序で除去しなければならない。一実施形態では、サーバーは、全提示を除去する場合に、プレイリストファイルをクライアント装置に利用できなくする。一実施形態では、サーバーは、メディアファイル及びプレイリストファイルを、除去されるべきメディアファイルを含む最長のプレイリストファイルの期間中維持して、現在のクライアント装置が提示へのアクセスを終了できるようにする。従って、プレイリストファイルにおける各メディアファイルＵＲＩの前には、プレイリストファイルにより指示されるメディアファイルのおおよその累積的期間を指示するためにＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを設けることができる。別の実施形態では、メディアファイル及びプレイリストファイルは、直ちに除去されてもよい。

クライアント装置からのプレイリストに対するその後の要求の結果、オペレーション２７５において、サーバーが更新されたプレイリストを与える。一実施形態では、プレイリストは、規則的に更新され、例えば、ターゲット期間に関連した時間周期で更新される。プレイリストファイルの周期的な更新は、サーバーが、動的に変化する提示へのアクセスを与えることができるようにする。

図２Ｃは、１つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートであり、これは、代替えストリームを使用する１つの形態である。図２Ｃの例は、ＨＴＴＰに関して示すが、他の非ストリーミングプロトコルを同様に使用することもできる。図２Ｃの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。

一実施形態では、サーバーは、複数のプレイリストファイルを提供するか、又は単一のプレイリストファイルに複数のメディアファイルリストを伴う単一のプレイリストファイルを提供して、同じ提示の異なるエンコーディングを与えることができる。異なるエンコーディングが与えられる場合には、プレイリストファイルは、異なるビットレートを与える各変形ストリームを含み、クライアント装置がエンコーディング間を動的にスイッチできるようにする（図９Ａ−９Ｄを参照して更に説明する）。変形ストリームを有するプレイリストファイルは、変形ストリームごとにＥＸＴ−Ｘ−ＳＴＲＥＡＮ−ＩＮＦタグを含むことができる。同じ提示に対する各ＥＸＴ−Ｘ−ＳＴＲＥＡＮ−ＩＮＦタグは、同じＰＲＯＧＲＡＭ−ＩＤ属性値をもつことができる。各提示のＰＲＯＧＲＡＭ−ＩＤ値は、変形ストリーム内で独特である。

一実施形態では、サーバーは、変形ストリームを発生するときに次の制約を満足する。各変形ストリームは、主提示の一部分ではない任意のコンテンツを含む同じコンテンツで構成することができる。サーバーは、ストリームの最小ターゲット期間の精度内で全ての変形ストリームに対して同じコンテンツ周期を利用できるようにする。変形ストリームのメディアファイルは、一実施形態では、全ての変形ストリームにおける対応コンテンツに対して一致するサンプルタイムスタンプを伴うＭＰＥＧ−２トランスポートストリーム、又はＭＰＥＧ−２番組ストリームのいずれかである。又、一実施形態では、全ての変形ストリームは、同じオーディオエンコーディングを含む。これは、クライアント装置がコンテンツを失うことなく変形ストリーム間でスイッチできるようにする。

図２Ｃを参照すれば、サーバー装置は、オペレーション２０２において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション２１２において、コンテンツを少なくとも一時的に記憶する。与えられるべきコンテンツは、オペレーション２２２において、複数のメディアファイルへとセグメント化される。各メディアファイルは、オペレーション２３２において、選択されたビットレート（又は他のエンコーディングパラメータの選択された値）についてエンコードされ、そしてサーバーに記憶される。例えば、メディアファイルは、高、中間及び低帯域巾接続についてターゲットが決められる。メディアファイルは、記憶の前に暗号化することができる。種々の形式の接続についてターゲットが決められたメディアファイルのエンコーディングは、ターゲット帯域巾レベルにおいてストリーミング経験を与えるように選択される。

一実施形態では、オペレーション２４２において、種々のエンコーディングレベルを指示するここに述べるタグを伴う変形プレイリストが発生される。タグは、例えば、対応するメディアプレイリストファイルに対するＵＲＩを伴うエンコーディングレベルごとのＥＸＴ−Ｘ−ＳＴＲＥＡＮ−ＩＮＦタグである。

この変形プレイリストは、種々のエンコーディングレベルについてメディアプレイリストファイルに対するＵＲＩを含むことができる。従って、クライアント装置は、エンコーディングレベルを指示する変形プレイリストに与えられた代替え物からターゲットビットレートを選択し、そしてそれに対応するプレイリストファイルを検索することができる。一実施形態では、クライアント装置は、再生中にビットレート間を切り換えることができる（図９Ａ−９Ｄを参照して述べるように）。種々のエンコーディングレベルを指示する変形プレイリストは、オペレーション２５２において、サーバーに記憶される。オペレーション２４２では、変形プレイリストにおいて参照されるプレイリストの各々を発生し、オペレーション２５２においてそれを記憶することができる。

クライアント装置からの要求に応答して、サーバーは、オペレーション２７２において、種々のエンコーディングレベルを指示する変形プレイリストを送信することができる。サーバーは、オペレーション２８２において、選択されたビットレートに対応する変形プレイリストにおいて特定されたメディアプレイリストの１つに対する要求を受け取る。この要求に応答して、サーバーは、オペレーション２９２において、クライアント装置からの要求に対応するメディアプレイリストファイルを送信する。次いで、クライアント装置は、メディアプレイリストを使用して、サーバーからのメディアファイルを要求する。サーバーは、オペレーション２９７において、それらの要求に応答してクライアント装置へメディアファイルを与える。

図３Ａは、クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図３Ａの例は、ＨＴＴＰに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。図３Ａ−３Ｂに示す方法は、１つのクライアント装置又は複数の別々のクライアント装置により遂行することができる。例えば、これら方法のいずれか１つの場合に、単一のクライアント装置が、全てのオペレーション（例えば、プレイリストファイルを要求し、プレイリストファイルのＵＲＩを使用してメディアファイルを要求し、提示／出力の発生及び供給のためにメディアファイルをアッセンブルする）を遂行するか、或いは複数の個別のクライアント装置が、全部ではなく幾つかのオペレーションを遂行する（例えば、第１のクライアント装置が、プレイリストファイルを要求し、そのプレイリストファイルのＵＲＩを使用してメディアファイルを要求し、そしてそれらのメディアファイルを第２のクライアント装置により使用するために記憶し、第２のクライアント装置は、メディアファイルを処理して、提示／出力を発生及び供給することができる）。

クライアント装置は、オペレーション３００において、サーバーからプレイリストファイルを要求する。一実施形態では、この要求は、ＨＴＴＰ適合のプロトコルに基づいて行われる。この要求は、サーバーに記憶された初期プレイリストファイルに対するＵＲＩを使用する。別の実施形態では、他の非ストリーミングプロトコルをサポートすることもできる。この要求に応答して、サーバーは、それに対応するプレイリストファイルを、ネットワークを経てクライアントへ送信する。上述したように、ネットワークは、ワイヤード又はワイヤレスであり、又、ワイヤード又はワイヤレスネットワークの組み合わせでもよい。更に、ネットワークは、データネットワーク（例えば、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６）でもよいし、セルラー電話ネットワーク（例えば、３Ｇ）でもよい。

クライアント装置は、オペレーション３１０において、プレイリストファイルを受け取ることができる。プレイリストファイルは、オペレーション３２０において、クライアント装置のメモリに記憶することができる。メモリは、例えば、ハードディスク、フラッシュメモリ、ランダムアクセスメモリである。一実施形態では、プレイリストファイルがプレイリストＵＲＩからロード又は再ロードされるたびに、クライアントは、プレイリストファイルが＃ＥＸＴＭ３Ｕタグで始まり、そしてタグが存在しない場合には継続しないことを決定するためのチェックを行う。上述したように、プレイリストファイルは、１つ以上のタグと、メディアファイルに対する１つ以上のＵＲＩとを含む。

クライアント装置は、オペレーション３３０において、プレイリストファイルのＵＲＩにより指示されたメディアファイルを要求することによりプレイリストファイルを使用してオリジナルコンテンツを再アッセンブルするアッセンブラーエージェントを含むことができる。一実施形態では、このアッセンブラーエージェントは、標準ウェブブラウザアプリケーションの一部分であるプラグインモジュールである。別の実施形態では、アッセンブラーエージェントは、ウェブブラウザと対話し、プレイリストファイルを使用してメディアファイルを受け取りアッセンブルするスタンドアローンアプリケーションでもよい。更に別の例として、アッセンブラーエージェントは、クライアント装置に埋め込まれる特殊目的のハードウェア又はファームウェアコンポーネントでもよい。

このアッセンブラーは、プレイリストファイルからのメディアファイルを、ＵＲＩにより指示されたサーバーからダウンロードさせる。プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含む場合には、プレイリストファイルにより指示されたメディアファイルが最初に再生される。ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない場合には、最後と最後から２番目のメディアファイルを除くメディアファイルが最初に再生される。再生すべき最初のメディアファイルが選択されると、プレイリストファイルにおける後続メディアファイルは、一実施形態では、それらがプレイリストファイルに現れる順序でロードされる（さもなければ、コンテンツは、無秩序に提示される）。一実施形態では、クライアント装置は、中断のない再生を与えると共にネットワークの待ち時間及びスループットの時間的変化を補償するために、メディアファイルが要求される以前にそれらをロードする（そしてそれらをバッファに記憶する）ように試みる。

ダウンロードされたメディアファイルは、オペレーション３４０において、クライアント装置のメモリに記憶することができる。コンテンツを記憶することのできるメモリは、クライアント装置における任意の形式のメモリであり、例えば、ランダムアクセスメモリ、ハードディスク又はビデオバッファである。記憶は、再生を許すために一時的でもよいし、又は永久的でもよい。プレイリストファイルがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含み、その値がＮＯである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後は、記憶しない。プレイリストがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含み、その値がＹＥＳである場合には、クライアントは、メディアファイルを、後で再生するために不定に記憶する。クライアント装置は、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値を使用して、番組起点時間をユーザに表示する。一実施形態では、クライアントは、複数のメディアファイルをバッファして、ネットワークジッタの影響を受け難くし、良好なユーザ経験を与えることができるようにする。

一実施形態において、解読方法がＡＥＳ−１２８である場合に、ＡＥＳ−１２８ ＣＢＣ解読が個々のメディアファイルに適用される。ファイル全体が解読される。一実施形態では、メディアファイルにわたって暗号ブロックチェーンが適用されない。メディアファイルのシーケンス番号は、上述したように初期化ベクトルとして使用することができる。

メモリからのコンテンツは、オペレーション３５０において、クライアント装置から出力することができる。出力又は提示は、例えば、内蔵スピーカ又はヘッドホンを経て出力されるオーディオである。出力は、スクリーンを経て出力されるか又はクライアント装置から投影されるビデオを含む。この技術で知られた任意の形式の出力を使用することができる。オペレーション３５１において、クライアント装置は、記憶された現在プレイリストに再生も提示もされていないメディアファイルがもっとあるかどうか決定する。そのようなメディアファイルが存在する（且つそれらが要求されていない）場合には、１つ以上のメディアファイルが要求されるオペレーション３３０へ処理が復帰し、プロセスが繰り返される。このようなメディアファイルがない（即ち、現在プレイリストにおける全てのメディアファイルが再生されている）場合には、処理がオペレーション３５２へ進み、これは、プレイリストファイルが終了タグを含むかどうか決定する。

オペレーション３５２において、プレイリストが終了タグ（例えば、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ）を含む場合には、プレイリストファイルにより指示されたメディアファイルが再生されたときに再生が終わる。終了タグがプレイリストにない場合には、クライアント装置は、サーバーからプレイリストを再び要求し、そしてオペレーション３００へ復帰して、番組のための更に別の又は更新されたプレイリストを得る。

図２Ｂを参照して詳細に説明したように、サーバーは、補足的コンテンツ（例えば、生放送における付加的なメディアコンテンツに対応する付加的なメディアファイル識別子）又は付加的なコンテンツ（例えば、ストリームの更に下流のコンテンツ）を導入するためにプレイリストファイルを更新する。この補足的コンテンツ又は付加的なコンテンツにアクセスするために、クライアントは、更新されたプレイリストをサーバーから再ロードすることができる。これは、プレイリストファイルに関連したメディアコンテンツの再生中でも、プレイリストファイルを動的に更新できるメカニズムを与える。クライアントは、多数のトリガーに基づいてプレイリストファイルの再ロードを要求する。終了タグの欠如は、１つのこのようなトリガーである。

一実施形態では、クライアント装置は、プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない限り、プレイリストファイルを周期的に再ロードする。クライアント装置が、プレイリストファイルを初めてロードするとき、又はプレイリストファイルを再ロードしそしてそれが前回ロードされて以来変化したことが分かったときには、クライアントは、再びプレイリストファイルを再ロードするよう試みる前に、ある時間周期待機することができる。この周期は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのロードを開始する時間から測定される。

一実施形態では、初期最小再ロード遅延は、プレイリストファイルにおける最後のメディアファイルの期間、又はターゲット期間の３倍の、どちらか小さい方である。メディアファイルの期間は、ＥＸＴＩＮＦタグにより特定される。クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある時間周期待機することができる。一実施形態における最小遅延は、ターゲット期間の３倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。一実施形態では、この倍数は、第１の試みでは０．５であり、第２の試みでは１．５であり、そしてその後の試みでは３．０であるが、他の倍数が使用されてもよい。

プレイリストファイルがロード又は再ロードされるたびに、クライアント装置は、プレイリストファイルを検査して、ロードすべき次のメディアファイルを決定する。ロードすべき第１のファイルは、上述したように、最初に再生するように選択されたメディアファイルである。再生されるべき第１のメディアファイルがロードされ、そしてプレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのＵＲＩを、最初に見つけたオフセットに含むことを検証することができ、ファイルが見つからない場合には再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたＵＲＩに続く第１のメディアファイルＵＲＩである。

再生されるべき第１のファイルがロードされ、そしてプレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものである。プレイリストファイルが、キーファイルＵＲＩを特定するＥＸＴ−Ｘ−ＫＥＹタグを含む場合には、クライアント装置は、キーファイルを得、そしてキーファイル内のキーを使用して、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまで、そのＥＸＴ−Ｘ−ＫＥＹタグに続くメディアファイルを解読する。

一実施形態では、クライアント装置は、以前に使用した同じＵＲＩを使用して、プレイリストファイルをダウンロードする。従って、プレイリストファイルに変更がなされた場合には、クライアント装置は、更新されたプレイリストファイルを使用して、メディアファイルを検索し、そしてそのメディアファイルに基づいて出力を与える。

プレイリストファイルの変更は、例えば、メディアファイルに対するＵＲＩの削除、新たなメディアファイルに対するＵＲＩの追加、置き換えメディアファイルに対するＵＲＩの置き換えを含む。プレイリストファイルに変更がなされるときには、その変更を反映するように１つ以上のタグが更新される。例えば、メディアファイルの変更で、プレイリストファイルによって指示されるメディアファイルの再生の期間に変更が生じる場合には、期間タグが更新される。

図３Ｂは、クライアント装置が、代替えストリームの一形態である複数のビットレートを使用するコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図３Ｂの例は、ＨＴＴＰに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。

オペレーション３７０において、クライアント装置は、プレイリストファイルを要求することができる。上述したように、プレイリストファイルは、クライアント装置に与えられるＵＲＩを使用して検索される。一実施形態では、プレイリストファイルは、同じコンテンツを異なるビットレートで与えるためにメディアファイルの変形ストリームのリストを含み、換言すれば、単一のプレイリストファイルは、各変形ストリームのメディアファイルに対するＵＲＩを含む。図３Ｂに示す例は、この実施形態を使用する。別の実施形態では、変形ストリームは、クライアントに別々に与えられる複数の個別のプレイリストファイルにより、その各々が同じコンテンツを異なるビットレートで与えるように表され、そして変形プレイリストは、個別のプレイリストファイルの各々に対してＵＲＩを与えることができる。これは、クライアント装置がクライアントの条件に基づいてビットレートを選択できるようにする。

オペレーション３７５において、プレイリストファイルは、クライアント装置によって検索することができる。オペレーション３８０において、プレイリストファイルは、クライアント装置のメモリに記憶することができる。クライアント装置は、オペレーション３８５において、使用すべきビットレートを、現在ネットワークの接続速度に基づいて選択する。メディアファイルは、オペレーション３９０において、選択されたビットレートに対応するプレイリストファイルに含まれたＵＲＩを使用してサーバーから要求される。検索されたメディアファイルは、クライアント装置のメモリに記憶することができる。出力は、オペレーション３９４において、メディアファイルを使用してクライアント装置により与えられ、そしてクライアント装置は、ビットレートを変更すべきかどうか決定する。

一実施形態において、クライアント装置は、最初に利用可能な最低ビットレートを選択する。メディアを再生する間に、クライアント装置は、利用可能な帯域巾（例えば、現在ネットワークの接続ビットレート）を監視して、その利用可能な帯域巾が再生のためにより高いビットレートの使用をサポートできるかどうか決定することができる。もしそうであれば、クライアント装置は、より高いビットレートを選択し、そしてより高いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。その逆をサポートすることもできる。再生が著しい帯域巾を消費する場合には、クライアント装置は、より低いビットレートを選択し、そしてより低いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。

クライアント装置が、オペレーション３９４において、例えば、利用可能な帯域巾の変更に応答し又はユーザ入力に応答して、ビットレートを変更する場合には、クライアント装置は、オペレーション３８５において、異なるビットレートを選択することができる。一実施形態では、異なるビットレートを選択するために、クライアント装置は、新たに選択されたビットレートに対応するプレイリストファイルに含まれたＵＲＩの異なるリストを利用することができる。一実施形態では、クライアント装置は、プレイリスト内のメディアファイルのアクセス中にビットレートを変更することができる。

オペレーション３９４においてビットレートが変更されない場合に、クライアント装置は、検索及び提示されていない未再生のメディアファイルが現在プレイリストにもっとあるかどうか決定する。そのようなメディアファイルが存在する場合には、処理がオペレーション３９０へ復帰し、そしてプレイリストにおけるそれらのファイルに対するＵＲＩを使用して１つ以上のメディアファイルが検索される。そのようなメディアファイルがない（即ち、現在プレイリストにおける全てのメディアファイルが再生された）場合には、処理がオペレーション３９６へ進み、プレイリストが終了タグを含むかどうか決定される。もしそうであれば、番組の再生が終了で、プロセスが完了であるが、もしそうでなければ、処理がオペレーション３７０へ復帰し、クライアント装置は、番組に対するプレイリストを再ロードすることを要求し、図３Ｂに示す方法を通してプロセスが繰り返される。

図４は、サーバーストリームエージェントの一実施形態のブロック図である。サーバーストリームエージェント４００の要素は、多数のサーバー装置にわたって分散できることを理解されたい。例えば、第１のサーバー装置は、セグメンタ４３０、インデクサ４４０及びセキュリティ４５０を含むが、ファイルサーバー４６０は含まず、又、第２のサーバー装置は、ファイルサーバー４５０を含むが、セグメンタ４３０、インデクサ４４０及びセキュリティ４５０は含まない。この例では、第１のサーバー装置は、プレイリスト及びメディアファイルを準備するが、それらをクライアント装置へ送信せず、一方、１つ以上の第２のサーバー装置は、プレイリスト及びメディアファイルを受け取って任意に記憶し、そしてプレイリスト及びメディアファイルをクライアント装置へ送信する。サーバーストリームエージェント４００は、サーバーストリームエージェント４００のオペレーションを指令する論理機能制御を具現化する制御ロジック４１０と、サーバーストリームエージェント４００のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路、又はソフトウェアルーチン、又はファームウェアである。一実施形態では、サーバーストリームエージェント４００は、制御ロジック４１０にインストラクションを与えるコードシーケンス及び／又はプログラムを表す１つ以上のアプリケーション４１２を備えている。

サーバーストリームエージェント４００は、データ又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ４１４を備えている。このメモリ４１４は、サーバーストリームエージェント４００に対してローカルのメモリを含んでもよいし、或いは又サーバーストリームエージェント４００が存在するホストシステムのメモリを含んでもよい。又、サーバーストリームエージェント４００は、サーバーストリームエージェント４００の外部のエンティティ（電子装置又は人間）に関してサーバーストリームエージェント４００への／からのアクセスインターフェイス（入力／出力インターフェイス）を表す１つ以上のインターフェイス４１６も備えている。

又、サーバーストリームエージェント４００は、サーバーストリームエージェント４００がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする１つ以上の機能を表すサーバーストリームエンジン４２０も備えている。図４の例は、サーバーストリームエンジン４２０に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、セグメンタ４３０、インデクサ４４０、セキュリティ４５０、及びファイルサーバー４６０を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。

セグメンタ４３０は、与えられるべきコンテンツを、ウェブサーバープロトコル（例えば、ＨＴＴＰ）を使用してファイルとして送信できるメディアファイルへと分割する。例えば、セグメンタ４３０は、コンテンツを、所定のファイルフォーマットにおける所定の固定サイズのデータブロックへと分割する。

インデクサ４４０は、セグメンタ４３０によって生成されるメディアファイルに対するＵＲＩ又はアドレスを与える１つ以上のプレイリストファイルを発生する。インデクサ４４０は、例えば、セグメンタ４３０により生成される各ファイルに対応する識別子のための順序のリストを伴う１つ以上のファイルを生成する。それら識別子は、セグメンタ４３０又はインデクサ４４０によって生成され又は指定される。又、インデクサ４４０は、メディアファイルのアクセス及び／又は利用をサポートするためにプレイリストファイルに１つ以上のタグを含むこともできる。

セキュリティ４５０は、上述したようなセキュリティ特徴（例えば、暗号化）を与えることができる。ウェブサーバー４６０は、ホストシステムに記憶されたファイルをリモートクライアント装置に与えることに関連したウェブサーバー機能を発揮する。ウェブサーバー４６０は、例えば、ＨＴＴＰ適合のプロトコルをサポートする。

図５は、クライアントストリームエージェントの一実施形態のブロック図である。クライアントストリームエージェントの要素は、多数のクライアント装置にわたって分散できることを理解されたい。例えば、第１のクライアント装置は、アッセンブラー５３０及びセキュリティ５５０を備え、そしてメディアファイルの解読されたストリームを第２のクライアント装置へ供給することができ、この第２のクライアント装置は、出力ジェネレータ５４０を含む（が、アッセンブラー５３０及びセキュリティ５５０は含まない）。別の例では、一次クライアント装置がプレイリストを検索してそれを二次クライアント装置へ供給することができ、この二次クライアント装置は、プレイリストにおいて特定されたメディアファイルを検索して、それらメディアファイルを提示するための出力を発生する。クライアントストリームエージェント５００は、このクライアントストリームエージェント５００のオペレーションを指令するための論理機能的制御を具現化する制御ロジック５１０と、このクライアントストリームエージェント５００のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路或いはソフトウェアルーチン又はファームウェアでよい。一実施形態では、クライアントストリームエージェント５００は、制御ロジック５１０にインストラクションを与えるコードシーケンス又はプログラムを表す１つ以上のアプリケーション５１２を備えている。

クライアントストリームエージェント５００は、データ及び／又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ５１４を備えている。このメモリ５１４は、クライアントストリームエージェント５００に対してローカルのメモリを含んでもよいし、或いは又クライアントストリームエージェント５００が存在するホストシステムのメモリを含んでもよい。又、クライアントストリームエージェント５００は、クライアントストリームエージェント５００の外部のエンティティ（電子装置又は人間）に関してクライアントストリームエージェント５００への／からのアクセスインターフェイス（入力／出力インターフェイス）を表す１つ以上のインターフェイス５１６も備えている。

又、クライアントストリームエージェント５００は、このクライアントストリームエージェント５００がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする１つ以上の機能を表すクライアントストリームエンジン５２０も備えている。図５の例は、クライアントストリームエンジン５２０に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、アッセンブラー５３０、出力ジェネレータ５４０、及びセキュリティ５５０を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。

アッセンブラー５３０は、サーバーから受け取られたプレイリストファイルを使用して、サーバーからウェブサーバープロトコル（例えば、ＨＴＴＰ）を経てメディアファイルにアクセスすることができる。一実施形態では、アッセンブラー５３０は、プレイリストファイルにおいてＵＲＩにより指示されたメディアファイルをダウンロードさせる。アッセンブラー５３０は、プレイリストファイルに含まれたタグに応答する。

出力ジェネレータ５４０は、受け取ったメディアファイルをホストシステムにおいてオーディオ又はビジュアル出力（又はオーディオ及びビジュアルの両方）として発生する。出力ジェネレータ５４０は、例えば、オーディオを１つ以上のスピーカへ出力させそしてビデオをディスプレイ装置へ出力させる。セキュリティ５５０は、上述したようなセキュリティ特徴を与える。

図６は、複数のタグを伴うプレイリストファイルの一実施形態を示す図である。図６の規範的なプレイリストは、特定数及び順序のタグを含む。これは、説明上のものに過ぎない。あるプレイリストファイルは、より多くの又はより少ない、或いは異なる組み合わせのタグを含み、そしてタグは、図６に示すものとは異なる順序で配列することができる。

開始タグ６１０は、プレイリストファイルの開始を指示することができる。一実施形態において、開始タグ６１０は、＃ＥＸＴＭ３Ｕタグである。期間タグ６２０は、再生リストの期間を指示することができる。即ち、再生リスト６００により指示されるメディアファイルの再生の期間である。一実施形態において、期間タグ６２０は、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグであるが、他のタグも使用できる。

日付／時刻タグ６２５は、再生リスト６００により指示されたメディアファイルにより与えられるコンテンツの日付及び時刻に関連した情報を与えることができる。一実施形態では、日付／時刻タグ６２５は、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＴタグであるが、他のタグを使用することもできる。シーケンスタグ６３０は、プレイリストのシーケンスにおけるプレイリストファイル６００のシーケンスを指示することができる。一実施形態では、シーケンスタグ６３０は、ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグであるが、他のタグも使用できる。

セキュリティタグ６４０は、プレイリストファイル６００により指示されたメディアファイルに適用されるセキュリティ及び／又は暗号化に関連した情報を与えることができる。例えば、セキュリティタグ６４０は、メディアファイルインジケータにより特定されたファイルを解読するための解読キーを特定することができる。一実施形態では、セキュリティタグ６４０は、ＥＸＴ−Ｘ−ＫＥＹタグであるが、他のタグを使用することもできる。変形リストタグ６４５は、変形ストリームがプレイリスト６００により与えられるかどうか指示すると共に、変形ストリームに関する情報（例えば、どれほど多く、ビットレート）を指示することができる。一実施形態では、変形リストタグ６４５は、ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグである。

メディアファイルインジケータ６５０は、再生されるべきメディアファイルに関する情報を与えることができる。一実施形態では、メディアファイルインジケータ６５０は、再生されるべき複数のメディアファイルに対するＵＲＩを含む。又、一実施形態では、プレイリスト６００におけるＵＲＩの順序は、メディアファイルにアクセスし及び／又は再生しなければならない順序に対応する。その後のプレイリストインジケータ６６０は、再生ファイル６００の後に使用されるべき１つ以上の再生ファイルに関連した情報を与えることができる。一実施形態では、その後のプレイリストインジケータ６６０は、プレイリスト６００のメディアファイルが再生された後に使用されるべき１つ以上のプレイリストファイルに対するＵＲＩを含むことができる。

メモリタグ６７０は、メディアファイルコンテンツの再生後にクライアント装置がメディアファイルを記憶できるかどうか及び／又はどれほど長く記憶できるか指示することができる。一実施形態では、メモリタグ６７０は、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグである。終了タグ６８０は、プレイリストファイル６００が提示のための最後のプレイリストファイルであるかどうか指示する。一実施形態では、終了タグ６８０は、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグである。

次の章は、一実施形態による幾つかの規範的なプレイリストファイルを含む。
簡単なプレイリストファイル

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT-X-ENDLIST



HTTPSを使用するスライディングウインドウプレイリスト

#EXTM3U
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,
https://priv.example.com/fileSequence2680.ts
#EXTINF:8,
https://priv.example.com/fileSequence2681.ts
#EXTINF:8,
https://priv.example.com/fileSequence2682.ts



暗号化されたメディアファイルを伴うプレイリストファイル

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:7794
#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI="
https://priv.example.com/key.php?r=52"
#EXTINF:15,
http://media.example.com/fileSequence7794.ts
#EXTINF:15,
http://media.example.com/fileSequence7795.ts
#EXTINF:15,
http://media.example.com/fileSequence7796.ts
#EXT-X-KEY:METHOD=AES-128,URI="
https://priv.example.com/key.php?r=53"
#EXTINF:15,
http://media.example.com/fileSequence7797.ts



変形プレイリストファイル

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
http://example.com/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example.com/mid.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example.com/hi.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"
http://example.com/audio-only.m3u8

図７は、ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。一実施形態において、受け取られたメディアファイルの再生は、スタート、ストップ、巻き戻し、等のためにユーザにより制御することができる。プレイリストファイルは、オペレーション７００において、クライアント装置により受け取られる。オペレーション７１０において、プレイリストファイルにより指示されたメディアファイルが検索される。オペレーション７２０において、受け取られたメディアファイルに基づいて出力が発生される。メディアファイルの受け取り及びそのメディアファイルに基づく出力の発生は、上述したように行うことができる。

オペレーション７３０において制御入力が検出された場合には、クライアント装置は、オペレーション７４０において入力がストップを指示するかどうか決定することができる。入力がストップである場合には、プロセスが終了となり、再生がストップする。オペレーション７５０において入力が巻き戻し又は送り要求を指示する場合には、クライアント装置は、オペレーション７６０において、メモリにまだ記憶されている以前に再生されたメディアファイルに基づいて出力を発生することができる。これらファイルがキャッシュにもはやない場合には、処理がオペレーション７１０へ復帰し、メディアファイルを検索してプロセスを繰り返す。別の実施形態では、再生は、ストップ入力のような再生の終了を伴わずに再生をハルトする休止特徴をサポートすることができる。

あるストリームから別のストリームへ遷移させる方法を、図９Ａ−９Ｄを参照して詳細に説明する。１つのクライアント装置でこれらの方法の各々を遂行することもできるし、又はこれら方法各々のオペレーションを、ここに述べる複数のクライアント装置にわたって分散させることもでき、例えば、分散させる場合には、１つのクライアント装置が変形プレイリスト及び２つのメディアプレイリストを検索しそしてそれらを別のクライアント装置に与えることができ、その別のクライアント装置が、２つのメディアプレイリストで特定されたメディアファイルを検索し、そしてその検索されたメディアファイルにより与えられる２つのストリーム間をスイッチすることができる。又、別の実施形態では、図示されたオペレーションの順序を変更してもよいし、又はこれらの図面に示されたものより多くの又は少ないオペレーションが遂行されてもよいことも理解されよう。これらの方法は、変形プレイリストを使用して、異なるストリームを選択することができる。オペレーション９０１において変形プレイリストを検索し処理して、番組（例えば、スポーツ行事）のための利用可能なストリームを決定することができる。オペレーション９１０は、クライアント装置によって行うことができる。第１のストリームは、オペレーション９０３において変形プレイリストから選択することができ、次いで、クライアント装置は、第１のストリームのためのメディアプレイリストを検索することができる。クライアント装置は、オペレーション９０５において、第１のストリームに対するメディアプレイリストを処理し、そしてオペレーション９０７において、第１のストリームに対するネットワーク接続のビットレートを測定し、さもなければ、決定することができる。オペレーションのシーケンスは、図９Ａに示されたものとは異なる順序で遂行されてもよく、例えば、オペレーション９０７は、オペレーション９０３の間に遂行されてもよく、等々であることが明らかであろう。オペレーション９１１において、クライアント装置は、オペレーション９０７からの測定されたビットレートに基づき変形プレイリストから代替えメディアプレイリストを選択し、この代替えメディアプレイリストは、第１のストリームの既存のビットレートより高い第２のビットレートでよい。これは、典型的に、代替えストリームが、第１のストリームより高い解像度を有することを意味する。代替えメディアプレイリストは、現在条件（例えば、オペレーション９０７で測定されたビットレート）に基づき第１のストリームに対する現在プレイリストより良好に一致する場合に選択することができる。オペレーション９１３において、代替えストリームに対する代替えメディアプレイリストが検索され処理される。これは、典型的に、クライアント装置が第１のストリーム及び代替えストリームの両方を受け取って処理し、従って、その両方を提示に利用でき、即ち一方を提示している間に、他方が処理の準備ができることを意味する。次いで、クライアント装置は、オペレーション９１５においてストリームのバージョン間をスイッチングする遷移ポイントを選択し、第１のストリームの提示を停止すると共に、代替えストリームの提示を開始する。このスイッチングをどのように遂行するかの例を、図９Ｂ−９Ｄを参照して示す。ある実施形態では、クライアント装置は、スイッチングを行う前に第１のストリームの受け取りを停止することができる。

図９Ｂは、クライアント装置が、オペレーション９２１及び９２３において第１のメディアプレイリスト（例えば、第１のストリーム）により特定されたコンテンツを検索し、記憶し及び提示し、そして第１のプレイリストにより特定されたコンテンツが提示される間に、オペレーション９２５において、クライアント装置が、第２のメディアプレイリスト（例えば、第２のストリーム）により特定されたコンテンツを検索し及び記憶することを示している。第１のメディアプレイリストから得たコンテンツを提示している間に第２のメディアプレイリストにより特定されたコンテンツを検索し（例えば、一時的バッファに）記憶することで、番組コンテンツの時間的なオーバーラップ９５５（図９Ｄに示す）を生成し、これは、クライアント装置が、番組を実質的に中断せずに番組のバージョン間をスイッチングできるようにする。このように、番組のバージョン間のスイッチングは、多くの場合に、スイッチングが生じることをユーザに通知せずに（ある場合には、スイッチングの後の高解像度の画像にユーザが気付くことがあるが）、又は番組提示の実質的な中断なしに、行うことができる。オペレーション９２７において、クライアント装置は、第１のメディアプレイリストにより特定されたコンテンツから第２のメディアプレイリストにより特定されたコンテンツへスイッチングすべき遷移点を決定し、遷移点の一例（遷移点９５９）が図９Ｄに示されている。第２のメディアプレイリストにより特定されたコンテンツは、スイッチングの後に、オペレーション９３１において提示される。

図９Ｃ及び９Ｄに示す方法は、遷移点を決定するための一実施形態を表し、この実施形態は、遷移点を決定するために２つのストリーム９５１及び９５３からのオーディオサンプルに対するパターンマッチングに依存する。代替え実施形態は、ビデオサンプルに対するパターンマッチングを使用するか、又は２つのストリームのタイムスタンプ等を使用して、遷移点を決定できることが明らかであろう。この方法は、オペレーション９４１において、第１のメディアプレイリストにより特定されたコンテンツ（例えば、ストリーム９５１）をバッファに記憶することを含み、このバッファは、コンテンツの提示及びパターンマッチングオペレーションに使用することができる。ストリーム９５１は、オーディオサンプル９５１Ａ及びビデオサンプル９５１Ｂの両方を含む。ビデオサンプルは、単一のビデオフレームを表示するのに必要な全てのコンテンツを有するｉフレーム又はキーフレームに依存する圧縮技術を使用することができる。ストリーム９５１のコンテンツは、時間（例えば、番組の開始から経過した時間）を特定するタイムスタンプを含み、これらタイムスタンプは、各サンプルの開始（例えば、各オーディオサンプル９５１Ａの開始及び各ビデオサンプル９５１Ｂの開始をマークすることができる。あるケースでは、２つのストリーム間のタイムスタンプの比較は、遷移点を決定する上で有用ではない。というのは、それらが充分正確でないか、又は２つのストリームにおけるサンプルの境界に差があるためである。しかしながら、２つのストリーム間の時間的なオーバーラップ９５５があることを検証するために、タイムスタンプ範囲の比較を使用することができる。オペレーション９４３において、クライアント装置は、第２のメディアプレイリストにより特定されたコンテンツをバッファに記憶し、このコンテンツは、第１のメディアプレイリストから得られたコンテンツと同じ番組に対するものであり、これもタイムスタンプを含むことができる。一実施形態において、タイムスタンプは、ストリームに存在しない場合には、ストリームのためのプレイリストに追加することができ、例えば、一実施形態では、１つ以上のタイムスタンプを含むＩＤ３タグを、変形プレイリスト又はメディアプレイリストのようなプレイリストのエントリに追加することができる。このエントリは、例えば、オーディオストリームの第１サンプルに対するＵＲＩである。図９Ｄは、第２のメディアプレイリストから得られたコンテンツ９５３の一例を示し、これは、オーディオサンプル９５３Ａ及びビデオサンプル９５３Ｂを含む。オペレーション９４５において、クライアント装置は、２つのストリーム９５１及び９５３のオーディオサンプルに対してパターンマッチングを遂行して、オーバーラップ９５５から遷移点９５９を選択することができ、これは、一実施形態では、一致したオーディオセグメント（例えば、セグメント９５７）の後の次の自蔵型ビデオフレーム（例えば、ｉフレーム９６１）である。ｉフレーム９６１（及びそれに関連したオーディオサンプル）で始めて、番組の提示は、第２のメディアプレイリストから得られた第２のストリームを使用する。前記方法は、一実施形態では、低速ビットレートから高速ビットレートへの変化、及び高速ビットレートから低速ビットレートへの変化の両方に使用することができるが、別の実施形態では、この方法は、低速ビットレートから高速ビットレートへの変化にしか使用できず、高速ビットレートから低速ビットレートへの変化には別の方法（例えば、遷移点を位置付けるよう試みず、低速ビットレートストリームからできるだけ即座にコンテンツを記憶し提示するよう試みる）を使用することができる。

図１０は、代替えストリームを使用してクライアント装置へプレイリスト又はメディアコンテンツ或いはその両方を与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。プレイリストが上述した代替えストリームを含む場合に、その代替えストリームは、帯域巾又は装置の代替え物として動作するだけでなく、故障フォールバックとして動作することもできる。例えば、クライアントが（例えば、４０４エラー又はネットワーク接続エラーのために）ストリームに対するプレイリストファイルを再ロードできない場合には、クライアントは、代替えストリームへスイッチするよう試みることができる。図１０を参照すれば、フェイルオーバー保護を具現化するために、第１のサーバー装置又は第１のコンテンツ配布サービスは、図２Ｃを参照して述べたように、オペレーション１００２において、ストリーム又は複数の代替え帯域巾ストリームを生成するように構成される。オペレーション１００４において、第１のサーバー装置又は第１のコンテンツ配布サービスは、オペレーション１００２において発生されたストリームからプレイリストファイルを発生する。第１のサーバー装置又は第２のコンテンツ配布サービスは、オペレーション１００６において、並列ストリーム又はストリームのセットを生成すると共に、プレイリストも生成する。これらの並列ストリームは、バックアップストリームと考えることができる。次いで、バックアップストリームのリストがオペレーション１００８においてプレイリストファイルに追加され、一次ストリームの後に、各帯域巾のバックアップストリームがリストされるようにする。例えば、一次ストリームがサーバーＡＬＰＨＡから到来しそしてバックアップストリームがサーバーＢＥＴＡにある場合には、プレイリストファイルが次のようになる。
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://ALPHA.mycompany.com/low/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://BETA.mycompany.com/low/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://ALPHA.mycompany.com/mid/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://BETA.mycompany.com/mid/prog_index.m3u8

バックアップストリームは、各帯域巾のバックアップがその帯域巾に対する一次の後にリストされたプレイリストにおける一次ストリームと混合されることに注意されたい。クライアントは、単一のバックアップストリームセットに限定されない。上述した例において、ＡＬＰＨＡ及びＢＥＴＡの後に、例えば、ＧＡＭＭＡが続く。同様に、ストリームの完全な並列セットを与える必要はない。例えば、単一の低帯域巾ストリームがバックアップサーバーに与えられる。

オペレーション１０１０において、クライアントは、第１のサーバー装置又は第１のコンテンツ配布サービスに関連した第１のストリームを使用して第１のＵＲＬからプレイリストファイルをダウンロードするように試みる。図１１は、一実施形態により、クライアント１１０２が、１つ以上のＵＲＬ、サーバー装置又はコンテンツ配布サービスと両方向に通信するネットワークを示す。プレイリストファイルは、オペレーション１０１２において、第１のＵＲＬ、サーバー装置又はコンテンツ配布サービスからクライアント１１０２へ送信される。クライアントが、第１のＵＲＬ、サーバー装置又はコンテンツ配布サービスからプレイリストファイルをダウンロードできない（例えば、ストリームのインデックスファイルを再ロードするエラーのために）場合には、クライアントは、代替えストリームへスイッチするよう試みる。１つのストリームに欠陥（例えば、インデックスロード欠陥）がある場合には（例えば、オペレーション１０１０）、クライアントは、オペレーション１０１４においてネットワーク接続がサポートする最も高い帯域巾の代替えストリームを選択する。同じ帯域巾の複数の代替え物がある場合には、クライアントは、プレイリストに載せられた順序でそれらを選択する。例えば、クライアント１１０２がＵＲＬ １から首尾よくダウンロードできない場合には、ＵＲＬ ２又は別のＵＲＬからダウンロードしてもよく、この場合、プレイリストファイルは、代替えＵＲＬからクライアントへ送信される。この特徴は、サーバーのクラッシュやコンテンツ配布ノードの故障のような厳しいローカル欠陥の場合でも、メディアがクライアントに到達できるようにする冗長なストリームを与える。

フェイルオーバー保護は、クライアントがプレイリスト及びメディアファイルを検索できるところの複数の冗長な位置を与える能力を備えている。従って、クライアントが第１の位置からストリームを検索できない場合には、第２、第３、等の位置からストリームにアクセスするよう試みることができる。

一実施形態において、クライアントがプレイリストを検索できるところの付加的な位置を指示するため、同じ変形プレイリストタグに、同じ帯域巾であるが新たなＵＲＩの冗長位置が与えられる。クライアントは、最初に、望ましい帯域巾に関連した第１のＵＲＬにアクセスするよう試みることができる。第１のＵＲＬからプレイリストをダウンロードできない場合には、帯域巾に対して提示される次のＵＲＬにアクセスするよう試み、等々、全ての可能性が尽きるまで行う。

以下の例は、２５６００００帯域巾に対する１冗長位置、及び７６８００００帯域巾に対する２冗長位置を含む。
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
http://example.com/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example.com/mid.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example1.com/mid-redundant2.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example.com/hi.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example2.com/hi-redudant2.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example3.com/hi-redudant3.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"
http://example.com/audio-only.m3u8

この例において、ファイルネーム（例えば、mid-redundant2.m3u8）及び実際のＵＲＬ（例えば、http://example2.com <http://example2.com/> ,http://example3.com <http://example3.com/>）の両方が変化することに注意されたい。しかしながら、一実施形態では、冗長位置は、ファイルネームに対してのみ又はウェブサイトに対してのみ変化する。

一実施形態において、プレイリストは、サーバー装置によって圧縮されて、圧縮形態でクライアント装置へ送られる。圧縮されたプレイリストは、通常、プレイリストを表現するのに非圧縮のプレイリストより少数のビットしか必要とせず、従って、圧縮されたプレイリストは、送信又は受信されるときに、ワイヤレスセルラー電話ネットワークのようなネットワークの利用可能な帯域巾をあまり使用しない。一実施形態では、プレイリストは、ＨＴＴＰ１．１規格プロトコルのような転送プロトコルに適合又は適合するウェブサーバーによって使用される内蔵圧縮技術又はファシリティに基づいてウェブサーバーにより圧縮することができ、このような圧縮技術又はファシリティの一例は、ＨＴＴＰ１．１のデフレート又はｇｚｉｐ圧縮ファシリティである。他の実施形態では、規格ベースの転送プロトコルの一部分である他の規格ベースの圧縮ファシリティを使用することができる。圧縮されたプレイリストの使用は、一実施形態では、サーバー装置及びクライアント装置の任意の特徴である。一実施形態では、プレイリストは、テクスチャーコンテンツ（例えば、テキストファイル）であり、規格ベースのウェブサーバーによりデフレート又はｇｚｉｐで効率的に圧縮され、次いで、クライアント装置により自動的に解凍される。ｇｚｉｐ圧縮ファシリティのバージョンの説明は、www.ietf.org/rfc/rfc1952.txtに見ることができ、デフレート圧縮ファシリティのバージョンは、www.ietf.org/rfc/rfc1951.txtに見ることができる。多数のウェブサーバー、及びクライアント装置の多数のウェブブラウザは、デフレート又はｇｚｉｐファシリティを自動的にサポートすることができる。

一実施形態において、クライアント装置は、更新されたプレイリストを周期的に要求することができ、例えば、クライアント装置は、サーバーから、更新されたプレイリストを数秒ごとに（例えば、１０、２０又は３０秒ごとに、或いは他の時間周期で）要求することができる。クライアントが生のゲーム中の任意の時点で生のゲームを始めから見始めるのを許す生の進行中の野球ゲームのプレイリストのような成長するプレイリストは、その成長するプレイリストがネットワークを通して繰り返し送信されるので、圧縮の使用でネットワークの帯域巾の消費を制限できるに充分な大きさとなる。

一実施形態において、クライアント装置は、いつプレイリスト（更新されたプレイリストのような）を要求するか、どんな圧縮技術（デフレート又はｇｚｉｐのような）をサポートできるか、任意に特定することができ、これら技術をサポートすることは、クライアント装置が、圧縮又はエンコードされたコンテンツを解読又はデコードできることを意味する。圧縮技術を任意に特定したクライアント装置のプレイリスト要求は、一実施形態において、プレイリストに対する圧縮技術をサポートすることが要求されずに非圧縮のプレイリストを送信できるウェブサーバーによって受け取られる。ウェブサーバーは、クライアント装置の要求に応答して、非圧縮のプレイリスト、又はプレイリストに対するクライアント装置の要求で特定された圧縮技術の１つを使用して圧縮されたプレイリストをクライアント装置へ送信することができる。クライアント装置は、プレイリストを受け取り、そしてそれをここに述べるように使用し、即ちプレイリストが圧縮された場合には、クライアント装置のウェブブラウザにおけるデコーダのようなクライアント装置のデコーダを使用してそれがデコードされる。

図８は、電子システムの一実施形態のブロック図である。図８に示す電子システムは、例えば、デスクトップコンピュータシステム、ラップトップコンピュータシステム、セルラー電話、セルラーイネーブルＰＤＡを含むパーソナルデジタルアシスタント（ＰＤＡ）、セットトップボックス、娯楽システム、又は他の消費者向け電子装置を含むある範囲の電子システム（ワイヤード又はワイヤレス）を表すことが意図される。代替え電子システムは、より多くの、より少ない及び／又は異なるコンポーネントを含んでもよい。図８の電子システムは、クライアント装置及び／又はサーバー装置を構成するように使用されてもよい。

電子システム８００は、情報を通信するためのバス８０５又は他の通信装置と、情報を処理するためにバス８０５に結合されたプロセッサ８１０とを備えている。電子システム８００は、単一のプロセッサをもつように示されているが、電子システム８００は、複数のプロセッサ及び／又はコプロセッサを含んでもよい。電子システム８００は、更に、バス８０５に結合されたランダムアクセスメモリ（ＲＡＭ）又は他のダイナミック記憶装置８２０（メインメモリと称される）を備え、これは、プロセッサ８１０により実行されるインストラクション及び情報を記憶する。又、このメインメモリ８２０は、プロセッサ８１０によるインストラクションの実行中に変数又は他の中間情報を一時的に記憶するように使用されてもよい。

電子システム８００は、バス８０５に結合されたリードオンリメモリ（ＲＯＭ）及び／又は他のスタティック記憶装置８３０も備え、これは、プロセッサ８１０のためのスタティック情報及びインストラクションを記憶する。データ記憶装置８４０は、情報及びインストラクションを記憶するためにバス８０５に結合される。フラッシュメモリ又は磁気ディスク又は光学ディスク及びそれに対応するドライブのようなデータ記憶装置８４０が、電子システム８００に結合される。

又、電子システム８００は、バス８０５を経て、陰極線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）のようなディスプレイ装置８５０に結合され、ユーザに情報を表示する。又、電子システム８００は、アルファニューメリック及び他のキーを含むアルファニューメリック入力装置８６０も備え、これは、情報及びコマンド選択をプロセッサ８１０へ通信するためにバス８０５に結合される。別の形式のユーザ入力装置は、方向情報及びコマンド選択をプロセッサ８１０へ通信すると共に、ディスプレイ８５０上のカーソル移動を制御するための、タッチパッド、マウス、トラックボール又はカーソル方向キーのようなカーソルコントロール８７０である。

更に、電子システム８００は、ローカルエリアネットワークのようなネットワークにアクセスを与えるために１つ以上のネットワークインターフェイス８８０を備えている。このネットワークインターフェイス８８０は、例えば、１つ以上のアンテナを表すアンテナ８８５を有するワイヤレスネットワークインターフェイスを含む。又、電子システム８００は、ＷｉＦｉ、ブルーツース、及びセルラー電話インターフェイスの組み合わせのような複数のワイヤレスネットワークインターフェイスを含むことができる。又、ネットワークインターフェイス８８０は、例えば、イーサネットケーブル、同軸ケーブル、光ファイバケーブル、シリアルケーブル、又はパラレルケーブルのようなネットワークケーブル８８７を経て、リモート装置と通信するためのワイヤードネットワークインターフェイスも含む。

一実施形態において、ネットワークインターフェイス８８０は、例えば、ＩＥＥＥ８０２．１１ｂ及び／又はＩＥＥＥ８０２．１１ｇ規格に適合することにより、ローカルエリアネットワークへのアクセスを与え、及び／又はワイヤレスネットワークインターフェイスは、例えば、ブルーツース規格に適合することにより、パーソナルアクセスネットワークへのアクセスを与えることができる。他のワイヤレスネットワークインターフェイス及び／又はプロトコルをサポートすることもできる。

ワイヤレスＬＡＮ規格を経ての通信に加えて又はそれに代わって、ネットワークインターフェイス８８０は、例えば、時分割多重アクセス（ＴＤＭＡ）プロトコル、移動通信用のグローバルシステム（ＧＳＭ）プロトコル、コード分割多重アクセス（ＣＤＭＡ）プロトコル、及び／又は他の形式のワイヤレス通信プロトコルを使用して、ワイヤレス通信を行うことができる。

本明細書において「一実施形態」又は「実施形態」とは、その実施形態に関連して述べた特定の特徴、構造又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書の種々の場所に「一実施形態」という句が現れたときには、必ずしも、全てが同じ実施形態を指すのではない。

以上、本発明の特定の実施形態を説明したが、本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、明細書及び添付図面は、本発明を単に例示するものであって、それに限定されるものではない。

アペンディックス
以下のアペンディックスは、本発明の特定の実施形態によるプロトコルのドラフト仕様書である。このアペンディックスにおける幾つかのキーワード（例えば、ＭＵＳＴ、ＭＵＳＴ ＮＯＴ、ＳＨＡＬＬ、ＳＨＡＬＬ ＮＯＴ、等）の使用は、この特定の実施形態に適用されるもので、本開示に述べる他の実施形態には適用されないことが理解されよう。

概略

本書は、ＨＴＴＰを経てマルチメディアデータの無限のストリームを送信するためのプロトコルについて述べる。これは、ファイルのデータフォーマットと、ストリームのサーバー（送信者）及びクライアント（受信者）により行われるアクションとを特定する。このプロトコルのバージョン１．０について述べる。

目次

１．序文
２．概要
３．プレイリストファイル
３．１．新たなタグ
３．１．１．ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
３．１．２．ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
３．１．３．ＸＥＸ−Ｘ−ＫＥＹ
３．１．４．ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
３．１．５．ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
３．１．６．ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
３．１．７．ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
３．１．８．ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
４．メディアファイル
５．キーファイル
５．１．ＡＥＳ−１２８のためのＩＶ
６．クライアント／サーバーアクション
６．１．サーバープロセス
６．１．１．スライディングウインドウプレイリスト
６．１．２．暗号メディアファイル
６．１．３．変形ストリームの付与
６．２．クライアントプロセス
６．２．１．プレイリストファイルのローディング
６．２．２．プレイリストファイルの再生
６．２．３．プレイリストファイルの再ローディング
６．２．４．ロードすべき次のファイルの決定
６．２．５．暗号化されたメディアファイルの再生
７．例
７．１．簡単なプレイリストファイル
７．２．ＨＴＴＰＳを使用するスライディングウインドウプレイリスト
７．３．暗号化されたメディアファイルを伴うプレイリストファイル
７．４．変形プレイリストファイル
８．セキュリティの考え方
９．参照文献
規範的参照文献
情報参照文献

１．序文
本書は、ＨＴＴＰ［ＲＦＣ２６１６］を経てマルチメディアデータの無限ストリームを送信するためのプロトコルについて述べる。このプロトコルは、メディアデータの暗号化と、ストリームの代替えバージョン（例えば、ビットレート）の付与とをサポートする。メディアデータは、それが生成されるや否や送信され、ほぼリアルタイムで受け取ることができるようにする。
ＨＴＴＰのような関連規格について述べる外部の参照文献は、第９章に列挙する。

２．概要
マルチメディアの提示は、付加的なＵＲＩの順序付けされたリストであるプレイリストファイルに対するＵＲＩ［ＲＦＣ３９８６］により特定される。プレイリストファイルの各ＵＲＩは、単一の隣接ストリームのセグメントであるメディアファイルを指す。
ストリームを再生するために、クライアントは、先ず、プレイリストファイルを得、そしてプレイリスト内の各メディアファイルを得て再生する。本書に述べるようにプレイリストファイルを再ロードして、付加的なセグメントを発見する。
本書におけるキーワード“ＭＵＳＴ”“ＭＵＳＴ ＮＯＴ”“ＲＥＱＵＩＲＥＤ”“ＳＨＡＬＬ”“ＳＨＡＬＬ ＮＯＴ”“ＳＨＯＵＬＤ”“ＳＨＯＵＬＤ ＮＯＴ”“ＲＥＣＯＭＭＥＮＤＥＤ”“ＭＡＹ”及び“ＯＰＴＩＯＮＡＬ”は、ＲＦＣ２１１９［ＲＦＣ２１１９］に述べるように解釈されるべきである。

３．プレイリストファイル
プレイリストは、拡張型のＭ３Ｕプレイリストファイル［Ｍ３Ｕ］でなければならない(MUST)。本書は、付加的なタグを定義することによりＭ３Ｕファイルフォーマットを拡張する。
Ｍ３Ｕプレイリストは、個々のラインより成るテキストファイルである。それらラインは、単一のＬＦキャラクタか、又はＣＲキャラクタ及びそれに続くＬＦキャラクタにより終了となる。各ラインは、ＵＲＩ、ブランクであるか、又はコメントキャラクタ‘＃’でスタートする。ＵＲＩは、再生されるべきメディアファイルを識別する。ブランクラインは、無視される。
コメントキャラクタ‘＃’でスタートするラインは、コメント又はタグである。タグは、＃ＥＸＴで始まる。‘＃’で始まる他の全てのラインは、コメントであり、無視しなければならない(SHOULD)。
ネームが.m3u8で終わり及び／又はＨＴＴＰコンテンツタイプ“application/vnd.apple.mpegurl”を有するＭ３Ｕプレイリストファイルは、ＵＴＦ−８［ＲＦＣ３６２９］でエンコードされる。ネームが.m3uで終わり及び／又はＨＴＴＰコンテンツタイプ［ＲＦＣ２６１６］“audio/mpegurl”を有するファイルは、ＵＳ−ＡＳＣＩＩ［ＵＳ＿ＡＳＣＩＩ］でエンコードされる。
具現化は、ネームが.m3u8で終わるか、又はＨＴＴＰを経て送信される場合にコンテンツタイプ“application/vnd.apple.mpegurl”を有するプレイリストファイルを発生しなければならない(SHOULD)。互換性のために、具現化は、ネームが.m3uで終わり及び／又はＨＴＴＰコンテンツタイプ“audio/mpegurl”を有するプレイリストファイルを発生してもよい(MAY)。
拡張型Ｍ３Ｕファイルフォーマットは、２つのタグＥＸＴＭ３Ｕ及びＥＸＴＩＮＦを定義する。拡張型Ｍ３Ｕファイルは、基本的Ｍ３Ｕファイルから、＃ＥＸＴＭ３Ｕでなければならない(MUST)その第１ラインにより区別される。
ＥＸＴＩＮＦは、それに続くＵＲＩにより識別されるメディアファイルを記述するレコードマーカーである。各メディアファイルＵＲＩは、ＥＸＴＩＮＦタグが先行しなければならない(MUST)。そのフォーマットは、次の通りである。
＃ＥＸＴＩＮＦ：＜duration＞、＜title＞
“duration”は、メディアファイルの期間を秒で特定する整数である。この期間は、最も近い整数に丸めねばならない(SHOULD)。カンマに続くラインの残りは、メディアファイルのタイトルである。

３．１．新たなタグ
本書は、７つの新たなタグ、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ、ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ、ＥＸＴ−Ｘ−ＫＥＹ、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ、ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ、及びＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ、を定義する。

３．１．１．ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグは、主提示に追加される次のメディアファイルのおおよその期間を指示する。これは、プレイリストファイルに現れねばならない(MUST)。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：＜seconds＞
メディアファイルの実際の期間は、ターゲット期間から若干異なってもよい(MAY)。

３．１．２．ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
プレイリストにおける各メディアファイルＵＲＩは、独特のシーケンス番号を有する。ＵＲＩのシーケンス番号は、それに先行するＵＲＩのシーケンス番号＋１に等しい。ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグは、プレイリストファイルに現れる第１のＵＲＩのシーケンス番号を指示する。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：＜number＞
プレイリストファイルが＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合には、プレイリスト内の第１のＵＲＩのシーケンス番号が１であると考えねばならない(SHALL)。
ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグの取り扱いに関する情報は、第６．２．１章及び第６．２．４章を参照されたい。

３．１．３．ＥＸＴ−Ｘ−ＫＥＹ
メディアファイルは、暗号化されてもよい(MAY)。ＥＸＴ−Ｘ−ＫＥＹタグは、それに続くメディアファイルを解読するに必要な情報を与える。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＫＥＹ：ＭＥＴＨＯＤ＝＜method＞［，ＵＲＩ＝“＜ＵＲＩ＞”］
ＭＥＴＨＯＤパラメータは、暗号化方法を特定する。ＵＲＩパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。
プロトコルのバージョン１．０は、２つの暗号化方法ＮＯＮＥ及びＡＥＳ−１２８を定義する。ＮＯＮＥの暗号化方法は、メディアファイルが暗号化されないことを意味する。
ＡＥＳ−１２８の暗号化方法は、１２８ビットキー及びＰＫＣＳ７パッディングを伴う進歩型暗号規格［ＡＥＳ＿１２８］［ＲＦＣ３８５２］を使用してメディアファイルが暗号化されることを意味する。
新たなＥＸＴ−Ｘ−ＫＥＹは、従来のＥＸＴ−Ｘ−ＫＥＹに取って代わる。
ＥＸＴ−Ｘ−ＫＥＹタグが存在しない場合には、メディアファイルが暗号化されない。
キーファイルのフォーマットについては、第５章を、そしてメディアファイル暗号化の付加的な情報については、第５．１章、第６．１．２章及び第６．２．５章を参照されたい。

３．１．４．ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグは、次のメディアファイルの開始を絶対的な日付及び／又は時刻に関連付ける。日付／時刻表現は、ＩＳＯ／ＩＥＣ８６０１：２００４［ＩＳＯ＿８６０１］であり、時間ゾーンを指示しなければならない(SHOULD)。例えば、次の通りである。
＃ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ：<YYYY-MM-DDThh:mm:ssZ>

３．１．５．ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグは、クライアントが、ダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶してもよいか(MAY)どうか指示する。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ：＜ＹＥＳ｜ＮＯ＞

３．１．６．ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグは、それ以上のメディアファイルがプレイリストファイルに追加されないことを指示する。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ

３．１．７．ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、プレイリストファイルにおける次のＵＲＩが別のプレイリストファイルを識別することを指示する。そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：[attribute=value］[,attribute=value]＊
＜ＵＲＩ＞
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグについて次の属性が定義される。
ＢＡＮＤＷＩＤＴＨ＝＜ｎ＞
但し、ｎは、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。
ＰＲＯＧＲＡＭ−ＩＤ＝＜ｉ＞
但し、ｉは、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。
プレイリストファイルは、同じ提示の変形ストリームを記述するために同じＰＲＯＧＲＡＭ−ＩＤを伴う複数のＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ ＵＲＩを含んでもよい(MAY)。
ＣＯＤＥＣＳ＝“[format][,format]*”
但し、各フォーマットは、プレイリストファイル内のメディアファイルに存在するメディアサンプル形式を特定する。
有効なフォーマット識別子は、ＲＦＣ４２８１［ＲＦＣ４２８１］により定義されたＩＳＯファイルフォーマットネームスペースにおける識別子である。

３．１．８．ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグは、それに続くメディアファイルが、それに先行するものとは異なる特性を有することを指示する。変更してもよい(MAY)特性のセットは、次の通りである。
○ファイルフォーマット
○トラックの数及び形式
○エンコーディングパラメータ
○エンコーディングシーケンス
○タイムスタンプシーケンス
そのフォーマットは、次の通りである。
＃ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ

４．メディアファイル
プレイリストファイルにおける各メディアファイルＵＲＩは、全体的提示のセグメントであるメディアファイルを識別しなければならない(MUST)。各メディアファイルは、ＭＰＥＧ−２トランスポートストリーム、ＭＰＥＧ−２番組ストリーム、又はＭＰＥＧ−２オーディオ基本的ストリーム［ＩＳＯ＿１３８１８］としてフォーマットされねばならない(MUST)。提示における全てのメディアファイルは、同じフォーマットを有していなければならない(MUST)。
トランスポートストリームファイルは、単一のＭＰＥＧ−２番組を含まねばならない(MUST)。各ファイルのスタートに、番組アソシエーションテーブル及び番組マップテーブルがなければならない(SHOULD)。ビデオを含むファイルは、少なくとも１つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない(SHOULD)。
クライアントは、合理的なサブセットを選択することにより特定形式（例えば、オーディオ又はビデオ）の複数のトラックを取り扱うように準備しなければならない(SHOULD)。クライアントは、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない(MUST)。
メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したままでなければならない(SHOULD)。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない(SHOULD)。

５．キーファイル
ＵＲＩパラメータを伴うＥＸＴ−Ｘ−ＫＥＹタグは、キーファイルを識別する。キーファイルは、プレイリストにおける後続メディアファイルを解読するのに使用しなければならない(MUST)暗号キーを含む。
ＡＥＳ−１２８暗号化方法は、１６オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおけるこれら１６オクテットのパックされたアレイに過ぎない。

５．１．ＡＥＳ−１２８のためのＩＶ
１２８ビットＡＥＳは、暗号及び解読を行うときに同じ１６オクテット初期化ベクトル（ＩＶ）を供給することを要求する。このＩＶを変更すると、暗号化の強度が高くなる。
暗号化ＭＥＴＨＯＤ ＡＥＳ−１２８を使用するときには、具現化は、メディアファイルを暗号化又は解読する際にメディアファイルのシーケンス番号をＩＶとして使用しなければならない(SHALL)。このシーケンス番号のビッグエンディアンバイナリー表現を１６オクテットバッファに配して（左側に）ゼロをパディングしなければならない(SHALL)。

６．クライアント／サーバーアクション
本章は、サーバーがどのようにプレイリスト及びメディアファイルを発生し、及びクライアントがどのようにそれをダウンロードして再生すべきか説明する。

６．１．サーバープロセス
ＭＰＥＧ−２ストリームの発生は、本書の範囲外であり、これは、主提示を含む連続的ストリームのソースを簡単に推定するものである。
サーバーは、ストリームを、その期間がほぼ等しい個々のメディアファイルに分割しなければならない(MUST)。サーバーは、個々のメディアファイルの有効なデコードをサポートするポイント、例えば、パケット及びキーフレーム境界においてストリームを分割するように試みなければならない(SHOULD)。
サーバーは、そのクライアントがファイルを得るのを許すＵＲＩをメディアファイルごとに生成しなければならない(MUST)。
サーバーは、プレイリストファイルを生成しなければならない(MUST)。プレイリストファイルは、第３章で述べたフォーマットに適合しなければならない。サーバーが利用したい各メディアファイルのＵＲＩは、それが再生される順序でプレイリストに現れねばならない(MUST)。ＵＲＩがプレイリストファイルにある場合には全メディアファイルがクライアントに利用できねばならない。
プレイリストファイルは、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグを含まねばならない(MUST)。これは、主提示に追加される次のメディアファイルのおおよその期間を指示しなければならない(MUST)。この値は、全提示に対して一定のままでなければならない(MUST)。典型的なターゲット期間は、１０秒である。
サーバーは、そのクライアントがファイルを得るのを許すＵＲＩをプレイリストファイルに対して生成しなければならない(MUST)。
プレイリストファイルの変更は、クライアントの観点から原子的に行われねばならない(MUST)。
プレイリストにおける各メディアファイルＵＲＩの前には、メディアファイルのおおよその期間を指示するＥＸＴＩＮＦタグがなければならない(MUST)。
サーバーは、ＵＲＩの前にＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグを置くことにより絶対日付及び時刻をメディアファイルに関連付けてもよい(MAY)。日付及び時刻の値は、任意である。
プレイリストが提示の最終的メディアファイルを含む場合には、プレイリストファイルは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まねばならない。
サーバーが全提示を除去したい場合には、プレイリストファイルをクライアントに利用不能にしなければならない(MUST)。これは、プレイリストファイルにおける全メディアファイルが、除去時に、少なくともプレイリストファイルの期間中クライアントに利用できるままとなるよう保証しなければならない(SHOULD)。

６．１．１．スライディングウインドウプレイリスト
サーバーは、メディアファイルの利用を、プレイリストに最新に追加されたものに限定してもよい(MAY)。これを行うために、プレイリストファイルは、常に、厳密に１つのＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まねばならない(MUST)。その値は、メディアファイルＵＲＩがプレイリストファイルから除去されるたびに１だけインクリメントされねばならない(MUST)。
メディアファイルＵＲＩは、それらが追加された順序でプレイリストファイルから除去されねばならない(MUST)。
サーバーがプレイリストからメディアファイルＵＲＩを除去するときに、メディアファイルは、メディアファイルの期間＋メディアファイルが現れた最も長いプレイリストファイルの期間に等しい時間周期中、クライアントに利用可能なままとされる。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。
サーバーがメディアファイルを除去する計画である場合には、ＨＴＴＰ満了ヘッダが、クライアントへの配信時に、計画生存時間を反映するように保証しなければならない(SHOULD)。
サーバーは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない限り、少なくとも３つの主提示メディアファイルをプレイリストに常に維持しなければならない(MUST)。

６．１．２．メディアファイルの暗号化
メディアファイルを暗号化すべき場合には、サーバーは、許可されたクライアントが解読キーを含むキーファイルを得るのを許すＵＲＩを定義しなければならない(MUST)。このキーファイルは、第５章で述べたフォーマットに適合しなければならない。
サーバーは、キーがキャッシュ記憶されたことを指示するためにキー応答に満了ヘッダをセットしてもよい(MAY)。
暗号化ＭＥＴＨＯＤがＡＥＳ−１２８である場合には、ＡＥＳ−１２８ ＣＢＣ暗号を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を暗号化しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第５章に述べたＩＶとして使用しなければならない(MUST)。
サーバーは、プレイリストファイルにおけるＵＲＩの直前のＥＸＴ−Ｘ−ＫＥＹタグにより特定された方法を使用してプレイリストにおける各メディアファイルを暗号化しなければならない(MUST)。ＭＥＴＨＯＤがＮＯＮＥであるＥＸＴ−Ｘ−ＫＥＹタグが先行するか、又はＥＸＴ−Ｘ−ＫＥＹタグが先行しないメディアファイルは、暗号化してはならない(MUST NOT)。
各ＥＸＴ−Ｘ−ＫＥＹタグのＵＲＩは、ＭＥＴＨＯＤがＮＯＮＥでない限り、プレイリストファイルに現れるか又は現れた１つおきのＥＸＴ−Ｘ−ＫＥＹタグのＵＲＩとは異なるものでなければならない。ＭＥＴＨＯＤがＮＯＮＥのＥＸＴ−Ｘ−ＫＥＹタグは、ＵＲＩパラメータを含んではならない。
サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルへのＵＲＩを含む場合には、プレイリストファイルからＥＸＴ−Ｘ−ＫＥＹタグを除去してはならない(MUST NOT)。

６．１．３．変形ストリームの付与
サーバーは、同じ提示の異なるエンコーディングを与えるために複数のプレイリストファイルを提供してもよい(MAY)。もしそうであれば、クライアントがエンコーディング間を動的にスイッチできるように各変形ストリームを列挙した変形プレイリストファイルを付与しなければならない(SHOULD)。
変形プレイリストは、変形ストリームごとにＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含まねばならない(MUST)。同じ提示に対する各ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、同じＰＲＯＧＲＡＭ−ＩＤ属性値を有していなければならない(MUST)。各提示に対するＰＲＯＧＲＡＭ−ＩＤ値は、変形プレイリスト内で独特でなければならない(MUST)。
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグがＣＯＤＥＣＳ属性を含む場合には、属性値は、プレイリストファイルに現れる又は現れるであろうメディアファイルに存在する［ＲＦＣ４２８１］により定義された各フォーマットを含まねばならない(MUST)。
サーバーは、変形ストリームを発生するときには、次の制約を満足しなければならない(MUST)。
各変形ストリームは、主提示の部分ではないコンテンツを含む同じコンテンツで構成されねばならない(MUST)。
サーバーは、ストリームの最小ターゲット期間という精度内で、全ての変形ストリームに対して同じコンテンツ周期が利用できるようにしなければならない(MUST)。
変形ストリームにおける一致するコンテンツは、一致するタイムスタンプを有していなければならない。これは、クライアントがストリームの同期をとれるようにする。
基本的なオーディオストリームファイルは、ＩＤ３ ＰＲＩＶタグ［ＩＤ３］の前に、“com.apple.streaming.transportStreamTimestamp”という所有者識別子を設けることにより、ファイルにおける第１サンプルのタイムスタンプを信号しなければならない(MUST)。バイナリーデータは、ビッグエンディアン８オクテット数として表現された３３ビットのＭＰＥＧ−２番組基本的ストリームタイムスタンプでなければならない(MUST)。
加えて、全ての変形ストリームは、同じエンコードされたオーディオビットストリームを含まねばならない(SHOULD)。これは、クライアントが聴覚欠陥なしにストリーム間をスイッチできるようにする。

６．２．クライアントプロセス
クライアントがプレイリストファイルに対するＵＲＩをどのようにして得るかは、本書の範囲外であり、それを行っているものと仮定する。
クライアントは、ＵＲＩからプレイリストファイルを得なければならない(MUST)。そのようにして得られたプレイリストファイルが変形プレイリストである場合には、クライアントは、変形プレイリストからプレイリストファイルを得なければならない(MUST)。
本書は、クライアントによる変形ストリームの処理を特定するものではない。

６．２．１．プレイリストファイルのローディング
プレイリストファイルがプレイリストＵＲＩからロード又は再ロードされるたびに、
クライアントは、プレイリストファイルが＃ＥＸＴＭ３Ｕで始まることをチェックし、もしそうでない場合には、継続を拒否しなければならない(SHOULD)。クライアントは、それが認識しないタグを無視しなければならない(SHOULD)。
クライアントは、第６．２．４章に述べるように、ロードすべき次のメディアファイルを決定しなければならない(MUST)。
プレイリストがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合には、クライアントは、プレイリストファイルがロードされた時間にプレイリストファイルの期間を加えた時間に、その中の各メディアファイルが利用できるようになると仮定しなければならない(SHOULD)。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。

６．２．２．プレイリストファイルの再生
クライアントは、再生がスタートするときにプレイリストからどのメディアファイルを最初に再生するか選択しなければならない(SHALL)。プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含む場合には、プレイリスト内のどのファイルを最初に再生してもよい(MAY)。ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない場合には、プレイリスト内の最後と最後から２番目のファイルを除くどのファイルを最初に再生してもよい(MAY)。
最初に再生すべきメディアファイルが選択されると、プレイリスト内のその後のメディアファイルは、それらが現れた順序でロードし、そしてそれらがロードされた順序で再生しなければならない(MUST)。
クライアントは、中断のない再生のためにメディアファイルが要求されるであろうときに前もってそれらをロードし、待ち時間及びスループットの一時的な変動を補償するよう試みなければならない(SHOULD)。
プレイリストファイルがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含みそしてその値がＮＯである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後に、キャッシュ記憶してはならない(MUST NOT)。さもなければ、クライアントは、ダウンロードされたメディアファイルを、後で再生するために不定にキャッシュ記憶してもよい(MAY)。
クライアントは、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値を使用して、番組発信時間をユーザに表示してもよい(MAY)。値が時間ゾーン情報を含む場合には、クライアントは、それを考慮しなければならない(SHALL)が、そうでない場合には、クライアントは、発信時間ゾーンを推定してはならない(MUST NOT)。
クライアントは、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値の正しさ又は一貫性に依存してはならない(MUST NOT)。

６．２．３．プレイリストファイルの再ローディング
クライアントは、プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない限り、プレイリストファイルを周期的に再ロードしなければならない(MUST)。
しかしながら、クライアントは、本章で特定された以上に頻繁にプレイリストファイルを再ロードするよう試みてはならない(MUST NOT)。
クライアントがプレイリストファイルを初めてロードするか、又はプレイリストファイルを再ロードして、それが最後にロードされて以来変化したことが分かったときには、クライアントは、プレイリストファイルを再ロードするよう試みる前に、ある期間待機しなければならない(MUST)。この期間は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのローディングを開始する時間から測定される。
初期最小再ロード遅延は、プレイリストにおける最後のメディアファイルの期間、又はターゲット期間の３倍の、どちらか小さい方である。メディアファイルの期間は、ＥＸＴＩＮＦタグにより特定される。
クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある期間待機しなければならない(MUST)。最小遅延は、ターゲット期間の３倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。この倍数は、第１の試みでは０．５であり、第２の試みでは１．５であり、そしてその後の試みでは３．０である。

６．２．４．ロードすべき次のファイルの決定
クライアントは、プレイリストファイルがロードされるか又は再ロードされるたびにロードすべき次のメディアファイルを決定するためにプレイリストファイルを検査しなければならない(MUST)。
ロードすべき最初のファイルは、第６．２．２章に述べたように、最初に再生すべくクライアントが選択したファイルでなければならない(MUST)。
再生されるべき最初のファイルがロードされそしてプレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのＵＲＩを、最初に見つけたオフセットに含むことを検証しなければならず(MUST)、そうでない場合は再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたＵＲＩに続く第１のメディアファイルＵＲＩでなければならない(MUST)。
再生されるべき第１のファイルがロードされ、そしてプレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものでなければならない(SHALL)。

６．２．５．暗号化されたメディアファイルの再生
プレイリストファイルが、キーファイルＵＲＩを特定するＥＸＴ−Ｘ−ＫＥＹタグを含む場合には、クライアントは、キーファイルを得、そしてその中のキーを使用して、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまで、そのＥＸＴ−Ｘ−ＫＥＹタグに続くメディアファイルを解読しなければならない(MUST)。
暗号化ＭＥＴＨＯＤがＡＥＳ−１２８である場合には、ＡＥＳ−１２８ ＣＢＣ解読を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を解読しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第５．１章に述べたＩＶとして使用しなければならない(MUST)。
暗号化ＭＥＴＨＯＤがＮＯＮＥである場合には、クライアントは、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまで、ＥＸＴ−Ｘ−ＫＥＹタグに続く全てのメディアファイルを平文（非暗号）として処理しなければならない(MUST)。

７．例
本章は、幾つかの規範的プレイリストファイルを含む。
７．１．簡単なプレイリストファイル
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT-X-ENDLIST
７．２．ＨＴＴＰＳを使用するスライディングウインドウプレイリスト
#EXTM3U
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680
#EXTINF:8,
https://priv.example.com/fileSequence2680.ts
#EXTINF:8,
https://priv.example.com/fileSequence2681.ts
#EXTINF:8,
https://priv.example.com/fileSequence2682.ts
７．３．暗号化されたメディアファイルを伴うプレイリストファイル
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:7794
#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-
128,URI="https://priv.example.com/key.php?r=52"

#EXTINF:15,
http://media.example.com/fileSequence7794.ts
#EXTINF:15,
http://media.example.com/fileSequence7795.ts
#EXTINF:15,
http://media.example.com/fileSequence7796.ts

#EXT-X-KEY:METHOD=AES-
128,URI="https://priv.example.com/key.php?r=53"

#EXTINF:15,
http://media.example.com/fileSequence7797.ts
７．４．変形プレイリストファイル
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
http://example.com/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example.com/mid.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example.com/hi.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"
http://example.com/audio-only.m3u8

８．セキュリティの考え方
プロトコルは、一般的に、ＨＴＴＰを使用してデータを送信するものであるから、ほぼ同じセキュリティの考え方が適用される。ＲＦＣ２６１６［ＲＦＣ２６１６］の第１５章を参照されたい。
メディアファイルパーサーは、典型的に、「ファジング」攻撃を受ける。クライアントは、サーバーから受け取ったファイルを構文解析するときに、不適合のファイルが拒絶されるように注意しなければならない(SHOULD)。
プレイリストファイルは、任意のエンティティのネットワーク要求をなすためにクライアントが使用するＵＲＩを含む。クライアントは、バッファのオーバーフローを防止するために応答のレンジチェックを行わねばならない(SHOULD)。ＲＦＣ３９８６［ＲＦＣ３９８６］の「セキュリティの考え方」の章を参照されたい。
クライアントは、サービス拒否攻撃への貢献を回避するためにＵＲＩにより怠惰に識別されるリソースをロードしなければならない(SHOULD)。
ＨＴＴＰ要求は、プライベートユーザデータを含むセッション状態（クッキー）をしばしば含む。具現化は、ＲＦＣ２９６５［ＲＦＣ２９６５］により特定されたクッキー制約及び満了ルールに従わねばならない(MUST)。ＲＦＣ２９６５及びＲＦＣ２９６４［ＲＦＣ２９６４］の「セキュリティの考え方」の章も参照されたい。
暗号キーは、ＵＲＩによって特定される。これらのキーの配信は、ＨＴＴＰのようなメカニズムにより、安全部門又はセッションクッキーに関連したＴＬＳ［ＲＦＣ５２４６］（以前のＳＳＬ）以上に安全確保されねばならない(SHOULD)。

９．参照文献
規範的参照文献
[AES_128] U.S. Department of Commerce/National Institute of
Standards and Technology, "Advanced Encryption Standard
(AES), FIPS PUB 197", November 2001, <http://
csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

[ISO_13818]
International Organization for Standardization, "ISO/IEC
International Standard 13818; Generic coding of moving
pictures and associated audio information", November 1994,
<http://www.iso.org/iso/catalogue_detail?csnumber=44169>.

[ISO_8601]
International Organization for Standardization, "ISO/IEC
International Standard 8601:2004; Data elements and
interchange formats -- Information interchange --
Representation of dates and times", December 2004,
<http://www.iso.org/iso/catalogue_detail?csnumber=40874>.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.

[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
Parameter for "Bucket" Media Types", RFC 4281,
November 2005.

[US_ASCII]
American National Standards Institute, "ANSI X3.4-1986,
Information Systems -- Coded Character Sets 7-Bit American
National Standard Code for Information Interchange (7-Bit
ASCII)", December 1986.
情報参照文献
[ID3] ID3.org, "The ID3 audio file data tagging format",
<http://www.id3.org/Developer_Information>.

[M3U] Nullsoft, Inc., "The M3U Playlist format, originally
invented for the Winamp media player",
<http://wikipedia.org/wiki/M3U>.

１１０：ネットワーク
１２０：サーバー
１３０：セグメンタ
１３５：インデクサ
１４０：セキュリティエージェント
１４５：ＨＴＴＰサーバーエージェント
１５０、１８０：クライアント装置
１６０：アッセンブラーエージェント
１６５：出力ジェネレータエージェント
１９０：アッセンブラーエージェント
１７０、１８５：セキュリティエージェント
１９５：出力ジェネレータエージェント
４００：サーバーストリームエージェント
４１０：制御ロジック
４１２：アプリケーション
４１４：メモリ
４２０：サーバーストリームエンジン
４３０：セグメンタ
４４０：インデクサ
４５０：セキュリティ
４６０：ファイルサーバー
５００：クライアントストリームエージェント
５１０：制御ロジック
５１４：メモリ
５１６：インターフェイス
５２０：クライアントストリームエンジン
５３０：アッセンブラー
５４０：出力ジェネレータ
５５０：セキュリティ

Claims (43)

1. サーバー装置においてデータのストリームを複数のメディアファイルへと分割する段階であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである段階と、
   複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有するプレイリストファイルを発生する段階であって、その複数のＵＲＩは、前記データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データのストリームから分割された特別のメディアファイルを識別する段階と、
   前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する段階であって、その更新されたプレイリストファイルは、前記データのストリームの表現を再生成するための複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含むものであり、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する段階と、
   を備えたマシン実施方法。
2. 前記複数のメディアファイルへの変更は、前記データのストリームに追加されたデータから分割された１つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩ及びその追加された１つ以上のメディアファイルを含む、請求項１に記載の方法。
3. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩを含み、そして前記更新されたタグが前記複数のメディアファイルへの修正を示す、請求項１に記載の方法。
4. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルから１つ以上の選択されたメディアファイルを除去し、１つ以上の更に別のメディアファイルを追加して１つ以上の残りのメディアファイルを生じることを含み、前記更新されたプレイリストファイルは、残りのメディアファイルに対するＵＲＩを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項１に記載の方法。
5. 前記更新されたプレイリストファイルは、選択された期間の満了時に発生される、請求項１に記載の方法。
6. 前記選択された期間は、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づく、請求項５に記載の方法。
7. 前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定する段階と、
   前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる段階と、
   を更に備えた請求項１に記載の方法。
8. 前記タグは、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグを含む、請求項７に記載の方法。
9. 前記プレイリストファイルにおける前記複数のＵＲＬのうちの１つ以上のＵＲＬのシーケンス番号を決定する段階と、
   １つ以上のシーケンス番号を指示する１つ以上のタグを前記プレイリストファイルに含ませる段階と、
   を更に備えた請求項１に記載の方法。
10. 前記１つ以上のタグは、１つ以上のＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む、請求項９に記載の方法。
11. 前記複数のメディアファイルを受信するクライアント装置が再生後に前記複数のメディアファイルを記憶することが許可されたかどうか決定する段階と、
    クライアント装置が再生後に前記複数のメディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストファイルに含ませる段階と、
    を更に備えた請求項１に記載の方法。
12. 前記タグは、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含む、請求項１１に記載の方法。
13. 実行時に、１つ以上のプロセッサが、
    サーバー装置においてデータのストリームを複数のメディアファイルへと分割し、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものであり、
    複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有するプレイリストファイルを発生し、複数のＵＲＬは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データのストリームから分割された特別のメディアファイルを識別し、
    前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生し、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたＵＲＩを含み、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する
    ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能な媒体を備えた物品。
14. 前記複数のメディアファイルへの変更は、１つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩ及びその追加された１つ以上のメディアファイルを含む、請求項１３に記載の物品。
15. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩを含み、そして前記１つ以上のタグが、前記複数のメディアファイルへの修正を示す、請求項１３に記載の物品。
16. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルから１つ以上の選択されたメディアファイルを除去しそして１つ以上の更に別のメディアファイルを追加して１つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するＵＲＩを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項１３に記載の物品。
17. 前記更新されたプレイリストファイルは、選択された期間の満了時に発生される、請求項１３に記載の物品。
18. 前記選択された期間は、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づくものである、請求項１７に記載の物品。
19. 前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定し、
    前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる、
    ことを更に含む請求項１３に記載の物品。
20. 前記タグは、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグを含む、請求項１９に記載の物品。
21. 前記プレイリストファイルにおける前記複数のＵＲＩのうちの１つ以上のＵＲＩのシーケンス番号を決定し、
    １つ以上のシーケンス番号を指示する１つ以上のタグを前記プレイリストファイルに含ませる、
    ことを更に含む請求項１３に記載の物品。
22. 前記１つ以上のタグは、１つ以上のＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む、請求項２１に記載の物品。
23. 前記複数のメディアファイルを受信するクライアント装置が再生後に前記複数のメディアファイルを記憶することが許可されたかどうか決定し、
    クライアント装置が再生後に前記複数のメディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストファイルに含ませる、
    ことを更に含む請求項１３に記載の物品。
24. サーバー装置においてデータのストリームを複数のメディアファイルへと分割する手段であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである手段と、
    複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有するプレイリストファイルを発生する手段であって、複数のＵＲＬは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データのストリームから分割された特別のメディアファイルを識別する手段と、
    前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する手段であって、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含むものであり、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する手段と、
    を備えた装置。
25. 前記複数のメディアファイルへの変更は、前記データのストリームに追加されたデータから分割された１つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩと、前記追加された１つ以上のメディアファイルとを含む、請求項２４に記載の装置。
26. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するＵＲＩを含み、そして１つ以上の更新されたタグは、前記複数のメディアファイルへの修正を示す、請求項２４に記載の装置。
27. 前記複数のメディアファイルへの変更は、前記複数のメディアファイルから１つ以上の選択されたメディアファイルを除去しそして１つ以上の更に別のメディアファイルを追加して１つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するＵＲＩを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、前記転送プロトコルは、ＨＴＴＰ適合プロトコルであり、前記更新されたプレイリストファイルは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づく、請求項２４に記載の装置。
28. 複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する段階であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである段階と、
    転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する段階であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有し、その複数のＵＲＩは、データの隣接時間ベースストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別する段階と、
    前記複数のＵＲＩのうちの１つ以上を使用するクライアント装置からの１つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの１つ以上をクライアント装置へ転送する段階と、
    更新されたプレイリストファイルをクライアント装置へ送信する段階であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、前記データの隣接時間ベースストリームの表現を再生成するための複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含むものであり、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する段階と、
    を備えたマシン実施方法。
29. 前記複数のメディアファイルへの変更は、（ａ）前記データの隣接時間ベースストリームに追加されたデータから分割された１つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するＵＲＩ及びその追加された１つ以上のメディアファイルを含むこと、（ｂ）前記複数のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するＵＲＩを含むこと、並びに１つ以上の更新されたタグが前記複数のメディアファイルへの修正を示すこと、或いは（ｃ）前記複数のメディアファイルから１つ以上の選択されたメディアファイルを除去しそして１つ以上の更なるメディアファイルを追加して１つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するＵＲＩを含むようにすること、のうちの少なくとも１つを含み、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項２８に記載の方法。
30. 前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づくものであり、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項２８に記載の方法。
31. 実行時に、１つ以上のプロセッサが、
    複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶し、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものであり、
    転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信し、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有し、その複数のＵＲＩは、前記データの隣接時間ベースストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別し、
    前記複数のＵＲＩのうちの１つ以上を使用するクライアント装置からの１つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの１つ以上をクライアント装置へ転送し、
    更新されたプレイリストファイルをクライアント装置へ送信し、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、前記データの隣接時間ベースストリームの表現を再生成するための複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含むものであり、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する
    ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能なメディアを備えた物品。
32. 前記複数のメディアファイルへの変更は、（ａ）前記データの隣接時間ベースストリームに追加されたデータから分割された１つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するＵＲＩ及びその追加された１つ以上のメディアファイルを含むこと、（ｂ）前記複数のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するＵＲＩを含むこと、並びに１つ以上の更新されたタグが前記複数のメディアファイルへの修正を示すこと、或いは（ｃ）前記複数のメディアファイルから１つ以上の選択されたメディアファイルを除去しそして１つ以上の更なるメディアファイルを追加して１つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するＵＲＩを含むようにすること、のうちの少なくとも１つを含み、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項３１に記載の方法。
33. 前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づくものであり、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項３１に記載の物品。
34. 複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する手段であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである手段と、
    転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する手段であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ（ＵＲＩ）を有し、その複数のＵＲＩは、前記データの隣接時間ベースストリームを再生成するための複数のメディアファイルの順序を指示するものであり、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別する手段と、
    前記複数のＵＲＩのうちの１つ以上を使用するクライアント装置からの１つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの１つ以上をクライアント装置へ転送する手段と、
    更新されたプレイリストファイルをクライアント装置へ送信する手段であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、前記データの隣接時間ベースストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたＵＲＩを含むものであり、各更新されたＵＲＩが特別の更新されたメディアファイルを識別する手段と、
    を備えた装置。
35. 転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
    前記要求に応答して、（１）番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ（ＵＲＩ）であって、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別するＵＲＩと、（２）複数のメディアファイルに関連したパラメータを有する複数のタグと、を含むプレイリストファイルを受信する段階と、
    前記プレイリストに指示された順序で前記複数のメディアファイルの１つ以上を要求して受信する段階と、
    前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含み、各更新されたＵＲＩが特別の更新されたメディアファイルを識別するものである段階と、
    を備えたマシン実施方法。
36. 前記複数の更新されたメディアファイルから番組の表現を発生する段階を更に備えた、請求項３５に記載の方法。
37. 前記複数のメディアファイルへの変更は、（ａ）前記データの隣接時間ベースストリームに追加されたデータから分割された１つ以上のメディアファイルを追加し、及び前記追加されたプレイリストファイルが、更新された複数のメディアファイルに対するＵＲＩを含むこと、（ｂ）前記複数のメディアファイルのうちの１つ以上を修正すること、或いは（ｃ）前記プレイリストファイルからメディアファイルの第１セットを除去しそしてプレイリストファイルに１つ以上の更なるメディアファイルを追加すること、のうちの少なくとも１つを含み、更に、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項３６に記載の方法。
38. 前記更新されたプレイリストは、前記プレイリストファイルにおける前記複数のタグのうちの１つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項３７に記載の方法。
39. 実行時に、１つ以上のプロセッサが、
    転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
    前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ（ＵＲＩ）であって、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別するＵＲＩと、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する段階と、
    前記プレイリストファイルに指示された順序で前記メディアファイルの１つ以上を要求して受信する段階と、
    前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含み、各更新されたＵＲＩが特別の更新されたメディアファイルを識別するものである段階と、
    を備えた方法を遂行するようにさせる実行可能なインストラクションを記憶したマシン読み取り可能な記憶メディア。
40. 前記方法は、更に、前記複数の更新されたメディアファイルから番組の表現を発生する段階を更に備えた、請求項３９に記載の記憶メディア。
41. 前記複数のメディアファイルへの変更は、（ａ）前記データの隣接時間ベースストリームに追加されたデータから分割された１つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、前記追加された複数のメディアファイルに対するＵＲＩを含むこと、（ｂ）前記複数のメディアファイルのうちの１つ以上を修正すること、或いは（ｃ）前記プレイリストファイルからメディアファイルの第１セットを除去しそしてプレイリストファイルに１つ以上の更なるメディアファイルを追加すること、のうちの少なくとも１つを含み、更に、前記転送プロトコルは、ＨＴＴＰ適合プロトコルである、請求項４０に記載の記憶メディア。
42. 前記更新されたプレイリストファイルは、前記プレイリストファイルにおける複数のタグのうちの１つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項４１に記載の記憶メディア。
43. 転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する手段と、
    前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ（ＵＲＩ）であって、各ＵＲＩが前記データの隣接時間ベースストリームから分割された特別のメディアファイルを識別するＵＲＩと、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する手段と、
    前記プレイリストに指示された順序で前記複数のメディアファイルの１つ以上を要求して受信する手段と、
    前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する手段であって、その更新されたプレイリストファイルは、複数の更新されたメディアファイルの順序を指示する複数の更新されたＵＲＩを含み、各更新されたＵＲＩが特別の更新されたメディアファイルを識別するものである手段と、
    を備えたデータ処理システム。

Images