视频转码与体积优化实战：H.264、H.265 与 AV1 到底怎么选

凌晨一点十四分，进度条走到 100%，Premiere 弹出"导出完成"。你盯着那个 2.4GB 的 MP4，心里刚松了一口气，微信就亮了——客户发来一句：“文件太大了传不过去，能不能压到 200M 以内？画质别掉太多。”

你打开百度网盘看了一眼上传速度，又看了一眼桌角已经凉透的咖啡，默默把 ffmpeg 敲进了终端。如果你也经历过这个场景，这篇文章就是写给你的：从 H.264、H.265 到 AV1，三代编码器到底怎么选，CRF 和码率怎么调，以及一套可以直接抄走的批量转码脚本。

📑 文章目录

• 一. 🌅 先搞清楚：视频为什么能被压缩
• 二. 🏗️ H.264、H.265、AV1 三代编码器原理对比
• 三. 🎯 CRF 与码率：转码参数到底怎么调
• 四. 🛠️ ffmpeg 实战：从单条命令到进阶姿势
• 五. ⚠️ 兼容性现实：体积省一半，播放器答应吗
• 六. 🌟 批量转码脚本：Bash 与 Python 两套方案
• 七. 🚀 选型决策：一张决策路径图
• 八. 📝 总结
• 参考文献

---

一. 🌅 先搞清楚：视频为什么能被压缩

在讨论"选哪个编码器"之前，得先明白一件事：一段 1080p 30fps 的视频，如果完全不压缩，每秒的数据量大约是 1920 × 1080 × 3 字节 × 30 ≈ 186MB。而你手机拍的同规格视频每秒只有几 MB，差了近两个数量级。这中间的全部魔法，就是视频编码（Video Coding）。

编码器的本质是去除冗余，冗余主要来自三个层面：

• 空间冗余：同一帧画面里，相邻像素往往颜色接近（天空、墙面、皮肤）。用 DCT 变换 + 量化，把"每个像素都存一遍"变成"只存低频系数"。
• 时间冗余：相邻两帧之间，大部分画面没变。运动估计（Motion Estimation）只记录"哪块区域往哪挪了多少"。
• 统计冗余：出现概率高的符号用短码、概率低的用长码（CABAC、算术编码），进一步压榨字节。

理解了这三点，后面所有的参数调优就都顺理成章了：CRF 调的是量化强度，preset 调的是运动搜索的用力程度，编码器的代差则体现在"块划分方式与帧内预测工具是否更聪明"。

💡 重点提示

编码器不生产信息，它只是冗余的搬运工。“画质不掉体积减半"的代价，永远在别的地方——编码时间、解码功耗或兼容性。本文后面所有选型建议，都是在替你回答"这个代价你愿不愿意付”。

二. 🏗️ H.264、H.265、AV1 三代编码器原理对比

2.1 H.264（AVC）：2003 年的绝对王者

H.264 由 ITU-T VCEG 与 ISO/IEC MPEG 联合制定，2003 年定稿。它把画面切成 16×16 的宏块（Macroblock），配合多参考帧、CABAC 熵编码、去块效应滤波器，在当时实现了" DVD 画质、码率减半"的跨越。

它的杀手锏不是压缩率，而是生态：从 2008 年后的几乎所有手机芯片、浏览器、智能电视、剪辑软件都内置了 H.264 硬件编解码。直到今天，“发给客户一个保底能放的文件”，答案依然是 H.264。

补充一个很多人没意识到的细节：x264 这个开源编码器本身就是 H.264 生态的功臣。它从 2004 年由 VideoLAN 社区发起，用十几年的迭代把"广播级画质消费级硬件"的门槛拉到了人人可用的水平。你在 ffmpeg 里写的 -c:v libx264，背后是这世界上被复用得最多的一段视频编码代码。也正因为如此，围绕它的参数调优资料最全、踩坑经验最沉淀，初学者的第一课永远是 x264。

2.2 H.265（HEVC）：省一半体积，交一半朋友

H.265 在 2013 年定稿，核心升级是把宏块换成了编码树单元（CTU，最大 64×64），支持四叉树递归划分；帧内预测方向从 9 种暴增到 35 种；加入了 CABAC 的并行改进、SAO 样本自适应补偿等工具。官方口径：同等主观画质下，码率比 H.264 节省约 50%。

但它有两个致命伤：

1. 专利费：HEVC 的专利池分裂成 MPEG LA、HEVC Advance、Velos 三个阵营，收费口径混乱，直接把浏览器阵营吓跑了——Chrome、Firefox 至今不支持 HEVC 软解（Apple 平台例外）。
2. 解码开销：解码功耗约为 H.264 的 2-3 倍，低端安卓机上硬解支持参差不齐。

思考：💡 既然 H.265 省一半体积，为什么 2026 年了还有大量平台默认输出 H.264？

🤔 因为编码格式从来不是技术单选题，而是生态题。接收方能不能放、直播 CDN 按什么格式计费、剪辑软件时间线是否流畅，这些约束的权重往往大于"省一半体积"。选编码器的第一原则：看最弱的那台接收设备，而不是看最强的那台旗舰手机。

2.3 AV1：开源阵营的反击

AV1 由开放媒体联盟（AOMedia，Google、Amazon、Netflix、Intel、Mozilla 等）于 2018 年发布，免版税是它最大的政治资本。技术上它站在 VP9 肩膀上：更大更灵活的块划分（128×128 superblock，递归到 4×4）、帧内预测多达 56 种方向模式、复杂的帧间预测工具（OBMC、 warped motion）、以及专为屏幕内容设计的调色板模式（Palette）。

代价同样明确：编码极慢。同样的画质，SVT-AV1 的编码耗时通常是 x264 medium 的 3-10 倍。YouTube、Netflix 已经在大规模使用 AV1 做分发（服务端编码一次、亿万次播放摊薄成本），但对个人创作者的"导出即传"场景，编码时间仍是真实门槛。

好消息是 SVT-AV1（Intel 主导开源的编码器实现）近几年的速度优化非常激进，preset 6-8 档位的编码速度已经进入了"一集电视剧几分钟"的可接受区间，加上免版税的加持，AV1 的个人创作者采用率正在肉眼可见地上升。另外，浏览器阵营对 AV1 的支持已经齐了：Chrome 70+、Firefox 67+、Edge 都内置了 AV1 解码，dav1d 解码器的软解性能在普通笔记本上播 1080p 毫无压力——这在 HEVC 身上从未发生过。

2.4 三代编码器速查表

维度	H.264/AVC (2003)	H.265/HEVC (2013)	AV1 (2018)
制定方	MPEG + VCEG（JVT）	MPEG + VCEG（JCT-VC）	AOMedia
专利费	收费（池子成熟）	收费（池子分裂）	免版税
同画质体积	基准 1.0	约 0.5	约 0.35-0.45
块划分	16×16 宏块	CTU 64×64 四叉树	Superblock 128×128 多类型树
帧内预测方向	9 种	35 种	56+ 种
编码速度	快	慢约 3-5 倍	慢约 3-10 倍
浏览器支持	全平台	Chrome/Firefox 桌面版不支持	Chrome/Edge/Firefox 均支持
硬件解码	全民级	2016 年后中高端芯片	2022 年后新芯片逐步普及
典型场景	分发保底、剪辑	4K 存档、局域网串流	Web 分发、长视频平台

💡 另一个常被忽略的点：视频规格里还藏着像素位深（8bit/10bit）与色度采样（4:2:0/4:2:2）。10bit 编码（-profile:v main10）在同为 H.264/H.265 时反而常能以相近码率获得更好的渐变表现，x264/x265 的 10bit 路径优化相当成熟，不必谈"10bit"色变。

三. 🎯 CRF 与码率：转码参数到底怎么调

这是整个转码环节最容易被问糊的部分，一次说清。

3.1 两种码控模式

ffmpeg 的码率控制本质是三种模式的取舍：

• CRF（Constant Rate Factor，恒定质量）：编码器根据画面复杂度自适应分配码率——静止的访谈镜头少给点，打斗、水波、雨雪多给点。输出体积不可预知，但单位体积的画质性价比最高。适合本地存档、一次性交付。
• ABR / 2-pass（目标码率）：指定"我就要 2Mbps"，2-pass 会先扫一遍分析复杂度分布再分配。输出体积精确可控。适合直播、带宽受限传输。
• CQP（恒定 QP）：每一帧用相同的量化参数，研究用得多，实战少。

日常建议很简单：能用 CRF 就用 CRF，需要卡体积上限时再上 2-pass。

3.2 CRF 数值怎么定

CRF 是"质量刻度"而不是"质量百分比"，不同编码器的数值含义不同，这点坑了无数人：

编码器	CRF/QP 范围	视觉无损参考点	常用区间	数值越大
x264 (H.264)	0-51	≈ 16-18	20-24	画质越差、体积越小
x265 (H.265)	0-51	≈ 18-20	22-26	同上
SVT-AV1	0-63	≈ 20-24	28-35	同上

注意 x265 的 CRF 26 大致对应 x264 的 CRF 21-22 的观感，直接把 x264 的 CRF 值照搬给 x265，等于白白浪费一档质量。SVT-AV1 的刻度又更松，30 左右就开始进入"手机屏幕上很难挑出毛病"的区间。

3.3 preset：时间换质量

preset 决定编码器"用多大力气找最优运动向量"。同一 CRF 下，preset 越慢，同画质体积越小（或同体积画质越好），但编码时间急剧上升。以 x264 为例，medium 与 veryslow 在 CRF 23 下体积差约 10-15%，耗时差 5-10 倍。日常建议 medium，重要交付用 slow，存档用 slower，别迷信 placebo。

3.4 VBV：给 CRF 加一道"码率天花板"

CRF 模式有个隐藏问题：遇到高复杂度片段（婚礼现场撒花瓣、演唱会频闪灯光、体育镜头快速摇移），编码器会毫不犹豫地砸码率，瞬时码率可能飙到平均值的 5-10 倍。本地播放无所谓，但网盘在线预览、弱网串流就会卡顿。解决办法是给 CRF 加上 VBV 约束：

# CRF 保画质 + VBV 限峰值：平均不超过 4Mbps、峰值不超过 6Mbps
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 22 \
       -maxrate 6M -bufsize 12M output.mp4

-maxrate 限制瞬时码率上限，-bufsize 是解码端缓冲区大小（经验值取 maxrate 的 2 倍）。加上之后，编码器在复杂片段会"咬着牙"提量化参数，而不是放飞自我。直播推流、网盘分发、嵌入网页的视频，都建议带上这两个参数。

顺带说一句帧率：很多人压体积时第一反应是降帧率（60fps 砍到 30fps），但帧率减半省下的体积通常只有 20-30%，而运动流畅度的损失是肉眼立刻可见的。**降帧率是体积优化里性价比最低的一档，除非素材本身就是静态画面（PPT 录屏、幻灯片课程），否则不要动它。**反过来，录屏类内容用 H.265 的人编码器（如 libx265）配合 tune 还能进一步压扁。

思考：💡 客户要求"200MB 以内、画质尽量好"，但 CRF 模式根本不知道输出多大，怎么办？

🤔 两板斧。第一板：用 CRF 先压一遍看结果，CRF 调大 2 往往体积降 15-25%，两三轮就能逼近目标；第二板：直接上 2-pass 精确命中目标，命令是 -b:v 配合 -pass 1/-pass 2，代价是编码两遍。想省事的话，还可以先 CRF 转码再估算、失败回退 2-pass——后面第六章的批量脚本就内置了这个逻辑。

四. 🛠️ ffmpeg 实战：从单条命令到进阶姿势

4.1 三条基准命令

先把三代编码器的标准转码命令放这，参数逐个讲：

# H.264：通用分发，兼容性天花板
ffmpeg -i input.mov -c:v libx264 -preset medium -crf 20 \
       -pix_fmt yuv420p -c:a aac -b:a 128k output_h264.mp4

# H.265：体积敏感的本地存档 / 4K 素材
ffmpeg -i input.mov -c:v libx265 -preset slow -crf 24 \
       -tag:v hvc1 -pix_fmt yuv420p -c:a aac -b:a 128k output_h265.mp4

