宋來將,白光偉,沈 航,3,葛 暢
1(南京工業大學 計算機科學與技術學院,南京 211816)2(南京大學 計算機軟件新技術國家重點實驗室,南京 210093)3(南京郵電大學 通信與網絡技術國家工程研究中心,南京 210003)
智能手機的續航能力一直為用戶所關心,特別是Android系統的手機;且隨著智能手機功能更加豐富、帶寬的不斷提升,流媒體已經成為了手機的主要應用之一.而流媒體是一種資源消耗型的任務,會產生高能耗,制約其在手機端的長時間使用.針對這個問題,我們現在采取最多的辦法是添加一個外置的移動電源,但是移動電源的攜帶不方便且影響美觀,這只是一個折衷的辦法.對于學術界和產業界的人來說,希望能通過優化手機的操作系統和應用來降低能耗、延長手機電池的一次使用時長,比如Google有針對Google Android API的優化1.
近年來,研究人員從音視頻編解碼[1,2]、音視頻網絡傳輸[3,4]和手機屏幕背光調節[6]等幾個方面入手優化手機續航能力.不同的編解碼方式會有不同的能耗和壓縮效率:H264編碼方式能耗低但壓縮效率也低,HEVC編碼方式則壓縮效率高但能耗也高,VP9則能在壓縮效率和能耗之間提供最好的權衡[2],而選擇低效的編碼器不僅會增加網絡信道的負載,還會浪費服務器的存儲空間和能源.而根據實際的網絡狀況選擇合適的碼率、幀率以及分辨率能節省5.7%~13.9%的能量[3].還有,同時進行背光亮度和碼率的調節平均能節省19%的能耗[5].而屏幕的能耗占到了手機總體能耗的很大一部分[7],調節屏幕背光亮度成為了優化手機續航能力的一個重要方法.
值得注意的是:實時流媒體應用具有交互性強、時延敏感等特點.若將背光調節等任務遷移到云端執行會帶來較高的延遲;若將背光調節直接放在手機端上完成,則會折衷節省的能量,且需要對客戶端APP進行較大的修改才能滿足要求[7].而邊緣計算的出現恰好能彌補它們的不足:既能提供較強的計算能力,減少手機端的能耗;同時,可以降低延遲、提高實時性[15,16].除此之外,背光調節對于視覺效果的影響,雖然可以通過計算SSIM和PSNR等參數準確地度量視頻的失真情況[6],但是這只是一種客觀的度量辦法,往往與用戶實際的視覺體驗不一致;而采用完全主觀的視頻質量評估辦法來衡量失真情況[19],雖然能很好地反應實際的視覺體驗,但是在同樣的條件下不同的人卻會產生不同的感受,有較大的隨機性.
本文提出面向邊緣計算環境的智能手機背光調節機制.與現有的方案不同,將背光亮度的確定和補償等任務遷移到邊緣計算節點上完成.首先,設計由智能手機、邊緣計算節點和云端3部分組成的體系結構.然后,根據背光調節的限制條件,從背光亮度值的計算、背光亮度補償以及背光亮度保持不變的幀間隔的確定等三個方面進行背光調節機制的優化,降低計算的時間復雜度,提高執行效率.最后,搭建面向Android移動平臺的實時流媒體原型系統,實驗測試背光調節對智能手機在能耗、網絡延遲和視頻質量等方面的影響.
背光調節主要涉及3方面問題:
1)如何計算視頻幀顯示的背光亮度;
2)如何確定背光亮度保持不變的幀間隔和背光亮度值調節幅度大小;
3)是在服務器端還是客戶端確定背光調節方案.
針對問題1,文獻[6]提前獲取所有視頻幀的信息,給各個視頻幀分配允許的最小背光亮度,得到一個全局最優的背光亮度調節方案,能最大限度地減少屏幕能耗,但是會影響用戶視覺體驗,且不能適用于實時視頻的應用場景.而文獻[12]以每個視頻幀中最大像素亮度值來衡量視頻幀顯示時的背光亮度值,避免在亮度補償時出現像素亮度值溢出的情況,并采用一種貪心算法的思想,實時計算得到一個整體上近似最優的背光調節方案,但這會影響節能效果.在本文中,我們根據視頻幀的像素亮度平均值來衡量背光亮度,這樣能更好地反應整體的亮度水平,有效保證視覺效果,且擁有良好的節能效果;同時,利用連續視頻幀在時空上的強相關性,一次性計算得到連續數幀的背光亮度,減少計算的復雜度,極大地滿足實時性的要求.
針對問題2,背光亮度的調節頻率以及幅度過大會產生閃爍的問題,影響用戶視覺效果.文獻[11,13]則選擇限定相鄰視頻幀的背光亮度變化范圍,且規定了背光亮度保持不變的幀間隔.本文基于此,提前設定好背光調節的幅度范圍,然后根據手機端的背光亮度和視頻幀的像素亮度之間的關系,動態調節背光亮度保持不變的幀間隔.
針對問題3,文獻[13]選擇在客戶端進行計算,但是這樣會引入額外的消耗,抵消掉背光調節節省下來的能量.文獻[6]選擇在一個云服務器上進行計算,延遲較大,不能滿足實時性的要求.本文從實時性和節能兩方面出發,選擇在邊緣計算節點上確定和執行背光調節方案,既能滿足實時性的需求,亦能達到釋放客戶端、節省能耗的目的.
因此,本文改進和優化確定背光亮度的方案:基于貪心算法的思想,以視頻幀的像素亮度均值來衡量背光亮度;從像素亮度和對比度兩個角度出發進行背光亮度補償;利用實時視頻的特點,確定背光亮度保持不變的幀間隔;將背光亮度方案的確定遷移到邊緣計算節點上完成.
本節描述邊緣計算環境下動態背光調節所需要的背景知識.
由于現在大多數手機都是LCD屏幕,所以本文主要研究基于LCD的手機屏幕能耗分析.如圖1所示,LCD主要由三部分組成:背光源、彩色濾光片和液晶面板.LCD面板作為顯示器件,本身是不發光的,需要借助外部的光才能顯示;背光源作為發光源,由許多的發光晶體管組成,負責點亮LCD面板;彩色濾光片,根據像素的值,選擇性地過濾一些光,一般情況,像素值越大,背光源發出的光通過濾光片的數量越多.

