桌面视频剪辑软件调研

目标：做一款基础桌面端视频剪辑软件（非线性编辑，NLE）。本文记录概念澄清、技术选型、难点分布、FFmpeg 商业合规方案与功能边界，以及「能不能接 API 自动剪辑」的现状。调研时间：2026-07。结论以「可落地的最小可用产品」为导向，不对标 Premiere / DaVinci。

怎么用这份笔记

定方向 → 看 §2 产品边界、§11 待决问题
选技术 → 看 §3-§5
评估工期与风险 → 看 §6
要卖钱/上架 → 必看 §7-§8
只想自动批量出片 → 直接跳 §9-§10

具体项目的落地方案（Tauri 工具箱 TooBox 也盒）见 TooBox 视频剪辑集成方案。

1 · 线编与非线编

1.1 线编（Linear Editing）

按时间顺序、一条带子往下剪的方式。

素材在磁带等顺序介质上，只能从头到尾顺序访问
剪辑流程：选 A 段录到母带 → 再接 B 段 → 再接 C
改中间某一刀往往要重录后面整段，插入/删减成本极高
典型时代：磁带对编、早期电视台机房

1.2 非线编（Non-Linear Editing，NLE）

素材数字化后，在电脑上任意跳转、任意修改任意位置。

磁盘/SSD 随机读取任意片段
时间线只存素材引用 + 入点/出点，一般不修改原始文件（非破坏编辑）
中间插入、删除、调序、撤销都很方便
Premiere、DaVinci、剪映、Shotcut 都属于 NLE

TIP

📌 打个比方：线编像用录音笔顺序录歌，中间要插一句往往得整段重录；非线编像用文档编辑器，光标点哪改哪，不用从第一页重打。这就是「非线性」的全部含义——修改位置不受播放顺序约束。

1.3 对比一览

维度	线编	非线编（NLE）
访问方式	顺序	随机
改中间	很难，常牵动后面	容易
素材形态	磁带实剪/实拷	数字文件 + 时间线
预览	依赖放机/录机	软件时间线实时预览
现状	基本淘汰	行业标准

1.4 现在还有线编吗

日常能接触到的剪辑几乎全是非线编。线编现在主要作为历史概念，用来解释「非线」到底非在哪里。

TIP

📌 注意区分「非线编」和「非破坏」：非线编强调能不能随便跳时间改任意位置；非破坏强调改的是「怎么用素材」而不是源文件。现代 NLE 几乎都同时是非破坏的，但两者不是同一个概念。

2 · 产品边界定义（MVP 范围）

「基础」应收敛为最小可用 NLE，而不是对标专业后期套件。

能力	MVP 必做	可后置
导入多格式素材	是
时间线裁剪、分割、拼接	是	多轨无限层
预览播放 / seek	是	实时特效预览
导出 MP4	是	多码率 / 硬编全覆盖
项目保存 / 打开	是	OTIO 工程互通
转场、字幕、调色、关键帧		是
AI 字幕 / 智能分镜		是

TIP

📌 为什么要先砍范围？视频剪辑软件的复杂度不在功能数量，而在时间线状态、预览、导出三者必须始终一致。三者对齐之前加特效，等于在流沙上盖楼——每加一个效果，都要同时在预览和导出两条管线里维护，返工量指数级上升。

3 · 业界两条技术路线

3.1 路线 A：专业开源 NLE（原生性能）

项目	UI	媒体引擎	特点
Shotcut	Qt 6	MLT + FFmpeg	模块清晰、成熟；C++/Qt 门槛高
Kdenlive	Qt / KDE	MLT + FFmpeg	功能全，构建依赖重
OpenShot	Python + Qt	libopenshot(C++) + FFmpeg	UI 易改，底层仍是 C++

共同点：解码、合成、预览交给 MLT 或自研 C++ 引擎，性能上限高，但要求团队掌握 C++ 与复杂构建链。

Shotcut 的分层可作为标准参考：

组件	职责
MainWindow	主界面容器，管理 dock / 菜单 / 工具栏
MLT::Controller	UI 与 MLT 引擎之间的桥（打开、播放、seek、滤镜、XML 工程）
Player	播放、传输控制
Timeline	多轨编辑
Filter	效果与处理
Encode	导出编码

3.2 路线 B：Web 桌面 + FFmpeg（现代独立/AI 向）

