An FFmpeg concat workflow can read a prepared list of sermon videos in sequence and send their combined output to YouTube Live through an encoder feed. It is a practical route when the files are compatible, but the documentation for each component does not guarantee one uninterrupted 24/7 session.
The dependable approach is to check and, if needed, normalise the files, test the transitions and live ingest, then make a separate plan for failures and sermon archives. Below is a workflow you can validate with your own recordings before relying on it for a church channel.
What a concat sermon stream does
FFmpeg's concat demuxer reads media files listed in order and presents their streams as a sequence. In this case, the list might contain Sunday sermons, short notices and other recordings you have permission to broadcast. The output can then be encoded and sent to a YouTube Live ingest address. The FFmpeg documentation for the concat demuxer describes how it reads entries and the conditions files must meet.
The demuxer is not a playlist player with a guarantee of seamless handoffs. It expects the files to have matching streams: in practical terms, compatible stream layouts, codecs and time bases. FFmpeg adjusts timestamps between files, but duration information matters. If a stored duration is wrong, the next file's timestamps can be offset, producing a gap or an artefact.
A concat file also does not itself solve live operations. Reading files, encoding at a suitable rate, pacing prerecorded content in real time, connecting to YouTube, reconnecting after a network failure and restarting a stopped process are separate concerns. Do not treat a successful local concat test as proof that a full-time broadcast will remain live.
This distinction is useful when choosing the workflow. If your library is already consistent and you can test the exact chain, the demuxer may be straightforward. If recordings vary substantially, normalising them first can make the handoffs easier to reason about. If your priority is a managed broadcast rather than maintaining an FFmpeg process on a computer, a cloud workflow may remove the need to keep that computer running; StreamNeo, for example, removes that specific always-on-computer burden for an uploaded-file YouTube stream.
Check sermon files before joining them
Start with an inventory rather than a command. For each recording, note the container, video and audio codecs, frame size, frame rate, audio layout, duration and whether the file plays to the end. A simple spreadsheet is enough. Include the source filename and any known editing history so you can trace a problem back to an export.
Then inspect the streams with FFmpeg's probe tools or another media inspector. Compare the files, not just their extensions: two .mp4 files can contain different codecs or stream parameters. For the concat demuxer, matching stream structure, codecs and time bases are central compatibility checks. Differences in dimensions, frame rate or audio arrangement are signals to investigate, not a reason to assume that concatenation will silently fix the material.
When files do not match, you have two broad options. You can re-encode them to a shared profile before concatenating, which takes time and can change quality, file size and generation loss. Or you can use a filter-based workflow that decodes and re-encodes the inputs into a common output, which gives more control over mismatched sources but adds processing and configuration work. The FFmpeg FAQ is a useful reference for questions about joining media; validate the method against your installed FFmpeg build.
Pay attention to durations as well as codecs. If an edit has unusual timestamps or container metadata reports an inaccurate duration, concatenation may create timestamp problems at the boundary. FFmpeg's concat list syntax supports duration information, but overriding it is not a substitute for checking the actual media timeline. If you cannot establish the right duration confidently, test the transition and consider producing a corrected intermediate file.
Listen to the beginnings and endings of representative sermons. A clip that starts with several seconds of silence may be technically valid but can sound like the stream has stalled. One file may be much quieter than another, or end in the middle of a sentence. These are editorial issues rather than concat syntax problems, and they are easier to fix before the channel is live.
Build and review the concat file
Put the chosen recordings in a working folder and create a plain-text file with one entry for each file, in the intended order. A simple example is:
ffconcat version 1.0
file 'sermon-01.mp4'
file 'sermon-02.mp4'
file 'sermon-03.mp4'
For automatic recognition, the ffconcat version 1.0 marker must be exactly the first line. Keep the list and its media files together while testing. Relative filenames make it easier to move the test set between folders and are less surprising than paths that depend on a particular computer.
Review the order as a church programme, not merely as a file list. Consider whether an opening notice belongs before the first sermon, whether the final item leaves a long silence, and whether the next cycle should begin immediately or have a planned interstitial. A concat demuxer processes entries in sequence; it does not know which recordings should be omitted on a special day.
The demuxer's safe-path behaviour matters. Its safe option defaults to 1, which rejects paths or directives it considers unsafe. Use ordinary relative filenames for a portable list and avoid casually disabling that restriction with -safe 0, especially if a list is generated or comes from an untrusted source. Validate names with spaces and punctuation in a small test before preparing a longer schedule.
Before connecting to YouTube, run a local test that reads the list and produces a short output or otherwise lets you observe the boundaries. Check that FFmpeg opens every entry, that video and audio continue across each handoff, and that duration estimates look plausible. A successful local run proves only that this test set worked in that context; it does not verify real-time pacing, streaming credentials, network stability or recovery behaviour.
Keep a dated copy of the list and a record of which source files it references. If someone replaces a sermon file, update the list deliberately and retest the affected join. For a related discussion of transition problems, see how to prevent gaps when switching videos on a 24/7 YouTube stream.
Choose a starting stream configuration
Choose output settings based on the recordings and the available upload connection, then test them. YouTube's encoder settings guidance lists supported codecs and recommended settings for its ingest. It recommends RTMPS for encrypted transport, constant bitrate (CBR), and keyframes about every two seconds, with no more than four seconds between them. Recommended bitrate depends on codec, resolution and frame rate; use YouTube's current table rather than borrowing a number from an unrelated setup.
For a sermon archive recorded in modest detail, 720p at 30 frames per second may be a reasonable editorial starting point if it suits the source and the viewers' connection. If the camera footage contains fine detail or the source is 1080p, 1080p30 may be more appropriate. Neither is a platform mandate, and upscaling a low-resolution recording does not create detail. Start from what the original files can show and what your connection can sustain.
Your feed settings need to agree end to end. Decide on output dimensions, frame rate, video codec, audio codec, sample rate and bitrate, then check that the encoder output matches the YouTube Live event. Re-encoding can make a uniform output from varied inputs, but it uses processing capacity and may affect picture or sound. Avoid adding complexity until you have a reason to change a setting.
Network capacity is a separate limit from video encoding. YouTube's streaming tips recommend about 20% extra upload bandwidth above the total streaming bitrate, and advise allowing for primary and backup streams. Measure the upload connection at the location and time the channel will run, especially if the connection is shared with church staff, guests or other services. A speed test at a quiet hour is not a promise about evening performance.
Connect FFmpeg to YouTube Live
In YouTube Studio, enable live streaming if needed, then create or schedule an event for an encoder. YouTube's encoder setup instructions explain how to obtain the stream URL and key. Activation for a first-time channel can take time, so check the current instructions and eligibility before scheduling a launch.
Treat the stream key as a password. Anyone who has it may be able to send a feed to the channel's ingest. Store it outside a public script, shared document or repository; use a private configuration method and limit who can access it. If it is exposed, rotate it in YouTube Studio rather than assuming that an obscure filename protects it.
Configure FFmpeg to use the selected input list, produce the chosen output format and publish to the event's ingest URL with the key supplied securely. There are several valid ways to assemble this, and the exact command depends on the FFmpeg build, files, filters, output settings and operating environment. A command copied from a forum may omit real-time pacing or failure handling, so do not publish or deploy an untested one-line command as a guaranteed 24/7 appliance.
Start with an unlisted or otherwise controlled test event where feasible. Send the feed, wait for it to appear in Live Control Room, inspect the preview and confirm that the event is configured as intended before making it public. The official workflow and Studio screens can change, so follow the current YouTube instructions rather than relying on an old screenshot.
Test playback, transitions and audio
A useful test covers more than whether the preview appears. Watch at least one full transition between different source recordings. Check for a pause, a flash of black, a frozen final frame, a change in audio level or a missing audio stream. Listen on headphones and on a typical phone or television speaker, since low speech volume can be harder to notice in a control-room preview.
Check the sound in each sermon, not only the first one. One recording may have a lectern microphone, another a room microphone, and a third music under the opening. Their loudness and noise floor can differ. If you adjust levels or apply filters, preserve intelligibility and test the processed output; do not assume that a single setting will suit every source.
Monitor the Live Control Room's preview and stream health while the encoder runs. YouTube recommends testing the encoder, checking audio and video, and monitoring health. Also verify that viewers can access the event with the intended visibility and that the stream behaves as expected on a second device or network. A private test is useful, but it may not reproduce the same network load as a Sunday service.
Test failure cases deliberately when you can do so without disrupting a public broadcast. Confirm who notices if the encoder exits, the computer sleeps, storage fills or the internet drops. Restart behaviour may require process supervision or a human response; it is not supplied automatically by the concat list. Record what happened during each test and change one variable at a time so you can identify the cause of a failure.
If you use a computer at the church, disable sleep only if the machine is dedicated to this job and the setting is appropriate for its operating environment. Check power, cooling, storage and network cabling. A restart after a power cut may require someone to log in or start the encoder again. For alternative process recovery planning, automatic OBS restart guidance covers a different encoder, but the operational question is similar: who detects and responds when a process stops?
Plan for interruptions and archives
An always-on channel has ongoing operational needs beyond a file list. Decide who receives an alert, who can access the machine and YouTube Studio, and what they should check first. Keep a written recovery note with the event details, file location, safe key-handling instructions and steps to restore the feed. Do not put the stream key in a public-facing runbook.
Plan for network interruption, encoder failure, a damaged input file and a power outage. FFmpeg documentation does not promise that one integrated session will reconnect and resume correctly in every environment. Test the exact combination of files, software build, ingest destination and network, and treat reconnection or process restart as behaviour that must be validated. If a live service is important, assign a person to monitor it and keep a tested recovery path rather than relying on an unattended process with no alerts.
YouTube's archive is not a substitute for your own recording plan. Its help page says streams under 12 hours can be automatically archived, while streams longer than 12 hours may not be captured at all; it recommends making a local archive. That makes a single 24/7 event a poor place to rely on for retaining each sermon. Keep the source files and, if you need a copy of the actual broadcast, plan a separate local recording and check that it is being created and has enough storage.
If you want each sermon available on demand, retain and publish the individual recordings separately, with titles and descriptions reviewed by your church. Rotating live events may help organise broadcasts, but it is a scheduling choice, not a guarantee that every event or archive will behave as expected. For a different recorded-channel workflow, streaming a recorded chemistry revision channel may help you compare the operational planning questions.
Check rights before broadcasting and archiving. YouTube's livestream terms require the content provider to have the rights needed for live and archived material, including music rights. Owning a sermon video does not by itself establish rights to every worship song, backing track, image or guest contribution it contains. Confirm permissions and licensing for the material and check current official guidance; requirements may depend on your circumstances and location.
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 loop sermons with an FFmpeg concat file?
A concat file lists media entries for FFmpeg to process in sequence. It does not, by itself, establish a reliable infinite live loop or ensure that the output is paced and recovered correctly. Test the exact looping and streaming method you plan to use with your files and FFmpeg build.
Do all sermon videos need the same format?
For the concat demuxer, matching streams, codecs and time bases matter. If your recordings differ, inspect them and consider converting them to a common profile or using a filter-based workflow that re-encodes to a consistent output. Check the resulting transitions rather than assuming that matching file extensions means compatibility.
What bitrate should I use for YouTube Live?
Use YouTube's current encoder settings table for your chosen codec, resolution and frame rate, then check that the upload connection can sustain the stream with the recommended headroom. A bitrate recommendation is an ingest guideline, not a guarantee of picture quality on every source or network. Test under the conditions in which the channel will operate.
Will YouTube save every sermon from a 24/7 stream?
Do not rely on the YouTube archive for a continuous event: YouTube warns that streams longer than 12 hours may not be captured. Keep the original sermon files and arrange a separate local recording or publish the individual sermons separately if you need dependable on-demand copies.