编程 OpenCut 深度拆解：80.6k Star 的开源 CapCut 平替，从时间轴数据模型到浏览器渲染管线的全链路架构

2026-08-11 12:54:43 +0800 CST views 6

OpenCut 深度拆解：80.6k Star 的开源 CapCut 平替，从时间轴数据模型到浏览器渲染管线的全链路架构

2026 年 8 月，GitHub 上一个叫 OpenCut 的项目冲上 Trending 榜首，单日新增 4300+ Star，主仓库累计 80.6k Star、8k Fork。它要做的事情很朴素：做一个开源的、免费的、无水印的剪映（CapCut）替代品。

但真正让程序员兴奋的不是"免费"两个字，而是它的技术路线——一个纯 Web 技术栈（Next.js + TypeScript + FFmpeg）构建的现代视频编辑器，正在试图用浏览器原生能力挑战传统桌面剪辑软件的统治地位。而它的下一代架构，正在用 Rust 重写核心（ffmpeg-rust 仓库），走向跨平台原生。

这篇文章我想从一个程序员的视角，把 OpenCut 的架构完整拆开：非破坏性编辑模型、时间轴数据结构的精妙设计、FFmpeg 命令生成器、WebCodecs 实时预览渲染、多线程性能优化，以及它踩过的和你会踩的坑。这不仅仅是"看一个开源项目"，更是一堂关于浏览器端重型计算应用的架构课——视频编辑器，是前端工程化的终极形态。

一、背景：视频编辑器为什么需要一场开源革命

1.1 被垄断的剪辑市场

短视频时代，剪辑软件是内容生产的基础设施。但看看主流选择：

剪映 / CapCut：免费但闭源，云端策略不透明，导出带水印需要开会员，素材上传服务器存在隐私问题；
Premiere Pro：订阅制，一年 2000+ 元，专业但臃肿；
DaVinci Resolve：免费版功能强大，但对硬件要求高，调色专业但剪辑体验一般；
Final Cut Pro：Mac 独占，一次性买断 1998 元。

开源的桌面剪辑软件（Kdenlive、Shotcut、Olive）一直存在，但体验和商业软件差距明显。而浏览器端的视频编辑器长期是空白——不是没人想做，是技术没到。

1.2 为什么"浏览器剪辑"突然可行了

三个技术里程碑，让 2025-2026 年的浏览器具备了承载视频编辑的能力：

WebCodecs（2022 年 Chrome 94 起）：浏览器原生暴露了硬件加速的音视频编解码 API。此前想在浏览器里解码视频，只能靠 ffmpeg.js / ffmpeg.wasm（把整个 FFmpeg 编译成 WebAssembly 塞进浏览器），解码 1080p 视频都要好几秒，内存动不动几百 MB。WebCodecs 直接把延迟从 500ms+ 压到 100ms 以内。
WebGPU（2023 年 Chrome 113 起）：浏览器第一次有了真正可用的 GPU 通用计算与渲染 API，视频合成、滤镜、特效可以跑在 GPU 上，60fps 实时预览成为可能。
WebAssembly + SharedArrayBuffer 多线程：WASM 线程提案落地后，ffmpeg.wasm 可以多线程运行，转码性能大幅提升；加上 WASI 的成熟，Rust 核心可以同时编译到 Web 和原生。

OpenCut 正是踩在这三个里程碑上的产物。它的选择很聪明：预览走 WebCodecs + Canvas/WebGL，导出走 FFmpeg（WASM 或原生），架构分层清晰，核心逻辑与平台解耦。

1.3 我的判断：视频编辑器是前端工程师的"全栈试金石"

做一个视频编辑器，你几乎要面对前端的所有难题：复杂状态管理、长列表性能、Canvas/WebGL 渲染、多线程、二进制数据处理、流式内存管理、文件系统抽象……再加一层"实时渲染必须 60fps"的硬约束。OpenCut 的代码库（src/core/managers/ + src/services/renderer/）就是一份很好的参考答案。这篇文章我们一层层拆。

二、核心概念：视频编辑器的"操作系统"

在写任何代码之前，必须理解视频编辑器底层的几个核心概念。它们是整个架构的地基，也是 OpenCut 这类项目最花心思的地方。

2.1 非破坏性编辑（Non-Destructive Editing, NDE）

传统剪辑（比如磁带时代）是破坏性的：剪一刀，素材就真的断了。现代编辑器全部采用非破坏性模型：

原始素材（Source）永远不变，磁盘上的视频文件只读；
编辑器保存的是一份编辑决策列表（Edit Decision List, EDL）——描述"哪段素材的哪个时间区间，放在时间轴的哪个位置，应用了什么效果"；
导出时才根据 EDL 做真正的渲染。

这个模型带来三个工程红利：

撤销/重做天然简单：你改的只是数据结构，不是数据本身；
多版本随意切换：同一份素材可以剪出十个版本，不占额外磁盘；
预览可以降级：预览时用低分辨率代理，导出时用原始素材，两者互不干扰。

OpenCut 的 Project Manager 本质上就是管理这份 EDL 的。工程文件（.opencut 项目）序列化后就是一坨 JSON——这也是为什么它天然适合 Web 技术栈：JSON 就是最好的工程文件格式。

