算法參數優化與評價
數據采集和標注
由于數據集非常匱乏,需要我們自己高效地獲取一批人工標注數據,進行參數的優化和算法的測試。我們自己錄了一些數據,并開發了一個小型的標注軟件,進行了數據標注工作。
算法評價指標
(圖片來源:https://en.wikipedia.org/wiki/Sensitivity_and_specificity)
- 準確率 (precision)
精確率是針對預測結果而言的,它表示的是預測為正的樣本中有多少是真正的正樣本。那么預測為正就有兩種可能,一種就是把正類預測為正類(TP),另一種就是把負類預測為正類(FP)
- 召回率(recall)
召回率是針對原來的樣本而言的,它表示的是樣本中的正例有多少被預測正確了。那也有兩種可能,一種是把原來的正類預測成正類(TP),另一種就是把原來的正類預測為負類(FN)。
內容識別算法需要在準確率和召回率之間進行權衡,根據業務場景調整檢測結果偏好。
算法實現與優化
算法實現
光流計算
稠密光流的計算目前有兩種常見算法,HS 光流,DIS 光流 在實現上,選用了 DIS 光流估計的方法,兩種方法在相同機器上運行時間如下表所示。
算法 | 分辨率 | 計算時間 |
---|---|---|
DIS 光流 | 320x180 | 7ms |
HS 光流 | 320x180 | 13ms |
更為具體的計算開銷和算法準確程度的數據可以參考下圖
(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. )
特征提取
在計算光流之后,我們需要提取運動幅度,運動角度以及紋理相關的特征。
在計算光流之后,提取運動幅度、運動角度以及紋理相關的特征。
- 坐標系轉化:笛卡爾系->極坐標系
光流估計得到的結果是每一個像素的(x,y)偏移,所以需要將這個笛卡爾坐標系的值轉化為極坐標系,從而得到光流的運動幅度和方向信息,即(x,y) ->(ρ,θ)
- 紋理計算
參考了前文提到的兩篇文獻的相關工作,在 4x4 的 patch 內統計 Y 通道上的直方圖特征,將 bin 的大小設為 1,統計 bin 的數量作為一個強特征。(這樣實質就變成了統計有多少個 unique 值的問題),然后利用一個 hash 表進行映射與統計。隨后與運動信息進行加權求和,可以獲得一個全局的與運動相關的紋理特征值。
- 角度特征的提取
角度特征的提取使用了方向統計的方法,計算得到當前內容運動角度的均值、加權均值、離散程度、加權離散程度等特征,這些特征可以描述當前畫面內容的運動信息。
狀態轉移
利用決策樹,經過一些剪枝處理后,獲得了一些強特征的閾值,比如運動的角度均值,運動的角度離散度等,這些閾值都具有非常顯著的可解釋性。在狀態轉移模塊中,使用內置的一個概率值記錄狀態,然后根據上述基于機器學習的規則對概率值進行調整,再結合業務融合一些人工特征,最終根據概率值的變化轉移模塊的狀態。
計算開銷優化
雖然該算法能夠以較快的速度對視頻幀進行處理,但實際的屏幕共享中,對計算機資源的消耗也有更加嚴格的要求。那么就需要對檢測的的策略進行細致的優化,夠進一步降低 CPU 占用和耗電量。
- 計算量與運算速度
算法的運算量熱點都在光流計算上,而光流的計算開銷與選用的算法、圖像大小以及算法具體參數有關。
算法 | 分辨率 | 運行時間 |
---|---|---|
DIS(MEDIUM) | 320x180 | 7ms |
DIS(FAST) | 320x180 | 4ms |
DIS(ULTRA FAST) | 320x180 | 1 ms |
在算法應用了 Ultra fast 模式后,檢測的 precision 和 recall 均出現了比較顯著的下滑,而 Fast 和 Medium 差別不大。所以最終選擇了 Fast 模式,在測試數據集上得到的結果也令人滿意。
Accuracy | Recall | Precision |
---|---|---|
0.9524 | 0.9608 | 0.9756 |
- 計算頻率優化與靜默模式
在計算量優化之后,算法能夠以 150fps-200fps 的速度進行檢測。在實際的屏幕共享場景,輸入的幀率可以達到 30fps,如果檢測頻率為 30fps 仍然會帶來顯著的 CPU 占用,還需要進一步降低檢測頻率。
在權衡響應時間和 CPU 占用后,直接大幅度降低檢測頻率,比如每隔 5 幀檢測一次,在這種策略下,響應時間和 CPU 占用都處于一種比較好的狀態。
但是,這種較低的檢測速度依舊會帶來可察覺的 CPU 增量,能不能再極致一點呢?
考慮到常見的辦公場景,用戶在屏幕共享時,其內容類型在較長的時間內是保持不變的,所以檢測的結果也應該是長時間保持不變。假如是我們人類在這種情況下,在做這樣的分類結果一直不變的任務時,可不可以稍稍偷偷懶呢?答案是肯定的,那么計算機應該也可以在這種情況下“偷一下懶”。這樣就可以在算法中引入了靜默的概念,當檢測的結果基本不變時,檢測算法模塊開始進入靜默狀態,此時檢測降低到更低的頻率,這樣 CPU 占用增長基本就察覺不到了。
如何確定何時需要進入靜默呢?算法利用時域上的積分求得一個分數,當該分數達到一定閾值的時候,并且滿足一些其它的限制條件的時候,就可以認為檢測到的為同一種類型了,就可以開始降低檢測頻率。這樣就保證了大多數情況下 CPU 的極低開銷,并且也盡可能保留了算法快速響應的特性。
功能實現
決策邏輯
在共享模式的決策邏輯的設計上,需要明確兩點:
- 盡可能保持穩定的分辨率與編碼策略,減少編解碼器重啟帶來的開銷
- 適當的切換速度
1. 幀率決策與分辨率決策
由于視頻流傳輸的過程中,在有限的帶寬下,往往需要將幀率和分辨率相匹配以獲得合適的帶寬消耗。
所以自動模式預設了若干個幀率和分辨率相匹配的檔位,在每次獲得檢測算法的檢測結果后對幀率進行增減,再根據幀率的大小匹配相應的分辨率。在幀率下降的時候,就可以根據內外部條件的限制升高傳輸分辨率;相反,在幀率上升的時候,就可以用適當的邏輯對分辨率進行降級操作。
**2. 編碼方式決策 **
在共享文字場景為主的屏幕內容時,編碼策略也會與流暢度優先的視頻編碼方式不同,這時會使用專門的針對屏幕內容的編碼器,并開啟重復幀檢測等策略,同時也會對碼控策略進行場景化的調整,從而使畫面更符合用戶需求。
**3. 抗抖動 **
策略的切換一般是需要需要響應時間的,比如分辨率的切換和編碼策略的切換都會有一定的響應時間,如果頻繁的切換就會造成卡頓。
為了在發生抖動的情況下,依舊能夠保證良好的共享體驗,需要引入一些抗抖動的機制。
- 抖動主要來自于兩個方面
- 誤檢測造成抖動
- 真實的共享內容頻繁切換導致抖動
對于第一點,通過兩種機制來減少抖動影響。
- 在整個 pipeline 的設計上,設計一種負反饋的調節機制。如前文所述,在幀率越高時,光流估計越準確,而幀率低時,不準確的光流估計容易將一般的文檔場景誤檢測成視頻播放的場景。當檢測出一次內容變化時,如果是因為輸入幀率低導致誤檢,這個時候及時提高幀率又能夠降低誤檢概率,這樣就可以避免由于誤檢導致的共享模式的切換,促成檢測速度和準確度的穩態。
- 通過控制決策頻率來抑制抖動的現象。
對于第二點所提到的抖動,最影響體驗的場景是在內容變化或者其他原因,幀率反復在決策點附近上下波動,導致分辨率反復切換。因此,在控制決策頻率的基礎上增加了 dead zone 機制,在該機制下,分辨率切換在提升和下降兩個變化方向的決策點并不一樣,留有一定的間隔,避免了內容頻繁切換或者其他原因造成的分辨率的抖動現象。
在這種機制下,分辨率就不會隨著幀率進行頻繁地切換,能夠更好地保證用戶體驗。
功能特色
業務實踐
在飛書屏幕共享的流暢度優先模式中率先啟用了該功能,在業務上稱為智能流暢模式,這樣在用戶就能夠在播放視頻時達到 30fps 的流暢度,在共享文檔/ppt 內容時,又能保持較高的清晰度。這個功能基本解決了用戶錯選流暢度優先造成的清晰度不符合需求的問題,同時又保證了在用戶在真正需要流暢度體驗的時候,得到高幀率的體驗。
落地效果
經過大范圍的線上測試之后,通過統計數據可以發現,采用“屏幕共享自動模式”后,一些原本采用“流暢模式”的共享場景被算法模塊糾正為了“清晰模式”,同時通過下圖可以發現,用戶的屏幕分享分辨率有了極大地提升,得到了顯著的清晰度提升。在線上算法的判定的準確程度上,通過對用戶反饋的統計,該功能也有著比較好的評價。
同時通過統計數據可以發現,得益于采集和編碼幀率的下降,CPU 占用不僅沒有上升反而得到了一定的優化,如下圖所示,開啟自動模式的功能之后,最高可以得到 CPU 占用降低 20%的收益。
與其他候選方案的比較
在研發之初,我們也調研了一些候選方案,一種技術方案是使用像素差異與變化的占比作為切換依據,這樣最大的問題是,在部分教學視頻或說明類內容中,在視頻內容中展示 ppt 場景時,算法會出現誤判,將肉眼感知到的靜態場景檢測為視頻場景,畫面清晰度下降,不符合用戶使用的直覺;此外還有一種方案是針對應用類型進行適配,比如根據進程名稱和窗口大小進行策略調整,這樣雖然能夠解決用戶場景化的需求差異,但是對于算法與策略的通用性會有較大的挑戰。本文使用的這套算法就能夠避開了上述的問題,體驗更加友好。
未來的演進與規劃
算法演進
雖然由于數據集的相對缺乏,在設計之初排除了深度學習模型的應用。在研發過程中,對算法流程與模塊進行拆分,其中獨立出的紋理分析等模塊,這樣就可以通過人工數據集的方式,在部分算法模塊嘗試應用深度學習模型,以期能夠獲得更好的算法表現。同時,考慮到當前的算法還是針對全局畫面的分類,未來會推出視頻區域的 ROI 檢測,這樣能夠讓下游應用具有更強的靈活性和對業務的適應能力。
業務演進
當前屏幕內容檢測算法支持了共享模式的切換,此外,利用屏幕內容檢測算法,還可以對發送端和接收端的網絡策略進行更智能的調優,以期在文檔、ppt 場景下,進一步減少屏幕共享的延時與卡頓,讓投屏與屏幕共享響應更高清、更流暢、延時更低,給用戶提供更好的沉浸式體驗,帶來更顯著的生產力的飛躍。
-
視頻會議
+關注
關注
4文章
158瀏覽量
30167 -
RTC
+關注
關注
2文章
538瀏覽量
66463
發布評論請先 登錄
相關推薦
評論