数据驱动直播体验改善

       最让程序员头疼的事是什么？是代码写得正酣，咣叽来了个工单，被迫打断手头工作。最让程序员崩溃的工单是哪种？是不描述具体情况，只骨感地甩过来一句，“卡啊我”。

       也罢，硬着头皮查上报、查日志、查指标，没料到数据居然都正常，网络没丢包，时延不高，服务也没告警，为啥我们的上帝就卡了呢。理性和耐心正在消耗殆尽，情急之下，只好祭出重启大法：“请把电脑重启一下试试，哦对，家里路由器也顺便重启一下”。

       工单倒是暂时挂起了，然而问题实际上没解决，过不了几天，另一个类似的工单，咣叽又回来了。

       问题究竟出在哪里？还是数据度量的问题。

• 视角不对：用户看到的是个体问题，而指标大盘往往是整体视角，平均之后，长尾问题被统计淹没了；

• 链路不全：整个端到端的业务链路路径，监控点覆盖不全，有缺失和短腿；

• 口径偏离：系统定义的卡，与用户主观感受到的卡，并不完全一致；

       举两个例子。

       视频播放器卡顿的定义，一般是在某个时间段内，譬如1秒或500毫秒，若持续没有视频帧输出就算一次卡顿，同时把这段时间记入卡顿时长。但用户主观上的卡，根本等不到帧率降为0，通常低于7帧的时候，就已经开始喊卡了。这就是度量的口径，偏离用户主观感受带来的问题。

       再比如开篇那个工单，用户遇到的并不是视频流的网络卡顿，而是手机负载高，系统渲染帧率从60fps，掉到了25fps以下，但我们度量的链路，到视频解码输出就终止了，并没有覆盖到最终渲染这一环节。

       没有度量就没有改善，然而虽有度量但跑偏了，也约等于没有度量。为了跳出工单的汪洋大海，逃离问题的六道轮回，我们先制定了数据指标和度量的原则。

• 有效性：工单反映出的问题，要能同某个指标的异常对应。这代表着我们能够准确地捕捉到用户实际使用中遇到的问题，尤其是体验最差的那部分用户的问题，确保我们对用户体验的关注无遗漏。

• 合理性： 设定指标所要达成的目标时，首先要能够保障用户体验的底线，其次要参考行业标杆的水准。

• 可达性： 指标的优化与提升，需要与我们的技术能力与可控变量相匹配，以便能切实达成和落实改善，避免出现定目标拍脑袋、抓过程拍胸脯、拿结果拍屁股的不良状况。

       这三个原则构成了我们质量改善指标的基础，确保我们的度量方式，既能够反映实际问题，又具备相应的合理性和实操性，为音视频质量的持续优化，指明了方向。

       据此，我们重新审视用户最常反馈的“卡”，细分拆解，从系统稳定性、视频流稳定性和音画质量这三个方面出发，制定出12个分项指标及对应的改善目标。

       特别值得注意的是，质量改善的本质是缩小统计方差。因此，我们选择的优化目标，是改善最糟糕的那一小撮用户的体验，除了关注指标概率分布的整体情况之外，还以95分位用户、95分位时刻的值，作为指标的统计口径。

      核心问题虽然就一个字，卡。但卡顿的背后，是一个复杂的系统，涉及网络状况、终端设备性能、视频流协议、服务端策略等多个因素，相互作用。

      我们虽然已经整合了一系列主流的网络与音视频处理算法，包括丢包重传、缓存优化、自适应码率、回声消除以及AI降噪等，但对于网络设备环境较差的用户而言，优化效果仍欠佳，超出了现有算法的适应范围，没有达到指标预期。

       因此，卡顿治理，本质上是算法策略驱动之下的弱网适应与设备适配。以下选取了3个指标的优化过程来说明。

a. 音画同步

      RTC中的音频和视频是分开传输的，两个通道各自独立控制，到了最后的播放环节才同步对齐，在弱网环境下，当两路传输的速度不一致时，若一味追求播放输出的稳定，就会牺牲同步，出现偏差。

       采集数据、校正统计方法后，我们发现音画同步偏差的指标，竟然超过了4秒！问题不容乐观，分析之下发现，指标差的用户样本背后，有一些相似的特征。

       首先是抗抖动的Jitter Buffer，预估算出的波动范围，比实际可容忍的网络抖动大得多，弱网情况下，端到端的延迟累积会变得非常大，潜在的同步偏差范围，也随之增大。

       其次，音频的延迟估计，也存在不合理的情况。网络均衡器（NetEQ）在遇到丢包重传时，二次重传的数据包，如下图中的T2，前后计算了两次接收时间，使得音频帧播放的时间，较实际情况偏慢一些，丢包率越高，重传的包越多，这个偏差就会越大。

       再者，播放端同步偏差的响应和收敛速度太慢，出现轻微不同步时未及时纠正，偏差较大时，纠正的节奏太慢、步长太小，整个过程需要超过10秒才能重新同步。

       此外，服务端视频缓存的队列长度也过大，当上行出现丢包、下行转发阻塞时，视频可能大幅落后于音频，这对于实时性要求高的场景，是没必要的。

       问题界定清楚后，针对改进的策略就比较明晰了：

