低延時實況視頻流傳輸?shù)闹谱鞣椒?br>【技術(shù)領(lǐng)域】
[0001] 本公開內(nèi)容總體上設(shè)及數(shù)字媒體分發(fā)領(lǐng)域，并且更特別地設(shè)及用于低延時視頻流 傳輸?shù)募夹g(shù)。
【背景技術(shù)】
[0002] 流式視頻是在由提供者遞送之時被向用戶呈現(xiàn)的多媒體形式，該多媒體形式有別 于設(shè)及到在回放視頻內(nèi)容之前接收完整視頻內(nèi)容的簡單文件傳送。已經(jīng)采用了超文本傳送 協(xié)議化1T巧作為用于經(jīng)由因特網(wǎng)用流傳輸視頻內(nèi)容的可伸縮和高效協(xié)議。HTTP實況流傳 輸化L巧、HTTP動態(tài)流傳輸（皿巧和通過HTTP的動態(tài)自適應(yīng)流傳輸值A(chǔ)SH)是用于從HTTP web服務(wù)器用流傳輸多媒體的現(xiàn)有技術(shù)的示例。視頻內(nèi)容被劃分成一系列文件段。使用該 些協(xié)議來個別地遞送每個段。例如，利用現(xiàn)有HTTP流傳輸技術(shù)，段具有固定間隔，并且每個 段被視為用于HTTP請求和HTTP響應(yīng)的分離的源。作為結(jié)果，直至完全地生成了視頻內(nèi)容 所屬于的完整固定間隔的視頻段、才可W遞送和回放視頻內(nèi)容。實況視頻流傳輸（例如，來 自實況體育事件）的延時一般是在實況事件發(fā)生時與在向用戶回放它時之間的時間差。因 此，延時至少是一個視頻段間隔的持續(xù)時間，并且遭受到附加緩沖延遲和網(wǎng)絡(luò)延遲。每個段 經(jīng)常至少若干秒長，該可能造成數(shù)十秒的延時。該樣的延遲特別是在時間關(guān)鍵的實況流傳 輸場景中是不希望的。

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

