FFmpeg这个工具，搞音视频的应该没人不知道。每次有人问我“视频转码用什么”“音频怎么抽出来”“HLS切片怎么做”，我基本都是同一句话：FFmpeg，然后顺手甩一条命令过去。但尴尬的是，很多人卡在了第一步——怎么把FFmpeg装起来并跑起来。尤其是跨平台场景，Windows、macOS、Linux各搞一套，再加上Docker这种容器化部署方式，光搜教程就能耗掉半天。这篇文章就把我之前在多台机器上折腾FFmpeg部署与使用的经验整理一遍，从最基础的本机安装到Docker容器化运行，再到高频实操命令和避坑点，一次说清楚。

1. 先搞清楚FFmpeg到底是什么

1.1 一个命令行工具为什么这么火

FFmpeg是一个开源的、跨平台的多媒体处理框架，名字里的“FF”代表Fast Forward，mpeg自然是指MPEG视频编码标准。它能做视频转码、音频转码、视频裁剪、音频提取、视频拼接、推流拉流、屏幕录制、加水印、调色、变速……几乎是音视频处理领域里的瑞士军刀。YouTube、VLC、OBS、B站很多底层处理逻辑都有它的影子。

但它的本质是一个命令行程序，没有自带图形界面。你打开终端，敲一段命令，它就开始干活。这个设计在工程师眼里特别合理——命令可以写在脚本里，可以批量执行，可以放进自动化流程。但在纯小白眼里就有点劝退：打开软件怎么没有窗口？怎么还要输入英文？

我这几年用下来的最大感受是：FFmpeg的学习曲线就是一条命令一条命令堆出来的，你不需要背几百个参数，只需要掌握最常见的十几个组合，并且理解它背后的机制，就能覆盖90%的日常需求。

1.2 为什么安装部署会成为一个问题

FFmpeg的官方源码是放在GitHub上的，绝大多数用户不会去自己编译，而是下载别人编译好的二进制包。问题就出在这里：不同平台的包不一样，Windows下要选build版本，macOS下需要处理签名权限，Linux下可能有静态库和动态库的区分。再加上很多系统里自带的FFmpeg版本很老，功能缺斤少两，想升级又容易牵扯到系统依赖。

所以很多人开始转向Docker部署：一条命令拉取现成镜像，跑在容器里，宿主机只需要有个Docker环境，不需要关心FFmpeg怎么编译、依赖怎么装。这种方式特别适合服务器、持续集成流水线、或者不想污染本机环境的场景。下面我先把本机安装和Docker部署两种情况都讲透，你自己按使用习惯选。

2. 本机安装FFmpeg：Windows / macOS / Linux三平台实操

2.1 Windows下安装FFmpeg：下载、解压、配环境变量

Windows下最常见的安装方式是从gyan.dev或者BtbN下载已经编译好的Windows版本。这两个维护方会定期跟进FFmpeg源码发布版本，提供essential、full、full_build等不同编译选项。日常使用推荐下载full版本，因为它包含了libx264、libx265、libmp3lame、libopus这类主流编码器。

具体步骤如下：

第一步，打开浏览器访问BtbN的GitHub Releases页面，找最新的win64发布版本，下载类似 ffmpeg-master-latest-win64-gpl.zip 的压缩包。如果网络不好，也可以去国内镜像站找。下载后解压到一个固定目录，比如 D:\tools\ffmpeg ，解压后你会看到 bin 、 doc 、 presets 这些子目录，FFmpeg的可执行文件就放在 bin 目录里，包括 ffmpeg.exe 、 ffprobe.exe 、 ffplay.exe 三个程序。

第二步，把 bin 目录路径加到系统环境变量Path里。右键“此电脑”->“属性”->“高级系统设置”->“环境变量”，在“系统变量”中找到Path，点击编辑，新建一行，填 D:\tools\ffmpeg\bin ，保存退出。这一步的目的就是让系统在任意目录下都能直接识别 ffmpeg 命令，不用每次敲完整路径。

第三步，重新打开一个CMD或者PowerShell窗口，输入 ffmpeg -version ，看到版本号输出就说明安装成功。如果提示“不是内部或外部命令”，多半是环境变量没有生效，重新开终端窗口，或者检查路径是否写错。

