TW201351965A - 對委託器提供具有不同位元率的內容串流版本集之方法及實施系統 - Google Patents

Abstract

本案擬議提供具有不同位元率的內容串流複數版本之方法。按照本方法，對委託器提供具有不同位元率的內容串流版本集。描述所提供內容串流版本集的清單組件，提交給委託器。委託器要求具有特定位元率的內容串流之一版本。提供給委託器的版本之位元率，以動態方式選擇，以動態適應鄰區版本位元率間之差異。本案擬議之方法改進適應性轉碼，故可根據分佈於現時輸送位元率左右的位元率數值小集，使用小清單組件。此外，擬議實施此方法之系統。

Description

對委託器提供具有不同位元率的內容串流版本集之方法及實施系統

本發明係關於提供具有不同位元率的內容串流複數版本之方法。按照本發明方法，各版本係從同樣輸入內容串流轉碼。本發明亦關係適於實施本發明方法之系統。

於今在伺服器內儲存愈來愈多數位聲訊和視訊，並可在線上輸送。內容在實體性媒體上之分佈繼續遞減。按照線上輸送的第一策略，聲訊和視訊內容(A/V視聽內容)可從伺服器下載到委託器，整個在單一檔案內，例如呈數位mp3聲訊檔案。然而，在此策略中，輸送視訊內容(諸如完整軟片)通常需長時間下載視訊內容，延遲使用者欣賞視訊內容的開始時間。

按照線上輸送的第二策略，把視聽內容切成小元件序列，逐一下載。個別元件亦稱為「語塊」。語塊代表小時段，數秒程度，可銜接重製完全內容。以系列語塊發送的語塊整體，亦稱為視聽串流。聲訊和視訊內容亦稱為「流送內容」。流送內容係由聲訊和/或視訊串流構成。

聲訊和/或視訊串流可由使用者使用各種不同裝置消費。尤其是視訊串流需要適應重製裝置顯示幕大小之格式或表示法。聲訊同樣受到重製裝置設定的限制。惟下述本發明以視訊串流為焦點舉例表示，並非本發明僅限於視訊串流。

任何種類的流送內容亦需適應，因為內容從伺服器流送到委託器裝置之連接有各種各樣。例如無線連接只能提供由於混雜而變化的貫輸量，或接收裝置徘徊造成的變化接收狀況。若適應性流送作業妥當，內容消費者始終可欣賞最佳的可能內容，因為所輸送串流之最佳速率，係連續性動態適應網路或回放條件變化。

迄今業已倡議適應性流送內容之各種實施方式。

一例是美國加州蘋果公司的實施方式，亦稱為HTTP靈活流送(Live Streaming)或HLS。此項實施方式載於R.Pantos著〈HTTP靈活流送〉，IETF，網際網路草案第5版(draft-pantos-http-live-streaming-05)，2010年11月。

另一實施方式是微軟公司提出，稱為「銀光順暢流送」。此實施方式載於〈IIS順暢流送技術概覽〉。詳細可查網上http：//www.microsoft.com/downloads/details.aspx？displaylang=en&FamilyID=03d22583-3ed6-44da-8464-b1b4b5ca7520。

另一實施方式是阿鐸比系統公司提出，稱為「阿鐸比動態流 送」。詳細可查文件〈阿鐸比快閃平台上的HTTP動態流送〉，可在網上查http：//www.adobe.com/products/httpdynamicstreaming/pdfs/httpdynamicstreaming wp ue.pdf。

適應性流送之標準化作業，仍然由SA4組群內的3GPP，以及在MPEG內利用「跨越HTTP的動態適應性流送」(DASH)組進行中。DASH組公佈於2011年12月發表的第一次規格。此作業之細節由T.Stockhammer：〈跨越HTTP之動態適應性流送一其標準和設計原理〉，發表於2011年ACM多媒體系統研討會議事錄(MMSysE 2011)，2011年2月，第157-168頁。