近年大量新项目采用这套：

UI (React)  →  IPC  →  Main (Node/Rust)  →  FFmpeg 子进程
      ↑
  时间线状态（非破坏 EDL）

代表项目形态：

Electron + React + FFmpeg 的多轨编辑器（部分还导出 OpenTimelineIO 工程）
Electron + React + Zustand + FFmpeg 的轻量 MVP，几周即可完成导入 / 时间线 / 裁剪 / 导出
Electron + FFmpeg + SQLite 的 AI 工作流型编辑器

3.3 开源 NLE 全景

按底层引擎归类，比按名气排序更有参考价值。

MLT 系（引擎共用）

项目	UI	特点	许可
Kdenlive	Qt / KDE	功能最全的开源 NLE：代理、多轨、关键帧齐全	GPL
Shotcut	Qt 6	同引擎，结构清爽，MLT 官方推荐入口	GPL
Flowblade	Python + GTK	Linux 为主，操作偏「片段插入」流派	GPL

TIP

📌 三个知名项目共用一套引擎，这件事本身就是结论：视频编辑最难的部分（解码、合成、渲染）值得复用现成引擎，而不是每个团队重写。「引擎复用 + 自己做 UI」是投入产出比最高的路子——这也是为什么路线 B 用 FFmpeg 而不是自研解码器。

自研引擎系

项目	技术	特点	许可
Olive	C++ / Qt + 自研渲染	节点式，OpenColorIO 色彩管理，专业方向，长期重写中	GPL
OpenShot	Python/Qt + libopenshot(C++)	库可被外部程序调用（有 Python 等绑定）	GPL（UI）/ LGPL + 商业双授权（libopenshot）
Cinelerra（含 GG 分支）	C++	历史悠久、功能猛，UI 上古	GPL

其他框架系

项目	引擎	备注
Pitivi	GStreamer + GES	GNOME 出身；GES 本身也是可编程的编辑库
Blender（VSE）	Blender 自研	顺手能剪，Python 可脚本化，但不是专业 NLE

工具型（不是 NLE，但很有名）

项目	用途
LosslessCut	无损切 / 拼（Electron + FFmpeg），接近本项目 MVP 的最小形态
Avidemux	简单剪切、滤镜、转码
HandBrake	只转码，不剪
auto-editor / MoviePy	命令行 / Python 自动剪，适合批量

NOTE

DaVinci Resolve、Lightworks 不是开源（免费 ≠ 开源）。Resolve 有官方脚本 API，但前提是装了 Resolve——与 §9.3 的 Premiere 情况类似。

最值得借鉴的三个

想学什么	看谁
Electron + FFmpeg 的最小闭环（导入、切、导出、进度解析）	LosslessCut
时间线语义与编辑命令模型（分割 / ripple / 吸附如何定义）	Shotcut
多轨工程 XML 化 + 命令行渲染（自动剪也能复用）	MLT / Kdenlive 工程格式

许可提醒

Kdenlive / Shotcut / Olive / Cinelerra 多为 GPL
libopenshot 是 LGPL + 商业双授权，闭源商用时比 GPL 项目友好（但其依赖 FFmpeg、JUCE 等各有自己的许可，需单独确认）
读源码学设计没问题；抄代码进闭源产品必须先看协议

3.4 结论

团队与目标	选路线
偏前端 / 全栈，要快速做出基础剪辑	路线 B
要 Shotcut 级实时合成与专业性能	路线 A

4 · 桌面壳选型

维度	Electron	Tauri 2	Qt (C++/QML)
安装包	大（约 150–300 MB，再加 FFmpeg）	小（约 10–40 MB）	中等
渲染一致性	自带 Chromium，WebCodecs/WebGPU 稳定	依赖系统 WebView，媒体 API 有差异	原生最佳
调 FFmpeg	Node `spawn` 极成熟	Rust 侧 spawn，也成熟	可链 MLT / FFmpeg 库
内存（空应用）	约 100–150 MB	约 30–60 MB	低
团队门槛	Web 栈最低	需要 Rust	C++ 最高
适合	基础剪辑 MVP、快速验证	在意体积与内存	长期专业 NLE

TIP

