用于提供多個經(jīng)譯碼的內(nèi)容流的方法和設(shè)備的制作方法
【專利摘要】提出了一種提供具有不同比特率的內(nèi)容流的多個版本的方法。根據(jù)該方法，向客戶端提供具有不同比特率的內(nèi)容流的版本的集合。向客戶端提交描述所提供的內(nèi)容流的版本的集合的清單部分?？蛻舳苏埱缶哂刑囟ū忍芈实膬?nèi)容流的一個版本。動態(tài)地選擇提供給客戶端的版本的比特率，使得動態(tài)地適配相鄰版本的比特率之間的差異。所提出的方法改善了自適應(yīng)譯碼，使得其使用基于在當(dāng)前所交付的比特率周圍分布的比特率值的小集合的小清單部分。此外，還提出了一種用于實現(xiàn)該方法的系統(tǒng)。
【專利說明】用于提供多個經(jīng)譯碼的內(nèi)容流的方法和設(shè)備

【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種提供具有不同比特率的內(nèi)容流的多個版本的方法。根據(jù)本發(fā)明的方法，根據(jù)相同的輸入內(nèi)容流對每個版本進(jìn)行了譯碼。本發(fā)明還涉及一種適于實現(xiàn)根據(jù)本發(fā)明的方法的系統(tǒng)。

