4

I am using a Pi Zero W with the Pi camera (noir) to stream live to Youtube using ffmpeg. The command line I am using is:

raspivid -o - -t 0 -h 720 -w 1296 -fps 24 -b 6000000 | ./ffmpeg -ar 44100 -ac 2 -acodec pcm_s16le -f s16le -ac 2 -i /dev/zero -f h264 -thread_queue_size 512 -i - -vcodec copy -acodec aac -ab 128k -g 50 -preset ultrafast -crf 32 -strict experimental -f flv rtmp://173.194.183.168/live2/<MY_YOUTUBE_KEY>

When this starts running, I initially get a speed of ~1.5x/45 FPS. I assume that this reported speed is the rate at which ffmpeg is able to encode and send the output of raspivid. After this command has been running for a few minutes, the speed will (always) monotonically degrade until the FPS is less than the input (24), and the stream starts to lag. I have tried a number of changes to the command, including smaller video, lower frame-rate, lower quality, and even streaming to a local file instead of YouTube. The behaviour remains in all cases, and it seems as if ffmpeg itself is getting slower the longer it runs.

Does anyone have any idea what might be going on here, and how I can resolve this?

  • I apologize for the weak suggestion (since I can't provide any how to right now), but have you considered heat? Do you have a heat sink on the SoC chip? – Chad Farmer Jan 25 '18 at 18:51
  • It's a good suggestion Chad, and after posting this question I installed a few performance tools which let me monitor CPU load and temp. It gets a little warm (mid 60s Centigrade), but never above about 30% load and there does not seem to be any sort of performance event that triggers the slow down, which always starts happening after a few minutes. I had also thought about network speed, but my test of simply writing to file (same result) seems to rule this out as well.. – Matt Jan 25 '18 at 19:11
  • Too bad, a heat sink would be an easy fix. Writing to a file initially writes into cache, then slows down to the actual write speed when the cache is full. The network interface doesn't have a cache (but the remote machine does). If you can still monitor the frame rate, try writing to /dev/null. You won't be able to validate the (discarded) video, but you will eliminate any possible processor/memory/buss overhead from the write side. All I can think of right now... – Chad Farmer Jan 25 '18 at 23:00
  • Thanks for the idea, but unfortunately that doesn't work because /dev/null "exists" already and it won't write to it. I'm using the same of the rest of the command line, with -f flv /dev/null. Is there another way to do it? – Matt Jan 26 '18 at 9:21
0

You could try increasing the thread_queue_size to something like 4096 or even higher. I've seen it as high as 12000. I had a similar problem with my stream lagging and this seemed to fix it.

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.