Bug report: libmpv OpenGL render API — INVALID_ENUM / black hardware‑decoded video with subtitles (nvidia‑open)

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Feb 11 2026 22:07:06
libplacebo version: v7.360.1
FFmpeg version: n8.0.1 (runtime n8.1.2)
FFmpeg library versions:
   libavcodec      62.11.100 (runtime 62.28.102)
   libavdevice     62.1.100 (runtime 62.3.102)
   libavfilter     11.4.100 (runtime 11.14.102)
   libavformat     62.3.100 (runtime 62.12.102)
   libavutil       60.8.100 (runtime 60.26.102)
   libswresample   6.1.100 (runtime 6.3.102)
   libswscale      9.1.100 (runtime 9.5.102)

Other Information

- Linux version: NAME="Arch Linux" PRETTY_NAME="Arch Linux"
- Kernel Version: Linux slimarch 7.1.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Thu, 09 Jul 2026 19:55:55 +0000 x86_64 GNU/Linux
- GPU Model: 09:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD104 [GeForce RTX 4070 SUPER] [10de:2783] (rev a1)
- Mesa/GPU Driver Version: OpenGL version string: 4.6.0 NVIDIA 610.43.03
- Window Manager and Version:
- Source of mpv:
- Latest known working version:
- Issue started after the following happened:

Reproduction Steps

This reproduces only through the libmpv OpenGL render API rendering into an externally-supplied GL context (Qt QOpenGLWidget), so a --no-config standalone run does not apply. A ~190-line PyQt6 + libmpv harness is the minimal case (attached under Sample Files):

# reproduces (hardware decode + a subtitle -> artifacts/black, subtitle still draws):
python3 hwdec_sub_test.py FILE --minimal --sid 3 --seek 600 --gpu-debug 2>gpu-debug.log

# forcing a desktop OpenGL 4.6 context instead of GLES -> STILL fails:
python3 hwdec_sub_test.py FILE --minimal --sid 3 --seek 600 --gl

# software decode -> works:
python3 hwdec_sub_test.py FILE --minimal --sid 3 --seek 600 --hwdec no

The harness builds MpvRenderContext(mpv, "opengl", ...) on a bare QOpenGLWidget, plays the file, and enables the first non-forced subtitle. FILE is a 10-bit HEVC (HDR, p010, bt.2020/pq) with an embedded SubRip track.

Standalone mpv does NOT reproduce — same file, subtitle and hwdec render correctly with both --vo=gpu and --vo=gpu-next:

mpv --no-config --vo=gpu      --hwdec=auto-copy-safe --sid=3 --start=600 FILE   # OK
mpv --no-config --vo=gpu-next --hwdec=auto-copy-safe --sid=3 --start=600 FILE   # OK

Every hardware backend fails identically through the render API:
auto-copy-safe (→ vulkan-copy), nvdec, nvdec-copy, auto-safe.
Reproduces at 1080p as well as 4K.

Expected Behavior

Hardware-decoded video composited with a subtitle through the OpenGL render API renders correctly (as it does under --vo=gpu/--vo=gpu-next), or the render API selects a texture format the driver accepts.

Actual Behavior

The hardware-decoded video plane turns to artifacts / black the moment a subtitle is composited, while the subtitle itself keeps drawing. mpv logs INVALID_ENUM on texture creation for both the video plane and the OSD (subtitle) texture.

GLES context (Qt's default on Wayland/NVIDIA):

libmpv_render: GL_VERSION='OpenGL ES 3.2 NVIDIA 610.43.03'
libmpv_render: Detected GLES 3.2.
Using hardware decoding (vulkan-copy).
vo/libmpv: reconfig to 3840x2160 p010 bt.2020-ncl/bt.2020/pq/limited/display
libmpv_render: Texture for plane 0: 3840x2160
libmpv_render: after creating texture: OpenGL error INVALID_ENUM.   <-- video
libmpv_render: Reallocating OSD texture to 256x128.
libmpv_render: after creating texture: OpenGL error INVALID_ENUM.   <-- subtitle

Forced desktop OpenGL 4.6 context + nvdec-copy — same failure:

libmpv_render: GL_VERSION='4.6.0 NVIDIA 610.43.03'
libmpv_render: Detected desktop OpenGL 4.6.
Using hardware decoding (nvdec-copy).
libmpv_render: Texture for plane 0: 3840x2160
libmpv_render: after creating texture: OpenGL error INVALID_ENUM.
libmpv_render: Reallocating OSD texture to 256x128.
libmpv_render: after creating texture: OpenGL error INVALID_ENUM.

With --gpu-debug the error brackets video rendering / texture creation itself:

libmpv_render: after video rendering: OpenGL error INVALID_ENUM.
libmpv_render: before video texture creation: OpenGL error INVALID_ENUM.

Note: INVALID_ENUM is also logged with hwdec=no, where playback works — so
the error alone is not fatal, but with hardware decoding the video plane texture is affected and the picture is lost.

Log File

gpu-debug.log

Sample Files

• The reproduction harness: hwdec_sub_test.py (~190 lines, PyQt6 + libmpv only)
  — in the dopeIPTV repo at tools/hwdec_sub_test.py
  (https://github.com/slimture/dopeIPTV/blob/main/tools/hwdec_sub_test.py).

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

Run tools/hwdec_sub_test.py with the documented --minimal commands, comparing GLES and desktop OpenGL with hardware decoding and hwdec=no; standalone mpv is the working comparison. Trace the libmpv OpenGL render API texture-creation path using the logged INVALID_ENUM locations. Done means hardware-decoded video and subtitles render correctly through the external Qt OpenGL context.