基于MirrorLink的VNC屏幕映射方法改進(jìn)與實(shí)現(xiàn)

蔣建春+鄧露+陳慧玲

【摘 要】MirrorLink是汽車行業(yè)里推出的唯一統(tǒng)一標(biāo)準(zhǔn)，旨在規(guī)范手機(jī)與車機(jī)互聯(lián)，給用戶帶來方便實(shí)用的體驗(yàn)效果，但是MirrorLink的VNC在傳輸多媒體數(shù)據(jù)的時候幀率低，卡頓現(xiàn)象嚴(yán)重，且不支持語音控制，這嚴(yán)重影響了用戶的體驗(yàn)效果。針對這個不足，課題組修改了VNC傳輸協(xié)議方法，設(shè)計(jì)出了一種新的多媒體傳輸方案。實(shí)驗(yàn)結(jié)果表明，VNC實(shí)時性有所增強(qiáng)，在多媒體傳輸中視頻能夠流暢播放，同時有效地降低了CPU利用率。

【關(guān)鍵詞】MirrorLink；VNC；屏幕映射；多媒體傳輸

【Abstract】MirrorLink is the automotive industrys only uniform standard， it is designed to regulate the mobile phone and the

vehicle connecting， and give users a convenient and practical experience. But the frame rate is low in the VNC of MirrorLink in the transmission of multimedia data， and it cannot supports voice control， which will seriously impact the users experience.To modify this

deficiency， our research group changed the VNC transport protocol method into a new multimedia transmission program， we also input a voice control system in the VNC transport protocol. The results show that the function of VNC has been strengthen. Videos can be

played smoothly in the multimedia transmission，in addition，the CPU utilization was reduced， and the voice control function was

implemented successfully.

【Key words】MirrorLink； Vnc； Voice control； Screen mapping； Multimedia transmission

0 引言

屏幕映射屬于一種新的顯示方法，也就是說它能將完整的窗口界面通過網(wǎng)絡(luò)，映射到另一臺計(jì)算機(jī)的屏幕上，主要解決不同設(shè)備之間的互操作與資源共享問題。蘋果公司最早提出的圖形用戶界面GUI （Graphic User Interface）為屏幕映射技術(shù)的產(chǎn)生和發(fā)展奠定了基礎(chǔ)[1]。伴隨著物聯(lián)網(wǎng)的快速發(fā)展，車聯(lián)網(wǎng)也呼之欲出，車機(jī)互聯(lián)也逐步成為車聯(lián)網(wǎng)研究的重要應(yīng)用之一。

在車聯(lián)網(wǎng)車載終端應(yīng)用過程中，由于車載終端硬件設(shè)備更新?lián)Q代較慢，部分功能不能滿足發(fā)展的需要，迫切需要一種替代的功能更新方案，屏幕映射技術(shù)的出現(xiàn)解決了車載終端硬件功能不足的問題。將移動終端屏幕內(nèi)容鏡像到車載大屏幕，讓我們可以利用移動終端的硬件與軟件的強(qiáng)大功能，解決車載終端的不足，同時，利用車載終端的大屏幕顯示移動終端的內(nèi)容，不用看著移動終端屏幕，只需要用車載上的物理按鍵或語音命令就能控制手機(jī)，給駕乘人員帶來更多的便利與舒適。目前屏幕映射主要有3種互聯(lián)方案：

（1）MirrorLink。MirrorLink最大的優(yōu)勢是平臺獨(dú)立獨(dú)立性和開放性，MirrorLink有更好的兼容性，除了iOS設(shè)備外，幾乎所有的主流智能手機(jī)系統(tǒng)都能支持[2]。MirrorLink支持無線和有線連接，能夠?qū)崿F(xiàn)屏幕雙向控制等。但是，MirrorLink也存在播放視頻延時，不支持語音控制等缺陷。

（2）AirPlay。AirPlay擁有流暢清晰的畫面，美中不足的是沒法實(shí)現(xiàn)雙向控制，支持的視頻格式有限，連接不方便等缺點(diǎn)。

