智能小车开发篇 - 低时延直播测试

本章节暂不考虑服务器性能指标, 目前仅对核心开发板资源占用、延时作为硬性考虑指标

前言

目前市面上常见的推拉流协议有：RTMP、HLS、HTTP-FLV、RTSP、WebRTC

上述的表格统计也仅为本人经验总结，欢迎大佬们指正与指点迷津。

上述延时均为大概范围，具体时间还得看不同的拉流手段、服务器环境、网路环境等因素。

题外话：

本人项目中也试过这样的推拉流方案：

• 推流端： RTSP
• 拉流端： JSMpeg
• 中转端： FFmpeg

整个流程：RTSP -> FFmpeg -> JAVA 服务 -> WebSocket -> 客户端

FFmpeg 拉取 RTSP 流，转码并转成 TCP 流至 JAVA 服务，JAVA 服务将接收到的流通过 WebSocket 推送至浏览器客户端；客户端接收后利用 JSMpeg 来播放整个流

当初这样处理主要是为了少搭建一个流媒体服务器，一般情况下我还是会去选择转 RTMP 后适用 flv.js 播放

相关资源

本次实验与测试对象如下

• 核心开发板：树莓派 4B Raspbarry 4B (4G 版本)
• 摄像头：树莓派官方 CSI 接口摄像头 1280x720
• 操作系统： ubuntu server 22.04LTS
• 相关软件： GStreamer

服务器相关资源

• 容器： Docker
• 流媒体服务器： SRS5.0
• 监控： Prometheus + Grafana

环境安装与部署

相关环境安装的教程建议参考官方文档（好的项目总是不断更新迭代的，经常翻阅文档将会是一个不错的习惯）

• SRS V5 官方文档
• GStreamer 官方文档
• Prometheus 官方文档
• Grafana 官方文档
• 在线时间

测试方案

目前由于学习成本与时间关系：仅从以下几种低成本的方式进行选择性测试，后续再发文其他方式的相关文章。

由于对延时的要求较高，因此目前暂不考虑 HLS 这等高延时方案，RTSP 由于是一个被动拉取的协议，因此也暂时不考虑 RTSP 的方案，WebRTC 方案技术成本较高，放后续进行测试与整理文档。

1. RTMP 推 - HTTP-FLV 拉
2. RTMP 推 - WebRTC 拉
3. 自定义格式 UDP 推流 - 自定义 UDP 拉流

基本资源占用情况

如上图所示，在未进行任何推流的情况下资源占用

• CPU：<= 1.5%
• 内存：<= 9.6%
• 网络：~= 0 kb/s

开发板中仅运行了：node_exporter 用于监控开发板资源

SRS 配置文件

由于是内网环境，目前下属文件配置环境中的 candidate 设置的 ip 为我局域网 ip

# main config for srs.
# @see full.conf for detail config.

listen              1935;
max_connections     1000;
#srs_log_tank        file;
#srs_log_file        ./objs/srs.log;
daemon              on;
http_api {
    enabled         on;
    listen          1985;
}

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
    #这里开启了跨域允许
    crossdomain on;
}

rtc_server {
    enabled on;
    listen 8000; # UDP port
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
    candidate 192.168.108.9;
}

vhost __defaultVhost__ {
    enabled on;
    tcp_nodelay on;
    min_latency on;

    hls {
        #暂不适用hls，不做开启
        enabled     off;
    }

    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }

    rtc {
        enabled     on;
        nack on;
        rtmp_to_rtc on;
        twcc on;
    }

    play{
        gop_cache off;
        queue_length 10;
        mw_latency 350;
    }

    publish{
        mr on;
        mr_latency 350;
    }
}

方案一：RTMP 推流 + RTMP 拉流

GStreamer 推流

推流前系统资源占用情况

此时设备刚开机，CPU 占用~=40%，查看了一下进程，发现是自动更新了某些东西

因此等待更新完成后再做下列操作

推流前系统资源占用情况

• CPU：~= 1%
• 内存：~= 10%
• 网络：~= 0 kb/s

开始推流

推流指令

gst-launch-1.0 -v v4l2src device=/dev/video0 ! 'video/x-h264, width=1280, height=720, framerate=30/1' ! h264parse ! flvmux ! rtmpsink location='${ip}'

推流了大概 5 分钟后延时图

推流资源占用情况

推流直播延时

• 实际时间： 10:14:15:069
• 显示时间： 10:14:13:600
• 相差延时： 1.3s 左右

本次推流大概使用的资源如下

• CPU：~= 1.5%
• 内存：~= 3M 左右
• 网络：60 kb/s ~ 7 Mb/s（具体看画面变化）

小总结

总的看来，使用 GStreamer 推流时带宽使用的较为大外，资源占用情况还是比较低的

我们其实可以看到 Network Traffic Basic 这一栏的波动，前一段是一个平缓的数值，突然间上涨到一个高度，然后再后续下降下来，最后呈现出一个很低的平缓直线

