简介针对FFmpeg HEVCH.265编解码实现的一份示例源码资源面向有音视频开发基础、希望快速上手H.265编解码的开发者。资源将解封装、解码、编码、AVPacket处理与输出等步骤拆解在一个C源文件中围绕libavcodec、libavformat等库阐述关键API的调用顺序可帮助读者理解HEVC相对H.264在压缩效率上的提升并掌握基于FFmpeg搭建H.265编解码流程的具体方法。资源包共1个文件为单个C源文件压缩包仅6KB体量精简便于直接阅读和对照修改。目前已有9966人学习下载。文件中通过注释与代码结构展示了 avformat_open_input()、avcodec_find_decoder()、avcodec_open2()、av_interleaved_write_frame() 等核心函数的使用方式覆盖了从读取输入流、分离音视频流、解码HEVC数据到重新编码并写入输出文件的完整链路。对于正在开发高清视频处理工具、需要优化带宽占用或构建自定义转码流程的开发者而言这份示例能提供清晰的参考框架和排错思路。 前阵子帮朋友把一批监控录像从 h264 转成 h265压完几百个文件硬盘直接腾出一半空间。当时就觉得FFmpeg 处理 h265 编解码这事儿真应该好好写一篇实操记录。网上讲 FFmpeg 的文章不少但大多要么是命令大全要么是纯原理真正能把编码参数、解码兼容性、常见坑串成一条完整实例链路的并不多。这篇我就从自己的实际使用经验出发把 h265 编解码的完整流程拆开讲透包括为什么要换 h265、编码命令怎么写、硬件加速怎么开、解码播放有哪些坑以及几个高频复合场景的实战命令适合刚接触 FFmpeg 的开发者也给已经用了一段时间但想提高编码质量的朋友一些参考。1. 为什么选择 h265一次编码带来的收益到底有多大先说个最直观的对比。同样是 1080p、30fps 的视频用 h264 编码码率一般得给到 8Mbps 到 12Mbps 画质才算够看换成 h265也叫 HEVC4Mbps 到 6Mbps 就能达到相近的观感。也就是说同样的画质h265 大约能节省 40% 到 50% 的码率。这个数字放到长时间录像、视频素材库、线上传输场景里省下来的就是实打实的存储成本和带宽成本。1.1 h265 的核心优势与适用场景h265 之所以能在同等画质下用更低的码率核心在于它引入了更灵活的编码单元划分方式。h264 的宏块大小固定是 16x16而 h265 的编码树单元可以从 64x64 一路划分到 8x8这样平坦区域用大块编码、细节区域用小块编码分配码率的方式就比 h264 精细得多。再加上更丰富的帧内预测模式和运动补偿精度压缩效率自然就上来了。不过压缩效率的提升不是没有代价的。h265 的编码复杂度比 h264 高不少特别是用软件编码器 x265 的时候同样的时长编码耗时可能是 h264 的三到四倍。所以什么时候用 h265需要结合场景来判断视频存储归档比如监控录像、直播录制、课程视频存档这类场景是一次编码、多次读取压缩率是王道h265 非常合适。网络传输带宽有限但画质要求高的场景比如视频会议、流媒体点播h265 能明显降低码率压力。短视频二次剪辑如果素材是 h265剪辑软件支持的话可以直接用但导出时如果目标平台兼容性一般建议转 h264。老设备播放这个要特别注意很多旧手机、旧电视盒子不支持 h265 硬解强行用 h265 可能导致播放卡顿甚至黑屏。1.2 软编码与硬编码的选型逻辑做 h265 编码时第一个要做的决定就是用软件编码器还是硬件编码器。软件编码器以 x265 为代表质量高、参数细、兼容性好但吃 CPU硬件编码器以 NVENCNVIDIA、Quick Sync VideoIntel、AMFAMD为代表速度快、几乎不占 CPU但画质在同码率下通常比 x265 略差参数调节空间也小。简单打个比方软件编码像是手工精修能控制每个细节但费时间硬件编码像是流水线批量生产快而省力但每个产品都差不多一个模子。具体到 h265 场景我的建议是离线批量转码、对画质有极致要求用 libx265实时推流、录屏、在线转码服务用硬件编码器。另外还要看设备支持情况比如有朋友问“gtx750 支持 h265 吗”这里明确说一下GTX 750 这个年代的显卡Maxwell 第一代虽然支持 h265 硬解但不支持完整的 h265 硬件编码用它硬编 h265 是不行的。这就是选型时必须先确认硬件能力的原因。2. 环境准备FFmpeg 安装与编解码器验证做 h265 编解码之前首先得确认你机器上的 FFmpeg 版本和编译选项支持 h265。很多朋友遇到的“找不到编码器”问题根本原因就是用的 FFmpeg 是精简版没有编译进 x265 或者硬件编码器。2.1 各平台安装 FFmpeg 的方法不同系统安装 FFmpeg 的方式差别比较大我把自己常用的几套方案整理一下Ubuntu / Debiansudo apt update sudo apt install ffmpeg装完一般是 4.x 或 5.x 版本基础功能够用。想要新版可以加 Jonathon F 的 PPA或者直接下载静态编译版。CentOS / AlmaLinux / Rocky Linux这类系统默认源里的 FFmpeg 版本比较老而且可能没有 x265。建议先装 EPEL 和 RPM Fusion 源再执行sudo dnf install ffmpeg。有朋友问“almalinux 安装 ffmpeg libx264”其实 h264 编码器默认就带重点是确认 x265 是否可用方法下面会说。macOSbrew install ffmpeg但默认编译不一定开启 x265可以加参数brew install ffmpeg --with-x265新版 brew 里这种参数可能已经简化直接装通常会带。Windows建议直接到 ffmpeg.org 下载官方编译的 release build或者用 BtbN 的 GitHub 自动构建版本解压后把 bin 目录加到 PATH 就行。注意区分 full 版和 essentials 版选 full 版包含的编码器更全。2.2 验证 FFmpeg 是否支持 h265安装完成后第一步不是急着执行编码命令而是先检查当前 FFmpeg 有没有 h265 的编解码能力。用这几条命令# 查看支持的编码器重点找 libx265、hevc_nvenc、hevc_qsv、hevc_amf ffmpeg -encoders | grep 265 # 查看支持的解码器重点找 hevc ffmpeg -decoders | grep 265如果编码器列表里有 libx265说明软件编码没问题有 hevc_nvenc 说明 NVIDIA 硬编可用有 hevc_qsv 说明 Intel 核显硬编可用。一个都没有的话就要考虑换 FFmpeg 版本或者重新编译了。顺便提一句以前我在 Windows 上遇到过一种情况ffmpeg -version能正常输出但编码时却报Unknown encoder libx265。查了半天发现是 PATH 里同时存在两个 FFmpeg一个是系统里的旧版一个是新解压的命令执行优先用了旧版。所以验证环境这一步看起来简单但真能省掉后面一大半的折腾时间。3. h265 编码实操从最简命令到参数调优环境就绪后正式开始编码。这一部分我从最基础的命令讲起逐步加入画质控制、预设调节、硬件加速等内容每个参数都会解释它到底在干什么方便你根据自己的需求调整。3.1 最基础的 h265 编码命令把输入文件转成 h265 的最简命令是ffmpeg -i input.mp4 -c:v libx265 -c:a copy output.mp4这条命令做了什么-c:v libx265指定视频用 x265 编码器-c:a copy表示音频流不重新编码直接复制。执行之后视频轨会被压成 h265音频保持原格式封装容器还是 MP4。但实际使用中这条裸命令很少直接用。因为 x265 默认的码率控制方式是固定量化参数如果画质要求高但不希望文件太大或者反过来有明确的体积目标都需要显式指定参数。否则很容易出现“压出来的视频比预期大很多”或者“画质肉眼可见地变差”这两种极端情况。3.2 CRF 与 preset画质和编码速度的平衡x265 最常用的码率控制方式是 CRFConstant Rate Factor也就是恒定质量因子。CRF 的取值在 0 到 51 之间数值越小画质越好、文件越大一般 h265 建议取值 23 到 28默认值是 28。实践下来我的经验是CRF 23视觉上几乎无损适合存档和高画质要求场景CRF 26画质与体积比较均衡日常压制推荐CRF 28默认值体积控制得好但复杂场景会出现轻微细节丢失CRF 30 以上不推荐除非对体积有极端要求完整命令长这样ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset medium -c:a copy output.mp4这里的-preset参数控制 x265 的编码速度档位从快到慢依次是ultrafast、superfast、veryfast、faster、fast、medium、slow、slower、veryslow。预设越慢编码器会尝试更多种划分方式和预测模式画质越好、文件越小但耗时成倍增加。一个常见的误区是认为 preset 越慢画质一定越好。其实在相同 CRF 下慢预设的主要收益是“同样体积下画质略好”而不是肉眼可见的质变。日常用 medium 到 slow 已经足够veryslow 对于大多数场景来说纯属浪费时间。我自己压片子1080p 的一般用 slow4K 素材用 medium再慢的生产效率就太低了。3.3 硬件编码加速NVENC、QSV 与 VPU如果你的机器有支持 h265 硬编的显卡或核显强烈建议在实时性要求高的场景用硬件编码器。NVIDIA 的命令是ffmpeg -i input.mp4 -c:v hevc_nvenc -preset p5 -cq 26 -c:a copy output.mp4这里的-preset p5是 NVENC 自己的预设档位从 p1最快到 p7最慢数值越大质量越好但速度越慢平衡点一般选 p4 到 p6。-cq是 NVENC 的恒定质量参数作用和 CRF 类似取值范围 0 到 51一般 24 到 28 之间。Intel 核显的命令是ffmpeg -i input.mp4 -c:v hevc_qsv -global_quality 26 -c:a copy output.mp4AMD 平台的命令类似用hevc_amf编码器参数是-qp_i、-qp_p之类不同显卡驱动版本差异较大需要查对应文档。至于有些嵌入式设备或者开发板上提到的 VPU 编解码其实就是硬件视频处理单元FFmpeg 通过特定的 API 调用 VPU 能力比如 Rockchip 平台的h264_rkmpp、hevc_rkmpp编码器。这类编码器的重点不在调参而在确认 FFmpeg 编译时是否带上了对应的 mpp 模块以及设备的驱动版本是否正确。3.4 几个值得记住的附加参数除了 CRF 和 preset实际编码时还有几个参数我几乎每次都会用到它们解决的是实用性问题和兼容性问题ffmpeg -i input.mp4 -c:v libx265 -crf 26 -preset medium -tag:v hvc1 -movflags faststart -c:a copy output.mp4-tag:v hvc1是很多人容易忽略的一个参数。MP4 容器里的 h265 视频流codec tag 有两种写法hvc1和hev1。hev1是 FFmpeg 默认写入的但不少播放器尤其苹果生态里的 QuickTime、Final Cut只认hvc1。不写这个参数在 Mac 上可能出现视频打不开的情况。-movflags faststart会把 moov 元数据移到文件头部这样视频边下载边播时不需要等整个文件加载完对 Web 播放场景尤其友好。4. h265 解码与播放的注意点编码只做了一半解码和播放才是用户真正接触的部分。h265 的解码在 FFmpeg 里很简单一条命令就能完成但解码之外的兼容性问题才是实际项目里最花时间的地方。4.1 用 FFmpeg 解码 h265 的基本操作如果你有一个 h265 编码的视频想转成 h264 方便兼容性不好的设备播放命令是ffmpeg -i input_hevc.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac output_h264.mp4这里视频轨被重新编码成 h264音频转成 aac。注意-c:v libx264后面的-crf 23是新编码的目标质量不是解码参数。解码是自动完成的FFmpeg 检测到输入流是 hevc 时会自动选择内置的 hevc 解码器不需要你手动指定。对绝大多数场景FFmpeg 的软件解码器hevc足够用CPU 占用虽然偏高但胜在兼容性最强。如果只是想抽取 h265 视频流不重新编码比如从 MP4 里把 h265 裸流提出来存成.h265文件ffmpeg -i input.mp4 -c:v copy -an output.h265这种操作常用于后续做流媒体切片测试或者喂给其他处理工具用。4.2 浏览器与播放器兼容性排查h265 播放兼容性的大坑主要在浏览器端。Chrome 浏览器对 h265 的支持一直很暧昧它本身不内置 h265 解码器是否播放成功取决于操作系统和显卡能不能提供硬件解码能力。比如在 Windows 10/11 上如果显卡支持 h265 硬解Chrome 可以通过系统解码器播放如果显卡太老或者驱动不对视频就会黑屏或提示无法播放。“谷歌浏览器设置播放 h265 编码”这个问题实际操作起来有几条路一是确保系统级解码器可用二是打开 Chrome 的硬件加速功能三是检查 chrome://flags 里是否有相关开关。但不同版本 Chrome 的界面差异很大这问题没有一个通吃的答案最稳妥的方案还是尽量避开Web 端视频要么用 h264要么用支持情况更好的 AV1或者用 DASH/HLS 流媒体方案让播放器自己选择兼容的码流。有个例外情况是苹果 SafariSafari 对 h265 的支持一直比较积极只要系统版本够新基本能直接播放 hvc1 标签的 h265 视频。所以你会发现一个行业现象同样的视频文件在 iPhone 上能播在 Windows 的 Chrome 上就播不了这跟文件本身没问题纯粹是生态差异。5. 高频场景实战m4s 转 mp4、精确裁剪与视音频处理掌握了基础编解码命令之后日常工作中还会遇到不少和 h265 相关的复合场景。这里挑几个搜索热度高、我自己也经常用的命令做一次完整演示。5.1 m4s 转 mp4B 站缓存的世纪难题网上很多人问“ffmpeg 怎么把 m4s 转换成 mp4”这个问题的来源是 B 站客户端下载的缓存视频音视频分离存储成.m4s文件直接用播放器打不开。处理思路是先把视频 m4s 和音频 m4s 合并再封装成 mp4ffmpeg -i video.m4s -i audio.m4s -c copy output.mp4-c copy意味着不需要重新编码视频和音频流直接复制进新的容器速度快且不损画质。B 站缓存的 m4s 视频有的是 h264 有的是 h265但不管哪种这条命令都能处理因为核心是“换容器”而不是“换编码”。如果合并后播放没声音多半是音频-c copy到 mp4 时格式不兼容可以改成-c:a aac重新编码音频。5.2 命令行精准裁掉片尾“ffmpeg 命令行精准裁掉片尾”这类需求常见于录屏和电视剧剪辑。核心逻辑就是指定要保留的时长用 copy 模式避免二次编码# 保留前 1 小时 23 分 45 秒视频音频直接从原始流复制 ffmpeg -i input.mp4 -t 01:23:45 -c copy output.mp4-t后面的时间可以写成HH:MM:SS格式也可以写成秒数比如-t 5025。这里有个容易踩的坑用-c copy裁剪时剪辑点必须落在关键帧GOP 的 I 帧上否则播放时开头会出现几秒黑屏或花屏。这是因为拷贝模式下 FFmpeg 不会重新生成关键帧而是直接从最近的一个关键帧开始保留画面。想精准到秒级就得重新编码ffmpeg -i input.mp4 -t 01:23:45 -c:v libx265 -crf 26 -c:a copy output.mp4代价是编码时间变长但换来的裁剪精度是帧级的。5.3 修复破损的 avi 文件与常见容器问题“ffmpeg 如何修复破损的 avi 文件”也是一个高频搜索词。这类文件的典型表现是用播放器打开卡在某一帧拖进度条黑屏或者干脆无法打开。优先尝试无损修复方式# 忽略错误把能读出来的数据尽量拷贝出来 ffmpeg -err_detect ignore_err -i broken.avi -c copy recovered.avi如果拷贝出来的文件还是问题多多就只能重新编码典型做法是先转成 h264 或 h265顺便修复了时间戳和索引问题ffmpeg -err_detect ignore_err -i broken.avi -c:v libx265 -crf 26 -c:a aac recovered.mp4重新编码时 FFmpeg 会重新生成完整的索引和时间戳多数损坏文件经过这一步都能救回来。但要注意如果原文件的视频流数据本身已经损坏严重编码依然会花屏那是物理损坏什么工具都无力回天。5.4 录屏、提升清晰度等相关操作Linux 下用 FFmpeg 录屏核心是用 x11grab 设备ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -f pulse -i default -c:v libx265 -crf 28 -c:a aac output.mkvWindows 下则是用 gdigrabffmpeg -f gdigrab -framerate 30 -video_size 1920x1080 -i desktop -c:v libx265 -crf 28 -c:a aac output.mkv录屏选择 h265 是个好思路因为录制时长通常较长h265 的高压缩比能让文件体积明显减小且录屏画面相对静态h265 的压缩率优势更容易发挥出来。至于“ffmpeg 提高视频清晰度”先说个扎心的事实FFmpeg 不能无中生有原视频的分辨率和码率决定了画质上限。我们能做的是在不增加严重副作用的前提下优化观感典型命令是加滤镜做适度锐化ffmpeg -i input.mp4 -vf unsharp5:5:0.8:3:3:0.4 -c:v libx265 -crf 24 -preset slow output.mp4unsharp滤镜第一个参数组控制亮度的锐化量5:5:0.8 是半径和强度第二个参数组是色度通道的锐化。适度锐化能让画面显得更清晰但调过头会产生白边和噪点影响观感。另外可以用scale滤镜配合高画质缩放算法把 720p 放大到 1080p比如-vf scale1920:1080:flagslanczos但放大后的清晰度提升更多是心理层面的实际细节并不会增加。6. 常见问题与排查技巧实录这部分把我在实际操作中遇到的问题整理成一个问题速查表很多是自己踩过坑才总结出来的网上不一定能找到现成答案。问题现象可能原因解决办法报错 Unknown encoder libx265FFmpeg 编译时未包含 x265安装完整版 FFmpeg 或自己编译Windows 下注意 PATH 里是否混入了旧版本编码速度极慢CPU 满载使用了较慢的 preset 或 4K 素材换 medium/fast 预设或改用 NVENC/QSV 硬件编码压出来的 h265 在手机/苹果电脑上打不开codec tag 是 hev1 而不是 hvc1加参数-tag:v hvc1网页播放 h265 视频黑屏浏览器/系统不支持 h265 硬解换 h264/AV1 编码或确保显卡和系统解码器支持 h265用 copy 模式裁剪后播放开头花屏裁剪点不在关键帧上用重新编码方式裁剪或用-ss配合-c copy但接受关键帧对齐的误差硬件编码 hevc_nvenc 报错显卡不支持 h265 硬编如 GTX 750确认显卡型号NVIDIA 从 Maxwell 第二代开始才完整支持 h265 硬编转换后视频没有声音音频流格式与容器不兼容音频改为-c:a aac重新编码录屏文件非常大用了无损或低 CRF 值录屏建议 CRF 28 以上画面静态区域多可以大胆提高 CRF播放时音画不同步原文件时间戳异常先重新封装-c copy修复时间戳不行再重新编码CLion 里调用 FFmpeg API 报找不到头文件项目没配置好 FFmpeg 头文件和链接库在 CMake 里用 pkg-config 找到 ffmpeg 的 include 和 lib 路径链接avcodec、avformat等库排查这类问题时有个方法论层面的建议先确认输入文件本身是否正常再看 FFmpeg 版本和编译选项最后才怀疑命令写法。很多莫名其妙的报错换个 FFmpeg 版本就解决了。所以我通常会在机器上多备一个静态编译版 FFmpeg出问题时快速切换对比能省很多排查时间。另外h265 编码后文件能否顺利播放硬件解码能力是非常关键的一环。如果你要给客户或朋友交付 h265 视频务必确认对方设备支持硬解尤其是几年前的电视盒子、车载播放器、老旧笔记本这类设备对 h265 的支持普遍不乐观。遇到这种情况要么提前交付 h264 版本要么干脆做多码率版本让播放端自己选。最后再分享一个小技巧批量转码时先用一小段素材测试参数比如截取视频前 30 秒ffmpeg -i input.mp4 -t 30 -c:v libx265 -crf 26 -preset slow -c:a copy test.mp4看测试输出的画质和文件大小再决定要不要全量转码。这个习惯看起来没什么技术含量但真的能帮你避免拿几百个文件试错之后发现参数不合适的惨剧。本文还有配套的精品资源点击获取