视频编辑器的编解码与加载机制

视频编辑器的编解码与加载机制

一、”视频文件”概念

很多人直觉觉得”加载视频”= 把文件读进内存就完事了。不对。 一个 .mp4 文件里装的不是像素，而是一个叫 Container（容器） 的东西，里面打包了好几层：

MP4 / MOV / MKV  ← 容器（午餐盒）
 ├── 视频流（H.264 / H.265 / AV1 压缩数据）
 ├── 音频流（AAC / MP3 / PCM）
 ├── 字幕流（可选）
 └── 元数据（时间码、宽高、帧率…）

所以播放/编辑一条管线必须是 拆包 → 解压 → 显示，一步步来。

二、核心管线：Demux → Decode → Frame → Render

Step 1 — Demux（解封装/分流）

把容器”拆开”，抽出独立的压缩数据流

Demuxer 读文件头 → 找到有几条流（视频/音频各一条）→ 按时间戳顺序逐个吐出 Packet（压缩数据包）

• • 一个 AVPacket ≈ 一帧（或一片）压缩数据，带 DTS（解码顺序时间戳）和 PTS（显示顺序时间戳）
• • 这步很便宜，只是解析文件结构，不做像素运算

Step 2 — Decode（解码/解压缩）

把压缩数据包还原成原始帧

解码器拿到 Packet，输出 Raw Frame（视频是 YUV/RGB 像素数据，音频是 PCM 采样）

这里有个关键点：视频不是每一帧都完整存了全量像素。比如 H.264 用的是 **GOP（Group of Pictures）**结构：

这意味着：你想跳到第 500 帧？不能从文件中间随便切一刀——必须找到 500 前面的那个 I 帧，从那里开始逐帧 decode 过来。这也是为什么拖时间轴会”顿一下”。

现代编辑器会尽量把这个活丢给 GPU 硬解（NVDEC / Intel Quick Sync / Apple VideoToolbox），让专用电路去干，CPU 省出来跑效果。

Step 3 — 处理 / 特效 / 调色

拿到原始帧数据后，才轮到编辑器的拿手戏：缩放、裁剪、调色、叠加字幕、混合模式……这些操作工作在 Raw Frame（像素）层面。

Step 4 — 显示 / 送回编码（导出时）

预览就直接 RGB→显示器；导出就再走一遍 Encode→Mux 写成新文件。

三、”加载视频”到底是不是一口气塞进内存？——绝对不是

这是最容易误解的地方

Import（导入素材）时：只建”索引”，不读画面

你把一段 10GB 的 4K 素材拖进项目，编辑器做的事是：

1. 1. 读文件的头部信息（编码格式、分辨率、时长、帧率、关键帧位置索引）
2. 2. 在内部建一个 Clip 对象，记录的是：文件路径 + 入点/出点 + 这条流的解码参数
3. 3. 不会把 10GB 复制一份进来，不会把画面解压进 RAM

项目文件可能只有几 MB——因为它存的只是指针和编辑决策，不是媒体本身。

播放头移动到某位置时：按需解码（On-Demand）

当你按播放或拖到 00:12:345：

Seek(00:12:345)
  → 二分查关键帧索引 → 找到最近的 I 帧位置
  → Demux 从那个位置开始吐 Packets
  → Decode 一路解到目标帧（跳过不需要输出的中间帧，或保留少量用于B帧参考）
  → 得到 Raw Frame → 上 GPU 显示

每次只读那一小段需要的数据，用完的旧帧释放掉，不会把整条视频全解出来排队。

那 RAM Preview / 缓存 是怎么回事？

为了让你第二次播同一段不卡，编辑器会把刚解好的帧暂存起来：

所以内存里只会缓存最近播放过的一小段 decoded frames（可能几十秒的量），不是全片。

四、Proxy（代理）解决什么问题？怎么运作？

问题根源

4K H.265 素材压缩得很聪明，但编辑器时间轴需要反复随机访问任意帧。而 H.265 的 Long-GOP（大量 P/B 帧）意味着：

• • 每次 seek 都要回溯到上一个 I 帧再解一串
• • 软解 H.265 4K 很吃 CPU
• • 结果 = 时间轴卡成 PPT

Proxy 的本质：提前转一份”好解的替身”

原始素材：  4K H.265 Long-GOP（难解、吃CPU）
                ↓ 导入时后台转码
Proxy素材：  1080p ProRes Proxy / DNxHR LB（intraframe，每帧自包含，好解10倍）

Proxy 的关键特性：

• • 分辨率更低（1080p 甚至 720p）
• • 用帧内编码（Intraframe），不依赖前后帧——拖到哪就从哪读，不用回溯
• • 码率小很多（5GB/h vs 40GB/h），磁盘吞吐压力也小
• • 存在另一组文件里，带同名/UUID 映射关系

编辑器里实际的切换逻辑

                 ┌─ 你在时间轴上看到的 / 拖动的
                 │          ↓
            [Proxy 开关]──开 → 读 Proxy 文件路径 → 流畅播放
                 │          ↓
                 关 → 读 Original 文件路径 → 高质量但可能卡
                 │
            导出时：无视开关，永远从 Original 采帧 → 保证输出是满分画质

你剪的全是 proxy 的路径和出入点信息，最后导出时再 relink（重新链接）回原始文件采帧。画质零损失，因为真正出片的像素来自原件。

Proxy ≠ “原视频的一部分加载进内存”。它是独立生成的另一份文件，编辑器只是在 Clip 对象里多记了一个 proxy_path 字段，随时切换用哪个。