RTC 場景下的屏幕共享優(yōu)化實踐2

算法參數(shù)優(yōu)化與評價

數(shù)據(jù)采集和標注

由于數(shù)據(jù)集非常匱乏，需要我們自己高效地獲取一批人工標注數(shù)據(jù)，進行參數(shù)的優(yōu)化和算法的測試。我們自己錄了一些數(shù)據(jù)，并開發(fā)了一個小型的標注軟件，進行了數(shù)據(jù)標注工作。

算法評價指標

（圖片來源：https://en.wikipedia.org/wiki/Sensitivity_and_specificity）

1. 準確率 （precision）

精確率是針對預(yù)測結(jié)果而言的，它表示的是預(yù)測為正的樣本中有多少是真正的正樣本。那么預(yù)測為正就有兩種可能，一種就是把正類預(yù)測為正類(TP)，另一種就是把負類預(yù)測為正類(FP)

2. 召回率（recall）

召回率是針對原來的樣本而言的，它表示的是樣本中的正例有多少被預(yù)測正確了。那也有兩種可能，一種是把原來的正類預(yù)測成正類(TP)，另一種就是把原來的正類預(yù)測為負類(FN)。

內(nèi)容識別算法需要在準確率和召回率之間進行權(quán)衡，根據(jù)業(yè)務(wù)場景調(diào)整檢測結(jié)果偏好。

算法實現(xiàn)與優(yōu)化

算法實現(xiàn)

光流計算

稠密光流的計算目前有兩種常見算法，HS 光流，DIS 光流 在實現(xiàn)上，選用了 DIS 光流估計的方法，兩種方法在相同機器上運行時間如下表所示。

更為具體的計算開銷和算法準確程度的數(shù)據(jù)可以參考下圖

（DIS 光流法計算準確度與運算時長相較其他算法比較，引用自 Kroeger, Till & Timofte, Radu & Dai, Dengxin & Van Gool, Luc. (2016). Fast Optical Flow Using Dense Inverse Search. LNCS. 9908. 471-488. 10.1007/978-3-319-46493-0_29. ）

特征提取

在計算光流之后，我們需要提取運動幅度，運動角度以及紋理相關(guān)的特征。

在計算光流之后，提取運動幅度、運動角度以及紋理相關(guān)的特征。

1. 坐標系轉(zhuǎn)化：笛卡爾系->極坐標系

光流估計得到的結(jié)果是每一個像素的（x,y）偏移，所以需要將這個笛卡爾坐標系的值轉(zhuǎn)化為極坐標系，從而得到光流的運動幅度和方向信息，即(x,y) ->(ρ,θ)

2. 紋理計算

參考了前文提到的兩篇文獻的相關(guān)工作，在 4x4 的 patch 內(nèi)統(tǒng)計 Y 通道上的直方圖特征，將 bin 的大小設(shè)為 1，統(tǒng)計 bin 的數(shù)量作為一個強特征。（這樣實質(zhì)就變成了統(tǒng)計有多少個 unique 值的問題），然后利用一個 hash 表進行映射與統(tǒng)計。隨后與運動信息進行加權(quán)求和，可以獲得一個全局的與運動相關(guān)的紋理特征值。

3. 角度特征的提取

角度特征的提取使用了方向統(tǒng)計的方法，計算得到當前內(nèi)容運動角度的均值、加權(quán)均值、離散程度、加權(quán)離散程度等特征，這些特征可以描述當前畫面內(nèi)容的運動信息。

狀態(tài)轉(zhuǎn)移

利用決策樹，經(jīng)過一些剪枝處理后，獲得了一些強特征的閾值，比如運動的角度均值，運動的角度離散度等，這些閾值都具有非常顯著的可解釋性。在狀態(tài)轉(zhuǎn)移模塊中，使用內(nèi)置的一個概率值記錄狀態(tài)，然后根據(jù)上述基于機器學(xué)習(xí)的規(guī)則對概率值進行調(diào)整，再結(jié)合業(yè)務(wù)融合一些人工特征，最終根據(jù)概率值的變化轉(zhuǎn)移模塊的狀態(tài)。

計算開銷優(yōu)化

雖然該算法能夠以較快的速度對視頻幀進行處理，但實際的屏幕共享中，對計算機資源的消耗也有更加嚴格的要求。那么就需要對檢測的的策略進行細致的優(yōu)化，夠進一步降低 CPU 占用和耗電量。

1. 計算量與運算速度

