A Raspberry Pi can send a live video source to YouTube with FFmpeg over Wi-Fi, but there is no single command that fits every setup. The correct command depends on whether your source is a Pi camera, USB camera, RTSP feed, or local media file, and whether the Pi must encode the video.
Think of the system as a chain: the source produces video and possibly audio, FFmpeg reads and prepares those streams, FFmpeg sends them to YouTube's ingest address, and YouTube reports whether the received feed is healthy. Testing each link separately is more useful than changing flags at random.
Map the source-to-YouTube chain
There are four parts to check:
- Source: a Pi camera, USB camera, IP camera, or media file creates the input.
- FFmpeg input: FFmpeg opens the source using the appropriate device, file, pipe, or network protocol.
- FFmpeg output: FFmpeg either copies compatible streams or encodes them into a format suitable for YouTube.
- YouTube ingest: FFmpeg sends the result to the URL and stream key shown in YouTube Live Control Room.
A successful connection only proves that FFmpeg reached an endpoint. It does not prove that YouTube is receiving the expected resolution, frame rate, audio, codec, or bitrate. Watch the local FFmpeg output and YouTube's stream-health messages as separate checks.
YouTube recommends RTMPS where the encoder and endpoint support it. Its current encoder guidance lists H.264, H.265, and AV1 video, AAC or MP3 audio, constant bitrate encoding, and a recommended two-second keyframe interval, with four seconds as the maximum. For a first Raspberry Pi test, H.264 video with AAC audio is a practical target because the command structure is widely understood, but the exact encoder available on your Pi still matters. See YouTube's live encoder settings and bitrate guidance before choosing final settings.
Keep the stream key private. YouTube treats it like a password. Do not paste a real key into a public script, screenshot, forum post, or shared terminal log. If it is exposed, reset it in Live Control Room.
Identify the Raspberry Pi, operating system, and FFmpeg build
Before writing a command, record the equipment and software that will run it. A command that works on one Pi may fail on another because the camera stack, operating system, FFmpeg package, or available encoder is different.
Useful checks include:
cat /etc/os-release
uname -a
ffmpeg -version
ffmpeg -devices
ffmpeg -formats
ffmpeg -codecs
You do not need to understand every line. You are looking for the Pi model, Raspberry Pi OS release, FFmpeg version, and whether the build includes the input and output support your source needs. For a USB camera, check whether the Video4Linux2 input is present. For an RTSP camera, check that the build can open the protocol. For hardware or camera-specific encoding, confirm the encoder name rather than assuming it exists.
If you use a Pi camera through Picamera2, treat camera capture and YouTube publishing as two related but distinct jobs. Picamera2 can configure the camera and produce encoded H.264 output, but the way that output is passed to FFmpeg, and how audio is added, must be designed for the particular program chain. The Picamera2 manual is the appropriate place to check camera configuration and encoding details.
Also check storage and power. A local file needs enough read performance for its format, while a camera needs a stable capture process. An underpowered board, a loose camera cable, or a USB device that repeatedly disconnects can look like an FFmpeg or Wi-Fi problem when the fault is earlier in the chain.
Choose input options for the actual source
The input determines the beginning of the command. Do not replace the input portion of a working example without checking what the source actually produces.
Pi camera
A Pi camera is not automatically a normal video device that every FFmpeg build can open directly. Depending on your Raspberry Pi OS and camera software, you may capture with a camera application, use Picamera2, or create an encoded stream and pipe it into FFmpeg.
A schematic pipe might look like this:
camera-capture-program [camera options] | ffmpeg -i pipe:0 [output options] '[YouTube ingest URL and private key]'
This is only a shape, not a ready-to-run Pi camera recipe. You must know the pipe format, whether the incoming data is raw or encoded, which process owns audio, and how timestamps are handled. A camera capture process that produces H.264 is a different input from one that produces raw frames. If audio is not included, you need a separate audio source or a deliberate silence track. The FFmpeg guide for adding silence to a YouTube stream covers that separate case.
USB camera
Many USB cameras appear through Video4Linux2, often as a device such as /dev/video0, but the supported pixel formats and frame rates vary. First inspect the device rather than selecting a size by guesswork:
v4l2-ctl --list-formats-ext -d /dev/video0
A schematic input is:
ffmpeg -f v4l2 -i /dev/video0 [video options] -i [audio source] [output options] '[YouTube ingest URL and private key]'
If the camera already supplies a suitable compressed format, you may be able to avoid a video re-encode. If it supplies raw frames, FFmpeg will need to encode them before publishing. USB cameras also differ on whether their microphone appears as an ALSA input, so do not assume that video and audio arrive as one device.
RTSP or IP camera
An IP camera adds another network path before YouTube: camera to local network, then Pi to YouTube. A schematic command is:
ffmpeg -rtsp_transport tcp -i 'rtsp://user:password@camera-address/path' [output options] '[YouTube ingest URL and private key]'
The camera's URL, authentication, transport, and stream layout are vendor-specific. TCP may be useful when you need a reliable RTSP transport, but it can behave differently from UDP on a busy network. Check the camera's own documentation and use a private account with only the access needed for the feed.
An RTSP camera may already produce H.264 video and AAC audio. If those streams match your selected YouTube settings, stream copying can reduce Pi CPU use. If the camera produces a format YouTube does not accept, or its frame rate and dimensions do not suit your plan, encode instead.
Local media file
A file is the simplest source to inspect because it is not dependent on a live camera. Start with:
ffprobe -hide_banner 'input-file.mp4'
Then use a file input such as:
ffmpeg -re -i 'input-file.mp4' [output options] '[YouTube ingest URL and private key]'
The -re option asks FFmpeg to read the file at approximately its native playback rate instead of sending it as quickly as possible. This is relevant when turning a recording into a live-style feed. Check the file's duration, audio presence, frame rate, and codec first. For playlists or continuous playback, handle the playlist logic separately from the first successful one-file test. A guide to continuously playing a video playlist on YouTube Live may be useful when the source is a collection rather than one file.
Decide whether to copy or encode the video
Stream copying means FFmpeg passes an already encoded stream through without decoding and re-encoding it. In a command this is usually represented by -c:v copy. It can greatly reduce CPU work, but it only works when the source codec and stream parameters are appropriate for the output.
Encoding means FFmpeg decodes the input and creates a new stream. This gives you control over resolution, frame rate, bitrate, keyframes, and audio format, but it uses more Pi resources and may not keep up in real time.
| Situation | First approach | Main advantage | Main risk to check |
|---|---|---|---|
| RTSP camera already produces suitable H.264 and audio | Test stream copy | Lower CPU load | Camera settings may not match the intended output |
| USB camera produces raw frames | Encode video | Predictable output settings | Pi may not encode at the chosen size or frame rate |
| Local file already has suitable H.264/AAC | Test stream copy with real-time reading | Little processing | File timestamps, audio, or container details may need adjustment |
| Pi camera is captured through a separate program | Verify the pipe first | Flexible camera control | Framing, timestamps, and audio ownership can be unclear |
| Source has unsupported codec or unsuitable dimensions | Encode or preprocess | Corrects incompatibilities | More CPU use and another possible failure point |
A stream-copy test might use a structure like:
ffmpeg -i '[source]' -c:v copy -c:a aac -b:a 128k -f flv '[YouTube ingest URL and private key]'
This is not universal. It assumes the source can be opened, that the video is suitable for the output, and that an audio stream exists or is supplied separately. If the source audio is already AAC, copying it may be possible, but validate the result rather than adding flags simply because they appear in an example.
An encoding structure might look like:
ffmpeg -i '[source]' \
-c:v [encoder available on this Pi] -b:v [selected video bitrate] \
-r [selected frame rate] -g [keyframe interval in frames] \
-c:a aac -b:a 128k -ar 44100 \
-f flv '[YouTube ingest URL and private stream key]'
The encoder name, bitrate, frame rate, and GOP value must be chosen for the specific Pi and source. A two-second keyframe interval expressed with -g depends on the frame rate, so it is not one universal number. YouTube's current H.264 recommendations list 5 Mbps for 1080p30, 17 Mbps for 1080p60, 3 Mbps for 720p30, and 8 Mbps for 720p60. These are platform recommendations, not proof that your Pi can encode them or that your Wi-Fi connection can sustain them.
Watch FFmpeg's speed indicator during a representative test. If it falls below real time, the Pi is not keeping up with the input. Reduce the workload by lowering resolution or frame rate, selecting a suitable hardware-assisted path where your build documents one, or using a source that is already encoded. Do not assume that a newer-looking encoder option is available merely because a tutorial uses it.
Build the FFmpeg output for YouTube ingest
Create an encoder stream in YouTube Studio and copy the current server URL and stream key from Live Control Room. Do not rely on an old endpoint copied from a forum post. Use the exact endpoint YouTube gives you, and prefer its RTMPS option when your FFmpeg build and setup support it.
The generic output shape is:
ffmpeg [input options] -i '[video and audio source]' \
[copy or encode options] \
-c:a aac -b:a 128k -ar 44100 \
-f flv '[YouTube-provided ingest URL plus private stream key]'
The quoted destination is a placeholder. Do not replace it with a real key in an article, script repository, or support request. Shell history can also retain secrets, so consider how you will enter and store the command on the Pi.
YouTube's guidance recommends constant bitrate encoding, two-second keyframes, and stereo AAC at 128 Kbps with 44.1 kHz sampling for the relevant setup. Treat those as target settings to compare with your source and encoder, not as a guarantee that every FFmpeg build will apply them exactly. The FFmpeg protocol documentation explains the RTMP family of protocol options, but it does not select your YouTube URL, key, source format, or encoder.
If the destination rejects the connection, separate an authentication or endpoint problem from a media problem. Check that the stream is configured for encoder input, that the key has not been reset, and that the URL was copied completely. If YouTube connects but shows warnings, inspect the codec, audio, resolution, frame rate, and bitrate instead of treating the connection as proof of a healthy broadcast.
Check Wi-Fi stability and upload capacity
The Pi must sustain the chosen stream bitrate over the actual Wi-Fi route from its final position. A speed test performed on a phone beside the router is not a useful substitute if the Pi is in another room, behind a wall, or connected to a different band.
YouTube's advice is direct: your outbound connection must be sufficient for the stream bitrate. Leave room for audio, bitrate variation, protocol overhead, and ordinary network activity. A stream selected near the measured upload limit has little margin when another device starts using the connection.
Test in this order:
- Put the Pi where it will run and connect it to the intended Wi-Fi network and band.
- Measure upstream capacity from the Pi, not only from another device.
- Run FFmpeg at the intended resolution, frame rate, and bitrate.
- Include the movement and audio expected in the real broadcast.
- Watch for Wi-Fi disconnections, packet loss, growing delay, FFmpeg warnings, and YouTube health messages.
- Repeat the test at a busy time if the channel will operate overnight or during household peak use.
The bitrates above are useful comparison points, but they do not turn Wi-Fi into a fixed-capacity link. If a 720p30 test remains healthy while a 1080p30 test produces warnings, the practical answer may be the lower setting. If the stream works on Ethernet but not Wi-Fi, compare signal quality, interference, router placement, and local network load before changing every FFmpeg option.
An RTSP camera makes this more difficult because its traffic also crosses the local network. The Pi needs enough capacity to receive the camera feed and send the YouTube feed, while the camera itself must remain reachable. A timeout can therefore come from the camera-to-Pi path or from the Pi-to-YouTube path. Test those paths independently.
For a channel that must continue while nobody is present, a home Pi also leaves you responsible for power, Wi-Fi, camera availability, storage, and recovery. That is the central trade-off in cloud streaming versus a spare PC for a 24/7 YouTube channel. If the source is a prepared file and your priority is avoiding an unattended computer, StreamNeo removes the need to leave that computer running by turning an uploaded video into a YouTube-only 24/7 stream, but it is not a Raspberry Pi or FFmpeg camera-ingestion method.
Test the feed in Live Control Room
Start with a private or otherwise appropriate test configuration and give YouTube time to analyse the incoming feed. Confirm that the preview shows the expected picture and that audio is present when it should be.
Use three separate observations:
- FFmpeg: Is the input open, is the encoder keeping pace, and are frames and audio packets being sent without repeated errors?
- Wi-Fi: Does the Pi remain connected, and does the route sustain the selected output without interruptions?
- YouTube: Does Live Control Room show reception, preview, stream health, and any codec, bitrate, or connection warnings?
YouTube specifically advises testing before starting a live stream and monitoring stream health. Perform a rehearsal with motion and sound similar to the planned broadcast. A static camera pointed at an empty room may hide encoding or bitrate problems that appear once the scene changes.
If the preview is black, verify the source before changing the network. If FFmpeg reports that it cannot open the device, inspect permissions, camera software, device names, and source reachability. If FFmpeg is sending frames but YouTube reports an unhealthy feed, check output codec, audio, keyframe timing, resolution, frame rate, and bitrate. If YouTube looks healthy but the broadcast later stops, investigate Wi-Fi, power, process supervision, and source availability.
Keep a small record of the working configuration: Pi model, operating system, FFmpeg version, source URL or device, resolution, frame rate, encoder, bitrate, audio settings, and the date you checked YouTube's current guidance. Do not record the private stream key in that document.
For long-running channels, plan recovery rather than assuming the first successful test will run unattended. A camera can disconnect, an IP address can change, a router can reconnect, or FFmpeg can exit after an input failure. If you are using a computer-based workflow, the practical differences between manual recovery and automatically restarting a stream when it crashes are worth considering before you call the setup finished.
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 one FFmpeg command work for every Raspberry Pi camera?
No. Pi camera access depends on the camera software, operating system, FFmpeg build, pixel format, and whether audio is present. Treat camera capture as its own stage, verify the output it produces, and then build the FFmpeg publishing command around that output.
Should I use stream copy or re-encode?
Try stream copy when the source already provides compatible video and audio and the parameters suit YouTube. Re-encode when the source format, dimensions, frame rate, bitrate, or audio needs to change, but confirm that the particular Pi can keep up in real time.
Is Wi-Fi reliable enough for a YouTube live stream?
It can be, but the answer depends on the Pi's location, network conditions, upload capacity, stream bitrate, and other traffic. Test from the final position using the actual FFmpeg settings, then repeat with representative movement and audio rather than relying on a short speed-test peak.
What should I do if YouTube receives the stream but reports warnings?
Check the layers separately. First confirm that FFmpeg is reading the expected source and keeping pace, then check Wi-Fi stability, and finally inspect YouTube's messages for codec, audio, resolution, frame rate, bitrate, or keyframe problems.