A Raspberry Pi 5 can send a camera, USB video source, or prepared file to YouTube Live with FFmpeg. The reliable setup depends first on how your source enters the Pi, then on whether the Pi must encode the video in software.
For a Pi camera, USB camera, or file, use a source-specific FFmpeg input rather than copying a command written for different hardware. Start with a modest resolution and frame rate, use YouTube-compatible H.264 and AAC settings, and run an unlisted test before treating the stream as ready for an overnight broadcast.
Choose the input path before choosing the command
There is no single FFmpeg input command for a Raspberry Pi 5. A Pi camera, USB camera, video file, and separate microphone arrive through different interfaces, and each can produce different video timing and audio behaviour.
Raspberry Pi camera
For a Raspberry Pi camera module, use Raspberry Pi's current camera software, rpicam-vid, as the capture step. Raspberry Pi documents a libav backend that can encode audio and video and save or stream the result over a network. Check the camera documentation and the help output installed on your Pi before building a pipeline, because option names and available features depend on the software version.
A camera pipeline may therefore look like this in principle:
Pi camera → rpicam-vid → FFmpeg, if further muxing or encoding is needed → YouTube RTMPS
Do not assume that the camera path and a USB path use the same pixel format, audio device, or encoder. If rpicam-vid is already producing a suitable encoded stream, FFmpeg may only need to remux or pass the video through. If the format or timing is unsuitable, FFmpeg will need to encode it again.
USB camera
A USB camera commonly appears to Linux as a V4L2 video device, often with a path such as /dev/video0. That path is only an example. List the actual devices on your Pi and inspect the formats offered by the camera before writing the command. A camera may provide raw frames, MJPEG, or H.264, and those choices make different demands on the Pi.
Audio is separate unless the camera includes a microphone that the operating system exposes as an audio device. You must identify that device and map it explicitly. A video-only command cannot create sound by implication, and a guessed microphone name can leave a live broadcast silent.
Video file
A prepared MP4 file is usually the simplest source for a looped channel. It already has timestamps and may already contain H.264 video and AAC audio. You can sometimes copy those streams, but only when their codec, frame timing, dimensions, keyframes, and audio format suit the YouTube output you have chosen.
For a playlist or continuous file-based channel, first make sure the files are arranged in the intended order. The guidance in how to prepare a YouTube playlist for a continuous live stream is useful for the programming side, while FFmpeg still needs a stable source and predictable timestamps.
Separate microphone or no audio
Decide whether the broadcast should contain audio before you configure the output. A devotional camera stream might use a USB microphone, a USB camera microphone, or audio embedded by another device. A study or ambience stream might use audio already present in a file. If there is no audio, omit the audio input and audio mapping rather than creating a silent track without checking how YouTube displays it.
This choice also affects CPU load. Capturing and encoding an extra audio stream is not usually the main burden, but an incorrect device or sample-rate conversion can create failures that look like network problems.
Understand what Pi 5 software encoding means
Raspberry Pi's documentation states that Raspberry Pi 5 uses software video encoders. That matters because the Pi's processor must do the video compression work rather than relying on a general assumption that a camera stream will be encoded by dedicated video hardware.
Software encoding has two practical consequences. First, the time between a frame arriving and an encoded frame being ready can be longer, especially as resolution, frame rate, scene movement, and quality settings increase. Secondly, CPU use competes with everything else on the Pi, including capture, audio handling, storage, networking, monitoring, and any desktop services you leave running.
This does not mean that a Pi 5 cannot produce a useful live stream. Raspberry Pi documents 1080p30 as readily achievable with its low-latency camera option, but that is not a guarantee for every input, scene, FFmpeg build, or complete pipeline. A USB camera that sends raw frames may impose more work than a source that already supplies a suitable encoded stream. A busy scene can also be harder to compress than a mostly static one.
Start with the target rather than the maximum your camera advertises. For a first rehearsal, 720p30 is a sensible lower-load choice. Move to 1080p30 only after checking CPU use, frame delivery, audio sync, and upload stability together. If your channel is mainly a static devotional image, a lofi visual, or a text loop, the source may be easier to encode than a detailed moving scene, but you should still measure the actual pipeline.
Use the local FFmpeg build as the authority for available inputs and encoders. Commands such as these are diagnostic rather than a complete stream setup:
ffmpeg -devices
ffmpeg -encoders
ffmpeg -h encoder=libx264
If an encoder or input is absent, change the plan rather than copying an option from a different operating system image. The FFmpeg command documentation explains the general command structure, but it does not promise that every Raspberry Pi OS package has the same compiled-in features.
What the low-latency camera option changes
Raspberry Pi documents --low-latency for rpicam-vid. Its purpose is to encode frames more quickly for real-time use, which can reduce the delay introduced by the camera encoding stage. This is relevant when the picture must remain close to live action, such as a local announcement, teaching session, or camera pointed at an event.
It is not a universal fix for end-to-end delay. YouTube ingest, buffering, network travel, decoding, and the viewer's playback mode can all add delay after the Pi has produced a frame. If the Pi is already delivering frames promptly, changing the camera encoder may not be the main source of the delay.
The option also has documented trade-offs. Raspberry Pi says low-latency encoding can reduce coding efficiency, use multiple processor cores somewhat less efficiently, and potentially lower the maximum frame rate. In practical terms, you may need more bitrate for comparable image quality, or you may need to reduce resolution or frame rate when CPU headroom is tight. Do not describe it as a free performance improvement.
Treat the option as an experiment with a defined target. Run one representative test without it and one with it. Keep the resolution, frame rate, bitrate, scene, network connection, and audio source the same. Compare the observed delay, dropped frames, CPU pressure, and picture quality rather than changing several settings at once.
For a camera-only path, consult the installed help first:
rpicam-vid --help | less
Look for the low-latency option and the output or libav features supported by your installed camera stack. If you use rpicam-vid to create an encoded output and then pass it to FFmpeg, confirm whether FFmpeg is receiving a complete stream, raw frames, or a container. The next FFmpeg command depends on that distinction.
Prepare a YouTube-compatible output
YouTube accepts RTMP and RTMPS ingestion and lists H.264, H.265, and AV1 as supported video codecs, with AAC or MP3 audio. For a straightforward Pi setup, H.264 video with AAC audio is a practical compatibility target. YouTube recommends RTMPS, a secure extension of RTMP, for live streaming. See the current YouTube Live encoder settings before publishing, because platform guidance can change.
For H.264, YouTube's current settings table gives these figures for common targets. They are YouTube's published guidance, not a measurement of what every Pi can encode.
| Target | YouTube H.264 minimum | YouTube H.264 recommended | Keyframe guidance |
|---|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps | 2 seconds recommended, no more than 4 seconds |
| 1080p30 | 5 Mbps | 14 Mbps | 2 seconds recommended, no more than 4 seconds |
Use constant bitrate encoding and set a two-second keyframe interval where your source and encoder allow it. A 30 fps stream with a two-second interval commonly corresponds to a 60-frame GOP, but the exact FFmpeg expression depends on the frame rate and encoder. Make the relationship explicit instead of copying a fixed GOP value into a different frame-rate command.
Choose the bitrate with your upload connection in mind. A recommended value is not a reason to consume nearly all available upstream capacity. Leave room for normal fluctuation and for other traffic on the connection. If the upload path is uncertain, begin at 720p30 and compare the result with YouTube's stream-health messages.
An FFmpeg output section for an H.264 and AAC target may resemble this pattern:
-c:v libx264 -b:v 5M -minrate 5M -maxrate 5M -bufsize 10M \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k \
-f flv "rtmps://YOUR_CURRENT_INGEST_PATH/YOUR_STREAM_KEY"
This is a template, not a universal command. The bitrate and GOP shown here are examples that need to match the resolution and frame rate you select. The audio bitrate is also a setting to verify against the current YouTube guidance and your local FFmpeg build. Add the correct input, stream mapping, frame rate, pixel format, and filter options for the source before using it.
If the incoming video is already H.264 with suitable timing and keyframes, -c:v copy can avoid another software encode. That can reduce Pi CPU use and preserve the source's existing quality, but it does not repair an unsuitable GOP, frame rate, resolution, or timestamp sequence. Re-encode when the input does not meet the output contract.
Connect FFmpeg to YouTube Live
Create or select the live event in YouTube Studio, then obtain the current server address and stream key from Live Control Room. Keep the key private. Do not paste it into a public script repository, a forum post, a screenshot, or a tutorial command that others can copy.
Use the RTMPS address supplied by YouTube rather than constructing a path from memory. Google's ingestion documentation explains that the correct RTMPS endpoint, path, port 443, and server hostname or SNI matter for authentication and connection setup. Review the YouTube live streaming API ingestion guidance if you are troubleshooting a TLS or endpoint error.
Start with a private or unlisted event. Watch the FFmpeg console for connection failures, encoder errors, repeated reconnects, and messages indicating that frames are being dropped. At the same time, open Live Control Room and check whether YouTube is receiving the expected resolution, frame rate, audio, and bitrate.
If the connection fails immediately, separate the problem into parts. Confirm that the local input works, confirm that FFmpeg can write a local file or short test output, confirm the stream key is current, and then inspect the RTMPS address and network path. A TLS failure is not fixed by lowering the video bitrate.
Test latency and stream health before going live
A latency claim is only useful when you define where the measurement begins and ends. Pi encoding delay, network delay, YouTube processing, player buffering, and the viewer's playback mode are separate parts of the journey. Measure the complete journey using the same source, output settings, connection, and viewing device that you expect to use later.
For a useful rehearsal, show a clock, a changing counter, or a person making visible movements in front of the camera. Listen for speech or a repeated sound at the same time. Compare the action at the source with what appears in the YouTube player. A static image cannot reveal frame delay, and a silent loop cannot reveal audio drift.
Run the test long enough to expose the problems that appear after initial connection. Watch CPU pressure, temperature, memory use, network traffic, FFmpeg warnings, and YouTube's stream-health panel. The goal is not merely to see a picture for a short moment. You want to know whether frames continue arriving, whether sound remains aligned, and whether the Pi stays responsive.
YouTube's current guidance recommends testing with representative content and monitoring stream health. For a channel intended to run overnight, include the actual files, camera movement, microphone, and network connection in the rehearsal. If you change from a camera to a playlist later, test that path separately.
When delay is too high, test the low-latency camera option if you are using rpicam-vid. If CPU use is high, reduce the resolution, frame rate, or encoding complexity. If YouTube reports an unstable connection, compare the chosen bitrate with a measured upload capacity and try a lower target. If audio drifts, inspect timestamps, audio device stability, and whether the source is being resampled or re-encoded more than once.
For a channel that must remain online while your own computer is off, moving the completed file and channel setup to StreamNeo removes the need to keep the Pi capturing, encoding, and reconnecting all night; the Pi remains useful for testing a camera path or preparing the source.
Tune settings for the actual source
Once the basic path works, change one variable at a time. The most useful order is usually source format, resolution, frame rate, video bitrate, keyframe interval, audio, and then any low-latency option. Record each test in a small table so that a setting which looks better in one scene is not mistaken for a general improvement.
| Symptom | First checks | Sensible next change |
|---|---|---|
| Long delay from camera to player | Pi encoding time, YouTube latency mode, buffering | Test --low-latency, then reduce load if CPU pressure rises |
| Dropped frames on the Pi | CPU load, source format, background processes | Lower resolution or frame rate; simplify the pipeline |
| YouTube reports an unstable connection | Upload capacity, bitrate, Wi-Fi path | Use wired networking where practical and lower bitrate |
| Picture is soft or blocky | Bitrate relative to resolution and movement | Increase bitrate only if upload and CPU headroom allow it |
| No audio | Device name, input permissions, stream mapping | Verify the device independently and map the intended audio stream |
| Audio and video drift | Source timestamps, resampling, repeated encoding | Test a simpler path and inspect FFmpeg timestamp messages |
| RTMPS or TLS error | Server address, path, port, hostname and SNI | Copy the current YouTube ingest details exactly |
| FFmpeg rejects an option | Installed build and encoder help | Check ffmpeg -h, available devices, and available encoders |
A camera that supplies raw video may need more software work than a camera or capture source that provides H.264. Conversely, passing through an already encoded stream can preserve the source's limitations. Decide whether you value lower CPU load, lower latency, easier troubleshooting, or control over the final quality.
For long-running channels, reliability is also part of the media settings. Avoid running an unnecessary desktop session, prevent the Pi from sleeping, use stable power and networking, and save the final command in a private, readable script. A script should read the stream key from a protected environment or configuration file rather than exposing it in a shared command history.
If you are comparing a Pi with another always-on arrangement, the relevant question is not simply which device can send one successful test. Compare who handles restarts, monitoring, source storage, network interruptions, and the need to keep your own equipment powered. The Linux VPS guide for a 24/7 YouTube stream covers a different operating model, while the YouTube upload-speed guide helps you assess the connection independently of the encoder.
For a Pi camera stream, the practical starting point is therefore clear: verify the source, begin at 720p30 or a carefully tested 1080p30 target, use H.264 with CBR and a two-second keyframe interval, and test the low-latency option rather than assuming it belongs in every command. If your channel is intended to run continuously, also consider what happens when the camera, network, or process stops during the night. The article on why 24/7 YouTube streams lose viewers after a few hours gives useful context for that operational side.
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
Can a Raspberry Pi 5 stream directly to YouTube with FFmpeg?
Yes, provided the selected input, encoder, audio path, and network connection are supported by the software installed on the Pi. The exact command depends on whether FFmpeg receives a Pi camera output, USB camera frames, an encoded stream, or a file, so a command for one source should not be treated as universal.
Does Raspberry Pi 5 have hardware video encoding for this setup?
Raspberry Pi's documentation says that Raspberry Pi 5 uses software video encoders. Plan for CPU-based encoding unless your particular source is already supplying an encoded stream that FFmpeg can pass through, and verify the available encoders on the installed system.
Should I always use --low-latency with rpicam-vid?
No. It can make frames available sooner, but Raspberry Pi documents lower coding efficiency, somewhat less efficient use of multiple processor cores, and a possible reduction in maximum frame rate as trade-offs. Test it against the normal path with representative movement and audio.
What should I do if the stream works but YouTube reports poor health?
Check the upload path, selected bitrate, dropped frames, CPU load, and the current RTMPS endpoint first. Lowering resolution, frame rate, or bitrate may help, but change one setting at a time and confirm the result in Live Control Room rather than judging only from the local FFmpeg console.