Ubuntu 上装 ffmpeg 这件事表面看就是sudo apt install ffmpeg一行命令但我在物理机、VMware 虚拟机、WSL 三种环境里前后折腾过十几次几乎每次都会卡在某个意想不到的地方装完发现版本还是老的、libx264编码器死活不在列表里、make跑到一半被系统 Killed、which ffmpeg指向了一个诡异的路径。所以这次我把整个流程重新梳理一遍把「命令」和「为什么这么写」放在一起讲顺便把那些官方文档不会写、但一定会踩的坑标出来。内容主要面向三类人第一次在 Ubuntu 上装 ffmpeg 的新手装完发现编码器不全想重装的老手以及被多版本共存折磨过的运维同学。全篇不需要你预先懂编译原理只要会敲命令、会看报错就能跟下来。1. 三条安装路线怎么选apt、预编译静态包、源码编译在动手之前先明确一件事Ubuntu 上装 ffmpeg 不是一个方案而是三个方案选错了后面全是白工。三条路的差别不在「能不能装上」而在「版本新旧」「编码器是否齐全」「后续好不好维护」这三个维度上。1.1 apt 的版本惰性先搞清楚仓库里到底给你什么apt 这条路最大的优点是干净、可回滚、跟系统其他包不打架。缺点只有一个但很致命版本受发行版冻结策略限制。Ubuntu LTS 的软件仓库在发布时就冻结了主要版本之后只打安全补丁不做大版本升级。粗算下来20.04 大概给你 4.2.x 这个量级22.04 大概是 4.4.x24.04 能到 6.1.x 上下——具体数字别背直接查sudo apt update apt-cache policy ffmpeg这条命令会打印三段信息已安装版本、候选版本Candidate、以及这个候选版本来自哪个源。重点看第三段。如果候选版本来自ppa.launchpadcontent.net之类的第三方源说明你之前加过 PPA而 PPA 这个东西有个特点维护者一旦停更它会在下一次发行版升级时直接卡住你的apt upgrade报一堆依赖冲突。所以看到 PPA 来源心里要有个数。版本够不够用取决于你要干什么。纯做格式转换mp4 转 mkv、提取音频、切片、压缩码率4.4 完全够用甚至 4.2 都够。但如果你要用较新的 AV1 编码器、要用libsvtav1、要跑一些新版本才有的滤镜比如libplacebo相关、一些新的 tone mapping 实现那 apt 版本就很难受。我自己踩过一次脚本里用了某个 5.x 才引入的滤镜参数apt 装的 4.4 直接报No such filter排查了半小时才反应过来是版本问题。另外提醒一个体积问题ffmpeg在 apt 里牵扯的依赖不少最小化安装的服务器上跑一遍可能要下 200MB 到 400MB。如果只是临时用一下可以加参数减少推荐包sudo apt-get install --no-install-recommends ffmpeg1.2 静态构建包最快的路也是坑最隐蔽的路市面上有一批针对 Linux 的静态构建版 ffmpeg下载下来解压里面就三个文件ffmpeg、ffprobe、ffplay不依赖系统里任何共享库拷到/usr/local/bin就能跑。这条路的好处是快五分钟搞定而且版本通常很新坏处是它和系统里的其他多媒体库完全隔离。有几个坑要提前说清楚。第一静态包分「精简」和「完整」两种口味精简版通常不包含libx265、不包含libfdk-aac这类授权有争议的组件完整版才有。你下载的时候如果不看说明回头发现 HEVC 编码用不了会以为是安装出了问题。第二Windows 上那套ffmpeg-x.x.x-essentials_build.7z是给 Windows 用的可执行文件千万不要解压后拷到 Ubuntu 上试图运行Linux 不认 PE 格式报错是cannot execute binary file: Exec format error反过来 Linux 的静态包拷到 Windows 也跑不起来。第三静态包无法通过 apt 管理你要升级只能手动替换文件时间长了容易忘记自己装过。我的建议如果你是临时用、跑在容器里、或者需要版本足够新又不想编译静态包是最优解如果是长期使用的生产机器还是走 apt 或源码。1.3 源码编译适合谁明确需求再动手什么情况下值得花二三十分钟编译一遍我总结了三类一是需要 apt 仓库拿不到的特定编码器组合比如同时要libx265和libsvtav1和libfdk-aac二是需要精确控制编译选项比如裁掉不用的组件做小体积镜像三是需要开启某些默认不编进去的功能典型的是硬件加速相关的模块。源码编译的代价也很明确首次编译耗时、依赖容易缺、升级要重来、卸载不完全干净。所以我的原则是「能不编就不编」确定要走这条路之后把所有依赖一次性装齐别搞成装一个库、跑一次 configure、再装一个库的循环。2. 编译前的依赖清单少一个库就要重来一遍源码编译最耗时间的环节不是编译本身而是 configure 报错后回去补依赖。因为 ffmpeg 的 configure 是逐个探测的它一次只告诉你缺了 A你装上 A 再跑它又告诉你缺了 B。所以正确做法是照着一张完整的表一次性把该装的都装上。2.1 编解码库与 configure 开关的对应关系下面这张表是我自己整理的常用组合左边是 apt 包名中间是对应的 configure 开关右边是用途。注意一个规律库名和开关名不是完全对应的比如libx264-dev对应--enable-libx264但libass-dev对应的是--enable-libass而下划线在 ffmpeg 里也有用到如--enable-libfdk-aac写作--enable-libfdk_aac这块只能靠查别凭感觉写。apt 包名configure 开关用途libx264-dev--enable-libx264H.264 软编最常用GPLlibx265-dev--enable-libx265H.265/HEVC 软编GPLlibvpx-dev--enable-libvpxVP8/VP9 编码WebM 场景libaom-dev--enable-libaomAV1 编码质量好但极慢libsvtav1-dev--enable-libsvtav1AV1 编码速度快很多libmp3lame-dev--enable-libmp3lameMP3 编码libopus-dev--enable-libopusOpus 编码语音首选libvorbis-dev--enable-libvorbisOgg Vorbislibass-dev--enable-libass字幕烧录硬字幕libfreetype6-dev--enable-libfreetypedrawtext 滤镜画文字libfontconfig1-dev--enable-libfontconfig字体自动匹配libharfbuzz-dev--enable-libharfbuzz复杂文字排版新版必装libsdl2-dev--enable-sdl2决定有没有 ffplaylibxcb-dev / libxcb-shm0-dev自动探测屏幕录制相关这张表里有个特别容易被忽略的点ffplay是受libsdl2-dev控制的。很多人编译完发现ffmpeg、ffprobe都在唯独没有ffplay以为是 bug其实就是没装 SDL2。如果你的使用场景全是命令行批处理完全可以不装 SDL2省一个依赖这也是「裁剪编译」的一个实际好处。另一个坑是libharfbuzz-dev。FFmpeg 从 7.x 开始libass和字体渲染相关功能对 harfbuzz 有依赖缺了它 configure 会在后半段突然报字体相关的错误看起来跟 harfbuzz 毫无关系非常隐蔽。2.2 pkg-config、nasm、SDL2 这三个最容易被忽略除了编解码库有三类工具是「意识不到存在、但一定需要」的pkg-configconfigure 靠它找库、nasm 或 yasmx264 等库的汇编优化代码以及 ffmpeg 自身部分汇编需要、构建工具链gcc、make、git 等。nasm 这个坑很典型。ffmpeg 的 configure 脚本对汇编器版本有要求Ubuntu 20.04 自带的 nasm 是 2.14.x某些新版本 ffmpeg 会要求 2.13 以上并且针对特定架构检查指令集支持。报错信息通常是nasm/yasm not found or too old但如果你已经装了 nasm 却还报这个错八成是版本不够。至于 pkg-config它的作用是让 configure 知道「某个库装在哪、头文件路径是什么」。当报错写着ERROR: x264 not found using pkg-config时真正的含义往往是三种之一库确实没装、库装在非标准路径比如自己编到/opt/xxx导致 pkg-config 找不到.pc文件、或者PKG_CONFIG_PATH环境变量没配。排查顺序应该是先pkg-config --modversion x264手动验一下能打印版本号说明库是好的问题在环境变量或 configure 参数上。2.3 一键安装依赖的命令与体积预估把上面这些拼起来我给一条在 Ubuntu 22.04/24.04 上比较稳的安装命令sudo apt update sudo apt install -y \ build-essential pkg-config nasm cmake git \ libx264-dev libx265-dev libvpx-dev libaom-dev libsvtav1-dev \ libmp3lame-dev libopus-dev libvorbis-dev \ libass-dev libfreetype6-dev libfontconfig1-dev libharfbuzz-dev \ libsdl2-dev几个说明cmake我列进去是因为部分新编码库比如某些 AV1 实现用 CMake 构建但ffmpeg 自己不用 CMake这点后面还会讲。git只在你要从仓库拉源码时才需要用 tar 包的话可以去掉。这条命令整体下载量大概 500MB 到 800MB编译安装后占用再加一两个 G跑在小容量云主机上要提前看下磁盘。装完之后强烈建议做一次预检pkg-config --modversion x264 x265 vpx能正常输出三个版本号再往下走 configure能省掉至少一轮往返。3. configure 参数不是越多越好从报错反推开关很多人第一次写 configure 参数的习惯是「把网上搜到的全抄一遍」结果一是编出来的东西臃肿二是里头的错误依赖会让你在编译阶段白白浪费二十分钟。我自己现在的习惯是先跑一个最小可用集看报错再补。3.1 --enable-gpl 与 --enable-nonfree 的边界这两个开关是许可证相关但它们对功能的影响是实打实的。libx264、libx265、libxvid这些库是 GPL 授权ffmpeg 要链接它们必须加--enable-gpl。加了之后你编出来的二进制就受 GPL 约束自用没问题但如果要对外分发需要遵守对应的开源义务。--enable-nonfree则是用来链接 GPL 不兼容的库最典型的就是 AAC 编码器libfdk_aac。它的报错信息长这样ERROR: libfdk_aac is licensed under a nonfree license. Add --enable-nonfree to...。关键点是一旦加了--enable-nonfree编出来的二进制就完全不能再分发了哪怕你只是想自用也建议慎重因为它会和其他组件的授权叠加出麻烦。我的实际做法是绝大多数场景根本不需要libfdk_aac。ffmpeg 内置的原生 AAC 编码器-c:a aac在 128kbps 及以上的码率下和 fdk 的差距听感上很小。所以在编译时我一般不碰 nonfree只在极少数对音质要求苛刻的项目里才单独编一份带 fdk 的版本放在独立目录里跟主版本隔离。3.2 前缀路径怎么定/usr/local 与独立目录的取舍--prefix决定装到哪这是整份 configure 里最值得多花两分钟思考的参数。装到/usr/local默认行为的优点是省事因为/usr/local/bin本来就在 PATH 里装完直接能用。缺点是容易和 apt 装的版本打架——你 apt 装过一份源码又装一份两个二进制抢同一个命令名出问题的时候你会搞不清自己在跑哪个。装到独立目录比如/opt/ffmpeg-7.1好处是干净、可多版本共存、卸载简单删目录就行。代价是要自己配 PATH 和动态库路径./configure \ --prefix/opt/ffmpeg-7.1 \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-libvpx \ --enable-libmp3lame \ --enable-libopus \ --enable-libvorbis \ --enable-libass \ --enable-libfreetype \ --enable-libfontconfig \ --enable-libharfbuzz \ --enable-shared \ --disable-debug--enable-shared是让 ffmpeg 编译出动态库libavcodec.so这些而不是把所有东西静态链进可执行文件。动态库的好处是多个程序可以共用坏处是运行时必须能找到库文件。如果装在非标准路径就得在/etc/ld.so.conf.d/下加一个 conf 文件把lib目录写进去然后跑sudo ldconfig刷新缓存。忘了 ldconfig 是新手最常见的错误症状是运行 ffmpeg 时报error while loading shared libraries: libavcodec.so.xx: cannot open shared object file。3.3 configure 结束后必须扫的那几行输出configure 跑完会打印一大段清单分块列出 enabled 和 disabled 的组件。这一段千万不要直接翻页跳过它就是你这次的编译成果说明书。我会重点扫三块Enabled encoders里有没有libx264、libx265Enabled filters里有没有ass、subtitles、drawtextExternal libraries那一行有没有libx264、libass这些看到External libraries:后面是空的或者缺项就说明某个库没被检测到但 configure 不会因此停下来报错——它只是安静地跳过。这就是「编译成功但功能缺失」的根源比编译失败更恶心因为你要到用的时候才发现。最后还有一个保险动作configure 在遇到真正的致命错误时详细信息会写进ffbuild/config.log老版本是config.log。报错信息里那行简短提示经常看不懂直接去 config.log 里搜error附近的内容能看到编译器原话比如缺哪个头文件、哪个符号找不到一目了然。提示configure 阶段产生的config.log会被下一次 configure 覆盖遇到难题时先把它复制一份再重跑。4. make 阶段的真实状况Killed、卡死与增量重编configure 通过之后就是make这一步通常很顺但一旦出问题就是「看起来毫无理由」的那种。4.1 internal compiler error: Killed 九成是内存如果你在编译到某个大文件时突然看到gcc: internal compiler error: Killed (program cc1)不要怀疑代码有问题9 成是内存不够被系统的 OOM Killer 干掉了。这是我在 1GB 内存的虚拟机上踩过好几次的坑。解决方案有两个按优先级排先把并行度降下来make -j1或者make -j2如果单线程也过不去就临时加一块 swapsudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile编译完再sudo swapoff /swapfile sudo rm /swapfile删掉。WSL 环境下还有个额外注意点WSL2 默认只分配宿主机一半内存如果你宿主机本身内存就不大编译时更容易触发这个错误可以在用户目录下的.wslconfig里手动限制一下内存上限和 swap 大小比直接 OOM 好排查。4.2 编译时间预期与 -j 的取值时间预期给你一个参考4 核机器开-j4带上面那套依赖大概 10 到 20 分钟8 核开-j8大概 5 到 10 分钟单核老老实实编半小时到一小时。-j的取值不是越大越好建议不超过物理核心数超了以后 CPU 抢占会拖慢整体速度同时在内存紧张时更容易被 Killed。我一般用make -j$(nproc)如果内存小于 2G 就手动写-j2。另一个实用技巧make是增量的。如果你只是改了几个 configure 参数、或者补装了一个库重新跑./configure之后再make已经编译过的目标文件不会重编速度会快很多。所以调参阶段不要动不动make clean那是自找麻烦。4.3 关于 cmake 的误会搜索 Ubuntu 编译相关问题时经常会刷到用 cmake 编译 ffmpeg 的教程。这里必须说清楚FFmpeg 从来不用 CMake它用的是自己那套手写的 configure 脚本加 make。它的构建系统是./configure生成config.mak和ffbuild/目录然后由顶层 Makefile 驱动。你在 ffmpeg 源码根目录下是找不到CMakeLists.txt的。那 cmake 什么时候用得上是你编译依赖库的时候。比如某些 AV1 编码器的新版本、某些硬件加速相关的辅助库它们自己用 CMake。所以正确的分工是依赖库用 cmake或者它自己的 configure编ffmpeg 本体用./configure make。我见过有人给 ffmpeg 写了一份 CMakeLists结果编出来缺一堆组件还在找原因纯属给自己加难度。5. 装完之后 ffmpeg 到底在跑哪一个多版本共存排查「装是装上了但好像没用」是多版本场景里最典型的症状。这时候别急着重新编译先把「现在跑的是谁」查清楚。5.1 which -a / type -a / hash -r 三板斧第一步永远是这三条命令which -a ffmpeg type -a ffmpeg hash -r ffmpeg -version | head -n 1which -a会把 PATH 里所有同名的可执行文件按顺序列出来排在第一位的才是实际被调用的那个。type -a类似但还会告诉你这是别名、函数还是文件信息更全。hash -r是清掉 bash 的命令路径缓存——这里有个非常隐蔽的坑bash 在第一次执行某个命令后会把它的绝对路径缓存起来如果你在同一个终端里刚装完新版 ffmpeg直接敲ffmpeg很可能还是跑旧的因为缓存没刷新。新开一个终端或者执行hash -r问题就消失了。这个坑我自己遇到过两次第一次排查了十几分钟。ffmpeg -version的第一行是版本号后面一行会有configuration:开头的内容这就是编译时的参数列表。想确认某个编码器是不是真编进去了看这行最准比看which靠谱得多。5.2 WSL 里的隐形杀手Windows 那边的 ffmpeg.exeWSL 环境有一类独有故障我第一次碰到时完全懵了在 WSL 里敲ffmpeg报错是cannot execute binary file: Exec format error或者干脆输出了 Windows 风格的路径。原因是WSL 默认会把 Windows 的 PATH 追加到 Linux 的 PATH 后面如果你 Windows 那边装过 ffmpeg比如解压了那个 essentials build 并且加了环境变量which -a ffmpeg就能看到一条/mnt/c/...开头的路径。这个问题有两种解法。临时的办法是在~/.bashrc里重新拼一次 PATH把/mnt/相关的路径剔掉。彻底的办法是在/etc/wsl.conf里关掉 PATH 追加[interop] appendWindowsPath false改完执行wsl --shutdown重启 WSL 生效。关掉之后 Windows 那边的命令行工具在 WSL 里就调不到了这是一个取舍——如果你经常在 WSL 里调 Windows 的工具就用第一种局部过滤的方式。顺带一提WSL 里还有一类「看不见的 ffmpeg」Python 的imageio-ffmpeg会在缓存目录里放一份自带的 ffmpeg 二进制moviepy这类库默认就用它。所以你明明在系统里装了新版跑 Python 脚本时表现却不一样八成是被这类自带二进制劫持了。排查思路是打印出实际调用的路径而不是盲猜。5.3 /usr/local 与 /usr/bin 的默认优先级在标准 Ubuntu 上默认 PATH 的顺序里/usr/local/bin排在/usr/bin前面。也就是说源码编译装到/usr/local的版本会自动压过 apt 装的版本不需要额外配置。这个行为在有意识的时候很方便在无意识的时候很误导——你会以为自己已经卸载了 apt 版本其实它还在只是被遮住了。想要确认用dpkg -l | grep ffmpeg看有没有 apt 包然后dpkg -L ffmpeg | head看它装了哪些文件。如果两者都在而你又不想手工删最省事的做法是做一次显式的卸载sudo apt remove ffmpeg把 apt 那一层清掉让源码版本独占命令名。6. 功能自检确认编码器、滤镜、硬件加速真的可用编译通过、命令能用不等于功能齐全。装完一定要跑一次自检这套检查我现在已经写成固定动作了。6.1 buildconf、encoders、hwaccels 三条命令ffmpeg -hide_banner -version | sed -n 2p ffmpeg -hide_banner -encoders | grep -E libx264|libx265|libvpx|libsvtav1 ffmpeg -hide_banner -filters | grep -E subtitles|ass|drawtext ffmpeg -hide_banner -hwaccels第一条看编译参数如果你的版本支持-buildconf也可以用ffmpeg -buildconf。第二条确认编码器注意列表里除了libx264之外还会有一个h264相关的原生软件编码器两者不是一回事libx264才是有实际使用价值的那一个。第三条看滤镜做字幕和画文字的场景必须确认subtitles、ass、drawtext都在。第四条列出编译进二进制的硬件加速后端但注意这只说明「支持」不代表「能用」下一小节细说。如果发现某个编码器缺失别急着重编先回到第 3.3 节看 configure 输出再看ffmpeg -version的 configuration 行里对应的--enable-xxx在不在。参数在但编码器不在那就是依赖没被检测到。6.2 拿一段真实素材跑转码验证查列表只是静态检查真正靠谱的验证是转一段真素材。我用下面这几条命令做冒烟测试覆盖视频编码、音频处理、流复制三个典型场景# 1. 视频转码 音频转码最常规的组合 ffmpeg -hide_banner -i input.mp4 \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -movflags faststart output.mp4 # 2. 只调音量视频流直接复制速度极快 ffmpeg -hide_banner -i input.mp4 \ -af volume1.5 -c:v copy out_louder.mp4 # 3. 精确裁剪 10 秒-ss 放 -i 后面是精确解码定位 ffmpeg -hide_banner -i input.mp4 -ss 00:01:30 -t 10 -c copy clip.mp4第 2 条里的音量和第 3 条里的裁剪特别值得一提。调音量有两种写法volume1.5是倍数volume3dB是分贝两者等价关系是倍数 10^(dB/20)所以 3dB 约等于 1.41 倍。但直接乘大倍数会削顶爆音因为采样值超过上限后被硬截断听起来会破。稳妥的做法是配合限幅器比如-af volume3.0,alimiterlimit0.95或者干脆用dynaudnorm做动态归一化。这个坑我是做播客素材处理时踩的当时以为是源文件有问题换了三次素材才反应过来。第 3 条的关键是-ss的位置。放在-i前面ffmpeg 会先跳到最近的关键帧再开始解速度快但起点有偏差放在-i后面ffmpeg 从头解码到指定时间点精确但慢。配合-c copy做无损裁剪时-ss放前面基本是唯一可行方案因为流复制没法做非关键帧的切割。下面这张表是我整理的高频报错对照遇到问题先在这里找一遍能省不少搜索时间报错信息根因处理方式Unknown encoder libx264编译时没开 libx264或 PATH 指向旧版本查 buildconf查 which -aERROR: x264 not found using pkg-config缺 libx264-dev 或 PKG_CONFIG_PATH 未配装库后重跑 configuregcc: internal compiler error: Killed内存不足被 OOM 杀掉降 -j 或加 swapcannot execute binary file: Exec format error调到了 Windows 的 exe检查 PATH 里的 /mnt/ 路径error while loading shared libraries动态库路径没注册ldconfig 或配 ld.so.conf.dNo such filter: subtitles缺 libass 或对应开关未启用补依赖重编Cannot load libva / No VA display found环境没有可用的 GPU 渲染节点虚拟机里基本无解见下节6.3 虚拟机里谈硬件加速的现实情况最后单独说硬件加速因为这块的期望管理特别重要。ffmpeg -hwaccels列出来的后端vdpau、cuda、vaapi、qsv、drm分两种状态编进二进制了和当前环境真的能用。前者只是「这个后端的代码在里面」后者还需要驱动、内核模块、设备节点全部就位。判断能不能用的最直接办法是看设备节点。Intel 核显走 VAAPI 需要/dev/dri/renderD128NVIDIA 走 NVENC 需要驱动装好且nvidia-smi能正常输出这些在 VMware 或 VirtualBox 的默认配置下通常都不存在因为虚拟机的显卡是模拟设备没有对应的媒体引擎。硬要试的结果就是Cannot load libva或者Device creation failed。我的建议很直接虚拟机和 WSL 里不要指望硬件加速老老实实用libx264 -preset veryfast这类软编参数。真要上硬件编码得是物理机 驱动 正确的 ffmpeg 编译组合NVENC 还需要注意驱动版本和 ffmpeg 版本的匹配——驱动太老会导致 NVENC 初始化失败报错通常是Cannot load libnvidia-encode.so.1这时候更新驱动比重新编译 ffmpeg 更有效。7. 卸载与回滚把系统恢复到干净状态装得乱、卸载更乱是源码编译最让人头疼的地方。所以最后一部分专门讲怎么收场这也是我踩过最多的区域。7.1 apt 装的怎么卸干净apt 这条路最简单但要注意「卸载」和「清配置」是两回事sudo apt remove ffmpeg sudo apt purge ffmpeg # 连配置文件一起清 sudo apt autoremove # 清理自动装上、现在没人用的依赖remove只删二进制和库配置文件还留着purge会一并清掉。autoremove这一步很有价值apt 装 ffmpeg 时拉进来的一堆依赖库在 ffmpeg 被删后往往就没人用了留在系统里纯占地方。如果之前加过第三方 PPA还要额外清理sudo add-apt-repository --remove ppa:你要移除的源 sudo apt update忘了移除废弃 PPA 的后果是将来系统升级时 apt 会因为拉不到那个源的索引而报错新手很容易被这类报错吓到其实原因就是几年前的某个 PPA 已经停更。7.2 源码装的 make uninstall 与手工清理清单源码编译留了make uninstall这个目标但它有三个前提条件源码目录还在、当时的 configure 参数没变、当前用户有权限删安装目录。只要其中一个不满足它就废了。参数变了以后再跑make uninstall删的文件清单就跟当初装的对不上会留下残留。所以我更推荐记一份手工清理清单。装在默认/usr/local的话需要删的东西大概是这些sudo rm -f /usr/local/bin/ffmpeg /usr/local/bin/ffprobe /usr/local/bin/ffplay sudo rm -f /usr/local/lib/libav*.so* sudo rm -f /usr/local/lib/libsw*.so* sudo rm -f /usr/local/lib/libpostproc*.so* sudo rm -rf /usr/local/include/libav* sudo rm -rf /usr/local/include/libsw* sudo rm -rf /usr/local/include/libpostproc sudo rm -rf /usr/local/share/ffmpeg sudo ldconfig删完之后务必跑一次sudo ldconfig否则动态链接器缓存里还记着那些已经不存在的库路径后续其他程序加载时可能报出莫名其妙的错误。清理完再用which -a ffmpeg和ldconfig -p | grep libav双重确认一遍两边都没输出才算干净。7.3 多版本并存的折中方案如果你经常需要在不同 ffmpeg 版本之间切换——比如老项目要用 4.4 的行为新项目要用 7.x 的功能——那最舒服的做法是每个版本一个独立目录不往系统路径里塞/opt/ffmpeg/4.4/bin/ffmpeg /opt/ffmpeg/7.1/bin/ffmpeg然后在脚本里显式写全路径或者写一个小的切换函数放在 shell 配置里。这种方式的额外好处是卸载极其干净——rm -rf /opt/ffmpeg/4.4就完事了不存在残留问题。代价是每个版本都要单独编译一次磁盘占用会上去一个完整版本连库带二进制大概 1GB 上下。这套做法我在处理历史素材批处理时用过一段时间体会是前期多花的半小时编译时间会在后面省掉无数次「这个行为怎么和昨天不一样」的困惑。相比每次都靠改 PATH 来切版本独立目录的方式在排查问题时能立刻排除版本干扰这个价值比省那点磁盘空间重要得多。最后再分享一个我用了很久的小习惯每次源码编译装完之后把ffmpeg -version的完整输出存一份到/opt/ffmpeg/版本号/buildinfo.txt。过半年再回头查「当时到底开了哪些开关」这份文件就是唯一可信的答案比翻历史命令记录靠谱得多。