基于HLS協(xié)議的流媒體直播系統(tǒng)的研究和改進(jìn)

羅淑貞，耿恒山，徐祥男，孫豪賽，高 艷 ，李 欽 ，謝 因

(1.河北工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與軟件學(xué)院，天津300401;2.天津理工大學(xué)自動(dòng)化學(xué)院，天津300384;3.天津?yàn)I海新區(qū)環(huán)球網(wǎng)絡(luò)電視有限公司，天津300202)

0 引言

HTTP Live Streaming是 Apple公司針對(duì)iphone，ipad等移動(dòng)終端設(shè)備開(kāi)發(fā)的一種基于HTTP的自適應(yīng)流媒體協(xié)議［1］，而HLS技術(shù)是將媒體源編碼為不同編碼速率的多個(gè)流，客戶端根據(jù)網(wǎng)絡(luò)帶寬狀況的變化選擇不同編碼速率的替換流，實(shí)現(xiàn)帶寬波動(dòng)時(shí)的流媒體自適應(yīng)切換［2-4］.

由于數(shù)據(jù)通過(guò)HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問(wèn)題，而且分段文件的時(shí)長(zhǎng)很短，客戶端可以很快地選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放［5］.當(dāng)這種技術(shù)應(yīng)用于電視直播時(shí)，為了滿足客戶端進(jìn)行一定時(shí)間的時(shí)移觀看功能，在服務(wù)器與客戶端的交互傳輸過(guò)程中會(huì)存在視頻流索引文件重復(fù)下載所造成的冗余問(wèn)題，浪費(fèi)流量和資源且影響了性能，為此筆者提出了一種方法——標(biāo)志法來(lái)有效改善這種情況，并通過(guò)實(shí)驗(yàn)把改善前后的效果進(jìn)行了對(duì)比，充分驗(yàn)證了這種方法的可行性.

1 HLS技術(shù)工作原理以及結(jié)構(gòu)

如圖1所示，HLS技術(shù)由3部分組成:服務(wù)組件、視頻分布存儲(chǔ)和客戶端軟件部分.首先對(duì)視頻數(shù)據(jù)進(jìn)行錄入，編碼，然后服務(wù)器軟件的流分段程序?qū)⒚襟w視頻流分解成一系列簡(jiǎn)短的.ts媒體文件，這些.ts文件被放置在web服務(wù)器上.這個(gè)流分段程序同時(shí)還創(chuàng)建一個(gè)索引文件，該索引文件包含元數(shù)據(jù)以及一個(gè).m3u8媒體文件的列表，且索引文件的URL發(fā)布到web服務(wù)器上，客戶端軟件即可讀取索引，請(qǐng)求媒體文件，并將其顯示出來(lái)［6-8］.

2 服務(wù)器與客戶端之間的傳輸過(guò)程以及出現(xiàn)的問(wèn)題

針對(duì)應(yīng)用HLS技術(shù)的電視直播情況，下面以客戶端和服務(wù)器之間的交互傳輸為例詳細(xì)分析其過(guò)程以及出現(xiàn)的視頻流索引文件重復(fù)下載的問(wèn)題，在這里采用網(wǎng)絡(luò)數(shù)據(jù)分析儀來(lái)實(shí)現(xiàn)分析和檢測(cè)，且下述圖例均是在網(wǎng)絡(luò)數(shù)據(jù)分析儀上截取的.

2.1 傳輸過(guò)程以及視頻流索引文件重復(fù)下載的問(wèn)題

圖2為客戶端與服務(wù)器之間的傳輸視頻流.

圖2 客戶端和服務(wù)器之間傳輸視頻流Fig.2 Transm it video stream ing between server and cllients

其中一定時(shí)間內(nèi)獲得的.ts索引文件的個(gè)數(shù)k是由服務(wù)器上用于直播的緩存來(lái)決定的.

假設(shè)設(shè)定進(jìn)行時(shí)移的時(shí)間是1 h，那么直播的緩存就要儲(chǔ)存1 h的.ts索引文件.若分段文件的時(shí)長(zhǎng)是2 s或是5 s，其個(gè)數(shù) k就為1 800或720.進(jìn)而再根據(jù)客戶端播放器的緩存來(lái)決定間隔多長(zhǎng)時(shí)間取.ts索引文件，如果緩存上的.ts文件數(shù)量滿足客戶端的需求，就暫時(shí)不用取，若不滿足就要去申請(qǐng)，所以索引文件的個(gè)數(shù)很大，很容易產(chǎn)生冗余，降低傳輸效率.下面以設(shè)置時(shí)移時(shí)間為2 h，分段文件的時(shí)長(zhǎng)10 s，且供選擇的帶寬分別是380 k、1 M、3.2 M為例來(lái)具體闡述其過(guò)程.

如圖2所示，客戶端首先向服務(wù)器發(fā)送一個(gè)請(qǐng)求頻道的.m3u8索引文件，服務(wù)器立刻發(fā)出回應(yīng)，如圖3(a)為具體實(shí)現(xiàn)步驟，且回應(yīng)的.m3u8文件的內(nèi)容如圖3(b)所示.通過(guò)內(nèi)容可以明顯看出，傳輸過(guò)來(lái)的索引文件有3個(gè)帶寬，大約為380 k、1 M、3.2 M，從而系統(tǒng)可以根據(jù)實(shí)時(shí)網(wǎng)絡(luò)的狀況來(lái)以不同帶寬傳輸視頻流.(在這里以頻道CCTV12為例).

如圖2所示，頻道的網(wǎng)絡(luò)狀態(tài)確定之后，就要開(kāi)始傳輸視頻流，此時(shí)客戶端就會(huì)申請(qǐng)包含.ts視頻流索引的.m3u8文件，服務(wù)器給出回應(yīng)并把.m3u8索引文件發(fā)給客戶端，此時(shí)若需要傳輸序列號(hào)為27 043的.ts視頻流片段，那么客戶端就會(huì)再次發(fā)送申請(qǐng)，服務(wù)器回應(yīng)并給出其播放地址，從而可播放該序列號(hào)的視頻段內(nèi)容，上述過(guò)程如圖4(a)所示.回應(yīng)的.m3u8索引文件的具體內(nèi)容如圖4(b)所示.

圖3 發(fā)出頻道申請(qǐng)以及回應(yīng)的具體內(nèi)容Fig.3 Send channel request and respond the contents

圖4 發(fā)出視頻流申請(qǐng)以及回應(yīng)的具體內(nèi)容Fig.4 Send stream ing request and respond the contents

如圖4(b)所示，.m3u8索引文件的具體內(nèi)容是是從序列號(hào)為26 327到27 043的.ts視頻流索引.

如圖2所示，服務(wù)器向客戶端傳送序列號(hào)為27 043的視頻流片段之后，客戶端就會(huì)向服務(wù)器再次發(fā)出申請(qǐng)，申請(qǐng)更新后的.m3u8索引文件，從而才可以下載下一個(gè)即序列號(hào)為27 044的視頻流片段，如圖5(a)所示.更新后的.m3u8索引文件的具體內(nèi)容如圖5(b)所示.

如圖5(b)所示，更新后的.m3u8文件內(nèi)容是從序列號(hào)為26 328到27 044的.ts視頻流索引.

由此可見(jiàn)，更新后的索引文件和前一個(gè)索引文件的內(nèi)容是存在很大冗余的，帶寬的浪費(fèi)率很高，很大程度耗費(fèi)流量，降低效率.

2.2 冗余問(wèn)題所帶來(lái)的弊端

當(dāng)使用手機(jī)或者電視進(jìn)行時(shí)，通常都是以高帶寬進(jìn)行傳輸，則流量的浪費(fèi)率計(jì)算過(guò)程如下.

根據(jù)2.1節(jié)敘述，傳輸?shù)囊粋€(gè).m3u8索引文件的內(nèi)容大小是1 448，如圖6所示.

圖5 更新.m3u8文件以及具體內(nèi)容Fig.5 The content of .m3u8 index files after update

圖6 .m3u8索引文件的內(nèi)容大小等信息Fig.6 The content length of.m3u8 index file

那么傳輸過(guò)來(lái)的.m3u8文件有4個(gè)，而緊接著傳輸過(guò)來(lái)的序列號(hào)為27 044的視頻流總共有280個(gè)，且每個(gè)文件大小為1 448，如圖7所示.故該序列號(hào)的視頻流總大小為1 448×280，可得出

則可得出來(lái)的比率為1.4%，以此類推，在采集了多次數(shù)據(jù)，試驗(yàn)了多次的基礎(chǔ)上得出帶寬的浪費(fèi)率大約為1.4% ～2.0%左右，對(duì)于手機(jī)電視用戶來(lái)說(shuō)，浪費(fèi)了較大部分流量，占用空間，影響性能.

圖7 .ts視頻流內(nèi)容的大小等信息Fig.7 The content length of.ts video stream ing

3 針對(duì)冗余問(wèn)題的對(duì)策

3.1 解決冗余問(wèn)題的方案

.ts視頻流索引文件是重復(fù)下載的，導(dǎo)致帶寬的浪費(fèi)，傳輸效率的降低，所以有這樣一種思路和方法，可以有效改善這種冗余狀況如圖8所示.

首先可以在.m3u8文件中添加一個(gè)新標(biāo)簽，#EXT-X-MEDIA-SEQUENCE-LAST，即客戶端每次都把接收到的最后一個(gè)流片段索引文件的序號(hào)賦值給#EXT-X-MEDIA-SEQUENCELAST.

