TWI519145B - 即時或幾乎即時之串流傳輸 - Google Patents

Description

即時或幾乎即時之串流傳輸

本發明之實施例係關於資料傳輸技術。更特定言之，本發明之實施例係關於允許使用非串流傳輸協定(諸如，超文字傳送協定(HTTP))串流傳輸資料之技術。

本申請案主張2011年1月11日申請之美國臨時申請案第61/431,813號(檔案號碼P7437Z11)之申請日期的權利，且本申請案因此以引用方式將該臨時申請案併入本文中。本申請案亦與以下專利申請案相關：

(1) 2008年12月31日申請之申請案第61/142,110號(檔案號碼P7437Z)；

(2) 2009年3月16日申請之申請案第61/160,693號(檔案號碼P7437Z2)；

(3) 2009年3月17日申請之申請案第61/161,036號(檔案號碼P7437Z3)；

(4) 2009年4月7日申請之申請案第61/167,524號(檔案號碼P7437Z4)；

(5) 2009年9月8日申請之申請案第61/240,648號(檔案號碼P7437Z5)；

(6) 2009年12月21日申請之申請案第61/288,828號(檔案號碼P7437Z6)；

(7) 2010年4月1日申請之申請案第61/320,213號(檔案號碼P7437Z7)；

(8) 2010年4月7日申請之申請案第61/321,767號(檔案號碼P7437Z8)；及

(9) 2010年6月4日申請之申請案第61/351,824號(檔案號碼P7437Z9)；及

(10) 2010年8月31日申請之申請案第61/378,893號(檔案號碼P7437Z10)。所有此等美國臨時申請案係在其符合本發明之意義上以引用方式併入本文中。

本美國專利申請案係關於以下美國專利申請案，該等美國專利申請案中之每一者係在其符合本發明之意義上以引用方式併入本文中：

(1) 2009年6月5日申請之題為「即時或幾乎即時串流傳輸(REAL-TIME OR NEAR REAL-TIME STREAMING)」之申請案第12/479,690號(檔案號碼P7437US1)；

(2) 2009年6月5日申請之題為「即時或幾乎即時串流傳輸之變體串流(VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING)」之申請案第12/479,698號(檔案號碼P7437US2)；

(3) 2009年6月5日申請之題為「可更新即時或幾乎即時串流傳輸(UPDATABLE REAL-TIME OR NEAR REAL-TIME STREAMING)」之申請案第12/479,732號(檔案號碼P7437US3)；

(4) 2009年6月5日申請之題為「用於即時或幾乎即時串流傳輸之播放清單(PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING)」之申請案第12/479,735號(檔案號碼P7437US4)；

(5) 2010年9月8日申請之題為「用以提供容錯轉移保護之即時或幾乎即時串流傳輸之變體串流(VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING TO PROVIDE FAILOVER PROTECTION)」之申請案第12/878,002號(檔案號碼P7437X)；及

(6) 2010年12月14日申請之題為「具有壓縮播放清單之即時或幾乎即時串流傳輸(REAL-TIME OR NEAR REAL-TIME STREAMING WITH COMPRESSED PLAYLISTS)」之申請案第12/968,202號(檔案號碼P7437X2)。

內容之串流傳輸通常指代經常地自伺服器裝置傳輸且由用戶端裝置接收之多媒體內容。內容常常在其正由串流傳輸伺服器傳遞時向最終使用者呈現。名稱指代媒體之傳遞方法而不是指代媒體本身。

當前串流傳輸服務通常需要專門的伺服器以將「實況」內容散佈至最終使用者。在任何大規模部署中，此可造成巨大成本，且需要專門的技藝來設置及執行。此導致不盡如人意的可用於串流傳輸之內容庫。

在本文中所描述之一實施例中，一播放清單檔案可指示由該播放清單檔案提供之內容之一類型。內容之類型可定義播放清單檔案之類型，且播放清單檔案之類型可在播放清單檔案中之標籤之參數中加以規定。在一實施例中，標籤可採取#EXT-X-PLAYLIST-TYPE:[VOD|LIVE|EVENT]之形式，其中此標籤規定VOD或實況或事件中之一者，且其中「VOD」指示播放清單檔案係關於隨選視訊內容，「Live」指示播放清單檔案係關於實況內容，其可具有不確定之開始時間且可與在用戶端裝置處接收到媒體檔案以供呈現(例如，經由顯示視訊來播放)幾乎同時發生，且「Event」指示播放清單檔案係關於事件，其可具有不確定之結束時間，但具有確定之固定開始時間且可與在用戶端裝置處接收到媒體檔案以供呈現幾乎同時發生。播放清單檔案可包括通用資源指示符(URI)，該等URI指示可由一用戶端裝置在接收到播放清單檔案之後按由播放清單檔案指示之次序擷取的複數個媒體檔案，且播放清單檔案亦可包括具有與播放清單中之該複數個媒體檔案之播放相關之參數(諸如，「VOD」或「live」)的複數個標籤(諸如，#EXT-X-PLAYLIST-TYPE標籤)。