# AV1：Web 分发、长视频、免版税场景
ffmpeg -i input.mov -c:v libsvtav1 -preset 6 -crf 30 \
       -pix_fmt yuv420p -c:a libopus -b:a 96k output_av1.mkv

几个参数值得单独点名：

• -pix_fmt yuv420p：必写。剪辑软件常导出 yuv422p 或 prores 的 444，很多播放器/手机只认 420，不加这条，"文件能传但打不开"的锅就背上了。
• -tag:v hvc1：H.265 文件想在 QuickTime / 苹果生态播放，必须把 tag 从默认的 hev1 换成 hvc1，这是 macOS 用户最常踩的坑之一。
• -c:a：视频变小的同时别忘了音频。对白类内容 AAC 128k 足够；AV1 容器配 Opus 性价比更高。
• -preset 6（SVT-AV1）：它的 preset 范围是 0-13，数字越大越快，6-8 是画质与速度的甜点区。

4.2 不重新编码的"体积手术"

很多时候根本不需要完整转码。如果源文件画质冗余很大，copy 模式零损失、秒级完成：

# 只砍音频码率，视频流原样复制
ffmpeg -i input.mp4 -c:v copy -c:a aac -b:a 96k output.mp4

# 去掉多余的音轨/字幕轨，体积立减
ffmpeg -i input.mp4 -map 0:v:0 -map 0:a:0 -c copy output.mp4

# 估算某 CRF 下的体积（先跑 1 分钟样本再等比放大）
ffmpeg -ss 00:01:00 -t 60 -i input.mp4 -c:v libx265 -crf 24 -f null -

最后一条的小技巧很实用：先拿 60 秒样本试参数，体积乘以总时长再乘 1.1 的安全系数，比整片压完才发现超标快得多。

思考：💡 同样的命令，为什么朋友 Windows 机器上跑 5 分钟，你的 Mac 要 20 分钟？

🤔 ffmpeg 默认走的 x264/x265 是 CPU 软编码，速度取决于单核性能与编译选项；VideoToolbox（macOS）和 NVENC（NVIDIA）这类硬件编码器快 10 倍以上，但同码率画质略逊于软编码。分发保底选硬编没毛病，重要存档还是建议软编——用 -c:v h264_videotoolbox 或 -c:v hevc_nvenc 可以快速验证你机器的硬编吞吐。

4.3 检查结果：ffprobe 三板斧

# 看编码器、码率、时长、流信息
ffprobe -v error -show_entries format=duration,bit_rate:stream=codec_name,width,height,profile -of default=noprint_wrappers=1 output.mp4

# 对比两个文件的每帧大小分布（排查码率尖刺）
ffprobe -v error -select_streams v:0 -show_entries frame=pkt_size -of csv output.mp4 | head -50

# 计算视频流平均码率（kbps）
ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate -of csv=p=0 output.mp4

体积优化做多了你会形成肌肉记忆：先看 bit_rate，再看 profile，最后才看分辨率——很多时候 4K H.264 转成 1080p 都不如原分辨率换 H.265 来得聪明。

4.4 滤镜链：缩放、截取与缩略图

转码之外，滤镜链（-vf）是 ffmpeg 的另一半威力。批量处理素材库时，下面三条出场率最高：

# 高质量缩放到 1080p（lanczos 是缩小场景的稳妥选择）
ffmpeg -i input_4k.mp4 -vf "scale=-2:1080:flags=lanczos" \
       -c:v libx265 -crf 22 -tag:v hvc1 -c:a copy output_1080p.mp4

# 从长视频里抽一段出来交付（-ss 放 -i 前面是关键帧快速定位）
ffmpeg -ss 00:03:20 -to 00:05:40 -i input.mp4 \
       -c:v libx264 -crf 20 -c:a aac -b:a 128k clip.mp4

# 给素材库批量生成封面缩略图（取第 10 秒那一帧）
ffmpeg -ss 00:00:10 -i input.mp4 -frames:v 1 -q:v 3 cover.jpg

