RTMP直播推流

一 . 前言

之前在老东家时，因为自己平时课外喜欢研究音视频相关的东西，刚好老大那一阵又忙，于是当时一个直播推流没有画面的问题就交给我来定位，但是那时候是基于老大的ffmpeg推流相关的代码去做修改，没有从头到尾的去自己弄一遍

二. Demo中RTMP推流模块使用方法

~~1. RTMP推流地址在doublesky_rtmp_push.mm的p_start_rtmp方法中设置~~

为了跨平台，最新版本将rtmp推流模块改为c++，RTMP推流地址在doublesky_rtmp.cpp的doublesky_rtmp::p_start_rtmp()方法中可修改
作者为了偷懒，没有从自己要推流的h264文件中解析sps与pps，而是将sps与pps写死在了p_start_rtmp方法的sps_pps参数中，如果大家要推自己的h264文件，记得修改这里，不然推的流会花屏，这里自己都差点忘了，还纳闷怎么换个文件推出来的流都花了

三. 实现思路

还是基于ffmpeg去封装，大致的流程为

1. AVFormatContext及其中的AVIOContext、AVOutputFormat初始化，调用函数为avio_open与av_guess_format
2. 开启rtmp推流avformat_write_header
3. 写入音视频帧数据av_interleaved_write_frame

四. 协议学习及抓包分析

RTMP协议基本组成单元为消息(Message Body)，而消息在数据传输过程中会被分为RTMP Chunk Header + RTMP Chunk Data

如一个消息为300字节，RTMP Chunk Data默认大小一般为128字节，因此这个300字节的消息被拆分为

第一个包：RTMP Chunk Header + 128字节负载
第二个包：RTMP Chunk Header + 128字节负载
第三个包：RTMP Chunk Header + 44字节负载

RTMP Chunk Header又由Basic Header + Message Header + Extended TimeStamp组成
Basic Header：1-3字节这里本人抓包过程中只看到了1字节的情况因此只对1字节的格式做分析
0 1 2 3 4 5 6 7共8位：0-1位表示Format也就是Message Header的长度，第2-7位表示Chunk Stream ID

Format为00时Message Header长度为11字节：TimeStamp(3字节) + MessageLength(3字节) + MessageTypeID(1字节) + MessageStreamID(4字节)
Format为01时Message Header长度为7字节：TimeStamp(3字节) + MessageLength(3字节) + MessageTypeID(1字节)
Format为10时Message Header长度为3字节：TimeStamp(3字节)
Format为11时Message Header长度为0字节：无

这里我们找一张wireshark抓包的截图来对应协议进行分析:

图1.png

如图1可以看到第一个字节为03，高两位代表Basic Header的Format为00也就代表了Message Header长度为完整的11字节，Basic Header的Chunk Stream ID为3，Body Size也就是MessageLength，代表后面的RTMP Body负载数据为141字节，MessageTypeID为0x14，这里说一下Message Type字段，其为1-7时为协议控制消息，8、9分别表示RTMP Body是音视频数据、15-20为AMF编码格式的数据，AMF编码是Adobe搞出来的一种编码格式，稍后会给出相关资料链接，有兴趣的同学可以看看

五. 音视频帧拆分为多个RTMP包

前面说过RTMP Chunk Data在协议中的默认大小为128字节，但是大家都知道，即使是压缩过后的视频帧也是很大的，设想如果一个10万字节的视频帧，以128字节为单位来拆分，要拆成780多个包，要多出780多个RTMP Chunk Header，不仅造成了数据冗余，发送端与接收端的拆包组包也有性能消耗吧。因此我们能看到我们推流过程中，有Set Chunk Size这种协议包来设置Chunk Data的大小如图2，这里可以看到推流前会有个Type ID为01即设置RTMP Chunk Size大小的包，这里我们看到设置的值为4096

图2.png

接下来就是看看视频包的拆分了，一个大的视频帧被拆成多个chunk包，但是wireshark没有转换为RTMP包而是全部识别成了TCP包，这里一度让自己怀疑对RTMP的理解有错，抓包结果如图3

图3.png

