If your worship video already matches YouTube Live’s ingest requirements, FFmpeg can loop it continuously and send it without re-encoding. The command uses -stream_loop -1, -re and -c copy; it does not make an incompatible file suitable for YouTube.
That distinction matters: stream copy preserves the input streams rather than changing their codecs, bitrate, resolution or keyframe cadence. Check the file and the current YouTube settings first, then test the feed before relying on it for a service or overnight broadcast.
Can FFmpeg loop a worship video without re-encoding?
Yes, provided the file is already appropriate for the output container and YouTube’s live ingest. FFmpeg can read a file repeatedly, pace its input as a live feed and copy the selected audio and video packets to an output. No new encode is performed in that workflow.
The condition is not a small technicality. A video that plays properly on a laptop may still have a codec, frame cadence or keyframe interval that is unsuitable for your planned live stream. With -c copy, FFmpeg does not decode and rebuild the media to correct those properties. If the source needs a change, use a compatible pre-encoded file or transcode it before streaming.
This is useful when a church has a finished recording or visual loop prepared to the required settings and wants to avoid another generation of encoding. It is less suitable when the source is unknown, has unusual tracks, or needs resizing or audio repair. If you need to adjust output properties, see the FFmpeg guide to setting a YouTube stream to 720p; that kind of adjustment is different from pure stream copy.
The stream-copy command
For a local file named worship.mp4, the basic pattern is:
ffmpeg -re -stream_loop -1 -i worship.mp4 -c copy -f flv "$YOUTUBE_RTMPS_URL"
This is a command pattern, not a promise that any MP4 will work. The input must contain streams suitable for the chosen output, and the destination variable must contain the current RTMPS ingest address assembled from YouTube’s live setup. The example deliberately contains no real stream key.
The placement of options is important. -re and -stream_loop -1 are input options, so put them before the -i for the file they affect. The output options -c copy and -f flv appear after the input and before the destination. FFmpeg’s command-line documentation describes option scope and the loop and copy options.
The flv muxer is commonly used with RTMP-family live ingest, but the source streams still have to be accepted in that container and by YouTube’s ingest. If FFmpeg reports that a stream cannot be muxed, or YouTube shows an ingest error, do not add random encoding flags while retaining -c copy. First establish which property is incompatible.
What the three main flags do
-stream_loop -1 asks FFmpeg to loop the input indefinitely. FFmpeg documents -1 as infinite looping. It is an input option; placed after -i, it will not apply to that input in the intended way. Looping means FFmpeg reaches the end and starts the input again. It does not guarantee that the transition will be seamless or that YouTube will never disconnect.
-re reads the input at its native rate, equivalent to a read rate of one. A file can otherwise be processed faster than real time, which is not what you want when using a file as the source of a live feed. Put it before the relevant -i. It paces file reading; it does not convert the file’s frame rate or make its timing more suitable for YouTube.
-c copy selects stream copy rather than encoding. FFmpeg passes along the selected packets without re-encoding. That avoids an additional encode, but it also means that this command cannot change the video codec, audio codec, resolution, bitrate or keyframe pattern. A flag such as -b:v does not cause copied video packets to be re-encoded to a new bitrate.
Together, these flags solve a specific job: repeat a file, read it at a live pace, and send its existing streams. They do not solve source preparation. For a wider workflow that uses more than one prerecorded item, the guide to continuously streaming prerecorded videos covers a different scheduling problem.
Check file and YouTube ingest compatibility
Start with the file, not the live key. Inspect the video and audio streams with a media inspection tool such as ffprobe, or use a media player that displays codec and stream details. Record the video codec, dimensions, frame rate, bitrate if available, keyframe interval, audio codec, sample rate and whether audio is present. Compare those facts with the current YouTube encoder settings.
YouTube’s guidance lists H.264, H.265/HEVC and AV1 video for RTMP/RTMPS ingest, frame rates up to 60 fps, and CBR encoding. It recommends a two-second keyframe frequency and says not to exceed four seconds. Its audio guidance includes AAC and MP3, with AAC required for 5.1 audio over RTMP/RTMPS. Check the current page for the full settings and any changes before using a source file.
Bitrate is tied to the intended resolution and frame rate, not to the word “worship” or to MP4 as a file extension. As one example, YouTube lists H.264 1080p30 at 5 Mbps minimum and 14 Mbps recommended; its 720p30 H.264 row lists 3 Mbps minimum and 8 Mbps recommended. Those are YouTube’s encoder-setting figures, not a guarantee that a particular source or connection will work. Choose the row that matches your planned output and check the current official guidance.
| Workflow | What happens to the source | Use it when | Main limitation |
|---|---|---|---|
| Stream copy | Existing audio and video packets are sent without another encode | The file already fits the intended ingest settings | It cannot change codec, bitrate, size or keyframe cadence |
| Transcoding | Media is decoded and encoded to chosen output settings | The source needs a supported codec, size or other adjustment | It requires an encode and suitable processing capacity |
This comparison is why the command should be treated as conditional. If your file has an unsupported codec or a keyframe pattern that does not meet the intended settings, copy mode preserves the problem. A video with no audio may also not match the stream you intend to publish; verify that configuration in a test rather than assuming acceptance. For church-specific source preparation, the format and bitrate notes for a nonstop church stream are a useful companion, but YouTube’s current documentation remains the authority for ingest requirements.
Add the YouTube Live destination safely
Create or open the live stream in YouTube Studio and use the current stream setup details shown there. YouTube recommends RTMPS, the secure RTMP transport. Google’s RTMPS delivery guide describes the connection requirements, including the rtmps protocol, a valid ingestion endpoint and application path, and port 443. Do not assume that an address copied from an old tutorial is the right endpoint for your stream.
Keep the stream key private. It grants access to send a broadcast to the associated live setup, so do not put it directly in an article, screenshot, public repository or a command you intend to share. Avoid leaving it in shell history where other users of the same account can read it. A safer pattern is to supply the full URL through an environment variable in a private session:
export YOUTUBE_RTMPS_URL='rtmps://YOUR_CURRENT_INGEST_PATH/YOUR_PRIVATE_KEY'
ffmpeg -re -stream_loop -1 -i worship.mp4 -c copy -f flv "$YOUTUBE_RTMPS_URL"
The placeholder is not a usable destination. Populate the variable from the current YouTube setup without posting its value or including it in logs you share. Shell environment variables reduce accidental exposure in the command text, but they are not a substitute for securing the account and machine. If a key is exposed, use YouTube Studio’s controls to replace or reset it, then update the private value used by FFmpeg.
Before starting, confirm that the URL is an RTMPS address provided for the current setup and that it is complete. A typo in the endpoint or path can look like a media problem when the connection is actually aimed incorrectly. YouTube’s guidance on live streaming in India and activation timing is relevant if the channel is new or live access has not yet been enabled; allow for account setup rather than troubleshooting a local command alone.
Test the feed before relying on it
Run a test while you can watch both FFmpeg’s output and the YouTube live control room. YouTube advises testing and monitoring stream health. Confirm that FFmpeg connects without muxing errors, that YouTube receives video and audio as expected, and that the preview looks and sounds right. A successful connection alone does not establish that the picture, sound or timing is suitable for viewers.
For a real test, use the same file, destination configuration, computer and network conditions intended for the broadcast. Watch through the file’s end and into the loop boundary. Look for a brief black frame, a pause, audio clipping, silence, a jump in music, or an abrupt change in scene. Stream copy does not blend the end and beginning of a file; if they do not join cleanly, edit the source or prepare a version whose boundary is suitable.
Check YouTube’s stream health indicators during the test and compare what they report with the source properties you inspected. If the preview is black, audio is absent, or the picture is delayed, isolate one cause at a time: verify the selected input, inspect the tracks, confirm the destination, then review the file’s settings. The black-screen troubleshooting guide for prerecorded YouTube streams can help with a visual symptom, although its OBS-specific steps do not replace FFmpeg checks.
A test is particularly important before leaving a channel unattended overnight. A loop can continue locally while the destination connection has failed, and a reconnect or account issue may require attention. If the broadcast must continue while your own computer is switched off, that is a separate operating choice: StreamNeo can remove the need to keep your computer running by turning an uploaded video into a YouTube live stream, but it does not change the requirement to prepare suitable content or check YouTube’s current ingest guidance.
Troubleshoot common stream-copy failures
FFmpeg says the output format or stream is unsupported. Check which audio and video streams are actually in the input and whether they can be carried in the selected output format and sent through the chosen protocol. The .mp4 extension describes a container, not a guarantee about the codecs inside it. If the source cannot be muxed as required, use a suitable source or transcode; copy mode cannot convert it.
YouTube does not receive a stable feed or reports an ingest issue. Check the endpoint and application path against the current live setup, ensure the address uses RTMPS, and verify the network can reach the required service. Then compare the source codec, bitrate expectations, frame rate and keyframe cadence with YouTube’s current settings. Do not assume that changing an output bitrate flag will alter copied packets.
There is picture but no sound. Confirm the file contains an audio stream and that FFmpeg is sending it. Check its codec and channels against the current YouTube guidance, then watch and listen to the preview. If the audio requires a codec change or level adjustment, that requires a different prepared source or an encode rather than -c copy alone.
The loop repeats but the join is distracting. The command restarts the file; it does not crossfade the last frame or audio into the first. Make the start and end compatible in an editor, or choose a different file. A stream-copy command cannot manufacture a smooth transition between unrelated ending and opening material.
The stream stops after a while. First distinguish a local process exit from a dropped connection or a YouTube-side stream state change. Review FFmpeg’s terminal output and YouTube’s health information, then test the file loop and destination separately. This command documents looping, not automatic recovery from every failure; plan how the broadcast will be observed and restarted if your setup needs that.
A practical preflight sequence
Before using the command for a service, keep a short written record of the media facts and the live setup. Confirm the input path is correct, the intended audio and video tracks exist, and the file properties match the chosen YouTube settings. Check that the local machine has access to the file and that it will not sleep or lose its network connection during a computer-run broadcast.
Next, prepare the private RTMPS destination from YouTube Studio, keeping the key out of shared scripts and screenshots. Run the command in a test stream, inspect FFmpeg’s output, and watch YouTube’s preview through at least one loop boundary. If the result is not right, change one part of the workflow at a time and repeat the test; this makes it easier to tell whether the issue is the file, the command, or the connection.
Keep a known-good copy of the file and note the settings that were actually checked. If you later replace the recording or edit its audio, repeat the preflight rather than assuming the new file inherited the previous file’s compatibility. For a channel that must run without a local computer, the choice is no longer only between copy and transcode; compare operating arrangements as well as media preparation.
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
Does -c copy mean the video will work on YouTube Live?
No. It means FFmpeg copies the selected encoded streams instead of re-encoding them. The codecs and stream properties still need to fit the output and YouTube’s current ingest requirements, so inspect the file and test the feed.
What does -stream_loop -1 do?
It tells FFmpeg to repeat the input indefinitely, and it belongs before the relevant -i option. It repeats the file but does not ensure a seamless join or an uninterrupted live connection.
Can I change the bitrate while keeping stream copy?
Not by setting an output bitrate option: copied packets retain the bitrate characteristics of the source. If the source needs different encoding settings, prepare a compatible file or transcode it before sending it live.
Is it safe to put my YouTube stream key in the command?
Do not publish or share a command containing the real key, and avoid leaving it in shell history or public scripts. Use the current RTMPS details from YouTube Studio and keep the key private; replace it if it is exposed.