简介：这是一份面向音视频开发者的FFmpeg HEVC编解码实战示例，聚焦H.265这一高效节省带宽的高清视频编码标准，适合已具备一定C语言与多媒体基础、希望深入理解FFmpeg编解码流程的中高级开发者参考。压缩包内共1个文件，为单个C源码文件，整体约6KB，体量轻巧却覆盖完整链路。代码围绕解复用、解码、编码、AVPacket处理与输出五个关键环节展开，涉及avformat_open_input、avcodec_find_decoder、avcodec_encode_video2、av_interleaved_write_frame等核心接口，并演示编码器上下文创建、参数设置与流写入的配合方式。通过研读可掌握FFmpeg处理HEVC视频的典型调用顺序与数据流转思路，理解libx265编解码器在工程中的接入方法，为多媒体应用开发与高清视频处理打下实践基础。目前已有9982人学习下载，具备较高的参考热度。
1. 从一次转码翻车说起：H.265 编解码到底能解决什么问题
去年帮一个做安防监控的朋友处理一批录像，4 路 1080P 存了 30 天，硬盘直接爆了。他一开始想加硬盘，我让他先别急，把其中一段用 H.265 重新压了一遍——同样的画质肉眼几乎看不出差别，体积直接砍到原来的六成左右。这就是 H.265（也叫 HEVC）最直接的诱惑：在同等主观画质下，码率大约能比 H.264 省 40% 到 50%。代价是编码复杂度上去了，算力吃得更多，兼容性也更挑环境。
这份资源就是围绕「用 FFmpeg 做 H.265 编解码」这件事展开的实例集合，核心工具链是 FFmpeg 命令行 + libx265 编码器。它适合两类人：一类是手里有大量高清视频、想批量压体积的运维或后端同学；另一类是想把 H.265 编解码嵌进自己服务里、需要先摸清参数和流程的开发者。下面我按「先跑通、再拆结构、最后能改」的顺序，把这份实例从头到尾过一遍。
2. 环境准备与最小可跑实例：先把一条命令跑通
2.1 确认 FFmpeg 是否带 x265
很多人第一步就翻车：装完 FFmpeg 一敲命令，报Unknown encoder 'libx265'。这不是命令写错了，是装的 FFmpeg 编译时没把 x265 编进去。先自检：
# 查看当前 ffmpeg 支持的编码器里有没有 libx265 ffmpeg -encoders | grep 265 # 正常应该能看到类似输出： # V....D libx265 libx265 H.265 / HEVC (codec hevc) # V....D hevc_nvenc NVIDIA NVENC hevc encoder如果libx265那行不存在，说明这个二进制是精简版。常见做法是换一个完整编译的版本，或者自己带--enable-libx265重新编译。Windows 上我一般直接用带 full 标记的构建包，Linux 上优先走发行版仓库里名字带-extra或完整版的包，实在没有再考虑源码编译。这一步别省，不然后面所有命令都是空谈。
2.2 一条能跑通的转码命令
环境确认后，先拿一个短视频试水，别一上来就压整部片子：
# 把 input.mp4 转成 H.265，CRF 28，preset medium ffmpeg -i input.mp4 \ -c:v libx265 \ -crf 28 \ -preset medium \ -c:a copy \ -tag:v hvc1 \ output_h265.mp4逐段说清楚这几个参数，因为它们决定了你后面所有调优的方向：
-c:v libx265：指定视频编码器为 libx265，这是整条命令的核心，缺了它 FFmpeg 会默认用 H.264。-crf 28：恒定质量模式，数值越小画质越好、体积越大。H.265 的 CRF 一般比 H.264 高 2 到 4 就能达到相近观感，所以 H.264 用 23 的话，H.265 从 26 到 28 起步比较稳。-preset medium：编码速度与压缩率的权衡档位，从 ultrafast 到 placebo 一共十档。medium 是默认值，想快就往 ultrafast 挪，想省体积就往 slow 挪。-c:a copy：音频直接复制，不重新编码，省时间也避免音质二次损失。-tag:v hvc1：这个参数是血泪经验。不加它，某些播放器和苹果设备会把 H.265 视频识别成不兼容格式，画面黑屏只有声音。
跑完之后用ffprobe output_h265.mp4确认一下编码格式，看到Video: hevc就说明成功了。
2.3 解码侧其实不用你操心
很多人以为 H.265 要单独写解码逻辑，其实 FFmpeg 解码是自动的。你直接ffmpeg -i output_h265.mp4 out.mp4它自己就认。真正需要显式指定解码器的情况很少，比如排查某个文件为什么解不开：
# 强制指定 hevc 解码器，用于排查解码问题 ffmpeg -c:v hevc -i output_h265.mp4 -f null --f null -表示不输出文件，只走一遍解码流程，用来验证文件本身能不能被正常解开。这个技巧在批量处理前做预检特别有用，能提前把坏文件挑出来，不至于跑到一半整个脚本崩掉。
3. 核心参数拆解：CRF、preset 和码率控制怎么选
3.1 三种码率控制模式的区别
H.265 编码在 FFmpeg 里主要有三种码率控制方式，选错了要么体积失控要么画质崩：
| 模式 | 参数 | 适用场景 | 特点 |
|---|---|---|---|
| 恒定质量 | -crf | 本地存档、点播 | 画质稳定，体积不可预测 |
| 平均码率 | -b:v | 直播、带宽受限 | 体积可控，画质波动 |
| 两遍编码 | -b:v+-pass | 对体积有硬要求 | 压缩率最高，耗时翻倍 |
我一般默认用 CRF，因为大部分场景下体积不是硬约束，画质稳定更重要。只有做流媒体分发、必须卡住码率上限时，才会切到-b:v配合-maxrate和-bufsize。
3.2 CRF 取值到底怎么定
CRF 是新手最容易纠结的参数。给一个我实际用下来的对照：
# 高质量存档，适合母带备份 ffmpeg -i input.mp4 -c:v libx265 -crf 20 -preset slow -c:a copy archive.mp4 # 通用分发，画质和体积平衡 ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset medium -c:a copy web.mp4 # 监控/预览，体积优先 ffmpeg -i input.mp4 -c:v libx265 -crf 32 -preset fast -c:a copy preview.mp4CRF 每加 6，码率大约减半，这是经验规律。但注意 CRF 不是线性的，20 到 26 之间的画质差异，在普通显示器上未必看得出来，但体积能差一倍。所以别盲目追低 CRF，先明确你的播放场景。
3.3 preset 对速度的影响比你想的大
preset 从 ultrafast 到 placebo，编码速度能差几十倍，压缩率差距其实只有百分之十几。我做过一组对比，同一个 1080P 片段：
# 测速对比，实际项目里按需选 time ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset ultrafast -an /dev/null time ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset medium -an /dev/null time ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset slow -an /dev/null-an是禁用音频，纯测视频编码速度。实测下来 medium 通常是 ultrafast 的三到五倍耗时，slow 又是 medium 的两三倍，但体积只小一成左右。所以除非是离线批处理、时间不值钱，否则 medium 到 slow 之间就够了，placebo 基本是玄学，不推荐。
提示：批量转码时先用
-t 30截取前 30 秒试跑，确认参数和体积符合预期再全量跑，能省下大量返工时间。
4. 批量转码与工程化封装：从单条命令到可复用脚本
4.1 用 shell 做批量处理
单条命令跑通后，真实场景往往是几百个文件。直接写个循环：
#!/bin/bash # 批量把当前目录下的 mp4 转成 H.265 mkdir -p output for f in *.mp4; do # 跳过已经是 hevc 的文件，避免重复编码 codec=$(ffprobe -v error -select_streams v:0 \ -show_entries stream=codec_name -of csv=p=0 "$f") if [ "$codec" = "hevc" ]; then echo "跳过已编码文件: $f" continue fi echo "正在处理: $f" ffmpeg -i "$f" \ -c:v libx265 -crf 26 -preset medium \ -c:a copy -tag:v hvc1 \ "output/${f%.mp4}_h265.mp4" \ -y -loglevel error done这段脚本有两个关键点：一是用ffprobe先探测编码格式，避免对已经是 H.265 的文件重复编码，白白浪费时间；二是-loglevel error把日志压到只输出错误，批量跑的时候屏幕不会被刷屏。${f%.mp4}是 shell 的字符串截断，去掉原扩展名再拼新名字。
4.2 用 Python 做更可控的封装
shell 适合简单场景，但要做并发、错误重试、进度统计，Python 更顺手：
import subprocess import os from concurrent.futures import ThreadPoolExecutor def transcode(src, dst, crf=26, preset="medium"): """单个文件转码，返回是否成功""" cmd = [ "ffmpeg", "-i", src, "-c:v", "libx265", "-crf", str(crf), "-preset", preset, "-c:a", "copy", "-tag:v", "hvc1", "-y", "-loglevel", "error", dst ] # capture_output 捕获错误信息，便于失败时定位 result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print(f"失败 {src}: {result.stderr[:200]}") return False return True def batch(files, out_dir, workers=2): os.makedirs(out_dir, exist_ok=True) tasks = [] with ThreadPoolExecutor(max_workers=workers) as pool: for f in files: name = os.path.splitext(os.path.basename(f))[0] dst = os.path.join(out_dir, f"{name}_h265.mp4") tasks.append(pool.submit(transcode, f, dst)) return sum(t.result() for t in tasks)这里workers别设太大，x265 本身就会吃满多核，开太多并发反而互相抢 CPU，整体更慢。一般按物理核心数除以 2 来设比较稳。capture_output=True是为了拿到 stderr，失败时能打印前 200 个字符快速定位问题，不然批量跑完你根本不知道哪个文件为什么挂。
4.3 硬件加速要不要上
如果机器有 NVIDIA 显卡，可以用hevc_nvenc走硬件编码，速度能快十倍以上，但同码率下画质不如 libx265：
# 硬件编码，适合对速度要求高、画质要求不极致的场景 ffmpeg -i input.mp4 \ -c:v hevc_nvenc \ -preset p4 \ -cq 28 \ -c:a copy \ output_nvenc.mp4注意硬件编码的参数名不一样，-cq对应软件编码的-crf，-preset的取值也是 p1 到 p7 而不是那十个英文档位。我的建议是：离线存档用 libx265 慢慢压，实时转码或预览用硬件编码抢时间，两者别混用同一套参数。
5. 避坑与常见问题排查
5.1 转出来的文件播放器打不开
现象：文件能生成，但某些播放器黑屏或提示格式不支持。原因多半是封装标签问题，H.265 在 MP4 容器里需要hvc1标签，而 FFmpeg 默认可能写成hev1。解决：命令里加-tag:v hvc1，已经转好的文件可以用ffmpeg -i bad.mp4 -c copy -tag:v hvc1 fixed.mp4无损修复，不用重新编码。
5.2 编码速度慢到无法接受
现象：一个十分钟的视频跑了半小时还没完。原因通常是 preset 选太慢，或者 CRF 太低导致码率飙升。解决：先把 preset 调到 fast 或 medium 试跑，确认速度可接受再逐步往慢调；同时检查是不是误用了 placebo。另外确认 FFmpeg 是不是只用了单核，正常 x265 会自动多线程，如果 CPU 占用只有一核，可能是编译版本的问题。
5.3 体积反而比原文件大
现象：转完发现 H.265 文件比 H.264 原文件还大。原因一般是原文件码率本来就很低，或者 CRF 设得太小。H.265 的优势在高码率场景才明显，一个已经压得很狠的低码率文件，再转 H.265 只会因为重新编码引入额外开销而变大。解决：转码前先用ffprobe看原文件码率，如果已经低于 1Mbps（1080P），就别折腾了，收益为负。
5.4 音频不同步或丢失
现象：转完视频画面正常但没声音，或者音画对不上。原因通常是-c:a copy遇到 FFmpeg 不支持的音频编码，或者源文件本身有时间戳问题。解决：先ffprobe看音频编码，如果是冷门格式就改成-c:a aac -b:a 128k重新编码；时间戳问题可以加-fflags +genpts让 FFmpeg 重新生成时间戳。
5.5 批量脚本跑到一半中断
现象：处理到某个文件时脚本报错退出，后面的全没跑。原因多半是某个文件损坏或格式异常，导致 ffmpeg 返回非零退出码，而脚本没做容错。解决：在循环里判断返回码，失败就记录到日志并continue，别让单个坏文件拖垮整批任务。上面 Python 版本里的returncode判断就是干这个的。
6. 二次开发改造：把编解码能力嵌进自己的服务
如果你不是单纯压片，而是要把 H.265 编解码做成服务的一部分，有几个改造方向值得先想清楚。
第一个是参数配置化。别把 CRF、preset 写死在代码里，抽成配置项，按业务场景分档。我一般会定义三档 profile：archive（CRF 20 / slow）、web（CRF 26 / medium）、preview（CRF 32 / fast），调用方传个档位名就行，避免每个业务方都来问参数怎么填。
第二个是任务队列化。转码是重 CPU 操作，直接同步调用会把请求线程堵死。常见做法是丢进消息队列，用独立的 worker 进程消费，前端只拿任务 ID 轮询进度。进度可以从 ffmpeg 的 stderr 里解析frame=那行拿到，配合总帧数算百分比。
第三个是失败重试与降级。硬件编码失败时自动降级到软件编码，软件编码超时则降低 preset 重试一次。这套逻辑用 Python 装饰器包一层很清爽：
def with_fallback(func): """编码失败时降级重试的装饰器""" def wrapper(src, dst, **kwargs): try: return func(src, dst, preset="medium", **kwargs) except RuntimeError: # 降级到更快的 preset 再试一次 print(f"降级重试: {src}") return func(src, dst, preset="fast", **kwargs) return wrapper第四个是验证环节。转码完成后别直接删源文件，先跑一遍ffmpeg -v error -i dst -f null -确认输出文件能完整解码，再标记任务成功。这个习惯救过我一次——有批文件因为磁盘写满导致尾部截断，ffmpeg 返回码却是 0，只有解码验证才能发现。
改造时最容易忽略的是并发控制。x265 默认吃满所有核心，如果你同时跑多个转码任务，每个任务都以为自己独占 CPU，结果就是互相拖慢、整体吞吐反而下降。我的做法是给 worker 池设一个上限，并且给每个 ffmpeg 进程加-threads限制，让并发数和线程数乘起来不超过物理核心数。
从那以后我每次上线转码服务前，都强制先用一批样本文件跑一遍全流程验证，确认体积、画质、耗时三个指标都在预期内才放量。这套流程看着笨，但比线上出问题再回滚省心得多。希望帮到你。
本文还有配套的精品资源，点击获取
