陳曉峰

（廣州珠江數(shù)碼集團(tuán)有限公司，廣東廣州510010）

OTT傳輸技術(shù)選擇分析

陳曉峰

（廣州珠江數(shù)碼集團(tuán)有限公司，廣東廣州510010）

對互聯(lián)網(wǎng)媒體內(nèi)容傳輸技術(shù)的發(fā)展進(jìn)行了分析，其中重點(diǎn)分析了近期出現(xiàn)的以HTTP為基礎(chǔ)的自適應(yīng)流媒體，包括Microsoft的SmoothStreaming、Adobe的HTTPDynamicStreaming、APPLE的HTTPLiveStreaming以及MPEG-DASH。在部分測試數(shù)據(jù)的基礎(chǔ)上，推論出適合有線網(wǎng)絡(luò)公司的OTT業(yè)務(wù)傳輸技術(shù)。

RTSP；MSS；HDS；HLS；MPEG-DASH；封裝；架構(gòu)

【本文獻(xiàn)信息】陳曉峰.OTT傳輸技術(shù)選擇分析［J］.電視技術(shù)，2015，39（10）.

10年前，全國廣電運(yùn)營商逐步完成數(shù)字電視整體轉(zhuǎn)換；5年前，進(jìn)入高清互動機(jī)頂盒的蓬勃發(fā)展期；近幾年，多個(gè)互聯(lián)網(wǎng)公司推出互聯(lián)網(wǎng)智能機(jī)頂盒搶占家庭娛樂終端，以其海量的視頻內(nèi)容以及豐富的應(yīng)用和開放的安卓操作系統(tǒng)對有線電視造成了不小的沖擊，因此對于傳統(tǒng)的廣電運(yùn)營商而言，如何發(fā)揮自身的優(yōu)勢，如何面對互聯(lián)網(wǎng)機(jī)頂盒的挑戰(zhàn)是擺在所有廣電人面前的巨大課題，廣電人近兩年也開始發(fā)展自身的OTT系統(tǒng)以面對眾多互聯(lián)網(wǎng)公司的挑戰(zhàn)。本文將對互聯(lián)網(wǎng)視頻傳輸技術(shù)做比較分析，以幫助有線網(wǎng)絡(luò)公司找到適合自身發(fā)展的方式。

1　互聯(lián)網(wǎng)視頻傳輸技術(shù)的類型

1.1傳統(tǒng)流媒體

使用RTSP［1］等流媒體傳輸協(xié)議，該協(xié)議本身既可基于TCP傳輸也可基于UDP傳輸。一般來說，其信令通過TCP傳輸，基于UDP傳輸時(shí)通常使用RTP協(xié)議來傳輸數(shù)據(jù)流。服務(wù)器只會發(fā)送部分?jǐn)?shù)據(jù)包去填充客戶端緩沖區(qū)，這個(gè)緩存通常在1～20 s之間。其為一個(gè)有狀態(tài)的協(xié)議，意味著服務(wù)器端可以始終監(jiān)測客戶端的狀態(tài)，客戶端的狀態(tài)會實(shí)時(shí)反映到服務(wù)器端，這對實(shí)時(shí)視頻傳輸非常有優(yōu)勢。類似的協(xié)議還有RTMP等。

1.2漸進(jìn)式下載流媒體

不像傳統(tǒng)流媒體服務(wù)器只能發(fā)送20 s左右數(shù)據(jù)給客戶端，這種方式依據(jù)HTTP方式連接，是一個(gè)無狀態(tài)的協(xié)議，可以根據(jù)請求來發(fā)起連接并下發(fā)數(shù)據(jù)，因此其視頻數(shù)據(jù)可以依據(jù)預(yù)先設(shè)置的狀態(tài)持續(xù)下載，并且可以在任意位置開始播放。

1.3自適應(yīng)流媒體

自適應(yīng)流媒體是一種混合的傳輸技術(shù)，它的傳輸依據(jù)傳統(tǒng)流媒體，但是實(shí)際上是基于漸進(jìn)式下載，并且可根據(jù)終端狀態(tài)進(jìn)行自適應(yīng)碼率調(diào)整。使用標(biāo)準(zhǔn)的HTTP協(xié)議來傳輸數(shù)據(jù)和信息，并不像RTSP使用信帶外協(xié)議傳輸，同時(shí)將HTTP協(xié)議轉(zhuǎn)化成類似RTSP的傳輸協(xié)議。在這種傳輸方式中，視頻內(nèi)容編轉(zhuǎn)碼后被切成無數(shù)小的數(shù)據(jù)切塊，每個(gè)切塊包括完整的GOP組，因此每個(gè)切塊之間既在時(shí)間上互相連續(xù)同時(shí)又相互獨(dú)立（客戶端可以從任意切塊開始播放），通常每個(gè)切塊是2～10 s長。其自適應(yīng)體現(xiàn)在：節(jié)目源會產(chǎn)生多個(gè)不同碼率的視頻流，客戶端依據(jù)和服務(wù)器端的網(wǎng)絡(luò)帶寬和本身設(shè)備的參數(shù)來選擇下載播放合適碼率的視頻流。

