MediaMTX 实战指南RTSP 摄像头流如何实时播到浏览器里【免费下载链接】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/mediamtxMediaMTX 是一个开箱即用、零依赖的实时流媒体服务器你把它当成一台媒体路由器摄像头、推流软件从一边进来网页、播放器从另一边读走它负责中间的接入、分发、录制和回放。它用 Go 写成编译后是一个独立可执行文件支持 RTSP、RTMP、WebRTC、SRT、LL-HLS、MPEG-TS、RTP 乃至较新的 Media-over-QUIC 协议而且不同协议之间可以自动互转不需要你额外部署转码服务。协议不匹配才是直播链路里最常被低估的问题先说一个很常见的卡点手边的设备只会说一种方言。摄像头普遍吐 RTSP 或 SRTOBS 之类的推流软件习惯用 RTMP而现代网页端真正流畅的实时播放走的是 WebRTC。传统做法是中间垫几台服务器做协议转换链路越长延迟越高运维也越重。MediaMTX 的思路是把这件事收敛到一个进程里。它内部由三块组成负责路径管理和认证的 path manager、承载各路流媒体的 path每个 path 对应一条独立流由一个发布端提供、同时分发给多个读取端、以及把流落盘的 recorder。所有协议适配都收敛在内部对外你只需要面对一个 URL 一个路径名。各协议对应的默认端口可以先记下来后面配防火墙、Docker 映射都会用到协议默认端口说明RTSP8554摄像头最常用RTMP1935OBS 等推流软件常用HLS8888含低延迟 HLSLL-HLS可挂 CDNWebRTC8889 8189/UDP浏览器低延迟播放UDP 口别忘了SRT8890/UDP抗弱网Media-over-QUIC8892 / 8893/UDP基于 QUIC 的新协议这些端口都写在mediamtx.yml里可按需调整具体取值以配置文件内注释和官方文档为准。三步接入装好、写一条路径、打开浏览器第一步把服务跑起来两种主流方式按你的环境选。Docker 方式适合生产docker run --rm -it \ -e MTX_RTSPTRANSPORTStcp \ -p 8554:8554 -p 1935:1935 -p 8888:8888 \ -p 8889:8889 -p 8890:8890/udp -p 8189:8189/udp \ bluenviron/mediamtx:1注意那行MTX_RTSPTRANSPORTStcpDocker 的网络栈有时会改写 UDP 包的源地址把 RTSP 的 UDP 传输关掉最省事如果你用--networkhost模式则不需要。二进制方式适合先试水到项目 Releases 页面下载对应平台的压缩包解压后直接执行./mediamtxWindows 下为mediamtx.exe它会读取同目录下的mediamtx.yml启动。第二步在配置里声明你的摄像头你真正需要动的往往只是paths这一段。以一台 RTSP 摄像头为例paths: cam1: source: rtsp://admin:password192.168.1.100:554/stream1就这么一条cam1是路径名source是流的来源。来源还可以是 RTMP、SRT、HLS、RTP、UDP 的 MPEG-TS甚至是另一台 MediaMTX——也就是说级联部署时从上游拉流和从摄像头拉流用的是同一种写法。改完配置不用重启MediaMTX 支持热加载保存文件即生效已连接的客户端不会断开。第三步用三种方式验证推一个假流也行用 VLC 拉个公开测试源推到rtsp://你的IP:8554/cam1也可以。然后分别验证浏览器直接访问http://你的IP:8889/cam1这是内置的 WebRTC 播放页延迟最低访问http://你的IP:8888/cam1/index.m3u8拿到 HLS 播放列表也可以直接打开http://你的IP:8888/cam1/看内置播放页用 VLC 播放rtsp://你的IP:8554/cam1验证 RTSP 读取。同一条流三种协议读出来这就是它作为媒体路由器的全部意义发布端只推一次读取端想用哪个协议就用哪个。不止看流把录像、回放和权限一次配好录像与自动清理很多场景安防、课堂记录要求流存得下来。在pathDefaults下开启即可pathDefaults: record: yes recordFormat: fmp4 recordDeleteAfter: 1d录像默认按小时切段、存到./recordings/下recordDeleteAfter控制保留多久设为0s则永不自动删除。recordPartDuration默认 1s决定了断电等异常下最多丢多久的数据可以理解为你的 RPO 下限。给历史录像一个播放入口录完还要能给人看。开启回放服务后它会监听 9996 端口提供列出录像时间段的接口和按时间段下载录像的接口返回的 fMP4 流可以直接塞进video标签playback: yes playbackAddress: :9996具体接口参数按路径、起始时间、时长查询见仓库docs/2-features/10-playback.md以官方文档为准。权限别忘了它默认对任何人敞开这是新手最容易忽略的一条默认配置里存在一个user: any的条目允许任意匿名用户发布、读取、回放所有路径。内网试用无所谓但暴露到公网前必须改掉。认证支持 internal账号写在配置文件里、外部 HTTP 校验、JWT 三种模式authMethod字段切换路径级还可以用maxReaders限制读取方数量。生产环境建议至少把 internal 用户收窄到具体 IP 段并设置密码。上线前的几个容易踩的坑UDP 端口漏配WebRTC 依赖 8189/UDPSRT 依赖 8890/UDPRTSP 的 UDP 传输还需要 8000-8005 一段。防火墙和 Docker 映射里漏掉 UDP症状往往是TCP 的 RTSP 正常、WebRTC 死活连不上。Docker 下 WebRTC 连不通容器对外暴露的 IP 和客户端实际要连的 IP 不一致时需要设置webrtcAdditionalHosts或MTX_WEBRTCADDITIONALHOSTS环境变量把客户端真正能到达的地址告诉它。HLS 延迟预期HLS 天生是分段播放的协议即便开启hlsVariant: lowLatency也只是低延迟而非实时。要毫秒级延迟走 WebRTC 或 SRTHLS 更适合做广兼容和 CDN 分发。排查手段先备好出问题时把logLevel调到debug再开dumpPackets把原始包落盘分析需要量化监控就打开metrics: yes9998 端口Prometheus 兼容格式。仓库里docs/2-features/23-performance.md有专门的性能排查文档值得先翻一遍。下一步可以做什么把一条真实摄像头流完整跑通接入 → WebRTC 播放 → 录制 → 回放走完这个闭环再谈扩展试一下发布用 A 协议、读取用 B 协议的组合比如 SRT 发布 WebRTC 读取感受弱网场景下 SRT 的作用研究runOnDemand、runOnRead等 hooks它们让你能在有人来读流时自动拉起 ffmpeg 推流是搭建按需直播系统的利器想深入实现细节的话直接看仓库源码路径管理在 internal/core/path_manager.go各协议适配在 internal/protocols/ 下的子目录里文档在 docs/。如果你需要拿到源码研究或二次开发仓库地址是https://gitcode.com/GitHub_Trending/me/mediamtx。最后提醒一句MediaMTX 配置项非常多本文只覆盖了最常用的一小块动手前把mediamtx.yml里的注释通读一遍、拿不准的参数以官方文档为准会比到处找零散教程省时间得多。【免费下载链接】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），仅供参考 MediaMTX 实战指南：RTSP 摄像头流如何实时播到浏览器里
MediaMTX 实战指南RTSP 摄像头流如何实时播到浏览器里【免费下载链接】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/mediamtxMediaMTX 是一个开箱即用、零依赖的实时流媒体服务器你把它当成一台媒体路由器摄像头、推流软件从一边进来网页、播放器从另一边读走它负责中间的接入、分发、录制和回放。它用 Go 写成编译后是一个独立可执行文件支持 RTSP、RTMP、WebRTC、SRT、LL-HLS、MPEG-TS、RTP 乃至较新的 Media-over-QUIC 协议而且不同协议之间可以自动互转不需要你额外部署转码服务。协议不匹配才是直播链路里最常被低估的问题先说一个很常见的卡点手边的设备只会说一种方言。摄像头普遍吐 RTSP 或 SRTOBS 之类的推流软件习惯用 RTMP而现代网页端真正流畅的实时播放走的是 WebRTC。传统做法是中间垫几台服务器做协议转换链路越长延迟越高运维也越重。MediaMTX 的思路是把这件事收敛到一个进程里。它内部由三块组成负责路径管理和认证的 path manager、承载各路流媒体的 path每个 path 对应一条独立流由一个发布端提供、同时分发给多个读取端、以及把流落盘的 recorder。所有协议适配都收敛在内部对外你只需要面对一个 URL 一个路径名。各协议对应的默认端口可以先记下来后面配防火墙、Docker 映射都会用到协议默认端口说明RTSP8554摄像头最常用RTMP1935OBS 等推流软件常用HLS8888含低延迟 HLSLL-HLS可挂 CDNWebRTC8889 8189/UDP浏览器低延迟播放UDP 口别忘了SRT8890/UDP抗弱网Media-over-QUIC8892 / 8893/UDP基于 QUIC 的新协议这些端口都写在mediamtx.yml里可按需调整具体取值以配置文件内注释和官方文档为准。三步接入装好、写一条路径、打开浏览器第一步把服务跑起来两种主流方式按你的环境选。Docker 方式适合生产docker run --rm -it \ -e MTX_RTSPTRANSPORTStcp \ -p 8554:8554 -p 1935:1935 -p 8888:8888 \ -p 8889:8889 -p 8890:8890/udp -p 8189:8189/udp \ bluenviron/mediamtx:1注意那行MTX_RTSPTRANSPORTStcpDocker 的网络栈有时会改写 UDP 包的源地址把 RTSP 的 UDP 传输关掉最省事如果你用--networkhost模式则不需要。二进制方式适合先试水到项目 Releases 页面下载对应平台的压缩包解压后直接执行./mediamtxWindows 下为mediamtx.exe它会读取同目录下的mediamtx.yml启动。第二步在配置里声明你的摄像头你真正需要动的往往只是paths这一段。以一台 RTSP 摄像头为例paths: cam1: source: rtsp://admin:password192.168.1.100:554/stream1就这么一条cam1是路径名source是流的来源。来源还可以是 RTMP、SRT、HLS、RTP、UDP 的 MPEG-TS甚至是另一台 MediaMTX——也就是说级联部署时从上游拉流和从摄像头拉流用的是同一种写法。改完配置不用重启MediaMTX 支持热加载保存文件即生效已连接的客户端不会断开。第三步用三种方式验证推一个假流也行用 VLC 拉个公开测试源推到rtsp://你的IP:8554/cam1也可以。然后分别验证浏览器直接访问http://你的IP:8889/cam1这是内置的 WebRTC 播放页延迟最低访问http://你的IP:8888/cam1/index.m3u8拿到 HLS 播放列表也可以直接打开http://你的IP:8888/cam1/看内置播放页用 VLC 播放rtsp://你的IP:8554/cam1验证 RTSP 读取。同一条流三种协议读出来这就是它作为媒体路由器的全部意义发布端只推一次读取端想用哪个协议就用哪个。不止看流把录像、回放和权限一次配好录像与自动清理很多场景安防、课堂记录要求流存得下来。在pathDefaults下开启即可pathDefaults: record: yes recordFormat: fmp4 recordDeleteAfter: 1d录像默认按小时切段、存到./recordings/下recordDeleteAfter控制保留多久设为0s则永不自动删除。recordPartDuration默认 1s决定了断电等异常下最多丢多久的数据可以理解为你的 RPO 下限。给历史录像一个播放入口录完还要能给人看。开启回放服务后它会监听 9996 端口提供列出录像时间段的接口和按时间段下载录像的接口返回的 fMP4 流可以直接塞进video标签playback: yes playbackAddress: :9996具体接口参数按路径、起始时间、时长查询见仓库docs/2-features/10-playback.md以官方文档为准。权限别忘了它默认对任何人敞开这是新手最容易忽略的一条默认配置里存在一个user: any的条目允许任意匿名用户发布、读取、回放所有路径。内网试用无所谓但暴露到公网前必须改掉。认证支持 internal账号写在配置文件里、外部 HTTP 校验、JWT 三种模式authMethod字段切换路径级还可以用maxReaders限制读取方数量。生产环境建议至少把 internal 用户收窄到具体 IP 段并设置密码。上线前的几个容易踩的坑UDP 端口漏配WebRTC 依赖 8189/UDPSRT 依赖 8890/UDPRTSP 的 UDP 传输还需要 8000-8005 一段。防火墙和 Docker 映射里漏掉 UDP症状往往是TCP 的 RTSP 正常、WebRTC 死活连不上。Docker 下 WebRTC 连不通容器对外暴露的 IP 和客户端实际要连的 IP 不一致时需要设置webrtcAdditionalHosts或MTX_WEBRTCADDITIONALHOSTS环境变量把客户端真正能到达的地址告诉它。HLS 延迟预期HLS 天生是分段播放的协议即便开启hlsVariant: lowLatency也只是低延迟而非实时。要毫秒级延迟走 WebRTC 或 SRTHLS 更适合做广兼容和 CDN 分发。排查手段先备好出问题时把logLevel调到debug再开dumpPackets把原始包落盘分析需要量化监控就打开metrics: yes9998 端口Prometheus 兼容格式。仓库里docs/2-features/23-performance.md有专门的性能排查文档值得先翻一遍。下一步可以做什么把一条真实摄像头流完整跑通接入 → WebRTC 播放 → 录制 → 回放走完这个闭环再谈扩展试一下发布用 A 协议、读取用 B 协议的组合比如 SRT 发布 WebRTC 读取感受弱网场景下 SRT 的作用研究runOnDemand、runOnRead等 hooks它们让你能在有人来读流时自动拉起 ffmpeg 推流是搭建按需直播系统的利器想深入实现细节的话直接看仓库源码路径管理在 internal/core/path_manager.go各协议适配在 internal/protocols/ 下的子目录里文档在 docs/。如果你需要拿到源码研究或二次开发仓库地址是https://gitcode.com/GitHub_Trending/me/mediamtx。最后提醒一句MediaMTX 配置项非常多本文只覆盖了最常用的一小块动手前把mediamtx.yml里的注释通读一遍、拿不准的参数以官方文档为准会比到处找零散教程省时间得多。【免费下载链接】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），仅供参考