不同技術的共同點是，伺服器每一時期提供若干語塊版本，容許位元率適應。伺服器、編碼器、委託器，以及連接二者的網路，由此代表之系統建造成為，對任何時期要求相對應語塊版本，即可使委託器從一位元率交換成另一位元率。分開提供描述語塊配置之清單組件(語塊期限、語塊位元率和/或格式)，而在流送情況下，需定期重新載錄，以供更新。

此舉如何達成之細節，以及清單組件的格式視所用特定技術：蘋果HTTP靈活流送、微軟順暢流送、阿鐸比HTTP動態流送等而異。惟基本上都依賴同樣構想。

如此系統之正常使用，是把資料從網路伺服器，透過網際網路輸送到任何委託器。如此伺服器，以及輸送路徑上的http窖藏器，把委 託器在指定時間會要求的全部語塊版本，均可以儲存。

在先前提出的歐洲專利申請案EP 1130609.3中，發明人說明HTTP適應性轉碼器，容許動態轉碼視聽串流，並傳輸到委託器，實施此等HTTP適應性流送協定。EP 1130609.3所述適應性轉碼器，計算資源有限，因此只轉碼至單一或很少數的不同位元率，而更多的可能位元率是在清單組件中通告給委託器。編碼器之目標位元率係按照委託器要求，以動態方式適應，故可維持HTTP適應性輸送之利，亦即動態適應網路和/或終端限制。適應性轉碼器亦稱為轉碼平台。

以HTTP適應性流送言，伺服器必須決定要推薦多少版本內容，和用多少位元率。一方面，可選擇的位元率數愈高，委託器可適應現時網路輸貫量條件更佳，又能維持最佳之可能聲訊和視訊(A/V)品質。另方面，HTTP伺服器通常必須儲存的資料量，視語塊的版本數而定。例如，指提供三種位準1 Mbps、2 Mbps、3 Mbps，意味串流使用資料量為僅需提供最高位元率者的二倍。故提高具有不同位元率之可用版本數，伺服器上的資料載錄，會比內容通常容量快速好幾倍。

以EP 1130609.3所載上述裝置，可飛動式轉碼，不會造成「未要求的」語塊，視聽串流的資料容量無關所擬議位元率數。所以，可大為提高通告位元率數，使委託器立在很準確適應其需要之位置。例如，在1 Mbps至3 Mbps之位元率範圍內，以不同的內容版本間之50 kbps步進規模，即有41種可能位元率，可以通告。公告之位元率組成委託器之節目表。

然而，描述可用位元率集合之清單組件，其規模與擬議的位元率數成比例。當播放靈活串流時，委託器需相當頻繁復新其節目單，包含重新載錄可用位元率之清單組件。故當可用位元率數愈高，以清單組件形式傳輸的描述性資料量，不再比內容位元率小。對於在委託器上運作以處理流送內容之應用，亦增加剖析作業。

本發明便是針對上述清單組件規模之問題。

按照本發明第一要旨，欲解決上述問題，建議一種對委託器(4)提供具有不同位元率的內容串流版本集之方法，包括如下步驟： a.準備清單組件，描述所提供內容串流版本集；b.把清單組件提交給委託器(4)；c.接受委託器(4)要求內容串流，具有特定位元率之一版本；d.把內容串流版本轉碼成委託器(4)所要求之位元率；e.以動態方式選擇提供給委託器(4)的版本之位元率，致使以動態方式適應鄰區版本位元率間之差異；f.重複步驟a至e。

本發明構想在於改進適應性轉碼器，使其基於分佈在現時輸送位元率周圍的位元率值小集合，使用小清單組件。

在有利實施方式中，本方法又包括步驟為，提供內容串流版本集，給單一委託器。

已發現適用的是，方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使鄰區位元率因委託器所要求位元率之變化而定。

