在视频处理这个行当里FFmpeg几乎是绕不开的存在。很多人电脑里装着一个FFmpeg用到的时候敲一行命令转个码、截个图但真到了项目里要选型要确认某个格式或协议是否支持才发现自己对它的了解远远不够。FFmpeg并不是一个简单的转码工具它本质上是整个多媒体处理领域的瑞士军刀内部包含了几百种编码器、解码器、封装格式解析器、网络协议实现和滤镜。它的能力边界几乎等同于整个开源多媒体生态的边界。这篇文章我想和你聊的不是怎么安装FFmpeg也不是转码命令怎么敲而是聚焦在标题里写的那四件事FFmpeg到底支持哪些编码器、解码器、封装格式、网络协议。这个能力清单直接决定了你的架构选型、转码方案、直播方案能不能落地。我会结合自己实际编译和使用FFmpeg的经验把这份清单背后的原理、编译配置、常见坑都梳理一遍。无论你是刚开始接触FFmpeg的小白还是已经在项目里被编码器不存在格式不支持折磨过几轮的开发这篇文章都能帮你省下不少排查时间。1. 为什么你需要真正认识FFmpeg的能力边界1.1 多数人的使用方式其实远够不到FFmpeg的完整能力大部分人用FFmpeg的场景是这样的从网上下载一个编译好的二进制文件然后开始转码遇到问题就换参数再试实在不行就换一个静态编译版本。我见过太多开发者在项目里用着一份不知道从哪里来的FFmpeg等到要接入某种协议、要用某个编码器的时候系统报一个Unknown encoder或者Protocol not found才开始慌。实际上FFmpeg的能力不是固定的它高度依赖编译时的配置。同样一个版本号的FFmpeg有人编译出来支持libx264、libfdk_aac、libvpx、libaom等几十个外部编码器有人编译出来只有内置那十几个。而支持多少编码器、封装格式、网络协议这件事恰恰就是标题里这四个维度的核心内容也是你在做视频项目选型时最先要搞清楚的事。举一个很典型的例子。某个直播项目需要把RTSP流拉下来转成HLS输出到CDN但在服务器上执行的时候发现FFmpeg能拉RTSP却报错找不到hls这个muxer。为什么因为那份二进制在编译时压根没启用HLS封装支持。你查代码、查文档、查网络折腾半天其实问题就是FFmpeg皮肤里没有长那个器官。所以认清FFmpeg的能力边界是选型的第一步也是排查问题的第一把钥匙。1.2 能力清单决定架构选型先搞清楚有什么再谈怎么用做任何视频相关的系统设计都会遇到几个绕不开的问题视频源是什么格式输出需要什么格式中间传输走什么协议。视频源是H.264的MP4还好说如果是一个老的MPEG-2 TS流或者一个H.265的RTSP摄像头你的处理节点就得同时具备对应的解码器和输入协议支持。如果处理节点还要做二次封装或者推流输出编码器和输出协议又成了新约束。我见过一个典型的方案翻车案例某公司在边缘节点用FFmpeg做实时转码输入是RTSP摄像头H.265主码流要求输出H.264的FLV推到CDN同时还要能转存成MP4。看起来没什么复杂但对FFmpeg的二进制来说这里涉及了H.265解码器、H.264编码器、FLV封装、MP4封装、RTSP协议、RTMP协议。只要其中任何一项在编译时被裁剪掉整个链路就跑不通。而且这种问题通常不在测试阶段暴露往往等到真机部署、流量上来才发现排查成本极高。所以我说这篇文章不只是在普及概念而是在帮你把FFmpeg的家底翻清楚。你自己用的那份FFmpeg能做什么、不能做什么命令一看便知但为什么要这样看、看到的每一行是什么意思、为什么有的编码器叫libx264而有的叫h264这些都搞明白之后你在面对视频技术选型时心里会有底得多。2. 一条命令查清家底查看内建编码器、解码器、格式与协议的方法2.1 ffmpeg -encoders 和 ffmpeg -decoders读懂列表里每一列想快速知道自己手上这份FFmpeg支持哪些编码器和解码器最直接的办法是执行以下两条命令。ffmpeg -encoders ffmpeg -decoders执行之后你会看到一张很大的列表。以编码器为例每一行大致长这样V....D libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264) V....D libx265 libx265 H.265 / HEVC (codec hevc) A....D libmp3lame libmp3lame MP3 (MPEG audio layer 2) (codec mp3)这里有三列信息值得关注。第一列是编码器类型和能力标记。V代表Video视频A代表Audio音频S代表Subtitle字幕。后面的四个点或字母分别代表第一个位置是否有帧级多线程支持第二个位置是否有slice级多线程支持第三个位置是否支持实验性功能第四个位置是否支持丢帧恢复。所以V....D的意思是视频编码器支持丢帧恢复其余能力未标记。第二列是编码器的内部名称也就是命令行里-c:v或者-c:a后面要填的名字。比如-c:v libx264、-c:a libmp3lame。第三列是描述信息括号里的codec通常是这个编码器对应通用编解码标识比如说libx264对应的codec是h264libmp3lame对应的codec是mp3。这里有个非常重要的点也是新手最常犯的错在命令行里写-c:v h264和写-c:v libx264结果完全不同。h264在编解码上下文里通常指的是解码器或者FFmpeg自研的实际上FFmpeg并没有一个完整的原生H.264编码器而libx264才是实际工作的H.264编码器它对外暴露的名字是libx264。如果你只写了-c:v h264FFmpeg会认为你想用名称叫h264的编码器在大多数编译配置下这个编码器根本不存在于是报Unknown encoder h264。看解码器列表的命令是一样的列出的条目更多因为解码器数量通常比编码器多FFmpeg在解码侧几乎是把各种历史格式都囊括了。同样要注意解码器名字和编码器名字不是一一对应的有的编码器没有对应解码器有的解码器没有对应编码器。比如mpeg4编解码器都有但h264编码器通常需要外部库解码器则是内置的。通过这两条命令你就能对自己手上的FFmpeg能力有个量化认知。我自己的习惯是拿到任何一份新的FFmpeg二进制第一步就是先跑这两条命令把输出重定向到文本文件里然后用grep去检索某个特定编解码器是否存在。2.2 ffmpeg -formats 和 ffmpeg -protocols容器与网络支持的完整视图编码器解码器之外另外两个维度就是封装格式和网络协议。对应命令分别是ffmpeg -formats ffmpeg -protocols执行ffmpeg -formats的输出每一行大概长这样DE flv Flv format D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV E mp4 MP4 (MPEG-4 Part 14) DE matroska,webm Matroska / WebM第一列的D代表支持解封装demuxing读取该容器E代表支持封装muxing写入该容器。所以DE表示既能读也能写D表示只能读E表示只能写。第二列是格式名称多个扩展名并列表示它们共用同一个封装实现。第三列是描述。这里要特别提醒格式名称是你在命令行里用-f参数指定的那个字符串而不是文件扩展名。例如播放一个FLV文件FFmpeg会自动根据文件头判断格式不需要加-f flv。但在输出时如果你指定了输出文件为output.mp4FFmpeg会根据扩展名推断muxer为mp4这时你手写-f mp4和省略-f效果一样。如果输出文件名没有扩展名就必须用-f指定输出格式。网络协议方面ffmpeg -protocols的输出分成输入协议和输出协议两组。常见的像file本地文件、pipe标准输入输出、http/https、rtmp/rtmps、rtsp、srt、udp、tcp、tls等都会在这里列出来。需要注意的是协议支持和编解码器不一样它几乎完全由编译时是否包含对应的网络库决定。比如要支持https编译时需要openssl或gnutls要支持srt编译时需要libsrt库要支持rtmps需要openssl。所以同样一份FFmpeg有没有这个协议不能靠猜跑一下ffmpeg -protocols就知道。我看过很多人排查问题时不看这个列表直接在网上搜ffmpeg rtmp not supported搜来搜去还是没法解决。其实你只要执行一下这个命令确认rtmp是否在你的协议列表里问题基本就能定位一多半。2.3 编译开关如何决定这份清单的长短现在你应该明白一个核心事实FFmpeg的能力清单不是天生的而是编译出来的。编译时调用的configure脚本带了哪些--enable参数决定了最终二进制里有哪些编码器、解码器、协议和格式。configure的常见参数大致可以分成三类内置功能开关。比如--disable-encoders、--disable-decoders、--disable-muxers、--disable-demuxers、--disable-protocols、--disable-filters以及更细粒度的--disable-encoderlibx264这种。默认情况下FFmpeg会启用全部内置功能外部库则要逐个enable。外部库开关。比如--enable-libx264、--enable-libx265、--enable-libvpx、--enable-libopus、--enable-libfdk-aac、--enable-libmp3lame、--enable-libass、--enable-libfreetype。每启用一个外部库都会给FFmpeg增加对应的编码器或解码器同时引入该库的license要求。授权模式开关。--enable-gpl、--enable-nonfree、--enable-version3这几个直接决定了最终二进制的授权性质后面我会专门讲。很多网上下载的全功能FFmpeg静态编译包其实并不可能包含所有外部库因为部分库的授权和GPL/nonfree冲突有些编译者为了规避法律风险会刻意关闭某些编码器。最常见的例子就是libfdk_aac它是高质量的AAC编码器但它的license是nonfree的所以很多发行版不会带上它。这也是为什么很多人在Windows上用一个下载的FFmpeg时执行ffmpeg -encoders能看到一串AAC相关的名字却唯独没有libfdk_aac。3. 编码器与解码器核心清单视频、音频按场景挑不踩坑3.1 视频编码器H.264/H.265/VP9/AV1的选型要点FFmpeg里的视频编码器可以从两个维度分类内置实现和外部库实现。内置实现的编码器通常质量一般、速度尚可、适用范围有限外部库则是有名的项目通过FFmpeg统一封装暴露出来。先看H.264。这是目前兼容性最好的视频编码格式几乎所有浏览器、播放器、手机、电视都支持。FFmpeg里主要有两个H.264编码实现一个是libx264这是H.264编码的事实标准另一个是OpenH264FFmpeg里叫libopenh264。日常使用首选libx264它的编码质量、参数控制、性能都是最成熟的。命令行例子ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a copy output_h264.mp4其中-preset控制编码速度和压缩率的取舍从ultrafast到placebo越慢压缩率越高-crf控制质量数值越低质量越高23是x264的默认平衡点。这里提醒一下如果你把人家的视频转成H.264最好不要用-placebo这种极端参数对于实际项目来说编码速度太慢不划算而且压缩率提升并不明显。H.265/HEVC的情况和H.264类似只是压缩率更高、编码更慢兼容性略差。FFmpeg里主要是libx265和libkvazaar其中libx265最常用。它的命令行逻辑与libx264几乎一致只是预设名称和部分参数的取值范围不同ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 -c:a copy output_hevc.mp4对于同等视觉质量H.265的码率通常可以比H.264再省一半左右代价是编码耗时明显增加。如果只是本地存档追求体积小画质好H.265是不错的选择如果是做在线视频平台要考虑终端的硬解兼容性H.264仍然是更稳的选择。VP9是Google主导的免版税视频编码格式。FFmpeg里对应libvpx-vp9。VP9的压缩率比H.264高和H.265接近但编码速度很慢一般用于Web和Android生态。它的命令行示例如下ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 2M -minrate 1M -maxrate 2M -cpu-used 4 -c:a libopus output.webmAV1是最新一代免版税编码格式压缩率比VP9再高一截但编码开销极大。FFmpeg里常见的实现是libaom-av1、librav1e、libsvtav1。如果你不是专门做视频压缩优化的建议观察SVT-AV1这个实现它在速度和压缩率之间平衡得相对好ffmpeg -i input.mp4 -c:v libsvtav1 -preset 8 -crf 30 -c:a copy output_av1.mp4再往下的MPEG-2、MPEG-4 Part 2也就是divx/xvid那一代、WMV、RV等老编码器FFmpeg也支持输出但基本只在做老旧设备兼容时才会用到。这类编码器的实现大多是内置的mpeg2video、mpeg4、wmv2、rv10等了解即可。关于解码器FFmpeg的解码覆盖非常广从最新的AV1到上世纪的各种格式都内置了解码。视频解码器最常见的有h264、hevc、mpeg2video、mpeg4、vp8、vp9、av1、wmv3、rv30、rv40等。出发点要知道的两件事一是解码器名字不带lib前缀因为FFmpeg自己实现了大部分解码器不依赖外部库二是硬解需要额外启用对应的hwaccel或hwdecoder比如-c:v h264_cuvid之类的解码器这是NVIDIA硬解的实现只有编译时启用了对应硬件支持才会出现。3.2 音频编码器AAC家族、Opus、MP3的取舍逻辑音频编码这块看起来简单实则最容易踩坑。最常见的需求就是把各种来源的视频转成带AAC音频的MP4或FLV如何选择AAC编码器就是一个典型的例子。FFmpeg里AAC编码器大概有这几种内置的aac、libfdk_aac、以及某些编译里会出现的native encoder变种。内置aac是FFmpeg自己实现的AAC编码器质量经过多年迭代已经可用但和libfdk_aac相比在低码率下还是有差距。libfdk_aac是Fraunhofer的AAC编码器实现质量公认最高但license是nonfree很多编译包不带。命令行用的时候# 使用内置AAC ffmpeg -i input.mp4 -c:a aac -b:a 128k output.mp4 # 使用libfdk_aac ffmpeg -i input.mp4 -c:a libfdk_aac -b:a 128k output.mp4对于大多数在线视频场景内置aac在128k到192k的码率下已经够用没必要为了那一点点音质差异去纠结nonfree库。但如果你正在做的产品对音频质量有硬性要求比如音乐类App的音频转码那就得找一个编译了libfdk_aac的FFmpeg版本。Opus是新一代免版税音频编码格式它在语音和低码率音乐场景下表现极为出色是VoIP和WebRTC的事实标准。FFmpeg里对应的编码器是libopus。如果你要把音频转成Opus格式尤其低保真度传输场景我强烈推荐ffmpeg -i input.mp3 -c:a libopus -b:a 64k output.opusMP3当然也支持编码器是libmp3lame。虽然新项目不推荐再用MP3编码但老设备的兼容性需求还是存在的。FLAC是无损音频编码FFmpeg内置了flac编码器做音频源文件转码、无损存档的时候会用到。还有像Vorbislibvorbis、AMR-NB、AMR-WB、AAC-LC这种专业音频编码器FFmpeg全都支持具体用哪个根据场景来定。3.3 解码器与免版税软解它是否真的无所不能有一个常见误区很多人以为FFmpeg能解码一切视频。实际上FFmpeg解码器的覆盖确实非常广几乎涵盖了所有常见和不常见的格式但仍然有边界。比如某些商用闭源编码器例如某些特殊监控设备的私有编码格式FFmpeg不一定有对应实现Windows Media Audio的某些变种FFmpeg虽然能解但偶尔也会遇到容器不规范导致的解析失败。这里我建议收藏下面这个命令它可以快速告诉你FFmpeg的解码器清单里有没有你要的格式ffmpeg -decoders | grep 268比如要查HEVC解码器就搜hevc要查AV1解码器就搜av1。查到之后还要确认前面是不是D标记。如果显示D指能解封装E指能封装只有D没有E很正常播放器场景只需要解封装。另外FFmpeg内置的解码器大多以软解实现也就是纯CPU运算。在低分辨率、低并发场景下够用但如果你的业务是大量并发转码、多路实时解码那就必须考虑GPU硬解方案。硬解在FFmpeg里体现为带硬件前缀的解码器比如h264_cuvid、hevc_nvenc这种。要确认你的FFmpeg是否支持硬解还是跑ffmpeg -encoders和ffmpeg -decoders搜索类似cuvid、nvenc、vaapi、qsv这样的关键词。如果搜不到就需要换一个编译了硬件加速支持的FFmpeg版本或者自己重新编译。4. 封装格式与网络协议容器选型和推流拉流背后的硬道理4.1 常用封装格式对照MP4、MKV、FLV、TS怎么选封装格式是很多人容易忽略的一层。编码器决定视频流和音频流本身的编码方式封装格式决定这些流如何被组织、如何被索引、如何被播放器读取。FFmpeg支持的封装格式非常多下面这张表我根据实际业务常用程度整理了一个对照封装格式主要场景支持情况一般Full Build备注MP4/MOV点播、H5播放、移动端DE索引在文件尾部不适合直播流直接写MKV/WebM高清收藏、多音轨多字幕DEWebM是MKV的免版税子集FLV直播推流、Flash时代遗留DE直播领域依旧活跃CDN兼容性好TS/M2TSHLS切片、广电直播DE支持拼接HLS切片必须用它AVI老设备、简单编辑DE索引方式老旧不推荐新项目WAV音频存档DE无压缩PCM文件大MP4是目前点播场景的王者它把音视频流交错存储并在文件尾部有一个moov box记录索引信息。这个设计带来一个麻烦如果把MP4直接作为直播输出流写播放器需要读到moov box才能开始播放而直播流没有尽头尾部永远无法写入。所以通常直播场景会用FLV或者TS来承载转存到本地时才封装成MP4。FFmpeg在输出MP4时默认会做faststart吗默认不会但你可以用-movflags faststart把moov box挪到文件头部ffmpeg -i input.mp4 -c:v copy -c:a copy -movflags faststart output_faststart.mp4做Web播放时这个参数很关键否则用户打开视频要等整个文件下载完或等到moov到达才能开始播放体验极差。FLV在直播领域的生命力出乎意料地强。虽然Flash已经淘汰但FLV容器本身结构简单、延迟低、兼容性好RTMP推流和大部分直播CDN都沿用FLV封装。FFmpeg输出FLV时要注意FLV不支持H.265编码流直接封装部分扩展实现例外也不支持某些音频编码器例如opus在FLV里也无法使用。所以在直播链路里常见的组合是H.264AACFLV这个组合在各大直播平台验证得非常成熟。TS则专门为流媒体设计它有很强的纠错机制和拼接能力所以HLS协议强制要求切片文件必须是TS。FFmpeg把流封装成TS很简单ffmpeg -i input.mp4 -c:v copy -c:a copy -f mpegts output.ts4.2 网络协议支持HTTP、RTMP、RTSP、SRT、UDP各管一段FFmpeg之所以能把远程视频流拉回来再推出去靠的就是网络协议层的实现。这里我把常见协议整理成一张使用场景表协议方向典型场景延迟特征file / pipe本地输入输出日常处理、管道流无http / https拉流、点播HLS拉流、HTTP-FLV取决于流类型rtsp拉流摄像头监控、IPCam低延迟rtmp / rtmps推流-拉流直播推流到CDN、旧式直播播放中低延迟srt推流-拉流跨国传输、弱网传输中低延迟udp / tcp自定义流、组播广电、音视频专网传输极低延迟RTSP是监控摄像头最常用的协议FFmpeg拉RTSP流的命令基本就是ffmpeg -rtsp_transport tcp -i rtsp://192.168.x.x:554/stream1 -c:v copy -c:a copy -f flv rtmp://push.example.com/live/stream这里有个细节摄像头默认可能走UDP传输但UDP在复杂网络下丢包严重建议显式指定-tcp。如果你要降低延迟可以加-fflags nobuffer和-flags low_delay这两个参数能把播放缓冲降到最低代价是丢包或网络抖动时更容易花屏。RTMP则是推流到直播服务器时最常用的协议。FFmpeg推RTMP流ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://ingest.example.com/live/stream注意-re参数它代表以输入文件的原始帧速率进行读取让FFmpeg以实时速度推流否则会全速推送瞬间推完。很多新手在推直播流时忘记加-re导致服务器端看到的是几秒内就推完的畸形流这是非常典型的问题。SRT是近年来直播传输中很受关注的协议它在UDP之上做了加密、重传和拥塞控制特别适合在不稳定的互联网上传输高码率视频。FFmpeg用libsrt接收SRT流ffmpeg -i srt://0.0.0.0:9000?modelistener -c:v copy -c:a copy -f mpegts output.ts最后HTTP协议在FFmpeg里主要承担拉流功能。HLS点播流的每一段TS切片都是通过HTTP拉取的HTTP-FLV则是目前低延迟直播应用的热门方案。FFmpeg从HTTP拉流没有太多特殊的参数但要注意如果目标URL需要cookie或者user-agent可以用-headers选项附加请求头。5. 从编译配置到自定义构建让FFmpeg真正匹配你的业务5.1 常见编译开关与授权边界GPL、LGPL、nonfree如果你打算自己编译FFmpeg而不是下载别人做好的二进制就必须理解编译开关和授权之间的关系。很多人在这里吃亏编译出来的FFmpeg要么缺这个库缺那个库要么因为license问题不敢用于商业项目。FFmpeg的configure脚本里控制授权的主要参数是这三个--enable-gpl、--enable-version3、--enable-nonfree。它们决定了你的构建属于哪一类授权边界。纯LGPL构建不启用gpl和nonfree或者只使用符合LGPL的组件。这样得到的FFmpeg可以闭源商用但不能链接GPL组件。实际上FFmpeg很多内置功能本身就是GPL的完全禁用GPL组件你会失去很多内置滤镜和部分编码器。GPL构建--enable-gpl。GPL构建允许链接libx264、libx265这类GPL授权的外部库但整个二进制的对外分发也必须遵守GPL。如果你只是内部自用不会把这套FFmpeg作为独立软件对外分发通常问题不大如果你做的是嵌入式设备、SDK或者商业闭源产品就需要谨慎。nonfree构建--enable-nonfree。加了nonfree之后可以链接libfdk_aac这类非自由授权库。但要特别注意--enable-nonfree和--enable-gpl不能同时使用吗在FFmpeg这里官方文档明确表示--enable-nonfree会覆盖GPL的检查最终二进制的授权会变得非常严格。一般建议非必要不启用nonfree能用手头已有的替代品就用手头已有的替代品。除了授权参数还有大量功能裁剪参数。比如./configure --prefix/opt/ffmpeg \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-libvpx \ --enable-libmp3lame \ --enable-libopus \ --enable-libass \ --enable-libfreetype \ --enable-openssl \ --disable-doc \ --disable-debug \ --disable-ffplay \ --disable-ffprobe \ --disable-ffserver这个配置里我保留了核心转码能力关闭了文档、调试和播放器工具最终二进制体积会小很多。如果你不需要ffplay播放器和ffprobe媒体分析工具可以disable掉。不过我的建议是保留ffprobe因为排查媒体文件时它太方便了。5.2 构建一个真正能用的FFmpeg最小化与定制化思路自己编译FFmpeg最核心的收益不是最小体积而是你可以精确控制编码器、协议、格式三者之间的组合。很多云服务器上的FFmpeg老出协议找不到muxer找不到的问题本质就是编译者没有针对使用场景裁剪或补齐功能。在实际构建时有几个很实用的思路第一永远用静态链接。静态编译会把依赖库全部编译进FFmpeg二进制里部署时不需要在每台机器上再装libx264、libopus这些系统依赖。对于容器化部署尤其方便COPY一个二进制进去就能跑。configure之后make的时候加一下静态编译选项./configure --enable-static --disable-shared ... make -j$(nproc) make install第二按需裁剪。如果你的服务只需要处理MP4转H.264AAC并输出HLS那可以disable掉不需要的编解码器。但我不建议过度裁剪因为生产环境的需求变化很快今天只需要H.264明天就可能要支持VP9。折中方案是保留常用编解码器只disable掉那些明显用不到的先例比如--disable-decoderals澳大利亚无损音频之类。第三外部库版本要匹配。FFmpeg对第三方库有最低版本要求系统自带的老版本库可能导致configure失败或运行时CE。编译前建议先把依赖库升级到较新稳定版本nginx-rtmp等模块也一样。最后还要说一个点手动编译FFmpeg之前把configure的输出留底。编译完之后用ffmpeg -version查看完整配置信息再对照你实际要用的功能检查一遍。这个习惯能帮你省掉后续大量为什么没有某个功能的问题。6. 实测过的坑与排查心得编码器不存在、格式不支持的真实处理过程6.1 编译后编码器仍然缺失一条完整排查链路有一次我在一台服务器上部署转码服务现场执行了一个转码命令指定使用libx264编码器结果FFmpeg直接报错Unknown encoder libx264我的第一反应不是去看代码而是先执行ffmpeg -encoders | grep 264发现输出列表里根本没有libx264。然后又执行ffmpeg -version确认FFmpeg的configure信息里没有--enable-libx264也没有--enable-gpl。问题显而易见这份FFmpeg是纯LGPL构建没链接x264。这个案例说明了一个排查顺序遇到编码器或协议缺失不要急着去查业务代码先用ffmpeg -encoders / -decoders / -protocols / -formats确认功能是否存在再用ffmpeg -version查看文章开头的configure参数判断是编译裁剪还是本来就没有如果功能确实缺失针对你的使用场景重新编译或找一个编译齐全的构建。有时候问题还出在参数写错。比如把-c:a libfdk_aac写成-c:a fdk_aac名称少了个lib前缀FFmpeg同样会报Unknown encoder。编码器名称必须严格匹配ffmpeg -encoders输出列表中的名字。另外如果你加了很多外部库之后编译成功但运行时又报error while loading shared libraries: libx264.so.xxx说明你编译时用了动态链接而目标机器上缺少对应的动态库。解决办法要么重新静态编译要么把动态库一并拷贝到目标机器并设置LD_LIBRARY_PATH。我自己经历过几次这类问题之后养成了一个习惯每次部署FFmpeg之后第一件事不是跑业务而是先跑一个自测脚本分别验证H.264编码、H.265解码、RTSP拉流、RTMP推流、HLS封装是否正常。这样能在业务接入之前就把环境问题暴露出来。6.2 容器与字幕、帧率的隐形限制几个容易忽略的细节功能缺失之外还有一类坑属于功能都在但组合起来不工作的情况这往往是容器与编码器、字幕流之间的兼容性问题。先说字幕。FFmpeg支持的字幕封装格式包括srt、ass、mov_text等但并不是所有容器都支持所有字幕格式。比如MP4容器通常支持mov_text字幕MKV容器支持srt和ass字幕而FLV和TS容器根本不支持字幕流。如果你做直播流推FLV又想带字幕基本无解只能在服务端把字幕烧录到画面里也就是用subtitles滤镜或overlay滤镜把字幕渲染成视频的一部分。再说帧率。有的容器对帧率有特殊要求比如某些老式播放器或专业广电设备对TS流的PTS/DTS要求比较严格。FFmpeg转码时如果只-c:v copy流的时间戳信息可能不规范的会导致播放器卡顿或音画不同步。这时可以在输出端加上-muxdelay 0 -muxpreload 0或者用-vf settbAVTB来强制时间基。还有一个常见场景把H.265视频封装到MP4里有些播放器能播有些老浏览器播不了。这不是FFmpeg不支持而是播放器不支持H.265解码。所以做浏览器端播放时别把视频转成H.265就以为万事大吉最好先确认目标播放器的软硬解能力。关于流拷贝也有一点值得专门提醒。用-c:v copy -c:a copy做流拷贝时FFmpeg几乎不重新编码速度极快但它要求源文件的编码格式和目标容器兼容。比如把MP4里的H.264AAC拷贝进MOV没问题但把H.264AAC拷贝进WebM会失败因为WebM只接受VP8/VP9/AV1视频和Vorbis/Opus音频。也就是说copy操作只能做容器转换不能做编码转换编码不兼容时就必须走重编码。最后提一个很多人问过的问题为什么ffmpeg -formats里明明有mp4我用-f mp4输出却报错这种情况通常是因为你同时指定了不支持的编码组合比如输出MP4时音视频流用了libvpx和libopusMP4并不支持VP9/Opus的标准组合MP4里VP9/Opus的支持依赖额外扩展FFmpeg的默认MP4 muxer对WebM系的编码支持很弱。FFmpeg在封装时会检查编码格式与容器是否兼容不兼容就报错。排查思路是把-c:v和-c:a临时换成-mp4容器支持的H.264和AAC问题立刻就能定位。这让我想起另一个教训在业务代码里封装格式和编码器最好抽象成配置项不要硬编码成MP4H.264AAC的组合。因为一旦后续需要输出WebM或TS改动会非常麻烦。我当时在一个模拟项目中就是这么设计的把输出容器、视频编码器、音频编码器全部做成可配置跑过一次多格式输出测试后发现新增格式只需要加配置不用动代码框架。这种格式无关的设计思路在视频处理系统里特别值得推广。
