多媒體流的自適應(yīng)轉(zhuǎn)碼的方法和裝置制造方法
【專利摘要】一種用于流傳輸從對應(yīng)的輸入內(nèi)容流自適應(yīng)地轉(zhuǎn)碼的輸出內(nèi)容流的方法，包括：給客戶端設(shè)備提供輸出內(nèi)容流的多個替代版本以供所述客戶端設(shè)備選擇，以及將輸入內(nèi)容流劃分成兩個或多個分段。在所述提供步驟之前，至少將輸入內(nèi)容流的第一分段轉(zhuǎn)碼和存儲為對應(yīng)于來自提供給客戶端設(shè)備的多個替代版本的至少一個版本的輸出內(nèi)容流的至少一個對應(yīng)分段。一旦從客戶端設(shè)備接收到對于輸出內(nèi)容流的所選版本的請求，使用在所述提供步驟之前已經(jīng)被轉(zhuǎn)碼和存儲的對應(yīng)于來自提供給客戶端設(shè)備的多個替代版本的至少一個版本的輸出內(nèi)容流的至少一個對應(yīng)分段來開始流傳輸。從所述請求提取轉(zhuǎn)碼參數(shù)，用于控制將所述輸入內(nèi)容流的后續(xù)分段轉(zhuǎn)碼為客戶端設(shè)備所選擇的版本，并且被轉(zhuǎn)碼為所請求版本的后續(xù)分段被流傳輸?shù)娇蛻舳恕?br> 【專利說明】多媒體流的自適應(yīng)轉(zhuǎn)碼的方法和裝置
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種用于多媒體流、特別是音頻和/或視頻流的自適應(yīng)轉(zhuǎn)碼的方法和
>J-U ρ?α裝直。
【背景技術(shù)】
[0002]音頻和/或視頻流可以通過使用各種不同設(shè)備的用戶而被消費。值得注意地，視頻流可能要求適配于再現(xiàn)設(shè)備的屏幕尺寸的格式或表示。音頻流可能同樣會受到再現(xiàn)設(shè)備所設(shè)置的限制。然而，在下面將集中于視頻流地提出本發(fā)明。
[0003]由于在其上對內(nèi)容進行流傳輸?shù)倪B接中的變型導(dǎo)致也可能需要任何種類的流傳輸內(nèi)容的自適應(yīng)。例如，無線連接由于擁塞、或者接收設(shè)備的漫游引起的變化的接收條件，可能僅提供變化的吞吐量。
[0004]已經(jīng)提出了內(nèi)容的自適應(yīng)流傳輸?shù)亩喾N實現(xiàn)方式。例如加利福尼亞的蘋果公司的也被稱為“HTTP實時流傳輸”或“HLS”的實現(xiàn)方式。這種實現(xiàn)方式由R.Pantos描述在2010年 11 月的 IETF, Internet-Draft Version5 (draft-pantos-http-live-streaming-05)的《HTTP Live Streaming》中。
[0005]另一種實現(xiàn)方式是由Microsoft?提出的，被稱為“Silverlight平滑流傳輸”。這種實現(xiàn)方式描述在《IlSsmooth streaming technical overview》中。詳細信息在http: //www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=03d22583-3ed6-44da~8464~b Ib4b5ca7520 上在線可得。
[0006]又一種實現(xiàn)方式是由Adobe Systems公司提出的，已知名稱為“Adobe動態(tài)流傳輸”。詳細信息可以在文件《HTTP dynamic streaming on the Adobe Flashplatform》中找至丨J，在 http: //www.adobe, com/products/httpDynamic-streaming/pdfs/httpdynamicstreaming wp ue.pdf 上在線可得。
[0007]標(biāo)準(zhǔn)化工作仍然由SA4小組內(nèi)的3GPP進行，并且由“HTTP上的動態(tài)自適應(yīng)流傳輸”(DASH)小組進行MPEG中的標(biāo)準(zhǔn)化工作。關(guān)于這項工作的詳細信息由T.Stockhammer公開在〈〈Dynamic adaptive streaming over HTTP-standards and design principles)) (2011年多媒體系統(tǒng)ACM會議(MMSysE2011)學(xué)報，2011年2月，第157-168頁)中。
[0008]在所有的已知的實現(xiàn)方式中，服務(wù)器必須已經(jīng)存儲了已被預(yù)編碼和已準(zhǔn)備好傳送的要被流傳輸?shù)膬?nèi)容——無論是作為單獨的塊或是作為可以從較大的容器文件中提取出來的分段。
[0009]Kevin J.Ma、Radim Bartos> Swapnil Bhatia、Raj Nair 在的《Mobile videodelivery with HTTP》(ffiEE通信雜志，2011年4月，第166-174頁)中公開了使用轉(zhuǎn)碼的內(nèi)容的自適應(yīng)流傳輸。轉(zhuǎn)碼被用來將多媒體內(nèi)容從一種格式轉(zhuǎn)變到另一種格式。
[0010]Kue1-Chung Chang、Ren_Yo Wu>Tien-Fu Chen ((Efficient segment-based videotranscoding proxy for mobile multimedia services》(2005 年多媒體和展覽 IEEE 國際會議(ICME)，第755-758頁)中也討論了流傳輸?shù)囊曨l的轉(zhuǎn)碼。
【發(fā)明內(nèi)容】

[0011]本發(fā)明的一個目的是改進經(jīng)轉(zhuǎn)碼的流傳輸?shù)膬?nèi)容的用戶體驗，并同時減少服務(wù)器和/或系統(tǒng)要求。
[0012]該目的通過在所附的權(quán)利要求中所提出的方法和裝置來實現(xiàn)。相應(yīng)的從屬權(quán)利要求表示該裝置和方法的實施例和發(fā)展。
【具體實施方式】
[0013]為了為流傳輸?shù)膬?nèi)容的每個項目提供可能的最佳用戶體驗，用戶可以選擇適合于他/她打算使用的回放設(shè)備的內(nèi)容格式。該選擇也可以基于其它考慮因素，包括但不限于傳輸(特別是關(guān)于經(jīng)由相同的傳輸信道并發(fā)的傳輸)所需的帶寬，以及與傳輸帶寬相關(guān)聯(lián)的成本。同樣地，付費內(nèi)容可能具有取決于顯示的質(zhì)量的定價。
[0014]如上面所討論的，內(nèi)容流通常存儲在服務(wù)器上，例如以多種格式和質(zhì)量存儲在HTTP服務(wù)器上。最高質(zhì)量的最可能具有高的比特率；最低質(zhì)量的最可能具有低的比特率。這允許將內(nèi)容分發(fā)到可能額外地遭受高度變化的網(wǎng)絡(luò)條件的多個不同的終端或客戶端設(shè)備。整個內(nèi)容流被劃分成多個塊，選擇所述塊使得客戶端設(shè)備，例如視頻播放器或終端，可以在兩個塊之間平滑地從一個質(zhì)量水平切換到另一個。這樣的切換可以在網(wǎng)絡(luò)連接的狀況變化的情況下發(fā)生，也可以在用戶想要更改播放設(shè)備同時繼續(xù)消費內(nèi)容的情況下發(fā)生。因此，視頻質(zhì)量可能在播放時變化，但很少中斷。
[0015]一旦用戶請求無法從服務(wù)器上獲得的質(zhì)量的內(nèi)容，內(nèi)容流或其塊就被轉(zhuǎn)碼到所請求的格式和質(zhì)量，并發(fā)送給用戶。但是，內(nèi)容的轉(zhuǎn)碼需要時間，這將延遲用戶所請求的內(nèi)容的回放。即使視頻的前幾個塊一旦被轉(zhuǎn)碼就可以被傳輸，并且可以在后臺繼續(xù)視頻的后續(xù)塊的轉(zhuǎn)碼，這樣的延遲通常也是不希望的，因為它降低了服務(wù)的用戶體驗的感知質(zhì)量。
[0016]在服務(wù)器和回放設(shè)備之間、或者在轉(zhuǎn)碼網(wǎng)關(guān)和回放設(shè)備之間的網(wǎng)絡(luò)連接變化的情況下，該延遲尤其明顯，迫使服務(wù)器或網(wǎng)關(guān)以降低到回放設(shè)備的連接上的內(nèi)容的數(shù)據(jù)速率。當(dāng)用戶改變回放設(shè)備同時繼續(xù)消費內(nèi)容時，該延遲同樣明顯，特別是對于可能是內(nèi)容提供商的有償優(yōu)質(zhì)服務(wù)的無縫回放體驗。例如，用戶可以在他/她的家中的大屏幕上開始觀看視頻，并在視頻沒有結(jié)束時決定移動到一個不同的地方。然后該視頻的其余部分可能在具有不同的屏幕尺寸和回放能力的移動設(shè)備上進行再現(xiàn)。這不僅要求該流必須被重定向到新的回放設(shè)備，還要求必須改變轉(zhuǎn)碼參數(shù)。如果新的格式的視頻或其塊的副本對于即時切換不是容易地可用的，這個轉(zhuǎn)變會在該流中插入另一延遲。
[0017]通常，內(nèi)容流被作為除其它事情之外還提供一組所謂的“表示”的流描述符宣告到客戶端設(shè)備或再現(xiàn)設(shè)備，每一種質(zhì)量水平、比特率、格式等一種表示。每個完整的表示包括優(yōu)選地具有相等的持續(xù)時間的一系列塊，并且具有附接的供客戶端選擇的一組描述性元素。每個塊可由單獨的URL訪問。
[0018]為了支持實時流傳輸，所述宣告可以僅描述對應(yīng)內(nèi)容流的一部分。在這種情況下，必須定期更新所宣告的部分。
[0019]如上面所進一步討論的，可以通過在服務(wù)器上以所有可以想到的格式保留內(nèi)容的副本來避免該延遲。然而，這種方法需要非常大的存儲，這對于不常被請求的格式是特別低效的，因此這是不希望的。
[0020]參閱上面的討論，如果只有一個最高質(zhì)量的內(nèi)容副本是可用的，另一種避免延遲的方式是使用轉(zhuǎn)碼器，它能夠并行地將請求的內(nèi)容轉(zhuǎn)碼到所有可以想到的格式。但是，這種轉(zhuǎn)碼器需要極高的處理能力，這很可能產(chǎn)生非常高的成本，因此這也是不希望的。
[0021]按照本發(fā)明的實施例，客戶端設(shè)備發(fā)送對于期望的內(nèi)容的請求到服務(wù)器。該請求包括所述客戶端設(shè)備能夠處理以進行再現(xiàn)的格式、質(zhì)量、帶寬、數(shù)據(jù)速率等的指示，并且還可以包括優(yōu)選格式的指示?？梢砸赃x擇多個HTTP鏈接之一的形式作出該請求，每個鏈接表示一種格式、數(shù)據(jù)速率或質(zhì)量，或以上的組合。每一鏈接向轉(zhuǎn)碼器傳遞允許設(shè)置適當(dāng)?shù)霓D(zhuǎn)碼器參數(shù)以生成具有期望的和所選的屬性的內(nèi)容流的信息。換句話說，由服務(wù)器提供的選擇頁面將如何可接收流傳輸?shù)膬?nèi)容的描述作為例如可供選擇的可用選項的列表提高給客戶端設(shè)備。
[0022]流傳輸內(nèi)容以塊的序列提供給客戶端。通過單獨的請求,例如HTTP請求，就好像它是個小巧的文件那樣來取回每個塊。對于每個塊，客戶端設(shè)備特別地關(guān)于網(wǎng)絡(luò)連接的屬性來決定哪個比特率、質(zhì)量、分辨率、格式等是合適的，并相應(yīng)地通過具體的鏈接地址或URL請求該塊。因此，對于各種比特率、格式、質(zhì)量等的每一個的流傳輸內(nèi)容的每個塊存在唯一的URL。逐一播放單獨請求的塊以形成所述內(nèi)容流。
[0023]如上面所進一步討論的，特別地對于實時流傳輸內(nèi)容，但是也對于其他類型的點播內(nèi)容，實時服務(wù)器需要實時地以所有可以想到的質(zhì)量、格式、數(shù)據(jù)速率等來準(zhǔn)備塊。典型地，得到的各種塊將至少被暫時地存儲和例如通過Web服務(wù)器根據(jù)要求來傳送。服務(wù)器端有限的轉(zhuǎn)碼和/或存儲資源為這樣的方法帶來了障礙。只響應(yīng)于對下一個塊的請求來改變轉(zhuǎn)碼參數(shù)將導(dǎo)致延遲，阻止內(nèi)容流的平滑和無縫回放。
[0024]按照本發(fā)明，如果雖然向客戶端設(shè)備公告為可用，但是具有所請求的屬性的塊不可用時，使用可用的塊、優(yōu)選地使用具有盡可能地接近所請求的屬性的屬性的可用的塊來應(yīng)答對于指向這種不可用的塊的鏈接的請求。這樣的塊可以是例如從相同的內(nèi)容的預(yù)先計算并存儲的版本的有限選擇中進行選擇。當(dāng)傳送預(yù)先計算的塊以提供平滑的內(nèi)容流時，原始請求的參數(shù)被用于相應(yīng)地改變轉(zhuǎn)碼器參數(shù)。然后要被發(fā)送的下一塊將以實際請求的格式、質(zhì)量、比特率等可用。這種方法在一定程度上依賴于比塊的再現(xiàn)的持續(xù)時間改變更慢的連接屬性。
[0025]本發(fā)明的自適應(yīng)流傳輸允許在傳輸過程中(on-the-fly)從(包括但不限于)任何傳入的廣播或傳統(tǒng)的IPTV節(jié)目中產(chǎn)生HTTP自適應(yīng)流傳輸兼容內(nèi)容流。一種可能的輸出是以適合于傳送到自適應(yīng)客戶端的格式進行多路復(fù)用的H.264視頻和AAC音頻，例如，用于傳送到加利福尼亞的蘋果公司制造的客戶端設(shè)備的MPEG-TS。
[0026]H.264編碼需要大量的計算以及資源有限的轉(zhuǎn)碼設(shè)備，例如采用被設(shè)計用于嵌入式設(shè)備并具有用于轉(zhuǎn)碼的有限資源的Intel CE4200處理器的設(shè)備。雖然這款處理器可以同時產(chǎn)生例如NTSC或PAL格式的標(biāo)準(zhǔn)清晰度的若干視頻，但它一次僅可以輸出一個HD視頻。
[0027]因此，Intel CE4200的計算能力限制了能夠同時輸出的不同的視頻質(zhì)量的數(shù)量。為例如，如果目標(biāo)分辨率接近HD，例如1920X 1080i/p，或720X 1280i/p，則只能輸出單個流，從而使產(chǎn)生多種質(zhì)量的自適應(yīng)流成為不可能的。[0028]本發(fā)明允許將輸入視頻流轉(zhuǎn)化為自適應(yīng)HTTP流，而無需在其它情況下產(chǎn)生各種可能的替代流所需的高處理能力。
[0029]根據(jù)本發(fā)明，向客戶端設(shè)備提供若干可能的表示，例如比特率、格式等，但實際上只有替代物的子集，或者如果處理能力很低的話甚至只有一個單一替代物，被以根據(jù)客戶端設(shè)備做出的請求調(diào)節(jié)的比特率來進行轉(zhuǎn)碼。
[0030]本發(fā)明解決的一個方面是在自適應(yīng)內(nèi)容流傳輸中，內(nèi)容流的塊在它們被宣告時必須是容易地可用的。因此，與傳輸過程中轉(zhuǎn)碼方法通常做出的相反，必須預(yù)測客戶端請求。否則對這些請求的響應(yīng)會來得太晚。由于兩個原因使得預(yù)期是可能的。首先，所請求的塊是整體流的一部分。換句話說，為了用戶能觀看正確的內(nèi)容流，必須以它們產(chǎn)生的順序來播放它們。因此，當(dāng)一個塊被轉(zhuǎn)碼時，已經(jīng)已知接下來要產(chǎn)生哪個塊。然后，以不是客戶端設(shè)備所請求的比特率的比特率產(chǎn)生少許塊，而且由于任何HTTP自適應(yīng)流傳輸客戶端設(shè)備實現(xiàn)方式固有的緩沖能力使得傳送這些塊而不是所請求的塊成為可能。當(dāng)然，在預(yù)測算法上必須慎重:必須避免溢出客戶端緩沖區(qū)。
[0031]根據(jù)本發(fā)明的方法包括預(yù)先產(chǎn)生流傳輸內(nèi)容的開始的一個或多個連續(xù)塊。例如，蘋果公司的實現(xiàn)方式在流傳輸會話的開始至少需要至少3個塊以填充播放器的緩沖區(qū)。其它實現(xiàn)方式可能需要將要預(yù)轉(zhuǎn)碼的不同數(shù)量的塊。當(dāng)產(chǎn)生了這些所謂的啟動塊的時候，客戶端期望的比特率仍是未知的。因此，由自適應(yīng)平臺預(yù)先選擇比特率。該選擇可以基于先前流傳輸會話的統(tǒng)計分析，或者僅僅是任意的。然后，在下一步驟中，列出替代表示，或變型的清單被例如通過HTTP服務(wù)器提供給客戶端。對于蘋果公司的實現(xiàn)方式，該清單是以M3U8播放列表的形式。這些變型可以提供除其它外的流傳輸內(nèi)容的不同的空間或時間分辨率、不同的格式、不同的比特率或不同質(zhì)量。例如，當(dāng)客戶端設(shè)備請求以M3U8播放列表的形式的視頻流時，HTTP服務(wù)器傳送列出可用的變型播放列表的主M3U8播放列表，從而定義可用的比特率。可用比特率的列表根據(jù)終端用戶代理，例如內(nèi)容播放器來進行調(diào)節(jié)。每個替代變型的清單條目包含已準(zhǔn)備好可由客戶端進行下載的塊的列表。由客戶端下載該變型描述。根據(jù)本發(fā)明，清單的所有可選的變型指向相同的預(yù)轉(zhuǎn)碼的塊。如上所述，對于蘋果公司的實現(xiàn)方式，這種變型清單由M3U8播放列表來表示，每個變型通過唯一的鏈接可選。然后，客戶端請求內(nèi)容的變型的流傳輸和因此請求從該變型供應(yīng)所述塊。變型播放列表列出指向可用的塊的鏈接，或者更精確地說，包含到可用塊的符號鏈接。響應(yīng)于來自客戶端的請求，內(nèi)容服務(wù)器僅傳送來自已經(jīng)可用的預(yù)轉(zhuǎn)碼的變型的對應(yīng)塊，并從所請求的鏈接確定所期望的比特率。該所期望的比特率被反饋到為后續(xù)塊調(diào)節(jié)編碼比特率的轉(zhuǎn)碼器。應(yīng)注意，比特率可以由格式、空間和時間分辨率、質(zhì)量等來代替。該轉(zhuǎn)碼器連續(xù)地捕獲傳入內(nèi)容流的部分，將其轉(zhuǎn)碼成所期望的比特率并將其以適合于自適應(yīng)流傳輸?shù)母袷竭M行封裝。每當(dāng)通過轉(zhuǎn)碼器產(chǎn)生新的塊并準(zhǔn)備好用于供應(yīng)時，更新提供給客戶端的清單和變型的清晰度，使得客戶端被告知新近可用的塊。從客戶端的角度，所述流看起來好像是轉(zhuǎn)碼器實際上在提供由若干替代變型組成的傳統(tǒng)自適應(yīng)流，并且該流被自適應(yīng)地調(diào)節(jié)到可用的帶寬或客戶端的能力。
[0032]例如，假設(shè)M是變型播放列表的數(shù)量，Pk是第k個變型播放列表，Bk是第k個變型播放列表的比特率，N是目前可用的塊的數(shù)量，Ci是對應(yīng)于第i次迭代的塊。所以基本上，當(dāng)塊Cp C2, C3可用時，播放列表Pk列出作為分別朝向Cp C2, C3的符號鏈接的塊Cu、ck；2, Ckj3的URL。以這樣一種方式構(gòu)造所述符號鏈接，使得可以方便地從該URL取回比特率。當(dāng)客戶端請求視頻塊Clu時，web服務(wù)器不僅傳送所請求的塊，也解析該請求URL。服務(wù)器從這個URL提取客戶端指示其期望以第k個變型播放列表信號通知的比特率Bk接收第一塊的事實。該信息被輸入到帶寬估計模塊，其計算足夠用于編碼隨后塊的比特率值。根據(jù)本發(fā)明，可以使用簡單的低通濾波器來平滑瞬時帶寬變化。帶寬估計模塊的輸出值B’k被立即用于重新配置轉(zhuǎn)碼器，使得其以比特率B’k產(chǎn)生下一個塊——在本示例中為編號4的塊。另外，該轉(zhuǎn)碼器被通知剛剛消費了塊# 1，從而指示“GO”用于產(chǎn)生塊# 4。轉(zhuǎn)碼器以啟動和停止的方式工作，使得它避免了在消費塊之前太早提前對其進行編碼。由于蘋果公司流傳輸實現(xiàn)方式要求存在N=3個塊，因此轉(zhuǎn)碼器運行，直到3個塊已經(jīng)準(zhǔn)備就緒，并且停止，直到最舊的塊已被消費。這種機制有助于加快收斂到客戶端所請求的比特率。一旦塊是可用的，對于從I到M范圍內(nèi)的k創(chuàng)建對應(yīng)的符號鏈接C4，k，并且更新所有的播放列表Pk以向客戶端通告存在塊C4，k。由于客戶端周期性地請求播放列表Pk的內(nèi)容，它將很快發(fā)現(xiàn)另一個塊的存在，并請求其重新補充它的播出緩沖區(qū)。
[0033]按照本發(fā)明的裝置能夠?qū)崟r地將傳入的內(nèi)容流轉(zhuǎn)碼為具有不同的格式、數(shù)據(jù)速率、質(zhì)量等的至少一種輸出內(nèi)容流。例如，這樣的裝置能夠?qū)魅氲囊曨l流轉(zhuǎn)碼到至少一種
H.264兼容的輸出視頻流。輸出視頻流可以被封裝為適合于HTTP自適應(yīng)流傳輸?shù)膫鬏敻袷健TTP服務(wù)器將轉(zhuǎn)碼后的視頻流的塊傳送到客戶端設(shè)備。服務(wù)器發(fā)信號通知期望的比特率、格式、質(zhì)量等給轉(zhuǎn)碼器。發(fā)信號通知給轉(zhuǎn)碼器的有關(guān)參數(shù)的信息是從客戶端的請求而取得的，但也可以從連接的監(jiān)視狀況推導(dǎo)出來，例如在與客戶端設(shè)備的無線連接的吞吐量變化的情況下。實際上，在充當(dāng)流傳輸?shù)膬?nèi)容的主機的服務(wù)器和客戶端之間的連接中的吞吐量的任何變化都可以導(dǎo)致轉(zhuǎn)碼參數(shù)中的變化。這種行為很大程度上取決于轉(zhuǎn)換器所處的連接中的位置。如果從任一側(cè)(即，從轉(zhuǎn)碼器的輸入側(cè)和從轉(zhuǎn)碼器的輸出側(cè))為轉(zhuǎn)碼器提供對應(yīng)信息，那么其在主機服務(wù)器和客戶端設(shè)備之間的連接中的位置幾乎是不相關(guān)的。
[0034]如上面所進一步 討論的，按照本發(fā)明的裝置的示例性實施例采用了基于IntelCE4200的平臺。這個處理器包括以硬件實現(xiàn)的基本的視頻解碼和編碼功能。封裝和web服務(wù)任務(wù)在軟件中執(zhí)行。在下面，這個平臺將被稱為“自適應(yīng)平臺“。
[0035]下面將參照附圖描述本發(fā)明，附圖中唯一的附圖示出了所涉及的組件的概述。
[0036]實施本發(fā)明的環(huán)境包括三個通用元件:源、播放器和自適應(yīng)平臺。
[0037]源是例如視頻的流傳輸內(nèi)容的來源。換句話說，源是流傳輸內(nèi)容的提供者。例如，它可能是傳送任何種類的家庭或預(yù)付費視頻的家庭設(shè)備，或是傳送廣播或組播視頻(DVB-T、DVB-1PTV……)，或者甚至可以被表示為文件或從網(wǎng)絡(luò)流傳輸?shù)狞c播視頻服務(wù)、VoD服務(wù)的外部內(nèi)容提供者。在該圖中，源被引用為DVB/IPTV。
[0038]播放器是商業(yè)終端或客戶端設(shè)備，其能夠取決于它的能力和網(wǎng)絡(luò)狀況以不同的質(zhì)量播放視頻。優(yōu)選類似HTTP自適應(yīng)流傳輸?shù)膮f(xié)議，因為它允許客戶端在播放之前請求適當(dāng)?shù)馁|(zhì)量。圖中將播放器示為“客戶端”。
[0039]自適應(yīng)平臺占據(jù)了附圖的最大的一部分。提供信號分離器“解復(fù)用器”以將傳入的內(nèi)容流解復(fù)用成獨立的音頻和視頻成分(如適用)。視頻成分在解碼器“解碼”中進行解碼并在分段單元“分段”中進行分段。然后，在編碼器“編碼”中對分段進行轉(zhuǎn)碼，即使用不用于原始參數(shù)的參數(shù)進行重新編碼。該編碼器可以是H.264編碼器，但其它格式同樣是可能的。音頻成分在分段單元“分段”中被分割為分段，并也可以被轉(zhuǎn)碼(未示出)。然后，轉(zhuǎn)碼后的音頻和視頻分段被提供給多路復(fù)用器“TS復(fù)用器”。多路復(fù)用器“TS復(fù)用器”將轉(zhuǎn)碼后和多路復(fù)用后的分段寫入存儲器“文件”，從那里服務(wù)器“Web服務(wù)器”(例如HTTP服務(wù)器)將分段轉(zhuǎn)移到客戶端。
[0040]如上面所進一步討論的，當(dāng)在具有有限的處理能力的轉(zhuǎn)碼設(shè)備中實現(xiàn)時本發(fā)明特別有用，例如在具有基于Intel CE4200處理器的基本的媒體處理能力的互聯(lián)網(wǎng)網(wǎng)關(guān)中。
[0041]本領(lǐng)域技術(shù)人員將認識到，上面討論的實施例中使用的對H.264編解碼器和M3U8清單格式的選擇只在應(yīng)用到蘋果客戶端設(shè)備時對描述本發(fā)明是必須的。當(dāng)編碼資源太稀缺以致難以并行產(chǎn)生出所有必要的替代流時，要求諸如VC1、WebM的其它編解碼器和其它清單格式的其它自適應(yīng)流傳輸實現(xiàn)方式可以同樣受益于所述發(fā)明。
[0042]在流傳輸實時視頻的情形中，清單宣布隨時間變化的塊的集合。已宣布的變型的集合也可能改變。這可以用于本發(fā)明的開發(fā)，其中，所提出的變型的集合被動態(tài)修改。例如，如果清單提出五個變型，三個具有接近于(例如略低于或略高于)最后請求的比特率的比特率，一個具有高得多的比特率，第五個具有低得多的比特率?？梢匀Q于該連接的吞吐量的過去的變化來更新清單中存在的這些版本。
[0043]如果轉(zhuǎn)碼器能夠產(chǎn)生多于一個H.264輸出流，期望預(yù)測該自適應(yīng)以進一步改善用戶體驗。按照本發(fā)明的發(fā)展，跟蹤器模塊除了當(dāng)前請求外還跟蹤先前請求的一個比特率或多個比特率。當(dāng)目前請求的比特率低于先前比特率時，預(yù)測模塊假定客戶端可以在以后的請求中進一步降低比特率。因此，在這種情況下，運行轉(zhuǎn)碼器的兩個實例，以所請求的比特率Ci,,和下一更低的比特率Ci,η兩者產(chǎn)生下一塊。呈現(xiàn)模塊為j屬于[k;M]的Cu創(chuàng)建指向Cu的所有符號鏈接，并且為j屬于[0;k-l]的Cu創(chuàng)建符號鏈接以指向Cu+
[0044]如果目前請求是以比先前比特率更高的比特率，預(yù)測模塊假定在未來請求中比特率將進一步增加，并以類似的方式引起以更高的比特率產(chǎn)生塊的其它版本。
[0045]應(yīng)注意，跟蹤器模塊、預(yù)測模塊和呈現(xiàn)模塊可被包括為通用微處理器上的軟件模塊，或者可以是專用電路。
[0046]本發(fā)明允許對包括移動設(shè)備的各種設(shè)備重新分配任何可用的輸入流和應(yīng)對傳輸質(zhì)量的變化。這種自適應(yīng)是非常符合成本效益的，因為它不要求預(yù)先準(zhǔn)備流以用于自適應(yīng)流傳輸，并且甚至可以通過諸如住宅網(wǎng)關(guān)的低端設(shè)備來實現(xiàn)。
[0047]因為沒有預(yù)先準(zhǔn)備流傳輸內(nèi)容的塊，因此從理論上講，有可能利用無限數(shù)量的變型來宣布流傳輸內(nèi)容。
[0048]因為盡可能接近用戶地(例如在住宅網(wǎng)關(guān)中)執(zhí)行所述自適應(yīng)，因此本發(fā)明提供了一種用于提供廣闊分布、同時保持每個單獨用戶的可能的最佳體驗的低成本的解決方案。視頻被以高質(zhì)量廣泛傳播，例如組播到住宅網(wǎng)關(guān)，并只在網(wǎng)關(guān)中自適應(yīng)。
[0049]除非意圖為以后的用戶保留流傳輸內(nèi)容，沒有必要將其保存在自適應(yīng)平臺上。只必要在平臺上存儲它的一部分以用于臨時使用和用于實施的便利。
【權(quán)利要求】
1.一種用于流傳輸從對應(yīng)的輸入內(nèi)容流自適應(yīng)地轉(zhuǎn)碼的輸出內(nèi)容流的方法，該方法包括以下步驟: -給客戶端設(shè)備提供輸出內(nèi)容流的多個替代版本以供所述客戶端設(shè)備選擇； -將輸入內(nèi)容流劃分成兩個或多個分段； -在所述提供步驟之前，至少將輸入內(nèi)容流的第一分段轉(zhuǎn)碼和存儲為對應(yīng)于來自提供給客戶端設(shè)備的多個替代版本的至少一個版本的輸出內(nèi)容流的至少一個對應(yīng)分段； -從客戶端設(shè)備接收用于流傳輸輸出內(nèi)容流的所選版本的塊的請求； -使用在所述提供步驟之前已經(jīng)被轉(zhuǎn)碼的對應(yīng)于來自提供給客戶端設(shè)備的多個替代版本的至少一個版本的輸出內(nèi)容流的至少一個對應(yīng)分段的第一分段來開始流傳輸； -從所述請求提取轉(zhuǎn)碼參數(shù)，用于控制將所述輸入內(nèi)容流的后續(xù)分段轉(zhuǎn)碼為客戶端設(shè)備所選擇的版本；以及 -流傳輸被轉(zhuǎn)碼為所請求版本的后續(xù)分段。
2.根據(jù)權(quán)利要求1所述的方法，其中，至少將輸入內(nèi)容流的第一分段預(yù)先轉(zhuǎn)碼為來自提供給客戶端設(shè)備的多個替代版本的許多版本的對應(yīng)分段。
3.根據(jù)權(quán)利要求2所述的方法，其中，響應(yīng)于所述請求被立即流傳輸?shù)膶?yīng)于所述至少第一分段的分段選自與客戶端的再現(xiàn)能力兼容的版本。
4.根據(jù)權(quán)利要求2所述的方法，其中，響應(yīng)于所述請求被立即流傳輸?shù)膶?yīng)于所述至少第一分段的分段選自這樣的版本，其轉(zhuǎn)碼參數(shù)與從客戶端設(shè)備接收的請求中提取的轉(zhuǎn)碼參數(shù)盡可能接近地匹配。
5.根據(jù)權(quán)利要求1所述的方法，其中，轉(zhuǎn)碼包括產(chǎn)生輸出內(nèi)容流，其中格式、空間或時間分辨率、數(shù)據(jù)速率、或者質(zhì)量中的至少一種與相應(yīng)的輸入格式、空間或時間分辨率、數(shù)據(jù)速率、或者質(zhì)量不同。
6.根據(jù)權(quán)利要求1所述的方法，其中，基于有關(guān)提供輸入內(nèi)容流的服務(wù)器和客戶端設(shè)備之間的連接的分段的容量的信息來改變用于控制輸入內(nèi)容流的后續(xù)分段的轉(zhuǎn)碼的轉(zhuǎn)碼參數(shù)。
7.根據(jù)權(quán)利要求1所述的方法，其中對于每個后續(xù)分段重復(fù)所述提供步驟，并且其中，按照從定向到當(dāng)前正在被服務(wù)的分段的請求中提取的參數(shù)來轉(zhuǎn)碼所提供的分段的至少一個變型。
8.—種適配于執(zhí)行根據(jù)前述權(quán)利要求中任一項的方法的裝置。
【文檔編號】H04N21/6379GK103765905SQ201280042071
【公開日】2014年4月30日 申請日期:2012年8月24日 優(yōu)先權(quán)日:2011年9月2日
【發(fā)明者】C.德勞內(nèi), R.侯代勒, S.戈雅克, H.貝爾哈德阿里 申請人:湯姆遜許可公司