OBS Auto Transitions When a Video Ends: Workflow Guide

Why Automate the Moment a Video Ends

Every live show that plays pre-recorded material eventually hits the same moment: the video ends, and someone has to switch scenes. When a human does it, the result is either a late cut, which leaves two seconds of frozen frame and awkward silence, or an early cut, which clips the last line of the video. Neither looks professional.

Automation removes that hesitation. When the transition fires from the media source itself, the switch happens on the exact frame you specified, every single time, whether you are at the keyboard or not. That consistency compounds: intros land cleaner, ad breaks start on cue, and replays roll without a producer hovering over a hotkey.

There is also a quieter benefit. Once transitions are event-driven, your attention is free during playback. You can prep the next guest, adjust a camera, answer a chat question, or simply breathe. The show stops being a sequence of manual interventions and starts behaving like a system.

This guide covers four working approaches to firing an OBS scene change when a video finishes, along with the timing details, failure modes, and testing habits that separate a demo from something you trust on air.

The Core Problem: Media Sources Do Not Announce Completion

OBS treats a media source as a self-contained playback object. In its properties you can set behaviors for when playback ends: restart the file, hold the last frame, or show nothing. You can loop, you can restart when the source becomes active, and you can close the file when inactive. What you cannot do natively is attach a scene change to the end of playback.

That gap is why so many streamers still use hotkeys for something that ought to be automatic. The workaround is always the same in principle: observe the media source state from outside, then tell OBS to change scenes. The four methods below differ only in where that observation happens.

Choose based on how much control you want and how much machinery you are willing to maintain:

• WebSocket control for maximum flexibility and external logic
• In-app scripting for a self-contained setup with no extra software
• Audio-based proxy triggers for quick wins with existing hardware
• Plugins for a no-code solution you can configure in minutes

Method One: Event-Driven Control Through the WebSocket API

Since OBS 28, the WebSocket server ships inside OBS itself. Enable it under Tools, then WebSocket Server Settings. Set a password, note the port, and decide whether you need it reachable from another machine on your network.

What the API Gives You

The WebSocket protocol exposes request types for nearly everything the interface can do, including scene switching, transition selection, source property changes, and media control. It also broadcasts events, which is where the interesting part lives. You can subscribe to playback events and scene change events, and you can query the current playback cursor position and duration at any time.

Polling Playback Position

The most portable pattern is a short polling loop. Ask for the media source status every few hundred milliseconds and compute remaining time:

remaining = mediaDuration - mediaCursor
if remaining <= transitionLead and not fired:
    switch_scene(target_scene)
    fired = True

The variable transitionLead is the key value. If your transition takes 500 milliseconds, you want to start it half a second before the video ends so the cut lands on the final beat rather than after it. Set the lead to your transition duration plus any encoder latency you have measured.

Reset the fired flag whenever the source restarts, or use a per-playback identifier so a looping video does not trigger a scene change on every pass.

Subscribing Instead of Polling

Polling is simple and robust, but it costs a request every few hundred milliseconds. If you prefer event-driven logic, subscribe to the media input playback events and act when the state reads as ended. The tradeoff is real: events tell you the video is over, which is too late for a smooth crossfade unless you deliberately delay the outgoing scene with a transition that holds the last frame.

The pragmatic hybrid is to poll for the approach and subscribe for the failure case. Polling catches the timing; the event handler catches the situation where the file ends unexpectedly, so you can still push the show forward instead of leaving a frozen frame on screen.

Firing the Transition

Switching scenes is a single request. Choose the transition first, then switch:

• Set the program scene to your target
• Optionally set the active transition and its duration beforehand
• Optionally trigger a studio mode transition if you are previewing

Wrapping these three calls into one function makes the logic reusable across every video source in your production. If you run several shows with the same structure, put the function in a shared module and keep only the scene names in configuration.

Method Two: Scripting Inside OBS with Lua or Python

If you would rather not run a second process, OBS has a scripting interface under Tools, Scripts. Lua is available on every platform; Python support depends on your build.

Reading Media State from a Script

