沈 專,白光偉,沈 航

(南京工業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,南京 211816)

1 引 言

云游戲[1]是眾多云服務(wù)中的一種,即是基于云計(jì)算的游戲模式.在該模式下,游戲玩家只需要一臺(tái)可以上網(wǎng)的電腦即可,而無(wú)需3D游戲所需要的高端顯卡、大存儲(chǔ)內(nèi)存、高配置的CPU等硬件.云游戲服務(wù)商提供云服務(wù)器,所有游戲都在服務(wù)器上運(yùn)行,并實(shí)時(shí)將渲染完成的游戲畫(huà)面通過(guò)網(wǎng)絡(luò)傳輸給游戲玩家,因此游戲玩家的客戶端只需要基本的視頻解壓能力[3].用戶可以在任何地方任何時(shí)間體驗(yàn)最新的電腦游戲,游戲開(kāi)發(fā)者也可以根據(jù)云游戲系統(tǒng)特定的硬件配置來(lái)優(yōu)化他們的游戲.

云游戲以一種全新的方式向用戶提供更高品質(zhì)的游戲體驗(yàn).云游戲服務(wù)商為了節(jié)省硬件成本[4],采用了虛擬化技術(shù)[5]在一個(gè)GPU上同時(shí)運(yùn)行多個(gè)游戲.然而,由于GPU處理圖像操作的異步性和非搶占性,因此存在著資源分配不平衡的問(wèn)題,導(dǎo)致游戲服務(wù)等級(jí)協(xié)議(Service Level Agreement,簡(jiǎn)稱SLA)得不到保證,這會(huì)導(dǎo)致有些游戲的幀數(shù)很高,有些游戲卻很低,并且客戶端在無(wú)線網(wǎng)絡(luò)環(huán)境下,圖像經(jīng)過(guò)傳輸之后會(huì)丟失一部分幀,使本來(lái)幀數(shù)就不高的游戲,畫(huà)面出現(xiàn)嚴(yán)重的花屏、卡頓現(xiàn)象,這樣嚴(yán)重影響服務(wù)質(zhì)量(Quality of Service),這可能會(huì)促使用戶放棄云游戲.

針對(duì)上述問(wèn)題,本文提出一種基于幀率控制的FEC補(bǔ)償策略.先通過(guò)幀率控制算法,使用反饋控制模型[2]和API攔截技術(shù)為每個(gè)游戲調(diào)度GPU資源,控制游戲占用GPU資源的時(shí)間,從而達(dá)到對(duì)游戲幀數(shù)的控制,確保每個(gè)游戲滿足最低的SLA需求,即至少每秒30個(gè)幀.在幀率控制的基礎(chǔ)上,再通過(guò)FEC補(bǔ)償算法,根據(jù)網(wǎng)絡(luò)狀況確定適量的冗余包,恢復(fù)在傳輸過(guò)程中丟失的源數(shù)據(jù)幀,從而達(dá)到節(jié)省網(wǎng)絡(luò)帶寬,優(yōu)化游戲畫(huà)面,提高服務(wù)質(zhì)量的目的.

本文的結(jié)構(gòu)安排為:第2節(jié)介紹體系結(jié)構(gòu);第3節(jié)提出幀率控制算法;第4節(jié)提出FEC補(bǔ)償算法;第5節(jié)是實(shí)驗(yàn)與性能分析;第6節(jié)總結(jié)全文.

2 體系結(jié)構(gòu)

如圖1所示,客戶端和服務(wù)器建立連接之后,客戶端的狀態(tài)監(jiān)視器就一直向服務(wù)器反饋客戶端的丟包率、FPS、帶寬等信息.服務(wù)器端的數(shù)據(jù)處理器接受到數(shù)據(jù)之后,過(guò)濾掉過(guò)時(shí)信息,把最新的信息發(fā)送給FEC編碼器,FEC補(bǔ)償算法將根據(jù)這些信息計(jì)算冗余包的數(shù)量.幀率控制算法是基于VMware的GPU虛擬機(jī)架構(gòu)實(shí)現(xiàn)的,利用了GPU虛擬化技術(shù)[5]和API攔截技術(shù).游戲?qū)嵗歼\(yùn)行在同一宿主機(jī)上的不同VM虛擬機(jī)中.

圖1 系統(tǒng)整體框架圖Fig.1 Picture of whole system framework

