mpv High CPU Usage: How to Fix It

High CPU usage in mpv usually means that video decoding, subtitle rendering, filters, shaders, or another playback task is running on the processor when you expected lighter or GPU-assisted work. The problem can also come from a demanding media file, an ineffective hardware-decoding configuration, a custom script, an online stream, or an interaction between mpv and the operating system.

The fastest way to find the cause is not to change every setting at once. Start with a clean command, compare controlled tests, and stop as soon as you identify a single option or media feature that explains the load. This guide applies to Windows, Linux, and macOS and covers local files, subtitles, HDR media, network streams, online URLs, playlists, scripts, shaders, and customized configuration files.

1. Confirm the Symptom With a Minimal Clean mpv Command

First, confirm that mpv itself is responsible for the CPU load. Open Task Manager on Windows, Activity Monitor on macOS, or a process monitor such as top or htop on Linux. Start playback and observe the mpv process for at least 30 seconds after seeking and initial buffering have finished.

Some brief CPU activity is normal when opening a file, loading fonts, parsing a large playlist, initializing a decoder, or seeking. The relevant symptom is sustained usage during otherwise stable playback, especially when it causes dropped frames, heat, fan noise, battery drain, or audio and video stuttering.

1.1 Establish a clean baseline

Run mpv from a terminal with its configuration, scripts, and subtitles disabled:

mpv --no-config --no-sub "path-to-video"

Keep the path in quotes when it contains spaces or shell-sensitive characters. On Windows, use the exact path to mpv.exe if its directory is not included in the system PATH.

This test removes common causes such as profiles, shader chains, subtitle styling, user scripts, custom input bindings, and forced filters. If CPU usage falls substantially, the file is playable and the cause is probably in your configuration or subtitle path. If usage remains high, test the decoder and the media itself.

1.2 Compare software and hardware decoding

Run two separate tests:

1. mpv --no-config --no-sub --hwdec=no "path-to-video"
2. mpv --no-config --no-sub --hwdec=auto "path-to-video"

The first command forces software decoding. The second allows mpv to select an available hardware-decoding method. Do not assume that --hwdec=auto must always lower the total CPU measurement. Hardware decoding can involve frame copies, format conversion, GPU synchronization, tone mapping, or fallback behavior that reduces its benefit.

Success means one test produces stable playback with clearly lower sustained CPU usage and no new corruption, crashes, or excessive dropped frames. Once you have a good result, stop switching decoding APIs unless another file exposes a separate problem.

1.3 Test more than one representative file

Use a simple H.264 file and the file that triggers the problem. If possible, also compare a lower-resolution file with the same codec. High-resolution HEVC and AV1 are substantially harder to decode in software than ordinary H.264 content. Ten-bit video, high frame rates, large resolutions, film grain synthesis, and unusual chroma formats can increase the work further.

If only one demanding HEVC or AV1 file produces high CPU usage, the result may reflect a media or hardware limitation rather than a broken mpv installation. If every file has the problem, investigate global configuration, scripts, drivers, and output settings.

2. Check mpv Options That Directly Increase CPU Work

After the clean baseline, restore one feature at a time. Begin with subtitles, filters, shaders, scaling, and hardware decoding because these are among the most common explanations for mpv high CPU usage.

2.1 Test ASS subtitles separately

ASS and SSA subtitles can contain animated text, blur, vector drawings, karaoke effects, transformations, and many simultaneously visible elements. Rendering complex signs or heavily styled dialogue can consume significant CPU time even when video decoding is hardware accelerated.

Compare these commands:

1. mpv --no-config --no-sub "path-to-video"
2. mpv --no-config --sid=auto "path-to-video"

If the file does not select the desired subtitle automatically, choose its subtitle track using mpv's track controls or specify the appropriate subtitle ID. You can also cycle subtitles during playback and watch whether CPU usage changes during complex scenes.

Review subtitle-related options in mpv.conf, especially forced style changes, scaling, margins, blending behavior, and external subtitle files. A very large or malformed subtitle file may also cause unusual processing. Do not permanently disable subtitles if you need them. Instead, simplify custom subtitle styling, select a less complex track when available, or use a profile that applies expensive styling only to suitable content.

