A looping ASMR video can be sent to YouTube Live with FFmpeg by reading the file in real time and requesting an indefinite loop. The starting point is -stream_loop -1 with -re before the input, followed by output settings that match your resolution, frame rate, codec and available upload capacity.
That command is not a guarantee of an uninterrupted broadcast. You should test the complete path with representative sound and motion, then watch YouTube's stream health and messages while the event is running.
Understand the loop and real-time options
FFmpeg normally processes a file as quickly as the computer allows. That is useful for converting a video, but it is not suitable for sending a prerecorded file to a live ingest point. The -re option tells FFmpeg to read the input at its native rate, which keeps packets paced more like a live source. FFmpeg documents this as equivalent to -readrate 1 and notes that it is useful when output timing matters, including live streaming. See the FFmpeg documentation for input options.
The -stream_loop -1 option asks FFmpeg to repeat the input indefinitely. The -1 value means there is no requested end to the loop. These are input options, so put them before the relevant -i, not after the output settings.
For a single MP4 containing both the picture and the intended audio, the basic shape is:
ffmpeg -re -stream_loop -1 -i "/path/to/asmr.mp4" [output options] "YOUR_RTMPS_DESTINATION"
The loop only repeats what is in the file. It does not repair an abrupt edit at the end, smooth a sudden audio change, or make separate inputs share a duration automatically. If you provide video and audio as separate files, you must design and test their loop behaviour together rather than assuming that looping one input loops the other.
There is also a difference between a process continuing to read a file and a live event continuing without interruption. FFmpeg may stop because of an input error, an encoder problem, a network failure or a local system issue. YouTube may also report an ingest or event problem. Treat the loop as one part of the arrangement, not as a complete operating plan.
Prepare the ASMR source file
Start with the material you actually intend to repeat. A quiet rain scene, a keyboard recording and a whispering session place different demands on the source even when they have the same resolution. Look at the loudest sections, the quietest sections and the transition where the file returns from its end to its beginning.
Listen to the boundary several times with headphones. If the final sound cuts off while a room tone is still present at the beginning, the repeat can be obvious. The same applies to picture: a camera movement that stops suddenly and restarts from a different position may look like a fault. FFmpeg can repeat the file, but it cannot infer how you want those two moments to join. If necessary, edit the source into a longer or more deliberate loop before encoding it for the live stream.
Keep the file's aspect ratio and intended frame rate in mind. If the source is 16:9 at 30 frames per second, a matching output is usually easier to reason about than forcing it into a different shape. Check for black bars, stretched faces, an unexpected crop and a frame-rate conversion before you begin the live test.
Audio needs the same attention. YouTube's listed stereo settings include AAC at 44.1 kHz and 128 kbps. A clean recording with sensible headroom is more useful than trying to make a quiet ASMR track loud by clipping its peaks. Watch for hum, fan noise, clicks at loop boundaries and long sections where the level is so low that listeners may think the stream has stopped.
If the file is part of a larger relaxation station, plan the sequence before choosing FFmpeg. A single loop is simple, while a playlist of separate recordings requires a different input and process design. The practical considerations are similar to those in this guide to starting a 24/7 lofi radio station, particularly around source preparation and checking the result overnight.
Set up YouTube Live ingestion
Create or open the live event in YouTube Live Control Room and obtain the assigned ingestion details. You need the ingestion address and the stream name or stream key. YouTube's Live Streaming API describes these as separate properties, while encoder interfaces may ask you to combine them into one destination string.
Prefer RTMPS when it is available for the event. YouTube lists RTMP and RTMPS as supported protocols and recommends RTMPS in its encoder guidance. The exact destination is assigned to your event, so do not copy an address from an unrelated tutorial and assume it will work for your channel.
You can review the API's description of ingestion details in the YouTube Live Streams documentation. YouTube's encoder settings and live streaming guidance should be your reference for the current platform requirements and recommendations.
Treat the stream key like a password. Do not paste it into a public article, a support screenshot, a shared command history or an unprotected script. If it is exposed, replace or reset it in YouTube before starting the event. A command that contains the key can also appear in shell history or process listings, depending on how you launch it.
Before sending the full stream, check that the selected event is the one you intend to use. Confirm its title, visibility, scheduled details and audience settings in YouTube. A technically correct FFmpeg command can still send the broadcast to the wrong event if the ingestion details were copied from another setup.
Build a starting FFmpeg configuration
The following is an illustrative starting point for 1080p at 30 frames per second, H.264 video, SDR and stereo AAC audio. The video bitrate uses YouTube's listed recommended H.264 value for that output choice.
ffmpeg -re -stream_loop -1 -i "/path/to/asmr.mp4" \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 14M -maxrate 14M -bufsize 28M \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://YOUR_INGEST_ADDRESS/YOUR_STREAM_NAME"
Replace the file path and destination with your own values. Do not put a real stream key in a public command or commit it to a public repository. The example assumes that the MP4 already contains the desired audio and video.
Several parts of this command have distinct jobs. -c:v libx264 selects the H.264 encoder when that encoder is available in your FFmpeg build. -preset veryfast trades some compression efficiency for less processing work; it is not a YouTube requirement. -pix_fmt yuv420p is a common compatibility choice for SDR video.
The -r 30 output frame rate matches the example. -g 60 represents a two-second GOP at 30 frames per second. YouTube expresses its keyframe guidance in seconds, so the arithmetic is 30 multiplied by 2. At 60 frames per second, the corresponding value would be 120 frames. The exact handling of private GOP controls depends on the selected encoder.
-keyint_min 60 and -sc_threshold 0 are illustrative libx264 controls intended to make keyframe spacing more regular in this example. They are not requirements stated by YouTube. If your installed encoder rejects them or behaves differently, check the options for that build with ffmpeg -h encoder=libx264. The important platform guidance is the keyframe interval: use two seconds where possible and do not exceed four seconds.
The sample uses constant-rate-style limits through -b:v, -maxrate and -bufsize, but you should verify the actual encoder output and YouTube's feedback. YouTube recommends CBR for its listed encoder settings. A command that starts without an error is not proof that the resulting stream matches every setting you intended.
The final -f flv and RTMPS destination follow a common FFmpeg arrangement for this type of output. Check the syntax against your installed FFmpeg build and the ingestion details supplied for the event. If the destination format or protocol is rejected, read the error carefully instead of changing several unrelated options at once.
Match codec and bitrate to your output choice
There is no special universal bitrate for ASMR. Choose the resolution and frame rate first, then use the corresponding platform guidance while checking whether your upload connection can sustain it. The table below reproduces YouTube's listed recommended video bitrates, checked on 3 October 2026. They are configuration recommendations, not measurements of ASMR quality or guarantees about a particular source.
| Ingest resolution and frame rate | H.264 recommended bitrate | AV1 or H.265 recommended bitrate |
|---|---|---|
| 2160p at 60 fps | 50 Mbps | 35 Mbps |
| 2160p at 30 fps | 42 Mbps | 30 Mbps |
| 1440p at 60 fps | 34 Mbps | 24 Mbps |
| 1440p at 30 fps | 21 Mbps | 15 Mbps |
| 1080p at 60 fps | 17 Mbps | 12 Mbps |
| 1080p at 30 fps | 14 Mbps | 10 Mbps |
| 720p at 60 fps | 8 Mbps | 6 Mbps |
| 720p at 30 fps | 6 Mbps | 6 Mbps |
| 480p at 30 fps | 4 Mbps | 3 Mbps |
| 360p at 30 fps | 3 Mbps | 3 Mbps |
For example, a 720p30 H.264 stream would use the 6 Mbps recommended video bitrate from the table, while a 1080p60 H.264 stream would use 17 Mbps. A 1080p30 H.264 stream should use 14 Mbps if your connection can reliably support YouTube's recommendation. Do not carry the 14 Mbps value into a different resolution or frame rate without checking the relevant row.
YouTube also lists minimum bitrates separately. For example, its listed H.264 minimum is 5 Mbps for 1080p30 and 3 Mbps for 720p30, while the recommended values are higher. A minimum is not the same as a target. Prefer the recommended figure when your upload is suitable, and test the connection with room for normal variation and other traffic.
H.264 is often the straightforward starting choice because it is widely supported by FFmpeg builds and hardware. YouTube also lists H.265 and AV1. Those codecs may be useful when your encoder and playback workflow support them, but the command, available encoder name and processing load can differ. Do not change codec solely because its table value is lower. Confirm that your FFmpeg build can encode it reliably and that your chosen hardware can sustain the workload.
YouTube's listed audio guidance includes AAC or MP3, with stereo AAC at 44.1 kHz and 128 kbps. It also lists 5.1 audio for AAC over RTMP or RTMPS at 48 kHz and 384 kbps. For a typical stereo ASMR channel, the stereo AAC settings are the simpler starting point. Use surround only when the source, production and listener experience justify the additional testing.
For SDR, YouTube lists Rec. 709 and 8-bit in its encoder settings. If your source uses a different colour workflow, check the conversion rather than assuming that a bitrate change will correct washed-out or over-saturated pictures. If the main problem is softness or blur, the guidance in why a fireplace stream can look blurry is relevant to diagnosing source scaling, encoding and delivery rather than simply increasing every number.
Test representative sound and motion
Run a private or otherwise controlled test before relying on the setup. Use a section with the same kind of movement and sound that viewers will receive during the real event. A still image with a silent track does not test a moving waterfall, whispered speech, crackling fire or delicate stereo ambience.
Check the source locally first. Confirm the picture fills the intended frame without distortion, the audio is present on both channels when it should be, the loudest passages do not clip and the loop boundary is acceptable. Then test the complete FFmpeg-to-YouTube path, because local playback does not reveal ingest errors, network instability or platform-side warnings.
During the test, look for:
- a correct aspect ratio and frame rate
- visible motion rather than a frozen frame
- audio that remains present through the loop boundary
- unexpected silence, clipping, hum or channel imbalance
- dropped or corrupted frames
- a delay or mismatch between the picture and sound
- YouTube stream-health warnings
- a bitrate that your upload connection can sustain
Let the test run through more than one repeat of the source. The first pass can look correct while the second exposes an audio reset, a timestamp issue or a visible jump at the boundary. If the source file is long, test the exact beginning and end as well as a representative middle section.
If your upload is shared with other people or devices, test under realistic conditions. A speed test taken when nothing else is using the connection does not represent an evening when cloud backups, phones and televisions are active. If the recommended bitrate is not stable, choose a smaller output that you can test consistently rather than treating the recommendation as a promise that your connection can carry it.
A 24/7 stream also has an operating decision behind it. Running FFmpeg on your own computer leaves you responsible for power, sleep settings, updates, network interruptions and process recovery. A managed approach such as StreamNeo removes the need to keep your computer switched on for a YouTube-only file-based broadcast, but it does not remove the need to prepare the source, protect the stream key or check YouTube's event status.
Monitor stream health and messages
Once the event is live, keep YouTube Live Control Room available and watch the stream-health feedback. YouTube advises testing representative content and monitoring stream health and messages. Use those messages as evidence about what is happening rather than guessing from the fact that FFmpeg is still printing output.
A healthy-looking local process does not prove that viewers are receiving the intended stream. Watch for dropped frames, unstable ingest, a frozen picture, missing audio, encoder warnings and changes at the loop boundary. If YouTube reports a problem, note when it occurred and compare it with the FFmpeg terminal output and your network activity.
Monitor the machine as well. Check processor load, memory pressure, disk access, temperature where relevant and the network interface. A faster preset may reduce processing load at the cost of compression efficiency. A higher resolution may increase upload demand without improving a source that was already soft. Change one factor at a time so that your test results remain useful.
Do not assume that -stream_loop -1 provides automatic reconnection or process supervision. The material reviewed for this setup does not establish automatic recovery, a particular uptime percentage or a universal event duration policy. If the process exits, someone or something still needs to identify the failure and decide whether to restart it.
For a more complete operating plan, read how to create an always-on YouTube channel with prerecorded videos. You should also review YouTube's current rules and event guidance directly, especially if your channel depends on prerecorded material. A looped file is a technical arrangement, not a statement that every use is suitable for every channel or policy situation.
Choose a repeatable operating method
FFmpeg is a good fit when you want direct control over the input, codec, bitrate and destination. It is also useful for a controlled test, because each option is visible and the terminal output can help you diagnose what the process is doing. The trade-off is that you must maintain the command, protect credentials, keep the computer awake and handle failures.
If you are running a local process, save the command without the secret key and provide the key through a safer method appropriate to your operating system. Document the source path, output choice, frame rate, bitrate and the date on which you checked YouTube's recommendations. That makes it easier to reproduce a working test without copying an old command blindly.
If the stream is for a business, devotional channel or ambient station that needs attention outside your normal working hours, decide who will see a failure and what they can do about it. A written check routine is more useful than a claim that one configuration will run forever. Include the event details, the source file, the expected output and the first checks to make when YouTube reports an issue.
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 make an FFmpeg stream permanent?
It requests indefinite repetition of the input, but it does not guarantee that the FFmpeg process, network connection or YouTube event will continue without interruption. You still need to test the complete path and monitor the event.
Where should -re and -stream_loop -1 go?
Put them before the relevant input, as in ffmpeg -re -stream_loop -1 -i "/path/to/asmr.mp4". They control how FFmpeg reads that input, while codec, bitrate and output options describe what is sent afterwards.
What bitrate should I use for 1080p ASMR?
For H.264 at 1080p30, YouTube's listed recommended video bitrate is 14 Mbps, checked on 3 October 2026. Your connection must sustain the selected output, so test it with representative audio and motion rather than treating the figure as a guarantee.
Can I loop separate video and audio files with the same command?
Not safely by assumption. The example uses one MP4 containing the intended audio and video; separate inputs need coordinated loop and duration handling, followed by a test of their timestamps and repeat boundaries.