📌 为什么做视频编辑反而更推荐"重"的 Electron？因为编辑器最怕渲染与解码行为在用户机器上不一致。Electron 捆绑固定版本 Chromium，开发时 WebCodecs / WebGPU 能跑，用户机器上大概率也能跑；Tauri 用系统 WebView（Windows WebView2 / macOS WKWebView / Linux WebKitGTK），媒体能力随系统版本漂移。对渲染引擎来说，这种不确定性是风险而不是节省。

情况	选择
默认（基础剪辑）	Electron + React + TypeScript + Vite + FFmpeg
强约束包体 / 内存，且接受 WebView 差异	Tauri 2 + React + FFmpeg
目标是 Shotcut 级实时合成	Qt + MLT（工期数量级不同）

5 · 推荐架构（MVP）

┌─────────────────────────────────────────┐
│  Renderer: React                         │
│  · 素材库 · 预览器 · 时间线 · 导出面板     │
│  · 状态: Zustand / 自研 Timeline Store    │
└─────────────────┬───────────────────────┘
                  │ IPC (invoke / event)
┌─────────────────▼───────────────────────┐
│  Main: 文件、项目 JSON、FFmpeg/ffprobe    │
│  · 元数据探针 · 缩略图 / 波形 / proxy      │
│  · 时间线 → filter_complex / concat       │
│  · 解析 stderr 回传进度                   │
└─────────────────┬───────────────────────┘
                  │ child_process
        FFmpeg（随包分发，勿打进 asar）

5.1 四个关键设计点

设计点	说明
非破坏编辑	时间线只存素材引用 + in/out + 轨道位置，不改源文件；工程用 JSON，后续可兼容 OpenTimelineIO
预览与导出两条管线	预览用 `<video>` / WebCodecs 播 proxy 或原片片段；导出由 Main 生成 FFmpeg 命令
Proxy 代理文件	长 4K 素材先转低码率代理，预览卡顿显著减少（建议 Phase 2）
打包	FFmpeg 走 `extraResources` 解包，分平台二进制，CI 矩阵构建

5.2 技术栈建议

层	建议
桌面	Electron + electron-vite / Electron Forge
UI	React + TypeScript + Tailwind
状态	Zustand（时间线 + 选中 clip）
媒体	随包 `ffmpeg` + `ffprobe`
工程存储	本地 JSON（可选 SQLite）
测试	Vitest（时间线纯逻辑）+ 导出冒烟脚本
分发	electron-builder（Win NSIS / macOS dmg）

6 · 难点分布与风险

6.1 真正难的核心三块

难点	为什么难
时间线状态机	in/out、轨道位置、重叠、空隙、分割合并、吸附、ripple、undo/redo；且必须保证预览 / 导出 / 存盘用同一套模型
预览体验	多段连续播、seek、切点顺滑、音画同步；4K 直接播原片会卡
导出编译	把时间线编译成 FFmpeg 命令：trim、拼接、时间基、变帧率、缺音轨、进度、取消、路径含中文空格

6.2 工程上很烦的部分

点	麻烦在哪
格式兼容	同为 MP4，编码 / 旋转元数据 / VFR / 损坏文件坑很多
大文件与内存	缩略图、波形、代理文件的生成与缓存
FFmpeg 分发	体积、许可、asar 不能塞二进制、三平台各一套
Electron 性能	主进程不能堵、IPC 不能传大帧
工程文件	素材路径迁移、相对路径、缺失素材（offline clip）

6.3 应该后放的

实时多轨 GPU 合成、完整调色节点、关键帧动画、全平台硬编统一、AI 生成类功能。

6.4 难度曲线

简单 ──────────────────────────────────────── 很难
 │                                              │
选文件 / ffprobe        单轨 trim + split      多轨 + 音频
单段 <video> 播放       按 EDL 稳定导出 MP4     帧级音画同步
存 JSON 工程            撤销 / 吸附 / ripple    实时特效预览
                        proxy 与缓存策略        专业调色与合成

目标	难度	体感（1 人熟 Web）
导入、裁切、拼接、导出	中	几周出可演示 MVP
不卡、少崩、杂格式也能导	中高	需持续打磨
接近剪映 / Shotcut 流畅度	高	年月级投入

6.5 三个最大风险

过早做特效 / 多轨，核心时间线不稳
预览与导出两套逻辑不一致（预览对导出错，或反之）
只用自己电脑上的干净 MP4 测试，用户一丢手机原片就崩