（3）Miracast。Miracast[2]的技術(shù)優(yōu)勢是其視頻播放的流暢度，但是Miracast方案也有顯著的缺點(diǎn)：無法雙向控制、延遲明顯、車機(jī)需要自帶wifi、耗電現(xiàn)象嚴(yán)重等。

由于MirrorLink概念提出時間早且是唯一的行業(yè)內(nèi)推出的統(tǒng)一標(biāo)準(zhǔn)，平臺獨(dú)立性與開放性，兼容性好等優(yōu)點(diǎn)，目前大多數(shù)汽車廠商都采用此方案。課題組針對MirrorLink的不足，融合了Miracast在視頻傳輸?shù)膬?yōu)點(diǎn)，設(shè)計(jì)出了一套新的車機(jī)互聯(lián)方案。

1 MirrorLink工作原理

MirrorLink是智能手機(jī)和車載系統(tǒng)之間連接的開放式行業(yè)標(biāo)準(zhǔn)，由全球車聯(lián)盟（Car Connectivity Consortium，CCC）發(fā)起建立[3]。在MirrorLink的環(huán)境下，客服端與服務(wù)端的運(yùn)行環(huán)境將完全一樣，并通過車機(jī)屏幕播放移動終端界面，更主要的是車載終端可以通過觸摸屏、按鈕等去控制移動設(shè)備界面等。

1.1 MirrorLink協(xié)議架構(gòu)

MirrorLink協(xié)議的組成結(jié)構(gòu)如圖1所示，它們分別是：

（1）連接協(xié)議，以IP（Internet Protocol）為基礎(chǔ)的面向有線（USB）和無線 （WIFI）的連接，用于傳輸網(wǎng)絡(luò)數(shù)據(jù)。

（2）UPnP服務(wù)協(xié)議，提供廣播機(jī)制通知ML（MirrorLink）客服端服務(wù)端的狀態(tài)。

（3）VNC協(xié)議，將ML服務(wù)端界面復(fù)制到客戶端，客服端可以反饋控制信息到服務(wù)端。此協(xié)議是基于RFB（Remote Frame Buffer）協(xié)議，并提供了壓縮技術(shù)。

（4）用于傳輸音頻的協(xié)議，其中主要包括RTP（Real-time Transport Protocol），藍(lán)牙的HFP（Hands-free Profile）和A2DP（Advanced Audio Distribution Profile），用于音頻數(shù)據(jù)的傳輸。

（5）安全機(jī)制協(xié)議，用于MirrorLink的認(rèn)證與保密[4]。

2 MirrorLink的VNC協(xié)議

VNC（Virtual Network Computer）架構(gòu)實(shí)現(xiàn)了兩個功能，一是將移動終端屏幕上的內(nèi)容轉(zhuǎn)移到客戶端，屏幕上的拷貝操作可以通過RFB協(xié)議來復(fù)制移動端設(shè)備顯示卡（Framebuffer 副本）中的內(nèi)容，將其進(jìn)過一定的處理（旋轉(zhuǎn)，壓縮，色彩轉(zhuǎn)換等）， 再傳入到客戶端的Framebuffer，從而在客戶端的顯示設(shè)備上能出現(xiàn)移動設(shè)備上的界面[3]。二是服務(wù)端被動的允許客戶端控制它，客戶端傳送事件消息到服務(wù)端。

2.1 VNC的核心協(xié)議RFB協(xié)議

VNC協(xié)議是基于RFB協(xié)議的，RFB （遠(yuǎn)程幀緩沖）是一個用于遠(yuǎn)程訪問圖形用戶接口的簡單協(xié)議[5]。它是建立在TCP/IP傳輸協(xié)議基礎(chǔ)之上的一個簡單的圖形界面?zhèn)鬏攨f(xié)議。

2.1.1 顯示協(xié)議

RFB顯示協(xié)議原理可簡單的歸結(jié)為：把像素?cái)?shù)據(jù)放在一個由 x，y 定位的矩形內(nèi)，通過這些小矩形內(nèi)的像素更新來完成整個幀緩存的更新，服務(wù)器每次只發(fā)送變化的矩形塊。

2.1.2 輸入?yún)f(xié)議

