为什么我们构建了一个浏览器端视频处理工具

当我们着手为网络构建视频工具时，传统观点很明确：视频处理属于服务器端。上传文件，运行 FFmpeg，返回结果。简单、成熟，但受到带宽、成本和隐私的严重限制。

我们认为一定有更好的方法。事实证明，确实有——而且它一直都在我们的浏览器中。

现状：ffmpeg.wasm

在过去几年中，ffmpeg.wasm 一直是浏览器内视频处理的首选解决方案。它将 FFmpeg 编译为 WebAssembly，让您可以在浏览器中直接访问完整的 FFmpeg 工具包。它确实有效，但伴随着显著的缺点：

• 庞大的捆绑包大小：ffmpeg.wasm 核心约为 25MB，加上特定格式的编解码器可达 30MB 以上
• 初始化缓慢：在任何处理开始之前加载一个 25MB 的 WebAssembly 模块
• 默认单线程：无法访问硬件加速
• 内存限制：WebAssembly 线性内存限制（4GB）对大文件处理造成问题
• 无硬件解码：仅支持软件解码/编码，完全缺少 GPU 加速

在我们的基准测试中，使用 ffmpeg.wasm 以 70% 质量压缩一个 50MB 的 MP4 视频需要 45-60 秒。不算太差，但也算不上好。

WebCodecs 方法

WebCodecs API 是一个相对较新的浏览器 API，它提供对浏览器原生媒体编解码器的直接访问——与 YouTube、Netflix 和所有其他流媒体平台用于视频播放的编解码器相同。主要优势：

• 硬件加速：在可用时使用 GPU 进行解码和编码
• 零捆绑包开销：没有 WebAssembly，没有编译的二进制文件——它是一个原生浏览器 API
• 快速初始化：立即可用，无需加载时间
• 全面格式支持：H.264、H.265、VP8、VP9、AV1 — 无论您的浏览器支持什么

问题是？WebCodecs 是低级的。您需要处理解复用、逐帧编码、容器格式化以及介于两者之间的一切。这需要大量的底层工作。

mediabunny 登场

我们构建了 mediabunny — 一个轻量级库，用简单、符合人体工程学的 API 封装了 WebCodecs。它处理复杂的部分：

• 自动解复用：检测容器格式并提取视频/音频流
• 帧级控制：访问单个帧进行精确编辑
• 智能重新编码：可配置的质量预设，带有实时进度
• 内存高效流处理：分块处理帧，而不是一次性处理所有帧

性能比较

全面提速 3-5 倍，内存使用量显著降低，并且零捆绑包开销。

隐私：杀手级功能

性能固然重要，但真正让浏览器端处理脱颖而出的是：架构层面的隐私。

使用基于服务器的工具，您是在将数据委托给他人。即使是善意的服务，其服务器也可能被入侵、被传唤或配置错误。使用 VideosKit：

• 文件绝不会离开您的设备——字面上没有用于文件上传的服务器端点
• 无 Cookie，无跟踪，无文件内容分析
• 加载后可离线工作——在飞机上、受限网络中，任何地方都能处理视频
• 对敏感内容的企业友好——无数据驻留或合规性担忧

开发挑战

构建它并非没有挑战：

大文件处理

浏览器不提供随机文件访问。我们使用 File API + 流式处理来逐帧处理视频，而无需将整个文件加载到内存中。这需要仔细的缓冲区管理和垃圾回收调优。

跨浏览器兼容性

WebCodecs 在 Chrome 94+、Edge 94+ 和 Safari 16.4+ 中受支持。Firefox 在版本 130 中添加了支持。我们检测功能并为不支持的浏览器优雅地回退到一条消息。

内存管理

视频帧很大——单个 4K 帧未压缩时约为 33MB。我们实现了帧池化和流式管道，以控制内存使用，即使是 4K 内容也不例外。

进度报告

用户需要知道等待多长时间。我们构建了一个回调系统，根据帧位置报告进度，提供准确的实时更新。

开源

VideosKit 和 mediabunny 都是开源的。查看代码：

• VideosKit：github.com/nicely-gg/video-tools
• mediabunny：github.com/nicely-gg/mediabunny

欢迎贡献、提出问题和提供反馈。

浏览器端视频的未来

WebCodecs 仍在不断发展。AV1 编码、WebGPU 驱动的处理以及改进的 MediaSource Extensions 将使浏览器端视频更加强大。我们很高兴能突破可能性的边界。

如果您还没有尝试过 VideosKit，请访问 videoskit.cc。压缩、转换、剪辑或检查视频——所有这些都在您的浏览器中，全部免费。