Windows平台还有一个常见场景是Windows 7。老系统上新版FFmpeg可能因为缺少系统更新而运行不了，这种情况下可以选择下载旧版本，比如热词里提到的 ffmpeg–4.4.8-essentials_build.7z ，这个版本在Win 7上踩坑的概率小很多。解压工具需要支持7z格式，推荐用7-Zip。

注意：Windows下不要直接把ffmpeg.exe放在系统盘根目录或C:\Windows\system32里，那样虽然也能运行，但后续升级维护会很乱，而且容易和其他软件冲突。专门建一个tools目录，统一管理第三方绿色软件才是长远之计。

2.2 macOS下安装FFmpeg：Homebrew一行搞定

macOS用户最幸福的点在于有Homebrew这个包管理器。装FFmpeg只需要一条命令：

brew install ffmpeg

Homebrew会自动处理依赖，把x264、x265、libvpx、fdk-aac这些常见的编解码库一并装好。如果你需要特定版本，可以搜索一下仓库里的历史版本，或者直接使用 brew install ffmpeg@4 这种带版本号的安装方式。需要注意的是，macOS从Catalina开始对未签名的二进制有严格的权限控制，如果你单独下载了第三方编译的FFmpeg包，首次运行时需要在“系统设置->隐私与安全性”里手动允许。用Homebrew安装则完全绕过了这个麻烦。

如果你用的是Apple Silicon芯片的Mac，仍然直接用 brew install ffmpeg 即可，Homebrew会自动安装arm64版本。别自己手动下载x86_64版本的包然后在Rosetta下运行，性能会打折扣。

2.3 Linux下安装FFmpeg：包管理器与源码编译

Debian/Ubuntu系安装很简单：

sudo apt update
sudo apt install ffmpeg

CentOS/RHEL系则稍微麻烦一点，默认源里的ffmpeg可能不全或者不存在，需要先启用EPEL和RPM Fusion源：

sudo yum install epel-release
sudo yum localinstall --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-7.noarch.rpm
sudo yum install ffmpeg

Linux下有一个坑是系统自带的FFmpeg版本偏老。Ubuntu 20.04自带的版本是4.2.x，虽然大部分功能都有，但遇到一些需要新版才支持的滤镜或协议就会报错。这时候有两种方案：一是用静态编译版本，从johnvansickle.com下载，解压后放进 /usr/local/bin ；二是源码编译，下面是常见步骤：

sudo apt install build-essential yasm cmake git libx264-dev libx265-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev
git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
cd ffmpeg
./configure --enable-gpl --enable-libx264 --enable-libx265 --enable-libvpx --enable-libfdk-aac --enable-libmp3lame --enable-libopus
make -j$(nproc)
sudo make install

源码编译最大的好处是可以按需裁剪，最大化利用CPU特性，比如开启 --enable-avx2 这类优化选项。缺点就是耗时，全量编译可能要等十几分钟甚至更久。如果不是对性能有极致追求，或者需要在特殊CPU架构上跑，直接用包管理器和静态版省心得多。

3. Docker部署FFmpeg：从拉取镜像到日常使用

3.1 为什么推荐用Docker跑FFmpeg

说实话，很长一段时间我都觉得FFmpeg没必要上Docker，本机装一个不就行了？后来在团队协作和服务器场景里踩了几次坑，才明白容器化的价值主要体现在三个地方：

第一，环境一致性。团队里有人用Windows、有人用macOS、有人用Linux，本机装的FFmpeg版本可能都不一样，跑出来的结果不完全一致。但如果大家都用同一个Docker镜像，命令和版本完全统一，参数行为一致，排查问题非常方便。

第二，隔离和干净。服务器上很多基础软件依赖OpenSSL、zlib这些库，FFmpeg可能依赖特定版本的libva或libvdpau，折腾来折腾去容易把系统环境搞乱。用容器就完全隔离，镜像怎么折腾都不影响宿主机。

第三，自动化部署。需要定期批量转码、抽帧、切片的话，可以直接把Docker启动命令写进脚本，或者放到Kubernetes的CronJob里，容器用完即走，不残留进程。

当然，容器方案也有代价：启动容器有额外开销，GPU直通配置稍复杂，磁盘IO在特殊场景下可能有性能损耗。但从综合运维成本看，确实是现代部署方式里最省心的方案。

3.2 Windows和macOS上先装好Docker Desktop

在Windows或macOS上要使用Docker，通常需要安装Docker Desktop。Docker Desktop自带Docker Engine、CLI、Compose和图形化界面，装完之后在终端里直接用 docker 命令就行。

