Bitmap Remoting (位圖遠程控制)

Citrix Bitmap remoting 是基于JPG 壓縮和RLE(Rung Length Encoding)技術(shù),該技術(shù)(這里指RLE)是Citrix特別發(fā)明的。你可以查詢這個網(wǎng)站(https://www.citrix.com/blogs/2016/09/28/lossless-compression-lowering-the-cost-of-pixel-perfection/)獲得更多的關(guān)于RLE的細節(jié)。位圖遠程(Bitmap Remoting),也叫做“Thinwire”是一種針對靜態(tài)內(nèi)容“Static Content”可以高效利用帶寬的遠程控制協(xié)議。另外,其視覺質(zhì)量“Visual Quality”非常接近原有圖像,我們甚至可以通過無損“l(fā)ossless”策略提升圖像質(zhì)量獲得更加完美的質(zhì)量“Pixel perfect”,用于某些必須的行業(yè),例如醫(yī)院影像處理。

所以,這對于Office相關(guān)的VDI或者XenApp使用場景是一個不錯的選擇。

[譯者]:Citrix最早發(fā)明了遠程桌面協(xié)議RDP并賣給了微軟,其廣泛用于Windows遠程桌面連接,類似于Bitmap Remoting,但由于主要是針對文本等靜態(tài)內(nèi)容的會話交付,其無法適用于當前視頻為王的新一代云桌面場景,包括3D CAD/CAE,云游戲。CStack xView產(chǎn)品也支持類似Bitmap的無損壓縮技術(shù),并可以進行智能動態(tài)切換。

為什么?

在大部分的時間里,用于Office或者ERP應(yīng)用的用戶并沒有看到太多的屏幕變化,因此位圖(bitmap)遠程協(xié)議非常高效。但是這里有更多的細節(jié)需要考慮:

圖像質(zhì)量(Image Quality)

我們不打算僅僅用肉眼來區(qū)分不同的圖片以便發(fā)現(xiàn)其圖像質(zhì)量與原有圖片有多接近。因此我們將使用更加客觀的方法用來進行測量:
結(jié)構(gòu)化相近指數(shù)(Structural Similarity Index: SSIM)是一個用于量化由于數(shù)據(jù)壓縮或者傳輸丟失所造成的的圖像質(zhì)量退化的指標。它是一個由兩張相同圖片不同來源:一個是參考圖像,一個是處理過的圖像所構(gòu)成的全參考指標。

Reference Image (參考圖像)

捕獲的圖片(VDI Session)

終端(Endpoint)

大部分的客戶會為他們的用戶采用瘦終端(ThinClient)而不是胖終端(FatClient)。這些瘦終端很多都已經(jīng)很舊了,甚至一些還不支持硬件解碼(hardware decoding)(我們后面會討論這些)。位圖遠程控制(Bitmap Remoting)不需要特別的終端硬件配置,同時對資源消耗非常低,所以基本上可以用于全部的瘦終端上。

[譯者]:CStack xView CSDP(CStack Desktop Protocol)中的無損壓縮技術(shù)同樣支持廣泛的CStack已有或者在研終端類型,包括軟終端,ARM A2000,A3000,X86 X1000等,最大限度的保護了用戶現(xiàn)有投資。

使用CPU資源編碼(Encoding CPU Load)

如前面所描述的終端情況,只需要適當?shù)腃PU資源就可以進行位圖(Bitmap)壓縮。但是它不能實現(xiàn)將編碼(encoding)工作卸載到GPU上(NVENC:這里指的是NVIDIA Encoding)

Citrix 策略設(shè)置

我建議下列策略設(shè)置從而強行啟用Bitmap Remoting:

Optimize for 3D graphics workload ->Disabled

這個策略在這里其實是不相關(guān)的,所以可以被禁用

Use video codec for compression ->Do not use video codec

為了強制使用位圖(Bitmap Remoting),所以我們需要禁用視頻編解碼(Video Codec)

Visual Quality ->High

這個策略的配置需要根據(jù)你對圖像質(zhì)量的要求來定。高“High”是個好的選擇,并且你可以選擇“嘗試無損”或者“總是無損” 用于我們前面提到過的需要完美圖像質(zhì)量的使用場景。

[譯者]:CStack xView從兩個維度提供了有關(guān)協(xié)議方面的控制:管理平臺可以集中配置協(xié)議參數(shù),并下發(fā)到各個終端上;終端側(cè)可以獨立配置協(xié)議控制,如果和管理平臺配置參數(shù)沖突,那么優(yōu)先選擇本地,同時我們可以做到更為細顆粒的協(xié)議參數(shù)控制(請參考下圖)。目前計劃引入網(wǎng)絡(luò)質(zhì)量實時監(jiān)測功能實現(xiàn)智能化、動態(tài)化的協(xié)議適配,簡化用戶配置。

