Thanks, You're meaning that if I raise the value, it'll simply extend the live stream duration without but problem but there's gonna be a problem at a time ? The fact is I'm already using the preset configuration ultrafast, I can't go any faster. And when you say lower resolution, you mean the ffmpeg input resolution before transcoding ? Because I can't change that, I'm retrieving frames from the RICOH THETA V and it's 4k. Speaking about speed indicator : during my stream my value is near constant at speed=0,999. Is that an acceptable value or this 0,001 will add a mini slowdown to the video ? Will, adding -re option, force the speed to 1 withtout drawbacks ? I post my cmd, inputs are my devices using ffmpeg -list_devices true -f avfoundation -i "" ffmpeg -thread_queue_size 512 -f avfoundation -i "0:" -thread_queue_size 2048 -f avfoundation -i ":4" -crf 30 -preset ultrafast -strict experimental -vf scale=1920:960 -vcodec libx264 -tune zerolatency -pix_fmt yuv420p -r 30 -g 60 -threads 4 -acodec aac -ac 4 -b:a 512k -map_channel 1.0.0 -map_channel 1.0.1 -map_channel 1.0.2 -map_channel 1.0.3 -map 0:v -map 1:a -f flv rtmp://localhost/live_no_1/mon_flux Thanks for the help, i appreciate Yael ________________________________ De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> de la part de Marton Balint <cus@passwd.hu> Envoyé : mercredi 20 juin 2018 08:21 À : FFmpeg user questions Objet : Re: [FFmpeg-user] Warning : Thread message queue blocking On Wed, 20 Jun 2018, yael Laouar wrote:

Hi all,

I'm trying to stream live using ffmpeg a set 3D camera and microphone to Facebook in order to realize a 3D live. I've the workflow complete now, meaning that I can stream from my set to Facebook, but I still have a problem.

If I launch my streaming it will work a little bit but after a while, a ffmpeg warning appears :

[avfoundation @ 0x7fbd9f000000] Thread message queue blocking; consider raising the thread_queue_size option (current value: 512)

This typically means your system is too slow for realtime transcoding, therefore the input queue fills up after some time. Raising the input queue size rarely resolves this. Try using a faster preset or lower resolution and make sure the speed indicator in the ffmpeg output does not go below 1x even after a few minutes. Regards, Marton _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ffmpeg-user Info Page<http://ffmpeg.org/mailman/listinfo/ffmpeg-user> ffmpeg.org This list is for regular user questions like compilation troubles, command-line issues and similar. Please provide your ffmpeg command(s) and complete, uncut, unscripted console output(s) when possible. To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".

Yes I saw Theta's specifications too but when I'm retrieving camera's stream threw avfoundation, I just can see a video stream 3840*1920 with the rawvideo codec, despite specifications mention "H.264" for video codec. I don't really understand why, I'm going to repeat this workflow on Windows to benefite theta's drivers, and try to contact theta360 team in order to ask if it's possible to manage camera's output format.

If you go from "ultrafast" to "fast" and still achieve ~1x, you're okay. You can check how fast the pure decoding goes as such:

$ ffmpeg -i input_url -f null -

I'm not, If I chose fast instead of ultrafast, encoding speed is around speed=0,6. How I must analyze pure decoding speed ?

Additional question: Does this also give you issues with the thread cue size?

Yes it does. It's not a constant thing, but some tests fail because of this error, but 2 on 3 tests work fine. I don't know if CPU usage can be a factor ? Like if I'm doing something CPU-greedy during the stream, this warning has more chance to happened ? Cheers, Yaël ________________________________ De : ffmpeg-user <ffmpeg-user-bounces@ffmpeg.org> de la part de Moritz Barsnick <barsnick@gmx.net> Envoyé : jeudi 21 juin 2018 08:17 À : FFmpeg user discussions Objet : Re: [FFmpeg-user] Warning : Thread message queue blocking On Wed, Jun 20, 2018 at 15:41:58 +0000, yael Laouar wrote: (Please avoid top-posting on this list.) A lot of your questions are much easier to answer if you show us your (actual) ffmpeg command line and its complete, uncut console output.

You're meaning that if I raise the value, it'll simply extend the live stream duration without but problem but there's gonna be a problem at a time ?

Probably. If ffmpeg's stats output reports a processing "speed" of less than 1x, you're lost with your current settings. But see below.

The fact is I'm already using the preset configuration ultrafast, I can't go any faster. And when you say lower resolution, you mean the ffmpeg input resolution before transcoding ? Because I can't change that, I'm retrieving frames from the RICOH THETA V and it's 4k.

Hmm, the datasheet I found says:

File size and frame rate (live streaming): 3840 × 1920, 29.97 fps 1920 × 960, 29.97 fps

(https://theta360.com/en/support/manual/v/content/add_info/add_info_01.html) RICOH THETA V - User Guide<https://theta360.com/en/support/manual/v/content/add_info/add_info_01.html> theta360.com Specifications Image sensor: 1/2.3 CMOS (Effective pixels: Approx. 12.0 megapixels) × 2 File size (still images): 5376 × 2688 File size and frame rate (videos):

Speaking about speed indicator : during my stream my value is near constant at speed=0,999. Is that an acceptable value or this 0,001 will add a mini slowdown to the video ? Will, adding -re option, force the speed to 1 withtout drawbacks ?

No, that's probably slight variation and should be okay. Depending on the input format, "-re" might not change anything, but it probably doesn't hurt. (I'm saying: I don't know.) If you go from "ultrafast" to "fast" and still achieve ~1x, you're okay. You can check how fast the pure decoding goes as such: $ ffmpeg -i input_url -f null - Additional question: Does this also give you issues with the thread cue size?

ffmpeg -thread_queue_size 512 -f avfoundation -i "0:" -thread_queue_size 2048 -f avfoundation -i ":4" -crf 30 -preset ultrafast -strict experimental -vf scale=1920:960 -vcodec libx264 -tune zerolatency -pix_fmt yuv420p -r 30 -g 60 -threads 4 -acodec aac -ac 4 -b:a 512k -map_channel 1.0.0 -map_channel 1.0.1 -map_channel 1.0.2 -map_channel 1.0.3 -map 0:v -map 1:a -f flv rtmp://localhost/live_no_1/mon_flux

-vf scale=1920:960 If you manage to set the camera to deliver 1920x960 (and its rescaled quality is acceptable), you don't need your CPU to do rescaling. OTOH, your processing speed looks fine, in summary.

The rest I can't comment on. Cheers, Moritz _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".