1

*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.

2

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
  • 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 Jan 23 at 7:21
  • @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 Jan 29 at 23:53
  • @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 Jan 29 at 23:57
  • 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 Jan 30 at 5:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.