For a local video played through an OBS Media Source during a YouTube livestream, leave Use hardware decoding when available off to begin with. Turn it on only if playback or CPU behaviour gives you a reason to compare both settings on the machine that will run the channel.
Hardware decoding concerns how OBS plays a supported input file; it does not make the file repeat. The separate Loop property controls repetition, so first get that setting right and confirm the file plays as intended.
What hardware decoding changes
A video file has to be decoded before OBS can display its frames in a scene. With software decoding, that work is handled by the CPU. With hardware decoding, OBS can ask a suitable decoder built into the GPU to handle certain file types. OBS describes the option as using the GPU for certain files when the GPU has the appropriate built-in decoder. That wording matters: the checkbox is an instruction to use a supported path when available, not a guarantee that every file will use it.
This is different from hardware encoding. Decoding is playback of the local source; encoding is the separate job of preparing OBS's outgoing livestream or recording. OBS's hardware encoding guide discusses the latter. If you are investigating stream output or encoder load, do not assume that changing a Media Source's decoding checkbox changes the outgoing encoder. They address different stages, even though both settings use the word “hardware”.
It is also separate from what YouTube does after receiving the stream. YouTube transcodes streams for delivery, as explained in OBS's transcoding documentation. That platform processing does not mean OBS needs to hardware-decode a local file before sending it. The source file still needs to play correctly in your OBS scene, and its playback behaviour is what this setting may affect.
The practical result can vary with the file and the system. If your video already plays smoothly and the machine is behaving normally, there is no benefit to changing a setting just because it mentions the GPU. If there is a playback or resource problem, compare the two states instead of treating one as universally faster.
Start with the default setting
The OBS Media Sources guide lists Use hardware decoding when available as off by default, and it also lists Loop as off by default. The first is optional decoding behaviour; the second determines whether a file starts again after it finishes. Check the controls in your installed version of OBS, since interface labels or defaults may change between versions. The Media Sources guide explains the source properties and the kinds of files it accepts.
Begin with hardware decoding off. This is a cautious baseline, not a claim that software decoding is better. It leaves the documented optional setting unchanged and gives you a clear starting point for troubleshooting. If the scene has been playing cleanly through repeated boundaries, there is no need to alter it merely to optimise an imagined CPU saving.
Before changing decoding, make sure you have the right source. The guidance here is for a local video file added as a Media Source. OBS's Sources Guide describes Media Sources as a way to add audio and video files to a scene. If instead you are capturing a browser, a YouTube webpage, or another live source, you have a different source path and this checkbox may not be relevant to the problem.
A useful starting note can be simple: record which file and scene you are testing, whether the stream is live or being tested locally, and the current checkbox state. You do not need a formal lab or special monitoring tools. You do need to avoid changing several source and output settings at once, because then you will not know which change mattered.
Check whether the file and GPU apply
OBS lists file extensions including .mp4, .ts, .mov, .flv, .mkv, .avi, .gif and .webm for Media Sources, along with common audio formats. That list identifies formats OBS can use as media sources; it does not prove that hardware decoding will be used for every file with one of those extensions. The encoded video inside a container, the GPU decoder and the system's software support all matter. The OBS guide does not provide a complete codec, GPU and driver compatibility matrix, so do not infer compatibility from the filename alone.
If you enable the option and see no change, that may simply mean the file or system did not use a hardware decoder. Conversely, if behaviour changes, note exactly what changed and whether it remains stable at the point where playback returns to the start. The setting is not a general-purpose repair switch for every choppy scene.
The OBS system requirements page also cautions in general that meeting compatible requirements does not by itself guarantee that a particular system can stream or record satisfactorily. Actual demands depend on the encoder, resolution, frame rate and scene complexity. Treat any change in your own CPU or GPU readings as an observation about your setup, not as a result that applies to every channel.
Do not buy a graphics card just to use this checkbox. The researched OBS documentation does not establish a need for a hardware upgrade, nor does it promise that new hardware will solve a file-specific or scene-specific issue. First test the existing machine. If the actual limitation is the computer's capacity to keep OBS and other work running, investigate the whole workload rather than expecting one media property to compensate for it.
For an always-on station, the wider system matters too. A loop can look fine during a brief check but become troublesome when the same scene runs overnight alongside other applications. If OBS is hosted on a virtual machine, the relevant symptoms may concern the host or stream process rather than a local GPU decoder; our guide to running OBS 24/7 on a low-cost VPS in India addresses that separate operating context.
Compare playback with decoding off and on
If you have a reason to investigate, compare the same file in the same scene with the same output conditions. First observe it with decoding off, then enable the setting and repeat the test. Keep the test long enough to see the file reach its end and begin again several times. Do not simultaneously change resolution, scene sources, output encoder, or other performance options; that would make the comparison hard to interpret.
Use practical observations rather than an invented target. Does the picture remain smooth? Does audio remain in step? Does the source restart cleanly at its end? Does the system feel more responsive, or does the change introduce freezes, instability or other visible problems? If your operating system exposes CPU, GPU or decoder activity, you can note those readings, but the published OBS material does not give benchmark values for this loop workload. There is no official number that tells you how much CPU a particular file should save.
A small comparison log is enough:
| What to observe | Decoding off | Decoding on |
|---|---|---|
| Same local file and scene | Record the baseline | Keep all other conditions the same |
| Playback through the end and restart | Note any pause, stutter or audio issue | Check the same points again |
| CPU behaviour | Note whether load is a concern | Compare only on this machine |
| GPU or decoder activity, if visible | Note what the system reports | Check whether activity changes |
| Stability across repeated loops | Keep observations concrete | Retain only if behaviour remains reliable |
The table is not a benchmark form with a pass mark. It is a way to prevent the common mistake of enabling the setting, seeing one brief improvement, and assuming it solved the actual problem. If there is no perceptible difference and no meaningful resource change, the simpler choice is to keep the default off.
For a channel that switches between prepared clips, test the normal transition as well as a single source's own loop. Those are not necessarily the same workflow. The article on switching between podcast episodes in OBS covers scene and episode changes; it should not be confused with whether one Media Source repeats its own file.
Watch CPU behaviour and loop smoothness
CPU load is one possible reason to test decoding, but do not treat it as the only measure of success. Hardware decoding may shift work away from the CPU in a compatible case, but it can also have no observable effect. What matters to you is whether the full playback path remains steady on the actual computer: the source displays properly, sound stays aligned, and the return to the start does not cause a fault that interrupts the channel.
Look for patterns rather than one-off moments. A dropped-looking frame at a loop boundary, a pause when a file restarts, or a gradual change in sync may have causes beyond decoding. Check the source file, scene composition, output settings and other processes if symptoms persist. The setting handles only the input decoding stage; it cannot repair a network connection, an overloaded outgoing encoder or a damaged media file.
If your channel is devotional music or ambience, audio continuity deserves particular attention. A picture that looks acceptable while the audio clicks or falls out of sync is not a successful result. For a broader diagnosis of that symptom on a VPS, see how to fix audio and video going out of sync on a VPS YouTube stream. That issue may have a different cause from the local decoding choice, so keep the checks distinct.
When the system is under pressure, consider the complete scene. A browser capture, animated overlays, filters, and the outgoing encoder can all consume resources independently of a Media Source. OBS's general requirements guidance notes that resolution, frame rate, encoder and scene complexity affect system demand. If you are relying on an encoder setting to reduce CPU work, treat that as a separate test from the Media Source checkbox and avoid attributing its effect to decoding.
Keep the setting that behaves reliably
After a controlled comparison, keep the state that produces reliable playback on the machine you will actually use. If both states behave the same, leaving the optional setting off is reasonable. If enabling it clearly improves a relevant symptom and remains stable through repeated loops, keeping it on is also a practical choice. This is a local decision, not a universal recommendation for every GPU or media file.
If enabling it makes playback less stable, turn it off again and continue checking the source or system. If neither state works, do not keep toggling the checkbox in the hope that it fixes an unrelated bottleneck. Review the file itself, simplify the scene temporarily, and check the outgoing encoder and system load separately. Make one change at a time so that any improvement or regression has an interpretable cause.
For a true 24/7 channel, reliability includes what happens when nobody is watching the preview. Run the chosen configuration under the conditions you expect to use, and check it after transitions and restarts. Do not infer overnight stability solely from a short test. If your concern is whether an interrupted hosted stream resumes after a service restart, that is a separate operational question covered in what happens to a cloud-hosted YouTube stream if the service restarts.
When an always-on channel must continue while your own computer is switched off, StreamNeo removes the need to keep a local OBS playback setup running for that uploaded video, so there is no local Media Source decoding checkbox to tune for that workflow. It is YouTube-only, and the local OBS comparison remains relevant when you are running OBS yourself.
Separate decoding from the Loop option
The Loop property determines whether the Media Source starts again when playback completes. The hardware-decoding property concerns how a compatible input is decoded. Both appear among Media Source properties, but they are independent controls. OBS documents Loop as off by default, so if the file stops at its end, check Loop first rather than enabling decoding and expecting the video to repeat.
To set up a basic local loop, add the media file as a Media Source, enable Loop, and test that the source returns to its beginning. Leave hardware decoding off initially. Once repetition works, evaluate decoding only if you have a playback or resource concern. This order avoids confusing a repeat setting with a processing setting.
OBS also offers a distinct VLC Video source, which requires VLC and can use a playlist with a separate Loop Playlist option. That is useful to understand if you have a playlist workflow, but it is not a prerequisite for looping one local file in a regular Media Source. You do not need to install VLC just to make a single file repeat.
If by “YouTube loop” you mean capturing a YouTube webpage rather than playing a local video, pause before applying this advice. A browser capture is not the same source type as a local Media Source, and its own playback and capture path needs to be diagnosed separately. Confirm what OBS source you have added before changing settings.
For a single local loop, the decision is therefore straightforward: Loop controls repetition; hardware decoding is an optional playback path. Start with the documented defaults, then test the decoding option only when your own symptoms justify it. Keep the choice that stays smooth and stable in your real scene rather than chasing a setting label.
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
Should hardware decoding be enabled for YouTube loops?
Usually, leave Use hardware decoding when available off at first. If the local file plays poorly or CPU behaviour is a concern, compare it on and off with the same file and scene, then keep the reliable result.
Does hardware decoding make an OBS Media Source loop?
No. Loop is the property that makes a local file start again after it finishes. Hardware decoding is a separate option for playback of certain files when the GPU has a suitable decoder.
Why did enabling hardware decoding make no difference?
The file or GPU may not use a supported hardware-decoding path, or the playback issue may have another cause. OBS's guide does not provide a full codec and GPU compatibility matrix, so check the actual playback behaviour rather than assuming the extension guarantees support.
Is this the same as hardware encoding or YouTube transcoding?
No. Media Source decoding is input playback, while hardware encoding concerns the outgoing stream or recording. YouTube transcoding is its own delivery process and does not determine whether OBS should decode your local file with the GPU.