If OBS is using too much CPU while a church service loops, first find out whether the load comes from encoding, media decoding or the scene itself. The right fix depends on which job is consuming resources; changing a random setting can trade away picture quality without solving the cause.
For one prerecorded service, an OBS Media Source can loop a file. For a playlist, OBS documents VLC Video with Loop Playlist enabled. Neither choice by itself guarantees lower CPU use: looping and encoding are separate jobs, and your results depend on the computer, the media and the scene.
Identify when OBS CPU usage is the problem
Open OBS’s Stats panel while the stream is running. Look at CPU usage alongside rendering lag and encoding lag. CPU use tells you that the processor is busy, but the lag counters help narrow down what is failing: rendering lag points towards the scene being too demanding to compose, while encoding lag suggests OBS is struggling to encode frames in time. A high CPU reading on its own is not proof that the stream is unhealthy.
Check what viewers actually see and hear as well. Look for dropped or irregular motion, audio that falls out of sync, a delayed scene change or a stream that stops progressing. A loop can appear to play normally in the OBS preview while the output has a different problem, so review the YouTube stream from another device if practical. You can also use the pre-stream checklist to make sure the rest of the broadcast is behaving as expected.
Start with a controlled comparison rather than changing several settings at once. Note the current Stats readings and observe a representative section of the service. If practical, make a short test with the loop source disabled, then another with the loop enabled, keeping the scene and output settings unchanged. Compare what changes. Do not treat a result from one computer or one service file as a universal benchmark.
If the computer is already near its limit before you go live, do not assume a graphics card purchase or a new encoder preset is the first answer. Identify which part of the workload is responsible, and check compatibility before buying anything. OBS’s system requirements guidance notes that requirements vary with the encoder, resolution, frame rate and scene complexity.
Check encoding, decoding and scene load
Think of the broadcast as three related jobs. OBS decodes the source video so it can play; it renders the scene by combining the video and other visible elements; then it encodes the finished output for YouTube. Any one of these may contribute to the load, and an overloaded computer can have more than one cause at the same time.
To check encoding, open Settings → Output and note whether the encoder is x264 or a hardware option. If x264 is selected and encoding lag appears alongside heavy CPU use, software encoding is a plausible bottleneck. If the encoder is already hardware-based, investigate rendering and decoding rather than expecting a second encoder change to fix everything.
To check media decoding, compare a test with the video source playing against one with it stopped. A large or demanding video file can take work to decode even when the scene contains no elaborate graphics. To check scene load, disable or remove elements one at a time—such as a browser source, animated overlay or duplicate capture—and see whether rendering lag changes. Keep a note of each test so you can reverse it if the picture or sound worsens.
A useful first comparison is:
| What you observe | Likely place to investigate | First controlled test |
|---|---|---|
| Encoding lag while x264 is selected | Video output encoding | Test a supported hardware encoder, then inspect quality |
| Rendering lag that changes with scene elements | Scene composition or sources | Disable one costly or unnecessary source |
| Load that rises when the video plays | Media decoding or video workload | Test hardware decoding if available; check media size |
| High CPU without visible lag | Not necessarily a stream fault | Monitor the output and compare under the same conditions |
These clues are not a diagnosis by themselves. For example, a detailed animated scene may increase rendering work while also adding work to encode the final picture. Make one change at a time, then review the output at the same resolution and frame rate. OBS’s encoding performance troubleshooting discusses source complexity, scene composition and media sizing.
Use Media Source for one looping video
For a single prerecorded service file, add an OBS Media Source, select the file and enable Loop in its properties. This is the straightforward arrangement when the same service, prayer or devotional video should repeat continuously. The Media Source has playback controls for its own file; it does not replace the encoder or take care of the entire broadcast.
OBS lists supported media formats and Media Source properties in its Media Sources documentation. If a file does not play correctly, check its format and audio behaviour before rebuilding the scene. Test from the beginning and through the point where the loop returns to the start. Confirm that the ending does not leave an unwanted blank frame, sudden volume jump or gap that is distracting for a congregation watching remotely.
Check how the source behaves when it is hidden or when you switch scenes. A service video may stop, continue or restart depending on the source configuration and the transitions in your scene. Test the exact scene changes you intend to use rather than assuming that a loop keeps its place. If you need a continuous background while announcements or lyrics appear, verify the media and overlays together.
Keep the audio path in mind. If the prerecorded service contains speech, singing or instrumental music, make sure the Media Source audio is not doubled by another capture of desktop audio. That duplicate can create echo or extra mixing work even if it is not the main CPU bottleneck. If a change fixes video performance but affects sound, return to the known-good state and isolate the audio source separately.
A single Media Source is generally easier to diagnose than a playlist, but it is not inherently a lighter workload in every case. The video still has to be decoded, composited and encoded. For more on moving from a prerecorded file to a continuous channel, see setting up an always-on channel with prerecorded videos.
Use VLC Video for a looping playlist
If you need several services or segments to play in sequence, OBS offers a VLC Video source with a playlist and a Loop Playlist option. This is different from enabling Loop on one Media Source: the playlist is useful when the channel needs to rotate through multiple files without manually changing the scene each time. OBS requires VLC for this source, so confirm the matching VLC installation is present if the source is unavailable.
A playlist brings its own checks. Test every item, not just the first one. Confirm that audio is present, the aspect ratio is acceptable and transitions between items do not show a black frame or an abrupt change in loudness. Mixed file formats, sizes or frame rates can behave differently; a clean hand-off between two short test clips does not establish that every long service file will behave the same way.
Use VLC Video only when the playlist feature is useful enough to justify its extra dependency and testing. If your channel repeats one file, the Media Source is simpler to maintain. If the playlist is part of a wider rotation plan, you may find how to schedule videos in a YouTube Live playlist useful for thinking through sequencing, though the OBS source setup remains a separate task.
Remember that VLC Video solves a playback and playlist requirement, not an encoding bottleneck. If Stats shows encoding lag while x264 is busy, swapping a single Media Source for VLC Video is unlikely to address the underlying encoder workload. Keep the source test separate from encoder tests so the cause remains clear.
Try hardware decoding when available
OBS Media Source includes Use hardware decoding when available. This option can shift supported media decoding work to the GPU, but it is conditional: the file format, graphics hardware and software support all matter. If the option is unavailable or does not change your test, do not infer that the computer is broken; its current configuration may not support that decoding path.
Enable it on the Media Source and test the actual service file. Watch the video and listen for sync, glitches or unexpected playback behaviour, including when the file loops. Compare Stats readings with the option off and on under the same scene and output conditions. A change in CPU use is only useful if the stream remains visually and audibly correct.
Hardware decoding and hardware encoding are different settings for different stages of the work. Decoding is the reading and playback of the source media; encoding is the creation of the outgoing live video. Enabling hardware decoding does not automatically change x264, and selecting a hardware encoder does not guarantee that the source file is decoded on the GPU. Keep the distinction in mind when deciding which setting to test.
If other scene elements are already demanding the GPU, shifting decoding work there may not help overall. The relevant question is not whether a checkbox sounds faster, but whether the intended file plays correctly and the observed bottleneck improves on this machine. Leave the option disabled if it introduces playback issues or gives no practical benefit.
Test a supported hardware encoder if x264 is the bottleneck
When x264 encoding is the clear source of CPU pressure, test a hardware encoder that your system supports. OBS lists options such as NVIDIA NVENC, AMD AMF and Intel QSV, but the available choices depend on the hardware, operating system, drivers and OBS configuration. Do not assume that a machine has a particular encoder because it has a graphics chip, or that all versions of a product offer the same capability.
OBS Project generally recommends hardware encoding for performance because it moves encoding work from the CPU to a specialised component in the GPU. That is a general direction, not a promise for every PC or stream. OBS also cautions that older hardware encoder generations may produce lower image quality than x264’s default veryfast preset at the same bitrate. Read the current OBS hardware encoding guidance and check the exact hardware and driver support before changing a working setup.
Test using a representative service scene, including the elements viewers actually need to see: lyrics, a lectern or altar, camera feeds, lower-thirds and any announcements. Check the picture at the bitrate and output settings you intend to use. Fine text, movement, dim lighting and detailed backgrounds can reveal quality differences that are not obvious in a static preview. Keep the same scene and resolution while comparing encoders so the test tells you something useful.
If a supported hardware encoder clears encoding lag but makes text or faces harder to read at your chosen settings, the trade-off may not suit the channel. Conversely, a modern supported encoder may suit a computer that cannot spare CPU for x264. There is no universal CPU-saving percentage: performance varies with encoder generation, resolution, frame rate, media and scene complexity.
A new GPU is a conditional option, not the default fix. Consider it only after confirming that x264 is the bottleneck and checking the computer’s available slot and space, power supply, operating system and driver compatibility. OBS’s compatibility examples are not a guarantee for an unknown church computer; verify the exact model and revision before spending money.
Reduce unnecessary source and media demands
Remove sources you no longer use, and avoid keeping duplicate versions in active scenes or collections without a reason. OBS guidance notes that sources can use resources even when they are not currently visible. A scene collection built up over time may contain old camera captures, browser overlays and media sources that appear harmless because they are hidden. Review what is active and remove what the channel does not need.
Browser sources deserve particular attention. A live web page, animated alert or changing graphic can require more work than a static image. If a graphic does not need to update during the service, replace it with an image source where practical. If a browser source must remain, reduce unnecessary instances and check whether its dimensions and content are larger or more complex than the output requires.
Right-size the service media. If a video is much larger than the stream output and OBS must scale it down, the extra detail may create needless work. Use source dimensions appropriate to the intended output, while retaining enough detail for lyrics, text and faces to remain readable. Avoid choosing a smaller resolution merely to lower load if the congregation depends on reading the screen.
If load remains high after simplifying sources, test a lower output resolution or frame rate one at a time. Lower settings can reduce the work required to render and encode frames, but they also affect the detail and smoothness viewers receive. Check a real service scene, not a blank test card: lyrics, camera movement and congregational detail may have different requirements. The right balance is the lowest workload that still presents the service clearly.
Keep notes on the settings that work, including encoder, output resolution, frame rate and source options. That makes it easier to recover after an OBS update or a scene change, and it prevents a future volunteer from guessing at several settings at once. If the computer must stay off or local power and internet interruptions make a PC-based loop hard to maintain, a cloud-run file broadcast can remove the need to leave OBS running on that computer; StreamNeo is for that specific operational pain, not an OBS CPU tuning option.
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
Does looping a church service use more CPU than playing it once?
Looping tells a source to repeat playback; it does not replace the work of decoding, rendering and encoding the stream. The load can change at a loop boundary if the media or scene behaves differently there, so test the full cycle rather than assuming looping itself is the cause.
Should I use Media Source or VLC Video?
Use Media Source for one file and enable Loop. Use VLC Video when you need an OBS playlist with Loop Playlist enabled, and account for VLC as a dependency. Both choices still need testing with your files and output settings.
Will hardware encoding always lower CPU use without changing quality?
No. A supported hardware encoder can reduce CPU encoding work, but support and quality depend on the hardware generation and settings. Compare it with x264 on a representative scene at your intended bitrate, then choose based on both performance and picture quality.
When should I lower resolution or frame rate?
Consider it after checking the encoder, decoding and scene load, and only if the computer still struggles. Test one change at a time and make sure lyrics, faces and other important service details remain clear and smooth enough for viewers.