MediaMTX 入门指南零依赖实时媒体服务器与媒体路由器核心能力全解析【免费下载链接】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 是一个开箱即用ready-to-use、零依赖zero-dependency的实时媒体服务器与媒体代理允许用户以多种主流协议发布、读取、代理、录制和回放实时音视频流。本文以官方入门文档为主体结合仓库源码与默认配置系统讲解 MediaMTX 的媒体路由器设计理念、完整功能矩阵、安装启动方式以及底层组件协作原理帮助读者快速掌握其核心能力并直接落地使用。什么是 MediaMTXMediaMTX被官方定义为media router媒体路由器它不承担复杂的媒体处理业务而是专注于把媒体流从一端高效地路由到另一端设计上以**效率efficiency与可移植性portability**为核心目标见 docs/1-kickoff/1-introduction.md。这一路由器定位可以从源码中得到印证。程序入口 main.go 极其简洁// main executable. package main import ( os github.com/bluenviron/mediamtx/internal/core ) func main() { s, ok : core.New(os.Args[1:]) if !ok { os.Exit(1) } s.Wait() }真正的能力全部封装在 internal/core/core.go 的Core结构中。从Core的字段即可看出 MediaMTX 的角色集合——它同时是媒体服务器、媒体代理、录制器与回放服务器type Core struct { // ... authManager *auth.Manager // 认证管理器 metrics *metrics.Metrics // 指标采集 pprof *pprof.PPROF // 性能剖析 recordCleaner *recordcleaner.Cleaner playbackServer *playback.Server // 回放服务器 pathManager *pathManager // 路径管理器 rtspServer *rtsp.Server // RTSP 服务器 rtspsServer *rtsp.Server // RTSPSTLS服务器 rtmpServer *rtmp.Server // RTMP 服务器 rtmpsServer *rtmp.Server // RTMPS 服务器 hlsServer *hls.Server // HLS/LL-HLS 服务器 webRTCServer *webrtc.Server // WebRTC 服务器 srtServer *srt.Server // SRT 服务器 moqServer *moq.Server // Media-over-QUIC 服务器 api *api.API // Control API confWatcher *confwatcher.ConfWatcher // 配置热重载监听器 // ... }围绕核心的pathManager路径管理器MediaMTX 组织起一整组协议服务器。其网络交互模型如下详见 docs/2-features/02-architecture.md作为客户端与配置中定义的外部源static source交互主动拉取流对外暴露一系列服务器允许客户端以 RTSP、RTMP、WebRTC、SRT、HLS 等协议发布或读取流对外提供回放服务器允许读取磁盘上已录制的流对外提供一系列管理服务metrics指标、pprof性能剖析、Control API。在内部整个服务围绕以下组件运转docs/2-features/02-architecture.md路径管理器path manager负责管理路径、执行认证、把客户端与路径关联起来路径paths每个路径承载一条流该流由单个发布者或单个外部源提供然后被广播给任意数量的读者录制器recorder负责把流写入磁盘。一切行为都由配置参数控制这些参数定义在配置文件中也可以通过环境变量注入如 Docker 部署中的MTX_前缀变量。核心功能全景MediaMTX 的主要特性与 README.md 及官方介绍一致覆盖了实时流媒体全链路发布、读取、自动协议转换、多路径、热重载、常开流、录制、回放、认证、转发、代理、控制 API、指标、性能监控与 hooks。下面逐项展开。发布流PublishMediaMTX 支持以Media-over-QUICMoQ、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TS、RTP等协议向服务器发布流发布端可以是FFmpeg、GStreamer、OBS Studio、Python、Golang、Unity、Web 浏览器、树莓派摄像头等。对应各类发布端的具体接入步骤可参考 发布流指南 以及更细分的客户端文档如 FFmpeg 发布、OBS Studio、树莓派摄像头、Web 浏览器 等。一个最典型的发布示例FFmpeg RTSPffmpeg -re -stream_loop -1 -i file.mp4 -c copy \ -f rtsp rtsp://localhost:8554/mystream读取流Read读者可以从服务器以Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS等协议读取流播放端涵盖FFmpeg、GStreamer、VLC、OBS Studio、Python、Golang、Unity、Web 浏览器等。同样以 RTSP 为例vlc --network-caching50 rtsp://localhost:8554/mystreamffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4更多播放端接入方式见 读取流指南 与 读取端协议文档 等分节。自动协议转换流在进入 MediaMTX 之后会被自动从一种协议转换为另一种协议。发布端用 RTSP 推流读者可以用 HLS 播放发布端用 WebRTC 推流读者可以用 RTMP 拉流。这正是媒体路由器的核心价值——接入与消费协议完全解耦。一次服务多条流路径PathsMediaMTX 通过**路径path**机制在同一服务器上同时服务多条流每条流对应一个独立的 URL 路径例如上例中的mystream。路径可以由发布者动态创建发布即创建也可以在配置文件中静态定义甚至用正则表达式匹配一组路径。从源码看路径由 internal/core/path_manager.go 中的pathManager统一管理其内部维护了一个paths map[string]*path并通过多个内部 channelchDescribe、chAddReader、chAddPublisher等串行化处理路径的查找、读者接入、发布者接入等操作。发布者与读者的连接、认证、流广播全部经由路径管理器汇合。配置热重载Hot ReloadingMediaMTX 支持在不断开现有客户端连接的情况下重新加载配置。这一机制的实现位于 internal/core/core.go启动时confWatcher会持续监听配置文件的变化当文件被修改主循环收到confChanged信号重新加载配置并调用reloadConf(newConf)reloadConf先通过closeResources(newConf)对比新旧配置只关闭真正发生变化的组件例如closeRTSPServer、closeHLSServer等布尔判定再通过createResources(false)创建新组件从而实现对存量客户端连接的最小影响。此外通过 Control API 修改配置如新增路径、修改全局参数同样会触发reloadConf日志中会打印reloading configuration (API request)。配置修改的详细说明见 配置指南。常开流Always-available Streams即使在发布者离线的情况下MediaMTX 也能提供始终可用的流。这在需要回放离线时段的场景下尤其有用——服务器可基于录制文件或离线编码的媒体文件持续向读者提供内容。实现细节见 常开流文档其底层涉及 internal/stream 下的离线子流offline sub-stream机制如offline_sub_stream.go与offline_h264.mp4、offline_av1.mp4等测试媒体文件所示。录制RecordMediaMTX 可以将流以 fMP4 或 MPEG-TS 格式录制到磁盘。录制相关的格式解析、分片、段文件生成代码位于 internal/recorderformat_fmp4.go、format_mpegts.go等而录制文件的自动清理由 internal/recordcleaner 的Cleaner负责——它仅在配置中存在路径设置了recordDeleteAfter时才会启动见 internal/core/core.go 中的atLeastOneRecordDeleteAfter判断。完整配置说明见 录制文档。回放Playback录制到磁盘的流可以通过回放服务器再次读取。回放服务器实现在 internal/playback支持 MP4 与 fMP4 两种 muxermuxer_mp4.go、muxer_fmp4.go并可通过onGet/onList钩子对接外部 HTTP API 定制回放行为。详见 回放文档。认证AuthenticationMediaMTX 提供三种认证方式见mediamtx.yml中authMethod的注释说明内部认证internal凭据直接存放在配置文件的authInternalUsers中外部 HTTP 服务认证每次认证请求调用外部 HTTP URLPOST响应码为 2xx 则放行外部 JWT 提供方认证凭据为外部身份服务器签发的令牌。认证还支持基于 IP 的访问控制ips字段与按路径/动作的细粒度授权permissions中的actionpath。认证核心实现位于 internal/authmanager.go、credentials.go、jwt_claims.go详细用法见 认证文档。转发与代理Forward Proxy转发Forward把流转发到其他服务器例如推送到另一个 MediaMTX 实例或第三方平台。转发目标配置在路径的forward参数中转发实现位于 internal/forward支持 RTSP、RTMP、SRT、WebRTC、MoQ 等目标详见 转发文档。代理Proxy把对服务器的请求代理到其他服务器详见 代理文档。Control APIMediaMTX 内置了用于控制服务器的 HTTP API可以查询路径、查看活动连接、动态修改配置等。API 定义位于 api/openapi.yaml其 Go 实现位于 internal/apiapi.go及各协议子模块。Control API 的完整接口说明见 控制 API 文档 与 参考手册。指标Metrics服务器以Prometheus 兼容格式暴露指标便于接入监控系统。指标实现位于 internal/metrics覆盖各协议服务器与路径/流级别的统计。详见 指标文档。性能监控PerformanceMediaMTX 内置pprof性能剖析支持可用于调查 CPU 与内存占用定位瓶颈。详见 性能文档。Hooks外部命令当客户端连接、断开、读取或发布流时MediaMTX 可以运行外部命令hooks。全局级的runOnConnect、runOnDisconnect以及路径级的runOnInit、runOnDemand、runOnReady、runOnRead、runOnUnready等钩子构成了一套完整的事件驱动扩展机制。钩子由 internal/externalcmd 统一调度执行事件定义见 internal/hooks。详见 hooks 文档。跨平台与零依赖MediaMTX兼容 Linux、Windows 和 macOS不依赖任何运行时或解释器——它就是一个独立的可执行文件。这一特性意味着下载解压、直接运行无需安装任何依赖环境特别适合嵌入式设备、边缘节点与快速试用的场景。快速上手安装与首次运行MediaMTX 提供了多种安装方式详见 安装文档最直接的是独立二进制方式从 Release 页面下载对应操作系统与架构的压缩包例如mediamtx_{version_tag}_linux_amd64.tar.gz解压直接运行./mediamtxWindows 下为mediamtx.exe可双击运行。若使用Docker部署官方镜像为bluenviron/mediamtx:1docker run --rm -it \ -e MTX_RTSPTRANSPORTStcp \ -e MTX_WEBRTCADDITIONALHOSTS192.168.x.x \ -p 8554:8554 \ -p 1935:1935 \ -p 8888:8888 \ -p 8889:8889 \ -p 8892:8892 \ -p 8890:8890/udp \ -p 8189:8189/udp \ -p 8892:8892/udp \ -p 8893:8893/udp \ bluenviron/mediamtx:1其中MTX_WEBRTCADDITIONALHOSTS需填客户端连接服务器所用的 IPMTX_RTSPTRANSPORTStcp用于禁用 RTSP 的 UDP 传输Docker 网络栈会改写 UDP 包的真实地址若需使用 UDP 传输则必须使用--networkhost。官方还提供1-ffmpeg内置 FFmpeg、1-rpi支持树莓派摄像头、1-ffmpeg-rpi三个镜像变体。默认情况下MediaMTX 会在当前目录及系统路径中查找配置文件。从 internal/core/core.go 可以看到其默认配置查找顺序var defaultConfPaths []string{ rtsp-simple-server.yml, mediamtx.yml, } var defaultConfPathsNotWin []string{ /usr/local/etc/mediamtx.yml, /usr/etc/mediamtx.yml, /etc/mediamtx/mediamtx.yml, }注意rtsp-simple-server.yml是 MediaMTX 前身项目的遗留配置名仍被兼容支持。如果找不到配置文件服务器会使用空配置启动并打印警告此时默认监听8554RTSP、1935RTMP、8888/8889HLS、8890WebRTC等端口。启动后即可体验发布→读取的完整链路基本用法文档用 FFmpeg 推流再用 VLC 或 FFmpeg 拉流验证。命令行还支持--version打印版本、--check-version检查新版本、--upgrade升级可执行文件等参数见 internal/core/core.go 中的cli结构。配置文件与参数体系所有行为都由 mediamtx.yml仓库根目录下的默认配置控制。该文件按功能分节组织例如全局通用参数logLevel日志级别error/warn/info/debug、logDestinationsstdout/file/syslog、readTimeout、writeTimeout、writeQueueSize出站包队列大小兼顾吞吐与内存、udpMaxPayloadSize默认 1452即以太网 MTU 1500 减去 IPv6 与 UDP 头部、udpReadBufferSize、runOnConnect/runOnDisconnect等认证参数authMethodinternal/HTTP/JWT以及authInternalUsers下的用户、密码、IP 白名单与权限列表各协议服务器参数rtsp、rtmp、hls、webrtc、srt、moq等小节路径参数paths小节用于静态定义路径及其录制、转发、发布/读取权限等行为。在 Docker 等场景下所有参数都可以通过环境变量注入规则为MTX_前缀加上大写化的参数路径例如MTX_RTSPTRANSPORTS、MTX_WEBRTCADDITIONALHOSTS这也是前文 Docker 示例中环境变量写法的由来。完整的参数表见 配置文件参考。深入源码启动流程与组件协作MediaMTX 的启动与运行可以概括为三个阶段internal/core/core.go解析参数与加载配置core.New通过kong解析命令行参数随后conf.Load在默认路径中加载配置失败则使用空配置创建资源createResources(true)依据配置依次创建日志器、认证管理器、metrics、pprof、录制清理器、回放服务器、路径管理器、各协议服务器RTSP/RTSPS、RTMP/RTMPS、HLS、WebRTC、SRT、MoQ以及 Control API最后启动confWatcher监听配置文件进入主循环run()在一个for select循环中同时监听四类事件——配置文件变更、Control API 的配置修改请求、中断信号SIGINT/SIGTERM与上下文取消。收到配置变更即走reloadConf热重载流程收到信号则优雅关闭全部资源。其中路径管理器是所有媒体流的中枢internal/core/path_manager.go 中的pathManager持有一份路径配置映射与运行时路径映射对外提供认证、路径描述、读者接入、发布者接入等接口并把流量分发给各协议服务器如 HLS 服务器通过chSetHLSServer与路径管理器协作。这也印证了官方介绍中的定位MediaMTX 本质上是把发布者—路径—读者三层关系高效组织起来的媒体路由器。参考资料导航Kickoff 文档首页安装、升级入口发布流指南 与 读取流指南配置文档 与 配置文件参考架构说明含架构图与组件职责录制、回放、认证、转发、代理、控制 API、指标、hooks 等专项文档【免费下载链接】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 入门指南：零依赖实时媒体服务器与“媒体路由器“核心能力全解析
MediaMTX 入门指南零依赖实时媒体服务器与媒体路由器核心能力全解析【免费下载链接】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 是一个开箱即用ready-to-use、零依赖zero-dependency的实时媒体服务器与媒体代理允许用户以多种主流协议发布、读取、代理、录制和回放实时音视频流。本文以官方入门文档为主体结合仓库源码与默认配置系统讲解 MediaMTX 的媒体路由器设计理念、完整功能矩阵、安装启动方式以及底层组件协作原理帮助读者快速掌握其核心能力并直接落地使用。什么是 MediaMTXMediaMTX被官方定义为media router媒体路由器它不承担复杂的媒体处理业务而是专注于把媒体流从一端高效地路由到另一端设计上以**效率efficiency与可移植性portability**为核心目标见 docs/1-kickoff/1-introduction.md。这一路由器定位可以从源码中得到印证。程序入口 main.go 极其简洁// main executable. package main import ( os github.com/bluenviron/mediamtx/internal/core ) func main() { s, ok : core.New(os.Args[1:]) if !ok { os.Exit(1) } s.Wait() }真正的能力全部封装在 internal/core/core.go 的Core结构中。从Core的字段即可看出 MediaMTX 的角色集合——它同时是媒体服务器、媒体代理、录制器与回放服务器type Core struct { // ... authManager *auth.Manager // 认证管理器 metrics *metrics.Metrics // 指标采集 pprof *pprof.PPROF // 性能剖析 recordCleaner *recordcleaner.Cleaner playbackServer *playback.Server // 回放服务器 pathManager *pathManager // 路径管理器 rtspServer *rtsp.Server // RTSP 服务器 rtspsServer *rtsp.Server // RTSPSTLS服务器 rtmpServer *rtmp.Server // RTMP 服务器 rtmpsServer *rtmp.Server // RTMPS 服务器 hlsServer *hls.Server // HLS/LL-HLS 服务器 webRTCServer *webrtc.Server // WebRTC 服务器 srtServer *srt.Server // SRT 服务器 moqServer *moq.Server // Media-over-QUIC 服务器 api *api.API // Control API confWatcher *confwatcher.ConfWatcher // 配置热重载监听器 // ... }围绕核心的pathManager路径管理器MediaMTX 组织起一整组协议服务器。其网络交互模型如下详见 docs/2-features/02-architecture.md作为客户端与配置中定义的外部源static source交互主动拉取流对外暴露一系列服务器允许客户端以 RTSP、RTMP、WebRTC、SRT、HLS 等协议发布或读取流对外提供回放服务器允许读取磁盘上已录制的流对外提供一系列管理服务metrics指标、pprof性能剖析、Control API。在内部整个服务围绕以下组件运转docs/2-features/02-architecture.md路径管理器path manager负责管理路径、执行认证、把客户端与路径关联起来路径paths每个路径承载一条流该流由单个发布者或单个外部源提供然后被广播给任意数量的读者录制器recorder负责把流写入磁盘。一切行为都由配置参数控制这些参数定义在配置文件中也可以通过环境变量注入如 Docker 部署中的MTX_前缀变量。核心功能全景MediaMTX 的主要特性与 README.md 及官方介绍一致覆盖了实时流媒体全链路发布、读取、自动协议转换、多路径、热重载、常开流、录制、回放、认证、转发、代理、控制 API、指标、性能监控与 hooks。下面逐项展开。发布流PublishMediaMTX 支持以Media-over-QUICMoQ、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TS、RTP等协议向服务器发布流发布端可以是FFmpeg、GStreamer、OBS Studio、Python、Golang、Unity、Web 浏览器、树莓派摄像头等。对应各类发布端的具体接入步骤可参考 发布流指南 以及更细分的客户端文档如 FFmpeg 发布、OBS Studio、树莓派摄像头、Web 浏览器 等。一个最典型的发布示例FFmpeg RTSPffmpeg -re -stream_loop -1 -i file.mp4 -c copy \ -f rtsp rtsp://localhost:8554/mystream读取流Read读者可以从服务器以Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS等协议读取流播放端涵盖FFmpeg、GStreamer、VLC、OBS Studio、Python、Golang、Unity、Web 浏览器等。同样以 RTSP 为例vlc --network-caching50 rtsp://localhost:8554/mystreamffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4更多播放端接入方式见 读取流指南 与 读取端协议文档 等分节。自动协议转换流在进入 MediaMTX 之后会被自动从一种协议转换为另一种协议。发布端用 RTSP 推流读者可以用 HLS 播放发布端用 WebRTC 推流读者可以用 RTMP 拉流。这正是媒体路由器的核心价值——接入与消费协议完全解耦。一次服务多条流路径PathsMediaMTX 通过**路径path**机制在同一服务器上同时服务多条流每条流对应一个独立的 URL 路径例如上例中的mystream。路径可以由发布者动态创建发布即创建也可以在配置文件中静态定义甚至用正则表达式匹配一组路径。从源码看路径由 internal/core/path_manager.go 中的pathManager统一管理其内部维护了一个paths map[string]*path并通过多个内部 channelchDescribe、chAddReader、chAddPublisher等串行化处理路径的查找、读者接入、发布者接入等操作。发布者与读者的连接、认证、流广播全部经由路径管理器汇合。配置热重载Hot ReloadingMediaMTX 支持在不断开现有客户端连接的情况下重新加载配置。这一机制的实现位于 internal/core/core.go启动时confWatcher会持续监听配置文件的变化当文件被修改主循环收到confChanged信号重新加载配置并调用reloadConf(newConf)reloadConf先通过closeResources(newConf)对比新旧配置只关闭真正发生变化的组件例如closeRTSPServer、closeHLSServer等布尔判定再通过createResources(false)创建新组件从而实现对存量客户端连接的最小影响。此外通过 Control API 修改配置如新增路径、修改全局参数同样会触发reloadConf日志中会打印reloading configuration (API request)。配置修改的详细说明见 配置指南。常开流Always-available Streams即使在发布者离线的情况下MediaMTX 也能提供始终可用的流。这在需要回放离线时段的场景下尤其有用——服务器可基于录制文件或离线编码的媒体文件持续向读者提供内容。实现细节见 常开流文档其底层涉及 internal/stream 下的离线子流offline sub-stream机制如offline_sub_stream.go与offline_h264.mp4、offline_av1.mp4等测试媒体文件所示。录制RecordMediaMTX 可以将流以 fMP4 或 MPEG-TS 格式录制到磁盘。录制相关的格式解析、分片、段文件生成代码位于 internal/recorderformat_fmp4.go、format_mpegts.go等而录制文件的自动清理由 internal/recordcleaner 的Cleaner负责——它仅在配置中存在路径设置了recordDeleteAfter时才会启动见 internal/core/core.go 中的atLeastOneRecordDeleteAfter判断。完整配置说明见 录制文档。回放Playback录制到磁盘的流可以通过回放服务器再次读取。回放服务器实现在 internal/playback支持 MP4 与 fMP4 两种 muxermuxer_mp4.go、muxer_fmp4.go并可通过onGet/onList钩子对接外部 HTTP API 定制回放行为。详见 回放文档。认证AuthenticationMediaMTX 提供三种认证方式见mediamtx.yml中authMethod的注释说明内部认证internal凭据直接存放在配置文件的authInternalUsers中外部 HTTP 服务认证每次认证请求调用外部 HTTP URLPOST响应码为 2xx 则放行外部 JWT 提供方认证凭据为外部身份服务器签发的令牌。认证还支持基于 IP 的访问控制ips字段与按路径/动作的细粒度授权permissions中的actionpath。认证核心实现位于 internal/authmanager.go、credentials.go、jwt_claims.go详细用法见 认证文档。转发与代理Forward Proxy转发Forward把流转发到其他服务器例如推送到另一个 MediaMTX 实例或第三方平台。转发目标配置在路径的forward参数中转发实现位于 internal/forward支持 RTSP、RTMP、SRT、WebRTC、MoQ 等目标详见 转发文档。代理Proxy把对服务器的请求代理到其他服务器详见 代理文档。Control APIMediaMTX 内置了用于控制服务器的 HTTP API可以查询路径、查看活动连接、动态修改配置等。API 定义位于 api/openapi.yaml其 Go 实现位于 internal/apiapi.go及各协议子模块。Control API 的完整接口说明见 控制 API 文档 与 参考手册。指标Metrics服务器以Prometheus 兼容格式暴露指标便于接入监控系统。指标实现位于 internal/metrics覆盖各协议服务器与路径/流级别的统计。详见 指标文档。性能监控PerformanceMediaMTX 内置pprof性能剖析支持可用于调查 CPU 与内存占用定位瓶颈。详见 性能文档。Hooks外部命令当客户端连接、断开、读取或发布流时MediaMTX 可以运行外部命令hooks。全局级的runOnConnect、runOnDisconnect以及路径级的runOnInit、runOnDemand、runOnReady、runOnRead、runOnUnready等钩子构成了一套完整的事件驱动扩展机制。钩子由 internal/externalcmd 统一调度执行事件定义见 internal/hooks。详见 hooks 文档。跨平台与零依赖MediaMTX兼容 Linux、Windows 和 macOS不依赖任何运行时或解释器——它就是一个独立的可执行文件。这一特性意味着下载解压、直接运行无需安装任何依赖环境特别适合嵌入式设备、边缘节点与快速试用的场景。快速上手安装与首次运行MediaMTX 提供了多种安装方式详见 安装文档最直接的是独立二进制方式从 Release 页面下载对应操作系统与架构的压缩包例如mediamtx_{version_tag}_linux_amd64.tar.gz解压直接运行./mediamtxWindows 下为mediamtx.exe可双击运行。若使用Docker部署官方镜像为bluenviron/mediamtx:1docker run --rm -it \ -e MTX_RTSPTRANSPORTStcp \ -e MTX_WEBRTCADDITIONALHOSTS192.168.x.x \ -p 8554:8554 \ -p 1935:1935 \ -p 8888:8888 \ -p 8889:8889 \ -p 8892:8892 \ -p 8890:8890/udp \ -p 8189:8189/udp \ -p 8892:8892/udp \ -p 8893:8893/udp \ bluenviron/mediamtx:1其中MTX_WEBRTCADDITIONALHOSTS需填客户端连接服务器所用的 IPMTX_RTSPTRANSPORTStcp用于禁用 RTSP 的 UDP 传输Docker 网络栈会改写 UDP 包的真实地址若需使用 UDP 传输则必须使用--networkhost。官方还提供1-ffmpeg内置 FFmpeg、1-rpi支持树莓派摄像头、1-ffmpeg-rpi三个镜像变体。默认情况下MediaMTX 会在当前目录及系统路径中查找配置文件。从 internal/core/core.go 可以看到其默认配置查找顺序var defaultConfPaths []string{ rtsp-simple-server.yml, mediamtx.yml, } var defaultConfPathsNotWin []string{ /usr/local/etc/mediamtx.yml, /usr/etc/mediamtx.yml, /etc/mediamtx/mediamtx.yml, }注意rtsp-simple-server.yml是 MediaMTX 前身项目的遗留配置名仍被兼容支持。如果找不到配置文件服务器会使用空配置启动并打印警告此时默认监听8554RTSP、1935RTMP、8888/8889HLS、8890WebRTC等端口。启动后即可体验发布→读取的完整链路基本用法文档用 FFmpeg 推流再用 VLC 或 FFmpeg 拉流验证。命令行还支持--version打印版本、--check-version检查新版本、--upgrade升级可执行文件等参数见 internal/core/core.go 中的cli结构。配置文件与参数体系所有行为都由 mediamtx.yml仓库根目录下的默认配置控制。该文件按功能分节组织例如全局通用参数logLevel日志级别error/warn/info/debug、logDestinationsstdout/file/syslog、readTimeout、writeTimeout、writeQueueSize出站包队列大小兼顾吞吐与内存、udpMaxPayloadSize默认 1452即以太网 MTU 1500 减去 IPv6 与 UDP 头部、udpReadBufferSize、runOnConnect/runOnDisconnect等认证参数authMethodinternal/HTTP/JWT以及authInternalUsers下的用户、密码、IP 白名单与权限列表各协议服务器参数rtsp、rtmp、hls、webrtc、srt、moq等小节路径参数paths小节用于静态定义路径及其录制、转发、发布/读取权限等行为。在 Docker 等场景下所有参数都可以通过环境变量注入规则为MTX_前缀加上大写化的参数路径例如MTX_RTSPTRANSPORTS、MTX_WEBRTCADDITIONALHOSTS这也是前文 Docker 示例中环境变量写法的由来。完整的参数表见 配置文件参考。深入源码启动流程与组件协作MediaMTX 的启动与运行可以概括为三个阶段internal/core/core.go解析参数与加载配置core.New通过kong解析命令行参数随后conf.Load在默认路径中加载配置失败则使用空配置创建资源createResources(true)依据配置依次创建日志器、认证管理器、metrics、pprof、录制清理器、回放服务器、路径管理器、各协议服务器RTSP/RTSPS、RTMP/RTMPS、HLS、WebRTC、SRT、MoQ以及 Control API最后启动confWatcher监听配置文件进入主循环run()在一个for select循环中同时监听四类事件——配置文件变更、Control API 的配置修改请求、中断信号SIGINT/SIGTERM与上下文取消。收到配置变更即走reloadConf热重载流程收到信号则优雅关闭全部资源。其中路径管理器是所有媒体流的中枢internal/core/path_manager.go 中的pathManager持有一份路径配置映射与运行时路径映射对外提供认证、路径描述、读者接入、发布者接入等接口并把流量分发给各协议服务器如 HLS 服务器通过chSetHLSServer与路径管理器协作。这也印证了官方介绍中的定位MediaMTX 本质上是把发布者—路径—读者三层关系高效组织起来的媒体路由器。参考资料导航Kickoff 文档首页安装、升级入口发布流指南 与 读取流指南配置文档 与 配置文件参考架构说明含架构图与组件职责录制、回放、认证、转发、代理、控制 API、指标、hooks 等专项文档【免费下载链接】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），仅供参考