OBS exposes media source state through the source API, including a state value that reports ended playback. The reliable pattern in a script is a timer callback: register a function that runs a few times per second, read the state of your video source, and compare it against the last known state.

last_state = nil
-- register a tick function that runs every 250 ms
function tick()
  local state = get_media_state(video_source)
  if last_state ~= ENDED and state == ENDED then
    switch_to_scene(live_scene)
  end
  last_state = state
end

Note the edge detection. Without it, the scene switches repeatedly while the state remains ended, which produces a visible stutter and floods your logs.

Why Scripts Are Good in Some Studios and Bad in Others

The upside is a single application, a single config folder, and no network surface to secure. The downside is debuggability. When a script misbehaves, your only signal is often the OBS log, and an unhandled error can leave the scene stuck on the wrong source.

Scripts are excellent for producers who want an appliance-style setup and are comfortable reading logs when something breaks. They are a poor fit if you want to reuse the same transition logic in other tools, or if multiple operators need to understand and edit the behavior.

Method Three: Audio-Based Proxy Triggers

Sometimes you do not need to know that the video ended; you need to know that the room went quiet. Silence detection is a legitimate trigger when your video has a continuous audio bed that stops cleanly at the end.

The classic implementation routes the media source audio to a virtual audio device, then uses a tool that watches for level drop below a threshold for a set duration. When the level stays low long enough, it fires the scene change.

Practical Considerations

• Set the threshold above your noise floor but below quiet dialogue.
• Require a hold time of at least 700 milliseconds so a dramatic pause does not fire a transition mid-sentence.
• Mute the proxy route so your stream does not hear the monitoring copy.
• Expect this method to be unreliable with music that fades out slowly.

Audio triggers shine in one specific case: when the same operator also runs lighting or a hardware switcher and wants a single signal that means the segment is finished. In every other case, media state is the better signal because it is precise rather than inferential. A silence detector guesses; a media state read knows.

Method Four: Plugins That Add Event Logic

The fastest route to a working automatic transition is a scene-switching plugin. Advanced Scene Switcher is the best-known option and handles a large share of automation needs, including media-finished conditions and timed sequences. Other useful additions include animation plugins that make transitions look deliberate rather than abrupt, and macro or companion apps that combine OBS control with other devices.

When a Plugin Is the Right Answer

Pick the plugin route if:

• You want results in fifteen minutes.
• You are uncomfortable maintaining code.
• Your logic is simple: media ends, go to scene X, then wait and go to scene Y.
• You need someone else to be able to operate the setup.

Pick code if your logic branches, if it depends on external data, or if you want the same behavior replicated across several machines and shows. A useful middle path is to build the first version with a plugin, run it for a week, and only move to code when you hit a condition the plugin cannot express.

Timing Details That Decide Whether It Looks Clean

Automation that fires is not the same as automation that looks good. These details do most of the work.

Transition lead. Start the transition before the media ends by the duration of the transition itself. A 300-millisecond crossfade needs a 300-millisecond lead. Getting this wrong is the single most common reason an otherwise correct automation looks sloppy.

Hold the last frame. If you cannot start early, set the media source to hold the last frame instead of going black. A held frame dissolves into your live camera far more gracefully than a hard cut from black.

Audio crossfade. Video transitions and audio transitions are separate problems. Route media audio through its own fader and fade it out over the same window, otherwise you get a click or an abrupt drop that viewers notice more than the picture change.

Buffer for encode lag. Your stream is delayed relative to your local machine. If you are reacting to a remote signal, account for the offset or your timing will drift by hundreds of milliseconds.

Scene item order. Build your target scene completely before going live. A scene that reorders layers on load, or that hides a source until a filter runs, will visibly pop during the transition.

A Complete Workflow: Pre-Recorded Intro into Live Camera

1. Create a scene named Intro Video with a single media source, plus a scene named Live Camera that already contains your camera and microphone inputs.
2. In the media source properties, disable looping, hold the last frame, and restart playback when the source becomes active.
3. Enable the WebSocket server and connect your control layer.
4. Start a polling loop that reads duration and cursor for the intro source.
5. Define the lead time as the transition duration plus 100 milliseconds of safety.
6. When the threshold is crossed, set the transition, switch to Live Camera, and unmute the microphone input.
7. Reset your fired flag when the Intro Video scene becomes active again.
8. Add a manual override hotkey that forces the Live Camera scene, so a human can always intervene.

