1. 为什么我决定丢掉付费录屏软件大概三个月前我电脑里那款用了快两年的付费录屏软件又弹出续费提醒。一年将近三百块的订阅费用其实不算贵但它录出来的文件越来越大启动越来越慢偶尔还偷偷在视频角落加上软件水印。最让我烦的是我根本用不到它那些花哨的直播推流、绿幕抠像功能我要的就是“把屏幕干净地录下来转成体积小、画质好的文件”这一件事。后来我认真列了一下自己真实的需求每周录几节操作演示视频、临时录个问题复现过程发给同事、偶尔录一段给客户看的产品操作流程。这些场景都不复杂但需要录制时足够稳定、清晰文件不能太大最好能一键开始、一键结束不需要被各种弹窗干扰。市面上免费录屏工具要么有时间和水印限制要么画质被压得一塌糊涂。付费软件倒是好用但为了这点功能持续掏钱总觉得像在给房东打工。于是我决定自己做一个。技术栈也很清晰FFmpeg负责所有视频编码和采集的脏活累活Python负责把它包装成好用的外壳AI编程助手负责在我不熟悉FFmpeg细节的时候帮我补齐代码和排查报错。这个组合做出来的录屏工具不仅完全免费而且每一行代码都长在我自己的需求上没有冗余功能没有广告没有体积膨胀想改成什么都行。这个项目我建议三类人参考一是有轻量录屏需求、又不想年年续费订阅的人二是想认真搞懂FFmpeg视频处理但苦于命令行太抽象的人三是想体验“AI辅助完整开发一个桌面小工具”的开发流程、愿意动动手把AI输出改成自己代码的人。不需要你多厉害会一点Python基础、愿意读报错信息就能复刻整个项目。2. 方案选型和整体思路拆解动手之前先把大方向定下来这比直接写代码重要得多。2.1 为什么选FFmpeg而不是“写一套录屏算法”录屏这个需求底层其实是三件事抓取屏幕画面、抓取音频、把音视频按时间轴编码成文件。屏幕抓取需要调用操作系统底层接口Windows上是Desktop Duplication或GDImacOS上是ScreenCaptureKitLinux上各家桌面环境还不一样编码封装更是涉及H.264、H.265、AAC、MP4容器等一串复杂规范。你不可能从零写一套这玩意就像你不会自己炼钢造螺丝来修自行车一样。FFmpeg是全球最成熟的多媒体处理工具集它把这些能力全部封装好了你要做的只是告诉它“从哪个设备采集、用什么参数编码、输出到哪里”。而且它免费开源、跨平台、几乎无依赖命令行版本加起来才几十MB非常适合作为工具的地基。也有人说Python里不是有OpenCV可以读摄像头和屏幕吗OpenCV的VideoCapture主要面向摄像头视频流做桌面录制要么依赖第三个库、要么自己用mss截帧再逐帧写视频。逐帧截图再编码的做法帧率上不去CPU占用爆炸而且声音完全要另找方案。FFmpeg是一条命令解决采集和编码全链路效率和代码量都是碾压级的。2.2 核心录制需求清单我把需求写成了一份可以勾选的清单所有功能都围绕这几条展开需求项具体描述优先级全屏录制录制整个桌面分辨率跟屏幕走必选区域录制只录指定位置和尺寸的矩形区域必选帧率控制默认30帧可选60帧必选编码质量体积小、画质清晰适合长视频必选麦克风声音录制时解说收录麦克风输入可选系统声音录制电脑内部播放的声音可选快速开始/停止不要复杂配置启动即录必选定时录制预设时长到点自动停可选2.3 技术栈分工谁干什么活这块是整个项目最核心的架构决策。我最终采用“FFmpeg干重活Python做调度AI当外脑”的三层结构。FFmpeg负责采集和编码具体到命令上就是使用gdigrab设备抓取屏幕Windows平台用dshow设备抓取麦克风再把两路输入用libx264编码器合成输出为MP4文件。Python作为外层封装用subprocess模块把FFmpeg做成的子进程拉起来同时负责接收键盘指令比如按Q键停止录制、按P键暂停。AI编程助手在整个过程里相当于一个可以随时交流的资深同事你不确定的参数、看不懂的报错、想要实现的某段逻辑都可以直接向它提问并让它生成代码。这个分工的好处是三层彼此独立FFmpeg参数出了问题不影响Python外壳Python代码有bug也不会破坏已经录好的视频文件。而且后续想扩展功能比如加一个自动上传到云端只要在Python层加代码就行完全不用动底层。3. AI辅助开发我是怎么让AI当我的编程搭档既然标题里提到了AI这部分我详细讲讲AI在整个项目里到底起了什么作用以及我是怎么“指挥”它的毕竟很多人用AI写代码时总感觉写得不对路。3.1 AI在这个项目里扮演的三个角色第一个角色是“FFmpeg参数翻译官”。说实话FFmpeg命令虽然强大但参数极其反直觉。比如屏幕录制里那个-offset_x 0 -offset_y 0 -video_size 1920x1080为什么video_size放在-i前面而不是后面为什么gdigrab采集时还要指定-framerate这些细节我不是全记得以前的习惯是翻文档现在直接问AI它给出的命令模板基本可跑我再根据实际情况微调。第二个角色是“草稿工程师”。整个Python脚本的骨架包括subprocess.Popen拉起FFmpeg、捕获键盘事件、写日志文件都是我先描述需求让AI生成初版然后自己一行行改。这里有个关键认知AI生成的代码不是拿来即用的它给你的是80分答案剩下的20分需要你根据自己的实际场景补齐。比如它默认录全屏但我还要录区域这就得自己改参数。第三个角色是“报错解读师”。开发过程中最崩溃的时刻不是代码写不出来而是明明照着文档写了运行时却报各种看不懂的错。Windows下最典型的就是“av_interleaved_write_frame(): Operation not permitted”和“Broken pipe”。这些报错信息很碎搜索引擎也不一定马上能找到答案但把完整报错丢给AI它能快速定位到是编码器参数和输出格式不匹配、还是磁盘空间不足、或是有其他进程占用了视频文件。3.2 调教AI代码质量的几条经验先说结论你用AI是要求一个靠谱的同事不是求一个打字快的应届生。所以提问方式非常重要。经验一一定要给出上下文和约束。不要只说“帮我写一个录屏程序”而是说“在Windows 10下用Python调用FFmpeg写一个录屏工具要求支持鼠标光标采集、30帧率、libx264编码、输入设备是gdigrab和dshow。请用subprocess实现”。喂给AI的信息越具体它输出的代码越接近可用状态。经验二把报错原文原样粘贴给AI。很多人遇到报错会自己“概括”一下再问AI结果把关键信息弄丢了。正确做法是直接粘贴控制台输出的完整日志AI能从中识别出是语法错误、环境变量问题、还是参数逻辑问题。经验三每改一次只让AI做一个事情。如果你同时提“帮我加暂停功能、加定时停止、把输出改成mkv格式”大概率得到一坨纠缠不清的代码。一次只提一个需求改完跑通再提下一个模块化推进。这一点在AI辅助开发中极其重要越小的迭代越好排查。经验四AI生成的代码必须要看懂再运行。不要无脑复制粘贴至少看懂每一段在做什么。因为FFmpeg命令里一个参数的顺序不同结果可能完全不同AI也不是每次都对。3.3 我实际使用的提问模板我把我用得最顺手的两个Prompt模板放这里你可以直接抄作业。模板一快速生成初版代码我在Windows 10系统上用Python 3.10开发一个录屏工具。 需要用subprocess调用FFmpeg录制整个屏幕帧率30编码器libx264CRF 23 输出MP4文件路径由命令行参数传入。 屏幕采集用gdigrab需要显示鼠标光标。 请输出完整的Python脚本并解释关键参数的含义。模板二排查具体报错这是我运行Python脚本时出现的完整报错信息 [粘贴报错] 我的环境是Windows 10Python 3.10FFmpeg版本是6.0。 请帮我分析可能的原因并给出修改后的代码或FFmpeg参数。用这两个模板开发效率提升非常明显。我把大概开发速度描述一下骨架代码AI几分钟就出我通读修改了不到半小时第一个能用的录屏版本就出来了。4. 环境准备FFmpeg和Python的安装坑与解法这一步很多人会卡住尤其是第一次安装FFmpeg时最大的坑不在软件本身而在环境变量和路径识别上。4.1 FFmpeg下载与安装FFmpeg官方不直接提供Windows的编译版可执行文件需要从gyan.dev或BtbN等第三方构建站点下载。下载文件一般是zip压缩包解压后能看到bin目录里面有三个exe文件ffmpeg.exe、ffprobe.exe、ffplay.exe。ffmpeg.exe是核心工具另外两个是辅助工具建议把整个bin目录放到一个稳定位置比如C:\ffmpeg\bin。然后必须配置Windows环境变量否则在命令行里输入ffmpeg -version会直接报“ffmpeg 不是内部或外部命令也不是可运行的程序或批处理文件”或者PowerShell里报“无法将‘ffmpeg’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个报错几乎每个新手都会遇到原因很简单系统不知道你的ffmpeg.exe放在哪里。配置路径如下右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”里找到Path→ 编辑 → 新建 → 填入C:\ffmpeg\bin→ 确定。配置完以后必须重新打开命令行窗口才能生效。要验证环境变量是否配置成功在命令行输入 ffmpeg -version 如果能看到版本号、配置参数和可用编码器列表说明安装成功。4.2 Python侧准备Python本身不需要装额外包标准库的subprocess、os、time、keyboard就足够了。唯一需要pip install的是keyboard库用来监听键盘按键实现停止录制。pip install keyboard这里有个小提示keyboard库在某些Windows环境下需要管理员权限运行Python才能成功监听全局按键。如果运行时发现按键监听没反应可以试试用管理员身份打开命令行再运行程序。4.3 第一次冒烟测试环境配好之后先别急着写Python而是直接用命令行测一下FFmpeg的录屏能力。这条命令你如果手头有环境也可以直接复制运行ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libx264 -pix_fmt yuv420p -crf 23 output.mp4按q键结束录制然后打开output.mp4看看效果。如果这段视频能正常播放说明FFmpeg环境已经完全可用了后面所有Python封装工作都是在这条命令之上做文章。5. 核心代码实现录屏工具是怎么一步步搭起来的这一章是整个项目的主体我会从最基础的录制命令开始一步一步把它扩展成完整体。每段代码我都解释清楚每一行在干什么方便你改造成适合自己的版本。5.1 第一版一个能用的全屏录制脚本我这里先写一个最简单的Python脚本它能拉起FFmpeg录全屏然后等待按键结束。import subprocess import time import keyboard # 录制参数 output_file frecording_{time.strftime(%Y%m%d_%H%M%S)}.mp4 fps 30 # 组装FFmpeg命令 cmd [ ffmpeg, -f, gdigrab, # 使用Windows桌面采集设备 -framerate, str(fps), # 帧率 -i, desktop, # 采集整个桌面 -c:v, libx264, # H.264编码 -pix_fmt, yuv420p, # 像素格式兼容播放器 -crf, 23, # 质量参数越小越清晰文件越大 -preset, fast, # 编码速度与压缩率的折中 output_file ] # 启动FFmpeg子进程 process subprocess.Popen(cmd) print(开始录制按 CtrlShiftQ 停止录制...) keyboard.wait(ctrlshiftq) process.terminate() print(f录制完成已保存到 {output_file})这段代码里有几个关键点我详细解释一下-f gdigrab是整个录制的入口告诉FFmpeg从Windows图形设备接口GDI抓取画面。桌面在FFmpeg里的“设备名”就叫desktop抓取整个屏幕时只要在-i后面写desktop就行。-framerate 30是采集帧率视频是由一帧帧画面组成的30帧就是每秒抓取30张画面大部分人眼看起来已经很流畅了。-crf 23是很多人会疑惑的参数。CRF全称是Constant Rate Factor恒定质量模式数值范围0到51越小质量越高、文件越大。23是H.264编码器公认的“画质和体积平衡点”日常录屏选23到28之间都合理。如果你对画质要求高、不太在乎体积可以降到18如果只是录个临时演示、希望文件小就调到28。不同数值的具体差异后面我在测试环节里详细对比。-preset fast是编码速度设置。libx264编码器提供了从ultrafast到placebo的多个速度档位越快则CPU占用越少但文件越大越慢则压缩率越好但CPU发热量猛增。对实时录屏来说fast或veryfast是最合适的既能保证不丢帧又不至于文件大得离谱。5.2 第二版增加区域录制全屏录制需求很快就满足不了我了很多时候我只想录某个软件的窗口或者录PPT播放区域的某一块。FFmpeg的gdigrab设备支持指定采集区域关键是三个参数-offset_x、-offset_y和-video_size。# 区域参数左上角坐标(100, 100)宽度1280高度720 offset_x 100 offset_y 100 width 1280 height 720 cmd [ ffmpeg, -f, gdigrab, -framerate, str(fps), -offset_x, str(offset_x), # 起始X坐标 -offset_y, str(offset_y), # 起始Y坐标 -video_size, f{width}x{height}, # 录制区域的宽高 -i, desktop, -c:v, libx264, -pix_fmt, yuv420p, -crf, 23, -preset, fast, output_file ]这三个参数的组合逻辑其实很简单offset_x和offset_y决定你从屏幕左上角往右、往下偏移多少像素开始截取video_size决定截取多大的矩形区域。比如你的屏幕分辨率是1920x1080想让录制区域从屏幕正中央开始截一个1280x720的矩形计算方法是offset_x (1920 - 1280) / 2 320offset_y (1080 - 720) / 2 180。这个方法做出来的区域录制不是“选窗口跟随”而是“固定位置截取”。如果你录的内容在屏幕上的位置会移动区域录制的画面就会跑偏。但对大多数录教程场景来说先把窗口摆好位置再开始录是完全够用的。5.3 第三版加上麦克风声音和系统声音有画面没声音对操作演示类视频来说基本不可用。FFmpeg在Windows上通过dshow设备采集音频设备包括麦克风Microphone和立体声混音Stereo Mix。我这里把两种需求拆开讲。只采集麦克风声音ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audioMicrophone Array (Realtek Audio) \ -c:v libx264 -pix_fmt yuv420p -crf 23 \ -c:a aac -b:a 128k \ output.mp4注意audio后面的设备名称必须和你系统里的真实设备名称完全一致否则会报“No such device”错误。查看本机设备列表的方法是用FFmpeg自带的枚举命令ffmpeg -list_devices true -f dshow -i dummy运行后它会列出所有可用的音频输入设备名称复制你麦克风的准确名称填进去即可。同时采集麦克风和系统声音这就稍微麻烦一点Windows的dshow接口一般情况下一个设备只能被一个程序独占而“系统声音”在Windows上是通过“立体声混音”设备暴露的需要你在声音设置里先把它启用具体路径是右键右下角音量图标 → 声音 → 录制 → 右键空白处 → 显示禁用的设备 → 启用立体声混音。启用后把它和麦克风一起作为两个音频输入源拉进来ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audioMicrophone Array (Realtek Audio) \ -f dshow -i audio立体声混音 (Realtek Audio) \ -filter_complex amixinputs2:durationlongest \ -c:v libx264 -pix_fmt yuv420p -crf 23 \ -c:a aac -b:a 128k \ output.mp4filter_complex里的amixinputs2是FFmpeg的音频混流滤镜它把两路音频叠在一起输出。这个filter是录双音轨场景里最常见的但新手最容易漏掉漏掉的话FFmpeg默认只压最后一路音频结果就是只有麦克风声音、没有系统声音或者反过来。这个坑我当初踩了很久特此记一笔。需要注意的是amix默认在混合时会把小于阈值音量的声音做衰减处理导致录制出来音量偏小。如果你发现最后视频音量比现场低可以在amix后面加一个音量放大参数-filter_complex amixinputs2:durationlongest:normalize0,volume2.05.4 完整版一个接近“商业软件体验”的录屏脚本把所有需求合起来我最终跑的版本是这样的import subprocess import time import sys import keyboard def record_screen(output_fileNone, modefull, regionNone, fps30, crf23, presetfast, mic_deviceNone, system_deviceNone): 录屏主函数 :param output_file: 输出文件路径 :param mode: full 全屏, region 区域 :param region: (offset_x, offset_y, width, height) 区域录制的坐标 :param fps: 帧率 :param crf: 质量参数 :param preset: 编码速度预设 :param mic_device: 麦克风设备名 :param system_device: 系统声音设备名 if output_file is None: output_file frec_{time.strftime(%Y%m%d_%H%M%S)}.mp4 cmd [ ffmpeg, -f, gdigrab, -framerate, str(fps), ] if mode region and region: offset_x, offset_y, width, height region cmd.extend([ -offset_x, str(offset_x), -offset_y, str(offset_y), -video_size, f{width}x{height}, ]) cmd.extend([-i, desktop]) # 音频设备处理 audio_filters [] if mic_device: cmd.extend([-f, dshow, -i, faudio{mic_device}]) audio_filters.append(mic) if system_device: cmd.extend([-f, dshow, -i, faudio{system_device}]) audio_filters.append(system) cmd.extend([ -c:v, libx264, -pix_fmt, yuv420p, -crf, str(crf), -preset, preset, ]) # 如果有音频输入就加音频编码 if audio_filters: if len(audio_filters) 1: cmd.extend([-c:a, aac, -b:a, 128k]) else: cmd.extend([ -filter_complex, amixinputs2:durationlongest:normalize0,volume2.0, -c:a, aac, -b:a, 192k, ]) cmd.append(output_file) print(f录制参数{全屏 if mode full else f区域 {region}} | f{fps}fps | CRF {crf} | {preset}) print(按 CtrlAltS 开始录制按 CtrlAltQ 停止录制...) keyboard.wait(ctrlalts) print(开始录制...) process subprocess.Popen(cmd) try: keyboard.wait(ctrlaltq) except KeyboardInterrupt: pass finally: process.terminate() process.wait() print(f录制结束文件已保存到{output_file}) if __name__ __main__: record_screen( moderegion, region(320, 180, 1280, 720), fps30, crf23, mic_deviceMicrophone Array (Realtek Audio), system_device立体声混音 (Realtek Audio), )这段代码我实测下来已经能稳定满足我的日常使用了。按下CtrlAltS开始按下CtrlAltQ结束中间不用碰鼠标对录操作类视频特别友好。你只改最后那行参数即可适配你的设备。code_project_review注意region参数里的四个值要按(offset_x, offset_y, width, height)顺序填写很多人会填反。比如想录屏幕正中央1280x720的区域在1920x1080屏幕上应该是(320, 180, 1280, 720)——先算居中偏移量再写宽高这个顺序错了录出来的区域会很怪。6. 实测对比不同编码参数对画质和体积的影响代码写完不代表完事了参数怎么调才最适合自己的场景必须实测。我专门做了几组对比测试在同一台机器、同样的录屏画面下只改变一个参数记录文件体积和视觉差异。6.1 CRF值对文件体积的影响录制时长统一为5分钟内容为静态桌面动态鼠标一遍代码滚动CRF值输出文件大小主观画质评价1886MB几乎无损放大后边缘锐利2341MB观感很好适合日常使用2818MB有轻微压缩痕迹文字边缘略糊328MB明显模糊不适合含文字的教程视频结论很直接CRF 23是“不折腾”的选择CRF 28适合临时录屏、追求文件小的场景。我日常主力是23发给客户看的东西用18自己内部存档用28。6.2 preset对CPU占用和文件大小的影响用同样的画面、CRF 23只换preset结果如下preset5分钟文件大小录屏时CPU占用率ultrafast78MB约15%veryfast52MB约22%fast41MB约35%medium37MB约48%slow32MB约70%如果你一边录屏一边还要开浏览器、跑IDECPU占用挤得太高会直接导致画面掉帧。所以我坚持用fast档把CPU占用控制在40%以内保证录制过程不影响其他操作。追求极致文件体积的话再考虑slow但那时候你最好不要开着大型软件录屏。6.3 帧率选择的理性判断30fps和60fps的差别在录代码、录PPT这类画面变化不剧烈的场景里基本看不出来但60fps的视频文件体积几乎是30fps的两倍。除非你要录游戏画面或者带动画的交互过程否则录屏工具默认30fps就够了。这个结论我在录制视频时验证了很多次逼自己在绝大多数场景下忍住不买“60帧”的营销口号。7. 常见问题与排查技巧实录开发和使用这个工具的过程中我踩了不少坑下面这些问题都是真实遇到过的每条都附上了排查思路和解决办法。7.1 “ffmpeg 不是内部或外部命令” / “无法将‘ffmpeg’项识别为 cmdlet”这是最基础的问题所有新手都会遇到。它表示系统在你当前的环境中找不到ffmpeg命令。排查顺序是先确认ffmpeg.exe确实存在再确认Path环境变量是否写对最后确认改完环境变量后是不是开了新终端窗口。设置完环境变量之后旧窗口里的环境变量不会刷新必须重新打开命令行或IDE。7.2 录出来的视频是一张静止画面鼠标能动但其他画面不动这个坑很隐蔽。Windows的GDI桌面采集在某些硬件加速开启的情况下会拿不到动态桌面内容。解决办法是在gdigrab后面加一个-hwaccel auto或者退出部分游戏的硬件加速模式。更简单的方法是用-f gdigrab -framerate 30 -i desktop的时候不要加-hwaccel cuda之类的强制硬件解码参数让FFmpeg自己判断。7.3 录制刚开始几秒就自动结束最常见原因是video_size区域设置得超出了屏幕范围。比如屏幕只有1920x1080你却设置了offset_x 视频宽度 1920gdigrab就会报错退出。排查时把-loglevel debug加进FFmpeg命令里会看到很明确的错误提示我每次排查FFmpeg问题第一步就是打开debug日志。7.4 录音没声音或录出来音量极小分两种情况排查。第一种是完全没声音大概率是设备名填错了用ffmpeg -list_devices true -f dshow -i dummy重新确认设备名注意系统里的设备名称是中文就填中文是英文就填英文一个字符都不能错。第二种是有声音但极小这是amix滤镜默认的降噪逻辑在捣乱加上normalize0参数关闭自动增益再用volume参数手动放大即可。7.5 录制的视频文件中途损坏无法播放最大嫌疑是磁盘空间不够导致写入中断。在subprocess.Popen之前脚本就对磁盘剩余空间做一次检查少于2GB直接提示并退出。还有一个容易被忽略的坑录制过程中电脑进入了睡眠模式gdigrab的设备就断了视频也坏了。解决方法是录制期间用一小段Python代码临时把睡眠策略设为“从不”录制结束再恢复。7.6 对视频做后期裁剪时怎么保持画质不二压录完了想剪掉开头和结尾很多人会直接打开剪辑软件重新导出这就多了一次有损编码。实际上FFmpeg可以直接无损切割。比如想保留原视频第2分钟到第5分钟的内容ffmpeg -ss 00:02:00 -to 00:05:00 -i input.mp4 -c copy output.mp4关键就在-c copy它告诉FFmpeg复制原始编码数据而不重新编码速度极快且画质无损。这个命令对录屏工具生产出的视频特别适用因为录屏文件里大多数内容都是冗余的剪辑需求很高。7.7 如果想让录屏文件更小还有别的编码器吗libx264虽然是默认首选但如果你想追求更小的文件体积可以试试H.265/HEVC编码器FFmpeg里的名字是libx265。它能在同样画质下比H.264减少大约30%-40%的体积代价是编码速度更慢、部分老设备播放器不支持。方法是在命令里把-c:v libx264换成-c:v libx265CRF值建议从28开始调因为H.265的CRF标定和H.264不一样。如果你用的是NVIDIA显卡还可以用h264_nvenc或hevc_nvenc硬件编码让显卡替代CPU干活几乎零CPU占用但相同码率下的画质会略有损失。就我的实际体验而言日常录屏用libx264就够好了文件大小并没有到不能接受的程度。7.8 在Linux上怎么实现类似功能很多用麒麟、Ubuntu等Linux发行版的朋友也问过我。FFmpeg跨平台兼容性很好只需要把采集设备的名称改一改。Linux桌面环境一般用x11grab设备采集屏幕ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -c:v libx264 output.mp4这里的:0.0是X11显示服务器的编号一般默认就是这个。如果用的是Wayland显示协议情况会复杂一些建议直接用后面提到的OBS Studio或者先用X11会话顶着。音频采集在Linux上通常用pulse或alsa设备具体命令在网上搜ffmpeg linux record desktop audio就能找到很多方案。8. 录屏工具还能怎么扩展工具做完以后我发现FFmpeg的潜力远比“录屏”本身大得多这里顺手列出几个我后续打算做的扩展方向给你一些参考。一是自动上传。录完的视频自动调用对象存储API传上去然后生成分享链接复制到剪贴板这样录完即分享不用再手动拖文件。实现上就是在Python的finally部分加两行云SDK调用。二是定时录制。有些操作演示需要在指定时间点开始录比如半夜跑自动化测试时要录屏幕留证。通过给脚本加一个time.sleep到目标时间再触发录制的逻辑就行代码量很小但使用价值很高。三是把区域录制参数做成可视化。用Tkinter或者PyQt实现一个“拖拽选框选录制区域”的界面这样就不用手动算坐标了。我目前手动算坐标也够用但做成视觉化更友好。四是加一个“自动压缩”功能。录完5分钟视频可能有40MB如果用libx265重新转压能压到20MB以内。可以用刚才提到的无损切割先剪掉无效片头再转一次H.265做长期存档兼顾清晰度和占用空间。五是把录屏会话的元数据写进文件名。比如20250317_产品演示_1080p30.mp4这个格式看着就比rec_20250317_145534.mp4舒服得多而且方便后续检索。扩展方向有个共同原则核心的FFmpeg调用保持稳定所有功能都放在Python外层做加法。这样不管怎么改底层录制逻辑都不会被破坏。9. 我的真实感受和一些建议这个项目从想法到第一个可用版本花了不到一天真正打磨到位大概是两三天时间。它最大的收获其实不是省了那三百块订阅费而是我彻底理解了录屏工具背后到底在做什么——屏幕怎么被抓取、声音怎么被采样、编码器怎么权衡体积和画质。这些知识是通用的以后遇到任何音视频处理需求我都有了底层的地图。如果你也想动手做我给几条掏心窝的建议第一不要一上来就追求功能完整先把最简单的全屏录制跑通再一点点加声音、加区域、加定时功能第二遇到问题优先看FFmpeg的-loglevel debug输出它比任何教程都诚实第三AI生成的代码只能当草稿你要改到它能“长在你手里”的程度才算真的是你的工具第四参数别照抄别人的CRF多少、preset选什么跟你的电脑性能、使用场景强相关花半小时测一遍你以后能省几十个小时。动手做一个自己的录屏工具远没有想象中那么难。你可以跑通之后再加点自己的奇怪需求——比如连续录一周的屏幕生成延时视频或者录屏时自动在关键帧打上时间戳。这类很小的自主软件用起来比商业软件顺手得多因为它是你身体的延伸。 用Python和FFmpeg自制录屏工具：AI辅助开发全流程
1. 为什么我决定丢掉付费录屏软件大概三个月前我电脑里那款用了快两年的付费录屏软件又弹出续费提醒。一年将近三百块的订阅费用其实不算贵但它录出来的文件越来越大启动越来越慢偶尔还偷偷在视频角落加上软件水印。最让我烦的是我根本用不到它那些花哨的直播推流、绿幕抠像功能我要的就是“把屏幕干净地录下来转成体积小、画质好的文件”这一件事。后来我认真列了一下自己真实的需求每周录几节操作演示视频、临时录个问题复现过程发给同事、偶尔录一段给客户看的产品操作流程。这些场景都不复杂但需要录制时足够稳定、清晰文件不能太大最好能一键开始、一键结束不需要被各种弹窗干扰。市面上免费录屏工具要么有时间和水印限制要么画质被压得一塌糊涂。付费软件倒是好用但为了这点功能持续掏钱总觉得像在给房东打工。于是我决定自己做一个。技术栈也很清晰FFmpeg负责所有视频编码和采集的脏活累活Python负责把它包装成好用的外壳AI编程助手负责在我不熟悉FFmpeg细节的时候帮我补齐代码和排查报错。这个组合做出来的录屏工具不仅完全免费而且每一行代码都长在我自己的需求上没有冗余功能没有广告没有体积膨胀想改成什么都行。这个项目我建议三类人参考一是有轻量录屏需求、又不想年年续费订阅的人二是想认真搞懂FFmpeg视频处理但苦于命令行太抽象的人三是想体验“AI辅助完整开发一个桌面小工具”的开发流程、愿意动动手把AI输出改成自己代码的人。不需要你多厉害会一点Python基础、愿意读报错信息就能复刻整个项目。2. 方案选型和整体思路拆解动手之前先把大方向定下来这比直接写代码重要得多。2.1 为什么选FFmpeg而不是“写一套录屏算法”录屏这个需求底层其实是三件事抓取屏幕画面、抓取音频、把音视频按时间轴编码成文件。屏幕抓取需要调用操作系统底层接口Windows上是Desktop Duplication或GDImacOS上是ScreenCaptureKitLinux上各家桌面环境还不一样编码封装更是涉及H.264、H.265、AAC、MP4容器等一串复杂规范。你不可能从零写一套这玩意就像你不会自己炼钢造螺丝来修自行车一样。FFmpeg是全球最成熟的多媒体处理工具集它把这些能力全部封装好了你要做的只是告诉它“从哪个设备采集、用什么参数编码、输出到哪里”。而且它免费开源、跨平台、几乎无依赖命令行版本加起来才几十MB非常适合作为工具的地基。也有人说Python里不是有OpenCV可以读摄像头和屏幕吗OpenCV的VideoCapture主要面向摄像头视频流做桌面录制要么依赖第三个库、要么自己用mss截帧再逐帧写视频。逐帧截图再编码的做法帧率上不去CPU占用爆炸而且声音完全要另找方案。FFmpeg是一条命令解决采集和编码全链路效率和代码量都是碾压级的。2.2 核心录制需求清单我把需求写成了一份可以勾选的清单所有功能都围绕这几条展开需求项具体描述优先级全屏录制录制整个桌面分辨率跟屏幕走必选区域录制只录指定位置和尺寸的矩形区域必选帧率控制默认30帧可选60帧必选编码质量体积小、画质清晰适合长视频必选麦克风声音录制时解说收录麦克风输入可选系统声音录制电脑内部播放的声音可选快速开始/停止不要复杂配置启动即录必选定时录制预设时长到点自动停可选2.3 技术栈分工谁干什么活这块是整个项目最核心的架构决策。我最终采用“FFmpeg干重活Python做调度AI当外脑”的三层结构。FFmpeg负责采集和编码具体到命令上就是使用gdigrab设备抓取屏幕Windows平台用dshow设备抓取麦克风再把两路输入用libx264编码器合成输出为MP4文件。Python作为外层封装用subprocess模块把FFmpeg做成的子进程拉起来同时负责接收键盘指令比如按Q键停止录制、按P键暂停。AI编程助手在整个过程里相当于一个可以随时交流的资深同事你不确定的参数、看不懂的报错、想要实现的某段逻辑都可以直接向它提问并让它生成代码。这个分工的好处是三层彼此独立FFmpeg参数出了问题不影响Python外壳Python代码有bug也不会破坏已经录好的视频文件。而且后续想扩展功能比如加一个自动上传到云端只要在Python层加代码就行完全不用动底层。3. AI辅助开发我是怎么让AI当我的编程搭档既然标题里提到了AI这部分我详细讲讲AI在整个项目里到底起了什么作用以及我是怎么“指挥”它的毕竟很多人用AI写代码时总感觉写得不对路。3.1 AI在这个项目里扮演的三个角色第一个角色是“FFmpeg参数翻译官”。说实话FFmpeg命令虽然强大但参数极其反直觉。比如屏幕录制里那个-offset_x 0 -offset_y 0 -video_size 1920x1080为什么video_size放在-i前面而不是后面为什么gdigrab采集时还要指定-framerate这些细节我不是全记得以前的习惯是翻文档现在直接问AI它给出的命令模板基本可跑我再根据实际情况微调。第二个角色是“草稿工程师”。整个Python脚本的骨架包括subprocess.Popen拉起FFmpeg、捕获键盘事件、写日志文件都是我先描述需求让AI生成初版然后自己一行行改。这里有个关键认知AI生成的代码不是拿来即用的它给你的是80分答案剩下的20分需要你根据自己的实际场景补齐。比如它默认录全屏但我还要录区域这就得自己改参数。第三个角色是“报错解读师”。开发过程中最崩溃的时刻不是代码写不出来而是明明照着文档写了运行时却报各种看不懂的错。Windows下最典型的就是“av_interleaved_write_frame(): Operation not permitted”和“Broken pipe”。这些报错信息很碎搜索引擎也不一定马上能找到答案但把完整报错丢给AI它能快速定位到是编码器参数和输出格式不匹配、还是磁盘空间不足、或是有其他进程占用了视频文件。3.2 调教AI代码质量的几条经验先说结论你用AI是要求一个靠谱的同事不是求一个打字快的应届生。所以提问方式非常重要。经验一一定要给出上下文和约束。不要只说“帮我写一个录屏程序”而是说“在Windows 10下用Python调用FFmpeg写一个录屏工具要求支持鼠标光标采集、30帧率、libx264编码、输入设备是gdigrab和dshow。请用subprocess实现”。喂给AI的信息越具体它输出的代码越接近可用状态。经验二把报错原文原样粘贴给AI。很多人遇到报错会自己“概括”一下再问AI结果把关键信息弄丢了。正确做法是直接粘贴控制台输出的完整日志AI能从中识别出是语法错误、环境变量问题、还是参数逻辑问题。经验三每改一次只让AI做一个事情。如果你同时提“帮我加暂停功能、加定时停止、把输出改成mkv格式”大概率得到一坨纠缠不清的代码。一次只提一个需求改完跑通再提下一个模块化推进。这一点在AI辅助开发中极其重要越小的迭代越好排查。经验四AI生成的代码必须要看懂再运行。不要无脑复制粘贴至少看懂每一段在做什么。因为FFmpeg命令里一个参数的顺序不同结果可能完全不同AI也不是每次都对。3.3 我实际使用的提问模板我把我用得最顺手的两个Prompt模板放这里你可以直接抄作业。模板一快速生成初版代码我在Windows 10系统上用Python 3.10开发一个录屏工具。 需要用subprocess调用FFmpeg录制整个屏幕帧率30编码器libx264CRF 23 输出MP4文件路径由命令行参数传入。 屏幕采集用gdigrab需要显示鼠标光标。 请输出完整的Python脚本并解释关键参数的含义。模板二排查具体报错这是我运行Python脚本时出现的完整报错信息 [粘贴报错] 我的环境是Windows 10Python 3.10FFmpeg版本是6.0。 请帮我分析可能的原因并给出修改后的代码或FFmpeg参数。用这两个模板开发效率提升非常明显。我把大概开发速度描述一下骨架代码AI几分钟就出我通读修改了不到半小时第一个能用的录屏版本就出来了。4. 环境准备FFmpeg和Python的安装坑与解法这一步很多人会卡住尤其是第一次安装FFmpeg时最大的坑不在软件本身而在环境变量和路径识别上。4.1 FFmpeg下载与安装FFmpeg官方不直接提供Windows的编译版可执行文件需要从gyan.dev或BtbN等第三方构建站点下载。下载文件一般是zip压缩包解压后能看到bin目录里面有三个exe文件ffmpeg.exe、ffprobe.exe、ffplay.exe。ffmpeg.exe是核心工具另外两个是辅助工具建议把整个bin目录放到一个稳定位置比如C:\ffmpeg\bin。然后必须配置Windows环境变量否则在命令行里输入ffmpeg -version会直接报“ffmpeg 不是内部或外部命令也不是可运行的程序或批处理文件”或者PowerShell里报“无法将‘ffmpeg’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个报错几乎每个新手都会遇到原因很简单系统不知道你的ffmpeg.exe放在哪里。配置路径如下右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”里找到Path→ 编辑 → 新建 → 填入C:\ffmpeg\bin→ 确定。配置完以后必须重新打开命令行窗口才能生效。要验证环境变量是否配置成功在命令行输入 ffmpeg -version 如果能看到版本号、配置参数和可用编码器列表说明安装成功。4.2 Python侧准备Python本身不需要装额外包标准库的subprocess、os、time、keyboard就足够了。唯一需要pip install的是keyboard库用来监听键盘按键实现停止录制。pip install keyboard这里有个小提示keyboard库在某些Windows环境下需要管理员权限运行Python才能成功监听全局按键。如果运行时发现按键监听没反应可以试试用管理员身份打开命令行再运行程序。4.3 第一次冒烟测试环境配好之后先别急着写Python而是直接用命令行测一下FFmpeg的录屏能力。这条命令你如果手头有环境也可以直接复制运行ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libx264 -pix_fmt yuv420p -crf 23 output.mp4按q键结束录制然后打开output.mp4看看效果。如果这段视频能正常播放说明FFmpeg环境已经完全可用了后面所有Python封装工作都是在这条命令之上做文章。5. 核心代码实现录屏工具是怎么一步步搭起来的这一章是整个项目的主体我会从最基础的录制命令开始一步一步把它扩展成完整体。每段代码我都解释清楚每一行在干什么方便你改造成适合自己的版本。5.1 第一版一个能用的全屏录制脚本我这里先写一个最简单的Python脚本它能拉起FFmpeg录全屏然后等待按键结束。import subprocess import time import keyboard # 录制参数 output_file frecording_{time.strftime(%Y%m%d_%H%M%S)}.mp4 fps 30 # 组装FFmpeg命令 cmd [ ffmpeg, -f, gdigrab, # 使用Windows桌面采集设备 -framerate, str(fps), # 帧率 -i, desktop, # 采集整个桌面 -c:v, libx264, # H.264编码 -pix_fmt, yuv420p, # 像素格式兼容播放器 -crf, 23, # 质量参数越小越清晰文件越大 -preset, fast, # 编码速度与压缩率的折中 output_file ] # 启动FFmpeg子进程 process subprocess.Popen(cmd) print(开始录制按 CtrlShiftQ 停止录制...) keyboard.wait(ctrlshiftq) process.terminate() print(f录制完成已保存到 {output_file})这段代码里有几个关键点我详细解释一下-f gdigrab是整个录制的入口告诉FFmpeg从Windows图形设备接口GDI抓取画面。桌面在FFmpeg里的“设备名”就叫desktop抓取整个屏幕时只要在-i后面写desktop就行。-framerate 30是采集帧率视频是由一帧帧画面组成的30帧就是每秒抓取30张画面大部分人眼看起来已经很流畅了。-crf 23是很多人会疑惑的参数。CRF全称是Constant Rate Factor恒定质量模式数值范围0到51越小质量越高、文件越大。23是H.264编码器公认的“画质和体积平衡点”日常录屏选23到28之间都合理。如果你对画质要求高、不太在乎体积可以降到18如果只是录个临时演示、希望文件小就调到28。不同数值的具体差异后面我在测试环节里详细对比。-preset fast是编码速度设置。libx264编码器提供了从ultrafast到placebo的多个速度档位越快则CPU占用越少但文件越大越慢则压缩率越好但CPU发热量猛增。对实时录屏来说fast或veryfast是最合适的既能保证不丢帧又不至于文件大得离谱。5.2 第二版增加区域录制全屏录制需求很快就满足不了我了很多时候我只想录某个软件的窗口或者录PPT播放区域的某一块。FFmpeg的gdigrab设备支持指定采集区域关键是三个参数-offset_x、-offset_y和-video_size。# 区域参数左上角坐标(100, 100)宽度1280高度720 offset_x 100 offset_y 100 width 1280 height 720 cmd [ ffmpeg, -f, gdigrab, -framerate, str(fps), -offset_x, str(offset_x), # 起始X坐标 -offset_y, str(offset_y), # 起始Y坐标 -video_size, f{width}x{height}, # 录制区域的宽高 -i, desktop, -c:v, libx264, -pix_fmt, yuv420p, -crf, 23, -preset, fast, output_file ]这三个参数的组合逻辑其实很简单offset_x和offset_y决定你从屏幕左上角往右、往下偏移多少像素开始截取video_size决定截取多大的矩形区域。比如你的屏幕分辨率是1920x1080想让录制区域从屏幕正中央开始截一个1280x720的矩形计算方法是offset_x (1920 - 1280) / 2 320offset_y (1080 - 720) / 2 180。这个方法做出来的区域录制不是“选窗口跟随”而是“固定位置截取”。如果你录的内容在屏幕上的位置会移动区域录制的画面就会跑偏。但对大多数录教程场景来说先把窗口摆好位置再开始录是完全够用的。5.3 第三版加上麦克风声音和系统声音有画面没声音对操作演示类视频来说基本不可用。FFmpeg在Windows上通过dshow设备采集音频设备包括麦克风Microphone和立体声混音Stereo Mix。我这里把两种需求拆开讲。只采集麦克风声音ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audioMicrophone Array (Realtek Audio) \ -c:v libx264 -pix_fmt yuv420p -crf 23 \ -c:a aac -b:a 128k \ output.mp4注意audio后面的设备名称必须和你系统里的真实设备名称完全一致否则会报“No such device”错误。查看本机设备列表的方法是用FFmpeg自带的枚举命令ffmpeg -list_devices true -f dshow -i dummy运行后它会列出所有可用的音频输入设备名称复制你麦克风的准确名称填进去即可。同时采集麦克风和系统声音这就稍微麻烦一点Windows的dshow接口一般情况下一个设备只能被一个程序独占而“系统声音”在Windows上是通过“立体声混音”设备暴露的需要你在声音设置里先把它启用具体路径是右键右下角音量图标 → 声音 → 录制 → 右键空白处 → 显示禁用的设备 → 启用立体声混音。启用后把它和麦克风一起作为两个音频输入源拉进来ffmpeg -f gdigrab -framerate 30 -i desktop \ -f dshow -i audioMicrophone Array (Realtek Audio) \ -f dshow -i audio立体声混音 (Realtek Audio) \ -filter_complex amixinputs2:durationlongest \ -c:v libx264 -pix_fmt yuv420p -crf 23 \ -c:a aac -b:a 128k \ output.mp4filter_complex里的amixinputs2是FFmpeg的音频混流滤镜它把两路音频叠在一起输出。这个filter是录双音轨场景里最常见的但新手最容易漏掉漏掉的话FFmpeg默认只压最后一路音频结果就是只有麦克风声音、没有系统声音或者反过来。这个坑我当初踩了很久特此记一笔。需要注意的是amix默认在混合时会把小于阈值音量的声音做衰减处理导致录制出来音量偏小。如果你发现最后视频音量比现场低可以在amix后面加一个音量放大参数-filter_complex amixinputs2:durationlongest:normalize0,volume2.05.4 完整版一个接近“商业软件体验”的录屏脚本把所有需求合起来我最终跑的版本是这样的import subprocess import time import sys import keyboard def record_screen(output_fileNone, modefull, regionNone, fps30, crf23, presetfast, mic_deviceNone, system_deviceNone): 录屏主函数 :param output_file: 输出文件路径 :param mode: full 全屏, region 区域 :param region: (offset_x, offset_y, width, height) 区域录制的坐标 :param fps: 帧率 :param crf: 质量参数 :param preset: 编码速度预设 :param mic_device: 麦克风设备名 :param system_device: 系统声音设备名 if output_file is None: output_file frec_{time.strftime(%Y%m%d_%H%M%S)}.mp4 cmd [ ffmpeg, -f, gdigrab, -framerate, str(fps), ] if mode region and region: offset_x, offset_y, width, height region cmd.extend([ -offset_x, str(offset_x), -offset_y, str(offset_y), -video_size, f{width}x{height}, ]) cmd.extend([-i, desktop]) # 音频设备处理 audio_filters [] if mic_device: cmd.extend([-f, dshow, -i, faudio{mic_device}]) audio_filters.append(mic) if system_device: cmd.extend([-f, dshow, -i, faudio{system_device}]) audio_filters.append(system) cmd.extend([ -c:v, libx264, -pix_fmt, yuv420p, -crf, str(crf), -preset, preset, ]) # 如果有音频输入就加音频编码 if audio_filters: if len(audio_filters) 1: cmd.extend([-c:a, aac, -b:a, 128k]) else: cmd.extend([ -filter_complex, amixinputs2:durationlongest:normalize0,volume2.0, -c:a, aac, -b:a, 192k, ]) cmd.append(output_file) print(f录制参数{全屏 if mode full else f区域 {region}} | f{fps}fps | CRF {crf} | {preset}) print(按 CtrlAltS 开始录制按 CtrlAltQ 停止录制...) keyboard.wait(ctrlalts) print(开始录制...) process subprocess.Popen(cmd) try: keyboard.wait(ctrlaltq) except KeyboardInterrupt: pass finally: process.terminate() process.wait() print(f录制结束文件已保存到{output_file}) if __name__ __main__: record_screen( moderegion, region(320, 180, 1280, 720), fps30, crf23, mic_deviceMicrophone Array (Realtek Audio), system_device立体声混音 (Realtek Audio), )这段代码我实测下来已经能稳定满足我的日常使用了。按下CtrlAltS开始按下CtrlAltQ结束中间不用碰鼠标对录操作类视频特别友好。你只改最后那行参数即可适配你的设备。code_project_review注意region参数里的四个值要按(offset_x, offset_y, width, height)顺序填写很多人会填反。比如想录屏幕正中央1280x720的区域在1920x1080屏幕上应该是(320, 180, 1280, 720)——先算居中偏移量再写宽高这个顺序错了录出来的区域会很怪。6. 实测对比不同编码参数对画质和体积的影响代码写完不代表完事了参数怎么调才最适合自己的场景必须实测。我专门做了几组对比测试在同一台机器、同样的录屏画面下只改变一个参数记录文件体积和视觉差异。6.1 CRF值对文件体积的影响录制时长统一为5分钟内容为静态桌面动态鼠标一遍代码滚动CRF值输出文件大小主观画质评价1886MB几乎无损放大后边缘锐利2341MB观感很好适合日常使用2818MB有轻微压缩痕迹文字边缘略糊328MB明显模糊不适合含文字的教程视频结论很直接CRF 23是“不折腾”的选择CRF 28适合临时录屏、追求文件小的场景。我日常主力是23发给客户看的东西用18自己内部存档用28。6.2 preset对CPU占用和文件大小的影响用同样的画面、CRF 23只换preset结果如下preset5分钟文件大小录屏时CPU占用率ultrafast78MB约15%veryfast52MB约22%fast41MB约35%medium37MB约48%slow32MB约70%如果你一边录屏一边还要开浏览器、跑IDECPU占用挤得太高会直接导致画面掉帧。所以我坚持用fast档把CPU占用控制在40%以内保证录制过程不影响其他操作。追求极致文件体积的话再考虑slow但那时候你最好不要开着大型软件录屏。6.3 帧率选择的理性判断30fps和60fps的差别在录代码、录PPT这类画面变化不剧烈的场景里基本看不出来但60fps的视频文件体积几乎是30fps的两倍。除非你要录游戏画面或者带动画的交互过程否则录屏工具默认30fps就够了。这个结论我在录制视频时验证了很多次逼自己在绝大多数场景下忍住不买“60帧”的营销口号。7. 常见问题与排查技巧实录开发和使用这个工具的过程中我踩了不少坑下面这些问题都是真实遇到过的每条都附上了排查思路和解决办法。7.1 “ffmpeg 不是内部或外部命令” / “无法将‘ffmpeg’项识别为 cmdlet”这是最基础的问题所有新手都会遇到。它表示系统在你当前的环境中找不到ffmpeg命令。排查顺序是先确认ffmpeg.exe确实存在再确认Path环境变量是否写对最后确认改完环境变量后是不是开了新终端窗口。设置完环境变量之后旧窗口里的环境变量不会刷新必须重新打开命令行或IDE。7.2 录出来的视频是一张静止画面鼠标能动但其他画面不动这个坑很隐蔽。Windows的GDI桌面采集在某些硬件加速开启的情况下会拿不到动态桌面内容。解决办法是在gdigrab后面加一个-hwaccel auto或者退出部分游戏的硬件加速模式。更简单的方法是用-f gdigrab -framerate 30 -i desktop的时候不要加-hwaccel cuda之类的强制硬件解码参数让FFmpeg自己判断。7.3 录制刚开始几秒就自动结束最常见原因是video_size区域设置得超出了屏幕范围。比如屏幕只有1920x1080你却设置了offset_x 视频宽度 1920gdigrab就会报错退出。排查时把-loglevel debug加进FFmpeg命令里会看到很明确的错误提示我每次排查FFmpeg问题第一步就是打开debug日志。7.4 录音没声音或录出来音量极小分两种情况排查。第一种是完全没声音大概率是设备名填错了用ffmpeg -list_devices true -f dshow -i dummy重新确认设备名注意系统里的设备名称是中文就填中文是英文就填英文一个字符都不能错。第二种是有声音但极小这是amix滤镜默认的降噪逻辑在捣乱加上normalize0参数关闭自动增益再用volume参数手动放大即可。7.5 录制的视频文件中途损坏无法播放最大嫌疑是磁盘空间不够导致写入中断。在subprocess.Popen之前脚本就对磁盘剩余空间做一次检查少于2GB直接提示并退出。还有一个容易被忽略的坑录制过程中电脑进入了睡眠模式gdigrab的设备就断了视频也坏了。解决方法是录制期间用一小段Python代码临时把睡眠策略设为“从不”录制结束再恢复。7.6 对视频做后期裁剪时怎么保持画质不二压录完了想剪掉开头和结尾很多人会直接打开剪辑软件重新导出这就多了一次有损编码。实际上FFmpeg可以直接无损切割。比如想保留原视频第2分钟到第5分钟的内容ffmpeg -ss 00:02:00 -to 00:05:00 -i input.mp4 -c copy output.mp4关键就在-c copy它告诉FFmpeg复制原始编码数据而不重新编码速度极快且画质无损。这个命令对录屏工具生产出的视频特别适用因为录屏文件里大多数内容都是冗余的剪辑需求很高。7.7 如果想让录屏文件更小还有别的编码器吗libx264虽然是默认首选但如果你想追求更小的文件体积可以试试H.265/HEVC编码器FFmpeg里的名字是libx265。它能在同样画质下比H.264减少大约30%-40%的体积代价是编码速度更慢、部分老设备播放器不支持。方法是在命令里把-c:v libx264换成-c:v libx265CRF值建议从28开始调因为H.265的CRF标定和H.264不一样。如果你用的是NVIDIA显卡还可以用h264_nvenc或hevc_nvenc硬件编码让显卡替代CPU干活几乎零CPU占用但相同码率下的画质会略有损失。就我的实际体验而言日常录屏用libx264就够好了文件大小并没有到不能接受的程度。7.8 在Linux上怎么实现类似功能很多用麒麟、Ubuntu等Linux发行版的朋友也问过我。FFmpeg跨平台兼容性很好只需要把采集设备的名称改一改。Linux桌面环境一般用x11grab设备采集屏幕ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -c:v libx264 output.mp4这里的:0.0是X11显示服务器的编号一般默认就是这个。如果用的是Wayland显示协议情况会复杂一些建议直接用后面提到的OBS Studio或者先用X11会话顶着。音频采集在Linux上通常用pulse或alsa设备具体命令在网上搜ffmpeg linux record desktop audio就能找到很多方案。8. 录屏工具还能怎么扩展工具做完以后我发现FFmpeg的潜力远比“录屏”本身大得多这里顺手列出几个我后续打算做的扩展方向给你一些参考。一是自动上传。录完的视频自动调用对象存储API传上去然后生成分享链接复制到剪贴板这样录完即分享不用再手动拖文件。实现上就是在Python的finally部分加两行云SDK调用。二是定时录制。有些操作演示需要在指定时间点开始录比如半夜跑自动化测试时要录屏幕留证。通过给脚本加一个time.sleep到目标时间再触发录制的逻辑就行代码量很小但使用价值很高。三是把区域录制参数做成可视化。用Tkinter或者PyQt实现一个“拖拽选框选录制区域”的界面这样就不用手动算坐标了。我目前手动算坐标也够用但做成视觉化更友好。四是加一个“自动压缩”功能。录完5分钟视频可能有40MB如果用libx265重新转压能压到20MB以内。可以用刚才提到的无损切割先剪掉无效片头再转一次H.265做长期存档兼顾清晰度和占用空间。五是把录屏会话的元数据写进文件名。比如20250317_产品演示_1080p30.mp4这个格式看着就比rec_20250317_145534.mp4舒服得多而且方便后续检索。扩展方向有个共同原则核心的FFmpeg调用保持稳定所有功能都放在Python外层做加法。这样不管怎么改底层录制逻辑都不会被破坏。9. 我的真实感受和一些建议这个项目从想法到第一个可用版本花了不到一天真正打磨到位大概是两三天时间。它最大的收获其实不是省了那三百块订阅费而是我彻底理解了录屏工具背后到底在做什么——屏幕怎么被抓取、声音怎么被采样、编码器怎么权衡体积和画质。这些知识是通用的以后遇到任何音视频处理需求我都有了底层的地图。如果你也想动手做我给几条掏心窝的建议第一不要一上来就追求功能完整先把最简单的全屏录制跑通再一点点加声音、加区域、加定时功能第二遇到问题优先看FFmpeg的-loglevel debug输出它比任何教程都诚实第三AI生成的代码只能当草稿你要改到它能“长在你手里”的程度才算真的是你的工具第四参数别照抄别人的CRF多少、preset选什么跟你的电脑性能、使用场景强相关花半小时测一遍你以后能省几十个小时。动手做一个自己的录屏工具远没有想象中那么难。你可以跑通之后再加点自己的奇怪需求——比如连续录一周的屏幕生成延时视频或者录屏时自动在关键帧打上时间戳。这类很小的自主软件用起来比商业软件顺手得多因为它是你身体的延伸。