FFmpeg can repeat a local lofi track, pace the file as real-time input, encode the programme and send it to YouTube Live. The complete setup also needs a continuous video stream, a YouTube ingest URL and stream key, and monitoring in Live Control Room.
The important detail is option placement. Input options such as looping and real-time file reading belong before the -i they affect, while encoding and output options belong before the destination. The examples below are templates to adapt and test on your installed FFmpeg build, not commands presented as tested or guaranteed.
What FFmpeg does in a YouTube live workflow
FFmpeg is the processing step between your media files and YouTube. It reads audio and video, selects the streams you intend to use, encodes them into a live-compatible format, and writes the result to YouTube's ingest endpoint.
A local music file is not automatically a live source. If FFmpeg reads it as quickly as it can, the process may finish much sooner than the track's playing time. For a live channel, you need the file to repeat and the output to move at roughly the same pace as playback. This is why looping and real-time reading are separate parts of the workflow.
YouTube also expects a programme with video for a conventional live broadcast. A lofi channel can use a still image, an animated visual, a waveform, or a longer visual loop, but that video must continue for as long as the audio output. If the video input ends first, the output may stop or the audio and video may no longer be composed as intended.
The broad path looks like this:
- Prepare the audio and visual files.
- Decide whether the audio is inside one video file or in a separate input.
- Place input options before each matching
-i. - Read local files at their natural rate.
- Encode the programme and send it to YouTube.
- Confirm the preview and health indicators before relying on the broadcast.
If you are starting with pre-recorded material rather than FFmpeg, the workflow in starting a 24/7 YouTube stream from pre-recorded videos covers some of the same preparation decisions from a less command-line-focused angle.
Prepare repeating lofi audio and continuous video
First check what your source actually contains. A file named lofi.mp4 may contain both a video stream and an audio stream. A file named lofi.flac, lofi.mp3 or lofi.wav normally contains audio only. Your choice affects the command because FFmpeg must know which input supplies video and which supplies audio.
A simple starting arrangement is one MP4 file containing the visual and its audio. Looping that single input keeps the relationship between the two streams straightforward:
ffmpeg -re -stream_loop -1 -i lofi_visual_with_audio.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-pix_fmt yuv420p -r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-b:v 3000k -maxrate 3000k -bufsize 6000k \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmp://SERVER/APP/STREAM_KEY"
This is an illustrative starting template, not a tested command and not a universal YouTube profile. The SERVER, APP and STREAM_KEY text is a placeholder. Replace the output with the current stream URL supplied in YouTube Studio, and keep the key private.
The loop may be less tidy when a track ends. A short gap, an audible click, or a mismatch between the audio and visual duration can become noticeable each time the file repeats. Listen to several boundaries locally before using the file for a public broadcast. If the source contains a visual loop and audio of different lengths, test how your chosen FFmpeg version handles the end of each stream rather than assuming that it will continue cleanly.
For separate files, think in terms of two inputs. The intended audio and video streams should be mapped explicitly, because automatic selection can choose a stream you did not expect. A schematic form is:
ffmpeg -re -stream_loop -1 -i visual.mp4 \
-re -stream_loop -1 -i lofi.mp3 \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -c:a aac \
-f flv "rtmp://SERVER/APP/STREAM_KEY"
This second example is deliberately incomplete as a production profile. Separate inputs can have different durations, timestamps, frame rates and codec requirements. Exact filter, synchronisation and end-of-stream behaviour depends on the files and the installed FFmpeg build. Use it as a diagram of the input and mapping structure, then build and test the final command with your actual media.
Do not use music merely because it is available to you. A copyright claim can affect a live broadcast and the channel's later use of the recording. The practical implications are discussed in whether copyright claims on a YouTube livestream affect the channel. Check the current YouTube and rights-holder guidance for the music you plan to use.
Put input options before the matching input
FFmpeg options have scope. An option placed before an input generally describes how FFmpeg should read that input. An option placed before the output describes how FFmpeg should encode or write the resulting programme.
For example, in this structure:
ffmpeg [input options] -i source-file [output options] output-target
-stream_loop -1 is an input-side instruction for repeating a file. The -1 value represents indefinite looping in builds that support this option. Put it before the -i for the file you want to repeat. With two inputs, place the relevant loop option before the matching input rather than assuming one option will apply to every source.
The exact -stream_loop syntax and behaviour can vary with the FFmpeg version you installed. Confirm it against the local documentation before treating the command as copy-and-run guidance:
ffmpeg -h full
Search the output for stream_loop, then check the normal FFmpeg documentation at ffmpeg.org. This matters especially when audio and video are separate, because the command can start successfully while still producing an unexpected end condition or stream selection.
-map is another useful control. In a one-file source, FFmpeg may automatically select what appears to be the best video and audio stream. That may be acceptable for a simple file, but explicit mapping is clearer when a file contains multiple audio tracks, subtitles, cover art or more than one video stream. For separate sources, -map 0:v:0 -map 1:a:0 states that video should come from input zero and audio from input one.
Read option placement as part of the meaning of the command, not as formatting. A command can look plausible in a terminal and still apply a setting to the wrong input or output. Make one change at a time during testing so you can identify whether a problem comes from the source, the mapping, the encoder or the network connection.
Read local files at real-time pace
When FFmpeg reads a local file for a live output, -re tells it to read at the file's native rate. FFmpeg documents this as equivalent to -readrate 1, and it is useful when packets need to leave at real-time pace rather than as quickly as the computer can decode them.
For a local file, the usual position is before its -i:
ffmpeg -re -i lofi_visual_with_audio.mp4 ...
Combined with indefinite repetition, the input portion may look like this:
ffmpeg -re -stream_loop -1 -i lofi_visual_with_audio.mp4 ...
Do not apply a low read rate indiscriminately to an input that is already live, such as a capture device or an incoming stream. That source already arrives in real time. Adding an inappropriate read limit can contribute to packet loss or delay. Treat -re as a pacing instruction for file input, not as a universal live-stream switch.
You can check whether the process behaves as expected by observing elapsed time, FFmpeg's output messages and the YouTube preview. A five-minute file should not be consumed almost instantly, and the process should not stop when the first pass ends if the loop option is working as intended. These observations are a diagnostic, not proof that a full overnight broadcast will remain healthy.
The files themselves also affect pacing. Variable frame rate video, unusual timestamps, damaged media or an audio stream with a different duration can create symptoms that look like network problems. Inspect and repair the source before adding more switches. A clean, representative test file is easier to troubleshoot than a whole folder of mixed tracks.
Encode and send to YouTube's ingest endpoint
YouTube Live provides the destination information in Live Control Room. Create or select the event, then copy the stream URL and stream key into the encoder output. YouTube describes the stream key as information used by the encoder to send the feed, so treat it like a password. Do not publish it in a screenshot, script repository or public support post. If it is exposed, reset it in Live Control Room and update the command.
YouTube's current encoder guidance recommends RTMP or RTMPS, constant bitrate, an appropriate keyframe interval, and supported audio formats. Its published guidance includes a two-second keyframe interval, with the interval not exceeding four seconds, and recommends AAC or MP3 audio for RTMP or RTMPS. For stereo audio, it lists 128 Kbps and a 44.1 kHz sample rate. Check the current YouTube live encoder settings before publishing because platform recommendations can change.
The template uses AAC at 128k and 44100 Hz for that reason. The video values in the example are not a universal answer. Resolution, frame rate, available upload capacity and your encoder support all affect the suitable video settings. A slower connection may require a lower resolution or bitrate, while a larger moving visual may need more data than a mostly static image.
The output format in the example is FLV, which is commonly used for RTMP delivery. The endpoint must be the current URL from your event, not a guessed address. If YouTube supplies an RTMPS endpoint, use that endpoint exactly as shown.
Before starting, write down the settings you intend to use:
| Part of the programme | Example in the template | What you must verify |
|---|---|---|
| Video codec | libx264 |
Supported encoder and suitable CPU load |
| Pixel format | yuv420p |
Compatibility with the selected video path |
| Frame rate | 30 |
Matches the visual and available upload capacity |
| Keyframe controls | -g 60, -keyint_min 60 |
Current YouTube interval guidance and frame rate |
| Video rate | 3000k with a matching maximum |
Resolution, movement and upload capacity |
| Audio codec | aac |
Supported live audio format |
| Audio rate | 128k |
Current platform guidance and channel needs |
| Audio sample rate | 44100 |
Source and current platform guidance |
| Destination | RTMP or RTMPS URL | Exact URL and private stream key |
The table separates an example from a requirement. Do not assume that copying every value produces the right result for your channel. YouTube's live streaming technical issues guidance can help you interpret format, bitrate and keyframe warnings.
A local computer is useful when you already have reliable power, upload capacity and a way to restart the process after a failure. An always-on VPS can make remote operation easier, but it adds administration, source-file transfer and restart supervision. If you are comparing those routes, 24/7 streaming on a VPS versus a managed service is a useful way to think about operational effort rather than just the command itself.
If the main problem is keeping the computer on and restarting the broadcast after a drop, StreamNeo removes that particular routine: you upload the video once, add the YouTube stream key, and the cloud-run broadcast can continue while your own computer is off, with automatic monitoring and restart handling. It is YouTube-only, so you should still confirm that this matches your channel's workflow and test the output before depending on it.
Test the feed before making it public
Use a private or unlisted test event where possible. Start with a short, representative visual and the same audio arrangement you expect to use in the real broadcast. Include a loop boundary in the test, because a file that plays once does not prove that the repeated input is behaving correctly.
YouTube's encoder guidance says, “Make sure to test before you start your live stream.” During the test, look for a preview in Live Control Room, confirm that audio is present, and watch for warnings about bitrate, format, codec or keyframe frequency. The YouTube Help page on creating a live stream with an encoder describes the control-room workflow.
Check the FFmpeg terminal as well. A healthy-looking process can still be sending the wrong stream, while an obvious error may explain why the preview is absent. Useful questions include:
- Is the process still running after the first track duration?
- Does the video remain visible when the audio reaches its loop boundary?
- Is the selected audio stream the one you intended?
- Does the output rate remain close to the configured rate?
- Does YouTube report a format, bitrate or keyframe issue?
- Does the machine have enough CPU, memory and upload capacity for the chosen encode?
Do not make a long broadcast public until you have allowed enough time to observe at least one complete repetition and the transition back to the beginning. A short test cannot prove that a process will survive every later network or machine failure, but it can expose incorrect option placement, a missing video stream and obvious synchronisation problems.
Monitor the stream while it is live
Starting FFmpeg is not the same as operating a reliable channel. Keep Live Control Room available and check stream health during the event. YouTube's dashboard can identify errors involving format, codec, bitrate and keyframe frequency. Correct the underlying setting rather than hiding the warning with unrelated command changes.
Audio deserves its own check. Listen for silence, clipping, a sudden level change at the loop boundary and gradual drift between the visual and the music. If a separate visual file ends, the output may terminate even if the audio loop is working. A continuous programme needs both sides to remain available.
Network monitoring matters too. A local process can continue reading and encoding while the upload is failing. Look at the YouTube preview and health state, not only at the fact that FFmpeg has not exited. If the connection drops, the process may need to reconnect or be restarted, depending on the failure and the supervision around it.
Treat the stream key as an operational credential. Store it outside public code and rotate it through Live Control Room if you believe it has been exposed. YouTube's stream key guidance should be your reference for the current control-room steps.
If you need an archive, check the current YouTube policy rather than assuming a long stream will be preserved in full. YouTube's encoder setup documentation says streams under 12 hours are automatically archived, but that statement should not be used as a promise about longer broadcasts. For important programming, consider a separate local recording or segmented events and verify the current rules before relying on the archive.
Choose a practical operating arrangement
There are three common ways to keep this workflow running. You can leave FFmpeg on your own computer, run it on a VPS, or use a service that accepts the prepared file and YouTube credentials through its own workflow.
A local computer gives you direct access to your files and logs. It also means your power, broadband, operating-system updates and restart habits become part of the channel. This can work well for a small test or a channel that already has a machine running continuously.
A VPS can be accessed remotely and may suit someone comfortable with command-line administration. You remain responsible for uploading files, installing the required software, securing the stream key, supervising the process and dealing with the provider's billing and access controls. The guide to running a YouTube radio stream from a VPS in India covers the operational questions that sit around the FFmpeg command.
A managed workflow reduces some of that maintenance, but it gives you less control over the command and may support only particular destinations or file types. Whichever route you choose, keep a copy of the source files, document the working settings and test a restart. The right arrangement is the one you can inspect and recover when the channel is quiet, not merely the one that starts most easily.
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 loop a song in FFmpeg?
For a local file, use the installed build's documented input-loop option, commonly -stream_loop -1, before the matching -i. Add -re before the local input when it must be read at real-time pace. Validate the syntax with ffmpeg -h full, then test the loop boundary with the actual file.
How do I stream looping music to YouTube Live?
You need an audio source, continuous video, an encoder configuration and the stream URL and key from YouTube Live Control Room. FFmpeg can map the intended audio and video streams, encode them and write the output to the supplied RTMP or RTMPS endpoint. Test privately or unlisted first and watch YouTube's health indicators.
Why does my FFmpeg live stream stop when the song ends?
The loop may not be applying to the input you intended, or a separate video input may be reaching its end first. Check the position of -stream_loop, use explicit -map options where needed, and test the durations and timestamps of both inputs. Separate audio and video files can require more specific synchronisation or filtering than the schematic examples show.
How do I keep a YouTube lofi stream running overnight?
Use a real-time-paced local input, repeat the media, provide video for the entire programme and monitor the YouTube feed rather than only the FFmpeg process. Also plan for power, upload, restarts, source-file errors and copyright questions. No command alone guarantees uninterrupted playback, so test the complete operating arrangement before relying on it.