當(dāng)游戲調(diào)用一個(gè)圖形庫(kù)函數(shù)時(shí),首先這個(gè)調(diào)用請(qǐng)求會(huì)通過(guò)客戶操作系統(tǒng)中的圖形庫(kù)函數(shù)發(fā)送到客戶GPU驅(qū)動(dòng)程序上進(jìn)行處理,而后,GPU驅(qū)動(dòng)程序會(huì)與虛擬機(jī)監(jiān)控器進(jìn)行通信,并向其發(fā)送一個(gè)命令包,虛擬機(jī)監(jiān)控器把命令包插入到虛擬GPU的I/O隊(duì)列中,且其宿主GPU任務(wù)分發(fā)器會(huì)對(duì)隊(duì)列中的任務(wù)進(jìn)行分發(fā)處理.在任務(wù)分發(fā)器與驅(qū)動(dòng)程序之間進(jìn)行API攔截,當(dāng)攔截到客戶操作系統(tǒng)向VMware虛擬機(jī)監(jiān)控器發(fā)送的圖形庫(kù)函數(shù)的請(qǐng)求時(shí),通過(guò)幀率控制算法調(diào)節(jié)FEC編碼所需的幀;最后再執(zhí)行原來(lái)的請(qǐng)求處理流程,使得客戶操作系統(tǒng)發(fā)來(lái)的函數(shù)調(diào)用請(qǐng)求被宿主操作系統(tǒng)所處理,并將最后的執(zhí)行結(jié)果以相同的幀率進(jìn)行視頻壓縮編碼.

在壓縮編碼之后,將視頻幀發(fā)送到FEC編碼器,并將視頻幀分組之后,分析當(dāng)前客戶端反饋回來(lái)的網(wǎng)絡(luò)帶寬等信息,調(diào)用FEC補(bǔ)償算法確定冗余包的數(shù)量,為了降低總的丟包率,使用盡可能少的冗余包,然后將源數(shù)據(jù)包和冗余數(shù)據(jù)包編碼成FEC數(shù)據(jù)包,若發(fā)現(xiàn)源數(shù)據(jù)幀不夠多,就向幀率控制器請(qǐng)求提高游戲的幀率.再將FEC數(shù)據(jù)包發(fā)送到數(shù)據(jù)包緩存中,最后經(jīng)過(guò)網(wǎng)絡(luò)傳輸?shù)娇蛻舳?客戶端在接受到這些數(shù)據(jù)包時(shí),因?yàn)榫W(wǎng)絡(luò)環(huán)境原因,可能已經(jīng)丟失了一部分源數(shù)據(jù)包,所以需要冗余數(shù)據(jù)包來(lái)彌補(bǔ)恢復(fù)源數(shù)據(jù),從而減少了畫(huà)面的失真,提高了服務(wù)質(zhì)量.

3 幀率控制

本節(jié)介紹幀率控制算法,用于保證運(yùn)行在同一個(gè)GPU上的多個(gè)游戲滿足SLA,從而確保FEC補(bǔ)償算法編碼時(shí)所需的幀率,提高FEC編碼有效性.

在真實(shí)游戲中,游戲的幀數(shù)會(huì)隨著游戲場(chǎng)景的變化而變化.其幀數(shù)是由GPU的渲染時(shí)間Tgpu和CPU的計(jì)算時(shí)間Tcpu決定[6];因此可通過(guò)設(shè)置睡眠時(shí)間來(lái)控制游戲的幀數(shù).

當(dāng)游戲的每一幀調(diào)用圖形庫(kù)的渲染函數(shù)時(shí),利用攔截技術(shù)在GPU被調(diào)用之前插入一個(gè)Sleep函數(shù),因此可以通過(guò)設(shè)置睡眠時(shí)間來(lái)控制虛擬機(jī)中游戲的幀率.假設(shè)游戲的FPS值為F,那么可以用如下公式表示睡眠時(shí)間Tsleep:

(1)

考慮到實(shí)際輸出值FPS并不總是期望的值,很多不確定因素會(huì)影響每一幀的總時(shí)間,例如,當(dāng)切換到一個(gè)有更多敵人、樹(shù)木和建筑物的場(chǎng)景時(shí)將比上一個(gè)場(chǎng)景需要更多的Tcpu和Tgpu,其次,由于圖形API以異步方式調(diào)用,因此游戲渲染時(shí)間Tgpu不能簡(jiǎn)單獲取到.盡管如此,當(dāng)前幀的渲染時(shí)間可以通過(guò)歷史幀的渲染時(shí)間來(lái)進(jìn)行估算,這是因?yàn)?D應(yīng)用程序中的每一幀實(shí)際上都在前一幀的基礎(chǔ)上稍微做些變化而生成的.雖然這種方法只能預(yù)測(cè)圖形庫(kù)函數(shù)的執(zhí)行時(shí)間,卻是一種行之有效的方法.

