MediaMTX 浏览器推流指南通过 Media-over-QUIC 与 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浏览器是 MediaMTX 最便捷的推流客户端之一无需安装任何软件打开一个网页即可把摄像头、麦克风或屏幕内容推送到服务器。MediaMTX 为浏览器推流提供了两条技术路线——基于 WebTransport 与 WebCodecs 的Media-over-QUIC端口8892和成熟的WebRTC端口8889两者都由服务器内置的网页直接驱动。读完本文你将掌握两种方式的完整接入步骤、页面嵌入方法、浏览器与编解码器兼容性边界以及如何基于仓库自带的页面源码定制自己的推流页面。一、总览浏览器推流的两条技术路线根据官方文档 Web browsers浏览器通过扮演以下两种客户端角色之一向服务器推流协议访问地址浏览器核心依赖支持的编码Media-over-QUIChttps://localhost:8892/mystream/publishWebTransport、WebCodecs视频 AV1/VP9/VP8/H265/H264音频 Opus/AACFLACWebRTChttp://localhost:8889/mystream/publishRTCPeerConnection、getUserMedia视频 AV1/VP9/VP8/H265/H264音频 Opus/G722/G711两条路线的共同点是推流成功后流都挂在 URL 中指定的路径上。例如访问/mystream/publish页面完成推流后其他客户端即可从mystream这个路径读取该直播流与 RTSP、RTMP、HLS 等来源产生的流完全等效。二、方式一用 Media-over-QUIC 从浏览器推流2.1 使用方法启动 MediaMTX 服务器后直接用浏览器打开https://localhost:8892/mystream/publish页面加载后会请求摄像头/麦克风权限并显示一个带推流控制面板的页面可以选择视频设备含屏幕共享选项、视频编码器AV1/VP9/VP8/H265/H264、码率、帧率、分辨率以及音频设备、音频编码器Opus/AAC和码率等参数。点击publish按钮即开始推流推流结果在/mystream路径上立即可读。2.2 前置条件Media-over-QUIC 是建立在 QUIC/HTTP3 与 WebTransport、WebCodecs 之上的新兴流媒体协议因此使用门槛明显高于 WebRTC客户端文档列出的要求包括服务器端HTTPS 为强制要求自签名证书也允许但见下方浏览器约束客户端必须能同时访问 HTTP/2 监听器8892/TCP用于网页与握手和 HTTP/3 监听器8892/UDP用于 WebTransport 端点若服务器部署在 Docker、NAT 或防火墙之后需要同时暴露并转发8892/TCP与8892/UDP。浏览器端若服务器使用自签名证书浏览器必须支持serverCertificatesHashes选项除 iOS Safari 外的现代浏览器均支持浏览器必须支持 WebTransport 与 WebCodecs所有现代浏览器均支持推流时还需支持MediaStreamTrackProcessor目前仅 Chrome 支持。这些要求在源码中都有对应实现。以 internal/servers/moq/http_server.go 为例MoQ 服务通过httpp.ServerHTTP/2承载网页、authmirror、fingerprint等端点与httpp3.ServerHTTP/3EnableWebTransport: true处理 WebTransport CONNECT 升级这一混合结构对外提供服务——纯 HTTP/3 场景通常禁止自签名证书这个混合设计正是为了绕开该限制。2.3 嵌入到自己的网页推流页面可以直接通过 iframe 嵌入到任何网页中iframe srchttps://mediamtx-ip:8892/mystream/publish scrollingno/iframe2.4 底层工作方式MoQ 推流页面在浏览器端实际上是一个采集 编码 传输三合一的程序核心逻辑封装在 internal/servers/moq/publisher.js 中名为MediaMTXMoQPublisher的独立类里采集通过getUserMedia摄像头/麦克风或getDisplayMedia屏幕共享支持cursor: always显示鼠标获得MediaStream编码调用 WebCodecs 的VideoEncoder/AudioEncoder对采集到的原始帧做硬件加速编码编码器候选及参数在 internal/servers/moq/publish_index.html 的populateCodecs()中列出av01.0.04M.08、vp09.00.10.08、vp8、avc3.640028、hev1.1.6.L93.B0等页面会先用isConfigSupported()探测浏览器实际支持的编码器只把可用的放进下拉框传输通过 WebTransport 连接到服务器moqt-19版本支持断线后每 2 秒自动重连并使用 MOQT Streaming FormatMSF通告轨道、Low Overhead Media ContainerLOC封装帧数据。页面上所有参数码率、分辨率等都会同步写入 URL 的 query stringwindow.history.replaceState刷新页面后通过loadValuesFromQuery()恢复方便把预设参数直接拼在嵌入链接上。此外页面还会请求authmirror端点回显认证凭据用于在配置了鉴权的场景下透传用户名密码。三、方式二用 WebRTC 从浏览器推流3.1 使用方法启动服务器后打开http://localhost:8889/mystream/publish页面工作方式与 MoQ 版一致选择音视频设备与编码器后点击publish即可流同样发布到/mystream路径。WebRTC 方案对浏览器要求更宽容——不需要 WebCodecs、不需要 WebTransport兼容性覆盖面比 MoQ 更广因此是当前最常见的浏览器推流路径。3.2 编码器兼容性提醒WebRTC 页面的编码器列表与 MoQ 不同视频 AV1/VP9/VP8/H265/H264音频 Opus/G722/G711且并非所有浏览器都能用任意编码器推流。官方文档 Codec support in browsers 特别指出两个高频坑H265大量浏览器不支持用 WebRTC 读取 H265 轨道部分浏览器仅在严格条件下支持如 Chrome 仅在 Windows 且具备支持硬件解码能力的 GPU 时可用H264 含 B 帧的流B 帧不属于 WebRTC 规范所有浏览器都有意不支持。为保证最大兼容性建议用 H264 baseline profile不产生 B 帧 Opus 编码转码后推流官方给出的 FFmpeg 示例ffmpeg -i rtsp://original-source \ -c:v libx264 -pix_fmt yuv420p -preset ultrafast -b:v 600k \ -c:a libopus -b:a 64K -async 50 \ -f rtsp rtsp://localhost:8554/mystream如果遇到连接建立困难的问题NAT 穿透等可参考 Solving WebRTC connectivity issues 一节排查。3.3 嵌入到自己的网页与 MoQ 相同WebRTC 推流页同样支持 iframe 嵌入iframe srchttp://mediamtx-ip:8889/mystream/publish scrollingno/iframe3.4 底层工作方式WebRTC 推流页面的前端逻辑同样独立成类位于 internal/servers/webrtc/publisher.jsMediaMTXWebRTCPublisher。从 internal/servers/webrtc/publish_index.html 可以看出页面初始化时依次做了三件事通过getUserMedia预取媒体流以触发权限申请随后立即停掉临时轨道避免 Android 上出现NotReadableError、用enumerateDevices()枚举音视频设备并额外提供 screen 屏幕共享选项、创建临时RTCPeerConnection生成 offer 来探测 SDP 中实际支持的编码器。推流时MediaMTXWebRTCPublisher会把采集到的MediaStream交给浏览器原生 WebRTC 栈通过 WHIP 端点whipURL 后缀与服务器完成信令与 ICE 协商最终建立 P2P 媒体通道。在服务器侧internal/servers/webrtc/http_server.go 负责路由以/publish结尾的路径返回推流页面HTML 响应带Cache-Control: no-cache这是为了防止 Firefox 在 iframe 被删除并重建后无法重新建立 WebRTC 连接的已知问题publisher.js/reader.js作为静态资源返回同时它还实现了完整的 WHIP/WHEP 端点POST /mystream/whip创建会话、PATCH发送 trickle ICE、DELETE结束会话也就是说浏览器页面走的就是 WHIP 信令通道——这也是 OBS Studio 等第三方软件能够用http://localhost:8889/mystream/whip直接推流的原因。四、高级用法定制自己的推流页面官方推流页面只是参考实现。对于更复杂的业务场景自定义 UI、接入自己的信令、特殊鉴权流程可以完全抛弃内置页面直接从仓库源码起步构建WebRTC 推流以 internal/servers/webrtc/publish_index.html 为页面骨架复用其中开箱即用的独立 JavaScript 类 internal/servers/webrtc/publisher.js。该类封装了完整的推流逻辑编码器探测、设备采集、WHIP 协商、错误重试你只需传入配置对象urlWHIP 端点、streamMediaStream、videoCodec/videoBitrate/audioCodec/audioBitrate等参数并实现onError、onConnected回调即可。MoQ 推流以 internal/servers/moq/publish_index.html 为骨架复用 internal/servers/moq/publisher.js 中的MediaMTXMoQPublisher类其配置项比 WebRTC 版多出videoFramerate、videoKeyframeInterval关键帧间隔秒、videoWidth/videoHeight以及可选的fingerprintUrl自签名证书场景下获取服务器证书指纹、user/pass/token鉴权凭据。自行托管的页面与服务器交互所需的全部端点都已在两个 HTTP 服务器中实现路由行为可分别参考 internal/servers/webrtc/http_server.go 与 internal/servers/moq/http_server.go。五、相关配置项速查两条推流路径对应的监听地址、TLS 开关等在全局配置mediamtx.yml中定义与推流相关的核心配置项见 internal/conf/conf.go配置项默认端口/取值作用webrtcyes是否启用 WebRTC 服务webrtcAddress:8889WebRTC HTTP 监听地址页面与 WHIP/WHEP 端点webrtcEncryptionno是否启用 HTTPSWebRTC 页面默认走http://webrtcServerKey/webrtcServerCert—启用webrtcEncryption时的 TLS 证书moqyes是否启用 Media-over-QUIC 服务moqAddress:8892MoQ 的 HTTP/2 与 HTTP/3 混合监听地址TCP 与 UDP 均需放行注意MoQ 路径强制 HTTPS因此其推流 URL 前缀固定为https://而 WebRTC 默认是明文 HTTPURL 前缀为http://。若为 WebRTC 开启了webrtcEncryption则需相应改用https://访问。六、小结浏览器推流有Media-over-QUIChttps://localhost:8892/…/publish更快、支持更多编码与 B 帧但浏览器门槛高且必须放行 TCPUDP与WebRTChttp://localhost:8889/…/publish兼容性最好两条成熟路线两种推流页均可通过 iframe 直接嵌入第三方网页且支持用 URL query 预置推流参数编码器兼容性是实际部署中最容易踩坑的环节跨浏览器场景优先选择 H264 baseline Opus需要深度定制时可直接复用 internal/servers/webrtc/publisher.js 与 internal/servers/moq/publisher.js 两个自包含的推流类配合服务器已实现的 WHIP/WebTransport 端点快速搭建自有推流前端。【免费下载链接】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 浏览器推流指南：通过 Media-over-QUIC 与 WebRTC 从网页发布实时流
MediaMTX 浏览器推流指南通过 Media-over-QUIC 与 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浏览器是 MediaMTX 最便捷的推流客户端之一无需安装任何软件打开一个网页即可把摄像头、麦克风或屏幕内容推送到服务器。MediaMTX 为浏览器推流提供了两条技术路线——基于 WebTransport 与 WebCodecs 的Media-over-QUIC端口8892和成熟的WebRTC端口8889两者都由服务器内置的网页直接驱动。读完本文你将掌握两种方式的完整接入步骤、页面嵌入方法、浏览器与编解码器兼容性边界以及如何基于仓库自带的页面源码定制自己的推流页面。一、总览浏览器推流的两条技术路线根据官方文档 Web browsers浏览器通过扮演以下两种客户端角色之一向服务器推流协议访问地址浏览器核心依赖支持的编码Media-over-QUIChttps://localhost:8892/mystream/publishWebTransport、WebCodecs视频 AV1/VP9/VP8/H265/H264音频 Opus/AACFLACWebRTChttp://localhost:8889/mystream/publishRTCPeerConnection、getUserMedia视频 AV1/VP9/VP8/H265/H264音频 Opus/G722/G711两条路线的共同点是推流成功后流都挂在 URL 中指定的路径上。例如访问/mystream/publish页面完成推流后其他客户端即可从mystream这个路径读取该直播流与 RTSP、RTMP、HLS 等来源产生的流完全等效。二、方式一用 Media-over-QUIC 从浏览器推流2.1 使用方法启动 MediaMTX 服务器后直接用浏览器打开https://localhost:8892/mystream/publish页面加载后会请求摄像头/麦克风权限并显示一个带推流控制面板的页面可以选择视频设备含屏幕共享选项、视频编码器AV1/VP9/VP8/H265/H264、码率、帧率、分辨率以及音频设备、音频编码器Opus/AAC和码率等参数。点击publish按钮即开始推流推流结果在/mystream路径上立即可读。2.2 前置条件Media-over-QUIC 是建立在 QUIC/HTTP3 与 WebTransport、WebCodecs 之上的新兴流媒体协议因此使用门槛明显高于 WebRTC客户端文档列出的要求包括服务器端HTTPS 为强制要求自签名证书也允许但见下方浏览器约束客户端必须能同时访问 HTTP/2 监听器8892/TCP用于网页与握手和 HTTP/3 监听器8892/UDP用于 WebTransport 端点若服务器部署在 Docker、NAT 或防火墙之后需要同时暴露并转发8892/TCP与8892/UDP。浏览器端若服务器使用自签名证书浏览器必须支持serverCertificatesHashes选项除 iOS Safari 外的现代浏览器均支持浏览器必须支持 WebTransport 与 WebCodecs所有现代浏览器均支持推流时还需支持MediaStreamTrackProcessor目前仅 Chrome 支持。这些要求在源码中都有对应实现。以 internal/servers/moq/http_server.go 为例MoQ 服务通过httpp.ServerHTTP/2承载网页、authmirror、fingerprint等端点与httpp3.ServerHTTP/3EnableWebTransport: true处理 WebTransport CONNECT 升级这一混合结构对外提供服务——纯 HTTP/3 场景通常禁止自签名证书这个混合设计正是为了绕开该限制。2.3 嵌入到自己的网页推流页面可以直接通过 iframe 嵌入到任何网页中iframe srchttps://mediamtx-ip:8892/mystream/publish scrollingno/iframe2.4 底层工作方式MoQ 推流页面在浏览器端实际上是一个采集 编码 传输三合一的程序核心逻辑封装在 internal/servers/moq/publisher.js 中名为MediaMTXMoQPublisher的独立类里采集通过getUserMedia摄像头/麦克风或getDisplayMedia屏幕共享支持cursor: always显示鼠标获得MediaStream编码调用 WebCodecs 的VideoEncoder/AudioEncoder对采集到的原始帧做硬件加速编码编码器候选及参数在 internal/servers/moq/publish_index.html 的populateCodecs()中列出av01.0.04M.08、vp09.00.10.08、vp8、avc3.640028、hev1.1.6.L93.B0等页面会先用isConfigSupported()探测浏览器实际支持的编码器只把可用的放进下拉框传输通过 WebTransport 连接到服务器moqt-19版本支持断线后每 2 秒自动重连并使用 MOQT Streaming FormatMSF通告轨道、Low Overhead Media ContainerLOC封装帧数据。页面上所有参数码率、分辨率等都会同步写入 URL 的 query stringwindow.history.replaceState刷新页面后通过loadValuesFromQuery()恢复方便把预设参数直接拼在嵌入链接上。此外页面还会请求authmirror端点回显认证凭据用于在配置了鉴权的场景下透传用户名密码。三、方式二用 WebRTC 从浏览器推流3.1 使用方法启动服务器后打开http://localhost:8889/mystream/publish页面工作方式与 MoQ 版一致选择音视频设备与编码器后点击publish即可流同样发布到/mystream路径。WebRTC 方案对浏览器要求更宽容——不需要 WebCodecs、不需要 WebTransport兼容性覆盖面比 MoQ 更广因此是当前最常见的浏览器推流路径。3.2 编码器兼容性提醒WebRTC 页面的编码器列表与 MoQ 不同视频 AV1/VP9/VP8/H265/H264音频 Opus/G722/G711且并非所有浏览器都能用任意编码器推流。官方文档 Codec support in browsers 特别指出两个高频坑H265大量浏览器不支持用 WebRTC 读取 H265 轨道部分浏览器仅在严格条件下支持如 Chrome 仅在 Windows 且具备支持硬件解码能力的 GPU 时可用H264 含 B 帧的流B 帧不属于 WebRTC 规范所有浏览器都有意不支持。为保证最大兼容性建议用 H264 baseline profile不产生 B 帧 Opus 编码转码后推流官方给出的 FFmpeg 示例ffmpeg -i rtsp://original-source \ -c:v libx264 -pix_fmt yuv420p -preset ultrafast -b:v 600k \ -c:a libopus -b:a 64K -async 50 \ -f rtsp rtsp://localhost:8554/mystream如果遇到连接建立困难的问题NAT 穿透等可参考 Solving WebRTC connectivity issues 一节排查。3.3 嵌入到自己的网页与 MoQ 相同WebRTC 推流页同样支持 iframe 嵌入iframe srchttp://mediamtx-ip:8889/mystream/publish scrollingno/iframe3.4 底层工作方式WebRTC 推流页面的前端逻辑同样独立成类位于 internal/servers/webrtc/publisher.jsMediaMTXWebRTCPublisher。从 internal/servers/webrtc/publish_index.html 可以看出页面初始化时依次做了三件事通过getUserMedia预取媒体流以触发权限申请随后立即停掉临时轨道避免 Android 上出现NotReadableError、用enumerateDevices()枚举音视频设备并额外提供 screen 屏幕共享选项、创建临时RTCPeerConnection生成 offer 来探测 SDP 中实际支持的编码器。推流时MediaMTXWebRTCPublisher会把采集到的MediaStream交给浏览器原生 WebRTC 栈通过 WHIP 端点whipURL 后缀与服务器完成信令与 ICE 协商最终建立 P2P 媒体通道。在服务器侧internal/servers/webrtc/http_server.go 负责路由以/publish结尾的路径返回推流页面HTML 响应带Cache-Control: no-cache这是为了防止 Firefox 在 iframe 被删除并重建后无法重新建立 WebRTC 连接的已知问题publisher.js/reader.js作为静态资源返回同时它还实现了完整的 WHIP/WHEP 端点POST /mystream/whip创建会话、PATCH发送 trickle ICE、DELETE结束会话也就是说浏览器页面走的就是 WHIP 信令通道——这也是 OBS Studio 等第三方软件能够用http://localhost:8889/mystream/whip直接推流的原因。四、高级用法定制自己的推流页面官方推流页面只是参考实现。对于更复杂的业务场景自定义 UI、接入自己的信令、特殊鉴权流程可以完全抛弃内置页面直接从仓库源码起步构建WebRTC 推流以 internal/servers/webrtc/publish_index.html 为页面骨架复用其中开箱即用的独立 JavaScript 类 internal/servers/webrtc/publisher.js。该类封装了完整的推流逻辑编码器探测、设备采集、WHIP 协商、错误重试你只需传入配置对象urlWHIP 端点、streamMediaStream、videoCodec/videoBitrate/audioCodec/audioBitrate等参数并实现onError、onConnected回调即可。MoQ 推流以 internal/servers/moq/publish_index.html 为骨架复用 internal/servers/moq/publisher.js 中的MediaMTXMoQPublisher类其配置项比 WebRTC 版多出videoFramerate、videoKeyframeInterval关键帧间隔秒、videoWidth/videoHeight以及可选的fingerprintUrl自签名证书场景下获取服务器证书指纹、user/pass/token鉴权凭据。自行托管的页面与服务器交互所需的全部端点都已在两个 HTTP 服务器中实现路由行为可分别参考 internal/servers/webrtc/http_server.go 与 internal/servers/moq/http_server.go。五、相关配置项速查两条推流路径对应的监听地址、TLS 开关等在全局配置mediamtx.yml中定义与推流相关的核心配置项见 internal/conf/conf.go配置项默认端口/取值作用webrtcyes是否启用 WebRTC 服务webrtcAddress:8889WebRTC HTTP 监听地址页面与 WHIP/WHEP 端点webrtcEncryptionno是否启用 HTTPSWebRTC 页面默认走http://webrtcServerKey/webrtcServerCert—启用webrtcEncryption时的 TLS 证书moqyes是否启用 Media-over-QUIC 服务moqAddress:8892MoQ 的 HTTP/2 与 HTTP/3 混合监听地址TCP 与 UDP 均需放行注意MoQ 路径强制 HTTPS因此其推流 URL 前缀固定为https://而 WebRTC 默认是明文 HTTPURL 前缀为http://。若为 WebRTC 开启了webrtcEncryption则需相应改用https://访问。六、小结浏览器推流有Media-over-QUIChttps://localhost:8892/…/publish更快、支持更多编码与 B 帧但浏览器门槛高且必须放行 TCPUDP与WebRTChttp://localhost:8889/…/publish兼容性最好两条成熟路线两种推流页均可通过 iframe 直接嵌入第三方网页且支持用 URL query 预置推流参数编码器兼容性是实际部署中最容易踩坑的环节跨浏览器场景优先选择 H264 baseline Opus需要深度定制时可直接复用 internal/servers/webrtc/publisher.js 与 internal/servers/moq/publisher.js 两个自包含的推流类配合服务器已实现的 WHIP/WebTransport 端点快速搭建自有推流前端。【免费下载链接】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），仅供参考