TIP

📌 难度不在「会不会用 FFmpeg」，而在于用一个可靠的时间线模型把预览和导出对齐，并在真实杂乱素材上扛住性能与兼容性。

7 · FFmpeg 许可与专利

以下为工程调研整理，不构成法律意见。正式商业销售、上架前应由法务或专利顾问确认。

7.1 两条独立的线

很多人把「FFmpeg 要不要版权」问成一个问题，实际是两件事：

事项	含义
FFmpeg 软件许可	开源协议（LGPL 2.1+ / 启用某些组件时为 GPL），约束源码与分发方式
视频编码专利	H.264 / H.265 等标准的专利池，商用大规模分发时可能需要授权

TIP

📌 不需要向 FFmpeg 项目付版权费。FFmpeg 是开源的，关键在于你怎么编译、怎么随软件分发、你的产品用什么许可证。而 H.264 专利是另一条完全独立的线——即使 FFmpeg 协议完全合规，专利问题依然存在。

7.2 GPL 传染的简化理解

若分发的是 GPL 版 FFmpeg，且与你的程序构成 GPL 意义上的组合作品，可能要求你的应用也按 GPL 开源
独立进程调用 ffmpeg 可执行文件 + LGPL 构建，是很多闭源桌面工具降低风险的常见做法，但仍须遵守对应许可证的全文义务
开源项目（如 Shotcut）直接用 GPL 全家桶，与「闭源商业」是完全不同的策略

8 · 低风险商业方案与功能限制

8.1 四条总原则

只分发 LGPL 构建的 FFmpeg，不要 GPL 大全包
独立 ffmpeg / ffprobe 可执行文件，进程调用，不静态链进主程序
编码走系统 API；FFmpeg 侧重解封装、解码、剪辑滤镜
安装包内附 LICENSE / COPYING / NOTICE，并提供第三方开源说明

8.2 推荐形态

你的 App（闭源，任意协议）
    │  spawn / CreateProcess
    ▼
ffmpeg / ffprobe   ← 独立文件，LGPL 构建
    │
    ├─ 解码、demux、trim、concat、scale、overlay…
    └─ 编码：优先系统编码器，不捆绑 x264 / x265

做法	建议
`child_process` 调外部 `ffmpeg`	建议
静态链接 libav* 进闭源二进制	不建议
捆绑 libx264 / libx265 / fdk-aac	不建议
使用需 `--enable-gpl` / `--enable-nonfree` 的组件	不建议
自己编译并归档 configure 参数	建议

8.3 构建方向

自行编译，或选用明确标注 LGPL、无非自由组件的构建，核心思路：

--enable-gpl=no
--enable-nonfree=no
--disable-libx264
--disable-libx265
--disable-libfdk-aac

解码端尽量保留（兼容面靠它），只在编码端做取舍。

8.4 各平台导出通道

平台	导出编码
Windows	Media Foundation：`h264_mf`（音频用系统 AAC 通道）
macOS	VideoToolbox：`h264_videotoolbox` / `aac_at`
Linux	无统一系统编码器；VAAPI / NVENC 碎片化，或依赖发行版 FFmpeg

建议先发 Windows + macOS，Linux 另议。

8.5 安装包合规清单

YourApp/
  YourApp.exe
  resources/
    ffmpeg/ffmpeg(.exe)
    ffmpeg/LICENSE
    ffmpeg/COPYING.LGPLv2.1
    ffmpeg/NOTICE        # 构建说明 + 版本号 + 源码获取地址
  licenses/
    THIRD_PARTY.html     # FFmpeg / Electron / …

应用内提供「关于 → 开源许可」入口；官网或安装目录提供对应版本的 FFmpeg 源码与 configure 脚本。

8.6 专利策略对比

策略	风险	说明
A. 系统编码器	最低	专利义务多在 OS / 硬件厂商侧
B. 商业编解码 SDK	低（付费换确定性）	合同中写清再分发条款
C. 捆绑 x264 导 H.264	偏高	协议与专利都要单独处理
D. 只导 ProRes / VP9 / FFV1	视产品	可回避 H.264 叙事，但用户体验受损

收费、上架、公司主体销售：选 A 或 B。

8.7 功能限制：这样做之后有什么代价

这是最容易被忽略、但必须说清楚的部分。

