简介视频流传输是直播与安防监控的核心环节而RTSP与RTMP作为两种关键流媒体协议分别承担着拉流与推流的角色。RTSP常用于从摄像头或NVR获取视频流RTMP则是直播平台和CDN普遍采用的推流协议。当需要将监控画面或本地视频源接入云直播服务时RTSP转RTMP就成了必不可少的转换环节。FFmpeg作为业界主流的流媒体处理工具凭借强大的协议转换能力和灵活的编码参数控制成为实现这一转换的首选方案。无论是通过命令参数实现高效转推还是应对卡顿、断流等常见故障掌握FFmpeg的配置和排查方法都能显著提升流媒体服务的稳定性。本文基于实际项目经验清晰梳理了RTSP转RTMP的完整链路、关键参数选择、测试资源搭建以及生产环境部署注意事项适合安防上云、直播接入、自建流媒体等场景的开发者参考。 我很久没遇到过这么标准的痛点需求了。手头正好在处理一个监控大屏项目十几路海康摄像头要同时上云但目标平台只认RTMP推流一个个手动去OBS里拉流再推根本不现实。折腾了一周踩了不少坑把RTSP转RTMP这套链路彻底摸透了。这篇就把完整方案、命令参数、实测中遇到的卡顿和断流问题全部写清楚希望能帮你少走弯路。1. 为什么需要这个转换RTSP和RTMP在视频传输链路里的角色差异1.1 协议分工RTSP负责拉RTMP负责推先说结论RTSP和RTMP其实不是一个层面的东西虽然都叫流媒体协议但它们在直播链路里的分工完全是两回事。RTSPReal Time Streaming Protocol本质是一个控制协议。它负责建立会话、发送播放/暂停/停止等指令真正承载视频数据的是配套的RTP包。这就有个关键特点RTSP天然是拉流协议适合从IPC网络摄像头、NVR网络录像机这类设备上取视频流。你打开VLC输入一个RTSP地址本质就是发一个PLAY请求然后设备把RTP流源源不断吐给你。RTMPReal Time Messaging Protocol则是Adobe当年为了直播场景设计的推流协议。它把视频数据切成一个个消息块chunk通过长连接持续上行延迟低、分发链路成熟。目前几乎所有主流的直播平台、云直播服务默认的接入协议都是RTMP。为什么非要转直接原因很简单RTSP只解决了从设备取流的问题但你要把流推出去喂给CDN、直播平台或者自建流媒体服务器对方根本不认RTSP只认RTMP。就像你从水库摄像头把水引出来了RTSP拉流但城市供水管网直播平台的接口规格是消防栓RTMP不装个转换接头转推工具水就进不了管网。1.2 业务场景哪些链路最需要这个转换工具我整理了一下近期社区里大家遇到的实际场景基本集中在这么几类场景典型链路核心诉求安防监控上云海康/大华IPC RTSP流 → 转换 → RTMP推流至云平台多路并发、7x24稳定运行直播平台接入本地视频/摄像头RTSP → 转换 → RTMP推到斗鱼/B站等低延迟、不卡顿自建流媒体内网分发RTSP → 转换 → RTMP进Nginx-RTMP/Node-Media-Server多端播放Web/小程序/App视频会议/在线教学录屏或专业摄像机RTSP → 转换 → RTMP至腾讯会议/钉钉直播稳定性优先音频同步你要做的其实就是在这一条链路的中间节点上塞一个转推工具把RTSP协议转换成RTMP协议。2. 方案选型FFmpeg是首选但你要知道它为什么是首选2.1 各路方案横向对比我试过的方案至少五六个各有优劣直接给你一个对照组方案优点缺点适用场景FFmpeg 命令行跨平台、参数细、可控度极高、免费、可脚本化有一定学习曲线参数需要理解绝大多数场景强烈推荐GStreamer功能同样强大插件化设计命令行比FFmpeg更复杂资料相对少嵌入式Linux、管线复杂场景OBS Studio Multi RTMP插件可视化、上手快支持多平台同时推流需要图形界面不适合服务器无人值守资源占用高临时性、桌面推流商业转推软件如LivePush等开箱即用、有管理界面收费、黑盒、定制化差不差钱且不想折腾的团队自研转推服务基于Live555自研RTMP sender完全可控工作量大、调试周期长有特殊定制需求的大厂2.2 为什么我坚持用FFmpeg用FFmpeg而不是其他工具理由有三第一它是流处理事实标准。凡是涉及音视频编解码、转协议、滤镜处理FFmpeg几乎是绕不开的基础设施。不管是OBS、VLC还是各家播放器底层都在用FFmpeg的库。命令行方式反而能让你把管线掰开揉碎知道每一步在做什么。第二资源占用和稳定性有优势。同样一路1080P的流转换OBS在图形界面下内存占用轻松上GB而纯命令行FFmpeg进程控制在几百MB以内还能用-re精确控制读取速度防止源流缓冲堆积。对于服务器上跑7x24小时转推任务的需求命令行是唯一不会随时被显卡驱动崩溃带崩的方案。第三参数是透明的。每一条命令、每一个参数都明明白白写在脚本里出了问题时可以一步步排查而不是对着一个黑盒瞎猜。3. 核心实操FFmpeg转推命令的参数拆解与选择逻辑3.1 最少参数版本先跑通再说假设你有一台海康摄像头RTSP拉流地址是rtsp://admin:password192.168.1.64:554/Streaming/Channels/101目标RTMP服务器是自建的rtmp://127.0.0.1:1935/live/monitor1那么最基础的命令是ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 -c:v copy -c:a aac -f flv rtmp://127.0.0.1:1935/live/monitor1这条命令干了几件事-rtsp_transport tcp强制用TCP传输RTSP数据。这是非常关键的一个参数默认FFmpeg用的是UDP在公网或无线环境下UDP丢包会导致画面花屏、马赛克甚至直接断流。TCP虽然会多一点重传开销但换来的是稳定。-c:v copy视频流直接复制封装不重新编码。如果源流本身就是H.264而RTMP也支持H.264那直接copy能节省大量CPU几乎零损耗。-c:a aac音频转成AAC编码因为RTMP对音频编码支持有限AAC是兼容性最好的选择。-f flv强制输出FLV封装格式。RTMP的payload本质上就是FLV tag所以推RTMP必须用FLV封装。3.2 需要重新编码时的完整命令版本上面那条命令能跑通的前提是源流是H.264 AAC。但现实很骨感——很多监控摄像头默认输出是H.265HEVC编码虽然画面更清晰、码率更小但RTMP的兼容性对H.265支持参差不齐尤其是一些老牌CDN和播放器根本不认H.265的FLV。这个时候你就得重新编码为H.264。完整命令长这样ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k -maxrate 2500k -bufsize 5000k -r 25 -g 50 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://127.0.0.1:1935/live/monitor1参数逐个拆解参数含义为什么这么设-c:v libx264视频编码器用libx264稳几乎全平台可用兼容性最好-preset veryfast编码速度与压缩率的平衡档位转推任务追求速度veryfast在画质和CPU占用之间挺合适-tune zerolatency针对低延迟场景优化编码器去掉编码器的延迟缓冲对直播场景极重要-b:v 2500k视频目标码率2500kbps1080P25帧的监控画面2500k足够清晰可根据实际画面动态调整-maxrate/-bufsize限制峰值码率防止抖动保持码率平稳防止网络波动时被服务器断连-r 25强制输出帧率25fps监控源通常是25fps强制统一防止时间戳错乱-g 50关键帧间隔为50帧即2秒一个关键帧关键帧间隔影响播放器起播速度和卡顿恢复速度-c:a aac -b:a 128k -ar 44100音频AAC编码、128kbps、44.1kHz采样率最通用的直播音频配置3.3 高性能场景为什么还要考虑硬编码如果你的机器CPU不强比如在云服务器上跑FFmpeg还要同时转推多路1080P流纯CPU软编很容易把负载打满导致推流卡顿。这个时候就需要硬编码。Intel核显或独显的FFmpeg硬编码参数是这样的ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 -c:v h264_qsv -global_quality 28 -c:a aac -f flv rtmp://127.0.0.1:1935/live/monitor1NVIDIA显卡则用h264_nvencAMD用h264_amf。提示硬编码虽然省CPU但画质在同等码率下通常略有损失且部分显卡驱动在长时间运行后会有内存泄漏的风险。如果是生产环境建议软硬结合关键流用软编、非关键流用硬编。4. 测试资源与工具链没有摄像头怎么验证整套流程4.1 公开RTSP测试流的获取与注意事项很多时候我们开发调试时手边没有摄像头需要找公开RTSP测试流。但我要提醒一句不要扫描和尝试未授权访问的摄像头这是基本的安全合规要求。请使用公开明确、允许测试的流地址。常见的公开RTSP测试流Wowza官方测试流rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov一些开放实验室提供的测试流自己用FFmpeg生成一个本地RTSP源这个最可控见下文我用得最多的是Wowza那个官方地址用来验证FFmpeg拉流参数和网络连通性非常好用。但注意公网测试流不稳定别拿来做长时间压测压测还是自己搭源靠谱。4.2 用FFmpeg自建RTSP测试源这个技巧极大方便了调试。你的开发机上跑一个RTSP服务然后用FFmpeg往这个服务推一路测试视频。这样你可以完全控制输出流的编码、帧率、分辨率模拟各种异常场景。首先搭建一个简单的RTSP服务。最简单的方式是使用mediamtx前身是rtsp-simple-server一个开源轻量的RTSP服务器。下载二进制后直接运行./mediamtx默认监听:8554RTSP地址形如rtsp://localhost:8554/test。然后启动FFmpeg往这个服务推流ffmpeg -re -f lavfi -i testsrcsize1280x720:rate25 -f lavfi -i sinefrequency1000:sample_rate44100 -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -shortest -f rtsp rtsp://localhost:8554/test这条命令会生成一个带动态测试图案和1kHz正弦波音的视频源。不需要真实的摄像头你就能验证后面的转推命令了。4.3 海康/大华取流地址格式速查你用真实摄像头时取流地址必须写对。不同厂商、不同型号的IPCRTSP路径设计差异很大这里给一份速查海康威视Hikvision主码流rtsp://用户名:密码IP:554/Streaming/Channels/101 子码流rtsp://用户名:密码IP:554/Streaming/Channels/102其中101里的1表示通道101表示主码流102的02表示子码流。部分新固件支持rtsp://用户名:密码IP:554/Streaming/tracks/101?starttime20241201T000000Z大华Dahuartsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0subtype0是主码流subtype1是子码流。宇视Univiewrtsp://用户名:密码IP:554/unicast/c1/s0/live如果摄像头做了RTSP端口修改就把554换成实际端口。用户名密码中的特殊字符需要用URL编码转义比如要写成%40冒号要写成%3A否则FFmpeg解析地址时会出错。4.4 RTMP测试地址与自建服务器方案需要RTMP服务端来接收推流除了用直播平台的推流地址最好自己搭一个。本地调试最方便的是Node-Media-Server单体项目、支持多协议一条Docker命令就能跑起来docker run -p 1935:1935 -p 8000:8000 illuspas/node-media-server启动后推流地址是rtmp://localhost:1935/live/stream1Play地址是http://localhost:8000/live/stream1.flv还能通过HTTP接口直接拉流测试。老牌方案是Nginx配合nginx-rtmp-module虽然配置稍微繁琐但非常稳定生产环境大量使用。两种方案的取舍后面章节会细说。5. 十个有九个会踩的坑认证、卡顿、断流和延迟的根因分析5.1 RTSP登录认证Digest认证和地址转义RTSP协议有一套登录认证机制摄像头厂家普遍实现的是Digest认证摘要认证而不是Basic基础认证。FFmpeg默认会处理Digest认证逻辑是先发送一个不带认证信息的请求收到401的挑战后再携带摘要信息重发请求。但这里有个坑如果你的地址里带上用户名密码FFmpeg会直接用Basic认证方式而很多摄像头只允许Digest方式这时候会一直401认证失败。解决方法是在FFmpeg命令中不要通过URL携带用户密码而是通过环境变量或配置文件的方式传递但FFmpeg命令行并没有直接支持username/password参数的选项用于RTSP更稳妥的做法是ffmpeg -rtsp_transport tcp -rtsp_flags prefer_tcp -i rtsp://192.168.1.64:554/Streaming/Channels/101 -c:v copy -f flv rtmp://127.0.0.1:1935/live/test然后收到提示时输入用户名密码交互式或者利用ffmpeg支持的-rtsp_flags配合其他认证方式。实际上FFmpeg对RTSP URL中的用户信息部分会提取出来做认证处理把rtsp://admin:passwordip/...写全时它也会先尝试Basic如果服务器返回401且WWW-Authenticate指示的是DigestFFmpeg是支持自动切换的。我自己实测大部分海康固件用带用户名的URL可以直接通过。不过遇到某些老固件或兼容性差的设备就改用不带用户名的方式或者用curl测试一下认证流程。注意点地址中的特殊字符必须转义。比如密码是abc123直接写在URL里会变成rtsp://admin:abc123192.168.1.64:554/...FFmpeg会把第一个后面的123192.168.1.64误判为host导致解析失败。正确写法是abc%40123。5.2 卡顿的根因为什么一画框推流就卡拉流却在VLC里很流畅这是社区里被问爆的问题RTSP流画框推送为新RTSP流为什么总是卡顿。我自己实测排查过结论是卡顿极少是RTMP服务端的问题绝大多数出在源流获取和编码环节。下面是一份排查清单症状根因解决方案推流端CPU占用100%解码/编码开销过大主机性能不足降低分辨率/码率开启硬编码画面每隔几秒卡一下但源流在VLC里流畅源流RTSP传输层用了UDP丢包加-rtsp_transport tcp推上去的流在播放器里频繁缓冲码率波动太大关键帧间隔过长限制-maxrate降低-g值长时间运行后卡顿越来越频繁内存泄漏或网络连接未释放定期重启转推进程加日志多路并发时全部卡顿带宽或CPU被打满做流控、错峰推流、改低码率针对画框推送为新RTSP流这个具体场景即对画面做AI检测或画框标注后再推流必须经过解码 → 滤镜处理 → 编码三步这个过程最容易出问题。我建议的排查顺序是先用VLC或FFmpeg直接拉原始RTSP流确认源流本身不卡。把滤镜处理去掉直接转推看是否卡顿。如果去掉滤镜就不卡说明卡顿来自滤镜算法性能。如果加了滤镜就卡优先用GPU滤镜比如scale_cuda、drawbox等支持GPU加速的滤镜或者降低处理分辨率。如果源流本身就是从NVR转发出来的子码流可能本身就有掉帧直接换主码流测试。卡顿没有灵丹妙药只能一环一环拆定位到具体瓶颈。5.3 断流自动重连FFmpeg没有内建完整的断线重连机制这是个残酷的现实命令行FFmpeg在RTSP源断掉后进程不会自动恢复它会报错退出。网上有一些说法是加-reconnect 1参数但这个参数的实现机制在不同的FFmpeg版本里并不一致实测并不完全可靠。我在生产环境里的做法是写一个循环脚本检测FFmpeg进程是否退出退出了就重新拉起来同时清理可能残留的socket。#!/bin/bash while true; do ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c:v copy -c:a aac -f flv rtmp://127.0.0.1:1935/live/camera1 2/var/log/ffmpeg_camera1.log echo $(date): FFmpeg exited, restarting in 5 seconds... /var/log/ffmpeg_camera1.log sleep 5 done注意几点用追加日志不要覆盖。sleep 5 是必须的否则如果摄像头短时间内持续不可用会形成疯狂重启的死循环。如果摄像头有多个地址主码流、子码流可以在脚本中做故障切换。5.4 低延迟的极限在哪里很多人推RTMP第一诉求是延迟要低但我要泼一盆冷水你不可能通过推流端单方面把端到端延迟压到无限低。RTMP推流本身延迟可以很低源到服务器1秒内不是问题。延迟大头通常出现在播放端播放器缓冲、服务器转HLS延迟、CDN分发网络缓冲。如果你自建服务器典型的低延迟配置是FFmpeg推流端-tune zerolatency -g 251秒一个关键帧服务端转发直接用RTMP-HTTP-FLV不要经过HLS播放端用flv.js或mpegts.js播放延迟普遍在1-3秒实测里在不经过CDN、局域网环境下FFmpeg推流NMS转发FLVflv.js播放端到端延迟能做到1-2秒已经接近RTMP链路的极限了。想更低就得走WebRTC那是另一个话题了。6. 推上去之后怎么办播放端、服务端和Web/H5播放链路6.1 播放端选型既要兼容性也要低延迟推流到RTMP服务器后消费端的播放方案直接决定了用户的观看体验。常见播放端选型播放端协议支持延迟兼容性适用场景VLCRTSP/RTMP/HLS/HTTP-FLV中默认缓冲较大桌面全平台验收、调试浏览器flv.js/mpegts.jsHTTP-FLV/WebSocket-FLV低1-3s现代浏览器均支持Web应用iOS/Android原生HLS/HTTP-FLV中低需集成SDK移动端App小程序HLS依赖服务端转高5-10s微信/支付宝等小程序播放VLC虽然能播RTMP但默认缓冲设置得很大看着延迟高不一定是推流端的问题而是播放器在缓冲。测试延迟时可以关掉VLC的缓存试试或者用FFprobe直接看流的时间戳。6.2 服务端对比Nginx-RTMP还是Node-Media-Server我两个都用过各有优劣Nginx nginx-rtmp-module优点极其稳定、资源占用极低、生态成熟、支持HLS直接输出。缺点配置稍繁琐模块需要自己编译或选用带模块的镜像对HTTP-FLV的支持需要额外的nginx-http-flv-module。一个最小可用配置是这样rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # 允许所有来源推流生产环境建议用token鉴权 allow publish 127.0.0.1; allow publish 192.168.0.0/16; deny publish all; } } }Node-Media-Server优点Node.js实现自带HTTP-FLV/WebSocket-FLV输出有内置的鉴权中间件机制管理API丰富配合Web项目特别顺。缺点并发量极高时不如Nginx稳定Node进程本身的内存管理需要留意。如果你主要面向Web播放用flv.jsNode-Media-Server开箱即用更省事。如果做大规模分发或已经重度依赖Nginx那就选Nginx。6.3 Web/H5播放为什么RTMP不能直接进浏览器以及替代方案浏览器的原生video标签不支持RTMP协议。RTMP依赖Flash时代的浏览器插件现在基本退出历史舞台了。所以从RTMP流到Web播放中间必须有一次协议再转换。主流的方案是服务端把RTMP流转成HTTP-FLV或WebSocket-FLV浏览器端用flv.js或mpegts.js来播放。只要推流端和服务端延迟控制得当播放端几乎无感。具体的播放代码大致是这样script srchttps://cdn.jsdelivr.net/npm/flv.js/dist/flv.min.js/script video idvideoElement controls muted autoplay/video script if (flvjs.isSupported()) { var videoElement document.getElementById(videoElement); var flvPlayer flvjs.createPlayer({ type: flv, isLive: true, url: http://127.0.0.1:8000/live/camera1.flv }); flvPlayer.attachMediaElement(videoElement); flvPlayer.load(); flvPlayer.play(); } /script6.4 uniapp/移动端播放RTSP的替代思路“uniapp 实现rtsp视频播放”是搜索热词我也被不少做App的同学问过。直接说结论不管你是uni-app也好、原生安卓也好直接播RTSP流的体验都很差因为移动端浏览器和应用层播放器对RTSP的兼容性极差。常规做法是RTSP先转RTMP再由服务端转出HTTP-FLV或HLSApp端用video标签或相应的播放SDK去播放。uni-app里可以用uni.createVideoContext结合HTTP-FLV地址配合原生插件播放或者干脆转HLS用video标签直接播。HLS延迟虽然高但胜在什么都不用配置就能播。7. 把单个进程变成生产力进程守护、日志、健康检查与扩展思路7.1 进程守护和存活监控生产环境里无脑写个死循环脚本虽然能用但不够体面。我建议至少做到这几点使用systemd管理在Linux服务器上给每个推流任务写一个systemd unit文件配置Restartalways、RestartSec5比shell脚本循环更规范。健康检查定期用FFprobe探活确认当前推流连接是否正常。比如每30秒执行一次ffprobe -v error -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 -show_entries streamindex -of csvp0 /dev/null 21 echo OK || echo DOWN日志旋转FFmpeg日志默认是无限增长的不加logrotate迟早撑爆磁盘。配置个按天切割就行。7.2 从单路到多路并发推流的资源估算与优化当你要从监控一路拉流扩展到同时转推十几路摄像头时资源规划是个大问题。我的经验公式先确认源流码率。用FFprobe看实际码率别信摄像头标称值。转推copy模式只做协议转换CPU开销很低主要瓶颈是网络带宽。转码模式每路1080P25fps软编大概需要2-4个CPU核心具体取决于preset和源流分辨率。一台8核云服务器软编跑2-3路就吃紧了。带宽估算转推N路上行带宽至少要 N × 码率×1.3留出协议开销余量。7.3 扩展思路转推到多个平台、录制存档、AI画框后再推送如果你要一键多平台分发建议在FFmpeg基础上套一个简单的管理服务。比如用Node.js或Python写一个控制层读取摄像头清单每个推流任务一个子进程记录存活状态支持热更新。这个思路可以扩展出很多能力转推多平台一个进程同时输出两个RTMP地址FFmpeg用-map 多个输出或者开多个进程。本地录制推流同时落盘用-c copy -f mp4单独开一个输出到文件方便事后回溯。AI画框结合OpenCV或其他视觉模型做目标检测然后用FFmpeg的.drawbox或自定义滤镜把检测结果叠加到画面里再推送就是热词里说到的rtsp流画框推送场景。核心还是那头管道设计RTSP拉流是源头FFmpeg是处理中心RTMP是出口。你只要把每段管子的状态监控起来这套系统就能稳定跑很久。最后再分享一个实际运维的小细节FFmpeg在长连接断掉之后偶尔会出现进程没退出但已无法推流的僵尸态。光靠进程守护还不够建议在健康检查脚本里不仅做TCP层的检测最好同时对比FFmpeg日志里的最后一条时间戳超过比如60秒没有新输出就强制kill重启。这套方案我用了将近两年稳定运行了好几路现场希望对你有帮助。本文还有配套的精品资源点击获取