TYPE標籤(例如，#EXT-X-PLAYLIST-TYPE)在播放清單檔案中之存在有效地宣佈播放清單將堅持與內容之類型一致的操作方式，且此可允許用戶端裝置以對播放清單之類型而言可為最佳化之方式處理播放清單。用戶端裝置可檢查播放清單類型指示符(諸如，「VOD」或「Live」或「Event」)之存在，且可根據播放清單類型指示符以最佳方式處理播放清單檔案。舉例而言，當播放清單類型指示符為「VOD」時，用戶端裝置可經組態以不更新播放清單檔案，因為可假定隨選視訊之播放清單將不變化且因此不必請求更新。另外，當播放清單類型指示符為「VOD」時，用戶端裝置可經組態以檢查播放清單檔案以尋找ENDLIST標籤(或指示播放清單完成之其他標籤)，且若此標籤不在播放清單檔案中，則用戶端裝置可將播放清單檔案標記為有錯誤。

當播放清單類型指示符為「Live」時，用戶端裝置可經組態以重複地請求經更新之播放清單檔案。當播放清單類型指示符為「Event」時，用戶端裝置可經組態以(a)僅載入經更新之播放清單之一較新近部分(藉此避免較舊部分之接收)或(b)僅剖析經更新之播放清單之一較新近部分(藉此避免對經更新之播放清單之較舊部分之重新剖析)。

在一實施例中，用戶端裝置可經組態以儲存與對播放清單檔案中所規定之媒體檔案之資料存取或在接收媒體檔案時出現之網路錯誤相關之統計資料，且此等統計資料可經由API(應用程式介面)供用戶端應用程式使用，以允許呈現關於網路錯誤或對媒體檔案之存取(例如，顯示器在VOD或實況表演之變體串流之間切換多少次等)之資訊。

一些實施例在一環境中包括一或多個應用程式設計介面(API)，其中呼叫程式碼經由該一或多個介面而與被呼叫之其他程式碼互動。可經由該等API在呼叫程式與被呼叫程式碼之間傳送可進一步包括各種類別之參數的各種函式呼叫、訊息或其他類型之調用。另外，API可為呼叫程式碼提供使用在API中定義且實施於被呼叫程式碼中之資料類型或類別之能力。

至少特定實施例包括一呼叫軟體組件經由一API與一被呼叫軟體組件互動之一環境。一用於在此環境中經由一API進行操作之方法包括經由該API傳送一或多個函式呼叫、訊息、其他類型之調用或參數。

本文中描述其他方法，且本文中描述用於執行此等方法之系統，且本文中亦描述儲存在執行時可使一資料處理系統執行此等方法中之任一者之可執行指令的機器可讀非暫時性儲存媒體。

在隨附圖式之圖中藉由實例且非限制性地說明本發明，在該等圖中，類似參考數字指代類似元件。

在以下描述中，闡述眾多特定細節。然而，可在不具此等特定細節之情況下實踐本發明之實施例。在其他例子中，未詳細展示熟知電路、結構及技術以便不使對此描述之理解含糊不清。

本描述包括受版權保護之材料，諸如，圖形使用者介面影像之說明。版權之所有者(包括本發明之受讓人)特此保留對此等材料之權利(包括版權)。版權所有者不反對傳真複製專利文件或專利揭示案中之任一者(當其出現在專利及商標局檔案或記錄中時)，但無論如何另外保留全部版權。版權Apple Inc. 2009-2010。

在一實施例中，本文中所描述之技術及組件可包括用以使用非串流傳輸協定(例如，HTTP)及其他技術(例如，動畫專家組(MPEG)串流傳輸)傳遞串流傳輸體驗之機制。舉例而言，可使用HTTP廣播「實況」音樂或體育事件、實況新聞、網路攝影機饋送等來提供幾乎即時串流傳輸體驗。在一實施例中，一協定可將傳入媒體資料分段成多個媒體檔案且將彼等分段媒體檔案儲存於伺服器上。該協定亦可建置包括將用戶端引導至儲存於一伺服器上之分段媒體檔案之統一資源識別符(URI)的一播放清單檔案。當根據播放清單檔案播放該等分段媒體檔案時，用戶端可為使用者提供「實況」事件之幾乎即時廣播。可以類似方式提供預先記錄之內容。

在一實施例中，伺服器可以動態方式將補充或替代媒體內容(例如，廣告、與體育事件相關之統計資料、至主要呈現之額外媒體內容)引入至廣播事件中。舉例而言，在媒體事件之用戶端播放期間，伺服器可將額外URI添加至播放清單檔案，URI可識別一位置，用戶端可自該位置下載補充媒體檔案。用戶端可受指示而週期性地自伺服器擷取一或多個經更新之播放清單檔案以便存取伺服器已引入之任何補充或額外媒體內容(或其兩者)。

在一實施例中，伺服器可以累積模式或以捲動模式操作。在累積模式中，伺服器可建立一播放清單檔案且將媒體檔案識別符附加至該播放清單檔案之最後。用戶端接著在下載後可存取來自單一播放清單檔案之串流之所有部分(例如，使用者可從表演之中間開始)。在捲動模式中，伺服器可能藉由以捲動為基礎自播放清單檔案之開頭移除媒體檔案識別符來限制媒體檔案之可用性，藉此提供用戶端裝置可存取之媒體內容之滑動窗。伺服器亦可將媒體檔案識別符添加至播放清單，且在捲動模式中，伺服器可將媒體檔案之可用性限於最近已添加至播放清單之彼等媒體檔案。用戶端接著重複地下載播放清單檔案之經更新複本以繼續觀看。當內容在時間上潛在地無限制(例如，來自連續操作之網路攝影機之內容)時，播放清單下載之捲動基礎可為有用的。用戶端可繼續以捲動模式重複地請求播放清單，直至其在播放清單中找到結束標籤。

在一實施例中，該機制藉由提供相同呈現之變體串流來支援位元速率切換。舉例而言，待伺服之呈現之若干版本可儲存於伺服器上。每一版本可具有實質上相同之內容，但係以不同位元速率編碼。此可允許用戶端裝置取決於(例如)對可用頻寬之偵測而在位元速率之間切換，而不危害播放之連續性。

在一實施例中，可提供保護特徵以保護內容以防止未授權使用。舉例而言，非順序媒體檔案編號可用以防止預測。可使用媒體檔案之加密。可使用部分媒體檔案清單。亦可提供額外及/或不同保護特徵。

圖1為可發送及接收即時或幾乎即時內容之伺服器及用戶端之一實施例的方塊圖。圖1之實例提供簡單的伺服器-用戶端連接，其中兩個用戶端經由網路而與伺服器耦接。利用本文中所描述之技術及機制可支援任何數目個用戶端。此外，多個伺服器可提供內容及/或可一起操作以根據本文中所描述之技術及機制來提供內容。舉例而言，一個伺服器可建立內容、建立播放清單且建立多個媒體(例如，檔案)，且其他伺服器儲存並傳輸建立之內容。

網路110可為任何類型之網路，無論是有線、無線(例如，IEEE 802.11、802.16)抑或其任何組合。舉例而言，網路100可為網際網路或企業內部網路。作為另一實例，網路110可為蜂巢式網路(例如，3G、CDMA)。在一實施例中，用戶端裝置150及180可能能夠經由多個網路類型通信(例如，每一裝置可經由WiFi無線LAN通信且亦可經由無線蜂巢式電話網路通信)。舉例而言，用戶端裝置150及180可為可經由蜂巢式無線電話網路以及資料網路通信之智慧電話或具備蜂巢式電話功能之個人數位助理。此等裝置可能能夠在任一類型之網路上利用本文中所描述之串流傳輸機制或甚至按需要在網路之間切換。

伺服器120可以此項技術中已知之任何方式像HTTP伺服器一樣操作。亦即，伺服器120包括使用HTTP協定提供內容之HTTP伺服器代理145。雖然圖1之實例係依據HTTP描述，但可以類似方式利用其他協定。分段器130及索引器135為駐留於伺服器120(或多個伺服器)上的用以藉由播放清單檔案提供媒體檔案中之內容的代理，如本文中所描述。可經由使用HTTP協定之HTTP伺服器代理145(或經由其他伺服器)經由網路110提供此等媒體檔案及播放清單檔案。本文中所論述之代理可實施為硬體、軟體、韌體或其組合。

分段器130可用以將媒體資料之串流劃分成可經由HTTP協定傳輸之多個媒體檔案。索引器135可用以建立對應於分段媒體檔案之播放清單檔案，使得用戶端裝置可重新組譯媒體檔案以提供由伺服器120提供之內容之即時或幾乎即時傳輸。回應於來自用戶端裝置之一或多個請求，HTTP伺服器代理145(或其他伺服器)可傳輸由索引器135產生之一或多個播放清單檔案及由分段器130產生之內容之媒體檔案。伺服器120可進一步包括提供本文中所論述之安全功能(例如，加密)中之一或多者之可選安全代理140。伺服器120亦可包括圖1中未說明之額外組件。

用戶端裝置150及180可經由網路110自伺服器120接收播放清單檔案及媒體檔案。用戶端裝置可為任何類型之能夠經由網路接收資料且利用經由網路接收之資料產生輸出之電子裝置，例如，無線行動裝置、PDA、娛樂裝置、消費型電子裝置等。輸出可為任何媒體類型或媒體類型之組合，包括(例如)音訊、視訊或其任何組合。

用戶端裝置150可包括組譯器代理160及輸出產生器代理165。類似地，用戶端裝置180可包括組譯器代理190及輸出產生器代理195。組譯器代理160及180接收來自伺服器120之播放清單檔案且使用該等播放清單檔案存取來自伺服器120之媒體檔案及自伺服器120下載媒體檔案。輸出產生器代理165及195使用下載之媒體檔案產生分別自用戶端裝置150及160之輸出。輸出可由一或多個揚聲器、一或多個顯示幕、揚聲器與顯示幕之組合或任何其他輸入或輸出裝置提供。用戶端裝置亦可包括記憶體(例如，快閃記憶體或DRAM等)以充當用以在接收媒體檔案時儲存其(例如，壓縮之媒體檔案或解壓縮之媒體檔案)之緩衝器；緩衝器可提供超出當前正在呈現之內容之時間許多秒的量的可呈現內容，使得可稍後顯示經緩衝之內容，與此同時下載新內容。此緩衝器可在用戶端裝置正嘗試經由一間歇性緩慢之網路連接擷取內容時提供可呈現內容，且因此緩衝器可隱藏網路延時或連接問題。

用戶端裝置150及180可分別進一步包括可選安全代理170及185，該等安全代理提供本文中所論述之安全功能中之一或多者。用戶端裝置150及180亦可包括圖1中未說明之額外組件。

在一實施例中，本申請案中所描述之技術可用以經由非串流傳輸協定(例如，HTTP)來傳輸多媒體資料之無限制串流。實施例亦可包括加密媒體資料及/或提供串流之替代版本(例如，提供替代位元速率)。因為媒體資料可在建立之後不久傳輸，所以可以幾乎即時之方式接收資料。提供檔案之實例資料格式以及多媒體資料之串流之伺服器(發送者)及用戶端(接收器)將採取之動作；然而，亦可支援其他格式。

可作為模擬即時串流(或幾乎即時串流)傳輸之媒體呈現係由指示播放清單檔案之通用資源指示符(URI)規定。在一實施例中，播放清單檔案為額外URI之有序清單。播放清單檔案中之每一URI指代為一串流之一區段之媒體檔案，該串流可為用於特定節目之媒體資料之單一連續串流。

為了播放媒體資料之串流，用戶端裝置自伺服器獲取播放清單檔案。用戶端亦獲取且播放由播放清單檔案指示之每一媒體資料檔案。在一實施例中，用戶端可以動態方式或重複地重新載入播放清單檔案以發現額外及/或不同媒體區段。

播放清單檔案可為(例如)擴展M3U播放清單檔案。在一實施例中，使用有效地擴展M3U格式之額外標籤。M3U指代動畫專家組音訊層3統一資源定位器(MP3 URL)且為用以儲存多媒體播放清單之格式。M3U檔案為含有供媒體播放器播放之一或多個媒體檔案之位置的文字檔案。

在一實施例中，播放清單檔案為由個別行組成的擴展M3U格式之文字檔案。該等行可以單一LF字元或以繼之以LF字元之CR字元終止。每一行可為URI、空白行或以註解字元(例如，「#」)開始。URI識別待播放之媒體檔案。空白行可忽略。

以註解字元開始之行可為註解或標籤。標籤可以#EXT開始，而註解行可以#開始。註解行通常被伺服器及用戶端忽略。在一實施例中，播放清單檔案係以UTF-8格式編碼。UTF-8(8位元統一碼變換格式)為可變長度字元編碼格式。在替代實施例中，可使用其他字元編碼格式。

在以下實例中，利用包括兩個標籤：EXTM3U及EXTINF之擴展M3U格式。可藉由包括「#EXTM3U」之第一行而將擴展M3U檔案區別於基本M3U檔案。

EXTINF為描述由該標籤之後的URI識別的媒體檔案之記錄標記。在一實施例中，每一媒體檔案URI之前存在一EXTINF標籤，例如：

#EXTINF:<持續時間>,<標題>

其中「持續時間」規定媒體檔案之持續時間且「標題」為目標媒體檔案之標題。

在一實施例中，以下標籤可用以管理媒體檔案之傳送及播放：

EXT-X-TARGETDURATION

EXT-X-MEDIA-SEQUENCE

EXT-X-KEY

EXT-X-PROGRAM-DATE-TIME

EXT-X-ALLOW-CACHE

EXT-X-STREAM-INF

EXT-X-ENDLIST

EXT-X-DISCONTINUITY

EXT-X-VERSION

下文將分別更詳細地描述此等標籤。儘管關於每一新標籤描述了特定格式及屬性，但亦可支援具有不同屬性、名稱、格式等之替代實施例。

在一實施例中，EXT-X-TARGETDURATION標籤可指示將添加至呈現之下一個媒體檔案之近似持續時間。該標籤可包括於播放檔案中且格式可為：

#EXT-X-TARGETDURATION:<秒>

其中「秒」指示媒體檔案之持續時間。在一實施例中，實際持續時間可稍微不同於該標籤所指示之目標持續時間。在一實施例中，指示一區段之每個URI將與該區段之近似持續時間相關聯；舉例而言，一區段之URI可以一指示該區段之近似持續時間之標籤作為前置詞。在另一實施例中，EXT-X-TARGETDURATION標籤可規定最大媒體檔案持續時間；播放清單檔案中之每一媒體檔案之EXTINF持續時間應小於或等於目標持續時間，且此標籤(其規定最大媒體檔案持續時間)可僅在播放清單檔案中規定一次，且該標籤適用於播放清單檔案中之所有媒體檔案，且該標籤之格式可為：

#EXT-X-TARGETDURATION:<s>

其中「s」為指示以秒計之目標持續時間之整數。

播放清單檔案中之每一媒體檔案URI可具有唯一序號。在一實施例中，URI之序號(若存在)等於在其之前的URI之序號加上1。EXT-X-MEDIA-SEQUENCE標籤可指示出現在播放清單檔案中之第一URI之序號，且格式可為：

#EXT-X-MEDIA-SEQUENCE:<數字>

其中「數字」為URI之序號。若播放清單檔案不包括#EXT-X-MEDIA-SEQUENCE標籤，則可將播放清單中之第一URI之序號視為1。在一實施例中，不需要媒體檔案之序號出現在其URI中，且在一實施例中，播放清單可僅含有一個EXT-X-MEDIA-SEQUENCE標籤。在一實施例中，序列編號可為非順序的；舉例而言，非順序之序列編號(諸如，1、5、7、17等)可使得難以預測序列中之下一個數字且此可幫助保護內容不被盜版。幫助保護內容之另一選項為在任何給定時間僅顯露播放清單之部分。

一些媒體檔案可能經加密。EXT-X-KEY標籤提供可用以解密在其之後的媒體檔案之資訊，且格式可為：

#EXT-X-KEY:METHOD=<方法>[,URI=「<URI>」][,IV=<IV>]

方法參數規定加密方法，且URI參數(若存在)規定如何獲取密鑰，且IV(初始化向量)(若存在)規定加密方法中所使用之初始化向量(例如，具有密鑰)。

NONE之加密方法指示未加密，且若指示NONE，則在一實施例中，URI參數及IV參數不應存在。可使用各種加密方法，例如AES-128，其指示使用利用128位元密鑰及PKCS7填補之進階加密標準加密(參見RFC3852)的加密。新EXT-X-KEY標籤取代任何先前EXT-X-KEY標籤。

具有URI參數之EXT-X-KEY標籤識別密鑰檔案。密鑰檔案可含有將用以解密播放清單檔案中所列出之後續媒體檔案之編密密鑰。舉例而言，AES-128加密方法使用16-八位元密鑰。密鑰檔案之格式可為二進位格式之16個八位元之封裝陣列。

AES-128之使用通常需要在加密及解密時供應相同的16-八位元初始化向量(IV)。改變IV可用以增加密碼之強度。當使用AES-128加密時，媒體檔案之序號可在加密或解密媒體檔案時用作為IV。

EXT-X-PROGRAM-DATE-TIME標籤可使下一個媒體檔案之開頭與絕對日期及/或時間相關聯，且可包括或指示時區。在一實施例中，日期/時間表示為ISO/IEC 8601:2004。此標籤中之日期及時間之值可提供媒體之時刻表至適當時鐘時間之資訊映射，該值可用作為用於基於日期及時間尋找用於播放之內容、用於顯示用於播放之內容或用於其他目的之基礎。在一實施例中，若伺服器提供此映射，則伺服器應將EXT-X-PROGRAM-DATE-TIME標籤置放於播放清單檔案中之每個EXT-X-DISCONTINUITY標籤之後。標籤格式可為：

EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

EXT-X-ALLOW-CACHE標籤可用以指示用戶端是否可快取所下載之媒體檔案以用於稍後播放。在一實施例中，此標籤可出現在播放清單檔案中之任何處，但在一實施例中，此標籤應僅在播放清單檔案中出現一次。標籤格式可為：

EXT-X-ALLOW-CACHE:<是|否>

在一實施例中，EXT-X-ENDLIST標籤指示沒有更多媒體檔案將添加至播放清單檔案。標籤格式可為：

EXT-X-ENDLIST

在一實施例中，若播放清單含有最後區段或媒體檔案，則播放清單將具有EXT-X-ENDLIST標籤。在一實施例中，此標籤可出現在播放清單檔案中之任何處，且在一實施例中，此標籤可僅在播放清單檔案中出現一次。

EXT-X-STREAM-INF標籤可用以指示播放清單檔案中之下一個URI識別另一播放清單檔案。在一實施例中，標籤格式可為：

EXT-X-STREAM-INF:[attribute=value][,attribute=value]*<URI>

其中可使用以下屬性。在此標籤的一實施例中，相同類型之屬性在同一標籤中不應出現一次以上。屬性BANDWIDTH=<n>為表示為每秒位元數之串流位元速率之近似上限。在一實施例中，屬性BANDWIDTH可為每一媒體檔案之總位元速率之上限，其經計算以包括出現或將出現在播放清單中之容器附加項。屬性PROGRAM-ID=<i>為在播放清單檔案之範疇內唯一地識別特定呈現之數字。播放清單檔案可包括具有相同PROGRAM-ID之多個EXT-X-STREAM-INF URI以描述相同呈現之變體串流，且此等變體播放清單可含有額外EXT-X-STREAM-INF標籤。將在本發明中進一步描述變體串流及變體播放清單(例如，參見圖9A至圖9D)。屬性CODECS=「[格式][,格式]*」可用以規定存在於播放清單檔案中之媒體檔案中之媒體樣本類型，其中每一格式規定一媒體樣本類型；在一實施例中，有效格式識別符可為由RFC 4281定義之ISO檔案格式名稱空間中之彼等識別符。屬性RESOLUTION=<N>×<M>可規定串流內之視訊之解析度，其中N為串流內之視訊之近似編碼水平解析度，其可表示為像素之數目，且M為近似編碼垂直解析度。

EXT-X-DISCONTINUITY標籤指示在該標籤之後的媒體檔案與在該標籤之前的媒體檔案之間的編碼不連續性。可變化之特性之集合為：

‧檔案格式

‧播放軌之數目及類型

‧編碼參數

‧編碼序列

‧時間戳記序列

該標籤之格式為：

#EXT-X-DISCONTINUITY

EXT-X-VERSION標籤指示播放清單檔案之相容性版本。在一實施例中，播放清單檔案、其相關聯媒體及其伺服器應遵守描述標籤值所指示之協定版本的此文件之最近版本之所有條款。

該標籤之格式為：

#EXT-X-VERSION:<n>

其中「n」為指示協定版本之整數。

在一實施例中，播放清單檔案可含有不多於一個的EXT-X-VERSION標籤。在一實施例中，不含有EXT-X-VERSION標籤之播放清單檔案應遵守此協定之版本1。若播放清單檔案具有此標籤，則在一實施例中，此標籤之值應為伺服器、播放清單檔案及相關聯媒體檔案全部遵守的最低協定版本。

前述標籤及屬性可由伺服器裝置使用以組織、傳輸且處理代表原始媒體內容之媒體檔案。用戶端裝置使用此資訊以按將即時或幾乎即時串流傳輸體驗(例如，諸如音樂或體育事件之實況廣播之觀看)提供至用戶端裝置之使用者的方式重新組譯且呈現媒體檔案。

播放清單檔案中之每一媒體檔案URI識別為原始呈現(亦即，原始媒體內容)之一區段之媒體檔案。在一實施例中，每一媒體檔案經格式化為MPEG-2輸送串流、MPEG-2節目串流或MPEG-2音訊基本串流。可藉由規定CODEC來規定格式，且播放清單可藉由規定CODEC來規定格式。在一實施例中，呈現中之所有媒體檔案具有相同格式；然而，在其他實施例中，可支援多個格式。在一實施例中，輸送串流檔案應含有單一MPEG-2節目，且在每一檔案開始時應存在節目關聯表及節目映射表。含有視訊之檔案應具有至少一關鍵圖框及足以完全初始化視訊解碼器之資訊。播放清單中之媒體檔案必須為解碼串流的在具有先前序號之媒體檔案之結尾處之繼續，除非該媒體檔案為出現在播放清單檔案中之第一媒體檔案或在該媒體檔案之前有一EXT-X-DISCONTINUITY標籤之情況下。用戶端應準備好藉由選擇一合理子集來處置特定類型(例如，音訊或視訊)之多個播放軌。在一實施例中，用戶端應忽略輸送串流內之其不能辨識之專用串流。用於媒體檔案內之串流內及跨多個媒體檔案之對應串流之間的樣本之編碼參數應保持一致。然而，用戶端應在遇到編碼變化時處理該等編碼變化，例如，藉由縮放視訊內容以適應解析度變化。

圖2A為用於一或多個伺服器裝置的用以使用非串流傳輸協定支援媒體內容之技術之一實施例的流程圖。圖2A之實例係依據HTTP提供；然而，可以類似方式利用其他非串流傳輸協定。圖2A之實例係依據執行特定任務之單一伺服器提供。然而，可利用任何數目個伺服器。舉例而言，將媒體檔案提供至用戶端裝置之伺服器可為不同於將內容分段成多個媒體檔案之伺服器的裝置。

在操作200中，伺服器裝置接收待提供之內容。該內容可代表實況音訊及/或視訊(例如，體育事件、實況新聞、網路攝影機饋送)。該內容亦可代表預先記錄之內容(例如，已記錄之音樂會、訓練講座等)。該內容可由伺服器根據此項技術中已知之任何格式及協定(串流傳輸或未串流傳輸)接收。在一實施例中，內容係以MPEG-2串流之形式由伺服器接收；然而，亦可支援其他格式。

在操作210中，伺服器可接著暫時儲存該內容之至少部分。該內容或該內容之至少部分可暫時儲存於儲存裝置(例如，儲存區域網路中之硬碟等)上或記憶體中。或者，可經由儲存媒體(例如，緊密光碟、隨身碟)接收該內容，該內容可自該儲存媒體傳送至儲存裝置或記憶體。在一實施例中，伺服器具有在必要時將該內容轉換成一或多個串流(例如，MPEG-2)之編碼器。此轉換可在不永久儲存接收之內容的情況下發生，且在一些實施例中，可能省略儲存操作210，或在其他實施例中，儲存操作210可能為一較長期儲存(例如，存檔儲存)。

在操作220中，將待提供之內容分段成多個媒體檔案。在一實施例中，伺服器將串流轉換成可使用標準網路伺服器散佈之分離且相異之媒體檔案(亦即，區段)。在一實施例中，伺服器在支援個別媒體檔案之有效解碼之點(例如，在諸如PES封包邊界及i圖框邊界的封包及關鍵圖框邊界上)將媒體串流分段。該等媒體檔案可為原始串流之具有近似相等持續時間之部分。伺服器亦為每一媒體檔案建立URI。此等URI允許用戶端裝置存取該等媒體檔案。

因為區段係使用固有地傳遞整個檔案之HTTP伺服器伺服，所以在可將媒體檔案伺服至用戶端之前，伺服器應具有可用的完整之分段媒體檔案。因此，用戶端(在時間上)可延滯於廣播至少一媒體檔案長度。在一實施例中，媒體檔案大小係基於延滯時間與具有過多檔案之間的平衡。

在一實施例中，支援兩個作業階段類型(實況作業階段及事件作業階段)。對於實況作業階段，僅保留串流之固定大小部分。在一實施例中，自節目播放清單檔案移除過時的內容媒體檔案，且可自伺服器移除過時的內容媒體檔案。第二類型之作業階段為事件作業階段，其中用戶端可調諧至廣播中之任一點(例如，自開頭開始、自中點開始)。此類型之作業階段可用於(例如)重播。

在操作230中，將媒體檔案儲存於伺服器記憶體中。在操作230中之儲存檔案之前，媒體檔案可由安全特徵(諸如，加密)保護。將媒體檔案儲存為準備好使用由伺服器裝置上之網路伺服器應用程式支援(或由進行傳輸之另一裝置支援)之網路協定(例如，HTTP或HTTPS)傳輸之檔案。

在操作240中，產生一或多個播放清單檔案以指示應藉以組譯媒體檔案以重新建立原始內容之次序。播放清單檔案可利用擴展M3U標籤及本文中所描述之標籤來為用戶端裝置提供資訊以存取並重新組譯媒體檔案以在用戶端裝置上提供串流傳輸體驗。每一媒體檔案之URI係以將用以播放媒體檔案之次序包括於播放清單檔案中。伺服器亦可為播放清單檔案建立一或多個URI以允許用戶端裝置存取播放清單檔案。

在操作250中，可將播放清單檔案儲存於伺服器上。儘管在圖2A中按特定次序呈現媒體檔案及播放清單檔案之建立及儲存，但亦可能使用不同次序。舉例而言，可在建立或儲存媒體檔案之前建立播放清單檔案。作為另一實例，可在儲存播放清單檔案及媒體檔案之任一者之前建立播放清單檔案及媒體檔案。

若媒體檔案待加密，則播放清單檔案可定義一URI，其允許經授權用戶端裝置獲取含有用以解密媒體檔案之加密密鑰之密鑰檔案。加密密鑰可使用安全連接(例如，HTTPS)傳輸。作為另一實例，播放清單檔案可使用HTTPS傳輸。作為又一實例，可按不可預測之次序配置媒體檔案，使得用戶端在無播放清單檔案之情況下不能重新建立串流。

若加密方法為AES-128，則可將(例如)AES-128 CBC加密應用於個別媒體檔案。在一實施例中，加密整個檔案。在一實施例中，通常不跨媒體檔案應用密碼區塊鏈結。媒體檔案之序號可用作為IV，或如上所述，IV可為EXT-X-KEY標籤之IV屬性之值。在一實施例中，伺服器將具有密鑰URI之EXT-X-KEY標籤添加至播放清單檔案之最後。伺服器接著用該密鑰加密所有後續媒體檔案，直至作出加密組態之變化為止。

為了切換至新加密密鑰，伺服器可經由相異於呈現中所使用之所有先前密鑰URI的新URI來使新密鑰可用。伺服器亦將具有新密鑰URI之EXT-X-KEY標籤添加至播放清單檔案之最後且用新密鑰加密所有後續媒體檔案。

為了結束加密，伺服器可在播放清單檔案之最後添加具有加密方法NONE之EXT-X-KEY標籤。在一實施例中，該標籤(以「NONE」作為方法)不包括URI參數。如上所述，在作出加密組態之變化之前，不加密所有後續媒體檔案。若一播放清單檔案含有至用該密鑰加密之媒體檔案之URI，則伺服器不自該播放清單檔案移除EXT-X-KEY標籤。在操作270中，伺服器可回應於用戶端請求經由網路傳輸播放清單檔案及媒體檔案，如關於圖3A所更詳細描述。

在一實施例中，伺服器回應於接收來自用戶端裝置之對播放清單檔案之請求而將播放清單檔案傳輸至用戶端裝置。用戶端裝置可使用已提供至用戶端裝置之URI來存取/請求播放清單檔案。URI指示播放清單檔案在伺服器上之位置。作為回應，伺服器可將播放清單檔案提供至用戶端裝置。用戶端裝置可利用播放清單檔案中之標籤及URI(或其他識別符)存取多個媒體檔案。

在一實施例中，伺服器可將媒體檔案之可用性限於最近已添加至播放清單檔案之彼等媒體檔案。為了如此限制，每一播放清單檔案可包括僅一個EXT-X-MEDIA-SEQUENCE標籤，且值可針對自播放清單檔案移除之每個媒體檔案URI而遞增1。可按添加媒體檔案URI之次序自播放清單檔案移除媒體檔案URI。在一實施例中，當伺服器自播放清單檔案移除媒體檔案URI時，媒體檔案在一等於媒體檔案之持續時間加上該媒體檔案已出現於之最長播放清單檔案之持續時間的時間段內保持可供用戶端使用。

一播放清單檔案之持續時間為該播放清單檔案內之媒體檔案之持續時間之總和。亦可使用其他持續時間。在一實施例中，除非EXT-X-ENDLIST標籤存在，否則伺服器可一直在播放清單中維持至少三個主要呈現媒體檔案。

圖2B為用於一或多個伺服器裝置的用以以動態方式將經更新之播放清單提供至一或多個用戶端裝置之技術之一實施例的流程圖。可使用本文中所描述之累積模式或捲動模式中之任一者來更新播放清單。圖2B之實例係依據HTTP提供；然而，可以類似方式利用其他非串流傳輸協定(例如，HTTPS等)。圖2B之實例係依據執行特定任務之伺服器提供。然而，可利用任何數目個伺服器。舉例而言，將媒體檔案提供至用戶端裝置之伺服器可為不同於將內容分段成多個媒體檔案之伺服器的裝置。

在操作205中，伺服器裝置接收待提供之內容。在操作215中，伺服器可接著暫時儲存該內容之至少部分。操作215可類似於圖2A中之操作210。在操作225中，將待提供之內容分段成多個媒體檔案。在操作235中，可將媒體檔案儲存於伺服器記憶體中。在操作235中之儲存檔案之前，媒體檔案可由安全特徵(諸如，加密)保護。

在操作245中，產生一或多個播放清單檔案以指示應藉以組譯媒體檔案以重新建立原始內容之次序。在操作255中，可將播放清單檔案儲存於伺服器上。儘管在圖2B中按特定次序呈現媒體檔案及播放清單檔案之建立及儲存，但亦可能使用不同次序。

在操作275中，伺服器(或另一伺服器)可回應於用戶端請求經由網路傳輸播放清單檔案及媒體檔案，如關於圖3A至圖3B所更詳細描述。

可出於各種原因由伺服器更新播放清單檔案。在操作285中，伺服器可接收待提供至用戶端裝置之額外資料。可在操作255中儲存播放清單檔案之後接收額外資料。額外資料可為(例如)實況呈現之額外部分或用於現有呈現之額外資訊。額外資料可包括廣告或統計資料(例如，與體育事件相關之分數或資料)。額外資料可覆疊(經由半透明性)在呈現上或呈現於側邊列使用者介面中。可以與最初接收之資料相同的方式將額外資料分段。若額外資料組成廣告或待插入至播放清單所代表之節目中之其他內容，則額外資料可在操作215中被儲存(至少暫時地)、在操作225中被分段且在操作235中被儲存；在儲存分段額外資料之前，可加密額外資料之區段。接著，在操作245中，將產生含有節目及額外資料的經更新之播放清單。在操作255中，基於額外資料更新播放清單且再次儲存播放清單。自用戶端裝置之觀點，播放清單檔案之變化應原子地(atomically)進行。在一實施例中，經更新之播放清單替換先前播放清單。如下文更詳細所論述，用戶端裝置可多次請求播放清單。此等請求使用戶端裝置能夠利用最新近的播放清單。在一實施例中，額外資料可為後設資料；在此情況下，不必更新播放清單，但可更新區段以包括後設資料。舉例而言，後設資料可含有可與區段中之時間戳記匹配的時間戳記，且後設資料可添加至具有匹配時間戳記之區段。

經更新之播放清單亦可導致媒體檔案之移除。在一實施例中，伺服器應按將媒體檔案添加至播放清單之次序自播放清單移除媒體檔案之URI。在一實施例中，若伺服器移除整個呈現，則伺服器使播放清單不可供用戶端裝置使用。在一實施例中，伺服器在含有待移除之媒體檔案之最長播放清單檔案之持續時間中維持媒體檔案及播放清單檔案，以允許當前用戶端裝置完成對呈現之存取。因此，播放清單檔案中之每個媒體檔案URI可以用以指示播放清單檔案所指示之媒體檔案之近似累積持續時間之EXT-X-STREAM-INF標籤作為前置詞。在替代實施例中，可立即移除媒體檔案及播放清單檔案。

來自用戶端裝置之對播放清單之後續請求導致在操作275中伺服器提供經更新之播放清單。在一實施例中，定期(例如，與目標持續時間相關之時間週期)更新播放清單。播放清單檔案之週期性更新允許伺服器為動態變化之呈現提供對伺服器之存取。

圖2C為用於一或多個伺服器裝置的用以使用多個位元速率將媒體內容提供至用戶端裝置之技術之一實施例的流程圖，該實施例為替代串流之使用之一形式。圖2C之實例係依據HTTP提供；然而，可以類似方式利用其他非串流傳輸協定。圖2C之實例係依據執行特定任務之伺服器提供。然而，可利用任何數目個伺服器。舉例而言，將媒體檔案提供至用戶端裝置之伺服器可為不同於將內容分段成多個媒體檔案之伺服器的裝置。

在一實施例中，伺服器可提供多個播放清單檔案或單一播放清單檔案(在該單一播放清單檔案中有多個媒體檔案清單)以提供相同呈現之不同編碼。若提供不同編碼，則播放清單檔案可包括提供不同位元速率之每一變體串流以允許用戶端裝置動態地在編碼之間切換(此將結合圖9A至圖9D進一步描述)。具有變體串流之播放清單檔案可包括用於每一變體串流之EXT-X-STREAM-INF標籤。用於相同呈現之每一EXT-X-STREAM-INF標籤可具有相同PROGRAM-ID屬性值。用於每一呈現之PROGRAM-ID值在變體串流內為唯一的。

在一實施例中，伺服器在產生變體串流時滿足以下約束。每一變體串流可由包括不為主要呈現之部分之可選內容之相同內容組成。伺服器可在所有變體串流之最小目標持續時間之準確度範圍內使相同時段之內容可供所有變體串流使用。在一實施例中，變體串流之媒體檔案為具有匹配所有變體串流中之對應內容之樣本時間戳記的MPEG-2輸送串流或MPEG-2節目串流。又，在一實施例中，所有變體串流應含有相同音訊編碼。此允許用戶端裝置在變體串流之間切換而不丟失內容。

參看圖2C，在操作202中，伺服器裝置接收待提供之內容。在操作212中，伺服器可接著至少暫時儲存該內容。在操作222中，將待提供之內容分段成多個媒體檔案。在操作232中，針對選定位元速率(或其他編碼參數之選定值)編碼每一媒體檔案且將每一媒體檔案儲存於伺服器上。舉例而言，媒體檔案可以高、中及低頻寬連接為目標。可在儲存之前加密媒體檔案。可選擇以各種類型之連接為目標之媒體檔案之編碼以在目標頻寬層級提供串流傳輸體驗。

在一實施例中，在操作242中，產生具有本文中所描述之指示各種編碼層級之標籤的變體播放清單。該等標籤可包括(例如)用於每一編碼層級之具有至對應媒體播放清單檔案之URI之EXT-X-STREAM-INF標籤。

此變體播放清單可包括至用於各種編碼層級之媒體播放清單檔案之URI。因此，用戶端裝置可自指示編碼層級之變體播放清單中所提供之替代者中選擇一目標位元速率且擷取對應播放清單檔案。在一實施例中，用戶端裝置可在播放期間在位元速率之間變化(例如，如關於圖9A至圖9D所描述)。在操作252中，將指示各種編碼層級之變體播放清單儲存於伺服器上。在操作242中，亦可產生變體播放清單中所參考之播放清單中之每一者，且接著在操作252中儲存該等播放清單中之每一者。

在操作272中，回應於來自用戶端裝置之請求，伺服器可傳輸指示各種編碼層級之變體播放清單。在操作282中，伺服器可接收對變體播放清單中所規定之媒體播放清單中之一對應於選定位元速率之媒體播放清單的請求。在操作292中，回應於該請求，伺服器傳輸對應於來自用戶端裝置之請求的媒體播放清單檔案。用戶端裝置接著可使用該媒體播放清單向該伺服器請求媒體檔案。在操作297中，伺服器回應於請求將該等媒體檔案提供至用戶端裝置。

圖3A為用於用戶端裝置的用以使用非串流傳輸協定支援內容之串流傳輸之技術之一實施例的流程圖。圖3A之實例係依據HTTP提供；然而，可以類似方式利用其他非串流傳輸協定。圖3A至圖3B所示之方法可由一個用戶端裝置或由若干分離之用戶端裝置執行。舉例而言，在此等方法中之任一者的情況下，單一用戶端裝置可能執行所有該等操作(例如，請求一播放清單檔案、使用該播放清單檔案中之URI請求媒體檔案、組譯該等媒體檔案以產生及提供一呈現/輸出)，或若干相異用戶端裝置可執行該等操作中之一些而非全部(例如，第一用戶端裝置可請求一播放清單檔案且使用該播放清單檔案中之URI請求媒體檔案且可儲存彼等媒體檔案以供第二用戶端裝置使用，該第二用戶端裝置可處理該等媒體檔案以產生及提供一呈現/輸出)。

在操作300中，用戶端裝置可向伺服器請求播放清單檔案。在一實施例中，該請求係根據符合HTTP之協定作出。該請求利用至儲存於伺服器上之初始播放清單檔案之URI。在替代實施例中，可支援其他非串流傳輸協定。回應於該請求，伺服器將經由網路將對應播放清單檔案傳輸至用戶端。如上文所論述，網路可為有線或無線的，且可為有線網路或無線網路之任何組合。此外，網路可為資料網路(例如，IEEE 802.11、IEEE 802.16)或蜂巢式電話網路(例如，3G)。

在操作310中，用戶端裝置可接收播放清單檔案。在操作320中，可將播放清單檔案儲存於用戶端裝置之記憶體中。該記憶體可為(例如)硬碟、快閃記憶體、隨機存取記憶體。在一實施例中，每當自播放清單URI載入或重新載入一播放清單檔案時，用戶端檢查以判定該播放清單檔案以#EXTM3U標籤開始且在缺少該標籤的情況下不繼續。如上文所論述，該播放清單檔案包括一或多個標籤以及至媒體檔案之一或多個URI。

用戶端裝置可包括一組譯器代理，其藉由在操作330中請求該播放清單檔案中之該等URI所指示之媒體檔案來使用該播放清單檔案重新組譯原始內容。在一實施例中，該組譯器代理為一外掛程式模組，其為標準網頁瀏覽器應用程式之部分。在另一實施例中，該組譯器代理可為獨立應用程式，其與網頁瀏覽器互動以使用播放清單檔案接收且組譯媒體檔案。作為又一實例，該組譯器代理可為嵌入於用戶端裝置中之專用硬體或韌體組件。

組譯器可使來自該播放清單檔案之媒體檔案得以自該等URI所指示之伺服器下載。若該播放清單檔案含有EXT-X-ENDLIST標籤，則可首先播放該播放清單檔案所指示之任何媒體檔案。若EXT-X-ENDLIST標籤不存在，則可首先播放除了最後一個及倒數第二個媒體檔案之外的任何媒體檔案。一旦已選擇了要播放之第一媒體檔案，在一實施例中，就按媒體檔案出現在播放清單檔案中之次序載入該播放清單檔案中之後續媒體檔案(否則，內容將無序地呈現)。在一實施例中，用戶端裝置嘗試在需要媒體檔案之前載入媒體檔案(且將其儲存於緩衝器中)以提供不中斷之播放且補償網路延時及輸送量之暫時變化。

在操作340中，可將下載之媒體檔案儲存於用戶端裝置上之記憶體中。記憶體(內容可儲存於其中)可為用戶端裝置上之任何類型之記憶體，例如，隨機存取記憶體、硬碟或視訊緩衝器。儲存可為暫時的以允許播放，或可為永久的。若播放清單檔案含有EXT-X-ALLOW-CACHE標籤且標籤之值為NO，則用戶端在下載之媒體檔案已播放之後不儲存該等下載之媒體檔案。若播放清單含有EXT-X-ALLOW-CACHE標籤且該標籤之值為YES，則用戶端裝置可無限期地儲存媒體檔案以供稍後重放。用戶端裝置可使用EXT-X-PROGRAM-DATE-TIME標籤之值以向使用者顯示節目起源時間。在一實施例中，用戶端可緩衝多個媒體檔案以使得其較不易受網路抖動影響，以便提供較佳使用者體驗。

在一實施例中，若解密方法為AES-128，則將AES-128 CBC解密應用於個別媒體檔案。解密整個檔案。在一實施例中，不跨媒體檔案應用密碼區塊鏈結。如上所述，可使用媒體檔案之序號作為初始化向量。

在操作350中，可將來自記憶體之內容自用戶端裝置輸出。輸出或呈現可為(例如)經由內建揚聲器或頭戴式耳機之音訊輸出。輸出可包括經由螢幕輸出或自用戶端裝置投射之視訊。可利用此項技術中已知之任何類型之輸出。在操作351中，用戶端裝置判定儲存之當前播放清單中是否還存在尚未播放或以其他方式呈現之媒體檔案。若此等媒體檔案存在(且若尚未請求此等媒體檔案)，則處理返回請求一或多個媒體檔案之操作330且處理程序重複。若不存在此等媒體檔案(亦即，當前播放清單中之所有媒體檔案已播放)，則處理進行至判定播放清單檔案是否包括一結束標籤之操作352。

若在操作352中，播放清單包括一結束標籤(例如，EXT-X-ENDLIST)，則播放在已播放了播放清單檔案所指示之媒體檔案時中止。若結束標籤不在播放清單中，則用戶端裝置再次向伺服器請求播放清單且回復到操作300以獲取節目之另一或經更新之播放清單。

如關於圖2B更詳細論述，伺服器可更新播放清單檔案以引入補充內容(例如，對應於實況廣播中之額外媒體內容之額外媒體檔案識別符)或額外內容(例如，串流中更後面之內容)。為了存取補充內容或額外內容，用戶端可重新載入來自伺服器的經更新之播放清單。此可提供可藉以動態地更新播放清單檔案之機制，即使在與播放清單檔案相關聯之媒體內容之播放期間亦然。用戶端可基於觸發器之數目來請求播放清單檔案之重新載入。沒有結束標籤為一個此種觸發器。

在一實施例中，除非播放清單檔案含有EXT-X-ENDLIST標籤，否則用戶端裝置週期性地重新載入播放清單檔案。當用戶端裝置第一次載入一播放清單檔案，或重新載入一播放清單檔案且發現該播放清單檔案自其上次載入以來已變化時，用戶端在嘗試再次重新載入該播放清單檔案之前可等待一段時間。將此時段稱為初始最小重新載入延遲。自用戶端開始載入播放清單檔案之時間起量測此初始最小重新載入延遲。

在一實施例中，初始最小重新載入延遲為播放清單檔案中之上一個媒體檔案之持續時間或目標持續時間的三倍中的較小者。媒體檔案持續時間係由EXTINF標籤規定。若用戶端重新載入一播放清單檔案且發現該播放清單檔案尚未變化，則用戶端可在重試之前等待一段時間。在一實施例中，最小延遲為目標持續時間的三倍或初始最小重新載入延遲的倍數中的較小者。在一實施例中，此倍數對第一嘗試為0.5、對第二嘗試為1.5且對後續嘗試為3.0；然而，可使用其他倍數。

每當載入或重新載入一播放清單檔案時，用戶端裝置檢查該播放清單檔案以判定要載入的下一個媒體檔案。如上所述，要載入的第一檔案為經選定首先播放之媒體檔案。若已載入待播放之第一媒體檔案且播放清單檔案不含有EXT-X-MEDIA-SEQUENCE標籤，則用戶端可驗證：當前播放清單檔案在最初發現上一次載入之媒體檔案之位移處含有上一次載入之媒體檔案之URI，在未發現該檔案之情況下暫停播放。要載入之下一個媒體檔案可為播放清單檔案中之在上一次載入之URI之後的第一媒體檔案URI。

若待播放之第一檔案已被載入且播放清單檔案含有EXT-X-MEDIA-SEQUENCE標籤，則要載入之下一個媒體檔案可為具有大於載入之上一個媒體檔案之序號之最小序號的媒體檔案。若播放清單檔案含有規定密鑰檔案URI之EXT-X-KEY標籤，則用戶端裝置獲取密鑰檔案且使用密鑰檔案內之密鑰解密EXT-X-KEY標籤之後的媒體檔案，直至遇到另一EXT-X-KEY標籤。

在一實施例中，用戶端裝置利用與先前用以下載播放清單檔案之URI相同的URI。因此，若已對播放清單檔案進行變化，則用戶端裝置可使用經更新之播放清單檔案來擷取媒體檔案且基於該等媒體檔案提供輸出。

對播放清單檔案之變化可包括：(例如)至媒體檔案之URI之刪除、至新媒體檔案之URI之添加、至替換媒體檔案之URI之替換。當對播放清單檔案進行變化時，可更新一或多個標籤以反映該(該等)變化。舉例而言，若對媒體檔案之變化導致對播放清單檔案所指示之媒體檔案之播放之持續時間的變化，則可更新持續時間標籤。

圖3B為用於用戶端裝置的用以使用多個位元速率(其為替代串流之一形式)支援內容之串流傳輸之技術之一實施例的流程圖。圖3B之實例係依據HTTP提供；然而，可以類似方式利用其他非串流傳輸協定。

在操作370中，用戶端裝置可請求播放清單檔案。如上文所論述，可利用提供至用戶端裝置之URI來擷取播放清單檔案。在一實施例中，播放清單檔案包括媒體檔案之變體串流之列表以按不同位元速率提供相同內容；換言之，單一播放清單檔案包括用於變體串流中之每一者之媒體檔案的URI。圖3B所示之實例使用此實施例。在另一實施例中，變體串流可由分離地提供至用戶端之各自按不同位元速率提供相同內容之多個相異播放清單檔案表示，且變體播放清單可提供用於相異播放清單檔案中之每一者之URI。此允許用戶端裝置基於用戶端條件來選擇位元速率。

在操作375中，可由用戶端裝置擷取播放清單檔案。在操作380中，可將播放清單檔案儲存於用戶端裝置記憶體中。用戶端裝置可基於當前網路連接速度在操作385中選擇待使用之位元速率。在操作390中，利用包括於對應於選定位元速率之播放清單檔案中之URI向伺服器請求媒體檔案。可將擷取之媒體檔案儲存於用戶端裝置記憶體中。在操作394中，由用戶端裝置利用媒體檔案提供輸出，且用戶端裝置判定是否改變位元速率。

在一實施例中，用戶端裝置最初選擇最低可用位元速率。當播放媒體時，用戶端裝置可監視可用頻寬(例如，當前網路連接位元速率)以判定可用頻寬是否可支援將較高位元速率用於播放。若支援，則用戶端裝置可選擇一較高位元速率且存取較高位元速率媒體播放清單檔案所指示之媒體檔案。亦可支援相反情況。若播放消耗過多頻寬，則用戶端裝置可選擇一較低位元速率且存取較低位元速率媒體播放清單檔案所指示之媒體檔案。

若在操作394中，用戶端裝置(例如)回應於可用頻寬之變化或回應於使用者輸入而改變位元速率，則在操作385中，用戶端裝置可選擇一不同位元速率。在一實施例中，為了選擇一不同位元速率，用戶端裝置可利用包括於對應於新選定位元速率之播放清單檔案中之URI之不同清單。在一實施例中，用戶端裝置可在存取播放清單內之媒體檔案期間改變位元速率。

若在操作394中不改變位元速率，則用戶端裝置判定當前播放清單中是否還存在未播放之尚未擷取且呈現之媒體檔案。若此等媒體檔案存在，則處理返回至操作390，且使用用於播放清單中之彼等檔案之URI擷取一或多個媒體檔案。若不存在此等媒體檔案(亦即，當前播放清單中之所有媒體檔案已播放)，則處理進行至判定播放清單是否包括一結束標籤之操作396。若播放清單包括結束標籤，則節目之播放已結束且處理程序已完成；若播放清單不包括結束標籤，則處理回到操作370，且用戶端裝置請求重新載入節目之播放清單，且處理程序經由圖3B中所示之方法重複。

圖4為伺服器串流代理之一實施例的方塊圖。將理解，伺服器串流代理400之元件可跨越若干伺服器裝置而分散。舉例而言，一第一伺服器裝置可包括分段器430、索引器440及安全性450，但不包括檔案伺服器460，且一第二伺服器裝置可包括檔案伺服器450，但不包括分段器430、索引器440及安全性450。在此實例中，該第一伺服器裝置會準備播放清單及媒體檔案，但不會將該等播放清單及媒體檔案傳輸至用戶端裝置，而一或多個第二伺服器裝置會接收且視情況儲存該等播放清單及媒體檔案且會將該等播放清單及媒體檔案傳輸至用戶端裝置。伺服器串流代理400包括：控制邏輯410，其實施用以引導伺服器串流代理400之操作的邏輯功能控制；及與引導伺服器串流代理400之操作相關聯之硬體。邏輯可能為硬體邏輯電路或軟體常式或韌體。在一實施例中，伺服器串流代理400包括一或多個應用程式412，該一或多個應用程式代表將指令提供至控制邏輯410之碼序列及/或程式。

伺服器串流代理400包括記憶體414，其代表記憶體裝置或對用於儲存資料或指令之記憶體資源之存取。記憶體414可包括在伺服器串流代理400本端之記憶體，以及或替代性地包括駐留有伺服器串流代理400之主機系統之記憶體。伺服器串流代理400亦包括一或多個介面416，該一或多個介面代表關於在伺服器串流代理400外部之實體(電子的或人類的)之至/自伺服器串流代理400之存取介面(一輸入/輸出介面)。

伺服器串流代理400亦可包括伺服器串流引擎420，其代表使伺服器串流代理400能夠如本文中所描述地提供即時或幾乎即時串流傳輸之一或多個功能。圖4之實例提供可能包括於伺服器串流引擎420中之若干組件；然而，亦可能包括不同或額外組件。提供串流傳輸環境的過程中可能涉及之實例組件包括分段器430、索引器440、安全性450及檔案伺服器460。此等組件中之每一者可進一步包括其他組件以提供其他功能。如本文中所使用，無論是以硬體、軟體、韌體抑或其某一組合來實施，組件指代常式、子系統等。

分段器430將待提供之內容劃分成可使用一網路伺服器協定(例如，HTTP)作為檔案傳輸之媒體檔案。舉例而言，分段器430可將內容劃分成預定檔案格式之資料之預定、固定大小區塊。

索引器440可提供將一位址或URI提供至由分段器430建立之媒體檔案的一或多個播放清單檔案。索引器440可(例如)建立具有對應於由分段器430建立之每一檔案之識別符之次序的列表之一或多個檔案。該等識別符可由分段器430或索引器440建立或指派。索引器440亦可將一或多個標籤包括於播放清單檔案中以支援對媒體檔案之存取及/或利用。

安全性450可提供安全特徵(例如，加密)，諸如上文所論述之彼等安全特徵。網路伺服器460可提供與將儲存於主機系統上之檔案提供至遠端用戶端裝置相關之網路伺服器功能性。網路伺服器460可支援(例如)符合HTTP之協定。

圖5為用戶端串流代理之一實施例的方塊圖。將理解，用戶端串流代理之元件可跨越若干用戶端裝置而分散。舉例而言，一第一用戶端裝置可包括組譯器530及安全性550且可將媒體檔案之經解密串流提供至一第二用戶端裝置，該第二用戶端裝置包括輸出產生器540(但不包括組譯器530及安全性550)。在另一實例中，一主要用戶端裝置可擷取播放清單且將該等播放清單提供至一次要用戶端裝置，該次要用戶端裝置擷取播放清單中所規定之媒體檔案且產生一輸出以呈現此等媒體檔案。用戶端串流代理500包括：控制邏輯510，其實施用以引導用戶端串流代理500之操作的邏輯功能控制；及與引導用戶端串流代理500之操作相關聯之硬體。邏輯可能為硬體邏輯電路或軟體常式或韌體。在一實施例中，用戶端串流代理500包括一或多個應用程式512，該一或多個應用程式代表將指令提供至控制邏輯510之碼序列或程式。

用戶端串流代理500包括記憶體514，其代表記憶體裝置或對用於儲存資料及/或指令之記憶體資源之存取。記憶體514可包括在用戶端串流代理500本端之記憶體，以及替代性地包括駐留有用戶端串流代理500之主機系統之記憶體。用戶端串流代理500亦包括一或多個介面516，該一或多個介面代表關於在用戶端串流代理500外部之實體(電子的或人類的)之至/自用戶端串流代理500之存取介面(一輸入/輸出介面)。

用戶端串流代理500亦可包括用戶端串流引擎520，其代表使用戶端串流代理500能夠如本文中所描述地提供即時或幾乎即時串流傳輸之一或多個功能。圖5之實例提供可能包括於用戶端串流引擎520中之若干組件；然而，亦可能包括不同或額外組件。提供串流傳輸環境之過程中可能涉及之實例組件包括組譯器530、輸出產生器540及安全性550。此等組件中之每一者可進一步包括其他組件以提供其他功能。如本文中所使用，無論是以硬體、軟體、韌體抑或其某一組合來實施，組件指代常式、子系統等。

組譯器530可利用自伺服器接收之播放清單檔案而經由網路伺服器協定(例如，HTTP)自伺服器存取媒體檔案。在一實施例中，組譯器530可使播放清單檔案中之URI所指示之媒體檔案得以下載。組譯器530可能回應於包括於播放清單檔案中之標籤。

輸出產生器540可能提供接收之媒體檔案作為主機系統上之音訊或視覺輸出(或音訊及視覺兩者)。輸出產生器540可能(例如)使音訊輸出至一或多個揚聲器且使視訊輸出至一顯示裝置。安全性550可提供諸如上文所論述之彼等安全特徵的安全特徵。

圖6說明具有多個標籤之播放清單檔案之一實施例。圖6之實例播放清單包括特定數目及次序之標籤。僅為描述目的提供此播放清單。一些播放清單檔案可能包括標籤之更多、更少或不同組合，且可按不同於圖6所示之次序來配置該等標籤。

開始標籤610可指示一播放清單檔案之開始。在一實施例中，開始標籤610為#EXTM3U標籤。持續時間標籤620可指示該播放清單之持續時間。亦即，播放清單600所指示的媒體檔案之播放之持續時間。在一實施例中，持續時間標籤620為EXT-X-TARGETDURATION標籤；然而，亦可使用其他標籤。

日期/時間標籤625可提供與由播放清單600指示之媒體檔案所提供的內容之日期及時間相關之資訊。在一實施例中，日期/時間標籤625為EXT-X-PROGRAM-DATE-TIME標籤；然而，亦可使用其他標籤。序列標籤630可指示播放清單之一序列中的播放清單檔案600之順序。在一實施例中，序列標籤630為EXT-X-MEDIA-SEQUENCE標籤；然而，亦可使用其他標籤。

安全性標籤640可提供與應用於播放清單檔案600所指示之媒體檔案的安全性及/或加密相關之資訊。舉例而言，安全性標籤640可規定一解密密鑰以解密該等媒體檔案指示符所規定之檔案。在一實施例中，安全性標籤640為EXT-X-KEY標籤；然而，亦可使用其他標籤。變體清單標籤645可指示變體串流是否由播放清單600以及與該等變體串流相關之資訊(例如，串流數目、位元速率)提供。在一實施例中，變體清單標籤645為EXT-X-STREAM-INF標籤。

媒體檔案指示符650可提供與待播放之媒體檔案相關之資訊。在一實施例中，媒體檔案指示符650包括至待播放之多個媒體檔案之URI。在一實施例中，播放清單600中之URI之次序對應於應用以存取及/或播放媒體檔案之次序。後續播放清單指示符660可提供與將在播放檔案600之後使用的一或多個播放檔案相關之資訊。在一實施例中，後續播放清單指示符660可包括至將在已播放播放清單600之媒體檔案之後使用的一或多個播放清單檔案之URI。

記憶體標籤670可指示在媒體檔案內容之播放之後用戶端裝置是否可儲存媒體檔案及/或可儲存多久。在一實施例中，記憶體標籤670為EXT-X-ALLOW-CACHE標籤。結束標籤680指示播放清單檔案600是否為要呈現之最後一個播放清單檔案。在一實施例中，結束標籤680為EXT-X-ENDLIST標籤。

以下章節(section)含有根據一實施例之若干實例播放清單檔案。

簡單播放清單檔案

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

滑動窗播放清單，使用HTTPS

#EXTM3U

#EXT-X-TARGETDURATION:8

#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,

https://priv.example.com/fileSequence2680.ts

#EXTINF:8,

https://priv.example.com/fileSequence2681.ts

#EXTINF:8,

https://priv.example.com/fileSequence2682.ts

具有加密媒體檔案之播放清單檔案

#EXTM3U

#EXT-X-MEDIA-SEQUENCE:7794

#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI="

https://priv.example.com/key.php?r=52"

#EXTINF:15,

http://media.example.com/fileSequence7794.ts

#EXTINF:15,

http://media.example.com'fileSequence7795.ts

#EXTINF:15,

http://media.example.com/fileSequence7796.ts

#EXT-X-KEY:METHOD=AES-128,URI="

https://priv.example.com/key.php?r=53"

#EXTINF:15,

http://media.example.com/fileSequence7797.ts

變體播放清單檔案

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-

ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"

http://example.com/audio-only.m3u8

圖7為本文中所描述的用於經組譯串流之播放技術之一實施例的流程圖。在一實施例中，接收之媒體檔案之播放可由使用者控制以開始、停止、倒轉等。在操作700中，由用戶端裝置接收播放清單檔案。在操作710中，擷取由播放清單檔案指示之媒體檔案。在操作720中，基於擷取之媒體檔案產生輸出。可如上所述地完成接收及基於媒體檔案產生輸出。

若在操作730中偵測到控制輸入，則在操作740中，用戶端裝置可判定該輸入是否指示停止。若該輸入為停止，則該處理程序終止(conclude)且播放停止。若在操作750中該輸入指示倒轉或快轉請求，則在操作760中，用戶端裝置可基於仍儲存於記憶體中的先前播放之媒體檔案而產生輸出。若此等檔案不再存在於快取記憶體中，則處理回復到用以擷取媒體檔案之操作710且重複該處理程序。在一替代實施例中，播放可支援暫停特徵，其在不終止播放(如同停止輸入之情況一樣)之情況下停住播放。

將參看圖9A至圖9D進一步描述用於自一個串流轉變(transition)至另一串流之方法。一個用戶端裝置可執行此等方法中之每一者，或此等方法中之每一者之操作可跨越多個用戶端裝置而分散，如本文中所描述；舉例而言，在分散式情況下，一個用戶端裝置可擷取變體播放清單及兩個媒體播放清單且將彼等播放清單提供至另一用戶端裝置，該另一用戶端裝置擷取由該兩個媒體播放清單規定之媒體檔案且在由擷取之媒體檔案提供的兩個串流之間切換。亦將理解，在替代實施例中，所展示的操作之次序可經修改，或可存在比此等圖中所示之操作更多或更少的操作。該等方法可使用一變體播放清單來選擇不同串流。在操作901中，可擷取且處理一變體播放清單以判定用於一節目(例如，一體育事件)之可用串流。操作901可由用戶端裝置進行。在操作903中，可自該變體播放清單選擇一第一串流，且一用戶端裝置接著可擷取用於該第一串流之一媒體播放清單。該用戶端裝置可在操作905中處理用於該第一串流之該媒體播放清單且亦可在操作907中量測或以其他方式判定用於該第一串流之網路連接之位元速率。將瞭解，操作之順序可按不同於圖9A所示之一次序的次序來執行；舉例而言，操作907可在操作903期間進行等。在操作911中，該用戶端裝置基於來自操作907的量測之位元速率而自該變體播放清單選擇一替代媒體播放清單；此替代媒體播放清單可在高於該第一串流之一現有位元速率的第二位元速率下。此通常意謂著替代串流將具有高於該第一串流之一解析度。若基於當前條件(例如，在操作907中量測之位元速率)，該替代媒體播放清單為一優於用於該第一串流之當前播放清單之匹配，則可選擇該替代媒體播放清單。在操作913中，擷取且處理用於一替代串流之替代媒體播放清單。此通常意謂著用戶端裝置可正在接收及處理該第一串流及該替代串流兩者，使得該兩者皆可用於呈現；一個串流被呈現而另一串流準備被呈現。該用戶端裝置接著在操作915中選擇一轉變點以在該等串流之版本之間切換，且停止呈現該第一串流且開始呈現該替代串流。結合圖9B至圖9D提供如何完成此切換之實例。在一些實施例中，該用戶端裝置可在進行此切換之前停止接收該第一串流。

圖9B展示用戶端裝置在操作921及923中擷取、儲存且呈現由第一媒體播放清單規定之內容(例如，該第一串流)，且儘管正在呈現由第一播放清單規定之內容，但用戶端裝置在操作925中亦擷取且儲存由第二媒體播放清單規定之內容(例如，該第二串流)。當呈現自第一媒體播放清單獲取之內容時，由第二媒體播放清單規定之內容之擷取及儲存(例如，在一暫時緩衝器中)建立了節目之內容的在時間上的重疊955(圖9D所示)，其允許用戶端裝置在節目之版本之間切換而不實質中斷該節目。以此方式，可在許多情況下達成節目之版本之間的切換而使用者未注意切換已發生(雖然在一些情況下，在切換之後使用者可注意到較高解析度影像)或無節目之呈現之實質中斷。在操作927中，用戶端裝置判定從由第一媒體播放清單規定之內容切換至由第二媒體播放清單規定之內容的一轉變點；轉變點(轉變點959)之一實例展示於圖9D中。接著在切換之後在操作931中呈現由第二媒體播放清單規定之內容。

圖9C及圖9D中所展示之方法代表用於判定轉變點之一實施例；此實施例依靠來自兩個串流951及953之音訊樣本之型樣匹配來判定轉變點。將瞭解，替代實施例可使用視訊樣本之型樣匹配或可使用兩個串流中之時間戳記等來判定轉變點。該方法可包括在操作941中將由第一媒體播放清單規定之內容(例如，串流951)儲存於一緩衝器中；該緩衝器可用於內容之呈現且亦可用於型樣匹配操作。串流951包括音訊樣本951A及視訊樣本951B兩者。視訊樣本可使用依靠i圖框或關鍵圖框(其具有用以顯示單一視訊圖框的所有必要內容)之壓縮技術。串流951中之內容可包括規定一時間(例如，自節目開始起經過的時間)之時間戳記，且此等時間戳記可標記樣本中之每一者之開始(例如，音訊樣本951A中之每一者之開始及視訊樣本951B中之每一者之開始)。在一些情況下，兩個串流之間的時間戳記之比較在判定轉變點上可能沒用，因為該等時間戳記可能不夠精確或因為兩個串流中之樣本之邊界之差別；然而，時間戳記範圍之比較可用以驗證(verify)在兩個串流之間存在時間上的重疊955。在操作943中，用戶端裝置將由第二媒體播放清單規定之內容儲存於一緩衝器中；此內容係關於與自第一媒體播放清單獲取之內容相同的節目且其亦可包括時間戳記。在一實施例中，可將時間戳記(若不存在於串流中)添加至用於一串流之一播放清單；舉例而言，在一實施例中，可將包括一或多個時間戳記之ID3標籤添加至一播放清單(諸如，一變體播放清單或一媒體播放清單)中之一輸入項。該輸入項可(例如)在用於一音訊串流之一第一樣本之一URI中。圖9D展示自第二媒體播放清單獲取之內容953之一實例，且此內容包括音訊樣本953A及視訊樣本953B。在操作945中，用戶端裝置可執行兩個串流951及953中之音訊樣本之型樣匹配以自重疊955選擇轉變點959，在一實施例中，轉變點可為在匹配之音訊區段(例如，區段957)之後的下一個自含視訊圖框(例如，i圖框961)。從i圖框961(及其相關聯音訊樣本)開始，節目之呈現使用自第二媒體播放清單獲取之第二串流。在一實施例中，前述方法可用於自較慢位元速率變化至較快位元速率及自較快位元速率變化至較慢位元速率兩者，但在另一實施例中，該方法僅可用於自較慢位元速率變化至較快位元速率，且另一方法(例如，不嘗試定位一轉變點，而是嘗試儲存且儘可能快地呈現來自較慢位元速率串流之內容)可用於自較快位元變化至較慢位元。

圖10為用於提供使用替代串流將播放清單或媒體內容或其兩者提供至用戶端裝置之多個冗餘位置之技術之一實施例的流程圖。若一播放清單含有替代串流(如上文所論述)，則替代串流不僅可在頻寬或裝置交替時操作，而且可在失敗後降(failure fallback)時操作。舉例而言，若用戶端不能夠重新載入一串流之播放清單檔案(例如，歸因於404錯誤或網路連接錯誤)，則用戶端可嘗試切換至一替代串流。參看圖10，為了實施容錯移轉保護，一第一伺服器裝置或第一內容散佈服務經組態以在操作1002中建立一串流或多個替代頻寬串流，如結合圖2C之描述所論述。在操作1004中，該第一伺服器裝置或第一內容散佈服務根據操作1002中所產生之該(該等)串流產生播放清單檔案。一第二伺服器裝置或第二內容散佈服務可建立一並列串流或串流之一集合(在操作1006中)且亦可建立一播放清單。可將此等並列串流視為備用串流。接下來，在操作1008中將備用串流之清單添加至該(該等)播放清單檔案，使得每一頻寬下之備用串流係在主要串流之後列出。舉例而言，若主要串流來自伺服器ALPHA且備用串流在伺服器BETA上，則一播放清單可能如下：

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000

http://ALPHA.mycompany.com/low/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000

http://BETA.mycompany.com/low/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000

http://ALPHA.mycompany.com/mid/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000

http://BETA.mycompany.com/mid/prog_index.m3u8

請注意，備用串流在播放清單中與主要串流互混，且每一頻寬下之備用串流係在該頻寬之主要串流之後列出。用戶端並不限於單一備用串流集合。在以上實例中，ALPHA及BETA可繼之以(例如)GAMMA。類似地，不必提供串流之完整並列集合。舉例而言，可在備用伺服器上提供單一低頻寬串流。

在操作1010中，用戶端嘗試使用與該第一伺服器裝置或該第一內容散佈服務相關聯之一第一串流自一第一URL下載播放清單檔案。圖11說明一網路，其中根據一實施例用戶端1102與一或多個URL、伺服器裝置或內容散佈服務雙向通信。在操作1012中，可將播放清單檔案自第一URL、伺服器裝置或內容散佈服務傳輸至用戶端1102。若一用戶端不能夠自第一URL、伺服器裝置或內容散佈服務下載播放清單檔案(例如，歸因於重新載入一串流之索引檔案時之錯誤)，則該用戶端嘗試切換至一替代串流。如果在一個串流上發生失敗(例如，索引載入失敗)(例如，操作1010)，則在操作1014中，用戶端選擇網路連接支援之最高頻寬的替代串流。若在相同頻寬下存在多個替代者，則用戶端按播放清單中所列出之次序在該多個替代者中進行選擇。舉例而言，若用戶端1102不能夠自URL 1成功下載，則其可自URL 2或另一URL下載，在此情況下，播放清單檔案係自替代URL傳輸至用戶端。即使在發生嚴重本端故障(諸如，伺服器崩潰或內容散佈器節點關機)的情況下，此特徵亦提供將允許媒體達到用戶端之冗餘串流。

容錯移轉保護提供了提供多個冗餘位置之能力，用戶端可自該多個冗餘位置擷取播放清單及媒體檔案。因此，若用戶端不能自第一位置擷取串流，則其可嘗試自第二、第三等位置存取串流。

在一實施例中，為了指示額外位置(用戶端可自該等額外位置擷取播放清單)，相同的變體播放清單標籤將具備相同頻寬，但具備冗餘位置之新URI。用戶端最初可嘗試存取與所要頻寬相關聯之第一URL。若用戶端不能自第一URL下載播放清單，則該用戶端接著可嘗試存取為該頻寬呈現的下一個URL等，直至該用戶端已用盡所有可能性。

以下實例包括用於2560000頻寬的1個冗餘位置及用於7680000頻寬的2個冗餘位置。

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://examplel.com/mid-redundant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example2.com/hi-redudant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example3.com/hi-redudant3.m3u8

#EXT-X-STREAM-INF:PROGRAM-

ID=1,BANDWIDTH=65000,CODECS=「mp4a.40.5」

http://example.com/audio-only.m3u8

請注意，在此實例中，檔案名稱(例如，mid-redundant2.m3u8)及實際URL(例如，http://example2.com<http://example2.com/>、http://example3.com<http://example3.com/>)均變化。然而，在一實施例中，冗餘位置可為僅檔案名稱之變化或僅網站之變化。

在一實施例中，播放清單可由伺服器裝置壓縮且以壓縮形式發送至用戶端裝置。壓縮之播放清單通常需要比未壓縮之播放清單少的位元來代表播放清單，且因此，壓縮之播放清單在傳輸或接收時使用網路(諸如，無線蜂巢式電話網路)之較少可用頻寬。在一實施例中，播放清單可由網路伺服器根據由網路伺服器使用之內建壓縮技術或設施(其符合或相容於諸如HTTP 1.1標準協定之傳送協定)壓縮；此壓縮技術或設施之一實例為HTTP 1.1之deflate或gzip壓縮設施。在其他實施例中，可使用為基於標準之傳送協定之部分的其他基於標準之壓縮設施。在一實施例中，壓縮之播放清單之使用可為伺服器裝置及用戶端裝置之可選特徵。在一實施例中，播放清單可為文字內容(例如，文字檔案)且可由基於標準之網路伺服器利用deflate或gzip有效地壓縮且接著由用戶端裝置自動解壓縮。Gzip壓縮設施之版本之描述可在www.ietf.org/rfc/rfc1952.txt找到；deflate壓縮設施之版本可在www.ietf.org/rfc/rfc1951.txt找到。許多網路伺服器及用戶端裝置上之許多網頁瀏覽器可自動支援deflate設施或gzip設施。

在一實施例中，一用戶端裝置可週期性地請求更新之播放清單；舉例而言，該用戶端裝置可每隔幾秒鐘(例如，每隔10秒、20秒或30秒或某一其他時間段)向一伺服器請求一更新之播放清單。漸增的播放清單(諸如，用於進行中的實況棒球比賽之播放清單，其允許用戶端在實況比賽期間在任何時間自實況比賽之開頭開始觀看)可變得足夠大以使得壓縮之使用可限制對網路之頻寬之消耗，因為漸增的播放清單係重複地經由網路發送。

在一實施例中，一用戶端裝置可在其請求一播放清單(諸如，一更新之播放清單)時視情況規定其可支援哪些壓縮技術(諸如，deflate或gzip)；對此等技術之支援意謂著該用戶端裝置可解壓縮或解碼經壓縮或編碼之內容。該用戶端裝置對播放清單之請求(具有對壓縮技術之可選規定)由一網路伺服器接收，在一實施例中，不需要該網路伺服器支援用於播放清單之壓縮技術，而是可發送未壓縮之播放請求。網路伺服器可藉由將一未壓縮播放清單或使用用戶端裝置對播放清單之請求中所規定的壓縮技術中之一者壓縮之一播放清單發送至用戶端裝置來回應於用戶端裝置之請求。用戶端裝置接收播放清單且如本文中所描述地使用該播放清單；若播放清單經壓縮，則使用用戶端裝置上之解碼器(諸如，用戶端裝置上之網頁瀏覽器中之解碼器)來解碼該播放清單。

圖12A及圖12B展示當將添加額外媒體檔案時(例如，當正在傳輸中的當前播放清單不含有EXT-X-ENDLIST標籤時)用於後續播放清單之傳輸的伺服器時序模型之一實施例。若當前播放清單不含有呈現之最終媒體檔案，則資料處理系統或伺服器可產生播放清單之新版本，其含有至少一新媒體檔案URI。圖12A及圖12B展示用於確保具有新媒體檔案URI之新播放清單將可以與播放清單之先前版本連續之方式用於至用戶端裝置之傳輸的伺服器時序模型之一實施例。此模型可(例如)在允許播放清單中所規定之媒體檔案在持續時間上為短(例如，僅幾秒鐘長)時使用。在一實施例中，藉由設定每一媒體檔案之最大媒體檔案持續時間及藉由基於最大媒體檔案持續時間設定播放清單持續時間之最小量，伺服器或其他資料處理系統可確保內容至用戶端裝置之連續散佈或傳輸，即使每一媒體檔案在持續時間上僅為幾秒鐘亦然。

現參看圖12A，若如在操作1200中判定，結束清單標籤不存在於下一個播放清單檔案中，則操作1201可用以建立一目標持續時間以作為播放清單中之每一媒體檔案之最大媒體檔案持續時間。操作1201可由一資料處理系統執行，該資料處理系統正在將資料之串流劃分成多個媒體檔案且將彼等多個媒體檔案儲存為個別檔案。劃分串流之處理程序可利用目標持續時間(例如，當前播放清單檔案之目標持續時間)來確保播放清單檔案中所規定之每一媒體檔案小於目標持續時間(或小於目標持續時間加上或減去小的時間段)。產生播放清單之資料處理系統亦可確保播放清單檔案之持續時間至少可為目標持續時間之倍數，如操作1203中所展示。在一實施例中，倍數可為用作播放清單持續時間之最小值的三個目標持續時間(或目標持續時間之某一其他倍數)，其中播放清單之持續時間係由播放清單內所規定之媒體檔案之累積持續時間定義。產生播放清單之系統(例如，伺服器)可藉由確保每一播放清單至少規定足夠數目個媒體檔案以滿足最小持續時間來遵守播放清單之最小持續時間；舉例而言，若最小持續時間為3個目標持續時間，則每一播放清單應包括至少3個目標持續時間。

操作1205亦可用作用以確保可自資料處理系統(諸如，傳輸媒體檔案之伺服器)得到一致且連續之串流之另一機制。此另一機制可減少用戶端裝置為了判定是否存在播放清單之變化而進行的輪詢或提取(pulling)之量。在操作1205中，可設置伺服器，以使得存在供伺服器傳輸下一個播放清單檔案之最早時間及最晚時間。最早時間及最晚時間可用作一時間窗，該時間窗基於或關於可得到先前播放清單檔案(其緊接在新播放清單檔案之前)的時間。最早時間可(例如)基於緊接在前的播放清單第一次可用於自伺服器傳輸(但未必已傳輸)的時間。最晚時間亦可(例如)基於緊接在前的播放清單第一次可用於自伺服器傳輸(但未必已傳輸)的時間。舉例而言，在一實施例中，可能將最早時間規定為不早於自先前播放清單檔案第一次可用於傳輸時起目標持續時間(例如，在操作1201中設定之目標持續時間)之第一預定百分比(例如，一半)之時間，且可將最晚時間設定為不遲於自緊接在前的播放清單檔案第一次可用於自伺服器傳輸時起目標持續時間之第二預定百分比(例如，1.5倍)。在一實施例中，播放清單檔案第一次可用於傳輸的時間可為播放清單檔案之建立時間(該時間由伺服器上的檔案系統記錄)。在圖12B中展示此實例，其包括時刻表1211。目標持續時間1213為播放清單持續時間1215之一部分，該播放清單持續時間代表在時間1209第一次可由一或多個伺服器使用之緊接在前的播放清單之持續時間，時間1209為先前播放清單檔案第一次可用於傳輸的時間。該播放清單中所規定之媒體檔案可在接近時間1209時開始其傳輸。根據圖12B所示之伺服器時序模型，伺服器在最早時間1217(其為在時間1209之後的目標持續時間之一半)之前不應傳輸下一個播放清單檔案，且伺服器在遲於時間1219(其在圖12B所示之實例中已規定為在時間1209之後的目標持續時間之1.5倍)之任何時間不應使下一個播放清單檔案可用。此伺服器時序模型可用以確保播放清單檔案可供用戶端裝置使用以為用戶端裝置提供足以擷取播放清單中所規定之媒體檔案且接著一致且連續地呈現彼等媒體檔案而在播放期間無內容之呈現中之暫停的時間。在一實施例中，當內容為一實況事件之傳輸，且來自該實況事件之資料之串流正被劃分成多個媒體檔案且接著以相對於該實況事件幾乎即時之方式將彼等多個媒體檔案傳輸至用戶端裝置(該等用戶端裝置在從實況事件(諸如，棒球比賽等)之資料之串流中劃分出多個媒體檔案之後不久接收該多個媒體檔案)時，可使用此等伺服器時序模型。

圖13展示尤其當用戶端裝置以幾乎即時之方式呈現實況事件時且當用戶端裝置正在呈現幾乎實況事件之當前結尾(在時間上最近的)之內容時可用以避免用戶端裝置處之播放中之暫停的方法之實施例。舉例而言，若實況事件為棒球比賽，則用戶端裝置之使用者可能更偏好僅觀看比賽中之最近事件而不是自比賽之最開頭開始觀看比賽。若使用者希望僅觀看在進行中之比賽之最近事件，則使用者可設法將播放設定為從距可用媒體串流之結束的最近10或15秒開始之點開始。網路中之問題或延遲可突然使資料變得不可得且可阻止新資料變得可用，且因此，當使用者將用戶端裝置設定為以此模式操作時，用戶端裝置可在非常短的時間段中用完呈現之內容。可使用圖13之方法，以便藉由在用戶端裝置處強制執行播放要求從至少在當前播放清單檔案結束之前一時間段(例如，30秒)之開始點開始的規則來減少此發生的機會。舉例而言，若播放清單檔案具有規定於其中之5個媒體檔案(每一媒體檔案為10秒長)，則此規則之一實施可為強制起始點為不遲於播放清單中所規定之五個媒體檔案之序列中之第三個媒體檔案。現參看圖13，操作1301可用以判定結束清單標籤或標記是否存在於播放清單中。若此結束清單標籤存在，則圖13之方法可由於無新內容將添加至播放清單而停止，因此在一實施例中，在操作1303中不必強制執行規則。另一方面，若無結束清單標籤存在於播放清單中，則可在用戶端裝置處強制執行規則，其要求起始點為至少在播放清單檔案之結束之前一時間段。可基於媒體檔案之目標持續時間來規定該時間段。舉例而言，在一實施例中，可要求用戶端裝置從距播放清單檔案之結束達三個以上目標持續時間之媒體檔案開始。

本發明之另一態樣係關於當在來自兩個播放清單之串流(例如，兩個變體串流)之間切換或在媒體檔案之兩個集合之間其他切換時可使用之方法。已結合圖9A、圖9B、圖9C及圖9D提供了用於在來自兩個不同播放清單的串流之間切換之方法之實例。在該方法中，兩個串流之間的時間上之重疊可用以確保一致且連續之播放，以使得串流之間的切換或轉變可為順暢的。如圖9D所示，重疊955代表一時間段，在該時間段中，來自兩個串流之媒體內容被儲存於用戶端裝置處且能夠在用戶端裝置處播放，藉此允許該兩個串流之間的順暢切換。在一實施例中，該重疊可為從不改變且在用戶端裝置內設定之最小數目。儘管此實施例可良好地工作，但可存在重疊可不必要地過長之時間。換言之，即使裝置準備好進行轉變，重疊亦可阻止切換或轉變發生。舉例而言，當自較低解析度切換至較高解析度時，不必要之長重疊可迫使使用者在較高解析度呈現已可用且準備呈現的時段中觀看較低解析度呈現。較高速度連接可(例如)提供快速地產生可比一較低速度連接或連接類型所需之重疊短的重疊之能力。在根據圖14A之實施例中，用戶端裝置可根據連接速度或連接類型進行調適且基於連接速度或連接類型來修改所需之最小重疊。舉例而言，若連接速度或類型為快，則可相對於較低連接速度或連接類型所需之最小重疊減少最小重疊。當條件變化(例如，用戶端裝置失去3G連接且必須依靠2G或較慢連接)時，就可變化最小重疊。因此，用戶端裝置可基於連接速度或類型來調適最小重疊。現參看圖14A，在操作1401中，用戶端裝置可判定連接之速度或類型。返回參看圖9D，可見，來自一第二播放清單之資料之一第二串流為一新資料源，在用戶端裝置亦接收來自一第一播放清單之串流之同時正在接收該第二串流。此時，用戶端裝置可判定連接之速度或連接之類型，以便在操作1403中基於當前連接速度或連接類型來判定所需之重疊之最小量。當條件變化時，可基於變化之條件(諸如，至蜂巢式電話塔、WiFi基地台等之無線連接)來調適此最小重疊。此在用戶端裝置正在移動通過無線蜂巢式電話網路或其他資料網路時可能尤其有利。在確定當前條件之最小重疊存在之後，用戶端裝置接著可在操作1405中自來自第一播放清單或舊源之串流切換或轉變至新源，其可為來自第二播放清單之串流。已關於與圖9A至圖9D相關聯之描述提供此轉變之實例。

圖14B、圖14C及圖14D展示兩個串流之間的重疊(諸如，結合圖9A至圖9D描述且展示之重疊，或結合圖14A描述之重疊)如何之另一態樣。圖14B、圖14C及圖14D所示之方法可用適應性導出之重疊(其結合圖14A描述)實施，或此方法可與不變化之固定重疊一起使用。圖14B至圖14D中所描繪之方法可從自「舊串流」1410(例如，其可為以在位元速率上慢於新串流1414之未來下載之一第二速度之一第一速度下載的較低解析度視訊)下載媒體檔案開始。舊串流1410已被下載(如雜湊標記1411所指示)且其目前正在(例如，播放頭位置所在之)播放點1412處在用戶端裝置上向使用者呈現；舊串流1410中之超出當前播放點1412的已下載之內容為在連接出故障的情況下可用之緩衝內容。用戶端裝置可接著讀取新串流1414之播放清單檔案且甚至在下載內容「區塊」(諸如，區塊1416及1415)之內容之前根據該播放清單檔案判定彼等區塊；舉例而言，新串流之播放清單檔案可至少近似地指示內容區塊1416及1415在時間上相對於舊串流1410之位置。此判定可允許用戶端裝置保守地決定藉由請求及擷取區塊1415之一或多個媒體檔案來下載新串流1414之第一區塊1415，且圖14C展示該下載之結果(區塊1415A具有雜湊標記以展示此區塊已被下載)。播放位置已在時間上前進至新位置(仍在舊串流1410之最左邊區塊內)。在此情況下，區塊1415之下載足夠快以使得播放位置未離開舊串流1410之最左邊區塊。在下載耗時較長的情況下保守地選擇區塊1415，使得播放可至少圍繞區塊1415A切換。在圖14C中所描繪之點處，用戶端裝置可檢查由區塊1415A提供之重疊與當前播放點(由圖14C中之1412展示)之間剩餘多少時間。若在給定連接速度之情況下存在足夠時間，則用戶端裝置可下載為先於當前重疊之區塊的區塊或區段1416，然後用戶端裝置可重複該檢查以判定由剛下載之區塊1416A提供之重疊(在圖14D中展示，在區塊已下載之後，如雜湊標記所指示)與當前播放點(由圖14D中之1412展示)之間剩餘多少時間。若如在圖14D所示之實例之情況下，1416A之下載快速發生，則用戶端裝置可在時間上向回移動重疊點，從而減少在串流之間切換耗費的時間(且因此允許區塊1416A內之切換)；另一方面，若下載1416A中存在延遲以使得切換不能在區塊1416A內發生，則用戶端裝置可使用區塊1415A作為可用以使切換在區塊1415A內發生之重疊。

在一實施例中，當在兩個串流之間切換時(諸如，在圖9A至圖9D及圖14A至圖14D中所示之實例中)，用戶端裝置可繼續儲存(而非捨棄)舊串流(例如，串流1410)，直至至新串流(例如，串流1414)之切換已完成或切換已於新串流上穩定操作達一最小時間段為止。

本發明之另一態樣可利用定義影像之解析度之屬性。此屬性可允許用戶端裝置基於該屬性決定：用戶端裝置不應切換解析度或以其他方式切換串流。舉例而言，用戶端裝置可決定：用戶端裝置已播放其可顯示之最大解析度，且沒有必要下載裝置可經由一資料網路得到之較高解析度。

圖15展示一實施例中的用於利用此屬性之方法之實例。在操作1501中，可由一用戶端裝置接收一播放清單檔案，且在操作1503中，該用戶端裝置可根據該播放清單檔案判定一屬性存在於該播放清單檔案內，該屬性定義該用戶端裝置可用之影像之解析度。在操作1505中，基於該屬性，用戶端裝置可判定是擷取另一播放清單檔案抑或擷取與該屬性相關聯之一媒體檔案。藉由提供解析度屬性，用戶端裝置可智慧地決定如何處理播放清單中之資料。此外，用戶端裝置可關於資料之擷取做出可防止不必要的下載之決策，且進而可最小化網路上的資料訊務之量。

本發明之一實施例可允許一系統基於日期及時間搜尋內容。舉例而言，使用者可能想要看到在2009年4月9日大約下午5點擊出之全壘打或可能想要看到在一日期及近似時間之另一事件。本發明之實施例可藉由經由使用與對應媒體檔案之開頭相關聯之EXT-X-PROGRAM-DATE-TIME標籤進行時間戳記來提供此能力；可藉由使該標籤在播放清單檔案中出現在該媒體檔案之前而使該標籤與其對應媒體檔案相關聯。諸如伺服器之系統可儲存可由用戶端裝置擷取(例如，下載)且用以搜尋日期及時間以找到所要媒體檔案之一或多個播放清單；或者，用戶端裝置可請求(例如，經由一日期及時間搜尋請求)伺服器在該一或多個播放清單中搜尋以識別匹配該日期及時間搜尋請求之一或多個媒體檔案，且伺服器可藉由識別該一或多個媒體檔案來回應。在一實施例中，標籤指示媒體檔案之實質上精確之開頭，且媒體檔案內之時間戳記可用以找到具有時間上的較精細粒度之播放點。舉例而言，一標籤之時間戳記可指示媒體檔案在2009年4月9日下午5:03開始，且一媒體檔案內之時間戳記(或時間之其他指示符)可規定在下午5:03之後以分鐘或秒等遞增之時間，以允許裝置在(例如)下午5:06或下午5:05:30處開始播放(經由選擇播放起始點)。

圖16A展示描繪根據一實施例的用於使用有時間戳記之標籤建立播放清單檔案之方法的流程圖。該方法可由實施有處理邏輯(包括軟體、硬體、韌體或上述任何者之組合)之伺服器執行。在一些實例中，伺服器由一媒體提供者(諸如，MLB)提供。

在方塊1610，處理邏輯建立有時間戳記之標籤且使該等有時間戳記之標籤中之每一者與一個媒體檔案相關聯。有時間戳記之標籤中之時間戳記指示相關聯媒體檔案之開始日期及時間。上文已論述了有時間戳記之標籤之一些實施例之細節。

在方塊1620，處理邏輯用一或多個有時間戳記之標籤(例如，EXT-X-PROGRAM-DATE-TIME標籤)建立一播放清單檔案，該一或多個有時間戳記之標籤中之每一者與一特定媒體檔案相關聯。請注意，媒體檔案本身亦具有內部時間戳記。在方塊1630，處理邏輯可散佈播放清單，使得播放清單檔案可用於使用有時間戳記之標籤中之日期及時間的按日期及時間搜尋。在一些實施例中，播放清單係儲存於一存放庫中，用戶端裝置可自該存放庫下載播放清單。

圖16B展示描繪根據一實施例的用於使用利用有時間戳記之標籤建立之播放清單檔案之方法的流程圖。該方法可由實施有處理邏輯(包括軟體、硬體、韌體或上述任何者之組合)之用戶端裝置執行。用戶端裝置可由與播放清單檔案相關聯之媒體之個別消費者、用戶或觀看者使用以存取及播放媒體。

在方塊1650，處理邏輯接收對一節目之在一特定日期及時間開始之一區段的一使用者請求。舉例而言，使用者可能請求在2010年4月6日下午8:15開始之棒球比賽的第四局，而不是完整的棒球比賽。回應於使用者請求，在區塊1652，處理邏輯自媒體伺服器下載與該節目相關聯之一或多個播放清單檔案。在區塊1654，處理邏輯使用播放清單檔案內的時間戳記標籤中之日期及時間在下載之播放清單檔案中搜尋最接近所請求之區段之日期及時間的日期及時間戳記。接著在區塊1656，處理邏輯自所請求之區段之日期及時間減去其日期及時間。此減法產生一持續時間。在區塊1657，處理邏輯接著向前推進播放清單檔案中之後續媒體檔案持續時間，直至處理邏輯定位了在有日期戳記之媒體檔案之後有大約那麼多持續時間之一目標媒體檔案。在區塊1658，處理邏輯接著下載此目標媒體檔案，因為該目標媒體檔案為關於哪個檔案含有所請求之區段之最佳推測。

在一些實施例中，有日期戳記之媒體檔案與目標媒體檔案之間的所有媒體檔案為單一編碼之部分，亦即，其間沒有不連續性標籤。若該等媒體檔案為連續的，則處理邏輯可自目標檔案中之媒體檔案時間戳記減去有日期戳記之檔案中之媒體檔案時間戳記以獲得精確持續時間，此允許精確地定位所請求之日期及時間。

透過使用播放清單檔案中之有時間戳記之標籤中之日期及時間，處理邏輯不必下載整個節目之所有媒體檔案以便在該等媒體檔案中搜尋以找到所請求之區段。因為當使用者未請求整個節目時，用戶端裝置不必下載整個節目之所有媒體檔案，所以可達成頻寬之顯著節約。此外，許多典型媒體檔案僅含有經常從零開始之任意時間戳記。因此，上文所論述之有時間戳記之標籤之日期及時間可使媒體檔案中之任意時間戳記與真實日期及/或時間相關聯。透過使用有時間戳記之標籤，用戶端裝置可比對每一媒體檔案進行掃描有效率地定位含有特定日期及/或時間之播放清單元件。

本發明之一實施例允許將定時後設資料以ID3格式插入至媒體串流中。媒體串流可能包括以預定格式編碼之視訊及/或音訊資料。舉例而言，媒體串流可能包括以由運動圖象專家組(Moving Pictures Expert Group，MPEG)開發之MPEG-2(其為國際標準ISO/IEC 13818)編碼的視訊及音訊資料。一般言之，後設資料包括關於媒體串流中之資料的資訊，及參考與特定時間(例如，進球得分之時間)相關聯之後設資料的定時後設資料。請注意，定時後設資料可隨時間變化。定時後設資料可以用於儲存後設資料之預定格式(諸如，ID3格式)插入至媒體串流中。在一些實施例中，可將視訊資料劃分成圖框之一序列。亦可將視訊資料的定時後設資料劃分成與圖框之序列相關聯之容器。每一容器可儲存一對應圖框的定時後設資料及與該對應圖框相關聯之時間兩者。或者，每一容器可儲存一對應圖框之定時後設資料及該對應圖框之圖框號兩者。在一些實施例中，一圖框之定時後設資料可包括該圖框之預定資訊之一集合。舉例而言，定時後設資料可包括記錄視訊資料之對應圖框所在的位置之位置資訊(例如，全球定位系統(GPS)資料)。

圖16C、圖16D及圖16E展示可使用定時後設資料或其他機制控制已在接收器(諸如，已藉由發送規定串流傳輸內容之URL來請求串流傳輸內容之用戶端裝置)處緩衝之串流傳輸內容之播放的一實施例之一實例。如本文中所描述，此等URL可含於一或多個播放清單檔案中。

圖16C展示可呈現於顯示裝置1660上(或該顯示裝置之一部分上)之使用者介面(UI)。在一實施例中，內容1661(諸如，實況體育事件或表演或基於時間的其他動畫內容)與兩個時刻表1662及1664呈現在一起。時刻表1664展示內容在時間上之整個長度(其可為固定量之時間，諸如90分鐘之表演，或不確定量之時間，諸如棒球比賽)。可呈現指示符1667以展示整個內容內之當前播放位置；在時刻表1666上的指示符1667相對於時刻表之長度的位置指示當前播放位置。舉例而言，若指示符1667處於左端點與右端點之間的一半處，則當前播放位置在現有內容中的約一半處。時刻表1666亦可與其他UI控制項(諸如，返回控制項1668、暫停控制項1669及向前快轉控制項1670)相關聯。返回控制項1668在被選定時可使當前播放位置在時間上向回移動(例如，向回移動30秒)。暫停控制項1669在被選定時可停止接收器處之播放，且向前快轉控制項1670在被選定時可使當前播放位置移動至最新近的當前(例如，實況或幾乎實況)內容。在一實施例中，時刻表1666及1662皆可同時存在於半透澈或半透明面板中，該面板上覆於在面板下呈現之串流傳輸內容上。

在一實施例中，時刻表1662表示接收器處之經緩衝內容之量在時間上之長度。如本文中所描述，接收器可緩衝串流內容，以確保：即使資料通信速率變得較低或串流傳輸內容之資料通信被中斷，亦始終有某串流傳輸內容可播放。在圖16C所示之實例中，已在接收器處接收且緩衝了總共4分鐘又30秒之串流傳輸內容；此總時間係自標記1663(3分鐘，51秒)及標記1665(39秒)導出，且此等標記亦展示當前播放位置為距最新近接收之內容(其可為實況或幾乎即時實況，如本文中所描述)39秒。在一實施例中，可藉由(例如)選擇指示符1664且沿著時刻表1662移動其而變化在經緩衝內容內之當前播放位置。此變化可(例如)藉由用手指觸摸指示符1662或藉由經由滑鼠或經由其他已知使用者介面技術控制游標來進行。圖16D展示移動指示符1662(至經緩衝內容中之中間點)之結果之一實例，使得內容之呈現目前設定於在最近接收且緩衝之內容(其由時刻表之右端點表示)之前2分鐘又15秒的播放點處。

圖16E展示用於使用圖16C及圖16D所示之使用者介面之一實施例之方法之一實例。在操作1672中，諸如接收器之資料處理系統可顯示或以其他方式呈現一表示串流傳輸節目之當前長度之時刻表(諸如，時刻表1666)且亦可顯示UI控制項(諸如，控制項1668、1669及1670)。另外，在操作1673中，此系統亦可同時顯示另一時刻表(諸如，時刻表1662)，其指示在經緩衝內容內之當前播放位置。在一實施例中，時刻表可在一可表示當前經緩衝內容在時間上之總長度之時刻表上展示經緩衝內容中之當前播放位置的指示符。在操作1674中，接收器可回應於使用者在一或多個UI控制項上之輸入，以便改變串流傳輸內容之呈現。舉例而言，若使用者沿著時刻表1662移動指示符1664，則使用者可改變在經緩衝內容內之當前播放位置；圖16C及圖16D中所示之實例展示當前播放位置可自在最新近接收之內容(其可為幾乎即時之「實況」串流)之前若干秒變至在最新近內容之前若干分鐘。在圖16C及圖16D之實例中，使用者實際上已將播放倒轉至經緩衝內容內之一較早點且可重放經緩衝內容，且可在與內容之整個當前時刻表(諸如，時刻表1666)分離之時刻表上控制此倒轉。

在本發明之一實施例中，媒體檔案之處理(例如，播放清單之擷取及播放清單中所規定之媒體檔案之擷取，及媒體檔案中之內容之解碼)可獨立於呈現媒體且控制媒體使之不被呈現的使用者介面進行。舉例而言，使用者應用程式(諸如，用於觀看實況事件之應用程式)(例如，用於觀看棒球比賽之美國職棒大聯盟(MLB)應用程式)或其他串流可提供用於呈現及控制(例如，接收媒體檔案之選擇)呈現之使用者介面，同時另一軟體處理程序(例如，伺服媒體之軟體處理程序，諸如用於伺服媒體之精靈協助程式，其可被稱為「媒體伺服」)可擷取播放清單且擷取並解碼媒體檔案。在一些情況下，可加密媒體檔案，且加密可由使用者應用程式(例如，MLB應用程式)控制；舉例而言，使用者應用程式可將用戶端憑證(例如，用以提供鑑認及信任鏈及可撤銷性之X.509憑證)安裝至其密鑰鏈(keychain)(持續地或僅在記憶體中)中，該用戶端憑證可用以在進行HTTP安全保護通訊槽層(SSL)連接以下載可用以解密媒體內容的密鑰時回答伺服器挑戰。在其他情況下，播放清單可含有一或多個密鑰之URL，該等URL使用由使用者應用程式或與使用者應用程式互動之伺服器使用之自訂URL配置(URL scheme)；在此情況下，使用者應用程式可註冊可經調用以獲取密鑰(諸如，新密鑰)的用於此等自訂URL配置之URL協定處理常式，且此可允許使用者應用程式在頻帶外輸送密鑰(例如，隱藏在其應用程式二進位中)，或使用專用協定自伺服器獲取密鑰。

圖17展示允許媒體伺服精靈協助程式與使用者應用程式互動之軟體架構之一實施例。該架構包括媒體伺服精靈協助程式(「媒體伺服」)1710及例示性使用者應用程式-事件媒體提供者(EMP)應用程式1720，該兩者皆可在執行於用戶端裝置(諸如，智慧電話、個人數位助理、桌上型電腦、膝上型電腦、平板裝置等)上之處理程序中執行。可使用圖8所示之電子系統800來實施用戶端裝置之一實施例。在一些實施例中，媒體伺服1710及EMP應用程式1720共用關於記憶體控制、記憶體空間、記憶體分配、檔案系統控制及網路控制的相同特殊權限。因而，媒體伺服1710可存取EMP應用程式1720可存取之資料。同樣地，禁止媒體伺服1710存取EMP應用程式1720不能存取之資料。

在一些實施例中，EMP應用程式1720進一步包括核心媒體堆疊1721，其為用於存取網路連接堆疊1723之自訂軟體堆疊，網路連接堆疊1723又存取URL協定處理常式-EMP處理常式1725。EMP應用程式1720可註冊用於自訂URL配置之EMP處理常式1725，可調用該EMP處理常式1725以獲取一或多個密鑰。因此，EMP應用程式1720可在頻帶外輸送密鑰(例如，隱藏在應用程式二進位中)。

一般而言，媒體伺服1710與EMP應用程式1720可彼此互動以下載並播放來自內容提供者(在當前實例中，其為EMP)之實況串流傳輸內容的媒體檔案。播放可在用戶端裝置上在媒體伺服1710中進行。在一些實施例中，媒體伺服1710可下載密鑰以用於解密媒體檔案，且若此下載失敗，則媒體伺服1710可要求EMP應用程式1720自內容提供者伺服器(在當前實例中，其為EMP伺服器1730)下載密鑰。在用戶端裝置上執行之EMP應用程式1720可簽約以獲得一或多個密鑰。通常，EMP應用程式1720可能在下載媒體檔案之前已註冊並獲取密鑰。在下文論述媒體伺服1710與EMP應用程式1720之間的互動之一些實施例之細節以進一步說明該概念。

參看圖17，EMP應用程式1720將具有至少一URL及一密鑰之播放清單發送至媒體伺服1710(1)。使用該密鑰，媒體伺服1710嘗試在該URL處存取由EMP提供之一媒體源且自該媒體源下載該播放清單中所規定之媒體檔案。該等媒體檔案可能經編碼或加密以防止對該等媒體檔案之內容的未經授權觀看。若媒體伺服1710未能下載該等媒體檔案或其未能解碼或解密下載之媒體檔案(2)，則媒體伺服1710將失敗報告至EMP應用程式1720(3)。

回應於來自媒體伺服1710之失敗報告，EMP應用程式1720使用其核心媒體堆疊1721來存取網路連接堆疊1723以便請求一新密鑰(4)，該網路連接堆疊又為了該新密碼而存取EMP處理常式1725(5)。EMP處理常式1725經由網路(例如，網際網路)連接至EMP伺服器1730以向EMP伺服器1730請求該新密鑰(6)。回應於該請求，EMP伺服器1730將該新密鑰發送至EMP處理常式(7)。接著，EMP處理常式1725將該新密鑰傳遞至核心媒體堆疊1721(8)，該核心媒體堆疊接著將該新密鑰傳遞至媒體伺服1710(9)。

當媒體伺服1710自核心媒體堆疊1721接收到該新密鑰時，媒體伺服1710可試著使用該新密鑰再次下載檔案媒體且接著使用該新密鑰解碼下載之媒體檔案(10)。或者，若媒體檔案先前已被成功下載，但媒體伺服1710未能解密媒體檔案，則媒體伺服1710可試著使用該新密鑰解密先前被下載之媒體檔案。若媒體伺服1710使用該新密鑰成功下載且解碼媒體檔案，則EMP應用程式1720可在用戶端裝置上呈現解碼之媒體檔案。

在本文中所描述之一實施例中，一播放清單檔案可指示由該播放清單檔案提供之內容之一類型。內容之類型可定義播放清單檔案之類型，且播放清單檔案之類型可在播放清單檔案中之標籤之參數中加以規定。在一實施例中，標籤可採取#EXT-X-PLAYLIST-TYPE:[VOD|LIVE|EVENT]之形式。此標籤可規定VOD或LIVE或EVENT中之一者或其中之僅一者。「VOD」可指示播放清單檔案係關於隨選視訊(VOD)內容，且「LIVE」可指示播放清單檔案係關於實況內容，其可具有不確定之結束時間及不確定之開始時間，且可與在用戶端裝置處接收到媒體檔案以供呈現(諸如，經由顯示視訊來播放)幾乎同時發生。「EVENT」指示播放清單檔案係關於事件，其可具有不確定之結束時間，但具有確定之固定開始時間(諸如，籃球比賽或棒球比賽)且可與在用戶端裝置處接收到媒體檔案以供呈現幾乎同時發生。具有此類型標籤之播放清單檔案可與本文中所描述之其他播放清單檔案相似且包括通用資源指示符(URI)，該等URI指示可由用戶端裝置在接收到播放清單檔案之後按由播放清單檔案指示之次序擷取的複數個媒體檔案。播放清單檔案亦可包括具有與播放清單檔案中之該複數個媒體檔案之播放相關之參數(諸如，VOD或LIVE)的複數個標籤(諸如，#EXT-X-PLAYLIST-TYPE標籤)。具有規定播放清單之類型的此類型標籤之播放清單檔案可與本發明中所描述之其他播放清單檔案相似。

類型標籤(諸如，#EXT-X-PLAYLIST-TYPE)在播放清單檔案中之存在有效地宣佈播放清單將堅持與內容之類型一致的操作方式，且此可允許用戶端裝置以對播放清單或內容之類型而言可為最佳化之方式處理播放清單。用戶端裝置可檢查播放清單類型指示符(諸如，VOD或LIVE或EVENT)之存在，且可根據播放清單類型指示符以最佳方式處理播放清單。

舉例而言，當播放清單類型指示符為「VOD」時，播放清單可使用戶端裝置經組態為不更新播放清單檔案，因為可假定隨選視訊呈現之播放清單將不變化且因此不必請求播放清單檔案之更新。因此，在此情形下，用戶端裝置將經組態為不請求播放清單檔案之更新。此外，當播放清單檔案為由播放清單類型指示符規定之「VOD」類型時，播放清單可使用戶端裝置經組態為在接收第二變體播放清單(諸如，同一隨選視訊內容之較佳品質呈現之播放清單)且切換至使用第二變體播放清單之後儲存第一變體播放清單(諸如，隨選視訊之較低品質呈現之播放清單)，因為第一變體播放清單在切換之後將仍有效且可在第二變體播放清單之使用變得有問題之情況下(諸如，當網路頻寬變得較低且不再可支援第二變體播放清單之使用時)使用。此外，當播放清單類型指示符為「VOD」時，用戶端裝置可經組態以檢查播放清單檔案以尋找ENDLIST標籤或指示播放清單完整之其他標籤，且若此標籤不在播放清單檔案中，則用戶端裝置可將該播放清單標記為有錯誤。

當播放清單類型指示符為「LIVE」時，用戶端裝置可經組態以重複地請求經更新之播放清單檔案。當播放清單類型指示符為「EVENT」時，用戶端裝置可經組態以(a)僅載入經更新之播放清單之一較新近部分(藉此避免對經更新之播放清單之較舊部分之接收)或(b)僅剖析經更新之播放清單之一較新近部分(藉此避免對經更新之播放清單之較舊部分之重新剖析)。

圖20展示根據一實施例之可藉以處理有能力包括類型指示符之播放清單的方法之一實例。在操作2001中，可由一用戶端裝置接收一播放清單，在操作2003中，該用戶端裝置可判定該播放清單檔案是否包括一類型指示符(諸如，「VOD」或「LIVE」或「EVENT」等)。將瞭解，在一實施例中，可使用此等例示性類型之一子集，且在一些實施例中，亦可使用本文中未描述之其他類型。若用戶端裝置判定播放清單包括一類型指示符，則在操作2007中，用戶端裝置適當地使用類型指示符(諸如，以本文中所描述或下文將進一步描述之圖21中所展示之方式)處理播放清單。若在操作2003中用戶端裝置判定播放清單檔案不包括一類型指示符，則在操作2005中，用戶端裝置不使用播放清單類型指示符來處理播放清單(例如，不執行圖21所展示之最佳化)。

圖21根據本發明之一實施例展示各種類型之播放清單類型指示符之一或多個使用之一實例。雖然圖21所示之方法假定可能存在三種不同類型指示符，但將瞭解，可利用較少類型指示符或可利用較多類型指示符以規定播放清單檔案之播放清單類型。亦將瞭解，替代實施例可具有較少操作或較多操作或按不同於圖21所示之次序的次序進行之操作。在操作2101中，用戶端裝置判定播放清單檔案是否包括播放清單類型指示符。若不存在播放清單類型指示符，則在操作2103中，用戶端裝置不使用類型指示符而操作且如本發明之剩餘部分中所描述地處理播放清單檔案。另一方面，若播放清單類型指示符存在，則在操作2105中，用戶端裝置判定類型指示符是否為「LIVE」指示符，在類型指示符為「LIVE」指示符之情況下，在操作2107中，將用戶端裝置設定為重複地更新播放清單檔案。若在操作2105中，用戶端裝置判定類型指示符不為「LIVE」指示符，則在操作2109中，用戶端裝置判定類型指示符是否為「VOD」類型。若類型指示符為「VOD」，則在操作2111中，將用戶端裝置設定為不更新播放清單檔案，且用戶端裝置亦可執行操作2113及2115。在操作2113中，用戶端裝置可在使用另一變體播放清單之同時儲存先前使用之變體播放清單，以防用戶端裝置必須切換回至先前使用之播放清單。舉例而言，在接收隨選視訊內容之第二變體播放清單且切換至使用其之後，用戶端可儲存可為同一隨選視訊之較低品質或較低位元速率呈現之播放清單的第一變體播放清單，因為第一變體播放清單在切換之後仍將有效且可在第二變體播放清單之使用變得有問題之情況下(諸如，當網路頻寬變得較低時等)使用。在操作2115中，用戶端裝置可檢查「ENDLIST」標籤或類似標籤，且在一實施例中若在播放清單檔案中未發現該標籤，則在操作2117中，用戶端裝置可將播放清單檔案標記為有錯誤。

若在操作2109中判定播放清單檔案不包括「VOD」類型指示符，則在操作2119中，用戶端裝置判定播放清單檔案是否包括「EVENT」類型指示符，且若包括，則用戶端裝置執行操作2123，否則執行操作2121，在操作2121中，不使用類型指示符來處理播放清單檔案或使用本文中未描述之不同類型指示符來處理播放清單檔案。在操作2123中，當請求經更新之播放清單時，用戶端裝置可僅重新載入經更新之播放清單之超出當前播放位置的最新近部分，或載入整個經更新之播放清單，但僅剖析經更新之播放清單之超出當前播放位置的最新近部分。以此方式，用戶端裝置可藉由避免處理已在用戶端裝置處呈現之播放清單之部分或藉由避免經由網路接收經更新之播放清單之較舊部分而智慧地處理經更新之播放清單。

在一實施例中，用戶端裝置可經組態以儲存與對播放清單檔案中所規定之媒體檔案之資料存取相關之統計資料或與在接收媒體檔案時發生之網路錯誤相關之統計資料。可經由API(應用程式介面)使此等統計資料可供用戶端應用程式使用以允許呈現關於網路錯誤之資訊或關於對媒體檔案之存取之資訊。此資訊可為(例如)顯示器在VOD或實況表演之變體串流之間切換多少次等。圖22展示一架構之一實例，在該架構中，可經由API將統計資料自媒體伺服器應用程式提供至用戶端應用程式。在此架構之情況下，媒體伺服器2201可負責請求並接收一播放清單檔案及處理該播放清單檔案及將內容提供至用戶端應用程式2203。媒體伺服器應用程式2201可建立一或多個記錄檔(10g)，從而將統計資料2205儲存於該一或多個記錄檔中。用戶端應用程式在其需要時或在由使用者請求時可藉由經由API介面2207進行呼叫來呈現關於統計資料之資訊，且作為回應，媒體伺服器2201可擷取所請求之統計資料且經由API介面2207將彼等統計資料提供至用戶端應用程式2203。媒體伺服器2201可在播放或提供串流傳輸內容時收集統計資料且可根據來自用戶端應用程式2203之需求經由API介面2207將統計資料提供至用戶端應用程式2203。用戶端應用程式2203可負責將統計資料記錄檔提供至彙總服務且可控制報告來自記錄檔之資訊的時序及頻率。一系統可具有一或多個記錄檔以儲存統計資料，且在一實施例中，記錄檔可遵守W3C擴展記錄檔檔案格式。在一實施例中，可提供兩種類型之記錄檔：存取記錄檔及錯誤記錄檔。

在存取記錄檔中，每當用戶端切換變體、進行搜尋或伺服器IP位址改變時，可產生新記錄檔輸入項(行)。最後一行可含有當前變體之統計資料。以下欄位可提供於存取記錄檔中：

sc-count　#在播放此變體時下載之區段之數目，<整數>

date　#此變體之播放開始的日期，<日期>

time　#此變體之播放開始的時間(UTC)，<時間>

uri　#播放清單檔案之URI，<uri>

s-ip　#提供媒體之伺服器之IP位址，<位址>

cs-guid　#由與單一播放作業階段相關之所有下載共用之GUID(作為HTTP GET請求之部分供應)，<文字>

c-start-time　#播放清單中開始播放處的位移，<固定>#秒

c-duration-downloaded　#下載之媒體持續時間，<固定>#秒

c-duration-watched　#觀看之媒體持續時間，<固定>#秒

c-stalls　#用戶端播放暫停、需要重新緩衝之次數，<整數>

c-frames-dropped　#在播放期間丟棄之視訊圖框之數目，<整數>

bytes　#傳送之位元組之數目，<整數>

c-observed-bitrate　#下載時觀測到的頻寬，<固定>位元/秒

sc-indicated-bitrate　#播放串流所需之頻寬，<固定>位元/秒

對初始播放延時感興趣之用戶端可獨立地報告起始播放之當日時間。可結合第一變體之日期/時間使用此當日時間以計算起動持續時間。在一實施例中亦可包括記錄檔伺服器重定向。在錯誤記錄檔中，每當遇到網路錯誤時可產生新記錄檔輸入項(行)。以下欄位可提供於錯誤記錄檔中：

date　#錯誤發生之日期，<日期>

time　#錯誤發生之時間(UTC)，<時間>

uri　#失敗存取之URI，<uri>

s-ip　#藉由解析URI中的主機而獲取之IP位址，<位址>，可選

cs-guid　#GUID(與存取記錄檔相同的cs-guid)

status　#錯誤狀態碼，<整數>

comment　#與狀態碼一起傳回之註解，<文字>，可選

圖8為電子系統之一實施例的方塊圖。圖8中所說明之電子系統意欲代表一系列電子系統(有線或無線)，其包括(例如)桌上型電腦系統、膝上型電腦系統、蜂巢式電話、包括具備蜂巢式電話功能之PDA的個人數位助理(PDA)、視訊轉換器、娛樂系統或其他消費型電子裝置。替代電子系統可包括更多、更少及/或不同組件。圖8之電子系統可用以提供用戶端裝置及/或伺服器裝置。

電子系統800包括用以傳達資訊之匯流排805或其他通信裝置，及耦接至匯流排805之可處理資訊之處理器810。雖然電子系統800經說明為具有單一處理器，但電子系統800可包括多個處理器及/或共處理器。電子系統800進一步可包括耦接至匯流排805之隨機存取記憶體(RAM)或其他動態儲存裝置820(被稱為主記憶體)且可儲存可由處理器810執行之資訊及指令。主記憶體820亦可用以在由處理器810執行指令期間儲存暫時變數或其他中間資訊。

電子系統800亦可包括耦接至匯流排805之唯讀記憶體(ROM)及/或其他靜態儲存裝置830，其可儲存用於處理器810之靜態資訊及指令。資料儲存裝置840可耦接至匯流排805以儲存資訊及指令。諸如快閃記憶體或磁碟或光碟及對應磁/光碟機之資料儲存裝置840可耦接至電子系統800。

電子系統800亦可經由匯流排805耦接至顯示裝置850(諸如，陰極射線管(CRT)或液晶顯示器(LCD))以向使用者顯示資訊。電子系統800亦可包括文數字輸入裝置860(包括文數字及其他鍵)，其可耦接至匯流排805以將資訊及命令選擇傳達至處理器810。另一類型之使用者輸入裝置為用以將方向資訊及命令選擇傳達至處理器810且控制顯示器850上之游標移動的游標控制870，諸如，觸控板、滑鼠、軌跡球或游標方向鍵。

電子系統800進一步可包括用以提供對網路(諸如，區域網路)之存取的一或多個網路介面880。網路介面880可包括(例如)具有天線885(其可代表一或多個天線)之無線網路介面。電子系統800可包括多個無線網路介面，諸如，WiFi介面、藍芽介面及蜂巢式電話介面之組合。網路介面880亦可包括(例如)用以經由網路纜線887(其可為例如乙太網路纜線、同軸纜線、光纖纜線、串並纜線或並並纜線)而與遠端裝置通信之有線網路介面。

在一實施例中，網路介面880可(例如)藉由遵守IEEE 802.11b及/或IEEE 802.11g標準來提供對區域網路之存取，及/或無線網路介面可(例如)藉由遵守藍芽標準來提供對個人區域網路之存取。亦可支援其他無線網路介面及/或協定。

除了經由無線LAN標準通信之外，或替代經由無線LAN標準通信，網路介面880可使用(例如)分時多重存取(TDMA)協定、全球行動通信系統(GSM)協定、分碼多重存取(CDMA)協定及/或任何其他類型之無線通信協定來提供無線通信。

在一些實施例中可使用一或多個應用程式設計介面(API)。API為由程式碼組件或硬體組件(在下文中為「API實施組件」)實施的介面，其允許不同程式碼組件或硬體組件(在下文中為「API呼叫組件」)存取並使用由API實施組件提供之一或多個函式、方法、程序、資料結構、類別及/或其他服務。API可定義在API呼叫組件與API實施組件之間傳遞的一或多個參數。

API允許API呼叫組件之開發者(其可為第三方開發者)利用由API實施組件提供之規定特徵。可存在一個API呼叫組件，或可能存在一個以上此組件。API可為電腦系統或程式庫提供以便支援來自應用程式之對服務之請求的原始程式碼介面。作業系統(OS)可具有多個API以允許在OS上執行之應用程式呼叫彼等API中之一或多者，且服務(諸如，程式庫)可具有多個API以允許使用該服務之應用程式呼叫彼等API中之一或多者。可在建置應用程式時根據可被解譯或編譯之程式設計語言來規定API。

在一些實施例中，API實施組件可提供一個以上API，每一者提供由API實施組件實施之功能性的不同態樣之不同視圖或具有存取由API實施組件實施之功能性之不同態樣的不同態樣。舉例而言，API實施組件之一個API可提供功能之第一集合且可暴露於第三方開發者，且API實施組件之另一API可被隱藏(未暴露)且提供功能之第一集合之一子集且亦提供功能之另一集合(諸如，不在功能之第一集合中之測試或除錯功能)。在其他實施例中，API實施組件自身可經由基礎API呼叫一或多個其他組件，且因此為API呼叫組件及API實施組件兩者。

API定義API呼叫組件在存取及使用API實施組件之規定特徵時使用之語言及參數。舉例而言，API呼叫組件經由API所暴露的一或多個API呼叫或調用(例如由函式或方法呼叫體現)來存取API實施組件之規定特徵，且經由API呼叫或調用使用參數來傳遞資料及控制資訊。API實施組件可回應於來自API呼叫組件之API呼叫而經由API傳回一值。儘管API定義API呼叫之語法及結果(例如，如何調用API呼叫及API呼叫進行何操作)，但API可不顯露API呼叫如何完成API呼叫所規定之功能。經由該一或多個應用程式設計介面在呼叫(API呼叫組件)與API實施組件之間傳送各種API呼叫。傳送API呼叫可包括發佈、起始、調用、呼叫、接收、傳回或回應於函式呼叫或訊息；換言之，傳送可描述由API呼叫組件或API實施組件中之任一者進行之動作。API之函式呼叫或其他調用可經由參數清單或其他結構來發送或接收一或多個參數。參數可為常數、密鑰、資料結構、物件、物件類別、變數、資料類型、指標、陣列、函式或方法之清單或至函式或方法之指標，或用以參考待經由API傳遞之資料或其他項目之另一方式。

此外，資料類型或類別可由API提供且由API實施組件實施。因此，API呼叫組件可藉由使用API中所提供之定義來宣告變數、使用至此等類型或類別之常數值之指標、使用或具現化此等類型或類別之常數值。

一般而言，API可用以存取由API實施組件提供之服務或資料，或起始由API實施組件提供之操作或計算之執行。以實例說明，API實施組件及API呼叫組件可各自為作業系統、程式庫、裝置驅動程式、API、應用程式或其他模組中之任一者(應瞭解，API實施組件及API呼叫組件可為彼此相同或不同類型之模組)。在一些情況下，API實施組件可至少部分地以韌體、微碼或其他硬體邏輯體現。在一些實施例中，API可允許用戶端程式使用由軟體開發套件(SDK)程式庫提供之服務。在其他實施例中，應用程式或其他用戶端程式可使用由應用程式框架(Application Framework)提供之API。在此等實施例中，應用程式或用戶端程式可併有對由SDK提供及由API提供之函式或方法之呼叫，或使用定義於SDK中且由API提供之資料類型或物件。在此等實施例中，應用程式框架可提供程式之主要事件迴圈，其回應於由框架定義之各種事件。API允許應用程式使用應用程式框架來規定事件及對事件之回應。在一些實施中，API呼叫可向應用程式報告硬體裝置之能力或狀態，包括與諸如輸入能力及狀態、輸出能力及狀態、處理能力、電力狀態、儲存容量及狀態、通信能力等的態樣相關之彼等能力或狀態，且API可部分地由韌體、微碼或部分地在硬體組件上執行之其他低階邏輯實施。

API呼叫組件可為本端組件(亦即，在與API實施組件相同的資料處理系統上)或經由API經由網路與API實施組件通信之遠端組件(亦即，在不同於API實施組件的資料處理系統上)。應理解，API實施組件亦可充當API呼叫組件(亦即，該組件可進行對由不同API實施組件暴露之API之API呼叫)，且API呼叫組件亦可藉由實施暴露於不同API呼叫組件之API來充當API實施組件。

API可允許以不同程式設計語言撰寫之多個API呼叫組件與API實施組件通信(因此，API可包括用於在API實施組件與API呼叫組件之間轉譯呼叫及傳回的特徵)；然而，可根據特定程式設計語言實施API。在一實施例中，API呼叫組件可呼叫來自不同提供者之API，諸如，來自OS提供者之API之一集合及來自外掛程式提供者之API之另一集合及來自另一提供者(例如，軟體程式庫之提供者)或API之另一集合之建立者的API之另一集合。

圖18為說明可在本發明之一些實施例中使用之例示性API架構的方塊圖。如圖18所示，API架構1800包括實施API 1820之API實施組件1810(例如，作業系統、程式庫、裝置驅動程式、API、應用程式、軟體或其他模組)。API 1820規定API實施組件之可由API呼叫組件1830使用之一或多個函式、方法、類別、物件、協定、資料結構、格式及/或其他特徵。API 1820可規定至少一呼叫慣例，其規定API實施組件中之函式如何自API呼叫組件接收參數及該函式如何將結果傳回至API呼叫組件。API呼叫組件1830(例如，作業系統、程式庫、裝置驅動程式、API、應用程式、軟體或其他模組)經由API 1820進行API呼叫以存取及使用API實施組件1810之由API 1820規定的特徵。API實施組件1810可回應於API呼叫而經由API 1820將一值傳回至API呼叫組件1830。

將瞭解，API實施組件1810可包括未經由API 1820規定且API呼叫組件1830不可用之額外函式、方法、類別、資料結構及/或其他特徵。應理解，API呼叫組件1830可在與API實施組件1810相同的系統上，或可遠端地定位且使用API 1820經由網路存取API實施組件1810。雖然圖18說明與API 1820互動之單一API呼叫組件1830，但應理解，可能以不同於API呼叫組件1830之語言(或相同語言)撰寫之其他API呼叫組件可使用API 1820。

API實施組件1810、API 1820及API呼叫組件1830可儲存於機器可讀非暫時性儲存媒體中，該儲存媒體包括用於儲存呈機器(例如，電腦或其他資料處理系統)可讀形式之資訊的任何機構。舉例而言，機器可讀媒體包括磁碟、光碟、隨機存取記憶體；唯讀記憶體、快閃記憶體裝置等。

在圖19(「軟體堆疊」)的例示性實施例中，應用程式可使用若干服務API進行對服務1或2之呼叫且使用若干OS API進行對作業系統(OS)之呼叫。服務1及2可使用若干OS API對OS進行呼叫。

請注意，服務2具有兩個API，其中之一者(服務2 API 1)接收來自應用程式1之呼叫且將值傳回至應用程式1，且其中之另一者(服務2 API 2)接收來自應用程式2之服務且將值傳回至應用程式2。服務1(其可為例如軟體程式庫)進行對OS API 1的呼叫且接收來自OS API 1之傳回值，且服務2(其可為例如軟體程式庫)進行對OS API 1及OS API 2兩者的呼叫且接收來自OS API 1及OS API 2兩者之傳回值。應用程式2進行對OS API 2的呼叫且接收來自OS API 2之傳回值。

說明書中對「一實施例」之參考意謂著關於該實施例所描述之特定特徵、結構或特性包括於本發明之至少一實施例中。片語「在一實施例中」出現於說明書中各處時未必全部指代同一實施例。

在前述說明書中，已參考本發明之特定實施例描述了本發明。然而，很顯然，可在不脫離本發明之更廣泛精神及範疇的情況下作出各種修改及變化。因此，應將說明書及圖式視為說明性意義而非限制性意義的。

附錄

以下附錄為根據本發明之一特定實施例之協定之草案說明書。將理解，特定關鍵詞(例如，必須、不得、應該、不應該等)在此附錄中之使用適用於此特定實施例，但不適用於本發明中所描述之其他實施例。

HTTP實況串流傳輸 draft-pantos-http-live-streaming-06

摘要

本文件描述用於傳送多媒體資料之無限制串流之協定。本文件規定檔案之資料格式及串流之伺服器(發送者)及用戶端(接收器)將採取之動作。本文件描述此協定之版本3。

目錄

1.介紹

2.概述

3.播放清單檔案

3.1.介紹

3.2.屬性清單

3.3.新標籤

3.3.1. EXT-X-TARGETDURATION

3.3.2. EXT-X-MEDIA-SEQUENCE

3.3.3. EXT-X-KEY

3.3.4. EXT-X-PROGRAM-DATE-TIME

3.3.5. EXT-X-ALLOW-CACHE

3.3.6. EXT-X-PLAYLIST-TYPE

3.3.7. EXT-X-ENDLIST

3.3.8. EXT-X-STREAM-INF

3.3.9. EXT-X-DISCONTINUITY

3.3.10. EXT-X-VERSION

4.媒體檔案

5.密鑰檔案

5.1.介紹

5.2.用於AES-128之IV

6.用戶端/伺服器動作

6.1.介紹

6.2.伺服器處理程序

6.2.1.介紹

6.2.2.滑動窗播放清單

6.2.3.加密媒體檔案

6.2.4.提供變體串流

6.3.用戶端處理程序

6.3.1.介紹

6.3.2.載入播放清單檔案

6.3.3.播放播放清單檔案

6.3.4.重新載入播放清單檔案

6.3.5.判定要載入之下一個檔案

6.3.6.解密加密的媒體檔案

7.協定版本相容性

8.實例

8.1.介紹

8.2.簡單播放清單檔案

8.3.滑動窗播放清單，使用HTTPS

8.4.具有加密媒體檔案之播放清單檔案

8.5.變體播放清單檔案

9.安全考慮

10.參考文獻

10.1.標準性參考文獻

10.2.資訊性參考文獻

1.介紹

本文件描述用於傳送多媒體資料之無限制串流之協定。該協定支援加密媒體資料及提供串流之替代版本(例如，位元速率)。媒體資料可在其建立之後不久被傳送，從而允許媒體資料以幾乎即時之方式播放。資料通常經由HTTP[RFC2616]攜載。

描述諸如HTTP之相關標準之外部參考文獻列出於章節11中。

2.概述

多媒體呈現由URI[RFC3986]在播放清單檔案中規定，播放清單檔案為媒體URI及資訊標記之有序清單。每一媒體URI參考為單一連續串流之一區段的一媒體檔案。

為了播放串流，用戶端首先獲取播放清單檔案且接著獲取並播放播放清單中之每一媒體檔案。如本文件中所描述，用戶端重新載入播放清單檔案以發現額外區段。

應如RFC 2119[RFC2119]中所描述地解譯本文件中之關鍵詞「必須」、「不得」、「需要」、「應該」、「不應該」、「應」、「不應」、「推薦」、「可」及「可選」。

3.播放清單檔案 3.1.介紹

播放清單必須為擴展M3U播放清單檔案[M3U]。本文件藉由定義額外標籤來擴展M3U檔案格式。

M3U播放清單為由個別行組成之文字檔案。行以單一LF字元或繼之以LF字元之CR字元終止。每一行為URI、空白的或以註解字元「#」開始。忽略空白行。除了明確規定有空白區域之元素之外，空白區域不得存在。

URI行識別媒體檔案或變體播放清單檔案(參見章節3.3.8)。

URI可為相對的。相對的URI必須對照含有其之播放清單檔案之URI來解析。

以註解字元「#」開始之行為註解或標籤。標籤以#EXT開始。以「#」開始之所有其他行為註解且應忽略。

一播放清單檔案之持續時間為該播放清單檔案內之媒體檔案之持續時間之總和。

名稱以.m3u8結尾及/或具有HTTP內容-類型「application/vnd.apple.mpegurl」之M3U播放清單檔案係以UTF-8[RFC3629]編碼。名稱以.m3u結尾及/或具有HTTP內容-類型[RFC2616]「audio/mpegurl」之檔案係以US-ASCII[US_ASCII]編碼。

播放清單檔案必須具有以.m3u8結尾之名稱及/或具有內容-類型「application/vnd.apple.mpegurl」(若經由HTTP傳送)，或具有以.m3u結尾之名稱及/或具有HTTP內容-類型類型「audio/mpegurl」(出於相容性)。

擴展M3U檔案格式定義兩個標籤：EXTM3U及EXTINF。擴展M3U檔案憑其必須為「#EXTM3U」之第一行而區別於基本M3U檔案。

EXTINF為描述由其後之URI識別的媒體檔案之記錄標記。每一媒體檔案URI之前必須有一EXTINF標籤。其格式為：

#EXTINF:<持續時間>,<標題>

「持續時間」為規定媒體檔案之以秒計之持續時間之整數或浮點數。整數持續時間應捨位至最接近的整數。若播放清單檔案之協定版本低於3，則持續時間必須為整數。該行的在逗號之後的剩餘部分為媒體檔案之標題，其為媒體區段之可選人類可讀之資訊標題。

本文件定義以下新標籤：EXT-X-TARGETDURATION、EXT-X-MEDIA-SEQUENCE、EXT-X-KEY、EXT-X-PROGRAM-DATE-TIME、EXT-X-ALLOW-CACHE、EXT-X-PLAYLIST-TYPE、EXT-X-STREAM-INF、EXT-X-ENDLIST、EXT-X-DISCONTINUITY及EXT-X-VERSION。

3.2.屬性清單

特定擴展M3U標籤具有為屬性清單之值。屬性清單為不具空白區域之屬性/值對的以逗號分離之清單。

屬性/值對具有以下語法：

AttributeName=AttributeValue

AttributeName為含有來自集合[A-Z]之字元之無引號串。

AttributeValue為下列各者中之一者：

○十進位整數：來自集合[0-9]之字元之無引號串，其表示十進位算術中之整數。

○十六進位整數：來自集合[0-9]及[A-F]之字元之無引號串，其以0x或0X為前置詞且表示十六進位算術中之整數。

○十進位浮點：來自集合[0-9]及「.」之字元之無引號串，其表示十進位算術中之浮點數。

○有引號串：在一對雙引號(")內之字元之串。串中所允許之字元之集合及用於使特殊字元逸出之任何規則係由屬性定義規定，但任何雙引號(")字元及任何歸位字元或換行字元將始終由逸出序列替換。

○列舉串：來自由屬性明確定義之一集合之無引號字元串。列舉串絕不會含有雙引號(")、逗號(,)或空白區域。

○十進位解析度：由「x」字元分離之兩個十進位整數，其指示水平及垂直像素尺寸。

給定AttributeName之AttributeValue之類型係由屬性定義規定。

給定AttributeName在給定屬性清單中不得出現一次以上。

用戶端必須忽略具有未辨識AttributeName之屬性/值對。

用戶端應忽略含有未辨識值之列舉串類型之屬性/值對。

3.3.新標籤 3.3.1. EXT-X-TARGETDURATION

EXT-X-TARGETDURATION標籤規定最大媒體檔案持續時間。播放清單檔案中之每一媒體檔案之EXTINF持續時間必須小於或等於目標持續時間。此標籤在播放清單檔案中必須出現一次。

該標籤之格式為：

#EXT-X-TARGETDURATION:<s>

其中s為指示以秒計之目標持續時間之整數。

3.3.2. EXT-X-MEDIA-SEQUENCE

播放清單中之每一媒體檔案URI具有唯一整數序號。URI之序號等於在其之前的URI之序號加上1。EXT-X-MEDIA-SEQUENCE標籤指示出現在播放清單檔案中之第一個URI之序號。

該標籤之格式為：

#EXT-X-MEDIA-SEQUENCE:<數字>

播放清單檔案不得含有一個以上之EXT-X-MEDIA-SEQUENCE標籤。若播放清單檔案不含有EXT-X-MEDIA-SEQUENCE標籤，則應該將播放清單中之第一個URI之序號視為0。

媒體檔案之序號不需要出現在其URI中。

參見章節6.3.2及章節6.3.5以獲取關於處置EXT-X-MEDIA-SEQUENCE標籤之資訊。

3.3.3. EXT-X-KEY

可加密媒體檔案。EXT-X-KEY標籤提供解密其後之媒體檔案所需之資訊。

該標籤之格式為：

#EXT-X-KEY:<attribute-list>

定義以下屬性：

方法屬性規定加密方法。其為列舉串之類型。定義兩個方法：NONE及AES-128。

加密方法NONE意謂著不加密媒體檔案。若加密方法為NONE，則URI及IV屬性不得存在。

加密方法AES-128意謂著使用利用128位元密鑰及PKCS7填補[RFC5652]之進階加密標準[AES_128]加密媒體檔案。若加密方法為AES-128，則URI屬性必須存在。IV屬性可存在；參見章節5.2。

URI屬性規定如何獲得密鑰。該屬性之值為含有密鑰之URI[RFC3986]之有引號串。

IV屬性(若存在)規定將與密鑰一起使用的初始化向量。該屬性之值為十六進位整數。IV屬性出現在協定版本2中。

新EXT-X-KEY取代任何先前EXT-X-KEY。

若播放清單檔案不含有EXT-X-KEY標籤，則不加密媒體檔案。

參見章節5以獲取密鑰檔案之格式，且參見章節5.2、章節6.2.3及章節6.3.6以獲取關於媒體檔案加密之額外資訊。

3.3.4. EXT-X-PROGRAM-DATE-TIME

EXT-X-PROGRAM-DATE-TIME標籤使下一個媒體檔案之開頭與絕對日期及/或時間相關聯。日期/時間表示為ISO/IEC 8601:2004[ISO_8601]且應指示時區。舉例而言：

#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

參見章節6.2.1及章節6.3.3以獲取關於EXT-X-PROGRAM-DATE-TIME標籤之更多資訊。

3.3.5. EXT-X-ALLOW-CACHE

EXT-X-ALLOW-CACHE標籤指示用戶端是否可或不得快取下載之媒體檔案以供稍後重放。該標籤可出現在播放清單檔案中之任何處；該標籤不得出現一次以上。EXT-X-ALLOW-CACHE標籤適用於播放清單中之所有區段。該標籤之格式為：

#EXT-X-ALLOW-CACHE：<是|否>

參見章節6.3.3以獲取關於EXT-X-ALLOW-CACHE標籤之更多資訊。

3.3.6. EXT-X-PLAYLIST-TYPE

EXT-X-PLAYLIST-TYPE標籤提供關於播放清單檔案之可變動性資訊。該標籤為可選的。該標籤之格式為：

#EXT-X-PLAYLIST-TYPE：<事件|VOD>

章節6.2.1定義EXT-X-PLAYLIST-TYPE標籤之含意。

3.3.7. EXT-X-ENDLIST

EXT-X-ENDLIST標籤指示沒有更多媒體檔案將添加至播放清單檔案。該標籤可出現在播放清單檔案中之任何處；該標籤不得出現一次以上。該標籤之格式為：

#EXT-X-ENDLIST

3.3.8. EXT-X-STREAM-INF

EXT-X-STREAM-INF標籤指示播放清單檔案中之下一個URI識別另一播放清單檔案。該標籤之格式為：

#EXT-X-STREAM-INF：<attribute-list><URI>

定義以下屬性：

BANDWIDTH

該值為每秒位元之十進位整數。該屬性必須為每一媒體檔案之總位元速率之上限，其經計算以包括出現或將出現在播放清單中之容器附加項。

每個EXT-X-STREAM-INF標籤必須包括BANDWIDTH屬性。

PROGRAM-ID

該值為在播放清單檔案之範疇內唯一地識別特定呈現之十進位整數。

播放清單檔案可含有具有相同PROGRAM-ID之多個EXT-X-STREAM-INF標籤以識別相同呈現之不同編碼。此等變體播放清單可含有額外EXT-X-STREAM-INF標籤。

CODECS

該值為含有以逗號分離之格式清單的有引號串，其中每一格式規定存在於播放清單檔案中之媒體檔案中的媒體樣本類型。有效格式識別符為由RFC 4281[RFC4281]定義之ISO檔案格式名稱空間中之彼等識別符。

每個EXT-X-STREAM-INF標籤應包括CODECS屬性。

RESOLUTION

該值為描述串流內之視訊之近似編碼水平解析度及垂直解析度的十進位解析度。

3.3.9. EXT-X-DISCONTINUITY

EXT-X-DISCONTINUITY標籤指示該標籤之後的媒體檔案與在該標籤之前的媒體檔案之間的編碼不連續性。可變化之特性之集合為：

○檔案格式

○播放軌之數目及類型

○編碼參數

○編碼序列

○時間戳記序列

該標籤之格式為：

#EXT-X-DISCONTINUITY

參見章節4、章節6.2.1及章節6.3.3以獲取關於EXT-X-DISCONTINUITY標籤之更多資訊。

3.3.10. EXT-X-VERSION

EXT-X-VERSION標籤指示播放清單檔案之相容性版本。播放清單檔案、其相關聯媒體及其伺服器必須遵守描述標籤值所指示之協定版本的此文件之最新近版本之所有條款。

該標籤之格式為：

#EXT-X-VERSION:<n>

其中n為指示協定版本之整數。

播放清單檔案不得含有一個以上之EXT-X-VERSION標籤。不含有EXT-X-VERSION標籤之播放清單檔案必須遵守此協定之版本1。

4.媒體檔案

播放清單檔案中之每一媒體檔案URI必須識別為全部呈現之區段的媒體檔案。每一媒體檔案必須格式化為MPEG-2輸送串流或MPEG-2音訊基本串流[ISO_13818]。

輸送串流檔案必須含有單一MPEG-2節目。在每一檔案之開頭處應存在節目關聯表及節目映射表。含有視訊之檔案應具有至少一關鍵圖框及足以完全初始化視訊解碼器之資訊。

播放清單中之媒體檔案必須為在具有先前序號之媒體檔案之結尾處之經編碼串流的繼續，除非該媒體檔案為曾出現在播放清單檔案中之第一媒體檔案或該媒體檔案以一EXT-X-DISCONTINUITY標籤為前置詞。

用戶端應準備好處置特定類型(例如，音訊或視訊)之多個播放軌。不具有其他偏好之用戶端應選擇其可播放之具有最低數字PID之播放軌。

用戶端必須忽略輸送串流內之其未辨識之專用串流。

用於媒體檔案內之串流內及跨多個媒體檔案之對應串流之間的樣本之編碼參數應保持一致。然而，用戶端應在遇到編碼變化時(例如)藉由縮放視訊內容以適應解析度變化來處理編碼變化。

5.密鑰檔案 5.1.介紹

具有URI屬性之EXT-X-KEY標籤識別密鑰檔案。密鑰檔案含有必須用以解密播放清單中之後續媒體檔案之編密密鑰。

AES-128加密方法使用16-八位元密鑰。密鑰檔案之格式簡單地為二進位格式之此等16個八位元之封裝陣列。

5.2.用於AES-128之IV

128位元AES需要在加密及解密時供應相同的16-八位元初始化向量(IV)。改變此IV增加了密碼之強度。

若EXT-X-KEY標籤具有IV屬性，則實施在用彼密鑰加密或解密時必須使用該屬性值作為IV。該值必須解譯為128位元十六進位數且必須以0x或0X作為前置詞。

若EXT-X-KEY標籤不具有IV屬性，則實施在加密或解密媒體檔案時必須使用彼媒體檔案之序號作為IV。序號之位元組由大到小(big-endian)二進位表示應該置於16-八位元緩衝器中且以零填補(在左側)。

6.用戶端/伺服器動作 6.1.介紹

此章節描述伺服器如何產生播放清單及媒體檔案，及用戶端應如何下載並播放該等檔案。

6.2.伺服器處理程序 6.2.1.介紹

MPEG-2串流之產生不在本文件之範疇內，本文件簡單地假定含有呈現之連續串流之源。

伺服器必須將串流劃分成持續時間小於或等於恆定目標持續時間之個別媒體檔案。伺服器應嘗試在支援個別媒體檔案之有效解碼之點(例如，在封包邊界及關鍵圖框邊界上)劃分串流。

伺服器必須為每一媒體檔案建立URI，其將允許伺服器之用戶端獲取該檔案。

伺服器必須建立播放清單檔案。播放清單檔案必須符合章節3中所描述之格式。伺服器希望使之可用之每一媒體檔案之URI必須按媒體檔案將播放之次序出現在播放清單中。若媒體檔案之URI在播放清單檔案中，則整個媒體檔案必須可供用戶端使用。

播放清單檔案必須含有EXT-X-TARGETDURATION標籤。該標籤之值必須等於或大於出現或將出現在播放清單檔案中之任何媒體檔案之EXTINF值。該標籤之值不得改變。典型目標持續時間為10秒。

播放清單檔案應含有一個EXT-X-VERSION標籤，其指示串流之相容性版本。該標籤之值必須為伺服器、播放清單檔案及相關聯的媒體檔案皆遵守之最低協定版本。

伺服器必須為播放清單檔案建立URI，其將允許伺服器之用戶端獲取該檔案。

若播放清單檔案係藉由HTTP散佈，則伺服器應支援使用「gzip」內容編碼之用戶端請求。

自用戶端之觀點而言，對播放清單檔案之變化必須原子地進行。

伺服器不得改變播放清單檔案，但以下情況除外：

將行附加至播放清單檔案(章節6.2.1)。

按媒體檔案URI出現之次序將媒體檔案URI以及僅適用於彼等媒體檔案之任何標籤一起自播放清單移除(章節6.2.2)。

改變EXT-X-MEDIA-SEQUENCE標籤之值(章節6.2.2)。

添加或移除EXT-X-STREAM-INF標籤(章節6.2.4)。請注意，不要求用戶端重新載入變體播放清單檔案，因此改變播放清單檔案可不具有即刻影響。

將EXT-X-ENDLIST標籤添加至播放清單(章節6.2.1)。

此外，播放清單檔案可含有值為EVENT或VOD之EXT-X-PLAYLIST-TYPE標籤。若該標籤存在且具有值EVENT，則伺服器不得改變或刪除播放清單檔案之任何部分(儘管伺服器可將行附加至播放清單檔案)。若該標籤存在且具有值VOD，則播放清單檔案不得改變。

播放清單中之每個媒體檔案URI必須以指示媒體檔案之持續時間之EXTINF標籤作為前置詞。

伺服器可藉由以EXT-X-PROGRAM-DATE-TIME標籤作為其URI之前置詞而使絕對日期及時間與媒體檔案相關聯。日期及時間之值提供媒體之時刻表至適當時鐘時間之資訊映射，其可用作為用於尋找、用於顯示或用於其他目的之基礎。若伺服器提供此映射，則伺服器應將EXT-X-PROGRAM-DATE-TIME標籤置放於播放清單檔案中之每個EXT-X-DISCONTINUITY標籤之後。

若播放清單含有呈現之最後媒體檔案，則播放清單檔案必須含有EXT-X-ENDLIST標籤。

若播放清單不含有EXT-X-ENDLIST標籤，則伺服器必須使含有至少一新媒體檔案URI的播放清單檔案之新版本可用。必須相對於播放清單檔案之先前版本可用之時間而使新版本可用：不早於在該時間之後的目標持續時間之一半，且不遲於在該時間之後的目標持續時間之1.5倍。

若伺服器希望移除整個呈現，則其必須使播放清單檔案不可供用戶端使用。伺服器應確保播放清單檔案中之所有媒體檔案在移除時在至少播放清單檔案之持續時間中保持可供用戶端使用。

6.2.2.滑動窗播放清單

伺服器可將媒體檔案之可用性限於最近已添加至播放清單之彼等媒體檔案。為此，播放清單檔案必須始終含有正好一個EXT-X-MEDIA-SEQUENCE標籤。該標籤之值必須針對自播放清單檔案移除之每個媒體檔案URI而遞增1。

必須按添加媒體檔案URI之次序自播放清單檔案移除媒體檔案URI。

若播放清單檔案之持續時間減去媒體檔案之持續時間小於三倍的目標持續時間，則伺服器不得自播放清單檔案移除媒體檔案URI。

當伺服器自播放清單移除媒體檔案URI時，媒體檔案應在一等於該媒體檔案之持續時間加上該媒體檔案已出現於之最長播放清單檔案之持續時間的時間段中保持可供用戶端使用。

若伺服器計劃在經由HTTP將媒體檔案傳遞至用戶端之後移除媒體檔案，則伺服器應確保HTTP回應含有一反映所計劃的存留時間之逾期標頭。

6.2.3.加密媒體檔案

若將加密媒體檔案，則伺服器必須定義允許經授權用戶端獲取含有解密密鑰之密鑰檔案之URI。密鑰檔案必須符合章節5中所描述之格式。

伺服器可設定密鑰回應中之HTTP逾期標頭以指示密鑰可被快取。

若加密方法為AES-128，則應該將AES-128 CBC加密應用於個別媒體檔案。必須加密整個檔案。不得跨媒體檔案應用密碼區塊鏈結。用於加密之IV必須為媒體檔案之序號或EXT-X-KEY標籤之IV屬性之值，如章節5.2中所描述。

伺服器必須使用由播放清單檔案中之緊接在媒體檔案URI之前之EXT-X-KEY標籤規定的方法及其他屬性加密播放清單中之每個媒體檔案。不得加密前面有METHOD為NONE之EXT-X-KEY標籤或前面沒有任何EXT-X-KEY標籤之媒體檔案。

若播放清單檔案含有至用該密鑰加密之媒體檔案之URI，則伺服器不得自播放清單檔案移除EXT-X-KEY標籤。

6.2.4.提供變體串流

伺服器可供給多個播放清單檔案以提供相同呈現之不同編碼。若伺服器供給多個播放清單檔案，則伺服器應提供列出每一變體串流之變體播放清單檔案以允許用戶端在編碼之間動態地切換。

變體播放清單必須含有每一變體串流之EXT-X-STREAM-INF標籤。相同呈現之每一EXT-X-STREAM-INF標籤必須具有相同PROGRAM-ID屬性值。每一呈現之PROGRAM-ID值在變體播放清單內必須為唯一的。

若EXT-X-STREAM-INF標籤含有CODECS屬性，則該屬性值必須包括存在於出現或將出現在播放清單檔案中之任何媒體檔案中的由[RFC4281]定義之每個格式。

當產生變體串流時，伺服器必須滿足以下約束：

每一變體串流必須呈現相同內容，包括串流不連續性。

每一變體播放清單檔案必須具有相同目標持續時間。

出現在一個變體播放清單檔案中，但不出現在另一變體播放清單檔案中之內容必須出現在播放清單檔案之開頭或結尾處且不得比目標持續時間長。

變體串流中之匹配內容必須具有匹配之時間戳記。此允許用戶端將串流同步。

基本音訊串流檔案必須藉由在前面加上(prepend)具有所有者識別符「com.apple.streaming.transportStreamTimestamp」之ID3 PRIV標籤[ID3]而傳訊檔案中之第一樣本之時間戳記。二進位資料必須為表示為位元組由大到小的8-八位元數之33位元MPEG-2節目基本串流時間戳記，其中前31個位元經設定為零。

另外，所有變體串流應含有相同的經編碼音訊位元串流。此允許用戶端在串流之間切換而無聲訊故障。

6.3.用戶端處理程序 6.3.1.介紹

用戶端如何獲取至播放清單檔案之URI不在本文件之範疇內；假定已獲取播放清單檔案。

用戶端必須根據URI獲取播放清單檔案。若如此獲取之播放清單檔案為變體播放清單，則用戶端必須自變體播放清單獲取播放清單檔案。

本文件未規定用戶端對變體串流之處理。

6.3.2.載入播放清單檔案

每當自播放清單URI載入或重新載入播放清單檔案時：

用戶端必須確保播放清單檔案以EXTM3U標籤開始且EXT-X-VERSION標籤(若存在)規定用戶端所支援之協定版本；若否，則用戶端不得嘗試使用該播放清單。

用戶端應忽略其未辨識之任何標籤及屬性。

用戶端必須判定要載入之下一個媒體檔案，如章節6.3.5中所描述。

若播放清單含有EXT-X-MEDIA-SEQUENCE標籤，則用戶端應假設：播放清單中之每一媒體檔案在載入播放清單檔案時以及在播放清單檔案之持續時間中將變得不可用。播放清單檔案之持續時間為該播放清單檔案內之媒體檔案之持續時間之總和。

6.3.3.播放播放清單檔案

當開始播放時，用戶端應該自播放清單選擇要首先播放哪個媒體檔案。若EXT-X-ENDLIST標籤不存在且用戶端意欲有規則地播放媒體(亦即，在標稱播放速率下按播放清單次序)，則用戶端不應選擇開始時間距播放清單檔案之結尾小於三個目標持續時間之檔案。選擇此檔案可觸發播放暫停。

為了達成規則播放，媒體檔案必須按媒體檔案出現在播放清單檔案中之次序播放。用戶端可以其希望之任何方式呈現可用媒體，包括規則播放、隨機存取及竅門模式(trick mode)。

用戶端在播放前面有EXT-X-DISCONTINUITY標籤之媒體檔案之前必須準備好重設其剖析器及解碼器。

用戶端應嘗試在需要媒體檔案以實現無中斷播放之前載入媒體檔案以補償延時及輸送量之暫時變化。

若播放清單檔案含有EXT-X-ALLOW-CACHE標籤且標籤之值為NO，則用戶端不得在已下載之媒體檔案已播放之後快取該等下載之媒體檔案。否則，用戶端可無限期地快取下載之媒體檔案以供稍後重放。

用戶端可使用EXT-X-PROGRAM-DATE-TIME標籤之值向使用者顯示節目起源時間。若值包括時區資訊，則用戶端應該考慮其，但若該值不包括時區資訊，則用戶端不得推斷起源時區。

用戶端不得取決於EXT-X-PROGRAM-DATE-TIME標籤之值之正確性或一致性。

6.3.4.重新載入播放清單檔案

除非播放清單檔案含有EXT-X-ENDLIST標籤，否則用戶端必須週期性地重新載入播放清單檔案。

然而，用戶端不得嘗試比此章節所規定的頻繁度更頻繁地重新載入播放清單檔案。

當用戶端第一次載入播放清單檔案，或重新載入播放清單檔案且發現該播放清單檔案自其上次載入以來已變化時，用戶端在嘗試再次重新載入該播放清單檔案之前必須等待一段時間。將此時段稱為初始最小重新載入延遲。自用戶端開始載入播放清單檔案之時間起量測該延遲。

初始最小重新載入延遲為播放清單中之上一個媒體檔案之持續時間。媒體檔案持續時間係由EXTINF標籤規定。

若用戶端重新載入播放清單檔案且發現該播放清單檔案未變化，則用戶端必須在重試之前等待一段時間。最小延遲為目標持續時間的倍數。此倍數對第一嘗試為0.5、對第二嘗試為1.5且對此後之嘗試為3.0。

為了減輕伺服器負擔，用戶端不應重新載入當前不在播放之變體串流之播放清單檔案。若伺服器決定將播放切換至一不同變體，則其應停止重新載入舊變體之播放清單且開始載入新變體之播放清單。伺服器可使用EXTINF持續時間及章節6.2.4中之約束來判定對應媒體之近似位置。一旦已載入來自新變體之媒體，就可將媒體檔案中之時間戳記用以使舊時刻表與新時刻表精確同步。

6.3.5.判定要載入之下一個檔案

每當載入或重新載入播放清單檔案時，用戶端必須檢查播放清單檔案以判定要載入之下一個媒體檔案。

要載入之第一檔案必須為用戶端已選擇為首先播放之檔案，如章節6.3.3中所描述。

若已載入待播放之第一檔案且播放清單檔案不含有EXT-X-MEDIA-SEQUENCE標籤，則用戶端必須驗證：當前播放清單檔案在最初發現上一次載入之媒體檔案之位移處含有上一次載入之媒體檔案之URI，在未發現該URI之情況下暫停播放。要載入之下一個媒體檔案必須為播放清單中之在上一次載入之URI之後的第一媒體檔案URI。

若待播放之第一檔案已被載入且播放清單檔案含有EXT-X-MEDIA-SEQUENCE標籤，則要載入之下一個媒體檔案應該為具有大於所載入之上一個媒體檔案之序號之最小序號的媒體檔案。

6.3.6.解密加密的媒體檔案

若播放清單檔案含有規定密鑰檔案URI之EXT-X-KEY標籤，則用戶端裝置必須獲取該密鑰檔案且使用該密鑰檔案內之密鑰解密EXT-X-KEY標籤之後的所有媒體檔案，直至遇到另一EXT-X-KEY標籤為止。

若加密方法為AES-128，則應該將AES-128 CBC解密應用於個別媒體檔案。必須解密整個檔案。不得跨媒體檔案應用密碼區塊鏈結。用於解密之IV必須為媒體檔案之序號或EXT-X-KEY標籤之IV屬性之值，如章節5.2中所描述。

若加密方法為NONE，則用戶端必須將EXT-X-KEY標籤之後的所有媒體檔案視為純文字(未加密)，直至遇到另一EXT-X-KEY標籤為止。

7.協定版本相容性

用戶端及伺服器必須實施協定版本2或更高版本以使用：

○EXT-X-KEY標籤之IV屬性。

用戶端及伺服器必須實施協定版本3或更高版本以使用：

○浮點EXTINF持續時間值。

8.實例 8.1.介紹

此章節含有若干實例播放清單檔案。

8.2.簡單播放清單檔案

#EXTM3U

#EXT-X-TARGETDURATION:5220

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

8.3.滑動窗播放清單，使用HTTPS

#EXTM3U

#EXT-X-TARGETDURATION:8

#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,

https://priv.example.com/fileSequence2680.ts

#EXTINF:8,

https://priv.example.com/fileSequence2681.ts

#EXTINF:8,

https://priv.example.com/fileSequence2682.ts

8.4.具有加密媒體檔案之播放清單檔案

#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/fileSequence52-1.ts

#EXTINF:15,

http://media.example.com/fileSequence52-2.ts

#EXTINF:15,

http://media.example.com/fileSequence52-3.ts

#EXT-X-KEY:METHOD=AES-

128,URI="https://priv.example.com/key.php?r=53"

#EXTINF:15,

http://media.example.com/fileSequence53-1.ts

8.5.變體播放清單檔案

#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

9.安全考慮

由於協定通常使用HTTP來傳送資料，故大多數相同安全考慮都適用。參見RFC 2616[RFC2616]之章節15。

媒體檔案剖析器通常遭受「模糊(fuzzing)」攻擊。用戶端在剖析自伺服器接收之檔案時應注意拒絕不符合要求的檔案。

播放清單檔案含有URI，用戶端將使用該等URI進行對任意實體之網路請求。用戶端應對回應作範圍檢查以防止緩衝器溢位。亦參見RFC 3986[RFC3986]之安全考慮章節。

用戶端應延遲地載入由URI識別之資源以避免促成拒絕服務的攻擊。

HTTP請求經常包括作業階段狀態(「小文字檔(cookie)」)，其可含有專用使用者資料。實施必須遵循由RFC 2965[RFC2965]規定之期滿規則及cookie限制。亦參見RFC 2965之安全考慮章節及RFC 2964[RFC2964]。

加密密鑰係由URI規定。此等密鑰之傳遞應受諸如TLS[RFC5246](以前的SSL)上之HTTP之機制結合安全領域或作業階段cookie保護。

10.參考文獻 10.1標準性參考文獻

[AES_128]美國商務部/國家標準技術局，「Advanced Encryption Standard(AES),FIPS PUB 197」，2001年11月，<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>>。

[ISO_13818]國際標準化組織，「ISO/IEC International Standard 13818;Generic coding of moving pictures and associated audio information」，2007年10月，<http://www.iso.org/iso/catalogue_detail?csnumber=44169>。

[ISO_8601]國際標準化組織，「ISO/IEC International Standard 8601:2004;Data elements and interchange formats--Information interchange--Representation of dates and times」，2004年12月，<http://www.iso.org/iso/catalogue_detail?csnumber=40874>。

[RFC2046] Freed,N.及N. Borenstein之「Multipurpose Internet Mail Extensions(MIME) Part Two: Media Types」，RFC 2046，1996年11月。

[RFC2119] Bradner,S.之「Key words for use in RFCs to Indicate Requirement Levels」，BCP 14，RFC 2119，1997年3月。

[RFC2616] Fielding,R.、Gettys,J.、Mogul,J.、Frystyk,H.、Masinter,L.、Leach,P.及T. Berners-Lee之「Hypertext Transfer Protocol--HTTP/1.1」,RFC 2616，1999年6月。

[RFC2964] Moore,K.及N. Freed之「Use of HTTP State Management」，BCP 44，RFC 2964，2000年10月。

[RFC2965] Kristol,D.及L. Montulli之「HTTP State Management Mechanism」，RFC 2965，2000年10月。

[RFC3629] Yergeau,F.之「UTF-8,a transformation format of ISO 10646」，STD 63，RFC 3629，2003年11月。

[RFC3986] Berners-Lee,T.、Fielding,R.及L. Masinter之「Uniform Resource Identifier(URI): Generic Syntax」，STD 66，RFC 3986，2005年1月。

[RFC4281] Gellens,R.、Singer,D.及P. Frojdh之「The Codecs Parameter for「Bucket」Media Types」，RFC 4281，2005年11月。

[RFC5246] Dierks,T.及E. Rescorla之「The Transport Layer Security(TLS) Protocol Version 1.2」，RFC 5246，2008年8月。

[RFC5652] Housley,R.之「Cryptographic Message Syntax(CMS)」，STD 70，RFC 5652，2009年9月。

[US_ASCII]美國國家標準局，「ANSI X3.4-1986,Information Systems--Coded Character Sets 7-Bit American National Standard Code for Information Interchange(7-Bit ASCII)」，1986年12月。

10.2.資訊性參考文獻

[ID3] ID3.org <http://ID3.org/>，「The ID3 audio file data tagging format」，<http://www.id3.org/Developer_Information>。

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

110．．．網路

120．．．伺服器

130．．．分段器

135．．．索引器

140．．．安全代理

145．．．超文字傳送協定(HTTP)伺服器代理

150．．．用戶端裝置

160．．．組譯器代理

165．．．輸出產生器代理

170．．．安全代理

180．．．用戶端裝置

185．．．安全代理

190．．．組譯器代理

195．．．輸出產生器代理

200．．．操作

202．．．操作

205．．．操作

210．．．操作

212．．．操作

215．．．操作

220．．．操作

222．．．操作

225．．．操作

230．．．操作

232．．．操作

235．．．操作

240．．．操作

242．．．操作

245．．．操作

250．．．操作

252．．．操作

255．．．操作

270．．．操作

272．．．操作

275．．．操作

282．．．操作

285．．．操作

292．．．操作

297．．．操作

300．．．操作

310．．．操作

320．．．操作

330．．．操作

340．．．操作

350．．．操作

351．．．操作

352．．．操作

370．．．操作

375．．．操作

380．．．操作

385．．．操作

390．．．操作

394．．．操作

395．．．操作

396．．．操作

400．．．伺服器串流代理

410．．．控制邏輯

412．．．應用程式

414．．．記憶體

416．．．介面

420．．．伺服器串流引擎

430．．．分段器

440．．．索引器

450．．．安全性

460．．．檔案伺服器

500．．．用戶端串流代理

510．．．控制邏輯

512．．．應用程式

514．．．記憶體

516．．．介面

520．．．用戶端串流引擎

530．．．組譯器

540．．．輸出產生器

550．．．安全性

600．．．播放清單檔案

610．．．開始標籤

620．．．持續時間標籤

625．．．日期/時間標籤

630．．．序列標籤

640．．．安全性標籤

645．．．變體清單標籤

650．．．媒體檔案指示符

660．．．後續播放清單指示符

670．．．記憶體標籤

680．．．結束標籤

700．．．操作

710．．．操作

720．．．操作

730．．．操作

740．．．操作

750．．．操作

760．．．操作

800．．．電子系統

805．．．匯流排

810．．．處理器

820．．．隨機存取記憶體(RAM)或其他動態儲存裝置

830．．．唯讀記憶體(ROM)及/或其他靜態儲存裝置

840．．．資料儲存裝置

850．．．顯示裝置

860．．．文數字輸入裝置

870．．．游標控制

880．．．網路介面

885．．．天線

887．．．網路纜線

901．．．操作

903．．．操作

905．．．操作

907．．．操作

911．．．操作

913．．．操作

915．．．操作

921．．．操作

923．．．操作

925．．．操作

927．．．操作

931．．．操作

941．．．操作

943．．．操作

945．．．操作

951．．．串流

951A．．．音訊樣本

951B．．．視訊樣本

953．．．串流

953A．．．音訊樣本

953B．．．視訊樣本

955．．．重疊

957．．．區段

959．．．轉變點

961．．．i圖框

1002．．．操作

1004．．．操作

1006．．．操作

1008．．．操作

1010．．．操作

1012．．．操作

1014．．．操作

1102．．．用戶端

1201．．．操作

1203．．．操作

1205．．．操作

1209．．．時間

1211．．．時刻表

1213．．．目標持續時間

1215．．．播放清單持續時間

1217．．．時間

1219．．．時間

1301．．．操作

1303．．．操作

1401．．．操作

1403．．．操作

1405．．．操作

1410．．．舊串流

1411．．．雜湊標記

1412．．．播放點

1414．．．新串流

1415．．．區塊

1415A．．．區塊

1416．．．區塊

1416A．．．下載之區塊

1501．．．操作

1503．．．操作

1505．．．操作

1610．．．方塊

1620．．．方塊

1630．．．方塊

1650．．．方塊

1652．．．區塊

1654．．．區塊

1656．．．區塊

1657．．．區塊

1658．．．區塊

1660．．．顯示裝置

1661．．．內容

1662．．．時刻表

1663．．．標記

1664．．．時刻表

1665．．．標記

1666．．．時刻表

1667．．．指示符

1668．．．返回控制項

1669．．．暫停控制項

1670．．．向前快轉控制項

1672．．．操作

1673．．．操作

1674．．．操作

1710．．．媒體伺服精靈協助程式

1720．．．事件媒體提供者(EMP)應用程式

1721．．．核心媒體堆疊

1723．．．網路連接堆疊

1725．．．事件媒體提供者(EMP)處理常式

1730．．．事件媒體提供者(EMP)伺服器

1800．．．應用程式設計介面(API)架構

1810．．．應用程式設計介面(API)實施組件

1820．．．應用程式設計介面(API)

1830．．．應用程式設計介面(API)呼叫組件

2001．．．操作

2003．．．操作

2005．．．操作

2007．．．操作

2101．．．操作

2103．．．操作

2105．．．操作

2107．．．操作

2109．．．操作

2111．．．操作

2113．．．操作

2115．．．操作

2117．．．操作

2119．．．操作

2121．．．操作

2123．．．操作

2201．．．媒體伺服器應用程式

2203．．．用戶端應用程式

2205．．．統計資料

2207．．．應用程式設計介面(API)介面

圖1為可發送及接收即時或幾乎即時內容之伺服器及用戶端之一實施例的方塊圖。

圖2A為用於一或多個伺服器裝置的使用非串流傳輸協定支援媒體內容之技術之一實施例的流程圖。

圖2B為用於一或多個伺服器裝置的以動態方式將經更新之播放清單提供至一或多個用戶端裝置之技術之一實施例的流程圖。

圖2C為用於一或多個伺服器裝置的使用多個位元速率將媒體內容提供至用戶端裝置之技術之一實施例的流程圖。

圖3A為用於用戶端裝置的用以使用非串流傳輸協定支援內容之串流之技術之一實施例的流程圖。

圖3B為用於用戶端裝置的用以使用多個位元速率支援內容之串流之技術之一實施例的流程圖。

圖4為伺服器串流代理之一實施例的方塊圖。

圖5為用戶端串流代理之一實施例的方塊圖。

圖6說明具有多個標籤之播放清單檔案之一實施例。

圖7為如本文中所描述的用於經組譯串流之播放技術之一實施例的流程圖。

圖8為電子系統之一實施例的方塊圖。

圖9A為展示用戶端裝置如何可在變體播放清單中之替代內容之間切換之一實例的流程圖。

圖9B為展示用戶端裝置如何可在兩個播放清單中之內容之間切換的另一流程圖。

圖9C為展示用戶端裝置如何可使用音訊型樣匹配在內容之間切換之一實例的另一流程圖。

圖9D圖示地展示如何利用音訊型樣匹配來實施圖9C之方法。

圖10為用於提供使用替代串流將媒體內容提供至用戶端裝置之多個冗餘位置之技術之一實施例的流程圖。

圖11說明一網路，其中根據一實施例用戶端1102與一或多個URL雙向通信。

圖12A為描繪根據本發明之一實施例的用於控制播放清單之建立及散佈之方法的流程圖。

圖12B展示在一實施例中可如何使用(例如)圖12A所示之方法傳輸或以其他方式散佈播放清單的時刻表。

圖13為根據本發明之一實施例的用於控制用戶端裝置處之播放之方法。

圖14A展示描繪在一實施例中用於基於連接速度或連接類型而適應性地判定最小重疊之量之方法的流程圖。圖14B、圖14C及圖14D展示使用重疊以用於在串流之間切換之實施例的另一態樣。

圖15為描繪根據本發明之一實施例的另一方法之流程圖。

圖16A展示描繪根據一實施例的用於使用有時間戳記之標籤建立播放清單檔案之方法的流程圖。

圖16B展示描繪根據一實施例的用於使用播放清單檔案中之有時間戳記之標籤來搜尋媒體檔案之方法的流程圖。

圖16C展示用於控制來自接收器處之緩衝的串流傳輸內容之播放的使用者介面之一實施例。

圖16D展示在UI之時刻表上之指示符已移動之後的圖16C之實施例。

圖16E為展示用於使用圖16C及圖16D所示之使用者介面之實施例之方法的流程圖。

圖17展示允許媒體伺服精靈協助程式與使用者應用程式互動之軟體架構之一實例。

圖18說明可在本發明之一些實施例中使用之例示性API架構的方塊圖。

圖19展示可在本發明之一些實施例中使用之軟體堆疊的例示性實施例。

圖20為展示根據一實施例之可使用播放清單類型指示符之方法之一實例的流程圖。

圖21為展示可使用播放清單類型指示符之方法之另一實例的流程圖。

圖22為一架構之一實例，在該架構中，可經由API將統計資料自媒體伺服器應用程式提供至用戶端應用程式。

2001．．．操作

2003．．．操作

2005．．．操作

2007．．．操作

Claims (17)

1. 一種機器可讀、有形、非暫時性儲存媒體，其儲存當執行時使一資料處理系統執行包含以下步驟之一方法的可執行指令：用一用戶端裝置向一伺服器裝置請求一播放清單檔案(playlist file)，其中該用戶端裝置經組態以利用該播放清單檔案播放媒體內容；回應於該請求在該用戶端裝置處自該伺服器裝置接收該播放清單檔案，該播放清單檔案具有通用資源指示符(URI)，該等URI指示自一資料串流(a stream of data)劃分出來的複數個媒體檔案及具有與該複數個媒體檔案之播放(playback)相關之參數的複數個標籤，以重新產生該資料串流；藉由該用戶端裝置剖析(parsing)該播放清單檔案，且判定該複數個標籤之一者包括具有一指示該播放清單檔案之一類型之一類型參數之PLAYLIST-TYPE標籤，其中該類型參數包括隨選視訊(video on demand；VOD)、實況或事件之一者；藉由該用戶端裝置剖析該播放清單檔案，以判定該複數個標籤之一者是否包括一ENDLIST標籤，該ENDLIST標籤指示沒有更多媒體檔案將添加至播放清單檔案；回應於具有該類型參數"實況(live)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以重複地向該伺服器裝置請求一經更新 之播放清單檔案；回應於具有該類型參數"事件(event)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以請求一經更新之播放清單檔案；藉由該用戶端裝置依該播放清單檔案所指示之一次序(order)向該伺服器裝置請求該等媒體檔案之一或多個；及藉由該用戶端裝置使用非串流傳輸協定透過一網路自該伺服器裝置接收經請求之該一或多個媒體檔案。
2. 如請求項1之媒體，其進一步包括，回應於具有該類型參數"隨選視訊(VOD)"之該PLAYLIST-TYPE標籤，組態該用戶端裝置以：不向該伺服器裝置請求一經更新之播放清單檔案；及產生一錯誤信號以回應於判定該播放清單檔案不包括該ENDLIST標籤。
3. 如請求項2之媒體，其中當該類型參數為VOD時，該播放清單檔案無變化，且該用戶端裝置經組態以在切換至由該播放清單檔案參考之內容之一變體播放清單(variant playlist)時儲存該播放清單檔案以供未來使用。
4. 如請求項1之媒體，其中當該類型參數為事件時，該事件具有一事件播放清單檔案(event playlist file)之一規定且固定之開始時間，且該用戶端裝置經組態以藉由以下任一種方式處理該播放清單：(a)僅載入該經更新之播放 清單檔案之一部分；或(b)載入整個該經更新之播放清單檔案且僅剖析該經更新之播放清單檔案之一部分。
5. 如請求項2之媒體，其中該方法進一步包含藉由用該用戶端裝置按由該播放清單檔案指示之該次序播放該等媒體檔案產生表示該內容串流之一音訊或視訊或一音訊/視訊輸出，且其中該非串流傳輸傳送協定包含一符合超文字傳送協定(HTTP)之協定。
6. 如請求項1之媒體，其中該方法進一步包含：將與對該等媒體檔案之資料存取或在接收該等媒體檔案時出現之網路錯誤相關之統計資料儲存於至少一記錄檔中；經由一API(應用程式介面)接收一請求以獲取該等統計資料。
7. 一種由一資料處理系統執行之機器實施方法，該方法包含：用一用戶端裝置向一伺服器裝置請求一播放清單檔案，其中該用戶端裝置經組態以利用該播放清單檔案播放媒體內容；回應於該請求在該用戶端裝置處自該伺服器裝置接收該播放清單檔案，該播放清單檔案具有通用資源指示符(URI)，該等URI指示複數個媒體檔案及具有與該複數個媒體檔案之播放相關之參數的複數個標籤；藉由該用戶端裝置剖析(parsing)該播放清單檔案，且判定該複數個標籤之一者包括具有一指示該播放清單 檔案之一類型之一類型參數之PLAYLIST-TYPE標籤，其中該類型參數包括隨選視訊(video on demand；VOD)、實況或事件之一者；藉由該用戶端裝置剖析該播放清單檔案，以判定該複數個標籤之一者是否包括一ENDLIST標籤，該ENDLIST標籤指示沒有更多媒體檔案將添加至播放清單檔案；回應於具有該類型參數"實況(live)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以重複地向該伺服器裝置請求一經更新之播放清單檔案；回應於具有該類型參數"事件(event)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以請求一經更新之播放清單檔案；藉由該用戶端裝置依該播放清單檔案所指示之一次序向該伺服器裝置請求該等媒體檔案之一或多個；及藉由該用戶端裝置使用非串流傳輸協定透過一網路自該伺服器裝置接收經請求之該一或多個媒體檔案。
8. 如請求項7之方法，其進一步包括，回應於具有該類型參數"隨選視訊(VOD)"之該PLAYLIST-TYPE標籤，組態該用戶端裝置以：不向該伺服器裝置請求一經更新之播放清單檔案；及產生一錯誤信號以回應於判定該播放清單檔案不包括該ENDLIST標籤。
9. 如請求項8之方法，其中當該類型參數為VOD時，該播放清單無變化，且該用戶端裝置經組態以在切換至由該播放清單參考之內容之一變體播放清單時儲存該播放清單以供未來使用。
10. 如請求項7之方法，其中當該類型參數為事件時，該事件具有一事件播放清單檔案之一規定且固定之開始時間，且該用戶端裝置經組態以藉由以下任一種方式處理該播放清單：(a)僅載入該經更新之播放清單檔案之一部分；或(b)載入整個該經更新之播放清單檔案且僅剖析該經更新之播放清單檔案之一部分。
11. 如請求項8之方法，其中該方法進一步包含藉由用該用戶端裝置以由該播放清單檔案指示之該次序播放該等媒體檔案產生表示該內容串流之一音訊或視訊或一音訊/視訊輸出，且其中該非串流傳輸傳送協定包含一符合超文字傳送協定(HTTP)之協定。
12. 一種資料處理系統，其包含：用於用一用戶端裝置向一伺服器裝置請求一播放清單檔案之構件，其中該用戶端裝置經組態以利用該播放清單檔案播放媒體內容；用於回應於該請求在該用戶端裝置處自該伺服器裝置接收該播放清單檔案之構件，該播放清單檔案具有通用資源指示符(URI)，該等URI指示複數個媒體檔案及具有與該複數個媒體檔案之播放相關之參數的複數個標籤；用於藉由該用戶端裝置剖析該播放清單檔案，且判定 該複數個標籤之一者包括具有一指示該播放清單檔案之一類型之一類型參數之PLAYLIST-TYPE標籤之構件，其中該類型參數包括隨選視訊、實況或事件之一者；藉由該用戶端裝置剖析該播放清單檔案，以判定該複數個標籤之一者是否包括一ENDLIST標籤，該ENDLIST標籤指示沒有更多媒體檔案將添加至播放清單檔案；回應於具有該類型參數"實況(live)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以重複地向該伺服器裝置請求一經更新之播放清單檔案；回應於具有該類型參數"事件(event)"之PLAYLIST-TYPE標籤及判定該播放清單檔案不包括該ENDLIST標籤，組態該用戶端裝置以請求一經更新之播放清單檔案；藉由該用戶端裝置依該播放清單檔案所指示之一次序向該伺服器裝置請求該等媒體檔案之一或多個；及藉由該用戶端裝置使用非串流傳輸協定透過一網路自該伺服器裝置接收經請求之該一或多個媒體檔案。
13. 如請求項12之系統，其進一步包括，回應於具有該類型參數"隨選視訊(VOD)"之該PLAYLIST-TYPE標籤，組態該用戶端裝置以：不向該伺服器裝置請求一經更新之播放清單檔案；及產生一錯誤信號以回應於判定該播放清單檔案不包括該ENDLIST標籤。
14. 如請求項13之系統，其中當該類型參數為VOD時，該播放清單無變化，且該用戶端裝置經組態以在切換至由該播放清單參考之內容之一變體播放清單時儲存該播放清單以供未來使用，且其中當該類型參數為事件時，該事件具有一事件播放清單之一規定且固定之開始時間，且該用戶端裝置經組態以藉由以下任一種方式處理該播放清單：(a)僅載入該經更新之播放清單檔案之一部分；或(b)載入整個該經更新之播放清單檔案且僅剖析該經更新之播放清單檔案之一部分。
15. 一種機器可讀、有形、非暫時性儲存媒體，其儲存當執行時使一資料處理系統執行包含以下步驟之一方法的可執行指令：在一伺服器裝置處自一用戶端裝置接收對一播放清單檔案之一請求，其中該用戶端裝置經組態以利用該播放清單檔案播放媒體內容；回應於該請求自該伺服器裝置傳輸該播放清單檔案，該播放清單檔案具有通用資源指示符(URI)，該等URI指示複數個媒體檔案及具有與該複數個媒體檔案之播放相關之參數的複數個標籤，其中該複數個標籤之一者包括具有一指示該播放清單檔案之一類型之一類型參數之PLAYLIST-TYPE標籤，且其中該類型參數包括隨選視訊、實況或事件之一者；回應來自一用戶端裝置的請求，該用戶端裝置經組態以根據該類型參數處理該播放清單檔案； 藉由該伺服器裝置依該播放清單檔案所指示之一次序自該用戶端裝置接收對該等媒體檔案之一或多個之請求；及藉由該伺服器裝置使用非串流傳輸協定透過一網路將經請求之該一或多個媒體檔案傳輸至該用戶端裝置。
16. 如請求項15之媒體，其中使用非串流傳輸協定透過該網路傳輸該播放清單。
17. 如請求項16之媒體，其中當該類型參數為VOD時，該播放清單無變化，該用戶端裝置經組態以不請求該播放清單之更新，且該用戶端裝置經組態以在切換至由該播放清單參考之內容之一變體播放清單時儲存該播放清單以供未來使用，且其中當該類型參數為實況時，該用戶端裝置經組態以重複地請求一經更新之播放清單，且其中當該類型參數為事件時，一事件具有一事件播放清單之一規定且固定之開始時間，且該用戶端裝置經組態以藉由以下任一種方式處理該播放清單：(a)僅載入該經更新之播放清單檔案之一部分；或(b)載入整個該經更新之播放清單檔案且僅剖析該經更新之播放清單檔案之一部分。