14

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

.

Alf
  • 1,821
  • 3
  • 30
  • 48
  • 6
    `-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. – Gyan May 11 '20 at 11:20
  • @Gyan `thread_queue_size` "_is applied to the first input specified after it_." That is indeed incredibly helpful, thank you!! – Alf May 11 '20 at 12:45
  • @Gyan 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? – Alf May 11 '20 at 12:48
  • 1
    Yes, either of the current t_q_s will do, for the audio. – Gyan May 11 '20 at 12:50

1 Answers1

9

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
Hadrien
  • 1,479
  • 2
  • 14
  • 18
Alf
  • 1,821
  • 3
  • 30
  • 48
  • 3
    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. – db-inf Oct 18 '20 at 08:35
  • @db-inf thanks, sounds like a good idea, will definitely have a look into that! – Alf Oct 19 '20 at 13:44