To stream a recorded sermon from Ubuntu Server 24.04 to YouTube Live, use an encoder such as FFmpeg to read the file at normal playback speed and send its audio and video to the RTMPS address and stream key for the broadcast you selected. Create the broadcast in YouTube Live Control Room first, then test the feed in its preview before starting the event.
This is a server-focused workflow, not a promise that one command will suit every sermon file or machine. Check the file’s codecs, the FFmpeg build installed on your host, available upload capacity and YouTube’s stream-health messages before relying on the setup unattended.
How Ubuntu sends a sermon to YouTube Live
Think of YouTube Live as two linked parts. A stream is the destination that receives encoder data; a broadcast is the viewer-facing event connected to that stream. The encoder on Ubuntu reads the sermon file and sends a live audio/video feed to the selected stream, even though the content was recorded earlier. Choose the right broadcast and its associated stream settings before starting FFmpeg.
For a headless Ubuntu server, FFmpeg is a practical command-line choice. It can read a local file and package its audio and video for transmission; depending on the source and your encoder build, you may copy compatible streams or transcode them. OBS Studio provides a graphical alternative if you have a desktop environment and prefer visual controls, but it is not necessary for this server workflow.
YouTube recommends RTMPS, the secure extension to RTMP. Its encoder settings guidance covers supported codecs and recommended settings. RTMPS protects the connection in transit; it does not make a stream key safe if you publish it in a script, screenshot or public log.
The result is a live broadcast, not a file upload or scheduled video premiere. Viewers see the stream as it arrives, and YouTube may also offer a replay or archive according to the broadcast’s settings. Do not assume archive capture: check the current controls in Live Control Room and your channel’s own settings.
Prepare Ubuntu Server 24.04 and the media file
Start with the exact server account and file that will be used during the broadcast. Put the sermon in a stable location, such as a dedicated media directory, and confirm that the account running FFmpeg can read it. A file that works in your desktop account may not be accessible to a service account or scheduled process.
Inspect the source before choosing an output recipe. FFmpeg’s ffprobe utility can report the container, video and audio streams, dimensions, frame rate and codecs. For example, run ffprobe -hide_banner /path/to/sermon.mp4 and read the stream information rather than assuming the extension tells the whole story. If ffprobe is not installed, check the package source and install the appropriate FFmpeg tools for your Ubuntu environment.
Check what is actually installed on the server with ffmpeg -version. You can also inspect available encoders using ffmpeg -encoders and supported protocols using ffmpeg -protocols. Builds and package sources can differ, so confirm that the build offers the encoder and RTMPS support you intend to use. The research for this guide does not verify the capabilities of every Ubuntu 24.04 installation.
Then play the source locally or inspect a short section to confirm that the sermon audio is present, at a useful level, and in sync with any picture. A static title card with a spoken sermon is still a video stream, but its motion and audio should be represented correctly. If the file has multiple audio tracks, subtitles or unusual codecs, decide deliberately which tracks to send; a command that selects the wrong stream can appear to run while omitting the part your audience needs.
Do not convert a file merely because its container is MKV or MP4. Containers and codecs are different things, and a compatible source may be passed through without recompression. OBS’s format documentation explains why some local recording formats behave differently; the outgoing YouTube feed is separately encoded and packaged by FFmpeg. If a source is not compatible with your selected output, test a conversion on a copy rather than altering the original recording.
A little preparation also reduces operational surprises. Ensure the server clock is sensible, the file is not being moved while the encoder reads it, and there is enough disk space if you intend to keep logs or make a separate local recording. These steps do not determine YouTube eligibility or guarantee a stable network, but they make it easier to diagnose problems at the server end.
Create the YouTube Live broadcast
Open YouTube Studio and enter Live Control Room. Create or select the broadcast that viewers are meant to watch, and review its title, visibility, schedule and audience settings. YouTube’s Live Streaming API overview explains the distinction between a broadcast and its associated stream; in the normal operator workflow, Live Control Room presents the controls you need without requiring API calls.
A scheduled broadcast and an immediate live event may have different operator steps, but both need the correct stream destination. Check that the selected stream settings belong to the intended event rather than another channel or test broadcast. If multiple people manage the channel, coordinate who will monitor the preview and who has permission to start or end the broadcast.
Read the current live-streaming status and requirements shown in YouTube Studio. Channel eligibility and feature availability can vary, and no encoder configuration guarantees approval or access. The official YouTube live streaming help is the place to check current account and event guidance.
Keep the Live Control Room open during preflight. It is where you can see whether YouTube is receiving the feed, whether the preview looks and sounds right, and whether diagnostic messages need attention. Sending packets from Ubuntu alone does not confirm that the right broadcast is ready for viewers.
Find the RTMPS ingest address and stream key
In the selected broadcast’s stream settings, locate the ingestion URL and stream key (also called a stream name in some documentation). Use the values YouTube gives for that stream; do not copy an endpoint from an old note or another channel’s example. YouTube’s RTMPS guidance describes the secure protocol and its ingestion settings. The destination needs the right host and path, and RTMPS uses port 443.
Treat the stream key as a password. Keep it out of shared command histories, tickets, public repositories, screenshots and logs that other users can read. If you place it in a shell command, it may be stored in shell history or appear in process information, depending on how you run the command. A protected configuration file or a carefully managed secret mechanism is safer than pasting the key into a publicly visible script.
Before transmission, match the endpoint and key as a pair to the selected stream. A valid key for a different stream can send data to the wrong event, while a typo or stale key can prevent ingestion. If you suspect that a key has been exposed, replace or reset it through the current YouTube controls and update the server’s protected configuration.
Do not remove the secure scheme or alter the path to make a sample command look simpler. Preserve the RTMPS address exactly as supplied and combine it with the stream key in the format required by the FFmpeg build and YouTube’s current instructions. Keep that assembly out of material you share for troubleshooting.
Configure FFmpeg for playback and output
There are two broad ways to send media. Stream copy avoids re-encoding compatible audio and video, which reduces encoder work, but it only works when the source codecs and stream characteristics are acceptable to YouTube. Transcoding creates an output with chosen codecs and settings, but it uses processing capacity and can fail to keep up if the server cannot encode in real time. Verify both source and destination capabilities instead of assuming either route is suitable.
YouTube currently lists H.264, H.265/HEVC and AV1 as video options in its encoder guidance, with AAC or MP3 audio. It recommends constant bitrate (CBR), frame rates up to 60 fps, and a two-second keyframe interval that should not exceed four seconds. Follow the current encoder settings table for the chosen codec and output. These are platform recommendations, not evidence that a particular FFmpeg command or server will meet them.
For comparison, YouTube’s H.264 examples show these bitrate choices:
| Output example | Published minimum video bitrate | Published recommended video bitrate |
|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps |
| 720p60 | 3 Mbps | 8 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
| 1080p60 | 6 Mbps | 17 Mbps |
These figures are YouTube’s published guidance, not a promise of image quality or a measurement of what your connection can sustain. The settings page also gives an audio recommendation of 128 Kbps AAC stereo. A sermon with a static image may not need the same visual detail as fast-moving footage, but the choice should still account for source resolution, codec, frame rate and available sustained upload capacity. Leave margin rather than treating the published recommended bitrate as a target your internet connection is certain to hold.
A sound starting point for a 1080p30 H.264 output, if that matches the source and can be sustained, is YouTube’s recommended 14 Mbps video bitrate, CBR, a two-second keyframe interval and AAC stereo at the published audio recommendation. Research notes for this article include a separate 10 Mbps 1080p30 example, but the current settings table must take precedence when choosing a value; verify the exact current guidance on YouTube’s page before configuring the event. Do not mix settings from different resolutions or frame rates without checking the table.
A generic FFmpeg command is not included here as a universal answer because input stream layout, installed encoders, audio mapping, and RTMPS handling vary. Once you have verified the build, construct a command that explicitly selects one video and one audio stream, sets the intended output codec and rate control, configures the keyframe interval, and targets the exact RTMPS endpoint with the protected stream key. FFmpeg’s local -h output and documentation for the installed build are more reliable than copying a command whose assumptions do not match your file.
Test the chosen output on a short section first. Watch CPU load and observe whether playback advances at normal speed. A transcode that runs slower than the source’s playback rate cannot maintain a live feed indefinitely; a server’s actual capacity depends on its processor, encoder implementation, settings and other workload. If it struggles, consider a compatible source format, lower output resolution or frame rate, or a machine better suited to the encoding task, then run the test again.
For a longer event, choose whether the encoder reads the sermon once or repeats it. A single playback should end when the file reaches its end; looping requires an explicit playback arrangement and should be tested rather than assumed. If the purpose is to repeat a recording as an always-on channel, the practical choices are covered in how to loop a conference replay on YouTube Live. Check YouTube’s current policies and channel settings for the content and event rather than inferring approval from the fact that the encoder accepts it.
Test the preview before going live
YouTube’s guidance is to test before starting a live stream. Run a preflight with audio and movement similar to the planned broadcast, not just a few seconds of a silent title card. Let the feed run long enough to assess lip-sync, voice level, picture stability, and whether the server’s connection sustains the selected output. Then look at the YouTube preview, not only the local command output.
Check that the right broadcast receives the feed and that it contains one intended video and one intended audio stream. Listen for clipping, silence, unexpected background sound and sync drift. If the sermon is a long recording, sample more than the opening: later sections may contain a different audio track, a slide change or a file discontinuity.
Read the stream-health status and messages in Live Control Room. YouTube diagnostics can identify concerns such as unsupported codecs, keyframe intervals that are too long, bitrate outside expected bounds, missing audio or video, multiple streams, unsupported resolution, or video starvation. Use the displayed diagnosis to guide changes rather than changing several settings at once. You can also review the latency choices for a pre-recorded, premiere-style stream, but latency selection does not replace an ingest test.
Only start or schedule the viewer-facing broadcast when the preview and audio are acceptable to the person responsible for the event. Confirm the title, visibility and timing one last time. A successful connection is not the same as a good programme feed, and a good local playback is not proof that YouTube is receiving the expected output.
Monitor, stop, and recover the stream
During the event, keep an operator able to see both the FFmpeg process and Live Control Room. On the server, review the process exit status and relevant logs; on YouTube, watch the preview, health messages and event state. This division helps distinguish an encoder failure from a destination, key, network or YouTube-side issue.
If the feed stops, note what changed before restarting: did FFmpeg exit, did the network drop, did the file end, or did YouTube report an ingest problem? Check the key and endpoint, confirm the file remains readable, and inspect the most recent error rather than repeatedly launching the same command. After correcting a problem, verify the preview again before resuming the event.
For unattended operation, a process supervisor or scheduler can relaunch a command after an unexpected exit, but restart behaviour is a deployment choice. Configure logging, access controls and an alert path so a restart does not silently hide a recurring fault. A supervisor cannot fix an exhausted upload link, a bad key, an unreadable file, or an encoder that cannot process the source fast enough.
End the broadcast using the controls in Live Control Room and stop the encoder deliberately when appropriate. Check whether the broadcast has ended rather than merely assuming that terminating FFmpeg also updates every YouTube event state. Keep a known-good copy of the source and your configuration, but store credentials separately and restrict access to them.
Network changes deserve special attention for a server that stays in one place. If a local connection changes address or drops, YouTube can lose ingest even though the Ubuntu process is still running. For more on that operational failure mode, see what can happen after an Indian ISP changes a stream’s IP address. If operating the server and recovering its process is the part you need to remove, StreamNeo runs an uploaded video as a YouTube live stream with your computer switched off, and monitors and restarts the broadcast if it drops; it is YouTube-only.
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 play a prerecorded video as a YouTube live stream?
Create or select the broadcast in Live Control Room, then use an encoder to read the recording at playback speed and send it to the associated stream. For a server workflow, FFmpeg can do this if its build supports the required input, output codecs and RTMPS connection; test the actual file and preview first.
Can I stream a video file to YouTube Live from Linux without a desktop?
Yes. A headless Linux server can run a command-line encoder such as FFmpeg, provided the installed build and server can handle the file and output settings. OBS Studio is a graphical alternative, but it is not required for a headless setup.
Should I copy the video or transcode it?
Copying avoids re-encoding and can reduce processing, but only suits compatible source streams. Transcoding lets you set YouTube-compatible output properties, while increasing encoder work; inspect the source and verify your FFmpeg build before choosing.
Does this command or setup guarantee a successful live stream?
No single command works for every media file, FFmpeg build, server and network, and the setup cannot guarantee YouTube approval or uninterrupted delivery. Confirm current YouTube guidance, test the feed in Live Control Room, and monitor stream health during the event.