Run sudo apt update and then sudo apt install ffmpeg on Raspberry Pi OS. That installs the FFmpeg package, but it does not by itself create a YouTube Live broadcast.
A working stream also needs a usable media input, an FFmpeg build with the required support, YouTube's stream URL and key, suitable encoding settings, and enough upload capacity. Docker can package the process, but it does not remove the need to adapt the command to your source, Pi model, network, and destination environment.
Map the media-to-YouTube data path
A Raspberry Pi YouTube stream usually has four stages:
- A source provides media, such as a camera, a video file, a playlist, or an audio track with a visual background.
- FFmpeg reads that source and decodes it into frames and audio samples.
- FFmpeg encodes the media into settings YouTube accepts, such as H.264 video and AAC audio.
- FFmpeg sends the encoded stream to YouTube over RTMP or RTMPS.
The Pi can perform all of these jobs locally, but the workload depends on the input and output. A camera feed may need real-time capture and encoding. A pre-existing H.264 file may require less processing if it can be copied rather than re-encoded, although its format and bitrate still need to suit YouTube. A still image combined with audio requires FFmpeg to produce a continuous video stream.
Docker sits around this process rather than replacing it. It gives you a repeatable way to package FFmpeg and its supporting files. The container still needs access to the input, the network, configuration, and any hardware devices involved. A Docker restart policy can bring a stopped container back, but it cannot prevent every interruption, fix a failed input, or guarantee that YouTube accepts every reconnect.
This distinction matters when you move the same design to a VPS. A Raspberry Pi may be your capture device while a VPS performs the long-running encode, or the Pi may do everything itself. The correct VPS size depends on the number of channels, input type, output resolution, codec, frame rate, and whether the video is being re-encoded. There is no single specification that suits every stream.
If your planned channel uses a long pre-recorded loop rather than a camera, first consider the wider YouTube rules for 24/7 pre-recorded content. The technical path may work while the content plan still needs a separate review.
Choose and verify the media input
Installing FFmpeg does not require a camera. You can install it on a Pi that will process files, receive another source, or only be used for testing. A camera becomes relevant when you want the Pi to capture live video.
For a camera-based setup, confirm how the camera appears to the operating system before writing a stream command. Raspberry Pi's official camera documentation covers camera software and FFmpeg-related workflows in its camera documentation. A Raspberry Pi Camera Module 3 can be a suitable optional capture input, but it is not required for installation and should not be treated as a universal choice for every project.
For a file-based stream, begin with a file that represents the material you will actually broadcast. Check whether it contains video, audio, or both, and note its dimensions, frame rate, codecs, and duration. The following command is a useful inspection step:
ffprobe input.mp4
ffprobe is normally installed with the FFmpeg package. Its output helps you avoid assuming that a file has an audio track or that its frame rate matches your intended output. A file that plays on a desktop may still need conversion before it is suitable for a continuous live feed.
You should also decide whether FFmpeg needs to encode the input. Stream copying can reduce CPU work, but it only makes sense when the existing streams, timestamps, container, and output requirements are compatible. Re-encoding gives you more control over resolution, frame rate, bitrate, keyframes, and audio, but it consumes more processing capacity.
Network choice is part of input planning when the Pi is capturing and sending at the same time. Raspberry Pi documentation supports network access over Wi-Fi or Ethernet. Ethernet may be preferable where it is practical, but a supported Wi-Fi connection can also be used. Test the actual connection in the location where the Pi will run rather than relying on a result from another room or device.
Install FFmpeg and inspect the local build
For a normal Raspberry Pi OS installation, open a terminal locally or connect using the remote access method you have already configured. Raspberry Pi OS uses APT for packages, so refresh the local package lists first:
sudo apt update
Then install FFmpeg:
sudo apt install ffmpeg
Raspberry Pi's documentation gives this installation command for FFmpeg in its camera software guidance. The package manager may ask you to confirm the installation and may install supporting libraries as dependencies.
Confirm that the executable is available:
ffmpeg -version
The version output identifies the installed build, but it does not prove that every encoder or protocol is available. Inspect the local capabilities before choosing a command:
ffmpeg -encoders
ffmpeg -protocols
Look for the encoder and protocol that your planned workflow requires. Package builds can differ between OS images and releases. Do not assume that installing the generic package enables hardware video encoding, or that a command written for another Pi model will behave the same way on yours.
If APT reports that the package cannot be found, check that the package lists refreshed successfully and that the Pi has working network access. Avoid copying a random repository command into a production machine simply to obtain a different build. First identify the OS release and the package source you are using, then check current Raspberry Pi and Debian documentation.
The installation command is the stable part of this procedure. The encoding command is not. It must follow from the media input, available encoders, desired output, and upload connection.
Build or select an FFmpeg container
You can run the installed FFmpeg binary directly on Raspberry Pi OS, or place FFmpeg inside a Docker container. Direct execution is usually easier for a first test because the process can access local files and devices without container path or device mappings. Docker becomes useful when you want a defined runtime, a repeatable configuration, or a process that can be managed separately from the host system.
Before selecting an image, check its architecture support and the FFmpeg features it contains. A Raspberry Pi may use an ARM architecture, while an image built only for a different architecture may not run. Also check whether the image includes the encoder, protocol, and device support you need. An image name containing ffmpeg is not evidence that it is suitable for your input or Pi.
A minimal Dockerfile can make the package choice explicit when a suitable base image is not available:
FROM debian:stable-slim
RUN apt-get update \
&& apt-get install -y --no-install-recommends ffmpeg \
&& rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["ffmpeg"]
This is a starting point, not a complete production image. You would need to choose a base image that supports your Pi's architecture, add the media files or mount them at runtime, and decide how configuration will be supplied. You should also test the resulting image on the actual host rather than assuming that a successful build means the stream will encode in real time.
For a file-based input, a container might receive a read-only media directory. For a camera input, it may need access to the relevant device or camera interface. Those permissions are deliberately omitted from a universal example because the correct mapping depends on the camera stack and operating system setup.
Docker's own run reference explains how container options, mounts, environment variables, and restart settings work. Read the options against your actual layout. A command that mounts /media on one host will fail if the files are somewhere else, and a container that has no access to a camera cannot capture one.
When the same container is moved to a VPS, the constraints change. The VPS may have no camera, so the input must be a file or another network-accessible source. CPU capacity, memory, disk access, egress capacity, and provider policies also matter. Choose those resources from a measured workload, not from the fact that the Pi command ran successfully.
Pass stream settings and credentials safely
Create or select the live event in YouTube Studio, then obtain the stream URL and stream key from the encoder settings. YouTube's encoder setup guidance treats these as values you enter into the encoder before starting the broadcast.
Treat the stream key as a password. Do not put a real key in a Dockerfile, public shell history, tutorial screenshot, shared script, or source-control repository. If you think it has been exposed, rotate it in YouTube Studio. A placeholder is safer in documentation:
YOUTUBE_URL=rtmps://your-ingest-endpoint/app
YOUTUBE_KEY=replace-with-your-key
You can pass settings to a container through an environment file with restricted permissions, a secret-management system, or a protected deployment process. The exact method depends on where the container runs. Environment variables are more convenient than writing credentials into the image, but they can still be visible to processes or administrators on the host, so use access controls appropriate to the machine.
Separate the values that identify the destination from the values that describe the media. The destination includes the YouTube URL and key. The media settings include the input path, output dimensions, frame rate, codec, bitrate, audio rate, and keyframe interval. Keeping them separate makes it easier to change a file or output profile without exposing the credential.
YouTube lists H.264, H.265 and AV1 as supported video codecs for encoder-based live streaming, with AAC or MP3 audio. The practical choice still depends on your local FFmpeg build, Pi model, container image, and YouTube workflow. AAC is the relevant choice when you need 5.1 audio over RTMP or RTMPS, according to YouTube's encoder guidance.
Configure the YouTube output URL and media profile
YouTube recommends RTMPS, its secure extension of RTMP. Use the current ingest URL shown in YouTube Studio rather than copying an old value from a forum post. Keep the URL and key as separate configuration values where your chosen tool permits it.
YouTube also recommends constant bitrate encoding and a two-second keyframe interval, with an interval no longer than four seconds. These are platform recommendations, not proof that a particular Raspberry Pi can encode at the selected profile. A command must express the settings supported by your FFmpeg build and the input.
For H.264, YouTube currently lists these recommended video bitrates:
| Output target | YouTube H.264 recommendation | What you still need to verify |
|---|---|---|
| 720p at 30 fps | 8 Mbps | Pi encoding load and upload stability |
| 720p at 60 fps | 8 Mbps | Whether the input and build sustain 60 fps |
| 1080p at 30 fps | 14 Mbps | CPU capacity, thermals and upload headroom |
| 1080p at 60 fps | 17 Mbps | Real-time encoding and reliable delivery |
These figures describe YouTube's guidance. They do not guarantee performance on your hardware or connection. If the Pi cannot encode in real time, or the connection cannot sustain the video bitrate plus overhead, reduce the output target or move the encode to a more suitable machine. Do not select 1080p60 merely because YouTube lists it.
A generic command can show the shape of the configuration, but it is not a drop-in answer for every source:
ffmpeg -re -i /media/input.mp4 \
-c:v libx264 -b:v 8M -maxrate 8M -bufsize 16M \
-g 60 -c:a aac -b:a 128k \
-f flv "rtmps://your-ingest-endpoint/app/STREAM_KEY"
This example assumes a file input, H.264 support, a 30 fps output where a two-second keyframe interval corresponds to -g 60, and a bitrate chosen for a particular profile. Your source may need an explicit frame rate, scale filter, pixel format, audio mapping, or different keyframe value. A camera may require a device-specific input format. A file may contain no audio, or may need timestamps corrected. Inspect and test before adapting the command.
Do not paste the real stream key into a publicly shared command. In a container, keep the command and secret separate where possible. You can also use an environment variable in a private execution script, but make sure the resulting process and logs do not print the key.
Run the container on a VPS
A VPS is useful when the Pi is not the right place for a long-running encode, when the source files already live remotely, or when you want to separate capture from transmission. It is not automatically better. A VPS adds another network path and another machine to maintain.
Start by deciding where the media enters the system. If the Pi captures a camera, the VPS needs a reliable feed from the Pi. If the VPS reads a local file, upload or mount the file there. If it reads a remote object, confirm that the connection can deliver it continuously and that the source remains available.
A typical container run has to define at least the image, input mount, environment configuration, output command, and restart behaviour. In outline:
docker run --name youtube-ffmpeg \
--env-file ./stream.env \
--mount type=bind,src=/srv/media,dst=/media,readonly \
your-ffmpeg-image \
-re -i /media/input.mp4 \
[video and audio options adapted to your input] \
-f flv "$YOUTUBE_OUTPUT"
Treat this as a layout example, not a universal command. The image entrypoint may already invoke FFmpeg, the environment variable may not be expanded inside the container in this form, and the output options need to match your source and build. Test the exact image and command on the target VPS.
Size the VPS from observation. A single file that is already encoded may need a different CPU profile from several simultaneous camera encodes. Higher resolution and frame rate generally increase the work, but the actual cost also depends on codec, filters, input format, and available acceleration. Measure CPU use, memory, temperatures where relevant, dropped frames, and network behaviour during a representative test.
Check the VPS provider's current terms for sustained outbound traffic and any restrictions that affect your use case. Do not infer a provider limit from a different plan or an old guide. The same caution applies to storage and network capacity: they are deployment choices, not properties of FFmpeg.
Plan restarts and monitor the process
A container restart policy can help when the FFmpeg process exits unexpectedly. For example, Docker supports policies such as unless-stopped and on-failure, but the right choice depends on how you want intentional stops and repeated failures handled. Read the Docker restart policy documentation before applying one.
A restart policy does not fix a bad input, invalid stream key, exhausted disk, missing camera permission, unsupported encoder, or unstable network. It can also create a loop in which a broken process starts and exits repeatedly. Add logs and an alerting method so that a restart is visible rather than mistaken for continuous service.
YouTube recommends testing before starting a live stream and monitoring stream health. Run a representative pre-event test with the intended audio, movement, resolution, frame rate, and duration. Watch for dropped frames, encoder overload, audio silence, buffering, reconnects, and a growing delay between the source and the live output.
For a basic local check, inspect the process and container logs:
docker ps
docker logs --tail 100 youtube-ffmpeg
These checks only show that a container or process exists and what it has reported. They do not prove that YouTube is receiving healthy media. Use YouTube Studio's stream health indicators as well, and compare them with the FFmpeg log.
For a Raspberry Pi running directly on the host, a process check might include:
pgrep -a ffmpeg
The FFmpeg stream-checking guide can help you distinguish a running process from a stream that is actually delivering usable output. If YouTube repeatedly reconnects, review the input timestamps, output bitrate, upload capacity, keyframe settings, and the common causes of RTMP reconnects rather than only increasing restart settings.
For an always-on channel, also plan what happens after a power cut, router restart, unattended package update, or source-file error. Keep the Pi or VPS clock correct, leave enough disk space for logs, and document how to rotate the stream key. A small written recovery procedure is more useful than a command that only one person remembers.
If maintaining a Pi, Docker image, input path, and YouTube connection through the night is more operational work than you want, StreamNeo removes the need to keep that local streaming process running by letting you upload the video, provide the YouTube stream key, and run the broadcast from the cloud with automatic monitoring and restart handling.
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
Is sudo apt install ffmpeg enough to stream to YouTube?
No. It installs FFmpeg, but you still need a media input, compatible encoding settings, YouTube's stream URL and key, and enough upload capacity. You must also start the encoder and check the resulting stream in YouTube Studio.
Do I need a Raspberry Pi camera to install FFmpeg?
No. FFmpeg can process files or other inputs without a camera. A camera is only needed for a camera-based capture workflow, and its required device access depends on the camera software and operating system setup.
Can I use the same Docker command on every Raspberry Pi or VPS?
No. The command must match the input, architecture, FFmpeg build, encoder, resolution, frame rate, bitrate, mounts, and network. A VPS may also need different resources from a Pi because it could be encoding several streams or handling a different source.
Will Docker restart keep a YouTube stream online all night?
It can restart a process that exits, but it cannot prevent every interruption or repair an invalid input, credential, encoder, or network connection. Use restart settings together with logs, YouTube stream health checks, representative testing, and a recovery procedure.