了解 WebRTC 音视频通话质量的指标,及如何跟踪和改进

WebRTC 因其易用性和低延迟性而成为实时通信应用的热门选择。然而,与任何技术一样,WebRTC 也并非没有缺陷。在 WebRTC 通话中,我们经常会遇到几个常见问题。这些问题会影响通话质量和整体用户体验。

网络条件、操作系统、音频和视频设备等一些因素不在我们的控制范围之内,从而导致用户的通话体验出现问题。在本文中,我们将讨论衡量 WebRTC 音视频通话质量的关键指标,并学习如何跟踪和改进这些指标以提高用户体验。

但首先,我们将把影响通话体验的问题分为以下几类。

1. 单向音频或视频: 单向媒体是指接收方听不到/看不到您,但您能听到/看到接收方(反之亦然)。

可能的原因如下:

  • 可能是由于不正确的网络设置/网络阻塞造成的,这会导致客户端的 ICE/STUN 绑定失败和媒体连接失败。
  • 单向音频或视频的另一个可能原因是网络连接不畅。当连接较弱或不稳定时,会影响音频和视频传输的质量。此外,与会者可能会不小心将麦克风静音或关闭摄像头,从而导致单向音频或视频。

2. 音频和视频延迟: 从源媒体采集到接收端播放所需的时间称为端到端延迟。如果这个延迟指标明显偏高,媒体就不再被视为实时媒体,用户的体验就会下降,我们称之为音视频延迟。通常情况下,超过 300 毫秒的端到端延迟会被视为次优。

这会导致对话不连贯和视频不流畅,对用户体验造成负面影响。

造成这一问题的一个常见原因是网络往返时间(RTT)过高,它测量的是数据包从发送方到接收方再返回所需的时间。高 RTT 值可能表明网络拥塞。

要解决这个问题,必须提高网络带宽。这有助于降低 RTT 值,提高通话的整体质量。改善网络带宽有几种方法,例如使用有线连接而不是无线连接、升级互联网计划以及限制通话期间连接到网络的设备数量。

除了改善网络带宽外,还可以实施其他策略来降低 RTT 和提高通话质量。这些策略包括实施拥塞控制策略、纠错技术和带宽管理策略。

拥塞控制策略(如 TCP 友好速率控制)可以防止网络拥塞和数据包丢失。这有助于确保数据包不丢失并保持通话质量。前向纠错(FEC)等纠错技术可帮助恢复丢失的数据包,降低音频和视频延迟的风险。动态比特率适应等带宽管理策略可帮助优化带宽使用,确保流畅无缝的用户体验。

3. 媒体断断续续或损坏:当双方都可以连接时,连续出现有损或质量差的音频会使对话难以理解。

高抖动是此问题的主要原因之一。抖动是指数据包从发送方传输到接收方所需时间的变化。由于抖动较高,数据包可能会无序到达,从而导致音频断断续续或损坏。

减少抖动的一种策略是实施拥塞控制技术。另一种技术是使用纠错方法,例如前向纠错 (FEC),它可以帮助恢复丢失的数据包并降低音频断断续续或损坏的风险。

对于视频,这将导致 FPS 不稳定并丢失帧,从而导致视频冻结。

4. 低质量视频:当视频的分辨率低于可接受的阈值时,可能会导致图像模糊或像素化,难以观看。

  • 如果空间联播处于活动状态并且接收器网络条件不足以处理更高质量的流变体,则 SFU 侧的带宽估计将切换到低质量流。
  • 在发送方,低质量输出可能有多种原因。
    • 如果可用的处理能力不足以进行高质量编码,编码器会将输出切换为低质量。
    • 编码器还获取网络反馈并使用它来调整 BWE 的质量,如果网络不足以以较高质量传输流,则会切换到较低质量。
    • 如果编码器保留分辨率或每秒帧数,还可以在出现问题时向编码器传递提示。默认值为“平衡”,因此对于喜欢保留质量的应用程序来说,这可能无法正确配置。
    • 另一个可能的原因可能是相机输入的质量低且不支持更高分辨率。

5. 视频滞后和音频/回声低:当视频的每秒帧数不理想时,会导致视频播放不和谐。

  • 如果时间联播处于活动状态并且接收器网络条件不足以处理更高 FPS 流变体,则 SFU 侧的带宽估计将切换到较低的时间层。

低音频或回声可能会产生问题,导致很难听到和理解其他参与者所说的内容。测量和优化通话质量对于增强 WebRTC 音频视频通话的用户体验至关重要。