[0003] 本發(fā)明的各實施例設(shè)及低延時實況視頻流傳輸。
[0004] 根據(jù)本發(fā)明的一個實施例，公開了一種計算機實施的方法，包括：在從實況內(nèi)容源 接收多媒體內(nèi)容的部分時生成多個視頻段，每個段代表該多媒體內(nèi)容的相應(yīng)的該部分；從 客戶端計算設(shè)備接收對于該視頻段中的至少兩個視頻段的僅一個HTTP請求；W及根據(jù)預(yù) 定義的推送策略從服務(wù)器計算機向該客戶端計算設(shè)備推送該至少兩個視頻段，而無需來自 該客戶端的、對于該視頻段中的每個視頻段的分離的HTTP請求。
[0005] 根據(jù)本
【發(fā)明內(nèi)容】
的另一實施例，公開了一種計算機實施的方法，包括：由客戶端計 算設(shè)備向服務(wù)器計算機發(fā)送對于至少兩個視頻段的僅一個HTTP請求，該至少兩個視頻段 代表多媒體內(nèi)容的部分；由該客戶端計算設(shè)備根據(jù)預(yù)定義的推送策略從該服務(wù)器計算機接 收該至少兩個視頻段，而無需來自該客戶端計算設(shè)備的、對于該視頻段中的每個視頻段的 分離的HTTP請求；W及由該客戶端計算設(shè)備使用該至少兩個視頻段來回放該多媒體內(nèi)容。
[0006] 根據(jù)本發(fā)明的又一實施例，公開了一種系統(tǒng)，包括：存儲裝置；W及處理器，該處 理器操作地禪合到該存儲裝置并且配置為執(zhí)行在該存儲裝置中存儲的指令，該指令在被執(zhí) 行時使得該處理器執(zhí)行過程，該過程包括：在從實況內(nèi)容源接收多媒體內(nèi)容的部分時生成 多個視頻段，每個段代表該多媒體內(nèi)容的相應(yīng)的該部分；從客戶端計算設(shè)備接收對于該視 頻段中的至少兩個視頻段的僅一個HTTP請求；W及根據(jù)預(yù)定義的推送策略從該系統(tǒng)向該 客戶端計算設(shè)備推送該至少兩個視頻段，而無需來自該客戶端計算設(shè)備的、對于該視頻段 中的每個視頻段的分離的HTTP請求。
【附圖說明】
[0007] 附圖并未旨在于按比例繪制。在附圖中，在各圖中圖示的每個相同或者接近相同 的部件由相似標號代表。
[000引圖1圖示了根據(jù)本發(fā)明的一個實施例的、用于低延時實況視頻流傳輸?shù)氖纠蛻?端-服務(wù)器系統(tǒng)。
[0009] 圖2圖示了根據(jù)本發(fā)明的一個實施例的、用于示例請求-響應(yīng)視頻流傳輸推送策 略的流程圖。
[0010] 圖3圖示了根據(jù)本發(fā)明的一個實施例的、用于另一示例請求-響應(yīng)視頻流傳輸推 送策略的流程圖。
[0011] 圖4圖示了根據(jù)本發(fā)明的一個實施例的、用于又一示例請求-響應(yīng)視頻流傳輸推 送策略的流程圖。
[0012] 圖5示出了根據(jù)本發(fā)明的一個實施例的、用于低延時實況視頻流傳輸?shù)氖纠?wù) 器側(cè)方法。
[0013] 圖6示出了根據(jù)本發(fā)明的一個實施例的、用于低延時實況視頻流傳輸?shù)氖纠蛻?端側(cè)方法。
[0014] 圖7是代表可W根據(jù)本發(fā)明的一個實施例被使用的示例計算設(shè)備的框圖。
【具體實施方式】
[0015] 如W上指出的那樣，已經(jīng)采用了HTTP流傳輸作為用于通過因特網(wǎng)遞送視頻內(nèi)容 的方案。該部分地由于HTTP服務(wù)器或者高速緩存的普遍性和可伸縮性。HTTP是無狀態(tài)通 信協(xié)議。一般而言，無狀態(tài)協(xié)議是如下通信協(xié)議，該通信協(xié)議將對于信息的每個請求視為與 任何先前請求無關(guān)的獨立事務(wù)，從而使得通信由獨立對的請求和響應(yīng)構(gòu)成。存在包括實況 視頻流傳輸?shù)娜舾深愋偷囊曨l流傳輸服務(wù)。實況視頻流傳輸是對實況事件（比如體育競 賽）的視頻的遞送。理想地，該樣的實況流傳輸在生成內(nèi)容時實時（其中實質(zhì)上沒有延遲） 或者接近實時（其中延遲不顯著）地出現(xiàn)。因此，對于實況視頻流傳輸，視頻流傳輸解決方 案應(yīng)當具有相對低的延時。然而，現(xiàn)有HTTP視頻流傳輸技術(shù)對于低延時應(yīng)用（比如實況視 頻流傳輸）并不適合，因為對視頻內(nèi)容的分割在個別地封裝、請求和實現(xiàn)每個段時引入在 服務(wù)器與客戶端之間的至少一個段延遲。一種用于減少延時的解決方案是減少每個段的長 度。然而，減少段長度的結(jié)果是段數(shù)目成比例地增加（例如，使段長度減半使段總數(shù)加倍）。 由于每個段被視為分離的資源，所W由客戶端發(fā)布的HTTP請求的數(shù)目隨著段數(shù)目增加。例 如，對于六十秒實況事件，如果段持續(xù)時間是四秒，則將共計有十五個請求/響應(yīng)對。然而， 如果段持續(xù)時間被減少成一秒，則請求/響應(yīng)對的數(shù)目將增長成六十。因而，非常小的段持 續(xù)時間可能造成HTTP請求和響應(yīng)的數(shù)目劇增。由于每個請求和響應(yīng)給客戶端、服務(wù)器和網(wǎng) 絡(luò)基礎(chǔ)結(jié)構(gòu)帶來附加處理開銷，所W該一簡單解決方案不能獲得充分數(shù)量的延時減少。
[0016] 為此，該里公開了用于低延時視頻流傳輸?shù)募夹g(shù)。根據(jù)本發(fā)明的一個實施例，客戶 端可W被配置為向服務(wù)器發(fā)送對于實況視頻流傳輸?shù)膯蝹€請求。服務(wù)器可W被配置為按照 預(yù)定義的推送策略向客戶端發(fā)送或者推送一個或者多個視頻段。例如，使用所謂的全推送 策略，客戶端向服務(wù)器發(fā)送僅一個請求，并且作為響應(yīng)，一旦每個段完成，服務(wù)器就向客戶 端推送所有視頻段?？蒞使用其它推送策略，比如W下進一步具體描述的推送策略?？蒞 利用無狀態(tài)通信協(xié)議（比如HTTP2.0)來推送視頻段。該一技術(shù)消除了在使用小段時的請 求劇增問題。另外，可W在一些實施例中變化用每個請求推送的段的數(shù)目，W便提供用于客 戶端切換成適當比特率段而控制任何附加開銷的方式。許多配置和變化將按照本公開內(nèi)容 而變得清楚。
[0017] 如該里所用，術(shù)語"內(nèi)容"和"多媒體內(nèi)容"包括音頻、視頻、靜止相片、數(shù)據(jù)、圖形 或者可W在任何聯(lián)網(wǎng)的信息系統(tǒng)（比如萬維網(wǎng)）中標識、尋址、引用或者處置的任何其它信 息或者可W經(jīng)由物理介質(zhì)（比如便攜USB驅(qū)動、CD、DVD或者藍光盤）從發(fā)布者向終端用戶 遞送的任何信息。一般而言，內(nèi)容包括數(shù)字形式的任何形式的信息；然而，可W在非數(shù)字形 式（例如，模擬）或者數(shù)字形式和非數(shù)字形式的組合中體現(xiàn)內(nèi)容。術(shù)語"視頻"如該里所用 旨在于包括所有類型的多媒體內(nèi)容。
[0018] HTTP2. 0如該里引用的那樣是例如萬維網(wǎng)被使用的HTTP通信協(xié)議的版本。HTTP 2.0由因特網(wǎng)工程任務(wù)小組（IET巧使用Google,Inc.的SPDY?作為起點來標準化。與例 如HTTP1.1比較，HTTP2.0通過使用頭部字段壓縮和允許在相同連接上的多個并行消息 來實現(xiàn)對網(wǎng)絡(luò)資源的更高效的使用和減少的延時感知。HTTP2.0也支持數(shù)據(jù)從服務(wù)器向 客戶端的非請求推送。然而，HTTP2.0未被設(shè)計用于視頻流傳輸應(yīng)用，并且服務(wù)器推送機 制不能被直接采用W用于視頻流傳輸。為此，該里公開的技術(shù)允許對視頻流傳輸應(yīng)用的W HTTP2. 0服務(wù)器推送為基礎(chǔ)的遞送，該些實況視頻流傳輸應(yīng)用包括例如運用基于皿S、化S 和DA甜的客戶端的實況視頻流傳輸應(yīng)用。
[0019] 如該里所用，術(shù)語"推送"和"服務(wù)器推送"一般是指基于網(wǎng)絡(luò)的通信，其中可W在 實況視頻段變成可用時從web服務(wù)器向客戶端主動地推送段而無需來自客戶端的對于每 個段的分離的HTTP請求。在該里提供的一個特別的示例實施例中，實況服務(wù)器推送策略在 接收單個請求之后推送多個視頻段。W該一方式，可W通過減少段持續(xù)時間來實現(xiàn)低延時 實況流傳輸體驗而未引起多個請求的高度地增加的請求開銷。推送服務(wù)與拉取服務(wù)對照， 在拉取服務(wù)中，對每一個段的傳輸由來自數(shù)據(jù)的接收方（例如，服務(wù)器的客戶端）的分離的 請求發(fā)起?？蒞如該里提供的那樣利用的推送服務(wù)的一個示例是HTTP2.0服務(wù)器推送，該 服務(wù)器推送一般包括從web服務(wù)器向web瀏覽器發(fā)送非請求或者異步數(shù)據(jù)。如將按照本公 開內(nèi)容被認識到的那樣，提供實況視頻內(nèi)容推送服務(wù)的web服務(wù)器未必必須在已經(jīng)向客戶 端推送了實況視頻數(shù)據(jù)的第一段之后終止與客戶端的連接。取而代之，web服務(wù)器可W讓 連接開放，從而使得如果事件出現(xiàn)（新內(nèi)容變成可用），則可W使用現(xiàn)有連接來立即發(fā)送出 它。
[0020] 基于HTTP的視頻流傳輸技術(shù)的現(xiàn)有版本（包括化S、皿S、平滑流傳輸和DASH)未 被設(shè)計或者優(yōu)化用于與HTTP2.0的服