互聯(lián)網(wǎng)智能電視技術(shù)方案分析

互聯(lián)網(wǎng)電視技術(shù)方案分析與比較夏勇（國家廣電總局廣播科學(xué)探討院互聯(lián)網(wǎng)技術(shù)探討所）

摘要：互聯(lián)網(wǎng)電視作為一種新的內(nèi)容服務(wù)方式正在快速發(fā)展。本文具體介紹了互聯(lián)網(wǎng)內(nèi)容傳輸技術(shù)發(fā)展歷史，總結(jié)了互聯(lián)網(wǎng)內(nèi)容傳輸技術(shù)的三種方式。并針對目前國外主要的4種互聯(lián)網(wǎng)電視技術(shù)方案進行了分析，重點探討了其中的關(guān)鍵內(nèi)容，優(yōu)勢和不足。關(guān)鍵字:互聯(lián)網(wǎng)電視流媒體傳輸方案

1．互聯(lián)網(wǎng)內(nèi)容傳輸方式的轉(zhuǎn)變在幾年以前流媒體傳輸領(lǐng)域就出現(xiàn)了一種發(fā)展趨勢，流媒體傳輸由傳統(tǒng)的RTSPMMSRTMP等協(xié)議在線服務(wù)向純粹的下載轉(zhuǎn)變?，F(xiàn)在已經(jīng)有很多視頻網(wǎng)站采納傳輸方案進行媒體內(nèi)容的傳輸，形成這種轉(zhuǎn)變主要有以下幾個理由：CDN以及服務(wù)器主機供應(yīng)的網(wǎng)頁下載服務(wù)比傳統(tǒng)的媒體流服務(wù)要便宜；傳統(tǒng)的媒體傳輸協(xié)議通常很難穿過防火墻或是路由器，因為它們主要是基于UDP協(xié)議不定端口傳輸，而協(xié)議沒有這個問題，基于80固定端口，網(wǎng)絡(luò)設(shè)備對80端口默認支持；方式媒體傳輸不須要特殊的緩存或代理；通過封裝將數(shù)據(jù)傳給用戶比其他方式更加便利及便宜；即使流媒體傳輸協(xié)議是設(shè)計用來特地傳輸媒體的，但事實上是互聯(lián)網(wǎng)是基于方式來建設(shè)和優(yōu)化的。這便產(chǎn)生了一個好玩的問題，“為什么要整個互聯(lián)網(wǎng)去適應(yīng)媒體傳輸，而不是讓媒體傳輸適應(yīng)互聯(lián)網(wǎng)”。

2．互聯(lián)網(wǎng)內(nèi)容傳輸三種形式互聯(lián)網(wǎng)上媒體傳輸主要有三種類型：傳統(tǒng)流媒體、漸序性下載及自適應(yīng)流媒體傳輸。2.1

傳統(tǒng)流媒體RTSP協(xié)議是一個典型的流媒體傳輸協(xié)議，也是一個有狀態(tài)的協(xié)議。有狀態(tài)的意思是指從客戶端連接上流媒體服務(wù)器的那一刻起，始終到客戶端斷掉與流媒體服務(wù)器端的連接，流媒體服務(wù)器始終保持著與客戶端的連接狀態(tài)?？蛻舳送ㄟ^play、pause、teardown等吩咐來與流媒體服務(wù)器進行通信。在客戶端和服務(wù)器端建立連接之后，服務(wù)器端起先穩(wěn)定發(fā)送小數(shù)據(jù)格式的媒體流，傳輸協(xié)議通常采納RTP協(xié)議，RTP數(shù)據(jù)包是1452字節(jié)，這就意味著在一個1Mbps視頻流中，每個數(shù)據(jù)包包含大約11毫秒的節(jié)目。RTSP協(xié)議既可以基于UDP傳輸也可以基于TCP傳輸。UDP比TCP更簡單被防火墻或代理服務(wù)器阻隔，但是TCP簡單產(chǎn)生延遲。