第一条里 -2:1080 的写法含义是"高度 1080，宽度按比例自动计算并取偶数"——视频分辨率宽高都必须是偶数，直接写 -1 遇到奇数比例会报错，-2 是老手标配。第三条生成封面图的命令，配合第六章的批量脚本，可以给整个素材库一键配齐预览图，挑素材的效率完全不是一个量级。

五. ⚠️ 兼容性现实：体积省一半，播放器答应吗

技术再好，接收方放不出来就是零分。这里是三条经验主义的红线：

第一条：给不确定的接收方，永远 H.264 + yuv420p + AAC-LC。 微信传输、U 盘拷给甲方、发给长辈——任何你无法控制对方设备的场景，H.264 是唯一不需要赌的选项。

第二条：H.265 只在你可控两端时使用。 自己的 NAS 存档、局域网串流到自家电视、发给同样用 Mac 的剪辑同事。一旦链路里出现 Chrome 浏览器或 2016 年前的安卓机，HEVC 就可能黑屏。

第三条：AV1 的正确位置是"Web 平台分发"。 上传到支持 AV1 转码的平台（YouTube 上传 VP9/AV1 源会被更高效地处理）、或者自家网站用 <video> 标签 + 多码率 fallback。直接把 AV1 文件发人，和 2015 年把 HEVC 发给 Chrome 用户是同一种行为艺术。

再说两个实际排查中高频出现的"玄学问题"。一是 MP4 容器里的 H.265 在部分 Windows 播放器上只有声音没有画面，九成是 hev1/hvc1 tag 问题，加 -tag:v hvc1 重封装即可（-c copy 就够，不用重编码）；二是转码后快进卡顿、进度条拖不动，这是因为关键帧间隔太大，默认关键帧间隔对剪辑交付素材来说往往不够密，交付前用 -g 48（约每 2 秒一个关键帧）会更友好。这些细节不会出现在任何教程标题里，但每个深夜都真实地折磨过某个人。

接收场景	推荐编码	推荐 CRF/QP	容器	音频
微信/邮件交付	H.264	20-23	MP4	AAC 128k
本地长期存档	H.265	22-24	MKV/MP4	AAC/FLAC
4K 素材归档	H.265 10bit	20-22	MKV	原轨保留
网站 / Web 播放	AV1 (+H.264 fallback)	30-34	MP4/WebM	Opus/AAC
上传视频平台	原画质 H.264 高码率	16-18	MP4	AAC 256k

💡 上传平台那条是反直觉的：给平台喂"高码率 H.264 原片"往往比自己压 AV1 上传效果更好——平台的二压算法对高质量输入的还原度更高，你本地压太狠反而会被二次劣化。

六. 🌟 批量转码脚本：Bash 与 Python 两套方案

单个文件转码是手艺活，几十个素材批量处理就是工程问题——这正是"素材资产化"的第一步。下图是我自己处理批量素材前的获取工作台：

6.1 Bash 一把梭版本

适合目录里一堆 mov/mp4 混杂、想统一转成 H.265 存档的场景：

#!/usr/bin/env bash
# batch_transcode.sh — 目录批量转 H.265 存档
set -euo pipefail

SRC_DIR="${1:-./source}"
DST_DIR="${2:-./output}"
CRF="${3:-24}"

mkdir -p "$DST_DIR"

