A frozen picture in a YouTube Live stream does not, by itself, tell you what failed. Compare the source file, FFmpeg’s local output or archive, YouTube’s Live Control Room preview and the viewer playback to find the first place the image stops advancing.
Make one change at a time, and use the evidence from each stage to choose it. A process that is still running may be reading a stalled input, struggling to encode, losing its outbound connection or delivering a stream that YouTube cannot process as expected.
Find the first point where the picture stops
Start by comparing the same moment in four places: the original media file, any local FFmpeg output or archive, the Live Control Room preview and the public YouTube player. This is more useful than treating “the stream is frozen” as one diagnosis. YouTube’s troubleshooting guidance for live streams likewise recommends checking the encoder output, encoder errors and CPU load, and the local archive.
If the source file itself has a still frame, a long static shot or a damaged section, YouTube may simply be receiving what the file contains. If the source plays normally but the local FFmpeg output stops, look at the input, filters, encoding and machine load. If local output keeps moving while the Live Control Room preview freezes, investigate the sending path and the platform’s ingestion status before rewriting the loop command.
The viewer player adds another comparison point, but it is not a substitute for preview. A player can lag behind the live edge, buffer or show an issue local to playback. Note whether its picture catches up, whether audio continues and whether other viewers see the same behaviour. Record the time at which each view changes; a repeatable freeze at the exact loop boundary points to a different line of investigation than an intermittent interruption during an otherwise smooth loop.
For an always-on channel, also note whether the sound continues while the image is stuck. A stream can have a moving audio track and a stalled video track, so “the broadcast is live” is not proof that both are healthy. The checks in this guide to missing sound on a Gurbani YouTube Live stream are useful when you need to separate an audio symptom from a picture problem.
Check the source file and loop behaviour
First play the source outside the live chain, including the portion near the apparent freeze and the point where playback should loop. Confirm that the image changes, the duration is what you expect, and playback can pass the end and begin again. A file that opens successfully can still have a damaged section, unusual timestamps or a transition that behaves differently under looping.
For a file input, FFmpeg documents -stream_loop -1 as infinite looping. It is an input option, so it belongs before the corresponding -i. The -re option reads the input at its native rate, which is useful when a file is being sent as a live stream. The FFmpeg documentation for input options explains these options.
An illustrative command shape is:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -c:a aac -f flv \
'rtmp://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
This is a pattern to adapt, not a complete or tested production command. Use the stream URL and key shown in your current Live Control Room, and keep the key private as you would a password. Your codec, stream mapping, resolution, frame rate, bitrate and audio settings need to match your source and YouTube’s current requirements. If the command already loops correctly and the freeze appears in the middle of the file, changing -stream_loop is unlikely to explain the evidence.
Pay particular attention to the loop boundary. If the same pause or freeze returns at the same point each cycle, check the file’s last and first frames, FFmpeg’s timestamps and any decoder messages around the transition. Avoid assuming the boundary is at fault merely because the stream loops; confirm that the event recurs there and compare the local result. Re-encoding can sometimes be appropriate for unsuitable timestamps or stream properties, but it should follow inspection of the file and logs rather than be a first guess.
Read FFmpeg logs and processing speed
Keep the FFmpeg log from a run that includes the symptom. Look for messages about reading or decoding input, filter failures, encoder errors, timestamps, output writes and connection state. The relevant message may appear before the visible freeze, so inspect a window around the time the picture stops rather than just the last line after the process exits.
A live command can remain open while its work falls behind. Watch whether FFmpeg’s reported processing speed stays near real time, whether it drops sharply, and whether CPU use rises when the picture stalls. If the machine cannot decode, filter and encode the chosen material fast enough, the output may become delayed or irregular even though the process has not terminated. YouTube’s troubleshooting page recommends checking CPU load and encoder errors for this reason.
Separate input-side and output-side messages. Decode or filter errors suggest a problem before the stream is sent; write errors and disconnections point towards delivery, though they do not establish whether the cause is your connection, endpoint or another part of the path. A log that contains no obvious error is useful evidence, but it is not proof that every frame is valid or that YouTube received it.
Do not publish a log or screenshot that contains the stream key. Redact the URL path or key before sending a diagnostic excerpt to a colleague or support channel. If the endpoint or key is suspected because the stream will not connect or start, verify both in the current Live Control Room rather than cycling through guesses. YouTube’s stream setup instructions describe entering the stream URL and key in an encoder.
Compare local output or archive
If you can, save a local copy of the outgoing stream while reproducing the problem. Inspect its actual frames at and around the freeze; do not rely only on the file’s existence or increasing size. A growing archive shows that data is being written, but does not prove that the video frames are changing. YouTube’s live-streaming tips advise monitoring the local archive and checking its integrity.
The local comparison divides the problem into useful branches. If the local copy freezes at the same moment as YouTube, focus first on the source, decoding, filters, encoding and the machine. If it remains smooth while the preview or public player freezes, concentrate on outbound delivery and ingestion. If the archive is smooth but the preview is not, preserve the timestamps and dashboard warnings: those details can help distinguish a transient path issue from a format or ingestion warning.
Make sure the archive represents the output you are trying to diagnose. A recording of the source file tests the source; a recording made before encoding does not establish that the encoded output is healthy. When feasible, check a decoded local copy of the actual outgoing video, and compare its frames with the original at the same elapsed time. This is particularly important if the pipeline includes scaling, frame-rate conversion, overlays or other filters.
If a local recording is not configured, do not add complexity in the middle of a live event without considering the risk. You can first inspect the source, logs and preview, then set up a test run or a controlled local capture before the next long broadcast. If your channel uses prerecorded video, the differences between OBS and StreamYard for prerecorded YouTube streams can help clarify which part of a setup is responsible for producing the outgoing picture.
Inspect the Live Control Room preview
Look at the Live Control Room preview while the stream is active and compare it with your local output at the same moment. Check for visible warnings or error messages, and note whether the preview pauses, recovers or never advances while the local picture stays healthy. YouTube recommends checking the preview before going live and monitoring audio and video quality during a stream.
Review the actual stream against the settings selected for the broadcast. YouTube’s encoder settings guidance gives format recommendations, including a target keyframe interval of two seconds and a direction not to exceed four seconds. At 30 frames per second, a two-second interval corresponds to 60 frames. The interval is a time target, so at a different frame rate the frame count needs to change to represent the same duration. YouTube also recommends constant bitrate encoding in its encoder guidance.
Treat those settings as checks, not a diagnosis. A frozen picture alone does not prove the keyframe interval is wrong. Compare dashboard warnings with the command and encoder output to see whether the actual stream differs from the selected format, frame rate, resolution or keyframe expectations. If YouTube reports an ingestion or format problem, correct the mismatch indicated by the current official guidance, then confirm the preview improves.
Do not change several settings at once. If a keyframe warning is present, adjust the relevant encoder setting and observe the result. If there is no such warning and the preview is the only place that freezes, preserve your local evidence and investigate delivery before changing GOP or codec options. A stream that has been accepted and is playing can still have a problem, but it is not the same situation as a rejected endpoint or an incorrect key.
Check outbound network health
When the source and local outgoing picture remain sound, test the upload path from the machine or location sending the stream. Pay attention to stability as well as available upload capacity: a favourable speed result at one moment does not establish that the connection will remain steady through an overnight broadcast. Compare the test with the configured stream bitrate and watch for packet loss, interruptions or changes in the Live Control Room’s reported stream status where available.
YouTube’s troubleshooting guidance recommends testing the outbound connection and suggests contacting the internet provider if the test shows a problem. Do not use download speed as a stand-in for upload performance. If your stream is intermittent, record when it happens and whether the local output continues normally while the preview loses motion; a timeline is more useful than a general impression that the internet was slow.
FFmpeg’s FIFO muxer documents optional output recovery behaviour, including an example for retrying after temporary network failure. Such recovery can help with a temporary sending interruption, but it does not repair a stalled source, make a frozen local output advance or resolve persistent connection problems. Consult the FFmpeg FIFO muxer documentation and validate any adaptation in a controlled test before relying on it for a long-running channel.
If you use retry or recovery options, understand what they do to the output and how the process reports a failure. Recovery is not a promise that viewers will see uninterrupted playback, and a restart can still leave a gap or require attention in YouTube. For a setup where keeping a computer running is itself the fragile part, StreamNeo can remove the need to leave that computer on for a file-based 24/7 broadcast; it does not change the need to check the source, YouTube preview and stream health.
Narrow the cause before changing settings
Use the first point of failure to narrow the next test. The table is a working diagnosis, not a guarantee: more than one fault can produce similar symptoms, and you should verify a suspected cause before changing the live configuration.
| What you observe | What it makes more likely | Useful next check |
|---|---|---|
| The source file freezes at the same frame | The media itself or its playback | Inspect the file around that point and through the loop boundary |
| Source is smooth; local encoded output freezes | Decode, filter, encode or machine load | Review FFmpeg messages, speed and CPU at that time |
| Local output is smooth; preview freezes intermittently | Outbound delivery or ingestion | Compare connection health and Live Control Room status |
| Preview is smooth; one viewer’s player freezes | Playback, buffering or a viewer-side path | Compare another playback view and determine whether it catches up |
| Freeze returns exactly at each loop boundary | Boundary handling, timestamps or source transition | Compare the local frames and log messages at the transition |
| Preview shows a format warning | A mismatch with the selected stream settings | Check the current YouTube guidance and actual encoder configuration |
Change only the setting tied to the evidence. A repeatable local freeze at the loop edge calls for inspecting media and timestamps, not adding network retries. A smooth local output paired with outbound write failures calls for connection investigation, not re-encoding a healthy file. A dashboard warning about format deserves a settings comparison, while a preview that is healthy and one viewer who sees a freeze calls for a playback comparison first.
Keep a short incident note: time, whether audio continued, which views were frozen, relevant FFmpeg messages, processing speed and any Control Room warning. If a change makes the symptom disappear, repeat the observation during a test rather than treating one recovery as proof. For several streams or a channel with planned rotation, this guide to managing concurrent broadcasts on one channel is relevant when you are separating a single stream fault from a scheduling or channel-level change.
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 is my YouTube Live picture frozen while FFmpeg is still running?
A running FFmpeg process only tells you that the process has not exited. Compare the source, local output, logs, Live Control Room preview and outbound connection to find whether frames stopped advancing before or after they left the encoder. Do not infer a reconnect or encoder fault from the symptom alone.
Should I add -stream_loop -1 to fix a frozen picture?
Use it when the intended behaviour is to repeat a file indefinitely, and place it before the relevant -i input. It does not repair a file that stalls, timestamps that behave badly at a boundary or an outbound connection problem. Check local playback and logs before changing the command.
Does a growing local archive mean the video is healthy?
No. The file can continue growing while repeated or static frames are written. Inspect the actual frames around the reported time and compare them with the source and YouTube preview.
When should I change the keyframe interval?
Change it when the encoder configuration or Live Control Room indicates that it does not meet the current YouTube guidance, not simply because the image froze. YouTube’s guidance targets a two-second interval and says not to exceed four seconds; match frame count to the configured frame rate and verify the result in a test.