2　自適應(yīng)流媒體傳輸主要技術(shù)分析

1）Microsoft的Smooth Streaming（MSS）［2］于2009年發(fā)布，該技術(shù)方案中采用H.264與AAC編碼方案，也支持自己提出的VC-1等編碼方案。Smooth Streaming采用虛擬切片技術(shù)，即每個(gè)碼率的視頻以一個(gè)長文件存儲在服務(wù)器端，在傳輸給客戶端的時(shí)候?qū)⑵湓偾谐尚〉臄?shù)據(jù)塊。該文件在硬盤存儲時(shí)使用較小的數(shù)據(jù)包頭，以便于更快地啟動客戶端播放器。當(dāng)客戶端向服務(wù)器發(fā)起請求時(shí)，服務(wù)器會在文件中尋找合適的碼率文件，并將其取出進(jìn)行切片封裝后傳輸給客戶端。其設(shè)計(jì)原理就是將一個(gè)長的視頻文件切成許多小的文件切片，客戶端播放器只需要按照連續(xù)的邏輯序列下載文件并順序播放即可。

優(yōu)點(diǎn)：相對于其他方案而言，方便的DRM集成是其優(yōu)勢，同時(shí)可以選擇微軟自己的PlayReady方案。

缺點(diǎn)：該方案相對繁復(fù)因此部署起來很費(fèi)時(shí)間，并且客戶端必須嵌入Silverlight，所有客戶端應(yīng)用如解析碼率更換都依賴Silverlight。其服務(wù)端是專有的IIS服務(wù)器并非通用的HTTP服務(wù)器。

2）Adobe的HTTP Dynamic Streaming（HDS）［3］2010年發(fā)布，與微軟的Smooth Streaming相似，由MPEG-4編碼形成切片文件.f4f，包含切片文件說明的索引文件.f4x以及包含DRM信息的.drmmeta。通過.f4x文件索引，指示客戶端播放器從哪一個(gè)切片開始播放。播放器能夠依據(jù)網(wǎng)絡(luò)狀況選擇最合適的碼率。對于內(nèi)容保護(hù)而言，HDS唯一支持的DRM是其自身Adobe DRM系統(tǒng)。

優(yōu)勢：由于RTMP方式的流行，因此支持播放Adobe HDS碼流的設(shè)備非常之多。

缺點(diǎn)：由于在Apple產(chǎn)品中不支持Flash，因此也不支持HDS方式。不同的Android平臺對Flash的支持也不盡相同。HDS只支持自己的Adobe DRM方案，第三方開發(fā)難度較大。

3）APPLE的HTTP Live Streaming（HLS）［4］2009年發(fā)布，到目前為止，HLS可以說是全球應(yīng)用最廣泛的互聯(lián)網(wǎng)電視傳輸協(xié)議，不但自己公司使用，同時(shí)許多機(jī)頂盒也使用了該技術(shù)。HLS主要基于TS流文件進(jìn)行封裝，可以說其對現(xiàn)有的廣播電視系統(tǒng)有更好的兼容性。HLS方案節(jié)目源采用H.264編碼格式，輸出MPEG TS流，切片通常是每片2～10 s，索引文件格式為m3u或m3u8，利用其生成播放文件列表來控制播放器。同樣的，HLS也能夠根據(jù)用戶帶寬的可用性在終端實(shí)現(xiàn)不同碼率的切換，為用戶在不穩(wěn)定的網(wǎng)絡(luò)上提供好的用戶體驗(yàn)，其終端可根據(jù)接收切片文件的時(shí)間長度來選擇最適合的碼率。

優(yōu)點(diǎn)：Apple已經(jīng)出售了大量的iPhone，iPod和iPad，因此HLS技術(shù)有著巨大的市場，特別是針對便攜設(shè)備。HLS在封裝格式上使用MPEG TS技術(shù)，可以和已有的數(shù)字電視系統(tǒng)集成。開發(fā)基于HLS DRM客戶端并不困難，許多公司基于PC平臺的DRM解決方案也可以用于HLS方案。其規(guī)范已提交IETF組織討論，有望成為通用的標(biāo)準(zhǔn)。