RFB客戶端將用戶通過觸摸屏、按鍵、鼠標(biāo)等I＼O設(shè)備的輸入作為事件請求發(fā)送至服務(wù)端。服務(wù)端接收消息后根據(jù)不同的輸入事件執(zhí)行相對應(yīng)的邏輯操作，響應(yīng)RFB客戶端提出的事件請求。

2.1.3 像素與圖形編碼

RFB客戶端和RFB服務(wù)端首次會話的時候?qū)f(xié)商具體的像素?cái)?shù)據(jù)格式以及傳輸?shù)木幋a方式。

像素?cái)?shù)據(jù)格式指的是像素顏色值的表示方法，通常我們使用的是24位或者16位真彩色的像素格式。編碼指的是矩形區(qū)域的像素?cái)?shù)據(jù)通過什么形式在網(wǎng)絡(luò)中傳輸。目前 RFB 中定義的編碼類型有原始編碼、 復(fù)制矩形編碼、 二維行程（RRE）編碼和，Hextile 編碼，ZRLE編碼[4]?？梢孕略鼍幋a方式對協(xié)議進(jìn)行擴(kuò)展。比如JPEG、MPEG等等。

通過對RFB協(xié)議的分析，RFB顯示協(xié)議采用被動更新方式，將使畫面有一定的延遲效果；特別在視頻傳輸時，延遲效果極大。

3 VNC協(xié)議改進(jìn)

對于VNC顯示協(xié)議，服務(wù)端采用被動更新方式將會給畫面帶來延遲效果，本文將采用服務(wù)端主動更新方式；由于移動硬件設(shè)備的限制，壓縮算法的缺陷等原因，導(dǎo)致了VNC在視頻傳輸中，視頻播放延遲非常大，在客戶端看到的圖像就如同幻燈片一樣，無法給用戶提供流暢視頻圖像[6]。與此同時在VNC環(huán)境下，手機(jī)與車機(jī)的畫面是完全同步的，這樣就使得在車載終端觀看視頻的時候，手機(jī)無法單獨(dú)操控，因?yàn)椴僮魇謾C(jī)，導(dǎo)致手機(jī)畫面變化，車載終端也會同樣跟著手機(jī)畫面；這樣會導(dǎo)致手機(jī)只是一臺服務(wù)器，我們無法在視頻傳輸?shù)臅r候使用手機(jī)的功能，本文針對這種不足設(shè)計(jì)了一種新的多媒體傳輸方案。

3.1 新的多媒體傳輸方案

本文借鑒了Miracast在傳輸視頻方面的優(yōu)勢，設(shè)計(jì)了一種針對車載智能終端與手機(jī)新的多媒體傳輸方案，如圖2所示。VNC 采用服務(wù)器被動更新策略，客戶端判斷幀緩存有變化才向服務(wù)器申請幀緩存更新，這種模式下兩條顯示更新之間的間隔至少是客戶端與服務(wù)器間網(wǎng)絡(luò)的 RTT 時間，再加上計(jì)算幀緩存變化所需要的時間，顯示更新就更慢了[7]，為了不影響人機(jī)交互的實(shí)時性，本文采用服務(wù)器主動更新。即在正常模式下，VNC服務(wù)端采用主動更新策略，即服務(wù)端幀緩沖變化馬上發(fā)送更新請求，減少不必要的交互過程；如果服務(wù)端捕獲到屏幕快速變化或者是打開視頻文件，VNC將切換到流媒體模式，VNC服務(wù)端將快速變換的圖像通過H.264編碼（如果是傳輸視頻文件，此時將掛起屏幕映射功能，只壓縮傳輸視頻數(shù)據(jù)），然后通過RTP/RTCP協(xié)議傳輸?shù)絍NC客戶端，客戶端完成解碼，將圖像數(shù)據(jù)組裝成圖片顯示（如果是視頻文件將會直接調(diào)用視頻播放器進(jìn)行播放）。多媒體傳輸系統(tǒng)整體架構(gòu)如圖2所示。

4 功能對比與實(shí)驗(yàn)結(jié)果分析

