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

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

前言

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

协议名称	延时	传输协议	优势	劣势	适用场景
RTMP	1~5s	TCP	1. 协议成熟 2. 上手成本低	兼容性问题，大部分主流浏览器已不支持 Flash	PC 端延时不敏感直播
HLS	>10s	TCP	1. 点播场景非常适用 2. 平滑播放（像播放视频文件一样直播）	延迟非常高	点播场景
HTTP-FLV	1~5s	TCP	1. 延时较低且可浏览器播放	浏览器上适用需要用到特定本播放器（flv.js）	对延时有一定要求并期望在浏览器上播放的场景
RTSP	<1s	TCP/UDP	1. 延时极低	属于被动协议，需要客户端主动去拉流，不会向外推流（GB28181 可以实现向外推流）	各大摄像头厂商基本协议
WebRTC	<500ms	UDP	1.延时很低	上手难度大	低时延直播、会议室

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

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

🔶🔶 题外话：

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

推流端： RTSP

拉流端： JSMpeg

中转端： FFmpeg

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

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

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

环境安装与部署

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

测试方案

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

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

RTMP 推 - HTTP-FLV 拉
RTMP 推 - WebRTC 拉
自定义格式 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 分钟后延时图
推流效果图

推流资源占用情况

时机	CPU	内存	网络
推流前	1%	10%	0 kb/s
推流后	2.5%	10.3%	60 kb/s ~ 7 Mb/s

推流直播延时

实际时间： 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 分钟后延时图

系统资源占用情况

时机	CPU	内存	网络
推流前	1.3%	9.5%	0 kb/s
推流后	58.2%	14.3%	600 kb/s

推流直播延时

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

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

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

小总结

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

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

章节总结

推流方式	延时	CPU 占用	内存占用	带宽占用
GStreamer	1.3s	1.5%	~=3M	60 kb/s ~ 7 Mb/s（具体看画面变化）
FFmpeg	3s	58%	~=140M	600 kb/s

上面的总结测试并不完整与科学；明显能得出的是 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 还是一个比较庞大且复杂的东西，里面还需要我更深入的去研究才能做出更好的选择。

测试小结

推流方式	拉流方式	延时	备注
GStreamer - RTMP	KMPlayer - RTMP	1.3s	资推流资源占用较低，但拉流时间较高
FFmpeg - RTMP	KMPlayer - RTMP	3s	资源占用较高，
GStreamer - RTMP	HTTP-FLV	1s	效果还行，普通的低延时场景够用，如果做远程控制则还是不太足够
GStreamer - RTMP	WebRTC	200ms	效果不错，但挪到公网上还有待考究

最后的总结：

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

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

参考文章

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

posted @ 2024-06-14 11:23 Bt4Girls 阅读(1387) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

Loading

Ming's Blog

你所接触到的任何一个点，未来都会连成一条线

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

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

前言

相关资源

环境安装与部署

测试方案

基本资源占用情况

SRS 配置文件

方案一：RTMP 推流 + RTMP 拉流

GStreamer 推流

推流前系统资源占用情况

开始推流

小总结

FFmpeg 推流

推流前系统资源占用情况

开始推流

小总结

章节总结

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

方案二：RTMP 推流 + WebRTC 拉流

测试小结

相关用到的部署命令

参考文章

公告