本發(fā)明一般而言涉及來自實況輸入流的自適應位速率流的實況編碼領域。具體而言，本發(fā)明涉及用于優(yōu)化和改進來自實況輸入流的自適應位速率流的實況編碼的若干技術。

背景技術：

流傳輸技術已經(jīng)進步到支持實況頂層流傳輸?shù)狞c。實況活動現(xiàn)在可以從由實況編碼服務器生成的自適應位速率流來查看。實況編碼服務器常常利用mpeg-dash格式(即，經(jīng)http的動態(tài)自適應流傳輸)。mpeg-dash(iso/iec23009-1)是用于經(jīng)互聯(lián)網(wǎng)流傳輸多媒體內(nèi)容的標準。mpeg-dash由運動圖像專家組(mpeg)開發(fā)。mpeg已經(jīng)負責開發(fā)以前的多媒體標準，包括mpeg-2、mpeg-4、mpeg-7、mpeg-21等。mpeg-dash是一種自適應的位速率流傳輸技術，其啟用經(jīng)互聯(lián)網(wǎng)從常規(guī)httpweb服務器輸送媒體內(nèi)容的高質(zhì)量流傳輸。通常，mpeg-dash使用各自包含經(jīng)由超文本傳輸協(xié)議(http)檢索的視頻片段的小文件序列，每個片段包含呈現(xiàn)的重放時間的短間隔。呈現(xiàn)可以是實況活動和/或具有指定的持續(xù)時間?？梢砸愿鞣N不同的位速率(諸如300kb/s、500kb/s和3mb/s)使自適應位速率流可用。將源流實況編碼和/或轉碼成多個自適應位速率流可以要求大量的計算資源，并且實況編碼硬件相當昂貴。

附圖說明

圖1是圖示根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)的網(wǎng)絡圖。

圖2是圖示根據(jù)本發(fā)明的實施例的、由實況編碼系統(tǒng)執(zhí)行的高級處理的流程圖。

圖3概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償丟失的輸入幀的實況編碼系統(tǒng)的示例。

圖4概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償丟失的輸入幀的實況編碼系統(tǒng)的備選示例。

圖5概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償延遲的輸入幀的實況編碼系統(tǒng)的示例。

圖6概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償延遲的輸入幀的實況編碼系統(tǒng)的備選示例。

圖7概念性地圖示了根據(jù)本發(fā)明的實施例的、復制幀以補償系統(tǒng)負載的實況編碼系統(tǒng)的示例。

圖8是用于根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)和流傳輸?shù)臄?shù)據(jù)流圖。

圖9是可以由本發(fā)明的實施例利用的用于mpeg-dash的媒體呈現(xiàn)描述(mpd)數(shù)據(jù)模型的示例。

圖10概念性地圖示了根據(jù)本發(fā)明的實施例的實況編碼服務器的體系架構。

具體實施方式

現(xiàn)在轉向附圖，圖示了根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)。在若干實施例中，實況編碼系統(tǒng)接收實況媒體饋送，諸如(但不限于)體育賽事、實況新聞報道、網(wǎng)絡直播流和/或單個或多路復用的媒體流。媒體流包含在由提供商輸送的同時不斷地由客戶端接收并呈現(xiàn)給客戶端的多媒體。流傳輸(streaming)是指經(jīng)由流輸送媒體的過程。實況編碼系統(tǒng)可以向客戶端提供從實況輸入流編碼的媒體流。而且，實況編碼系統(tǒng)可以將接收到的實況媒體饋送編碼成具有不同最大位速率的若干不同的自適應位速率流。實況編碼系統(tǒng)還可以經(jīng)由包括(但不限于)http請求的協(xié)議將實況媒體呈現(xiàn)中的編碼的自適應位速率流發(fā)送到流傳輸客戶端，和/或?qū)⒕幋a的自適應位速率流提供給服務器用以分發(fā)到客戶端設備。實況媒體呈現(xiàn)的編碼和傳輸對執(zhí)行這些操作所使用的硬件來說可能是繁重的。本發(fā)明的實施例提供了幾種減少執(zhí)行實況編碼和傳輸操作的硬件上的負載的技術。例如，根據(jù)本發(fā)明的許多實施例的實況編碼系統(tǒng)可以根據(jù)若干測量來評估網(wǎng)絡和/或服務器負載水平。負載常常作為實況編碼系統(tǒng)正在執(zhí)行的工作(例如，計算、編碼操作、存儲器操作等)的量來測量?；谠u估，實況編碼系統(tǒng)可以調(diào)整來自實況媒體饋送的視頻幀如何被編碼。例如，實況編碼系統(tǒng)的一些實施例復制當前編碼幀，而不是對所述當前幀進行重新編碼，然后根據(jù)需要針對若干不同的自適應位速率流將復制的幀調(diào)整到不同的位速率、分辨率和/或上下文。此外，實況編碼系統(tǒng)的各種實施例可以擴展正被重新包裝和/或重新編碼的當前幀的持續(xù)時間。利用這些和其它技術，根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)可以更高效地處理接收數(shù)據(jù)中的間隙、數(shù)據(jù)的較慢饋送和/或服務器硬件上的重負載。