從另一個方面來說，是一個無狀態(tài)的協(xié)議。假如客戶端懇求數(shù)據(jù)，那服務(wù)器端會剛好響應(yīng)，但是服務(wù)器不會記住客戶端的狀態(tài)，每個懇求都是在一個時間會話中獨立處理。無狀態(tài)協(xié)議很難干脆應(yīng)用在媒體流傳輸上。WindowsMediaService運用改進版本的協(xié)議，MS-WMSP協(xié)議作為微軟媒體傳輸?shù)幕A(chǔ)協(xié)議。MS-WMSP運用標準的協(xié)議來傳輸數(shù)據(jù)和信息，同時也為此會話狀態(tài)，有效的將協(xié)議轉(zhuǎn)化成類似RTSP的傳輸協(xié)議。類似RTSP和WindowsMedia傳統(tǒng)流媒體協(xié)議有兩點比較重要：服務(wù)器向客戶端實時發(fā)送數(shù)據(jù)包，媒體流的碼率在編碼時被確定。例如：一個視頻節(jié)目被編碼成500Kbps的碼流，那么傳輸?shù)娇蛻舳说拇a率大約也是500kbps。服務(wù)器只會發(fā)送部分未播放節(jié)目的數(shù)據(jù)包去填充客戶端緩沖區(qū)。通常，客戶端的緩存區(qū)是1秒到10秒之間。這就意味著，假如你暫停一個節(jié)目流10分鐘，在這段時間內(nèi)大約只有5秒鐘的節(jié)目被下載到客戶端。2.2漸序性下載另一種通常的互聯(lián)網(wǎng)媒體傳輸形式是漸序性下載，它本質(zhì)上和從網(wǎng)頁服務(wù)器上下載一個文件差不多。大多數(shù)的播放器和媒體傳輸平臺支持漸序性下載，漸序性來自于大多數(shù)播放器允許媒體文件回看，而后臺同時也在下載節(jié)目。支持1.1的客戶端能夠定位到未下載完整的文件位置。目前流行的視頻共享網(wǎng)站包括：YouTube、Vimeo、Myspace、MSN都支持漸序性下載。不像傳統(tǒng)流媒體服務(wù)器很少能在一個時間段內(nèi)夠發(fā)送超過10秒媒體數(shù)據(jù)給客戶端，網(wǎng)頁服務(wù)器能夠保證持續(xù)的節(jié)目數(shù)據(jù)傳輸直到整個文件下載完成。即使客戶端在回看時暫停節(jié)目播放，節(jié)目數(shù)據(jù)依舊會持續(xù)下載到閱讀器的緩存中，保證用戶能有良好的收看體驗。這種方式也有它的問題，假如客戶端找30秒內(nèi)下載完成了10分鐘的節(jié)目，而用戶只觀看了30秒鐘的節(jié)目就退出觀看，那就奢侈了9分30秒的帶寬資源。為了解決這個問題，微軟IIS7.0提出了一個名為“BitRateThrolling”的技術(shù)，它能夠限制流媒體服務(wù)器的內(nèi)容傳輸速率，以達到削減帶寬奢侈的目的。2.3為基礎(chǔ)的流媒體自適應(yīng)傳輸為基礎(chǔ)的流媒體自適應(yīng)傳輸是一種混合型的傳輸方式，它的傳輸動作類似流媒體，但是事實上是基于漸序性下載。為基礎(chǔ)的自適應(yīng)流媒體傳輸?shù)暮锰幨沁\用了已有的協(xié)議而不是去開發(fā)一個新的傳輸協(xié)議。微軟提出的SmoothStreaming和移動網(wǎng)絡(luò)自適應(yīng)碼流傳輸都是為基礎(chǔ)的自適應(yīng)流媒體傳輸?shù)膽?yīng)用實例，該技術(shù)能夠?qū)崿F(xiàn)持續(xù)的小數(shù)據(jù)的下載，而不是一個大文件的連續(xù)下載。在典型的為基礎(chǔ)的自適應(yīng)流媒體傳輸方案中，音視頻節(jié)目被編碼成很多小的數(shù)據(jù)片，這些小的數(shù)據(jù)片組成一個數(shù)據(jù)塊，一個數(shù)據(jù)卡通常是2～4秒長。從編碼技術(shù)角度，一個數(shù)據(jù)塊正好就是一個GOP的大小，每個GOP里有一個關(guān)鍵幀，每個數(shù)據(jù)塊或GOP的解碼都是獨立不依靠其他的數(shù)據(jù)塊或GOP。碼流自適應(yīng)技術(shù)有幾個共同的技術(shù)特點，第一，它從同一個源產(chǎn)生多個不同碼率的節(jié)目流以適應(yīng)不同的帶寬和不同的設(shè)備類型。其次.自適應(yīng)分發(fā)文件以及碼流傳輸?shù)淖兏际沁m應(yīng)有效網(wǎng)絡(luò)吞吐量和可用的CPU資源。第三：全部的操作對用戶都是透亮的，節(jié)目流的切換都在后臺進行，用戶很難留意到節(jié)目流的變更。同時，碼流自適應(yīng)技術(shù)運行特點也是相像的，當然也有幾點關(guān)鍵不同點，相同點是全部的碼流自適應(yīng)技術(shù)都有幾個相關(guān)的關(guān)鍵參考參數(shù)，例如：視頻緩存區(qū)狀態(tài)、網(wǎng)絡(luò)有效吞吐量、CPU利用率以及丟幀后消耗的計算資源等，這些參數(shù)確定了何時去變更碼流。不同廠家的在碼流自適應(yīng)技術(shù)一個關(guān)鍵的不同就在是否部署流服務(wù)器上。一種設(shè)計方案是由流服務(wù)器來實現(xiàn)不同碼率節(jié)目的切換，而另一種則沒有碼流服務(wù)器，而是同時部署多個網(wǎng)頁服務(wù)器或利用一臺網(wǎng)頁服務(wù)器來供應(yīng)不同碼率節(jié)目的傳輸，而用戶端的設(shè)備通過監(jiān)視終端CPU利用率、緩存區(qū)狀態(tài)等參數(shù)以確定何時在不同的碼率節(jié)目見切換。

