When a pre-recorded clip changes or freezes as you switch OBS scenes, first work out whether the clip restarted, briefly disappeared while reloading, held on one frame, or whether the whole output became choppy. Those are different symptoms, and the right first check is usually in the Media Source properties or in OBS performance—not a YouTube setting.
Use the OBS preview to make the distinction before changing anything. If only one clip is affected, test its playback behaviour; if several sources and the preview stall together, look at scene and encoding load. The available OBS guidance explains these local source and rendering behaviours but does not establish YouTube as the cause of scene-switch changes.
Identify exactly what freezes or changes
Switch between the affected scenes during a controlled test and note what happens to both the clip and the OBS preview. Does the video begin again from its first frame? Does the scene return with a short blank or frozen-looking interval before the file appears? Does one frame remain on screen while audio continues? Or do other sources, transitions, and the preview also stutter? Write down what you see rather than labelling all of it a “freeze”.
A restart is a playback position change: after returning to the scene, the file starts over. A reload gap is different: the source was not available while hidden and needs a moment to appear again. A held frame can be confined to one media source, while choppiness across the preview suggests a wider rendering or encoding problem. These descriptions help narrow the next test; they are not a formal diagnostic decision tree from OBS.
Compare the preview with the stream only after establishing what OBS itself is doing. If the preview visibly restarts or stalls at the scene change, investigate the source or OBS workload first. If the preview behaves normally but viewers report a problem, collect the time, affected scene, and available stream evidence before concluding where the issue lies. Scene switching alone is not evidence that YouTube caused the behaviour.
For a broader picture of switching between looped clips, see the guide to OBS scene transition settings. Transitions affect how scenes are presented; they are separate from whether a hidden Media Source restarts or is unloaded.
Check Media Source playback properties
Right-click the affected source in OBS and open its properties. Confirm that it is the Media Source you intended to test and that the file path points to the clip in question. OBS's Media Sources documentation describes the controls available for local files, including looping, playback speed, hardware decoding when available, restart-on-activation, and closing the file while inactive. Labels and layout can vary with the OBS version, so check the controls in your installed version rather than relying on a screenshot from another release.
For a single local clip, first inspect its loop and playback settings. A clip that reaches its end may hide when playback ends if that option is enabled; a looping source should repeat instead. A playback-speed value other than the intended speed can also make a clip appear to behave unexpectedly. Do not change all the properties at once: note their original state, adjust only the one that fits the observed symptom, then repeat the same scene change.
If the problem is a restart on return, test Restart playback when source becomes active. OBS describes this property as restarting playback when the source becomes active in the current scene and visible. It is documented as on by default in the Media Sources guidance. Turning it off is a targeted test for a clip that begins again whenever you return; it is not a general remedy for a held frame, a reload gap, or system-wide stutter.
If the setting is already off, confirm that you are editing the source instance used in the scene you switch to. OBS scenes can contain different sources that point to the same file, or separate source instances with their own properties. A change to one instance will not necessarily change another. Test the exact source visible in the returning scene and keep a brief note of the result.
Understand restart playback when the source becomes active
“Active” matters here. When a source becomes visible in the current scene, OBS can apply its restart-on-activation behaviour. That can be useful for a short introduction, title card, or clip that should always begin at the opening when shown. It is undesirable for background footage or a long programme segment that you expect to continue from its previous position after temporarily switching away.
If your clip restarts and you want it to continue, turn off the restart option for that source, then switch away and back in the same test sequence. Watch the preview from before the switch through the return. If the clip resumes at the expected point, you have evidence that this property explains the restart. If it instead reappears late or remains frozen, restore or leave the setting according to your intended playback behaviour and investigate the separate inactive-source setting.
Consider the purpose of the scene before changing this behaviour. A welcome clip may be meant to restart each time it is shown; a long devotional or ambience bed may be expected to keep its position. The setting controls playback on activation, not the contents of the file and not what YouTube does with the broadcast. To compare scene-transition timing separately, use the looped-video transition guide as a companion, but keep one variable under test at a time.
Check pause behaviour when the source is inactive
Inspect Close file when inactive independently. OBS documents that this option unloads a source file when it is hidden or absent from the current scene, which can free memory. When the source becomes visible again, it may take a short time to reload. That interval can look like a freeze even though it is not the restart-on-activation behaviour.
If you need the return to be immediate and the memory saving is not important for your setup, test with the file kept open while inactive. Switch away and back several times and note whether the blank or held-looking interval changes. If it does, the unload-and-reload behaviour was relevant. If not, do not assume the setting is responsible just because it is present.
The trade-off is straightforward: unloading can reduce the resources used by a hidden source, while keeping it loaded can avoid the reload delay. The appropriate choice depends on the number and size of sources and how important an immediate return is. Do not treat a short reload gap as proof that the file is corrupt, or as evidence of a YouTube-side fault.
Also distinguish pausing from unloading. A source may stop advancing while it is hidden and continue when shown again, or it may reload; what you see depends on its properties and OBS behaviour. Record whether the first visible frame is the old position, a new start, or a brief blank, then test the matching control rather than toggling both properties together.
Test scene switching with the source visible
A simple test can separate a source property from the way the scene is built. Make a temporary scene containing the affected Media Source, or use the existing scene after recording its current settings. Start playback, wait until the clip is visibly moving, switch to a scene without it, and return. Repeat using the same transition and approximate wait so you can compare like with like.
During the test, keep an eye on the OBS preview and listen for audio if the clip has it. Note whether the picture and audio both stop, whether audio continues beneath a frozen frame, and whether another source stutters at the same time. These observations do not identify a confirmed cause on their own, but they make the next test more useful than changing settings by guesswork.
If the source behaves differently in another scene, inspect whether the two scenes use the same source instance and whether a transition or visibility action is involved. Try a direct cut temporarily only as an isolation test; it is not a recommendation to remove the transition permanently. The radio-stream buffering guide addresses a different symptom: viewer-side buffering can have different causes from a local source changing during an OBS scene switch.
For an unresolved media-only issue, try a controlled comparison with another copy of the clip or a short test file, without changing the scene setup. If the alternate file works, that narrows the investigation towards the original media or its path, but does not prove which property is at fault. If both behave the same way, return to the source settings and scene visibility behaviour.
OBS also offers VLC Video for cases where a playlist or extended media support is needed. According to the OBS VLC Video documentation, the source uses VLC libraries and requires VLC to be installed; a 64-bit OBS installation requires 64-bit VLC. Treat this as an isolation option when its playlist or format support is relevant, not as a promised cure for freezing. For a single ordinary file, built-in Media Source may be the simpler choice.
| Choice | Useful when | What to account for |
|---|---|---|
| Media Source | You need to play a local file with OBS's built-in source controls | Test its activation and inactive-file properties directly |
| VLC Video | You need playlist or extended-media support | VLC must be installed in the matching bitness for OBS |
In either case, compare the same file, scene, and switching sequence, and observe the preview. Do not infer that one source type is inherently more reliable from a single test.
If the whole output is choppy, investigate performance
If several sources or the whole OBS preview become choppy, stop treating the symptom as a single Media Source restart. OBS notes that scene composition uses GPU resources, and its encoding performance troubleshooting guide recommends reducing output resolution or frame rate and simplifying scenes when OBS cannot keep up. Those are general performance measures, not a diagnosis that your machine is overloaded.
First test a simpler version of the scene: hide decorative browser sources, filters, or animations that are not needed for the test, and see whether the preview improves. If there is a change, restore sources one at a time to find which part of the composition matters. Avoid buying a new graphics card or storage drive based only on one clip freezing at a scene switch; the evidence should point to a broader capacity limit before hardware becomes a sensible consideration.
Reducing output resolution or frame rate can lower the work OBS must do, but it changes the stream viewers receive. Choose a test value appropriate to your channel and connection, then compare the same scene-switch sequence. A lower frame rate may be acceptable for a static lecture slide or devotional image, while moving footage may make the difference more noticeable. There is no universal setting that suits every channel or system.
Change one performance factor at a time. If simplifying a scene helps but changing output settings does not, the scene composition is more relevant than the output target. If neither changes a single-source restart, return to the Media Source properties. OBS's recommendations are conditional: broad stutter supports testing resource demand, but an isolated source symptom does not by itself prove a GPU bottleneck.
For a channel that is intended to run continuously, the operator's computer also becomes part of the broadcast workflow: OBS must remain open and the source must keep behaving as intended. If your actual problem is that you need the uploaded file to continue as a YouTube live stream while your own computer is switched off, StreamNeo removes that specific need to keep OBS running locally; it does not alter OBS's scene-switch settings or diagnose a local OBS freeze.
Verify the fix with repeatable scene changes
Once a setting appears to help, verify it with several return trips to the same scene rather than stopping at the first successful switch. Use a repeatable sequence: start the clip, switch away, wait a consistent interval, then return. Check whether it resumes, restarts, reloads with a gap, or still holds a frame. The aim is not to prove a permanent guarantee but to establish whether the change reliably affects the symptom in your own setup.
Keep a small troubleshooting note with the OBS version, operating system, file format, the relevant source properties, and what happened to audio and preview. If the issue returns, capture an OBS log from the affected session and note the approximate time. This is practical evidence to share when seeking support; it does not by itself identify a cause.
After changing one setting, restore the original value if the result is worse or unrelated. That gives you a clean baseline and avoids ending up with several undocumented changes. If the preview is normal but the audience still reports a problem, describe that distinction when you investigate further rather than calling it an OBS scene-switch freeze without evidence.
If you are separately planning an always-on channel, the comparison of a VPS and cloud streaming service can help frame the operational trade-offs. It is a different decision from fixing a local Media Source: first establish whether you need to operate OBS on your own computer at all, then choose a workflow that matches the channel.
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 pre-recorded video freeze when I switch scenes in OBS?
Several behaviours can look like a freeze: the source may restart on activation, reload after being closed while inactive, or stall as part of broader OBS choppiness. Check the preview and the source properties to identify which one matches before changing settings.
Should I turn off “Restart playback when source becomes active”?
Test turning it off if the clip starts from the beginning whenever you return to its scene and you want it to continue from its earlier position. It is not a universal fix for a blank reload interval, a held frame, or stutter across the whole output.
Does YouTube cause OBS to freeze when I change scenes?
The documented Media Source behaviour concerns OBS's local source and its visibility in a scene; the cited OBS performance guidance concerns OBS rendering and encoding load. Those sources do not establish YouTube as the cause of scene-switch behaviour, so check what the OBS preview does before assigning fault to the destination.
Should I switch from Media Source to VLC Video?
Consider VLC Video when you need playlist or extended-media support and can meet its VLC installation requirement. Compare it under the same scene-switch test, because OBS documentation does not promise that changing source type will cure a freeze.