基于能耗優(yōu)化的協(xié)作式動態(tài)自適應(yīng)流媒體系統(tǒng)

曲凱明++張小奕

摘要：針對傳統(tǒng)的HTTP動態(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è)備；碼率選擇；移動云計(jì)算

中圖分類號：TN919.8

文獻(xiàn)標(biāo)識碼：A

DOI：10.3969/j.issn.1003-6970.2015.09.002

0 引言

隨著智能手機(jī)的普及與無線通信技術(shù)的成熟，人們可以隨時(shí)隨地用手機(jī)、平板或其他移動設(shè)備觀看視頻內(nèi)容。HTTP動態(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)一組鄰近的用戶通過移動客戶端觀看同一段網(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è)備的請求并對請求的視頻資源做動態(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ù)。由于蜂窩移動網(wǎng)絡(luò)模塊是智能手機(jī)中能耗最高的模塊之一，大量觸發(fā)蜂窩移動網(wǎng)絡(luò)模塊的開啟與關(guān)閉狀態(tài)會導(dǎo)致能耗的顯著增加。本文所提出的D2D協(xié)作式DASH系統(tǒng)會在數(shù)據(jù)傳輸活躍階段避免了蜂窩移動網(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)用移動云計(jì)算思想的結(jié)構(gòu)，云服務(wù)器上存儲了原始的視頻資源，與傳統(tǒng)DASH系統(tǒng)不同的是，所提供的視頻資源是根據(jù)領(lǐng)隊(duì)設(shè)備客戶端所請求的視頻碼率動態(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ù)器模塊組成。客戶端資源管理模塊負(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播放器的改動，使得本文所提出的系統(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è)緩存大小的下限，稱為低閾值P₀另一方面，要保證為用戶提供較高的視頻質(zhì)量，那么當(dāng)緩存大小足夠大的時(shí)候需要考慮提高視頻質(zhì)量，定義一個(gè)緩存大小的正常閾值C₀當(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)整只會變動一個(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ǎ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后峰值信噪比提升不明顯。

由于蜂窩移動網(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ò)帶寬波動劇烈的環(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è)備通過移動網(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í)間動態(tài)選擇領(lǐng)隊(duì)設(shè)備，由領(lǐng)隊(duì)設(shè)備承擔(dān)額外的鏈路能耗，使得D2D協(xié)作式DASH系統(tǒng)可以在降低約25%的平均能耗同時(shí)保證了較高的視頻質(zhì)量。