Windows上安装Docker Desktop有两个前提：一是Windows 10 64位专业版/企业版/教育版，或者Windows 11（家庭版也是可行的但配置路径略不同）；二是必须启用系统的虚拟化功能，这是因为Docker在Windows上是跑在Hyper-V虚拟机里的。

很多人在启动Docker Desktop的时候会遇到这个报错：“Docker Desktop failed to start because virtualisation support wasn't detected”。这个问题我自己也踩过，大概率是以下三个原因之一：BIOS里没有开启虚拟化、Windows功能里没有启用“虚拟机平台”，或者Hyper-V没有打开。解决方法是：

第一步，重启电脑，在开机时进入BIOS设置（不同品牌按键不同，一般是Del或F2），找到Intel Virtualization Technology或SVM Mode，设置为Enabled。第二步，在Windows里打开“控制面板->程序->启用或关闭Windows功能”，勾选“Hyper-V”和“虚拟机平台”相关选项，确定后重启。第三步，重新启动Docker Desktop。

macOS上安装Docker Desktop相对简单，直接从官网下载dmg安装包拖进Applications文件夹就行。如果是Intel芯片的Mac，Docker Desktop可以基于HyperKit框架跑；Apple Silicon芯片则使用Virtualization.framework，性能和原生差别不大。装完后首次启动可能会要求授权辅助功能权限，放行就行。Docker Desktop在较老的macOS版本上可能无法运行，建议保持系统不要过旧。

注意：Windows家庭版默认没有Hyper-V，但Docker Desktop较新版本已经可以用WSL 2后端来运行，不需要额外安装Hyper-V。只要在“启用或关闭Windows功能”里打开“适用于Linux的Windows子系统”和“虚拟机平台”，然后安装一个Linux内核更新包，一样能跑起来，比Hyper-V更轻量。

3.3 拉取FFmpeg镜像并创建容器

选镜像这块，Docker Hub上有多个FFmpeg镜像，我常用的是 jrottenberg/ffmpeg 和 linuxserver/ffmpeg 两个。

jrottenberg/ffmpeg 是纯FFmpeg镜像，基于Alpine或Ubuntu构建，特点是轻量，适合跑具体的转码任务。但它没有附带复杂的shell环境，文件操作都放在挂载目录里，要靠宿主机来完成。 linuxserver/ffmpeg 是LinuxServer.io团队维护的镜像，它在FFmpeg的基础上增加了文件服务、Web界面、队列管理等功能，更适合需要批量操作和可视化管理的小型服务。

拉取镜像并运行一次转码任务的完整命令如下：

docker run --rm \
  -v /本地路径/输入目录:/input \
  -v /本地路径/输出目录:/output \
  jrottenberg/ffmpeg \
  -i /input/input.mp4 \
  -c:v libx264 -preset fast -crf 23 \
  -c:a aac -b:a 128k \
  /output/output.mp4

这里的 --rm 表示容器运行结束后自动删除，避免堆积大量无用容器； -v 做目录挂载，把宿主机上的输入输出目录映射到容器里，这是Docker跑FFmpeg最重要的机制——容器内部是隔离文件系统，不挂载你就访问不到宿主机的文件。

我用Docker跑FFmpeg的日常操作时，一般会先在本地建一个工作目录，比如 ~/media-work/input 和 ~/media-work/output ，然后把所有视频丢进input文件夹，转码命令统一从宿主机发起。这样脚本里的命令很干净，而且不会误删容器里的文件。

3.4 把Docker FFmpeg封装成本机命令

每次敲这么长一段 docker run 命令确实很烦。一个实用技巧是写一个shell脚本或者配置别名，把Docker FFmpeg封装成和本机 ffmpeg 一样的用法。

Linux/macOS上可以在 ~/.bashrc 或 ~/.zshrc 里加一行：

alias ffmpeg='docker run --rm -v $(pwd):/work -w /work jrottenberg/ffmpeg'

这样你就可以像本机命令一样使用：

ffmpeg -i input.mp4 -c:v libx264 output.mp4

当前目录会被挂载成容器的 /work 工作目录，所以文件名和路径都直接用相对路径就行。Windows上对应的做法是写一个 ffmpeg.bat 批处理文件放在固定目录下，然后把这个目录加进Path：

docker run --rm -v %cd%:/work -w /work jrottenberg/ffmpeg %*

