To loop a finished guided body scan meditation indefinitely with FFmpeg, put -stream_loop -1 before the file’s -i option, then use -re to pace that file for live output. Configure the output for YouTube’s current encoder guidance and send it to the stream URL and key shown in YouTube Studio.
The option order matters: -stream_loop applies to an input, not to the output that follows it. The example below is a starting point for one video file containing both picture and sound; it is not a guarantee of a stable stream or a substitute for testing your particular file and connection.
Prepare the finished guided body scan file
Start with the finished media rather than trying to make FFmpeg repair the meditation as it streams. Listen to the whole recording, check that the narration and any background sound are present, and look at the opening and ending. A clipped first word, an abrupt music cut or a long silent tail will recur every time the file reaches its end. Fix those points in an editor and export a file you are content to repeat.
Check what is actually inside the file before writing the command. FFmpeg’s companion tool, ffprobe, can report its video and audio streams, duration, dimensions, frame rate and audio format. For example, run ffprobe -hide_banner -i "body-scan.mp4" and read the stream lines. This can help explain why audio is missing: a picture-only file has no audio track for FFmpeg to send, and a separate narration file will not be looped merely because the video input is.
For the simplest workflow, use one file with the visual track and guided audio together. If the meditation’s voice, music and visuals come from separate inputs, plan the mapping and looping of each input separately. Every finite input that must continue needs its own loop treatment, correctly placed before that input’s -i; do not assume the video loop keeps a separate audio source alive. If you are building from narration WAV files, the related guide on creating a YouTube Live stream from podcast WAV files may help with the audio side of the workflow.
Make sure you have the rights needed for the voice recording, background music, ambient sounds and visuals. Permission for one element does not automatically cover the rest. Repetition also does not establish eligibility for monetisation: YouTube’s channel monetisation policies say content should offer creative, educational or other value, and materially repetitive formats may be assessed under the platform’s inauthentic-content rules. Check the current policy and your own rights before relying on a long-running loop.
Put the loop option before its input
-stream_loop is an FFmpeg input option. Give it the value -1 for infinite looping, and put it before the -i belonging to the file it should repeat. With a single file, the essential shape is:
ffmpeg -re -stream_loop -1 -i "body-scan.mp4" [encoding options] -f flv "RTMP(S) destination"
The placement is deliberate. FFmpeg reads options in relation to inputs and outputs; an option appearing after an input will not retroactively change how that input is read. Keep -stream_loop -1 before -i "body-scan.mp4". Do not substitute FFplay’s -loop option: FFplay is a playback application, while this command uses FFmpeg to encode and send a feed.
When there are multiple inputs, repeat the option ahead of each file that needs to loop. For instance, if video and narration are separate finite files, put a -stream_loop -1 before the video’s -i and another before the audio’s -i, then map the intended streams. Check the resulting playback rather than assuming the two durations line up. If a sound file is shorter than the video, or vice versa, the boundary may be audible or visible even though both inputs repeat.
This option repeats a file; it does not inspect whether the join sounds natural. A body scan might have an intentionally quiet ending that works well before the opening, or it might end with a spoken sign-off that sounds odd when followed immediately by the introduction. Decide whether that transition suits the listener. If not, edit the file or use a more considered sequence rather than expecting the loop flag to add a fade or crossfade.
Pace file input with -re
A file can be read faster than real time unless it is paced. For this file-to-live workflow, -re tells FFmpeg to read the input at its native rate, so a recording that lasts an hour takes about an hour to feed through before it reaches its end and repeats. Place -re before the file input as shown in the command. It is useful here because the source is a completed file, not a live capture device.
Do not carry this advice over blindly to a live camera, microphone or other real-time source. FFmpeg’s documentation cautions against using low read rates on actual live inputs, where the source already arrives in real time. The workflow here is specifically a file being used as a live output source. If you change the input type, revisit the input pacing choices rather than keeping -re by habit.
If the command appears to run slowly, that is expected for paced output: it is feeding frames and audio as the live event needs them rather than rapidly processing the entire file. Watch the elapsed time and FFmpeg’s output timestamps while testing. If the picture and sound do not progress together, check the source streams, timestamps and chosen mappings before adding filters or changing the output frame rate.
Match the output to YouTube’s encoder guidance
YouTube’s encoder settings and bitrate guidance describes supported video codecs and audio formats, recommends constant bitrate (CBR), and recommends a two-second keyframe interval, with an interval no longer than four seconds. It also gives bitrate recommendations by resolution, frame rate and codec. Choose from that table for the format you intend to send; a bitrate copied from a different resolution or frame rate is not a universal setting.
Here is an illustrative command shape for one file with video and audio, an H.264 video output at 30 fps, AAC audio and an RTMP-compatible FLV output:
ffmpeg -re -stream_loop -1 -i "body-scan.mp4" \
-c:v libx264 -preset veryfast -tune stillimage \
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-b:v 4500k -maxrate 4500k -bufsize 9000k \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
Treat the values as an example to adapt, not tested or universal recommendations. In particular, the video bitrate shown does not stand in for YouTube’s current table. For context, YouTube lists 5 Mbps as a recommended H.264 bitrate at 1080p30, while its recommendations vary with the selected format. The example’s -g 60 at 30 fps sets a 60-frame group of pictures, corresponding to two seconds; if you choose a different frame rate, calculate the keyframe cadence to match the interval you intend. YouTube recommends 128 kbps for stereo audio and a 44.1 kHz sample rate in the cited encoder guidance.
The command assumes a video file with audio, and does not scale an input or create a visual track for audio-only material. A variable-frame-rate source, unusual dimensions, separate tracks or a file without sound may need a different command. Use ffprobe, check the installed FFmpeg build and test the actual output. For a practical discussion of choosing video dimensions for a continuous channel, see what resolution to use for a 24/7 fireplace stream; the right choice still depends on your own source and upload connection.
Send the feed to YouTube Studio’s URL and key
In YouTube Studio’s Live Control Room, create or select the live event and copy the server URL and stream key supplied for that stream. In the command’s final argument, use the destination format YouTube gives you, with the key appended in the way its current instructions specify. The example uses an RTMPS-style destination and an FLV container, but confirm the ingestion method shown in Studio rather than mixing settings from a different workflow.
Treat the stream key like a password. Do not paste a real key into a public tutorial, shared screenshot, issue tracker or script repository. Shell history and logs can also preserve command text, so consider how you will store and invoke the command on your machine. If someone else can access a script or log containing the key, they may be able to send a feed to your event. If a key is exposed, use Studio’s controls to manage it and check the current YouTube instructions.
YouTube’s live encoder setup guide explains the Studio workflow and notes that the encoder feed is what creates the watch page for the stream. Stopping the encoder feed ends the stream. This makes the relationship between your FFmpeg process and the event important: restarting a local command is not the same thing as confirming the event is still accepting and displaying the feed.
If you want a local computer to run FFmpeg, it must remain on and connected for the process to continue. If that is the part of the workflow that has failed you overnight, StreamNeo removes the need to leave your own computer running by letting you upload the finished video, provide the YouTube stream key and have the broadcast run from the cloud. The product is for YouTube streams, so it is not a general-purpose destination for other platforms.
Test the whole path before launch
Do not treat successful command startup as a complete test. You need to establish that the file is being read, FFmpeg is encoding it, the feed reaches YouTube, and the live picture and sound are acceptable at the other end. YouTube Help says to test before starting a live stream, including audio and video movement similar to what the stream will contain. Use a private or otherwise appropriate test arrangement and confirm the current controls in Studio before exposing the event to viewers.
Check the start, a representative passage and the loop boundary. Listen for narration that has been cut off, missing ambience or a level change at the join. Watch for a frozen picture, an unexpected black frame, an aspect ratio problem or a visible jump. A still image over continuous guided audio may be the intended format, but confirm that the picture track remains live and that the result matches your plan.
Test on the same computer, connection, file and output settings you expect to use. A speed test can inform whether the upload connection has headroom for the chosen bitrate, but it does not prove that a long session will behave identically. If you change resolution, frame rate, audio or the source file after testing, test again. For creators comparing approaches to a local video folder and a continuous channel, running a 24/7 YouTube stream with OBS and a local video folder offers a different workflow to consider.
Monitor health and troubleshoot loop boundaries
During the broadcast, watch both FFmpeg’s logs and YouTube Studio’s stream-health display. If Studio reports a problem, compare its indication with FFmpeg’s output and the actual viewer experience. A running process only tells you that a process has not exited; it does not prove that the platform is receiving a usable picture and sound. Likewise, a healthy-looking feed at one moment does not guarantee that the source will loop cleanly later.
When the video loops but audio stops, first determine whether both streams are in the same input file. If the voice or music comes from a separate file, check that the audio input also has its own -stream_loop -1 before its -i, and that your mapping selects that audio stream. If the audio file is shorter, longer or differently edited than the video, the join may drift in a way that needs editing or an explicitly designed output. Do not assume the video’s loop option applies to another input.
For a visible pause or jump at the boundary, inspect the actual end and beginning frames and their timestamps. A file can repeat correctly while still having a perceptible discontinuity. Consider trimming or re-exporting the source to make the transition suitable, then repeat the end-to-end test. If FFmpeg exits instead of continuing, inspect the error message and check whether the file, destination and connection remain available; a retry or recovery option can help in some cases but is not a promise that YouTube, the network and the encoder will reconnect successfully.
Plan the session length deliberately. YouTube says streams shorter than 12 hours are automatically archived, but that does not mean an indefinite loop will be preserved as one uninterrupted archive. If a continuous meditation channel matters more than a single event archive, decide how you will handle event duration and any intentional restart, then check YouTube’s current behaviour. For other unattended-stream concerns, the guide to monitoring a 24/7 nature stream remotely covers monitoring considerations that also apply to a long-running broadcast.
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 -stream_loop -1 go before or after -i?
Put it before the input it should repeat, for example -stream_loop -1 -i "body-scan.mp4". It is an input option; putting it after that input does not apply it to the file you have already opened.
Does looping the video also loop a separate audio file?
No. Each separate finite input that must continue needs its own loop option before its own -i, and you must map the audio stream you want in the output. Test the sound at the join, especially if the files have different durations or edits.
Why use -re with a finished meditation file?
It paces a file input at its native rate for live output, rather than allowing FFmpeg to read the file as quickly as it can encode it. This advice is for a file source, not a live capture input that already arrives in real time.
Does the example command guarantee a stable or uninterrupted stream?
No. It is an illustrative starting point, and the source file, connection, encoder, destination settings and YouTube event all affect the result. Test the full path and keep an eye on FFmpeg and YouTube stream health.