直播核心技术

September 04, 2022

直播

直播作为一种视频信息的传播形态，已经有多年的历史，在近年来也发展的如火如荼，由早期的秀场直播到电商直播，全民参与的直播使其热度不减。加之又在一个直播公司里工作，探究下直播背后的技术。

直播核心模块

一个通用的直播模型一般包括三个模块：推流端（主播端）、服务器端、拉流端（播放端）。主要包含采集、预处理、编码、传输、解码和渲染等这几个环节。

推流端

推流：将采集到的音视频数据，通过流媒体传输协议发送到流媒体服务器。

主播端是产生视频流的源头，由一系列流程组成：

1. 音视频采集：

通过一定的设备（摄像头、麦克风）来采集数据：采集一般都是走系统API, Android和IOS都有自己的系统框架，音视频采集层面的优化处理包括：采集的帧率稳定性、采集图像监控反馈、重新设置相机例如曝光参数等

	视频采集框架	音频采集框架
Android	CAMERA1和 CAMERA2	OpenSL ES 或 AudioRecord
IOS	AVCaptureSession	Audio Unit

2. 预处理：

包括图像处理和音频处理，将采集的数据进行一系列的处理，比如水印、美颜和特效滤镜、降噪等处理；

（1）采集到的原始数据，音频二进制数据为pcm格式，视频二进制数据一般为YUV、RGBA格式（内存的数据）和纹理数据（显存的数据）

（2）图像处理：首先会将采集到的视频进行按需剪裁、翻转等，技术实现：openGL

然后进行美颜、特效滤镜等相关处理，技术接入包括商汤、字节、自研sdk，其中除美白、磨皮、滤镜外，其他美颜美妆、贴纸等均依赖人脸识别。同时根据业务场景不同，会有手势识别、性别识别、舞蹈识别、乐器识别等，均在该环节进行处理

再就是包括舞蹈分屏处理、镜像等一系列处理。

（3）音频处理：包括降噪、回音消除、音效、耳返等

降噪和音效均有对应算法，每个音效对应一个算法，把音频传进去，处理完输出来。耳返，低延时的播放，把录的声音给播出来

3. 音视频编码：

将处理后的音视频编码压缩成可观看可传输的视频流：编码方式包括硬编码和软编码，把视频原始数据YUV、RGBA编码成H264,H265, 把音频数据PCM转成AAC

	视频硬编码框架	编码方式	编码格式
Android	MediaCodec	硬编码、软编码	H264，H265
IOS	VideoToolBox	硬编码、软编码	H264，H265

	音频编码框架	编码方式	编码格式
Android	MediaCodec、 fdk-aac	硬编码、软编码	AAC，MP3
IOS	AudioToolBox、fdk-aac	硬编码、软编码	AAC，MP3

4. 分发推流

将压缩后的音视频数据按照传输协议封装，通过网络通道推送到流媒体服务器

（1）推流协议：RTMP、SRT

RTMP，流媒体传输协议，广泛用于直播领域，底层基于TCP，延时率大概在1～3s左右
SRT协议是一种能在复杂网络环境下实时、安全、可靠地传输数据流的网络传输技术，底层基于UDP协议，低延迟

推流基于RTMP协议进行封装+传输，RTMP over TCP, RTMP下层使用TCP传输；RTMP over SRT, RTMP下层使用SRT传输，抗丢包能力强，更适用于复杂的网络

（2）码率自适应：在弱网或网络不稳定时，根据预测的带宽，动态调整编码bitrate来适应实时的带宽，避免拥塞的发送，降低推流失败率及卡顿率，提高视频流畅度

拉流端

拉流：从流媒体服务器上，获取音视频数据

拉流协议

rtmp 在浏览器端依赖flash 2.httpflv 3.hls 4.p2p 5.httpsflv 6.httpshls 7.httpsFlvQuic

分离流数据

流数据 = 头格式数据 + 流的包数据，从流数据中，分离出视频包、音频包、自定义报文包

音视频解码、渲染：

将分离出来的数据包、音频包放入音频解码队列，视频包放入视频解码队列，音频、视频解码器去队列取未解码的数据进行解码—输出yuv，放到音画同步模块，渲染

服务器端

直播服务器端提供的最核心功能是收集主播端的视频推流，并将其推送给所有观众端。常见服务器有腾讯云、华为云、阿里云

除此之外，还有很多运营级别的诉求，比如实时转码、鉴权认证、视频连线和自动鉴黄，多屏合一，以及云端录制存储等功能。

业务场景

虚拟开播、游戏开播、连麦等等

连麦

可以理解为三个角色，直播的主播A, 请求连麦的主播B, 然后就是第三方观众。大致流程是，主播A端推一路自己的画面，拉一路主播B的画面；主播B端推一路自己的画面，拉一路主播A的画面；第三方观众拉一路连麦主播AB混流后的画面

混流

就是把多路音视频流混合成单流。准确滴说，混流应该叫做混音频流和混视频流。

对于第三方观众，如果想同时看到两个连麦主播的画面，最简单的办法就是拉两路流。但是缺点是两条流的延时不好控制，以及多拉一条流多产生一路流的费用，所以需要把这两条流混成一路流分发。

目前手机端都是在服务端混流，pc端在客户端混流

连麦主播之间，如何实现低时延交流？如何避免重复采集音频数据导致的回音？

如何实现低时延交流

区别于普通的直播流走的是CDN，延迟大概2～3秒左右；低时延流采用超级节点和内网专线构建的超级链路将连麦主播地域的传输延迟降至最低，延迟可以控制在500ms以内。生成低时延流地址的方法和生产推流地址类似，通过rtmp拉流地址后面加上推流防盗链key计算的防盗链

回音消除

对于连麦的主播，由于需要一边采集本地音视频数据推流出去，一边播放对方的音视频，这样就可能重复采集音频数据，导致回音现象。所以连麦场景需要打开回音消除

整体流程如下：

主播A正常推流直播，直播码为streamA
主播B正常推流直播，直播码为streamB
主播B向主播A请求连麦，并带上自己的推流地址B
主播A如果同意连麦，向主播b回应，与此同时，主播A拉去streamB的流进行播放
主播B拉取streamA的流进行播放
主播A或主播B通知服务器混流，CDN的观众拉取混流后的画面

主播A此时需要播放streamB的低时延地址，注意这里不能播放普通的CDN的观看地址。CDN地址只能给普通观众观看，不能用于主播之间的连麦。同样，主播B播放的也是streamA的低时延地址。

低时延链路使用的是服务器核心机房的专线超级链路，如果用于普通观众观看，虽然延迟低，但是费用成本太高。所以普通观众看还是用普通的CDN地址。