当前位置: 首页>编程语言>正文

RTMP直播推流

一 . 前言

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

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

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

  1. 为了跨平台,最新版本将rtmp推流模块改为c++,RTMP推流地址在doublesky_rtmp.cpp的doublesky_rtmp::p_start_rtmp()方法中可修改
  2. 作者为了偷懒,没有从自己要推流的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抓包的截图来对应协议进行分析:


RTMP直播推流,第1张
图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


RTMP直播推流,第2张
图2.png

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


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为接下来的一个包数据


RTMP直播推流,第4张
图4.png

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

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

六. 实现后的效果

RTMP直播推流,第5张
图5.JPG

七. 遇到的问题

  1. 用手机往电脑推流,用vlc拉流时没有画面,用wireshark抓包显示电脑已经收到了视频帧,但sps跟pps数据如图6
RTMP直播推流,第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
  1. 在sps与pps成功收到后,发现vlc还是无法播放,抓包发现如下图Control为0x27


    RTMP直播推流,第7张
    图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;
  1. FLV容器中sps及pps结构与264裸流中的数据格式不一样,如图8
RTMP直播推流,第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的长度

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

八. 优化

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


RTMP直播推流,第9张
时延.PNG

九. 总结

  1. RTMP使用了很多FLV现有的知识,因此个人建议学习RTMP前先去学习FLV容器格式,两者都可以参考雷神的博客,参考文章中已给出链接
  2. 本文没有对RTMP协议做很仔细的解读,只是简单的抓包分析并且针对自己完成RTMP推流过程遇到的问题进行定位分析
  3. 对于流媒体协议的学习,突然觉得看源码是一个很好方式,之前都是网上各种找资料,这次发现都不如分析源码来的实在
  4. 在阅读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


https://www.xamrdz.com/lan/5wk2016621.html

相关文章: