リアルタイム又はほぼリアルタイムのストリーミング
【課題】HTTP適合プロトコルのような転送プロトコルを使用してコンテンツをリアルタイム又はほぼリアルタイムでストリーミングする方法及び装置を提供する。
【解決手段】この方法は、番組(例えば、生映像放送)の隣接時間ベースコンテンツを表すデータのストリームを複数の個別のメディアファイルへと分割する段階、及び複数のタグと、複数の個別のメディアファイルの提示順序を指示するユニバーサルリソースインジケータとを有するプレイリストファイルを発生する段階を含む。複数のメディアファイル及びプレイリストファイルは、クライアント装置へ送信するように利用でき、クライアント装置は、プレイリストファイルを使用してメディアファイルを検索することができる。
【解決手段】この方法は、番組(例えば、生映像放送)の隣接時間ベースコンテンツを表すデータのストリームを複数の個別のメディアファイルへと分割する段階、及び複数のタグと、複数の個別のメディアファイルの提示順序を指示するユニバーサルリソースインジケータとを有するプレイリストファイルを発生する段階を含む。複数のメディアファイル及びプレイリストファイルは、クライアント装置へ送信するように利用でき、クライアント装置は、プレイリストファイルを使用してメディアファイルを検索することができる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ送信技術に係る。より詳細には、本発明は、例えば、ハイパーテキストトランスファープロトコル(HTTP)のような非ストリーミングプロトコルを使用してデータのストリーミングを行えるようにする技術に係る。
【0002】
関連出願:本出願は、次の米国プロビジョナル特許出願の出願日の利益を主張する。
(1)2008年12月31日に出願された特許出願第61/142,110号(管理番号P7437Z);
(2)2009年3月16日に出願された特許出願第61/160,693号(管理番号P7437Z2);
(3)2009年3月17日に出願された特許出願第61/161,036号(管理番号P7437Z3);
(4)2009年4月7日に出願された特許出願第61/167,524号(管理番号P7437Z4);
(5)2009年9月8日に出願された特許出願第61/240,648号(管理番号P7437Z5);及び
(6)2009年12月21日に出願された特許出願第61/288,828号(管理番号P7437Z6)。これら米国プロビジョナル特許出願は、全て、本開示と矛盾しない程度に参考としてここに援用する。
【0003】
本米国特許出願は、参考としてここに各々援用する次の米国特許出願に関連している。
(1)2009年6月5日に出願された“REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,690号(管理番号P7437US1);
(2)2009年6月5日に出願された“VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,698号(管理番号P7437US2);
(3)2009年6月5日に出願された“UPDATABLE REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,732号(管理番号P7437US3); (4)2009年6月5日に出願された“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,735号(管理番号P7437US4)。
【背景技術】
【0004】
コンテンツのストリーミングとは、一般的に、サーバー装置により常時送信されてクライアント装置により受信されるマルチメディアコンテンツを指す。コンテンツは、通常、エンドユーザがストリーミングサーバーにより配信されている間に、エンドユーザに提示される。ネームとは、メディアそれ自身ではなく、メディアの配信方法を指す。
【発明の概要】
【発明が解決しようとする課題】
【0005】
現在のストリーミングサービスは、一般に、エンドユーザに「生」のコンテンツを配布するために特殊なサービスを要求する。大規模な配備では、これが多大なコストを招き、設定及び運転のために特殊なスキルを必要とする。その結果、ストリーミングに利用できるコンテンツのライブラリーは、望ましいライブラリーには至らない。
【課題を解決するための手段】
【0006】
一実施形態において、サーバー装置は、ストリーミングされるべきコンテンツの少なくとも一部分を記憶する。コンテンツは、典型的に、画像又は音声(例えば、サウンド又は音楽)或いはその両方の時間ベースストリームであり、時間ベースストリームの一例は、画像の順序及び提示が時間に基づいていて、従って、時間ベースストリームと考えられる映画である。サーバーは、ストリーミングされるべきコンテンツをネットワークプロトコルに基づいてパケットを経て送信されるべきセグメントへと分解するためのセグメントエージェントと、セグメント化されたユーザデータをクライアントが提示するのを容易にすることのできる1つ以上のプレイリストファイルを発生するためのインデクサエージェントとを備えている。クライアント装置は、ネットワークを経てサーバー装置(或いはセグメント及びプレイリストを記憶してそれらを送信するが、発生はしない別のサーバー)に結合される。クライアント装置は、1つ以上のプレイリストファイルを受け取り、そしてその1つ以上のプレイリストファイルに基づいてコンテンツへのセグメント化メディアファイルの検索を容易にするためのアッセンブラーエージェントを有している。又、クライアント装置は、そのクライアント装置の1つ以上の出力コンポーネントを経てコンテンツを出力するための出力ジェネレータエージェントも有している。
【0007】
一実施形態において、サーバー装置は、クライアント装置へ送信されるべきデータを取得する。サーバー装置は、送信されるべきデータをセグメンタエージェントで複数のメディアファイルに分割する。又、サーバー装置は、複数のセグメントをメモリに個々のメディアファイルとして記憶する。更に、サーバー装置は、複数のメディアファイルへのリファレンスを有する1つ以上のプレイリストファイルを発生する。クライアント装置からのデータの要求に応答して、サーバー装置(又は別のサーバー装置)は、ネットワークを経てクライアント装置へ1つ以上のプレイリストファイル及び少なくとも複数のメディアファイルのサブセットを送信する。複数のメディアファイルは、クライアント装置からの要求に応答して非ストリーミング転送プロトコルを使用して送信することができ、このプロトコルは、例えば、HTTPである。
【0008】
一実施形態において、クライアント装置は、1つ以上のプレイリストファイルを受け取って記憶することができる。次いで、クライアントは、プレイリストファイルにおいて識別されたセグメント化されたメディアファイルを要求し、そしてリンクされたメディアファイルをダウンロードすることができる。次いで、クライアント装置(又は別のクライアント装置)は、コンテンツのストリームを表すオーディオ及び/又はビデオ出力を発生することができる。
【0009】
一実施形態において、更新されたプレイリストを、サーバーによって動的に発生して、クライアントにより検索することができる。更新されたプレイリストは、オリジナルのプレイリストにおける番組に加えて示された付随的資料(例えば、サイドバーユーザインターフェイスにおける広告、関連コンテンツ、別のバージョン、等)を含むか、又は番組の付加的な部分(例えば、オリジナルのプレイリストにおいて識別された第1の半分を越える番組の第2の半分)を含むことができる。1つの具現化において、サーバーは、ここに述べるローリング方法を使用して、プレイリストを更新し、これを、次いで、クライアントにより更新されたプレイリストとして検索することができる。
【0010】
一実施形態において、プレイリストは、同じコンテンツを表す複数の代替えストリームを特定することができ、これら代替えストリームは、異なる視覚解像度で送信される(ひいては、異なるビットレートで送信される)同じ番組でもよいし、或いは他の異なる属性を伴う同じ番組でもよい。サーバーは、代替えストリームごとに1つづつ、複数のプレイリストを発生することができ、又、代替えストリームを指すかさもなければそれを特定する変形プレイリストを発生することができる。次いで、サーバー(又は別のサーバー)は、変形プレイリストをクライアント装置へ送信することができ、そしてクライアント装置は、現在ネットワーク条件(例えば、メディアファイルを転送するのに使用されるネットワークの現在スループットレート)に基づいて、変形プレイリストからどのプレイリストを選択すべきか判断することができ、そしてクライアント装置は、選択されたプレイリストをダウンロードすることができる(更に、その選択されたプレイリストにより特定されたメディアファイルをダウンロードすることができる)。
【0011】
一実施形態において、クライアント装置は、コンテンツを受け取って提示する間に変形プレイリストにおける第1のプレイリストからその変形プレイリストにおける第2のプレイリストへスイッチすることができる。例えば、クライアント装置は、第1のプレイリスト及び第1のビットレートを使用して番組を受け取ることができ、そしてネットワークのスループットレートの測定を通して、第2のプレイリストによりコンテンツが特定されるところの同じ番組のコンテンツをより高い第2のビットレートで受信できると決定することができる。この場合に、クライアント装置は、第2のプレイリストを要求し、第2のプレイリストを受け取り、そして第1のプレイリストにより特定されたコンテンツを提示し続けながら第2のプレイリストにおいて特定されたメディアファイルの検索を開始することができる。クライアント装置は、メディアファイル及び結果的に得られる解凍されたコンテンツを両プレイリストのバッファに記憶することができ、そしてクライアント装置は、自動的なオペレーションを遂行して、いつ、どのように、コンテンツの2つのバージョン間をスイッチ又は遷移すべきか決定することができる。例えば、クライアント装置は、コンテンツの2つのバージョンにおけるオーディオコンテンツのパターンマッチングを使用して、2つのバージョンにおける一致点を見出し、次いで、第2のプレイリストから新たなコンテンツの遷移を識別した後にスイッチを行わせることができる。
【0012】
一実施形態において、方法は、代替えストリームを使用してメディアコンテンツをクライアント装置に与える複数の冗長位置を設けることを含む。フェイルオーバー保護を具現化するため、第1のサーバー装置又は第1のコンテンツ配布サービスは、ストリーム又は複数の代替え帯域巾ストリームを生成し、そしてプレイリストファイル(1つ又は複数)を作成する。第2のサーバー装置又は第2のコンテンツ配布サービスは、並列ストリーム又はストリームのセットを生成する。クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のユニフォームリソースロケーター(URL)からプレイリストファイル(1つ又は複数)をダウンロードするよう試みる。クライアントは、第1のURLからプレイリストファイルをダウンロードできない場合に、別のURLに関連した代替えストリームへスイッチするよう試みる。
【0013】
一実施形態において、方法は、プレイリストの要求を発し、その要求においてプレイリストを圧縮できることを特定し、そしてその要求に応答して、サーバーがプレイリストを圧縮形態で与えることができる場合にプレイリストを圧縮形態で受け取ることを含む(さもなければ、プレイリストは、サーバーにより非圧縮形態で与えることができる)。プレイリストは、デフレート又はgzipのような既存のHTTP標準圧縮技術によりサポートされる圧縮技術又はフォーマットを使用して圧縮(エンコードとも称される)することができる。圧縮形態でのプレイリストの送信及び受信は、特に、プレイリストが時間と共に成長するときに(例えば、プレイリストが長いベースボールゲーム用のものであるときに)、送信及び受信されるデータのサイズを著しく減少することができる。一実施形態において、プレイリストに圧縮を使用することは、クライアント(プレイリストを要求するシステム)及びサーバー(プレイリストを送信することにより要求に応答するシステム)の両方にとって任意である。HTTP規格の一部分である圧縮技術又はフォーマットを使用することは、適合するウェブサーバーが圧縮されたプレイリストを供給できるようにすると共に、適合するクライアントがプレイリストを解凍して使用できるようにもする。
【0014】
本発明は、同様の要素が同じ参照番号で示された添付図面に、一例として、非限定的に示されている。
【図面の簡単な説明】
【0015】
【図1】リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。
【図2A】1つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。
【図2B】1つ以上のサーバー装置が1つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。
【図2C】1つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートである。
【図3A】クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。
【図3B】クライアント装置が複数のビットレートを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。
【図4】サーバーストリームエージェントの一実施形態のブロック図である。
【図5】クライアントストリームエージェントの一実施形態のブロック図である。
【図6】複数のタグを伴うプレイリストファイルの一実施形態を示す図である。
【図7】ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。
【図8】電子システムの一実施形態のブロック図である。
【図9A】クライアント装置が変形プレイリスト内の代替えコンテンツ間をどのようにスイッチできるかの一例を示すフローチャートである。
【図9B】クライアント装置が2つのプレイリストのコンテンツ間をどのようにスイッチできるかを示す更に別のフローチャートである。
【図9C】クライアント装置がオーディオパターンマッチングを使用してコンテンツ間をどのようにスイッチできるかの一例を示す更に別のフローチャートである。
【図9D】図9Cの方法がオーディオパターンマッチングでどのように具現化されるか概略的に示す。
【図10】代替えストリームを使用してクライアント装置へメディアコンテンツを与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。
【図11】一実施形態によりクライアント1102が1つ以上のURLと両方向に通信するネットワークを示す。
【発明を実施するための形態】
【0016】
以下の説明では、多数の特定の細部について述べる。しかしながら、本発明の実施形態は、これらの特定の細部を伴わずに実施されてもよい。他の点については、良く知られた回路、構造及び技術は、説明の理解を妨げないために詳細に示さない。
【0017】
この説明は、版権で保護される資料、例えば、グラフィックユーザインターフェイスの画像の例示を含む。本発明の譲受人を含む版権所有者は、これら資料において版権を含む権利を所有している。版権所有者は、特許商標庁の特許ファイル又は記録に現れるように特許文書又は特許開示を誰かが複写再現することに異議を唱えるものではなく、著作権の全ての権利は何であれ保存されるものとする。版権アップル社2009年。
【0018】
一実施形態において、ここに述べる技術及びコンポーネントは、非ストリーミングプロトコル(例えば、HTTP)及び他のテクノロジー(例えば、モーションピクチャーエクスパートグループ(MPEG)ストリーム)を使用してストリーミングの経験を配信するためのメカニズムを含むことができる。例えば、「生」のミュージカル又はスポーツ行事、生のニュース、ウェブカメラフィード、等を放送するために、HTTPを使用してほぼリアルタイムのストリーミング経験を提供することができる。一実施形態では、プロトコルは、到来するメディアデータを複数のメディアファイルにセグメント化し、そしてそれらのセグメント化されたメディアファイルをサーバーに記憶することができる。又、プロトコルは、サーバーに記憶されたセグメント化されたメディアファイルにクライアントを向けるユニフォームリソースアイデンティファイア(URI)を含むプレイリストファイルを構築することもできる。セグメント化されたメディアファイルがプレイリストファイル(1つ又は複数)に基づいて再生されるときには、クライアントは、「生」の事象のほぼリアルタイムの放送をユーザに提供することができる。予め記録されたコンテンツを同様に提供することもできる。
【0019】
一実施形態において、サーバーは、補足的又は代替え的メディアコンテンツ(例えば、広告、スポーツ行事に関連した統計情報、主たる提示に対する付加的なメディアコンテンツ)を放送事象に動的に導入することができる。例えば、メディア事象のクライアント再生中に、サーバーは、付加的なURIをプレイリストファイルに追加することができ、URIは、クライアントが補足的メディアファイルをダウンロードできるところの位置を識別する。クライアントは、サーバーが導入した補足的又は付加的(又は両方の)メディアコンテンツにアクセスするために1つ以上の更新されたプレイリストファイルをサーバーから周期的に検索するように命令される。
【0020】
一実施形態において、サーバーは、累積モード又はローリングモードのいずれかで動作することができる。累積モードでは、サーバーは、プレイリストファイルを生成し、そしてプレイリストファイルの終わりにメディアファイル識別子を添付することができる。次いで、クライアントは、ダウンロード時に単一のプレイリストファイルからストリームの全ての部分にアクセスすることができる(例えば、ユーザは、ショーの中間でスタートすることができる)。ローリングモードでは、サーバーは、ローリングベースでプレイリストファイルの始めからメディアファイル識別子を除去して、クライアント装置にアクセスできるメディアコンテンツのスライディングウインドウを設けることにより、メディアファイルの利用性を制限することができる。又、サーバーは、プレイリストにメディアファイル識別子を追加することもでき、そしてローリングモードでは、サーバーは、メディアファイルの利用性を、プレイリストに最新に追加されたものに制限することができる。次いで、クライアントは、プレイリストファイルの更新コピーを繰り返しダウンロードして見続ける。プレイリストダウンロードのためのローリングベースは、コンテンツが潜在的に時間的に無限である(例えば、連続的に動作されるウェブからコンテンツが到来する)ときに有用である。クライアントは、プレイリストに終了タグを見つけるまでローリングモードにおいてプレイリストを繰り返し要求し続けることができる。
【0021】
一実施形態において、このメカニズムは、同じ提示の変形ストリームを与えることによりビットレートスイッチングをサポートする。例えば、サービスされるべき提示の多数のバージョンをサーバーに記憶することができる。各バージョンは、実質的に同じコンテンツを有するが、異なるビットレートでエンコードすることができる。これは、クライアント装置が、再生の連続性を妥協することなく、例えば、利用可能な帯域巾の検出に基づいて、ビットレート間をスイッチできるようにする。
【0022】
一実施形態において、無断使用に対してコンテンツを保護するために保護特徴を設けることができる。例えば、予想を防止するために、非順次メディアファイルナンバリングを使用してもよい。又、メディアファイルの暗号化を使用してもよい。更に、部分メディアファイルリストを使用してもよい。又、付加的な及び/又は異なる保護特徴を設けてもよい。
【0023】
図1は、リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。図1の例は、2つのクライアントがネットワークを経てサーバーに結合された簡単なサーバー/クライアント接続を示す。ここに述べる技術及びメカニズムを使用して、いかなる数のクライアントもサポートすることができる。更に、ここに述べる技術及びメカニズムに基づき、複数のサーバーがコンテンツを与えてもよく、及び/又はそれらが一緒に動作してコンテンツを与えてもよい。例えば、1つのサーバーがコンテンツを生成し、プレイリストを生成し、そして複数のメディア(例えば、ファイル)を生成すると共に、他のサーバーがその生成されたコンテンツを記憶し送信してもよい。
【0024】
ネットワーク110は、ワイヤードであるか、ワイヤレス(例えば、IEEE802.11、802.16)であるか、又はその組み合わせであるかに関わらず、いかなる形式のネットワークでもよい。例えば、ネットワーク110は、インターネット又はイントラネットでよい。別の例として、ネットワーク110は、セルラーネットワーク(例えば、3G、CDMA)でもよい。一実施形態において、クライアント装置150及び180は、複数のネットワーク形式を経て通信することができる(例えば、各装置は、WiFiワイヤレスLANを経て及びワイヤレスセルラー電話ネットワークも経て通信することができる)。例えば、クライアント装置150及び180は、セルラー無線電話ネットワーク及びデータネットワークを経て通信できるスマートホン又はセルラーイネーブル型パーソナルデジタルアシスタントでもよい。これらの装置は、いずれかの形式のネットワークを経てここに述べるストリーミングメカニズムを使用することもできるし、又は必要に応じてネットワーク間をスイッチすることもできる。
【0025】
サーバー120は、この技術で良く知られたように、HTTPサーバーとして動作してもよい。即ち、サーバー120は、HTTPプロトコルを使用してコンテンツを与えるHTTPサーバーエージェント145を備えている。図1の例は、HTTPに関して説明するが、他のプロトコルを同様に利用することができる。セグメンタ130及びインデクサ135は、ここに述べるようにメディアファイルのコンテンツにプレイリストファイルを与えるためにサーバー120(又は複数のサーバー)上に存在するエージェントである。これらのメディアファイル及びプレイリストファイルは、HTTPプロトコルを使用してHTTPサーバーエージェント145を経て(又は他のサーバーを経て)ネットワーク110にわたり送ることができる。ここに述べるエージェントは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせとして具現化することができる。
【0026】
セグメント130は、メディアデータのストリームを、HTTPプロトコルを経て送信できる複数のメディアファイルへ分割するように機能する。インデクサ135は、セグメント化されたメディアファイルに対応するプレイリストファイルを生成するように機能して、クライアント装置がメディアファイルを再アッセンブルし、サーバー120により与えられたコンテンツをリアルタイム又はほぼリアルタイムで送信できるようにする。クライアント装置からの1つ以上の要求に応答して、HTTPサーバーエージェント145(又は他のサーバー)は、インデクサ135により発生される1つ以上のプレイリストファイル及びセグメンタ130により発生されるコンテンツのメディアファイルを送信することができる。サーバー120は、更に、ここに述べるセキュリティ機能の1つ以上(例えば、暗号化)を与える任意のセキュリティエージェント140を備えている。又、サーバー120は、図1に示されていない付加的なコンポーネントを含んでもよい。
【0027】
クライアント装置150及び180は、サーバー120からネットワーク110を経てプレイリストファイル及びメディアファイルを受け取る。クライアント装置は、ネットワークを経て送信されたデータを受け取ることができ、そしてネットワークを経て受け取ったデータ使用して出力を発生できる任意の形式の電子装置、例えば、ワイヤレス移動装置、PDA、娯楽装置、消費者向け電子装置、等でよい。その出力は、任意のメディア形式又はメディア形式の組み合わせで、例えば、オーディオ、ビデオ、又はその組み合わせを含む。
【0028】
クライアント装置150は、アッセンブラーエージェント160及び出力ジェネレータエージェント165を含むことができる。同様に、クライアント装置180は、アッセンブラーエージェント190及び出力ジェネレータエージェント195を含むことができる。アッセンブラーエージェント160及び180は、サーバー120からプレイリストファイルを受け取り、そしてそのプレイリストファイルを使用して、サーバー120にアクセスし、そこからメディアファイルをダウンロードする。出力ジェネレータエージェント165及び195は、ダウンロードされたメディアファイルを使用して、各々、クライアント装置150及び160から出力を発生することができる。出力は、1つ以上のスピーカ、1つ以上のディスプレイスクリーン、スピーカ及びディスプレイスクリーンの組み合わせ、或いは他の入力又は出力装置により発生することができる。又、クライアント装置は、メディアファイル(例えば、圧縮されたメディアファイル又は解凍されたメディアファイル)が受け取られたときにそれらを記憶するためのバッファとして作用するメモリ(例えば、フラッシュメモリ又はDRAM、等)を含むこともでき、このバッファは、現在提示されているコンテンツの時間を越えて何秒にも値する提示可能なコンテンツを与え、新たなコンテンツがダウンロードされる間にそのバッファされたコンテンツを後で表示できるようにする。このバッファは、クライアント装置が間欠的な低速のネットワーク接続を通してコンテンツを検索するよう試みる間に提示可能なコンテンツを与えることができ、ひいては、このバッファは、ネットワークの待ち時間又は接続の問題を隠すことができる。
【0029】
更に、クライアント装置150及び180は、各々、ここに述べるセキュリティ機能の1つ以上を与える任意のセキュリティエージェント170及び185を備えている。又、クライアント装置150及び180は、図1には示されていない付加的なコンポーネントを含んでもよい。
【0030】
一実施形態において、本出願に述べる技術は、非ストリーミングプロトコル(例えば、HTTP)を経てマルチメディアデータの無限のストリームを送信するのに使用されてもよい。又、実施形態は、メディアデータを暗号化し及び/又はストリームの代替えバージョンを与える(例えば、代替えビットレートを与える)ことも含み得る。メディアデータは、生成後に直ちに送信できるので、ほぼリアルタイムで受け取ることができる。マルチメディアデータのストリームのサーバー(送信者)及びクライアント(受信者)によってとられるべきアクション及びファイルの規範的なデータフォーマットが与えられるが、他のフォーマットをサポートすることもできる。
【0031】
シミュレーションされたリアルタイムストリーム(又はほぼリアルタイムのストリーム)として送信できるメディア提示は、プレイリストファイルを指示するユニバーサルリソースインジケータ(URI)により特定される。一実施形態において、プレイリストファイルは、付加的なURIの順序付けされたリストである。プレイリストファイルにおける各URIは、特定番組に対するメディアデータの単一隣接ストリームであるストリームのセグメントであるメディアファイルを指す。
【0032】
メディアデータのストリームを再生するため、クライアント装置は、サーバーからプレイリストファイルを得る。又、クライアントは、プレイリストファイルにより指示された各メディアデータファイルを得て再生する。一実施形態において、クライアントは、付加的な及び/又は異なるメディアセグメントを発見するためにプレイリストファイルを動的に又は繰り返し再ロードすることができる。
【0033】
プレイリストファイルは、例えば、拡張M3Uプレイリストファイルでよい。一実施形態において、M3Uフォーマットを効果的に拡張する付加的なタグが使用される。M3Uは、ムービングピクチャーエクスパーツグループオーディオレイヤ3ユニフォームリソースロケーター(MP3 URL)を指すもので、マルチメディアプレイリストを記憶するのに使用されるフォーマットである。M3Uファイルは、メディアプレーヤが再生するための1つ以上のメディアファイルの位置を含むテキストファイルである。
【0034】
プレイリストファイルは、一実施形態では、個々のラインより成る拡張型M3Uフォーマットテキストファイルである。それらのラインは、単一のLFキャラクタにより終了するか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了することができる。各ラインは、URI、ブランクライン、又はコメントキャラクタ(例えば、‘#’)でのスタートである。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視することができる。
【0035】
コメントキャラクタでスタートするラインは、コメント又はタグである。タグは、#EXTで開始し、一方、コメントラインは、#で開始することができる。コメントラインは、通常、サーバー及びクライアントにより無視することができる。一実施形態において、プレイリストファイルは、UTF−8フォーマットでエンコードされる。UTF−8(8ビットのユニコードトランスフォーメーションフォーマット)は、可変長さのキャラクタエンコーディングフォーマットである。別の実施形態では、他のキャラクタエンコーディングフォーマットを使用することができる。
【0036】
以下の例では、2つのタグ、EXTM3U及びEXTINFを含む拡張型M3Uフォーマットが使用される。拡張型M3Uファイルは、“#EXTM3U”を含む第1のラインにより基本的M3Uファイルから区別される。
【0037】
EXTINFは、タグに続くURIにより識別されるメディアファイルを示すレコードマーカーである。一実施形態において、各メディアファイルの前には、EXTINFタグ、例えば、
#EXTINF:<duration>、<title>
があり、“duration”は、メディアファイルの期間を特定し、そして“title”は、ターゲットメディアファイルのタイトルである。
【0038】
一実施形態において、次のタグは、メディアファイルの転送及び再生を管理するのに使用される。
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
【0039】
これらのタグは、各々、以下で詳細に述べる。各新たなタグについて特定のフォーマット及び属性を説明するが、異なる属性、ネーム、フォーマット、等を伴う別の実施形態をサポートすることもできる。
【0040】
EXT−X−TARGETDURATIONタグは、提示に追加される次のメディアファイルのおおよその期間を指示することができる。これは、再生ファイルに含まれ、そのフォーマットは、次の通りである。
#EXT−X−TARGETDURATION:<seconds>
但し、“seconds”は、メディアファイルの期間を指示する。一実施形態において、実際の期間は、タグによって指示されるターゲット期間とは若干相違することがある。一実施形態において、セグメントを指示する各URIは、セグメントのおおよその期間に関連付けられ、例えば、セグメントのURIの前に、そのセグメントのおおよその期間を指示するタグが付けられる。
【0041】
プレイリストファイルにおける各メディアファイル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、等の非順次のシーケンス番号は、シーケンスにおける次の番号の予想を困難にし、これは、コンテンツを海賊版作成から保護する上で助けとなる。コンテンツを保護する上で助けとなる別のオプションは、所与の時間にプレイリストの一部分だけを露呈することである。
【0042】
あるメディアファイルは、暗号化することができる。EXT−X−KEYタグは、それに続くメディアファイルを解読するために使用できる情報を与え、そのフォーマットは、次の通りである。
#EXT−X−KEY:METHOD=<method>[,URI=“<URI>”]
METHODパラメータは、暗号化方法を特定し、そしてURIパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。
【0043】
NONEの暗号化方法は、暗号化しないことを指示する。種々の暗号化方法を使用することができ、例えば、AES−128は、128ビットキー及びPKCS7パッディング(RFC3852を参照)を伴う「アドバンスエンクリプションスタンダード」暗号化を使用する暗号化を指示する。新規なEXT−X−KEYタグは、従来のEXT−X−KEYタグに取って代わるものである。
【0044】
URIパラメータを伴うEXT−X−KEYタグは、キーファイルを識別する。このキーファイルは、プレイリストファイルに載せられた後続メディアファイルを解読するのに使用される暗号キーを含む。例えば、AES−128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおける16オクテットのパックアレイである。
【0045】
AES−128の使用は、通常、暗号化及び解読時に同じ16オクテットの初期化ベクトル(IV)を供給することを要求する。IVの変更を使用して、暗号化の強度を高めることができる。AES−128暗号化を使用するときに、メディアファイルのシーケンス番号は、メディアファイルの暗号化又は解読時にIVとして使用することができる。
【0046】
EXT−X−PROGRAM−DATE−TIMEタグは、次のメディアファイルの開始を絶対的日付及び/又は時刻に関連付けできるもので、時間ゾーンを含むか又は指示することができる。一実施形態において、日付/時刻表現は、ISO/IEC8601:2004である。タグのフォーマットは、次の通りである。
EXT−X−PROGRAM−DATE−TIME:<YYY-MM-DDThh:mm:ssZ>
【0047】
EXT−X−ALLOW−CACHEタグは、クライアントがダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶できるかどうか指示するのに使用することができる。タグのフォーマットは、次の通りである。
EXT−X−ALLOW−CACHE:<YES|NO>
【0048】
EXT−X−ENDLISTタグは、一実施形態では、それ以上のメディアファイルをプレイリストファイルに追加しないことを指示する。タグのフォーマットは、次の通りである。
EXT−X−ENDLIST
一実施形態において、プレイリストが最終的セグメント又はメディアファイルを含む場合には、プレイリストがEXT−X−ENDLISTタグをもつことになる。
【0049】
EXT−X−STREAM−INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示するのに使用できる。タグのフォーマットは、一実施形態では、次の通りである。
EXT−X−STREAM−INF:[attribute=value][,attribute=value]*
<URI>
ここで、次の属性が使用される。属性BANDWIDTH=<n>は、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。属性PROGRAM−ID=<i>は、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM−IDを伴う複数のEXT−X−STREAM−INF URIを含む。この開示では、変形ストリーム及び変形プレイリストについて更に説明する(例えば、図9A−9Dを参照)。
【0050】
以上のタグ及び属性は、オリジナルメディアコンテンツを表すメディアファイルを編成し、送信しそして処理するために、サーバー装置により使用することができる。クライアント装置は、この情報を使用して、リアルタイム又はほぼリアルタイムのストリーミング経験(例えば、音楽又はスポーツ行事のような生放送を見ること)をクライアント装置のユーザに与えるようにメディアファイルを再アッセンブルし、提示する。
【0051】
プレイリストファイルにおける各メディアファイルURIは、オリジナル提示(即ち、オリジナルメディアコンテンツ)のセグメントであるメディアを識別する。一実施形態において、各メディアファイルは、MPEG−2トランスポートストリーム、MPEG−2番組ストリーム、又はMPEG−2オーディオ基本的ストリームとしてフォーマットされる。このフォーマットは、CODECを特定することにより特定することができ、そしてプレイリストは、CODECを特定することによりフォーマットを特定することができる。一実施形態では、提示における全てのメディアファイルが同じフォーマットを有するが、他の実施形態では、複数のフォーマットをサポートできる。トランスポートストリームファイルは、一実施形態では、単一のMPEG−2番組を含まねばならず、各ファイルの開始に番組アソシエーションテーブル及び番組マップテーブルがなければならない。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない。クライアントは、合理的なサブセットを選択することにより特定形式(例えば、オーディオ又はビデオ)の複数のトラックを取り扱うように準備しなければならない。クライアントは、一実施形態では、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない。メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したものでなければならない。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない。
【0052】
図2Aは、1つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。図2Aの例は、HTTPに関して与えられるが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Aの例は、単一のサーバーが幾つかのタスクを遂行することに関して与えられる。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でもよい。
【0053】
サーバー装置は、オペレーション200において、与えられるべきコンテンツを受け取る。コンテンツは、生のオーディオ及び/又はビデオ(例えば、スポーツ行事、生のニュース、ウェブカメラのフィード)を表す。又、コンテンツは、予め記録されたコンテンツ(例えば、記録されたコンサート、トレーニングセミナー、等)を表してもよい。コンテンツは、ストリーム型であるかどうかに関わらず、この技術で知られたフォーマット及びプロトコルに基づいてサーバーにより受け取られる。一実施形態では、コンテンツは、MPEG−2ストリームの形態でサーバーにより受け取られるが、他のフォーマットをサポートすることもできる。
【0054】
次いで、サーバーは、オペレーション210において、コンテンツの少なくとも一部分を一時的に記憶する。コンテンツ又はコンテンツの少なくとも一部分は、例えば、記憶装置(例えば、記憶エリアネットワークのハードディスク、等)又はメモリに一時的に記憶される。或いは又、コンテンツは、記憶メディア(例えば、コンパクトディスク、フラッシュドライブ)を経て受け取られ、そこから記憶装置又はメモリへコンテンツを転送してもよい。一実施形態では、サーバーは、必要に応じてコンテンツを1つ以上のストリーム(例えば、MPEG−2)へ変換するエンコーダを有する。この変換は、受け取ったコンテンツを永久的に記憶せずに行うことができ、ある実施形態では、記憶オペレーション210を省略してもよいし、又は他の実施形態では、それが長期間記憶(例えば、アーカイブ記憶)であってもよい。
【0055】
与えられるべきコンテンツは、オペレーション220において、複数のメディアファイルへとセグメント化される。一実施形態では、サーバーは、ストリームを、別々の個別のメディアファイル(即ち、セグメント)へと変換し、これらファイルは、標準ウェブサーバーを使用して配布することができる。一実施形態では、サーバーは、個々のメディアファイルの有効なデコードをサポートするポイントにおいて(例えば、PESパケット境界及びi−フレーム境界のようなパケット及びキーフレーム境界において)メディアストリームをセグメント化する。メディアファイルは、ほぼ等しい期間を伴うオリジナルストリームの一部分である。又、サーバーは、メディアファイルごとにURIを生成する。これらのURIは、クライアント装置がメディアファイルにアクセスできるようにする。
【0056】
セグメントは、本来的に全ファイルを配信するHTTPサーバーを使用してサービスされるので、サーバーは、クライアントにサービスできるまでに完全なセグメント化メディアファイルが得られねばならない。従って、クライアントは、少なくとも1つのメディアファイル長さだけ放送が(時間的に)遅れることがある。一実施形態において、メディアファイルサイズは、時間の遅れとファイル数が多過ぎることとのバランスに基づいたものになる。
【0057】
一実施形態では、2つのセッション形式(生のセッション及びイベントセッション)がサポートされる。生のセッションでは、ストリームの固定サイズ部分だけが保存される。一実施形態では、時代遅れのコンテンツメディアファイルが番組プレイリストファイルから除去され、そしてサーバーからも除去される。第2の形式のセッションは、クライアントが放送の任意のポイントへ同調できる(例えば、初めからスタートするか、中間点からスタートする)イベントセッションである。この形式のセッションは、例えば、再放送に使用することができる。
【0058】
オペレーション230では、メディアファイルがサーバーメモリに記憶される。メディアファイルは、オペレーション230において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。メディアファイルは、サーバー装置においてウェブサーバーアプリケーションによりサポートされる(又は送信を行う別の装置によりサポートされる)ネットワークプロトコル(例えば、HTTP又はHTTPS)を使用して送信の準備ができたファイルとして記憶される。
【0059】
オペレーション240において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、拡張型M3Uタグ及びここに述べるタグを使用して、クライアント装置がメディアファイルにアクセスしてそれを再アッセンブルし、クライアント装置にストリーミング経験を与えるための情報を発生できるようにする。各メディアファイルのURIは、メディアファイルを再生すべき順序でプレイリストファイルに含まれる。又、サーバーは、クライアント装置がプレイリストファイルにアクセスできるようにプレイリストファイルの1つ以上のURIを生成することもできる。
【0060】
オペレーション250において、プレイリストファイルをサーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Aにおいて、特定の順序で提示されるが、異なる順序を使用してもよい。例えば、プレイリストファイルは、メディアファイルが生成され又は記憶される前に生成されてもよい。別の例として、プレイリストファイル及びメディアファイルは、そのいずれかが記憶される前に生成される。
【0061】
メディアファイルを暗号化すべき場合には、プレイリストファイルは、許可されたクライアント装置がメディアファイル解読のための暗号キーを含むキーファイルを得ることができるようにするURIを定義することができる。暗号キーは、セキュアな接続(例えば、HTTPS)を使用して送信することができる。別の例として、プレイリストファイルは、HTTPSを使用して送信することができる。更に別の例として、メディアファイルは、クライアントがプレイリストファイルなしにストリームを再生成できないように予想不能な順序で配列することができる。
【0062】
暗号化方法がAES−128である場合には、例えば、AES−128 CBC暗号化が個々のメディアファイルに適用される。一実施形態において、ファイル全体が暗号化される。一実施形態では、暗号ブロックチェーンが、通常、メディアファイルにわたって適用されない。メディアファイルのシーケンスが、上述したように、IVとして使用される。一実施形態では、サーバーは、キーURIを伴うEXT−X−KEYタグをプレイリストファイルの終わりに追加する。次いで、サーバーは、暗号構成に変更がなされるまで、全ての後続メディアファイルをそのキーで暗号化する。
【0063】
新たな暗号キーへスイッチするために、サーバーは、提示に使用された全ての以前のキーURIとは個別の新たなURIを経て新たなキーを利用できるようにする。又、サーバーは、プレイリストファイルの終わりに新たなキーURIを伴うEXT−X−KEYタグも追加し、そしてその新たなキーで全ての後続メディアファイルを暗号化する。
【0064】
暗号化を終了するために、サーバーは、プレイリストファイルの終わりに暗号化方法NONEを伴うEXT−X−KEYタグを追加することができる。このタグ(“NONE”を方法として伴う)は、一実施形態では、URIパラメータを含まない。全ての後続メディアファイルは、上述したように暗号構成に変更がなされるまで、暗号化されない。サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルに対するURIを含む場合には、EXT−X−KEYタグをプレイリストファイルから除去しない。サーバーは、図3Aを参照して詳細に述べるように、オペレーション270において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。
【0065】
一実施形態において、サーバーは、プレイリストファイルについての要求をクライアント装置から受け取るのに応答してクライアント装置へプレイリストファイルを送信する。クライアント装置は、クライアント装置に与えられたURIを使用してプレイリストファイルにアクセスし/それを要求することができる。URIは、サーバーにおけるプレイリストファイルの位置を指示する。それに応答して、サーバーは、プレイリストファイルをクライアント装置へ与えることができる。クライアント装置は、プレイリストファイルにおけるタグ及びURI(又は他の識別子)を使用して、複数のメディアファイルにアクセスすることができる。
【0066】
一実施形態において、サーバーは、メディアファイルの利用性を、プレイリストファイルに最新に追加されたものに限定することができる。これを行うために、各プレイリストファイルは、1つのEXT−X−MEDIA−SEQUENCEタグしか含むことができず、そしてメディアファイルURIがプレイリストファイルから除去されるたびに値を1だけインクリメントすることができる。メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去することができる。一実施形態において、サーバーがプレイリストファイルからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間と、メディアファイルが現れた最も長いプレイリストファイルの期間との和に等しい期間中、クライアントに利用可能なままとなる。
【0067】
プレイリストファイルの期間は、そのプレイリストファイル内のメディアファイルの期間の和である。又、他の期間を使用することもできる。一実施形態において、サーバーは、EXT−X−ENDLISTタグが存在しない限り、少なくとも3つの主提示のメディアファイルを常にプレイリストに維持することができる。
【0068】
図2Bは、1つ以上のサーバー装置が1つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。プレイリストは、ここに述べる累積モード又はローリングモードのいずれかを使用して更新することができる。図2Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコル(例えば、HTTPS、等)も、同様に使用することができる。図2Bの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。
【0069】
サーバー装置は、オペレーション205において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション215において、コンテンツの少なくとも一部分を一時的に記憶する。オペレーション215は、図2Aのオペレーション210と同様である。与えられるべきコンテンツは、オペレーション225において、複数のメディアファイルへとセグメント化される。メディアファイルは、オペレーション235においてサーバーメモリに記憶することができる。メディアファイルは、オペレーション235において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。
【0070】
オペレーション245において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、オペレーション255において、サーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Bでは特定の順序で表されるが、異なる順序が使用されてもよい。
【0071】
サーバー(又は別のサーバー)は、図3A−3Bを参照して詳細に述べるように、オペレーション275において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。
【0072】
プレイリストファイルは、種々の理由で、サーバーによって更新される。サーバーは、オペレーション285において、クライアント装置に与えられるべき付加的なデータを受け取ることができる。付加的なデータは、オペレーション255においてプレイリストファイルが記憶された後に受け取ることができる。付加的なデータは、例えば、生の提示の付加的な部分、又は既存の提示の付加的な部分である。付加的なデータは、広告又は統計情報(例えば、スポーツ行事に関するスコア又はデータ)を含む。又、付加的なデータは、提示上に(半透明体を通して)オーバーレイすることもできるし、又はサイドバーユーザインターフェイスに提示することもできる。付加的なデータは、最初に受け取られたデータと同様に、セグメント化することができる。付加的なデータが、広告を構成するか、又はプレイリストにより表された番組に挿入されるべき他のコンテンツを構成する場合には、付加的なデータは、オペレーション215において(少なくとも一時的に)記憶することができ、オペレーション225においてセグメント化することができ、そしてオペレーション235において記憶することができ、又、セグメント化された付加的なデータを記憶する前に、付加的なデータのセグメントを暗号化することができる。次いで、オペレーション245において、番組及び付加的なデータを含む更新されたプレイリストが発生される。そのプレイリストは、オペレーション255において、付加的なデータに基づいて更新されて、再び記憶される。プレイリストファイルに対する変更は、クライアント装置の観点から原子的に行わねばならない。更新されたプレイリストは、一実施形態では、以前のプレイリストに置き換わる。以下に詳細に述べるように、クライアント装置は、プレイリストを何回も要求することができる。これらの要求は、クライアント装置が最新のプレイリストを利用できるようにする。一実施形態では、付加的なデータがメタデータであり、この場合、プレイリストは、更新する必要がないが、セグメントは、メタデータを含むように更新することができる。例えば、メタデータは、セグメントのタイムスタンプと一致させることのできるタイムスタンプを含み、そしてメタデータは、一致するタイムスタンプを有するセグメントに追加することができる。
【0073】
又、更新されたプレイリストは、メディアファイルの除去を生じてもよい。一実施形態では、サーバーは、プレイリストから、メディアファイルに対し、URIを、それらがプレイリストに追加された順序で除去しなければならない。一実施形態では、サーバーは、全提示を除去する場合に、プレイリストファイルをクライアント装置に利用できなくする。一実施形態では、サーバーは、メディアファイル及びプレイリストファイルを、除去されるべきメディアファイルを含む最長のプレイリストファイルの期間中維持して、現在のクライアント装置が提示へのアクセスを終了できるようにする。従って、プレイリストファイルにおける各メディアファイルURIの前には、プレイリストファイルにより指示されるメディアファイルのおおよその累積的期間を指示するためにEXT−X−STREAM−INFタグを設けることができる。別の実施形態では、メディアファイル及びプレイリストファイルは、直ちに除去されてもよい。
【0074】
クライアント装置からのプレイリストに対するその後の要求の結果、オペレーション275において、サーバーが更新されたプレイリストを与える。一実施形態では、プレイリストは、規則的に更新され、例えば、ターゲット期間に関連した時間周期で更新される。プレイリストファイルの周期的な更新は、サーバーが、動的に変化する提示へのアクセスを与えることができるようにする。
【0075】
図2Cは、1つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートであり、これは、代替えストリームを使用する1つの形態である。図2Cの例は、HTTPに関して示すが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Cの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。
【0076】
一実施形態では、サーバーは、複数のプレイリストファイルを提供するか、又は単一のプレイリストファイルに複数のメディアファイルリストを伴う単一のプレイリストファイルを提供して、同じ提示の異なるエンコーディングを与えることができる。異なるエンコーディングが与えられる場合には、プレイリストファイルは、異なるビットレートを与える各変形ストリームを含み、クライアント装置がエンコーディング間を動的にスイッチできるようにする(図9A−9Dを参照して更に説明する)。変形ストリームを有するプレイリストファイルは、変形ストリームごとにEXT−X−STREAN−INFタグを含むことができる。同じ提示に対する各EXT−X−STREAN−INFタグは、同じPROGRAM−ID属性値をもつことができる。各提示のPROGRAM−ID値は、変形ストリーム内で独特である。
【0077】
一実施形態では、サーバーは、変形ストリームを発生するときに次の制約を満足する。各変形ストリームは、主提示の一部分ではない任意のコンテンツを含む同じコンテンツで構成することができる。サーバーは、ストリームの最小ターゲット期間の精度内で全ての変形ストリームに対して同じコンテンツ周期を利用できるようにする。変形ストリームのメディアファイルは、一実施形態では、全ての変形ストリームにおける対応コンテンツに対して一致するサンプルタイムスタンプを伴うMPEG−2トランスポートストリーム、又はMPEG−2番組ストリームのいずれかである。又、一実施形態では、全ての変形ストリームは、同じオーディオエンコーディングを含む。これは、クライアント装置がコンテンツを失うことなく変形ストリーム間でスイッチできるようにする。
【0078】
図2Cを参照すれば、サーバー装置は、オペレーション202において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション212において、コンテンツを少なくとも一時的に記憶する。与えられるべきコンテンツは、オペレーション222において、複数のメディアファイルへとセグメント化される。各メディアファイルは、オペレーション232において、選択されたビットレート(又は他のエンコーディングパラメータの選択された値)についてエンコードされ、そしてサーバーに記憶される。例えば、メディアファイルは、高、中間及び低帯域巾接続についてターゲットが決められる。メディアファイルは、記憶の前に暗号化することができる。種々の形式の接続についてターゲットが決められたメディアファイルのエンコーディングは、ターゲット帯域巾レベルにおいてストリーミング経験を与えるように選択される。
【0079】
一実施形態では、オペレーション242において、種々のエンコーディングレベルを指示するここに述べるタグを伴う変形プレイリストが発生される。タグは、例えば、対応するメディアプレイリストファイルに対するURIを伴うエンコーディングレベルごとのEXT−X−STREAN−INFタグである。
【0080】
この変形プレイリストは、種々のエンコーディングレベルについてメディアプレイリストファイルに対するURIを含むことができる。従って、クライアント装置は、エンコーディングレベルを指示する変形プレイリストに与えられた代替え物からターゲットビットレートを選択し、そしてそれに対応するプレイリストファイルを検索することができる。一実施形態では、クライアント装置は、再生中にビットレート間を切り換えることができる(図9A−9Dを参照して述べるように)。種々のエンコーディングレベルを指示する変形プレイリストは、オペレーション252において、サーバーに記憶される。オペレーション242では、変形プレイリストにおいて参照されるプレイリストの各々を発生し、オペレーション252においてそれを記憶することができる。
【0081】
クライアント装置からの要求に応答して、サーバーは、オペレーション272において、種々のエンコーディングレベルを指示する変形プレイリストを送信することができる。サーバーは、オペレーション282において、選択されたビットレートに対応する変形プレイリストにおいて特定されたメディアプレイリストの1つに対する要求を受け取る。この要求に応答して、サーバーは、オペレーション292において、クライアント装置からの要求に対応するメディアプレイリストファイルを送信する。次いで、クライアント装置は、メディアプレイリストを使用して、サーバーからのメディアファイルを要求する。サーバーは、オペレーション297において、それらの要求に応答してクライアント装置へメディアファイルを与える。
【0082】
図3Aは、クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Aの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。図3A−3Bに示す方法は、1つのクライアント装置又は複数の別々のクライアント装置により遂行することができる。例えば、これら方法のいずれか1つの場合に、単一のクライアント装置が、全てのオペレーション(例えば、プレイリストファイルを要求し、プレイリストファイルのURIを使用してメディアファイルを要求し、提示/出力の発生及び供給のためにメディアファイルをアッセンブルする)を遂行するか、或いは複数の個別のクライアント装置が、全部ではなく幾つかのオペレーションを遂行する(例えば、第1のクライアント装置が、プレイリストファイルを要求し、そのプレイリストファイルのURIを使用してメディアファイルを要求し、そしてそれらのメディアファイルを第2のクライアント装置により使用するために記憶し、第2のクライアント装置は、メディアファイルを処理して、提示/出力を発生及び供給することができる)。
【0083】
クライアント装置は、オペレーション300において、サーバーからプレイリストファイルを要求する。一実施形態では、この要求は、HTTP適合のプロトコルに基づいて行われる。この要求は、サーバーに記憶された初期プレイリストファイルに対するURIを使用する。別の実施形態では、他の非ストリーミングプロトコルをサポートすることもできる。この要求に応答して、サーバーは、それに対応するプレイリストファイルを、ネットワークを経てクライアントへ送信する。上述したように、ネットワークは、ワイヤード又はワイヤレスであり、又、ワイヤード又はワイヤレスネットワークの組み合わせでもよい。更に、ネットワークは、データネットワーク(例えば、IEEE802.11、IEEE802.16)でもよいし、セルラー電話ネットワーク(例えば、3G)でもよい。
【0084】
クライアント装置は、オペレーション310において、プレイリストファイルを受け取ることができる。プレイリストファイルは、オペレーション320において、クライアント装置のメモリに記憶することができる。メモリは、例えば、ハードディスク、フラッシュメモリ、ランダムアクセスメモリである。一実施形態では、プレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、クライアントは、プレイリストファイルが#EXTM3Uタグで始まり、そしてタグが存在しない場合には継続しないことを決定するためのチェックを行う。上述したように、プレイリストファイルは、1つ以上のタグと、メディアファイルに対する1つ以上のURIとを含む。
【0085】
クライアント装置は、オペレーション330において、プレイリストファイルのURIにより指示されたメディアファイルを要求することによりプレイリストファイルを使用してオリジナルコンテンツを再アッセンブルするアッセンブラーエージェントを含むことができる。一実施形態では、このアッセンブラーエージェントは、標準ウェブブラウザアプリケーションの一部分であるプラグインモジュールである。別の実施形態では、アッセンブラーエージェントは、ウェブブラウザと対話し、プレイリストファイルを使用してメディアファイルを受け取りアッセンブルするスタンドアローンアプリケーションでもよい。更に別の例として、アッセンブラーエージェントは、クライアント装置に埋め込まれる特殊目的のハードウェア又はファームウェアコンポーネントでもよい。
【0086】
このアッセンブラーは、プレイリストファイルからのメディアファイルを、URIにより指示されたサーバーからダウンロードさせる。プレイリストファイルがEXT−X−ENDLISTタグを含む場合には、プレイリストファイルにより指示されたメディアファイルが最初に再生される。EXT−X−ENDLISTタグが存在しない場合には、最後と最後から2番目のメディアファイルを除くメディアファイルが最初に再生される。再生すべき最初のメディアファイルが選択されると、プレイリストファイルにおける後続メディアファイルは、一実施形態では、それらがプレイリストファイルに現れる順序でロードされる(さもなければ、コンテンツは、無秩序に提示される)。一実施形態では、クライアント装置は、中断のない再生を与えると共にネットワークの待ち時間及びスループットの時間的変化を補償するために、メディアファイルが要求される以前にそれらをロードする(そしてそれらをバッファに記憶する)ように試みる。
【0087】
ダウンロードされたメディアファイルは、オペレーション340において、クライアント装置のメモリに記憶することができる。コンテンツを記憶することのできるメモリは、クライアント装置における任意の形式のメモリであり、例えば、ランダムアクセスメモリ、ハードディスク又はビデオバッファである。記憶は、再生を許すために一時的でもよいし、又は永久的でもよい。プレイリストファイルがEXT−X−ALLOW−CACHEタグを含み、その値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後は、記憶しない。プレイリストがEXT−X−ALLOW−CACHEタグを含み、その値がYESである場合には、クライアントは、メディアファイルを、後で再生するために不定に記憶する。クライアント装置は、EXT−X−PROGRAM−DATE−TIMEタグの値を使用して、番組起点時間をユーザに表示する。一実施形態では、クライアントは、複数のメディアファイルをバッファして、ネットワークジッタの影響を受け難くし、良好なユーザ経験を与えることができるようにする。
【0088】
一実施形態において、解読方法がAES−128である場合に、AES−128 CBC解読が個々のメディアファイルに適用される。ファイル全体が解読される。一実施形態では、メディアファイルにわたって暗号ブロックチェーンが適用されない。メディアファイルのシーケンス番号は、上述したように初期化ベクトルとして使用することができる。
【0089】
メモリからのコンテンツは、オペレーション350において、クライアント装置から出力することができる。出力又は提示は、例えば、内蔵スピーカ又はヘッドホンを経て出力されるオーディオである。出力は、スクリーンを経て出力されるか又はクライアント装置から投影されるビデオを含む。この技術で知られた任意の形式の出力を使用することができる。オペレーション351において、クライアント装置は、記憶された現在プレイリストに再生も提示もされていないメディアファイルがもっとあるかどうか決定する。そのようなメディアファイルが存在する(且つそれらが要求されていない)場合には、1つ以上のメディアファイルが要求されるオペレーション330へ処理が復帰し、プロセスが繰り返される。このようなメディアファイルがない(即ち、現在プレイリストにおける全てのメディアファイルが再生されている)場合には、処理がオペレーション352へ進み、これは、プレイリストファイルが終了タグを含むかどうか決定する。
【0090】
オペレーション352において、プレイリストが終了タグ(例えば、EXT−X−ENDLIST)を含む場合には、プレイリストファイルにより指示されたメディアファイルが再生されたときに再生が終わる。終了タグがプレイリストにない場合には、クライアント装置は、サーバーからプレイリストを再び要求し、そしてオペレーション300へ復帰して、番組のための更に別の又は更新されたプレイリストを得る。
【0091】
図2Bを参照して詳細に説明したように、サーバーは、補足的コンテンツ(例えば、生放送における付加的なメディアコンテンツに対応する付加的なメディアファイル識別子)又は付加的なコンテンツ(例えば、ストリームの更に下流のコンテンツ)を導入するためにプレイリストファイルを更新する。この補足的コンテンツ又は付加的なコンテンツにアクセスするために、クライアントは、更新されたプレイリストをサーバーから再ロードすることができる。これは、プレイリストファイルに関連したメディアコンテンツの再生中でも、プレイリストファイルを動的に更新できるメカニズムを与える。クライアントは、多数のトリガーに基づいてプレイリストファイルの再ロードを要求する。終了タグの欠如は、1つのこのようなトリガーである。
【0092】
一実施形態では、クライアント装置は、プレイリストファイルがEXT−X−ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードする。クライアント装置が、プレイリストファイルを初めてロードするとき、又はプレイリストファイルを再ロードしそしてそれが前回ロードされて以来変化したことが分かったときには、クライアントは、再びプレイリストファイルを再ロードするよう試みる前に、ある時間周期待機することができる。この周期は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのロードを開始する時間から測定される。
【0093】
一実施形態では、初期最小再ロード遅延は、プレイリストファイルにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある時間周期待機することができる。一実施形態における最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。一実施形態では、この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0であるが、他の倍数が使用されてもよい。
【0094】
プレイリストファイルがロード又は再ロードされるたびに、クライアント装置は、プレイリストファイルを検査して、ロードすべき次のメディアファイルを決定する。ロードすべき第1のファイルは、上述したように、最初に再生するように選択されたメディアファイルである。再生されるべき第1のメディアファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証することができ、ファイルが見つからない場合には再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIである。
【0095】
再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものである。プレイリストファイルが、キーファイルURIを特定するEXT−X−KEYタグを含む場合には、クライアント装置は、キーファイルを得、そしてキーファイル内のキーを使用して、別のEXT−X−KEYタグに遭遇するまで、そのEXT−X−KEYタグに続くメディアファイルを解読する。
【0096】
一実施形態では、クライアント装置は、以前に使用した同じURIを使用して、プレイリストファイルをダウンロードする。従って、プレイリストファイルに変更がなされた場合には、クライアント装置は、更新されたプレイリストファイルを使用して、メディアファイルを検索し、そしてそのメディアファイルに基づいて出力を与える。
【0097】
プレイリストファイルの変更は、例えば、メディアファイルに対するURIの削除、新たなメディアファイルに対するURIの追加、置き換えメディアファイルに対するURIの置き換えを含む。プレイリストファイルに変更がなされるときには、その変更を反映するように1つ以上のタグが更新される。例えば、メディアファイルの変更で、プレイリストファイルによって指示されるメディアファイルの再生の期間に変更が生じる場合には、期間タグが更新される。
【0098】
図3Bは、クライアント装置が、代替えストリームの一形態である複数のビットレートを使用するコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。
【0099】
オペレーション370において、クライアント装置は、プレイリストファイルを要求することができる。上述したように、プレイリストファイルは、クライアント装置に与えられるURIを使用して検索される。一実施形態では、プレイリストファイルは、同じコンテンツを異なるビットレートで与えるためにメディアファイルの変形ストリームのリストを含み、換言すれば、単一のプレイリストファイルは、各変形ストリームのメディアファイルに対するURIを含む。図3Bに示す例は、この実施形態を使用する。別の実施形態では、変形ストリームは、クライアントに別々に与えられる複数の個別のプレイリストファイルにより、その各々が同じコンテンツを異なるビットレートで与えるように表され、そして変形プレイリストは、個別のプレイリストファイルの各々に対してURIを与えることができる。これは、クライアント装置がクライアントの条件に基づいてビットレートを選択できるようにする。
【0100】
オペレーション375において、プレイリストファイルは、クライアント装置によって検索することができる。オペレーション380において、プレイリストファイルは、クライアント装置のメモリに記憶することができる。クライアント装置は、オペレーション385において、使用すべきビットレートを、現在ネットワークの接続速度に基づいて選択する。メディアファイルは、オペレーション390において、選択されたビットレートに対応するプレイリストファイルに含まれたURIを使用してサーバーから要求される。検索されたメディアファイルは、クライアント装置のメモリに記憶することができる。出力は、オペレーション394において、メディアファイルを使用してクライアント装置により与えられ、そしてクライアント装置は、ビットレートを変更すべきかどうか決定する。
【0101】
一実施形態において、クライアント装置は、最初に利用可能な最低ビットレートを選択する。メディアを再生する間に、クライアント装置は、利用可能な帯域巾(例えば、現在ネットワークの接続ビットレート)を監視して、その利用可能な帯域巾が再生のためにより高いビットレートの使用をサポートできるかどうか決定することができる。もしそうであれば、クライアント装置は、より高いビットレートを選択し、そしてより高いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。その逆をサポートすることもできる。再生が著しい帯域巾を消費する場合には、クライアント装置は、より低いビットレートを選択し、そしてより低いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。
【0102】
クライアント装置が、オペレーション394において、例えば、利用可能な帯域巾の変更に応答し又はユーザ入力に応答して、ビットレートを変更する場合には、クライアント装置は、オペレーション385において、異なるビットレートを選択することができる。一実施形態では、異なるビットレートを選択するために、クライアント装置は、新たに選択されたビットレートに対応するプレイリストファイルに含まれたURIの異なるリストを利用することができる。一実施形態では、クライアント装置は、プレイリスト内のメディアファイルのアクセス中にビットレートを変更することができる。
【0103】
オペレーション394においてビットレートが変更されない場合に、クライアント装置は、検索及び提示されていない未再生のメディアファイルが現在プレイリストにもっとあるかどうか決定する。そのようなメディアファイルが存在する場合には、処理がオペレーション390へ復帰し、そしてプレイリストにおけるそれらのファイルに対するURIを使用して1つ以上のメディアファイルが検索される。そのようなメディアファイルがない(即ち、現在プレイリストにおける全てのメディアファイルが再生された)場合には、処理がオペレーション396へ進み、プレイリストが終了タグを含むかどうか決定される。もしそうであれば、番組の再生が終了で、プロセスが完了であるが、もしそうでなければ、処理がオペレーション370へ復帰し、クライアント装置は、番組に対するプレイリストを再ロードすることを要求し、図3Bに示す方法を通してプロセスが繰り返される。
【0104】
図4は、サーバーストリームエージェントの一実施形態のブロック図である。サーバーストリームエージェント400の要素は、多数のサーバー装置にわたって分散できることを理解されたい。例えば、第1のサーバー装置は、セグメンタ430、インデクサ440及びセキュリティ450を含むが、ファイルサーバー460は含まず、又、第2のサーバー装置は、ファイルサーバー450を含むが、セグメンタ430、インデクサ440及びセキュリティ450は含まない。この例では、第1のサーバー装置は、プレイリスト及びメディアファイルを準備するが、それらをクライアント装置へ送信せず、一方、1つ以上の第2のサーバー装置は、プレイリスト及びメディアファイルを受け取って任意に記憶し、そしてプレイリスト及びメディアファイルをクライアント装置へ送信する。サーバーストリームエージェント400は、サーバーストリームエージェント400のオペレーションを指令する論理機能制御を具現化する制御ロジック410と、サーバーストリームエージェント400のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路、又はソフトウェアルーチン、又はファームウェアである。一実施形態では、サーバーストリームエージェント400は、制御ロジック410にインストラクションを与えるコードシーケンス及び/又はプログラムを表す1つ以上のアプリケーション412を備えている。
【0105】
サーバーストリームエージェント400は、データ又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ414を備えている。このメモリ414は、サーバーストリームエージェント400に対してローカルのメモリを含んでもよいし、或いは又サーバーストリームエージェント400が存在するホストシステムのメモリを含んでもよい。又、サーバーストリームエージェント400は、サーバーストリームエージェント400の外部のエンティティ(電子装置又は人間)に関してサーバーストリームエージェント400への/からのアクセスインターフェイス(入力/出力インターフェイス)を表す1つ以上のインターフェイス416も備えている。
【0106】
又、サーバーストリームエージェント400は、サーバーストリームエージェント400がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すサーバーストリームエンジン420も備えている。図4の例は、サーバーストリームエンジン420に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、セグメンタ430、インデクサ440、セキュリティ450、及びファイルサーバー460を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。
【0107】
セグメンタ430は、与えられるべきコンテンツを、ウェブサーバープロトコル(例えば、HTTP)を使用してファイルとして送信できるメディアファイルへと分割する。例えば、セグメンタ430は、コンテンツを、所定のファイルフォーマットにおける所定の固定サイズのデータブロックへと分割する。
【0108】
インデクサ440は、セグメンタ430によって生成されるメディアファイルに対するURI又はアドレスを与える1つ以上のプレイリストファイルを発生する。インデクサ440は、例えば、セグメンタ430により生成される各ファイルに対応する識別子のための順序のリストを伴う1つ以上のファイルを生成する。それら識別子は、セグメンタ430又はインデクサ440によって生成され又は指定される。又、インデクサ440は、メディアファイルのアクセス及び/又は利用をサポートするためにプレイリストファイルに1つ以上のタグを含むこともできる。
【0109】
セキュリティ450は、上述したようなセキュリティ特徴(例えば、暗号化)を与えることができる。ウェブサーバー460は、ホストシステムに記憶されたファイルをリモートクライアント装置に与えることに関連したウェブサーバー機能を発揮する。ウェブサーバー460は、例えば、HTTP適合のプロトコルをサポートする。
【0110】
図5は、クライアントストリームエージェントの一実施形態のブロック図である。クライアントストリームエージェントの要素は、多数のクライアント装置にわたって分散できることを理解されたい。例えば、第1のクライアント装置は、アッセンブラー530及びセキュリティ550を備え、そしてメディアファイルの解読されたストリームを第2のクライアント装置へ供給することができ、この第2のクライアント装置は、出力ジェネレータ540を含む(が、アッセンブラー530及びセキュリティ550は含まない)。別の例では、一次クライアント装置がプレイリストを検索してそれを二次クライアント装置へ供給することができ、この二次クライアント装置は、プレイリストにおいて特定されたメディアファイルを検索して、それらメディアファイルを提示するための出力を発生する。クライアントストリームエージェント500は、このクライアントストリームエージェント500のオペレーションを指令するための論理機能的制御を具現化する制御ロジック510と、このクライアントストリームエージェント500のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路或いはソフトウェアルーチン又はファームウェアでよい。一実施形態では、クライアントストリームエージェント500は、制御ロジック510にインストラクションを与えるコードシーケンス又はプログラムを表す1つ以上のアプリケーション512を備えている。
【0111】
クライアントストリームエージェント500は、データ及び/又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ514を備えている。このメモリ514は、クライアントストリームエージェント500に対してローカルのメモリを含んでもよいし、或いは又クライアントストリームエージェント500が存在するホストシステムのメモリを含んでもよい。又、クライアントストリームエージェント500は、クライアントストリームエージェント500の外部のエンティティ(電子装置又は人間)に関してクライアントストリームエージェント500への/からのアクセスインターフェイス(入力/出力インターフェイス)を表す1つ以上のインターフェイス516も備えている。
【0112】
又、クライアントストリームエージェント500は、このクライアントストリームエージェント500がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すクライアントストリームエンジン520も備えている。図5の例は、クライアントストリームエンジン520に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、アッセンブラー530、出力ジェネレータ540、及びセキュリティ550を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。
【0113】
アッセンブラー530は、サーバーから受け取られたプレイリストファイルを使用して、サーバーからウェブサーバープロトコル(例えば、HTTP)を経てメディアファイルにアクセスすることができる。一実施形態では、アッセンブラー530は、プレイリストファイルにおいてURIにより指示されたメディアファイルをダウンロードさせる。アッセンブラー530は、プレイリストファイルに含まれたタグに応答する。
【0114】
出力ジェネレータ540は、受け取ったメディアファイルをホストシステムにおいてオーディオ又はビジュアル出力(又はオーディオ及びビジュアルの両方)として発生する。出力ジェネレータ540は、例えば、オーディオを1つ以上のスピーカへ出力させそしてビデオをディスプレイ装置へ出力させる。セキュリティ550は、上述したようなセキュリティ特徴を与える。
【0115】
図6は、複数のタグを伴うプレイリストファイルの一実施形態を示す図である。図6の規範的なプレイリストは、特定数及び順序のタグを含む。これは、説明上のものに過ぎない。あるプレイリストファイルは、より多くの又はより少ない、或いは異なる組み合わせのタグを含み、そしてタグは、図6に示すものとは異なる順序で配列することができる。
【0116】
開始タグ610は、プレイリストファイルの開始を指示することができる。一実施形態において、開始タグ610は、#EXTM3Uタグである。期間タグ620は、再生リストの期間を指示することができる。即ち、再生リスト600により指示されるメディアファイルの再生の期間である。一実施形態において、期間タグ620は、EXT−X−TARGETDURATIONタグであるが、他のタグも使用できる。
【0117】
日付/時刻タグ625は、再生リスト600により指示されたメディアファイルにより与えられるコンテンツの日付及び時刻に関連した情報を与えることができる。一実施形態では、日付/時刻タグ625は、EXT−X−PROGRAM−DATE−TIMTタグであるが、他のタグを使用することもできる。シーケンスタグ630は、プレイリストのシーケンスにおけるプレイリストファイル600のシーケンスを指示することができる。一実施形態では、シーケンスタグ630は、EXT−X−MEDIA−SEQUENCEタグであるが、他のタグも使用できる。
【0118】
セキュリティタグ640は、プレイリストファイル600により指示されたメディアファイルに適用されるセキュリティ及び/又は暗号化に関連した情報を与えることができる。例えば、セキュリティタグ640は、メディアファイルインジケータにより特定されたファイルを解読するための解読キーを特定することができる。一実施形態では、セキュリティタグ640は、EXT−X−KEYタグであるが、他のタグを使用することもできる。変形リストタグ645は、変形ストリームがプレイリスト600により与えられるかどうか指示すると共に、変形ストリームに関する情報(例えば、どれほど多く、ビットレート)を指示することができる。一実施形態では、変形リストタグ645は、EXT−X−STREAM−INFタグである。
【0119】
メディアファイルインジケータ650は、再生されるべきメディアファイルに関する情報を与えることができる。一実施形態では、メディアファイルインジケータ650は、再生されるべき複数のメディアファイルに対するURIを含む。又、一実施形態では、プレイリスト600におけるURIの順序は、メディアファイルにアクセスし及び/又は再生しなければならない順序に対応する。その後のプレイリストインジケータ660は、再生ファイル600の後に使用されるべき1つ以上の再生ファイルに関連した情報を与えることができる。一実施形態では、その後のプレイリストインジケータ660は、プレイリスト600のメディアファイルが再生された後に使用されるべき1つ以上のプレイリストファイルに対するURIを含むことができる。
【0120】
メモリタグ670は、メディアファイルコンテンツの再生後にクライアント装置がメディアファイルを記憶できるかどうか及び/又はどれほど長く記憶できるか指示することができる。一実施形態では、メモリタグ670は、EXT−X−ALLOW−CACHEタグである。終了タグ680は、プレイリストファイル600が提示のための最後のプレイリストファイルであるかどうか指示する。一実施形態では、終了タグ680は、EXT−X−ENDLISTタグである。
【0121】
次の章は、一実施形態による幾つかの規範的なプレイリストファイルを含む。
簡単なプレイリストファイル
#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
【0122】
図7は、ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。一実施形態において、受け取られたメディアファイルの再生は、スタート、ストップ、巻き戻し、等のためにユーザにより制御することができる。プレイリストファイルは、オペレーション700において、クライアント装置により受け取られる。オペレーション710において、プレイリストファイルにより指示されたメディアファイルが検索される。オペレーション720において、受け取られたメディアファイルに基づいて出力が発生される。メディアファイルの受け取り及びそのメディアファイルに基づく出力の発生は、上述したように行うことができる。
【0123】
オペレーション730において制御入力が検出された場合には、クライアント装置は、オペレーション740において入力がストップを指示するかどうか決定することができる。入力がストップである場合には、プロセスが終了となり、再生がストップする。オペレーション750において入力が巻き戻し又は送り要求を指示する場合には、クライアント装置は、オペレーション760において、メモリにまだ記憶されている以前に再生されたメディアファイルに基づいて出力を発生することができる。これらファイルがキャッシュにもはやない場合には、処理がオペレーション710へ復帰し、メディアファイルを検索してプロセスを繰り返す。別の実施形態では、再生は、ストップ入力のような再生の終了を伴わずに再生をハルトする休止特徴をサポートすることができる。
【0124】
あるストリームから別のストリームへ遷移させる方法を、図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のストリームの受け取りを停止することができる。
【0125】
図9Bは、クライアント装置が、オペレーション921及び923において第1のメディアプレイリスト(例えば、第1のストリーム)により特定されたコンテンツを検索し、記憶し及び提示し、そして第1のプレイリストにより特定されたコンテンツが提示される間に、オペレーション925において、クライアント装置が、第2のメディアプレイリスト(例えば、第2のストリーム)により特定されたコンテンツを検索し及び記憶することを示している。第1のメディアプレイリストから得たコンテンツを提示している間に第2のメディアプレイリストにより特定されたコンテンツを検索し(例えば、一時的バッファに)記憶することで、番組コンテンツの時間的なオーバーラップ955(図9Dに示す)を生成し、これは、クライアント装置が、番組を実質的に中断せずに番組のバージョン間をスイッチングできるようにする。このように、番組のバージョン間のスイッチングは、多くの場合に、スイッチングが生じることをユーザに通知せずに(ある場合には、スイッチングの後の高解像度の画像にユーザが気付くことがあるが)、又は番組提示の実質的な中断なしに、行うことができる。オペレーション927において、クライアント装置は、第1のメディアプレイリストにより特定されたコンテンツから第2のメディアプレイリストにより特定されたコンテンツへスイッチングすべき遷移点を決定し、遷移点の一例(遷移点959)が図9Dに示されている。第2のメディアプレイリストにより特定されたコンテンツは、スイッチングの後に、オペレーション931において提示される。
【0126】
図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のストリームを使用する。前記方法は、一実施形態では、低速ビットレートから高速ビットレートへの変化、及び高速ビットレートから低速ビットレートへの変化の両方に使用することができるが、別の実施形態では、この方法は、低速ビットレートから高速ビットレートへの変化にしか使用できず、高速ビットレートから低速ビットレートへの変化には別の方法(例えば、遷移点を位置付けるよう試みず、低速ビットレートストリームからできるだけ即座にコンテンツを記憶し提示するよう試みる)を使用することができる。
【0127】
図10は、代替えストリームを使用してクライアント装置へプレイリスト又はメディアコンテンツ或いはその両方を与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。プレイリストが上述した代替えストリームを含む場合に、その代替えストリームは、帯域巾又は装置の代替え物として動作するだけでなく、故障フォールバックとして動作することもできる。例えば、クライアントが(例えば、404エラー又はネットワーク接続エラーのために)ストリームに対するプレイリストファイルを再ロードできない場合には、クライアントは、代替えストリームへスイッチするよう試みることができる。図10を参照すれば、フェイルオーバー保護を具現化するために、第1のサーバー装置又は第1のコンテンツ配布サービスは、図2Cを参照して述べたように、オペレーション1002において、ストリーム又は複数の代替え帯域巾ストリームを生成するように構成される。オペレーション1004において、第1のサーバー装置又は第1のコンテンツ配布サービスは、オペレーション1002において発生されたストリームからプレイリストファイルを発生する。第1のサーバー装置又は第2のコンテンツ配布サービスは、オペレーション1006において、並列ストリーム又はストリームのセットを生成すると共に、プレイリストも生成する。これらの並列ストリームは、バックアップストリームと考えることができる。次いで、バックアップストリームのリストがオペレーション1008においてプレイリストファイルに追加され、一次ストリームの後に、各帯域巾のバックアップストリームがリストされるようにする。例えば、一次ストリームがサーバーALPHAから到来しそしてバックアップストリームがサーバーBETAにある場合には、プレイリストファイルが次のようになる。
#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
【0128】
バックアップストリームは、各帯域巾のバックアップがその帯域巾に対する一次の後にリストされたプレイリストにおける一次ストリームと混合されることに注意されたい。クライアントは、単一のバックアップストリームセットに限定されない。上述した例において、ALPHA及びBETAの後に、例えば、GAMMAが続く。同様に、ストリームの完全な並列セットを与える必要はない。例えば、単一の低帯域巾ストリームがバックアップサーバーに与えられる。
【0129】
オペレーション1010において、クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のURLからプレイリストファイルをダウンロードするように試みる。図11は、一実施形態により、クライアント1102が、1つ以上のURL、サーバー装置又はコンテンツ配布サービスと両方向に通信するネットワークを示す。プレイリストファイルは、オペレーション1012において、第1のURL、サーバー装置又はコンテンツ配布サービスからクライアント1102へ送信される。クライアントが、第1のURL、サーバー装置又はコンテンツ配布サービスからプレイリストファイルをダウンロードできない(例えば、ストリームのインデックスファイルを再ロードするエラーのために)場合には、クライアントは、代替えストリームへスイッチするよう試みる。1つのストリームに欠陥(例えば、インデックスロード欠陥)がある場合には(例えば、オペレーション1010)、クライアントは、オペレーション1014においてネットワーク接続がサポートする最も高い帯域巾の代替えストリームを選択する。同じ帯域巾の複数の代替え物がある場合には、クライアントは、プレイリストに載せられた順序でそれらを選択する。例えば、クライアント1102がURL 1から首尾よくダウンロードできない場合には、URL 2又は別のURLからダウンロードしてもよく、この場合、プレイリストファイルは、代替えURLからクライアントへ送信される。この特徴は、サーバーのクラッシュやコンテンツ配布ノードの故障のような厳しいローカル欠陥の場合でも、メディアがクライアントに到達できるようにする冗長なストリームを与える。
【0130】
フェイルオーバー保護は、クライアントがプレイリスト及びメディアファイルを検索できるところの複数の冗長な位置を与える能力を備えている。従って、クライアントが第1の位置からストリームを検索できない場合には、第2、第3、等の位置からストリームにアクセスするよう試みることができる。
【0131】
一実施形態において、クライアントがプレイリストを検索できるところの付加的な位置を指示するため、同じ変形プレイリストタグに、同じ帯域巾であるが新たなURIの冗長位置が与えられる。クライアントは、最初に、望ましい帯域巾に関連した第1のURLにアクセスするよう試みることができる。第1のURLからプレイリストをダウンロードできない場合には、帯域巾に対して提示される次のURLにアクセスするよう試み、等々、全ての可能性が尽きるまで行う。
【0132】
以下の例は、2560000帯域巾に対する1冗長位置、及び7680000帯域巾に対する2冗長位置を含む。
#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
【0133】
この例において、ファイルネーム(例えば、mid-redundant2.m3u8)及び実際のURL(例えば、http://example2.com <http://example2.com/> ,http://example3.com <http://example3.com/>)の両方が変化することに注意されたい。しかしながら、一実施形態では、冗長位置は、ファイルネームに対してのみ又はウェブサイトに対してのみ変化する。
【0134】
一実施形態において、プレイリストは、サーバー装置によって圧縮されて、圧縮形態でクライアント装置へ送られる。圧縮されたプレイリストは、通常、プレイリストを表現するのに非圧縮のプレイリストより少数のビットしか必要とせず、従って、圧縮されたプレイリストは、送信又は受信されるときに、ワイヤレスセルラー電話ネットワークのようなネットワークの利用可能な帯域巾をあまり使用しない。一実施形態では、プレイリストは、HTTP1.1規格プロトコルのような転送プロトコルに適合又は適合するウェブサーバーによって使用される内蔵圧縮技術又はファシリティに基づいてウェブサーバーにより圧縮することができ、このような圧縮技術又はファシリティの一例は、HTTP1.1のデフレート又はgzip圧縮ファシリティである。他の実施形態では、規格ベースの転送プロトコルの一部分である他の規格ベースの圧縮ファシリティを使用することができる。圧縮されたプレイリストの使用は、一実施形態では、サーバー装置及びクライアント装置の任意の特徴である。一実施形態では、プレイリストは、テクスチャーコンテンツ(例えば、テキストファイル)であり、規格ベースのウェブサーバーによりデフレート又はgzipで効率的に圧縮され、次いで、クライアント装置により自動的に解凍される。gzip圧縮ファシリティのバージョンの説明は、www.ietf.org/rfc/rfc1952.txtに見ることができ、デフレート圧縮ファシリティのバージョンは、www.ietf.org/rfc/rfc1951.txtに見ることができる。多数のウェブサーバー、及びクライアント装置の多数のウェブブラウザは、デフレート又はgzipファシリティを自動的にサポートすることができる。
【0135】
一実施形態において、クライアント装置は、更新されたプレイリストを周期的に要求することができ、例えば、クライアント装置は、サーバーから、更新されたプレイリストを数秒ごとに(例えば、10、20又は30秒ごとに、或いは他の時間周期で)要求することができる。クライアントが生のゲーム中の任意の時点で生のゲームを始めから見始めるのを許す生の進行中の野球ゲームのプレイリストのような成長するプレイリストは、その成長するプレイリストがネットワークを通して繰り返し送信されるので、圧縮の使用でネットワークの帯域巾の消費を制限できるに充分な大きさとなる。
【0136】
一実施形態において、クライアント装置は、いつプレイリスト(更新されたプレイリストのような)を要求するか、どんな圧縮技術(デフレート又はgzipのような)をサポートできるか、任意に特定することができ、これら技術をサポートすることは、クライアント装置が、圧縮又はエンコードされたコンテンツを解読又はデコードできることを意味する。圧縮技術を任意に特定したクライアント装置のプレイリスト要求は、一実施形態において、プレイリストに対する圧縮技術をサポートすることが要求されずに非圧縮のプレイリストを送信できるウェブサーバーによって受け取られる。ウェブサーバーは、クライアント装置の要求に応答して、非圧縮のプレイリスト、又はプレイリストに対するクライアント装置の要求で特定された圧縮技術の1つを使用して圧縮されたプレイリストをクライアント装置へ送信することができる。クライアント装置は、プレイリストを受け取り、そしてそれをここに述べるように使用し、即ちプレイリストが圧縮された場合には、クライアント装置のウェブブラウザにおけるデコーダのようなクライアント装置のデコーダを使用してそれがデコードされる。
【0137】
図8は、電子システムの一実施形態のブロック図である。図8に示す電子システムは、例えば、デスクトップコンピュータシステム、ラップトップコンピュータシステム、セルラー電話、セルラーイネーブルPDAを含むパーソナルデジタルアシスタント(PDA)、セットトップボックス、娯楽システム、又は他の消費者向け電子装置を含むある範囲の電子システム(ワイヤード又はワイヤレス)を表すことが意図される。代替え電子システムは、より多くの、より少ない及び/又は異なるコンポーネントを含んでもよい。図8の電子システムは、クライアント装置及び/又はサーバー装置を構成するように使用されてもよい。
【0138】
電子システム800は、情報を通信するためのバス805又は他の通信装置と、情報を処理するためにバス805に結合されたプロセッサ810とを備えている。電子システム800は、単一のプロセッサをもつように示されているが、電子システム800は、複数のプロセッサ及び/又はコプロセッサを含んでもよい。電子システム800は、更に、バス805に結合されたランダムアクセスメモリ(RAM)又は他のダイナミック記憶装置820(メインメモリと称される)を備え、これは、プロセッサ810により実行されるインストラクション及び情報を記憶する。又、このメインメモリ820は、プロセッサ810によるインストラクションの実行中に変数又は他の中間情報を一時的に記憶するように使用されてもよい。
【0139】
電子システム800は、バス805に結合されたリードオンリメモリ(ROM)及び/又は他のスタティック記憶装置830も備え、これは、プロセッサ810のためのスタティック情報及びインストラクションを記憶する。データ記憶装置840は、情報及びインストラクションを記憶するためにバス805に結合される。フラッシュメモリ又は磁気ディスク又は光学ディスク及びそれに対応するドライブのようなデータ記憶装置840が、電子システム800に結合される。
【0140】
又、電子システム800は、バス805を経て、陰極線管(CRT)又は液晶ディスプレイ(LCD)のようなディスプレイ装置850に結合され、ユーザに情報を表示する。又、電子システム800は、アルファニューメリック及び他のキーを含むアルファニューメリック入力装置860も備え、これは、情報及びコマンド選択をプロセッサ810へ通信するためにバス805に結合される。別の形式のユーザ入力装置は、方向情報及びコマンド選択をプロセッサ810へ通信すると共に、ディスプレイ850上のカーソル移動を制御するための、タッチパッド、マウス、トラックボール又はカーソル方向キーのようなカーソルコントロール870である。
【0141】
更に、電子システム800は、ローカルエリアネットワークのようなネットワークにアクセスを与えるために1つ以上のネットワークインターフェイス880を備えている。このネットワークインターフェイス880は、例えば、1つ以上のアンテナを表すアンテナ885を有するワイヤレスネットワークインターフェイスを含む。又、電子システム800は、WiFi、ブルーツース、及びセルラー電話インターフェイスの組み合わせのような複数のワイヤレスネットワークインターフェイスを含むことができる。又、ネットワークインターフェイス880は、例えば、イーサネットケーブル、同軸ケーブル、光ファイバケーブル、シリアルケーブル、又はパラレルケーブルのようなネットワークケーブル887を経て、リモート装置と通信するためのワイヤードネットワークインターフェイスも含む。
【0142】
一実施形態において、ネットワークインターフェイス880は、例えば、IEEE802.11b及び/又はIEEE802.11g規格に適合することにより、ローカルエリアネットワークへのアクセスを与え、及び/又はワイヤレスネットワークインターフェイスは、例えば、ブルーツース規格に適合することにより、パーソナルアクセスネットワークへのアクセスを与えることができる。他のワイヤレスネットワークインターフェイス及び/又はプロトコルをサポートすることもできる。
【0143】
ワイヤレスLAN規格を経ての通信に加えて又はそれに代わって、ネットワークインターフェイス880は、例えば、時分割多重アクセス(TDMA)プロトコル、移動通信用のグローバルシステム(GSM)プロトコル、コード分割多重アクセス(CDMA)プロトコル、及び/又は他の形式のワイヤレス通信プロトコルを使用して、ワイヤレス通信を行うことができる。
【0144】
本明細書において「一実施形態」又は「実施形態」とは、その実施形態に関連して述べた特定の特徴、構造又は特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。本明細書の種々の場所に「一実施形態」という句が現れたときには、必ずしも、全てが同じ実施形態を指すのではない。
【0145】
以上、本発明の特定の実施形態を説明したが、本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、明細書及び添付図面は、本発明を単に例示するものであって、それに限定されるものではない。
【0146】
アペンディックス
以下のアペンディックスは、本発明の特定の実施形態によるプロトコルのドラフト仕様書である。このアペンディックスにおける幾つかのキーワード(例えば、MUST、MUST NOT、SHALL、SHALL NOT、等)の使用は、この特定の実施形態に適用されるもので、本開示に述べる他の実施形態には適用されないことが理解されよう。
概略
本書は、HTTPを経てマルチメディアデータの無限のストリームを送信するためのプロトコルについて述べる。これは、ファイルのデータフォーマットと、ストリームのサーバー(送信者)及びクライアント(受信者)により行われるアクションとを特定する。このプロトコルのバージョン1.0について述べる。
目次
1.序文
2.概要
3.プレイリストファイル
3.1.新たなタグ
3.1.1.EXT−X−TARGETDURATION
3.1.2.EXT−X−MEDIA−SEQUENCE
3.1.3.XEX−X−KEY
3.1.4.EXT−X−PROGRAM−DATE−TIME
3.1.5.EXT−X−ALLOW−CACHE
3.1.6.EXT−X−ENDLIST
3.1.7.EXT−X−STREAM−INF
3.1.8.EXT−X−DISCONTINUITY
4.メディアファイル
5.キーファイル
5.1.AES−128のためのIV
6.クライアント/サーバーアクション
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.参照文献
規範的参照文献
情報参照文献
【0147】
1.序文
本書は、HTTP[RFC2616]を経てマルチメディアデータの無限ストリームを送信するためのプロトコルについて述べる。このプロトコルは、メディアデータの暗号化と、ストリームの代替えバージョン(例えば、ビットレート)の付与とをサポートする。メディアデータは、それが生成されるや否や送信され、ほぼリアルタイムで受け取ることができるようにする。
HTTPのような関連規格について述べる外部の参照文献は、第9章に列挙する。
2.概要
マルチメディアの提示は、付加的なURIの順序付けされたリストであるプレイリストファイルに対するURI[RFC3986]により特定される。プレイリストファイルの各URIは、単一の隣接ストリームのセグメントであるメディアファイルを指す。
ストリームを再生するために、クライアントは、先ず、プレイリストファイルを得、そしてプレイリスト内の各メディアファイルを得て再生する。本書に述べるようにプレイリストファイルを再ロードして、付加的なセグメントを発見する。
本書におけるキーワード“MUST”“MUST NOT”“REQUIRED”“SHALL”“SHALL NOT”“SHOULD”“SHOULD NOT”“RECOMMENDED”“MAY”及び“OPTIONAL”は、RFC2119[RFC2119]に述べるように解釈されるべきである。
3.プレイリストファイル
プレイリストは、拡張型のM3Uプレイリストファイル[M3U]でなければならない(MUST)。本書は、付加的なタグを定義することによりM3Uファイルフォーマットを拡張する。
M3Uプレイリストは、個々のラインより成るテキストファイルである。それらラインは、単一のLFキャラクタか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了となる。各ラインは、URI、ブランクであるか、又はコメントキャラクタ‘#’でスタートする。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視される。
コメントキャラクタ‘#’でスタートするラインは、コメント又はタグである。タグは、#EXTで始まる。‘#’で始まる他の全てのラインは、コメントであり、無視しなければならない(SHOULD)。
ネームが.m3u8で終わり及び/又はHTTPコンテンツタイプ“application/vnd.apple.mpegurl”を有するM3Uプレイリストファイルは、UTF−8[RFC3629]でエンコードされる。ネームが.m3uで終わり及び/又はHTTPコンテンツタイプ[RFC2616]“audio/mpegurl”を有するファイルは、US−ASCII[US_ASCII]でエンコードされる。
具現化は、ネームが.m3u8で終わるか、又はHTTPを経て送信される場合にコンテンツタイプ“application/vnd.apple.mpegurl”を有するプレイリストファイルを発生しなければならない(SHOULD)。互換性のために、具現化は、ネームが.m3uで終わり及び/又はHTTPコンテンツタイプ“audio/mpegurl”を有するプレイリストファイルを発生してもよい(MAY)。
拡張型M3Uファイルフォーマットは、2つのタグEXTM3U及びEXTINFを定義する。拡張型M3Uファイルは、基本的M3Uファイルから、#EXTM3Uでなければならない(MUST)その第1ラインにより区別される。
EXTINFは、それに続くURIにより識別されるメディアファイルを記述するレコードマーカーである。各メディアファイルURIは、EXTINFタグが先行しなければならない(MUST)。そのフォーマットは、次の通りである。
#EXTINF:<duration>、<title>
“duration”は、メディアファイルの期間を秒で特定する整数である。この期間は、最も近い整数に丸めねばならない(SHOULD)。カンマに続くラインの残りは、メディアファイルのタイトルである。
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−TARGETDURATION
EXT−X−TARGETDURATIONタグは、主提示に追加される次のメディアファイルのおおよその期間を指示する。これは、プレイリストファイルに現れねばならない(MUST)。そのフォーマットは、次の通りである。
#EXT−X−TARGETDURATION:<seconds>
メディアファイルの実際の期間は、ターゲット期間から若干異なってもよい(MAY)。
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であると考えねばならない(SHALL)。
EXT−X−MEDIA−SEQUENCEタグの取り扱いに関する情報は、第6.2.1章及び第6.2.4章を参照されたい。
3.1.3.EXT−X−KEY
メディアファイルは、暗号化されてもよい(MAY)。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−TIME
EXT−X−PROGRAM−DATE−TIMEタグは、次のメディアファイルの開始を絶対的な日付及び/又は時刻に関連付ける。日付/時刻表現は、ISO/IEC8601:2004[ISO_8601]であり、時間ゾーンを指示しなければならない(SHOULD)。例えば、次の通りである。
#EXT−X−PROGRAM−DATE−TIME:<YYYY-MM-DDThh:mm:ssZ>
3.1.5.EXT−X−ALLOW−CACHE
EXT−X−ALLOW−CACHEタグは、クライアントが、ダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶してもよいか(MAY)どうか指示する。そのフォーマットは、次の通りである。
#EXT−X−ALLOW−CACHE:<YES|NO>
3.1.6.EXT−X−ENDLIST
EXT−X−ENDLISTタグは、それ以上のメディアファイルがプレイリストファイルに追加されないことを指示する。そのフォーマットは、次の通りである。
#EXT−X−ENDLIST
3.1.7.EXT−X−STREAM−INF
EXT−X−STREAM−INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示する。そのフォーマットは、次の通りである。
#EXT−X−STREAM−INF:[attribute=value][,attribute=value]*
<URI>
EXT−X−STREAM−INFタグについて次の属性が定義される。
BANDWIDTH=<n>
但し、nは、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。
PROGRAM−ID=<i>
但し、iは、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。
プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM−IDを伴う複数のEXT−X−STREAM−INF URIを含んでもよい(MAY)。
CODECS=“[format][,format]*”
但し、各フォーマットは、プレイリストファイル内のメディアファイルに存在するメディアサンプル形式を特定する。
有効なフォーマット識別子は、RFC4281[RFC4281]により定義されたISOファイルフォーマットネームスペースにおける識別子である。
3.1.8.EXT−X−DISCONTINUITY
EXT−X−DISCONTINUITYタグは、それに続くメディアファイルが、それに先行するものとは異なる特性を有することを指示する。変更してもよい(MAY)特性のセットは、次の通りである。
○ファイルフォーマット
○トラックの数及び形式
○エンコーディングパラメータ
○エンコーディングシーケンス
○タイムスタンプシーケンス
そのフォーマットは、次の通りである。
#EXT−X−DISCONTINUITY
4.メディアファイル
プレイリストファイルにおける各メディアファイルURIは、全体的提示のセグメントであるメディアファイルを識別しなければならない(MUST)。各メディアファイルは、MPEG−2トランスポートストリーム、MPEG−2番組ストリーム、又はMPEG−2オーディオ基本的ストリーム[ISO_13818]としてフォーマットされねばならない(MUST)。提示における全てのメディアファイルは、同じフォーマットを有していなければならない(MUST)。
トランスポートストリームファイルは、単一のMPEG−2番組を含まねばならない(MUST)。各ファイルのスタートに、番組アソシエーションテーブル及び番組マップテーブルがなければならない(SHOULD)。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない(SHOULD)。
クライアントは、合理的なサブセットを選択することにより特定形式(例えば、オーディオ又はビデオ)の複数のトラックを取り扱うように準備しなければならない(SHOULD)。クライアントは、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない(MUST)。
メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したままでなければならない(SHOULD)。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない(SHOULD)。
5.キーファイル
URIパラメータを伴うEXT−X−KEYタグは、キーファイルを識別する。キーファイルは、プレイリストにおける後続メディアファイルを解読するのに使用しなければならない(MUST)暗号キーを含む。
AES−128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおけるこれら16オクテットのパックされたアレイに過ぎない。
5.1.AES−128のためのIV
128ビットAESは、暗号及び解読を行うときに同じ16オクテット初期化ベクトル(IV)を供給することを要求する。このIVを変更すると、暗号化の強度が高くなる。
暗号化METHOD AES−128を使用するときには、具現化は、メディアファイルを暗号化又は解読する際にメディアファイルのシーケンス番号をIVとして使用しなければならない(SHALL)。このシーケンス番号のビッグエンディアンバイナリー表現を16オクテットバッファに配して(左側に)ゼロをパディングしなければならない(SHALL)。
6.クライアント/サーバーアクション
本章は、サーバーがどのようにプレイリスト及びメディアファイルを発生し、及びクライアントがどのようにそれをダウンロードして再生すべきか説明する。
6.1.サーバープロセス
MPEG−2ストリームの発生は、本書の範囲外であり、これは、主提示を含む連続的ストリームのソースを簡単に推定するものである。
サーバーは、ストリームを、その期間がほぼ等しい個々のメディアファイルに分割しなければならない(MUST)。サーバーは、個々のメディアファイルの有効なデコードをサポートするポイント、例えば、パケット及びキーフレーム境界においてストリームを分割するように試みなければならない(SHOULD)。
サーバーは、そのクライアントがファイルを得るのを許すURIをメディアファイルごとに生成しなければならない(MUST)。
サーバーは、プレイリストファイルを生成しなければならない(MUST)。プレイリストファイルは、第3章で述べたフォーマットに適合しなければならない。サーバーが利用したい各メディアファイルのURIは、それが再生される順序でプレイリストに現れねばならない(MUST)。URIがプレイリストファイルにある場合には全メディアファイルがクライアントに利用できねばならない。
プレイリストファイルは、EXT−X−TARGETDURATIONタグを含まねばならない(MUST)。これは、主提示に追加される次のメディアファイルのおおよその期間を指示しなければならない(MUST)。この値は、全提示に対して一定のままでなければならない(MUST)。典型的なターゲット期間は、10秒である。
サーバーは、そのクライアントがファイルを得るのを許すURIをプレイリストファイルに対して生成しなければならない(MUST)。
プレイリストファイルの変更は、クライアントの観点から原子的に行われねばならない(MUST)。
プレイリストにおける各メディアファイルURIの前には、メディアファイルのおおよその期間を指示するEXTINFタグがなければならない(MUST)。
サーバーは、URIの前にEXT−X−PROGRAM−DATE−TIMEタグを置くことにより絶対日付及び時刻をメディアファイルに関連付けてもよい(MAY)。日付及び時刻の値は、任意である。
プレイリストが提示の最終的メディアファイルを含む場合には、プレイリストファイルは、EXT−X−ENDLISTタグを含まねばならない。
サーバーが全提示を除去したい場合には、プレイリストファイルをクライアントに利用不能にしなければならない(MUST)。これは、プレイリストファイルにおける全メディアファイルが、除去時に、少なくともプレイリストファイルの期間中クライアントに利用できるままとなるよう保証しなければならない(SHOULD)。
6.1.1.スライディングウインドウプレイリスト
サーバーは、メディアファイルの利用を、プレイリストに最新に追加されたものに限定してもよい(MAY)。これを行うために、プレイリストファイルは、常に、厳密に1つのEXT−X−MEDIA−SEQUENCEタグを含まねばならない(MUST)。その値は、メディアファイルURIがプレイリストファイルから除去されるたびに1だけインクリメントされねばならない(MUST)。
メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去されねばならない(MUST)。
サーバーがプレイリストからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間+メディアファイルが現れた最も長いプレイリストファイルの期間に等しい時間周期中、クライアントに利用可能なままとされる。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。
サーバーがメディアファイルを除去する計画である場合には、HTTP満了ヘッダが、クライアントへの配信時に、計画生存時間を反映するように保証しなければならない(SHOULD)。
サーバーは、EXT−X−ENDLISTタグが存在しない限り、少なくとも3つの主提示メディアファイルをプレイリストに常に維持しなければならない(MUST)。
6.1.2.メディアファイルの暗号化
メディアファイルを暗号化すべき場合には、サーバーは、許可されたクライアントが解読キーを含むキーファイルを得るのを許すURIを定義しなければならない(MUST)。このキーファイルは、第5章で述べたフォーマットに適合しなければならない。
サーバーは、キーがキャッシュ記憶されたことを指示するためにキー応答に満了ヘッダをセットしてもよい(MAY)。
暗号化METHODがAES−128である場合には、AES−128 CBC暗号を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を暗号化しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第5章に述べたIVとして使用しなければならない(MUST)。
サーバーは、プレイリストファイルにおけるURIの直前のEXT−X−KEYタグにより特定された方法を使用してプレイリストにおける各メディアファイルを暗号化しなければならない(MUST)。METHODがNONEであるEXT−X−KEYタグが先行するか、又はEXT−X−KEYタグが先行しないメディアファイルは、暗号化してはならない(MUST NOT)。
各EXT−X−KEYタグのURIは、METHODがNONEでない限り、プレイリストファイルに現れるか又は現れた1つおきのEXT−X−KEYタグのURIとは異なるものでなければならない。METHODがNONEのEXT−X−KEYタグは、URIパラメータを含んではならない。
サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルへのURIを含む場合には、プレイリストファイルからEXT−X−KEYタグを除去してはならない(MUST NOT)。
6.1.3.変形ストリームの付与
サーバーは、同じ提示の異なるエンコーディングを与えるために複数のプレイリストファイルを提供してもよい(MAY)。もしそうであれば、クライアントがエンコーディング間を動的にスイッチできるように各変形ストリームを列挙した変形プレイリストファイルを付与しなければならない(SHOULD)。
変形プレイリストは、変形ストリームごとにEXT−X−STREAM−INFタグを含まねばならない(MUST)。同じ提示に対する各EXT−X−STREAM−INFタグは、同じPROGRAM−ID属性値を有していなければならない(MUST)。各提示に対するPROGRAM−ID値は、変形プレイリスト内で独特でなければならない(MUST)。
EXT−X−STREAM−INFタグがCODECS属性を含む場合には、属性値は、プレイリストファイルに現れる又は現れるであろうメディアファイルに存在する[RFC4281]により定義された各フォーマットを含まねばならない(MUST)。
サーバーは、変形ストリームを発生するときには、次の制約を満足しなければならない(MUST)。
各変形ストリームは、主提示の部分ではないコンテンツを含む同じコンテンツで構成されねばならない(MUST)。
サーバーは、ストリームの最小ターゲット期間という精度内で、全ての変形ストリームに対して同じコンテンツ周期が利用できるようにしなければならない(MUST)。
変形ストリームにおける一致するコンテンツは、一致するタイムスタンプを有していなければならない。これは、クライアントがストリームの同期をとれるようにする。
基本的なオーディオストリームファイルは、ID3 PRIVタグ[ID3]の前に、“com.apple.streaming.transportStreamTimestamp”という所有者識別子を設けることにより、ファイルにおける第1サンプルのタイムスタンプを信号しなければならない(MUST)。バイナリーデータは、ビッグエンディアン8オクテット数として表現された33ビットのMPEG−2番組基本的ストリームタイムスタンプでなければならない(MUST)。
加えて、全ての変形ストリームは、同じエンコードされたオーディオビットストリームを含まねばならない(SHOULD)。これは、クライアントが聴覚欠陥なしにストリーム間をスイッチできるようにする。
6.2.クライアントプロセス
クライアントがプレイリストファイルに対するURIをどのようにして得るかは、本書の範囲外であり、それを行っているものと仮定する。
クライアントは、URIからプレイリストファイルを得なければならない(MUST)。そのようにして得られたプレイリストファイルが変形プレイリストである場合には、クライアントは、変形プレイリストからプレイリストファイルを得なければならない(MUST)。
本書は、クライアントによる変形ストリームの処理を特定するものではない。
6.2.1.プレイリストファイルのローディング
プレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、
クライアントは、プレイリストファイルが#EXTM3Uで始まることをチェックし、もしそうでない場合には、継続を拒否しなければならない(SHOULD)。クライアントは、それが認識しないタグを無視しなければならない(SHOULD)。
クライアントは、第6.2.4章に述べるように、ロードすべき次のメディアファイルを決定しなければならない(MUST)。
プレイリストがEXT−X−MEDIA−SEQUENCEタグを含む場合には、クライアントは、プレイリストファイルがロードされた時間にプレイリストファイルの期間を加えた時間に、その中の各メディアファイルが利用できるようになると仮定しなければならない(SHOULD)。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。
6.2.2.プレイリストファイルの再生
クライアントは、再生がスタートするときにプレイリストからどのメディアファイルを最初に再生するか選択しなければならない(SHALL)。プレイリストファイルがEXT−X−ENDLISTタグを含む場合には、プレイリスト内のどのファイルを最初に再生してもよい(MAY)。EXT−X−ENDLISTタグが存在しない場合には、プレイリスト内の最後と最後から2番目のファイルを除くどのファイルを最初に再生してもよい(MAY)。
最初に再生すべきメディアファイルが選択されると、プレイリスト内のその後のメディアファイルは、それらが現れた順序でロードし、そしてそれらがロードされた順序で再生しなければならない(MUST)。
クライアントは、中断のない再生のためにメディアファイルが要求されるであろうときに前もってそれらをロードし、待ち時間及びスループットの一時的な変動を補償するよう試みなければならない(SHOULD)。
プレイリストファイルがEXT−X−ALLOW−CACHEタグを含みそしてその値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後に、キャッシュ記憶してはならない(MUST NOT)。さもなければ、クライアントは、ダウンロードされたメディアファイルを、後で再生するために不定にキャッシュ記憶してもよい(MAY)。
クライアントは、EXT−X−PROGRAM−DATE−TIMEタグの値を使用して、番組発信時間をユーザに表示してもよい(MAY)。値が時間ゾーン情報を含む場合には、クライアントは、それを考慮しなければならない(SHALL)が、そうでない場合には、クライアントは、発信時間ゾーンを推定してはならない(MUST NOT)。
クライアントは、EXT−X−PROGRAM−DATE−TIMEタグの値の正しさ又は一貫性に依存してはならない(MUST NOT)。
6.2.3.プレイリストファイルの再ローディング
クライアントは、プレイリストファイルがEXT−X−ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードしなければならない(MUST)。
しかしながら、クライアントは、本章で特定された以上に頻繁にプレイリストファイルを再ロードするよう試みてはならない(MUST NOT)。
クライアントがプレイリストファイルを初めてロードするか、又はプレイリストファイルを再ロードして、それが最後にロードされて以来変化したことが分かったときには、クライアントは、プレイリストファイルを再ロードするよう試みる前に、ある期間待機しなければならない(MUST)。この期間は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのローディングを開始する時間から測定される。
初期最小再ロード遅延は、プレイリストにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。
クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある期間待機しなければならない(MUST)。最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0である。
6.2.4.ロードすべき次のファイルの決定
クライアントは、プレイリストファイルがロードされるか又は再ロードされるたびにロードすべき次のメディアファイルを決定するためにプレイリストファイルを検査しなければならない(MUST)。
ロードすべき最初のファイルは、第6.2.2章に述べたように、最初に再生すべくクライアントが選択したファイルでなければならない(MUST)。
再生されるべき最初のファイルがロードされそしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証しなければならず(MUST)、そうでない場合は再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIでなければならない(MUST)。
再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものでなければならない(SHALL)。
6.2.5.暗号化されたメディアファイルの再生
プレイリストファイルが、キーファイルURIを特定するEXT−X−KEYタグを含む場合には、クライアントは、キーファイルを得、そしてその中のキーを使用して、別のEXT−X−KEYタグに遭遇するまで、そのEXT−X−KEYタグに続くメディアファイルを解読しなければならない(MUST)。
暗号化METHODがAES−128である場合には、AES−128 CBC解読を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を解読しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第5.1章に述べたIVとして使用しなければならない(MUST)。
暗号化METHODがNONEである場合には、クライアントは、別のEXT−X−KEYタグに遭遇するまで、EXT−X−KEYタグに続く全てのメディアファイルを平文(非暗号)として処理しなければならない(MUST)。
7.例
本章は、幾つかの規範的プレイリストファイルを含む。
7.1.簡単なプレイリストファイル
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT-X-ENDLIST
7.2.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
7.3.暗号化されたメディアファイルを伴うプレイリストファイル
#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
7.4.変形プレイリストファイル
#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
8.セキュリティの考え方
プロトコルは、一般的に、HTTPを使用してデータを送信するものであるから、ほぼ同じセキュリティの考え方が適用される。RFC2616[RFC2616]の第15章を参照されたい。
メディアファイルパーサーは、典型的に、「ファジング」攻撃を受ける。クライアントは、サーバーから受け取ったファイルを構文解析するときに、不適合のファイルが拒絶されるように注意しなければならない(SHOULD)。
プレイリストファイルは、任意のエンティティのネットワーク要求をなすためにクライアントが使用するURIを含む。クライアントは、バッファのオーバーフローを防止するために応答のレンジチェックを行わねばならない(SHOULD)。RFC3986[RFC3986]の「セキュリティの考え方」の章を参照されたい。
クライアントは、サービス拒否攻撃への貢献を回避するためにURIにより怠惰に識別されるリソースをロードしなければならない(SHOULD)。
HTTP要求は、プライベートユーザデータを含むセッション状態(クッキー)をしばしば含む。具現化は、RFC2965[RFC2965]により特定されたクッキー制約及び満了ルールに従わねばならない(MUST)。RFC2965及びRFC2964[RFC2964]の「セキュリティの考え方」の章も参照されたい。
暗号キーは、URIによって特定される。これらのキーの配信は、HTTPのようなメカニズムにより、安全部門又はセッションクッキーに関連したTLS[RFC5246](以前のSSL)以上に安全確保されねばならない(SHOULD)。
9.参照文献
規範的参照文献
[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>.
【符号の説明】
【0148】
110:ネットワーク
120:サーバー
130:セグメンタ
135:インデクサ
140:セキュリティエージェント
145:HTTPサーバーエージェント
150、180:クライアント装置
160:アッセンブラーエージェント
165:出力ジェネレータエージェント
190:アッセンブラーエージェント
170、185:セキュリティエージェント
195:出力ジェネレータエージェント
400:サーバーストリームエージェント
410:制御ロジック
412:アプリケーション
414:メモリ
420:サーバーストリームエンジン
430:セグメンタ
440:インデクサ
450:セキュリティ
460:ファイルサーバー
500:クライアントストリームエージェント
510:制御ロジック
514:メモリ
516:インターフェイス
520:クライアントストリームエンジン
530:アッセンブラー
540:出力ジェネレータ
550:セキュリティ
【技術分野】
【0001】
本発明は、データ送信技術に係る。より詳細には、本発明は、例えば、ハイパーテキストトランスファープロトコル(HTTP)のような非ストリーミングプロトコルを使用してデータのストリーミングを行えるようにする技術に係る。
【0002】
関連出願:本出願は、次の米国プロビジョナル特許出願の出願日の利益を主張する。
(1)2008年12月31日に出願された特許出願第61/142,110号(管理番号P7437Z);
(2)2009年3月16日に出願された特許出願第61/160,693号(管理番号P7437Z2);
(3)2009年3月17日に出願された特許出願第61/161,036号(管理番号P7437Z3);
(4)2009年4月7日に出願された特許出願第61/167,524号(管理番号P7437Z4);
(5)2009年9月8日に出願された特許出願第61/240,648号(管理番号P7437Z5);及び
(6)2009年12月21日に出願された特許出願第61/288,828号(管理番号P7437Z6)。これら米国プロビジョナル特許出願は、全て、本開示と矛盾しない程度に参考としてここに援用する。
【0003】
本米国特許出願は、参考としてここに各々援用する次の米国特許出願に関連している。
(1)2009年6月5日に出願された“REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,690号(管理番号P7437US1);
(2)2009年6月5日に出願された“VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,698号(管理番号P7437US2);
(3)2009年6月5日に出願された“UPDATABLE REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,732号(管理番号P7437US3); (4)2009年6月5日に出願された“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”と題する特許出願第12/479,735号(管理番号P7437US4)。
【背景技術】
【0004】
コンテンツのストリーミングとは、一般的に、サーバー装置により常時送信されてクライアント装置により受信されるマルチメディアコンテンツを指す。コンテンツは、通常、エンドユーザがストリーミングサーバーにより配信されている間に、エンドユーザに提示される。ネームとは、メディアそれ自身ではなく、メディアの配信方法を指す。
【発明の概要】
【発明が解決しようとする課題】
【0005】
現在のストリーミングサービスは、一般に、エンドユーザに「生」のコンテンツを配布するために特殊なサービスを要求する。大規模な配備では、これが多大なコストを招き、設定及び運転のために特殊なスキルを必要とする。その結果、ストリーミングに利用できるコンテンツのライブラリーは、望ましいライブラリーには至らない。
【課題を解決するための手段】
【0006】
一実施形態において、サーバー装置は、ストリーミングされるべきコンテンツの少なくとも一部分を記憶する。コンテンツは、典型的に、画像又は音声(例えば、サウンド又は音楽)或いはその両方の時間ベースストリームであり、時間ベースストリームの一例は、画像の順序及び提示が時間に基づいていて、従って、時間ベースストリームと考えられる映画である。サーバーは、ストリーミングされるべきコンテンツをネットワークプロトコルに基づいてパケットを経て送信されるべきセグメントへと分解するためのセグメントエージェントと、セグメント化されたユーザデータをクライアントが提示するのを容易にすることのできる1つ以上のプレイリストファイルを発生するためのインデクサエージェントとを備えている。クライアント装置は、ネットワークを経てサーバー装置(或いはセグメント及びプレイリストを記憶してそれらを送信するが、発生はしない別のサーバー)に結合される。クライアント装置は、1つ以上のプレイリストファイルを受け取り、そしてその1つ以上のプレイリストファイルに基づいてコンテンツへのセグメント化メディアファイルの検索を容易にするためのアッセンブラーエージェントを有している。又、クライアント装置は、そのクライアント装置の1つ以上の出力コンポーネントを経てコンテンツを出力するための出力ジェネレータエージェントも有している。
【0007】
一実施形態において、サーバー装置は、クライアント装置へ送信されるべきデータを取得する。サーバー装置は、送信されるべきデータをセグメンタエージェントで複数のメディアファイルに分割する。又、サーバー装置は、複数のセグメントをメモリに個々のメディアファイルとして記憶する。更に、サーバー装置は、複数のメディアファイルへのリファレンスを有する1つ以上のプレイリストファイルを発生する。クライアント装置からのデータの要求に応答して、サーバー装置(又は別のサーバー装置)は、ネットワークを経てクライアント装置へ1つ以上のプレイリストファイル及び少なくとも複数のメディアファイルのサブセットを送信する。複数のメディアファイルは、クライアント装置からの要求に応答して非ストリーミング転送プロトコルを使用して送信することができ、このプロトコルは、例えば、HTTPである。
【0008】
一実施形態において、クライアント装置は、1つ以上のプレイリストファイルを受け取って記憶することができる。次いで、クライアントは、プレイリストファイルにおいて識別されたセグメント化されたメディアファイルを要求し、そしてリンクされたメディアファイルをダウンロードすることができる。次いで、クライアント装置(又は別のクライアント装置)は、コンテンツのストリームを表すオーディオ及び/又はビデオ出力を発生することができる。
【0009】
一実施形態において、更新されたプレイリストを、サーバーによって動的に発生して、クライアントにより検索することができる。更新されたプレイリストは、オリジナルのプレイリストにおける番組に加えて示された付随的資料(例えば、サイドバーユーザインターフェイスにおける広告、関連コンテンツ、別のバージョン、等)を含むか、又は番組の付加的な部分(例えば、オリジナルのプレイリストにおいて識別された第1の半分を越える番組の第2の半分)を含むことができる。1つの具現化において、サーバーは、ここに述べるローリング方法を使用して、プレイリストを更新し、これを、次いで、クライアントにより更新されたプレイリストとして検索することができる。
【0010】
一実施形態において、プレイリストは、同じコンテンツを表す複数の代替えストリームを特定することができ、これら代替えストリームは、異なる視覚解像度で送信される(ひいては、異なるビットレートで送信される)同じ番組でもよいし、或いは他の異なる属性を伴う同じ番組でもよい。サーバーは、代替えストリームごとに1つづつ、複数のプレイリストを発生することができ、又、代替えストリームを指すかさもなければそれを特定する変形プレイリストを発生することができる。次いで、サーバー(又は別のサーバー)は、変形プレイリストをクライアント装置へ送信することができ、そしてクライアント装置は、現在ネットワーク条件(例えば、メディアファイルを転送するのに使用されるネットワークの現在スループットレート)に基づいて、変形プレイリストからどのプレイリストを選択すべきか判断することができ、そしてクライアント装置は、選択されたプレイリストをダウンロードすることができる(更に、その選択されたプレイリストにより特定されたメディアファイルをダウンロードすることができる)。
【0011】
一実施形態において、クライアント装置は、コンテンツを受け取って提示する間に変形プレイリストにおける第1のプレイリストからその変形プレイリストにおける第2のプレイリストへスイッチすることができる。例えば、クライアント装置は、第1のプレイリスト及び第1のビットレートを使用して番組を受け取ることができ、そしてネットワークのスループットレートの測定を通して、第2のプレイリストによりコンテンツが特定されるところの同じ番組のコンテンツをより高い第2のビットレートで受信できると決定することができる。この場合に、クライアント装置は、第2のプレイリストを要求し、第2のプレイリストを受け取り、そして第1のプレイリストにより特定されたコンテンツを提示し続けながら第2のプレイリストにおいて特定されたメディアファイルの検索を開始することができる。クライアント装置は、メディアファイル及び結果的に得られる解凍されたコンテンツを両プレイリストのバッファに記憶することができ、そしてクライアント装置は、自動的なオペレーションを遂行して、いつ、どのように、コンテンツの2つのバージョン間をスイッチ又は遷移すべきか決定することができる。例えば、クライアント装置は、コンテンツの2つのバージョンにおけるオーディオコンテンツのパターンマッチングを使用して、2つのバージョンにおける一致点を見出し、次いで、第2のプレイリストから新たなコンテンツの遷移を識別した後にスイッチを行わせることができる。
【0012】
一実施形態において、方法は、代替えストリームを使用してメディアコンテンツをクライアント装置に与える複数の冗長位置を設けることを含む。フェイルオーバー保護を具現化するため、第1のサーバー装置又は第1のコンテンツ配布サービスは、ストリーム又は複数の代替え帯域巾ストリームを生成し、そしてプレイリストファイル(1つ又は複数)を作成する。第2のサーバー装置又は第2のコンテンツ配布サービスは、並列ストリーム又はストリームのセットを生成する。クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のユニフォームリソースロケーター(URL)からプレイリストファイル(1つ又は複数)をダウンロードするよう試みる。クライアントは、第1のURLからプレイリストファイルをダウンロードできない場合に、別のURLに関連した代替えストリームへスイッチするよう試みる。
【0013】
一実施形態において、方法は、プレイリストの要求を発し、その要求においてプレイリストを圧縮できることを特定し、そしてその要求に応答して、サーバーがプレイリストを圧縮形態で与えることができる場合にプレイリストを圧縮形態で受け取ることを含む(さもなければ、プレイリストは、サーバーにより非圧縮形態で与えることができる)。プレイリストは、デフレート又はgzipのような既存のHTTP標準圧縮技術によりサポートされる圧縮技術又はフォーマットを使用して圧縮(エンコードとも称される)することができる。圧縮形態でのプレイリストの送信及び受信は、特に、プレイリストが時間と共に成長するときに(例えば、プレイリストが長いベースボールゲーム用のものであるときに)、送信及び受信されるデータのサイズを著しく減少することができる。一実施形態において、プレイリストに圧縮を使用することは、クライアント(プレイリストを要求するシステム)及びサーバー(プレイリストを送信することにより要求に応答するシステム)の両方にとって任意である。HTTP規格の一部分である圧縮技術又はフォーマットを使用することは、適合するウェブサーバーが圧縮されたプレイリストを供給できるようにすると共に、適合するクライアントがプレイリストを解凍して使用できるようにもする。
【0014】
本発明は、同様の要素が同じ参照番号で示された添付図面に、一例として、非限定的に示されている。
【図面の簡単な説明】
【0015】
【図1】リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。
【図2A】1つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。
【図2B】1つ以上のサーバー装置が1つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。
【図2C】1つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートである。
【図3A】クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。
【図3B】クライアント装置が複数のビットレートを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。
【図4】サーバーストリームエージェントの一実施形態のブロック図である。
【図5】クライアントストリームエージェントの一実施形態のブロック図である。
【図6】複数のタグを伴うプレイリストファイルの一実施形態を示す図である。
【図7】ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。
【図8】電子システムの一実施形態のブロック図である。
【図9A】クライアント装置が変形プレイリスト内の代替えコンテンツ間をどのようにスイッチできるかの一例を示すフローチャートである。
【図9B】クライアント装置が2つのプレイリストのコンテンツ間をどのようにスイッチできるかを示す更に別のフローチャートである。
【図9C】クライアント装置がオーディオパターンマッチングを使用してコンテンツ間をどのようにスイッチできるかの一例を示す更に別のフローチャートである。
【図9D】図9Cの方法がオーディオパターンマッチングでどのように具現化されるか概略的に示す。
【図10】代替えストリームを使用してクライアント装置へメディアコンテンツを与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。
【図11】一実施形態によりクライアント1102が1つ以上のURLと両方向に通信するネットワークを示す。
【発明を実施するための形態】
【0016】
以下の説明では、多数の特定の細部について述べる。しかしながら、本発明の実施形態は、これらの特定の細部を伴わずに実施されてもよい。他の点については、良く知られた回路、構造及び技術は、説明の理解を妨げないために詳細に示さない。
【0017】
この説明は、版権で保護される資料、例えば、グラフィックユーザインターフェイスの画像の例示を含む。本発明の譲受人を含む版権所有者は、これら資料において版権を含む権利を所有している。版権所有者は、特許商標庁の特許ファイル又は記録に現れるように特許文書又は特許開示を誰かが複写再現することに異議を唱えるものではなく、著作権の全ての権利は何であれ保存されるものとする。版権アップル社2009年。
【0018】
一実施形態において、ここに述べる技術及びコンポーネントは、非ストリーミングプロトコル(例えば、HTTP)及び他のテクノロジー(例えば、モーションピクチャーエクスパートグループ(MPEG)ストリーム)を使用してストリーミングの経験を配信するためのメカニズムを含むことができる。例えば、「生」のミュージカル又はスポーツ行事、生のニュース、ウェブカメラフィード、等を放送するために、HTTPを使用してほぼリアルタイムのストリーミング経験を提供することができる。一実施形態では、プロトコルは、到来するメディアデータを複数のメディアファイルにセグメント化し、そしてそれらのセグメント化されたメディアファイルをサーバーに記憶することができる。又、プロトコルは、サーバーに記憶されたセグメント化されたメディアファイルにクライアントを向けるユニフォームリソースアイデンティファイア(URI)を含むプレイリストファイルを構築することもできる。セグメント化されたメディアファイルがプレイリストファイル(1つ又は複数)に基づいて再生されるときには、クライアントは、「生」の事象のほぼリアルタイムの放送をユーザに提供することができる。予め記録されたコンテンツを同様に提供することもできる。
【0019】
一実施形態において、サーバーは、補足的又は代替え的メディアコンテンツ(例えば、広告、スポーツ行事に関連した統計情報、主たる提示に対する付加的なメディアコンテンツ)を放送事象に動的に導入することができる。例えば、メディア事象のクライアント再生中に、サーバーは、付加的なURIをプレイリストファイルに追加することができ、URIは、クライアントが補足的メディアファイルをダウンロードできるところの位置を識別する。クライアントは、サーバーが導入した補足的又は付加的(又は両方の)メディアコンテンツにアクセスするために1つ以上の更新されたプレイリストファイルをサーバーから周期的に検索するように命令される。
【0020】
一実施形態において、サーバーは、累積モード又はローリングモードのいずれかで動作することができる。累積モードでは、サーバーは、プレイリストファイルを生成し、そしてプレイリストファイルの終わりにメディアファイル識別子を添付することができる。次いで、クライアントは、ダウンロード時に単一のプレイリストファイルからストリームの全ての部分にアクセスすることができる(例えば、ユーザは、ショーの中間でスタートすることができる)。ローリングモードでは、サーバーは、ローリングベースでプレイリストファイルの始めからメディアファイル識別子を除去して、クライアント装置にアクセスできるメディアコンテンツのスライディングウインドウを設けることにより、メディアファイルの利用性を制限することができる。又、サーバーは、プレイリストにメディアファイル識別子を追加することもでき、そしてローリングモードでは、サーバーは、メディアファイルの利用性を、プレイリストに最新に追加されたものに制限することができる。次いで、クライアントは、プレイリストファイルの更新コピーを繰り返しダウンロードして見続ける。プレイリストダウンロードのためのローリングベースは、コンテンツが潜在的に時間的に無限である(例えば、連続的に動作されるウェブからコンテンツが到来する)ときに有用である。クライアントは、プレイリストに終了タグを見つけるまでローリングモードにおいてプレイリストを繰り返し要求し続けることができる。
【0021】
一実施形態において、このメカニズムは、同じ提示の変形ストリームを与えることによりビットレートスイッチングをサポートする。例えば、サービスされるべき提示の多数のバージョンをサーバーに記憶することができる。各バージョンは、実質的に同じコンテンツを有するが、異なるビットレートでエンコードすることができる。これは、クライアント装置が、再生の連続性を妥協することなく、例えば、利用可能な帯域巾の検出に基づいて、ビットレート間をスイッチできるようにする。
【0022】
一実施形態において、無断使用に対してコンテンツを保護するために保護特徴を設けることができる。例えば、予想を防止するために、非順次メディアファイルナンバリングを使用してもよい。又、メディアファイルの暗号化を使用してもよい。更に、部分メディアファイルリストを使用してもよい。又、付加的な及び/又は異なる保護特徴を設けてもよい。
【0023】
図1は、リアルタイム又はほぼリアルタイムでコンテンツを送信及び受信することのできるサーバー及びクライアントの一実施形態のブロック図である。図1の例は、2つのクライアントがネットワークを経てサーバーに結合された簡単なサーバー/クライアント接続を示す。ここに述べる技術及びメカニズムを使用して、いかなる数のクライアントもサポートすることができる。更に、ここに述べる技術及びメカニズムに基づき、複数のサーバーがコンテンツを与えてもよく、及び/又はそれらが一緒に動作してコンテンツを与えてもよい。例えば、1つのサーバーがコンテンツを生成し、プレイリストを生成し、そして複数のメディア(例えば、ファイル)を生成すると共に、他のサーバーがその生成されたコンテンツを記憶し送信してもよい。
【0024】
ネットワーク110は、ワイヤードであるか、ワイヤレス(例えば、IEEE802.11、802.16)であるか、又はその組み合わせであるかに関わらず、いかなる形式のネットワークでもよい。例えば、ネットワーク110は、インターネット又はイントラネットでよい。別の例として、ネットワーク110は、セルラーネットワーク(例えば、3G、CDMA)でもよい。一実施形態において、クライアント装置150及び180は、複数のネットワーク形式を経て通信することができる(例えば、各装置は、WiFiワイヤレスLANを経て及びワイヤレスセルラー電話ネットワークも経て通信することができる)。例えば、クライアント装置150及び180は、セルラー無線電話ネットワーク及びデータネットワークを経て通信できるスマートホン又はセルラーイネーブル型パーソナルデジタルアシスタントでもよい。これらの装置は、いずれかの形式のネットワークを経てここに述べるストリーミングメカニズムを使用することもできるし、又は必要に応じてネットワーク間をスイッチすることもできる。
【0025】
サーバー120は、この技術で良く知られたように、HTTPサーバーとして動作してもよい。即ち、サーバー120は、HTTPプロトコルを使用してコンテンツを与えるHTTPサーバーエージェント145を備えている。図1の例は、HTTPに関して説明するが、他のプロトコルを同様に利用することができる。セグメンタ130及びインデクサ135は、ここに述べるようにメディアファイルのコンテンツにプレイリストファイルを与えるためにサーバー120(又は複数のサーバー)上に存在するエージェントである。これらのメディアファイル及びプレイリストファイルは、HTTPプロトコルを使用してHTTPサーバーエージェント145を経て(又は他のサーバーを経て)ネットワーク110にわたり送ることができる。ここに述べるエージェントは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせとして具現化することができる。
【0026】
セグメント130は、メディアデータのストリームを、HTTPプロトコルを経て送信できる複数のメディアファイルへ分割するように機能する。インデクサ135は、セグメント化されたメディアファイルに対応するプレイリストファイルを生成するように機能して、クライアント装置がメディアファイルを再アッセンブルし、サーバー120により与えられたコンテンツをリアルタイム又はほぼリアルタイムで送信できるようにする。クライアント装置からの1つ以上の要求に応答して、HTTPサーバーエージェント145(又は他のサーバー)は、インデクサ135により発生される1つ以上のプレイリストファイル及びセグメンタ130により発生されるコンテンツのメディアファイルを送信することができる。サーバー120は、更に、ここに述べるセキュリティ機能の1つ以上(例えば、暗号化)を与える任意のセキュリティエージェント140を備えている。又、サーバー120は、図1に示されていない付加的なコンポーネントを含んでもよい。
【0027】
クライアント装置150及び180は、サーバー120からネットワーク110を経てプレイリストファイル及びメディアファイルを受け取る。クライアント装置は、ネットワークを経て送信されたデータを受け取ることができ、そしてネットワークを経て受け取ったデータ使用して出力を発生できる任意の形式の電子装置、例えば、ワイヤレス移動装置、PDA、娯楽装置、消費者向け電子装置、等でよい。その出力は、任意のメディア形式又はメディア形式の組み合わせで、例えば、オーディオ、ビデオ、又はその組み合わせを含む。
【0028】
クライアント装置150は、アッセンブラーエージェント160及び出力ジェネレータエージェント165を含むことができる。同様に、クライアント装置180は、アッセンブラーエージェント190及び出力ジェネレータエージェント195を含むことができる。アッセンブラーエージェント160及び180は、サーバー120からプレイリストファイルを受け取り、そしてそのプレイリストファイルを使用して、サーバー120にアクセスし、そこからメディアファイルをダウンロードする。出力ジェネレータエージェント165及び195は、ダウンロードされたメディアファイルを使用して、各々、クライアント装置150及び160から出力を発生することができる。出力は、1つ以上のスピーカ、1つ以上のディスプレイスクリーン、スピーカ及びディスプレイスクリーンの組み合わせ、或いは他の入力又は出力装置により発生することができる。又、クライアント装置は、メディアファイル(例えば、圧縮されたメディアファイル又は解凍されたメディアファイル)が受け取られたときにそれらを記憶するためのバッファとして作用するメモリ(例えば、フラッシュメモリ又はDRAM、等)を含むこともでき、このバッファは、現在提示されているコンテンツの時間を越えて何秒にも値する提示可能なコンテンツを与え、新たなコンテンツがダウンロードされる間にそのバッファされたコンテンツを後で表示できるようにする。このバッファは、クライアント装置が間欠的な低速のネットワーク接続を通してコンテンツを検索するよう試みる間に提示可能なコンテンツを与えることができ、ひいては、このバッファは、ネットワークの待ち時間又は接続の問題を隠すことができる。
【0029】
更に、クライアント装置150及び180は、各々、ここに述べるセキュリティ機能の1つ以上を与える任意のセキュリティエージェント170及び185を備えている。又、クライアント装置150及び180は、図1には示されていない付加的なコンポーネントを含んでもよい。
【0030】
一実施形態において、本出願に述べる技術は、非ストリーミングプロトコル(例えば、HTTP)を経てマルチメディアデータの無限のストリームを送信するのに使用されてもよい。又、実施形態は、メディアデータを暗号化し及び/又はストリームの代替えバージョンを与える(例えば、代替えビットレートを与える)ことも含み得る。メディアデータは、生成後に直ちに送信できるので、ほぼリアルタイムで受け取ることができる。マルチメディアデータのストリームのサーバー(送信者)及びクライアント(受信者)によってとられるべきアクション及びファイルの規範的なデータフォーマットが与えられるが、他のフォーマットをサポートすることもできる。
【0031】
シミュレーションされたリアルタイムストリーム(又はほぼリアルタイムのストリーム)として送信できるメディア提示は、プレイリストファイルを指示するユニバーサルリソースインジケータ(URI)により特定される。一実施形態において、プレイリストファイルは、付加的なURIの順序付けされたリストである。プレイリストファイルにおける各URIは、特定番組に対するメディアデータの単一隣接ストリームであるストリームのセグメントであるメディアファイルを指す。
【0032】
メディアデータのストリームを再生するため、クライアント装置は、サーバーからプレイリストファイルを得る。又、クライアントは、プレイリストファイルにより指示された各メディアデータファイルを得て再生する。一実施形態において、クライアントは、付加的な及び/又は異なるメディアセグメントを発見するためにプレイリストファイルを動的に又は繰り返し再ロードすることができる。
【0033】
プレイリストファイルは、例えば、拡張M3Uプレイリストファイルでよい。一実施形態において、M3Uフォーマットを効果的に拡張する付加的なタグが使用される。M3Uは、ムービングピクチャーエクスパーツグループオーディオレイヤ3ユニフォームリソースロケーター(MP3 URL)を指すもので、マルチメディアプレイリストを記憶するのに使用されるフォーマットである。M3Uファイルは、メディアプレーヤが再生するための1つ以上のメディアファイルの位置を含むテキストファイルである。
【0034】
プレイリストファイルは、一実施形態では、個々のラインより成る拡張型M3Uフォーマットテキストファイルである。それらのラインは、単一のLFキャラクタにより終了するか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了することができる。各ラインは、URI、ブランクライン、又はコメントキャラクタ(例えば、‘#’)でのスタートである。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視することができる。
【0035】
コメントキャラクタでスタートするラインは、コメント又はタグである。タグは、#EXTで開始し、一方、コメントラインは、#で開始することができる。コメントラインは、通常、サーバー及びクライアントにより無視することができる。一実施形態において、プレイリストファイルは、UTF−8フォーマットでエンコードされる。UTF−8(8ビットのユニコードトランスフォーメーションフォーマット)は、可変長さのキャラクタエンコーディングフォーマットである。別の実施形態では、他のキャラクタエンコーディングフォーマットを使用することができる。
【0036】
以下の例では、2つのタグ、EXTM3U及びEXTINFを含む拡張型M3Uフォーマットが使用される。拡張型M3Uファイルは、“#EXTM3U”を含む第1のラインにより基本的M3Uファイルから区別される。
【0037】
EXTINFは、タグに続くURIにより識別されるメディアファイルを示すレコードマーカーである。一実施形態において、各メディアファイルの前には、EXTINFタグ、例えば、
#EXTINF:<duration>、<title>
があり、“duration”は、メディアファイルの期間を特定し、そして“title”は、ターゲットメディアファイルのタイトルである。
【0038】
一実施形態において、次のタグは、メディアファイルの転送及び再生を管理するのに使用される。
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
【0039】
これらのタグは、各々、以下で詳細に述べる。各新たなタグについて特定のフォーマット及び属性を説明するが、異なる属性、ネーム、フォーマット、等を伴う別の実施形態をサポートすることもできる。
【0040】
EXT−X−TARGETDURATIONタグは、提示に追加される次のメディアファイルのおおよその期間を指示することができる。これは、再生ファイルに含まれ、そのフォーマットは、次の通りである。
#EXT−X−TARGETDURATION:<seconds>
但し、“seconds”は、メディアファイルの期間を指示する。一実施形態において、実際の期間は、タグによって指示されるターゲット期間とは若干相違することがある。一実施形態において、セグメントを指示する各URIは、セグメントのおおよその期間に関連付けられ、例えば、セグメントのURIの前に、そのセグメントのおおよその期間を指示するタグが付けられる。
【0041】
プレイリストファイルにおける各メディアファイル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、等の非順次のシーケンス番号は、シーケンスにおける次の番号の予想を困難にし、これは、コンテンツを海賊版作成から保護する上で助けとなる。コンテンツを保護する上で助けとなる別のオプションは、所与の時間にプレイリストの一部分だけを露呈することである。
【0042】
あるメディアファイルは、暗号化することができる。EXT−X−KEYタグは、それに続くメディアファイルを解読するために使用できる情報を与え、そのフォーマットは、次の通りである。
#EXT−X−KEY:METHOD=<method>[,URI=“<URI>”]
METHODパラメータは、暗号化方法を特定し、そしてURIパラメータは、もしそれが存在する場合には、キーをどのように得るか特定する。
【0043】
NONEの暗号化方法は、暗号化しないことを指示する。種々の暗号化方法を使用することができ、例えば、AES−128は、128ビットキー及びPKCS7パッディング(RFC3852を参照)を伴う「アドバンスエンクリプションスタンダード」暗号化を使用する暗号化を指示する。新規なEXT−X−KEYタグは、従来のEXT−X−KEYタグに取って代わるものである。
【0044】
URIパラメータを伴うEXT−X−KEYタグは、キーファイルを識別する。このキーファイルは、プレイリストファイルに載せられた後続メディアファイルを解読するのに使用される暗号キーを含む。例えば、AES−128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおける16オクテットのパックアレイである。
【0045】
AES−128の使用は、通常、暗号化及び解読時に同じ16オクテットの初期化ベクトル(IV)を供給することを要求する。IVの変更を使用して、暗号化の強度を高めることができる。AES−128暗号化を使用するときに、メディアファイルのシーケンス番号は、メディアファイルの暗号化又は解読時にIVとして使用することができる。
【0046】
EXT−X−PROGRAM−DATE−TIMEタグは、次のメディアファイルの開始を絶対的日付及び/又は時刻に関連付けできるもので、時間ゾーンを含むか又は指示することができる。一実施形態において、日付/時刻表現は、ISO/IEC8601:2004である。タグのフォーマットは、次の通りである。
EXT−X−PROGRAM−DATE−TIME:<YYY-MM-DDThh:mm:ssZ>
【0047】
EXT−X−ALLOW−CACHEタグは、クライアントがダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶できるかどうか指示するのに使用することができる。タグのフォーマットは、次の通りである。
EXT−X−ALLOW−CACHE:<YES|NO>
【0048】
EXT−X−ENDLISTタグは、一実施形態では、それ以上のメディアファイルをプレイリストファイルに追加しないことを指示する。タグのフォーマットは、次の通りである。
EXT−X−ENDLIST
一実施形態において、プレイリストが最終的セグメント又はメディアファイルを含む場合には、プレイリストがEXT−X−ENDLISTタグをもつことになる。
【0049】
EXT−X−STREAM−INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示するのに使用できる。タグのフォーマットは、一実施形態では、次の通りである。
EXT−X−STREAM−INF:[attribute=value][,attribute=value]*
<URI>
ここで、次の属性が使用される。属性BANDWIDTH=<n>は、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。属性PROGRAM−ID=<i>は、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM−IDを伴う複数のEXT−X−STREAM−INF URIを含む。この開示では、変形ストリーム及び変形プレイリストについて更に説明する(例えば、図9A−9Dを参照)。
【0050】
以上のタグ及び属性は、オリジナルメディアコンテンツを表すメディアファイルを編成し、送信しそして処理するために、サーバー装置により使用することができる。クライアント装置は、この情報を使用して、リアルタイム又はほぼリアルタイムのストリーミング経験(例えば、音楽又はスポーツ行事のような生放送を見ること)をクライアント装置のユーザに与えるようにメディアファイルを再アッセンブルし、提示する。
【0051】
プレイリストファイルにおける各メディアファイルURIは、オリジナル提示(即ち、オリジナルメディアコンテンツ)のセグメントであるメディアを識別する。一実施形態において、各メディアファイルは、MPEG−2トランスポートストリーム、MPEG−2番組ストリーム、又はMPEG−2オーディオ基本的ストリームとしてフォーマットされる。このフォーマットは、CODECを特定することにより特定することができ、そしてプレイリストは、CODECを特定することによりフォーマットを特定することができる。一実施形態では、提示における全てのメディアファイルが同じフォーマットを有するが、他の実施形態では、複数のフォーマットをサポートできる。トランスポートストリームファイルは、一実施形態では、単一のMPEG−2番組を含まねばならず、各ファイルの開始に番組アソシエーションテーブル及び番組マップテーブルがなければならない。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない。クライアントは、合理的なサブセットを選択することにより特定形式(例えば、オーディオ又はビデオ)の複数のトラックを取り扱うように準備しなければならない。クライアントは、一実施形態では、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない。メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したものでなければならない。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない。
【0052】
図2Aは、1つ以上のサーバー装置が非ストリーミングプロトコルを使用してメディアコンテンツをサポートするための技術の一実施形態のフローチャートである。図2Aの例は、HTTPに関して与えられるが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Aの例は、単一のサーバーが幾つかのタスクを遂行することに関して与えられる。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でもよい。
【0053】
サーバー装置は、オペレーション200において、与えられるべきコンテンツを受け取る。コンテンツは、生のオーディオ及び/又はビデオ(例えば、スポーツ行事、生のニュース、ウェブカメラのフィード)を表す。又、コンテンツは、予め記録されたコンテンツ(例えば、記録されたコンサート、トレーニングセミナー、等)を表してもよい。コンテンツは、ストリーム型であるかどうかに関わらず、この技術で知られたフォーマット及びプロトコルに基づいてサーバーにより受け取られる。一実施形態では、コンテンツは、MPEG−2ストリームの形態でサーバーにより受け取られるが、他のフォーマットをサポートすることもできる。
【0054】
次いで、サーバーは、オペレーション210において、コンテンツの少なくとも一部分を一時的に記憶する。コンテンツ又はコンテンツの少なくとも一部分は、例えば、記憶装置(例えば、記憶エリアネットワークのハードディスク、等)又はメモリに一時的に記憶される。或いは又、コンテンツは、記憶メディア(例えば、コンパクトディスク、フラッシュドライブ)を経て受け取られ、そこから記憶装置又はメモリへコンテンツを転送してもよい。一実施形態では、サーバーは、必要に応じてコンテンツを1つ以上のストリーム(例えば、MPEG−2)へ変換するエンコーダを有する。この変換は、受け取ったコンテンツを永久的に記憶せずに行うことができ、ある実施形態では、記憶オペレーション210を省略してもよいし、又は他の実施形態では、それが長期間記憶(例えば、アーカイブ記憶)であってもよい。
【0055】
与えられるべきコンテンツは、オペレーション220において、複数のメディアファイルへとセグメント化される。一実施形態では、サーバーは、ストリームを、別々の個別のメディアファイル(即ち、セグメント)へと変換し、これらファイルは、標準ウェブサーバーを使用して配布することができる。一実施形態では、サーバーは、個々のメディアファイルの有効なデコードをサポートするポイントにおいて(例えば、PESパケット境界及びi−フレーム境界のようなパケット及びキーフレーム境界において)メディアストリームをセグメント化する。メディアファイルは、ほぼ等しい期間を伴うオリジナルストリームの一部分である。又、サーバーは、メディアファイルごとにURIを生成する。これらのURIは、クライアント装置がメディアファイルにアクセスできるようにする。
【0056】
セグメントは、本来的に全ファイルを配信するHTTPサーバーを使用してサービスされるので、サーバーは、クライアントにサービスできるまでに完全なセグメント化メディアファイルが得られねばならない。従って、クライアントは、少なくとも1つのメディアファイル長さだけ放送が(時間的に)遅れることがある。一実施形態において、メディアファイルサイズは、時間の遅れとファイル数が多過ぎることとのバランスに基づいたものになる。
【0057】
一実施形態では、2つのセッション形式(生のセッション及びイベントセッション)がサポートされる。生のセッションでは、ストリームの固定サイズ部分だけが保存される。一実施形態では、時代遅れのコンテンツメディアファイルが番組プレイリストファイルから除去され、そしてサーバーからも除去される。第2の形式のセッションは、クライアントが放送の任意のポイントへ同調できる(例えば、初めからスタートするか、中間点からスタートする)イベントセッションである。この形式のセッションは、例えば、再放送に使用することができる。
【0058】
オペレーション230では、メディアファイルがサーバーメモリに記憶される。メディアファイルは、オペレーション230において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。メディアファイルは、サーバー装置においてウェブサーバーアプリケーションによりサポートされる(又は送信を行う別の装置によりサポートされる)ネットワークプロトコル(例えば、HTTP又はHTTPS)を使用して送信の準備ができたファイルとして記憶される。
【0059】
オペレーション240において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、拡張型M3Uタグ及びここに述べるタグを使用して、クライアント装置がメディアファイルにアクセスしてそれを再アッセンブルし、クライアント装置にストリーミング経験を与えるための情報を発生できるようにする。各メディアファイルのURIは、メディアファイルを再生すべき順序でプレイリストファイルに含まれる。又、サーバーは、クライアント装置がプレイリストファイルにアクセスできるようにプレイリストファイルの1つ以上のURIを生成することもできる。
【0060】
オペレーション250において、プレイリストファイルをサーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Aにおいて、特定の順序で提示されるが、異なる順序を使用してもよい。例えば、プレイリストファイルは、メディアファイルが生成され又は記憶される前に生成されてもよい。別の例として、プレイリストファイル及びメディアファイルは、そのいずれかが記憶される前に生成される。
【0061】
メディアファイルを暗号化すべき場合には、プレイリストファイルは、許可されたクライアント装置がメディアファイル解読のための暗号キーを含むキーファイルを得ることができるようにするURIを定義することができる。暗号キーは、セキュアな接続(例えば、HTTPS)を使用して送信することができる。別の例として、プレイリストファイルは、HTTPSを使用して送信することができる。更に別の例として、メディアファイルは、クライアントがプレイリストファイルなしにストリームを再生成できないように予想不能な順序で配列することができる。
【0062】
暗号化方法がAES−128である場合には、例えば、AES−128 CBC暗号化が個々のメディアファイルに適用される。一実施形態において、ファイル全体が暗号化される。一実施形態では、暗号ブロックチェーンが、通常、メディアファイルにわたって適用されない。メディアファイルのシーケンスが、上述したように、IVとして使用される。一実施形態では、サーバーは、キーURIを伴うEXT−X−KEYタグをプレイリストファイルの終わりに追加する。次いで、サーバーは、暗号構成に変更がなされるまで、全ての後続メディアファイルをそのキーで暗号化する。
【0063】
新たな暗号キーへスイッチするために、サーバーは、提示に使用された全ての以前のキーURIとは個別の新たなURIを経て新たなキーを利用できるようにする。又、サーバーは、プレイリストファイルの終わりに新たなキーURIを伴うEXT−X−KEYタグも追加し、そしてその新たなキーで全ての後続メディアファイルを暗号化する。
【0064】
暗号化を終了するために、サーバーは、プレイリストファイルの終わりに暗号化方法NONEを伴うEXT−X−KEYタグを追加することができる。このタグ(“NONE”を方法として伴う)は、一実施形態では、URIパラメータを含まない。全ての後続メディアファイルは、上述したように暗号構成に変更がなされるまで、暗号化されない。サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルに対するURIを含む場合には、EXT−X−KEYタグをプレイリストファイルから除去しない。サーバーは、図3Aを参照して詳細に述べるように、オペレーション270において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。
【0065】
一実施形態において、サーバーは、プレイリストファイルについての要求をクライアント装置から受け取るのに応答してクライアント装置へプレイリストファイルを送信する。クライアント装置は、クライアント装置に与えられたURIを使用してプレイリストファイルにアクセスし/それを要求することができる。URIは、サーバーにおけるプレイリストファイルの位置を指示する。それに応答して、サーバーは、プレイリストファイルをクライアント装置へ与えることができる。クライアント装置は、プレイリストファイルにおけるタグ及びURI(又は他の識別子)を使用して、複数のメディアファイルにアクセスすることができる。
【0066】
一実施形態において、サーバーは、メディアファイルの利用性を、プレイリストファイルに最新に追加されたものに限定することができる。これを行うために、各プレイリストファイルは、1つのEXT−X−MEDIA−SEQUENCEタグしか含むことができず、そしてメディアファイルURIがプレイリストファイルから除去されるたびに値を1だけインクリメントすることができる。メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去することができる。一実施形態において、サーバーがプレイリストファイルからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間と、メディアファイルが現れた最も長いプレイリストファイルの期間との和に等しい期間中、クライアントに利用可能なままとなる。
【0067】
プレイリストファイルの期間は、そのプレイリストファイル内のメディアファイルの期間の和である。又、他の期間を使用することもできる。一実施形態において、サーバーは、EXT−X−ENDLISTタグが存在しない限り、少なくとも3つの主提示のメディアファイルを常にプレイリストに維持することができる。
【0068】
図2Bは、1つ以上のサーバー装置が1つ以上のクライアント装置へ動的に更新されたプレイリストを与えるための技術の一実施形態のフローチャートである。プレイリストは、ここに述べる累積モード又はローリングモードのいずれかを使用して更新することができる。図2Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコル(例えば、HTTPS、等)も、同様に使用することができる。図2Bの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。
【0069】
サーバー装置は、オペレーション205において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション215において、コンテンツの少なくとも一部分を一時的に記憶する。オペレーション215は、図2Aのオペレーション210と同様である。与えられるべきコンテンツは、オペレーション225において、複数のメディアファイルへとセグメント化される。メディアファイルは、オペレーション235においてサーバーメモリに記憶することができる。メディアファイルは、オペレーション235において記憶される前に、暗号化のようなセキュリティ特徴により保護することができる。
【0070】
オペレーション245において、オリジナルコンテンツを再生成するためにメディアファイルをアッセンブルしなければならない順序を指示するように1つ以上のプレイリストファイルが発生される。プレイリストファイルは、オペレーション255において、サーバーに記憶することができる。メディアファイル及びプレイリストファイルの生成及び記憶は、図2Bでは特定の順序で表されるが、異なる順序が使用されてもよい。
【0071】
サーバー(又は別のサーバー)は、図3A−3Bを参照して詳細に述べるように、オペレーション275において、クライアントの要求に応答してネットワークを経てプレイリストファイル及びメディアファイルを送信することができる。
【0072】
プレイリストファイルは、種々の理由で、サーバーによって更新される。サーバーは、オペレーション285において、クライアント装置に与えられるべき付加的なデータを受け取ることができる。付加的なデータは、オペレーション255においてプレイリストファイルが記憶された後に受け取ることができる。付加的なデータは、例えば、生の提示の付加的な部分、又は既存の提示の付加的な部分である。付加的なデータは、広告又は統計情報(例えば、スポーツ行事に関するスコア又はデータ)を含む。又、付加的なデータは、提示上に(半透明体を通して)オーバーレイすることもできるし、又はサイドバーユーザインターフェイスに提示することもできる。付加的なデータは、最初に受け取られたデータと同様に、セグメント化することができる。付加的なデータが、広告を構成するか、又はプレイリストにより表された番組に挿入されるべき他のコンテンツを構成する場合には、付加的なデータは、オペレーション215において(少なくとも一時的に)記憶することができ、オペレーション225においてセグメント化することができ、そしてオペレーション235において記憶することができ、又、セグメント化された付加的なデータを記憶する前に、付加的なデータのセグメントを暗号化することができる。次いで、オペレーション245において、番組及び付加的なデータを含む更新されたプレイリストが発生される。そのプレイリストは、オペレーション255において、付加的なデータに基づいて更新されて、再び記憶される。プレイリストファイルに対する変更は、クライアント装置の観点から原子的に行わねばならない。更新されたプレイリストは、一実施形態では、以前のプレイリストに置き換わる。以下に詳細に述べるように、クライアント装置は、プレイリストを何回も要求することができる。これらの要求は、クライアント装置が最新のプレイリストを利用できるようにする。一実施形態では、付加的なデータがメタデータであり、この場合、プレイリストは、更新する必要がないが、セグメントは、メタデータを含むように更新することができる。例えば、メタデータは、セグメントのタイムスタンプと一致させることのできるタイムスタンプを含み、そしてメタデータは、一致するタイムスタンプを有するセグメントに追加することができる。
【0073】
又、更新されたプレイリストは、メディアファイルの除去を生じてもよい。一実施形態では、サーバーは、プレイリストから、メディアファイルに対し、URIを、それらがプレイリストに追加された順序で除去しなければならない。一実施形態では、サーバーは、全提示を除去する場合に、プレイリストファイルをクライアント装置に利用できなくする。一実施形態では、サーバーは、メディアファイル及びプレイリストファイルを、除去されるべきメディアファイルを含む最長のプレイリストファイルの期間中維持して、現在のクライアント装置が提示へのアクセスを終了できるようにする。従って、プレイリストファイルにおける各メディアファイルURIの前には、プレイリストファイルにより指示されるメディアファイルのおおよその累積的期間を指示するためにEXT−X−STREAM−INFタグを設けることができる。別の実施形態では、メディアファイル及びプレイリストファイルは、直ちに除去されてもよい。
【0074】
クライアント装置からのプレイリストに対するその後の要求の結果、オペレーション275において、サーバーが更新されたプレイリストを与える。一実施形態では、プレイリストは、規則的に更新され、例えば、ターゲット期間に関連した時間周期で更新される。プレイリストファイルの周期的な更新は、サーバーが、動的に変化する提示へのアクセスを与えることができるようにする。
【0075】
図2Cは、1つ以上のサーバー装置が複数のビットレートを使用してクライアント装置へメディアコンテンツを与えるための技術の一実施形態のフローチャートであり、これは、代替えストリームを使用する1つの形態である。図2Cの例は、HTTPに関して示すが、他の非ストリーミングプロトコルを同様に使用することもできる。図2Cの例は、サーバーがあるタスクを遂行することに関して示される。しかしながら、いかなる数のサーバーが使用されてもよい。例えば、クライアント装置にメディアファイルを与えるサーバーは、コンテンツを複数のメディアファイルへとセグメント化するサーバーとは異なる装置でよい。
【0076】
一実施形態では、サーバーは、複数のプレイリストファイルを提供するか、又は単一のプレイリストファイルに複数のメディアファイルリストを伴う単一のプレイリストファイルを提供して、同じ提示の異なるエンコーディングを与えることができる。異なるエンコーディングが与えられる場合には、プレイリストファイルは、異なるビットレートを与える各変形ストリームを含み、クライアント装置がエンコーディング間を動的にスイッチできるようにする(図9A−9Dを参照して更に説明する)。変形ストリームを有するプレイリストファイルは、変形ストリームごとにEXT−X−STREAN−INFタグを含むことができる。同じ提示に対する各EXT−X−STREAN−INFタグは、同じPROGRAM−ID属性値をもつことができる。各提示のPROGRAM−ID値は、変形ストリーム内で独特である。
【0077】
一実施形態では、サーバーは、変形ストリームを発生するときに次の制約を満足する。各変形ストリームは、主提示の一部分ではない任意のコンテンツを含む同じコンテンツで構成することができる。サーバーは、ストリームの最小ターゲット期間の精度内で全ての変形ストリームに対して同じコンテンツ周期を利用できるようにする。変形ストリームのメディアファイルは、一実施形態では、全ての変形ストリームにおける対応コンテンツに対して一致するサンプルタイムスタンプを伴うMPEG−2トランスポートストリーム、又はMPEG−2番組ストリームのいずれかである。又、一実施形態では、全ての変形ストリームは、同じオーディオエンコーディングを含む。これは、クライアント装置がコンテンツを失うことなく変形ストリーム間でスイッチできるようにする。
【0078】
図2Cを参照すれば、サーバー装置は、オペレーション202において、与えられるべきコンテンツを受け取る。次いで、サーバーは、オペレーション212において、コンテンツを少なくとも一時的に記憶する。与えられるべきコンテンツは、オペレーション222において、複数のメディアファイルへとセグメント化される。各メディアファイルは、オペレーション232において、選択されたビットレート(又は他のエンコーディングパラメータの選択された値)についてエンコードされ、そしてサーバーに記憶される。例えば、メディアファイルは、高、中間及び低帯域巾接続についてターゲットが決められる。メディアファイルは、記憶の前に暗号化することができる。種々の形式の接続についてターゲットが決められたメディアファイルのエンコーディングは、ターゲット帯域巾レベルにおいてストリーミング経験を与えるように選択される。
【0079】
一実施形態では、オペレーション242において、種々のエンコーディングレベルを指示するここに述べるタグを伴う変形プレイリストが発生される。タグは、例えば、対応するメディアプレイリストファイルに対するURIを伴うエンコーディングレベルごとのEXT−X−STREAN−INFタグである。
【0080】
この変形プレイリストは、種々のエンコーディングレベルについてメディアプレイリストファイルに対するURIを含むことができる。従って、クライアント装置は、エンコーディングレベルを指示する変形プレイリストに与えられた代替え物からターゲットビットレートを選択し、そしてそれに対応するプレイリストファイルを検索することができる。一実施形態では、クライアント装置は、再生中にビットレート間を切り換えることができる(図9A−9Dを参照して述べるように)。種々のエンコーディングレベルを指示する変形プレイリストは、オペレーション252において、サーバーに記憶される。オペレーション242では、変形プレイリストにおいて参照されるプレイリストの各々を発生し、オペレーション252においてそれを記憶することができる。
【0081】
クライアント装置からの要求に応答して、サーバーは、オペレーション272において、種々のエンコーディングレベルを指示する変形プレイリストを送信することができる。サーバーは、オペレーション282において、選択されたビットレートに対応する変形プレイリストにおいて特定されたメディアプレイリストの1つに対する要求を受け取る。この要求に応答して、サーバーは、オペレーション292において、クライアント装置からの要求に対応するメディアプレイリストファイルを送信する。次いで、クライアント装置は、メディアプレイリストを使用して、サーバーからのメディアファイルを要求する。サーバーは、オペレーション297において、それらの要求に応答してクライアント装置へメディアファイルを与える。
【0082】
図3Aは、クライアント装置が非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Aの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。図3A−3Bに示す方法は、1つのクライアント装置又は複数の別々のクライアント装置により遂行することができる。例えば、これら方法のいずれか1つの場合に、単一のクライアント装置が、全てのオペレーション(例えば、プレイリストファイルを要求し、プレイリストファイルのURIを使用してメディアファイルを要求し、提示/出力の発生及び供給のためにメディアファイルをアッセンブルする)を遂行するか、或いは複数の個別のクライアント装置が、全部ではなく幾つかのオペレーションを遂行する(例えば、第1のクライアント装置が、プレイリストファイルを要求し、そのプレイリストファイルのURIを使用してメディアファイルを要求し、そしてそれらのメディアファイルを第2のクライアント装置により使用するために記憶し、第2のクライアント装置は、メディアファイルを処理して、提示/出力を発生及び供給することができる)。
【0083】
クライアント装置は、オペレーション300において、サーバーからプレイリストファイルを要求する。一実施形態では、この要求は、HTTP適合のプロトコルに基づいて行われる。この要求は、サーバーに記憶された初期プレイリストファイルに対するURIを使用する。別の実施形態では、他の非ストリーミングプロトコルをサポートすることもできる。この要求に応答して、サーバーは、それに対応するプレイリストファイルを、ネットワークを経てクライアントへ送信する。上述したように、ネットワークは、ワイヤード又はワイヤレスであり、又、ワイヤード又はワイヤレスネットワークの組み合わせでもよい。更に、ネットワークは、データネットワーク(例えば、IEEE802.11、IEEE802.16)でもよいし、セルラー電話ネットワーク(例えば、3G)でもよい。
【0084】
クライアント装置は、オペレーション310において、プレイリストファイルを受け取ることができる。プレイリストファイルは、オペレーション320において、クライアント装置のメモリに記憶することができる。メモリは、例えば、ハードディスク、フラッシュメモリ、ランダムアクセスメモリである。一実施形態では、プレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、クライアントは、プレイリストファイルが#EXTM3Uタグで始まり、そしてタグが存在しない場合には継続しないことを決定するためのチェックを行う。上述したように、プレイリストファイルは、1つ以上のタグと、メディアファイルに対する1つ以上のURIとを含む。
【0085】
クライアント装置は、オペレーション330において、プレイリストファイルのURIにより指示されたメディアファイルを要求することによりプレイリストファイルを使用してオリジナルコンテンツを再アッセンブルするアッセンブラーエージェントを含むことができる。一実施形態では、このアッセンブラーエージェントは、標準ウェブブラウザアプリケーションの一部分であるプラグインモジュールである。別の実施形態では、アッセンブラーエージェントは、ウェブブラウザと対話し、プレイリストファイルを使用してメディアファイルを受け取りアッセンブルするスタンドアローンアプリケーションでもよい。更に別の例として、アッセンブラーエージェントは、クライアント装置に埋め込まれる特殊目的のハードウェア又はファームウェアコンポーネントでもよい。
【0086】
このアッセンブラーは、プレイリストファイルからのメディアファイルを、URIにより指示されたサーバーからダウンロードさせる。プレイリストファイルがEXT−X−ENDLISTタグを含む場合には、プレイリストファイルにより指示されたメディアファイルが最初に再生される。EXT−X−ENDLISTタグが存在しない場合には、最後と最後から2番目のメディアファイルを除くメディアファイルが最初に再生される。再生すべき最初のメディアファイルが選択されると、プレイリストファイルにおける後続メディアファイルは、一実施形態では、それらがプレイリストファイルに現れる順序でロードされる(さもなければ、コンテンツは、無秩序に提示される)。一実施形態では、クライアント装置は、中断のない再生を与えると共にネットワークの待ち時間及びスループットの時間的変化を補償するために、メディアファイルが要求される以前にそれらをロードする(そしてそれらをバッファに記憶する)ように試みる。
【0087】
ダウンロードされたメディアファイルは、オペレーション340において、クライアント装置のメモリに記憶することができる。コンテンツを記憶することのできるメモリは、クライアント装置における任意の形式のメモリであり、例えば、ランダムアクセスメモリ、ハードディスク又はビデオバッファである。記憶は、再生を許すために一時的でもよいし、又は永久的でもよい。プレイリストファイルがEXT−X−ALLOW−CACHEタグを含み、その値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後は、記憶しない。プレイリストがEXT−X−ALLOW−CACHEタグを含み、その値がYESである場合には、クライアントは、メディアファイルを、後で再生するために不定に記憶する。クライアント装置は、EXT−X−PROGRAM−DATE−TIMEタグの値を使用して、番組起点時間をユーザに表示する。一実施形態では、クライアントは、複数のメディアファイルをバッファして、ネットワークジッタの影響を受け難くし、良好なユーザ経験を与えることができるようにする。
【0088】
一実施形態において、解読方法がAES−128である場合に、AES−128 CBC解読が個々のメディアファイルに適用される。ファイル全体が解読される。一実施形態では、メディアファイルにわたって暗号ブロックチェーンが適用されない。メディアファイルのシーケンス番号は、上述したように初期化ベクトルとして使用することができる。
【0089】
メモリからのコンテンツは、オペレーション350において、クライアント装置から出力することができる。出力又は提示は、例えば、内蔵スピーカ又はヘッドホンを経て出力されるオーディオである。出力は、スクリーンを経て出力されるか又はクライアント装置から投影されるビデオを含む。この技術で知られた任意の形式の出力を使用することができる。オペレーション351において、クライアント装置は、記憶された現在プレイリストに再生も提示もされていないメディアファイルがもっとあるかどうか決定する。そのようなメディアファイルが存在する(且つそれらが要求されていない)場合には、1つ以上のメディアファイルが要求されるオペレーション330へ処理が復帰し、プロセスが繰り返される。このようなメディアファイルがない(即ち、現在プレイリストにおける全てのメディアファイルが再生されている)場合には、処理がオペレーション352へ進み、これは、プレイリストファイルが終了タグを含むかどうか決定する。
【0090】
オペレーション352において、プレイリストが終了タグ(例えば、EXT−X−ENDLIST)を含む場合には、プレイリストファイルにより指示されたメディアファイルが再生されたときに再生が終わる。終了タグがプレイリストにない場合には、クライアント装置は、サーバーからプレイリストを再び要求し、そしてオペレーション300へ復帰して、番組のための更に別の又は更新されたプレイリストを得る。
【0091】
図2Bを参照して詳細に説明したように、サーバーは、補足的コンテンツ(例えば、生放送における付加的なメディアコンテンツに対応する付加的なメディアファイル識別子)又は付加的なコンテンツ(例えば、ストリームの更に下流のコンテンツ)を導入するためにプレイリストファイルを更新する。この補足的コンテンツ又は付加的なコンテンツにアクセスするために、クライアントは、更新されたプレイリストをサーバーから再ロードすることができる。これは、プレイリストファイルに関連したメディアコンテンツの再生中でも、プレイリストファイルを動的に更新できるメカニズムを与える。クライアントは、多数のトリガーに基づいてプレイリストファイルの再ロードを要求する。終了タグの欠如は、1つのこのようなトリガーである。
【0092】
一実施形態では、クライアント装置は、プレイリストファイルがEXT−X−ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードする。クライアント装置が、プレイリストファイルを初めてロードするとき、又はプレイリストファイルを再ロードしそしてそれが前回ロードされて以来変化したことが分かったときには、クライアントは、再びプレイリストファイルを再ロードするよう試みる前に、ある時間周期待機することができる。この周期は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのロードを開始する時間から測定される。
【0093】
一実施形態では、初期最小再ロード遅延は、プレイリストファイルにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある時間周期待機することができる。一実施形態における最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。一実施形態では、この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0であるが、他の倍数が使用されてもよい。
【0094】
プレイリストファイルがロード又は再ロードされるたびに、クライアント装置は、プレイリストファイルを検査して、ロードすべき次のメディアファイルを決定する。ロードすべき第1のファイルは、上述したように、最初に再生するように選択されたメディアファイルである。再生されるべき第1のメディアファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証することができ、ファイルが見つからない場合には再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIである。
【0095】
再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものである。プレイリストファイルが、キーファイルURIを特定するEXT−X−KEYタグを含む場合には、クライアント装置は、キーファイルを得、そしてキーファイル内のキーを使用して、別のEXT−X−KEYタグに遭遇するまで、そのEXT−X−KEYタグに続くメディアファイルを解読する。
【0096】
一実施形態では、クライアント装置は、以前に使用した同じURIを使用して、プレイリストファイルをダウンロードする。従って、プレイリストファイルに変更がなされた場合には、クライアント装置は、更新されたプレイリストファイルを使用して、メディアファイルを検索し、そしてそのメディアファイルに基づいて出力を与える。
【0097】
プレイリストファイルの変更は、例えば、メディアファイルに対するURIの削除、新たなメディアファイルに対するURIの追加、置き換えメディアファイルに対するURIの置き換えを含む。プレイリストファイルに変更がなされるときには、その変更を反映するように1つ以上のタグが更新される。例えば、メディアファイルの変更で、プレイリストファイルによって指示されるメディアファイルの再生の期間に変更が生じる場合には、期間タグが更新される。
【0098】
図3Bは、クライアント装置が、代替えストリームの一形態である複数のビットレートを使用するコンテンツのストリーミングをサポートするための技術の一実施形態のフローチャートである。図3Bの例は、HTTPに関して示すが、他の非ストリーミングプロトコルも同様に使用できる。
【0099】
オペレーション370において、クライアント装置は、プレイリストファイルを要求することができる。上述したように、プレイリストファイルは、クライアント装置に与えられるURIを使用して検索される。一実施形態では、プレイリストファイルは、同じコンテンツを異なるビットレートで与えるためにメディアファイルの変形ストリームのリストを含み、換言すれば、単一のプレイリストファイルは、各変形ストリームのメディアファイルに対するURIを含む。図3Bに示す例は、この実施形態を使用する。別の実施形態では、変形ストリームは、クライアントに別々に与えられる複数の個別のプレイリストファイルにより、その各々が同じコンテンツを異なるビットレートで与えるように表され、そして変形プレイリストは、個別のプレイリストファイルの各々に対してURIを与えることができる。これは、クライアント装置がクライアントの条件に基づいてビットレートを選択できるようにする。
【0100】
オペレーション375において、プレイリストファイルは、クライアント装置によって検索することができる。オペレーション380において、プレイリストファイルは、クライアント装置のメモリに記憶することができる。クライアント装置は、オペレーション385において、使用すべきビットレートを、現在ネットワークの接続速度に基づいて選択する。メディアファイルは、オペレーション390において、選択されたビットレートに対応するプレイリストファイルに含まれたURIを使用してサーバーから要求される。検索されたメディアファイルは、クライアント装置のメモリに記憶することができる。出力は、オペレーション394において、メディアファイルを使用してクライアント装置により与えられ、そしてクライアント装置は、ビットレートを変更すべきかどうか決定する。
【0101】
一実施形態において、クライアント装置は、最初に利用可能な最低ビットレートを選択する。メディアを再生する間に、クライアント装置は、利用可能な帯域巾(例えば、現在ネットワークの接続ビットレート)を監視して、その利用可能な帯域巾が再生のためにより高いビットレートの使用をサポートできるかどうか決定することができる。もしそうであれば、クライアント装置は、より高いビットレートを選択し、そしてより高いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。その逆をサポートすることもできる。再生が著しい帯域巾を消費する場合には、クライアント装置は、より低いビットレートを選択し、そしてより低いビットレートのメディアプレイリストファイルにより指示されたメディアファイルにアクセスすることができる。
【0102】
クライアント装置が、オペレーション394において、例えば、利用可能な帯域巾の変更に応答し又はユーザ入力に応答して、ビットレートを変更する場合には、クライアント装置は、オペレーション385において、異なるビットレートを選択することができる。一実施形態では、異なるビットレートを選択するために、クライアント装置は、新たに選択されたビットレートに対応するプレイリストファイルに含まれたURIの異なるリストを利用することができる。一実施形態では、クライアント装置は、プレイリスト内のメディアファイルのアクセス中にビットレートを変更することができる。
【0103】
オペレーション394においてビットレートが変更されない場合に、クライアント装置は、検索及び提示されていない未再生のメディアファイルが現在プレイリストにもっとあるかどうか決定する。そのようなメディアファイルが存在する場合には、処理がオペレーション390へ復帰し、そしてプレイリストにおけるそれらのファイルに対するURIを使用して1つ以上のメディアファイルが検索される。そのようなメディアファイルがない(即ち、現在プレイリストにおける全てのメディアファイルが再生された)場合には、処理がオペレーション396へ進み、プレイリストが終了タグを含むかどうか決定される。もしそうであれば、番組の再生が終了で、プロセスが完了であるが、もしそうでなければ、処理がオペレーション370へ復帰し、クライアント装置は、番組に対するプレイリストを再ロードすることを要求し、図3Bに示す方法を通してプロセスが繰り返される。
【0104】
図4は、サーバーストリームエージェントの一実施形態のブロック図である。サーバーストリームエージェント400の要素は、多数のサーバー装置にわたって分散できることを理解されたい。例えば、第1のサーバー装置は、セグメンタ430、インデクサ440及びセキュリティ450を含むが、ファイルサーバー460は含まず、又、第2のサーバー装置は、ファイルサーバー450を含むが、セグメンタ430、インデクサ440及びセキュリティ450は含まない。この例では、第1のサーバー装置は、プレイリスト及びメディアファイルを準備するが、それらをクライアント装置へ送信せず、一方、1つ以上の第2のサーバー装置は、プレイリスト及びメディアファイルを受け取って任意に記憶し、そしてプレイリスト及びメディアファイルをクライアント装置へ送信する。サーバーストリームエージェント400は、サーバーストリームエージェント400のオペレーションを指令する論理機能制御を具現化する制御ロジック410と、サーバーストリームエージェント400のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路、又はソフトウェアルーチン、又はファームウェアである。一実施形態では、サーバーストリームエージェント400は、制御ロジック410にインストラクションを与えるコードシーケンス及び/又はプログラムを表す1つ以上のアプリケーション412を備えている。
【0105】
サーバーストリームエージェント400は、データ又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ414を備えている。このメモリ414は、サーバーストリームエージェント400に対してローカルのメモリを含んでもよいし、或いは又サーバーストリームエージェント400が存在するホストシステムのメモリを含んでもよい。又、サーバーストリームエージェント400は、サーバーストリームエージェント400の外部のエンティティ(電子装置又は人間)に関してサーバーストリームエージェント400への/からのアクセスインターフェイス(入力/出力インターフェイス)を表す1つ以上のインターフェイス416も備えている。
【0106】
又、サーバーストリームエージェント400は、サーバーストリームエージェント400がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すサーバーストリームエンジン420も備えている。図4の例は、サーバーストリームエンジン420に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、セグメンタ430、インデクサ440、セキュリティ450、及びファイルサーバー460を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。
【0107】
セグメンタ430は、与えられるべきコンテンツを、ウェブサーバープロトコル(例えば、HTTP)を使用してファイルとして送信できるメディアファイルへと分割する。例えば、セグメンタ430は、コンテンツを、所定のファイルフォーマットにおける所定の固定サイズのデータブロックへと分割する。
【0108】
インデクサ440は、セグメンタ430によって生成されるメディアファイルに対するURI又はアドレスを与える1つ以上のプレイリストファイルを発生する。インデクサ440は、例えば、セグメンタ430により生成される各ファイルに対応する識別子のための順序のリストを伴う1つ以上のファイルを生成する。それら識別子は、セグメンタ430又はインデクサ440によって生成され又は指定される。又、インデクサ440は、メディアファイルのアクセス及び/又は利用をサポートするためにプレイリストファイルに1つ以上のタグを含むこともできる。
【0109】
セキュリティ450は、上述したようなセキュリティ特徴(例えば、暗号化)を与えることができる。ウェブサーバー460は、ホストシステムに記憶されたファイルをリモートクライアント装置に与えることに関連したウェブサーバー機能を発揮する。ウェブサーバー460は、例えば、HTTP適合のプロトコルをサポートする。
【0110】
図5は、クライアントストリームエージェントの一実施形態のブロック図である。クライアントストリームエージェントの要素は、多数のクライアント装置にわたって分散できることを理解されたい。例えば、第1のクライアント装置は、アッセンブラー530及びセキュリティ550を備え、そしてメディアファイルの解読されたストリームを第2のクライアント装置へ供給することができ、この第2のクライアント装置は、出力ジェネレータ540を含む(が、アッセンブラー530及びセキュリティ550は含まない)。別の例では、一次クライアント装置がプレイリストを検索してそれを二次クライアント装置へ供給することができ、この二次クライアント装置は、プレイリストにおいて特定されたメディアファイルを検索して、それらメディアファイルを提示するための出力を発生する。クライアントストリームエージェント500は、このクライアントストリームエージェント500のオペレーションを指令するための論理機能的制御を具現化する制御ロジック510と、このクライアントストリームエージェント500のオペレーションの指令に関連したハードウェアとを含む。ロジックは、ハードウェアロジック回路或いはソフトウェアルーチン又はファームウェアでよい。一実施形態では、クライアントストリームエージェント500は、制御ロジック510にインストラクションを与えるコードシーケンス又はプログラムを表す1つ以上のアプリケーション512を備えている。
【0111】
クライアントストリームエージェント500は、データ及び/又はインストラクションを記憶するためのメモリ装置又はメモリリソースへのアクセスを表すメモリ514を備えている。このメモリ514は、クライアントストリームエージェント500に対してローカルのメモリを含んでもよいし、或いは又クライアントストリームエージェント500が存在するホストシステムのメモリを含んでもよい。又、クライアントストリームエージェント500は、クライアントストリームエージェント500の外部のエンティティ(電子装置又は人間)に関してクライアントストリームエージェント500への/からのアクセスインターフェイス(入力/出力インターフェイス)を表す1つ以上のインターフェイス516も備えている。
【0112】
又、クライアントストリームエージェント500は、このクライアントストリームエージェント500がここに述べるリアルタイム又はほぼリアルタイムのストリーミングを与えることができるようにする1つ以上の機能を表すクライアントストリームエンジン520も備えている。図5の例は、クライアントストリームエンジン520に含まれる多数のコンポーネントを示すが、異なる又は付加的なコンポーネントが含まれてもよい。ストリーミング環境を与えるために含まれる規範的コンポーネントは、アッセンブラー530、出力ジェネレータ540、及びセキュリティ550を含む。これらコンポーネントの各々は、更に、他の機能を与えるための他のコンポーネントを含んでもよい。ここで使用するコンポーネントとは、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせで具現化されるかどうかに関わらず、ルーチン、サブシステム、等を指す。
【0113】
アッセンブラー530は、サーバーから受け取られたプレイリストファイルを使用して、サーバーからウェブサーバープロトコル(例えば、HTTP)を経てメディアファイルにアクセスすることができる。一実施形態では、アッセンブラー530は、プレイリストファイルにおいてURIにより指示されたメディアファイルをダウンロードさせる。アッセンブラー530は、プレイリストファイルに含まれたタグに応答する。
【0114】
出力ジェネレータ540は、受け取ったメディアファイルをホストシステムにおいてオーディオ又はビジュアル出力(又はオーディオ及びビジュアルの両方)として発生する。出力ジェネレータ540は、例えば、オーディオを1つ以上のスピーカへ出力させそしてビデオをディスプレイ装置へ出力させる。セキュリティ550は、上述したようなセキュリティ特徴を与える。
【0115】
図6は、複数のタグを伴うプレイリストファイルの一実施形態を示す図である。図6の規範的なプレイリストは、特定数及び順序のタグを含む。これは、説明上のものに過ぎない。あるプレイリストファイルは、より多くの又はより少ない、或いは異なる組み合わせのタグを含み、そしてタグは、図6に示すものとは異なる順序で配列することができる。
【0116】
開始タグ610は、プレイリストファイルの開始を指示することができる。一実施形態において、開始タグ610は、#EXTM3Uタグである。期間タグ620は、再生リストの期間を指示することができる。即ち、再生リスト600により指示されるメディアファイルの再生の期間である。一実施形態において、期間タグ620は、EXT−X−TARGETDURATIONタグであるが、他のタグも使用できる。
【0117】
日付/時刻タグ625は、再生リスト600により指示されたメディアファイルにより与えられるコンテンツの日付及び時刻に関連した情報を与えることができる。一実施形態では、日付/時刻タグ625は、EXT−X−PROGRAM−DATE−TIMTタグであるが、他のタグを使用することもできる。シーケンスタグ630は、プレイリストのシーケンスにおけるプレイリストファイル600のシーケンスを指示することができる。一実施形態では、シーケンスタグ630は、EXT−X−MEDIA−SEQUENCEタグであるが、他のタグも使用できる。
【0118】
セキュリティタグ640は、プレイリストファイル600により指示されたメディアファイルに適用されるセキュリティ及び/又は暗号化に関連した情報を与えることができる。例えば、セキュリティタグ640は、メディアファイルインジケータにより特定されたファイルを解読するための解読キーを特定することができる。一実施形態では、セキュリティタグ640は、EXT−X−KEYタグであるが、他のタグを使用することもできる。変形リストタグ645は、変形ストリームがプレイリスト600により与えられるかどうか指示すると共に、変形ストリームに関する情報(例えば、どれほど多く、ビットレート)を指示することができる。一実施形態では、変形リストタグ645は、EXT−X−STREAM−INFタグである。
【0119】
メディアファイルインジケータ650は、再生されるべきメディアファイルに関する情報を与えることができる。一実施形態では、メディアファイルインジケータ650は、再生されるべき複数のメディアファイルに対するURIを含む。又、一実施形態では、プレイリスト600におけるURIの順序は、メディアファイルにアクセスし及び/又は再生しなければならない順序に対応する。その後のプレイリストインジケータ660は、再生ファイル600の後に使用されるべき1つ以上の再生ファイルに関連した情報を与えることができる。一実施形態では、その後のプレイリストインジケータ660は、プレイリスト600のメディアファイルが再生された後に使用されるべき1つ以上のプレイリストファイルに対するURIを含むことができる。
【0120】
メモリタグ670は、メディアファイルコンテンツの再生後にクライアント装置がメディアファイルを記憶できるかどうか及び/又はどれほど長く記憶できるか指示することができる。一実施形態では、メモリタグ670は、EXT−X−ALLOW−CACHEタグである。終了タグ680は、プレイリストファイル600が提示のための最後のプレイリストファイルであるかどうか指示する。一実施形態では、終了タグ680は、EXT−X−ENDLISTタグである。
【0121】
次の章は、一実施形態による幾つかの規範的なプレイリストファイルを含む。
簡単なプレイリストファイル
#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
【0122】
図7は、ここに述べるアッセンブルされたストリームに対する再生技術の一実施形態のフローチャートである。一実施形態において、受け取られたメディアファイルの再生は、スタート、ストップ、巻き戻し、等のためにユーザにより制御することができる。プレイリストファイルは、オペレーション700において、クライアント装置により受け取られる。オペレーション710において、プレイリストファイルにより指示されたメディアファイルが検索される。オペレーション720において、受け取られたメディアファイルに基づいて出力が発生される。メディアファイルの受け取り及びそのメディアファイルに基づく出力の発生は、上述したように行うことができる。
【0123】
オペレーション730において制御入力が検出された場合には、クライアント装置は、オペレーション740において入力がストップを指示するかどうか決定することができる。入力がストップである場合には、プロセスが終了となり、再生がストップする。オペレーション750において入力が巻き戻し又は送り要求を指示する場合には、クライアント装置は、オペレーション760において、メモリにまだ記憶されている以前に再生されたメディアファイルに基づいて出力を発生することができる。これらファイルがキャッシュにもはやない場合には、処理がオペレーション710へ復帰し、メディアファイルを検索してプロセスを繰り返す。別の実施形態では、再生は、ストップ入力のような再生の終了を伴わずに再生をハルトする休止特徴をサポートすることができる。
【0124】
あるストリームから別のストリームへ遷移させる方法を、図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のストリームの受け取りを停止することができる。
【0125】
図9Bは、クライアント装置が、オペレーション921及び923において第1のメディアプレイリスト(例えば、第1のストリーム)により特定されたコンテンツを検索し、記憶し及び提示し、そして第1のプレイリストにより特定されたコンテンツが提示される間に、オペレーション925において、クライアント装置が、第2のメディアプレイリスト(例えば、第2のストリーム)により特定されたコンテンツを検索し及び記憶することを示している。第1のメディアプレイリストから得たコンテンツを提示している間に第2のメディアプレイリストにより特定されたコンテンツを検索し(例えば、一時的バッファに)記憶することで、番組コンテンツの時間的なオーバーラップ955(図9Dに示す)を生成し、これは、クライアント装置が、番組を実質的に中断せずに番組のバージョン間をスイッチングできるようにする。このように、番組のバージョン間のスイッチングは、多くの場合に、スイッチングが生じることをユーザに通知せずに(ある場合には、スイッチングの後の高解像度の画像にユーザが気付くことがあるが)、又は番組提示の実質的な中断なしに、行うことができる。オペレーション927において、クライアント装置は、第1のメディアプレイリストにより特定されたコンテンツから第2のメディアプレイリストにより特定されたコンテンツへスイッチングすべき遷移点を決定し、遷移点の一例(遷移点959)が図9Dに示されている。第2のメディアプレイリストにより特定されたコンテンツは、スイッチングの後に、オペレーション931において提示される。
【0126】
図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のストリームを使用する。前記方法は、一実施形態では、低速ビットレートから高速ビットレートへの変化、及び高速ビットレートから低速ビットレートへの変化の両方に使用することができるが、別の実施形態では、この方法は、低速ビットレートから高速ビットレートへの変化にしか使用できず、高速ビットレートから低速ビットレートへの変化には別の方法(例えば、遷移点を位置付けるよう試みず、低速ビットレートストリームからできるだけ即座にコンテンツを記憶し提示するよう試みる)を使用することができる。
【0127】
図10は、代替えストリームを使用してクライアント装置へプレイリスト又はメディアコンテンツ或いはその両方を与える複数の冗長位置を設けるための技術の一実施形態のフローチャートである。プレイリストが上述した代替えストリームを含む場合に、その代替えストリームは、帯域巾又は装置の代替え物として動作するだけでなく、故障フォールバックとして動作することもできる。例えば、クライアントが(例えば、404エラー又はネットワーク接続エラーのために)ストリームに対するプレイリストファイルを再ロードできない場合には、クライアントは、代替えストリームへスイッチするよう試みることができる。図10を参照すれば、フェイルオーバー保護を具現化するために、第1のサーバー装置又は第1のコンテンツ配布サービスは、図2Cを参照して述べたように、オペレーション1002において、ストリーム又は複数の代替え帯域巾ストリームを生成するように構成される。オペレーション1004において、第1のサーバー装置又は第1のコンテンツ配布サービスは、オペレーション1002において発生されたストリームからプレイリストファイルを発生する。第1のサーバー装置又は第2のコンテンツ配布サービスは、オペレーション1006において、並列ストリーム又はストリームのセットを生成すると共に、プレイリストも生成する。これらの並列ストリームは、バックアップストリームと考えることができる。次いで、バックアップストリームのリストがオペレーション1008においてプレイリストファイルに追加され、一次ストリームの後に、各帯域巾のバックアップストリームがリストされるようにする。例えば、一次ストリームがサーバーALPHAから到来しそしてバックアップストリームがサーバーBETAにある場合には、プレイリストファイルが次のようになる。
#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
【0128】
バックアップストリームは、各帯域巾のバックアップがその帯域巾に対する一次の後にリストされたプレイリストにおける一次ストリームと混合されることに注意されたい。クライアントは、単一のバックアップストリームセットに限定されない。上述した例において、ALPHA及びBETAの後に、例えば、GAMMAが続く。同様に、ストリームの完全な並列セットを与える必要はない。例えば、単一の低帯域巾ストリームがバックアップサーバーに与えられる。
【0129】
オペレーション1010において、クライアントは、第1のサーバー装置又は第1のコンテンツ配布サービスに関連した第1のストリームを使用して第1のURLからプレイリストファイルをダウンロードするように試みる。図11は、一実施形態により、クライアント1102が、1つ以上のURL、サーバー装置又はコンテンツ配布サービスと両方向に通信するネットワークを示す。プレイリストファイルは、オペレーション1012において、第1のURL、サーバー装置又はコンテンツ配布サービスからクライアント1102へ送信される。クライアントが、第1のURL、サーバー装置又はコンテンツ配布サービスからプレイリストファイルをダウンロードできない(例えば、ストリームのインデックスファイルを再ロードするエラーのために)場合には、クライアントは、代替えストリームへスイッチするよう試みる。1つのストリームに欠陥(例えば、インデックスロード欠陥)がある場合には(例えば、オペレーション1010)、クライアントは、オペレーション1014においてネットワーク接続がサポートする最も高い帯域巾の代替えストリームを選択する。同じ帯域巾の複数の代替え物がある場合には、クライアントは、プレイリストに載せられた順序でそれらを選択する。例えば、クライアント1102がURL 1から首尾よくダウンロードできない場合には、URL 2又は別のURLからダウンロードしてもよく、この場合、プレイリストファイルは、代替えURLからクライアントへ送信される。この特徴は、サーバーのクラッシュやコンテンツ配布ノードの故障のような厳しいローカル欠陥の場合でも、メディアがクライアントに到達できるようにする冗長なストリームを与える。
【0130】
フェイルオーバー保護は、クライアントがプレイリスト及びメディアファイルを検索できるところの複数の冗長な位置を与える能力を備えている。従って、クライアントが第1の位置からストリームを検索できない場合には、第2、第3、等の位置からストリームにアクセスするよう試みることができる。
【0131】
一実施形態において、クライアントがプレイリストを検索できるところの付加的な位置を指示するため、同じ変形プレイリストタグに、同じ帯域巾であるが新たなURIの冗長位置が与えられる。クライアントは、最初に、望ましい帯域巾に関連した第1のURLにアクセスするよう試みることができる。第1のURLからプレイリストをダウンロードできない場合には、帯域巾に対して提示される次のURLにアクセスするよう試み、等々、全ての可能性が尽きるまで行う。
【0132】
以下の例は、2560000帯域巾に対する1冗長位置、及び7680000帯域巾に対する2冗長位置を含む。
#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
【0133】
この例において、ファイルネーム(例えば、mid-redundant2.m3u8)及び実際のURL(例えば、http://example2.com <http://example2.com/> ,http://example3.com <http://example3.com/>)の両方が変化することに注意されたい。しかしながら、一実施形態では、冗長位置は、ファイルネームに対してのみ又はウェブサイトに対してのみ変化する。
【0134】
一実施形態において、プレイリストは、サーバー装置によって圧縮されて、圧縮形態でクライアント装置へ送られる。圧縮されたプレイリストは、通常、プレイリストを表現するのに非圧縮のプレイリストより少数のビットしか必要とせず、従って、圧縮されたプレイリストは、送信又は受信されるときに、ワイヤレスセルラー電話ネットワークのようなネットワークの利用可能な帯域巾をあまり使用しない。一実施形態では、プレイリストは、HTTP1.1規格プロトコルのような転送プロトコルに適合又は適合するウェブサーバーによって使用される内蔵圧縮技術又はファシリティに基づいてウェブサーバーにより圧縮することができ、このような圧縮技術又はファシリティの一例は、HTTP1.1のデフレート又はgzip圧縮ファシリティである。他の実施形態では、規格ベースの転送プロトコルの一部分である他の規格ベースの圧縮ファシリティを使用することができる。圧縮されたプレイリストの使用は、一実施形態では、サーバー装置及びクライアント装置の任意の特徴である。一実施形態では、プレイリストは、テクスチャーコンテンツ(例えば、テキストファイル)であり、規格ベースのウェブサーバーによりデフレート又はgzipで効率的に圧縮され、次いで、クライアント装置により自動的に解凍される。gzip圧縮ファシリティのバージョンの説明は、www.ietf.org/rfc/rfc1952.txtに見ることができ、デフレート圧縮ファシリティのバージョンは、www.ietf.org/rfc/rfc1951.txtに見ることができる。多数のウェブサーバー、及びクライアント装置の多数のウェブブラウザは、デフレート又はgzipファシリティを自動的にサポートすることができる。
【0135】
一実施形態において、クライアント装置は、更新されたプレイリストを周期的に要求することができ、例えば、クライアント装置は、サーバーから、更新されたプレイリストを数秒ごとに(例えば、10、20又は30秒ごとに、或いは他の時間周期で)要求することができる。クライアントが生のゲーム中の任意の時点で生のゲームを始めから見始めるのを許す生の進行中の野球ゲームのプレイリストのような成長するプレイリストは、その成長するプレイリストがネットワークを通して繰り返し送信されるので、圧縮の使用でネットワークの帯域巾の消費を制限できるに充分な大きさとなる。
【0136】
一実施形態において、クライアント装置は、いつプレイリスト(更新されたプレイリストのような)を要求するか、どんな圧縮技術(デフレート又はgzipのような)をサポートできるか、任意に特定することができ、これら技術をサポートすることは、クライアント装置が、圧縮又はエンコードされたコンテンツを解読又はデコードできることを意味する。圧縮技術を任意に特定したクライアント装置のプレイリスト要求は、一実施形態において、プレイリストに対する圧縮技術をサポートすることが要求されずに非圧縮のプレイリストを送信できるウェブサーバーによって受け取られる。ウェブサーバーは、クライアント装置の要求に応答して、非圧縮のプレイリスト、又はプレイリストに対するクライアント装置の要求で特定された圧縮技術の1つを使用して圧縮されたプレイリストをクライアント装置へ送信することができる。クライアント装置は、プレイリストを受け取り、そしてそれをここに述べるように使用し、即ちプレイリストが圧縮された場合には、クライアント装置のウェブブラウザにおけるデコーダのようなクライアント装置のデコーダを使用してそれがデコードされる。
【0137】
図8は、電子システムの一実施形態のブロック図である。図8に示す電子システムは、例えば、デスクトップコンピュータシステム、ラップトップコンピュータシステム、セルラー電話、セルラーイネーブルPDAを含むパーソナルデジタルアシスタント(PDA)、セットトップボックス、娯楽システム、又は他の消費者向け電子装置を含むある範囲の電子システム(ワイヤード又はワイヤレス)を表すことが意図される。代替え電子システムは、より多くの、より少ない及び/又は異なるコンポーネントを含んでもよい。図8の電子システムは、クライアント装置及び/又はサーバー装置を構成するように使用されてもよい。
【0138】
電子システム800は、情報を通信するためのバス805又は他の通信装置と、情報を処理するためにバス805に結合されたプロセッサ810とを備えている。電子システム800は、単一のプロセッサをもつように示されているが、電子システム800は、複数のプロセッサ及び/又はコプロセッサを含んでもよい。電子システム800は、更に、バス805に結合されたランダムアクセスメモリ(RAM)又は他のダイナミック記憶装置820(メインメモリと称される)を備え、これは、プロセッサ810により実行されるインストラクション及び情報を記憶する。又、このメインメモリ820は、プロセッサ810によるインストラクションの実行中に変数又は他の中間情報を一時的に記憶するように使用されてもよい。
【0139】
電子システム800は、バス805に結合されたリードオンリメモリ(ROM)及び/又は他のスタティック記憶装置830も備え、これは、プロセッサ810のためのスタティック情報及びインストラクションを記憶する。データ記憶装置840は、情報及びインストラクションを記憶するためにバス805に結合される。フラッシュメモリ又は磁気ディスク又は光学ディスク及びそれに対応するドライブのようなデータ記憶装置840が、電子システム800に結合される。
【0140】
又、電子システム800は、バス805を経て、陰極線管(CRT)又は液晶ディスプレイ(LCD)のようなディスプレイ装置850に結合され、ユーザに情報を表示する。又、電子システム800は、アルファニューメリック及び他のキーを含むアルファニューメリック入力装置860も備え、これは、情報及びコマンド選択をプロセッサ810へ通信するためにバス805に結合される。別の形式のユーザ入力装置は、方向情報及びコマンド選択をプロセッサ810へ通信すると共に、ディスプレイ850上のカーソル移動を制御するための、タッチパッド、マウス、トラックボール又はカーソル方向キーのようなカーソルコントロール870である。
【0141】
更に、電子システム800は、ローカルエリアネットワークのようなネットワークにアクセスを与えるために1つ以上のネットワークインターフェイス880を備えている。このネットワークインターフェイス880は、例えば、1つ以上のアンテナを表すアンテナ885を有するワイヤレスネットワークインターフェイスを含む。又、電子システム800は、WiFi、ブルーツース、及びセルラー電話インターフェイスの組み合わせのような複数のワイヤレスネットワークインターフェイスを含むことができる。又、ネットワークインターフェイス880は、例えば、イーサネットケーブル、同軸ケーブル、光ファイバケーブル、シリアルケーブル、又はパラレルケーブルのようなネットワークケーブル887を経て、リモート装置と通信するためのワイヤードネットワークインターフェイスも含む。
【0142】
一実施形態において、ネットワークインターフェイス880は、例えば、IEEE802.11b及び/又はIEEE802.11g規格に適合することにより、ローカルエリアネットワークへのアクセスを与え、及び/又はワイヤレスネットワークインターフェイスは、例えば、ブルーツース規格に適合することにより、パーソナルアクセスネットワークへのアクセスを与えることができる。他のワイヤレスネットワークインターフェイス及び/又はプロトコルをサポートすることもできる。
【0143】
ワイヤレスLAN規格を経ての通信に加えて又はそれに代わって、ネットワークインターフェイス880は、例えば、時分割多重アクセス(TDMA)プロトコル、移動通信用のグローバルシステム(GSM)プロトコル、コード分割多重アクセス(CDMA)プロトコル、及び/又は他の形式のワイヤレス通信プロトコルを使用して、ワイヤレス通信を行うことができる。
【0144】
本明細書において「一実施形態」又は「実施形態」とは、その実施形態に関連して述べた特定の特徴、構造又は特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。本明細書の種々の場所に「一実施形態」という句が現れたときには、必ずしも、全てが同じ実施形態を指すのではない。
【0145】
以上、本発明の特定の実施形態を説明したが、本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、明細書及び添付図面は、本発明を単に例示するものであって、それに限定されるものではない。
【0146】
アペンディックス
以下のアペンディックスは、本発明の特定の実施形態によるプロトコルのドラフト仕様書である。このアペンディックスにおける幾つかのキーワード(例えば、MUST、MUST NOT、SHALL、SHALL NOT、等)の使用は、この特定の実施形態に適用されるもので、本開示に述べる他の実施形態には適用されないことが理解されよう。
概略
本書は、HTTPを経てマルチメディアデータの無限のストリームを送信するためのプロトコルについて述べる。これは、ファイルのデータフォーマットと、ストリームのサーバー(送信者)及びクライアント(受信者)により行われるアクションとを特定する。このプロトコルのバージョン1.0について述べる。
目次
1.序文
2.概要
3.プレイリストファイル
3.1.新たなタグ
3.1.1.EXT−X−TARGETDURATION
3.1.2.EXT−X−MEDIA−SEQUENCE
3.1.3.XEX−X−KEY
3.1.4.EXT−X−PROGRAM−DATE−TIME
3.1.5.EXT−X−ALLOW−CACHE
3.1.6.EXT−X−ENDLIST
3.1.7.EXT−X−STREAM−INF
3.1.8.EXT−X−DISCONTINUITY
4.メディアファイル
5.キーファイル
5.1.AES−128のためのIV
6.クライアント/サーバーアクション
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.参照文献
規範的参照文献
情報参照文献
【0147】
1.序文
本書は、HTTP[RFC2616]を経てマルチメディアデータの無限ストリームを送信するためのプロトコルについて述べる。このプロトコルは、メディアデータの暗号化と、ストリームの代替えバージョン(例えば、ビットレート)の付与とをサポートする。メディアデータは、それが生成されるや否や送信され、ほぼリアルタイムで受け取ることができるようにする。
HTTPのような関連規格について述べる外部の参照文献は、第9章に列挙する。
2.概要
マルチメディアの提示は、付加的なURIの順序付けされたリストであるプレイリストファイルに対するURI[RFC3986]により特定される。プレイリストファイルの各URIは、単一の隣接ストリームのセグメントであるメディアファイルを指す。
ストリームを再生するために、クライアントは、先ず、プレイリストファイルを得、そしてプレイリスト内の各メディアファイルを得て再生する。本書に述べるようにプレイリストファイルを再ロードして、付加的なセグメントを発見する。
本書におけるキーワード“MUST”“MUST NOT”“REQUIRED”“SHALL”“SHALL NOT”“SHOULD”“SHOULD NOT”“RECOMMENDED”“MAY”及び“OPTIONAL”は、RFC2119[RFC2119]に述べるように解釈されるべきである。
3.プレイリストファイル
プレイリストは、拡張型のM3Uプレイリストファイル[M3U]でなければならない(MUST)。本書は、付加的なタグを定義することによりM3Uファイルフォーマットを拡張する。
M3Uプレイリストは、個々のラインより成るテキストファイルである。それらラインは、単一のLFキャラクタか、又はCRキャラクタ及びそれに続くLFキャラクタにより終了となる。各ラインは、URI、ブランクであるか、又はコメントキャラクタ‘#’でスタートする。URIは、再生されるべきメディアファイルを識別する。ブランクラインは、無視される。
コメントキャラクタ‘#’でスタートするラインは、コメント又はタグである。タグは、#EXTで始まる。‘#’で始まる他の全てのラインは、コメントであり、無視しなければならない(SHOULD)。
ネームが.m3u8で終わり及び/又はHTTPコンテンツタイプ“application/vnd.apple.mpegurl”を有するM3Uプレイリストファイルは、UTF−8[RFC3629]でエンコードされる。ネームが.m3uで終わり及び/又はHTTPコンテンツタイプ[RFC2616]“audio/mpegurl”を有するファイルは、US−ASCII[US_ASCII]でエンコードされる。
具現化は、ネームが.m3u8で終わるか、又はHTTPを経て送信される場合にコンテンツタイプ“application/vnd.apple.mpegurl”を有するプレイリストファイルを発生しなければならない(SHOULD)。互換性のために、具現化は、ネームが.m3uで終わり及び/又はHTTPコンテンツタイプ“audio/mpegurl”を有するプレイリストファイルを発生してもよい(MAY)。
拡張型M3Uファイルフォーマットは、2つのタグEXTM3U及びEXTINFを定義する。拡張型M3Uファイルは、基本的M3Uファイルから、#EXTM3Uでなければならない(MUST)その第1ラインにより区別される。
EXTINFは、それに続くURIにより識別されるメディアファイルを記述するレコードマーカーである。各メディアファイルURIは、EXTINFタグが先行しなければならない(MUST)。そのフォーマットは、次の通りである。
#EXTINF:<duration>、<title>
“duration”は、メディアファイルの期間を秒で特定する整数である。この期間は、最も近い整数に丸めねばならない(SHOULD)。カンマに続くラインの残りは、メディアファイルのタイトルである。
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−TARGETDURATION
EXT−X−TARGETDURATIONタグは、主提示に追加される次のメディアファイルのおおよその期間を指示する。これは、プレイリストファイルに現れねばならない(MUST)。そのフォーマットは、次の通りである。
#EXT−X−TARGETDURATION:<seconds>
メディアファイルの実際の期間は、ターゲット期間から若干異なってもよい(MAY)。
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であると考えねばならない(SHALL)。
EXT−X−MEDIA−SEQUENCEタグの取り扱いに関する情報は、第6.2.1章及び第6.2.4章を参照されたい。
3.1.3.EXT−X−KEY
メディアファイルは、暗号化されてもよい(MAY)。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−TIME
EXT−X−PROGRAM−DATE−TIMEタグは、次のメディアファイルの開始を絶対的な日付及び/又は時刻に関連付ける。日付/時刻表現は、ISO/IEC8601:2004[ISO_8601]であり、時間ゾーンを指示しなければならない(SHOULD)。例えば、次の通りである。
#EXT−X−PROGRAM−DATE−TIME:<YYYY-MM-DDThh:mm:ssZ>
3.1.5.EXT−X−ALLOW−CACHE
EXT−X−ALLOW−CACHEタグは、クライアントが、ダウンロードされたメディアファイルを後で再生するためにキャッシュ記憶してもよいか(MAY)どうか指示する。そのフォーマットは、次の通りである。
#EXT−X−ALLOW−CACHE:<YES|NO>
3.1.6.EXT−X−ENDLIST
EXT−X−ENDLISTタグは、それ以上のメディアファイルがプレイリストファイルに追加されないことを指示する。そのフォーマットは、次の通りである。
#EXT−X−ENDLIST
3.1.7.EXT−X−STREAM−INF
EXT−X−STREAM−INFタグは、プレイリストファイルにおける次のURIが別のプレイリストファイルを識別することを指示する。そのフォーマットは、次の通りである。
#EXT−X−STREAM−INF:[attribute=value][,attribute=value]*
<URI>
EXT−X−STREAM−INFタグについて次の属性が定義される。
BANDWIDTH=<n>
但し、nは、秒当たりのビット数として表されるストリームビットレートのおおよその上限である。
PROGRAM−ID=<i>
但し、iは、プレイリストファイルの範囲内の特定の提示を独特に識別する番号である。
プレイリストファイルは、同じ提示の変形ストリームを記述するために同じPROGRAM−IDを伴う複数のEXT−X−STREAM−INF URIを含んでもよい(MAY)。
CODECS=“[format][,format]*”
但し、各フォーマットは、プレイリストファイル内のメディアファイルに存在するメディアサンプル形式を特定する。
有効なフォーマット識別子は、RFC4281[RFC4281]により定義されたISOファイルフォーマットネームスペースにおける識別子である。
3.1.8.EXT−X−DISCONTINUITY
EXT−X−DISCONTINUITYタグは、それに続くメディアファイルが、それに先行するものとは異なる特性を有することを指示する。変更してもよい(MAY)特性のセットは、次の通りである。
○ファイルフォーマット
○トラックの数及び形式
○エンコーディングパラメータ
○エンコーディングシーケンス
○タイムスタンプシーケンス
そのフォーマットは、次の通りである。
#EXT−X−DISCONTINUITY
4.メディアファイル
プレイリストファイルにおける各メディアファイルURIは、全体的提示のセグメントであるメディアファイルを識別しなければならない(MUST)。各メディアファイルは、MPEG−2トランスポートストリーム、MPEG−2番組ストリーム、又はMPEG−2オーディオ基本的ストリーム[ISO_13818]としてフォーマットされねばならない(MUST)。提示における全てのメディアファイルは、同じフォーマットを有していなければならない(MUST)。
トランスポートストリームファイルは、単一のMPEG−2番組を含まねばならない(MUST)。各ファイルのスタートに、番組アソシエーションテーブル及び番組マップテーブルがなければならない(SHOULD)。ビデオを含むファイルは、少なくとも1つのキーフレームと、ビデオデコーダを完全に初期化するに充分な情報とを有していなければならない(SHOULD)。
クライアントは、合理的なサブセットを選択することにより特定形式(例えば、オーディオ又はビデオ)の複数のトラックを取り扱うように準備しなければならない(SHOULD)。クライアントは、彼らが認識しないトランスポートストリーム内のプライベートストリームを無視しなければならない(MUST)。
メディアファイル内部のストリーム内及び複数のメディアファイルを横切る対応ストリーム間のサンプルに対するエンコーディングパラメータは、一貫したままでなければならない(SHOULD)。しかしながら、クライアントは、彼らが遭遇する変化をエンコードすることを、例えば、解像度変化を受け容れるようにビデオコンテンツをスケーリングすることで、取り扱わねばならない(SHOULD)。
5.キーファイル
URIパラメータを伴うEXT−X−KEYタグは、キーファイルを識別する。キーファイルは、プレイリストにおける後続メディアファイルを解読するのに使用しなければならない(MUST)暗号キーを含む。
AES−128暗号化方法は、16オクテットキーを使用する。キーファイルのフォーマットは、バイナリーフォーマットにおけるこれら16オクテットのパックされたアレイに過ぎない。
5.1.AES−128のためのIV
128ビットAESは、暗号及び解読を行うときに同じ16オクテット初期化ベクトル(IV)を供給することを要求する。このIVを変更すると、暗号化の強度が高くなる。
暗号化METHOD AES−128を使用するときには、具現化は、メディアファイルを暗号化又は解読する際にメディアファイルのシーケンス番号をIVとして使用しなければならない(SHALL)。このシーケンス番号のビッグエンディアンバイナリー表現を16オクテットバッファに配して(左側に)ゼロをパディングしなければならない(SHALL)。
6.クライアント/サーバーアクション
本章は、サーバーがどのようにプレイリスト及びメディアファイルを発生し、及びクライアントがどのようにそれをダウンロードして再生すべきか説明する。
6.1.サーバープロセス
MPEG−2ストリームの発生は、本書の範囲外であり、これは、主提示を含む連続的ストリームのソースを簡単に推定するものである。
サーバーは、ストリームを、その期間がほぼ等しい個々のメディアファイルに分割しなければならない(MUST)。サーバーは、個々のメディアファイルの有効なデコードをサポートするポイント、例えば、パケット及びキーフレーム境界においてストリームを分割するように試みなければならない(SHOULD)。
サーバーは、そのクライアントがファイルを得るのを許すURIをメディアファイルごとに生成しなければならない(MUST)。
サーバーは、プレイリストファイルを生成しなければならない(MUST)。プレイリストファイルは、第3章で述べたフォーマットに適合しなければならない。サーバーが利用したい各メディアファイルのURIは、それが再生される順序でプレイリストに現れねばならない(MUST)。URIがプレイリストファイルにある場合には全メディアファイルがクライアントに利用できねばならない。
プレイリストファイルは、EXT−X−TARGETDURATIONタグを含まねばならない(MUST)。これは、主提示に追加される次のメディアファイルのおおよその期間を指示しなければならない(MUST)。この値は、全提示に対して一定のままでなければならない(MUST)。典型的なターゲット期間は、10秒である。
サーバーは、そのクライアントがファイルを得るのを許すURIをプレイリストファイルに対して生成しなければならない(MUST)。
プレイリストファイルの変更は、クライアントの観点から原子的に行われねばならない(MUST)。
プレイリストにおける各メディアファイルURIの前には、メディアファイルのおおよその期間を指示するEXTINFタグがなければならない(MUST)。
サーバーは、URIの前にEXT−X−PROGRAM−DATE−TIMEタグを置くことにより絶対日付及び時刻をメディアファイルに関連付けてもよい(MAY)。日付及び時刻の値は、任意である。
プレイリストが提示の最終的メディアファイルを含む場合には、プレイリストファイルは、EXT−X−ENDLISTタグを含まねばならない。
サーバーが全提示を除去したい場合には、プレイリストファイルをクライアントに利用不能にしなければならない(MUST)。これは、プレイリストファイルにおける全メディアファイルが、除去時に、少なくともプレイリストファイルの期間中クライアントに利用できるままとなるよう保証しなければならない(SHOULD)。
6.1.1.スライディングウインドウプレイリスト
サーバーは、メディアファイルの利用を、プレイリストに最新に追加されたものに限定してもよい(MAY)。これを行うために、プレイリストファイルは、常に、厳密に1つのEXT−X−MEDIA−SEQUENCEタグを含まねばならない(MUST)。その値は、メディアファイルURIがプレイリストファイルから除去されるたびに1だけインクリメントされねばならない(MUST)。
メディアファイルURIは、それらが追加された順序でプレイリストファイルから除去されねばならない(MUST)。
サーバーがプレイリストからメディアファイルURIを除去するときに、メディアファイルは、メディアファイルの期間+メディアファイルが現れた最も長いプレイリストファイルの期間に等しい時間周期中、クライアントに利用可能なままとされる。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。
サーバーがメディアファイルを除去する計画である場合には、HTTP満了ヘッダが、クライアントへの配信時に、計画生存時間を反映するように保証しなければならない(SHOULD)。
サーバーは、EXT−X−ENDLISTタグが存在しない限り、少なくとも3つの主提示メディアファイルをプレイリストに常に維持しなければならない(MUST)。
6.1.2.メディアファイルの暗号化
メディアファイルを暗号化すべき場合には、サーバーは、許可されたクライアントが解読キーを含むキーファイルを得るのを許すURIを定義しなければならない(MUST)。このキーファイルは、第5章で述べたフォーマットに適合しなければならない。
サーバーは、キーがキャッシュ記憶されたことを指示するためにキー応答に満了ヘッダをセットしてもよい(MAY)。
暗号化METHODがAES−128である場合には、AES−128 CBC暗号を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を暗号化しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第5章に述べたIVとして使用しなければならない(MUST)。
サーバーは、プレイリストファイルにおけるURIの直前のEXT−X−KEYタグにより特定された方法を使用してプレイリストにおける各メディアファイルを暗号化しなければならない(MUST)。METHODがNONEであるEXT−X−KEYタグが先行するか、又はEXT−X−KEYタグが先行しないメディアファイルは、暗号化してはならない(MUST NOT)。
各EXT−X−KEYタグのURIは、METHODがNONEでない限り、プレイリストファイルに現れるか又は現れた1つおきのEXT−X−KEYタグのURIとは異なるものでなければならない。METHODがNONEのEXT−X−KEYタグは、URIパラメータを含んではならない。
サーバーは、プレイリストファイルがそのキーで暗号化されたメディアファイルへのURIを含む場合には、プレイリストファイルからEXT−X−KEYタグを除去してはならない(MUST NOT)。
6.1.3.変形ストリームの付与
サーバーは、同じ提示の異なるエンコーディングを与えるために複数のプレイリストファイルを提供してもよい(MAY)。もしそうであれば、クライアントがエンコーディング間を動的にスイッチできるように各変形ストリームを列挙した変形プレイリストファイルを付与しなければならない(SHOULD)。
変形プレイリストは、変形ストリームごとにEXT−X−STREAM−INFタグを含まねばならない(MUST)。同じ提示に対する各EXT−X−STREAM−INFタグは、同じPROGRAM−ID属性値を有していなければならない(MUST)。各提示に対するPROGRAM−ID値は、変形プレイリスト内で独特でなければならない(MUST)。
EXT−X−STREAM−INFタグがCODECS属性を含む場合には、属性値は、プレイリストファイルに現れる又は現れるであろうメディアファイルに存在する[RFC4281]により定義された各フォーマットを含まねばならない(MUST)。
サーバーは、変形ストリームを発生するときには、次の制約を満足しなければならない(MUST)。
各変形ストリームは、主提示の部分ではないコンテンツを含む同じコンテンツで構成されねばならない(MUST)。
サーバーは、ストリームの最小ターゲット期間という精度内で、全ての変形ストリームに対して同じコンテンツ周期が利用できるようにしなければならない(MUST)。
変形ストリームにおける一致するコンテンツは、一致するタイムスタンプを有していなければならない。これは、クライアントがストリームの同期をとれるようにする。
基本的なオーディオストリームファイルは、ID3 PRIVタグ[ID3]の前に、“com.apple.streaming.transportStreamTimestamp”という所有者識別子を設けることにより、ファイルにおける第1サンプルのタイムスタンプを信号しなければならない(MUST)。バイナリーデータは、ビッグエンディアン8オクテット数として表現された33ビットのMPEG−2番組基本的ストリームタイムスタンプでなければならない(MUST)。
加えて、全ての変形ストリームは、同じエンコードされたオーディオビットストリームを含まねばならない(SHOULD)。これは、クライアントが聴覚欠陥なしにストリーム間をスイッチできるようにする。
6.2.クライアントプロセス
クライアントがプレイリストファイルに対するURIをどのようにして得るかは、本書の範囲外であり、それを行っているものと仮定する。
クライアントは、URIからプレイリストファイルを得なければならない(MUST)。そのようにして得られたプレイリストファイルが変形プレイリストである場合には、クライアントは、変形プレイリストからプレイリストファイルを得なければならない(MUST)。
本書は、クライアントによる変形ストリームの処理を特定するものではない。
6.2.1.プレイリストファイルのローディング
プレイリストファイルがプレイリストURIからロード又は再ロードされるたびに、
クライアントは、プレイリストファイルが#EXTM3Uで始まることをチェックし、もしそうでない場合には、継続を拒否しなければならない(SHOULD)。クライアントは、それが認識しないタグを無視しなければならない(SHOULD)。
クライアントは、第6.2.4章に述べるように、ロードすべき次のメディアファイルを決定しなければならない(MUST)。
プレイリストがEXT−X−MEDIA−SEQUENCEタグを含む場合には、クライアントは、プレイリストファイルがロードされた時間にプレイリストファイルの期間を加えた時間に、その中の各メディアファイルが利用できるようになると仮定しなければならない(SHOULD)。プレイリストファイルの期間は、その中のメディアファイルの期間の和である。
6.2.2.プレイリストファイルの再生
クライアントは、再生がスタートするときにプレイリストからどのメディアファイルを最初に再生するか選択しなければならない(SHALL)。プレイリストファイルがEXT−X−ENDLISTタグを含む場合には、プレイリスト内のどのファイルを最初に再生してもよい(MAY)。EXT−X−ENDLISTタグが存在しない場合には、プレイリスト内の最後と最後から2番目のファイルを除くどのファイルを最初に再生してもよい(MAY)。
最初に再生すべきメディアファイルが選択されると、プレイリスト内のその後のメディアファイルは、それらが現れた順序でロードし、そしてそれらがロードされた順序で再生しなければならない(MUST)。
クライアントは、中断のない再生のためにメディアファイルが要求されるであろうときに前もってそれらをロードし、待ち時間及びスループットの一時的な変動を補償するよう試みなければならない(SHOULD)。
プレイリストファイルがEXT−X−ALLOW−CACHEタグを含みそしてその値がNOである場合には、クライアントは、ダウンロードされたメディアファイルを、それらが再生された後に、キャッシュ記憶してはならない(MUST NOT)。さもなければ、クライアントは、ダウンロードされたメディアファイルを、後で再生するために不定にキャッシュ記憶してもよい(MAY)。
クライアントは、EXT−X−PROGRAM−DATE−TIMEタグの値を使用して、番組発信時間をユーザに表示してもよい(MAY)。値が時間ゾーン情報を含む場合には、クライアントは、それを考慮しなければならない(SHALL)が、そうでない場合には、クライアントは、発信時間ゾーンを推定してはならない(MUST NOT)。
クライアントは、EXT−X−PROGRAM−DATE−TIMEタグの値の正しさ又は一貫性に依存してはならない(MUST NOT)。
6.2.3.プレイリストファイルの再ローディング
クライアントは、プレイリストファイルがEXT−X−ENDLISTタグを含まない限り、プレイリストファイルを周期的に再ロードしなければならない(MUST)。
しかしながら、クライアントは、本章で特定された以上に頻繁にプレイリストファイルを再ロードするよう試みてはならない(MUST NOT)。
クライアントがプレイリストファイルを初めてロードするか、又はプレイリストファイルを再ロードして、それが最後にロードされて以来変化したことが分かったときには、クライアントは、プレイリストファイルを再ロードするよう試みる前に、ある期間待機しなければならない(MUST)。この期間は、初期最小再ロード遅延と称される。これは、クライアントがプレイリストファイルのローディングを開始する時間から測定される。
初期最小再ロード遅延は、プレイリストにおける最後のメディアファイルの期間、又はターゲット期間の3倍の、どちらか小さい方である。メディアファイルの期間は、EXTINFタグにより特定される。
クライアントは、プレイリストファイルを再ロードし、それが変化しなかったことが分かると、再試みまで、ある期間待機しなければならない(MUST)。最小遅延は、ターゲット期間の3倍、又は初期最小再ロード遅延の倍数、のどちらか小さい方である。この倍数は、第1の試みでは0.5であり、第2の試みでは1.5であり、そしてその後の試みでは3.0である。
6.2.4.ロードすべき次のファイルの決定
クライアントは、プレイリストファイルがロードされるか又は再ロードされるたびにロードすべき次のメディアファイルを決定するためにプレイリストファイルを検査しなければならない(MUST)。
ロードすべき最初のファイルは、第6.2.2章に述べたように、最初に再生すべくクライアントが選択したファイルでなければならない(MUST)。
再生されるべき最初のファイルがロードされそしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含まない場合には、クライアントは、現在プレイリストファイルが、最後にロードされたメディアファイルのURIを、最初に見つけたオフセットに含むことを検証しなければならず(MUST)、そうでない場合は再生を中止する。ロードすべき次のメディアファイルは、プレイリストファイルにおいて最後にロードされたURIに続く第1のメディアファイルURIでなければならない(MUST)。
再生されるべき第1のファイルがロードされ、そしてプレイリストファイルがEXT−X−MEDIA−SEQUENCEタグを含む場合には、ロードされるべき次のメディアファイルは、ロードされた最後のメディアファイルのシーケンス番号より大きい最低シーケンス番号をもつものでなければならない(SHALL)。
6.2.5.暗号化されたメディアファイルの再生
プレイリストファイルが、キーファイルURIを特定するEXT−X−KEYタグを含む場合には、クライアントは、キーファイルを得、そしてその中のキーを使用して、別のEXT−X−KEYタグに遭遇するまで、そのEXT−X−KEYタグに続くメディアファイルを解読しなければならない(MUST)。
暗号化METHODがAES−128である場合には、AES−128 CBC解読を個々のメディアファイルに適用しなければならない(SHALL)。ファイル全体を解読しなければならない(MUST)。メディアファイルにわたって暗号ブロックチェーンを適用してはならない(MUST NOT)。メディアファイルのシーケンス番号を、第5.1章に述べたIVとして使用しなければならない(MUST)。
暗号化METHODがNONEである場合には、クライアントは、別のEXT−X−KEYタグに遭遇するまで、EXT−X−KEYタグに続く全てのメディアファイルを平文(非暗号)として処理しなければならない(MUST)。
7.例
本章は、幾つかの規範的プレイリストファイルを含む。
7.1.簡単なプレイリストファイル
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT-X-ENDLIST
7.2.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
7.3.暗号化されたメディアファイルを伴うプレイリストファイル
#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
7.4.変形プレイリストファイル
#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
8.セキュリティの考え方
プロトコルは、一般的に、HTTPを使用してデータを送信するものであるから、ほぼ同じセキュリティの考え方が適用される。RFC2616[RFC2616]の第15章を参照されたい。
メディアファイルパーサーは、典型的に、「ファジング」攻撃を受ける。クライアントは、サーバーから受け取ったファイルを構文解析するときに、不適合のファイルが拒絶されるように注意しなければならない(SHOULD)。
プレイリストファイルは、任意のエンティティのネットワーク要求をなすためにクライアントが使用するURIを含む。クライアントは、バッファのオーバーフローを防止するために応答のレンジチェックを行わねばならない(SHOULD)。RFC3986[RFC3986]の「セキュリティの考え方」の章を参照されたい。
クライアントは、サービス拒否攻撃への貢献を回避するためにURIにより怠惰に識別されるリソースをロードしなければならない(SHOULD)。
HTTP要求は、プライベートユーザデータを含むセッション状態(クッキー)をしばしば含む。具現化は、RFC2965[RFC2965]により特定されたクッキー制約及び満了ルールに従わねばならない(MUST)。RFC2965及びRFC2964[RFC2964]の「セキュリティの考え方」の章も参照されたい。
暗号キーは、URIによって特定される。これらのキーの配信は、HTTPのようなメカニズムにより、安全部門又はセッションクッキーに関連したTLS[RFC5246](以前のSSL)以上に安全確保されねばならない(SHOULD)。
9.参照文献
規範的参照文献
[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>.
【符号の説明】
【0148】
110:ネットワーク
120:サーバー
130:セグメンタ
135:インデクサ
140:セキュリティエージェント
145:HTTPサーバーエージェント
150、180:クライアント装置
160:アッセンブラーエージェント
165:出力ジェネレータエージェント
190:アッセンブラーエージェント
170、185:セキュリティエージェント
195:出力ジェネレータエージェント
400:サーバーストリームエージェント
410:制御ロジック
412:アプリケーション
414:メモリ
420:サーバーストリームエンジン
430:セグメンタ
440:インデクサ
450:セキュリティ
460:ファイルサーバー
500:クライアントストリームエージェント
510:制御ロジック
514:メモリ
516:インターフェイス
520:クライアントストリームエンジン
530:アッセンブラー
540:出力ジェネレータ
550:セキュリティ
【特許請求の範囲】
【請求項1】
サーバー装置においてデータのストリームを複数のメディアファイルへと分割する段階であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである段階と、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生する段階であって、その複数のURIは、前記データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する段階であって、その更新されたプレイリストファイルは、前記データのストリームの表現を再生成するための前記更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項2】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項1に記載の方法。
【請求項3】
前記複数のメディアファイルへの変更は、前記1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項1に記載の方法。
【請求項4】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去し、1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じることを含み、前記更新されたプレイリストファイルは、残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項1に記載の方法。
【請求項5】
前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項1に記載の方法。
【請求項6】
前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項5に記載の方法。
【請求項7】
前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定する段階と、
前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項8】
前記タグは、EXT−X−TARGETDURATIONタグを含む、請求項7に記載の方法。
【請求項9】
前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定する段階と、
1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項10】
前記1つ以上のタグは、1つ以上のEXT−X−MEDIA−SEQUENCEタグを含む、請求項9に記載の方法。
【請求項11】
前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定する段階と、
クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項12】
前記タグは、EXT−X−ALLOW−CACHEタグを含む、請求項11に記載の方法。
【請求項13】
実行時に、1つ以上のプロセッサが、
サーバー装置においてデータのストリームを複数のメディアファイルへと分割し、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものであり、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生し、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生し、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含む、
ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能な媒体を備えた物品。
【請求項14】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項13に記載の物品。
【請求項15】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項13に記載の物品。
【請求項16】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項13に記載の物品。
【請求項17】
前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項13に記載の物品。
【請求項18】
前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものである、請求項17に記載の物品。
【請求項19】
前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定し、
前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項20】
前記タグは、EXT−X−TARGETDURATIONタグを含む、請求項19に記載の物品。
【請求項21】
前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定し、
1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項22】
前記1つ以上のタグは、1つ以上のEXT−X−MEDIA−SEQUENCEタグを含む、請求項21に記載の物品。
【請求項23】
前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定し、
クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項24】
サーバー装置においてデータのストリームを複数のメディアファイルへと分割する手段であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである手段と、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生する手段であって、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する手段であって、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えた装置。
【請求項25】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIと、前記追加された1つ以上のメディアファイルとを含む、請求項24に記載の装置。
【請求項26】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項24に記載の装置。
【請求項27】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、前記転送プロトコルは、HTTP適合プロトコルであり、前記更新されたプレイリストは、選択された期間の満了時に発生され、そしてその選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項24に記載の装置。
【請求項28】
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する段階であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである段階と、
転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する段階であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する段階と、
更新されたプレイリストファイルをクライアント装置へ送信する段階であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項29】
前記複数のメディアファイルへの変更は、(a)1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、(b)前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いは(c)前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。
【請求項30】
前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。
【請求項31】
実行時に、1つ以上のプロセッサが、
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶し、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものであり、
非ストリーミング転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信し、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送し、
更新されたプレイリストファイルをクライアント装置へ送信し、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである、
ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能なメディアを備えた物品。
【請求項32】
前記複数のメディアファイルへの変更は、(a)1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、(b)前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いは(c)前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の方法。
【請求項33】
前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の物品。
【請求項34】
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する手段であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである手段と、
転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する手段であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する手段と、
更新されたプレイリストファイルをクライアント装置へ送信する手段であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えた装置。
【請求項35】
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
前記要求に応答して、(1)番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、(2)複数のメディアファイルに関連したパラメータを有する複数のタグと、を含むプレイリストファイルを受信する段階と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項36】
前記更新された複数のメディアファイルから番組の表現を発生する段階を更に備えた、請求項35に記載の方法。
【請求項37】
前記メディアファイルへの変更は、(a)1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、(b)前記複数のメディアファイルのうちの1つ以上を修正すること、或いは(c)前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項36に記載の方法。
【請求項38】
前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項37に記載の方法。
【請求項39】
実行時に、1つ以上のプロセッサが、
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する段階と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えた方法を遂行するようにさせる実行可能なインストラクションを記憶したマシン読み取り可能な記憶メディア。
【請求項40】
前記方法は、更に、前記更新されたプレイリストから番組の表現を発生する段階を更に備えた、請求項39に記載の記憶メディア。
【請求項41】
前記メディアファイルへの変更は、(a)1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、(b)前記複数のメディアファイルのうちの1つ以上を修正すること、或いは(c)前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項40に記載の記憶メディア。
【請求項42】
前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項41に記載の記憶メディア。
【請求項43】
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する手段と、
前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する手段と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する手段と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する手段であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えたデータ処理システム。
【請求項1】
サーバー装置においてデータのストリームを複数のメディアファイルへと分割する段階であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである段階と、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生する段階であって、その複数のURIは、前記データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する段階であって、その更新されたプレイリストファイルは、前記データのストリームの表現を再生成するための前記更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項2】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項1に記載の方法。
【請求項3】
前記複数のメディアファイルへの変更は、前記1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項1に記載の方法。
【請求項4】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去し、1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じることを含み、前記更新されたプレイリストファイルは、残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項1に記載の方法。
【請求項5】
前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項1に記載の方法。
【請求項6】
前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項5に記載の方法。
【請求項7】
前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定する段階と、
前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項8】
前記タグは、EXT−X−TARGETDURATIONタグを含む、請求項7に記載の方法。
【請求項9】
前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定する段階と、
1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項10】
前記1つ以上のタグは、1つ以上のEXT−X−MEDIA−SEQUENCEタグを含む、請求項9に記載の方法。
【請求項11】
前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定する段階と、
クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる段階と、
を更に備えた請求項1に記載の方法。
【請求項12】
前記タグは、EXT−X−ALLOW−CACHEタグを含む、請求項11に記載の方法。
【請求項13】
実行時に、1つ以上のプロセッサが、
サーバー装置においてデータのストリームを複数のメディアファイルへと分割し、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものであり、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生し、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生し、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含む、
ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能な媒体を備えた物品。
【請求項14】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含む、請求項13に記載の物品。
【請求項15】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項13に記載の物品。
【請求項16】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項13に記載の物品。
【請求項17】
前記更新されたプレイリストは、選択された期間の満了時に発生される、請求項13に記載の物品。
【請求項18】
前記選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものである、請求項17に記載の物品。
【請求項19】
前記プレイリストファイルに追加されるべき次のメディアファイルのおおよその期間を決定し、
前記おおよその期間を指示するタグを前記プレイリストファイルに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項20】
前記タグは、EXT−X−TARGETDURATIONタグを含む、請求項19に記載の物品。
【請求項21】
前記プレイリストファイルにおける1つ以上のURLのシーケンス番号を決定し、
1つ以上のシーケンス番号を指示する1つ以上のタグを前記プレイリストファイルに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項22】
前記1つ以上のタグは、1つ以上のEXT−X−MEDIA−SEQUENCEタグを含む、請求項21に記載の物品。
【請求項23】
前記メディアファイルを受信するクライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか決定し、
クライアント装置が再生後に前記メディアファイルを記憶することが許可されたかどうか指示するタグを前記プレイリストに含ませる、
ことを更に含む請求項13に記載の物品。
【請求項24】
サーバー装置においてデータのストリームを複数のメディアファイルへと分割する手段であって、その複数のメディアファイルの各々は、転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶されるべきものである手段と、
複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有するプレイリストファイルを発生する手段であって、複数のURLは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、
前記複数のメディアファイルへの変更に対応する更新されたプレイリストファイルを発生する手段であって、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えた装置。
【請求項25】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルを追加することを含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIと、前記追加された1つ以上のメディアファイルとを含む、請求項24に記載の装置。
【請求項26】
前記複数のメディアファイルへの変更は、1つ以上のメディアファイルへの修正を含み、前記更新されたプレイリストファイルは、複数のメディアファイルに対するURIを含み、そして前記複数のタグにおける1つ以上のタグは、前記1つ以上のメディアファイルへの修正を反映するように更新される、請求項24に記載の装置。
【請求項27】
前記複数のメディアファイルへの変更は、前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更に別のメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせることを含み、前記更新されたプレイリストファイルは、その残りのメディアファイルに対するURIを含み、前記データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、前記転送プロトコルは、HTTP適合プロトコルであり、前記更新されたプレイリストは、選択された期間の満了時に発生され、そしてその選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づく、請求項24に記載の装置。
【請求項28】
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する段階であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである段階と、
転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する段階であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである段階と、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する段階と、
更新されたプレイリストファイルをクライアント装置へ送信する段階であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項29】
前記複数のメディアファイルへの変更は、(a)1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、(b)前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いは(c)前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。
【請求項30】
前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項28に記載の方法。
【請求項31】
実行時に、1つ以上のプロセッサが、
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶し、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものであり、
非ストリーミング転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信し、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものであり、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送し、
更新されたプレイリストファイルをクライアント装置へ送信し、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである、
ようにさせる実行可能なインストラクションを記憶したコンピュータ読み取り可能なメディアを備えた物品。
【請求項32】
前記複数のメディアファイルへの変更は、(a)1つ以上のメディアファイルを追加すること、及び前記更新されたプレイリストファイルが、複数のメディアファイルに対するURI及びその追加された1つ以上のメディアファイルを含むこと、(b)前記1つ以上のメディアファイルへの修正、及び前記更新されたプレイリストファイルが複数のメディアファイルに対するURIを含むこと、並びに前記複数のタグのうちの1つ以上のタグが前記1つ以上のメディアファイルへの修正を反映するように更新されること、或いは(c)前記複数のメディアファイルから1つ以上の選択されたメディアファイルを除去しそして1つ以上の更なるメディアファイルを追加して1つ以上の残りのメディアファイルを生じさせ、前記更新されたプレイリストファイルがその残りのメディアファイルに対するURIを含むようにすること、のうちの少なくとも1つを含み、更に、データのストリームは、単一の番組に対するコンテンツの隣接時間ベースストリームであり、そして前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の方法。
【請求項33】
前記更新されたプレイリストは、選択された期間の満了時に発生され、その選択された期間は、前記プレイリストファイルにおける1つのタグの属性に基づくものであり、前記転送プロトコルは、HTTP適合プロトコルである、請求項31に記載の物品。
【請求項34】
複数のメディアファイルを転送プロトコル適合フォーマットでメモリに個々のファイルとして記憶する手段であって、その複数のメディアファイルは、データの隣接時間ベースストリームから分割されたものである手段と、
転送プロトコルを使用してプレイリストファイルをクライアント装置へ送信する手段であって、そのプレイリストファイルは、複数のタグ及び複数のユニバーサルリソースインジケータ(URI)を有し、その複数のURIは、データのストリームを再生成するための複数のメディアファイルの順序を指示するものである手段と、
前記複数のURIのうちの1つ以上を使用するクライアント装置からの1つ以上の要求に応答して、転送プロトコルを使用して複数のメディアファイルの1つ以上をクライアント装置へ転送する手段と、
更新されたプレイリストファイルをクライアント装置へ送信する手段であって、その更新されたプレイリストファイルは、前記複数のメディアファイルへの変更に対応し、更に、その更新されたプレイリストファイルは、データのストリームの表現を再生成するための更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えた装置。
【請求項35】
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
前記要求に応答して、(1)番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、(2)複数のメディアファイルに関連したパラメータを有する複数のタグと、を含むプレイリストファイルを受信する段階と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えたマシン実施方法。
【請求項36】
前記更新された複数のメディアファイルから番組の表現を発生する段階を更に備えた、請求項35に記載の方法。
【請求項37】
前記メディアファイルへの変更は、(a)1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、(b)前記複数のメディアファイルのうちの1つ以上を修正すること、或いは(c)前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項36に記載の方法。
【請求項38】
前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項37に記載の方法。
【請求項39】
実行時に、1つ以上のプロセッサが、
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する段階と、
前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する段階と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する段階と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する段階であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである段階と、
を備えた方法を遂行するようにさせる実行可能なインストラクションを記憶したマシン読み取り可能な記憶メディア。
【請求項40】
前記方法は、更に、前記更新されたプレイリストから番組の表現を発生する段階を更に備えた、請求項39に記載の記憶メディア。
【請求項41】
前記メディアファイルへの変更は、(a)1つ以上のメディアファイルを追加し、及び前記更新されたプレイリストファイルが、更新された複数のメディアファイルに対するURIを含むこと、(b)前記複数のメディアファイルのうちの1つ以上を修正すること、或いは(c)前記プレイリストファイルからメディアファイルの第1セットを除去しそしてプレイリストファイルに1つ以上の更なるメディアファイルを追加すること、のうちの少なくとも1つを含み、更に、前記転送プロトコルは、HTTP適合プロトコルである、請求項40に記載の記憶メディア。
【請求項42】
前記更新されたプレイリストは、前記プレイリストファイルにおける1つのタグの属性に基づく時間の満了時にクライアント装置により要求される、請求項41に記載の記憶メディア。
【請求項43】
転送プロトコルを使用して、プレイリストファイルをクライアント装置で要求する手段と、
前記要求に応答して、番組のデータの隣接時間ベースストリームに対する複数のメディアファイルを指示するユニバーサルリソースインジケータ(URI)と、複数のメディアファイルに関連したパラメータを有する複数のタグとを含むプレイリストファイルを受信する手段と、
前記プレイリストに指示された順序で前記メディアファイルの1つ以上を要求して受信する手段と、
前記メディアファイルへの変更に対応する更新されたプレイリストファイルを受信する手段であって、その更新されたプレイリストファイルは、更新された複数のメディアファイルの順序を指示する複数の更新されたURIを含むものである手段と、
を備えたデータ処理システム。
【図1】
【図2A】
【図2B】
【図2C】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図10】
【図11】
【図2A】
【図2B】
【図2C】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図10】
【図11】
【公開番号】特開2012−138083(P2012−138083A)
【公開日】平成24年7月19日(2012.7.19)
【国際特許分類】
【外国語出願】
【出願番号】特願2011−269431(P2011−269431)
【出願日】平成23年11月21日(2011.11.21)
【分割の表示】特願2011−544570(P2011−544570)の分割
【原出願日】平成21年12月28日(2009.12.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
2.GSM
【出願人】(503260918)アップル インコーポレイテッド (568)
【Fターム(参考)】
【公開日】平成24年7月19日(2012.7.19)
【国際特許分類】
【出願番号】特願2011−269431(P2011−269431)
【出願日】平成23年11月21日(2011.11.21)
【分割の表示】特願2011−544570(P2011−544570)の分割
【原出願日】平成21年12月28日(2009.12.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
2.GSM
【出願人】(503260918)アップル インコーポレイテッド (568)
【Fターム(参考)】
[ Back to top ]