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:

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.

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:

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

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:

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

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

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.

This is where the problem statement got real clear.

Switch to NVIDIA

Confirm which GPU is active:

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.

Lets check GPU and Driver Stack

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

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

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

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

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

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

Now, I am sure its a context mismatch issue.

Fixing GPU context mismatch

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

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.

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://github.com/mpv-player/mpv/issues/15980

• https://github.com/mpv-player/mpv/issues/10854

• https://github.com/mpv-player/mpv/issues/372

• https://wiki.archlinux.org/title/Hardware_video_acceleration

• 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.