做低延迟视频方案的时候很多人的第一反应是上 WebRTC但真要落地时往往被信令、网关、服务端开发折腾得够呛。我个人这些年用得最顺手、也最省心的一套组合反而是 FFmpeg WebSocket JSMpeg 这套偏“轻量”的方案——编码用 FFmpeg传输走 WebSocket解码渲染交给 JSMpeg整条链路跑下来延迟能压到 1 秒以内局域网环境甚至能做到 200~500 毫秒。这个方案的核心思路就是绕开 HLS 的分片打包、绕开播放器的缓冲策略用最直接的二进制帧把视频从采集端送到浏览器里的 Canvas 上。这篇文章是系列第一篇总览面向的是想快速做出一套可用系统、又不希望一头扎进复杂流媒体协议里的开发者先帮你把整条链路怎么搭、每一步解决什么问题讲清楚。1. 整体架构与设计思路1.1 三个组件各管哪一段很多人第一次看到 FFmpeg、WebSocket、JSMpeg 这三个词堆在一起会有点懵其实它们分工非常明确采集端设备把画面交给 FFmpegFFmpeg 负责把原始视频压缩成适合网络传输的 MPEG1 或 MJPEG 编码流然后通过 WebSocket 协议把编码后的字节流源源不断地推给浏览器端浏览器端由 JSMpeg 这个 JavaScript 写的解码器负责解析最终把画面画到 Canvas 上。整个过程没有后端的转码服务器也没有需要部署的播放器插件。我在实际项目里经常把服务端这一层单独拎出来做 WebSocket 转发因为采集端不一定直接把流推到浏览器——比如摄像头在采集端机房浏览器分布在各个办公室这时候一个轻量 WebSocket 服务端做中转就很有必要。它做的事情很简单接收 FFmpeg 推上来的二进制数据再分发给所有已连接的浏览器客户端。抽象成一句话就是“生产者-分发者-消费者”三端模型。这套架构最舒服的地方在于它的解耦程度FFmpeg 只负责采流编码WebSocket 服务端只负责转发JSMpeg 只负责播放。哪个环节出问题就单独排查哪个环节替换也方便。我后来在另一个项目里把 FFmpeg 换成了硬件编码器JSMpeg 端完全没动这就是分层的价值。1.2 低延迟从哪里来数据链路对比传统网页直播方案走到浏览器里绕不开 HLS 或 HTTP-FLV。HLS 的核心问题是“切分—拉取—拼接”这套机制服务端把视频切成 2~6 秒一段的小文件客户端再一小段一小段去拉取播放。哪怕把切片切得很小、留很短的窗口算上播放器的缓冲水位端到端延迟稳稳落在 5~30 秒这个区间对于远程控制摄像头、无人机图传这种场景来说等看到画面确认完状态再做动作黄花菜都凉了。这套三件套方案把延迟压缩的关键是去掉了三种“缓冲”编码缓冲FFmpeg 用-tune zerolatency和low_delay相关参数让编码器不要为了追求压缩率而积攒多帧再输出传输缓冲WebSocket 是全双工长连接二进制帧直接顺带发送不像 HTTP 每帧请求都要带一堆头部字段和握手开销播放缓冲JSMpeg 默认不维护大的帧队列来一帧解码一帧画面即时渲染到 Canvas。延迟的本质就是链路上所有排队和缓冲时间之和。这套方案把能砍掉的排队点都砍了剩下的就只有网络物理传输时间再加解码耗时自然就能做到亚秒级。1.3 为什么不是 WebRTC也不是 HLS有人一定会问WebRTC 不是更专业吗没错WebRTC 是当前延迟最低的浏览器实时方案理想状态下能到 100~300 毫秒但它要处理 STUN/TURN 打洞、ICE 协商、信令服务、音视频引擎的适配服务端的压力和客户端的兼容性坑都更多。如果项目只是要“看到实时画面操作延迟不太离谱”上 WebRTC 有种杀鸡用牛刀的感觉。HLS 和 HTTP-FLV 则是另一个极端虽然部署成熟、CDN 链路完善但前者延迟太高后者依赖浏览器对 FLV 的解析能力还需要额外引入 flv.js 并维护 MSE 缓冲逻辑。我做过一个对比测试拿同一路 RTSP 摄像头信号分别做 HLS 和 FFmpegWebSocket 推流在不优化参数的前提下HLS 显示延迟为 8~14 秒三件套方案在局域网内约为 0.4~0.8 秒。这个数量级的差距直接决定了远程看护或者机器人操控场景到底能不能用。下表是我自己做技术选型时常用的对比维度方案核心协议端到端延迟服务端复杂度适合场景HLSHTTPTS 分片5~30 秒低静态切片分发大规模直播、点播HTTP-FLVHTTP 长连接1~4 秒中直播平台、弹幕交互WebRTCSRTP/UDP0.1~0.5 秒高信令网关音视频会议、双向互动FFmpegWebSocketJSMpegWebSocket 二进制帧0.2~1 秒低监控、无人值守、单向低延迟查看2. FFmpeg、WebSocket、JSMpeg 三个核心组件的关键原理2.1 FFmpeg 编码侧为什么默认用 MPEG1 而不用 H.264FFmpeg 支持的编码格式一大堆但在 JSMpeg 面前选项其实被限制得比较死。JSMpeg 的解码核心是用 JavaScript 实现的 MPEG1 视频解码器这意味着它只能处理 MPEG1 或者 MJPEG 这两种格式。为什么不把 H.264 直接拿到浏览器里让 JSMpeg 解因为 H.264 的完整解码复杂度极高纯 JS 实现跑不动浏览器内置的 H.264 解码能力又不存在开放给普通 JavaScript 调用的通用接口。用 WebCodecs 是个出路但那已经是另一个方案的范畴不在这个系列的总览范围里。所以在 FFmpeg 侧实际上只需要搞清楚两件事输出格式选mpeg1video或mjpeg。两者的取舍是这样的MJPEG 是把每一帧 JPEG 压缩实现最简单、解码最容易拖到 JSMpeg 里逐帧就能画出来但单帧体积大网络上跑起来带宽占用高画面动作一多文件体积飙升得很厉害MPEG1 则更进一步引入了 I 帧、P 帧的帧间预测机制用时间和计算量换取更低的码率。我在做摄像头监控时传 640x48030fps选 MPEG1 大约只需要 800kbps 左右码率比 MJPEG 低一大截画面平滑度还更好。一个基本命令长这样ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.100/stream1 \ -an -c:v mpeg1video -s 640x480 -r 25 -b:v 800k \ -f mpeg1video -fflags nobuffer -flags low_delay \ ws://127.0.0.1:8082/这里的-fflags nobuffer用来把输入侧缓冲降到最低-flags low_delay减小编码器内部缓冲-f mpeg1video让 FFmpeg 以裸 MPEG1 流的方式输出裸数据。没有-f mpegts封装也省掉了一层容器开销。后面系列文章里我还会专门写一篇命令参数的逐项拆解这里先有个整体印象就行。2.2 WebSocket 传输侧为什么它是这套方案的传输底座WebSocket 在这套方案里不只是一个可选的通道它是一个刚需。传统 HTTP 传输视频流时要么是边下边播的分块响应要么是客户端不断去拉取新片段。但 WebSocket 是建立一次 TCP 长连接之后两端随时可以往管道里塞数据HTTP 头部的开销只在握手阶段出现一次后续传输二进制裸数据时帧头只有很小的开销。更重要的是WebSocket 的数据帧天然自带边界JSMpeg 收到一个二进制消息就可以当一个完整的片断来处理。实际落地时我建议在中间加一层转发服务。FFmpeg 把编码流推到一个 WebSocket 服务端入口服务端通过广播的方式推给所有订阅的浏览器。这个转发服务通常用 Node.js 的 ws 库几十行代码就能搭完而且可以顺手做连接鉴权、客户端数量统计、录制存储等扩展功能。转发时有一个细节JSMpeg 需要的是原始的 MPEG1 字节流不需要额外封装因为你一旦给数据加了壳JSMpeg 还得先花功夫解这个壳没必要。2.3 JSMpeg 播放端纯 JS 解码器如何工作JSMpeg 的原理是把浏览器端接收到的 MPEG1 编码数据逐步喂给内部的解码器解码器还原出原始图像的宽度、高度、亮度和色度数据再通过 Canvas 的putImageData或drawImage的方式渲染到页面上。整个过程完全在浏览器线程内执行所以它不需要后端配合转封装格式也不依赖系统解码器兼容性反而好控制。这里重点提醒一下JSMpeg 播放时对 CPU 是实打实有消耗的尤其是分辨率高、帧率高的画面。我之前实测在一般办公笔记本上播放 720x48025fpsCPU 占用大约 10~15%这还可以接受但如果你把它搬到低端安卓盒子上跑解码压力会明显增大画面掉帧会非常明显。所以在做系统规划时不要把前端播放器的性能当成免费午餐编码侧分辨率、帧率和码率三者必须一起权衡。音频方面 JSMpeg 也能处理 MPEG1 音频但音频和视频的同步会带来额外的复杂度很多项目干脆先去掉音频把音频需求放到独立通道处理。我个人处理安防类场景时是直接-an丢弃音频画面优先。3. 跑通最小系统的路线图3.1 环境准备先把这个系统需要的东西列一下一台能跑 FFmpeg 的机器一般用 Linux 或者 macOS一个 WebSocket 服务端环境我习惯用 Node.js ws 库一个现代浏览器一个视频源。视频源是最好解决的没有摄像头的话直接拿本机桌面录制或者一个本地 mp4 文件当输入也行。搭建最小验证环境时我强烈建议把“采集端-转发端-播放端”控制在同一台机器上先跑通逻辑再去考虑跨网络的问题。这样可以最大化排除网络因素的干扰确定问题出在编码还是出在传输。这个最小系统需要的代码量并不大下面每一步都能在半小时内走完。3.2 编码端推流命令假设你的前端页面运行在 8082 端口WebSocket 服务端也在 8082那么 FFmpeg 推流命令可以简化成ffmpeg -re -i /path/to/input.mp4 \ -an -c:v mpeg1video -s 640x480 -r 25 -b:v 800k \ -f mpeg1video -fflags nobuffer -flags low_delay \ http://127.0.0.1:8082/video注意这里我改了输出地址因为某些版本的 FFmpeg 对ws://协议支持并不统一而输出到 HTTP 地址后由服务端在收到 HTTP 分块请求时把数据读取出来再转成 WebSocket 广播这样反倒最简单稳妥。当然了如果你用的 FFmpeg 版本支持直接推ws://也可以省掉服务端 HTTP 接收这一步。我这里采用的是 99% 环境都能直接跑的方式。如果只是验证用本地文件-re表示按原视频帧率逐步读取文件推送如果用的是直播摄像头输入通常不应该加-re而是让 FFmpeg 按实时解码出来的速度推流——摄像头本身就是实时源不需要人为限速。3.3 服务端转发逻辑服务端模块拆成两部分一部分负责接收 HTTP 分块上传的数据也就是 FFmpeg 推上来的流另一部分维护所有 WebSocket 播放连接。收到编码数据后不做任何加工直接写进每个 WebSocket 连接的发送缓冲区。Node.js 侧的核心逻辑大致可以是const http require(http); const WebSocket require(ws); const clients new Set(); const server http.createServer((req, res) { if (req.url.startsWith(/video)) { req.on(data, chunk { for (const client of clients) { if (client.readyState WebSocket.OPEN) { client.send(chunk); } } }); req.on(end, () res.end(ok)); } }); const wss new WebSocket.Server({ port: 8082 }); wss.on(connection, ws { clients.add(ws); ws.on(close, () clients.delete(ws)); });这只是最粗糙版本生产环境还得考虑客户端发送速度、背压、断线重连、WebSocket 最大消息体限制等问题但作为总览篇先看核心脉络已经足够了。这条链路的延迟瓶颈其实很少出现在这里——Node 转发基本是内存拷贝级别瓶颈还是在编码等待和网络状况。3.4 浏览器端接入浏览器端引入 JSMpeg 只需要一个 JavaScript 文件和几行代码script srcjsmpeg.min.js/script canvas idscreen width640 height480/canvas script const canvas document.getElementById(screen); const player new JSMpeg.Player(ws://127.0.0.1:8082/, { canvas: canvas, video: true, audio: false, autoplay: true }); /script需要注意的是wss 和 ws 协议在跨域、混合内容限制上是跟着页面协议走的。如果页面是 HTTPS 部署那 WebSocket 也必须用 WSS否则浏览器会直接拦掉。这地方我在项目里踩过坑FFmpeg 采集端在局域网用 ws浏览器页面在公网 HTTPS 环境下怎么也连不上排查半天最后发现是加密 WebSocket 没做反向代理补一层 WSS 转发就通了。3.5 延迟测量方法系统跑通之后首先要量化延迟多少不能凭感觉说“挺快”。最省事的办法是准备一个秒表让视频源对准秒表画面然后手机拍一张浏览器播放画面对比当前秒表读数和画面里秒表读数的差值多测几次取平均。这个偏差就是端到端延迟的近似值。我见过用毫秒级的系统时钟来测的但那个对设备同步要求高反而不如物理秒表直观。我的经验是连续测量 10 组数据如果最大值和最小值之间的抖动能控制在 200 毫秒以内这套系统在对应网络环境下的稳定性就还能接受。抖动比延迟绝对值更可怕因为视频控制功能对“每次操作后的等待时间不一致”这种情况非常敏感。4. 延迟从哪里来以及调优方向4.1 四段链路延迟拆解把整条链路切开看延迟主要分布在四个地方编码端缓冲、网络传输、解码器缓冲、渲染间隔。编码端最常见的问题是采集卡或摄像头的内部缓冲以及 FFmpeg 的输入/输出缓冲。有些网络摄像头在 RTSP 拉流时TCP 模式比 UDP 模式更稳但会带来一定缓冲延迟-ftps_transport tcp并不是灵丹妙药要以实际测试为准。网络传输这一段的延迟主要由链路质量和跨运营商时延决定局域网内通常低于 5 毫秒跨公网则会到几十毫秒甚至更多这不是码率能解决的。解码器这一侧JSMpeg 本身不维护大缓冲但浏览器主线程如果有其他 JS 任务抢占 CPU解码节奏会被打断视频帧会瞬间积压造成隐性延迟。渲染间隔则取决于浏览器帧率一般是 16.6ms 或 33.3ms这部分影响不大但客观存在。四段加起来理想状况下一个 640x48025fps 的本地局域网系统端到端延迟在 0.3~0.6 秒范围内是很正常的。4.2 核心调优参数调优第一个重点在 FFmpeg 命令把preset调成ultrafast把tune设成zerolatency关闭 B 帧和某些高级预测选项延缓编码器内部等待。第二个重点是分辨率和帧率之间的取舍有些人为了画面清晰一上来就 1080p30fps结果 CPU 解码跟不上实际体验反而比 480p15fps 差。我通常会建议如果只看画面不抠细节720x48025fps 是个大量场景下最均衡的档位。第三个重点在 WebSocket 服务端不要对每一个连接单独开阻塞式同步写要利用 ws 库的bufferedAmount做背压检测。当某个客户端网络差、发送缓冲区越积越多的时候主动丢掉旧帧或断开重连别让一个慢客户端把整个服务的发送队列拖垮。我在多路并发项目里就是因为没做这个限制一路弱网客户端不断堆积最后整个进程 OOM 了。第四个重点在前端 Canvas如果页面需要同时显示多路、多画面不要让每个播放器独立一个高刷 Canvas最好只对可见画面做绘制甚至在低端设备上把渲染分辨率降一档。JSMpeg 默认渲染到 Canvas 的清晰度与视频分辨率一致这个可以通过 CSS 缩放去控制实际显示大小但要意识到 CSS 放大并不会增加画面信息量。4.3 常见问题与排查清单把项目里实际遇到的高频问题整理一下现象可能原因处理思路画面花屏、绿色马赛克WebSocket 丢帧或数据乱序MPEG1 解码状态被破坏且 P 帧依赖前序帧优先排查网络丢包降低码率或分辨率必要时重启推流播放端黑屏无画面WebSocket 握手失败或服务端从未收到 FFmpeg 数据检查服务端日志确认连接数单独 curl HTTP 入口确认数据流画面有延迟但不卡顿编码缓冲或者播放缓冲仍然存在检查fflags nobuffer是否生效确认 JSMpeg 没有设置过大的 streamBufferSizeCPU 占用过高分辨率或帧率超出 JS 解码能力降低分辨率、降帧率或改用 MJPEG 模式用空间换时间多路并发后内存飙升WebSocket 发送缓冲不释放开启背压检测丢弃落后客户端帧数据这些都算是这个架构比较有代表性的“坑”。在总览篇先摆出来也是希望你在正式动工前对这套方案的脾气有个预期。细节排查方法每一类问题以后可以单独展开讲。5. 应用场景和这套方案的边界5.1 最适合的场景以我实际做过的项目来看这套三件套最适合以下场景安防监控类的远程画面查看、家用或小型机房的无人值守监看、机器人或小车的第一视角回传、以及展会或教学环境中的多屏同显。这些场景的共同特点是“观看到操作之间的延迟控制在 1 秒左右就能接受”并不需要像视频会议那样唇音同步。拿一个具体的例子说帮朋友做的小型仓库监控就是一台普通工控机 USB 摄像头FFmpeg 拉 RTSP 转 MPEG1WebSocket 转发浏览器开一个网格页面同时看八个摄像头画面刷新延迟稳定在 0.6 秒左右。需求变了以后还能直接加录像WebSocket 服务端在广播的同时把数据写一份本地文件回放时直接用 FFmpeg 转一下就行。这套组合的扩展性体现在它的简单性因为每一层都不复杂改起来反而灵活。5.2 不适合的场景这套方案也有非常明显的边界它不适合需要双向实时互动的音视频通话那是 WebRTC 的主场不适合几万人同时观看的大规模直播因为 WebSocket 中心化转发模式撑不住需要靠标准流媒体协议和 CDN也不适合对画质要求极高的场景MPEG1 压缩率摆在那里和 H.264/H.265 没法比画面细节。音频支持薄弱也是短板JSMpeg 对音频同步处理不够完善强行启用经常会遇到音画不同步所以我一般建议直接当纯视频系统用。理解边界比理解优势更重要。你在做技术选型的时候如果发现需求里写着“保证低延迟且支持大规模分发”那可能应该考虑 WebRTC 连麦 CDN 转播混合架构而不是硬把三件套做大。技术方案没有绝对的好坏只有适不适合当前的限制条件。5.3 后续系列规划这篇是总览篇因此只画了整体地图。后续我会按这个顺序继续输出第二篇专门拆解 FFmpeg 编码参数的每个开关到底影响什么把nobuffer、low_delay、GOP size、B 帧这些概念一次说透第三篇做 WebSocket 服务端的深入实现讲清楚背压、广播、鉴权和断线重连让转发层能扛住真实环境的请求第四篇讲前端播放器的细节定制包括多画面网格、错误恢复、低 CPU 渲染策略第五篇再回到实测调优用真实数据对比不同参数组合下的延迟和画面质量。如果你手头有具体的参考场景或奇怪的设备源也欢迎在交流时把你的方案参数一起抛出来我这边能实测的都会帮你实测一遍不能实测的也会梳理清楚排查思路。6. 几个我用下来的经验提示这套方案我从最早折腾到现在差不多快三年踩过的坑比顺利站起来的时候多得多。最核心的一条体会是不要为了“低延迟”这个目标硬堆参数先把系统跑通再逐段量化延迟最后才动手调优。否则很容易进入“参数越调画面越花”的死循环。另一个经验是WebSocket 转发的数据流最好在服务端做好“只转不发、按需丢弃”的控制。一个木桶能装多少水取决于最短的那块板视频链路的短板经常不在程序里而在客户端所在网络的稳定性。弱网情况下与其让客户端吃进一堆追不上的旧帧不如主动降低刷新率让画面慢一点但稳定一点。我做远程看护画面时手动设定服务端每 200 毫秒才给某个弱网客户端发一次最新帧观感立刻就好了很多延迟从 1.5 秒降到 0.9 秒画面也不再频繁花屏。最后还想提一句这套方案别看组件轻但长期维护成本并不完全为零。FFmpeg 版本更替、浏览器策略更新、Node 依赖升级都可能影响行为。如果你追求的是一次性交付后不管的项目可以把它当成标准答案直接用如果你需要一套长期演进、能接进复杂业务系统里的方案那就要给每层留好接口和替换余地。我是从 WebRTC 焦虑期一路折腾过来才定的这个方向现在回头看它算不上完美但胜在诚实、可控、够用。