用Fout表示控制算法輸出的FPS值(即每一幀時(shí)間的倒數(shù)),由于CPU和GPU執(zhí)行時(shí)間在運(yùn)行時(shí)被計(jì)算得出,可以假設(shè)它們?yōu)槌Ａ?因此,Fout和Tsleep之間實(shí)際上是一個(gè)反比例關(guān)系,其反比例關(guān)系表示如下:

(2)

3.1 反饋控制

反饋控制系統(tǒng)如圖2(a)所示,Gc(Z)是PI控制器[7]的傳遞函數(shù);Gp(Z)是云游戲系統(tǒng),即被控系統(tǒng)的傳遞函數(shù);H(z)是測(cè)量當(dāng)前游戲反饋的FPS值的感應(yīng)器傳遞函數(shù).為了控制Fout等于r,可以看作是一個(gè)典型的離散時(shí)間控制問(wèn)題,r是參數(shù),F是控制輸入,Fout是控制輸出.

在每次GPU計(jì)算循環(huán)結(jié)束,系統(tǒng)的測(cè)量輸出值就是系統(tǒng)的輸入值,所以傳遞函數(shù)應(yīng)為:H(z)=1.因?yàn)镻I控制器能使整個(gè)系統(tǒng)得到穩(wěn)定和收斂[2],所以調(diào)用PI控制器,其傳遞函數(shù)可表示為:

(3)

式中,kp表示PI控制器的比例控制常數(shù),ki表示累積控制常數(shù),必須給這兩個(gè)控制常量賦予合適的值才能使系統(tǒng)穩(wěn)定和收斂.接下來(lái)要計(jì)算被控系統(tǒng)的傳遞函數(shù)Gp(Z).用公式(1)替換公式(2)中的Tsleep可以得到:

(4)

對(duì)公式(4)做z變換[2]可得被控系統(tǒng)的傳遞函數(shù)Gp(Z),但直接對(duì)其做變換有點(diǎn)困難.對(duì)公式(4)兩邊取對(duì)數(shù),可得:

(5)

y=ln1000+h

(6)

圖2 控制算法閉環(huán)模型Fig.2 Closed-loop model of control algorithm

(7)

為了系統(tǒng)的穩(wěn)定性,令公式(7)中右邊數(shù)的分母(kp+ki+1)·z-(kp+1)為0,那么就可以得到:

(8)

公式(8)即是整個(gè)控制系統(tǒng)的極點(diǎn)所在.根據(jù)控制理論[2]可知,當(dāng)極點(diǎn)在以原點(diǎn)為圓心的單位圓內(nèi)時(shí),也就是:

(9)

這時(shí),整個(gè)控制系統(tǒng)是穩(wěn)定和收斂的.

3.2 算法實(shí)現(xiàn)

本文旨在控制FPS,通過(guò)在調(diào)用渲染函數(shù)Present之前插入Sleep函數(shù)來(lái)拖延每一幀的時(shí)間,從而嚴(yán)格控制每一次迭代的時(shí)間.

圖3 算法執(zhí)行流程Fig.3 Execution process of the algorithm

圖3顯示了這種設(shè)計(jì)思想.如圖所示,每一幀都是由CPU執(zhí)行時(shí)間、睡眠時(shí)間和GPU執(zhí)行渲染函數(shù)所花費(fèi)的時(shí)間構(gòu)成.CPU的執(zhí)行時(shí)間能夠在每次迭代中精確計(jì)算出;雖然渲染函數(shù)的執(zhí)行是異步的,但是GPU執(zhí)行時(shí)間可以估算得到,那么只要給出合理的睡眠時(shí)間,每幀的時(shí)間就能被固定,整個(gè)游戲的FPS值也能夠被嚴(yán)格控制住.

