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://<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? 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... 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
  • 1
    @ChadFarmer I doubt the bitrate of ffmpeg is anywhere near the limit of the SD card data rate (6Mbps is less than 1 megabyte per second). Writing to a file should be good enough for a test. Apr 5 '21 at 12:39

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.


How much RAM do you have? I'm wondering if you are running out of memory room the longer you stream.

If this is the problem, do this:

sudo dd if=/dev/zero of=/swap1 bs=1M count=2048
sudo mkswap /swap1
sudo vim /etc/fstab

This will open up your fstab file. You may or may not have a swap file. If you see something like,

/swap0 swap swap

You already had a swap so replace that line with the following( if the line is absent add the following line to your fstab file)

/swap1 swap swap

Reboot your Pi.

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.