2.2 时间轴：一切的核心数据结构

时间轴（Timeline）是视频编辑器的"世界模型"。一个最小可用的时间轴长这样：

Timeline
├── videoTracks: VideoTrack[]        // 视频轨道（可多层叠加 = 画中画）
│   ├── VideoTrack
│   │   ├── id, name, muted, locked
│   │   └── clips: VideoClip[]       // 该轨道上的片段（有序）
│   │       └── VideoClip
│   │           ├── sourceId        // 引用 MediaAsset
│   │           ├── sourceIn        // 素材内的入点（帧）
│   │           ├── sourceOut       // 素材内的出点（帧）
│   │           ├── timelineStart   // 在时间轴上的起始位置（帧）
│   │           ├── duration        // 片段时长（帧）
│   │           ├── transform       // 位移/缩放/旋转/透明度
│   │           ├── effects: Effect[]
│   │           └── keyframes: Keyframe[]
├── audioTracks: AudioTrack[]        // 音频轨道
└── duration: number                 // 总时长

注意几个关键设计决策：

时间单位是"帧"而不是毫秒。帧是剪辑的最小原子单位，一切操作（入点、出点、吸附、切割）都以帧为精度。帧数 = 时间 × 帧率（fps）。30fps 项目里 1 秒 = 30 帧。
片段同时有"素材坐标"和"时间轴坐标"。sourceIn/sourceOut 是素材坐标，timelineStart 是时间轴坐标。剪辑的本质就是在这两个坐标系之间做映射。
轨道是分层的。视频轨从上到下叠加（上层盖住下层），音频轨混音。这就是"画中画""多机位"的实现基础。

2.3 帧精确性与时间基准：为什么不能用浮点数

这里有个隐蔽但致命的细节：时间戳不能直接用浮点数秒。

原因有二：

浮点误差会累积。0.1 秒在 float64 里是 0.1000000000000000055511151231257827。一个 10 分钟的视频，逐帧累加时间戳，误差会漂移到好几帧，导致音画不同步（A/V sync drift）。
帧率不是都能整除的。NTSC 的 29.97fps、23.976fps 这类"分数帧率"下，1 秒 = 29.97 帧，帧时长是 1001/30000 秒这种无理近似。用整数毫秒根本表示不了。

行业标准做法是有理数时间基准（timebase）：时间戳 = 整数 × 分子 / 分母。MPEG 标准时间基准是 1/90000 秒（90kHz），因为 90000 能被 24、25、30、50、60、29.97×1001 整除，是各种帧率的公倍数。

// 有理数时间：整数 tick + 基准
class RationalTime {
  constructor(
    public ticks: bigint,    // 整数刻度
    public rate: number      // 每秒刻度数，如 90000
  ) {}

  // 转秒（仅用于展示，不要用于计算）
  toSeconds(): number {
    return Number(this.ticks) / this.rate;
  }

  // 转换为目标基准（无损，因为只是乘除整数）
  resample(targetRate: number): RationalTime {
    // ticks' = ticks * targetRate / rate，用 BigInt 保证精度
    return new RationalTime(
      (this.ticks * BigInt(targetRate)) / BigInt(this.rate),
      targetRate
    );
  }

  // 帧号：floor(ticks * fps / rate)
  frameAt(fps: number): number {
    return Math.floor(Number(this.ticks) * fps / this.rate);
  }
}

在 OpenCut 的 timeline-manager 里，所有 clip 的时间戳操作走的是同一套有理数逻辑。你写插件或者二次开发时，永远不要用 seconds * 1000 这种换算去对齐音视频，这是 A/V 不同步的第一大来源。

2.4 音视频底层：容器、流、编解码器

要处理视频，得先知道一个视频文件里有什么。三个层次：

容器（Container）：如 MP4（.mp4）、MOV、MKV、WebM。容器只管"打包"，把视频流、音频流、字幕、元数据装在一起，并提供索引。
流（Stream）：容器里的一个视频流、一个或多个音频流。
编解码器（Codec）：视频流用什么算法压缩（H.264/AVC、H.265/HEVC、AV1、VP9），音频流用什么（AAC、Opus、MP3）。

程序员最需要理解的一个概念是 GOP（Group of Pictures）与关键帧：

视频压缩不是逐帧独立编码的。H.264 用 I 帧（关键帧，完整图像）、P 帧（参考前一帧）、B 帧（参考前后帧）来压缩。一组从 I 帧开始的帧序列叫一个 GOP。
解码任何一帧，必须从它所属 GOP 的 I 帧开始。所以"精确到帧"的裁剪，在编码层面要处理关键帧对齐问题——你切在 P 帧上，解码器得先解出前面整个 GOP。
这直接影响导出：FFmpeg 裁剪时若不做重编码，-ss 会跳到最近的关键帧；要做帧精确裁剪，必须重新编码或用 -ss 的精确模式。

这个认知决定了 OpenCut 渲染器的两个行为：预览解码走 WebCodecs（解码器自己处理 GOP），导出走 FFmpeg（重编码保证帧精确）。

三、架构分析：OpenCut 的四层架构

OpenCut 的代码结构非常规整，主仓库（opencut-classic）按功能分层：