一开始我还在好奇，怎么流量上涨了这么多？我好像也没处理什么，还以为有什么其他程序增高了这个

但后想了以下，也没开其他应用程序；

然后怀疑是 H.264 传输压缩的问题， 测试了一下，当我将摄像头摆在一个画面丰富且动态变化的情况下，此时网络占用非常高；当我将摄像头盖起来（基本上处于一个黑色不变的情况下），此时网络占用几近于无（~=60 kb/s）

做了这个实验其实已经证实了我的想法， H.264 编码里面会使用 I帧 、 P帧 、 B帧 来组成画面与减少数据体积；^[1]

当我们画面几乎不变时 使用 P帧 和 B帧 编码是数据体积会很小，因此节省了很多的带宽资源。

FFmpeg 推流

推流前系统资源占用情况

推流前先用了 echo 3 > /proc/sys/vm/drop_caches 命令清空了 buff/cache

此时系统占用情况

• CPU：~= 1.3%
• 内存：~= 9.5%
• 网络：~= 0 kb/s

开始推流

推流指令

ffmpeg -f v4l2 -framerate 30 -video_size 1280x720 -i /dev/video0 \
       -c:v libx264 -preset veryfast -maxrate 1000k -bufsize 2000k -pix_fmt yuv420p \
       -c:a aac -b:a 128k -ar 44100 \
       -f flv ${ip}

推流了大概 5 分钟后延时图

系统资源占用情况

推流直播延时

• 实际时间： 10:30:24:387
• 显示时间： 10:30:21:533
• 相差延时： 3s 左右

本次推流大概使用的资源如下

• CPU：~= 58%
• 内存：~= 140M 左右
• 网络：600 kb/s

小总结

这里可以看到与 Gstreamer 推流相比，FFmpeg 推流下系统资源占用，延时等明显上升了一个台阶，但是带宽稳定在 600 kb/s

这里应该是对整个视频流进行了压缩处理导致需要较多的 CPU 资源与 内存占用（目前还没熟悉 FFmpeg 的相关参数，后续对其学习后整理相关的文档在过来重新分析对此进行分析）

章节总结

上面的总结测试并不完整与科学；明显能得出的是 FFmpeg 应该会去压缩画面从而减少带宽，但与之相对应的是系统资源的占用提升；目前由于我们第一要义是选择资源占用小的，延时低的，暂时先选择用 GStreamer 来进行推流；（欢迎各位大佬来帮忙解答这部分）

方案二：RTMP 推流 + HTTP-FLV 拉流

由于推流在方案一里已经做了对比效果，因此本方案只使用 GStreamer 进行推流；然后只针对于 HTTP-FLV 拉流的方式进行查看延时效果

拉流效果图

• 实际时间： 10:52:01:173
• 显示时间： 10:52:00:289
• 相差延时： 1s 左右

总的来说效果还是出乎我的意料的；看上去延时不是特别高，而且最主要还能直接通过浏览器进行播放；

方案二：RTMP 推流 + WebRTC 拉流

由于推流在方案一里已经做了对比效果，因此本方案只使用 GStreamer 进行推流；然后只针对于 WebRTC 拉流的方式进行查看延时效果

拉流效果图

• 实际时间： 10:55:03:620
• 显示时间： 10:55:03:452
• 相差延时： 200ms 左右

这个局域网拉流的实际效果已经非常不错了，基本上可以算是一个比较实时的反馈了。当然其实 WebRTC 还是一个比较庞大且复杂的东西，里面还需要我更深入的去研究才能做出更好的选择。

测试小结

最后的总结：

如果双端都能做到走 WebRTC 的方案，延时会更小更稳定一些吧；
如果是普通场景，我觉得我去先择 RTMP + HTTP-FLV 已经十分足够了，但是目前需要做远程控制，而且还需要做到外网控制的话， WebRTC 是一个不错的选择。
当然，本次实验的过程其实可以说是漏洞百出，例如：

1. 没有对 KMPlayer 播放器是否会做其他操作来增高延时（例如SRS里面说的不要用VLC观看，VLC延时会很大^[2]）
2. 也没使用自定义协议来进行传输（理论上应该延时也比较低，但是稳定性就需要看怎么去设计了）
3. 而且很多细节没有去深究为什么，怎么做到统一从而减少误差。
   参考了很多文章，也学到了不少新的知识点，也算是稍微拓宽了我的知识面吧。

相关用到的部署命令

# Docker run Prometheus
docker run -itd -p 9090:9090 --name promethues prom/prometheus

# Docker run Grafana
docker run -d --name grafana -p 3000:3000 grafana/grafana-enterprise

参考文章

https://stackoverflow.com/questions/70655928/live-streaming-from-raspberry-pi-to-nodejs-server-hosted-on-google-app-engine/70675353#70675353
https://opensource.com/article/19/1/gstreamer
https://github.com/ossrs/srs/issues/2304
http://www.riqicha.com/beijingshijian.html