如圖8所示，當(dāng)服務(wù)器向客戶端發(fā)送完視頻流之后，客戶端會(huì)發(fā)送一個(gè).m3u8索引文件，服務(wù)器分析.m3u8索引文件的內(nèi)容，其中的新標(biāo)簽就會(huì)顯示為

圖8 服務(wù)器與客戶端的傳輸過(guò)程Fig.8 The transm it process between server and cients

#EXT-X-MEDIA-SEQUENCE-LAST=tm.那么服務(wù)器就會(huì)向客戶端回應(yīng)tm之后的視頻流索引，這樣只重復(fù)被標(biāo)記過(guò)的視頻流片段索引文件，這種方法大幅度減少了冗余的問(wèn)題，有效充分地利用了帶寬，提高了效率.由2.1節(jié)敘述為例，即改進(jìn)后的.m3u8索引文件內(nèi)容如圖9所示.

圖9 改進(jìn)后的.m3u8索引文件Fig.9 The .m3u8 index files after improvement

3.2 實(shí)施對(duì)策后的效果改善

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

圖10 改進(jìn)前后的.m3u8索引文件內(nèi)容比較Fig.10 The content of .m3u8 index files between and after

由圖10(b)可知，經(jīng)由改進(jìn)方案后的.m3u8索引文件，其內(nèi)容為序列號(hào)為27 043和序列號(hào)為27 044的索引文件.與改進(jìn)前圖10(a)(序列號(hào)26 328到27 044的索引文件)相比較，大大降低了冗余度，改善效果很明顯.

根據(jù)公式(2)并可得出流量的浪費(fèi)率

可得其流量被浪費(fèi)的比率為0.37%，與改進(jìn)前流量浪費(fèi)率1.4%相比，有效節(jié)省了流量.

經(jīng)過(guò)大量的實(shí)驗(yàn)，當(dāng)改變時(shí)移時(shí)間或是視頻流片段時(shí)間時(shí)，改進(jìn)前后的帶寬的浪費(fèi)率如表1所示.由表中可得出，改進(jìn)后的效果較為明顯，冗余度大大降低，有效提高了傳輸?shù)男阅?改善方法是非常可行的.

表1 不同情況下帶寬浪費(fèi)率的比較Tab.1 The bandw idth wastage rates in different situation between and after improvement

4 結(jié)論

針對(duì)基于HLS技術(shù)的流媒體直播系統(tǒng)進(jìn)行了深入的研究，剖析了了當(dāng)中所存在的問(wèn)題，并立足于現(xiàn)狀，提出了解決方案，能夠提高工作效率，提升性能，但是針對(duì)冗余問(wèn)題提出的解決方案有所不足，當(dāng)進(jìn)行直播時(shí)，若網(wǎng)絡(luò)狀態(tài)出現(xiàn)極其不好的時(shí)候，可能會(huì)出現(xiàn)視頻流段沒(méi)有被完全下載的情況.但是出現(xiàn)這種情況的概率還是很小的，所以這個(gè)方案還是非常有可行性的，可以預(yù)見(jiàn)，會(huì)有很廣泛的應(yīng)用前景.

［1］ 朱倩.新一代流媒體HLS關(guān)鍵技術(shù)的研究及實(shí)現(xiàn)［D］.遼寧:大連理工大學(xué)信息學(xué)院，2011.

［2］ 李云飛，謝偉凱，魯晨平，等.面向直播 HTTP Streaming系統(tǒng)的HTTP緩存服務(wù)器行為優(yōu)化［J］.計(jì)算機(jī)工程與應(yīng)用，2012，40(3):168-174.

［3］ 凌艷群.基于HTTP的流媒體系統(tǒng)關(guān)鍵技術(shù)研究與實(shí)現(xiàn)［D］.遼寧:大連理工大學(xué)信息學(xué)院，2011.

［4］ 李光大.基于HTTP直播的移動(dòng)流媒體系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［D］.華中科技大學(xué)計(jì)算機(jī)學(xué)院，2011.

［5］ HTTP Live streaming draft-pantos-http-live-streaming-11［EB/OL］.［2013-04-16］.http://tools.ietf.org/html/draft-pantos-http-live-streaming-11

［6］ Apple Inc.HTTP Live Streaming Archictecture:Technical report［R］，2010.

［7］ Open IPTV Forum-Release 2 Specification，HTTP A-daptive Streaming［R］.Draft V0.06 June 7，2010.

［8］ 金達(dá)，葉慶偉，狄紅衛(wèi)，等.基于HLS的流媒體播放系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［J］.信息技術(shù)，2013，29(40):103-104.