Camera streaming made easy [NEW Release]

A persistent challenge in robotics is streaming camera feeds efficiently—on the robot you need raw or compressed images for processing, but on the remote operator station you require low-latency, low-bandwidth video. The common approach of using compressed ROS images (e.g., via usb_cam with jpeg) wastes bandwidth and CPU due to unnecessary decode/re-encode cycles. StefanFabian's new open-source package, ros_camera_server, directly tackles this. It accepts camera input (e.g., jpeg from USB) and produces multiple outputs—ROS2 topics, RTP, SRT, or WebRTC streams—from a single YAML configuration file. The server automatically builds GStreamer pipelines that use available hardware accelerations (e.g., VA-API, NVENC), scales and framerate-limits per output, and crucially avoids decoupling and re-encoding the original jpeg. Benchmarks comparing cam-both, cam-ros, and ros-stream outputs at 2085×1125 resolution show stream sizes of ~53 KB vs. 131 KB for the raw route, translating to 10-30× bandwidth savings for comparable quality.

Beyond bandwidth, ros_camera_server preserves the original camera capture timestamp as a custom RTP header extension, so when the stream is re-ingested into ROS on the operator station, the timestamp remains intact—critical for synchronization and logging. The package supports all major modern transport protocols and is designed for teams without dedicated video streaming expertise. Its automated pipeline optimization means users simply define cameras and desired outputs, not complex gstreamer command lines. With AGPLv3 licensing (custom terms available), it's poised to accelerate field-deployable teleoperation, especially in rescue robotics where bandwidth is a scarce resource. The combined effect of lower latency, reduced CPU load, and dramatically lower bitrate makes real-time remote control over cellular links or satellite connections far more practical.