使用url模板和構造規則的增強型塊請求流送的製作方法

2023-04-25 06:06:41

專利名稱：使用url模板和構造規則的增強型塊請求流送的製作方法
技術領域：
本發明涉及改善的媒體流送系統和方法，尤其涉及自適應於網絡和緩衝條件以使流送媒體的呈現最優化並允許對流送媒體數據進行高效的並發或時間分布式投遞的系統和方法。
背景技術：
流送媒體投遞可能變得日益重要，因為在諸如網際網路、蜂窩和無線網絡、輸電線網絡、以及其他類型的網絡之類的基於分組的網絡上投遞高質量音頻和視頻變得越來越常見。所投遞的流送媒體能被呈現出的質量可取決於數種因素，包括原始內容的解析度(或其他屬性)、原始內容的編碼質量、接收設備解碼和呈現媒體的能力、在接收機處接收到的信號的及時性和質量等。為了產生感知到的良好的流送媒體體驗，在接收機處接收到的信號的傳輸和及時性可能尤其重要。良好的傳輸可以提供在接收機處接收到的流相對於發送方發送的流的保真度，而及時性可以代表接收機在初始請求內容之後多快就能開始播出該內容。媒體投遞系統可表徵為具有媒體源、媒體目的地、以及將源和目的地分開的(時間和/或空間上的)信道的系統。典型地，源包括能訪問可電子地管理的形式的媒體的發射機、以及有能力電子地控制對媒體(或其近似物)的接收並將其提供給媒體消費者(例如，具有以某種方式耦合到該接收機、存儲設備或元件、另一信道等的顯示設備的用戶)的接收機。雖然有許多變型是可能的，但在常見的示例中，媒體投遞系統具有能訪問電子形式的媒體內容的一個或更多個伺服器，並且一個或更多個客戶端系統或設備向伺服器作出對媒體的請求，而伺服器使用作為該伺服器的一部分的向客戶端處的接收機進行傳送的發射機來輸送該媒體，從而收到的媒體能由該客戶端以某種方式消費。在簡單的示例中，對於給定的請求和響應而言有一個伺服器和一個客戶端，但並非必需如此。按傳統，媒體投遞系統可表徵為「下載」模型或「流送」模型。「下載」模型可由媒體數據的投遞與該媒體向用戶或接收方設備的播出之間的時基獨立性來表徵。作為示例，媒體在被需要或將被使用之前被下載得足夠多，並且在該媒體被使用時，在接收方處已有所需那麼多的媒體可用。在下載的上下文中的投遞往往是使用諸如 HTTP、FTP或單向傳輸上的文件投遞(FLUTE)之類的文件傳輸協議來執行的，且投遞速率可由下層的流量和/或擁塞控制協議(諸如TCP/IP)來決定。該流量或擁塞控制協議的操作可獨立於媒體向用戶或目的地設備的播出，而播出可與下載並發地發生或在其他某個時間發生。「流送」模式可由媒體數據的投遞與該媒體向用戶或接收方設備的播出的時基之間的緊耦合來表徵。在該上下文中的投遞往往是使用流送協議來執行的，諸如用於控制的實時流送協議(RTSP)和用於媒體數據的實時傳輸協議(RTP)。投遞速率可由流送伺服器決定，通常與數據的播出速率匹配。「下載」模型的一些缺點可能在於，由於投遞與播出之間的時基獨立性，要麼在需要媒體數據供播出時該媒體數據可能不可用(例如，由於可用帶寬小於媒體數據率)，導致播出暫時停止(「停滯」)，而這造成不良的用戶體驗；要麼可能要求提前在播出之前很久就下載媒體數據(例如，由於可用帶寬大於媒體數據率)，從而消費掉接收設備上可能稀缺的存儲資源，並且消費寶貴的網絡資源進行投遞，而這在內容最終沒有被播出或以其他方式使用的情況下會被浪費掉。「下載」模型的優點可在於執行此類下載所需的技術(例如，HTTP)非常成熟、被廣泛部署且全面適用於很廣範圍的應用。用於實現此類文件下載的大規模可伸縮性的下載伺服器和解決方案(例如，HTTP Web伺服器和內容投遞網絡)可能是現成可用的，從而使得基於該技術的服務部署簡單且成本低廉。「流送」模型的一些缺點可能在於，一般而言，媒體數據的投遞速率並不適配於從CN 102577307 A說明書3/65 頁
伺服器到客戶端的連接上的可用帶寬，且需要提供帶寬和延遲擔保的專門的流送伺服器或更複雜的網絡架構。儘管存在支持根據可用帶寬來變化投遞數據率的流送系統(例如， Adobe Flash自適應流送)，但是這些系統在利用所有可用帶寬方面一般不如諸如TCP之類的下載傳輸流量控制協議那麼高效。最近，已開發和部署了基於「流送」和「下載」模型的組合的新型媒體投遞系統。此類模型的示例在本文中被稱為「塊請求流送」模型，其中媒體客戶端使用諸如HTTP之類的下載協議來向服務基礎設施請求媒體數據塊。此類系統中的關注點可能是開始播出流的能力，例如使用個人計算機來解碼和渲染收到的音頻和視頻流並在計算機屏幕上顯示該視頻以及通過內置揚聲器來播放該音頻，或者作為另一示例，使用機頂盒來解碼和渲染收到的音頻和視頻流並在電視顯示設備上顯示該視頻以及通過立體聲系統來播放該音頻。諸如能夠足夠快地解碼源塊以跟上源流送速率、使解碼等待時間最小化以及減少對可用CPU資源的使用之類的其他關注點也是問題所在。另一關注點是提供穩健和可伸縮的流送投遞解決方案，其允許系統的組件發生故障而不會不利地影響投遞給接收機的流的質量。基於在呈現正被分發時關於該呈現的快速改變的信息，可能發生其他問題。因此，希望具有改善的過程和裝置。發明簡要概述一種塊請求流送系統典型地使用攝取系統來提供此類系統的用戶體驗和帶寬效率的改善，該攝取系統生成將由常規文件伺服器(例如，HTTP、FTP或類似伺服器)供應的形式的數據，其中該攝取系統攝入內容並將其製備為將由可包括或可不包括高速緩存的該文件伺服器來供應的文件或數據元素。客戶端設備可適配成利用攝取過程並且包括促成獨立於該攝取過程的更好呈現的改進。在一方面，客戶端設備和攝取系統被協調，從而存在用於作出對HTTP文件名的塊請求的預定義映射和模板，而常規文件伺服器可通過使用URL構造規則來接受這樣的塊請求。在一些實施例中，提供了對用於以近似方式指定段大小以獲得更高效的組織的方法的新穎改進。以下詳細描述連同附圖將提供對本發明的本質和優點的更好理解。附圖簡述

