In OBS Studio on Windows, process priority is under Settings > Advanced > General > Process Priority. Start with Normal; if evidence points to CPU scheduling contention, test Above Normal carefully and compare results.
Priority can influence how Windows schedules OBS relative to other processes, but it cannot fix every CPU, encoder, network or source problem. It is a tuning choice, not a promise of continuous broadcasting or a way to prevent every dropped frame.
Find Process Priority in OBS on Windows
Open OBS and select Settings. In the settings window, choose Advanced, then look in General for Process Priority. In the current English interface, the dropdown contains High, Above Normal, Normal, Below Normal and Idle. OBS's current interface labels confirm those names.
Choose the setting in OBS rather than trying to change the process from a separate Windows utility. The setting is associated with OBS's process and is easier to test consistently from the application. After changing it, apply the change if the dialog offers that control, close settings and verify the selected value when you return. If your interface differs, check that you are in the Advanced settings rather than the Output page, where encoder and bitrate choices live.
This setting is for the Windows version of OBS. It is not a YouTube Studio control and does not change your stream key, video file, stream resolution or the priority YouTube gives to your broadcast. If your immediate problem is that the live preview shows no audio, a process priority change is unlikely to help; a more targeted checklist is available for audio checks on a 24/7 music channel.
Before adjusting it on a machine that already runs a channel, write down the current selection. Also note whether you launch OBS directly or through a shortcut, whether a scheduled task starts it, and what is running alongside it. Those details matter if you need to revert or reproduce a test after a restart.
What the priority levels mean
Windows priority is one input into scheduling work among processes. Raising OBS's process priority can make it more likely to receive CPU time ahead of lower-priority work when there is contention. It does not give OBS a separate processor, make the encoder faster, or increase the internet connection's capacity. When there is no contention, changing priority may make no visible difference.
The choices are relative levels, not settings for stream quality. Normal is the standard starting point. Below Normal and Idle make OBS less favoured when other work competes for CPU; they are not sensible troubleshooting defaults for an always-on stream unless you have a specific reason to defer OBS. Above Normal raises its scheduling precedence modestly relative to Normal. High is a stronger change and is not an established best setting for a prerecorded 24/7 broadcast. Do not jump to it as a routine fix.
| OBS priority | Practical interpretation | A cautious use |
|---|---|---|
| Idle | OBS is strongly deprioritised against other work | Avoid for an active broadcast unless you deliberately want other tasks to take precedence |
| Below Normal | OBS is less favoured than Normal under contention | Usually not a troubleshooting starting point for a live channel |
| Normal | Standard balance with other work | Use first and establish a baseline |
| Above Normal | OBS is favoured over Normal-priority work when contention exists | Test only when observations suggest scheduling competition |
| High | A substantially elevated priority choice | Do not assume it is best; there is no basis here to recommend it for this use |
The table describes the intent of the levels, not a guarantee about a particular Windows version, CPU, encoder or workload. OBS's older advanced settings help says Above Normal may sometimes help CPU-intensive capture and encoding. That page is legacy guidance, so treat it as context rather than a tailored recommendation for a long prerecorded stream. A measured test on your own system is more useful than copying a setting from a screenshot.
Start at Normal and look for contention
Normal is the useful baseline because it keeps OBS in the ordinary scheduling mix and gives you a comparison point. If a stream is already stable at Normal, do not change priority simply because an always-on channel sounds demanding. A change without a suspected problem makes it harder to know what caused a later improvement or failure.
Look for a pattern that plausibly involves CPU scheduling. Does OBS report rendering or encoding lag while another application is doing a CPU-heavy task, such as a video export or a large file operation? Does the stream behave acceptably when the machine is otherwise quiet, then deteriorate when a predictable competing workload begins? Is the CPU near saturation at the same time as the OBS statistics worsen? A single high CPU reading is not enough; relate it to the time and type of missed work.
OBS's own statistics and logs can help establish what is happening. Record the count or trend for rendering lag, encoding lag and dropped frames, and note the time. Keep the distinction clear: rendering and encoding lag point toward work OBS cannot complete on time, while network-related dropped frames suggest a different path to investigate. Names and counters can vary with OBS version, so consult the current OBS interface and log rather than treating one label as a complete diagnosis.
Keep other variables steady while you establish the baseline. Do not simultaneously change resolution, frame rate, encoder preset, bitrate, source layout and process priority. If the channel uses a 720p loop, for example, preserve its existing settings during the test; the 720p OBS setup for an India-based loop stream is a separate set of decisions from Windows scheduling priority.
When to test Above Normal
Above Normal is a reasonable experiment when the evidence suggests that OBS is losing scheduling time to other processes, particularly during a repeatable CPU-heavy task. It is not a universal improvement. If the machine has insufficient capacity for the chosen encoder or scene, a priority adjustment cannot create capacity; it can only alter which process gets a turn sooner when work is competing.
Make one controlled change: switch from Normal to Above Normal, then repeat the same workload under similar conditions. Leave the stream content, output settings and competing applications as consistent as practical. Compare OBS statistics, the resulting YouTube stream health and what viewers actually receive. If the stream was stable before, there may be no meaningful improvement to retain.
Consider what else is running. Giving OBS more scheduling precedence may make less urgent background work wait longer, and raising priority is not a substitute for leaving the broadcast computer available to do its job. A desktop used for browsing, downloads, cloud sync and gaming at the same time may produce a noisy test. A fair test either pauses incidental tasks or repeats the same tasks at the same stage of each comparison.
Do not interpret a short, clean interval as proof that the change has solved an overnight problem. The test needs to include the type of load and duration that usually precede the symptom. If you cannot reproduce the issue, leave the baseline alone and collect better evidence rather than escalating to High.
Separate CPU scheduling from encoder and network trouble
A stream can fail in several places that process priority does not control. If the selected encoder is too demanding, the GPU or CPU may be unable to keep up. If OBS cannot render scenes in time, simplify sources or reduce the work required to compose each frame. If frames are encoded but cannot be sent reliably, investigate the connection, route, upload capacity and YouTube's stream health indicators instead of changing Windows priority.
The OBS encoding performance troubleshooting guide discusses ways to diagnose performance problems, including reducing load and checking encoder choices. Its system requirements page is useful for understanding that requirements depend on the work being done; a computer meeting a general requirement is not proof that every scene and encoder configuration will run continuously. Use current OBS guidance alongside your own logs.
A useful first split is to ask whether OBS reports rendering lag, encoding lag or network-related dropped frames. Rendering lag can point to GPU rendering pressure or complex scenes. Encoding lag can point to an encoder that cannot sustain the chosen output. Network drops indicate delivery problems beyond the CPU scheduling of OBS. These clues are not diagnoses on their own, but they stop you from treating every counter as a reason to raise process priority.
For network symptoms, YouTube's live encoder settings and bitrates guidance provides the platform's current requirements and recommendations. Check that official guidance for your stream format rather than relying on an old copied bitrate table. For a connection that drops repeatedly, investigate the connection path and service conditions; this is closer to the problem described in why a podcast livestream disconnects on YouTube in India than to a process scheduling setting.
A file-based stream has another distinction: the video may play correctly locally while the live connection, audio routing or OBS source handling has a separate fault. Test the actual output, not just the local preview. If a loop loses sound after changing files, use the specific OBS looping audio troubleshooting guide rather than expecting priority to repair source behaviour.
Retest a prerecorded stream under sustained load
A short test can confirm that OBS opens and begins sending, but a 24/7 channel needs a more representative check. Use the same prerecorded file, scene collection, encoder and output configuration you intend to keep. Let the stream run through the kinds of transitions that matter: a loop boundary, any scheduled source or scene change, and the hours when other routine computer tasks usually happen.
Before the test, note the starting priority and relevant OBS statistics. During the run, record when rendering or encoding lag appears, when dropped frames rise, and whether YouTube Studio reports a stream health issue. Keep a simple log with time, setting, other active workload and observed symptom. This helps distinguish a coincidental quiet period from a repeatable difference between Normal and Above Normal.
Check what a viewer receives, too. The OBS preview cannot confirm that YouTube is receiving a continuous signal or that the public playback has the expected picture and sound. Monitor the live watch page or an appropriate test destination and check YouTube Studio. For audio-led channels, verify levels and listen for silence at the loop boundary; a channel can be technically live while its useful content is not reaching the audience.
A test should be long enough to include the recurring workload that has caused the concern. There is no universal duration that proves an always-on setup will remain healthy indefinitely. A successful overnight run is evidence about that run, not a guarantee about the next one. Keep monitoring after the test, especially after OBS, Windows, drivers, network equipment or content changes.
For a truly nonstop operation, also decide how the stream will recover if the computer or connection fails. Process priority only influences scheduling while OBS and Windows are running. It does not restart a powered-off computer, restore an internet connection or supervise a failed stream from outside that machine. If keeping a home computer running is itself the burden, StreamNeo removes the need to leave that computer on for a file-based YouTube broadcast: you upload the video, provide your stream key and the broadcast can continue from the cloud with monitoring and automatic restart if it drops.
Revert settings that do not help
Return to Normal if Above Normal does not produce a repeatable improvement, makes no difference under the relevant workload or causes other tasks to behave poorly. Reverting is not a failure; it is the correct result of a test that did not support the change. Leave a note of what you tried and what the logs showed so the next troubleshooting session does not repeat a guess.
If performance remains poor at Normal and Above Normal, return attention to the bottleneck. Review encoder settings and workload, reduce unnecessary sources or visual effects, and check OBS logs for clues. For network symptoms, assess the connection and YouTube's stream health. For audio or loop behaviour, test the media and source transitions separately. Avoid stacking several unmeasured tweaks: they obscure cause and make it harder to restore a known-good configuration.
Before changing other settings, preserve your OBS profile or note the values that matter. If the stream is live, schedule experiments at a time when a short interruption is acceptable, and make one change at a time. A prudent setting is the one that behaves predictably in your workload, not the one with the strongest label in a menu.
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
Where is Process Priority in OBS on Windows?
Open Settings > Advanced > General and find Process Priority. The current English interface lists High, Above Normal, Normal, Below Normal and Idle. It is a Windows OBS setting, not a YouTube Studio option.
Should I use Above Normal for a prerecorded stream?
Use Normal first, then test Above Normal if symptoms and logs suggest CPU scheduling contention. Keep the rest of the setup consistent and compare the same workload. If there is no repeatable benefit, return to Normal.
Does High prevent dropped frames or keep a stream online?
No. Process priority may affect scheduling among competing processes, but it does not fix encoder capacity, a network interruption, a failed source or a powered-off computer. High is not an established best setting for a nonstop prerecorded YouTube stream, and no priority level guarantees uptime.
Will changing priority fix YouTube stream health warnings?
Only if the underlying issue is related to OBS not receiving CPU time under contention, and even then the change needs testing. Warnings can stem from encoding, rendering, network delivery or the source itself. Check OBS statistics and YouTube's current official guidance before choosing a fix.