缺點(diǎn)：在瀏覽器端沒有集成的HLS，插件需要單獨(dú)開發(fā)。由于封裝使用MPEG TS技術(shù)，會有一定的專利費(fèi)。HLS中對DRM沒有考慮完整支持，采用的是端到端整體加密。

4）MPEG-DASH［5］。2010年，MPEG和ISO組織創(chuàng)立了MPEG-DASH（Dynamic Adaptive Streaming over HTTP）。DASH的技術(shù)目的是標(biāo)準(zhǔn)化HTTP Streaming技術(shù)，以取代目前已經(jīng)存在的技術(shù)方案。DASH方案同樣也包含切片文件和切片索引文件，切片文件采用3GP或MP4的編碼方式。在該方案中切片文件被稱為媒體展示，而切片索引文件被稱為媒體展示描述，媒體展示描述（MPD）包括文件塊索引文件以及其他相關(guān)信息。在播放節(jié)目內(nèi)容時(shí)，其客戶端首先要獲取MPD文件，通過解析MPD文件，客戶端獲知節(jié)目相關(guān)信息和DRM信息以及其他信息，利用這些信息，客戶端選擇合適的碼率進(jìn)行播放。

優(yōu)點(diǎn)：MPEG-DASH在設(shè)計(jì)之初就是要標(biāo)準(zhǔn)化HTTP Streaming技術(shù)，為了更好地將MPEG技術(shù)利用HTTP傳輸，其定義了各種框架場景，并且對直播的支持也描述得非常具體。同時(shí)也是MPEG和ISO推動的標(biāo)準(zhǔn)。

缺點(diǎn)：從現(xiàn)實(shí)來說，采用MPEG-DASH方案的客戶端還比較少，而且MPEG-DASH方案仍然還有許多需要完善的地方。

3　選擇分析

1）以HTTP為基礎(chǔ)的流媒體自適應(yīng)傳輸技術(shù)很好地解決了網(wǎng)絡(luò)帶寬不穩(wěn)定下的節(jié)目穩(wěn)定傳輸，并且從終端上不易察覺。但是，從以上分析中可以看出，此類技術(shù)的共同點(diǎn)都是將一個(gè)連續(xù)的媒體文件切割成小的文件，以便終端可以從眾多的小文件中選擇適合帶寬的文件進(jìn)行播放。從中可以知道當(dāng)終端從不同的碼率跳轉(zhuǎn)的過程中，視頻流的GOP對齊相當(dāng)重要，否則將會產(chǎn)生一個(gè)比較明顯的抖動，如果這是在互聯(lián)網(wǎng)傳輸狀態(tài)下，用戶比較容易接受，但如果發(fā)生在一個(gè)網(wǎng)絡(luò)質(zhì)量很高并且以傳輸質(zhì)量取勝的有線電視網(wǎng)，將會是一個(gè)致命之傷。從實(shí)際已經(jīng)運(yùn)營的IPTV/OTT網(wǎng)絡(luò)中，這個(gè)問題相當(dāng)明顯，有的系統(tǒng)在前端推流和終端優(yōu)化較好的情況下這種抖動不易察覺，但大部分系統(tǒng)依然存在這個(gè)問題。因此建議在有線電視網(wǎng)中應(yīng)首先選擇基于RTSP協(xié)議的流媒體傳輸協(xié)議，雖然其不支持流媒體自適應(yīng)傳輸技術(shù)，但是其良好的傳輸性能在一個(gè)相對穩(wěn)定的有線電視網(wǎng)中更能發(fā)揮其優(yōu)勢，并且不會產(chǎn)生令人討厭的帶寬切換時(shí)的抖動，將來當(dāng)技術(shù)成熟后再考慮放棄RTSP技術(shù)才是一個(gè)明智的選擇，系統(tǒng)預(yù)留將來平滑升級的能力即可。RTSP協(xié)議不切小片，因此其占用系統(tǒng)的帶寬較小，推流服務(wù)器的能力相對會高很多，同時(shí)對網(wǎng)絡(luò)的壓力也較小，更適合系統(tǒng)初期建設(shè)。當(dāng)然系統(tǒng)初期建設(shè)也可以使用流媒體自適應(yīng)傳輸技術(shù)來作為主要的推流方式，但必須做好終端的優(yōu)化，否則其傳輸優(yōu)勢沒有發(fā)揮出來反倒讓劣勢影響到收看效果，那就得不償失了。

