从 1 GB 录屏到可交付文件：一套可复现的视频压缩流程

前几天需要把一段产品演示录屏发给同事。视频只有十分钟，文件却接近 1 GB：邮件附件放不下，聊天工具上传很慢，传到测试环境后，手机端首次播放也要等待很久。

一开始我直接把分辨率从 4K 改成 1080P，结果体积仍然不理想。检查源文件后才发现，真正影响体积的不只是分辨率，还有时长、帧率、视频码率、音频码率和编码方式。

这篇文章记录一次可复现的视频压缩流程：先读取源文件参数，再根据交付目标选择 CRF 或目标码率，最后验证画面、声音和兼容性。

核心思路：不要一上来选择“最强压缩”。先明确文件上限和观看场景，再调整参数。

一、先理解文件体积从哪里来

视频文件通常由视频流、音频流、字幕和封装信息组成，其中视频流占用的空间最多。可以使用下面的简化公式估算文件大小：

文件大小（MB）≈ 总码率（Mbps）× 时长（秒）÷ 8

例如，一段 10 分钟的视频，如果总码率为 12 Mbps，理论体积约为：

12 × 600 ÷ 8 = 900 MB

这也解释了为什么有些 1080P 视频仍然很大：分辨率降下来了，但码率没有合理调整。

分辨率决定每帧包含多少像素，帧率决定每秒需要展示多少帧，码率则反映编码后每秒大约使用多少数据。三者相互影响，但并不存在一套适用于所有素材的固定参数。

二、使用 ffprobe 检查源文件

开始视频压缩之前，先用 ffprobe 读取源文件信息：

ffprobe -v error \
  -show_entries format=duration,size,bit_rate \
  -show_entries stream=index,codec_type,codec_name,width,height,r_frame_rate,bit_rate \
  -of json \
  input.mp4

重点关注以下字段：

• duration：视频时长；
• size：当前文件体积；
• bit_rate：整体或单条流的码率；
• width、height：分辨率；
• r_frame_rate：帧率；
• codec_name：视频和音频的编码格式。

读取参数的意义不是收集信息，而是避免无效操作。如果源文件已经被多次转码，再次使用很激进的参数只会放大色块、拖影和文字模糊。

原始素材应单独保留。每次实验都从原文件生成结果，不要拿上一次的压缩文件继续处理。

三、画质优先时使用 CRF

如果目标是网页预览、课程录屏或内部演示，通常不需要把文件精确控制在某个数值，只要体积合理、画面清楚即可。此时可以使用 H.264 的 CRF 模式：

ffmpeg -i input.mp4 \
  -c:v libx264 \
  -preset slow \
  -crf 23 \
  -c:a aac \
  -b:a 128k \
  -movflags +faststart \
  output.mp4

CRF 应该设置多少

crf 数值越低，保留的细节越多，输出文件通常也越大。常见测试区间为 18～28，可以先从 23 或 24 开始。

不同素材对参数的反应并不相同。人物访谈、游戏画面和代码录屏即使使用相同 CRF，输出体积和视觉效果也会有明显差异。

preset 不是画质等级

preset 主要控制编码器愿意花多少时间寻找更高效的表示方式。slow 通常比 fast 花费更多编码时间，但它不是简单的“高清”开关。

-movflags +faststart 会把 MP4 的关键索引信息移动到文件前部，更适合网页渐进式加载。

四、先压缩 30 秒，不要直接跑完整文件

长视频转码可能需要较长时间。为了避免处理完成后才发现字幕模糊，可以先选取一个具有代表性的片段：

ffmpeg -ss 00:02:00 -t 30 -i input.mp4 \
  -c:v libx264 \
  -preset slow \
  -crf 23 \
  -c:a aac \
  -b:a 128k \
  sample.mp4

这个命令从第 2 分钟开始，截取并处理 30 秒。测试片段最好同时包含：

• 快速移动或镜头切换；
• 人物面部、头发等细节；
• 渐变背景和暗部画面；
• 字幕、代码或界面小字；
• 连续声音和明显口型。

用测试片段调整好参数后，再处理完整素材，通常比反复重跑整个文件更节省时间。