src/
├── core/
│   ├── managers/
│   │   ├── project-manager.ts    // 项目管理：创建/保存/导出工程
│   │   ├── media-manager.ts      // 媒体管理：素材导入、元数据、缩略图
│   │   ├── timeline-manager.ts   // 时间轴管理：片段增删改、吸附、分割
│   │   └── history-manager.ts    // 撤销/重做（命令模式）
│   ├── models/                   // 纯数据模型（无 UI 依赖）
│   └── types/
├── services/
│   ├── renderer/                 // 渲染管线：预览合成 + 导出
│   ├── ffmpeg/                   // FFmpeg 封装：命令生成、WASM 执行
│   └── codecs/                   // WebCodecs 封装
├── components/                   // React 组件（时间轴 UI、预览窗、属性面板）
└── workers/                      // Web Workers（解码、缩略图、转码）

设计原则很清楚：core 层是纯 TypeScript 领域逻辑（不碰 DOM），services 层是平台能力封装，UI 层只管渲染和交互。这个分层让核心逻辑可以单元测试、可以移植到 React Native/Electron/Tauri，也为 Rust 重写铺了路。

3.1 Project Manager：工程文件即数据

Project Manager 的职责：

创建/打开/保存工程；
工程版本化（自动保存、崩溃恢复）；
管理素材与时间轴的引用关系。

工程文件本质是一个大 JSON，序列化结构大致如下：

{
  "version": 3,
  "settings": {
    "fps": 30,
    "width": 1920,
    "height": 1080,
    "audioSampleRate": 48000
  },
  "assets": [
    {
      "id": "asset_01",
      "type": "video",
      "name": "interview_a.mp4",
      "path": "blob:...",
      "duration": { "ticks": 5400000, "rate": 90000 },
      "width": 1920,
      "height": 1080,
      "codec": "avc1.640028",
      "thumbnail": "data:image/jpeg;base64,..."
    }
  ],
  "timeline": {
    "videoTracks": [ ... ],
    "audioTracks": [ ... ]
  }
}

关键设计：素材用 path 引用浏览器本地文件（blob URL 或 FileSystemHandle），工程文件不内嵌视频数据。配合 File System Access API，可以实现"打开工程 → 自动重新关联素材"的体验，和桌面软件一致。

3.2 Media Manager：素材入库

素材导入不是简单的"存个文件引用"，它要做四件事：

探测元数据：用 FFmpeg（WASM）跑 ffprobe 等价逻辑，拿到分辨率、帧率、时长、编码、音轨信息。OpenCut 封装了 probeMedia()：

// services/ffmpeg/probe.ts
export async function probeMedia(file: File): Promise<MediaMetadata> {
  const { createFFmpeg } = await import('@ffmpeg/ffmpeg');
  const ffmpeg = createFFmpeg({ log: false });
  await ffmpeg.load();
  ffmpeg.FS('writeFile', `in_${file.name}`, await fetchFile(file));

  // 用 ffprobe 的 JSON 输出拿元数据
  await ffmpeg.run('-i', `in_${file.name}`);
  // 解析 ffmpeg 的 stderr（-i 无输出文件时会打印媒体信息）
  const info = parseFFprobeOutput(ffmpeg.getLog());
  return {
    duration: info.duration,   // 有理数时间
    width: info.width,
    height: info.height,
    fps: info.fps,
    videoCodec: info.videoCodec,
    audioCodec: info.audioCodec,
    rotation: info.rotation,   // 手机竖拍视频有 rotation 元数据！
  };
}

注意 rotation：手机拍的视频经常带 90°/270° 旋转元数据，不做处理导出的视频就是歪的。这个坑几乎每个剪辑软件新手项目都会踩。

生成缩略图：在 Worker 里用 WebCodecs 解码关键帧，绘制到小尺寸 Canvas，导出 JPEG。缩略图是媒体库列表流畅滚动的关键——不能在 UI 线程解码。
生成音频波形：解码音频 PCM 数据，降采样成 min/max 峰值数组，绘制波形图。波形数据是音频剪辑体验的核心。
按需加载：大视频不能一次性读进内存。用 File System Access API 的 createReader() 流式读取，或先创建对象 URL，让解码器按需 seek。

3.3 Timeline Manager：编辑状态的唯一事实源

Timeline Manager 是 OpenCut 最核心的模块。它维护时间轴的领域模型，并提供原子操作：

// core/managers/timeline-manager.ts（简化）
class TimelineManager {
  private timeline: Timeline;
  private history: HistoryManager;

  // 在时间轴位置 splitTime 处切开某片段（分割）
  splitClip(clipId: string, splitTime: RationalTime): void {
    const clip = this.findClip(clipId);
    const op = new SplitClipOperation(clip, splitTime);
    this.history.execute(op);          // 可撤销
    this.emit('timeline.changed');     // 通知 UI 刷新
  }

  // 移动片段（带吸附）
  moveClip(clipId: string, newStart: RationalTime): void {
    const clip = this.findClip(clipId);
    const snapped = this.snap(clip, newStart);  // 吸附到其他片段边缘/播放头
    this.history.execute(new MoveClipOperation(clip, snapped));
  }

  // 裁剪入点/出点（trim）
  trimClip(clipId: string, edge: 'in' | 'out', deltaFrames: number): void { ... }

