對源和接收機之間在多個tcp連接上的http流進行控制的制作方法
【專利摘要】客戶端設備呈現(xiàn)流媒體，并包括用于對流進行控制的流管理器、用于對內(nèi)容進行網(wǎng)絡請求的請求加速器、耦接到流管理器和請求加速器的用于確定進行哪些請求的源組件、網(wǎng)絡連接以及媒體播放器。請求加速器可以使用多個TCP連接，使下載速率進行加速。目標下載速率可以在HTTP請求之間發(fā)生變化。用于給定的TCP連接的TCP接收機窗口大小，可以是基于用于該TCP連接的目標下載速率和/或針對當前TCP連接的當前估計往返時間乘以乘數(shù)速率，其中該乘數(shù)速率位于下面二者限定的范圍之內(nèi)：針對當前TCP連接的目標下載速率、以及與該目標下載速率相比更高預定的量的速率。
【專利說明】對源和接收機之間在多個TCP連接上的HTTP流進行控制
[0001]相關申請的交叉引用
[0002]本申請要求享受2012年2月27日提交的、題目為“Improved DASH Client andReceiver with Rate Adaptat1n and Downloading for Adaptive Video” 的美國臨時申請N0.61/603, 569的權(quán)益，故出于所有目的，作為整體以引用方式將其全部內(nèi)容并入本文。

【背景技術(shù)】
[0003]DASH指的是“動態(tài)自適應HTTP流”。使用DASH，內(nèi)容提供商將內(nèi)容格式化成分段、片段、表現(xiàn)(representat1n)、改編(adaptat1n)等,連同相關聯(lián)的元數(shù)據(jù)(諸如MPD文件)，并將所有這些存儲為通過標準HTTP服務器或者專用HTTP服務器可獲得的文件。DASH客戶端是根據(jù)需要獲得這些文件，以向該DASH客戶端的用戶提供呈現(xiàn)的接收方。
[0004]由于用戶通常在網(wǎng)絡受到約束的環(huán)境中，在很少或沒有提前通知的情況下，想要高質(zhì)量的流，因此DASH客戶端具有苛刻的限制。從而，改進的DASH客戶端令人期望。


【發(fā)明內(nèi)容】

[0005]客戶端設備呈現(xiàn)流媒體，并包括用于對流進行控制的流管理器、用于對內(nèi)容進行網(wǎng)絡請求的請求加速器、耦接到流管理器和請求加速器的用于確定進行哪些請求的源組件、網(wǎng)絡連接以及媒體播放器。請求加速器包括:用于對請求進行緩存的請求數(shù)據(jù)緩沖器、以及用于向其可以響應的每一個請求返回完整的響應的邏輯?？梢詫⒘鞴芾砥鳌⒄埱蠹铀倨骱驮唇M件實現(xiàn)成處理器指令或程序代碼，客戶端設備還包括程序存儲器、工作存儲器、處理器和電源。此外，客戶端設備還包括顯示器和用戶輸入設備。在源組件、流管理器和請求加速器之間對客戶端任務進行解析，以便對數(shù)據(jù)進行高效地流傳輸。
[0006]在各個方面，如本申請所描述的，客戶端可以執(zhí)行諸如下面的操作:確定何時維持一個表現(xiàn)或者切換到另一個表現(xiàn)，確定請求哪些片段，并確保媒體播放器可以獲得充足的數(shù)據(jù)(在大多數(shù)狀況下)，以便在沒有停滯的情況下繼續(xù)流媒體播放。
[0007]可以通過下面的方式，對源和接收機之間的網(wǎng)絡路徑上的下載速率進行加速:在所述源和所述接收機之間具有多個TCP連接，針對每一個TCP連接，確定用于該TCP連接的TCP接收機窗口大小，其中所述源和所述接收機之間的TCP連接可以是直接連接，也可以是間接連接；針對所述多個TCP連接中的每一個TCP連接，確定用于媒體內(nèi)容的目標下載速率，其中對于至少兩個連續(xù)的HTTP請求來說，所述目標下載速率在至少兩個值之間變化；使用所述多個TCP連接中的每一個TCP連接來下載要進行下載的媒體內(nèi)容的多個媒體數(shù)據(jù)元素，其中所述媒體內(nèi)容是針對多個HTTP請求的響應的一部分或者全部；其中，針對給定的TCP連接所確定的TCP接收機窗口大小，是至少部分地基于用于該TCP連接的目標下載速率來確定的，其中對于所述至少兩個連續(xù)的HTTP請求來說，所確定的TCP接收機窗口大小在至少兩個值之間變化。提供了用于下載速率加速的方法和裝置。
[0008]所確定的TCP接收機窗口大小可以是基于針對所述當前TCP連接的當前估計往返時間(“ERTT”)與一個乘數(shù)速率相乘的乘積來確定的，其中所述乘數(shù)速率位于下面二者限定的范圍之內(nèi):針對所述當前TCP連接的目標下載速率、以及與所述目標下載速率相比更高預定的量的速率?？梢詺v史地、或許基于在靜止周期結(jié)束時的測量值來確定所述當前ERTT，其中在所述靜止周期期間，在所述TCP連接上沒有呈現(xiàn)活動的HTTP請求達到預定的持續(xù)時間段。針對一個TCP連接的目標下載速率可以與下面的值成正比:所有在用的TCP連接上的當前合計下載速率除以在用的TCP連接的數(shù)量。例如，針對一個TCP連接的目標下載速率是下面的值的兩倍:所有在用的TCP連接上的當前合計下載速率除以在用的TCP連接的數(shù)量。所述目標下載速率可以與所述媒體內(nèi)容的播放速率成正比，其中所述播放速率是橫跨所有在用的TCP連接的合計速率除以在用的TCP連接的數(shù)量?？梢詫⒚恳粋€媒體數(shù)據(jù)元素劃分成大小位于預定的偏差范圍之內(nèi)的多個區(qū)塊，其中這些區(qū)塊的數(shù)量是基于在用的TCP連接的數(shù)量、針對所述當前TCP連接的當前ERTT、當前下載速率、和/或請求的媒體片段的大小。所述預定的偏差范圍可以是零，和/或每一個區(qū)塊可以具有大于或等于最小字節(jié)數(shù)的大小。可以將針對后續(xù)媒體數(shù)據(jù)元素的后續(xù)HTTP請求，分配給第一可用的TCP連接。
[0009]在一些實施例中，在源和接收機之間的網(wǎng)絡路徑上進行下載包括:確定用于媒體內(nèi)容的目標下載速率；確定與所述網(wǎng)絡路徑有關的網(wǎng)絡狀況；基于所述網(wǎng)絡狀況，確定在所述源和所述接收機之間使用的TCP連接的數(shù)量；作為針對多個HTTP請求的響應的一部分或者全部，使用所述TCP連接中的每一個TCP連接來下載多個媒體數(shù)據(jù)元素。所述TCP連接的數(shù)量可以位于兩個和十六個之間，和/或與下面各項的乘積成正比:所述目標下載速率、所述ERTT、以及估計的丟失率的平方根?？梢曰谒瞿繕讼螺d速率來確定所述TCP接收機窗口大小。
[0010]一種接收機包括:用于從網(wǎng)絡接收數(shù)據(jù)的接收機電路；用于執(zhí)行處理的處理器；用于存儲數(shù)據(jù)的存儲器，保存與所述源和所述接收機之間的多個TCP連接有關的數(shù)據(jù)，其包括用于TCP連接的TCP接收機窗口大小，其中所述源和所述接收機之間的TCP連接可以是直接連接，也可以是間接連接；用于確定針對媒體內(nèi)容的目標下載速率的邏輯(硬件、軟件或者組合)；保存下載所述媒體內(nèi)容的多個媒體數(shù)據(jù)元素的結(jié)果，其中所述媒體內(nèi)容是針對多個HTTP請求的響應的一部分或者全部；其中，針對給定的TCP連接所確定的TCP接收機窗口大小，是至少部分地基于所述目標下載速率的大小，對于所述至少兩個連續(xù)的HTTP請求來說，所確定的TCP接收機窗口大小在至少兩個值之間變化。
[0011]針對當前的TCP連接的TCP接收機窗口大小，可以是針對所述當前TCP連接的當前估計往返時間(“ERTT”)與一個乘數(shù)速率相乘的乘積，其中所述乘數(shù)速率位于下面二者限定的范圍之內(nèi):針對所述當前TCP連接的目標下載速率、以及與所述目標下載速率相比更高預定的量的速率。
[0012]接收機可以使用多個HTTP連接，將媒體請求分解成更小的區(qū)塊請求，使用TCP流控制機制來對這些連接進行同步，并突發(fā)地請求數(shù)據(jù)。此外，接收機可以使用HTTP管道處理來保持這些連接繁忙。
[0013]可以使用用于由處理器執(zhí)行，對通過一個網(wǎng)絡路徑耦接的源和接收機之間的所述網(wǎng)絡路徑上的數(shù)據(jù)下載進行控制的計算機可讀介質(zhì)，來實現(xiàn)各個單元。該計算機可讀介質(zhì)可以是非臨時性計算機可讀介質(zhì)。
[0014]通過本說明書，本發(fā)明的其它方面應當是顯而易見的。

【專利附圖】

【附圖說明】
[0015]圖1示出了 DASH部署中的包括DASH客戶端的各個組成部分，顯示了媒體記錄如何到達終端用戶，其中涉及記錄、內(nèi)容準備以及內(nèi)容遞送階段。
[0016]圖2示出了具有不同組件的DASH客戶端的示例性架構(gòu)，其包括流管理器、請求加速器、源組件、網(wǎng)絡連接和媒體播放器。
[0017]圖3是示出表現(xiàn)切換過程的時序圖，其中包括用于回看過程的圖3A和用于快進過程的圖3B。
[0018]圖4是示出針對切換點對齊的情況的表現(xiàn)切換過程的時序圖。
[0019]圖5是示出如由速率估計器所管理的速率隨時間變化的圖，特別地，該速率估計器是自適應于緩沖器水平的估計器(諸如Pker型速率估計器))。
[0020]圖6是示出當使用非自適應指數(shù)加權(quán)移動平均(“EWMA”)過濾器時，速率增加對比下載時間(r時間)的圖。
[0021]圖7是示出當使用非自適應EWMA過濾器時，速率增加對比播放時間(p時間)的圖。
[0022]圖8是示出當使用可變窗口大小加權(quán)移動平均(“WMA”)過濾器時，速率增加對比下載時間(r時間)的圖。
[0023]圖9是示出當使用pker型過程時，速率增加對比播放時間(P時間)的圖。
[0024]圖10是示出當使用來自2.1章節(jié)的pker型過程時,速率增加對比下載時間的圖。
[0025]圖11示出了速率上突然增加的pker過程的行為。
[0026]圖12示出了突然速率下降的pker過程的行為。
[0027]圖13示出了簡單(固定寬度的)移動窗口平均與指數(shù)加權(quán)移動平均的對比。
[0028]圖14是pker速率估計過程的流程圖。
[0029]圖15示出了如何根據(jù)記錄的(Tp, Tr)值的歷史連同圖16,來確定由pker過程使用的值B和Tfast。
[0030]圖16示出了對值進行確定的方面。
[0031]圖17示出了 “水印”獲取過程的行為。
[0032]圖18示出了如可以用于選擇播放速率的lambda和mu函數(shù)的示例。
[0033]圖19示出了使用“保守”設置的(lambda，mu)函數(shù)的示例性選擇。
[0034]圖20示出了使用“中等”設置的(lambda，mu)函數(shù)的示例性選擇。
[0035]圖21示出了使用“積極”設置的(lambda，mu)函數(shù)的示例性選擇。
[0036]圖22示出了使用用于在一定程度上仿真MLB過程的過程的(lambda, mu)函數(shù)的示例性選擇。
[0037]圖23示出了用于lambda設置的并排值的示例。
[0038]圖24示出了用于mu設置的并排值的示例。
[0039]圖25示出了用于進行速率估計、然后進行基于速率的速率選擇、然后進行基于緩沖器管理的速率選擇的過程。
[0040]圖26示出了在沒有請求取消的情況下的速率下降。
[0041]圖27示出了在具有請求取消的情況下的速率下降。
[0042]圖28是示出示例性請求取消過程的流程圖。
[0043]圖29示出了用于請求取消檢測的過程。
[0044]圖30是利用多個TCP連接但沒有接收緩沖器調(diào)整的獲取的行為的圖。
[0045]圖31是利用多個TCP連接并利用接收緩沖器調(diào)整的獲取的其它行為的圖。
[0046]圖32是示例性請求加速器過程的流程圖。
[0047]圖33示出了用于發(fā)現(xiàn)多個子請求，以有助于給定的片段請求的過程。
[0048]圖34示出了用于選擇各個請求的過程，其中這些請求被選定為具有計算出的大小的源請求的不相交時間間隔。
[0049]圖35示出了時間偏移以及通過時間偏移所確定的用于修復分段的片段結(jié)構(gòu)的示例。
[0050]圖36包括可以用于速率選擇中的lambda和mu的值的表。

【具體實施方式】
[0051]本申請所闡釋的DASH客戶端包括流管理器(SM)、請求加速器(RA)、源組件(SC)、網(wǎng)絡連接和媒體播放器，如圖2中所示。DASH客戶端還可以包括一個或多個媒體數(shù)據(jù)緩沖器。在一些實現(xiàn)中，RA、SC和媒體播放器均可以具有其自己的數(shù)據(jù)緩沖器，或者具有一個大型數(shù)據(jù)緩沖器的邏輯分區(qū)。在其它實現(xiàn)中，或許僅RA具有用于緩存請求的數(shù)據(jù)緩沖器，使得RA能夠向其可以響應的每一個請求發(fā)送完整的響應，并且媒體播放器使用SC已建立的任何數(shù)據(jù)緩沖器。SM可以具有其自己的本地存儲(物理的或邏輯的)，以便根據(jù)需要自己決定來存儲元數(shù)據(jù)。
[0052]圖1示出了具有DASH客戶端的DASH部署。
[0053]圖2示出了具有不同的組件的DASH客戶端的示例架構(gòu)。應當理解的是，SM、RA、SC和媒體播放器可以在硬件、軟件或某種組合中實現(xiàn)。因此，在將功能歸結(jié)于組件的情況下，其可以實現(xiàn)為處理器指令、程序代碼等，在這種情況下，暗含必要的硬件來執(zhí)行這些指令(程序存儲器、ROM、RAM、處理器、電源、連接器、電路板等)。在描述網(wǎng)絡功能時，網(wǎng)絡連接應當被理解為是存在的，并且其可以是有線、光纖、無線等，并且當暗示用戶交互時，還暗含用戶接口能力(顯示器、鍵盤、觸摸板、揚聲器、麥克風等)。
[0054]DASH客戶端維持兩個時鐘或其邏輯等同物。一個時鐘是指示在該客戶端中運行的本地時鐘的時間的實時時鐘電路或軟件,而另一個時鐘是呈現(xiàn)時間，其表示媒體內(nèi)容相對于其起始的呈現(xiàn)時間。在本文中，將實時時鐘時間稱為“r時間”，而“p時間”是表現(xiàn)呈現(xiàn)時間的描述符。
[0055]表現(xiàn)是針對相同的內(nèi)容，以不同的比特率或者其它差別進行編碼的媒體流。因此，用戶通常將僅需要一個表現(xiàn)，但客戶端可以根據(jù)情況和/或需求變化，從一個表現(xiàn)切換到另一個表現(xiàn)。例如，如果帶寬較高，則流客戶端可以選擇高質(zhì)量、高比特率表現(xiàn)。如果帶寬降低，則客戶端可以通過切換到較低質(zhì)量、較低比特率的表現(xiàn)來適應這些情況。
[0056]切換點(或隨機接入點)是表現(xiàn)中的一些樣本，可以從這些樣本開始對媒體樣本的解碼，而不需要該流之前的數(shù)據(jù)的知識。具體而言，在視頻表現(xiàn)中，由于樣本(幀)通常依賴于先前的幀，因此并不是每個樣本都是隨機接入點。當流客戶端想要切換表現(xiàn)時，其應當確保在切換點開始對新的表現(xiàn)進行解碼，以避免做無用功。在一些情況下，在分段索引(sidx)中以信號方式將切換點發(fā)送給流客戶端。
[0057]表現(xiàn)組(有時簡稱為組)是可切換的表現(xiàn)的集合。一個媒體呈現(xiàn)可以包含一個以上的表現(xiàn)組。例如，針對以不同比特率的視頻表現(xiàn)可以具有一個表現(xiàn)組，并且針對音頻比特率可以具有另一個表現(xiàn)組。在DASH標準中，有時還將表現(xiàn)組稱為自適應集。
[0058]分段是包含針對這些表現(xiàn)中的一個表現(xiàn)的至少一部分中的媒體數(shù)據(jù)的文件。片段是分段的一部分，其中，從該片段的起始P時間到該分段中的該片段的字節(jié)范圍的映射是可獲得的。有時，使用術(shù)語子分段來代替片段，這些術(shù)語可以被視作為是等同的。一些媒體內(nèi)容不被分割在片段中；在這種情況下，“片段”可以指代分段其自身。
[0059]圖3是示出兩種可能的表現(xiàn)切換過程的時序圖。該切換可以是回看(第一過程；圖3A)，在該情況下，通過以下方面來尋找切換到的表現(xiàn)中的切換點:查找已經(jīng)在切換自的表現(xiàn)中請求的P時間伸縮，并選擇在P時間上從切換到的表現(xiàn)中向后選擇最靠近該伸縮的結(jié)束的前一切換點。第二過程(圖3B)是快進:其從在切換自的表現(xiàn)中的最后請求的P時間處開始，在P時間上向前尋找切換到的表現(xiàn)中的下一個切換點。
[0060]圖4是示出當切換點對齊時并且當一個切換點緊接在最后請求的片段之后時進行切換的過程的時序圖。該圖描繪了回看和快進方法二者的行為，這兩個過程在這種設置下是表現(xiàn)相同的行為。因此，當這些切換點對齊時，以上的任一過程都不必下載重疊的數(shù)據(jù)。
[0061]呈現(xiàn)時間是預期通常按照正常的速度，來播放或者重放媒體的時間周期。例如，30分鐘視頻呈現(xiàn)將播放30分鐘。用戶可以對進行快進或快退，這將改變實際花費的時間，但應當理解的是，該呈現(xiàn)仍然是30分鐘視頻呈現(xiàn)。呈現(xiàn)單元在呈現(xiàn)時間上向用戶提供該呈現(xiàn)。呈現(xiàn)單元的示例包括視頻顯示和音頻顯示，或者被管道化傳輸?shù)娇梢詫ζ溥M行呈現(xiàn)的設備的視頻/音頻流?！安シ拧笔怯糜诿枋雒襟w的消費的術(shù)語。例如，智能電話可以下載或者獲得在一個呈現(xiàn)的呈現(xiàn)時間(P時間)上表現(xiàn)該呈現(xiàn)的媒體數(shù)據(jù)，對其進行緩存，媒體播放器“消費”該媒體，優(yōu)選地消費是使得至少在該呈現(xiàn)時間的結(jié)束之前，該緩沖器不是完全地為空，使得當接收機等待獲得更多的數(shù)據(jù)時，用戶不會體驗到呈現(xiàn)的停滯。當然，“重放”或者“播放”并不暗不對媒體播放一次以上。在很多實例中，其可以是一旦被媒體被消費一次，就不再使用該媒體。
[0062]呈現(xiàn)緩沖器是接收機、媒體播放器或者可訪問一個或二者的部件中的內(nèi)存單元。為了簡化說明，本申請交換地使用術(shù)語“呈現(xiàn)緩沖器”、“緩沖器”、“媒體緩沖器”和“播放緩沖器”，并理解其是包括已被下載但還沒播放或者消費的數(shù)據(jù)(通常為媒體數(shù)據(jù))的邏輯緩沖器。其可以是下面的情況:將包括呈現(xiàn)緩沖器的數(shù)據(jù)劃分在一個設備中的不同組件之間，即，所下載的數(shù)據(jù)的一些部分由一個進程(例如，該設備中的接收進程)進行保持，而其它部分可能已經(jīng)被傳送給另一個進程(例如，該設備中的播放進程)。此外，其還可以是下面的情況:可以在不同的進程的不同緩沖器中，對包括呈現(xiàn)緩沖器的數(shù)據(jù)的至少一部分進行至少部分地重復。在一些情況下，不是所有已被下載但仍沒有播放的數(shù)據(jù)，都被視作為仍然位于呈現(xiàn)緩沖器之中，例如，在一些情況下，一旦將該媒體內(nèi)容傳遞給媒體播放器，就不再將其視作為位于呈現(xiàn)緩沖器之中。通常，已被下載但仍沒有播放的媒體數(shù)據(jù)，以及被視作為不位于呈現(xiàn)緩沖器之中的媒體數(shù)據(jù)(如果有的話)的數(shù)量非常的小。
[0063]呈現(xiàn)緩沖器容納不均發(fā)接收和播放媒體，存儲所接收的媒體數(shù)據(jù)，直到其被消費為止。在媒體數(shù)據(jù)被消費之后，可以根據(jù)配置，將其刪除或者繼續(xù)保存。在一些實現(xiàn)中，呈現(xiàn)緩沖器的大小(如通過可以在該呈現(xiàn)緩沖器中存儲的數(shù)據(jù)的字節(jié)數(shù)量所測量的)可以隨時間發(fā)生變化。例如，可以根據(jù)需要，從共享內(nèi)存中動態(tài)地分配呈現(xiàn)緩沖器。
[0064]在本申請所詳細描述的很多示例中，可以假定通過大小來示出呈現(xiàn)緩沖器的特性。在固定的存儲器大小專用于呈現(xiàn)緩沖器的情況下，可以通過能在可用的存儲器中存儲的字節(jié)數(shù)量來測量該大小。當呈現(xiàn)緩沖器是動態(tài)分配的時，針對呈現(xiàn)緩沖器的“大小”屬性可以等于目前分配給該呈現(xiàn)緩沖器的字節(jié)數(shù)量、可以分配給該呈現(xiàn)緩沖器的最大字節(jié)數(shù)量、或者某種其它適當?shù)臏y量值。有時，還依據(jù)呈現(xiàn)緩沖器中當前可用的媒體的呈現(xiàn)播放持續(xù)時間，來測量呈現(xiàn)緩沖器的大小。
[0065]此外，呈現(xiàn)緩沖器還具有另一種特性:其“水平”或者“填充水平”。呈現(xiàn)緩沖器的水平表示在該呈現(xiàn)緩沖器中存在多少未被消費的媒體數(shù)據(jù)(例如，使用字節(jié)或者呈現(xiàn)持續(xù)時間來測量的)。可以預期的是，隨著接收到媒體數(shù)據(jù)，該水平增加，隨著媒體數(shù)據(jù)被消費，該水平下降。該水平也可以僅是一種邏輯量，例如，呈現(xiàn)緩沖器可以是不斷充滿有媒體數(shù)據(jù),但該媒體數(shù)據(jù)中的一些(例如，已被消費的媒體數(shù)據(jù))被進行了標記，以便接收到新媒體數(shù)據(jù)時進行覆蓋?？梢詫σ恍┙邮諜C進行編程，使得“空緩沖器”是存在零個未消費的媒體數(shù)據(jù)的狀況，“滿緩沖器”是該呈現(xiàn)緩沖器的100%都填充有未消費的媒體數(shù)據(jù)的狀況。其它接收機可以具有其它限制，使得該水平范圍處于與呈現(xiàn)緩沖器大小的0%到100%相比更小的范圍之上。在使用共享內(nèi)存，并且僅當存儲未消費的媒體數(shù)據(jù)時，才向呈現(xiàn)緩沖器進行分配的情況下，使用呈現(xiàn)緩沖器的這種動態(tài)分配的內(nèi)存大小作為在指示水平比率時的分母，可能沒有任何意義，這是由于根據(jù)規(guī)定，該呈現(xiàn)緩沖器始終是滿的。更適合的是，可以將該呈現(xiàn)緩沖器的水平測量成:該呈現(xiàn)緩沖器中的未消費媒體數(shù)據(jù)的數(shù)量除以該呈現(xiàn)緩沖器的最大允許大小之比。
[0066]1、客戶端組件的概述
[0067]再次參見圖1-2，示出示例性客戶端的各種組件。
[0068]SC保持元數(shù)據(jù)(例如，關于哪些表現(xiàn)是可用的、以及其片段都是有哪些之類的信息)的跟蹤。此外，SC還負責對通過網(wǎng)絡接收的媒體數(shù)據(jù)進行緩存，以便將其傳遞給媒體播放器。SM負責決定在什么時間點將下載哪些表現(xiàn)，以及進行速率切換決定。最后，給定精確的URL以及如SC所提供的字節(jié)范圍信息，RA負載下載媒體片段。
[0069]SM是負責進行速率切換決定的軟件組件。SM的目標之一是針對給定的情形，挑選最佳的內(nèi)容。例如，如果有大量可用的帶寬，可以實現(xiàn)高下載速率，則SM應當挑選高速率表現(xiàn)。如果下載速率明顯地下降，所選擇的高表現(xiàn)不再是可維持的，則SM應當切換到更低的表現(xiàn)速率，更適合于當前狀況。SM應當足夠快地切換速率，以避免使播放緩沖器完全地耗盡(由于這將造成播放停滯)，但同時嘗試不要切換的太匆忙或者太頻繁。此外，應當將目標設定為請求可以通過網(wǎng)絡下載、并且在沒有停滯的情況下進行播放的最高質(zhì)量內(nèi)容。SM在其決策過程中，可以擴展到考慮不同于下載速率的其它因素。其可以潛在地考慮諸如電池壽命、顯示器尺寸之類的事物、以及當關于表現(xiàn)進行決策時的其它因素。可以將這些另外的約束作為過濾器增加到SM中，但其不影響本申請所描述的基本速率決策計算。
[0070]現(xiàn)在描述客戶端的典型、高水平操作。假定用戶請求一個特定的媒體內(nèi)容，例如，實時體育廣播、預錄制的電影、音頻流或者其它音視頻內(nèi)容或者其它內(nèi)容，其可以涉及不同于視頻和音頻的媒體類型。客戶端或許通過用戶接口或者計算機接口，向SM提供該請求。SM從SC進行請求，并接收關于下面信息的指示:有哪些表現(xiàn)可用、哪些P時間跨度被哪些片段覆蓋、以及這些表現(xiàn)中的切換點位于什么位置。除了該信息之外，SM可以具有關于在處理的短期下載速率的某種信息(如下面所解釋的)，RA將該數(shù)據(jù)報告給SC，SC將其報告或者提供給SM。
[0071]SM使用該信息，以及過去的歷史，估計可持續(xù)的速率，選擇一個表現(xiàn)中的適當切換點，以及從該切換點起始、要從該表現(xiàn)下載的媒體內(nèi)容的量。隨著下載的進行，對媒體內(nèi)容進行播放，SM使用提供的信息來決定速率切換是否恰當。如果速率切換不恰當，則SM告訴SC繼續(xù)從當前表現(xiàn)獲取片段。如果速率切換是恰當?shù)?，則SM尋找潛在的切換點，決定需要從哪些表現(xiàn)中的哪些片段進行獲取，以進行期望的切換。隨后，SM將該信息傳遞給SC。SC和SM之間的這種信息交換是定期進行的(只要應當關于要下載的下一節(jié)做出決定)。為了做出正確的決定，SM對緩沖器水平進行監(jiān)測，在一些情況下，SM可以決定該緩沖器是足夠的滿，在一段時間之內(nèi)不需要再下載任何片段。
[0072]—旦SM決定要下載一個片段，SC就負責獲得RA以實際地下載該片段，將所下載的片段保存在媒體緩沖器中，最后當媒體緩沖器中的媒體數(shù)據(jù)的播放時間到了時，將其傳遞給媒體播放器。
[0073]在SM告訴了 SC進行下載之后，SM就不再活動地涉及到這些片段之中。但是，SP使在給定的片段的下載已經(jīng)開始之后，SM仍然可以改變其決定，取消其先前已發(fā)出的片段請求。這種功能在下面的情形中是有用的:事實證明下載速率極速地下降，截止到媒體緩沖器被完全地耗盡的時間，被下載的片段也不可能是可用的。如果發(fā)生這種狀況，則SM應當負責檢測，取消該請求，并切換到更適當?shù)乃俾省?br> [0074]一旦SC從SM接收到要獲取的片段句柄，就在其數(shù)據(jù)結(jié)構(gòu)中查找該URL和相應的片段的字節(jié)范圍，使用該信息來產(chǎn)生向RA傳遞的請求。此外，SC還負責從RA獲取響應數(shù)據(jù)，將所接收的媒體片段轉(zhuǎn)換成可播放的流。最后，SC負責對元數(shù)據(jù)(例如，從MH)獲得的數(shù)據(jù)、分段索引(sidx)盒、或者蘋果的HTTP實時流(HLS)情況下的播放列表)進行解析和保持跟蹤。
[0075]RA是從SC接收片段和元數(shù)據(jù)請求，生成相應的HTTP請求，并通過網(wǎng)絡連接來發(fā)送這些HTTP請求，獲取相應的響應并將其傳遞回SC的組件。網(wǎng)絡連接可以是因特網(wǎng)連接、基于蜂窩的連接、WiFi連接或者能夠處理HTTP請求和響應的其它網(wǎng)絡連接。該網(wǎng)絡連接可以是在單一設備的內(nèi)部，即，其可以是針對已經(jīng)在該設備中高速緩存的媒體數(shù)據(jù)的內(nèi)部接口。此外，還可以存在多種組合，即，媒體內(nèi)容中的一些可以從有線因特網(wǎng)連接下載，一些通過基于蜂窩的連接來下載，一些通過WiFi連接來下載，一些來自于本地高速緩存。在一些情況下，下載媒體數(shù)據(jù)的連接可以是混合的，即，一部分是通過蜂窩、一部分通過WiF1、一部分通過有線等。在一些實例中，具體的請求可以是不同于HTTP，但當服務于該媒體內(nèi)容的服務器是HTTP服務器時，HTTP是優(yōu)選的。
[0076]在其最簡單的形式，RA是HTTP客戶端。但是，可能期望RA與通用HTTP客戶端相比更高效。RA的一個目標是實現(xiàn)足夠高的下載速率；其應當將目標設定于:與所選定的播放媒體速率相比，下載速率要明顯地更快。另一方面，還應當注意不要為了原始吞吐量而使時效性受到處罰:與處于進一步的后面位置的其它片段相比，不久將被播放的片段是更加急迫的，RA應當嘗試及時地接收這些片段。因此，需要為了時效性而犧牲一些吞吐量。應當將RA設計為在全部合理的網(wǎng)絡狀況下能進行很好地工作。
[0077]RA的一種基本設計方案是使用一些連接和可能的FEC(前向糾錯)來獲得最佳的結(jié)果。因此，RA通常需要對一個以上的開放HTTP連接進行管理。RA將請求派發(fā)到這些連接上。在一些環(huán)境中，RA可以將請求分割成一組更小的請求。當接收到相應的響應時，RA隨后將該數(shù)據(jù)重新組裝成一個相干的響應。換言之，RA負責決定要發(fā)送的HTTP請求的顆粒度、將這些請求派發(fā)到哪些連接、以及決定要請求源片段或者修復片段的哪些部分。這些請求的顆粒度可以取決于多種事物，例如，緩沖器水平、請求的急迫性、可用連接的數(shù)量等。
[0078]RA發(fā)送出的每一個請求是針對于元數(shù)據(jù)的HTTP請求，也可以是針對于SC已傳送給該RA的片段請求的一部分或者全部。其可以是針對源媒體數(shù)據(jù)的請求，也可以是針對根據(jù)源媒體數(shù)據(jù)所生成的修復數(shù)據(jù)的請求。在大多數(shù)情況下，對于根據(jù)SC片段請求所生成的RA請求的響應，應當是足夠用于重建該片段請求中的所有媒體數(shù)據(jù)，隨后RA可以將其傳送回SC。因此，RA負責將來自于與媒體片段請求相關聯(lián)的RA請求的響應，組合回一個針對該片段請求的響應，以提供給SC。RA執(zhí)行的這種組合可以包括FEC解碼(例如，如果存在一些針對FEC修復數(shù)據(jù)的RA請求的話)。
[0079]除了對HTTP請求進行管理之外，RA在短期時段上、在一些采樣速率的時間片上，對下載速率進行測量。一種示例性采樣速率是100ms，即，RA在10ms時段上對下載速率進行測量。SM使用該使用數(shù)據(jù)來計算其下載速率估計，并最終做出速率決策。其它采樣速率也是可以的。
[0080]RA不需要知道關于諸如DASH媒體呈現(xiàn)描述(MPD)或者關于分段結(jié)構(gòu)的元數(shù)據(jù)。在特定的實現(xiàn)中，RA使用HTTP棧實現(xiàn)的幾個同時實例來在一些連接上(甚至在一些情況下，在針對相似或者不同服務器的不同類型的連接上)實現(xiàn)HTTP檢索。
[0081]RA負責使SC知道何時可以接受新的請求。SC調(diào)用SM來確定要請求的下一個片段，向RA提供該適當?shù)恼埱?。此外，RA還提供一些狀態(tài)信息。RA通?？梢酝ㄟ^SC向SM提供短期的下載速率、下載所花費的總時間。此外，SM還可以針對該信息，通過SC來間接地向RA進行輪詢。除了該方面之外，RA還向SM通知關于各個請求已完成的百分比信息。使用SM進行調(diào)用以獲取該信息的API，來類似地提供該信息。
[0082]在RA、SC和實際的媒體管道之間，應當存在非常緊急的數(shù)據(jù)，故盡可能地在RA或SC中緩存很少的數(shù)據(jù)(除了故意的媒體緩沖器之外)。相同的理由對于具有各種形式的HTTP請求來說也是成立的；與通過網(wǎng)絡來發(fā)送實際相應的HTTP請求的時間相比，SM應當僅只提前很短的時間，必須決定要請求的片段。一種原因在于:SM必須決定一個請求的提前量更早，保持最新的信息就越不準確，因此其所做出的決策的質(zhì)量就越低。
[0083]SM—次發(fā)出一個請求。但是，如果所有先前的請求都沒有完成，SM還可以發(fā)出新請求；允許同時的請求。SC將這些請求按照SM發(fā)出其順序來傳送給RA。隨后，RA對同時處理保持注意，確保其將接收的數(shù)據(jù)返回給SC。
[0084]同時的請求使RA可以實現(xiàn)HTTP管道化。事實上，甚至利用多個連接的RA也適應這種方案。
[0085]1.1、流管理器(SM)
[0086]響應于用戶動作、網(wǎng)絡狀況和其它因素的組合，SM確定何時對片段進行請求、以及對哪些片段進行請求。當用戶決定開始觀看內(nèi)容時，SM負責針對該內(nèi)容，確定要請求的第一片段(其開始于用戶或者所提供的服務所指定的P時間)。例如，一些實時流服務可能需要所有用戶在相同的r時間觀看該媒體內(nèi)容的相同的P時間部分，而其它實時流和按需服務可以允許終端用戶或者應用具有關于在什么r時間對什么P時間進行播放的靈活性。當媒體緩沖器變滿時，SM臨時地暫停提供另外的片段請求。SM負責根據(jù)網(wǎng)絡狀況和其它因素(例如，顯示器的大小、剩余的電池壽命等)，來決定在每一個P時間點，按照什么質(zhì)量來播放該內(nèi)容。
[0087]當SM認為其適合于提供片段請求時，SM可以只提供一個請求(如果RA準備好接收和處理片段請求)。SC通過對RA進行輪詢來確定這種情況，并將該信息轉(zhuǎn)發(fā)給SM。
[0088]當RA準備好接收下一個請求時，SM決定是否應當發(fā)出新的請求，并選擇下一個片段進行請求。SM—次針對媒體數(shù)據(jù)一個片段進行請求，SM負責請求片段，其允許及時地和無縫地播放該內(nèi)容。表現(xiàn)中的播放改變，通常只在切換點處發(fā)生，在兩個連續(xù)的切換點之間可以存在多個片段；SM尊重該限制。
[0089]通常，SM只嘗試請求有理由認為應當及時地接收以平滑播放的片段。但是，假定網(wǎng)絡狀況有時可以非?？焖俚丶眲∽兓⒉荒茉谒协h(huán)境中都保證這種情況。因此，SM還具有取消請求的能力。如果檢測到擁塞，SM將取消請求，如果不采取任何動作，則有很大的停滯風險。如果不采取任何動作，很可能發(fā)生停滯，例如，如果由于在發(fā)出片段請求之后不久網(wǎng)絡狀況就惡化，而造成的下載速率突然急劇地下降。
[0090]SM對表現(xiàn)R、以及大多數(shù)最近先前選擇的片段的結(jié)束P時間E保持跟蹤。通常，SM選擇請求起始P時間為的下一個片段。一些變化可以是:起始時間根據(jù)緩沖器水平和當前播放時間來確定。
[0091]如果丟棄切換點處的潛在重疊，則SM產(chǎn)生旨在生成可以平滑地播放的流的請求序列。SM生成請求的順序，與RA應當對其劃分優(yōu)先級的順序相同(雖然不一定是問題)。其還可以是RA將所接收的數(shù)據(jù)傳遞回SC、并且SC應當對其進行播放的相同順序。
[0092]如果SM決定其需要切換速率，則在通常情況下，這樣做有兩個過程。在一個過程中，SM在新的(“切換目標”)表現(xiàn)中尋找P時間小于或等于E的切換點(其有時還稱為“隨機接入點”或“RAP”)，一旦識別了這種點，SM就開始請求該新表現(xiàn)中的片段。第二過程是尋找P時間小于或等于E的切換點P，并繼續(xù)請求舊的(“切換源”)表現(xiàn)中的片段，直到請求了結(jié)束時間超過P的片段為止的過程。在任一情況下，將這種切換信息發(fā)送給SC都是有用的。
[0093]應當注意，這兩種過程都具有必須要下載一些重疊的數(shù)據(jù)的屬性。存在著P時間的伸縮，需要在該時間，下載從其切換自的表現(xiàn)和切換到的表現(xiàn)的數(shù)據(jù)。
[0094]這些切換過程中的哪個是有利的，取決于上述情形。例如，其可以是:在一些特定的情形下，用于這些過程中的一個的重疊是不合理地大，而對于另一個來說卻是很短。在所有片段在表現(xiàn)之間都是對齊、并且所有這些片段都以RAP起始的簡單情形下，這些切換過程簡化為更簡單的方法，其中在該方法中，SM只通過從切換到的表現(xiàn)而不是從從其切換自的表現(xiàn)中請求下一個片段來進行切換。此外，還應當注意，在該情況下，不需要下載重疊的數(shù)據(jù)。
[0095]1.1.KSM片段決策討稈
[0096]該節(jié)描述了 SM片段決策過程，以決定告訴SC要請求哪些片段。在這些示例中，假定一個簡單的表現(xiàn)組，但這些示例可以被擴展為解決使用多個表現(xiàn)組的過程，例如，從視頻表現(xiàn)組中選擇一個視頻表現(xiàn)，從音頻表現(xiàn)組中選擇一個音頻表現(xiàn)。
[0097]通常，SM所選擇的下一個片段的起始P時間是前一個片段請求的結(jié)束P時間。下面描述可以在SM中實現(xiàn)以便選擇要請求的下一個片段的某種詳細邏輯。
[0098]在下面的示例中，假定片段以RAP起始，并且在表現(xiàn)之間是對齊的。如果不是這種情況，則本說明書的變化也是有可能的。如果存在這些狀況，則SM的片段決策降低為速率決策，即，SM決定是停留在當前表現(xiàn)上，還是切換到不同的表現(xiàn)。在更一般的情況下，片段不是必需在表現(xiàn)之間是對齊的，并且可以不以RAP起始，這種決策是類似的，但切換的代價更高，在切換時可以考慮該代價。
[0099]SM表現(xiàn)處理包括兩個邏輯單獨的過程:第一過程是速率估計器，其根據(jù)RA提供的短期樣本，計算近似持續(xù)的下載速率，第二過程是利用該估計來做出切換決策的決策過程。
[0100]2、諫率估計討稈
[0101]自適應比特率流媒體客戶端通常使用下載速率估計器模塊，速率決策模塊使用該下載速率估計器模塊來選擇正確的比特率媒體。使用該方法，當下載速率較大時，可以對高質(zhì)量媒體進行流傳輸。下載速率的改變可以觸發(fā)表現(xiàn)切換。速率估計的質(zhì)量對于流媒體客戶端的質(zhì)量具有很大的影響。
[0102]用于自適應視頻流媒體設備的良好速率估計器應當具有多種屬性。首先，其應當具有很小的偏差，即使短期下載速率變化很大。第二，其應當在底層的信道上進行快速地速率改變。當信道速率顯著下降時，該估計應當反映這種快速的事實，使得設備可以在無需停滯的情況下，對質(zhì)量進行相應地調(diào)整。相應地，應當快速地觀測到視頻質(zhì)量的增加，使得可以獲取更佳的質(zhì)量內(nèi)容。
[0103]滿足這兩種需求可能需要一些平衡。通常，具有很小偏差的估計器將具有較大的反應時間，反之亦然。例如，假定可以在設備中使用的簡單估計器。該估計器對最后X秒的下載(對于某些固定的X)，執(zhí)行移動平均。挑選較大的x(例如，X = 30秒)，將導致具有很小偏差的相對平滑估計，但其將只反應為下載速率慢速地改變。如果這種估計器是用于速率決策，則最終的播放器可能由于帶寬下降而頻繁停滯，或者不能及時地切換到更高比特率(當其可以安全地這樣做時)。由于這些原因，一種實現(xiàn)可以挑選較小的X，如X = 3s。這種選擇將導致更快速的速率調(diào)整，但以穩(wěn)定性為代價。速率估計變化很大，因此播放器可能非?？焖俚馗淖円曨l播放速率，其導致很差的用戶體驗。
[0104]在圖5中，顛簸曲線是原始下載速率，其具有很多的短期波動。速率估計器是顛簸下載速率的平滑版本。在速率改變時，其收斂到新的持續(xù)速率，只要速率不發(fā)生改變，則仍然類似于它。
[0105]期望的一種屬性在于:如果存在很小的緩沖器水平，則調(diào)整是快速的，其造成速率的快速調(diào)整，使得當下載速率下降時，呈現(xiàn)緩沖器在調(diào)整之前不為空。另一方面，如果在媒體緩沖器中存在很多的媒體數(shù)據(jù)，則速率估計應當是具有更慢調(diào)整的更加平滑。與媒體緩沖器中存在很少的媒體數(shù)據(jù)相比，當在媒體緩沖器中存在更多的媒體數(shù)據(jù)時，播放速率應當趨向于在下載速率下降時，在更長的時間段保持為較高。
[0106]下文所給出的速率估計過程(其稱為pkeiNpker過程或者pker類型過程)，針對速率改變進行快速地反應，但其還是穩(wěn)定的，滿足針對低偏差和高反應的需求。
[0107]2.1、Dker 討稈
[0108]該節(jié)描述了本申請稱為pkeiNpker類型過程或者僅“pker過程”的速率估計過程?；舅俾使烙嬈鲗⑵涔烙嬑ㄒ坏鼗诙唐谒俾蕼y量值，根據(jù)該值，使用一種方法或另一種方法來計算較長的平均運行。如上所述的基本移動窗口平均(“MWA”)是該過程的一個示例。
[0109]圖6-7示出了為了速率選擇目的，使用非自適應(固定系數(shù))指數(shù)加權(quán)平均的效果。為了簡單起見，這些圖假定新的速率估計立即觸發(fā)新的下載選擇(即，這些片段是相對較小的)，新的速率選擇僅是速率估計。
[0110]圖6示出了 r時間方面。如圖所示，X軸是下載時間(實際時間)。當在時間Tl處發(fā)生急劇的速率增加時，緩沖器非?？焖俚亻_始增長，這是由于與播放的速率相比，視頻數(shù)據(jù)被更快速地下載。EWMA估計逐漸收斂到真實的速率。
[0111]圖7示出了相同事件的P時間方面。在該圖中，線702描述了在屏幕上顯示的比特率。與圖6的r時間圖片相比，這里的速率調(diào)整是更慢速的。與r時間相比的P時間的收斂速度，下降了開始中的NR/0R的因子(這是由于在該時間點的每一秒的下載，播放器接收了大約NR/0R秒的視頻)。因此，當使用這種類型的速率估計器時，凈效應是媒體可以在顯著數(shù)量的P時間，按照與下載速率相比更慢的速率進行播放。
[0112]如果為了流媒體的目的來對速率進行估計，則估計器可以利用其它有關的信息。具體而言，對媒體播放器的緩沖器感興趣，或者通常對媒體播放器的下載歷史感興趣(與當前緩沖器中的內(nèi)容相比，對更遠的過去感興趣)，其包括花費了多長的信息來下載被緩存或者已經(jīng)播放的各個媒體片段。
[0113]例如，一種實現(xiàn)可以使用MWA估計器，但根據(jù)媒體緩沖器來選擇窗口大小。
[0114]如果媒體播放器的緩沖器水平較高，則播放器不會具有立即停滯的風險，所以可以使用較大的窗口來進行長期的估計，這將導致一個更穩(wěn)定的估計。另一方面，如果緩沖器水平較低，則播放器應當快速地反應，建議在這種情況下，更短的平均窗口是一種更好的選擇。
[0115]所以速率估計過程的實現(xiàn)可以使用變化的窗口寬度，其利用與當前媒體緩沖器中的P時間的數(shù)量成比例的r時間窗口寬度(也就是說，已下載但沒有播放的當前數(shù)量的P時間)。
[0116]另一種實現(xiàn)可以對窗口寬度進行選擇，以便與媒體緩沖器中當前包含的字節(jié)數(shù)量成正比。
[0117]一種實現(xiàn)還可以檢查緩沖器的內(nèi)容，而不是只檢查其水平。例如，如果確定緩沖器的很大部分是用與該相同內(nèi)容的播放持續(xù)時間相比更短的時間來下載的，則說明該下載緩沖器正在快速地增長，速率估計器因此可以推斷需要對估計進行調(diào)整。
[0118]類似地，速率估計器可以對緩沖器水平的改變速率進行跟蹤，將緩沖器水平的快速改變作為需要對速率估計進行快速地調(diào)整的指示。
[0119]圖8-9示出了當使用可變窗口大小加權(quán)移動平均(“WMA”)過濾器時，與圖6_7相同的場景中的行為。在這些示例中，如同這種可變窗口大小WMA過濾器，將“pker”過程解釋為程序代碼。可以將Pker過程實現(xiàn)成由處理器執(zhí)行的程序指令。
[0120]在圖8中，線802是底層信道的速率突然從速率OR(舊速率)增加到速率NR(新速率)的情況下的Pker速率估計。為了進行速率選擇以調(diào)整到新速率所花費的r時間的量與0R/NR成正比。增加越大，則這種調(diào)整在實際時間中將更快速地發(fā)生。如圖所示，在時間 T2 處，BuffiT2 = 2*BuffiTl, Tfast = 0R/NR*Buff@Tl。
[0121]圖9顯示了 p時間中的播放行為。pker估計器花費大約一個緩沖器持續(xù)時間(當發(fā)生速率增加時，處于該緩沖器中的P時間的數(shù)量)來調(diào)整到新速率，即，在媒體緩沖器具有增加到該媒體緩沖器的P時間持續(xù)量B的媒體內(nèi)容量的時間之前，Pker估計器調(diào)整到新速率，其中B是在速率增加到新速率的時間，該媒體緩沖器中的媒體內(nèi)容的P時間持續(xù)量。
[0122]現(xiàn)在將描述執(zhí)行該處理的具體過程。該處理確定其花費多少r時間來下載播放緩沖器的最后Yt比例，其中Yt是適當選擇的常量。例如，這可以是其下載全部的當前播放緩沖器(Yt= I)所花費的全部時間，或者其下載播放緩沖器的最后一半(YT = 0.5)所花費的時間。還可以發(fā)生YT>1。使Tfast是其下載播放緩沖器的最后比例所花費的r時間的量?？梢酝ㄟ^對下載時間的前面Tfast秒上的下載速率進行估計，來計算估計的下載速率。應當注意，其它的Yt值也是可以的。如本申請所解釋的，不同的值可以服務于不同的目標。
[0123]這種類型的在Tfast寬度窗口上的加窗口平均，具有檢測速率快速地增加的卓越性能。事實上，如果使用值γτ〈1來確定Tfast，那么估計器具有下面的屬性:如果當媒體緩沖器中的媒體內(nèi)容的P時間持續(xù)量是B時，該速率在某個時刻增加了任何因子的倍數(shù)，則在速率估計器收斂到增加的速率之前，該緩沖器將至多增長到B的有限倍數(shù)。
[0124]更詳細的速率估計方法可以對上面所提及的兩種方法進行組合。具體而言，可以將緩沖器水平B和Tfast的最小值使用成平均的窗口寬度(即，在其上對下載速率進行平均的r時間的量)。通常而言,可以在Yb.B和Tfast的最小值的前面r時間上，對下載速率進行平均，其中Yb是適當選擇的常量。這種選擇具有下面的屬性:當存在具有停滯風險的速率下降時，其將快速地反應，這是由于在這些情況下，B是最小值，在與媒體緩沖器中的媒體內(nèi)容的P時間持續(xù)量成正比的r時間上進行平均，從而在媒體緩沖器消耗一半的時間，速率估計將是新的速率。例如，假定在速率減少的時間，媒體緩沖器中的媒體內(nèi)容持續(xù)時間是B，下載速率減少，使得在該下載速率減少之前下載速率是所選定的呈現(xiàn)的播放速率的一個比例α〈1，悲觀的是，所選定的表現(xiàn)的播放速率不會減小，直到速率估計減少到新的下載速率為止。隨后，隨著在發(fā)生速率減少時，持續(xù)下載超出該時間X的r時間，則緩沖器水平是B' =Β-χ+α.χ，Β卩，從媒體緩沖器中消耗X的P時間，向該媒體緩沖器下載了 α.χ。速率估計將是此時的新速率，使得X = B'，即，在此時，P時間中的媒體緩沖器水平等于下載已經(jīng)處于該新速率的r時間，這是由于此時，前面r時間的下載上的估計將是新速率，在該全部時間期間，下載都已處于新的速率。對于方程x = B'= B-X+α.X中的X進行求解，得出X = B' =B/(2-a)，S卩，當緩沖器B'仍然至少為B/2時，速率估計將達到新速率。如果在此時，速率增加的非常明顯，那么Tfast將是最小值，與前面的B !■時間上的平均值相比，在前面的Tfast r時間上的平均下載速率明顯更高。
[0125]現(xiàn)在基于這種構(gòu)建，來給出pker速率估計過程的一個示例的詳細描述。其使用可以從下載模塊(例如，請求加速器(RA))獲得的短期速率測量和緩沖器信息來計算估計。使用緩沖器信息來確定短期速率測量值能獲得有用的估計的窗口寬度。
[0126]圖10示出了當下載速率急劇下降時，pker速率估計器如何演進。只要速率一下降，緩沖器水平就開始下降。速率估計也開始調(diào)整。在緩沖器水平下降到二分之一時，速率估計達到新的速率(NR)。在該示例中，不進行中間速率決策，所以緩沖器線性地下降。如果進行了中間決策，則緩沖器水平的下降將逐漸慢慢地下降。
[0127]pker過程的設計目標是足夠大的平均窗口來避免具有嘈雜的數(shù)字，但對于反應來說具有足夠短的數(shù)量。Pker過程通過使用具有動態(tài)改變的窗口大小的加窗口平均來實現(xiàn)該目標。RA在存儲器中維持幾個變量，以便由Pker過程使用，其包括B、播放緩沖器的水平(在P時間)、處理參數(shù)YB、Yt和Tfast、下載該緩沖器的最后γτ比例(在P時間)所花費的r時間的節(jié)省量、以及R、在r時間的下載的最后C的持續(xù)時間上平均下載速度，其中C =1^叉(5丁卩，1^11(￥,8，^)，5??？是最小可接受窗口大小(其應當超過采樣時間周期(如，100ms))。在一些實施例中，Yb =1，Yt = 0.5，但其它值也是可以的，并導致性質(zhì)相似的行為(只要這兩個值是正在的，并且Υτ〈1)。較小的Yb造成Pker過程對于速率減少反應的很快，而較小的Yt造成其對于速率增加反應的很快。
[0128]如本申請所解釋的，為了計算在持續(xù)時間C上的下載速率，SM使用RA定期提供的下載速度信息。由于此目的，SM可以保持RA所提供的下載速度信息的歷史。進行該平均的持續(xù)時間至多是Yb緩沖器持續(xù)時間，其有效地限制當存在關于媒體緩沖器水平的上限時，需要保持多久的歷史信息。
[0129]應當注意，如果所選定的播放速率近似地等于下載速率，則緩存值C具有緩沖器持續(xù)時間的量級，這是由于如果與播放該流所花費的時間相比，對該流下載花費相同數(shù)量的時間，則可以具有Tfast= Yt-B0對于用于下載速率估計的平滑時間間隔來說，選擇某種量級的r時間的緩沖器水平是一種自然選擇，由于其是遠見量，因此流媒體客戶端必須決定是否想要避免停滯。
[0130]在一種簡單的實現(xiàn)中，平均的窗口寬度與B (視頻緩沖器中所包含的P時間的量)成正比。這種選擇能非常好地防止停滯，但具有下面的缺陷:如果下載速率是所選定的媒體的速率的k倍，則每一秒的下載導致k秒的P時間的媒體被下載，其造成速率估計實際調(diào)整地很慢。例如，如果k = 10，并且存在10秒的緩沖器，那么在調(diào)整之前，速率估計器將下載大約k*10s = 10s的P時間,其是一段非常長的時間。這促使向pker方法引入了 TfastS數(shù)。事實上，如果使用指數(shù)加權(quán)移動平均進行平滑，事情可能甚至變得更差，這是由于這些過濾器具有無限沖激響應。由于此原因，Pker過程替代地使用有限沖激響應。簡單移動平均工作；一種實現(xiàn)還可以使用更精密的加權(quán)移動平均。
[0131]圖13示出了這最后一點。其示出了簡單(固定寬度)移動窗口平均與指數(shù)加權(quán)移動平均的比較。該圖示出了當觀測到速率改變時，固定窗口移動平均首先慢慢地收斂到新速率，但其將一個窗口持續(xù)時間之內(nèi)收斂。指數(shù)加權(quán)移動平均趨向于在開始時快速地移動，但在后面階段，其只是慢慢地收斂。與加窗口的移動平均不同，不在固定的窗口之內(nèi)收斂，而是利用速率改變的幅度的時間對數(shù)進行收斂。
[0132]在Yb = I和Υτ = 0.5的情況下，pker過程可以提供各種保證。對于一種情況，如果下載速度下降任何倍數(shù)，則在緩沖器收縮到其原始持續(xù)時間的一半的時間之內(nèi)，將估計調(diào)整到新的下載速度。對于另一種情況，如果下載速度增加任何倍數(shù)，則在Pker過程收斂到新的速率之前，對至多值得另外的P時間的一個緩沖器進行下載。簡單明了的計算將示出類似的恒定比例擔保，持有0〈 Yb并且0〈 Υτ〈1的任何選擇。
[0133]用于計算緩沖器水平B的一種方法如下所述。使T是媒體播放器的當前播放P時間，使Fi;1，…，F(xiàn)i;n是表現(xiàn)組i中的已經(jīng)被下載或者正在下載但還沒有播放的片段，其以增加的起始時間來排序。仍然被下載的組i的任何片段，位于Fi;1，…，F(xiàn)i;n之間。使a (Fu)是已經(jīng)被下載的片段Fu的比例，例如，已經(jīng)下載的片段Fu的字節(jié)數(shù)除以片段Fu的字節(jié)大小。RA可以計算用于各種i和j的a (Fiij)的值，并將其傳遞給SM。對于給定的組i，將下載的P時間的當前總數(shù)量規(guī)定成如式I中所示:



N.1
[0134]Tv-:= starttimc(F ,) + Vdurat1nC^.).^Fj j)(式 I)
, /=1 ,
[0135]為了根據(jù)式I的結(jié)果來計算整體Tp值，DASH客戶端考慮每一個組的加權(quán)因子w'，后者是根據(jù)MPD (媒體呈現(xiàn)描述元數(shù)據(jù))和表現(xiàn)組的數(shù)量G來確定的，DASH客戶端執(zhí)行式2的計算。隨后，將緩沖器水平B規(guī)定為B: =Tp-T。
[0136]Tv --Jjv1rTp i (式幻

/=1
[0137]式2還捕獲屬于當前正播放的緩沖器的一部分。應當注意，如果一次下載幾個片段，則這種規(guī)定也起作用。
[0138]為了計算Tfast, SM通常保持一些歷史。使I；是RA(嘗試)下載媒體所花費的r時間的總數(shù)量，使Z是RA下載的字節(jié)的總數(shù)量。RA對I；的值進行計算。SM保持按照規(guī)則時間間隔(例如，每100ms)所采樣的三元組的歷史H，其中i = 1，2，...，Κ，第K
個觀測值是最后一個。假定以觀測順序來存儲該歷史；所以具有匕，以及Γ/ SI；2 S--CZf 和 Z1 ( Z2 ? ζκ。
[0139]現(xiàn)在，為了計算Tfast，假定已經(jīng)使用上面所給出的方法計算得到了 B。隨后，RA確定j，使得滿足式3的不等式(例如，通過使用二進制搜索，對歷史進行搜索)。
[0140]Tg -Jf1 <Yt.BSTf-Τξ (式 3)
[0141]轉(zhuǎn)而，Tfast-.= Tf-Γ/。應當注意到，不需要保持無限的歷史，只需要Ti值足夠跨度超過最大緩沖器持續(xù)時間的Yb比例。
[0142]圖15(連同圖16的放大的變量)示出了如何根據(jù)記錄的(Τρ，?；)值的歷史，來確定pker過程使用的值B和Tfast。該附圖示出了 r時間和p時間同樣進展快速的情況(不存在下載中斷)，因此播放時間(P時間)是下載時間(r時間)的45度斜線。在該圖中畫出了(Tp, Tr)值的歷史，其導致嚴格地高于播放時間線的曲線(如果不發(fā)生播放停滯的話)。轉(zhuǎn)而，緩沖器水平B是最后記錄的Tp值與播放時間的差值?？梢酝ㄟ^下面方式在該圖中觀測到Tfast的值:測量在當前(最后)TP值之下的γτ.Β電平處，與(ΤΡ，?；)曲線的水平距離。
[0143]圖11使用了與圖15-16相同類型的呈現(xiàn)方式，來示出pker過程對于速率的突然增加的響應。當接收速率觀測到播放器還沒有進行反應的突然增加時，Tfast是相對很小的。其示出了對于高接收速率的快速響應。應當注意，平均窗口完全地位于該圖形的高速率部分之內(nèi)，這是由于其是相對地較窄。因此，在該時間點，Pker估計已收斂到更大的速率。
[0144]圖12再次使用圖15的呈現(xiàn)方式，來示出針對速率下降的可變窗口大小WMA過濾器(例如，pker)響應。在該情況下，T—變得相對地較大，但緩沖器耗盡，所以B變得較小，其造成在某個消耗時間之后，平均窗口完全地落入到低速率區(qū)域。如圖所示，平均窗口的寬度B是使得B小于Tfast，但在緩沖器被完全耗盡之前，估計仍然收斂到新的更低的速率。
[0145]圖14是pker速率估計過程的流程圖。
[0146]一旦計算出1_和8的值，下面的C值將容易計算，最后步驟是在過去的持續(xù)時間為C的窗口上計算速率R。由于該目的，使用歷史中的Zi和Γ/值。
[0147]為了計算在時間間隔C上的速率，SM或者RA執(zhí)行下面的操作:(1)尋找最大的j，
使得(2)隨后計算平均下載速率，如式4中所示。如果在第一步驟中不存在這種j，則SM或者RA設置j: =0(即，最舊的已知觀測值)。可以通過二進制搜索，來高效地確定j的值。
[0148]ff(式 4)
[0149]每一個組具有相關聯(lián)的權(quán)重W，后者與該組預期使用的總帶寬的部分相對應。其取決于Mro所提供的信息，優(yōu)選地是在過濾完不可用的表現(xiàn)之后。這里，所提議的組g的權(quán)重W的規(guī)定是w (g): = maxrate (g) +minrate (g),其中maxrate O是組g中的最大播放速率，minrate O是最小速率。
[0150]對于權(quán)重w而言，SM或RA可以計算歸一化的權(quán)重V，如下所述。假定客戶端想要對組1，…，G進行流處理，那么歸一化的權(quán)重是所述權(quán)重除以所有權(quán)重之和，如式5中所
/Jn ο
[0151]丨(式 5)
M
[0152]這種歸一化趨向于關于實際進行流處理的權(quán)重來進行。例如，如果存在不被進行流處理的一個組，則就不應當考慮該組。
[0153]在pker過程的操作中，采取了一些假定。例如，應當將各個表現(xiàn)組的緩沖器水平保持的相對接近。用此方式，Pker過程的效果更好。例如，假定一個組具有很大的緩沖器，另一個組具有很小的緩沖器，二者具有類似的權(quán)重。在該情況下，需要快速地調(diào)整速率估計，這是由于對于小緩沖器而言，需要在狀況發(fā)生改變時避免停滯。但Pker過程仍然容易地平滑其估計，如同針對更大的緩沖器所操作的。相反，對于較大的緩沖器而言，這些測量值具有某種高偏差(由于緩沖器水平所允許的)，并因此導致緊張的速率決定。
[0154]在一些情況下，表現(xiàn)組在緩沖器水平中具有很大的差值是不可避免的。由于此原因，另一種實現(xiàn)可以使用Pker方法的變型，后者當一些緩沖器非常小時，更快速地調(diào)整速率，因此在這些情況下更好地防止比特停滯。這種實現(xiàn)可以用與先前所描述的相同方式來計算 Tfast，但將窗口大小設置為 C = max (STP, min (Tfast, Tp；1 - Τ, Τρ，2 - Τ,…，ΤΡ，Ν - Τ))。
[0155]這些下載速率估計的其它變型包括:針對每一個表現(xiàn)組，使用獨立的pker估計來針對該組做出決策。
[0156]3、獲取策略
[0157]通常，流視頻播放器具有有限的媒體緩沖器。因此預期在通常的操作中，可以最后達到緩沖器滿狀態(tài)。當緩沖器達到滿狀態(tài)時，流模塊應當控制媒體輸入，以避免該緩沖器的溢出。一種做到這一點的簡單方法是:只要該緩沖器滿了就進行等待，直到該緩沖器被消耗足夠的多，以便能夠保存下一個片段為止，隨后繼續(xù)進行取數(shù)。
[0158]這種方法的效果是對每一個片段進行單獨地獲取，因此在每一個片段請求之間存在一個時間間隙，即用于對緩沖器消耗足夠的多，使得能適應下一個片段并對其進行請求而花費的時間量。
[0159]TCP協(xié)議基于當前網(wǎng)絡狀況，自動地調(diào)整其下載速率。當通過TCP連接來發(fā)起下載時，初始下載速率通常非常低，隨著TCP協(xié)議探測到是否可以實現(xiàn)更高的下載速率，而下載速率發(fā)生增加。TCP如何快速地增加下載速率、以及TCP通常如何對端到端TCP連接的屬性進行反應，是相當復雜的，并且取決于多種因素，這些因素包括:固有的端到端網(wǎng)絡時延、沿著TCP傳輸和確認路徑的網(wǎng)絡單元的緩沖器容量、沿著這些路徑的競爭流量、在使用TCP的哪種變型等。通常，TCP以較慢的下載速率進行開始，隨著時間來增加其下載速率，因此該TCP連接在整個下載時間上的平均下載速率只接近可持續(xù)TCP下載速率(當整個下載時間是巨大的時)。例如，如果可持續(xù)TCP下載速率是I兆/秒，該TCP連接按照下載速率基本為零進行開始，并且在一秒內(nèi)隨時間線性地增加到I兆/秒，那么在第一秒上的平均下載速率是500K比特/秒，平均下載速率達到可持續(xù)下載速率的95%要花費10秒的下載。由于此原因，在請求之間具有多個下載間隙的獲取策略是不理想的，其中這些下載間隙是一個下載請求的完成和下一個下載請求的開始之間的時間段。即使當下載請求之間的間隙為零也不是理想的，這是由于:通常，在前一個請求的完成之后，TCP要花費一段時間來爬升到針對下一個請求的下載速率。在每一個間隙之后，必須實現(xiàn)新的可持續(xù)吞吐量，其減少了整體實現(xiàn)的平均下載速率。
[0160]這種速率的減小可能導致更小的速率估計，并因此選擇更小的媒體速率。轉(zhuǎn)而，這通常導致更小的媒體片段被下載(依據(jù)字節(jié)大小而言)，其進一步增加所述間隙的相對幅度，導致潛在地選擇甚至更小的播放速率。換言之，這種效果是自放大。
[0161]因此，DASH客戶端實現(xiàn)使用使這種問題的影響減到最小的處理是有利的。
[0162]一種實現(xiàn)可以連續(xù)地下載媒體數(shù)據(jù)，隨后定期地對緩沖器水平進行消耗，如下所述。只要請求的但沒有播放的P時間的數(shù)量超過預置的高水印Mh，那么SM不再發(fā)出任何請求，直到緩沖器水平下降到低于低水印M1為止。在特定的實現(xiàn)中，Mh = 20秒，M1 = 10秒，但在其它實現(xiàn)中，這些值可以更低，也可以更高。在下降到低于低水印之后，重新繼續(xù)正常的操作，SM開始再次發(fā)出片段決策。
[0163]另一種實現(xiàn)可以使用以字節(jié)而不是呈現(xiàn)時間來指定的水印，來實現(xiàn)類似的效果。
[0164]系統(tǒng)的其它部分可以以有利于自己的方式，使用緩沖器被定期地耗盡的事實。例如，其可以用于獲得RTT的新鮮估計，如第6.1.2節(jié)中所解釋的。
[0165]圖17示出了一種“水印”獲取過程的行為。上圖是可見到交替模式的消耗時期和獲取時期的緩沖器水平圖。在下圖中顯示出下載速率。在每一個獲取時期的開始過程中，TCP花費一些時間來達到可持續(xù)的最大速度，因此平均下載速率(在這些獲取時期期間)小于最大可實現(xiàn)下載速率。低水印和高水印之間的差值越大，獲取時期就越長，并且平均速率就越聞。
[0166]4、諫率詵擇討稈
[0167]當開始請求媒體數(shù)據(jù)時，流模塊(SM)使用某種方法來做出第一播放速率選擇?？梢赃x擇最低可用的速率，或者可以例如保持網(wǎng)絡狀況的歷史，隨后基于該歷史，確定在沒有停滯的情況下，可以維持的播放速率的估計以便進行選擇。當SM已經(jīng)接收到數(shù)據(jù)，并且在其處理時具有速率估計R(例如，使用來自節(jié)2的方法所計算的速率估計中的一個)，那么其可以做出決定是停留在該速率，還是對表現(xiàn)進行改變。
[0168]現(xiàn)在描述一種簡單的速率決策過程。接收機確定播放速率低于所估計的下載速率R的最高帶寬表現(xiàn)，挑選該表現(xiàn)作為用于播放(重放)數(shù)據(jù)的表現(xiàn)。雖然簡單，但該方法具有多種問題。首先，其不自然地造成較小的媒體緩沖器增大，并因此容易受到停滯的影響(即使當下載速率僅變化很小時)。第二，變化的估計R將導致快速地改變速率決策，這可以是不必要的，并可以造成視覺錯覺。第三，其導致啟動時間至少近似地是一個片段的持續(xù)時間，并因此通常是幾秒鐘。
[0169]因此，DASH客戶端可以實現(xiàn)一種速率決策過程，該速率決策過程將其速率決策不僅基于下載估計R，而且還基于緩沖器水平B(也就是說，已緩存但沒有播放的P時間的數(shù)量)、以及取決于內(nèi)容的變量，例如改變速率D，后者是通常兩個連續(xù)的切換點之間的P時間持續(xù)量的估計值。
[0170]因此，一種實現(xiàn)可以將與R成正比的最大播放速率，挑選為該決策速率，其中該比例因子取決于緩沖器水平。
[0171]通常，該比例因子λ是緩沖器水平的遞增函數(shù)。例如，一種實現(xiàn)可以使λ是緩沖器水平的仿射函數(shù)。
[0172]如果λ取決于緩沖器水平，那么一種實現(xiàn)可以在緩沖器為空或者較小時，選擇使入更小。這種選擇是有利的，這是由于其將使得較小的緩沖器增大，并且當沒有準確地預測下載速率時，還提供某種安全以防止停滯。
[0173]對于較大的緩沖器水平而言，一種實現(xiàn)可以選擇λ的值靠近、等于或者甚至超過I。這將確保當不存在中間停滯風險時，選擇高播放速率來進行下載，從而導致以穩(wěn)定狀態(tài)來流處理高質(zhì)量媒體。
[0174]該速率決策過程可以將λ實現(xiàn)成B的分段仿射函數(shù)，而不僅只是簡單的仿射函數(shù)。分段仿射函數(shù)可以將任意連續(xù)函數(shù)近似成任何所需的精確度，這使其進行一個合適的選擇?？梢蕴娲剡x擇具有相同屬性的任何其它參數(shù)化類型的函數(shù)。
[0175]另一種實現(xiàn)使λ取決于以字節(jié)計量的緩沖器水平，而不是以P時間計量的緩沖器水平。
[0176]另一種實現(xiàn)使λ不僅取決于緩沖器水平B，而且取決于緩沖器水平B和切換機會的頻率二者。這樣做的原因在于:與具有對速率進行改變的更多機會的播放器相比，具有對速率進行改變的更少機會的播放器將各個決定進一步承諾到未來。因此在后一情況下，將各個決定承諾到更大的時間跨度，故其還具有更高的風險。當緩沖器水平B和估計的下載速率R相同時，建議在前一種情況而不是后一種情況下挑選低速率，以便將停滯的風險保持的很低。
[0177]一種用于考慮速率切換機會的頻率的速率選擇過程的具體方式如下所述。使D是流中的兩個連續(xù)切換點之間的P時間的典型量。D的值取決于編碼的視頻，例如，可以將其值采取為兩個連續(xù)切換點之間的P時間的最大距離、或者兩個連續(xù)切換點的90個百分點的距離、或者該媒體中的兩個連續(xù)切換點的P時間距離的任何其它適當測量值。給定這種D，一種方法可以包括選擇λ為B/D的分段仿射函數(shù)或者其變型(例如，B/max(u, D)or B/(D+u))，其中增加值u以考慮在發(fā)出請求時產(chǎn)生的開銷。u的值可以是較小的時間常數(shù)量(例如，10ms)。作為進一步的細化，一種實現(xiàn)可以使u為所估計的RTT的較小倍數(shù)。
[0178]將其速率決策僅基于λ.R的處理(例如，上面所描述的方法)，具有R的甚至相對很小差異也可能導致很多的速率切換的缺陷。這可能不是合乎要求的。當存在足夠的緩沖器時，更佳的是，不是針對R的較小變化立即進行反應，而是使緩沖器水平相應地變化。
[0179]為了獲得這種行為，一種處理可以使用值λ和μ、相同數(shù)量的兩種函數(shù)(例如，B、B/D或B/max (100ms，D)，如上面所解釋的)，后者連同當前速率來挑選新的速率決策。應當以下面的方式來選擇這些函數(shù):λ *R是低可接受速率選擇，μ *R是高可接受速率選擇。隨后，可以對該處理進行設計，以便使用這兩個值作為用于良好速率決策的向?qū)А?br> [0180]在這種設置中，應當對這些函數(shù)進行選擇，使得通常λ < μ。
[0181]如果前一選擇已經(jīng)處于從λ *R到μ.R的范圍之內(nèi)，則該速率決策過程可以決定將速率保持不變。如果前一選擇小于λ *R，則選擇等于或者小于λ *R的最大可用播放速率。如果前一選擇大于μ *R，則選擇等于或者小于μ.R的最大可用播放速率。
[0182]一種實現(xiàn)可以選擇使函數(shù)λ和μ進行硬編碼。替代地，其可以根據(jù)環(huán)境，以更精細的方式來選擇這些函數(shù)。具體而言，一種實現(xiàn)可以根據(jù)客戶端至多進行緩存的數(shù)量，來選擇適當?shù)摩撕挺毯瘮?shù)。對于點播內(nèi)容而言，客戶端可以選擇對大量的數(shù)據(jù)(潛在幾分鐘的媒體數(shù)據(jù))進行預緩存。對于低延時的直播內(nèi)容，客戶端可以永遠只對至多該端到端延時所預訂的媒體量(其可以只是幾秒鐘)進行緩存。對于具有很少緩存的內(nèi)容而言，客戶端可以決定挑選更保守的λ和μ函數(shù)(S卩，其具有更小的值)。
[0183]例如，一種具體實現(xiàn)可以在兩個外部函數(shù)λ jP λ 2之間，線性地插入函數(shù)，其中所選定的插值點是低緩沖器水印1(參見第3節(jié))。所以其具有兩個硬編碼函數(shù)(入1和λ2)，其中λ I用于較小的M1的值(其小于某個IIi1),當對于某些值m2(其中In^m2), M1 ^ m2時，使用\ 2。對于位于從In1到1112的范圍之內(nèi)的值來說,使用函數(shù)λ (X): = λ j (χ) (In2-M1)/(m2 -1ii1) + λ 2 (χ) (M1 - Hi1) / (m2 - Hi1)。
[0184]現(xiàn)在接著上面的描述，給出速率決策過程的詳細示例。為此，引入一些注釋。
[0185]I)使S1, S2，…，為一個表現(xiàn)組中的L個可用的表現(xiàn)的流速率(以遞增順序給出)。
[0186]2)使λ (χ)為分段線性函數(shù)，其采用非負標量作為輸入，并返回非負實數(shù)縮放系數(shù)。函數(shù)λ (χ)應當可在編譯時間進行設置，或者通過配置文件來設置。對于較大的Χ(例如，對于X大于M1來說)，λ (X)應當不發(fā)生改變。
[0187]這里給出了關于如何實現(xiàn)該函數(shù)的一個示例。給定角點(0，λ0), (Χι, A1),…、(ΧΝ，λΝ)，其中\(zhòng)具有遞增順序。為了對λ (χ)進行評估，尋找最大的i，使得Xi< χ。隨后，使用式6，接收機可以對該函數(shù)進行評估。