五、文件有明确上限时计算目标码率

上传表单、工单附件或邮件经常有明确的体积限制。这时 CRF 模式无法保证最终大小，需要先计算码率预算：

目标总码率（kbps）≈ 目标体积（MB）× 8192 × 0.97 ÷ 时长（秒）

其中 0.97 用于给封装信息和码率波动留出少量空间。再从目标总码率中减去音频码率，就能得到视频流的大致预算。

假设视频时长为 600 秒，目标体积为 100 MB，音频使用 128 kbps：

目标总码率 ≈ 100 × 8192 × 0.97 ÷ 600 ≈ 1324 kbps
视频码率 ≈ 1324 - 128 ≈ 1196 kbps

可以把视频码率取整为 1180k，继续留出安全余量：

ffmpeg -i input.mp4 \
  -c:v libx264 \
  -b:v 1180k \
  -maxrate 1300k \
  -bufsize 2600k \
  -c:a aac \
  -b:a 128k \
  output-under-100mb.mp4

如果文件上限非常严格，可以进一步使用两遍编码，让编码器先分析画面复杂度，再分配码率。实际提交时不要把结果卡在 99.9 MB，平台对 MB 的计算方式和文件封装误差都可能导致上传失败。

六、什么时候应该降低分辨率

如果 4K 素材最终只在文档页面的小窗口中播放，保留全部像素通常没有必要。可以在 FFmpeg 中加入缩放参数：

-vf "scale=-2:1080"

-2 会根据原始比例自动计算宽度，并让结果满足编码器的尺寸要求。

但代码录屏、设计稿演示和数据看板不能只看分辨率数字。小字号文字对缩放很敏感，应该在手机和电脑上以实际播放尺寸检查，而不是把画面放大 400% 后观察。

七、在线工具在视频压缩流程中的位置

在工程化的视频压缩任务中，本地 FFmpeg 更适合重复执行、批量处理和记录参数。浏览器端工具则适合临时任务，或者用来快速生成一个对照结果。

例如，可以选取一段不含敏感信息的短片，在 VideoCompress 中生成一个版本，再与本地 FFmpeg 输出进行对比。比较重点应放在字幕边缘、运动画面、文件体积和声音同步，而不是只看压缩百分比。

客户资料、内部会议、未发布产品和包含个人信息的视频，应该优先采用团队批准的本地环境。

八、处理完成后的验证清单

视频压缩完成后，不要只确认文件变小了。建议逐项检查：

• 输出体积低于目标平台限制，并留有余量；
• 时长、开头和结尾没有被意外截断；
• 字幕、代码和界面文字仍然清晰；
• 快速运动区域没有明显色块或拖影；
• 渐变背景没有严重色带；
• 音画同步，音量没有异常变化；
• 手机、电脑和目标浏览器均可正常播放；
• 原始素材已单独备份。

可以再次运行 ffprobe，把输出文件的体积、时长、分辨率、码率和编码格式记录下来。如果后续需要批量处理，这些数据可以作为脚本参数和质量基线。

九、几个常见误区

反复压缩同一个成品

有损编码会丢弃部分信息。需要调整参数时，应返回原始素材重新生成，避免失真不断累积。

只降低分辨率

分辨率只是影响因素之一。码率仍然过高时，1080P 文件也可能很大；码率过低时，保留 1080P 也不代表画面清楚。

一次修改多个变量

同时改变分辨率、帧率、CRF 和音频码率后，很难判断是哪项设置造成画质变化。测试阶段最好一次只调整一个变量。

只在电脑上检查

开发者电脑能够顺利播放，不代表移动网络和手机浏览器的体验同样可靠。最终验证应回到真实交付环境。

写在最后

可靠的视频压缩不是追求最小文件，而是在交付限制内保留真正有用的信息。

先用 ffprobe 了解源文件，再根据目标选择 CRF 或码率预算；必要时调整分辨率，最后通过代表性片段和多设备播放验证结果。把这些步骤固定下来，临时操作就能逐渐变成可复现、可维护的处理流程。

本作品采用《CC 协议》，转载必须注明作者和本文链接