算法的運算量熱點都在光流計算上，而光流的計算開銷與選用的算法、圖像大小以及算法具體參數(shù)有關(guān)。

在算法應(yīng)用了 Ultra fast 模式后，檢測的 precision 和 recall 均出現(xiàn)了比較顯著的下滑，而 Fast 和 Medium 差別不大。所以最終選擇了 Fast 模式，在測試數(shù)據(jù)集上得到的結(jié)果也令人滿意。

2. 計算頻率優(yōu)化與靜默模式

在計算量優(yōu)化之后，算法能夠以 150fps-200fps 的速度進行檢測。在實際的屏幕共享場景，輸入的幀率可以達到 30fps，如果檢測頻率為 30fps 仍然會帶來顯著的 CPU 占用，還需要進一步降低檢測頻率。

在權(quán)衡響應(yīng)時間和 CPU 占用后，直接大幅度降低檢測頻率，比如每隔 5 幀檢測一次，在這種策略下，響應(yīng)時間和 CPU 占用都處于一種比較好的狀態(tài)。

但是，這種較低的檢測速度依舊會帶來可察覺的 CPU 增量，能不能再極致一點呢？

考慮到常見的辦公場景，用戶在屏幕共享時，其內(nèi)容類型在較長的時間內(nèi)是保持不變的，所以檢測的結(jié)果也應(yīng)該是長時間保持不變。假如是我們?nèi)祟愒谶@種情況下，在做這樣的分類結(jié)果一直不變的任務(wù)時，可不可以稍稍偷偷懶呢？答案是肯定的，那么計算機應(yīng)該也可以在這種情況下“偷一下懶”。這樣就可以在算法中引入了靜默的概念，當檢測的結(jié)果基本不變時，檢測算法模塊開始進入靜默狀態(tài)，此時檢測降低到更低的頻率，這樣 CPU 占用增長基本就察覺不到了。

如何確定何時需要進入靜默呢？算法利用時域上的積分求得一個分數(shù)，當該分數(shù)達到一定閾值的時候，并且滿足一些其它的限制條件的時候，就可以認為檢測到的為同一種類型了，就可以開始降低檢測頻率。這樣就保證了大多數(shù)情況下 CPU 的極低開銷，并且也盡可能保留了算法快速響應(yīng)的特性。

功能實現(xiàn)

決策邏輯

在共享模式的決策邏輯的設(shè)計上，需要明確兩點：

• 盡可能保持穩(wěn)定的分辨率與編碼策略，減少編解碼器重啟帶來的開銷
• 適當?shù)那袚Q速度

1. 幀率決策與分辨率決策

由于視頻流傳輸?shù)倪^程中，在有限的帶寬下，往往需要將幀率和分辨率相匹配以獲得合適的帶寬消耗。

所以自動模式預(yù)設(shè)了若干個幀率和分辨率相匹配的檔位，在每次獲得檢測算法的檢測結(jié)果后對幀率進行增減，再根據(jù)幀率的大小匹配相應(yīng)的分辨率。在幀率下降的時候，就可以根據(jù)內(nèi)外部條件的限制升高傳輸分辨率；相反，在幀率上升的時候，就可以用適當?shù)倪壿媽Ψ直媛蔬M行降級操作。

**2. 編碼方式?jīng)Q策 **

在共享文字場景為主的屏幕內(nèi)容時，編碼策略也會與流暢度優(yōu)先的視頻編碼方式不同，這時會使用專門的針對屏幕內(nèi)容的編碼器，并開啟重復(fù)幀檢測等策略，同時也會對碼控策略進行場景化的調(diào)整，從而使畫面更符合用戶需求。

**3. 抗抖動 **

策略的切換一般是需要需要響應(yīng)時間的，比如分辨率的切換和編碼策略的切換都會有一定的響應(yīng)時間，如果頻繁的切換就會造成卡頓。

為了在發(fā)生抖動的情況下，依舊能夠保證良好的共享體驗，需要引入一些抗抖動的機制。

• 抖動主要來自于兩個方面
  • 誤檢測造成抖動
  • 真實的共享內(nèi)容頻繁切換導(dǎo)致抖動

對于第一點，通過兩種機制來減少抖動影響。

• 在整個 pipeline 的設(shè)計上，設(shè)計一種負反饋的調(diào)節(jié)機制。如前文所述，在幀率越高時，光流估計越準確，而幀率低時，不準確的光流估計容易將一般的文檔場景誤檢測成視頻播放的場景。當檢測出一次內(nèi)容變化時，如果是因為輸入幀率低導(dǎo)致誤檢，這個時候及時提高幀率又能夠降低誤檢概率，這樣就可以避免由于誤檢導(dǎo)致的共享模式的切換，促成檢測速度和準確度的穩(wěn)態(tài)。
• 通過控制決策頻率來抑制抖動的現(xiàn)象。