这个批处理里， %cd% 是当前目录， %* 会把后面输入的所有参数透传给容器里的ffmpeg。实测在PowerShell和CMD里都能正常工作。有了这个封装，本机装不装FFmpeg都无所谓了，Docker环境才是真正统一的运行环境。

3.5 进阶场景：GPU转码与多架构镜像

Docker部署FFmpeg还有一个很大的优势，就是可以轻松利用GPU加速。在Linux服务器上如果装了NVIDIA驱动和NVIDIA Container Toolkit，可以直接在 docker run 里加 --gpus all 参数，然后使用FFmpeg的硬件编码器，比如h264_nvenc、hevc_nvenc。

docker run --rm --gpus all \
  -v $(pwd):/work -w /work \
  jrottenberg/ffmpeg \
  -hwaccel cuda -i input.mp4 \
  -c:v h264_nvenc -preset p4 -cq 23 \
  output.mp4

相比CPU转码，GPU转码的耗时能缩短几倍甚至一二十倍，在直播转码、批量切片场景里特别实用。当然， jrottenberg/ffmpeg 这个镜像官方默认构建未必包含全部硬件加速库，建议在NVIDIA官网仓库里找带cuda标签的镜像，比如 nvcr.io/nvidia/ffmpeg 或社区维护的 mwader/static-ffmpeg （它会把很多静态构建的ffmpeg封装好，适合无GPU的通用场景）。

4. FFmpeg命令行核心实操：高频场景与命令拆解

4.1 基本命令语法：先看懂再动手

FFmpeg命令的基本结构可以用一句话概括： ffmpeg [全局参数] -i 输入文件 [输入文件参数] [输出文件参数] 输出文件 。全局参数作用于整个命令，输入文件参数作用于对应的输入流，输出文件参数决定最终输出的编码格式、码率、分辨率等。

理解FFmpeg的命令可以从“它是怎么工作的”这个角度切入：FFmpeg内部有一个解封装和解码管线，先把输入文件解析成一段段原始的音视频数据包，再根据输出参数选择对应的编码器重新编码，最后封装成输出格式。所以输入参数和输出参数是解耦的，你可以用来路是MP4、输出是MKV这样的交叉封装，也可以用H.264编码的输入转成H.265编码的输出。

最简单的转码命令就是：

ffmpeg -i input.mp4 output.avi

这条命令没有指定任何编解码参数，FFmpeg会根据输出文件的扩展名推测封装格式，并自动选择默认的编码器。日常练习可以先从这种命令开始，跑通了再逐步加参数。但实际项目中，你很少会看到这种裸命令，因为不指定码率会默认用编码器内置默认配置，得到的结果往往是文件巨大或者质量不可控。

4.2 视频转码与压缩：让视频体积和画质平衡

最常用的场景就是把一个视频转成H.264编码的MP4，同时控制码率或画质。下面这条命令是我用得最频繁的：

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4

这里 -c:v libx264 指定视频编码器为H.264（libx264）， -preset medium 指定编码速度和压缩率的平衡档位， -crf 23 是质量参数。CRF是libx264的核心概念，范围是0到51，数值越小画质越高、文件越大，23是默认值，视觉上基本无损但文件能小不少。视频压缩这件事没有标准答案，CRF 18~23是非常适合线上传播的范围，CRF 0是无损，CRF 30以后画质损伤肉眼可见。

如果你需要严格控制输出文件大小，可以用 -b:v 指定平均码率：

ffmpeg -i input.mp4 -c:v libx264 -b:v 2000k -c:a aac -b:a 128k output.mp4

这种用法适合上传到平台前做预压缩，把2GB的视频压到几百MB。但需要注意的是，指定码率后画质会波动，遇到运动剧烈的场景可能马赛克感明显，所以优先推荐CRF方案。

4.3 截取视频片段：按时间精准裁剪

FFmpeg截取视频最常用的是 -ss 和 -t 参数。 -ss 指定开始时间， -t 指定持续时间，还能用 -to 指定结束时间。比如提取从第10秒开始、持续20秒的片段：

ffmpeg -ss 00:00:10 -i input.mp4 -c copy -t 20 output.mp4

这里的 -c copy 是直接复制编码数据流，不做重新编码，所以速度极快，也不会损失画质。但有一个细节：把 -ss 放在 -i 前面和放在 -i 后面效果不同。 -ss 放前面时，FFmpeg会先以精确到时间点的方式定位输入文件，然后直接从关键帧开始解码，速度快但时间点可能不是真正的第10秒； -ss 放后面时，FFmpeg会先解码整段视频，再丢弃目标时间点之前的数据，精度高但慢很多。