这里可以看到图3最上面编号为3292(第一行) 选中的那行数据总长度为78字节的TCP负载为12字节，其实就是一个完整的RTMP Chunk Header，根据上面的协议分析可知RTMP Body Size为00 6b c6也就为27590个字节，代表这一帧视频的总长度为27590个字节，然后接下来编号为3293的(总长度为1514字节的数据，它的负载部分为1448字节 = 1514 - 14(链路层帧头) - 20(ip头) - 20(tcp头) - 12(tcp选项)，编号为3294的数据分析同3293，关键到了编号3295的数据，为什么它的数据负载只有1266字节了呢(负载数据为1200字节，1266减去各协议头数据后为1200)，这是因此推流前，协议部分将Chunk Size已经设置成了4096，因此一个RTMP包的负载最多只能搭载4096字节的数据，这里的各部分负载数据1448+1448+1200刚好等于4096，也就是到这里，一个RTMP包发送完成了，下一次的数据应该又要带上RTMP包头了，图4为接下来的一个包数据

图4.png

图4中我们取第一个字节c6为 Basic Header 可知fmt为11也就是没有Message Header，估计是因为这帧视频长度太大，要拆成多个4096的包，因此后面的包都可以用到第一个包的Message Header，减少冗余嘛。

那么后续就不再往下分析了，不得不说，Wireshark这里没有帮忙把TCP的包转换成RTMP包，浪费了好多的时间在这，不过仔细一想，也算是加深了对RTMP协议的理解吧。

六. 实现后的效果

图5.JPG

七. 遇到的问题

用手机往电脑推流，用vlc拉流时没有画面，用wireshark抓包显示电脑已经收到了视频帧，但sps跟pps数据如图6

图6.jpeg

如上图6显示，Video data 为 00 00 00 00 压根没有收到正确的sps跟pps，但是自己明明第一帧也就是调用ffmpeg的av_interleaved_write_frame就传入了sps跟pps了，在没有头绪的情况下，只能从ffmpeg源码入手了。

以下是定位该问题时分析的av_interleaved_write_frame主要的调用流程：

av_interleaved_write_frame调用write_packet
write_packet调用s->oformat->write_packet，这里的AVOutputFormat的write_packet是个函数指针，指向的是flv_write_packet函数
flv_write_packet函数中就是将数据写成flv格式，没有什么特别的操作，到这里s->oformat->write_packet调用完成，紧接着是write_packet调用的avio_flush函数
avio_flush内是调用了AVIOContext的write_packet函数，这个函数在这里也是个函数指针，指向的是rtmp_write函数
rtmp_write函数大致就是从之前flv_write_packet写好的flv数据中取数据然后构建RTMP包头之类的操作，然后在这里我发现，这个函数调用rtmp_send_packet发出去的数据，居然不是自己用av_interleaved_write_frame传入的数据，就像上图的@setDataFrame|Video Data，这个@setDataFrame里是视频的时长，宽高等信息，并不是自己传入的，因此这里猜测是在写FLV文件头时写进去的，于是去推流之前的avformat_write_header函数查看
一打开avformat_write_header就看到了s->oformat->write_header，这里的s->oformat->write_header指向的是flv_write_header
flv_write_header中就是写FLV文件的头信息之类的，这里惊讶的发现里面居然有写入音视频Tag Header与Tag Data的内容，并且写入Tag Data有ff_isom_write_avcc(pb, enc->extradata, enc->extradata_size)，熟悉ffmpeg的同学一定知道AVCodecContext的extradata往往放的就是sps跟pps信息，因此这里知道，原来在调用avformat_write_header之前，就要把sps跟pps传入，于是问题解决，电脑成功收到正确的sps跟pps

在sps与pps成功收到后，发现vlc还是无法播放，抓包发现如下图Control为0x27

图7.jpeg

这里的RTMP Body其实就是FLV的Video Tag Data部分，第一个字节的高四位代表的是帧类型，低四位代表的是视频编码方式，这里的0x27代表的是非关键帧帧的AVC格式，关键帧的AVC格式应该是0x17，但是断点显示自己是推了I帧数据的，于是从flv_write_packet看到了

flags |= pkt->flags & AV_PKT_FLAG_KEY ? FLV_FRAME_KEY : FLV_FRAME_INTER;

原来自己没有在AVPacket里设置是否是关键帧参数，在判断是I帧后设置AVPacket的flag为关键帧，问题解决

if (naltype == 0x05)
        pkt.flags = AV_PKT_FLAG_KEY;

FLV容器中sps及pps结构与264裸流中的数据格式不一样，如图8

图8.jpeg

图8左边为FLV容器中的sps及pps结构，右边为264裸流中的sps及pps结构

右边裸流中sps为 67 64 00 1E AC ... 16 2D
左边FLV中的sps 67 64 00 1E前还有一串多出来的数据为17 00 00 00 00 01 64 00 1E FF E1 00 18
第一个字节17，上面说了代表为AVC格式的关键帧，后面的数据不知从何而来，查阅相关资料知道当为AVC时，后续的数据格式为| AVCPacketType(8)| CompostionTime(24) | Data |
AVCPacketType为00时代表数据类型为AVCSequence Header
AVCPacketType为01时代表数据类型为AVC NALU
于是知道17后面的4个00分别为AVCPacketType和CompostionTime，也从ffmpeg中的flv_write_header找到
```
avio_w8(pb, 0); // AVC sequence header
avio_wb24(pb, 0); // composition time
ff_isom_write_avcc(pb, enc->extradata, enc->extradata_size);
```
从上面知道00代表后面的数据类型是AVCSequence Header，于是知道ff_isom_write_avcc函数是写入AVCSequence Header的过程，我们来看看内部到底干了什么

  avio_w8(pb, 1); /* version */
  avio_w8(pb, sps[1]); /* profile */
  avio_w8(pb, sps[2]); /* profile compat */
  avio_w8(pb, sps[3]); /* level */
  avio_w8(pb, 0xff); /* 6 bits reserved (111111) + 2 bits nal size length - 1 (11) */
  avio_w8(pb, 0xe1); /* 3 bits reserved (111) + 5 bits number of sps (00001) */
  avio_wb16(pb, sps_size);
  avio_write(pb, sps, sps_size);
  avio_w8(pb, 1); /* number of pps */
  avio_wb16(pb, pps_size);
  avio_write(pb, pps, pps_size);

从这里可以知道，多出来的01 64 00 1E FF E1 00 18数据分别代表了
01是AVC sequence header的版本
64 00 1E是sps中的数据
FF前6位为保留位，后两位为nal size length的长度减1，ffmpeg中是用2字节表示nal size的，因此为11（11-1=10，十进制为2）
E1前3位为保留位，后5位代表了sps的个数，这里为1。看到这里突然想起来，之前也碰到过包含多个sps跟pps的视频啊
00 18 为sps的长度

音频如果为AAC格式，需要推入的是去除ADTS头的原始流数据，且需要在音频AVCodecContext的extradata设置AAC sequence header

八. 优化

在安卓组老大的帮助下，申请了免费的腾讯云直播的RTMP测试账号，经测试发现时延基本在1.0-1.4秒之间，记得之前有同学接入腾讯的直播SDK，和我说延时能在400ms左右，因此希望有优化方案的同学能留言，共同进步

时延.PNG

九. 总结

RTMP使用了很多FLV现有的知识，因此个人建议学习RTMP前先去学习FLV容器格式，两者都可以参考雷神的博客，参考文章中已给出链接
本文没有对RTMP协议做很仔细的解读，只是简单的抓包分析并且针对自己完成RTMP推流过程遇到的问题进行定位分析
对于流媒体协议的学习，突然觉得看源码是一个很好方式，之前都是网上各种找资料，这次发现都不如分析源码来的实在
在阅读ffmpeg源码的过程中写了一些备注，文件在demo的“源码备注”文件夹下，只有flvenc.c和rtmpproto.c两个文件，为了方便自己及大家查看，因此在每个备注前都加了doublesky，搜索即可

十. 参考文章

雷霄骅：视音频编解码学习工程-FLV封装格式分析器
雷霄骅：RTMP规范简单分析
轻口味： FLV格式解析
devzhaoyou：直播推流实现RTMP协议的一些注意事项
FlyingPenguin：RTMP协议 03 RTMP设计思想
FlyingPenguin：AVC sequence header & AAC sequence header
RTMP AAC sequence header
流媒体-FLV格式详解及数据分析

十一. Demo地址

RTMP直播推流Demo