# Debugging MPV Hardware Decoding on Hybrid Intel–NVIDIA Systems (Wayland, Ubuntu): A Step-by-Step Debugging Journey

# Overview

Who am I? Just a regular guy who loves watching movies. I also tend to dig into the technical side of everyday problems — but I’m usually too lazy to actually solve them. A few months ago, I ran into an issue while trying to play a media file. That’s when I realized my system wasn’t too friendly with AV1-encoded videos.

So, what did I do? Well, since I have a dual-boot setup, I simply switched over to Windows to play it. (Don’t judge!) But honestly, how long could I keep doing that? It was *incredibly* inconvenient to switch OSes just to watch a movie.

A few days ago, I finally decided to dig deeper. At first, I looked online to see if others had the same issue. I had tried that before — back when the problem first appeared — but didn’t find any promising solutions. That’s why I kept relying on my quick “boot to Windows” workaround.

This time, though, I was serious. My inner engineer refused to stay quiet. And that’s how this debugging journey began. In this article, I’ll take you along with me — step by step — through how I diagnosed and finally solved what seemed like a complex issue that turned out to be surprisingly tricky but simple af.

# Introduction

## Problem Statement

I had this `.mkv` video file encoded with the shiny new **AV1 codec**, and for some reason, it just refused to play on my Ubuntu machine — even though I already had `mpv` and `ffmpeg` installed. The player would **either crash** or refuse to open the file. Was it a codec issue, a player quirk, or something weird going on with GPU hardware decoding behind the scenes?

## System Overview

Here’s a brief summary of my setup:

| **Component** | **Details** |
| --- | --- |
| OS | Ubuntu 24.04 LTS (Wayland) |
| Kernel | Linux 6.14.0-33-generic |
| MPV | 0.37.0 |
| FFmpeg | 6.1.1 |
| GPU | Intel iGPU + NVIDIA RTX 3050 |
| Drivers | NVIDIA 570.172.08, CUDA 12.8 |

# Investigation Process - The Journey

### Check MPV & FFmepeg Build Info

Some Ubuntu systems, especially if using **older media players** or missing certain libraries — **don’t support AV1 playback natively**. Although I had done basic installation of both the software and as my OS and Kernel not that old, I knew there must be support for AV1.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760186716460/b8f33c3b-50b6-40e6-94a0-0b3ae1ec57ae.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760186992134/55aa0def-c571-4346-b377-6d3c986dc11c.png align="center")

```bash
ffmpeg -codecs | grep av1
---Notable OUTPUT---
WARNING: library configuration mismatch
...
DEV.L. av1         Alliance for Open Media AV1 (decoders: libdav1d libaom-av1 av1 av1_cuvid av1_qsv) (encoders: libaom-av1 librav1e libsvtav1 av1_nvenc av1_qsv av1_vaapi)
DEAIL. wmav1       Windows Media Audio 1
```

FFmpeg build does include **AV1 decoding support,** thus FFmpeg and MPV can handle AV1 — at least from a codec capability perspective.

As for the **WARNING** message, initially I thought MPV might be loading mismatched libraries but this message is common to have after upgrades. Trust me, I did the clean re-installation, the warning was gone for a new start. However, it recurred after few reboots.

Just in case if you would like to perform clean re-install:

```bash
sudo apt purge ffmpeg mpv -y
sudo apt autoremove -y
sudo apt update
sudo apt install ffmpeg mpv -v
ffmpeg --version && mpv --version
```

### Check if FFmpeg can Decode it Manually

```bash
ffmpeg -v error -i yourfile.mkv -f null -
```

This will attempt to decode the entire video to `/dev/null`. If you see **no errors,** FFmpeg can decode it fine — the issue is purely in playback. If there’s a decoding error at this step its because the file is corrupted or encoded with an unsupported AV1 profile like 10-bit.

**Inspect Video Stream Details**:

```bash
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,bit_rate -of default=nw=1 yourfile.mkv
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760188492914/9554c9b2-1f92-4f0a-b7bc-ff60709a7830.png align="center")

Therefore, my media file is a **10-bit AV1 video (**`pix_fmt=yuv420p10le`**)**, so software decoders like `libdav1d libaom-av1` should easily handle it. I did this step out of curiosity as I read somewhere that some GPU-accelerated pipelines can’t handle 10-bit AV1 video file yet. So I just wanted to check that it.

### Check MPV logs

```bash
mpv -v yourfile.mkv | tee mpv.log
---Notable OUTPUT---
[vo/gpu/wayland] GL_VENDOR='Intel'
[vo/gpu/wayland] GL_RENDERER='Mesa Intel(R) Graphics (ADL GT2)'
...
[vd] Opening decoder libdav1d
[vd] Looking at hwdec av1-vaapi...
[vo/gpu] Loading hwdec drivers for format: 'vaapi'
[vo/gpu] Loading hwdec driver 'vaapi'
...
[vd] Pixel formats supported by decoder: cuda vaapi vdpau vulkan yuv420p10le
...
[ffmpeg/video] av1: Failed to end picture decode issue: 23 (internal decoding error).
[ffmpeg/video] av1: HW accel end frame fail.
[vd] Error while decoding frame (hardware decoding)!
```

Well this log was full of informational details I needed. Lets see what did I find out:

* Intel integrated graphic was used as renderer. While Alder Lake does support **AV1 hardware decoding,** it depends on:
    
    * The **driver stack, VAAPI version, Wayland/X11 compositor setup**
        
    * Many systems with Intel iGPUs hit issues like **black screen, freeze, or no output** when AV1 VAAPI decoding is attempted — especially under **Wayland.**
        
* My guess, MPV loads VAAPI → Wayland → EGL → dmabuf interop → hardware AV1 decoder. This is where it likely stops showing video — the FPU driver fails silently.
    
* Hence, problem = **VAAPI hardware docoding of AV1 under Intel-iGPU + Wayland combo.**
    

<mark>This is where the problem statement got real clear.</mark>

### Switch to NVIDIA

**Confirm which GPU is active:**

```bash
glxinfo | grep "OpenGL renderer"
```

If it says something like `OpenGL renderer string: Mesa Intel(R) Graphics …` then your session (`wayland or X`) is currently using the Intel GPU, not NVIDIA.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760684347798/ccf1ae27-3134-4bae-aaf4-350fb9c14da8.png align="center")

**Lets check GPU and Driver Stack**

```bash
vainfo | grep -i av1
ffmpeg -hwaccels
ffmpeg -decoders | grep av1
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760686287550/b9d92e04-a8b4-4880-85ae-8b823b8a7a26.png align="center")

