FFMpeg + WebSocket + JSMpeg 搭建低延迟视频系统（总览篇）
目录
0. 摘要
1. 系统整体架构
2. 为什么选择这套方案
3. 核心链路步骤详解
4.本系列文章主要关注的关键优化点
5.总结与后续优化
0. 摘要
本文并非纯概念介绍，而是基于我实际搭建的 FFmpeg、WebSocket 与 JSMpeg 原型系统整理而来 。本系列主要研究低延迟视频播放中的TTFF（Time to First Frame）以及浏览器端处理瓶颈 。本文将梳理从视频采集、编码、封装、传输到浏览器端“解封装-解码-渲染”的完整链路，并深入分析浏览器侧成为延迟瓶颈的核心原因。
1. 系统整体架构
整个系统可以概括为一条清晰的物理链路：
FFmpeg：负责采集原始视频、编码并输出 MPEG-TS 流。
Relay Server：负责中继和分发二进制流。
浏览器端：通过 JSMpeg 接收并解码，最后由 Canvas 完成画面渲染。
处理流程分解：采集 → 编码 → 封装 → 传输 → 解封装 → 解码 → 渲染。
2. 为什么选择这套方案
在低延迟领域，常见方案对比 ：
HLS：兼容性强，但基于切片分发，首帧延迟高 。
WebRTC：延迟极低，但工程复杂性高（涉及 SDP、ICE、NAT 穿透等）。
WebSocket + JSMpeg：优势在于链路简单、浏览器原生支持、调试成本极低，是低延迟流媒体实验第一阶段的最佳选择。
3. 核心链路步骤详解
步骤 | 功能描述 | 关键点 |
采集（Capture） | 获取原始数据 | 来源可以是USB摄像头、树莓派、本地文件或桌面 |
编码（Encoding） | 压缩数据、降低带宽 | GOP大小、B帧、编码缓存都会直接影响时延 |
封装（Muxing） | 组织容器格式 | 选用MPEG-TS，因为其适合边生成边发送的流式场景 |
传输（Transport） | 数据送达浏览器 | WebSocket持续推送二进制流，服务端实现简单 |
解封装（demuxing） | 从TS流中重新拆出视频数据包 | JS处理Buffer的效率及数据同步开销 |
解码（decoding） | 将压缩数据还原为原始图像帧 | 核心瓶颈：软解码消耗大量CPU和主线程资源 |
渲染（Rendering） | 将帧图像绘制到Canvas画布上 | 浏览器事件循环（Event Loop）阻塞导致的显示延迟 |
4.本系列文章主要关注的关键优化点
其实根据拆解的核心链路可以发现，低延迟视频流处理的绝不是只有网络，还有编码端影响、封装与传输影响、浏览器端的影响等。基于作者目前的成果，本系列文章主要针对下列瓶颈进行优化：
- 编码端参数：GOP、B帧、码率、分辨率
- 封装与传输方式：TS+WebSocket的流式发送特性
- 浏览器端处理：demux、decode、render
- 缓冲策略和恢复机制
5.总结与后续优化
这套系统非常适合研究首帧时间 (TTFF)、GOP 对恢复速度的影响以及码率对浏览器压力的影响。本文作为本系列文章的总览篇只简单介绍了本系统的总体架构。本系列的第2篇作者将详细讲讲编码优化的过程。