特殊的需求引出的特殊处理
为什么会有这样的需求？
众所周知，在直播行业内用的最多的软件是六间房直播伴侣、OBS这类软件。这类软件的特点是可以在视频上任意叠加别的视频、图片、文字、桌面等等。但是在VR（虚拟现实）领域，这些特点都变成了缺点甚至是缺陷。因为在VR领域，讲究的是身临其境，任意叠加视频之外的东西会严重破坏3D感，在这里我就不对此做详细的理论说明了。
其次，目前的2D直播，手机端直播是不太在乎视频的质量的，PC端的直播顶多也是1080P。但是在VR领域，1080P也是完全不能满足需求的，所以目前所有的直播伴侣是不能用的。这也是要自己做的根本原因。
最后，目前主播用的电脑配置基本是i5左右，不会太好。VR领域的视频分辨率较大，在PC端做软编会严重的消耗资源，性能很差，甚至在什么事情都不干的情况下也无法保证30FPS。另外现在出的3D摄像头，例如Insta360，都是支持RTMP或者RTSP这种协议拉取已经编码好的流，那我们完全可以将这些流拿来直接用。至于为什么要结合本地视频是因为主播要用特殊的声卡，出来的声音会做特殊处理，这点是小小摄像头无法做到的。
版权声明：本文为博主原创文章，转载请注明出处：http://blog.jerkybible.com/2016/08/24/H264原始流与本地音频结合传输方式之流程说明/
访问原文「H264原始流与本地音频结合传输方式之流程说明」
思路
其实也不能叫什么思路。很明显就是直接把摄像头编码好的视频流和本地编码好的音频流合在一起推出去就行了。当然这也是我一开始的想法，在具体做的时候才发现还是有很多细节需要处理的。本次先把大致的流程梳理下好了。
流程
这里我先给出一份时序图吧，如下图。其实这个也不能叫时序图，因为图中有3个线程，这3个线程在大部分时间内是独立运行的。
下面详细对图里主要的3个线程作说明。
H264原始流读取线程
- 开始摄像头读取视频；
- 在获取一个I帧时读取H264的头部信息，也是SPS和PPS，然后存入音视频RTMP Packet队列；
- 读取一帧视频；
- 将一帧视频包装为RTMP Packet存入音视频RTMP Packet队列；
- 重复至3。
本地音频采集线程
- 初始化音频编码器；
- 将音频编码的头部信息打包成RTMP Packet存入音视频RTMP Packet队列；
- 读取一帧原始音频流；
- 对一帧原始音频流进行编码；
- 将一帧编码好的音频流包装为RTMP Packet存入音视频RTMP Packet队列；
- 重复至3。
RTMP发送线程
- 从音视频RTMP Packet队列获取一帧Packet；
- RTMP Packet队列返回一帧Packet
线程间的约束
在整个流程中的三个线程之间还是有依赖关系的。
- 音视频帧要保持同步；
- RTMP发送线程要首先建立链接；
- 没有音视频的头部信息是不能开始推流的；
- …