几乎不受影响

读常见封装（MP4 / MOV / MKV）与手机、相机素材
解码 H.264、常见 AAC 音轨
非破坏时间线：in/out、分割、删除、排序
重编码导出 H.264 + AAC 的 MP4
缩放、裁切、pad、基础叠加与淡入淡出
缩略图、波形、ffprobe 元数据
切点落在关键帧时的 stream copy 无损裁切

硬限制

能力	状态
x264 / x265 软件编码调参	不捆绑
libfdk-aac 音频调优	不捆绑
nonfree 组件	不适用
仅 GPL 提供的库 / 滤镜	不适用
ProRes / DNxHR 专业交换格式	不在此路径
HEVC / AV1	取决于系统与硬件，不能作为默认承诺
FFmpeg 作为进程内低延迟实时特效引擎	架构不适合

软限制（能做但会打折）

项目	相对 x264 的差距
码率模式	CRF 等细调能力弱一档，多为 bitrate / 质量档位
画质体积比	同体积往往略差且不易控
参数丰富度	远少于 x264
跨机器一致性	同一时间线在不同电脑导出可能有差异（驱动、GPU、OS）
无独显 / 老机器	MF 异常时可能失败或极慢，需回退策略

其他软限制：

精确到帧的裁切必须重编码；-c copy 只在关键帧附近准
较新 HEVC / HDR / 10bit：能解不一定能好预览，HDR 转 SDR 要自己做
专业相机 RAW、冷门 MXF：精简构建可能直接不支持
滤镜生态更瘦：基础滤镜可用，frei0r 等大量插件不在其中
Linux 是二等公民

TIP

📌 产品话术应该是「导出为兼容 MP4」，而不是「电影级可控编码、全平台像素级一致」。系统编码器换来的是合规与省事，代价是编码可控性与跨机一致性。这个取舍要提前写进产品说明，而不是等用户投诉画质时再解释。

与「满血 FFmpeg（GPL + x264）」的用户可感知差异

维度	低风险方案	满血方案
剪辑 / 时间线	一样	一样
导出 MP4 能否播放	一样能	一样能
画质 / 体积极致调优	弱	强
全平台导出一致性	弱	较强
冷门格式	更弱	更全
滤镜插件生态	更瘦	更全
HEVC / HDR 工作流	不完整	相对完整
闭源商业合规叙事	清晰	别扭

应写进产品说明的诚实限制

导出依赖操作系统自带的硬件 / 系统编码器，极少数环境可能无法导出
不同电脑导出的画质与速度可能略有差异
精确到帧的剪辑会重新编码
支持格式以列表为准，不保证专业 / 冷门摄像机全覆盖
高级特效与专业色彩管线不在基础版范围
Linux / HEVC / HDR 为实验性或不支持

小结

不是「用了低风险方案就做不了剪辑」，而是剪辑逻辑完整，但编码与生态收窄：少了 x264 级掌控、少了 GPL 插件全家桶，Linux / HEVC / 专业格式需降级或砍掉。对基础 NLE 而言这个代价可接受；对专业后期则是故意不覆盖。

9 · 剪映 / Premiere 的 API 现状

9.1 剪映 / CapCut：没有官方开放剪辑 API

需求	现状
官方公开、开发者可自由调用的剪辑 API	没有
在自己 App 里调用「剪映帮我导出 / 加字幕」	不行
网上的「剪映 API / 小助手」	第三方非官方

海外 CapCut 曾有插件形态的开放能力（如 ChatGPT 插件、编辑器内插件平台），属于限定场景，不是通用的服务端渲染 API。

9.2 非官方「剪映小助手」是什么

原理很朴素：用程序生成剪映能打开的草稿，或遥控剪映导出。

剪映桌面版工程本质是本地文件：

草稿文件夹/
  draft_content.json   ← 时间线、素材、字幕等
  draft_info.json
  素材文件…

这类工具做的事：

按剪映格式写 / 改这些 JSON（加视频、音频、字幕、轨道）
把草稿放进剪映草稿目录
用剪映打开精修，或用 UI 自动化模拟点击「导出」

常见形态：

类型	说明
Python 库	代码里拼草稿（如 pyJianYingDraft 一类）
HTTP 小助手	REST 接口：建草稿、加素材、加字幕（如 capcut-mate 等）
云端 / 付费包装	上面再包渲染与模板
UI 自动化导出	本机装剪映，脚本点导出（多为 Windows）

