片库越攒越大，最后卡住我的不是 4K，是一批早年的 1080p 剧集：单集三四 GB，一部十二集就吃掉四十多 GB，投到电视上隔三米看，和现在两 GB 一集的也没差多少。为了决定到底该压到多少，我把同一段母带用十组参数各压了一遍。
先说清楚测的是什么
母带是公开测试片 Big Buck Bunny，1080p30、24.5 Mbps，循环拼成 60 秒，不做任何预处理，直接当参照。机器是 Ryzen 5 3550H（4 核 8 线程）、16GB 内存，ffmpeg 用 2026-10-31 的构建 N-128227，x264、x265、SVT-AV1、AMF 都在包里。
耗时按墙钟算，只算编码；画质用 VMAF，取母带第 20~28 秒计算，8 线程。VMAF 90 以上日常看不出差别，85 左右要在暗部和平滑渐变里找块，80 以下一眼就能发现。
素材是动画，边缘锐利、平滑色块多，属于好压的一类；实拍带颗粒和暗部噪点，同样 CRF 下码率会更高。所以这张表看的是参数之间的差距，别把绝对值当准数。
十组参数，一张表
| 参数 | 60 秒耗时 | 体积 | 码率(Mbps) | VMAF |
| --- | --- | --- | --- | --- |
| x264 ultrafast · CRF 23 | 23.3s | 223.4MB | 31.23 | 93.26 |
| x264 veryfast · CRF 23 | 35.7s | 29.6MB | 4.14 | 93.50 |
| x264 fast · CRF 23 | 75.2s | 41.9MB | 5.86 | 95.03 |
| x264 medium · CRF 23 | 96.5s | 43.1MB | 6.03 | 94.75 |
| x264 medium · CRF 20 | 105.5s | 68.8MB | 9.62 | 96.36 |
| x264 medium · CRF 26 | 85.8s | 27.4MB | 3.83 | 92.57 |
| x265 medium · CRF 24 | 170.5s | 35.0MB | 4.89 | 95.26 |
| x265 medium · CRF 26 | 151.1s | 25.5MB | 3.56 | 94.06 |
| SVT-AV1 preset 8 · CRF 32 | 87.2s | 31.9MB | 4.46 | 95.57 |
| h264_amf · 4 Mbps（Vega 8） | 29.2s | 28.9MB | 4.04 | 85.43 |
CRF 数字越大丢得越多；x265 的标尺和 x264 不是一回事，两列不能横着比。想在自己的片源上复核，把 -preset 和 -crf 换着跑，比体积、再让 ffmpeg 接一段 libvmaf 打分就行。
三个和直觉相反的结论
一、ultrafast 花了 7.5 倍体积，画质还更低
223.4MB 对 29.6MB，93.26 对 93.50。查一下编码器输出的 profile 就明白：ultrafast 落到 Constrained Baseline，等于关掉 CABAC 换回 CAVLC、不要 B 帧、参考帧只留一帧。熵编码效率一低，CRF 就管不住码率了——它只决定量化步长，剩下的体积全是白送的。真要赶时间，veryfast 才是底线。
二、fast 和 medium 打平，medium 白花 21 秒
fast：41.9MB、95.03；medium：43.1MB、94.75。多等 21 秒，体积大了 1.2MB，分数反倒低 0.28。medium 多开的 trellis 和参考帧搜索，在这种运动平缓、边缘锐利的内容上收益很小，预算反而摊给了参考帧。所以批量我一律用 fast，只有颗粒重的实拍片才拿 slower 试一小段。
三、显卡硬编只快 3.3 倍，画质掉到 85
Vega 8 的 h264_amf，60 秒素材 29.2 秒压完，VMAF 只有 85.43，人物横移时边缘有拖影、暗部成块。它不做 CRF，只认目标码率，快的那部分被码率控制吃掉了。同一档 4 Mbps 换 x264 跑两遍编码：89.1 秒、93.26——同码率差 7.8 分，瓶颈不在码率给得够不够，在编码器会不会分配。但两遍本身也不划算，veryfast 用 CRF 23 是 4.14 Mbps、93.50，只要 35.7 秒。
换算成一集 45 分钟，音轨才是大头
码率 × 2700 秒 ÷ 8：2 Mbps 约 675MB，4 Mbps 约 1.35GB，6 Mbps 约 2.0GB。对回表里，x264 fast CRF 23 是 5.86 Mbps，一集约 1.98GB；veryfast 是 4.14 Mbps，约 1.4GB，差的是 1.5 分 VMAF。十二集算下来 24GB 对 17GB，隔三米看，我选小的那版。测试片段运动连续、密度偏高，真实剧集有大量对话和静态镜头，实际往往还小一两成。
音轨常被忽略：照抄 DTS-HD MA 的 1.5 Mbps，45 分钟光声音就 506MB；TrueHD 那种 3 Mbps 起步的，音频比视频还沉。转 AAC 192k 只有 65MB，老片重新封装能掉三分之一体积，多数时候是音轨让的位。
二次压制，和我最后留下的参数
把 medium CRF 23 的产物（43.1MB、94.75）用同样参数再压一遍：38.7MB、93.17。体积只少一成，画质实打实掉 1.6 分——第一遍该去的冗余已经去干净，第二遍只剩细节可砍。
现在固下来的：剧集动画用 x264 CRF 22~23、preset fast、AAC 192k，容器加 -movflags +faststart；想省空间用 SVT-AV1 preset 8 CRF 32（31.9MB、95.57，比 x264 小四分之一，耗时还短一成，代价是老设备放不了）；要兼容就用 x265 CRF 24（35.0MB、95.26，慢 77%）；4K 原盘不转码，直通播放。
两个坑：-crf 和 -b:v 同时写会按 ABR 走，CRF 被忽略，你以为在定质量其实在定码率；-c:a copy 复制 DTS/TrueHD 音轨看着省事，播放端未必解得了，体积还全在它身上。
有些片子就别压了
不是所有片子都值得走一遍。已经压过的片源（WEB-DL、BDRip、各种重封装）再压一次，就是上面那组代际数据的现实版：体积只降一成，画质掉的是实打实的细节，越老的片源亏得越多。真要省空间，先删掉不看的，比压片划算。
带 HDR 的更麻烦。8bit 的 x264 转一遍，色调映射没做好，画面就是一片灰——这不是参数问题，是色彩链路断了。这类片源要么直通播放，要么走 10bit 的 x265 配上正确的 tone mapping，前者省事得多。
4K 原盘同理：码率本来就压得紧，硬件解码又都跟得上，转码的唯一收获是更长的等待时间和更小的细节。
你们压片是一次压到位，还是留原盘、另存一版小的？