圖1描繪了根據本發明的實施例的塊請求流送系統的元素。圖2解說圖1的塊請求流送系統，示出了耦合到塊供應基礎設施(「BSI」)以接收由內容攝取系統處理的數據的客戶端系統的元素中的更多細節。圖3解說了攝取系統的硬體/軟體實現。圖4解說了客戶端系統的硬體/軟體實現。圖5解說了圖1中所示的內容存儲的可能結構，包括段和媒體呈現描述符(「MPD」) 文件，以及MPD文件內的段分解、時基和其他結構。圖6解說了如可存儲在圖1和5中解說的內容存儲中的典型源段的細節。圖7a和7b解說了文件內的簡單索引和階層式索引。圖8 (a)解說了在媒體流的多個版本上具有對準的查找點的可變塊大小控制。圖8(b)解說了在媒體流的多個版本上具有非對準的查找點的可變塊大小控制。圖9 (a)解說了元數據表。圖9 (b)解說了從伺服器向客戶端傳輸塊和元數據表。
圖10解說了獨立於RAP邊界的塊。圖11解說了跨段的連續時基和不連續時基。圖12是示出可伸縮塊的一方面的圖。圖13描繪了塊請求流送系統內的某些變量隨時間演進的圖形表示。圖14描繪了塊請求流送系統內的某些變量隨時間演進的另一圖形表示。圖15描述了作為閾值的函數的狀態的單元柵格。圖16是可在接收機中執行的每請求能請求單個塊以及多個塊的過程的流程圖。圖17是靈活管線過程的流程圖。圖18解說了在某個時間的一組候選請求、其優先級、以及在哪些連接上能發出這些請求的示例。圖19解說了已隨時間變遷而演進的一組候選請求、其優先級、以及在哪些連接上能發出這些請求的示例。圖20是基於文件標識符的一致性高速緩存伺服器代理選擇的流程圖。圖21解說了對合適的表達式語言的句法定義。圖22解說了合適的散列函數的示例。圖23解說了文件標識符構造規則的示例。圖M(a)_(e)解說了 TCP連接的帶寬波動。圖25解說了對源數據和修複數據的多個HTTP請求。圖沈解說了帶FEC和不帶FEC的示例頻道換臺時間。圖27解說了作為圖1中所示的攝取系統一部分的從源段和控制參數生成修復段的修復段生成器的詳情。圖觀解說了源塊與修復塊之間的關係。圖四解說了在客戶端處不同時間的實況服務的規程。在附圖中，相似的項目用相似的標號來引述且在括號中提供副標以指示相似或相同項目的多個實例。除非另行指出，否則最後的副標(例如，「N」或「M」)並非意在限定於任何特定值，且一個項目的實例數目可與另一項目的實例數目不同，即使在解說了相同的標號且重複使用了副標時亦然。發明詳細描述如本文中所描述的，流送系統的目標是將媒體從其存儲位置(或正生成該媒體的位置)移到正消費該媒體的位置，即呈現給用戶或以其他方式被人類或電子消費者「用盡」。理想情況下，流送系統可在接收端提供不間斷的回放(或更一般而言，不間斷的「消費」)，且在用戶請求了流或流集合之後不久就能開始播放這個或這些流。出於效率原因，還希望每個流在一旦用戶指示不再需要該流時，諸如當用戶正從一個流切換到另一個流或者其服從例如「字幕」流之類的流的呈現時就被停下。若諸如視頻之類的媒體分量繼續被呈現，但選擇了不同的流來呈現該媒體分量，則往往優選令新的流佔用有限的帶寬並停止舊的流。根據本文中描述的實施例的塊請求流送系統提供許多益處。應理解，可行的系統無需包括本文中描述的所有特徵，因為一些應用可用不足本文中描述的特徵全體的特徵來提供令人滿意程度適宜的體驗。
HTTP 流送HTTP流送是一種具體的流送類型。在HTTP流送下，源可以是標準web伺服器和內容投遞網絡(CDN)並且可使用標準HTTP。該技術可涉及流分段以及使用多個流，所有這些皆落在標準化HTTP請求的上下文中。諸如視頻之類的媒體可以用多個比特率來編碼以構成不同的版本或表示。術語「版本」和「表示」在本文中同義地使用。每個版本或表示可被分解成較小的片以構成段，片可能在幾秒的量級。每個段隨後可作為單獨的文件被存儲在 web伺服器或⑶N上。在客戶端一側，隨後可使用HTTP作出對個體段的請求，這些個體段由客戶端無縫地拼接在一起。客戶端可基於可用帶寬切換到不同的數據率。客戶端還可請求多個表示， 每個表示呈現不同的媒體分量，並且可聯合且同步地呈現這些表示中的媒體。切換的觸發可包括例如緩衝器佔用率和網絡測量。當在穩態下操作時，客戶端可調整向伺服器請求的步調以維持目標緩衝器佔用率。HTTP流送的優點可包括比特率自適應、快速啟動和查找、以及最小程度的不必要投遞。這些優點源於將投遞控制成僅比播出提前很短時間、對可用帶寬作出最大程度的使用(通過可變比特率媒體)、以及優化流分段和智能客戶端規程。媒體呈現描述可被提供給HTTP流送客戶端，以使得客戶端能使用文件(例如以 3GPP規定的格式，在本文中稱為3gp段)的集合來向用戶提供流送服務。媒體呈現描述以及可能還有該媒體呈現描述的更新描述了實為結構化的段集合的媒體呈現，每個段包含媒體分量以使得客戶端能以同步方式呈現所包括的媒體並且能提供高級特徵，諸如查找、切換比特率、以及聯合呈現不同表示中的媒體分量。客戶端可按不同方式使用媒體呈現描述信息來得到服務的供給。具體而言，根據媒體呈現描述，HTTP流送客戶端可確定能訪問該集合中的哪些段，從而流送服務內的數據對於客戶端能力以及用戶而言是有用的。在一些實施例中，媒體呈現描述可以是靜態的，但段可以是動態地創建的。媒體呈現描述可以儘可能緊湊以使該服務的訪問和下載時間最小化。其他專用伺服器連通性可被最小化，例如客戶端與伺服器之間常規或頻繁的時基同步。可以將媒體呈現構造成允許被具有不同能力——諸如接入不同的接入網類型、不同的當前網絡條件、顯示器大小、訪問比特率和編解碼器支持——的終端訪問。客戶端隨後可提取恰適的信息以向用戶提供流送服務。媒體呈現描述還可根據要求允許部署靈活性以及緊湊性。在最簡單的情形中，每個替換表示可被存儲在單個3GP文件中，即遵照如3GPP TS26. 244中的定義的文件、或遵照如IS0/IEC 14496-12或衍生規範中定義的ISO基媒體文件格式(諸如3GPP技術規範26. 244中描述的3GP文件格式)的任何其他文件。在本文檔的其餘部分中，在引述3GP文件時，應理解IS0/IEC 14496-12和衍生規範可將所有所描述的特徵映射到如IS0/IEC 14496-12或任何衍生規範中定義的更一般性的ISO基媒體文件格式。客戶端隨後可請求文件的初始部分以獲悉媒體元數據(其典型地被存儲在也被稱為 「moov」包的電影頭部包中)連同電影片斷時間和字節偏移量。客戶端隨後可發出HTTP部分獲取請求以獲得所要求的電影片斷。在一些實施例中，可能希望將每個表示拆分成若干段，其中這些段。在段格式基於 3GP文件格式的情形中，則段包含電影片斷的非交迭時間片，稱為「按時間拆分」。這些段中的每一個可包含多個電影片斷且每個段本身可以是有效3GP文件。在另一實施例中，表示被拆分成包含元數據的初始段(典型情況下為電影頭部「moov」包)以及一組媒體段，每個媒體段包含媒體數據，並且初始段與任何媒體段的級聯構成有效的3GP文件，而且一個表示的初始段和所有媒體段的級聯也構成有效的3GP文件。通過依次播出每個段、根據每個表示的起始時間將文件內的局部時戳映射到全局呈現時間便可構成整個呈現。應注意，貫穿本說明書對「段」的引述應被理解為包括作為文件下載協議請求(包括例如HTTP請求)的結果完全或部分地從存儲介質構造或讀取或者以其他方式獲得的任何數據對象。例如，在HTTP的情形中，數據對象可被存儲在駐留於連接到HTTP伺服器或構成HTTP伺服器一部分的盤或其他存儲介質上的實際文件中，或者數據對象可由響應於 HTTP請求而執行的CGI腳本或其他動態地執行的程序來構造。除非另行指出，否則術語「文件」和「段」在本文中同義地使用。在HTTP的情形中，段可被視為HTTP請求響應的實體主體。術語「呈現」和「內容項」在本文中同義地使用。在許多示例中，呈現是具有定義的「播出」時間的音頻、視頻或其他媒體呈現，但其他變型也是可能的。除非另行指出，否則術語「塊」和「片斷」在本文中同義地使用且一般指代有索引的最小的數據聚集。基於可用的索引法，客戶端可在不同的HTTP請求中請求片斷的不同部分，或者可在一個HTTP請求中請求一個或更多個連貫片斷或片斷部分。在其中使用基於 ISO基媒體文件格式的段或基於3GP文件格式的段的情形中，片斷典型地指代定義為電影片斷頭部(『moof』 )包和媒體數據(『mdat』 )包的組合的電影片斷。在本文中，為了簡化本文中的描述而假定攜帶數據的網絡是基於分組的，在閱讀本公開之後應認識到，本領域技術人員能將本文中描述的本發明的實施例應用於其他類型的傳輸網絡，諸如連續比特流網絡。在本文中，為了簡化本文中的描述而假定由FEC碼提供對抗數據投遞時間長且可變這一問題的保護，在閱讀本公開之後應認識到，本領域技術人員能將本發明的實施例應用於其他類型的數據傳輸問題，諸如數據的比特翻轉訛誤。例如，在沒有FEC的情況下，若所請求片斷的最後部分比該片斷的先前部分晚到很久或者其抵達時間有很大變動，則內容換臺時間可能是長且可變的，而在使用FEC和並行請求的情況下，僅需要針對片斷所請求的數據的大半抵達後就能恢復該片斷，藉此減少了內容換臺時間以及內容換臺時間上的可變性。在本描述中，可假定待編碼數據(即，源數據)已被分解成可以具有有任何長度(小至單個比特)的等長「碼元」，但對於數據的不同部分而言，碼元可以具有不同長度，例如， 可對不同的數據塊使用不同的碼元大小。在本描述中，為了簡化本文中的描述，假定每次向數據「塊」或「片斷」應用FEC，即 「塊」是用於FEC編碼和解碼目的的「源塊」。客戶端設備可使用本文中描述的段索引法來幫助確定段的源塊結構。本領域技術人員可將本發明的實施例應用於其他類型的源塊結構， 例如源塊可以是片斷的一部分，或者可涵蓋一個或更多個片斷或片斷部分。考慮與塊請求流送聯用的FEC碼典型情況下是系統FEC碼，即源塊的源碼元可作為該源塊的編碼的一部分被包括，並且因此源碼元被傳送。如本領域技術人員將認識到的， 本文中描述的實施例也等同地適用於非系統的FEC碼。系統FEC編碼器從由源碼元構成的源塊生成一定數目的修復碼元，且源碼元和修復碼元中的至少一些的組合便是在信道上發送的表示源塊的經編碼碼元。一些FEC碼對於高效地生成如所需的那麼多的修復碼元而言可能是有用的，諸如「信息加性碼」或「噴泉碼」，且這些碼的示例包括「鏈式反應碼」和「多級鏈式反應碼」。諸如Reed-Solomon碼之類的其他FEC碼可能實際上僅為每個源塊生成有限數目的修復碼元。在這些示例中的許多示例中假定客戶端耦合到媒體伺服器或多個媒體伺服器，且客戶端在信道或多個信道上向該媒體伺服器或該多個媒體伺服器請求流送媒體。然而，更複雜的安排也是可能的。益處示例通過塊請求流送，媒體客戶端維護這些塊請求的時基與向用戶進行媒體播出的時基之間的耦合。該模型可留存以上描述的「下載」模型的優點，同時避免源於媒體播出與媒體投遞之間通常為解耦的一些缺點。該塊請求流送模型利用諸如TCP之類的傳輸協議中可用的速率和擁塞控制機制來確保最大可用帶寬被用於媒體數據。另外，將媒體呈現分成塊允許從一組多種可用編碼中選擇每個經編碼媒體數據塊。該選擇可基於任何數目個準則，包括媒體數據率與可用帶寬的匹配——即使在可用帶寬隨時間改變時亦然，媒體解析度或解碼複雜性與客戶端能力或配置的匹配，或者與諸如語言之類的用戶偏好的匹配。該選擇還可包括對輔助分量的下載和呈現，諸如可訪問性分量、隱藏字幕、字幕、手語視頻等。使用塊請求流送模型的現有系統的示例包括行動網路(Move Network )、微軟流暢流送(Microsoft Smooth Streaming)以及蘋果 iPhone 流送協議。通常，每個媒體數據塊可作為個體文件存儲在伺服器上，且隨後使用諸如HTTP之類的協議協同在伺服器上執行的HTTP伺服器軟體將該文件作為單位來請求。典型地，向客戶端提供元數據文件，元數據文件例如可以為可擴展標記語言(XML)格式或播放列表文本格式或二進位格式，元數據文件描述了在本文檔中通常稱為「表示」的媒體呈現的特徵， 諸如可用編碼(例如，要求的帶寬、解析度、編碼參數、媒體類型、語言)，以及將編碼劃分成塊的方式。例如，元數據可包括每個塊的統一資源定位符(URL)。URL本身可提供諸如以串「http://」來前綴以指示將用於訪問此記載的資源的協議是HTTP的方案。另一示例是 「ftp://」以指示將使用的協議是FTP。在其他系統中，例如可由伺服器響應於來自客戶端的以時間指示媒體呈現中被請求的部分的請求「在運行中」構造媒體塊。例如，在使用方案「http://」的HTTP情形中，對該URL的請求的執行提供請求響應，在該請求響應的實體主體中包含一些特定數據。在網絡中關於如何生成該請求響應的實現可能是十分不同的，這取決於服務此類請求的伺服器的實現。典型地，每個塊可以是能獨立解碼的。例如，在視頻媒體的情形中，每個塊可始於 「查找點」。在一些編碼方案中，查找點被稱為「隨機訪問點」或即「RAP」，儘管並非所有RAP 都會被指定為查找點。類似地，在其他編碼方案中，查找點在H. 264視頻編碼的情形中始於 「獨立數據刷新」巾貞或即「IDR」，儘管並非所有IDR都會被指定為查找點。查找點是視頻(或其他)媒體中解碼器不需要關於先前幀或數據或樣本的任何數據就能開始解碼的位置，而正被解碼的幀或樣本不是以自立方式而是例如作為當前幀與先前幀之間的差異來編碼的情形可能就是需要關於先前幀或數據或樣本的數據的情形。
此類系統中的關注點可能是開始播出流的能力，例如使用個人計算機來解碼和渲染收到的音頻和視頻流並在計算機屏幕上顯示該視頻以及通過內置揚聲器播放該音頻，或者作為另一示例，使用機頂盒來解碼和渲染收到的音頻和視頻流並在電視顯示設備上顯示該視頻以及通過立體聲系統播放該音頻。主要關注點可能是使在用戶決定觀看作為流來投遞的新內容並採取表達該決定的行動(例如，用戶點擊瀏覽器窗口內的連結或遙控設備上的播放按鈕)的時間與內容開始在用戶的屏幕上播放的時間之間的延遲(下文中稱為「內容換臺時間」)最小化。這些關注點中的每一個均可由本文中描述的增強型系統的元素來解決。內容換臺的示例是用戶正觀看經由第一流來投遞的第一內容，並且隨後該用戶決定觀看經由第二流來投遞的第二內容並發起開始觀看第二內容的行動。第二流可以是從與第一流相同或不同的一組伺服器發送的。內容換臺的另一示例是用戶正訪問網站並通過點擊瀏覽器窗口內的連結來決定開始觀看經由第一流投遞的第一內容。以類似方式，用戶可能決定並非從頭，而是從流內的某個時間開始播放內容。用戶指示其客戶端設備查找時間位置並且用戶可能期望所選擇的時間被立刻渲染。使內容換臺時間最小化對於視頻觀看而言是重要的，其允許用戶在搜索和取樣很廣範圍的可用內容時獲得高質量的快速內容衝浪體驗。近期，考慮使用前向糾錯(FEC)碼在傳輸期間保護流送媒體已成為慣例。當在分組網絡(其示例包括網際網路和諸如由諸如3GPP、3GPP2和DVB之類的群體標準化的那些無線網絡)上發送時，源流在被生成或變為可用時被放入分組中，且因此這些分組可用來將源或內容流按其被生成或變為可用的次序攜至接收機。在向這些類型的場景應用FEC碼的典型情形中，編碼器可使用FEC碼來創建修復分組，隨後將這些修復分組作為包含源流的原始源分組的補充來發送。修復分組具有以下性質當發生源分組丟失時，可使用接收到的修復分組來恢復丟失的源分組中包含的數據。 修復分組可被用來恢復完全丟失的丟失源分組的內容，但也可被用來從部分分組丟失中恢復，這些恢復或者是從完全接收到的修復分組或者甚至是從部分接收到的修復分組來進行的。因此，可以使用整體或部分接收到的修復分組來恢復整體或部分丟失的源分組。在其他示例中，所發送的數據可能發生其他類型的訛誤，例如比特值可能翻轉，並且因此修復分組可被用來糾正此類訛誤並提供對源分組儘可能準確的恢復。在其他示例中，源流不一定以分立的分組來發送，而是可代之以例如作為連續比特流來發送。存在可用於提供對源流的保護的FEC碼的許多示例。Reed-Solomon碼是公知的用於在通信系統中進行差錯和擦除糾正的碼。對於例如分組數據網絡上的擦除糾正， Reed-Solomon 碼的公知高效實現使用如在 L. Rizzo 的 「Effective Erasure Codes for Reliable Computer Communication Protocols (用於可靠的計算機通信協議的有效擦除碼)」，計算機通信評論27 O):對-36(1997年4月)(下文稱為「Rizzo」)以及Bloemer等人的「An XOR-Based Erasure-Resilient Coding Scheme (基於異或的擦除回彈編碼方案)」， 技術報告TR-95-48，國際計算機科學協會，加利福尼亞州伯克利市(1995年)(下文稱為 "XOR-Reed-Solomon")中或別處描述的柯西(Cauchy)或範德蒙(Vandermonde)矩陣。FEC碼的其他示例包括LDPC碼、諸如Luby I中描述的那些之類的鏈式反應碼、以及諸如Siokrollahi I中的多級鏈式反應碼。
用於Reed-Solomon碼的變體的FEC解碼過程的示例在Rizzo和 XOR-Reed-Solomon中描述。在那些示例中，解碼可在已接收到充分的源數據分組和修複數據分組之後應用。解碼過程可能是計算密集的，且取決於可用的CPU資源，解碼過程可能要花費與塊中的媒體所跨越的時間長度成比例的相當多的時間來完成。接收機在演算開始接收媒體流與播出該媒體之間所需的延遲時可以計及解碼所需的該時間長度。由於解碼造成的該延遲被用戶感知為其對特定媒體流的請求與開始回放之間的延遲。因此希望使該延遲最小化。在許多應用中，分組可被進一步細分成對其應用FEC過程的碼元。分組可包含一個或更多個碼元(或者不足一個碼元，但通常碼元不會被跨分組群拆分，除非已知分組群之間的差錯條件是高度相關的)。碼元可具有任何大小，但碼元的大小往往至多等於分組的大小。源碼元是編碼要傳送的數據的那些碼元。修復碼元是直接或間接地從源碼元生成的作為源碼元的補充的碼元(即，若全部源碼元都可用且沒有任何修復碼元可用，也能完全恢復出要傳送的數據)。一些FEC碼可以是基於塊的，因為編碼操作取決於塊中的碼元並且可獨立於不在該塊中的碼元。通過基於塊的編碼，FEC編碼器可從塊中的源碼元生成該塊的修復碼元，隨後繼續前往下一個塊且無需參考除了正被編碼的當前塊的源碼元以外的其他源碼元。在傳輸中，包括源碼元的源塊可由包括經編碼碼元(其可以是一些源碼元、一些修復碼元或兩者)的經編碼塊來表示。在存在修復碼元的情況下，在每個經編碼塊中，並非所有源碼元都是需要的。對於一些FEC碼，特別是Reed-Solomon碼，編碼和解碼時間可能會隨著每源塊的經編碼碼元數目的增長而增長到不切實際的地步。因此，在實踐中，每源塊能生成的經編碼碼元總數往往存在切合實際的上限0 是一些應用的大致的切合實際的上限)，尤其是在由定製硬體執行Reed-Solomon編碼或解碼過程的典型情形中，例如，使用作為DVB-H標準的一部分被包括的Reed-Solomon碼來保護流以對抗分組丟失的MPE-FEC過程是在蜂窩電話內的專門硬體中實現的，其限於每源塊總共有255個Reed-Solomon經編碼碼元。由於往往要求將碼元放入分開的分組有效載荷中，因此這對正被編碼的源塊的最大長度設置了切合實際的上限。例如，若分組有效載荷限於IOM字節或更少且每個分組攜帶一個經編碼碼元，則經編碼源塊可至多為255千字節，並且這對於源塊本身的大小當然也是上限。諸如能夠足夠快地解碼源塊以跟上源流送速率、使由FEC解碼引入的解碼等待時間最小化、以及在FEC解碼期間的任何時間點僅使用接收設備上可用CPU的一小部分等其他關注點由本文中描述的元素來解決和應付。需要提供穩健和可伸縮的流送投遞解決方案，其允許系統的組件發生故障而不會不利地影響投遞給接收機的流的質量。塊請求流送系統需要支持對呈現的結構或元數據的改變，例如對可用媒體編碼的數目的改變或是對媒體編碼的參數(諸如比特率、解析度、縱橫比、音頻或視頻編解碼器或編解碼參數)的改變，或是對諸如URL之類的與內容文件相關聯的其他元數據的改變。此類改變可能是出於多個原因而必需的，包括將較大呈現的諸如廣告或不同段之類的來自不同源的內容編輯在一起，作為例如由於配置改變、裝備故障或從裝備故障恢復或其他原因造成的服務基礎設施改變的結果而變得必要的對URL或其他參數的修改。
存在可由持續更新的播放列表文件來控制呈現的方法。由於該文件被持續更新， 因此以上描述的至少一些改變能在這些更新中作出。常規方法的缺點在於客戶端設備必須不斷地檢索(也稱為「輪詢」)播放列表文件，從而對服務基礎設施造成負荷，並且該文件可能沒有被高速緩存得比更新間隔更久，從而使得服務基礎設施的任務困難得多。這由本文中的元素來解決，從而在無需由客戶端對元數據文件進行不斷輪詢的情況下提供以上描述的這種的更新。典型地從廣播分發中知曉的尤其存在於實況服務中的另一問題是缺乏供用戶觀看在比用戶加入節目的時間早時廣播的內容的能力。典型地，本地個人錄製消耗不必要的本地存儲，或者在客戶端沒有調諧到該節目或受到內容保護條例禁止時不可能進行本地個人錄製。網絡錄製和時移觀看是優選的，但要求用戶與伺服器的個體連接以及與實況服務分開的投遞協議和基礎設施，從而造成重複的基礎設施和顯著的伺服器成本。這也由本文中描述的元素來解決。系統概覽參照圖1描述本發明的一個實施例，圖1示出了實施本發明的塊請求流送系統的簡化圖。在圖1中，解說了塊流送系統100，其包括塊供應基礎設施(「BSI」)101，BSI 101 又包括攝取系統103，其用於攝取內容102、製備該內容並將其打包以通過將其存儲在攝取系統103和HTTP流送伺服器104兩者均可訪問的內容存儲110中來由HTTP流送伺服器 104供應。如圖所示，系統100還可包括HTTP高速緩存106。在操作中，諸如HTTP流送客戶端之類的客戶端108向HTTP流送伺服器104發送請求112並從HTTP流送伺服器104或 HTTP高速緩存106接收響應114。在每種情形中，圖1中所示的元素可至少部分地在軟體中實現，其中包括在處理器或其他電子器件上執行的程序代碼。內容可包括電影、音頻、2D平面視頻、3D視頻、其他類型的視頻、圖像、定時文本、 定時元數據或類似物。一些內容可涉及要以定時方式呈現或消費的數據，諸如用於隨正被播出的其他媒體一起呈現輔助信息(臺標識、廣告、股價、Flash 序列等)的數據。也可以使用組合其他媒體和/或超越僅音頻和視頻的其他混合呈現。如圖2中所示，媒體塊可被存儲在塊供應基礎設施101 (1)內，其可以是例如HTTP 伺服器、內容投遞網絡設備、HTTP代理、FTP代理或伺服器、或其他某種媒體伺服器或系統。 塊供應基礎設施101 (1)連接到網絡122，網絡122可以是例如諸如網際網路之類的網際協議 (「IP」)網絡。塊請求流送系統客戶端被示為具有6個功能組件，即塊選擇器123，其被提供以上描述的元數據並執行從由該元數據指示的多個可用塊之中選擇要請求的塊或部分塊的功能；塊請求器124，其接收來自塊選擇器123的請求指令並執行在網絡122上向塊供應基礎設施101(1)發送對指定塊、塊的部分、或多個塊的請求以及接收包括該塊的數據作為回復所必要的操作；以及塊緩衝器125 ；緩衝監視器126 ；媒體解碼器127 ；以及促成媒體消費的一個或更多個媒體換能器128。由塊請求器IM接收到的塊數據被傳遞到存儲媒體數據的塊緩衝器125進行臨時存儲。替換地，接收到的塊數據可如圖1中所示地被直接存儲到塊緩衝器125中。媒體解碼器127由塊緩衝器125來提供媒體數據並對該數據執行向媒體換能器1 提供合適的輸入所必要的變換，媒體換能器128以適合用戶或其他消費的形式來渲染該媒體。媒體換能器的示例包括諸如存在於行動電話、計算機系統或電視中的那些之類的視覺顯示設備，並且還可包括諸如揚聲器或頭戴式送受話器之類的音頻渲染設備。媒體解碼器的示例可以是將在H. 264視頻編碼標準中描述的格式的數據變換成視頻幀的模擬或數字表示(諸如每一幀或樣本有相關聯的呈現時戳的YUV格式像素映射) 的功能。緩衝監視器1 接收關於塊緩衝器125的內容的信息，並且基於該信息以及可能還有其他信息向塊選擇器123提供輸入，該輸入被用來確定對要請求的塊的選擇，如本文中所描述的。在本文中使用的術語中，每個塊具有「播出時間」或「歷時」，其表示接收機以正常速度播放該塊中所包括的媒體要花的時間量。在一些情形中，塊內的媒體的播出可能依賴於已接收到來自先前塊的數據。在罕見的情形中，塊中的一些媒體的播出可能依賴於後續塊，在這種情形中，塊的播出時間是參照該塊內不參照後續塊就能播出的媒體來定義的，且後續塊的播出時間增大該塊內只能在已接收到該後續塊之後才能播出的媒體的播出時間。 由於在塊中包括依賴於後續塊的媒體是罕見的情形，因此在本公開的其餘部分中，假定一個塊中的媒體不依賴於後續塊，但是應注意，本領域技術人員將認識到這種變形可被輕易地添加到以下描述的實施例。接收機可具有諸如「暫停」、「快進」、「倒退」等控制，這些控制可導致塊通過以不同速率播放來被消費，但是若接收機能獲得並解碼每個連貫的塊序列的集總時間等於或少於排除該序列中的最末塊情況下的集總播放時間，則接收機能不停滯地向用戶呈現該媒體。 在本文中的一些描述中，媒體流中的特定位置被稱為該媒體中的特定「時間」，其對應於媒體播出的開始與到達視頻流中的該特定位置的時間之間會流逝的時間。媒體流中的時間或位置是常規概念。例如，在視頻流包括M幀每秒的場合，第一幀可以被稱為具有t = 0. 0 秒的位置或時間，且第241幀可被稱為具有t= 10.0秒的位置或時間。自然，在基於幀的視頻流中，位置或時間無需是連續的，因為該流中從第241幀的第一比特直至第242幀的第一比特之前的每個比特可以全都具有相同的時間值。採用以上術語，塊請求流送系統(BRSQ包括向一個或更多個內容伺服器(例如， HTTP伺服器、FTP伺服器等)作出請求的一個或更多個客戶端。攝取系統包括一個或更多個攝取處理器，其中攝取處理器(實時地或非實時地)接收內容，處理該內容以供BRSS使用並將該內容以及可能還連同由攝取處理器生成的元數據一起存儲在內容伺服器可訪問的存儲中。BRSS還可包含與內容伺服器協作的內容高速緩存。內容伺服器和內容高速緩存可以是常規的HTTP伺服器和HTTP高速緩存，它們接收包括URL的HTTP請求形式的對文件或段的請求，並且這些請求還可包括字節範圍以請求不足由該URL指示的文件或段的全部。 客戶端可包括常規的HTTP客戶端，其作出對HTTP伺服器的請求並且處置對這些請求的響應，其中HTTP客戶端由編制請求、將它們傳遞給HTTP客戶端、獲取來自HTTP客戶端的響應並處理這些響應(或存儲、變換等)以將它們提供給呈現播放器供客戶端設備播出的新穎客戶端系統驅動。典型地，客戶端系統事先並不知道將需要什麼媒體(因為該需要可能取決於用戶輸入、用戶輸入的改變等)，因此其被稱為「流送」系統，因為媒體是一旦被接收到或此後不久就被「消費」的。結果，響應延遲和帶寬約束可能導致呈現的延遲，諸如當流追趕用戶正消費該呈現時所在之處時造成呈現的暫停。為了提供被感知為有良好質量的呈現，可在BRSS中在客戶端或在攝取端或在這兩者處實現多個細節。在一些情形中，所實現的細節是考慮並為應對網絡上的客戶端-伺服器接口來進行的。在一些實施例中，客戶端系統和攝取系統兩者皆知曉該增強，而在其他實施例中，僅一側知曉該增強。在此類實施例中，即使一側並不知曉該增強，整個系統也會受益於該增強，而在其他實施例中，該效益僅在兩側皆知曉該增強的情況下才發生，但在一側不知曉時，其仍無故障地操作。如圖3中解說的，根據各種實施例，攝取系統可實現為硬體與軟體組件的組合。攝取系統可包括可被執行以導致系統執行本文中討論的任何一種或更多種方法的指令集。該系統可實現為計算機形式的專門機器。該系統可以是伺服器計算機、個人計算機(PC)、或能夠執行指定要由該系統採取的行動的指令集(順序或以其他方式)的任何系統。此外，雖然僅示出了單個系統，但是術語「系統」還應被視為包括任何系統集合，這些系統個體地或聯合地執行指令集(或多個指令集)以執行本文中所討論的任何一種或更多種方法。攝取系統可包括攝取處理器302(例如，中央處理單元(CPU))、可存儲執行期間的程序代碼的存儲器304、以及盤存儲306，所有這些均經由總線300彼此通信。該系統可進一步包括視頻顯示單元308(例如，液晶顯示器(LCD)或陰極射線管(CRT))。該系統還可包括字母數字輸入設備310(例如，鍵盤)、以及用於接收內容源並投遞內容存儲的網絡接口設備312。盤存儲單元306可包括其上可存儲實施本文中所描述的任何一個或更多個方法或功能的一個或更多個指令集(例如，軟體)的機器可讀介質。這些指令在其被系統執行期間還可完全或至少部分地駐留在存儲器304內和/或攝取處理器302內，其中存儲器304 和攝取處理器302也構成機器可讀介質。如圖4中解說的，根據各種實施例，客戶端系統可實現為硬體與軟體組件的組合。 客戶端系統可包括能被執行以導致系統執行本文中討論的任何一種或更多種方法的指令集。該系統可實現為計算機形式的專門機器。該系統可以是伺服器計算機、個人計算機 (PC)、或能夠執行指定要由該系統採取的行動的指令集(順序或以其他方式)的任何系統。 此外，雖然僅示出了單個系統，但是術語「系統」還應被視為包括任何系統集合，這些系統個體地或聯合地執行指令集(或多個指令集)以執行本文中所討論的任何一種或更多種方法。客戶端系統可包括客戶端處理器402(例如，中央處理單元(CPU))、可存儲執行期間的程序代碼的存儲器404、以及盤存儲406，所有這些均經由總線400彼此通信。該系統可進一步包括視頻顯示單元408(例如，液晶顯示器(LCD)或陰極射線管(CRT))。該系統還可包括字母數字輸入設備410 (例如，鍵盤)、以及用於發送請求並接收響應的網絡接口設備 412。盤存儲單元406可包括其上可存儲實施本文中所描述的任何一個或更多個方法或功能的一個或更多個指令集(例如，軟體)的機器可讀介質。這些指令在其被系統執行期間還可完全或至少部分地駐留在存儲器404內和/或客戶端處理器402內，其中存儲器 404和客戶端處理器402也構成機器可讀介質。3GPP文件格式的使用
3GPP文件格式或基於ISO基媒體文件格式(諸如MP4文件格式或3GPP2文件格式)的任何其他文件可被用作具有以下特徵的用於HTTP流送的容器格式。每個段中可包括段索引以信令通知時間偏移量和字節範圍，以使得客戶端能下載如所需的恰適文件片或媒體段。整個媒體呈現的全局呈現時基和每個3GP文件或媒體段內的局部時基可準確地對準。一個3GP文件或媒體段內的各個軌跡可被準確地對準。跨各個表示的各個軌跡也可通過將它們之中的每個指派到全局時間線來對準，以使得跨表示的切換可以是無縫的，並且不同表示中的媒體分量的聯合呈現可以同步。文件格式可包含具有以下性質的用於自適應流送的簡檔。所有電影數據可被包含在電影片斷中——「moov」包可以不包含任何樣本信息。音頻和視頻樣本數據可以按與如 TS26. 244中規定的對漸進式下載簡檔的要求類似的要求來被交織。「moov」包可被放在文件開頭處，繼之以也被稱為段索引的片斷偏移量數據，其包含該包容段中的每個片斷或者至少片斷子集的時間偏移量信息以及字節範圍。還有可能使媒體呈現描述引用跟隨在存在的漸進式下載簡檔之後的文件。在這種情形中，客戶端可使用媒體呈現描述簡單地從多個可用版本之中選擇恰適的替換版本。客戶端也可對順應於漸進式下載簡檔的文件使用HTTP部分獲取請求以請求每個替換版本的子集並藉此實現效率略低的形式的自適應流送。在這種情形中，包含漸進式下載簡檔中的媒體的不同表示仍可遵守共同的全局時間線以使得能夠進行跨表示的無縫切換。高級方法概覽在以下小節中，描述了用於改進的塊請求流送系統的方法。應理解，這些改進中的一些改進可在有或沒有這些改進中的其他改進的情況下使用，這取決於應用的需要。在一般操作中，接收機向伺服器或其他發射機作出對特定數據塊或數據塊部分的請求。也被稱為段的文件可包含多個塊並且與媒體呈現的一個表示相關聯。優選地，生成也被稱為「段索引」或「段映射」的索引信息，其提供從播出或解碼時間至段內相應的塊或片斷的字節偏移量的映射。該段索引可被包括在段內，典型地在段開頭處(至少一些段映射在開頭處)且往往很小。段索引也可被設在單獨的索引段或文件中。尤其是在段索引被包含在該段中的情形中，接收機可迅速下載此段映射的一些或全部， 並隨後將其用來確定時間偏移量與文件內同這些時間偏移量相關聯的片斷的相應字節位置之間的映射。接收機可使用字節偏移量來請求來自與特定時間偏移量相關聯的片斷的數據，而不必下載與同感興趣的時間偏移量無關聯的其他片斷相關聯的全部數據。以此方式，段映射或段索引能極大地增進接收機直接訪問段中與感興趣的當前時間偏移量有關的部分的能力，其效益包括改善的內容換臺時間、在網絡條件變化時從一個表示迅速換到另一表示的能力、以及減少浪費網絡資源來下載沒有在接收機處播出的媒體。在考慮從一個表示(本文中稱為「切換自，，的表示)切換到另一表示(本文中稱為「切換到」的表示)的情形中，還可使用段索引來標識「切換到」的表示中的隨機訪問點的開始時間，從而標識在「切換自，，的表示中要請求以確保無縫切換的數據量，此無縫切換的意義是指「切換自」的表示中的媒體被下載到直至使得對「切換到」的表示的播出能從該隨機訪問點無縫地開始的呈現時間。這些塊代表請求方接收機為了生成給該接收機的用戶的輸出所需要的視頻媒體或其他媒體的段。媒體的接收機可以是客戶端設備，諸如當接收機從傳送內容的伺服器接收內容時。示例包括機頂盒、計算機、遊戲機、特殊裝備的電視、手持設備、特殊裝備的行動電話、或其他客戶端接收機。本文中描述了許多高級的緩衝管理方法。例如，緩衝管理方法使得客戶端能請求可及時接收以連續播出的具有最高媒體質量的塊。可變塊大小特徵提高了壓縮效率。具有多個連接以用於向請求方設備傳送塊而同時限制請求頻度的能力提供了改善的傳輸性能。 部分收到的數據塊可被用來繼續媒體呈現。可以為多個塊重用連接而不必在一開始就承諾由該連接負責特定的一組塊。改善了由多個客戶端從多個可能的伺服器之中選擇伺服器的一致性，這減少了近旁伺服器中內容重複的頻度並且提高了伺服器包含整個文件的概率。 客戶端可基於嵌入在關於包含媒體塊的文件的URL中的元數據(諸如可用媒體編碼)來請求這些媒體塊。系統可提供對在能開始內容播而不會在媒體播出中招致後續暫停之前所需的緩衝時間量的演算和最小化。可以在多個媒體塊之間共享可用帶寬，隨著每個塊的播出時間逼近而進行調節，從而在必要的情況下較大份額的可用帶寬可有傾向性地被分配給具有最接近播出時間的塊。HTTP流送可採用元數據。呈現級元數據包括例如流歷時、可用編碼(比特率、編解碼器、空間解析度、幀率、語言、媒體類型)、指向每種編碼的流元數據的指針、以及內容保護 (數字版權管理(DRM)信息)。流元數據可以是關於段文件的URL。段元數據可包括字節範圍對時間信息以用於段內請求以及標識隨機訪問點(RAP) 或其他查找點，其中該信息中的一些或全部可以是段索引或段映射的一部分。流可包括對相同內容的多種編碼。每種包括隨後可被分解成段，其中每一段對應於存儲單位或文件。在HTTP的情形中，段典型地是能由URL引用的資源，並且對此類URL的請求導致返回該段作為請求響應消息的實體主體。段可包括多個畫面群(GoP)。每個GoP 可進一步包括多個片斷，其中段索引提供關於每個片斷的時間/字節偏移量信息，即索引的單位是片斷。可通過並行的TCP連接來請求片斷或片斷部分以提高吞吐量。這可以緩解在共享瓶頸鏈路上的連接時或者在連接由於擁塞而丟失時產生的問題，由此提高投遞的總體速度和可靠性，這能明顯改善內容換臺時間的速度和可靠性。可以藉由過度請求用帶寬換等待時間，但是應注意避免作出對太遠的將來的請求，這會增加匱乏風險。對相同伺服器上的段的多個請求可被管線化(在當前請求完成之前作出下一請求)以避免反覆的TCP啟動延遲。對連貫片斷的請求可被聚集成一個請求。一些CDN偏好大文件並且可在首次看到範圍請求時觸發從原始伺服器來後臺取回整個文件。然而，絕大多數CDN將從高速緩存來服務範圍請求——若數據可用。因此，使客戶端請求的某個部分針對整個段文件可能是有利的。若有必要，這些請求可在以後被取消。有效切換點可以是目標流中的查找點，具體而言例如是RAP。不同的實現是可能的，諸如固定GoP結構或跨流的RAP對準(基於媒體的開頭或基於GoP)。在一個實施例中，段和GoP可跨不同速率的流對準。在該實施例中，GoP可具有可變大小並且可包含多個片斷，但片斷在這些不同速率的流之間並不對準。在一些實施例中，可有利地採用文件冗餘性。在這些實施例中，對每個片斷應用擦除碼以生成該數據的冗餘版本。優選地，源格式化不因使用FEC而改變，且可作為攝取系統中的附加步驟生成包含FEC修複數據的例如作為源表示的從屬表示的附加修復段並使其可用。僅使用片斷的源數據就能夠重構該片斷的客戶端可僅向伺服器請求該段內的該片斷的源數據。若伺服器不可用或者與伺服器的連接較慢——這可能是在請求源數據之前或之後確定的，則可請求來自修復段的關於該片斷的附加修複數據，這減少了用於可靠地投遞足以恢復該片斷的數據的時間，從而有可能使用FEC解碼以使用收到的源數據和修複數據的組合來恢復該片斷的源數據。此外，若片斷變得緊急，即其播出時間變得迫近，則可以請求附加修複數據以允許恢復該片斷，這增加了鏈路上用於該片斷的數據份額，但比關掉該鏈路上的其他連接以釋放帶寬更高效。這還可以緩解由於使用並行連接造成的匱乏風險。片斷格式可以是存儲著的具有通過實時傳輸控制協議RTCP達成的音頻/視頻同步的實時傳輸協議(RTP)分組流。段格式也可以是存儲著的具有通過MPEG-2TS內部時基達成的音頻/視頻同步的 MPEG-2TS分組流。使用信令和/或塊創津來使流送更高效在塊請求流送系統中可以使用或不使用數種特徵以提供改善的性能。性能可涉及不停滯地播出呈現、在帶寬約束內獲得媒體數據、和/或在客戶端、伺服器和/或攝取系統處有限的處理器資源內這樣做的能力。現在將描述這些特徵中的一些。段內的索引為了編制對電影片斷的部分獲取請求，可向客戶端告知文件或段內的片斷中所包含的所有媒體分量在解碼或呈現時間的字節偏移量和開始時間、以及還有哪些片斷始於或包含隨機訪問點(且因此適合用作替換表示之間的切換點)，其中該信息往往被稱為段索引或段映射。在解碼或呈現時間的開始時間可直接表達或者可表達為相對於參考時間的 Δ。該時間和字節偏移量索引信息可能每電影片斷需要至少8位元組數據。作為示例， 對於具有500ms電影片斷的單個文件內所包含的2小時電影，這將會是總共約112千字節數據。在開始呈現時下載該數據的全部可能導致顯著的附加啟動延遲。然而，該時間和字節偏移量數據可被階層式編碼，從而客戶端能迅速找到與呈現中希望開始的點有關的小時間塊和偏移量數據。該信息也可分布在段內，以使得對段索引的某種細化可與媒體數據交織地放置。注意，若表示是按時間分段成多個段的，則使用該階層式編碼可能是不必要的，因為每個段的完整的時間和偏移量數據可能已經十分小。例如，若段是一分鐘而非以上示例中的2小時，則時間-字節偏移量索引信息約為1千字節數據，其通常可裝進單個TCP/IP 分組內。有不同選項可能用於向3GPP文件添加片斷時間和字節偏移量數據首先，可出於此目的使用電影片斷隨機訪問包(「MFRA」)。MFRA提供表，其可輔助讀者使用電影片斷來尋找文件中的隨機訪問點。為支持該功能，MFRA順帶地包含帶有隨機訪問點的MFRA包的字節偏移量。MFRA可被放在文件末尾處或附近，但並非必需如此。通過從文件末尾掃描電影片斷隨機訪問偏移量包並使用其中的大小信息，就能夠定位到電影片斷隨機訪問包的開頭。然而，將MFRA放在末尾來進行HTTP流送典型地需要至少3到4個HTTP請求來訪問合意數據至少一個用於從文件末尾請求MFRA，一個用於獲得MFRA並且最後一個用於獲得該文件中的合意片斷。因此，放在開頭可能是可取的，因為這樣就可在單個請求中與第一媒體數據一起下載mfra。另外，對HTTP流送使用MFRA可能是效率不高的，因為「MFRA」中除了時間和moof_偏移量以外的其他任何信息都是不需要的，且指定偏移量而非長度可能需要更多比特。其次，可以使用項定位包(ILOC)。「IL0C」通過定位元數據資源的包容文件、它們在該文件內的偏移量及其長度來提供該文件或其他文件中的元數據資源的目錄。例如，系統可將所有被外部引用的元數據資源整合到一個文件中，相應地重新調整文件偏移量和文件引用。然而，「IL0C」旨在給出元數據的位置，因此可能很難使其與真正的元數據共存。最後且可能最適合的是規定稱為時間索引包(「TIDX」)的新包，其專用於以高效方式提供確切的片斷時間或歷時以及字節偏移量。這在下節中更詳細地描述。具有相同功能性的替換包可以是段索引包(「SIDX」)。在本文中，除非另行指出，否則這兩者可以是可互換的，因為兩種包皆提供了以高效方式提供確切的片斷時間或歷時以及字節偏移量的能力。以下提供TIDX與SIDX之間的差異。如何互換TIDX包和SIDX包應當是明顯的，因為這兩種包均實現段索引。段索引段具有標識出的開始時間和標識出的字節數。多個片斷可被級聯成單個段，且客戶端可發出標識該段內與所請求的片斷或片斷子集相對應的具體字節範圍的請求。例如， 在使用HTTP作為請求協議時，HTTP範圍頭部可用於此目的。該辦法要求客戶端能訪問該段的「段索引」，其指定不同片斷在該段內的位置。該「段索引」可作為元數據的一部分來提供。該辦法具有以下結果與在每個塊被保持在單獨的文件中的辦法相比，需要創建和管理的文件少得多。對創建、傳遞和存儲非常大量的文件(比如說對於1小時呈現，其可延伸到好幾千個文件)的管理可能是複雜的且容易出錯，因此減少文件數量代表著優點。若客戶端僅知曉段的較小部分的合意開始時間，則它可請求整個文件，隨後從頭至尾讀取該文件以確定恰適的播出起始位置。為了提高帶寬利用率，段可包括索引文件作為元數據，其中索引文件映射個體塊的字節範圍與這些塊所對應的時間範圍，稱為段索引或段映射。該元數據可被格式化為XML數據或者它們可以是二進位的，例如遵循3GPP文件格式的原子和包結構。索引可以是簡單的，其中每個塊的時間和字節範圍相對於文件的開始是絕對的，或者它們可以是階層式的，其中一些塊被編組成父塊(且這些父塊被編組成祖父塊，等等)且給定塊的時間和字節範圍是相對於該塊的父塊的時間和/或字節範圍來表達的。示例索引映射結構在一個實施例中，媒體流的一個表示的原始源數據可被包含在一個或更多個在本文中被稱為「媒體段」的媒體文件中，其中每個媒體段包含用於回放該媒體的連續時間段的媒體數據，例如5分鐘的媒體回放。圖6示出了媒體段的示例整體結構。在每個段內，在源段開頭或遍布整個源段，還可存在包括時間/字節偏移量段映射的索引信息。一個實施例中的時間/字節偏移量段映
射可以是時間/字節偏移量對的列表(T (0),B(O)), (T(l),B(I)).....(T⑴，B⑴).....
(T(n)，B(n))，其中T(i-l)代表該段內相對於該媒體在所有媒體段中的初始開始時間用於回放第i個媒體片斷的開始時間，T(i)代表第i個片斷的結束時間(且因此代表下一片斷的開始時間)，並且字節偏移量B(i-l)是該源段內相對於該源段開頭第i個媒體片斷開始之處的數據的開頭的相應字節索引，且B(i)是第i個片斷的相應結束字節索引(且因此是下一片斷的首個字節的索引)。若段包含多個媒體分量，則可以絕對方式為該段中的每個分量提供T(i)和B (i)，或者它們可相對於用作參考媒體分量的另一媒體分量來表達。在該實施例中，源段中的片斷數目為n，其中η在段與段之間可有所不同。在另一實施例中，段索引中關於每個片斷的時間偏移量可以用第一片斷的絕對開始時間以及每個片斷的歷時來確定。在這種情形中，段索引可以記載第一片斷的開始時間以及該段中所包括的所有片斷的歷時。段索引還可以僅記載片斷子集。在該情形中，段索引記載被定義為一個或更多個連貫片斷的子段的歷時，該子段在包容段的末尾或在下一子段的開頭處結束。對於每個片斷，還可以有指示該片斷是否始於或包含查找點的值，即在某點處，該點之後的媒體皆不依賴於該點之前的任何媒體，且因此自該片斷前行的媒體能獨立於先前片斷地播出。查找點一般而言是媒體中能獨立於所有先前的媒體地開始播出之處的點。圖 6還示出了源段的可能段索引的簡單示例。在該示例中，時間偏移量值以毫秒為單位，且因此該源段的首個片斷自該媒體開頭20秒處開始，且首個片斷具有485毫秒的播出時間。 首個片斷的開始的字節偏移量為0，且首個片斷的末尾/第二片斷的開始的字節偏移量為 50，245，且因此首個片斷的大小為50，245位元組。若片斷或子段並非始於隨機訪問點，但該片斷或子段中包含隨機訪問點，則可以給出開始時間與實際RAP時間之間的解碼時間或呈現時間差。這使得在切換到該媒體段的情形中客戶端能準確地知曉「切換自」的表示需要一直被呈現到的時間。補充地或代替地，可以使用簡單的或階層式的索引、雛菊鏈索引和/或混合索引。由於不同軌跡的樣本歷時可能不是相同的(例如，視頻樣本可能播放33ms，而音頻樣本可能持續80ms)，因此電影片斷中的不同軌跡可能不是在正好相同的時間開始和結束的，即，音頻可能比視頻略早或略遲開始，而在前一片斷中可能正好是相反情形以作為補償。為避免多義性，在時間和字節偏移量數據中指定的時戳可相對於特定軌跡來指定，且此軌跡對於每個表示可以是相同的軌跡。通常這將是視頻軌跡。這允許客戶端在切換表示時能確切地標識下一視頻幀。儘管有上述問題，但在呈現期間可注意維持軌跡時標與呈現時間之間的嚴格關係，以確保流暢播出以及維持音頻/視頻同步。圖7解說了一些示例，諸如簡單索引700和階層式索引702。以下提供包含段映射的包的兩個具體示例，一個稱為時間索引包(『TIDX』』)且一個稱為(『SIDX』』)。該定義遵循根據ISO基媒體文件格式的包結構。用於此類包以定義類似句法且具有相同語義和功能性的其他設計對於讀者應當是明顯的。時間索引包定義包類型『tidx，容器文件強制性的否
數量任何數目0或1時間索引包可提供將文件的某些區域與呈現的某些時間區間相關聯的一組時間和字節偏移量索引。時間索引包可包括目標類型(targettype)欄位，其指示所引用的數據的類型。例如，具有目標類型「moof」的時間索引包提供在時間和字節偏移量兩者意義上對文件中所包含的媒體片斷的索引。具有目標類型「時間索引包(Time Index Box) 」的時間索引包可被用來構造階層式時間索引，從而允許文件的用戶迅速導航至該索引的所需部分。段索引可例如包含以下句法
aligned(8) class TimeIndexBox extends FullB ox('frai') { unsigned int(32) targettype; unsigned int(32) time_reference—track—ID; unsigned int(32) number一of—elements; unsigned int(64) first_element_offset; unsigned int(64) first_element—time;
for(i=l; i <= number一of—elements; i++) {
bit (1) random acces s_flag ； unsigned int(31) length; unsigned int(32) deltaT;
}
}語義targettype (目標類型)為該時間索引包引用的包數據的類型。它可以是電影片斷頭部("moof")或時間索引包(「tidx」)。time-reference_track_id(時間參考軌跡id)指示指定該索引中的時間偏移量時參照的軌跡。number_0f_elementS (元素數目)由該時間索引包索引的元素的數目。firstjiementjffset (首個元素偏移量)首個被索引的元素自該文件的開始起的字節偏移量。firSt_element_time (首個元素時間)首個被索引的元素的開始時間，使用由 「時間參考軌跡id」標識的軌跡的媒體頭部包中指定的時標。random_access_flag(隨機訪問標誌)若元素的開始時間是隨機訪問點則為1。 否則為0。length(長度)被索引的元素以字節計的長度。
deltaT(AT)該元素的開始時間與下一元素的開始時間之間的差量，該時間差是由「時間參考軌跡id」標識的軌跡的媒體頭部包中指定的時標的形式。段索引包段索引包(『sidx』)提供對段中的電影片斷和其他段索引包的緊湊索引。段索引包中有兩個循環結構。第一循環記載子段的第一樣本，即由第二循環引用的第一電影片斷中的樣本。第二循環提供該子段的索引。『sidx』包的容器是該文件或直接是段。句法
aligned(8) class SegmentIndexBox extends FullBox('sidx', version, 0) { unsigned int(32) reference一track一ID; unsigned int(16) track—count; unsigned int(16) reference—count;
for (i=l; i<= track_count; i++) {
unsigned int(32) track—ID;
if (version==0) {
unsigned int(32) decoding time; } else
{
unsigned int(64) decoding time;
}
}
for(i=l; i <= reference count; i++) {
bit (1)reference_type;
unsigned int(31) reference_offset; unsigned int(32) subsegment_duration; bit(l)containsRAP;
unsigned int(31) RAP—delta—time;
}
}
語義reference_track_ID(參考軌跡ID)提供參考軌跡的軌跡ID。traCk_Coimt (軌跡計數)接下來的循環中被索引的軌跡的數目(1或更大)；reference_c0imt (參考計數)由第二循環索引的元素的數目(1或更大)；track_ID(軌跡ID)其軌跡片斷被包括在由該索引標識的首個電影片斷中的那個軌跡的ID ；該循環中有恰好一個「軌跡ID」等於「參考軌跡ID」。decodingjime (解碼時間)由第二循環中的第一項引用的電影片斷中由「軌跡 ID」標識的軌跡中的首個樣本的解碼時間，以該軌跡的時標來表達(如在該軌跡的媒體頭部包的時標欄位中記載的)；referencejype (引用類型)在設為0時指示該引用是對電影片斷(『moof』)包的引用；在設為1時指示該引用是對段索引(『sidx』 )包的引用；referendoffset (引用偏移量)從繼包容段索引包之後的首個字節至被引用包的首個字節的以字節計的距離；subsegmentduration (子段歷時)當引用是對段索引包的引用時，該欄位攜帶該包的第二循環中的「子段歷時」欄位的總和；當引用是對電影片斷的引用時，該欄位攜帶參考軌跡中、所指示的電影片斷以及直至該循環中的下一條目記載的首個電影片斷或該子段末尾(取較早者)的後續電影片斷中的樣本的樣本歷時總和；該歷時以該軌跡的時標來表達(如在該軌跡的媒體頭部包的時標欄位中記載的)；COntainS_RAP(包含RAP):當引用是對電影片斷的引用時，則若該電影片斷內「軌跡ID」等於「參考軌跡ID」的那個軌跡的的軌跡片斷包含至少一個隨機訪問點，那麼該比特可為1，否則該比特設為0;當引用是對段索引的引用時，則僅在該段索引中的任何引用的該比特被設為1時該比特才被設為1，否則設為0 ；RAP_de 1 ta_time (RAP_ Δ時間)若「包含RAP 」為1，則提供隨機訪問點(RAP)的呈現(合成)時間，；若「包含RAP」為0則保留值0。該時間表達為在由該條目記載的子段的首個樣本的解碼時間與「軌跡ID」等於「參考軌跡ID」的軌跡中隨機訪問點的呈現(合成)時間之間的差量。TIDX與SIDX之間的差異SIDX和SIDX就索引而言提供相同的功能性。SIDX的第一循環作為補充還提供首個電影片斷的全局時基，但該全局時基也可被包含在該電影片斷自身中，其或者是絕對的或者是相對於參考軌跡的。SIDX的第二循環實現TIDX的功能性。具體地，SIDX準許具有由「引用類型」所指的每個索引的引用的目標的混合，而TIDX僅僅是要麼只引用IDX要麼只引用MOOF。TIDX中的「元素數目」對應於SIDX中的「引用計數」，TIDX中的「時間參考軌跡ID」對應於SIDX中的「參考軌跡ID」，TIDX中的「首個元素偏移量」對應於第二循環的首個條目中的「引用偏移量」，TIDX中的「首個元素時間」對應於第一循環中的「參考軌跡」的「解碼時間」，TIDX中的 「隨機訪問標誌」對應於SIDX中的「包含RAP」，後者還具有額外的自由——在SIDX中，RAP 可以不一定要放在片斷開始處，且因此需要「RAP_A時間」，TIDX中的「長度」對應於SIDX 中的「引用偏移量」，並且最後TIDX中的AT對應於SIDX中的「子段歷時」。因此，這兩個包的功能性是等效的。
可變塊大小控制和子GoP塊對於視頻媒體而言，視頻編碼結構與供請求的塊結構之間的關係可能是重要的。 例如，若每個塊始於諸如隨機訪問點(「RAP」)之類的查找點且每個塊代表相等的視頻時間段，則視頻媒體中的至少一些查找點的定位是固定的且查找點在視頻編碼內將以有規律的間隔出現。如視頻編碼領域中的技術人員公知的，若查找點是根據視頻幀之間的關係來放置的，並且具體而言若它們被放置在與先前幀幾乎沒有多少共性的幀處，則壓縮效率可得以提高。由此要各塊代表等量時間的要求對視頻編碼構成了約束，從而使得壓縮可能是未臻最優的。希望允許視頻呈現內的查找點的位置由視頻編碼系統來選取，而非要求查找點位於固定位置。允許視頻編碼系統選取查找點得到改善的視頻壓縮，並且因此使用給定的可用帶寬能提供更高的視頻媒體質量，從而得到改善的用戶體驗。當前的塊請求流送系統可能要求所有塊具有相同的歷時(以視頻時間計)，且每個塊必須始於查找點且這因此是現有系統的缺點。現在描述提供勝於上述系統的優點的新穎的塊請求流送系統。在一個實施例中， 視頻分量的第一版本的視頻編碼過程可被配置成選取查找點的位置以力圖優化壓縮效率， 但要求對查找點之間的歷時有最大限度。後一個要求的確限制了編碼過程對查找點的選取且因此降低了壓縮效率。然而，倘若查找點之間的歷時的最大限度不是太小(例如，大於約 1秒)，則壓縮效率的降低與假如查找點要求有規律的固定位置所招致的壓縮效率降低相比是微小的。此外，若對查找點之間的歷時的最大限度是幾秒，則該壓縮效率的降低與查找點的完全自由定位相比一般是微乎其微的。在包括本實施例的許多實施例中，可能有一些RAP不是查找點，即可能有幀是兩個連貫查找點之間的沒有被選取為查找點的RAP，例如由於該RAP在時間上太接近周圍的查找點，或者由於該RAP之前或之後的查找點與該RAP之間的媒體數據量太少。媒體呈現的所有其他版本內的查找點的位置可被約束成與第一(例如，最高媒體數據率)版本中的查找點相同。與允許編碼器自由選取查找點相比，這的確降低了這些其他版本的壓縮效率。使用查找點典型地要求幀是能獨立解碼的，這一般導致該幀的低壓縮效率。不被要求能獨立解碼的幀可參考其他幀中的數據來編碼，這一般而言將使該幀的壓縮效率提高達取決於待編碼幀與參考幀之間的共性量的量。對查找點定位的高效選取優先選取與先前幀具有低共性的幀作為查找點幀，並藉此使得由於以能獨立解碼的方式編碼該幀招致的壓縮效率懲罰最小化。然而，幀與潛在可能的參考幀之間的共性的程度是跨該內容的不同表示而高度相關的，因為原始內容是相同的。因此，令其他變體中的查找點與第一變體中的查找點具有相同位置的約束對於壓縮效率而言並沒有帶來很大差別。查找點結構優選被用來決定塊結構。優選地，每個查找點決定塊的開始，且可能存在涵蓋兩個連貫查找點之間的數據的一個或更多個塊。由於為以良好壓縮進行編碼的目的使得查找點之間的歷時不是固定的，因此不要求所有塊都具有相同的播出歷時。在一些實施例中，塊在內容的各版本之間是對準的——即，若在內容的一個版本中有跨越特定幀群的塊，則在該內容的另一版本中也有跨越相同的幀群的塊。內容的給定版本的各塊不交迭，且內容的每個幀被包含在每個版本的恰好一個塊內。使得能允許高效利用查找點之間的可變歷時以及因此的可變歷時GoP的特徵是可被包括在段中或通過其他手段提供給客戶端的段索引或段映射，即，這是可被提供的與該表示中的此段相關聯的包括該呈現的每個塊的開始時間和歷時的元數據。當用戶已請求該呈現在段內的特定點開始時，客戶端可在確定要在哪個塊開始該呈現時使用該段索引數據。若沒有提供此類元數據，則呈現僅能在內容開頭或在接近合意點的隨機或近似點開始 (例如，通過將所請求的起始點(以時間計)除以平均塊歷時以給出起始塊的索引來選取起始塊)。在一個實施例中，每個塊可作為單獨的文件來提供。在另一個實施例中，多個連貫塊可被聚集成單個文件以構成段。在該第二實施例中，可以提供每個版本的元數據，其包括每個塊的開始時間和歷時以及該塊在此文件內開始處的字節偏移量。該元數據可響應於初始協議請求而提供，即可與段或文件分開地獲得，或者可被包含在與塊本身相同的文件或段內，例如位於文件開頭處。如對於本領域技術人員將清楚的，該元數據可以諸如gzip或 Δ編碼之類的壓縮形式或以二進位形式來編碼，以減少向客戶端傳輸該元數據所需的網絡資源。圖6示出了段索引的示例，其中塊具有可變大小，且其中塊的範疇是部分GoPdP 一個RAP與下一個RAP之間的媒體數據的部分量。在該示例中，查找點由RAP指示符來指示，其中RAP指示符值1指示該塊始於或包含RAP或查找點，並且其中RAP指示符O指示該塊不包含RAP或查找點。在該示例中，頭三個塊即字節O到157，033構成第一 GoP，其具有 1. 623秒的呈現歷時，其呈現時間從進入內容中的20秒走到21. 623秒。在該示例中，頭三個塊中的第一塊包括0. 485秒的呈現時間，且包括該段中的媒體數據的頭50，245位元組。在該示例中，塊4、5和6構成第二 GoP，塊7和8構成第三GoP，並且塊9、10和11構成第四 GoP0注意，媒體數據中可能存在沒有被指定為查找點、且因此在段映射中沒有作為RAP被信令的其他RAP。再次參照圖6，若客戶端或接收機想要訪問始於進入媒體呈現中約22秒的時間偏移量處的內容，則客戶端可首先使用諸如以下更詳細地描述的MPD之類的其他信息來首先確定該相關媒體數據的確在該段內。客戶端可例如使用HTTP字節範圍請求來下載該段的第一部分以獲得段索引，其在本例中只有幾個字節。使用該段索引，客戶端可確定自己應當下載的第一塊是時間偏移量至多為22秒且始於RAP、即實為查找點的首個塊。在該示例中， 儘管塊5具有小於22秒的時間偏移量，即其時間偏移量為21. 965秒，但段索引指示塊5並非始於RAP，且由此基於段索引，客戶端改為選擇下載塊4，因為其開始時間至多為22秒，即其時間偏移量為21. 623秒，且其始於RAP。因此，基於段索引，客戶端將作出始於字節偏移量157,034的HTTP範圍請求。假使段索引不可用，則客戶端可能不得不在下載該數據之前先下載所有之前的 157，034位元組的數據，導致啟動時間或頻道換臺時間長得多，以及浪費地下載了無用的數據。替換地，假使段索引不可用，則客戶端可近似出合意數據在該段內的開始之處，但該近似可能是不良的並且它可能錯過恰適的時間且隨後需要後退，這再次增加了啟動延遲。一般而言，每個塊涵蓋媒體數據的一部分，該部分連同先前各塊一起可由媒體播放器播出。因此，這種成塊結構以及向客戶端信令通知段索引成塊結構(無論包含在段內還是通過其他手段提供給客戶端)的機制能顯著改善客戶端提供快速頻道換臺、以及在面臨網絡變動和中斷時的無縫播出的能力。如由段索引實現的對可變歷時塊以及僅涵蓋GoP 的部分的塊的支持能顯著改善流送體驗。例如，再次參照圖6以及以上描述的其中客戶端想要在進入呈現中約22秒處開始播出的示例，客戶端可通過一個或更多個請求來請求塊 4內的數據並隨後一旦該塊可用就將其饋送給媒體播放器以開始回放。因此，在該示例中， 一旦在客戶端處接收到塊4的42，011位元組，播出就開始，由此實現快速的頻道換臺時間。 若相反在播放將要起動之前需要客戶端先請求整個GoP，則頻道換臺時間將較長，因為有 144，211位元組的數據。在其他實施例中，RAP或查找點也可出現在塊當中，且段索引中可以有指示該RAP 或查找點在塊或片斷內何處的數據。在其他實施例中，時間偏移量可以是塊內的第一幀的解碼時間，而非塊內的第一幀的呈現時間。圖8(a)和8 (b)解說了對跨多個版本或表示對準的查找點結構的可變塊大小控制的示例；圖8(a)解說了在媒體流的多個版本上有對準的查找點的可變塊大小控制，而圖 8(b)解說了在媒體流的多個版本上有非對準的查找點的可變塊大小控制。跨頂部以秒示出時間，且這兩個表示的兩個段的塊和查找點以其相對於該時間線的時基的形式從左到右示出，並且因此所示的每個塊的長度與其播出時間成比例而不是與塊中的字節數目成比例。在該示例中，這兩個表示的兩個段的段索引對於查找點將具有相同的時間偏移量，但查找點之間具有潛在不同數目的塊或片斷，且由於每個塊中的媒體數據量不同，因此塊有不同的字節偏移量。在該示例中，若客戶端想要在約23秒的呈現時間處從表示1切換到表示2，則客戶端可請求直至表示1的段中的塊1. 2，並自塊2. 2起開始請求表示2的段，且因此切換將發生在與表示1中的查找點1. 2重合的呈現處，其與表示2 中的查找點2. 2位於相同的時間。如從前述內容應當清楚的，所描述的塊請求流送系統並不約束視頻編碼要將查找點放置在內容內的特定位置處，並且這緩解了現有系統的問題之一。在以上描述的實施例中，組織成使得相同內容呈現的各種表示的查找點被對準。 然而，在許多情形中，優選放寬該對準要求。例如，有時是這種情形已使用編碼工具生成不具有生成查找點對準的表示的能力的表示。作為另一示例，內容呈現可被獨立地編碼成不同的表示，而不同的表示之間沒有查找點對準。作為另一示例，表示在其具有低速率且更普遍需要切換或者在其包含切換點以支持諸如快進或倒帶或快速查找之類的特技模式時可包含較多查找點。因此，希望提供使得塊請求流送系統能高效且無縫地應對跨內容呈現的各種表示非對準的查找點的方法。在該實施例中，跨表示的查找點的位置可能並不對準。塊被構造成使得新塊始於每個查找點，且因此在呈現的不同版本的塊之間可能沒有對準。此類不同表示之間非對準的查找點結構的示例在圖8(b)中示出。跨頂部以秒示出時間，且這兩個表示的兩個段的塊和查找點以其相對於該時間線的時基的形式從左到右示出，且因此所示的每個塊的長度與其播出時間成比例而不是與塊中的字節數目成比例。在該示例中，這兩個表示的兩個段的段索引對於查找點將具有潛在不同的時間偏移量，並且查找點之間也具有潛在不同數目的塊或片斷，且由於每個塊中的媒體數據量不同，因此塊有不同的字節偏移量。在該示例中， 若客戶端想要在約25秒的呈現時間處從表示1切換到表示2，則客戶端可請求直至表示1的段中的塊1. 3，並自塊2. 3起開始請求表示2的段，且因此切換將發生在與表示2中的查找點2. 3重合的呈現處，其位於表示1中塊1. 3的播出當中，且因此塊1. 2的媒體中的一些將不被播出(儘管塊1. 3的沒被播出的幀的媒體數據可能已被加載到接收機緩衝器中以用於塊1. 3的其他被播出的幀的解碼)。在該實施例中，塊選擇器123的操作可被修改以使得每當它被要求從不同於先前所選版本的表示選擇塊時，其第一幀不晚於上次所選塊的最末幀之後的幀的最晚塊被選取。該最近描述的實施例可消除約束除第一版本以外的其他版本內的查找點位置的要求，且因此提高了這些版本的壓縮效率，從而對於給定的可用帶寬得到更高質量的呈現並且這是改善的用戶體驗。進一步的考慮是執行跨內容的多個編碼(版本)的查找點對準功能的視頻編碼工具可能並非普遍可用，因此該最近描述的實施例的優點在於可以使用目前可用的視頻編碼工具。另一優點在於內容的不同版本的編碼可並行進行而完全無需不同版本的編碼過程之間的協調。另一優點在於內容的附加版本可在稍後的時間被編碼並被添加到呈現，而不必向編碼工具提供具體查找點位置的列表。一般而言，在畫面被編碼為畫面群(GoP)的場合，序列中的第一畫面可以是查找點，但並非總是必需如此。最優塊劃分塊請求流送系統中的一個關注問題是例如視頻媒體之類的經編碼媒體的結構與用於塊請求的塊結構之間的交互。如視頻編碼領域中的技術人員將知曉的，往往是這種情形每個視頻幀的經編碼表示所需的比特數目有時實際上逐幀變化。因此，收到數據量與由該數據編碼的媒體歷時之間的關係可能不是直截了當的。此外，在塊請求流送系統內將媒體數據分成塊增加了進一維的複雜性。具體而言，在一些系統中，塊的媒體數據可能在整個塊被接收到之前不會被播出，例如，使用擦除碼的塊內的媒體數據布局或者塊內的媒體樣本之間的依存性就可能導致這種性質。由於塊大小與塊歷時之間的這些複雜交互以及可能需要在開始播出之前接收整個塊，因此客戶端系統通常採納保守辦法，其中在播出開始之前緩衝媒體數據。此類緩衝導致頻道換臺時間很長並且因此用戶體驗不良。I^kzad描述了「塊劃分方法」，這些方法是基於數據流的底層結構來決定如何將數據流劃分成毗連塊的新穎且高效的方法，且I^akzad進一步描述了這些方法在流送系統的上下文中的若干優點。現在描述本發明將I^akzad的塊劃分方法應用於塊請求流送系統的進一步實施例。該方法可包括將待呈現媒體數據安排成大致的呈現時間次序，以使得媒體數據的任何給定元素(例如，視頻幀或音頻樣本)的播出時間與任何毗鄰媒體數據元素的播出時間相差小於所設閾值。如此排序的媒體數據按I^akzad的話來說可被視為數據流，且應用於該數據流的任何I^akzad方法標識該數據流的塊邊界。任一對毗鄰塊邊界之間的數據按本公開的話來說被視為「塊」，且本公開的方法被應用以提供該媒體數據在塊請求流送系統內的呈現。如本領域技術人員在閱讀本公開之際將清楚的，Pakzad中公開的方法的若干優點由此可在塊請求流送系統的上下文中實現。如I^akzad中描述的，對段的塊結構(包括涵蓋部分GoP或涵蓋一個以上GoP的部分的塊)的確定會影響客戶端實現快速頻道換臺時間的能力。在I^kzad中，提供了在給出目標啟動時間的情況下將提供塊結構和目標下載速率的方法，該塊結構和目標下載速率將確保若客戶端在任何查找點開始下載表示並在該目標啟動時間已流逝之後開始播出，則只要在每個時間點該客戶端已下載的數據量至少為目標下載速率乘以自下載開始以來流逝的時間，那麼播出就將無縫地繼續。有利的是使客戶端能訪問目標啟動時間和目標下載速率，因為這向客戶端提供了確定何時開始在最早的時間點播出該表示的手段，並且只要下載滿足上述條件就允許客戶端繼續播出該表示。因此，稍後描述的方法提供了用於在媒體呈現描述內包括目標啟動時間和目標下載速率的手段，從而其可被用於上述目的。媒體旱.現數據樽型圖5解說了圖1中所示的內容存儲的可能結構，包括段和媒體呈現描述(「MPD」) 文件，以及MPD文件內的段分解、時基和其他結構。現在將描述MPD結構或文件的可能實現的細節。在許多示例中，MPD被描述為文件，但也可以使用非文件結構。如其中解說的，內容存儲110裝有多個源段510、MPD 500和修復段512。MPD可包括時段記錄501，時段記錄501又可包括表示記錄502，表示記錄502包含諸如對初始化段 504和媒體段505的引用之類的段信息503。圖9 (a)解說了示例元數據表900，而圖9 (b)解說了 HTTP流送客戶端902如何在與HTTP流送伺服器906的連接上獲得元數據表900和媒體塊904的示例。在本文中描述的方法中，提供包括關於客戶端可用的媒體呈現的表示的信息的 「媒體呈現描述」。表示可以是替換性的，替換性的意義是指客戶端選出不同替換項之一，或者它們可以是互補性的，互補性的意義是指客戶端選擇其中若干個表示、每個表示可能也來自一組替換項，並且聯合地呈現這些表示。表示可有利地被指派到群，其中客戶端被編程或配置成理解對於一群中的表示，它們各自是彼此的替換項，而來自不同群的表示使得能聯合地呈現一個以上表示。換言之，若群中有一個以上表示，則客戶端從該群挑選一個表示，從下一群挑選一個表示等等以構成呈現。描述表示的信息可有利地包括所應用的媒體編解碼器的詳情，包括解碼該表示所需的那些編解碼器的簡檔和等級、視頻幀率、視頻解析度以及數據率。接收媒體呈現描述的客戶端可使用該信息來事先確定表示是否適合解碼或呈現。這代表了優點，因為若區別信息將僅被包含在表示的二進位數據中，則將必需請求來自所有表示的二進位數據並解析和提取相關信息才能發現關於其適用性的信息。這多個請求以及對數據的解析並附提取可能要花一些時間，這會導致啟動時間很長並且因此用戶體驗不良。此外，媒體呈現描述可包括基於時辰來限制客戶端請求的信息。例如對於實況服務，客戶端可被限於請求呈現中接近「當前廣播時間」的部分。這代表了優點，因為對於實況廣播，可能希望從服務基礎設施中清空比當前廣播時間早所設閾值以上廣播的內容的數據。這對於服務基礎設施內的存儲資源的重複使用而言是可取的。這還可能取決於所提供的服務類型而變為可取的，例如，在一些情形中，由於接收客戶端設備的某個訂閱模型，可使得呈現僅有實況可用，而可使得其他媒體呈現有實況和點播可用，並可使得其他呈現對於第一類客戶端設備僅有實況可用，對於第二類客戶端設備僅有點播可用，以及對於第三類客戶端設備有實況或點播的組合可用。(下文)「媒體呈現數據模型」小節中描述的方法允許向客戶端通知此類策略，從而客戶端對於服務基礎設施中可能不可用的數據可避免作出請求並調節對用戶的供應。作為替換方案，例如，客戶端可向用戶呈現該數據不可用的通知。
在本發明的進一步實施例中，媒體段可順應於IS0/IEC 14496-12或衍生規範中描述的ISO基媒體文件格式(諸如3GPP技術規範26. 244中描述的3GP文件格式)。(上文)「3GPP文件格式的使用」這一小節描述了對ISO基媒體文件格式的新穎增強，從而準許在塊請求流送系統內高效地使用該文件格式的數據結構。如該參考文獻中描述的，可在文件內提供信息從而準許媒體呈現的時間段與文件內的字節範圍之間快速且高效的映射。 媒體數據本身可根據IS0/IEC14496-12中定義的電影片斷構造來結構化。提供時間和字節偏移量的該信息可被階層式地結構化或被結構化為單個信息塊。該信息可在文件開始處提供。使用如「3GPP文件格式的使用」這一小節中描述的高效編碼來提供該信息導致客戶端能迅速檢索該信息，例如在塊請求流送系統使用的文件下載協議是HTTP的情形中使用 HTTP部分獲取請求來迅速檢索該信息，這導致很短的啟動、查找或流切換時間且因此導致改善的用戶體驗。媒體呈現中的表示是同步在全局時間線上的，以確保跨表示(典型地為替換項) 的無縫切換，並且確保兩個或更多個表示的同步呈現。因此，自適應HTTP流送媒體呈現內的各表示中所包含的媒體的樣本時基可跨多個段與連續的全局時間線相關。包含多種類型的媒體(例如，音頻和視頻)的經編碼媒體塊對於不同類型的媒體可具有不同的呈現結束時間。在塊請求流送系統中，此類媒體塊可按使每種媒體類型被連續地播放的方式來連貫播出，且因此來自一個塊的一種類型的媒體樣本可能在前一塊的另一類型的媒體樣本之前播出，這在本文中被稱為「連續塊拼接」。作為替換，此類媒體塊可按以下方式播放一個塊的任何類型的最早樣本在前一塊的任何類型的最晚樣本之後播放， 這在本文中被稱為「非連續塊拼接」。當這兩個塊包含來自相同內容項和相同表示的按順序編碼的媒體時或在其他情形中，連續塊拼接可能是恰適的。典型地，在一個表示內，在拼接兩個塊時可以應用連續塊拼接。這是有利的，因為可以應用現有編碼，且可以在無需使媒體軌跡在塊邊界處對準的情況下進行分段。這在圖10中解說，其中視頻流1000包括塊1202 和其他塊，帶有諸如RAP 1204之類的RAP。媒體呈現描述媒體呈現可被視為HTTP流送伺服器上的結構化的文件集合。HTTP流送客戶端可下載充分的信息以向用戶呈現流送服務。替換表示可包括一個或更多個3GP文件或3GP文件的部分，其中這些3GP文件遵循3GPP文件格式或至少遵照一組定義明確的能容易地轉換自或轉換成3GP文件的數據結構。媒體呈現可由媒體呈現描述來描述。媒體呈現描述(MPD)可包含元數據，客戶端能使用該元數據來構造恰適的文件請求，例如HTTP獲取請求，以在恰適的時間訪問處該數據並向用戶提供流送服務。媒體呈現描述可提供充分的信息以供HTTP流送客戶端選擇恰適的3GPP文件和文件片。信令通知客戶端可訪問的單位被稱為段。媒體呈現描述尤其可包含如下元素和屬性等。媒體呈現描述(MediaPresentationDescription)元素封裝供HTTP流送客戶端用來向最終用戶提供流送服務的元數據的元素。「媒體呈現描述」元素可包含以下屬性和元素中的一個或更多個。版本協議的版本號以確保可擴展性。呈現標識符(PresentationIdentifier)使得該呈現可在其他呈現之中被唯一性地標識出來的信息。也可包含私有欄位或名稱。更新頻率(UpdateFrequency):媒體呈現描述的更新頻率，即客戶端可多頻繁地重新加載實際的媒體呈現描述。若該元素不出現，則媒體呈現可以是靜態的。更新媒體呈現可意味著媒體呈現不能被高速緩存。媒體呈現描述URI (MediaPresentationDescriptionURL)用於約定媒體呈現描述的URI。流(Stream)描述流或媒體呈現的類型視頻、音頻或文本。視頻流類型可包含音頻並且可包含文本。服務(Service)描述具有附加屬性的服務類型。服務類型可以是實況或點播。這可以用來通知客戶端超出某個當前時間的查找和訪問是不被準許的。最大客戶端預緩衝時間(MaximumClientPreBufferTime)客戶端可預緩衝媒體流的最大時間量。該時基可將流送與客戶端被限於下載超出該最大預緩衝時間的漸進式下載區別開。該值可以不出現，指示沒有預緩衝意義上的限制可應用。安全保護區間實況服務(&ifetyGuardIntervalLiveService)關於伺服器上的實況服務的最大周轉時間的信息。向客戶端提供了在當前時間有哪些信息已可訪問的指示。若預期客戶端和伺服器按UTC時間操作且不提供緊密的時間同步，則該信息可能是必需的。時移緩衝器深度(TimeShiftBufferD印th)關於客戶端在實況服務中kel相對於當前時間回移多遠的信息。藉由該深度的擴展，無需在服務供應中作出特定改變也可準許時移觀看和追看服務。準許本地高速緩存(LocalCachingPermitted)該標誌指示HTTP客戶端在已播放所下載的數據之後是否能本地高速緩存該數據。實況呈現區間(LivePresentationlnverval)通過指定開始時間(MartTimes) 和結束時間(EndTimes)來包含其間呈現可用的時間區間。「開始時間」指示服務的開始時間而「結束時間」指示服務的結束時間。若沒有指定結束時間，則結束時間在當前時間是未知的，且「更新頻率」可確保客戶端能在服務的實際結束時間之前訪問到結束時間。點播可用性區間(OnDemandAvailabilityInterval)該呈現區間指示該服務在網絡上的可用性。可以提供多個呈現區間。HTTP客戶端在任何指定時間窗以外可能不能訪問該服務。通過提供「點播區間」，可指定額外的時移觀看。對於實況服務，該屬性也可出現。倘若對於實況服務該屬性出現，則伺服器可確保在所有所提供的可用性區間期間，客戶端能以點播服務的形式來訪問該服務。因此，「實況呈現區間」不可與任何「點播可用性區間」交迭。MPD文件信息動態(MPDFiIeInfoDynamic)描述媒體呈現中的文件的默認動態構造。更多細節在下文中提供。若對若干或所有替換表示使用相同規則，則在MPD等級上的默認指定可以節省不必要的重複。MPD編解碼器描述(MPDCodecDescription)描述媒體呈現中的主默認編解碼器。 更多細節在下文中提供。若對若干或所有表示使用相同的編解碼器，則在MPD等級上的默認指定可以節省不必要的重複。MPD 移動包頭部大小不變(MPDMoveBoxHeaderSizeDoexNotChange)指示移動包頭部的大小在整個媒體呈現內各個體文件之間是否改變的標誌。該標誌可用來優化下載並且可以僅在特定段格式(尤其是其段包含moov頭部的那些段格式)的情形中才出現。FileURI模式(FileURII^attern)客戶端用來生成對媒體呈現內的文件的請求消息的模式。不同屬性準許為媒體呈現內的每個文件生成唯一性的URI。基URI可以是HTTP URI。替換表示描述表示列表。(AlternativeRepresentation) 「 jt^.封裝一個表示的所有元數據的XML元素。「替換表示」元素可包含以下屬性和元
ο表示ID(ItepresentationID)媒體呈現內該特定替換表示的唯一性ID。靜態文件信息(Fileshfc^tatic)提供一個替換呈現的所有文件的起始時間和 URI的顯式列表。文件列表的該靜態提供可提供對媒體呈現有確切時基描述的優點，但可能不夠緊湊，尤其是如果替換表示包含許多文件。另外，這些文件名稱可具有任意的名稱。動態文件信息(FilesInfoDynamic)提供構造一個替換呈現的起始時間和URI的列表的隱式方式。該文件列表的動態提供可提供具有更緊湊表示的優點。若僅提供了起始時間序列，則此處時基優點也成立，但文件名稱將基於文件模式URI(FileI^tternURI)來動態地構造。若僅提供每個段的歷時，則表示是緊湊的並且可適合用在實況服務內，但文件的生成可由全局時基來掌管。AP移動包頭部大小不變(APMoveBoxHeaderSizeDoesNotChange)指示移動包頭部的大小在替換描述內各個體文件之間是否改變的標誌。該標誌可用來優化下載並且可以僅在特定段格式(尤其是其段包含moov頭部的那些段格式)的情形中才出現。AP編解碼器描述(APCodecDescription)描述替換呈現中的文件的主編解碼器。媒體描述元素媒體描述(MediaDescription)可封裝該表示中所包含的媒體的所有元數據的元素。具體而言，它可包含關於該替換呈現中的軌跡以及推薦的軌跡編組(若適用)的信息。「媒體描述」屬性包含以下屬性軌跡描述(TrackDescription)封裝該表示中所包含的媒體的所有元數據的XML 屬性。「軌跡描述」屬性包含以下屬性軌跡ID(TrackID)替換表示內的軌跡的唯一性ID。這可以用在軌跡是編組描述的一部分的情形中。比特率(Bitrate)軌跡的比特率。軌跡編解碼器描述(TrackCodecDescription)包含關於該軌跡中使用的編解碼器的所有屬性的XML屬性。「軌跡編解碼器描述」屬性包含以下屬性媒體名稱(MediaName)定義媒體類型的屬性。媒體類型包括「音頻」、「視頻」、「文本」、「應用」和「消息」。編解碼器(Codec):包括簡檔和等級的編解碼器類型。語言標記(LanguageiTag)語言標記(若適用)。最大寬度(MaxWidth)、最大高度(MaxHeight)對於視頻而言，是指被包含的視頻以像素計的高度和寬度。
採樣率(SamplingRate)對於音頻而言的採樣率。群描述(GroupDescription)基於不同參數向客戶端提供對恰適編組的推薦的屬性。群類型(GroupType)基於該類型，客戶端可決定如何編組軌跡。媒體呈現描述中的信息有利地被HTTP流送客戶端用來在恰適的時間執行對文件 /段或其部分的請求，以選擇來自例如在接入帶寬、顯示能力、編解碼器能力等等以及諸如語言等用戶偏好的意義上匹配其能力的勝任表示的段。此外，由於「媒體呈現描述」描述了時間對準且被映射到全局時間線的表示，因此客戶端在正在進行的媒體呈現期間還可以使用MPD中的信息來發起恰適的行動以跨表示進行切換、聯合地呈現各表示、或在媒體呈現內進行查找。信令通知段開始時間表示可按時間被拆分成多個段。一個段的最後片斷與下一段的下一片斷之間存在軌跡間時基問題。此外，在使用有恆定歷時的段的情形中，存在另一個時基問題。對每個段使用相同歷時可具有MPD既緊湊又呈靜態的優點。然而，每個段可能仍始於隨機訪問點。因此，要麼可將視頻編碼約束成在這些特定點提供隨機訪問點，要麼實際的段歷時可能沒有像在MPD中指定的那樣精確。可能希望流送系統對視頻編碼過程不施加不必要的限制，且因此第二選項可能是優選的。具體而言，若在MPD中將文件歷時指定為d秒，則第η個文件可始於時間(n-l)d 處或緊隨其後的隨機訪問點。在該辦法中，每個文件可包括關於該段的在全局呈現時間意義上的確切開始時間的信息。信令通知這一點的三種可能方式包括(1)第一，將每個段的開始時間限制成如在MPD中指定的確切時基。但由此媒體編碼器對於IDR幀的放置可能不具有任何靈活性且文件流送可能要求特殊編碼。(2)第二，為每個段向MPD添加確切開始時間。對於點播情形，MPD的緊湊性可能降低。對於實況情形，這可能要求對MPD的定期更新，這會降低可伸縮性。(3)第三，在MPD中向段添加全局時間或相對於該表示的宣稱開始時間或該段的宣稱開始時間的確切開始時間，向段添加的意義是指段包含該信息。它可被添加至專用於自適應流送的新包。該包還可包括如由「TIDX」或「SIDX」包所提供的信息。該第三辦法的結果是在查找這些段之一的開頭附近的特定位置時，客戶端可以基於MPD來選取包含所請求的查找點的那個段的後續段。該情形中的簡單反應可以是將查找點前向移至檢索到的段的開始(即，移至查找點之後的下一個隨機訪問點)。通常，至少每幾秒就提供隨機訪問點 (且使得它們更不頻繁往往幾乎獲得不到多少編碼增益)且因此在最差情形中，查找點可被移到比指定處晚幾秒。替換地，客戶端在檢索該段的頭部信息時可確定所請求查找點實際上是在前一段中並改為請求該段。這可能導致不時地增加執行查找操作所需的時間。可訪問段的列表媒體呈現包括一組表示，每個表示提供對原始媒體內容的某個不同版本的編碼。 這些表示本身有利地包含關於該表示相比於其他參數的區別參數的信息。它們還顯式地或隱式地包含可訪問段的列表。段可被區別為僅包含元數據的不受時間影響的段和主要包含媒體數據的媒體段。媒體呈現描述(「MPD」)有利地標識每個段並向每個段指派不同的屬性，要麼隱式地要麼顯式地進行。有利地指派給每個段的屬性包括期間段可訪問的時段、藉以可訪問段的資源和協議。此外，媒體段被有利地指派諸如該段在媒體呈現中的開始時間、以及該段在媒體呈現中的歷時之類的屬性。在媒體呈現如有利地由媒體呈現描述中的屬性(諸如點播可用性區間)指示的那樣為「點播」類型的場合，則媒體呈現描述典型地描述整個段並且還提供這些段何時可訪問以及這些段何時不可訪問的指示。段的開始時間有利地相對於媒體呈現的開始來表達，以使得在不同時間開始回放相同媒體呈現的兩個客戶端能使用相同的媒體呈現描述以及相同的媒體段。這有利地提高了高速緩存這些段的能力。在媒體呈現如有利地由媒體呈現描述中的屬性(諸如「服務」屬性)指示的那樣為「實況」類型的場合，則包括媒體呈現的超出實際時辰的部分的段一般不被生成或者至少不可訪問，儘管這些段在MPD中作了完整描述。然而，有了媒體呈現服務為「實況」類型的指示，客戶端可基於MPD中包含的信息以及MPD的下載時間來產生對以壁鍾時間計的客戶端內部時間「現在」而言可訪問的段連同時基屬性的列表。伺服器有利地在使得資源可訪問從而在壁鍾時間「現在」用MPD的實例操作的參考客戶端能訪問該資源的意義上操作。具體地，參考客戶端基於MPD中包含的信息以及MPD的下載時間產生對以壁鍾時間計的客戶端內部時間「現在」而言可訪問的段連同時基屬性的列表。隨著時間前進，客戶端將使用相同的MPD並且將創建能用來連續地播出該媒體呈現的新的可訪問段列表。因此，伺服器可在段實際上能訪問之前在MPD中宣告這些段。這是有利的，因為其減少了對 MPD的頻繁更新和下載。假定通過諸如「靜態文件信息」之類的元素中的播放列表顯式地描述了或者通過使用諸如「動態文件信息」之類的元素隱式地描述了各自具有開始時間tS的段的列表。以下描述使用「動態文件信息」來生成段列表的有利方法。基於該構造規則，客戶端能訪問每個表示r的URI的列表(在本文中稱為FileURI (r，i))以及索引為i的每個段的開始時間
tS(r, i) ο使用MPD中的信息來創建段的可訪問時間窗可使用以下規則來執行。對於如有利地由諸如「服務」之類的屬性指示的那樣類型為「點播」的服務，若在客戶端處的當前壁鍾時間「現在」落在如有利地由諸如「點播可用性區間」之類的MPD元素表達的任何可用性範圍內，則該點播呈現的所有被描述的段皆是可訪問的。若在客戶端處的當前壁鍾時間「現在」落在任何可用性範圍之外，則該點播呈現的被描述段皆是不可訪問的。對於如有利地由諸如「服務」之類的屬性指示的那樣類型為「實況」的服務，開始時間tS(r，i)有利地以壁鍾時間來表達可用性時間。可用性開始時間可推導為是事件的實況服務時間與伺服器處用於捕捉、編碼和發布的一些周轉時間的組合。該過程的時間可例如在MPD中指定，例如使用在MPD中指定為「安全保護區間實況服務」的安全保護區間tG來指定。這將提供UTC時間與HTTP流送伺服器上的數據可用性之間的最小差異。在另一實施例中，MPD顯式地指定MPD中的段的可用性時間而不提供作為事件實況時間與周轉時間之差的周轉時間。在以下描述中，假定任何全局時間被指定為可用性時間。實況媒體廣播領域中的普通技術人員在閱讀本描述之後可從媒體呈現描述中的合適信息推導出該信息。
若在客戶端處的當前壁鍾時間「現在」落在有利地由諸如「實況呈現區間」之類的 MPD元素表達的實況呈現區間的任何範圍之外，則該實況呈現的被描述的段皆是不可訪問的，若在客戶端處的當前壁鍾時間「現在」落在實況呈現區間內，則該實況呈現的被描述的段中的至少某些段可能是可訪問的。對可訪問段的限制由以下值來掌管壁鍾時間「現在」(如客戶端可用的)。例如在媒體呈現描述中指定為「時移緩衝器深度」的所準許的時移緩衝器深度 tTSBo客戶端在相對事件時間、可能僅被允許請求開始時間tS(r，i)落在(現在-tTSB) 至「現在」的區間中或者落在使得歷時為d的段的結束時間也被包括(從而得到區間(現在-tTSB-d)至「現在」)的區間中的段。更新 MPD在一些實施例中，伺服器事先並不知道段的文件或段定位符以及開始時間，因為例如伺服器位置將改變，或者媒體呈現包括來自不同伺服器的一些廣告，或者媒體呈現的歷時是未知的，或者伺服器想要混淆後繼段的定位符。在此類實施例中，伺服器可能僅描述已經可訪問或者在發布了 MPD的該實例之後不久便可訪問的段。此外，在一些實施例中，客戶端有利地消費接近MPD中描述的媒體的那些媒體，以使得用戶體驗到所包含的與媒體內容的生成儘可能接近的媒體節目。一旦客戶端預計自己到達MPD中所描述的媒體段的末尾，它就有利地在伺服器已發布描述新媒體段的新MPD的預期下請求MPD的新實例以繼續連續播出。伺服器有利地生成MPD的新實例並更新MPD以使得客戶端能依賴該規程進行連續更新。伺服器可使自己的MPD更新規程連同段生成和發布適配於其行為舉止如普通客戶端可能的行為舉止的參考客戶端的規程。若MPD的新實例僅描述很短的時間提前量，則客戶端需要頻繁地請求MPD的新實例。這可能由於不必要的頻繁請求而導致可伸縮性問題以及不必要的上行鏈路和下行鏈路話務。因此，有關係的是，一方面要描述儘可能遠地進入將來的段而不必使它們已可訪問，另一方面要使MPD中未預見的更新能表達新伺服器位置、準許插入諸如廣告之類的新內容或提供編解碼器參數的改變。此外，在一些實施例中，媒體段的歷時可能很小，諸如在幾秒的範圍中。媒體段的歷時有利地是靈活的，以便調節到可針對投遞或高速緩存性質來優化的合適段大小、補償實況服務中的端對端延遲或應對段存儲或投遞的其他方面、或出於其他原因。尤其是在段與媒體呈現歷時相比很小的情形中，則需要在媒體呈現描述中描述顯著量的媒體段資源和開始時間。結果，媒體呈現描述的大小可能很大，這會不利地影響媒體呈現描述的下載時間且因此影響媒體呈現的啟動延遲以及還有接入鏈路上的帶寬使用。因此，有利的是不僅準許使用播放列表來描述媒體段列表，且還準許通過使用模板或URL構造規則來進行描述。 模板和URL規則規則在本描述中同義地使用。此外，模板可有利地被用來在實況情形中描述超出當前時間的段定位符。在此類情形中，對MPD的更新本身不是必需的，因為定位符以及段列表是由模板描述的。然而，可能仍會發生未預見的事件，這要求對表示或段的描述進行改變。當來自多個不同源的內容被拼接在一起時，例如在插入了廣告時，可能需要自適應HTTP流送媒體呈現描述上的改變。來自不同源的內容可能在各種方面有所不同。實況呈現期間的另一個原因在於可能有必要改變用於內容文件的URL以提供從一個實況發源伺服器故障轉移到另一個。在一些實施例中，有利的是若MPD被更新，則對MPD的更新被執行以使得經更新的 MPD與先前MPD兼容，兼容的意義是指對於直至先前MPD的有效時間為止的任何時間，參考客戶端以及因此任何所實現的客戶端從經更新的MPD生成的可訪問段列表與其從MPD的該先前實例會生成的可訪問段列表等同地起效。該要求確保了(a)客戶端可立即開始使用新MPD而無需與舊MPD同步，因為新MPD在更新時間之前就與舊MPD兼容；以及(b)更新時間無需與對MPD的實際改變發生的時間同步。換言之，對MPD的更新可事先被廣告，並且一旦有新信息可用，伺服器就能替換掉MPD的舊實例而不必維護MPD的不同版本。對跨用於一組表示或所有表示的MPD更新的媒體時基可存在兩種可能性。(a)現有全局時間線跨該MPD更新而延續(在本文中被稱為「連續MPD更新」)，或(b)當前時間線結束並且新時間線從繼該改變之後的段開始(在本文中被稱為「非連續MPD更新」)。在考慮到媒體片斷的軌跡以及因此段的軌跡由於跨各軌跡的樣本粒度有所不同故而一般並不在相同的時間開始和結束的情況下，這些選項之間的差異可能是明顯的。在正常呈現期間，片斷的一個軌跡的樣本可能在先前片斷的另一軌跡的一些樣本之前被渲染，即片斷之間可能存在某種交迭，儘管單個軌跡內可能沒有交迭。(a)與(b)之間的差異在於是否可允許跨MPD更新實現此類交迭。當MPD更新是由於完全分開的內容的拼接時，此類交迭一般是難以達成的，因為新內容需要新編碼才能與先前內容拼接。因此有利的是提供通過為某些段重啟時間線來非連續地更新媒體呈現、 以及有可能還在更新之後定義一組新的表示的能力。而且，若內容已被獨立地編碼和分段， 則還避免要將時戳調節成擬合在先前內容片的全局時間線內。在更新是出於次要原因，諸如僅僅是向所描述媒體段的列表添加新媒體段時，或者若URL的位置被改變，則交迭和連續更新可被允許。在非連續MPD更新的情形中，先前表示的最末段的時間線在該段中任何樣本的最晚呈現結束時間處結束。下一表示的時間線(或更準確而言，媒體呈現的新部分的第一個媒體段的首次呈現時間，也被稱為新時段)典型地且有利地始於與上一時段的呈現的結束相同的該時刻，以確保無縫和連續播出。這兩種情形在圖11中解說。優選且有利的是將MPD更新限制於段邊界。將此類改變或更新限制於段邊界的基本原理如下。首先，對每個表示的二進位元數據(典型情況下為電影頭部)的改變至少可在段邊界處發生。其次，媒體呈現描述可包含指向段的指針(URL)。在某種意義上，MPD是將與媒體呈現相關聯的所有段文件編組在一起的「傘」數據結構。為了維護該包容關係，每個段可被單個MPD引用，且當該MPD被更新時，有利的是僅在段邊界處更新該MPD。一般不要求段邊界對準，然而對於從不同源拼接的內容的情形以及普遍對於非連續MPD更新，使段邊界對準是有意義的(具體而言，每個表示的最末段可在相同的視頻幀結束並且不可包含呈現開始時間晚於該幀的呈現時間的音頻樣本)。非連續更新隨後可在共同的時刻(稱為時段)開始一組新的表示。該組新的表示的有效性的開始時間例如由時段開始時間來提供。每個表示的相對開始時間被復位為0且該時段的開始時間將該新時段中的該組表示放在全局媒體呈現時間線中。對於連續MPD更新，不要求段邊界對準。每個替換表示的每個段可由單個媒體呈現描述來掌管，且因此對該媒體呈現描述的新實例的更新請求(其一般因預計沒有更多的媒體段在此工作MPD中被描述而被觸發)取決於所消費的這一組表示可發生在不同時間， 其中該組表示包括預計要消非的這組表示。為了支持更一般化情形中MPD元素和屬性的更新，不僅是表示或一組表示，而是可將任何元素與有效性時間相關聯。因此，若MDP的某些元素需要更新，例如在表示的數目改變了或URL構造規則改變了的場合，則通過為元素的多個副本提供不相交的有效性時間，這些元素各自可在指定時間被分別更新。有效性有利地與全局媒體時間相關聯，以使得與有效性時間相關聯的被描述元素在媒體呈現的全局時間線的時段裡有效。如以上所討論的，在一個實施例中，有效性時間僅被添加到全組表示。每個全組則構成時段。有效性時間隨後構成該時段的開始時間。換言之，在使用有效性元素的具體情形中，全組表示可在由一組表示的全局有效性時間指示的時間段裡有效。一組表示的有效性時間被稱為時段。在新時段的開始，前一組表示的有效性過期且新一組表示有效。再次注意，有效性時間段優選是不相交的。如上所述，對媒體呈現描述的改變發生在段邊界處，且因此對於每個表示，元素改變實際上發生在下一段邊界處。客戶端隨後可構成有效MPD，其包括媒體的呈現時間內的每個時刻的段列表。在其中塊包含來自不同表示或來自不同內容(例如，來自內容段和廣告)的媒體數據的情形中或在其他情形中，非連續塊拼接可能是恰適的。在塊請求流送系統中可能要求對呈現元數據的改變僅發生在塊邊界處。這齣於實現原因可能是有利的，因為在塊內更新媒體解碼器參數可能比僅在塊之間更新這些參數更加複雜。在該情形中，可有利地指定如上所描述的有效性區間可被解釋成近似的，以使得元素被視為從不早於所指定的有效性區間的開始的第一個塊邊界至不早於所指定的有效性區間的末尾的第一個塊邊界是有效的。以上描述的對塊請求流送系統的新穎增強的示例實施例在稍後給出的為「對媒體呈現的改變」的小節中描述。段歷時信令非連續更新有效地將呈現分成一系列不相交的稱為時段的區間。每個時段具有其自己的時間線用於媒體樣本時基。時段內的表示的媒體時基可有利地通過指定每個時段或時段中的每個表示的段歷時的單獨的緊湊列表來指示。與MPD內的元素相關聯的例如稱為時段開始時間之類的屬性可指定媒體呈現時間內的某些元素的有效性時間。該屬性可被添加到MPD的任何元素(可對元素換上可被指派有效性的屬性)。對於非連續MPD更新，所有表示的段可在非連續點結束。這一般至少意味著該非連續點之前的最末段與先前各段具有不同歷時。信令通知段歷時可涉及指示所有段具有相同的歷時或者為每個段指示單獨的歷時。可能希望具有關於段歷時列表的緊湊表示，這在有許多段具有相同歷時的情形中是高效的。
一個表示或一組表示中的每個段的歷時可有利地用單個串來實現，該串指定了從非連續更新的開始(即該時段的開始)直至MPD中描述的最末媒體段為止的單個區間的所有段歷時。在一個實施例中，該元素的格式是與包含段歷時條目列表的產生式相符的文本串，其中每個條目包含歷時屬性dur以及該屬性的可任選的乘數mult，該乘數指示該表示包含第一條目的個其歷時為第一條目的的段，隨後是第二條目的個其歷時為第二條目的的段，依此類推。每個歷時條目指定一個或更多個段的歷時。若值後面跟有「*」字符和數字， 則該數字指定具有該歷時(以秒計)的連貫段的數目。若不存在乘數符號「*」，則段數目為 1。若存在「*」而沒有後繼數字，則所有後續段具有所指定的歷時且該列表中可能沒有進一步的條目。例如，串「30*」意味著所有段具有30秒的歷時。串「30*12 10.5」指示有12個歷時30秒的段，繼以一個歷時為10. 5秒的段。若針對每個替換表示分開地指定段歷時，則每個區間內的段歷時的總和對於每個表示而言可以是相同的。在視頻軌跡的情形中，該區間在每個替換表示中可結束於相同的幀。本領域普通技術人員在閱讀本公開之際可發現以緊湊方式來表達段歷時的類似和等效途徑。在另一實施例中，由信號「歷時屬性 」來信令通知除了最後一個段以外，對於該表示中的所有段而言段的歷時是恆定的。非連續更新之前的最末段的歷時可以較短， 只要提供了下一非連續更新的開始點或新時段的開始即可，而這則意味著最末段的歷時延及下一時段的開始。對表示元數據的改變和更新指示諸如電影頭部「moov」改變之類的經二進位編碼的表示元數據的改變可按不同方式來完成(a)在MPD中引用的單獨文件中可以對所有表示有一個moov包，(b)在每個替換表示中引用的單獨文件中可以對每個替換表示有一個moov包，(c)每個段可包含moov 包且因此是自含式的，(d)在與MPD—起的一個3GP文件中可以有用於所有表示的moov包。注意在(a)和(b)的情形中，可有利地將單個「moov」與來自上文的有效性概念相組合，組合的意義是指在MPD中可以引用更多的「moov」包，只要其有效性不相交即可。例如，有了時段邊界的定義，舊時段中的『moov』的有效性可隨著新時段的開始而過期。在選項(a)的情形中，對單個moov包的引用可被指派有效性元素。可允許多個呈現頭部，但每個時間僅可有一個呈現頭部有效。在另一實施例中，如以上定義的時段中的整組表示或整個時段的有效性時間可被用作該表示元數據的有效性時間，典型地作為moov 頭部來提供。在選項(b)的情形中，對每個表示的moov包的引用可被指派有效性元素。可允許多個表示頭部，但每個時間僅可有一個表示頭部有效。在另一實施例中，如以上定義的整個表示或整個時段的有效性時間可被用作該表示元數據的有效性時間，典型地作為moov頭部來提供。在選項(c)的情形中，可以不在MPD中添加信令，但可在媒體流中添加附加信令以指示moov包對於任何即將到來的段是否將改變。這在下文「信令通知段元數據內的更新」 這一小節的上下文中進一步解釋。
信令通知段元數據內的更新為了避免頻繁更新媒體呈現描述以獲得關於潛在更新的知識，有利的是連同媒體段一起信令通知任何此類更新。在媒體段本身內可提供附加的一個或多個元素，其可指示有經更新的元數據(諸如媒體呈現描述)可用並且必須在某個時間量內被訪問才能成功地繼續創建可訪問段列表。此外，對於經更新的元數據文件，此類元素可提供文件標識符(諸如URL)或可用來構造文件標識符的信息。經更新元數據文件可包括等於將與該呈現的原始元數據文件中提供的元數據修改成指示有效性區間的元數據、連同也伴隨著有效性區間的附加元數據。此類指示可在媒體呈現的所有可用表示的媒體段中提供。訪問塊請求流送系統的客戶端在檢測到媒體塊內的此類指示之際可使用文件下載協議或其他手段來檢索經更新元數據文件。藉此為客戶端提供了關於媒體呈現描述中的改變以及這些改變將發生或已發生的時間的信息。有利地，每個客戶端僅在此類改變發生時請求經更新媒體呈現描述一次，而非「輪詢」並接收該文件許多次以獲得可能的更新或改變。改變的示例包括表示的添加或移除，對一個或更多個表示的改變，諸如比特率、解析度、縱橫比、所包括的軌跡或編解碼器參數的改變，以及對URL構造規則的改變，例如用於廣告的不同發源伺服器。一些改變可能僅影響與表示相關聯的初始化段，諸如電影頭部 ("moov")原子，而其他改變可能影響媒體呈現描述(MPD)。在點播內容的情形中，這些改變及其時基可以事先知曉且可在媒體呈現描述中信令通知。對於實況內容，改變可能在它們發生的時間點之前是未知的。一個解決方案是允許在特定URL處可用的媒體呈現描述被動態地更新並且要求客戶端定期地請求該MPD以便檢測改變。該解決方案在可伸縮性(發源伺服器負荷以及高速緩存效率)意義上有缺點。 在具有大量觀眾的場景中，高速緩存可能在MPD的先前版本已從高速緩存過期之後並在新版本被接收到之前接收到許多對MPD的請求，且所有這些請求可能被轉發給發源伺服器。 發源伺服器可能需要不斷地處理來自高速緩存的對MPD的每個經更新版本的請求。而且， 這些更新可能不容易與媒體呈現中的改變在時間上對準。由於HTTP流送的優點之一在於利用標準web基礎設施和服務以獲得可伸縮性的能力，因此優選的解決方案可僅涉及「靜態」(即，可高速緩存的)文件而不依賴於客戶端 「輪詢」文件以查看它們是否已改變。討論並提議了用於解決包括媒體呈現描述和二進位表示元數據(諸如自適應 HTTP流送媒體呈現中的「moov」原子)的元數據的更新的解決方案。對於實況內容的情形，在構造MPD時可能不知道MPD或「moov」可能發生改變的時間點。由於出於帶寬和可伸縮性原因一般應當避免頻繁「輪詢IPD以檢查更新，因此對MPD 的更新可在段文件自身中「帶內」地指示，即每個媒體段可具有指示更新的選項。取決於上文的段格式(a)到(c)，可信令通知不同的更新。一般而言，可有利地在段內的信號中提供以下指示MPD可能在請求該表示內的下一段或其開始時間大於當前段的開始時間的任何下一段之前被更新的指示符。更新可事先被宣告，以指示該更新只需要在晚於該下一段的任何段發生。在媒體段的定位符改變了的情形中，該MPD更新還可用來更新二進位表示元數據，諸如電影頭部。另一信號可指示在該段完成時，不應再請求更多將時間提前的段。
在段是根據段格式(C)來格式化，即每個媒體段可包含諸如電影頭部之類的自初始化元數據的情形中，則可添加另一信號，以指示後續段包含經更新的電影頭部(moov)。這有利地允許將電影頭部包括在段中，但該電影頭部僅在若先前段指示電影頭部更新的情況下或在當切換表示時進行查找或隨機訪問的情形中才需要被客戶端請求。在其他情形中， 客戶端可發出對段的字節範圍請求，其排除電影頭部的下載，因此有利地節省了帶寬。在另一實施例中，若信令通知了 MPD更新指示，則該信號還可包含關於經更新的媒體呈現描述的諸如URL之類的定位符。在非連續更新的情形中，經更新的MPD可使用諸如新時段和舊時段之類的有效性屬性來描述更新前後的呈現。這可以有利地被用來準許如以下進一步描述的時移觀看，但還有利地允許MPD更新在其所包含的改變生效之前任何時間被信令通知。客戶端可立即下載新MPD並將其應用於正在進行的呈現。在具體實現中，對媒體呈現描述、moov頭部或呈現結束的任何改變的信令通知可被包含在遵循使用ISO基媒體文件格式的包結構的段格式的規則來格式化的流送信息包中。該包可為任何不同更新提供專門信號。流送信息包定義包類型『sinf，容器無強制性的否數量0或 1。流送信息包包含關於文件是哪個流送呈現的一部分的信息。句法
aligned(8) class StreamingInformationBox extends FullBox('sinf) { unsigned int(32) streaming—information一flags;
III以下是可任選欄位
string mpd location }SXstreaming_information_flags (流送信息標誌)包含以下各項中的O個或更多個的邏輯或0x00000001後續有電影頭部更新0x00000002呈現描述更新0x00000004 呈現結束若且唯若呈現描述更新(!Presentation Description update)標誌被置位時mpd_ location (mpd位置)出現，並且其提供關於新的媒體呈現描述的統一資源定位符。實況服各的MPD更新的示例使用情形假設服務提供方想要使用本文中描述的增強型塊請求流送來提供實況足球比賽。或許幾百萬用戶可能想要訪問該比賽的呈現。該實況事件被請求暫停時的休息或該行動中的其他間歇偶發地打斷，在此期間可加插廣告。典型情況下，對於休息的確切時基完全或幾乎沒有事先通知。服務提供方可能需要提供冗餘的基礎設施(例如，編碼器和伺服器)以在實況比賽期間有任何組件故障情形中能進行無縫轉切。假設用戶Arma在公交車上用她的行動裝置訪問該服務並且該服務立即可用。她旁邊坐著另一用戶Paul，Paul在他的膝上型設備上觀看該比賽。進了球且兩個人在相同的時間慶祝該事件。Paul告訴Anna該比賽中的第一個球甚至更激動人心並且Anna使用該服務從而她能回看30分鐘前的比賽。在看了該進球之後，她回到實況比賽。為了解決該使用情形，服務提供方應當能夠更新MPD，向客戶端信令通知有經更新的MPD可用，並準許客戶端訪問流送服務以使得其能接近實時地呈現該數據。按與段投遞異步的方式對MPD進行更新是可行的，如本文中別處所解釋的。伺服器可向接收機提供MPD在一定時間裡不更新的擔保。伺服器可依賴於當前MPD。然而，當 MPD在某個最小更新期之前就被更新時無需任何顯式信令。完全同步的播出是幾乎難以達成的，因為客戶端可能在對不同的MPD更新實例進行操作因此客戶端可能有漂移。使用MPD更新，伺服器可傳達改變並且客戶端可被提醒有改變，即使在呈現期間亦然。逐段基礎上的帶內信令可被用來指示MPD的更新，因此更新可能被限於段邊界，但在絕大多數應用中這應當是可接受的。可以添加如下的MPD元素，其提供MPD的以壁鍾時間計的發布時間以及添加在段開頭以信令通知要求MPD更新的可任選MPD更新包。該更新可如同MPD那樣階層式地進行。MPD定義，不需要容器、不是強制性的且具有數量0或1。MPD更新包包含關於段是哪個媒體呈現的一部分的信息。示例句法如下
aligned(8) class MPDUpdateBox extends FullB ox('mupe') { unsigned int(3) mpd information flags; unsigned int(l) new location flag; unsigned int(28) latest mpd update time; III以下是可任選欄位
string mpd_location }MPDUpdateBox (MPD更新包)類的各種對象的語義可如下mpd_information_flags(mpd信息標誌)以下各項中的O個或更多個的邏輯或
0x00現在的媒體呈現描述更新0x01將來的媒體呈現描述更新0x02呈現結束0x030x07 保留new_location flag(新位置標誌)若置為 1，則在 mpd_location (mpd 位置)中指定的新位置處有新的媒體呈現描述可用。latest_mpd_update time (最新mpd更新時間)指定相對於最新MPD的MPD發出時間最晚必需進行MPD更新的時間(以ms計)。客戶端可選擇在其與現在之間的任何時間更新MPD。mpd_l0Cati0n(mpd位置)若且唯若「新位置標誌」被置位時出現，且若如此，則 「mpd位置」提供關於新的媒體呈現描述的統一資源定位符。若更新所使用的帶寬成問題，則伺服器可供應針對某些設備能力的MPD以使得只有這些部分被更新。時移觀看和網絡PVR在時移觀看得到支持時，可能在該會話的壽命時間裡碰巧有兩個或更多個MPD或電影頭部是有效的。在這種情形中，通過在必要時更新MPD，但添加有效性機制或時段概念， 便可對整個時間窗都有有效的MPD存在。這意味著伺服器可確保任何MPD和電影頭部在落在用於時移觀看的有效時間窗內的任何時間段上都是被宣告的。由客戶端來確保其當前呈現時間的可用MPD和元數據是有效的。還可支持僅使用少量的MPD更新來將實況會話遷移到網絡PVR會話。特殊媒體段當在塊請求流送系統內使用IS0/IEC 14496-12的文件格式時的問題在於，如上文描述的，將呈現的單個版本的媒體數據存儲在按連貫時間段安排的多個文件中可能是有利的。此外，將每個文件安排成始於隨機訪問點可能是有利的。此外，可能有利的是在視頻編碼過程期間選取查找點的位置並基於在編碼過程期間作出的對查找點的選取來將呈現分段成各自始於查找點的多個文件，其中每個隨機訪問點可以置於文件開頭也可以不置於文件開頭，但其中每個文件始於隨機訪問點。在具有上述性質的一個實施例中，呈現元數據或媒體呈現描述可包含每個文件的確切歷時，其中歷時例如被認為表示文件的視頻媒體的開始時間與下一文件的視頻媒體的開始時間之差。基於呈現元數據中的該信息，客戶端能夠構造媒體呈現的全局時間線與每個文件內的媒體的局部時間線之間的映射。在另一實施例中，通過改為指定每個文件或段具有相同歷時可有利地減小呈現元數據的大小。然而，在這種情形中並且在根據上述方法來構造媒體文件的場合，每個文件的歷時可能並不嚴格等於在媒體呈現描述中指定的歷時，因為在自該文件開始起恰好過了該指定歷時的點處可能並無隨機訪問點存在。現在描述本發明的又一實施例，用於在即使有以上提及的矛盾的情況下也能實現塊請求流送系統的正確操作。在該方法中，可在每個文件內提供如下的元素，該元素指定該文件內的媒體的局部時間線(其指根據IS0/IEC 14496-12的從時戳0開始的、可供對照著來指定該文件中的媒體樣本的解碼和合成時戳的時間線)向全局呈現時間線的映射。該映射信息可包括全局呈現時間中的與局部文件時間線中的0時戳相對應的單個時戳。該映射信息可替換地包括偏移值，其根據呈現元數據中提供的信息來指定與局部文件時間線中的 0時戳相對應的全局呈現時間與同文件開始相對應的全局呈現時間之間的差量。此類包的示例可例如是軌跡片斷解碼時間(『tfdt』 )包或軌跡片斷調整包 (Hfad')連同軌跡片斷媒體調整(『tfma』 )包。包括段列表牛成的示例客戶端現在將描述示例客戶端。它可被用作伺服器用來確保MPD的恰當生成和更新的參考客戶端。HTTP流送客戶端由MPD中提供的信息來指導。假定客戶端能訪問其在時間T(即它能成功接收MPD的時間)接收到的MPD。確定成功接收可包括客戶端獲得經更新的MPD 或客戶端驗證出該MPD自先前的成功接收以來尚未被更新過。以下介紹示例客戶端行為。為了向用戶提供連續流送服務，客戶端首先解析MPD 並且在計及如以下詳述的可能使用播放列表或使用URL構造規則的段列表生成規程的情況下為每個表示創建在當前系統時間的客戶端本地時間可訪問的段的列表。隨後，客戶端基於表示屬性中的信息以及其他信息(例如可用帶寬和客戶端能力)選擇一個或多個表示。取決於編組，表示可自立呈現或與其他表示聯合呈現。對於每個表示，客戶端獲取諸如該表示的「moov」頭部之類的二進位元數據(若有)、以及所選表示的媒體段。客戶端通過可能使用段列表之類以請求段或段的字節範圍來訪問媒體內容。客戶端可在開始該呈現之前初始地緩衝媒體，並且一旦該呈現已開始，客戶端就通過在計及MPD更新規程的情況下不斷請求段或段部分來繼續消費該媒體內容。客戶端可在計及經更新的MPD信息和/或來自其環境的經更新信息(例如，可用帶寬的改變)的情況下切換表示。以對包含隨機訪問點的媒體段的任何請求，客戶端就可切換到不同的表示。在前移，即當前系統時間(稱為「現在時間」，用於表示相對於呈現的時間)前進時，客戶端消費可訪問的段。隨著「現在時間」中的每次前進，客戶端有可能根據本文中指定的規程擴展每個表示的可訪問段的列表。若尚未到達媒體呈現結束且若當前回放時間落在客戶端預計會用盡任何正在消費或將要消費的表示的MPD中所描述的媒體中的媒體的閾值以內，則客戶端可請求MPD的更新，其帶有新的取回時間「接收時間T」。一旦接收到，客戶端隨後計及有可能經更新的 MPD和新時間T來生成可訪問段列表。圖四解說了在客戶端處不同時間的實況服務的規程。可訪問段列表生成假定HTTP流送客戶端能訪問MPD並且可能想要生成對於壁鍾時間「現在」而言可訪問的段的列表。客戶端以某個精度同步到全局時間基準，但有利地不要求直接同步到 HTTP流送伺服器。每個表示的可訪問段列表優選定義為段開始時間和段定位符的列表對，其中不失一般性，段開始時間可定義為是相對於表示的開始而言的。表示的開始可與時段的開始對準(若應用該概念)。否則，表示開始可在媒體呈現的開始處。客戶端使用例如本文中進一步定義的URL構造規則和時基。一旦獲得了所描述段的列表，該列表被進一步限於可訪問的段，它們可以是完整媒體呈現的段的子集。該構造由時鐘在客戶端「現在」時間的當前值來掌管。一般而言，段僅在一組可用性時間以內的任何「現在」時間可用。對於落在該窗口以外的「現在」時間，則沒有段可用。此外，對於實況服務，假定某個時間「檢查時間(checktime) 」提供關於將此媒體描述到進入將來多遠的信息。 「檢查時間」是在MPD記載的媒體時間軸上定義的；當客戶端的回放時間到達檢查時間時， 其有利地請求新MPD。；當客戶端的回放時間到達檢查時間時，其有利地請求新MPD。
隨後，段列表由檢查時間連同MPD屬性TimeSiiftBufferD^th (時移緩衝器深度) 進一步限制，以使得可用媒體段僅有媒體段的開始時間與表示開始時間之和落入「現在」減去時移緩衝器深度減去上個被描述的段的歷時與檢查時間或「現在」中的較小值之間的區間的那些段。可伸縮塊有時，可用帶寬下降得如此之低，從而接收機處當前正在接收的一個或多個塊變得不大可能被及時完全接收以供不暫停呈現地播出。接收機可能事先檢測到此類情形。例如，接收機可確定自己正在接收每6單位的時間編碼5單位的媒體的塊，並且具有4單位的媒體的緩衝器，因此接收機可能預期不得不將該呈現停滯或暫停到大約M單位的時間以後。在充分注意到此點的情況下，接收機可通過例如放棄當前的塊流之類來對此類情形作出反應並開始請求來自該內容的不同表示(諸如每單位播出時間使用較少帶寬的表示)的一個或多個塊。例如，若接收機切換到其中對於相同大小的塊而言，塊所編碼的視頻時間至少多了 20%的表示，則接收機可能能夠消除停滯直至帶寬情形得到改善的需要。然而，使接收機完全丟棄已從被放棄的表示接收到的數據可能是浪費的。在本文中描述的塊流送系統的實施例中，每個塊內的數據可按以下方式來編碼和安排塊內的數據的某些前綴可被用來在尚未接收到該塊的其餘部分的情況下繼續該呈現。例如，可使用可伸縮視頻編碼的公知技術。此類視頻編碼方法的示例包括H. 264可伸縮視頻編碼(SVC) 或H. 264高級視頻編碼(AVC)的時間可伸縮性。有利地，該方法允許呈現基於塊中已接收到的部分來繼續進行，即使對一個或多個塊的接收例如由於可用帶寬的改變而可能被放棄。 另一優點在於單個數據文件可被用作該內容的多個不同表示的源。這是可能的，例如通過利用選擇塊中與所要求的表示相對應的子集的HTTP部分獲取請求來實現。本文中詳述的一種改進是增強型段可伸縮段映射。該可伸縮段映射包含段中不同層的位置，以使得客戶端能相應地訪問這些段的各部分並提取各層。在另一實施例中，段中的媒體數據被排序，以使得在從段開頭逐漸下載數據的同時段的質量也在提高。在另一實施例中，質量的逐漸提高被應用於段中包含的每個塊或片斷，以使得能進行片斷請求來解決可伸縮辦法。圖12是示出可伸縮塊的一方面的圖。在該圖中，發射機1200輸出元數據1202、 可伸縮層1 (1204)、可伸縮層2 (1206)、以及可伸縮層3 (1208)，其中後者被延誤了。接收機1210隨後可使用元數據1202、可伸縮層1(1204)和可伸縮層2(1206)來呈現媒體呈現 1212。獨立可伸縮性層如以上所解釋的，不希望塊請求流送系統在接收機不能及時接收到媒體數據的特定表示的所請求塊供其播出時不得不停滯，因為這往往造成不良用戶體驗。通過將所選取的表示的數據率限制成比可用帶寬小得多以使該呈現不太可能有任何給定部分不會被及時接收到，就能夠避免、減少或緩解停滯，但該策略具有媒體質量必然比可用帶寬原則上能支持的媒體質量低得多。比可能達到的質量低的呈現也可能被解釋為不良用戶體驗。因此， 塊請求流送系統的設計者在設計客戶端規程、客戶端編程或硬體配置時面臨著以下選擇 要麼請求具有比可用帶寬低得多的數據率的內容版本，在這種情形中用戶可能遭受不良媒體質量；要麼請求具有接近可用帶寬的數據率的內容版本，在這種情形中用戶在呈現期間隨著可用帶寬改變有高概率會遭受暫停。為了處置此類情形，本文中描述的塊流送系統可被配置成獨立地處置多個可伸縮性層，以使得接收機能作出分層請求並且發射機能響應於分層請求。在此類實施例中，每個塊的經編碼媒體數據可被劃分成多個不相交的片(在本文中被稱為「層」)，以使得層組合構成塊的整個媒體數據並且使得已接收到這些層的某些子集的客戶端可執行對該內容的表示的解碼和呈現。在該辦法中，流中的數據的排序使得毗連範圍在質量上呈遞增且元數據反映這一點。可用來生成具有上述性質的層的技術的示例是例如ITU-T標準H. ^4/SVC中描述的可伸縮視頻編碼技術。可用來生成具有上述性質的層的技術的另一示例是如ITU-T標準 H. 264/AVC中提供的時間可伸縮性層技術。在這些實施例中，元數據可在MPD中或在段自身中提供，從而使得能構造對任何給定塊的個體層和/或層組合和/或多個塊的給定層和/或多個塊的層組合的請求。例如，構成塊的層可被存儲在單個文件內且可提供指定該文件內與個體層相對應的字節範圍的元數據。能夠指定字節範圍的文件下載協議(例如HTTP 1. 1)可被用來請求個體層或多個層。此外，如本領域技術人員在查閱本公開之際將清楚的，以上描述的涉及可變大小的塊及可變的塊組合的構造、請求和下載的技術也可應用於本上下文。MA現在描述數個實施例，它們可有利地由塊請求流送客戶端採用以通過使用如以上描述地劃分成層的媒體數據來達成相比於現有技術在用戶體驗上的改善和/或在服務基礎設施容量要求上的減少。在第一實施例中，可應用塊請求流送系統的已知技術，其修改在於內容的不同版本在一些情形中層的不同組合所取代。這就是說在現有系統可提供內容的兩種相異表示的場合，此處描述的增強型系統便可提供兩個層，其中現有系統中內容的一個表示在比特率、 質量以及可能還有其他度量方面類似於增強型系統中的第一層，而現有系統中內容的第二表示在比特率、質量以及可能還有其他度量方面類似於增強型系統中這兩個層的組合。因此，該增強型系統內要求的存儲容量相比於現有系統中要求的存儲容量得以減小。此外，現有系統的客戶端可發出對一個表示或另一表示的塊的請求，而該增強型系統的客戶端可發出對塊的第一層或兩層的請求。因此，這兩個系統中的用戶體驗是相似的。此外，提供了改善的高速緩存，因為即使是對於不同的質量，使用的也是共用的段，由此段被高速緩存的似然性更高。在第二實施例中，採用現在描述的層方法的增強型塊請求流送系統中的客戶端可為媒體編碼的若干層中的每一層維護分開的數據緩衝器。如對於客戶端設備內的數據管理的領域中的技術人員而言將清楚的，這些「分開的」緩衝器可通過為這些分開的緩衝器分配物理上或邏輯上分開的存儲器區域或通過其他技術來實現，其中所緩衝的數據被存儲在單個或多個存儲器區域中且來自不同層的數據的分開是通過使用包含對來自分開的層的數據的存儲位置的引用的數據結構來邏輯地達成的，且因此在下文中，術語「分開的緩衝器」 應當被理解為包括其中相異層的數據可被分開標識的任何方法。客戶端基於每個緩衝器的佔用率發出對每個塊的個體層的請求，例如這些層可按優先級次序排序以使得對來自一個層的數據的請求在優先級次序上較低的層的任何緩衝器的佔用率低於該較低層的閾值的情況下不會被發出。在該方法中，對接收來自優先級次序上較低的層的數據給予優先，以使得若可用帶寬降至比還接收優先級次序上較高的層所要求的帶寬低，則僅請求這些較低層。此外，與不同層相關聯的閾值可以不同，以使得例如較低層具有較高閾值。在可用帶寬改變以使得較高層的數據不能在塊的播出時間之前被接收到的情形中，那麼較低層的數據將必然已被接收到且因此呈現能單單用這些較低層來繼續進行。緩衝器佔用率的閾值可按數據字節、緩衝器中包含的數據的播出歷時、塊數目或任何其他合適的度量的形式來定義。在第三實施例中，第一和第二實施例的方法可被組合以使得提供多個媒體表示， 每個媒體表示包括層的子集(如同第一實施例中一樣)並且第二實施例被應用於表示內的層的子集。在第四實施例中，第一、第二和/或第三實施例的方法可與其中提供內容的多個獨立表示的實施例相組合，以使得例如這些獨立表示中的至少一個獨立表示包括應用第一、第二和/或第三實施例的技術的多個層。高級緩衝管理器與緩衝監視器126(參見圖2、相組合，可使用高級緩衝管理器來優化客戶端方的緩衝器。塊請求流送系統想要確保媒體播出能迅速開始並平滑地繼續，與此同時向用戶或目的地設備提供最大程度的媒體質量。這可能要求客戶端請求具有最高媒體質量、但也能迅速開始並在此後被及時接收以便在不會迫使呈現中發生暫停的情況下播出的塊。在使用高級緩衝管理器的實施例中，該管理器決定要請求媒體數據的哪些塊以及何時作出這些請求。可例如向高級緩衝管理器提供要呈現的內容的元數據集，該元數據包括內容可用的表示列表以及每個表示的元數據。表示的元數據可包括關於表示的數據率以及其他參數的信息，諸如視頻、音頻或其他編解碼器和編解碼參數、視頻解析度、解碼複雜性、音頻語言以及會影響客戶端處對表示的選取的任何其他參數。表示的元數據還可包括該表示已被分段成的塊的標識符，這些標識符提供客戶端請求塊所需的信息。例如，在請求協議是HTTP的場合，該標識符可以是HTTP URL可能還連同附加信息，該附加信息標識由該URL所標識的文件內的字節範圍或時間跨度，該字節範圍或時間跨度標識由該URL所標識的文件內的特定塊。在具體實現中，高級緩衝管理器決定接收機何時作出對新塊的請求並且其自身可能處置該請求的發送。在新穎的方面，高級緩衝管理器根據在使用過多帶寬與流送播出期間用盡媒體之間進行平衡的平衡比的值來對新塊作出請求。緩衝監視器1 從塊緩衝器125接收到的信息可包括對何時接收到媒體數據、已接收到多少、對媒體數據的播出何時已開始或停止、以及媒體播出的速度等的每個事件的指示。基於該信息，緩衝監視器126可演算代表當前緩衝器大小的變量Bsti。在這些示例中，Bsti代表客戶端或其他一個或多個設備緩衝器中包含的媒體量並且可以時間單位來度量，從而Bsti代表假使不再接收更多的塊或部分塊那麼播出該一個或多個緩衝器中所存儲的塊或部分塊所表示的所有媒體將花費的時間量。因此，Bsti代表客戶端處可用但尚未播放的媒體數據按正常播出速度的「播出歷時」。隨著時間流逝，Bsti的值將隨著媒體被播出而減小並且會在每次接收到塊的新數據時增大。注意，出於本解釋的目的，假定塊是在該塊的全部數據在塊請求器IM處可用時被接收的，但也可以改為使用其他措施以例如計及部分塊的接收。在實踐中，對塊的接收可發生在時段上。圖13解說了在媒體被播出並且塊被接收時Bsti的值隨時間的變化。如圖13中所示，對於小於、的時間，B 的值為0，指示尚未接收到數據。在、，第一塊被接收並且B ati 的值增大到等於所接收的塊的播放歷時。此時，播出尚未開始且因此Bsti的值保持恆定直至時間t1;此時第二塊抵達並且B增大該第二塊的大小。此時，播出開始並且B的值開始線性減小直至時間t2，此時第三塊抵達。Bsti的累進以此「鋸齒」方式繼續，每次接收到塊時階躍地增大(在時間t2、t3、t4、 、和、)並在其間隨著數據被播出而平滑地減小。注意，在該示例中，播出是以該內容的正常播出速率來進行的，並且因此塊接收之間的曲線斜率恰好為-1，意味著對於流逝的每一秒真正時間，有一秒的媒體數據被播放。在基於幀的媒體以給定幀數每秒(例如M幀每秒)播出時，斜率-ι將由指示每個個體數據幀的播出的小階躍函數來近似，例如每幀播出時-1Λ4秒的步長。圖14示出了 Bsti隨時間演進的另一個示例。在該示例中，第一塊在、抵達並且播出立即開始。塊抵達和播出繼續直至時間t3，此時Bsti的值到達0。在這種情況發生時， 沒有更多媒體數據可供播出，從而迫使媒體呈現暫停。在時間t4，第四塊被接收並且播放可恢復。該示例因此示出了其中對第四塊的接收晚於所需從而導致播出暫停以及因此導致不良用戶體驗的情形。因此，高級緩衝管理器及其他特徵的目標是降低該事件的概率，與此同時維持高媒體質量。緩衝監視器1 還可演算另一度量Btw (t)，其為給定時間段中接收到的媒體與該時間段的長度之比。更具體而言，Btw (t)等於Tfts/(Ta4-t)，其中Tfts是在自t直至當前時間1 4的該時間段中接收到的媒體量(以其播出時間來度量)，t是比的當前時間早的某個時間。Btw (t)可用于衡量Bsti的變化率。Btw(t) =0是其中自時間t起尚未接收到數據的情形；假定媒體正在播出，則B·自該時間起將減少了(Titt-t)。B_(t) = 1是其中對於時間(Ta4_t)而言接收到的媒體的量與正在播出的量相同的情形；Bsti在時間Ta 4將具有與時間t時相同的值。Btw (t) > 1是其中對於時間(Ta4-t)而言接收到的數據比播出所需的多的情形；Bsti從時間t到時間Ta4將有所增大。緩衝監視器1 進一步演算「Mate (狀態)」值，其可取離散數目個值。緩衝監視器1 進一步裝備有函數NewState (B·，B比率)，在給定B當前的當前值和B比率對於t < T現 4的值的情況下該函數提供新「狀態」值作為輸出。每當Bsti和Btw導致該函數返回不同於 「狀態」的當前值的值時，該新值就被指派給「狀態」並且向塊選擇器123指示該新狀態值。函數NewMate (新狀態)可參照(B當前，B比率(Ta4-Tx))對的所有可能值的空間來求值，其中Tx可以是固定(配置)值，或者可例如由從Bsti的值映射到Tx的值的配置表從Bsti推導出，或者可取決於「狀態」的先前值。向緩衝監視器1 供應該空間的一個或更多個劃分，其中每個劃分包括不相交區域的集合，每個區域用「狀態」值來標註。對函數 「NewState」的求值由此包括標識劃分並確定(Bati，Btw (Tim-Tj)對所落在的區域的操作。返回值由此是與該區域相關聯的標註。在簡單情形中，只提供一個劃分。在更複雜的情形中，劃分可取決於前一次對NewState函數求值時的(BstJ，Btw (Ta在-Tx))對或取決於其他因素。在具體實施例中，以上描述的劃分可基於包含Bsti的數個閾值以及Btw的數個閾
值的配置表。具體而言，令B浦的閾值為B_ (0) =0、B「1).....Β_ (ηι)、Β_ (叫+1) =°ο,
其中Ii1是B當前的非零閾值的數目。令B比率的閾值為B比率閾(0) = O、B比率閾⑴.....B比率閾
(η2)、Β比率w (n2+l) =^ ，其中1!2是8比率的閾值的數目。這些閾值定義了包括(n^l)χ(η2+1) 的單元柵格的劃分，其中第j行的第i個單元對應於其中Bw (i-1) <=BatJ<Bw (i)且 B比率_(j-l) <=B_<B_w(j)的區域。以上描述的柵格的每個單元格諸如通過與存儲在存儲器中的特定值相關聯之類而被標註以狀態值，並且函數NewState隨後返回與由值B 當前和B比率(Ta4-Tx)指示的單元格相關聯的狀態值。在另一實施例中，可令遲滯值與每個閾值相關聯。在該增強型方法中，對函數 NewState的求值可基於使用一組臨時修改的閾值如下構造的臨時劃分。對於小於與在對 NewState的上次求值時所選取的單元格相對應的B 範圍的每個B 閾值，通過減去與該閾值相關聯的遲滯值來減小該閾值。對於大於與在對NewState的上次求值時所選取的單元格相對應的B·范圍的每個B·閾值，通過加上與該閾值相關聯的遲滯值來增大該閾值。 對於小於與在對NewState的上次求值時所選取的單元格相對應的B tw範圍的每個B tt率閾值，通過減去與該閾值相關聯的遲滯值來減小該閾值。對於大於與在對NewState的上次求值時所選取的單元格相對應的Btw範圍的每個Btw閾值，通過加上與該閾值相關聯的遲滯值來增大該閾值。經修改的閾值被用來對NewState的值進行求值並且隨後這些閾值返回其原始值。在閱讀本公開之際，定義空間的劃分的其他方式對於本領域技術人員將變得明顯。例如，劃分可通過使用基於Btw和Bsti的線性組合的不等式，例如α0、α1和α 2為實數值的al*Btw + a2*Bsti彡a O形式的線性不等式閾值來定義，以定義整個空間內的半空間以及將每個不相交集合定義為數個此類半空間的交集。以上描述是為了解說基本過程。如實時編程領域的技術人員在閱讀本公開之際將清楚的，高效實現是可能的。例如，每次將新信息提供給緩衝監視器126時，就有可能演算若例如不接收塊的進一步的數據則NewState將轉移到新值的將來時間。隨後為該時間設置定時器並且在沒有進一步的輸入的情況下，該定時器的期滿將導致新的狀態值被發送給塊選擇器123。因此，只需要在有新信息被提供給緩衝監視器1 時或者在定時器期滿時執行計算，而無需連續地執行。狀態的合適值可為「低」、「穩定」和「滿」。合適的閾值集合和所得單元柵格的示例在圖15中示出。在圖15中，Bsti閾值以毫秒在橫軸上示出，遲滯值在其下方以「+/_值」形式示出。 B 閾值以千分率(即，乘以1000)在縱軸上示出，遲滯值在其下方以「+/_值」形式示出。 「低」、「穩定」和「滿」狀態值分別在柵格單元中被標註為「L」、「S」和「F」。
每當有機會請求新塊時，塊選擇器123就接收到來自塊請求器124的通知。如以上所描述的，向塊選擇器123提供關於可用的這多個塊的信息以及這些塊的元數據，包括例如關於每個塊的媒體數據率的信息。關於塊的媒體數據率的信息可包括該特定塊的實際媒體數據率(S卩，以字節計的塊大小除以以秒計的播出時間)、塊所屬的表示的平均媒體數據率、或為了不暫停地播出該塊所屬的表示在維繫的基礎上需要的可用帶寬的度量、或以上的組合。塊選擇器123基於緩衝監視器1 最新指示的狀態值來選擇塊。在該狀態值為 「穩定」時，塊選擇器123從與先前所選塊相同的表示選擇塊。所選擇的塊是包含該呈現中先前未曾請求過其媒體數據的時段的媒體數據的第一塊(按播出次序)。在該狀態值為「低」時，塊選擇器123從具有比先前所選塊的媒體數據率低的媒體數據率的表示選擇塊。數個因素會影響該情形中對表示的確切選取。例如，塊選擇器123 可被提供對傳入數據的聚集速率的指示並且可選取具有小於該值的媒體數據率的表示。在該狀態值為「滿」時，塊選擇器123從具有比先前所選塊的媒體數據率高的媒體數據率的表示選擇塊。數個因素會影響該情形中對表示的確切選取。例如，塊選擇器123 可被提供對傳入數據的聚集速率的指示並且可選取具有不高於該值的媒體數據率的表示。數個附加因素可能進一步影響塊選擇器123的操作。具體而言，可限制增大所選塊的媒體數據率的頻度，即使緩衝監視器126持續指示「滿」狀態亦然。此外，塊選擇器123 有可能接收到「滿」狀態指示但沒有更高媒體數據率的塊可用(例如，由於上次所選的塊已經對應最高可用媒體數據率)。在這種情形中，塊選擇器123可將下一塊的選擇延遲某個時間，該時間被選取為使得在塊緩衝器125中緩衝的媒體數據總量是上有界的。附加因素可能影響在選擇過程期間考慮的塊集合。例如，可用塊可被限於來自其編碼解析度落在提供給塊選擇器123的特定範圍以內的那些表示的塊。塊選擇器123還可接收來自監視系統的其他方面的其他組件的輸入，所監視的方面諸如是用於媒體解碼的計算資源的可用性。若此類資源變得稀缺，則塊選擇器123可在元數據內指示其解碼的計算複雜性較低的塊(例如，具有較低解析度或幀率的表示一般具有較低解碼複雜性)。以上描述的實施例帶來的實質優點在於，在緩衝監視器126內對NewState函數求值時使用值Btw與僅考慮Bsti的方法相比允許在呈現開始時質量更快地上升。在不考慮B
的情況下，可能在累積了大量緩衝的數據後系統才能選擇具有更高媒體數據率以及因此具有更高質量的塊。然而，當Btw值很大時，這指示可用帶寬遠高於先前接收到的塊的媒體數據率且即使緩衝的數據相對較少(即，Bsti的值很低)，請求有更高媒體數據率以及因此有更高質量的塊仍是安全的。同樣地，若Btw值很低(例如< 1)，這指示可用帶寬已降至先前所請求的塊的媒體數據率之下且因此即使Bsti很高，系統仍將切換到較低的媒體數據率以及因此較低的質量，以例如避免到達B·= 0且媒體的播出停滯的點。這種改善的行為在其中網絡條件以及因此投遞速度可能快速且動態地變化(例如用戶向行動裝置流送) 的環境中可能尤其重要。使用配置數據來指定(Β·，Β_)的值空間的劃分帶來了另一優點。此類配置數據可作為呈現元數據的一部分或通過其他動態手段被提供給緩衝監視器126。在實踐部署中，由於用戶網絡連接的行為在各用戶之間以及對於單個用戶而言隨時間推移而可能高度可變，因此可能很難預測對於所有用戶都將工作良好的劃分。動態地向用戶提供此類配置信息的可能性允許隨時間推移根據累積的經驗來開發良好的配置設置。可變請求大小控制若每個請求針對單個塊且若每個塊編碼短媒體段，則可能需要高頻度的請求。若媒體塊很短，則視頻播出迅速地在塊間移動，這為接收機提供了更頻繁的通過改變表示來調整或改變其所選數據率的機會，從而提高了播出能不停滯地繼續的可能性。然而，高頻度的請求的不利方面在於它們在其中客戶端至伺服器網絡中的可用帶寬受約束的某些網絡上可能是不能維繫的，例如在諸如3G和4G無線WAN之類的無線WAN網絡中，其中從客戶端至網絡的數據鏈路的容量是受限制的或者會由於無線電條件的改變而變為在或短或長的時間段上受限制。高頻度的請求還意味著服務基礎設施的高負荷，這帶來容量要求方面的關聯成本。因此，將希望有高頻度請求的一些效益而沒有所有這些缺點。在塊流送系統的一些實施例中，將高請求頻度的靈活性與低頻度請求相組合。在該實施例中，塊可以如上所描述地構造並且同樣如以上所描述地被聚集成包含多個塊的段。在呈現的開頭，應用以上所描述的其中每個請求引用單個塊或者作出多個並發請求以請求塊的各部分的過程以確保在呈現的開始有快速的頻道換臺時間並且因此有良好的用戶體驗。隨後，當滿足將在以下描述的某個條件時，客戶端可發出在單個請求中涵蓋多個塊的請求。這是可能的，因為這些塊已被聚集成較大文件或段並且可使用字節或時間範圍來請求。連貫的字節或時間範圍可被聚集成單個較大的字節或時間範圍，從而導致單個請求針對多個塊，並且甚至能在一個請求中請求非連續的塊。可由決定是請求單個塊(或部分塊)還是請求多個連貫塊來驅使的一個基本配置是使該決定基於所請求塊是否很可能被播出。例如，若很可能不久將需要換到另一表示，則客戶端最好作出針對單個塊即少量媒體數據的請求。此舉的一個原因在於，若在可能即將要切換至另一表示時作出針對多個塊的請求，那麼該切換可能在該請求的最後幾個塊被播出之前作出。因此，對這最後幾個塊的下載可能延遲了對所切換到的表示的媒體數據的投遞，這可能導致媒體播出停滯。然而，針對單個塊的請求的確導致更高頻度的請求。另一方面，若不大可能不久將需要換到另一表示，則可能優選作出針對多個塊的請求，因為所有這些塊很可能將被播出， 並且這導致較低頻度的請求，從而可以大量上降低請求開銷，典型地在表示中沒有即將來臨的改變的情況下尤其如此。在常規的塊聚集系統中，每個請求中所請求的量不是動態地調整的，即典型地每個請求針對整個文件，或者每個請求針對與表示的文件大致相同的量(有時以時間度量， 有時以字節度量)。因此，若所有請求都較小，則請求開銷較高，而若所有請求都較大，則這增加了媒體停滯事件的機會和/或在選取了較低質量表示以避免不得不隨著網絡條件變化而迅速改變表示的情況下增加了提供較低質量媒體播出的機會。在被滿足時可導致後續請求引用多個塊的條件的示例是對緩衝器大小Bsti的閾值。若Bsti低於該閾值，則發出的每個請求引用單個塊。若Bsti大於或等於該閾值，則發出的每個請求引用多個塊。若發出引用多個塊的請求，則每單個請求中所請求的塊數目可按若干種可能方式之一來決定。例如，該數目可以是常數，例如2。替換地，單個請求中所請求的塊數目可取決於緩衝器狀態並且尤其是取決於BstJ。例如，可以設置數個閾值，其中單個請求中所請求的塊數目是從小於B·的多個閾值中的最高閾值來推導的。在被滿足時可導致請求引用多個塊的條件的另一示例是以上描述的「狀態」值變量。例如，當狀態為「穩定」或「滿」時，則可發出針對多個塊的請求，但當狀態為「低」時，則所有請求可針對一個塊。另一實施例在圖16中示出。在該實施例中，當將發出下一請求時(在步驟1300中決定)，使用當前狀態值和Bsti來決定下一請求的大小。若當前狀態值為「低」、或當前狀態值為「滿」且當前表示不是最高可用的表示(在步驟1310中確定，答案為「是」)，則下一請求被選取為短請求，例如僅針對下一塊(在步驟1320中確定塊並作出請求)。此舉背後的基本原理在於，這些條件是其中很可能很快將有表示改變的條件。若當前狀態值為「穩定」、 或當前狀態值為「滿」且當前表示是最高可用的表示(在步驟1310中確定，答案為「否」)， 則下一請求中所請求的連貫塊的歷時對於某個固定的α <1被選取為與Bsti的α分數成比例(在步驟1330中確定塊，在步驟1340中作出請求)，例如對於α =0.4，若Bsti= 5 秒，則下一請求可針對約2秒的塊，而若Bsti= 10秒，則下一請求可針對約4秒的塊。此舉背後的一個基本原理在於在這些條件下，在與Bsti成比例的時間量裡將不大可能作出向新表示的切換。靈活管線僕,塊流送系統可使用具有例如TCP/IP之類的特定底層傳輸協議的文件請求協議。 在TCP/IP或其他傳輸協議連接的開頭，可能要花某個相當長的時間來達成對全部可用帶寬的利用。這可能導致在每次開始新連接時都有「連接啟動懲罰」。例如，在TCP/IP的情形中，連接啟動懲罰由於初始TCP握手建立連接所花的時間以及擁塞控制協議達成對可用帶寬的完全利用所花的時間兩者而發生。在該情形中，可能希望使用單個連接來發出多個請求，以降低招致連接啟動懲罰的頻度。然而，例如HTTP之類的一些文件傳輸協議不提供並非將傳輸層連接完全關閉而是取消請求的機制，並且因此在建立新連接來代替舊連接時招致連接啟動懲罰。若確定可用帶寬已改變並且改為要求不同的媒體數據率，即決定切換到不同的表示，則發出的請求可能需要被取消。取消發出的請求的另一原因可能是用戶已請求結束媒體呈現並且開始新呈現(或許是在該呈現的不同點的相同內容項、或者或許是新內容項)。如已知的，可通過保持連接打開並對後續請求重用相同的連接來避免連接啟動懲罰，並且如同樣已知的，若在相同的連接上同時發出多個請求(在HTTP的上下文中被稱為 「管線化」的技術)，則連接可保持充分利用。然而，同時地或者更一般地以使得連接上有多個請求在先前請求完成之前發出的方式發出多個請求的缺點可能在於，該連接隨後要負責攜帶對這些請求的響應並且因此若希望改變應當發出的請求，則該連接可能會被關閉—— 若需要取消已發出但不再想要的請求。所發出的請求需要被取消的概率可部分地取決於發出該請求與所請求塊的播出時間之間的時間區間的歷時，部分取決於的意義是指當該時間區間大時，所發出的請求需要被取消的概率也高(因為在該區間期間可用帶寬很可能改變了)。如已知的，一些文件下載協議具有單個底層傳輸層連接可有利地被用於多個下載請求的性質。例如，HTTP具有該性質，因為將單個連接重用於多個請求對於除第一個請求以外的其他請求避免了以上描述的「連接啟動懲罰」。然而，該辦法的缺點在於該連接要負責傳輸每個所發出請求中所請求的數據，且因此若一個或多個請求需要被取消，則要麼該連接可能被關閉，從而在建立取代連接時招致連接啟動懲罰，要麼客戶端可能等待接收不再需要的數據，從而在接收後續數據時招致延遲。現在描述留存連接重用的優點而不招致該缺點並且還附加地提高連接能被重用的頻度的實施例。本文中描述的塊流送系統的實施例被配置成對多個請求重用連接而不必一開始就承諾由該連接負責特定的一組請求。實質上，在現有連接上的已發出的請求尚未完成但接近完成時在該連接上發出新請求。不等待直至現有請求完成的一個原因在於，若先前的請求完成則連接速度可能降級，即，底層TCP會話可能進入空閒狀態或者TCP cwnd變量可能被顯著地減小，藉此顯著降低該連接上發出的新請求的初始下載速度。在發出額外請求之前等待直至接近完成的一個原因在於，因為若新請求是在先前請求完成之前很久就發出的，則新發出的請求可能甚至在某個很長時間段內不開動，並且有可能在新發出的請求開動之前的該時間段期間，作出新請求的決定不再有效，例如由於決定切換表示而導致上述情形。因此，實現該技術的客戶端的實施例將在不減慢連接的下載能力的情況下儘可能晚地在該連接上發出新請求。該方法包括監視響應於在連接上發出的最晚請求在該連接上接收到的字節數目並對該數目應用測試。這可以通過使接收機(或發射機，若適用)配置成進行監視和測試來進行。若測試通過，則可在該連接上發出另一請求。合適的測試的一個示例是接收到的字節數目是否大於所請求數據的大小的固定分數。例如，該分數可以為80%。合適的測試的另一示例基於以下演算，如圖17中所解說的。在該演算中，令R為對該連接的數據率的估計，T為對往返行程時間(「RTT」)的估計，並且X為例如可以是設為0.5與2之間的值的常數的數值因子，其中對R和T的估計在定期的基礎上更新(在步驟1410中更新)。令 S為最晚請求中所請求的數據的大小，B為所請求的數據中接收到的字節數目(在步驟1420 中演算)。合適的測試將是使接收機(或發射機，若適用)執行評估不等式(S-B) <X-R-T 的例程(在步驟1430中測試)，並且若「是」則採取行動。例如，可作出測試以查看是否有另一個請求準備好要在該連接上發出(在步驟1440中測試)，並且若「是」則向該連接發出該請求(步驟1450)並且若「否」則本過程返回步驟1410以繼續更新和測試。若步驟1430 中的測試的結果是「否」，則本過程返回步驟1410以繼續更新和測試。步驟1430中的不等式測試(例如由恰適地編程的元件來執行)導致在待接收的剩餘數據量等於X乘以在一個RTT內以當前估計的接收速率能接收的數據量時發出每個後續請求。數種在步驟1410中估計數據率R的方法是本領域已知的。例如，數據率可估計為 Dt/t，其中Dt是在之前t秒中接收到的比特數目並且其中t可以是例如1秒或0. 5秒或其他某個區間。另一種方法是對傳入數據率的指數加權平均或一階無限衝激響應(IIR)濾波。數種在步驟1410中估計RTT 「T」的方法是本領域已知的。步驟1430中的測試可應用於接口上所有活躍連接的聚集，如以下更詳細地解釋的。
該方法進一步包括構造候選請求列表，將每個候選請求與可向其作出該請求的一組合適伺服器相關聯，並且按優先級次序排序該候選請求列表。候選請求列表中的一些條目可具有相同的優先級。與每個候選請求相關聯的合適伺服器列表中的伺服器由主機名來標識。每個主機名對應於可從域名系統獲得的一組網際協議地址，這是公知的。因此，候選請求列表上的每個可能的請求與一組網際協議地址相關聯，具體而言是與該候選請求的關聯伺服器的關聯主機名的關聯的各組網際協議地址的併集相關聯。每當連接滿足步驟1430 中描述的測試並且該連接上尚未發出新請求時，就選取候選請求列表上與該連接的目的地的網際協議地址相關聯的最高優先級請求，並且在該連接上發出該請求。還將該請求從候選請求列表中移除。候選請求可從候選請求列表移除(取消)，具有高於候選列表上的已有請求的優先級的新請求可被添加到候選列表，並且候選列表上的現有請求的優先級可改變。有哪些請求在候選請求列表上這一動態本質以及其在候選列表上的優先級這一動態本質可取決於何時滿足步驟1430中描述的類型的測試而更改接下來可發出哪些請求。例如，有可能若在某個時間t對步驟1430中描述的測試的回答為「是」，則發出的下一請求將為請求A，而若對步驟1430中描述的測試的回答並非為「是」直至某個時間t' > t，則發出的下一請求將改為是請求B，因為請求A在時間t與t'之間從候選請求列表被移除，或者由於在時間t與t 『之間優先級比請求A高的請求B被添加到候選請求列表，或者由於請求B在時間t時已在該候選列表上但優先級比請求A低，並且在時間t與t'之間，請求B的優先級被改為高於請求A的優先級。圖18解說了候選請求列表上的請求列表的示例。在該示例中，有三個連接，並且候選列表上有6個請求，標示為A、B、C、D、E和F。候選列表上的每個請求可在如所指示的連接子集上發出，例如請求A可在連接1上發出，而請求F可在連接2或連接3上發出。每個請求的優先級也在圖18中標示，並且較低的優先級值指示請求有較高優先級。因此，具有優先級0的請求A和B是最高優先級請求，而具有優先級值3的請求F是候選列表上的請求中的最低優先級。若在該時間點t，連接1通過了步驟1430中描述的測試，則在連接1上發出請求A 或請求B。若改為是連接3在該時間t通過了步驟1430中描述的測試，則在連接3上發出請求D，因為請求D是能在連接3上發出的具有最高優先級的請求。假設對於所有連接，從時間t到某個稍後的時間t'對步驟1430中描述的測試的答案皆為「否」，並且在時間t與t'之間，請求A的優先級從0改變為5，請求B從候選列表被移除，並且具有優先級0的新請求G被添加到該候選列表。隨後，在時間t'，新候選列表可如圖19中所示。若在時間t'連接1通過了步驟1430中描述的測試，則在連接1上發出優先級為 4的請求C，因為它是候選列表上在該時間點能在連接1上發出的的最高優先級請求。假設在該相同的情形中改為在時間t在連接1上本來發出了請求A(其為如圖18 中所示的在時間t對連接1而言兩個最高優先級選擇之一)。由於從時間t到某個稍後的時間t'對於所有連接而言步驟1430中描述的測試的答案皆為「否」，因此連接1仍為在時間t之前發出的請求投遞數據直到至少時間t'，且因此請求A在至少時間t'之前將不會開動。在時間t'發出請求C是比本來在時間t發出請求A更好的決定，因為請求C在t'之後與請求A本來將開動的時間相同的時間開動，並且因為截至該時間，請求C比請求A具有更高優先級。作為另一替換方案，若步驟1430中描述的類型的測試應用於活躍連接的聚集，則可選取其目的地的網際協議地址與候選請求列表上的第一個請求或同所述第一個請求具有相同優先級的另一請求相關聯的連接。有數種方法可用於構造候選請求列表。例如，候選列表可包含代表對呈現的當前表示按時間順序次序的接下來η個數據部分的請求的η個請求，其中對最早數據部分的請求具有最高優先級而對最晚數據部分的請求具有最低優先級。在一些情形中，η可以為1。 η的值可取決於緩衝器大小Bsti，或狀態變量或客戶端緩衝器佔用率的狀態的其他度量。例如，可為B 設置數個閾，並且有值與每個閾相關聯，隨後將η的值取為與小於B 的最高閾相關聯的值。以上描述的實施例確保了靈活地將請求分配給連接，從而確保向重用現有連接給予優待，即使最高優先級請求不適合該連接(因為該連接的目的地IP位址不是分配給與該請求相關聯的任何主機名的那一 IP位址)亦然。η對Bsti或客戶端緩衝器佔用率的狀態或其他度量的依存性確保了在客戶端亟需發出和完成與按時間順序要播出的下一數據部分相關聯的請求時，此類「脫離優先級次序」的請求不被發出。這些方法可有利地與協作式HTTP和FEC相組合。一致件的服各器詵擇如公知的，將使用文件下載協議來下載的文件通常由包括主機名和文件名的標識符來標識。例如，HTTP協議就是這種情形，在該情形中，標識符是統一資源標識符(URI)。 主機名可對應於由各網際協議地址標識的多個主機。例如，這是跨多個物理機器分攤來自多個客戶端的請求負荷的常見方法。具體而言，該辦法常被內容投遞網絡(CDN)採用。在這種情形中，在連接上向任何物理主機發出的請求預期將成功。已知有多種可供客戶端用來從與主機名相關聯的各網際協議地址中進行選擇的方法。例如，這些地址通常經由域名系統提供給客戶端並按優先級次序提供。客戶端隨後可選取最高優先級(第一)網際協議地址。然而，一般而言，客戶端之間就如何作出該選取並沒有協調，因此不同客戶端可能向不同伺服器請求相同的文件。這可能導致相同的文件被存儲在近旁多個伺服器的高速緩存中，這降低了高速緩存基礎設施的效率。這可以由有利地增加請求相同塊的兩個客戶端將向相同伺服器請求該塊的概率的系統來處置。此處描述的新穎方法包括以由要請求的文件的標識符來決定的方式並以使得被呈示了相同或相似的網際協議地址和文件標識符選擇的不同客戶端將作出相同選取的方式從可用網際協議地址中進行選擇。參考圖20來描述該方法的第一實施例。客戶端首先獲得一組網際協議地址IPp
IP2.....IPn，如步驟1710中所示。若如步驟1720中確定的有要針對其發出請求的文件，
則客戶端決定用哪個網際協議地址來發出對該文件的請求，如步驟1730-1770中所決定的。給定一組網際協議地址和要請求的文件的標識符，該方法包括以由該文件標識符所決定的方式排序這些網際協議地址。例如，對於每個網際協議地址，構造出包括該網際協議地址與該文件標識符的級聯的字節串，如步驟1730中所示。向該字節串應用散列函數，如步驟1740中所示，並且根據固定排序，例如數值升序，來排列所得的散列值，如步驟1750中所示，從而引起網際協議地址的排序。相同散列函數可被所有客戶端使用，因此保證對於所有客戶端的給定輸入，該散列函數產生相同的結果。該散列函數可被靜態地配置到客戶端集合中的所有客戶端中，或者客戶端集合中的所有客戶端可在這些客戶端獲得網際協議地址列表時獲得該散列函數的部分或完整描述，或者客戶端集合中的所有客戶端可在這些客戶端獲得文件標識符時獲得該散列函數的部分或完整描述，或者該散列函數可由其他手段確定。該排序中的首個網際協議地址被選取並且該地址隨後被用來建立連接並發出對該文件的全部或部分的請求，如步驟1760和1770中所示。以上方法可在建立新連接以請求文件時應用。它還可在有多個建成的連接可用時應用，並且這些連接中的一個可被選取來發出新請求。此外，當有建成的連接可用並且可從具有相等優先級的候選請求的集合中選取請求時，例如通過以上描述的相同的散列值方法引起對候選請求的排序，並且該排序中首個出現的候選請求被選取。這些方法可被組合以從一組連接和具有相等優先級的請求中同樣通過計算連接與請求的每個組合的散列、根據固定排序對這些散列值進行排序、並選取對請求與連接的組合的集合引起的排序中首個出現的組合來選擇連接和候選請求兩者。該方法出於以下原因具有優點諸如圖1(BSI 101)或圖2(BSI 101)中所示的塊供應基礎設施採取的典型辦法、尤其是CDN通常採取的辦法是提供多個接收客戶端請求的高速緩存代理伺服器。高速緩存代理伺服器可能並未裝有給定請求中所請求的文件並且在這種情形中，此類伺服器典型地將該請求轉發給另一伺服器，接收來自該伺服器的響應 (典型地包括所請求的文件)，並將該響應轉發給客戶端。高速緩存代理伺服器也可存儲 (高速緩存)所請求的文件，從而它能立即響應對該文件的後續請求。以上描述的常用辦法具有以下性質存儲在給定高速緩存代理伺服器上的文件集很大程度上是由該高速緩存代理伺服器已接收到的請求集合來決定的。以上描述的方法具有以下優點。若客戶端集合中的所有客戶端被提供相同的網際協議地址列表，則這些客戶端將對針對相同文件發出的所有請求使用相同的網際協議地址。若存在兩個不同的網際協議地址列表並且每個客戶端被提供這兩個列表之一，則客戶端對針對相同文件發出的所有請求將使用至多兩個不同的網際協議地址。一般而言，若提供給客戶端的網際協議地址列表是相似的，則這些客戶端將對針對相同文件發出的所有請求使用所提供的網際協議地址的小集合。由於近程的客戶端傾向於被提供相似的網際協議地址列表，因此很可能近程客戶端會向這些客戶端可用的高速緩存代理伺服器的僅小部分發出對文件的請求。因此，將只有很小分數的高速緩存代理伺服器高速緩存該文件，這有利地使用於高速緩存該文件的高速緩存資源量最小化。優選地，散列函數具有以下性質很小分數的不同輸入被映射到相同的輸出，且不同輸入被映射到本質上隨機的輸出，以確保對於給定的網際協議地址集合，使網際協議地址中給定的一個地址在由步驟1750產生的經分序列表中為首個地址的文件比例對於該列表中的所有網際協議地址大致相同。另一方面，重要的是該散列函數是確定性的，確定性的意義是指對於給定輸入，該散列函數的輸出對於所有客戶端都相同。以上描述的方法的另一優點如下。假設客戶端集合中的所有客戶端被提供相同的網際協議地址列表。由於該散列函數的剛才描述的這些性質，很可能來自這些客戶端的對不同文件的請求將均勻地跨該組網際協議地址分攤，這進而意味著這些請求將跨高速緩存代理伺服器均勻分攤。因此，用於存儲這些文件的高速緩存資源跨高速緩存代理伺服器均勻分攤，且對文件的請求跨這些高速緩存代理伺服器均勻分攤。因此，該方法提供跨高速緩存基礎設施的存儲平衡和負荷平衡兩者。以上描述的辦法的多種變形為本領域技術人員所知的，並且在許多情形中，這些變形留存了存儲在給定代理上的文件集是至少部分地由該高速緩存代理伺服器已接收到的請求集合決定這一性質。在其中給定主機名解析到多個物理高速緩存代理伺服器的常見情形中，所有這些伺服器將最終存儲任何被頻繁請求的給定文件的副本將會是很常見的。 此類重複可能是不可取的，因為高速緩存代理伺服器上的存儲資源是有限的，且因此文件有時可能會從高速緩存被移除(清空)。此處描述的新穎方法確保了對給定文件的請求以減少這種重複的方式被定向到高速緩存代理伺服器，藉此減少從高速緩存移除文件的需要並且藉此增大任何給定文件存在於該代理高速緩存中(即，尚未從其清空)的可能性。當文件存在於代理高速緩存中時，向客戶端發送的響應更快，這具有減少所請求的文件晚到的概率的優點，所請求文件晚到會導致媒體播出的暫停並且因此導致不良的用戶體驗。此外，當文件不存在於代理高速緩存中時，該請求可被發送給另一伺服器，從而既造成服務基礎設施上又造成伺服器之間的網絡連接上的額外負荷。在許多情形中，請求所發往的伺服器可能位於遙遠位置並且從該伺服器向高速緩存代理伺服器回傳該文件可能招致傳輸成本。因此，此處描述的新穎方法使得這些傳輸成本能得以減少。概率件全文件請求將HTTP協議與範圍請求聯用的情形中特別的關注點是通常用來提供服務基礎設施中的可伸縮性的高速緩存伺服器的行為。雖然HTTP高速緩存伺服器支持HTTP範圍頭部可能是常見的，但不同HTTP高速緩存伺服器的確切行為因實現而變化。大多數高速緩存伺服器實現在文件在高速緩存中可用的情形中從該高速緩存來服務範圍請求。HTTP高速緩存伺服器的常用實現總是將包含範圍頭部的下遊HTTP請求轉發給上遊節點，除非該高速緩存伺服器具有該文件的副本(高速緩存伺服器或原始伺服器)。在一些實現中，對該範圍請求的上遊響應是整個文件，並且該整個文件被高速緩存且從該文件提取對下遊範圍請求的響應並發送該響應。然而，在至少一種實現中，對範圍請求的上遊響應只是範圍請求本身中的數據字節，且這些數據字節不被高速緩存而是只作為對下遊範圍請求的響應被發送。因此，客戶端使用範圍頭部可能的後果是文件本身從不被放入高速緩存且網絡的可取的可伸縮性性質將會丟失。在上述內容中，描述了高速緩存代理伺服器的操作，並且還描述了從作為多個塊的聚集的文件來請求塊的方法。例如，這可以通過使用HTTP範圍請求頭部來達成。此類請求在下文被稱為「部分請求」。現在描述另一實施例，其在塊供應基礎設施101不提供對 HTTP範圍頭部的完全支持的情形中具有優點。通常，塊供應基礎設施內的伺服器例如內容投遞網絡支持部分請求，但可能不在本地存儲(高速緩存)中存儲對部分請求的響應。此類伺服器可通過將請求轉發給另一伺服器來履行部分請求，除非完整文件被存儲在本地存儲中，在後一種情形中可在不將請求轉發給另一伺服器的情況下發送響應。利用以上描述的對塊聚集的新穎增強的塊請求流送系統在塊供應基礎設施顯現該行為的情況下可能性能不良，因為實為部分請求的所有請求將被轉發給另一伺服器並且沒有任何請求將由高速緩存代理伺服器來服務，這首先就使提供高速緩存代理伺服器所為的目的落空。在如上描述的塊請求流送過程期間，客戶端可能在某個時刻請求處在文件開頭的塊。根據此處描述的新穎方法，每當滿足某個條件時，便可將此類請求從對文件中的首個塊的請求轉換成對整個文件的請求。當高速緩存代理伺服器接收到對整個文件的請求時，該代理伺服器通常存儲響應。因此，這些請求的使用使得文件被放入本地高速緩存代理伺服器的高速緩存中，以使得後續請求無論是針對全文件的還是部分請求均可直接由該高速緩存代理伺服器來服務。該條件可以是使得在與給定文件相關聯的請求集合(例如由觀看所議的內容項的一組客戶端生成的請求的集合)中，該條件至少對於這些請求中的規定的分數而言將是滿足的。合適條件的示例是隨機選取的數字高於所規定的閾值。該閾值可被設置成使得將單塊請求轉換成全文件請求的這種轉換平均而言對這些請求中規定的分數發生，例如10 個請求裡面發生一次(在這種情形中，可從區間
選取該隨機數並且閾值可為0. 9)。合適條件的另一示例是對與塊相關聯的一些信息以及與客戶端相關聯的一些信息演算出的散列函數取所規定的值集合中的一個值。該方法具有以下優點對於被頻繁請求的文件，該文件將被放入本地高速緩存代理伺服器的高速緩存中，然而塊請求流送系統的操作與其中每個請求針對單個塊的標準操作相比沒有明顯更改。在許多情形中，在發生將請求從單塊請求轉換成全文件請求的場合，客戶端規程本將接著請求該文件內的其他塊。如果是這種情形，則此類請求可被抑制，因為所議的塊無論如何都將作為全文件請求的結果被接收到。URL構造以及段列表牛成和杳找段列表生成應對客戶端在特定的客戶端本地時間「現在」如何從MPD來為始於某個開始時間「starttime」的特定表示生成段列表的問題，其中該開始時間「starttime」對於點播情形而言是相對於媒體呈現的開始而言的，或者是以壁鍾時間來表達的。段列表可包括定位符，例如指向可任選的初始表示元數據的URL，以及媒體段列表。每個媒體段可能已被指派開始時間、歷時和定位符。開始時間典型地表達段中所包含媒體的媒體時間的近似，但不一定是樣本準確時間。開始時間被HTTP流送客戶端用來在恰適的時間發出下載請求。段列表(包括每個段的開始時間)的生成可按不同方式進行。URL可作為播放列表提供，或者URL構造規則可被有利地用於段列表的緊湊表示。可例如執行基於URL的段列表構造——若MPD通過諸如文件動態信息 (FileDynamicInfo)或等效信號之類的特定屬性或元素來信令通知這一點。以下在「URL構造概覽」小節中提供從URL構造創建段列表的普適方式。基於播放列表的構造可例如由不同信號來信令通知。本上下文中還有利地實現在段列表中查找以及到達準確的媒體時間的功能。URL構造器概覽如先前描述的，在本發明的一個實施例中，可提供包含URL構造規則的元數據文件，這些URL構造規則允許客戶端設備構造呈現的塊的文件標識符。現在描述對塊請求流送系統的進一步新穎增強，其提供元數據文件的改變，包括URL構造規則的改變、可用編碼的數目的改變、與可用編碼相關聯的元數據諸如比特率、縱橫比、解析度、音頻或視頻編解碼器或編解碼參數或其他參數的改變。在該新穎增強中，可提供與元數據文件的每個元素相關聯的指示在整個呈現內的時間區間的附加數據。在該時間區間內，該元素可被視為有效，而除該時間區間以外，該元素可被忽略。此外，可增強元數據的句法，以使得先前允許出現僅一次或至多一次的元素可出現多次。在這種情形中可應用附加限制，其規定對於此類元素，指定的時間區間必須不相交。在任何給定時刻，僅考慮其時間區間包含此給定時刻的元素就將得到與原始元數據句法相一致的元數據文件。將此類時間區間稱為有效性區間。該方法因此提供了在單個元數據文件內信令通知上述種類的改變的手段。有利地，此類方法可用來提供在呈現內的指定點支持所描述的種類的改變的媒體呈現。URL構造器如本文中所描述的，塊請求流送系統的常見特徵是需要向客戶端提供「元數據」， 元數據標識可用媒體編碼並提供客戶端請求來自這些編碼的塊所需的信息。例如，在HTTP 的情形中，該信息可包括包含媒體塊的文件的URL。可提供播放列表文件，其列出給定編碼的塊的URL。提供多個播放列表文件，每個文件針對一種編碼，連同列出與不同編碼相對應的播放列表的「關於播放列表的主播放列表」。該系統的缺點在於元數據可能變得相當大， 且因此在客戶端開始流時要花一定時間來請求元數據。該系統的另一缺點在實況內容的情形中是明顯的，此時與媒體數據塊相對應的文件是從正被實時地(實況)捕捉的媒體流 (例如實況體育比賽或新聞節目)「在運行中」生成的。在這種情形中，可在每次有新塊可用時(例如，每幾秒)更新播放列表文件。客戶端設備可重複地取回該播放列表文件以確定是否有新塊可用並獲得其URL。這可能對服務基礎設施造成顯著負荷，並且尤其意味著元數據文件不能被高速緩存比更新間隔更久的時間，更新間隔等於通常為幾秒的量級的塊大小。塊請求流送系統的一個重要方面是用於向客戶端通知應當與文件下載協議一起用來請求塊的文件標識符(例如URL)的方法。例如，其中對於呈現的每個表示都提供播放列表文件的方法，該播放列表文件列出包含媒體數據塊的文件的URL。該方法的缺點在於播放列表文件本身的至少一些需要被下載後播出才能開始，這增加了頻道換臺時間並且因此導致不良用戶體驗。對於具有若干或許多表示的長媒體呈現，文件URL的列表可能很大，並且因此播放列表文件可能很大，這進一步增加了頻道換臺時間。該方法的另一缺點發生在實況內容的情形中。在這種情形中，不會事先就有完整的URL列表可用，且播放列表文件隨著有新塊變為可用而被周期性地更新，並且客戶端周期性地請求該播放列表文件以接收經更新版本。由於該文件被頻繁更新，因此其不能被長時間存儲在高速緩存代理伺服器內。這意味著對該文件的很多請求將被轉發給其他伺服器並最終轉發給生成該文件的伺服器。在受歡迎的媒體呈現的情形中，這可能對該伺服器以及網絡造成高負荷，進而可能導致響應時間很慢並因此導致頻道換臺時間很長且用戶體驗不良。在最差情形中，伺服器變得過載，並且這導致一些用戶不能觀看該呈現。在塊請求流送系統的設計中希望避免對可使用的文件標識符的形式加以限制。這是由於多種考慮可能激發使用特定形式的標識符的動機。例如，在塊供應基礎設施是內容投遞網絡的情形中，可能存在與跨網絡分布存儲或服務負荷的願望或其他要求相關的文件命名或存儲慣例，這導致在系統設計時不能預測的特定形式的文件標識符。現在描述另一實施例，其緩解了上述缺點而同時留存選取恰適文件標識慣例的靈活性。在該方法中，可為媒體呈現的每個表示提供包括文件標識符構造規則的元數據。文件標識符構造規則可例如包括文本串。為了確定呈現的給定塊的文件標識符，可提供解讀文件標識符構造規則的方法，該方法包括確定輸入參數以及將文件標識構造規則連同這些輸入參數一起求值。輸入參數可例如包括要標識的文件的索引，其中第一文件具有索引0， 第二文件具有索引1，第三文件具有索引2，依此類推。例如，在每個文件跨越相同時間歷時 (或大致相同的時間歷時)的情形中，則與呈現內任何給定時間相關聯的文件的索引可容易地確定。替換地，呈現內由每個文件跨越的時間可在呈現或版本元數據內提供。在一個實施例中，文件標識符構造規則可包括文本串，該文本串可包含與輸入參數相對應的某些特殊標識符。文件標識符構造規則的求值方法包括確定這些特殊標識符在該文本串內的位置，以及用相應的輸入參數的值的串表示來取代每個此類特殊標識符。在另一實施例中，文件標識符構造規則可包括遵循表達語言的文本串。表達語言包括該語言的表達可遵循的句法的定義以及用於對遵循該句法的串求值的規則集。現在將參照圖21及下列等等來描述具體示例。圖21中示出對以增廣巴科斯-諾爾範式(Augmented Backus Naur Form)定義的合適表達式語言的句法定義的示例。用於對遵循圖21中的 產生式的串的規則求值的示例包括如下將遵循 產生式的串遞歸地變換成遵循 產生式的串遵循 產生式的 不變。遵循 產生式的 用由該〈變量〉產生式的 串標識的變量的值來替代。遵循 產生式的 通過如下描述地根據這些規則來對其每個自變量求值並向這些自變量應用取決於 產生式的 元素的變換來求值。遵循 產生式的最後選項的 通過如下描述地對這兩個 元素求值並向這些自變量應用取決於 產生式的此最後選項的 元素的運算來求值。在以上描述的方法中，假定求值發生在其中可定義多個變量的上下文中。變量是 (名稱，值)對，其中「名稱」是遵循〈令牌〉產生式的串，而「值」是遵循〈字面〉產生式的串。一些變量可在求值開始前在求值過程外部定義。其他變量可在求值過程本身內部定義。 所有變量都是「全局」的，「全局」的意義是指對於每個可能的「名稱」僅存在一個變量。函數的示例是「printf」函數。該函數接受一個或更多個自變量。第一自變量可遵循〈串〉產生式(下文稱為「串」)。printf函數求值得到其第一自變量的經變換版本。 所應用的變換與C標準庫的「printf 」函數相同，其中〈函數〉產生式中包括的附加自變量供應C標準庫printf函數預期的附加自變量。函數的另一示例是「hash (散列)」函數。該函數接受兩個自變量，其中第一個自變量可以是串，而第二個自變量可遵循〈數字〉產生式(下文稱為「數字」)。「hash」函數向第一自變量應用散列算法並返回為小於第二自變量的非負整數結果。合適散列函數的示例在圖22中所示的C函數中給出，其自變量為輸入串(排除包封的引號)以及數值輸入值。 散列函數的其他示例對本領域技術人員是公知的。函數的另一示例是取一個、兩個或三個串自變量的「Subst」函數。在供應一個自變量的情形中，「Subst」函數的結果是第一自變量。在供應兩個自變量的情形中，則「Subst」 函數的結果通過在第一自變量內擦除第二自變量(排除包封的引號)的任何出現並返回經如此修改的第一自變量來計算。在供應三個自變量的情形中，則「Subst」函數的結果通過在第一自變量內用第三自變量(排除包封的引號)來替代第二自變量(排除包封的引號) 的任何出現並返回經如此修改的第一自變量來計算。運算符的一些示例是加、減、除、乘和模運算符，分別由〈運算符〉產生式『 + 』、『_』、 『/』、『*』、『 ％ 』標識。這些運算符要求 產生式任一側的 產生式求值均得到數字。運算符的求值包括以常規方式向這兩個數字應用恰適的算術運算(分別為加、 減、除、乘和模)並返回遵循〈數字〉產生式的形式的結果。運算符的另一示例是賦值運算符，由 產生式『=』標識。該運算符要求左邊的自變量求值得到串，其內容遵循〈令牌〉產生式。串的內容被定義為包封的引號內的字符串。等於運算符導致其名稱為等於左邊自變量的內容的〈令牌〉的變量被賦於等於對右邊自變量求值的結果的值。該值也是對該運算符表達式求值的結果。運算符的另一示例是順序運算符，由 產生式『；，標識。對該運算符求值的結果是右邊的自變量。注意，與所有運算符一樣，兩個自變量均被求值並且左邊的自變量先被求值。在本發明的一個實施例中，文件的標識符可通過根據以上規則用標識所要求的文件的特定的一組輸入變量對文件標識符構造規則求值來獲得。輸入變量的示例是名稱為 「index(索引)」且值等於該文件在呈現內的數值索引的變量。輸入變量的另一示例是名稱為「bitrate (比特率)，，且值等於呈現的所要求版本的平均比特率的變量。圖23解說了文件標識符構造規則的一些示例，其中輸入變量是給出想要的呈現的表示的標識符的「id」以及給出文件的序列號的「seq」。如本領域技術人員在閱讀本公開之際將清楚的，以上方法的許多變形是可能的。 例如，可以並非提供以上描述的函數和運算符的全部，或者可提供外加的函數或運算符。URL構造規則和時基本節提供基本URI構造規則，以指派文件或段URI以及每個段在表示和媒體呈現內的開始時間。對於本條，假定客戶端處有媒體呈現描述可用。假定HTTP流送客戶端正在播出在媒體呈現內下載的媒體。HTTP客戶端的實際呈現時間可用呈現時間相對於呈現開始在何處來定義。在初始化時，可假定呈現時間t = 0。在任何點t，HTTP客戶端可下載播放時間tP (也是相對於呈現的開始而言的)比實際呈現時間t提前至多「MaximumClientfreBufferTime (最大客戶端預緩衝時間)」的任何數據、以及由於用戶交互(例如，查找、快進等)而需要的任何數據。在一些實施例中， 「最大客戶端預緩衝時間」甚至可以不被指定，不被指定的意義是指客戶端能無限制地下載比當前播放時間提前(tP)的數據。HTTP客戶端可避免下載不必要的數據，例如，來自預期不會播出的表示的任何段可能典型地不被下載。提供流送服務的基本過程可以是通過生成下載整個文件/段或文件/段子集的恰適請求，例如通過使用HTTP獲取請求或HTTP部分獲取請求來下載數據。本描述解決了如何訪問特定播出時間tP的數據，但一般而言，客戶端可下載更大時間範圍的播放時間的數據以避免低效率請求。HTTP客戶端可使得在提供流送服務時的HTTP請求的數目/頻度最小化。為了訪問特定表示中在播放時間tP或至少接近播放時間tP的媒體數據，客戶端確定指向包含該播放時間的文件的URL並且另外確定該文件中用於訪問該播放時間的字節範圍。媒體呈現描述可例如通過使用R印resentationID (表示ID)屬性向每個表示指派表示id 「r」。換言之，MPD的該內容在由攝取系統寫時或在被客戶端讀時將被解讀成存在指派。為了下載id為r的特定表示的特定播放時間tP的數據，客戶端可構造針對文件的恰適URI。媒體呈現描述可向每個表示r的每個文件或段指派以下屬性(a)表示r內的文件的序號i，其中i = 1，2，...，Nr，(b)表示id為r且文件索引為i的文件相對於呈現時間而言的相對開始時間，定義為ts(r，i)，(c)表示id為r且文件索引為i的文件/段的文件URI，記為FileURI (r, i)。在一個實施例中，可顯式地為表示提供文件的開始時間和文件URI。在另一實施例中，可顯式地提供文件URI列表，其中每個文件URI根據在該列表中的位置被固有地指派索引i，並且段的開始時間是作為從1到i_l的段的所有段歷時之和來推導的。每個段的歷時可根據以上討論的任何規則來提供。例如，懂基礎數學的任何人員可使用其他方法來推導用於從單個元素或屬性以及文件URI在表示中的位置/索引來容易地推導開始時間的方法。若MPD中提供動態URI構造規則，則每個文件的開始時間以及每個文件URI可通過使用構造規則、所請求的文件的索引、以及潛在可能還使用在媒體呈現描述中提供的一些附加參數來動態地構造。該信息例如可在諸如文件URI模式(FileURII^attern)和動態文件信息(FilelnfoDynamic)等MPD屬性及元素中提供。文件URI模式提供關於如何基於文件索引序號i和表示ID r來構造URI的信息。文件URI格式(FileURIi^rmat)構造為文件URI 格式=sprintf ( "% s% s% s% s% s. % s，，，基 URI，基文件名稱，表示ID格式，分隔符格式，文件序列ID格式，文件擴展名)；並且FileURI (r, i)構造為FileURI (r，i) = sprintf (文件 URI 格式，r，i)；每個文件/段的相對開始時間ts(r，i)可由MPD中包含的描述該表示中的段的歷時的某個屬性來推導，例如「動態文件信息」屬性。MPD還可包含對媒體呈現中的所有表示或以如上指定的相同方式至少在時段中對所有表示而言為全局的「動態文件信息」屬性序列。若表示r中的特定播放時間tP的媒體數據被請求，則相應的索引i(r，tP)可被推導為 i(r, tp)，以使得該索引的播放時間落在開始時間ts(r，i(r, tP))與ts(r，i (r, tP)+l)的區間中。段訪問可進一步被以上情形限制，例如段是不可訪問的。一旦獲得相應段的索引和URI，訪問確切的播放時間tP就取決於實際段格式。在該示例中，不失一般性，假定媒體段具有始於0的局部時間線。為了訪問和呈現播放時間tP 的數據，客戶端可從能通過其中i = i(r，tp)的URIFileURI (r，i)訪問的文件/段下載與局部時間相對應的數據。—般而言，客戶端可下載整個文件並且隨後可訪問播放時間tP。然而，不一定3GP
59文件的所有信息都需要被下載，因為3GP文件提供將局部時基映射到字節範圍的結構。因此，只要有充分的隨機訪問信息可用，僅訪問播放時間tP的特定字節範圍就足以播放媒體。同樣，在段的初始部分中可例如使用段索引之類來提供關於媒體段的字節範圍和局部時基的結構和映射的充分信息。通過能訪問段的初始的例如1200個字節，客戶端就可具有充分的信息以直接訪問播放時間tP所需的字節範圍。在另一示例中，假定段索引(可能在下文指定為「tidx」包)可被用於標識所要求的一個或多個片斷的字節偏移量。可針對所要求的一個或多個片斷形成部分獲取請求。還存在其他替換方案，例如，客戶端可發出對文件的標準請求並在已接收到第一個「tidx」包時取消該請求。^^客戶端可嘗試查找到表示中的特定呈現時間tp。基於MPD，客戶端能訪問表示中的每個段的媒體段開始時間和媒體段URL。客戶端可獲取開始時間tS(r，i)小於或等於呈現時間tp的最大段索引i作為最有可能包含呈現時間tp的媒體樣本的段的段索引 segment_index，即段索引=max{i |tS(r，i) <=tp}。獲得段 URL 為 FileURI (r，i)。注意，由於與隨機訪問點的放置、媒體軌跡的對準以及媒體時基漂移有關的問題， MPD中的時基信息可能是近似的。因此，由以上規程所標識出的段可能始於比tp稍晚的時間，並且呈現時間tp的媒體數據可能位於先前媒體段中。在查找的情形中，可將查找時間更新成等於檢索到的文件的首個樣本時間，或者可代之以檢索前一文件。然而應注意，在連續播出期間，包括在替換表示/版本之間切換的情形中，tp與檢索到的段的開始之間的時間的媒體數據仍是可用的。為了準確地查找到呈現時間tp，HTTP流送客戶端需要訪問隨機訪問點(RAP)。 為了在3GPP自適應HTTP流送的情形中確定媒體段中的隨機訪問點，客戶端可例如使用 『tidx』或『sidx』包(若存在)中的信息來定位媒體呈現中的隨機訪問點以及相應的呈現時間。在段為3GPP電影片斷的情形中，也可能由客戶端使用『moof』和『mdat』包內的信息來例如定位RAP並從電影片斷中的信息和從MPD推導出的段開始時間來獲得必需的呈現時間。若沒有呈現時間在所請求的呈現時間tp之前的RAP可用，則客戶端可訪問先前段或者可僅僅使用首個隨機訪問點作為查找結果。當媒體段始於RAP時，這些規程是簡單的。同樣應注意，媒體段的所有信息未必都需要被下載才能訪問呈現時間tp。客戶端可以例如首先使用字節範圍請求從媒體段的開頭請求『tidx』或『sidx』包。通過使用 『tidx』或『sidx』包，段時基可被映射到段的字節範圍。通過連續使用部分HTTP請求，僅媒體段中有關係的部分需要被訪問，從而得到改善的用戶體驗以及低啟動延遲。段列表生成如本文中所描述的，如何實現使用由MPD提供的信息來為具有信令通知的大致段歷時dur的表示創建段列表的簡單直接的HTTP流送客戶端應當是明了的。在一些實施例中，客戶端可向表示內的媒體段指派連貫索引i = 1，2，3，...，即第一個媒體段被指派索引 i = 1，第二個媒體段被指派索引i = 2，依此類推。那麼，具有段索引i的媒體段的列表被指派startTime[i](開始時間[i])，並且例如如下生成URL[i]。首先，將索引i設為1。獲得第一個媒體段的開始時間為0，即startTime[l] = 0。獲得媒體段i的URL即URL[i]為 FileURI (r，i)。該過程針對具有索引i的所有被描述的媒體段繼續，並且獲得媒體段i的startTime [i]為(i_l) *dur，並且獲得 URL[i]為 FileURI (r，i)。並發HTTP/TCP 請求塊請求流送系統中一關注點是希望總是請求能被及時地完整接收以供播出的最高質量塊。然而，數據抵達率可能不是事先已知的，且因此可能碰巧所請求的塊沒有及時抵達以供播出。這導致需要暫停媒體播出，從而導致不良用戶體驗。該問題可通過對要請求的塊的選擇採取保守辦法的客戶端算法來緩解，此保守辦法請求更有可能即便在塊的接收期間數據抵達率下降亦能被及時接收到的較低質量(因此有較小大小)的塊。然而，該保守辦法具有可能向用戶或目的地設備投遞較低質量播出這一缺點，這也是不良用戶體驗。當同時使用多個HTTP連接來下載不同塊時該問題可能放大，如以下所描述的，因為可用網絡資源跨連接被共享，且因此被同時用於具有不同播出時間的塊。客戶端並發地發出對多個塊的請求可能是有利的，其中在本上下文中，「並發地」 表示對請求的響應發生在交迭的時間區間中，且這些請求不一定是在精確或甚至大致相同的時間作出的。在HTTP協議的情形中，該辦法由於TCP協議的行為(這是公知的)故而可改善對可用帶寬的利用率。這對於改善內容換臺時間可能是尤為重要的，因為在新內容首次被請求時，藉以請求這些塊的數據的相應HTTP/TCP連接可能起動很慢，並且因此在此時使用若干HTTP/TCP連接能極大地加速第一批塊的數據投遞時間。然而，在不同HTTP/TCP 連接上請求不同塊或片斷也可能導致性能降級，因為對將要先播出的塊的請求正在與對後續塊的請求競爭，競爭的各HTTP/TCP下載在其投遞速度方面大為不同，並且因此該請求的完成時間可能高度可變，且一般不可能控制哪些HTTP/TCP連接將迅速完成而哪些將較慢， 因此很有可能至少一些時候頭幾個塊的HTTP/TCP下載將最後完成，因此導致很大且可變的頻道換臺時間。假設段的每個塊或片斷是在單獨的HTTP/TCP連接上下載的，並且並行連接的數量為η且每個塊的播出歷時為t秒，並且與該段相關聯的內容的流送率為S。當客戶端最初開始流送該內容時，可發出對頭η個塊的請求，這代表n*t秒的媒體數據。如本領域技術人員已知的，TCP連接的數據率有很大變動。然而，為了簡化本討論， 假設理想情況下所有連接都並行地進行，從而第一個塊將在與其他n-1個請求的塊大約相同的時間被完全接收。為了進一步簡化本討論，假設這η個下載連接所利用的聚集帶寬在該下載的整個歷時期間固定為值B，並且流送率S在整個表示期間是恆定的。進一步假設媒體數據結構使得塊的播出在整個塊在客戶端處可用時才能進行，即塊的播出只能在接收到整個塊之後開始，例如由於底層視頻編碼的結構或者由於採用了加密來單獨加密每個片斷或塊，且因此整個片斷或塊需要先被接收到才能被解密。因此，為了簡化以下的討論，假定在塊的任何部分能被播出之前，需要接收到整個塊。那麼，在第一個塊抵達並且能被播出之前所需的時間約為n*t*S/B。由於希望使內容換臺時間最小化，因此使n*t*S/B最小化是可取的。t的值可由諸如底層視頻編碼結構以及如何利用攝取方法等因素決定，且因此t可以適度地小，但非常小的t值導致過度複雜的段映射，並且可能與高效視頻編碼和解密(若使用)不兼容。η 的值也可能影響B的值，即B對於較大的連接數量η可能較大，且因此減少連接數量η具有潛在地減少所利用的可用帶寬量B的負面效應，因此對於達成減少內容換臺時間的目標可能不是有效的。S的值取決於選取下載和播出哪個表示，且理想情況下S應當儘可能接近B以使給定網絡條件下媒體的播出質量最大化。因此，為了簡化本討論，假定S約等於B。那麼，頻道換臺時間與n*t成比例。因此，若各連接利用的聚集帶寬與連接數量呈亞線性比例 (通常就是這種情形)，則利用較多連接來下載不同片斷會使頻道換臺時間降級。作為示例，假設t = 1秒，且n= 1時B的值= 500Kbps，n = 2時B的值= 700Kbps， 且η = 3時B的值=800Kbps。假設選取了 S = 700Kbps的表示。那麼，在η = 1吋，第一塊的下載時間為1*700/500 = 1. 4秒，在η = 2時，第一塊的下載時間為2*700/700 = 2秒， 在η = 3吋，第一塊的下載時間為3*700/800 = 2. 625秒，此外，隨著連接數量増加，各連接的個體下載速度的可變性很可能増加(儘管即使在一個連接的情況下，也很可能有某個明顯的可變性)。因此，在該示例中，頻道換臺時間和頻道換臺時間可變性隨連接數量的增加而增加。直觀上，正被投遞的塊具有不同優先級，即第一個塊具有最早投遞期限，第二個塊具有次最早期限等等，而正藉以投遞這些塊的各下載連接正在投遞期間競爭網絡資源， 且因此具有最早期限的塊隨著有越來越多的競爭塊被請求而越加延遲。另ー方面，即使在該情形中，最終使用ー個以上下載連接也允許支持可維繫的較高流送率，例如在三個連接的情況下，在該示例中能支持最高達800Kbps的流送率，而在ー個連接的情況下僅能支持 500Kbps 的流。在實踐中，如上所述，連接的數據率在相同連接內隨著時間推移以及在不同連接之間都可能高度可變，並且因此，η個所請求的塊一般不在同時完成，且事實上通常可能是 ー個塊可能在另ー塊的一半時間裡就完成了。該效應導致不可預測的行為，因為在ー些情形中，第一個塊可能比其他塊完成得快得多，而在其他情形中，第一個塊可能比其他塊完成得晚得多，且因此播出的開始在一些情形中可能相對迅速地發生而在其他情形中可能發生得很慢。這種不可預測的行為對於用戶來說可能是令人沮喪的，並且因此可能被視為不良用戶體驗。因此，需要能利用多個TCP連接來改善頻道換臺時間和頻道換臺時間可變性而同時支持可能的良好質量流送率的方法。還需要允許隨著塊的播出時間的逼近調節分配給每個塊的可用帶寬的份額、從而在必要的情況下較大份額的可用帶寬能有傾向性地被分配給具有最迫近的播放時間的塊的方法。協作式HTTP/TCP請求現在描述以協作式方式使用並發HTTP/TCP請求的方法。接收機可採用多個並發的協作式HTTP/TCP請求，例如使用多個HTTP字節範圍請求，其中每個此類請求針對源段中的片斷的一部分、或源段的片斷的全部、或修復段的一部分或修復片斷、或針對修復段的修復片段的全部。協作式HTTP/TCP請求連同使用FEC修複數據的優點對於提供ー貫快速的頻道換臺時間可能尤為重要。例如，在頻道換臺時間，TCP連接很可能剛剛起動或者已空閒了一段時間，在這種情形中擁塞窗cwnd對於這些連接位於其最小值，且因此這些TCP連接的投遞速度將花若干往返行程時間(RTT)來斜坡上升，且在該斜坡上升時間期間不同TCP連接上的投遞速度將具有高度可變性。現在描述無FEC方法的概覽，無FEC方法是協作式HTTP/TCP請求方法，其中使用多個並發HTTP/TCP連接來僅請求源塊的媒體數據，即不請求FEC修複數據。通過該無FEC 方法，在不同連接上請求相同片斷的各部分，例如使用針對該片斷的各部分的HTTP字節範圍請求，且因此例如每個HTTP字節範圍請求針對該片斷的段映射中指示的字節範圍的一部分。可能是這種情形個體HTTP/TCP的投遞速度在若干RTT (往返行程時間)上斜坡上升以完全利用可用帶寬，且因此在相對長的時間段裡投遞速度小於可用帶寬，因此若使用單個HTTP/TCP連接來下載例如要播出的內容的第一個片斷，則頻道換臺時間可能很大。使用無FEC方法，在不同HTTP/TCP連接上下載相同片斷的不同部分就能顯著減小頻道換臺時間。現在描述FEC方法的概覽，FEC方法是協作式HTTP/TCP請求方法，其中使用多個並發HTTP/TCP連接來請求源段的媒體數據以及從該媒體數據生成的FEC修複數據。通過該FEC方法，使用針對片斷的各部分的HTTP字節範圍請求在不同連接上請求相同片斷的各部分以及從該片斷生成的FEC修複數據，且因此例如每個HTTP字節範圍請求針對該片斷的段映射中指示的字節範圍的一部分。可能是這種情形個體HTTP/TCP請求的投遞速度在若干RTT(往返行程時間)上斜坡上升以完全利用可用帶寬，因此在相對長的時間段裡投遞速度小於可用帶寬，因此若使用單個HTTP/TCP連接來下載例如要播出的內容的第一個片斷， 則頻道換臺時間可能很大。使用FEC方法具有與無FEC方法相同的優點，且具有並非所有所請求數據都需要在能恢復該片斷之前抵達的額外優點，因此進ー步減小了頻道換臺時間以及頻道換臺時間可變性。通過在不同TCP連接上作出請求、以及在其中至少一條連接上還請求FEC修複數據的溢額請求，投遞例如足以恢復使得媒體播出能開始的第一個所請求片斷的數據量要花的時間量可被極大地減少，井能使之比不使用協作式TCP連接和FEC修複數據的情況下更加一致。圖M(a)_(e)示出在從仿真的演進數據優化(EVDO)網絡上的相同HTTPweb伺服器至相同客戶端的相同鏈路上運行的5個TCP連接的投遞率波動的示例。在圖M(a)_(e) 中，X軸示出以秒計的時間，並且Y軸示出客戶端處在這5個TCP連接中的每ー個連接上接收比特的速率，每個連接上的速率是針在1秒的區間上測量的。在該特定仿真中，在該鏈路上總共有12個TCP連接在運行，且因此網絡在所示時間期間是相對有負荷的，這在有ー個以上客戶端正在行動網路的相同蜂窩小區內進行流送時是典型的。注意，儘管投遞率隨著時間推移來看在一定程度上是相關的，但這5個連接的投遞率在許多時間點是有巨大差異的。圖25示出針對大小為250，000比特(約為31. 25千字節)的片斷的可能請求結構，其中對該片斷的不同部分並行地作出4個HTTP字節範圍請求，即第一 HTTP連接請求頭50，000比持，第二 HTTP連接請求接下來的50，000比持，第三HTTP連接請求接下來的 50，000比持，而第四HTTP連接請求接下來的50，000比持。若不使用FEC，即無FEC方法， 則在該示例中對該片斷只有4個請求。若使用FEC，即FEC方法，則在該示例中，有一個附加的HTTP請求，用於請求從該片斷生成的修復段的額外50，000比特FEC修複數據。圖沈是圖M(a)-(e)中所示的5個TCP連接的頭幾秒的放大，其中在圖沈中，X 軸以100毫秒的間隔示出時間，並且Y軸示出客戶端處在這5個TCP連接中的每ー個連接上接收比特的速率，該速率是在100毫秒區間上測量的。一條線示出在客戶端處已從頭4 個HTTP連接(排除藉以請求FEC數據的那個HTTP連接)為該片斷接收到的聚集比特量， 即，使用無FEC方法抵達的聚集比特量。另一條線示出在客戶端出已從所有這5個HTTP連接(包括藉以請求FEC數據的那個HTTP連接)為該片斷接收到的聚集比特量，即，使用FEC方法抵達的聚集比特量。對於FEC方法，假定該片斷從接收到250，000個所請求比特中的任何200，000比特時起能被FEC解碼，這在例如使用Reed-Solomon FEC碼的情況下就能實現，且在例如使用Luby IV中描述的RaptorQ碼的情況下則本質上能實現。對於該示例中的FEC方法，在1秒後接收到足以使用FEC解碼來恢復該片斷的數據，從而允許1秒的頻道換臺時間(假定在第一個片斷被完全播出之前能請求並接收後續片斷的數據)。對於該示例中的無FEC方法，在能恢復該片斷之前不得不接收這4個請求的所有數據，這在1. 7秒之後發生，從而得到1. 7秒的頻道換臺時間。因此，在圖沈中所示的示例中，無FEC方法在頻道換臺時間的意義上比FEC方法差70%。該示例中的FEC方法表現出的優點的ー個原因在幹，對於FEC方法，接收到所請求的數據中的任何80%就允許恢復該片斷，而對於無FEC 方法，要求接收到所請求的數據的100%。因此，無FEC方法不得不等待最慢的TCP連接完成投遞，且由於TCP投遞率的自然變動，最慢TCP連接的投遞速度與平均TCP連接相比可能動輒有很大方差。在該示例中的FEC方法下，ー個慢TCP連接不會決定該片斷何時能恢復。 相反，對於FEC方法，足夠數據的投遞更多地取決於平均TCP投遞率而非最差情形TCP投遞卓。存在以上描述的無FEC方法和FEC方法的許多變形。例如，協作式HTTP/TCP請求可被用於發生頻道換臺後的僅頭幾個片斷，且此後僅使用單個HTTP/TCP請求來下載進ー 步的片斷、多個片斷或整個段。作為另ー示例，所使用的協作式HTTP/TCP連接的數量可以是正在請求的片斷的緊急性(即，這些片斷的播出時間有多迫切)以及當前網絡條件的函數。在一些變形中，可使用多個HTTP連接來請求來自修復段的修複數據。在其他變形中，可在不同的HTTP連接上請求不同的數據量，例如取決於媒體緩衝器的當前大小以及客戶端處的數據接收速率。在另ー變形中，各源表示彼此並不獨立，而是代表分層媒體編碼， 其中例如增強型源表示可取決於基源表示。在這種情形中，可以有與基源表示相對應的修復表示、以及與基和增強源表示的組合相對應的另一修復表示。附加的全部元件增進了可由以上公開的方法實現的優點。例如，所使用的HTTP 連接的數量可取決於媒體緩衝器中的當前媒體量、和/或向媒體緩衝器中接收的速率而變化。在媒體緩衝器相對較空時可進取性地使用利用FEC的協作式HTTP請求，即以上描述的FEC方法及該方法的變形，例如對第一片斷的不同部分並行地作出較多的協作式HTTP請求，請求源片斷的全部以及來自相應的修復片段的相對大分數的修複數據，井隨後隨著媒體緩衝器增長，轉換到數量減少的並發HTTP請求，每請求皆請求更大部分的媒體數據，以及請求較小分數的修複數據，例如，轉換到1、2或3個並發HTTP請求，轉換到每請求對滿量的片斷或多個連貫片斷作出請求，以及轉換到不請求修複數據。作為另ー示例，FEC修複數據的量可作為媒體緩衝器大小的函數而變化，即，當媒體緩衝器小吋，則可請求較多FEC修複數據，並且隨著媒體緩衝器增長，則可逐漸減少所請求的FEC修複數據的量，以及在媒體緩衝器充分大時的某個時間點，可以不請求FEC修複數據，僅請求來自源表示的源段的數據。此類增強型方法的益處在於它們可允許更快和更ー 致的頻道換臺時間、以及更強的抗潛在媒體不流暢或停滯的回弾性，同時通過減少請求消息話務和FEC修複數據兩者使所使用的超過只投遞源段中的媒體本應消費的量的額外帶寬量最小化，同時又使得能支持給定網絡條件下最高的可能媒體速率。
使用並發HTTP連接時的附加增強若滿足合適的條件則可放棄HTTP/TCP請求並且可作出另ー HTTP/TCP請求以下載可替代在被放棄的請求中所請求的數據的數據，其中第二 HTTP/TCP請求可請求與原始請求中完全相同的數據，例如源數據；或交迭數據，例如相同源數據和修複數據中在第一請求中尚未請求的一些；或者完全不相交的數據，例如第一請求中尚未請求的修複數據。合適條件的示例是請求因在所規定時間內沒有來自塊伺服器基礎設施(BSI)的響應、或者在建立與BSI的傳輸連接時發生故障、或接收到來自伺服器的顯式故障消息、或其他故障條件而失敗。合適條件的另ー示例是根據將連接速度的度量(響應於所議請求的數據抵達率) 與預期連接速度、或與在響應中包含的媒體數據的播出時間或取決於該時間的其他時間之前接收該響應所需的連接速度的估計作比較，數據的接收進行得異常慢。該辦法在BSI有時顯現故障或不良性能的情形中具有優點。在這種情形中，上述辦法提高了即使BSI內有故障或不良性能該客戶端仍能繼續可靠地播出媒體數據的概率。 注意，在一些情形中，以BSI有時的確顯現出此類故障或不良性能的方式來設計BSI可能存在優點，例如此類設計可具有比不顯現出此類故障或不良性能或不那麼頻繁地顯現出此類故障或不良性能的替換設計低的成本。在這種情形中，本文中描述的方法具有進ー步優點， 因為其允許對BSI利用此類較低成本設計而不會導致用戶體驗降級的後果。在另ー實施例中，對與給定塊相對應的數據發出的請求的數目可取決於是否滿足關於該塊的合適條件。若不滿足該條件，則假使對該塊的所有目前未完成的數據請求的成功完成將允許以高概率恢復出該塊，客戶端可被禁止對該塊作出進ー步請求。若滿足該條件，則可發出對該塊的更大量請求，即，以上的禁止不適用。合適條件的示例是截至該塊的調度播出時間為止的時間或取決於該時間的其他時間落在所規定的閾值之下。該方法具有優點，這是由於對塊的數據的附加請求是在對塊的接收因包括該塊的媒體數據的播出時間迫近而變得更急迫之後發出的。在諸如HTTP/TCP之類的常見傳輸協議的情形中，這些附加請求具有增加專用於對所議塊的接收有貢獻的數據的可用帶寬的份額的效應。這減少了完成足以恢復該塊的數據的接收所需的時間，並因此減少該塊不能在包括該塊的媒體數據的調度播出時間之前被恢復的概率。如以上所描述的，若該塊不能在包括該塊的媒體數據的調度播出時間之前被恢復，則播出會暫停，從而導致不良用戶體驗，因此這裡描述的方法有利地減少了這種不良用戶體驗的概率。應理解，貫穿本說明書對塊的調度播出時間的引述是指包括該塊的經編碼媒體數據最初可在客戶端處可用以達成該呈現的無暫停播出的時間。如對於媒體呈現系統領域的技術人員將清楚的，該時間實際上比包括該塊的媒體出現在用於播出的物理換能器(屏幕、揚聲器等)處的實際時間稍早，因為可能需要對包括該塊的媒體數據應用若干變換功能以實現對該塊的實際播出並且這些功能可能要花一定量的時間來完成。例如，媒體數據一般是以壓縮形式傳輸的並且可應用解壓變換。用於生成支持協作式HTTP/FEC方法的文件結構的方法現在描述用於生成可有利地被採用協作式HTTP/FEC方法的客戶端使用的文件結構的實施例。在該實施例中，對於每個源段，存在如下生成的相應修復段。參數R指示對於源段中的源數據而言平均生成多少FEC修複數據。例如，R = 0. 33指示若源段包含1，000千字節的數據，則相應的修復段包含約330千字節的修複數據。參數S指示用於FEC編碼和解碼的以字節計的碼元大小。例如，S = 64指示源數據和修複數據包括各自用於FEC編碼和解碼目的的大小為64位元組的碼元。可如下為源段生成修復段。源段的每個片斷被視為用於FEC編碼目的的源塊，且因此每個片斷被當作據以生成修復碼元的源塊的源碼元序列。為頭i個片斷生成的修復碼元總數演算為TNRS(i) = ceiling(R*B(i)/S)，其中ceilingOO是用於輸出值至少為x的最小整數的函數。因此，為片斷i生成的修復碼元數目為NRS (i) = TNRS (i)-TNRS (i-1)。修復段包括關於這些片斷的修復碼元的級聯，其中修復段內的修復碼元的次序按據以生成這些修復碼元的片斷的次序，且在片斷內，修復碼元按其編碼碼元標識符(ESI) 的次序。與源段結構相對應的修復段結構在圖27中示出，包括修復段生成器2700。注意，通過如上所述地定義關於片斷的修復碼元數目，關於所有先前片斷的修復碼元總數以及因此修復段的字節索引僅取決於R、S、B(i-l)和B(i)，而不取決於源段內的片斷的任何先前或後續結構。這是有利的，因為其允許客戶端僅使用關於據以生成修復塊的源段的相應片斷的結構的局部信息來迅速計算修復段內的修復塊開始的位置，並且還迅速計算該修復塊內的修復碼元數目。因此，若客戶端決定從源段中間開始下載和播出片斷， 則它還能從相應的修復段內迅速生成和訪問相應的修復塊。與片斷i相對應的源塊中的源碼元數目演算為NSS(i)= ceiling((B(i)-B(i-l))/S)0若B(i)_B(i_l)不是S的倍數，則最後的源碼元出於FEC編碼和解碼目的被填充「O」字節，即，最後的源碼元被填充「O」字節從而其大小為S字節以用於FEC編碼和解碼目的，但這些「O」填充字節不被存儲為源段的一部分。在該實施例中，源碼元的 ESI 為 0、1、...、NSS (i)-1，並且修復碼元的 ESI 為 NSS⑴、...、NSS(i)+NRS(i)_l。在該實施例中，可通過簡單地向源段的URL添加後綴「.r印air」來從相應的源段的URL生成修復段的URL。修復段的修復索引信息和FEC信息由相應的源段的索引信息以及從R和S 的值隱式地定義，如本文中所描述的。時間偏移量和包括修復段的片斷結構由相應的源段的時間偏移量和結構決定。至與片斷i相對應的修復段中的修復碼元末尾的字節偏移量可被演算為RB(i) = S*ceiling(R*B(i)/S)。與片斷i相對應的修復段中的字節數目則為RB(i)-RB(i-l)，且因此與片斷i相對應的修復碼元數目被演算為NRS⑴=(RB⑴-RB(i-1))/S。與片斷i相對應的源碼元數目可演算為NSS(i)= ceiling((B(i)-B(i-1))/S)。因此，在該實施例中，修復段內的修復塊的修復索引信息和相應的FEC信息可從R、S以及相應源段的相應片斷的索引信息隱式地推導出。作為示例，考慮圖觀中所示的示例，其示出始於字節偏移量B(I) =6，410並止於字節偏移量B (2) = 6，770的片斷2。在該示例中，碼元大小為S = 64位元組，且虛豎線示出源段內與S的倍數相對應的字節偏移量。作為源段大小的分數的總修復段大小在該示例中被設為R = 0. 5。片斷2的源塊中的源碼元數目演算為NSS (2) =ceiling( (6，770-6，410) /64)
= ceil (5. 625) = 6，且這6個源碼元分別具有ESI 0.....5，其中第一個源碼元為片斷2的
始於該源段內的字節索引6，410處的頭64個字節，第二個源碼元為片斷2的始於源段內的字節索引6，474處的接下來64個字節，等等。與片斷2相對應的修復塊的末尾字節偏移量演算為 RB じ)=64*ceiling(0. 5*6,770/64) = 64*ceiling(52. 89. · ·) = 64*53 = 3,392，
66且與片斷2相對應的修復塊的開始字節偏移量演算為RB(I) =64*ceiling(0. 5*6，410/64) =64*ceiling(50. 07. . .) = 64*51 = 3，264，因此在該示例中，在與片斷2相對應的修復塊中具有ESI分別為6和7的兩個修復碼元，始於修復段內字節偏移量3，264處並止於字節偏移量3，392。注意，在圖28中所示的示例中，儘管R = 0. 5且存在與片斷2相對應的6個源碼元，修復碼元的數目也不是如簡單地使用源碼元數目來演算修復碼元數目的情況下可預期的3個，而是根據本文中所描述的方法解出其為2。與簡單地使用片斷的源碼元數目來確定修復碼元數目不同，以上描述的實施例使得能夠單單從與相應源段的相應源塊相關聯的索引信息來演算修復段內的修復塊的定位。此外，隨著源塊中源碼元數目K增長，相應修復塊的修復碼元數目KR緊密近似為K*R，因為一般而言KR至多為ceil (K*R)且KR至少為 floor ((K-I) *R)，其中floor (χ)是最多為χ的最大整數。存在以上用於生成可有利地被採用協作式HTTP/FEC方法的客戶端使用的文件結構的實施例的許多變形，如本領域技術人員將認識到的。作為替換實施例的示例，表示的原始段可被劃分成N > 1個並行段，其中對於i = 1，...，N，原始段的指定分數Fi被包含在第 i個並行段中，且其中i = 1，. . .，N的Fi之和等於1。在該實施例中，可存在被用於推導所有並行段的段映射的一個主段映射，類似於在以上描述的實施例中如何從源段映射推導出修復段映射。例如，若並非所有源媒體數據都被劃分成並行段而是改為被包含在ー個原始段中，則主段映射可指示片斷結構，並且隨後第i個並行段的段映射可如下從主段映射推導出演算若原始段的片斷的第一前綴中的媒體數據量為L字節，則頭i個並行段中該前綴聚集的字節總數為ceil (L*Gi)，其中Gi為Fj在j = 1，. . .，i上的和。作為替換實施例的另ー示例，段可包括每個段的原始源媒體數據其後緊隨著該片斷的修複數據的組合，從而得到包含源媒體數據與使用FEC碼從該源媒體數據生成的修複數據的混合的段。作為替換實施例的另ー示例，包含源媒體數據和修複數據的混合的段可被劃分成多個包含源媒體數據和修複數據的混合的並行段。本領域普通技術人員在閱讀本公開之後可以預見其他實施例。在其他實施例中， 可有利地作出以上所公開的發明的組合或子組合。組件的示例安排是出於解說目的示出的，應理解，在本發明的替換實施例中構想了組合、添加、重新安排、及類似方案。因此，儘管本發明是參照示例性實施例描述的，但是本領域技術人員將意識到許多修改是可能的。例如，本文中描述的過程可使用硬體組件、軟體組件和/或其任何組合來實現。在這些情形中，軟體組件可在有形的非瞬態介質上提供以在設有該介質或與該介質分開的硬體上執行。因此，本說明書和附圖被認為是解說性的而非限制性的。然而，顯然可對其作出各種修改和變更而不會脫離所附權利要求中所闡述的本發明的更寬泛的精神和範圍，且本發明旨在涵蓋落在所附權利要求的範圍內的所有修改和等效技術方案。
權利要求
1.一種在其中客戶端設備向媒體攝取系統請求媒體文件的通信系統中的方法，包括 在所述客戶端設備處基於URL構造規則來構造所述媒體文件的文件標識符，其中所述構造規則使得能在所述文件標識符中指定所要求的媒體及相關聯的元數據；向所述媒體攝取系統發送對所述媒體文件的請求，其中所述請求包括所構造的文件標識符。
2.一種在其中客戶端設備從媒體攝取系統接收媒體數據流的通信系統中的方法，包括在所述媒體攝取系統處提供與所述媒體數據流相關聯的媒體呈現描述(MPD)文件；以及在所述MPD內提供媒體段的開始時間，其中所述開始時間被捨入到最近的隨機訪問點，藉此允許以更壓縮的形式傳達開始時間和歷時。
全文摘要
一種塊請求流送系統典型地使用攝取系統來提供此類系統的用戶體驗和帶寬效率的改善，該攝取系統生成將由常規文件伺服器(例如，HTTP、FTP或類似伺服器)供應的形式的數據，其中該攝取系統攝入內容並將其製備為要由該文件伺服器供應的文件或數據元素，該文件伺服器可包括高速緩存。客戶端設備可適配成利用攝取過程以及促成獨立於該攝取過程的更好呈現的改進。客戶端設備和攝取系統可被協調以具有用於作出對HTTP文件名的塊請求的預定義映射和模板，而常規文件伺服器可通過使用URL構造規則來接受這樣的塊請求。可以近似方式指定段大小以得到更高效的組織。
文檔編號H04N21/234GK102577307SQ201080042943
公開日2012年7月11日 申請日期2010年9月22日 優先權日2009年9月22日
發明者B·王, L·威茨薩諾, M·G·路比, M·沃森, P·帕克扎得, T·斯託克漢姆 申請人:高通股份有限公司