在幀率控制算法中,設(shè)置最低標(biāo)準(zhǔn)為30幀,當(dāng)遇到一個(gè)游戲的FPS高于30時(shí),遍歷游戲列表,若有游戲的FPS低于30,那么該游戲釋放一部分資源,若沒(méi)有,該游戲繼續(xù)運(yùn)行;當(dāng)遇到一個(gè)游戲的FPS低于30時(shí),算法就會(huì)讓高于30個(gè)PFS的游戲釋放一部分資源,并把這些資源給低于30個(gè)FPS的游戲.幀率控制算法的具體實(shí)現(xiàn)如下:

算法1.幀率控制算法

1.setcriteriatoconstant//constant是個(gè)標(biāo)準(zhǔn),設(shè)置為30

2.whileTRUEdo

3.getFout;

4.ComputerObjectsInFrame();

5.DrawShapes(VGA_Buffer);

6.ifFout>criteriathen

//查找FPS低于30的游戲

7.Game_below_30_list= search(Game_all_list);

8.n= Length(Game_below_30_list);

9.ifn> 0then

10.r=r-1; //設(shè)置該游戲應(yīng)該運(yùn)行的FPS參考值

11.elsethenreturn;

12.endif

13.elseifFout

14.Game_above_30_list=search(Game_all_list);

15.foreachGameiinGame_above_30_listdo

16.ri=ri- 1;

17.endfor

18.endif

19.d=r-Fout; //計(jì)算誤差

20.F=facebackControl(d); //反饋控制器

21.sleep_time=calculateSleeptime(F);

22.Sleep(sleep_time);

23.Present();

24.endwhile

4 FEC補(bǔ)償算法

本節(jié)介紹FEC補(bǔ)償算法,該算法基于特定的幀率進(jìn)行編碼,在幀率控制算法的基礎(chǔ)上可以獲得編碼所需的幀率,提高編碼的有效性;該算法根據(jù)客戶端反饋的信息調(diào)節(jié)冗余數(shù)據(jù)包的數(shù)量,在考慮到一定丟包率的情況下,以最少的冗余數(shù)據(jù)包恢復(fù)丟失的源數(shù)據(jù);并且在云游戲環(huán)境中,能夠很好的應(yīng)對(duì)客戶端無(wú)線網(wǎng)絡(luò)環(huán)境不穩(wěn)定和丟包現(xiàn)象.

4.1 非均勻FEC編碼

FEC是一類用于有損信道通信的編碼,通過(guò)增加冗余數(shù)據(jù)來(lái)提高抵御錯(cuò)誤的能力,如圖4所示,一個(gè)FEC塊有n個(gè)數(shù)據(jù)包,其中包括k個(gè)原始數(shù)據(jù)包和(n-k)個(gè)冗余數(shù)據(jù)包.在FEC(n,k)編碼中,(n-k)個(gè)冗余數(shù)據(jù)包用于恢復(fù)k個(gè)原始數(shù)據(jù)包.如果一個(gè)FEC塊的任意k個(gè)包被正確接受,就可以重構(gòu)出所有的k個(gè)原始數(shù)據(jù)包.

在本文中,分別設(shè)計(jì)了對(duì)I幀的幀級(jí)別編碼和對(duì)P幀的分組級(jí)編碼方案;在這樣一個(gè)FEC編碼方案中,關(guān)鍵問(wèn)題是確定I幀和P幀的冗余數(shù)量和每個(gè)FEC塊中P幀的數(shù)量.使用Gibert模型[8]對(duì)無(wú)線網(wǎng)絡(luò)進(jìn)行建模,假設(shè)一個(gè)GOP由M個(gè)源數(shù)據(jù)幀組成,用編號(hào)m標(biāo)識(shí)(1<=m<=M),Sm表示幀的大小.dm表示幀m在數(shù)據(jù)傳輸和視頻解碼過(guò)程中的質(zhì)量失真,其主要是因?yàn)閭鬏敃r(shí)損傷和解碼時(shí)依賴于父幀造成的,也稱為幀m的總失真,并且根據(jù)仿射模型[9]有:dm=tm+fm,其中tm是截?cái)嗍д?即通過(guò)網(wǎng)絡(luò)傳輸時(shí)丟包引起的視頻幀m的失真.fm是漂移失真,即由于父幀不能完全重構(gòu)引起的失真.πB表示丟包率,RTT表示環(huán)路延遲時(shí)間,μ表示當(dāng)前可用帶寬.

圖4 非均勻的FEC編碼方式Fig.4 Non-uniform FEC coding

