一、推流架构

推流SDK客户端的模块主要有三个，推流采集端、队列控制模块、推流端。其中每个模块的主要流程如下，本文的主要目的就是拆分推流流程，

1.1 采集端

视频采集：通过Camera采集视频。

音频采集：通过麦克风采集音频。

视频后处理：美颜、滤镜、贴纸、翻转等特效。

音频后处理：重采样、3A处理等。

视频编码：支持硬编码和软编码，同时支持H264和HEVC编码，特别要注意编码的特殊情况。

音频编码：AAC编码

采集端的很多功能都是平台相关的，相机采集、编码等Android和iOS上处理都不一样。尤其是Android平台，很多机型和芯片，当然会有一些特殊的情况需要兼容下，这个后面我们会详细描述的。

1.2 队列控制

队列控制模块是推流SDK非常重要的控制模块，推流SDK就是一个很简单的“生产者——消费者模型”，采集端是生产者，推流端是消费者，采集端采集的是本地数据，推流端和服务端交互，正常情况下都是推流端会出现延迟，像弱网情况下推流端消费肯定会很慢，但是采集端速度并不会慢下来，如果没有队列控制这个降压阀，那很多数据就会堆积在队列中，本地数据不断堆积，最终导致OOM。

队列控制应该如何控制？

视频的数据比音频大很多，所以队列控制主要是视频基准，音频跟着视频相应丢帧。

编码之后视频队列大小设置为60，在推流的过程中，发现视频的队列已满，需要丢弃队列最前面的一帧，然后再入队新的一帧，音频队列也要同步操作，对应时间点的音频数据也要丢掉。

1.3 推流端

推流采用的是RTMP协议，RTMP是Adobe公司开发的，算是事实上的工业标准，全称是Real Time Messaging Protocol，虽然实时性要比HLS好一点，但是也还有几秒左右的延迟。它的底层是基于TCP协议。

RTMP协议的建连流程如下：

RTMP建连需要商量两件事情：

版本号：客户端和服务器的版本号不一致，无法继续工作

时间戳，视频播放过程中，时间戳很重要，如果没有，后续的音视频同步无法继续开展。

首先，客户端发送 C0 表示自己的版本号，不必等对方的回复，然后发送 C1 表示自己的时间戳。服务器只有在收到 C0 的时候，才能返回 S0，表明自己的版本号，如果版本不匹配，可以断开连接。服务器发送完 S0 后，也不用等什么，就直接发送自己的时间戳 S1。客户端收到 S1 的时候，发一个知道了对方时间戳的 ACK C2。同理服务器收到 C1 的时候，发一个知道了对方时间戳的 ACK S2。

推流的过程，就是将 NALU 放在 Message 里面发送，这个也称为 RTMP Packet 包。Message 的格式就像这样。

一定要记住音频和视频的头部要单独发送，在发送视频头部的视频，需要将NALU起始标识符去掉，RTMP不需要它们。

二、技术要点

2.1 声音处理

在采集完声音之后，需要对音频进行3A处理，即声学回声消除（AEC）、背景噪声抑制（ANS）、自动增益控制（AGC），3A处理在声音后期处理中非常重要，在推流场景的声音处理中应用十分广泛。

AEC

回声消除（AEC）是指在二线传输的两个方向上同时间、同频谱地占用线路，在线路两个方向传输的信号完全混在一起，本端发信号的回波就成为了本端信号的干扰信号，利用自适滤波器可抵消回波以达到较好的接收信号质量，即为回声消除。

回声消除的原理就是利用接收到的音频与本地采集的音频做对比，添加反向的人造回声，将远端的声音消除。

ANS

背景噪声抑制（ANS）指的是将声音中的背景噪声识别并进行消除的处理。

背景噪声分平衡噪声和瞬时噪声，平稳噪声频谱稳定，瞬时噪声频谱能量方差小，利用噪声的特点，对音频数据添加反向波形处理即可消除。