实际项目中我推荐用第二段精准裁剪配合 -c copy 的做法，虽然速度慢一点但时间点非常准。要避免的坑是裁剪MP4时因为关键帧对齐问题导致开头黑屏几秒，可以通过重新编码解决，即去掉 -c copy 。

4.4 提取音频与转换音频格式

音视频分离是FFmpeg的看家本领，比如从视频里提取MP3音频：

ffmpeg -i input.mp4 -vn -c:a libmp3lame -q:a 2 output.mp3

-vn 表示不处理视频流， -c:a libmp3lame 指定用LAME编码器输出MP3， -q:a 2 是音质等级，范围0到9，数值越小音质越高。要提取无损音频可以将输出编码设为 -c:a flac 或 -c:a pcm_s16le ，保存成FLAC或WAV格式。

音频转换也很常用，比如把WAV转成AAC：

ffmpeg -i input.wav -c:a aac -b:a 192k output.m4a

如果遇到视频里有多个音轨，比如一个中文配音一个英文原声，可以用 -map 参数选择音轨。举个实际例子，如果输入文件有两条音轨，提取第二条音轨：

ffmpeg -i input.mkv -map 0:1 -c:a copy output.aac

0:1 表示输入文件的第1个流的第二个流（FFmpeg是从0开始计数的）， -c:a copy 直接复制音频流不做重编码。

4.5 视频抽帧：按时间点或按秒截取图片

视频抽帧在内容生产里的使用非常频繁，比如做视频封面、生成缩略图、做基于帧的预览。按固定间隔抽帧：

ffmpeg -i input.mp4 -vf fps=1/5 -q:v 2 frame_%03d.jpg

上面这条命令每5秒抽一帧，输出名以 frame_001.jpg 、 frame_002.jpg 这样的格式命名。 fps=1/5 的意思是每秒输出1/5帧，也就是5秒一帧。 -q:v 2 控制输出JPEG质量，数值越高质量越好。如果从视频第10秒开始抽取一张封面图：

ffmpeg -ss 10 -i input.mp4 -frames:v 1 -q:v 2 cover.jpg

-frames:v 1 表示只输出一帧画面。这里用 -ss 放在 -i 前面，快速定位到10秒附近，抽取效率非常高，适合批量生成缩略图。

4.6 视频拼接与GIF动图生成

视频拼接是另一个刚需。如果只是临时拼几个视频，可以用FFmpeg的concat协议：

ffmpeg -i "concat:01.mp4|02.mp4|03.mp4" -c copy output.mp4

这个方式要求这些视频的编码参数完全一致，否则拼接结果会有问题。如果需要更稳定的拼接方案，推荐先创建一个文本清单：

file '01.mp4'
file '02.mp4'
file '03.mp4'

然后执行：

ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4

最后生成GIF也值得一提，很多人问“怎么把视频片段做成表情包”，一条命令就能解决：

ffmpeg -ss 10 -t 3 -i input.mp4 -vf "fps=10,scale=320:-1:flags=lanczos" -loop 0 output.gif

fps=10 控制GIF帧率， scale=320:-1 把宽度缩到320像素，高度按比例适配。帧率越低、分辨率越小，GIF文件就越小。要是生成了超大GIF，可以往 scale 里再压一档分辨率。

5. 常见问题与排查技巧实录

5.1 部署相关：Docker和FFmpeg的兼容性问题

很多人部署完Docker Desktop后启动不了，前面提到过大概率是虚拟化支持没开启。但如果开了BIOS虚拟化还是报错，还有一个常见原因是Windows的“内核隔离”或者说“Device Guard”与Hyper-V冲突。可以在“Windows安全中心->设备安全性->内核隔离”里把“内存完整性”关掉再试试。个人实测，关闭后启动Docker Desktop的成功率提升了一大截。

在Linux服务器上跑Docker容器时，如果遇到“permission denied”之类的权限错误，基本是当前用户不在docker用户组里。把用户加入docker组再重新登录：

sudo usermod -aG docker $USER

这条操作背后的逻辑是让当前用户免sudo直接访问Docker的socket，属于非常基础的运维配置。

FFmpeg容器本身常见的错误是“No such file or directory”，但输入文件其实明明存在。这种大概率是路径问题，挂载目录没对上。解决方案是在命令里用 ls 先确认一下容器内的路径：

