FFmpeg 这东西只要你在 Ubuntu 上碰过音视频早晚都得跟它打交道。转码、切片段、抽帧、合流、压字幕、调音量、做直播推流命令行里几乎所有跟媒体流相关的活儿它都能接。但真正让人头疼的从来不是怎么用它而是怎么把它装明白——我在不同机器上装过不下二十次 FFmpeg从 apt 一键装完却发现没有 libx264 编码器到源码编译卡在 nasm 版本太旧再到改完 PATH 敲ffmpeg还是老版本每一种坑都亲自趟过一遍。这篇就按我实际操作的顺序把 Ubuntu 下安装 FFmpeg 的三条主流路线讲透包管理器直接装、社区静态构建包解压用、源码编译自己编。每条路线适合什么人、具体敲哪些命令、会在哪一步翻车、翻车之后怎么捞回来全部写清楚。刚装完 Ubuntu 的新手可以从第一条路线看起做音视频开发或者需要特定编码器的同学建议直接跳到源码编译那部分——那里才是坑最密集的地方也是最值得花时间的地方。1. 装之前先想清楚你到底需要哪个 FFmpeg1.1 三条路线的取舍对比很多人装 FFmpeg 的第一反应是sudo apt install ffmpeg敲完回车几十秒装完看起来很美好。问题在于这个装完和能用之间隔着一段距离。发行版仓库里的 FFmpeg 是维护者按发行版策略编译的功能开关、第三方库支持都经过裁剪跟你实际想要的可能不是一回事。所以动手之前先花两分钟判断自己属于哪一类需求能省掉后面好几个小时的折腾。我把三条路线整理成一张表对着看就行路线耗时版本新旧功能完整度适合人群apt 直接装1-3 分钟跟发行版走偏旧基础编解码齐全部分第三方库缺失偶尔转个格式、学习命令行的新手静态构建包5 分钟较新相当完整常用编码器基本都有需要开箱即用、不想折腾依赖的人源码编译30 分钟起自己定完全可控想要什么编什么开发、需要特定硬件加速或私有编码器判断标准其实很简单如果你只是想把一段视频转成 MP4、把音频提取出来、给视频加个字幕apt 那条路完全够用犯不上折腾。如果你要接硬件编码、要用 libfdk-aac 这类因为授权问题不进仓库的编码器、或者你写的程序要链接 libavcodec 动态库那就得走源码。静态构建包则是中间地带省事又够用我个人给同事的机器做环境时用得最多的就是它。1.2 为什么发行版仓库里的版本总被人嫌弃先说清楚一件事仓库版本旧不等于不能用。Ubuntu 22.04 LTS 仓库里的 FFmpeg 是 4.4.x 分支24.04 是 6.1.x 分支这两个版本在解码、滤镜、封装格式上都已经相当成熟日常使用一点问题没有。真正的问题出在编译选项上——仓库版本为了规避授权风险默认不开 GPL 和 nonfree 那几组开关。具体来说你会遇到这些现象编码 H.264 时提示Unknown encoder libx264想用 x265 压 HEVC 也不行AAC 音频只能用 FFmpeg 内置的实验性编码器而不是质量更好的那套。这不是装错了是编译时就没开。判断方法很简单ffmpeg -version输出里会有一行configuration:后面跟着一长串--enable-xxx。这行信息比版本号本身重要得多它直接告诉你手上这个二进制到底带了什么能力。我见过太多人对着这行扫一眼就跳过然后花半小时在论坛上找为什么 libx264 找不到其实答案就写在自己屏幕的第一行里。还有一点值得提醒不同 Ubuntu 版本、不同架构amd64 / arm64、甚至不同时间点打的包configuration 都可能不一样。所以别信别人的截图自己敲一遍命令看自己的输出。这是排查一切 FFmpeg 功能问题的起点后面所有章节我都会反复回到这一行。2. apt 路线实战三分钟装完但别急着收工2.1 基础安装与版本体检标准动作就两条命令sudo apt update sudo apt install -y ffmpeg第二条命令会顺带拉进来一堆依赖libavcodec、libavformat、libavutil、libswscale 这些库都在里面。装完之后立刻做三件事which ffmpeg ffmpeg -version apt policy ffmpegwhich ffmpeg告诉你二进制在哪正常情况下是/usr/bin/ffmpeg。ffmpeg -version输出前面提到的 configuration 行重点看有没有--enable-libx264、--enable-libx265、--enable-libvpx、--enable-libmp3lame、--enable-libopus这几个。apt policy ffmpeg则能看出这个包来自哪个仓库、有没有可升级的版本这个信息在你想换源升级的时候特别有用。注意apt policy输出的 Candidate 才是如果现在装会装哪个版本Installed 是你机器上当前装的版本。这两个不一致的时候说明有人可能是你自己之前在别的源装过后面会讲到这种混合状态有多麻烦。如果 configuration 里你要的编码器都在那到这儿就结束了别往下折腾。没有的话再考虑走静态包或者源码。2.2 用第三方源补新版本的正确姿势社区里有一些维护得不错的第三方源专门打包较新版本的 FFmpeg。加源的动作通常是先sudo add-apt-repository再加源然后apt update、apt install。这套流程本身没毛病但有三个坑必须提前知道。第一个坑是依赖冲突。第三方源里的 FFmpeg 往往依赖更新版本的底层库比如更高版本的 libavcodec 或者 libx264而你系统里其他软件尤其是桌面环境、播放器、浏览器可能依赖旧版本。apt 会尝试升级升级完之后某些桌面组件可能直接罢工。我遇到过一次装完新 FFmpeg 之后文件管理器打不开缩略图排查半天才发现是底层库被顶掉了。第二个坑是系统大版本升级。Ubuntu 从 22.04 升到 24.04 的时候第三方源的包通常还没跟上升级过程会因为依赖不满足而中断卡在半路的状态非常难处理。第三个坑最难缠源里某个版本突然撤包。维护者一旦停止维护或者对方服务器挂了你的 apt 会持续报 404每次apt update都刷一屏红字。我的建议是真要加第三方源先做两件事一是apt-mark hold ffmpeg把版本钉住避免它自己乱升级二是记下原始状态出问题时用ppa-purge之类的工具把源干净地摘掉。如果只是想要新版本、不想动系统库那还不如直接用下一章的静态构建包风险小得多。2.3 卸载与依赖清理的坑卸载看着简单实操起来容易留尾巴sudo apt remove --purge ffmpeg sudo apt autoremove --purge第一条删掉 FFmpeg 主包第二条清理不再被需要的依赖。这里有个很多人不知道的点autoremove判断是否需要的依据是依赖关系图如果你之前手动装过 libx264-dev 之类的东西它们不会被清掉会一直留在系统里某天编译别的东西时突然被链接进去造成莫名其妙的错误。清理完之后用这两条命令确认一下战果dpkg -l | grep -iE ffmpeg|libav find /usr/local -name ffmpeg* -o -name libav* 2/dev/null第二条尤其重要——apt 管不到/usr/local目录。所有手动装进去的东西apt 完全不知道它们存在卸载的时候一根手指都不会碰。这就是我明明卸载了 ffmpeg怎么which ffmpeg还有输出这类灵异事件的根源。反过来也一样很多时候你以为装好了新版本其实系统里同时躺着两三个 ffmpeg敲命令时跑的是哪个全看 PATH 顺序。3. 静态构建包路线解压即用但 PATH 这事得说透3.1 选包、校验与解压社区里长期有人维护 FFmpeg 的静态构建包所谓静态是指所有依赖库都被编进了单个二进制里不依赖系统动态库拷到哪儿都能跑。这个特性带来两个好处不会污染系统库删的时候直接删文件就行;不同发行版之间可以通用我在 CentOS 和 Ubuntu 之间来回拷过同一个二进制跑得好好的。选包的时候注意三件事。第一是架构amd64对应 64 位 x86arm64对应 ARM 服务器选错了一眼就能看出来——执行会报Exec format error。第二是授权模式静态包通常分 GPL 版和 LGPL 版前者功能全、编码器多代价是你自己用它做出的产物在分发给别人时要遵守 GPL;后者约束少但功能有裁剪。普通人自己用选 GPL 版就行。第三是校验。下载完先跑一遍哈希sha256sum ffmpeg-release-amd64-static.tar.xz拿输出跟官网页面上的值对一下。这一步看着形式主义但我在内网环境里真的拿到过下载不完整的压缩包解压时报xz: unexpected end of input如果不校验你还以为是解压命令写错了。解压就是标准的 tar 操作tar xf ffmpeg-release-amd64-static.tar.xz cd ffmpeg-*-amd64-static ls目录里会有ffmpeg、ffprobe、ffplay三个主程序和一堆文档。ffprobe是分析媒体信息的ffplay是简易播放器需要图形环境平时用得最多的是前两个。3.2 放进系统目录的规范做法有两种放法选择取决于你要不要 sudo 权限。系统级放法是拷到/usr/local/binsudo cp ffmpeg ffprobe /usr/local/bin/ sudo chmod 755 /usr/local/bin/ffmpeg/usr/local/bin这个目录在绝大多数发行版的默认 PATH 里都排在/usr/bin前面所以它会盖过 apt 装的版本。这个特性是好事也是坑——好处是你不用卸载系统版本也能让新版本生效坏处是下次apt upgrade更新了系统版本你也不知道因为跑的根本不是它。用户级放法是拷到~/.local/binmkdir -p ~/.local/bin cp ffmpeg ffprobe ~/.local/bin/这个目录在较新的 Ubuntu 上默认就在 PATH 里如果没有往~/.bashrc加一行export PATH$HOME/.local/bin:$PATH就行。用户级的好处是完全不需要 sudo卸载就是rm多版本管理也方便——给不同版本起不同的名字放在一起随时切换。3.3 命令哈希缓存改完 PATH 还不生效的元凶这是最经典、最让人抓狂的一个坑值得单独拿出来讲。你把新版本拷进去了echo $PATH也确认顺序没问题但敲ffmpeg -version显示的还是老版本。这时候别急着怀疑人生先敲这一条type -a ffmpeg如果输出里列出了好几个路径说明系统里确实有多份 ffmpeg。但如果你明明把新版本路径排在前面它还是选老的那个那十有八九是撞上了 bash 的命令哈希缓存。原理是这样的bash 每次执行命令时会先在内存里维护一张哈希表记录这个命令上次在哪个路径找到的。这张表存在的意义是加速查找代价是——你用mv、cp、改 PATH 这些方式调整了文件位置之后bash 并不知道它还是会按老地址去找。这个行为在 vim 里也一样很多人改了编辑器版本发现没生效都栽在这上面。解决办法就一条hash -r或者退出当前 shell 重新登录。hash -r清空整张缓存表之后 bash 会重新遍历 PATH 去找。实测下来这一招能解决至少三成的我明明装好了问题。顺手再补一个判断技巧command -v ffmpeg和which ffmpeg都能告诉你最终会执行哪个二进制但type -a能列出所有候选排查多版本冲突时信息量更大。4. 源码编译路线可控性拉满依赖清单先备齐4.1 依赖安装清单与逐个说明源码编译的核心逻辑是FFmpeg 本体只是框架具体能编什么格式、解什么码全靠编译时挂上哪些外部库。所以第一步是把依赖装齐。下面这份清单是我在 Ubuntu 20.04 到 24.04 上反复验证过的包名作用不装的后果build-essentialgcc、make 等基础工具链连 configure 都跑不了pkg-config查找已安装库的编译参数大量库报 not foundnasmx264、x265 的汇编优化编译 x264 时直接失败yasm部分老版本 x264 需要同上二选一但都装上更保险git拉取源码只能手动下 tar 包libx264-devH.264 编码无法用 libx264libx265-devH.265/HEVC 编码无法用 libx265libvpx-devVP8/VP9 编码无法用 libvpxlibmp3lame-devMP3 编码无法用 libmp3lamelibopus-devOpus 音频编码无法用 libopuslibvorbis-devVorbis 音频编码无法用 libvorbislibass-dev字幕渲染字幕滤镜不可用libfreetype6-dev字体渲染字幕烧录会缺字libfribidi-dev双向文字排版阿拉伯语等字幕错乱libfontconfig1-dev字体配置drawtext 滤镜不可用libaom-devAV1 编码无法用 libaom-av1libdav1d-devAV1 解码无法用 libdav1dlibssl-devHTTPS 协议支持无法拉取网络流libv4l-dev摄像头采集v4l2 设备用不了一条命令装完sudo apt install -y build-essential pkg-config nasm yasm cmake git \ libx264-dev libx265-dev libvpx-dev libmp3lame-dev libopus-dev \ libvorbis-dev libass-dev libfreetype6-dev libfribidi-dev \ libfontconfig1-dev libaom-dev libdav1d-dev libssl-dev libv4l-dev这里要专门说一下libfdk-aac。这个 AAC 编码器的音质口碑很好但它不在 Ubuntu 仓库里原因是它的许可条款和 GPL 不兼容Debian 系出于合规考虑不打包。想要用它只能自己先编译 fdk-aac 源码再把它作为依赖传给 FFmpeg。而且一旦开了--enable-nonfree最终生成的二进制就不能再对外分发了这是授权层面的限制心里要有数。还有一个历史悠久的坑nasm 版本。x264 对 nasm 有最低版本要求老一点的 Ubuntu比如 16.04、18.04仓库里的 nasm 太旧configure 会报nasm version 2.x.x found, but 2.13 or greater is required。解决办法是从源码装新版 nasm或者换用 yasm。后来我干脆养成了习惯先跑一遍nasm -v看版本低于 2.13 就先处理它别等到 x264 编译到一半才炸。4.2 configure 参数逐条拆解拿到 FFmpeg 源码之后git clone 或者下 release tar 包都行进目录跑 configure。我平时用的这套参数./configure \ --prefix/usr/local/ffmpeg \ --enable-gpl \ --enable-nonfree \ --enable-shared \ --disable-static \ --enable-pic \ --enable-libx264 \ --enable-libx265 \ --enable-libvpx \ --enable-libmp3lame \ --enable-libopus \ --enable-libvorbis \ --enable-libass \ --enable-libfreetype \ --enable-libfontconfig \ --enable-libfribidi \ --enable-libaom \ --enable-libdav1d \ --enable-libfdk-aac \ --enable-openssl逐条解释为什么这么写--prefix/usr/local/ffmpeg是安装位置。我特意不装到/usr/local根下而是放进一个单独子目录目的是让整个安装可拆卸——想卸载直接rm -rf /usr/local/ffmpeg干净利落不会跟系统里其他东西混在一起。这是我踩过几次装完之后不知道哪些文件是自己装的之后养成的习惯。--enable-gpl是打开 GPL 组件x264、x265 都属于 GPL 范畴不开这个就没法用它们。--enable-nonfree则是给 fdk-aac 这类非自由授权组件开的口子。记住一点这两个开关同时打开产物不可再分发。自己内部用没问题要发给客户就得重新考虑。--enable-shared和--disable-static是一对。前者生成动态库.so文件好处是编译出来的二进制体积小、多个程序可以共享同一份库;代价是运行时必须能找到这些库也就是后面要讲的动态链接器路径问题。如果你只是要一个自包含的命令行工具全静态编译--disable-shared --enable-static反而更省事拷来拷去不用担心库路径。我在这两者之间反复横跳过结论是做开发、要链接 libavcodec 的用 shared;只要命令行工具的静态更省心。--enable-pic生成位置无关代码配合 shared 用链接动态库时必需。在某些 ARM 平台上不加这个直接报重定位错误。剩下的--enable-libxxx就是把前面装的依赖一个个挂上去。注意这些开关写错了不会报错只会在最终 configuration 里默默少一项所以 configure 跑完之后一定要回头看它打印出来的摘要。提示./configure --help的输出非常长但可以用./configure --help | grep enable-lib快速筛出所有跟第三方库相关的开关比翻文档快得多。4.3 编译、安装与动态库路径configure 通过之后就是编译make -j$(nproc) sudo make install-j$(nproc)让 make 用满所有 CPU 核心8 核机器大概 5 到 15 分钟。但这里有个隐藏风险并行编译会同时开多个编译进程每个都很吃内存。在内存 2G 的小虚拟机里-j8极有可能触发 OOM然后 make 会莫名其妙地中断报一个跟内存毫无关系的编译错误。判断方法是在编译失败之后跑一下dmesg | tail -20如果看到Out of memory: Killed process之类的字样那就是内存不够把-j调小或者老老实实单线程编。经验法则是-j的值不超过内存 GB 数的一半。安装完成之后因为是 shared 模式必须告诉系统动态链接器去哪里找新装的库。做法是新建一个配置文件echo /usr/local/ffmpeg/lib | sudo tee /etc/ld.so.conf.d/ffmpeg.conf sudo ldconfigldconfig会重建动态链接器的缓存之后所有程序都能找到/usr/local/ffmpeg/lib下的库。这一步不做的话直接运行/usr/local/ffmpeg/bin/ffmpeg会报error while loading shared libraries: libavcodec.so.xx: cannot open shared object file。这个报错信息其实很直白说的是找不到库但很多人第一次见会以为编译失败了其实编译完全成功只是运行时环境没配。如果你以后要写程序链接 FFmpeg还需要设置PKG_CONFIG_PATHexport PKG_CONFIG_PATH/usr/local/ffmpeg/lib/pkgconfig:$PKG_CONFIG_PATH因为我把 prefix 设成了/usr/local/ffmpegpkgconfig 文件不在标准的/usr/local/lib/pkgconfig里编译器默认找不到。这也正是前面那个依赖清单里pkg-config包的作用——很多项目靠它来定位库的编译参数。4.4 编译报错对照表源码编译的报错五花八门但高频的就那么几个。整理成表格下次遇到直接查报错信息根本原因解决办法ERROR: x264 not found using pkg-config没装 libx264-dev或 PKG_CONFIG_PATH 不对装库或设置正确的 pkgconfig 路径nasm/yasm not found or too old汇编器缺失或版本过低装 nasm 并确认版本 ≥ 2.13ERROR: libfdk_aac not found没装 fdk-aac 或没开 --enable-nonfree先编 fdk-aac再开开关ERROR: libvpx not found缺 libvpx-dev补装即可cannot find -lX11缺 X11 开发包部分滤镜需要装 libx11-dev 等relocation R_X86_64_32 against ...没开 PIC加 --enable-pic 重编C compiler test failed工具链本身有问题检查 build-essential 是否完整Permission denied出现在 make install没用 sudo加 sudo或改 prefix 到用户目录有一个通用排查思路值得记住报错里带 not found 的先去看 FFmpeg 源码目录下的ffbuild/config.log。这个文件记录了 configure 每一步的详细输出包括它到底在哪些路径下找过库、是在哪一步判断失败的。相比在搜索引擎里翻半天直接读 config.log 通常五分钟就能定位问题。5. 装完不算完验证、环境变量与多版本共存5.1 三条命令确认安装质量装完之后别急着用先跑这三条命令做体检ffmpeg -version ffmpeg -hide_banner -encoders | grep -E libx264|libx265|libfdk_aac ffmpeg -hide_banner -hwaccels第一条看版本和 configuration。第二条确认你要的编码器真的存在注意加-hide_banner可以省掉一大段版权信息输出干净得多。第三条列出硬件加速能力如果你装了显卡驱动这里应该能看到cuda、vaapi、qsv之类的条目。再跑一个实际转码测试光有列表不代表能跑通ffmpeg -f lavfi -i testsrcduration5:size1280x720:rate30 \ -c:v libx264 -preset ultrafast -y /tmp/test.mp4这条命令用 FFmpeg 内置的测试信号源生成 5 秒视频再编成 H.264。-f lavfi是虚拟输入设备不需要真实文件特别适合做环境自检。跑通之后ls -lh /tmp/test.mp4看一眼文件大小几 MB 就是正常的。如果这一步报错说明编码器有问题回退去查配置。5.2 环境变量写在哪里才不会翻车PATH 和 LD_LIBRARY_PATH 的配置位置是有讲究的写错了会出现终端里能用、双击图标用不了或者普通用户能用、sudo 用不了这类诡异现象。~/.bashrc只对交互式 bash 生效图形界面启动的程序、systemd 服务、sudo 命令都读不到。如果你只在终端里用 FFmpeg写这里没问题;如果别的程序要调用它就得往系统级位置放。系统级推荐用/etc/profile.d/目录sudo tee /etc/profile.d/ffmpeg.sh /dev/null EOF export PATH/usr/local/ffmpeg/bin:$PATH export LD_LIBRARY_PATH/usr/local/ffmpeg/lib:$LD_LIBRARY_PATH EOF sudo chmod 644 /etc/profile.d/ffmpeg.sh这样对所有登录 shell 生效。注意 LD_LIBRARY_PATH 其实可以通过ldconfig配置更优雅地解决我在 4.3 节讲的/etc/ld.so.conf.d/方式就是系统级的正确做法比塞环境变量更规范而且对 sudo 和后台服务同样有效。还有一个反复踩的坑往 .bashrc 里追加 PATH 时不做判断会导致路径重复累积。每开一个子 shell 就加一遍跑几天之后你的 PATH 能有几百个重复条目echo $PATH刷一屏。养成先判断再追加的习惯case :$PATH: in *:/usr/local/ffmpeg/bin:*) ;; *) export PATH/usr/local/ffmpeg/bin:$PATH ;; esac顺便提醒一下sudo 默认会重置环境变量env_reset所以你在~/.bashrc里设的 PATH 在sudo ffmpeg时是不生效的。要解决就得用sudo -E保留环境或者干脆走/etc/profile.dldconfig的系统级配置。5.3 多版本共存与切换系统里同时存在 apt 版本、静态包版本、自编译版本这在搞音视频的机器上几乎是常态。与其每次改 PATH不如用update-alternatives管理sudo update-alternatives --install /usr/local/bin/ffmpeg ffmpeg /usr/local/ffmpeg/bin/ffmpeg 100 sudo update-alternatives --install /usr/local/bin/ffmpeg ffmpeg /usr/bin/ffmpeg 50 sudo update-alternatives --config ffmpeg第三条命令会列出所有候选版本交互式选择。数字是优先级数字大的是默认。这个机制的好处是切换干净没有 PATH 污染而且update-alternatives --display ffmpeg能一眼看清系统里都装了哪些版本。如果你嫌这套麻烦还有更朴素的办法给不同版本起不同名字。cp ffmpeg /usr/local/bin/ffmpeg-6.1 cp ffmpeg /usr/local/bin/ffmpeg-7.0想用哪个显式敲哪个。脚本里依赖特定版本时这种方法反而最稳——因为不依赖任何环境配置换台机器照样跑。6. 常见问题速查与踩坑清单6.1 那些看起来像没装好的报错有一类报错会让人误以为是安装失败其实跟 FFmpeg 本身毫无关系。最典型的是在 Windows 的 PowerShell 里敲命令收到这么一句ffmpeg : 无法将ffmpeg项识别为 cmdlet、函数、脚本文件或可运行程序的名称这个报错的本质是shell 在 PATH 里找不到这个可执行文件跟 FFmpeg 装得好不好没关系纯粹是环境变量问题。它的原理和 Linux 下的command not found完全一样shell 拿到一个命令名沿着 PATH 列表逐个目录去找同名文件找到就执行找完一圈都没有就报错。搞清楚这个机制这类问题就再也不会让你慌了。在 Ubuntu 上遇到ffmpeg: command not found按这个顺序排查command -v ffmpeg # 有没有找到 type -a ffmpeg # 找到了几个分别在哪儿 echo $PATH # PATH 长什么样 ls -l /usr/local/bin/ffmpeg # 文件在不在有没有执行权限四个命令基本能覆盖九成情况。找不到通常是三条原因文件根本不在 PATH 覆盖的目录里;PATH 里那个目录拼错了多一个空格、少一个斜杠都算;文件没有执行权限。第三个最好判断ls -l一看权限位就知道了。另一类常见报错是版本不对。你明明装了新版但ffmpeg -version显示的还是旧的原因在 3.3 节已经讲过——bash 的命令哈希缓存。hash -r是万能钥匙。还有一类是转码时报Unknown encoder libx264这个不是路径问题而是当前这个二进制的 configuration 里就没有这一项。别折腾环境变量了去查编译选项。6.2 WSL 与虚拟机环境的特殊处理在 WSL 里跑 Ubuntu 装 FFmpeg有两个专属坑。第一个是 PATH 污染。WSL 默认会把 Windows 的 PATH 追加到 Linux 的 PATH 后面或者前面取决于配置结果就是你在 Linux 里敲命令有时候会命中 Windows 那边的 exe 文件。表现是命令能跑但行为诡异或者报一些完全不像是 Linux 程序的错误。解决方法是编辑/etc/wsl.conf[interop] appendWindowsPath false改完在 Windows 侧执行wsl --shutdown重启子系统PATH 就干净了。代价是不能直接敲code、explorer.exe这些跨系统命令了自己在/etc/profile.d里单独加需要的就行。第二个是文件系统性能。WSL 访问 Windows 盘符是通过/mnt/c这类挂载点跨系统的 IO 性能非常差。如果你把源码放在/mnt/c/Users/xxx/下编译那编译时间可能是放在~/下的五到十倍而且有时候会因为文件锁的问题出现权限错误。我的做法是在~/work下建目录编完再拷出来。虚拟机VMware、VirtualBox环境下的坑集中在共享文件夹和资源分配上。共享文件夹通常是vmhgfs-fuse或者vboxsf挂载的默认挂载选项里往往没有执行权限你在里面放个脚本文件chmod x是无效的——因为整个文件系统的权限是挂载时参数决定的跟文件本身没关系。解法要么是重新挂载时指定合适的 uid/gid 和权限选项要么更简单把要编译的东西拷到虚拟机本地的~目录下再操作。资源分配上虚拟机给的内存和 CPU 核心数都有限。前面提过make -j并发过高会触发 OOM在虚拟机里这个风险被放大好几倍。另外虚拟机的磁盘 IO 通常是瓶颈编译大项目时把虚拟磁盘放在 SSD 上体验差别很明显。6.3 几条真正省时间的实操心得折腾了这么多轮有几条经验是我现在每次装环境都会执行的分享出来。第一把 configure 命令存成脚本文件。放在~/scripts/build-ffmpeg.sh里下次换机器或者要重新编译时一行命令跑完。我早期每次都是凭记忆敲参数结果经常漏一个--enable-libfontconfig导致 drawtext 滤镜用不了排查半天才发现是漏写参数。第二装完之后立刻备份二进制。静态包或者自编译的产物打成一个 tar 包存着tar czf ~/backup/ffmpeg-$(date %Y%m%d).tar.gz /usr/local/ffmpeg/bin/ffmpeg环境坏掉的时候解压出来就能用不用重新编译二十分钟。这个习惯救过我好几次尤其是在虚拟机快照回滚之后。第三养成看 configuration 行的习惯。不管什么途径装的 FFmpeg第一件事就是ffmpeg -version | head -3扫一眼配置。这一步只花三秒但能提前发现绝大多数功能缺失类的困惑。我见过太多人在论坛上问为什么我没有某个编码器其实答案就摆在第一条命令的输出里。第四别在/mnt或者共享目录下编译。这条不是技术限制是纯粹的经验——所有我在共享目录下遇到的诡异权限问题、IO 缓慢问题、编译中断问题换成本地目录之后全部消失。多花一分钟 cp 文件省下半小时排查这笔账怎么算都划算。第五给不同的使用场景准备不同的安装。日常转码用静态包就够开发调试用自编译的 shared 版本需要跟系统深度集成的场景用 apt 版本。这三种共存没有任何问题关键是用update-alternatives或者显式命名把它们的边界划清楚别让 PATH 里出现两个不可控的同名文件。最后分享一个真实经历收尾。有一次同事的机器上ffmpeg -version显示的是版本 4.4但ffmpeg -encoders | grep 264又能看到 libx264我一度以为这两个输出对不上是因为工具链有什么玄机。后来用type -a ffmpeg一查系统里躺着三个 ffmpeg/usr/bin/ffmpeg、/usr/local/bin/ffmpeg和/snap/bin/ffmpegPATH 顺序决定了-version显示的是哪个而他之前的 shell 会话里哈希缓存指向的又是另一个。三个二进制来自三条不同的安装路线各自功能不一样混在一起用当然会出各种怪事。把那台机器收拾干净之后我的第一条建议就变成了装之前先看清楚系统里已经有了什么type -a和dpkg -l | grep ffmpeg各跑一遍比事后排查省事得多。