全协议媒体服务器云部署MediaMTX 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大促前一晚推流端突然涌入单机出口带宽被打满有人想加只读副本分流滚动升级时又碰了端口整条流断掉。流媒体服务和普通 Web 服务不同每个读者都挂着一条长连接并发量直接决定资源占用。这篇实战以开源的 MediaMTX 为例讲清楚如何把它部署成一台支持 RTSP、RTMP、WebRTC、SRT、HLS 的媒体服务器并在阿里云上完成容器化部署、配置调优与高可用设计配置均可直接照抄。一、先想清楚单机还是集群这一节回答一个问题你的流量规模到底需要几台机器。MediaMTX 是零依赖的纯转发型媒体服务器不做转码协议间自动转换比如相机走 RTSP 推上来浏览器用 WebRTC 播放。官方文档明确指出这类负载的瓶颈几乎总是服务器到读者的带宽所以扩容基本是横向加机器。判断条件建议并发读者数百以内、单可用区单机即可2C4G 起步先跑通读者规模大或要求多可用区容灾origin 只读副本集群第五节详述需要转码、压缩超出 MediaMTX 职责范围用 docker/ffmpeg.Dockerfile 构建的镜像或独立转码链路一句话原则先单机验证带宽先于 CPU 成为瓶颈时再谈集群。二、跑起来最小可用部署这一节只给一条最短路径选镜像、一条启动命令、一份最小配置。镜像怎么选生产直接用官方标准镜像它基于 docker/standard.Dockerfile用 scratch 打底、无系统依赖且通过TARGETPLATFORM在构建时自动从 amd64、armv6、armv7、arm64 四个预编译二进制中挑出匹配架构——ECS 的 x86 实例默认 amd64ARM 架构实例如倚天/Graviton 系列拉的就是 arm64不需要自己交叉编译。docker run -d --name mediamtx --restart always \ --network host \ -v $PWD/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:latest--network host可以让容器直接使用宿主机端口省掉 NAT 转发UDP 密集的媒体流量在这种模式下也更省事。最小配置仓库自带的 mediamtx.yml 默认值就能跑只需打开两样东西、加一条测试路数api: yes # 控制API默认关闭 metrics: yes # Prometheus指标默认关闭 paths: cam1: source: rtmp://10.0.0.5:1935/cam1 # 按需代理一路上游源流三、调稳定配置与参数这一节只列云环境里真正值得动的 5 个参数其余保持默认。参数示例取值为什么调webrtcAdditionalHosts[你的公网IP]WebRTC 的 SDP 需要声明对外可达地址不配公网 IP 时浏览器端经常连不回来udpReadBufferSize2097152默认跟随操作系统调大 UDP 接收缓冲区可明显降低高峰期的丢包maxReaders100默认 0 表示不限给单路流设上限防止某一路突发读者吃光资源sourceOnDemandyes有读者才去拉源闲置相机不占上游带宽sourceOnDemandCloseAfter30s配合上一项无读者一段时间自动关源默认 10s日志容器里建议logDestinations: [stdout]把轮转交给容器平台加logStructured: true输出 JSONL方便日志服务采集。环境变量注入每个配置项都能用MTX_大写参数名覆盖例如MTX_RTSPADDRESS:8554。多套环境用同一份配置文件、只改环境变量Kubernetes 部署时尤其好用。四、看得见监控与健康检查这一节解决我怎么知道它还活着、跑得好不好两个内置入口都不用加旁路组件。健康检查开启api: yes后Control API 监听:9997。用下面这条命令作为探针即可返回 200 即视为存活curl -f http://localhost:9997/v3/paths/list完整接口见 api/openapi.yaml路径的增删改查、配置热更新都走这套 REST API。性能指标开启metrics: yes后:9998/metrics输出 Prometheus 格式指标。挑 4 个最值得盯的指标含义paths{name,state}各路数的状态offline/ready流掉线时最先变化paths_readers每路流的并发读者数扩容的首要依据paths_inbound_bytes入站字节数反映推流端上行是否正常paths_outbound_bytes出站字节数读者侧带宽消耗成本核算就看它五、扛得住高可用与弹性这一节回答单点挂掉怎么办、流量涨了怎么扛。高可用的正确姿势是读写分离而不是无脑多副本。媒体流是有状态的官方推荐的水平扩展方式是只读副本推流只进 origin 实例副本通过一条代理路数从 origin 拉流再服务给读者paths: ~^(.)$: source: rtsp://origin内网域名:8554/$G1 sourceOnDemand: yes负载均衡的选型有讲究RTSP/RTMP/SRT 读者走四层 LBHLS/WebRTC 读者走七层 LB 并开启 sticky sessions因为一次会话由多个连续请求组成。副本 Pod 再加跨可用区打散spec: replicas: 3 template: spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: {app: mediamtx}扩缩容起步阶段用 CPU 阈值即可接上 Prometheus Adapter 后建议改用paths_readers的平均值做副本数指标比 CPU 更贴近业务真实负载apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: mediamtx} spec: scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: mediamtx} minReplicas: 2 maxReplicas: 6 metrics: - type: Resource resource: name: cpu target: {type: Utilization, averageUtilization: 70}安全加固上线前逐条过rtspEncryption: yes、webrtcEncryption: yes媒体链路全加密authMethod从内置账号切到 JWT配authJWTJWKS或外部 HTTP 鉴权复用现有身份体系用authInternalUsers给关键路数收紧读/写权限必要时限定来源 IPapiEncryption: yes且 9997/9998 两个端口只暴露在内部网络安全组按协议放行端口并限制 UDP 端口范围公网入口只留必要的几个上线前自查清单安全组是否按协议放行 8554/8888/8889/8890 及对应 UDP 范围webrtcAdditionalHosts是否已填公网地址浏览器端能否拉到画面curl :9997/v3/paths/list与:9998/metrics是否按预期返回匿名推流是否已被鉴权配置拒绝日志采集与录像目录recordings/磁盘清理策略是否就位规模再上一个台阶后值得深入的两件事只读副本的多 region 部署细节以及alwaysSource常备流与录像回放playback的组合玩法。【免费下载链接】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/WebRTC 容器化实战指南
全协议媒体服务器云部署MediaMTX 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大促前一晚推流端突然涌入单机出口带宽被打满有人想加只读副本分流滚动升级时又碰了端口整条流断掉。流媒体服务和普通 Web 服务不同每个读者都挂着一条长连接并发量直接决定资源占用。这篇实战以开源的 MediaMTX 为例讲清楚如何把它部署成一台支持 RTSP、RTMP、WebRTC、SRT、HLS 的媒体服务器并在阿里云上完成容器化部署、配置调优与高可用设计配置均可直接照抄。一、先想清楚单机还是集群这一节回答一个问题你的流量规模到底需要几台机器。MediaMTX 是零依赖的纯转发型媒体服务器不做转码协议间自动转换比如相机走 RTSP 推上来浏览器用 WebRTC 播放。官方文档明确指出这类负载的瓶颈几乎总是服务器到读者的带宽所以扩容基本是横向加机器。判断条件建议并发读者数百以内、单可用区单机即可2C4G 起步先跑通读者规模大或要求多可用区容灾origin 只读副本集群第五节详述需要转码、压缩超出 MediaMTX 职责范围用 docker/ffmpeg.Dockerfile 构建的镜像或独立转码链路一句话原则先单机验证带宽先于 CPU 成为瓶颈时再谈集群。二、跑起来最小可用部署这一节只给一条最短路径选镜像、一条启动命令、一份最小配置。镜像怎么选生产直接用官方标准镜像它基于 docker/standard.Dockerfile用 scratch 打底、无系统依赖且通过TARGETPLATFORM在构建时自动从 amd64、armv6、armv7、arm64 四个预编译二进制中挑出匹配架构——ECS 的 x86 实例默认 amd64ARM 架构实例如倚天/Graviton 系列拉的就是 arm64不需要自己交叉编译。docker run -d --name mediamtx --restart always \ --network host \ -v $PWD/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:latest--network host可以让容器直接使用宿主机端口省掉 NAT 转发UDP 密集的媒体流量在这种模式下也更省事。最小配置仓库自带的 mediamtx.yml 默认值就能跑只需打开两样东西、加一条测试路数api: yes # 控制API默认关闭 metrics: yes # Prometheus指标默认关闭 paths: cam1: source: rtmp://10.0.0.5:1935/cam1 # 按需代理一路上游源流三、调稳定配置与参数这一节只列云环境里真正值得动的 5 个参数其余保持默认。参数示例取值为什么调webrtcAdditionalHosts[你的公网IP]WebRTC 的 SDP 需要声明对外可达地址不配公网 IP 时浏览器端经常连不回来udpReadBufferSize2097152默认跟随操作系统调大 UDP 接收缓冲区可明显降低高峰期的丢包maxReaders100默认 0 表示不限给单路流设上限防止某一路突发读者吃光资源sourceOnDemandyes有读者才去拉源闲置相机不占上游带宽sourceOnDemandCloseAfter30s配合上一项无读者一段时间自动关源默认 10s日志容器里建议logDestinations: [stdout]把轮转交给容器平台加logStructured: true输出 JSONL方便日志服务采集。环境变量注入每个配置项都能用MTX_大写参数名覆盖例如MTX_RTSPADDRESS:8554。多套环境用同一份配置文件、只改环境变量Kubernetes 部署时尤其好用。四、看得见监控与健康检查这一节解决我怎么知道它还活着、跑得好不好两个内置入口都不用加旁路组件。健康检查开启api: yes后Control API 监听:9997。用下面这条命令作为探针即可返回 200 即视为存活curl -f http://localhost:9997/v3/paths/list完整接口见 api/openapi.yaml路径的增删改查、配置热更新都走这套 REST API。性能指标开启metrics: yes后:9998/metrics输出 Prometheus 格式指标。挑 4 个最值得盯的指标含义paths{name,state}各路数的状态offline/ready流掉线时最先变化paths_readers每路流的并发读者数扩容的首要依据paths_inbound_bytes入站字节数反映推流端上行是否正常paths_outbound_bytes出站字节数读者侧带宽消耗成本核算就看它五、扛得住高可用与弹性这一节回答单点挂掉怎么办、流量涨了怎么扛。高可用的正确姿势是读写分离而不是无脑多副本。媒体流是有状态的官方推荐的水平扩展方式是只读副本推流只进 origin 实例副本通过一条代理路数从 origin 拉流再服务给读者paths: ~^(.)$: source: rtsp://origin内网域名:8554/$G1 sourceOnDemand: yes负载均衡的选型有讲究RTSP/RTMP/SRT 读者走四层 LBHLS/WebRTC 读者走七层 LB 并开启 sticky sessions因为一次会话由多个连续请求组成。副本 Pod 再加跨可用区打散spec: replicas: 3 template: spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: {app: mediamtx}扩缩容起步阶段用 CPU 阈值即可接上 Prometheus Adapter 后建议改用paths_readers的平均值做副本数指标比 CPU 更贴近业务真实负载apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: mediamtx} spec: scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: mediamtx} minReplicas: 2 maxReplicas: 6 metrics: - type: Resource resource: name: cpu target: {type: Utilization, averageUtilization: 70}安全加固上线前逐条过rtspEncryption: yes、webrtcEncryption: yes媒体链路全加密authMethod从内置账号切到 JWT配authJWTJWKS或外部 HTTP 鉴权复用现有身份体系用authInternalUsers给关键路数收紧读/写权限必要时限定来源 IPapiEncryption: yes且 9997/9998 两个端口只暴露在内部网络安全组按协议放行端口并限制 UDP 端口范围公网入口只留必要的几个上线前自查清单安全组是否按协议放行 8554/8888/8889/8890 及对应 UDP 范围webrtcAdditionalHosts是否已填公网地址浏览器端能否拉到画面curl :9997/v3/paths/list与:9998/metrics是否按预期返回匿名推流是否已被鉴权配置拒绝日志采集与录像目录recordings/磁盘清理策略是否就位规模再上一个台阶后值得深入的两件事只读副本的多 region 部署细节以及alwaysSource常备流与录像回放playback的组合玩法。【免费下载链接】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），仅供参考