uniapp H5如何实现RTMP推流到后端？

Question

在使用 UniApp 开发 H5 应用时，如何实现将摄像头采集的音视频流通过 RTMP 协议推流到后端服务器？由于 H5 标准本身不支持原生 RTMP 推流，且浏览器限制了对底层音视频编码和封装的控制，导致无法直接将 MediaStream 编码为 FLV 并通过 WebSocket 或 RTMPT 传输。常见问题包括：如何将 `navigator.mediaDevices.getUserMedia` 获取的流转换为 RTMP 格式？是否必须依赖第三方 JS 库（如 flv.js 或 webrtc-streamer）？能否通过 WebSocket 中转实现实时推流？以及跨域、延迟、兼容性等问题如何解决？

Answer 1

一、H5 推流技术背景与限制分析

在使用 UniApp 开发 H5 应用时，实现摄像头音视频流的 RTMP 推流面临本质性挑战。HTML5 标准通过 navigator.mediaDevices.getUserMedia() 可获取用户的音视频流（MediaStream），但浏览器出于安全和标准化考虑，并未开放对底层音视频编码（如 H.264/AAC）及封装格式（如 FLV）的直接控制能力。

RTMP 协议要求将音视频数据以 FLV 封装并通过 TCP 长连接传输，而现代浏览器不支持原生 RTMP 客户端，也无法直接调用系统级编码器。因此，无法像原生 App 那样使用 FFmpeg 或 librtmp 实现高效推流。

技术点	浏览器支持	是否可用于 RTMP 推流
getUserMedia	✅ 支持（需 HTTPS）	仅提供原始流，不能直接推 RTMP
WebRTC	✅ 支持	可间接用于中转，非标准 RTMP
WebSocket + FLV 封装	✅ 支持	需 JS 编码，性能损耗大
原生 RTMP API	❌ 不支持	必须依赖外部服务或库

二、常见问题拆解与路径选择

1. 如何将 getUserMedia 获取的 MediaStream 转换为 RTMP 格式？
   由于浏览器无法直接生成 RTMP 包，需先采集流，再通过 JavaScript 手动编码为 H.264/AAC 并封装成 FLV 片段，最后通过 WebSocket 发送给服务器模拟 RTMP 行为（即 RTMPT）。此过程依赖 WebAssembly 模块或 asm.js 实现软编码，例如使用 ffmpeg.wasm 或 jsmpeg。
2. 是否必须依赖第三方 JS 库？
   是的，在当前技术条件下，几乎必须依赖第三方库来完成编码或协议适配。典型方案包括：
   • flv.js：主要用于播放 FLV 流，不支持推流；
   • webrtc-streamer：将 WebRTC 流桥接到 RTMP 服务器（如 nginx-rtmp）；
   • node-media-server：支持接收 WebSocket 推送的 FLV 数据并转为 RTMP；
   • ffmpeg.wasm：可在前端进行编码，但延迟高、CPU 占用严重。
3. 能否通过 WebSocket 中转实现实时推流？
   可以，这是目前主流替代方案之一。流程如下：

// 示例：通过 WebSocket 发送编码后的 FLV 数据块
const socket = new WebSocket('ws://your-server:8080/flv');
let mediaRecorder;

navigator.mediaDevices.getUserMedia({ video: true, audio: true })
.then(stream => {
    // 使用 MediaRecorder API 录制原始数据（非 FLV）
    mediaRecorder = new MediaRecorder(stream, { mimeType: 'video/webm' });
    mediaRecorder.ondataavailable = event => {
        if (event.data.size > 0) {
            // 此处需将 WebM 转 FLV，或使用 WASM 编码为 H.264
            socket.send(remuxToFLV(event.data)); // 自定义转换逻辑
        }
    };
    mediaRecorder.start(20); // 每20ms发送一次
});
    

三、架构设计与可行方案对比

针对 UniApp H5 平台，以下是几种可行的技术路径及其适用场景：

方案	原理	延迟	兼容性	开发复杂度
WebRTC → 后端转 RTMP	前端推 WebRTC 到 SFU，后端转码为 RTMP	低（300~800ms）	高（主流浏览器均支持）	中
WASM 编码 + WebSocket 推 FLV	前端用 ffmpeg.wasm 编码后通过 WS 发送	高（>2s）	中（依赖 CPU）	高
Flash 回退（已淘汰）	使用 Flash 实现 RTMP 推流	低	极低（Chrome 等已禁用）	不推荐
Hybrid App 插件方式	在 App 环境下使用原生插件推流	低	高（仅限 App 内嵌 WebView）	中

四、关键技术实现流程图

以下为基于 WebRTC 中转模式的完整推流链路：

graph TD
    A[用户授权摄像头] --> B[getUserMedia 获取 MediaStream]
    B --> C[创建 RTCPeerConnection]
    C --> D[连接至 WebRTC 信令服务器]
    D --> E[协商 SDP 与 ICE]
    E --> F[建立 P2P 连接]
    F --> G[流传输至 SFU/Edge Server]
    G --> H[服务器转码为 H.264/AAC]
    H --> I[封装为 FLV 并推送到 RTMP 服务器]
    I --> J[CDN 分发供播放器消费]
    

五、跨域、延迟与兼容性解决方案

实际部署中需重点解决以下三大问题：

• 跨域问题：确保信令服务器和 WebSocket 服务启用 CORS 头部（Access-Control-Allow-Origin），且 getUserMedia 请求运行在 HTTPS 环境下。
• 延迟优化：
  • 优先采用 WebRTC 方案，利用 UDP 传输降低延迟；
  • 设置合适的 keyframe interval（建议 2 秒内）；
  • 服务端启用 SPS/PPS 缓存，避免频繁重传编码参数。
• 兼容性处理：
  • 检测浏览器是否支持 MediaRecorder、RTCPeerConnection；
  • 对 Safari 等特殊浏览器降级使用 HLS 回放；
  • UniApp 中可通过条件编译区分 H5 与 App 端逻辑。

此外，建议在后端使用 Node-Media-Server 或 Ant Media Server 接收 WebSocket 推送的 FLV 流或 WebRTC 流，并自动转为 RTMP 输出，形成统一接入层。