網(wǎng)絡傳輸水平可以影響實況編碼過程。例如，當實況媒體饋送在從實況輸入流到實況編碼系統(tǒng)的各網(wǎng)絡傳輸層中遭受中斷時，實況編碼系統(tǒng)會在傳入的數(shù)據(jù)中遇到間隙。傳入的數(shù)據(jù)中的間隙會在輸出數(shù)據(jù)中產(chǎn)生間隙和/或?qū)е聦崨r編碼系統(tǒng)不能在被請求時輸送輸出幀。根據(jù)本發(fā)明的一些實施例的實況編碼系統(tǒng)可以評估傳入的媒體饋送，以確定間隙是何時發(fā)生的。這些評估可以基于若干測量，包括(但不限于)傳入的幀速率、傳入的位速率、到達幀之間的時間和/或網(wǎng)絡帶寬測量。根據(jù)本發(fā)明的許多實施例的實況編碼系統(tǒng)可以通過在將傳入的媒體流重新包裝成若干自適應位速率流期間復制幀和/或擴展幀來補償數(shù)據(jù)中檢測到的間隙。通過復制幀和/或擴展幀，實況編碼系統(tǒng)可以允許網(wǎng)絡條件有穩(wěn)定的機會，而不會危及在被請求時客戶端所依賴的幀的可用性。具體而言，實況編碼系統(tǒng)可以落后于實況流傳輸媒體的實況邊緣?？蛻舳送ǔ奈挥诔尸F(xiàn)的實況邊緣的實況流中請求幀。當在本文中被使用時，術語“實況邊緣”是指在沒有請求還不可用的片段的風險的情況下客戶端可以請求的實況流的最近編碼的片段。請求還不可用的片段導致許多流傳輸錯誤，諸如(但不限于)延遲、http未找到錯誤，并且會導致帶寬阻塞重復請求。

服務器負載水平也會影響實況編碼過程。在實況編碼系統(tǒng)被實現(xiàn)為實況編碼服務器的時候，服務器硬件會被編碼過程壓倒。在實況編碼服務器落后于實況邊緣的時候，若干自適應位速率流會由于客戶端依賴在實況邊緣進行的請求而失敗。具體而言，實況流傳輸客戶端可以基于實況編碼系統(tǒng)不比實時更慢地生成片段的假設來請求視頻的片段。根據(jù)本發(fā)明的許多實施例的實況編碼系統(tǒng)可以通過擴展當前幀并調(diào)整輸出幀的時間戳來補償服務器負載。擴展的幀可以產(chǎn)生微小的和/或難以察覺的視覺錯誤，但將保留請求并接收客戶端為了實況流傳輸而依賴的http循環(huán)。而且，根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)還可以通過復制當前幀并調(diào)整輸出流所需的其幀上下文來補償服務器負載。

已經(jīng)討論了根據(jù)本發(fā)明的許多實施例的實況編碼系統(tǒng)的操作和功能的簡要概述，下面給出根據(jù)本發(fā)明的實施例的、用于實況編碼系統(tǒng)的系統(tǒng)、服務器和方法的更詳細討論。

用于實況編碼系統(tǒng)的網(wǎng)絡體系架構

圖1中圖示了根據(jù)本發(fā)明的實施例的、用于實況編碼系統(tǒng)的網(wǎng)絡體系架構。系統(tǒng)100包括實況編碼服務器和支持硬件102，其包括支持實況編碼所需的應用服務器、數(shù)據(jù)庫服務器和/或數(shù)據(jù)庫。實況編碼服務器和支持硬件102可以從內(nèi)容源114接收實況媒體內(nèi)容和/或非實況內(nèi)容。內(nèi)容源114可以包括用來向?qū)崨r編碼服務器和支持硬件102提供媒體的硬件。從內(nèi)容源114接收的媒體可以包括(但不限于)web流、實況媒體廣播、電視廣播、實況活動覆蓋、來自實況相機的視頻饋送、先前存儲的媒體、原始媒體饋送、編碼的媒體饋送和/或從本地和/或遠程存儲裝置接收的靜態(tài)文件。

實況編碼服務器和支持硬件102可以經(jīng)網(wǎng)絡104與若干組設備進行通信，以便提供內(nèi)容的流。設備組包括(但不限于)web、文件和/或媒體服務器106、計算設備108和/或移動設備112。來自這些設備組的設備的用戶可以利用本地流傳輸客戶端查看所提供的流傳輸內(nèi)容。此外，來自web、文件和/或媒體服務器106的web服務器還可以對于所提供的流傳輸內(nèi)容的附加下游查看者和/或客戶端充當主機。

如圖1中所示，實況編碼服務器和支持硬件102包括應用服務器、數(shù)據(jù)庫服務器和數(shù)據(jù)庫。在各種實施例中，實況編碼服務器和支持硬件102可以包括不同數(shù)量和類型的設備。例如，實況編碼服務器和支持硬件102可以被實現(xiàn)為單個計算設備，其中這單個計算設備具有足夠的存儲、聯(lián)網(wǎng)和/或計算能力。但是，實況編碼服務器和支持硬件102還可以使用各種類型和多個位置的多個計算設備來實現(xiàn)。例如，實況編碼服務器和支持硬件102可以被實現(xiàn)為用于編碼實況媒體的實況編碼服務器和用于響應針對由實況編碼服務器編碼的片段的http請求的http服務器。雖然實況編碼服務器和支持硬件102被示為包括應用服務器、數(shù)據(jù)庫服務器和數(shù)據(jù)庫，但是本領域技術人員將認識到的是，本發(fā)明不限于圖1中所示的設備并且可以包括附加類型的計算設備(例如，web服務器和/或云存儲系統(tǒng))。

在圖1所示的實施例中，網(wǎng)絡104是互聯(lián)網(wǎng)。實況編碼服務器和支持硬件102可以通過網(wǎng)絡104并經(jīng)無線連接110來從移動設備112接收請求并向移動設備112發(fā)送媒體片段。無線連接110可以是(但不限于)4g連接、蜂窩網(wǎng)絡、wi-fi網(wǎng)絡和/或適于具體應用的要求的任何其它無線數(shù)據(jù)通信鏈路。實況編碼服務器和支持硬件102可以通過網(wǎng)絡104直接與計算設備108和web、文件和/或媒體服務器106通信。其它實施例可以使用其它網(wǎng)絡(諸如以太網(wǎng)或虛擬網(wǎng)絡)在設備之間進行通信。本領域技術人員將認識到的是，本發(fā)明不限于圖1所示的網(wǎng)絡類型并且可以包括附加類型的網(wǎng)絡(例如，內(nèi)聯(lián)網(wǎng)、虛擬網(wǎng)絡、移動網(wǎng)絡和/或適于具體應用的要求的其它網(wǎng)絡)。

雖然在圖1中示出了具體的體系結構，但是可以使用涉及電子設備和網(wǎng)絡通信的不同體系架構來實現(xiàn)實況編碼系統(tǒng)以執(zhí)行操作并提供根據(jù)本發(fā)明的實施例的功能。

用于實況編碼服務器的系統(tǒng)和過程

在實況編碼系統(tǒng)中，客戶端常常依賴能夠請求和接收位于實況編碼邊緣的幀。編碼和/或傳輸?shù)娜魏沃袛喽紩е驴蛻舳藷o法接收所需的幀、失敗的http請求、圖像斷斷續(xù)續(xù)以及觀眾所感受的普遍沮喪。根據(jù)本發(fā)明的許多實施例的實況編碼系統(tǒng)可以使用傳入媒體和/或編碼系統(tǒng)負載的實時分析來通過下面討論的技術減輕實況編碼中的損失和中斷。

圖2概念性地圖示了根據(jù)本發(fā)明的實施例的、可以由實況編碼系統(tǒng)在接收媒體、生成流以及將生成的流提供給實況流傳輸客戶端時執(zhí)行的過程200。在多個實施例中，過程200由根據(jù)上面結合圖1描述的實施例的實況編碼服務器執(zhí)行。特別地，過程200可以由mpeg-dash實況編碼服務器在媒體的連續(xù)實況編碼和實況流傳輸期間執(zhí)行。

媒體可以被接收(210)。如上面所提到的，媒體可以涵蓋許多不同類型、格式、標準和/或呈現(xiàn)。所接收的媒體常常是已編碼媒體的實況饋送。所接收的媒體可以包括(但不限于)從本地和/或遠程存儲裝置接收的輸入流、實況媒體饋送、電視饋送、衛(wèi)星饋送、web流和/或靜態(tài)文件。

流可以從接收到的媒體生成(220)。所生成的流可以是許多可能的格式，諸如(但不限于)mpeg-dash、h.264/avc、http實況流傳輸、平滑流傳輸和/或任何其它自適應位速率格式。然后所生成的流可以經(jīng)網(wǎng)絡連接被提供給流傳輸客戶端。通常，所生成的流將具有不同的最大位速率并且根據(jù)變化的編碼參數(shù)進行編碼。在一些實施例中，流是利用實況編碼服務器的重新包裝應用來生成的。重新包裝應用將接收到的媒體重新包裝成輸出流。由此，重新包裝應用可以根據(jù)需要利用各種編碼器和解碼器來根據(jù)需要生成流。

流的生成可以是在接收實況媒體時執(zhí)行的持續(xù)過程。在流響應于接收實況媒體而持續(xù)生成期間，可以評估實況編碼系統(tǒng)上的負載水平、通信網(wǎng)絡中的負載水平、媒體接收中的間隙和/或流生成中的間隙(230)。而且，不同的實施例可以評估實況編碼服務器操作的其它方面。執(zhí)行所述評估可以包括若干子操作。例如，實況編碼系統(tǒng)可以檢查接收到的媒體的傳入數(shù)據(jù)速率和/或幀速率?？梢詫⒔邮盏降拿襟w的傳入數(shù)據(jù)速率和/或幀速率與根據(jù)實況編碼系統(tǒng)的內(nèi)部邏輯確定的幀時間進行比較。內(nèi)部邏輯可以包括確定可靠時間的若干來源，諸如(但不限于)所接收的媒體的時間戳、實況編碼系統(tǒng)上的時鐘實現(xiàn)和/或接收到的媒體的所聲明的幀速率。在一些實施例中，實況編碼系統(tǒng)可以測量傳入的幀之間的時間差，以便計算總體傳入數(shù)據(jù)速率。然后，實況編碼系統(tǒng)可以監(jiān)視計算出的總體傳入數(shù)據(jù)速率，以識別傳入的數(shù)據(jù)中的間隙或可能壓倒實況編碼系統(tǒng)的處理能力的潛在浪涌。這些評估中的一個或多個可以指示實況編碼系統(tǒng)沒有在適當?shù)臅r間接收到幀和/或?qū)o法及時編碼幀以滿足對于實況編碼系統(tǒng)的實況邊緣要求。

