简介这份资源围绕 ffmpeg.js 展开面向希望在前端直接完成音视频处理的开发者尤其是需要做浏览器端转码、剪辑或格式转换、又不愿搭建后端服务的同学。它把 FFmpeg 的能力搬进浏览器通过简单 API 即可完成视频转码适合前端进阶与音视频方向的学习者参考。压缩包共 122 个文件约 3.44MB以 61 个 png 截图、27 个 js 脚本、8 个 md 说明、6 个 html 示例页为主另含 yml 配置、json、ts 与少量 avi、wav、ogg 等测试素材覆盖演示页面、源码与文档多个层面。目前已有 6396 人学习下载。资源内提供转码示例代码展示如何加载 worker、写入源文件、执行 transcode 并读取输出还配有网络摄像头、图片转视频、concatDemuxer 等示例页面便于读者理解浏览器端音视频处理的完整链路与目录组织方式快速上手实践。1. 浏览器里跑 FFmpeg为什么前端工程师开始把转码搬到客户端你可能遇到过这种需求用户上传一段手机录的 MOV页面要立刻给出 MP4 预览或者要把几段视频拼起来、抽一帧当封面、把音频转成 WAV 再送进语音识别。传统做法是传到后端用服务器上的 FFmpeg 处理完再回传。问题是上传慢、服务器贵、并发一上来就排队用户还得盯着进度条干等。ffmpeg.js 这类方案解决的就是这件事把 FFmpeg 编译成 WebAssembly配合 JavaScript 胶水层直接在浏览器里跑。它不需要任何后端服务视频不出本地转码、裁剪、抽帧、合成都能在页面里完成。适合谁做在线剪辑、格式转换、素材预处理、隐私敏感场景的前端和全栈工程师。代价也很明确首次要下载十几到几十 MB 的 wasm内存和 CPU 都吃浏览器这一份移动端要谨慎。下面按「能不能用、怎么跑通、参数怎么设、坑在哪」一路讲透。2. ffmpeg.js 到底怎么在浏览器里跑起来WASM 加载与最小可运行闭环2.1 它不是把 FFmpeg 重写了一遍而是编译 胶水FFmpeg 本体是 C 代码浏览器不认识。Emscripten 把 FFmpeg 的 C 源码编译成 WebAssembly 字节码再生成一层 JavaScript 胶水负责内存分配、文件系统模拟和函数调用转发。你在 JS 里调用的ffmpeg.FS、ffmpeg.exec本质是在操作一块 wasm 线性内存里的虚拟文件系统MEMFS。理解这一点后面所有坑都好解释浏览器没有真实磁盘输入文件得先「写进」虚拟 FS输出文件得从虚拟 FS「读出来」再转成 Blob 给用户下载或播放。所谓「无需后端」是把原本服务器上的进程搬进了浏览器沙箱CPU 和内存的账还是得有人付。常见做法有两类一类是ffmpeg/ffmpeg这种封装好的库API 友好适合业务代码另一类是直接加载单文件ffmpeg-core.wasm控制力强但胶水要自己写。新手建议先用封装库跑通再决定要不要下沉。2.2 最小可运行加载 core、写文件、执行、取结果先装依赖再写一个「把输入转成 MP4」的最小闭环。下面这段是能直接抄的骨架import { FFmpeg } from ffmpeg/ffmpeg; import { fetchFile, toBlobURL } from ffmpeg/util; const ffmpeg new FFmpeg(); // 1. 加载 corewasm 和 js 胶水都要就位 async function loadFFmpeg() { const base https://your-cdn.example/ffmpeg-core; // 换成你自己的静态资源地址 await ffmpeg.load({ coreURL: await toBlobURL(${base}/ffmpeg-core.js, text/javascript), wasmURL: await toBlobURL(${base}/ffmpeg-core.wasm, application/wasm), }); } // 2. 转码主流程 async function transcode(file) { await loadFFmpeg(); // 把 File 写进虚拟文件系统名字随便起但要和命令里一致 await ffmpeg.writeFile(input.mov, await fetchFile(file)); // 执行命令参数就是 FFmpeg 原生命令去掉开头的 ffmpeg await ffmpeg.exec([-i, input.mov, -c:v, libx264, -preset, ultrafast, output.mp4]); // 从虚拟 FS 读回结果 const data await ffmpeg.readFile(output.mp4); return new Blob([data.buffer], { type: video/mp4 }); }逻辑说明toBlobURL把远程资源转成同源 Blob URL绕开部分跨域和 MIME 校验问题writeFile是往 MEMFS 写不是写磁盘exec是同步阻塞式的命令执行返回后文件才真正生成readFile拿到的是Uint8Array必须用.buffer才能构造 Blob直接传数组会得到一个内容错乱的 Blob这是新手最常见的翻车点。参数说明-c:v libx264指定视频编码器浏览器里跑 x264 是纯 CPU 计算慢但兼容好-preset ultrafast牺牲压缩率换速度前端场景几乎必选默认medium会让用户等到怀疑人生-i后面必须紧跟输入文件名顺序错了 FFmpeg 会直接报错退出。2.3 进度、日志和中断别让用户对着白屏猜转码是长任务没有反馈用户会以为页面卡死。封装库提供事件钩子ffmpeg.on(log, ({ message }) console.log([ffmpeg], message)); ffmpeg.on(progress, ({ progress, time }) { // progress 是 0~1 的估算值time 是已处理微秒数 updateBar(Math.min(progress, 1)); }); // 需要取消时 ffmpeg.terminate(); // 直接销毁实例之后要重新 loadprogress是估算值遇到某些封装格式会跳变甚至超过 1UI 上要Math.min夹一下。terminate是「后悔药」但代价大实例销毁后虚拟 FS 里的文件全没了必须重新load并重新写文件。想保留中间结果就别轻易 terminate改用短任务拆分。提示首次加载 core 的耗时和体积是体验瓶颈务必配 CDN、开 gzip/brotli并在加载期间给出明确的 loading 状态别让用户以为页面坏了。3. 参数怎么设把 FFmpeg 命令翻译成浏览器能扛的配置3.1 编码器选型libx264 稳、libvpx 慢、硬件编码看运气浏览器 wasm 里能用的编码器取决于编译时开了哪些。常见组合里libx264兼容性和速度平衡最好libvpx-vp8/vp9体积小但慢得多libmp3lame、libopus处理音频够用。硬件加速WebCodecs是另一条路但它和 ffmpeg.js 是两套体系别混着讲。选型建议面向「快速出结果」用libx264 ultrafast面向「体积优先、能等」再考虑 VP9音频抽取用-vn -acodec copy或转libmp3lame。下面这张表是我实际调过的常用参数对照场景关键参数说明快速转 MP4-c:v libx264 -preset ultrafast -crf 28crf 越大越糊28 是速度与画质折中只抽音频-vn -acodec libmp3lame -q:a 4不碰视频流速度快很多截取片段-ss 00:00:05 -t 10 -c copy关键帧对齐时才能 copy否则要重编码抽封面帧-ss 1 -frames:v 1 out.jpg放在 -i 前更快精度略低缩放-vf scale640:-2-2 保证宽高比且为偶数编码器要求3.2 内存与文件大小大文件必须分片别硬刚wasm 线性内存有上限32 位构建通常卡在 2GB 左右实际能用的更少。一个 500MB 的视频写进 MEMFS 再解码峰值内存可能是文件的好几倍直接Out of memory或页面崩溃。血泪经验超过一两百 MB 的输入别指望一次性处理。可行做法是分片用-ss和-t把长视频切成若干段分别转码再拼接。拼接可以用 concat demuxer但要求各段编码参数完全一致// 分段转码后拼接各段必须同编码、同分辨率、同帧率 await ffmpeg.writeFile(list.txt, new TextEncoder().encode( [file part0.mp4, file part1.mp4, file part2.mp4].join(\n) )); await ffmpeg.exec([-f, concat, -safe, 0, -i, list.txt, -c, copy, merged.mp4]);-safe 0允许列表里出现相对路径以外的写法本地虚拟 FS 场景一般要加。-c copy不重编码秒级完成但前提是各段参数一致否则拼接处会花屏或音画不同步。分片时每段尽量切在关键帧上用-ss放在-i前做快速定位。3.3 线程与性能wasm 多线程不是默认就开Emscripten 编译时可以开 pthread但需要页面满足跨源隔离条件COOP/COEP 响应头否则SharedArrayBuffer不可用多线程直接失效。很多「为什么我的 ffmpeg.js 这么慢」的问题根子在这里。检查方法在控制台看crossOriginIsolated是否为true。为false就说明没开隔离多线程版 core 跑不起来。要开隔离服务端得返回# 静态资源服务需要带的响应头 Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp注意开了 COEP 之后页面里所有跨域资源图片、脚本、字体都必须带 CORP 头或走 CORS否则会被拦。这是典型的「开了一个功能坏了一片资源」上线前要全量回归。单线程 core 虽然慢但没有这些约束小文件场景反而更省心。提示性能调优的顺序应该是「先减输入体积 → 再选 ultrafast → 最后才考虑多线程」。很多人一上来折腾线程结果输入是个 4K 原片怎么调都慢。4. 避坑与排查ffmpeg.js 在真实项目里最容易翻车的 5 个点4.1 现象readFile 拿到的 Blob 播放花屏或直接损坏原因readFile返回Uint8Array直接new Blob([data])在某些环境下会把类型信息丢掉或按字符串处理字节被破坏。解决统一用new Blob([data.buffer], { type: video/mp4 })并确认data确实是Uint8Array而不是字符串。如果 core 版本返回的是字符串要先TextEncoder转回字节。4.2 现象命令执行后报「output file not found」原因命令里的输出文件名和readFile读的名字不一致或者exec因为参数错误提前失败但没抛异常你以为成功了。解决监听log事件把 FFmpeg 的 stderr 打出来真正的错误信息都在里面。养成「exec 后先 readFile 再判断」的习惯读不到就说明命令没成功别急着往下走。4.3 现象移动端 Safari 加载 core 后直接崩溃原因iOS 对 wasm 内存和单页内存限制更严大 core 加上大文件很容易触发进程被杀且没有明显报错。解决移动端限制输入体积优先用单线程小 core必要时降级到「上传后端处理」。别在低端机上硬跑大文件用户体验和崩溃率都扛不住。4.4 现象开了多线程反而更慢或直接报 SharedArrayBuffer 未定义原因页面没满足跨源隔离或者 CDN 缓存了不带 COOP/COEP 的旧响应。解决确认crossOriginIsolated true检查响应头是否被 CDN 覆盖清缓存重试。不满足条件就老老实实用单线程 core。4.5 现象连续处理多个文件后内存只涨不降原因虚拟 FS 里的文件不会自动清理terminate之外的实例会一直持有内存。解决每个任务结束后主动deleteFile删掉输入输出或者干脆每个任务用独立实例并在完成后terminate。长会话页面尤其要注意否则跑十几个文件后必崩。5. 进阶把 ffmpeg.js 用稳的三个具体技巧第一个技巧是「预检 降级」。在真正转码前先用ffmpeg.exec([-i, input, -f, null, -])探测输入信息从 log 里解析出时长、分辨率、编码格式据此决定用哪套参数、要不要分片。探测本身很快能避免「跑到一半才发现参数不对」的浪费。解析 log 时用正则抓Duration和Stream行即可别引入额外依赖。第二个技巧是「Worker 隔离」。把 ffmpeg 实例放进 Web Worker主线程只负责 UI 和消息传递。这样即使转码把 CPU 打满页面也不会卡到无法点击。通信时注意Uint8Array的 transferable 用法用postMessage(data, [data.buffer])转移所有权避免大数组的结构化克隆开销。Worker 里同样要处理加载失败和 terminate 的清理。第三个技巧是「结果校验」。转码完成后不要直接给用户下载先做一次轻量校验读回文件头判断容器格式是否正确或者用-f null -再跑一遍确认能正常解码。这一步能拦住大部分「文件生成了但其实是坏的」情况。校验通过再生成下载链接失败则提示重试并上报日志。技巧解决的问题代价预检 降级参数不匹配、中途失败多一次快速 execWorker 隔离主线程卡死通信和生命周期管理变复杂结果校验坏文件流出多一次解码开销我自己的习惯是任何要上线的 ffmpeg.js 功能先在目标机型的最低配设备上跑一遍最大预期文件跑通了再谈优化。浏览器转码这件事能跑通和跑得稳之间隔着一堆内存和兼容性的坑别拿开发机的表现当基准。希望帮到你。本文还有配套的精品资源点击获取