"サーバー装置においてデータのストリームを複数のメディアファイルへと分割する段階であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである段階と、複数のタグ及び複数のユニバーサルリソースインジケータURIを有するプレイリストファイルを発生する段階であって、その複数のURIは、前記データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する段階であって、その更新されたプレイリストファイルは、前記データのストリームの表現を再生成するための前記更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、を備えたマシン実施方法。前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項1に記載の方法。前記複数のメディアファイルへの変更は、前記1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項1に記載の方法。前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去し、1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じることを含み、前記更新されたプレイリストファイルは、残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項1に記載の方法。前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項1に記載の方法。前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項5に記載の方法。前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定する段階と、前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる段階と、を更に備えた請求項1に記載の方法。前記タグは、EXT-X-TARGETDURATIONタグを含む、請求項7に記載の方法。前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定する段階と、1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる段階と、を更に備えた請求項1に記載の方法。前記1つ以上のタグは、1つ以上のEXT-X-MEDIA-SEQUENCEタグを含む、請求項9に記載の方法。前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定する段階と、クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる段階と、を更に備えた請求項1に記載の方法。前記タグは、EXT-X-ALLOW-CACHEタグを含む、請求項11に記載の方法。実行時に、1つ以上のプロセッサが、サーバー装置においてデータのストリームを複数のメディアファイルへと分割し、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものであり、複数のタグ及び複数のユニバーサルリソースインジケータURIを有するプレイリストファイルを発生し、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生し、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含む、ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能な媒体を備えた物品。前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項13に記載の物品。前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項13に記載の物品。前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項13に記載の物品。前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項13に記載の物品。前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものである、請求項17に記載の物品。前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定し、前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる、ことを更に含む請求項13に記載の物品。前記タグは、EXT-X-TARGETDURATIONタグを含む、請求項19に記載の物品。前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定し、1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる、ことを更に含む請求項13に記載の物品。前記1つ以上のタグは、1つ以上のEXT-X-MEDIA-SEQUENCEタグを含む、請求項21に記載の物品。前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定し、クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる、ことを更に含む請求項13に記載の物品。サーバー装置においてデータのストリームを複数のメディアファイルへと分割する手段であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである手段と、複数のタグ及び複数のユニバーサルリソースインジケータURIを有するプレイリストファイルを発生する手段であって、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する手段であって、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、を備えた装置。前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIと、前記追加された1つ以上のメディアファイルとを含む、請求項24に記載の装置。前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項24に記載の装置。前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、前記転送プロトコルは、HTTP適合プロトコルであり、前記更新されたプレイリストは、選択された期間の満了時に発生され、そしてその選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項24に記載の装置。複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する段階であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである段階と、転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する段階であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータURIを有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する段階と、更新されたプレイリストファイルをクライアント装置へ送信する段階であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、を備えたマシン実施方法。前記複数のメディアファイルへの変更は、a1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、b前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いはc前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。実行時に、1つ以上のプロセッサが、複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶し、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものであり、非ストリーミング転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信し、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータURIを有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送し、更新されたプレイリストファイルをクライアント装置へ送信し、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである、ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能なメディアを備えた物品。前記複数のメディアファイルへの変更は、a1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、b前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いはc前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の方法。前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の物品。複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する手段であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである手段と、転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する手段であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータURIを有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する手段と、更新されたプレイリストファイルをクライアント装置へ送信する手段であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、を備えた装置。転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、前記要求に応答して、1番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータURIと、2複数のメディアファイルに関連したパラメータを有する複数のタグと、を含むプレイリストファイルを受信する段階と、前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、を備えたマシン実施方法。前記更新された複数のメディアファイルから番組の表現を発生する段階を更に備えた、請求項35に記載の方法。前記メディアファイルへの変更は、a1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、b前記複数のメディアファイルのうちの1つ以上を修正すること、或いはc前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項36に記載の方法。前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項37に記載の方法。実行時に、1つ以上のプロセッサが、転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータURIと、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する段階と、前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、を備えた方法を遂行するようにさせる実行可能なインストラクションを記憶したマシン読み取り可能な記憶メディア。前記方法は、更に、前記更新されたプレイリストから番組の表現を発生する段階を更に備えた、請求項39に記載の記憶メディア。前記メディアファイルへの変更は、a1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、b前記複数のメディアファイルのうちの1つ以上を修正すること、或いはc前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項40に記載の記憶メディア。前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項41に記載の記憶メディア。転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する手段と、前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータURIと、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する手段と、前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する手段と、前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する手段であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、を備えたデータ処理システム。現在のストリーミングサービスは、一般に、エンドユーザに生のコンテンツを配布するために特殊なサービスを要求する。大規模な配備では、これが多大なコストを招き、設定及び運転のために特殊なスキルを必要とする。その結果、ストリーミングに利用できるコンテンツのライブラリーは、望ましいライブラリーには至らない。一実施形態において、サーバー装置は、ストリーミングされるべきコンテンツの少なくとも一部分を記憶する。コンテンツは、典型的に、画像又は音声例えば、サウンド又は音楽或いはその両方の時間ベースストリームであり、時間ベースストリームの一例は、画像の順序及び提示が時間に基づいていて、従って、時間ベースストリームと考えられる映画である。サーバーは、ストリーミングされるべきコンテンツをネットワークプロトコルに基づいてパケットを経て送信されるべきセグメントへと分解するためのセグメントエージェントと、セグメント化されたユーザデータをクライアントが提示するのを容易にすることのできる1つ以上のプレイリストファイルを発生するためのインデクサエージェントとを備えている。クライアント装置は、ネットワークを経てサーバー装置或いはセグメント及びプレイリストを記憶してそれらを送信するが、発生はしない別のサーバーに結合される。クライアント装置は、1つ以上のプレイリストファイルを受け取り、そしてその1つ以上のプレイリストファイルに基づいてコンテンツへのセグメント化メディアファイルの検索を容易にするためのアッセンブラーエージェントを有している。又、クライアント装置は、そのクライアント装置の1つ以上の出力コンポーネントを経てコンテンツを出力するための出力ジェネレータエージェントも有している。一実施形態において、サーバー装置は、クライアント装置へ送信されるべきデータを取得する。サーバー装置は、送信されるべきデータをセグメンタエージェントで複数のメディアファイルに分割する。又、サーバー装置は、複数のセグメントをメモリに個々のメディアファイルとして記憶する。更に、サーバー装置は、複数のメディアファイルへのリファレンスを有する1つ以上のプレイリストファイルを発生する。クライアント装置からのデータの要求に応答して、サーバー装置又は別のサーバー装置は、ネットワークを経てクライアント装置へ1つ以上のプレイリストファイル及び少なくとも複数のメディアファイルのサブセットを送信する。複数のメディアファイルは、クライアント装置からの要求に応答して非ストリーミング転送プロトコルを使用して送信することができ、このプロトコルは、例えば、HTTPである。一実施形態において、クライアント装置は、1つ以上のプレイリストファイルを受け取って記憶することができる。次いで、クライアントは、プレイリストファイルにおいて識別されたセグメント化されたメディアファイルを要求し、そしてリンクされたメディアファイルをダウンロードすることができる。次いで、クライアント装置又は別のクライアント装置は、コンテンツのストリームを表すオーディオ及び/又はビデオ出力を発生することができる。一実施形態において、更新されたプレイリストを、サーバーによって動的に発生して、クライアントにより検索することができる。更新されたプレイリストは、オリジナルのプレイリストにおける番組に加えて示された付随的資料例えば、サイドバーユーザインターフェイスにおける広告、関連コンテンツ、別のバージョン、等を含むか、又は番組の付加的な部分例えば、オリジナルのプレイリストにおいて識別された第1の半分を越える番組の第2の半分を含むことができる。1つの具現化において、サーバーは、ここに述べるローリング方法を使用して、プレイリストを更新し、これを、次いで、クライアントにより更新されたプレイリストとして検索することができる。一実施形態において、プレイリストは、同じコンテンツを表す複数の代替えストリームを特定することができ、これら代替えストリームは、異なる視覚解像度で送信されるひいては、異なるビットレートで送信される同じ番組でもよいし、或いは他の異なる属性を伴う同じ番組でもよい。サーバーは、代替えストリームごとに1つづつ、複数のプレイリストを発生することができ、又、代替えストリームを指すかさもなければそれを特定する変形プレイリストを発生することができる。次いで、サーバー又は別のサーバーは、変形プレイリストをクライアント装置へ送信することができ、そしてクライアント装置は、現在ネットワーク条件例えば、メディアファイルを転送するのに使用されるネットワークの現在スループットレートに基づいて、変形プレイリストからどのプレイリストを選択すべきか判断することができ、そしてクライアント装置は、選択されたプレイリストをダウンロードすることができる更に、その選択されたプレイリストにより特定されたメディアファイルをダウンロードすることができる。一実施形態において、クライアント装置は、コンテンツを受け取って提示する間に変形プレイリストにおける第1のプレイリストからその変形プレイリストにおける第2のプレイリストへスイッチすることができる。例えば、クライアント装置は、第1のプレイリスト及び第1のビットレートを使用して番組を受け取ることができ、そしてネットワークのスループットレートの測定を通して、第2のプレイリストによりコンテンツが特定されるところの同じ番組のコンテンツをより高い第2のビットレートで受信できると決定することができる。この場合に、クライアント装置は、第2のプレイリストを要求し、第2のプレイリストを受け取り、そして第1のプレイリストにより特定されたコンテンツを提示し続けながら第2のプレイリストにおいて特定されたメディアファイルの検索を開始することができる。クライアント装置は、メディアファイル及び結果的に得られる解凍されたコンテンツを両プレイリストのバッファに記憶することができ、そしてクライアント装置は、自動的なオペレーションを遂行して、いつ、どのように、コンテンツの2つのバージョン間をスイッチ又は遷移すべきか決定することができる。例えば、クライアント装置は、コンテンツの2つのバージョンにおけるオーディオコンテンツのパターンマッチングを使用して、2つのバージョンにおける一致点を見出し、次いで、第2のプレイリストから新たなコンテンツの遷移を識別した後にスイッチを行わせることができる。一実施形態において、方法は、代替えストリームを使用してメディアコンテンツをクライアント装置に与える複数の冗長位置を設けることを含む。フェイルオーバー保護を具現化するため、第1のサーバー装置又は第1のコンテンツ配布サービスは、ストリーム又は複数の代替え帯域巾ストリームを生成し、そしてプレイリストファイル1つ又は複数を作成する。第2のサーバー装置又は第2のコンテンツ配布サービスは、並列ストリーム又はストリームのセットを生成する。クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のユニフォームリソースロケーターURLからプレイリストファイル1つ又は複数をダウンロードするよう試みる。クライアントは、第1のURLからプレイリストファイルをダウンロードできない場合に、別のURLに関連した代替えストリームへスイッチするよう試みる。一実施形態において、方法は、プレイリストの要求を発し、その要求においてプレイリストを圧縮できることを特定し、そしてその要求に応答して、サーバーがプレイリストを圧縮形態で与えることができる場合にプレイリストを圧縮形態で受け取ることを含むさもなければ、プレイリストは、サーバーにより非圧縮形態で与えることができる。プレイリストは、デフレート又はgzipのような既存のHTTP標準圧縮技術によりサポートされる圧縮技術又はフォーマットを使用して圧縮エンコードとも称されるすることができる。圧縮形態でのプレイリストの送信及び受信は、特に、プレイリストが時間と共に成長するときに例えば、プレイリストが長いベースボールゲーム用のものであるときに、送信及び受信されるデータのサイズを著しく減少することができる。一実施形態において、プレイリストに圧縮を使用することは、クライアントプレイリストを要求するシステム及びサーバープレイリストを送信することにより要求に応答するシステムの両方にとって任意である。HTTP規格の一部分である圧縮技術又はフォーマットを使用することは、適合するウェブサーバーが圧縮されたプレイリストを供給できるようにすると共に、適合するクライアントがプレイリストを解凍して使用できるようにもする。本発明は、同様の要素が同じ参照番号で示された添付図面に、一例として、非限定的に示されている。以下の説明では、多数の特定の細部について述べる。しかしながら、本発明の実施形態は、これらの特定の細部を伴わずに実施されてもよい。他の点については、良く知られた回路、構造及び技術は、説明の理解を妨げないために詳細に示さない。この説明は、版権で保護される資料、例えば、グラフィックユーザインターフェイスの画像の例示を含む。本発明の譲受人を含む版権所有者は、これら資料において版権を含む権利を所有している。版権所有者は、特許商標庁の特許ファイル又は記録に現れるように特許文書又は特許開示を誰かが複写再現することに異議を唱えるものではなく、著作権の全ての権利は何であれ保存されるものとする。版権アップル社2009年。一実施形態において、ここに述べる技術及びコンポーネントは、非ストリーミングプロトコル例えば、HTTP及び他のテクノロジー例えば、モーションピクチャーエクスパートグループMPEGストリームを使用してストリーミングの経験を配信するためのメカニズムを含むことができる。例えば、生のミュージカル又はスポーツ行事、生のニュース、ウェブカメラフィード、等を放送するために、HTTPを使用してほぼリアルタイムのストリーミング経験を提供することができる。一実施形態では、プロトコルは、到来するメディアデータを複数のメディアファイルにセグメント化し、そしてそれらのセグメント化されたメディアファイルをサーバーに記憶することができる。又、プロトコルは、サーバーに記憶されたセグメント化されたメディアファイルにクライアントを向けるユニフォームリソースアイデンティファイアURIを含むプレイリストファイルを構築することもできる。セグメント化されたメディアファイルがプレイリストファイル1つ又は複数に基づいて再生されるときには、クライアントは、生の事象のほぼリアルタイムの放送をユーザに提供することができる。予め記録されたコンテンツを同様に提供することもできる。一実施形態において、サーバーは、補足的又は代替え的メディアコンテンツ例えば、広告、スポーツ行事に関連した統計情報、主たる提示に対する付加的なメディアコンテンツを放送事象に動的に導入することができる。例えば、メディア事象のクライアント再生中に、サーバーは、付加的なURIをプレイリストファイルに追加することができ、URIは、クライアントが補足的メディアファイルをダウンロードできるところの位置を識別する。クライアントは、サーバーが導入した補足的又は付加的又は両方のメディアコンテンツにアクセスするために1つ以上の更新されたプレイリストファイルをサーバーから周期的に検索するように命令される。一実施形態において、サーバーは、累積モード又はローリングモードのいずれかで動作することができる。累積モードでは、サーバーは、プレイリストファイルを生成し、そしてプレイリストファイルの終わりにメディアファイル識別子を添付することができる。次いで、クライアントは、ダウンロード時に単一のプレイリストファイルからストリームの全ての部分にアクセスすることができる例えば、ユーザは、ショーの中間でスタートすることができる。ローリングモードでは、サーバーは、ローリングベースでプレイリストファイルの始めからメディアファイル識別子を除去して、クライアント装置にアクセスできるメディアコンテンツのスライディングウインドウを設けることにより、メディアファイルの利用性を制限することができる。又、サーバーは、プレイリストにメディアファイル識別子を追加することもでき、そしてローリングモードでは、サーバーは、メディアファイルの利用性を、プレイリストに最新に追加されたものに制限することができる。次いで、クライアントは、プレイリストファイルの更新コピーを繰り返しダウンロードして見続ける。プレイリストダウンロードのためのローリングベースは、コンテンツが潜在的に時間的に無限である例えば、連続的に動作されるウェブからコンテンツが到来するときに有用である。クライアントは、プレイリストに終了タグを見つけるまでローリングモードにおいてプレイリストを繰り返し要求し続けることができる。一実施形態において、このメカニズムは、同じ提示の変形ストリームを与えることによりビットレートスイッチングをサポートする。例えば、サービスされるべき提示の多数のバージョンをサーバーに記憶することができる。各バージョンは、実質的に同じコンテンツを有するが、異なるビットレートでエンコードすることができる。これは、クライアント装置が、再生の連続性を妥協することなく、例えば、利用可能な帯域巾の検出に基づいて、ビットレート間をスイッチできるようにする。一実施形態において、無断使用に対してコンテンツを保護するために保護特徴を設けることができる。例えば、予想を防止するために、非順次メディアファイルナンバリングを使用してもよい。又、メディアファイルの暗号化を使用してもよい。更に、部分メディアファイルリストを使用してもよい。又、付加的な及び/又は異なる保護特徴を設けてもよい。図1は、リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。図1の例は、2つのクライアントがネットワークを経てサーバーに結合された簡単なサーバー/クライアント接続を示す。ここに述べる技術及びメカニズムを使用して、いかなる数のクライアントもサポートすることができる。更に、ここに述べる技術及びメカニズムに基づき、複数のサーバーがコンテンツを与えてもよく、及び/又はそれらが一緒に動作してコンテンツを与えてもよい。例えば、1つのサーバーがコンテンツを生成し、プレイリストを生成し、そして複数のメディア例えば、ファイルを生成すると共に、他のサーバーがその生成されたコンテンツを記憶し送信してもよい。ネットワーク110は、ワイヤードであるか、ワイヤレス例えば、IEEE802.11、802.16であるか、又はその組み合わせであるかに関わらず、いかなる形式のネットワークでもよい。例えば、ネットワーク110は、インターネット又はイントラネットでよい。別の例として、ネットワーク110は、セルラーネットワーク例えば、3G、CDMAでもよい。一実施形態において、クライアント装置150及び180は、複数のネットワーク形式を経て通信することができる例えば、各装置は、WiFiワイヤレスLANを経て及びワイヤレスセルラー電話ネットワークも経て通信することができる。例えば、クライアント装置150及び180は、セルラー無線電話ネットワーク及びデータネットワークを経て通信できるスマートホン又はセルラーイネーブル型パーソナルデジタルアシスタントでもよい。これらの装置は、いずれかの形式のネットワークを経てここに述べるストリーミングメカニズムを使用することもできるし、又は必要に応じてネットワーク間をスイッチすることもできる。サーバー120は、この技術で良く知られたように、HTTPサーバーとして動作してもよい。即ち、サーバー120は、HTTPプロトコルを使用してコンテンツを与えるHTTPサーバーエージェント145を備えている。図1の例は、HTTPに関して説明するが、他のプロトコルを同様に利用することができる。セグメンタ130及びインデクサ135は、ここに述べるようにメディアファイルのコンテンツにプレイリストファイルを与えるためにサーバー120又は複数のサーバー上に存在するエージェントである。これらのメディアファイル及びプレイリストファイルは、HTTPプロトコルを使用してHTTPサーバーエージェント145を経て又は他のサーバーを経てネットワーク110にわたり送ることができる。ここに述べるエージェントは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせとして具現化することができる。セグメント130は、メディアデータのストリームを、HTTPプロトコルを経て送信できる複数のメディアファイルへ分割するように機能する。インデクサ135は、セグメント化されたメディアファイルに対応するプレイリストファイルを生成するように機能して、クライアント装置がメディアファイルを再アッセンブルし、サーバー120により与えられたコンテンツをリアルタイム又はほぼリアルタイムで送信できるようにする。クライアント装置からの1つ以上の要求に応答して、HTTPサーバーエージェント145又は他のサーバーは、インデクサ135により発生される1つ以上のプレイリストファイル及びセグメンタ130により発生されるコンテンツのメディアファイルを送信することができる。サーバー120は、更に、ここに述べるセキュリティ機能の1つ以上例えば、暗号化を与える任意のセキュリティエージェント140を備えている。又、サーバー120は、図1に示されていない付加的なコンポーネントを含んでもよい。クライアント装置150及び180は、サーバー120からネットワーク110を経てプレイリストファイル及びメディアファイルを受け取る。クライアント装置は、ネットワークを経て送信されたデータを受け取ることができ、そしてネットワークを経て受け取ったデータ使用して出力を発生できる任意の形式の電子装置、例えば、ワイヤレス移動装置、PDA、娯楽装置、消費者向け電子装置、等でよい。その出力は、任意のメディア形式又はメディア形式の組み合わせで、例えば、オーディオ、ビデオ、又はその組み合わせを含む。クライアント装置150は、アッセンブラーエージェント160及び出力ジェネレータエージェント165を含むことができる。同様に、クライアント装置180は、アッセンブラーエージェント190及び出力ジェネレータエージェント195を含むことができる。アッセンブラーエージェント160及び180は、サーバー120からプレイリストファイルを受け取り、そしてそのプレイリストファイルを使用して、サーバー120にアクセスし、そこからメディアファイルをダウンロードする。出力ジェネレータエージェント165及び195は、ダウンロードされたメディアファイルを使用して、各々、クライアント装置150及び160から出力を発生することができる。出力は、1つ以上のスピーカ、1つ以上のディスプレイスクリーン、スピーカ及びディスプレイスクリーンの組み合わせ、或いは他の入力又は出力装置により発生することができる。又、クライアント装置は、メディアファイル例えば、圧縮されたメディアファイル又は解凍されたメディアファイルが受け取られたときにそれらを記憶するためのバッファとして作用するメモリ例えば、フラッシュメモリ又はDRAM、等を含むこともでき、このバッファは、現在提示されているコンテンツの時間を越えて何秒にも値する提示可能なコンテンツを与え、新たなコンテンツがダウンロードされる間にそのバッファされたコンテンツを後で表示できるようにする。このバッファは、クライアント装置が間欠的な低速のネットワーク接続を通してコンテンツを検索するよう試みる間に提示可能なコンテンツを与えることができ、ひいては、このバッファは、ネットワークの待ち時間又は接続の問題を隠すことができる。更に、クライアント装置150及び180は、各々、ここに述べるセキュリティ機能の1つ以上を与える任意のセキュリティエージェント170及び185を備えている。又、クライアント装置150及び180は、図1には示されていない付加的なコンポーネントを含んでもよい。一実施形態において、本出願に述べる技術は、非ストリーミングプロトコル例えば、HTTPを経てマルチメディアデータの無限のストリームを送信するのに使用されてもよい。又、実施形態は、メディアデータを暗号化し及び/又はストリームの代替えバージョンを与える例えば、代替えビットレートを与えることも含み得る。メディアデータは、生成後に直ちに送信できるので、ほぼリアルタイムで受け取ることができる。マルチメディアデータのストリームのサーバー送信者及びクライアント受信者によってとられるべきアクション及びファイルの規範的なデータフォーマットが与えられるが、他のフォーマットをサポートすることもできる。シミュレーションされたリアルタイムストリーム又はほぼリアルタイムのストリームとして送信できるメディア提示は、プレイリストファイルを指示するユニバーサルリソースインジケータURIにより特定される。一実施形態において、プレイリストファイルは、付加的なURIの順序付けされたリストである。プレイリストファイルにおける各URIは、特定番組に対するメディアデータの単一隣接ストリームであるストリームのセグメントであるメディアファイルを指す。メディアデータのストリームを再生するため、クライアント装置は、サーバーからプレイリストファイルを得る。又、クライアントは、プレイリストファイルにより指示された各メディアデータファイルを得て再生する。一実施形態において、クライアントは、付加的な及び/又は異なるメディアセグメントを発見するためにプレイリストファイルを動的に又は繰り返し再ロードすることができる。プレイリストファイルは、例えば、拡張M3Uプレイリストファイルでよい。一実施形態において、M3Uフォーマットを効果的に拡張する付加的なタグが使用される。M3Uは、ムービングピクチャーエクスパーツグループオーディオレイヤ3ユニフォームリソースロケーターMP3URLを指すもので、マルチメディアプレイリストを記憶するのに使用されるフォーマットである。M3Uファイルは、メディアプレーヤが再生するための1つ以上のメディアファイルの位置を含むテキストファイルである。プレイリストファイルは、一実施形態では、個々のラインより成る拡張型M3Uフォーマットテキストファイルである。それらのラインは、単一のLFキャラクタにより終了するか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了することができる。各ラインは、URI、ブランクライン、又はコメントキャラクタ例えば、‘’でのスタートである。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視することができる。コメントキャラクタでスタートするラインは、コメント又はタグである。タグは、EXTで開始し、一方、コメントラインは、で開始することができる。コメントラインは、通常、サーバー及びクライアントにより無視することができる。一実施形態において、プレイリストファイルは、UTF-8フォーマットでエンコードされる。UTF-88ビットのユニコードトランスフォーメーションフォーマットは、可変長さのキャラクタエンコーディングフォーマットである。別の実施形態では、他のキャラクタエンコーディングフォーマットを使用することができる。以下の例では、2つのタグ、EXTM3U及びEXTINFを含む拡張型M3Uフォーマットが使用される。拡張型M3Uファイルは、EXTM3Uを含む第1のラインにより基本的M3Uファイルから区別される。EXTINFは、タグに続くURIにより識別されるメディアファイルを示すレコードマーカーである。一実施形態において、各メディアファイルの前には、EXTINFタグ、例えば、EXTINF:<duration>、<title>があり、durationは、メディアファイルの期間を特定し、そしてtitleは、ターゲットメディアファイルのタイトルである。一実施形態において、次のタグは、メディアファイルの転送及び再生を管理するのに使用される。EXT-X-TARGETDURATIONEXT-X-MEDIA-SEQUENCEEXT-X-KEYEXT-X-PROGRAM-DATE-TIMEEXT-X-ALLOW-CACHEEXT-X-STREAM-INFEXT-X-ENDLISTこれらのタグは、各々、以下で詳細に述べる。各新たなタグについて特定のフォーマット及び属性を説明するが、異なる属性、ネーム、フォーマット、等を伴う別の実施形態をサポートすることもできる。EXT-X-TARGETDURATIONタグは、提示に追加される次のメディアファイルのおおよその期間を指示することができる。これは、再生ファイルに含まれ、そのフォーマットは、次の通りである。EXT-X-TARGETDURATION:<seconds>但し、secondsは、メディアファイルの期間を指示する。一実施形態において、実際の期間は、タグによって指示されるターゲット期間とは若干相違することがある。一実施形態において、セグメントを指示する各URIは、セグメントのおおよその期間に関連付けられ、例えば、セグメントのURIの前に、そのセグメントのおおよその期間を指示するタグが付けられる。プレイリストファイルにおける各メディアファイルURIは、独特のシーケンス番号をもつことができる。URIのシーケンス番号は、もしそれが存在する場合は、一実施形態では、それに先行するURIのシーケンス番号1に等しくなる。EXT-X-MEDIA-SEQUENCEタグは、プレイリストファイルに現れる第1のURIのシーケンス番号を指示することができ、そのフォーマットは、次の通りである。EXT-X-MEDIA-SEQUENCE:<number>但し、numberは、URIのシーケンス番号である。プレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含まない場合には、プレイリスト内の第1のURIのシーケンス番号が1であると考えられる。一実施形態において、シーケンス番号は、非順次でよく、例えば、1、5、7、17、等の非順次のシーケンス番号は、シーケンスにおける次の番号の予想を困難にし、これは、コンテンツを海賊版作成から保護する上で助けとなる。コンテンツを保護する上で助けとなる別のオプションは、所与の時間にプレイリストの一部分だけを露呈することである。あるメディアファイルは、暗号化することができる。EXT-X-KEYタグは、それに続くメディアファイルを解読するために使用できる情報を与え、そのフォーマットは、次の通りである。EXT-X-KEY:METHOD=<method>[,URI=<URI>]METHODパラメータは、暗号化方法を特定し、そしてURIパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。NONEの暗号化方法は、暗号化しないことを指示する。種々の暗号化方法を使用することができ、例えば、AES-128は、128ビットキー及びPKCS7パッディングRFC3852を参照を伴うアドバンスエンクリプションスタンダード暗号化を使用する暗号化を指示する。新規なEXT-X-KEYタグは、従来のEXT-X-KEYタグに取って代わるものである。URIパラメータを伴うEXT-X-KEYタグは、キーファイルを識別する。このキーファイルは、プレイリストファイルに載せられた後続メディアファイルを解読するのに使用される暗号キーを含む。例えば、AES-128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおける16オクテットのパックアレイである。AES-128の使用は、通常、暗号化及び解読時に同じ16オクテットの初期化ベクトルIVを供給することを要求する。IVの変更を使用して、暗号化の強度を高めることができる。AES-128暗号化を使用するときに、メディアファイルのシーケンス番号は、メディアファイルの暗号化又は解読時にIVとして使用することができる。EXT-X-PROGRAM-DATE-TIMEタグは、次のメディアファイルの開始を絶対的日付及び/又は時刻に関連付けできるもので、時間ゾーンを含むか又は指示することができる。一実施形態において、日付/時刻表現は、ISO/IEC8601:2004である。タグのフォーマットは、次の通りである。EXT-X-PROGRAM-DATE-TIME:<YYYMMDDThhmmssZ>EXT-X-ALLOW-CACHEタグは、クライアントがダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶できるかどうか指示するのに使用することができる。タグのフォーマットは、次の通りである。EXT-X-ALLOW-CACHE:<YES|NO>EXT-X-ENDLISTタグは、一実施形態では、それ以上のメディアファイルをプレイリストファイルに追加しないことを指示する。タグのフォーマットは、次の通りである。EXT-X-ENDLIST一実施形態において、プレイリストが最終的セグメント又はメディアファイルを含む場合には、プレイリストがEXT-X-ENDLISTタグをもつことになる。EXT-X-STREAM-INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示するのに使用できる。タグのフォーマットは、一実施形態では、次の通りである。EXT-X-STREAM-INF:attributevalue]attributevalue<URI>ここで、次の属性が使用される。属性BANDWIDTH=<n>は、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。属性PROGRAM-ID=<i>は、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM-IDを伴う複数のEXT-X-STREAM-INFURIを含む。この開示では、変形ストリーム及び変形プレイリストについて更に説明する例えば、図9A-9Dを参照。以上のタグ及び属性は、オリジナルメディアコンテンツを表すメディアファイルを編成し、送信しそして処理するために、サーバー装置により使用することができる。クライアント装置は、この情報を使用して、リアルタイム又はほぼリアルタイムのストリーミング経験例えば、音楽又はスポーツ行事のような生放送を見ることをクライアント装置のユーザに与えるようにメディアファイルを再アッセンブルし、提示する。プレイリストファイルにおける各メディアファイルURIは、オリジナル提示即ち、オリジナルメディアコンテンツのセグメントであるメディアを識別する。一実施形態において、各メディアファイルは、MPEG-2トランスポートストリーム、MPEG-2番組ストリーム、又はMPEG-2オーディオ基本的ストリームとしてフォーマットされる。このフォーマットは、CODECを特定することにより特定することができ、そしてプレイリストは、CODECを特定することによりフォーマットを特定することができる。一実施形態では、提示における全てのメディアファイルが同じフォーマットを有するが、他の実施形態では、複数のフォーマットをサポートできる。トランスポートストリームファイルは、一実施形態では、単一のMPEG-2番組を含まねばならず、各ファイルの開始に番組アソシエーションテーブル及び番組マップテーブルがなければならない。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない。クライアントは、合理的なサブセットを選択することにより特定形式例えば、オーディオ又はビデオの複数のトラックを取り扱うように準備しなければならない。クライアントは、一実施形態では、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない。メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したものでなければならない。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない。図2Aは、1つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。図2Aの例は、HTTPに関して与えられるが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Aの例は、単一のサーバーが幾つかのタスクを遂行することに関して与えられる。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でもよい。サーバー装置は、オペレーション200において、与えられるべきコンテンツを受け取る。コンテンツは、生のオーディオ及び/又はビデオ例えば、スポーツ行事、生のニュース、ウェブカメラのフィードを表す。又、コンテンツは、予め記録されたコンテンツ例えば、記録されたコンサート、トレーニングセミナー、等を表してもよい。コンテンツは、ストリーム型であるかどうかに関わらず、この技術で知られたフォーマット及びプロトコルに基づいてサーバーにより受け取られる。一実施形態では、コンテンツは、MPEG-2ストリームの形態でサーバーにより受け取られるが、他のフォーマットをサポートすることもできる。次いで、サーバーは、オペレーション210において、コンテンツの少なくとも一部分を一時的に記憶する。コンテンツ又はコンテンツの少なくとも一部分は、例えば、記憶装置例えば、記憶エリアネットワークのハードディスク、等又はメモリに一時的に記憶される。或いは又、コンテンツは、記憶メディア例えば、コンパクトディスク、フラッシュドライブを経て受け取られ、そこから記憶装置又はメモリへコンテンツを転送してもよい。一実施形態では、サーバーは、必要に応じてコンテンツを1つ以上のストリーム例えば、MPEG-2へ変換するエンコーダを有する。この変換は、受け取ったコンテンツを永久的に記憶せずに行うことができ、ある実施形態では、記憶オペレーション210を省略してもよいし、又は他の実施形態では、それが長期間記憶例えば、アーカイブ記憶であってもよい。与えられるべきコンテンツは、オペレーション220において、複数のメディアファイルへとセグメント化される。一実施形態では、サーバーは、ストリームを、別々の個別のメディアファイル即ち、セグメントへと変換し、これらファイルは、標準ウェブサーバーを使用して配布することができる。一実施形態では、サーバーは、個々のメディアファイルの有効なデコードをサポートするポイントにおいて例えば、PESパケット境界及びi-フレーム境界のようなパケット及びキーフレーム境界においてメディアストリームをセグメント化する。メディアファイルは、ほぼ等しい期間を伴うオリジナルストリームの一部分である。又、サーバーは、メディアファイルごとにURIを生成する。これらのURIは、クライアント装置がメディアファイルにアクセスできるようにする。セグメントは、本来的に全ファイルを配信するHTTPサーバーを使用してサービスされるので、サーバーは、クライアントにサービスできるまでに完全なセグメント化メディアファイルが得られねばならない。従って、クライアントは、少なくとも1つのメディアファイル長さだけ放送が時間的に遅れることがある。一実施形態において、メディアファイルサイズは、時間の遅れとファイル数が多過ぎることとのバランスに基づいたものになる。一実施形態では、2つのセッション形式生のセッション及びイベントセッションがサポートされる。生のセッションでは、ストリームの固定サイズ部分だけが保存される。一実施形態では、時代遅れのコンテンツメディアファイルが番組プレイリストファイルから除去され、そしてサーバーからも除去される。第2の形式のセッションは、クライアントが放送の任意のポイントへ同調できる例えば、初めからスタートするか、中間点からスタートするイベントセッションである。この形式のセッションは、例えば、再放送に使用することができる。オペレーション230では、メディアファイルがサーバーメモリに記憶される。メディアファイルは、オペレーション230において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。メディアファイルは、サーバー装置においてウェブサーバーアプリケーションによりサポートされる又は送信を行う別の装置によりサポートされるネットワークプロトコル例えば、HTTP又はHTTPSを使用して送信の準備ができたファイルとして記憶される。オペレーション240において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、拡張型M3Uタグ及びここに述べるタグを使用して、クライアント装置がメディアファイルにアクセスしてそれを再アッセンブルし、クライアント装置にストリーミング経験を与えるための情報を発生できるようにする。各メディアファイルのURIは、メディアファイルを再生すべき順序でプレイリストファイルに含まれる。又、サーバーは、クライアント装置がプレイリストファイルにアクセスできるようにプレイリストファイルの1つ以上のURIを生成することもできる。オペレーション250において、プレイリストファイルをサーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Aにおいて、特定の順序で提示されるが、異なる順序を使用してもよい。例えば、プレイリストファイルは、メディアファイルが生成され又は記憶される前に生成されてもよい。別の例として、プレイリストファイル及びメディアファイルは、そのいずれかが記憶される前に生成される。メディアファイルを暗号化すべき場合には、プレイリストファイルは、許可されたクライアント装置がメディアファイル解読のための暗号キーを含むキーファイルを得ることができるようにするURIを定義することができる。暗号キーは、セキュアな接続例えば、HTTPSを使用して送信することができる。別の例として、プレイリストファイルは、HTTPSを使用して送信することができる。更に別の例として、メディアファイルは、クライアントがプレイリストファイルなしにストリームを再生成できないように予想不能な順序で配列することができる。暗号化方法がAES-128である場合には、例えば、AES-128CBC暗号化が個々のメディアファイルに適用される。一実施形態において、ファイル全体が暗号化される。一実施形態では、暗号ブロックチェーンが、通常、メディアファイルにわたって適用されない。メディアファイルのシーケンスが、上述したように、IVとして使用される。一実施形態では、サーバーは、キーURIを伴うEXT-X-KEYタグをプレイリストファイルの終わりに追加する。次いで、サーバーは、暗号構成に変更がなされるまで、全ての後続メディアファイルをそのキーで暗号化する。新たな暗号キーへスイッチするために、サーバーは、提示に使用された全ての以前のキーURIとは個別の新たなURIを経て新たなキーを利用できるようにする。又、サーバーは、プレイリストファイルの終わりに新たなキーURIを伴うEXT-X-KEYタグも追加し、そしてその新たなキーで全ての後続メディアファイルを暗号化する。暗号化を終了するために、サーバーは、プレイリストファイルの終わりに暗号化方法NONEを伴うEXT-X-KEYタグを追加することができる。このタグNONEを方法として伴うは、一実施形態では、URIパラメータを含まない。全ての後続メディアファイルは、上述したように暗号構成に変更がなされるまで、暗号化されない。サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルに対するURIを含む場合には、EXT-X-KEYタグをプレイリストファイルから除去しない。サーバーは、図3Aを参照して詳細に述べるように、オペレーション270において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。一実施形態において、サーバーは、プレイリストファイルについての要求をクライアント装置から受け取るのに応答してクライアント装置へプレイリストファイルを送信する。クライアント装置は、クライアント装置に与えられたURIを使用してプレイリストファイルにアクセスし/それを要求することができる。URIは、サーバーにおけるプレイリストファイルの位置を指示する。それに応答して、サーバーは、プレイリストファイルをクライアント装置へ与えることができる。クライアント装置は、プレイリストファイルにおけるタグ及びURI又は他の識別子を使用して、複数のメディアファイルにアクセスすることができる。一実施形態において、サーバーは、メディアファイルの利用性を、プレイリストファイルに最新に追加されたものに限定することができる。これを行うために、各プレイリストファイルは、1つのEXT-X-MEDIA-SEQUENCEタグしか含むことができず、そしてメディアファイルURIがプレイリストファイルから除去されるたびに値を1だけインクリメントすることができる。メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去することができる。一実施形態において、サーバーがプレイリストファイルからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間と、メディアファイルが現れた最も長いプレイリストファイルの期間との和に等しい期間中、クライアントに利用可能なままとなる。プレイリストファイルの期間は、そのプレイリストファイル内のメディアファイルの期間の和である。又、他の期間を使用することもできる。一実施形態において、サーバーは、EXT-X-ENDLISTタグが存在しない限り、少なくとも3つの主提示のメディアファイルを常にプレイリストに維持することができる。図2Bは、1つ以上のサーバー装置が1つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。プレイリストは、ここに述べる累積モード又はローリングモードのいずれかを使用して更新することができる。図2Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコル例えば、HTTPS、等も、同様に使用することができる。図2Bの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。サーバー装置は、オペレーション205において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション215において、コンテンツの少なくとも一部分を一時的に記憶する。オペレーション215は、図2Aのオペレーション210と同様である。与えられるべきコンテンツは、オペレーション225において、複数のメディアファイルへとセグメント化される。メディアファイルは、オペレーション235においてサーバーメモリに記憶することができる。メディアファイルは、オペレーション235において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。オペレーション245において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、オペレーション255において、サーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Bでは特定の順序で表されるが、異なる順序が使用されてもよい。サーバー又は別のサーバーは、図3A-3Bを参照して詳細に述べるように、オペレーション275において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。プレイリストファイルは、種々の理由で、サーバーによって更新される。サーバーは、オペレーション285において、クライアント装置に与えられるべき付加的なデータを受け取ることができる。付加的なデータは、オペレーション255においてプレイリストファイルが記憶された後に受け取ることができる。付加的なデータは、例えば、生の提示の付加的な部分、又は既存の提示の付加的な部分である。付加的なデータは、広告又は統計情報例えば、スポーツ行事に関するスコア又はデータを含む。又、付加的なデータは、提示上に半透明体を通してオーバーレイすることもできるし、又はサイドバーユーザインターフェイスに提示することもできる。付加的なデータは、最初に受け取られたデータと同様に、セグメント化することができる。付加的なデータが、広告を構成するか、又はプレイリストにより表された番組に挿入されるべき他のコンテンツを構成する場合には、付加的なデータは、オペレーション215において少なくとも一時的に記憶することができ、オペレーション225においてセグメント化することができ、そしてオペレーション235において記憶することができ、又、セグメント化された付加的なデータを記憶する前に、付加的なデータのセグメントを暗号化することができる。次いで、オペレーション245において、番組及び付加的なデータを含む更新されたプレイリストが発生される。そのプレイリストは、オペレーション255において、付加的なデータに基づいて更新されて、再び記憶される。プレイリストファイルに対する変更は、クライアント装置の観点から原子的に行わねばならない。更新されたプレイリストは、一実施形態では、以前のプレイリストに置き換わる。以下に詳細に述べるように、クライアント装置は、プレイリストを何回も要求することができる。これらの要求は、クライアント装置が最新のプレイリストを利用できるようにする。一実施形態では、付加的なデータがメタデータであり、この場合、プレイリストは、更新する必要がないが、セグメントは、メタデータを含むように更新することができる。例えば、メタデータは、セグメントのタイムスタンプと一致させることのできるタイムスタンプを含み、そしてメタデータは、一致するタイムスタンプを有するセグメントに追加することができる。又、更新されたプレイリストは、メディアファイルの除去を生じてもよい。一実施形態では、サーバーは、プレイリストから、メディアファイルに対し、URIを、それらがプレイリストに追加された順序で除去しなければならない。一実施形態では、サーバーは、全提示を除去する場合に、プレイリストファイルをクライアント装置に利用できなくする。一実施形態では、サーバーは、メディアファイル及びプレイリストファイルを、除去されるべきメディアファイルを含む最長のプレイリストファイルの期間中維持して、現在のクライアント装置が提示へのアクセスを終了できるようにする。従って、プレイリストファイルにおける各メディアファイルURIの前には、プレイリストファイルにより指示されるメディアファイルのおおよその累積的期間を指示するためにEXT-X-STREAM-INFタグを設けることができる。別の実施形態では、メディアファイル及びプレイリストファイルは、直ちに除去されてもよい。クライアント装置からのプレイリストに対するその後の要求の結果、オペレーション275において、サーバーが更新されたプレイリストを与える。一実施形態では、プレイリストは、規則的に更新され、例えば、ターゲット期間に関連した時間周期で更新される。プレイリストファイルの周期的な更新は、サーバーが、動的に変化する提示へのアクセスを与えることができるようにする。図2Cは、1つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートであり、これは、代替えストリームを使用する1つの形態である。図2Cの例は、HTTPに関して示すが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Cの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。一実施形態では、サーバーは、複数のプレイリストファイルを提供するか、又は単一のプレイリストファイルに複数のメディアファイルリストを伴う単一のプレイリストファイルを提供して、同じ提示の異なるエンコーディングを与えることができる。異なるエンコーディングが与えられる場合には、プレイリストファイルは、異なるビットレートを与える各変形ストリームを含み、クライアント装置がエンコーディング間を動的にスイッチできるようにする図9A-9Dを参照して更に説明する。変形ストリームを有するプレイリストファイルは、変形ストリームごとにEXT-X-STREAN-INFタグを含むことができる。同じ提示に対する各EXT-X-STREAN-INFタグは、同じPROGRAM-ID属性値をもつことができる。各提示のPROGRAM-ID値は、変形ストリーム内で独特である。一実施形態では、サーバーは、変形ストリームを発生するときに次の制約を満足する。各変形ストリームは、主提示の一部分ではない任意のコンテンツを含む同じコンテンツで構成することができる。サーバーは、ストリームの最小ターゲット期間の精度内で全ての変形ストリームに対して同じコンテンツ周期を利用できるようにする。変形ストリームのメディアファイルは、一実施形態では、全ての変形ストリームにおける対応コンテンツに対して一致するサンプルタイムスタンプを伴うMPEG-2トランスポートストリーム、又はMPEG-2番組ストリームのいずれかである。又、一実施形態では、全ての変形ストリームは、同じオーディオエンコーディングを含む。これは、クライアント装置がコンテンツを失うことなく変形ストリーム間でスイッチできるようにする。図2Cを参照すれば、サーバー装置は、オペレーション202において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション212において、コンテンツを少なくとも一時的に記憶する。与えられるべきコンテンツは、オペレーション222において、複数のメディアファイルへとセグメント化される。各メディアファイルは、オペレーション232において、選択されたビットレート又は他のエンコーディングパラメータの選択された値についてエンコードされ、そしてサーバーに記憶される。例えば、メディアファイルは、高、中間及び低帯域巾接続についてターゲットが決められる。メディアファイルは、記憶の前に暗号化することができる。種々の形式の接続についてターゲットが決められたメディアファイルのエンコーディングは、ターゲット帯域巾レベルにおいてストリーミング経験を与えるように選択される。一実施形態では、オペレーション242において、種々のエンコーディングレベルを指示するここに述べるタグを伴う変形プレイリストが発生される。タグは、例えば、対応するメディアプレイリストファイルに対するURIを伴うエンコーディングレベルごとのEXT-X-STREAN-INFタグである。この変形プレイリストは、種々のエンコーディングレベルについてメディアプレイリストファイルに対するURIを含むことができる。従って、クライアント装置は、エンコーディングレベルを指示する変形プレイリストに与えられた代替え物からターゲットビットレートを選択し、そしてそれに対応するプレイリストファイルを検索することができる。一実施形態では、クライアント装置は、再生中にビットレート間を切り換えることができる図9A-9Dを参照して述べるように。種々のエンコーディングレベルを指示する変形プレイリストは、オペレーション252において、サーバーに記憶される。オペレーション242では、変形プレイリストにおいて参照されるプレイリストの各々を発生し、オペレーション252においてそれを記憶することができる。クライアント装置からの要求に応答して、サーバーは、オペレーション272において、種々のエンコーディングレベルを指示する変形プレイリストを送信することができる。サーバーは、オペレーション282において、選択されたビットレートに対応する変形プレイリストにおいて特定されたメディアプレイリストの1つに対する要求を受け取る。この要求に応答して、サーバーは、オペレーション292において、クライアント装置からの要求に対応するメディアプレイリストファイルを送信する。次いで、クライアント装置は、メディアプレイリストを使用して、サーバーからのメディアファイルを要求する。サーバーは、オペレーション297において、それらの要求に応答してクライアント装置へメディアファイルを与える。図3Aは、クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Aの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。図3A-3Bに示す方法は、1つのクライアント装置又は複数の別々のクライアント装置により遂行することができる。例えば、これら方法のいずれか1つの場合に、単一のクライアント装置が、全てのオペレーション例えば、プレイリストファイルを要求し、プレイリストファイルのURIを使用してメディアファイルを要求し、提示/出力の発生及び供給のためにメディアファイルをアッセンブルするを遂行するか、或いは複数の個別のクライアント装置が、全部ではなく幾つかのオペレーションを遂行する例えば、第1のクライアント装置が、プレイリストファイルを要求し、そのプレイリストファイルのURIを使用してメディアファイルを要求し、そしてそれらのメディアファイルを第2のクライアント装置により使用するために記憶し、第2のクライアント装置は、メディアファイルを処理して、提示/出力を発生及び供給することができる。クライアント装置は、オペレーション300において、サーバーからプレイリストファイルを要求する。一実施形態では、この要求は、HTTP適合のプロトコルに基づいて行われる。この要求は、サーバーに記憶された初期プレイリストファイルに対するURIを使用する。別の実施形態では、他の非ストリーミングプロトコルをサポートすることもできる。この要求に応答して、サーバーは、それに対応するプレイリストファイルを、ネットワークを経てクライアントへ送信する。上述したように、ネットワークは、ワイヤード又はワイヤレスであり、又、ワイヤード又はワイヤレスネットワークの組み合わせでもよい。更に、ネットワークは、データネットワーク例えば、IEEE802.11、IEEE802.16でもよいし、セルラー電話ネットワーク例えば、3Gでもよい。クライアント装置は、オペレーション310において、プレイリストファイルを受け取ることができる。プレイリストファイルは、オペレーション320において、クライアント装置のメモリに記憶することができる。メモリは、例えば、ハードディスク、フラッシュメモリ、ランダムアクセスメモリである。一実施形態では、プレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、クライアントは、プレイリストファイルがEXTM3Uタグで始まり、そしてタグが存在しない場合には継続しないことを決定するためのチェックを行う。上述したように、プレイリストファイルは、1つ以上のタグと、メディアファイルに対する1つ以上のURIとを含む。クライアント装置は、オペレーション330において、プレイリストファイルのURIにより指示されたメディアファイルを要求することによりプレイリストファイルを使用してオリジナルコンテンツを再アッセンブルするアッセンブラーエージェントを含むことができる。一実施形態では、このアッセンブラーエージェントは、標準ウェブブラウザアプリケーションの一部分であるプラグインモジュールである。別の実施形態では、アッセンブラーエージェントは、ウェブブラウザと対話し、プレイリストファイルを使用してメディアファイルを受け取りアッセンブルするスタンドアローンアプリケーションでもよい。更に別の例として、アッセンブラーエージェントは、クライアント装置に埋め込まれる特殊目的のハードウェア又はファームウェアコンポーネントでもよい。このアッセンブラーは、プレイリストファイルからのメディアファイルを、URIにより指示されたサーバーからダウンロードさせる。プレイリストファイルがEXT-X-ENDLISTタグを含む場合には、プレイリストファイルにより指示されたメディアファイルが最初に再生される。EXT-X-ENDLISTタグが存在しない場合には、最後と最後から2番目のメディアファイルを除くメディアファイルが最初に再生される。再生すべき最初のメディアファイルが選択されると、プレイリストファイルにおける後続メディアファイルは、一実施形態では、それらがプレイリストファイルに現れる順序でロードされるさもなければ、コンテンツは、無秩序に提示される。一実施形態では、クライアント装置は、中断のない再生を与えると共にネットワークの待ち時間及びスループットの時間的変化を補償するために、メディアファイルが要求される以前にそれらをロードするそしてそれらをバッファに記憶するように試みる。ダウンロードされたメディアファイルは、オペレーション340において、クライアント装置のメモリに記憶することができる。コンテンツを記憶することのできるメモリは、クライアント装置における任意の形式のメモリであり、例えば、ランダムアクセスメモリ、ハードディスク又はビデオバッファである。記憶は、再生を許すために一時的でもよいし、又は永久的でもよい。プレイリストファイルがEXT-X-ALLOW-CACHEタグを含み、その値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後は、記憶しない。プレイリストがEXT-X-ALLOW-CACHEタグを含み、その値がYESである場合には、クライアントは、メディアファイルを、後で再生するために不定に記憶する。クライアント装置は、EXT-X-PROGRAM-DATE-TIMEタグの値を使用して、番組起点時間をユーザに表示する。一実施形態では、クライアントは、複数のメディアファイルをバッファして、ネットワークジッタの影響を受け難くし、良好なユーザ経験を与えることができるようにする。一実施形態において、解読方法がAES-128である場合に、AES-128CBC解読が個々のメディアファイルに適用される。ファイル全体が解読される。一実施形態では、メディアファイルにわたって暗号ブロックチェーンが適用されない。メディアファイルのシーケンス番号は、上述したように初期化ベクトルとして使用することができる。メモリからのコンテンツは、オペレーション350において、クライアント装置から出力することができる。出力又は提示は、例えば、内蔵スピーカ又はヘッドホンを経て出力されるオーディオである。出力は、スクリーンを経て出力されるか又はクライアント装置から投影されるビデオを含む。この技術で知られた任意の形式の出力を使用することができる。オペレーション351において、クライアント装置は、記憶された現在プレイリストに再生も提示もされていないメディアファイルがもっとあるかどうか決定する。そのようなメディアファイルが存在する且つそれらが要求されていない場合には、1つ以上のメディアファイルが要求されるオペレーション330へ処理が復帰し、プロセスが繰り返される。このようなメディアファイルがない即ち、現在プレイリストにおける全てのメディアファイルが再生されている場合には、処理がオペレーション352へ進み、これは、プレイリストファイルが終了タグを含むかどうか決定する。オペレーション352において、プレイリストが終了タグ例えば、EXT-X-ENDLISTを含む場合には、プレイリストファイルにより指示されたメディアファイルが再生されたときに再生が終わる。終了タグがプレイリストにない場合には、クライアント装置は、サーバーからプレイリストを再び要求し、そしてオペレーション300へ復帰して、番組のための更に別の又は更新されたプレイリストを得る。図2Bを参照して詳細に説明したように、サーバーは、補足的コンテンツ例えば、生放送における付加的なメディアコンテンツに対応する付加的なメディアファイル識別子又は付加的なコンテンツ例えば、ストリームの更に下流のコンテンツを導入するためにプレイリストファイルを更新する。この補足的コンテンツ又は付加的なコンテンツにアクセスするために、クライアントは、更新されたプレイリストをサーバーから再ロードすることができる。これは、プレイリストファイルに関連したメディアコンテンツの再生中でも、プレイリストファイルを動的に更新できるメカニズムを与える。クライアントは、多数のトリガーに基づいてプレイリストファイルの再ロードを要求する。終了タグの欠如は、1つのこのようなトリガーである。一実施形態では、クライアント装置は、プレイリストファイルがEXT-X-ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードする。クライアント装置が、プレイリストファイルを初めてロードするとき、又はプレイリストファイルを再ロードしそしてそれが前回ロードされて以来変化したことが分かったときには、クライアントは、再びプレイリストファイルを再ロードするよう試みる前に、ある時間周期待機することができる。この周期は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのロードを開始する時間から測定される。一実施形態では、初期最小再ロード遅延は、プレイリストファイルにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある時間周期待機することができる。一実施形態における最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。一実施形態では、この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0であるが、他の倍数が使用されてもよい。プレイリストファイルがロード又は再ロードされるたびに、クライアント装置は、プレイリストファイルを検査して、ロードすべき次のメディアファイルを決定する。ロードすべき第1のファイルは、上述したように、最初に再生するように選択されたメディアファイルである。再生されるべき第1のメディアファイルがロードされ、そしてプレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証することができ、ファイルが見つからない場合には再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIである。再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものである。プレイリストファイルが、キーファイルURIを特定するEXT-X-KEYタグを含む場合には、クライアント装置は、キーファイルを得、そしてキーファイル内のキーを使用して、別のEXT-X-KEYタグに遭遇するまで、そのEXT-X-KEYタグに続くメディアファイルを解読する。一実施形態では、クライアント装置は、以前に使用した同じURIを使用して、プレイリストファイルをダウンロードする。従って、プレイリストファイルに変更がなされた場合には、クライアント装置は、更新されたプレイリストファイルを使用して、メディアファイルを検索し、そしてそのメディアファイルに基づいて出力を与える。プレイリストファイルの変更は、例えば、メディアファイルに対するURIの削除、新たなメディアファイルに対するURIの追加、置き換えメディアファイルに対するURIの置き換えを含む。プレイリストファイルに変更がなされるときには、その変更を反映するように1つ以上のタグが更新される。例えば、メディアファイルの変更で、プレイリストファイルによって指示されるメディアファイルの再生の期間に変更が生じる場合には、期間タグが更新される。図3Bは、クライアント装置が、代替えストリームの一形態である複数のビットレートを使用するコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。オペレーション370において、クライアント装置は、プレイリストファイルを要求することができる。上述したように、プレイリストファイルは、クライアント装置に与えられるURIを使用して検索される。一実施形態では、プレイリストファイルは、同じコンテンツを異なるビットレートで与えるためにメディアファイルの変形ストリームのリストを含み、換言すれば、単一のプレイリストファイルは、各変形ストリームのメディアファイルに対するURIを含む。図3Bに示す例は、この実施形態を使用する。別の実施形態では、変形ストリームは、クライアントに別々に与えられる複数の個別のプレイリストファイルにより、その各々が同じコンテンツを異なるビットレートで与えるように表され、そして変形プレイリストは、個別のプレイリストファイルの各々に対してURIを与えることができる。これは、クライアント装置がクライアントの条件に基づいてビットレートを選択できるようにする。オペレーション375において、プレイリストファイルは、クライアント装置によって検索することができる。オペレーション380において、プレイリストファイルは、クライアント装置のメモリに記憶することができる。クライアント装置は、オペレーション385において、使用すべきビットレートを、現在ネットワークの接続速度に基づいて選択する。メディアファイルは、オペレーション390において、選択されたビットレートに対応するプレイリストファイルに含まれたURIを使用してサーバーから要求される。検索されたメディアファイルは、クライアント装置のメモリに記憶することができる。出力は、オペレーション394において、メディアファイルを使用してクライアント装置により与えられ、そしてクライアント装置は、ビットレートを変更すべきかどうか決定する。一実施形態において、クライアント装置は、最初に利用可能な最低ビットレートを選択する。メディアを再生する間に、クライアント装置は、利用可能な帯域巾例えば、現在ネットワークの接続ビットレートを監視して、その利用可能な帯域巾が再生のためにより高いビットレートの使用をサポートできるかどうか決定することができる。もしそうであれば、クライアント装置は、より高いビットレートを選択し、そしてより高いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。その逆をサポートすることもできる。再生が著しい帯域巾を消費する場合には、クライアント装置は、より低いビットレートを選択し、そしてより低いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。クライアント装置が、オペレーション394において、例えば、利用可能な帯域巾の変更に応答し又はユーザ入力に応答して、ビットレートを変更する場合には、クライアント装置は、オペレーション385において、異なるビットレートを選択することができる。一実施形態では、異なるビットレートを選択するために、クライアント装置は、新たに選択されたビットレートに対応するプレイリストファイルに含まれたURIの異なるリストを利用することができる。一実施形態では、クライアント装置は、プレイリスト内のメディアファイルのアクセス中にビットレートを変更することができる。オペレーション394においてビットレートが変更されない場合に、クライアント装置は、検索及び提示されていない未再生のメディアファイルが現在プレイリストにもっとあるかどうか決定する。そのようなメディアファイルが存在する場合には、処理がオペレーション390へ復帰し、そしてプレイリストにおけるそれらのファイルに対するURIを使用して1つ以上のメディアファイルが検索される。そのようなメディアファイルがない即ち、現在プレイリストにおける全てのメディアファイルが再生された場合には、処理がオペレーション396へ進み、プレイリストが終了タグを含むかどうか決定される。もしそうであれば、番組の再生が終了で、プロセスが完了であるが、もしそうでなければ、処理がオペレーション370へ復帰し、クライアント装置は、番組に対するプレイリストを再ロードすることを要求し、図3Bに示す方法を通してプロセスが繰り返される。図4は、サーバーストリームエージェントの一実施形態のブロック図である。サーバーストリームエージェント400の要素は、多数のサーバー装置にわたって分散できることを理解されたい。例えば、第1のサーバー装置は、セグメンタ430、インデクサ440及びセキュリティ450を含むが、ファイルサーバー460は含まず、又、第2のサーバー装置は、ファイルサーバー450を含むが、セグメンタ430、インデクサ440及びセキュリティ450は含まない。この例では、第1のサーバー装置は、プレイリスト及びメディアファイルを準備するが、それらをクライアント装置へ送信せず、一方、1つ以上の第2のサーバー装置は、プレイリスト及びメディアファイルを受け取って任意に記憶し、そしてプレイリスト及びメディアファイルをクライアント装置へ送信する。サーバーストリームエージェント400は、サーバーストリームエージェント400のオペレーションを指令する論理機能制御を具現化する制御ロジック410と、サーバーストリームエージェント400のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路、又はソフトウェアルーチン、又はファームウェアである。一実施形態では、サーバーストリームエージェント400は、制御ロジック410にインストラクションを与えるコードシーケンス及び/又はプログラムを表す1つ以上のアプリケーション412を備えている。サーバーストリームエージェント400は、データ又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ414を備えている。このメモリ414は、サーバーストリームエージェント400に対してローカルのメモリを含んでもよいし、或いは又サーバーストリームエージェント400が存在するホストシステムのメモリを含んでもよい。又、サーバーストリームエージェント400は、サーバーストリームエージェント400の外部のエンティティ電子装置又は人間に関してサーバーストリームエージェント400への/からのアクセスインターフェイス入力/出力インターフェイスを表す1つ以上のインターフェイス416も備えている。又、サーバーストリームエージェント400は、サーバーストリームエージェント400がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すサーバーストリームエンジン420も備えている。図4の例は、サーバーストリームエンジン420に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、セグメンタ430、インデクサ440、セキュリティ450、及びファイルサーバー460を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。セグメンタ430は、与えられるべきコンテンツを、ウェブサーバープロトコル例えば、HTTPを使用してファイルとして送信できるメディアファイルへと分割する。例えば、セグメンタ430は、コンテンツを、所定のファイルフォーマットにおける所定の固定サイズのデータブロックへと分割する。インデクサ440は、セグメンタ430によって生成されるメディアファイルに対するURI又はアドレスを与える1つ以上のプレイリストファイルを発生する。インデクサ440は、例えば、セグメンタ430により生成される各ファイルに対応する識別子のための順序のリストを伴う1つ以上のファイルを生成する。それら識別子は、セグメンタ430又はインデクサ440によって生成され又は指定される。又、インデクサ440は、メディアファイルのアクセス及び/又は利用をサポートするためにプレイリストファイルに1つ以上のタグを含むこともできる。セキュリティ450は、上述したようなセキュリティ特徴例えば、暗号化を与えることができる。ウェブサーバー460は、ホストシステムに記憶されたファイルをリモートクライアント装置に与えることに関連したウェブサーバー機能を発揮する。ウェブサーバー460は、例えば、HTTP適合のプロトコルをサポートする。図5は、クライアントストリームエージェントの一実施形態のブロック図である。クライアントストリームエージェントの要素は、多数のクライアント装置にわたって分散できることを理解されたい。例えば、第1のクライアント装置は、アッセンブラー530及びセキュリティ550を備え、そしてメディアファイルの解読されたストリームを第2のクライアント装置へ供給することができ、この第2のクライアント装置は、出力ジェネレータ540を含むが、アッセンブラー530及びセキュリティ550は含まない。別の例では、一次クライアント装置がプレイリストを検索してそれを二次クライアント装置へ供給することができ、この二次クライアント装置は、プレイリストにおいて特定されたメディアファイルを検索して、それらメディアファイルを提示するための出力を発生する。クライアントストリームエージェント500は、このクライアントストリームエージェント500のオペレーションを指令するための論理機能的制御を具現化する制御ロジック510と、このクライアントストリームエージェント500のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路或いはソフトウェアルーチン又はファームウェアでよい。一実施形態では、クライアントストリームエージェント500は、制御ロジック510にインストラクションを与えるコードシーケンス又はプログラムを表す1つ以上のアプリケーション512を備えている。クライアントストリームエージェント500は、データ及び/又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ514を備えている。このメモリ514は、クライアントストリームエージェント500に対してローカルのメモリを含んでもよいし、或いは又クライアントストリームエージェント500が存在するホストシステムのメモリを含んでもよい。又、クライアントストリームエージェント500は、クライアントストリームエージェント500の外部のエンティティ電子装置又は人間に関してクライアントストリームエージェント500への/からのアクセスインターフェイス入力/出力インターフェイスを表す1つ以上のインターフェイス516も備えている。又、クライアントストリームエージェント500は、このクライアントストリームエージェント500がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すクライアントストリームエンジン520も備えている。図5の例は、クライアントストリームエンジン520に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、アッセンブラー530、出力ジェネレータ540、及びセキュリティ550を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。アッセンブラー530は、サーバーから受け取られたプレイリストファイルを使用して、サーバーからウェブサーバープロトコル例えば、HTTPを経てメディアファイルにアクセスすることができる。一実施形態では、アッセンブラー530は、プレイリストファイルにおいてURIにより指示されたメディアファイルをダウンロードさせる。アッセンブラー530は、プレイリストファイルに含まれたタグに応答する。出力ジェネレータ540は、受け取ったメディアファイルをホストシステムにおいてオーディオ又はビジュアル出力又はオーディオ及びビジュアルの両方として発生する。出力ジェネレータ540は、例えば、オーディオを1つ以上のスピーカへ出力させそしてビデオをディスプレイ装置へ出力させる。セキュリティ550は、上述したようなセキュリティ特徴を与える。図6は、複数のタグを伴うプレイリストファイルの一実施形態を示す図である。図6の規範的なプレイリストは、特定数及び順序のタグを含む。これは、説明上のものに過ぎない。あるプレイリストファイルは、より多くの又はより少ない、或いは異なる組み合わせのタグを含み、そしてタグは、図6に示すものとは異なる順序で配列することができる。開始タグ610は、プレイリストファイルの開始を指示することができる。一実施形態において、開始タグ610は、EXTM3Uタグである。期間タグ620は、再生リストの期間を指示することができる。即ち、再生リスト600により指示されるメディアファイルの再生の期間である。一実施形態において、期間タグ620は、EXT-X-TARGETDURATIONタグであるが、他のタグも使用できる。日付/時刻タグ625は、再生リスト600により指示されたメディアファイルにより与えられるコンテンツの日付及び時刻に関連した情報を与えることができる。一実施形態では、日付/時刻タグ625は、EXT-X-PROGRAM-DATE-TIMTタグであるが、他のタグを使用することもできる。シーケンスタグ630は、プレイリストのシーケンスにおけるプレイリストファイル600のシーケンスを指示することができる。一実施形態では、シーケンスタグ630は、EXT-X-MEDIA-SEQUENCEタグであるが、他のタグも使用できる。セキュリティタグ640は、プレイリストファイル600により指示されたメディアファイルに適用されるセキュリティ及び/又は暗号化に関連した情報を与えることができる。例えば、セキュリティタグ640は、メディアファイルインジケータにより特定されたファイルを解読するための解読キーを特定することができる。一実施形態では、セキュリティタグ640は、EXT-X-KEYタグであるが、他のタグを使用することもできる。変形リストタグ645は、変形ストリームがプレイリスト600により与えられるかどうか指示すると共に、変形ストリームに関する情報例えば、どれほど多く、ビットレートを指示することができる。一実施形態では、変形リストタグ645は、EXT-X-STREAM-INFタグである。メディアファイルインジケータ650は、再生されるべきメディアファイルに関する情報を与えることができる。一実施形態では、メディアファイルインジケータ650は、再生されるべき複数のメディアファイルに対するURIを含む。又、一実施形態では、プレイリスト600におけるURIの順序は、メディアファイルにアクセスし及び/又は再生しなければならない順序に対応する。その後のプレイリストインジケータ660は、再生ファイル600の後に使用されるべき1つ以上の再生ファイルに関連した情報を与えることができる。一実施形態では、その後のプレイリストインジケータ660は、プレイリスト600のメディアファイルが再生された後に使用されるべき1つ以上のプレイリストファイルに対するURIを含むことができる。メモリタグ670は、メディアファイルコンテンツの再生後にクライアント装置がメディアファイルを記憶できるかどうか及び/又はどれほど長く記憶できるか指示することができる。一実施形態では、メモリタグ670は、EXT-X-ALLOW-CACHEタグである。終了タグ680は、プレイリストファイル600が提示のための最後のプレイリストファイルであるかどうか指示する。一実施形態では、終了タグ680は、EXT-X-ENDLISTタグである。次の章は、一実施形態による幾つかの規範的なプレイリストファイルを含む。簡単なプレイリストファイルEXTM3UEXTXTARGETDURATION10EXTINF5220httpmediaexamplecomentiretsEXTXENDLISTHTTPSを使用するスライディングウインドウプレイリストEXTM3UEXTXTARGETDURATION8EXTXMEDIASEQUENCE2680EXTINF8httpsprivexamplecomfileSequence2680tsEXTINF8httpsprivexamplecomfileSequence2681tsEXTINF8httpsprivexamplecomfileSequence2682ts暗号化されたメディアファイルを伴うプレイリストファイルEXTM3UEXTXMEDIASEQUENCE7794EXTXTARGETDURATION15EXTXKEYMETHODAES128URIhttpsprivexamplecomkeyphpr52EXTINF15httpmediaexamplecomfileSequence7794tsEXTINF15httpmediaexamplecomfileSequence7795tsEXTINF15httpmediaexamplecomfileSequence7796tsEXTXKEYMETHODAES128URIhttpsprivexamplecomkeyphpr53EXTINF15httpmediaexamplecomfileSequence7797ts変形プレイリストファイルEXTM3UEXTXSTREAMINFPROGRAMID1BANDWIDTH1280000httpexamplecomlowm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH2560000httpexamplecommidm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH7680000httpexamplecomhim3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH65000CODECSmp4a405httpexamplecomaudioonlym3u8図7は、ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。一実施形態において、受け取られたメディアファイルの再生は、スタート、ストップ、巻き戻し、等のためにユーザにより制御することができる。プレイリストファイルは、オペレーション700において、クライアント装置により受け取られる。オペレーション710において、プレイリストファイルにより指示されたメディアファイルが検索される。オペレーション720において、受け取られたメディアファイルに基づいて出力が発生される。メディアファイルの受け取り及びそのメディアファイルに基づく出力の発生は、上述したように行うことができる。オペレーション730において制御入力が検出された場合には、クライアント装置は、オペレーション740において入力がストップを指示するかどうか決定することができる。入力がストップである場合には、プロセスが終了となり、再生がストップする。オペレーション750において入力が巻き戻し又は送り要求を指示する場合には、クライアント装置は、オペレーション760において、メモリにまだ記憶されている以前に再生されたメディアファイルに基づいて出力を発生することができる。これらファイルがキャッシュにもはやない場合には、処理がオペレーション710へ復帰し、メディアファイルを検索してプロセスを繰り返す。別の実施形態では、再生は、ストップ入力のような再生の終了を伴わずに再生をハルトする休止特徴をサポートすることができる。あるストリームから別のストリームへ遷移させる方法を、図9A-9Dを参照して詳細に説明する。1つのクライアント装置でこれらの方法の各々を遂行することもできるし、又はこれら方法各々のオペレーションを、ここに述べる複数のクライアント装置にわたって分散させることもでき、例えば、分散させる場合には、1つのクライアント装置が変形プレイリスト及び2つのメディアプレイリストを検索しそしてそれらを別のクライアント装置に与えることができ、その別のクライアント装置が、2つのメディアプレイリストで特定されたメディアファイルを検索し、そしてその検索されたメディアファイルにより与えられる2つのストリーム間をスイッチすることができる。又、別の実施形態では、図示されたオペレーションの順序を変更してもよいし、又はこれらの図面に示されたものより多くの又は少ないオペレーションが遂行されてもよいことも理解されよう。これらの方法は、変形プレイリストを使用して、異なるストリームを選択することができる。オペレーション901において変形プレイリストを検索し処理して、番組例えば、スポーツ行事のための利用可能なストリームを決定することができる。オペレーション910は、クライアント装置によって行うことができる。第1のストリームは、オペレーション903において変形プレイリストから選択することができ、次いで、クライアント装置は、第1のストリームのためのメディアプレイリストを検索することができる。クライアント装置は、オペレーション905において、第1のストリームに対するメディアプレイリストを処理し、そしてオペレーション907において、第1のストリームに対するネットワーク接続のビットレートを測定し、さもなければ、決定することができる。オペレーションのシーケンスは、図9Aに示されたものとは異なる順序で遂行されてもよく、例えば、オペレーション907は、オペレーション903の間に遂行されてもよく、等々であることが明らかであろう。オペレーション911において、クライアント装置は、オペレーション907からの測定されたビットレートに基づき変形プレイリストから代替えメディアプレイリストを選択し、この代替えメディアプレイリストは、第1のストリームの既存のビットレートより高い第2のビットレートでよい。これは、典型的に、代替えストリームが、第1のストリームより高い解像度を有することを意味する。代替えメディアプレイリストは、現在条件例えば、オペレーション907で測定されたビットレートに基づき第1のストリームに対する現在プレイリストより良好に一致する場合に選択することができる。オペレーション913において、代替えストリームに対する代替えメディアプレイリストが検索され処理される。これは、典型的に、クライアント装置が第1のストリーム及び代替えストリームの両方を受け取って処理し、従って、その両方を提示に利用でき、即ち一方を提示している間に、他方が処理の準備ができることを意味する。次いで、クライアント装置は、オペレーション915においてストリームのバージョン間をスイッチングする遷移ポイントを選択し、第1のストリームの提示を停止すると共に、代替えストリームの提示を開始する。このスイッチングをどのように遂行するかの例を、図9B-9Dを参照して示す。ある実施形態では、クライアント装置は、スイッチングを行う前に第1のストリームの受け取りを停止することができる。図9Bは、クライアント装置が、オペレーション921及び923において第1のメディアプレイリスト例えば、第1のストリームにより特定されたコンテンツを検索し、記憶し及び提示し、そして第1のプレイリストにより特定されたコンテンツが提示される間に、オペレーション925において、クライアント装置が、第2のメディアプレイリスト例えば、第2のストリームにより特定されたコンテンツを検索し及び記憶することを示している。第1のメディアプレイリストから得たコンテンツを提示している間に第2のメディアプレイリストにより特定されたコンテンツを検索し例えば、一時的バッファに記憶することで、番組コンテンツの時間的なオーバーラップ955図9Dに示すを生成し、これは、クライアント装置が、番組を実質的に中断せずに番組のバージョン間をスイッチングできるようにする。このように、番組のバージョン間のスイッチングは、多くの場合に、スイッチングが生じることをユーザに通知せずにある場合には、スイッチングの後の高解像度の画像にユーザが気付くことがあるが、又は番組提示の実質的な中断なしに、行うことができる。オペレーション927において、クライアント装置は、第1のメディアプレイリストにより特定されたコンテンツから第2のメディアプレイリストにより特定されたコンテンツへスイッチングすべき遷移点を決定し、遷移点の一例遷移点959が図9Dに示されている。第2のメディアプレイリストにより特定されたコンテンツは、スイッチングの後に、オペレーション931において提示される。図9C及び9Dに示す方法は、遷移点を決定するための一実施形態を表し、この実施形態は、遷移点を決定するために2つのストリーム951及び953からのオーディオサンプルに対するパターンマッチングに依存する。代替え実施形態は、ビデオサンプルに対するパターンマッチングを使用するか、又は2つのストリームのタイムスタンプ等を使用して、遷移点を決定できることが明らかであろう。この方法は、オペレーション941において、第1のメディアプレイリストにより特定されたコンテンツ例えば、ストリーム951をバッファに記憶することを含み、このバッファは、コンテンツの提示及びパターンマッチングオペレーションに使用することができる。ストリーム951は、オーディオサンプル951A及びビデオサンプル951Bの両方を含む。ビデオサンプルは、単一のビデオフレームを表示するのに必要な全てのコンテンツを有するiフレーム又はキーフレームに依存する圧縮技術を使用することができる。ストリーム951のコンテンツは、時間例えば、番組の開始から経過した時間を特定するタイムスタンプを含み、これらタイムスタンプは、各サンプルの開始例えば、各オーディオサンプル951Aの開始及び各ビデオサンプル951Bの開始をマークすることができる。あるケースでは、2つのストリーム間のタイムスタンプの比較は、遷移点を決定する上で有用ではない。というのは、それらが充分正確でないか、又は2つのストリームにおけるサンプルの境界に差があるためである。しかしながら、2つのストリーム間の時間的なオーバーラップ955があることを検証するために、タイムスタンプ範囲の比較を使用することができる。オペレーション943において、クライアント装置は、第2のメディアプレイリストにより特定されたコンテンツをバッファに記憶し、このコンテンツは、第1のメディアプレイリストから得られたコンテンツと同じ番組に対するものであり、これもタイムスタンプを含むことができる。一実施形態において、タイムスタンプは、ストリームに存在しない場合には、ストリームのためのプレイリストに追加することができ、例えば、一実施形態では、1つ以上のタイムスタンプを含むID3タグを、変形プレイリスト又はメディアプレイリストのようなプレイリストのエントリに追加することができる。このエントリは、例えば、オーディオストリームの第1サンプルに対するURIである。図9Dは、第2のメディアプレイリストから得られたコンテンツ953の一例を示し、これは、オーディオサンプル953A及びビデオサンプル953Bを含む。オペレーション945において、クライアント装置は、2つのストリーム951及び953のオーディオサンプルに対してパターンマッチングを遂行して、オーバーラップ955から遷移点959を選択することができ、これは、一実施形態では、一致したオーディオセグメント例えば、セグメント957の後の次の自蔵型ビデオフレーム例えば、iフレーム961である。iフレーム961及びそれに関連したオーディオサンプルで始めて、番組の提示は、第2のメディアプレイリストから得られた第2のストリームを使用する。前記方法は、一実施形態では、低速ビットレートから高速ビットレートへの変化、及び高速ビットレートから低速ビットレートへの変化の両方に使用することができるが、別の実施形態では、この方法は、低速ビットレートから高速ビットレートへの変化にしか使用できず、高速ビットレートから低速ビットレートへの変化には別の方法例えば、遷移点を位置付けるよう試みず、低速ビットレートストリームからできるだけ即座にコンテンツを記憶し提示するよう試みるを使用することができる。図10は、代替えストリームを使用してクライアント装置へプレイリスト又はメディアコンテンツ或いはその両方を与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。プレイリストが上述した代替えストリームを含む場合に、その代替えストリームは、帯域巾又は装置の代替え物として動作するだけでなく、故障フォールバックとして動作することもできる。例えば、クライアントが例えば、404エラー又はネットワーク接続エラーのためにストリームに対するプレイリストファイルを再ロードできない場合には、クライアントは、代替えストリームへスイッチするよう試みることができる。図10を参照すれば、フェイルオーバー保護を具現化するために、第1のサーバー装置又は第1のコンテンツ配布サービスは、図2Cを参照して述べたように、オペレーション1002において、ストリーム又は複数の代替え帯域巾ストリームを生成するように構成される。オペレーション1004において、第1のサーバー装置又は第1のコンテンツ配布サービスは、オペレーション1002において発生されたストリームからプレイリストファイルを発生する。第1のサーバー装置又は第2のコンテンツ配布サービスは、オペレーション1006において、並列ストリーム又はストリームのセットを生成すると共に、プレイリストも生成する。これらの並列ストリームは、バックアップストリームと考えることができる。次いで、バックアップストリームのリストがオペレーション1008においてプレイリストファイルに追加され、一次ストリームの後に、各帯域巾のバックアップストリームがリストされるようにする。例えば、一次ストリームがサーバーALPHAから到来しそしてバックアップストリームがサーバーBETAにある場合には、プレイリストファイルが次のようになる。EXTM3UEXTXSTREAMINFPROGRAMID1BANDWIDTH200000httpALPHAmycompanycomlowprogindexm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH200000httpBETAmycompanycomlowprogindexm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH500000httpALPHAmycompanycommidprogindexm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH500000httpBETAmycompanycommidprogindexm3u8バックアップストリームは、各帯域巾のバックアップがその帯域巾に対する一次の後にリストされたプレイリストにおける一次ストリームと混合されることに注意されたい。クライアントは、単一のバックアップストリームセットに限定されない。上述した例において、ALPHA及びBETAの後に、例えば、GAMMAが続く。同様に、ストリームの完全な並列セットを与える必要はない。例えば、単一の低帯域巾ストリームがバックアップサーバーに与えられる。オペレーション1010において、クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のURLからプレイリストファイルをダウンロードするように試みる。図11は、一実施形態により、クライアント1102が、1つ以上のURL、サーバー装置又はコンテンツ配布サービスと両方向に通信するネットワークを示す。プレイリストファイルは、オペレーション1012において、第1のURL、サーバー装置又はコンテンツ配布サービスからクライアント1102へ送信される。クライアントが、第1のURL、サーバー装置又はコンテンツ配布サービスからプレイリストファイルをダウンロードできない例えば、ストリームのインデックスファイルを再ロードするエラーのために場合には、クライアントは、代替えストリームへスイッチするよう試みる。1つのストリームに欠陥例えば、インデックスロード欠陥がある場合には例えば、オペレーション1010、クライアントは、オペレーション1014においてネットワーク接続がサポートする最も高い帯域巾の代替えストリームを選択する。同じ帯域巾の複数の代替え物がある場合には、クライアントは、プレイリストに載せられた順序でそれらを選択する。例えば、クライアント1102がURL1から首尾よくダウンロードできない場合には、URL2又は別のURLからダウンロードしてもよく、この場合、プレイリストファイルは、代替えURLからクライアントへ送信される。この特徴は、サーバーのクラッシュやコンテンツ配布ノードの故障のような厳しいローカル欠陥の場合でも、メディアがクライアントに到達できるようにする冗長なストリームを与える。フェイルオーバー保護は、クライアントがプレイリスト及びメディアファイルを検索できるところの複数の冗長な位置を与える能力を備えている。従って、クライアントが第1の位置からストリームを検索できない場合には、第2、第3、等の位置からストリームにアクセスするよう試みることができる。一実施形態において、クライアントがプレイリストを検索できるところの付加的な位置を指示するため、同じ変形プレイリストタグに、同じ帯域巾であるが新たなURIの冗長位置が与えられる。クライアントは、最初に、望ましい帯域巾に関連した第1のURLにアクセスするよう試みることができる。第1のURLからプレイリストをダウンロードできない場合には、帯域巾に対して提示される次のURLにアクセスするよう試み、等々、全ての可能性が尽きるまで行う。以下の例は、2560000帯域巾に対する1冗長位置、及び7680000帯域巾に対する2冗長位置を含む。EXTM3UEXTXSTREAMINFPROGRAMID1BANDWIDTH1280000httpexamplecomlowm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH2560000httpexamplecommidm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH2560000httpexample1commidredundant2m3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH7680000httpexamplecomhim3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH7680000httpexample2comhiredudant2m3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH7680000httpexample3comhiredudant3m3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH65000CODECSmp4a405httpexamplecomaudioonlym3u8この例において、ファイルネーム例えば、midredundant2m3u8及び実際のURL例えば、httpexample2comhttpexample3comの両方が変化することに注意されたい。しかしながら、一実施形態では、冗長位置は、ファイルネームに対してのみ又はウェブサイトに対してのみ変化する。一実施形態において、プレイリストは、サーバー装置によって圧縮されて、圧縮形態でクライアント装置へ送られる。圧縮されたプレイリストは、通常、プレイリストを表現するのに非圧縮のプレイリストより少数のビットしか必要とせず、従って、圧縮されたプレイリストは、送信又は受信されるときに、ワイヤレスセルラー電話ネットワークのようなネットワークの利用可能な帯域巾をあまり使用しない。一実施形態では、プレイリストは、HTTP1.1規格プロトコルのような転送プロトコルに適合又は適合するウェブサーバーによって使用される内蔵圧縮技術又はファシリティに基づいてウェブサーバーにより圧縮することができ、このような圧縮技術又はファシリティの一例は、HTTP1.1のデフレート又はgzip圧縮ファシリティである。他の実施形態では、規格ベースの転送プロトコルの一部分である他の規格ベースの圧縮ファシリティを使用することができる。圧縮されたプレイリストの使用は、一実施形態では、サーバー装置及びクライアント装置の任意の特徴である。一実施形態では、プレイリストは、テクスチャーコンテンツ例えば、テキストファイルであり、規格ベースのウェブサーバーによりデフレート又はgzipで効率的に圧縮され、次いで、クライアント装置により自動的に解凍される。gzip圧縮ファシリティのバージョンの説明は、wwwietforgrfcrfc1952txtに見ることができ、デフレート圧縮ファシリティのバージョンは、wwwietforgrfcrfc1951txtに見ることができる。多数のウェブサーバー、及びクライアント装置の多数のウェブブラウザは、デフレート又はgzipファシリティを自動的にサポートすることができる。一実施形態において、クライアント装置は、更新されたプレイリストを周期的に要求することができ、例えば、クライアント装置は、サーバーから、更新されたプレイリストを数秒ごとに例えば、10、20又は30秒ごとに、或いは他の時間周期で要求することができる。クライアントが生のゲーム中の任意の時点で生のゲームを始めから見始めるのを許す生の進行中の野球ゲームのプレイリストのような成長するプレイリストは、その成長するプレイリストがネットワークを通して繰り返し送信されるので、圧縮の使用でネットワークの帯域巾の消費を制限できるに充分な大きさとなる。一実施形態において、クライアント装置は、いつプレイリスト更新されたプレイリストのようなを要求するか、どんな圧縮技術デフレート又はgzipのようなをサポートできるか、任意に特定することができ、これら技術をサポートすることは、クライアント装置が、圧縮又はエンコードされたコンテンツを解読又はデコードできることを意味する。圧縮技術を任意に特定したクライアント装置のプレイリスト要求は、一実施形態において、プレイリストに対する圧縮技術をサポートすることが要求されずに非圧縮のプレイリストを送信できるウェブサーバーによって受け取られる。ウェブサーバーは、クライアント装置の要求に応答して、非圧縮のプレイリスト、又はプレイリストに対するクライアント装置の要求で特定された圧縮技術の1つを使用して圧縮されたプレイリストをクライアント装置へ送信することができる。クライアント装置は、プレイリストを受け取り、そしてそれをここに述べるように使用し、即ちプレイリストが圧縮された場合には、クライアント装置のウェブブラウザにおけるデコーダのようなクライアント装置のデコーダを使用してそれがデコードされる。図8は、電子システムの一実施形態のブロック図である。図8に示す電子システムは、例えば、デスクトップコンピュータシステム、ラップトップコンピュータシステム、セルラー電話、セルラーイネーブルPDAを含むパーソナルデジタルアシスタントPDA、セットトップボックス、娯楽システム、又は他の消費者向け電子装置を含むある範囲の電子システムワイヤード又はワイヤレスを表すことが意図される。代替え電子システムは、より多くの、より少ない及び/又は異なるコンポーネントを含んでもよい。図8の電子システムは、クライアント装置及び/又はサーバー装置を構成するように使用されてもよい。電子システム800は、情報を通信するためのバス805又は他の通信装置と、情報を処理するためにバス805に結合されたプロセッサ810とを備えている。電子システム800は、単一のプロセッサをもつように示されているが、電子システム800は、複数のプロセッサ及び/又はコプロセッサを含んでもよい。電子システム800は、更に、バス805に結合されたランダムアクセスメモリRAM又は他のダイナミック記憶装置820メインメモリと称されるを備え、これは、プロセッサ810により実行されるインストラクション及び情報を記憶する。又、このメインメモリ820は、プロセッサ810によるインストラクションの実行中に変数又は他の中間情報を一時的に記憶するように使用されてもよい。電子システム800は、バス805に結合されたリードオンリメモリROM及び/又は他のスタティック記憶装置830も備え、これは、プロセッサ810のためのスタティック情報及びインストラクションを記憶する。データ記憶装置840は、情報及びインストラクションを記憶するためにバス805に結合される。フラッシュメモリ又は磁気ディスク又は光学ディスク及びそれに対応するドライブのようなデータ記憶装置840が、電子システム800に結合される。又、電子システム800は、バス805を経て、陰極線管CRT又は液晶ディスプレイLCDのようなディスプレイ装置850に結合され、ユーザに情報を表示する。又、電子システム800は、アルファニューメリック及び他のキーを含むアルファニューメリック入力装置860も備え、これは、情報及びコマンド選択をプロセッサ810へ通信するためにバス805に結合される。別の形式のユーザ入力装置は、方向情報及びコマンド選択をプロセッサ810へ通信すると共に、ディスプレイ850上のカーソル移動を制御するための、タッチパッド、マウス、トラックボール又はカーソル方向キーのようなカーソルコントロール870である。更に、電子システム800は、ローカルエリアネットワークのようなネットワークにアクセスを与えるために1つ以上のネットワークインターフェイス880を備えている。このネットワークインターフェイス880は、例えば、1つ以上のアンテナを表すアンテナ885を有するワイヤレスネットワークインターフェイスを含む。又、電子システム800は、WiFi、ブルーツース、及びセルラー電話インターフェイスの組み合わせのような複数のワイヤレスネットワークインターフェイスを含むことができる。又、ネットワークインターフェイス880は、例えば、イーサネットケーブル、同軸ケーブル、光ファイバケーブル、シリアルケーブル、又はパラレルケーブルのようなネットワークケーブル887を経て、リモート装置と通信するためのワイヤードネットワークインターフェイスも含む。一実施形態において、ネットワークインターフェイス880は、例えば、IEEE802.11b及び/又はIEEE802.11g規格に適合することにより、ローカルエリアネットワークへのアクセスを与え、及び/又はワイヤレスネットワークインターフェイスは、例えば、ブルーツース規格に適合することにより、パーソナルアクセスネットワークへのアクセスを与えることができる。他のワイヤレスネットワークインターフェイス及び/又はプロトコルをサポートすることもできる。ワイヤレスLAN規格を経ての通信に加えて又はそれに代わって、ネットワークインターフェイス880は、例えば、時分割多重アクセスTDMAプロトコル、移動通信用のグローバルシステムGSMプロトコル、コード分割多重アクセスCDMAプロトコル、及び/又は他の形式のワイヤレス通信プロトコルを使用して、ワイヤレス通信を行うことができる。本明細書において一実施形態又は実施形態とは、その実施形態に関連して述べた特定の特徴、構造又は特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。本明細書の種々の場所に一実施形態という句が現れたときには、必ずしも、全てが同じ実施形態を指すのではない。以上、本発明の特定の実施形態を説明したが、本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、明細書及び添付図面は、本発明を単に例示するものであって、それに限定されるものではない。アペンディックス以下のアペンディックスは、本発明の特定の実施形態によるプロトコルのドラフト仕様書である。このアペンディックスにおける幾つかのキーワード例えば、MUST、MUSTNOT、SHALL、SHALLNOT、等の使用は、この特定の実施形態に適用されるもので、本開示に述べる他の実施形態には適用されないことが理解されよう。概略本書は、HTTPを経てマルチメディアデータの無限のストリームを送信するためのプロトコルについて述べる。これは、ファイルのデータフォーマットと、ストリームのサーバー送信者及びクライアント受信者により行われるアクションとを特定する。このプロトコルのバージョン1.0について述べる。目次1.序文2.概要3.プレイリストファイル3.1.新たなタグ3.1.1.EXT-X-TARGETDURATION3.1.2.EXT-X-MEDIA-SEQUENCE3.1.3.XEX-X-KEY3.1.4.EXT-X-PROGRAM-DATE-TIME3.1.5.EXT-X-ALLOW-CACHE3.1.6.EXT-X-ENDLIST3.1.7.EXT-X-STREAM-INF3.1.8.EXT-X-DISCONTINUITY4.メディアファイル5.キーファイル5.1.AES-128のためのIV6.クライアント/サーバーアクション6.1.サーバープロセス6.1.1.スライディングウインドウプレイリスト6.1.2.暗号メディアファイル6.1.3.変形ストリームの付与6.2.クライアントプロセス6.2.1.プレイリストファイルのローディング6.2.2.プレイリストファイルの再生6.2.3.プレイリストファイルの再ローディング6.2.4.ロードすべき次のファイルの決定6.2.5.暗号化されたメディアファイルの再生7.例7.1.簡単なプレイリストファイル7.2.HTTPSを使用するスライディングウインドウプレイリスト7.3.暗号化されたメディアファイルを伴うプレイリストファイル7.4.変形プレイリストファイル8.セキュリティの考え方9.参照文献規範的参照文献情報参照文献1.序文本書は、HTTP[RFC2616]を経てマルチメディアデータの無限ストリームを送信するためのプロトコルについて述べる。このプロトコルは、メディアデータの暗号化と、ストリームの代替えバージョン例えば、ビットレートの付与とをサポートする。メディアデータは、それが生成されるや否や送信され、ほぼリアルタイムで受け取ることができるようにする。HTTPのような関連規格について述べる外部の参照文献は、第9章に列挙する。2.概要マルチメディアの提示は、付加的なURIの順序付けされたリストであるプレイリストファイルに対するURI[RFC3986]により特定される。プレイリストファイルの各URIは、単一の隣接ストリームのセグメントであるメディアファイルを指す。ストリームを再生するために、クライアントは、先ず、プレイリストファイルを得、そしてプレイリスト内の各メディアファイルを得て再生する。本書に述べるようにプレイリストファイルを再ロードして、付加的なセグメントを発見する。本書におけるキーワードMUSTMUSTNOTREQUIREDSHALLSHALLNOTSHOULDSHOULDNOTRECOMMENDEDMAY及びOPTIONALは、RFC2119[RFC2119]に述べるように解釈されるべきである。3.プレイリストファイルプレイリストは、拡張型のM3Uプレイリストファイル[M3U]でなければならない。本書は、付加的なタグを定義することによりM3Uファイルフォーマットを拡張する。M3Uプレイリストは、個々のラインより成るテキストファイルである。それらラインは、単一のLFキャラクタか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了となる。各ラインは、URI、ブランクであるか、又はコメントキャラクタ‘’でスタートする。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視される。コメントキャラクタ‘’でスタートするラインは、コメント又はタグである。タグは、EXTで始まる。‘’で始まる他の全てのラインは、コメントであり、無視しなければならない。ネームがm3u8で終わり及び/又はHTTPコンテンツタイプapplicationvndapplempegurlを有するM3Uプレイリストファイルは、UTF-8[RFC3629]でエンコードされる。ネームがm3uで終わり及び/又はHTTPコンテンツタイプ[RFC2616]audiompegurlを有するファイルは、US-ASCII[US_ASCII]でエンコードされる。具現化は、ネームがm3u8で終わるか、又はHTTPを経て送信される場合にコンテンツタイプapplicationvndapplempegurlを有するプレイリストファイルを発生しなければならない。互換性のために、具現化は、ネームがm3uで終わり及び/又はHTTPコンテンツタイプaudiompegurlを有するプレイリストファイルを発生してもよい。拡張型M3Uファイルフォーマットは、2つのタグEXTM3U及びEXTINFを定義する。拡張型M3Uファイルは、基本的M3Uファイルから、EXTM3Uでなければならないその第1ラインにより区別される。EXTINFは、それに続くURIにより識別されるメディアファイルを記述するレコードマーカーである。各メディアファイルURIは、EXTINFタグが先行しなければならない。そのフォーマットは、次の通りである。EXTINF:<duration>、<title>durationは、メディアファイルの期間を秒で特定する整数である。この期間は、最も近い整数に丸めねばならない。カンマに続くラインの残りは、メディアファイルのタイトルである。3.1.新たなタグ本書は、7つの新たなタグ、EXT-X-TARGETDURATION、EXT-X-MEDIA-SEQUENCE、EXT-X-KEY、EXT-X-PROGRAM-DATE-TIME、EXT-X-ALLOW-CACHE、EXT-X-STREAM-INF、及びEXT-X-ENDLIST、を定義する。3.1.1.EXT-X-TARGETDURATIONEXT-X-TARGETDURATIONタグは、主提示に追加される次のメディアファイルのおおよその期間を指示する。これは、プレイリストファイルに現れねばならない。そのフォーマットは、次の通りである。EXT-X-TARGETDURATION:<seconds>メディアファイルの実際の期間は、ターゲット期間から若干異なってもよい。3.1.2.EXT-X-MEDIA-SEQUENCEプレイリストにおける各メディアファイルURIは、独特のシーケンス番号を有する。URIのシーケンス番号は、それに先行するURIのシーケンス番号1に等しい。EXT-X-MEDIA-SEQUENCEタグは、プレイリストファイルに現れる第1のURIのシーケンス番号を指示する。そのフォーマットは、次の通りである。EXT-X-MEDIA-SEQUENCE:<number>プレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含まない場合には、プレイリスト内の第1のURIのシーケンス番号が1であると考えねばならない。EXT-X-MEDIA-SEQUENCEタグの取り扱いに関する情報は、第6.2.1章及び第6.2.4章を参照されたい。3.1.3.EXT-X-KEYメディアファイルは、暗号化されてもよい。EXT-X-KEYタグは、それに続くメディアファイルを解読するに必要な情報を与える。そのフォーマットは、次の通りである。EXT-X-KEY:METHOD=<method>[,URI=<URI>]METHODパラメータは、暗号化方法を特定する。URIパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。プロトコルのバージョン1.0は、2つの暗号化方法NONE及びAES-128を定義する。NONEの暗号化方法は、メディアファイルが暗号化されないことを意味する。AES-128の暗号化方法は、128ビットキー及びPKCS7パッディングを伴う進歩型暗号規格[AES_128][RFC3852]を使用してメディアファイルが暗号化されることを意味する。新たなEXT-X-KEYは、従来のEXT-X-KEYに取って代わる。EXT-X-KEYタグが存在しない場合には、メディアファイルが暗号化されない。キーファイルのフォーマットについては、第5章を、そしてメディアファイル暗号化の付加的な情報については、第5.1章、第6.1.2章及び第6.2.5章を参照されたい。3.1.4.EXT-X-PROGRAM-DATE-TIMEEXT-X-PROGRAM-DATE-TIMEタグは、次のメディアファイルの開始を絶対的な日付及び/又は時刻に関連付ける。日付/時刻表現は、ISO/IEC8601:2004[ISO_8601]であり、時間ゾーンを指示しなければならない。例えば、次の通りである。EXT-X-PROGRAM-DATE-TIME:3.1.5.EXT-X-ALLOW-CACHEEXT-X-ALLOW-CACHEタグは、クライアントが、ダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶してもよいかどうか指示する。そのフォーマットは、次の通りである。EXT-X-ALLOW-CACHE:<YES|NO>3.1.6.EXT-X-ENDLISTEXT-X-ENDLISTタグは、それ以上のメディアファイルがプレイリストファイルに追加されないことを指示する。そのフォーマットは、次の通りである。EXT-X-ENDLIST3.1.7.EXT-X-STREAM-INFEXT-X-STREAM-INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示する。そのフォーマットは、次の通りである。EXT-X-STREAM-INF:attributevalue]attributevalue<URI>EXT-X-STREAM-INFタグについて次の属性が定義される。BANDWIDTH=<n>但し、nは、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。PROGRAM-ID=<i>但し、iは、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM-IDを伴う複数のEXT-X-STREAM-INFURIを含んでもよい。CODECS=formatformat但し、各フォーマットは、プレイリストファイル内のメディアファイルに存在するメディアサンプル形式を特定する。有効なフォーマット識別子は、RFC4281[RFC4281]により定義されたISOファイルフォーマットネームスペースにおける識別子である。3.1.8.EXT-X-DISCONTINUITYEXT-X-DISCONTINUITYタグは、それに続くメディアファイルが、それに先行するものとは異なる特性を有することを指示する。変更してもよい特性のセットは、次の通りである。○ファイルフォーマット○トラックの数及び形式○エンコーディングパラメータ○エンコーディングシーケンス○タイムスタンプシーケンスそのフォーマットは、次の通りである。EXT-X-DISCONTINUITY4.メディアファイルプレイリストファイルにおける各メディアファイルURIは、全体的提示のセグメントであるメディアファイルを識別しなければならない。各メディアファイルは、MPEG-2トランスポートストリーム、MPEG-2番組ストリーム、又はMPEG-2オーディオ基本的ストリーム[ISO_13818]としてフォーマットされねばならない。提示における全てのメディアファイルは、同じフォーマットを有していなければならない。トランスポートストリームファイルは、単一のMPEG-2番組を含まねばならない。各ファイルのスタートに、番組アソシエーションテーブル及び番組マップテーブルがなければならない。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない。クライアントは、合理的なサブセットを選択することにより特定形式例えば、オーディオ又はビデオの複数のトラックを取り扱うように準備しなければならない。クライアントは、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない。メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したままでなければならない。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない。5.キーファイルURIパラメータを伴うEXT-X-KEYタグは、キーファイルを識別する。キーファイルは、プレイリストにおける後続メディアファイルを解読するのに使用しなければならない暗号キーを含む。AES-128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおけるこれら16オクテットのパックされたアレイに過ぎない。5.1.AES-128のためのIV128ビットAESは、暗号及び解読を行うときに同じ16オクテット初期化ベクトルIVを供給することを要求する。このIVを変更すると、暗号化の強度が高くなる。暗号化METHODAES-128を使用するときには、具現化は、メディアファイルを暗号化又は解読する際にメディアファイルのシーケンス番号をIVとして使用しなければならない。このシーケンス番号のビッグエンディアンバイナリー表現を16オクテットバッファに配して左側にゼロをパディングしなければならない。6.クライアント/サーバーアクション本章は、サーバーがどのようにプレイリスト及びメディアファイルを発生し、及びクライアントがどのようにそれをダウンロードして再生すべきか説明する。6.1.サーバープロセスMPEG-2ストリームの発生は、本書の範囲外であり、これは、主提示を含む連続的ストリームのソースを簡単に推定するものである。サーバーは、ストリームを、その期間がほぼ等しい個々のメディアファイルに分割しなければならない。サーバーは、個々のメディアファイルの有効なデコードをサポートするポイント、例えば、パケット及びキーフレーム境界においてストリームを分割するように試みなければならない。サーバーは、そのクライアントがファイルを得るのを許すURIをメディアファイルごとに生成しなければならない。サーバーは、プレイリストファイルを生成しなければならない。プレイリストファイルは、第3章で述べたフォーマットに適合しなければならない。サーバーが利用したい各メディアファイルのURIは、それが再生される順序でプレイリストに現れねばならない。URIがプレイリストファイルにある場合には全メディアファイルがクライアントに利用できねばならない。プレイリストファイルは、EXT-X-TARGETDURATIONタグを含まねばならない。これは、主提示に追加される次のメディアファイルのおおよその期間を指示しなければならない。この値は、全提示に対して一定のままでなければならない。典型的なターゲット期間は、10秒である。サーバーは、そのクライアントがファイルを得るのを許すURIをプレイリストファイルに対して生成しなければならない。プレイリストファイルの変更は、クライアントの観点から原子的に行われねばならない。プレイリストにおける各メディアファイルURIの前には、メディアファイルのおおよその期間を指示するEXTINFタグがなければならない。サーバーは、URIの前にEXT-X-PROGRAM-DATE-TIMEタグを置くことにより絶対日付及び時刻をメディアファイルに関連付けてもよい。日付及び時刻の値は、任意である。プレイリストが提示の最終的メディアファイルを含む場合には、プレイリストファイルは、EXT-X-ENDLISTタグを含まねばならない。サーバーが全提示を除去したい場合には、プレイリストファイルをクライアントに利用不能にしなければならない。これは、プレイリストファイルにおける全メディアファイルが、除去時に、少なくともプレイリストファイルの期間中クライアントに利用できるままとなるよう保証しなければならない。6.1.1.スライディングウインドウプレイリストサーバーは、メディアファイルの利用を、プレイリストに最新に追加されたものに限定してもよい。これを行うために、プレイリストファイルは、常に、厳密に1つのEXT-X-MEDIA-SEQUENCEタグを含まねばならない。その値は、メディアファイルURIがプレイリストファイルから除去されるたびに1だけインクリメントされねばならない。メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去されねばならない。サーバーがプレイリストからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間メディアファイルが現れた最も長いプレイリストファイルの期間に等しい時間周期中、クライアントに利用可能なままとされる。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。サーバーがメディアファイルを除去する計画である場合には、HTTP満了ヘッダが、クライアントへの配信時に、計画生存時間を反映するように保証しなければならない。サーバーは、EXT-X-ENDLISTタグが存在しない限り、少なくとも3つの主提示メディアファイルをプレイリストに常に維持しなければならない。6.1.2.メディアファイルの暗号化メディアファイルを暗号化すべき場合には、サーバーは、許可されたクライアントが解読キーを含むキーファイルを得るのを許すURIを定義しなければならない。このキーファイルは、第5章で述べたフォーマットに適合しなければならない。サーバーは、キーがキャッシュ記憶されたことを指示するためにキー応答に満了ヘッダをセットしてもよい。暗号化METHODがAES-128である場合には、AES-128CBC暗号を個々のメディアファイルに適用しなければならない。ファイル全体を暗号化しなければならない。メディアファイルにわたって暗号ブロックチェーンを適用してはならない。メディアファイルのシーケンス番号を、第5章に述べたIVとして使用しなければならない。サーバーは、プレイリストファイルにおけるURIの直前のEXT-X-KEYタグにより特定された方法を使用してプレイリストにおける各メディアファイルを暗号化しなければならない。METHODがNONEであるEXT-X-KEYタグが先行するか、又はEXT-X-KEYタグが先行しないメディアファイルは、暗号化してはならない。各EXT-X-KEYタグのURIは、METHODがNONEでない限り、プレイリストファイルに現れるか又は現れた1つおきのEXT-X-KEYタグのURIとは異なるものでなければならない。METHODがNONEのEXT-X-KEYタグは、URIパラメータを含んではならない。サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルへのURIを含む場合には、プレイリストファイルからEXT-X-KEYタグを除去してはならない。6.1.3.変形ストリームの付与サーバーは、同じ提示の異なるエンコーディングを与えるために複数のプレイリストファイルを提供してもよい。もしそうであれば、クライアントがエンコーディング間を動的にスイッチできるように各変形ストリームを列挙した変形プレイリストファイルを付与しなければならない。変形プレイリストは、変形ストリームごとにEXT-X-STREAM-INFタグを含まねばならない。同じ提示に対する各EXT-X-STREAM-INFタグは、同じPROGRAM-ID属性値を有していなければならない。各提示に対するPROGRAM-ID値は、変形プレイリスト内で独特でなければならない。EXT-X-STREAM-INFタグがCODECS属性を含む場合には、属性値は、プレイリストファイルに現れる又は現れるであろうメディアファイルに存在する[RFC4281]により定義された各フォーマットを含まねばならない。サーバーは、変形ストリームを発生するときには、次の制約を満足しなければならない。各変形ストリームは、主提示の部分ではないコンテンツを含む同じコンテンツで構成されねばならない。サーバーは、ストリームの最小ターゲット期間という精度内で、全ての変形ストリームに対して同じコンテンツ周期が利用できるようにしなければならない。変形ストリームにおける一致するコンテンツは、一致するタイムスタンプを有していなければならない。これは、クライアントがストリームの同期をとれるようにする。基本的なオーディオストリームファイルは、ID3PRIVタグ[ID3]の前に、comapplestreamingtransportStreamTimestampという所有者識別子を設けることにより、ファイルにおける第1サンプルのタイムスタンプを信号しなければならない。バイナリーデータは、ビッグエンディアン8オクテット数として表現された33ビットのMPEG-2番組基本的ストリームタイムスタンプでなければならない。加えて、全ての変形ストリームは、同じエンコードされたオーディオビットストリームを含まねばならない。これは、クライアントが聴覚欠陥なしにストリーム間をスイッチできるようにする。6.2.クライアントプロセスクライアントがプレイリストファイルに対するURIをどのようにして得るかは、本書の範囲外であり、それを行っているものと仮定する。クライアントは、URIからプレイリストファイルを得なければならない。そのようにして得られたプレイリストファイルが変形プレイリストである場合には、クライアントは、変形プレイリストからプレイリストファイルを得なければならない。本書は、クライアントによる変形ストリームの処理を特定するものではない。6.2.1.プレイリストファイルのローディングプレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、クライアントは、プレイリストファイルがEXTM3Uで始まることをチェックし、もしそうでない場合には、継続を拒否しなければならない。クライアントは、それが認識しないタグを無視しなければならない。クライアントは、第6.2.4章に述べるように、ロードすべき次のメディアファイルを決定しなければならない。プレイリストがEXT-X-MEDIA-SEQUENCEタグを含む場合には、クライアントは、プレイリストファイルがロードされた時間にプレイリストファイルの期間を加えた時間に、その中の各メディアファイルが利用できるようになると仮定しなければならない。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。6.2.2.プレイリストファイルの再生クライアントは、再生がスタートするときにプレイリストからどのメディアファイルを最初に再生するか選択しなければならない。プレイリストファイルがEXT-X-ENDLISTタグを含む場合には、プレイリスト内のどのファイルを最初に再生してもよい。EXT-X-ENDLISTタグが存在しない場合には、プレイリスト内の最後と最後から2番目のファイルを除くどのファイルを最初に再生してもよい。最初に再生すべきメディアファイルが選択されると、プレイリスト内のその後のメディアファイルは、それらが現れた順序でロードし、そしてそれらがロードされた順序で再生しなければならない。クライアントは、中断のない再生のためにメディアファイルが要求されるであろうときに前もってそれらをロードし、待ち時間及びスループットの一時的な変動を補償するよう試みなければならない。プレイリストファイルがEXT-X-ALLOW-CACHEタグを含みそしてその値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後に、キャッシュ記憶してはならない。さもなければ、クライアントは、ダウンロードされたメディアファイルを、後で再生するために不定にキャッシュ記憶してもよい。クライアントは、EXT-X-PROGRAM-DATE-TIMEタグの値を使用して、番組発信時間をユーザに表示してもよい。値が時間ゾーン情報を含む場合には、クライアントは、それを考慮しなければならないが、そうでない場合には、クライアントは、発信時間ゾーンを推定してはならない。クライアントは、EXT-X-PROGRAM-DATE-TIMEタグの値の正しさ又は一貫性に依存してはならない。6.2.3.プレイリストファイルの再ローディングクライアントは、プレイリストファイルがEXT-X-ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードしなければならない。しかしながら、クライアントは、本章で特定された以上に頻繁にプレイリストファイルを再ロードするよう試みてはならない。クライアントがプレイリストファイルを初めてロードするか、又はプレイリストファイルを再ロードして、それが最後にロードされて以来変化したことが分かったときには、クライアントは、プレイリストファイルを再ロードするよう試みる前に、ある期間待機しなければならない。この期間は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのローディングを開始する時間から測定される。初期最小再ロード遅延は、プレイリストにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある期間待機しなければならない。最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0である。6.2.4.ロードすべき次のファイルの決定クライアントは、プレイリストファイルがロードされるか又は再ロードされるたびにロードすべき次のメディアファイルを決定するためにプレイリストファイルを検査しなければならない。ロードすべき最初のファイルは、第6.2.2章に述べたように、最初に再生すべくクライアントが選択したファイルでなければならない。再生されるべき最初のファイルがロードされそしてプレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証しなければならず、そうでない場合は再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIでなければならない。再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT-X-MEDIA-SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものでなければならない。6.2.5.暗号化されたメディアファイルの再生プレイリストファイルが、キーファイルURIを特定するEXT-X-KEYタグを含む場合には、クライアントは、キーファイルを得、そしてその中のキーを使用して、別のEXT-X-KEYタグに遭遇するまで、そのEXT-X-KEYタグに続くメディアファイルを解読しなければならない。暗号化METHODがAES-128である場合には、AES-128CBC解読を個々のメディアファイルに適用しなければならない。ファイル全体を解読しなければならない。メディアファイルにわたって暗号ブロックチェーンを適用してはならない。メディアファイルのシーケンス番号を、第5.1章に述べたIVとして使用しなければならない。暗号化METHODがNONEである場合には、クライアントは、別のEXT-X-KEYタグに遭遇するまで、EXT-X-KEYタグに続く全てのメディアファイルを平文非暗号として処理しなければならない。7.例本章は、幾つかの規範的プレイリストファイルを含む。7.1.簡単なプレイリストファイルEXTM3UEXTXTARGETDURATION10EXTINF5220httpmediaexamplecomentiretsEXTXENDLIST7.2.HTTPSを使用するスライディングウインドウプレイリストEXTM3UEXTXTARGETDURATION8EXTXMEDIASEQUENCE2680EXTINF8httpsprivexamplecomfileSequence2680tsEXTINF8httpsprivexamplecomfileSequence2681tsEXTINF8httpsprivexamplecomfileSequence2682ts7.3.暗号化されたメディアファイルを伴うプレイリストファイルEXTM3UEXTXMEDIASEQUENCE7794EXTXTARGETDURATION15EXTXKEYMETHODAES128URIhttpsprivexamplecomkeyphpr52EXTINF15httpmediaexamplecomfileSequence7794tsEXTINF15httpmediaexamplecomfileSequence7795tsEXTINF15httpmediaexamplecomfileSequence7796tsEXTXKEYMETHODAES128URIhttpsprivexamplecomkeyphpr53EXTINF15httpmediaexamplecomfileSequence7797ts7.4.変形プレイリストファイルEXTM3UEXTXSTREAMINFPROGRAMID1BANDWIDTH1280000httpexamplecomlowm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH2560000httpexamplecommidm3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH7680000httpexamplecomhim3u8EXTXSTREAMINFPROGRAMID1BANDWIDTH65000CODECSmp4a405httpexamplecomaudioonlym3u88.セキュリティの考え方プロトコルは、一般的に、HTTPを使用してデータを送信するものであるから、ほぼ同じセキュリティの考え方が適用される。RFC2616[RFC2616]の第15章を参照されたい。メディアファイルパーサーは、典型的に、ファジング攻撃を受ける。クライアントは、サーバーから受け取ったファイルを構文解析するときに、不適合のファイルが拒絶されるように注意しなければならない。プレイリストファイルは、任意のエンティティのネットワーク要求をなすためにクライアントが使用するURIを含む。クライアントは、バッファのオーバーフローを防止するために応答のレンジチェックを行わねばならない。RFC3986[RFC3986]のセキュリティの考え方の章を参照されたい。クライアントは、サービス拒否攻撃への貢献を回避するためにURIにより怠惰に識別されるリソースをロードしなければならない。HTTP要求は、プライベートユーザデータを含むセッション状態クッキーをしばしば含む。具現化は、RFC2965[RFC2965]により特定されたクッキー制約及び満了ルールに従わねばならない。RFC2965及びRFC2964[RFC2964]のセキュリティの考え方の章も参照されたい。暗号キーは、URIによって特定される。これらのキーの配信は、HTTPのようなメカニズムにより、安全部門又はセッションクッキーに関連したTLS[RFC5246]以前のSSL以上に安全確保されねばならない。9.参照文献規範的参照文献AES128USDepartmentofCommerceNationalInstituteofStandardsandTechnologyAdvancedEncryptionStandardFIPSPUB197November2001ISO13818InternationalOrganizationforStandardizationISOIECInternationalStandard13818GenericcodingofmovingpicturesandassociatedaudioinformationNovember1994ISO8601InternationalOrganizationforStandardizationISOIECInternationalStandard86012004DataelementsandinterchangeformatsInformationinterchangeRepresentationofdatesandtimesDecember2004RFC2046FreedNandNBorensteinMultipurposeInternetMailExtensionsPartTwoMediaTypesRFC2046November1996RFC2119BradnerSKeywordsforuseinRFCstoIndicateRequirementLevelsBCP14RFC2119March1997RFC2616FieldingRGettysJMogulJFrystykHMasinterLLeachPandTBernersLeeHypertextTransferProtocolHTTP11RFC2616June1999RFC3629YergeauFUTF8atransformationformatofISO10646STD63RFC3629November2003RFC3852HousleyRCryptographicMessageSyntaxRFC3852July2004RFC3986BernersLeeTFieldingRandLMasinterUniformResourceIdentifierGenericSyntaxSTD66RFC3986January2005RFC4281GellensRSingerDandPFrojdhTheCodecsParameterforBucketMediaTypesRFC4281November2005USASCIIAmericanNationalStandardsInstituteANSIX341986InformationSystemsCodedCharacterSets7BitAmericanNationalStandardCodeforInformationInterchangeDecember1986情報参照文献ID3ID3orgTheID3audiofiledatataggingformatM3UNullsoftIncTheM3UPlaylistformatoriginallyinventedfortheWinampmediaplayer"