徐祥男，富 坤，羅淑貞，耿恒山，耿躍華

（河北工業(yè)大學(xué) a.計(jì)算機(jī)科學(xué)與軟件學(xué)院；b.電氣工程學(xué)院，天津 300130）

HLS直播流媒體傳輸系統(tǒng)的冗余優(yōu)化

徐祥男a，富 坤a，羅淑貞a，耿恒山a，耿躍華b

（河北工業(yè)大學(xué) a.計(jì)算機(jī)科學(xué)與軟件學(xué)院；b.電氣工程學(xué)院，天津 300130）

對(duì)HTTP Live Streaming深入研究之后，發(fā)現(xiàn)該協(xié)議在直播流媒體傳輸過(guò)程中存在視頻流索引文件重復(fù)傳送的問(wèn)題。詳細(xì)闡述了服務(wù)器與客戶端之間的交互過(guò)程，并通過(guò)對(duì)網(wǎng)絡(luò)監(jiān)控軟件的使用，檢測(cè)到交互過(guò)程中服務(wù)器傳輸給客戶端的視頻流索引文件存在較大的冗余，造成網(wǎng)絡(luò)帶寬開(kāi)銷(xiāo)增大。提出一種可行的改進(jìn)方案，在.m3u8文件中添加一個(gè)#EXT-X-MEDIA-SEQUENCE-LAST標(biāo)簽，并使服務(wù)器和客戶端都對(duì)該標(biāo)簽進(jìn)行識(shí)別。通過(guò)對(duì)網(wǎng)絡(luò)占用率的對(duì)比分析，改進(jìn)后的方案對(duì)網(wǎng)絡(luò)帶寬的占用率明顯減小，進(jìn)而驗(yàn)證了該改進(jìn)方案的可行性。

HLS；視頻流；索引文件；標(biāo)簽；網(wǎng)絡(luò)帶寬；占用率

1 HTTP Live Streaming典型結(jié)構(gòu)

HTTP Live Streaming protocol是由蘋(píng)果公司提出的基于HTTP的流媒體協(xié)議。HTTP Live Streaming媒體系統(tǒng)典型結(jié)構(gòu)如圖1所示。包括流媒體準(zhǔn)備服務(wù)器、流媒體分發(fā)服務(wù)器和客戶端3個(gè)部分[1]。流媒體準(zhǔn)備服務(wù)器包括編碼器和流分割器兩個(gè)主要部分，編碼器連接的是音視頻采集設(shè)備，編碼器將輸入的媒體數(shù)字化并編碼為H.264視頻和ACC音頻格式，然后再封裝成為符合MPEG-2系統(tǒng)層標(biāo)準(zhǔn)的傳輸流（TS）格式進(jìn)行輸出。流媒體分發(fā)服務(wù)器既可以是一般的Web服務(wù)器，也可以是一個(gè)Web緩存系統(tǒng)，其供HTTP客戶端下載媒體索引文件和視頻流片段[2]。一般來(lái)說(shuō)，索引文件采用.m3u8文件格式規(guī)范?？蛻舳送ㄟ^(guò)訪問(wèn)Web服務(wù)器來(lái)獲取和下載一個(gè)流媒體的.m3u8文件，當(dāng)客戶端下載一定數(shù)量的媒體文件后，將它們按下載的順序拼成一個(gè)TS視頻流，然后送至播放器進(jìn)行解碼和呈現(xiàn)[3]。但是在直播的情況下，為了滿足客戶端進(jìn)行一定時(shí)間的時(shí)移觀看功能，服務(wù)器與客戶端的交互過(guò)程中會(huì)有視頻流索引文件重復(fù)傳送的問(wèn)題[4]。

圖1 直播流媒體系統(tǒng)結(jié)構(gòu)

2 HTTP Live Streaming在直播傳輸過(guò)程中存在的問(wèn)題

在網(wǎng)絡(luò)帶寬波動(dòng)的情況下，如果服務(wù)器還是向客戶端發(fā)送單一碼率的流媒體文件，則可能出現(xiàn)卡頓的現(xiàn)象，這就產(chǎn)生了網(wǎng)絡(luò)自適應(yīng)的解決方法。網(wǎng)絡(luò)自適應(yīng)是指流媒體準(zhǔn)備服務(wù)器中的編碼器會(huì)把采集到的同一視頻編碼生成不同碼率的替換流和相對(duì)應(yīng)的索引文件[5]。在主索引文件中包含了指向不同替換流的索引文件的URI指針。服務(wù)器與客戶端的交互過(guò)程如圖2所示（客戶端指向服務(wù)器的箭頭表示客戶端請(qǐng)求過(guò)程，服務(wù)器指向客戶端的箭頭表示服務(wù)器回應(yīng)客戶端的過(guò)程，下同）。

