A Raspberry Pi that slows down during an FFmpeg YouTube stream may be thermal throttling, but heat is only one possible cause. Confirm the board’s temperature and throttling state while the representative stream is running, then check power, encoding load and network conditions before changing cooling.
The right remedy depends on the exact Pi model, enclosure and FFmpeg build. Pi 4 and Pi 5 do not have identical H.264 encoding paths, so first establish what your system can actually use.
Identify the board and the stream workload
Start with the model, not a cooler or a copied command. Pi 4 and Pi 5 differ in their encoding options, and details such as RAM, operating system, cooling and the installed FFmpeg package can change what is practical. Note the exact model and OS release, then record what the stream is doing: source resolution and frame rate, output resolution and frame rate, codec, bitrate, audio settings, and whether FFmpeg is decoding and encoding or mostly passing through compatible video.
The source file matters as much as the output. A 1080p source being resized and re-encoded demands more work than a compatible stream copy. A complex source codec, scaling, filters, overlays, or audio processing can add load before the video encoder even begins. If you run a looping channel, record whether the stream is stable with one file and whether transitions or other processing coincide with slowdowns. A practical guide to the shape of a continuous broadcast is how to send a playlist to YouTube Live; the same principle applies when you build a loop with FFmpeg: test the actual sequence, not just a short sample clip.
Keep a short baseline of the setup before changing it. Include the power supply and cable, case, room conditions, network connection, FFmpeg version and command line. Do not assume a Pi is running at the settings you intended: inspect FFmpeg’s output and the YouTube stream’s reported health during a test. If you use a browser or display on the same Pi, close unrelated work for the initial test, then add it back later if it is part of the intended setup.
For a channel meant to run unattended, distinguish the task of generating video from the task of keeping a broadcast available. The YouTube Live Control Room stream-key guide covers the platform-side setup; here, the question is whether the Pi can sustain your encoding workload without degraded performance.
Distinguish heat from other causes
Thermal throttling is a protective response: the board reduces performance as temperature rises. Raspberry Pi’s computer hardware documentation describes a defined SoC limit of 85°C. From 80°C to 85°C, Arm cores are progressively throttled; at 85°C, Arm and GPU frequencies are throttled. Those documented points explain the protection mechanism, but they are not a rule that every stream problem begins at the same temperature. Board and system behaviour, sensor readings and workload all matter.
A warm board or a temperature reading by itself does not prove that heat caused dropped frames. Look for evidence that performance changes as temperature rises and that a throttling flag is present. Even then, do not treat a single flag as a complete diagnosis: some flags describe current conditions and others indicate that a condition occurred earlier. Read the flag meanings for your board and software version, and capture readings over time rather than relying on one snapshot.
Power is an important competing explanation. Raspberry Pi documents that supply voltage below the specified threshold can trigger throttling. A weak or unsuitable supply, a poor cable or a connector problem can therefore affect clocks even when temperature is not unusually high. Check the supply recommended for your board and inspect the system’s undervoltage status. If a clock drops without a corresponding rise in temperature, investigate power before adding a fan.
Other causes can look similar from the viewer’s perspective. The encoder may be overloaded, the source decoder may not keep pace, storage may stall while reading a file, or a filter may be expensive. On the output side, a slow or unstable upload can affect YouTube stream health while the Pi continues encoding normally. Compare FFmpeg’s progress and error messages with the YouTube Live Control Room’s stream-health information; YouTube’s live encoder guidance advises testing and monitoring stream health.
Use a small set of questions to narrow the cause:
| What you observe | What to check next |
|---|---|
| Temperature climbs and a thermal throttling state appears during encoding | Compare with idle, inspect airflow, and check whether reducing encode load changes the result |
| Clocks fall but temperature remains comparatively steady | Check undervoltage state, supply and cable before attributing the problem to heat |
| Temperature and clocks are stable, but FFmpeg reports slow processing | Check encoder, decoder, filters, resolution and frame rate |
| FFmpeg keeps pace, but YouTube reports poor stream health | Check upload stability, bitrate and available headroom |
These observations can overlap. For example, high encoding load can raise temperature, while a network problem can independently interrupt the live output. Change one variable at a time so you do not mistake a coincidental improvement for a diagnosis.
Measure during a representative stream
Run the channel’s normal FFmpeg command for long enough to reach its usual steady workload. A test that is only a few minutes long may miss a problem that appears after the case warms up; a short test is useful for checking that the stream starts, not for clearing a 24/7 setup. Use the same file, output settings, enclosure and room location you expect to use, and monitor from another device so the Pi is not doing extra work to display the stream.
On supported systems, vcgencmd measure_temp provides an instantaneous SoC temperature reading. vcgencmd get_throttled reports throttling flags; consult Raspberry Pi’s documentation for how to interpret the returned bits on your board and software version. You can also read /sys/class/thermal/thermal_zone0/temp; the value is in millidegrees Celsius, so divide it by 1000 for Celsius. Raspberry Pi cautions that Linux readings can be inaccurate on some architectures, while its documentation describes vcgencmd measure_temp as an accurate instantaneous reading.
Take readings at idle, at stream start and at intervals while the stream continues. Log time, temperature, clock information if available, throttling state, FFmpeg progress and any dropped-frame or speed messages. Also note YouTube’s stream-health warnings and whether the local network is busy. A text log is more useful than a memory of the highest displayed temperature because you can compare the sequence: whether a throttle flag appeared before or after the slowdown, and whether it cleared when load or temperature fell.
A single command does not prove why frames were missed. Treat the measurements as evidence alongside FFmpeg’s processing speed, input and output timestamps, system load, and YouTube’s health report. If you only find a historical throttle flag after the test, it tells you that throttling occurred at some point, not necessarily when the visible issue occurred. Repeat a test after one change and compare the same measurements.
Check FFmpeg and the board’s encoder path
Before selecting an encoder, check the installed build. FFmpeg options depend on how that build was compiled and packaged; an encoder mentioned in a guide may simply be unavailable on your system. ffmpeg -version identifies the build, and ffmpeg -encoders lists encoders it exposes. You can inspect relevant help output with ffmpeg -h encoder=libx264 or a hardware encoder name that appears in your own list. Check supported input and output pixel formats as well as the encoder’s presence: a path that cannot accept your decoded frames may require conversion work that changes the load.
Do not transfer a Pi 4 recommendation to a Pi 5 by name alone. Raspberry Pi’s H.264 performance paper illustrates the distinction: its Pi 5 software-encoding example uses libx264, while its Pi 4 comparison uses the hardware encoder h264_v4l2m2m. The paper’s examples are not proof that your installed build offers either path in a usable form. Check your own encoder list, version, formats and actual FFmpeg output.
If libx264 is present, it is a software encoder and uses CPU resources. Its preset adjusts the speed-versus-compression trade-off: a faster preset generally does less work but may produce a larger file or require a higher bitrate for comparable visual quality. Raspberry Pi’s paper includes a low-latency Pi 5 example using the ultrafast preset and zerolatency tune, but that is an example configuration, not a universal command. Test a suitable preset with your source, output settings and upload capacity.
A hardware encoder can reduce CPU work where the board, driver, FFmpeg build and format pipeline support it. That does not make it a guaranteed drop-in replacement: formats, quality controls and latency differ, and conversions can consume resources too. Confirm the exact encoder and format support on the Pi, then compare CPU load, processing speed, stream health and picture quality in a real test. For a wider view of what a modest computer can sustain, see using a low-end PC for a 24/7 YouTube radio station, but do not assume that PC advice maps directly to a Pi’s encoder hardware.
Reduce encoding work before changing cooling
Start with the stream you actually need. If FFmpeg is falling behind, reduce one workload factor at a time: output resolution, frame rate, scaling or filters, then encoding complexity. Keep the original source unchanged for each comparison so you can see which adjustment helped. If the stream is a static devotional image with audio, for example, test whether your chosen frame rate is necessary rather than assuming that a source’s frame rate must be preserved.
Preserve YouTube’s ingest requirements while tuning. YouTube recommends RTMP or RTMPS for encoder ingest, supports H.264, recommends constant bitrate, and specifies a two-second keyframe frequency, not exceeding four seconds. Its current live encoder guidance recommends 14 Mbps for H.264 at 1080p30 and 8 Mbps at 720p30. These are ingest recommendations, not a promise that a Pi can encode those settings or that your connection can upload them. Check the current official guidance before going live, and choose a quality level the board sustains with upload headroom.
Bitrate is not a direct fix for CPU overload. Lowering it can help a constrained upload, but the encoder may still need to process every frame at the same resolution and rate. Conversely, keeping a high bitrate does not rescue an encoder that cannot keep pace. Make changes according to the evidence: reduce frame size or frame rate for encoding strain; address bandwidth and bitrate for upload strain; simplify the pipeline if decoding, scaling or filters dominate.
If you test a faster x264 preset, judge the result on the actual content. A low-detail static scene may tolerate a different quality trade-off from moving footage or detailed animation. Review the stream from a viewer device, check for blockiness or judder, and confirm that FFmpeg remains at the intended speed. Do not disable quality features or choose a preset solely because it appears in another person’s command line.
Once the workload is stable, retain the command and notes as a baseline. That makes later tests meaningful and gives you a known working fallback if a change causes problems. It also helps separate performance tuning from the different question of how to keep a stream running when the source application or device fails.
Improve cooling to suit the board and enclosure
Only move to cooling changes after you have evidence of persistent thermal throttling during the intended workload. First improve what costs nothing: remove obstructions around the case, provide open airflow, avoid placing the board in a hot enclosed space, and check that vents are not blocked by dust or a shelf. A heatsink works better when air can move across it; enclosing a board tightly can limit the benefit of passive cooling.
Raspberry Pi’s cooling white paper discusses extra cooling for high ambient temperatures, persistent workloads and airtight enclosures, and notes that video processing can be a sustained compute-heavy task. The official computer hardware documentation says a heatsink or small fan can reduce thermal throttling and improve performance. This is guidance to match cooling to conditions, not a guarantee that a particular accessory will fix dropped frames.
A passive heatsink has no moving part or fan noise, but relies on airflow and the case’s ability to shed heat. An active fan moves air across the board or heatsink and may be more useful for a sustained workload or warm room, at the cost of noise, power draw and additional physical fit considerations. Neither is universally better. Check whether a cooler fits the exact Pi revision and case, whether its airflow is obstructed, and whether the installation leaves ports and other components accessible. Compatibility varies by board and enclosure.
Pi 5-specific cooling claims should remain Pi 5-specific. Raspberry Pi’s article on active cooling for Raspberry Pi 5 reports behaviour under its own heavy stress-test conditions; it is not a duration threshold or prediction for your FFmpeg stream. Likewise, a case fan designed around Pi 4 fit should not be assumed to suit Pi 5. Match the accessory to the board and case, then measure the result under your workload.
Do not raise the thermal limit or overclock as a remedy for a stream that is already struggling. The limit is protective, and non-standard overclock settings can bring other consequences. If the Pi remains thermally throttled after workload reductions and reasonable airflow changes, consider a compatible active cooling setup or a different device better suited to the sustained job. The goal is steady encoding under observed conditions, not a lower number on a temperature display for its own sake.
Retest under the same conditions
After changing settings or cooling, repeat the representative stream test with the same source, duration, room placement, case, power supply and network path. Change only the item you are evaluating where practical. If you change from software to hardware encoding and add a fan in the same test, an improvement will not tell you which change mattered. Record the same temperature, throttling state, FFmpeg speed and YouTube health observations as before.
A useful result is not merely that the board runs cooler. Confirm that throttling no longer coincides with a performance slowdown, FFmpeg keeps up with the output timeline, and YouTube reports a healthy ingest. Also verify picture quality and audio sync from a viewer device. A fan may lower temperature without solving network instability; a smaller output may keep the encoder on pace without eliminating unrelated undervoltage. Keep the distinction clear when deciding whether a change succeeded.
Repeat after rebooting and starting the stream in the same way you intend to operate it. Check that the command, file paths, credentials and network connection are still correct, and observe enough of a representative run to catch the behaviour that led you to investigate. For a 24/7 channel, your practical test should reflect the normal unattended arrangement rather than an open bench setup with the case removed.
If the Pi cannot sustain the target after sensible tuning and compatible cooling, do not keep increasing complexity in pursuit of one more setting. Reassess the target resolution and frame rate, or use a device that can handle the workload with margin. If the recurring problem is keeping a loop live through local power, network or device interruptions, a cloud-based workflow may remove the need to keep this particular computer running; StreamNeo is designed for that specific computer-off pain, while it does not change YouTube ingest requirements or make an unsupported Pi encoder work.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does 85°C mean every Raspberry Pi stream starts throttling at that temperature?
No. Raspberry Pi’s hardware documentation defines 85°C as the SoC limit, with progressive Arm throttling from 80°C through 85°C and Arm and GPU throttling at the limit. Use the readings and flags from your own board during the actual stream; do not treat one temperature as a universal failure point.
Is a fan the first thing to try?
Not unless you have evidence that thermal throttling is occurring under the representative workload. Check the FFmpeg processing rate, temperature and throttle state, and investigate the power supply and upload path as well. Improve airflow and consider a compatible cooler if sustained heat is confirmed.
Can I use the Pi 4 hardware encoder instructions on a Pi 5?
Not automatically. Raspberry Pi’s examples distinguish Pi 4’s h264_v4l2m2m hardware path from Pi 5 software encoding with libx264, and your installed FFmpeg build may expose different options. Inspect the build and encoder formats, then test the available path with your real source.
If FFmpeg reports dropped frames, is heat the cause?
Not on that evidence alone. Encoding load, input decoding, filters, storage, power and upload conditions can all contribute to a stream problem. Compare logs and throttle state over time with YouTube’s stream-health information before choosing a remedy.