风险：非官方无 SLA；剪映升级后草稿结构一变就失效；可能违反用户协议；来路不明的服务涉及素材与账号安全。

TIP

📌 剪映小助手 ≠ 剪映 API。它本质是「伪造 / 生成剪映工程文件的第三方工具」，渲染仍然依赖剪映本体。当个人脚本或参考实现可以，当商业产品的核心架构不行。

9.3 Premiere Pro：有官方扩展 API，但不是云 API

说法	实际情况
有没有官方 API	有
是不是公网 REST API	不是
怎么用	在已安装的 Premiere 里跑插件 / 脚本

UXP（现在主推）：现代 JS 插件平台，可访问项目、序列、时间线等；官方文档 developer.adobe.com/premiere-pro/uxp/
ExtendScript / CEP（旧方案）：仍可用，Adobe 正在向 UXP 迁移
没有「不装 PR、只调一个 URL 就帮你剪完导出」的大众开放 API

	剪映	Premiere
官方可编程接口	基本没有	有（插件 / 脚本）
前提	—	用户机器上要有 PR 与授权
典型用途	—	工作室工具、批量改工程

10 · 开源自动剪辑方案

结论：真正适合自动剪的不是桌面 GUI，而是引擎 / 无头库 / 自己包一层 API。

方案	适合度	说明
FFmpeg	⭐ 最高	不是 GUI，但是自动剪主力；自己写 HTTP / CLI / 队列
MLT（Shotcut / Kdenlive 引擎）	高	生成 `.mlt` XML → 调 `melt` 渲染；多轨、滤镜、转场，更像 NLE
libopenshot	中	C++ 库 + Python 等绑定，可在程序里建工程、加 clip、导出
MCP / AI 向编辑器（如 SynthCut）	中	本地 FFmpeg + 工具化接口，适合 Agent 驱动；较新，需评估许可与成熟度
Shotcut / Kdenlive / OpenShot 桌面版	不适用	没有官方稳定 HTTP 自动剪辑 API；只能脚本 / 改工程 / UI 自动化

10.1 与需求的对应

目标	更合适
批量裁切、拼接、加字幕、出 MP4	FFmpeg + 自建 API
多轨、滤镜、工程感	MLT + 自建 API
在 Python 里调库	libopenshot 或 FFmpeg 封装
给大模型 / Agent 调工具	MCP 类方案或自研 tool 层
把 Shotcut 当服务器 API	基本不行

10.2 自动剪辑务实架构

业务 API
   → 时间线 JSON（自定义）
   → 转成 FFmpeg 命令 或 MLT XML
   → 渲染出片

TIP

📌 自动剪辑不必先做完整 NLE UI。时间线 JSON 是唯一需要先定死的东西——它既能喂给渲染器，也能将来喂给桌面 UI。先把「数据模型 + 渲染」做对，界面是后面的事。

11 · MVP 排期与待决问题

11.1 阶段拆分（1 人全栈粗估）

阶段	内容	工期
P0	工程骨架、选文件、ffprobe 元数据、简单播放	3–5 天
P1	单轨时间线：加 clip、trim、split、删除、吸附	1–2 周
P2	按 EDL 导出 MP4 + 进度条	3–5 天
P3	工程存读、撤销重做	3–5 天
P4	双轨（V+A）、音量、淡入淡出	1 周
P5	三端打包 + FFmpeg 资源路径	3–7 天

可演示 MVP：约 4–6 周（不含复杂特效与多轨合成）。

11.2 风险与对策

风险	对策
预览不同步	MVP 接受段级预览；后期用 proxy + 统一时钟
FFmpeg 命令爆炸	先做「裁切 + 顺序 concat」，特效阶段再抽象 Graph
大文件卡 UI	Worker / 队列，缩略图异步
许可与专利	见 §7-§8，闭源走 LGPL + 系统编码器
包体过大	接受或改 Tauri；裁剪 FFmpeg 编译选项

11.3 待决问题

平台：只做 Windows，还是 Windows + macOS？
团队栈：更熟 Web / TypeScript，还是 C++ / Qt？
产品形态：工具型（剪完导出）还是偏创作 / AI？
商业模式：开源、闭源免费，还是闭源收费（决定 §8 强度）？

