Skip to content
streamneo.
Setup Guides14 min read

How to Set Up YouTube RTMP Streaming with FFmpeg for a Video Loop

Set up a YouTube video loop with FFmpeg: find the right stream endpoint, protect your key, test the preview and troubleshoot playback.

sn.
StreamNeoPublished 4 October 2026
Worth sharing?

You can stream a local video repeatedly to YouTube with FFmpeg by sending the file to the Stream URL shown in YouTube Live Control Room. The reliable workflow is to confirm live access, copy the current URL and key, pace the file in real time, and wait for YouTube's preview before going live.

This guide uses command templates rather than a command claimed to work unchanged on every computer. Your FFmpeg build, input file, network, and the destination displayed by YouTube all affect the result.

Confirm live-stream access and create an encoder stream

YouTube live streaming is not available to every channel immediately. YouTube says your channel must be verified and must not have had live-streaming restrictions in the previous 90 days. Check the current requirements in YouTube's encoder streaming guide rather than relying on an old tutorial.

In YouTube Studio, open Create, then Go live. Choose the encoder option if you are sending video from FFmpeg. You can start an immediate stream or create and schedule one from the Manage area. The choice changes the final steps: an immediate stream may become live after YouTube receives the feed, while a scheduled stream normally requires you to start the encoder first and then confirm the event in Live Control Room.

Give the stream a useful title, visibility, and description before testing. For a devotional channel, for example, the event details should make clear whether the video is a loop, a live presentation, or a scheduled programme. Check that you have the rights to the video, music, images, and any spoken material. YouTube's technical approval of a feed does not decide whether your content is authorised for use.

Do not start by guessing the ingest address. Create or open the specific encoder stream first. The URL and key belong together, and using a key from another event can leave FFmpeg apparently connected to the wrong destination.

If your actual aim is to keep a channel running all day, first understand the distinction between a looped file and a YouTube live event in what “loop” really means on YouTube. A loop in FFmpeg repeats the input locally; it does not make YouTube replay an ordinary uploaded video as a live broadcast.

Copy the current Stream URL and Stream key

In the stream settings, locate Stream URL and Stream key. Copy both values directly from YouTube Live Control Room. YouTube describes the stream key as the credential used by the encoder to send the feed, so treat it like a password rather than like public channel information.

Keep the URL and key separate while you prepare the command. The URL may contain the server and application path, while the key identifies your stream. Do not replace the displayed path with a value found in a forum post, and do not assume that every YouTube event uses the same complete destination string.

A safe working method is to paste the values into a local password manager or a file that is not uploaded, committed to source control, or shared in a screenshot. In the command examples below, STREAM_URL and STREAM_KEY are placeholders, not values to copy literally.

If the key appears in a terminal command, remember that command history may retain it. On a shared computer, another user may be able to read that history. You can reduce exposure by using an environment variable or another local secret-handling method suited to your operating system, but check how your shell records commands before choosing that approach.

If you accidentally publish the key, reset it in YouTube Live Control Room and replace the old value in FFmpeg. A key that has been exposed should not be considered private merely because the stream is currently offline. The YouTube guide to managing live stream settings is the appropriate place to confirm the current reset workflow.

Choose RTMP or RTMPS using the displayed destination

RTMP and RTMPS describe the transport used between FFmpeg and YouTube. RTMPS adds TLS encryption to the connection, so YouTube recommends it when your encoder supports the displayed endpoint and protocol.

Use the destination YouTube gives you rather than changing only the first few letters of the address. The default view may show an ordinary RTMP URL. YouTube's RTMPS instructions explain how to reveal the secure endpoint, including the destination available from the lock icon in Live Control Room. See the current YouTube RTMPS documentation before editing an endpoint by hand.

The difference matters in the command. An RTMP destination commonly begins with rtmp://; an encrypted destination begins with rtmps://. Your local FFmpeg build must support the protocol, and the server must accept the exact URL that YouTube displays. A connection error is not proof that the stream key is wrong.

For example, the final argument might look like one of these templates:

rtmp://SERVER/APPLICATION/STREAM_KEY
rtmps://SERVER/APPLICATION/STREAM_KEY

These are shapes only. Do not insert a guessed server name or expose a real key in a script that others can read. If the secure connection produces a TLS or SSL error, first check that you copied the RTMPS endpoint from YouTube and that your installed FFmpeg has the required protocol support. YouTube notes that port 443 may help in some RTMPS connection situations, but you should use the port and URL provided for your stream rather than adding one indiscriminately.

Prepare the local video and loop input in FFmpeg

Before building a publishing command, inspect the file. Confirm that it opens normally, has the expected duration, and contains the audio and video streams you think it contains. A video without audio needs different handling from a file with an AAC-compatible audio track. Do not assume that a silent file will behave identically to a file with a silent audio stream.

