FFmpeg sws_scale()处理4K@60FPS视频时异常缓慢问题排查

我来帮你拆解这个棘手的问题——从你的描述来看，核心矛盾是非跳帧模式下YUV转BGRA的耗时突然暴涨10倍，而且堆栈指向了ntoskrnl.exe!KiPageFault，这显然不是单纯的睿频下降或者线程数不够的问题。结合Windows内存模型和FFmpeg的特性，我梳理了几个最可能的成因：

1. 虚拟内存工作集被频繁修剪，导致软页错误激增 #

虽然你的物理内存剩余20GB+，但Windows的内存管理机制并不会让进程无限制占用工作集（即当前加载到物理内存的页）。当你用16线程持续处理4K帧时，系统可能因为以下原因主动trim你的进程工作集：

• 16线程的频繁上下文切换，导致每个线程的内存页无法长期驻留物理内存；
• 后台系统进程（比如Windows Defender实时扫描、Superfetch）会抢占物理内存缓存，把你的进程页面移到备用列表（虽然没写到磁盘，但重新加载仍有开销）。

跳帧模式下因为处理的帧少，工作集还能维持在稳定状态，软页错误少；非跳帧模式持续运行后，页面被反复移出/移入，导致每次YUV/BGRA转换都触发大量软页错误，直接把耗时拉到350ms。

排查建议：

• 用Process Explorer查看进程的「Page Faults/sec」指标，对比跳帧和非跳帧模式的差异；
• 尝试用SetProcessWorkingSetSize强制锁定进程工作集（需要管理员权限），看是否能缓解卡顿。

2. 16线程内存密集型任务导致总线带宽饱和+缓存命中率暴跌 #

YUV转BGRA本质是内存读写密集型任务：4K YUV420P单帧约8MB，BGRA约16MB，16线程同时处理的话，每秒要读写的内存量是(8+16)6016≈23GB/s，这很可能超过了你机器的内存总线带宽（比如DDR4-3200单通道带宽约25GB/s，双通道约50GB/s，但实际可用带宽会打折扣）。

更关键的是，16线程同时访问不同的帧缓冲区，会彻底冲刷CPU的L3缓存，导致缓存命中率暴跌——跳帧模式下处理的帧少，缓存还能命中部分数据；非跳帧模式持续运行后，缓存完全失效，每次内存访问都要走主存，延迟直接翻10倍以上，叠加页错误后耗时暴涨。

排查建议：

• 降低线程数到8甚至4，测试转换耗时变化（内存密集型任务的最优线程数通常远小于CPU核心数）；
• 用Windows Performance Recorder记录CPU缓存命中率指标，看非跳帧模式下是否出现命中率骤降。

3. FFmpeg转换上下文的不合理使用导致内存开销放大 #

如果你在每个线程每次转换时都创建/销毁SwsContext（FFmpeg用于图像转换的上下文），会导致大量内存分配/释放操作，长期运行后产生内存碎片，进而触发更多页错误。另外，如果你的帧缓冲区没有按SIMD指令要求对齐（比如16字节/32字节对齐），会导致sws_scale无法启用最优的SIMD优化，非跳帧模式下这种低效会被持续放大。

排查建议：

• 为每个线程复用一个SwsContext，不要每次转换都重新创建；
• 用av_malloc（FFmpeg的内存分配函数）来分配帧缓冲区，它会自动保证内存对齐，最大化SIMD指令的效率。

4. 系统后台进程的隐性干扰 #

堆栈中的KiPageFault也可能是后台进程触发的——比如Windows Defender的实时扫描可能会扫描你的帧缓冲区内存，导致页面被锁定；或者系统的内存压缩服务在后台压缩内存页，间接增加了你的进程的内存访问延迟。

排查建议：

• 临时关闭Windows Defender实时保护，测试非跳帧模式的耗时变化；
• 用Process Monitor查看是否有其他进程频繁访问你的进程内存区域。

内容的提问来源于stack exchange，提问作者user2328447