摄像头说RTSP，浏览器只认WebRTC：这个实时流媒体服务器让它们握手言和

摄像头说RTSP浏览器只认WebRTC这个实时流媒体服务器让它们握手言和【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx晚上十点快递显示已签收我却没法确认它是否躺在门口——那台只会说RTSP的摄像头怎么都进不了手机浏览器。直到我遇到MediaMTX一个把 RTSP、RTMP、SRT、WebRTC、LL-HLS、MPEG-TS 互相翻译的实时流媒体服务器画面一帧都不重编码。先别急着装你得知道它到底在解决什么把视频协议想象成方言安防摄像头祖传 RTSPOBS 这类推流软件习惯 RTMP专业传输设备认 SRT因为它在弱网下抗丢包而浏览器和手机 App 只听得懂 WebRTC 和 HLS。你的设备说各自的方言中间却没人翻译。以前怎么办对每一种输入协议→输出协议的组合单独搭一套链路一台机器装 FFmpeg 转码另一台做流媒体服务再写个播放页面。RTSP 转 WebRTC 一套RTMP 转 HLS 再一套每套都是独立部署、独立维护、独立的延迟。跑上半年光画拓扑图就得半天。更冤的是很多人以为协议转换必须转码。其实协议转换只是换个信封画面编码比如 H.264根本没变。为了迁就格式去重编码白白烧 CPU还多出几秒延迟。MediaMTX 想拆掉的正是这座协议巴别塔。它自称媒体路由器流从一端进、从另一端出协议变了画质和延迟几乎不变。三个关键时刻它帮我挡掉了什么麻烦RTSP转WebRTC三行配置一帧都不重编码最让我意外的是第一次把摄像头送进浏览器。在mediamtx.yml里加三行启动浏览器打开http://localhost:8888点一下路径名画面就出来了——WebRTC 通道延迟几百毫秒的量级。同一路流用 VLC 打开rtsp://localhost:8554/cam1也能看手机走 HLS 也行。同一个源三种读法服务器没有重编码一帧。省下的不只是买转码服务器的钱还有画面为什么变糊了的排查时间。流断了页面却不黑屏传统监控方案最怕推流端掉线摄像头一断网页立刻黑屏等着接用户投诉。MediaMTX 把流和源解耦了它有常驻可用机制——发布端暂时离线读取端拿到的仍是一条正常的流页面不闪断、客户端不报错。再配合按需发布有人来读才去拉起摄像头没人读就休眠一台小主机就能挂几十路流这正是视频监控Web端播放能规模化落地的关键。错过的事回放来补半夜的事故没人守在屏幕前。它可以边转发边录制格式选 fMP4 或 MPEG-TS按需回放它还留了一排钩子hooks有人开始读流、录完一段文件、某个源上线……都能触发外部命令比如录完一段直接推送到对象存储或给企业微信推一条告警。加上 Control API 和 Prometheus 格式的指标想把它接进自己的流媒体性能监控面板半天能搞定。亲手试一次三步从下载到看到画面准备一个能拉流的 RTSP 地址没有摄像头可以用ffmpeg -re -stream_loop -1 -i 视频文件 -f rtsp rtsp://localhost:8554/test自己推一路。第一步拿到程序。三选一下载对应平台的单个可执行文件解压后就是一个mediamtx加一个mediamtx.yml零依赖单文件部署想从源码跑git clone https://gitcode.com/GitHub_Trending/me/mediamtx按docs/6-misc/1-compile.md编译Docker 用户最简单docker run --rm -it --networkhost bluenviron/mediamtx:1。产出./mediamtx启动后日志显示各协议端口就绪RTSP 8554、RTMP 1935、HLS 8888……。第二步写一段五行的配置。在mediamtx.yml的paths:下加paths: cam1: source: rtsp://admin:你的密码192.168.1.100:554/stream1保存即可它会自动检测配置文件变更并热重载已连接的客户端不断线。产出日志里出现路径已就绪的提示源已拉通。第三步浏览器验证。打开http://localhost:8888点cam1选 WebRTC 播放。产出低延迟实时画面再用rtsp://localhost:8554/cam1在 VLC 里打开同一路流——一个源多种读法这下有了直观感受。它的边界说清楚免得你踩坑想上生产环境它还备着内置/HTTP/JWT 三种认证、把流转发到其他服务器的能力、多实例分摊压力的部署模式。但它有两件事刻意不做。一是不转码如果客户端网络参差不齐、需要把 4K 压成 720p那是 FFmpeg 的活配合着用就行官方镜像有带 FFmpeg 的版本。二是不做大而全的 VOD 平台它擅长实时流的录制与回放而不是海量视频点播库。写在最后那天夜里我在楼梯间用手机看完了监控画面快递确实在门口。一个只装了一个文件的服务替我消掉了两种协议之间鸡同鸭讲的十年恩怨。如果你手里也有一堆各自为政的设备从docs/1-kickoff/的安装说明开始配置文件每个字段的含义都写在docs/5-references/1-configuration-file.md里。从把第一路流送进浏览器到接入自己的告警和监控面板它大概不会让你失望。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考