ROS2多路相机视频流转换实战：用image2rtsp实现RTSP推流

在机器人项目里折腾过多路相机的人，几乎都撞过同一堵墙：话题里面的画面明明好好的，可真要把它拿去给上位机看、给浏览器看、给另一个工位上的显示器看，立马抓瞎。rqt_image_view开个三四路就卡出幻灯片效果，OpenCV窗口自己写个转发服务又得重新处理编解码、并发、跨平台，最后做出来的东西只在自己电脑上跑得动。我最近在一个巡检机器人项目里做多路相机采集，四路USB相机加一路网络相机，被“视频流怎么高效率地出ROS2”这个问题卡了好几天，最后用image2rtsp这个包把实时视频流转换的问题彻底理顺了。这篇就把我的完整踩坑过程和最终方案写出来，项目背景、安装、配置、参数、故障排查一条龙，给同样被这问题卡住的朋友做个参考。

1. 多路相机采集为什么要专门做视频流转换

1.1 从话题到RTSP：多路画面“出不去”的痛点

先说说我实际遇到的问题。机器人本体上跑着ROS2，装了好几组相机，图像话题在系统里刷得飞起，ros2 topic hz /camera_0/image_raw测出来稳定在30帧。但问题来了，调试的时候我在机器人旁边，可以通过rqt_image_view直接看，可一旦我需要站在两三米外的调试电脑上看画面，或者把画面投到车间大屏，甚至让另一个城市的同事远程瞄一眼，这条路就断了。

按常规思路，很多人会开一个OpenCV窗口然后通过网络把画面传出去。但真正多路相机采集场景下，这条路有四个很现实的问题：

• 第一，多路同时imshow的话，每路视频都要单独跑一个HTTP或者Socket服务，代码量不小，而且每一路都是独立进程，资源管理、断线重连、端口分配全得自己写。
• 第二，OpenCV默认走的是帧内编码的MJPEG或者原始帧，带宽占用高得离谱，四路1080p在Wi-Fi下基本别想流畅。
• 第三，跨平台观看麻烦。想在手机上瞄一眼？想在浏览器里直接开？想用VLC这种通用播放器收流？用OpenCV这套得自己再套一层WebRTC或者HLS，复杂度直接翻倍。
• 第四，机器人端往往资源紧张，CPU要跑感知算法、导航、底盘控制，如果视频转发还要占用几个核心，整个系统都会受影响。

我当时的判断是：这事不该自己造轮子，应该找一条“把ROS2图像话题转成标准视频流”的成熟路子。标准方式无非就是RTSP、RTMP、WebRTC、HLS这几种。RTMP在Web端还得转，HLS延迟太高，WebRTC要搭信令服务器，综合下来RTSP是最通用、最轻、延迟也可控的方案。所以目标就变成了：把一个或多个ROS2图像话题，实时编码成RTSP流，让任意支持RTSP的播放器直接拉流。

1.2 image2rtsp是什么：一条GStreamer管道解决的事

image2rtsp这个开源包，简单说就是专门干这件事的。它运行在ROS2节点里，订阅指定的sensor_msgs/Image话题，把图像数据通过GStreamer的appsrc送入管道，经过颜色空间转换、编码、封装，最后通过内置的RTSP Server对外推流。推出来的地址就是标准的rtsp://<设备IP>:<端口>/<路径>，VLC、PotPlayer、ffplay都能直接打开。

这个包解决了一个核心问题：你不需要关心编码器和RTSP Server的细节，只要给它一个话题名和一个输出路径，它就能跑起来。而且因为它底层是GStreamer，编码这块的可控性非常高：机器上有NVIDIA显卡就自动用nvv4l2h264enc硬件编码，没有就退回x264enc软件编码，编码器本身的参数也可以通过配置项透传下去。

当时我对比过几个方案：有基于RTP直接推流的、有基于ROS2 topic转发到另一台机器再显示的，还有用NVIDIA DeepStream整套框架的。最后选image2rtsp，理由有三个：第一，它够轻，不需要部署一整套DeepStream；第二，它上游就是GStreamer生态，扩展能力强；第三，它支持多话题在一个RTSP Server里以不同路径输出，也支持把多路画面拼成一个mosaic大图，刚好覆盖多路相机采集的两种观看需求。