Test this path end to end at least three times before a real show. The third run is where you find the mistake, not the first. Between runs, restart OBS completely, because some state survives a scene change but not an application restart.

Fallbacks and Failure Recovery

Automation fails in predictable ways. Plan for each one.

• Control layer disconnects. Keep a hotkey bound. Never rely solely on a network connection during a paid show.
• Video file missing or corrupted. Validate media paths in a pre-show checklist, and give the media source an alternative scene to fall back on.
• Script error. Wrap logic in error handling and log every state change so you can reconstruct what happened.
• Repeated firing. Always use edge detection or a fired flag, never a bare state comparison.
• Stuck scene. If your automation fails mid-show, the manual override is the only thing standing between a glitch and a dead stream.
• Silent failure. Automation that quietly stops working is worse than automation that errors loudly. Log a heartbeat so you notice.

A useful rule: any automation that changes what viewers see should have a manual equivalent within one keypress. That rule has saved more broadcasts than any amount of clever scripting.

Testing and Measurement

You cannot improve timing you do not measure. Build a small test harness:

• Record the timestamp when the media ends according to the file metadata.
• Record the timestamp when the scene change actually occurs.
• Repeat ten times and look at the spread, not just the average.

If the spread is under 100 milliseconds, your automation is tighter than a human operator and you can stop worrying about it. If the spread is 400 milliseconds or more, find the source: polling interval, transition duration, network round trip, or encoder buffering. Change one variable at a time, otherwise you will fix the symptom and miss the cause.

Also count manual interventions per show. That number is the honest score of your automation, and it should trend toward zero. If it does not, your automation is doing something different from what you assumed.

Common Mistakes to Avoid

Polling too slowly. A one-second interval is fine for a slow fade and terrible for a hard cut. Match your interval to your transition duration, roughly one tenth of it.

Ignoring the transition duration. Starting the switch exactly when the video ends guarantees a visible overlap or a gap. Always lead by the transition length.

Forgetting to reset state. A looping video with a naive trigger will fire on every loop and eventually fire during a live segment.

Mixing audio and video logic. Unmuting the microphone in the same call that changes the scene creates races. Sequence them deliberately and test the order.

Building scenes at runtime. Pre-build everything, then toggle visibility. Runtime construction is where pops and missing sources come from.

Trusting one method completely. Layer a plugin condition and a manual hotkey if the show matters.

Skipping the log. When something breaks during a live show, logs are the only evidence you have afterward.

Never rehearsing the failure. Run a drill where you kill the control layer mid-show and confirm the manual override works.

FAQ

Can OBS fire a scene change natively when a video ends?
Not through the media source itself. You need the WebSocket API, a script, an audio-based trigger, or a plugin.

Which method should most people start with?
A scene-switching plugin. It covers the common case in minutes and is easy to hand off to another operator.

How early should the transition start?
By the length of the transition plus a small safety margin, typically 100 to 400 milliseconds depending on your setup.

What if my video should hold its last frame?
Set the media source to hold the last frame, then dissolve into the next scene. It hides small timing errors and gives you room to correct drift.

Can I automate several videos in a sequence?
Yes. Chain scenes in order and let each one trigger the next, but add a supervisor condition so a failure in the middle does not stall the whole chain.

Will this work for a pre-recorded show with no live operator?
Yes, and this is where automation pays off most. Without it, a pre-recorded show still needs someone to press keys at the right moment.

Does automation add latency?
The scene change itself is effectively instant. Perceived latency comes from transition duration and encoder buffering, both of which are configurable.

How do I stop a transition from firing twice?
Use edge detection on state changes, or a fired flag that resets only when the source restarts. Bare state comparisons are the usual culprit.

Do I need studio mode?
No, but studio mode makes rehearsal easier because you can preview the next scene before switching. If you already use it, your automation should target the same transition path you use manually.