對于第二點所提到的抖動，最影響體驗的場景是在內(nèi)容變化或者其他原因，幀率反復(fù)在決策點附近上下波動，導(dǎo)致分辨率反復(fù)切換。因此，在控制決策頻率的基礎(chǔ)上增加了 dead zone 機制，在該機制下，分辨率切換在提升和下降兩個變化方向的決策點并不一樣，留有一定的間隔，避免了內(nèi)容頻繁切換或者其他原因造成的分辨率的抖動現(xiàn)象。

在這種機制下，分辨率就不會隨著幀率進行頻繁地切換，能夠更好地保證用戶體驗。

功能特色

業(yè)務(wù)實踐

在飛書屏幕共享的流暢度優(yōu)先模式中率先啟用了該功能，在業(yè)務(wù)上稱為智能流暢模式，這樣在用戶就能夠在播放視頻時達到 30fps 的流暢度，在共享文檔/ppt 內(nèi)容時，又能保持較高的清晰度。這個功能基本解決了用戶錯選流暢度優(yōu)先造成的清晰度不符合需求的問題，同時又保證了在用戶在真正需要流暢度體驗的時候，得到高幀率的體驗。

落地效果

經(jīng)過大范圍的線上測試之后，通過統(tǒng)計數(shù)據(jù)可以發(fā)現(xiàn)，采用“屏幕共享自動模式”后，一些原本采用“流暢模式”的共享場景被算法模塊糾正為了“清晰模式”，同時通過下圖可以發(fā)現(xiàn)，用戶的屏幕分享分辨率有了極大地提升，得到了顯著的清晰度提升。在線上算法的判定的準確程度上，通過對用戶反饋的統(tǒng)計，該功能也有著比較好的評價。

同時通過統(tǒng)計數(shù)據(jù)可以發(fā)現(xiàn)，得益于采集和編碼幀率的下降，CPU 占用不僅沒有上升反而得到了一定的優(yōu)化，如下圖所示，開啟自動模式的功能之后，最高可以得到 CPU 占用降低 20%的收益。

與其他候選方案的比較

在研發(fā)之初，我們也調(diào)研了一些候選方案，一種技術(shù)方案是使用像素差異與變化的占比作為切換依據(jù)，這樣最大的問題是，在部分教學(xué)視頻或說明類內(nèi)容中，在視頻內(nèi)容中展示 ppt 場景時，算法會出現(xiàn)誤判，將肉眼感知到的靜態(tài)場景檢測為視頻場景，畫面清晰度下降，不符合用戶使用的直覺；此外還有一種方案是針對應(yīng)用類型進行適配，比如根據(jù)進程名稱和窗口大小進行策略調(diào)整，這樣雖然能夠解決用戶場景化的需求差異，但是對于算法與策略的通用性會有較大的挑戰(zhàn)。本文使用的這套算法就能夠避開了上述的問題，體驗更加友好。

未來的演進與規(guī)劃

算法演進

雖然由于數(shù)據(jù)集的相對缺乏，在設(shè)計之初排除了深度學(xué)習(xí)模型的應(yīng)用。在研發(fā)過程中，對算法流程與模塊進行拆分，其中獨立出的紋理分析等模塊，這樣就可以通過人工數(shù)據(jù)集的方式，在部分算法模塊嘗試應(yīng)用深度學(xué)習(xí)模型，以期能夠獲得更好的算法表現(xiàn)。同時，考慮到當前的算法還是針對全局畫面的分類，未來會推出視頻區(qū)域的 ROI 檢測，這樣能夠讓下游應(yīng)用具有更強的靈活性和對業(yè)務(wù)的適應(yīng)能力。

業(yè)務(wù)演進

當前屏幕內(nèi)容檢測算法支持了共享模式的切換，此外，利用屏幕內(nèi)容檢測算法，還可以對發(fā)送端和接收端的網(wǎng)絡(luò)策略進行更智能的調(diào)優(yōu)，以期在文檔、ppt 場景下，進一步減少屏幕共享的延時與卡頓，讓投屏與屏幕共享響應(yīng)更高清、更流暢、延時更低，給用戶提供更好的沉浸式體驗，帶來更顯著的生產(chǎn)力的飛躍。