1.3 什么时候该用、什么时候别硬上

不是所有项目都需要引入视频流转换。如果你的应用只在单机上调试，rqt_image_view就够；如果你需要超低延迟操作视觉反馈（比如机械臂实时视觉伺服），RTSP这种走编码器的方案就不合适，延迟再低也比不上共享内存直读话题。更好的选择是共享内存传输。

我个人的经验边界是这样的：

• 需要跨设备观看、需要多人同时看、需要把画面接入现有视频系统时，用image2rtsp这类方案是对的。
• 纯本机显示且延迟敏感，直接rqt_image_view或者共享内存方案。
• 需要做算法分析，那应该直接在原始图像话题上做，不要从RTSP流里拿数据去跑算法，绕一圈没有意义。

在巡检机器人这种场景里，“观看类应用”才是视频流转换的主战场，把图像话题转成RTSP流之后，地面站、Web端、录像系统都能直接消费，互不影响，这个价值非常大。

2. 环境准备：ROS2版本、GStreamer依赖与image2rtsp安装

2.1 ROS2版本选择和安装建议

image2rtsp对ROS2的版本要求不算苛刻，我在Humble和Jazzy上都跑通过。如果你的系统是Ubuntu 22.04，用ROS2 Humble最稳妥；如果是Ubuntu 24.04，那就用ROS2 Jazzy。这两个都是LTS版本，社区资料多，遇到问题也容易搜到答案。

安装ROS2本身这里不多说，网上一键脚本很多，新手直接用自动化脚本装也能省不少事。装完之后务必确认环境变量没问题，一个常见的坑是开了新终端后ros2命令找不到，大概率是没执行source /opt/ros/<distro>/setup.bash，或者没写进~/.bashrc。我建议装完第一时间跑一下ros2 doctor，把环境问题先暴露出来，别等后面推流出问题了再回头查环境。

另外强烈建议把colcon装好，因为image2rtsp是源码编译安装的，不是apt直接能装的包。

sudo apt install python3-colcon-common-extensions

2.2 安装GStreamer相关依赖

image2rtsp依赖GStreamer的开发库和常用插件。我第一次编译的时候就是少了几个插件包，编译能过，但跑起来之后GStreamer的pipeline起不来，报了一个很含糊的“could not link”错误，排查了半天才发现是插件缺失。所以这里先把依赖装全：

sudo apt install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev sudo apt install gstreamer1.0-plugins-base gstreamer1.0-plugins-good sudo apt install gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly sudo apt install gstreamer1.0-tools

如果你用的是NVIDIA Jetson或者有NVIDIA独立显卡，建议再确认一下GStreamer能否识别到硬件编码器。以Jetson为例，装完系统自带插件后，可以用下面这条命令验证：

gst-inspect-1.0 | grep nvv4l2h264enc

能输出nvv4l2h264enc，说明硬件编码器已经就绪。如果是台式机带N卡，通常还需要装对应的驱动和GStreamer插件版本，这部分不同显卡差异比较大，最好先跑一下这条命令确认。

2.3 拉取并编译image2rtsp

接下来把源码拉下来编译。个人建议不要在根用户下直接编译，用普通用户即可：

mkdir -p ~/ros2_ws/src cd ~/ros2_ws/src git clone https://github.com/radarhere/image2rtsp.git cd ~/ros2_ws rosdep install --from-paths src --ignore-src -r -y colcon build --symlink-install source install/setup.bash

colcon build的时候如果提示找不到某个package，先检查rosdep install是否执行成功。另外，因为image2rtsp依赖rclcpp和sensor_msgs，编译前确保这些基础依赖都在，通常装了完整版ROS2 Desktop的不会有问题，但如果装的是ROS2 Base版，需要单独补一下ros-<distro>-sensor-msgs和ros-<distro>-rclcpp。

编译完成后，验证一下节点是否注册成功：

ros2 pkg list | grep image2rtsp