【背景技術(shù)】
[0002]如今，越來越多的數(shù)字音頻和視頻存儲在服務(wù)器上并且可以在線地交付。通過物理介質(zhì)的內(nèi)容分發(fā)正在不斷地減少。根據(jù)在線交付的第一種方式，可以將音頻和視頻內(nèi)容(A/V內(nèi)容)作為在單個文件中的整體(例如，作為數(shù)字mp3音頻文件)從服務(wù)器下載到客戶端設(shè)備。然而，在該方式下，交付諸如整個電影這樣的視頻內(nèi)容通常需要很長一段時間來下載該視頻內(nèi)容，從而延遲了用戶可以享受該視頻內(nèi)容的開始時間。
[0003]根據(jù)在線交付的第二種方式，音頻/視頻內(nèi)容被分成將被一個接一個地下載的小單元的序列。單獨的單元也被稱為“組塊”。組塊表示以幾秒鐘量級的小段時間，可以將其連結(jié)以再現(xiàn)完整的內(nèi)容。作為組塊系列被發(fā)送的組塊的整體也被稱為音頻/視頻流。音頻和視頻內(nèi)容也被稱為“流傳輸內(nèi)容”。流傳輸內(nèi)容由音頻和/或視頻流組成。
[0004]用戶可以使用各種不同設(shè)備來消耗音頻和/或視頻流。值得注意的是，視頻流可能需要適配于再現(xiàn)設(shè)備的屏幕大小的格式或表示。同樣地，音頻流可能受到由再現(xiàn)設(shè)備設(shè)置的限制。然而，下面將示例性地呈現(xiàn)本發(fā)明，其中，關(guān)注于視頻流，但是不將本發(fā)明限制于視頻流。
[0005]由于從服務(wù)器向客戶端設(shè)備對內(nèi)容進(jìn)行流傳輸?shù)倪B接中的變化，還可能需要對任何種類的流傳輸內(nèi)容進(jìn)行適配。例如，由于擁塞或者接收設(shè)備漫游所造成的變化的接收條件，無線連接可能僅提供變化的吞吐量。如果自適應(yīng)流傳輸工作正常，則因為所交付的流的最佳速率不斷地動態(tài)適配于網(wǎng)絡(luò)或重放條件的改變，所以內(nèi)容的消耗者始終能夠享受到可能的最佳內(nèi)容。
[0006]已經(jīng)提出了內(nèi)容的自適應(yīng)流傳輸?shù)母鞣N實現(xiàn)方式。
[0007]一個示例是Apple Inc.，CA的實現(xiàn)方式，也被稱為“HTTP實時流傳輸(HTTP LiveStreaming) ”或者“HLS”。R.Pantos 描述了這種實現(xiàn)方式:“HTTP Live Streaming, ”IETF,Internet-Draft Vers1n 5(draft-pantos-http-live_streaming-05),2010 年 11 月。
[0008]另一種實現(xiàn)方式由Microsoft?給出，被稱為“SiIverlight平滑流傳輸(Silverlight Smooth streaming)，，。這種實現(xiàn)方式在“IIS smooth streaming technicaloverview，，中描述。細(xì)節(jié)可以通過http://www.microsoft.com/downloads/details, aspx ?displaylang = en&FamilylD = 03d22583-3ed6-44da-8464_blb4b5ca7520 在線地得到。
[0009]又一種實現(xiàn)方式由Adobe Systems Inc.給出，被稱為“Adobe動態(tài)流傳輸(Adobe Dynamic Streaming)”。細(xì)節(jié)可以在文獻(xiàn)“HTTP dynamic streaming on theAdobe Flash platform” 中獲得，該文獻(xiàn)可以通過 http://www.adobe, com/products/httpdynamicstreaming/pdfs/httpdynamicstreamin g wp ue.pdf 在線地得至丨J0
[0010]關(guān)于自適應(yīng)流傳輸?shù)臉?biāo)準(zhǔn)化工作仍在由SA4組內(nèi)的3GPP以及由“HTTP動態(tài)自適應(yīng)流傳輸(Dynamic adaptive streaming over HTTP)(DASH)組以 MPEG 進(jìn)行。DASH 組于2011年12月公布了第一個規(guī)范發(fā)布。T.Stockhammer公布了關(guān)于該工作的細(xì)節(jié):“Dynamicadaptive streaming over HTTP-standards and design principles，，,Proc.0f the 2011ACM Conference on Multimedia Systems(MMSysE 2011), 2011 年 2 月，157-168 頁。
[0011]不同技術(shù)的共同之處在于，對于每個時間段，服務(wù)器供應(yīng)組塊的若干版本以允許比特率適配。以如下方式構(gòu)建通過服務(wù)器、編碼器、客戶端以及連接這三者的網(wǎng)絡(luò)表示的系統(tǒng):對于任何時間段，使客戶端能夠通過請求對應(yīng)的組塊版本從一個比特率切換到另一個比特率。獨立地供應(yīng)描述組塊布置的清單部分(組塊的持續(xù)時間、比特率和/或組塊的格式)，并且在進(jìn)行流傳輸?shù)那闆r下需要定期重載以便更新。
[0012]關(guān)于如何實現(xiàn)這一點的細(xì)節(jié)以及清單部分的格式根據(jù)使用的特定技術(shù)而變化:Apple HTTP實時流傳輸，Microsoft平滑流傳輸，Adobe HTTP動態(tài)流傳輸，等等。但是，全部都依賴于基本相同的概念。
[0013]對這種系統(tǒng)的常規(guī)使用是為了通過因特網(wǎng)從網(wǎng)絡(luò)服務(wù)器向任何客戶端交付數(shù)據(jù)。這種服務(wù)器(以及在交付路徑上的http高速緩沖存儲器)存儲客戶端可能在特定時間請求的所有的組塊版本。
[0014]在先前提交的歐洲專利申請EP 1130609.3中，發(fā)明人描述了一種HTTP自適應(yīng)譯碼器，其允許動態(tài)地對AV流進(jìn)行譯碼，并且將其傳送給實現(xiàn)這種HTTP自適應(yīng)流傳輸協(xié)議的客戶端。在EP 1130609.3中所述的自適應(yīng)譯碼器具有有限的計算資源，因此，僅譯碼成單個或者數(shù)量非常少的不同的比特率，而在清單文件中向客戶端廣告更多可能的比特率。根據(jù)客戶端請求動態(tài)地適配編碼器的目標(biāo)比特率，從而維持了 HTTP自適應(yīng)交付的有利之處，即:對網(wǎng)絡(luò)和/或終端限制的動態(tài)適配。自適應(yīng)譯碼器也被稱為譯碼平臺。
[0015]使用HTTP自適應(yīng)流傳輸，服務(wù)器必須決定它將提出內(nèi)容的多少個版本并且以哪些比特率。另一方面，可供選擇的比特率的數(shù)量越大，客戶端就越能更好地適配當(dāng)前網(wǎng)絡(luò)吞吐量條件，同時維持可能的最佳音頻和視頻(A/V)質(zhì)量。另一方面，HTTP服務(wù)器通常必須存儲許多數(shù)據(jù)，其取決于組塊版本的數(shù)量。例如，僅供應(yīng)lMbps、2Mbps和3Mbps這3個級別意味著該流使用與僅提供最高比特率所需的數(shù)據(jù)量相比兩倍的數(shù)據(jù)量。因此，在增加具有不同比特率的可用版本的數(shù)量時，加載到服務(wù)器上的數(shù)據(jù)可能迅速地成為內(nèi)容的正常量的若干倍。
[0016]使用在EP 1130609.3中描述的上面所提及的設(shè)備(其即時地進(jìn)行譯碼，并且不生成“未請求的”組塊)，AV流的數(shù)據(jù)量不取決于所提出的比特率的數(shù)量。因此，能夠顯著地增加被廣告的比特率的數(shù)量，從而使客戶端能夠非常精確地適配其需求。例如，在不同版本的內(nèi)容之間的步長(step)大小為50 kbps的從IMbps到3Mbps的比特率范圍內(nèi)，有41種可能的比特率將被廣告。被廣告的比特率組成客戶端的播放列表。
[0017]然而，描述可用比特率的集合的清單部分的大小與所提出的比特率的數(shù)量成正t匕。在播放實時流時，客戶端需要相當(dāng)頻繁地刷新其播放列表，其中包括針對可用比特率而重載清單部分。因此，在可用比特率的數(shù)量變高時，與內(nèi)容比特率相比，以清單部分的形式傳送的描述性數(shù)據(jù)的量就不小了。對于運行在客戶端上用于處理流傳輸內(nèi)容的應(yīng)用，這還增加了分析工作。
[0018]本發(fā)明解決如上所述的清單部分的大小的問題。


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

