RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/out/opengl/hwdec_vdpau.c

284 lines
8.4 KiB
C
Raw Normal View History

vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
/*
* This file is part of mpv.
*
vo_opengl: hwdec_vdpau: relicense under LGPL All code was written by myself.
2016-01-07 10:22:54 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
vo_opengl: hwdec_vdpau: relicense under LGPL All code was written by myself.
2016-01-07 10:22:54 +00:00
* GNU Lesser General Public License for more details.
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
*
vo_opengl: hwdec_vdpau: relicense under LGPL All code was written by myself.
2016-01-07 10:22:54 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
*/
#include <stddef.h>
#include <assert.h>
vdpau/GLX: don't access VO backend Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
2014-12-03 20:13:59 +00:00
#include <GL/glx.h>
vo_opengl: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "hwdec.h"
#include "utils.h"
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
#include "video/vdpau.h"
vo_opengl: make it work with vf_vdpaupp This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
2014-04-29 13:11:26 +00:00
#include "video/vdpau_mixer.h"
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
gl_hwdec_vdpau: silence warning caused by buggy GL_NV_vdpau_interop spec VDPAU handles are integers, but for some reasons the VDPAU GL extension expects them as void*.
2013-11-09 22:31:12 +00:00
// This is a GL_NV_vdpau_interop specification bug, and headers (unfortunately)
// follow it. I'm not sure about the original nvidia headers.
#define BRAINDEATH(x) ((void *)(uintptr_t)(x))
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
static int reinit(struct gl_hwdec *hw, struct mp_image_params *params);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
struct priv {
vdpau: mp_msg conversions
2013-12-21 17:05:23 +00:00
struct mp_log *log;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
struct mp_vdpau_ctx *ctx;
uint64_t preemption_counter;
struct mp_image_params image_params;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
GLuint gl_textures[4];
vo_opengl: vdpau: call glVDPAUFiniNV only if initialized This is "more correct". See #2798.
2016-02-08 12:39:33 +00:00
bool vdpgl_initialized;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
GLvdpauSurfaceNV vdpgl_surface;
VdpOutputSurface vdp_surface;
vo_opengl: make it work with vf_vdpaupp This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
2014-04-29 13:11:26 +00:00
struct mp_vdpau_mixer *mixer;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
bool direct_mode;
vo_opengl: silence vdpau hwdec warnings with smoothmotion Since the gl_rework merge, this started to print some OpenGL errors when using vdpau hardware decoding with vo_opengl smoothmotion. This happens because some hwdec unmap_image call were not paired with a map_image call. Unlike the old vo_opengl, the new code does not do this out of convenience (it would be a pain to track this exactly). It was triggered by smoothmotion, because not every rendered frame has actually a new input video frame (i.e. no map_image call, but it called unmap_image anyway). Solve this by handling unmapping differently in the vdpau code. The next commit will remove the unmap_image callback completely. Fixes #1687.
2015-03-14 21:36:59 +00:00
bool mapped;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
};
vo_opengl: hwdec_vdpau: remove minor code duplication Move unmap() to the top of the function, and replace some duplicated code with a call to it.
2016-06-08 20:16:32 +00:00
static void unmap(struct gl_hwdec *hw)
{
struct priv *p = hw->priv;
GL *gl = hw->gl;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
if (p->mapped) {
vo_opengl: hwdec_vdpau: remove minor code duplication Move unmap() to the top of the function, and replace some duplicated code with a call to it.
2016-06-08 20:16:32 +00:00
gl->VDPAUUnmapSurfacesNV(1, &p->vdpgl_surface);
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
if (p->direct_mode) {
gl->VDPAUUnregisterSurfaceNV(p->vdpgl_surface);
p->vdpgl_surface = 0;
}
}
vo_opengl: hwdec_vdpau: remove minor code duplication Move unmap() to the top of the function, and replace some duplicated code with a call to it.
2016-06-08 20:16:32 +00:00
p->mapped = false;
}
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
static void mark_vdpau_objects_uninitialized(struct gl_hwdec *hw)
{
struct priv *p = hw->priv;
p->vdp_surface = VDP_INVALID_HANDLE;
vo_opengl: silence vdpau hwdec warnings with smoothmotion Since the gl_rework merge, this started to print some OpenGL errors when using vdpau hardware decoding with vo_opengl smoothmotion. This happens because some hwdec unmap_image call were not paired with a map_image call. Unlike the old vo_opengl, the new code does not do this out of convenience (it would be a pain to track this exactly). It was triggered by smoothmotion, because not every rendered frame has actually a new input video frame (i.e. no map_image call, but it called unmap_image anyway). Solve this by handling unmapping differently in the vdpau code. The next commit will remove the unmap_image callback completely. Fixes #1687.
2015-03-14 21:36:59 +00:00
p->mapped = false;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
}
static void destroy_objects(struct gl_hwdec *hw)
{
struct priv *p = hw->priv;
vdpau/GLX: don't access VO backend Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
2014-12-03 20:13:59 +00:00
GL *gl = hw->gl;
vdpau: remove pointer indirection for a field There's no reason to. This is basically a cosmetic change.
2014-03-19 18:57:08 +00:00
struct vdp_functions *vdp = &p->ctx->vdp;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
VdpStatus vdp_st;
vo_opengl: hwdec_vdpau: remove minor code duplication Move unmap() to the top of the function, and replace some duplicated code with a call to it.
2016-06-08 20:16:32 +00:00
unmap(hw);
vo_opengl: silence vdpau hwdec warnings with smoothmotion Since the gl_rework merge, this started to print some OpenGL errors when using vdpau hardware decoding with vo_opengl smoothmotion. This happens because some hwdec unmap_image call were not paired with a map_image call. Unlike the old vo_opengl, the new code does not do this out of convenience (it would be a pain to track this exactly). It was triggered by smoothmotion, because not every rendered frame has actually a new input video frame (i.e. no map_image call, but it called unmap_image anyway). Solve this by handling unmapping differently in the vdpau code. The next commit will remove the unmap_image callback completely. Fixes #1687.
2015-03-14 21:36:59 +00:00
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
if (p->vdpgl_surface)
gl->VDPAUUnregisterSurfaceNV(p->vdpgl_surface);
p->vdpgl_surface = 0;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
glDeleteTextures(4, p->gl_textures);
for (int n = 0; n < 4; n++)
p->gl_textures[n] = 0;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
if (p->vdp_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(p->vdp_surface);
vdpau: mp_msg conversions
2013-12-21 17:05:23 +00:00
CHECK_VDP_WARNING(p, "Error when calling vdp_output_surface_destroy");
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
}
vo_opengl: make it work with vf_vdpaupp This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
2014-04-29 13:11:26 +00:00
p->vdp_surface = VDP_INVALID_HANDLE;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: fix other minor namespace issues See previous commit.
2016-05-23 19:25:43 +00:00
gl_check_error(gl, hw->log, "Before uninitializing OpenGL interop");
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau: call glVDPAUFiniNV only if initialized This is "more correct". See #2798.
2016-02-08 12:39:33 +00:00
if (p->vdpgl_initialized)
gl->VDPAUFiniNV();
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau: call glVDPAUFiniNV only if initialized This is "more correct". See #2798.
2016-02-08 12:39:33 +00:00
p->vdpgl_initialized = false;
vo_opengl: fix other minor namespace issues See previous commit.
2016-05-23 19:25:43 +00:00
gl_check_error(gl, hw->log, "After uninitializing OpenGL interop");
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
}
static void destroy(struct gl_hwdec *hw)
{
struct priv *p = hw->priv;
destroy_objects(hw);
vo_opengl: make it work with vf_vdpaupp This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
2014-04-29 13:11:26 +00:00
mp_vdpau_mixer_destroy(p->mixer);
video: refactor how VO exports hwdec device handles The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
2016-05-09 17:42:03 +00:00
if (p->ctx)
hwdec_devices_remove(hw->devs, &p->ctx->hwctx);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
mp_vdpau_destroy(p->ctx);
}
static int create(struct gl_hwdec *hw)
{
vdpau/GLX: don't access VO backend Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
2014-12-03 20:13:59 +00:00
GL *gl = hw->gl;
Display *x11disp = glXGetCurrentDisplay();
if (!x11disp)
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
return -1;
if (!(gl->mpgl_caps & MPGL_CAP_VDPAU))
return -1;
struct priv *p = talloc_zero(hw, struct priv);
hw->priv = p;
vdpau: mp_msg conversions
2013-12-21 17:05:23 +00:00
p->log = hw->log;
video: reduce error message when loading hwdec backend fails When using --hwdec=auto, about half of all systems will print: "[vdpau] Error when calling vdp_device_create_x11: 1" this happens because usually mpv will be linked against both vdpau and vaapi libs, but the drivers are not necessarily available. Then trying to load a driver will fail. This is a normal part of probing, but the error messages were printed anyway. Silence them by explicitly distinguishing probing. This pretty much goes through all the layers. We actually consider loading hw backends for vo_opengl always "auto probed", even if a hw backend is explicitly requested. In this case vd_lavc will print a warning message anyway (adjust this message a bit).
2015-06-20 20:26:57 +00:00
p->ctx = mp_vdpau_create_device_x11(hw->log, x11disp, true);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
if (!p->ctx)
return -1;
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 19:49:32 +00:00
if (mp_vdpau_handle_preemption(p->ctx, &p->preemption_counter) < 1)
return -1;
vo_opengl: make it work with vf_vdpaupp This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
2014-04-29 13:11:26 +00:00
p->vdp_surface = VDP_INVALID_HANDLE;
p->mixer = mp_vdpau_mixer_create(p->ctx, hw->log);
vo_opengl: never load vaapi GLX interop by default Causes more harm than it helps. Will eventually be removed. Also rename the "reject_emulated" field to "probing" - this is more appropriate now.
2015-11-09 10:58:38 +00:00
if (hw->probing && mp_vdpau_guess_if_emulated(p->ctx)) {
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
destroy(hw);
return -1;
}
video: refactor how VO exports hwdec device handles The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
2016-05-09 17:42:03 +00:00
p->ctx->hwctx.driver_name = hw->driver->name;
hwdec_devices_add(hw->devs, &p->ctx->hwctx);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
return 0;
}
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
static int reinit(struct gl_hwdec *hw, struct mp_image_params *params)
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
{
struct priv *p = hw->priv;
vdpau/GLX: don't access VO backend Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
2014-12-03 20:13:59 +00:00
GL *gl = hw->gl;
vdpau: remove pointer indirection for a field There's no reason to. This is basically a cosmetic change.
2014-03-19 18:57:08 +00:00
struct vdp_functions *vdp = &p->ctx->vdp;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
VdpStatus vdp_st;
destroy_objects(hw);
vo_opengl: actually set hardware decoder mapped texture format Surfaces used by hardware decoding formats can be mapped exactly like a specific software pixel format, e.g. RGBA or NV12. p->image_params is supposed to be set to this format, but it wasn't. (How did this ever work?) Also, setting params->imgfmt in the hwdec interop drivers is pointless and redundant. (Change them to asserts, because why not.)
2015-09-24 21:48:57 +00:00
assert(params->imgfmt == hw->driver->imgfmt);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
p->image_params = *params;
vo_opengl: vdpau: better handling of preemption recovery If recovery from preemption is done successfully, continue normally. Only fail if it's preempted during init.
2016-01-25 18:40:35 +00:00
if (mp_vdpau_handle_preemption(p->ctx, &p->preemption_counter) < 0)
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
return -1;
gl_hwdec_vdpau: silence warning caused by buggy GL_NV_vdpau_interop spec VDPAU handles are integers, but for some reasons the VDPAU GL extension expects them as void*.
2013-11-09 22:31:12 +00:00
gl->VDPAUInitNV(BRAINDEATH(p->ctx->vdp_device), p->ctx->get_proc_address);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau: call glVDPAUFiniNV only if initialized This is "more correct". See #2798.
2016-02-08 12:39:33 +00:00
p->vdpgl_initialized = true;
vdpau: use libavutil for surface allocation during decoding Use the libavutil vdpau frame allocation code instead of our own "old" code. This also uses its code for copying a video surface to normal memory (used by vdpau-copy). Since vdpau doesn't really have an internal pixel format, 4:2:0 can be accessed as both nv12 and yuv420p - and libavutil prefers to report yuv420p. The OpenGL interop has to be adjusted accordingly. Preemption is a potential problem, but it doesn't break it more than it already is. This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well as taking screenshots) will fail. Libav has fixed this bug ages ago.
2017-01-17 10:00:31 +00:00
p->direct_mode = params->hw_subfmt == IMGFMT_NV12 ||
params->hw_subfmt == IMGFMT_420P;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
gl->GenTextures(4, p->gl_textures);
for (int n = 0; n < 4; n++) {
gl->BindTexture(GL_TEXTURE_2D, p->gl_textures[n]);
GLenum filter = p->direct_mode ? GL_NEAREST : GL_LINEAR;
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, filter);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, filter);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
}
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
gl->BindTexture(GL_TEXTURE_2D, 0);
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
if (p->direct_mode) {
params->imgfmt = IMGFMT_NV12;
vo_opengl: hwdec: reset hw_subfmt field In theory, mp_image_params with hw_subfmt set to non-0 if imgfmt is not a hwaccel format is invalid. (It worked fine because nothing checks this yet.)
2016-07-15 10:01:30 +00:00
params->hw_subfmt = 0;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
} else {
vdp_st = vdp->output_surface_create(p->ctx->vdp_device,
VDP_RGBA_FORMAT_B8G8R8A8,
params->w, params->h, &p->vdp_surface);
CHECK_VDP_ERROR(p, "Error when calling vdp_output_surface_create");
p->vdpgl_surface = gl->VDPAURegisterOutputSurfaceNV(BRAINDEATH(p->vdp_surface),
GL_TEXTURE_2D,
1, p->gl_textures);
if (!p->vdpgl_surface)
return -1;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
gl->VDPAUSurfaceAccessNV(p->vdpgl_surface, GL_READ_ONLY);
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
params->imgfmt = IMGFMT_RGB0;
vo_opengl: hwdec: reset hw_subfmt field In theory, mp_image_params with hw_subfmt set to non-0 if imgfmt is not a hwaccel format is invalid. (It worked fine because nothing checks this yet.)
2016-07-15 10:01:30 +00:00
params->hw_subfmt = 0;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
}
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
gl_check_error(gl, hw->log, "After initializing vdpau OpenGL interop");
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
return 0;
}
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
static int map_frame(struct gl_hwdec *hw, struct mp_image *hw_image,
struct gl_hwdec_frame *out_frame)
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
{
struct priv *p = hw->priv;
vdpau/GLX: don't access VO backend Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
2014-12-03 20:13:59 +00:00
GL *gl = hw->gl;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
struct vdp_functions *vdp = &p->ctx->vdp;
VdpStatus vdp_st;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 19:49:32 +00:00
int pe = mp_vdpau_handle_preemption(p->ctx, &p->preemption_counter);
if (pe < 1) {
mark_vdpau_objects_uninitialized(hw);
if (pe < 0)
return -1;
vo_opengl: fix another potential vdpau preemption issue reinit() will change the image params fields, so give it a copy. Will fix potential crashes if preemption happens more than once.
2016-09-07 16:22:36 +00:00
struct mp_image_params params = p->image_params;
if (reinit(hw, &params) < 0)
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 19:49:32 +00:00
return -1;
}
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
if (p->direct_mode) {
VdpVideoSurface surface = (intptr_t)hw_image->planes[3];
// We need the uncropped size.
VdpChromaType s_chroma_type;
uint32_t s_w, s_h;
vdp_st = vdp->video_surface_get_parameters(surface, &s_chroma_type, &s_w, &s_h);
CHECK_VDP_ERROR(hw, "Error when calling vdp_video_surface_get_parameters");
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
p->vdpgl_surface = gl->VDPAURegisterVideoSurfaceNV(BRAINDEATH(surface),
GL_TEXTURE_2D,
4, p->gl_textures);
if (!p->vdpgl_surface)
return -1;
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
gl->VDPAUSurfaceAccessNV(p->vdpgl_surface, GL_READ_ONLY);
gl->VDPAUMapSurfacesNV(1, &p->vdpgl_surface);
p->mapped = true;
*out_frame = (struct gl_hwdec_frame){
.vdpau_fields = true,
};
for (int n = 0; n < 4; n++) {
bool chroma = n >= 2;
out_frame->planes[n] = (struct gl_hwdec_plane){
.gl_texture = p->gl_textures[n],
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
.gl_target = GL_TEXTURE_2D,
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
.tex_w = s_w / (chroma ? 2 : 1),
.tex_h = s_h / (chroma ? 4 : 2),
};
};
} else {
if (!p->vdpgl_surface)
return -1;
mp_vdpau_mixer_render(p->mixer, NULL, p->vdp_surface, NULL, hw_image, NULL);
gl->VDPAUMapSurfacesNV(1, &p->vdpgl_surface);
p->mapped = true;
*out_frame = (struct gl_hwdec_frame){
.planes = {
{
.gl_texture = p->gl_textures[0],
.gl_target = GL_TEXTURE_2D,
.tex_w = p->image_params.w,
.tex_h = p->image_params.h,
},
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
},
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
};
}
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
return 0;
}
const struct gl_hwdec_driver gl_hwdec_vdpau = {
vo_opengl: hwdec: use IDs for API, and log which backend is used Since there can be multiple backends for a single API (vaapi can use GLX or EGL), not logging the exact backend name is annoying. So add it. At the same time, there is no need to duplicate the name as used by the --hwdec options, so replace it with using the numeric hwdec API ID.
2016-02-01 19:02:52 +00:00
.name = "vdpau-glx",
.api = HWDEC_VDPAU,
gl_hwdec: use a imgfmt field instead of a query_format callback Now that vdpau always uses a single image format, this can be simplified.
2013-11-29 13:19:51 +00:00
.imgfmt = IMGFMT_VDPAU,
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
.create = create,
.reinit = reinit,
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
.map_frame = map_frame,
.unmap = unmap,
vo_opengl: support for vdpau hardware decoding This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
2013-11-05 21:06:48 +00:00
.destroy = destroy,
};