部标jt1078实时音视频，视频推流部分

经过两个月的研究，参考了大量资料，终于小有成果，我使用的方案是收到数据包做相应的处理，然后rtmp推流到流媒体服务器，在这里希望给今后从事相关工作的同学一点帮助，少走一点弯路。

既然你来到我的帖子，说明你已经知道jt1078协议是什么了，在此我不再多说。对了，说一点协议里有问题的地方，实时音视频协议见表19，在这个表里，负载类型这里有误，应该是表12。simId 使用的BCD8421编码，主要是这两个地方，如果不清楚，是很难往下进行的，因为解码的时候要用到编码类型。看下图：

 

  大家也都知道，这个协议是在rtp协议基础上扩展了消息ID，simid号，音视频通道号等字段，所以它不能算是标准的rtp包，当然不能用通用的rtp转发服务来操作它啦。所以我们第一步要做的就是，写服务端，这里服务端可以是tcp也可以是udp，使用什么协议，依据的是jt808协议下发的指令（这里不去讲808），我推荐大家用tcp，因为稳定。做好服务端，我们要做的就是处理粘包，粘包处理大家应该都接触过。这里说一下思路：

1.首先定义接收缓冲区大小，因为数据包最大是980，所以我定义了10个大小的缓冲，如果有粘包，最多会接收9800.

2.把收到的数据包开始解析，解析出相应字段，首先应该先判断头信息，这个大家都清楚。解出数据体之前的长度+数据体的长度，把剩余的送到下次处理。

3.需要注意的地方，因为我们的数据包不总是980，也可能是视频帧的最后一个包，比方说最后一个包是300大小，而粘包的原因正好把这300字节分割成了150和150，那我们解出的数据体长度字段是270，判断150-30 < 270,那这个数据包就要插入到下一次接收缓冲区的头部。

好了，大致粘包就是这么个思路，我不太会组织语言，我描述不清使大家没有理解可以下方评论问我哈。

 

解包处理完，为了效率，使用两个线程，一个负责收包解包送入队列，一个负责取队列数据rtmp推流。rtmp推流使用的是ffmpeg，因为解包的数据是在队列里，也就是内存，所以用到的是ffmpeg从内存里取数据。网上大部分例子都是使用ffmpeg打开文件操作。在研究ffmpeg时候，参考了大量雷神的工程demo，在此像雷神致敬，虽然雷神已经走了三年了，但他留下的财富依旧在指导着音视频工作者，给这些工作入门降低了门槛。也要感谢其他csdn的大咖，把自己的研究成果分享出来。（说个题外话，QQ群真的是一点帮助都没有，平常吹牛逼，几百上千条消息，到真正有问题提问的时候，根本没人出来解答）以下附上参考链接：

windows下的个版本ffmpeg库

雷神的文章：

最简单的基于FFmpeg的内存读写的例子：内存转码器

最简单的基于FFmpeg的推流器（以推送RTMP为例）

ffmpeg新旧接口对照

如果写的bs架构，那这个东西你肯定需要，在线测试flash播放rtmp流是否正常

flash测试rtmp流是否正常

这个也是前人踩过的坑

关于ffmpeg推流器中踩的几个坑

 

再说几个我踩过的坑，

回调函数传进去的buffsize大小，因为我之前处理的时候要组帧，也就是把分包的帧组成一个完整的数据包，所以buffsize要大于32778，为什么是32778呢，因为如果你在调用avformat_open_input的时候传入的解包获取的编码类型，那这个buffsize就是固定大小32778，最后导致内存溢出。

所以有两个办法，第一就是不组帧；第二就是不传入编码类型（只针对于视频），让ffmpeg自己判断编码类型（一般都是H264,我没有遇到过其他的），缺点就是时间可能会有点长。在调用avformat_find_stream_info的时候，如果不传入编码类型，让ffmpeg自己判断，这个函数调用会很长时间不返回，导致你推流的延时增大，这里设置这两个参数可以减少avformat_find_stream_info的返回时间。

另一个坑就是，调用avformat_open_input函数，这个函数会去回调函数里取数据，一定要保证它取的数据是关键帧数据，什么是关键帧呢，就是I帧，切记一定要是I帧，不能是B帧或者P帧，否则返回-22出错。

因为时间有点长，所以有的坑可能忘记了，想起来再补充哈~~

最后记住，申请的内存一定要记得释放，调用相应的ffmpeg接口释放不同的结构体。否则会导致内存泄露。

根据雷神的两个例子完全可以做出视频推流器，下一篇更新音视频推流器，音视频同步，相对于音频的坑，视频的坑跟本就不算什么。本人表达能力不好，写的很乱，望大伙勿喷。