项目路线图

本页面概述了 ffmpeg.wasm 的当前状态、已知限制以及未来的开发计划。其中包括从旧版本迁移的技术细节，以及 WebAssembly 环境施加的具体约束。

当前项目状态

ffmpeg.wasm 在 0.12.0 版本进行了重写，以采用基于 TypeScript 的单仓库（monorepo）结构。该项目现在支持官方的 Web Worker 执行，并为单线程（@ffmpeg/core）和多线程（@ffmpeg/core-mt）执行提供了独立的包。

版本迁移（0.11.x 到 0.12+）

0.12+ 版本引入了破坏性 API 更改，以提高一致性并支持 async/await 等现代 JavaScript 模式。

0.11.x 功能0.12+ 对应项备注
import { createFFmpeg } from '@ffmpeg/ffmpeg'import { FFmpeg } from '@ffmpeg/ffmpeg'基于类的实例化
createFFmpeg()new FFmpeg()配置移至 ffmpeg.load()
await ffmpeg.run(...args)await ffmpeg.exec([...args])重命名以提高清晰度
ffmpeg.FS.writeFile()await ffmpeg.writeFile()移至顶层异步
ffmpeg.exit()ffmpeg.terminate()更好地反映 worker 生命周期
ffmpeg.setLogger()ffmpeg.on("log", callback)事件驱动架构
import { fetchFile } from '@ffmpeg/ffmpeg'import { fetchFile } from '@ffmpeg/util'移至工具包

已知限制

WebAssembly 环境施加了几个硬性约束，定义了项目的技术边界。

1. 性能和内存

  • WASM 与原生: WebAssembly 的执行速度显著慢于原生执行。多线程（mt）版本的速度可提升约 2 倍，但会消耗更多的 CPU 和内存
  • 2 GB 文件限制: 由于 WebAssembly 当前的内存寻址约束，输入文件存在 2 GB 的硬性限制

2. 网络和 Node.js

  • RTSP 支持: 目前不支持，因为 WebAssembly 缺乏原始套接字功能
  • Node.js 支持终止: 为了专注于浏览器特定的优化并减少维护开销，0.12.0 版本起官方不再支持 Node.js

3. 安全要求

多线程需要 SharedArrayBuffer，这 necessitates 特定的 HTTP 头以实现跨源隔离：

  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp

未来路线图

项目的演进侧重于利用新的 WebAssembly 特性并优化构建流水线。

短期目标

  • WebAssembly 内建函数: 研究使用 SIMD 和内联汇编代码来缩小与原生 FFmpeg 的性能差距
  • 库扩展: 在 Docker 构建过程中添加对更多流行外部库的支持
  • 构建优化: 进一步优化基于 Docker 的多阶段构建，以减少特定用例的二进制文件大小

代码实体映射：Build 到 Core

项目路线图

社区与贡献

该项目正在积极寻求维护者，协助完成转译 FFmpeg 庞大功能集这一复杂任务。

贡献工作流程

  1. 环境设置: 多阶段构建流水线需要 Docker 23.0+
  2. 核心开发: 大部分社区工作集中在 @ffmpeg/core 上，用于添加新编解码器或优化标志
  3. 依赖更新: 通过 build/*.sh 脚本管理，这些脚本为 Emscripten 配置 zimg、x264 和 libvpx 等库

代码到系统映射：Utility & Core

项目路线图