If a video loop appears to freeze during a YouTube live stream, first check whether the picture has stopped in OBS itself or only in YouTube playback. That distinction tells you whether to investigate the source and its files, or the stream’s encoding and delivery; neither symptom has one universal cause or fix.
Start by identifying whether OBS is playing one file with Media Source, a playlist with VLC Video, or a network stream. Then change one relevant control at a time and record what happens at the same file boundary.
Determine where the freeze appears
Look at OBS’s preview at the point where viewers report the freeze. If the picture stops there too, the problem is already visible before YouTube delivery. Focus first on the source, its playback controls, the media inputs and OBS’s own logs. If the preview continues normally, do not assume the source has frozen simply because a viewer’s YouTube player appears stuck.
When available, compare the preview with a local recording and the audio meter. A local recording can help establish whether OBS continued producing output, though it may not reproduce every issue in the live delivery path. The audio meter is another clue, not a verdict: sound continuing while a picture appears still does not establish whether the cause is an OBS source, encoding, or playback on YouTube.
YouTube’s guidance recommends checking the stream directly in the encoder. If that output is unhealthy there, investigate sources routed into the encoder, encoder errors and CPU load. If it looks healthy in the encoder, turn attention to the outbound connection and YouTube’s stream-health evidence. See how to check whether a 24/7 YouTube lecture stream is still playing for a separate way to think about monitoring a channel over time; it does not replace inspecting the output where the fault occurs.
Keep the symptom description precise. “The VLC playlist preview stops on the second item” is more useful than “YouTube froze”. Note whether the picture freezes, goes blank, or disappears, whether audio continues, and whether the problem is visible locally. If OBS is healthy and only one YouTube playback view is affected, that is a different diagnostic branch from a source visibly stuck in OBS.
Check the source in OBS
Open the scene that contains the loop and identify the exact source type. OBS Media Source is for an individual media file. VLC Video supports playlists and uses VLC libraries; OBS documentation says VLC must be installed for this source to appear, and that 64-bit OBS requires 64-bit VLC. A source receiving a network stream is another case: it depends on the supplied stream input, not merely a local file reaching its end.
Write down the source name, scene, file or playlist location, and whether the media is local or remote. For a playlist, record the entries and their order. Check whether every transition fails or only the transition from one particular item to another. If the same file plays elsewhere but a single boundary repeatedly fails in OBS, that points towards a narrower test than replacing the whole setup.
OBS’s Media Sources reference lists supported built-in media types including MP4, TS, MOV, FLV, MKV, AVI, GIF, WebM, MP3, AAC, OGG and WAV. That list identifies documented types; it does not guarantee that every file with a listed extension is encoded in a way that will behave correctly in every system. Preserve an original copy before converting or otherwise modifying a file, so that you can compare the original and the test copy.
For a controlled check, create a temporary scene with only the source in question. Keep the output settings unchanged and test the relevant file or transition. If a simpler scene behaves differently, then scene complexity or another source may matter. If it fails in the same way, you have narrowed the test towards the media input or source configuration, but have not yet proved the exact cause.
If you are weighing a different playback method, keep the distinction practical. Media Source is the simpler fit when you have one file; VLC Video is the documented OBS source for a list of files. Other workflows, such as streaming videos in order from a text file to YouTube, involve a different tool and configuration. That comparison is useful when choosing a workflow, not evidence that changing software will cure a fault in your current one.
Inspect media-source playback controls
Match the loop control to the source type. For one file in Media Source, inspect Loop: this controls whether the file plays again after completion. For a multi-file VLC Video playlist, inspect Loop Playlist, which controls whether the playlist restarts after it runs out of files. OBS documents Loop Playlist as enabled by default, but check the current setting rather than assuming it has not been changed.
Also verify the playlist itself. Confirm that each intended entry is present, that its path still resolves, and that the item order matches your expectation. A list that fails at one boundary calls for checking the files on each side of that boundary. A loop setting cannot correct a missing or inaccessible playlist item, and turning on the wrong loop control will not test the behavior you mean to test.
Several nearby Media Source options have different jobs:
| Control | What it does | What to check |
|---|---|---|
| Loop | Repeats an individual Media Source file after completion. | Use it for a single file intended to repeat. |
| Loop Playlist | Restarts a VLC Video playlist after it runs out of files. | Use it for a playlist, and confirm its entries and order. |
| Restart playback when source becomes active | Starts the file again when its source becomes active in the current scene and visible. | Do not treat this as the end-of-file loop control. |
| Show nothing when playback ends | Hides the source after the file ends. | It does not make a file repeat. |
| Close file when inactive | Closes the media file when the source is hidden or off the current scene to free memory. | OBS warns that showing the source again can involve a short reload. |
For VLC Video, Visibility Behaviour controls whether playback continues, pauses or stops while the source is not visible. This matters if your scenes switch during the stream: a source becoming hidden is not the same event as its playlist reaching the end. Test visibility behavior only if the source is being hidden or moved between scenes when the symptom occurs.
Avoid toggling several controls together. If you enable Restart playback when source becomes active and alter Loop Playlist in the same test, a successful restart will not tell you which change mattered. First restore the intended scene and visibility behavior, then test the end-of-file control that matches the source.
Check output and stream-health evidence
When OBS preview continues but YouTube playback looks stalled, check the encoder output and YouTube’s stream-health information before changing media-source settings. YouTube’s live-stream troubleshooting guidance separates problems visible in the encoder from problems that appear in delivery. Its stream-health documentation can help you inspect the evidence YouTube reports for the broadcast.
Look for contemporaneous indicators rather than a single impression: does OBS show rendering lag, dropped frames or an encoder warning; does the encoder’s own output stop; does YouTube report a stream issue; and does the outbound connection appear unstable? The answers help choose the next branch. A healthy-looking OBS output with trouble reported only in delivery makes a source-loop adjustment a poor first test. A visibly stopped source in OBS is not explained merely by checking internet strength.
If you use a local recording, compare the portion around the reported boundary with what appeared in the preview and the YouTube player. A recording that contains continuous video while the live player stalls is useful evidence of a difference between local production and delivery. It does not by itself identify the network, encoder, or player behavior responsible. Note the time and the exact segment so you can match it against OBS and YouTube diagnostics.
OBS’s encoding-performance troubleshooting guide discusses resource bottlenecks, complex scenes, and resource-intensive sources or filters as possible performance concerns. Use that branch when the freeze coincides with rendering lag, encoder warnings, or other system-wide symptoms. Reduce scene complexity or costly filters as a test, and inspect the relevant OBS log; do not infer that a GPU bottleneck caused every freeze at a file boundary.
Likewise, a reported freeze alone is not evidence that you need new hardware. A simpler scene or a lower media resolution may be worth testing if the evidence points to performance pressure. OBS recommends matching media resolution to what the canvas and output need. Change that only as a measured test, and compare the result rather than assuming lower resolution is a universal fix.
Test files and transitions separately
A loop has at least two things to test: playback of each item and the hand-off from one item to the next. Play a suspect file by itself in the same source and scene. Then test a short sequence that includes the item before the problem, the problem item, and the item after it. If individual files play but one transition repeatedly stalls, record that boundary; do not label the whole playlist defective without further evidence.
Keep the test conditions stable. Use the same source type and scene, and note whether the file paths are local or remote. If practical, test a copy of the suspect file in a temporary, separate sequence without changing the original playlist. If the copy behaves differently, that gives you a useful comparison, but it still does not establish why the original behaved differently. Record any file conversion or other change so the test remains interpretable.
Do not assume that a transition fault is a YouTube fault or that every playlist needs a different source. The OBS forum contains user reports using phrases such as “VLC video source freezes after ~6 hours”. That is an individual report, not a typical duration, measured rate, or confirmed explanation for other users’ symptoms. Community reports can help you recognise that others have described a similar experience, but they do not establish a general fix.
The same caution applies to proposed workarounds such as scheduled OBS restarts, larger network-cache values, or replacing the source. A workaround is relevant only if you test it against your own reproducible symptom and can show that it changed the result. OBS documents a default VLC Video network-caching value of 400 ms; that is a documented setting default, not a recommended adjustment for this freeze. Do not increase it just because the word “freeze” sounds like a network problem.
For a recurring channel, choose tests that do not jeopardise the programme your viewers expect. A short private or otherwise suitable test broadcast, or a test scene when the channel is not carrying its main content, can make it easier to isolate a boundary. Follow YouTube’s current guidance for the visibility and settings of your tests. The point is to see the source and output under known conditions, not to experiment blindly during an important devotional, study, news, or ambience stream.
Change one setting at a time
Once you have a repeatable symptom, make one change that answers one question. For example, if a single Media Source file ends and does not begin again, check its Loop control. If a VLC Video playlist reaches the end and does not start over, verify Loop Playlist. If the source vanishes when it ends, inspect Show nothing when playback ends. Each test should correspond to the behavior you observed.
Before a test, write down the existing setting and the expected result. Make the change, reproduce the same file boundary, then note whether the symptom changed. If the issue is intermittent, say so: one successful pass is evidence, not proof that the issue is resolved for an always-on stream. Keep the previous configuration available so you can restore it if the test causes a different problem.
If the evidence points to performance, reduce one likely burden such as a costly filter or an unnecessarily complex scene, then compare OBS’s indicators and the transition. If the evidence points to delivery, leave source controls alone while you examine the outbound connection and YouTube stream health. Avoid mixing a source change, a media re-encode and an output-bitrate change into one trial; you would not know which factor affected the result.
A different streaming workflow may be appropriate if OBS’s playlist behavior is not a good fit for your operating needs, but make that a separate decision. For example, FFmpeg options for looping a folder of videos on a Linux server describe another approach, with its own setup and trade-offs. It is not a reason to abandon a working OBS configuration before you have located the fault.
If maintaining a computer and diagnosing repeated source behavior is the pain you are trying to remove, StreamNeo turns an uploaded video into a YouTube live stream that can run with your computer switched off and be monitored and restarted automatically if it drops. It is YouTube-only, and it addresses the operating burden of broadcasting a file; it does not diagnose or repair an OBS source that freezes between playlist items.
Document reproducible results
Keep a short incident record for each test. Include OBS version, source type, media file or playlist, scene and visibility behavior, the relevant loop controls, and whether the files are local or remote. Record the time of the symptom, whether OBS preview and any local recording continued, what the audio meter did, and what YouTube reported. These details let you distinguish a source-side freeze from a delivery-side problem when you revisit it after a night’s run.
Save the OBS log associated with the affected session and note any warning near the time of the incident. A log is most useful alongside a repeatable description; an isolated warning that happens at another time may not explain the transition. If you ask for help, share the source type, the smallest repeatable test, the relevant log, and what you observed in OBS versus YouTube. Remove stream keys and other sensitive details before sharing configuration or screenshots.
Use a simple results table so the conclusion does not depend on memory:
| Test | Single file or boundary | One change made | OBS result | YouTube result | Next step |
|---|---|---|---|---|---|
| Baseline | Record the exact item or transition. | None; current settings. | Preview, recording and warnings. | Player and stream-health observation. | Choose the branch supported by evidence. |
| Source control | Same item or transition. | One matching source control. | Did the source restart or remain stuck? | Did delivery change? | Keep, revert or test again. |
| Performance | Same scene and boundary. | One scene, source or filter adjustment. | Note lag or encoder evidence. | Note any corresponding change. | Inspect the log or restore baseline. |
Do not turn a single good run into a permanent conclusion when the failure is intermittent. Repeat under comparable conditions and make clear whether the result is consistent, mixed, or not yet reproduced. The useful outcome may be a narrowed diagnosis rather than a certain root cause. That is better than presenting a forum anecdote or a guess as a universal fix.
If a test identifies a persistent OBS source problem, you can decide whether to continue with that source, simplify the playlist, or evaluate another workflow. If it instead points to encoder or delivery health, follow the evidence on that path. For a 24/7 channel, the operational choice is not only what works once but what you can monitor, recover and explain when it fails overnight.
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
Is a freeze between files always caused by the VLC playlist?
No. First determine whether you are using Media Source for one file, VLC Video for a playlist, or a network source, then see whether the fault is visible in OBS. A YouTube player issue with healthy encoder output is a different problem from a source visibly frozen in the OBS preview.
Should I increase VLC network caching to fix the freeze?
Not without evidence that this is the relevant issue. OBS documents a 400 ms default for VLC Video network caching, but that default is not a prescribed fix for a file-boundary freeze. Test one change at a time and record whether it alters the reproducible symptom.
Does “Restart playback when source becomes active” make a file loop?
No. It restarts playback when the source becomes active in the current scene and visible; Loop is the Media Source control for repeating an individual file after it completes. For a VLC Video playlist, check Loop Playlist instead.
What should I send when asking for help?
Include your OBS version, source type, file or playlist details, relevant controls, and a log from the affected session. Explain whether the preview, local recording, audio and YouTube playback continued, and identify the exact file boundary and any one-setting tests you have already made.