TW201408020A - 用於處置低等待時間串流的增強型區塊請求串流系統 - Google Patents

用於處置低等待時間串流的增強型區塊請求串流系統 Download PDF

Info

Publication number
TW201408020A
TW201408020A TW102115099A TW102115099A TW201408020A TW 201408020 A TW201408020 A TW 201408020A TW 102115099 A TW102115099 A TW 102115099A TW 102115099 A TW102115099 A TW 102115099A TW 201408020 A TW201408020 A TW 201408020A
Authority
TW
Taiwan
Prior art keywords
media
segment
time
block
request
Prior art date
Application number
TW102115099A
Other languages
English (en)
Other versions
TWI492598B (zh
Inventor
Michael G Luby
Mark Watson
Lorenzo Vicisano
Payam Pakzad
Bin Wang
Ying Chen
Thomas Stockhammer
Jaber Mohammad Borran
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/456,474 external-priority patent/US9380096B2/en
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of TW201408020A publication Critical patent/TW201408020A/zh
Application granted granted Critical
Publication of TWI492598B publication Critical patent/TWI492598B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Abstract

一種區塊請求串流系統提供對媒體呈現的低等待時間串流。根據編碼協定產生複數個媒體段。每個媒體段包括隨機存取點。根據相同的協定編碼複數個媒體片斷。媒體段是從複數個媒體片斷聚集而成的。

Description

用於處置低等待時間串流的增強型區塊請求串流系統
本發明係關於改善的媒體串流系統和方法，尤其係關於自我調整於網路和緩衝條件以使串流媒體的呈現最佳化並允許對串流媒體資料進行高效的併發或時間分散式投遞的系統和方法。
串流媒體投遞可能變得日益重要，因為在諸如網際網路、蜂巢和無線網路、輸電線網路，及其他類型的網路之類的基於封包的網路上投遞高品質音訊和視訊變得越來越常見。所投遞的串流媒體能被呈現出的品質可取決於數種因素，包括原始內容的解析度(或其他屬性)、原始內容的編碼品質、接收裝置解碼和呈現媒體的能力、在接收器處接收到的訊號的及時性和品質等。為了產生感知到的良好的串流媒體體驗，在接收器處接收到的訊號的傳輸和及時性可能尤其重要。良好的傳輸可以提供在接收器處接收到的串流相對於發送方發送的串流的保真度，而及時性可以代表接收器在初始請求內容之後多快就能開始播出該內容。
媒體投遞系統可表徵為具有媒體源、媒體目的地，及將源和目的地分開的(時間及/或空間上的)通道的系統。典型地，源包括能存取可電子地管理的形式的媒體的發射器，及有能力電子地控制對媒體(或媒體的近似物)的接收並將媒體提供給媒體消費者(例如，具有以某種方式耦合到該接收器、儲存裝置或元件、另一通道等的顯示裝置的使用者)的接收器。
儘管有許多變型是可能的，但在常見的實例中，媒體投遞系統具有能存取電子形式的媒體內容的一或多個伺服器，並且一或多個客戶端系統或裝置向伺服器作出對媒體的請求，而伺服器使用作為該伺服器的一部分的向客戶端處的接收器進行傳送的發射器來輸送該媒體，從而收到的媒體能由該客戶端以某種方式消費。在簡單的實例中，對於給定的請求和回應而言有一個伺服器和一個客戶端，但並非必需如此。
按傳統，媒體投遞系統可表徵為「下載」模型或「串流」模型。「下載」模型可由媒體資料的投遞與該媒體向使用者或接收方裝置的播出之間的時基獨立性來表徵。
作為實例，媒體在被需要或將被使用之前被下載得足夠多，並且在該媒體被使用時，在接收方處已有所需一般多的媒體可用。在下載的上下文中的投遞往往是使用諸如HTTP、FTP或單向傳輸上的檔投遞(FLUTE)之類的檔案傳輸通訊協定來執行的，且投遞速率可由下層的流量及/或壅塞控制協定(諸如TCP/IP)來決定。該流量或壅塞控制協定的 操作可獨立於媒體向使用者或目的地裝置的播出，而播出可與下載併發地發生或在其他某個時間發生。
「串流」模式可由媒體資料的投遞與該媒體向使用者或接收方裝置的播出的時基之間的緊耦合來表徵。在該上下文中的投遞往往是使用串流協定來執行的，諸如用於控制的即時串流協定(RTSP)和用於媒體資料的即時傳輸協定(RTP)。投遞速率可由串流伺服器決定，通常與資料的播出速率匹配。
「下載」模型的一些缺點可能在於，由於投遞與播出之間的時基獨立性，要麼在需要媒體資料供播出時該媒體資料可能不可用(例如，由於可用頻寬小於媒體資料率)，導致播出暫時停止(「停滯」)，而此舉造成不良的使用者體驗；要麼可能要求提前在播出之前很久就下載媒體資料(例如，由於可用頻寬大於媒體資料率)，從而消費掉接收裝置上可能稀缺的儲存資源，並且消費寶貴的網路資源進行投遞，而此舉在內容最終沒有被播出或以其他方式使用的情況下會被浪費掉。
「下載」模型的優點可在於執行此類下載所需的技術(例如，HTTP)非常成熟、被廣泛部署且全面適用於很廣範圍的應用。用於實現此類檔下載的大規模可伸縮性的下載伺服器和解決方案(例如，HTTP Web伺服器和內容投遞網路)可能是現成可用的，從而使得基於該技術的服務部署簡單且成本低廉。
「串流」模型的一些缺點可能在於，一般而言，媒 體資料的投遞速率並不適配於從伺服器到客戶端的連接上的可用頻寬，且需要提供頻寬和延遲擔保的專門的串流伺服器或更複雜的網路架構。儘管存在支援根據可用頻寬來變化投遞資料率的串流系統(例如，Adobe Flash自我調整串流)，但是該等系統在利用所有可用頻寬方面通常不如諸如TCP之類的下載傳輸流量控制協定一般高效。
最近，已開發和部署了基於「串流」和「下載」模型的組合的新型媒體投遞系統。此類模型的實例在本文中被稱為「區塊請求串流」模型，其中媒體客戶端使用諸如HTTP之類的下載協定來向服務基礎設施請求媒體資料區塊。此類系統中的關注點可能是開始播出串流的能力，例如使用個人電腦來解碼和渲染收到的音訊和視訊串流並在電腦螢幕上顯示該視訊以及經由內置揚聲器來播放該音訊，或者作為另一實例，使用機上盒來解碼和渲染收到的音訊和視訊串流並在電視顯示裝置上顯示該視訊及經由身歷聲系統來播放該音訊。
諸如能夠足夠快地解碼源區塊以跟上源串流速率、使解碼等待時間最小化及減少對可用CPU資源的使用之類的其他關注點亦是問題所在。另一關注點是提供穩健和可伸縮的串流投遞解決方案，該解決方案允許系統的元件發生故障而不會不利地影響投遞給接收器的串流的品質。基於在呈現正被分發時關於該呈現的快速改變的資訊，可能發生其他問題。因此，希望具有改善的過程和設備。
一種區塊請求串流系統典型地使用攝取系統來提供此類系統的使用者體驗和頻寬效率的改善，該攝取系統產生將由習知檔案伺服器(例如，HTTP、FTP或類似伺服器)供應的形式的資料，其中該攝取系統攝入內容並將該內容製備為將由可包括或可不包括快取記憶體的該檔案伺服器來供應的檔或資料元素。
根據實施例，一種區塊請求串流系統的媒體伺服器允許對媒體呈現內容的低等待時間串流。用於實況簡檔串流的相對較大的媒體段可從用於低等待時間串流的相對較小的媒體片斷聚集而成。媒體段和媒體片斷是根據相同的編碼協定來編碼的。
以下詳細描述連同附圖將提供對本發明的本質和優點的更好理解。
100‧‧‧區塊串流系統
101‧‧‧區塊供應基礎設施
101(1)‧‧‧區塊供應基礎設施
102‧‧‧攝取內容
103‧‧‧攝取系統
104‧‧‧HTTP串流伺服器
106‧‧‧HTTP快取記憶體
108‧‧‧客戶端
110‧‧‧內容儲存
112‧‧‧請求
114‧‧‧回應
122‧‧‧網路
123‧‧‧區塊選擇器
124‧‧‧區塊請求器
125‧‧‧區塊緩衝器
126‧‧‧緩衝監視器
127‧‧‧媒體解碼器
128‧‧‧媒體換能器
270‧‧‧修復段產生器
300‧‧‧匯流排
302‧‧‧攝取處理器
304‧‧‧記憶體
306‧‧‧磁碟儲存
308‧‧‧視訊顯示單元
310‧‧‧數符號輸入裝置
312‧‧‧網路介面裝置
400‧‧‧匯流排
402‧‧‧客戶端處理器
404‧‧‧記憶體
406‧‧‧磁碟儲存
408‧‧‧視訊顯示單元
410‧‧‧數符號輸入裝置
412‧‧‧網路介面裝置
500‧‧‧MPD
501‧‧‧時段記錄
502‧‧‧表示記錄
503‧‧‧段資訊
504‧‧‧初始化段
505(1)‧‧‧媒體段
510‧‧‧源段
512‧‧‧修復段
700‧‧‧簡單索引
702‧‧‧階層式索引
900‧‧‧中繼資料表
902‧‧‧HTTP串流客戶端
904‧‧‧媒體區塊
906‧‧‧HTTP串流伺服器
1000‧‧‧視訊串流
1002‧‧‧區塊
1004‧‧‧RAP
1200‧‧‧發射器
1202‧‧‧中繼資料
1204‧‧‧可伸縮層1
1206‧‧‧可伸縮層2
1208‧‧‧可伸縮層3
1210‧‧‧接收器
1212‧‧‧媒體呈現
1300‧‧‧步驟
1310‧‧‧步驟
1320‧‧‧步驟
1330‧‧‧步驟
1340‧‧‧步驟
1410‧‧‧步驟
1420‧‧‧步驟
1430‧‧‧步驟
1440‧‧‧步驟
1450‧‧‧步驟
1710‧‧‧步驟
1720‧‧‧步驟
1730‧‧‧步驟
1740‧‧‧步驟
1750‧‧‧步驟
1760‧‧‧步驟
1770‧‧‧步驟
3002‧‧‧媒體段
3004‧‧‧媒體片斷
3006‧‧‧媒體片斷
3008‧‧‧媒體片斷
圖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圖示了檔辨識符構造規則的實例。
圖24(a)至圖24(e)圖示了TCP連接的頻寬波動。
圖25圖示了對來源資料和修復資料的多個HTTP請求。
圖26圖示了帶FEC和不帶FEC的實例頻道換台時間。
圖27圖示了作為圖1中所示的攝取系統一部分的從源段和控制參數產生修復段的修復段產生器的詳情。
圖28圖示了源區塊與修復區塊之間的關係。
圖29圖示了在客戶端處不同時間的實況服務的程序。
圖30圖示了用於低等待時間串流的媒體片斷與諸媒體片斷之間的關係。
在附圖中，相似的項目用相似的標號來引述且在括弧中提供副標以指示相似或相同項目的多個實例。除非另行指出，否則最後的副標(例如，「N」或「M」)並非意在限定於任何特定值，且一個項目的實例數目可與另一項目的實例數目不同，即使在圖示了相同的標號且重複使用了副標時亦然。
如本文中所描述的，串流系統的目標是將媒體從媒體的儲存位置(或正產生該媒體的位置)移到正消費該媒體的位置，即呈現給使用者或以其他方式被人類或電子消費者「用盡」。理想情況下，串流系統可在接收端提供不間斷的重播(或更一般而言，不間斷的「消費」)，且在使用者請求了該串流或該等串流之後不久就能開始播放串流或串流集合。出於效率原因，亦希望每個串流在一旦使用者指示不再需要該串流時，諸如當使用者正從一個串流切換到另一個串流或者該串流服從例如「字幕」串流之類的串流的呈現時就被停下。若諸如視訊之類的媒體分量繼續被呈現，但選擇了不同的串流來呈現該媒體分量，則往往較佳令新的串流佔用有限的頻寬並停止舊的串流。
根據本文中描述的實施例的區塊請求串流系統提供許多益處。應理解，可行的系統無需包括本文中描述的所有特徵，因為一些應用可用不足本文中描述的特徵全體的特徵來提供令人滿意程度適宜的體驗。
HTTP串流
HTTP串流是一種具體的串流類型。在HTTP串流下，源可以是標準web伺服器和內容投遞網路(CDN)並且可使用標準HTTP。該技術可涉及串流分段及使用多個串流，所有該等皆落在標準化HTTP請求的上下文中。諸如視訊之類的媒體可以用多個位元元速率來編碼以構成不同的版本或表示。術語「版本」和「表示」在本文中同義地使用。每個版本或 表示可被分解成較小的片以構成段，片可能在幾秒的量級。每個段隨後可作為單獨的檔被儲存在web伺服器或CDN上。
在客戶端一側，隨後可使用HTTP作出對個體段的請求，該等個體段由客戶端無瑕疵地拼接在一起。客戶端可基於可用頻寬切換到不同的資料率。客戶端亦可請求多個表示，每個表示呈現不同的媒體分量，並且可聯合且同步地呈現該等表示中的媒體。切換的觸發可包括例如緩衝器佔用率和網路量測。當在穩態下操作時，客戶端可調整向伺服器請求的步調以維持目標緩衝器佔用率。
HTTP串流的優點可包括位元元速率自我調整、快速啟動和檢視，及最小程度的不必要投遞。該等優點源於將投遞控製成僅比播出提前很短時間、對可用頻寬作出最大程度的使用(經由變數位元元速率媒體)，及最佳化串流分段和智慧客戶端程序。
媒體呈現描述可被提供給HTTP串流客戶端，以使得客戶端能使用檔(例如以3GPP規定的格式，在本文中稱為3gp段)的集合來向使用者提供串流服務。媒體呈現描述及可能亦有該媒體呈現描述的更新描述了實為結構化的段集合的媒體呈現，每個段包含媒體分量以使得客戶端能以同步方式呈現所包括的媒體並且能提供高級特徵，諸如檢視、切換位元元速率，及聯合呈現不同表示中的媒體分量。客戶端可按不同方式使用媒體呈現描述資訊來得到服務的供給。具體而言，根據媒體呈現描述，HTTP串流客戶端可決定能存取該集合中的何段，從而串流服務內的資料對於客戶端能力及使用者 而言是有用的。
在一些實施例中，媒體呈現描述可以是靜態的，但段可以是動態地建立的。媒體呈現描述可以儘可能緊湊以使該服務的存取和下載時間最小化。其他專用伺服器連通性可被最小化，例如客戶端與伺服器之間一般或頻繁的時基同步。
可以將媒體呈現構造成允許被具有不同能力-諸如存取不同的存取網路類型、不同的當前網路條件、顯示器大小、存取位元元速率和轉碼器支援-的終端存取。客戶端隨後可提取合適的資訊以向使用者提供串流服務。
媒體呈現描述亦可根據要求允許部署靈活性及緊湊性。
在最簡單的情形中，每個替換表示可被儲存在單個3GP檔中，亦即，遵照如3GPP TS26.244中界定的檔，或遵照如ISO/IEC 14496-12或衍生規範中界定的ISO基媒體檔案格式(諸如3GPP技術規範26.244中描述的3GP檔案格式)的任何其他檔。在本文件的其餘部分中，在引述3GP檔時，應理解ISO/IEC 14496-12和衍生規範可將所有所描述的特徵映射到如ISO/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 NetworkTM)、微軟流暢串流(Microsoft Smooth Streaming)及蘋果iPhoneTM串流協定。
通常，每個媒體資料區塊可作為個體檔儲存在伺服器上，且隨後使用諸如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(2)：24-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中描述的彼等之類的鏈式反應碼，及諸如Shokrollahi I中的多級鏈式反應碼。
用於Reed-Solomon碼的變體的FEC解碼過程的實例在Rizzo和XOR-Reed-Solomon中描述。在彼等實例中，解碼可在已接收到充分的來源資料封包和修復資料封包之後應用。解碼過程可能是計算密集的，且取決於可用的CPU資源，解碼過程可能要花費與區塊中的媒體所跨越的時間長度成比例的相當多的時間來完成。接收器在演算開始接收媒體串流與播出該媒體之間所需的延遲時可以計及解碼所需的該時間長度。由於解碼造成的該延遲被使用者感知為使用者對特定媒體串流的請求與開始重播之間的延遲。因此希望使該延遲最小化。
在許多應用中，封包可被進一步細分成對符號應用FEC過程的符號。封包可包含一或多個符號(或者不足一個符號，但通常符號不會被跨封包群拆分，除非已知封包群之間的差錯條件是高度相關的)。符號可具有任何大小，但符號 的大小往往至多等於封包的大小。源符號是編碼要傳送的資料的彼等符號。修復符號是直接或間接地從源符號產生的作為源符號的補充的符號(亦即，若全部源符號皆可用且沒有任何修復符號可用，亦能完全恢復出要傳送的資料)。
一些FEC碼可以是基於區塊的，因為編碼操作取決於區塊中的一或多個符號並且可獨立於不在彼區塊中的符號。經由基於區塊的編碼，FEC編碼器可從彼區塊中的源符號產生該區塊的修復符號，隨後繼續前往下一個區塊且無需參考除了正被編碼的當前區塊的源符號以外的其他源符號。在傳輸中，包括源符號的源區塊可由包括經編碼符號(經編碼符號可以是一些源符號、一些修復符號或兩者)的經編碼區塊來表示。在存在修復符號的情況下，在每個經編碼區塊中，並非所有源符號皆是需要的。
對於一些FEC碼，特別是Reed-Solomon碼，編碼和解碼時間可能會隨著每源區塊的經編碼符號數目的增長而增長到不切實際的地步。因此，在實踐中，每源區塊能產生的經編碼符號總數往往存在切合實際的上限(255是一些應用的大致的切合實際的上限)，尤其是在由定製硬體執行Reed-Solomon編碼或解碼過程的典型情形中，例如，使用作為DVB-H標準的一部分被包括的Reed-Solomon碼來保護串流以對抗封包丟失的MPE-FEC過程是在蜂巢式電話內的專門硬體中實現的，該專門硬體限於每源區塊總共有255個Reed-Solomon經編碼符號。由於往往要求將符號放入分開的封包有效載荷中，因此此對正被編碼的源區塊的最大長度設 置了切合實際的上限。例如，若封包有效載荷限於1024位元組或更少且每個封包攜帶一個經編碼符號，則經編碼源區塊可至多為255千位元組，並且此對於源區塊本身的大小當然亦是上限。
諸如能夠足夠快地解碼源區塊以跟上源串流速率、使由FEC解碼引入的解碼等待時間最小化，及在FEC解碼期間的任何時間點僅使用接收裝置上可用CPU的一小部分等其他關注點由本文中描述的元素來解決。
需要提供穩健和可伸縮的串流投遞解決方案，該串流投遞解決方案允許系統的元件發生故障而不會不利地影響投遞給接收器的串流的品質。
區塊請求串流系統需要支援對呈現的結構或中繼資料的改變，例如對可用媒體編碼的數目的改變或是對媒體編碼的參數(諸如位元元速率、解析度、縱橫比、音訊或視訊轉碼器或編解碼參數)的改變，或是對諸如URL之類的與內容檔相關聯的其他中繼資料的改變。此類改變可能是出於多個原因而必需的，包括將較大呈現的諸如廣告或不同段之類的來自不同源的內容編輯在一起，作為例如由於配置改變、裝備故障或從裝備故障恢復或其他原因造成的服務基礎設施改變的結果而變得必要的對URL或其他參數的修改。
存在可由持續更新的播放清單檔來控制呈現的方法。由於該檔被持續更新，因此以上描述的至少一些改變能在該等更新中作出。習知方法的缺點在於客戶端裝置必須不斷地檢索(亦稱為「輪詢」)播放清單檔，從而對服務基礎設 施造成負荷，並且該檔可能沒有被快取記憶體得比更新間隔更久，從而使得服務基礎設施的任務困難得多。此由本文中的元素來解決，從而在無需由客戶端對中繼資料檔進行不斷輪詢的情況下提供以上描述的此種的更新。
典型地從廣播分發中知曉的尤其存在於實況服務中的另一問題是缺乏供使用者觀看在比使用者加入節目的時間早時廣播的內容的能力。典型地，本端個人錄製消耗不必要的本機儲存區，或者在客戶端沒有調諧到該節目或受到內容保護條例禁止時不可能進行本端個人錄製。網路錄製和時移觀看是較佳的，但要求使用者與伺服器的個體連接及與實況服務分開的投遞協定和基礎設施，從而造成重複的基礎設施和顯著的伺服器成本。此亦由本文中描述的元素來解決。
系統概覽
參照圖1描述本發明的一個實施例，圖1圖示實施本發明的區塊請求串流系統的簡化圖。
在圖1中，圖示了區塊串流系統100，區塊串流系統100包括區塊供應基礎設施(「BSI」)101，BSI 101又包括攝取系統103，攝取系統103用於攝取內容102、製備彼內容並將彼內容打包以經由將彼內容儲存在攝取系統103和HTTP串流伺服器104兩者均可存取的內容儲存110中來由HTTP串流伺服器104供應。如圖所示，系統100亦可包括HTTP快取記憶體106。在操作中，諸如HTTP串流客戶端之類的客戶端108向HTTP串流伺服器104發送請求112並從HTTP串流伺服器104或HTTP快取記憶體106接收回應114。在每種情形中，圖1中所 示的元素可至少部分地在軟體中實現，其中包括在處理器或其他電子裝置上執行的程式碼。
內容可包括電影、音訊、2D平面視訊、3D視訊、其他類型的視訊、圖像、定時文字、定時中繼資料或類似物。一些內容可涉及要以定時方式呈現或消費的資料，諸如用於隨正被播出的其他媒體一起呈現輔助資訊(台識別、廣告、股價、FlashTM序列等)的資料。亦可以使用組合其他媒體及/或超越僅音訊和視訊的其他混合呈現。
如圖2中所示，媒體區塊可被儲存在區塊供應基礎設施101(1)內，區塊供應基礎設施101(1)可以是例如HTTP伺服器、內容投遞網路裝置、HTTP代理、FTP代理或伺服器，或其他某種媒體伺服器或系統。區塊供應基礎設施101(1)連接到網路122，網路122可以是例如諸如網際網路之類的網際網路協定(「IP」)網路。區塊請求串流系統客戶端被示為具有6個功能元件，即：區塊選擇器123，區塊選擇器123被提供以上描述的中繼資料並執行從由該中繼資料指示的複數個可用區塊之中選擇要請求的區塊或部分區塊的功能；區塊請求器124，區塊請求器124接收來自區塊選擇器123的請求指令並執行在網路122上向區塊供應基礎設施101(1)發送對指定區塊、區塊的部分，或多個區塊的請求及接收包括該區塊的資料作為回復所必要的操作；及區塊緩衝器125；緩衝監視器126；媒體解碼器127；及促成媒體消費的一或多個媒體換能器128。
由區塊請求器124接收到的區塊資料被傳遞到儲存媒體資料的區塊緩衝器125進行臨時儲存。替換地，接收到的 區塊資料可如圖1中所示地被直接儲存到區塊緩衝器125中。媒體解碼器127由區塊緩衝器125來提供媒體資料並對該資料執行向媒體換能器128提供合適的輸入所必要的變換，媒體換能器128以適合使用者或其他消費的形式來渲染該媒體。媒體換能器的實例包括諸如存在於行動電話、電腦系統或電視中的彼等之類的視覺顯示裝置，並且亦可包括諸如揚聲器或頭戴式耳機之類的音訊渲染裝置。
媒體解碼器的實例可以是將在H.264視訊編碼標準中描述的格式的資料變換成視訊訊框的類比或數位表示(諸如每一訊框或取樣有相關聯的呈現時戳的YUV格式圖元映射)的功能。
緩衝監視器126接收關於區塊緩衝器125的內容的資訊，並且基於該資訊及可能亦有其他資訊向區塊選擇器123提供輸入，該輸入被用來決定對要請求的區塊的選擇，如本文中所描述的。
在本文中使用的術語中，每個區塊具有「播出時間」或「歷時」，該「播出時間」或「歷時」表示接收器以正常速度播放彼區塊中所包括的媒體要花的時間量。在一些情形中，區塊內的媒體的播出可能取決於已接收到來自先前區塊的資料。在罕見的情形中，區塊中的一些媒體的播出可能取決於後續區塊，在此種情形中，區塊的播出時間是參照該區塊內不參照後續區塊就能播出的媒體來界定的，且後續區塊的播出時間增大該區塊內只能在已接收到該後續區塊之後才能播出的媒體的播出時間。由於在區塊中包括取決於後續 區塊的媒體是罕見的情形，因此在本案的其餘部分中，假定一個區塊中的媒體不取決於後續區塊，但是應注意，本領域技藝人士將認識到此種變形可被輕易地添加到以下描述的實施例。
接收器可具有諸如「暫停」、「快進」、「倒退」等控制，該等控制可導致區塊經由以不同速率播放來被消費，但是若接收器能獲得並解碼每個連貫的區塊序列的集總時間等於或少於排除該序列中的最末區塊情況下的集總播放時間，則接收器能不停滯地向使用者呈現該媒體。在本文中的一些描述中，媒體串流中的特定位置被稱為該媒體中的特定「時間」，該特定「時間」對應於媒體播出的開始與到達視訊串流中的該特定位置的時間之間會流逝的時間。媒體串流中的時間或位置是習知概念。例如，在視訊串流包括24訊框每秒的場合，第一訊框可以被稱為具有t=0.0秒的位置或時間，且第241訊框可被稱為具有t=10.0秒的位置或時間。自然，在基於訊框的視訊串流中，位置或時間無需是連續的，因為該串流中從第241訊框的第一位元直至第242訊框的第一位元之前的每個位元可以全都具有相同的時間值。
採用以上術語，區塊請求串流系統(BRSS)包括向一或多個內容伺服器(例如，HTTP伺服器、FTP伺服器等)作出請求的一或多個客戶端。攝取系統包括一或多個攝取處理器，其中攝取處理器(即時地或非即時地)接收內容，處理該內容以供BRSS使用並將該內容及可能亦連同由攝取處理器產生的中繼資料一起儲存在內容伺服器可存取的儲存中。
BRSS亦可包含與內容伺服器協調的內容快取記憶體。內容伺服器和內容快取記憶體可以是習知的HTTP伺服器和HTTP快取記憶體，HTTP伺服器和HTTP快取記憶體接收包括URL的HTTP請求形式的對檔或段的請求，並且該等請求亦可包括位元組範圍以請求不足由該URL指示的檔或段的全部。客戶端可包括習知的HTTP客戶端，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-2 TS內部時基達成的音訊/視訊同步的MPEG-2 TS封包串流。
使用訊號傳遞及/或區塊建立來使串流更高效
在區塊請求串流系統中可以使用或不使用數種特徵以提供改善的效能。效能可係關於不停滯地播出呈現、在頻寬約束內獲得媒體資料，及/或在客戶端、伺服器及/或攝取系統處有限的處理器資源內如此做的能力。現在將描述該等特徵中的一些。
段內的索引
為了編制對電影片斷的部分獲取請求，可向客戶端告知檔或段內的片斷中所包含的所有媒體分量在解碼或呈現時間的位元組偏移量和開始時間，及亦有何種片斷始於或包含隨機存取點(且因此適合用作替換表示之間的切換點)， 其中該資訊往往被稱為段索引或段映射。在解碼或呈現時間的開始時間可直接表達或者可表達為相對於參考時間的△。
該時間和位元組偏移量索引資訊可能每電影片斷需要至少8位元組資料。作為實例，對於具有500ms電影片斷的單個檔內所包含的2小時電影，此將會是總共約112千位元組資料。在開始呈現時下載該資料的全部可能導致顯著的額外啟動延遲。然而，該時間和位元組偏移量資料可被階層式編碼，從而客戶端能迅速找到與呈現中希望開始的點有關的小時間塊和偏移量資料。該資訊亦可分佈在段內，以使得對段索引的某種細化可與媒體資料交錯地放置。
注意，若表示是按時間分段成多個段的，則使用該階層式編碼可能是不必要的，因為每個段的完整的時間和偏移量資料可能已經十分小。例如，若段是一分鐘而非以上實例中的2小時，則時間-位元組偏移量索引資訊約為1千位元組資料，1千位元組資料通常可裝進單個TCP/IP封包內。
有不同選項可能用於向3GPP檔添加片斷時間和位元組偏移量資料：首先，可出於此目的使用電影片斷隨機存取包(「MFRA」)。MFRA提供表，表可輔助讀者使用電影片斷來尋找檔中的隨機存取點。為支援該功能，MFRA順帶地包含帶有隨機存取點的MFRA包的位元組偏移量。MFRA可被放在檔末尾處或附近，但並非必需如此。經由從檔末尾掃瞄電影片斷隨機存取偏移量包並使用電影片斷隨機存取偏移量包中的大小資訊，就能夠定位到電影片斷隨機存取包的開頭。然而， 將MFRA放在末尾來進行HTTP串流典型地需要至少3到4個HTTP請求來存取所要資料：至少一個用於從檔末尾請求MFRA，一個用於獲得MFRA並且最後一個用於獲得該檔中的所要片斷。因此，放在開頭可能是可取的，因為如此就可在單個請求中與第一媒體資料一起下載mfra。另外，對HTTP串流使用MFRA可能是效率不高的，因為「MFRA」中除了時間和moof_偏移量以外的其他任何資訊皆是不需要的，且指定偏移量而非長度可能需要更多位元。
其次，可以使用項定位包(ILOC)。「ILOC」經由定位中繼資料資源的包容檔、中繼資料資源在彼檔內的偏移量及中繼資料資源的長度來提供該檔或其他檔中的中繼資料資源的目錄。例如，系統可將所有被外部引用的中繼資料資源整合到一個檔中，相應地重新調整檔偏移量和檔引用。然而，「ILOC」意欲提供中繼資料的位置，因此可能很難使「ILOC」與真正的中繼資料共存。
最後且可能最適合的是規定稱為時間索引包(「TIDX」)的新包，時間索引包專用於以高效方式提供確切的片斷時間或歷時及位元組偏移量。此點在下節中更詳細地描述。具有相同功能性的替換包可以是段索引包(「SIDX」)。在本文中，除非另行指出，否則該兩者可以是可互換的，因為兩種包皆提供了以高效方式提供確切的片斷時間或歷時及位元組偏移量的能力。以下提供TIDX與SIDX之間的差異。如何互換TIDX包和SIDX包應當是明顯的，因為該兩種包均實現段索引。
段索引
段具有識別出的開始時間和識別出的位元組數。多個片斷可被級聯成單個段，且客戶端可發出識別該段內與所請求的片斷或片斷子集相對應的具體位元組範圍的請求。例如，在使用HTTP作為請求協定時，HTTP範圍頭部可用於此目的。該辦法要求客戶端能存取該段的「段索引」，該「段索引」指定不同片斷在該段內的位置。該「段索引」可作為中繼資料的一部分來提供。該辦法具有以下結果：與在每個區塊被保持在單獨的檔中的辦法相比，需要建立和管理的檔少得多。對建立、傳遞和儲存非常大量的檔(諸如對於1小時呈現，該等檔可延伸到好幾千個文件)的管理可能是複雜的且容易出錯，因此減少檔數量代表著優點。
若客戶端僅知曉段的較小部分的所要開始時間，則客戶端可請求整個檔，隨後從頭至尾讀取該檔以決定合適的播出起始位置。為了改進頻寬利用率，段可包括索引檔作為中繼資料，其中索引檔映射個體區塊的位元組範圍與該等區塊所對應的時間範圍，稱為段索引或段映射。該中繼資料可被格式化為XML資料或者該中繼資料可以是二進位的，例如遵循3GPP檔案格式的原子和包結構。索引可以是簡單的，其中每個區塊的時間和位元組範圍相對於檔的開始是絕對的，或者每個區塊的時間和位元組範圍可以是階層式的，其中一些區塊被編組成父區塊(且彼等父區塊被編組成祖父區塊，等等)且給定區塊的時間和位元組範圍是相對於該區塊的父區塊的時間及/或位元組範圍來表達的。
示例索引映射結構
在一個實施例中，媒體串流的一個表示的原始來源資料可被包含在一或多個在本文中被稱為「媒體段」的媒體檔中，其中每個媒體段包含用於重播該媒體的連續時間段的媒體資料，例如5分鐘的媒體重播。
圖6圖示媒體段的實例整體結構。在每個段內，在源段開頭或遍佈整個源段，亦可存在包括時間/位元組偏移量段映射的索引資訊。一個實施例中的時間/位元組偏移量段映射可以是時間/位元組偏移量對的清單(T(0),B(0))、(T(1),B(1))、...、(T(i),B(i))、...、(T(n),B(n))，其中T(i-1)代表該段內相對於該媒體在所有媒體段中的初始開始時間用於重播第i個媒體片斷的開始時間，T(i)代表第i個片斷的結束時間(且因此代表下一片斷的開始時間)，並且位元組偏移量B(i-1)是該源段內相對於該源段開頭第i個媒體片斷開始之處的資料的開頭的相應位元組索引，且B(i)是第i個片斷的相應結束位元組索引(且因此是下一片斷的首個位元組的索引)。若段包含多個媒體分量，則可以絕對方式為該段之每一者分量提供T(i)和B(i)，或者T(i)和B(i)可相對於用作參考媒體分量的另一媒體分量來表達。
在該實施例中，源段中的片斷數目為n，其中n在段與段之間可有所不同。
在另一實施例中，段索引中關於每個片斷的時間偏移量可以用第一片斷的絕對開始時間及每個片斷的歷時來決定。在此種情形中，段索引可以記載第一片斷的開始時間及 該段中所包括的所有片斷的歷時。段索引亦可以僅記載片斷子集。在該情形中，段索引記載被界定為一或多個連貫片斷的子段的歷時，該子段在包容段的末尾或在下一子段的開頭處結束。
對於每個片斷，亦可以有指示該片斷是否始於或包含檢視點的值，亦即，在某點處，彼點之後的媒體皆不取決於彼點之前的任何媒體，且因此自彼片斷前行的媒體能獨立於先前片斷地播出。檢視點一般而言是媒體中能獨立於所有先前的媒體地開始播出之處的點。圖6亦圖示源段的可能段索引的簡單實例。在彼實例中，時間偏移量值以毫秒為單位，且因此該源段的首個片斷自該媒體開頭20秒處開始，且首個片斷具有485毫秒的播出時間。首個片斷的開始的位元組偏移量為0，且首個片斷的末尾/第二片斷的開始的位元組偏移量為50245，且因此首個片斷的大小為50245位元組。若片斷或子段並非始於隨機存取點，但該片斷或子段中包含隨機存取點，則可以提供開始時間與實際RAP時間之間的解碼時間或呈現時間差。此使得在切換到該媒體段的情形中客戶端能準確地知曉「切換自」的表示需要一直被呈現到的時間。
補充地或代替地，可以使用簡單的或階層式的索引、雛菊鏈索引及/或混合索引。
由於不同軌跡的取樣歷時可能不是相同的(例如，視訊取樣可能播放33ms，而音訊取樣可能持續80ms)，因此電影片斷中的不同軌跡可能不是在正好相同的時間開始和結束的，亦即，音訊可能比視訊略早或略遲開始，而在前一片 斷中可能正好是相反情形以作為補償。為避免多義性，在時間和位元組偏移量資料中指定的時戳可相對於特定軌跡來指定，且此軌跡對於每個表示可以是相同的軌跡。通常此將是視訊軌跡。此允許客戶端在切換表示時能確切地識別下一視訊訊框。
儘管有上述問題，但在呈現期間可注意維持軌跡時標與呈現時間之間的嚴格關係，以確保流暢播出及維持音訊/視訊同步。
圖7圖示了一些實例，諸如簡單索引700和階層式索引702。
以下提供包含段映射的包的兩個具體實例，一個稱為時間索引包(‘TIDX’)且一個稱為(‘SIDX’)。該定義遵循根據ISO基媒體檔案格式的包結構。用於此類包以界定類似句法且具有相同語義和功能性的其他設計對於讀者應當是明顯的。
時間索引包
定義
包類型：‘tidx’
容器：檔
強制性的：否
數量：任何數目0或1
時間索引包可提供將檔的某些區域與呈現的某些時間區間相關聯的一組時間和位元組偏移量索引。時間索引包可包括目標類型(targettype)欄位，目標類型欄位指示所引 用的資料的類型。例如，具有目標類型「moof」的時間索引包提供在時間和位元組偏移量兩者意義上對檔中所包含的媒體片斷的索引。具有目標類型「時間索引包(Time Index Box)」的時間索引包可被用來構造階層式時間索引，從而允許檔的使用者迅速導航至該索引的所需部分。
段索引可例如包含以下句法：
語義
targettype(目標類型)：為該時間索引包引用的包資料的類型。此目標類型可以是電影片斷頭部(「moof」)或時間索引包(「tidx」)。
time-reference_track_id(時間參考軌跡id)：指示指定該索引中的時間偏移量時參照的軌跡。
number_of_elements(元素數目)：由該時間索引包索引的元素的數目。
first_element_offset(首個元素偏移量)：首個被索引的元素自該檔的開始起的位元組偏移量。
first_element_time(首個元素時間)：首個被索引的元素的開始時間，使用由「時間參考軌跡id」識別的軌跡的媒體頭部包中指定的時標。
random_access_flag(隨機存取標誌)：若元素的開始時間是隨機存取點則為1。否則為0。
length(長度)：被索引的元素以位元組計的長度。
deltaT(△T)：該元素的開始時間與下一元素的開始時間之間的差量，該時間差是由「時間參考軌跡id」識別的軌跡的媒體頭部包中指定的時標的形式。
段索引包
段索引包(‘sidx’)提供對段中的電影片斷和其他段索引包的緊湊索引。段索引包中有兩個循環結構。第一循環記載子段的第一取樣，亦即，由第二循環引用的第一電影片斷中的取樣。第二循環提供該子段的索引。‘sidx’包的容器是該檔或直接是段。
句法
語義：
reference_track_ID(參考軌跡ID)提供參考軌跡的軌跡ID。
track_count(軌跡計數)：接下來的循環中被索引的軌跡的數目(1或更大)；reference_count(參考計數)：由第二循環索引的元素的數目(1或更大)；track_ID(軌跡ID)：軌跡片斷被包括在由該索引識別的首個電影片斷中的彼軌跡的ID；該循環中有恰好一個「軌跡ID」等於「參考軌跡ID」。
decoding_time(解碼時間)：由第二循環中的第一項引用的電影片斷中由「軌跡ID」識別的軌跡中的首個取樣的解碼時間，以該軌跡的時標來表達(如在該軌跡的媒體頭部包的時標欄位中記載的)；reference_type(參考類型)：在設為0時指示該引用是對電影片斷(‘moof’)包的引用；在設為1時指示該引用是對段索引(‘sidx’)包的引用；reference_offset(引用偏移量)：從繼包容段索引包之後的首個位元組至被引用包的首個位元組的以位元組計的距離；subsegment_duration(子段歷時)：當引用是對段索引包的引用時，該欄位攜帶彼包的第二循環中的「子段歷時」欄位的總和；當引用是對電影片斷的引用時，該欄位攜帶參考軌跡中、所指示的電影片斷及直至該循環中的下一條目記載的首個電影片斷或該子段末尾(取較早者)的後續電 影片斷中的取樣的取樣歷時總和；該歷時以該軌跡的時標來表達(如在該軌跡的媒體頭部包的時標欄位中記載的)；contains_RAP(包含RAP)：當引用是對電影片斷的引用時，則若彼電影片斷內「軌跡ID」等於「參考軌跡ID」的彼軌跡的的軌跡片斷包含至少一個隨機存取點，則該位元可為1，否則該位元設為0；當引用是對段索引的引用時，則僅在彼段索引中的任何引用的該位元被設為1時該位元才被設為1，否則設為0；RAP_delta_time(RAP_△時間)：若「包含RAP」為1，則提供隨機存取點(RAP)的呈現(合成)時間；若「包含RAP」為0則保留值0。該時間表達為在由該條目記載的子段的首個取樣的解碼時間與「軌跡ID」等於「參考軌跡ID」的軌跡中隨機存取點的呈現(合成)時間之間的差量。
TIDX與SIDX之間的差異
TIDX和SIDX就索引而言提供相同的功能性。SIDX的第一循環作為補充亦提供首個電影片斷的全域時基，但該全域時基亦可被包含在該電影片斷自身中，該全域時基或者是絕對的或者是相對於參考軌跡的。
SIDX的第二循環實現TIDX的功能性。具體地，SIDX准許具有由「參考類型」所指的每個索引的引用的目標的混合，而TIDX僅僅是要麼只引用TIDX要麼只引用MOOF。TIDX中的「元素數目」對應於SIDX中的「引用計數」，TIDX中的「時間參考軌跡ID」對應於SIDX中的「參考軌跡ID」，TIDX中的「首個元素偏移量」對應於第二循環的首個條目中的「 引用偏移量」，TIDX中的「首個元素時間」對應於第一循環中的「參考軌跡」的「解碼時間」，TIDX中的「隨機存取標誌」對應於SIDX中的「包含RAP」，後者亦具有額外的自由-在SIDX中，RAP可以不一定要放在片斷開始處，且因此需要「RAP_△時間」，TIDX中的「長度」對應於SIDX中的「引用偏移量」，並且最後TIDX中的△T對應於SIDX中的「子段歷時」。因此，該兩個包的功能性是等效的。
可變區塊大小控制和子GoP區塊
對於視訊媒體而言，視訊編碼結構與供請求的區塊結構之間的關係可能是重要的。例如，若每個區塊始於諸如隨機存取點(「RAP」)之類的檢視點且每個區塊代表相等的視訊時間段，則視訊媒體中的至少一些檢視點的定位是固定的且檢視點在視訊編碼內將以有規律的間隔出現。如視訊編碼領域中的技藝人士公知的，若檢視點是根據視訊訊框之間的關係來放置的，並且具體而言若檢視點被放置在與先前訊框幾乎沒有多少共性的訊框處，則壓縮效率可得以改進。由此要各區塊代表等量時間的要求對視訊編碼構成了約束，從而使得壓縮可能是未臻最優的。
希望允許視訊呈現內的檢視點的位置由視訊編碼系統來選取，而非要求檢視點位於固定位置。允許視訊編碼系統選取檢視點得到改善的視訊壓縮，並且因此使用給定的可用頻寬能提供更高的視訊媒體品質，從而得到改善的使用者體驗。當前的區塊請求串流系統可能要求所有區塊具有相同的歷時(以視訊時間計)，且每個區區塊必須始於檢視點且 此因此是現有系統的缺點。
現在描述提供勝於上述系統的優點的新穎的區塊請求串流系統。在一個實施例中，視訊分量的第一版本的視訊編碼過程可被配置成選取檢視點的位置以力圖最佳化壓縮效率，但要求對檢視點之間的歷時有最大限度。後一個要求的確限制了編碼過程對檢視點的選取且因此降低了壓縮效率。然而，倘若檢視點之間的歷時的最大限度不是太小(例如，大於約1秒)，則壓縮效率的降低與若檢視點要求有規律的固定位置所招致的壓縮效率降低相比是微小的。此外，若對檢視點之間的歷時的最大限度是幾秒，則該壓縮效率的降低與檢視點的完全自由定位相比一般是微乎其微的。
在包括本實施例的許多實施例中，可能有一些RAP不是檢視點，亦即，可能有訊框是兩個連貫檢視點之間的沒有被選取為檢視點的RAP，例如由於該RAP在時間上太接近周圍的檢視點，或者由於該RAP之前或之後的檢視點與該RAP之間的媒體資料量太少。
媒體呈現的所有其他版本內的檢視點的位置可被約束成與第一(例如，最高媒體資料率)版本中的檢視點相同。與允許編碼器自由選取檢視點相比，此的確降低了該等其他版本的壓縮效率。
使用檢視點典型地要求訊框是能獨立解碼的，此一般導致彼訊框的低壓縮效率。不被要求能獨立解碼的訊框可參考其他訊框中的資料來編碼，此一般而言將使彼訊框的壓縮效率提高達取決於待編碼訊框與參考訊框之間的共性量的 量。對檢視點定位的高效選取較佳選取與先前訊框具有低共性的訊框作為檢視點訊框，並藉此使得由於以能獨立解碼的方式編碼該訊框招致的壓縮效率懲罰最小化。
然而，訊框與潛在可能的參考訊框之間的共性的程度是跨該內容的不同表示而高度相關的，因為原始內容是相同的。因此，令其他變體中的檢視點與第一變體中的檢視點具有相同位置的約束對於壓縮效率而言並沒有帶來很大差別。
檢視點結構較佳被用來決定區塊結構。較佳地，每個檢視點決定區塊的開始，且可能存在涵蓋兩個連貫檢視點之間的資料的一或多個區塊。由於為以良好壓縮進行編碼的目的使得檢視點之間的歷時不是固定的，因此不要求所有區塊皆具有相同的播出歷時。在一些實施例中，區塊在內容的各版本之間是對準的-亦即，若在內容的一個版本中有跨越特定訊框群的區塊，則在該內容的另一版本中亦有跨越相同的訊框群的區塊。內容的給定版本的各區塊不重疊，且內容的每個訊框被包含在每個版本的恰好一個區塊內。
使得能允許高效利用檢視點之間的可變歷時及因此的可變歷時GoP的特徵是可被包括在段中或經由其他手段提供給客戶端的段索引或段映射，亦即，此是可被提供的與該表示中的此段相關聯的包括該呈現的每個區塊的開始時間和歷時的中繼資料。當使用者已請求該呈現在段內的特定點開始時，客戶端可在決定要在何區塊開始該呈現時使用該段索引資料。若沒有提供此類中繼資料，則呈現僅能在內容開頭 或在接近所要點的隨機或近似點開始(例如，經由將所請求的起始點(以時間計)除以平均區塊歷時以提供起始區塊的索引來選取起始區塊)。
在一個實施例中，每個區塊可作為單獨的檔來提供。在另一個實施例中，多個連貫區塊可被聚集成單個檔以構成段。在該第二實施例中，可以提供每個版本的中繼資料，中繼資料包括每個區塊的開始時間和歷時及該區塊在此檔內開始處的位元組偏移量。該中繼資料可回應於初始協定請求而提供，亦即，可與段或檔分開地獲得，或者可被包含在與區塊本身相同的檔或段內，例如位於檔開頭處。如對於本領域技藝人士將清楚的，該中繼資料可以諸如gzip或△編碼之類的壓縮形式或以二進位形式來編碼，以減少向客戶端傳輸該中繼資料所需的網路資源。
圖6圖示段索引的實例，其中區塊具有可變大小，且其中區塊的範疇是部分GoP，亦即，一個RAP與下一個RAP之間的媒體資料的部分量。在該實例中，檢視點由RAP指示符來指示，其中RAP指示符值1指示該區塊始於或包含RAP或檢視點，並且其中RAP指示符0指示該區塊不包含RAP或檢視點。在該實例中，頭三個區塊，亦即，即位元組0到157033構成第一GoP，第一GoP具有1.623秒的呈現歷時，第一GoP的呈現時間從進入內容中的20秒走到21.623秒。在該實例中，頭三個區塊中的第一區塊包括0.485秒的呈現時間，且包括該段中的媒體資料的頭50245位元組。在該實例中，區塊4、5和區塊6構成第二GoP，區塊7和區塊8構成第三GoP，並且區塊9、10和 區塊11構成第四GoP。注意，媒體資料中可能存在沒有被指定為檢視點、且因此在段映射中沒有作為RAP被訊號傳遞的其他RAP。
再次參照圖6，若客戶端或接收器想要存取始於進入媒體呈現中約22秒的時間偏移量處的內容，則客戶端可首先使用諸如以下更詳細地描述的MPD之類的其他資訊來首先決定該相關媒體資料的確在該段內。客戶端可例如使用HTTP位元組範圍請求來下載該段的第一部分以獲得段索引，其在本例中只有幾個位元組。使用該段索引，客戶端可決定自己應當下載的第一區塊是時間偏移量至多為22秒且始於RAP、即實為檢視點的首個區塊。在該實例中，儘管區塊5具有小於22秒的時間偏移量，亦即，區塊5的時間偏移量為21.965秒，但段索引指示區塊5並非始於RAP，且由此基於段索引，客戶端改為選擇下載區塊4，因為區塊4開始時間至多為22秒，亦即，區塊4的時間偏移量為21.623秒，區塊4始於RAP。因此，基於段索引，客戶端將作出始於位元組偏移量157034的HTTP範圍請求。
若段索引不可用，則客戶端可能不得不在下載該資料之前先下載所有之前的157034位元組的資料，導致啟動時間或頻道換台時間長得多，及浪費地下載了無用的資料。替換地，若段索引不可用，則客戶端可近似出所要資料在該段內的開始之處，但該近似可能是不良的並且該近似可能錯過合適的時間且隨後需要後退，此再次增加了啟動延遲。
一般而言，每個區塊涵蓋媒體資料的一部分，該部 分連同先前各區塊一起可由媒體播放機播出。因此，此種成區塊結構及向客戶端訊號傳遞通知段索引成區塊結構(無論包含在段內還是經由其他手段提供給客戶端)的機制能顯著改善客戶端提供快速頻道換台，及在面臨網路變動和中斷時的無瑕疵播出的能力。如由段索引實現的對可變歷時區塊及僅涵蓋GoP的部分的區塊的支援能顯著改善串流體驗。例如，再次參照圖6及以上描述的其中客戶端想要在進入呈現中約22秒處開始播出的實例，客戶端可經由一或多個請求來請求區塊4內的資料並隨後一旦該區塊可用就將該區塊內的資料饋送給媒體播放機以開始重播。因此，在該實例中，一旦在客戶端處接收到區塊4的42011位元組，播出就開始，由此實現快速的頻道換台時間。若相反在播放將要起動之前需要客戶端先請求整個GoP，則頻道換台時間將較長，因為有144211位元組的資料。
在其他實施例中，RAP或檢視點亦可出現在區塊當中，且段索引中可以有指示該RAP或檢視點在區塊或片斷內何處的資料。在其他實施例中，時間偏移量可以是區塊內的第一訊框的解碼時間，而非區塊內的第一訊框的呈現時間。
圖8(a)和圖8(b)圖示了對跨複數個版本或表示對準的檢視點結構的可變區塊大小控制的實例；圖8(a)圖示了在媒體串流的複數個版本上有對準的檢視點的可變區塊大小控制，而圖8(b)圖示了在媒體串流的複數個版本上有非對準的檢視點的可變區塊大小控制。
跨頂部以秒圖示時間，且該兩個表示的兩個段的區 塊和檢視點以該等區塊和檢視點相對於該等時線的時基的形式從左到右圖示，並且因此所示的每個區塊的長度與每個區塊的播出時間成比例而不是與區塊中的位元組數目成比例。在該實例中，該兩個表示的兩個段的段索引對於檢視點將具有相同的時間偏移量，但檢視點之間具有潛在不同數目的區塊或片斷，且由於每個區塊中的媒體資料量不同，因此區塊有不同的位元組偏移量。在該實例中，若客戶端想要在約23秒的呈現時間處從表示1切換到表示2，則客戶端可請求直至表示1的段中的區塊1.2，並自區塊2.2起開始請求表示2的段，且因此切換將發生在與表示1中的檢視點1.2重合的呈現處，檢視點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的操作可被修改以使得每當區塊選擇器123被要求從不同於先前所選版本的表示選擇區塊時，區塊的第一訊框不晚於上次所選區塊的最末訊框之後的訊框的最晚區塊被選取。
該最近描述的實施例可消除約束除第一版本以外的 其他版本內的檢視點位置的要求，且因此提高了該等版本的壓縮效率，從而對於給定的可用頻寬得到更高品質的呈現並且此是改善的使用者體驗。進一步的考慮是執行跨內容的多個編碼(版本)的檢視點對準功能的視訊編碼工具可能並非普遍可用，因此該最近描述的實施例的優點在於可以使用目前可用的視訊編碼工具。另一優點在於內容的不同版本的編碼可並行進行而完全無需不同版本的編碼過程之間的協調。另一優點在於內容的額外版本可在稍後的時間被編碼並被添加到呈現，而不必向編碼工具提供具體檢視點位置的列表。
一般而言，在畫面被編碼為畫面群(GoP)的場合，序列中的第一畫面可以是檢視點，但並非總是必需如此。
最優區塊劃分
區塊請求串流系統中的一個關注問題是例如視訊媒體之類的經編碼媒體的結構與用於區塊請求的區塊結構之間的互動。如視訊編碼領域中的技藝人士將知曉的，往往是此種情形：每個視訊訊框的經編碼表示所需的位元數目有時實際上逐訊框變化。因此，收到資料量與由彼資料編碼的媒體歷時之間的關係可能不是直截了當的。此外，在區塊請求串流系統內將媒體資料分成區塊增加了進一維的複雜性。具體而言，在一些系統中，區塊的媒體資料可能在整個區塊被接收到之前不會被播出，例如，使用擦除碼的區塊內的媒體資料佈局或者區塊內的媒體取樣之間的依存性就可能導致此種性質。由於區塊大小與區塊歷時之間的該等複雜互動及可能需要在開始播出之前接收整個區塊，因此客戶端系統通常採 納保守辦法，其中在播出開始之前緩衝媒體資料。此類緩衝導致頻道換台時間很長並且因此使用者體驗不良。
Pakzad描述了「區塊劃分方法」，該等方法是基於資料串流的底層結構來決定如何將資料串流劃分成毗連區塊的新穎且高效的方法，且Pakzad進一步描述了該等方法在串流系統的上下文中的若干優點。現在描述本發明將Pakzad的區塊劃分方法應用於區塊請求串流系統的進一步實施例。該方法可包括將待呈現媒體資料安排成大致的呈現時間次序，以使得媒體資料的任何給定元素(例如，視訊訊框或音訊取樣)的播出時間與任何毗鄰媒體資料元素的播出時間相差小於所設閾值。如此排序的媒體資料按Pakzad的話而言可被視為資料串流，且應用於該資料串流的任何Pakzad方法識別該資料串流的區塊邊界。任一對毗鄰區塊邊界之間的資料按本案的話而言被視為「區塊」，且本案的方法被應用以提供該媒體資料在區塊請求串流系統內的呈現。如本領域技藝人士在閱讀本案之際將清楚的，Pakzad中揭示的方法的若干優點由此可在區塊請求串流系統的上下文中實現。
如Pakzad中描述的，對段的區塊結構(包括涵蓋部分GoP或涵蓋一個以上GoP的部分的區塊)的決定會影響客戶端實現快速頻道換台時間的能力。在Pakzad中，提供了在提供目標啟動時間的情況下將提供區塊結構和目標下載速率的方法，該區塊結構和目標下載速率將確保若客戶端在任何檢視點開始下載表示並在該目標啟動時間已流逝之後開始播出，則只要在每個時間點該客戶端已下載的資料量至少為目標 下載速率乘以自下載開始以來流逝的時間，則播出就將無瑕疵地繼續。有利的是使客戶端能存取目標啟動時間和目標下載速率，因為此向客戶端提供了決定何時開始在最早的時間點播出該表示的手段，並且只要下載滿足上述條件就允許客戶端繼續播出該表示。因此，稍後描述的方法提供了用於在媒體呈現描述內包括目標啟動時間和目標下載速率的手段，從而該方法可被用於上述目的。
媒體呈現資料模型
圖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的實例。
在本文中描述的方法中，提供包括關於客戶端可用的媒體呈現的表示的資訊的「媒體呈現描述」。表示可以是替換性的，替換性的意義是指客戶端選出不同替換項之一，或者表示可以是互補性的，互補性的意義是指客戶端選擇其 中若干個表示、每個表示可能亦來自一組替換項，並且聯合地呈現該等表示。表示可有利地被指派到群，其中客戶端被程式設計或配置成理解：對於一群中的表示，該等表示各自是彼此的替換項，而來自不同群的表示使得能聯合地呈現一個以上表示。換言之，若群中有一個以上表示，則客戶端從彼群挑選一個表示，從下一群挑選一個表示等等以構成呈現。
描述表示的資訊可有利地包括所應用的媒體轉碼器的詳情，包括解碼該表示所需的彼等轉碼器的簡檔和等級、視訊訊框率、視訊解析度及資料率。接收媒體呈現描述的客戶端可使用該資訊來事先決定表示是否適合解碼或呈現。此代表了優點，因為若區別資訊將僅被包含在表示的二進位資料中，則將必需請求來自所有表示的二進位資料並解析和提取相關資訊才能發現關於區別資訊的適用性的資訊。該多個請求及對資料的解析並附提取可能要花一些時間，此會導致啟動時間很長並且因此使用者體驗不良。
此外，媒體呈現描述可包括基於時辰來限制客戶端請求的資訊。例如對於實況服務，客戶端可被限於請求呈現中接近「當前廣播時間」的部分。此代表了優點，因為對於實況廣播，可能希望從服務基礎設施中清空比當前廣播時間早所設閾值以上廣播的內容的資料。此對於服務基礎設施內的儲存資源的重複使用而言是可取的。此亦可能取決於所提供的服務類型而變為可取的，例如，在一些情形中，由於接收客戶端裝置的某個訂閱模型，可使得呈現僅有實況可用， 而可使得其他媒體呈現有實況和點播可用，並可使得其他呈現對於第一類客戶端裝置僅有實況可用，對於第二類客戶端裝置僅有點播可用，及對於第三類客戶端裝置有實況或點播的組合可用。(下文)「媒體呈現資料模型」小節中描述的方法允許向客戶端通知此類策略，從而客戶端對於服務基礎設施中可能不可用的資料可避免作出請求並調節對使用者的供應。作為替換方案，例如，客戶端可向使用者呈現該資料不可用的通知。
在本發明的進一步實施例中，媒體段可順應於ISO/IEC 14496-12或衍生規範中描述的ISO基媒體檔案格式(諸如3GPP技術規範26.244中描述的3GP檔案格式)。(上文)「3GPP檔案格式的使用」該小節描述了對ISO基媒體檔案格式的新穎增強，從而准許在區塊請求串流系統內高效地使用該檔案格式的資料結構。如該參考文件中描述的，可在檔內提供資訊從而准許媒體呈現的時間段與檔內的位元組範圍之間快速且高效的映射。媒體資料本身可根據ISO/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)：客戶端可預緩衝媒體串流的最大時間量。該時基可將串流與客戶端被限於下載超出該最大預緩衝時間的漸進式下載區別開。該值可以不出現，指示沒有預緩衝意義上的限制可應用。
安全保護區間實況服務(SafetyGuardIntervalLiveService)：關於伺服器上的實況服務的最大周轉時間的資訊。向客戶端提供了在當前時間有何種資訊已可存取的指示。若預期客戶端和伺服器按UTC時間操作且不提供緊密的時間同步，則該資訊可能是必需的。
時移緩衝器深度(TimeShiftBufferDepth)：關於客戶端在實況服務中相對於當前時間回移多遠的資訊。藉由該深度的擴展，無需在服務供應中作出特定改變亦可准許時移觀看和追看服務。
准許本端快取記憶體(LocalCachingPermitted)：該標誌指示HTTP客戶端在已播放所下載的資料之後是否能本端快取記憶體該資料。
實況呈現區間(LivePresentationInverval)：經由指定開始時間(StartTimes)和結束時間(EndTimes)來包含其間呈現可用的時間區間。「開始時間」指示服務的開始時間而「結束時間」指示服務的結束時間。若沒有指定結束時間，則結束時間在當前時間是未知的，且「更新頻率」可確保客戶端能在服務的實際結束時間之前存取到結束時間。
點播可用性區間(OnDemandAvailabilityInterval)：該呈現區間指示該服務在網路上的可用性。可以提供多個呈現區間。HTTP客戶端在任何指定時間訊窗以外可能不能存取該服務。經由提供「點播區間」，可指定額外的時移觀看。對於實況服務，該屬性亦可出現。倘若對於實況服務該屬性出現，則伺服器可確保在所有所提供的可用性區間期間，客戶端能以點播服務的形式來存取該服務。因此，「實況呈現區間」不可與任何「點播可用性區間」重疊。
MPD檔資訊動態(MPDFileInfoDynamic)：描述媒體呈現中的檔的預設動態構造。更多細節在下文中提供。若對若干或所有替換表示使用相同規則，則在MPD等級上的預設指定可以節省不必要的重複。
MPD轉碼器描述(MPDCodecDescription)：描述媒體呈現中的主預設轉碼器。更多細節在下文中提供。若對若干或所有表示使用相同的轉碼器，則在MPD等級上的預設指定可以節省不必要的重複。
MPD移動包頭部大小不變(MPDMoveBoxHeaderSizeDoexNotChange)：指示移動包頭部 的大小在整個媒體呈現內各個體檔之間是否改變的標誌。該標誌可用來最佳化下載並且可以僅在特定段格式(尤其是段格式的段包含moov頭部的彼等段格式)的情形中才出現。
FileURI模式(FileURIPattern)：客戶端用來產生對媒體呈現內的檔的請求訊息的模式。不同屬性准許為媒體呈現內的每個檔產生唯一性的URI。基URI可以是HTTP URI。
替換表示：描述表示列表。
「替換表示(AlternativeRepresentation)」元素：封裝一個表示的所有中繼資料的XML元素。「替換表示」元素可包含以下屬性和元素。
表示ID(RepresentationID)：媒體呈現內該特定替換表示的唯一性ID。
靜態檔資訊(FilesInfoStatic)：提供一個替換呈現的所有檔的起始時間和URI的顯式列表。檔清單的該靜態提供可提供對媒體呈現有確切時基描述的優點，但可能不夠緊湊，尤其是若替換表示包含許多檔。另外，該等檔案名稱可具有任意的名稱。
動態檔資訊(FilesInfoDynamic)：提供構造一個替換呈現的起始時間和URI的清單的隱式方式。該檔清單的動態提供可提供具有更緊湊表示的優點。若僅提供了起始時間序列，則此處時基優點亦成立，但檔案名稱將基於檔模式URI(FilePatternURI)來動態地構造。若僅提供每個段的歷時，則表示是緊湊的並且可適合用在實況服務內，但檔的產生可由全域時基來掌管。
AP移動包頭部大小不變(APMoveBoxHeaderSizeDoesNotChange)：指示移動包頭部的大小在替換描述內各個體檔之間是否改變的標誌。該標誌可用來最佳化下載並且可以僅在特定段格式(尤其是段格式的段包含moov頭部的彼等段格式)的情形中才出現。
AP轉碼器描述(APCodecDescription)：描述替換呈現中的檔的主轉碼器。
媒體描述元素
媒體描述(MediaDescription)：可封裝該表示中所包含的媒體的所有中繼資料的元素。具體而言，該元素可包含關於該替換呈現中的軌跡以及推薦的軌跡編組(若適用)的資訊。「媒體描述」屬性包含以下屬性：軌跡描述(TrackDescription)：封裝該表示中所包含的媒體的所有中繼資料的XML屬性。「軌跡描述」屬性包含以下屬性：軌跡ID(TrackID)：替換表示內的軌跡的唯一性ID。此可以用在軌跡是編組描述的一部分的情形中。
位元元速率(Bitrate)：軌跡的位元元速率。
軌跡轉碼器描述(TrackCodecDescription)：包含關於該軌跡中使用的轉碼器的所有屬性的XML屬性。「軌跡轉碼器描述」屬性包含以下屬性：媒體名稱(MediaName)：界定媒體類型的屬性。媒體類型包括「音訊」、「視訊」、「文字」、「應用程式」和「訊息」。
轉碼器(Codec)：包括簡檔和等級的轉碼器類型。
語言標記(LanguageTag)：語言標記(若適用)。
最大寬度(MaxWidth)、最大高度(MaxHeight)：對於視訊而言，是指被包含的視訊以圖元計的高度和寬度。
取樣速率(SamplingRate)：對於音訊而言的取樣速率。
群描述(GroupDescription)：基於不同參數向客戶端提供對合適編組的推薦的屬性。
群類型(GroupType)：基於該類型，客戶端可決定如何編組軌跡。
媒體呈現描述中的資訊有利地被HTTP串流客戶端用來在合適的時間執行對檔/段或檔/段部分的請求，以選擇來自例如在存取頻寬、顯示能力、轉碼器能力等等以及諸如語言等使用者偏好的意義上匹配資訊能力的勝任表示的段。此外，由於「媒體呈現描述」描述了時間對準且被映射到全域等時線的表示，因此客戶端在正在進行的媒體呈現期間亦可以使用MPD中的資訊來發起合適的行動以跨表示進行切換、聯合地呈現各表示，或在媒體呈現內進行檢視。
訊號傳遞通知段開始時間
表示可按時間被拆分成多個段。一個段的最後片斷與下一段的下一片斷之間存在軌跡間時基問題。此外，在使用有恆定歷時的段的情形中，存在另一個時基問題。
對每個段使用相同歷時可具有MPD既緊湊又呈靜態 的優點。然而，每個段可能仍始於隨機存取點。因此，要麼可將視訊編碼約束成在該等特定點提供隨機存取點，要麼實際的段歷時可能沒有像在MPD中指定的一般精確。可能希望串流系統對視訊編碼過程不施加不必要的限制，且因此第二選項可能是較佳的。
具體而言，若在MPD中將檔歷時指定為d秒，則第n個檔可始於時間(n-1)d處或緊隨時間(n-1)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元素表達的實況呈現區間的任何範圍之外，則該實況呈現的被描述的段皆是不可存 取的，若在客戶端處的當前壁鐘時間「現在」落在實況呈現區間內，則該實況呈現的被描述的段中的至少某些段可能是可存取的。
對可存取段的限制由以下值來掌管：壁鐘時間「現在」(如客戶端可用的)。
例如在媒體呈現描述中指定為「時移緩衝器深度」的所准許的時移緩衝器深度tTSB。
客戶端在相對事件時間t1可能僅被允許請求開始時間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更新，所有表示的段可在非連續點結束。此一般至少意味著該非連續點之前的最末段與先前各段具有不同歷時。訊號傳遞通知段歷時可涉及指示所有段具有相同的歷時或者為每個段指示單獨的歷時。可能希望具有關於段歷時列表的緊湊表示，此在有許多段具有相同歷時的情形中是高效的。
一個表示或一組表示之每一者段的歷時可有利地用單個串來實現，該串指定了從非連續更新的開始(亦即，該 時段的開始)直至MPD中描述的最末媒體段為止的單個區間的所有段歷時。在一個實施例中，該元素的格式是與包含段歷時條目列表的產生式相符的文字串，其中每個條目包含歷時屬性dur及該屬性的可任選的乘數mult，該乘數指示該表示包含第一條目的<mult>個、歷時為第一條目的<dur>的段，隨後是第二條目的<mult>個、歷時為第二條目的<dur>的段，依此類推。
每個歷時條目指定一或多個段的歷時。若<dur>值後面跟有「＊」字元和數位，則該數位指定具有該歷時(以秒計)的連貫段的數目。若不存在乘數符號「＊」，則段數目為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」包的有效性不相交即可。例如，有了時段邊界的定義，舊時段中的‘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」可能發生改變的時間點。由於出於頻寬和可伸縮性原因一般應當避免頻繁「輪詢」MPD以檢查更新，因此對MPD的更新可在段檔自身中「帶內」地指示，亦即，每個媒體段可具有指示更新的選項。取決於上文的段格式(a)到段格式(c)，可訊號傳遞通知不同的更新。
一般而言，可有利地在段內的訊號中提供以下指示：MPD可能在請求該表示內的下一段或段的開始時間大於當前段的開始時間的任何下一段之前被更新的指示符。更新可事先被宣告，以指示該更新只需要在晚於該下一段的任何段發生。在媒體段的定位符改變了的情形中，該MPD更新亦可用來更新二進位表示中繼資料，諸如電影頭部。另一訊號可指示在該段完成時，不應再請求更多將時間提前的段。
在段是根據段格式(c)來格式化，亦即，每個媒體段可包含諸如電影頭部之類的自初始化中繼資料的情形中，則可添加另一訊號，以指示後續段包含經更新的電影頭部(moov)。此有利地允許將電影頭部包括在段中，但該電影頭部僅在若先前段指示電影頭部更新的情況下或在當切換表示時進行檢視或隨機存取的情形中才需要被客戶端請求。在其他情形中，客戶端可發出對段的位元組範圍請求，該位元組範圍請求排除電影頭部的下載，因此有利地節省了頻寬。
在另一實施例中，若訊號傳遞通知了MPD更新指示，則該訊號亦可包含關於經更新的媒體呈現描述的諸如URL之類的定位符。在非連續更新的情形中，經更新的MPD可使用諸如新時段和舊時段之類的有效性屬性來描述更新前後的 呈現。此可以有利地被用來准許如以下進一步描述的時移觀看，但亦有利地允許MPD更新在該MPD更新所包含的改變生效之前任何時間被訊號傳遞通知。客戶端可立即下載新MPD並將新MPD應用於正在進行的呈現。
在具體實現中，對媒體呈現描述、moov頭部或呈現結束的任何改變的訊號傳遞通知可被包含在遵循使用ISO基媒體檔案格式的包結構的段格式的規則來格式化的串流資訊包中。該包可為任何不同更新提供專門訊號。
串流信息包
定義
包類型：‘sinf’
容器：無
強制性的：否
數量：0或1。
串流資訊包包含關於檔是何種串流呈現的一部分的資訊。
句法
語義
streaming_information_flags(串流資訊標誌)包含以下各項中的0個或更多個的邏輯或：0x00000001後續有電影頭部更新
0x00000002呈現描述更新
0x00000004呈現結束
當且僅當呈現描述更新(Presentation Description update)標誌被設定時mpd_location(mpd位置)出現，並且mpd_location(mpd位置)提供關於新的媒體呈現描述的統一資源定位符。
實況服務的MPD更新的示例使用情形
假設服務提供方想要使用本文中描述的增強型區塊請求串流來提供實況足球事件。或許幾百萬使用者可能想要存取該事件的呈現。該實況事件被請求暫停時的休息或該行動中的其他間歇偶發地打斷，在此期間可加插廣告。典型情況下，對於休息的確切時基完全或幾乎沒有事先通知。
服務提供方可能需要提供冗餘的基礎設施(例如，編碼器和伺服器)以在實況事件期間有任何元件故障情形中能進行無瑕疵轉切。
假設使用者Anna在公車上用她的行動裝置存取該服務並且該服務立即可用。她旁邊坐著另一使用者Paul，Paul在他的膝上型裝置上觀看該事件。進了球且兩個人在相同的時間慶祝該事件。Paul告訴Anna該比賽中的第一個球甚至更激動人心並且Anna使用該服務從而她能回看30分鐘前的事件。在看了該進球之後，她回到實況比賽。
為了解決該使用情形，服務提供方應當能夠更新MPD，向客戶端訊號傳遞通知有經更新的MPD可用，並准許客戶端存取串流服務以使得該MPD能接近即時地呈現該資料。
按與段投遞非同步的方式對MPD進行更新是可行的，如本文中別處所解釋的。伺服器可向接收器提供MPD在一定時間裡不更新的擔保。伺服器可依賴於當前MPD。然而，當MPD在某個最小更新期之前就被更新時無需任何顯式訊號傳遞。
完全同步的播出是幾乎難以達成的，因為客戶端可能在對不同的MPD更新實例進行操作因此客戶端可能有漂移。使用MPD更新，伺服器可傳達改變並且客戶端可被提醒有改變，即使在呈現期間亦然。逐段基礎上的帶內訊號傳遞可被用來指示MPD的更新，因此更新可能被限於段邊界，但在絕大多數應用中此應當是可接受的。
可以添加如下的MPD元素，該MPD元素提供MPD的以壁鐘時間計的發佈時間以及添加在段開頭以訊號傳遞通知要求MPD更新的可任選MPD更新包。該更新可如同MPD一般階層式地進行。
MPD「發佈時間」提供MPD的唯一性辨識符及MPD何時發出。MPD「發佈時間」亦提供用於更新程序的錨。
MPD更新包可存在於MPD中的「styp」包之後，並且由包類型=「mupe」界定，不需要容器、不是強制性的且具有數量0或1。MPD更新包包含關於段是何者媒體呈現的一部 分的資訊。
實例句法如下：
MPDUpdateBox(MPD更新包)類的各種物件的語義可如下：mpd_information_flags(mpd資訊標誌)：以下各項中的0個或更多個的邏輯或：
i. 0x00 現在的媒體呈現描述更新
ii. 0x01 將來的媒體呈現描述更新
iii. 0x02 呈現結束
iv. 0x03-0x07 保留
new_location flag(新位置標誌)：若置為1，則在mpd_location(mpd位置)中指定的新位置處有新的媒體呈現描述可用。
latest_mpd_update time(最新mpd更新時間)：指定相對於最新MPD的MPD發出時間最晚必需進行MPD更新的時間(以ms計)。客戶端可選擇在客戶端與現在之間的任何時 間更新MPD。
mpd_location(mpd位置)：當且僅當「新位置標誌」被設定時出現，且若如此，則「mpd位置」提供關於新的媒體呈現描述的統一資源定位符。
若更新所使用的頻寬成問題，則伺服器可供應針對某些裝置能力的MPD以使得只有該等部分被更新。
時移觀看和網路PVR
在時移觀看得到支援時，可能在該通信期的壽命時間裡碰巧有兩個或兩個以上MPD或電影頭部是有效的。在此種情形中，經由在必要時更新MPD，但添加有效性機制或時段概念，便可對整個時間訊窗皆有有效的MPD存在。此意味著伺服器可確保任何MPD和電影頭部在落在用於時移觀看的有效時間訊窗內的任何時間段上皆是被宣告的。由客戶端來確保客戶端的當前呈現時間的可用MPD和中繼資料是有效的。亦可支援僅使用少量的MPD更新來將實況通信期遷移到網路PVR通信期。
特殊媒體段
當在區塊請求串流系統內使用ISO/IEC 14496-12的檔案格式時的問題在於，如上文描述的，將呈現的單個版本的媒體資料儲存在按連貫時間段安排的多個檔中可能是有利的。此外，將每個檔安排成始於隨機存取點可能是有利的。此外，可能有利的是在視訊編碼過程期間選取檢視點的位置並基於在編碼過程期間作出的對檢視點的選取來將呈現分段成各自始於檢視點的多個檔，其中每個隨機存取點可以置於 檔開頭亦可以不置於檔開頭，但其中每個檔始於隨機存取點。在具有上述性質的一個實施例中，呈現中繼資料或媒體呈現描述可包含每個檔的確切歷時，其中歷時例如被認為表示檔的視訊媒體的開始時間與下一檔的視訊媒體的開始時間之差。基於呈現中繼資料中的該資訊，客戶端能夠構造媒體呈現的全域等時線與每個檔內的媒體的局部等時線之間的映射。
在另一實施例中，經由改為指定每個檔或段具有相同歷時可有利地減小呈現中繼資料的大小。然而，在此種情形中並且在根據上述方法來構造媒體檔的場合，每個檔的歷時可能並不嚴格等於在媒體呈現描述中指定的歷時，因為在自該檔開始起恰好過了該指定歷時的點處可能並無隨機存取點存在。
現在描述本發明的又一實施例，用於在即使有以上提及的矛盾的情況下亦能實現區塊請求串流系統的正確操作。在該方法中，可在每個檔內提供如下的元素，該元素指定該檔內的媒體的局部等時線(該檔內的媒體的局部等時線指根據ISO/IEC 14496-12的從時戳0開始的、可供對照著來指定該檔中的媒體取樣的解碼和合成時戳的等時線)向全域呈現等時線的映射。該映射資訊可包括全域呈現時間中的與局部檔等時線中的0時戳相對應的單個時戳。該映射資訊可替換地包括偏移值，該偏移值根據呈現中繼資料中提供的資訊來指定與局部檔等時線中的0時戳相對應的全域呈現時間與同檔開始相對應的全域呈現時間之間的差量。
此類包的實例可例如是軌跡片斷解碼時間(‘tfdt’)包或軌跡片斷調整包(‘tfad’)連同軌跡片斷媒體調整(‘tfma’)包。
包括段列表產生的實例客戶端
現在將描述實例客戶端。該客戶端可被用作伺服器用來確保MPD的恰當產生和更新的參考客戶端。
HTTP串流客戶端由MPD中提供的資訊來指導。假定客戶端能存取客戶端在時間T(亦即，客戶端能成功接收MPD的時間)接收到的MPD。決定成功接收可包括客戶端獲得經更新的MPD或客戶端驗證出該MPD自先前的成功接收以來尚未被更新過。
以下介紹實例客戶端行為。為了向使用者提供連續串流服務，客戶端首先解析MPD並且在計及如以下詳述的可能使用播放清單或使用URL構造規則的段清單產生程序的情況下為每個表示建立在當前系統時間的客戶端本端時間可存取的段的列表。隨後，客戶端基於表示屬性中的資訊及其他資訊(例如可用頻寬和客戶端能力)選擇一或多個表示。取決於編組，表示可自立呈現或與其他表示聯合呈現。
對於每個表示，客戶端獲取諸如該表示的「moov」頭部之類的二進位中繼資料(若有)，及所選表示的媒體段。客戶端經由可能使用段列表之類以請求段或段的位元組範圍來存取媒體內容。客戶端可在開始該呈現之前初始地緩衝媒體，並且一旦該呈現已開始，客戶端就經由在計及MPD更新程序的情況下不斷請求段或段部分來繼續消費該媒體內容 。
客戶端可在計及經更新的MPD資訊及/或來自客戶端環境的經更新資訊(例如，可用頻寬的改變)的情況下切換表示。以對包含隨機存取點的媒體段的任何請求，客戶端就可切換到不同的表示。在前移，亦即，當前系統時間(稱為「現在時間」，用於表示相對於呈現的時間)前進時，客戶端消費可存取的段。隨著「現在時間」中的每次前進，客戶端有可能根據本文中指定的程序擴展每個表示的可存取段的列表。
若尚未到達媒體呈現結束且若當前重播時間落在客戶端預計會用盡任何正在消費或將要消費的表示的MPD中所描述的媒體中的媒體的閾值以內，則客戶端可請求MPD的更新，該更新帶有新的取回時間「接收時間T」。一旦接收到，客戶端隨後計及有可能經更新的MPD和新時間T來產生可存取段列表。圖29圖示了在客戶端處不同時間的實況服務的程序。
可存取段列表產生
假定HTTP串流客戶端能存取MPD並且可能想要產生對於壁鐘時間「現在」而言可存取的段的列表。客戶端以某個精度同步到全域時間基準，但有利地不要求直接同步到HTTP串流伺服器。
每個表示的可存取段列表較佳界定為段開始時間和段定位符的列表對，其中不失一般性，段開始時間可界定為是相對於表示的開始而言的。表示的開始可與時段的開始對 準(若應用該概念)。否則，表示開始可在媒體呈現的開始處。
客戶端使用例如本文中進一步界定的URL構造規則和時基。一旦獲得了所描述段的列表，該列表被進一步限於可存取的段，該等段可以是完整媒體呈現的段的子集。該構造由時鐘在客戶端「現在」時間的當前值來掌管。一般而言，段僅在一組可用性時間以內的任何「現在」時間可用。對於落在該訊窗以外的「現在」時間，則沒有段可用。此外，對於實況服務，假定某個時間「檢查時間(checktime)」提供關於將此媒體描述到進入將來多遠的資訊。「檢查時間」是在MPD記載的媒體時間軸上界定的；當客戶端的重播時間到達檢查時間時，客戶端有利地請求新MPD。當客戶端的重播時間到達檢查時間時，其有利地請求新MPD。
隨後，段清單由檢查時間連同MPD屬性TimeShiftBufferDepth(時移緩衝器深度)進一步限制，以使得可用媒體段僅有媒體段的開始時間與表示開始時間之和落入「現在」減去時移緩衝器深度減去上個被描述的段的歷時與檢查時間或「現在」中的較小值之間的區間的彼等段。
可伸縮區塊
有時，可用頻寬下降得如此之低，從而接收器處當前正在接收的一或多個區塊變得不大可能被及時完全接收以供不暫停呈現地播出。接收器可能事先偵測到此類情形。例如，接收器可決定自己正在接收每6單位的時間編碼5單位的媒體的區塊，並且具有4單位的媒體的緩衝器，因此接收器可 能預期不得不將該呈現停滯或暫停到大約24單位的時間以後。在充分注意到此點的情況下，接收器可經由例如放棄當前的區塊串流之類來對此類情形作出反應並開始請求來自該內容的不同表示(諸如每單位播出時間使用較少頻寬的表示)的一或多個區塊。例如，若接收器切換到其中對於相同大小的區塊而言，區塊所編碼的視訊時間至少多了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.264/SVC中描述的可伸縮視訊編碼技術。可用來產生具有上述性質的層的技術的另一實例是如ITU-T標準H.264/AVC中提供的時間可伸縮性層技術。
在該等實施例中，中繼資料可在MPD中或在段自身中提供，從而使得能構造對任何給定區塊的個體層及/或層組合及/或多個區塊的給定層及/或多個區塊的層組合的請求。例如，構成區塊的層可被儲存在單個檔內且可提供指定該檔內與個體層相對應的位元組範圍的中繼資料。
能夠指定位組範圍的檔下載協定(例如HTTP 1.1)可被用來請求個體層或多個層。此外，如本領域技藝人士在查閱本案之際將清楚的，以上描述的涉及可變大小的區塊及可變的區塊組合的構造、請求和下載的技術亦可應用於本上下文。
組合
現在描述數個實施例，該等實施例可有利地由區塊請求串流客戶端採用以經由使用如以上描述地劃分成層的媒 體資料來達成相比於現有技術在使用者體驗上的改善及/或在服務基礎設施容量要求上的減少。
在第一實施例中，可應用區塊請求串流系統的已知技術，該等技術的修改在於內容的不同版本在一些情形中由層的不同組合所取代。換言之，在現有系統可提供內容的兩種相異表示的場合，此處描述的增強型系統便可提供兩個層，其中現有系統中內容的一個表示在位元速率、品質及可能亦有其他度量方面類似於增強型系統中的第一層，而現有系統中內容的第二表示在位元速率、品質及可能亦有其他度量方面類似於增強型系統中該兩個層的組合。因此，該增強型系統內要求的儲存容量相比於現有系統中要求的儲存容量得以減小。此外，現有系統的客戶端可發出對一個表示或另一表示的區塊的請求，而該增強型系統的客戶端可發出對區塊的第一層或兩層的請求。因此，該兩個系統中的使用者體驗是相似的。此外，提供了改善的快取記憶體，因為即使是對於不同的品質，使用的亦是共用的段，由此段被快取記憶體的概度性更高。
在第二實施例中，採用現在描述的層方法的增強型區塊請求串流系統中的客戶端可為媒體編碼的若干層中的每一層維護分開的資料緩衝器。如對於客戶端裝置內的資料管理的領域中的技藝人士而言將清楚的，該等「分開的」緩衝器可經由為該等分開的緩衝器分配實體上或邏輯上分開的記憶體區域或經由其他技術來實現，其中所緩衝的資料被儲存在單個或多個記憶體區域中且來自不同層的資料的分開是經 由使用包含對來自分開的層的資料的儲存位置的引用的資料結構來邏輯地達成的，且因此在下文中，術語「分開的緩衝器」應當被理解為包括其中相異層的資料可被分開識別的任何方法。客戶端基於每個緩衝器的佔用率發出對每個區塊的個體層的請求，例如該等層可按優先順序次序排序以使得對來自一個層的資料的請求在優先順序次序上較低的層的任何緩衝器的佔用率低於該較低層的閾值的情況下不會被發出。在該方法中，對接收來自優先順序次序上較低的層的資料給予優先，以使得若可用頻寬降至比亦接收優先順序次序上較高的層所要求的頻寬低，則僅請求該等較低層。此外，與不同層相關聯的閾值可以不同，以使得例如較低層具有較高閾值。在可用頻寬改變以使得較高層的資料不能在區塊的播出時間之前被接收到的情形中，則較低層的資料將必然已被接收到且因此呈現能單單用該等較低層來繼續進行。緩衝器佔用率的閾值可按資料位元組、緩衝器中包含的資料的播出歷時、區塊數目或任何其他合適的量測的形式來界定。
在第三實施例中，第一實施例和第二實施例的方法可被組合以使得提供多個媒體表示，每個媒體表示包括層的子集(如同第一實施例中一樣)並且使得第二實施例被應用於表示內的層的子集。
在第四實施例中，第一實施例、第二實施例及/或第三實施例的方法可與其中提供內容的多個獨立表示的實施例相組合，以使得例如該等獨立表示中的至少一個獨立表示包括應用第一實施例、第二實施例及/或第三實施例的技術的多 個層。
高級緩衝管理器
與緩衝監視器126(參見圖2)相組合，可使用高級緩衝管理器來最佳化客戶端方的緩衝器。區塊請求串流系統想要確保媒體播出能迅速開始並平滑地繼續，與此同時向使用者或目的地裝置提供最大程度的媒體品質。此可能要求客戶端請求具有最高媒體品質、但亦能迅速開始並在此後被及時接收以便在不會迫使呈現中發生暫停的情況下播出的區塊。
在使用高級緩衝管理器的實施例中，該管理器決定要請求媒體資料的何者區塊及何時作出彼等請求。可例如向高級緩衝管理器提供要呈現的內容的中繼資料集，該中繼資料包括內容可用的表示清單及每個表示的中繼資料。表示的中繼資料可包括關於表示的資料率及其他參數的資訊，諸如視訊、音訊或其他轉碼器和編解碼參數、視訊解析度、解碼複雜性、音訊語言及會影響客戶端處對表示的選取的任何其他參數。
表示的中繼資料亦可包括該表示已被分段成的區塊的辨識符，該等辨識符提供客戶端請求區塊所需的資訊。例如，在請求協定是HTTP的場合，該辨識符可以是HTTP URL可能亦連同額外資訊，該額外資訊識別由該URL所識別的檔內的位元組範圍或時間跨度，該位元組範圍或時間跨度識別由該URL所識別的檔內的特定區塊。
在具體實現中，高級緩衝管理器決定接收器何時作 出對新區塊的請求並且高級緩衝管理器自身可能處置該請求的發送。在新穎的態樣，高級緩衝管理器根據在使用過多頻寬與串流播出期間用盡媒體之間進行平衡的平衡比的值來對新區塊作出請求。
緩衝監視器126從區塊緩衝器125接收到的資訊可包括對何時接收到媒體資料、已接收到多少、對媒體資料的播出何時已開始或停止，及媒體播出的速度等的每個事件的指示。基於該資訊，緩衝監視器126可演算代表當前緩衝器大小的變數B 當前 。在該等實例中，B 當前 代表客戶端或其他一或多個裝置緩衝器中包含的媒體量並且可以時間單位來量測，從而B 當前 代表若不再接收更多的區塊或部分區塊則播出該一或多個緩衝器中所儲存的區塊或部分區塊所表示的所有媒體將花費的時間量。因此，B 當前 代表客戶端處可用但尚未播放的媒體資料按正常播出速度的「播出歷時」。
隨著時間流逝，B 當前 的值將隨著媒體被播出而減小並且會在每次接收到區塊的新資料時增大。注意，出於本解釋的目的，假定區塊是在彼區塊的全部資料在區塊請求器124處可用時被接收的，但亦可以改為使用其他措施以例如計及部分區塊的接收。在實踐中，對區塊的接收可發生在時段上。
圖13圖示了在媒體被播出並且區塊被接收時B 當前 的值隨時間的變化。如圖13中所示，對於小於t 0 的時間，B 當前 的值為0，指示尚未接收到資料。在t 0 ，第一區塊被接收並且B 當前 的值增大到等於所接收的區塊的播放歷時。此時，播出尚未 開始且因此B 當前 的值保持恆定直至時間t 1 ，此時第二區塊抵達並且B 當前 增大該第二區塊的大小。此時，播出開始並且B 當前 的值開始線性減小直至時間t 2 ，此時第三區塊抵達。
B 當前 的累進以此「鋸齒」方式繼續，每次接收到區塊時階躍地增大(在時間t 2 、t 3 、t 4 、t 5 和t 6 )並在其間隨著資料被播出而平滑地減小。注意，在該實例中，播出是以該內容的正常播出速率來進行的，並且因此區塊接收之間的曲線斜率恰好為-1，意味著對於流逝的每一秒真正時間，有一秒的媒體資料被播放。在基於訊框的媒體以給定訊框數每秒(例如24訊框每秒)播出時，斜率-1將由指示每個個體資料訊框的播出的小階躍函數來近似，例如每訊框播出時-1/24秒的步長。
圖14圖示B 當前 隨時間進化的另一個實例。在該實例中，第一區塊在t 0 抵達並且播出立即開始。區塊抵達和播出繼續直至時間t 3 ，此時B 當前 的值到達0。在此種情況發生時，沒有更多媒體資料可供播出，從而迫使媒體呈現暫停。在時間t 4 ，第四區塊被接收並且播放可恢復。該實例因此圖示其中對第四區塊的接收晚於所需從而導致播出暫停及因此導致不良使用者體驗的情形。因此，高級緩衝管理器及其他特徵的目標是降低該事件的概率，與此同時維持高媒體品質。
緩衝監視器126亦可演算另一度量B 比率 (t)，B 比率 (t)為給定的時間段中接收到的媒體與該時間段的長度之比。更具體而言，B 比率 (t)等於T 收到 /(T 現在 -t)，其中T 收到 是在自t直至當前時間T 現在 的該時間段中接收到的媒體量(以媒體播出時間來 度量)，t是比當前時間早的某個時間。
B 比率 (t)可用於量測B 當前 的變化率。B 比率 (t)=0是其中自時間t起尚未接收到資料的情形；假定媒體正在播出，則B 當前 自該時間起將減少了(T 現在 -t)。B 比率 (t)=1是其中對於時間(T 現在 -t)而言接收到的媒體的量與正在播出的量相同的情形；B 當前 在時間T 現在 將具有與時間t時相同的值。B 比率 (t)>1是其中對於時間(T 現在 -t)而言接收到的資料比播出所需的多的情形；B 當前 從時間t到時間T 現在 將有所增大。
緩衝監視器126進一步演算「State(狀態)」值，「State(狀態)」值可取離散數目個值。緩衝監視器126進一步裝備有函數NewState(B 當前 ,B 比率 )，在給定B 當前 的當前值和B 比率 對於t<T 現在 的值的情況下該函數提供新「狀態」值作為輸出。每當B 當前 和B 比率 導致該函數返回不同於「狀態」的當前值的值時，該新值就被指派給「狀態」並且向區塊選擇器123指示該新狀態值。
函數NewState(新狀態)可參照(B 當前 ,B 比率 (T 現在 -T x ))對的所有可能值的空間來求值，其中T x 可以是固定(配置)值，或者可例如由從B 當前 的值映射到T x 的值的配置表從B 當前 推導出，或者可取決於「狀態」的先前值。向緩衝監視器126供應該空間的一或多個劃分，其中每個劃分包括不相交區域的集合，每個區域用「狀態」值來標注。對函數「NewState」的求值由此包括識別劃分並決定(B 當前 ,B 比率 (T 現在 -T x ))對所落在的區域的操作。返回值由此是與該區域相關聯的標注。在簡單情形中，只提供一個劃分。在更複雜的情形中，劃分 可取決於前一次對NewState函數求值時的(B 當前 ,B 比率 (T 現在 -T x ))對或取決於其他因素。
在具體實施例中，以上描述的劃分可基於包含B 當前 的數個閾值及B 比率 的數個閾值的配置表。具體而言，令B 當前 的閾值為B 閾 (0)=0、B 閾 (1)、...、B 閾 (n 1)、B 閾 (n 1+1)=∞，其中n 1是B 當前 的非零閾值的數目。令B 比率 的閾值為B 比率閾 (0)=0、B 比率閾 (1)、...、B 比率閾 (n 2)、B 比率閾 (n 2+1)=∞，其中n 2是B 比率 的閾值的數目。該等閾值界定了包括(n 1+1)×(n 2+1)的單元柵格的劃分，其中第j行的第i個單元對應於其中B 閾 (i-1)<=B 當前 <B 閾 (i)且B 比率閾 (j-1)<=B 比率 <B 比率閾 (j)的區域。以上描述的柵格的每個儲存格諸如經由與儲存在記憶體中的特定值相關聯之類而被標注以狀態值，並且函數NewState隨後返回與由值B 當前 和B 比率 (T 現在 -T x )指示的儲存格相關聯的狀態值。
在另一實施例中，可令遲滯值與每個閾值相關聯。在該增強型方法中，對函數NewState的求值可基於使用一組臨時修改的閾值如下構造的臨時劃分。對於小於與在對NewState的上次求值時所選取的儲存格相對應的B 當前 範圍的每個B 當前 閾值，經由減去與該閾值相關聯的遲滯值來減小該閾值。對於大於與在對NewState的上次求值時所選取的儲存格相對應的B 當前 範圍的每個B 當前 閾值，經由加上與該閾值相關聯的遲滯值來增大該閾值。對於小於與在對NewState的上次求值時所選取的儲存格相對應的B 比率 範圍的每個B 比率 閾值，經由減去與該閾值相關聯的遲滯值來減小該閾值。對於大於與在對NewState的上次求值時所選取的儲存格相對應的B 比率 範圍的每個B 比率 閾值，經由加上與該閾值相關聯的遲滯值來增大該閾值。經修改的閾值被用來對NewState的值進行求值並且隨後該等閾值返回閾值的原始值。
在閱讀本案之際，界定空間的劃分的其他方式對於本領域技藝人士將變得明顯。例如，劃分可經由使用基於B 比率 和B 當前 的線性組合的不等式，例如α0、α1和α2為實數值的α1‧B 比率 +α2‧B 當前 ≦α0形式的線性不等式閾值來界定，以界定整個空間內的半空間及將每個不相交集合界定為數個此類半空間的交集。
以上描述是為了圖示基本過程。如實時程式設計領域的技藝人士在閱讀本案之際將清楚的，高效實現是可能的。例如，每次將新資訊提供給緩衝監視器126時，就有可能演算若例如不接收區塊的進一步的資料則NewState將轉移到新值的將來時間。隨後為該時間設置計時器並且在沒有進一步的輸入的情況下，該計時器的期滿將導致新的狀態值被發送給區塊選擇器123。因此，只需要在有新資訊被提供給緩衝監視器126時或者在計時器期滿時執行計算，而無需連續地執行。
狀態的合適值可為「低」、「穩定」和「滿」。合適的閾值集合和所得單元柵格的實例在圖15中圖示。
在圖15中，B 當前 閾值以毫秒在橫軸上圖示，遲滯值在B 當前 閾值下方以「+/-值」形式圖示。B 比率 閾值以千分率(亦即，乘以1000)在縱軸上圖示，遲滯值在B 比率 閾值下方以「+/-值」形式圖示。「低」、「穩定」和「滿」狀態值分別在柵 格單元中被標注為「L」、「S」和「F」。
每當有機會請求新區塊時，區塊選擇器123就接收到來自區塊請求器124的通知。如以上所描述的，向區塊選擇器123提供關於可用的該複數個區塊的資訊及彼等區塊的中繼資料，包括例如關於每個區區塊的媒體資料率的資訊。
關於區塊的媒體資料率的資訊可包括該特定區塊的實際媒體資料率(亦即，以位元組計的區塊大小除以以秒計的播出時間)、區塊所屬的表示的平均媒體資料率，或為了不暫停地播出該區塊所屬的表示在維繫的基礎上需要的可用頻寬的度量，或以上的組合。
區塊選擇器123基於緩衝監視器126最新指示的狀態值來選擇區塊。在該狀態值為「穩定」時，區塊選擇器123從與先前所選區塊相同的表示選擇區塊。所選擇的區塊是包含該呈現中先前未曾請求過該呈現的媒體資料的時段的媒體資料的第一區塊(按播出次序)。
在該狀態值為「低」時，區塊選擇器123從具有比先前所選區塊的媒體資料率低的媒體資料率的表示選擇區塊。數個因素會影響該情形中對表示的確切選取。例如，區塊選擇器123可被提供對傳入資料的聚集速率的指示並且可選取具有小於該值的媒體資料率的表示。
在該狀態值為「滿」時，區塊選擇器123從具有比先前所選區塊的媒體資料率高的媒體資料率的表示選擇區塊。數個因素會影響該情形中對表示的確切選取。例如，區塊選擇器123可被提供對傳入資料的聚集速率的指示並且可選取 具有不高於該值的媒體資料率的表示。
數個額外因素可能進一步影響區塊選擇器123的操作。具體而言，可限制增大所選區塊的媒體資料率的頻率，即使緩衝監視器126持續指示「滿」狀態亦然。此外，區塊選擇器123有可能接收到「滿」狀態指示但沒有更高媒體資料率的區塊可用(例如，由於上次所選的區塊已經對應最高可用媒體資料率)。在此種情形中，區塊選擇器123可將下一區塊的選擇延遲某個時間，該時間被選取為使得在區塊緩衝器125中緩衝的媒體資料總量是上有界的。
額外因素可能影響在選擇過程期間考慮的區塊集合。例如，可用區塊可被限於來自區塊的編碼解析度落在提供給區塊選擇器123的特定範圍以內的彼等表示的區塊。
區塊選擇器123亦可接收來自監視系統的其他態樣的其他元件的輸入，所監視的態樣諸如是用於媒體解碼的計算資源的可用性。若此類資源變得稀缺，則區塊選擇器123可在中繼資料內指示其解碼的計算複雜性較低的區塊(例如，具有較低解析度或訊框率的表示一般具有較低解碼複雜性)。
以上描述的實施例帶來的實質優點在於，在緩衝監視器126內對NewState函數求值時使用值B 比率 與僅考慮B 當前 的方法相比允許在呈現開始時品質更快地上升。在不考慮B 比率 的情況下，可能在累積了大量緩衝的資料後系統才能選擇具有更高媒體資料率及因此具有更高品質的區塊。然而，當B 比率 值很大時，該指示可用頻寬遠高於先前接收到的區塊的媒體 資料率且即使緩衝的資料相對較少(亦即，B 當前 的值很低)，請求有更高媒體資料率及因此有更高品質的區塊仍是安全的。同樣地，若B 比率 值很低(例如<1)，該指示可用頻寬已降至先前所請求的區塊的媒體資料率之下且因此即使B 當前 很高，系統仍將切換到較低的媒體資料率及因此較低的品質，以例如避免到達B 當前 =0且媒體的播出停滯的點。此種改善的行為在其中網路條件及因此投遞速度可能快速且動態地變化(例如使用者向行動裝置串流)的環境中可能尤其重要。
使用配置資料來指定(B 當前 ,B 比率 )的值空間的劃分帶來了另一優點。此類配置資料可作為呈現中繼資料的一部分或經由其他動態手段被提供給緩衝監視器126。在實踐部署中，由於使用者網路連接的行為在各使用者之間及對於單個使用者而言隨時間推移而可能高度可變，因此可能很難預測對於所有使用者皆將工作良好的劃分。動態地向使用者提供此類配置資訊的可能性允許隨時間推移根據累積的經驗來開發良好的配置設置。
可變請求大小控制
若每個請求針對單個區塊且若每個區塊編碼短媒體段，則可能需要高頻率的請求。若媒體區塊很短，則視訊播出迅速地在區塊間移動，此為接收器提供了更頻繁的經由改變表示來調整或改變接收器所選資料率的機會，從而提高了播出能不停滯地繼續的可能性。然而，高頻率的請求的不利方面在於該等請求在其中客戶端至伺服器網路中的可用頻寬受約束的某些網路上可能是不能維繫的，例如在諸如3G和4G 無線WAN之類的無線WAN網路中，其中從客戶端至網路的資料連結的容量是受限制的或者會由於無線電條件的改變而變為在或短或長的時間段上受限制。
高頻率的請求亦意味著服務基礎設施的高負荷，此帶來容量要求方面的關聯成本。因此，將希望有高頻率請求的一些效益而沒有所有該等缺點。
在區塊串流系統的一些實施例中，將高請求頻率的靈活性與低頻率請求相組合。在該實施例中，區塊可以如上所描述地構造並且同樣如以上所描述地被聚集成包含多個區塊的段。在呈現的開頭，應用以上所描述的其中每個請求引用單個區塊或者作出多個併發請求以請求區塊的各部分的過程以確保在呈現的開始有快速的頻道換台時間並且因此有良好的使用者體驗。隨後，當滿足將在以下描述的某個條件時，客戶端可發出在單個請求中涵蓋多個區塊的請求。此是可能的，因為該等區塊已被聚集成較大檔或段並且可使用位元組或時間範圍來請求。連貫的位元組或時間範圍可被聚集成單個較大的位元組或時間範圍，從而導致單個請求針對多個區塊，並且甚至能在一個請求中請求非連續的區塊。
可由決定是請求單個區塊(或部分區塊)還是請求多個連貫區塊來驅使的一個基本配置是使該決定基於所請求區塊是否很可能被播出。例如，若很可能不久將需要換到另一表示，則客戶端最好作出針對單個區塊即少量媒體資料的請求。此舉的一個原因在於，若在可能即將要切換至另一表示時作出針對多個區塊的請求，則該切換可能在該請求的最 後幾個區塊被播出之前作出。因此，對該最後幾個區塊的下載可能延遲了對所切換到的表示的媒體資料的投遞，此可能導致媒體播出停滯。
然而，針對單個區塊的請求的確導致更高頻率的請求。另一方面，若不大可能不久將需要換到另一表示，則可能較佳作出針對多個區塊的請求，因為所有該等區塊很可能將被播出，並且此導致較低頻率的請求，從而可以大量上降低請求管理負擔，典型地在表示中沒有即將來臨的改變的情況下尤其如此。
在習知的區塊聚集系統中，每個請求中所請求的量不是動態地調整的，即典型地每個請求針對整個檔，或者每個請求針對與表示的檔大致相同的量(有時以時間量測，有時以位元組量測)。因此，若所有請求皆較小，則請求管理負擔較高，而若所有請求皆較大，則此增加了媒體停滯事件的機會及/或在選取了較低品質表示以避免不得不隨著網路條件變化而迅速改變表示的情況下增加了提供較低品質媒體播出的機會。
在被滿足時可導致後續請求引用多個區塊的條件的實例是對緩衝器大小B 當前 的閾值。若B 當前 低於該閾值，則發出的每個請求引用單個區塊。若B 當前 大於或等於該閾值，則發出的每個請求引用多個區塊。若發出引用多個區塊的請求，則每單個請求中所請求的區塊數目可按若干種可能方式之一來決定。例如，該數目可以是常數，例如2。替換地，單個請求中所請求的區塊數目可取決於緩衝器狀態並且尤其是取決於 B 當前 。例如，可以設置數個閾值，其中單個請求中所請求的區塊數目是從小於B 當前 的多個閾值中的最高閾值來推導的。
在被滿足時可導致請求引用多個區塊的條件的另一實例是以上描述的「狀態」值變數。例如，當狀態為「穩定」或「滿」時，則可發出針對多個區塊的請求，但當狀態為「低」時，則所有請求可針對一個區塊。
另一實施例在圖16中圖示。在該實施例中，當將發出下一請求時(在步驟1300中決定)，使用當前狀態值和B 當前來決定下一請求的大小。若當前狀態值為「低」，或當前狀態值為「滿」且當前表示不是最高可用的表示(在步驟1310中決定，答案為「是」)，則下一請求被選取為短請求，例如僅針對下一區塊(在步驟1320中決定區塊並作出請求)。此舉背後的基本原理在於，該等條件是其中很可能很快將有表示改變的條件。若當前狀態值為「穩定」，或當前狀態值為「滿」且當前表示是最高可用的表示(在步驟1310中決定，答案為「否」)，則下一請求中所請求的連貫區塊的歷時對於某個固定的α<1被選取為與B 當前的α分數成比例(在步驟1330中決定區塊，在步驟1340中作出請求)，例如對於α=0.4，若B 當前 =5秒，則下一請求可針對約2秒的區塊，而若B 當前 =10秒，則下一請求可針對約4秒的區塊。此舉背後的一個基本原理在於在該等條件下，在與B 當前 成比例的時間量裡將不大可能作出向新表示的切換。
靈活管線化
區塊串流系統可使用具有例如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，因為請求C是候選列表上在該時間點能在連接1上發出的的最高優先順序請求。
假設在該相同的情形中改為在時間t在連接1上本來發出了請求A(請求A為如圖18中所示的在時間t對連接1而言兩個最高優先順序選擇之一)。由於從時間t到某個稍後的時間t′對於所有連接而言步驟1430中描述的測試的答案皆為「否」，因此連接1仍為在時間t之前發出的請求投遞資料直到至少時間t′，且因此請求A在至少時間t′之前將不會開動。在時間t′發出請求C是比本來在時間t發出請求A更好的決定，因為請求C在t′之後與請求A本來將開動的時間相同的時間 開動，並且因為截至該時間，請求C比請求A具有更高優先順序。
作為另一替換方案，若步驟1430中描述的類型的測試應用於活躍連接的聚集，則可選取連接的目的地的網際網路協定位址與候選請求清單上的第一個請求或同該第一個請求具有相同優先順序的另一請求相關聯的連接。
有數種方法可用於構造候選請求列表。例如，候選列表可包含代表對呈現的當前表示按時間順序次序的接下來n個資料部分的請求的n個請求，其中對最早資料部分的請求具有最高優先順序而對最晚資料部分的請求具有最低優先順序。在一些情形中，n可以為1。n的值可取決於緩衝器大小B 當前 ，或狀態變數或客戶端緩衝器佔用率的狀態的其他度量。例如，可為B 當前 設置數個閾，並且有值與每個閾相關聯，隨後將n的值取為與小於B 當前 的最高閾相關聯的值。
以上描述的實施例確保了靈活地將請求分配給連接，從而確保向重用現有連接給予優待，即使最高優先順序請求不適合該連接(因為該連接的目的地IP位址不是分配給與該請求相關聯的任何主機名稱的那一IP位址)亦然。n對B 當前 或客戶端緩衝器佔用率的狀態或其他度量的依存性確保了在客戶端亟需發出和完成與按時間順序要播出的下一資料部分相關聯的請求時，此類「脫離優先順序次序」的請求不被發出。
該等方法可有利地與協調式HTTP和FEC相組合。
一致性的伺服器選擇
如公知的，將使用檔下載協定來下載的檔通常由包括主機名稱和檔案名的辨識符來識別。例如，HTTP協定就是此種情形，在該情形中，辨識符是統一資源辨識項(URI)。主機名稱可對應於由各網際網路協定位址識別的多個主機。例如，此是跨多個實體機器分攤來自多個客戶端的請求負荷的常見方法。具體而言，該辦法常被內容投遞網路(CDN)採用。在此種情形中，在連接上向任何實體主機發出的請求預期將成功。已知有多種可供客戶端用來從與主機名稱相關聯的各網際協定位址中進行選擇的方法。例如，該等位址通常經由領域名稱系統提供給客戶端並按優先順序次序提供。客戶端隨後可選取最高優先順序(第一)網際協定位址。然而，一般而言，客戶端之間就如何作出該選取並沒有協調，因此不同客戶端可能向不同伺服器請求相同的檔。此舉可能導致相同的檔被儲存在近旁多個伺服器的快取記憶體中，此舉降低了快取記憶體基礎設施的效率。
此舉可以由有利地增加請求相同區塊的兩個客戶端將向相同伺服器請求該區塊的概率的系統來處置。此處描述的新穎方法包括以由要請求的檔的辨識符來決定的方式並以使得被呈示了相同或相似的網際協定位址和檔辨識符選擇的不同客戶端將作出相同選取的方式從可用網際網路協定位址中進行選擇。
參考圖20來描述該方法的第一實施例。客戶端首先獲得一組網際協定位址IP1、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,1]選取該亂數並且閾值可為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函數求值得到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提前至多「MaximumClientPreBufferTime(最大客戶端預緩衝時間)」的任何資料，及由於使用者互動(例如，檢視、快進等)而需要的任何資料。在一些實施例中，「最大客戶端預緩衝時間」甚至可以不被指定，不被指定的意義是指客戶端能無限制地下載比當前播放時間提前(tP)的資料。
HTTP客戶端可避免下載不必要的資料，例如，來自預期不會播出的表示的任何段可能典型地不被下載。
提供串流服務的基本過程可以是經由產生下載整個檔/段或檔/段子集的合適請求，例如經由使用HTTP獲取請求或HTTP部分獲取請求來下載資料。本描述解決了如何存取特定播出時間tP的資料，但一般而言，客戶端可下載更大時間範圍的播放時間的資料以避免低效率請求。HTTP客戶端可使得在提供串流服務時的HTTP請求的數目/頻率最小化。
為了存取特定表示中在播放時間tP或至少接近播放時間tP的媒體資料，客戶端決定指向包含該播放時間的檔的URL並且另外決定該檔中用於存取該播放時間的位元組範圍。
媒體呈現描述可例如經由使用RepresentationID(表示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-1的段的所有段歷時之和來推導的。每個段的歷時可根據以上論述的任何規則來提供。例如，懂基礎數學的任何人員可使用其他方法來推導用於從單個元素或屬性及檔URI在表示中的位置/索引來容易地推導開始時間的方法。
若MPD中提供動態URI構造規則，則每個檔的開始時間及每個檔URI可經由使用構造規則、所請求的檔的索引，及潛在可能亦使用在媒體呈現描述中提供的一些額外參數來動態地構造。該資訊例如可在諸如檔URI模式(FileURIPattern)和動態檔資訊(FileInfoDynamic)等MPD屬性及元素中提供。檔URI模式提供關於如何基於檔索引序號i和表示ID r來構造URI的資訊。檔URI格式(FileURIFormat)構造為：檔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)+1)的區間中。段存取可進一步被以上情形限制，例如段是不可存取的。
一旦獲得相應段的索引和URI，存取確切的播放時間tP就取決於實際段格式。在該實例中，不失一般性，假定媒體段具有始於0的局部等時線。為了存取和呈現播放時間tP的資料，客戶端可從能經由其中i=i(r,tp)的URI FileURI(r,i)存取的檔/段下載與局部時間相對應的資料。
一般而言，客戶端可下載整個檔並且隨後可存取播放時間tP。然而，不一定3GP檔的所有資訊皆需要被下載，因為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[1]=0。獲得媒體段i的URL即URL[i]為FileURI(r,i)。 該過程針對具有索引i的所有被描述的媒體段繼續，並且獲得媒體段i的startTime[i]為(i-1)＊ 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連接上下載的，並且並行連接的數量為n且每個區塊的播出歷時為t秒，並且與該段相關聯的內容的串流率為S。當客戶端最初開始串流該內容時，可發出對頭n個區塊的請求，此代表n＊t秒的媒體資料。
如本領域技藝人士已知的，TCP連接的資料率有很大變動。然而，為了簡化本論述，假設理想情況下所有連接皆並行地進行，從而第一個區塊將在與其他n-1個請求的區塊大約相同的時間被完全接收。為了進一步簡化本論述，假設該n個下載連接所利用的聚集頻寬在該下載的整個歷時期間固定為值B，並且串流率S在整個表示期間是恆定的。進一步假設媒體資料結構使得區塊的播出在整個區塊在客戶端處可用時才能進行，即區塊的播出只能在接收到整個區塊之後開始，例如由於底層視訊編碼的結構或者由於採用了加密來單獨加密每個片斷或區塊，且因此整個片斷或區塊需要先被接 收到才能被解密。因此，為了簡化以下的論述，假定在區塊的任何部分能被播出之前，需要接收到整個區塊。則，在第一個區塊抵達並且能被播出之前所需的時間約為n＊t＊S/B。
由於希望使內容換台時間最小化，因此使n＊t＊S/B最小化是可取的。t的值可由諸如底層視訊編碼結構及如何利用攝取方法等因素決定，且因此t可以適度地小，但非常小的t值導致過度複雜的段映射，並且可能與高效視訊編碼和解密(若使用)不相容。n的值亦可能影響B的值，即B對於較大的連接數量n可能較大，且因此減少連接數量n具有潛在地減少所利用的可用頻寬量B的負面效應，因此對於達成減少內容換台時間的目標可能不是有效的。S的值取決於選取下載和播出何者表示，且理想情況下S應當儘可能接近B以使給定網路條件下媒體的播出品質最大化。因此，為了簡化本論述，假定S約等於B。則，頻道換台時間與n＊t成比例。因此，若各連接利用的聚集頻寬與連接數量呈亞線性比例(通常就是此種情形)，則利用較多連接來下載不同片斷會使頻道換台時間降級。
作為實例，假設t=1秒，且n=1時B的值=500Kbps，n=2時B的值=700Kbps，且n=3時B的值=800Kbps。假設選取了S=700Kbps的表示。則，在n=1時，第一區塊的下載時間為1＊700/500=1.4秒，在n=2時，第一區塊的下載時間為2＊700/700=2秒，在n=3時，第一區塊的下載時間為3＊700/800=2.625秒，此外，隨著連接數量增加，各連接的個體下載速度的可變性很可能增加(儘管即使在一個連接的情 況下，亦很可能有某個明顯的可變性)。因此，在該實例中，頻道換台時間和頻道換台時間可變性隨連接數量的增加而增加。直觀上，正被投遞的區塊具有不同優先順序，亦即，第一個區塊具有最早投遞期限，第二個區塊具有次最早期限等等，而正藉以投遞該等區塊的各下載連接正在投遞期間爭用網路資源，且因此具有最早期限的區塊隨著有越來越多的爭用區塊被請求而越加延遲。另一方面，即使在該情形中，最終使用一個以上下載連接亦允許支援可維繫的較高串流率，例如在三個連接的情況下，在該實例中能支援最高達800Kbps的串流率，而在一個連接的情況下僅能支援500Kbps的流。
在實踐中，如上所述，連接的資料率在相同連接內隨著時間推移及在不同連接之間皆可能高度可變，並且因此，n個所請求的區塊一般不在同時完成，且事實上通常可能是一個區塊可能在另一區塊的一半時間裡就完成了。該效應導致不可預測的行為，因為在一些情形中，第一個區塊可能比其他區塊完成得快得多，而在其他情形中，第一個區塊可能比其他區塊完成得晚得多，且因此播出的開始在一些情形中可能相對迅速地發生而在其他情形中可能發生得很慢。此種不可預測的行為對於使用者來說可能是令人沮喪的，並且因此可能被視為不良使用者體驗。
因此，需要能利用多個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修復資料的情況下更加一致。
圖24(a)至圖24(e)圖示在從模擬的進化資料最佳化(EVDO)網路上的相同HTTP web伺服器至相同客戶端的相同鏈路上執行的5個TCP連接的投遞率波動的實例。在圖24(a)至圖24(e)中，X軸圖示以秒計的時間，並且Y軸圖示客戶端處在該5個TCP連接中的每一個連接上接收位元的速率，每個連接上的速率是針在1秒的區間上量測的。在該特定模擬中，在該鏈路上總共有12個TCP連接在執行，且因此網路在所示時間期間是相對有負荷的，此在有一個以上客戶客戶端正在行動網路的相同細胞服務區內進行串流時是典型的。注意，儘管投遞率隨著時間推移來看在一定程度上是相關的，但該5個連接的投遞率在許多時間點是有巨大差異的。
圖25圖示針對大小為250000位元(約為31.25千位元組)的片斷的可能請求結構，其中對該片斷的不同部分並行地作出4個HTTP位元組範圍請求，即第一HTTP連接請求頭50000位元，第二HTTP連接請求接下來的50000位元，第三HTTP連接請求接下來的50000位元，而第四HTTP連接請求接下來的50000位元。若不使用FEC，即無FEC方法，則在該實例中對該片斷只有4個請求。若使用FEC，即FEC方法，則在該實例中，有一個額外的HTTP請求，用於請求從該片斷產生的修復段的額外50000位元FEC修復資料。
圖26是圖24(a)至圖24(e)中所示的5個TCP連接的頭幾秒的放大，其中在圖26中，X軸以100毫秒的間隔圖示時間，並且Y軸圖示客戶端處在該5個TCP連接中的每一個連接上接收位元的速率，該速率是在100毫秒區間上量測的。一條線 圖示在客戶端處已從頭4個HTTP連接(排除藉以請求FEC資料的彼HTTP連接)為該片斷接收到的聚集位元量，亦即，使用無FEC方法抵達的聚集位元量。另一條線圖示在客戶端出已從所有該5個HTTP連接(包括藉以請求FEC資料的彼HTTP連接)為該片斷接收到的聚集位元量，亦即，使用FEC方法抵達的聚集位元量。對於FEC方法，假定該片斷從接收到250000個所請求位元中的任何200000位元時起能被FEC解碼，該在例如使用Reed-Solomon FEC碼的情況下就能實現，且在例如使用Luby IV中描述的RaptorQ碼的情況下則本質上能實現。對於該實例中的FEC方法，在1秒後接收到足以使用FEC解碼來恢復該片斷的資料，從而允許1秒的頻道換台時間(假定在第一個片斷被完全播出之前能請求並接收後續片斷的資料)。對於該實例中的無FEC方法，在能恢復該片斷之前不得不接收該4個請求的所有資料，此在1.7秒之後發生，從而得到1.7秒的頻道換台時間。因此，在圖26中所示的實例中，無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指示若源段包含1000千位元組的資料，則相應的修 復段包含約330千位元組的修復資料。參數S指示用於FEC編碼和解碼的以位元組計的符號大小。例如，S=64指示來源資料和修復資料包括各自用於FEC編碼和解碼目的的大小為64位元組的符號。
可如下為源段產生修復段。源段的每個片斷被視為用於FEC編碼目的的源區塊，且因此每個片斷被當作據以產生修復符號的源區塊的源符號序列。為頭i個片斷產生的修復符號總數演算為TNRS(i)=ceiling(R＊B(i)/S)，其中ceiling(x)是用於輸出值至少為x的最小整數的函數。因此，為片斷i產生的修復符號數目為NRS(i)=TNRS(i)-TNRS(i-1)。
修復段包括關於該等片斷的修復符號的級聯，其中修復段內的修復符號的次序按據以產生該等修復符號的片斷的次序，且在片斷內，修復符號按其編碼符號辨識符(ESI)的次序。與源段結構相對應的修復段結構在圖27中圖示，包括修復段產生器2700。
注意，經由如上所述地界定關於片斷的修復符號數目，關於所有先前片斷的修復符號總數及因此修復段的位元組索引僅取決於R、S、B(i-1)和B(i)，而不取決於源段內的片斷的任何先前或後續結構。此是有利的，因為此舉允許客戶端僅使用關於據以產生修復區塊的源段的相應片斷的結構的局部資訊來迅速計算修復段內的修復區塊開始的位置，並且亦迅速計算該修復區塊內的修復符號數目。因此，若客戶端決定從源段中間開始下載和播出片斷，則客戶端亦能從相應的修復段內迅速產生和存取相應的修復區塊。
與片斷i相對應的源區塊中的源符號數目演算為NSS(i)=ceiling((B(i)-B(i-1))/S)。若B(i)-B(i-1)不是S的倍數，則最後的源符號出於FEC編碼和解碼目的被填充「0」位元組，亦即，最後的源符號被填充「0」位元組從而最後的源符號大小為S位元組以用於FEC編碼和解碼目的，但該等「0」填充位元組不被儲存為源段的一部分。在該實施例中，源符號的ESI為0、1、...、NSS(i)-1，並且修復符號的ESI為NSS(i)、...、NSS(i)+NRS(i)-1。
在該實施例中，可經由簡單地向源段的URL添加後置「.repair」來從相應的源段的URL產生修復段的URL。
修復段的修復索引資訊和FEC資訊由相應的源段的索引資訊及從R和S的值隱式地界定，如本文中所描述的。時間偏移量和包括修復段的片斷結構由相應的源段的時間偏移量和結構決定。至與片斷i相對應的修復段中的修復符號末尾的位元組偏移量可被演算為RB(i)=S＊ceiling(R＊B(i)/S)。與片斷i相對應的修復段中的位元組數目則為RB(i)-RB(i-1)，且因此與片斷i相對應的修復符號數目被演算為NRS(i)=(RB(i)-RB(i-1))/S。與片斷i相對應的源符號數目可演算為NSS(i)=ceiling((B(i)-B(i-1))/S)。因此，在該實施例中，修復段內的修復區塊的修復索引資訊和相應的FEC資訊可從R、S及相應源段的相應片斷的索引資訊隱式地推導出。
作為實例，考慮圖28中所示的實例，圖28圖示始於位元組偏移量B(1)=6410並止於位元組偏移量B(2)=6770的片斷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的始於該源段內的位元組索引6410處的頭64個位元組，第二個源符號為片斷2的始於源段內的位元組索引6474處的接下來64個位元組，等等。與片斷2相對應的修復區塊的末尾位元組偏移量演算為RB(2)=64＊ceiling(0.5＊6,770/64)=64＊ceiling(52.89...)=64＊53=3,392，且與片斷2相對應的修復區塊的開始位元組偏移量演算為RB(1)=64＊ceiling(0.5＊6,410/64)=64＊ceiling(50.07...)=64＊51=3,264，因此在該實例中，在與片斷2相對應的修復區塊中具有ESI分別為6和7的兩個修復符號，始於修復段內位元組偏移量3264處並止於位元組偏移量3392。
注意，在圖28中所示的實例中，儘管R=0.5且存在與片斷2相對應的6個源符號，修復符號的數目亦不是如簡單地使用源符號數目來演算修復符號數目的情況下可預期的3個，而是根據本文中所描述的方法解出該數目為2。與簡單地使用片斷的源符號數目來決定修復符號數目不同，以上描述的實施例使得能夠單單從與相應源段的相應源區塊相關聯的索引資訊來演算修復段內的修復區塊的定位。此外，隨著源區塊中源符號數目K增長，相應修復區塊的修復符號數目KR緊密近似為K＊R，因為一般而言KR至多為ceil(K＊R)且KR至少為 floor((K-1)＊R)，其中floor(x)是最多為x的最大整數。
存在以上用於產生可有利地被採用協調式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秒。
如上所述，將儲存媒體呈現的段的每個檔安排成始於隨機存取點(RAP)可能是有利的。一些簡檔(尤其是ISO基媒體檔案格式實況簡檔)要求每個媒體段始於RAP。
然而，在其中需要低的端到端等待時間遞送的環境中，每個段的歷時必須較短以使實況活動與該實況事件在客戶端上的呈現之間的延遲最小化。期望避免在將用於低等待時間串流的每個段中插入RAP。例如，視訊中的RAP通常由IDR訊框來實現。經由避免在期望用於低等待時間串流的短段內使用IDR訊框，編碼效率可得到改善。
根據實施例，產生媒體呈現的順應於實況簡檔的表示和低等待時間表示。順應於實況簡檔的表示具有相對較大的媒體段歷時。順應於實況簡檔的表示的每個媒體段在該媒體段的開始處具有RAP。低等待時間表示具有相對較短的段(該等段可被稱為「媒體片斷」)，該等段可以不包含RAP。支援低等待時間串流的客戶端可接收為媒體呈現的低等待時間表示所產生的媒體片斷，而不支援低等待時間串流的客戶端可以能夠接收為媒體呈現的順應於實況簡檔的表示所產生的媒體段。
圖30圖示了用於低等待時間串流的媒體片斷與諸媒體片斷之間的關係。為實況簡檔串流所產生的媒體段3002在該媒體資料的開始處包含RAP 3004(「mdat」)。相反，在為低等待時間串流所產生的媒體片斷3004、3006和3008中， 只有媒體片斷3004包含RAP。
該等媒體片斷是在執行中產生的，並且可供客戶端經由HTTP進行下載。該等媒體片斷可被累積成順應於ISO基媒體檔案格式實況簡檔的媒體段，而無需對該等媒體片斷作任何修改。例如，該等媒體片斷可被級聯成媒體段。
媒體段和媒體片斷兩者可使用相同的編碼過程來建立。以此方式，媒體可被高效地編碼以供在需要低的端到端等待時間的環境中操作的客戶端及由使用要求在每個段中有RAP的協定的客戶端消費。
在一些實施例中，為每個媒體片斷產生段索引(SIDX)。SIDX可包括在媒體段內的呈現時間範圍及媒體段被該媒體片斷所佔據的相應位元組範圍。在一些實施例中，SIDX指示片斷內是否存在RAP。在圖30中，媒體片斷3004的SIDX包的「包含_RAP」欄位被設為1，指示該媒體片斷3004包含RAP。媒體片斷3006和3008的SIDX包的「包含_RAP」欄位被設為0，指示媒體片斷3006和3008不包含RAP。SIDX可進一步指示第一RAP在片斷內的呈現時間。
根據實施例，媒體伺服器可產生用於低等待時間串流的片斷並將該等片斷推送到快取記憶體中。該快取記憶體可級聯該等片斷以產生與實況簡檔相容的媒體段。在產生媒體段之後，該快取記憶體可清空已被級聯以產生該媒體段的彼等媒體片斷。
單個媒體呈現描述(MPD)可儲存關於具有媒體呈現的順應於實況簡檔的媒體段的第一表示和具有低等待時間 流的媒體片斷的第二表示的資訊。使用媒體段進行時移緩衝及使用媒體片斷來處置在該串流的近實況邊緣處的觀看，可提供時移觀看。客戶端可在該等表示之間切換，例如，在時移緩衝器中開始並經由跳過該媒體呈現的諸章節而移動至更靠近實況邊緣。MPD的每個表示可被指派一屬性以表達可用於單個媒體呈現的表示陣列。
在儲存關於具有媒體段的第一表示和具有媒體片斷的第二表示的資訊的MPD中，提供指示第二表示的何者媒體片斷始於RAP的資訊可能是有利的。例如，MPD可包括一屬性以指示在複數個媒體片斷內出現RAP的頻率。在一個實施例中，MPD包括以片斷數目的方式來指示頻率的屬性(亦即，每第x個媒體片斷包含RAP)。在另一個實施例中，該屬性以毗鄰RAP之間在時間上的距離的方式來指示頻率。
替換地，關於媒體片斷的資訊可儲存在第一MPD中，而關於媒體段的資訊可儲存在第二MPD中。
在一些實施例中，MPD可發訊號通知適用於具體表示的具體參數，諸如表示的媒體段或媒體片斷的最大歷時。
本領域一般技藝人士在閱讀本案之後可以預見其他實施例。在其他實施例中，可有利地作出以上所揭示的發明的組合或子群組合。元件的實例安排是出於圖式目的圖示的，應理解，在本發明的替換實施例中構想了組合、添加、重新安排，及類似方案。因此，儘管本發明是參照示例性實施例描述的，但是本領域技藝人士將意識到許多修改是可能的。
例如，本文中描述的過程可使用硬體元件、軟體元件及/或以上各者之任何組合來實現。在該等情形中，軟體元件可在有形的非瞬態媒體上提供以在設有該媒體或與該媒體分開的硬體上執行。因此，本說明書和附圖被認為是圖示性的而非限制性的。然而，顯然可對本發明作出各種修改和變更而不會脫離所附請求項中所闡述的本發明的更寬泛的精神和範圍，且本發明意欲涵蓋落在所附請求項的範圍內的所有修改和等效技術方案。