圖2 服務(wù)器與客戶端交互過(guò)程

假設(shè)規(guī)定進(jìn)行時(shí)移的時(shí)間是2 h，那么直播的緩存就要儲(chǔ)存2 h的視頻流片段索引文件，并且如果流分割器是分割成10 s一個(gè)的視頻流片段，其個(gè)數(shù)k為720，以此類(lèi)推，如果分割成2 s或是5 s一個(gè)的視頻流片段，那么k的值分別為3 600和1 440。由此看出索引文件的個(gè)數(shù)是很多的，很容易產(chǎn)生重復(fù)傳送。每當(dāng)當(dāng)前視頻流片段即將播放完畢時(shí)，客戶端會(huì)向服務(wù)器申請(qǐng)下一個(gè)視頻流片段，用網(wǎng)絡(luò)監(jiān)測(cè)軟件監(jiān)測(cè)客戶端與服務(wù)器對(duì)于某一個(gè)視頻流的交互過(guò)程，如圖3所示。將圖4中的.m3u8索引文件打開(kāi)，里面的內(nèi)容如圖5所示。

圖3 監(jiān)測(cè)的交互過(guò)程圖（截圖）

圖4 索引文件內(nèi)容（截圖）

圖5 監(jiān)測(cè)的交互過(guò)程（截圖）

再用網(wǎng)絡(luò)監(jiān)測(cè)軟件監(jiān)測(cè)下一個(gè)視頻流片段，觀看客戶端與服務(wù)器之間的交互過(guò)程，如圖5所示。再把圖5中的.m3u8索引文件打開(kāi)，可以看到該索引文件包含的內(nèi)容如圖6所示。

從圖4可以看出，索引文件的序列號(hào)是從26 318到26 511，而從圖6可以看出索引文件的序列號(hào)是從26 320到27 038，說(shuō)明有很多的索引文件是重復(fù)傳送的，這樣會(huì)導(dǎo)致服務(wù)器負(fù)載增加，還會(huì)占用網(wǎng)絡(luò)帶寬。下面提出一種行之有效的解決方法。

圖6 索引文件內(nèi)容（截圖）

3 視頻流索引文件重復(fù)傳送改進(jìn)方案

可以在.m3u8文件內(nèi)添加一個(gè)標(biāo)簽，用于標(biāo)記接收到的索引文件中最后一個(gè)視頻流片段，用#EXT-X-MEDIA-SEQUENCE-LAST標(biāo)記，每次客戶端都會(huì)把接收到的索引文件的最后一個(gè)視頻流片段的序號(hào)賦值給#EXT-X-MEDIA-SEQUENCE-LAST[8]。當(dāng)客戶端再次向服務(wù)器發(fā)送請(qǐng)求時(shí)，服務(wù)器分析.m3u8文件的內(nèi)容，會(huì)將#EXT-X-MEDIA-SEQUENCE-LAST標(biāo)記的視頻流片段及其之后的索引文件發(fā)送給客戶端，這樣只重復(fù)發(fā)送用#EXT-X-MEDIA-SEQUENCE-LAST標(biāo)記的那個(gè)視頻流片段，減少了重復(fù)發(fā)送的問(wèn)題。在此要重點(diǎn)說(shuō)明一下，特別是廣域網(wǎng)，由于網(wǎng)絡(luò)線路的不同，服務(wù)器發(fā)送的視頻流片段不一定最后一個(gè)到達(dá)，有可能比它前面序號(hào)的視頻流片段先到達(dá)客戶端。也就是說(shuō)，本來(lái)服務(wù)器已經(jīng)發(fā)送了N片視頻流，很可能客戶端接收到了第N片以后才收到第N-1或N-2片或是更前的片段。但這不會(huì)對(duì)本設(shè)計(jì)有影響，因?yàn)榭蛻舳藭?huì)在播放當(dāng)前視頻流片段的同時(shí)或是更早就去申請(qǐng)下一次的視頻流，這個(gè)時(shí)間差足夠發(fā)送完所有的視頻流片段，并且客戶端把這些片段按順序排好，并標(biāo)記完最后一個(gè)視頻流片段。所以不存在上述由于網(wǎng)絡(luò)路線的不同而導(dǎo)致的問(wèn)題。這里重復(fù)發(fā)送#EXT-X-MEDIA-SE?QUENCE-LAST標(biāo)記的視頻流片段可以保證在索引文件目錄沒(méi)有更新的情況下，服務(wù)器依然可以回應(yīng)客戶端的請(qǐng)求。改進(jìn)后的交互過(guò)程示意圖如圖7所示。

