A YouTube live stream that appears stuck on one video may be failing at the source, encoder, VPS, YouTube ingestion or viewer playback. The picture alone cannot identify which stage has stopped, so check each part of the chain and compare timestamps and health messages before changing settings.
If FFmpeg still shows as running, that only tells you that a process exists. It does not prove that the source is advancing, new frames are being encoded, the VPS is delivering them steadily or YouTube is receiving them smoothly. Work through the checks below in order and keep a record of what you observe.
Determine whether the source or playlist is advancing
Start at the input. Find out whether the file, playlist or other source is producing new content at the time the stream appears frozen. A player can repeat a still frame even while a broadcast connection remains open, and a playlist can reach its end or repeat an unintended item without an obvious error on YouTube.
If you use a playlist, confirm which item should be playing now and which item actually appears in the encoder logs or process configuration. Check that the playlist has not run out of entries, that paths still point to readable files and that the intended loop or rotation is active. If you run an MP4 loop through FFmpeg, the guide to looping an MP4 with SRS and FFmpeg can help you review that part of the setup; do not assume a working loop is the cause or cure without checking your own process.
For a file-based source, compare input timestamps immediately before and during the reported freeze. If the input timestamp advances but the output timestamp does not, the fault is likely later in the local chain than the file reader. If neither advances, look at the input, playlist state, file access and the command or service that launches the stream. These observations narrow the investigation; they do not, on their own, prove a root cause.
Also establish what viewers mean by “one video”. They may mean one still image, one repeated scene, or the same scheduled item continuing longer than expected. Those are different symptoms. A devotional channel that is meant to show one temple image while bhajan audio plays may be behaving as configured, while a music rotation that should move to a new track may not be. Check the intended schedule against what the source actually supplies. For planning playlist changes rather than diagnosing a stalled process, see the article on daily playlist rotation for a 24/7 cartoon livestream.
Keep a short timeline: the time the viewer noticed the freeze, the source item expected, the last input timestamp, and the first timestamp that failed to move, if any. Use one time zone consistently. This gives you something concrete to compare against encoder logs, VPS metrics and YouTube’s health history.
Check whether the encoder is emitting new frames
Next, inspect the actual encoder rather than relying on a service manager’s status. A service can report “active” while its child process is stuck, repeatedly reconnecting, unable to read the input or failing to send output. Review FFmpeg or OBS logs around the recorded time, including restarts and errors, and compare input and output timestamps where your setup exposes them.
Look for evidence such as a process exit, a restart loop, decode or read errors, a stalled output timestamp, encoder overload, or a connection that repeatedly drops and reconnects. Note the exact time and message rather than paraphrasing it. If the process has no useful logs, consider adding logging or monitoring before the next overnight run so that a recurrence is diagnosable. A lack of a visible error is not evidence that frames are reaching YouTube.
For an FFmpeg-based stream, distinguish input progress from output progress. An input advancing while output stops points to a problem between reading and sending frames, but more evidence is still needed to separate encoding, resource pressure and network delivery. If both advance, yet the public player looks frozen, continue downstream rather than repeatedly restarting the source.
Configuration matters too. Compare the actual codec, resolution, frame rate, bitrate, keyframe interval and audio format with YouTube’s encoder settings guidance. YouTube lists RTMP/RTMPS, supported video codecs including H.264, H.265/HEVC and AV1, and recommends a two-second keyframe frequency with no more than four seconds. These are configuration recommendations, not a promise that a particular encoder or connection will work.
Use the row for your real codec, resolution and frame rate when checking bitrate. For example, YouTube’s current table gives H.264 1080p30 a recommended 14 Mbps and a minimum 5 Mbps; H.264 720p30 is listed at a recommended 8 Mbps and a minimum 3 Mbps. Those figures are YouTube recommendations, not proof that your VPS can sustain the rate. The table can change, so confirm the current guidance rather than treating figures in an old command as permanent.
Audio can help distinguish a full freeze from a video-only issue. If viewers still hear changing audio while the picture holds, record that separately. YouTube’s settings guidance lists AAC or MP3 audio for RTMP/RTMPS and recommends 44.1 kHz stereo at 128 kbps stereo bitrate. A mismatch or missing audio may generate a health issue, but audio continuing does not establish that video ingestion is healthy.
Review VPS CPU and outbound network
A VPS may have enough nominal capacity on paper but still struggle during an actual encode or sustained upload. Check CPU use, memory pressure and relevant system logs around the freeze, along with the encoder’s own output. If the CPU is saturated, the process may not keep up with its chosen encoding settings; if the host or route has interruptions, the output may not reach YouTube steadily.
Measure sustained outbound throughput while the stream is running and compare it with the selected video and audio bitrate. Advertised port speed is not the same as observed delivery over time. Also look for disconnects, packet loss or other signs of instability if your VPS monitoring provides them. Record what the host reports at the time rather than inferring a network issue from a frozen player.
OBS’s official troubleshooting guidance describes dropped frames as a sign that the connection to the remote server is unstable or cannot keep up with the configured bitrate. That advice is useful as a principle for a VPS encoder, but OBS’s interface-specific instructions are not FFmpeg commands. For FFmpeg, inspect its logs and the host’s network evidence instead. If the evidence points to insufficient or unstable capacity, a controlled test at a lower bitrate may help; change no other setting at the same time.
A useful comparison is whether the source and encoder timestamps move, whether YouTube reports an incoming-feed issue, and whether the VPS can sustain the selected output. Compare configurations using actual codec, resolution, frame rate and bitrate—not a host’s headline bandwidth alone.
| Evidence | What it supports | What it does not prove |
|---|---|---|
| Input timestamp stops | Check the source, file access or playlist progression | That YouTube or the VPS network caused the freeze |
| Input moves but output stalls | Investigate encoder processing, resources and send path | Which local component failed without logs and metrics |
| Output moves, YouTube reports a feed issue | Investigate delivery and the reported health message | That one bitrate change will fix every case |
| YouTube reports healthy ingestion, only some viewers affected | Compare playback devices, browsers and networks | A universal viewer-side fix |
Inspect YouTube ingestion and stream health
Open Live Control Room and review the stream health and any messages around the time of the symptom. YouTube’s Live Streaming API documentation models the incoming feed as a liveStream resource with status and health information. Its issue catalogue identifies conditions such as low bitrate, frame-rate mismatch, missing audio and other configuration problems. Record the precise message, issue code and time; “health looked bad” is less useful than the exact text.
One issue worth recognising is videoIngestionStarved. Google’s configuration issues documentation describes this as YouTube not receiving enough video to maintain smooth streaming, so viewers may experience buffering. If you see that issue, it is evidence about the feed reaching YouTube. It does not by itself say whether the source stopped, the encoder fell behind or the route from your VPS became unstable. Use local timestamps and host evidence to distinguish those possibilities.
Read the health message before adjusting encoder settings. A bitrate warning, a keyframe issue and a frame-rate mismatch call for different checks. Compare the message with the actual encoder output and the current YouTube settings table. YouTube recommends monitoring stream health during the event; keep a note of the status before and after any test change.
If no health issue appears, that is useful but not conclusive. It makes a documented ingestion warning less likely to explain the viewer’s report, but it does not tell you that every viewer’s playback path is working. Preserve the health status and continue to compare the local output with what different viewers see.
Compare the viewer playback path
Check whether the freeze is visible to everyone or only to one viewer, device or network. Ask another person to open the public player, and if practical compare a second device or browser. Note whether audio continues, whether the player buffers or pauses, and whether refreshing changes the report. These checks help separate a shared broadcast problem from an individual playback problem, but they are not a diagnosis by themselves.
When YouTube reports healthy ingestion and only some viewers see a frozen picture, collect the video URL, time, player and device details, browser or app version where available, network context and whether another viewer reproduces it. Keep those details beside the stream health status and your encoder timeline. The available official guidance does not establish one definitive fix for every viewer-side freeze, so avoid prescribing a universal cache reset or bitrate change without evidence.
The distinction matters for a small business or local news loop: restarting a stream can interrupt every viewer, even if only one phone on a poor connection is affected. First establish how broadly the symptom occurs. If all viewers report the same point at the same time, investigate upstream stages; if reports differ, retain the playback details while checking that the feed itself remains healthy.
Change one suspected failure point at a time
Once the evidence points towards a stage, make one change that addresses that stage and repeat a test. If the source is not advancing, correct the playlist or input before tuning bitrate. If output timestamps stall alongside CPU saturation, test a lower encoding load or suitable encoder setting. If the VPS output is not sustained and health messages support an ingestion problem, test a bitrate that matches both YouTube’s current recommendation for the selected format and the capacity you actually observe.
Do not change bitrate, resolution, frame rate, keyframe interval and the playlist all at once. If the stream improves, a bundle of changes will not tell you which mattered; if it worsens, you will have more possibilities to unwind. Write down the original setting, the single change, the time, and the resulting source/output timestamps, host metrics and YouTube health. Revert a test if it introduces a new issue.
For a useful test, use movement and audio similar to the real programme, then observe it long enough to see whether the suspected symptom returns. YouTube advises testing before going live with audio and movement similar to the intended stream, and monitoring health messages during the event. A static test frame may not reveal a problem that appears during a changing video or audio segment.
If you are choosing a different way to keep a file-based channel running because overnight VPS process checks and restarts are the recurring burden, StreamNeo removes that particular task by taking an uploaded video and running it as a YouTube live stream without your computer left on. That does not diagnose a current frozen stream or remove the need to check your source, channel and YouTube health.
Confirm the stream resumes moving
Do not call the issue fixed merely because the service process is active again or the player starts showing a picture. Verify that the source is advancing as intended, the encoder’s output timestamps keep moving, the VPS can sustain its outbound stream, and YouTube’s health messages remain consistent with a healthy feed. Then compare playback from more than one viewer where possible.
Keep the before-and-after evidence together: the event time, expected source item, input and output timestamps, relevant process messages, CPU and network observations, YouTube issue code or status, and viewer reports. If the symptom returns, this record can show whether it recurred at the same point in the chain or only on a particular playback path.
A continuous channel also needs a recovery plan for a failed host or process. After diagnosing this incident, review the operational steps in how to restart a YouTube 24/7 stream after a power outage. Automatic restart can help recover an exited process, but it cannot guarantee that the source advances or that YouTube receives a clean feed. Treat restart behaviour as one part of the chain, not a substitute for monitoring it.
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 24/7 YouTube live stream stuck on one video?
The symptom alone does not reveal whether the source stopped, the encoder stopped emitting new frames, the VPS delivery became unstable, YouTube reported an ingestion issue, or only a viewer’s playback stalled. Compare source and output timestamps with VPS evidence and YouTube’s health messages before choosing a cause.
How do I keep a YouTube stream running from a VPS?
Keep the source and playlist accessible, monitor the encoder process and output, and check host resources and sustained outbound delivery while the stream is active. Review YouTube health during the broadcast and keep logs that let you identify which stage failed if the stream stops moving.
Why does my livestream freeze or buffer even though FFmpeg is still running?
A running FFmpeg process does not prove that it is reading new content, encoding new frames or delivering them steadily. Check its logs and timestamps, compare VPS resource and network evidence, and look for matching YouTube health messages; the process status alone cannot locate the fault.
What should I do if YouTube says the stream is healthy but one viewer sees a freeze?
Check whether another viewer, device or browser reproduces the problem, and record the time, URL, player details and whether audio continues. Keep YouTube’s health status alongside those observations; healthy ingestion with a single viewer report does not support a confident universal playback fix.