專利名稱：實時或準實時流傳輸的制作方法
技術領域：
本發(fā)明的實施例涉及數據傳輸技術。更特別地，本發(fā)明的實施例涉及允許數據流使用非流傳輸協(xié)議的技術，例如超文本傳輸協(xié)議(HTTP)。
背景技術：
內容流通常涉及持續(xù)從服務器設備傳送并由客戶端設備接收的多媒體內容。該內容通常呈現(xiàn)給端用戶，同時該內容由流服務器傳送。該名稱涉及介質的傳送方法而不是該介質本身。當前的流服務通常需要專門的服務器分配“實況”內容給端用戶。在任何大規(guī)模部署中，這會導致大的開銷，并需要專門的技術來創(chuàng)建和運行。其結果就是可供流傳輸的內容庫比預期的要少。

發(fā)明內容
在一個實施例中，一種系統(tǒng)可基于日期和時間搜索內容。例如，在一個實施例中，創(chuàng)建時間戳標簽，每一個所述時間戳標簽可以與特定媒體文件相聯(lián)系。在時間戳標簽中的時間戳指示相關媒體文件的開始日期和時間。注意所述媒體文件包括其自己的內部時間戳?？梢岳靡粋€或多個時間戳標簽創(chuàng)建播放列表文件?？梢允褂盟鰰r間戳標簽中的日期和時間分配所述播放列表文件并使其可用于通過日期和時間的搜索。在一個實施例中，所述時間戳標簽可使用一種被稱為ID3的格式。在一個實施例中，一種方法可在客戶端設備上執(zhí)行用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)。所述方法進一步在所述客戶端設備上運行媒體服務進程以取回指定所述媒體文件的播放列表以及可獲得所述媒體文件的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼。所述用戶應用可被配置成通過自定義URL或自定義協(xié)議或者這兩者與一個或多個服務器通信，即使所述媒體服務進程不被配置來處理所述自定義URL或自定義協(xié)議。所述自定義URL或自定義協(xié)議可指定或提供解密密鑰以用于解密所述媒體文件中的加密內容。在具有與通過所述一個或多個接口與其他被調用的程序代碼交互的調用程序代碼的環(huán)境中，一些實施例包括一個或多個應用編程接口(API)。進一步可能包括不同類型參數的不同函數調用、消息或其他調用類型可以通過所述調用程序和被調用代碼之間的API被傳輸。另外，API能夠為所述調用程序代碼提供使用在API中定義并在所述調用程序代碼中實現(xiàn)的數據類型或類的能力。至少某些實施例包括一種具有通過API與被調用軟件組件交互的調用軟件組件(calling software component)的環(huán)境。一種用于在該環(huán)境中通過API進行操作的方法包括通過所述API傳輸一個或多個函數調用、消息、其他調用類型或參數。本文描述了其他方法，以及用于實現(xiàn)這些方法的系統(tǒng)，本文還描述了存儲可執(zhí)行指令的機器可讀的非暫時性存儲介質，當這些指令被執(zhí)行則會促使數據處理系統(tǒng)實現(xiàn)這些方法中的任何一個。


本發(fā)明通過附圖中的示例的方式闡述，而不是以限制的方式，其中相似的參考數字涉及類似組件。圖I是能夠發(fā)送和接收實時或準實時內容的服務器和客戶端的實施例的框圖。圖2A是用于一個或多個服務器設備使用非流傳輸協(xié)議支持媒體內容的技術的實施例的流程圖。圖2B是用于一個或多個服務器設備為一個或多個客戶端設備提供動態(tài)更新播放列表的技術的實施例的流程圖。圖2C是用于一個或多個服務器設備使用多比特率為客戶端設備提供媒體內容的技術的實施例的流程圖。圖3A是用于客戶端設備使用非流傳輸協(xié)議支持內容的流傳輸的技術的實施例的流程圖。圖3B是用于客戶端設備使用多比特率支持內容的流傳輸的技術的實施例的流程圖。圖4是服務器流代理的實施例的框圖。圖5是客戶端流代理的實施例的框圖。圖6是帶有多標簽的播放列表文件的實施例。圖7是本文描述的用于組合流的重放技術的實施例的流程圖。圖8是電子系統(tǒng)的實施例的框圖。圖9A是顯示客戶端設備如何在不同播放列表的供選擇的內容之間切換的示例的流程圖。圖9B是進一步顯示客戶端設備如何在兩個播放列表的內容之間切換的示例的流程圖。圖9C是進一步顯示客戶端設備如何使用音頻模式匹配在內容之間切換的示例的流程圖。圖9D以圖表法示出如何利用音頻模式匹配來實現(xiàn)圖9C中的方法。圖10是用于使用可替代流提供用于向客戶端設備提供媒體內容的多個冗余位置的技術的實施例的流程圖。圖11示出根據一個實施例的客戶端1102與一個或多個URL進行雙向通信的網絡。圖12A是描述根據本發(fā)明的實施例的用于控制播放列表的創(chuàng)建和分配的方法的流程圖。圖12B示出在一實施例中，播放列表如何能夠使用如圖12A中的方法被傳輸或被分配的時間表。圖13是根據本發(fā)明的實施例的用于在客戶端設備控制重放的方法。圖14A示出描述在一實施例中的用于基于連接速度或連接類型適應性地確定最小重疊量的方法流程圖。圖14B、14C和14D示出使用重疊以在流之間切換的實施例的其他方面。圖15是描述根據本發(fā)明的實施例的另一方法的流程圖。
圖16A是示出描述實施例的用于使用時間戳標簽創(chuàng)建播放列表文件的方法流程圖。圖16B示出描述實施例的用于在播放列表中使用時間戳標簽搜索媒體文件的方法流程圖。圖17A示出用于允許媒體服務后臺程序(daemon)與用戶應用交互的軟件體系結構的示例。圖17B示出使用自定義URL技術的軟件體系結構的示例，圖17C為顯示使用自定義URL技術的方法示例流程圖。圖17D示出提供由使用自定義URL技術的應用實現(xiàn)的方法示例的流程圖；圖17E示出由播放器服務或操作系統(tǒng)或者兩者所實現(xiàn)的方法示例的流程圖。圖18示出在本發(fā)明的某些實施例中可用的示例性API結構的框圖。圖19示出在本發(fā)明的某些實施例中可用的軟件堆棧的示例性實施例。