自適應(yīng)流媒體傳輸相對與傳統(tǒng)流媒體傳輸具有以下幾個優(yōu)點：（1）由于該技術(shù)方案能夠充分利用廣泛存在基礎(chǔ)環(huán)境，它實施起來成本更低；（2）它具備了更好的伸縮性和可達性，削減了最終一英里帶來的問題；（3）它能夠讓觀眾有更好的體驗，而不須要內(nèi)容供應(yīng)商或運營商去揣測用那種碼率傳輸更適合觀眾；對用戶而言它同樣具有以下幾個優(yōu)點：（1）快速播放以及拖動，因為播放或拖動節(jié)目都是在低碼率下完成，等動作完成后客戶端會主動切換到高碼率上去；（2）沒有緩沖等待、沒有鏈接中斷、沒用回看停頓；（3）平滑的在不同碼率節(jié)目間切換；目前，不同的IT、軟件已經(jīng)互聯(lián)網(wǎng)企業(yè)已經(jīng)看到了將來互聯(lián)網(wǎng)電視發(fā)展趨勢，紛紛推出自己的解決方案，以下主要想介紹Apple、Microsoft、Adobe以及MPEG組織的互聯(lián)網(wǎng)電視技術(shù)方案。

3．APPLEHLS3.1.1

發(fā)展歷史Apple公司首次在2009年IOS3.0中集成了HLSLiveStreaming技術(shù)，截止到今日HLS是全球應(yīng)用最廣發(fā)的互聯(lián)網(wǎng)電視傳輸技術(shù)協(xié)議，該技術(shù)被廣泛應(yīng)用到Apple公司產(chǎn)品終端和機頂盒中。在2010年9月1日，StevenJobs報告中公開介紹了基于HLS的直播技術(shù)，同時宣布了APPLETV2。IPAD的勝利很大程度上適合了用戶運用IPAD看視頻的須要。MeFeedia公司一向探討報告表明IPAD用戶在線看視頻時間長度是傳統(tǒng)視頻網(wǎng)站用戶的三倍。3.1.2