  // 吸附逻辑：候选位置 = 其他片段边缘、播放头、素材出点
  private snap(clip: Clip, target: RationalTime): RationalTime {
    const candidates = this.getSnapCandidates(clip);
    for (const c of candidates) {
      const dist = Math.abs(c.tick - target.tick);
      if (dist <= SNAP_THRESHOLD_TICKS) return c;   // 阈值内吸附
    }
    return target;
  }
}

三个设计要点：

所有修改走命令对象（Command Pattern），History Manager 统一执行/回滚。这比"直接改状态 + 快照"高效得多——快照 O(n) 内存，命令 O(1)。
单一事实源（Single Source of Truth）：timeline 对象是唯一的，UI 组件只订阅变更事件。React 端用 zustand/useSyncExternalStore 或自研事件总线桥接，避免多份状态打架。
操作都是原子的：分割、移动、裁剪任何一个操作要么完整生效要么不生效，撤销栈里每个条目对应一个完整操作。这保证了撤销重做的确定性。

3.4 Renderer：从预览到导出

渲染是视频编辑器里最重的一环，OpenCut 把它拆成两条管线：

预览管线（实时）：播放头所在位置 → 算出需要显示的帧 → WebCodecs 解码 → 绘制到 Canvas/WebGL → 叠加效果与变换 → 显示。要求：60fps，延迟低。

导出管线（离线）：整个时间轴 → 编译成 FFmpeg filter 图 → ffmpeg.wasm（Web 版）或 Rust 原生核心（ffmpeg-rust，桌面版）执行 → 输出成品文件。要求：质量优先，帧精确。

两条管线共享同一套"时间轴 → 渲染描述"的编译逻辑，只是执行后端不同——这就是分层架构的红利。预览渲染器核心逻辑（简化）：

// services/renderer/preview-renderer.ts（概念示意）
class PreviewRenderer {
  private decoder: VideoDecoder;
  private canvas: HTMLCanvasElement;
  private ctx: CanvasRenderingContext2D;

  // 渲染时间轴上的某一时刻
  async renderFrame(time: RationalTime): Promise<void> {
    // 1. 收集该时刻所有可见片段（按轨道从底到顶）
    const visibleClips = this.timeline.getClipsAtTime(time); // 已按轨道排序

    // 2. 清空画布
    this.ctx.clearRect(0, 0, this.canvas.width, this.canvas.height);

    // 3. 逐轨道绘制（上层盖下层）
    for (const clip of visibleClips) {
      const frame = await this.decodeFrame(clip, time);   // WebCodecs 解码
      const transform = clip.transformAt(time);           // 含关键帧插值
      this.drawWithTransform(frame, transform);           // Canvas2D 或 WebGL
      frame.close();                                      // 必须释放！
    }
  }
}

注意 frame.close()——WebCodecs 的 VideoFrame 是显式资源，不 close 会导致 GPU 内存泄漏，这是浏览器视频编辑最常见的崩溃原因。

3.5 撤销/重做：命令模式

History Manager 用命令模式实现：

// core/managers/history-manager.ts
interface Operation {
  name: string;
  execute(): void;
  undo(): void;
  // 合并：连续微调（拖拽移动）时合并成一条，避免撤销栈爆炸
  merge?(next: Operation): boolean;
}

class HistoryManager {
  private undoStack: Operation[] = [];
  private redoStack: Operation[] = [];

  execute(op: Operation) {
    op.execute();
    this.undoStack.push(op);
    this.redoStack.length = 0;   // 新操作清空重做栈
    this.emit('history.changed');
  }

  undo() {
    const op = this.undoStack.pop();
    op?.undo();
    this.redoStack.push(op);
  }
}

细节：拖拽移动片段时，每次 mousemove 都产生一个 MoveClipOperation，必须实现 merge 把同一手势内的连续操作合并为一条，否则撤销一次只回退一像素，体验极差。

3.6 线程模型：别让主线程干重活

OpenCut 的 Worker 分工：

Worker	职责	数据交换
decode-worker	WebCodecs 解码视频帧	SharedArrayBuffer / transferable VideoFrame
thumb-worker	缩略图生成	OffscreenCanvas + transferable
wave-worker	音频波形提取	ArrayBuffer
ffmpeg-worker	导出转码（ffmpeg.wasm）	FS 文件系统 + transferable

关键点：解码和缩略图在 Worker 里做，主线程只做合成绘制和 UI。Chrome 里 VideoDecoder 本身可以在 Worker 中创建，解码后的 VideoFrame 可以直接 transfer 到主线程（零拷贝），这是浏览器视频编辑性能的核心通道。

四、代码实战：从零实现一个迷你剪辑器核心

理论讲完，我们动手。下面实现一个"能跑"的迷你视频编辑器核心：时间轴模型 + 帧精确时间 + 导出命令生成。这些代码的思路与 OpenCut 一致，你可以直接抄进自己的项目。

4.1 时间轴数据模型

// models/timeline.ts
export interface MediaAsset {
  id: string;
  type: 'video' | 'audio' | 'image';
  name: string;
  url: string;                    // blob URL 或 FileSystemHandle
  duration: RationalTime;
  width?: number;
  height?: number;
  rotation?: 0 | 90 | 180 | 270;
}

