从90MB到156MB：为什么视频剪短了反而变大了？——程序员的视频编码避坑指南

我想要身体健康

2544人浏览 · 2026-01-07 15:01:17

我想要身体健康 · 2026-01-07 15:01:17 发布

最近在制作关于 ESP32-C3 烧录 的技术分享视频时，我遇到了一个非常反直觉的现象：

我使用 OBS 录制了 20 分钟的原始素材（MKV格式），文件大小只有 91.3 MB。
然而，当我把视频导入剪辑软件，剪切掉废话，缩短到 7 分钟并导出后，文件大小竟然飙升到了 156 MB。

时长缩短了 60%，体积却膨胀了 70%。 这听起来不符合逻辑，但对于视频编码来说，这却是一个经典的“新手陷阱”。

今天这篇博客就来复盘一下这个问题，聊聊视频编码背后那些关于“码率”和“压缩”的底层逻辑。

1. 为什么代码演示视频可以这么小？

首先我们要理解视频压缩的一个核心概念：帧间压缩 (Inter-frame Compression)。

视频不仅仅是一连串的图片。现代编码器（如 H.264/H.265）非常聪明，它们不会把每一帧都完整存下来。

I帧 (关键帧)：记录完整的画面。
P/B帧 (预测帧)：只记录“相对于上一帧变化的部分”。

对于我的 ESP32 烧录演示视频，画面内容大部分时间是 VS Code 代码编辑器 或 终端窗口。在我不打字、不切换窗口的那几十秒里，屏幕像素几乎是静止的。

这时候，编码器只需要在文件中记录一条指令：“同上 (Same as before)”。这占用的数据量微乎其微。因此，OBS 录制的 20 分钟原始视频，平均码率只有 626 kbps，体积自然极小。

2. 剪辑软件的“一刀切”逻辑

既然原始视频压缩率这么高，为什么剪辑后变大了？

问题出在导出设置上。

当我们把视频拖入剪辑软件（如剪映、Premiere）并点击导出时，软件执行的是 “解码 -> 渲染 -> 重编码” 的过程。它并不知道你的源视频是“静态的代码”，它只遵循一个死板的公式：

$(Duration)\text{文件体积} \approx \text{码率 (Bitrate)} \times \text{时长 (Duration)}$

大多数剪辑软件的默认“推荐码率”通常是为了应对游戏或实拍风景视频（画面剧烈运动）设计的，往往设定在 5000 kbps - 10000 kbps。

原始视频：智能地使用了 626 kbps。
导出视频：软件傻傻地强制填充了 10200 kbps (10 Mbps) 的数据量。

这就好比我要寄一张邮票（静态画面），原始包装只是一个信封；但快递公司（剪辑软件）非要强制我买一个装冰箱的大木箱来装这张邮票。虽然东西还是那个东西，但体积却撑大了十几倍。

3. 避坑指南：程序员如何正确导出？

了解了原理，解决办法就很简单了。对于代码演示、PPT讲解、软件教程这类“低动态”视频，我们在导出时需要手动干预。

核心参数设置建议：

参数	默认设置 (坑)	推荐设置 (代码/教程类)	说明
码率 (Bitrate)	8000-10000 kbps	1500 - 2500 kbps	静态画面 1500k 足够清晰
模式	CBR / 智能推荐	VBR (动态码率)	允许静止时自动降低码率
编码 (Codec)	H.264	HEVC (H.265)	同画质下体积减半，B站已支持
分辨率	4K / 1080P	1080P (30fps)	代码演示不需要 60fps

实操案例

在剪映或必剪的导出界面，将“码率”从“推荐”改为“自定义”，手动输入 2000。你会发现，导出的 7 分钟视频将从 150MB 骤降至 60MB 左右，且肉眼几乎看不出画质区别。

4. 延伸知识：MKV vs MP4

细心的朋友可能发现，我原始录像用的是 .mkv，导出用的是 .mp4。

MKV (Matroska)：是一个万能容器。OBS 推荐用它是因为它具有容错性。如果录制过程中电脑蓝屏或断电，MKV 文件断电前的内容依然可以播放；而 MP4 因为索引写在文件尾部，一旦未正常结束，整个文件就会损坏无法打开。
MP4：是兼容性之王。剪辑完成后，为了确保在网页、微信、各种设备上都能播放，导出为 MP4 是最佳选择。

总结

视频编码其实和写代码一样，没有绝对的“最佳配置”，只有“最适合场景的配置”。

作为开发者，我们习惯了掌控细节。下次在导出视频时，不要盲目相信软件的“自动推荐”，看一眼 Bitrate，手动填上一个合理的数字，你的硬盘会感谢你的。

Next Step: 如果你也对自建 NAS 或整理大量视频素材感兴趣，可以研究一下 FFmpeg 命令行工具，它能帮你批量处理这些“虚胖”的视频文件。


---

### **💡 博客发布小贴士：**

1. **配图建议**：
* 可以在“帧间压缩”那一段，配一张 I 帧和 P 帧的示意图（或者你之前那张 156MB 和 90MB 的对比截图）。
* 在“参数设置”部分，放一张剪映导出界面的截图，圈出“码率”和“自定义”的位置。


2. **SEO 优化**：
* 我在 Front Matter (文章头部) 里加了 `H.265`, `Bitrate`, `FFmpeg` 等标签，这有助于搜索引擎检索。


3. **后续互动**：
* 文章结尾预留了关于 NAS 和 FFmpeg 的引子，如果你以后写 Proxmox 或 NAS 相关的文章，可以链接回来，形成知识闭环。



你看这篇草稿的风格是否符合你的要求？如果需要调整语气（更严肃或更幽默），随时告诉我！