WebRTC 的一个有趣的功能是能够为媒体轨道配置一个内容提示,以便 WebRTC 能够为该特定类型的内容优化传输。 这样,如果内容提示是 “文本”,它将尝试优化传输的可读性;如果内容提示是 “运动”,它将尝试优化传输的流畅性,即使这意味着降低视频的分辨率或清晰度。
这在分享文档或幻灯片时特别有用,因为文本的 “清晰性 “对用户体验非常重要。 你可以在这张截图中看到这些提示对视频编码的影响,该截图取自W3C规范:
这非常有用,但有一个小问题。当我们不知道共享内容的类型时会发生什么?我们如何知道共享的浏览器选项卡是否有一些静态文本幻灯片或正在播放的 YouTube 视频?一种可能的选择是进行某种类型的图像处理以检测视频帧中的内容类型并检查文本内容。如果每隔几秒只运行一次,那是可行的并且不会那么昂贵。但现在我更感兴趣的是使用现有的 WebRTC 统计数据作为代理来检测内容的类型,所以我尝试了一些沿着这些思路的方法。进行这种检测的另一个动机可能是出于分析目的,以更好地了解用户如何与产品交互,并进一步更改应用程序以针对这些用例对其进行优化。
屏幕共享内容检测最简单的方法
这个想法是,当你发送静态内容(幻灯片)时,WebRTC 注意到帧与前一帧没有变化,并跳过发送新帧,因此它最终每秒仅发送约 1 帧。
通过这种方法,只需检查使用 getStats() API 发送的帧率,我们就可以高度确信内容是静态的。例如,我们可以使用 2-3 fps 的阈值来区分静态和动态内容。
特别案例:
- 发送低帧率是因为可用带宽太低,而不是因为内容是静态的。我不认为 libwebrtc 在那种情况下会发送如此低的帧率,但无论如何我们可以通过检查 WebRTC 统计数据的“availableOutgoingBitrate”和/或“qualityLimitationReason”来区分这种情况。
- 当你将光标移到幻灯片上时,或者幻灯片的一个角上有一个小的动画徽标,或者你正在共享一个文本编辑器但有一个闪烁的小光标。在那些情况下,这种方法将不起作用,因为发送的帧率会很高。
详细方法
这个想法是,当你发送静态图像时,你可以用更少的位数发送更高质量的图像,因为图像不会从一帧到下一帧发生变化,所以它需要更少的像素来编码。
我们可以使用来自 WebRTC 的帧率、qp(量化参数)和分辨率统计数据,并计算出一个直观显示 Quality / BitsUsedPerPixel 的数字。
您可以在这个 jsfiddle 中看到实现:https://jsfiddle.net/zb8w4nd5/3/
我使用包含两张幻灯片的文档测试了这两种方法,一张静态包含文本和一张图像,另一张嵌入了 youtube 视频。结果显示在下图中。
我们可以在图中看到的一件事是,帧率是一个很好的代理,除了鼠标光标等一些“人为”移动之外。从这个意义上说,质量因素看起来是一种问题较少的方法。正如你再次从视频幻灯片切换到文本幻灯片后在图表中看到的那样,需要一点时间质量才能恢复。结合这两种方法并在这种情况下使用帧速率可以使检测速度更快。
其他注意事项:
- 忽略前几秒可能是个好主意,因为它可能需要一点时间才能稳定下来。
- 添加一些滞后或窗口平均值以避免在切换幻灯片或在文本文档中滚动时检测到。
- 品质因数假设一切都是线性的,也许其他方法(对数、二次…)可以获得更准确的结果。
- 我还没有在真正的产品中使用过它,所以把它当作一个要探索的想法列表,而不是一个完整的可靠算法。
本文为原创稿件,版权归作者所有,如需转载,请注明出处:https://www.nxrte.com/jishu/webrtc/26572.html