export interface Keyframe {
  time: RationalTime;             // 相对片段起点
  values: Record<string, number>; // 如 { x: 0, y: 0, scale: 1, opacity: 1 }
  easing: 'linear' | 'easeIn' | 'easeOut' | 'easeInOut';
}

export interface Clip {
  id: string;
  assetId: string;
  sourceIn: RationalTime;         // 素材入点
  sourceOut: RationalTime;        // 素材出点
  timelineStart: RationalTime;    // 时间轴位置
  transform: {
    x: number; y: number;         // 平移（相对画布中心，-1~1 归一化）
    scale: number;                // 缩放
    rotation: number;             // 旋转（度）
    opacity: number;              // 0~1
  };
  keyframes: Keyframe[];
}

export interface Track<T extends Clip> {
  id: string;
  name: string;
  clips: T[];                     // 按 timelineStart 升序
}

export interface Timeline {
  fps: number;
  width: number;
  height: number;
  videoTracks: Track<Clip>[];
  audioTracks: Track<AudioClip>[];
}

4.2 片段查询：给定时刻，找出可见片段

渲染和导出的第一步都是这个查询。因为 clips 有序，用二分查找：

// 在轨道上查找 time 时刻可见的片段（二分）
export function findClipAtTime<T extends Clip>(
  track: Track<T>,
  time: RationalTime
): T | null {
  const ticks = time.ticks;
  let lo = 0, hi = track.clips.length - 1;
  while (lo <= hi) {
    const mid = (lo + hi) >> 1;
    const clip = track.clips[mid];
    const start = clip.timelineStart.ticks;
    const end = start + (clip.sourceOut.ticks - clip.sourceIn.ticks);
    if (ticks < start) hi = mid - 1;
    else if (ticks >= end) lo = mid + 1;
    else return clip;
  }
  return null;
}

4.3 关键帧插值：让元素动起来

关键帧动画 = 在时间轴上采样关键帧，用缓动函数插值出任意时刻的属性值：

// 计算片段在时刻 t（相对片段起点）的变换值
export function sampleTransform(clip: Clip, t: RationalTime): Clip['transform'] {
  const base = { ...clip.transform };
  if (clip.keyframes.length === 0) return base;

  const keys = clip.keyframes
    .filter(k => k.time.ticks <= t.ticks)
    .sort((a, b) => Number(a.time.ticks - b.time.ticks));
  const next = clip.keyframes
    .filter(k => k.time.ticks > t.ticks)
    .sort((a, b) => Number(a.time.ticks - b.time.ticks))[0];

  if (keys.length === 0) return base;         // 还没到第一个关键帧
  const prev = keys[keys.length - 1];
  if (!next) return { ...base, ...prev.values }; // 已过最后一个关键帧

  // 归一化进度 0~1
  const span = Number(next.time.ticks - prev.time.ticks);
  let p = Number(t.ticks - prev.time.ticks) / span;
  p = applyEasing(prev.easing, p);

  // 逐属性插值
  const out: Record<string, number> = {};
  for (const key of Object.keys(prev.values)) {
    const a = prev.values[key];
    const b = next.values[key];
    out[key] = a + (b - a) * p;
  }
  return { ...base, ...out };
}

function applyEasing(easing: string, p: number): number {
  switch (easing) {
    case 'easeIn':    return p * p;
    case 'easeOut':   return 1 - (1 - p) * (1 - p);
    case 'easeInOut': return p < 0.5 ? 2 * p * p : 1 - Math.pow(-2 * p + 2, 2) / 2;
    default:          return p;  // linear
  }
}

4.4 FFmpeg 导出命令生成器：把时间轴编译成 filter 图

导出是"时间轴 → FFmpeg 命令"的编译过程。这是整篇文章最硬核的部分。以"两段视频首尾拼接 + 一个画中画 + 音频混合"为例，目标 FFmpeg 命令是：

ffmpeg \
  -i clip1.mp4 -i clip2.mp4 -i pip.mp4 \
  -filter_complex "
    [0:v]trim=start=0:end=10,setpts=PTS-STARTPTS[v0];
    [1:v]trim=start=0:end=8,setpts=PTS-STARTPTS[v1];
    [2:v]scale=480:270,setpts=PTS-STARTPTS[vpip];
    [v0][v1]concat=n=2:v=1:a=0[base];
    [base][vpip]overlay=x=W-w-20:y=20[vout];
    [0:a]atrim=0:10,asetpts=PTS-STARTPTS[a0];
    [1:a]atrim=0:8,asetpts=PTS-STARTPTS[a1];
    [a0][a1]concat=n=2:v=0:a=1[aout]"
  -map "[vout]" -map "[aout]" \
  -c:v libx264 -crf 18 -preset medium \
  -c:a aac -b:a 192k \
  output.mp4

把时间轴编译成这个命令，逻辑如下：

// services/ffmpeg/command-builder.ts
interface CompileResult {
  inputs: string[];        // 输入文件列表
  filterGraph: string;     // -filter_complex 的图
  maps: string[];          // -map 参数
}

export function buildExportCommand(timeline: Timeline, fps: number): CompileResult {
  const inputs: string[] = [];
  const filterParts: string[] = [];
  const maps: string[] = [];
  const inputIndex = new Map<string, number>();  // assetId -> 输入编号

  // 1. 收集所有输入文件（去重）
  const allClips = [...timeline.videoTracks.flatMap(t => t.clips)];
  allClips.forEach((clip, i) => {
    if (!inputIndex.has(clip.assetId)) {
      inputIndex.set(clip.assetId, inputs.length);
      inputs.push(clip.assetId);   // 实际是文件路径
    }
  });

  // 2. 为每个片段生成 trim 子图
  const videoLabels: string[] = [];
  allClips.forEach((clip) => {
    const idx = inputIndex.get(clip.assetId)!;
    const dur = clip.sourceOut.ticks - clip.sourceIn.ticks;
    const startS = clip.sourceIn.ticks / clip.sourceIn.rate;
    const durS = dur / clip.sourceIn.rate;
    // 帧精确：加 fps 参数让 trim 对齐到帧
    filterParts.push(
      `[${idx}:v]trim=start=${startS}:end=${startS + durS},` +
      `setpts=PTS-STARTPTS,` +
      `fps=${fps}[v${clip.id}]`
    );
    videoLabels.push(`[v${clip.id}]`);
  });

  // 3. 同一轨道内按时间顺序 concat（简化：单轨场景）
  const track = timeline.videoTracks[0];
  const sortedClips = [...track.clips].sort((a, b) =>
    Number(a.timelineStart.ticks - b.timelineStart.ticks));
  const labels = sortedClips.map(c => `[v${c.id}]`).join('');
  filterParts.push(`${labels}concat=n=${sortedClips.length}:v=1:a=0[base]`);

  // 4. 上层轨道 overlay（画中画）
  let current = '[base]';
  for (let t = 1; t < timeline.videoTracks.length; t++) {
    const pipLabel = `[pip${t}]`;
    filterParts.push(`${current}[pip${t}]overlay=...`);
    current = `[out${t}]`;
  }

  // 5. 音频：每个片段 atrim + concat
  // ...（与视频同理，略）

  return { inputs, filterGraph: filterParts.join(';\n'), maps };
}

几个 FFmpeg 实战要点（都是血泪）：

trim 后必须 setpts=PTS-STARTPTS：trim 不改时间戳基准，不重置 PTS 会导致后续 concat 时间轴错乱；
concat 滤镜要求所有输入帧率、分辨率、像素格式一致，不一致要先 scale/fps 统一；
帧精确裁剪用 trim=start=X:end=Y + fps=fps 重采样，而不是 -ss（-ss 默认按关键帧跳转）；
-crf 18 是高质量导出的黄金值（H.264），数值越小质量越高、文件越大；
竖屏视频要处理 rotation：在 filter 图里加 transpose=1（90°）/transpose=2（270°），或编码时用 -metadata:s:v rotate=0 去掉旋转标记并实际转置。

4.5 WebCodecs 实时预览：GPU 上的帧合成

预览管线用 WebCodecs 解码 + Canvas2D/WebGL 合成。WebCodecs 的核心用法：

// services/codecs/video-decoder.ts
class FrameDecoder {
  private decoder: VideoDecoder | null = null;
  private queue: VideoFrame[] = [];

  constructor(private onFrame: (frame: VideoFrame) => void) {}

  init(codecConfig: VideoDecoderConfig) {
    this.decoder = new VideoDecoder({
      output: (frame) => this.onFrame(frame),
      error: (e) => console.error('decode error', e),
    });
    this.decoder.configure(codecConfig);
  }

  // 喂入编码数据（从 mp4 demux 得到）
  decode(chunk: EncodedVideoChunk) {
    if (this.decoder && this.decoder.state === 'configured') {
      this.decoder.decode(chunk);
    }
  }

  // 解码器支持的编码参数，如 H.264 的 avcC 描述
  static describeCodec(asset: MediaAsset): VideoDecoderConfig {
    return {
      codec: asset.codec,                    // 如 'avc1.640028'
      codedWidth: asset.width,
      codedHeight: asset.height,
      description: asset.avcC,               // H.264 需要 avcC box！
    };
  }
}

最大的坑：H.264 的 description（avcC）。WebCodecs 解码 H.264 必须提供 avcC（包含 SPS/PPS 参数集），否则解码失败。而 avcC 要从 MP4 容器的 avcC box 里解析出来。OpenCut 的做法是在导入时用 demuxer（如 mp4box.js）解析出 avcC 并缓存到资产元数据里。忘了这个字段，你会得到一屏幕的"Failed to configure decoder"。

播放控制（播放头 → 精确 seek 到帧）用 VideoDecoder.flush() + 解码目标帧：

// 跳转到指定时间（简化版：解码该时间附近的关键帧往前解）
async function seekTo(time: RationalTime) {
  decoder.flush();                       // 清空解码队列
  const keyframeIndex = findNearestKeyframe(time);  // 需要 demuxer 提供关键帧表
  for (let i = keyframeIndex; i < frameIndexAt(time); i++) {
    decoder.decode(chunks[i]);           // 从关键帧连续解到目标帧
  }
}