關(guān)鍵技術(shù)點HLS主要基于TS的視頻流或文件進行封裝傳輸，HLS類似一個容器封裝MPEGTS傳輸格式。TS是廣播電視行業(yè)中采納的節(jié)目傳輸格式。HLS編解碼采納MPEG-4或H.264，音頻采納AAC。這樣技術(shù)路途使得APPLE可以運用成熟工業(yè)標準，將其應(yīng)用在互聯(lián)網(wǎng)電視技術(shù)方案上幾乎不須要改動，對現(xiàn)有標準兼容的越好，HLS便可以更快進入到產(chǎn)業(yè)鏈中。

HLS方案主要技術(shù)特點：（1）節(jié)目源采納H.264/TS編碼格式，可變碼率；運用流切片技術(shù)將一個完整的節(jié)目切成若干小片，通常是10秒每片，同時運用m3u或m3u8格式生成播放列表文件用來指導(dǎo)播放器如何播放文件切片；（2）通過Server分發(fā)節(jié)目，同時供應(yīng)合適的緩存。HLS技術(shù)另外一個優(yōu)勢是能夠?qū)崿F(xiàn)動態(tài)自適應(yīng)碼率傳輸。相對于移動流媒體RTP傳輸技術(shù)，HLS能夠依據(jù)終端用戶帶寬的可用性在終端而不是在前端視頻服務(wù)上，實現(xiàn)對碼率的切換。這種實現(xiàn)方式是為用戶在無保障的網(wǎng)絡(luò)上供應(yīng)好的用戶體驗。（3）索引文件說明白在同一個頻道或文件中不同碼率節(jié)目流的對應(yīng)性；（4）終端依據(jù)接收切變文件的時間長度來選擇最合適的碼率；（5）每個切片文件最長10秒，所以接收設(shè)備可以自動適應(yīng)碼率變更；開發(fā)基于HLSDRM客戶端并不困難，Verimatrix,

Widevine,NDS,Latens與SecureMedia一些DRM公司基于PC平臺的DRM解決方案也可以適應(yīng)HLS方案。假如進一步探討HLS中的DRM技術(shù)，會發(fā)覺HLS只是描述了如何利用128位AES算法加擾HLS流，并沒有說明如何從DRM密鑰服務(wù)器中獲得密鑰。這就說明DRM與HLS之間并不完全兼容。3.1.4

優(yōu)勢截至到2011年9月，APPLE已經(jīng)出售了13億臺IPHONE，6千萬臺IPODTouch，以及超過3千萬臺IPAD，因此HLS技術(shù)有著巨大的市場，特殊是針對便攜設(shè)備。HLS為不行靠的開放網(wǎng)絡(luò)供應(yīng)了一種有效的碼率自適應(yīng)方案。HLS運用成熟的H.264編解碼技術(shù)，目前H.264解碼芯片供應(yīng)商有很多。HLS基于TS技術(shù)，使得它可以很簡單集成到已有的數(shù)字電視系統(tǒng)中，很多IPTVDRM方案供應(yīng)商能夠供應(yīng)相應(yīng)的解決方案。3.1.5

不足自適應(yīng)技術(shù)方案只限制在用戶端，這種動態(tài)方法可能限制某些專業(yè)用戶希望能夠自己對特殊內(nèi)容傳輸進行微調(diào)和限制；APPLE并沒有支持主要閱讀器集成HLS，缺乏插件使得利用WebTV收看HLS節(jié)目變得困難；HLS主要運用MPEG標準，兼容HLS技術(shù)的設(shè)備可能須要向MPEGLA支付肯定的專利費。HLS中DRM加密采納是端到端整體加密實現(xiàn)，這樣降低了系統(tǒng)的敏捷性；目前，HLS只能供應(yīng)一個音軌在一個視頻流中。IOS5能夠供應(yīng)可切換的音軌，但是音軌數(shù)量被限制在2個，而在SmoothStreaming或MPEG-DASH中則對音軌的數(shù)量沒有限制。3．2