2）4種基于HTTP的流媒體自適應(yīng)傳輸技術(shù)的比較列于表1。

表14　種傳輸技術(shù)的對比

MSS只能用于機(jī)頂盒和PC，沒有IOS和Android方案，后續(xù)開發(fā)難度大，并且其技術(shù)繁復(fù)部署復(fù)雜，頭端為IIS服務(wù)器非通用HTTP服務(wù)器，而且客戶端必須嵌入Silverlight，如果不是全方位使用該技術(shù)，建議選擇放棄。

HDS技術(shù)由于有良好的PC支持，并且開發(fā)第三方應(yīng)用簡單，如果推出有關(guān)PC的多屏應(yīng)用，建議選擇HDS方式。當(dāng)然目前也有基于HLS的PC應(yīng)用，由于缺乏插件，從已使用的平臺系統(tǒng)來看其開發(fā)時(shí)間長，后期調(diào)試?yán)щy。

HLS技術(shù)涵蓋機(jī)頂盒、PC、IOS和Android，并且該技術(shù)是基于應(yīng)用最廣泛的MPEG TS流技術(shù)，并且開發(fā)相應(yīng)的DRM方案簡單，毋庸置疑其應(yīng)是OTT平臺首選的傳輸技術(shù)，有線電視內(nèi)網(wǎng)可變碼率，基于其他運(yùn)營商的不確定網(wǎng)絡(luò)，以及多屏的IOS和Android手機(jī)/平板，從目前來看其都有最好的適應(yīng)性。

MPEG-DASH目前處于早期不成熟階段，但其是MPEG和ISO推動的標(biāo)準(zhǔn)，因此有必要保持足夠的關(guān)注，保留系統(tǒng)的升級能力。

3）從以上分析可以發(fā)現(xiàn)，對于不同的終端有不同的最佳封裝協(xié)議，因此前端在編轉(zhuǎn)碼、內(nèi)容采集和注入最好選擇TS over UDP/RTP方式，在封裝設(shè)備中將其打包成合適的封裝以適應(yīng)不同的推流服務(wù)器或CDN。對于內(nèi)網(wǎng)機(jī)頂盒采用RTSP/ RTP或HLS，外網(wǎng)、不確定網(wǎng)絡(luò)、IOS和Android手機(jī)/平板采用HLS方式，對于PC端采用HDS或HLS方式，是目前的最佳選擇?；诮y(tǒng)一的HLS推流方案優(yōu)勢是前端推流方式統(tǒng)一、管理簡單，但終端開發(fā)難度較大、部署周期長；基于RTSP/HLS/ HDS混合推流方案優(yōu)勢是終端開發(fā)難度小，但前端復(fù)雜、管理壓力較大，需要大量的封裝設(shè)備同時(shí)占據(jù)更大的機(jī)房空間。不同的網(wǎng)絡(luò)公司可依據(jù)自身的技術(shù)特點(diǎn)和業(yè)務(wù)發(fā)展需求選擇不同的推流架構(gòu)。

4）為適應(yīng)不同的終端采用編轉(zhuǎn)碼和封裝設(shè)備分開，這不僅是OTT技術(shù)架構(gòu)的需要，同時(shí)也會有很多其他的優(yōu)點(diǎn)。首先采用編轉(zhuǎn)碼和封裝設(shè)備分開的架構(gòu)后，編轉(zhuǎn)碼設(shè)備將只用于視音頻處理功能，可采用ASIC來處理，這樣不僅可以提高設(shè)備密度節(jié)省機(jī)房資源，同時(shí)可以提高設(shè)備的穩(wěn)定性，降低功耗；對于封裝設(shè)備不需要處理編轉(zhuǎn)碼而只需處理和封裝相關(guān)的功能，同樣也會增加系統(tǒng)的處理能力和穩(wěn)定性。OTT技術(shù)是一個(gè)不斷發(fā)展完善的技術(shù)，編轉(zhuǎn)碼和封裝功能分開可以使得封裝設(shè)備能夠適應(yīng)將來技術(shù)的發(fā)展而更新變化，比如不同CDN或者不同的DRM技術(shù)，而無需更換編轉(zhuǎn)碼設(shè)備。當(dāng)設(shè)備需要維護(hù)時(shí)，同樣編轉(zhuǎn)碼和封裝設(shè)備互不干擾，當(dāng)更換封裝方式以適應(yīng)不同的推流服務(wù)器或CDN時(shí)無需更換編轉(zhuǎn)碼器，反之更換編轉(zhuǎn)碼器時(shí)也無須更換封裝設(shè)備，這樣整體架構(gòu)清晰，系統(tǒng)維護(hù)簡單，大大地提高了系統(tǒng)的穩(wěn)定性。當(dāng)編轉(zhuǎn)碼和封裝設(shè)備分開后，編轉(zhuǎn)碼可采用硬件編碼方式，有利于提高設(shè)備穩(wěn)定性和處理能力，而封裝設(shè)備的軟件升級等等也不會影響到編轉(zhuǎn)碼設(shè)備。由于編轉(zhuǎn)碼設(shè)備沒有封裝輸出，因此編轉(zhuǎn)碼設(shè)備可以和原有的互動平臺設(shè)備共用，有利于節(jié)省系統(tǒng)投資，提高維護(hù)效率。

