Hardware encoding on a Raspberry Pi is conditional, not a setting you can safely copy from an old tutorial. Check the exact board, camera path, operating system and installed FFmpeg build first, then use hardware H.264 only if that combination exposes and runs it.
For a camera stream, the practical route is to capture H.264 where appropriate, avoid encoding the same video again, and send a constant-bitrate RTMP or RTMPS feed with suitable keyframes to YouTube. Raspberry Pi 5 needs particular care because Raspberry Pi’s current camera documentation describes its video encoders as software encoders.
Start with the board and the software path
Before changing an FFmpeg command, write down four details: the Raspberry Pi model, the Raspberry Pi OS release, the camera or capture device, and the application that will perform the capture. These determine which encoder names, device nodes and pixel formats are available.
A command written for an older Raspberry Pi may refer to an encoder that is absent from your installation. The same board can also behave differently after an operating-system, kernel or FFmpeg package change. The name shown in a forum post is not proof that the encoder exists on your Pi, nor that it can sustain your chosen resolution and frame rate.
You can identify the board with:
cat /proc/device-tree/model
uname -a
cat /etc/os-release
ffmpeg -version
The first command usually reports the board model. The other commands provide useful context when you are checking a guide or asking for help. Record the output before making changes, because a later package update can alter the available codecs without changing the camera itself.
Next identify the capture route. A Raspberry Pi camera using the current camera applications is a different path from a USB webcam exposed through Video4Linux2. A capture card may provide another path again. You should not assume that an H.264 camera output, a raw camera output and a V4L2 M2M encoder are interchangeable.
For an always-on channel, this initial inventory is worth doing even if your first test is only a few minutes. It prevents you from spending a night troubleshooting an encoder name that belongs to a different board or an old package. If the camera is only one part of a longer workflow, the go-always-live checklist is useful for checking power, networking and recovery before you leave the stream unattended.
When hardware H.264 encoding is available
Raspberry Pi’s camera documentation uses an important qualification: rpicam-vid uses hardware H.264 encoding “when available”. That means availability depends on the board and the software path, rather than being a universal property of the Raspberry Pi name.
Read the current Raspberry Pi camera documentation for the capture application you are using. It documents H.264 controls such as bitrate, I-frame interval, profile and level for the camera-side encoder. Those options are relevant when rpicam-vid is doing the encoding, but they do not automatically become FFmpeg options with identical names or behaviour.
There are two broad ways to build the video path:
| Path | What does the encoding | Main advantage | Main risk to check |
|---|---|---|---|
| Camera application produces H.264, then sends it onward | The camera application | It can avoid a second video encode | The output must have suitable timestamps, format, bitrate and keyframes |
| Camera or capture device supplies video to FFmpeg | FFmpeg, if its selected encoder works | FFmpeg can control muxing, audio and delivery | A software encode may use substantial CPU, while a hardware device may be missing or unsupported |
The first path can be efficient when the camera application already produces a YouTube-suitable H.264 stream. FFmpeg may then copy the video while handling the container and audio. The second path gives more control over conversion and synchronisation, but it adds an encoding decision that must be tested on the actual Pi.
FFmpeg includes a Video4Linux2 memory-to-memory H.264 wrapper. The existence of that wrapper in FFmpeg documentation means FFmpeg knows how to communicate with that interface. It does not establish that your kernel exposes a working encoder device, or that your installed Raspberry Pi package was built with the relevant support.
That distinction matters more than an encoder list copied from another machine. A Pi can show an encoder name and still fail when it opens the device, rejects a pixel format, or cannot maintain the selected frame rate. Treat hardware encoding as confirmed only after a short, representative test succeeds and the Pi remains responsive.
Do not recommend or select h264_omx merely because it appears in an older Raspberry Pi tutorial. Verify the current board, driver and package instead. If the exact combination is not documented and tested, use a simpler path or reduce the workload rather than relying on a historical encoder name.
Why Raspberry Pi 5 changes the decision
Raspberry Pi 5 is the clearest reason not to generalise from older boards. Raspberry Pi’s current documentation explicitly says that Raspberry Pi 5 uses software video encoders. It should therefore not be presented as a board with hardware H.264 encoding available through the same route as an older model.
Software encoding can still produce a valid YouTube stream. The trade-off is that the CPU performs the H.264 work, leaving less headroom for camera processing, audio, network handling and recovery scripts. A modest 720p30 stream may be a more sensible starting point than a higher-resolution stream, but the right choice depends on the scene, encoder settings and the rest of the workload.
The useful response is not to search for a different old encoder flag. First test whether the selected software encoder can sustain the intended output without dropped frames or thermal and CPU problems. Then decide whether to lower the resolution, lower the frame rate, use a camera-side H.264 output where appropriate, or move the continuous encoding job elsewhere.
Video copying is especially valuable on a software-encoding device. If the camera application already supplies H.264 with the required properties, re-encoding it in FFmpeg adds work without improving the picture. Copying is not automatic, however. You must still verify that the stream has usable timestamps, an appropriate frame rate, a compatible H.264 profile and regular keyframes.
This is also why a Raspberry Pi 5 camera project and a pre-recorded 24/7 channel are different problems. If you are looping files rather than capturing a camera, compare the FFmpeg method for looping pre-recorded videos on YouTube Live with a camera pipeline. A file-based stream may avoid live capture entirely, while a camera stream must deal with changing frames, audio timing and device interruptions.
Inspect the FFmpeg build you actually have
Run the following on the Pi rather than on a desktop computer:
ffmpeg -hide_banner -encoders
ffmpeg -hide_banner -decoders
ffmpeg -hide_banner -formats
ffmpeg -hide_banner -h encoder=libx264
ffmpeg -hide_banner -h encoder=h264_v4l2m2m
The last command may report that the encoder is unavailable. That is useful information, not a failure in your investigation. If it is listed, you still need to test it against the device and input format. FFmpeg’s codec documentation explains the encoder interface, but it cannot provide a complete support matrix for every Raspberry Pi OS image, kernel and camera.
Check the input separately. For a USB or capture-device route, list Video4Linux2 devices and formats with tools available on your system, such as:
v4l2-ctl --list-devices
v4l2-ctl --list-formats-ext -d /dev/video0
Replace /dev/video0 with the device reported for your camera. Some devices offer raw formats, while others offer H.264 directly. A format that appears in a list is not necessarily stable at every requested size and frame rate, so make a short recording before turning it into a live broadcast.
For the encoder test, use a short local output first. Confirm that FFmpeg opens the camera, accepts the selected format, creates H.264 and runs at the intended rate. Watch CPU usage and the FFmpeg log. A command that exits cleanly after a few seconds has not yet proved that the device will run unattended overnight, but an immediate device or format error saves you from debugging YouTube at the same time.
Keep the test output private. Never put your real YouTube stream key in a command pasted into a public issue, screenshot, shell-history example or repository. Use a placeholder in documentation and insert the private key locally.
Capture camera video in H.264 where appropriate
If you use a supported Raspberry Pi camera, rpicam-vid is often the first path to examine. Raspberry Pi documents an integrated --codec libav route that can encode audio and video and stream over a network. The documentation also states that the camera application uses hardware H.264 when it is available, so the result remains conditional on the board.
A basic inspection command is:
rpicam-vid --help
Do not treat the following as a universal broadcast command, but note the types of controls you need to map to your target. The camera application exposes a bitrate in bits per second and an I-frame interval in frames, along with H.264 profile and level options. At 30 frames per second, an I-frame interval selected for roughly two seconds would be around 60 frames, subject to the application’s actual interpretation and the platform guidance you are following.
The important point is the conversion between frames and time. YouTube describes keyframe frequency in seconds, while a camera application may ask for an interval in frames. If you change the frame rate, recalculate the interval rather than retaining the same frame count. Check the resulting stream with a short test and inspect the live status page.
For a camera that already outputs H.264 in a suitable form, a conceptual FFmpeg command may copy the video instead of encoding it again:
ffmpeg -i camera-input \
-c:v copy -c:a aac -b:a 128k \
-f flv "rtmps://your-ingest-url/app/STREAM_KEY"
This is a pattern, not a guaranteed command for every rpicam-vid output. The input may arrive over a pipe, a local socket or a network endpoint, and its audio may need different handling. The output may also require timestamps or a format adjustment. If the H.264 stream does not meet the delivery requirements, use a tested re-encode rather than forcing -c:v copy.
When FFmpeg must encode the video, select only an encoder that your local inspection and test confirm. A software example might use libx264, while a V4L2 M2M example would use the locally exposed h264_v4l2m2m path if the device and build support it. Do not infer that either option will work from the name alone.
Audio needs its own test. A camera may provide no audio, while a USB microphone may appear as a separate input. You need one coherent audio and video timeline before sending the stream to YouTube. For a simple stereo AAC track, YouTube’s current guidance lists 128 kbps as a recommendation, but follow the current platform page if its requirements change.
Send a compatible feed to YouTube Live
YouTube accepts live encoder feeds over RTMP or RTMPS. YouTube recommends RTMPS, the secure extension of RTMP, for live streaming. Use the server URL and stream key shown in YouTube Studio, and keep the key private.
The stream should normally be H.264 video with constant bitrate, an audio track in a supported format, and regular keyframes. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. These are delivery requirements to apply to the encoded output, not proof that a particular Raspberry Pi encoder has produced them.
The current YouTube live encoder guidance provides the authoritative settings and should be checked before publication. YouTube can change its recommendations, and the Live Control Room will report stream-health messages that are more useful than guessing from a command line.
A robust test sequence is:
- Start with a private or unlisted broadcast in YouTube Studio.
- Use the same camera, resolution, frame rate, audio and network connection planned for the real channel.
- Send a short test with representative movement, not only a static lens cap or still image.
- Watch the FFmpeg log and YouTube’s stream-health panel together.
- Confirm that the preview, audio and keyframe behaviour are acceptable before making the stream public.
This test catches problems at the boundaries. A local encoder test may succeed while the network upload fluctuates. A clean network test may still reveal audio drift or unsuitable timestamps. A picture that looks fine in the preview may have dropped frames that become obvious after the process has run longer.
If you need to stop the stream and start again, check how your broadcast is configured in YouTube Studio. Do not assume that restarting FFmpeg has the same effect as ending a broadcast. For an always-on channel, document the restart procedure and keep a spare, tested command without exposing the private key.
Match resolution and bitrate to the uplink
YouTube’s published H.264 guidance gives useful starting points for two common 30-frame-per-second outputs:
| Output | YouTube-listed H.264 minimum | YouTube-listed recommended bitrate |
|---|---|---|
| 720p30 | 3 Mbps | 6 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
These figures are platform recommendations, not a promise that your internet connection can sustain them. The uplink must maintain the selected bitrate over time, with room for normal network variation and other traffic. A connection that briefly reaches a target is not the same as one that can hold it through the night.
A smaller resolution is often the more reliable choice for a Pi camera installation with limited upload capacity or CPU headroom. A larger output can show more detail, but it raises the encoding and network workload. Test the real scene: leaves moving in wind, people crossing the frame, text on a noticeboard or changing devotional artwork can all produce a different workload from a static room.
Constant bitrate does not mean the network will be constant. It describes how the encoder targets the stream. You still need a stable uplink, suitable rate control and enough headroom. Watch YouTube’s health indicators during the test rather than assuming that the number in the FFmpeg command is the number arriving at the platform.
If a camera-side H.264 stream is already close to the required bitrate and keyframe interval, copying it can preserve CPU for capture and networking. If its settings are wrong, re-encoding may be necessary. That gives you control over bitrate, profile and keyframes, but on Raspberry Pi 5 the additional software work deserves particular attention.
For a channel that does not need live camera input, a spare computer may be easier to manage than a Pi camera stack. The practical comparison in how to keep a YouTube Live stream running from a spare PC can help you decide whether the Pi is solving a real constraint or simply adding another device to monitor.
Make the overnight test meaningful
A successful five-minute preview is only the beginning. Let the exact capture and delivery path run long enough to expose thermal behaviour, storage issues, camera reconnect problems and network interruptions. Keep the Pi in the position and power arrangement you will use in production, not on a desk with an improvised cable that will later be moved.
Monitor the facts that indicate failure: FFmpeg errors, dropped frames, audio timestamp warnings, CPU load, temperature, available storage and the YouTube stream-health messages. If you use a USB camera or microphone, make sure the device cannot be casually disconnected and confirm what happens after a power cycle.
Keep configuration in a private file or protected environment rather than repeating the stream key in shell history. Use a named script with clear comments and a local placeholder when you need to share the structure with someone else. A second copy of the tested settings is useful, but it should not contain the credential.
Decide what recovery means. A process supervisor can restart a failed FFmpeg process, but it cannot correct a bad encoder choice or an unavailable camera. If the camera is disconnected, the network is down or the Pi is overheating, automatic restarting may simply repeat the same failure. Check the cause before adding more restart logic.
If you want the channel to continue from an uploaded file rather than a live camera, StreamNeo removes the need to keep this capture computer running by turning the prepared video into a YouTube live stream from the cloud. That is a different workflow from Raspberry Pi camera encoding, so choose it only when the source is a finished file and not a live scene.
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 every Raspberry Pi support hardware H.264 encoding?
No. Raspberry Pi’s documentation describes hardware H.264 as being used when available, so the board and software path must be checked together. Confirm the local camera application, kernel, driver and FFmpeg build before relying on hardware encoding.
Can I use h264_omx because an old guide recommends it?
Do not select it without current verification. Older tutorials may describe a path that is not present or suitable on your board and installed software. Inspect the encoders on the target Pi and complete a short test with the actual camera.
Does Raspberry Pi 5 have hardware H.264 encoding for this setup?
Raspberry Pi’s current camera documentation says Raspberry Pi 5 uses software video encoders. Plan around the CPU cost, test the selected resolution and frame rate, and consider copying a suitable camera-side H.264 stream rather than encoding the same video twice.
What keyframe interval should I use for YouTube?
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Convert that timing into frames when your camera application uses an I-frame count, then verify the actual output during a representative private or unlisted test.