FFMPEG参数-rtbufsize与-thread_queue_size的区别及关联是什么

核心概念定义 #

• thread queue size（线程队列大小）
  是FFmpeg多线程处理链路中，上下游线程之间传递帧数据的队列可容纳的最大单元数，你之前的理解是正确的：针对视频流场景，这个单元通常就是未编码/已编码的视频帧。它的作用是做线程间的流量削峰，避免上游采集/解码速度波动直接导致下游编码/输出环节断流。
  桌面录制场景下对应的调整参数通常是-thread_queue_size，需要跟在输入源参数之前配置，示例如下：

  ffmpeg -thread_queue_size 1024 -f gdigrab -i desktop output.mp4
  

• real time buffer size（实时缓冲区大小）
  是FFmpeg针对实时输入源（桌面采集、摄像头、直播流等）单独设置的底层数据缓冲区，存储的是还没有被demuxer拆解成帧的原始输入数据流，单位通常是字节。它的作用是缓存硬件/系统采集层上报的原始数据，避免上层处理不及时导致的采集数据直接丢失。
  Windows下gdigrab/dshow采集对应的调整参数是-rtbufsize，同样需要跟在输入源参数之前配置。

两者的核心区别 #

• 存储内容不同：thread queue存的是已经完成拆解的独立帧，real time buffer存的是未拆解的原始二进制流
• 所处链路位置不同：real time buffer在采集模块和demuxer模块之间，thread queue在demuxer模块和后续处理/编码线程之间
• 配置单位不同：thread queue单位是帧个数，real time buffer单位是字节（支持k/M/G后缀，比如-rtbufsize 200M）

两者的关联 #

• 两者都是为了缓解实时场景下处理速度不匹配导致的丢帧、报错问题，属于FFmpeg流处理链路中不同层级的流量缓冲组件
• 单独调大thread_queue_size并不会直接提升rtbufsize的大小：前者是线程间通信的队列容量，后者是输入层的独立缓存，二者参数独立配置，没有自动联动的逻辑
• Windows下这类报错出现概率更高的核心原因是Windows桌面采集API（gdigrab/dshow）的优先级更低，系统调度波动更容易导致采集数据上报突发阻塞，两个缓存任意一个被打满都会抛出对应报错，建议同时调整两个参数来解决问题，比如Windows桌面录制的常用参数组合：

  ffmpeg -rtbufsize 150M -thread_queue_size 1024 -f gdigrab -framerate 30 -i desktop -c:v h264_qsv output.mp4
  

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