1
0
mirror of https://github.com/mpv-player/mpv synced 2025-02-21 15:27:00 +00:00
Commit Graph

4 Commits

Author SHA1 Message Date
wm4
8fb9cc2534 vo_opengl: read framebuffer depth from actual FBO used for rendering
In some cases, such as when using the libmpv opengl-cb API, or with
certain vo_opengl backends, the main framebuffer is never accessed.
Instead, rendering is done to a FBO that acts as back buffer. This meant
an incorrect/broken bit depth could be used for dithering.

Change it to read the framebuffer depth lazily on the first render call.

Also move the main FBO field out of the GL struct to MPGLContext,
because the renderer's init function does not need to access it anymore.
2017-03-20 13:31:28 +01:00
wm4
84bf6aabf0 vo_opengl: context_vdpau: resize output surfaces lazily
This actually fixes the dreaded errors during resizing. It works pretty
much like before, except each surface is reallocated before it's used.
It implies surfaces with the old size remain in the presentation queue
and will be displayed.
2017-03-19 09:26:10 +01:00
wm4
d2dc29f221 vo_opengl: context_vdpau: minor fixes
Don't assume 0 is an invalid object handle. vdpau with its weird API
design makes all objects indexes, with 0 being a perfectly valid and
common value. You need to use VDP_INVALID_HANDLE, which is not 0.

Don't crash if init fails at vdpau initialization. It's because
mp_vdpau_destroy(NULL) crashes. Simplify it.

Destroy output surface backed FBO before output surface. Also, strictly
bookkeep the map/unmap calls (and unmap surfaces before destroying the
FBO/texture). I can't see a change in the weird errors when resizing the
window, but I guess it's slightly more correct.

Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might
fail compilation with headers that do not contain the vdpau extension
(well, probably doesn't matter).
2017-03-19 09:03:13 +01:00
wm4
c3248369ac vo_opengl: add experimental vdpauglx backend
As the manpage says, this has no value other than adding bugs.

It uses code based on context_x11.c, and basically does very stripped
down context creation (no alpha support etc.). It uses vdpau for
display, and maps vdpau output surfaces as FBOs to render into them.

This might be good to experiment with asynchronous presentation. For
now, it presents synchronously, with a 4 frame delay (which should whack
off A/V sync). The forced 4 frame delay is probably also why interaction
feels slower.

There are some weird vdpau errors on resizing and uninit. No idea what
causes them.
2017-03-18 17:43:57 +01:00