同理，已發現適用的是，方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使位元率之差異因委託器如何經常要求不同位元率而定。

在有利具體例中，方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使位元率差異因委託器所要求位元率與現時所接收版本位元率相較變化多大而定。

在另一具體例中，本發明方法又包括步驟為，具備所提供位元率集合，其包括之位元率，隨接近現時所要求位元率，而遞增與鄰區位元率差異。

有利的是，方法又包括步驟為，具備所提供位元率集合，各對鄰區位元率具有同等距離。

在有利實施方式中，方法又包括步驟為，若所要求版本位元率與現時所接受版本位元率相較之差異超過臨限值時，以動態方式適應不同版本的鄰區位元率之步進規模。

按照本發明第二要旨，建議一種系統，供實施本發明之方法。

1‧‧‧系統

2‧‧‧原始

3‧‧‧適應平台

4‧‧‧重製裝置

6‧‧‧解多工器

7‧‧‧解碼器

8‧‧‧分節單位

9‧‧‧編碼器

11‧‧‧分節單位

12‧‧‧多工器

13‧‧‧大量儲存器

14‧‧‧伺服器

21‧‧‧位元率標度

41‧‧‧提供版本之步驟

42‧‧‧準備清單組件之步驟

43‧‧‧提交清單組件之步驟

44‧‧‧要求特定版本之步驟

45‧‧‧選擇位元率之步驟

46‧‧‧環路

第1圖為本發明實施之示意方塊圖；第2a至2c圖為表示所提供版本位元率在不同條件下之曲線圖；第3圖為表示特別情形的位元率之另一曲線圖；第4圖為繪示本發明方法之流程圖。

附圖繪示本發明具體例。

第1圖表示本發明實施系統1之示意方塊圖。系統1包括原始2、適應平台3、重製裝置4。

原始2為流送內容，例如視訊內容之原址。易言之，原始2為流送內容之提供者。例如為家用裝置、輸送任何種家用或預付視訊、或是外部內容提供者、輸送廣播或多元播送視訊(DVB-T、DVB-IPTV等)，或甚至應需服務(VoD服務)之視訊，可以檔案呈現或從網路流送。在第1圖中，原始2所示為提供以DVB和IPTV訊號形式之視聽內容為例。

重製裝置4為商業終端機，或委託器裝置，能夠以不同品質播放聲訊和/或視訊，視其資格和網路條件而定。在本專利申請案中，委託器裝置可為容許使用者連接至伺服器之任何裝置，為使用者下載內容，以可聽可視的方式重製內容。在專利申請案中使用「委託器裝置」和「委託器」為同義詞。於本案HTTP適應性流送之文脈內，重製裝置4亦稱為委託器4。以像HTTP適應性流送之協定為佳，因為容許委託器4要求正要播放之前有妥當品質。

適應平台3具備解多工器6，把進入的內容串流解多工化，若可行，分成分開聲訊和視訊組份。視訊組份在解碼器7內解碼，並在視訊分節單位8內分節。然後，諸節(原始語塊)經轉碼，即在編碼器9內，使用與原址參數不同的參數重新編碼。編碼器9可為H.264編碼器，但其他格式同樣可行。聲訊組份在分節單位11內分裂成諸節(聲訊語塊)亦可轉碼(圖上未示)。然後，聲訊和轉碼視訊組份提供給多工器12。多工器12按照M3U8清單格式，準備清單組件。多工器12在大量儲存器13(檔案)內儲存轉碼和多工化諸節以及清單組件，伺服器14(網路伺服器)，例 如HTTP伺服器，由此轉移諸節之委託器4。

如上所述，本發明特別可用在適應平台3內實施，或具有限制處理能力的轉碼器，例如基於Intel CE4200型處理器，具有基本媒體處理資格之網際網路閘口。