Claims (9)

  1. 一種用於在一媒體伺服器中構造要供應的內容資料的方法，包括以下步驟：獲得要供應的該內容；產生表示該內容並根據一編碼協定來編碼的複數個媒體段，該複數個媒體段包括一媒體呈現的編碼到每個媒體段中的一或多個訊框，其中在每個媒體段中有一隨機存取點可用；及產生根據該編碼協定來編碼的複數個媒體片斷，其中該複數個媒體片斷中的至少一些媒體片斷包括隨機存取點並且至少一些媒體片斷不包括隨機存取點；其中一媒體段是從複數個媒體片斷聚集而成的。
  2. 如請求項1述及之方法，其中該媒體段是經由級聯複數個媒體片斷來產生的。
  3. 如請求項2述及之方法，進一步包括以下步驟：在一快取記憶體中產生該媒體段，並且其中當在該快取記憶體中產生該媒體段之後，從該快取記憶體中清空用於產生該媒體段的該複數個媒體片斷。
  4. 如請求項1述及之方法，進一步包括以下步驟：為每個媒體片斷產生一段索引，該段索引包括在一媒體段內的一呈現時間範圍及該媒體段中被該媒體片斷所佔據的一相應位元組 範圍。
  5. 如請求項4述及之方法，其中該段索引亦包括一隨機存取點存在性指示符，該隨機存取點存在性指示符指示該媒體片斷內是否存在一隨機存取點。
  6. 如請求項1述及之方法，進一步包括以下步驟：產生一單個媒體呈現描述(MPD)檔，該MPD檔儲存關於該媒體呈現的包括該複數個媒體段的一第一表示及該媒體呈現的包括該複數個媒體片斷的一第二表示的資訊。
  7. 如請求項6述及之方法，其中該MPD包括一屬性以指示在該第二表示內出現隨機存取點的一頻率。
  8. 如請求項7述及之方法，其中該頻率是一時間段。
  9. 如請求項7述及之方法，其中該頻率是一媒體片斷數目。