Success means enabling subtitles no longer causes excessive sustained CPU usage or dropped frames. If the load spikes only during elaborate ASS effects, the renderer is responding to the subtitle content rather than failing continuously.

2.2 Remove audio and video filters

Filters can perform expensive work on every frame or audio block. Inspect your command line and configuration for --vf, --af, vf-add, and af-add. Common costly operations include denoising, interpolation, deinterlacing, sharpening, debanding, scaling, frame-rate conversion, loudness processing, and channel remapping.

Test without configured filters:

mpv --no-config "path-to-video"

If you need to preserve the rest of your configuration while checking filter lists, use mpv's console or terminal output to inspect active filter chains, then temporarily comment out the relevant lines in mpv.conf. Input bindings and scripts can add filters after playback starts, so a configuration file may not reveal the entire chain.

For isolation, disable one category at a time. First remove video filters, test again, and then remove audio filters. Success means CPU usage falls when a particular filter is absent and returns when that filter is restored. Keep the filter disabled, reduce its quality or intensity, or limit it to a profile for media that genuinely needs it.

2.3 Review shaders and scaling settings

Custom GLSL shaders and advanced scaling algorithms are usually GPU-oriented, but they can still contribute indirectly to CPU load through driver overhead, synchronization, frame conversion, or an output path that does not operate as expected. Multiple shaders, high-quality debanding, interpolation, and large upscaling ratios can also overwhelm weaker GPUs, causing playback pressure elsewhere.

Look for options such as glsl-shaders, scale, cscale, dscale, tscale, interpolation, and aggressive debanding settings. Temporarily remove custom shaders and return scaling options to defaults.

If the clean command is efficient but your normal profile is not, reintroduce one shader or quality option at a time. Success means playback meets your quality needs without sustained overload or dropped frames. Once you find the first setting that causes the increase, stop adding more settings until that one has been adjusted.

2.4 Verify hardware decoding instead of assuming it works

A configured hardware decoder may be unavailable for the file's codec, bit depth, profile, chroma format, or resolution. mpv may then use software decoding. It may also decode on the GPU but copy frames back to system memory for filters, reducing the expected savings.

Start with --hwdec=auto rather than forcing a platform-specific backend without evidence. Watch terminal output for the selected decoder and video output details. Compare CPU usage, dropped frames, image correctness, and seek behavior against --hwdec=no.

Hardware decoding is not always the best answer. Some filters require software frames, some drivers have inefficient paths, and older GPUs may not support modern HEVC or AV1 variants. Keep hardware decoding only when the controlled comparison demonstrates a practical benefit.

2.5 Check profiles, scripts, and input bindings

Profiles can silently activate based on resolution, protocol, file extension, or other conditions. Scripts can inspect frames, manage playlists, fetch metadata, update status displays, alter speed, or repeatedly invoke external programs. Input bindings can add filters or toggle expensive features without making the change obvious.

Inspect these locations in your mpv configuration directory:

• mpv.conf for global options and conditional profiles
• input.conf for commands that add filters, shaders, screenshots, or scripts
• The scripts directory for Lua or JavaScript extensions
• The script-opts directory for extension-specific settings

Do not delete the whole configuration directory. Rename or move one script temporarily, comment out one profile, or launch with --no-config. Use --show-profile=PROFILE_NAME to print the contents of a named profile before deciding whether it is relevant.

Success means a specific script, binding, or profile reliably explains the difference between normal and clean playback. Leave unrelated customizations untouched.

2.6 Inspect screenshot behavior

Taking a screenshot can require frame conversion, subtitle blending, image encoding, and disk writes. A single screenshot may cause a short CPU spike, but repeated screenshots can create sustained load.

Check input.conf for a key that repeats unintentionally, a script that captures frames on a timer, or commands using screenshot modes that include subtitles. Confirm that the destination is writable and not a slow network-mounted directory. Success means CPU usage returns to normal when automated or repeated capture stops.

3. Check Operating System and Media Constraints

3.1 Update trusted graphics components

Hardware decoding and video output rely on the operating system's graphics stack. On Windows and macOS, use operating system updates and drivers from the hardware vendor or computer manufacturer. On Linux, use packages supplied by your distribution or another repository you explicitly trust. Avoid random codec packs and unofficial binary bundles.