5）基于HTTP的流媒體自適應(yīng)傳輸技術(shù)在傳輸中都是切片進(jìn)行傳輸?shù)?，切片一方面是為了傳輸方便，不是一次性下載大的文件就可以順利播放；另一方面終端接收更容易在不同的碼率之間進(jìn)行切換，終端僅需保存較小的切片緩存就可以在當(dāng)前網(wǎng)速下選擇另外更適合的播放帶寬。因此切片大小的選擇也是一個(gè)關(guān)鍵參數(shù)，一般來說切片越小越有利于在不同碼率間轉(zhuǎn)換，但過小的切片也會造成終端緩存過少而無法完成這個(gè)切換（緩存過少播放器的可播放時(shí)間不足以下載較大碼率的切片），實(shí)際測試會發(fā)現(xiàn)5 s左右的切片更有利于動態(tài)碼率切換的完成。

6）再完美的傳輸方案遇到不穩(wěn)定的網(wǎng)絡(luò)都會出現(xiàn)傳輸誤碼，由于網(wǎng)絡(luò)傳輸丟包會導(dǎo)致黑屏馬賽克等問題，因而要參考文獻(xiàn)：

采用ARQ（Automatic Repeat-reQuest）來解決網(wǎng)絡(luò)丟包問題。ARQ雖然通過重傳能夠解決一定的問題，但同時(shí)也會浪費(fèi)傳輸帶寬，首先傳輸不能使用全部帶寬，其次當(dāng)出現(xiàn)錯(cuò)誤時(shí)終端請求以及重傳都會對網(wǎng)絡(luò)造成不小的浪費(fèi)，因此更建議選擇FEC的方式解決傳輸問題。FEC只占用很少帶寬卻能夠解決絕大部分傳輸問題。對于網(wǎng)絡(luò)傳輸不穩(wěn)定流量控制也是必不可少的技術(shù)，一方面可以減輕網(wǎng)絡(luò)不穩(wěn)定的壓力，同時(shí)也可以解決編碼源的不穩(wěn)定造成的終端緩存溢出。

［1］NetworkWorkingGroup.RFC2326［EB/OL］.［2015-01-07］.http：// www.ietf.org/rfc/rfc2326.txt.

［2］Microsoft.［MS-SSTR］：SmoothStreamingProtocol［EB/OL］.［2015-01-02］.https：//msdn.microsoft.com/en-us/library/ff469518. aspx.

［3］Adobe.Hds-dynamic-streaming［EB/OL］.［2015-01-07］.http：// www.adobe.com/products/hds-dynamic-streaming.html.

［4］PANTOS R.Http live streaming［EB/OL］.［2015-01-07］.http：//tools. ietf.org/html/draft-pantos-http-live-streaming-14.

［5］DASH.Guidelines for implementation：DASH-IF interoperability points［EB/OL］.［2015-01-07］.http：//dashif.org/wp-content/uploads/ 2015/04/DASH-IF-IOP-v3.0.pdf.

OTT Transmission Technology Selection Analysis

CHEN Xiaofeng
（Guangzhou Digital Media Group Co.，Ltd.，Guangzhou 510010，China）

Through analyzing the development of the Internet media transmission technology，which focuses on the recent emergence of HTTP based adaptive Streaming media，including Microsoft Smooth Streaming，Adobe HTTP Dynamic Streaming，APPLE HTTP Live Streaming and MPEG-DASH，in part，on the basis of test data，infer OTT business transmission technology for cable companies.

RTSP；MSS；HDS；HLS；MPEG-DASH；encapsulation；architecture

TN913

A

10.16280/j.videoe.2015.10.018

閆雯雯

2015-01-07

陳曉峰（1973—），工程師，主要從事數(shù)字電視播出、傳輸和接收技術(shù)、接入網(wǎng)技術(shù)以及OTT系統(tǒng)技術(shù)研究。