RTC 場景下的螢幕共享優化實踐

語言: CN / TW / HK

動手點關注乾貨不迷路  :point_up_2:

背景介紹

需求背景

螢幕共享是視訊會議場景使用最廣泛的功能之一,在共享一個 PPT 或者文件的情況下,人們對畫面清晰度有著極高的要求,“看不清” 是最容易被使用者吐槽的事情;而在共享一個視訊素材的情況下,大家又對流暢度有著極高的要求,“卡頓” 也是最容易被使用者吐槽的點。

為了更好地同時滿足使用者對清晰度和流暢度的要求,視訊會議軟體通常會設計兩種模式:

  1. 清晰模式:主打清晰度,儘量保持高解析度(如:最高 4K 原畫質),頻寬或效能不足的時候,只降低幀率(如:從 30fps -> 5fps),不降低解析度。

  2. 流暢模式:主打流暢度,儘量提升幀率(如:最高 30fps),頻寬或效能不足的時候,優先降低解析度(如:從 4K -> 720p),最後才考慮降幀率。通常情況下,預設選擇“清晰模式”,當用戶要共享視訊的時候,需要自己 “手動” 點選勾選上 “流暢度優先”按鈕。

一般的做法是,讓使用者在共享螢幕時手動來勾選“清晰模式”還是“流暢模式”。但在實際的產品場景中,使用者對這兩種模式的感知並不是很強烈,不太可能要求使用者在共享螢幕的過程中手動來回切換當前的共享模式,對使用者體驗影響比較大。

一種簡單的方案是根據使用者共享內容的檔案字尾名來決定是“清晰度優先”還是“流暢度優先”,比如共享 PPT 時自動切換為“清晰模式”,共享視訊時自動切換為“流暢模式”,但是這樣設計會遇到一些問題:比如使用者的 PPT 裡嵌入了一段視訊,在播放這段視訊時理應追求“流暢度優先”;而如果使用者視訊其實是一段 PPT 的教學錄屏,裡面有大量的時間在播放靜止的文字和畫面,這時候“流暢模式”則會導致這些關鍵內容顯得模糊。

RTC 要如何幫助使用者及時調整最佳的共享模式呢?

需求分析

需求功能分析

痛點:

使用者分享視訊內容需要高幀率,而文字/ppt 需要高清晰度,這兩種場景的需求是互相矛盾的,如果需要使用者手動勾選相應的共享模式,不僅操作繁瑣,也容易漏選、錯選。

如何解決:

需要研發一個演算法自動識別共享內容,進而確定當前是需要高幀率還是需要高清晰度。這樣,在使用者想要清晰畫面的時候,產品就提供清晰的畫面,使用者想要流暢的視訊體驗時,產品就儘可能地保障螢幕畫面的流暢性,使用者在無感知的情況下就能獲得當前場景的最佳體驗。

螢幕共享場景定義

清晰度優先的場景

以文字為主,使用者更需要看清楚畫面的邊緣特徵,而較少關注其運動特徵。

流暢度優先的場景

以視訊內容為主,使用者更需要流暢連貫的動態畫面,而較少關注於單幀的清晰度。

技術實現

演算法原理

學界相關成果概述

目前我們參考了以下兩篇參考文獻。第一篇是 Jing, Wang & Xuetao, Guan & Yang, Zhang. (2013). An Adaptive Encoding Application Sharing System Based on Remote Display. 266-269. 10.1109/ISDEA.2012.66.

該論文主要假定視訊區域的均會以 24-30FPS 的頻率發生變化,用 N*N 的 patch 的形式進行檢測,從而發現視訊區域。

第二篇參考文獻是,侯文慧, 王俊峰. 面向雲桌面協議的視訊區域偵測演算法[J]. 計算機應用, 2018, 038(005):1463-1469,1487.

這篇論文主要通過高變化區域偵測,並利用傳統 sobel 運算元+膨脹演算法的邊緣檢測發現可能的矩形區域,通過顏色直方圖的顏色數量判定文字區域從而確定視訊內容區域。

相關演算法的介紹

  1. 光流