A driver problem is more likely when hardware decoding unexpectedly falls back, a particular output driver behaves poorly, or CPU usage changed after a system update. Test default output selection before forcing gpu, gpu-next, or a platform-specific output.

Success means mpv selects a stable decoding and presentation path with no unexplained fallback. If driver changes make no measurable difference, return to option-level troubleshooting.

3.2 Consider the display server and presentation path

On Linux, behavior can differ between Wayland and X11 because window presentation, scaling, synchronization, and driver integration use different paths. Fractional desktop scaling, multiple displays with different refresh rates, or a compositor under load can affect playback.

Do not change display systems as the first fix. First prove that --no-config still has high CPU usage and that the decoder is not the main cause. If the problem occurs only in one session type, test the default video output in both environments and review the terminal log for fallback messages.

3.3 Check audio backends and track selection

Audio usually consumes much less CPU than high-resolution video, but resampling, normalization, spatial processing, damaged streams, or an unsuitable backend can matter. Test with audio disabled:

mpv --no-config --no-audio "path-to-video"

If this changes the result, inspect audio filters, selected tracks, channel layouts, and the operating system's audio device. For files containing several tracks, make sure mpv is not processing an unexpected track selected by a profile or command-line option.

Success means selecting a normal track or removing a costly audio filter restores stable playback. If disabling audio makes almost no difference, focus on video, subtitles, and scripts.

3.4 Separate local playback from online streaming

For an online URL, mpv may call an external tool such as yt-dlp to resolve the media. The selected format might be AV1, high-frame-rate video, or a resolution your hardware cannot decode efficiently. Network retries, playlist processing, and external helper activity can also look like an mpv player issue.

Test a known local file first. Then inspect the online format selected by the resolver. Ensure yt-dlp comes from its official project or a trusted package manager and that mpv can find the intended executable. Avoid assuming that replacing yt-dlp will fix CPU usage when the actual cause is the codec chosen by the site.

For direct network streams, test whether the same content behaves differently after obtaining a legitimate local copy from an authorized source. If local playback is efficient but the stream is not, investigate format selection, unstable network delivery, reconnect behavior, and buffering rather than decoder settings alone.

3.5 Recognize media-file limitations

A damaged file can trigger repeated decoder errors, concealment work, or unusual seeking behavior. A technically valid file may still exceed the capabilities of the system. Examples include high-bitrate 4K or 8K HEVC, AV1 without hardware support, 10-bit profiles unsupported by an older GPU, and unusually complex subtitle tracks.

Compare another file encoded with the same codec and resolution. If only one file fails, examine its track and codec information and watch for repeated errors in the log. Success may mean accepting software-decoding load for that file, selecting a compatible track, or creating a personal compatible encode from media you are authorized to process.

4. Use mpv Diagnostics to Identify the Active Cause

4.1 Read ordinary terminal output first

Run mpv from a terminal instead of launching it only through a desktop shortcut. The initial output identifies tracks, codecs, filters, output behavior, and many fallback conditions. Look for repeated warnings rather than treating every informational line as an error.

Pay attention to the selected video and audio tracks, decoder name, pixel format, hardware-decoding status, subtitle type, and messages that repeat every frame. Repeated decoder or driver errors are more actionable than a single harmless startup warning.

4.2 Increase logging carefully

For a detailed temporary log, run:

mpv --no-config --msg-level=all=v --log-file=mpv-test.log "path-to-video"

Verbose logging can itself add overhead, especially when an error repeats rapidly. Use it only long enough to reproduce the problem, then close mpv. Before sharing a log, review it for local paths, URLs, tokens, usernames, or other private information.

Success means the log reveals a concrete fallback, repeated failure, active filter, script error, or unsupported decoding path. If it does not, compare logs from one efficient test and one inefficient test rather than increasing verbosity indefinitely.

4.3 Use the stats overlay and track list

mpv's built-in stats display can show decoder, output, frame timing, dropped frames, and other playback details. The default stats bindings are commonly available through the i key, although customized input bindings can replace them. Use the overlay to compare the same scene under clean and normal configurations.

Inspect the active track list as well. Confirm which video, audio, and subtitle tracks are selected. A file may contain an unexpected high-resolution video track, commentary audio, image-based subtitles, or an ASS track selected by language preferences.