圖1 TFT-LCD結構原理Fig.1 Structure principle of TFT-LCD
LCD在顯示圖像的時候,背光源發出的光是通過濾光片過濾之后才射出液晶面板被人眼所感知的.因此,影響人眼最終視覺感知效果的主要因素是LCD背光強度(即背光亮度)和濾光片的光透過率.而濾光片的光透過率與圖像各像素點灰度的大小(即像素亮度值)是成正比的[8].一般情況下,LCD背光強度與濾光片的光透過率的乘積等于人眼的最終視覺感知效果.
LCD功耗的主要來源是背光源,降低背光亮度是減少LCD能耗的最直接的一種方式.當降低背光亮度時,可以提高像素亮度,以作為一種亮度補償的方式.而對比度是畫面黑與白的比值,反映了從黑到白的漸變層次,比值越大,色彩的表現越豐富.對比度增強是另一種亮度補償方式,它通過增強圖像的對比度達到亮度補償的效果.
通常情況下,視頻解碼器會將視頻流壓縮數據解碼成YUV格式的原始數據,其中Y表示亮度,也就是灰度值;U和V則表示色度,主要用于描述其色彩及其飽和度,用于指定像素的顏色.由于顯示設備是使用RGB格式進行圖像的顯示的,所以在顯示之前,需要將YUV格式的原始視頻數據轉換成RGB格式的視頻數據.對于YUV和RGB之間的轉換,可以采用如下的辦法:
①像素格式由YUV轉換為RGB

②像素格式由RGB轉換為YUV

其中,Y/U/V∈[0,255],R/G/B∈[0,255].
在傳統云計算環境下,計算任務需要遷移到遠端數據中心,這就帶來了較高的傳輸延遲,可能會成為很多服務的障礙,如游戲.而邊緣計算為了簡化移動網絡的需求,選擇通過無線連接的方式,將部分任務或全部任務遷移到邊緣節點上,減少數據傳輸延時、提高手機端任務遷移的魯棒性[9].
邊緣計算網絡架構類似于CDN[10](Content Distributed Network),可以將用戶請求的資源轉發到離用戶最近的邊緣節點.與之不同的是,邊緣計算節點不僅具有存儲和分發的功能,還具有較強的計算能力,可以將一些原本需要放在云端的計算任務遷移到邊緣節點上完成,徹底解放手機端的計算能力,減少能耗,特別是對于與數據中心有較強交互性的應用,可以降低延遲、提高實時性.
圖2給出了系統的整體框架圖,主要由流媒體數據中心、手機端、邊緣計算節點組成.三者的功能如下:

圖2 系統整體框架Fig.2 System framework
1)流媒體數據中心的主要功能是提供實時視頻源,包括不同碼率、分辨率的視頻,還可以負責用戶身份的有效性認證,當用戶向流媒體數據中心發出視頻流的請求時,流媒體數據中心首先會驗證用戶身份的有效性,如果通過,然后將幀數據發送到邊緣計算節點,由邊緣計算節點進行轉碼適配和轉發;
2)邊緣計算節點則主要用于確定背光調節方案、對視頻數據進行轉碼和轉發、定期收集手機端的信息;
3)手機端則負責接收邊緣計算節點發送過來的視頻數據,然后解碼顯示.
本文側重于研究邊緣計算節點與手機端在進行背光調節之間的關系.圖3給出了邊緣計算節點與手機端的各功能模塊及其交互情況.

圖3 手機端與邊緣計算節點功能模塊及交互流程Fig.3 Function module and interaction process between smartphone and edge-computing node
邊緣計算節點由選擇模塊、YUV獲取模塊、背光調節模塊、編碼模塊、網絡狀況預測模塊等組成.選擇模塊是根據手機端傳遞過來的狀態(如背光亮度水平、剩余電量等)來選擇是否執行背光亮度調節,比如:當剩余電量超過80%時,則直接將YUV數據傳遞給編碼模塊;否則,選擇執行背光亮度調節,將YUV數據和手機端背光亮度值傳遞給背光調節模塊.背光調節模塊則在保證用戶體驗的前提下,根據視頻幀的像素亮度和手機端的背光亮度,確定視頻幀在手機端顯示時的背光亮度,發送給客戶端;同時為了減弱背光亮度降低對視覺效果的影響,會執行視頻幀的像素亮度增強和對比度增強.網絡狀況主要由RSSI(Received Signal Strength Indicator)來表征,網絡狀況預測模塊使用RSSI值來預測網絡狀況,根據網絡狀況的預測值選擇合適的編碼參數,并將編碼參數發送給邊緣計算節點[3].編碼模塊依據網絡狀況選擇合適的編碼參數,如分辨率、碼率等,對音視頻進行壓縮編碼,并將壓縮編碼的數據發送給客戶端.
客戶端則包括解碼、播放、網絡狀況獲取、背光控制、背光亮度獲取等模塊.解碼模塊負責將從邊緣計算節點傳遞來的編碼幀進行解碼.播放模塊主要負責音、視頻數據的播放.背光控制模塊則依據邊緣計算節點發送過來的背光亮度值,調用背光調節的系統接口實時調節背光值.網絡狀況獲取模塊則負責定期收集手機端所處網絡環境中的RSSI值,并發送給邊緣計算節點的網絡狀況預測模塊.
背光調節模塊是整個體系架構中最主要的一個模塊.其工作流程是:當流媒體數據傳輸到邊緣計算節點時,利用其計算能力強、可交互性高、延遲低等特點,首先分析視頻幀的像素亮度,并與手機端的背光亮度水平作比較,確定視頻幀在手機端顯示時的背光亮度值;然后針對視頻幀進行亮度補償,以彌補背光亮度降低對視頻質量的影響;最后,利用流媒體自身的特性,以及連續幀像素亮度之間的關系,確定背光亮度保持不變的幀間隔.本文第4節首先描述背光調節的問題,然后描述背光亮度值度量、背光亮度補償以及背光亮度保持不變的幀間隔的確定的詳細過程.
前面在第三節,我們簡單介紹了背光亮度調節的基本原理:在降低背光亮度的大小同時,對視頻幀進行亮度補償.所以需要在保證視頻質量的前提下,最大化節能效果.
假定有N個視頻幀F={f1,f2,…,fN},每幀fi對應一個背光亮度值Bi,i=1,2,…,N;背光亮度與能耗之間存在映射關系E(·),則目標函數為:
(1)
同時,滿足如下的限制條件:
(2)
Bi∈[Bi-1-Δb,Bi-1+Δb)]
(3)
L≥Lmin
(4)
式(2)是一種亮度補償會造成失真的限制,即背光亮度的比例R要比幀像素亮度的最大值Ym(在默認情況下,像素亮度值是[0,255]中的整數值)與255的比值大.為了不影響視頻幀的顯示質量,會調整視頻幀所有像素的亮度,這樣當前視頻幀的亮度值會變為原來的1/R倍,若不滿足限制(2)就會使得亮度補償之后像素亮度值會溢出.限制(3)則體現了為了避免出現屏幕閃爍的現象,連續幀顯示時的背光亮度變化不宜過大,即相對于前一幀允許最大有Δb的背光亮度變化.限制(4)則表示了一種硬件性能上的限制.由于應用背光調節的方案是需要一定的計算能力的,若是對每個視頻幀都調整背光亮度,一方面會減弱背光調節的節能效果,另一方面會增加整體的延遲.我們規定背光亮度保持不變的幀間隔L至少要持續Lmin,即Lmin的幀的背光亮度會保持相同的水平.
基于我們的研究對象是實時視頻,延遲是其中的一個重要性能指標,為了提高本文研究的實用性,做如下的優化:
1.為了能實時獲得視頻幀對應的背光亮度,我們利用貪心算法的思想,求解背光亮度局部最優值;
2.為了提高節能的效率,不要求視頻幀的所有像素點都滿足(2),允許一定比例的像素亮度值溢出,若像素亮度補償值超出范圍,直接賦值為255;
3.由于視頻幀之間存在一定的時空相關性,如在H.264編碼方式中B幀和P幀都參考I幀,而這種參考關系一旦跨越了關鍵幀間隔,相關性會減弱,不再具有較好的傳遞性;另外,增加上限值可以減少計算的復雜度[11].所以,我們規定L∈[Lmin,Lmax].
為了減少計算背光亮度值的開銷,會在一定時間內保持背光亮度不變.于是,我們選擇計算長度為L的視頻幀亮度均值來衡量整體亮度的水平,連續L幀的亮度均值定義如下:
(5)