為了減輕不能及時為實況邊緣生成幀的風險，接收到的媒體的幀可以可選地被重復和/或復制(240)。在一些實施例中，可以修改重復的幀，以考慮與各種生成的流相關聯(lián)的新的幀上下文。不同的幀上下文可以包括(但不限于)不同的分辨率、不同的幀類型(諸如i幀、b幀和/或p幀)、不同的最大位速率。從接收到的媒體生成流常常涉及將接收到的媒體重新編碼為不同的格式，其中接收到的媒體包括編碼的幀。接收到的媒體的重新編碼可以在由實況編碼系統(tǒng)執(zhí)行的更多資源密集型操作當中。然后重復的幀可以在生成的流中使用，而不需要相對昂貴的重新編碼操作。而且，除了來自接收到的媒體的編碼幀之外，重復的幀還可以從來自接收到的媒體的原始幀復制。

但是，復制編碼幀而不是重新編碼幀(其作為實況編碼過程的一部分)會導致輸出流違反h.264/avc中的假定參考解碼器(hrd)的某些要求。根據(jù)定義，當其輸入是兼容流時，hrd不應當上溢或下溢。復制大的編碼幀并在低最大位速率流中利用復制的流存在造成緩沖區(qū)上溢的風險，這將導致hrd要求失敗。但是，由于其更靈活的緩沖區(qū)，軟件解碼器客戶端可以補償這一點，而不會出現(xiàn)問題。軟件解碼器客戶端可能需要附加的cpu周期來處理復制的幀。當復制的幀用于較低最大位速率流中時，硬件解碼器客戶端將由于可能的緩沖區(qū)上溢而遇到錯誤。本發(fā)明的一些實施例提供了減少復制幀用于較低最大位速率輸出流的位值，以便減輕硬件解碼器中緩沖區(qū)上溢的風險。在還有其它實施例中，重復的幀僅用于其自己具體的最大位速率輸出流；由此防止高位值幀被用于低最大位速率流。這可以通過為每個輸出流包括單獨的編碼過程來實現(xiàn)。

而且，在一些實施例中，幀可以從輸入流復制和/或重復，其中輸入流和輸出流共享相同的格式、最大位速率和/或分辨率。這會發(fā)生在期望的輸出流與輸入流相同的地方。在這種情況下，可以跳過重新編碼，并且若干實施例可以簡單地復制來自輸入流的瞬時解碼刷新(idr)幀。如上面所討論的，在所述若干實施例中，結果所得的輸出流可以是非hrd兼容的。

在用于減輕不能及時為實況邊緣生成幀的風險的另一種技術中，接收到的媒體的幀可以可選地被擴展(250)。擴展幀可以包括在與給定幀的指派時間戳不同的時間將該給定幀包裝到輸出流中。依賴于以前的評估，會發(fā)生不同的幀擴展。在媒體的饋送和/或接收中檢測到間隙的情況下，可以在生成輸出流時擴展當前幀。在利用作為實況編碼服務器的一部分的重新包裝應用的實施例中，重新包裝應用可以在將幀重新包裝到輸出流期間執(zhí)行擴展。為了減少視頻中的視覺偽影和/或感知停頓，重新包裝應用可以在多個幀上散布若干較小的幀擴展，以便在多個步驟中補償間隙。較小的擴展可以用來隱藏擴展不讓流傳輸客戶端觀眾看到。

所生成的輸出流可以被提供(260)給流傳輸客戶端。所生成的輸出流可以處于不同的最大位速率，但每個位速率表示單個媒體呈現(xiàn)。因此，可以在具有不同最大位速率的若干流中向流傳輸客戶端提供給定的媒體呈現(xiàn)。所生成的輸出流的提供可以經(jīng)由對來自所生成的輸出流的片段的http請求來實現(xiàn)。

雖然以線性次序給出了過程200中給出的操作，但是各種實施例可以以不同的次序執(zhí)行所述操作。例如，當接收到實況媒體時，可以持續(xù)地執(zhí)行流的生成及其向客戶端的提供。因此，在過程200中給出的操作的次序僅僅是示范性的并且可以作為用于從接收到的媒體的幀實況生成流的循環(huán)過程的一部分而被持續(xù)地執(zhí)行。在討論了由一些實施例的實況編碼系統(tǒng)執(zhí)行的過程的概述之后，下面的討論將提供可以作為所述過程的一部分被執(zhí)行的幀擴展和幀復制的若干示例。

幀擴展和幀復制的示例

如上面所討論的，根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)可以響應于被評估的網(wǎng)絡和/或服務器條件來擴展幀和/或復制幀。幀擴展和/或幀復制可以補償丟棄的輸入幀、延遲的輸入幀和/或編碼系統(tǒng)負載。圖3、圖4、圖5、圖6和圖7概念性地圖示了根據(jù)本發(fā)明的實施例的幀擴展和幀復制的若干示例。上面提到的圖中給出的示例是實況編碼過程的抽象，實況編碼過程被圖示以示出幀復制和/或幀擴展的效果。根據(jù)本發(fā)明的實施例的實況編碼系統(tǒng)將包括未在圖3、圖4、圖5、圖6和圖7的示例中示出的附加細節(jié)、部件和/或功能。用于時間戳、幀號和/或幀持續(xù)時間的具體數(shù)字是為了示范目的給出的。本發(fā)明的實施例不限于圖3、圖4、圖5、圖6和圖7中給出的具體值，并且可以根據(jù)實況編碼操作的需要結合寬范圍的可能時間戳、幀號和/或幀持續(xù)時間。而且，雖然在下面的附圖中僅示出了單個輸出流，但是本發(fā)明的實施例通常利用變化的編碼參數(shù)生成處于變化的最大位速率的多個輸出流。

