Start with 1280×720 output, H.264, CBR, a two-second keyframe interval and YouTube's RTMPS ingest. The correct FFmpeg command depends on your Raspberry Pi model, camera, audio device and installed FFmpeg build, so there is no reliable universal command.
For 720p H.264 live ingestion, YouTube currently lists 3–8 Mbps for both 30 fps and 60 fps. Choose 30 or 60 fps according to the source and the Pi's sustainable encoding and upload capacity, then test with the same movement and audio you expect during the real stream.
Identify the Raspberry Pi and the source first
Before changing an FFmpeg setting, write down four things: the Pi model, the operating system, the video source and the audio source. A Raspberry Pi Camera Module, a USB webcam, an HDMI capture device and a prerecorded file do not use the same FFmpeg input arguments. The correct video device may also change between operating systems and capture software.
The model matters because Raspberry Pi generations do not share one encoding path. Raspberry Pi's guidance discusses hardware H.264 encoding on Pi 4 through h264_v4l2m2m, while its Pi 5 comparison uses software H.264 encoding with libx264. That is a useful starting point, not a guarantee that either encoder is present or usable in your installation.
Check the installed build before constructing the full stream command. For example, inspect the encoders exposed by your local FFmpeg installation with ffmpeg -encoders, and look for the encoder you intend to test. Also check the input devices that FFmpeg can see. The exact commands for listing cameras, microphones and capture devices vary by operating system and device type.
Do not paste your YouTube stream key into a public tutorial, screenshot, shell history shared with somebody else or service log. Put the key into the local command only after you have obtained the current RTMPS server address and stream key from YouTube Live Control Room. If the key is exposed, replace it in YouTube rather than continuing to use it.
A Pi that successfully displays a camera preview has not necessarily proved that it can encode and deliver a continuous live stream. Previewing, encoding, audio capture and network transmission all consume different resources. Establish each part separately before combining them.
Choose a frame rate that the source and Pi can sustain
Set the output to 1280×720, then choose 30 or 60 frames per second based on the source. A talking-head camera, devotional image, study timer or mostly static ambience scene usually has little to gain from 60 fps. A fast-moving local scene, sports feed or camera pan may look smoother at 60 fps if the source, encoder and connection can sustain it.
Do not create 60 fps output from a source that only produces 30 fps. FFmpeg can duplicate frames, but that does not add real motion detail. It can add processing and transmission work while leaving the picture no smoother than the original source. Likewise, reducing a genuine 60 fps source to 30 fps can be sensible when Pi CPU headroom or upload capacity is limited.
The frame rate is part of the load, not just a quality preference. At the same resolution and codec settings, 60 fps gives the encoder twice as many frames to process as 30 fps. It also gives the viewer more frequent motion updates, but the benefit depends on what is moving in the picture.
Use the camera's actual mode where possible. A 720p30 camera feeding a stable 720p30 stream is a more useful starting point than forcing 720p60 and then discovering dropped frames overnight. If the camera offers several modes, test the mode that matches the stream rather than asking FFmpeg to perform unnecessary conversion.
The source can also determine whether 720p is appropriate at all. A low-resolution devotional graphic will not gain detail from scaling up to 1280×720. A high-resolution camera may need scaling to keep the Pi's encoding workload manageable. Scaling, frame-rate conversion and colour conversion can each add work before the H.264 encoder is reached.
For a Raspberry Pi FFmpeg YouTube live stream, choose the simplest path that preserves the source's useful motion. Start at 720p30 when the picture is mostly static or when you are unsure about CPU headroom. Move to 720p60 only after a representative test shows that the Pi keeps up without sustained overload or dropped frames.
Use RTMPS and H.264 for the YouTube output
YouTube supports RTMP and RTMPS for live encoder delivery and recommends RTMPS. Use the RTMPS server address shown in YouTube Live Control Room rather than copying an old address from an unrelated guide. The destination and stream key are supplied separately: the destination identifies the ingest service, while the key identifies your live stream.
For this Pi workflow, H.264 is the compatibility-focused video choice. YouTube also lists H.265 and AV1 among accepted video codecs, so H.264 is not the only codec YouTube can accept. It is nevertheless the practical choice for the Raspberry Pi paths discussed here, particularly when your installed FFmpeg build exposes h264_v4l2m2m or libx264.
Use progressive 1280×720 output rather than interlaced output. YouTube's typical SDR recommendations include square pixels, progressive scanning and Rec. 709. For audio, use a format your input and FFmpeg build can produce consistently. YouTube lists AAC or MP3 as accepted audio codecs and 128 Kbps stereo as an advanced recommendation for typical SDR live output.
Those audio settings do not solve an unsuitable microphone input. A USB microphone that disconnects, clips or produces long gaps can make the stream unpleasant even when the video health indicator is good. Test the complete audio path, including the capture device, channel layout, sample rate and encoder, before leaving the Pi unattended.
An FFmpeg RTMPS stream to YouTube should also be treated as a live ingest process, not as an upload. Do not use YouTube's separate upload-video table to choose the live bitrate. YouTube's upload guidance lists different 720p figures, while its live encoder guidance provides the figures relevant to this job. You can compare the two official pages in YouTube's live encoder settings guidance and its recommended upload encoding settings.
Configure CBR and a two-second keyframe interval
Set the video rate control to constant bitrate, usually represented by -b:v together with the encoder's CBR-related options. The exact flags depend on whether you use libx264 or a V4L2 hardware encoder. Do not assume that an option accepted by one encoder will be accepted by another.
A target such as -b:v 5000k expresses the intended video bitrate, but it does not by itself prove that the encoder is operating in CBR mode. Some encoders require a matching maximum bitrate and buffer setting, while hardware encoders may expose different option names. Read the help output for the encoder installed on your Pi and confirm the resulting stream rather than relying on a familiar command copied from another model.
Set the keyframe interval to two seconds. In FFmpeg's x264 path, this is commonly expressed by setting the GOP size to twice the frame rate, such as 60 at 30 fps or 120 at 60 fps, and by setting a two-second minimum keyframe interval where the encoder supports it. Hardware encoder syntax can differ, so treat those values as the logic to reproduce, not as a universal command.
YouTube's guidance recommends a two-second keyframe frequency and says it should not exceed four seconds. At 30 fps, a two-second interval represents 60 frames. At 60 fps, it represents 120 frames. If you change frame rate, revisit the frame-count setting rather than leaving the old GOP value in place.
A fixed keyframe interval helps the receiving service understand the stream consistently. An excessively long interval can delay recovery when a viewer joins or when delivery encounters a problem. A value shorter than necessary may increase overhead. The practical instruction is therefore simple: aim for two seconds, keep it within YouTube's stated maximum, and verify what your selected encoder actually produces.
Avoid variable bitrate settings for this particular starting point. A scene with little movement may require very little data, while a busy camera shot may create a sudden bitrate peak. Those peaks can collide with a limited upstream connection. CBR does not make a weak connection reliable, but it makes the intended delivery rate more predictable.
Choose a bitrate within YouTube's 720p range
For live H.264 ingestion, YouTube currently lists 3 Mbps as the minimum and 8 Mbps as the recommended bitrate for 720p30. The same 3–8 Mbps figures are listed for 720p60. These are guidance values for live ingestion, not a promise that every Raspberry Pi, Wi-Fi link or camera will remain stable at every point in that range.
Treat the bitrate as a choice inside both a service range and your own connection's limits. The total stream also includes audio and protocol overhead, so an upload test that barely reaches the video target leaves little room for normal variation. Use a sustainable upload rate rather than the highest short-lived result from a speed-test page.
| 720p choice | YouTube H.264 live guidance | Sensible starting question |
|---|---|---|
| 30 fps | 3–8 Mbps | Is the source mostly static, and can the Pi encode it comfortably? |
| 60 fps | 3–8 Mbps | Does the source contain useful fast motion, and can the Pi sustain twice as many frames? |
For a mostly static bhajan loop, prayer image or study scene, a conservative value within the range may be adequate if the picture remains clear in motion. For a camera that moves frequently, a higher value within the range can preserve more detail, provided the Pi and upstream connection remain stable. Do not select a number only because it is the recommended upper figure.
The bitrate is not a substitute for source quality. A soft camera, noisy low-light image or heavily compressed input can remain soft at 8 Mbps. Conversely, a clean static graphic may not need the same rate as a detailed outdoor camera. Test the scenes that matter rather than judging only from a still frame.
Keep the audio bitrate in the overall network calculation. YouTube's typical SDR guidance lists 128 Kbps stereo audio, but the correct value also depends on the audio encoder and source. If the microphone is mono, do not create a complicated stereo path merely to match a table. Stable, intelligible audio is more useful than an unused channel.
If your connection cannot sustain the selected setting, reduce the video bitrate or simplify the stream before increasing resolution or frame rate. A lower, stable 720p stream is more useful than a higher target that repeatedly buffers or disconnects. You can also use the practical checks in this guide to check FFmpeg bitrate and dropped frames on YouTube Live.
Account for Pi 4 and Pi 5 encoder differences
The main model distinction in this setup is the encoder path. Raspberry Pi's H.264 performance guidance describes Pi 4 hardware encoding through h264_v4l2m2m and Pi 5 software encoding through libx264. That does not mean every Pi 4 installation exposes the hardware encoder correctly, or that every Pi 5 workload has identical CPU capacity.
On a Pi 4, hardware H.264 can reduce the CPU work involved in video encoding when the required V4L2 path is available and compatible with the installed FFmpeg build. You still need to account for capture, scaling, audio processing and network handling. Hardware encoding is not a guarantee that the complete pipeline will run indefinitely.
On a Pi 5, software H.264 with libx264 uses CPU time rather than the Pi 4 hardware path described above. Monitor CPU headroom while the actual stream is running. A Pi 5 may handle the chosen setting well, but you should not infer that from a short preview or from the model name alone.
Raspberry Pi's camera documentation also notes that Pi 5 software encoding can have greater latency than older hardware encoders in some real-time cases. Where the camera application supports it, rpicam-vid --low-latency reduces encoding latency, with a coding-efficiency trade-off. Whether that option applies to your pipeline depends on how the camera is being captured and handed to FFmpeg.
This is why a model-aware setup is safer than a universal copy-and-paste command. Check the installed FFmpeg encoder list, then read the local encoder help for the options it accepts. For camera workflows, Raspberry Pi's rpicam-vid documentation and camera software documentation are the appropriate references for the capture side.
The operating system and FFmpeg package matter as much as the board. A command written for one image may fail because a device name, pixel format, encoder, protocol option or hardware interface is absent in another. Start with a short local recording or test stream and change one variable at a time. This makes it possible to tell whether a failure comes from capture, encoding or delivery.
Test motion, audio and stream health
Do not test only a static desktop or a silent camera. YouTube's encoder guidance says tests should include audio and movement similar to what you will use in the stream. For a devotional channel, include the real audio loop and a scene change. For a local camera, include pans, people moving through the frame and the lighting you expect at night.
Begin with a private or otherwise controlled YouTube test where possible. Confirm that the preview appears, the picture is 1280×720, the frame rate is the one you selected and the audio is present without clipping. Check YouTube's stream health rather than assuming that a running FFmpeg process means viewers are receiving a healthy stream.
Watch the Pi while the test continues. Look for rising CPU use on a Pi 5, encoder errors on any model, dropped frames, input-device warnings, audio under-runs and network reconnects. Also watch the output over time. A process that looks healthy for a few minutes may fail once the camera warms up, the wireless link changes or the input device briefly disappears.
Change one setting per test. If you move from 30 to 60 fps, keep the bitrate and scene the same. If you change the encoder, keep the source and destination the same. This gives you evidence about the trade-off instead of turning several changes into one unexplained result.
The first reliable test should run for long enough to represent the intended use. If you are building an overnight devotional or ambience channel, test the exact loop and audio arrangement rather than a short camera preview. For a 24/7 stream, also consider what happens after a reboot, a temporary network interruption and an input-device restart. A separate guide on keeping a prerecorded YouTube livestream running after a server reboot covers the operational side.
If the stream stops, record the time and the visible symptom before changing the command. YouTube stream health, FFmpeg's terminal output and the Pi's resource use together are more useful than guessing. The FFmpeg YouTube Live stream troubleshooting guide can help you separate an ingest problem from a local process or network problem.
Decide whether the Pi should run continuously
A Raspberry Pi can be a sensible local encoder when the source is already nearby and you want direct control of the camera, microphone and network connection. It also gives you responsibility for power, cooling, storage, operating-system updates, automatic restart behaviour and the connection between each device.
For a fixed camera in a room with dependable wired networking, that control may be worth the maintenance. For an unattended channel where the computer must remain on overnight, a local Pi adds more points that need checking. Keep the board powered consistently, prevent accidental cable movement and make sure the capture devices return after a reboot.
If the recurring problem is not the FFmpeg settings but leaving a computer running, a cloud workflow can remove that specific burden. StreamNeo is designed for the case where you upload the video once, provide the YouTube stream key and let the broadcast run without your own computer switched on, with automatic monitoring and restart when the broadcast drops.
That does not remove the need to check your source rights, YouTube settings or channel policies. It simply changes where the continuous delivery process runs. If your requirement is a live camera feed that must be captured at the Pi, local FFmpeg remains the relevant approach; if your requirement is a prerecorded loop, compare the operating burden before choosing.
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 I use the same FFmpeg command on every Raspberry Pi?
No. Pi model, operating system, FFmpeg build, camera and audio device determine the available input and encoder options. Treat h264_v4l2m2m as a Pi 4 path only when your installation exposes and supports it, and test libx264 on Pi 5 while watching CPU headroom.
Should a 720p YouTube stream use 30 or 60 fps?
Use the frame rate produced by the source and useful for the scene. Choose 30 fps for mostly static content or when the Pi and connection need more headroom; choose 60 fps only when the source has meaningful fast motion and the complete pipeline sustains it.
Is 3 Mbps enough for 720p live streaming?
YouTube currently lists 3 Mbps as the minimum H.264 live-ingest figure and 8 Mbps as the recommended figure for both 720p30 and 720p60. It is not a reliability guarantee, so include audio and overhead and test the actual stream on your connection.
What keyframe interval should FFmpeg use?
Aim for a two-second keyframe interval and do not exceed four seconds. The frame-count value depends on the selected frame rate, so revisit the GOP setting when changing from 30 to 60 fps, and confirm that your chosen encoder accepts the options you use.