凡技術專家均認知，選用上述具體例內所用H.264寫解碼器和M3U8清單組件，只是說明本發明應用於蘋果委託器所必須。當編碼資源有稀罕，無法並行生產串流全部必要之變通版本時，需要其他解寫碼器之適應性流送實施方式，諸如VC1、WebM和其他清單格式，均同樣有本發明所述益處。

以流送現場視訊情況而言，清單宣告經時變化的語塊集合。變化式之宣告集合亦隨之改變。此用在本發明，以動態方式修飾所擬議變化式集合或所提供版本集合。清單呈現之版本視連接輸貫量的過去變化而更新。換言之，亦可說清單組件內的版本，因應委託器要求而更新，詳後所說明。

由於適應平台3在實際位元率間之連接鬆弛，產生語塊，以及委託器4要求之位元率，尚可自由產生清單。按照本發明，適應平台3選擇下列位元率，有待委託器建議。

適應平台為委託器擬議現時目標位元率，即委託器要求之最後位元率。此點重要，因網路條件安定時，委託器可會聚於最適值，保持要求此值。所以，需要擬議。

適應平台3亦擬議某些位元率，相當靠近現時目標位元率。為了委託器之最適會聚性(最佳可能品質，而停留在正好最大可用帶寬以下)，擬議選項位元率，係由現時接收位元率分開之小步進規模。此舉容許委託器4進行與順暢品質變化之準確適應。此對末端使用者感受的視覺品質具有重要性。

除此之外，適應平台3擬議遠離現時目標之某些其他位元率。網路條件有重大變化情況時，可使委託器4快速適應。

在特別實施例中，假設內容串流之版本，以2 Mbps位元率輸送。則清單提供有如下位元率之版本集合：1 Mbps；1.5 Mbps；1.8 Mbps；1.9 Mbps；1.95 Mbps；2 Mbps；2.05 Mbps；2.1 Mbps；2.2 Mbps；2.5 Mbps； 3 Mbps。

誠然，步進數和步進間隔，可適應系統1之各種參數。

甚至可以動態方式改變步進配置方式，視委託器4之行為而定。當所要求位元率相當穩定時，本發明擬議更多位元率靠近現時輸送版本之一，有很小步進，以及遠比現時所用為少之位元率。當條件變得不穩定時，本發明擬議間隔位元率，在位元率間為正規步進，故委託器可自行歸位於可用位元率範圍內之任何面積。

所述情形如第2a至2c圖所示，表示1 Mbps至3 Mbps範圍內之位元率標度21。直條表示擬議或提供給委託器4之位元率。標度21中途之長直條代表「現時」位元率。第2a至2c圖繪示本發明具體例，擬議有10個選項位元率之版本給委託器4。

第2a圖表示穩定情況之位元率，現時輸送位元率左右有小步進。如第2a圖所示，在1 Mbps和3 Mbps的最低和最高可能之位元率，並未對委託器4擬議。所擬議位元率毋寧跨越更有限範圍，因為在穩定帶寬之假設下，在本具體例中，對諸如1 Mbps或3 Mbps之極端值，委託器不太可能需要變化。

第2c圖表示跨越完全可用範圍的位元率同等間隔集合。當情形不穩定，即使此種位元率選擇，而委託器4即能夠到達可用範圍內之「任何」位元率。

第2b圖表示中間情形，與第2a圖相較之下，擬議的位元率較少聚焦於現時輸送位元率周圍，而是仍然非等距，就像第2c圖。

第2a至2c圖繪示本發明一基本概念，即以動態方式選擇提供給委託器4版本之位元率，得以動態方式適應鄰區版本位元率間之差異。鄰區版本的位元率間之差異，在於第2a至2c圖和第3圖內，相當於直條間之距離。

誠然，擬議之位元率數可以不同，並不衝擊本發明創意，可以在時間上變化。擬議的位元率集合亦不需對稱分配如第2a至2c圖所示。例如，當現時要求之位元率與指定內容的可能範圍相較很低或很高，即會有較少量數值分別低於或高於現時位元率，而較多數更大間隔分別高於或低於現時位元率。