MicrosoftSmoothStreaming3.2.1

發(fā)展歷史微軟在1998年在NetshowService和WindowsMediaPlayer6.1中首次采納了依據(jù)客戶端狀態(tài)自適應(yīng)節(jié)目傳輸碼率的“streamthinning”的技術(shù)。該技術(shù)通過自動檢測終端網(wǎng)絡(luò)狀況，自動削減幀率。在網(wǎng)絡(luò)條件比較惡劣的狀況下，客戶端可能會終止整個視頻的播放而只是播放聲音。最早的多碼率媒體流傳輸時在Microsoft2000中，作為WindowsMediaTechnology4.0和WindowsMediaService4.1服務(wù)的一部分，和WindowsMediaPlayer6.4一起發(fā)布的。在2002年，微軟在WindowsMedia9系列產(chǎn)品中引入了“IntelligentStreaming”。IntelligentStreaming依舊采納ASF封裝格式，但是在該技術(shù)的設(shè)計上，它將帶寬偵測、streamingthinning、MBR以及更好的圖像處理結(jié)合起來。隨著技術(shù)發(fā)展，微軟在2009年發(fā)布MicrosoftSmoothStreaming是Silverlight3.0相關(guān)標準。Microsoft在它的技術(shù)方案中采納H.264與AAC編碼方案，也能夠支持微軟自己提出的WMA與VC-1或者能夠支持3GP封裝支持的編碼方案。

關(guān)鍵技術(shù)點IIS采納MPEG-4Part14標準格式作為其文件存儲格式以及傳輸封裝格式。SmoothStreaming方案中定義每個文件塊/GOP作為一個MPEG-4電影幀，并將其存儲在一個聯(lián)系的MP4文件中以利于系統(tǒng)讀取。一個MP4文件編碼成一個碼率。當客戶端從IIS網(wǎng)頁服務(wù)器上懇求一個特點時間片段的節(jié)目源時，服務(wù)器將動態(tài)聯(lián)系的MP4文件中找尋合適的電視幀單元（BOX），并且將它作為一個獨立的文件發(fā)送。換句話說，SmoothStreaming方案中文件塊是在服務(wù)器端接收到客戶端懇求時產(chǎn)生的，在服務(wù)存儲中視頻內(nèi)容是以一個完整的單一碼率文件形式存在。（1）SmoothStreaming流格式介紹SmoothStreaming格式涉及兩個部分，封裝格式和硬盤存儲格式。SmoothStreaming中視頻作為一個單一碼率文件完整的存儲在硬盤中，在傳輸給客戶端的時候會轉(zhuǎn)換成很多小的文件數(shù)據(jù)塊。封裝格式是用來傳輸時運用，而文件格式用來描述文件在硬盤的存儲格式。MP4允許文件以一系列片結(jié)構(gòu)組織及存儲，這就意味著SmoothStreaming封裝格式是文件存儲格式的子集。（2）SmoothStreaming文件硬盤存儲格式MP4文件的基本單位是“BOX”。這些“BOX”中即包含數(shù)據(jù)也包含元數(shù)據(jù)。MP4支持在一個文件內(nèi)容以不同的方式來組織數(shù)據(jù)和元數(shù)據(jù)。在大多數(shù)媒體場景中，將元數(shù)據(jù)放在負載數(shù)據(jù)之前對于播放器的讀取時非要有用的，因為播放器可以在播放之前可以更多的知道負載數(shù)據(jù)信息。然而，不太可能在整個數(shù)據(jù)流前寫入元數(shù)據(jù)。較少的元數(shù)據(jù)信息意味著小的數(shù)據(jù)包頭，有利于更快的啟動播放器。基于以上理由MP4文件格式中允許存在一系列曉得元數(shù)據(jù)、負載數(shù)據(jù)對，而不是一個長的元數(shù)據(jù)/負載數(shù)據(jù)對。下圖描述了在一個SmoothStreaming文件中文件組織格式：