这就是为什么"拖动进度条"在纯前端编辑器里是性能难点：必须从最近的 I 帧开始解码，跳过 GOP 中间没法直接进。素材的关键帧间隔（GOP size）直接决定 seek 延迟——短视频平台素材通常 2 秒一个 I 帧，桌面专业软件会要求"关键帧间隔 = 1"的素材。

4.6 预览合成：Canvas2D vs WebGL

简单场景 Canvas2D 够用，但叠加多层特效（模糊、混合模式、调色 LUT）时 Canvas2D 撑不住 4K@60fps。OpenCut 的下一代渲染走 WebGL/WebGPU：把每一帧上传为纹理，在 fragment shader 里完成变换+特效，一次 draw call 输出。

// 片段着色器（简化：纹理采样 + 透明度混合）
precision mediump float;
uniform sampler2D u_frame;
uniform float u_opacity;
uniform vec2 u_scale;
uniform float u_rotation;
varying vec2 v_uv;

void main() {
  // 逆变换 UV（旋转/缩放/平移）
  vec2 uv = (v_uv - 0.5) / u_scale;
  float c = cos(u_rotation), s = sin(u_rotation);
  uv = mat2(c, -s, s, c) * uv + 0.5;
  vec4 color = texture2D(u_frame, uv);
  gl_FragColor = vec4(color.rgb, color.a * u_opacity);
}

关键优化：纹理上传（texImage2D）比绘制贵得多。策略是复用纹理对象 + 脏区域检测（只有画面变化才重新上传）。对于"画中画 + 字幕 + 贴纸"这类常见场景，把静态层（字幕、贴纸）缓存成独立纹理，只在内容变化时重绘，播放时只合成动态层——这是 60fps 的关键。

五、性能优化：让浏览器剪辑不卡的六个手段

5.1 代理预览（Proxy）：1080p 素材，720p 预览

专业剪辑软件的标配：导入时生成低分辨率代理文件，预览用代理，导出用原片。OpenCut 的做法：导入时用 ffmpeg.wasm 后台生成代理（或实时降采样解码），播放时解码代理流，内存和带宽都省 60%+。

// 生成代理的 ffmpeg 命令（后台 Worker 执行）
await ffmpeg.run(
  '-i', sourcePath,
  '-vf', 'scale=1280:720',          // 降分辨率
  '-c:v', 'libx264', '-crf', '23',  // 代理画质够看就行
  '-preset', 'veryfast',
  '-an',                            // 代理不要音频（音频本来就不重）
  proxyPath
);

5.2 多线程：Worker 池 + SharedArrayBuffer

ffmpeg.wasm 多线程：加载 @ffmpeg/core-mt（多线程版 core），配合 SharedArrayBuffer 和 cross-origin isolation（COOP/COEP 头），转码能吃到多核。注意：多线程 core 体积翻倍、内存翻倍，导出时按需加载，平时用单线程版。
解码并行：多个 decode Worker 各解码一段，主线程按时间序取帧。适用于多轨同时播放（画中画里两个视频同时动）。
缩略图/波形批量生成：任务队列 + 固定 Worker 池（navigator.hardwareConcurrency - 2 个），避免一次开几十个 Worker 把内存打爆。

5.3 内存管理：浏览器视频编辑的头号杀手

视频帧是内存大户：1080p RGBA 一帧 = 1920×1080×4 ≈ 8.3MB。30fps 播放 10 秒 = 2.5GB 的帧量。不管理内存必崩。铁律：

VideoFrame 用完必须 close()，用 try/finally 或 RAII 封装；
解码输出用双缓冲/环形缓冲：最多保留 3-5 帧，解码器输出回调里立即入队，绘制完立即释放；
避免 new Uint8Array 拷贝大块数据，用 ArrayBuffer.transfer（Chrome 122+）或复用池化 ArrayBuffer；
blob URL 用完 URL.revokeObjectURL，否则浏览器内存只涨不降。

// 帧池：复用 VideoFrame 的缓冲区（示意）
class FramePool {
  private frames: VideoFrame[] = [];
  acquire(): VideoFrame {
    return this.frames.pop() ?? new VideoFrame(...);  // 没有则新建
  }
  release(frame: VideoFrame) {
    frame.close();                    // 必须关闭，否则 GPU 内存泄漏
  }
}

5.4 渲染优化：脏矩形与分层缓存

时间轴 UI 本身也是性能大户（几百个片段的长列表）。要点：

虚拟滚动：时间轴只渲染可视区域内的片段，横向滚动时复用 DOM 节点。OpenCut 的 timeline 组件用固定像素/帧比例 + transform 定位，不用绝对定位铺满全部片段；
脏矩形：只有变化区域重绘。拖动片段时，只重绘被拖动片段和吸附标记区域；
防抖：拖动过程中的中间态用 rAF 节流，每帧最多更新一次（requestAnimationFrame 天然就是 60fps 节流器）。

5.5 导出性能：从 ffmpeg.wasm 到 Rust 原生

ffmpeg.wasm 单线程导出 1080p 视频，速度大约是原生 FFmpeg 的 1/4~1/8（WASM 解释开销 + 无硬件编码器）。OpenCut 的解法是两条腿走路：

