To change sermon videos without deliberately ending the church’s YouTube live event, keep the encoder connected and change what it sends from inside OBS. A prepared scene for each video makes that distinction easier to operate: switch the programme output, not the live event or encoder session.
That reduces avoidable stoppages, but it cannot guarantee a seamless transition. A scene switch, file playback issue, computer problem or network failure can still interrupt what viewers receive, so prepare and rehearse the change and watch the outgoing picture and sound.
Keep the existing event and encoder connected
Think of the broadcast as two separate things: the YouTube event that receives the stream, and the changing picture and sound produced by your encoder. OBS sends its current output to YouTube using the event’s stream URL and stream key. Changing the sermon clip is a change to that output; it does not by itself require creating a new event or reconnecting the encoder.
Before the service, open the scheduled event in YouTube Live Control Room and confirm which event the church intends to use. In OBS, confirm that the correct stream destination and key are already configured. YouTube describes the key as the credential that lets an encoder send a feed to YouTube. Treat it accordingly: do not display it on screen, share it casually or change it as part of a routine video switch. See YouTube’s live stream settings guidance for how the key and other event settings work.
During the broadcast, leave OBS streaming and leave the event open while the operator changes scenes. Do not press Stop Streaming in OBS, and do not choose End Stream in Live Control Room simply because one sermon video has finished. Those controls stop the broadcast rather than select its next piece of content.
This is the central operational distinction: a scene or source change changes the encoder’s programme; stopping the encoder or ending the event changes the status of the broadcast. YouTube’s encoder streaming instructions describe connecting an encoder to send a feed and ending the stream separately. The suggested workflow follows those roles; it is not a promise that every transition, computer or connection will behave without a visible interruption.
If your church repeats services, keep a short written note of the event name, the OBS profile and the person responsible for the stream key. That helps a substitute operator avoid starting a different event or changing credentials while trying to solve a simple playback problem. A separate guide to using a stream key for a recurring church broadcast can help you document that part of the setup.
Prepare sermon scenes and media sources in OBS
Do the preparation before viewers are waiting. In OBS, a scene is a prepared layout, and sources are the video, audio and other items placed in that layout. You can therefore create a scene for each sermon clip, or keep one scene and replace or change the media source. The first arrangement usually makes a live cue more obvious; the second can make a crowded scene list shorter but requires careful checking of the selected file.
For a service with an opening loop, a sermon and a closing message, create clearly named scenes such as “Opening”, “Sermon – morning” and “Closing”. Add the intended video file to each dedicated scene as a Media Source. If the church uses the same title slide, camera window or lower-third graphic with every clip, include those elements in each scene or arrange shared sources deliberately. Then make sure the resulting output has the intended framing and does not cover important text.
OBS Media Source supports common local video formats and includes controls for playback behaviour. Depending on the clip and your plan, settings include restarting playback when a source becomes active, looping, hiding a source when playback ends and closing a file while inactive. These settings affect what happens when a source is shown or reaches the end, so test the actual file rather than assuming the default behaviour suits the service. OBS explains the available controls in its Media Sources documentation.
Decide what should happen if a video ends early. A closing slide, a camera shot of the pulpit or a holding screen can be more useful than an unexpected blank frame. If a clip should play only once, check what OBS displays after it finishes. If it should repeat while the pastor is speaking, test the loop and confirm that the repeat point is acceptable. Do not discover either behaviour during the service.
Check every file path on the computer that will run OBS. A file that played on the media volunteer’s laptop may not exist at the same location on the church’s streaming computer. Put the service files in a known folder, use that machine to open each one, and avoid renaming or moving them after setup. If the church uses a playlist workflow instead of manually selected scenes, this guide to skipping videos that fail to open in an FFmpeg playlist covers a different kind of fallback; it does not replace testing OBS sources used in a live service.
| Approach | Useful when | Operator check |
|---|---|---|
| A dedicated scene for each sermon video | Clips need different layouts, or the volunteer benefits from an obvious named cue | Confirm the scene name, selected file, framing and audio before service |
| One scene with a changing media source | The layout stays the same and the operator is comfortable changing files | Confirm the newly selected file and its playback state at every change |
There is no universal winner. Choose the method the actual volunteer can operate reliably under service conditions, then keep scene names and source labels unambiguous. A scene called “Scene 4” is harder to cue than “Sermon – guest speaker”. OBS also supports scene-switch hotkeys, which can be assigned to an ordinary keyboard; a dedicated macro keypad is optional. Read the OBS Studio overview for its scene and hotkey concepts.
Switch scenes without stopping the encoder
Write the sequence down and rehearse it in the same order the service will use. A straightforward run-through is: start the YouTube event and OBS output; confirm the opening scene is visible in the Live Control Room preview; cue the sermon scene in OBS; confirm the sermon is visible and audible; then cue the next prepared scene when required. The operator should know which control changes the scene and which control stops the stream.
At the transition, select the prepared scene in OBS or use the rehearsed hotkey. Keep the streaming indicator active and do not stop the encoder. If the next scene contains a Media Source that is set to restart on activation, OBS can begin the clip from its start when that scene becomes active. If instead the source is being changed in place, select the new file and use the playback control you tested. Do not improvise with an unfamiliar setting while the broadcast is live.
A brief fade or other transition can make the change feel intentional, but it does not remove the need to check the output. The encoder still has to render and send the resulting picture and audio, and the file must play correctly. Rehearsal reduces avoidable mistakes such as selecting the wrong scene, leaving an old clip paused or muting its audio; it cannot prevent every technical interruption.
If a second person is available, give one volunteer the role of cueing OBS and another the role of watching YouTube’s preview and listening to the programme. For a small church with one operator, pause after each switch and check the preview before moving to another task. Avoid putting the scene controls, event-ending controls and stream key in a loose checklist that invites an accidental click; identify them clearly and keep the key private.
Check playback, audio and scene transitions
A transition is not complete just because the scene name changed. Look at the audience-facing output in OBS and the preview in Live Control Room. Confirm that the expected clip appears, the first frame is not black, the image is correctly sized, and any overlay or title remains legible. If you use a portrait recording in a landscape programme, check the framing before service; this OBS source-scaling guide for mixed portrait and landscape video explains the layout issue in more detail.
Listen to the output as well as watching it. A video source may have its own audio, while the scene may also include a microphone or music source. Check that the clip is not unexpectedly silent, that the microphone is not accidentally louder than the video, and that the audio meter responds as expected. If the church uses speakers in the room, avoid judging the stream mix only by what is audible in the sanctuary; use headphones or another suitable monitoring path to hear what OBS is sending.
Test the beginning, middle and end of each file before the service. Confirm that the clip starts where intended, that there is no unwanted long pause, and that the end behaviour matches the plan. Then rehearse the switch in both directions if the service may return from a video to a live camera or slide. When OBS is set to close a file while inactive, check that it reopens properly when the scene becomes active again.
Do not treat a green or active encoder indicator as proof that the audience can see and hear the intended programme. The indicator says something about OBS sending; the preview and a separate viewer check help establish what is arriving at YouTube. YouTube’s live streaming tips recommend checking the preview and the channel or watch page, along with stream quality. Have a trusted person view the public or unlisted watch page on another device when practical, and ask them to confirm picture and sound.
Monitor the YouTube Live Control Room
Keep Live Control Room available to the person monitoring the broadcast. Before the service begins, check that the correct event is open and that its preview shows the expected output. During the service, watch for a missing preview, a frozen picture or a quality warning, and compare any issue with what OBS shows locally. That comparison helps separate a scene or source problem from a problem in the connection between encoder and YouTube.
A preview delay is not the same as an event ending. Give the page time to update, but do not assume that an apparently unchanged preview means the next scene failed. Check OBS’s programme output, the Media Source playback controls and the audio meters, then ask the separate viewer what is appearing on the watch page. Make one change at a time so that you can tell whether the problem was the source, the scene or the event connection.
Agree on a simple escalation order before service. The scene operator checks the selected scene and file; the monitor checks the YouTube preview and watch page; then the person responsible for the computer or network investigates a broader encoder or connection warning. Do not reset the stream key or create another event as an early response to a missing video source. Those actions can change the destination without fixing the actual file or playback issue.
A backup encoder or alternate programme can be useful for a church that has rehearsed it, but failover is a separate recovery plan, not a scene-switch method. YouTube recommends testing encoder failover by interrupting the primary encoder and confirming that the player rolls over to the backup. Schedule that test outside worship and follow the current instructions in the Live Control Room. Do not unplug a cable or stop the primary encoder during a service merely to change sermon videos.
Troubleshoot a stalled or missing source
If the new scene appears but the video is black, first check the selected scene and whether its Media Source points to the intended file. Verify that the file is accessible on the streaming computer and that playback is not paused or already at the end. Use the restart control if that is part of the rehearsed process. If the source is missing, restore the file path or switch to the tested holding scene while the operator diagnoses it.
If the picture plays but there is no sound, check whether the clip contains audio, whether its source is muted, and whether the scene’s audio routing and meters respond. Check the OBS output and, if available, the audience-facing watch page. Keep the troubleshooting sequence narrow: correcting an audio mute is more relevant than ending and restarting the YouTube event.
If OBS itself stops responding or the encoder loses its connection, the problem is no longer just a video change. Follow the church’s recovery plan and the current Live Control Room status. Do not promise viewers that YouTube will keep the stream live if the encoder stops sending; a stream interruption may be visible, and the next safe action depends on the event state and what OBS reports. A recovery note should say who can restart OBS, who can check the event and who can communicate with viewers.
For a recurring channel, record which scenes were used and what was checked after any incident. If one clip repeatedly fails, test its file and playback settings offline and replace or convert it before the next service rather than relying on a live workaround. For continuous prerecorded rotations beyond a single service, compare that workflow with a guide to rotating prerecorded videos on YouTube Live with a Raspberry Pi; it describes a different operating arrangement, not a guarantee against interruptions.
End the event only when the broadcast is finished
When the service and any planned closing content are complete, end the YouTube event deliberately. The operator should follow the current Live Control Room ending steps and stop sending content from the encoder as appropriate. This is when the stop controls belong in the workflow, rather than when one sermon file ends and another should begin.
After the event, verify that the broadcast has ended as intended and that the archive is available if the church expects one. YouTube states that streams shorter than 12 hours are automatically archived; the guidance does not mean every situation will produce an archive, so check the event and current help information. Keep the recording or original sermon files independently if they matter to the church.
A short post-service note can capture whether scene changes worked, whether an audio issue occurred and which source settings need attention. Make the fix before the next service, then rehearse the updated sequence. This separates a controlled end-of-service shutdown from the avoidable stoppage the workflow is meant to reduce.
When the church’s recurring pain is keeping a prerecorded programme running without leaving a computer on to manage each change, StreamNeo can take the uploaded file and run it as a YouTube live stream, removing that particular manual handoff; it does not replace checking that the video and channel are ready.
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
How do I change a video during a YouTube live stream without ending it?
Keep OBS streaming to the same YouTube event and select a prepared scene with the next video, or change the media source using the controls you rehearsed. Check the Live Control Room preview and audio after the switch. Do not press Stop Streaming or End Stream for a routine content change.
Does switching an OBS scene guarantee viewers will not see an interruption?
No. A prepared scene and a connected encoder reduce avoidable stoppages, but playback, rendering, computer or network problems can still affect the output. Rehearse and monitor the transition rather than treating it as guaranteed.
Should we create a scene for each sermon video?
A dedicated scene is often easier to cue when clips have different layouts or the operator benefits from clearly named choices. A single scene with a changing source can suit a consistent layout, provided the operator checks the file and playback state every time. Test the method with the volunteer who will run the service.
When should we stop the encoder and end the event?
End the event after the service and any planned closing content are finished, following YouTube’s current Live Control Room steps. A sermon video ending or changing is not, by itself, a reason to stop sending the encoder feed.