管理平臺中的協(xié)議配置

Android A2000 協(xié)議配置

視頻編解碼(Video Codecs)

Citrix目前支持H.264和H.265編解碼。另外,這里有不同的H.264類型:YUV420和YUV444. 目前我們(Citrix)僅支持H.265 YUV420類型。這兩之間更多的對比和差異會在后續(xù)的博客文章中進行講解。這里我先聚焦在什么時候需要選擇視頻編解碼(Video Codec)和…

[譯者]:CStack xView是國內(nèi)第一家也是目前唯一一家支持云桌面H.265編碼傳輸?shù)脑谱烂娈a(chǎn)品。

…為什么?

如我們前面所看到的,位圖(Bitmap Remoting)對于靜態(tài)圖像支持的非常好,但是當涉及到移動圖像和視頻播放時,情況則有所不同了。當幀率越高(30fps,60fps),就有越多的圖像需要被位圖遠程控制(Bitmap Remoting)所傳輸,這將嚴重影響帶寬需求和總體的使用體驗。所以,這種情況下視頻編解碼正好有所作用。

[譯者]:所以微軟后期對于RDP的發(fā)展也停滯不前了,推出了RemoteFX以便適應(yīng)高幀率的視頻等場景。國內(nèi)一些低端廠商通過包裝RDP實現(xiàn)所謂自研的云桌面產(chǎn)品,其技術(shù)能力和產(chǎn)品支持可想而知。

帶寬

視頻編解碼(H.264,H.265)進行圖像編碼時,對于色彩信息(相對于亮度信息)會采用相對更低的分辨率,這是因為人類視覺系統(tǒng)對于色彩的敏銳度相對于亮度較低。這種技術(shù)使得可以在低帶寬需求下進行視頻播放或者3D建模,甚至是高幀率的使用場景。也使得用戶可以在家或者遠程帶寬較低的WAN情況下進行辦公和使用。

[譯者]:根據(jù)CStack和某省電信公司天翼云合作開展的云桌面帶寬對比測試結(jié)果可以看出,廣域網(wǎng)環(huán)境下采用H.265在不降低甚至提升用戶使用體驗的同時,可以有效地降低帶寬使用量,大約節(jié)省40%的帶寬。請詳見CStack文章。。。。。《鏈接》

圖像質(zhì)量(Image Quality)

視頻編解碼中YUV420(Citrix 缺省)由于采用了色彩二次采用效應(yīng)“chroma subsampling effect”導(dǎo)致了圖像模糊,尤其是在一些特殊布局的文本顯示下。這種情況對于對象移動的視頻播放來說不是問題,但是會對于Office應(yīng)用的使用帶來不便。我們會利用之前位圖遠程協(xié)議中所采用的相同參考圖像和SSIM測量方法向你展示這種行為:

參考圖片(Reference Image)

捕獲的圖片 H.264 YUV420

SSIM heatmap result H.264 YUV420

通過對比參考圖片和捕獲的圖片,你應(yīng)該通過肉眼已經(jīng)看出了巨大的區(qū)別了。另外,在SSIM熱圖中先了83%的準確率。你現(xiàn)在應(yīng)該能夠更好地理解了,為什么用戶會在YUV420的情況抱怨了。

[譯者]:對于顏色非常敏感的設(shè)計師來說,剛開始使用云桌面時候一定會有所抱怨的,包括Citrix一流云桌面廠家同樣會遇到此類問題,通過選擇靜態(tài)無損壓縮或者YUV444可以解決此問題,但是同樣會帶來一定的負面影響,包括帶寬消耗,延時增加,瘦終端適配等。所以,我們在實施此類項目時,一定需要先清楚地了解客戶真實需求和原有環(huán)境配置,然后適當?shù)倪M行調(diào)整。坦白地講,并不是所有的設(shè)計場景都適合云桌面。CStack能夠從創(chuàng)立之初就挑戰(zhàn)設(shè)計類場景,也是基于多年來的技術(shù)積累和前瞻性投入。

延時(Latency)

一旦我們利用了諸如H.264編解碼技術(shù)我們就需要在服務(wù)器端對捕獲的圖像進行編碼,然后在終端上進行解碼。這是一個非常耗時耗力的任務(wù),如果不能使用硬件編碼方式,那么H.264需要1個vCPU。好的情況是,Citrix利用Tesla GPU支持硬件編碼方式,這樣就可以將這些任務(wù)卸載到專用的GPU上的ASIC芯片上去完成。相對于基于CPU的編碼方式,硬件編碼總是要快的,并且可以很好的降低編碼延時。舉例來說,你可以認為GPU編碼只需要4ms,而CPU編碼則需要約30ms。

