github/mpv
1
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-10-30 04:46:41 +01:00
Code Releases Activity
8e87ddd7fe
mpv/video/vdpau_mixer.c

298 lines
11 KiB
C
Raw Normal View History

vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
/*
* This file is part of mpv.
*
* Parts of video mixer creation code:
* Copyright (C) 2008 NVIDIA (Rajib Mahapatra <rmahapatra@nvidia.com>)
* Copyright (C) 2009 Uoti Urpala
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* 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
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#include <assert.h>
#include "vdpau_mixer.h"
static void free_mixed_frame(void *arg)
{
struct mp_vdpau_mixer_frame *frame = arg;
talloc_free(frame);
}
// This creates an image of format IMGFMT_VDPAU with a mp_vdpau_mixer_frame
// struct. Use mp_vdpau_mixed_frame_get() to retrieve the struct and to
// initialize it.
// "base" is used only to set parameters, no image data is referenced.
struct mp_image *mp_vdpau_mixed_frame_create(struct mp_image *base)
{
assert(base->imgfmt == IMGFMT_VDPAU);
struct mp_vdpau_mixer_frame *frame =
talloc_zero(NULL, struct mp_vdpau_mixer_frame);
for (int n = 0; n < MP_VDP_HISTORY_FRAMES; n++)
frame->past[n] = frame->future[n] = VDP_INVALID_HANDLE;
frame->current = VDP_INVALID_HANDLE;
frame->field = VDP_VIDEO_MIXER_PICTURE_STRUCTURE_FRAME;
struct mp_image *mpi = mp_image_new_custom_ref(base, frame, free_mixed_frame);
video: introduce failure path for image allocations Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
if (mpi) {
mpi->planes[2] = (void *)frame;
mpi->planes[3] = (void *)(uintptr_t)VDP_INVALID_HANDLE;
}
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
return mpi;
}
struct mp_vdpau_mixer_frame *mp_vdpau_mixed_frame_get(struct mp_image *mpi)
{
if (mpi->imgfmt != IMGFMT_VDPAU)
return NULL;
return (void *)mpi->planes[2];
}
struct mp_vdpau_mixer *mp_vdpau_mixer_create(struct mp_vdpau_ctx *vdp_ctx,
struct mp_log *log)
{
struct mp_vdpau_mixer *mixer = talloc_ptrtype(NULL, mixer);
*mixer = (struct mp_vdpau_mixer){
.ctx = vdp_ctx,
.log = log,
.video_mixer = VDP_INVALID_HANDLE,
.video_eq = {
.capabilities = MP_CSP_EQ_CAPS_COLORMATRIX,
},
};
return mixer;
}
void mp_vdpau_mixer_destroy(struct mp_vdpau_mixer *mixer)
{
struct vdp_functions *vdp = &mixer->ctx->vdp;
VdpStatus vdp_st;
if (mixer->video_mixer != VDP_INVALID_HANDLE) {
vdp_st = vdp->video_mixer_destroy(mixer->video_mixer);
CHECK_VDP_WARNING(mixer, "Error when calling vdp_video_mixer_destroy");
}
talloc_free(mixer);
}
static bool opts_equal(const struct mp_vdpau_mixer_opts *a,
const struct mp_vdpau_mixer_opts *b)
{
return a->deint == b->deint && a->chroma_deint == b->chroma_deint &&
a->pullup == b->pullup && a->hqscaling == b->hqscaling &&
a->sharpen == b->sharpen && a->denoise == b->denoise;
}
static int set_video_attribute(struct mp_vdpau_mixer *mixer,
VdpVideoMixerAttribute attr,
const void *value, char *attr_name)
{
struct vdp_functions *vdp = &mixer->ctx->vdp;
VdpStatus vdp_st;
vdp_st = vdp->video_mixer_set_attribute_values(mixer->video_mixer, 1,
&attr, &value);
if (vdp_st != VDP_STATUS_OK) {
MP_ERR(mixer, "Error setting video mixer attribute %s: %s\n", attr_name,
vdp->get_error_string(vdp_st));
return -1;
}
return 0;
}
#define SET_VIDEO_ATTR(attr_name, attr_type, value) set_video_attribute(mixer, \
VDP_VIDEO_MIXER_ATTRIBUTE_ ## attr_name, &(attr_type){value},\
# attr_name)
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
static int create_vdp_mixer(struct mp_vdpau_mixer *mixer,
VdpChromaType chroma_type, uint32_t w, uint32_t h)
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
{
struct vdp_functions *vdp = &mixer->ctx->vdp;
VdpDevice vdp_device = mixer->ctx->vdp_device;
struct mp_vdpau_mixer_opts *opts = &mixer->opts;
#define VDP_NUM_MIXER_PARAMETER 3
#define MAX_NUM_FEATURES 6
int i;
VdpStatus vdp_st;
MP_VERBOSE(mixer, "Recreating vdpau video mixer.\n");
int feature_count = 0;
VdpVideoMixerFeature features[MAX_NUM_FEATURES];
VdpBool feature_enables[MAX_NUM_FEATURES];
static const VdpVideoMixerParameter parameters[VDP_NUM_MIXER_PARAMETER] = {
VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH,
VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT,
VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE,
};
const void *const parameter_values[VDP_NUM_MIXER_PARAMETER] = {
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
&(uint32_t){w},
&(uint32_t){h},
&(VdpChromaType){chroma_type},
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
};
if (opts->deint >= 3)
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL;
if (opts->deint == 4)
features[feature_count++] =
VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL;
if (opts->pullup)
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE;
if (opts->denoise)
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_NOISE_REDUCTION;
if (opts->sharpen)
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_SHARPNESS;
if (opts->hqscaling) {
VdpVideoMixerFeature hqscaling_feature =
VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1 + opts->hqscaling - 1;
VdpBool hqscaling_available;
vdp_st = vdp->video_mixer_query_feature_support(vdp_device,
hqscaling_feature,
&hqscaling_available);
CHECK_VDP_ERROR(mixer, "Error when calling video_mixer_query_feature_support");
if (hqscaling_available) {
features[feature_count++] = hqscaling_feature;
} else {
MP_ERR(mixer, "Your hardware or VDPAU library does not support "
"requested hqscaling.\n");
}
}
vdp_st = vdp->video_mixer_create(vdp_device, feature_count, features,
VDP_NUM_MIXER_PARAMETER,
parameters, parameter_values,
&mixer->video_mixer);
vdpau: correctly mark invalid mixer as such on vdp_video_mixer_create() failure Otherwise vdp_video_mixer_destroy() would later fail when called on an invalid video mixer handle. With mesa r600 vdpau driver, this would cause a segfault.
2014-08-13 17:51:07 +02:00
if (vdp_st != VDP_STATUS_OK)
mixer->video_mixer = VDP_INVALID_HANDLE;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
CHECK_VDP_ERROR(mixer, "Error when calling vdp_video_mixer_create");
mixer->initialized = true;
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
mixer->current_chroma_type = chroma_type;
mixer->current_w = w;
mixer->current_h = h;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
for (i = 0; i < feature_count; i++)
feature_enables[i] = VDP_TRUE;
if (feature_count) {
vdp_st = vdp->video_mixer_set_feature_enables(mixer->video_mixer,
feature_count, features,
feature_enables);
CHECK_VDP_WARNING(mixer, "Error calling vdp_video_mixer_set_feature_enables");
}
if (opts->denoise)
SET_VIDEO_ATTR(NOISE_REDUCTION_LEVEL, float, opts->denoise);
if (opts->sharpen)
SET_VIDEO_ATTR(SHARPNESS_LEVEL, float, opts->sharpen);
if (!opts->chroma_deint)
SET_VIDEO_ATTR(SKIP_CHROMA_DEINTERLACE, uint8_t, 1);
csputils: replace float[3][4] with a struct Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
2015-01-06 16:49:53 +01:00
struct mp_cmat yuv2rgb;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
VdpCSCMatrix matrix;
struct mp_csp_params cparams = MP_CSP_PARAMS_DEFAULTS;
csputils: move image_params -> csp_params into a function Although the line count increases, this is better for making sure everything is handled consistently for all users of the mp_csp_params stuff. This also makes sure mp_csp_params is always initialized with MP_CSP_PARAMS_DEFAULTS (for consistency).
2015-01-06 15:21:26 +01:00
mp_csp_set_image_params(&cparams, &mixer->image_params);
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
mp_csp_copy_equalizer_values(&cparams, &mixer->video_eq);
csputils: rename "yuv2rgb" functions They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-09 00:22:12 +01:00
mp_get_csp_matrix(&cparams, &yuv2rgb);
csputils: replace float[3][4] with a struct Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
2015-01-06 16:49:53 +01:00
for (int r = 0; r < 3; r++) {
for (int c = 0; c < 3; c++)
matrix[r][c] = yuv2rgb.m[r][c];
matrix[r][3] = yuv2rgb.c[r];
}
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
set_video_attribute(mixer, VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX,
&matrix, "CSC matrix");
return 0;
}
vdpau_mixer: allow overriding frame opts So a caller can override the filter options dictated by vf_vdpaupp.
2014-04-29 15:12:38 +02:00
// If opts is NULL, use the opts as implied by the video image.
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
int mp_vdpau_mixer_render(struct mp_vdpau_mixer *mixer,
vdpau_mixer: allow overriding frame opts So a caller can override the filter options dictated by vf_vdpaupp.
2014-04-29 15:12:38 +02:00
struct mp_vdpau_mixer_opts *opts,
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
VdpOutputSurface output, VdpRect *output_rect,
struct mp_image *video, VdpRect *video_rect)
{
struct vdp_functions *vdp = &mixer->ctx->vdp;
VdpStatus vdp_st;
vdpau: always render to cropped size at most vo_opengl (or gl_hwdec_vdpau.c to be specific) calls mp_vdpau_mixer_render() with video_rect=NULL, which means to use the full surface. This is incorrect if the surface is actually cropped, as it can happen with h264. In this case, it was rendering the parts outside of the image. Fix it by making this case use the cropped size instead. Alternative fix for PR #1863.
2015-04-26 18:56:46 +02:00
VdpRect fallback_rect = {0, 0, video->w, video->h};
if (!video_rect)
video_rect = &fallback_rect;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
video: handle hwdec screenshots differently Instead of converting the hw surface to an image in the VO, provide a generic way to convet hw surfaces, and use this in the screenshot code. It's all relatively straightforward, except vdpau is being terrible. It needs a huge chunk of new code, because copying back is not simple.
2015-01-22 17:47:14 +01:00
if (video->imgfmt == IMGFMT_VDPAU_OUTPUT) {
VdpOutputSurface surface = (uintptr_t)video->planes[3];
int flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_0;
vdp_st = vdp->output_surface_render_output_surface(output,
output_rect,
surface,
video_rect,
NULL, NULL, flags);
CHECK_VDP_WARNING(mixer, "Error when calling "
"vdp_output_surface_render_output_surface");
return 0;
}
if (video->imgfmt != IMGFMT_VDPAU)
return -1;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
struct mp_vdpau_mixer_frame *frame = mp_vdpau_mixed_frame_get(video);
struct mp_vdpau_mixer_frame fallback = {{0}};
if (!frame) {
frame = &fallback;
frame->current = (uintptr_t)video->planes[3];
for (int n = 0; n < MP_VDP_HISTORY_FRAMES; n++)
frame->past[n] = frame->future[n] = VDP_INVALID_HANDLE;
frame->field = VDP_VIDEO_MIXER_PICTURE_STRUCTURE_FRAME;
}
vdpau_mixer: allow overriding frame opts So a caller can override the filter options dictated by vf_vdpaupp.
2014-04-29 15:12:38 +02:00
if (!opts)
opts = &frame->opts;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
if (mixer->video_mixer == VDP_INVALID_HANDLE)
mixer->initialized = false;
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
VdpChromaType s_chroma_type;
uint32_t s_w, s_h;
vdp_st = vdp->video_surface_get_parameters(frame->current, &s_chroma_type,
&s_w, &s_h);
CHECK_VDP_ERROR(mixer, "Error when calling vdp_video_surface_get_parameters");
vdpau_mixer: allow overriding frame opts So a caller can override the filter options dictated by vf_vdpaupp.
2014-04-29 15:12:38 +02:00
if (!mixer->initialized || !opts_equal(opts, &mixer->opts) ||
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
!mp_image_params_equal(&video->params, &mixer->image_params) ||
mixer->current_w != s_w || mixer->current_h != s_h ||
mixer->current_chroma_type != s_chroma_type)
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
{
vdpau_mixer: allow overriding frame opts So a caller can override the filter options dictated by vf_vdpaupp.
2014-04-29 15:12:38 +02:00
mixer->opts = *opts;
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
mixer->image_params = video->params;
if (mixer->video_mixer != VDP_INVALID_HANDLE) {
vdp_st = vdp->video_mixer_destroy(mixer->video_mixer);
CHECK_VDP_WARNING(mixer, "Error when calling vdp_video_mixer_destroy");
}
mixer->video_mixer = VDP_INVALID_HANDLE;
mixer->initialized = false;
vdpau: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
if (create_vdp_mixer(mixer, s_chroma_type, s_w, s_h) < 0)
vdpau: add a postprocessing pseudo-filter This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
2014-04-29 15:07:21 +02:00
return -1;
}
vdp_st = vdp->video_mixer_render(mixer->video_mixer, VDP_INVALID_HANDLE,
0, frame->field,
MP_VDP_HISTORY_FRAMES, frame->past,
frame->current,
MP_VDP_HISTORY_FRAMES, frame->future,
video_rect,
output, NULL, output_rect,
0, NULL);
CHECK_VDP_WARNING(mixer, "Error when calling vdp_video_mixer_render");
return 0;
}
Copy Permalink