圖3概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償丟失的輸入幀的實況編碼系統(tǒng)的示例。如圖所示，實況編碼系統(tǒng)300在接收輸入流310并生成輸出流360。在圖3所示的示例中，實況編碼系統(tǒng)300的實況編碼處理在輸入流310的持續(xù)接收和輸出流360的生成期間執(zhí)行。輸入流310可以是上面討論的輸入流和/或媒體中的任何一個。實況編碼系統(tǒng)360可以經(jīng)由上面討論的任何技術將生成的輸出流360提供給流傳輸客戶端(未示出)。技術諸如接收http請求并發(fā)送來自輸出流的片段。

如圖所示，輸入流310包括具有識別出的時間戳和持續(xù)時間的若干幀。幀可以包括媒體的部分，諸如幀視頻。時間戳由縮寫“ts”指示。持續(xù)時間由縮寫“d”指示。如前面所提到的，圖3中所示的值是示范性的。本發(fā)明的實施例可以根據(jù)需要接收并處理各種不同的時間戳和持續(xù)時間值，以支持實況編碼。幀5320具有等于5的時間戳值和等于1的持續(xù)時間值。

實況編碼系統(tǒng)300期望在指定的時間從輸入流310接收幀。當在指定的時間沒有接收到幀時，實況編碼系統(tǒng)300可能無法及時地生成實況流傳輸客戶端預期的用于實況邊緣的輸出流360。實況編碼系統(tǒng)300可以使用如上面所討論的各種測量來評估幀是否從輸入流310丟失。諸如將由實況編碼系統(tǒng)300維護的內(nèi)部時鐘與實況輸入流310的接收到的幀的時間戳進行比較。實況編碼系統(tǒng)310還可以包括在擴展幀之前必須滿足的、用于丟失幀的閾值。實況編碼系統(tǒng)310包括在選擇擴展幀以補償至少兩個幀的間隙之前兩個丟失幀的閾值。不同的實施例可以包括不同閾值，不同閾值可以基于不同的幀數(shù)和/或不同的閾值測量，諸如在一段時間上丟失的幀而不是依次丟失的幀。視頻的實況編碼固有地是資源密集型過程，因此各種實施例可以結合評估編碼條件(諸如編碼系統(tǒng)負載、客戶端斷斷續(xù)續(xù)、網(wǎng)絡帶寬穩(wěn)定性、視頻質(zhì)量以及會影響視頻的實況編碼的其它度量和/或條件)利用各種閾值。如上面所討論的，在本發(fā)明的不同實施例中，可以計算幀的具體計數(shù)及其輸送并將其與幀計數(shù)和時間的不同閾值進行比較。此外，不同的實施例可以使用不同的度量來評估這種流傳輸條件、處理周期計數(shù)、用于對幀集合進行編碼的時間基準、網(wǎng)絡傳輸速率、輸送和顯示的幀速率以及視覺質(zhì)量/保真度的各種測量。雖然本文沒有提供具體的值，但是在不背離本發(fā)明的精神的情況下，可以根據(jù)需要利用不同的具體值(諸如低于24幀/秒的dip、超過某些伽馬值的造成顯示失敗的視覺錯誤、每秒編碼的幀等)，以實現(xiàn)本發(fā)明。

在各種不同情況下輸入幀可能丟失，諸如(但不限于)當在輸入流提供者與實況編碼系統(tǒng)之間的網(wǎng)絡連接出現(xiàn)故障時、當在輸入流中存在錯誤時，和/或?qū)崨r編碼系統(tǒng)的內(nèi)部錯誤。如圖所示，輸入流310丟失了幀330和幀340。實況編碼系統(tǒng)300可以通過將幀8350的時間戳與幀5320的時間戳以及由實況編碼系統(tǒng)300維持的內(nèi)部時鐘相比較來檢測這個間隙。一旦滿足丟失幀閾值，實況編碼系統(tǒng)300就可以擴展幀，以補償幀中的間隙。各種實施例可以使用不同的閾值方案，包括上面討論的那些中的任一個。

如圖所示，實況編碼系統(tǒng)300在生成輸出流360時擴展來自輸入流310的幀5320。擴展幀370被擴展為具有等于3的持續(xù)時間值，以便覆蓋丟失的幀330和340。擴展幀370將在實況流傳輸客戶端請求時可用，并保留支持不間斷實況流傳輸所需的實況邊緣。但是，如果過度使用，那么擴展幀持續(xù)時間會導致視覺偽影。

圖4概念性地圖示了有助于隱藏幀擴展效果的擴展幀持續(xù)時間的備選方法。如圖所示，實況編碼系統(tǒng)400從輸入流410生成輸出流460。輸入流410丟失了幀430和440。為了補償這個間隙，實況編碼系統(tǒng)400可以擴展幀5420和幀8450的持續(xù)時間，并且還調(diào)整幀8450的時間戳值。如輸出流460所示，擴展幀5470已經(jīng)被擴展為具有持續(xù)時間值2，并且擴展幀8480已經(jīng)被擴展為具有持續(xù)時間值2。但是，用于擴展幀8470的時間戳已經(jīng)被調(diào)整為7，使得擴展幀8480將在擴展幀5470之后立即可用。通過在丟失幀周圍分布擴展，實況編碼系統(tǒng)400可以隱藏由幀持續(xù)時間擴展所造成的視覺偽影中的一些。

