★ FEATURED ARTICLE 1. 为什么非要自己编译一份FFmpeg如果你只是想推 H.264 的 RTMP 流Ubuntu 18.04 上通过 apt 直接安装的 FFmpeg 完全够用系统源里那个 3.4 版本虽然老但推流 H.264 一点问题没有。可需求一旦变成“把 H.265 画面推成 RTMP”自带版本立刻翻脸报错非常直接[flv 0x...] Could not find tag for codec hevc in stream #0, codec not currently supported in container这句话翻译过来就是FLV 封装器muxer的编码格式表里根本没有 HEVC 这个条目它不知道该怎么把 H.265 的数据包塞进 FLV/RTMP 的流里。这不是你的参数写错了也不是 FFmpeg 不认识 H.265而是 RTMP 的老协议规范在设计时只认 H.264、VP6 那一批老编码格式。要解决这个问题本质上就两条路要么换用新版 FFmpeg 内建的增强 RTMP 能力要么自己改源码、让 FLV 封装器支持 HEVC。目前生产环境里大量摄像头方案、直播服务端和自研播放器沿用的还是“HEVC codec id 12”这套老约定所以自己编译一份打过补丁的 FFmpeg反而是最通用、最好控制的做法。这篇文章就完整记录我在 Ubuntu 18.04 下从零编译、打补丁、推流验证的全过程所有步骤都按可复现的粒度写清楚了。1.1 系统自带FFmpeg到底缺了什么Ubuntu 18.04 的 apt 源里的 FFmpeg默认没有开启 libx265 编码器也没有完整的 RTMP 推流能力。更重要的是它作为一份“原版”代码遵循的是 RTMP/FLV 的原始规范而原始规范里没有 H.265 的位置。所以哪怕你手动装了 libx265-dev系统自带那份 FFmpeg 也不会让你把 H.265 数据封装进 FLV 容器里。有人可能想用-c:v libx265去推结果发现命令刚执行就停在初始化阶段根本到不了编码那一步。这就是因为封装器在avformat_write_header阶段检查编码格式表时发现 HEVC 没有对应的 FLV codec tag于是直接拒绝了输出。搞清楚这个报错出现的时机很重要它不是推流中途才挂而是输出格式初始化时就挂了。另外还要理解一层关系FFmpeg 推 RTMP实际是“flv 封装器”拼出 FLV tag 的字节流然后把字节流交给“rtmp 协议层”发送到服务器。RTMP 协议层本身对视频编码格式并不敏感它只是搬运 FLV 数据块。真正拦路的是 flv 封装器那一层所以补丁的主战场在libavformat/flvenc.c和libavformat/flv.h。1.2 这套补丁方案的来龙去脉FLV 容器里视频 tag 的第一个字节用低 4 位表示视频编码 ID。原规范里H.264 对应 ID 7VP6 对应 ID 4所以你在抓包工具里看到的 H.264 视频 tag 首字节一般是 0x17关键帧或 0x27非关键帧。而 H.265 在原规范里根本没有官方 ID。后来为了在 RTMP 链路里跑 H.265行业内逐步形成了一个事实约定把 codec id 120x0C定义为 HEVC。支持“H.265 RTMP”的流媒体服务器和播放器都是拿着这个 ID 互相认的。服务器看到视频 tag 首字节低 4 位是 12就知道接下来按 H.265 的配置记录格式解析播放器也是靠这个 ID 决定调用哪个解码器。我们要打的补丁本质就是把 FFmpeg 的 FLV 封装器改造成能输出这套格式第一在编码格式表里登记 HEVC 与 codec id 12 的映射关系第二像 H.264 那样在关键帧之前把 H.265 的配置记录HEVCDecoderConfigurationRecord里面包含 VPS、SPS、PPS作为 sequence header 发出去第三把编码器输出的 Annex B 格式 NAL 包转成 FLV 里使用的 length-prefixed 形式。这三件事做完FFmpeg 就能把 H.265 画面推成 RTMP 流了。1.3 谁需要、谁不需要这套方案先泼点冷水。H.265 推 RTMP 不是“推出去谁都能播”的通用能力它需要服务器端和播放端都认这套约定。如果你只是本地录文件、推 H.264、或者播放端完全不受控比如只能用通用桌面播放器那就没必要折腾编译。很多桌面播放器至今只认 RTMP 里的 H.264你推 H.265 过去就是黑屏或花屏这不是你编码参数的问题是播放端压根不认这个格式。反过来如果你在做直播采集、摄像头/NVR 上云、低带宽直播、或者自研播放器那这套方案就非常值。H.265 在同等画质下码率通常比 H.264 省 30% 到 50%同样是 1080p 画面H.264 可能要 4 到 6 MbpsH.265 压到 2.5 到 3.5 Mbps 就能达到差不多的观感。带宽成本下来之后服务器压力、存储成本都会跟着降。下文所有操作都默认你是“自己控制服务端和播放端”的场景。2. 环境准备Ubuntu 18.04 的依赖安装2.1 系统基础工具编译 FFmpeg 第一步是装好编译工具链。Ubuntu 18.04 的默认源里这些东西都有直接 apt 安装即可sudo apt update sudo apt install -y build-essential pkg-config git curl如果你用的 Ubuntu 18.04 已经比较旧apt update 可能会遇到源失效的情况这是老版本镜像下线导致的。解决办法就是把 apt 源切换到当前还能用的镜像源具体切换方式每家公司镜像都有说明这里不展开。装好之后确认一下gcc --version能正常输出别在编译中途才想起编译器没装。这里有一个实际经验不要图省事用 Ubuntu 20.04 或更新系统的 apt 包去凑合。标题既然限定在 18.04就按 18.04 的依赖情况来因为不同系统版本里 x265 库的版本、soname 都不一样混着用药不对症。2.2 汇编器为什么必须装sudo apt install -y yasm nasm这两个汇编器不是可选依赖是硬依赖。FFmpeg 的 x86 平台优化代码、x264、x265 的汇编加速都依赖它们。很多人编译 x264 或 FFmpeg 时卡在nasm not found就是少了这一步。Ubuntu 18.04 源里的 nasm 版本是 2.13.02yasm 是 1.3.0对 FFmpeg 4.4 和 x265 2.6 来说完全够用。值得多提一句的是yasm 和 nasm 的语法体系不同不能互相替代。FFmpeg 内部大量内联汇编用的是 nasm/yasm 两套都能处理的格式但 x264 编译时需要 nasmlibvpx 也需要。所以别偷懒两个都装上一劳永逸。2.3 编解码依赖库清单推流 H.265 到 RTMP音频那边通常还需要 AAC所以除了 x265 之外建议把常用编解码库一次装齐。下面是我实测可用的安装命令sudo apt install -y libx264-dev libx265-dev libvpx-dev libmp3lame-dev libopus-dev sudo apt install -y libfdk-aac-dev如果你执行apt install libfdk-aac-dev提示找不到包说明系统没开 multiverse 软件源。Ubuntu 18.04 的 fdk-aac 在 multiverse 里开一下源再装sudo apt install -y software-properties-common sudo add-apt-repository multiverse sudo apt update sudo apt install -y libfdk-aac-dev这套依赖里libx264 和 libx265 是核心。x264 是为了留一条 H.264 推流的后路万一目标服务器不认 H.265你还能切回去libvpx、libmp3lame、libopus 是音频和 VP8/VP9 编码的补充装上之后 FFmpeg 的可选编码覆盖就比较完整了。libfdk-aac 是目前 FFmpeg 里质量最好的 AAC 编码器但它的许可证和 GPL 不兼容所以后续 configure 需要加--enable-nonfree这一点到配置时再说。2.4 关于libx265版本的一句话提醒Ubuntu 18.04 自带的 libx265-dev 是 2.x 老版本只有 8-bit 编码能力。对直播场景来说8-bit 反而更稳因为推流格式和播放端解码器大多按 8-bit 验证。如果你的项目确实需要 10-bit H.265或者想要新版 x265 的速度优化那建议单独从源码编译一份更新的 x265再把 FFmpeg 的 configure 指向它。本文后面全都基于 apt 版本的 libx265-dev先把链路跑通升级 x265 是后面的事。装完依赖之后可以用dpkg -l | grep -E libx26|libfdk快速核对一下几个关键包是否在位。3. 源码获取与 H.265 补丁的三个关键修改3.1 选择哪个FFmpeg版本我推荐用 4.4.x 分支下文以 4.4.2 为例。这个版本在摄像头、编码器、直播服务商的项目里用得非常多稳定性已经过大量生产验证。5.x、6.x 分支也能改但代码位置有差异网上找到的很多补丁也是按 4.x 写的。另外一个现实问题新版 FFmpeg 主线对增强 RTMP 有了原生支持它用 FourCC比如 “hvc1” 标识 H.265的方式工作这和我们要打的“codec id 12”老补丁格式不是一套。如果你的服务端和播放器是按老格式实现的直接拿新版 FFmpeg 推流双方对不上反而推不进去。所以做生产集成时版本锁定很重要。下载源码wget -c https://ffmpeg.org/releases/ffmpeg-4.4.2.tar.xz tar xf ffmpeg-4.4.2.tar.xz cd ffmpeg-4.4.23.2 补丁第一处flv.h 增加 codec id先打开libavformat/flv.h找到声明 FLV codec id 的枚举位置在里面加一行enum { FLV_CODECID_VP6F 5, FLV_CODECID_H264 7, FLV_CODECID_AAC 10, FLV_CODECID_H265 12, // 新增H.265 over RTMP 的行业通行 ID };注意这个 12 不是 FLV 原规范定义的它是业界为了让 H.265 走 RTMP 而约定出来的扩展值。你熟悉的 H.264 对应 7所以你在网上看到的视频 tag 首字节 0x17、0x27 就是“帧类型 codec id 7”拼出来的。H.265 对应 12首字节就是 0x2C关键帧、0x3C非关键帧这类组合。3.3 补丁第二处flvenc.c 的 codec tag 表接着打开libavformat/flvenc.c找到flv_video_codec_ids[]数组在 H264 那行后面加一行static const AVCodecTag flv_video_codec_ids[] { { AV_CODEC_ID_FLV1, FLV_CODECID_SCREENVIDEO }, { AV_CODEC_ID_VP6, FLV_CODECID_VP6 }, { AV_CODEC_ID_VP6F, FLV_CODECID_VP6 }, { AV_CODEC_ID_H264, FLV_CODECID_H264 }, { AV_CODEC_ID_HEVC, FLV_CODECID_H265 }, // 新增 { AV_CODEC_ID_NONE, 0} };这个数组是 FLV 封装器判断“某种编码能不能装进 FLV”的依据。av_codec_get_tag在写头的时候会查这张表查不到就直接报Could not find tag for codec hevc。加了这行报错自然消失。3.4 补丁第三处写 sequence header这是最关键的一处也是难度最高的一处。H.264 在 FLV 里的封装套路是第一个视频 tag 不携带图像数据而是携带 AVCDecoderConfigurationRecord里面是 SPS、PPS 等解码参数这个 tag 的第二个字节是 0表示“sequence header”。之后每个真正的帧用四字节长度前缀把 NAL 单元串起来。H.265 要照葫芦画瓢把它的 HEVCDecoderConfigurationRecord里面是 VPS、SPS、PPS作为 sequence header 发出去。在flv_write_packet函数里找到 H264 的分支在它后面加一个 HEVC 分支大致逻辑如下} else if (par-codec_id AV_CODEC_ID_HEVC) { if (par-extradata par-extradata_size 0) { avio_w8(pb, 0x2C); // 关键帧 H265 codec id 12 avio_w8(pb, 0); // AVCPacketType: sequence header avio_w24(pb, 0); // CompositionTime 设为 0 avio_write(pb, par-extradata, par-extradata_size); } }但注意光发 extradata 还不够真正的帧数据也要处理。H.264 的现有逻辑里如果编码器给出的包以00 00 00 01开头的 Annex B 起始码flvenc.c 会调用ff_avc_parse_nal_units之类的函数把它转成四字节长度前缀形式。HEVC 分支也要做同样的转换对应的处理函数在h2645_parse相关代码里可以找到启发。很多现成的补丁干脆就是把 H264 分支复制一份把AV_CODEC_ID_H264换成AV_CODEC_ID_HEVC把 avc 配置记录的处理换成 hevc 配置记录的处理再在 codec id 的位置用 12实测就能跑通。这里我强调一句这部分修改因为 FFmpeg 版本不同、x265 版本不同代码细节会有差异不要指望一个 diff 拷遍天下。补丁的核心思想就三点——登记 codec id、发配置记录、转 NAL 长度前缀。弄懂这三点遇到任何版本你都能自己改。3.5 解码端要不要改如果你编译这份 FFmpeg 只是为了推流那改上面三个地方就够了不需要碰解码端。但如果你想用这份 FFmpeg 自己拉流验证、或者做转流转发那libavformat/flvdec.c里也需要对应的 H.265 解析支持否则播放的时候同样会因为不认识 codec id 12 而报错。实操建议是把推流和拉流分开先用支持 H.265 RTMP 的服务端和播放器验证封装格式正确再用这份 FFmpeg 做推流端。不要一上来就指望同一个二进制把拉流播放也全包了那样排错时变量太多。4. configure、编译与安装4.1 configure参数逐项解读打完全部补丁之后开始配置。下面是我在 Ubuntu 18.04 上验证过的一段完整 configure./configure \ --prefix/usr/local \ --enable-gpl \ --enable-nonfree \ --enable-libx264 \ --enable-libx265 \ --enable-libfdk-aac \ --enable-libmp3lame \ --enable-libopus \ --enable-libvpx \ --enable-pthreads几个参数要说明白--enable-gplx264、x265 这些库基于 GPLFFmpeg 要链接它们必须打开这个开关。--enable-nonfreelibfdk-aac 的许可证和 GPL 不兼容必须配合--enable-nonfree才能一起编。如果前面 fdk-aac 没装成功那这里就把--enable-libfdk-aac和--enable-nonfree一起去掉音频用 FFmpeg 自带的原生aac编码器也能用只是质量略逊。--enable-libx265这就是我们这次的主角H.265 编码能力来自它。--enable-libx264保留 H.264 推流能力万一服务器不支持 H.265 还能降级。--enable-pthreads多线程编码x265 本身的多线程能力也需要它。配置完成后注意看输出末尾的 configuration 汇总应该有x265 yes之类的字样。如果没有多半是 pkg-config 找不到 x265 库回头检查 libx265-dev 是否真的装上了。4.2 编译与安装make -j$(nproc)这里有个实际教训-j$(nproc)在核心多的机器上会把内存吃满。FFmpeg 链接阶段很吃内存如果你只有 4G 内存还开 16 核并行很容易 OOM。保守起见内存不够就手动限制make -j4编译完成后sudo make install sudo ldconfigldconfig这步很多人会漏。FFmpeg 默认装到/usr/local/lib如果系统 ldconfig 缓存里没有这个路径运行时就会报error while loading shared libraries: libavcodec.so.58。稳妥的做法是把路径写进 ld 配置echo /usr/local/lib | sudo tee /etc/ld.so.conf.d/ffmpeg.conf sudo ldconfig4.3 验证编译结果装完之后先确认用的是不是刚编译出来的那份which ffmpeg ffmpeg -version | head -n 5如果which ffmpeg显示的还是/usr/bin/ffmpeg说明 shell 的路径缓存或 PATH 顺序有问题先hash -r或者直接跑/usr/local/bin/ffmpeg -version验证。接着检查我们最关心的两样ffmpeg -hide_banner -encoders | grep 265 ffmpeg -hide_banner -protocols | grep rtmp第一行应该能看到libx265第二行应该能看到rtmp。最后再确认一下编译配置ffmpeg -hide_banner -buildconf | grep -E x265|fdk|gpl能看到--enable-libx265就说明这份二进制确实带 H.265 编码能力补丁也在这个二进制里生效了。5. 推流实操H.265编码 RTMP5.1 一条能跑的推流命令编译和补丁都正常后推流命令反而不复杂。从一个本地文件推流最简单的形态是这样ffmpeg -re -i 1080p.mp4 \ -c:v libx265 -preset veryfast -b:v 3000k \ -maxrate 3600k -bufsize 6000k \ -c:a aac -b:a 128k -ar 44100 \ -g 60 -keyint_min 60 -sc_threshold 0 \ -x265-params bframes0 \ -f flv rtmp://你的服务器地址/live/test逐个解释。-re表示按原视频的帧率来读文件模拟实时推流不加这个参数 FFmpeg 会以最快速度读完文件然后瞬间推完直播场景必须加。-c:v libx265指定 H.265 编码器。-b:v 3000k是目标码率1080p H.265 直播一般 2.5 到 4 Mbps 之间就能达到可用画质这个值需要根据内容动态微调。-preset veryfast是编码速度和压缩率的折中直播场景推荐 veryfast 或 faster别用 medium延迟会变大、CPU 占用也高。音频方面-c:a aac用的是 FFmpeg 原生 AAC 编码器如果你编译时带上了 fdk-aac可以换成-c:a libfdk_aac音质更好。-g 60是 GOP 大小也就是每 60 帧一个关键帧在 30 帧率下相当于 2 秒一个关键帧这个值对直播延迟和首开速度影响很大。-x265-params bframes0是关掉 B 帧直播场景强烈建议关能让播放端不用为了重排帧序多等时间。5.2 直播编码参数的核心取舍关于 H.265 直播参数有几个取舍值得单独说。第一是码率控制方式。VOD 场景用-crf恒定质量很舒服但直播场景网络带宽是固定的我更推荐用-b:v配合-maxrate、-bufsize做限速这样码率波动不会把上行带宽打满。如果非要 CRF建议范围在 26 到 30 之间超过 32 画面细节就开始明显丢失了。第二是 GOP 和延迟的关系。关键帧间隔越短播放端启播越快、拖到关键帧的等待时间越短但码率开销越大。直播场景 1 到 2 秒一个关键帧是比较平衡的选择。有些人图省事写-g 0那在推流场景会出问题因为部分服务端认定关键帧间隔太大会主动断连。第三是 B 帧问题。RTMP/FLV 容器本身通过 CompositionTime 字段是支持 B 帧的但很多低延迟播放器收到带 B 帧的流要等重排延迟直接上去。-x265-params bframes0这个参数实测对延迟帮助非常明显而且牺牲的画质微乎其微。5.3 摄像头或采集卡输入如果你是做摄像头接入输入源就不是 mp4 文件而是 v4l2 设备。命令形态类似这样sudo ffmpeg -f v4l2 -framerate 25 -video_size 1920x1080 \ -input_format yuyv422 -i /dev/video0 \ -c:v libx265 -preset veryfast -b:v 2500k \ -f flv rtmp://你的服务器地址/live/camera01这里-video_size和-input_format要按摄像头的实际输出格式调整不少 USB 摄像头直接出 MJPEG 格式这时把-input_format换成mjpeg能让 CPU 负担小很多。注意 v4l2 设备通常需要 root 权限或者把自己的用户加进 video 组。5.4 播放端和服务端的配合验证推流命令起来了画面能不能播取决于接收端是不是认这套格式。如果服务端不支持 codec id 12推流可能表现为连接建立后没有报错但服务器端日志能看到 FLV tag 解析异常或者干脆在握手后主动断开。所以在正式环境上线前一定要先用一个支持 H.265 RTMP 的接收端做一次端到端验证。验证时最干净的做法是先用支持 H.265 RTMP 的服务端收流再用自研播放器或打过对应补丁的拉流播放链路看图像。不要用通用桌面播放器去验 H.265 RTMP大概率黑屏这会让你误以为是自己推流推错了。我个人的排查顺序是先看推流端是否持续打印编码日志再看服务端是否持续收到数据最后才怀疑播放端和解码格式。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因解决办法configure 报ERROR: libx265 not foundlibx265-dev 没装好或 pkg-config 路径不对重装 libx265-dev检查/usr/lib/pkgconfig下有没有 x265.pcmake 后运行 ffmpeg 报cannot open shared object fileldconfig 缓存里没有 /usr/local/lib执行ldconfig或写入/etc/ld.so.conf.d/ffmpeg.conf推流直接报Could not find tag for codec hevcflv_video_codec_ids 数组没加 HEVC 映射检查补丁第二处是否生效推流能建立但播放端黑屏sequence header 没发对或播放端不认 codec id 12检查 HEVC 分支是否写入 extradata换一个支持 H.265 RTMP 的播放端验证出现Non-monotonous DTS警告时间戳不连续常见于没加-re或 B 帧引发推流加-re直播参数里加bframes0服务器连上就断服务端不认 H.265 RTMP 扩展换支持该约定的服务器或用 H.264 降级测试CPU 占用接近满载preset 太慢、分辨率太高、码率控制没做好换-preset veryfast限制分辨率用-b:v限码率6.2 最隐蔽的坑补丁没生效但编译也不报错这可能是最坑的一点。有些情况下你改了flv.h和flvenc.c但实际编译的时候用的还是旧的目标文件FFmpeg 的增量编译偶尔会骗人。最稳的做法是改完源码后先make clean再重新 configure 和 make或者干脆删掉整个源码目录重新解压、重新打补丁。我踩过一次这个坑花了大半个晚上排查最后发现是增量编译用了旧的 flv 封装器对象文件。另外如果你的编译过程有多个工作目录或者用了别的构建脚本务必确认ffmpeg -buildconf里显示的就是你当前源码目录这次 configure 的结果。用strings去 grep 二进制里有没有 HEVC 相关字符串也是个快速检查法但最直接还是看自己的补丁步骤有没有真正执行。6.3 推流端正常但服务端拒收这种情况多半不是编译问题而是两边的格式约定不一致。现在凡是支持 H.265 RTMP 的服务端内部实现也可能有细微差异有的严格校验 sequence header 的格式有的只认特定的 VPS 层级有的要求 extradata 必须是完整 HEVCDecoderConfigurationRecord少一个数组就断流。实测中我最常遇到的就是 x265 在某些参数下输出的 extradata 结构和服务端解析器不兼容。遇到这种情况先用最简单的参数组合测试-profile:v main、-pix_fmt yuv420p、bframes0把变量降到最少。H.265 RTMP 这条链路本身就处在“事实标准”的地带参数越花哨踩到兼容性问题的概率越大。等基础链路通了再慢慢往上加编码质量参数。6.4 低配机器编译时的内存问题如果你是在云服务器或者老旧的工控机上编译内存只有 2 到 4 G那么make -j$(nproc)很容易把内存打满表现为编译中途进程被内核杀掉。解决办法是限制并行度make -j2甚至make -j1同时关掉不必要的服务释放内存。编译 FFmpeg 本身不像编译 chromium 那么恐怖但链接阶段的瞬间内存确实不小别掉以轻心。6.5 关于10-bit H.265的兼容性提醒如果后续你把 x265 换成了 10-bit 版本推流前先确认-pix_fmt是yuv420p10le并且在配置 ESP 时考虑播放端的解码能力。很多嵌入式和网页播放器只支持 8-bit 解码10-bit 推流会导致花屏或者完全没有图像。我的建议是RTMP H.265 场景老老实实用 8-bit Main Profile10-bit 留给文件存储和高画质点播场景。7. 个人实操心得与后续扩展思路编译这份 FFmpeg 的前前后后我最大的体会是工作量其实不在编译本身而在理解封装器那三层逻辑——codec tag 表、sequence header、NAL 格式转换。一旦你把这三件事想透了以后无论是换 FFmpeg 版本、加新的编码格式还是排查兼容性问题思路都会清晰很多。很多人卡在“编译失败了”这一步其实回去看看 configure 的输出百分之八十的问题都在依赖库没装全。补丁管理上我的建议是不要直接在源码目录里用 sed 或手改完就扔而是把修改整理成一个独立的 diff 文件下次解压新源码后一条命令打上去。这样既方便版本升级时复用也方便团队协作时让别人 review 你到底改了哪里。我的习惯是命名成h265_rtmp.patch和源码放在同一个目录管理。如果未来不想维护这套老补丁可以关注新版 FFmpeg 主线对增强 RTMP 的支持。它用 FourCC 的方式重新定义了 H.265 在 RTMP 里的封装格式理论上更规范。但要注意增强 RTMP 和本文讲的 codec id 12 老格式并不等价服务端和播放端都需要升级才能兼容。所以现有的摄像头、编码器项目如果已经在线上跑着老协议不要盲目升级先做兼容性测试。这个方案后续还可以做一些很实用的扩展。比如把这套FFmpeg 集成进推流脚本配合 shell 或服务端程序做多路摄像头轮询推流比如在推流的同时用-f flv落一份本地备份方便事后回看再比如把目标码率、GOP、分辨率做成配置文件按场景动态切换参数。H.265 over RTMP 这个链路目前看还会在生产环境存在很长一段时间自己掌握编译能力比每次都去网上找一个别人编译好的二进制要靠谱得多。
阅读完成 · 觉得有帮助？