1.H-(L., -X1)- Λ—Λ if KN
[0188]A(v) = jxi+x~xi(式 6)
_λΝ,ifi=N
[0189]用于這種λ (χ)函數(shù)的適當示例是通過示例參數(shù)N = I, [(O, 0.5)，(3，I)]所規(guī)定的函數(shù)，也就是說，在X = O處等于0.5的該函數(shù)，直到X達到3為止都線性增加，在后一點，該函數(shù)等于1，并且在其后仍然為I。
[0190]3)使μ (χ)是另一個這種分段線性函數(shù)。一種示例性該函數(shù)是在X = O處評估為0，在χ = 3處達到1.5，其后保持不變的函數(shù)。
[0191]4)使D為從一個切換點到下一個切換點的P時間的持續(xù)時間的估計(如先前所指定的)。
[0192]5)使 χ: = min {(Td - T), Ml} /max {D, lsecond)，其中 T 是當前播放 P 時間，Td 是進行速率決策的P時間，D是如上面所給出的，Ml是緩沖器水平低水印(參見第3節(jié))。
[0193]6)使CURR是當前所選定的表現(xiàn)(即，在后一片段請求中使用的表現(xiàn))。使UP是速率至多為λ (χ) *R的最高比特率表現(xiàn)的播放速率，如果不存在這種表現(xiàn)，則UP是最低比特率表現(xiàn)的播放速率。使DOWN是速率至多為μ (χ).R的最高比特率表現(xiàn)的播放速率，如果不存在這種表現(xiàn)，則DOWN是最低比特率表現(xiàn)的播放速率。由于通常λ (χ)μ (χ)，因此通常DOWUP。
[0194]轉(zhuǎn)而，該速率決策過程挑選下一個片段的速率NEXT，如下所述:(I)如果UP〈⑶RR，那么 NEXT: = min (DOWN, CURR) ； (2)否則 NEXT: = UP。
[0195]在上面的步驟5中使用max {D，lsecond}而不是簡單的D的原因，是由于RTT ;1的角色是用于充當RTT的上限。
[0196]優(yōu)選的是，函數(shù)λ (χ)和μ (χ)是X的遞增函數(shù)。優(yōu)選的是，對于所有較小的X，入和μ函數(shù)都〈1，這將確保所選擇的播放速率是小于R，其對于較小緩沖器水平，造成緩沖器增長。應當注意，所選定的播放速率至多等于max( λ (B/max{D, I}), μ (B/max{D, I})).R,確保λ (B/max{D, I})和μ (B/max{D, I})均小于一的所有緩沖器水平B的緩沖器增長。
[0197]一種更簡單的處理直接將新表現(xiàn)挑選為播放速率小于λ (B).R的最佳表現(xiàn)。這將具有下面的屬性:當緩沖器接近于空時，該緩沖器趨向于進行填充。但是，其還造成大量的表現(xiàn)切換，這是由于R可能波動的相當大。本申請所描述的更復雜的速率選擇過程嘗試避免切換，而不是允許在向下切換到更低的播放速率之前，緩沖器某種程度地耗盡。對于這項工作，應當以某種方式來選擇函數(shù)μ和λ，使得對于中等到大型緩沖器水平，μ超過λ:
應當注意，如果所選定的播放速率是CURR，，所測量的速率是R，那么只要滿足式7，就不會發(fā)生速率改變，其允許在不具有速率切換的情況下，接收速率某種程度地波動。

