Correct usage of thread_queue_size in ffmpeg

Question

I am doing a screencast where I am recording what is going on at my screen together with simultaneous audio comments from an external USB microphone. I am using the following command:

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

I thought that using such high values for thread_queue_size should put me on the safe site to avoid any buffer xrun errors which I had previously. However, this seems not to be the case. Here is the warning message which appeared during recording:

[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    

Two things I do not understand:

1. Why is x11grab saying the thread_queue_size is 8, whereas I set it to 1024 ?
2. Still an ALSA buffer xrun error/warning, despite the thread_queue_size of 1024, what values can I put here - what is the maximum and what exactly does the value mean?

Any comments would be greatly appreciated!

---

Versions:

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

.

Seaweed

-thread_queue_size is per-input and is applied to the first input specified after it. So, in your command, it's applied only to the audio input. Place it before -i :0.0+320,236 as well. – Periodate

@Periodate thread_queue_size "is applied to the first input specified after it." That is indeed incredibly helpful, thank you!! – Seaweed

@Periodate am I right then, that I don't need to specify it directly before the -f alsa (like I have done it) as this thread_queue_size would refer to the next input which is -i hw:1 and this already has a thread_queue_size in front of it? – Seaweed

Yes, either of the current t_q_s will do, for the audio. – Periodate

Answer 1

Two questions, two answers:

1. As @Gyan has said in the comments, thread_queue_size is applied to the first input specified after it. That means for my ffmpeg command as given in the question:

   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
   

2. The problem here seems to be that I save an uncompressed video file - those files will become VERY large very fast. My disk seems to have problems to keep up with writing everything on time onto it. Thus I changed the recording to save compressed videos, which puts more demand onto the CPU much strongly reduces the file size. My new command to record a screenshot (which will not result in any 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
   

Seaweed

As your first choice of video encoder was huffyuv, I guess you intend to recompress your recorded file afterwards. You could reduce cpu load a lot by using one of the hardware accelerated video codecs, like h264-vaapi, h264_nvenc and their h265/hevc equivalents, or still quite a bit by using -preset ultrafast, both with a quality or bitrate somewhat higher than that of your final recompress step. – Hagio

@Hagio thanks, sounds like a good idea, will definitely have a look into that! – Seaweed