背景知识

视频编辑类产品，如何做技术选型？

首先我们需要了解一点基础知识，一个视频文件主要由两部分组成：封装层和图像帧编码数据。

• 封装层就像是视频的"外壳"， 在整个视频文件中体积占比通常比较小。而真正的"大头"是图像帧数据， 它占据了视频文件的绝大部分空间！
• 图像帧的编解码过程，也就是压缩和解压的过程，计算量是非常巨大的。
• 这也是为什么我们通常优先使用 GPU 硬件加速的原因，因为 CPU 处理起来实在太慢了。

理解了这个基础，我们再来看看现在市面上主流的三种技术方案。

Native 方案

第一种是原生 Native 方案。它的实现原理主要是通过 FFmpeg 这类音视频处理库，或者直接调用操作系统的视频编解码能力。

优点是

• 生态非常丰富，各种功能应有尽有
• 兼容性也很好，能处理各种格式的视频
• 用户体验丝滑流畅

缺点是

• 用户需要下载安装，操作的学习成本也更高
• 开发成本相对较高，需要深入了解底层技术

B/S 方案

第二种是 B/S 方案，也就是浏览器+服务器的架构。它的实现原理是前端用 Web 技术做出 UI 界面，将用户操作数据与素材上传到服务器，服务器用 Native 方案处理视频，两者结合。

优点是

• 使用便捷，浏览器打开网页即可
• 稳定性，将 Native 方案部署在服务端，消除不确定因素
• 不挑用户设备，浏览器版本低、配置差的设备也能用

缺点是

• 视频预览和最终合成结果可能不一致，因为用户预览的是前端模拟的效果
• 服务器资源可能排队，高峰期要等待，用户的交互响应可能会有延迟
• 成本昂贵，既要前后端协作开发，又要承担服务器的计算、带宽、存储成本

纯 Web 方案

第三种是纯 Web 网页编辑方案，这是近年来因 Web 开放了新的 API 才逐渐流行。

它的实现原理是使用浏览器提供的 WebCodecs API，让 JS 能够间接调用系统的编解码能力。

优点是

• 使用非常便捷，跟 B/S 方案一样，打开浏览器就能用
• 跨平台，不管是 Windows、Mac 还是 Linux 都能用
• 开发成本极低，前端工程师就能独立搞定

缺点是

• 生态还不够成熟，开源社区还没有丰富可用的配套工具
• 浏览器版本兼容性问题，旧版本浏览器可能不支持

对比分析

我们从几个维度来对比这三种方案

• 成本方面：Web 优于 Native 优于 B/S （这里的成本包括 学习开发成本、服务的运行成本）
• 便捷性方面：B/S 等于 Web 优于 Native
• 生态方面：Native 优于 B/S 优于 Web
• 兼容性：B/S 优于 Native 优于 Web

• 性能体验方面：Native 优于 Web 优于 B/S

  • Native 最快，Web 其实比较接近了
  • B/S 方案在用户操作过程中可能出现延迟，它的合成速度理论上最快的，但因为计算资源是所有用户共享的，往往需要等待更长的时间（除非vip用户独享一路服务器资源）

未来趋势

展望未来，我个人认为会有这样的发展趋势：

• Native 方案维持现状 成为专业人士的专属工具，就像达芬奇、PR、Final Cut Pro 一样
• B/S 方案像是在 Web 没有视频编辑能力之前， 为了便捷性的妥协的方案，因为成本和用户体验的问题，加上 Web 技术发展，会逐渐挤占该方案的生存空间
• Web 加 AI 的组合会成为面向大众用户的主流方案， 现在已经看到越来越多的创新产品使用这个方案来处理音视频

选择建议

那么当下该如何选择呢？

首先要考虑你的团队技术积累。 如果团队在某个方向有深厚积累，优先考虑发挥优势。

然后根据具体的产品需求来选择：

选择 Native 的情况：

• 需要影视级的音视频处理能力
• 要用到最新的编解码技术或特殊硬件
• 产品功能复杂，需要成熟的生态能力支持

选择 B/S 的情况：

• 不差钱，预算充足
• 对兼容性零容忍，要求支持绝大部分用户，甚至包括手机用户

如果看了上面的分析内容，还没有确定的答案：

• 建议在调研阶段先用 Web 方案，验证当前能力是否满足你们的核心诉求；因为 Web 方案的优势就是成本小，能快速验证；