第3圖表示之情形是現時輸送位元率，在可用位元率範圍之上限。因此，全部其他提供之位元率，均低於現時輸送之位元率。

在本發明特別具體例中，使用下述過程：

把通告位元率數設定於11。

為指定內容，決定最小和最大位元率值。最大位元率是視訊具有最佳可能品質，即理想上不用轉碼。在原始2和輸出寫解碼器9之位元率必須不同的情況，則轉碼為強制性，而最大位元率即與原始位元率不同。最小位元率為末端使用者可接受之最低位元率。此相當主觀，視裝置型式(預計HD電視機品質會比行動電話好)和使用者偏好而定。最大位元率(max)和最小位元率(min)間之比，為例如10。

然後，在任一時點，視現時位元率B係最後所要求。啟動時，由轉碼器選擇某初值，一如歐洲專利申請案EP 1130609.3所解釋。此位元率始終包含在通告位元率表單內。對於10個剩餘位元率值，首先決定其數在B之下或之上。此二數分別與(B-min)和(max-B)呈比例，但為最低數至頂值間之概數。意即小的一邊始終至少一值，除非B正好等於最小或最大位元率。例如，若B相當於低端以最小位元率而高端以最大位元率為界限的位元率間距(簡寫成〔min,max〕)值之75%，則7個通告值在B以下，而3個在B以上。若B相當於間距〔min,max〕值之90%，則有9個通告值低於B，而有1通告值高於B。尤其可知，若B相當於間距〔min,max〕值之99%，仍然有9個通告值低於B，和1個通告值高於B。

接著，為了把數值置入各間距，測量委託器4之「穩定性」。為此，輸送內容語塊的網路伺服器14，收集委託器4所要求位元率值。計算對委託器所要求最後20個位元率值集合之標準偏差σ。設N為上述將產生高於B的位元率數。若σ大於(max-B)/N，則要求之不穩定性，需要提供等間隔位元率。否則，使用ρ=(max-B)/(N×σ)，對〔1,N〕(1至N之自然數間距)內使用n，產生n^ρ值(另外寫法：n^ρ)。那些N值乘以(max-B)/n^ρ，加在基本值B，最後降低正確範圍。

同樣演算法容易應用到低於B之值，式內使用B-min取代max-B即可。

須知其他方程式亦可造成所需效果。本發明不限於如何計算 網路穩定性之特別方式。

本發明主要優點是，容許適應性輸送視聽內容，以很大精確性會聚於任何最適值，而不需通告很長表單的選項版本，涵蓋所有可能之位元率。

提供小位元率步進也有幫助，因會降低所要求位元率，與藉有限數之位元率，把語塊預轉碼引進所提供語塊間之差異。例如，若委託器要求具有位元率B之語塊N，適應性轉碼器即準備具有同樣位元率B之語塊N+1，以及具有位元率B之後續語塊N+2。換言之，要求另一位元率發送到適應性轉碼器，和以所要求位元率產生第一語塊之間，有遲延。例如，若委託器需從位元率B改變成較低位元率B'，因而要求具有位元率B'之語塊N+1時，實際上仍然會接收到具有位元率B的語塊N+1和語塊N+2，而非具有位元率B'。轉碼器只編碼具有位元率B'之語塊N+3。

當B和B'間之差異大，發送太多資料之此項遲延，會使委託器緩衝器空乏，導致視訊凍結於委託器4內。理由是因為要接收之語塊較可用帶寬太大，要長時間才到達。於此期間，委託器4會用完所有先前緩衝之資料，並將停止播放，等到其餘資料到達。

提供較小步進，給委託器機會更常變換，但位元率小差異，減少視訊在委託器4內凍結之虞。