docker run --rm -v $(pwd):/work -w /work jrottenberg/ffmpeg ls -la /work

5.2 FFmpeg命令报错：越界、编码器不支持、格式不匹配

• Requested output format 'mp4' is not a suitable output format ：这种一般是你把输出文件扩展名写错了，或者写了一个FFmpeg不支持的格式后缀。检查一下扩展名，改成mp4、mkv、ts这类常见格式。

• Unknown encoder 'libx264' ：这是最常遇到的错误，说明你当前这个FFmpeg版本在编译时没有开启libx264库。解决方法是换一个完整版本的FFmpeg构建，或者在Docker里换用jrottenberg/ffmpeg这类自带x264的镜像。

• Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height ：意思是输出参数不合法。最常见原因是分辨率没设成偶数，H.264/H.265编码要求宽高是偶数，如果你输入的视频分辨率是奇数，加一个 -vf scale=trunc(iw/2)*2:trunc(ih/2)*2 再输出就能解决。

• Non-monotonous DTS in output stream ：这个警告一般出现在转封装或拼接时，原因是时间戳出现了非递增情况。多数情况下没有实际影响，但如果输出的视频在播放器里拖动进度条有异常，就需要重新编码一次，或者在拼接时使用 -fflags +genpts 重新生成时间戳。

5.3 实操心得：版本、硬件加速和批处理

版本管理是我最想强调的一个点。很多人装了Docker之后彻底放弃了本机FFmpeg，这没有错，但建议在脚本里固定镜像版本，比如 jrottenberg/ffmpeg:5.1.1-ubuntu ，不要用最新标签。镜像一旦升级，底层库和命令行行为可能有细微变化，导致线上批量任务结果不一致。固定版本后整个流水线非常稳定，这也算是容器部署最基本的素养。

硬件加速这一块，如果你经常做转码任务，一定要把GPU用起来。当前支持NVIDIA GPU的FFmpeg编码器有h264_nvenc、hevc_nvenc等，Intel核显对应的是h264_qsv，AMD显卡对应h264_amf。举个例子：

ffmpeg -i input.mp4 -c:v h264_nvenc -preset p4 -cq 23 -c:a copy output.mp4

在Docker环境里要用GPU，前面提过加 --gpus all 即可。Windows上则要在FFmpeg编译时包含nvenc支持，并且安装好对应的显卡驱动。硬件编码器的画质和码率控制相比CPU编码器会有差异，建议先用同一个素材分别用libx264和h264_nvenc各压一遍，对比肉眼画质和文件大小，再决定生产环境用哪个。

批处理这块，脚本一个简单的循环就能搞定几百个文件。比如把某个目录下所有mp4转成h265编码并用原文件名保持：

for i in *.mp4; do ffmpeg -i "$i" -c:v libx265 -crf 26 -c:a copy "${i%.*}_265.mp4"; done

Windows下的PowerShell写法类似，用 Get-ChildItem 加 ForEach-Object 。这套思路配合Docker封装命令，可以很轻松地搭建一个本地批量转码环境，不需要什么重型平台。

6. 部署方案怎么选：本机、Docker还是源码编译

写到最后我想把选择逻辑捋一遍。如果你只是偶尔处理一两个视频，下载一个本机版本，配好环境变量，直接敲命令就够了。Windows推荐用完整版构建包，macOS推荐Homebrew，Linux推荐包管理器或静态构建版。

如果你在团队中工作，或者是需要在服务器上自动化处理音视频，那直接上Docker。Docker方案能让团队成员拿到一模一样的工具链，省去大量“我这边报错你那边正常”的沟通成本。镜像固定版本，脚本统一管理，部署的时候一条命令搞定，回滚也容易。

源码编译这条路，除非你有非常特殊的定制需求（比如指定编译参数、裁剪模块、针对特定CPU优化），否则我不建议日常使用。编译时间是一次性的，但后续每次升级都要重新编译，维护成本比较高。我在自己的服务器上用过一段时间源码编译，后来换到Docker后发现整个人都轻松了。

根据我个人的实际经验，最推荐的组合是：本机装一个FFmpeg用来临时调试命令，正式业务全部通过Docker跑。本机调试时所见即所得，快速验证命令结果，业务流水线统一走容器化，保证生产环境稳定一致。这两种方式互补，并不冲突。