JP2016026427A - リアルタイム又はリアルタイムに近いストリーミング - Google Patents

リアルタイム又はリアルタイムに近いストリーミング Download PDF

Info

Publication number
JP2016026427A
JP2016026427A JP2015165081A JP2015165081A JP2016026427A JP 2016026427 A JP2016026427 A JP 2016026427A JP 2015165081 A JP2015165081 A JP 2015165081A JP 2015165081 A JP2015165081 A JP 2015165081A JP 2016026427 A JP2016026427 A JP 2016026427A
Authority
JP
Japan
Prior art keywords
playlist
file
media
client device
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2015165081A
Other languages
English (en)
Other versions
JP6141926B2 (ja
Inventor
ウィリアム メイ
May William
ウィリアム メイ
ロジャー パントス
Pantos Roger
ロジャー パントス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/078,741 external-priority patent/US9729830B2/en
Application filed by Apple Inc filed Critical Apple Inc
Publication of JP2016026427A publication Critical patent/JP2016026427A/ja
Application granted granted Critical
Publication of JP6141926B2 publication Critical patent/JP6141926B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/43—Querying
    • G06F16/438—Presentation of query results
    • G06F16/4387—Presentation of query results by the use of playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast

Abstract

【課題】非ストリーミングプロトコルを用いて、ほぼリアルタイムなコンテンツストリーミングを可能とするプログラム、方法及びシステムを提供する。【解決手段】クライアントデバイスは、プレイリストファイルによって表されたコンテンツのタイプ（ビデオ・オン・デマンド、ライブ又はイベントのようなパラメータ）のインジケータを含むプレイリストファイルを受信し２００１、プレイリストファイルがタイプインジケータを含んでいた場合２００３；ＹＥＳ、パラメータによって示されたプレイリストファイルのタイプに基づいてプレイリストファイルを処理する２００７。【選択図】図２０

Description

〔関連出願〕
本出願は、２０１１年１月１１日出願の米国仮特許出願６１／４３１，８１３号（整理番号Ｐ７４３７Ｚ１１）の出願日付の恩典を請求し、本出願は、この米国仮特許出願をこれによって引用により本明細書に組み込んでいる。本出願はまた、以下の特許出願に関連している：（１）２００８年１２月３１日出願の特許出願第６１／１４２，１１０号（整理番号Ｐ７４３７Ｚ）；（２）２００９年３月１６日出願の特許出願第６１／１６０，６９３号（整理番号Ｐ７４３７Ｚ２）；（３）２００９年３月１７日出願の特許出願第６１／１６１，０３６号（整理番号Ｐ７４３７Ｚ３）；（４）２００９年４月７日出願の特許出願第６１／１６７，５２４号（整理番号Ｐ７４３７Ｚ４）；（５）２００９年９月８日出願の特許出願第６１／２４０，６４８号（整理番号Ｐ７４３７Ｚ５）；（６）２００９年１２月２１日出願の特許出願第６１／２８８，８２８号（整理番号Ｐ７４３７Ｚ６）；（７）２０１０年４月１日出願の特許出願第６１／３２０，２１３号（整理番号Ｐ７４３７Ｚ７）；（８）２０１０年４月７日出願の特許出願第６１／３２１，７６７号（整理番号Ｐ７４３７Ｚ８）；（９）２０１０年６月４日出願の特許出願第６１／３５１，８２４号（整理番号Ｐ７４３７Ｚ９）；（１０）２０１０年８月３１日出願の特許出願第６１／３７８，８９３号（整理番号Ｐ７４３７Ｚ１０）。これらの米国仮特許出願の全ては、これらが本発明の開示に矛盾しない限り、引用により本明細書に組み入れられる。
本米国特許出願は、以下の米国特許出願に関連しており、これらの各々は、これらが本発明の開示に矛盾しない限り、引用により本明細書に組み入れられる：（１）「リアルタイム又はリアルタイムに近いストリーミング」という名称の２００９年６月５日出願の特許出願第１の２／４７９，６９０号（整理番号Ｐ７４３７ＵＳ１）；（２）「リアルタイム又はリアルタイムに近いストリーミングのための変形ストリーム」という名称の２００９年６月５日出願の特許出願第１の２／４７９，６９８号（整理番号Ｐ７４３７ＵＳ２）；（３）「更新可能なリアルタイム又はリアルタイムに近いストリーミング」という名称の２００９年６月５日出願の特許出願第１の２／４７９，７３２号（整理番号Ｐ７４３７ＵＳ３）；（４）「リアルタイム又はリアルタイムに近いストリーミングのためのプレイリスト」という名称の２００９年６月５日出願の特許出願第１の２／４７９，７３５号（整理番号Ｐ７４３７ＵＳ４）；（５）「フェイルオーバー保護を提供するためのリアルタイム又はリアルタイムに近いストリーミングのための変形ストリーム」という名称の２０１０年９月８日出願の特許出願第１の２／８７８，００２号（整理番号Ｐ７４３７Ｘ）；（６）「圧縮されたプレイリストを有するリアルタイム又はリアルタイムに近いストリーミング」という名称の２０１０年１２月１４日出願の特許出願第１の２／９６８，２０２号（整理番号Ｐ７４３７Ｘ２）。
本発明の実施形態は、データ送信技術に関する。より具体的には、本発明の実施形態は、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）のような非ストリーミングプロトコルを使用したデータのストリーミングを可能にする技術に関する。
コンテンツのストリーミングは、一般的に、絶えずサーバデバイスから送信されてクライアントデバイスによって受信されるマルチメディアコンテンツを意味する。コンテンツは、通常、ストリーミングサーバによって配信される場合にエンドユーザに提示される。その名称は、媒体自体ではなく、媒体の配信方法を意味している。
ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１９５２．ｔｘｔ ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１９５１．ｔｘｔ
現在のストリーミングサービスは、一般的に、「ライブ」コンテンツをエンドユーザに配信するための専用サーバを必要とする。いずれの大規模な配備においても、これは、大きなコストをもたらす可能性があり、設定及び実行するのに専門技術を必要とする。この結果、ストリーミングに利用可能なコンテンツのライブラリは、十分に望ましいものとは言えない。
本明細書で説明する一実施形態において、プレイリストファイルは、プレイリストファイルによって提供されるコンテンツのタイプを示すことができる。コンテンツのタイプは、プレイリストファイルのタイプを定義することができ、プレイリストファイルのタイプは、プレイリストファイルのタグのパラメータで指定することができる。一実施形態において、タグは、＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ：［ＶＯＤ｜ＬＩＶＥ｜ＥＶＥＮＴ］の形式を取ることができ、従って、このタグは、ＶＯＤ又はＬｉｖｅ又はＥｖｅｎｔの１つを指定し、「ＶＯＤ」は、プレイリストファイルがビデオ・オン・デマンドコンテンツのためのものであることを示し、「Ｌｉｖｅ」は、プレイリストファイルがライブコンテンツのためのものであることを示し、不定の開始時間を有することができ、媒体ファイルがクライアントデバイスでの提示（例えば、ビデオを表示することを通じた再生）のために受信したのと実質的に同時に発生させることができ、「Ｅｖｅｎｔ」は、プレイリストファイルが、不定の終了時間を有するが、確定した固定開始時間を有することができ、クライアントデバイスでの提示のために媒体ファイルを受信したのと実質的に同時に発生させることができるイベントのためのものであることを示す。プレイリストファイルは、プレイリストファイルによって示された順序でプレイリストファイルを受信した後にクライアントデバイスによって検索することができる複数の媒体ファイルを示すユニバーサルリソースインジケータ（ＵＲＩ）を含むことができ、プレイリストファイルは、プレイリストファイルにおける複数の媒体ファイルの再生に関連するパラメータ（「ＶＯＤ」又は「ｌｉｖｅ」など）を有する＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥタグのような複数のタグを含むことができる。
プレイリストファイルのＴＹＰＥタグ（例えば、＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ）の存在は、プレイリストが、コンテンツのタイプに矛盾しない作動の方法を遵守することになり、それによってクライアントデバイスが、プレイリストのタイプに対して最適化することができる方法でプレイリストを処理することができることを実質的に通知する。クライアントデバイスは、「ＶＯＤ」又は「Ｌｉｖｅ」又は「Ｅｖｅｎｔ」のようなプレイリストタイプインジケータの存在を検査することができ、プレイリストタイプインジケータによる最適方式でプレイリストファイルを処理することができる。例えば、プレイリストタイプインジケータが「ＶＯＤ」である時に、クライアントデバイスは、ビデオ・オン・デマンドに対するプレイリストが変化しないと仮定することができるのでプレイリストファイルを更新しないように構成することができ、従って、更新を要求する必要性がない。更に、プレイリストタイプインジケータが「ＶＯＤ」である時に、クライアントデバイスは、ＥＮＤＬＩＳＴタグ（又はプレイリストが完全であることを示す他のタグ）に対してプレイリストファイルを調べるように構成することができ、このようなタグがプレイリストファイルからなくなっている場合、クライアントデバイスは、プレイリストファイルがエラーを有するとしてマーク付けすることができる。
プレイリストタイプインジケータが「Ｌｉｖｅ」である時に、クライアントデバイスは、更新されたプレイリストファイルを繰返し要求するように構成することができる。プレイリストタイプインジケータが「Ｅｖｅｎｔ」である時に、クライアントデバイスは、（ａ）更新されたプレイリストの最新部分だけをロードするか（それによって古い部分の受信を阻止する）又は（ｂ）更新されたプレイリストの最新部分だけを構文解析するか（それによって更新されたプレイリストの古い部分の再構文解析を阻止する）のいずれかを実行するように構成することができる。
一実施形態において、クライアントデバイスは、プレイリストファイルに指定された媒体ファイルのデータアクセスに関する統計値又は媒体ファイルを受信した時に起こるネットワークエラーを格納するように構成することができ、これらの統計値は、クライアントアプリケーションに利用することができ、ＡＰＩ（アプリケーションプログラムインタフェース）を通じて、ネットワークエラー又は媒体ファイルへのアクセスに関する情報（例えば、ＶＯＤ又はライブ番組の変形ストリーム間で何回表示が切り換わったかなど）の提示を可能にする。
一部の実施形態は、１つ又はそれよりも多くのインタフェースを通じて呼び出される他のプログラムコードと対話する呼出しプログラムコードを備えた環境における１つ又はそれよりも多くのアプリケーションプログラミングインタフェース（ＡＰＩ）を含む。様々なタイプのパラメータを更に含むことができ、様々な機能呼出し、メッセージ、又は他のタイプの起動は、呼出しプログラム及び呼び出されるコード間でＡＰＩを通じて転送することができる。更に、ＡＰＩは、ＡＰＩで定義されかつ呼び出されたプログラムコードで実施されるデータタイプ又はクラスを使用する機能を呼出しプログラムコードに提供することができる。
少なくともある一定の実施形態は、ＡＰＩを通じて呼び出されたソフトウエア構成要素と対話する呼出し側ソフトウエア構成要素を備えた環境を含む。この環境でＡＰＩを通じて作動する方法は、ＡＰＩを通じて１つ又はそれよりも多くの機能呼出し、メッセージ、他のタイプの起動又はパラメータを転送する段階を含む。
他の方法を本明細書に説明し、これらの方法を実行するためのシステムを本明細書に説明し、実行された時にこれらの方法のいずれか１つをデータ処理システムに実行させることができる実行可能命令を格納する機械可読非一時的ストレージ媒体を本明細書に説明する。
本発明を同じ参照番号が類似の要素を示す添付の図面の図に一例として制限ではなく例示する。
リアルタイム又はリアルタイムに近いコンテンツを送信及び受信することができるサーバ及びクライアントの一実施形態を示すブロック図である。 １つ又はそれよりも多くのサーバデバイスが非ストリーミングプロトコルを使用して媒体コンテンツをサポートするための技術の一実施形態を示す流れ図である。 １つ又はそれよりも多くのサーバデバイスが動的に更新されたプレイリストを１つ又はそれよりも多くのクライアントデバイスに提供するための技術の一実施形態を示す流れ図である。 １つ又はそれよりも多くのサーバデバイスが媒体コンテンツを複数のビットレートを使用してクライアントデバイスに提供するための技術の一実施形態を示す流れ図である。 クライアントデバイスが非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態を示す流れ図である。 クライアントデバイスが複数のビットレートを使用してコンテンツのストリーミングをサポートするための技術の一実施形態を示す流れ図である。 サーバストリームエージェントの一実施形態を示すブロック図である。 クライアントストリームエージェントの一実施形態を示すブロック図である。 複数のタグを備えたプレイリストファイルの実施形態を示す図である。 本明細書に説明するアセンブルストリームのための再生技術の一実施形態を示す流れ図である。 電子システムの一実施形態を示すブロック図である。 クライアントデバイスが変形プレイリストにおける代替のコンテンツ間で切り換えることができる方法の例を示す流れ図である。 クライアントデバイスが２つのプレイリストのコンテンツ間で切り換えることができる方法を示す更に別の流れ図である。 クライアントデバイスがオーディオパターン照合を使用してコンテンツ間で切り換えることができる方法の例を示す更に別の流れ図である。 図９Ｃの方法がオーディオパターン照合によってどのように実施されるかを示す図である。 代替ストリームを使用してクライアントデバイスに媒体コンテンツを提供する複数の冗長ロケーションを提供するための技術の一実施形態を示す流れ図である。 クライアント１１０２が一実施形態に従って１つ又はそれよりも多くのＵＲＬと双方向に通信するネットワークを示す図である。 プレイリストの作成及び配信を制御するための本発明の一実施形態による方法を示す流れ図である。 一実施形態においてプレイリストを例えば図１２Ａの方法を使用して送信又はそうでなければ配信することができる方法の時系列を示す図である。 クライアントデバイスで再生を制御するための本発明の一実施形態による方法を示す図である。 接続速度又は接続タイプに基づいて最小オーバーラップの量を適応的に判断するための一実施形態における方法を示す流れ図である。 ストリーム間で切り換えるためのオーバーラップを使用する実施形態の別の態様を示す図である。 ストリーム間で切り換えるためのオーバーラップを使用する実施形態の別の態様を示す図である。 ストリーム間で切り換えるためのオーバーラップを使用する実施形態の別の態様を示す図である。 本発明の一実施形態による別の方法を示す流れ図である。 タイムスタンプタグを使用してプレイリストファイルを作成するための一実施形態による方法を示す流れ図である。 プレイリストファイルのタイムスタンプタグを使用して媒体ファイルを検索するための一実施形態による方法を示す流れ図である。 受信機でバッファに入れられたストリーミングコンテンツからの再生を制御するためのユーザインタフェースの実施形態を示す図である。 ＵＩの時系列上のインジケータが移動した後の図１６Ｃの実施形態を示す図である。 図１６Ｃ及び１６Ｄに示すユーザインタフェースの実施形態を使用する方法を示す流れ図である。 媒体サービスデーモンがユーザアプリケーションと対話することを可能にするためのソフトウエアアーキテクチャの例を示す図である。 本発明の一部の実施形態で使用可能な例示的なＡＰＩアーキテクチャを示すブロック図である。 本発明の一部の実施形態で使用可能なソフトウエアスタックの例示的な実施形態を示す図である。 プレイリストタイプインジケータを使用することができる一実施形態による方法の例を示す流れ図である。 プレイリストタイプインジケータを使用することができる方法の別の例を示す流れ図である。 ＡＰＩを通じて媒体サーバアプリケーションからクライアントアプリケーションに統計値を提供することができるアーキテクチャの例を示す図である。
以下の説明では、多数の特定の詳細が示されている。しかし、本発明の実施形態は、これらの特定の詳細なしに実施することができる。他の例では、公知の回路、構造、及び技術は、この説明の理解を曖昧にしないために詳しく示していない。
本説明は、グラフィカルユーザインタフェース画像の図のような権利によって保護された内容を含む。本発明の出願人を含む権利の所有者は、ここにこれらの内容における権利を含む権利を留保する。権利の権利所有者は、合衆国特許登録商標庁のファイル又は記録内に表される通りに第三者が特許文書又は特許開示を複製することに異議を唱えないが、それ以外は全ての権利を留保する。著作権アップル・インコーポレーテッド２００９−２０１０。
一実施形態において、本明細書に説明する技術及び構成要素は、非ストリーミングプロトコル（ＨＴＴＰなど）及び他の技術（モーションピクチャエキスパートグループ（ＭＰＥＧ）ストリームなど）を使用してストリーミング体験を配信するための機構を含むことができる。例えば、リアルタイムに近いストリーミング体験をＨＴＴＰを使用して提供し、「ライブ」音楽又はスポーツイベント、ライブニュース、ウェブカメラフィードなどをブロードキャストすることができる。一実施形態において、プロトコルは、着信媒体データを複数の媒体ファイルにセグメント化し、サーバにこれらのセグメント化媒体ファイルを格納することができる。プロトコルはまた、クライアントをサーバに格納されたセグメント化媒体ファイルに向けるユニフォームリソース識別子（ＵＲＩ）を含むプレイリストファイルを作ることができる。セグメント化媒体ファイルがプレイリストファイルに従って再生された時に、クライアントは、ユーザに「ライブ」イベントのリアルタイムに近いブロードキャストを提供することができる。事前に記録されたコンテンツも類似の方法で提供することができる。
一実施形態において、サーバは、補足又は代替の媒体コンテンツ（広告、スポーツイベンツに関する統計値、主提示への付加的な媒体コンテンツなど）をブロードキャストイベントに動的に導入することができる。例えば、媒体イベントのクライアント再生中に、サーバは、付加的なＵＲＩをプレイリストファイルに追加することができ、ＵＲＩは、クライアントが補足媒体ファイルをダウンロードすることができるロケーションを識別することができる。クライアントは、サーバが導入したいずれかの補足又は付加的な（又は両方の）媒体コンテンツにアクセスするために、１つ又はそれよりも多くの更新されたプレイリストファイルをサーバから定期的に検索するように示されている。
一実施形態において、サーバは、累積モード又はローリングモードのいずれかで作動させることができる。累積モードでは、サーバは、プレイリストファイルを作成し、媒体ファイル識別子をプレイリストファイルの最後に添付することができる。次に、クライアントは、ダウンロードされた時に単一のプレイリストファイルからストリームの全ての部分へのアクセスを有する（例えば、ユーザは、番組の途中で開始することができる）。ローリングモードでは、サーバは、ローリングに基づいてプレイリストファイルの始めから媒体ファイル識別子を取り除くことによって媒体ファイルの利用可能度を制限することができ、それによってクライアントデバイスにアクセス可能な媒体コンテンツのスライディングウインドウを提供する。サーバはまた、媒体ファイル識別子をプレイリストに追加することができ、ローリングモードでは、サーバは、媒体ファイルの利用可能度をプレイリストに最近追加されたものに制限することができる。次に、クライアントは、見続けるために、プレイリストファイルの更新された複写を繰返しダウンロードする。プレイリストダウンローディングのためのローリング原理は、コンテンツが潜在的に時間的に無制限にされた時に有用になる（例えば、継続して作動されるウェブカムからのコンテンツ）。クライアントは、プレイリストにエンドタグを見つけるまでローリングモードで繰返しプレイリストを要求し続けることができる。
一実施形態において、この機構は、同じ提示の変形ストリームを提供することによってビットレート切り換えをサポートする。例えば、サービスを受ける提示のいくつかのバージョンをサーバに格納することができる。各バージョンは、実質的に同じコンテンツを有することができるが、異なるビットレートで符号化することができる。それによってクライアントデバイスは、例えば、再生の連続性を犠牲にすることなく、利用可能な帯域幅の検出に応答してビットレートを切り換えることができる。
一実施形態において、許可されていない使用に対してコンテンツを保護するための保護機能を提供することができる。例えば、予想を防ぐために、連続していない媒体ファイルの付番を使用することができる。媒体ファイルの暗号化を使用することができる。部分的な媒体ファイルリストを使用することができる。付加的な及び／又は異なる保護機能も提供することができる。
図１は、リアルタイム又はリアルタイムに近いコンテンツを送信及び受信することができるサーバ及びクライアントの一実施形態のブロック図である。図１の例は、ネットワークを通じてサーバに結合された２つのクライアントとの単純なサーバ−クライアント接続を提供する。クライアントのいずれの数も、本明細書に説明する技術及び機構を利用してサポートすることができる。更に、複数のサーバがコンテンツを提供することができ、及び／又は本明細書に説明する技術及び機構に従ってコンテンツを提供するために共に作動させることができる。例えば、１つのサーバがコンテンツを作成し、プレイリストを作成し複数の媒体（ファイルなど）を作成することができ、他のサーバは、作成されたコンテンツを格納して送信する。
ネットワーク１１０は、有線、無線（ＩＥＥＥ ８０２．１１、８０２．１６など）又はこれらのいずれかの組合せのネットワークのいずれかのタイプとすることができる。例えば、ネットワーク１００は、インターネット又はイントラネットとすることができる。別の一例として、ネットワーク１１０は、セルラーネットワーク（３Ｇ、ＣＤＭＡなど）とすることができる。一実施形態において、クライアントデバイス１５０及び１８０が、複数のネットワークのタイプを通じて通信することができる（例えば、各デバイスはＷｉＦｉ無線ＬＡＮを通じて及び無線セルラー電話ネットワークを通じて通信することができる）。例えば、クライアントデバイス１５０及び１８０は、セルラー無線電話ネットワーク、並びにデータネットワークを通じて通信することができるスマートフォン又はセルラー対応携帯情報端末とすることができる。これらのデバイスは、必要に応じてネットワークのいずれかのタイプ又はネットワーク間の切り換えを通じて本明細書に説明するストリーミング機構を利用することができる。
サーバ１２０は、当業技術で公知のいずれかの方法でＨＴＴＰサーバとして作動させることができる。すなわち、サーバ１２０は、ＨＴＴＰプロトコルを使用してコンテンツを提供するＨＴＴＰサーバエージェント１４５を含む。図１の例は、ＨＴＴＰの観点から説明されているが、他のプロトコルを類似の方式で利用することができる。セグメンタ１３０及びインデクサ１３５は、本明細書で説明するようにプレイリストファイルを有する媒体ファイルでコンテンツを提供するためにサーバ１２０（又は複数のサーバ）に存在するエージェントである。これらの媒体ファイル及びプレイリストファイルは、ＨＴＴＰプロトコルを使用してＨＴＴＰサーバエージェント１４５を通じて（又は他のサーバを通じて）ネットワーク１１０を通じて提供することができる。本明細書で説明したエージェントは、ハードウエア、ソフトウエア、ファームウエア、又はその組合せとして実施することができる。
セグメンタ１３０は、ＨＴＴＰプロトコルを通じて送信することができる複数の媒体ファイルに媒体データのストリームを分割するように働くことができる。インデクサ１３５は、セグメント化された媒体ファイルに対応するプレイリストファイルを作成するように働くことができ、それによってクライアントデバイスは、サーバ１２０によって提供されたコンテンツのリアルタイム又はリアルタイムに近い送信を提供するために媒体ファイルをリアセンブルすることができる。クライアントデバイスからの１つ又はそれよりも多くの要求に応答して、ＨＴＴＰサーバエージェント１４５（又は他のサーバ）は、インデクサ１３５によって生成された１つ又はそれよりも多くのプレイリストファイル及びセグメンタ１３０によって生成されたコンテンツの媒体ファイルを送信することができる。サーバ１２０は、本明細書に説明するセキュリティ機能（暗号化など）の１つ又はそれよりも多くを提供する任意的なセキュリティエージェント１４０を更に含むことができる。サーバ１２０は、図１に示されていない付加的な構成要素を含むことができる。
クライアントデバイス１５０及び１８０は、サーバ１２０からネットワーク１１０を通じてプレイリストファイル及び媒体ファイルを受信することができる。クライアントデバイスは、ネットワークを通じて送信されたデータを受信することができ、ネットワーク、例えば、無線移動デバイス、ＰＤＡ、娯楽デバイス、消費者電子デバイスなどを通じて受信したデータを利用して出力を発生させることができるいずれかのタイプの電子デバイスとすることができる。出力は、例えば、オーディオ、ビデオ、又はこれらのいずれかの組合せを含む媒体タイプの組合せのいずれかの媒体タイプとすることができる。
クライアントデバイス１５０は、アセンブラエージェント１６０及び出力発生エージェント１６５を含むことができる。同様に、クライアントデバイス１８０は、アセンブラエージェント１９０及び出力発生エージェント１９５を含むことができる。アセンブラエージェント１６０及び１８０は、サーバ１２０からプレイリストファイルを受信し、プレイリストファイルを使用してサーバ１２０からの媒体ファイルにアクセスしダウンロードする。出力発生エージェント１６５及び１９５は、ダウンロードされた媒体ファイルを使用して、クライアントデバイス１５０及び１６０それぞれからの出力を発生させる。出力は、１つ又はそれよりも多くのスピーカ、１つ又はそれよりも多くの表示画面、スピーカ及び表示画面の組合せ、又はいずれかの他の入力又は出力デバイスによって提供することができる。クライアントデバイスは、受信した媒体ファイル（圧縮媒体ファイル又は非圧縮媒体ファイルなど）を格納するためのバッファとして機能するメモリ（フラッシュメモリ又はＤＲＡＭなど）を含むことができ、バッファは、現在提示されているコンテンツの時間を超える提示可能なコンテンツに値する多くの秒数を提供することができ、それによって新しいコンテンツがダウンロードされている間バッファに入れられたコンテンツを後で表示することができる。このバッファは、クライアントデバイスが間欠的に遅いネットワーク接続を通じてコンテンツを検索しようとする間に提示可能なコンテンツを提供することができ、従って、バッファはネットワーク待ち時間又は接続問題を隠すことができる。
クライアントデバイス１５０及び１８０は、それぞれに本明細書に説明するセキュリティ機能の１つ又はそれよりも多くを提供する任意的なセキュリティエージェント１７０及び１８５を更に含むことができる。クライアントデバイス１５０及び１８０は、図１に示されていない付加的な構成要素を含むことができる。
一実施形態において、本出願に説明する技術を非ストリーミングプロトコル（ＨＴＴＰなど）を通じてマルチメディアデータの無制限ストリームを送信するために使用することができる。実施形態は、媒体データの暗号化及び／又はストリームの代替のバージョンの供給（例えば、代替のビットレートを提供するため）を含むことができる。媒体データが作成後直ちに送信することができるので、データは、実質的にリアルタイムで受信することができる。ファイルに対する例示的なデータフォーマット、並びにマルチメディアデータのストリームのサーバ（送信者）及びクライアント（受信者）によって行われる作動が提供されるが、他のフォーマットもサポートすることができる。
模擬のリアルタイムストリーム（又はリアルタイムに近いストリーム）として送信することができる媒体提示は、プレイリストファイルを示すユニバーサルリソースインジケータ（ＵＲＩ）によって指定される。一実施形態において、プレイリストファイルは、付加的なＵＲＩの順序付けられたリストである。プレイリストファイルにおける各ＵＲＩは、特定のプログラムのための媒体データの単一の連続ストリームとすることができるストリームのセグメントである媒体ファイルを示している。
媒体データのストリームを再生するために、クライアントデバイスは、サーバからプレイリストファイルを取得する。クライアントは、プレイリストファイルによって示された各媒体データファイルを取得及び再生する。一実施形態において、クライアントは、付加的な及び／又は異なる媒体セグメントを見出すためにプレイリストファイルを動的に又は繰返しリロードすることができる。
プレイリストファイルは、例えば、拡張Ｍ３Ｕプレイリストファイルとすることができる。一実施形態において、Ｍ３Ｕフォーマットを実質的に拡張する付加的なタグが使用される。Ｍ３Ｕは、ムービング・ピクチャ・エキスパート・グループ・オーディオ・レーヤ３・ユニフォーム・リソース・ロケータ（ＭＰ３ＵＲＬ）を示し、マルチメディアプレイリストを格納するのに使用されるフォーマットである。Ｍ３Ｕファイルは、媒体プレーヤが再生する１つ又はそれよりも多くの媒体ファイルのロケーションを含むテキストファイルである。
プレイリストファイルは、一実施形態において、個々の行から構成される拡張Ｍ３Ｕフォーマットテキストファイルである。行は、単一のＬＦ文字又はＬＦ文字が後に続くＣＲ文字のいずれかによって終わらせることができる。各行は、ＵＲＩ、空白行、又はコメント文字（「＃」など）による開始とすることができる。ＵＲＩは、再生される媒体ファイルを識別する。空白行は無視することができる。
コメント文字で始まる行は、コメント又はタグのいずれかとすることができる。タグは、＃ＥＸＴで開始することができ、コメント行は、＃で開始することができる。コメント行は、通常、サーバ及びクライアントによって無視される。一実施形態において、プレイリストファイルは、ＵＴＦ−８フォーマットで符号化される。ＵＴＦ−８（８ビット−ユニコード・トランスフォーメーション・フォーマット）は、可変長文字符号化フォーマットである。代替の実施形態において、他の文字符号化フォーマットを使用することができる。
以下の例では、２つのタグ：ＥＸＴＭ３Ｕ及びＥＸＴＩＮＦを含む拡張Ｍ３Ｕフォーマットが利用される。拡張Ｍ３Ｕファイルは、「＃ＥＸＴＭ３Ｕ」を含む第１の行によって基本Ｍ３Ｕファイルとは区別することができる。
ＥＸＴＩＮＦは、タグに続くＵＲＩによって識別された媒体ファイルを説明する記録マーカである。一実施形態において、各媒体ファイルＵＲＩは、ＥＸＴＩＮＦタグによって先行され、例えば、＃ＥＸＴＩＮＦ：＜持続時間＞、＜タイトル＞である。従って、「持続時間」は、媒体ファイルの持続時間を指定し、「タイトル」はターゲット媒体ファイルのタイトルである。
一実施形態において、媒体ファイルの転送及び再生を管理するために以下のタグを使用することができる：
ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
ＥＸＴ−Ｘ−ＫＥＹ
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ。
これらのタグの各々は、以下に更に詳しく説明する。特定のフォーマット及び属性が各新しいタグに関して説明するが、代替の実施形態は、異なる属性、名称、フォーマット等によってサポートすることができる。
ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグは、一実施形態において、提示に追加される次の媒体ファイルの大体の持続時間を示すことができる。再生ファイル及びフォーマットに含むことができるのは、＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：＜秒＞である。従って、「秒」は、媒体ファイルの持続時間を示す。一実施形態において、実際の持続時間は、タグによって示されたターゲット持続時間とは僅かに異なる場合がある。一実施形態において、セグメントを示す全てのＵＲＩをセグメントの大体の持続時間に関連付けることになり、例えば、セグメントに対するＵＲＩは、そのセグメントの大体の持続時間を示すタグを前に付けることができる。別の実施形態において、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグは、最大媒体ファイル持続時間を指定することができ、プレイリストファイルの各媒体ファイルのＥＸＴＩＮＦ持続時間は、ターゲット持続時間未満か又はこれに等しくすべきであり、このタグ（最大媒体ファイル持続時間を指定する）は、プレイリストファイルにおいて一度だけ指定することができ、これは、プレイリストファイルの全ての媒体ファイルに適用され、そのフォーマットは、＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：＜ｓ＞とすることができ、ここで「ｓ」は、ターゲット持続時間を秒で示す整数である。
プレイリストファイルの各媒体ファイルＵＲＩは、固有のシーケンス番号を有することができる。あるとすれば、ＵＲＩのシーケンス番号は、それに先行したＵＲＩのシーケンス番号に等しく、一実施形態では１を加えた番号である。ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグは、プレイリストファイルに現れる最初のＵＲＩのシーケンス番号を示すことができ、フォーマットは、＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：＜番号＞とすることができ、従って、「番号」は、ＵＲＩのシーケンス番号である。プレイリストファイルが＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合、プレイリストにおける第１のＵＲＩのシーケンス番号は１と考えることができる。媒体ファイルのシーケンス番号は、一実施形態ではそのＵＲＩに現れる必要はなく、一実施形態において、プレイリストは、単に１つのＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含むことができる。一実施形態において、シーケンス付番は、不連続にすることができ、例えば、１、５、７、１７のような不連続シーケンス付番は、シーケンスにおける次の番号を予想することを困難にすることができ、これは、コンテンツの違法コピーを防ぐのを助けることができる。コンテンツの保護を助けるための別の選択肢は、いずれかの所定の時間にプレイリストの一部分だけを明かすことである。
一部の媒体ファイルを暗号化することができる。ＥＸＴ−Ｘ−ＫＥＹタグは、これに続く媒体ファイルを解読するために使用することができる情報を提供し、フォーマットは、＃ＥＸＴ−Ｘ−ＫＥＹ：ＭＥＴＨＯＤ≦ｍｅｔｈｏｄ＞［，ＵＲＩ＝“＜ＵＲＩ＞”］［，ＩＶ≦ＩＶ＞］とすることができる。ＭＥＴＨＯＤパラメータは、暗号化方法を指定し、ＵＲＩパラメータは、あるとすれば、キーを取得する方法を指定し、ＩＶ（初期化ベクトル）は、あるとすれば、暗号化方法（キーなどによる）で使用された初期化ベクトルを指定する。
ＮＯＮＥの暗号化方法は、暗号化を指示せず、ＮＯＮＥが次に示された場合、一実施形態において、ＵＲＩ及びＩＶパラメータを存在させるべきではない。様々な暗号化方法を使用することができ、例えば、ＡＥＳ−１２８は、１２８ビットキー及びＰＫＣＳ７パディングによる高度暗号化規格暗号化を使用する暗号化を示す［ＲＦＣ３８５２を参照されたい］。新しいＥＸＴ−Ｘ−ＫＥＹタグは、いずれの前のＥＸＴ−Ｘ−ＫＥＹタグにも取って替わる。
ＵＲＩパラメータを有するＥＸＴ−Ｘ−ＫＥＹタグはキーファイルを識別する。キーファイルは、プレイリストファイルに列挙された次の媒体ファイルを解読するのに使用される暗号キーを含むことができる。例えば、ＡＥＳ−１２８暗号化方法は１６オクテットキーを使用する。キーファイルのフォーマットは、バイナリフォーマットの１６オクテットのパケット化アレイとすることができる。
ＡＥＳ−１２８の使用は、暗号化及び解読する時に同じ１６オクテット初期化ベクトル（ＩＶ）が供給されることを通常は必要とする。ＩＶの変更は、暗号の強度を高めるために使用することができる。ＡＥＳ−１２８暗号化を使用する時に、媒体ファイルのシーケンス番号は、媒体ファイルを暗号化又は解読する時にＩＶとして使用することができる。
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグは、次の媒体ファイルの開始を絶対及び／又は時間に関連付けることができ、時間帯を含む又は示すことができる。一実施形態において、日付／時間表示は、ＩＳＯ／ＩＥＣ８６０１：２００４である。このタグにおける日付及び時間の値は、適切な壁時計時間への媒体の時系列の情報マッピングを提供することができ、表示又は他の目的のために日付及び時間に基づく再生のためのコンテンツを求める基礎として使用することができる。一実施形態において、サーバがこのマッピングを提供する場合、サーバは、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグをプレイリストファイルの全てのＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグの後に置くべきである。タグフォーマットは、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ：＜ＹＹＹＹ−ＭＭ−ＤＤＴｈｈ：ｍｍ：ｓｓＺ＞とすることができる。
クライアントが後の再生のためにダウンロードされた媒体ファイルをキャッシュに入れることができるか否かを示すためにＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを使用することができる。このタグは、一実施形態ではプレイリストファイルのあらゆる場所に出現することができるが、一実施形態において、プレイリストファイルに一度だけ出現すべきである。タグフォーマットは、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ：＜ＹＥＳ｜ＮＯ＞とすることができる。
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグは、一実施形態において、媒体ファイルがこれ以上プレイリストファイルに追加されないことを示す。タグフォーマットは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴとすることができる。一実施形態において、プレイリストが最終セグメント又は媒体ファイルを含む場合、プレイリストはＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを有することになる。このタグは、一実施形態ではプレイリストファイルのあらゆる場所に出現することができ、一実施形態において、プレイリストファイルに一度だけ発生させることができる。
プレイリストファイルの次のＵＲＬが別のプレイリストファイルを識別することを示すためにＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを使用することができる。タグフォーマットは、一実施形態では、ＥＸＴ−Ｘ−ＳＴＲＥＡＭ −ＩＮＦ：［属性＝値］［，属性＝値］*＜ＵＲＬ＞とすることができ、ここで、以下の属性を使用することができる。同じタイプの属性は、このタグの一実施形態において、同じタグに一度より多く出現すべきではない。属性ＢＡＮＤＷＩＤＴＨ≦ｎ＞は、ビット／秒の数として表されるストリームビットレートの大体の上限境界である。一実施形態において、属性ＢＡＮＤＷＩＤＴＨは、プレイリストに出現又は出現するであろうコンテナオーバヘッドを含むように計算された各媒体ファイルの全体的なビットレートの上限境界とすることができる。属性ＰＲＯＧＲＡＭ−ＩＤ≦ｉ＞は、プレイリストファイルの範囲の特定の提示を固有に識別する数字である。プレイリストファイルは、同じＰＲＯＧＲＡＭ−ＩＤを有する複数のＥＸＴ−ＳＴＲＥＡＭ−ＩＮＦ ＵＲＩを含むことができ、同じ提示の変形ストリームを説明し、これらの変形プレイリストは、付加的なＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含むことができる。変形ストリーム及び変形プレイリストを本発明の開示で更に説明する（例えば、図９Ａ−９Ｄを参照されたい）。属性ＣＯＤＥＣＳ＝“［フォーマット］［，フォーマット］*”は、プレイリストファイルの媒体ファイルに存在する媒体サンプルタイプを指定するために使用することができ、ここで各フォーマットは、媒体サンプルタイプを指定し、一実施形態において、有効フォーマット識別子をＲＦＣ４２８１によって定義されたＩＳＯファイルフォーマットネームスペースにおける識別子とすることができる。属性ＲＥＳＯＬＵＴＩＯＮ≦Ｎ＞ｘ＜Ｍ＞は、ストリーム内のビデオの解像度を指定することができ、ここでＮは、ストリーム内のビデオの大体の符号化水平解像度であり、ピクセルの数として表現することができ、Ｍは、大体の符号化垂直解像度である。
ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグは、それに続く媒体ファイルとそれに先行する媒体ファイルの間の符号化不連続性を示す。変更することができる特性のセットは、
・ファイルフォーマット
・トラックの数及びタイプ
・符号化パラメータ
・符号化シーケンス
・タイムスタンプシーケンス
である。そのフォーマットは、＃ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹである。
ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグは、プレイリストファイルの互換性バージョンを示す。プレイリストファイル、その関連媒体、及びそのサーバは、一実施形態において、タグ値によって示されるプロトコルバージョンを説明するこの文書の最新バージョンの全ての条項を遵守すべきである。そのフォーマットは、＃ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ：＜ｎ＞であり、従って、「ｎ」はプロトコルバージョンを示す整数である。
プレイリストファイルは、一実施形態において、１つよりも多いＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグを含むことはできない。ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグを含まないプレイリストファイルは、一実施形態において、このプロトコルのバージョン１を遵守すべきである。プレイリストファイルがこのタグを有する場合、その値は、一実施形態において、サーバ、プレイリストファイル及び関連の媒体ファイルが全て遵守する最低プロトコルバージョンとすべきである。
上述のタグ及び属性は、オリジナル媒体コンテンツを表す媒体ファイルを編成、送信、及び処理するためにサーバデバイスによって使用することができる。クライアントデバイスは、この情報を使用して、リアルタイム又はリアルタイムに近いストリーミング体験（例えば、音楽又はスポーツイベントのようなライブブロードキャストの視聴）をクライアントデバイスのユーザに提供するために、ある方式で媒体ファイルをリアセンブル及び提示する。
プレイリストファイルの各媒体ファイルＵＲＩは、オリジナル提示のセグメント（すなわち、オリジナル媒体コンテンツ）である媒体ファイルを識別する。一実施形態において、各媒体ファイルは、ＭＰＥＧ２トランスポートストリーム、ＭＰＥＧ２プログラムストリーム、又はＭＰＥＧ２オーディオエレメンタリストリームとしてフォーマット設定される。フォーマットは、ＣＯＤＥＣを指定することによって指定することができ、プレイリストは、ＣＯＤＥＣを指定することによってフォーマットを指定することができる。一実施形態において、提示における全ての媒体ファイルは、同じフォーマットを有するが、しかし、他の実施形態では複数のフォーマットをサポートすることができる。トランスポートストリームファイルは、一実施形態において、単一のＭＰＥＧ２プログラムを含むべきであり、各ファイルの最初にプログラムアソシエーションテーブル及びプログラムマップテーブルを存在させるべきである。ビデオを含むファイルは、ビデオ復号器を完全に初期化するために少なくとも１つのキーフレーム及び十分な情報を有するべきである。プレイリストの媒体ファイルは、プレイリストファイルに現れる最初の媒体ファイルでない限り又はＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグによって先行される場合、前のシーケンス番号を有する媒体ファイルの最後での符号化ストリームの連続でなくてはならない。クライアントは、妥当な部分集合を選択することによって特定のタイプの複数のトラック（例えば、オーディオ又はビデオ）を処理する準備をすべきである。クライアントは、一実施形態において、認識していないトランスポートストリームの内側のプライベートストリームを無視すべきである。媒体ファイルの内側のストリーム内及び複数の媒体ファイルにわたる対応するストリーム間のサンプルに対する符号化パラメータは一貫したままにすべきである。しかし、クライアントは、例えば、解像度変更に対処するためにビデオコンテンツをスケーリングすることにより、遭遇する符号化変更を処理すべきである。
図２Ａは、１つ又はそれよりも多くのサーバデバイスが非ストリーミングプロトコルを使用して媒体コンテンツをサポートするための技術の一実施形態の流れ図である。図２Ａの例は、ＨＴＴＰの観点から提供されるが、他の非ストリーミングプロトコルも類似の方式で利用することができる。図２Ａの例は、特定のタスクを実行する単一のサーバの観点から提供される。しかし、サーバのいずれの数も利用することができる。例えば、媒体ファイルをクライアントデバイスに提供するサーバは、コンテンツを複数の媒体ファイルにセグメント化するサーバとは異なるデバイスとすることができる。
サーバデバイスは、作動２００で提供されるコンテンツを受信する。コンテンツは、ライブオーディオ及び／又はビデオ（例えば、スポーツイベント、ライブニュース、ウェブカメラフィード）を表すことができる。コンテンツはまた、事前に記録されたコンテンツ（例えば、記録されたコンサート、トレーニングセミナーなど）を表すことができる。コンテンツは、当業技術で公知のいずれかのフォーマット及びプロトコルに従ってストリーミングか否かに関わらずサーバによって受信することができる。一実施形態において、コンテンツは、ＭＰＥＧ２ストリームの形式でサーバによって受信されるが、しかし、他のフォーマットもサポートすることができる。
次に、サーバは、作動２１０でコンテンツの少なくとも一部分を一時的に格納することができる。コンテンツ又はコンテンツの少なくとも一部分は、例えば、格納デバイス（格納エリアネットワークにおけるハードディスクなど）に又はメモリに一時的に格納することができる。代替的に、格納デバイス又はメモリにそこからコンテンツを転送することができるストレージ媒体（例えば、コンパクトディスク、フラッシュドライブ）を通じてコンテンツを受信することができる。一実施形態において、サーバは、必要に応じてコンテンツを１つ又はそれよりも多くのストリーム（ＭＰＥＧ２など）に変換する符号化器を有する。この変換は、受信したコンテンツを永久に格納することなく実行することができ、一部の実施形態において、格納作動２１０を省くことができ、又は他の実施形態では長期格納（アーカイブ格納デバイスなど）とすることができる。
提供されるコンテンツは、作動２２０で複数の媒体ファイルにセグメント化される。一実施形態において、サーバが、ストリームを標準的なウェブサーバを使用して配信することができる個別の異なる媒体ファイル（すなわち、セグメント）に変換する。一実施形態において、サーバは、個々の媒体ファイルの効率的な復号をサポートするポイントで（例えば、ＰＥＳパケット境界及びｉフレーム境界のようなパケット及びキーフレーム境界で）媒体ストリームをセグメント化する。媒体ファイルは、実質的に等しい持続時間を有するオリジナルストリームの一部分とすることができる。サーバはまた、各媒体ファイルに対するＵＲＩを作成する。これらのＵＲＩにより、クライアントデバイスは媒体ファイルにアクセス可能である。
セグメントが、全体のファイルを固有に配信するＨＴＴＰサーバを使用してサービスを受けるので、サーバは、クライアントにサービスを受ける前に利用可能な完全セグメント化媒体ファイルを有するべきである。従って、クライアントは、少なくとも１つの媒体ファイル長毎にブロードキャストを（時間的に）遅らせることができる。一実施形態において、媒体ファイルサイズは、ラグ時間と多くのファイルを有するこの間の均衡に基づいている。
一実施形態において、２つのセッションタイプ（ライブセッション及びイベントセッション）がサポートされる。ライブセッションでは、ストリームの固定サイズ部分だけが保存される。一実施形態において、古くなったコンテンツ媒体ファイルが、プログラムプレイリストファイルから取り除かれ、サーバから取り除くことができる。セッションの第２のタイプは、イベントセッションであり、クライアントは、ブロードキャストのいずれのポイントにも合わせることができる（例えば、最初から開始し、中間ポイントから開始する）。セッションのこのタイプは、例えば、再ブロードキャストのために使用することができる。
媒体ファイルは、作動２３０でサーバメモリに格納される。媒体ファイルは、作動２３０におけるファイルの格納の前に、暗号化のようなセキュリティ機能によって保護することができる。媒体ファイルは、サーバデバイスのウェブサーバアプリケーションによってサポートされる（又は送信を実行する別のデバイスによってサポートされる）ネットワークプロトコル（例えば、ＨＴＴＰ又はＨＴＴＰＳ）を使用していつでも送信することができるファイルとして格納される。
オリジナルコンテンツを再生するために媒体ファイルをアセンブルすべきである順序を示すように作動２４０で１つ又はそれよりも多くのプレイリストファイルが作成される。プレイリストファイルは、クライアントデバイスでのストリーミング体験を提供するために媒体ファイルにアクセス及びリアセンブルするためのクライアントデバイスに対する情報を提供するために、拡張Ｍ３Ｕタグ及び本明細書に説明するタグを利用することができる。各媒体ファイルに対するＵＲＩは、媒体ファイルが再生される順序でプレイリストファイルに含まれる。サーバは、クライアントデバイスがプレイリストファイルへのアクセスを提供するために、プレイリストファイルに対する１つ又はそれよりも多くのＵＲＩを作成することができる。
プレイリストファイルを作動２５０でサーバに格納することができる。媒体ファイル及びプレイリストファイルの作成及び格納は、図２Ａの特定の順序で提示され、異なる順序を使用することもできる。例えば、媒体ファイルが作成又は格納される前にプレイリストファイルを作成することができる。別の一例として、プレイリストファイル及び媒体ファイルをいずれかが格納される前に作成することができる。
媒体ファイルが暗号化される場合、プレイリストファイルは、許可されたクライアントデバイスが媒体ファイルを解読するための暗号化キーを含むキーファイルを取得することを可能にするＵＲＩを定義することができる。暗号化キーは、セキュア接続（ＨＴＴＰＳなど）を使用して送信することができる。別の一例として、ＨＴＴＰＳを使用してプレイリストファイルを送信することができる。更に別の一例として、媒体ファイルを予想できない順序で構成することができ、それによってクライアントは、プレイリストファイルなしにはストリームを再生することができない。
暗号化方法がＡＥＳ−１２８である場合、ＡＥＳ−１２８ＣＢＣ暗号化は、例えば、個々の媒体ファイルに適用することができる。一実施形態において、全ファイルが暗号化される。暗号ブロック連鎖は、通常、一実施形態では媒体ファイルにわたって適用されない。媒体ファイルのシーケンス番号はＩＶとして使用することができ、又はＩＶを上述したようにＥＸＴ−Ｘ−ＫＥＹタグのＩＶ属性の値とすることができる。一実施形態において、サーバが、キーＵＲＩを備えたＥＸＴ−Ｘ−ＫＥＹタグをプレイリストファイルの最後に追加する。次に、サーバは、暗号化構成における変更が行われるまで、そのキーによって全ての次の媒体ファイルを暗号化する。
新しい暗号化キーに切り換えるために、サーバは、提示で使用された全ての前のキーＵＲＩとは個別の新しいＵＲＩを通じて利用可能な新しいキーを作ることができる。サーバはまた、新しいキーＵＲＩを備えたＥＸＴ−Ｘ−ＫＥＹタグをプレイリストファイルの最後に追加し、新しいキーで全ての次の媒体ファイルを暗号化する。
暗号化を終了するために、サーバは、プレイリストファイルの最後に暗号化方法ＮＯＮＥを備えたＥＸＴ−Ｘ−ＫＥＹタグを追加することができる。タグ（方法としての「ＮＯＮＥ」を備えた）は、一実施形態ではＵＲＩパラメータを含まない。全ての次の媒体ファイルは、暗号化構成における変更が上述したように行われるまで暗号化されない。サーバは、プレイリストファイルがそのキーによって暗号化された媒体ファイルへのＵＲＩを含む場合、プレイリストファイルからＥＸＴ−Ｘ−ＫＥＹタグを取り除かない。サーバは、図３Ａに関して詳しく説明するように、作動２７０でクライアント要求に応答してプレイリストファイル及び媒体ファイルをネットワークを通じて送信することができる。
一実施形態において、サーバは、プレイリストファイルに対するクライアントデバイスからの要求の受信に応答してクライアントデバイスにプレイリストファイルを送信する。クライアントデバイスは、クライアントデバイスに提供されたＵＲＩを使用してプレイリストファイルにアクセス／要求することができる。ＵＲＩは、サーバ上のプレイリストファイルのロケーションを示す。それに応じて、サーバは、プレイリストファイルをクライアントデバイスに提供することができる。クライアントデバイスは、複数の媒体ファイルにアクセスするために、プレイリストファイルのタグ及びＵＲＩ（又は他の識別子）を利用することができる。
一実施形態において、サーバは、プレイリストファイルに最も新しく追加された媒体ファイルに媒体ファイルの利用可能度を制限することができる。これを実行するために、各プレイリストファイルは、単に１つのＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含むことができ、その値は、プレイリストファイルから取り除かれた全ての媒体ファイルＵＲＩに対して１ずつ増分することができる。媒体ファイルＵＲＩは、これらが追加された順序でプレイリストファイルから取り除くことができる。一実施形態において、サーバがプレイリストファイルから媒体ファイルＵＲＩを取り除いた時に、媒体ファイルは、媒体ファイルの持続時間に媒体ファイルが出現した最長プレイリストファイルの持続時間を加えたものに等しい時間、クライアントに利用可能のままになる。
プレイリストファイルの持続時間は、そのプレイリストファイル内の媒体ファイルの持続時間の和である。他の持続時間を使用することもできる。一実施形態において、サーバは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない限り、全ての時間にプレイリストに少なくとも３つの主提示媒体ファイルを維持することができる。
図２Ｂは、１つ又はそれよりも多くのサーバデバイスが動的に更新されたプレイリストを１つ又はそれよりも多くのクライアントデバイスに提供するための技術の一実施形態の流れ図である。プレイリストは、累積モード又は本明細書に説明するローリングモードのいずれかを使用して更新することができる。図２Ｂの例は、ＨＴＴＰの観点から提供されるが、しかし、他の非ストリーミングプロトコル（ＨＴＴＰＳなど）を類似の方式で利用することもできる。図２Ｂの例は、特定のタスクを実行するサーバの観点から提供される。しかし、サーバのいずれの数も利用することができる。例えば、媒体ファイルをクライアントデバイスに提供するサーバは、コンテンツを複数の媒体ファイルにセグメント化するサーバとは異なるデバイスとすることができる。
サーバデバイスは、作動２０５で提供されるコンテンツを受信する。次に、サーバは、作動２１５でコンテンツの少なくとも一部分を一時的に格納することができる。作動２１５は、図２Ａの作動２１０に類似とすることができる。提供されるコンテンツは、作動２２５で複数の媒体ファイルにセグメント化される。媒体ファイルは、作動２３５でサーバメモリに格納することができる。媒体ファイルは、作動２３５でファイルを格納する前に暗号化のようなセキュリティ機能によって保護することができる。
媒体ファイルを作動２４５でオリジナルコンテンツを再生するためにアセンブルすべきである順序を示すために、１つ又はそれよりも多くのプレイリストファイルが生成される。プレイリストファイルは、作動２５５でサーバに格納することができる。媒体ファイル及びプレイリストファイルの作成及び格納は図２Ｂで特定の順序で提示されているが、異なる順序を使用することもできる。
サーバ（又は別のサーバ）は、図３Ａ−３Ｂに関して更に詳しく説明するように、作動２７５でクライアント要求に応答してプレイリストファイル及び媒体ファイルをネットワークを通じて送信することができる。
プレイリストファイルは、様々な理由のためにサーバによって更新することができる。サーバは、作動２８５でクライアントデバイスに提供される付加的なデータを受信することができる。付加的なデータは、作動２５５でプレイリストファイルが格納された後に受信することができる。付加的なデータは、例えば、ライブ提示の付加的な部分、又は既存の提示のための付加的な情報とすることができる。付加的なデータは、広告又は統計値（例えば、スポーツイベントに関するスコア又はデータ）を含むことができる。付加的なデータは、提示の上に(半透明にして)重ねることができ、又はサイドバーユーザインタフェースで提示することができる。付加的なデータは、オリジナルの受信データと同じ方式でセグメント化することができる。付加的なデータが広告を構成する場合、又は他のコンテンツが、プレイリストによって表されたプログラムに挿入される場合、付加的なデータを作動２１５で（少なくとも一時的に）格納し、作動２２５でセグメント化して作動２３５で格納することができ、セグメント化された付加的なデータの格納の前に、付加的なデータのセグメントを暗号化することができる。次に、作動２４５で、プログラム及び付加的なデータを含む更新されたプレイリストが生成される。プレイリストは、付加的なデータに基づいて更新され作動２５５で再度格納される。プレイリストファイルの変更は、クライアントデバイスの観点からごく小さく実行するべきである。更新されたプレイリストは、一実施形態において、前のプレイリストに置き換わる。以下に更に詳しく説明するように、クライアントデバイスはプレイリストを複数回要求することができる。これらの要求により、クライアントデバイスは、最新のプレイリストを利用することができるようなる。一実施形態において、付加的なデータをメタデータとすることができ、この場合、プレイリストは更新する必要はないが、セグメントは、メタデータを含むように更新することができる。例えば、メタデータは、セグメントのタイムスタンプに適合することができるタイムスタンプを含むことができ、メタデータは、適合するタイムスタンプを有するセグメントに追加することができる。
更新されたプレイリストは、媒体ファイルの除去をもたらすことができる。一実施形態において、サーバは、媒体ファイルに対するＵＲＩをこれらがプレイリストに追加された順序でプレイリストから取り除くべきである。一実施形態において、サーバが全提示を取り除く場合、サーバは、プレイリストファイルをクライアントデバイスに利用できないようにする。一実施形態において、サーバは、現在のクライアントデバイスが提示へのアクセスを終了することができるように、取り除かれる媒体ファイルを含む最長プレイリストファイルの持続時間にわたって媒体ファイル及びプレイリストファイルを維持する。従って、プレイリストファイルのあらゆる媒体ファイルＵＲＩは、プレイリストファイルによって示された媒体ファイルの大体の累積持続時間を示すために、ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを前に付けることができる。代替の実施形態において、媒体ファイル及びプレイリストファイルを即座に取り除くことができる。
クライアントデバイスからのプレイリストに対する次の要求は、作動２７５で更新されたプレイリストをサーバに提供させる。一実施形態において、プレイリストは、定期的に、例えば、ターゲット持続時間に関連付けられた期間で更新される。プレイリストファイルの定期的な更新により、サーバは、動的に変更された提示のためにサーバへのアクセスを提供することができるようなる。
図２Ｃは、代替ストリームの使用の１つの形式である１つ又はそれよりも多くのサーバデバイスが複数ビットレートを使用してクライアントデバイスに媒体コンテンツを提供するための技術の一実施形態の流れ図である。図２Ｃの例は、ＨＴＴＰの観点から提供されるが、しかし、他の非ストリーミングプロトコルを類似の方式で利用することもできる。図２Ｃの例は、特定のタスクを実行するサーバの観点から提供される。しかし、サーバのいずれの数も利用することができる。例えば、媒体ファイルをクライアントデバイスに提供するサーバは、コンテンツを複数の媒体ファイルにセグメント化するサーバとは異なるデバイスとすることができる。
一実施形態において、サーバは、同じ提示の異なる符号化を提供するために、複数のプレイリストファイル、又は単一のプレイリストファイルにおける複数の媒体ファイルリストを備えた単一のプレイリストファイルを供給することができる。異なる符号化が提供される場合、プレイリストファイルは、クライアントデバイスが動的に符号化を切り換えられるようにするために異なるビットレートを提供する各変形ストリームを含むことができる（これは、図９Ａ−９Ｄに関して更に説明する）。変形ストリームを有するプレイリストファイルは、各変形ストリームに対するＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含むことができる。同じ提示のための各ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、同じＰＲＯＧＲＡＭ−ＩＤ属性値を有することができる。各提示のためのＰＲＯＧＲＡＭ−ＩＤ値は、変形ストリーム内で固有である。
一実施形態において、サーバが、変形ストリームを作成する時に以下の制約を満足させる。各変形ストリームは、主提示の一部ではない任意的なコンテンツを含む同じコンテンツを含むことができる。サーバは、ストリームの最小ターゲット持続時間の精度内で全ての変形ストリームに対してコンテンツの同じ時間を利用可能にすることができる。変形ストリームの媒体ファイルは、一実施形態において、全ての変形ストリームにおける対応するコンテンツに対して適合するサンプルタイムスタンプを有するＭＰＥＧ２トランスポートストリーム又はＭＰＥＧ２プログラムストリームのいずれかである。全ての変形ストリームは、一実施形態において同じオーディオ符号化を含むべきである。それによってクライアントデバイスは、コンテンツを失うことなく変形ストリーム間で切り換えることができる。
図２Ｃを参照すると、サーバデバイスは、作動２０２で提供されるコンテンツを受信する。次に、サーバは。作動２１２で少なくとも一時的にコンテンツを格納することができる。提供されるコンテンツは、作動２２２で複数の媒体ファイルにセグメント化される。各媒体ファイルは、選択されたビットレート（又は他の符号化パラメータの選択された値）に対して符号化され、作動２３２でサーバに格納される。例えば、媒体ファイルは、高−、中−、及び低−帯域幅接続を望ましいものとすることができる。媒体ファイルは、格納の前に暗号化することができる。接続の様々なタイプをターゲットとした媒体ファイルの符号化は、ターゲット帯域幅レベルでストリーミング体験を提供するように選択することができる。
一実施形態において、変形プレイリストは、様々な符号化レベルを示す本明細書に説明するタグによって作動２４２で生成される。タグは、例えば、対応する媒体プレイリストファイルへのＵＲＩを備えた各符号化レベルに対するＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含むことができる。
この変形プレイリストは、様々な符号化レベルのための媒体プレイリストファイルへのＵＲＩを含むことができる。従って、クライアントデバイスは、符号化レベルを示す変形プレイリストで提供される代替からターゲットビットレートを選択し、対応するプレイリストファイルを検索することができる。一実施形態において、クライアントデバイスは、再生中にビットレートを変更することができる（例えば、図９Ａ−９Ｄに関して説明するように）。様々な符号化レベルを示す変形プレイリストは、作動２５２でサーバに格納される。作動２４２で変形プレイリストで参照されたプレイリストの各々を生成し、次に、作動２５２で格納することができる。
クライアントデバイスからの要求に応答して、サーバは、作動２７２で様々な符号化レベルを示す変形プレイリストを送信することができる。サーバは、作動２８２で選択されたビットレートに対応する変形プレイリストで指定された媒体プレイリストの１つに対する要求を受信することができる。要求に応答して、サーバは、作動２９２でクライアントデバイスからの要求に対応する媒体プレイリストファイルを送信する。次に、クライアントデバイスは、サーバから媒体ファイルを要求するために媒体プレイリストを使用することができる。サーバは、作動２９７で要求に応答して媒体ファイルをクライアントデバイスに提供する。
図３Ａは、クライアントデバイスが非ストリーミングプロトコルを使用してコンテンツのストリーミングをサポートするための技術の一実施形態の流れ図である。図３Ａの例は、ＨＴＴＰの観点から提供されるが、しかし、他の非ストリーミングプロトコルも類似の方式で利用することができる。図３Ａ−３Ｂに示す方法は、１つのクライアントデバイスによって又はいくつかの個別のクライアントデバイスによって実行することができる。例えば、これらの方法のいずれか１つの場合、単一のクライアントデバイスが、作動の全て（例えば、プレイリストファイルの要求、プレイリストファイルのＵＲＩを使用した媒体ファイルの要求、提示／出力を生成及び提供するための媒体ファイルのアセンブル）を実行することができ、又はいくつかの個別のクライアントデバイスが、作動の全部ではないが一部を実行することができる（例えば、第１のクライアントデバイスは、プレイリストファイルを要求し、プレイリストファイルのＵＲＩを使用して媒体ファイルを要求することができ、提示／出力を生成及び提供するために媒体ファイルを処理することができる第２のクライアントデバイスによって使用するためにこれらの媒体ファイルを格納することができる）。
クライアントデバイスは、作動３００でサーバからプレイリストファイルを要求することができる。一実施形態において、要求は、ＨＴＴＰ準拠プロトコルに従って行われる。要求は、サーバに格納された初期プレイリストファイルへのＵＲＩを利用する。代替の実施形態において、他の非ストリーミングプロトコルもサポートすることができる。要求に応答して、サーバは、対応するプレイリストファイルをクライアントにネットワークを通じて送信する。上述したように、ネットワークは有線又は無線とすることができ、有線又は無線ネットワークのいずれの組合せにができる。更に、ネットワークは、データネットワーク（ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１６など）、又はセルラー電話ネットワーク（３Ｇなど）とすることができる。
クライアントデバイスは、作動３１０でプレイリストファイルを受信することができる。プレイリストファイルは、作動３２０でクライアントデバイスのメモリに格納することができる。メモリは、例えば、ハードディスク、フラッシュメモリ、ランダムアクセスメモリとすることができる。一実施形態において、プレイリストファイルがプレイリストＵＲＩからロード又はリロードされる度に、クライアントは、プレイリストファイルが＃ＥＸＴＭ３Ｕタグで開始していると判断するために検査し、タグがない場合は継続しない。上述したように、プレイリストファイルは、１つ又はそれよりも多くのタグ、並びに媒体ファイルへの１つ又はそれよりも多くのＵＲＩを含む。
クライアントデバイスは、作動３３０でプレイリストファイルのＵＲＩによって示された媒体ファイルを要求することによってオリジナルコンテンツをリアセンブルするためにプレイリストファイルを使用するアセンブラエージェントを含むことができる。一実施形態において、アセンブラエージェントは、標準的なウェブブラウザアプリケーションの一部である接続モジュールである。別の実施形態において、アセンブラエージェントは、媒体ファイルを受信しプレイリストファイルを使用して媒体ファイルをアセンブルするためにウェブブラウザと対話する独立型アプリケーションとすることができる。更に別の例として、アセンブラエージェントは、クライアントデバイスに実施される専用ハードウエア又はファームウエア構成要素とすることができる。
アセンブラは、プレイリストファイルからの媒体ファイルをＵＲＩによって示されたサーバからダウンロードさせる。プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含む場合、プレイリストファイルによって示されたいずれの媒体ファイルも最初に再生することができる。ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在しない場合、最後及び最後から２番目の媒体ファイルを除くいずれの媒体ファイルも最初に再生することができる。再生する最初の媒体ファイルが選択された状態で、プレイリストファイルにおける次の媒体ファイルが、一実施形態ではこれらがプレイリストファイルに現れる順序でロードされる（そうでなければコンテンツがばらばらに提示されている）。一実施形態において、クライアントデバイスは、媒体ファイルが要求される前に媒体ファイルをロードしようとし（更にこれらをバッファに格納し）、中断されない再生を提供しネットワーク待ち時間及び処理量における一時的な変動を補償する。
ダウンロードされた媒体ファイルは、作動３４０でクライアントデバイスのメモリに格納することができる。コンテンツを格納することができるメモリは、クライアントデバイスのいずれかのタイプのメモリ、例えば、ランダムアクセスメモリ、ハードディスク、又はビデオバッファとすることができる。格納デバイスは、再生を可能にするために一時的とすることができ、又は永久とすることができる。プレイリストファイルがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含み、その値がＮＯである場合、クライアントは、ダウンロードされた媒体ファイルが再生された後にダウンロードされた媒体ファイルを格納しない。プレイリストがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含み、その値がＹＥＳである場合、クライアントデバイスは、後の再生のために媒体ファイルを永久に格納することができる。クライアントデバイスは、プログラム開始時間をユーザに表示するためにＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値を使用することができる。一実施形態において、クライアントは、より良いユーザ体験を提供するために、ネットワークジッタの影響を受けないように複数の媒体ファイルをバッファに入れることができる。
一実施形態において、解読方法がＡＥＳ−１２８である場合、ＡＥＳ−１２８ＣＢＣ解読が個々の媒体ファイルに適用される。全ファイルが解読される。一実施形態において、暗号ブロック連鎖方式は媒体ファイルにわたって適用されない。上述したように、媒体ファイルのシーケンス番号を初期化ベクトルとして使用することができる。
メモリから、作動３５０でクライアントデバイスからのコンテンツを出力することができる。出力又は提示は、例えば、組み込み型スピーカ又はヘッドフォンを通じたオーディオ出力とすることができる。出力は、スクリーンを通じて出力される又はクライアントデバイスから投影されるビデオを含むことができる。当業技術で公知の出力のいずれのタイプも利用することができる。作動３５１で、クライアントデバイスは、再生又はそうでなければ提示されていなかった格納された現在のプレイリストにまだ媒体ファイルが存在するか否かを判断する。このような媒体ファイルが存在する場合（及びこれらが要求されていなかった場合）、次に、処理は作動３３０に戻り、１つ又はそれよりも多くの媒体ファイルが要求され処理が繰り返される。このような媒体ファイルが存在しない場合（すなわち、現在のプレイリストの全ての媒体ファイルが再生されている）、次に、処理は作動３５２に進み、プレイリストファイルが終了タグを含むか否かを判断する。
プレイリストが作動３５２で終了タグ（ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴなど）を含む場合、プレイリストファイルによって示された媒体ファイルが再生された時に再生が終わる。終了タグがプレイリストにない場合、クライアントデバイスは、サーバから再度プレイリストを要求し、作動３００に戻り、プログラムに対する更に別の又は更新されたプレイリストを取得する。
図２Ｂに関して更に詳しく説明するように、サーバは、補足のコンテンツ（例えば、ライブブロードキャストにおける付加的な媒体コンテンツに対応する付加的な媒体ファイル識別子）又は付加的なコンテンツ（例えば、ストリームの更に下流のコンテンツ）を導入するためにプレイリストファイルを更新することができる。補足コンテンツ又は付加的なコンテンツにアクセスするために、クライアントは、サーバから更新されたプレイリストをリロードすることができる。これは、プレイリストファイルに関連付けられる媒体コンテンツの再生中でも、それによってプレイリストファイルを動的に更新することができる機構を提供することができる。クライアントは、トリガの数に基づいてプレイリストファイルのリロードを要求することができる。終了タグの欠如は、１つのこのようなトリガである。
一実施形態において、プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない限り、クライアントデバイスは定期的にプレイリストファイルをリロードする。クライアントデバイスが初めてプレイリストファイルをロードした又は最後にロードされてからプレイリストファイルが変更されたことを見出した時に、クライアントは、プレイリストファイルを再度リロードしようとする前にある時間待つことができる。この期間は、初期最小リロード遅延と呼ぶ。これは、クライアントがプレイリストファイルのロードを開始した時間から測定される。
一実施形態において、初期最小リロード遅延は、プレイリストファイルの最後の媒体ファイルの持続時間又はターゲット持続時間の３倍のうちのいずれか小さい方である。媒体ファイル持続時間は、ＥＸＴＩＮＦタグによって指定される。クライアントがプレイリストファイルをリロードし、これが変化していないことを見出した場合、クライアントは、リトライの前にある時間待つことができる。一実施形態における最小遅延は、ターゲット持続時間の３倍又は初期最小リロード遅延の倍数のうちのいずれか小さい方である。一実施形態において、この倍数は、最初の試みに対して０．５、第２の試みに対して１．５、更に次の試みに対して３．０であるが、しかし、他の倍数を使用することもできる。
プレイリストファイルがロード又はリロードされる度に、クライアントデバイスは、ロードする次の媒体ファイルを判断するためにプレイリストファイルを調べる。ロードする最初のファイルは、上述したように最初に再生するように選択された媒体ファイルである。再生される第１の媒体ファイルがロードされプレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合、クライアントは、現在のプレイリストファイルが、本質的に見出されていたオフセットで最後にロードされた媒体ファイルのＵＲＩを含むことを検証することができ、ファイルが見出されなかった場合に再生を停止する。ロードする次の媒体ファイルは、プレイリストファイルにおける最後にロードされたＵＲＩに続く第１の媒体ファイルＵＲＩとすることができる。
再生される第１のファイルがロードされ、プレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合、ロードする次の媒体ファイルは、ロードされた最後の媒体ファイルのシーケンス番号よりも大きい最低シーケンス番号を有する媒体ファイルとすることができる。プレイリストファイルが、キーファイルＵＲＩを指定するＥＸＴ−Ｘ−ＫＥＹを含む場合、クライアントデバイスは、キーファイルを取得し、キーファイルの内側のキーを使用して、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまでＥＸＴ−Ｘ−ＫＥＹタグに続く媒体ファイルを解読する。
一実施形態において、クライアントデバイスは、プレイリストファイルをダウンロードするために以前使用されたのと同じＵＲＩを利用する。従って、プレイリストファイルに変更が行われた場合、クライアントデバイスは、媒体ファイルを検索して媒体ファイルに基づいて出力を提供するために、更新されたプレイリストファイルを使用することができる。
プレイリストファイルの変更は、例えば、媒体ファイルへのＵＲＩの削除、新しい媒体ファイルへのＵＲＩの追加、置換媒体ファイルへのＵＲＩの置換を含むことができる。プレイリストファイルに変更が行われた時に、変更を反映するために１つ又はそれよりも多くのタグを更新することができる。例えば、媒体ファイルの変更が、プレイリストファイルによって示された媒体ファイルの再生の持続時間の変更をもたらす場合、持続時間タグを更新することができる。
図３Ｂは、代替ストリームの１つの形式であるクライアントデバイスがマルチビットレートを使用してコンテンツのストリーミングをサポートするための技術の一実施形態の流れ図である。図３Ｂの例は、ＨＴＴＰの観点から提供されるが、しかし、他の非ストリーミングプロトコルも類似の方式で利用することができる。
クライアントデバイスは、作動３７０でプレイリストファイルを要求することができる。上述したように、プレイリストファイルは、クライアントデバイスに提供されたＵＲＩを利用して検索することができる。一実施形態において、プレイリストファイルは、異なるビットレートで同じコンテンツを提供するために媒体ファイルの変形ストリームのリストを含み、換言すると、単一のプレイリストファイルが、変形ストリームの各々の媒体ファイルに対するＵＲＩを含む。図３Ｂに示す例は、この実施形態を使用する。別の実施形態において、変形ストリームは、各々が異なるビットレートで同じコンテンツを提供し、クライアントに別々に提供された複数の個別のプレイリストファイルによって表すことができ、変形プレイリストは、個別のプレイリストファイルの各々に対するＵＲＩを提供することができる。それによってクライアントデバイスは、クライアント条件に基づいてビットレートを選択することができる。
プレイリストファイルは、作動３７５でクライアントデバイスによって検索することができる。プレイリストファイルは、作動３８０でクライアントデバイスメモリに格納することができる。クライアントデバイスは、現在のネットワーク接続速度に基づいて作動３８５で使用されるビットレートを選択することができる。媒体ファイルは、作動３９０で選択されたビットレートに対応するプレイリストファイルに含まれたＵＲＩを利用してサーバから要求される。検索された媒体ファイルは、クライアントデバイスメモリに格納することができる。出力が作動３９４で媒体ファイルを利用するクライアントデバイスによって提供され、クライアントデバイスがビットレートを変更するか否かを判断する。
一実施形態において、クライアントデバイスが、最初に最低利用可能ビットレートを選択する。媒体を再生している間、クライアントデバイスは、利用可能な帯域幅が再生のための高ビットレートの使用をサポートすることができるか否かを判断するために、利用可能な帯域幅（現在のネットワーク接続ビットレートなど）をモニタすることができる。サポートすることができる場合、クライアントデバイスは、高ビットレートを選択し、高ビットレート媒体プレイリストファイルによって示される媒体ファイルにアクセス可能である。逆もサポートすることができる。再生がより多くの帯域幅を消費する場合、クライアントデバイスは、低ビットレートを選択して低ビットレート媒体プレイリストファイルによって示される媒体ファイルにアクセス可能である。
クライアントデバイスが作動３９４でビットレートを変更した場合、例えば、利用可能な帯域幅における変更に応答して又はユーザ入力に応答して、クライアントデバイスは、作動３８５で異なるビットレートを選択することができる。一実施形態において、異なるビットレートを選択するために、クライアントデバイスは、新しく選択されたビットレートに対応するプレイリストファイルに含まれるＵＲＩの異なるリストを利用することができる。一実施形態において、クライアントデバイスは、プレイリスト内の媒体ファイルのアクセス中にビットレートを変更することができる。
ビットレートが作動３９４で変化しなかった場合、クライアントデバイスは、検索及び提示されなかった現在のプレイリストにまだ再生されていない媒体ファイルがあるか否かを判断する。このような媒体ファイルが存在する場合、処理は作動３９０に戻り、１つ又はそれよりも多くの媒体ファイルが、プレイリストのファイルに対するＵＲＩを使用して検索される。このような媒体ファイルがない（すなわち、現在のプレイリストの全ての媒体ファイルが再生されている）場合、処理は作動３９６に進み、ここでプレイリストが終了タグを含むか否かを判断する。含む場合、プログラムの再生が終了し処理は完了し、含まない場合、処理は作動３７０に戻り、クライアントデバイスは、プログラムに対するプレイリストのリロードを要求し、図３Ｂに提示されている方法を通じて処理が繰り返される。
図４は、サーバストリームエージェントの一実施形態のブロック図である。サーバストリームエージェント４００の要素をいくつかのサーバデバイスにわたって分散させることができることが認められるであろう。例えば、第１のサーバデバイスは、セグメンタ４３０、インデクサ４４０、及びセキュリティ４５０を含むことができるが、ファイルサーバ４６０を含むことができず、第２のサーバデバイスは、ファイルサーバ４５０を含むことができるが、セグメンタ４３０、インデクサ４４０、及びセキュリティ４５０を含むことができない。この例では、第１のサーバデバイスは、プレイリスト及び媒体ファイルを準備するが、これらをクライアントデバイスに送信することはなく、１つ又はそれよりも多くの第２のサーバデバイスは、プレイリスト及び媒体ファイルを受信し、任意的に格納し、プレイリスト及び媒体ファイルをクライアントデバイスに送信することになる。サーバストリームエージェント４００は、制御論理４１０を含み、サーバストリームエージェント４００の作動を示すための論理機能制御、及びサーバストリームエージェント４００の作動の指示に関連付けられるハードウエアを実施する。論理は、ハードウエア論理回路又はソフトウエアルーチン又はファームウエアとすることができる。一実施形態において、サーバストリームエージェント４００は、制御論理４１０に命令を提供するコードシーケンス及び／又はプログラムを表す１つ又はそれよりも多くのアプリケーション４１２を含む。
サーバストリームエージェント４００は、メモリデバイス又はデータ又は命令を格納するためのメモリリソースへのアクセスを表すメモリ４１４を含む。メモリ４１４は、サーバストリームエージェント４００にローカルのメモリを含むことができ、同様に又は代替的に、サーバストリームエージェント４００が存在するホストシステムのメモリを含む。サーバストリームエージェント４００はまた、サーバストリームエージェント４００の外部のエンティティ（電子又は人間）に関する（入力／出力インタフェース）サーバストリームエージェント４００への／からのアクセスインタフェースを表す１つ又はそれよりも多くのインタフェース４１６を含む。
サーバストリームエージェント４００は、本明細書で説明するようにリアルタイム又はリアルタイムに近いストリーミングを提供するためにサーバストリームエージェント４００を有効にする１つ又はそれよりも多くの機能を表すサーバストリームエンジン４２０を含むことができる。図４の例は、サーバストリームエンジン４２０に含むことができるいくつかの構成要素を提供するが、しかし、異なる又は付加的な構成要素を含むこともできる。ストリーミング環境を提供する場合に含むことができる例の構成要素は、セグメンタ４３０、インデクサ４４０、セキュリティ４５０、及びファイルサーバ４６０を含む。これらの構成要素の各々は、他の機能を提供するための他の構成要素を更に含むことができる。本明細書で使用される構成要素は、ハードウエア、ソフトウエア、ファームウエア、又はこれらのある組合せで実施されるか否かに関わらず、ルーチン、サブシステムなどを示している。
セグメンタ４３０は、ウェブサーバプロトコル（ＨＴＴＰなど）を使用してファイルとして送信することができる媒体ファイルに、提供されるコンテンツを分割する。例えば、セグメンタ４３０は、コンテンツを所定のファイルフォーマットでデータの所定の固定サイズブロックに分割することができる。
インデクサ４４０は、セグメンタ４３０によって作成された媒体ファイルのアドレス又はＵＲＩを提供する１つ又はそれよりも多くのプレイリストファイルを提供することができる。インデクサ４４０は、例えば、セグメンタ４３０によって作成された各ファイルに対応する識別子のための順序のリストによって１つ又はそれよりも多くのファイルを作成することができる。識別子は、セグメンタ４３０又はインデクサ４４０のいずれかによって作成又は割り当てることができる。インデクサ４４０は、媒体ファイルのアクセス及び／又は利用をサポートするためのプレイリストファイルの１つ又はそれよりも多くのタグを含むことができる。
セキュリティ４５０は、上述したようなセキュリティ機能（暗号化など）を提供することができる。ウェブサーバ４６０は、ホストシステムに格納されたファイルをリモートクライアントデバイスに提供することに関するウェブサーバ機能を提供することができる。ウェブサーバ４６０は、例えば、ＨＴＴＰ準拠プロトコルをサポートすることができる。
図５は、クライアントストリームエージェントの一実施形態のブロック図である。クライアントストリームエージェントの要素をいくつかのクライアントデバイスにわたって分散させることができることが認められるであろう。例えば、第１のクライアントデバイスは、アセンブラ５３０及びセキュリティ５５０を含むことができ、媒体ファイルの解読されたストリームを出力発生器５４０を含む（しかし、アセンブラ５３０及びセキュリティ５５０を含まない）第２のクライアントデバイスに提供することができる。別の例では、１次クライアントデバイスが、プレイリストを検索し、これらをプレイリストに指定された媒体ファイルを検索しこれらの媒体ファイルを提示するために出力を発生させる２次クライアントデバイスに提供することができる。クライアントストリームエージェント５００は、制御論理５１０を含み、クライアントストリームエージェント５００の作動を示すための論理的機能制御、及びクライアントストリームエージェント５００の作動の指示に関連付けられたハードウエアを実施する。論理は、ハードウエア論理回路又はソフトウエアルーチン又はファームウエアとすることができる。一実施形態において、クライアントストリームエージェント５００は、命令を制御論理５１０に提供するコードシーケンス又はプログラムを表す１つ又はそれよりも多くのアプリケーション５１２を含む。
クライアントストリームエージェント５００は、メモリデバイス又はデータ及び／又は命令を格納するためのメモリリソースへのアクセスを表すメモリ５１４を含む。メモリ５１４は、クライアントストリームエージェント５００にローカルのメモリ、並びに又は代替的に、クライアントストリームエージェント５００が存在するホストシステムのメモリを含むことができる。クライアントストリームエージェント５００は、クライアントストリームエージェント５００の外部のエンティティ（電子又は人間）に関する（入力／出力インタフェース）クライアントストリームエージェント５００間のアクセスインタフェースを表す１つ又はそれよりも多くのインタフェース５１６を含む。
クライアントストリームエージェント５００は、本明細書で説明するようにリアルタイム又はリアルタイムに近いストリーミングを提供するためにクライアントストリームエージェント５００を有効にする１つ又はそれよりも多くの機能を表すクライアントストリームエンジン５２０を含むことができる。図５の例は、クライアントストリームエンジン５２０に含むことができるいくつかの構成要素を提供するが、しかし、異なる又は付加的な構成要素を含むことができる。ストリーミング環境を提供する場合に含むことができる例示的な構成要素は、アセンブラ５３０、出力発生器５４０、及びセキュリティ５５０を含む。これらの構成要素の各々は、他の機能を提供するための他の構成要素を更に含むことができる。本明細書で使用される構成要素は、ハードウエア、ソフトウエア、ファームウエア、又はこれらのある組合せで実施されるか否かに関わらず、ルーチン、サブシステムなどを示している。
アセンブラ５３０は、サーバからウェブサーバプロトコル（ＨＴＴＰなど）を通じて媒体ファイルにアクセスするためにサーバから受信したプレイリストファイルを利用することができる。一実施形態において、アセンブラ５３０は、プレイリストファイルのＵＲＩによって示される媒体ファイルをダウンロードさせることができる。アセンブラ５３０は、プレイリストファイルに含まれたタグに応答することができる。
出力発生器５４０は、ホストシステムにおいてオーディオ又は視覚出力（又はオーディオと視覚の両方）として受信した媒体ファイルを提供することができる。出力発生器５４０は、例えば、１つ又はそれよりも多くのスピーカにオーディオを出力させ、表示デバイスにビデオを出力させることができる。セキュリティ５５０は、上述したようなセキュリティ機能を提供することができる。
図６は、複数のタグを備えたプレイリストファイルの一実施形態を示している。図６の例示的なプレイリストは、タグの特定の数及び順序付けを含む。これは、説明の目的のためだけに提供される。一部のプレイリストファイルは、タグのより多い、少ない、又は異なる組合せを含むことができ、タグを図６に示すものとは異なる順序で構成することができる。
開始タグ６１０は、プレイリストファイルの開始を示すことができる。一実施形態において、開始タグ６１０は、＃ＥＸＴＭ３Ｕタグである。持続時間タグ６２０は、再生リストの持続時間を示すことができる。すなわち、媒体ファイルの再生の持続時間は、再生リスト６００によって示されている。一実施形態において、持続時間タグ６２０は、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグであるが、しかし、他のタグを使用することもできる。
日付／時間タグ６２５は、再生リスト６００によって示された媒体ファイルによって提供されるコンテンツの日付及び時間に関する情報を提供することができる。一実施形態において、日付／時間タグ６２５は、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグであるが、しかし、他のタグを使用することもできる。シーケンスタグ６３０は、プレイリストのシーケンスにおけるプレイリストファイル６００のシーケンスを示すことができる。一実施形態において、シーケンスタグ６３０は、ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグであるが、しかし、他のタグを使用することもできる。
セキュリティタグ６４０は、プレイリストファイル６００によって示された媒体ファイルに適用されるセキュリティ及び／又は暗号化に関する情報を提供することができる。例えば、セキュリティタグ６４０は、媒体ファイルインジケータによって指定されたファイルを解読するための解読キーを指定することができる。一実施形態において、セキュリティタグ６４０は、ＥＸＴ−Ｘ−ＫＥＹタグであるが、しかし、他のタグを使用することもできる。変形リストタグ６４５は、変形ストリームがプレイリスト６００、並びに変形ストリームに関する情報（回数、ビットレートなど）によって提供されるか否かを示すことができる。一実施形態において、変形リストタグ６４５はＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグである。
媒体ファイルインジケータ６５０は、再生される媒体ファイルに関する情報を提供することができる。一実施形態において、媒体ファイルインジケータ６５０は、再生される複数の媒体ファイルへのＵＲＩを含む。一実施形態において、プレイリスト６００のＵＲＩの順序は、媒体ファイルにアクセス及び／又は再生すべきである順序に対応する。次のプレイリストインジケータ６６０は、再生ファイル６００の後に使用される１つ又はそれよりも多くの再生ファイルに関する情報を提供することができる。一実施形態において、次のプレイリストインジケータ６６０は、プレイリスト６００の媒体ファイルが再生された後に使用される１つ又はそれよりも多くのプレイリストファイルへのＵＲＩを含むことができる。
メモリタグ６７０は、クライアントデバイスが媒体ファイルコンテンツの再生後に媒体ファイルを格納することができるか否かを及び／又はその期間を示すことができる。一実施形態において、メモリタグ６７０は、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグである。終了タグ６８０は、プレイリストファイル６００が提示のための最後のプレイリストファイルであるか否かを示す。一実施形態において、終了タグ６８０はＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグである。
以下の段落は、一実施形態によるいくつかの例示的なプレイリストファイルを含む。
単純なプレイリストファイル
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT-X-ENDLIST
_______________________________________________
ＨＴＴＰＳを使用したスライディングウィンドウプレイリスト
#EXTM3U
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,
https://priv.example.com/fileSequence2680.ts
#EXTINF:8,
https://priv.example.com/fileSequence2681.ts
#EXTINF:8,
https://priv.example.com/fileSequence2682.ts
________________________________________________
暗号化媒体ファイルを備えたプレイリストファイル
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:7794
#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI="
https://priv.example.com/key.php−r=52"
#EXTINF:15,
http://media.example.com/fileSequence7794.ts
#EXTINF:15,
http://media.example.com/fileSequence7795.ts
#EXTINF:15,
http://media.example.com/fileSequence7796.ts
#EXT-X-KEY:METHOD=AES-128,URI="
https://priv.example.com/key.php−r=53"
#EXTINF:15,
http://media.example.com/fileSequence7797.ts
________________________________________________
変形プレイリストファイル
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
http://example.com/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example.com/mid.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example.com/hi.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"
http://example.com/audio-only.m3u8
________________________________________________
図７は、本明細書に説明するアセンブルストリームのための再生技術の一実施形態の流れ図である。一実施形態において、受信した媒体ファイルの再生は、開始、中止、繰り出しなどのためにユーザによって制御することができる。プレイリストファイルは、作動７００でクライアントデバイスによって受信される。プレイリストファイルによって示された媒体ファイルは、作動７１０で検索される。出力が、作動７２０で受信した媒体ファイルに基づいて生成される。媒体ファイルに基づく出力の受信及び生成は、上述したように達成することができる。
制御入力が作動７３０で検出された場合、クライアントデバイスは、入力が中止を示しているか否かを作動７４０で判断することができる。入力が中止である場合、処理は完了し再生は中止する。入力が作動７５０において繰り出し又は先送り要求を示す場合、クライアントデバイスは、作動７６０でメモリに格納されていた以前に再生された媒体ファイルに基づいて出力を発生させることができる。これらのファイルがそれ以上キャッシュにない場合、処理は媒体ファイルを検索するように作動７１０に戻り処理を繰り返す。代替の実施形態において、再生は、中止入力と同様に再生を完了させることなく再生を停止する休止機能をサポートすることができる。
１つのストリームから別のストリームに遷移する方法を図９Ａ−９Ｄに関して更に説明する。１つのクライアントデバイスが、これらの方法の各々を実行することができ、又はこれらの方法の各々の作動を本明細書で説明するように複数のクライアントデバイスにわたって分散させることができ、例えば、分散される場合、１つのクライアントデバイスは、変形プレイリスト及び２つの媒体プレイリストを検索し、これらを２つの媒体プレイリストによって指定された媒体ファイルを検索して検索された媒体ファイルによって提供される２つのストリーム間を切り換える別のクライアントデバイスに提供することができる。代替の実施形態において、図示の作動の順序を変更することができ、又はこれらの図に示すものよりも多いか又は少ない作動を存在させることができることが認められるであろう。本方法は、様々なストリームを選択するために変形プレイリストを使用することができる。変形プレイリストは、プログラム（スポーツイベントなど）に対する利用可能なストリームを判断するために、作動９０１で検索及び処理することができる。作動９０１は、クライアントデバイスによって実行することができる。第１のストリームは、作動９０３で変形プレイリストから選択することができ、次に、クライアントデバイスは、第１のストリームに対する媒体プレイリストを検索することができる。クライアントデバイスは、作動９０５で第１のストリームに対する媒体プレイリストを処理することができ、作動９０７で第１のストリームに対するネットワーク接続のビットレートを測定又はそうでなければ判断することができる。作動のシーケンスを図９Ａに示すものとは異なる順序で実行することができることが理解されると考えられ、例えば、作動９０７は、作動９０３中に実行することができる等々である。作動９１１でクライアントデバイスは、作動９０７からの測定されたビットレートに基づいて変形プレイリストから代替の媒体プレイリストを選択し、この代替の媒体プレイリストは、第１のストリームの既存のビットレートより高い第２のビットレートとすることができる。これは、典型的には、代替ストリームが第１のストリームより高い解像度を有することを意味する。代替の媒体プレイリストは、現在の条件に基づいて第１のストリームに対する現在のプレイリストより良い適合（例えば、作動９０７で測定されたビットレート）の場合に選択することができる。作動９１３で、代替ストリームに対する代替の媒体プレイリストが検索及び処理される。これは、典型的には、クライアントデバイスが、提示に両方が利用可能な第１のストリーム及び代替ストリームの両方を受信及び処理することができることを意味し、一方は提示され、他方は提示の準備がされる。次に、クライアントデバイスは、作動９１５でストリームのバージョンを切り換えるために遷移ポイントを選択し、第１のストリームの提示を中止して代替ストリームの提示を開始する。この切り換えがどのように達成されるかの例を図９Ｂ−９Ｄに関して提供する。一部の実施形態において、クライアントデバイスは、切り換えを実行する前に第１のストリームの受信を中止することができる。
図９Ｂは、クライアントデバイスが作動９２１及び９２３で第１の媒体プレイリスト（第１のストリームなど）によって指定されたコンテンツを検索、格納、及び提示することを示し、第１のプレイリストによって指定されたコンテンツが提示され、クライアントデバイスは作動９２５で第２の媒体プレイリストによって指定されたコンテンツ（第２のストリームなど）を検索及び格納する。第１の媒体プレイリストから得られたコンテンツを提示している間の第２の媒体プレイリストによって指定されたコンテンツの検索及び格納（一時バッファなど）は、クライアントデバイスがプログラムの大幅な中断なしにプログラムのバージョンを切り換えられるようにするプログラムのコンテンツの時間のオーバーラップ９５５（図９Ｄに図示）を作成する。従って、プログラムのバージョン間の切り換えは、切り換えが発生したことをユーザに通知することなく（ユーザは場合によっては切り換えの後に高解像度画像を通知することができるが）又はプログラムの提示における大幅な中断なしに多くの場合に達成することができる。作動９２７で、クライアントデバイスは、第１の媒体プレイリストによって指定されたコンテンツから第２の媒体プレイリストによって指定されたコンテンツに切り換える遷移ポイントを判断し、遷移ポイントの例（遷移ポイント９５９）は、図９Ｄに示されている。第２の媒体プレイリストによって指定されたコンテンツは、次に、切り換えの後に作動９３１で示される。
図９Ｃ及び９Ｄに示す方法は、遷移ポイントを判断するための一実施形態を表し、この実施形態は、遷移ポイントを判断するために２つのストリーム９５１及び９５３からのオーディオサンプルにおけるパターン照合に頼る。代替の実施形態は、ビデオサンプルにおけるパターン照合を使用することができる又は遷移ポイントを判断するために２つのストリームにおけるタイムスタンプなどを使用することができることが認められるであろう。本方法は、作動９４１でバッファの第１の媒体プレイリストによって指定されたコンテンツ（ストリーム９５１など）を格納する段階を含むことができ、バッファは、コンテンツの提示のため及びパターン照合作動のために使用することもできる。ストリーム９５１は、オーディオサンプル９５１Ａ及びビデオサンプル９５１Ｂの両方を含む。ビデオサンプルは、単一のビデオフレームを表示するために全ての必要なコンテンツを有するｉフレーム又はキーフレームに頼る圧縮技術を使用することができる。ストリーム９５１におけるコンテンツは、時間（例えば、プログラムの開始から経過した時間）を指定するタイムスタンプを含むことができ、これらのタイムスタンプは、サンプルの各々の開始（例えば、オーディオサンプル９５１Ａの各々の開始及びビデオサンプル９５１Ｂの各々の開始）にマーク付けすることができる。場合によっては、２つのストリーム間のタイプスタンプの比較は、これらが十分に正確でないために又は２つのストリームにおけるサンプルの境界の差のために遷移ポイントを判断する場合に有用でない場合があるが、しかし、タイムスタンプ範囲の比較は、２つのストリーム間の時間におけるオーバーラップ９５５が存在することを検証するために使用することができる。作動９４３で、クライアントデバイスは、第２の媒体プレイリストによって指定されたコンテンツをバッファに格納し、このコンテンツは、第１の媒体プレイリストから得られたコンテンツと同じプログラムのためのものであり、これもタイプスタンプを含むことができる。一実施形態において、タイプスタンプは、ストリームに存在しない場合、ストリームに対するプレイリストに追加することができ、例えば、一実施形態において、１つ又はそれよりも多くのタイプスタンプを含むＩＤ３タグを変形プレイリスト又は媒体プレイリストのようなプレイリストでエントリに追加することができる。エントリは、例えば、オーディオストリームの第１のサンプルに対するＵＲＩとすることができる。図９Ｄは、第２の媒体プレイリストから得られたコンテンツ９５３の例を示し、これは、オーディオサンプル９５３Ａ及びビデオサンプル９５３Ｂを含む。作動９４５で、クライアントデバイスは、一実施形態では適合したオーディオセグメント（セグメント９５７など）の後の次の自己包含ビデオフレーム（ｉフレーム９６１など）とすることができる遷移ポイント９５９をオーバーラップ９５５から選択するために、２つのストリーム９５１及び９５３におけるオーディオサンプルにおけるパターン照合を実行することができる。ｉフレーム９６１（及びその関連のオーディオサンプル）から開始して、プログラムの提示は、第２の媒体プレイリストから得られた第２のストリームを使用する。上述の方法は、遅いから速いビットレートへの変更及び速いから遅いビットレートへの変更の両方に対して一実施形態において使用することができるが、別の実施形態において、本方法は、遅いから速いビットレートへの変更だけに使用することができ、別の方法（例えば、遷移ポイントを配置しようとはしないが可能な限り早く遅いビットレートストリームからのコンテンツを格納して提示しようとする）は、速いから遅いビットへの変更に対して使用することができる。
図１０は、代替ストリームを使用してプレイリスト又は媒体コンテンツ又は両方をクライアントデバイスに提供する複数の冗長ロケーションを提供するための技術の一実施形態の流れ図である。プレイリストが上述したように代替ストリームを含む場合、代替ストリームは、帯域幅又はデバイスの代替的にだけでなく失敗フォールバックとして作動させることができる。例えば、クライアントがストリームに対するプレイリストファイルをリロードできない（例えば、４０４エラー又はネットワーク接続エラーのために）場合、クライアントは、代替ストリームへの切り換えを試みることができる。図１０を参照すると、フェイルオーバー保護を実施するために、第１のサーバデバイス又は第１のコンテンツ配信サービスは、図２Ｃの説明に関して上述したように、作動１００２で１つのストリーム又は複数の代替の帯域幅ストリームを作成するように構成される。作動１００４で、第１のサーバデバイス又は第１のコンテンツ配信サービスは、作動１００２で生成されたストリームからプレイリストファイルを生成する。第２のサーバデバイス又は第２のコンテンツ配信サービスは、作動１００６で並行ストリーム又はストリームのセットを作成することができ、プレイリストも作成することができる。これらの並行ストリームは、バックアップストリームと考えることができる。次に、バックアップストリームのリストが作動１００８でプレイリストファイルに追加され、それによって各帯域幅でのバックアップストリームが１次ストリームの後に列挙される。例えば、１次ストリームがサーバＡＬＰＨＡから来て、バックアップストリームがサーバＢＥＴＡにある場合、プレイリストファイルは以下の様にすることができる。
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝２００００
ｈｔｔｐ:／／ＡＬＰＡ．ｍｙｃｏｍｐａｎｙ．ｃｏｍ／ｌｏｗ／ｐｒｏｇ_ｉｎｄｅｘ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝２００００
ｈｔｔｐ:／／ＢＥＴＡ．ｍｙｃｏｍｐａｎｙ．ｃｏｍ／ｌｏｗ／ｐｒｏｇ_ｉｎｄｅｘ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝５００００
ｈｔｔｐ:／／ＡＬＰＨＡ．ｍｙｃｏｍｐａｎｙ．ｃｏｍ／ｍｉｄ／ｐｒｏｇ_ｉｎｄｅｘ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝５００００
ｈｔｔｐ:／／ＢＥＴＡ．ｍｙｃｏｍｐａｎｙ．ｃｏｍ／ｍｉｄ／ｐｒｏｇ_ｉｎｄｅｘ．ｍ３ｕ８
バックアップストリームが、各帯域幅がその帯域幅に対する１次の後に列挙されるバックアップによってプレイリストの１次ストリームに混ぜられることに注意されたい。クライアントは、単一のバックストリームセットに制限されない。上述の例では、ＡＬＰＨＡ及びＢＥＴＡの後に、例えば、ＧＡＭＭＡを続けることができる。同様に、ストリームの完全な並行セットを提供する必要はない。単一の狭帯域幅ストリームを例えばバックアップサーバで提供することができる。
作動１０１０で、クライアントは、第１のサーバデバイス又は第１のコンテンツ配信サービスに関連付けられる第１のストリームを使用して第１のＵＲＬからプレイリストファイルをダウンロードしようとする。図１１は、クライアント１１０２が、一実施形態に従って１つ又はそれよりも多くのＵＲＬ、サーバデバイス又はコンテンツ配信サービスと双方向に通信するネットワークを示している。プレイリストファイルを作動１０１２において、第１のＵＲＬ、サーバデバイス、又はコンテンツ配信サービスからクライアント１１０２に送信することができる。クライアントが、第１のＵＲＬ、サーバデバイス、又はコンテンツ配信サービスからプレイリストをダウンロードできない場合（例えば、ストリームに対する索引ファイルのリロードにおけるエラーのために）、クライアントは、代替ストリームに切り換えようにとする。１つのストリームにおける失敗（索引ロード失敗など）の場合（作動１０１０など）、クライアントは、作動１０１４でネットワーク接続がサポートする最高帯域幅代替ストリームを選択する。同じ帯域幅に複数の代替が存在する場合、クライアントはプレイリストに列挙された順序でこれらの中から選択する。例えば、クライアント１１０２がＵＲＬ１から確実にダウンロードできない場合、クライアント１１０２はＵＲＬ２又は別のＵＲＬからダウンロードすることができ、この場合、プレイリストファイルは、代替のＵＲＬからクライアントに送信される。この機能は、サーバクラッシュ又はコンテンツディストリビュータノードゴーダウンのようないくつかのローカルの失敗の場合にも媒体がクライアントに到達することができるようなる冗長ストリームを提供する。
フェイルオーバー保護は、クライアントがプレイリスト及び媒体ファイルを検索することができる複数の冗長ロケーションを提供する機能を提供する。従って、クライアントが第１のロケーションからストリームを検索できない場合、クライアントは、２次、３次のようなロケーションからのストリームへのアクセスを試みることができる。
一実施形態において、クライアントがプレイリストを検索することができる付加的なロケーションを示すために、同じ変形プレイリストタグが同じ帯域幅によって提供されるが、冗長ロケーションの新しいＵＲＩである。クライアントは、最初に、望ましい帯域幅に関連付けられる第１のＵＲＬへのアクセスを試みることができる。第１のＵＲＬからプレイリストをダウンロードできない場合、帯域幅に対して提示された次のＵＲＬへのアクセスを試みることができ、更に可能性の全てが尽きるまで等々である。
以下の例は、２５６００００帯域幅に対する１冗長ロケーション及び７６８００００帯域幅に対する２冗長ロケーションを含む。
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝１２８００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ．ｃｏｍ／ｌｏｗ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝２５６００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ．ｃｏｍ／ｍｉｄ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝２５６００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ．ｃｏｍ／ｍｉｄ−ｒｅｄｕｎｄａｎｔ２．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝７６８００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ．ｃｏｍ／ｈｉ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝７６８００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ２．ｃｏｍ／ｈｉ−ｒｅｄｕｎｄａｎｔ２．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝７６８００００
ｈｔｔｐ:／／ｅｘａｍｐｌｅ３．ｃｏｍ／ｈｉ−ｒｅｄｕｎｄａｎｔ３．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１，ＢＡＮＤＷＩＤＴＨ＝６５０００，ＣＯＤＥＣＳ，＝“ｍｐ４ａ．４０．５”
ｈｔｔｐ:／／ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｄｉｏ−ｏｎｌｙ．ｍ３ｕ８
この例では、ファイル名（例えば、ｍｉｄ−ｒｅｄｕｎｄａｎｔ２．ｍ３ｕ８）及び実際のＵＲＬ（ｈｔｔｐ:／／ｅｘａｍｐｌｅ２．ｃｏｍ＜ｈｔｔｐ:／／ｅｘａｍｐｌｅ２．ｃｏｍ／＞、ｈｔｔｐ:／／ｅｘａｍｐｌｅ３．ｃｏｍ＜ｈｔｔｐ:／／ｅｘａｍｐｌｅ３．ｃｏｍ／＞）の両方が変化することに注意されたい。しかし、一実施形態において、冗長ロケーションは、ファイル名だけ又はウェブサイトだけの変更とすることができる。
一実施形態において、プレイリストは、サーバデバイスによって圧縮することができ、圧縮形式でクライアントデバイスに送信することができる。圧縮されたプレイリストは、通常、圧縮されていないプレイリストよりプレイリストを表す少ないビットを要求し、従って、圧縮されたプレイリストは、送信又は受信される時に、無線セルラー電話ネットワークのようなネットワークの利用可能な帯域幅を使用しない。一実施形態において、ＨＴＴＰ１．１規格プロトコルのような転送プロトコルに準拠するか又はこれに適合するウェブサーバによって使用される内臓圧縮技術又は機能に従ってプレイリストをウェブサーバによって圧縮することができ、このような圧縮技術又は機能の例は、デフレート又はＨＴＴＰ１．１のｇｚｉｐ圧縮機能である。規格に基づく転送プロトコルの一部である他の規格に基づく圧縮機能を他の実施形態で使用することができる。圧縮されたプレイリストの使用は、一実施形態において、サーバデバイス及びクライアントデバイスの任意的な機能とすることができる。一実施形態において、プレイリストは、テキストコンテンツ（テキストファイルなど）とすることができ、規格に基づくウェブサーバによってデフレート又はｇｚｉｐによって実質的に圧縮し次に、クライアントデバイスによって自動的に解凍することができる。ｇｚｉｐ圧縮機能のバージョンの説明は、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１９５２．ｔｘｔに見つけることができ、デフレート圧縮機能のバージョンは、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１９５１．ｔｘｔに見つけることができる。クライアントデバイス上の多くのウェブサーバ及び多くのウェブブラウザが、デフレート又はｇｚｉｐ機能を自動的にサポートすることができる。
一実施形態において、クライアントデバイスは、更新されたプレイリストを定期的に要求することができ、例えば、クライアントデバイスは、サーバから数秒毎に（例えば、１０、２０、又は３０秒又はある他の時間毎に）更新されたプレイリストを要求することができる。ライブゲーム中のいずれの時間にもライブゲームの開始からクライアントが視聴を開始することを可能にするライブ・オン−ゴーイング・ベースボールゲームのためのプレイリストのようなグローイングプレイリストは、グローイングプレイリストがネットワークを通じて繰返し送信される場合に圧縮の使用がネットワークの帯域幅の消費を制限することができるように十分成長することができる。
一実施形態において、クライアントデバイスは、プレイリスト（更新されたプレイリストなど）を要求する時間、サポートすることができる圧縮技術（デフレート又はｇｚｉｐなど）を任意的に指定することができ、これらの技術に対するサポートは、クライアントデバイスが圧縮又は符号化コンテンツを解凍又は復号することができることを意味する。プレイリストに対するクライアントデバイスの要求は、圧縮技術の任意的な仕様と共に、ウェブサーバによって受信され、一実施形態において、プレイリストに対する圧縮技術をサポートすることを要求されないが圧縮されていないプレイリストを送信することができる。ウェブサーバは、圧縮されていないプレイリスト又はプレイリストに対するクライアントデバイスの要求に指定された圧縮技術の１つを使用して圧縮されたプレイリストをクライアントデバイスに送信することにより、クライアントデバイスの要求に応答することができる。クライアントデバイスは、本明細書で説明するようにプレイリストを受信してこれを使用し、プレイリストが圧縮されている場合、プレイリストは、クライアントデバイス上のウェブブラウザの復号器のようなクライアントデバイス上の復号器を使用して復号される。
図１２Ａ及び１２Ｂは、付加的な媒体ファイルが追加される時（例えば、送信されている現在のプレイリストがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない時）続いて起こるプレイリストの送信用サーバタイミングモデルの一実施形態を示している。現在のプレイリストが提示の最終媒体ファイルを含まない場合、データ処理システム又はサーバは、少なくとも１つの新しい媒体ファイルＵＲＩを含むプレイリストの新しいバージョンを作ることができる。図１２Ａ及び１２Ｂは、新しい媒体ファイルＵＲＩを備えた新しいプレイリストがプレイリストの前のバージョンに連続した方式でのクライアントデバイスへの送信に利用可能になることを保証するためのサーバタイミングモデルの一実施形態を示している。このモデルは、例えば、プレイリストに指定された媒体ファイルの持続時間を短くすることができる（例えば、数秒の長さだけ）時に使用することができる。一実施形態において、各媒体ファイルに対する最大媒体ファイル持続時間を設定することによって及び最大媒体ファイル持続時間に基づくプレイリスト持続時間の最小量を設定することにより、サーバ又は他のデータ処理システムは、各媒体ファイルが数秒の持続時間しかない時でもクライアントデバイスへのコンテンツの連続配信又は送信を保証することができる。
ここで図１２Ａを参照すると、エンドリストタグが作動１２００で判断されるように次のプレイリストファイルに存在しない場合にプレイリストにおける各媒体ファイルの最大媒体ファイル持続時間としてターゲット持続時間を設定するように作動１２０１を使用することができる。作動１２０１は、データのストリームを複数の媒体ファイルに分割して個々のファイルとしてこれらの複数の媒体ファイルを格納するデータ処理システムによって実行することができる。ストリームを分割する処理は、プレイリストファイルに指定された各媒体ファイルがターゲット持続時間よりも短い（又はターゲット持続時間に短い時間を加えた又は除いた時間よりも短い）ことを保証するために、ターゲット持続時間（例えば、現在のプレイリストファイルのターゲット持続時間）を利用することができる。プレイリストを生成するデータ処理システムは、プレイリストファイルの持続時間が作動１２０３に示すように少なくともターゲット持続時間の倍数にすることができることを保証することができる。一実施形態において、倍数は、３ターゲット持続時間（又はターゲット持続時間のある他の倍数）とすることができ、プレイリスト持続時間の最小値として使用され、プレイリストの持続時間は、プレイリスト内に指定された媒体ファイルの累積持続時間によって定義される。プレイリストを生成するシステム（サーバなど）は、最小持続時間を満足させるために少なくとも十分な媒体ファイルの数を各プレイリストが指定することを保証することにより、プレイリストの最小持続時間を遵守することができ、例えば、最小持続時間が３ターゲット持続時間である場合、各プレイリストは、少なくとも３ターゲット持続時間を含むべきである。
作動１２０５は、適合した及び連続したストリームが、媒体ファイルを送信しているサーバのようなデータ処理システムから利用可能であることを保証するための更に別の機構として使用することができる。この更に別の機構は、プレイリストへの変更があるか否かを判断するために、クライアントデバイスによるポーリング又はプリングの量を低減することができる。作動１２０５で、サーバが次のプレイリストファイルを送信するための最も早い時間と最も遅れた時間が存在するようにサーバを設定することができる。最も早い時間及び最も遅れた時間を前のプレイリストファイル（新しいプレイリストファイルのすぐ前にある）が利用可能になった時間に基づく又はこれに対する時間ウィンドウとして使用することができる。最も早い時間は、例えば、すぐ前のプレイリストがサーバからの送信に最初に利用可能になった（が必ずしも送信されていない）時間に基づくことができる。最も遅れた時間は、例えば、そのすぐ前のプレイリストがサーバからの送信に最初に利用可能になった（が必ずしも送信されていない）時間に基づくことができる。例えば、一実施形態において、最も早い時間は、前のプレイリストファイルが最初に送信に利用可能になった時からターゲット持続時間（例えば、作動１２０１で設定されたターゲット時間）の最初の所定の百分率（例えば、１／２）より早くない時間として指定することができ、最も遅れた時間は、すぐ前のプレイリストファイルがサーバからの送信に最初に利用可能になった時からターゲット持続時間の第２の所定の百分率（例えば、１．５倍）よりも遅くならないように設定することができる。プレイリストファイルが最初に送信に利用可能になった時間は、一実施形態において、プレイリストファイルの作成の時間（サーバ上にファイルシステムによって記録された時間）とすることができる。この例は、時系列１２１１を含む図１２Ｂに示されている。ターゲット持続時間１２１３は、前のプレイリストファイルが最初に送信に利用可能になった時間である時間１２０９で１つ又はそれよりも多くのサーバによって最初に利用可能になったすぐ前のプレイリストの持続時間を表すプレイリスト持続時間１２１５の一部分である。そのプレイリストに指定された媒体ファイルは、時間１２０９の近くでその送信を開始することができる。図１２Ｂに示すサーバタイミングモデルに従ってサーバは、時間１２０９の後のターゲット時間の１／２である最も早い時間１２１７まで次のプレイリストファイルを送信すべきではなく、サーバは、図１２Ｂに示す例では時間１２０９の後の１及び１．５倍ターゲット持続時間に指定されていた時間１２１９よりもいくらか遅く次のプレイリストファイルを利用可能にすべきではない。このサーバタイミングモデルは、プレイリストに指定された媒体ファイルを検索するのに十分な時間をクライアントデバイスに提供し、次に、再生中のコンテンツの提示を中断することなく一貫して及び連続してこれらの媒体ファイルを提示するために、プレイリストファイルがクライアントデバイスに利用可能であることを保証するように使用することができる。一実施形態において、これらのサーバタイミングモデルは、コンテンツがライブイベントの送信である時に使用することができ、ライブイベントからのデータのストリームは、複数の媒体ファイルに分割され、次に、これらの複数の媒体ファイルは、ライブイベントに対してリアルタイムに近い時間でベースボールゲームのようなライブイベントのデータのストリームからこれらが分割された後直ちに複数の媒体ファイルを受信するクライアントデバイスに送信される。
図１３は、特にクライアントデバイスが実質的にリアルタイムでライブイベントを提示している時に、及びクライアントデバイスがライブイベントの現在の終わりに近い（時間的に最も新しい）コンテンツを提示している時に、クライアントデバイスでの再生における停止を防ぐために使用することができる方法の実施形態を示している。例えば、ライブイベントがベースボールゲームである場合、クライアントデバイスのユーザは、ゲームの最初からゲームを見始めるのではなくゲームの最新のイベントだけを見ることを好む場合がある。ユーザが進行中のゲームの最新イベントだけを見たい場合、ユーザは、利用可能な媒体ストリームの終わりから最後の１０又は１５秒で開始するポイントから始まるように再生の設定を求めることができる。ネットワークにおける問題又は遅延は、突然データを利用できなくすることがあり、新しいデータが利用できなくなることがあり、従って、非常に短い時間で、クライアントデバイスは、ユーザがこのモードで作動するようにクライアントデバイスを設定した時に提示するコンテンツを使い果たすことがある。図１３の方法は、現在のプレイリストファイルの終わりの前の少なくともある時間（例えば、３０秒）である開始ポイントで開始するように再生が望ましい規則をクライアントデバイスで実施することによってこのハプニングの機会を軽減するために利用することができる。例えば、プレイリストファイルがその中に指定された５媒体ファイルを有する場合（各媒体ファイルは１０秒の長さである）、この規則の１つの実施は、プレイリストに指定された５媒体ファイルのシーケンスにおける第３の媒体ファイルよりも遅くない開始ポイントを強制することとすることができる。ここで図１３を参照すると、作動１３０１は、エンドリストタグ又はマーカがプレイリストに存在するか否かを判断するために使用することができる。このようなエンドリストタグが存在する場合、図１３の方法は、新しいコンテンツがプレイリストに追加されないように中止することができ、それによって一実施形態において作動１３０３で規則を実施する必要はない。他方、プレイリストにエンドリストタグが存在しない場合、プレイリストファイルが終わる前の少なくともある時間に開始ポイントを設定するように要求する規則をクライアントデバイスで実施することができる。ある時間は、媒体ファイルのターゲット持続時間に基づいて指定することができる。例えば、一実施形態において、クライアントデバイスは、プレイリストファイルの終わりから３より多いターゲット持続時間である媒体ファイルから開始するように要求することができる。
本発明の別の態様は、２つのプレイリストからのストリーム（例えば、２つの変形ストリーム）間を切り換える時又は媒体ファイルの２つのセット間の他の切り換えの時に使用することができる方法に関する。２つの異なるプレイリストからのストリーム間を切り換える方法の例は、図９Ａ、９Ｂ、９Ｃ、及び９Ｄに関して提供される。本方法では、ストリーム間の切り換え又は遷移がシームレスになるように一貫した及び連続した再生を保証するために、２つのストリーム間の時間のオーバーラップを使用することができる。図９Ｄに示すように、オーバーラップ９５５は、両方のストリームからの媒体コンテンツがクライアントデバイスに格納され更にクライアントデバイスで再生することができる時間を表し、それによって２つのストリーム間のシームレスな切り換えを可能にする。一実施形態において、オーバーラップは、決して変化せず、クライアントデバイス内で設定された最小数とすることができる。この実施形態は、確実に機能することができるが、オーバーラップが不要に長すぎる時がある場合がある。換言すると、デバイスが遷移の準備をしているとしてもオーバーラップが切り換え又は遷移が起こるのを阻止することがある。例えば、低解像度から高解像度に切り換える時に、不要に長いオーバーラップは、高解像度提示が既に利用可能であり、提示の準備ができている時間にユーザに低解像度提示を見ることを強いる場合がある。高速接続は、例えば、低速接続又は接続のタイプに必要なオーバーラップよりも短くすることができるオーバーラップを迅速に開発する機能を提供することができる。図１４Ａによる実施形態において、クライアントデバイスが、接続速度又は接続タイプに適応することができ、接続速度又は接続タイプに基づいて望ましい最小オーバーラップを修正することができる。例えば、接続速度又はタイプが速い場合、低接続速度又は接続タイプに対して望ましい最小オーバーラップに対して最小オーバーラップを低減することができる。条件が変化した（例えば、クライアントデバイスが３Ｇ接続を失い２Ｇ又は遅い接続に頼らなければならない）時に、次に、最小オーバーラップを変更することができる。従って、クライアントデバイスは、接続速度又はタイプに基づいて最小オーバーラップに適応することができる。ここで図１４Ａを参照すると、作動１４０１で、クライアントデバイスは、接続の速度又はタイプを判断することができる。図９Ｄを参照すると、クライアントデバイスが第１のプレイリストからのストリームを受信中に、第２のプレイリストからのデータの第２のストリームは、受信されているデータの新しいソースであることを見ることができる。この時に、クライアントデバイスは、作動１４０３で現在の接続速度又は接続タイプに基づいて望ましいオーバーラップの最小量を判断するために、接続の速度又は接続のタイプを判断することができる。条件が変化した時に、この最小オーバーラップは、セルラー電話タワー、ＷｉＦｉ基地局などへの無線接続のような変化する条件に基づいて適応させることができる。クライアントデバイスが無線セルラー電話ネットワーク又は他のデータネットワーク上で移動している時にこれは特に有利とすることができる。現在の条件に対する最小オーバーラップが存在すると設定した後、次に、クライアントデバイスは、作動１４０５で、第１のプレイリスト又は古いソースからのストリームから第２のプレイリストからのストリームとすることができる新しいソースへ切り換える又は遷移することができる。この遷移の例は、図９Ａ−９Ｄに関連付けられる説明を用いて提供される。
図１４Ｂ、１４Ｃ、及び１４Ｄは、２つのストリーム間のオーバーラップ（図９Ａ−９Ｄと共に説明及び提示されたオーバーラップ又は図１４Ａと共に説明したオーバーラップ）の別の態様を示している。図１４Ｂ、１４Ｃ、及び１４Ｄに示す方法は、適応的に得られるオーバーラップによって実施することができ（図１４Ａに関して説明する）、又は本方法は、変化しない固定オーバーラップと共に使用することができる。図１４Ｂ−１４Ｄに提示されている方法は、「古いストリーム」１４１０からの媒体ファイルのダウンロードによって開始することができる（例えば、「古いストリーム」１４１０は新しいストリーム１４１４に対する将来のダウンロードの第２の速度より遅いビットレートである第１の速度でダウンロードされた低解像度ビデオとすることができる）。古いストリーム１４１０は、ハッシュマーカ１４１１によって示される通りにダウンロードされ、現在、クライアントデバイス上で再生ポイント（再生ヘッド位置など）１４１２でユーザに提示されており、現在の再生ポイント１４１２を超えた古いストリーム１４１０における既にダウンロードされたコンテンツは、接続が失敗した場合に利用可能であるバッファに入れられたコンテンツである。次に、クライアントデバイスは、新しいストリーム１４１４に対するプレイリストファイルを読取り、これらのブロックのコンテンツをダウンロードする前でも、ブロック１４１６及び１４１５のようなコンテンツ「ブロック」をプレイリストファイルから判断することができ、例えば、新しいストリームに対するプレイリストファイルは、少なくとも実質的に古いストリーム１４１０に対するコンテンツブロック１４１６及び１４１５の時間のロケーションを示すことができる。この判断により、クライアントデバイスは、ブロック１４１５に対する１つ又はそれよりも多くの媒体ファイルを要求及び検索することによって新しいストリーム１４１４に対する第１のブロック１４１５のダウンロードを保守的に判断することができ、図１４Ｃは、そのダウンロードの結果を示している（ブロック１４１５Ａは、このブロックがダウンロードされたことを示すためのハッシュマークを有する）。再生位置は、時間的に新しいロケーション（古いストリーム１４１０の最も左のブロック内にまだある）に進行している。この場合、ブロック１４１５のダウンロードは、再生位置が古いストリーム１４１０のその最も左のブロックに残らない程十分速かったものである。ブロック１４１５は、再生がブロック１４１５Ａ近くで少なくとも切り換えることができるようにダウンロードが長くかかった場合に保守的に選択される。図１４Ｃに示すポイントで、クライアントデバイスは、ブロック１４１５Ａによって提供されたオーバーラップと再生の現在のポイント（図１４Ｃの１４１２に示す）間にどのくらいの時間が残っているかを検査することができる。接続速度が与えられて十分な時間が存在する場合、クライアントデバイスは、現在のオーバーラップの前のブロックであるブロック又はセグメント１４１６をダウンロードすることができ、次に、クライアントデバイスは、ダウンロードされたブロック１４１６Ａ（ハッシュマークによって示された通りにダウンロードされた後の図１４Ｄに示されている）によって提供されたオーバーラップと再生の現在のポイント（図１４Ｄの１４１２に示す）との間にどのくらいの時間が残っているかを判断するために検査を繰り返すことができる。図１４Ｄに示す例の場合のように、１４１６Ａのダウンロードが即座に起こった場合、クライアントデバイスは、オーバーラップのポイントを時間的に後方に移動することができ、ストリーム間の切り換えに必要とされる時間を低減し（及び従ってブロック１４１６Ａ内の切り換えを可能にする）、他方、切り換えがブロック１４１６Ａ内で発生できないようなダウンロード１４１６Ａにおける遅延が存在する場合、クライアントデバイスは、ブロック１４１５Ａ内で切り換えを起こすために使用することができるオーバーラップとしてブロック１４１５Ａを使用することができる。
一実施形態において、２つのストリーム間を切り換える時（図９Ａ−９Ｄ及び１４Ａ−１４Ｄに示す例など）、クライアントデバイスは、新しいストリーム（ストリーム１４１４など）への切り換えが完了するか又は切り換えが最小時間に新しいストリームに安定して作動するまで、古いストリーム（ストリーム１４１０など）の格納（廃棄ではなく）を続けることができる。
本発明の別の態様は、画像の解像度を定義する属性を利用することができる。この属性により、クライアントデバイスは、解像度を切り換えるべきかでないか又はそうでなければ属性に基づいてストリーム間で切り換えるべきかを判断することができる。例えば、クライアントデバイスは、表示することができる最大解像度を既に再生していること、及びデータネットワークを通じてデバイスに利用可能にすることができる高解像度をダウンロードする場合にポイントがないことを判断することができる。
図１５は、このような属性を利用するための一実施形態における方法の例を示している。作動１５０１で、クライアントデバイスによってプレイリストファイルを受信することができ、クライアントデバイスは、作動１５０３で、クライアントデバイスに利用可能な画像の解像度を定義する属性がプレイリストファイルに存在することをプレイリストファイルから判断することができる。その属性に基づいて、クライアントデバイスは、作動１５０５で、別のプレイリストファイルを検索するか又はその属性に関連付けられる媒体ファイルを検索するか否かを判断することができる。解像度属性を提供することにより、クライアントデバイスは、プレイリストのデータを処理する方法を知的に判断することができる。更に、クライアントデバイスは、不要なダウンロードを阻止することができるデータの検索に関する判断を実行することができ、これは、ネットワークにおけるデータトラフィックの量を最小にすることができる。
本発明の実施形態により、システムは、日付及び時間に基づいてコンテンツを検索することができる。例えば、ユーザは、２００９年４月９日午後５時頃のホームランヒットを見ることを要求することができ、又は日付及び大体の時間に別のイベントを見ることを要求することができる。本発明の実施形態は、タイムスタンピングにより、対応する媒体ファイルの開始に関連付けられるＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの使用を通じてこの機能を提供することができ、タグは、プレイリストファイルのその媒体ファイルの前に現れるタグを有することによってその対応する媒体ファイルに関連付けることができる。サーバのようなシステムは、望ましい媒体ファイルを見出すためにクライアントデバイスによって検索（例えば、ダウンロード）することができ日付及び時間を探すために使用することができる１つ又はそれよりも多くのプレイリストを格納することができ、代替的に、クライアントデバイスは、日付及び時間検索要求に適合する１つ又はそれよりも多くの媒体ファイルを識別するために、１つ又はそれよりも多くのプレイリストを検索するように（例えば、日付及び時間検索要求を通じて）サーバに要求することができ、更に、サーバは、１つ又はそれよりも多くの媒体ファイルを識別することによって応答することができる。一実施形態において、タグは、媒体ファイルの実質的に正確な開始を示し、媒体ファイル内のタイムスタンプを時間的により細かい細粒度を有する再生ポイントを見つけるために使用することができる。例えば、タグのタイプスタンプは、２００９年４月９日の午後５時３分に媒体ファイルが始まったことを示すことができ、媒体ファイル内のタイムスタンプ（又は時間の他のインジケータ）は、午後５時３分後の分又は秒のような区分で時間を指定することができ、それによってデバイスは、例えば、午後５時６分又は午後５時５分３０秒で（再生開始ポイントの選択を通じて）再生を開始することができる。
図１６Ａは、タイムスタンプタグを使用してプレイリストファイルを作成するための一実施形態による方法を示す流れ図を示している。本方法は、ソフトウエア、ハードウエア、ファームウエア、又は上述のいずれかの組合せを含む処理論理によって実施されるサーバによって実行することができる。一部の例では、サーバは、ＭＬＢのような媒体プロバイダによって提供される。
ボックス１６１０で、処理論理は、タイムスタンプタグを作成し、タイムスタンプタグの各々を１つの媒体ファイルに関連付ける。タイムスタンプタグのタイムスタンプは、関連付けられた媒体ファイルの開始日付及び時間を示す。タイムスタンプタグの一部の実施形態の詳細は上記に説明している。
ボックス１６２０で、処理論理は、１つ又はそれよりも多くのタイムスタンプタグ（例えば、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグ）を備えたプレイリストファイルを作成し、タグの各々は、特定の媒体ファイルに関連付けられる。媒体ファイル自体が同様に内部タイムスタンプを有することに注意されたい。ボックス１６３０で、処理論理は、プレイリストを配信することができ、それによってタイムスタンプタグの日付及び時間を使用した日付及び時間毎の検索にプレイリストファイルを利用することができる。一部の実施形態において、プレイリストは、リポジトリに格納され、リポジトリからクライアントデバイスはプレイリストをダウンロードすることができる。
図１６Ｂは、タイムスタンプタグを備えた作成されたプレイリストファイルを使用するための一実施形態による方法を示す流れ図を示している。本方法は、ソフトウエア、ハードウエア、ファームウエア、又は上述のいずれかの組合せを含む処理論理によって実施されるクライアントデバイスによって実行することができる。クライアントデバイスは、媒体にアクセス及び再生するために、プレイリストファイルに関連付けられた媒体の個々の消費者、加入者、又は視聴者によって使用することができる。
ブロック１６５０で、処理論理は、特定の日付及び時間に開始するプログラムのセグメントに対するユーザ要求を受信する。例えば、ユーザは、野球ゲーム全体の代わりに、２０１０年４月６日の午後８時１５分に始まる野球ゲームの第４のイニングを要求することができる。ユーザ要求に応答して、処理論理は、ブロック１６５２でプログラムに関連付けられる１つ又はそれよりも多くのプレイリストファイルを媒体サーバからダウンロードする。ブロック１６５４で、処理論理は、要求されたセグメントの日付及び時間に最も近い日付及び時間に対するプレイリストファイル内部のタイムスタンプタグの時間及び日付を使用してダウンロードされたプレイリストファイルを検索する。次に、処理論理は、ブロック１６５６で要求されたセグメントの日付及び時間からその日付及び時間を差し引く。これは、持続時間を生成する。次に、処理論理は、処理論理がブロック１６５７で日付スタンプされた媒体ファイルの後のその持続時間に近いターゲット媒体ファイルを配置するまで、プレイリストファイルの次の媒体ファイル持続時間を前方に進む。次に、処理論理は、要求されたセグメントを含むファイルに関して確実に推測された場合、ブロック１６５８でこのターゲット媒体ファイルをダウンロードする。
一部の実施形態において、日付スタンプされた媒体ファイル及びターゲット媒体ファイル間の全ての媒体ファイルは、単一の符号化の一部であり、すなわち、これらの間に不連続のタグはない。これらがある場合、処理論理は、正確な持続時間を得るためにターゲットファイルにおける媒体ファイルタイムスタンプから日付スタンプされたファイルにおける媒体ファイルタイムスタンプを差し引くことができ、これは、要求された日付及び時間の正確な配置ししを可能にする。
プレイリストファイルにおけるタイムスタンプタグの日付及び時間を使用して、処理論理は、要求されたセグメントを見出すために媒体ファイルを検索するために、全プログラムの全ての媒体ファイルをダウンロードする必要はない。ユーザが全プログラムを要求しない時にクライアントデバイスは全プログラムの全ての媒体ファイルをダウンロードする必要がないので、帯域幅における大幅な節約を達成することができる。更に、多くの典型的な媒体ファイルは任意のタイムスタンプだけを含み、これは、ゼロで始まることが多い。従って、上述のタイムスタンプタグの日付及び時間は、媒体ファイルの任意のタイムスタンプを現実の日付及び／又は時間に関連付けることができる。タイプスタンプタグを使用して、クライアントデバイスは、各媒体ファイルを走査するより実質的に特定の日付及び／又は時間を含むプレイリスト要素を配置することができる。
本発明の一実施形態は、ＩＤ３フォーマットの媒体ストリームへのタイムメタデータの挿入を可能にする。媒体ストリームは、所定のフォーマットで符号化されたビデオ及び／又はオーディオデータを含むことができる。例えば、媒体ストリームは、国際規格ＩＳＯ／ＩＥＣ１３８１８であるムービング・ピクチャ・エキスパート・グループ（ＭＰＥＧ）によって開発されたＭＰＥＧ−２で符号化されたビデオ及びオーディオデータを含むことができる。大まかに、メタデータは、媒体ストリームにおけるデータの情報、及び特定の時間（例えば、ターゲットが得点された時間）に関連付けられるメタデータを示す時間付きメタデータを含む。時間付きメタデータは時間の経過時に変化する場合があることに注意されたい。時間付きメタデータは、ＩＤ３フォーマットのようなメタデータを格納するための所定のフォーマットで媒体ストリームに挿入することができる。一部の実施形態において、ビデオデータをフレームのシーケンスに分割することができる。ビデオデータの時間メタデータは、フレームのシーケンスに関連付けられるコンテナに分割することができる。各コンテナは、対応するフレームの時間メタデータ及び対応するフレームに関連付けられる時間の両方を格納することができる。代替的に、各コンテナは、対応するフレームの時間メタデータ及び対応するフレームのフレーム数の両方を格納することができる。一部の実施形態において、フレームの時間メタデータは、フレームの所定の情報のセットを含むことができる。例えば、時間メタデータは、ビデオデータの対応するフレームが記録されたロケーションのロケーション情報（全地球測位システム（ＧＰＳ）データなど）を含むことができる。
図１６Ｃ、１６Ｄ、及び１６Ｅは、ストリーミングコンテンツを指定するＵＲＬを送信することによってストリーミングコンテンツを要求するクライアントデバイスのような受信機にバッファに入れられたストリーミングコンテンツの再生を制御するために時間メタデータ又は他の機構を使用することができる実施形態の例を示している。これらのＵＲＬは、本明細書に説明する１つ又はそれよりも多くのプレイリストファイルに含むことができる。
図１６Ｃは、表示デバイス１６６０（又はその表示デバイスの一部分）に提示することができるユーザインタフェース（ＵＩ）を示している。時間に基づくライブスポーツイベント又は番組又は他のビデオコンテンツのようなコンテンツ１６６１は、一実施形態では２つの時系列１６６２及び１６６４と共に提示されている。時系列１６６４は、コンテンツの時間の全ての長さ（９０分番組のような固定された時間、又は野球の試合のようなはっきり決まっていない時間のいずれかとすることができる）を示している。インジケータ１６６７は、全コンテンツ内の現在の再生位置を示すために提示することができ、時系列の長さに対する時系列１６６６上のインジケータ１６６７の位置は、その現在の再生位置を示す。例えば、インジケータ１６６７が左の終点と右の終点の中間にある場合、現在の再生位置は、既存のコンテンツの約半分である。時系列１６６６は、後退制御１６６８、中断制御１６６９、及び早送り制御１６７０のような他のＵＩ制御に関連付けることができる。後退制御１６６８は、選択された時に、現在の再生時間位置に戻ることができる（例えば、３０秒戻ることができる）。中断制御１６６９は、選択された時に、受信機での再生を停止することができ、早送り制御１６７０は、選択された時に、現在の再生位置を最も新しい現在の（ライブ又はライブに近い）コンテンツに移動することができる。一実施形態において、両方の時系列１６６６及び１６６２は、パネルの下に提示されているストリーミングコンテンツの上に重なる半透明又は半透過性のパネルに同時に存在させることができる。
時系列１６６２は、一実施形態において、受信機でのバッファに入れられたコンテンツの量の時間での長さを表している。受信機は、本明細書で説明するようにストリーミングコンテンツをバッファに入れることができ、データ通信速度が遅くなる又はストリーミングコンテンツのデータ通信が中断された場合でも、常にストリーミングコンテンツが再生されるようにする。図１６Ｃに示す例では、ストリーミングコンテンツの総合的に４分３０秒が受信機で受信及びバッファに入れられ、この合計時間が、マーカ１６６３（３分５１秒）及びマーカ１６６５（３９秒）から得られ、これらのマーカは、現在の再生位置が最も新しく受信したコンテンツ（本明細書で説明するようにライブ又はリアルタイムに近いライブとすることができる）から３９秒であることを示している。一実施形態において、バッファに入れられたコンテンツ内の現在の再生位置は、例えば、時系列１６６２に沿ってインジケータ１６６４を選択及び移動することによって変更することができる。これは、例えば、指でインジケータ１６６２に触れることによって又はマウスを通じてカーソルを制御することにより、又は他の公知のユーザインタフェース技術を通じて実行することができる。図１６Ｄは、インジケータ１６６２を移動した結果の例を示しており（バッファに入れられたコンテンツの中間ポイント）、それによってコンテンツの提示は、最も新しく受信した及びバッファに入れられたコンテンツの前の２分１５秒（時系列の右の終点によって表される）である再生ポイントに現在設定される。
図１６Ｅは、図１６Ｃ及び１６Ｄに示すユーザインタフェースを使用するための一実施形態の方法の例を示している。受信機のようなデータ処理システムは、作動１６７２で時系列１６６６のような時系列を表示又はそうでなければ提示することができ、これは、ストリーミングプログラムの現在の長さを表し、制御１６６８、１６６９、及び１６７０のようなＵＩ制御を表示することができる。更に、このシステムは、作動１６７３で、バッファに入れられたコンテンツ内の現在の再生位置を示す時系列１６６２のような別の時系列を同時に表示することができる。一実施形態において、時系列は、現在バッファに入れられているコンテンツの合計の時間の長さを表すことができる時系列上のバッファコンテンツにおける現在の再生位置のインジケータを示すことができる。受信機は、ストリーミングコンテンツの提示を変更するために、１つ又はそれよりも多くのＵＩ制御上のユーザ入力に作動１６７４で応答することができる。例えば、ユーザが時系列１６６２に沿ってインジケータ１６６４を移動した場合、ユーザは、バッファに入れられたコンテンツ内の現在の再生位置を変更することができ、図１６Ｃ及び１６Ｄに示す例は、現在の再生位置が最も新しく受信したコンテンツ（リアルタイムに近い「ライブ」ストリームとすることができる）の前の数秒から最も新しいコンテンツの前の数分に変更することができることを示している。図１６Ｃ及び１６Ｄの例では、ユーザは、実際には、バッファに入れられたコンテンツ内の早いポイントに再生を繰り出しており、バッファに入れられたコンテンツを再生することができ、この繰り出しは、コンテンツの時系列１６６６のような全ての現在の時系列とは別の時系列で制御することができる。
本発明の一実施形態において、媒体ファイルの処理（例えば、プレイリストの検索及びプレイリストに指定された媒体ファイルの検索及び媒体ファイルにおけるコンテンツの復号）は、媒体を提示し提示される媒体を制御するユーザインタフェースとは別に行うことができる。例えば、ライブイベント（例えば、野球の試合を見るためのメジャーリーグベースボール（ＭＬＢ）アプリケーションなど）又は他のストリームを見るためのアプリケーションのようなユーザアプリケーションは、提示を表示及び制御する（媒体ファイルの選択を受信する）ためのユーザインタフェースを提供することができ、同時に別のソフトウエア処理（例えば、「メディアサーブド」と呼ぶことができる媒体をサービス提供するためのデーモンのような媒体をサービス提供するソフトウエア処理）は、プレイリストを検索して媒体ファイルを検索及び復号することができる。場合によっては、媒体ファイルを暗号化することができ、暗号化は、ユーザアプリケーション（ＭＬＢアプリケーションなど）によって制御することができ、例えば、ユーザアプリケーションは、クライアント証明書（例えば、認証及びトラストの連鎖、及び取消可能性を提供するためのＸ．５０９証明書）を媒体のコンテンツを解読するために使用することができるキーをダウンロードするためにＨＴＴＰセキュアソケット層（ＳＳＬ）接続が行われた時のサーバ問題に回答するために使用することができるこれらのキーチェーンに（永続的又はメモリのみのいずれかで）インストールすることができる。他の場合、プレイリストは、ユーザアプリケーション又はユーザアプリケーションと対話するサーバによって使用されるカスタムＵＲＬ方式を使用する１つ又はそれよりも多くのキーのためのＵＲＬを含むことができ、この場合、ユーザアプリケーションは、キー（新しいキーなど）を取得するために起動することができるこれらのカスタムＵＲＬ方式のためのＵＲＬプロトコルハンドラを登録することができ、それによってユーザアプリケーションは、帯域外（例えば、これらのアプリケーションバイナリで隠された）キーをトランスポートし、又はプライベートプロトコルを使用するサーバからキーを取得することができる。
図１７は、媒体サービスデーモンがユーザアプリケーションと対話することを可能にするためのソフトウエアアーキテクチャの一実施形態を示している。アーキテクチャは、媒体サービスデーモン（「メディアサーブド」）１７１０及び例示的なユーザアプリケーション、イベント媒体プロバイダ（ＥＭＰ）アプリケーション１７２０を含み、これらは、例えば、スマートフォン、携帯情報端末、デスクトップコンピュータ、ラップトップコンピュータ、タブレットデバイスのようなクライアントデバイスで実施される処理において実行可能である。クライアントデバイスの一実施形態は、図８に示す電子システム８００を使用して実施することができる。一部の実施形態において、メディアサーブド１７１０及びＥＭＰアプリケーション１７２０は両方とも、メモリ制御、メモリスペース、メモリ割り当て、ファイルシステム制御、及びネットワーク制御に関して同じ特権を共有する。従って、メディアサーブド１７１０は、ＥＭＰアプリケーション１７２０がアクセス可能なデータにアクセスすることができる。同様に、メディアサーブド１７１０は、ＥＭＰアプリケーション１７２０がアクセス不能であるデータにはアクセスすることができない。
一部の実施形態において、ＥＭＰアプリケーション１７２０は、ネットワーキングスタック１７２３にアクセスするためのカスタマイズ化ソフトウエアスタックであるコア媒体スタック１７２１を更に含み、コア媒体スタック１７２１は、ＵＲＬプロトコルハンドラ、ＥＭＰハンドラ１７２５にアクセスする。ＥＭＰアプリケーション１７２０は、１つ又はそれよりも多くのキーを取得するために起動することができるカスタムＵＲＬ方式のためのＥＭＰハンドラ１７２５を登録することができる。従って、ＥＭＰアプリケーション１７２０は、帯域外（例えば、アプリケーションバイナリに隠されている）キーをトランスポートすることができる。
一般的に、メディアサーブド１７１０及びＥＭＰアプリケーション１７２０は、本例ではＥＭＰであるコンテンツプロバイダからライブストリーミングコンテンツのための媒体ファイルをダウンロード及び再生するために互いに対話することができる。再生は、クライアントデバイス上のメディアサーブド１７１０で実行することができる。一部の実施形態において、メディアサーブド１７１０は、媒体ファイルの解読のためのキーをダウンロードすることができ、これが失敗した場合、メディアサーブド１７１０は、本例ではＥＭＰサーバ１７３０であるコンテンツプロバイダサーバからキーをダウンロードするようにＥＭＰアプリケーション１７２０に要求することができる。クライアントデバイスで実施されるＥＭＰアプリケーション１７２０は、１つ又はそれよりも多くのキーを取得するために署名することができる。通常、ＥＭＰアプリケーション１７２０は、媒体ファイルをダウンロードする前に署名及びキーを取得しておくことができる。メディアサーブド１７１０とＥＭＰアプリケーション１７２０の間の対話の一部の実施形態の詳細は、本概念を更に示すために以下に説明する。
図１７を参照すると、ＥＭＰアプリケーション１７２０は、少なくともＵＲＬ及びキーを備えたプレイリストをメディアサーブド１７１０に送信する（１）。キーを使用して、メディアサーブド１７１０は、ＵＲＬでＥＭＰによって提供される媒体ソースへのアクセス及び媒体ソースからプレイリストに指定された媒体ファイルのダウンロードを試みる。媒体ファイルは、媒体ファイルのコンテンツの許可されない視聴を防ぐために符号化又は暗号化することができる。メディアサーブド１７１０が媒体ファイルのダウンロードに失敗した場合、又はダウンロードされた媒体ファイルの復号又は解読に失敗した場合（２）、メディアサーブド１７１０は、失敗をＥＭＰアプリケーション１７２０に報告する（３）。
メディアサーブド１７１０からの失敗報告に応答して、ＥＭＰアプリケーション１７２０は、新しいキーを要求するためネットワーキングスタック１７２３にアクセスするためにそのコア媒体スタック１７２１を使用し（４）、コア媒体スタック１７２１が、新しいキーのためのＥＭＰハンドラ１７２５にアクセスする（５）。ＥＭＰハンドラ１７２５は、ＥＭＰサーバ１７３０から新しいキーを要求するために、ネットワーク（インターネットなど）を通じてＥＭＰサーバ１７３０に接続する（６）。要求に応答して、ＥＭＰサーバ１７３０は新しいキーをＥＭＰハンドラに送信する（７）。次に、ＥＭＰハンドラ１７２５は、新しいキーをコア媒体スタック１７２１に通し（８）、コア媒体スタック１７２１が、次に、新しいキーをメディアサーブド１７１０に通す（９）。
メディアサーブド１７１０がコア媒体スタック１７２１から新しいキーを受信した時に、メディアサーブド１７１０は、新しいキーを使用して再度媒体ファイルをダウンロードし新しいキーを使用してダウンロードされた媒体ファイルの復号を試みることができる（１０）。代替的に、媒体ファイルが以前にダウンロードに成功しているが、メディアサーブド１７１０が媒体ファイルの解読に失敗した場合、メディアサーブド１７１０は、新しいキーを使用して以前にダウンロードされた媒体ファイルの解読を試みることができる。メディアサーブド１７１０が新しいキーを使用して媒体ファイルのダウンロード及び復号明細書に成功した場合、ＥＭＰアプリケーション１７２０は、クライアントデバイスに復号された媒体ファイルを提示することができる。
本明細書に説明する一実施形態において、プレイリストファイルは、プレイリストファイルによって提供されるコンテンツのタイプを示すことができる。コンテンツのタイプは、プレイリストファイルのタイプを定義することができ、プレイリストファイルのタイプは、プレイリストファイルにおけるタグのパラメータで指定することができる。一実施形態において、タグは、＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ：［ＶＯＤ｜ＬＩＶＥ｜ＥＶＥＮＴ］の形式を取ることができる。このタグは、ＶＯＤ、又はＬＩＶＥ、又はＥＶＥＮＴの１つ又は１つだけを指定することができる。「ＶＯＤ」は、プレイリストファイルがビデオ・オン・デマンド（ＶＯＤ）コンテンツのためのものであることを示すことができ、「ＬＩＶＥ」は、プレイリストファイルがライブコンテンツのためのものであることを示すことができ、はっきりしない終了時間及びはっきりしない開始時間を有することができ、媒体ファイルがクライアントデバイスでのビデオのディスプレイを通じた再生のような提示のために媒体ファイルを受信したのと実質的に同時に発生させることができる。「ＥＶＥＮＴ」は、プレイリストファイルが、バスケットボールの試合又は野球の試合のようなはっきりしない終了時間を有するが明確に固定された開始時間を有することができるイベントのためのものであることを示し、媒体ファイルがクライアントデバイスでの提示のために受信したのと実質的に同時に発生させることができる。このようなタイプタグを備えたプレイリストファイルは、本明細書に説明する他のプレイリストファイルと同じとすることができ、プレイリストファイルによって示された順序で、プレイリストを受信した後のクライアントデバイスによって検索することができる複数の媒体ファイルを示すユニバーサルリソースインジケータ（ＵＲＩ）を含むことができる。プレイリストファイルは、プレイリストファイルの複数の媒体ファイルの再生に関連するパラメータ（ＶＯＤ又はＬＩＶＥなど）を有する＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥタグのような複数のタグを含むことができる。プレイリストのタイプを指定するこのタイプタグを有するプレイリストファイルは、本発明の開示に説明する他のプレイリストファイルと同じとすることができる。
プレイリストファイルにおける＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥのようなタイプタグの存在は、プレイリストが、コンテンツのタイプに矛盾しない作動の方式によることを実質的に知らせ、それによってクライアントデバイスは、プレイリスト又はコンテンツのタイプに対して最適化することができる方式でプレイリストを処理することができる。クライアントデバイスは、ＶＯＤ又はＬＩＶＥ又はＥＶＥＮＴのようなプレイリストタイプインジケータの存在を検査することができ、プレイリストタイプインジケータによる最適方式でプレイリストを処理することができる。
例えば、プレイリストタイプインジケータが「ＶＯＤ」である時に、ビデオ・オン・デマンド提示のためのプレイリストが変化せず、従って、プレイリストファイルの更新を要求する必要がないと仮定することができるので、プレイリストは、プレイリストファイルを更新しないようにクライアントデバイスを構成させることができる。従って、この状況では、クライアントデバイスは、プレイリストファイルの更新を要求しないように構成されることになる。更にプレイリストファイルがプレイリストタイプインジケータによって指定されるように「ＶＯＤ」タイプである時に、同じビデオ・オン・デマンドコンテンツの高品質の提示のためのプレイリストのような第２の変形プレイリストを受信及びこの使用に切り換えた後に、ビデオ・オン・デマンドの低品質提示のためのプレイリストのような第１の変形プレイリストを保存するようにクライアントデバイスを構成させることができ、この理由は、第１の変形プレイリストが、切り換えの後にも有効であり、ネットワーク帯域幅が低くなり、もうそれ以上第２の変形プレイリストの使用をサポートできない時のように第２の変形プレイリストファイルの使用が問題になった時に使用することができるからである。更に、プレイリストタイプインジケータが「ＶＯＤ」である時に、クライアントデバイスは、プレイリストが完全であることを示すＥＮＤＬＩＳＴタグ又は他のタグに対してプレイリストファイルを調べるようにクライアントデバイスを構成することができ、このようなタグがプレイリストファイルからなくなっている場合、クライアントデバイスは、エラーを有するとしてプレイリストにマーク付けすることができる。
プレイリストタイプインジケータが「ＬＩＶＥ」である時に、クライアントデバイスは、更新されたプレイリストファイルを繰返し要求するように構成することができる。プレイリストタイプインジケータが「ＥＶＥＮＴ」である時に、クライアントデバイスは、（ａ）更新されたプレイリストの最新の部分だけをロードする（それによって更新されたプレイリストの古い部分の受信を防ぐ）又は（ｂ）更新されたプレイリストの最新の部分だけを構文解析する（それによって更新されたプレイリストの古い部分の再構文解析を防ぐ）のいずれかを実行するように構成することができる。
図２０は、タイプインジケータを含む機能を有するプレイリストを処理することができる一実施形態による方法の例を示している。作動２００１で、プレイリストをクライアントデバイスによって受信することができ、作動２００３で、クライアントデバイスは、プレイリストファイルが「ＶＯＤ」又は「ＬＩＶＥ」又は「ＥＶＥＮＴ」のようなタイプインジケータを含むか否かを判断することができる。これらの例示的なタイプの部分集合を一実施形態において使用することができること及び本明細書に説明されていない他のタイプも一部の実施形態で使用することができることが認められるであろう。プレイリストがタイプインジケータを含むとクライアントデバイスが判断した場合、作動２００７で、クライアントデバイスは、本明細書に説明する又は以下に更に説明する図２１に提示されている方法のように必要に応じてタイプインジケータを使用してプレイリストを処理する。プレイリストファイルがタイプインジケータを含まないことをクライアントデバイスが作動２００３で判断した場合、作動２００５で、クライアントデバイスは、プレイリストタイプインジケータを使用することなくプレイリストを処理する（例えば、図２１に示す最適化は実施されない）。
図２１は、本発明の一実施形態によるプレイリストタイプインジケータの様々なタイプの１つ又はそれよりも多くの使用例を示している。図２１に示す方法は、３つの異なるタイプインジケータの可能な存在を仮定し、プレイリストファイルに対するプレイリストタイプを指定するために、より少ないタイプインジケータを利用することができ、又はより多くのタイプインジケータを利用することができることが認められるであろう。代替の実施形態は、より少ない作動又はより多い作動又は図２１に示すものとは異なる順序の作動を有することができることは認められるであろう。作動２１０１で、クライアントデバイスは、プレイリストファイルがプレイリストタイプインジケータを含むか否かを判断する。何もない場合、クライアントデバイスは、作動２１０３で、タイプインジケータの使用なしに作動し、本発明の開示の残りの部分に説明するようにプレイリストファイルを処理する。他方、プレイリストタイプインジケータが存在する場合、作動２１０５で、クライアントデバイスは、タイプインジケータが「ＬＩＶＥ」インジケータであるか否かを判断し、この場合、クライアントデバイスは、作動２１０７で、プレイリストファイルを繰返し更新するように設定される。クライアントデバイスが作動２１０５でタイプインジケータが「ＬＩＶＥ」インジケータではないと判断した場合、タイプインジケータが「ＶＯＤ」タイプであるか否かを作動２１０９で判断する。タイプインジケータが「ＶＯＤ」である場合、クライアントデバイスは、作動２１１１で、プレイリストファイルを更新しないように設定され、クライアントデバイスは、作動２１１３及び２１１５を実行することができる。作動２１１３で、クライアントデバイスは、以前に使用されたプレイリストに戻さなければならない場合に、別の変形プレイリストを使用しながら以前に使用された変形プレイリストを保存することができる。例えば、クライアントは、第１の変形プレイリストを保存することができ、これは、同じビデオ・オン・デマンドコンテンツに対する第２の変形プレイリストを受信及びこの使用に切り換えた後に、ビデオ・オン・デマンドの低品質又は低ビットレート提示のプレイリストとすることができる第１の変形プレイリストを保存することができ、この理由は、第１の変形プレイリストが、切り換え後に有効であり、第２の変形プレイリストの使用がネットワーク帯域幅が低くなった時のように問題になった場合に使用することができるからである。作動２１１５で、クライアントデバイスは「ＥＮＤＬＩＳＴ」タグ又は類似のタグを検査することができ、プレイリストファイル内に何も見つからなかった場合、クライアントデバイスは、作動２１１７で、一実施形態においてエラーを有するとしてプレイリストファイルにマーク付けすることができる。
作動２１０９でプレイリストファイルが「ＶＯＤ」タイプインジケータを含まないことが判断された場合、クライアントデバイスは、プレイリストファイルが「ＥＶＥＮＴ」タイプインジケータを含むか否かを作動２１１９で判断し、含む場合、作動２１２３を実行し、そうでなければ、プレイリストファイルがタイプインジケータの使用なしに処理される又は本明細書に説明されていない異なるタイプインジケータの使用によって処理される作動２１２１を実行する。作動２１２３で、クライアントデバイスは、更新されたプレイリストを要求した時に、現在の再生位置を超えた更新されたプレイリストの最新部分だけをリロードするか又は全ての更新されたプレイリストをロードするが現在の再生位置を超えた更新されたプレイリストの最新部分だけを構文解析するかのいずれかを実行することができる。従って、クライアントデバイスは、クライアントデバイスで既に提示されているプレイリストの部分の処理を防ぐことによって又はネットワークを通じて更新されたプレイリストの古い部分の受信を防ぐことにより、更新されたプレイリストを知的に処理することができる。
一実施形態において、プレイリストファイルに指定された媒体ファイルのデータアクセスに関する統計値又は媒体ファイルを受信した時に発生するネットワークエラーに関する統計値を格納するようにクライアントデバイスを構成することができる。これらの統計値は、ＡＰＩ（アプリケーションプログラムインタフェース）を通じてクライアントアプリケーションに利用することができるようなり、ネットワークエラーに関する情報又は媒体ファイルへのアクセスに関する情報の提示を可能にする。この情報は、例えば、ディスプレイがＶＯＤ又はライブ番組のような変形ストリーム間で切り換わった回数とすることができる。図２２は、ＡＰＩを通じて媒体サーバアプリケーションからクライアントアプリケーションに統計値を提供することができるアーキテクチャの例を示している。このアーキテクチャの場合、媒体サーバ２２０１は、プレイリストファイルを要求及び受信しプレイリストファイルを処理しコンテンツをクライアントアプリケーション２２０３に提供することができる。媒体サーバアプリケーション２２０１は、１つ又はそれよりも多くのログに統計値２２０５を格納する１つ又はそれよりも多くのログを作成することができる。クライアントアプリケーションは、これが要求する時又はユーザによって要求される時に、ＡＰＩインタフェース２２０７を通じた呼出しを実行することによって統計値に関する情報を提示することができ、それに応じて、媒体サーバ２２０１は、要求された統計値を検索し、これらの統計値をＡＰＩインタフェース２２０７を通じてクライアントアプリケーション２２０３に提供することができる。媒体サーバ２２０１は、ストリーミングコンテンツを再生又は提供している間に統計値を収集することができ、統計値をオンデマンドでクライアントアプリケーション２２０３からＡＰＩインタフェース２２０７を通じてクライアントアプリケーション２２０３に提供することができる。クライアントアプリケーション２２０３は、統計値ログを集約サービスに提供する働きをすることができ、ログからの情報の報告のタイミング及び頻度を制御することができる。システムは、統計値を格納するための１つ又はそれよりも多くのログを有することができ、一実施形態において、ログは、Ｗ３Ｃ拡張ログファイルフォーマットによることができる。一実施形態において、ログの２つのタイプ、すなわち、アクセスログとエラーログを提供することができる。
アクセスログでは、クライアントが変形を切り換え、探索し、又はサーバＩＰアドレスが変わる度に新しいログエントリ（行）を生成することができる。最後の行は、現在の変形に対する統計値を含むことができる。以下のフィールドは、アクセスログで提供することができる。
Figure 2016026427
初期再生待ち時間に関心のあるクライアントは、再生が開始された日の時間を独自に報告することができる。これは、起動持続時間を計算するために第１の変形の日付／時間と組み合わせて使用することができる。ログサーバリディレクトも実施形態に含むことができる。エラーログでは、ネットワークエラーに遭遇する度に新しいログエントリ（行）を生成することができる。以下のフィールドは、エラーログで提供することができる。
Figure 2016026427
図８は、電子システムの一実施形態のブロック図である。図８に示す電子システムは、例えば、デスクトップコンピュータシステム、ラップトップコンピュータシステム、セルラー電話、セルラー対応ＰＤＡを含む携帯情報端末（ＰＤＡ）、セットトップボックス、娯楽システム又は他の消費者電子デバイスを含む電子システムの範囲（有線又は無線のいずれか）を表すものとする。代替の電子システムは、より多い、より少ない、及び／又は異なる構成要素を含むことができる。図８の電子システムは、クライアントデバイス及び／又はサーバデバイスを提供するために使用することができる。
電子システム８００は、情報を伝送するためのバス８０５又は他の通信デバイス、及び情報を処理することができるバス８０５に結合されたプロセッサ８１０を含む。電子システム８００が単一のプロセッサによって示されているが、電子システム８００は、複数のプロセッサ及び／又はコプロセッサを含むことができる。電子システム８００は、バス８０５に結合されたランダムアクセスメモリ（ＲＡＭ）又は他の動的格納デバイス８２０（主メモリとも呼ぶ）を更に含むことができ、プロセッサ８１０によって実行することができる情報及び命令を格納することができる。主メモリ８２０はまた、プロセッサ８１０による命令の実行中に一時的変数又は他の中間情報を格納するために使用することができる。
電子システム８００は、プロセッサ８１０のための静的情報及び命令を格納することができるバス８０５に結合された読取専用メモリ（ＲＯＭ）及び／又は他の静的格納デバイス８３０を含むことができる。データ格納デバイス８４０は、情報及び命令を格納するためにバス８０５に結合することができる。フラッシュメモリ又は磁気ディスク又は光学ディスク及び対応するドライブのようなデータ格納デバイス８４０は、電子システム８００に結合することができる。
電子システム８００は、ユーザに情報を表示するために、ブラウン管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）のような表示デバイス８５０にバス８０５を通じて結合することができる。電子システム８００は、プロセッサ８１０に情報及び指令選択を伝送するためにバス８０５に結合することができる英数字及び他のキーを含む英数字入力デバイス８６０を含むことができる。ユーザ入力デバイスの別のタイプは、方向情報及び指令選択をプロセッサ８１０に伝送してディスプレイ８５０上のカーソルの動きを制御するためのタッチパッド、マウス、トラックボール、又はカーソル方向キーのようなカーソル制御８７０である。
電子システム８００は、ローカルエリアネットワークのようなネットワークへのアクセスを提供するための１つ又はそれよりも多くのネットワークインタフェース８８０を更に含むことができる。ネットワークインタフェース８８０は、例えば、１つ又はそれよりも多くのアンテナを表すことができるアンテナ８８５を有する無線ネットワークインタフェースを含むことができる。電子システム８００は、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、及びセルラー電話インタフェースの組合せのような複数の無線ネットワークインタフェースを含むことができる。ネットワークインタフェース８８０は、例えば、イーサネットケーブル、同軸ケーブル、光ファイバケーブル、シリアルケーブル、又はパラレルケーブルとすることができるネットワークケーブル８８７を通じて遠隔デバイスと通信するための有線ネットワークインタフェースを含むことができる。
一実施形態において、ネットワークインタフェース８８０は、例えば、ＩＥＥＥ ８０２．１１ｂ及び／又はＩＥＥＥ ８０２．１１ｇ規格によることにより、ローカルエリアネットワークへのアクセスを提供することができ、及び／又は無線ネットワークインタフェースが、例えば、Ｂｌｕｅｔｏｏｔｈ規格によることにより、パーソナルエリアネットワークへのアクセスを提供することができる。他の無線ネットワークインタフェース及び／又はプロトコルもサポートすることができる。
無線ＬＡＮ規格を通じた通信に加えて又は代替的に、ネットワークインタフェース８８０は、例えば、時分割多元接続（ＴＤＭＡ）プロトコル、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）プロトコル、符号分割多元接続（ＣＤＭＡ）プロトコル、及び／又は無線通信プロトコルのいずれかの他のタイプを使用して無線通信を提供することができる。
１つ又はそれよりも多くのアプリケーションプログラミングインタフェース（ＡＰＩ）を一部の実施形態で使用することができる。ＡＰＩは、プログラムコード構成要素又はハードウエア構成要素によって実施されるインタフェース（以下「ＡＰＩ実施構成要素」）であり、それによって異なるプログラムコード構成要素又はハードウエア構成要素（以下「ＡＰＩ呼出し構成要素」）が、ＡＰＩ実施構成要素によって提供される１つ又はそれよりも多くの機能、方法、手順、データ構造、クラス、及び／又は他のサービスにアクセスしてそれを使用することができる。ＡＰＩは、ＡＰＩ呼出し構成要素とＡＰＩ実施構成要素の間で送られる１つ又はそれよりも多くのパラメータを定義することができる。
ＡＰＩにより、ＡＰＩ呼出し構成要素の開発者（第三者開発者とすることができる）は、ＡＰＩ実施構成要素によって提供される指定された機能を利用することができる。１つのＡＰＩ呼出し構成要素を存在させることができ、又は１つよりも多いこのような構成要素を存在させることができる。ＡＰＩは、コンピュータシステム又はプログラムライブラリがアプリケーションからのサービスに対する要求をサポートするために提供するソースコードインタフェースとすることができる。オペレーティングシステム（ＯＳ）は、これらのＡＰＩの１つ又はそれよりも多くをＯＳで実施されるアプリケーションが呼び出せるようにする複数のＡＰＩを有することができ、サービス（プログラムライブラリなど）は、サービスを使用するアプリケーションがこれらのＡＰＩの１つ又はそれよりも多くを呼び出せるようにする複数のＡＰＩを有することができる。ＡＰＩは、アプリケーションが作られた時に翻訳又はコンパイルすることができるプログラミング言語に関して指定することができる。
一部の実施形態において、ＡＰＩ実施構成要素は、１つよりも多いＡＰＩを提供することができ、各々は、ＡＰＩ実施構成要素によって実施される機能の様々な態様にアクセスする様々な態様又はその異なるビューを提供する。例えば、ＡＰＩ実施構成要素の１つのＡＰＩは、機能の第１のセットを提供することができ、第三者開発者に露出することができ、ＡＰＩ実施構成要素の別のＡＰＩは、隠す（露出させない）ことができ、機能の第１のセットの部分集合を提供し、更に機能の第１のセットにはない試験又はデバッグ機能のような機能の別のセットを提供することができる。他の実施形態において、ＡＰＩ実施構成要素は、それ自体が、元にあるＡＰＩを通じて１つ又はそれよりも多くの他の構成要素を呼び出すことができ、従って、ＡＰＩ呼出し構成要素及びＡＰＩ実施構成要素の両方とすることができる。
ＡＰＩは、ＡＰＩ実施構成要素の指定された機能にアクセスしてそれを使用する時にＡＰＩ呼出し構成要素が使用する言語及びパラメータを定義する。例えば、ＡＰＩ呼出し構成要素は、ＡＰＩによって露出された１つ又それよりも多くのＡＰＩ呼出し又は起動（例えば、機能又は方法呼出しによって実施される）を通じてＡＰＩ実施構成要素の指定された機能にアクセスし、ＡＰＩ呼出し又は起動を通じてパラメータを使用するデータ及び制御情報を転送する。ＡＰＩ実施構成要素は、ＡＰＩ呼出し構成要素からのＡＰＩ呼出しに応答してＡＰＩを通じて値を戻すことができる。ＡＰＩはＡＰＩ呼出しの構文及び結果を定義する（例えば、ＡＰＩ呼出しを起動する方法及びＡＰＩ呼出しが実行すること）が、ＡＰＩは、ＡＰＩ呼出しによって指定された機能をＡＰＩ呼出しがどのように達成するかを明らかにしなくてもよい。様々なＡＰＩ呼出しが、呼出し（ＡＰＩ呼出し構成要素）とＡＰＩ実施構成要素の間で１つ又はそれよりも多くのアプリケーションプログラミングインタフェースを通じて転送される。ＡＰＩ呼出しの転送は、機能呼出し又はメッセージの発行、初期化、起動、呼出し、受信、返答、又は応答を含むことができ、換言すると、転送は、ＡＰＩ呼出し構成要素又はＡＰＩ実施構成要素のいずれかによる作動を表すことができる。ＡＰＩの機能呼出し又は他の起動は、パラメータリスト又は他の構造を通じて１つ又はそれよりも多くのパラメータを送信又は受信することができる。パラメータは、定数、キー、データ構造、オブジェクト、オブジェクトクラス、変数、データタイプ、ポインタ、アレイ、リスト又は機能へのポインタ、又はＡＰＩを通じて送られるデータ又は他の項目を参照する方法又は別の方式とすることができる。
更に、データタイプ又はクラスをＡＰＩによって提供及びＡＰＩ実施構成要素によって実施することができる。従って、ＡＰＩ呼出し構成要素は、ＡＰＩで提供された定義を使用することによってこのようなタイプ又はクラスの定数値を使用又は例示化するために、変数を宣言してポインタを使用することができる。
一般的に、ＡＰＩは、ＡＰＩ実施構成要素によって提供されたサービス又はデータにアクセスするか又はＡＰＩ実施構成要素によって提供される作動又はコンピュータ計算の成果を初期化するために使用することができる。一例として、ＡＰＩ実施構成要素及びＡＰＩ呼出し構成要素の各々は、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、又は他のモジュールのいずれか１つとすることができる（ＡＰＩ実施構成要素及びＡＰＩ呼出し構成要素は、同じか又は互いに異なるモジュールのタイプとすることができることを理解されたい）。ＡＰＩ実施構成要素は、場合によっては、ファームウエア、マイクロコード、又は他のハードウエア論理で少なくとも一部実施することができる。一部の実施形態において、ＡＰＩにより、クライアントプログラムは、ソフトウエア開発者Ｋｉｔ（ＳＤＫ）ライブラリによって提供されるサービスを使用することができる。他の実施形態において、アプリケーション又は他のクライアントプログラムは、アプリケーションフレームワークによって提供されるＡＰＩを使用することができる。これらの実施形態において、アプリケーション又はクライアントプログラムは、ＳＤＫによって提供される及びＡＰＩによって提供される機能又は方法の呼出しを組み込むことができ、又はＳＤＫに定義されＡＰＩによって提供されるデータタイプ又はオブジェクトを使用することができる。アプリケーションフレームワークは、これらの実施形態でフレームワークによって定義された様々なイベントに応答するプログラムのための主イベントループを提供することができる。ＡＰＩにより、アプリケーションは、アプリケーションフレームワークを使用してイベント及びイベントへの応答を指定することができる。一部の実施では、ＡＰＩ呼出しは、入力機能及び状態、出力機能及び状態、処理容量、電力状態、格納容量及び状態、通信容量のような態様に関するものを含むハードウエアデバイスの機能又は状態をアプリケーションに報告することができ、ＡＰＩは、ハードウエア構成要素で一部実施されるファームウエア、マイクロコード、又は他の低レベル論理によって一部実施することができる。
ＡＰＩ呼出し構成要素は、ローカル構成要素（すなわち、ＡＰＩ実施構成要素と同じデータ処理システム上の）又はリモート構成要素（すなわち、ＡＰＩ実施構成要素とは異なるデータ処理システム上の）とすることができ、ネットワーク上でＡＰＩを通じてＡＰＩ実施構成要素と通信する。ＡＰＩ実施構成要素は、ＡＰＩ呼出し構成要素として作動させることができ（すなわち、ＡＰＩ実施構成要素は、異なるＡＰＩ実施構成要素によって露出されたＡＰＩにＡＰＩ呼出しを実行することができる）、更にＡＰＩ呼出し構成要素は、異なるＡＰＩ呼出し構成要素に露出されたＡＰＩを実施することによってＡＰＩ実施構成要素として作動させることができる。
ＡＰＩにより、異なるプログラミング言語で書かれた複数のＡＰＩ呼出し構成要素は、ＡＰＩ実施構成要素と通信することができるが（従って、ＡＰＩはＡＰＩ実施構成要素とＡＰＩ呼出し構成要素の間で呼出し及び返答を変換するための機能を含むことができる）、しかし、ＡＰＩは、特定のプログラミング言語に関して実施することもできる。ＡＰＩ呼出し構成要素は、一実施形態において、ＯＳプロバイダからＡＰＩのセット及び接続プロバイダからのＡＰＩの別のセット及び別のプロバイダ（例えば、ソフトウエアライブラリのプロバイダ）又はＡＰＩの別のセットのクリエータからのＡＰＩの別のセットのような異なるプロバイダからのＡＰＩを呼び出すことができる。
図１８は、本発明の一部の実施形態で使用することができる例示的なＡＰＩアーキテクチャを示すブロック図である。図１８に示すように、ＡＰＩアーキテクチャ１８００は、ＡＰＩ１８２０を実施するＡＰＩ実施構成要素１８１０（オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、ソフトウエア又は他のモジュールなど）を含む。ＡＰＩ１８２０は、ＡＰＩ呼出し構成要素１８３０によって使用することができるＡＰＩ実施構成要素の１つ又はそれよりも多くの機能、方法、クラス、オブジェクト、プロトコル、データ構造、フォーマット、及び／又は他の機能を指定する。ＡＰＩ１８２０は、ＡＰＩ実施構成要素における機能がＡＰＩ呼出し構成要素からパラメータを受信する方法及び機能がＡＰＩ呼出し構成要素に結果を戻す方法を指定する少なくとも１つの呼出し規約を指定することができる。ＡＰＩ呼出し構成要素１８３０（例えば、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、ソフトウエア、又は他のモジュールなど）は、ＡＰＩ１８２０によって指定されたＡＰＩ実施構成要素１８１０の機能にアクセスしてそれを使用するために、ＡＰＩ１８２０を通じてＡＰＩ呼出しを実行する。ＡＰＩ実施構成要素１８１０は、ＡＰＩ呼出しに応答してＡＰＩ１８２０を通じてＡＰＩ呼出し構成要素１８３０に値を戻すことができる。
ＡＰＩ実施構成要素１８１０は、ＡＰＩ１８２０を通じて指定されず、かつＡＰＩ呼出し構成要素１８３０に利用可能ではない付加的な機能、方法、クラス、データ構造、及び／又は他の機能を含むことができることは認められるであろう。ＡＰＩ呼出し構成要素１８３０は、ＡＰＩ実施構成要素１８１０と同じシステム上にあるものとすることができ、又は遠隔に配置することができてネットワークを通じてＡＰＩ１８２０を使用してＡＰＩ実施構成要素１８１０にアクセスすることを理解すべきである。図１８は、ＡＰＩ１８２０と対話する単一のＡＰＩ呼出し構成要素１８３０を示しているが、ＡＰＩ呼出し構成要素１８３０とは異なる言語（又は同じ言語）で書くことができる他のＡＰＩ呼出し構成要素がＡＰＩ１８２０を使用することができることを理解すべきである。
ＡＰＩ実施構成要素１８１０、ＡＰＩ１８２０、及びＡＰＩ呼出し構成要素１８３０は、機械（例えば、コンピュータ又は他のデータ処理システム）によって可読の形式で情報を格納するためのいずれかの機構を含む機械可読非一時的ストレージ媒体に格納することができる。例えば、機械可読媒体は、磁気ディスク、光学ディスク、ランダムアクセスメモリ；読取専用メモリ、フラッシュメモリデバイスなどを含む。
図１９（「ソフトウエアスタック」）の例示的な実施形態において、アプリケーションは、いくつかのサービスＡＰＩを使用してサービス１又は２に、かついくつかのＯＳ ＡＰＩを使用してオペレーティングシステム（ＯＳ）に呼出しを実行することができる。サービス１及び２は、いくつかのＯＳ ＡＰＩを使用してＯＳに呼出しを実行することができる。
サービス２は、２つのＡＰＩを有し、そのうちの１つ（サービス２ＡＰＩ１）は、アプリケーション１から呼出しを受信してアプリケーション１に値を戻し、他（サービス２ＡＰＩ２）は、アプリケーション２から呼出しを受信してアプリケーション２に値を戻すことに注意されたい。サービス１（例えば、ソフトウエアライブラリとすることができる）は、ＯＳ ＡＰＩ１に呼出しを実行して、ＯＳ ＡＰＩ１から戻された値を受信し、サービス２（例えば、ソフトウエアライブラリとすることができる）は、ＯＳ ＡＰＩ１及びＯＳ ＡＰＩ２の両方に呼出しを実行して、ＯＳ ＡＰＩ１及びＯＳ ＡＰＩ２の両方から戻された値を受信する。アプリケーション２は、ＯＳ ＡＰＩ２に呼出しを実行して、ＯＳ ＡＰＩ２から戻された値を受信する。
本明細書における「一実施形態」又は「実施形態」への参照は、実施形態に関して説明する特定の機能、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な箇所における「一実施形態では」という句の出現は、必ずしも全て同じ実施形態を示すものではない。
以上の明細書では、本発明をその特定の実施形態に関して説明した。しかし、本発明の広範な精神及び範囲から逸脱することなく様々な修正及び変形を本明細書に行うことができることは明らかであろう。従って、本明細書及び図面は、制限の意味ではなく例示的な意味に捉えるべきである。
２００１ クライアントデバイスでプレイリストファイルを受信する作動
２００３ プレイリストファイルがプレイリストタイプインジケータを含むか否かを判断する作動
２００５ タイプインジケータの使用なしにプレイリストファイルを処理する作動
２００７ 必要に応じてタイプインジケータを使用してプレイリストを処理する作動
付録
以下の付録は、本発明の特定の実施形態によるプロトコルの草案の明細書である。本付録における特定のキーワードの使用（例えば、ＭＵＳＴ（ねばならない）、ＭＵＳＴ ＮＯＴ（してはならない）、ＳＨＡＬＬ（すべきだ）、ＳＨＡＬＬ ＮＯＴ（すべきではない）など）の使用は、この特定の実施形態に適用され、本発明の開示に説明する他の実施形態には適用されない。
ＨＴＴＰライブストリーミング
ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０６
要約
本文書は、マルチメディアデータの無制限ストリームを転送するためのプロトコルを説明する。本文書は、ファイルのデータフォーマット及びストリームのサーバ（送信者）及びクライアント（受信者）によって行われるアクションを指定する。本文書は、このプロトコルのバージョン３を説明する。
コンテンツの表
１．序文
２．要約
３．プレイリストファイル
３．１．序文
３．２．属性リスト
３．３．新しいタグ
３．３．１．ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
３．３．２．ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
３．３．３．ＥＸＴ−Ｘ−ＫＥＹ
３．３．４．ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
３．３．５．ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
３．３．６．ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ
３．３．７．ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
３．３．８．ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
３．３．９．ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
３．３．１０．ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ
４．媒体ファイル
５．キーファイル
５．１．序文
５．２．ＡＥＳ−１２８のためのＩＶ
６．クライアント／サーバアクション
６．１．序文
６．２．サーバ処理
６．２．１．序文
６．２．２．スライディングウィンドウプレイリスト
６．２．３．媒体ファイルの暗号化
６．２．４．変形ストリームの提供
６．３．クライアント処理
６．３．１．序文
６．３．２．プレイリストファイルのローディング
６．３．３．プレイリストファイルの再生
６．３．４．プレイリストファイルのリローディング
６．３．５．ロードする次のファイルの判断
６．３．６．暗号化媒体ファイルの解読
７．プロトコルバージョンの互換性
８．実施例
８．１．序文
８．２．単純なプレイリストファイル
８．３．ＨＴＴＰＳを使用したスライディングウィンドウプレイリスト
８．４．暗号化媒体ファイルを備えたプレイリストファイル
８．５．変形プレイリストファイル
９．セキュリティ配慮
１０．参考文献
１０．１．基準参考文献
１０．２．情報参考文献
１．序文
本文書は、マルチメディアデータの無制限ストリームを転送するためのプロトコルを説明する。プロトコルは、媒体データの暗号化及びストリームの代替のバージョン（ビットレートなど）の供給をサポートする。媒体データは、作成された後に直ちに転送することができ、実質的にリアルタイムで再生することができる。データは、通常、ＨＴＴＰを通じて運ばれる［ＲＦＣ２６１６］。
ＨＴＴＰのような関連の規格を説明する外部参考文献は段落１１に示している。
２．要約
マルチメディア提示は、プレイリストファイルへのＵＲＩ［ＲＦＣ３９８６］によって指定され、これは、媒体ＵＲＩ及び情報タグの順序付けられたリストである。各媒体ＵＲＩは、単一の連続ストリームのセグメントである媒体ファイルを示している。
ストリームを再生するために、クライアントは、最初にプレイリストファイルを取得し、次に、プレイリストの各媒体ファイルを取得及び再生する。クライアントは、付加的なセグメントを見出すためにこの文書に説明するようにプレイリストファイルをリロードする。
本文書におけるキーワード「ＭＵＳＴ（ねばならない）」、「ＭＵＳＴ ＮＯＴ（してはならない）」、「ＲＥＱＵＩＲＥＤ（要求される）」、「ＳＨＡＬＬ（すべきだ）」、「ＳＨＡＬＬ ＮＯＴ（すべきでない）」、「ＳＨＯＵＬＤ（すべきだ）」、「ＳＨＯＵＬＤ ＮＯＴ（すべきでない）」、「ＲＥＣＯＭＭＥＮＤＥＤ（推薦される）」、「ＭＡＹ（することができる）」、及び「ＯＰＴＩＯＮＡＬ（任意的）」は、ＲＦＣ２１１９［ＲＦＣ２１１９］で説明するように解釈すべきである。
３．プレイリストファイル
３．１．序文
プレイリストは、拡張Ｍ３Ｕプレイリストファイル［Ｍ３Ｕ］でなくてはならない。この文書は、付加的なタグを定義することによってＭ３Ｕファイルフォーマットを拡張する。
Ｍ３Ｕプレイリストは、個々の行から構成されるテキストファイルである。行は、単一のＬＦ文字又はＬＦ文字の後に続くＣＲ文字のいずれかによって終わる。各行は、ＵＲＩ、空白であり、又はコメント文字「＃」から始まる。空白行は無視される。空白は、これが明示的に指定される要素を除いて存在してはならない。
ＵＲＩ行は、媒体ファイル又は変形プレイリストファイルを識別する（段落３．３．８を参照されたい）。
ＵＲＩは、相対的とすることができる。相対的なＵＲＩは、これを含むプレイリストファイルのＵＲＩに対して解決すべきである。
コメント文字「＃」で始まる行は、コメント又はタグのいずれかである。タグは、＃ＥＸＴから始まる。「＃」で始まる全ての他の行はコメントであり、無視すべきである。
プレイリストファイルの持続時間は、その中の媒体ファイルの持続時間の和である。
名称が．ｍ３ｕ８で終わる及び／又はＨＴＴＰコンテンツタイプ「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ａｐｐｌｅ．ｍｐｅｇｕｒｌ」を有するＭ３Ｕプレイリストファイルは、ＵＴＦ−８［ＲＦＣ３６２９］で符号化される。名称が．ｍ３ｕで終わる及び／又はＨＴＴＰコンテンツタイプ［ＲＦＣ２６１６］「ａｕｄｉｏ／ｍｐｅｇｕｒｌ」を有するファイルは、ＵＳ−ＡＳＣＩＩ［ＵＳ_ＡＳＣＩＩ］で符号化される。
プレイリストファイルは、ｍ３ｕ８で終わる及び／又はコンテンツタイプ「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ａｐｐｌｅ．ｍｐｅｇｕｒｌ」（ＨＴＴＰを通じて転送される場合）を有する名称を持たなくてはならず、又は．ｍ３ｕで終わる及び／又はＨＴＴＰコンテンツタイプ「ａｕｄｉｏ／ｍｐｅｇｕｒｌ」（互換性のため）を有する名称を持たなくてはならない。
拡張Ｍ３Ｕファイルフォーマットは、ＥＸＴＭ３Ｕ及びＥＸＴＩＮＦの２つのタグを定義する。拡張Ｍ３Ｕファイルは、＃ＥＸＴＭ３Ｕでなくてはならないその第１の行によって基本Ｍ３Ｕフォーマットとは区別される。
ＥＸＴＩＮＦは、それに続くＵＲＩによって識別される媒体ファイルを説明する記録マーカである。各媒体ファイルＵＲＩは、ＥＸＴＩＮＦタグが先行すべきである。そのフォーマットは以下の通りである。
＃ＥＸＴＩＮＦ：＜持続時間＞、＜タイトル＞
「持続時間」は、媒体ファイルの持続時間を秒で指定する整数又は浮動小数点数である。整数の持続時間は、最も近い整数に丸めるべきである。持続時間は、プレイリストファイルのプロトコルバージョンが３未満である場合は整数でなくてはならない。コンマの後に続く行の残りは、媒体ファイルのタイトルであり、媒体セグメントの任意的な人間が読める情報タイトルである。
この文書は、以下の新しいタグを定義する：ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ、ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ、ＥＸＴ−Ｘ−ＫＥＹ、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ、ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ、ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ、ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ、ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ、及びＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ。
３．２．属性のリスト
特定の拡張Ｍ３Ｕタグは、属性リストである値を有する。属性リストは、空白を持たない属性／値の対のコンマで区切られたリストである。
属性／値対は、以下の構文を有する。
ＡｔｔｒｉｂｕｔｅＮａｍｅ＝ＡｔｔｒｉｂｕｔｅＶａｌｕｅ
ＡｔｔｒｉｂｕｔｅＮａｍｅは、セット［Ａ−Ｚ］からの文字を含む引用符のない文字列である。
ＡｔｔｒｉｂｕｔｅＶａｌｕｅは、以下のうちの１つである。
・十進数−整数：十進法演算で整数を表すセット［０−９］からの文字の引用符のない文字列。
・１６進数−整数：０ｘ又は０Ｘが前に付いた１６進数演算で整数を表すセット［０−９］及び［Ａ−Ｆ］からの文字の引用符のない文字列。
・十進数−浮動小数点：十進数演算で浮動小数点数を表すセット［０−９］及び「．」からの文字の引用符のない文字列。
・引用符付き文字列：二重引用符（“）の対内の文字の文字列。文字列で許可される文字のセット及び特別な文字を逃がすためのいずれの規則も属性定義によって指定されるが、いずれの二重引用符（”）文字及びいずれの復帰改行又は改行も、常にエスケープシーケンスによって置換される。
・列挙−文字列：属性によって明示的に定義されたセットからの引用符のない文字の文字列。列挙−文字列は、二重引用符（“）、コンマ（，）、又は空白を決して含まない。
・十進数−解像度：水平及び垂直ピクセル寸法を示す「ｘ」文字によって分離された２つの十進数−整数。
所定のＡｔｔｒｉｂｕｔｅＮａｍｅに対するＡｔｔｒｉｂｕｔｅＶａｌｕｅのタイプは、属性定義によって指定される。
所定のＡｔｔｒｉｂｕｔｅＮａｍｅは、所定の属性リストで１回よりも多く現れてはならない。
認識されなかったＡｔｔｒｉｂｕｔｅＮａｍｅを有する属性／値の対は、クライアントによって無視すべきである。
認識されなかった値を含むタイプ列挙文字列の属性／値対は、クライアントによって無視すべきである。
３．３．新しいタグ
３．３．１．ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ
ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグは、最大媒体ファイル持続時間を指定する。プレイリストファイルの各媒体ファイルのＥＸＴＩＮＦ持続時間は、ターゲット持続時間未満か又はこれに等しくなくてはならない。このタグは、プレイリストファイルに一度出現すべきである。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：＜ｓ＞
ここで、ｓは、ターゲット持続時間を秒で示す整数である。
３．３．２．ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ
プレイリストの各媒体ファイルＵＲＩは、固有の整数シーケンス番号を有する。ＵＲＩのシーケンス番号は、それに先行するＵＲＩのシーケンス番号に１を加えたものに等しい。ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグは、プレイリストファイルに現れる最初のＵＲＩのシーケンス番号を示す。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：＜番号＞
プレイリストファイルは、１つよりも多いＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含んではならない。プレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合、プレイリストの第１のＵＲＩのシーケンス番号は、０と考えるべきである。
媒体ファイルのシーケンス番号は、そのＵＲＩに出現する必要はない。
ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを処理する場合の情報については、段落６．３．２及び段落６．３．５．を参照されたい。
３．３．３．ＥＸＴ−Ｘ−ＫＥＹ
媒体ファイルは、暗号化することができる。ＥＸＴ−Ｘ−ＫＥＹタグは、それに続く媒体ファイルを解読するのに必要な情報を提供する。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＫＥＹ：＜ａｔｔｒｉｂｕｔｅ−ｌｉｓｔ＞
以下の属性が定義される。
方法属性は、暗号化方法を指定する。これは、タイプ列挙文字列である。２つの方法、ＮＯＮＥ及びＡＥＳ−１２８が定義される。
ＮＯＮＥの暗号化方法は、媒体ファイルが暗号化されないことを意味する。暗号化方法がＮＯＮＥである場合、ＵＲＩ及びＩＶ属性は存在してはならない。
ＡＥＳ−１２８の暗号化方法は、媒体ファイルが、１２８ビットキー及びＰＫＣＳ７パディング［ＲＦＣ５６５２］を備えた高度暗号化規格［ＡＥＳ_１２８］を使用して暗号化されることを意味する。暗号化方法がＡＥＳ−１２８である場合、ＵＲＩ属性が存在すべきである。ＩＶ属性が存在することができ、段落５．２を参照されたい。
ＵＲＩ属性は、キーを取得する方法を指定する。その値は、キーに対するＵＲＩ［ＲＦＣ３９８６］を含む引用符付き文字列である。
ＩＶ属性は、存在するとすれば、キーと共に使用される初期化ベクトルを指定する。その値は、１６進数の整数である。ＩＶ属性は、プロトコルバージョン２で出現する。
新しいＥＸＴ−Ｘ−ＫＥＹは、いずれの前のＥＸＴ−Ｘ−ＫＥＹにも優先する。
プレイリストファイルがＥＸＴ−Ｘ−ＫＥＹタグを含まない場合、媒体ファイルは暗号化されない。
キーファイルのフォーマットに関しては段落５、及び媒体ファイル暗号化における付加的な情報に関しては段落５．２、段落６．２．３、及び段落６．３．６．を参照されたい。
３．３．４．ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグは、次の媒体ファイルの開始を絶対日付及び／又は時間に関連付ける。日付／時間表示は、ＩＳＯ／ＩＥＣ８６０１：２００４［ＩＳＯ_８６０１］であり、時間帯を指示すべきである。例えば、
＃ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥ：＜ＹＹＹＹ−ＭＭ−ＤＤＴｈｈ：ｍｍ：ｓｓＺ＞
ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグに対する更なる情報に関しては、段落６．２．１及び段落６．３．３を参照されたい。
３．３．５．ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグは、クライアントが後の再生のためにダウンロードされた媒体ファイルをキャッシュに入れることができるか又はキャッシュに入れてはならないかを示す。ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグは、プレイリストファイルのあらゆる場所に発生させることができ、１回より多くは発生してはならない。ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグは、プレイリストの全てのセグメントに適用される。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥ：＜ＹＥＳ｜ＮＯ＞
ＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグに対する更なる情報に関しては、段落６．３．３を参照されたい。
３．３．６．ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ
ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥタグは、プレイリストファイルに関する変更可能性情報を提供する。これは任意的である。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥ：＜イベント｜ＶＯＤ＞
段落６．２．１は、ＥＸＴ−Ｘ−ＰＬＡＹＬＩＳＴ−ＴＹＰＥタグの意味を定義する。
３．３．７．ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグは、媒体ファイルが、もはやそれ以上プレイリストファイルに追加されないことを示す。これは、プレイリストファイルのあらゆる場所に発生させることができ、これは、１回より多く発生してはならない。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
３．３．８．ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、プレイリストファイルの次のＵＲＩが別のプレイリストファイルを識別することを示す。そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：＜ａｔｔｒｉｂｕｔｅ−ｌｉｓｔ＞＜ＵＲＩ＞
以下の属性が定義される。
ＢＡＮＤＷＩＤＴＨ
この値は、１秒当たりのビットの十進数−整数である。これは、コンテナオーバヘッドを含むために計算される各媒体ファイルの全体的なビットレートの上限限度でなくてはならず、プレイリストに出現するか又は出現することになる。
あらゆるＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグが、ＢＡＮＤＷＩＤＴＨ属性を含まなくてはならない。
ＰＲＯＧＲＡＭ−ＩＤ
この値は、プレイリストファイルの範囲内の特定の提示を固有に識別する十進数−整数である。
プレイリストファイルは、同じ提示の異なる符号化を識別するために、同じＰＲＯＧＲＡＭ−ＩＤを有する複数のＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含むことができる。これらの変形プレイリストは、付加的なＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含むことができる。
ＣＯＤＥＣＳ
この値は、フォーマットのコンマで区切られたリストを含む引用符付き文字列であり、ここで、各フォーマットは、プレイリストファイルの媒体ファイルに存在する媒体サンプルタイプを指定する。有効フォーマット識別子は、ＲＦＣ４２８１［ＲＦＣ４２８１］によって定義されるＩＳＯファイルフォーマットネームスペースの識別子である。
あらゆるＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグがＣＯＤＥＣＳ属性を含むべきである。
ＲＥＳＯＬＵＴＩＯＮ
この値は、ストリーム内のビデオの大体の符号化された水平及び垂直解像度を説明する十進数−解像度である。
３．３．９．ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグは、それに続く媒体ファイルとそれに先行する媒体ファイルの間の符号化不連続性を示す。変更することができる特性のセットは以下の通りである。
ファイルフォーマット
トラックの数及びタイプ
符号化パラメータ
符号化シーケンス
タイムスタンプシーケンス
そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹ
ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグに対する更なる情報は、段落４、段落６．２．１、及び段落６．３．３を参照されたい。
３．３．１０．ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ
ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグは、プレイリストファイルの互換性バージョンを示す。プレイリストファイル、その関連の媒体及びそのサーバは、タグ値によって示されたプロトコルバージョンを説明する本文書の最新バージョンの全ての供給に従わなくてはならない。
そのフォーマットは以下の通りである。
＃ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮ：＜ｎ＞
ここで、ｎは、プロトコルバージョンを示す整数である。
プレイリストファイルは、１つよりも多いＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグを含んではならない。ＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグを含まないプレイリストファイルは、このプロトコルのバージョン１に従わなくてはならない。
４．媒体ファイル
プレイリストファイルの各媒体ファイルＵＲＩは、全体の提示のセグメントである媒体ファイルを識別すべきである。各媒体ファイルは、ＭＰＥＧ−２トランスポートストリーム又はＭＰＥＧ−２オーディオエレメンタリストリーム［ＩＳＯ_１３８１８］としてフォーマット設定すべきである。
トランスポートストリームファイルは、単一のＭＰＥＧ−２プログラムを含まなくてはならない。各ファイルの始まりにはプログラム関連性テーブル及びプログラムマップテーブルを存在させるべきである。ビデオを含むファイルは、ビデオ復号器を完全に初期化するために少なくとも１つのキーフレーム及び十分な情報を有するべきである。
プレイリストの媒体ファイルは、第１の媒体ファイルがプレイリストファイルに現れない限り、又はＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグが前に付かない限り、前のシーケンス番号を有する媒体ファイルの最後での符号化ストリームの連続でなくてはならない。
クライアントは、特定のタイプ（例えば、オーディオ又はビデオ）の複数のトラックを処理する準備をすべきである。他のプリファレンスを持たないクライアントは、再生することができる最低数字ＰＩＤを備えたものを選択すべきである。
クライアントは、認識していないトランスポートストリーム内部のプライベートストリームを無視すべきである。
媒体ファイル内部のストリーム内及び複数の媒体ファイルにわたる対応するストリーム間のサンプルの符号化パラメータは、一貫したものにすべきである。しかし、クライアントは、例えば、解像度変化に対応するためにビデオコンテンツをスケーリングすることにより、クライアントが遭遇する符号化変化に対処すべきである。
５．キーファイル
５．１．序文
ＵＲＩ属性を備えたＥＸＴ−Ｘ−ＫＥＹタグは、キーファイルを識別する。キーファイルは、プレイリストの次の媒体ファイルを解読するために使用すべきである暗号キーを含む。
ＡＥＳ−１２８暗号化方法は、１６オクテットキーを使用する。キーファイルのフォーマットは、単純にバイナリフォーマットでのこれらの１６オクテットのパックアレイである。
５．２．ＡＥＳ−１２８のためのＩＶ
１２８−ビットＡＥＳは、暗号化及び解読される時に供給される同じ１６オクテット初期化ベクトルを要求する。変化するこのＩＶは、暗号の強度を増す。
ＥＸＴ−Ｘ−ＫＥＹタグがＩＶ属性を有する場合、実施は、そのキーで暗号化又は解読する時にＩＶとして属性値を使用すべきである。値は、１２８−ビット１６進数として解釈すべきであり、０ｘ又は０Ｘを前に付けなくてはならない。
ＥＸＴ−Ｘ−ＫＥＹタグがＩＶ属性を持たない場合、実施は、その媒体ファイルを暗号化又は解読する時にＩＶとして媒体ファイルのシーケンス番号を使用すべきである。シーケンス番号のｂｉｇ−ｅｎｄｉａｎバイナリ表示は、１６オクテットバッファに入れられ、ゼロでパッド（左に）すべきである。
６．クライアント／サーバアクション
６．１．序文
この段落は、サーバがどのようにプレイリスト及び媒体ファイルを生成するか及びクライアントがこれらをどのようにダウンロード及び再生すべきかを説明する。
６．２．サーバ処理
６．２．１．序文
ＭＰＥＧ−２ストリームの生成は、本文書の範囲外であり、提示を含む連続ストリームのソースを単純に前提とする。
サーバは、持続時間が、一定のターゲット持続時間よりも少ないか又は等しい個々の媒体ファイルにストリームを分割すべきである。サーバは、個々の媒体ファイルの効率的な復号をサポートするポイント、例えば、パケット及びキーフレーム境界でストリームの分割を試みるべきである。
サーバは、クライアントがファイルを取得することを可能にする各媒体ファイルに対するＵＲＩを作成すべきである。
サーバは、プレイリストファイルを作成すべきである。プレイリストファイルは、段落３に説明したフォーマットに従わなくてはならない。サーバが利用可能にしたいと思う各媒体ファイルに対するＵＲＩは、再生される順序でプレイリストに出現すべきである。そのＵＲＩがプレイリストファイルにある場合に全媒体ファイルをクライアントに利用することを可能にすべきである。
プレイリストファイルは、ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮタグを含まなくてはならない。その値は、プレイリストファイルに出現するか又は出現することになるいずれかの媒体ファイルのＥＸＴＩＮＦ値に等しいか又はそれよりも大きくなくてはならない。その値は、変化してはならない。典型的なターゲット持続時間は１０秒である。
プレイリストファイルは、ストリームの互換性バージョンを示す１つのＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグを含むべきである。その値は、サーバ、プレイリストファイル、及び関連の媒体ファイル全てが従う最低プロトコルバージョンでなくてはならない。
サーバは、そのクライアントがファイルを取得することを可能にするプレイリストファイルに対するＵＲＩを作成すべきである。
プレイリストファイルがＨＴＴＰによって配信される場合、サーバは、「ｇｚｉｐ」コンテンツ符号化を使用するためのクライアント要求をサポートすべきである。
プレイリストファイルの変更は、クライアントの観点から細かく行わなくてはならない。
サーバは、以下を除いてプレイリストファイルを変更してはならない。
それに行を添付する（段落６．２．１）。
これらの媒体ファイルだけに適用されるいずれのタグも一緒に、出現する順序でプレイリストから媒体ファイルＵＲＩを取り除く（段落６．２．２）。
ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグの値を変更する（段落６．２．２）。
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを追加又は取り除く（段落６．２．４）。クライアントは、これらを変更することが即座の影響を持たない場合があるので、変形プレイリストファイルをリロードすることを要求されないことに注意されたい。
ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグをプレイリストに追加する（段落６．２．１）。
更に、プレイリストファイルは、ＥＶＥＮＴ又はＶＯＤのいずれかの値を有するＥＸＴ−Ｘ−ＰＬＡＬＩＳＴ−ＴＹＰＥタグを含むことができる。タグが存在しＥＶＥＮＴの値を有する場合、サーバは、プレイリストファイルのいずれの部分も変更又は削除してはならない（しかし、行をそれに添付することができる）。タグが存在しＶＯＤの値を有する場合、プレイリストファイルは変更してはならない。
プレイリストのいずれの媒体ファイルＵＲＩの前にも、媒体ファイルの持続時間を示すＥＸＴＩＮＦタグを付けることができる。
サーバは、そのＵＲＩの前にＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグを付けることにより、絶対日付及び時間を媒体ファイルに関連付けることができる。日付及び時間の値は、媒体の時系列と適切な壁時計時間の情報マッピングを提供し、シーキング、ディスプレイのために、又は他の目的のための基礎として使用することができる。サーバがこのマッピングを提供する場合、サーバは、プレイリストファイルの全てのＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグの後にＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグを置くべきである。
プレイリストが提示の最終媒体ファイルを含む場合、プレイリストファイルは、ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴを含まなくてはならない。
プレイリストがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない場合、サーバは、少なくとも１つの新しい媒体ファイルＵＲＩを含むプレイリストファイルの新しいバージョンを利用することを可能にすべきである。それは、プレイリストファイルの前のバージョンが利用可能になった時間に対して利用可能にされるべきであり、すなわち、その時間の後のターゲット持続時間の１／２より早くなく、その時間の後のターゲット持続時間の１．５倍より遅くない時間である。
サーバが全提示を取り除きたいと思う場合、サーバは、プレイリストファイルをクライアントに利用できないようにすべきである。サーバは、プレイリストファイルの全ての媒体ファイルが取り除く時に少なくともプレイリストファイルの持続時間にクライアントに利用することを可能にしておくべきである。
６．２．２．スライディングウィンドウプレイリスト
サーバは、プレイリストに最も新しく追加されたものに媒体ファイルの利用可能度を制限することができる。これを実行するために、プレイリストファイルは、１つのＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを常に正確に含まなくてはならない。その値は、プレイリストファイルから取り除かれる媒体ファイルＵＲＩ毎に１ずつ増加させなければならない。
媒体ファイルＵＲＩは、これらが追加された順序でプレイリストファイルから取り除かなくてはならない。
サーバは、プレイリストファイルの持続時間から媒体ファイルの持続時間を引いた時間がターゲット持続時間の３倍よりも少ない場合には、プレイリストファイルから媒体ファイルＵＲＩを取り除いてはならない。
サーバがプレイリストから媒体ファイルＵＲＩを取り除いた時に、媒体ファイルは、媒体ファイルの持続時間に媒体ファイルが現れる最長プレイリストファイルの持続時間を加えたものに等しい時間にわたってクライアントに利用可能にすべきである。
サーバがＨＴＴＰを通じてクライアントに配信された後に媒体ファイルを取り除くことを計画した場合、サーバは、ＨＴＴＰ応答が計画されたライブまでの時間を反映する満了ヘッダを含むことを保証すべきである。
６．２．３．媒体ファイルの暗号化
媒体ファイルが暗号化される場合、サーバは、解読キーを含むキーファイルを許可されたクライアントが取得することを可能にするＵＲＩを定義すべきである。キーファイルは、段落５に説明したフォーマットに従わなくてはならない。
サーバは、キーをキャッシュに入れることができることを示すために、キー応答にＨＴＴＰ満了ヘッダを設定することができる。
暗号化方法がＡＥＳ−１２８である場合、ＡＥＳ−１２８ＣＢＣ暗号化は、個々の媒体ファイルに適用すべきである。ファイル全体が暗号化されなければならない。暗号ブロック連鎖は、媒体ファイルにわたって適用してはならない。暗号化に対して使用されるＩＶは、媒体ファイルのシーケンス番号又は段落５．２に説明されているようにＥＸＴ−Ｘ−ＫＥＹタグのＩＶ属性の値のいずれかでなくてはならない。
サーバは、本方法及びプレイリストファイルにおいてそのＵＲＩのすぐ前のＥＸＴ−Ｘ−ＫＥＹタグによって指定された他の属性を使用して、プレイリストにおける全媒体ファイルを暗号化すべきである。そのＭＥＴＨＯＤがＮＯＮＥであるＥＸＴ−Ｘ−ＫＥＹタグによって先行されるか、又はＥＸＴ−Ｘ−ＫＥＹタグによって先行されない媒体ファイルは、暗号化してはならない。
プレイリストファイルがそのキーによって暗号化された媒体ファイルへのＵＲＩを含む場合、サーバは、プレイリストファイルからＥＸＴ−Ｘ−ＫＥＹタグを取り除いてはならない。
６．２．４．変形ストリームの提供
サーバは、同じ提示の異なる符号化を提供するために複数のプレイリストファイルを供給することができる。サーバがこれを実行する場合、サーバは、クライアントが符号化を動的に切り換えられるようにするために、各変形ストリームを列挙する変形プレイリストファイルを提供すべきである。
変形プレイリストは、各変形ストリームに対するＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグを含まなくてはならない。同じ提示のための各ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグは、同じＰＲＯＧＲＡＭ−ＩＤ属性値を持たなくてはならない。各提示に対するＰＲＯＧＲＡＭ−ＩＤ値は、変形プレイリスト内で固有のものでなくてはならない。
ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦタグがＣＯＤＥＣＳ属性を含む場合、属性値は、プレイリストファイルに現れる又は現れることになるいずれの媒体ファイルにも存在する［ＲＦＣ４２８１］によって定義されたいずれかのフォーマットを含まなくてはならない。
サーバは、変形ストリームを生成する時に以下の制約を満足させなくてはならない。
各変形ストリームは、ストリーム不連続性を含む同じコンテンツを提示する。
各変形プレイリストファイルは、同じターゲット持続時間を持たなくてはならない。
１つの変形プレイリストファイルに現れるが別の変形プレイリストファイルには現れないコンテンツは、プレイリストファイルの始め又は最後のいずれかに現れなくてはならず、ターゲット持続時間よりも長くてはならない。
変形ストリームにおける適合コンテンツは、適合タイムスタンプを持たなくてはならない。それによってクライアントはストリームを同期することができる。
エレメンタリオーディオストリームファイルは、「ｃｏｍ．ａｐｐｌｅ．ｓｔｒｅａｍｉｎｇ．ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＴｉｍｅｓｔａｍｐ」の所有者識別子を有するＩＤ３ＰＲＩＶタグ［ＩＤ３］を先頭に追加することによってファイルの第１のサンプルのタイムスタンプを信号送信すべきである。バイナリデータは、ゼロに設定された上限３１ビットを有するビッグエンディアン８オクテット数として表現される３３ビットＭＰＥＧ−２プログラム基本ストリームタイムスタンプでなくてはならない。
更に、全ての変形ストリームは、同じ符号化オーディオビットストリームを含むべきである。それによってクライアントは可聴グリッチングなしにストリーム間で切り換えることができる。
６．３．クライアント処理
６．３．１．序文
クライアントがどのようにプレイリストファイルへのＵＲＩを取得するかは、本文書の範囲外であり、これは、行われたと仮定する。
クライアントは、ＵＲＩからプレイリストファイルを取得すべきである。このように得られたプレイリストファイルが変形プレイリストである場合、クライアントは変形プレイリストからプレイリストファイルを取得すべきである。
本文書は、クライアントによる変形ストリームの処理を指定しない。
６．３．２．プレイリストファイルのローディング
プレイリストファイルがプレイリストＵＲＩからロード又はリロードされる度に：
クライアントは、プレイリストファイルがＥＸＴＭ３Ｕタグから始まること、及びＥＸＴ−Ｘ−ＶＥＲＳＩＯＮタグが存在するとすれば、クライアントによってサポートされるプロトコルバージョンを指定することを保証しなくてならない；存在しない場合には、クライアントは、プレイリストを使用しようとしてはならない。
クライアントは、認識していないいずれのタグ及び属性も無視すべきである。
クライアントは、段落６．３．５に説明するようにロードする次の媒体ファイルを判断すべきである。
プレイリストがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合、クライアントは、ロードされたプレイリストファイルにプレイリストファイルの持続時間を加えた時間に各媒体ファイルが利用できなくなることを仮定すべきである。プレイリストファイルの持続時間は、その中の媒体ファイルの持続時間の和である。
６．３．３．プレイリストファイルの再生
クライアントは、再生が開始された時にプレイリストから最初に再生する媒体ファイルを選択すべきである。ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグが存在せず、クライアントが定期的に（すなわち、公称再生速度のプレイリスト順序で）再生することが想定されている場合、クライアントは、プレイリストファイルの最後から３ターゲット持続時間未満に始まるファイルを選択すべきではない。これを行うことで、再生停止を起こすことがある。
定期的再生を達成するために、媒体ファイルは、プレイリストファイルに出現する順序で再生すべきである。クライアントは、定期的再生、ランダムアクセス、及び（ｔｒｉｃｋ ｍｏｄｅｓ）を含むクライアントが望むいずれの方法でも利用可能な媒体を提示することができる。
クライアントは、ＥＸＴ−Ｘ−ＤＩＳＣＯＮＴＩＮＵＩＴＹタグが前に付いている媒体ファイルを再生する前にそのパーサー及び復号器のリセットを準備しておかなくてはならない。
クライアントは、待ち時間及び処理量における一時的変動を補償するために、中断されない再生に対して媒体ファイルが要求される時に予め媒体ファイルをロードすることを試みるべきである。
プレイリストファイルがＥＸＴ−Ｘ−ＡＬＬＯＷ−ＣＡＣＨＥタグを含み、その値がＮＯである場合、クライアントは、再生された後にダウンロードされた媒体ファイルをキャッシュに入れてはならない。それ以外は、クライアントは後のリプレイのためにダウンロードされた媒体ファイルを無期限にキャッシュに入れることができる。
クライアントは、プログラム開始時間をユーザに表示するためにＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値を使用することができる。値が時間帯情報を含む場合、クライアントは、考慮に入れるべきであろうが、含まない場合、クライアントは、開始時間帯を推測してはならない。
クライアントは、ＥＸＴ−Ｘ−ＰＲＯＧＲＡＭ−ＤＡＴＥ−ＴＩＭＥタグの値の精度又は一貫性に依存してはならない。
６．３．４．プレイリストファイルのリローディング
クライアントは、プレイリストファイルがＥＸＴ−Ｘ−ＥＮＤＬＩＳＴタグを含まない限りプレイリストファイルを定期的にリロードすべきである。
しかし、クライアントは、この段落によって指定されるよりも頻繁にプレイリストファイルをリロードしようとしてはならない。
クライアントが初めてプレイリストファイルをロードするか又はプレイリストファイルをリロードし最後にロードされてから変化したことを見つけた時に、クライアントは、プレイリストファイルを再度リロードしようとする前にある時間待たなくてはならない。この期間は、初期最小リロード遅延と呼ぶ。これは、クライアントがプレイリストファイルのローディングを開始した時間から測定される。
初期最小リロード遅延は、プレイリストにおける最後の媒体ファイルの持続時間である。媒体ファイル持続時間は、ＥＸＴＩＮＦタグによって指定される。
クライアントがプレイリストファイルをリロードして変化しなかったことを見つけた場合、リトライの前にある時間にわたって待たなくてはならない。最小遅延は、ターゲット持続時間の倍数である。この倍数は、第１の試みに対して０．５、第２に対して１．５、及びその後は３．０である。
サーバロードを低減するために、クライアントは、現在再生されていない変形ストリームのプレイリストファイルをリロードすべきではない。異なる変形に再生を切り換えると判断した場合、古い変形のプレイリストのリロードを中止して新しい変形のプレイリストのロードを開始すべきである。クライアントは、対応する媒体の大体のロケーションを判断するために、ＥＸＴＩＮＦ持続時間及び段落６．２．４の制約を使用することができる。新しい変形からの媒体がロードされた状態で、古い時系列と新しい時系列を正確に同期させるために媒体ファイルのタイムスタンプを使用することができる。
６．３．５．ロードする次のファイルの判断
クライアントは、ロードする次の媒体ファイルを判断するために、ロード又はリロードされる度にプレイリストファイルを調べなければならない。
ロードする第１のファイルは、段落６．３．３で説明するように、クライアントが最初に再生することを選択したファイルでなくてはならない。
再生される第１のファイルがロードされており、プレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含まない場合、クライアントは、現在のプレイリストファイルが、それが本質的に見出されたオフセットでの最後のロードされた媒体ファイルのＵＲＩを含むことを検証しなければならず、含まない場合は再生を停止する。ロードされる次の媒体ファイルは、プレイリストにおける最後にロードされたＵＲＩに続く第１の媒体ファイルＵＲＩでなければならない。
再生される第１のファイルがロードされており、プレイリストファイルがＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥタグを含む場合、ロードされる次の媒体ファイルは、ロードされた最後の媒体ファイルのシーケンス番号よりも大きい最低シーケンス番号を有する媒体ファイルにすべきである。
６．３．６．暗号化された媒体ファイルの解読
プレイリストファイルが、キーファイルＵＲＬを指定するＥＸＴ−Ｘ−ＫＥＹタグを含む場合、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまで、クライアントは、ＥＸＴ−Ｘ−ＫＥＹタグに続く全ての媒体ファイルを解読するために、そのキーファイルを取得してその内側のキーを使用すべきである。
暗号化方法がＡＥＳ−１２８である場合、ＡＥＳ−１２８ＣＢＣ解読が個々の媒体ファイルに適用されるべきである。ファイル全体が、解読されなければならない。暗号ブロック連鎖は、媒体ファイルにわたって適用してはならない。解読のために使用されるＩＶは、段落５．２に説明するように、媒体ファイルのシーケンス番号又はＥＸＴ−Ｘ−ＫＥＹタグのＩＶ属性の値のいずれかにすべきである。
暗号化方法がＮＯＮＥである場合、クライアントは、別のＥＸＴ−Ｘ−ＫＥＹタグに遭遇するまでクリアテキスト（暗号化されていない）としてＥＸＴ−Ｘ−ＫＥＹタグに続く全ての媒体ファイルを扱わなければならない。
７．プロトコルバージョン互換性
クライアント及びサーバは、使用すべきプロトコルバージョン２又はそれよりも高いバージョンを実施すべきである。
・ＥＸＴ−Ｘ−ＫＥＹタグのＩＶ属性。
クライアント及びサーバは、使用すべきプロトコルバーション３又はそれよりも高いバージョンを実施すべきである。
・浮動小数点ＥＸＴＩＮＦ持続時間値。
８．実施例
８．１．序文
この段落は、いくつかの例示的なプレイリストファイルを含む。
８．２．単純なプレイリストファイル
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：５２２０
＃ＥＸＴＩＮＦ：５２２０、
ｈｔｔｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ／ｅｎｔｉｒｅ．ｔｓ
＃ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ
８．３．ＨＴＴＰＳを使用したスライディングウィンドウプレイリスト
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：８
＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：２６８０
＃ＥＸＴＩＮＦ：８、
ｈｔｔｐｓ：／／ｐｒｉｖ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ２６８０．ｔｓ
＃ＥＸＴＩＮＦ：８、
ｈｔｔｐｓ：／／ｐｒｉｖ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ２６８1．ｔｓ
＃ＥＸＴＩＮＦ：８、
ｈｔｔｐｓ：／／ｐｒｉｖ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ２６８２．ｔｓ
８．４．暗号化媒体ファイルを備えたプレイリストファイル
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ：７７９４
＃ＥＸＴ−Ｘ−ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ：１５
＃ＥＸＴ−Ｘ−ＫＥＹ：ＭＥＴＨＯＤ＝ＡＥＳ−
１２８、ＵＲＩ＝「ｈｔｔｐｓ：／／ｐｒｉｖ．ｅｘａｍｐｌｅ．ｃｏｍ／ｋｅｙ．ｐｈｐ？ｒ＝５２」
＃ＥＸＴＩＮＦ：１５、
ｈｔｔｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ５２−１．ｔｓ
＃ＥＸＴＩＮＦ：１５、
ｈｔｔｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ５２−２．ｔｓ
＃ＥＸＴＩＮＦ：１５、
ｈｔｔｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ５２−３．ｔｓ
＃ＥＸＴ−Ｘ−ＫＥＹ：ＭＥＴＨＯＤ＝ＡＥＳ−
１２８、ＵＲＩ＝「ｈｔｔｐｓ：／／ｐｒｉｖ．ｅｘａｍｐｌｅ．ｃｏｍ／ｋｅｙ．ｐｈｐ？ｒ＝５３」
＃ＥＸＴＩＮＦ：１５、
ｈｔｔｐ：／／ｍｅｄｉａ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅＳｅｑｕｅｎｃｅ５３−１．ｔｓ
８．５．変形プレイリストファイル
＃ＥＸＴＭ３Ｕ
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１、ＢＡＮＤＷＩＤＴＨ＝１２８００００
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｌｏｗ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１、ＢＡＮＤＷＩＤＴＨ＝２５６００００
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｍｉｄ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１、ＢＡＮＤＷＩＤＴＨ＝７６８００００
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｈｉ．ｍ３ｕ８
＃ＥＸＴ−Ｘ−ＳＴＲＥＡＭ−ＩＮＦ：ＰＲＯＧＲＡＭ−ＩＤ＝１、ＢＡＮＤＷＩＤＴＨ＝６５００００、ＣＯＤＥＣＳ＝「ｍｐ４ａ．４０．５」
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｄｉｏ−ｏｎｌｙ．ｍ３ｕ８
９．セキュリティ配慮
プロトコルは、一般的にデータを転送するためにＨＴＴＰを使用するので、同じセキュリティ配慮の多くが適用される。ＲＦＣ２６１６［ＲＦＣ２６１６］の段落１５を参照されたい。
媒体ファイルパーサーは、典型的に「曖昧」攻撃を受けやすい。クライアントは、準拠しないファイルが拒否されるように、サーバから受信したファイルを構文解析する時に注意すべきである。
プレイリストファイルは、クライアントが任意のエンティティのネットワーク要求を実行するために使用するＵＲＩを含む。クライアントは、バッファオーバフローを防ぐために、応答をレンジチェックすべきである。ＲＦＣ３９８６［ＲＦＣ３９８６］のセキュリティ配慮の段落を参照されたい。
クライアントは、サービス拒絶攻撃に寄与しないようにＵＲＩによって識別されたリソースをレイジーにロードすべきである。
ＨＴＴＰ要求は、プライベートユーザデータを含む場合があるセッション状態「クッキー」を含むことが多い。実施は、ＲＦＣ２９６５［ＲＦＣ２９６５］によって指定されたクッキー制約及び満了規則に従わなければならない。ＲＦＣ２９６５のセキュリティ配慮の段落、及びＲＦＣ２９６４［ＲＦＣ２９６４］を参照されたい。
暗号化キーは、ＵＲＩによって指定される。これらのキーの配信は、セキュアアドレス体系又はセッションクッキーと共にＴＬＳ［ＲＦＣ５２４６］（公式にはＳＳＬ）を通じたＨＴＴＰのような機構によって守られるべきである。
１０．参考文献
１０．１．標準参考文献
［ＡＥＳ_１２８］ 米国商務省標準技術局、「最新暗号化基準（ＡＥＳ）、ＦＩＰＳ ＰＵＢ１９７」、２００１年１１月、
＜ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｆｉｐｓ／ｆｉｐｓ１９７／ｆｉｐｓ−１９７．ｐｄｆ
＜ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｆｉｐｓ／ｆｉｐｓ１９７／ｆｉｐｓ−１９７．ｐｄｆ≫。

［ＩＳＯ_１３８１８］ 国際標準化機構、「ＩＳＯ／ＩＥＣ国際規格１３８１８；ビデオ及び関連オーディオ情報の一般的な符号化」、２００７年１０月、
＜ｈｔｔｐ：／／ｗｗｗ．ｉｓｏ．ｏｒｇ／ｉｓｏ／ｃａｔａｌｏｇｕｅ ｄｅｔａｉｌ？ｃｓｎｕｍｂｅｒ＝４４１６９＞。

［ＩＳＯ_８６０１］ 国際標準化機構、「ＩＳＯ／ＩＥＣ国際規格８６０１：２００４；データ要素及び交換フォーマット−情報交換−日付及び時間の表示」、２００４年１２月、
＜ｈｔｔｐ：／／ｗｗｗ．ｉｓｏ．ｏｒｇ／ｉｓｏ／ｃａｔａｌｏｇｕｅ ｄｅｔａｉｌ？ｃｓｎｕｍｂｅｒ＝４０８７４＞。

［ＲＦＣ２０４６］ Ｆｒｅｅｄ、Ｎ．及びＮ．Ｂｏｒｅｎｓｔｅｉｎ、「多目的インターネットメール拡張（ＭＩＭＥ）パートＩＩ：媒体タイプ」、ＲＦＣ２０４６、１９９６年１１月。

［ＲＦＣ２１１９］ Ｂｒａｄｎｅｒ、Ｓ．、「要件レベルを示すためにＲＦＣで使用されるキーワード」、ＢＣＰ１４、ＲＦＣ２１１９、１９９７年３月。

［ＲＦＣ２６１６］ Ｆｉｅｌｄｉｎｇ、Ｒ．、Ｇｅｔｔｙｓ、Ｊ．、Ｍｏｇｕｌ、Ｊ．、Ｆｒｙｓｔｙｋ、Ｈ．、Ｍａｓｉｎｔｅｒ、Ｌ．、Ｌｅａｃｈ、Ｐ．、及びＴ．Ｂｅｒｎｅｒｓ−Ｌｅｅ、「ハイパーテキスト転送プロトコル−ＨＴＴＰ／１．１」、ＲＦＣ２６１６、１９９９年６月。

［ＲＦＣ２９６４］ Ｍｏｏｒｅ、Ｋ．及びＮ．Ｆｒｅｅｄ、「ＨＴＴＰ状態管理の使用」、ＢＣＰ４４、ＲＦＣ２９６４、２０００年１０月。

［ＲＦＣ２９６５］ Ｋｒｉｓｔｏｌ、Ｄ．及びＬ．Ｍｏｎｔｕｌｌｉ、「ＨＴＴＰ状態管理機構」、ＲＦＣ２９６５、２０００年１０月。

［ＲＦＣ３６２９］ Ｙｅｒｇｅａｕ、Ｆ．、「ＵＴＦ−８、ＩＳＯ１０６４６の変換フォーマット」、ＳＴＤ６３、ＲＦＣ３６２９、２００３年１１月。

［ＲＦＣ３９８６］ Ｂｅｒｎｅｒｓ−Ｌｅｅ、Ｔ．、Ｆｉｅｌｄｉｎｇ、Ｒ．、及びＬ．Ｍａｓｉｎｔｅｒ、「ユニフォームリソース識別子（ＵＲＩ）：一般的な構文」、ＳＴＤ６６、ＲＦＣ３９８６、２００５年１月。

［ＲＦＣ４２８１］ Ｇｅｌｌｅｎｓ、Ｒ．、Ｓｉｎｇｅｒ、Ｄ．、及びＰ．Ｆｒｏｊｄｈ、「“バケット”媒体タイプのためのコーデックパラメータ」、ＲＦＣ４２８１、２００５年１１月。

［ＲＦＣ５２４６］ Ｄｉｅｒｋｓ、Ｔ．及びＥ．Ｒｅｓｃｏｒｌａ、「トランスポート層セキュリティ（ＴＬＳ）プロトコルバージョン１．２」ＲＦＣ５２４６、２００８年８月。

［ＲＦＣ５６５２］ Ｈｏｕｓｌｅｙ、Ｒ．、「暗号化メッセージ構文（ＣＭＳ）」、ＳＴＤ７０、ＲＦＣ５６５２、２００９年９月。

［ＵＳ_ＡＳＣＩＩ］ 米国規格協会、「ＡＮＳＩ Ｘ３．４−１９８６、情報システム−情報交換のための符号化文字セット７ビット米国規格コード（７ビットＡＳＣＩＩ）」、１９８６年１２月。
１０．２．情報参考文献
［ＩＤ３］ ＩＤ３．ｏｒｇ＜ＨＴＴＰ：／／ＩＤ３．ｏｒｇ／＞、「ＩＤ３オーディオファイルデータタグ付けフォーマット」、
＜ｈｔｔｐ：／／ｗｗｗ．ｉｄ３．ｏｒｇ／Ｄｅｖｅｌｏｐｅｒ Ｉｎｆｏｒｍａｔｉｏｎ＞。

［Ｍ３Ｕ］ Ｎｕｌｌｓｏｆｔ、Ｉｎｃ．、「Ｗｉｎａｐ媒体プレーヤのために最初に発明されたＭ３Ｕプレイリストフォーマット」、
＜ｈｔｔｐ：／／ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍ３Ｕ＞。

Claims (21)

  1. データ処理システムに、
    クライアントデバイスを用いてプレイリストファイルを要求する手順と、
    前記要求に応答して前記クライアントデバイスにおいて、複数の媒体ファイルと該複数の媒体ファイルの再生に関連するパラメータを有する複数のタグとを示すユニバーサルリソースインジケータ（ＵＲＩ）を有する前記プレイリストファイルをサーバデバイスから受信する手順と、
    前記プレイリストファイルが、プレイリストのタイプを示すタイプパラメータを有するか否かを判断する手順と、
    前記プレイリストファイルが前記タイプパラメータを有する時に該タイプパラメータに従って前記プレイリストを処理する手順と、
    を実行させるための命令を記録したマシーンで読み取り可能な不揮発性の記録媒体。
  2. 前記タイプパラメータは、（ａ）ビデオ・オン・デマンド（ＶＯＤ）、（ｂ）ライブ、又は（ｃ）イベントのうちの１つであり、
    ＶＯＤプレイリストが、変化せず、
    イベントが、イベントプレイリストのための指定されて固定の開始時間を有し、
    前記プレイリストは、非ストリーミング転送プロトコルを使用してネットワークを通じて受信され、
    前記プレイリストファイルによって示された順序で前記媒体ファイルの１つ又それよりも多くを要求する手順と、
    前記非ストリーミング転送プロトコルを使用して前記ネットワークを通じて前記１つ又はそれよりも多くの要求された媒体ファイルを受信する手順と、
    を更に実行させる命令を含む、請求項１に記載の記録媒体。
  3. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストを更新しないように構成され、
    該クライアントデバイスは、該プレイリストによって参照されたコンテンツに対する変形プレイリストに切り換えた時に将来の使用ために該プレイリストを保存するように構成されることを特徴とする、請求項２に記載の記録媒体。
  4. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストにＥＮＤＬＩＳＴタグがない時にエラー信号を発生するように構成されることを特徴とする、請求項３に記載の記録媒体。
  5. 前記タイプパラメータがライブである時に、前記クライアントデバイスは、更新されたプレイリストを要求するように構成されることを特徴とする、請求項２に記載の記録媒体。
  6. 前記タイプパラメータがイベントである時に、前記クライアントデバイスは、（ａ）更新されたプレイリストの一部分だけをロードするか、又は（ｂ）該更新されたプレイリストの一部分だけを構文解析するかのいずれかであるように構成されることを特徴とする、請求項２に記載の記録媒体。
  7. 前記プレイリストファイルによって示された前記順序で前記クライアントデバイスを用いて前記媒体ファイルを再生することにより、前記コンテンツのストリームを表すオーディオ又はビデオ又はオーディオ／ビデオ出力を発生させる手順を更に含み、
    前記非ストリーミング転送プロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）準拠プロトコルを含む、
    ことを特徴とする請求項２に記載の記録媒体。
  8. 前記媒体ファイルのデータアクセスに関連する統計値又は該媒体ファイルを受信する時に起こるネットワークエラーを少なくとも１つのログに格納する手順と、
    前記統計値を取得するためにＡＰＩ（アプリケーションプログラムインタフェース）を通じて要求を受信する手順と、
    を更に実行させる命令を含む、請求項１に記載の記録媒体。
  9. データ処理システムにより、
    クライアントデバイスを用いてプレイリストファイルを要求する処理と、
    前記要求に応答して前記クライアントデバイスにおいて、複数の媒体ファイルと該複数の媒体ファイルの再生に関連するパラメータを有する複数のタグとを示すユニバーサルリソースインジケータ（ＵＲＩ）を有する前記プレイリストファイルをサーバデバイスから受信する処理と、
    前記プレイリストファイルが、プレイリストのタイプを示すタイプパラメータを有するか否かを判断する処理と、
    前記プレイリストファイルが前記タイプパラメータを有する時に該タイプパラメータに従って前記プレイリストを処理する処理と、
    が実行される方法。
  10. 前記タイプパラメータは、（ａ）ビデオ・オン・デマンド（ＶＯＤ）、（ｂ）ライブ、又は（ｃ）イベントのうちの１つであり、
    ＶＯＤプレイリストが、変化せず、
    イベントが、イベントプレイリストのための指定されて固定の開始時間を有し、
    前記プレイリストは、非ストリーミング転送プロトコルを使用してネットワークを通じて受信され、
    前記プレイリストファイルによって示された順序で前記媒体ファイルの１つ又それよりも多くを要求する処理と、
    前記非ストリーミング転送プロトコルを使用して前記ネットワークを通じて前記１つ又はそれよりも多くの要求された媒体ファイルを受信する処理と、
    を更に含む、請求項９に記載の方法。
  11. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストを更新しないように構成され、該クライアントデバイスは、該プレイリストを該プレイリストによって参照されたコンテンツのための変形プレイリストに切り換える時の将来の使用のために保存するように構成されることを特徴とする、請求項１０に記載の方法。
  12. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストにＥＮＤＬＩＳＴタグがない時にエラー信号を発生するように構成されることを特徴とする、請求項１１に記載の方法。
  13. 前記タイプパラメータがライブである時に、前記クライアントデバイスは、更新されたプレイリストを要求するように構成されることを特徴とする、請求項１０に記載の方法。
  14. 前記タイプパラメータがイベントである時に、前記クライアントデバイスは、（ａ）更新されたプレイリストの一部分だけをロードするか、又は（ｂ）該更新されたプレイリストの一部分だけを構文解析するかのいずれかであるように構成されることを特徴とする、請求項１０に記載の方法。
  15. 前記プレイリストファイルによって示された前記順序で前記クライアントデバイスを用いて前記媒体ファイルを再生することにより、前記コンテンツのストリームを表すオーディオ又はビデオ又はオーディオ／ビデオ出力を発生させる処理を更に含み、
    前記非ストリーミング転送プロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）準拠プロトコルを含む、請求項１０に記載の方法。
  16. クライアントデバイスを用いてプレイリストファイルを要求するための手段と、
    前記要求に応答して前記クライアントデバイスにおいて、複数の媒体ファイルと該複数の媒体ファイルの再生に関連するパラメータを有する複数のタグとを示すユニバーサルリソースインジケータ（ＵＲＩ）を有する前記プレイリストファイルをサーバデバイスから受信するための手段と、
    前記プレイリストファイルが、プレイリストのタイプを示すタイプパラメータを有するか否かを判断するための手段と、
    前記プレイリストファイルが前記タイプパラメータを有する時に該タイプパラメータに従って前記プレイリストを処理するための手段と、
    を含むデータ処理システム。
  17. 前記タイプパラメータは、（ａ）ビデオ・オン・デマンド（ＶＯＤ）、（ｂ）ライブ、又は（ｃ）イベントのうちの１つであり、
    ＶＯＤプレイリストが、変化せず、
    イベントが、イベントプレイリストのための指定されて固定の開始時間を有し、
    前記プレイリストは、非ストリーミング転送プロトコルを使用してネットワークを通じて受信され、
    前記プレイリストファイルによって示された順序で前記媒体ファイルの１つ又それよりも多くを要求するための手段と、
    前記非ストリーミング転送プロトコルを使用して前記ネットワークを通じて前記１つ又はそれよりも多くの要求された媒体ファイルを受信するための手段と、
    を更に含む、請求項１６に記載のシステム。
  18. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストを更新しないように構成され、該クライアントデバイスは、該プレイリストを該プレイリストによって参照されたコンテンツのための変形プレイリストに切り換える時の将来の使用のために保存するように構成され、
    前記タイプパラメータがライブである時に、前記クライアントデバイスは、更新されたプレイリストを要求するように構成され、
    前記タイプパラメータがイベントである時に、前記クライアントデバイスは、（ａ）更新されたプレイリストの一部分だけをロードするか、又は（ｂ）該更新されたプレイリストの一部分だけを構文解析するかのいずれかであるように構成される、
    ことを特徴とする請求項１７に記載のシステム。
  19. データ処理システムに、
    サーバデバイスにおいてプレイリストファイルに対する要求を受信する手順と、
    複数の媒体ファイルと該複数の媒体ファイルの再生に関連するパラメータを有する複数のタグとを示すユニバーサルリソースインジケータ（ＵＲＩ）を有し、プレイリストのタイプを示すタイプパラメータを有する前記プレイリストファイルを前記要求に応答して前記サーバデバイスから送信する手順と、
    前記タイプパラメータに従って前記プレイリストを処理しているクライアントデバイスからの要求に応答する手順と、
    を実行させるための命令を記録したマシーンで読み取り可能な不揮発性の記録媒体。
  20. 前記タイプパラメータは、（ａ）ビデオ・オン・デマンド（ＶＯＤ）、（ｂ）ライブ、又は（ｃ）イベントのうちの１つであり、
    ＶＯＤプレイリストが、変化せず、
    イベントが、イベントプレイリストのための指定されて固定の開始時間を有し、
    前記プレイリストは、非ストリーミング転送プロトコルを使用してネットワークを通じて送信され、
    前記プレイリストファイルによって示された順序で前記媒体ファイルの１つ又はそれよりも多くに対する要求を受信する手順と、
    前記非ストリーミング転送プロトコルを使用して前記ネットワークを通じて前記１つ又はそれよりも多くの要求された媒体ファイルを送信する手順と、
    を更に実行させる命令を含む、請求項１９に記載の記録媒体。
  21. 前記タイプパラメータがＶＯＤである時に、前記クライアントデバイスは、前記プレイリストを更新しないように構成され、該クライアントデバイスは、該プレイリストを該プレイリストによって参照されたコンテンツのための変形プレイリストに切り換える時の将来の使用のために保存するように構成され、
    前記タイプパラメータがライブである時に、前記クライアントデバイスは、更新されたプレイリストを要求するように構成され、
    前記タイプパラメータがイベントである時に、前記クライアントデバイスは、（ａ）更新されたプレイリストの一部分だけをロードするか、又は（ｂ）該更新されたプレイリストの一部分だけを構文解析するかのいずれかであるように構成される、
    ことを特徴とする請求項２０に記載の記録媒体。
JP2015165081A 2011-01-11 2015-08-24 リアルタイム又はリアルタイムに近いストリーミング Active JP6141926B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161431813P 2011-01-11 2011-01-11
US61/431,813 2011-01-11
US13/078,741 US9729830B2 (en) 2010-04-01 2011-04-01 Real-time or near real-time streaming
US13/078,741 2011-04-01

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2013549500A Division JP2014509109A (ja) 2011-01-11 2012-01-10 リアルタイム又はリアルタイムに近いストリーミング

Publications (2)

Publication Number Publication Date
JP2016026427A true JP2016026427A (ja) 2016-02-12
JP6141926B2 JP6141926B2 (ja) 2017-06-07

Family

ID=46507416

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2013549500A Pending JP2014509109A (ja) 2011-01-11 2012-01-10 リアルタイム又はリアルタイムに近いストリーミング
JP2015165081A Active JP6141926B2 (ja) 2011-01-11 2015-08-24 リアルタイム又はリアルタイムに近いストリーミング

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2013549500A Pending JP2014509109A (ja) 2011-01-11 2012-01-10 リアルタイム又はリアルタイムに近いストリーミング

Country Status (5)

Country Link
EP (1) EP2646936B1 (ja)
JP (2) JP2014509109A (ja)
KR (1) KR101528991B1 (ja)
TW (3) TWI519145B (ja)
WO (1) WO2012097006A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021508220A (ja) * 2018-05-29 2021-02-25 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． メディア再生のローディング制御方法、装置及び記憶媒体
JP2021508891A (ja) * 2018-05-29 2021-03-11 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． ウェブページで解像度を切り替えてメディアファイルを再生する方法、装置及び記憶媒体
JP2021510991A (ja) * 2018-05-29 2021-04-30 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． 非ストリームメディアファイルのウェブページ再生方法、装置及び記憶媒体
JP2021534698A (ja) * 2018-08-17 2021-12-09 ロク インコーポレイテッド メディアストリームの再生間の遷移中における遷移フレームの動的再生
JP2023015026A (ja) * 2016-01-04 2023-01-31 グレースノート インコーポレイテッド 関連した音楽およびストーリを有するプレイリストの生成および配信

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2704449A1 (en) * 2012-08-30 2014-03-05 Thomson Licensing Rendering time control
JP6193569B2 (ja) * 2012-12-28 2017-09-06 キヤノン株式会社 受信装置、受信方法、及びプログラム、撮像装置、撮像方法、及びプログラム、送信装置、送信方法、及びプログラム
WO2014158707A1 (en) 2013-03-14 2014-10-02 Apple Inc. Media delivery service protocol to support large numbers of client with error failover processes
US9191725B2 (en) 2013-03-15 2015-11-17 Arris Technology, Inc. Method and apparatus for streaming video
US9432431B2 (en) 2014-03-18 2016-08-30 Accenture Global Servicse Limited Manifest re-assembler for a streaming video channel
EP3057273B1 (en) 2015-02-13 2019-03-27 Mitsubishi Electric R&D Centre Europe B.V. Method for a traffic shaping in a network
EP3160149A3 (en) * 2015-04-30 2017-08-02 Advanced Digital Broadcast S.A. A system and a method for distributed processing and selection of video content in a mobile content gateway
EP3089460A1 (en) 2015-04-30 2016-11-02 Advanced Digital Broadcast S.A. A system and a method for distributing content via static channel assignment in a mobile content gateway
EP3089463A1 (en) * 2015-04-30 2016-11-02 Advanced Digital Broadcast S.A. A system and a method for a time shift function in a mobile content gateway
CN105704504B (zh) 2016-01-28 2021-02-12 腾讯科技（深圳）有限公司 视频直播中插入推送信息的方法、装置、设备及存储介质
JP6513054B2 (ja) * 2016-06-16 2019-05-15 Kddi株式会社 コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム
BR112019003128A2 (pt) * 2016-09-15 2019-05-21 Nuts Holdings, Llc trânsito e armazenamento de dados de usuário criptografados
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
CN107391527B (zh) 2017-03-28 2020-03-27 创新先进技术有限公司 一种基于区块链的数据处理方法及设备
US20180359539A1 (en) * 2017-06-08 2018-12-13 Qualcomm Incorporated Smooth transition for content type changes in streaming content
JP6797755B2 (ja) * 2017-06-20 2020-12-09 キヤノン株式会社 撮像装置、撮像装置の処理方法およびプログラム
JP6400163B2 (ja) * 2017-08-09 2018-10-03 キヤノン株式会社 受信装置、受信方法、送信装置、送信方法、及びプログラム
CN111782725A (zh) 2018-02-27 2020-10-16 阿里巴巴集团控股有限公司 跨区块链的交互方法及装置、系统、电子设备
CN110662086A (zh) * 2019-10-31 2020-01-07 成都威爱新经济技术研究院有限公司 一种5g高清直播系统及视频处理方法
KR102287497B1 (ko) * 2019-12-11 2021-08-09 네이버 주식회사 플랫폼 적응형 오디오 정규화 방법 및 시스템
KR102432376B1 (ko) * 2020-10-19 2022-08-12 네이버 주식회사 콘텐츠 재생 방법 및 시스템
US11812081B2 (en) 2020-11-02 2023-11-07 Hulu, LLC Session based adaptive playback profile decision for video streaming

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010078281A2 (en) * 2008-12-31 2010-07-08 Apple Inc. Real-time or near real-time streaming
JP2013505681A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド スケーラブル符号化を用いた拡張ブロック−要求ストリーミング

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020002039A1 (en) * 1998-06-12 2002-01-03 Safi Qureshey Network-enabled audio device
WO2002057943A1 (en) * 2001-01-18 2002-07-25 Yahoo! Inc. Method and system for managing digital content, including streaming media
US7076478B2 (en) * 2001-06-26 2006-07-11 Microsoft Corporation Wrapper playlists on streaming media services
US7159174B2 (en) * 2002-01-16 2007-01-02 Microsoft Corporation Data preparation for media browsing
JP2003288290A (ja) * 2002-03-28 2003-10-10 Nippon Telegr & Teleph Corp <Ntt> ファイル配信方法
KR100689430B1 (ko) * 2004-12-16 2007-03-08 삼성전자주식회사 디지털 홈 서비스에서 하이브리드 모니터링을 통한 동적서비스 품질 매핑 장치 및 방법
CN102752639B (zh) * 2005-07-18 2015-08-05 汤姆森许可贸易公司 使用元数据来处理多个视频流的方法和设备
US20070174147A1 (en) * 2005-12-30 2007-07-26 Realnetworks System and method for updating a playlist based upon ratings
US20070282905A1 (en) * 2006-06-06 2007-12-06 Sony Ericsson Mobile Communications Ab Communication terminals and methods for prioritizing the playback of distributed multimedia files
JP2008251082A (ja) * 2007-03-30 2008-10-16 Hitachi Ltd 録画システムおよび録画再生方法
TWI383684B (zh) * 2008-11-18 2013-01-21 Univ Nat Taiwan 多媒體串流之動態視訊編碼系統與方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010078281A2 (en) * 2008-12-31 2010-07-08 Apple Inc. Real-time or near real-time streaming
JP2013505681A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド スケーラブル符号化を用いた拡張ブロック−要求ストリーミング

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023015026A (ja) * 2016-01-04 2023-01-31 グレースノート インコーポレイテッド 関連した音楽およびストーリを有するプレイリストの生成および配信
JP7429271B2 (ja) 2016-01-04 2024-02-07 グレースノート インコーポレイテッド 関連した音楽およびストーリを有するプレイリストの生成および配信
JP2021508220A (ja) * 2018-05-29 2021-02-25 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． メディア再生のローディング制御方法、装置及び記憶媒体
JP2021508891A (ja) * 2018-05-29 2021-03-11 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． ウェブページで解像度を切り替えてメディアファイルを再生する方法、装置及び記憶媒体
JP2021510991A (ja) * 2018-05-29 2021-04-30 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． 非ストリームメディアファイルのウェブページ再生方法、装置及び記憶媒体
US11025991B2 (en) 2018-05-29 2021-06-01 Beijing Bytedance Network Technology Co., Ltd. Webpage playing method and device and storage medium for non-streaming media file
JP7008829B2 (ja) 2018-05-29 2022-01-25 北京字節跳動網絡技術有限公司 ウェブページで解像度を切り替えてメディアファイルを再生する方法、装置及び記憶媒体
JP7181308B2 (ja) 2018-05-29 2022-11-30 北京字節跳動網絡技術有限公司 メディア再生のローディング制御方法、装置及び記憶媒体
JP2021534698A (ja) * 2018-08-17 2021-12-09 ロク インコーポレイテッド メディアストリームの再生間の遷移中における遷移フレームの動的再生
US11503366B2 (en) 2018-08-17 2022-11-15 Roku, Inc. Dynamic playout of transition frames while transitioning between play out of media streams
JP7191226B2 (ja) 2018-08-17 2022-12-16 ロク インコーポレイテッド メディアストリームの再生間の遷移中における遷移フレームの動的再生
US11812103B2 (en) 2018-08-17 2023-11-07 Roku, Inc. Dynamic playout of transition frames while transitioning between playout of media streams

Also Published As

Publication number Publication date
JP2014509109A (ja) 2014-04-10
EP2646936A1 (en) 2013-10-09
TWI519145B (zh) 2016-01-21
JP6141926B2 (ja) 2017-06-07
TW201714457A (zh) 2017-04-16
TWI584638B (zh) 2017-05-21
TW201234839A (en) 2012-08-16
KR101528991B1 (ko) 2015-06-15
WO2012097006A1 (en) 2012-07-19
EP2646936B1 (en) 2018-11-07
KR20130118944A (ko) 2013-10-30
TW201608883A (zh) 2016-03-01
TWI610562B (zh) 2018-01-01

Similar Documents

Publication Publication Date Title
JP6141926B2 (ja) リアルタイム又はリアルタイムに近いストリーミング
US20200314161A1 (en) Real-time or near real-time streaming
US20210263981A1 (en) Playlists for real-time or near real-time streaming
US11019309B2 (en) Real-time or near real-time streaming
US8892691B2 (en) Real-time or near real-time streaming
US8843586B2 (en) Playlists for real-time or near real-time streaming
US8260877B2 (en) Variant streams for real-time or near real-time streaming to provide failover protection
US8856283B2 (en) Playlists for real-time or near real-time streaming
US8560642B2 (en) Real-time or near real-time streaming
WO2011123821A1 (en) Real-time or near real-time streaming
AU2015221573A1 (en) Playlists for real-time or near real-time streaming
GB2510766A (en) Determining earliest and latest transmission times for playlist files having plural tags and universal resource indicators (URIs)

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161024

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170322

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170403

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170508

R150 Certificate of patent or registration of utility model

Ref document number: 6141926

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250