能看到包名，说明编译安装成功，可以进入下一步了。

3. 多路相机推流实操：从单路跑通到八路同出

3.1 预备工作：确认图像话题与相机驱动

推流之前，先把相机话题搞清楚。我项目里用usb_cam驱动USB相机，用v4l2_camera或者自定义SDK驱动网络相机。不管哪种，先确认话题名、消息类型、帧率、分辨率：

ros2 topic list ros2 topic info /camera_0/image_raw --verbose ros2 topic hz /camera_0/image_raw

这一步有两个信息很关键：一是话题名，后面配置image2rtsp的ros_image_topic参数不能写错；二是话题的QoS策略，image2rtsp默认按sensor_dataQoS订阅，如果你相机的发布端改成了reliable，后面会出现订阅不到消息的怪问题，这个在第4部分详细展开。

我在项目里习惯把所有相机话题统一命名成/cameras/<id>/image_raw的格式，比如/cameras/cam0/image_raw、/cameras/cam1/image_raw。这样后面配置image2rtsp多路参数时会清爽很多，也能避免不同驱动默认话题名冲突的问题。

3.2 单路推流：最快验证完整体链路

先别急着上多路，拿一路相机把链路跑通再说。在ROS2环境里启动image2rtsp节点，最简单的命令行方式：

ros2 run image2rtsp image2rtsp --ros-args \ -p ros_image_topic:=/cameras/cam0/image_raw \ -p rtsp_server_path:=/0 \ -p port:=8554 \ -p fps:=15 \ -p bite_rate:=8000000 \ -p encode:=h264

注意参数名bite_rate，这个包的作者其实拼写习惯是“bite”，少一个t，指的就是码率。这里我设置成8000000，也就是8Mbps，对应1080p@15fps的H.264视频，画质和码率算是比较均衡的。

启动后如果一切正常，终端里会打印出RTSP Server监听信息。然后在同一台机器上开VLC，打开网络串流，输入：

rtsp://localhost:8554/0

能看到实时画面，说明链路已经通了。如果VLC和节点不在同一台机器，把localhost换成节点的IP地址。这一步验证完成后，再往多路扩展。

3.3 多路推流：端口规划与launch文件编排

多路相机采集场景下，每路相机都要单独推流。image2rtsp支持在一个节点内通过参数数组配置多路话题，也支持启动多个节点各推一路。我在实际项目里测试过两种方式，最后还是选了“每路一个节点 + 独立端口”的方案。

先看一下单节点多路怎么配。用YAML参数文件的话大概是这样：

image2rtsp: ros__parameters: ros_image_topic: ["/cameras/cam0/image_raw", "/cameras/cam1/image_raw", "/cameras/cam2/image_raw"] rtsp_server_path: ["/0", "/1", "/2"] port: 8554 fps: 15 bite_rate: 8000000 encode: h264

这种方式的优点是只需要一个节点、一个端口，部署简单。但有一个隐患：如果某一路相机掉线或者话题异常，整组流可能会受影响，而且故障排查时无法单独重启某一路。

所以我更推荐的方式是，每路相机单独启动一个image2rtsp节点，用不同的端口，通过一个Python launch文件统一管理。这样看起来端口多了几个，但故障隔离性非常好，某一路挂了不影响其他路，需要重启哪路就重启哪路。

下面是我项目里实际用的launch文件骨架：

from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): cameras = [ {"id": "cam0", "port": 8550}, {"id": "cam1", "port": 8551}, {"id": "cam2", "port": 8552}, {"id": "cam3", "port": 8553}, ] nodes = [] for cam in cameras: nodes.append( Node( package='image2rtsp', executable='image2rtsp', name=f'image2rtsp_{cam["id"]}', parameters=[{ 'ros_image_topic': f'/cameras/{cam["id"]}/image_raw', 'rtsp_server_path': f'/{cam["id"]}', 'port': cam["port"], 'fps': 15, 'bite_rate': 8000000, 'encode': 'h264', }], output='screen', respawn=True, respawn_delay=5.0, ) ) return LaunchDescription(nodes)