4 改善前后對(duì)網(wǎng)絡(luò)帶寬的影響

利用網(wǎng)絡(luò)帶寬檢測(cè)軟件network monitor對(duì)服務(wù)器與客戶端的交互過(guò)程進(jìn)行監(jiān)測(cè)，圖3、圖5、圖8均是利用該軟件檢測(cè)得到的。

4.1 改善前對(duì)網(wǎng)絡(luò)的影響

當(dāng)播放視頻文件時(shí)，通常都是以高帶寬進(jìn)行傳輸，其帶寬被浪費(fèi)的公式為

圖7 改進(jìn)后的交互過(guò)程

圖8 改進(jìn)后服務(wù)器回應(yīng)的.m3u8索引文件（截圖）

式中：p表示帶寬的浪費(fèi)率，以圖5為例來(lái)計(jì)算，從圖9可知，傳輸一個(gè).m3u8索引文件的內(nèi)容大小是1 448。

圖9 .m3u8索引文件的內(nèi)容（截圖）

那么傳輸過(guò)來(lái)的.m3u8文件有4個(gè)，而傳輸過(guò)來(lái)的序列號(hào)為26 789的視頻流總共210個(gè)，且每個(gè)大小為1 452，如圖10所示，故該序列號(hào)的視頻流總大小為1 448×210，故

圖10 視頻流片段內(nèi)容（截圖）

從式（2）中可以看出，帶寬的占用率只和傳輸?shù)?m3u8的個(gè)數(shù)和傳輸?shù)囊曨l流總的個(gè)數(shù)有關(guān)，與每次傳輸?shù)拇笮o(wú)關(guān)。在采集了多次數(shù)據(jù)，經(jīng)過(guò)大量的實(shí)驗(yàn)后，改變時(shí)移時(shí)間或者是一個(gè)視頻流片段時(shí)，在計(jì)算了多次的基礎(chǔ)上得出帶寬的浪費(fèi)率約為1.1%～6.0%，嚴(yán)重占用了帶寬。

4.2 改善后對(duì)帶寬的影響

以圖5為例，服務(wù)器回應(yīng)的.m3u8索引文件的具體內(nèi)容是從序列號(hào)為26 318到26 511的.ts視頻流索引，當(dāng)服務(wù)器向客戶端傳送序列號(hào)為26 343的視頻流片段之后，為了下載下一個(gè)序列號(hào)為26 344的視頻流片段，客戶端向服務(wù)器再次發(fā)出申請(qǐng)，申請(qǐng)新的.m3u8索引文件，當(dāng)實(shí)施這個(gè)改進(jìn)方案之后，更新后的.m3u8索引文件的具體內(nèi)容如圖11所示。

圖11 更新的.m3u8文件的內(nèi)容（截圖）

表1 改善前后帶寬的浪費(fèi)率

從表1可以看出，在未改善的情況下，當(dāng)時(shí)移時(shí)間短、視頻流片段短的時(shí)候，帶寬的浪費(fèi)率還不高，但是系統(tǒng)一般不會(huì)設(shè)置太短的時(shí)移時(shí)間和視頻流片段，否則會(huì)增加成本和復(fù)雜度，隨著時(shí)移時(shí)間和視頻流片段時(shí)間的增長(zhǎng)，帶寬的浪費(fèi)問(wèn)題會(huì)越來(lái)越嚴(yán)重，帶寬的浪費(fèi)率增加，降低了效率，嚴(yán)重影響了其性能。從改善后的數(shù)據(jù)可以看出，帶寬浪費(fèi)率約為未改善時(shí)的1/10，可以說(shuō)是對(duì)帶寬的浪費(fèi)率有了明顯的改善。

5 結(jié)語(yǔ)