If `vainfo` lists only Intel devices, it means the NVIDIA VAAPI driver (rarely used) isn’t active. That’s expected;

If you see `cuda`, `vulkan`, or `vaapi` in the list, good — the driver stack is okay.

Lastly, check that `ffmpeg` recognizes the NVIDIA AV1 decoder.

**Test playback directly via NVIDIA**

```bash
DRI_PRIME=1 mpv --hwdec=cuda --vo=gpu-next --gpu-api=opengl --gpu-context=waylandvk "censored-name.mkv"
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760687078988/890f330e-3db2-43a9-bfe0-363aa4909380.png align="center")

This means mpv **found the NVIDIA GPU (via** `DRI_PRIME=1`) but **couldn’t create a rendering context under Wayland** — because Wayland + NVIDIA is still finicky with OpenGL/Vulkan interop.

**Test with the safer X11 EGL path**

```bash
DRI_PRIME=1 mpv --hwdec=cuda --vo=gpu-next --gpu-context=x11egl "censored-name.mkv"
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760688383361/1cea2117-b588-4751-8457-3583c0d8a2d2.png align="center")

This forces mpv to use an XWayland bridge to talk to the NVIDIA GPU.

* mpv successfully detects the **video**, **audio**, and **subtitle** tracks.
    
* The **libEGL warning** (`failed to create dri2 screen`) and **CUDA\_ERROR\_INVALID\_GRAPHICS\_CONTEXT** indicate a **context mismatch** — CUDA tried to access OpenGL through the wrong display backend (likely Wayland instead of X11).
    
* The note `CUDA hwdec only works with OpenGL or Vulkan backends` explains the failure reason.
    
* Despite that, mpv still falls back to **software rendering**
    

<mark>Now, I am sure its a </mark> **<mark>context mismatch</mark>** <mark>issue.</mark>

**Fixing GPU context mismatch**

```bash
__GLX_VENDOR_LIBRARY_NAME=nvidia mpv --hwdec=cuda --vo=gpu-next --gpu-context=waylandvk "censored-name.mkv"
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760688971283/aa79b893-19c6-4c0d-a2fd-0e4535c8e486.png align="center")

Finally It worked !! This plays the video with now errors or warnings.

Wayland sessions and NVIDIA drivers don’t always automatically set the correct OpenGL vendor path.  
The variable `__GLX_VENDOR_LIBRARY_NAME=nvidia` forces MPV (and the GLX stack) to use the NVIDIA OpenGL library instead of Mesa (Intel/AMD). This fixed the “invalid OpenGL or DirectX context” errors.

---

# Final Solution

For convenience you can make this your default MPV configuration so you don’t have to type it each time.

```bash
vi ~/.config/mpv/mpv.conf
---Add below configurations---
hwdec=cuda
vo=gpu-next
gpu-context=waylandvk

vi ~/.config/environment.d/99-nvidia.conf
---Add below configurations---
__GLX_VENDOR_LIBRARY_NAME=nvidia

---REBOOT System---
Enjoy your media file.
```

**What** `~/.config/environment.d/` **is —** This directory is part of **systemd’s user environment mechanism**.  
Anything you put as `.conf` files here (with `KEY=value` pairs) gets automatically loaded **into your user session environment**, *before* applications start.

---

# Conclusion

What started as *“why won’t this stupid file play”* turned into a journey through drivers, GPU contexts, and environment tweaks — and I learned more about the Linux graphics stack in one evening than I had in months.

## References

* [https://ffmpeg.org/documentation.html](https://ffmpeg.org/documentation.html)
    
* [https://github.com/mpv-player/mpv/issues/15980](https://github.com/mpv-player/mpv/issues/15980)
    
* [https://github.com/mpv-player/mpv/issues/10854](https://github.com/mpv-player/mpv/issues/10854)
    
* [https://github.com/mpv-player/mpv/issues/372](https://github.com/mpv-player/mpv/issues/372)
    
* [https://wiki.archlinux.org/title/Hardware\_video\_acceleration](https://wiki.archlinux.org/title/Hardware_video_acceleration)
    
* [https://developer.nvidia.com/video-codec-sdk](https://developer.nvidia.com/video-codec-sdk)
    

## Lesson Learned

* Try to step out of the comfort box, being lazy dosen’t solve things.
    
* Problems seems hard until its well understood.
    
* Data Flow : MPV → FFmpeg → CUDA/NVDEC → NVIDIA GPU → Display (Wayland
    
* Logs are the goto debugging checkpoints.
    
* PS: This is my 1st time writing a technical article, thus open to take suggestion to improve the structure and writing.