曲凱明++張小奕
摘要:針對傳統(tǒng)的HTTP動(dòng)態(tài)自適應(yīng)流媒體(DASH)的鄰近用戶網(wǎng)絡(luò)帶寬競爭問題,提出一種設(shè)備對設(shè)備(D2D)協(xié)作式DASH系統(tǒng),該系統(tǒng)采用了D2D協(xié)作的方式充分利用鄰近用戶的網(wǎng)絡(luò)帶寬能力下載和分享視頻,客戶端以中間件架構(gòu)實(shí)現(xiàn),使得該系統(tǒng)與主流播放器兼容。針對過度追求高視頻質(zhì)量而忽視智能手機(jī)能耗的問題,提出了一種能耗優(yōu)化碼率選擇算法應(yīng)用于D2D協(xié)作式DASH系統(tǒng)。根據(jù)智能手機(jī)當(dāng)前的能耗、CPU使用率、內(nèi)存占用率與系統(tǒng)停留時(shí)間選出領(lǐng)隊(duì)設(shè)備,領(lǐng)隊(duì)設(shè)備負(fù)責(zé)視頻的下載與D2D自組網(wǎng)的分享。實(shí)驗(yàn)測試結(jié)果表明:該算法與非合作算法相比在保證相同視頻質(zhì)量的情況下可以最多節(jié)省25%的能耗。
關(guān)鍵詞:流媒體;能耗;設(shè)備對設(shè)備;碼率選擇;移動(dòng)云計(jì)算
中圖分類號:TN919.8
文獻(xiàn)標(biāo)識碼:A
DOI:10.3969/j.issn.1003-6970.2015.09.002
0 引言
隨著智能手機(jī)的普及與無線通信技術(shù)的成熟,人們可以隨時(shí)隨地用手機(jī)、平板或其他移動(dòng)設(shè)備觀看視頻內(nèi)容。HTTP動(dòng)態(tài)自適應(yīng)流媒體(Dynamic Adaptive Streaming over HTTP,DASH)已經(jīng)成為目前最流行的視頻流媒體播放標(biāo)準(zhǔn)。DASH將這個(gè)視頻文件分割成一系列的可以基于HTTP傳輸?shù)男∏衅?,切片的大小是固定的,一般?-10s之間。分割后每個(gè)切片都有覆蓋各種不同碼率的版本,即服務(wù)器上具有多碼率編碼的源內(nèi)容。當(dāng)DASH客戶端播放網(wǎng)絡(luò)視頻時(shí)將基于自身的網(wǎng)絡(luò)狀況例如吞吐量和時(shí)延等條件選擇下一段切片的碼率。
根據(jù)最新的統(tǒng)計(jì),將近五分之一的YouTube用戶每天在用智能手機(jī)觀看視頻,其中有近一半的人會與他們的朋友一起觀看視頻。當(dāng)一組鄰近的用戶通過移動(dòng)客戶端觀看同一段網(wǎng)絡(luò)視頻時(shí),這一組用戶的客戶端會分別向服務(wù)器請求視頻資源,這些客戶端獲得的視頻碼率總會受到網(wǎng)絡(luò)限制。而如果這些用戶是通過同樣的方式接入網(wǎng)絡(luò),他們獲取的視頻質(zhì)量就會更加糟糕,因?yàn)橄嗷ジ偁幍年P(guān)系,這些客戶端都無法達(dá)到網(wǎng)絡(luò)本身的最大能力。
本文提出了一種設(shè)備對設(shè)備(Device-to-Device,D2D)協(xié)作式DASH系統(tǒng),充分考慮到用戶使用的智能手機(jī)設(shè)備通常具有多個(gè)網(wǎng)絡(luò)接入方式,當(dāng)設(shè)備通過3G/4G連接網(wǎng)絡(luò)時(shí),就可以考慮利用Wi-Fi連接,即引入D2D的連接使一組客戶端相互合作下載和分享視頻資源。客戶端以中間件架構(gòu)實(shí)現(xiàn),在中間件內(nèi)部處理調(diào)度視頻的下載、分享與切片的拼接,對外暴露傳統(tǒng)的DASH接口,即D2D協(xié)作式DASH系統(tǒng)對播放器來說是透明的,主流支持DASH協(xié)議的播放器都可以兼容D2D協(xié)作式DASH。從而用戶可以享受更好的視頻質(zhì)量的同時(shí)不用去關(guān)心播放器的兼容性問題。
本文還提出了一種能耗優(yōu)化碼率選擇算法應(yīng)用在D2D協(xié)作式DASH系統(tǒng)。綜合考慮智能手機(jī)當(dāng)前的能耗,CPU使用率,內(nèi)存占用率與系統(tǒng)停留時(shí)間選出領(lǐng)隊(duì)設(shè)備,領(lǐng)隊(duì)設(shè)備負(fù)責(zé)向云服務(wù)器發(fā)起視頻下載請求并基于領(lǐng)隊(duì)設(shè)備提出了一種自適應(yīng)碼率選擇算法,下載好的視頻通過D2D自組網(wǎng)分享。實(shí)驗(yàn)結(jié)果表明能耗優(yōu)化碼率選擇算法可以降低約25%的能耗同時(shí)保證了視頻質(zhì)量。
1 相關(guān)工作
對于新興的協(xié)作式流媒體系統(tǒng)有很多相關(guān)研究,可分為兩類:采用DASH的協(xié)作式流媒體系統(tǒng)和不采用DASH的協(xié)作式流媒體系統(tǒng)。在不采用DASH的協(xié)作式流媒體系統(tǒng)中,Keller等提出了一種采用網(wǎng)絡(luò)編碼的漸進(jìn)式合作下載系統(tǒng),但無法適應(yīng)網(wǎng)絡(luò)的變化并造成了資源的浪費(fèi)。一組用戶使用不采用DASH的系統(tǒng)從云服務(wù)器發(fā)起視頻下載請求,而這種一組用戶全部參與下載的機(jī)制會導(dǎo)致較高的能耗。Zhang等提出讓一組用戶的客戶端全部向云服務(wù)器發(fā)起下載請求,而只有一個(gè)用戶的客戶端可以播放視頻。Yaccoub等提出了一種合作機(jī)制,該機(jī)制將云服務(wù)器的所有視頻內(nèi)容推送到組內(nèi)某個(gè)用戶的客戶端,并通過該客戶端將所有視頻內(nèi)容廣播分享至所有組員,顯然該機(jī)制不能充分利用合作的優(yōu)勢來獲得更好的視頻質(zhì)量。
我們之前的工作提出了一種DASH系統(tǒng)部署在Android平臺上,一組用戶通過D2D白組網(wǎng)進(jìn)行視頻分享。然而該系統(tǒng)僅考慮了網(wǎng)絡(luò)的可用帶寬卻并沒有考慮智能手機(jī)的能耗問題,并且該系統(tǒng)與傳統(tǒng)DASH不兼容所以主流播放器無法直接使用該系統(tǒng)。
2 D2D協(xié)作式DASH系統(tǒng)
2.1 系統(tǒng)結(jié)構(gòu)
該系統(tǒng)包括一個(gè)云服務(wù)器和一組客戶端設(shè)備,系統(tǒng)結(jié)構(gòu)如圖1所示。云服務(wù)器為客戶端設(shè)備提供流媒體資源,包括響應(yīng)客戶端設(shè)備的請求并對請求的視頻資源做動(dòng)態(tài)處理??蛻舳嗽O(shè)備通過3G/4G網(wǎng)絡(luò)連接到云服務(wù)器,一組設(shè)備互相之間通過Wi-Fi連接作為D2D的接口,使鄰近的客戶端互相連接起來。在一組客戶端設(shè)備中采取分層架構(gòu),需要預(yù)先制定若干個(gè)領(lǐng)隊(duì)設(shè)備,作用是承擔(dān)發(fā)起下載請求的任務(wù),而在下載完成后領(lǐng)隊(duì)設(shè)備需要承擔(dān)D2D分享的任務(wù)。由于蜂窩移動(dòng)網(wǎng)絡(luò)模塊是智能手機(jī)中能耗最高的模塊之一,大量觸發(fā)蜂窩移動(dòng)網(wǎng)絡(luò)模塊的開啟與關(guān)閉狀態(tài)會導(dǎo)致能耗的顯著增加。本文所提出的D2D協(xié)作式DASH系統(tǒng)會在數(shù)據(jù)傳輸活躍階段避免了蜂窩移動(dòng)網(wǎng)絡(luò)模塊的頻繁開啟與關(guān)閉,從而能耗顯著降低。
2.2 服務(wù)器模塊設(shè)計(jì)
服務(wù)器由資源管理模塊、轉(zhuǎn)碼模塊和HTTP服務(wù)器模塊等部分組成?;谛〗M的資源管理模塊負(fù)責(zé)控制系統(tǒng)的云服務(wù)器,首先當(dāng)服務(wù)器收到客戶端領(lǐng)隊(duì)設(shè)備代表一個(gè)小組發(fā)起的視頻切片列表的請求時(shí),資源管理模塊接受請求,記錄小組規(guī)模Ⅳ并生成一個(gè)隨機(jī)的認(rèn)證標(biāo)識返回給這一組客戶端,在之后的通信中用來識別一個(gè)小組。另外資源管理模塊的重要功能是防止D2D自組網(wǎng)的無線信道碰撞,當(dāng)一個(gè)領(lǐng)隊(duì)設(shè)備完成了視頻碎片的下載并且尚未通過D2D自組網(wǎng)進(jìn)行廣播分享,領(lǐng)隊(duì)設(shè)備需要向云服務(wù)器的資源管理模塊發(fā)起D2D無線信道占用請求以防止在D2D無線信道下的數(shù)據(jù)碰撞。當(dāng)視頻碎片被分享之后,領(lǐng)隊(duì)設(shè)備需要向云服務(wù)器的資源管理模塊發(fā)起D2D無線信道解除占用請求。轉(zhuǎn)碼模塊是系統(tǒng)中應(yīng)用移動(dòng)云計(jì)算思想的結(jié)構(gòu),云服務(wù)器上存儲了原始的視頻資源,與傳統(tǒng)DASH系統(tǒng)不同的是,所提供的視頻資源是根據(jù)領(lǐng)隊(duì)設(shè)備客戶端所請求的視頻碼率動(dòng)態(tài)實(shí)時(shí)轉(zhuǎn)碼得到的,利用轉(zhuǎn)碼模塊實(shí)現(xiàn)了擴(kuò)展客戶端上的網(wǎng)絡(luò)能力。HTTP服務(wù)器模塊負(fù)責(zé)處理客戶端發(fā)起的HTTP請求,不過當(dāng)一個(gè)設(shè)備請求某個(gè)視頻切片時(shí),并不是直接返回用戶請求的完整文件,而是將視頻切片分割成碎片并通過HTTP協(xié)議的206響應(yīng)指明當(dāng)前碎片的偏移量。之后的工作就交給客戶端,由小組內(nèi)的領(lǐng)隊(duì)設(shè)備通過D2D連接完成碎片的拼接和視頻分享。
2.3 客戶端設(shè)備模塊設(shè)計(jì)
客戶端設(shè)備由客戶端資源管理模塊、下載模塊、廣播模塊和代理服務(wù)器模塊組成??蛻舳速Y源管理模塊負(fù)責(zé)在客戶端一側(cè)系統(tǒng)的整體控制,主要任務(wù)包括協(xié)調(diào)下載模塊和廣播模塊,緩存視頻切片,文件讀寫,響應(yīng)代理服務(wù)器的請求等。當(dāng)代理服務(wù)器模塊向資源管理模塊請求某一視頻切片時(shí),客戶端資源管理模塊會將下載模塊和廣播模塊通過網(wǎng)絡(luò)或D2D白組網(wǎng)獲取的視頻碎片組裝,獲得完整的視頻切片文件后將文件交給代理服務(wù)器模塊。
2.3.1 代理服務(wù)器中間件架構(gòu)
系統(tǒng)的客戶端一側(cè)采用中間件的架構(gòu)設(shè)計(jì)??蛻舳嗽O(shè)備的資源管理模塊、下載模塊和廣播模塊對于客戶端的播放器來說是透明的。播放器通過代理服務(wù)器提供的傳統(tǒng)DASH接口與系統(tǒng)進(jìn)行交互。對于任何支持傳統(tǒng)DASH協(xié)議播放器,在播放開始階段會先向代理服務(wù)器發(fā)起HTTP GET請求,請求下載視頻資源的切片文件列表,這里的切片文件列表相當(dāng)于DASH協(xié)議中的MPD文件。代理服務(wù)器此時(shí)暫時(shí)阻塞切片文件列表請求,同時(shí)將該請求轉(zhuǎn)發(fā)給客戶端資源管理模塊。當(dāng)資源管理模塊通過調(diào)度下載模塊和廣播模塊從服務(wù)器獲取到切片文件列表后,需要將切片文件列表的云服務(wù)器視頻資源一一映射到客戶端本地的虛擬文件,代理服務(wù)器重新生成一個(gè)包含本地虛擬文件的切片文件列表交付給DASH協(xié)議播放器,同時(shí)解除阻塞狀態(tài)。當(dāng)DASH協(xié)議播放器根據(jù)切片文件列表向代理服務(wù)器請求客戶端本地的虛擬文件時(shí),如果該虛擬文件所映射的真正視頻切片文件已經(jīng)通過資源管理模塊、下載模塊和廣播模塊的協(xié)作之下獲取到,那么就將真正的視頻切片文件交付給DASH協(xié)議播放器。如果該虛擬文件所映射的真正視頻切片文件尚未獲取到,那么代理服務(wù)器就暫時(shí)阻塞該請求,直到真正的視頻切片文件獲取到了為止。這種中間件架構(gòu)的設(shè)計(jì)避免了對傳統(tǒng)DASH播放器的改動(dòng),使得本文所提出的系統(tǒng)可以兼容傳統(tǒng)的DASH播放器。
2.3.2 自適應(yīng)碼率選擇算法
下載模塊負(fù)責(zé)向云服務(wù)器的HTTP服務(wù)器模塊發(fā)起請求。組內(nèi)的領(lǐng)隊(duì)設(shè)備負(fù)責(zé)下載合適碼率的視頻切片。為了讓用戶獲得更好的視頻質(zhì)量,客戶端需要應(yīng)對多變的網(wǎng)絡(luò)狀況以獲取合適的視頻碼率。如果客戶端所請求的視頻碼率超過了當(dāng)前的網(wǎng)絡(luò)帶寬會導(dǎo)致播放緩存不足,就會出現(xiàn)播放停頓。如果客戶端所請求的視頻碼率過于保守則會導(dǎo)致較差的視頻質(zhì)量。所以關(guān)鍵問題是如何根據(jù)多變的網(wǎng)絡(luò)帶寬選擇合適的視頻碼率。本文提出了一種自適應(yīng)碼率選擇算法來應(yīng)對多變的網(wǎng)絡(luò)帶寬。該算法會以組內(nèi)所有領(lǐng)隊(duì)設(shè)備的平均緩存大小作為考慮因素。該算法會持續(xù)監(jiān)測所有領(lǐng)隊(duì)設(shè)備的播放緩存狀態(tài),通過組內(nèi)所有領(lǐng)隊(duì)設(shè)備當(dāng)前平均緩存大小與設(shè)定的兩個(gè)閾值的比較,可以確定下一個(gè)視頻切片的合適碼率。每當(dāng)一個(gè)視頻切片下載完成,就會執(zhí)行該算法來計(jì)算下一個(gè)切片的碼率。為了保證不卡頓的情況,也就是要保證緩存始終處于安全的閾值之上,定義一個(gè)緩存大小的下限,稱為低閾值P0另一方面,要保證為用戶提供較高的視頻質(zhì)量,那么當(dāng)緩存大小足夠大的時(shí)候需要考慮提高視頻質(zhì)量,定義一個(gè)緩存大小的正常閾值C0當(dāng)緩存小于低閾值P,意味著馬上就將因?yàn)榫彺娌蛔愣鴮?dǎo)致播放停止,該算法會盡可能地選擇最低碼率的視頻切片來保證視頻流暢性。當(dāng)緩存大于低閾值P小于正常閾值C,該算法將采取平穩(wěn)的碼率選擇策略,因此會選擇與前一個(gè)視頻切片一樣的碼率等級g。如果緩沖區(qū)大于正常閾值C,即緩存足夠大的時(shí)候,該算法會根據(jù)緩存大小的變化趨勢來選擇合適的視頻碼率。如果緩存呈增長趨勢,那么該算法會選擇q或q+l碼率等級的視頻切片,反之則會選擇q或q-1碼率等級的視頻切片。每次碼率調(diào)整只會變動(dòng)一個(gè)等級,避免碼率變化跨度過大,引起用戶反感。白適應(yīng)碼率選擇算法的具體實(shí)現(xiàn)算法如下:
算法1 自適應(yīng)碼率選擇算法
1)buffer←Calculate the current buffer which is the average of all captain devices'huffer
2)q←O(the quality to download)
3)while new video segment do
4)if buffer>common threshold C then
5)q←q+l
6)if buffer 7)q←O (the poorest video quality) 8)else if huffer is decreasing rapidly then 9)q←q-1 10)Download the segment with quality q 11)end while 算法中的第1)行是算法開始計(jì)算所有領(lǐng)隊(duì)設(shè)備的平均緩存;第2)行對碼率等級進(jìn)行初始化;第3)-11)行開始進(jìn)行視頻切片的下載與視頻碼率的選擇;第4)-5)行判斷如果緩沖區(qū)大于正常閾值C則會選擇q+l等級的視頻切片;第6)-7)行判斷如果緩存小于低閾值尸則選擇最低等級的視頻切片;第8)-9)行判斷如果緩存區(qū)大小下降過快則會選擇q-1等級的視頻切片;第10)行表示如果緩存大于低閾值P小于正常閾值C時(shí)會選擇與前一個(gè)視頻切片一樣的碼率等級q。 2.3.3 D2D自組網(wǎng)的視頻分享 廣播模塊負(fù)責(zé)系統(tǒng)在客戶端設(shè)備一側(cè)的核心功能,實(shí)現(xiàn)設(shè)備對設(shè)備的連接。當(dāng)組內(nèi)的各個(gè)領(lǐng)隊(duì)設(shè)備下載完視頻碎片之后,通過D2D自組網(wǎng)將視頻碎片廣播給其他領(lǐng)隊(duì)設(shè)備和所有的組員設(shè)備。雖然組內(nèi)的各個(gè)領(lǐng)隊(duì)設(shè)備只負(fù)責(zé)下載很小一部分的視頻碎片,但是廣播模塊使得每個(gè)設(shè)備都能獲得領(lǐng)隊(duì)設(shè)備下載的內(nèi)容,這樣就實(shí)現(xiàn)了對單個(gè)設(shè)備網(wǎng)絡(luò)能力的擴(kuò)展。當(dāng)領(lǐng)隊(duì)設(shè)備向云服務(wù)器請求視頻切片時(shí),云服務(wù)器的轉(zhuǎn)碼模塊將視頻切片分割成j個(gè)碎片并被領(lǐng)隊(duì)設(shè)備所下載。針對組內(nèi)的每個(gè)超級節(jié)點(diǎn)分別建立隊(duì)列長度為L的任務(wù)隊(duì)列。如果該領(lǐng)隊(duì)設(shè)備的任務(wù)隊(duì)列所積壓的任務(wù)沒有超過隊(duì)列長度并且該視頻切片尚未被下載完全,則一個(gè)新的碎片任務(wù)會被分配至該領(lǐng)隊(duì)設(shè)備。當(dāng)遇到下載碎片失敗的情況,失敗的碎片bi將會被重新放入云服務(wù)器的任務(wù)池。
3 能耗優(yōu)化碼率選擇算法
考慮到一組用戶的參與向云端下載視頻切片的領(lǐng)隊(duì)設(shè)備數(shù)目是在不斷變化的,從而組內(nèi)的可用帶寬也是在不斷波動(dòng)的,導(dǎo)致了組內(nèi)用戶觀看的視頻質(zhì)量和能耗也是在不斷變化。如果一組用戶觀看的視頻切片的視頻質(zhì)量較高,這時(shí)對視頻切片的視頻質(zhì)量的些許提升就會導(dǎo)致嚴(yán)重的能耗損失,綜合視頻質(zhì)量的提升與損失的能耗來看這樣做是不必要的。因此D2D協(xié)作式DASH系統(tǒng)將從一組用戶中選出m個(gè)領(lǐng)隊(duì)設(shè)備負(fù)責(zé)向云服務(wù)器下載視頻切片,在保證可接受的視頻質(zhì)量前提下盡可能降低能耗。當(dāng)選擇領(lǐng)隊(duì)設(shè)備時(shí),一組用戶內(nèi)每個(gè)用戶設(shè)備的電量、CPU利用率、內(nèi)存占用和用戶在組內(nèi)停留的時(shí)間都將被考慮在內(nèi)。當(dāng)m個(gè)領(lǐng)隊(duì)設(shè)備選擇完畢,m個(gè)領(lǐng)隊(duì)設(shè)備將代表該組內(nèi)的所有用戶向云服務(wù)器發(fā)起視頻切片下載的請求,根據(jù)領(lǐng)隊(duì)設(shè)備平均緩沖和網(wǎng)絡(luò)帶寬來選擇下載合適碼率的視頻切片。
3.1 領(lǐng)隊(duì)設(shè)備
選擇更多的領(lǐng)隊(duì)設(shè)備參與視頻切片下載和分享會獲取更高的視頻質(zhì)量,同時(shí)也導(dǎo)致了更大的能耗損失。然而視頻質(zhì)量的提升與能耗損失并不成正比。本文通過計(jì)算分析峰值信噪比(Peak Sig-nal-to-Noise Ratio.PSNR)和能耗的關(guān)系來決定一組用戶需要多少領(lǐng)隊(duì)設(shè)備參與視頻切片的下載和分享。考慮這樣一個(gè)場景,一組用戶觀看一個(gè)碼率為br的視頻,每個(gè)視頻切片時(shí)長ts,則每個(gè)視頻切片的數(shù)據(jù)量為。
峰值信噪比由于它與主觀視頻質(zhì)量的高相關(guān)性被廣泛用于評估視頻質(zhì)量,峰值信噪比取值越大表示信號越清晰而噪聲越小,亦即擁有更高的視頻質(zhì)量。選取某一段視頻切片為例,將其轉(zhuǎn)碼到不同的碼率等級,從200kbps到3000kbps,以lOOkbps的粒度分為29個(gè)等級,然后分別與轉(zhuǎn)碼前的原始資源對比計(jì)算峰值信噪比,如圖2可以看出,當(dāng)視頻碼率大于lOOOkbps后峰值信噪比提升不明顯。
由于蜂窩移動(dòng)網(wǎng)絡(luò)模塊即無線網(wǎng)卡是智能手機(jī)中能耗最高的模塊之一,本文采用一種線性能耗模型來計(jì)算該模塊的能耗,通過無線網(wǎng)卡(NIC)發(fā)送數(shù)據(jù)的能耗與接收數(shù)據(jù)的能耗可認(rèn)為大體相等。所以無線網(wǎng)卡的能耗可以由網(wǎng)卡工作狀態(tài)的能耗和發(fā)送接收數(shù)據(jù)的能耗組成,如式(l)所示:
圖3表示客戶端從云服務(wù)器下載不同碼率視頻的能耗與lOOOkbps碼率視頻的能耗之比。從圖3可以看出能耗與碼率呈線性關(guān)系。由于峰值信噪比與能耗均與碼率相關(guān),并且當(dāng)碼率較高時(shí)能耗的增長顯著高于視頻質(zhì)量的提升,所以需要綜合考慮能耗與視頻質(zhì)量的關(guān)系來選擇合適的碼率。
4 實(shí)驗(yàn)結(jié)果與性能分析
4.1 實(shí)驗(yàn)環(huán)境
本文采用8核Intel Xeon E51620 CPU和16GBRAM配置的主機(jī)作為云服務(wù)器,7個(gè)Android平臺的智能手機(jī)組成一組。預(yù)先選好一段實(shí)驗(yàn)視頻,將其轉(zhuǎn)碼到不同的碼率等級,從200kbps到3000kbps,以1OOkbps的粒度分為29個(gè)等級,然后轉(zhuǎn)碼成不同目標(biāo)碼率的視頻切片。每個(gè)視頻切片包含2s的視頻內(nèi)容。原始視頻的碼率為5000kbps。
4.2影響因子c
根據(jù)式(10),影響因子c、峰值信噪比和能耗共同影響視頻碼率的選擇。當(dāng)c趨近于1時(shí),視頻質(zhì)量對碼率的影響會越來越重要。同理當(dāng)c趨近于0時(shí),能耗對碼率的影響會加重。圖4顯示了c對碼率選擇的影響,其中N=7,t=2,w=4。
當(dāng)c的取值由0到l變化時(shí),br的最優(yōu)解將會趨近更高的視頻碼率。如圖5顯示了歸一化后的峰值信噪比與能耗分別在P=0.25,0.35,0.5,0.65,0.75的極值點(diǎn)。當(dāng)c取值0.5時(shí),可以獲得較高的視頻質(zhì)量的同時(shí)降低能耗。
4.3 協(xié)作式與非協(xié)作式流媒體系統(tǒng)對比
本文在進(jìn)一步研究對比協(xié)作式與非協(xié)作式流媒體系統(tǒng)時(shí),參考了微軟的平滑式流媒體技術(shù)(Microsoft Smooth Streaming,MSS)。MSS是微軟的流媒體技術(shù)方案可作為傳統(tǒng)DASH系統(tǒng)??紤]一組用戶規(guī)模為7。能耗優(yōu)化碼率選擇算法的影響因子c設(shè)為0.5。由圖6可以得出,在網(wǎng)絡(luò)帶寬波動(dòng)劇烈的環(huán)境下,與MSS系統(tǒng)相比較,本文提出的D2D協(xié)作式DASH系統(tǒng)對可用帶寬的利用率有著顯著的提升。同樣的如圖7所示,與MSS系統(tǒng)相比,本文提出的D2D協(xié)作式DASH系統(tǒng)可以獲取更高的視頻質(zhì)量。由t=2可知每個(gè)視頻切片時(shí)長2秒,本文對組內(nèi)的所有組員進(jìn)行間隔2秒的采樣來獲取當(dāng)前的能耗狀況。同樣的,采用MSS系統(tǒng)的對照組采取同樣的采樣間隔對能耗狀況進(jìn)行檢測。表1表示了各系統(tǒng)的能耗與觀看lOOOkbps碼率視頻所消耗的能耗相對值。由表1可以得出,D2D協(xié)作式DASH所采用的能耗優(yōu)化碼率選擇算法與MSS系統(tǒng)相比較,可以減少約25%的平均能耗損失。
5 結(jié)論
考慮到DASH系統(tǒng)導(dǎo)致的鄰近用戶網(wǎng)絡(luò)帶寬競爭問題,本文提出一種D2D協(xié)作式DASH系統(tǒng),領(lǐng)隊(duì)設(shè)備通過移動(dòng)網(wǎng)絡(luò)下載視頻并通過Wi-Fi廣播分享視頻從而充分利用了組內(nèi)用戶的網(wǎng)絡(luò)帶寬??蛻舳艘灾虚g件架構(gòu)在Android平臺上實(shí)現(xiàn),使得主流支持DASH協(xié)議的播放器都可以兼容D2D協(xié)作式DASH。從而用戶可以享受更好的視頻質(zhì)量的同時(shí)不用去關(guān)心播放器的兼容性問題。為了保證高視頻質(zhì)量的同時(shí)兼顧能耗問題,本文提出了一種能耗優(yōu)化碼率選擇算法應(yīng)用在D2D協(xié)作式DASH系統(tǒng),該算法綜合考慮智能手機(jī)當(dāng)前的能耗,CPU使用率,內(nèi)存占用率與系統(tǒng)停留時(shí)間動(dòng)態(tài)選擇領(lǐng)隊(duì)設(shè)備,由領(lǐng)隊(duì)設(shè)備承擔(dān)額外的鏈路能耗,使得D2D協(xié)作式DASH系統(tǒng)可以在降低約25%的平均能耗同時(shí)保證了較高的視頻質(zhì)量。