When FFmpeg loops a prerecorded file into YouTube Live and viewers see old frames, work through the path from the file to YouTube before changing settings at random. Check that the loop option applies to the intended input, confirm real-time pacing, then compare what FFmpeg produces locally with YouTube’s received stream and health messages.
Those checks help locate the symptom; they do not establish its cause. Without the exact command, FFmpeg version, source-file properties, timestamps, logs and stream-health details, it is not possible to tell whether the issue is in the file, the encoding process, the connection or YouTube playback.
First locate where the picture becomes stale
Start by describing what “old frames” means in your case. Is the picture frozen on one scene, does it briefly show an earlier part of the video after each loop, or does the live playback lag behind the source and later catch up? Note when it happens: at the start of the broadcast, only at the loop boundary, after running for a while, or intermittently. These are observations, not diagnoses, but they make the next checks more useful.
The key comparison is between FFmpeg’s local output and what viewers see on YouTube. If you can monitor a local output safely, look at it at the same time as the YouTube playback. If the local picture is already stale, investigate the input, timestamps, command and encoder process before focusing on YouTube ingest. If local output looks current while YouTube playback does not, compare the broadcast’s health and settings in Live Control Room. This distinction narrows the search; it does not prove which component is responsible.
Keep a short record of the time and type of symptom. For example: “The local preview follows the file, but YouTube freezes for several seconds just after the file restarts.” That is more actionable than “the loop is broken”, because it separates what you observed from what you suspect. If you need a broader explanation of terms such as ingest and bitrate, the guide to live-streaming terms in plain English can help you read the status and configuration screens without treating a label as a diagnosis.
Confirm the loop option applies to the right input
In FFmpeg, -stream_loop is an input option. Put it before the -i for the file you intend to loop. For example, -stream_loop -1 -i input.mp4 requests an indefinite loop of that input. If the option appears after the relevant -i, do not assume it applies to that file; inspect the command’s order and the options associated with each input. The FFmpeg command-line documentation describes the option and its placement.
This matters especially in commands with more than one input, such as a video file and a separate audio source. Read the command from left to right and identify which options precede each -i. Make a copy of the actual command before editing it, then change only the relevant placement and test again. A command copied from an example may have different input order or output options from the one running your stream.
A correctly placed loop option still does not show that every file will repeat cleanly. FFmpeg’s documentation includes considerations around seeking and input behaviour; how a particular file behaves can depend on its format and timestamps. Stream-copy looping may also depend on suitable keyframes and timestamp conditions. Treat those as avenues to inspect if the symptom aligns with a loop boundary, not as a conclusion about your media. A guide to looping a prerecorded video over a broadband connection offers a related operational context, but your own command and source remain the evidence to check.
Pace a file input for live output
A prerecorded file can be read faster than real time unless you ask FFmpeg to pace the input. For a file feeding a live output, -re is the commonly used check: FFmpeg documents it as equivalent to -readrate 1, reading at the input’s native rate. Place it before the file’s -i, just as with other input options. Pacing is relevant because a live destination expects a stream delivered over time, rather than the entire file as quickly as the machine can process it.
Do not assume that adding -re will fix old frames. It is a diagnostic setting for a file input, not an explanation of the incident, and it cannot correct every problem in the source, timestamps, encoder performance or ingest path. Change it in a controlled test, observe the local output and logs, and then compare the YouTube playback. Avoid combining many unrelated changes in one attempt: if the picture improves, you will otherwise not know which adjustment mattered.
There is an important distinction between a file and a live capture source. FFmpeg cautions against applying low read rates to actual capture devices or live streams, because doing so may cause packet loss. Do not paste a file-loop command into a capture workflow without understanding its inputs. If your command mixes a file with a camera or another live feed, determine which input each option affects before changing it.
For an illustrative file-to-live command, the input options appear before the input file:
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 -preset veryfast -b:v 10M -maxrate 10M -bufsize 20M \\
-g 60 -c:a aac -b:a 128k -f flv 'RTMPS_INGEST_URL/STREAM_NAME'
This is a command skeleton, not a tested universal fix. Replace the ingest placeholder with the primary RTMPS ingest address supplied for your stream and its assigned stream name; never publish a live stream key. Adjust codec, bitrate, frame rate, GOP and audio options for your source, intended output and system. In this example, -g 60 corresponds to a two-second GOP only if the output is 30 frames per second. A different frame rate changes that relationship. The FFmpeg guide to a nonstop fireplace stream may be useful for a separate reconnecting symptom, but reconnect options should not be mistaken for a diagnosis of stale frames.
Inspect local output and preserve useful evidence
Before attributing the symptom to YouTube, inspect what FFmpeg is producing. If you have a local preview or can capture a short output for review, compare it with the source around the moment the problem occurs. Check whether the local image pauses, repeats a scene, jumps backwards or remains current while only the YouTube playback looks stale. The point is not to add another monitoring tool for its own sake; it is to establish on which side of the comparison the symptom is visible.
Keep FFmpeg’s relevant log output from the same period. Record the exact command with secrets removed, the FFmpeg version and build information, the source container and stream details, and the timestamps around the loop boundary if available. Also note the output resolution, frame rate, selected codec and bitrate. These details let someone assess whether an option is being applied where intended and whether the media or output differs from an example. Do not include a stream key in a public post or support request.
If you are not sure how to capture or interpret a log, preserve the unedited output first and redact credentials only in the copy you share. Avoid rewriting a suspicious message in your own words: the exact text and the time it appeared can be useful. A warning may point to a condition worth investigating, but a single log line does not necessarily explain a viewer’s symptom. Likewise, a clean-looking log is not proof that the delivered picture is current.
Change one factor at a time and repeat a short, representative test. First verify input option placement; then test file pacing; then review the output configuration if needed. Keep a note of what changed and whether the local output or YouTube playback changed. If the symptom occurs only after a long run, a short test may not reproduce it, so report that limitation rather than presenting an inconclusive test as proof.
Read YouTube’s stream-health messages alongside playback
When the local FFmpeg output appears current but YouTube playback shows old frames, inspect the stream’s health in YouTube Live Control Room while the broadcast is active. YouTube recommends testing before going live and monitoring stream health. The LiveStreams API documentation also describes stream status and health fields for API users. Use the current Control Room message or relevant API status as evidence about what YouTube is receiving, not as a substitute for comparing the local output.
Note the exact health message and when it appears relative to the stale picture. A health warning that begins at the same time gives you a concrete lead to investigate. If health appears normal while playback still seems behind, record that too. It does not rule out all ingest or playback issues, but it prevents you from treating “YouTube is fine” or “the network is bad” as established facts without evidence.
Check whether your configured output matches the stream you intended to send: codec, resolution, frame rate, bitrate, keyframe cadence and audio format. The primary YouTube guidance covers supported ingest settings and recommendations, but the values must fit your actual resolution and frame rate. If your upload connection cannot sustain the selected video bitrate reliably, lower the configured quality and test again. A connection’s nominal plan speed alone does not establish how consistently it can deliver a live upload.
For a 24/7 stream, capture evidence before restarting or editing the command when it is practical to do so. A restart can clear the visible symptom while losing the window in which the health message or log was useful. Do not delay a needed recovery just to collect perfect evidence; save what you can, note the time, and then restore the channel. The related guide to YouTube disconnects caused by RTMP timeouts addresses a different failure mode, so apply its checks only if your evidence points to a disconnect rather than stale imagery.
Compare your settings with current YouTube guidance
YouTube’s encoder recommendations are a useful configuration check, not a promise that a stream will be healthy or that a particular setting explains old frames. Its guidance for RTMP/RTMPS lists H.264, H.265 and AV1 video, CBR, and a recommended keyframe interval of two seconds, with an interval not exceeding four seconds. It lists up to 60 fps. Recheck the current YouTube encoder settings and bitrate table before changing a live workflow, since platform recommendations can change.
The bitrate depends on output format. As listed in YouTube Help when checked on 3 October 2026, H.264 at 1080p30 has a 5 Mbps minimum and 14 Mbps recommended video bitrate. Those figures are for that specific codec, resolution and frame rate; do not apply them automatically to another output. YouTube also gives audio guidance, including AAC or MP3 stereo at 44.1 kHz and 128 kbps. Confirm the values on the current official page rather than relying on an old command copied from a forum.
Compare the guidance with the settings FFmpeg actually uses. A target bitrate in a command does not prove that your connection can sustain it, and the configured output frame rate may not be the source file’s frame rate. If you change resolution, frame rate or bitrate to test, note the before-and-after values and check both local output and YouTube health. You are looking for evidence that helps separate a settings mismatch from a loop or timestamp issue, not a single prescribed profile that fits every channel.
The sensible next step depends on what the comparison shows. If the loop option is misplaced, correct the order and test. If a file is being read without real-time pacing, test pacing for that file input. If local output is already stale, investigate the source, timestamps, FFmpeg behaviour and logs; if only YouTube playback is stale, examine stream health and delivery settings. If those checks do not isolate the issue, share the redacted command, version, relevant logs, source details and health messages with someone who can examine that evidence.
For a channel that must keep running when your own computer is switched off, StreamNeo removes the specific burden of keeping a local machine running the file and restarting the broadcast yourself if it drops; it does not identify or repair a faulty source file or guarantee YouTube stream health.
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
Why does my YouTube live stream keep showing old frames when FFmpeg loops a video?
The symptom alone does not identify the cause. Check that -stream_loop -1 precedes the intended input, verify real-time pacing for a file, then compare FFmpeg’s local output and logs with YouTube playback and stream-health messages.
Does -stream_loop -1 with -re always fix old frames?
No. They are checks for input looping and file pacing, not a guaranteed fix. The exact command, source media, timestamps, encoding behaviour and YouTube’s received stream still need to be examined.
Where should -stream_loop -1 and -re go?
For the file being looped and paced, place both input options before that file’s -i. In a command with several inputs, verify the option order for each input rather than assuming an option applies to the whole command.
What should I include when asking for help?
Share the command with stream keys and other credentials removed, FFmpeg version, relevant logs, source format and timestamps, and the YouTube health messages from the same time. Say whether the local output also shows the stale frames and describe when they occur.