[0019]根據(jù)第一方面，本發(fā)明提出通過如下方法解決上述問題:向客戶端(4)提供具有不同比特率的內(nèi)容流的版本的集合，其中，該方法包括以下步驟:
[0020]a)準(zhǔn)備描述所提供的內(nèi)容流的版本的集合的清單部分；
[0021]b)向所述客戶端(4)提交所述清單部分；
[0022]c)從所述客戶端(4)接收對具有特定比特率的內(nèi)容流的一個版本的請求；
[0023]d)將內(nèi)容流的版本譯碼成由所述客戶端(4)請求的比特率；
[0024]f)動態(tài)地選擇提供給所述客戶端(4)的版本的比特率，使得動態(tài)地適配相鄰版本的比特率之間的差異；以及
[0025]g)重復(fù)步驟a)到f)。
[0026]本發(fā)明的想法是改善自適應(yīng)譯碼器，使得其使用基于在當(dāng)前所交付的比特率周圍分布的比特率值的小集合的小清單部分。
[0027]在有利的實現(xiàn)方式中，該方法還包括向單個客戶端提供內(nèi)容流的版本的集合的步驟。
[0028]發(fā)現(xiàn)如果該方法還包括如下步驟則是有用的:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得相鄰比特率取決于由所述客戶端請求的比特率的改變。
[0029]同樣地，發(fā)現(xiàn)如果該方法還包括如下步驟則是有用的:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得比特率的差異取決于所述客戶端有多頻繁地請求不同的比特率。
[0030]在有利的實施例中，該方法還包括如下步驟:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得比特率的差異取決于與當(dāng)前所接收的版本的比特率相比，由所述客戶端請求的比特率的改變有多大。
[0031]在又一個實施例中，本發(fā)明的方法還包括如下步驟:供應(yīng)所提供的比特率的集合，所述比特率的集合包括對更加接近于當(dāng)前所請求的比特率的相鄰比特率具有增加的差異的比特率。
[0032]有利地，所述方法還包括如下步驟:供應(yīng)所提供的比特率的集合，其中每個到相鄰比特率具有相等間距。
[0033]在有利的實現(xiàn)方式中，所述方法還包括如下步驟:如果所請求的版本的比特率與當(dāng)前所接收的版本的比特率相比的差異超過閾值，則動態(tài)地適配不同版本的相鄰比特率的步長大小。
[0034]根據(jù)第二方面，本發(fā)明提出了一種適于實現(xiàn)根據(jù)本發(fā)明的方法的系統(tǒng)。