建立位元率表單所需計算，在計算動力上所費不多。此小小成本可藉清單組件內傳送給委託器4的容量節省，得以平衡，但亦可限制產生「擬似語塊」的成本，諸如透過大量儲存器13內之象徵性鏈路。可解釋如下：在適應性轉碼器中，當在位元率B產生語塊時，每一位元率創造一檔案，並在清單內發訊。網路伺服器正好必須伺服所要求之檔案。檔案名稱是以語塊數和位元率值建立。而非使用許多儲存空間複製檔案，創造象徵性鏈路，全部指向同一檔案。然而，甚至創造鏈路也要成本，因為是檔案系統呼叫。如果各語塊發生多次，所需計算動力就相當可觀。

須知如果委託器4穩定性變化超過預定臨限值，只有適應平台3所提供版本的位元率集合能適應。在一具體例中，臨限值界定為在預定期限當中，與現時輸送位元率不同的位元率特別要求數。

在另一具體例中，臨限值界定為，所要求位元率與現時輸送 位元率相較之差異。在本發明實施時，會超過一個臨限值。超過一個或數個臨限值，會啟用所提供版本集合的位元率適應。

第4圖繪示本發明方法原理之流程圖。在步驟41，適應平台3提供不同位元率的視聽內容版本，給委託器4。在步驟42，適應平台3亦準備所提供版本之清單組件。在步驟43，適應平台3提交清單組件給委託器4。委託器在步驟44要求特定內容版本。回應委託器4之要求，適應平台3選擇所提供版本之位元率。如上所述，所選擇位元率以委託器4的要求為函數變化與否均可。以環路46為象徵，方法回到步驟41，適應平台3在此提供內容版本集合給委託器4。

本發明系統改進使用者以適應轉碼器所得經驗，方式是容許會聚到接近最適位元率，即面對穩定網路條件時，委託器之穩定行為。所需位元率以上和以下二數值間沒有振盪。

41‧‧‧提供版本之步驟

42‧‧‧準備清單組件之步驟

43‧‧‧提交清單組件之步驟

44‧‧‧要求特定版本之步驟

45‧‧‧選擇位元率之步驟

46‧‧‧環路

Claims (9)

1. 一種對委託器(4)提供具有不同位元率的內容串流版本集之方法，包括如下步驟：a.準備清單組件，描述所提供內容串流版本集；b.把清單組件提交給委託器(4)；c.接受委託器(4)要求內容串流具有特定位元率之一版本；d.把內容串流版本轉碼成委託器(4)所要求之位元率；e.以動態方式選擇提供給清單組件內委託器(4)的版本之位元率，致使以動態方式適應鄰區版本位元率間之差異；f.重複步驟a至e者。
2. 如申請專利範圍第1項之方法，其中方法又包括步驟為，提供內容串流版本集給單一委託器(4)者。
3. 如申請專利範圍第1項之方法，其中方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使鄰區位元率因委託器(4)所要求位元率變化而定者。
4. 如申請專利範圍第3項之方法，其中方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使位元率差異因委託器如何經常要求不同位元率而定者。
5. 如申請專利範圍第3項之方法，其中方法又包括步驟為，以動態方式適應所提供位元率集合內不同鄰區版本間位元率之差異，使位元率差異因委託器所要求位元率與現時所接收版本位元率相較變化多大而定者。
6. 如申請專利範圍第3項之方法，其中方法又包括步驟為，具備所提供位元率集合，其包括之位元率，隨接近現時所要求位元率，而遞增與鄰區位元率差異者。
7. 如申請專利範圍第3項之方法，其中方法又包括步驟為，具備所提供位元率集合，各對鄰區位元率具有同等距離者。
8. 如申請專利範圍第3至5項之一項或數項方法，其中方法又包括步驟為，若所要求版本位元率與現時所接受版本位元率相較之差異超過臨限值時，以動態方式適應不同版本的鄰區位元率之步進寬度者。
9. 一種系統(1)，適於實施前述申請專利範圍一項或數項之方法者。