FFmpeg reads a file as quickly as it can unless you tell it to follow real time. For a file being used as a live source, place -re before the input option. Without real-time pacing, FFmpeg may finish reading a short file quickly, send data too fast, or behave unlike a live encoder even though the output command looks plausible.

The input loop is requested with -stream_loop -1. The option belongs with the input side of the command. The -1 value asks FFmpeg to repeat the input indefinitely. Because FFmpeg builds vary, check the help output for the version installed on your computer and confirm that the option is supported. The FFmpeg documentation explains the general command structure and the importance of option placement.

A basic input pattern is:

ffmpeg -re -stream_loop -1 -i "loop.mp4" ...

Replace loop.mp4 with the path to your file. If the path contains spaces, keep the quotation marks. On Windows, use a path format accepted by the shell you are using. On macOS or Linux, check capitalisation carefully because file names may be case-sensitive.

If the file ends unexpectedly, test it without streaming and note FFmpeg's final messages. A damaged input, an unsupported codec, or a missing stream can be mistaken for a YouTube connection problem. It is easier to solve those issues before adding the network destination.

For a practical distinction between a local repeating file and other always-on approaches, compare this workflow with streaming a local video file to YouTube Live with FFmpeg. If a computer must remain switched on for the whole broadcast, also consider whether your power, internet connection, and restart plan are suitable for that responsibility.

Build the publishing command with placeholders

Once the input works, add the video and audio encoders, the output format, and the YouTube destination. This illustrative command follows the structure documented by FFmpeg and the broad encoder format described by YouTube, but it is untested and is not a guarantee for every local build, file, resolution, or connection:

ffmpeg -re -stream_loop -1 -i "loop.mp4" \
  -c:v libx264 -preset veryfast \
  -b:v 2500k -maxrate 2500k -bufsize 5000k \
  -pix_fmt yuv420p -g 60 \
  -c:a aac -b:a 128k -ar 44100 \
  -f flv "RTMPS_DESTINATION"

In this template, replace loop.mp4 with your file and replace RTMPS_DESTINATION with the complete URL and key shown by YouTube. Do not type the word RTMPS_DESTINATION into a real command. If YouTube shows an RTMP destination and your build does not support the secure version, use the displayed RTMP value instead.

The command has two different kinds of options. -re and -stream_loop -1 affect how FFmpeg reads the input, so they appear before -i. The codec, bitrate, pixel format, GOP, audio settings, muxer, and destination describe the outgoing stream. Keeping this separation clear helps when you add a second input or change the output.

-c:v libx264 asks FFmpeg to encode video as H.264, while -c:a aac asks for AAC audio. -f flv selects the output muxer used in the RTMP command pattern. The exact encoder names available depend on the FFmpeg build. If libx264 or AAC is unavailable, the command will fail locally before YouTube can show a preview.

Do not claim that this command has been tested simply because FFmpeg accepts its syntax. Test it on the computer and input you will actually use. If the source has no audio, remove or redesign the audio part intentionally rather than forcing a stream mapping that does not exist. If it has multiple audio or video streams, inspect and map the desired ones explicitly.

To stop the process, use the normal interrupt for your terminal and then handle the YouTube event in Live Control Room. Ending the encoder process stops the outgoing feed; it does not necessarily replace the separate action of ending a scheduled live event.

Choose encoding settings supported by YouTube

The example values are starting points, not universal recommendations. YouTube's current live encoder guidance describes H.264 video, AAC audio, CBR bitrate mode, and a two-second keyframe frequency, with the keyframe interval not exceeding four seconds. Check the current YouTube encoder settings, bitrates, and resolutions for the resolution and frame rate you intend to send.

The sample -g 60 means a GOP of 60 frames. It represents two seconds only when the output is 30 frames per second. If your output frame rate differs, calculate the frame count for the intended interval instead of copying 60 automatically. A GOP setting is a frame count, not a duration.

The sample 2500k video bitrate and 5000k buffer are illustrative. They are not a YouTube-prescribed value for every format. Higher resolution and frame rate usually require more data, while a connection with limited upload capacity may need a lower output format. Your upload should have room for the chosen feed, and other devices sharing the connection can change what is practical.

If the source is already encoded suitably, you might consider stream copying to avoid re-encoding, but that is environment-specific. The source must be compatible with the destination's codec, frame rate, pixel format, audio, timing, and container expectations. Re-encoding is slower and uses CPU, but it gives you more control over the outgoing format. Measure your computer's behaviour with the real file instead of assuming that a short test represents an overnight run.

Watch for the difference between a clean video file and a live-ready feed. A file can play correctly in a media player while still producing unsupported timestamps, an absent audio stream, or an unsuitable frame rate in a live command. Checking the file's streams and reading FFmpeg's warnings is part of the setup, not an optional extra.

If the stream appears soft despite a high bitrate, the cause may be source resolution, scaling, motion, encoder settings, or YouTube processing rather than bitrate alone. The troubleshooting guide on why a YouTube live stream can look blurry at high bitrate covers that distinction without treating bitrate as a guarantee of picture quality.

