RTMP低延迟推流

人总是需要压力才能进步, 最近有个项目, 需要我在RK3568上, 推流到公网, 最大程度的降低延迟.
废话不多说, 先直接看效果:

数据经过WiFi发送到Inenter的SRS服务器, 再通过网页拉流的.

因为是打金任务, 所以逼了自己一把, 把RTMP推流好好捋一遍.
先说说任务目标, 首先是MPP编码, 把mpp的github库下载下来, 研究mpi_enc_test这个例程, 基本就能实现, 从摄像头/dev/video0获取yuv数据, 编码为h264, 保存为文件.

最终值得注意是几点:

log看不到, mpp的log都保存到了/var/log/messages中.

输入参数, 因为人家的test demo, 包装得非常好, 编码的参数需要用参数输入, 而你必须设置一些编码参数, 我想到一个非常偷懒的做法:

伪装, 哈哈
这里面几个比较重要的参数,
-w -h分辨率之类,
-n 表示连续获取数据帧, 不显示数量
-t 就是h264比那吗
-g 是关键帧间隔
-rc 是码流控制, 1代表固定码流, 可根据需要修改, 在固定码流模式下, 可以设置码率

下图的bps就是码率, 直接写死, 要提高码率, 可以修改这里

在整个编码一开始, 会有一个生成SPS/PPS帧的过程, 原本的代码是直接写入到h264裸文件中. 我看了下面雷神的做法, 先缓存了下来, 跟第一个I帧一起发送.

接下来就是RTMP推流国过程了.

整个过程的前提是, 我之前在腾讯, 花5分钟(开通)+30分钟(折腾防火墙发现是梯子的问题), 搞了个SRS的服务器, 这个服务能接收N种推流方式:

这里面我最熟悉的就是RTMP了.
其实我最迷信的就是直接TCP转发…但是播放端没有研究, 而我之前试过, 先在板子这端用RTSP, 然后用ZLMedia的pusher, 或者叫Muxer, 把RTSP转到RTMP上去:

https://blog.csdn.net/zunly/article/details/138510170?spm=1001.2014.3001.5502

我偶然发现, 通过网页看到的流, 延迟非常小, 说明这个路应该是ok的, 但是经过RTSP, 再转推, 实在太2, 于是乎经过了几天的折腾, 下面是一点发现:

先说说目前的目标, 就是把mpp编码完的h264数据帧, 一帧一帧的通过RTMP推到Internet上的SRS上去.

首先我能想到的, 就是这么普及的应用, 应该是有库的吧, 搜了一圈, 发现有几个选择:
传说的librtmp, 如果直接在github搜索, librtmp, 过滤掉iOS, 安卓平台, 就会看到雷神(致敬RIP)之前的仓库:

https://github.com/leixiaohua1020/simplest_librtmp_example.git

他的做法是使用一个叫librtmp的库, 但是这个库没有源码, 只有编译好的lib文件跟dll文件, 这没法移植啊…

github上, SRS librtmp的仓库, 留了一个留言:

两个连接都已经失效.

我又研究了ZLMedia的RTMP部分, 发现一时之间很难看懂…

接下来是ffmpeg, ffmpeg最早进入视野是因为我一开始就想研究webRTC的推流, 据说那玩意儿贼快, 于是看到了一个国内的现状, 很多开发者, 开发出一个框架, 像变现, 方法成了, 什么知识星球, 什么CSDN收费下载…唉…当然作为一个自由主义知识分子, 信仰的是Milton Friedman, Ronald H. Coase, 我举双手赞同知识付费…
最后因为没有钱, 我放弃了WHIP就是webRTC推流的方法…默默留下了贫穷的眼泪.

偶然的机会, 我发现了另一个雷神的仓库:
https://github.com/leixiaohua1020/simplest_ffmpeg_streamer

差点跟前面那个搞混了, 这个仓库就是一个既可以推mp4也可以推flv, 也可以推裸流的宝藏代码, 也是雷神在8年前遗珠…
这个方案用的是ffmpeg的库, ffmpeg老早就集成了这些了…ffmpeg牛逼!!!
我先是在Unbantu上面, 把代码在x86/x64环境跑起来(居然真的能跑通, 推流也是能看到画面的).
然后通过WireShark抓包, 看看到底除了了裸流的数据, ffmpeg 还发了些啥:

在wireshark中, 我发现了几个问题, 一个是对应代码的, RTMP的初始化连接过程, 是非常必要的, 这个过程相当于告诉RTMP的服务器, 你要推流的视频的一些信息, 例如宽高, 帧率之类.

而这些信息, 其实是ffmpeg通过读取你要发送的h264/flv文件来获取的, 就是这个write_head的过程

实际的每一个数据帧的发送, 根据打印结果发现, 如下图, 如果我推流的是一个h264的文件, 每次发送的packet, 其实就是通过ffmpeg的 av_read_frame方法 读取文件中的NAL的分割字符(00 00 00 01或者00 00 01), 读取的一帧数据

read之后, 打印pkt, 长度跟数据内容, 用winhex打开比较

发现, 每个包, 就是一帧

那么思路就这样串起来了.

首先, 通过编码, 把摄像头数据, 保存为一个h264的文件, 这个文件当中, 最少有1个SPS, PPS, 跟一个关键帧, 作为一个初始化ffmepg AVPacket对象的工具, 同时也供RTMP的连接初始化使用, 接下来, 再使用实时编码出来的h264帧, 不断填充AVPacket对象的data 跟len这两个参数, 再通过ffmpeg的av_interleaved_write_frame 方法, 就可以把数据源源不断的推到RTMP上去了.

代码暂时不开源, 因为是个打金的项目, 如果上面的文章您还有任何疑问, 欢迎发私信讨论, 感谢大家.