4.2 算法實(shí)現(xiàn)

我們提出一種基于GOP(group of picture)的非均勻FEC編碼.思路是基于I幀和P幀的數(shù)據(jù)優(yōu)先級(jí),通常I幀比P幀占有更多的比特.端到端的視頻幀延遲不能超過(guò)給定的期限時(shí)間T,這是確定FEC冗余數(shù)的一個(gè)挑戰(zhàn)性任務(wù).一方面,提高冗余能夠減緩傳輸丟幀,但增加了端到端的延遲.用較少的冗余數(shù)據(jù)包,接收端可以更早開(kāi)始解碼過(guò)程,但可能犧牲恢復(fù)性[10].下面將介紹I幀和P幀的FEC冗余估計(jì)算法.

(10)

(11)

(12)

冗余值可以用I幀所描述的步驟確定.如圖4所示,假設(shè)把P幀分成t個(gè)分組,每個(gè)分組代表一個(gè)FEC塊.分組的位置數(shù)表示最后P幀的索引數(shù).例如,一個(gè)GOP中有29個(gè)P幀,分成r1=13,r2=22,r3=30,分配的冗余分組數(shù)是R(r1)=20,R(r2)=15和R(r3)=12.可以描述這個(gè)分組中P幀的總失真為:

(13)

其中,tm表示這一分組的截?cái)嗍д?fri+1表示后繼分組的漂移失真.因?yàn)橥粋€(gè)分組中的P幀被編碼到一個(gè)FEC塊中,所以只要接收足夠的FEC包,恢復(fù)過(guò)程就開(kāi)始執(zhí)行.因此可以得出P幀的總失真如下:

(14)

算法2.FEC補(bǔ)償算法

1.Input:video frames within a GOP,RTT,T,kmin=10;

2.Output:{km,nm}1<=m<=M;

6.forj=1toRdo

7.index=0;

8.dtemp=0; //dtemp為臨時(shí)變量,用于比較.

9.fori=2toMdo

10.R(i)=R(i)+1; //加一個(gè)I幀.

12.R(i)=R(i)-1;

14.index=i;

16.endif

17.endfor

18.endfor

5 實(shí)驗(yàn)設(shè)計(jì)和性能分析

在實(shí)驗(yàn)室局域網(wǎng)環(huán)境下搭建了一個(gè)仿真實(shí)驗(yàn)床(testbed),如圖5所示,用于測(cè)試提出的算法在實(shí)際應(yīng)用時(shí)的效果.實(shí)驗(yàn)需要一臺(tái)服務(wù)器、一臺(tái)路由器和多臺(tái)客戶端.服務(wù)器配置Intel Core i7 4790 四核處理器,主頻3.6GHz,16GB RAM;AMD HD6750,核心頻率800MHz,顯存1024M;安裝64位Windows7 操作系統(tǒng);使用VMware Workstation 10版本虛擬機(jī),每個(gè)虛擬機(jī)配置了雙核和2G的內(nèi)存并安裝Windows7系統(tǒng).路由器安裝并運(yùn)行dummynet,用以調(diào)節(jié)延遲、丟包率和網(wǎng)絡(luò)帶寬模擬真實(shí)的網(wǎng)絡(luò)環(huán)境.客戶端都配置Intel Core i5-2.3GHz CPU,8GB內(nèi)存,120GB SSD.

圖5 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)Fig.5 Network topology

實(shí)驗(yàn)測(cè)試選取Dirt、Farcry和Starcraft這三個(gè)游戲,游戲SLA需求設(shè)定為30個(gè)FPS.讓每個(gè)游戲單獨(dú)運(yùn)行于虛擬機(jī)中,并且讓3個(gè)虛擬機(jī)同時(shí)運(yùn)行在服務(wù)器上.

5.1 幀率控制算法對(duì)游戲幀數(shù)的影響

通過(guò)與不運(yùn)行幀率控制算法時(shí)比較,分析各游戲的FPS值,如圖6所示,圖6(a)和圖6(b)是游戲運(yùn)行時(shí)對(duì)應(yīng)的幀數(shù),圖6(c)和圖6(d)是3秒內(nèi)游戲幀數(shù)的概率百分比;圖6(a)和圖6(c)是不運(yùn)行該算法時(shí),各游戲的FPS值.從圖6(a)可以看出,在一個(gè)GPU上同時(shí)運(yùn)行多個(gè)游戲存在資源分配不平衡的問(wèn)題.有些游戲的FPS值很高,有些游戲的FPS值很低,甚至低于30幀,從圖6(c)中可以看出Dirt的幀數(shù)在23到28之間,占據(jù)了73%,達(dá)不到流暢的要求,Farcry的幀數(shù)比較分散且不穩(wěn)定,這是因?yàn)橛捎诙鄠€(gè)游戲同時(shí)對(duì)GPU資源的爭(zhēng)奪,有的游戲的資源請(qǐng)求得不到及時(shí)的處理,從而導(dǎo)致其FPS波動(dòng)很大.從圖6(a)上我們還可以看出,由于游戲場(chǎng)景的變換,所以他們的FPS值也一直在變換;游戲幀數(shù)的突上突下還說(shuō)明運(yùn)行在云游戲服務(wù)器上的游戲極易受到整個(gè)系統(tǒng)環(huán)境的影響,比如被系統(tǒng)中比較耗CPU資源的不是游戲程序的程序搶占了CPU資源,從而導(dǎo)致FPS突然下降.

圖6 幀率控制算法分析Fig.6 Analysis of frame rate control algorithm

從圖6(b)和圖6(d)中可以看出,在運(yùn)行該算法后,測(cè)試剛開(kāi)始時(shí)Dirt的PFS低于30,此時(shí),幀率控制算法檢測(cè)到,就開(kāi)始調(diào)度工作,通過(guò)釋放其他兩個(gè)游戲的一部分GPU資源給Dirt,從而使Dirt滿足SLA需求,從圖6(d)可知Dirt只有6%的幀小于30,且在27到29之間,說(shuō)明該算法具有很好的及時(shí)性.經(jīng)過(guò)分析可知,幀率控制算法能夠有效調(diào)節(jié)各游戲幀數(shù),滿足最低服務(wù)等級(jí)協(xié)議,充分利用了GPU資源,為FEC編碼提供保證.

5.2 FEC補(bǔ)償算法對(duì)服務(wù)質(zhì)量的影響

本小節(jié)我們從畫(huà)面質(zhì)量分析FEC補(bǔ)償算法對(duì)云游戲用戶體驗(yàn)的影響.

實(shí)驗(yàn)分別獲取在運(yùn)行該算法前后的一段視頻,保存為YUV格式,從每一段視頻上截取相同的長(zhǎng)度為50s的視頻,計(jì)算出多組PSNR數(shù)據(jù),求取平均值,評(píng)估該算法對(duì)云游戲畫(huà)面質(zhì)量的影響.圖7反映了該算法對(duì)游戲畫(huà)面PSNR值的影響.觀察這些數(shù)據(jù)可知,運(yùn)行該算法時(shí)的畫(huà)面質(zhì)量比不運(yùn)行時(shí)更好,PSNR平均高了7.85dB,這是因?yàn)镕EC補(bǔ)償算法分析了傳輸丟包率和網(wǎng)絡(luò)狀況從而減少總的丟包率,并且提供了冗余數(shù)據(jù)包,可以恢復(fù)丟失的源數(shù)據(jù)幀;還可以發(fā)現(xiàn)有線網(wǎng)絡(luò)接受的平均視頻質(zhì)量是高于無(wú)線網(wǎng)絡(luò)的,并且比無(wú)線網(wǎng)絡(luò)更穩(wěn)定.在表1中,展示了視頻質(zhì)量結(jié)果PSNR與游戲幀率的關(guān)系,可以發(fā)現(xiàn)視頻質(zhì)量隨著幀率的增加而變好,并且?guī)试礁咴撍惴ㄐЧ胶?

圖7 FEC補(bǔ)償算法分析Fig.7 Analysis of FEC compensation algorithm

表1 PSNR數(shù)據(jù)表Table 1 Data table of PSNR

實(shí)驗(yàn)結(jié)果表明FEC補(bǔ)償算法能夠提高云游戲的畫(huà)面質(zhì)量,緩解丟幀所引起的花屏、卡頓現(xiàn)象,提高游戲服務(wù)質(zhì)量.

5.3 策略整體對(duì)云游戲響應(yīng)延遲的影響

實(shí)驗(yàn)分別在運(yùn)行策略前和運(yùn)行策略后進(jìn)行測(cè)試,在這兩個(gè)不同環(huán)境下觸發(fā)云游戲的按鍵事件,通過(guò)觀察游戲畫(huà)面的改變測(cè)算出從事件發(fā)生到出現(xiàn)結(jié)果的總延遲,評(píng)估該策略對(duì)總延遲的影響.

