企业官网建设流程全解析

简介：面向64位Windows平台的FFmpeg开发者版本，构建于2019年2月，对应Git提交7e4d3db，适用于需要在C或C++项目中集成音视频编解码、转码与滤镜处理能力的开发者。资源包共165个文件，压缩后仅614KB，包含114个头文件、23个C示例源文件，以及8个lib、8个a、8个def链接库文件，另附readme与makefile，可快速完成开发环境配置和库链接；其中头文件用于接口声明，C示例帮助快速上手，lib与a文件供静态或动态链接，def文件则用于生成导入库。当前已有162人学习下载。包内提供libavcodec编码库、libavformat容器格式库、libavfilter滤镜库、libavutil工具库等核心模块的接口定义与实际编译产物，开发者可调用H.264、VP9、AAC、Opus、AV1等编解码能力，也可参照内置示例编写转码、剪辑、封装与滤镜处理逻辑。与稳定版相比，dev版更新更频繁，带有实验性特性和最新修复，适合在测试环境探索新API与GPU硬件加速支持；生产环境部署前需仔细验证稳定性。 做视频处理这块时间长了，基本绕不开 FFmpeg。我最近一次折腾，直接用上了 ffmpeg dev 最新版——项目里接到一批新设备录制的视频，编码格式比较新，手头稳定版 FFmpeg 解码失败，提示 Unknown decoder。查了一圈才发现，这个编码器在 FFmpeg 的 master 分支（也就是 dev 版）里才刚合入。如果你也遇到类似需求，想用最新编码器、最新滤镜、最新协议支持，又不知道该不该用 dev 版，这篇东西正好可以给你一套从下载安装到日常命令的完整参考。内容不照抄官方文档，是我自己在 Windows 和 Linux 上实际折腾过之后的总结，踩过的坑都会明说。

1. 为什么我会盯上 ffmpeg dev 版

FFmpeg 的发布节奏很多人不太清楚，先理清概念。你从官方 ffmpeg.org/download.html 下载的"release"版本，对应的是 git 仓库里打了 tag 的分支，大概每隔几个月到半年出一个稳定版，现在常见的是 6.x 和 7.x。而 dev 版（也叫 git master、开发版、每日构建）是仓库 master 分支每天自动构建出来的产物，版本号长这样：N-118832-g4a5e30f 或者 7.0-dev。用手机系统来类比的话，release 是正式版，dev 是每天刷新的开发者预览版，功能最新，偶尔带点小毛病。

什么场景必须用 dev 版？我自己遇到最典型的是三种。第一种是设备厂商用新编码格式出片，比如运动相机、无人机拍的视频，用了刚合入主线的编码扩展，release 版解码器还不认识，只有 dev 版能解。第二种是新协议或者新滤镜，比如要处理 HLS 里某个新变种、要试某个刚发布的滤镜效果，release 版根本没有这个参数。第三种是 bug 修复，官方仓库的 issue 里经常能看到"这个问题已在 master 修复，请等下一个 release"，如果你正好被这个 bug 卡住，下载一个当日 dev 构建是最直接的办法。

反过来，生产环境如果不追求新功能，还是老老实实用 release 版。dev 版改动比较大，个别滤镜参数名会变，某些旧的 -vf 写法会报 deprecation warning，甚至行为变化会直接导致输出结果不一样。如果你维护的是长期跑批的脚本，不建议直接拿 dev 版替换。

2. 安装与 PATH 配置：Windows 和 Linux 两条路我都试过

2.1 Windows 下选构建站点

Windows 上没有统一包管理器，大家一般去 gyan.dev 或者 BtbN/FFmpeg-Builds 这两个渠道下载。gyan.dev 是 FFmpeg 官方列出的 Windows 构建站，页面里有一个 ffmpeg-master-latest-win64-gpl.zip，这个就是每天更新的 dev 构建。BtbN 这个 GitHub 仓库也有 win64 的 dev 构建，在 releases 页面里找 tag 为 latest 的 asset 就行。

这里有个容易踩的坑：dev 构建也分带不带 libfdk_aac 这类非自由编解码库。很多直播推流场景想用 fdk_aac 编码，虽然 FFmpeg 自带原生 aac 编码器也能编，但码率控制不如 fdk_aac 稳定。gyan.dev 的 gpl 构建通常不带 fdk_aac，需要找 nonfree 标识的构建。我在这上面栽过：下载了 gpl 版，命令里写 -c:a libfdk_aac，结果报 Unknown encoder，换成带 nonfree 的构建就好了。

解压后，bin 目录里应该有 ffmpeg.exe、ffprobe.exe、ffplay.exe 三个程序。很多人会漏掉把 bin 目录加到系统 PATH 这一步。操作路径是：系统属性 -> 环境变量 -> Path -> 新建，把解压后的绝对路径填进去。然后重开一个终端，输入 ffmpeg -version，能看到编译日期和版本号就说明成功了。ffplay.exe 就是常说的"ffmpeg 播放器"，一个极简的命令行播放器，日常快速预览视频非常好用。

2.2 Linux 下的快速安装和源码编译

Linux 上如果只是临时用，下载静态构建是最省事的。比如 CentOS 7 这种老系统，自带源里没有 ffmpeg，RPM Fusion 源配置又麻烦，我一般直接从 johnvansickle.com 拉一份静态构建：

wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz tar xf ffmpeg-release-amd64-static.tar.xz cp ffmpeg-amd64-static/ffmpeg ffmpeg-amd64-static/ffprobe /usr/local/bin/

这里要说明一下，johnvansickle 的构建偏稳定版，和 dev 版不是一个东西。如果你想要 Linux 下的 dev 构建，可以看 BtbN/FFmpeg-Builds 仓库里的 linux64 静态构建。CentOS 7 上跑静态构建没有依赖问题，因为是静态链接，这一点对老服务器很友好。顺便说一句，如果项目里明确要求 FFmpeg 3.4 这种历史版本，那就直接找对应版本的 static 构建，别用 dev 版也别随便升级，老版本行为稳定，适合线上长期跑。

如果非要自己编译 dev 版，源码拉下来之后的常规套路是这样：

git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg ./configure --prefix=/usr/local/ffmpeg --enable-gpl --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-nonfree --enable-libfdk-aac make -j$(nproc) make install

编译的坑全在依赖库。缺了 libx264 的 dev 包，configure 会直接报 ERROR。Ubuntu 上要提前 apt install libx264-dev libx265-dev libmp3lame-dev libopus-dev libfdk-aac-dev。CentOS 7 上这些包不全还得自己编依赖，所以我个人在服务器上很少选择源码编译，静态构建至少省下一半事。

3. 高频命令逐个拆：转码、截图、合并、推流

3.1 关于 -y 和几个全局参数

ffmpeg -y 的作用是自动覆盖输出文件，不加的话，如果输出文件已存在，命令会停下来问你要不要覆盖。很多新手第一次跑命令看到 [y/N] 卡住，不知道在等什么。和 -y 相对的是 -n，表示输出文件存在就直接失败，适合脚本里防止误覆盖。另一个容易混淆的是 -i，它后面跟输入文件，一个命令里可以有多个 -i。常见规范写法是把 -y 放在最前面：

ffmpeg -y -i input.mp4 output.mp4

有的文档写成 ffmpeg -i input.mp4 -y output.mp4 也能跑，但全局参数放在最前面更符合惯例，也能一眼看出这个命令允不允许覆盖已有文件。

3.2 截图：-ss 和 -frames:v 的顺序很重要

截取视频某一帧的画面，最常用命令是：

ffmpeg -ss 00:01:30 -i input.mp4 -frames:v 1 -q:v 2 frame.jpg

-ss 放 -i 前面是快速 seek，因为 ffmpeg 会直接跳到目标时间点附近的关键帧开始处理，速度快；-ss 放 -i 后面时，ffmpeg 会先解码这个时间点之前的所有帧再输出目标帧，精确但慢。对绝大多数截图场景，我推荐把 -ss 放前面，速度快且位置基本够准。

-frames:v 1 等价于老写法 -vframes 1，意思是只输出一帧。如果不加这个参数，ffmpeg 会把整个视频的每一帧都输出成图片，命令根本停不下来。热词里提到"截图时加了 -vframes:v 1 还是报 the specified filename..."，多半是脚本把整个命令当成字符串整体传给 ffmpeg 了。尤其在 Java 的 ProcessBuilder 或 Python 的 subprocess 里，空格和引号处理不当，ffmpeg 会把 "frame.jpg" 误认为输入文件。解决办法是把参数拆成数组逐个传入，不要拼成一条大字符串。

3.3 合并多个 ts 文件

合并 ts 文件最常用的是 concat demuxer，先写一个文本列表：

file '001.ts' file '002.ts' file '003.ts'

然后执行：

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

-safe 0 是为了允许列表里出现相对路径，不加的话相对路径会被拒绝。这里关键是 -c copy，流复制不重新编码，速度比转码快几倍。但如果这些 ts 文件的分辨率、帧率不一致，-c copy 合并出来可能播放异常，这种情况就得老老实实转码：

ffmpeg -f concat -safe 0 -i list.txt -c:v libx264 -c:a aac output.mp4

目标格式是 mp4 的话，输出文件名直接写 .mp4 就行。转出来如果花屏，多半是原始 ts 来自不同来源，建议先

本文还有配套的精品资源，点击获取