这里respawn参数值得说一下。机器人运行过程中相机偶尔断流其实很正常，respawn=True能让节点在崩溃后自动重启，5秒后重新拉流，比手动恢复省心太多。缺点是重启期间这一路画面会短暂中断，但大部分监控和调试场景都能接受。

启动之后，每路相机对应的地址就是：

• rtsp://<设备IP>:8550/cam0
• rtsp://<设备IP>:8551/cam1
• 以此类推

3.4 多路画面拼接（mosaic）模式

除了每路单独推，image2rtsp还支持把多路图像拼成一个画布，通过一个RTSP地址同时看到所有相机。这个功能在需要“全局总览”的巡检场景里非常实用，地面站操作员一个窗口就能扫完所有画面。

配置方式也很简单，在参数里开启mosaic，然后同样以数组形式传入多个话题：

image2rtsp: ros__parameters: ros_image_topic: ["/cameras/cam0/image_raw", "/cameras/cam1/image_raw", "/cameras/cam2/image_raw", "/cameras/cam3/image_raw"] rtsp_server_path: "/mosaic" port: 8554 fps: 15 bite_rate: 12000000 mosaics: true

开启mosaic后，节点会自动按输入话题数量排布画面布局，四路就拼成2x2，九路就拼成3x3，不用手动指定位置。这个功能实测很好用，但有两点要注意：

第一，各路输入分辨率最好一致。如果一路是1080p，一路是720p，拼出来的画布会对齐到同一尺寸，小分辨率的画面会被拉伸，观感上会有明显差异。

第二，叠加后的总像素不能超过编码器能力上限。以Jetson平台的H.264硬件编码器为例，单路编码的最大分辨率通常是4096x4096左右，超过这个上限pipeline会起不来。比如九路1080p拼成3x3，总画布是5760x3240，远超上限，这时候就得把单路分辨率降下来，或者减少拼接路数。用软件编码器理论上限更大，但CPU压力会非常高，不推荐。

我的建议是：如果现场需要总览，用mosaic模式，单路分辨率降到720p，总画布压缩到编码器能处理的范围内；如果需要单路详细画面，用多端口方案，保持1080p全分辨率。两者同时开也行，各占一份编码资源，但要提前评估设备CPU和GPU的余量。

4. 参数调优、编码选型与性能实测

4.1 分辨率、码率与帧率怎么组合最稳

多路相机采集场景下，资源是有限的，画面质量、延迟、CPU占用三者必须做取舍。我做了一套比较保守的组合，稳定跑了很长时间：

帧率这块很多人有个误区，觉得相机是30帧，推流也一定要30帧。实际在调试和监控场景，15帧足够肉眼观看，而且帧率降一半，带宽和编码压力差不多也降一半。如果画面里有快速运动的物体（比如AGV小车跑动），20帧以上会更顺滑，但15帧也能看出运动轨迹。

码率方面，我个人经验是1080p从8Mbps起步，往上加码率的画质收益会递减。码率设低了画面会出现块状模糊，尤其是在画面边缘和快速变化的区域，这时候不要一味降码率，可以考虑降分辨率而不是降质量。

4.2 CPU软编与GPU硬编的性能差异

image2rtsp的encode参数可以指定编码器。默认情况下，它会根据系统情况自动选择一个可用的H.264编码器，但如果你有明确偏好，可以手动指定。

软件编码用x264enc，硬件编码用nvv4l2h264enc（NVIDIA平台）或者v4l2h264enc。在Jetson系列设备上，硬件编码器的效果我非常推荐。实测下来，四路720p@15fps软编大约要占满4个CPU核心，而同一配置换成硬编，CPU占用几乎可以忽略不计，编码器由GPU硬件完成。

如果机器上有NVIDIA独显，驱动装好的前提下，GStreamer能直接调用CUDA加速的硬件编码模块。不过要注意，不是所有NVIDIA显卡都支持同一个nvv4l2h264enc插件，这个插件主要面向Jetson和部分专业卡，消费级显卡上可能需要用nvh264enc或者其他基于NVENC的插件。具体以你系统里gst-inspect-1.0 | grep 264输出的结果为准。