目前，对于平稳的噪声已经有很多种简单方法能够成功抑制，但是生活中常见的一些瞬态噪声却依然缺乏好办法。

瞬态噪声的共同特点就是突发性极强，在时域上呈振荡衰弱的形式，持续时间在十几毫秒至上百毫秒不等；在频域上分布很宽，瞬态噪声的频谱基本上是和正常语音的频谱混叠在一起，很难进行抑制。

AGC

自动增益控制（AGC）主要用于调整音量幅值，提高语音通信系统在带噪声环境中的性能。

人们正常交谈的音量在 40-60dB 之间，低于 25dB 的声音听起来很吃力，而超过 100dB 的声音会让人感到不适，AGC 的作用就是将音量调整到人接受的范围。

音频响度及麦克风拾音控制是保证音视频沟通质量的重要技术手段，一般来说，音频标准、传输条件、人为失误等因素都可能导致音频信号之间出现声音突变或者响度不一致的情况，这时候就需要对音频信号放大或缩小以得到自然清晰的语音通信。

2.2 视频处理

相机采集的原始数据首先要进行帧处理，主播通常会应用一些特效，例如美颜、滤镜等，这些都会在视频帧后处理流程中开展，帧处理之后才会进行编码处理。

H264和H265编码还有点不同。

H264头部由SPS和PPS组成，SPS是序列参数集，包括一个图像序列的所有信息，如图像尺寸、视频格式等；PPS是图像参数集，包括一个图像的所有分片的相关信息，如图片类型、序列号。

H264的码流结构如下：

起始码 + SPS + 起始码 + PPS + 起始码 + SEI + 起始码 + I帧 + 起始码 + P帧 + ......

H265头部除了SPS和PPS之外，还有一个VPS，VPS是视频参数集。

H265码流结构如下：

起始码 + VPS + 起始码 + SPS + 起始码 + PPS + 起始码 + SEI + 起始码 + I帧 + 起始码 + P帧 + ......

其中H264和H265的码流类型有两种，一种是Annexb格式，另一种是MP4格式，使用最广泛的还是Annexb格式，本文主要以Annexb为例。

起始码只是起到分割的作用，并不是有效的视频数据，起始码也有两种：

4字节的00 00 00 01

3字节的00 00 01

但是图像编码中也有可能出现00 00 00 01和00 00 01，出现这种情况怎么办？

00 00 00 修改为 00 00 03 00

00 00 01 修改为 00 00 03 01

00 00 02 修改为 00 00 03 02

00 00 03 修改为 00 00 03 03

这样在编码的过程中就不会出现混淆了。

2.3 推流控制

上文也说了在采集端和推流段其实是通过一个队列控制的，采集端采集本地的视频和音频，然后编码好了放入队列中，推流段从队列中取出视频和音频然后根据特定的格式发送到服务端。相当于采集端是往水池中注水，推流段是放水。

采集端是很快的，推流段是受限于网络的，如果网络状态比较好的情况下，可以达到一个较好的平衡，但是一旦网络变差，队列就会出现堆积，我们不可能让队列无限堆积，需要设置一个队列阈值，当然队列已满，需要将队列中原有的数据抛弃，将新数据入队。这样就会出现丢帧，这时候推流段可以适当降低码率降低丢帧的概率。

2.4 支持FLV-HEVC

flv 是不支持H265的，需要手动修改FLV支持H265编码和解码的解析，当然也需要拉流段支持FLV-H265。具体的修改方式如下：

https://www.zhihu.com/question/41393752/answer/2775763571

三、三方库介绍

libfdk_aac：https://github.com/mstorsjo/fdk-aac

libx264：https://code.videolan.org/videolan/x264

libx265：https://github.com/videolan/x265

ffmpeg：https://github.com/FFmpeg/FFmpeg

librtmp：https://github.com/ossrs/librtmp

libsox：https://github.com/dmkrepo/libsox

sonic：https://github.com/waywardgeek/sonic

librosa：https://github.com/librosa/librosa