圖20示出用于允許一個設備控制或啟動另一設備上的媒體重放的軟件體系結構的示例。圖21示出軟件體系結構的示例，其使用圖20和圖21中顯示的兩個不同設備上的軟件體系結構中的軟件的不同組件之間的調用。圖22A和22B示出根據本發(fā)明的實施例的可用于允許兩個設備，例如圖20中顯示的那些設備，進行交互并提供在由另一個設備啟動的一個設備上的遠程重放的方法示例。
具體實施例方式在下面的描述中，闡述了許多特定細節(jié)。但是，本發(fā)明的實施例可以在沒有這些特定細節(jié)下被實踐。在其他情況下，未詳細呈現(xiàn)熟知的電路、結構和技術，以便不模糊對本說明書的理解。本說明書包括版權保護的材料，例如圖形用戶界面圖像的圖示。因此版權所有者，包括本發(fā)明的受讓人，保留他們在這些材料中的權利，包括版權。版權所有者不反對任何人對于專利文件或專利公開的復制，因為其出現(xiàn)在專利商標局文件或記錄中，但除此之外保留所有版權。蘋果公司2009年版權所有。在一實施例中，這里所描述的技術和組件包括使用非流傳輸協(xié)議(例如，HTTP)和其他技術(例如，運動圖像專家組(MPEG)流)傳遞流體驗的機制。例如，可以使用HTTP提供準實時流體驗以廣播“實況”音樂或體育事件、實況新聞、網絡攝像機視頻源(camera feed)等。在一實施例中，協(xié)議可將輸入的媒體數據分割成多個媒體文件并將那些分割的媒體文件存儲到服務器中。該協(xié)議還可創(chuàng)建包括將客戶引導到存儲在服務器上的分割的媒體文件的統(tǒng)一資源標識符(URI)的播放列表文件。當分割的媒體文件按照(多個)播放列表文件被重放時，客戶端可為用戶提供“實況”事件的準實時廣播?？梢砸灶愃品绞教峁╊A錄內容。在一實施例中，服務器可將補充的或替代的媒體內容(例如，廣告、涉及體育事件的統(tǒng)計資料、對主呈現(xiàn)的附加媒體內容)動態(tài)引入到廣播事件中。例如，在媒體事件的客戶端重放過程中，服務器可將附加URI添加到播放列表文件中，URI標識客戶端下載補充媒體文件的位置?？芍甘究蛻舳酥芷诘貜姆掌鳙@取一個或多個更新的播放列表文件，以訪問服務器已引入的任何補充或附加(或者兩者兼有)的媒體內容。在一實施例中，服務器可在累積模式或滾動模式中操作。在累積模式中，服務器創(chuàng)建播放列表文件并在播放列表文件末尾追加媒體文件標識符。當單一的播放列表文件被下載以后，客戶端具有對來自該播放列表文件的流的所有部分的訪問權(例如，用戶可以從表演秀的中間開始)。在滾動模式中，服務器通過以滾動方式從播放列表文件開始處移除媒體文件標識符來限制媒體文件的可用性，從而提供客戶端設備可訪問的媒體內容的滑動窗口。服務器還可以將媒體文件標識符添加到播放列表，并且在滾動模式中，服務器將媒體文件的可用性限制到那些最近添加到播放列表中的文件。然后客戶端重復下載播放列表文件的更新副本以繼續(xù)瀏覽。當內容在時間上是潛在無界的(例如，來自于持續(xù)運作的網絡攝像機的內容)，對于播放列表下載來說滾動方式是有用的?？蛻舳丝稍跐L動模式中繼續(xù)重復請求播放列表直到其在播放列表中發(fā)現(xiàn)結束標記。在一實施例中，該機制通過 提供同一呈現(xiàn)的不同的流來支持比特率切換。例如，可將要被服務的呈現(xiàn)的若干版本存儲在服務器中。每一版本可具有本質上相同的內容但以不同比特率被編碼。這能夠允許客戶端設備在不犧牲重放連續(xù)性的情況下，例如依賴可用帶寬檢測而在比特率之間進行切換。在一實施例中，提供保護特性以保護內容防止未經授權的使用。例如，可使用非順序性媒體文件編號來防止預測。可使用媒體文件的加密?？墒褂貌糠置襟w文件列表。還可提供附加的和/或不同的保護特性。圖I示出能夠發(fā)送和接收實時或準實時內容的服務器和客戶端的實施例的框圖。圖I的例子提供了一種簡單的服務器-客戶端連接，其具有兩個通過網絡耦合到服務器的客戶端。使用這里描述的技術和機制可支持任何數量的客戶端。此外，根據這里描述的技術和機制，多個服務器可提供內容和/或一起操作以提供內容。例如，一個服務器創(chuàng)建內容，創(chuàng)建播放列表并創(chuàng)建多個媒體(例如，文件)，其他服務器存儲和傳輸所創(chuàng)建的內容。網絡110可以是任何類型的網絡，不管是有線的、無線的(例如，IEEE 802.11、802. 16)還是其任何組合。例如，網絡100可以是因特網或內聯(lián)網。作為另一個例子，網絡110可以是蜂窩網絡(例如，3G、CDMA ) ο在一實施例中，客戶端設備150和180能夠通過多個網絡類型通信(例如，每一個設備可通過WiFi無線局域網通信并且也能通過無線蜂窩電話網絡通信)。例如，客戶端設備150和180可以是智能電話或者是能夠在蜂窩式射頻電話網絡和數據網絡中通信的具蜂窩功能的個人數字助理。這些設備能夠在任何類型的網絡中使用這里描述的流機制，或者在必要時甚至能夠在網絡之間切換。服務器120能以本領域已知的任何方式作為HTTP服務器工作。也就是說服務器120包括使用HTTP協(xié)議提供內容的HTTP服務器代理145。雖然圖I的例子以術語HTTP描述，但也能夠以類似方式使用其他協(xié)議。分割器130和索引器135是駐留在服務器120(或多個服務器)中的代理，用于為媒體文件中的內容提供這里所描述的播放列表文件。這些媒體文件和播放列表文件可以通過使用HTTP協(xié)議的HTTP服務器代理145 (或通過其他服務器)在網絡110上提供。這里所討論的代理能夠以硬件、軟件、固件或其組合來實現(xiàn)。分割器130可用于將媒體數據流分割為可通過HTTP協(xié)議傳輸的多個媒體文件。索引器135可用于創(chuàng)建與所分割的媒體文件相對應的播放列表文件，以便客戶端設備能夠重新組合媒體文件來為由服務器120提供的內容提供實時或準實時的傳輸。響應于來自于客戶端設備的一個或多個請求，HTTP服務器代理145 (或其他服務器)傳輸一個或多個例如由索引器135生成的播放列表文件以及例如由分割器130生成的內容的媒體文件。服務器120進一步包括可選安全代理140，其提供一個或多個本文所討論的安全功能(例如，加密)。服務器120還包括在圖I中沒有顯示的附加組件。客戶端設備150和180在網絡110中從服務器120接收播放列表文件和媒體文件?？蛻舳嗽O備可以是能接收在網絡中傳輸的數據并利用通過網絡接收的數據產生輸出的傳輸任何類型的電子設備，例如，無線移動設備、PDA、娛樂設備、消費電子設備等等。輸出可以是媒體類型組合中的任何媒體類型，例如包括音頻、視頻或其任何組合?？蛻舳嗽O備150包括組合代理160和輸出生成器代理165。類似地，客戶端設備180包括組合代理190和輸出生成器代理195。組合代理160和180接收來自服務器120的播放列表文件，并使用播放列表文件從服務器120訪問和下載媒體文件。輸出生成器代理165和195分別使用所下載的媒體文件從客戶端設備150和160生成輸出。輸出可由一個或多個揚聲器、一個或多個顯不屏、揚聲器和顯不屏的組合或任何其他輸入或輸出設備提供?？蛻舳嗽O備還包括存儲器(例如，閃存或DRAM等)以在接收媒體文件時作為緩存(或緩沖區(qū)，buffer)存儲媒體文件(例如，壓縮的媒體文件或解壓縮的媒體文件)；緩存可在當
前呈現(xiàn)內容的時間以外提供相當于許多秒的可呈現(xiàn)內容，以便當下載新的內容時稍后顯示所緩存的內容。該緩存能夠在客戶端設備正試圖通過間歇性慢速網絡連接獲取內容時提供可顯示內容，因此緩存能夠隱藏網絡延遲或連接問題?？蛻舳嗽O備150和180進一步包括可選安全代理170和185，其分別提供一個或多個這里所討論的安全功能?？蛻舳嗽O備150和180還包括圖I中沒有顯示的附加組件。在一實施例中，本申請中描述的技術可用于在非流傳輸協(xié)議(例如，HTTP)上傳輸多媒體數據的無邊界流。實施例還包括媒體數據的加密和/或對備選版本數據流的提供(例如，提供備選比特率)。由于媒體數據在創(chuàng)建之后立刻就可被傳輸，因而可準實時地接收數據。提供用于文件以及用于由多媒體數據流的服務器(發(fā)送者)和客戶端(接收者)所采取的行動的示例數據格式，但是，其他格式也能得到支持?？勺鳛槟M實時流(或準實時流)傳輸的媒體呈現(xiàn)由指示播放列表文件的統(tǒng)一資源指示符(URI)指定。在一實施例中，播放列表文件是附加URI的有序列表。播放列表文件中的每一個URI都引用作為流的一個部分的媒體文件，該流可以是特定節(jié)目的單一連續(xù)的媒體數據流。為了播放媒體數據流，客戶端設備從服務器獲取播放列表文件?？蛻舳诉€獲取和播放由播放列表文件指示的每一個媒體數據文件。在一實施例中，客戶端可動態(tài)地或重復地重新加載播放列表文件以發(fā)現(xiàn)附加的和/或不同的媒體部分。例如，播放列表文件可以是擴展M3U播放列表文件。在一實施例中，使用可有效擴展M3U格式的附加標簽。M3U指的是運動圖像專家組音頻第3層統(tǒng)一資源定位符(MP3 URL)并且是一種用于存儲多媒體播放列表的格式。M3U文件是包含媒體播放器要播放的一個或多個媒體文件的位置的文本文件。在一實施例中，播放列表文件是由多個獨立行組成的擴展M3U格式的文本文件?？赏ㄟ^單獨的LF字符或CR字符后面緊跟LF字符來結束行。每一行都可以是一個URI、一個空行、或以一注釋字符(例如，‘#’)開始。URI標識要被播放的媒體文件?？招锌杀缓雎浴Ｒ宰⑨屪址_頭的行可以是注釋也可以是標簽。標簽可以以#EXT開頭，注釋行可以以#開頭。注釋行通常被服務器和客戶端忽略。在一實施例中，以UTF-8格式對播放列表文件進行編碼。UTF-8 (8比特統(tǒng)一碼轉換格式)是一種可變長度字符編碼格式。在替代實施例中，可使用其他字符編碼格式。在如下示例中，使用包括兩個標簽EXTM3U和EXTINF的擴展M3U格式。通過包括“#EXTM3U”的首行可以從基本M3U文件中識別出擴展M3U文件來。EXTINF是一種記錄標記，描述由跟在標簽之后的URI識別的媒體文件。在一實施例中，每一個媒體文件URI由一個EXTINF標簽引導，例如#EXTINF:〈duration〉，〈title〉其中，“duration”標識媒體文件的持續(xù)時間，“title”為目標媒體文件的標題。
在一實施例中，可使用如下標簽來管理媒體文件的傳輸和重放EXT-X-TARGETDURATION
EXT-X-MEDIA-SEQUENCEEXT-X-KEYEXT-X-PROGRAM-DATE-TIMEEXT-X-ALLOff-CACHEEXT-X-STREAM-INFEXT-X-ENDLISTEXT-X-DISCONTINUITYEXT-X-VERSION下面將對這些標簽的每一個進行更為詳細地描述。雖然描述了關于每一個新標簽的具體格式和屬性，但是具有不同屬性、名稱、格式等的備選實施例也可以得到支持。在一實施例中，EXT-X-TARGETDURAT ION標簽表示將被添加到呈現(xiàn)中的下一個媒體文件的大概持續(xù)時間。其可被包含在重放文件中，且格式可以為#EXT-X_TARGETDURATION:〈seconds〉其中“seconds”表示媒體文件的持續(xù)時間。在一實施例中，實際持續(xù)時間可能與標簽所表不的目標持續(xù)時間稍微有所不同。在一實施例中，每一個表不一個片段的URI都將與片段的大概持續(xù)時間相聯(lián)系；例如，一個片段的URI被加上一個表不該片段的大概持續(xù)時間的標簽作為前綴。在另一個實施例中，EXT-X-TARGETDURATION標簽可以指定最大媒體文件持續(xù)時間；播放列表文件中的每一個媒體文件的EXTINF持續(xù)時間應當小于或等于目標持續(xù)時間，該標簽(其指定最大媒體文件持續(xù)時間)可以在播放列表文件中僅被指定一次且適用于播放列表文件中的所有媒體文件，它的格式可以為#EXT-X-TARGETDURATION:<s>其中“s”為以秒數表示目標持續(xù)時間的整數。播放列表文件中的每一個媒體文件URI都有一個唯一的序號。在一實施例中，一個URI的序號，如果存在的話，等于其之前的那個URI的序號加I。EXT-X-MEDIA-SEQUENCE標簽可以表示出現(xiàn)在播放列表文件中的第一個URI的序號，其格式可以為#EXT-X-MEDIA-SEQUENCE:〈number〉其中“number”為URI的序號。如果播放列表文件不包含#EXT-X_MEDIA_SEQUENCE標簽，那么播放列表的第一個URI的序號可被視為I。在一實施例中，媒體文件的序號并不要求出現(xiàn)在它的URI中，并且在一實施例中，播放列表可僅包含一個EXT-X-MEDI A-SEQUENCE標簽。在一實施例中，序號可以是非順序的；例如，非順序序號如I、5、7、17等使得難以預測序列中的下一個號碼，這有助于保護內容不被剽竊。另一個有助于保護內容的選擇是在任何給定時間都只顯示部分播放列表?？蓪σ恍┟襟w文件進行加密。EXT-X-KEY標簽提供可用于對其后的媒體文件進行解密的信息，其格式可以為#EXT-X-KEY:METHOD=〈method>[，URI=”〈URI>”] [，IV=<IV>]METHOD參數指定加密方法，URI參數，如果出現(xiàn)的話，指定如何獲取密鑰，IV (初始化向量)，如果出現(xiàn)的話，指定用于加密方法(如利用密鑰)中的初始化向量。加密方法為NONE表示沒有加密，在一實施例中，如果指示了 NONE，那么URI和IV參數就不應當出現(xiàn)?？梢允褂枚喾N加密方法，例如AES-128，其表示使用具有128比特密鑰和PKCS7填充的高級加密標準加密的加密方法[參見RFC3852]。新的EXT-X-KEY標簽取代
任何之前的EXT-X-KEY標簽。具有URI參數的EXT-X-KEY標簽標識密鑰文件。密鑰文件可包含要用于對于播放列表文件中列出的隨后的媒體文件進行解密的密碼密鑰。例如，AES-128加密方法使用16字節(jié)密鑰。密鑰文件的格式可以是二進制格式的16字節(jié)的合并(packed)數組。AES-128的使用通常要求在加密和解密時提供相同的16字節(jié)初始化向量(IV)。改變IV可用于增加密碼的強度。當使用AES-128加密算法時，在加密或解密媒體文件時媒體文件的序號可被用作IV。EXT-X-PROGRAM-DATE-TIME標簽可使得下一個媒體文件的開始與絕對日期和/或時間相關聯(lián)，并包含或指示時區(qū)。在一實施例中，日期/時間表示法為IS0/IEC 8601:2004。在該標簽中的日期和時間值能夠提供媒體時間線到合適的墻鐘時間的信息映射，其可用作基于日期和時間而為顯示或其他目的的尋找用于重放的內容的基礎。在一實施例中，如果服務器提供該映射，就應當在播放列表文件中每一個EXT-X-DISC0NTI⑶ITY標簽后面放置一 EXT-X-PROGRAM-DATE-UME標簽。該標簽格式可以為EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh: mm:ssZ>EXT-X-ALLOff-CACHE標簽可用于指示客戶端是否可為之后的重放而緩存所下載的媒體文件。在一實施例中該標簽可出現(xiàn)在播放列表文件的任何地方，但是，在一實施例中該標簽在播放列表文件中只能出現(xiàn)一次。該標簽格式可以為EXT-X-ALLOff-CACHE:〈YES|NO〉EXT-X-ENDLIST標簽在一實施例中指示再沒有媒體文件將被添加到播放列表文件中。該標簽格式可以為EXT-X-ENDLIST在一實施例中，如果一播放列表包含媒體文件的最后部分，那么播放列表將具有EXT-X-ENDLIST標簽。在一實施例中，該標簽可出現(xiàn)在播放列表文件的任何地方，并且在一實施例中，它在該播放列表文件中只能出現(xiàn)一次。EXT-X-STREAM-INF標簽可用于指示播放列表文件中下一個URI標識另一個播放列表文件。在一實施例中該標簽格式可以為EXT-X-STREAM-INF:[attribute=value][, attribute=value]*〈URI>其中可使用如下屬性。在該標簽的一個實施例中，相同類型的屬性在相同標簽中不應當出現(xiàn)超過一次。屬性BANDWIDTH=〈n>為以每秒比特數表示的流比特率的近似上限。在一實施例中，屬性BANDWIDTH可以是每一個媒體文件的總比特率的上限，其被計算以包括出現(xiàn)或將要出現(xiàn)在播放列表中的容器(container)開銷。屬性PROGRAM_ID=〈i>為在播放列表文件范圍內唯一標識一特定呈現(xiàn)的數字。播放列表文件可包含具有相同PROGRAM-ID的多個EXT-X-STREAM-INF URI以描述相同呈現(xiàn)的不同流，并且這些不同的播放列表可包含附加的EXT-X-STREAM-INF標簽。在本公開中將進一步描述不同流和不同播放列表(例如，參見圖9A-9D)。屬性CODECS=” [format] [, format] 可用于在播放列表文件中指定出現(xiàn)在媒體文件中的媒體樣本類型，其中每一種格式指定一種媒體樣本類型；在一實施例中，有效的格式標識符可以是由RFC 4281定義的ISO文件格式名稱空間中的那些。屬性RES0LUTI0N=<N>X<M>可指定流中的視頻分辨率，其中N為流中視頻的近似編碼水平分辨率，其能以像素數目來表示，M為近似編碼垂直分辨率。EXT-X-DISCONTINUITY標簽指示在該標簽后面的媒體文件與其之前的媒體文件之間的編碼間斷性?？筛淖兊奶卣鹘M為

文件格式 軌道的數目和類型 編碼參數 編碼序列·時間戳序列其格式為#EXT-X-DISC0NTINUITYEXT-X-VERSION標簽指示播放列表文件的兼容版本。在一實施例中，播放列表文件、其相關媒體以及其服務器都應當遵守描述由標簽值表示的協(xié)議版本的該文檔的最近版本的所有條款。其格式為#EXT-X-VERSI0N:<n>其中“η”為表示協(xié)議版本的整數。在一實施例中，播放列表文件不能包含超過一個的EXT-X-VERSI0N標簽。在一實施例中，不包含EXT-X-VERSI0N標簽的播放列表文件應當遵守該協(xié)議的版本I。在一實施例中，如果播放列表文件具有該標簽，那么它的取值應當是服務器、播放列表文件以及相關媒體文件都遵守的最低協(xié)議版本。服務器設備可使用前述標簽和屬性來組織、傳輸和處理表示原始媒體內容的媒體文件。客戶端設備使用該信息以按如下方式重新組合和呈現(xiàn)媒體文件為客戶端設備的用戶提供實時或準實時流體驗(例如，實況廣播如音樂或體育事件的瀏覽)。播放列表文件中每一個媒體文件URI都標識作為原始呈現(xiàn)(即，原始媒體內容)的一片段的媒體文件。在一實施例中，每一個媒體文件都被格式化為MPEG-2傳輸流、MPEG-2節(jié)目流或MPEG-2音頻基本流。格式可通過指定CODEC的方式被指定，并且播放列表可通過指定CODEC的方式來指定格式。在一實施例中，在一呈現(xiàn)中的所有媒體文件都具有相同格式；但是，在其他實施例中可支持多種格式。在一實施例中，傳輸流文件應當包括單獨的MPEG-2節(jié)目，并且在每個文件的開始應當有節(jié)目關聯(lián)表和節(jié)目映射表。包含視頻的文件應當具有至少一個密鑰幀和足以完整初始化視頻解碼器的信息。播放列表中的媒體文件必須是具有前一個序列號的媒體文件末尾的編碼流的延續(xù)，除非它是出現(xiàn)在播放列表文件中的第一個媒體文件，或者如果它是以EXT-X-DISCONTINUITY標簽引導的。客戶端應當準備通過選擇合理子集來處理特定類型(例如，音頻或視頻)的多個軌道。在一實施例中，客戶端應當忽略傳輸流內部其無法識別的私有流。用于媒體文件內部的流中的樣本以及在多個媒體文件中相應流之間的樣本的編碼參數應當保持一致。但是客戶端應當在遇到編碼變化時對其進行處理，例如通過縮放視頻內容以提供分辨率變化。圖2A是用于一個或多個服務器設備使用非流傳輸協(xié)議支持媒體內容的技術的實施例的流程圖。附圖2A的示例以HTTP方式提供；但是，能夠以類似方式使用其他非流傳輸協(xié)議。圖2A的示例以執(zhí)行某些任務的單獨服務器的方式提供。但是，可使用任何數量的服務器。例如，為客戶端設備提供媒體文件的服務器可以是與將內容分割成多個媒體文件的服務器不同的設備。服務器設備接收在操作200中提供的內容。內容可呈現(xiàn)實況音頻和/或視頻(例如，體育事件、實況新聞、網絡攝像機視頻源)。內容還可呈現(xiàn)預錄內容(例如，已經被記錄的 音樂會、培訓研討會等)。服務器可根據本領域已知的任何格式和協(xié)議接收內容，不論是否是流式的。在一實施例中，服務器以MPEG-2流的形式接收內容；但是，其他格式也能夠得到支持。然后在操作210中服務器臨時存儲至少部分內容。例如，內容或至少部分內容可被臨時存儲在存儲設備(例如，存儲區(qū)域網絡中的硬盤等)上或存儲器中?；蛘?，內容以通過存儲介質(例如，光盤、閃存驅動器)的方式接收，可將內容從該存儲介質傳送到存儲設備或存儲器。在一實施例中，服務器具有編碼器，必要時，該編碼器將內容轉換為一個或多個流(例如，MPEG-2)。該轉換可在不永久存儲所接收的內容的情況下發(fā)生，并且在一些實施例中，存儲操作210可以被省略，或者在其他實施例中其可以為長期存儲(例如，檔案存儲)。在操作220中要被提供的內容被分割成多個媒體文件。在一實施例中，服務器將數據流轉換為可使用標準網絡服務器對其進行發(fā)布的單獨的不同的媒體文件(也即，片段)。在一實施例中，服務器在支持對各個多個媒體文件的有效解碼的點(例如，在分組和密鑰幀的邊界處，如PES分組邊界和i幀邊界)處對媒體流進行分割。媒體文件可以是具有近似相等持續(xù)時間的原始數據流的部分。服務器還為每一個媒體文件創(chuàng)建URI。這些URI允許客戶端設備訪問媒體文件。由于利用HTTP服務器為分段提供服務，其內在地傳遞整個文件，因此服務器應當具有在服務于客戶端之前就可用的完整的分割的媒體文件。因此，客戶端可落后(在時間上)該廣播至少一個媒體文件的長度。在一實施例中，媒體文件大小基于落后時間和具有過多文件之間的平衡。在一實施例中，支持兩種會話類型(實況會話和事件會話)。對于實況會話來說，僅保留流中固定大小的部分。在一實施例中，過期的內容媒體文件從節(jié)目播放列表文件中被移除，并且可以從服務器中被移除。第二種會話類型為事件會話，其中客戶端可轉到廣播的任何位置(例如，從開頭開始、從中間點開始)。例如，這種會話類型可用于轉播。在操作230中媒體文件被存儲到服務器存儲器。在操作230存儲文件之前，可通過安全特性保護媒體文件，例如加密。媒體文件作為準備傳輸的文件被存儲，使用由服務器設備上的網絡服務器應用支持的(或由執(zhí)行傳輸的另一設備支持的)網絡協(xié)議(例如，HTTP或HTTPS)進行傳輸。在操作240中生成一個或多個播放列表文件以指示應當重組媒體文件以再現(xiàn)原始內容的順序。播放列表文件可使用擴展M3U標簽和這里所描述的標簽來為客戶端設備提供信息，從而訪問和重組媒體文件以在客戶端設備上提供流體驗。每個媒體文件的URI都以播放媒體文件的順序被包括在(多個)播放列表文件中。服務器還可以為(多個)播放列表文件創(chuàng)建一個或多個URI以允許客戶端設備訪問(多個)播放列表文件。在操作250中(多個)播放列表文件可被存儲在服務器上。雖然媒體文件和(多個)播放列表文件的創(chuàng)建和存儲是以圖2A中的特定順序表示的，但也可以使用不同的順序。例如，(多個)播放列表文件可在媒體文件被創(chuàng)建或存儲之前被創(chuàng)建。作為另一個示例，(多個)
播放列表文件和媒體文件可在其中一個被存儲之前被創(chuàng)建。如果媒體文件要被加密，(多個)播放列表文件可定義一 URI，以允許授權客戶端設備獲取包含加密密鑰的密鑰文件以對媒體文件進行解密?？墒褂冒踩B接(例如，HTTPS)傳輸加密密鑰。作為另一個示例，可使用HTTPS傳輸(多個)播放列表文件。作為另外的示例，以不可預期的順序排列媒體文件，使得客戶端在沒有(多個)播放列表文件的情況下無法再創(chuàng)建流。如果加密方法為AES-128，例如AES-128CBC加密可應用于各個媒體文件。在一實施例中，整個文件都被加密。在一實施例中通常不橫跨媒體文件而應用密碼塊鏈。媒體文件的序號可用作IV，或者IV可以是如前面描述的EXT-X-KEY標簽的IV屬性的值。在一實施例中，服務器將具有密鑰URI的EXT-X-KEY標簽添加到播放列表文件的末尾。然后服務使用該密鑰對其后的所有媒體文件進行加密，直到加密配置發(fā)生改變。為了切換到新的加密密鑰，服務器可通過新的URI來使新密鑰可用，新的URI與呈現(xiàn)中所使用的所有之前的密鑰URI不同。服務器還將帶有新密鑰URI的EXT-X-KEY標簽添加到播放列表文件的末尾，并使用該新密鑰對其后所有媒體文件進行加密。為了結束加密，服務器可將帶有加密方法為NONE的EXT-X-KEY標簽添加到播放列表文件的末尾。在一實施例中標簽(以“NONE”作為該方法)不包括URI參數。對其后所有媒體文件都不進行加密，直到如前面描述的加密配置發(fā)生改變。如果播放列表文件包含用于以該密鑰加密的媒體文件的URI，那么服務器不將EXT-X-KEY標簽從該播放列表文件中移除。在操作270中，響應于客戶端請求，服務器可在網絡中傳輸(多個)播放列表文件和媒體文件，如關于圖3A所作的更為詳細的描述。在一實施例中，響應于來自于客戶端設備的對播放列表文件請求的接收，服務器將播放列表文件傳輸到客戶端設備?？蛻舳嗽O備可使用已經提供給客戶端設備的URI訪問/請求播放列表文件。URI表示播放列表文件在服務器上的位置。在響應中，服務器為客戶端設備提供播放列表文件?？蛻舳嗽O備可使用播放列表文件中的標簽和URI (或其他標識符)來訪問多個媒體文件。在一實施例中，服務器可將媒體文件的可用性限制到那些最近被添加到(多個)播放列表文件中的那些。為此，每個播放列表文件都僅包括一個EXT-X-MEDI A-SEQUENCE標簽，并且針對每一個從播放列表文件中移除的媒體文件URI，其值可以增加I。媒體文件URI以它們被添加的順序從(多個)播放列表文件移除。在一實施例中，當服務器將媒體文件URI從(多個)播放列表文件中移除時，媒體文件對客戶端保持可用一段時間，該時間等于媒體文件的持續(xù)時間加上媒體文件出現(xiàn)的播放列表文件的最長持續(xù)時間。播放列表文件的持續(xù)時間為該播放列表文件內媒體文件的持續(xù)時間的總和。也可使用其他持續(xù)時間。在一實施例中，服務器可始終保持播放列表中的至少三個主呈現(xiàn)媒體文件，除非出現(xiàn)EXT-X-ENDLIST標簽。圖2B是用于一個或多個服務器設備為一個或多個客戶端設備提供動態(tài)更新播放列表的技術的一實施例的流程圖?？衫眠@里所描述的累積模式或滾動模式的任何一個來更新播放列表。圖2B中的示例是以HTTP的方式提供的；但是，也可以以類似方式使用其他非流傳輸協(xié)議(例如，HTTPS等)。圖2B中的示例是以執(zhí)行某些任務的服務器的方式提供的。但是，可使用任何數量的服務器。例如，為客戶端設備提供媒體文件的服務器可以是不同于將內容分割為多個媒體文件的服務器的設備。在操作205，服務器設備接收要被提供的內容。然后在操作215，服務器可臨時存儲至少部分內容。操作215可與圖2A中的操作210相類似。在操作225，要被提供的內容 被分割成多個媒體文件。在操作235，媒體文件被存儲于服務器存儲器中。在操作235，在存儲媒體文件之前可通過例如加密的安全特性來保護這些媒體文件。在操作245，生成一個或多個播放列表文件以指示媒體文件進行重組以再創(chuàng)建原始內容的順序。在操作255，(多個)播放列表文件被存儲于服務器。雖然媒體文件和(多個)播放列表文件的創(chuàng)建和存儲以圖2B中的特定順序出現(xiàn)，但也可以使用不同順序。在操作275，響應于客戶端請求，服務器(或另一個服務器)可在網絡中傳輸(多個)播放列表文件和媒體文件，如關于圖3A-3B的更為詳細地描述。服務器可基于各種理由更新(多個)播放列表文件。在操作285，服務器可接收要被提供給客戶端設備的附加數據。在操作255中存儲(多個)播放列表文件之后，接收附加數據。例如，附加數據可以是實況呈現(xiàn)的附加部分或已有呈現(xiàn)的附加信息。附加數據可包括廣告或統(tǒng)計資料(例如，有關體育事件的成績或數據)?？梢栽诔尸F(xiàn)上(通過半透明物)覆蓋附加數據，或在側欄用戶界面中呈現(xiàn)附加數據。可以以與原始接收的數據相同的方式對附加數據進行分割。如果附加數據構成廣告或其他要被插入到由播放列表表示的節(jié)目中去的內容，那么在操作215 (至少暫時)存儲附加數據，在操作225分割附加數據，并在操作235存儲附加數據；在對分割的附加數據進行存儲之前，可對附加數據的分段進行加密。然后在操作245，生成包含節(jié)目和附加數據的更新播放列表。在操作255，基于附加數據更新播放列表并再次進行存儲。應當從客戶端設備的角度原子地對播放列表文件進行改變。在一實施例中，以更新的播放列表替換之前的播放列表。如下文將更詳細地討論的，客戶端設備可多次請求播放列表。這些請求使得客戶端設備能夠使用最新的播放列表。在一實施例中，附加數據可以是元數據；在這種情況下，不需要更新播放列表，但是可以更新其分段以包含元數據。例如，元數據可包含與分段中的時間戳相匹配的時間戳，并且元數據可被添加到具有匹配的時間戳的分段中。更新的播放列表還可導致媒體文件的移除。在一實施例中，服務器應當以其被添加到播放列表的順序從播放列表中移除媒體文件的URI。在一實施例中，如果服務器移除整個呈現(xiàn)，就會使得(多個)播放列表文件對客戶端設備不可用。在一實施例中，服務器在最長(多個)播放列表文件的持續(xù)時間內維持媒體文件和播放列表文件，以允許當前客戶端設備完成對呈現(xiàn)的訪問，該最長(多個)播放列表文件包含要被移除的媒體文件。因此，可對播放列表文件中的每個媒體文件URI添加EXT-X-STREAM-INF標簽作為前綴，以表示由播放列表文件指示的媒體文件的近似累積持續(xù)時間。在替代實施例中，可立即移除媒體文件和(多個)播放列表文件。在操作275，來自客戶端設備的對播放列表的隨后請求使得服務器提供更新的播放列表。在一實施例中，定期更新播放列表，例如，按與目標持續(xù)時間有關的時間周期。播放列表文件的周期更新允許服務器為動態(tài)變化的呈現(xiàn)提供對服務器的訪問。圖2C是用于一個或多個服務器設備使用多比特率為客戶端設備提供媒體內容的技術的一實施例的流程圖，其為替代流的一種使用形式。圖2C中的示例是以HTTP的方式提供的；但是，也可以以類似方式使用其他非流傳輸協(xié)議。圖2C中的示例是以執(zhí)行某些任務的服務器的方式提供的。但是，可使用任何數量的服務器。例如，為客戶端設備提供媒體文件的服務器可以是不同于將內容分割為多個媒體文件的服務器的設備。在一實施例中，服務器可提供多個播放列表文件或具有在單一播放列表文件中列出的多個媒體文件的單一播放列表文件，以提供相同呈現(xiàn)的不同編碼。如果提供不同編碼，(多個)播放列表文件可包括每一個提供不同比特率的變型流，以允許客戶端設備在編碼之間動態(tài)切換(將結合圖9A-9D對其作進一步描述)。具有變型流的播放列表文件包括用于每一個變型流的EXT-X-STREAM-INF標簽。相同呈現(xiàn)的每一個EXT-X-STREAM-INF標簽都可以具有相同的PR0GRAM-ID屬性值。每個呈現(xiàn)的PR0GRAM-ID值在變型流中是唯一的。在一實施例中，服務器在產生變型流時會遇到如下限制。每個變型流可以由包含不屬于主要呈現(xiàn)的一部分的可選內容的相同內容組成。服務器可在流的最小目標持續(xù)時間的準確度內使相同的內容時段對所有變型流都可用。在一實施例中，變型流的媒體文件為具有與所有變型流中的相應內容相匹配的采樣時間戳的MPEG-2傳輸流或MPEG-2節(jié)目流中的任何一個。并且，在一實施例中，所有變型流都應當包含相同音頻編碼。這就允許客戶端設備在變型流之間進行切換而不丟失內容。參考圖2C，在操作202，服務器設備接收要被提供的內容。然后，在操作212，服務器至少對內容進行臨時存儲。在操作222，要被提供的內容被分割為多個媒體文件。在操作232，利用選擇的比特率(或其他編碼參數的選擇值)對每個媒體文件進行編碼，并將其存儲到服務器。例如，媒體文件可以高帶寬、中帶寬和低帶寬連接為目標?？稍诖鎯χ皩γ襟w文件進行加密?？蛇x擇以不同連接類型為目標的媒體文件的編碼，以在目標帶寬級上提供流體驗。在一實施例中，在操作242，生成具有這里所描述的指示不同編碼等級的標簽的變體播放列表。例如，該標簽可包括用于每個編碼等級的具有相應媒體播放列表文件的URI的 EXT-X-STREAM-INF 標簽。該變體播放列表可包括用于不同編碼等級的媒體播放列表文件的URI。因此，客戶端設備可從指示編碼等級的變體播放列表中提供的選項中選擇目標比特率，并獲取相應播放列表文件。在一實施例中，客戶端設備在重放過程中可在比特率之間變化(例如，有關圖9A-9D所描述的)。在操作252，將表示不同編碼等級的變體播放列表存儲到服務器。在操作242，還生成在變體播放列表中涉及的每個播放列表，然后在操作252中對其進行存儲。在操作272，響應于來自客戶端設備的請求，服務器傳輸表示不同編碼等級的變體播放列表。在操作282，服務器接收對變體播放列表中指定的與選擇的比特率相對應的媒體播放列表中的一個的請求。在操作292，響應于該請求，服務器傳輸與來自客戶端設備的請求對應的媒體播放列表文件。然后客戶端設備可以使用媒體播放列表從服務器請求媒體文件。在操作297，服務器響應于請求而為客戶端設備提供媒體文件。圖3A是用于客戶端設備使用非流傳輸協(xié)議支持內容流的技術的一實施例的流程圖。圖3A中的示例是以HTTP的方式提供的；但是，也可以以類似方式使用其他非流傳輸協(xié)議。圖3A-3B中所示的方法可由一個客戶端設備或由多個獨立的客戶端設備來執(zhí)行。例如，在這些方法的任何一種的情況下，單獨的客戶 端設備執(zhí)行所有操作(例如，請求播放列表文件、使用播放列表文件中的URI請求媒體文件、組合媒體文件以生成和提供呈現(xiàn)/輸出)，或者多個不同的客戶端設備執(zhí)行其中一些但不是全部的操作(例如，第一客戶端設備請求播放列表文件和使用播放列表文件中的URI請求媒體文件，并存儲那些媒體文件以供第二客戶端設備使用，第二客戶端設備處理媒體文件以生成和提供呈現(xiàn)/輸出)。在操作300，客戶端設備可從服務器請求播放列表文件。在一實施例中，根據符合HTTP的協(xié)議作出該請求。該請求利用存儲在服務器上的初始的播放列表文件的URI。在替代實施例中，支持其他非流傳輸協(xié)議。響應于該請求，服務器將在網絡中將相應播放列表文件傳輸到客戶端。如上文所討論的，網絡可以是有線的或者無線的，并且可以是有線或無線網絡的任何組合。另外，網絡可以是數據網絡(例如，IEEE 802. IUIEEE 802. 16)或蜂窩電話網絡(例如，3G)。在操作310，客戶端設備接收播放列表文件。在操作320，將播放列表文件存儲在客戶端設備的存儲器中。例如，存儲器可以是硬盤、閃速存儲器、隨機訪問存儲器。在一實施例中，每次從播放列表URI中加載或重新加載播放列表文件時，客戶端都對其進行檢查以確定播放列表文件以#EXTM3U標簽開頭，如果不出現(xiàn)該標簽的話就不再繼續(xù)。正如上文所討論的，播放列表文件包括一個或多個標簽，以及一個或多個到媒體文件的URI。在操作330，客戶端設備包括組合器代理，其使用播放列表文件以通過請求由播放列表文件中的URI所指示的媒體文件重組原始內容。在一實施例中，組合器代理是作為標準網絡瀏覽器應用的一部分的插件模塊。在另一個實施例中，組合器代理可以是與網絡瀏覽器進行交互以接收(多個)播放列表文件并使用(多個)播放列表文件組合媒體文件的獨立應用。作為進一步示例，組合器代理可以是嵌入到客戶端設備中的專用硬件或固件組件。組合器使得來自播放列表文件的媒體文件從由URI指示的服務器下載。如果播放列表文件包含EXT-X-ENDLIST標簽，任何由播放列表文件指示的媒體文件都可被最先播放。如果EXT-X-ENDLIST標簽不出現(xiàn)，除了最后一個和倒數第二個媒體文件以外的任何媒體文件都可以被最先播放。在一實施例中，一旦選擇了最先播放的媒體文件，則以其在播放列表文件中出現(xiàn)的順序下載播放列表文件中后續(xù)的媒體文件(除非內容是無序呈現(xiàn)的)。在一實施例中，客戶端設備試圖在需要媒體文件之前裝載媒體文件(并將其存儲在緩存中)，以提供不間斷的重放，并彌補網絡延遲和吞吐量的臨時變化。在操作340，可將下載的(多個)媒體文件存儲在客戶端設備的存儲器中?？纱鎯热莸拇鎯ζ骺梢允强蛻舳嗽O備上的任何類型的存儲器，例如，隨機訪問存儲器、硬盤、或視頻緩沖區(qū)。存儲可以是臨時的以允許重放，也可以是永久的。如果播放列表文件包含EXT-X-ALLOff-CACHE標簽并且其值為NO，那么在下載的媒體文件播放過之后，客戶端不對其進行存儲。如果播放列表包含EXT-X-ALLOW-CACHE標簽并且其值為YES，那么客戶端設備無期限地存儲媒體文件以用于以后的重播?？蛻舳嗽O備可使用ext-x-program-date-hme標簽的值以向用戶顯示節(jié)目的開始時間。在一實施例中，客戶端可緩存多個媒體文件使其不那么容易受網絡抖動的影響，以提供更好的用戶體驗。在一實施例中，如果解密方法為AES-128，那么在各個媒體文件中應用AES-128CBC解密。對整個文件進行解密。在一實施例中，不跨過媒體文件使用密碼塊鏈接?？墒褂妹襟w文件的序號作為上文所描述的初始化向量。在操作350，從客戶端設備的存儲器中輸出內容。例如，輸出或呈現(xiàn)可以是通過內置揚聲器或耳機輸出的音頻。輸出內容可包括通過屏幕輸出的或從客戶端設備投射的視頻。可使用本領域已知的任何類型的輸出。在操作351，客戶端設備確定在存儲的當前播放列表中是否還有媒體文件沒有被播放或呈現(xiàn)。如果存在這樣的媒體文件(并且，如果它們還沒有被請求)，那么處理返回到操作330，在那里請求一個或多個媒體文件并且處理重復。如果沒有這樣的媒體文件(也即，當前播放列表中的所有媒體文件都已經被播放)，那么處
理繼續(xù)進行到操作352，確定播放列表文件是否包含結束標記。在操作352，如果播放列表包含結束標記(例如，EXT-X-ENDLIST)，那么當由播放列表文件指示的媒體文件已經被播放時終止重放。如果播放列表中沒有結束標記，那么客戶端設備再次從服務器請求播放列表，并恢復到操作300以獲得節(jié)目的進一步的或更新的播放列表。正如圖2B中更為詳細地討論的，服務器可更新播放列表文件以引入補充內容(例如，與實況廣播中的附加媒體內容相對應的附加媒體文件標識符)或附加內容(例如，數據流更下方的內容)。為了訪問補充內容或附加內容，客戶端從服務器重新加載更新的播放列表。這能提供一種可動態(tài)更新播放列表文件的機制，即使在重放與播放列表文件相關的媒體內容的過程中?？蛻舳丝苫诖罅坑|發(fā)器請求播放列表文件的重新加載。缺少結束標記就是一個這樣的觸發(fā)器。在一實施例中，客戶端設備周期性地重新加載(多個)播放列表文件，除非播放列表文件包含EXT-X-ENDLIST標簽。當客戶端設備第一次加載播放列表文件或重新加載播放列表文件，并發(fā)現(xiàn)播放列表文件自最后一次加載以后已經發(fā)生變化，客戶端可在再次嘗試重新加載播放列表文件之前等待一段時間。這段時間被稱作最初的最低重新加載延時。從客戶端開始裝載播放列表文件的時間開始測量這段時間。在一實施例中，最初的最低重新加載延時為播放列表文件中最后一個媒體文件的持續(xù)時間，或目標持續(xù)時間的三倍，取較小值。由EXTINF標簽指定媒體文件持續(xù)時間。如果客戶端重新加載播放列表文件并發(fā)現(xiàn)它沒有發(fā)生變化，那么客戶端可以在重試之前等待一段時間。在一實施例中，最小延時為目標持續(xù)時間的三倍，或者為最初的最低重新加載延時的倍數，取較小值。在一實施例中，該倍數在第一次嘗試時為O. 5，第二次嘗試時為I. 5，之后的嘗試時為3. O ;但也可以使用其他倍數。每次加載或重新加載播放列表文件，客戶端設備都檢查播放列表文件以確定下一個要加載的媒體文件。第一個要加載的文件為上文所描述的被選擇以最先播放的媒體文件。如果已經加載了要被播放的第一個媒體文件并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE標簽，那么客戶端可檢驗當前播放列表文件在其最初被發(fā)現(xiàn)的偏移位置處包含最后加載的媒體文件的URI，如果沒有發(fā)現(xiàn)該文件則暫停重放。下一個要加載的媒體文件可以是播放列表文件中最后加載的URI之后的第一個媒體文件URI。如果已經加載了要被播放的第一個媒體文件并且播放列表文件包含EXT-X-MEDIA-SEQUENCE標簽，那么下一個要加載的媒體文件可以是具有大于最后加載的媒體文件的序號的最小序號的媒體文件。如果播放列表文件包含指定密鑰文件URI的EXT-X-KEY標簽，客戶端設備獲取密鑰文件并使用密鑰文件中的密鑰來對EXT-X-KEY標簽之后的媒體文件進行解密，直到遇到另一個EXT-X-KEY標簽。在一實施例中，客戶端設備使用與之前用過的相同的URI來下載播放列表文件。因此，如果播放列表文件發(fā)生了變化，客戶端設備可使用更新的播放列表文件來重新獲得媒體文件并基于該媒體文件提供輸出。播放列表文件的變化可包括，例如，媒體文件的URI的刪除、新的媒體文件的URI的增加、替換媒體文件URI的替換。當播放列表文件發(fā)生變化時，可更新一個或多個標簽以 反映(多個)變化。例如，如果媒體文件的變化導致由播放列表文件指示的媒體文件的重放的持續(xù)時間發(fā)生變化，可對持續(xù)時間標簽進行更新。圖3B是用于客戶端設備使用作為一種替代流形式來支持多比特率內容流的技術的一實施例的流程圖。圖3B中的示例是以HTTP的方式提供的；但是，也可以以類似方式使用其他非流傳輸協(xié)議。在操作370，客戶端設備請求播放列表文件。如上文所討論的，可利用提供給客戶端設備的URI重新獲取播放列表文件。在一實施例中，播放列表文件包括媒體文件的變型流清單，從而以不同比特率提供相同內容；也就是說，單個播放列表文件包括用于每個變型流的媒體文件的URI。圖3B中示出的示例使用該實施例。在另一個實施例中，變型流可由分別提供給客戶端的多個不同播放列表文件來表示，其中每一個播放列表文件都以不同比特率提供相同內容，并且變體播放列表可為每一個不同的播放列表文件提供一個URI。這就允許客戶端設備基于客戶條件選擇比特率。在操作375，客戶端設備重新獲取(多個)播放列表文件。在操作380，將(多個)播放列表文件存儲在客戶端設備存儲器中?？蛻舳嗽O備可基于當前網絡連接速度選擇要用于操作385中的比特率。在操作390，使用包含在與選擇的比特率相對應的播放列表文件中的URI從服務器請求媒體文件?？蓪⒅匦芦@取的媒體文件存儲在客戶端設備存儲器中。在操作394，客戶端設備使用媒體文件提供輸出，并且客戶端設備確定是否改變比特率。在一實施例中，客戶端設備最初選擇最低可用比特率。當播放媒體時，客戶端設備監(jiān)視可用帶寬(例如，當前網絡連接比特率)以確定可用帶寬是否可支持重放使用更高比特率。如果是，客戶端設備選擇更高比特率并訪問由更高比特率媒體播放列表文件指示的媒體文件。反過來也可以支持。如果重放消耗過多帶寬，客戶端設備可選擇更低比特率并訪問由更低比特率媒體播放列表文件指示的媒體文件。在操作394，如果客戶端設備改變比特率，例如響應于可用帶寬的變化或響應于用戶輸入，那么在操作385，客戶端設備可選擇不同的比特率。在一實施例中，為了選擇不同的比特率，客戶端設備可使用與新選擇的比特率相對應的播放列表文件中包含的不同URI列表。在一實施例中，客戶端設備可在訪問播放列表中的媒體文件的過程中改變比特率。在操作394，如果比特率沒有變化，那么客戶端設備確定在當前播放列表中是否還有沒有播放的媒體文件沒有被重新獲取并呈現(xiàn)。如果存在這樣的媒體文件，那么處理返回到操作390并且使用播放列表中用于那些文件的URI重新獲取一個或多個媒體文件。如果沒有這樣的媒體文件(也即，當前播放列表中所有媒體文件都已經播放)，那么處理繼續(xù)進行到操作396以確定播放列表是否包含結束標記。如果是，節(jié)目的重放結束并且處理完成；如果否，那么處理轉到操作370，客戶端設備請求重新加載節(jié)目播放列表，并且以圖3B中所示的方法該過程重復進行。圖4是服務器流代理的一實施例的框圖?？梢岳斫獾氖?，可以在多個服務器設備中分布服務器流代理400的組件。例如，第一服務器設備包括分割器430、索引器440和安全組件450但不包括文件服務器460，第二服務器設備包括文件服務器460但不包括分割器430、索引器440和安全組件450。在該不例中，第一服務器設備準備播放列表和媒體文件但不將其傳輸到客戶端設備，而一個或多個第二服務器設備接收和可選地存儲播放列表和媒
體文件并將播放列表和媒體文件傳輸到客戶端設備。服務器流代理400包括實現(xiàn)邏輯功能控制以指導服務器流代理400的操作的控制邏輯410，以及與指導服務器流代理400操作有關的硬件。邏輯可以是硬件邏輯電路或軟件例程或固件。在一實施例中，服務器流代理400包括一個或多個應用412，其表示為了控制邏輯410而提供指令的代碼序列和/或程序。服務器流代理400包括存儲器414，其表示存儲器設備或對用于存儲數據或指令的存儲器資源的訪問通道。存儲器414可包括服務器流代理400本地的存儲器，以及，或作為選擇，包括服務器流代理400駐留的主機系統(tǒng)的存儲器。服務器流代理400還包括一個或多個接口 416，表示同服務器流代理400的外部實體(電子的或人類的)有關的到服務器流代理400/從服務器流代理400的訪問接口(輸入/輸出接口)。服務器流代理400還包括服務器流弓I擎420，表示能夠使得服務器流代理400提供這里所描述的實時或準實時流的一個或多個功能。圖4的示例提供了服務器流引擎420中可包括的多個組件；但是，也可以包括不同的或附加的組件。可被包含以提供流環(huán)境的示例性組件包括分割器430、索引器440、安全組件450和文件服務器460。這些組件中的每一個可進一步包括其他組件以提供其他功能。這里所使用的組件涉及例程、子系統(tǒng)等，不論是以硬件、軟件、固件或是其某些組合來實現(xiàn)的。分割器430把將被提供的內容分割成可作為文件使用網絡服務器協(xié)議(例如，HTTP)進行傳輸的媒體文件。例如，分割器430可將內容分割成以預先確定的文件格式表示的預先確定的、固定大小的數據塊。索引器440可提供一個或多個播放列表文件，其提供由分割器430創(chuàng)建的媒體文件的地址或URI。例如，索引器440創(chuàng)建一個或多個文件，該文件具有與分割器430所創(chuàng)建的每個文件相對應的標識符的順序列表?？赏ㄟ^分割器430或索引器440中的任何一個來創(chuàng)建或指派標識符。索引器440還包括在播放列表文件中的一個或多個標簽以支持媒體文件的訪問和/或使用。安全組件450可提供如上文所討論的那些安全特性(例如，加密)。網絡服務器460可提供涉及將存儲在主機系統(tǒng)上的文件提供給遠程客戶端設備的網絡服務器功能。例如，網絡服務器460可支持符合HTTP的協(xié)議。圖5是客戶端流代理的一實施例的框圖?？梢岳斫獾氖牵梢钥邕^多個客戶端設備而分布客戶端流代理的組件。例如，第一客戶端設備包括組合器530和安全組件550，并為第二客戶端設備提供媒體文件的解密流，第二客戶端設備包括輸出生成器540(但不包括組合器530和安全組件550)。在另一個示例中，主要客戶端設備可重新獲取播放列表并將其提供給第二客戶端設備，第二客戶端設備重新獲取播放列表中指定的媒體文件并產生輸出以呈現(xiàn)這些媒體文件。客戶端流代理500包括執(zhí)行指導客戶端流代理500操作的邏輯功能控制的控制邏輯510，以及與指導客戶端流代理500操作有關的硬件。邏輯可以是硬件邏輯電路或軟件例程或固件。在一實施例中，客戶端流代理500包括一個或多個應用512，其表示為控制邏輯510提供指令的代碼序列或程序。客戶端流代理500包括存儲器514，其表示存儲器設備或到用于存儲數據和/或指令的存儲器資源的訪問通道。存儲器514可包括客戶端流代理500本地的存儲器，以及，或作為選擇，包括客戶端流代理500所駐留的主機系統(tǒng)的存儲器。客戶端流代理500還包括一個或多個接口 516，表示同客戶端流代理500的外部實體(電子的或人類的)相關的到客戶端流代理500/從客戶端流代理500的訪問接口(輸入/輸出接口)。 客戶端流代理500還包括客戶端流引擎520，表示能夠使得客戶端流代理500提供 這里所描述的實時或準實時流的一個或多個功能。圖5的示例提供了客戶端流引擎520中可包括的多個組件；但是，也可以包括不同的或附加的組件?？杀话蕴峁┝鳝h(huán)境的示例性組件包括組合器530、輸出生成器540和安全組件550。這些組件中的每一個可進一步包括其他組件以提供其他功能。這里所使用的組件涉及例程、子系統(tǒng)等，不論是以硬件、軟件、固件或是其某些組合來實現(xiàn)的。組合器530可使用從服務器接收的播放列表文件通過網絡服務器協(xié)議(例如，HTTP)從服務器訪問媒體文件。在一實施例中，組合器530可導致由播放列表文件中的URI所指示的媒體文件被下載。組合器530可對包含在播放列表文件中的標簽作出反應。輸出生成器540可在主機系統(tǒng)上提供作為音頻或可視輸出(或音頻和可視的兩者兼有)的所接收的媒體文件。例如，輸出生成器540可使得音頻被輸出到一個或多個揚聲器，并使得視頻被輸出到顯示設備。安全組件550可提供如上文所討論的那些安全特性。圖6不出帶有多標簽的播放列表文件的一實施例。圖6的不例性播放列表包含標簽的具體數量和順序。這僅僅是為了描述的目地提供的。一些播放列表文件可包含更多、更少或不同組合的標簽，并且可以以不同于圖6中所顯示的順序排列標簽。開始標簽610指示播放列表文件的開始。在一實施例中，開始標簽610S#EXTM3U標簽。持續(xù)時間標簽620指示重放列表的持續(xù)時間。也就是，由重放列表600指示的媒體文件的重放的持續(xù)時間。在一實施例中，持續(xù)時間標簽620為EXT-X-TARGETDURATION標簽；但是，也可使用其他標簽。日期/時間標簽625提供與由重放列表600指示的媒體文件所提供的內容的日期和時間有關的信息。在一實施例中，日期/時間標簽625為EXT-X-PROGRAM-DATE-HME標簽；但是，也可使用其他標簽。順序標簽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的順序與訪問和/或播放媒體文件的順序相對應。后續(xù)播放列表指示符660提供與在重放文件600之后要被使用的一個或多個重放文件相關的信息。在一實施例中，后續(xù)播放列表指不符660包含一個或多個播放列表文件的URI,該播放列表文件在播放列表600的媒體文件被播放之后要被使用。存儲器標簽670指示客戶端設備是 否能在媒體文件內容重放之后存儲媒體文件，和/或存儲媒體文件多長時間。在一實施例中，存儲器標簽670為EXT-X-ALLOW-CACHE標簽。結束標簽680指示播放列表文件600是否為供呈現(xiàn)的最后一個播放列表文件。在一實施例中，結束標簽680為EXT-X-ENDLIST標簽。下面的部分包含根據一個實施例的多個示例的播放列表文件。簡單播放列表文件#EXTM3U#EXT-X-TRAGEDURATION:10#EXTINF:5220,http://media, example, com/entire, ts#EXT-X-ENDLIST滑動窗口播放列表，使用HTTPS#EXTM3U#EXT-X-TRAGEDURATION: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:METH0D=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:METH0D=AES-128, URI=”https://priv. example, com/key. php r=53”#EXTINF:15,http://media. example, com/fileSequence7797.ts變體播放列表文件#EXTM3U#EXT-X-STREAM-INF:PR0GRAM-ID=1,BANDWIDTH=1280000 http://example, com/low. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1,BANDWIDTH=2560000http://example, com/mid. m3u8
#EXT-X-STREAM-INF:PR0GRAM_ID=1,BANDWIDTH=7680000http: //example, com/hi. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=I, BANDWIDTH=65000, CODECS=”mp4a. 40. 5”http://example, com/audio-only. m3u8圖7是這里描述的用于組合流的重放技術的一實施例的流程圖。在一實施例中，所接收的媒體文件的重放可由用戶控制以開始、停止、倒回等。在操作700，客戶端設備接收播放列表文件。在操作710，重新獲取由播放列表文件指示的媒體文件。在操作720，基于所接收的媒體文件產生輸出。基于媒體文件接收和產生輸出可如上所述實現(xiàn)。如果在操作730檢測到控制輸入，在操作740，客戶端設備確定該輸入是否指示停止。如果輸入為停止，則過程結束并且重放停止。在操作750如果輸入指示倒回或快進請求，則在操作760客戶端設備基于之前播放的仍然存儲在存儲器中的媒體文件產生輸出。如果這些文件已不在緩存中了，那么處理返回到操作710以重新獲取媒體文件并重復過程。在一替代實施例中，重放可支持暫停特性，其中止重放但不像停止輸入那樣結束重放。將參考圖9A-9D進一步描述從一個流到另一個流的轉換方法。一個客戶端設備可執(zhí)行這些方法中的每一個，或者，可如這里所描述的跨過多個客戶端設備而分布每個方法的操作；例如，在分布式的情況下，一個客戶端設備獲取變體播放列表和兩個媒體播放列表，并將其提供給另一個客戶端設備，該另一個客戶端設備重新獲取由兩個媒體播放列表指定的媒體文件并在由重新獲取的媒體文件所提供的兩個流之間切換。也可以認識到，在替代實施例中，可修改所顯示操作的順序，或者可以有比這些圖中所顯示的操作更多或更少的操作。這些方法可使用變體播放列表來選擇不同的流。在操作901，重新獲取和處理變體播放列表以確定可用于節(jié)目(例如，體育事件)的流。操作901可由客戶端設備完成。在操作903，從變體播放列表中選擇第一流，然后客戶端設備可重新獲取第一流的媒體播放列表。在操作905，客戶端設備處理第一流的媒體播放列表，并在操作907測量或確定用于第一流的網絡連接的比特率?？梢砸庾R到可以以不同于圖9A中所顯示的順序來執(zhí)行操作順序；例如，可以在操作903執(zhí)行過程中執(zhí)行操作907等。在操作911，客戶端設備基于來自操作907的測量比特率，從變體播放列表中選擇替代的媒體播放列表；該替代的媒體播放列表可以具有比第一流的現(xiàn)行比特率高的第二比特率。這通常意味著替代流將具有比第一流更高的分辨率。如果基于當前條件(例如，在操作907中測量的比特率)替代的媒體播放列表是比第一流的當前播放列表更好的匹配者，則選擇該替代的媒體播放列表。在操作913，重新獲取并處理替代流的替代媒體播放列表。這通常意味著客戶端設備可接收和處理第一流和替代流兩者，因而兩者對于呈現(xiàn)來說都是可用的；呈現(xiàn)一個并準備好呈現(xiàn)另一個。然后在操作915，客戶端設備選擇轉換點以在流的版本之間切換，停止呈現(xiàn)第一流并開始呈現(xiàn)替代流。與圖9B-9D—起共同提供如何完成該切換的示例。在一些實施例中，客戶端設備可在作出切換之前停止接收第一流。圖9B示出在操作921和923，客戶端設備重新獲取、存儲和呈現(xiàn)由第一媒體播放列表(例如，第一流)指定的內容，并且在操作925，當呈現(xiàn)由第一播放列表指定的內容時，客戶端設備還重新獲取和存儲由第二媒體播放列表(例如，第二流)指定的內容。當呈現(xiàn)從第一媒體播放列表獲得的內容時對由第二媒體播放列表指定的內容的重新獲取和存儲(例如，于臨時緩沖區(qū)中)造成節(jié)目內容在時間上的重疊955 (如圖9D中所示)，從而允許客戶端設備在節(jié)目的版本之間切換而不會對節(jié)目造成實質中斷。這樣，可以在多種情況下實現(xiàn)節(jié)目版本之間的切換，而不會使用戶察覺到切換的發(fā)生(雖然在某些情況下，在切換之后用戶會 注意到更高分辨率圖像)或者不會對節(jié)目的呈現(xiàn)造成實質中斷。在操作927，客戶端設備確定轉換點，在該轉換點從由第一媒體播放列表指定的內容切換到由第二媒體播放列表指定的內容；圖9D中顯示了轉換點的示例(轉換點959)。在切換之后，隨后在操作931呈現(xiàn)由第二媒體播放列表指定的內容。圖9C和9D中所示的方法表示用于確定轉換點的一個實施例；該實施例依賴對來自于兩個流951和953的音頻采樣的模式匹配來確定轉換點?？梢砸庾R到，替代實施例可使用對視頻采樣的模式匹配或使用在兩個流中的時間戳等來確定轉換點。方法包括，在操作941，將由第一媒體播放列表指定的內容(例如，流951)存儲于緩沖區(qū)中；緩沖區(qū)可被用于內容的呈現(xiàn)以及模式匹配操作。流951包括音頻采樣951A和視頻采樣951B。視頻采樣可使用依賴于包括顯示單個視頻幀所必需的所有內容的i幀或關鍵幀的壓縮技術。流951中的內容可包括指定時間的時間戳(例如，從節(jié)目開始時以來流逝的時間)，這些時間戳可標記每個采樣的開始(例如，每個音頻采樣95IA的開始以及每個視頻采樣95IB的開始)。在某些情況下，兩個流之間的時間戳的比較在確定轉換點時是沒有用的，因為它們不足夠精確或者由于兩個流中采樣邊界的不同；但是，時間戳范圍的比較可被用于驗證在兩個流之間存在時間上的重疊955。在操作943，客戶設備在緩沖區(qū)中存儲由第二媒體播放列表指定的內容；該內容與從第一媒體播放列表獲得的內容用于相同的節(jié)目，并且還可包括時間戳。在一實施例中，如果流中沒有出現(xiàn)時間戳，可將時間戳添加到流的播放列表；例如，在一實施例中，可將包括一個或多個時間戳的ID3標簽添加到如變體播放列表或媒體播放列表的播放列表的條目中。例如，條目可存在于用于音頻流的第一采樣的URI中。圖9D顯示從第二媒體播放列表獲得的內容953的示例，其包括音頻采樣953A和視頻采樣953B。在操作945，客戶端設備可對流951和953中的音頻采樣執(zhí)行模式匹配以從重疊部分955中選擇轉換點959，在一實施例中，該轉換點為匹配的音頻分段(例如，分段957)之后的下一個獨立(自包含的)視頻幀(例如，i幀961)。以i幀961 (以及其相關音頻采樣)開始，節(jié)目的呈現(xiàn)使用從第二媒體播放列表獲得的第二流。在一實施例中上述方法可用于從較慢比特率到較快高比特率的變化以及從較快比特率到較慢比特率的變化，但是，在另一實施例中，該方法僅可用于從較慢低比特率到較快高比特率的變化，而另一方法(例如，不嘗試定位轉換點，但嘗試盡快存儲和呈現(xiàn)來自較慢比特率流的內容)可用于從較快高比特率到較慢比特率的變化。圖10是用于提供利用替代流來為客戶端設備提供播放列表或媒體內容或其二者的多個冗余位置的技術的一實施例的流程圖。如 果播放列表包含上文討論的替代流，則替代流不僅僅作為帶寬替代或設備替代來操作，還作為失敗回退(fallback)。例如,如果客戶端不能重新加載流的播放列表文件(例如，由于404錯誤或網絡連接錯誤)，客戶端可嘗試切換到替換流。參考圖10，如同結合圖2C的說明所討論的，在操作1002，為了實現(xiàn)故障備援(failover)保護，第一服務器設備或第一內容分發(fā)服務被配置為創(chuàng)建一個流或多個替代帶寬流。在操作1004，第一服務器設備或第一內容分發(fā)服務從操作1002中生成的(多個)流中生成(多個)播放列表文件。在操作1006，第二服務器設備或第二內容分發(fā)服務創(chuàng)建平行流或流集合，并創(chuàng)建播放列表。這些(多個)平行流可被視作備份流。接著，在操作1008，將備份流列表添加到(多個)播放列表文件，以便每個帶寬的(多個)備份流被列在主要流之后。例如，如果主要流來自于服務器ALPHA，備份流在服務器BETA，那么播放列表文件可以如下表不:#EXTM3U#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=200000http://ALPHA, mycompany. com/low/prog_index. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=200000http://BETA, mycompany. com/low/prog_index. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=500000http://ALPHA, mycompany. com/mid/prog_index. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=500000http://BETA, mycompany. com/mid/prog_index. m3u8注意到，備份流與播放列表中的主要流相混合，其中每個帶寬上的備份被列在該帶寬的主要流之后。客戶端并不局限于單一備份流組合。在上述示例中，例如ALPHA和BETA繼之以GAMMA。類似地，提供完整的平行流組合并不是必要的。例如，可在備份服務器上提供單一低帶寬流。在操作1010，客戶端嘗試使用與第一服務器設備或第一內容分發(fā)服務相關的第一流從第一 URL下載(多個)播放列表文件。圖11不出根據一個實施例的客戶端1102與一個或多個URL、服務器設備或內容分發(fā)服務進行雙向通信的網絡。在操作1012，將(多個)播放列表文件從第一 URL、服務器設備或內容分發(fā)服務傳輸到客戶端1102。如果客戶端不能夠從第一 URL、服務器設備或內容分發(fā)服務下載(多個)播放列表文件(例如，由于重新加載流索引文件中出現(xiàn)錯誤)，客戶端嘗試切換到替代流。在一個流上的故障(例如，索引裝載故障)事件中(例如，操作1010 )，在操作1014，客戶端選擇網絡連接支持的最高帶寬替代流。如果存在具有相同帶寬的多個替代，客戶端以播放列表中所列的順序在它們之間進行選擇。例如，如果客戶端1102不能從URL I成功下載，可從URL 2或另一個URL下載，在這種情況下，將(多個)播放列表文件從替代URL傳輸到客戶端。這一特性提供冗余流以允許媒體到達客戶端，即使在嚴重的本地故障事件中，如服務器崩潰或內容分發(fā)節(jié)點停機。故障備援保護具備提供多個冗余位置的能力，客戶端可從這些位置重新獲取播放列表和媒體文件。因此，如果客戶端不能從第一位置重新獲取流，它可以嘗試從第二、第三等位置訪問流。在一實施例中，為了指示客戶端可重新獲取播放列表的附加位置，可提供具有相同帶寬、但新的冗余位置的URI的相同變體播放列表標簽?？蛻舳俗畛蹩蓢L試訪問與所需帶寬相關的第一 URL。如果不能從第一 URL下載播放列表，則其可嘗試訪問呈現(xiàn)給該帶寬的下一個URL等等，直到其窮盡了所有可能性。下面的示例包括用于2560000帶寬的I個冗余位置以及用于7680000帶寬的2個冗余位置。#EXTM3U #EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=1280000http://example, com/low. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=2560000http://example, com/mid. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=2560000http://examplel. com/mid-redundant2. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=7680000http: //example, com/hi. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=7680000http://exampIe2. com/hi-redudant2. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=1, BANDWIDTH=7680000http://exampIe3. com/hi-redudant3. m3u8#EXT-X-STREAM-INF:PR0GRAM-ID=I, 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://examp I e3. com/〉)二者都發(fā)生變化。但是，在一實施例中，冗余位置可以是僅對文件名或僅對網站的變化。在一實施例中，服務器設備可對播放列表進行壓縮并將其以壓縮形式發(fā)送到客戶端設備。壓縮的播放列表通常需要比非壓縮的播放列表更少比特以呈現(xiàn)播放列表，因此壓縮的播放列表，當被發(fā)送或接收時，使用如無線蜂窩電話網絡的網絡的更少的可用帶寬。在一實施例中，網絡服務器按照內置壓縮技術或設施壓縮播放列表，由與諸如HTTP I. I標準協(xié)議的傳輸協(xié)議一致或兼容的網絡服務器使用該壓縮技術或設施；這樣的壓縮技術或設施的一個示例是HTTP I. I的deflate或gzip壓縮設施。其他基于標準的壓縮設施，作為基于標準的傳輸協(xié)議的一部分，可被用于其他實施例中。在一實施例中，壓縮播放列表的使用可以是服務器設備和客戶端設備的可選特性。在一實施例中，播放列表可以是文本內容(例如，文本文件)并由基于標準的網絡服務器的deflate或gzip進行有效壓縮，然后由客戶端設備自動解壓?？梢栽赪WW. ietf. org/rfc/rfcl952. txt找到gzip壓縮設施的版本描述；可在www. ietf. org/rfc/rfcl951. txt找到deflate壓縮設施的版本。許多網絡服務器和客戶端設備上的許多網絡瀏覽器可自動支持deflate或gzip設施。在一實施例中，客戶端設備周期性地請求更新的播放列表；例如，客戶端設備每隔幾秒(例如，每隔10、20或30秒或其他時間周期)從服務器請求更新的播放列表。不斷增長的播放列表(如用于實況正在進行的籃球賽的播放列表，其允許客戶端在實況比賽過程中的任意時間從實況比賽開頭開始觀看)變得足夠大使得壓縮的使用可限制網絡帶寬的消耗，因為不斷增長的播放列表通過網絡被重復發(fā)送。在一實施例中，當客戶端設備請求播放列表(如更新的播放列表)時，其可選擇地指定可支持的壓縮技術(如deflate或gzip);這些技術的支持意味著客戶端設備可解壓或譯碼被壓縮或編碼的內容。通過壓縮技術的可選指定，網絡服務器接收客戶端設備對播放列表的請求，在一實施例中，并不需要該網絡服務器來支持用于播放列表的壓縮技術，而是可發(fā)送非壓縮播放列表。網絡服務器通過向客戶端設備發(fā)送非壓縮播放列表或使用在客戶 端設備對播放列表的請求中指定的壓縮技術之一進行壓縮的播放列表，來響應客戶端設備的請求。客戶端設備如這里所描述的接收和使用播放列表；如果播放列表是壓縮的，則使用客戶端設備中的解碼器，如客戶端設備上網絡瀏覽器中的解碼器，對其進行解碼。圖12A和12B顯示當附加媒體文件將被添加時(例如，當正被傳輸的當前播放列表不包含EXT-X-ENDLIST標簽時)用于后繼播放列表的傳輸的服務器定時模型的一實施例。如果當前播放列表不包含呈現(xiàn)的最后一個媒體文件，那么數據處理系統(tǒng)或服務器可制作包含至少一個新的媒體文件URI的播放列表新版本。圖12A和12B顯示服務器定時模型的一實施例，用于確保具有新的媒體文件URI的新播放列表能夠以延續(xù)播放列表前一個版本的方式傳輸到客戶端設備。例如，當允許在播放列表中指定的媒體文件具有較短的持續(xù)時間(例如，僅幾秒鐘長)時可使用該模型。在一實施例中，通過為每個媒體文件設置最大媒體文件持續(xù)時間和通過基于最大媒體文件持續(xù)時間設置播放列表持續(xù)時間的最小總量，服務器或其它數據處理系統(tǒng)可確保內容連續(xù)分發(fā)或傳輸到客戶端設備，即使每個媒體文件僅有幾秒鐘的持續(xù)時間?，F(xiàn)在參照圖12A，如果在操作1200所確定的下一個播放列表文件中不出現(xiàn)endlist標簽，則操作1201可用于建立作為播放列表中每個媒體文件的最大媒體文件持續(xù)時間的目標持續(xù)時間?？捎蓪祿骷毞譃槎鄠€媒體文件并將其存儲為各個文件的數據處理系統(tǒng)執(zhí)行操作1201。細分數據流的過程使用目標持續(xù)時間(例如，當前播放列表文件的目標持續(xù)時間)來確保播放列表文件中指定的每個媒體文件都小于目標持續(xù)時間(或小于目標持續(xù)時間加上或減去一小段時間)。如操作1203所示，產生播放列表的數據處理系統(tǒng)還確保播放列表文件的持續(xù)時間至少為目標持續(xù)時間的倍數。在一實施例中，該倍數可以是三個用作最小播放列表持續(xù)時間的目標持續(xù)時間(或目標持續(xù)時間的某些其他倍數)，其中，通過播放列表中指定的媒體文件的累積持續(xù)時間定義播放列表的持續(xù)時間。產生播放列表的系統(tǒng)(例如，服務器)通過確保每個播放列表指定至少足夠數量的媒體文件以滿足最小持續(xù)時間來遵守播放列表的最小持續(xù)時間；例如，如果最小持續(xù)時間是3個目標持續(xù)時間，則每個播放列表都應包含至少3個目標持續(xù)時間。操作1205還可用作確保一致的連續(xù)的數據流從數據處理系統(tǒng)(如傳輸媒體文件的服務器)中可用的進一步機制。該進一步機制可減少客戶端設備用于確定播放列表是否發(fā)生變化的輪詢和牽引的總量。在操作1205，可創(chuàng)建服務器以便服務器具有傳輸下一個播放列表的最早時間和最晚時間。最早時間和最晚時間可被用作基于或相對于前一個播放列表文件(恰好先于新播放列表)變?yōu)榭捎玫臅r間的時間窗口。例如，最早時間可基于緊接的前一個播放列表首次可用于從服務器傳輸(但不必已經傳輸)的時間。例如，最晚時間也可基于緊接的前一個播放列表首次可用于從服務器傳輸(但不必已經傳輸)的時間。例如，在一實施例中，最早時間可被指定為從之前的播放列表文件首次對傳輸變?yōu)榭捎瞄_始不早于目標持續(xù)時間(例如，在操作1201中設置的目標持續(xù)時間)的第一預定百分比(例如，二分之一)的時間，最晚時間可被設置為不晚于從緊接的前一個播放列表文件首次對從服務器的傳輸變?yōu)榭捎瞄_始不晚于目標持續(xù)時間的第二預定百分比(例如，1.5倍)的時間。在一實施例中，播放列表文件首次對傳輸可用的時間可以是播放列表文件的創(chuàng)建時間(該時間由服務器上的文件系統(tǒng)所記錄)。在包括時間線1211的圖12B中顯示該示例。目標持續(xù)時間1213為播放列表持續(xù)時間1215的一部分,播放列表持續(xù)時間表不在時間1209被一個或多個服務器首次變?yōu)榭捎玫木o接的前一個播放列表的持續(xù)時間，在時間1209，該前一個播放 列表文件首次對傳輸變?yōu)榭捎?。在該播放列表中指定的媒體文件差不多在時間1209開始它們的傳輸。根據圖12B中顯不的服務器定時模型,服務器不應當傳輸下一個播放列表文件，直到達到最早時間1217，其為時間1209之后的目標持續(xù)時間的二分之一，并且，服務器不應當在任何晚于時間1219的時間使下一個播放列表文件可用，在圖12B所述的示例中，時間1219被指定為時間1209之后的I. 5倍目標持續(xù)時間。可使用該服務器定時模型以確保播放列表文件對客戶端設備可用，來為客戶端設備提供足夠時間以重新獲取在播放列表中指定的媒體文件，并隨后在重放過程中一致且連續(xù)地、沒有拖延地在內容呈現(xiàn)中呈現(xiàn)那些媒體文件。在一實施例中，當內容為實況事件的傳輸并且來自實況事件的數據流被細分為多個媒體文件時可使用這些服務器定時模型，隨后，相對于實況事件準實時地將那些多個媒體文件傳輸到客戶端設備，客戶端設備在多個媒體文件從實況事件(如籃球比賽等)的數據流中被分出來之后不久接收該多個媒體文件。圖13示出可被用于防止客戶端設備重放中出現(xiàn)拖延的方法的實施例，尤其是當客戶端設備正準實時地呈現(xiàn)實況事件時以及當客戶端設備正在呈現(xiàn)接近實況事件的當前結尾(在時間上最新)的內容時。例如，如果實況事件為籃球比賽，客戶端設備的用戶寧愿僅觀看比賽中的最新事件而不愿從比賽最開頭開始觀看比賽。如果用戶想要僅觀看進行中的比賽的最新事件，則用戶可試圖對重放進行設置以從距離可用媒體流結尾10或15秒為起始點開始。當用戶設置客戶端設備使其在該模式下操作時，網絡問題或延遲可突然導致數據不可用并可阻止新數據變得可用，因此在很短時間內，客戶端設備可用完要呈現(xiàn)的內容?？墒褂脠D13的方法通過在客戶端設備執(zhí)行規(guī)定以減少上述問題發(fā)生的幾率，該規(guī)定要求在當前播放列表文件結尾之前至少一段時間(例如，30秒)的起始點開始重放。例如，如果播放列表文件內指定有5個媒體文件(每個媒體文件持續(xù)10秒)，那么該規(guī)定的一種實現(xiàn)方式是強制開始點在不晚于播放列表指定的五個媒體文件的序列中的第三個媒體文件?，F(xiàn)參照圖13，操作1301用于確定endlist標簽或標記是否出現(xiàn)在播放列表中。如果出現(xiàn)這樣的endlist標簽，那么圖13的方法可在沒有新的內容添加到播放列表時停止，因此在一實施例中不需要執(zhí)行操作1303中的規(guī)定。另一方面，如果在播放列表中不出現(xiàn)endlist標簽，那么在客戶端設備執(zhí)行規(guī)定要求開始點必須是至少在播放列表文件結束之前一時間段?？筛鶕襟w文件的目標持續(xù)時間指定該時間段。例如，在一實施例中，要求客戶端設備從距離播放列表文件結尾超過三倍目標持續(xù)時間的媒體文件開始。本發(fā)明的另一個方面涉及當在來自兩個播放列表的流之間(例如，兩個變型流)切換或在兩組媒體文件之間切換時使用的方法。結合圖9A、9B、9C和9D提供了用于在來自兩個不同播放列表的流之間切換的方法示例。在該方法中，兩個流之間在時間上的重疊被用于確保一致且連續(xù)的重放，以便流之間的切換或轉換是無縫的。如圖9D所示，重疊955表示來自兩個流的媒體內容在客戶端設備被存儲并能夠在客戶端設備被重放的時間段，從而允許在兩個流之間進行無縫切換。在一實施例中，重疊部分為從不改變的且在客戶端設備中設置的最小數字。雖然該實施例運作良好，但在某些時候該重疊部分不必要地太長。也就是說，重疊部分可防止切換或轉換的發(fā)生，即使設備已準備好進行轉換。例如，當從較低分辨率到較高分辨率切換時，不必要的長的重疊會迫使用戶在較高分辨率顯示內容已經可用和準備好被呈現(xiàn)時觀看一段時間的較低分辨率顯示內容。例如，高速的連接可提供快速開發(fā)重疊部分的能力，該重疊部分短于低速連接或連接類型所需的重疊部分。在根據圖14A 的實施例中，客戶端設備可適應連接速度或連接類型，并基于連接速度或連接類型修改所需的最小重疊。例如，如果連接速度或類型較快，則可相對于較低連接速度或連接類型所需的最小重疊而縮短最小重疊。當條件改變(例如，客戶端設備丟失3G連接且必須依賴2G或更慢的連接)時，可改變最小重疊。因此，客戶端設備可基于連接速度或類型適配最小重疊?，F(xiàn)參照圖14A，在操作1401，客戶端設備確定連接的速度或類型。重新參考圖9D，可以看到來自第二播放列表的第二數據流為當客戶端設備還接收來自第一播放列表的流時接收的新的數據源。這時，在操作1403，客戶端設備可確定連接速度或連接類型以確定基于當前連接速度或連接類型所需的最小重疊量。當諸如由無線連接到蜂窩電話塔、WiFi基站的條件改變時，可基于改變的條件適配該最小重疊。當客戶端設備在無線蜂窩電話網絡或其他數據網絡中移動時這會特別有利。當確定當前條件的最小重疊存在后，在操作1405，客戶端設備可從來自第一播放列表或舊的數據源的流切換或轉換到可以是來自第二播放列表的流的新的數據源。已結合圖9A-9D的相關描述提供了該轉換的示例。圖14B、14C和14D示出兩個流之間如何重疊的另一個方面(例如，結合圖9A-9D所示和描述的重疊或結合圖14A所描述的重疊)?？赏ㄟ^自適應導出的重疊(已連同圖14A對其進行描述)實現(xiàn)圖14B、14C和14D所示的方法，或者可通過不變的固定重疊使用該方法。圖14B-14D中描述的方法以從“舊流”1410 (例如，其可以是以第一速度下載的較低分辨率視頻，該第一速度在比特率上比用于新的流1414的后續(xù)下載的第二速度低)中下載媒體文件開始。如同哈希標記1411所指示的那樣舊流1410已經被下載，并且在客戶端設備上其正為用戶在重放點(例如，重放頭位置)1412呈現(xiàn)；在當前重放點1412之外的舊流1410中已經下載的內容為緩存內容，其在連接失敗時應當是有效的。然后客戶端設備讀取新流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的下載很快發(fā)生，那么客戶端設備可在時間上向回移動重疊點，減少在流之間切換所需的時間(并因此允許在塊1416A中的切換);另一方面，如果在下載1416A過程中有延時以致于切換不能在塊1416A中發(fā)生，那么客戶端設備可使用塊1415A作為可用以使得切換在塊1415A中發(fā)生的重疊部分。本發(fā)明的另一個方面使用定義圖像分類率的屬性。該屬性可允許客戶端設備決定它不應當切換分辨率或者不應當基于該屬性切換流。例如，客戶端設備確定已經在播放可顯示的最高分辨率并且通過數據網絡下載設備可用的更高分辨率是沒有意義的。 圖15示出在一實施例中用于使用這樣的屬性的方法的示例。在操作1501，客戶端設備接收播放列表文件，并且在操作1503，客戶端設備根據播放列表文件確定定義客戶端設備可用的圖像分辨率的屬性存在于播放列表文件中。基于該屬性，在操作1505，客戶端設備確定是否重新獲取另一個播放列表文件或是否重新獲取與該屬性相關的媒體文件。通過提供分辨率屬性，客戶端設備可智能地決定如何處理播放列表中的數據。另外，客戶端設備可作出有關數據重新取得的決定，該決定可防止不必要的下載，因而將網絡上數據流量的總量減到最小。本發(fā)明的實施例可允許系統(tǒng)基于日期和時間搜索內容。例如，用戶想要看2009年4月9日下午5點的一記全壘打或想要看某個日期大致時間的另一個事件。本發(fā)明的實施例可通過時間戳，通過使用與相應媒體文件的開頭相關的ext-x-program-date-hme標簽，提供該能力；通過在播放列表文件的媒體文件之前出現(xiàn)標簽使得該標簽與相應媒體文件關聯(lián)。系統(tǒng)，如服務器，存儲可由客戶端設備重新獲取(例如，下載)的一個或多個播放列表并用于搜索日期和時間以找到想要的媒體文件；或者，客戶端設備請求(例如，通過日期和時間搜索請求)服務器搜索一個或多個播放列表以識別一個或多個匹配日期和時間搜索請求的媒體文件，并且服務器通過識別該一個或多個媒體文件作出響應。在一實施例中，標簽指示媒體文件基本精確的開頭，并且媒體文件中的時間戳可用于以時間上的更精確粒度來找到重放點。例如，標簽的時間戳指示媒體文件在2009年4月9日下午5:03開始，并且媒體文件中的時間戳(或時間的其他指示)在下午5:03以后以分鐘或秒等為增量指定時間，以允許設備在例如下午5:06或下午5:05:30開始重放(通過重放開始點的選擇)。圖16A示出描述根據一實施例的用于使用時間戳標簽創(chuàng)建播放列表文件的方法的流程圖。由通過包括軟件、硬件、固件或上述的任意組合的處理邏輯實現(xiàn)的服務器執(zhí)行該方法。在一些示例中，由媒體提供商，如MLB，提供該服務器。在方框1610，處理邏輯創(chuàng)建時間戳標簽并將每個時間戳標簽與一個媒體文件相關聯(lián)。時間戳標簽中的時間戳指示相關媒體文件的開始日期和時間。上面已經討論了時間戳標簽的一些實施例的細節(jié)。在方框1620,處理邏輯創(chuàng)建具有一個或多個時間戳標簽(例如，EXT-X-PROGRAM-DATE-TIME標簽)的播放列表文件，其中每一個時間戳標簽與一特定媒體文件相關聯(lián)。注意到，媒體文件本身也具有內部時間戳。在方框1630，處理邏輯分配播放列表以便播放列表文件可用于使用時間戳標簽中的日期和時間進行日期和時間的搜索。在一些實施例中，在儲存庫中存儲播放列表，客戶端設備可從中下載播放列表。圖16B示出描述根據一實施例的用于使用連同時間戳標簽而創(chuàng)建的播放列表文件的方法流程圖。由通過包括軟件、硬件、固件或上述的任意組合的處理邏輯實現(xiàn)的客戶端設備執(zhí)行該方法。由與播放列表文件相關聯(lián)的媒體的個別消費者、訂閱者或瀏覽者使用客戶端設備訪問和播放該媒體。在方框1650，處理邏輯接收對在特定日期和時間開始的節(jié)目分段的用戶請求。例如，用戶可請求于2010年4月6日下午8:15開始的籃球比賽的第四節(jié)，而不是整個籃球比賽。響應于用戶請求，在方框1652，處理邏輯從媒體服務器下載一個或多個與節(jié)目相關聯(lián)的 播放列表文件。在方框1654，處理邏輯使用在播放列表文件內部的時間戳標簽中的日期和時間搜索下載的播放列表文件以尋找與請求分段的日期和時間最接近的日期和時間標志(時間戳)。然后在方框1656，處理邏輯從請求分段的日期和時間中減去其日期和時間。這就產生一持續(xù)時間。然后在方框1657，處理邏輯向前經過播放列表中的后續(xù)媒體文件持續(xù)時間，直到在被標記日期的媒體文件之后的大約該持續(xù)時間時，處理邏輯定位到目標媒體文件。然后在方框1658，處理邏輯下載該目標媒體文件，因為其是哪個文件包含請求分段的最好猜測。在一些實施例中，在被標記日期的媒體文件和目標媒體文件之間的所有媒體文件為單一編碼的一部分，即，在它們之間沒有中斷標簽。如果它們是，處理邏輯從目標文件中的那些媒體文件時間戳中減去被標記日期的文件中的媒體文件時間戳以得到精確持續(xù)時間，從而允許精確定位所請求的日期和時間。使用播放列表文件中時間戳標簽中的日期和時間，處理邏輯不必下載整個節(jié)目的所有媒體文件以在媒體文件中進行搜索以發(fā)現(xiàn)所請求的分段。由于在用戶沒有請求整個節(jié)目時客戶端設備不必下載整個節(jié)目的所有媒體文件，可實現(xiàn)帶寬的顯著節(jié)省。此外，許多典型的媒體文件僅包含任意時間戳，通常以零開始。因此，上述時間戳標簽的日期和時間將媒體文件中的任意時間戳與實際日期和/或時間相關聯(lián)。與掃描每個媒體文件相比，使用時間戳標簽，客戶端設備可更有效地定位包含特定日期和/或時間的播放列表元素。本發(fā)明的實施例允許將時間元數據以ID3格式插入到媒體流中。媒體流包含以預定格式編碼的視頻和/或音頻數據。例如，媒體流可包含以MPEG-2格式編碼的視頻和音頻數據，MPEG-2是由運動圖像專家組(MPEG)開發(fā)的國際標準IS0/IEC 13818。廣義上說，元數據包含媒體流中數據相關的信息，以及涉及有關特定時間(例如，進球得分的時間)的元數據的定時元數據。注意到，定時元數據可隨時間改變?？蓪⒍〞r元數據以預定的用于存儲元數據的格式，如ID3格式，插入到媒體流中。在一些實施例中，可將視頻數據分成一系列幀。還可將視頻數據的定時元數據分入與該系列幀有關的容器。每一個容器可存儲相應幀的定時元數據以及與相應幀有關的時間二者?？蛇x地，每一個容器可存儲相應幀的定時元數據以及相應巾貞的巾貞數目二者。在一些實施例中，巾貞的定時元數據包含該巾貞的一組預定信息。例如，定時元數據包含記錄視頻數據的相應幀的位置的位置信息(例如，全球定位系統(tǒng)(GPS)數據)。在一實施例中，下面內容描述了如何在這里所描述的HTTP現(xiàn)場流傳輸協(xié)議所使用的MPEG-2傳輸流中攜帶ID3元數據作為定時元數據(參見IS0/IEC13818-1: 2007信息技術-運動圖像的通用編碼和相關音頻信息下文作為“MPEG-2標準”提及的系統(tǒng))。根據MPEG-2標準的第2. 12節(jié)，可在傳輸流中攜帶元數據。例如，可在基本流(PES)中攜帶元數據，而不是在傳送帶中。ID3元數據是自描述的，不需要配置信息，因此不需要使用元數據解碼器配置數據的規(guī)定。元數據流可與主要節(jié)目素材(也即，音頻/視頻內容)在相同節(jié)目中。表S1、S2、S3和S4提供了可被使用的語法的實施例。在下面的語法表中，僅以有效輪廓和字段名顯示該語法結構(左欄)。這就意味著，為了清楚起見，省略條件為假時的’ if’方框。針對完整語法、字段大小和可接受值可查閱MPEG-2標準。在具有每個字段名的行中，右欄指示在該上下文中所需的值，或者包含該行的解釋。 使用的代碼點概述ID3定義格式和語義，因此，相同的注冊的format_identifier可用于metadata_format」dent if ier 和 metadata_application_format_identifier 二者。在注冊機構SMPTE注冊中心(參見http://www. smpte-ra. org),為這些所注冊的值為“ID3” (ID3空格，或0x490x440x330x20)(待分配)。為了指示使用的注冊值，字段metadata_format和metadata_application_format可分別取值為oxff和oxffff。在一實施例中，可在私用數據流中載有該元數據，而不是以MPEG-2標準的第12. 4節(jié)中定義的元數據訪問單元(MAU)的形式格式化的流。因此，如同MPEG-2標準第2. 12. 3節(jié)中所規(guī)定的,用于流的stream_id的值為 private_stream_id_l、Oxbd。如同 MPEG-2 標準第 2. 12. 9. I 節(jié)中所規(guī)定的，stream_type被設置為0x15，指示在PES流中攜帶元數據。由于通常僅攜帶一個元數據流，因此metadata_service_id通常被設為O ;但是,如果需要的話，可使用任何合適的值以區(qū)別該元數據流與其他流。使用的描述符元數據描述符的格式和內容記載在MPEG-2標準第2. 6. 58-2. 6. 61節(jié)中。用于節(jié)目的PMT的描述符循環(huán)在節(jié)目的piOgram_inf0循環(huán)中，為了聲明元數據流的存在，可在PMT中設置metadata_pointer_descriptor (MPEG-2標準第2. 6. 58節(jié))。兀數據可與主要節(jié)目(音頻/視頻)內容在相同的節(jié)目中。在一實施例中，不支持使用該描述符來引用另一個節(jié)目。表SI
權利要求
1.一種客戶端設備執(zhí)行的方法，所述方法包括 執(zhí)行用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)；以及 運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼以及將來自所述媒體文件的解碼內容提供給所述用戶應用。
2.根據權利要求I所述的方法，其中所述媒體服務進程和所述用戶應用對存儲器控制、存儲器空間、存儲器分配、文件系統(tǒng)控制和網絡控制共享相同的特權。
3.根據權利要求2所述的方法，其中所述用戶應用提供用戶界面以控制所述呈現(xiàn)并且通過應用編程接口(API)與所述媒體服務進程通信，并且其中所述用戶應用和所述媒體服務進程是不同的軟件進程。
4.根據權利要求2所述的方法，其中所述媒體服務進程取回媒體文件，所述媒體文件是使用由所述用戶應用處理或者由所述用戶應用取回并處理的密鑰進行解碼的。
5.根據權利要求2所述的方法，其中所述用戶應用安裝客戶端證書，所述證書用于在創(chuàng)建連接以下載解密密鑰時應答服務器的詢問。
6.根據權利要求2所述的方法，其中所述播放列表包含使用自定義URL方案的解密密鑰的URL。
7.根據權利要求3所述的方法，其中當所述媒體服務進程加載或解碼媒體文件失敗時，所述媒體服務進程通過所述API調用所述用戶應用以使得所述用戶應用取回一個或多個返回到所述媒體服務進程的密鑰。
8.根據權利要求3所述的方法，其中所述媒體服務進程取回媒體文件，所述媒體文件是使用由所述用戶應用處理或者由所述用戶應用取回并處理的密鑰進行解碼的。
9.根據權利要求8所述的方法，其中所述用戶應用安裝客戶端證書，所述證書用于在創(chuàng)建連接以下載解密密鑰時應答服務器的詢問。
10.根據權利要求9所述的方法，其中所述播放列表包含使用自定義URL方案的解密密鑰的URL。
11.一種由數據處理系統(tǒng)執(zhí)行的機器實現(xiàn)的方法，所述方法包括 在客戶端設備上執(zhí)行用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)；以及 在所述客戶端設備上運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼； 通過所述媒體服務器接收URL，所述URL涉及所述媒體服務器使用的用于解碼或呈現(xiàn)至少一個所述媒體文件的數據； 由所述媒體服務器調用所述用戶應用以處理所述URL來獲得所述媒體服務器要使用的所述數據； 響應于所述用戶應用處理所述URL而接收所述數據，從而獲得所述數據；以及 使用所述數據解碼至少一個所述媒體文件。
12.根據權利要求11所述的方法，其中所述數據是解密密鑰。
13.根據權利要求11所述的方法，其中所述用戶應用使用自定義URL，所述自定義URL用于保護通過所述用戶應用提供的內容。
14.根據權利要求13所述的方法，其中注冊表存儲所述自定義URL和所述用戶應用之間的關系，并且其中當所述媒體服務器不能解碼媒體文件時，所述媒體服務器檢查所述注冊表以調用所述用戶應用。
15.根據權利要求14所述的方法，其中所述自定義URL由EXT-X-KEY標簽指定，并且其中所述用戶應用由所述媒體文件的提供者授權。
16.根據權利要求15所述的方法，其中所述用戶應用將自定義URL和所述用戶應用之間的關系安裝到注冊表中，所述自定義URL用于為所述媒體文件取回一個或多個解密密鑰，并且其中當所述用戶應用第一次被安裝或第一次被啟動時，所述用戶應用將所述關系安裝到所述注冊表中。
17.根據權利要求13所述的方法，其中所述自定義URL不被所述媒體服務器所支持。
18.根據權利要求13所述的方法，其中所述自定義URL用于取回被提供給所述媒體服務器以對所述播放列表中的所述媒體文件進行解碼的所述解密密鑰。
19.根據權利要求18所述的方法，其中所述用戶應用對所述自定義URL的解析取決于如下條件中的至少一個Ca)所述用戶應用的對于所述媒體文件中的內容的特權等級；(b)所述媒體文件中的內容；以及(c)呈現(xiàn)所述媒體文件中的內容的請求的日期或時間或日期和時間。
20.根據權利要求19所述的方法，其中所述解密密鑰通過所述用戶應用被返回給所述媒體服務器。
21.一種由數據處理系統(tǒng)執(zhí)行的機器實現(xiàn)的方法，所述方法包括 在客戶端設備上執(zhí)行用戶應用，所述用戶應用被配置以控制所述媒體文件的呈現(xiàn)；以及 在所述客戶端設備上運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼； 通過所述媒體服務器接收在所述播放列表中或用于所述播放列表的URL，所述URL涉及被用于處理至少一個所述媒體文件的數據； 由所述媒體服務器調用所述用戶應用以處理所述URL來獲取遠程媒體服務器要使用的數據； 響應于所述用戶應用處理所述URL而接收所述數據，從而獲得所述數據；以及 傳輸所述數據到所述遠程媒體服務器。
22.根據權利要求21所述的方法，其中所述URL是所述播放列表中的一個的自定義URL或者是所述播放列表中的至少一個媒體文件的解密密鑰，并且其中所述用戶應用使用所述自定義URL來保護通過所述用戶應用提供的內容。
23.根據權利要求21所述的方法，其中注冊表存儲所述自定義URL和所述用戶應用之間的關系，并且其中當所述媒體服務器不能處理所述URL時，所述媒體服務器檢查所述注冊表以調用所述用戶應用。
24.根據權利要求23所述的方法，其中所述遠程媒體服務器是機頂盒的一部分，并且被配置成取回和處理播放列表，并被配置成產生被傳輸回所述媒體服務器的消息，以請求對所述自定義URL的解析，并且其中傳輸數據到所述遠程媒體服務器提供了對所述自定義URL的解析。
25.一種客戶端設備，所述客戶端設備包括 用于執(zhí)行用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)的裝置；以及 用于運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼以及將來自所述媒體文件的解碼內容提供給所述用戶應用的裝置。
26.根據權利要求25所述的客戶端設備，其中所述媒體服務進程和所述用戶應用對存儲器控制、存儲器空間、存儲器分配、文件系統(tǒng)控制和網絡控制共享相同的特權。
27.根據權利要求26所述的客戶端設備，其中所述用戶應用提供用戶界面以控制所述呈現(xiàn)并且通過應用編程接口(API)與所述媒體服務進程通信，并且其中所述用戶應用和所述媒體服務進程是不同的軟件進程。
28.根據權利要求26所述的客戶端設備，其中所述媒體服務進程取回媒體文件，所述媒體文件是使用由所述用戶應用處理或者由所述用戶應用取回并處理的密鑰進行解碼的。
29.根據權利要求26所述的客戶端設備，其中所述用戶應用安裝客戶端證書，所述證書用于在創(chuàng)建連接以下載解密密鑰時應答服務器的詢問。
30.根據權利要求26所述的客戶端設備，其中所述播放列表包含使用自定義URL方案的解密密鑰的URL。
31.根據權利要求27所述的客戶端設備，其中當所述媒體服務進程加載或解碼媒體文件失敗時，所述媒體服務進程通過所述API調用所述用戶應用以使得所述用戶應用取回一個或多個返回到所述媒體服務進程的密鑰。
32.根據權利要求27所述的客戶端設備，其中所述媒體服務進程取回媒體文件，所述媒體文件是使用由所述用戶應用處理或者由所述用戶應用取回并處理的密鑰進行解碼的。
33.根據權利要求32所述的客戶端設備，其中所述用戶應用安裝客戶端證書，所述證書用于在創(chuàng)建連接以下載解密密鑰時應答服務器的詢問。
34.根據權利要求33所述的客戶端設備，其中所述播放列表包含使用自定義URL方案的解密密鑰的URL。
35.一種數據處理系統(tǒng)，所述數據處理系統(tǒng)包括客戶端設備和媒體服務器， 其中，所述客戶端設備包括 用于執(zhí)行用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)的裝置；以及 用于運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼的裝置；以及 所述媒體服務器包括 用于接收URL的裝置，所述URL涉及所述媒體服務器使用的用于解碼或呈現(xiàn)至少一個所述媒體文件的數據； 用于調用所述用戶應用以處理所述URL來獲得所述媒體服務器要使用的所述數據的裝置； 其中，所述客戶端設備還包括 用于響應于所述用戶應用處理所述URL而接收所述數據，從而獲得所述數據的裝置；以及 用于使用所述數據解碼至少一個所述媒體文件的裝置。
36.根據權利要求35所述的數據處理系統(tǒng)，其中所述數據是解密密鑰。
37.根據權利要求35所述的數據處理系統(tǒng)，其中所述用戶應用使用自定義URL，所述自定義URL用于保護通過所述用戶應用提供的內容。
38.根據權利要求37所述的數據處理系統(tǒng)，其中注冊表存儲所述自定義URL和所述用戶應用之間的關系，并且其中當所述媒體服務器不能解碼媒體文件時，所述媒體服務器檢查所述注冊表以調用所述用戶應用。
39.根據權利要求38所述的數據處理系統(tǒng)，其中所述自定義URL由EXT-X-KEY標簽指定，并且其中所述用戶應用由所述媒體文件的提供者授權。
40.根據權利要求39所述的數據處理系統(tǒng)，其中所述用戶應用將自定義URL和所述用戶應用之間的關系安裝到注冊表中，所述自定義URL用于為所述媒體文件取回一個或多個解密密鑰，并且其中當所述用戶應用第一次被安裝或第一次被啟動時，所述用戶應用將所述關系安裝到所述注冊表中。
41.根據權利要求37所述的數據處理系統(tǒng)，其中所述自定義URL不被所述媒體服務器所支持。
42.根據權利要求37所述的數據處理系統(tǒng)，其中所述自定義URL用于取回被提供給所述媒體服務器以對所述播放列表中的所述媒體文件進行解碼的所述解密密鑰。
43.根據權利要求42所述的數據處理系統(tǒng)，其中所述用戶應用對所述自定義URL的解析取決于如下條件中的至少一個(a)所述用戶應用的對于所述媒體文件中的內容的特權等級；(b)所述媒體文件中的內容；以及(C)呈現(xiàn)所述媒體文件中的內容的請求的日期或時間或日期和時間。
44.根據權利要求43所述的數據處理系統(tǒng)，其中所述解密密鑰通過所述用戶應用被返回給所述媒體服務器。
45.一種數據處理系統(tǒng)，所述數據處理系統(tǒng)包括客戶端設備和媒體服務器， 其中，所述客戶端設備包括 用于執(zhí)行用戶應用的裝置，所述用戶應用被配置以控制所述媒體文件的呈現(xiàn)；以及 用于運行媒體服務進程，獨立于所述用戶應用，以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼的裝置；并且 所述媒體服務器包括 用于接收在所述播放列表中或用于所述播放列表的URL的裝置，所述URL涉及被用于處理至少一個所述媒體文件的數據； 用于調用所述用戶應用以處理所述URL來獲取遠程媒體服務器要使用的數據的裝置， 其中所述客戶端設備還包括 用于響應于所述用戶應用處理所述URL而接收所述數據，從而獲得所述數據的裝置；以及 用于傳輸所述數據到所述遠程媒體服務器的裝置。
46.根據權利要求45所述的數據處理系統(tǒng)，其中所述URL是所述播放列表中的一個的自定義URL或者是所述播放列表中的至少一個媒體文件的解密密鑰，并且其中所述用戶應用使用所述自定義URL來保護通過所述用戶應用提供的內容。
47.根據權利要求45所述的數據處理系統(tǒng)，其中注冊表存儲所述自定義URL和所述用戶應用之間的關系，并且其中當所述媒體服務器不能處理所述URL時，所述媒體服務器檢查所述注冊表以調用所述用戶應用。
48.根據權利要求47所述的數據處理系統(tǒng)，其中所述遠程媒體服務器是機頂盒的一部分，并且被配置成取回和處理播放列表，并被配置成產生被傳輸回所述媒體服務器的消息，以請求對所述自定義URL的解析，并且其中傳輸數據到所述遠程媒體服務器提供了對所述自定義URL的解析。
全文摘要
本發(fā)明涉及實時或準實時流傳輸。方法和設備使用傳輸協(xié)議如HTTP兼容協(xié)議提供在一個或多個播放列表中指定的內容的實時或準實時流傳輸。在一實施例中，一種方法可在客戶端設備上執(zhí)行一用戶應用以呈現(xiàn)媒體文件并控制所述媒體文件的呈現(xiàn)。所述方法可進一步在所述客戶端設備上運行一媒體服務進程以取回指定所述媒體文件的播放列表以及所述媒體文件可用的媒體源，從所述媒體源取回所述媒體文件，并對取回的所述媒體文件進行解碼。為了獲獲取自定義URL所引用的對象，所述媒體服務進程可調用所述用戶應用以處理所述自定義URL。
文檔編號H04L29/06GK102882845SQ20121027892
公開日2013年1月16日 申請日期2011年4月7日 優(yōu)先權日2010年4月7日
發(fā)明者R·潘特斯, A·楚恩格, 小W·梅 申請人:蘋果公司