4.3 QoS策略：图像话题订阅不到的隐形原因

这是我在多路相机项目里踩过最隐蔽的一个坑，单独拎出来说。

ROS2的话题通信有QoS策略，发布端和订阅端的QoS如果不匹配，消息就会“静默丢弃”，节点不报错、话题存在，但就是收不到数据。相机驱动发布图像话题时，大多数用的都是sensor_dataQoS，也就是best_effort可靠性、短队列。而某些通用节点默认用reliable策略，这就导致两者不兼容。

image2rtsp默认按sensor_data策略订阅图像话题，所以正常情况下和相机驱动是匹配的。但如果你做了话题转发、桥接、或者用ros2 run的方式从其他网络域接收话题，QoS策略就可能被重置。判断方法很简单：

ros2 topic info /cameras/cam0/image_raw --verbose

输出里会显示Publisher和Subscriber各自声明的QoS配置。如果发现不一致，检查发布端驱动是不是被配置成了reliable，或者订阅端是不是有额外参数覆盖。在launch文件里，也可以通过qos_overrides参数强制设置：

Node( package='image2rtsp', executable='image2rtsp', parameters=[{ 'ros_image_topic': '/cameras/cam0/image_raw', 'rtsp_server_path': '/0', 'port': 8550, 'fps': 15, 'bite_rate': 8000000, 'qos_overrides': { '/cameras/cam0/image_raw': { 'reliability': 'best_effort', 'durability': 'volatile', } }, }], )

这段配置的作用是强制订阅端使用best_effort策略，和相机驱动保持一致。不过要注意，qos_overrides这种方式对不同类型的节点支持程度不一样，如果你的节点里用的是rclcpp::QoS而不是rclcpp::SensorDataQoS，可能需要改代码或者在参数里直接指定。这个属于比较深的问题，自己改源码时留意一下rclcpp的QoS构造函数签名就行。

5. 排查实录：多路推流最常见的几类故障

5.1 问题速查表

这几类问题是我在项目里真实遇到过的，整理成表格方便对照排查：

5.2 三个容易被忽略的“非软件”坑

除了软件配置，多路相机采集项目里还有几个硬件和系统层面的坑，单纯调参根本解决不了，这里专门说一下。

第一个是USB带宽问题。多路USB相机如果接在同一个USB控制器上，带宽是共享的。USB3.0理论带宽5Gbps，实际可用大概1.5-2Gbps，而四路1080p原始图像如果不经过压缩直接传输，每路大概要占200-400Mbps，几路加起来很容易把USB总线打满。表现就是相机帧率集体下降，图像一卡一卡。排查方法是插几路到不同的USB控制器上，或者把相机的输出分辨率降到720p，甚至降到10fps，减轻链路压力。

第二个是网卡中断绑定问题。如果推流节点和拉流客户端走的是同一个千兆网口，当带宽接近极限时，网络中断处理可能抢占CPU，影响编码线程。实测下来，多路1080p推流时建议用独立的千兆或者更高带宽的网卡，或者把管理网络和视频网络分开，哪怕只是逻辑上的VLAN隔离，也能让问题域更清晰。

第三个是供电问题。多路USB相机如果通过同一个HUB供电，电流不足会导致相机随机掉线。这个在工业现场尤其常见，因为现场用线长，压降大。我当时有几路相机不定期断流，排查了很久，最后发现是HUB供电不稳。解决办法是换带独立供电的工业级HUB，或者用POE供电的IP相机替代USB相机，供电和通信分开，稳定性会好很多。

写在最后

image2rtsp这个包帮我解决了一个很实际的问题：把ROS2里零散的图像话题，变成一组标准、稳定的RTSP视频流，让多路相机采集的画面能够方便地流转到各个终端。如果你也在做类似的项目，我个人的建议是：先单路跑通，再上多路；先软编调通，再切硬编；先本地验证，再跨网络部署。每一步都留足排查时间。视频流这块的问题，很多时候不是软件不行，而是链路里的某个小环节没对齐，比如QoS、带宽、供电。希望这篇实操记录能帮你少踩几个坑。