從上圖中我們能看到在一個外殼中，文件以文件元數(shù)據(jù)信息（moov）起先，但是負載帶元實際包含在片BOX單元中，在這些BOX中又攜帶了精確的文件片元數(shù)據(jù)（moof）和媒體數(shù)據(jù)（mdat），格式以mfra索引BOX結(jié)束。（3）SmoothStreaming文件封裝格式當一個播放器客戶端向IIS服務(wù)器懇求一個視頻時間片段時，服務(wù)器會在MP4文件中找尋合適的文件片，并將其取出封裝完成后傳輸給客戶端。文件片經(jīng)過封裝后可以有效提高傳輸效率。下圖描述了一個MP4文件片封裝結(jié)構(gòu)

微軟在MP4ISO媒體文件描述格式的基礎(chǔ)上自定義了BOX組織數(shù)據(jù)結(jié)構(gòu)和BOX信息。為了區(qū)分SmoothStreaming文件和標準的“vanilla”MP4文件格式，微軟運用了新的文件擴展：*.ismv(視頻和音頻)和*.isma音頻（4）SmoothStreaming播放SmoothStreaming自適應(yīng)播放的設(shè)計原理本質(zhì)上是將一個長的視頻文件切成很多小的文件片。為了從Web服務(wù)器中獲得這些文件片，客戶端播放器只須要依據(jù)連續(xù)的邏輯序列0001.vid0002.vid0003.vid…下載文件即可。在SmoothStreaming的設(shè)計方案中，微軟運用了更加困難的設(shè)計。視頻文件不須要被切成多數(shù)小的文件片，而只是在傳輸時依據(jù)文件片的方式傳輸，而這些文件片事實上來自MP4文件中的GOP片段。這樣的設(shè)計須要在服務(wù)器端和客戶端實現(xiàn)以下兩點變更：服務(wù)器必需能將URL轉(zhuǎn)換成在MP4文件中的精確的偏移范圍；（5）客戶端能夠支持更加開放的懇求格式；客戶端播放器首先從SmoothStreaming服務(wù)器上獲得*.ismc客戶端文件塊索引文件文件。該文件告知播放器節(jié)目內(nèi)容的編碼格式、碼率、清楚度以及可用數(shù)據(jù)塊列表。在SmoothStreaming中客戶端懇求文件數(shù)據(jù)塊的URL以以下方式描述：://video.foo/NBA.ism/Qualitylevels(400000)/Freaments(video=610275114)在以上URL中出現(xiàn)的數(shù)字分別代表了編碼碼率和在一個單位時間段內(nèi)（通常是100ns）片段起先位置的偏差值。在服務(wù)器端收到客戶端懇求后，SmoothStreaming在服務(wù)器文件塊索引文件文件中查找碼率，并找尋對應(yīng)的.ismv.isma文件。然后基于tfra索引單元（BOX）找到相應(yīng)片段（moof+mdat）和起先時間偏差值，讀取相關(guān)的MP4文件封裝后發(fā)送給客戶端。這個部分的設(shè)計對于整個傳輸設(shè)計是至關(guān)重要的?？蛻舳讼螺d的內(nèi)容會在網(wǎng)絡(luò)中自動緩存，假如其他的客戶端懇求了同樣的內(nèi)容便會從緩存中獲得這樣就大大節(jié)約了服務(wù)端的壓力。3.2.3