為了驗(yàn)證方案的正確性，本文在一部GALAXY S3手機(jī)和一部NOTE 3手機(jī)上進(jìn)行了測試，為了保證網(wǎng)絡(luò)環(huán)境的一致性，本文在傳統(tǒng)的VNC上引進(jìn)了Wifi Direct技術(shù)，同時改進(jìn)的VNC也采用了Wifi Direct技術(shù)。在正常模式下采用被動更新策略，通過監(jiān)測客戶端發(fā)送RfbFramebufferUpdateReques-t消息到客戶端接收到RfbFramebuffer Update消息并繪出圖片所需要的時間；在正常模式下采用主動更新策略，通過測量Server發(fā)出RfbFramebufferUpdate消息到客戶端繪出圖片所需時間，對此2種情況的實(shí)時性進(jìn)行了統(tǒng)計(jì)，如圖3實(shí)時性對比圖所示。在流媒體模式下，由于VNC不支持視頻傳輸，與本文方法無法進(jìn)行對比，所以本文只對視頻播放的流暢性和VNC Sever端CPU利用率進(jìn)行了測試，如圖4所示。

從圖3中可以發(fā)現(xiàn)，VNC實(shí)時性不是很好，都在零點(diǎn)幾秒，這對于實(shí)時性要求高的場合是無法滿足要求的。本文設(shè)計(jì)的VNC普通模式就是針對這種實(shí)時性要求不高的場合，而且采用了主動更新策略使實(shí)時性平均大致提升了0.25秒，能夠滿足我們正常的需求。

VNC Server把圖像數(shù)據(jù)（或視頻文件）通過H.264壓縮由RTP協(xié)議把實(shí)時數(shù)據(jù)傳輸?shù)娇蛻舳?，客戶端在本地解碼播放。通過實(shí)驗(yàn)觀察，視頻流暢性相當(dāng)好，沒有一點(diǎn)的卡頓現(xiàn)象，由圖4可知CPU的負(fù)載也不高，大致在30%左右。

本文改進(jìn)的VNC方法，在正常模式下，實(shí)時性得以提升，滿足正常的需求；在流媒體模式下，視頻播放流暢，到達(dá)了完美的播放效果。

5 結(jié)語

本文介紹了MirrorLink協(xié)議，詳細(xì)介紹了VNC的RFB協(xié)議。針對車載智能終端與手機(jī)的多媒體傳輸方案，在分析了現(xiàn)有的方案基礎(chǔ)上結(jié)合了Miracast視頻傳輸?shù)膬?yōu)勢，本文設(shè)計(jì)了一種新的多媒體傳輸方案，然后在Android手機(jī)上實(shí)現(xiàn)了該方案。試驗(yàn)結(jié)果表明，在非視頻傳輸?shù)那闆r，采用VNC主動更新，可以提高一定的實(shí)時性；在視頻傳輸?shù)那闆r下，通過H.264編碼采用RTP協(xié)議直接傳輸視頻文件，有效地控制了CPU利用率，視頻能夠完美播放。

【參考文獻(xiàn)】

[1]郭代，宴堅(jiān)，王文江.新型屏幕共享系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用研究，2007， 24（6）：299-301.

[2]趙國輝.車聯(lián)方案哪家強(qiáng)？聊聊MirrorLink、CarPlay和Android Auto | oh！百科[EB/OL].http：//www.qu55.com/qiche/6522.html.

[3]邱程.手機(jī)、車機(jī)互聯(lián)_MirrorLink解析[EB/OL]. http：//shuoke.autohome.com.cn/article/24184.html.

[4]張?jiān)?，陳瑋.車載系統(tǒng)MirrorLink方案的研究[J].信息技術(shù)，2013（2）：55-58.

[5]吳筱桉.VNC系統(tǒng)中RFB協(xié)議分析及視頻播放性能改進(jìn)[D].南開大學(xué)，2008.

[6]Deboosere L， De Wachter J， Simoens P， et al. Thin Client Computing Solutions in Low-and High-Motion Scenarios[C]//Networking and Services， 2007， ICNS. Third International Conference onIEEE， 2007： 38-38.

[7]李超.基于流媒體的Android遠(yuǎn)程桌面的設(shè)計(jì)與實(shí)現(xiàn)[D].廣州：華南理工大學(xué)，2012.

[責(zé)任編輯：楊玉潔]