TW102115099A 2012-04-26 2013-04-26 用於處置低等待時間串流的增強型區塊請求串流系統 TWI492598B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/456,474 US9380096B2 (en) 2006-06-09 2012-04-26 Enhanced block-request streaming system for handling low-latency streaming

Publications (2)

Publication Number Publication Date
TW201408020A true TW201408020A (zh) 2014-02-16
TWI492598B TWI492598B (zh) 2015-07-11

Family

ID=48471085

Family Applications (1)

Application Number Title Priority Date Filing Date
TW102115099A TWI492598B (zh) 2012-04-26 2013-04-26 用於處置低等待時間串流的增強型區塊請求串流系統

Country Status (13)

Country Link
EP (1) EP2842336A1 (zh)
JP (1) JP6105717B2 (zh)
KR (1) KR101741484B1 (zh)
CN (1) CN104221390B (zh)
BR (1) BR112014026741B1 (zh)
CA (1) CA2869311C (zh)
HK (1) HK1203015A1 (zh)
IL (1) IL234872A (zh)
MY (1) MY166917A (zh)
PH (1) PH12014502203B1 (zh)
RU (1) RU2629001C2 (zh)
TW (1) TWI492598B (zh)
WO (1) WO2013163448A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105487500A (zh) * 2014-10-06 2016-04-13 费希尔-罗斯蒙特系统公司 在过程控制系统中流式传输用于分析的数据
TWI574535B (zh) * 2014-03-07 2017-03-11 艾瑞克生公司 自適性位元率串流影像白點覆蓋系統與方法
TWI578231B (zh) * 2015-03-27 2017-04-11 英特爾股份有限公司 用以提供原子範圍運算的指令及邏輯
TWI635727B (zh) * 2015-03-06 2018-09-11 新力電腦娛樂美國有限責任公司 雲端輸入頻道管理
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network
US10551799B2 (en) 2013-03-15 2020-02-04 Fisher-Rosemount Systems, Inc. Method and apparatus for determining the position of a mobile control device in a process plant
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10656627B2 (en) 2014-01-31 2020-05-19 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
US10678225B2 (en) 2013-03-04 2020-06-09 Fisher-Rosemount Systems, Inc. Data analytic services for distributed industrial performance monitoring
US10866952B2 (en) 2013-03-04 2020-12-15 Fisher-Rosemount Systems, Inc. Source-independent queries in distributed industrial system
US11385608B2 (en) 2013-03-04 2022-07-12 Fisher-Rosemount Systems, Inc. Big data in process control systems

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX2016006798A (es) 2013-11-27 2016-11-28 Interdigital Patent Holdings Inc Descripcion de medios de presentacion.
KR102367134B1 (ko) 2015-06-25 2022-02-24 삼성전자주식회사 가속기를 제어하는 방법 및 이를 이용한 가속기
CN106559677B (zh) * 2015-09-30 2020-04-03 华为技术有限公司 终端、缓存服务器及获取视频分片的方法及装置
KR102393158B1 (ko) * 2015-10-13 2022-05-02 삼성전자주식회사 메타데이터를 포함하는 비트 스트림을 이용한 서비스 제공 방법 및 장치
CN105406913B (zh) * 2015-10-27 2019-07-19 航天恒星科技有限公司 信号处理方法、装置及中国移动多媒体广播系统
US9426543B1 (en) * 2015-12-18 2016-08-23 Vuclip (Singapore) Pte. Ltd. Server-based video stitching
US10079884B2 (en) * 2016-03-14 2018-09-18 Adobe Systems Incorporated Streaming digital content synchronization
CN105915582B (zh) * 2016-03-28 2019-04-02 深圳市双赢伟业科技股份有限公司 路由器访问网页的方法及路由器
WO2017207861A1 (en) * 2016-05-30 2017-12-07 Teleste Oyj An arrangement for media stream organization
CN107634930B (zh) * 2016-07-18 2020-04-03 华为技术有限公司 一种媒体数据的获取方法和装置
US11617019B2 (en) 2016-07-28 2023-03-28 Qualcomm Incorporated Retrieving and accessing segment chunks for media streaming
US20190222872A1 (en) * 2016-09-30 2019-07-18 Net Insight Intellectual Property Ab Playout buffering in a live content distribution system
EP3539271A1 (en) 2016-11-10 2019-09-18 Telefonaktiebolaget LM Ericsson (PUBL) Resource segmentation to improve delivery performance
WO2018174367A1 (ko) * 2017-03-22 2018-09-27 엘지전자 주식회사 방송 신호 송수신 방법 및 장치
CN108668179B (zh) * 2017-03-27 2021-05-14 华为技术有限公司 媒体索引文件的传输方法及相关设备
CN109936715B (zh) * 2017-12-19 2021-09-03 华为技术有限公司 一种mp4文件的处理方法及其相关设备
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
US11197052B2 (en) 2019-07-12 2021-12-07 Apple Inc. Low latency streaming media
CN110324727A (zh) 2019-07-16 2019-10-11 浙江大华技术股份有限公司 计算机可读存储介质、服务器及其响应播放请求的方法
US20230031033A1 (en) * 2021-07-28 2023-02-02 Grass Valley Limited Virtual file system for dynamically providing media content

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7594250B2 (en) 1992-04-02 2009-09-22 Debey Henry C Method and system of program transmission optimization using a redundant transmission sequence
US7941554B2 (en) * 2003-08-01 2011-05-10 Microsoft Corporation Sparse caching for streaming media
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US7805456B2 (en) * 2007-02-05 2010-09-28 Microsoft Corporation Query pattern to enable type flow of element types
SG179403A1 (en) * 2007-02-23 2012-04-27 Nokia Corp Backward-compatible characterization of aggregated media data units
CN101146110B (zh) * 2007-09-25 2011-06-29 深圳市迅雷网络技术有限公司 一种播放流媒体的方法
US8635360B2 (en) * 2007-10-19 2014-01-21 Google Inc. Media playback point seeking using data range requests
TWI355168B (en) * 2007-12-07 2011-12-21 Univ Nat Chiao Tung Application classification method in network traff
CN101217553A (zh) * 2008-01-15 2008-07-09 中兴通讯股份有限公司 一种媒体流的随机访问处理方法
CN101222616B (zh) * 2008-01-22 2011-08-10 中兴通讯股份有限公司 点播服务中的mpeg传送流的传输处理方法
US20090257508A1 (en) * 2008-04-10 2009-10-15 Gaurav Aggarwal Method and system for enabling video trick modes
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
CN101989977B (zh) * 2009-08-04 2013-08-07 华为技术有限公司 富媒体实时业务实现的方法、设备、服务器和系统
US9917874B2 (en) * 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
KR101737325B1 (ko) * 2010-08-19 2017-05-22 삼성전자주식회사 멀티미디어 시스템에서 멀티미디어 서비스의 경험 품질 감소를 줄이는 방법 및 장치

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10678225B2 (en) 2013-03-04 2020-06-09 Fisher-Rosemount Systems, Inc. Data analytic services for distributed industrial performance monitoring
US11385608B2 (en) 2013-03-04 2022-07-12 Fisher-Rosemount Systems, Inc. Big data in process control systems
US10866952B2 (en) 2013-03-04 2020-12-15 Fisher-Rosemount Systems, Inc. Source-independent queries in distributed industrial system
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US11169651B2 (en) 2013-03-15 2021-11-09 Fisher-Rosemount Systems, Inc. Method and apparatus for controlling a process plant with location aware mobile devices
US10551799B2 (en) 2013-03-15 2020-02-04 Fisher-Rosemount Systems, Inc. Method and apparatus for determining the position of a mobile control device in a process plant
US11112925B2 (en) 2013-03-15 2021-09-07 Fisher-Rosemount Systems, Inc. Supervisor engine for process control
US10649412B2 (en) 2013-03-15 2020-05-12 Fisher-Rosemount Systems, Inc. Method and apparatus for seamless state transfer between user interface devices in a mobile control room
US10649413B2 (en) 2013-03-15 2020-05-12 Fisher-Rosemount Systems, Inc. Method for initiating or resuming a mobile control session in a process plant
US10691281B2 (en) 2013-03-15 2020-06-23 Fisher-Rosemount Systems, Inc. Method and apparatus for controlling a process plant with location aware mobile control devices
US10671028B2 (en) 2013-03-15 2020-06-02 Fisher-Rosemount Systems, Inc. Method and apparatus for managing a work flow in a process plant
US11573672B2 (en) 2013-03-15 2023-02-07 Fisher-Rosemount Systems, Inc. Method for initiating or resuming a mobile control session in a process plant
US10656627B2 (en) 2014-01-31 2020-05-19 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
TWI574535B (zh) * 2014-03-07 2017-03-11 艾瑞克生公司 自適性位元率串流影像白點覆蓋系統與方法
CN105487500A (zh) * 2014-10-06 2016-04-13 费希尔-罗斯蒙特系统公司 在过程控制系统中流式传输用于分析的数据
US10909137B2 (en) 2014-10-06 2021-02-02 Fisher-Rosemount Systems, Inc. Streaming data for analytics in process control systems
TWI635727B (zh) * 2015-03-06 2018-09-11 新力電腦娛樂美國有限責任公司 雲端輸入頻道管理
TWI578231B (zh) * 2015-03-27 2017-04-11 英特爾股份有限公司 用以提供原子範圍運算的指令及邏輯
US11886155B2 (en) 2015-10-09 2024-01-30 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network

