To stream a prerecorded devotional video to YouTube Live from Ubuntu with FFmpeg, encode it as H.264 video and AAC audio, send it to YouTube’s current RTMPS ingest address, and check the Control Room preview before relying on the broadcast. The command below is a template: your FFmpeg build, source file, machine and connection determine whether it works as written.
For a repeating channel, FFmpeg can read the file in real time and loop it; for a single broadcast, you can let it end at the file’s end. In either case, keep the stream key private and confirm the picture and sound in YouTube Live Control Room.
What you need on Ubuntu
You need an Ubuntu computer with FFmpeg installed, a video file you have the right to stream, a YouTube channel that can start a live broadcast, and a connection capable of sustaining the selected video and audio bitrate. This is a software setup; the requirements here do not establish a need for an encoder appliance or capture card.
Check which FFmpeg is installed and which encoders it exposes before building the command:
ffmpeg -version
ffmpeg -hide_banner -encoders
Look for libx264 in the encoder list if you plan to use the software H.264 encoder in the example. FFmpeg installations differ, so the command may need changes if that encoder is absent. Ubuntu’s FFmpeg codec manual documents VAAPI H.264 support for suitable systems, but that documentation does not mean your particular hardware, driver and FFmpeg build support it.
If libx264 is missing, first identify your Ubuntu release and how FFmpeg was installed, then check that build’s documentation or package details. Do not replace the codec option with a guessed hardware-encoder name: hardware encoders have their own availability and parameter requirements. If encoding falls behind in real time, lowering output resolution or frame rate may be more practical than changing codecs without checking the result.
You also need to create or prepare the live stream in YouTube Live Control Room. Keep the Control Room open while configuring FFmpeg: it supplies the current ingest endpoint and stream key, and it is where you will check what YouTube receives.
Choose settings that fit YouTube and your file
YouTube’s live encoder settings list RTMP and RTMPS ingestion and recommend RTMPS. They list H.264, H.265/HEVC and AV1 video, AAC or MP3 audio, up to 60 frames per second, and constant bitrate (CBR). H.264 with AAC stereo over RTMPS is a practical compatibility-oriented starting point, not the only supported combination.
Choose the output resolution and frame rate before setting the bitrate. YouTube’s H.264 guidance recommends 5 Mbps for 1080p at 30 fps and 8 Mbps for 720p at 30 fps. These are recommendations for those specific output modes, not a universal bitrate rule. For other modes, consult the current YouTube table rather than extrapolating. YouTube detects resolution and frame rate automatically by default; manual resolution selection is available with a custom stream key.
| H.264 output mode | YouTube-recommended video bitrate | GOP for a two-second interval |
|---|---|---|
| 1080p at 30 fps | 5 Mbps | 60 frames |
| 720p at 30 fps | 8 Mbps | 60 frames |
A GOP, or group of pictures, is the number of frames between keyframes. The table’s GOP values follow the frame rate: at 30 fps, 60 frames span two seconds; at 25 fps, use 50 frames for the same interval. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. This is why the -g value must change if you change -r.
YouTube’s advanced guidance also calls for square pixels, progressive scan, two B-frames, one reference frame, CABAC, and Rec. 709 for SDR. It recommends 44.1 kHz stereo audio and lists 128 kbps for stereo audio. These are alignment targets, not a reason to force settings that do not fit your media or encoder. The example uses AAC at 44.1 kHz, stereo and 128 kbps, but it does not explicitly set every advanced video property.
Keep the source’s aspect ratio in mind. A devotional video in portrait or non-standard dimensions can appear with bars or be stretched if you force it into a different shape. Avoid adding scaling or cropping until you have inspected the file and decided how it should look in the preview. For a wider discussion of the stream’s wider operating choices, see cloud hosting for a 24/7 Indian radio channel.
Prepare the devotional video
Before choosing output settings, inspect the file rather than assuming it is 1080p30 or contains an audio track. FFmpeg’s information output can help you check the video and audio streams:
ffmpeg -i input.mp4
FFmpeg may report an error after printing the file information because the command has no output destination; that is expected for this inspection. Note the video dimensions, frame rate and whether an audio stream is present. Also play the file locally from beginning to end, or at least check representative points, for the intended devotional content, picture orientation, audible level and any unwanted silence or cut-off.
The example command assumes the input contains both video and audio. If it has no audio stream, an audio encoder option cannot create devotional sound from nothing; you would need to decide whether to add an appropriate audio source or intentionally send video without audio. If the file has multiple audio tracks, check which one FFmpeg will select rather than assuming it is the desired mix. Subtitles or captions are a separate consideration; see how to add closed captions to a prerecorded playlist in OBS if captions are part of your workflow.
Decide whether the broadcast should repeat. A 24/7 devotional channel usually needs the file to loop, while an event intended to play once should stop or transition deliberately when the file ends. Repeating one video can also repeat a visible title card, a long pause or an audio gap, so review the transition between the end and beginning before leaving it to run.
For looped streams, consider the file’s duration and whether a repeated transition is acceptable to viewers. If you need a sequence of different videos rather than one repeating file, that is a playlist problem, not something this single-file template solves. An adjacent example is rotating pre-recorded videos with a Raspberry Pi, though the equipment and method there are different.
Build an adaptable FFmpeg command
This illustrative template targets a file with video and audio, output at 1080p30, and a repeating broadcast. Replace the input path and the final destination with the values for your file and stream:
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 -pix_fmt yuv420p -preset veryfast \\
-b:v 5M -maxrate 5M -bufsize 10M -r 30 -g 60 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
This is a template assembled around published settings, not a tested command or a guarantee for every Ubuntu installation. Replace input.mp4 with the actual file path. Replace the placeholder destination with the ingest address and private stream key shown for your stream in Live Control Room. Do not paste the placeholder unchanged and expect it to connect.
The options before -i apply to the input in this pattern. -re tells FFmpeg to read the file at its native rate for real-time output rather than pushing it as fast as the file can be read. -stream_loop -1 asks it to loop the input indefinitely. The FFmpeg command-line documentation explains option placement and input looping; options generally apply to the next input or output, so moving them can change what they affect.
After the input, -c:v libx264 selects the H.264 encoder, -pix_fmt yuv420p selects a widely used pixel format, and -preset veryfast trades some compression efficiency for less encoding work than slower presets. It does not promise a particular performance level. If the machine cannot keep pace, the FFmpeg output’s reported speed is useful evidence; a speed consistently below real time means the output may fall behind.
The -b:v and -maxrate values set the target and cap to 5 Mbps for the 1080p30 example; -bufsize sets the rate-control buffer. The -r 30 sets output frame rate and -g 60 sets a two-second GOP at that rate. For 720p30, YouTube recommends 8 Mbps for H.264, so use the relevant current guidance and choose a resolution that your source, computer and connection can sustain. For any other frame rate, update the GOP to approximately twice the frames per second to preserve the two-second interval.
The audio options encode AAC at 128 kbps, resample to 44.1 kHz and request two channels. If the source is mono or has a different sample rate, FFmpeg’s output is being configured for stereo 44.1 kHz, but you should listen to the preview to ensure the result is suitable. The final -f flv selects the output container commonly used for RTMP-family delivery; the destination uses the RTMPS endpoint supplied by YouTube.
For a single-play stream, omit -stream_loop -1. Decide in advance what should happen at file end; the process finishing is not the same as a planned channel handover. For a 25 fps output, for example, use -r 25 and -g 50, and find the matching bitrate recommendation from YouTube’s current table rather than reusing 1080p30 figures automatically.
Protect the stream key
Treat the stream key like a password. Anyone who obtains it may be able to send a broadcast to the associated stream. YouTube’s LiveStreams API documentation describes ingestion addresses in the API context, while creators should take the active endpoint and key from the Control Room for their stream.
A key placed directly in a shell command can be saved in shell history, visible in a screenshot or copied into a public script. Avoid sharing a terminal recording that exposes it, and do not put it in a repository, a support post or a log file you intend to publish. Keep access to the Ubuntu account limited to people who should be able to control the broadcast.
The command uses a quoted destination only to show where the actual endpoint and key go; the quotation marks do not make the value secret. If you need a more private way to supply the destination, use a method appropriate to your shell and local security practice, and ensure the key is not printed when diagnosing errors. If you believe the key has been exposed, use YouTube’s current Control Room controls to rotate or replace it, then update the sender. A church’s stream-key change checklist is relevant to planning that update without losing track of which sender uses which key.
Start the broadcast and inspect what YouTube receives
In Live Control Room, set up the broadcast, choose the appropriate stream configuration and copy the current ingest address and key. Prefer the RTMPS endpoint when YouTube offers it. Start the FFmpeg command only after confirming that the destination belongs to the intended stream; then watch both FFmpeg’s terminal output and the YouTube preview/status.
Do not judge success solely by seeing FFmpeg continue to print progress. Confirm that YouTube has received video, that the preview has the intended aspect ratio and colour, and that the devotional audio is present and intelligible. Check a transition or loop point, not just the first few seconds, if you plan to repeat the file. Give the preview time to catch up before diagnosing a still or delayed image.
YouTube detects resolution and frame rate automatically by default. If the stream configuration uses a custom key with manual selection, check that the selected output mode agrees with the FFmpeg settings. When the preview differs from what you expected, verify the source, output flags and Control Room configuration rather than changing multiple settings at once.
Monitor FFmpeg’s reported speed and any connection errors. The published settings do not establish that a particular computer can encode in real time or that a particular internet connection can sustain the chosen bitrate. If the process cannot keep up, reduce the output resolution or frame rate and consult the matching bitrate guidance. If the connection is unstable, check the local network and available upload capacity rather than assuming the encoder command itself is the only issue.
If you are planning an ongoing channel rather than testing a one-off command, consider what happens when the computer sleeps, reboots or loses connectivity. This article’s FFmpeg template does not promise automatic recovery or unattended operation. For a prerecorded channel where leaving your own computer running is the specific pain, StreamNeo can run an uploaded video as a YouTube Live broadcast with your computer switched off; check the actual stream in YouTube before depending on it.
Troubleshoot audio, keyframes and connection
If YouTube reports a stream problem or the preview is missing, start with the simplest checks. Confirm the stream is active in the intended Control Room event, the destination contains the current endpoint and key, and FFmpeg’s output does not show an authentication or connection failure. Re-copy the endpoint carefully if needed, but keep the key out of screenshots and public logs.
If video appears but sound does not, inspect the input’s stream information again and verify it actually includes the audio you want. Check that FFmpeg is selecting the correct track, then listen to the Control Room preview rather than relying on the command’s presence of -c:a. That option encodes an audio stream only if an appropriate input stream is available.
If YouTube flags keyframes, match the GOP to the output frame rate. A value of 60 at 30 fps spans two seconds; a value of 50 at 25 fps does the same. YouTube recommends two-second keyframes and says not to exceed four seconds, so do not copy a GOP value from an example without checking whether its frame rate matches yours.
If the image stutters or the encoder falls behind, distinguish encoding load from network trouble. A low reported speed suggests the computer is struggling to encode at the chosen settings; a healthy encoding speed alongside connection errors points towards delivery or network conditions. Try a lower output mode with its corresponding current YouTube bitrate recommendation, then recheck both FFmpeg and the incoming preview. Do not assume that a different codec or hardware encoder is available until your local installation confirms it.
Finally, if the stream drops, the command shown here does not itself promise that it will reconnect successfully. Find whether FFmpeg exited, the connection was interrupted or YouTube stopped receiving the feed, and handle the cause before restarting. If you want to review a separate reconnect workflow, see how to make a 24/7 YouTube stream reconnect after an internet outage.
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
How do I stream a video to YouTube Live with FFmpeg?
Inspect the file and select output settings that fit its resolution, frame rate and audio. Use an H.264/AAC RTMPS command as a starting point, replace the destination with the current Control Room endpoint and key, and verify the incoming preview before relying on it.
How do I loop a video on YouTube Live using FFmpeg?
Place -stream_loop -1 before the input’s -i option to repeat that input indefinitely. Use -re to pace file reading for real-time output, and review the file’s end-to-start transition so the repeated broadcast does not introduce an unwanted pause or cut.
Can I use this command unchanged on every Ubuntu system?
No. FFmpeg versions and available encoders vary, and the input media, hardware and network also differ. Check ffmpeg -version, inspect the encoder list, and test the actual incoming video and audio in YouTube Live Control Room.
What should I change if my stream is not smooth?
Check FFmpeg’s reported speed and connection errors, then determine whether encoding or delivery is the likely constraint. If the machine cannot sustain the selected output, lower resolution or frame rate and use YouTube’s matching current bitrate recommendation; no command guarantees uninterrupted streaming.