体育直播反复卡顿：检查上传、WiFi 与编码器

热身画面清晰，比赛开始后，观众刚开始上传片段，直播就卡顿。这时容易想购买更快的路由器，但故障可能来自繁忙的 WiFi 信道、过载编码器、不稳定上传，或某一观众的连接。

更改设置前，先通过简短演练隔离故障阶段。在活动许可允许时保留本地录像，避免网络问题同时导致失去赛事唯一可用副本。

找出卡顿从哪里开始

在 OBS 及类似软件中，渲染延迟、编码延迟和网络丢帧描述的是不同问题。记录相关计数器及其上升时间。降低相机分辨率无法修复所有网络故障，移动 AP 也无法解决视频编码器过载。

预算应按输出直播，而非下载速度

根据预定平台和编码器选择分辨率、帧率、编解码器与码率。每场活动前确认平台当前设置。球场上的快速运动，比静止图像更适合作为演练内容。

上传计算示例： 编码器设置为 8 Mb/s 视频加 0.2 Mb/s 音频时，发送量约为 8.2 Mb/s，尚未计入传输开销。在此设置下，两个独立输出约需 16.4 Mb/s，三个约需 24.6 Mb/s，且尚未计入其他流量。这些是按配置负载计算的数值，并非平台预设或实测性能结果。

多台相机输入同一节目编码器时，通常产生一条输出节目流。除非这些相机确实通过该连接发送独立流，否则不要按相机数量成倍计算互联网预算。

应在场所可持续上传速率以下保留余量。简短测速可提供参考，但不能证明链路能在繁忙比赛期间持续承载所选码率。应在正常场所流量活动时测试完整直播。

沿画面路径一直检查到观众端

请使用其他互联网连接的远程观察者协助。让他们检查讲话、人群运动、比分变化及播放失败的位置。通过同一场所 WiFi 观看的手机，不能独立证明外部观众收到正常直播。

对照时钟时，应考虑平台正常播放延迟。延迟本身与反复卡顿或音频缺失不同。

先尝试编码器有线连接

可行时，将编码器接到经过测试的网络点。确认笔记本识别适配器、使用正确接口，且上联稳定。USB-C 连接器本身不代表支持充电、视频或某种以太网速率。

该 TP-Link UE300C 为兼容的 USB-C 主机提供千兆以太网路径。它是以太网适配器，并非充电扩展坞。活动前核实操作系统、可用主机端口及线缆。

如果无法避免 WiFi，应测试实际制作位置与当地信道条件。应有计划地安排普通访客流量和编码器持续需求。在 AP 旁用手机上传，不能替代编码器的完整直播测试。

为每个网络组件明确分工

更快的端口或新路由器，只有在针对限制阶段时才有用。流量优先级可安排相互竞争的需求，但不能创造互联网带宽。测试任何优先级或限速策略时，应让报名服务台及其他关键服务继续运行。

备用 WAN 也需要演练。切换到其他供应商可能改变公网地址，并中断当前直播会话。请参阅 为什么双 WAN 故障切换时通话和会话仍可能中断。不要仅因接了两条互联网线缆，就宣传赛事直播可以无缝持续。

开场哨前先演练

1. 采用真实制作链路。 保留预定相机、采集设备、音频、笔记本供电及编码器设置。
2. 进行持续演练。 例如，持续直播 15–30 分钟，包含运动、讲话与预计场所活动。更长活动可能需要更长时间的持续运行测试。
3. 检查两端。 同时观察本地编码器统计，以及使用其他连接的远程观众。
4. 测试备用方案。 确认主 WAN 失效时会发生什么，以及操作员如何恢复节目。
5. 保存可用配置。 记录网络点、编码器配置、上传设置与恢复步骤。

从故障证据开始。 如果本地录像正常，而有线路径消除了网络丢帧，应修复无线或上传路径。如果本地帧已失败，应先排查制作与编码。目标是稳定的完整节目，而非一次亮眼的独立测速。

常见问题