To loop a prerecorded video into YouTube Live from a Linode host, configure a YouTube encoder stream, then run FFmpeg with -stream_loop -1 before the file input’s -i. That option repeats the input; it does not keep a broadcast healthy by itself, so you must also check the ingest connection, playback, audio and process.
This guide covers the setup and the checks around it. The command is a template, not a tested Linode benchmark: choose settings that fit your source and host, and confirm the current requirements in YouTube’s documentation before going live.
Prepare the prerecorded source and Linux host
Start with a source file that you have the right to broadcast and that plays correctly from beginning to end. Check its picture, sound, aspect ratio and ending. A loop repeats the file’s last moments and then returns to the beginning; if the file has a long black tail, silence or an abrupt ending, viewers will encounter that on every pass. For music or devotional programming, listen across the transition rather than assuming the restart will be unobtrusive.
You need a Linux host that can read the full media file and run FFmpeg for the intended broadcast. A Linode Compute Instance is one possible cloud host; Linode’s streaming-server guide describes creating an instance for streaming work. Follow current account, firewall and system-maintenance guidance from the provider. The guide is not a performance test for this particular FFmpeg command, and it does not establish a suitable instance size for every source.
A computer you already control may be preferable if it has enough encoding capacity and a dependable internet connection. A cloud host can keep the job away from your home computer, but it still needs an available file, enough capacity for the selected encoding, and outbound network that can sustain the stream. Compare administration effort and current cost rather than assuming that either route is always cheaper or more reliable.
Install FFmpeg according to the current package instructions for the Linux distribution on your host. Package versions and enabled codecs vary. Before planning the live run, check that your build includes the video and audio encoders you intend to use and supports the output protocol. Copy the video to the host and confirm the exact path, including capitalisation. You can inspect media streams with FFmpeg’s probing tools; make sure the expected audio and video are present and that the duration and dimensions match your plan.
If the source is already encoded appropriately, FFmpeg may be able to copy streams rather than re-encode them, but compatibility and container requirements still matter. The example later uses H.264 and AAC encoding to make the intended output explicit. Encoding consumes host capacity; the actual load depends on the source, resolution, frame rate, codec settings and machine. Do not infer capacity from a provider’s generic streaming example.
If the file is large, confirm that the transfer completed rather than relying only on the copy process returning. Keep the source path stable while the stream runs. A renamed, moved or unreadable file can stop the process or prevent a restart from succeeding.
Create a YouTube Live encoder stream
In YouTube Live Control Room, create or select a stream configured for an encoder. YouTube requires a verified channel and says a channel must not have live-streaming restrictions in the previous 90 days; its help guidance also sets a minimum age of 16 for livestreaming. These eligibility conditions can change, so check YouTube’s current live-streaming access guidance before building a schedule around a broadcast.
Choose a title, visibility and other event details deliberately. If you are planning recurring programming, scheduling the event and preparing its title and description are separate tasks from running FFmpeg. For the related decisions about event timing and YouTube’s schedule, see the guide to scheduling a 24/7 YouTube live stream. Scheduling an event does not start the encoder process or prove that the feed is healthy.
YouTube’s encoder setup instructions explain how to connect an encoder to a live stream. The control room provides the ingest information for that stream. Keep the browser page available while you set up the command, but do not put credentials in a public document, tutorial, screenshot or support message.
Before committing to a long broadcast, test the chosen event and media with a short preview. Check how the source’s aspect ratio and audio level appear in the player, and confirm the live control room receives the feed. A file that looks fine in a local player can still have an unsuitable encoding, silent audio track or unexpected framing when converted for the live output.
Copy the ingest URL and protect the stream key
Copy the ingest URL and stream key from the selected encoder stream in Live Control Room. The URL identifies where the encoder sends the feed; the key authenticates the stream. Use RTMPS if it is offered and supported by your FFmpeg build. YouTube describes RTMPS as RTMP carried over TLS/SSL, which encrypts the connection to the ingest endpoint.
Treat the key like a password. Do not include a real key in a published command, shell history that other users can read, a shared chat, a screenshot or a repository. The command below uses a placeholder, not a working credential. For a real deployment, limit access to the account and host, restrict permissions on any configuration file, and avoid printing secrets in logs. If you believe a key has been exposed, replace or reset it through YouTube’s controls and update the encoder configuration.
The safest way to avoid accidental disclosure depends on how you administer the host. A protected configuration file or a carefully managed environment is preferable to repeatedly pasting a secret into a shared terminal or script. Check who can read those files and who can inspect process details on the system. Do not assume that putting a key in a command automatically makes it private.
Use the exact URL and key format shown in your control room. Some encoder interfaces display the ingest URL and key as separate values; the final destination is assembled according to that interface’s instructions. Avoid guessing at slashes or reusing a key from a different event. YouTube’s encoder connection documentation is the reference if the interface or workflow changes.
Put -stream_loop -1 before the input -i
In FFmpeg, -stream_loop -1 is an input option. Put it before the -i that names the file to repeat. For a single input, the relevant ordering is -stream_loop -1 -i /path/to/video.mp4. Placing the option after that input can apply it to the wrong part of the command or fail to produce the intended loop. The FFmpeg documentation describes the option and its input scope.
The -1 value requests an indefinite number of repeats. It means FFmpeg continues reading that input again after reaching its end while the process remains able to run. It does not reconnect a failed network session, restore a missing file, restart a crashed process or ensure YouTube is receiving a usable picture and sound. Those are separate operational concerns.
A schematic command for the full output follows. Replace every uppercase placeholder with values appropriate to your source and the values supplied by Live Control Room. Do not paste the example as-is, and do not expose your actual key when saving or sharing a modified copy.
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \\
-c:v libx264 -preset veryfast -b:v VIDEO_BITRATE \\
-maxrate VIDEO_BITRATE -bufsize VIDEO_BUFFER \\
-pix_fmt yuv420p -g KEYFRAME_INTERVAL \\
-c:a aac -b:a 128k -f flv 'RTMPS_INGEST_URL/STREAM_KEY'
This is a configuration template, not a tested command for a particular Linode size or FFmpeg build. The quotes are there to keep the destination together as one argument; adapt the final destination to the exact format from Live Control Room. Confirm the installed FFmpeg supports the selected encoder and RTMPS protocol before relying on this invocation.
The -re option reads the file at its native rate rather than processing it as quickly as the host can. The loop option still belongs before -i; the encoder and output options follow the input. If you add more inputs, take care to place input options before the -i they govern. Review the final command for typos without putting a real key into anything you plan to publish.
Configure FFmpeg output for YouTube Live
Set output to match both YouTube’s current recommendations and what the host can sustain. YouTube’s encoder guidance recommends constant bitrate (CBR) and a two-second keyframe interval, and says not to exceed four seconds. The -g option sets a GOP length in frames, so calculate it from the chosen frame rate rather than copying a frame count blindly. For example, the right value differs between a 25 fps and a 30 fps source if you are targeting the same interval. Check the current YouTube recommended encoder settings.
The placeholders VIDEO_BITRATE and VIDEO_BUFFER are not fixed recommendations. Choose a bitrate compatible with the resolution and frame rate you intend to send, the quality of the source, and the available outbound capacity. -b:v sets a target video bitrate, -maxrate limits the rate, and -bufsize governs the rate-control buffer. The example uses the same placeholder for target and maximum so that the intended CBR-style configuration is visible, but you must replace it with coherent values for your chosen profile.
The example transcodes video with libx264, requests a broadly compatible pixel format with yuv420p, and encodes audio as AAC. Those choices do not guarantee that a given build has the codec, that the source will look good at your selected rate or that the host can encode in real time. If your source has no audio, decide explicitly how to handle that rather than expecting an audio encoder to invent a useful track. Listen to a preview and check for clipping, silence or an unexpected channel layout.
YouTube accepts several ingest and encoding combinations; do not infer that every setting shown in an old guide remains the right one. The resolution and frame rate should make sense for the source. Upscaling a small file does not add detail, while selecting a demanding output can waste capacity and network headroom. The applicable limits and recommendations belong to YouTube’s current documentation, not to a guessed universal profile.
Network capacity is a separate constraint from CPU capacity. YouTube recommends keeping upload bandwidth headroom of 20% beyond the total stream bitrate. That margin helps account for variation; it is not a guarantee that a congested or unstable connection will hold. If you run FFmpeg on a cloud host, consider its effective outbound path and any account or network limits rather than measuring only the connection at your home. Avoid committing to a bitrate that leaves no room for normal fluctuation.
Verify playback and monitor the process
Start FFmpeg and watch its output for errors, frame progress and an advancing timestamp. A process that has not exited is not proof that YouTube is receiving valid media. In Live Control Room, wait for the preview and stream-health indicators, then inspect the actual picture and sound. Confirm that the expected title and event are selected, the image is correctly framed and the audio is audible at a sensible level.
Observe at least one transition back to the beginning if your test duration allows. A loop can restart with a visible flash, abrupt audio cut or gap caused by the source itself. Also check that the loop is genuinely repeating rather than reaching the end and exiting. A representative test should include the portions with the most motion or sound, because easy opening frames do not reveal every encoding problem.
Once live, keep an eye on the process, the control room’s health information, and host resource and network conditions. YouTube’s stream health guidance can help interpret warnings. If frames are dropping, the output is intermittent or audio and video drift apart, lower the encoding demand or investigate the specific resource or connection issue. Do not assume that adding -stream_loop -1 will repair any of those failures.
For an always-on channel, plan for what happens after a process or host failure. A shell session closing, a system update, a disk filling or a network interruption can all affect a long run. If you rely on automatic restart or a process supervisor, configure and test it separately; restarting FFmpeg does not necessarily resume the YouTube event in the state you expect. StreamNeo can remove the specific burden of keeping your own computer running by taking an uploaded file and running the YouTube broadcast with monitoring and automatic restarts, but it does not change YouTube’s eligibility or content rules.
Think through the end of the session too. YouTube says live streams under 12 hours are automatically archived; do not assume a single indefinitely long session will produce one complete archive. Plan separate sessions or verify the current archive behaviour for the duration you intend. When finished, end the event in Live Control Room and stop FFmpeg cleanly, then confirm that the event has ended rather than leaving an encoder process sending into an inactive session.
The content of the file matters independently of the mechanics. Repeating a video does not resolve rights questions for music, images, performances or other material. Review YouTube’s current policies and the rights you hold for each element. For a broader discussion of this risk, see whether YouTube can issue a copyright strike during a live stream. If your feed includes a continuous programme with chapter or episode changes, the article on displaying episode titles during a continuous podcast stream covers a different presentation problem; it does not replace testing the loop transition.
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 video on YouTube Live with FFmpeg?
Create an encoder stream in YouTube Live Control Room, then run FFmpeg with -stream_loop -1 before the file’s -i input option. Configure a compatible output and confirm that the live preview shows the expected picture and sound. The loop repeats the source; it does not guarantee the network, process or broadcast will remain healthy.
Can I put -stream_loop -1 after -i?
For the input you want to repeat, put -stream_loop -1 before its -i. FFmpeg options have scope, and this loop setting applies to an input rather than serving as an output option. Check the FFmpeg manual if you add more inputs or change the command structure.
Will an indefinitely looping stream be archived as one video?
Do not rely on that. YouTube’s cited help guidance says streams under 12 hours are automatically archived; it does not promise a complete archive for an indefinitely long stream. Check current guidance and plan how you will handle longer broadcasts.
Does Linode make the stream uninterrupted?
No. A cloud host can run FFmpeg without your personal computer staying on, but it still depends on the host, file, process, network and YouTube ingest behaving as expected. Test monitoring and recovery for your own setup, and do not treat the loop option as a restart or uptime mechanism.