For a conventional SDR video that you want to send from a Raspberry Pi to YouTube Live, start with H.264 video and AAC audio, carried as a live stream over RTMPS. Use constant bitrate encoding and a two-second keyframe interval, then choose a resolution and bitrate your particular Pi and internet connection can sustain.
An MP4 can be a sensible source file, but it does not itself make a live broadcast. MP4 is a container, H.264 and AAC are codecs, and RTMPS is the protocol that carries the live stream to YouTube. Keep those roles separate and test the complete path before relying on it overnight.
Choose H.264 video and AAC audio
For a typical standard dynamic range (SDR) channel, H.264 video with AAC audio is the straightforward starting point. YouTube accepts other video codecs for live ingestion, but H.264 is a conservative choice when your workflow involves a Raspberry Pi, a pre-recorded file and a conventional live encoder. AAC is a common audio codec and fits the same broadly compatible setup.
This recommendation is about the stream sent by your encoder, not a promise that every source file will play or convert cleanly on every Pi. Check the file’s actual video and audio codecs, resolution, frame rate and audio track. A file extension such as .mp4 does not tell you whether its contents match the desired output; the container can hold different combinations of tracks and codecs.
For normal SDR, use progressive video, square pixels and Rec. 709 colour as the baseline. YouTube’s live encoder guidance also includes settings such as two B-frames, one reference frame and CABAC for H.264, alongside stereo audio at 44.1 kHz and 128 kbps. Treat these as encoder guidance rather than a checklist every Pi encoder can expose. If your software does not offer a setting, do not assume that forcing a less familiar option is necessary; verify the resulting stream in YouTube’s preview.
A file that already has H.264 video and AAC audio may be usable without changing those tracks, depending on the playback and streaming software. That is different from transcoding: remuxing changes how existing tracks are packaged, while transcoding decodes and re-encodes them. Re-encoding consumes additional processing capacity, so avoid it when the existing media and output path already meet your needs. If you need to prepare or convert a source, the practical distinctions in exporting screen recordings in different video formats can help you inspect the file before building the live setup.
Understand MP4, codec and RTMPS roles
The word “format” is used loosely, which makes this question confusing. A container such as MP4 is the file wrapper; codecs such as H.264 and AAC encode picture and sound; and RTMPS is a live-ingest protocol. They answer different questions: what holds the tracks in a file, how the tracks are compressed, and how the encoder sends a broadcast to YouTube.
YouTube’s upload guidance describes recommended properties for uploaded videos, including MP4 with H.264 video. That guidance is useful when preparing a source file, but uploading a finished file and sending a live broadcast are different workflows. A pre-recorded MP4 can be played by streaming software; the software then sends encoded live output to YouTube through a supported ingest protocol.
For a conventional SDR stream, use RTMPS. YouTube Help recommends RTMPS, describing it as a secure extension of RTMP. YouTube’s live encoder settings guidance covers the live protocols and encoding settings. In other words, do not put “MP4” in the protocol field or assume that an MP4 upload recommendation specifies your live stream settings.
YouTube also documents HLS ingestion for situations such as HDR workflows or codecs that are not supported through RTMP. HLS has its own delivery requirements and higher latency, so it is not a like-for-like replacement to choose casually for an ordinary SDR Pi setup. Unless you have a particular need for it and have checked YouTube’s current guidance, RTMPS is the simpler route to test.
After YouTube receives the live stream, it transcodes it into formats for viewers. You therefore select a suitable input stream; you are not expected to create every playback version yourself. If your aim is to run a repeating recorded playlist rather than a single event, planning the playback and hand-off between files matters too. The guide to scheduling a YouTube 24/7 playlist with FFmpeg covers a broader playlist workflow, while the choices here concern the media sent into live ingest.
Set bitrate and keyframe interval for the target
YouTube calls for constant bitrate (CBR) encoding for this live setup and recommends a keyframe interval of two seconds, with an interval no longer than four seconds. A keyframe interval is the time between full reference frames in the video stream. Use the two-second recommendation if your encoder exposes it, and confirm that the actual output follows the selected setting.
Bitrate depends on the resolution and frame rate you intend to send. YouTube’s H.264 guidance lists the following recommended and minimum bitrates. These are YouTube’s published input settings, not a measurement of what a Raspberry Pi can encode or what a particular connection can sustain.
| Output target | YouTube recommended H.264 bitrate | YouTube minimum H.264 bitrate |
|---|---|---|
| 720p30 | 8 Mbps | 3 Mbps |
| 720p60 | 8 Mbps | 3 Mbps |
| 1080p30 | 14 Mbps | 5 Mbps |
| 1080p60 | 17 Mbps | 6 Mbps |
| 1440p30 | 21 Mbps | 7 Mbps |
| 1440p60 | 34 Mbps | 8 Mbps |
| 2160p30 | 42 Mbps | 11 Mbps |
| 2160p60 | 50 Mbps | 14 Mbps |
For example, if you choose 1080p30, YouTube’s table recommends 14 Mbps for H.264 and lists 5 Mbps as the minimum. Do not read the minimum as a promise of good results for every image or connection, or the recommendation as proof that your Pi can produce it continuously. A music visualiser with little movement and a sports playlist with fast motion can behave differently at the same resolution; inspect the picture rather than choosing solely from a number.
Match the output to the source where practical. If your recording is 30 frames per second, sending it at a higher frame rate does not add genuine motion detail. Upscaling a smaller image may increase the data and processing burden without recovering detail that is absent from the source. A smaller output can be a more dependable choice if the source, encoder or uplink is constrained.
Keep room for other traffic on the internet connection. The selected stream bitrate is not the only traffic using your upload capacity, and a connection that briefly reaches a target may still fluctuate. Test at the intended time and with the intended network path. You can also review YouTube Live bitrate settings for 1080p at 30 fps for a more focused discussion of that particular target.
Check the Pi media pipeline and upload capacity
The Raspberry Pi model matters, but a published encoder capability is not a guarantee for your complete workload. Raspberry Pi’s specifications list H.264 encoding up to 1080p30 for the Pi 4 Model B. Raspberry Pi’s camera software documentation describes different encoder paths, including software video encoders on Pi 5. Neither statement proves that your exact file, operating system, playback application, encoder build and network can run an uninterrupted stream at a chosen setting.
First identify what the software is doing with the file. If it can pass through compatible, already-encoded media, the Pi may be doing less work than if it must decode and re-encode every frame. If it must transcode, resolution, frame rate, codec settings and the available encoder all affect the workload. A command or guide written for raw camera frames is not automatically ready to use for a recorded MP4; the input path and pipeline are different.
Then test the exact chain you plan to leave running. Use the actual recording, playback or playlist software, encoder, stream settings and network connection. Watch for dropped frames, audio drift, pauses between files, overheating or throttling, and output interruptions over a period long enough to reveal problems in your own use. Do not infer overnight reliability from a short preview or from a product specification.
On Pi 5, Raspberry Pi’s camera guidance discusses software encoding and a low-latency option for real-time streaming. It notes a trade-off: lower latency can reduce coding efficiency and may reduce maximum frame rate. That is useful context, but it does not settle whether a particular pre-recorded-file pipeline will meet your needs. On a Pi 4, the published H.264 encode specification is a starting point for investigation, not a reason to skip testing. Choose hardware based on the work your setup must actually do, rather than buying a model because a capability figure appears to match the output target.
Measure the upload path as well as the media pipeline. The connection needs to sustain the chosen bitrate with headroom for variation and other household or business use. If the uplink is shared, test while it is being used in the way it will be during the broadcast. A wired network connection can remove some wireless variability, but it cannot improve an insufficient internet upload service.
For a channel that needs to keep running when your local computer is switched off, the Raspberry Pi is not the only way to handle continuous playback. StreamNeo turns an uploaded video into a YouTube live stream, so it can remove the specific need to keep the Pi and its local playback pipeline running. It is YouTube-only; it does not change the need to prepare suitable media or confirm your channel and live settings.
Test through YouTube Live Control Room
Do not treat a local playback check as proof that YouTube is receiving the intended stream. Configure the channel and encoder, send a test stream, and check the preview and stream health in YouTube Live Control Room before scheduling a real broadcast. YouTube’s testing guidance explains how to test a live stream. Keep the stream private or unlisted as appropriate for your test and check the current settings in your account.
Check the picture for resolution, frame rate, colour and motion, not just whether a preview appears. Watch scenes with movement and transitions between playlist items. A static title card can conceal judder or dropped frames that become obvious once a video begins. If the preview is inconsistent, lower the output target or address the bottleneck before going live rather than hoping that the public broadcast will behave differently.
Listen to the audio from the preview. Confirm that the correct track is present, that speech or music is not clipping, and that sound remains in sync after the stream has been running. For a playlist, check the hand-off between one file and the next, including whether the audio briefly disappears or restarts unexpectedly. A technically connected stream can still be a poor viewing experience if a repeated gap occurs at every transition.
Review the stream health indicators and any warnings shown in Control Room. If the encoder reports dropped frames, compare what it reports with the Pi’s own load and the network conditions. A warning can reflect different parts of the path; do not respond by changing several settings at once. Change one relevant variable, such as output resolution or bitrate, then run the test again so you can tell whether the change helped.
Finally, test the conditions that matter to your channel. For a devotional or ambience loop, listen for clean repetition and stable audio; for news or study videos, check text legibility and transitions. If the channel is intended to run continuously, test the intended playlist and restart behaviour, not merely one short clip. A successful test is evidence about that particular combination of file, Pi, software and connection, not a universal guarantee for other workloads.
If your workflow involves a scheduled event, check the schedule and stream key as well as the encoder. The guide on scheduling and rescheduling a YouTube Live stream is useful for that separate part of preparation. Keep the stream key private, and confirm that the scheduled broadcast and the encoder are set to the same destination before the test.
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
What format should I use to stream a pre-recorded video to YouTube Live?
For a conventional SDR stream, start with H.264 video and AAC audio, sent over RTMPS using CBR and a two-second keyframe interval. Pick the resolution, frame rate and bitrate for your source and the capacity you have verified. Test the resulting stream in Live Control Room before broadcasting.
Can a Raspberry Pi stream an MP4 to YouTube Live?
An MP4 can be the source file, but the Pi’s software must be able to play or process its tracks and send a live stream to YouTube. The container alone does not determine whether the Pi can sustain the work or whether the live-ingest settings are correct. Test your exact file, software, Pi model and connection.
Is 1080p30 a safe setting for every Raspberry Pi?
No. YouTube’s recommended H.264 bitrate for 1080p30 is 14 Mbps, but that is a YouTube ingest recommendation, not a Raspberry Pi performance result. Raspberry Pi publishes an H.264 encoding capability for Pi 4 Model B, while Pi models and software paths differ; validate the full pipeline on your own device.
Should I use RTMPS or HLS?
For an ordinary SDR stream, RTMPS is the recommended starting point. YouTube documents HLS for particular workflows, including some HDR or codec cases, and it has different delivery requirements and higher latency. Check YouTube’s current official guidance if your stream has a specific reason to use HLS.