圖5概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償延遲的輸入幀的實況編碼系統(tǒng)的示例。如圖所示，實況編碼系統(tǒng)500從輸入流510生成輸出流560。但是，幀延遲530和540導致幀6550遲到。實況編碼系統(tǒng)500可以檢測幀延遲并使用幀持續(xù)時間擴展進行補償。與以前的示例不同，將不會有丟失的幀。實況編碼系統(tǒng)500生成輸出流560，輸出流560包括具有擴展到3的持續(xù)時間的擴展幀5和具有調(diào)整為8的時間戳值的幀6580。擴展幀570將在由實況流傳輸客戶端請求時可用并保留支持不間斷的實況流傳輸所需的實況邊緣。與上面討論的示例類似，如果過度使用，那么擴展幀持續(xù)時間會導致視覺偽影。

圖6概念性地圖示了擴展幀持續(xù)時間以補償幀延遲的備選方法，這有助于隱藏幀擴展的效果。如圖所示，實況編碼系統(tǒng)600從輸入流610生成輸出流660。如上所述，在630和640處發(fā)生幀延遲。為了補償這個延遲，實況編碼系統(tǒng)600可以擴展幀5620和幀6650的持續(xù)時間，并且還調(diào)整幀6650的時間戳值。如輸出流660中所示，擴展幀8670已經(jīng)被擴展為具有持續(xù)時間值2，并且擴展幀8已經(jīng)被擴展為具有持續(xù)時間值2。但是，用于擴展幀8670的時間戳已被調(diào)整為7，使得擴展幀8670將在擴展幀5670之后立即可用。通過在延遲的幀周圍分布擴展，實況編碼系統(tǒng)400可以隱藏由幀持續(xù)時間擴展造成的視覺偽影中的一些。

本發(fā)明的實施例不限于上面關于圖3、圖4、圖5和圖6討論的幀擴展技術。各種實施例可以在不同的情況下利用如圖3和圖5中所示的幀持續(xù)時間的順序擴展和/或如圖4和圖5中所示的幀持續(xù)時間的分散擴展。此外，擴展幀持續(xù)時間不限于由于丟失和/或延遲的幀而被執(zhí)行。

實況編碼服務器通常是非常強大和昂貴的機器，其需要顯著的計算能力來編碼滿足實況邊緣要求的實況流。但是，即使是強大的服務器也會變得過載，而不太強大的服務器更是如此。特別地，重新編碼編碼幀可能是對服務器資源的嚴重消耗。圖7概念性地圖示了根據(jù)本發(fā)明的實施例的、擴展幀以補償服務器負載的實況編碼系統(tǒng)的示例。如圖所示，實況編碼系統(tǒng)700接收輸入流710并生成輸出流760。在圖7所示的示例中，實況編碼系統(tǒng)700的實況編碼過程在輸入流710的持續(xù)接收和輸出流760的生成期間被執(zhí)行。實況編碼系統(tǒng)700被示為處于負載740之下。為了補償這個負載，實況編碼系統(tǒng)700可以在編碼域中從編碼的輸入流復制幀。

如圖所示，實況編碼系統(tǒng)700接收編碼幀4720和編碼幀5730。實況編碼系統(tǒng)700在生成編碼的輸出流750時復制這些幀。用于復制幀4760和復制幀5770的幀字段可能必須被調(diào)整以便考慮新的幀上下文。但是，與重新編碼操作相比，這些調(diào)整可以要求顯著更少的處理資源。復制幀4760和復制幀5770具有與編碼幀4720和編碼幀5730相同的持續(xù)時間值和時間戳值。

本發(fā)明的實施例不限于上面在圖7中概念性示出的示例中討論的具體幀復制技術。各種實施例可以利用具有各種格式的輸入流(諸如原始、未編碼的輸入流)進行的幀復制和/或重復。而且，本發(fā)明的實施例不限于僅在服務器負載時間期間執(zhí)行幀復制和/或幀重復。例如，作為持續(xù)編碼過程的一部分，本發(fā)明的一些實施例可以執(zhí)行編碼的幀復制，以維持高效的實況編碼，而不必等到服務器負載達到臨界水平。所述一些實施例可以在不太強大的實況編碼服務器上使用。

mpeg-dash實況編碼

mpeg-dash(iso/iec23009-1)是用于經(jīng)互聯(lián)網(wǎng)流傳輸多媒體內(nèi)容的標準。mpeg-dash由運動圖像專家組(mpeg)開發(fā)。mpeg已經(jīng)負責開發(fā)以前的多媒體標準，包括mpeg-2、mpeg-4、mpeg-7、mpeg-21等。mpeg-dash提供使用http的自適應分段媒體輸送。mpeg-dash規(guī)范僅定義mpd和片段格式。值得注意的是，在mpeg-dash標準中未定義mpd的輸送和包含片段的媒體編碼格式，以及用于獲取、自適應啟發(fā)和播放內(nèi)容的客戶端行為。

圖8概念性地圖示了根據(jù)本發(fā)明實施例的、用于利用mpeg-dash的實況編碼系統(tǒng)的示例性數(shù)據(jù)流圖。圖8包括媒體饋送數(shù)據(jù)810、實況編碼系統(tǒng)820、http請求830、所請求的流片段840、流傳輸客戶端850以及媒體呈現(xiàn)描述860。雖然未示出，但是媒體饋送數(shù)據(jù)810、http請求830、所請求的流片段840和媒體呈現(xiàn)描述860可以經(jīng)通信網(wǎng)絡發(fā)送。通信網(wǎng)絡可以包括(但不限于)互聯(lián)網(wǎng)。