針對(duì)冗余問(wèn)題提出來(lái)的解決方案有所不足，當(dāng)進(jìn)行直播時(shí)，若網(wǎng)絡(luò)狀態(tài)極其不好，可能會(huì)出現(xiàn)視頻流片段沒(méi)有被完全下載。但是出現(xiàn)這種情況的概率還是很小的，因?yàn)檎缜拔乃?，流媒體準(zhǔn)備服務(wù)器中的編碼器會(huì)把采集到的同一視頻編碼成不同碼率的替換流并生成相對(duì)應(yīng)的索引文件，在主索引文件中包含了指向不同替換流的索引文件的URI指針。在網(wǎng)絡(luò)帶寬波動(dòng)的情況下，服務(wù)器會(huì)根據(jù)網(wǎng)絡(luò)情況向客戶端發(fā)送合適碼率的流媒體文件，但這種情況發(fā)生的概率很小。綜合實(shí)驗(yàn)結(jié)果可以看出這個(gè)方案還是非常有可行性的，將有很廣泛的應(yīng)用前景。

[1]霍龍社，甘震.移動(dòng)流媒體協(xié)議綜述［J］.信息通信技術(shù)，2010（4）∶6-13.

[2] 呂鹍，郝敏.流媒體中間件在Linux下的設(shè)計(jì)與實(shí)現(xiàn)[J].電視技術(shù)，2014，38（5）：77-80.

[3] 許雪松，楊明極，李天池.基于流媒體技術(shù)的移動(dòng)視頻服務(wù)器的設(shè)計(jì)[J].電視技術(shù)，2013，37（17）：167-169.

[4] Method and apparatus for dynamically generating media sequenc?es on demand for http live streaming：US，US201229068 [P].2012-11-15.

[5]尹浩，林闖，文浩，等.大規(guī)模流媒體應(yīng)用中關(guān)鍵技術(shù)的研究[J].計(jì)算機(jī)學(xué)報(bào)，2008（5）：755-774.

[6] 李鳴.多媒體有線電視網(wǎng)絡(luò)應(yīng)用研究[J].華僑大學(xué)學(xué)報(bào)：自然科學(xué)版，2000，21（1）：96-100.

[7]李云飛，謝偉凱，魯晨平.面向直播HTTP Streaming系統(tǒng)的HTTP緩存服務(wù)器行為優(yōu)化［J］.計(jì)算機(jī)工程與應(yīng)用，2012（10）：68-74.

徐祥男（1990—），碩士生，主研計(jì)算機(jī)網(wǎng)絡(luò)、流媒體傳輸；

富 坤（1979—），女，博士，講師，主要研究方向?yàn)榭芍貥?gòu)計(jì)算、計(jì)算機(jī)系統(tǒng)結(jié)構(gòu)；

羅淑貞（1990—），女，碩士生，主要研究方向?yàn)橛?jì)算機(jī)網(wǎng)絡(luò)、流媒體傳輸；

耿恒山（1952—），教授，研究生導(dǎo)師，主研計(jì)算機(jī)網(wǎng)絡(luò)、自動(dòng)控制、多媒體傳輸；

耿躍華（1978—），女，碩士，主研計(jì)算機(jī)網(wǎng)絡(luò)、電磁原理。

Redundancy Optim ization in Live Stream ing Transm ission System

XU Xiangnana，F(xiàn)U Kuna，LUO Shuzhena，GENG Hengshana，GENG Yuehuab
（a.School of Computer Science and Engineering；b.School of Electrical Engineering，Hebei University of Technology，Tianjin 300130，China）

After in-depth study on the HLS，it is found that HLS has the problem in the video streaming transmitted repeatedly aspect of the index file in live streaming process.Specifically addressed the interaction process between the server and the client，for using network monitoring software，video streaming index files are detected that there is a large redundancy when the server transmits to the client in the interactive process，resulting in the increased network bandwidth overhead.A viable improvement program is proposed，to add a#EXT-X-MEDIA-SEQUENCE-LAST tag in the.m3u8 file，making the label identified by the server and the client.Through comparative analysis，the occupancy rate of the network bandwidth，the occupancy rate of the network bandwidth are significantly reduced in the improved program，verify the feasibility of the improved program.

HLS;video streaming;index files;tag;network bandwidth;occupancy ratio

TN949.6

B

?? 盈

2014-03-08

【本文獻(xiàn)信息】徐祥男，富坤，羅淑貞，等.HLS直播流媒體傳輸系統(tǒng)的冗余優(yōu)化[J].電視技術(shù)，2014，38（16）.

國(guó)家自然科學(xué)基金項(xiàng)目（31100711）；河北省高等學(xué)?？茖W(xué)技術(shù)研究青年基金項(xiàng)目（20111122）；河北省交通運(yùn)輸廳科學(xué)技術(shù)項(xiàng)目（Y2011087）