To run an FFmpeg YouTube stream on Raspberry Pi OS Bookworm, first identify what is producing the video: a Pi camera, a USB camera, a file, or a network stream. Each source enters the signal path differently, and the right capture and encoding choices depend on the Pi model and the FFmpeg build installed on it.
The path is input, stream selection and any needed encoding, FLV muxing, then delivery to YouTube’s current RTMP or RTMPS ingest. Treat example command shapes as starting points, not verified recipes: check the options on your target image, test with your actual source, and keep the stream key private.
1. Start with the source
A Pi camera, USB camera, local video file and network stream are not interchangeable FFmpeg inputs. Before choosing flags, write down where video comes from, whether audio is part of that source, and whether the source already produces a format YouTube can accept. This prevents a common failure: solving an encoding problem when the actual issue is capture, or trying to capture a device through the wrong interface.
For a camera connected to the Pi’s camera interface, Bookworm uses the rpicam-* application names. Raspberry Pi’s camera documentation identifies rpicam-vid as the video capture application. Old instructions built around raspivid may refer to earlier software and should not be copied without checking that the tool and options apply to your system. The Raspberry Pi camera software documentation explains the current applications and their options.
A USB camera commonly exposes video through Linux’s Video4Linux2 interface, or V4L2. The device path, supported pixel formats and frame sizes are properties of the camera and installed drivers; discover them on the Pi rather than assuming that every camera appears at the same path or accepts the same capture settings. Audio may arrive through a separate USB device or sound interface, so video detection alone does not mean the whole programme is ready.
A file is simpler to identify but not necessarily simpler to deliver. It has a known duration, may contain several streams, and may already have codecs and parameters suited to YouTube—or may require conversion. A network source introduces its own protocol, authentication and buffering behaviour. Confirm that the Pi can receive and decode it before adding YouTube as a second network leg.
If your source is a prerecorded loop rather than a live camera, the decision is often whether the Pi needs to run the process continuously at all. A guide to sending one video repeatedly with FFmpeg covers that distinct case. This page focuses on identifying the input and building a path that you can validate on Bookworm.
2. Trace the signal path before writing a command
Draw the route from source to YouTube in plain language. A Pi camera path might be camera sensor → rpicam-vid capture → FFmpeg processing or packaging → FLV output → RTMPS ingest. A USB camera path might be V4L2 video plus a separate audio input → FFmpeg stream selection and encoding → FLV → ingest. A file or network path starts with FFmpeg reading an existing container or protocol instead.
This distinction matters because FFmpeg options belong to different parts of the route. Input options go before the input they configure; output options go after the inputs and apply to the output. A camera’s frame size is a capture choice. Selecting audio and video streams is a mapping choice. A codec, bitrate control mode and keyframe interval are output or encoding choices. Putting an otherwise valid option on the wrong side of an input can make it apply somewhere other than intended.
FFmpeg can copy a compatible compressed stream without decoding and re-encoding it, or decode and encode it into a chosen output format. Copying can reduce work on the Pi but cannot change a codec or repair unsuitable video parameters. Encoding offers control over the output but consumes compute and can introduce dropped frames if the Pi cannot keep up. The correct route is determined by source inspection and a test, not by the fact that a command starts.
The last local step is muxing: putting the selected audio and video streams into the output container expected by the delivery protocol. FFmpeg’s protocol documentation describes RTMP options, but the installed build and its help output are the practical reference for your machine. YouTube recommends RTMPS, a secure extension of RTMP; use the endpoint and stream settings shown in Live Control Room rather than treating an endpoint copied from an old tutorial as permanent.
3. Check the Pi and its Bookworm build
Record the Pi model, operating-system image and installed FFmpeg version before planning the encode. Raspberry Pi models do not all offer the same hardware video-encoding path. Raspberry Pi documents hardware H.264 encoding where available; Pi 5 uses software video encoders. Do not assume that a command that uses a hardware encoder on one generation will work or perform the same way on another.
On Bookworm, install or update software through the system’s package-management tools as appropriate for your image, then inspect the tools actually available. Check the FFmpeg version and its help and encoder listings on the Pi. The Debian Bookworm FFmpeg manual is useful for general command-line behaviour, but it does not guarantee that a particular Raspberry Pi OS image has every codec or encoder listed in a guide.
Check both the executable and the camera tools if using a Pi camera. The available capture options can depend on the camera stack, model and installed packages. If a proposed option is rejected, inspect the local help output and camera documentation rather than adding flags until the error disappears. A successful parse of a command still does not prove that the device can sustain the chosen resolution, frame rate or encoding method.
The Pi 5 distinction is especially important for a camera workflow. Raspberry Pi documents a --low-latency option for its software encoding path that emits frames sooner, with trade-offs in coding efficiency, maximum frame rate and multicore use. The documentation states that the Pi 5 can achieve 1080p30, but that is a Raspberry Pi statement about its documented capability, not a test of your camera, audio chain and YouTube output together. Begin with a conservative configuration and validate real motion on the target device.
4. Capture according to the input
For a Pi camera, separate capture from delivery. rpicam-vid captures video; depending on the workflow, it can produce an encoded bitstream or use its libav backend. Raspberry Pi’s documentation says that the libav backend uses hardware H.264 when present. Whether you send capture output into FFmpeg or let a capture tool handle more of the path depends on the desired processing and the installed software. Do not assume a pipe format or encoder option without confirming the current tool’s output and the FFmpeg input settings.
For a USB camera, inspect the V4L2 device’s actual capabilities before choosing input options. Confirm the device node, supported formats and the camera’s available sizes and frame rates. If the device can output compressed video that suits the planned stream, copying may be possible; if it outputs raw frames or an unsuitable format, encoding is likely required. Add audio as a separately discovered input when appropriate, and check synchronisation with a recording or private test.
For a local file, inspect its duration, streams, codecs and frame properties before sending it. Decide whether you are sending it once, looping it, or using it as part of a programme; those are different operating behaviours. A finite file can end while the YouTube broadcast is still expected to continue, so make sure the process behaviour at end-of-file matches your intention. If the stream is intended to stay live after a clip ends, see the guide on keeping a live tour active after a video file ends.
For a network input, test reception independently before sending anything to YouTube. Confirm that the source URL is reachable from the Pi, that credentials are handled safely, and that FFmpeg can read the incoming streams. The network source’s transport and codecs affect buffering and whether stream copy is sensible. If both source and destination use the network, upload capacity is not the only concern: an unstable or delayed incoming feed can make the outgoing stream unhealthy even when the Pi has spare processing capacity.
In every case, confirm whether there is usable audio. A camera may provide no audio, while a USB microphone or interface can be a distinct input. A file may contain multiple audio tracks or none. Mapping an absent or unintended track can result in silence, the wrong language, or an output that fails to mux. Check the selected stream with a short recording or test broadcast rather than relying on a command’s exit status alone.
5. Decide whether to copy or encode
Stream copy avoids a new encode: FFmpeg passes a compressed stream through to the output. It is appropriate only when the input codec and stream characteristics fit the output container and YouTube’s current ingest expectations. It will not convert a camera’s raw frames into H.264, change a frame rate, rescale an image, add a missing audio codec or fix a problematic keyframe cadence. If one of those changes is needed, the relevant stream must be encoded.
Encoding lets you choose output characteristics, but the Pi’s capacity is finite and model-dependent. Resolution, frame rate, filters, audio processing and codec all contribute to the work. Start with a modest target appropriate to the programme and verify sustained operation with movement and sound, not a static screen alone. A lofi scene with little movement and a local news camera with frequent motion are different tests even if their nominal frame size is the same.
YouTube’s current live encoder settings guidance lists H.264, H.265/HEVC and AV1 video, and AAC or MP3 audio. It recommends constant bitrate (CBR), keyframes every two seconds and says not to exceed four seconds. It lists a maximum frame rate of 60 fps, and recommends stereo audio at 44.1 kHz and 128 Kbps. These are YouTube-published recommendations, not proof that a given Pi or FFmpeg build can encode every listed format in real time. Choose only a codec your installed build supports and your Pi can sustain.
Use the current YouTube page for the bitrate appropriate to your resolution and frame rate rather than guessing or reusing a value from an unrelated setup. The research and test here do not establish a universal bitrate for every source. For an always-on stream, a stable, supportable output is more useful than selecting a high setting the Pi or network cannot maintain. For the network side, this upload-speed guide for a 24/7 stream in India explains why you should measure the actual connection and allow for normal variation.
6. Mux and send using current ingest settings
FFmpeg commonly writes an FLV-muxed output when delivering RTMP. The protocol URL and output settings should use the active configuration supplied in YouTube Live Control Room. YouTube recommends RTMPS; its current encoder page explains the supported ingest approach. Do not assume one fixed server name, endpoint suffix or key arrangement will suit every account or remain unchanged. Copy the active settings from the control room when you prepare the broadcast.
A command’s conceptual shape is: declare capture or input options, identify each input, select the intended streams, apply encoding only where needed, set output muxing and delivery options, then provide the configured ingest destination. This is not a ready-to-run command. For a Pi camera, the capture side may be handled by rpicam-vid; for V4L2, the input options describe a device; for a file or network source, FFmpeg reads the relevant media or protocol. Substituting one input block for another without checking the installed options is a common source of errors.
Keep the stream key out of shell history, public scripts, screenshots and support posts. If you put a key in a command line, it can be exposed to anyone who can inspect that command or its history. Prefer a method appropriate to your system for storing and supplying secrets, restrict access to the files that contain them, and avoid pasting a key into logs when asking for help. If you believe it has been exposed, use YouTube’s account controls to replace or reset it and update your local setup.
A correct FFmpeg output does not itself make a stream public or healthy. Confirm the destination, visibility and scheduled event in YouTube, then watch the Live Control Room’s stream-health information. YouTube advises testing with representative movement and audio before the event and monitoring messages while live. A short successful test tells you more than a command copied from another Pi, but it does not guarantee that a long-running session will not need attention.
7. Validate the actual image and plan for operation
Run the test on the same Pi model, Bookworm image, camera, audio path and network connection you intend to use. First validate each stage locally: capture a short sample or confirm that FFmpeg reads the source; check that the selected audio and video streams are the expected ones; confirm the output encoder is available; then test a private or unlisted YouTube event. This isolates whether a failure is in capture, encoding, muxing or delivery.
Include representative motion, scene changes and the actual audio. Watch for dropped or delayed frames, audio that disappears or drifts, a stream that arrives at the wrong aspect ratio, and warnings or health messages in YouTube. A static desktop preview can conceal a camera’s exposure or motion issues. If the Pi becomes overloaded, reduce the work: consider a lower resolution or frame rate, fewer filters, a suitable stream-copy path, or a different machine for the job.
A 24/7 channel also needs a recovery plan. Decide who can see the device, how it reconnects after a network interruption, and how you will tell whether the channel is still transmitting the intended content. Test recovery by observing the behaviour in a controlled test rather than assuming a process will restart itself. If remote observation is part of the workflow, the remote monitoring guide for a YouTube playlist stream offers a separate perspective on checking a running broadcast.
The Pi may be a good fit when the source is local, the encoding load is modest and you can maintain the device and network. It may be a poor fit when you need heavier encoding, cannot tolerate a local power or internet interruption, or need unattended recovery without someone nearby. In that case, compare a cloud workflow with the operational cost and source-transfer requirements; a guide to prerecorded streaming from a VPS covers that alternative. Neither approach removes the need to test the programme and review YouTube’s current requirements.
StreamNeo can remove the need to leave a Pi or desktop running when the job is simply to turn an uploaded video into a YouTube broadcast, but it is not a camera-capture replacement and is YouTube-only. For a live camera feed, local capture and an appropriate encoder remain part of the signal path.
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
How do I stream from a Raspberry Pi to YouTube Live with FFmpeg?
Identify the source, check the Pi’s installed capture and FFmpeg capabilities, then select, encode if needed, mux and send to the active YouTube ingest settings. There is no single command that is validated for every camera, audio device, Pi model and Bookworm image, so test your exact path before going live.
Can I stream a Raspberry Pi camera to YouTube?
Yes, the Bookworm camera applications use the rpicam-* naming, and rpicam-vid is the current video capture application discussed in Raspberry Pi’s documentation. How you connect its output to FFmpeg depends on the capture mode, build and model; verify the options locally and test the full output path.
Does a Raspberry Pi 5 use hardware H.264 encoding?
Raspberry Pi documents Pi 5 as using software video encoders, unlike models where hardware H.264 encoding is available. The software path has different latency and load characteristics, so do not copy a hardware-encoder recipe from another Pi without checking the current documentation and testing on your device.
Should I use RTMP or RTMPS, and where do I get the key?
YouTube recommends RTMPS and provides the active ingest configuration in Live Control Room. Use those current settings, keep the key private, and replace it through your account controls if it is exposed.