光流(Optical flow or optic flow)是空間運動物體在成像平面上的畫素運動的瞬時速度,是分析畫素運動的一種方法。光流法在模式識別、計算機視覺以及其他影象處理領域中用處廣泛,可用於運動檢測、影象分割、運動補償編碼和立體視差測量等領域。

(光流示意,引用自:https://medium.com/axinc-ai/raft-a-machine-learning-model-for-estimating-optical-flow-6ab6d077e178)

光流法實際是通過檢測影象畫素點隨時間的變化進而推斷出物體移動速度及方向的方法。假設該移動很小,那麼可以根據泰勒級數得出:

因此可以推出

最終可得出光流方程:

這個方程有兩個未知數,不能直接進行求解,這被稱為光流演算法的孔徑問題。為了求解光流方程,還需要另一組方程,這個方程由附加的約束給出。(以上內容引用自 wikipedia)

孔徑問題

(孔徑問題示意,引用自:https://zhuanlan.zhihu.com/p/74460341)

假設:

  • 相鄰幀之間的亮度恆定;

  • 相鄰視訊幀的取幀時間連續,或者,相鄰幀之間物體的運動比較“微小”;

  1. 決策樹

決策樹是一種邏輯簡單的機器學習演算法,它是一種樹形結構,所以叫決策樹。這是一種基於 if-then-else 規則的有監督學習演算法,決策樹的這些規則通過訓練得到,而不是人工制定的。

  • 決策樹易於理解和解釋,可以視覺化分析,容易提取出規則;

  • 可以同時處理標稱型和數值型資料;

  • 比較適合處理有缺失屬性的樣本;

  • 能夠處理不相關的特徵;

  • 測試資料集時,執行速度比較快;

  • 在相對短的時間內能夠對大型資料來源做出可行且效果良好的結果。(引用自 wikipedia)

  1. 顏色直方圖

顏色直方圖是許多影象檢索系統中被廣泛採用的顏色特徵。它所描述的是不同色彩在整幅影象中所佔的比例,而並不關心每種色彩所處的空間位置,即無法描述影象中的物件或物體。(引用自 wikipedia)

  1. 方向統計(Directional Statistics)

Directional statistics (also circular statistics or spherical statistics) is the subdiscipline of statistics that deals with directions (unit vectors in R(n)), axes (lines through the origin in R(n)) or rotations in R(n). More generally, directional statistics deals with observations on compact Riemannian manifolds including the Stiefel manifold. The fact that 0 degrees and 360 degrees are identical angles, so that for example 180 degrees is not a sensible mean of 2 degrees and 358 degrees, provides one illustration that special statistical methods are required for the analysis of some types of data (in this case, angular data). Other examples of data that may be regarded as directional include statistics involving temporal periods (e.g. time of day, week, month, year, etc.), compass directions, dihedral angles in molecules, orientations, rotations and so on. (引用自 wikipedia)

利用方向統計方法,能夠準確地統計出向量樣本的方向均值,以及方向的離散程度,也避免了傳統統計方法在角度值統計計算上的誤差。

舉個簡單的例子,如下圖所示,7/4π 和 1/4π 統計均值,以傳統方法計算為 π,而利用方向統計就可以得到出均值為 0 的結果。

演算法總流程設計

視訊的定義就是運動的畫面,但在螢幕共享當中,並不能夠將運動的畫面都當作視訊內容來處理。實際使用中,需要將部分運動的畫面識別為需要高清優先、流暢度其次的螢幕內容,保證使用者在此時獲得清晰的觀看體驗。

  1. 探索性資料分析(EDA)

在正式進行演算法開發之前,先進行了探索性資料分析,分析發現螢幕的運動特徵具有較高的區分度,從而大致判定利用光流法來完成該任務的特徵提取是可行的。

  1. 演算法流程圖

該檢測演算法分成三個模組,五個步驟。

三個模組分別是:

  • 運動幅度分析:主要進行運動幅度相關特徵的提取,能夠統計運動畫面比例,去除一些噪音。

  • 運動角度分析:主要進行運動角度相關特徵的提取,能夠統計畫面運動的方向,以及運動方向的分散程度等

  • 紋理特徵分析:主要提取一些紋理相關的特徵,判定當前區域是否為文字區域。

具體分為五個步驟:

  • 取樣:光流演算法需要前後兩幀資料進行計算,需要對視訊流進行取樣,得到兩幀資料

  • 光流計算:計算出全圖的稠密光流

  • 特徵提取:提取運動和紋理特徵

  • 狀態轉移:通過一系列模式和規則進行狀態轉移

  • 輸出結果:根據內部狀態資訊輸出檢測結果

演算法引數優化與評價

資料採集和標註

由於資料集非常匱乏,需要我們自己高效地獲取一批人工標註資料,進行引數的優化和演算法的測試。我們自己錄了一些資料,並開發了一個小型的標註軟體,進行了資料標註工作。

演算法評價指標

(圖片來源:https://en.wikipedia.org/wiki/Sensitivity_and_specificity)

  1. 準確率 (precision)

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

  1. 召回率(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. )

特徵提取

在計算光流之後,我們需要提取運動幅度,運動角度以及紋理相關的特徵。

在計算光流之後,提取運動幅度、運動角度以及紋理相關的特徵。

  1. 座標系轉化:笛卡爾系->極座標系

光流估計得到的結果是每一個畫素的(x,y)偏移,所以需要將這個笛卡爾座標系的值轉化為極座標系,從而得到光流的運動幅度和方向資訊,即(x,y) ->(ρ,θ)

  1. 紋理計算

參考了前文提到的兩篇文獻的相關工作,在 4x4 的 patch 內統計 Y 通道上的直方圖特徵,將 bin 的大小設為 1,統計 bin 的數量作為一個強特徵。(這樣實質就變成了統計有多少個 unique 值的問題),然後利用一個 hash 表進行對映與統計。隨後與運動資訊進行加權求和,可以獲得一個全域性的與運動相關的紋理特徵值。

  1. 角度特徵的提取

角度特徵的提取使用了方向統計的方法,計算得到當前內容運動角度的均值、加權均值、離散程度、加權離散程度等特徵,這些特徵可以描述當前畫面內容的運動資訊。

狀態轉移

利用決策樹,經過一些剪枝處理後,獲得了一些強特徵的閾值,比如運動的角度均值,運動的角度離散度等,這些閾值都具有非常顯著的可解釋性。在狀態轉移模組中,使用內建的一個概率值記錄狀態,然後根據上述基於機器學習的規則對概率值進行調整,再結合業務融合一些人工特徵,最終根據概率值的變化轉移模組的狀態。

計算開銷優化

雖然該演算法能夠以較快的速度對視訊幀進行處理,但實際的螢幕共享中,對計算機資源的消耗也有更加嚴格的要求。那麼就需要對檢測的的策略進行細緻的優化,夠進一步降低 CPU 佔用和耗電量。

  1. 計算量與運算速度

演算法的運算量熱點都在光流計算上,而光流的計算開銷與選用的演算法、影象大小以及演算法具體引數有關。

演算法 解析度 執行時間
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
  1. 計算頻率優化與靜默模式

在計算量優化之後,演算法能夠以 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 場景下,進一步減少螢幕共享的延時與卡頓,讓投屏與螢幕共享響應更高清、更流暢、延時更低,給使用者提供更好的沉浸式體驗,帶來更顯著的生產力的飛躍。

加入我們

位元組跳動 RTC 團隊,作為全球領先的音視訊團隊,我們致力於提供全球網際網路範圍內高品質、低延時的實時音視訊通訊能力,目前已經支撐了抖音、TikTok、清北網校、位元組系遊戲,視訊會議等多個場景的應用,服務 10 億使用者,使用者遍佈全球每一個角落。

我們是 RTC Lab 部門, 負責 RTC 產品中音訊、視訊、網路等基礎功能的研發,通過極致的工程和音視訊演算法,打磨頂級的實時音視訊基礎體驗,期待優秀同學的加入  :runner: 點選 “閱讀原文“ 連結,加入我們吧!

  點選“閱讀原文”,一鍵投遞簡歷!