Success means the overlay and track selection confirm the component responsible for the difference. Once the expected track, decoder, and output are active and playback is stable, stop changing unrelated options.

4.4 Inspect profile expansion

If a named profile is suspicious, run:

mpv --show-profile=PROFILE_NAME

Replace PROFILE_NAME with the actual name from your configuration. Review every option the profile applies, including inherited profiles. Conditional profiles deserve special attention because they may activate only for HDR, particular protocols, large video widths, or specific file types.

5. Run a Clean Temporary Test Before Permanent Changes

Use a repeatable test sequence so that each result answers one question. Choose a two-minute scene that reliably causes high CPU usage and avoid changing playback position between comparisons.

1. Run mpv --no-config --no-sub --hwdec=no "file" to measure clean software decoding.
2. Run the same command with --hwdec=auto.
3. Keep the better decoding mode and enable subtitles.
4. Restore your main configuration but temporarily exclude scripts and custom shaders.
5. Restore one script, profile, filter, or shader at a time.
6. Repeat the winning command once to confirm that the result is reproducible.

Change only one variable per run. Record approximate CPU usage, dropped frames, decoder choice, and visible problems. Small fluctuations are normal, so look for a sustained and repeatable difference rather than a one-second peak.

Stop when playback is smooth, CPU usage is reasonable for the codec and hardware, and the necessary features still work. Chasing the lowest possible percentage can introduce compatibility problems without producing a meaningful improvement.

6. Quick Fix Checklist

• Confirm sustained CPU usage after startup and buffering finish.
• Test the file with --no-config --no-sub.
• Compare --hwdec=no with --hwdec=auto.
• Check whether HEVC or AV1 is being decoded in software.
• Disable ASS subtitles temporarily and compare the same scene.
• Remove custom video and audio filters one category at a time.
• Disable shader chains, interpolation, and aggressive scaling temporarily.
• Inspect profiles with --show-profile.
• Temporarily isolate scripts instead of deleting the configuration directory.
• Check input bindings for filters, shaders, or repeated screenshots.
• Verify active audio, video, and subtitle tracks.
• Use terminal output and a short verbose log to detect fallbacks.
• Test a trusted local file before blaming yt-dlp or the network.
• Use trusted operating system, driver, mpv, and yt-dlp sources.
• Stop once one reproducible change restores stable playback.

7. Frequently Asked Questions

7.1 Why does mpv use high CPU for HEVC or AV1?

HEVC and AV1 can require substantial software-decoding work, particularly at 4K, high frame rates, or 10-bit depth. If the GPU does not support the exact codec profile or mpv cannot use the relevant hardware path, decoding falls back to the CPU. Compare --hwdec=no and --hwdec=auto, then verify the selected decoder in terminal output or the stats overlay.

7.2 Can subtitles cause high CPU usage?

Yes. Complex ASS subtitles can use animated effects, blur, drawings, and many layered elements. Test with --no-sub. If that resolves the issue, restore subtitles and simplify custom styling or select a less demanding track. A short spike during an elaborate subtitle scene does not necessarily indicate a malfunction.

7.3 Why does hardware decoding fail to reduce CPU usage?

The file may not be supported by the GPU, mpv may be falling back to software, or filters may require hardware-decoded frames to be copied into system memory. Driver overhead, tone mapping, format conversion, and presentation can also remain CPU tasks. Keep hardware decoding only when it improves the complete playback result.

7.4 How can I tell whether my mpv configuration is responsible?

Run the same file with --no-config. If CPU usage falls, restore options in small groups. Check mpv.conf, input.conf, profiles, scripts, script options, shaders, and filters. Do not erase the complete configuration before isolating the specific cause.

7.5 Why is CPU usage high only for online videos?

The online service may supply a more demanding codec or resolution than your local files, and yt-dlp may select AV1 or high-frame-rate media. A script or resolver can also perform extra work while handling playlists. Test a local file, inspect the selected online format, and separate decoder load from network retries or external-tool activity.

7.6 When is high CPU usage normal?

It can be normal during software decoding of demanding HEVC or AV1 video, complex subtitle effects, intensive filters, startup, seeking, or screenshot encoding. The key questions are whether playback remains smooth, whether the load matches the media's demands, and whether a clean test reveals an avoidable option. If performance is stable and controlled tests show no faulty configuration, further changes may not be necessary.