Also Published As

Publication number Publication date
MY166917A (en) 2018-07-24
RU2629001C2 (ru) 2017-08-24
JP6105717B2 (ja) 2017-03-29
WO2013163448A1 (en) 2013-10-31
EP2842336A1 (en) 2015-03-04
BR112014026741B1 (pt) 2021-10-26
CA2869311A1 (en) 2013-10-31
KR101741484B1 (ko) 2017-05-30
TWI492598B (zh) 2015-07-11
CN104221390A (zh) 2014-12-17
CN104221390B (zh) 2018-10-02
PH12014502203A1 (en) 2014-12-10
BR112014026741A2 (pt) 2017-06-27
BR112014026741A8 (pt) 2021-06-22
IL234872A (en) 2017-05-29
PH12014502203B1 (en) 2014-12-10
JP2015519813A (ja) 2015-07-09
HK1203015A1 (zh) 2015-10-09
RU2014147463A (ru) 2016-06-20
CA2869311C (en) 2018-02-13
KR20150003296A (ko) 2015-01-08

Similar Documents

Publication Publication Date Title
US11770432B2 (en) Enhanced block-request streaming system for handling low-latency streaming
US11743317B2 (en) Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
TWI492598B (zh) 用於處置低等待時間串流的增強型區塊請求串流系統
JP6117151B2 (ja) 協力的並行ｈｔｔｐ及び前方誤り訂正を用いた拡張ブロック−要求ストリーミング
CN114401420B (zh) 使用可伸缩编码的增强型块请求流送
CN107196963B (zh) 使用url模板和构造规则的增强型块请求流送