如圖所示，實況編碼系統(tǒng)820正在接收媒體饋送數(shù)據(jù)810。媒體饋送數(shù)據(jù)810可以包括至少上面討論的接收到的媒體的類型。實況編碼系統(tǒng)820可以從接收到的媒體饋送數(shù)據(jù)810生成輸出流。在從接收到的媒體饋送數(shù)據(jù)810生成輸出流期間，基于對媒體饋送數(shù)據(jù)810的接收速率的評估、實況編碼系統(tǒng)820上的負載水平、支持媒體饋送數(shù)據(jù)810的傳輸?shù)耐ㄐ啪W(wǎng)絡中的負載水平、媒體饋送數(shù)據(jù)810中的間隙，和/或由實況編碼系統(tǒng)820生成流時的間隙，實況編碼系統(tǒng)820可以復制來自媒體饋送數(shù)據(jù)810的幀和/或擴展來自媒體饋送數(shù)據(jù)810的幀。

實況編碼系統(tǒng)820還接收http請求830。響應于http請求，實況編碼系統(tǒng)820提供所請求的流片段840。http請求830可以包括來自所生成的輸出流之一的具體分段的字節(jié)范圍請求。實況編碼系統(tǒng)820可以包括多個部件，包括單獨的實況編碼服務器和http服務器。http服務器可以支持與客戶端的媒體片段和請求的http通信。而且，http服務器可以利用基于http的內(nèi)容分發(fā)網(wǎng)絡(cdn)來輔助媒體片段向流傳輸客戶端850的輸送。

mpeg-dash使用媒體呈現(xiàn)描述(mpd)來向客戶端提供結構良好的xml清單，該清單描述可以經(jīng)由對流片段的http請求來訪問的若干自適應位速率流。每個mpd與可經(jīng)由若干所描述自適應位速率流來查看的單個媒體呈現(xiàn)對應。mpd描述可訪問的媒體片段和用于可訪問的媒體片段的對應定時。mpd是分層數(shù)據(jù)模型，其包括(從層次結構的頂部向下)媒體呈現(xiàn)、時段、適配集、表示和片段。媒體呈現(xiàn)可以包括實況廣播、實況流、實況活動和/或預先錄制的媒體呈現(xiàn)。媒體呈現(xiàn)可以被拼接和/或可以包括若干時段。默認情況下，時段是不連接的并且可以在它們之間拼接廣告時段，而不損失功能。時段可以包括若干適配集。適配集可以包括關于同一呈現(xiàn)的不同視角，諸如來自實況體育賽事的不同相機。此外，不同的適配集可以包括不同的格式，諸如音頻適配集和視頻適配集。在每個適配集內(nèi)，可以包括若干表示。表示支持從相同的呈現(xiàn)中選擇不同的帶寬和/或最大位速率水平。因此，mpeg-dash的客戶端可以通過在帶寬和/或客戶端負載允許的情況下切換到不同的表示來使用自適應位速率流傳輸。每個表示包括可以經(jīng)由http請求的媒體的片段。http請求在與每個片段相關聯(lián)的預格式化的url上被接收。

圖9概念性地圖示了來自mpeg-dash的示例媒體呈現(xiàn)描述mpd數(shù)據(jù)模型。如圖所示，媒體呈現(xiàn)910包括若干時段915-925。時段915-925各自包括不同的時段開始時間。開始時間為100秒的時段920被擴張，以示出若干包括的適配集925-930。適配集1925包括來自媒體呈現(xiàn)910的相機1的視頻。適配集2930包括用于媒體呈現(xiàn)910的音頻。適配集3935包括來自媒體呈現(xiàn)910的相機2的視頻。適配集1925已被擴張，以示出表示1940和表示2945。表示1940是用于適配集1925的500kb/s表示，而表示2945是用于適配集1925的250kb/s表示。在表示1940當中的是初始化片段100和媒體片段955-965。這些片段由流傳輸客戶端經(jīng)由http請求，以接收其中包含的媒體。

值得注意的是，圖9中所示的橢圓的實例指示可能有附加的時段、適配集、呈現(xiàn)以及片段。圖9中給出的示例mpd僅僅是來自由本發(fā)明的各種實施例支持的任何種類的配置的一個可能示例。例如，本發(fā)明的不同實施例可以支持與圖9所示的實施例中為了示范性目的而提供的那些位速率不同的許多其它最大位速率。

實況編碼服務器體系架構

根據(jù)本發(fā)明的實施例的實況編碼服務器1000的體系架構在圖10中示出。實況編碼服務器1000包括與非易失性存儲器1030、易失性存儲器1020和網(wǎng)絡接口1040通信的處理器10。在所示實施例中，非易失性存儲器包括輸入數(shù)據(jù)處理應用1050、解復用器應用1055、重新包裝器應用1060、mpd組合應用1065、mpd生成應用1070、http請求應用1075、音頻解碼器應用1080、音頻編碼器應用1085、視頻解碼器應用1090以及視頻編碼器應用1095。值得注意的是，實況編碼服務器1000是mpeg-dash格式的實況編碼服務器，其準備用于流的mpd文件并通過http請求向流傳輸客戶端提供輸出流的片段。其它實施例可以利用不同的格式并且根據(jù)需要包括不同的應用，以支持所述不同格式。