Start the feed and check the Live Control Room preview

Open the relevant YouTube event before launching FFmpeg. Then start the command and watch its terminal output. You are looking for evidence that FFmpeg opened the file, encoded frames, encoded audio where expected, and continued sending data without repeated errors.

For a scheduled stream, YouTube recommends starting the encoder and waiting for the Live Control Room preview. Inspect the picture, audio, stream health, title, and event details. Only after the preview is acceptable should you use Go live for the scheduled event. A preview lets you catch a wrong file, missing audio, wrong destination, or unsuitable quality before viewers see it.

Test with the same type of movement and audio that the real loop contains. A mostly still devotional image may behave differently from a video with moving text, while a local news loop may contain fine ticker text that exposes scaling or bitrate problems. Listen for silence, clipping, repeated gaps, or audio that falls out of sync after the file loops.

Keep the terminal and Live Control Room visible during the first test. FFmpeg can report a local encoding issue while YouTube reports a separate ingest or stream-health issue. These are related but not identical. A process that is still running does not prove that YouTube is receiving a usable feed.

If you need a genuine 24-hour channel but cannot keep a personal computer running, uploading the file once to a service that runs the YouTube broadcast from the cloud can remove the need to leave your machine switched on; StreamNeo is designed for that specific file-to-YouTube workflow, with automatic monitoring and restart when a feed drops. It remains YouTube-only, and you should still prepare the video, rights, title, and channel settings yourself.

YouTube says streams shorter than 12 hours are automatically archived. Do not treat that behaviour as a promise about every longer event or as a substitute for keeping your own source file. Save the original video and any project files separately.

Troubleshoot connection and playback issues

There is no preview. Confirm that the FFmpeg process is still running and producing output. Recheck that the Stream URL and Stream key came from the same YouTube event, then check whether you used the RTMP or RTMPS destination displayed for that event. A placeholder, copied line break, or incomplete URL can prevent ingest.

The terminal reports a connection or protocol error. Check the protocol prefix and confirm that your FFmpeg build supports the selected transport. If you selected RTMPS, copy the secure endpoint again from Live Control Room instead of guessing the path. For an SSL error, consult YouTube's RTMPS guidance, including its note about port 443, and follow the endpoint shown for your stream.

The stream connects but has no sound. Inspect the input file for an audio stream. If there is none, the command's AAC output section cannot create meaningful audio by itself. Decide whether to omit audio, add an intentional audio source, or prepare a new file with the required track. Do not assume that adding -c:a aac creates audio from silence.

The picture stops or the feed drops. Check the computer's CPU load, disk access, and network upload while FFmpeg is running. Lowering resolution, frame rate, or bitrate may help when the connection cannot sustain the chosen format, but make the change according to YouTube's current encoder table and your available capacity. Monitor YouTube's stream-health messages rather than judging the connection only by the terminal.

The loop does not restart cleanly. Test the file and the installed FFmpeg version separately. Verify support for -stream_loop -1, look for timestamp or decode warnings, and try a locally generated output before adding YouTube. Some source files have timing or codec characteristics that make a repeated input less reliable than a newly prepared, standardised file.

The key was exposed. Reset it immediately in Live Control Room and update the command. Remove the old key from scripts, screenshots, shared documents, and shell history where practical. A new key does not make a public copy of the old one private.

The preview looks wrong. Check the source dimensions, frame rate, aspect ratio, audio sample rate, and bitrate against YouTube's current guidance. If small text is unreadable, changing bitrate alone may not solve the problem. Start with a representative short test and change one major setting at a time so you can identify what helped.

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 stream a video loop on YouTube?

Create an encoder stream in YouTube Studio, copy its current Stream URL and Stream key, and use them in an FFmpeg command with -re and -stream_loop -1. Start the feed, inspect the Live Control Room preview, and only then make the scheduled event live where required.

How do I find my YouTube RTMP stream key?

Open YouTube Studio, choose Create, then Go live, and open the encoder stream settings. The Stream key is shown there alongside the Stream URL. Keep it private and reset it if it has been exposed.

Should I use RTMP or RTMPS with FFmpeg?

Use RTMPS when your FFmpeg build supports it and YouTube provides that endpoint, because it protects the feed in transit. Do not invent an RTMPS path by editing an RTMP address; copy the destination shown in Live Control Room.

Can FFmpeg guarantee an uninterrupted 24/7 stream?

No. A loop command only controls how FFmpeg reads the file. Power loss, network interruptions, local failures, unsupported input details, and YouTube event settings can still stop or affect the broadcast, so test the complete arrangement and plan how you will monitor it.

YOU’VE REACHED THE END

Keep the ideas coming.

More guides, useful tools and a little help for your next broadcast.

Back to the journal ↗
YOUR NEXT READ

A little more to explore.

More Setup Guides guides ↗ · All topics ↗