for f in "$SRC_DIR"/*.{mp4,mov,avi,mkv}; do
  [[ -e "$f" ]] || continue
  name=$(basename "$f")
  echo ">>> 转码中: $name"
  ffmpeg -y -i "$f" \
    -c:v libx265 -preset slow -crf "$CRF" -tag:v hvc1 \
    -pix_fmt yuv420p \
    -c:a aac -b:a 128k \
    -movflags +faststart \
    "$DST_DIR/${name%.*}.mp4" < /dev/null
done

echo "全部完成，输出目录: $DST_DIR"

-movflags +faststart 值得单独说：它把 moov atom 挪到文件头，网页/网盘在线播放时可以边下边看，不加的话播放器要等整个文件下载完才能起播。另外循环里的 < /dev/null 不是可有可无的仪式感——没有它，ffmpeg 在某些终端环境下会吞掉后续循环的输入，导致第二条文件开始参数全部错乱，这种 bug 一旦出现能查到你怀疑人生。

6.2 Python 增强版：体积不达标自动降档重压

结合第三章"CRF 试压 + 2-pass 兜底"的策略，写一个真正实用的批量工具：

#!/usr/bin/env python3
"""batch_optimize.py — 批量压到目标体积，CRF 优先，2-pass 兜底"""
import subprocess
import sys
from pathlib import Path

TARGET_MB = float(sys.argv[2]) if len(sys.argv) > 2 else 200.0
ENCODER = "libx265"          # 可换 libx264 / libsvtav1
CRF_START = 22               # 起始 CRF，按编码器调整

def probe_size_mb(path: Path) -> float:
    out = subprocess.check_output([
        "ffprobe", "-v", "error", "-show_entries",
        "format=size", "-of", "csv=p=0", str(path)
    ])
    return int(out.strip()) / 1024 / 1024

def transcode(src: Path, dst: Path, crf: int) -> None:
    subprocess.run([
        "ffmpeg", "-y", "-i", str(src),
        "-c:v", ENCODER, "-preset", "medium", "-crf", str(crf),
        "-tag:v", "hvc1", "-pix_fmt", "yuv420p",
        "-c:a", "aac", "-b:a", "128k",
        "-movflags", "+faststart",
        str(dst),
    ], check=True, capture_output=True)

def optimize(src: Path) -> Path:
    dst = src.with_name(f"{src.stem}_opt.mp4")
    crf = CRF_START
    while crf <= 30:                       # CRF 逐档加压
        transcode(src, dst, crf)
        if probe_size_mb(dst) <= TARGET_MB:
            print(f"[OK] {src.name} -> {probe_size_mb(dst):.1f}MB @CRF{crf}")
            return dst
        crf += 2
    bitrate = int(TARGET_MB * 8192 / (probe_duration(src) or 1))
    two_pass(src, dst, bitrate)            # 2-pass 精确兜底
    return dst

def probe_duration(src: Path) -> float:
    out = subprocess.check_output([
        "ffprobe", "-v", "error", "-show_entries",
        "format=duration", "-of", "csv=p=0", str(src)
    ])
    return float(out.strip())

def two_pass(src: Path, dst: Path, bitrate_kbps: int) -> None:
    for p in ("1", "2"):
        cmd = ["ffmpeg", "-y", "-i", str(src)]
        if p == "1":
            cmd += ["-c:v", ENCODER, "-b:v", f"{bitrate_kbps}k", "-pass", "1", "-f", "null", "-"]
        else:
            cmd += ["-c:v", ENCODER, "-b:v", f"{bitrate_kbps}k", "-pass", "2",
                    "-tag:v", "hvc1", "-pix_fmt", "yuv420p",
                    "-c:a", "aac", "-b:a", "128k", "-movflags", "+faststart", str(dst)]
        subprocess.run(cmd, check=True, capture_output=True)
    Path("ffmpeg2pass-0.log").unlink(missing_ok=True)

if __name__ == "__main__":
    targets = [Path(p) for p in [sys.argv[1]]] if Path(sys.argv[1]).is_file() \
              else sorted(Path(sys.argv[1]).glob("*.mp4"))
    for t in targets:
        optimize(t)

脚本逻辑：CRF 从 22 起步，每轮超体积上限就 +2 重压，到 30 仍不达标就切 2-pass 按目标体积精确命中。整晚挂着跑，早上收货。

思考：💡 批量处理的素材如果来自各平台下载，版权上有什么要注意的？

🤔 两点底线：一是用途边界——平台素材下载后仅作个人学习、剪辑练习与技术验证，遵守原平台版权规则，商用必须走授权；二是保留溯源——批量入库时保留来源链接与作者信息，这也是我坚持把"来源"作为素材元数据第一字段的原因。转码是技术问题，素材从哪来是原则问题，后者不能省事。

顺带一提工作流：这类批量场景里，我最近在用一个叫「影栈」的素材库工具，下载完的素材自动入库、按项目和标签归类，转码脚本直接对着素材库目录跑，"获取—整理—处理"的链路顺畅了不少。

七. 🚀 选型决策：一张决策路径图

把前面所有结论压缩成一条决策路径：

                    ┌─ 接收方设备不可控？ ─→ H.264 + CRF 20-23 + yuv420p
开始转码 ─→ 判断用途 ┤
                    │   ┌─ 自己存档/NAS？ ─→ H.265 + CRF 22-24 + -tag:v hvc1
                    └─ 设备可控 ┤
                            └─ Web 分发/长视频？ ─→ AV1 + CRF 30-34 (+H.264 fallback)
                                        │
                  ┌─────────────────────┴──────────────────────┐
                  ▼                                            ▼
        体积必须卡上限？                              画质必须最佳？
        CRF 逐档试压 → 2-pass 兜底                   preset slow/slower + 10bit

三条容易被反复验证的经验，值得写在便签上贴到显示器边：

1. 编码器选择看接收端，参数选择看用途。这两件事经常被人混为一谈。
2. CRF 是相对刻度，跨编码器比较时先校准基准（x264:20 ≈ x265:24 ≈ AV1:30 左右）。
3. 省体积优先级：换编码器 > 降 CRF > 降分辨率 > 降帧率。降分辨率对观感的伤害往往大于前两者，永远放在最后考虑。

补充一个团队协作视角：如果转码是给剪辑流程服务的（比如把各平台下载的高码率素材统一转成代理文件 Proxy 给时间线用），那选型逻辑会完全反过来——代理文件追求的不是体积小，而是解码快、剪辑流畅，这时 H.264 + 高 preset（faster/veryfast）+ 低分辨率才是正解，转完直接喂给剪辑软件。同一个 ffmpeg，在"交付"和"剪辑"两个语境里的最优参数几乎相反，这是很多教程没讲透、而实战里天天踩的坑。

八. 📝 总结

回到开头那个凌晨：客户要 200MB，你手上的武器已经齐了——判断素材用途、选对编码器、CRF 试压、2-pass 兜底、批量脚本挂机跑完。三代编码器没有绝对赢家，H.264 赢在"全世界都能放"，H.265 赢在"一半体积存 4K"，AV1 赢在"免版税的 Web 未来"，你的任务只是在正确的场景里调用它们。

最后说点技术之外的话。我之所以愿意花这么多时间抠 CRF 的两档数值、写脚本把转码时间从三小时压到四十分钟，是因为创作这件事本身已经够难了——好的想法不该被一个 2.4GB 的文件拖住后腿。工具和参数的意义，就是让技术环节尽量隐形，把省下来的时间和心力，还给内容本身。愿你的每一次导出，都不用等到凌晨一点十四分。

💡 本文涉及的平台素材下载与处理，均指个人学习用途，请遵守各平台版权规则。

参考文献

[1] FFmpeg Documentation. FFmpeg Project. https://ffmpeg.org/documentation.html

[2] FFmpeg Wiki: H.264 Encoding Guide. https://trac.ffmpeg.org/wiki/Encode/H.264

[3] FFmpeg Wiki: HEVC / H.265 Encoding Guide. https://trac.ffmpeg.org/wiki/Encode/H.265

[4] FFmpeg Wiki: AV1 Encoding Guide (libaom / SVT-AV1). https://trac.ffmpeg.org/wiki/Encode/AV1

[5] ITU-T Rec. H.264: Advanced video coding for generic audiovisual services. https://www.itu.int/rec/T-REC-H.264

[6] ITU-T Rec. H.265: High efficiency video coding. https://www.itu.int/rec/T-REC-H.265

[7] AOMedia. AV1 Bitstream & Decoding Process Specification. https://aomedia.org/av1-specification/

[8] SVT-AV1: Scalable Video Technology for AV1, Open Source Project. https://gitlab.com/AOMediaCodec/SVT-AV1

[9] x264, a free H.264 encoder. https://www.videolan.org/developers/x264.html

[10] MDN Web Docs: Video codec guide. https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs