搞视频处理的人迟早会撞上FFmpeg这个命令行工具。你要是没听过它那说明你还没被视频格式、编码、推流这些问题折磨过你要是听过但没用它录过像那这篇内容正好能帮你把“录制”这块短板补上。FFmpeg不是一个图形界面软件它是一整套开源音视频处理库加命令行工具的组合。它最厉害的地方在于几乎所有你能想象到的音视频操作它都能用一条命令完成。录制屏幕、录制摄像头、采集麦克风、定时录像、转码压缩、多视频合并、逐帧导出全都能干。本文就围绕“FFmpeg视频录制”这个具体场景从安装、参数、实操模板到排查问题完整讲一遍我自己的使用经验。这套东西适合谁适合需要批量处理视频的运营同学、需要自动化采集画面的测试工程师、想做简易录屏工具的开发者以及任何不想被商业录屏软件绑住的人。只要你愿意敲命令行它就能给你最大的自由度。1. 视频录制为什么绕不开FFmpeg1.1 一个命令行工具解决所有录制需求市面上录屏软件很多OBS、Bandicam、Camtasia各有各的拥趸。但OBS功能虽强没法在无头服务器上跑商业软件有授权限制没法嵌入你自己的程序里。FFmpeg则完全不同——它没有图形界面没有弹窗一条命令就是一个功能天然适合脚本化、自动化、批量化的场景。拿我自己举例。有一段时间我需要给客户做一轮功能演示录制要求每天早上固定时间自动录下某块屏幕区域的画面再上传到内部服务器。用OBS加插件也能做但折腾计划任务麻烦用FFmpeg只需要一条带定时启动的命令配合Windows任务计划程序或者Linux cron就能稳定跑几个月不宕机。这就是FFmpeg录制最大的特点轻、稳、可编程。它不挑图形环境不依赖显卡驱动面板只要系统能识别到的音视频设备它基本都能采集。实际工作中我用它录过Windows屏幕、Mac的Retina屏、Linux的X11桌面也用过USB采集卡录HDMI信号全都稳定。1.2 录制能力在FFmpeg全家桶里的位置很多人一提到FFmpeg就想到转码忽略了它的采集能力。其实FFmpeg从设计之初就支持多路输入所谓“视频录制”本质就是“把输入设备的数据流经编码器压缩后写入文件或网络流”。录制的底层过程可以拆成三块采集从操作系统获取原始音视频帧Windows走dshowDirectShow、macOS走avfoundation、Linux走v4l2/x11grab。编码原始帧数据量大得惊人1秒1080p不压缩画面可能超过100MB必须用H.264/H.265等编码器压下来。封装写入把压缩后的视频和音频按一定容器格式MP4、MKV、FLV等写入文件或推到流媒体服务器。这三步对应FFmpeg最核心的指令结构ffmpeg -f [输入格式] -i [输入设备] -c:v [视频编码器] -c:a [音频编码器] [输出文件]理解了这个结构后面所有命令都是往这几个位置填参数的事。录制并没有那么神秘真正的难点在于参数选择和排查问题。2. 录制前的准备安装、版本与编解码器选型2.1 三平台安装实操FFmpeg安装并不难难在选对对的包。官方不直接提供Windows二进制文件需要去gyan.dev或BtbN下载编译好的版本。国内开发者也经常通过包管理器安装Windows推荐直接下载gyan.dev提供的full build版本解压后把bin目录加进系统PATH。用winget的朋友也可以直接winget install ffmpeg实测也能用但版本更新速度一般。macOSbrew install ffmpeg会连带安装libx264、libx265等常用编码器比较省心。LinuxUbuntu/Debiansudo apt install ffmpegCentOS/RHEL系建议用EPEL源或直接下载静态编译包因为系统自带的版本往往偏旧。具体到录制场景我最看重的是“输入设备支持是否完整”。Windows下一定要确认你的版本编译进了dshow设备支持否则摄像头和麦克风都采集不到。Linux下则需要确认有v4l2和x11grab。这些模块通常在完整版里都有你下载的时候看一眼列表即可。2.2 GPL和LGPL版本怎么选这是很多人下载FFmpeg时第一个蒙圈的地方。简单说GPL版本可以包含libx264、libx265这类有GPL传染性的库功能全LGPL版本只带核心库和部分宽松许可的编码器适合商业分发时避免GPL协议带来的开源义务。自己用、录个屏、转个码我建议直接下GPL版本功能完整省得漏掉编码器。但如果你是做商业软件想把FFmpeg以库的形式嵌到产品里就得评估LGPL和GPL对你项目的法律影响。这不是技术问题是合规问题值得提前规划。技术选型和法律风险绑在一起考虑是我这几年吃过亏之后的经验。2.3 自己编译还是用现成二进制除非你有非常特殊的需求比如必须用特定芯片的硬件编码器、要定制裁剪体积否则强烈建议直接用现成二进制。自己编译FFmpeg是一件费时费力的事MSVC环境下编译libx265、配置d3d11va等等每一环都可能坑你半天。热搜词里出现的“msvc 编译ffmpeg libx265”就是这个痛点。真需要自己编译时记住一句经验先装好所有依赖库再配configure。比如要libx265你就得先编译安装x265库要硬件编码器就得确保系统SDK版本匹配。看完官网的编译文档再动手能省很多时间。3. 录制命令核心参数拆解把每条指令吃透3.1 输入设备怎么选f参数是起点录制的第一步是让FFmpeg找到输入设备。不同操作系统、不同设备类型用的输入格式都不同平台/场景输入格式示例Windows 屏幕录制gdigrab-f gdigrab -i desktopWindows 摄像头/麦克风dshow-f dshow -i videoUSB CameramacOS 屏幕录制avfoundation-f avfoundation -i 1:nonemacOS 摄像头/麦克风avfoundation-f avfoundation -i 0:0Linux 桌面录制x11grab-f x11grab -i :0.0Linux 摄像头v4l2-f v4l2 -i /dev/video0Windows下查看可用dshow设备可以用这条命令ffmpeg -list_devices true -f dshow -i dummy它会列出所有摄像头和麦克风名称很好用。macOS下则是ffmpeg -f avfoundation -list_devices true -i Linux下摄像头很好确认插上设备后通常对应/dev/video0。屏幕录制的抓取区域则用-video_size 1920x1080 -offset_x 0 -offset_y 0来控制offset是起点坐标默认从左上角开始。3.2 编码器选择软编与硬编的平衡点视频录制绕不开编码器。录制场景里最常用的三个选择libx264H.264软件编码器兼容性最好画质稳CPU占用看机器性能。libx265H.265软件编码器压缩率更高但编码速度慢录制长时间内容时发热明显。硬件编码器Windows上有h264_nvencNVIDIA、h264_qsvIntel核显、h264_amfAMDmacOS上有h264_videotoolbox。硬编几乎不占CPU画质在同等码率下略逊于软编但胜在速度极快。我的通用建议是日常屏幕录制用libx264追求稳定和兼容性长时间无人值守录制用h264_qsv或h264_nvenc硬编降低CPU负载。录制4K高画质内容时硬编的基本够用如果对画质极其挑剔再考虑libx265配合中等preset。硬件加速选项里经常会看到d3d11va和dxva2这两个词它们都是Windows下的硬件解码加速接口。dxva2是老一代API兼容旧显卡d3d11va基于Direct3D 11更现代对新硬件和更高分辨率支持更好。做录制时如果涉及“边解码边转码”这种场景优先选d3d11va单纯的设备采集录制一般不直接用到这两个参数它们是用来解码输入视频的不是用来采集的。3.3 码率、帧率与画质的权衡录制参数里最核心的还有码率。码率太低画面马赛克明显码率太高文件体积暴涨。我的经验参考值1080p 30fps 的屏幕录制静态为主的内容-b:v 2M就够动态画面多一些建议-b:v 4M。4K 30fps 的本地录制建议-b:v 15M起步必要时-b:v 20M。纯讲PPT的会议录制可以降到-b:v 1.5M文件能小很多。更精细的做法是用H.264的CRF模式控制质量——-crf 23是默认值越小画质越好。屏幕录制文本内容较多时我用-crf 20既清晰又不过分大ffmpeg -f gdigrab -framerate 30 -video_size 1920x1080 -i desktop -c:v libx264 -preset veryfast -crf 20 -c:a aac output.mp4等号后面没有指定码率而是用质量模式这样FFmpeg会根据画面复杂程度动态调整码率对屏幕录制这种“长时间静态、偶尔动态”的内容特别友好。3.4 音画同步与延迟控制录制最怕音画不同步。通常是采集延迟和编码耗时造成的。屏幕录制里音频和视频来自不同设备必须以一定时间基准对齐。FFmpeg录制时会在封装阶段打时间戳正常情况下会自动同步但如果你用了-re、-ss这类参数就可能打乱同步逻辑。我的经验是屏幕录制时尽量让音频使用AAC编码封装用MP4或MKV这两个容器对时间戳处理成熟不同步的概率低。另外如果发现音频比视频慢可以给音频输入加-itsoffset 0.5之类的小偏移量手动校正。这个值要反复试牵连因素较多没有绝对真理。延迟问题在推流场景更为敏感。热搜词里提到的“ffmpeg推流到srs存在延迟”就是这样。推流到流媒体服务器时延迟来源包括采集缓冲、编码缓存、网络发送缓冲等。经验做法是用-tune zerolatency降低编码延迟。减少GOP长度-g 30或更小让关键帧频繁出现播放端能更快切入。合理设置-bufsize和-maxrate避免因突发数据量导致缓冲。但注意低延迟和画质本身是矛盾的参数调太激进会牺牲画质要按实际场景找平衡点。4. 我常用的录制模板六组可直接抄的命令4.1 屏幕录制基础版Windows下最基础的屏幕录制ffmpeg -f gdigrab -framerate 30 -video_size 1920x1080 -i desktop -c:v libx264 -preset ultrafast -crf 20 -c:a aac -b:a 128k screen.mp4注意这里没有指定音频输入所以不会录到声音。需要同时录制麦克风时后面再接一路音频输入ffmpeg -f gdigrab -framerate 30 -video_size 1920x1080 -i desktop -f dshow -i audioMicrophone -c:v libx264 -preset ultrafast -crf 20 -c:a aac -b:a 128k screen_with_mic.mp4macOS下的屏幕录制对应为ffmpeg -f avfoundation -framerate 30 -video_size 1920x1080 -i 1:none -c:v libx264 -preset ultrafast -crf 20 output.mkv这里的1:none表示用索引为1的屏幕输入不录音频。4.2 摄像头麦克风录制摄像头录像是很常见的需求。Windows下ffmpeg -f dshow -framerate 30 -video_size 1280x720 -i videoUSB Camera -f dshow -i audioMicrophone -c:v libx264 -preset veryfast -crf 22 -c:a aac -b:a 128k interview.mp4需要留意的是dshow的输入名称必须和-list_devices输出完全一致包括空格。Linux下的摄像头则更简单ffmpeg -f v4l2 -video_size 1280x720 -framerate 30 -i /dev/video0 -f pulse -i default -c:v libx264 -preset veryfast -crf 22 -c:a aac output.mp44.3 定时录制与后台运行这是FFmpeg录制最香的应用场景之一。配合Linux cron或Windows任务计划让它在凌晨录直播流、定点录课程都很方便。Linux下cron示例30 8 * * 1-5 /usr/bin/ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -c:v libx264 -preset veryfast -crf 20 /home/user/records/$(date \%Y\%m\%d).mp4Windows任务计划里则把命令写成bat脚本再触发执行即可。需要注意后台运行时的日志输出建议用-loglevel error降低日志量避免产生巨大的日志文件。4.4 同时录制多个画面FFmpeg支持多路输入这在录制“主机画面摄像头画中画”时特别好用。把两路画面用滤镜组合ffmpeg -f gdigrab -framerate 30 -video_size 1920x1080 -i desktop -f dshow -video_size 320x240 -i videoUSB Camera -filter_complex [1:v]scale320:240[pi];[0:v][pi]overlayW-w-20:20[out] -map [out] -c:v libx264 -preset veryfast -crf 20 combined.mp4这条命令里overlayW-w-20:20把摄像头画面放在屏幕右下角距离边缘20像素。画中画录制就是这么简单OBS里拖几下鼠标的事FFmpeg一行命令也就搞定了而且更容易自动化。4.5 多视频合并成一个视频录制时间长了会产生好几个文件合并是高频操作。用FFmpeg合并有两种方式文件列表法推荐ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4list.txt内容file part1.mp4 file part2.mp4这种方式优先考虑因为-c copy直接复制流数据不重新编码速度极快。只有在编码参数、分辨率不一致时才需要重新编码ffmpeg -i part1.mp4 -i part2.mp4 -filter_complex [0:v][0:a][1:v][1:a]concatn2:v1:a1[outv][outa] -map [outv] -map [outa] merged.mp4重新编码版兼容性最好适合拼接不同来源的视频但耗时较久画质也会略微损失。4.6 视频信息查询与逐帧导出录制完的视频想查看编码信息ffmpeg -i input.mp4输出的FFmpeg信息里包含视频编码格式、分辨率、帧率、码率、音频编码、采样率等。如果想要更结构化的JSON输出用ffprobe -show_streams -print_format json input.mp4脚本处理时很实用。逐帧导出则是视频分析需求里常用的功能ffmpeg -i input.mp4 -vf fps30 frames/frame_%04d.jpg这条命令按30fps从视频里抽帧。需要某一时间范围的帧加-ss 00:01:00 -t 10就行导出10秒内的帧。我在做视频内容自动化测试时就用这种逐帧导出方式检查关键节点画面是否正常。5. 录制中的坑常见问题与排查心得5.1 黑屏或画面静止屏幕录制最常见的问题是录出来黑屏。Windows下gdigrab黑屏通常是权限问题或用远程桌面会话时显卡加速策略不同导致。我实际排查时遇到过多次解决思路尝试用管理员权限运行ffmpeg。远程桌面场景里把目标机器的显卡加速设置改掉或直接改用-f gdigrab -i title/窗口标题抓单独窗口。Linux下黑屏则检查x11grab的DISPLAY环境变量echo $DISPLAY看看是不是:0.0。5.2 录制没有声音这个坑极大。首先要区分是“视频文件没有音频流”还是“有音频流但无声”。前者用ffprobe查看流信息即可后者往往是采集设备音量问题或音频格式不被播放器支持。Windows dshow采集麦克风时如果出现“no available audio device”错误先确认设备名。设备名里有空格命令里就必须加引号很多人是栽在这里。macOS avfoundation的索引号也可能因为设备插拔而变化遇到没声音先重新跑一遍-list_devices true看看索引对不对。5.3 CPU占用过高与帧率下降录制直播或4K内容时CPU占用飙升是最常见的性能问题。libx264在presetveryfast以上时CPU已经吃得很满再想省资源就要上硬编。遇到帧率下降时核心排查思路检查采集帧率设置是否正确-framerate 30写没写看编码器预设是否太慢-preset medium换-preset veryfast。输出文件写入的磁盘是否足够快机械硬盘连续写4K视频容易跟不上换个SSD路径会立竿见影。硬盘写入速度不够时可以先录成更节省IO的格式比如MKV临时文件最后再转成MP4。5.4 录制文件损坏无法播放录制中途强制终止MP4文件一般就废了常见的报错是moov atom找不到。解决思路有两个录制时直接用-f mkv输出临时文件MKV容器对中断录制更宽容录制完再转封装成MP4。已经损坏的MP4尝试用ffmpeg -i damaged.mp4 -c copy repaired.mp4修复很多时候能救回来但可能会丢部分数据。录制长时间内容时我都是先录MKV再转MP4这条经验救了我很多次。5.5 推流延迟与卡顿录制和推流经常同时出现。离线录制基本不用关心延迟但推送到SRS这类服务器时延迟控制就变得重要。前面第3.4节提过-tune zerolatency和-g参数再补充一个核心点监控推流侧的带宽与CPU状态。延迟通常不只是FFmpeg单方面的问题。我此前给客户做在线培训推流时发现服务器和客户端都在同一局域网延迟却高达3秒以上。排查后定位到是播放器缓冲策略的问题——RTMP/HTTP-FLV播放端默认缓冲较大只能通过播放器配置减小缓冲或者改用延迟更低的协议。调编码参数只能管住编码侧的延迟链路与播放测也要同步检查。6. 进阶实战把FFmpeg封装成自己的录制工具6.1 SDK集成还是命令行调用做产品的朋友经常纠结一个问题把FFmpeg集成到自己的软件里是调用命令行还是用SDK我的判断标准是如果只是偶尔执行录制或转码任务命令行调用完全够用开发速度快、维护成本低。但如果你需要流式处理、实时预览、动态拼接多路流、需要监听编码进度并在不同阶段做精细控制建议用FFmpeg的C API或libavformat/libavcodec库。网上常搜到的“ffmpeg c封装”就是这个话题。封装思路一般是用libavformat打开输入和输出上下文。用libavcodec处理编码器和解码器参数。写一个录制类封装Open/Write/Close等接口上层应用只需调用这几个方法。这种封装的难点在于内存管理、时间戳换算、错误码处理以及多线程下对AVFrame生命周期的管理。初次做的话强烈建议从命令行调用起步跑通了再考虑SDK化。6.2 一个最简的C录制核心逻辑给一个极简的、能运行的思路示意伪代码级// 打开输入设备以dshow为例 AVFormatContext *fmtCtx nullptr; avformat_open_input(fmtCtx, videoUSB Camera, dshow, nullptr); // 找到视频流与解码器 AVCodecParameters *params fmtCtx-streams[videoIdx]-codecpar; AVCodec *codec avcodec_find_decoder(params-codec_id); avcodec_parameters_to_context(codecCtx, params); avcodec_open2(codecCtx, codec, nullptr); // 初始化输出上下文为MP4格式 avformat_alloc_output_context2(outCtx, nullptr, mp4, output.mp4); // 循环读取帧 - 时间戳重映射 - 编码写入 while (av_read_frame(fmtCtx, pkt) 0) { if (pkt.stream_index videoIdx) { pkt.pts av_rescale_q(pkt.pts, inStream-time_base, outStream-time_base); pkt.dts av_rescale_q(pkt.dts, inStream-time_base, outStream-time_base); av_interleaved_write_frame(outCtx, pkt); } } av_write_trailer(outCtx);这里最容易出错的是时间戳换算。设备采集的时间基准是微秒级MP4的时间基准通常是1/1000秒做av_rescale_q时稍微写错录出来的视频不是快进就是卡顿。我现在做封装时都会把时间戳处理单独抽成工具函数统一管理。6.3 录制模块的工程化建议如果你真的要把FFmpeg录制做成产品功能还有几个工程层面的注意事项日志管理FFmpeg的日志输出要做分级平时只记录error调试时才打开info。否则长时间无人值守运行时日志文件会撑爆硬盘。异常恢复录制模块必须有自动重启机制。硬件设备偶尔会出现信号中断、USB摄像头掉线的情况健壮的程序应该能感知错误并自动重试。参数配置化分辨率、帧率、码率、设备名这些不能写死在代码里做成配置文件或接口参数。否则每换一台设备都要重新编译运维的人会疯。7. 把录制能力延展出去FFmpeg录制学完之后延展方向非常多。降码率压缩视频、提取音频、转GIF、抽字幕、做倍速播放全都建立在掌握了录制参数和滤镜基础上。比如降低视频码率ffmpeg -i input.mp4 -c:v libx264 -crf 28 -c:a aac -b:a 96k output_small.mp4这条命令就是把原视频压成码率更低的版本。理解CRF、preset、码率的控制逻辑后你在视频处理的任何环节都能举一反三。我个人在实际操作中的体会是FFmpeg的录制功能解决的不只是“把画面存下来”这个需求它背后是一整套对采集、编码、封装、网络传输的理解。把这套逻辑吃透之后你再遇到OBS出问题、商业软件限制、服务器上没法用图形界面都不会慌——敲一行命令就是一条出路。最后再分享一个小技巧录制时如果不想画面里有鼠标指针可以在输入层后面加输出滤镜把光标隐藏或者反过来把鼠标操作高亮显示方便做教程视频。具体用-vf cursorshow或-vf cursorhide控制。这种小细节正式发布视频时很实用但看文档还真不容易找到。