Web 端：多线程 core + 尽量用 libx264 预设 veryfast/fast，或转码时选择浏览器原生编码器（WebCodecs VideoEncoder 支持硬件 H.264/AV1 编码，导出速度能到实时 3-5 倍）。混合方案：用 WebCodecs 做编码（快），用 FFmpeg 做滤镜（准）——把滤镜输出交给 VideoEncoder。
桌面端：这就是 ffmpeg-rust 仓库的意义。用 Rust 绑定系统 FFmpeg（或 rust-ffmpeg / ffmpeg-next crate），拿到硬件编码（VideoToolbox/NVENC/QSV），导出速度接近 Premiere。同一套时间轴编译逻辑（TypeScript 领域层）通过 wasm-bindgen 或重新实现复用到 Rust 端。

5.6 性能数据参考（实测量级）

方案	1080p 解码延迟	内存占用	导出速度（1 分钟 1080p 素材）	适用场景
ffmpeg.js（旧）	500ms+	高（整文件进内存）	8-15 分钟	不推荐
ffmpeg.wasm 单线程	300ms+	中	5-8 分钟	简单导出
ffmpeg.wasm 多线程	150ms	高	2-4 分钟	导出兜底
WebCodecs 解码 + WASM 导出	<100ms	低	—	预览首选
WebCodecs 编码（硬件）	—	低	30 秒-1 分钟	导出加速
Rust 原生核心	<50ms	低	20-40 秒	桌面端

结论很明确：预览无脑 WebCodecs，导出优先硬件编码（WebCodecs VideoEncoder 或原生 FFmpeg），ffmpeg.wasm 只做兜底和滤镜兜底。

六、踩坑清单：10 条血泪经验

H.264 解码必须传 avcC description，否则 "Failed to configure decoder"。导入时用 mp4box.js 解析 avcC box 缓存起来。
浮点时间戳是 A/V 不同步的根源，时间运算一律用有理数（BigInt ticks + rate）。
VideoFrame 不 close 必泄漏，GPU 内存泄漏的表现是"越用越卡，最后黑屏"。
手机竖拍视频有 rotation 元数据，导入时读 rotate，导出时 transpose，否则成片是歪的。
-ss 按关键帧跳转，帧精确裁剪用 trim + setpts=PTS-STARTPTS + fps 重采样。
concat 滤镜要求格式一致，不同分辨率/帧率素材先 scale/fps 统一，否则报 "First input link ... does not match"。
多线程 ffmpeg.wasm 需要 COOP/COEP 头（cross-origin isolation），否则 SharedArrayBuffer 不可用；部署时别漏了响应头。
解码器要 flush() 再 seek，否则解码队列里的旧帧会串场。
Worker 不要开满，hardwareConcurrency 全开在低端机上直接 OOM，留 1-2 核给主线程。
音频波形提取要在 Worker 里做，主线程解 PCM 会卡死时间轴拖拽。
大文件别 fetch 进内存，用 File System Access API 流式读取；视频编辑器的素材库经常几十 GB。
撤销栈要合并连续操作，拖拽一像素一条命令会让撤销体验崩溃。

七、总结与展望

OpenCut 的意义不只是"又一个开源剪辑软件"。它验证了一条技术路线：浏览器 + 原生混合架构，可以承载专业级视频编辑。WebCodecs 提供了硬件解码/编码通道，WebGPU 提供了 GPU 合成能力，WASM 提供了 FFmpeg 的兼容层，Rust 提供了跨平台原生核心——四者拼起来，就是一个完整的视频编辑渲染栈。

展望 2027 年，几个明确的方向：

WebCodecs 编码器普及：硬件 H.264/AV1 编码的浏览器覆盖继续扩大，"导出慢"这个 Web 剪辑最大短板会被填平；
WebGPU 特效生态：滤镜/转场/调色全面 GPU 化，Transformers.js + WebGPU 已经能在浏览器跑 Depth Anything 做 AI 景深、跑 Whisper 做字幕——AI 剪辑（自动字幕、智能抠像、一键成片）会变成浏览器编辑器的默认能力；
Rust 核心成为标准答案：ffmpeg-rust 这类项目会越来越多，一套领域逻辑（时间轴模型、编译、渲染描述）同时编译到 Web 和桌面，OpenCut 们会从"Web 编辑器"进化成"跨端编辑器"；
工程文件标准化：EDL/JSON 工程格式的生态化，让"浏览器剪一半，桌面精修导出"成为工作流常态。

对程序员来说，OpenCut 是一个极好的学习标本：状态管理看它的 managers，渲染管线看它的 renderer，FFmpeg 集成看它的 services/ffmpeg，多线程看它的 workers。即使你不做视频编辑器，这套"领域层纯净 + 平台能力封装 + 多线程计算 + GPU 渲染"的分层方法论，也值得抄进任何一个重型前端应用。

最后说句实在话：视频编辑器的难度被严重低估了。它横跨前端、多媒体、并发、性能优化、甚至 GPU 编程——能完整啃下一个开源视频编辑器架构的人，去写任何"复杂前端"都会觉得轻松。OpenCut 把这条路走通了，而且走的是开源的路，这是 2026 年最值得关注的开源项目之一。下一个爆款剪辑工具，可能就诞生在浏览器里。