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

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 冗余問題所帶來的弊端

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

根據(jù)2.1節(jié)敘述，傳輸?shù)囊粋€.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

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

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

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

3 針對冗余問題的對策

3.1 解決冗余問題的方案

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

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

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

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

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

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

3.2 實施對策后的效果改善

由2.1小節(jié)圖4為例，服務(wù)器回應(yīng)的.m3u8索引文件的具體內(nèi)容是從序列號為26 327到27 043的.ts視頻流索引，當(dāng)服務(wù)器向客戶端傳送序列號為27 043的視頻流片段之后，為了下載下一個序列號為27 044的視頻流片段，客戶端向服務(wù)器再次發(fā)出申請，申請新的.m3u8索引文件，當(dāng)實施這個改進(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)容為序列號為27 043和序列號為27 044的索引文件.與改進(jìn)前圖10(a)(序列號26 328到27 044的索引文件)相比較，大大降低了冗余度，改善效果很明顯.

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

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

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

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

4 結(jié)論

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

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

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

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

［4］ 李光大.基于HTTP直播的移動流媒體系統(tǒng)的設(shè)計與實現(xiàn)［D］.華中科技大學(xué)計算機學(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è)計與實現(xiàn)［J］.信息技術(shù)，2013，29(40):103-104.