RTC 场景下的屏幕共享优化实践2

算法参数优化与评价

数据采集和标注

由于数据集非常匮乏，需要我们自己高效地获取一批人工标注数据，进行参数的优化和算法的测试。我们自己录了一些数据，并开发了一个小型的标注软件，进行了数据标注工作。

算法评价指标

（图片来源：https://en.wikipedia.org/wiki/Sensitivity_and_specificity）

1. 准确率 （precision）

精确率是针对预测结果而言的，它表示的是预测为正的样本中有多少是真正的正样本。那么预测为正就有两种可能，一种就是把正类预测为正类(TP)，另一种就是把负类预测为正类(FP)

2. 召回率（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) ->(ρ,θ)

2. 纹理计算

参考了前文提到的两篇文献的相关工作，在 4x4 的 patch 内统计 Y 通道上的直方图特征，将 bin 的大小设为 1，统计 bin 的数量作为一个强特征。（这样实质就变成了统计有多少个 unique 值的问题），然后利用一个 hash 表进行映射与统计。随后与运动信息进行加权求和，可以获得一个全局的与运动相关的纹理特征值。

3. 角度特征的提取

角度特征的提取使用了方向统计的方法，计算得到当前内容运动角度的均值、加权均值、离散程度、加权离散程度等特征，这些特征可以描述当前画面内容的运动信息。

状态转移

利用决策树，经过一些剪枝处理后，获得了一些强特征的阈值，比如运动的角度均值，运动的角度离散度等，这些阈值都具有非常显著的可解释性。在状态转移模块中，使用内置的一个概率值记录状态，然后根据上述基于机器学习的规则对概率值进行调整，再结合业务融合一些人工特征，最终根据概率值的变化转移模块的状态。

计算开销优化

虽然该算法能够以较快的速度对视频帧进行处理，但实际的屏幕共享中，对计算机资源的消耗也有更加严格的要求。那么就需要对检测的的策略进行细致的优化，够进一步降低 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

2. 计算频率优化与静默模式

在计算量优化之后，算法能够以 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 场景下，进一步减少屏幕共享的延时与卡顿，让投屏与屏幕共享响应更高清、更流畅、延时更低，给用户提供更好的沉浸式体验，带来更显著的生产力的飞跃。