(6)
(7)
考慮到限制(3),我們規定:相鄰幀背光亮度變化閾值為θ.當計算得到的背光亮度值Bi與從手機端獲取的背光亮度值Bc之間的差值大于θ時,則背光亮度調節幅度為Δb;否則,背光亮度調節幅度為1.本文將Δb置為5,θ置為10.

算法1.視頻幀顯示時背光亮度值
1Input:當前手機端的背光亮度值Bc背光亮度保持不變的幀間隔L
3ift 6endif 7 根據幀像素亮度計算視頻幀顯示時的背光亮度Bi 8ifBc>Bithen 9ifabs(Bc-Bi) < θthen 11else 13endif 14else 15ifabs(Bc-Bi)< θthen 17else 19endif 20endif 為了彌補背光亮度降低對視頻顯示質量的影響,我們采取的辦法是按比例增加每幀的像素亮度和對比度.具體的定義如下: (8) (9) 亮度增強系數和對比度增強系數是根據幀的實際內容動態調整來確定的.根據式(8)分析可知,當像素亮度的均值較大時,大多數像素點包含較高的亮度值,此時如果對比度增強系數過大,會導致過多的像素點亮度值溢出、造成較嚴重的畫面失真.本文以亮度均值的平方根為自變量來度量對比度增強系數,定義如下: (10) 由于亮度補償之后,可能會出現像素亮度值的溢出.因此,本文引入一種反饋機制,對亮度增強系數進行調節:當像素亮度值溢出的個數超出閾值,會減少亮度增強系數;然后重新計算像素的亮度值,并記錄亮度值溢出的像素個數.循環若干次,直到亮度值溢出情況低于閾值.亮度增強系數反饋調節為 (11) 其中,k初始值為0,隨著失真度的增加而增加,且α1最小為1. 結合式(8)~式(11),當k增大后,α1減小,Y′會減小;同時,亮度值溢出的像素個數會減少,背光亮度補償對視頻幀質量的影響也會減小.像素亮度值溢出的比例D為 (12) 其中,No為亮度值溢出的像素總數. 由于迭代次數太大會增加延遲,不適合實時視頻的應用場景.于是,定義加速背光亮度方案收斂的公式為 (13) (14) 其中σ為調整的基準參數,默認為0.1;η為相對失真度;S為人眼能接受的最大失真度,默認為1%,可以根據實際需求進行修正;T為像素的總數,由視頻分辨率來決定. 對于背光亮度保持不變的幀間隔L的確定,我們利用了與實時流媒體有關的兩個參數:關鍵幀間隔與幀緩存大小.關鍵幀間隔大小反應了編碼的最小連續幀數,幀緩存大小則體現了允許緩存的最大幀個數.考慮到實時流媒體的特點,本文將Lmin表示為為關鍵幀間隔大小,而Lmax設為幀緩存的大小.當連續兩幀之間的亮度差距超過閾值,那么將L減小;否則,增大L,具體描述見算法2.L的初始值為Lmin. 算法2描述了確定背光亮度保持不變的幀間隔的過程.第3行表示計算當前幀的像素亮度均值,時間復雜度為O(R×C);第4~15行表示根據相鄰幀之間的像素亮度均值的差值來決定背光亮度保持不變的幀間隔,時間復雜度為O(1).所以,算法2的時間復雜度在于計算幀的像素亮度值,所以時間復雜度為O(R×C). 本節搭建Android環境下的實時流媒體原型系統,用于測試背光調節對客戶端在節能、網絡延遲、視頻質量等方面的實際影響.原型系統主要由三部分組成:流媒體服務器、邊緣計算節點以及智能手機. 選用Mi 6智能手機,配置Qualcomm Snapdragon 835處理器,8核16線程,主頻2.45GHz;6GB RAM;支持IEEE 802.11n WiFi和4G/3G/2G;Android 7.1.1操作系統.流媒體服務器使用阿里云的服務器,配置Intel(R)Xeon(R)CPU E5-2682 v4的處理器,1核2線程,主頻為2.50GHz;2GB RAM;Ubuntu 16.04 64位.邊緣計算節點的配置為Intel Core i7 4790處理器,4核8線程,主頻為3.6GHz;16GB RAM;128GB固態硬盤(SSD). 算法2.背光亮度保持不變的幀間隔的確定1 Input:背光亮度保持不變的幀間隔L、關鍵幀間隔Lmin、幀緩存Lmax2 Output:L′3 計算幀像素亮度Yi4 if abs( Yi- Yi-1)> θ then5 if L > Lmin then6 L′ ← L-Lmin7 else8 L′ ← Lmin9 end if10 else 11 if L < Lmax then12 L′ ← L + Lmin13 else 14 L′ ← Lmax15 end if16 end if17 return L′ 智能手機安裝的程序有GWPlayer、Trepn Profile,GWPlayer是我們自主研發的一款APP,主要功能包括實時視頻(RTMP/RTSP)的播放、背光的控制與反饋、網絡狀況的監控.Trepn Profile可以從各大應用商店下載,主要用于能耗的測量.服務端使用SRS*https://github.com/ossrs/srs來提供四種分辨率(1080p/720p/480p/360p)的實時視頻流,包括News(背景變化小)和Game(背景變化大)兩種類型,每種時長2min.邊緣計算節點使用FFmpeg*http://ffmpeg.org來實現背光方案的確定、亮度增強與對比度增強以及轉碼與轉發. 為了提高實驗數據的參考價值,每個實驗都運行了5次,然后取平均值,以減少數據隨機性.為了不失一般性,在實驗之前,我們將智能手機充電至100%,且終止掉除系統進程之外的其他應用程序,以減少其他因素的影響. 在不考慮網絡預測的前提下,我們做兩類實驗:一類是有背光調節,另一類是沒有背光調節.每類分別測量手機端在播放兩種不同類型、四種不同分辨率的視頻的能耗和延遲情況. 為了實驗的方便,選擇測量播放2min時長視頻的總體能耗和延遲.其中,總體能耗是利用Trepn Profile來測量GWPlayer播放2min時長的視頻的能耗,而總體延遲則通過記錄播放完成2min時長的視頻實際所需要的時間增量來衡量. 由圖4可知,分辨率的越大,能耗和延遲也會越大.分辨率越大,會需要更多的處理時間.同樣,在采用背光調節方案之后,會增加一定的延遲,平均會增加300ms.延遲的增加主要是由于在采取背光亮度方案之前,需要對視頻數據進行解碼,這是一個計算密集型的操作.而采用背光調節方案可以減少能耗,且平均能節省20%~30%的能耗.由于實驗是采用2min時長的視頻數據,延遲的增加會折衷能耗的節省.但隨著視頻長度的增加,相對于300ms左右的絕對延遲增量,能耗的絕對減少量會相當可觀.所以,對于長時間的視頻數據,采用背光調節方案會有良好的表現. 同時,可以結合圖4(a)和圖4(b)的有背光調節能耗2的情形,比較可以發現,News類型的視頻在采用了背光調節之后會比Game類型的視頻節能效果更好,這主要是因為相對于News中的場景相對固定而言,Game中的場景變化較為頻繁,這樣會導致背光亮度會連續地增加或者減少,反而增加了能耗.所以,頻繁改變背光亮度是不合適的,而應該選擇一個合適的背光亮度保持不變的幀間隔. 為了衡量亮度增強和對比度增強等亮度補償方式對視頻質量的影響,我們將經亮度補償之后的視頻保存到本地,與原始視頻進行比較,計算它們的SSIM[18]和PSNR.測量結果顯示平均能獲得28.50dB PSNR和0.998 SSIM.在不考慮視頻傳輸、解碼等因素的影響下,像素亮度增強造成的亮度值溢出是視頻質量下降的主要原因,所以像素亮度是影響SSIM和PSNR的關鍵因素.而視頻通過無線網絡傳輸的質量損失度一般在20~25dB是可以接受的[16].因此,本文提出的亮度補償方法能獲得較好的視頻質量. SSIM和PSNR等指標是從客觀的角度來衡量視頻質量的,與主觀的視覺感受是有差別的.于是,我們隨機選取經亮度補償的視頻和原始的視頻分別在屏幕上顯示時的幀畫面對比情況,如圖5所示.每張圖左邊是有亮度補償的視頻,右邊是原始的視頻.經觀察可知,無論是色澤和飽和度,還是像素亮度和對比度,有背光調節與無背光調節差異較小:在圖5(a),前者比后者的效果遜色些;在圖5(b)中,前者與后者的效果基本一致;在圖5(c)中,前者比后者效果更好.像素亮度越大,經亮度增強之后,出現像素亮度值溢出的概率越大. 圖5 有、無背光調節的主觀視頻質量對比Fig.5 Subjective video quality contrast with or without backlight scaling 另外,由于不同人對同一視頻會有不同的視覺感受.為了驗證本文提出的背光調節方法的有效性,我們做了一組調查實驗:隨機找到50位實驗者,在不告知其是否有背光調節的前提下,讓他們依次觀看多組視頻,并收集他們觀看視頻之后的感受.實驗者會給視頻打分,分數從1~5,1分表示背光變化容易被察覺到,5分則表示背光的改變很難被發現. 由圖6可知,平均滿意度為3.17,說明背光亮度的變化是令人滿意的,不容易被人察覺到.因此,本文采取的背光亮度調節方法,在降低背光亮度的情況下,仍能保持較好的視覺體驗. 圖6 視頻質量滿意度情況Fig.6 Satisfaction degree about video quality 在上面實驗的基礎上,我們做一類實驗:針對News類型的視頻,將背光調節放到手機端來執行,測量2min時長視頻的總體能耗和延遲. 由圖7可知,在邊緣計算節點執行背光亮度調節比在手機端上的節能效果更好,而延遲方面兩者相差并不大,甚至隨著分辨率的增加,前者的延遲反而會比后者還要低一些.這主要是因為除了執行背光調節方案的位置不同之外,其他執行流程基本相同:分析流、獲取背光亮度方案、解碼煊染等.而相對而言,邊緣計算節點擁有更強的計算能力,執行背光調節效率會更高,即使是高質量的視頻亦能較快獲得結果.所以邊緣計算節點在處理高分辨率的視頻時整體上能獲得更低的延遲.當在邊緣計算節點上確定好背光亮度調節方案之后,手機端只需根據發送過來的背光亮度流進行背光亮度控制即可,而不需要再對流媒體進行分析,所以節能效果會更好. 圖7 手機端和邊計算節點的能耗和延遲對比Fig.7 Comparison of energy consumption and delay between smartphone and edge-computing node 本文提出了面向邊緣計算環境的智能手機背光調節機制,提高手機端續航能力.其核心思想是將背光亮度值的確定和背光亮度補償等任務遷移到邊緣計算節點上完成.其他類似的應用程序只需要添加背光控制功能就能快速接入該系統,且該系統既能滿足實時流媒體的要求,也能適用于點播的應用場景,系統使用范圍較廣.實驗結果表明,在保證視頻質量和延遲的前提下,該機制能達到較好的節能效果.后續工作包括: 1)研究OLED的背光調節方案,提高系統適應性; 2)結合視頻編解碼和傳輸,進一步優化視頻在移動端的能耗.5.3 背光亮度補償

5.4 背光亮度保持不變的幀間隔的確定
6 實驗與性能分析

6.1 背光調節對客戶端的影響


6.2 邊緣節點對客戶端能耗的影響

7 結束語