<p>The "Thread message queue blocking" message is an indicator that your computer cannot keep up with encoding in real-time. It's recommending the "thread_queue_size" parameter because it thinks you want to process data in real-time (based on your command). By setting "thread_queue_size" to a higher value, you are increasing the buffer size for packets which are waiting to be encoded. If you exceed the packet buffer size (i.e., buffer gets full), ffmpeg will start to drop packets to keep up in real-time; increasing the buffer will <em>hopefully</em> allow your computer to process the packets before it has to drop them... But that won't work if you eventually run out of memory or exceed the new buffer size anyway since you are processing in less than real-time (less than 1.0x speed). </p>

<p>With your command, the reason ffmpeg is trying to process in realtime is because you are using -framerate 500/21 as an <em>input</em> instead of your desired output fps. So basically, ffmpeg is trying to encode 500/21 worth of images per second, which your computer can't keep up with when using the fast preset. Using -preset veryfast lowers the output quality, and your computer can apparently keep up with that, but I doubt that's what you want...</p>

<p>Since you really don't need to process in real-time (you're using a file-based source and not something live), you should use -r for the <em>output</em> instead of using framerate on the input.</p>

<pre><code>ffmpeg -start_number 1518 -i %d.png -i audio.ogg -c:a copy -vf "scale=3840:-1" -c:v libx265 -preset fast -crf 19 -pix_fmt yuv422p10le -r 500/21  output.ts
</code></pre>

CC BY-SA 4.0
2022-05-12T03:18:08.107Z
Sparkyish's answer doesn't appear to be correct, or at least not anymore. Not specifying the input frame rate still causes that warning to be thrown: > ffmpeg -i %06d.png -i eng1.flac -i .\eng2.flac -i sub.srt -map 0 -map 1 -map 2 -c:v libx265 -c:a copy -c:s copy -crf 21 -profile:v main -preset slow -pix_fmt yuv420p -vf "crop=2832:1712:504:206" -metadata:s:1 language=eng -metadata:s:2 language=eng -metadata:s:s language=eng -r 30000/1001 out.mkv<br />
............<br />
[image2 @ 00000227610b5a40] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
f
PlantDaddy
CC BY-SA 4.0
2019-01-23T07:21:39.217Z
*So basically, ffmpeg is trying to encode 500/21 worth of images per second* --> no, ffmpeg offers no contract on encoding speed; it will attempt to encode as fast as possible, but the input rate has nothing to do with it.
Gyan
CC BY-SA 4.0
2019-01-29T23:53:57.327Z
@Sparkyish Thanks for the answer, I need clarification on a few things though: "Using -preset veryfast lowers the output quality", when you say output quality I don't understand. The speed of the encode, when there is no error message, has nothing to do with the video/audio quality generated right? It should only influence filesize shouldn't it?
kite
CC BY-SA 4.0
2019-01-29T23:57:27.263Z
@Gyan Sorry I'm not fully understanding yet. Based on your comment are you disputing the entirety of Sparkyish's claim? Or just the way one section was worded? If ffmpeg offers no 'contract' on encoding speed and the input rate is irrelevant, doesn't that means -framerate as an input isn't the problem? If so, what is the problem in that case? Again, it's me not fully understanding what was being said I request a bit more clarification if possible.
kite
CC BY-SA 4.0
2019-01-30T05:24:55.457Z
All `-framerate` does is set timestamps for the input frames. And has no other effect. When multiple `-i` inputs are provided, FFmpeg reads each input in a separate thread and buffers packets till requested from further down the pipeline. When the input packets aren't dequeued fast enough and the queue is full, ffmpeg can't deposit new packets from the input into the queue so it has to wait and the warning is printed. Speeding up video encoding (usually the most time-consuming part of the pipeline) speeds up packet consumption rate.
Gyan
CC BY-SA 4.0
2019-01-23T03:45:42.870Z
2019-01-23T03:45:42.870Z
Sparkyish
<p>I first came across this message today when trying to pipe curl output (inside a while loop) as input to ffmpeg and then remux to mkv. The process was much more time-consuming than downloading all the files locally first and then concating and remuxing them with ffmpeg afterwards. I believe this message indicates how many bytes of the input file ffmpeg is trying to read at a time. In my case the message was</p>
<blockquote>
<p>[mpegts @ 0x55c7f9fe7a00] Thread message queue blocking; consider raising the thread_queue_size option (current value: 1)</p>
</blockquote>
<p>which would explain the delay in the process. After putting <code>-thread_queue_size 4096</code> before the input, the message disappeared and the process was as fast as it should.</p>