[譯者]:國內(nèi)大部分通過在Guest OS(虛擬機)里面安裝agent進行云桌面交付的產(chǎn)品,由于能力有限無法利用硬件加速技術(shù),使得其無法高效地支持高端云桌面場景,包括多路2K/4K超高清視頻播放,云游戲,3D渲染等,某些廠家通過視頻重定向技術(shù)將視頻重定向到瘦終端上進行解碼和playback,這樣將帶來視頻文件格式兼容性,播放器兼容性,播放路數(shù)受限,終端要求等多種問題。CStack xView產(chǎn)品通過硬件加速技術(shù),無需消耗云桌面vCPU資源,極大的提升了單機并發(fā)量和用戶使用體驗。

終端(Endpoint)

我們的終端需要具備解碼的能力。所以,它需要是一個硬件的解碼器或者裝備有性能足夠的CPU用于對視頻流進行解碼。同樣延時也需要同樣的硬件特性。硬件解碼是優(yōu)先選擇的,因為它能夠降低總體的延時。所以,如果我們用一個過時的瘦終端,它很可能會無法進行解碼,最終導(dǎo)致用戶使用體驗的降級。

[譯者]:CStack提供多種類型的終端,包括軟終端,ARM終端和X86終端,可以最大限度地利用終端的有限資源進行視頻解碼

使用CPU資源編碼(Encoding CPU Load)

Citrix 支持在硬件上使用NVENC(NVIDIA Encoding)進行編碼。通過將任務(wù)卸載到GPU上,從而能夠獲得更多的好處,例如更低的CPU資源消耗,甚至為位圖協(xié)議還要低

Citrix 策略設(shè)置

你應(yīng)該按照以下內(nèi)容進行策略設(shè)置

Optimize for 3D graphics workload ->Enabled

啟用這個策略以便使用NVFBC(NVIDIA Direct FB Access)和NVENC(NVDIA Encoding)

Use video codec for compression ->For the entire screen

對于較老的XenDesktop版本(7.12 ～ 7.16),需要啟用“全屏幕策略”以便使用NVENC功能

Visual Quality ->High

雖然這個選項無法避免色彩二次采用效應(yīng),但是設(shè)置為“高”依舊可以在很多場景下帶來較高的圖像質(zhì)量。另外,因為“中等”和“高”對于帶寬的消耗并沒有太多差異,所以我建議設(shè)置為“高”作為一個好的開始

Use hardware encoding ? Enabled (這是Citrix默認的配置,所以我沒有為它單獨創(chuàng)建一個截圖)

[譯者]:只要購買我們的一體機,或者軟件+CSDP硬件加速套裝,那么CStack xView對于硬件加速技術(shù)缺省就是啟用的,無需用戶進行配置和調(diào)整,也不存在版本兼容性問題。目前我們在增加更加完善的智能動態(tài)檢測技術(shù),針對屏幕熱點圖像的特性進行智能化地動態(tài)協(xié)議調(diào)整,以便應(yīng)對不同的應(yīng)用軟件,諸如Office,視頻播放,云游戲和3D設(shè)計等。

使用場景(Use Case)

同時,僅僅使用“H.264 YUV420 only”的場景在減少,這里有幾個原因,最主要的是由于“色彩二次采用效應(yīng)”以及有其他替代方案。從Citrix 7.17及以后版本,我們支持混合編碼 “mixed codecs” (Bitmap和Video),這種技術(shù)可以將H.264全屏幕方式編碼縮小到“3D VDI使用模式”,后者對于色彩的高準確度并不是必須的。我會在另外一篇博客文章中詳細講解混合編碼模式“mixed codecs”

如果你想了解如何選擇正確的VDI協(xié)議,可以觀看我們在GTC大會上的視頻錄像。

關(guān)于作者

Simon Schaber: NVIDIA GRID 解決方案架構(gòu)師

譯文出處

上?？釛？萍加邢薰?簡稱:“CStack”)是一家提供行業(yè)領(lǐng)先的云桌面產(chǎn)品及解決方案的高科技公司,其前身是上海思華科技股份有限公司云計算事業(yè)部,自2012年從事云計算及云桌面技術(shù)研究和標準化產(chǎn)品交付以來,已完成眾多云桌面項目集成與實施。其產(chǎn)品和解決方案已廣泛應(yīng)用于運營商、公安、制造、教育、金融、醫(yī)療、保險等多個行業(yè)及領(lǐng)域。

公司愿景:成為全球領(lǐng)先的云桌面提供商

公司使命:以安全、極簡的云桌面,實現(xiàn)人、設(shè)備和數(shù)據(jù)的智慧互聯(lián)

songjy