主题
视频压缩：CRF 不是体积目标
「把这个视频压到 50MB 以内」是个很自然的需求，但视频编码器并不接受这种指令。理解它到底接受什么，就知道压不动的时候该动哪个旋钮。
CRF 控制的是画质，不是体积
主流编码器最常用的参数叫 CRF（Constant Rate Factor，恒定质量因子），取值一般 0～51，数字越小画质越好、体积越大。常用区间是 18～28。
关键在于：CRF 是画质目标，不是体积目标。给定 CRF，编码器会为画面复杂的片段多分配数据、为静止片段少分配，最终体积取决于内容本身。
同样是 CRF 23：
- 一段固定机位的会议录像，画面几乎不动，可能压到几十 MB；
- 同样时长的运动镜头或粒子特效，每帧都在变，可能是前者的十倍。
所以「CRF 设多少能压到 50MB」这个问题没有答案。想要确定体积，需要的是另一套做法（两遍编码 + 目标码率），代价是画质在复杂片段上会明显劣化。
压不下去时，按这个顺序动
第一优先：分辨率。 体积大致随像素数变化。4K 降到 1080P，像素数变成四分之一，体积降幅远超调 CRF。而如果成片只在手机上看，1080P 和 4K 的观感差别微乎其微。
第二优先：帧率。 60fps 降到 30fps，数据量直接减半。除了游戏录屏和体育慢动作，多数内容 30fps 完全够用。
第三优先：时长。 最有效但最容易被忽略——把片头片尾和中间的空白删掉，比任何编码参数都管用。
最后才是 CRF。 从 23 调到 28 大约能省三到四成，但画质开始肉眼可辨，尤其在暗部和渐变区域会出现色块。
转 GIF 是另一回事
GIF 不是视频格式，它每帧都是独立的调色板图像，且最多只有 256 种颜色。所以同样内容转成 GIF，体积往往比原视频还大，画质还更差。
要控制 GIF 体积，能动的是三个量：帧率（10～15fps 通常够用）、尺寸（宽度 480 以内）、时长（超过 10 秒就该考虑用视频）。指望调「质量」参数把 GIF 压小，方向就错了。
剪辑时的一个陷阱
按时间范围裁剪视频有两种做法：无损剪切直接复制原始数据，速度极快、画质零损失，但切点只能落在关键帧上——你要的是 10.0 秒，实际可能从 9.2 秒开始。精确剪切需要重新编码，能切在任意帧，但慢且有一次编码损失。
需要精确对齐字幕或音乐节拍时用后者；只是粗略掐头去尾时用前者，快得多。
字幕：烧进去还是外挂
字幕有两种交付方式，选错了对方就是看不到。
外挂字幕是独立的 .srt / .ass 文件，播放器加载后叠加显示。优点是可以关、可以改、不影响画质；缺点是必须和视频文件一起传，而且很多平台和手机相册根本不加载它。
压制字幕（也叫硬字幕）是把文字直接画进画面像素里。优点是走到哪都在，任何播放器、任何平台都显示；缺点是不可关闭、不可修改，而且要重新编码一次。
发给同事审片用外挂，发到社交平台或微信用压制——后者几乎是唯一能保证对方看得到的方式。
压制前记得确认字幕时间轴和视频对得上：如果视频做过裁剪而字幕没跟着调整，压进去就再也改不了了。
格式互转要看容器和编码
MP4、MOV、MKV、WebM 这几个是容器，不是编码格式。容器负责把视频流、音频流、字幕流装在一起，真正决定画质与体积的是里面的编码（H.264、H.265、VP9、AV1）。
这带来一个实用结论：MOV 转 MP4 常常不需要重新编码——两个容器都能装 H.264，直接换个壳即可，速度快到几乎瞬间完成，画质零损失。而 MP4 转 WebM 就必须重编码，因为 WebM 只接受 VP8/VP9/AV1。
判断依据很简单：目标容器支不支持当前的编码。支持就换壳，不支持才重编。很多人默认「格式转换 = 重新编码」，白白多损失一次画质、多等十几分钟。