【權(quán)利要求】
1.一種對通過網(wǎng)絡路徑耦接的源和接收機之間的所述網(wǎng)絡路徑上的數(shù)據(jù)下載進行控制的方法，所述方法包括: 針對所述源和所述接收機之間的多個TCP連接中的每一個TCP連接，確定用于該TCP連接的TCP接收機窗口大小，其中，所述源和所述接收機之間的TCP連接可以是直接連接或間接連接； 針對所述多個TCP連接中的每一個TCP連接，確定媒體內(nèi)容的目標下載速率，其中，所述目標下載速率在針對至少兩個連續(xù)的HTTP請求的至少兩個值之間變化； 使用所述多個TCP連接中的每一個TCP連接來下載要下載的所述媒體內(nèi)容的多個媒體數(shù)據(jù)元素，其中，所述媒體內(nèi)容是對多個HTTP請求的響應的一部分或者全部， 其中，針對給定的TCP連接所確定的TCP接收機窗口大小是至少部分地基于用于該TCP連接的所述目標下載速率來確定的，并且其中，所確定的TCP接收機窗口大小在針對所述至少兩個連續(xù)的HTTP請求的至少兩個值之間變化。
2.根據(jù)權(quán)利要求1所述的方法，其中，針對當前TCP連接所確定的TCP接收機窗口大小是至少部分地基于針對所述當前TCP連接的當前估計往返時間(“ERTT”)與乘數(shù)速率相乘的乘積來確定的，其中，所述乘數(shù)速率在由針對所述當前TCP連接的所述目標下載速率和比所述目標下載速率高出預定量的速率所限定的范圍之內(nèi)。
3.根據(jù)權(quán)利要求2所述的方法，其中，所述當前ERTT是至少部分地通過在緊鄰的前一測量周期觀測到的最小RTT的測量值來確定的。
4.根據(jù)權(quán)利要求3所述的方法，其中，所述緊鄰的前一測量周期對應于十秒或者更少的時段。
5.根據(jù)權(quán)利要求2所述的方法，其中，所述當前ERTT是至少部分地通過在靜止周期結(jié)束時的測量值來確定的，所述靜止周期是在所述多個TCP連接上，沒有出現(xiàn)活動的HTTP請求達到預定的持續(xù)時間段的周期。
6.根據(jù)權(quán)利要求1所述的方法，其中，針對一個TCP連接的所述目標下載速率與所有在用的TCP連接上的當前合計下載速率除以在用的TCP連接的數(shù)量成正比。
7.根據(jù)權(quán)利要求1所述的方法，其中，針對一個TCP連接的所述目標下載速率是所有在用的TCP連接上的當前合計下載速率除以在用的TCP連接的數(shù)量的兩倍。
8.根據(jù)權(quán)利要求1所述的方法，其中，所述目標下載速率與所述媒體內(nèi)容的播放速率成正比，所述播放速率是在所有在用的TCP連接上的合計的速率除以在用的TCP連接的數(shù)量。
9.根據(jù)權(quán)利要求1所述的方法，其中，將每一個媒體數(shù)據(jù)元素劃分成具有在預定的偏差范圍內(nèi)的大小的多個區(qū)塊，其中，這些區(qū)塊的數(shù)量是基于在用的TCP連接的數(shù)量。
10.根據(jù)權(quán)利要求9所述的方法，其中，這些區(qū)塊的所述數(shù)量還基于以下各項中的至少一項:針對當前TCP連接的當前估計往返時間(“ERTT”)、當前下載速率、和/或請求的媒體片段的大小。
11.根據(jù)權(quán)利要求9所述的方法，其中，所述預定的偏差范圍是零，并因此每一個區(qū)塊在每一個片段請求具有相同的大小，并且其中，所述區(qū)塊的數(shù)量等于在用的TCP連接的數(shù)量乘以預定的因子。
12.根據(jù)權(quán)利要求9所述的方法，其中，每一個區(qū)塊具有大于或者等于最小字節(jié)數(shù)的大小。
13.根據(jù)權(quán)利要求1所述的方法,其中，將針對后續(xù)媒體數(shù)據(jù)元素的后來的HTTP請求分配給第一可用的TCP連接。
14.一種對通過網(wǎng)絡路徑耦接的源和接收機之間的所述網(wǎng)絡路徑上的數(shù)據(jù)下載進行控制的方法，所述方法包括: 確定針對媒體內(nèi)容的目標下載速率，其中，所述目標下載速率在針對至少兩個連續(xù)的HTTP請求的至少兩個值之間變化； 確定與所述網(wǎng)絡路徑有關的至少一個網(wǎng)絡狀況； 確定在所述源和所述接收機之間使用的TCP連接的數(shù)量，其中，所述數(shù)量大于1，并且其中，使用的所述TCP連接的數(shù)量是至少部分地基于所確定的至少一個網(wǎng)絡狀況來確定的；以及 使用所述多個TCP連接中的每一個TCP連接來下載要進行下載的媒體內(nèi)容的多個媒體數(shù)據(jù)元素，其中，所述媒體內(nèi)容是對多個HTTP請求的響應的一部分或者全部。
15.根據(jù)權(quán)利要求14所述的方法，其中，在用的TCP連接的數(shù)量是至少部分地基于針對TCP連接的估計往返時間(“ERTT”)、所述目標下載速率、以及丟失率的估計來確定的。
16.根據(jù)權(quán)利要求15所述的方法，其中，估計所述丟失率為I%或者0.1 %。
17.根據(jù)權(quán)利要求14所述的方法，其中，使用的所述TCP連接的數(shù)量被限制在2和16之間，其包含和/或與以下各項的乘積成正比:(a)所述目標下載速率、(b)估計的往返時間(“ERTT”)、以及(c)估計的丟失率的平方根。
18.根據(jù)權(quán)利要求14所述的方法，還包括: 針對所述TCP連接中的每一個TCP連接，至少部分地基于所述目標下載速率來確定用于該TCP連接的TCP接收機窗口大小，其中，所確定的TCP接收機窗口大小在針對所述至少兩個連續(xù)的HTTP請求的至少兩個值之間變化。
19.一種在網(wǎng)絡上通過網(wǎng)絡路徑從源下載數(shù)據(jù)的接收機，包括: 接收機電路，其用于從所述網(wǎng)絡接收數(shù)據(jù)； 處理器，其用于執(zhí)行處理； 存儲器，其用于存儲數(shù)據(jù)； 用于與所述源和所述接收機之間的多個TCP連接有關的數(shù)據(jù)的存儲單元，所述數(shù)據(jù)包括用于TCP連接的TCP接收機窗口大小，其中，所述源和所述接收機之間的TCP連接可以是直接連接或間接連接； 用于確定針對媒體內(nèi)容的目標下載速率的邏輯單元，其中，所述目標下載速率在針對至少兩個連續(xù)的HTTP請求的至少兩個值之間變化； 用于下載所述媒體內(nèi)容的多個媒體數(shù)據(jù)元素的結(jié)果的存儲單元，其中，所述媒體內(nèi)容是對多個HTTP請求的響應的一部分或者全部， 其中，針對給定的TCP連接所確定的TCP接收機窗口大小是至少部分地基于所述目標下載速率的大小，并且所確定的TCP接收機窗口大小在針對所述至少兩個連續(xù)的HTTP請求的至少兩個值之間變化。
20.根據(jù)權(quán)利要求19所述的接收機，其中，針對當前TCP連接所確定的TCP接收機窗口大小是針對所述當前TCP連接的當前估計往返時間(“ERTT”)與乘數(shù)速率相乘的乘積，其中，所述乘數(shù)速率在由針對所述當前TCP連接的所述目標下載速率和比所述目標下載速率高出預定量的速率所限定的范圍之內(nèi)。
21.根據(jù)權(quán)利要求20所述的接收機，其中，所述當前ERTT是在緊鄰的前一測量周期觀測到的最小RTT的測量值。
22.根據(jù)權(quán)利要求20所述的接收機，其中，所述當前ERTT是至少部分地通過靜止周期之后的下載周期期間的測量值確定的，所述靜止周期是在所述TCP連接上，沒有出現(xiàn)活動的HTTP請求達到預定的持續(xù)時間段的周期。
23.根據(jù)權(quán)利要求19所述的接收機，其中，所述目標下載速率與所有在用的TCP連接上的當前合計下載速率除以在用的TCP連接的數(shù)量成正比。
24.根據(jù)權(quán)利要求19所述的接收機，其中，將每一個媒體數(shù)據(jù)元素劃分成具有在預定的偏差范圍內(nèi)的大小的多個區(qū)塊，其中，這些區(qū)塊的數(shù)量是基于以下各項中的至少一項:在用的所述TCP連接的數(shù)量、針對當前TCP連接的當前估計往返時間(“ERTT”)、當前下載速率、和/或請求的媒體片段的大小。
25.用于由處理器執(zhí)行以便對通過網(wǎng)絡路徑耦接的源和接收機之間的所述網(wǎng)絡路徑上的數(shù)據(jù)下載進行控制的非臨時性計算機可讀介質(zhì)，包括: 用于針對所述源和所述接收機之間的多個TCP連接中的每一個TCP連接，確定用于該TCP連接的TCP接收機窗口大小的程序代碼，其中，所述源和所述接收機之間的TCP連接可以是直接連接或間接連接； 用于確定媒體內(nèi)容的目標下載速率的程序代碼，其中，所述目標下載速率在針對至少兩個連續(xù)的HTTP請求的至少兩個值之間變化； 用于使用所述多個TCP連接中的每一個TCP連接來下載要下載的所述媒體內(nèi)容的多個媒體數(shù)據(jù)元素的程序代碼，其中，所述媒體內(nèi)容是對多個HTTP請求的響應的一部分或者全部; 用于至少部分地基于所述目標下載速率來確定針對給定的TCP連接的TCP接收機窗口大小的程序代碼，并且其中，所確定的TCP接收機窗口大小在針對所述至少兩個連續(xù)的HTTP請求的至少兩個值之間變化。
26.根據(jù)權(quán)利要求25所述的非臨時性計算機可讀介質(zhì)，其中，針對當前TCP連接所確定的TCP接收機窗口大小是至少部分地基于針對所述當前TCP連接的當前估計往返時間(“ERTT”)與乘數(shù)速率相乘的乘積來確定的，其中，所述乘數(shù)速率在由針對所述當前TCP連接的所述目標下載速率和比所述目標下載速率高出預定量的速率所限定的范圍之內(nèi)。
27.根據(jù)權(quán)利要求26所述的非臨時性計算機可讀介質(zhì)，其中，所述當前ERTT是至少部分地通過在緊鄰的前一測量周期觀測到的最小RTT的測量值、或者至少部分地通過在靜止周期之后的下載周期期間的測量值來確定的，所述靜止周期是在所述多個TCP連接上，沒有出現(xiàn)活動的HTTP請求達到預定的持續(xù)時間段的周期。
28.根據(jù)權(quán)利要求25所述的非臨時性計算機可讀介質(zhì)，其中，所述目標下載速率與下面的值成正比:所有在用的TCP連接上的當前合計下載速率和所述媒體內(nèi)容的播放速率除以在用的TCP連接的數(shù)量。
29.用于由處理器執(zhí)行以便對通過網(wǎng)絡路徑耦接的源和接收機之間的所述網(wǎng)絡路徑上的數(shù)據(jù)下載進行控制的非臨時性計算機可讀介質(zhì)，包括: 用于確定針對媒體內(nèi)容的目標下載速率的程序代碼，其中，所述目標下載速率在針對至少兩個連續(xù)的HTTP請求的至少兩個值之間變化； 用于確定與所述網(wǎng)絡路徑有關的至少一個網(wǎng)絡狀況的程序代碼； 用于確定在所述源和所述接收機之間使用的TCP連接的數(shù)量的程序代碼，其中，所述數(shù)量大于1，并且其中，使用的所述TCP連接的數(shù)量是至少部分地基于所確定的至少一個網(wǎng)絡狀況來確定的；以及 用于使用所述多個TCP連接中的每一個TCP連接來下載要進行下載的媒體內(nèi)容的多個媒體數(shù)據(jù)元素的程序代碼，其中，所述媒體內(nèi)容是對多個HTTP請求的響應的一部分或者全部。
30.根據(jù)權(quán)利要求29所述的非臨時性計算機可讀介質(zhì)，其中，在用的所述TCP連接的數(shù)量是至少部分地基于:針對TCP連接的估計往返時間(“ERTT”)、所述目標下載速率、以及丟失率的估計。
31.根據(jù)權(quán)利要求29所述的非臨時性計算機可讀介質(zhì)，其中，使用的所述TCP連接的數(shù)量在2和16之間，其包含和/或與以下各項的乘積成正比:(a)所述目標下載速率、(b)估計的往返時間(“ERTT”)、以及(c)估計的丟失率的平方根。
32.根據(jù)權(quán)利要求29所述的非臨時性計算機可讀介質(zhì)，還包括: 用于至少部分地基于所述目標下載速率，來確定用于所述TCP連接的TCP接收機窗口大小的程序代碼，其中，所述TCP接收機窗口大小在針對所述至少兩個連續(xù)的HTTP請求的至少兩個值之間變化。
【文檔編號】H04L29/06GK104205771SQ201380016038
【公開日】2014年12月10日 申請日期:2013年2月26日 優(yōu)先權(quán)日:2012年2月27日
【發(fā)明者】M·G·盧比, L·C·明德 申請人:高通股份有限公司