简介面向Linux环境下需要部署ffmpeg的开发者与运维人员这是一份详细讲解ffmpeg源码编译安装的中文教程文档重点解决依赖库安装、编译选项配置以及安装后运行报错等问题。资源以单个docx文档提供整包仅18KB但内容紧凑涵盖从基础环境准备到最终验证的完整流程已有1544人学习浏览说明其在初学者中有较高的参考价值。文档从mp3编码库lame入手逐步演示amr-nb/amr-wb、faad2、faac等音频组件的编译接入再进入ffmpeg主体configure与make步骤对configure时常见的config.h权限拒绝给出了直接修改建议并针对动态共享库找不到的问题列出复制so文件的处理方式。文末还附带视频转码、视频截图等常用命令示例方便读者装完即用适合需要手动编译安装ffmpeg或想深入理解依赖关系的入门及中级用户。1. ffmpeg 安装看起来是下载解压实际上在选运行时和协议很多人第一次接触 ffmpeg 安装以为下载解压就能用结果卡在半路要么打开终端提示找不到命令要么转码时报 encoder 找不到要么编译出来的版本连 h264 都编不了。ffmpeg 安装从来不是“下载一个可执行文件放进 PATH”那么简单它背后是三个选择用哪种方式装包管理器、官方二进制文件、源码编译、选哪类许可证GPL 还是 LGPL、要不要带上 SDK 给后续开发用。这篇文章把这三件事一次讲透让新手能跟着步骤把 ffmpeg 跑起来也让熟手在选型时少踩坑。2. 安装路线先想清楚包管理器、官方二进制、源码编译怎么选2.1 系统包管理器安装最快但可能不是最新版在 Linux 和 macOS 上最常见的 ffmpeg 安装方式是直接走系统包管理器Debian/Ubuntu 用 aptCentOS/RHEL 用 yum/dnfmacOS 用 Homebrew。这种方式的好处是依赖自动处理装完就能跑不用管那些乱七八糟的动态库。我一般会建议刚入门的用户先用这条路先把 ffmpeg 用起来等遇到编码器缺失或者版本太旧的问题再考虑换路线。但包管理器有一个绕不开的短板版本滞后。Ubuntu 的 apt 源里 ffmpeg 版本往往比官方落后一两个大版本而且很多发行版为了许可证合规默认编译时砍掉了 GPL 组件。你可能会遇到这种情况转码时想用 libx265结果 ffmpeg 直接告诉你 Unknown encoder libx265。这不是你操作失误而是安装源里那个 ffmpeg 二进制文件本身就不带 GPL 编码器。所以用包管理器安装后的第一件事不是急着转码而是确认你拿到的是个“完整版”。命令很简单ffmpeg -encoders 2/dev/null | grep -E libx264|libx265如果这条命令什么都没输出说明当前安装的 ffmpeg 不包含这两个最常用的 H.264/H.265 编码器。在 Ubuntu 上可以通过安装额外包解决一部分问题但更干净的解法是换官方二进制文件或者自己编译。这一点我在第 5 章的避坑部分会专门展开。2.2 官方二进制文件下载Windows/macOS 的省心路线如果你用 Windows系统包管理器这种概念基本不成立官方二进制文件就是最省心的路线。ffmpeg 官网的下载页也就是热词里常说的 ffmpeg 下载官网提供了各平台的编译好的二进制包Windows 有 static 和 shared 两种版本macOS 有对应架构的构建产物。static 版本把所有依赖和模块都打进了一个可执行文件里运行时不依赖额外 DLL适合直接拿来跑命令shared 版本则把核心逻辑放在 DLL 里体积更小但需要把 DLL 一起带上适合做二次开发时参考链接。我一般建议工具型用户选 static做 C 封装或者 SDK 调用的开发者选 shared因为后者会额外输出 lib 和头文件虽然官方 Windows 包的头文件并不总是齐全这一点后面说。下载时还要注意一个细节官方 Windows 构建分带 GPL 和不带 GPL 两种。如果你只是做日常转码不带 GPL 的版本也能处理 H.264 和 H.265 的软编解码但如果你打算用 ffmpeg 去调用 libx265 这类 GPL 编码器就必须下载标注了 GPL 的构建。这个选择直接关系到后面命令能不能跑通不是玄学是许可证边界。2.3 源码编译安装什么时候才需要走这条路源码编译是最后一道选择也是很多人最头疼的一条路。它适合三种人一是需要定制模块的人比如在 ffmpeg 里加一个官方构建没带的第三方库二是需要做二次开发的人他们不只要可执行文件还需要完整的头文件、导入库和符号信息三是遇到“官方二进制文件没有对应平台版本”的人比如某些嵌入式环境或者特定的操作系统组合。这里有一个很常见的需求在 Windows 上用 MSVC 编译 ffmpeg 并启用 libx265。为什么官方有现成的 Windows 包还要自己编因为官方二进制文件是用 MinGW 工具链编的生成的库文件格式和 MSVC 的 C 运行库CRT不匹配你在 Visual Studio 里做 C 封装时链接阶段会碰到一堆莫名其妙的符号冲突。所以做 Windows 桌面开发的人经常绕不开“用 MSVC 重编一遍 ffmpeg”这个活。MSVC 编译 ffmpeg 的正确打开方式是先装 MSYS2在里面把 yasm/nasm 和 pkg-config 配好再用 Visual Studio 的开发者命令提示符环境去调用 configure——注意这里的魔鬼细节你不能直接在 cmd 里跑 configure必须在“适用于 VS 的 x64 原生工具命令提示符”里执行否则编译器检测环节会直接翻车。configure 时如果想带 libx265需要先单独编译 x265 库并让它能被 pkg-config 找到。这块每一步都依赖前置环境少一个环节就是报错重来所以新手我一般不建议第一条路就选源码编译。在动手之前先想清楚你是要跑命令做工具用还是要拿 API 做开发。工具用官方二进制文件最省事开发用哪怕是折磨人的 MSVC 编译也躲不掉。这个判断做完后面的安装步骤才有意义。3. 实操从下载到环境变量把 ffmpeg 装进你的机器3.1 Windows下载、解压、配置环境变量三步走Windows 上装 ffmpeg 的完整流程可以拆成三步下载、解压、配环境变量。前两步没有技术含量但有一个细节值得提下载下来的压缩包解压后里面是一个像ffmpeg-7.x-full_build这样的目录真正的可执行文件在bin子目录下。很多人解压后直接进目录双击 ffmpeg.exe 闪退就以为安装失败了其实它只是缺一个能停住的控制台窗口。第三步环境变量是关键也是热搜词 “ffmpeg 安装后怎么配置环境变量” 对应的问题。把bin目录路径加进系统 PATH 之后你在任何目录下打开终端都能直接敲 ffmpeg。PowerShell 下配置的推荐写法如下# 假设解压路径为 D:\tools\ffmpeg-7.x-full_build # 把 bin 目录追加到用户级 PATH 变量 $ffmpegBin D:\tools\ffmpeg-7.x-full_build\bin $oldPath [Environment]::GetEnvironmentVariable(Path, User) [Environment]::SetEnvironmentVariable(Path, $oldPath;$ffmpegBin, User)这段脚本用 .NET API 直接修改的是用户级环境变量的注册表持久值而不是当前会话的临时值。这样做的优势是新开的每一个终端窗口都能生效不需要每次开机都重新配一次。配完后要刷新环境变量有几种方式重开终端、注销重登、或者用refreshenv工具。我一般习惯直接重开一个 PowerShell 窗口最省心。验证是否装好就一条命令ffmpeg -version如果输出里能看到ffmpeg version和--enable-libx264 --enable-libx265这类配置项说明安装成功且 GPL 编码器是齐的。如果提示“无法将 ffmpeg 识别为 cmdlet”先别怀疑 ffmpeg先去看 PATH 是不是真的写对了。3.2 macOSHomebrew 一条命令后的隐藏配置macOS 上装 ffmpeg 大多走 Homebrew。如果你还没装 Homebrew可以直接去官网按它的安装命令装装完再执行brew install ffmpeg这条命令会把 ffmpeg 以及一大堆依赖库x264、x265、vpx、mp3lame 等一起编译安装。安装过程比较久因为 Homebrew 默认用源码编译这些依赖除非你已经有一个带 bottle预编译包的环境。装完以后的位置在/opt/homebrew/bin/ffmpegApple Silicon 架构或者/usr/local/bin/ffmpegIntel 架构这两个路径通常已经在 Homebrew 安装时自动加入 PATH。装完先别急着用先看一眼编码器是否齐全ffmpeg -encoders 2/dev/null | grep 265如果是 Apple Silicon 的机器除了 libx265你还会看到hevc_videotoolbox这个硬件编码器。很多人在这里纠结既然有硬件编码器是不是就不需要 libx265 了不是一回事。hevc_videotoolbox走的是 GPU 硬件编码速度快但码率控制不如 x265 精细x265 是纯软件编码慢但压缩率好。两个都留着按场景选这才是完整安装的价值。另外如果你在 macOS 上做开发Homebrew 装的 ffmpeg 会顺带把ffmpeg-lib相关库和头文件放到/opt/homebrew/include和/opt/homebrew/lib下这对后面做 C 封装是一个巨大利好。Windows 官方二进制文件缺的那部分开发文件在 macOS 上反而很齐整。3.3 Linuxapt 装完先查一下编码器支持Linux 的安装命令因发行版而异。Debian/Ubuntu 系是sudo apt update sudo apt install ffmpegCentOS/RHEL 系默认仓库里可能没有 ffmpeg需要先启用 EPEL 和 RPM Fusion 仓库再执行安装。装完以后同样先验证编码器ffmpeg -hide_banner -encoders 2/dev/null | grep libx265如果没有输出就需要给 apt 添加第三方多媒体源比如 deb-multimedia或者直接用官方编译的静态包。这里有一个很多教程没讲透的点Ubuntu 的 ffmpeg 包有时会显示--enable-libx265但实际运行的版本却被 UEFI Secure Boot 或版权相关的策略裁掉了导致编译配置里有这个选项运行时却找不到编码器。所以我验证时习惯直接用一次性命令跑一个真实转码而不是看配置输出的那种表面自信。这也是我强调“装完先跑通”的原因。4. 安装完先跑通这三条命令再谈其他4.1 ffprobe 验证装上不等于能用ffmpeg 安装完成后很多人直接跑转码命令报错之后才开始排查效率很低。我的习惯是先跑 ffprobe这不是“多此一举”而是用最小成本确认三件事可执行文件路径是否正确、动态库依赖是否完整、媒体解析器是否可用。ffprobe -hide_banner -show_format detail.mp4把detail.mp4换成你手上任意一个视频文件。如果这条命令能输出文件的时长、比特率、编码器信息说明 ffmpeg 的核心动态库加载没有问题。如果在这条命令上报error while loading shared libraries那么你装的那个版本缺系统依赖这个我们在第 5 章细说。-show_format参数是让 ffprobe 输出封装格式层面的信息-hide_banner则是去掉启动时的编译配置输出让结果干净一点。这里有一个参数细节ffprobe 和 ffmpeg 是同一个项目装出来的两个独立工具如果 ffmpeg 能跑但 ffprobe 提示找不到通常不是安装损坏而是你把两者放到了不同的目录PATH 里只能搜到其中一个。下载官方二进制文件时ffprobe.exe 和 ffmpeg.exe 在同一个 bin 目录下一般不会出现这种分裂但如果你是自己编译的记得把--prefix指向同一个安装目录。4.2 一条转码命令验证硬件与编码器工作正常ffprobe 过了再跑一条真实转码命令。这条命令的目的是验证编码器链路完整而不是追求压缩效果所以参数要保守确保在任何机器上都能跑通ffmpeg -i detail.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4这条命令把输入视频的编码改为 H.264libx264音频转成 AAC 的 128kbps-preset medium是速度和压缩率的中间档-crf 23是 H.264 的默认质量档数值越小画质越好、文件越大。如果这命令能跑完并且生成 output.mp4说明你的 ffmpeg 至少具备封装格式MP4读写、H.264 编码器、AAC 编码器、H.264 解码能力。如果报Unknown encoder libx264说明你装的版本没有 GPL 组件。解决方案是换官方 GPL 构建或者自己编译时打开--enable-gpl --enable-libx264。如果你装的是 apt 源里的版本也可以试着安装libavcodec-extra来补全编码器。注意 apt 的 extra 包在某些发行版里也覆盖不全最保底的做法还是官方二进制文件。在这条命令里最容易翻车的参数其实是-crf 23。有些刚上手的人会以为 CRF 值越大画质越好实际正好相反CRF 是“质量导向”的恒定质量参数值越小质量越高。这个参数不是越大越好也不是越小越好它是一个面向结果的压缩率档位理解错了后面调优就全乱套。4.3 用 ffmpeg 降低码率并推流到 SRS测延迟要看整体链路验证完转码再往前走一步就是推流了。很多人在“ffmpeg 推流到 SRS 存在延迟”这个问题上兜圈子其实推流工具本身只是链路的一环延迟不是 ffmpeg 单独能背的锅但 ffmpeg 的参数会显著影响延迟表现。先看降低码率这个需求它和推流往往是连在一起的上传带宽有限或直播场景要求码率不要超限。一条典型的命令是ffmpeg -re -i input.mp4 -c:v libx264 -b:v 1500k -maxrate 1800k -bufsize 3000k \ -c:a aac -b:a 128k -f flv rtmp://your-server.lan/live/stream-re表示按原始帧率读取输入模拟实时直播-b:v 1500k把视频码率压到 1500kbps-maxrate和-bufsize约束了码率波动范围这两个参数不配合设置的话实测码率会忽高忽低。音频 128k 是常见值不会带来明显延迟。推流到 SRS 时如果你发现播放端延迟偏高先别急着改 ffmpeg 参数先用这个思路排查SRS 的 HTTP-FLV 播放是否开了 GOP 缓存、播放器缓冲设置了多少秒、推流时是不是用了-re导致输入读取节奏和实际时间不一致。延迟是一个链路问题ffmpeg 推出来的流本身只引入编码缓冲和网络发送缓冲这两部分通常只有几百毫秒。如果你把 ffmpeg 当成“导致延迟的元凶”大概率会调错方向。实际处理时我会先测裸延迟直接播放源流再测叠加 ffmpeg 之后的延迟差值才是 ffmpeg 真正贡献的延迟。5. 安装过程中的常见问题与避坑排查5.1 环境变量配了不生效玄学背后是会话缓存现象按照教程把 bin 目录加进 PATH也重启了终端敲 ffmpeg 依然提示找不到命令。 原因Windows 的环境变量修改不会实时同步到已经打开的进程。资源管理器里已经存在的终端窗口会继承打开时父进程的环境变量块。而且有些人用setx命令修改 PATH它默认会把整个 PATH 截断到 1024 个字符导致原有变量丢失后面的路径反而失效了。 解决设置持久环境变量用 PowerShell 的[Environment]::SetEnvironmentVariable方法而不是 setx改完以后务必新开一个终端窗口不放心就连资源管理器一起重启。5.2 报错 error while loading shared libraries缺依赖不是 ffmpeg 的锅现象Linux 上执行ffmpeg -version直接报libavcodec.so.61: cannot open shared object file或者 Windows 上双击后报缺少 DLL 文件。 原因安装的 ffmpeg 二进制文件是用一套依赖编译出来的运行环境里却没有这些动态库。常见于直接把编译机上的二进制文件拷到另一台机器或者下载了需要额外依赖的 shared 版本却只拷贝了 exe。 解决Windows 下优先选 static 构建它把依赖全打进去了Linux 下用ldd $(which ffmpeg)先看缺哪些库再用包管理器补上对应名称的运行时库。还有一种情况是下载的 shared 版本带了 DLL 但没把 DLL 放在 exe 同目录ffmpeg 搜索动态库时找不着——把整个包保持原样解压别只挑 exe 拖出来。5.3 GPL 和 LGPL 选错libx265 直接消失现象转码时指定-c:v libx265报Unknown encoder但ffmpeg -version里看起来配置很完整。 原因ffmpeg 项目本身采用 LGPL 授权但 libx264、libx265 这些编码器库是 GPL 授权把它们编进去之后整个 ffmpeg 二进制文件的再分发就受 GPL 约束。所以官方和非官方构建都会区分 GPL 版和 LGPL 版你下载的是 LGPL 版自然就没有 libx265。 解决下载时确认名称里带gpl字样的版本自己编译时 configure 参数里要有--enable-gpl --enable-libx265。另外注意就算是在 LGPL 版本里libx264有时也被去掉只剩下内置的mpeg4这类编码器所以检查时别只看 H.264把 libx265 也一起确认。5.4 装了 7.x 新版旧脚本却翻车现象照着网上 2020 年的教程写转码命令用-vcodec copy之类的老写法在新版 ffmpeg 上要么报 warning 要么行为变化。 原因ffmpeg 从 6.x 到 7.x 做过不少参数废弃和默认值调整老的教程大多基于 4.x 版本。比如-vcodec虽然还兼容但很多 filter 参数和自动缩放行为已经变了。 解决脚本里尽量用-c:v、-c:a这种现代写法升级版本后先用ffmpeg -h full查你用的参数是否还在列表里。好消息是 ffmpeg 对参数废弃比较保守大多数老命令只是警告还能跑坏消息是这是颗定时炸弹别等到线上任务挂了再回头查版本相容性。5.5 换个终端就找不到 ffmpegPATH 的三种写法坑现象PowerShell 里能跑 ffmpeg切到 CMD 就找不到或者在 VSCode 的集成终端里能跑系统终端里不行。 原因PATH 是分层的用户级和系统级是两个独立变量。如果你把 ffmpeg 配到了用户级 PATH那么只有以当前用户身份运行的进程才能看到如果你在某个终端里手动set PATH过那也只是当前进程临时有效。 解决统一把 ffmpeg 配到系统级 PATH需要管理员权限或者确认用户级 PATH 已设置。在 VSCode 这类集成终端里它继承的是启动 VSCode 时父进程的环境变量所以 VSCode 开着的时候改 PATH 不生效必须重启 VSCode。这个坑很隐蔽排查时先想清楚“哪个进程什么时候启动的”。6. 进阶给 C 封装和 SDK 调用留好后路6.1 安装时就把头文件和库文件的位置记下来如果你不只是用命令行工具还想做 ffmpeg 的 C 封装安装阶段就要多留一个心眼记下头文件、库文件和可执行文件的位置。ffmpeg 提供的是 C 接口封装时需要把 avcodec、avformat、avutil 这些库链接进来。用 pkg-config 是最省事的方式pkg-config --cflags --libs libavcodec libavformat libavutil这条命令会输出编译需要的 include 路径和库链接参数。CMake 里直接用它就行find_package(PkgConfig REQUIRED) pkg_check_modules(FFMPEG REQUIRED libavcodec libavformat libavutil) include_directories(${FFMPEG_INCLUDE_DIRS}) target_link_libraries(your_target ${FFMPEG_LIBRARIES})注意一个很容易踩的坑链接顺序。ffmpeg 的库之间有依赖关系libavformat依赖libavcodec后者又依赖libavutil静态链接时必须按这个顺序写否则报一堆未定义引用。pkg-config 生成的链接参数已经排好序了手动写的时候别打乱。6.2 动态库路径与运行期依赖用 shared 版本做开发时编译通过只是第一步运行时还要让系统找到 DLL 或 so 文件。Windows 上最简单的办法是把 ffmpeg 的 DLL 目录加到 PATH或者在项目输出目录里放一份 DLL。Linux 上则是把库路径写进LD_LIBRARY_PATH或者在链接时用-rpath把绝对路径编进可执行文件。这里我强烈建议用-rpath因为它不依赖部署环境装到别的机器上也能直接跑g your_app.cpp $(pkg-config --cflags --libs libavcodec) -Wl,-rpath,/opt/ffmpeg/lib-rpath写在链接阶段程序启动时动态加载器会优先去这个目录找库这比每次部署都手动设环境变量可靠得多。做 C 封装时还有一个老手提示ffmpeg 的头文件是 C 接口在 C 里引用时必须包extern C不然符号名被 C 编译器做 name mangling 后链接会一堆 undefined reference。这属于第一次做 ffmpeg C 封装必翻车的点。6.3 验证安装的最后一个技巧用 ffmpeg -buildconf 留底最后分享一个我自己的习惯每次安装完 ffmpeg我都会把-buildconf的输出存一份到项目目录里。这条命令打印的是这个 ffmpeg 二进制文件完整的编译配置比-version的信息细得多。它有几个实际用途判断编码器、协议、滤镜是从哪个版本集编译进来的排查“为什么这个编码器在你这儿没有”以及最关键的——当你的代码跑在一个 ffmpeg 版本上你至少能精确知道它编译时开了哪些特性排查兼容性问题时不用猜。ffmpeg -buildconf ffmpeg-build-config.txt这份文件就是你的“后悔药”。以后换版本、换机器、换编译参数拿这份配置一比对就知道差异在哪。我在实际做过一次 ffmpeg 的 C 封装项目后最深的一个教训是ffmpeg 安装的坑大多不在安装本身而在你装的时候有没有搞清楚自己拿到的版本边界——许可证、编码器集合、开发文件齐不齐。安装这一步欠下的债后面每次转码、每次编译、每次部署都会让你加倍还。把这一步做扎实后面的路才顺。希望帮到你。本文还有配套的精品资源点击获取