CC BY-SA 4.0
2022-09-11T20:25:46.383Z
2022-09-20T18:16:52.350Z
2022-09-20T18:16:52.350Z
KaMyKaSii
<p><strong>*Edit:</strong> changing the render to <code>-preset veryfast</code> will no longer display the warning message. I also noticed that the video itself for the versions where the warning displayed had the last few minutes cutoff on both the audio and the video. I'm quite lost as to why this is.<br>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</p>

<blockquote>
<pre><code>Thread message queue blocking; consider raising the thread_queue_size option 
  (current value: 8)
</code></pre>
</blockquote>

<p>I'm trying to find information on this warning message and what it means. The information I found online is indicating that not increasing my <code>thread_queue_size</code> can create artifacts and sync issues..? However the postings are many years old, and I'm unsure if they are true or still apply etc. They also apply towards screencasting specifically, which I am not knowingly doing.</p>

<p>The command I use that prompts this message is as follows:</p>

<pre><code>ffmpeg -framerate 500/21 -start_number 1518 -i %d.png -i audio.ogg -c:a copy -vf "scale=3840:-1" -c:v libx265 -preset fast -crf 19 -pix_fmt yuv422p10le output.ts
</code></pre>

<p>So basically I'm turning thousands upon thousands of 1080p png into a 10 bit 4k h.265 .ts video. Whether I use a preset or not, or do audio separately, the warning still displays.</p>

<p>While I'm doing my command ffmpeg uses 90%-100% of my cpu and 80%-90% of my ram. I want to know if my render is suffering in some way by ignoring the warning message. The stuff I read online was concerning. For the sake of argument <a href="https://nowardev.wordpress.com/2015/03/24/ffmpeg-and-the-message-thread-message-queue-blocking-consider-raising-the-thread_queue_size-option-current-value-8-alsa-buffer-xrun/" rel="noreferrer">I'll link the info I found, just note the language is nsfw.</a></p>

<p>I will add that my content is just over 30 minutes long. Also I noticed that after rendering it out and lining it up with the original content in my Video editor, that there is a slight audio echo. Meaning the audio does not sync 100% correctly as it should. It's irrelevant for my video in the grand scheme, but I'd like to know if its related in any way as the linked info suggests. I'd also like to know what I can/should do to address the warning, if anything.  </p>

<p>s speed = 0.117x<br>
using preset fast</p>

<p>I came across information in my search that said speed needs to be 1.0 or faster...? I don't know if that was related to a specific situation in the post read, or if there's something I never knew about happening here. Almost all my renders occur under 1.0x speed unless I'm rewrapping/copying streams.</p>

<ffmpeg>
ffmpeg thread_queue_size warning: What does this mean?
kite
# ffmpeg thread_queue_size warning: What does this mean?

(Asked by: username_0 on 2019-01-08)

*Edit: changing the render to -preset veryfast will no longer display the warning message. I also noticed that the video itself for the versions where the warning displayed had the last few minutes cutoff on both the audio and the video. I'm quite lost as to why this is.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Thread message queue blocking; consider raising the thread_queue_size option 
  (current value: 8)


I'm trying to find information on this warning message and what it means. The information I found online is indicating that not increasing my thread_queue_size can create artifacts and sync issues..? However the postings are many years old, and I'm unsure if they are true or still apply etc. They also apply towards screencasting specifically, which I am not knowingly doing.
The command I use that prompts this message is as follows:
ffmpeg -framerate 500/21 -start_number 1518 -i %d.png -i audio.ogg -c:a copy -vf "scale=3840:-1" -c:v libx265 -preset fast -crf 19 -pix_fmt yuv422p10le output.ts

So basically I'm turning thousands upon thousands of 1080p png into a 10 bit 4k h.265 .ts video. Whether I use a preset or not, or do audio separately, the warning still displays.
While I'm doing my command ffmpeg uses 90%-100% of my cpu and 80%-90% of my ram. I want to know if my render is suffering in some way by ignoring the warning message. The stuff I read online was concerning. For the sake of argument I'll link the info I found, just note the language is nsfw.
I will add that my content is just over 30 minutes long. Also I noticed that after rendering it out and lining it up with the original content in my Video editor, that there is a slight audio echo. Meaning the audio does not sync 100% correctly as it should. It's irrelevant for my video in the grand scheme, but I'd like to know if its related in any way as the linked info suggests. I'd also like to know what I can/should do to address the warning, if anything.  
s speed = 0.117x
using preset fast
I came across information in my search that said speed needs to be 1.0 or faster...? I don't know if that was related to a specific situation in the post read, or if there's something I never knew about happening here. Almost all my renders occur under 1.0x speed unless I'm rewrapping/copying streams.