• 控制播放端的视频Jitter Buffer，使其动态范围与链路的实时性要求相匹配；

• 改进NetEQ中音频延迟计算，排除重传包，并增加平滑窗处理；

• 缩小同步偏差校正范围，并加快同步校正的收敛速度；

• 缩小服务端视频队列的时间窗，控制弱网情况下的端到端时延；

       随着上述改进策略的陆续实施，同步偏差的指标，从3秒持续降至1秒内，达成了目标基线。

b. 播放帧率

       播放端的流畅度，由网络视频流与设备的流畅度共同决定。为了适配不同的设备需求和网络条件的变化，我们在服务端采用了Simulcast的多码流技术方案，可动态自适应地调整视频流的码率，如下图所示：

       服务端为了实现动态码率调整，需要根据每个用户实时反馈的网络参数，如丢包率、传输时延等，持续进行链路带宽预测。

       深入分析发现，在某些网络条件下，带宽预测会出现过于保守、低于实际的情况，低估的带宽，又导致了不必要的码率和帧率下降。

       因此，我们双管齐下。在带宽预测的模型中，细化了场景识别与对应的判断逻辑，改善了网络条件剧烈变化时的带宽估计准确性。另一方面，控制帧率主动下降的幅度，适当减少丢帧，在代表播放流畅度的帧率，与带宽受限的卡顿之间，取一个更合理的平衡点。

       经结果数据验证，帧率指标从3.5fps，升至7fps上下，充分挖掘了带宽受限网络的潜力，改善了用户体验。

c. 音质

       根据用户的反馈，音频相关的问题占比较大，有“声音忽大忽小”、“有噪音”、“声音间歇性消失”等典型问题，与我们期望的声音品质，还存在不小的差距。梳理、分析这些场景，有几个方面的影响因素。

       首先是网络丢包。先前的FEC补偿策略，都是检测到丢包后才触发，只能应对随机的小规模丢包，而对于突发的密集丢包，则处理效果欠佳。

       第二是主播端的环境噪音，被麦克风采集之后，不仅降低语音质量，还会干扰语音特征，影响算法效果，尤其是混入外置扬声器播放的音乐时，听感体验严重恶化。

       第三是回声抑制造成的额外消音。连麦时，若近端和远端同时说话（双讲），近端麦克风采集进入回声消除（AEC）模块的信号包含了两部分，除扬声器外放的远端用户语音回声Y(n)之外，还有近端用户自己的语音S(n)。由于S(n)会对AEC模块的回声预估产生严重的干扰，在双讲出现的时候，AEC模块的回声过滤器参数，需要暂停更新，这就用到另一个关键而又复杂的双讲检测模块（DTD，double talk dedector），若DTD的检测滞后不及时，近端用户自己的语音，会被AEC模块连同回声共同消除一部分，在远端用户那里听起来，就会呈现忽强忽弱的卡顿现象。

       为解决上述问题，我们采取了一系列措施：针对突发密集丢包配置了重传ARQ策略，配合FEC提升抗丢包能力；通过引入深度学习的降噪模型，实现高效率的实时环境噪声抑制；升级语音双讲检测模型至48K采样率，减少误检率；采用256点FFT代替128点，提升频域分析精度与时延估计的准确性；提升AEC无回声条件下自适应滤波器的参数更新速率，加快收敛，减少音损;

       经上述优化，连麦音质指标提升至2.3，非连麦音质指标提升至2.5。虽然离目标还有一些差距，问题厘清后，优化的发力方向是明确的。

       程序员、工程师真正的核心职责，其实不是写代码，而是解决问题。而解决问题的过程，是一个探索、知真之旅，是一个追求以假设为驱动、以事实为基础、符合逻辑的真知灼见的过程。带着对某个问题的分析、猜测与假设，下场实施改善，然后根据结果数据的变化，最终证实或证伪最初的假设，进而获取认知的刷新。

       譬如，在面对用户的弱网环境时，我们最初的认知和假设，是通过建设边缘网络，来提升最后一公里的整体接入质量。然而在实践中发现，事实并非如此。最大的网络问题，并不在最后一公里，而是出在最后十几米的Wi-Fi信号的衰减与拥塞上，边缘网络对95分位的用户，非但无改善，甚至有变得更差的趋势。此例之中，我们通过观测事实，修正了最初的假设，形成了更具应用价值的认知。

       因此，解决问题非常需要抱持批判性思维，以确保事实和逻辑最终能趋于一致。

       我们将努力持续提升直播视频的质量，确保用户在每一次教学互动中，都能够沉浸和专注。这不仅是对团队技术水平的挑战，更是对用户体验的承诺。

       另一方面，我们是一个对最终教学效果负责的技术团队，因此，我们还将建立教学效果的数据度量体系，来指引我们的教学直播系统迭代，激发学习兴趣，提升学习效果。这既是对技术创新的期许，更是对在线教育不断进步的积极贡献。