表2反映了運(yùn)行該策略前后云游戲的總延遲.觀察這些數(shù)據(jù)可知,該策略會(huì)影響云游戲的總延遲,平均延遲增加了24ms.這主要是因?yàn)楸仍瓉?lái)增加了冗余包,需要更多的傳輸時(shí)延和處理延遲.文獻(xiàn)[3]表明,不同類別的游戲可以容忍的延遲程度不同,例如,對(duì)延遲最敏感的第一人稱射擊游戲要求延遲不能超過(guò)100ms.在云游戲的應(yīng)用場(chǎng)景中,該策略能夠提高用戶的游戲體驗(yàn),所引起的延遲在可接受的范圍內(nèi),基本滿足云游戲嚴(yán)格的延遲要求.

表2 云游戲總延遲數(shù)據(jù)表Table 2 Total delay of cloud gaming

6 結(jié)束語(yǔ)

本文提出了云游戲中基于幀率控制的FEC彌補(bǔ)策略.其主要目的是通過(guò)FEC編碼來(lái)解決無(wú)線網(wǎng)絡(luò)中由于丟幀所引起的服務(wù)質(zhì)量差的問(wèn)題.該策略先通過(guò)幀率控制算法使運(yùn)行在同一個(gè)GPU上的游戲滿足SLA;然后通過(guò)FEC補(bǔ)償算法根據(jù)網(wǎng)絡(luò)狀況最小化估算冗余包的數(shù)量,使客戶端丟失的源數(shù)據(jù)可以恢復(fù).實(shí)驗(yàn)結(jié)果表明,該策略能夠優(yōu)化游戲畫(huà)面,提高云游戲的服務(wù)質(zhì)量.

：

[1] Cai W,Shea R,Huang C Y,et al.A survey on cloud gaming:future of computer games[J].IEEE Access,2016,4(99):7605-7620.

[2] Ogata K.Discrete-time control systems [M].Englewood Cliffs,NJ:Prentice Hall,1995.

[3] Huang C Y,Hsu C H,Chen K T.Gaming anywhere:an open-source cloud gaming platform[J].ACM SIG Multimedia Records,2015,7(1):3-5.

[4] Hong H J,Chen D Y,Huang C Y,et al.Placing virtual machines to optimize cloud gaming experience[J].IEEE Transactions on Cloud Computing,2015,3(1):42-53.

[5] Dowty M,Sugerman J.GPU virtualization on VMware′s hosted I/O architecture [J].ACM SIGOPS Operating Systems Review,2009,43(3):73-82.

[6] Zhang C,Yao J,Qi Z,et al.vGASA:Adaptive scheduling algorithm of virtualized GPU resource in cloud gaming [J].IEEE Transactions on Parallel and Distributed Systems,2014,25(11):3036-3045.

[7] Ugon B,Nandong J,Zang Z.Advanced PID controller synthesis using multiscale control scheme[C].Proceedings of Industrial Electronics and Applications,IEEE,2014:775-780.

[8] Gilbert E N.Capacity of a burst-noise channel [J].Bell Labs Technical Journal,1960,39(5):1253-1265.

[9] Freris N M,Hsu C H,Singh J P,et al.Distortion-aware scalable video streaming to multinetwork clients [J].IEEE/ACM Transactions on Networking,2013,21(2):469-481.

[10] Wu J,Yuen C,Wang M,et al.Content-aware concurrent multipath transfer for high-definition video streaming over heterogeneous wireless networks [J].IEEE Transactions on Parallel and Distributed Systems,2016,27(3):710-723.

[11] Sharma V,Kar K,Ramakrishnan K K,et al.A transport protocol to exploit multipath diversity in wireless networks [J].IEEE/ACM Transactions on Networking(TON),2012,20(4):1024-1039.

[12] Wu J,Yuen C,Cheung N M,et al.Streaming mobile cloud gaming video over TCP with adaptive Source-FEC coding[J].IEEE Transactions on Circuits & Systems for Video Technology,2017,27(1):32-48.

[13] Wu J,Cheng B,Wang M,et al.Delivering high-frame-rate video to mobile devices in heterogeneous wireless networks [J].IEEE Transactions on Communications,2016,64(11):4800-4816.