優(yōu)勢SmoothStreaming在一個碼流中能夠支持多聲道和多個主題。這為用戶供應(yīng)了與收看數(shù)字廣播想同的體驗。相對于其他互聯(lián)網(wǎng)電視方案而言，SmoothStreaming已經(jīng)將DRM很好的集成到其中。雖然，微軟也有自己的PlayReady解決方案，它也明確的支持其他的DRM廠家與SmoothStreaming的集成。在網(wǎng)頁媒體領(lǐng)域，SmoothStreaming在高清直播中獲得了很好的圖像質(zhì)量，與以flash技術(shù)為基礎(chǔ)的視頻網(wǎng)站相比，Silverlight能夠依據(jù)客戶端的解碼實力去選擇合適的節(jié)目碼率進而保證節(jié)目的流暢。對于微軟的互聯(lián)網(wǎng)電視方案來說，這可能是一個優(yōu)勢也可能是一個劣勢，微軟互聯(lián)網(wǎng)電視技術(shù)方案說明特別具體，運用了很多例子進行說明，這使得技術(shù)人員很簡單理解該方案，但是可能會花很多時間進行部署。3.2.4

不足正如上文提到的，微軟的互聯(lián)網(wǎng)電視方案特別具體，所以部署起來很費時間，結(jié)果是該方案不如HLS那樣簡單被接受。盡管SmoothStreaming以Web媒體為目標，但是客戶端必需嵌入Silverlight，剛好是IE閱讀器也必需安裝額外的插件。像HLS一樣，SmoothStreaming不能依靠網(wǎng)絡(luò)中心服務(wù)器來管理帶寬，這些工作必需依靠客戶端設(shè)備。3．3

AdobeDynamicStreaming3.3.1

發(fā)展歷史假如我們回看本世紀初起先整個互聯(lián)網(wǎng)視頻傳播的發(fā)展歷史，我們會發(fā)覺Adobe毫無疑問是其中的主要貢獻者，很多知名網(wǎng)站如：YouTube、Dailymotion、Hulu以及成百上千的視頻網(wǎng)站都運用了Adobe的方案。然后，大多是視頻采納的是.FLV格式（不是直播流媒體），無法支持DRM,也不支持碼率自適應(yīng)。AdobeFlash在1996年發(fā)布，依據(jù)Adobe公司的報告，在2010年全美98%的網(wǎng)頁運用者運用FlashPlayer。然后第一個能夠播放視頻段的Flashpayer是version6.在2010年七月，Adobe發(fā)表了互聯(lián)網(wǎng)電視方案，支持碼率自適應(yīng)機制，支持直播，支持Adobe自己的FlashAccessDRM方案。3.3.2

關(guān)鍵技術(shù)點從技術(shù)角度來看，HDS方案與微軟的SmoothStreaming特別相像，HDS系統(tǒng)主要由以下幾個部分組成：一個以XML為基礎(chǔ)的索引文件.f4m包含MPEG-4編碼格式內(nèi)容的片文件.f4f包含切片文件說明信息的索引文件.f4xHDS支持H.264以及VP6視頻編碼格式，AAC和MP3音頻編碼格式。.f4m文件塊索引文件文件包好一個bootstrap，它相對于MPEG-DASH的初始化段，這能夠指示終端播放器從哪一個片起先解碼。在文件塊索引文件中，假如有多種碼率可選，播放器能夠依據(jù)內(nèi)容回看效果選擇最合適的碼率。播放器是用ActionScript語言編寫，能夠運行在Flash或者AdobeAIR框架下。Adobe供應(yīng)了一個參考視頻播放器，稱為OpenSourceMediaFramework（OSMF），在互聯(lián)網(wǎng)上已經(jīng)有一些flash/javascript播放器基于這種方式編寫，這些播放器基本上是完全定制化播放HDS視頻流。對于內(nèi)容愛護而言，HDS唯一支持的DRM方案是其自身AdobeDRM系統(tǒng)，F(xiàn)lashAccess服務(wù)器，F(xiàn)lashAccess方案是一個很有特點的加擾系統(tǒng)，版權(quán)管理中有很敏捷的限制權(quán)，它能夠?qū)圩o層進行愛護也能夠?qū)σ曨l文件切片進行愛護。3.3.3

