FFmpeg can send a prerecorded lesson file to a YouTube Live broadcast and repeat it continuously. The basic pattern is -stream_loop -1 to repeat the input and -re to read it at normal playback speed, but neither option guarantees that the broadcast will remain connected.
For a dependable 24/7 lesson channel, you need more than a working command. You need a prepared file, a correctly configured YouTube broadcast, a protected stream key, process supervision, a recovery plan and a decision about whether the live archive matters.
Prepare the lesson file
Start with the video rather than the command. A lesson that plays correctly in a media player can still cause trouble in a long-running encoder if it has damaged timestamps, missing audio, variable frame behaviour or an unusual codec. Play the complete file from beginning to end before using it for a live broadcast.
Check that the file contains the streams you expect. For a normal lesson, that usually means one video stream and one audio stream. FFmpeg can inspect the file with ffprobe, which is included with many FFmpeg installations:
ffprobe lesson.mp4
Look for the duration, video dimensions, frame rate, video codec, audio codec and sample rate. If the lesson has no audio, that is not automatically a problem, but YouTube and your encoder still need a deliberate output configuration. Silent educational video may be better served by adding a suitable audio track or configuring the output so that the absence of audio is handled consistently.
Use a stable filename without spaces while you are testing. For example, lesson.mp4 is easier to place in a script than a filename containing several punctuation marks. Keep the original file separately so that you can return to it if you create a compatibility version.
You have two broad output approaches. With -c copy, FFmpeg can pass the existing codecs through without re-encoding. This uses less CPU, but only works reliably when the source codecs, timestamps, pixel format and container-to-output combination fit the YouTube workflow. Transcoding with H.264 video and AAC audio is more predictable when the original file came from an editing application, phone or screen recorder.
Do not choose a bitrate simply because it appears in an example command. The suitable value depends on resolution, frame rate, codec, source quality and your upload capacity. Use YouTube's current encoder settings, bitrates and resolutions as the reference, then test the actual file and connection you intend to use.
A lesson channel also needs a content check. Make sure you own the lesson, have permission for any music and have rights to graphics, photographs, fonts and included clips. A file can be technically ready while still needing a rights review before it is broadcast.
Create or schedule the YouTube Live stream
In YouTube Studio, create a live stream using an encoder. YouTube provides the ingest server URL and a stream key for that broadcast. You then give those details to FFmpeg, which sends the encoded video to YouTube over the live connection.
If you are using live streaming on the channel for the first time, YouTube says the channel must meet its current eligibility requirements and that enablement can take up to 24 hours. Restrictions and requirements can change, so check the current instructions in YouTube's guide to creating a live stream with an encoder before scheduling a public lesson channel.
A scheduled stream and an immediate stream have different operating steps. With a scheduled broadcast, YouTube Studio may show a preview before you start the event. You may need to click the relevant control in Live Control Room after FFmpeg has connected. Do not assume that sending data to the ingest endpoint automatically makes every scheduled broadcast public.
Set the title, description, visibility, category and audience settings before the first test. If the lesson is for children, review the relevant audience declaration carefully. Add enough information for a viewer to understand what is being repeated and when the programme may restart.
For a first test, use an unlisted broadcast. This lets you confirm that video, audio, orientation, timing and captions behave as expected without announcing an unfinished stream. Watch from a separate device or network. The encoder's local output is not the same as the viewer's delivered picture.
The stream key is a credential. Treat it like a password: do not publish it in a tutorial, commit it to a public repository, put it in a screenshot or leave it in a shared log. If it is exposed, reset it in YouTube Studio and update the process that uses it. A separate key for testing can reduce the chance that a test interrupts the main broadcast.
Configure FFmpeg for YouTube
The following is a general command shape for a local FFmpeg process. Replace every placeholder, and never replace the placeholder with a key that you intend to share:
ffmpeg -re -stream_loop -1 -i lesson.mp4 \\
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
This example transcodes the video to H.264 and the audio to AAC, then writes an FLV-formatted stream to an RTMPS destination. The bitrate values are examples for illustrating the command structure, not universal recommendations. Select output settings from YouTube's current guidance and from what the source can support.
The -g and -keyint_min values relate to keyframe placement. The example uses a group-of-pictures interval that can correspond to a two-second interval at a particular frame rate. If you change the frame rate, revisit the calculation rather than copying the number unchanged. YouTube's guidance recommends a two-second keyframe frequency and says it should not exceed four seconds.
RTMPS is the secure transport pattern used in the example. Google also documents the delivery of live YouTube content through RTMPS ingestion. Copy the current server URL from YouTube Studio rather than assuming that an old address or a remembered format is still correct.
The order of input options matters in FFmpeg. Options that affect an input normally belong before -i, while output options belong after the input. That is why -re and -stream_loop -1 appear before -i in this example. Confirm the syntax against the FFmpeg version installed on the machine. Builds differ, and a command copied from an older guide may not behave exactly as expected.
If the source is already compatible, you can investigate a stream-copy variant:
ffmpeg -re -stream_loop -1 -i lesson.mp4 \\
-c copy -f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
Use this only after testing. Stream copying can preserve source problems and may fail when the file has incompatible codecs, timestamps or an output format that does not accept the streams. Transcoding consumes more CPU but gives you more control over the video and audio delivered to YouTube.
Keep the key out of shell history where possible. A small environment variable or protected configuration file is safer than writing a credential into a script that will be shared. Check file permissions, avoid verbose logs containing the full destination, and redact the key before sending diagnostic output to anyone.
Repeat the input with -stream_loop -1
The option -stream_loop -1 tells FFmpeg to repeat the input indefinitely. When the file reaches its end, FFmpeg opens it again and continues producing output. For a single prerecorded lesson, this is the part of the command that creates the repeating programme.
It does not create a playlist. If you have several lessons, concatenate them into a planned file, use a playlist workflow that you have tested, or move to a different scheduling design. A single input loop will return to the beginning of that one input, which may be exactly what you want for a prayer lesson or revision class, but not for a channel that needs different episodes in sequence.
The loop also does not repair the source between passes. If the file has a timestamp issue at the end, a bad final frame or an audio transition that causes the process to exit, repeating the input will repeat the problem. Watch at least one complete cycle and the transition back to the first frame before treating the setup as ready.
A file repeating locally is not the same thing as a broadcast staying live. FFmpeg may exit because of an input error, an output error, a resource problem or a condition in the installed build. The network may drop while the file continues to exist. YouTube may stop receiving data even though the local process appears to be running.
For multiple lessons, a prepared combined programme may be easier to reason about than several independent commands. You can then review the order, transitions and total duration before putting it on air. If you need to change the programme while it is running, a fixed local loop is a poor fit. A workflow designed for remote changes is covered in this guide to changing videos in a running 24/7 YouTube stream remotely.
Pace playback with -re
The -re option tells FFmpeg to read the file at its native rate rather than consuming it as quickly as the machine can process it. Without real-time pacing, a local file can be read far faster than its intended duration, which is not how a normal live encoder should feed a prerecorded lesson.
This matters even when the computer is powerful. FFmpeg's ability to process the file quickly is not a reason to send several minutes of lesson content in a few seconds. YouTube expects a live input with timing that progresses as a broadcast, and viewers need audio and video to arrive at a usable pace.
-re is not a network throttle and is not a recovery mechanism. It does not make a weak upload connection stronger, and it cannot reconnect a process after an output failure. It only controls how FFmpeg reads the file for the input workflow. A correctly paced stream can still disconnect when the network, computer or YouTube session fails.
Monitor timing during the test. Look for audio that drifts, video that freezes, a steadily increasing delay or a process that reports repeated buffer and connection errors. Compare the live picture with the local file, but also check what a viewer sees after the stream has passed through YouTube.
The source frame rate affects keyframe planning and output load. A high-resolution lesson with a high frame rate may require more CPU and upload capacity than a simple talking-head class. If the original file is larger than necessary, create a deliberate delivery version instead of relying on the encoder to struggle through it indefinitely.
You can read more about choosing an appropriate output profile in this FFmpeg bitrate and resolution guide for a 24/7 YouTube stream. Treat that guidance as a starting point, then verify the current YouTube settings and the results from your own upload connection.
Supervise and monitor the long-running process
A command that runs for a lesson is not automatically a service that can operate unattended overnight. On a local machine, the process depends on power, operating-system updates, disk health, network stability and the account that launched it. Decide which of those can fail and what should happen next.
At minimum, use a process supervisor or a carefully tested wrapper that can detect an unexpected FFmpeg exit and start it again. The exact mechanism depends on the operating system. A Linux service manager, a container policy, a scheduled task or a small script may all be suitable, but each needs testing. Do not add an automatic restart rule without checking whether it could create a rapid restart loop.
A restart is not the same as seamless recovery. The new FFmpeg process may begin the file from the start, YouTube may show a break, and the scheduled broadcast may require an action in Live Control Room. Protocol reconnect options are specific to the protocol and failure mode. FFmpeg's protocol documentation should be checked against the options supported by your installed build.
Monitor more than whether a terminal window is open. Useful checks include:
- whether the FFmpeg process still exists
- whether the process is producing output rather than merely remaining alive
- whether upload traffic is continuing
- whether YouTube reports a healthy incoming stream
- whether the public or unlisted viewer sees current video and audio
- whether CPU, memory, disk and temperature remain within safe limits
Keep logs, but redact the stream key. Record the time of a failure, the FFmpeg exit message, the network state and what YouTube Studio displayed. This turns an overnight failure into a diagnosis rather than a guess.
Run a long burn-in before publicising the channel. Include a loop boundary, a temporary network interruption if you can test one safely, a machine restart and a recovery from an FFmpeg error. A short test confirms that the command starts. It does not confirm that the operating plan survives the night. The 48-hour burn-in checklist gives this kind of test a more deliberate structure.
If keeping a local machine powered and supervised is too much work, a managed workflow can remove the need to keep your own computer running. StreamNeo addresses the specific problem of uploading the finished video once, connecting it to your YouTube stream key and having the cloud-run broadcast monitored and restarted without requiring an installation on your computer. It remains your responsibility to check the video, account, rights and YouTube requirements.
Plan continuity and archive trade-offs
A repeated input and a continuous broadcast are separate things. The first describes what FFmpeg does when it reaches the end of a file. The second depends on the process, network path, YouTube session and the actions taken after a failure. Do not describe -stream_loop -1 as a guarantee of uninterrupted broadcasting.
There is also a difference between keeping a channel live and preserving a complete replay. YouTube says live streams under 12 hours can be automatically archived, while streams exceeding 12 hours may not be captured at all. That means a 24/7 broadcast should not be sold to your viewers as a guaranteed 24-hour recording.
If replay matters, maintain a local recording as a separate safeguard. Check that the recording is actually being written, that the storage has enough room for the planned period and that the resulting files can be opened. A local recording protects against one kind of archive problem, but it does not replace checking whether the live broadcast reached YouTube correctly.
You can also divide the programming into manageable broadcasts. That may make individual replays easier to locate and reduce the risk of asking one live event to cover a period for which YouTube does not promise a complete archive. It introduces boundaries that viewers may notice, so test how the hand-off, title and restart appear on the channel.
Choose the operating model against the work you are willing to do:
| Approach | Main control | Main operational burden | Suitable when |
|---|---|---|---|
| Local FFmpeg process | Direct control of the file, command and machine | You maintain power, network, updates, supervision and recovery | You are comfortable testing and monitoring a computer |
| Hosted machine running FFmpeg | The process can run away from your home or office | You still maintain the command, credentials, logs and recovery plan | You want remote access but can manage a long-running process |
| Managed prerecorded-video workflow | Less hands-on process maintenance | You must understand the provider's current YouTube workflow, limits and terms | You want the file to run without leaving your own computer on |
No row guarantees a gap-free broadcast or a complete YouTube archive. Compare monitoring, restart behaviour, control over programme changes, stream-key handling, current YouTube support and total operating cost before choosing one.
Finally, consider channel policy and viewer value. YouTube's monetisation policies apply to live streams, and its current guidance on inauthentic content warns against repetitive or mass-produced material with little educational value. That does not establish that every repeated lesson is prohibited, but a continuous identical loop should not be presented as a monetisation shortcut or a guarantee of eligibility. Make the educational purpose clear, use material you have rights to use, and check YouTube's current channel monetisation policies before relying on revenue.
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 FFmpeg loop one lesson on YouTube all day?
Yes, -stream_loop -1 can repeat a file indefinitely while FFmpeg is running, and -re can pace it at normal playback speed. The loop does not guarantee that the process, network connection or YouTube broadcast will stay live.
Should I use -c copy or transcode the lesson?
Use -c copy only when the source streams and timestamps are known to fit the output. Transcoding to a compatible H.264 and AAC output is often more predictable, but it uses more CPU and still needs settings matched to YouTube's current guidance.
Will YouTube save the complete 24-hour lesson stream?
Do not rely on that. YouTube says streams exceeding 12 hours may not be captured, so keep a local recording and consider dividing programming into separate broadcasts if replay is important.
What happens if the FFmpeg process stops overnight?
The broadcast may stop or show a gap, even if the file itself is still available. Use supervision, logs and a tested restart plan, then confirm how YouTube handles the new connection rather than assuming it will resume seamlessly.