直播推流端是整个直播内容的生产源头。我们熟知的推流工具有:PC 推流工具 OBS、手持设备和各个直播平台的手机推流 App、针对一些复杂场景有更专业的导播台硬件等等。虽然工具众多,但推流端的整个工作流程还是比较固定的:
摄像头、麦克风采集 → 视频编码、音频编码 → 音视频封装合流 → 推流
在推流端我们可以针对用户播放体验做的优化主要包含:推流断流优化和推流延时优化。
在直播推流端,我们最关注的就是是否断流,因为推流断流最终可能造成播放端的卡顿、报错等问题,对直播业务有很大的负面影响。其中与推流断流相关的指标有下面这些:
此外,对某些业务场景来说,直播延时也是很重要的一个指标,除了在 CDN 服务端和播放端做一些优化外,推流端也可以做一些推流延时优化。
造成直播推流卡顿的原因主要有设备、视频流、网络这三方面。
高清视频的编解码往往会给硬件带来更大的压力,由于编解码造成的卡顿尤为明显。对于推流端因为开播需要音视频编码、播放礼物动画、展示聊天消息等能力,这些组件叠加很容易使得 CPU、GPU 过载而导致手机发热和卡顿。
如果是这个原因,解决方法有以下几点:
在直播中,当音视频时间戳不同时,会影响画面渲染,导致画面解析时出现问题,造成一卡一卡的现象,音视频时间戳非单调递增会导致播放器在解析画面时出现错乱的情况,前后画面衔接会出现不连续甚至花屏的现象。
在实际场景中,有些推流中断的情况是由于设备音视频权限被抢占或打断造成的。比如,在推流时,弹出一个视频播放把音频权限模式给改掉了,导致推流没有音频采集权限而中断。这种情况在复杂的业务场景里是有可能出现的。
对应这种情况,可以这样解决:
根据人眼的视觉暂留原理,每秒的画面帧数必须达到一定的数值,人眼观看才是连续有效的,帧率(帧率即每秒的画面帧数)过低会导致用户视觉感受是卡顿的。
此外,如果视频的帧率设置过低,可能导致视频流的编码方式与服务器有不兼容的情况,这样在服务器转码直播流数据时可能出现了解析错误,也会导致直播放卡顿的问题。
直播从推流端,到服务端,再到播放端,各节点一般都会有音视频流数据的缓冲。在推流端发生断流,在各级缓冲没有消耗完音视频数据之前,如果能恢复数据生产,还是有希望避免播放端出现断播或卡顿的。这样一来,实现推流断流重连还是很有必要的。
推理断流重连的实现说起来其实比较简单,就是断开原有的推流会话,然后重启会话来建连推流。但这里有两点需要注意:
推流断流重连还可以做一个间隔重试策略,比如,间隔 1s 重试一次直至推流成功或外部停止推流,或者重试间隔时间线性递增直至推流成功或外部停止推流。
在实际应用场景中,很多主播都是使用手机进行推流,这时会有一个问题,如果主播受到其他打扰,比如来了电话或者查看微信,就会退出应用,这时候也会造成推流断流。对于这种情况,可以支持退后台继续推流,不过有几点需要注意:
推流端在遇到网络较差,音视频码率发送不出去的时候也会造成播放端的卡顿或者报错,因此推流端也需要做码率自适应来适配网络。
推流端的码率自适应主要是通过计算单位时间内编码码率与发送码率来判断网络的实时情况,然后可以根据多次判定的结果进行码率调整。
下面是 RTMP 推流码率自适应的一种示例策略:
编码码率
与发送码率
进行对比,统计连续 10 次的对比结果,定义:这 10 次统计中发送码率大于或等于编码码率的次数在 [N, 10]
区间,则判定网络优秀;在 [M, N)
区间,则判定网络一般;在 [0, M)
区间,则判定网络较差。上面讲的推流码率自适应主要是推流端在已经开播后动态适配网络的码率策略。而通常在开播前,我们也可以根据需要对开播端进行网络探测,从而配置不同的推流模板以适配网络。这里的推流模板包含了推流的码率、帧率、分辨率、GOP 长度、编码方式等参数。
推流多模板策略包括以下几个步骤:
通过 AI 算法加持,对于推流进行数据识别,将识别后的结果进行打分,得出需要准确的码率大小,这样可以更精准的控制码率,从而提升用户体验。
直播过程中整体延时通常指的是生产端到消费端的延时,也就是推流相机采集的每一帧到用户观看的每一帧时间差,通常我们可以用秒表来粗略估算,但代码中可以使用 SEI 配合 NTP 时间戳进行计算。
推流端延时则是从推流端到 CDN 服务端的延时。要对推流端的延时做优化主要是控制推流端的缓冲区策略,此外更重要的是选择合适的传输协议。
推流端的缓冲区比较典型的通常有两个:音视频数据采集模块和编码模块之间的缓冲区,编码模块和网络发送模块之间的缓冲区。
当这两个缓冲区中累积的数据比较多时,推流端的延时就会比较大,所以需要优化采集模块、编码模块、网络发送模块的性能和协调性,尽量降低缓冲区的数据累积。比如,当编码模块压力比较大时,可能导致采集模块和编码模块之间的缓冲区数据累积较多,这时候可以调整采集模块降低帧率来减轻编码模块的压力。
我们对当前主流直播技术做了分析,在低延时直播技术出现前主要有 HLS 和 RTMP/HTTP-FLV 两个协议。
主流直播技术延时
这两类协议都是基于 TCP,国内厂商基本上已经将 RTMP over TCP 的延时做到的极致,如果一个协议仍然基于 TCP 优化延时,效果上很难优于目前的 RTMP。
TCP 由于其自身的一些特性,并不适用于低延时直播场景,主要原因如下:
低延时直播技术
上图是基于 UDP 的两种方案对比,第一种是可靠 UDP 方向,比如 Quic;另一种是 RTC 方案,比如 WebRTC。
从五个维度对两种方案进行对比:
综上,Quic 方案的最大优点是复杂度低,不过这个方案要想达到更低的延时,也需要引入更多的复杂度。从方案的先进性上看,选择 WebRTC 技术的低延时方案,RTC 技术和直播技术的融合,是未来音视频传输技术的一个趋势。