優(yōu)勢Adobe勝利在月在互聯(lián)網(wǎng)早期發(fā)展過程中將其框架作為一種強制插件嵌入到網(wǎng)頁中。同時，F(xiàn)lash插件到今日已經(jīng)有實力自動更新，現(xiàn)在幾乎全部的PC都能播放AdobeHDS碼流。HDS在Adobe為VOD應(yīng)用供應(yīng)了豐富的文檔，他們能夠為開發(fā)送人供應(yīng)一些參考源代碼以支持對方開發(fā)有價值的第三方插件。3.3.4

不足Apple目前在Apple產(chǎn)品中不支持Flash。但是對于Android平板電腦和智能手機，F(xiàn)lash的支持特別依靠具體的Android版本，即使是特定Android版本，F(xiàn)lash支持也依靠硬件平臺廠家。HDS只支持自己的DRM方案，從Adobe開放出來的文檔中也很難看出FlashAccess是如何工作的，尤其是直播應(yīng)用。和AppleHLS一樣，HDS碼流目前只能供應(yīng)一個音軌。在改進版的系統(tǒng)中對于點播節(jié)目能夠供應(yīng)可替換音軌，但是直播節(jié)目不具備這個功能。3．4

MPEG-DASH3.4.1

發(fā)展歷史2010年，3GPP和OIPF發(fā)布了自己的碼率自適應(yīng)方案，AdaptiveStreaming（AHS,partof3GPPR9）和AdaptiveStreaming(HAS),但是，這些協(xié)議沒有兼容。MPEG-LA和ISO標準組織創(chuàng)立了橫跨整個業(yè)界的Streaming協(xié)議小組：MPEG-DASH（DynamicAdaptiveStreamingover）,第一個DASH草稿在2011年2月發(fā)布。DASH技術(shù)目的是標準化Streaming技術(shù)以取代目前已經(jīng)存在的不同廠家的技術(shù)方案，如：MicrosoftSmoothStreaming、AppleLiveStreaming。DASH工作組已經(jīng)在產(chǎn)業(yè)界取得了肯定的支持，但是目前Adobe和Apple并未明確表態(tài)支持DASH。對于DASH來說現(xiàn)在它不支持HTML5傳輸?shù)木幋a節(jié)目，這就意味著它可能采納H.264或是WebM編碼方式。最終，DASH是否免費還不知曉，這可能會影響一些潛在用戶，如Mozilla。全部的為基礎(chǔ)的碼流傳輸技術(shù)都包含兩個功能模塊，節(jié)目碼流和文件塊索引文件，在DASH方案中節(jié)目碼流稱之為媒體表示，而文件塊索引文件稱之為媒體描述，如下圖所示。

3.4.2

關(guān)鍵技術(shù)點下圖描述了MPEG-DASH前端服務(wù)器和MPEG-DASH客戶端之間的邏輯關(guān)系。節(jié)目內(nèi)容首先存儲在MPEG-DASH前端服務(wù)器上，隨后運用協(xié)議進行傳輸。媒體內(nèi)容在服務(wù)上存儲方式由兩個部分組成：第一：媒體內(nèi)容描述MediaPresentationDescription(MPD)，其中包括內(nèi)容的文件塊索引文件文件、內(nèi)容的變量信息、URL以及其他特點。其次：文件片段，它代表了該節(jié)目全部的節(jié)目數(shù)據(jù)塊。

在播放節(jié)目內(nèi)容時，MPEG-DASH客戶端首先要獲得MPD文件，MPD文件可是通過、email、廣播或者其他方式傳輸。通過解析MPD文件，email客戶端可以了解節(jié)目的時間信息、節(jié)目的可用性、節(jié)目類型、清楚度、最大與最小帶寬，以及幾種不同編碼碼率的節(jié)目流、DRM信息、節(jié)目位置以及與內(nèi)容相關(guān)的其他信息。利用以上這些信息，MPEG-DASH客戶端選擇合適碼率進行播放。在節(jié)目內(nèi)容起先傳輸并起先緩沖時，客戶端