简介在安防监控与视频直播场景中设备输出RTSP流而平台多接收RTMP流两者协议差异显著RTSP基于UDP、控制与数据分离适合局域网实时监控RTMP基于TCP、封装FLV具备出色的公网分发与低延迟能力。理解协议转换原理是解决公网播放卡顿、花屏问题的关键。FFmpeg作为最成熟的推流工具通过一条命令即可完成RTSP拉流、转封装并推送到RTMP服务器配合SRS等开源服务端可构建完整链路。本文从工具选型、参数调优到断流重连、H.265处理等工程实践系统梳理了监控对接与直播推流中常见的踩坑点为开发者和集成商提供一套可落地的技术方案。 做安防监控对接和直播推流这几年最常被问到的问题之一就是摄像头里的RTSP流怎么推到直播平台上去或者说怎么让手机端、web端也能流畅播放监控画面我早期做这类项目的时候也在这个环节上踩了不少坑。市面上的方案绕来绕去其实核心就一句话用适当的推流工具把RTSP拉到的流重新封装成RTMP格式再推到目标服务器。今天这篇就围绕“rtsp转rtmp推流工具”这个主题把我实际用过的方案、踩过的坑、调参的经验一次讲清楚。这篇内容不是单纯给你贴一条命令就完事而是从协议原理、工具选型、具体实操到问题排查全链路拆开揉碎。不管你是刚接触流媒体的小白还是在做安防对接的嵌入式开发或者正被海康、大华取流地址折磨的集成商都值得读下去。尤其是那些被“rtsp流画框推送为新rtsp流为什么总是卡顿”折磨过的朋友看完你应该能找到排查的方向。1. 为什么需要RTSP转RTMP协议差异与选型思路1.1 RTSP和RTMP的本质区别先把这两个协议说透。RTSPReal Time Streaming Protocol本身不是一个传输媒体数据的协议它更像是流媒体世界的“遥控器”负责发起会话、控制播放、暂停、快进这些动作。真正的音视频数据走的是RTP协议而且RTSP拉流默认走UDP居多控制通道和数据通道是分开的。所以你在VLC里填一个rtsp://地址它能播放但体验和延迟完全取决于播放器对RTP的处理能力。RTMPReal Time Messaging Protocol是Adobe当年为了Flash播放器设计的协议基于TCP数据封装成FLV格式控制消息和数据消息混在同一个TCP连接里。它的优势在于穿透性好、防火墙友好、延迟能控制在1-3秒而且绝大多数云直播平台、CDN、流媒体服务器都对RTMP推流有成熟的接入方案。这就是为什么现实世界里“拉流用RTSP推流用RTMP”是标配。摄像头这种设备天生就出RTSP流而直播平台、微信小程序、网页播放器最兼容的入流协议就是RTMP。两者之间必须有人做“翻译”这个翻译的过程就是转封装或者叫转码。1.2 为什么不能直接用RTSP流做公网分发我见过不少刚接触这个领域的同学问既然VLC能放RTSP为什么不能直接把RTSP地址丢给直播平台答案很简单直播平台几乎不接收RTSP推流。原因有两层。第一RTSP使用UDP传输RTP数据公网环境下UDP丢包严重视频会出现花屏、马赛克体验没法看。第二RTSP没有大规模CDN分发的生态它更适合局域网内的实时监控。你想想一个监控摄像头一天24小时实时上传画面到公网服务器如果用UDP中间任何链路抖动都会导致画面破损而用户端根本没法重传数据。所以RTSP转RTMP的本质第一是“控制协议”到“分发协议”的转换第二是“UDP传输”到“TCP传输”的转换第三是“RTP封装”到“FLV封装”的转换。搞懂这三点你就明白为什么转完之后画面在网页端能流畅播放了。1.3 能用到的工具方案对比工具层面市面上主流的方案有这么几种我简单做个对比。方案原理适合场景上手难度稳定性FFmpeg命令行通用转封装/转码老兵单路或少量路数、Linux服务器部署中等高GStreamer管道流媒体瑞士军刀需要定制管道、叠加画框滤镜较高高Node-Media-ServerNode.js流媒体服务器内置拉流代理快速搭建带转发的服务端低中OBS推流图形化采集推流电脑本地抓屏/摄像头推送极低中商业转流网关硬件或软件一体机多路大规模、要求品牌支持低高你如果是做项目落地的我的建议是优先学FFmpeg。原因很朴素——它是命令行工具可以脚本化、可以定时重连、可以远程调试几乎所有的商业方案底层都是FFmpeg。学会FFmpeg之后不管上层套什么壳你都能看透本质。2. FFmpeg推流工具实战一条命令打通拉流与推流2.1 环境准备与最基础的推流命令第一步肯定是要有FFmpeg。Windows直接去官网下载编译好的exeLinux用apt或者yum装macOS用brew install ffmpeg。装完之后终端输入ffmpeg -version看到输出就行。基础的转推命令长这样ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/stream1这条命令做的事情是通过TCP方式从RTSP地址拉流视频流直接复制不重新编码音频转成AAC格式封装成FLV输出推送到RTMP服务器。实测下来从摄像头到服务器延迟能控制在1秒左右画质无损。注意我用了-rtsp_transport tcp。这点极其关键。默认情况下FFmpeg拉RTSP流走UDP局域网偶尔没事但在公网环境下UDP丢包会导致花屏、卡顿。TCP方式虽然延迟略微高一点点但稳定性和画面完整性要好得多。做公网转推我建议无脑加这个参数。2.2 关键参数逐个拆解很多人贴了命令就跑出了问题不知道怎么改。其实FFmpeg的转推命令里每个参数都对应一个可能的坑我逐个说一下。-i后面的rtsp://地址是输入源。海康摄像头的取流地址规律是rtsp://用户名:密码IP:554/Streaming/Channels/101其中101表示主码流第一路102表示子码流第一路。大华的地址是rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0subtype0是主码流subtype1是子码流。这里有个经验如果是往公网推流条件允许尽量用子码流。主码流一般4Mbps起步子码流通常512Kbps到1Mbps带宽成本差了好几倍。如果只是用来做手机端远程预览子码流的清晰度完全够用。-c:v copy是视频直接复制。前提是你的RTSP源是H.264编码。现在市面上90%的摄像头主码流都是H.264或者H.265如果是H.265RTMP那边会有兼容问题这个我后面单独讲。-c:a aac是把音频转成AAC因为很多摄像头的音频编码是G.711或者AAC而RTMP协议对音频格式支持最稳的就是AAC统一转一下准没错。-f flv是强制输出封装格式为FLV。RTMP协议规定了推流数据必须是FLV封装如果没有这个参数FFmpeg会根据输出地址的后缀猜格式有时候能猜对有时候会报错。我习惯直接写死。2.3 延迟优化与画质平衡如果你对延迟有要求比如要对着监控画面做远程操作那1秒延迟还嫌高还有一套延迟优化参数ffmpeg -rtsp_transport tcp -fflags nobuffer -flags low_delay \ -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv -flvflags no_dts_files rtmp://your-server-ip/live/stream1-fflags nobuffer意思是尽量减少缓冲-flags low_delay同样是降低延迟这组参数组合起来能让端到端延迟压到300-500毫秒。但代价是网络抖动时更容易出现卡顿。建议是局域网内调试可以开低延迟模式公网环境中还是保留默认缓冲更稳。画质方面如果摄像头输出的是1080p主码流你要转推到一个限制带宽的平台那就必须转码而不是copy。转码命令长这样ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v libx264 -preset veryfast -crf 23 -b:v 2000k -maxrate 2200k -bufsize 4000k \ -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/stream1libx264是CPU软件编码-preset veryfast在编码速度和压缩率之间取一个平衡点-crf 23是质量常数数值越小画质越好文件越大。-b:v 2000k锁定了基准码率-maxrate和-bufsize是控制峰值码率的防止画面复杂时瞬间码率暴涨导致卡顿。这里有个点要提醒转码非常吃CPU。实测1080p 30帧的流一台4核的云服务器用veryfast转码CPU大概会跑到60%-80%。如果路数多最好用GPU硬编FFmpeg配合NVIDIA显卡可以加-c:v h264_nvenc直接硬编CPU占用可以降到10%以内。3. 进阶玩法多路流转发、断流重连与复杂场景3.1 多路RTSP并发转推的架构设计做监控项目往往不止一路摄像头。一个厂区动辄几十路你不可能为每一路单独开一个FFmpeg进程然后手动管理。实际项目里一般有两种做法一种是用FFmpeg的filter_complex把所有流合入同一个进程但操作起来复杂且不够灵活另一种是每路一个进程但通过supervisor或者systemd管理统一启停、自动拉起。我后来用的比较多的是后者。每个摄像头写一个shell脚本循环执行FFmpeg推流然后交给systemd常驻。脚本长这样#!/bin/bash while true; do ffmpeg -rtsp_transport tcp \ -stimeout 10000000 \ -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/camera01 echo FFmpeg exited, restarting in 3 seconds... sleep 3 done-stimeout 10000000是设置RTSP socket超时时间为10秒如果10秒内收不到数据就自动断开让脚本进入重连逻辑。这个参数很关键没有它FFmpeg可能会因为TCP半开连接永远挂在那里不退出外层的循环就永远走不下去。用systemd或者直接写个cron监控脚本保证这个shell脚本本身不挂。这样每路摄像头都是独立进程一个挂了不会影响其他路重启也方便配合监控报警足够了。3.2 断流自动重连与稳定性保障RTSP摄像头有一个老毛病网络稍微波一下就断流。有的是因为摄像头本身的TCP连接超时设置太短有的是因为路由器NAT会话老化总之FFmpeg推着推着就断了。断流不可怕可怕的是断流之后不会自动恢复。上面那个while循环就解决了自动重连的问题。但重连有个细节要注意FFmpeg退出后立刻重连有时候会因为摄像头侧还没释放旧连接而失败。所以sleep 3是有讲究的给摄像头留出处理旧连接的时间。还有一个更稳的做法是加退避策略比如连续失败5次以后sleep时间从3秒递增到10秒防止摄像头被频繁连接打挂。脚本可以这样写#!/bin/bash fail_count0 while true; do ffmpeg -rtsp_transport tcp -stimeout 10000000 \ -i rtsp://... -c:v copy -c:a aac \ -f flv rtmp://... code$? if [ $code -ne 0 ]; then fail_count$((fail_count1)) else fail_count0 fi if [ $fail_count -gt 5 ]; then sleep 10 else sleep 3 fi done这里用FFmpeg的退出码做判断正常退出码是0异常退出码非0。实测下来这套逻辑能扛住摄像头断电、网线松动、服务器重启等各种场景。3.3 GStreamer备用方案真正意义上的“流媒体瑞士军刀”FFmpeg虽然强但有的时候你要对画面做处理比如叠加文字、画框、加马赛克再用FFmpeg的filter语法处理会比较绕。这时候GStreamer就更有优势。比如“rtsp流画框推送为新rtsp流”这种需求GStreamer的插件体系处理起来非常明确。一条简单的GStreamer RTSP转RTMP管道长这样gst-launch-1.0 rtspsrc locationrtsp://admin:password192.168.1.64:554/Streaming/Channels/101 latency0 ! \ rtph264depay ! h264parse ! flvmux streamabletrue ! \ rtmpsink locationrtmp://your-server-ip/live/stream1如果要去掉音频就只保留视频分支如果要叠加画框可以在h264parse后面接videoconvert ! cairooverlay text区域A等等。GStreamer的优点是可组合性极强每个插件就是一个积木缺点是学习曲线陡峭、文档零散。一般项目用FFmpeg就够了只有在定制化处理需求很高的时候才建议上GStreamer。3.4 H.265编码流的特殊处理现在越来越多的新款摄像头默认输出H.265编码。H.265的优点是同画质下码率只有H.264的一半对存储和带宽都非常友好。但RTMP协议从诞生那天起就没考虑过H.265标准RTMP服务器收到H.265的FLV流基本是黑屏。解决方案有两条路。第一条是把H.265转码成H.264再推流命令很简答ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v libx264 -preset veryfast -crf 23 \ -c:a aac -f flv rtmp://...代价是CPU开销上去了。第二条是用支持H.265扩展的RTMP服务器比如SRS 4.0以上版本原生支持Enhanced-RTMP允许在FLV里封装HEVC数据。这种情况下视频流可以继续copyCPU零开销ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v copy -c:a copy -f flv rtmp://...但注意接收端播放器也得支持Enhanced-RTMP才能解码。实测下来网页端用VLC、ffplay移动端用ijkplayer开启对应选项后能正常播放。如果你无法控制接收端环境稳妥起见还是转码成H.264。4. 搭建RTMP推流服务器与测试资源4.1 用SRS一条命令搭建RTMP服务器说完了推流端再说接收端。没有RTMP服务器你推出去的数据没人接等于白干。实际工作中SRSSimple Realtime Server是我用过最顺手的开源流媒体服务器一个二进制文件跑起来就是一个完整的RTMP服务器。用Docker一条命令起服务docker run -d --name srs \ -p 1935:1935 \ -p 8080:8080 \ -p 8443:8443 \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4 \ ./objs/srs -c conf/rtmp.conf默认配置下SRS监听1935端口接收RTMP推流8080端口提供HTTP-FLV和HLS的播放能力。推流地址就是rtmp://服务器IP:1935/live/stream1播放地址可以是http://服务器IP:8080/live/stream1.flv或者http://服务器IP:8080/live/stream1.m3u8。这种做法的好处是摄像头RTSP → FFmpeg转推 → SRS → HTTP-FLV/HLS → 浏览器/小程序播放整条链路全是开源方案不依赖任何商业云平台完全私有化部署适合对数据敏感的内网场景。4.2 公网RTSP测试地址从哪里来在调试推流工具时最头疼的是没有现成的RTSP源可以用。总不能每次都扛着摄像头去现场吧。这里分享几个搞测试源的思路。第一个是本地造流用FFmpeg把一段本地视频文件模拟成一个RTSP服务。比如用Mediamtx原RTSP-Simple-Server起一个本地的RTSP服务再用FFmpeg把mp4文件循环推到它的端口上ffmpeg -re -stream_loop -1 -i test.mp4 \ -c:v copy -c:a copy -f rtsp rtsp://localhost:8554/test这样你本地就有一个rtsp://localhost:8554/test地址随时可以拿来做转推试验。第二个是公开测试流地址。WanCheng、海康官方文档、各大流媒体论坛都会不定期放出公开的RTSP测试源。这类地址有一个特点能用多久全看提供者的心情经常用着用着就断了。所以我的建议是不要把公开源写死在生产代码里只用于功能验证。第三个很简单粗暴用手机摄像头配合一些App把手机变成RTSP源。这类App不少原理是App内部起一个RTSP服务器把摄像头画面以RTSP形式发出来局域网内可访问。调试网络摄像头转推的整个流程完全够用。4.3 实测验证一条完整链路光说不练假把式。我把整个链路串起来跑一遍你照着做就能复现。第一步准备好摄像头或者本地RTSP源假设地址是rtsp://192.168.1.100:554/live用VLC打开确认能播放。第二步启动SRS服务器确认1935端口监听正常。第三步执行转推命令ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/live \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/stream1看到终端持续输出muxing overhead之类的日志说明推流正常。第四步另开一个终端用ffplay验证播放效果ffplay rtmp://127.0.0.1:1935/live/stream1或者用VLC打开播放看到画面且延迟不明显说明链路完全通了。这一步我建议每个参数都挨个试比如把-c:v copy改成-c:v libx264试试CPU占用变化把-rtsp_transport tcp去掉试试公网拉流花不花屏这样一轮下来你对整个系统就有感觉了。5. 常见问题与排查技巧实录5.1 卡顿、花屏、延迟飙升排查思路先说“rtsp流画框推送为新rtsp流为什么总是卡顿”这类问题。根据我的经验卡顿的根源就几个方向。第一链路带宽不足。摄像头的码率假设是4Mbps而你的上传带宽只有2Mbps那不管怎么调都必卡。先确认源码率和可用带宽的关系。用ffprobe查码率ffprobe -v error -show_entries formatbit_rate -of defaultnoprint_wrappers1:nokey1 rtsp://...第二UDP拉流丢包。前面反复强调的-rtsp_transport tcp很多人就是不加明明公网环境还默认走UDP花屏卡顿当然在所难免。第三CPU转码性能不足。如果是用软件转码CPU跑满导致编码速度跟不上也会表现为卡顿。解决办法是开硬编、降低分辨率、用子码流。第四中间环节堆积。如果推流端很平稳但播放端还是卡问题可能出在服务器分发环节。检查SRS日志有没有丢包检查播放端是否有多个连接同时占用带宽。画框这个操作本身也有讲究。如果每帧都要做图像识别再叠加画框那处理耗时可能超过帧间隔帧率就上不去了。遇到这种需求我的建议是做异步检测识别进程跑在独立线程画框只用于结果渲染别让识别逻辑拖累推流管线。5.2 RTSP登录认证处理细节不少RTSP摄像头把认证信息放在URL里像rtsp://admin:passwordip:554/...。但这有个坑如果密码里有、:、/这些特殊字符URL解析就会出错。解决办法是将特殊字符做URL编码。比如密码是abc123要写成abc%40123。的URL编码是%40:是%3A/是%2F。用脚本生成目标地址时建议用Python的urllib.parse.quote()自动处理避免手写出错。另外有些摄像头支持RTSP digest认证FFmpeg默认处理没问题但如果你用GStreamer的rtspsrc插件有概率需要额外添加rtpdec相关参数才能通过认证遇到这种问题直接到GStreamer的官方文档里查rtspsrc的user-id和user-pw属性。5.3 常见问题速查表现象可能原因解决方式推流后播放黑屏视频流是H.265播放器不支持转码为H.264或使用支持H.265的扩展RTMP服务有视频没声音音频编码格式不兼容统一转AAC编码如-c:a aac -b:a 128k播放画面花屏拉流UDP丢包指定-rtsp_transport tcp重试断流后长时间不复位FFmpeg进程挂死增加-stimeout参数外层while循环兜底推流日志一直刷错误RTMP服务器地址/密钥错误用ffplay本地先验证RTMP地址是否正确CPU飙到100%软件转码压力大换h264_nvenc硬编、用子码流、降低分辨率延迟越来越大数据积累或缓冲设置过大加-fflags nobuffer -flags low_delay检查网络抖动浏览器无法直接播放RTSPRTSP在Web端兼容性差通过RTMP接入服务器后用HTTP-FLV或HLS播放5.4 一个关于稳定性的心得最后说一个我个人做监控推流项目时的体会。RTSP转RTMP看似只是加一条FFmpeg命令的事但真正上了生产环境你会发现决定系统稳定性的往往不是FFmpeg本身而是你围绕它打造的“外围体系”——重连够不够快、失败退避够不够合理、状态监控有没有到位。有一次我部署的推流服务凌晨3点集体掉线排查发现是交换机因为网络风暴重启了但脚本里的重连逻辑因为退避时间太短反而把几个摄像头打得死机了。后来我在重连逻辑里加了失败次数统计连续失败超过5次就拉长间隔到30秒同时加了一个健康检查接口每10秒探一次RTMP服务器端口端口不通就自动整个服务重启。从那以后这套系统几乎再没出过需要人工介入的问题。所以我的建议是别把宝全押在一条命令上多想想命令之外的基础设施。用systemd管理FFmpeg进程、用Prometheus监控推流状态、用日志系统记录每次断流原因这些工作都会在你最不想出问题的深夜替你兜住底。本文还有配套的精品资源点击获取 RTSP转RTMP推流工具全解析与实战经验
简介在安防监控与视频直播场景中设备输出RTSP流而平台多接收RTMP流两者协议差异显著RTSP基于UDP、控制与数据分离适合局域网实时监控RTMP基于TCP、封装FLV具备出色的公网分发与低延迟能力。理解协议转换原理是解决公网播放卡顿、花屏问题的关键。FFmpeg作为最成熟的推流工具通过一条命令即可完成RTSP拉流、转封装并推送到RTMP服务器配合SRS等开源服务端可构建完整链路。本文从工具选型、参数调优到断流重连、H.265处理等工程实践系统梳理了监控对接与直播推流中常见的踩坑点为开发者和集成商提供一套可落地的技术方案。 做安防监控对接和直播推流这几年最常被问到的问题之一就是摄像头里的RTSP流怎么推到直播平台上去或者说怎么让手机端、web端也能流畅播放监控画面我早期做这类项目的时候也在这个环节上踩了不少坑。市面上的方案绕来绕去其实核心就一句话用适当的推流工具把RTSP拉到的流重新封装成RTMP格式再推到目标服务器。今天这篇就围绕“rtsp转rtmp推流工具”这个主题把我实际用过的方案、踩过的坑、调参的经验一次讲清楚。这篇内容不是单纯给你贴一条命令就完事而是从协议原理、工具选型、具体实操到问题排查全链路拆开揉碎。不管你是刚接触流媒体的小白还是在做安防对接的嵌入式开发或者正被海康、大华取流地址折磨的集成商都值得读下去。尤其是那些被“rtsp流画框推送为新rtsp流为什么总是卡顿”折磨过的朋友看完你应该能找到排查的方向。1. 为什么需要RTSP转RTMP协议差异与选型思路1.1 RTSP和RTMP的本质区别先把这两个协议说透。RTSPReal Time Streaming Protocol本身不是一个传输媒体数据的协议它更像是流媒体世界的“遥控器”负责发起会话、控制播放、暂停、快进这些动作。真正的音视频数据走的是RTP协议而且RTSP拉流默认走UDP居多控制通道和数据通道是分开的。所以你在VLC里填一个rtsp://地址它能播放但体验和延迟完全取决于播放器对RTP的处理能力。RTMPReal Time Messaging Protocol是Adobe当年为了Flash播放器设计的协议基于TCP数据封装成FLV格式控制消息和数据消息混在同一个TCP连接里。它的优势在于穿透性好、防火墙友好、延迟能控制在1-3秒而且绝大多数云直播平台、CDN、流媒体服务器都对RTMP推流有成熟的接入方案。这就是为什么现实世界里“拉流用RTSP推流用RTMP”是标配。摄像头这种设备天生就出RTSP流而直播平台、微信小程序、网页播放器最兼容的入流协议就是RTMP。两者之间必须有人做“翻译”这个翻译的过程就是转封装或者叫转码。1.2 为什么不能直接用RTSP流做公网分发我见过不少刚接触这个领域的同学问既然VLC能放RTSP为什么不能直接把RTSP地址丢给直播平台答案很简单直播平台几乎不接收RTSP推流。原因有两层。第一RTSP使用UDP传输RTP数据公网环境下UDP丢包严重视频会出现花屏、马赛克体验没法看。第二RTSP没有大规模CDN分发的生态它更适合局域网内的实时监控。你想想一个监控摄像头一天24小时实时上传画面到公网服务器如果用UDP中间任何链路抖动都会导致画面破损而用户端根本没法重传数据。所以RTSP转RTMP的本质第一是“控制协议”到“分发协议”的转换第二是“UDP传输”到“TCP传输”的转换第三是“RTP封装”到“FLV封装”的转换。搞懂这三点你就明白为什么转完之后画面在网页端能流畅播放了。1.3 能用到的工具方案对比工具层面市面上主流的方案有这么几种我简单做个对比。方案原理适合场景上手难度稳定性FFmpeg命令行通用转封装/转码老兵单路或少量路数、Linux服务器部署中等高GStreamer管道流媒体瑞士军刀需要定制管道、叠加画框滤镜较高高Node-Media-ServerNode.js流媒体服务器内置拉流代理快速搭建带转发的服务端低中OBS推流图形化采集推流电脑本地抓屏/摄像头推送极低中商业转流网关硬件或软件一体机多路大规模、要求品牌支持低高你如果是做项目落地的我的建议是优先学FFmpeg。原因很朴素——它是命令行工具可以脚本化、可以定时重连、可以远程调试几乎所有的商业方案底层都是FFmpeg。学会FFmpeg之后不管上层套什么壳你都能看透本质。2. FFmpeg推流工具实战一条命令打通拉流与推流2.1 环境准备与最基础的推流命令第一步肯定是要有FFmpeg。Windows直接去官网下载编译好的exeLinux用apt或者yum装macOS用brew install ffmpeg。装完之后终端输入ffmpeg -version看到输出就行。基础的转推命令长这样ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/stream1这条命令做的事情是通过TCP方式从RTSP地址拉流视频流直接复制不重新编码音频转成AAC格式封装成FLV输出推送到RTMP服务器。实测下来从摄像头到服务器延迟能控制在1秒左右画质无损。注意我用了-rtsp_transport tcp。这点极其关键。默认情况下FFmpeg拉RTSP流走UDP局域网偶尔没事但在公网环境下UDP丢包会导致花屏、卡顿。TCP方式虽然延迟略微高一点点但稳定性和画面完整性要好得多。做公网转推我建议无脑加这个参数。2.2 关键参数逐个拆解很多人贴了命令就跑出了问题不知道怎么改。其实FFmpeg的转推命令里每个参数都对应一个可能的坑我逐个说一下。-i后面的rtsp://地址是输入源。海康摄像头的取流地址规律是rtsp://用户名:密码IP:554/Streaming/Channels/101其中101表示主码流第一路102表示子码流第一路。大华的地址是rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0subtype0是主码流subtype1是子码流。这里有个经验如果是往公网推流条件允许尽量用子码流。主码流一般4Mbps起步子码流通常512Kbps到1Mbps带宽成本差了好几倍。如果只是用来做手机端远程预览子码流的清晰度完全够用。-c:v copy是视频直接复制。前提是你的RTSP源是H.264编码。现在市面上90%的摄像头主码流都是H.264或者H.265如果是H.265RTMP那边会有兼容问题这个我后面单独讲。-c:a aac是把音频转成AAC因为很多摄像头的音频编码是G.711或者AAC而RTMP协议对音频格式支持最稳的就是AAC统一转一下准没错。-f flv是强制输出封装格式为FLV。RTMP协议规定了推流数据必须是FLV封装如果没有这个参数FFmpeg会根据输出地址的后缀猜格式有时候能猜对有时候会报错。我习惯直接写死。2.3 延迟优化与画质平衡如果你对延迟有要求比如要对着监控画面做远程操作那1秒延迟还嫌高还有一套延迟优化参数ffmpeg -rtsp_transport tcp -fflags nobuffer -flags low_delay \ -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv -flvflags no_dts_files rtmp://your-server-ip/live/stream1-fflags nobuffer意思是尽量减少缓冲-flags low_delay同样是降低延迟这组参数组合起来能让端到端延迟压到300-500毫秒。但代价是网络抖动时更容易出现卡顿。建议是局域网内调试可以开低延迟模式公网环境中还是保留默认缓冲更稳。画质方面如果摄像头输出的是1080p主码流你要转推到一个限制带宽的平台那就必须转码而不是copy。转码命令长这样ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v libx264 -preset veryfast -crf 23 -b:v 2000k -maxrate 2200k -bufsize 4000k \ -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/stream1libx264是CPU软件编码-preset veryfast在编码速度和压缩率之间取一个平衡点-crf 23是质量常数数值越小画质越好文件越大。-b:v 2000k锁定了基准码率-maxrate和-bufsize是控制峰值码率的防止画面复杂时瞬间码率暴涨导致卡顿。这里有个点要提醒转码非常吃CPU。实测1080p 30帧的流一台4核的云服务器用veryfast转码CPU大概会跑到60%-80%。如果路数多最好用GPU硬编FFmpeg配合NVIDIA显卡可以加-c:v h264_nvenc直接硬编CPU占用可以降到10%以内。3. 进阶玩法多路流转发、断流重连与复杂场景3.1 多路RTSP并发转推的架构设计做监控项目往往不止一路摄像头。一个厂区动辄几十路你不可能为每一路单独开一个FFmpeg进程然后手动管理。实际项目里一般有两种做法一种是用FFmpeg的filter_complex把所有流合入同一个进程但操作起来复杂且不够灵活另一种是每路一个进程但通过supervisor或者systemd管理统一启停、自动拉起。我后来用的比较多的是后者。每个摄像头写一个shell脚本循环执行FFmpeg推流然后交给systemd常驻。脚本长这样#!/bin/bash while true; do ffmpeg -rtsp_transport tcp \ -stimeout 10000000 \ -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip/live/camera01 echo FFmpeg exited, restarting in 3 seconds... sleep 3 done-stimeout 10000000是设置RTSP socket超时时间为10秒如果10秒内收不到数据就自动断开让脚本进入重连逻辑。这个参数很关键没有它FFmpeg可能会因为TCP半开连接永远挂在那里不退出外层的循环就永远走不下去。用systemd或者直接写个cron监控脚本保证这个shell脚本本身不挂。这样每路摄像头都是独立进程一个挂了不会影响其他路重启也方便配合监控报警足够了。3.2 断流自动重连与稳定性保障RTSP摄像头有一个老毛病网络稍微波一下就断流。有的是因为摄像头本身的TCP连接超时设置太短有的是因为路由器NAT会话老化总之FFmpeg推着推着就断了。断流不可怕可怕的是断流之后不会自动恢复。上面那个while循环就解决了自动重连的问题。但重连有个细节要注意FFmpeg退出后立刻重连有时候会因为摄像头侧还没释放旧连接而失败。所以sleep 3是有讲究的给摄像头留出处理旧连接的时间。还有一个更稳的做法是加退避策略比如连续失败5次以后sleep时间从3秒递增到10秒防止摄像头被频繁连接打挂。脚本可以这样写#!/bin/bash fail_count0 while true; do ffmpeg -rtsp_transport tcp -stimeout 10000000 \ -i rtsp://... -c:v copy -c:a aac \ -f flv rtmp://... code$? if [ $code -ne 0 ]; then fail_count$((fail_count1)) else fail_count0 fi if [ $fail_count -gt 5 ]; then sleep 10 else sleep 3 fi done这里用FFmpeg的退出码做判断正常退出码是0异常退出码非0。实测下来这套逻辑能扛住摄像头断电、网线松动、服务器重启等各种场景。3.3 GStreamer备用方案真正意义上的“流媒体瑞士军刀”FFmpeg虽然强但有的时候你要对画面做处理比如叠加文字、画框、加马赛克再用FFmpeg的filter语法处理会比较绕。这时候GStreamer就更有优势。比如“rtsp流画框推送为新rtsp流”这种需求GStreamer的插件体系处理起来非常明确。一条简单的GStreamer RTSP转RTMP管道长这样gst-launch-1.0 rtspsrc locationrtsp://admin:password192.168.1.64:554/Streaming/Channels/101 latency0 ! \ rtph264depay ! h264parse ! flvmux streamabletrue ! \ rtmpsink locationrtmp://your-server-ip/live/stream1如果要去掉音频就只保留视频分支如果要叠加画框可以在h264parse后面接videoconvert ! cairooverlay text区域A等等。GStreamer的优点是可组合性极强每个插件就是一个积木缺点是学习曲线陡峭、文档零散。一般项目用FFmpeg就够了只有在定制化处理需求很高的时候才建议上GStreamer。3.4 H.265编码流的特殊处理现在越来越多的新款摄像头默认输出H.265编码。H.265的优点是同画质下码率只有H.264的一半对存储和带宽都非常友好。但RTMP协议从诞生那天起就没考虑过H.265标准RTMP服务器收到H.265的FLV流基本是黑屏。解决方案有两条路。第一条是把H.265转码成H.264再推流命令很简答ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v libx264 -preset veryfast -crf 23 \ -c:a aac -f flv rtmp://...代价是CPU开销上去了。第二条是用支持H.265扩展的RTMP服务器比如SRS 4.0以上版本原生支持Enhanced-RTMP允许在FLV里封装HEVC数据。这种情况下视频流可以继续copyCPU零开销ffmpeg -rtsp_transport tcp -i rtsp://... \ -c:v copy -c:a copy -f flv rtmp://...但注意接收端播放器也得支持Enhanced-RTMP才能解码。实测下来网页端用VLC、ffplay移动端用ijkplayer开启对应选项后能正常播放。如果你无法控制接收端环境稳妥起见还是转码成H.264。4. 搭建RTMP推流服务器与测试资源4.1 用SRS一条命令搭建RTMP服务器说完了推流端再说接收端。没有RTMP服务器你推出去的数据没人接等于白干。实际工作中SRSSimple Realtime Server是我用过最顺手的开源流媒体服务器一个二进制文件跑起来就是一个完整的RTMP服务器。用Docker一条命令起服务docker run -d --name srs \ -p 1935:1935 \ -p 8080:8080 \ -p 8443:8443 \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4 \ ./objs/srs -c conf/rtmp.conf默认配置下SRS监听1935端口接收RTMP推流8080端口提供HTTP-FLV和HLS的播放能力。推流地址就是rtmp://服务器IP:1935/live/stream1播放地址可以是http://服务器IP:8080/live/stream1.flv或者http://服务器IP:8080/live/stream1.m3u8。这种做法的好处是摄像头RTSP → FFmpeg转推 → SRS → HTTP-FLV/HLS → 浏览器/小程序播放整条链路全是开源方案不依赖任何商业云平台完全私有化部署适合对数据敏感的内网场景。4.2 公网RTSP测试地址从哪里来在调试推流工具时最头疼的是没有现成的RTSP源可以用。总不能每次都扛着摄像头去现场吧。这里分享几个搞测试源的思路。第一个是本地造流用FFmpeg把一段本地视频文件模拟成一个RTSP服务。比如用Mediamtx原RTSP-Simple-Server起一个本地的RTSP服务再用FFmpeg把mp4文件循环推到它的端口上ffmpeg -re -stream_loop -1 -i test.mp4 \ -c:v copy -c:a copy -f rtsp rtsp://localhost:8554/test这样你本地就有一个rtsp://localhost:8554/test地址随时可以拿来做转推试验。第二个是公开测试流地址。WanCheng、海康官方文档、各大流媒体论坛都会不定期放出公开的RTSP测试源。这类地址有一个特点能用多久全看提供者的心情经常用着用着就断了。所以我的建议是不要把公开源写死在生产代码里只用于功能验证。第三个很简单粗暴用手机摄像头配合一些App把手机变成RTSP源。这类App不少原理是App内部起一个RTSP服务器把摄像头画面以RTSP形式发出来局域网内可访问。调试网络摄像头转推的整个流程完全够用。4.3 实测验证一条完整链路光说不练假把式。我把整个链路串起来跑一遍你照着做就能复现。第一步准备好摄像头或者本地RTSP源假设地址是rtsp://192.168.1.100:554/live用VLC打开确认能播放。第二步启动SRS服务器确认1935端口监听正常。第三步执行转推命令ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/live \ -c:v copy -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/stream1看到终端持续输出muxing overhead之类的日志说明推流正常。第四步另开一个终端用ffplay验证播放效果ffplay rtmp://127.0.0.1:1935/live/stream1或者用VLC打开播放看到画面且延迟不明显说明链路完全通了。这一步我建议每个参数都挨个试比如把-c:v copy改成-c:v libx264试试CPU占用变化把-rtsp_transport tcp去掉试试公网拉流花不花屏这样一轮下来你对整个系统就有感觉了。5. 常见问题与排查技巧实录5.1 卡顿、花屏、延迟飙升排查思路先说“rtsp流画框推送为新rtsp流为什么总是卡顿”这类问题。根据我的经验卡顿的根源就几个方向。第一链路带宽不足。摄像头的码率假设是4Mbps而你的上传带宽只有2Mbps那不管怎么调都必卡。先确认源码率和可用带宽的关系。用ffprobe查码率ffprobe -v error -show_entries formatbit_rate -of defaultnoprint_wrappers1:nokey1 rtsp://...第二UDP拉流丢包。前面反复强调的-rtsp_transport tcp很多人就是不加明明公网环境还默认走UDP花屏卡顿当然在所难免。第三CPU转码性能不足。如果是用软件转码CPU跑满导致编码速度跟不上也会表现为卡顿。解决办法是开硬编、降低分辨率、用子码流。第四中间环节堆积。如果推流端很平稳但播放端还是卡问题可能出在服务器分发环节。检查SRS日志有没有丢包检查播放端是否有多个连接同时占用带宽。画框这个操作本身也有讲究。如果每帧都要做图像识别再叠加画框那处理耗时可能超过帧间隔帧率就上不去了。遇到这种需求我的建议是做异步检测识别进程跑在独立线程画框只用于结果渲染别让识别逻辑拖累推流管线。5.2 RTSP登录认证处理细节不少RTSP摄像头把认证信息放在URL里像rtsp://admin:passwordip:554/...。但这有个坑如果密码里有、:、/这些特殊字符URL解析就会出错。解决办法是将特殊字符做URL编码。比如密码是abc123要写成abc%40123。的URL编码是%40:是%3A/是%2F。用脚本生成目标地址时建议用Python的urllib.parse.quote()自动处理避免手写出错。另外有些摄像头支持RTSP digest认证FFmpeg默认处理没问题但如果你用GStreamer的rtspsrc插件有概率需要额外添加rtpdec相关参数才能通过认证遇到这种问题直接到GStreamer的官方文档里查rtspsrc的user-id和user-pw属性。5.3 常见问题速查表现象可能原因解决方式推流后播放黑屏视频流是H.265播放器不支持转码为H.264或使用支持H.265的扩展RTMP服务有视频没声音音频编码格式不兼容统一转AAC编码如-c:a aac -b:a 128k播放画面花屏拉流UDP丢包指定-rtsp_transport tcp重试断流后长时间不复位FFmpeg进程挂死增加-stimeout参数外层while循环兜底推流日志一直刷错误RTMP服务器地址/密钥错误用ffplay本地先验证RTMP地址是否正确CPU飙到100%软件转码压力大换h264_nvenc硬编、用子码流、降低分辨率延迟越来越大数据积累或缓冲设置过大加-fflags nobuffer -flags low_delay检查网络抖动浏览器无法直接播放RTSPRTSP在Web端兼容性差通过RTMP接入服务器后用HTTP-FLV或HLS播放5.4 一个关于稳定性的心得最后说一个我个人做监控推流项目时的体会。RTSP转RTMP看似只是加一条FFmpeg命令的事但真正上了生产环境你会发现决定系统稳定性的往往不是FFmpeg本身而是你围绕它打造的“外围体系”——重连够不够快、失败退避够不够合理、状态监控有没有到位。有一次我部署的推流服务凌晨3点集体掉线排查发现是交换机因为网络风暴重启了但脚本里的重连逻辑因为退避时间太短反而把几个摄像头打得死机了。后来我在重连逻辑里加了失败次数统计连续失败超过5次就拉长间隔到30秒同时加了一个健康检查接口每10秒探一次RTMP服务器端口端口不通就自动整个服务重启。从那以后这套系统几乎再没出过需要人工介入的问题。所以我的建议是别把宝全押在一条命令上多想想命令之外的基础设施。用systemd管理FFmpeg进程、用Prometheus监控推流状态、用日志系统记录每次断流原因这些工作都会在你最不想出问题的深夜替你兜住底。本文还有配套的精品资源点击获取