【專利附圖】

【附圖說明】
[0035]在附圖中，例示了本發(fā)明的實施例。
[0036]附圖示出:
[0037]圖1，本發(fā)明實現(xiàn)方式的示意性框圖；
[0038]圖2a到2c，示出在不同條件下所提供的版本的比特率的圖表；
[0039]圖3，示出特殊情況的比特率的圖表；以及
[0040]圖4，例示本發(fā)明方法的流程圖。

【具體實施方式】
[0041]圖1示出實現(xiàn)本發(fā)明的系統(tǒng)I的示意性框圖。系統(tǒng)I包括源2、適配平臺3和再現(xiàn)設(shè)備4。
[0042]源2是流傳輸內(nèi)容(例如,視頻內(nèi)容)的起點。換言之,源2是流傳輸內(nèi)容的供應(yīng)者。例如，它可以是交付任何種類的家庭或預(yù)付費視頻的家庭設(shè)備，或者交付可以被表示為文件的或從網(wǎng)絡(luò)流傳輸?shù)膹V播或多播視頻(DVB-T、DVB-1PTV等)乃至視頻點播服務(wù)(VoD服務(wù))的外部內(nèi)容供應(yīng)者。作為示例，在圖1中，源2被示為以DVB和IPTV信號的形式來提供A/V內(nèi)容。
[0043]再現(xiàn)設(shè)備4是商用終端或者客戶端設(shè)備，其能夠根據(jù)其能力和網(wǎng)絡(luò)條件以不同的質(zhì)量來播放音頻和/或視頻。在本專利申請中，客戶端設(shè)備是允許用戶連接到服務(wù)器、下載內(nèi)容并且以對該用戶可聽且可見的方式來再現(xiàn)該內(nèi)容的任何設(shè)備。在本專利申請中，同義地使用術(shù)語“客戶端設(shè)備”和“客戶端”。在HTTP自適應(yīng)流傳輸?shù)漠?dāng)前背景下，再現(xiàn)設(shè)備4也被稱為客戶端4。優(yōu)選像HTTP自適應(yīng)流傳輸這樣的協(xié)議，因為其允許客戶端4恰好在播放它之前請求合適的質(zhì)量。
[0044]適配平臺3裝備有多路分離器6 ( “多路分離”)，用于(如果適用)將進(jìn)入的內(nèi)容流多路分離成分開的音頻和視頻成分。在解碼器7 “解碼”中對視頻成分進(jìn)行解碼，并且在分割單元8 “分割”中進(jìn)行分割。然后，在編碼器9 “編碼”中對片段(“源組塊”)進(jìn)行譯碼，亦即，使用不同于原始參數(shù)的參數(shù)重新編碼。編碼器9可以是H.264編碼器，但是，其他格式同樣是可行的。在分割單元11 “分割”中將音頻成分分成片段(“音頻組塊”)，并且也可以對其進(jìn)行譯碼(未示出)。然后，向多路復(fù)用器12 “TS多路復(fù)用”供應(yīng)音頻片段和經(jīng)譯碼的視頻片段。多路復(fù)用器12根據(jù)M3U8清單格式準(zhǔn)備清單部分。多路復(fù)用器12“TS多路復(fù)用”在海量存儲設(shè)備13 “文件”中存儲經(jīng)譯碼并多路復(fù)用的片段和清單部分，服務(wù)器14 “網(wǎng)絡(luò)服務(wù)器”(例如，HTTP服務(wù)器)從該海量存儲設(shè)備向客戶端4傳遞片段。
[0045]如在更上面所述的那樣，本發(fā)明在實現(xiàn)為適配平臺3或者具有有限處理能力的譯碼器(例如，基于英特爾CE4200處理器的具有基本媒體處理能力的因特網(wǎng)網(wǎng)關(guān))時特別有用。
[0046]本領(lǐng)域的技術(shù)人員將認(rèn)識到，對在上述實施例中使用的H.264編碼解碼器和M3U8清單格式的選擇，僅對于描述在應(yīng)用于Apple客戶端設(shè)備時的本發(fā)明是必需的。在編碼資源過于缺乏以致不能并行地生成流的所有必要替代版本時，需要諸如VCUWebM這樣的其他編碼解碼器和其他清單格式的其他自適應(yīng)流傳輸實現(xiàn)方式同樣能夠受益于所述發(fā)明。
[0047]在對實時視頻進(jìn)行流傳輸?shù)那闆r下，清單通告隨時間改變的組塊的集合。所通告的變體的集合也變化。這在本發(fā)明中使用，通過動態(tài)地修改所提出的變體的集合或者所提供的版本的集合。根據(jù)連接的吞吐量的過去的變化來更新在清單中給出的版本。換言之，還可以說，響應(yīng)于客戶端的請求來更新清單部分中的版本，對此將在下面作進(jìn)一步的解釋。
[0048]因為適配平臺3具有生成組塊的實際比特率和客戶端4所請求的比特率之間的松散聯(lián)系，所以能夠相當(dāng)自由地生成清單。根據(jù)本發(fā)明，適配平臺3選擇下面的要提出給客戶端的比特率。
[0049]適配平臺對客戶端提出當(dāng)前目標(biāo)比特率，S卩，客戶端所請求的最后的比特率。這很重要，因為在網(wǎng)絡(luò)條件穩(wěn)定時，客戶端將收斂到最優(yōu)值并保持請求最優(yōu)值。因此，需要提出它。
[0050]適配平臺3還提出一些相當(dāng)接近于當(dāng)前目標(biāo)比特率的比特率。為了客戶端的最佳收斂(可能的最好質(zhì)量，同時恰好處于最大可用帶寬之下)，提出從當(dāng)前所接收的比特率分開小步長大小的替代比特率。這樣允許客戶端4做出具有平滑的質(zhì)量改變的精確適配。這對于終端用戶的所感知的視覺質(zhì)量是很重要的。
[0051]除此之外，適配平臺3提出遠(yuǎn)離當(dāng)前目標(biāo)的一些其他比特率。這允許客戶端4在網(wǎng)絡(luò)條件顯著地改變時做出快速的適配。
[0052]在具體的示例中，假設(shè)用2Mbps的比特率交付內(nèi)容流的一個版本。然后，清單提供具有如下比特率的一組版本:IMbpsU.5Mbps、l.8Mbps、l.9Mbps、l.95Mbps,2Mbps,
2.05Mbps、2.lMbps、2.2MbpsΛ2.5Mbps、3Mbps。
[0053]實際上，步長的數(shù)量以及步長之間的間隔可以適配于系統(tǒng)I的各種參數(shù)。
[0054]甚至能夠根據(jù)客戶端4的行為動態(tài)地改變安排步長的方式。當(dāng)所請求的比特率相當(dāng)穩(wěn)定時，本發(fā)明提出更多的具有非常小的步長的接近當(dāng)前所交付的版本之一的比特率以及更少的遠(yuǎn)離當(dāng)前比特率的比特率。當(dāng)條件變得穩(wěn)定時，本發(fā)明提出在比特率之間用規(guī)律的步長來隔開比特率，使得客戶端能夠在可用的比特率范圍內(nèi)的任何區(qū)域中重新定位其自身。
[0055]在圖2a到2c中例示了所述情形,示出了 IMbps到3Mbps范圍中的比特率的標(biāo)度
21。豎線示出了向客戶端4提出或提供的比特率。標(biāo)度21中間的長豎線代表“當(dāng)前的”比特率。圖2a到2c例示了向客戶端4提出具有10個替代比特率的版本的本發(fā)明的示例性實施例。
[0056]圖2a示出了穩(wěn)定情形的比特率，在當(dāng)前所交付的比特率周圍具有小步長。如在圖2a中所示，不向客戶端4提出在IMbps和3Mbps處的最低和最高的可能比特率。所提出的比特率反而跨越更加有限的范圍，因為在穩(wěn)定帶寬的假設(shè)下，客戶端未必需要改變成諸如本實施例中的IMbps或3Mbps這樣的極值。
[0057]圖2c示出了跨越全部可用范圍的一組間隔相等的比特率。在條件不穩(wěn)定并且客戶端4將能夠轉(zhuǎn)到該可用范圍內(nèi)的“任何”比特率時，使用比特率的這種選擇。
[0058]圖2b示出了中間情形，其中，與圖2a相比，所提出的比特率不太集中于當(dāng)前所交付的比特率的周圍，但是仍然像在圖2c中那樣地不是等間距的。
[0059]圖2a到2c例示了本發(fā)明的一個基本概念，即，動態(tài)地選擇要提供給客戶端4的版本的比特率，使得動態(tài)地適配相鄰版本的比特率之間的差異。相鄰版本的比特率之間的差異在圖2a到2c以及圖3中對應(yīng)于豎線之間的間距。
[0060]實際上，所提出的比特率的數(shù)量可以不同，而不會影響本發(fā)明的想法，并且可以隨時間變化。如圖2a到2c所示，所提出的比特率的集合也并不需要對稱地分布。例如，在當(dāng)前所請求的比特率與給定內(nèi)容的可能范圍相比非常低或者非常高時，可以有更小數(shù)量的具有小間距的值分別低于或者高于當(dāng)前比特率，并且有更大數(shù)量的具有更大間隔的值分別高于或者低于當(dāng)前比特率。
[0061]圖3示出了當(dāng)前所交付的比特率處于可用比特率范圍的上限的情形。因此，所提供的其他全部的比特率都低于當(dāng)前所交付的比特率。
[0062]在本發(fā)明的具體實施例中，使用以下過程:
[0063]將被廣告比特率的數(shù)量設(shè)置為11。
[0064]對于給定內(nèi)容，確定最小和最大的比特率值。最大值是視頻在其可能的最好質(zhì)量(亦即，理想地、無需譯碼的質(zhì)量)下的比特率。在源2和輸出編碼解碼器9的比特率必須不同的情況下，那么譯碼是強(qiáng)制性的，并且最大比特率可以與源比特率不同。最小比特率被確定為終端用戶的最低可接受的比特率。這是相當(dāng)主觀的，并且取決于設(shè)備類型(對于HD電視機(jī)，期待比移動電話更好的質(zhì)量)和用戶偏好。例如，最大比特率(max)和最小比特率(min)之間的比值是10。
[0065]然后，在任何時間點上，將當(dāng)前比特率B視為最后請求的比特率。關(guān)于啟動，由譯碼器選擇某個初始值，對此在歐洲專利申請EP 1130609.3中也進(jìn)行了解釋。這個比特率始終包括在被廣告的比特率的列表中。對于剩余的10個比特率值，首先，決定它們中的低于或者高于B的數(shù)量。使這兩個數(shù)量分別與(B-min)和(max-B)成正比，但是將最低的數(shù)量舍入成高限值(ceilingvalue)。這意味著,除了在B恰好等于最小或最大比特率的時候,小的一側(cè)始終具有至少一個值。例如，如果B對應(yīng)于在低端處受限于最小比特率并且在高端處受限于最高比特率的比特率區(qū)間(簡而言之，該區(qū)間記為[min，max])中的75%的值，則有7個被廣告的值低于B，并且有3個高于B。如果B對應(yīng)于區(qū)間[min，max])中的90%的值，則有9個被廣告的值低于B，并且有I個被廣告的值高于B。特別要指出的是，如果B對應(yīng)于區(qū)間值[min，max])中的99%的值，則仍然有9個被廣告的值低于B，并且有一個被廣告的值高于B。
[0066]然后，為了將值放置到每個區(qū)間中，測量客戶端4的“穩(wěn)定性”。為此目的，交付內(nèi)容組塊的網(wǎng)絡(luò)服務(wù)器14收集從客戶端4請求的比特率值。由此計算客戶端所請求的最后20個比特率值的集合的標(biāo)準(zhǔn)偏差σ。令N為如上所解釋的要產(chǎn)生的高于B的比特率的數(shù)量。如果σ大于(max-B)/N，則請求的不穩(wěn)定性要求供應(yīng)等間隔的比特率。否則，對于使用[1，N](從I到N的自然數(shù)區(qū)間)中的n，使用比值P = (max-B)/(N X σ )來產(chǎn)生值n~P (其他寫法:ηΡ)。通過乘以(max-B)/Ν~ P并且添加基值B，那些N個值最后被縮減至正確的范圍。
[0067]通過使用B-min而不是公式中的max_B,容易地將同一算法應(yīng)用于低于B的值。
[0068]要指出的是，其他公式也產(chǎn)生預(yù)期效果。本發(fā)明不限于如何計算網(wǎng)絡(luò)穩(wěn)定性的具體方式。
[0069]本發(fā)明的主要優(yōu)點在于，允許A/V內(nèi)容的自適應(yīng)交付高精確度地收斂到任何最優(yōu)值，同時不需要廣告關(guān)于覆蓋所有可能比特率的替代版本的非常冗長的列表。
[0070]提供小的比特率步長也是有幫助的，因為這降低了所請求的比特率和以有限數(shù)量的(多個)比特率對組塊進(jìn)行預(yù)譯碼而引入的所供應(yīng)的組塊之間的差異。例如，如果客戶端請求了比特率為B的組塊N，自適應(yīng)譯碼器準(zhǔn)備具有相同比特率B的組塊N+1以及具有比特率B的后續(xù)組塊N+2。換言之，在向自適應(yīng)譯碼器發(fā)送對另一比特率的請求時與在以所請求的比特率生成第一組塊時之間存在延遲。例如，如果客戶端需要從比特率B改變?yōu)楦偷谋忍芈蔅’，并且隨后請求具有比特率B’的組塊N+1，則實際上它仍然將以比特率B而非比特率B’接收組塊N+1和組塊N+2。譯碼器僅對組塊N+3以比特率B’進(jìn)行編碼。
[0071]當(dāng)B和B’之間的差異較大時，發(fā)送過多數(shù)據(jù)的這種延遲可能會餓死客戶端緩沖器并且導(dǎo)致客戶端4中的視頻定格(freeze)。原因是，因為要接收的組塊與可用帶寬相比過大，所以將會花費很長一段時間到達(dá)。在這段時間期間，客戶端4可能已經(jīng)使用了所有先前緩沖的數(shù)據(jù)并且可能已經(jīng)停止了播放，等待剩余數(shù)據(jù)到達(dá)。
[0072]提供更小的步長將給予客戶端更頻繁地但是以很小的比特率差異來改變的機(jī)會，從而降低了客戶端4中的視頻定格的風(fēng)險。
[0073]構(gòu)建比特率列表所需的計算在計算能力方面成本不高。這種小成本是通過節(jié)省清單部分中的傳送給客戶端4的量并且還諸如通過海量存儲13中的符號鏈接限制生成《偽組塊》的成本來平衡的?？梢詫Υ私忉屓缦?在自適應(yīng)譯碼器中，在以比特率B生成組塊時，創(chuàng)建針對每個比特率的一個文件并且以清單的形式用信號告知。網(wǎng)絡(luò)服務(wù)器僅需要為所請求的文件服務(wù)。利用組塊號碼和比特率值來構(gòu)建文件的文件名。創(chuàng)建全部指向同一文件的符號鏈接，而不是利用大量存儲空間來復(fù)制文件。然而，即使創(chuàng)建鏈接也是有成本的，因為它是文件系統(tǒng)調(diào)用。如果針對每個組塊發(fā)生很多次，則所需要的計算能力可能是相當(dāng)大的。
[0074]要指出的是，僅在客戶端4的穩(wěn)定性改變超過預(yù)定閾值時，才對由適配平臺3提供的版本的比特率的集合進(jìn)行適配。在一個實施例中，將閾值定義為針對與在預(yù)定時間段期間內(nèi)的當(dāng)前所交付的比特率不同的比特率的請求的特定數(shù)量。在另一實施例中，將閾值定義為所請求的比特率與當(dāng)前所交付的比特率相比的差異。在本發(fā)明的實現(xiàn)方式中，可以有一個以上的閾值。超過一個或若干閾值將引發(fā)對所提供的版本的集合的比特率的適配。
[0075]圖4以流程圖例示了根據(jù)本發(fā)明的方法的原理。在步驟41中，適配平臺3向客戶端4提供具有不同比特率的A/V內(nèi)容的版本。在步驟42中，適配平臺3還準(zhǔn)備所提供的版本的清單部分。在步驟43中，適配平臺3向客戶端4提交清單部分?？蛻舳嗽诓襟E44中請求內(nèi)容的特定版本。響應(yīng)于客戶端4的請求，適配平臺3選擇所提供的版本的比特率。如上所述，所選擇的比特率可以根據(jù)客戶端4的請求而改變或者不改變。如通過循環(huán)46所表示的，該方法返回到步驟41，其中適配平臺3向客戶端4提供內(nèi)容的版本的集合。
[0076]根據(jù)本發(fā)明的系統(tǒng)通過允許收斂到接近于最優(yōu)比特率(亦即，在面對穩(wěn)定的網(wǎng)絡(luò)條件時的客戶端的穩(wěn)定行為)而改善了使用自適應(yīng)譯碼器獲得的用戶體驗。在高于和低于期望值的兩個值之間沒有振蕩。
[0077]附圖標(biāo)號列表
[0078]I 系統(tǒng)
[0079]2 源
[0080]3適配平臺
[0081]4再現(xiàn)設(shè)備
[0082]6多路分離器
[0083]7解碼器
[0084]8視頻分割單元
[0085]9編碼器
[0086]11音頻分割單元
[0087]12多路復(fù)用器
[0088]13海量存儲
[0089]14服務(wù)器
[0090]21比特率標(biāo)度
[0091]41提供版本的步驟
[0092]42準(zhǔn)備清單部分的步驟
[0093]43提交清單部分的步驟
[0094]44請求特定版本的步驟
[0095]45選擇比特率的步驟
[0096]46循環(huán)
【權(quán)利要求】
1.一種向客戶端(4)提供具有不同比特率的內(nèi)容流的版本的集合的方法，其中所述方法包括以下步驟: a)準(zhǔn)備描述所提供的內(nèi)容流的版本的集合的清單部分； b)向所述客戶端(4)提交所述清單部分； c)從所述客戶端(4)接收對具有特定比特率的內(nèi)容流的一個版本的請求； d)將內(nèi)容流的版本譯碼成由所述客戶端(4)請求的比特率； f)動態(tài)地選擇在所述清單部分中向所述客戶端(4)提供的版本的比特率，使得動態(tài)地適配相鄰版本的比特率之間的差異；以及 g)重復(fù)步驟a)到f)。
2.根據(jù)權(quán)利要求1所述的方法，其中所述方法還包括如下步驟:向單個客戶端(4)提供所述內(nèi)容流的版本的集合。
3.根據(jù)權(quán)利要求1所述的方法，其中所述方法還包括如下步驟:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得相鄰比特率取決于由所述客戶端(4)請求的比特率的改變。
4.根據(jù)權(quán)利要求3所述的方法，其中所述方法還包括如下步驟:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得比特率的差異取決于所述客戶端有多頻繁地請求不同的比特率。
5.根據(jù)權(quán)利要求3所述的方法，其中所述方法還包括如下步驟:動態(tài)地適配所提供的比特率的集合中的不同的相鄰版本之間的比特率差異，使得比特率的差異取決于與當(dāng)前所接收的版本的比特率相比，由所述客戶端請求的比特率的改變有多大。
6.根據(jù)權(quán)利要求3所述的方法，其中所述方法還包括如下步驟:供應(yīng)所提供的比特率的集合，所述比特率的集合包括對更加接近于當(dāng)前所請求的比特率的相鄰比特率具有增加的差異的比特率。
7.根據(jù)權(quán)利要求3所述的方法，其中所述方法還包括如下步驟:供應(yīng)所提供的比特率的集合，其中每個到相鄰比特率具有相等間距。
8.根據(jù)權(quán)利要求3至5中的一項或若干項所述的方法，其中所述方法還包括如下步驟:如果所請求的版本的比特率與當(dāng)前所接收的版本的比特率相比的差異超過閾值，則動態(tài)地適配不同版本的相鄰比特率的步長大小。
9.一種適于實現(xiàn)根據(jù)前述權(quán)利要求中的一項或若干項所述的方法的系統(tǒng)(I)。
【文檔編號】H04N21/24GK104247368SQ201380020259
【公開日】2014年12月24日 申請日期:2013年4月24日 優(yōu)先權(quán)日:2012年5月4日
【發(fā)明者】R.霍戴利, S.古阿什, C.德勞奈 申請人:湯姆遜許可公司