輸入數(shù)據(jù)處理應用1050從網(wǎng)絡接口1040接收輸入流。輸入流可以包括(但不限于)視頻內(nèi)容、媒體呈現(xiàn)、僅視頻的文件、僅音頻的文件、體育賽事、web流和/或mpeg-dash標準流的實況流。輸入數(shù)據(jù)處理應用1050可以執(zhí)行附加功能，包括輸入流的識別?？梢允褂幂斎肓髦邪脑獢?shù)據(jù)和/或輸入流的特點和參數(shù)的評估來執(zhí)行識別。

解復用器應用1055從輸入流中解復用各個基本流。例如，解復用器應用1055可以打斷輸入流內(nèi)的音頻、視頻和/或字幕流。解復用的流可以在由其它應用執(zhí)行的后續(xù)操作中被分析、解碼和重新編碼。

重新包裝器應用1060可以作為整體實況編碼服務器操作的一部分執(zhí)行重新編碼、重復和幀擴展操作。重新包裝器應用1060可以根據(jù)需要從輸入數(shù)據(jù)處理應用1050、解復用器應用1055、網(wǎng)絡接口1040和/或?qū)崨r編碼服務器1000的任何其它部件接收輸入流，以重新包裝流。重新包裝器應用1060可以根據(jù)需要利用視頻解碼器應用1090和視頻編碼器應用1095將接收到的媒體的傳入實況幀重新編碼為若干輸出流。在重新編碼操作期間，重新包裝器應用1060可以根據(jù)若干測量來評估實況編碼服務器1000的網(wǎng)絡和/或服務器負載水平?；谶@些評估，重新包裝器應用1060可以重復傳入的幀，以降低服務器負載水平和/或擴展某些幀，以補償傳入的網(wǎng)絡帶寬中的預期下降。重新包裝器應用1060可以通過操縱幀的時間代碼和/或時間戳來擴展幀，以增加其在輸出流中的持續(xù)時間。重新包裝器應用1060可以向mpd組合應用1065和/或mpd生成應用1070提供輸出流的重新包裝的、重新編碼的、重復的和/或擴展的幀，以便準備好隨后利用http請求應用1075向客戶端流傳輸。

mpd組合應用1065將由重新包裝器應用1060生成的多個輸出流組合成單個呈現(xiàn)。mpd組合應用1070可以生成用于組合呈現(xiàn)的mpd文件。如上面所討論的，mpd文件可以描述媒體呈現(xiàn)的時段、適配集、表示和片段。mpd組合應用1070根據(jù)所生成的輸出流的特點生成mpd文件。這些特點將根據(jù)由重新包裝器應用1060執(zhí)行的操作而變化。mpd文件通常最初被請求并且提供給流傳輸客戶端，以便發(fā)起mpeg-dash流傳輸會話。

http請求應用1075根據(jù)所述http請求處理http請求和服務器媒體片段。http請求應用1075可以通過網(wǎng)絡接口1040與流傳輸客戶端進行通信。在一些實施例中，http請求應用1075被托管在與實況編碼服務器分開的http服務器中。

非易失性存儲器包括音頻解碼器應用1080、音頻編碼器應用1085、視頻解碼器應用1090和視頻編碼器應用1095。雖然非易失性存儲器1030僅包括單個視頻解碼器應用1090和單個視頻編碼器應用1095，但是其它實施例可以包括多個視頻編碼器和視頻解碼器應用。而且，一些實施例可以對每個輸出流使用應用的集合，以便讓分開的重新包裝器、解碼器和編碼器應用生成每個不同的輸出流。

在若干實施例中，網(wǎng)絡接口1040可以與處理器1010、易失性存儲器1020和/或非易失性存儲器1030通信。存儲在實況編碼服務器1000的非易失性存儲器1030中的應用的上述討論討論了支持實況編碼服務器1000的一個示例性應用集合。本發(fā)明的其它實施例可以利用具有下面討論的功能的多個服務器，這些功能根據(jù)需要分布在多個服務器和/或位置上以實現(xiàn)本發(fā)明。此外，下面討論的應用可以組合成一個或多個應用，并且根據(jù)需要實現(xiàn)為軟件模塊，以實現(xiàn)本發(fā)明。例如，下面討論的應用可以備選地被實現(xiàn)為駐留在實況編碼服務器1000上的單個應用的模塊。而且，在示出單個應用的情況下，其它實施例可以利用專用于類似功能的多個應用。

上面討論的各種過程可以在單個離散的服務器上實現(xiàn)。備選地，它們可以各自被實現(xiàn)為任何數(shù)量的物理、虛擬或云計算設備上的共享和/或離散的服務器。具體而言，根據(jù)本發(fā)明的一些實施例的實況編碼系統(tǒng)可以包括單獨的(一個或多個)編碼服務器和(一個或多個)http服務器。本領域普通技術人員將認識到的是，各種實現(xiàn)方法可以被用來實現(xiàn)本發(fā)明的實施例的過程服務器。

雖然上面的描述包含本發(fā)明的許多具體實施例，但是這些不應當被解釋為對本發(fā)明的范圍的限制，而是作為其一個實施例的示例。因而，本發(fā)明的范圍不應當由所示實施例而是由所附權利要求及其等同物來確定。