推流自动切换这个功能,几乎所有编码器和推流软件都有,开关就摆在那儿。但真正把它配对的人不多——要么配得太灵敏,网络抖一下就切,一场直播切七八次;要么配得太钝,主线路都断了二十秒才反应过来。
我们在自己的测试机房花了两个下午,把这些参数一格一格试过去。用的是三台不同品牌的硬件编码器加一套开源方案,模拟了六种断流场景。这篇把实验数据摊开写,包括那些跟说明书不一致的地方。
先说清楚"断"有几种
大部分人理解的断流就是网线拔掉。实际现场遇到的断法比这复杂得多,而推流自动切换的判定逻辑对不同断法的反应差异极大。
我们模拟的六种:物理断链(拔网线)、上行拥塞(带宽压到码率的六成)、丢包(注入 15% 随机丢包)、服务端拒绝(源站返回 403)、DNS 解析失败、TCP 连接假死(链路通但对端不回 ACK)。
前四种大部分设备都能正确识别。真正会翻车的是后两种。DNS 失败时,某品牌编码器的表现是持续重试同一个域名,重试间隔还是固定的 5 秒,试了六次共三十秒才判定失败——这三十秒直播已经黑掉了。TCP 假死更麻烦,链路层看起来一切正常,编码器的发送缓冲区在涨,但很多设备只监控"连接是否存在",不监控"数据是否真的发出去了",于是一直不切。
摄行科技现在给客户配推流自动切换,第一件事就是问设备支不支持基于发送缓冲区水位的判定。不支持的话,后面的参数怎么调都是治标。
判定窗口:3 秒是个坎
判定窗口是最核心的一个参数,指的是"连续多久检测不到有效发送才判定为断"。
我们从 1 秒试到 10 秒,每档跑二十次断流演练,同时记录另一个数字——正常直播两小时内的误切次数。
- 1 秒:切换响应快,平均 1.4 秒完成判定。但两小时误切 11 次。会场 WiFi 环境下更夸张,单小时能到 20 次。
- 2 秒:判定 2.3 秒,两小时误切 4 次。
- 3 秒:判定 3.2 秒,两小时误切 0 次(跑了三轮共六小时,一次没有)。
- 5 秒:判定 5.1 秒,零误切。但观众端能明显感觉到卡顿。
- 8 秒以上:观众开始退出。我们看播放端数据,断流超过 6 秒,退出率明显上台阶。
3 秒是个比较清楚的拐点。低于 3 秒,误切概率陡增;高于 3 秒,收益递减但体验损失线性增加。我们现在的默认建议就是 3 秒,有线专线环境可以压到 2 秒,会场 WiFi 或者 4G/5G 环境建议放到 4 秒。
需要说明的是,这个 3 秒是"连续无有效发送"的时长,不是"丢包持续时长"。有些设备的参数名叫 timeout 但实际语义是后者,配之前一定要看清楚文档,或者干脆自己做一次拔线实验拿秒表掐。
切换耗时:比判定慢得多
判定完成不等于切过去了。从判定到备线出画,中间还有一段。
我们测的三台硬件编码器,这段耗时分别是 1.8 秒、2.6 秒、4.1 秒。差异主要来自备线连接是"常连"还是"按需建连"。常连的那台最快——备线的 TCP 连接一直保持着,只是不发数据,切换时直接开阀门。按需建连的那台每次都要重新握手、鉴权、协商,四秒多就是这么来的。
所以推流自动切换的真实中断时长 = 判定窗口 + 切换耗时。3 秒判定加 4 秒切换就是 7 秒,观众绝对有感。
结论很直白:能开备线常连就一定开。代价是备线的推流地址会一直占着一个连接槽位,某些平台会按连接数计费,但这个钱值得花。摄行科技的现场包里现在标配一句检查项——"备线常连是否已开启",写在开播前四十分钟的检查表上。
重试次数这个坑
很多设备把"重试次数"和"判定窗口"做成了两个独立参数,而且默认值互相打架。
举个真实例子:某台设备默认判定窗口 3 秒、重试 3 次、重试间隔 2 秒。看上去挺合理。实际逻辑是:检测到异常后先重试 3 次,每次间隔 2 秒(共 6 秒),重试都失败才进入 3 秒判定窗口。真实响应时间是 9 秒,不是 3 秒。
这个坑我们踩过。一次年会直播主线路被物理断了,现场看编码器指示灯变红,但备线迟迟不出画,导播在耳返里连喊三遍。事后查日志才发现是重试逻辑在前面吃掉了六秒。
现在的做法是:重试次数一律设 1,靠判定窗口来兜。重试的意义在于抵抗瞬时抖动,但判定窗口本身已经是一个时间窗口了,两个机制叠加就是重复保险。相关的现场排障思路,直播延时器在什么场合必须上那篇里有互补的角度。
码率回退要不要一起开
切到备线以后,备线的带宽通常不如主线路。这时候有两种策略:保码率(可能推不上去继续断)、降码率(画质掉但稳)。
我们建议开自动降码率,但降幅要设死,不能让它自由发挥。实验里把自动档位打开,某台设备在丢包场景下一路降到 380kbps,画面糊成马赛克,还不如断了重连。
推荐的配置是:备线码率上限设为主线路的 60%,下限设为主线路的 40%,超出下限就不再降、改为提示导播。1080p 主线 6Mbps 的话,备线区间就是 2.4M 到 3.6M。这个区间下 1080p 画质会有可见损失,但 PPT 文字和人脸依然清楚。
有一点容易忽略:降码率会导致分辨率是否同步下降,不同设备行为不一样。有的设备只降码率不降分辨率,结果 1080p 挂 2.4M,画面在运动镜头下糊得很难看;有的会自动降到 720p,反而清楚。我们的习惯是手动把备线预设为 720p,不让它自己判断。
切回主线路这件事
切过去容易,切回来是个哲学问题。
自动切回听起来很美,但主线路恢复后往往还不稳定,自动切回容易造成来回震荡。我们测过一种极端情况:模拟主线路间歇性丢包,自动切回打开的情况下,二十分钟内来回切了 14 次,每次切换观众端都有一到两秒卡顿。
现在统一的做法是自动切出、手动切回。主线路恢复后系统只在导播台上亮一个绿灯,导播判断时机(通常等到 PPT 翻页或者环节间隙)手动切回。这跟前面讲的降码率下限提示是一个逻辑——机器负责发现,人负责决策。
演练要怎么做才有意义
配完参数一定要演练,但演练方式很多人做错了。常见的错法是开播前拔一次网线,看到备线出画就算过。
问题在于,这只测了物理断链这一种场景,而且是在没有观众、没有录制、导播不忙的理想状态下。
摄行科技现在的演练流程是三次:开播前四十分钟做一次物理断链,开播前二十分钟做一次带宽压制(用限速工具把上行压到主码率的一半),彩排过程中随机做一次不打招呼的断流——这次连导播都不知道,专门测人的反应。第三次最有价值,前两次都通过而第三次翻车的情况我们遇到过四回,原因清一色是"人没看到告警"。
演练的记录要留档,包括每次的判定耗时、切换耗时、观众端表现。这些数据在事后如果真出了事故要划责任,是最硬的材料。关于责任划分的具体条款,直播出了事故责任到底怎么划分里写得比较全。整套链路的可靠性,还可以配合5G背包直播能不能替代专线一起看。
一份可以照抄的参数
给一个我们现在用的基线配置,场地是有线专线加 4G 备份:
判定窗口 3 秒 / 重试次数 1 / 备线常连开启 / 备线分辨率固定 720p / 备线码率上限 3.5Mbps 下限 2.4Mbps / 自动切出开启 / 自动切回关闭 / 告警同时推导播台和微信群 / 切换日志本地留存 30 天。
WiFi 或纯移动网络的场地,判定窗口改 4 秒,备线码率上限降到 2.5M。
这套参数的依据一部分来自行业公开的流媒体传输规范,可以参考中国通信标准化协会发布的相关文档(ccsa.org.cn)和万维网联盟关于媒体流传输的技术说明(w3.org)。
不想自己试的话
参数这东西,别人的配置永远只能当起点。你的场地、你的编码器、你的上行链路,组合出来的最优解一定不一样。但两个下午的实验成本对大部分团队来说太贵了。
摄行科技可以带设备上门做一次推流自动切换的实测,半天时间,出一份带数据的参数建议书,包含你们现有设备的判定耗时、切换耗时实测值,以及针对场地网络的推荐参数。有需要的话把编码器型号和场地网络情况发过来,先聊清楚做不做得了。要整场直播技术保障报价的,把场次规模和机位需求告诉摄行科技,我们按实际配置算。
#摄行科技