11.4 一页结论

问题	结论
要做什么	基础非线编（NLE），单轨或 V+A，非破坏
用什么做	Electron + React + TS + Zustand + 本地 FFmpeg
难在哪	时间线模型、预览、导出三者对齐；杂素材兼容
导出怎么办	LGPL FFmpeg 处理 + 系统编码器出 H.264 MP4
代价是什么	编码可控性、全格式、全特效、Linux 体验
能不能蹭现成软件的 API	剪映不行；PR 只能装了 PR 后写插件；自动剪用 FFmpeg / MLT
别一上来就做	实时多轨 GPU 合成、完整调色、强 AI 生成

附录 A · 参考来源

主题	来源
MLT 多媒体框架	`mltframework.org`
Shotcut 源码与依赖	`github.com/mltframework/shotcut`
OpenShot / libopenshot	`openshot.org/libopenshot/`
Premiere UXP API	`developer.adobe.com/premiere-pro/uxp/`
OpenTimelineIO 工程互通	`opentimeline.io`
MCP 驱动的开源编辑器示例	`github.com/Relo-video/SynthCut`
Kdenlive（MLT 系功能最全）	`kdenlive.org`
Olive（自研渲染 + OCIO）	`olivevideoeditor.org`
Pitivi / GES（GStreamer 编辑库）	`pitivi.org`
LosslessCut（Electron + FFmpeg 最小闭环）	`github.com/mifi/lossless-cut`

附录 B · 术语速查

术语	含义
NLE	Non-Linear Editing，非线性编辑
EDL	Edit Decision List，剪辑决策表（时间线的抽象描述）
非破坏编辑	只改「怎么用素材」，不改源文件
Proxy	代理文件，低码率替身用于流畅预览
stream copy	`-c copy`，不重编码直接复制码流
filter_complex	FFmpeg 复杂滤镜图语法
MF / VideoToolbox	Windows Media Foundation / macOS 系统编码框架
OTIO	OpenTimelineIO，跨软件时间线交换格式
VFR	可变帧率

本页目录

桌面视频剪辑软件调研#

怎么用这份笔记#

1 · 线编与非线编#

1.1 线编（Linear Editing）#

1.2 非线编（Non-Linear Editing，NLE）#

1.3 对比一览#

1.4 现在还有线编吗#

2 · 产品边界定义（MVP 范围）#

3 · 业界两条技术路线#

3.1 路线 A：专业开源 NLE（原生性能）#

3.2 路线 B：Web 桌面 + FFmpeg（现代独立/AI 向）#

3.3 开源 NLE 全景#

MLT 系（引擎共用）#

自研引擎系#

其他框架系#

工具型（不是 NLE，但很有名）#

最值得借鉴的三个#

许可提醒#

3.4 结论#

4 · 桌面壳选型#

5 · 推荐架构（MVP）#

5.1 四个关键设计点#

5.2 技术栈建议#

6 · 难点分布与风险#

6.1 真正难的核心三块#

6.2 工程上很烦的部分#

6.3 应该后放的#

6.4 难度曲线#

6.5 三个最大风险#

7 · FFmpeg 许可与专利#

7.1 两条独立的线#

7.2 GPL 传染的简化理解#

8 · 低风险商业方案与功能限制#

8.1 四条总原则#

8.2 推荐形态#

8.3 构建方向#

8.4 各平台导出通道#

8.5 安装包合规清单#

8.6 专利策略对比#

8.7 功能限制：这样做之后有什么代价#

几乎不受影响#

硬限制#

软限制（能做但会打折）#

与「满血 FFmpeg（GPL + x264）」的用户可感知差异#

应写进产品说明的诚实限制#

小结#

9 · 剪映 / Premiere 的 API 现状#

9.1 剪映 / CapCut：没有官方开放剪辑 API#

9.2 非官方「剪映小助手」是什么#

9.3 Premiere Pro：有官方扩展 API，但不是云 API#

10 · 开源自动剪辑方案#

10.1 与需求的对应#

10.2 自动剪辑务实架构#

11 · MVP 排期与待决问题#

11.1 阶段拆分（1 人全栈粗估）#

11.2 风险与对策#

11.3 待决问题#

11.4 一页结论#

附录 A · 参考来源#

附录 B · 术语速查#