ffmpeg中thread_queue_size的正确使用答案

【问题标题】：Correct usage of thread_queue_size in ffmpegffmpeg中thread_queue_size的正确使用
【发布时间】：2020-08-26 15:10:20
【问题描述】：

我正在做一个截屏视频，我正在录制屏幕上正在发生的事情以及来自外部 USB 麦克风的同步音频。我正在使用以下命令：

ffmpeg -f x11grab -r 25 -s 1280x720 -i :0.0+320,236 -thread_queue_size 1024 -f alsa -thread_queue_size 1024 -i hw:1 -vcodec huffyuv screencast.mkv

我认为对thread_queue_size 使用如此高的值应该会让我进入安全站点，以避免我之前遇到的任何buffer xrun 错误。然而，情况似乎并非如此。以下是录制过程中出现的警告信息：

[x11grab @ 0x55ffe44e6a40] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
[alsa @ 0x55ffe44efe80] Thread message queue blocking; consider raising the thread_queue_size option (current value: 1024)
[alsa @ 0x55ffe44efe80] ALSA buffer xrun.B time=00:07:35.96 bitrate=203382.4kbits/s speed=0.994x    
[alsa @ 0x55ffe44efe80] ALSA buffer xrun.B time=00:20:18.76 bitrate=210805.7kbits/s speed=0.998x

两件事我不明白：

为什么x11grab 说thread_queue_size 是8，而我将它设置为1024？
仍然是 ALSA buffer xrun 错误/警告，尽管有 thread_queue_size 和 1024，我可以在此处输入什么值 - 最大值是多少，该值的确切含义是什么？

任何 cmets 将不胜感激！

版本：

ffmpeg version 3.4.6-0ubuntu0.18.04.1
Kernel 4.15.0-99-generic
xubuntu 18.04.4 LTS x86_64

。

【问题讨论】：

-thread_queue_size 是每个输入的，并应用于它之后指定的第一个输入。因此，在您的命令中，它仅应用于音频输入。也将它放在-i :0.0+320,236 之前。
@Gyan thread_queue_size "应用于它之后指定的第一个输入。"这确实非常有帮助，谢谢！！
@Gyan 我是对的，我不需要 直接在 -f alsa 之前指定它（就像我已经做到的那样），因为 thread_queue_size 会参考下一个输入 -i hw:1 并且前面已经有一个 thread_queue_size？
是的，当前的 t_q_s 中的任何一个都可以，用于音频。

标签： ffmpeg alsa screencast

【解决方案1】：

两个问题，两个答案：

正如@Gyan 所说的in the comments，thread_queue_size 应用于它之后指定的第一个输入。这意味着对于我在问题中给出的ffmpeg 命令：

ffmpeg -f x11grab -thread_queue_size 1024 -r 25 -s 1280x720 -i :0.0+320,236 -f alsa -thread_queue_size 1024 -i hw:1 -vcodec huffyuv screencast.mkv
这里的问题似乎是我保存了一个未压缩的视频文件 - 这些文件会很快变得非常大。我的磁盘似乎无法跟上按时将所有内容写入它的速度。因此，我更改了录制以保存压缩视频，这对 CPU 提出了更多要求，大大减少了文件大小。我录制屏幕截图的新命令（不会导致任何buffer xrun：

$ ffmpeg -f x11grab -thread_queue_size 4096 -r 25 -s 1280x720 -i :0.0+320,236 -f alsa -thread_queue_size 4096 -i hw:1 -vcodec libx264 -pix_fmt yuv420p -threads 0 -acodec aac screencast.mp4

【讨论】：

由于您首选的视频编码器是huffyuv，我猜您打算之后重新压缩您录制的文件。您可以通过使用其中一种硬件加速视频编解码器（如 h264-vaapi、h264_nvenc 及其 h265/hevc 等价物）来大大减少 CPU 负载，或者通过使用-preset ultrafast 仍然可以大大减少 CPU 负载，两者的质量或比特率都略高于最后的重新压缩步骤。
@db-inf 谢谢，听起来不错，一定会看看！