WebRTC 通话中需要注意的指标

  • 数据包丢失是衡量 WebRTC 通话质量时最重要的跟踪指标之一。这是因为数据包丢失可能会导致音频和视频质量下降,让用户感到沮丧。当数据包丢失时,接收方可能会遇到音频或视频断断续续的情况,甚至音频或视频完全丢失。这就是为什么将数据包丢失保持在最低限度以确保流畅、无缝的用户体验非常重要。
    • getStats –fractionLost(丢包率)
  • 往返时间 (RTT)是 WebRTC 中测量通话质量时需要跟踪的另一个重要指标。RTT 测量数据包从发送方传输到接收方并返回所需的时间。高 RTT 值可能表明网络拥塞,导致数据包丢失和通话质量差。当 RTT 较高时,用户可能会遇到音频或视频延迟甚至完全丢失的情况。通过跟踪 RTT,开发人员可以识别导致拥塞的网络区域,并采取措施缓解拥塞。
    • getStats –roundTripTime
  • 抖动(jitter)是数据包从发送方传输到接收方所需时间的变化。高抖动值可能会导致音频和视频失真,这可能会让用户感到沮丧。通过跟踪抖动,开发人员可以识别导致抖动的网络区域,并采取措施减轻抖动。
    • getStats –jitter
  • 图像丢失指示 (PLI)是从接收器到发送器的信号,指示视频帧已丢失。跟踪该指标非常重要,因为丢失的视频帧可能会导致视频流卡顿或冻结,这可能会让用户感到沮丧。通过跟踪 PLI,开发人员可以识别视频帧丢失的时间和地点,并采取措施提高视频流的质量。
    • getStats – pliCount
  • 丢帧:当传输过程中丢失一帧或多帧时,就会发生丢帧,导致通话期间视频断断续续或不稳定。
  • 每秒帧数 (FPS)是视频中每秒显示的帧数。在WebRTC中,我们可以通过计算给定时间间隔内显示的帧数来测量FPS。当帧速率太低时,用户可能会遇到视频流卡顿或冻结的情况。
  • 当视频编码器无法跟上帧速率时,就会发生隐藏事件,导致视频流中的视觉信息丢失。
  • 网络资源(例如带宽和 CPU 使用率)也会影响通话质量。当带宽不足或CPU资源不可用时,用户可能会遇到通话质量较差的情况。通过跟踪这些资源,开发人员可以确定资源何时何地过度紧张,并采取措施对其进行优化。
    • getStats-qualityLimitationReasonqualityLimitationDurationqualityLimitationResolutionChanges
  • 总处理延迟是数据包从发送方传输到接收方所需的时间,包括每一端的处理时间。在WebRTC中,高处理延迟会导致延迟并影响通话的整体质量。
  • 抖动缓冲延迟是接收器在播放传入数据包之前缓冲它们所花费的时间。在WebRTC中,高抖动缓冲延迟会导致延迟并影响通话的整体质量。
    • getStats – jitterBufferDelay

纠错是提高 WebRTC 通话质量的另一个重要策略。当数据包丢失时,前向纠错 (FEC) 等纠错技术可以帮助恢复数据包。FEC 为发送的数据添加冗余,允许重建丢失的数据包。使用 FEC,开发人员可以帮助确保丢失的数据包不会导致通话质量不佳。

带宽管理对于确保 WebRTC 中良好的通话质量也很重要。当可用带宽不足时,用户可能会遇到通话质量较差的情况。动态比特率适应等带宽管理技术可以帮助优化带宽使用,从而实现流畅、无缝的用户体验。

监控这些指标

要监控这些指标,WebRTC 开发人员可以使用 getStats() 从客户端 RTCPeerConnection 提取这些指标。

虽然客户端的提取很简单,但要建立一个可观察性管道来摄取这些指标、持久化它们并从中获取有价值的数据并不简单。最简单的方法是使用 testRTC 的 watchRTC 等产品,它提供端到端监控功能。但是,一旦您想超越基本功能并需要自定义监控/分析,您可能就必须独立构建这种功能。

通过这种可观察性,您可以查看特定的用户会话,了解呼叫的执行情况,并找到潜在问题的根本原因,以防用户没有获得最佳体验。它还能让您监控全系统范围内的通话性能汇总数据,从而进行精确分析。

例如:

  • 了解不同浏览器版本(如从 Chrome 110 到 Chrome 111)对性能的影响
  • 了解特定地区或互联网服务提供商的性能,并了解它们与媒体服务器的连接情况

不过,有时 getStats() 并不能提供完整的信息。您必须对 TCP/UDP 层进行分析。获取这些数据并不容易,因为浏览器无法提供这些数据,而且需要运行 tcpdump 等工具来捕获低层转储(pcaps),然后在 Wireshark 等工具中查看这些转储。

在低层,当网络拥塞时,数据包可能会丢失,导致通话质量低下。拥塞控制策略(如 TCP 友好速率控制)有助于防止网络拥塞和数据包丢失。通过限制数据包的发送速率,拥塞控制可帮助确保数据包不会丢失并保持通话质量。

结论

测量和优化通话质量对于增强 WebRTC音视频通话的用户体验至关重要。开发人员可以通过跟踪数据包丢失、RTT、PLI、帧速率、抖动和网络资源等指标来识别和缓解质量问题。通过实施拥塞控制、纠错和带宽管理策略,开发人员可以提高通话质量,为用户提供更流畅、更无缝的实时通信体验。

借助正确的工具和技术,开发人员可以确保他们的 WebRTC 应用程序提供尽可能最高质量的音频和视频体验。

本文为原创稿件,版权归作者所有,如需转载,请注明出处:https://www.nxrte.com/jishu/webrtc/31358.html

(1)

相关推荐

发表回复

登录后才能评论