**Tags:** ffmpeg


---

## 2 answers

### Answer by username_1 on 2019-01-23. Score: 4

The "Thread message queue blocking" message is an indicator that your computer cannot keep up with encoding in real-time. It's recommending the "thread_queue_size" parameter because it thinks you want to process data in real-time (based on your command). By setting "thread_queue_size" to a higher value, you are increasing the buffer size for packets which are waiting to be encoded. If you exceed the packet buffer size (i.e., buffer gets full), ffmpeg will start to drop packets to keep up in real-time; increasing the buffer will hopefully allow your computer to process the packets before it has to drop them... But that won't work if you eventually run out of memory or exceed the new buffer size anyway since you are processing in less than real-time (less than 1.0x speed). 
With your command, the reason ffmpeg is trying to process in realtime is because you are using -framerate 500/21 as an input instead of your desired output fps. So basically, ffmpeg is trying to encode 500/21 worth of images per second, which your computer can't keep up with when using the fast preset. Using -preset veryfast lowers the output quality, and your computer can apparently keep up with that, but I doubt that's what you want...
Since you really don't need to process in real-time (you're using a file-based source and not something live), you should use -r for the output instead of using framerate on the input.
ffmpeg -start_number 1518 -i %d.png -i audio.ogg -c:a copy -vf "scale=3840:-1" -c:v libx265 -preset fast -crf 19 -pix_fmt yuv422p10le -r 500/21  output.ts

> **Comments:**
> **username_3**: *So basically, ffmpeg is trying to encode 500/21 worth of images per second* --> no, ffmpeg offers no contract on encoding speed; it will attempt to encode as fast as possible, but the input rate has nothing to do with it.  
> **username_0**: @username_1 Thanks for the answer, I need clarification on a few things though: "Using -preset veryfast lowers the output quality", when you say output quality I don't understand. The speed of the encode, when there is no error message, has nothing to do with the video/audio quality generated right? It should only influence filesize shouldn't it?  
> **username_0**: @username_3 Sorry I'm not fully understanding yet. Based on your comment are you disputing the entirety of username_1's claim? Or just the way one section was worded? If ffmpeg offers no 'contract' on encoding speed and the input rate is irrelevant, doesn't that means -framerate as an input isn't the problem? If so, what is the problem in that case? Again, it's me not fully understanding what was being said I request a bit more clarification if possible.  
> **username_3**: All `-framerate` does is set timestamps for the input frames. And has no other effect. When multiple `-i` inputs are provided, FFmpeg reads each input in a separate thread and buffers packets till requested from further down the pipeline. When the input packets aren't dequeued fast enough and the queue is full, ffmpeg can't deposit new packets from the input into the queue so it has to wait and the warning is printed. Speeding up video encoding (usually the most time-consuming part of the pipeline) speeds up packet consumption rate.  
> **username_2**: username_1's answer doesn't appear to be correct, or at least not anymore. Not specifying the input frame rate still causes that warning to be thrown: > ffmpeg -i %06d.png -i eng1.flac -i .\eng2.flac -i sub.srt -map 0 -map 1 -map 2 -c:v libx265 -c:a copy -c:s copy -crf 21 -profile:v main -preset slow -pix_fmt yuv420p -vf "crop=2832:1712:504:206" -metadata:s:1 language=eng -metadata:s:2 language=eng -metadata:s:s language=eng -r 30000/1001 out.mkv<br /> ............<br /> [image2 @ 00000227610b5a40] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) f  

---

### Answer by username_4 on 2022-09-11. Score: 3

I first came across this message today when trying to pipe curl output (inside a while loop) as input to ffmpeg and then remux to mkv. The process was much more time-consuming than downloading all the files locally first and then concating and remuxing them with ffmpeg afterwards. I believe this message indicates how many bytes of the input file ffmpeg is trying to read at a time. In my case the message was

> [mpegts @ 0x55c7f9fe7a00] Thread message queue blocking; consider raising the thread\_queue\_size option (current value: 1)

which would explain the delay in the process. After putting `-thread_queue_size 4096` before the input, the message disappeared and the process was as fast as it should.


---

