For a Raspberry Pi 4 YouTube stream, start by choosing either H.264 at 720p30 or 1080p30, then configure constant bitrate (CBR) and a two-second keyframe interval if your installed encoder supports them. YouTube lists 8 Mbps as its recommended H.264 video bitrate for 720p30 and 14 Mbps for 1080p30, but those are ingest targets, not proof that a particular Pi 4 setup can encode continuously at either rate.
The reliable setting is the one your capture, encoder, audio source and connection can sustain together. Check the controls available in your actual software build, test representative sound and movement, and watch YouTube’s stream-health feedback before relying on a long-running broadcast.
Choose a resolution and frame rate for the scene
Begin with what viewers need to see, rather than choosing the largest resolution your camera offers. A static devotional image, a lofi background or a local information loop may not benefit much from 1080p if the source itself is a still image. A camera showing a speaker, a shop floor or a changing outdoor scene may benefit from the extra detail, but only if the entire pipeline remains stable.
For this comparison, use 30 frames per second (30 fps) as the starting frame rate. It gives you two clear targets, 720p30 and 1080p30, without assuming that a Pi 4 camera, capture input and encoder combination can handle a higher frame rate. YouTube publishes guidance for other formats too, but a published platform target is not a Pi performance result.
Think about resolution, motion and upload capacity together. A detailed image with little movement can be less demanding in one respect than rapidly changing footage, while a moving scene can make compression artefacts more visible. The bitrate needs to fit the platform’s ingest guidance and your stable upload headroom; it is not a way to repair an encoder that is falling behind.
If you are streaming a recorded loop rather than a live camera, check the source file and its audio before choosing output settings. A high-resolution file does not automatically make a higher-resolution stream useful, particularly if the picture is mostly static. For considerations specific to a recorded video loop, see settings for a relaxing fireplace loop.
YouTube H.264 bitrate figures for 720p30 and 1080p30
YouTube’s live encoder guidance gives minimum and recommended H.264 video bitrates for common formats. The figures below are platform guidance for ingest, not minimums that guarantee acceptable picture quality, viewer playback or Pi 4 encoding performance. The YouTube Help encoder settings page is the source to recheck when you configure a stream, since platform guidance can change.
| Output format | YouTube H.264 minimum | YouTube H.264 recommendation | How to use the figure |
|---|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps | A lower-resolution target to test first when detail needs are modest or capacity is constrained. |
| 1080p30 | 5 Mbps | 14 Mbps | A higher-detail target to test only when capture, encoding and upload are stable together. |
The minimum is not a recommended universal setting. It is a published floor for YouTube’s ingest guidance, not an assurance that a picture will look good at that rate in your scene. A fast-moving camera view can show compression more readily than a still background, and different sources can behave differently even at the same resolution.
Likewise, do not treat 14 Mbps as a benchmark for what a Raspberry Pi 4 can encode. That figure says what YouTube recommends for a 1080p30 H.264 stream; it does not measure your camera, operating system, FFmpeg build, audio mix or network. Raspberry Pi’s camera documentation describes an FFmpeg/libav path that can use hardware H.264 encoding when available, but that does not establish a sustained result for every installation. Review the Raspberry Pi camera software documentation alongside your installed software’s own options.
Select one target and test it rather than changing resolution and bitrate at the same time. If you begin at 720p30, the YouTube recommended figure is 8 Mbps; if you move to 1080p30, the recommendation is 14 Mbps. Keep in mind that audio and network overhead also use capacity, and leave enough stable upload headroom instead of planning to consume the full measured connection rate.
Set CBR and a two-second keyframe interval
YouTube’s encoder guidance calls for constant bitrate (CBR) and recommends a two-second keyframe frequency; it also says the interval should not exceed four seconds. A keyframe is a frame encoded so that the decoder can reconstruct a picture without relying on earlier frames. Regular keyframes help the receiving platform handle the stream predictably, while a long or variable interval can fall outside the guidance.
CBR means aiming for a steady video bitrate rather than allowing it to rise and fall widely with scene complexity. It does not mean the picture has a fixed quality: a simple still image and a busy scene may use the available bits differently. For this reason, a stable target bitrate alone cannot ensure that every scene looks the same or that an encoder keeps pace.
Where the installed encoder exposes the controls, set CBR and a two-second keyframe interval. Do not paste a command from a different Pi image or FFmpeg package and assume each option maps to the same encoder setting. Confirm how the named encoder handles rate control and keyframes before building the final command.
YouTube recommends RTMPS for ingest. Make sure your streaming application or command supports the protocol and settings you plan to use, and follow YouTube’s current setup instructions for the stream destination and key. If the platform reports an ingest problem, use its current guidance rather than assuming a bitrate change is always the answer.
Check the controls exposed by your installed encoder
A command that worked for another Raspberry Pi owner may refer to an encoder or option your current system does not have. Operating-system images, camera interfaces and FFmpeg packages can differ. In particular, old examples using h264_omx should be treated as version-specific rather than as universal instructions for every Pi 4 installation.
Inspect your installed FFmpeg build before writing the final command. The official FFmpeg documentation shows encoder-specific help in the form ffmpeg -h encoder=<encoder>. First identify which encoders your build offers, then request help for the one you intend to use. Verify that its documented options cover the settings you need, including bitrate mode and keyframe behaviour.
This check is not just about whether an encoder name appears in a list. The selected encoder must be usable with your input and must accept the controls you are setting. Raspberry Pi documents a camera workflow for Pi 4B or earlier and describes hardware H.264 encoding through libav when present. That is evidence of a documented route, not a promise that every camera, software package and audio input will work unchanged.
Raspberry Pi’s camera tooling documents a bitrate option expressed in bits per second, with an example value of 10000000 for 1920x1080 output. Treat that as an example of a control, not as YouTube’s recommendation or a required Pi 4 setting. If your workflow uses rpicam-vid, consult the matching documentation and determine how it connects to the FFmpeg or libav path on your system.
Keep a note of the software version, selected encoder, input format and options that you verify. That makes a later update easier to diagnose: if a command stops working after a package or OS change, you can distinguish an encoder-interface change from a capture or network issue. Avoid adding settings that you have not confirmed the encoder accepts.
Test real footage, motion and audio before settling
Run a preflight with the same camera or video input, encoder, output resolution, bitrate, audio source and network connection you expect to use. YouTube advises testing before the event with similar sound and movement. A short test of a static desktop or silent still image is not a useful substitute for the content you will actually broadcast.
For a camera stream, include the movement that viewers will see: a person crossing the frame, a pan, foliage moving in the wind, or changing light. For a recorded loop, test the busiest visual passage rather than only its opening frame. Watch for encoder lag, dropped frames, blockiness in motion and audio that drifts, clips or disappears. These symptoms point to different parts of the pipeline, so note when and how they occur.
Check the audio path independently as well as in the combined stream. YouTube’s current encoder guidance lists AAC and MP3 as audio codec choices and gives stereo audio guidance of 128 Kbps at a 44.1 kHz sample rate. Confirm that your chosen encoder actually exposes compatible audio controls and that the source is present throughout the test. A silent test can miss a mismatch in sample rate, channel layout or device selection.
Test first at one resolution and one bitrate, then let the system run long enough to reveal whether it remains consistent under your actual conditions. A successful start only confirms that the stream began; it does not show that the encoder can continue without accumulating delays or that your connection will remain steady. Repeat the test after changing a material part of the setup.
If the aim is a 24/7 broadcast, consider what happens when the computer, connection or encoder process is interrupted, in addition to tuning the picture. A local Pi arrangement depends on the Pi and its surrounding setup being available. For a recorded video that must continue with your computer switched off, StreamNeo removes the specific burden of keeping that local machine running by taking an uploaded file and running it as a YouTube live stream; it does not replace checking that your content and channel are ready.
Monitor stream health and adjust cautiously
During a test or broadcast, watch YouTube’s stream health and any encoder counters your setup provides. Treat a health warning as a reason to investigate, not as a diagnosis by itself. Separate signs of an overloaded encoder from signs of a weak or unstable connection where your tools permit, and check whether audio remains in sync.
If frames drop or health degrades, change one thing at a time. A practical first test is to reduce resolution or frame rate, then repeat the same representative footage and audio. If the system becomes stable, you have evidence that the previous combination was too demanding for that setup, though it does not identify a single cause unless you have isolated the other variables.
Adjust bitrate with both YouTube’s guidance and your connection in mind. The stream needs upload capacity for the video target, audio and protocol overhead, with headroom for normal variation. If your connection cannot reliably support a target, reducing output demand may be safer than trying to push through at a nominal number. Conversely, a lower bitrate can affect detail, especially during motion, so review the actual picture rather than assuming that any rate above the platform minimum will look adequate.
Do not make several changes between tests. If you alter resolution, bitrate, encoder, audio rate and network path together, a better or worse result tells you little about which change mattered. Keep a simple record of the settings and observed symptoms, then change one variable and repeat. This approach is slower than copying a command, but it produces settings grounded in your own capture path.
When connection interruptions are the recurring problem, bitrate may not be the only factor. Review the network path, local power and the encoder process, and make sure your recovery plan is clear. The guide to diagnosing YouTube Live disconnections covers a related problem from the service side; the same habit of separating symptoms helps when you are troubleshooting a Pi-based setup.
If the channel is meant to run all day, decide how you will notice a failure and what you will do when it happens. A good test should include the normal audio and movement, but a long-running channel also needs a way to notice a stopped or unhealthy broadcast. If your workflow relies on a computer staying awake, this guide to preventing sleep during a 24/7 broadcast can help you think through that operational risk, even if your encoder is FFmpeg rather than OBS.
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
Should I use 720p30 or 1080p30 on a Raspberry Pi 4?
Choose based on the detail your viewers need and what your own capture and encoder test can sustain. YouTube’s recommended H.264 bitrate is 8 Mbps for 720p30 and 14 Mbps for 1080p30, but neither figure proves that a particular Pi 4 installation will encode reliably at that setting.
Is YouTube’s minimum bitrate enough for a good stream?
Not necessarily. The 3 Mbps 720p30 and 5 Mbps 1080p30 figures are YouTube’s listed H.264 ingest minimums, not guarantees of picture quality or viewer playback. Test the actual motion in your scene and assess the result.
Can I use an old FFmpeg command with h264_omx?
Do not assume it applies to your current system. Check which encoders your installed FFmpeg build provides and inspect the selected encoder’s help before relying on its options. Package and driver interfaces can differ across installations.
What should I change first if the stream health worsens?
Check the encoder and connection symptoms, and change one setting at a time. If frames drop or the stream health indicator degrades, test a lower resolution or frame rate first, then reassess bitrate and upload headroom against YouTube’s current guidance.