mpv/video/filter/vf_scale.c

429 lines
12 KiB
C
Raw Normal View History

/*
* This file is part of MPlayer.
*
* MPlayer 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.
*
* MPlayer 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 MPlayer; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <inttypes.h>
#include <sys/types.h>
#include <libswscale/swscale.h>
#include "config.h"
#include "common/msg.h"
#include "options/options.h"
#include "video/img_format.h"
#include "video/mp_image.h"
#include "vf.h"
#include "video/fmt-conversion.h"
#include "video/sws_utils.h"
#include "video/csputils.h"
#include "video/out/vo.h"
video, options: implement better YUV->RGB conversion control Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
#include "options/m_option.h"
static struct vf_priv_s {
2013-07-18 11:13:03 +00:00
int w, h;
int cfg_w, cfg_h;
int v_chr_drop;
double param[2];
2013-07-18 11:41:38 +00:00
struct mp_sws_context *sws;
int noup;
int accurate_rnd;
} const vf_priv_dflt = {
2013-07-18 11:13:03 +00:00
0, 0,
-1, -1,
0,
{SWS_PARAM_DEFAULT, SWS_PARAM_DEFAULT},
};
//===========================================================================//
2013-07-18 11:13:03 +00:00
static const unsigned int outfmt_list[] = {
// YUV:
IMGFMT_444P,
IMGFMT_444P16_LE,
IMGFMT_444P16_BE,
IMGFMT_444P14_LE,
IMGFMT_444P14_BE,
IMGFMT_444P12_LE,
IMGFMT_444P12_BE,
IMGFMT_444P10_LE,
IMGFMT_444P10_BE,
IMGFMT_444P9_LE,
IMGFMT_444P9_BE,
IMGFMT_422P,
IMGFMT_422P16_LE,
IMGFMT_422P16_BE,
IMGFMT_422P14_LE,
IMGFMT_422P14_BE,
IMGFMT_422P12_LE,
IMGFMT_422P12_BE,
IMGFMT_422P10_LE,
IMGFMT_422P10_BE,
IMGFMT_422P9_LE,
IMGFMT_422P9_BE,
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
IMGFMT_420P,
IMGFMT_420P16_LE,
IMGFMT_420P16_BE,
IMGFMT_420P14_LE,
IMGFMT_420P14_BE,
IMGFMT_420P12_LE,
IMGFMT_420P12_BE,
IMGFMT_420P10_LE,
IMGFMT_420P10_BE,
IMGFMT_420P9_LE,
IMGFMT_420P9_BE,
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
IMGFMT_420AP,
IMGFMT_410P,
IMGFMT_411P,
IMGFMT_NV12,
IMGFMT_NV21,
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
IMGFMT_YUYV,
IMGFMT_UYVY,
IMGFMT_440P,
// RGB and grayscale (Y8 and Y800):
IMGFMT_BGR32,
IMGFMT_RGB32,
IMGFMT_ABGR,
IMGFMT_ARGB,
IMGFMT_BGRA,
IMGFMT_RGBA,
IMGFMT_BGR24,
IMGFMT_RGB24,
IMGFMT_GBRP,
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
IMGFMT_RGB48_LE,
IMGFMT_RGB48_BE,
IMGFMT_BGR565,
IMGFMT_RGB565,
IMGFMT_BGR555,
IMGFMT_RGB555,
IMGFMT_BGR444,
IMGFMT_RGB444,
IMGFMT_Y8,
IMGFMT_BGR8,
IMGFMT_RGB8,
IMGFMT_BGR4,
IMGFMT_RGB4,
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
IMGFMT_RGB4_BYTE,
IMGFMT_BGR4_BYTE,
IMGFMT_MONO,
IMGFMT_MONO_W,
0
};
/**
* A list of preferred conversions, in order of preference.
* This should be used for conversions that e.g. involve no scaling
* or to stop vf_scale from choosing a conversion that has no
* fast assembler implementation.
*/
static const int preferred_conversions[][2] = {
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
{IMGFMT_YUYV, IMGFMT_UYVY},
{IMGFMT_YUYV, IMGFMT_422P},
{IMGFMT_UYVY, IMGFMT_YUYV},
{IMGFMT_UYVY, IMGFMT_422P},
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
{IMGFMT_422P, IMGFMT_YUYV},
{IMGFMT_422P, IMGFMT_UYVY},
video: decouple internal pixel formats from FourCCs mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
2012-12-23 19:03:30 +00:00
{IMGFMT_420P10, IMGFMT_420P},
{IMGFMT_GBRP, IMGFMT_BGR24},
{IMGFMT_GBRP, IMGFMT_RGB24},
{IMGFMT_GBRP, IMGFMT_BGR32},
{IMGFMT_GBRP, IMGFMT_RGB32},
{IMGFMT_PAL8, IMGFMT_BGR32},
{IMGFMT_XYZ12, IMGFMT_RGB48},
{0, 0}
};
static int check_outfmt(vf_instance_t *vf, int outfmt)
{
enum AVPixelFormat pixfmt = imgfmt2pixfmt(outfmt);
if (pixfmt == AV_PIX_FMT_NONE || sws_isSupportedOutput(pixfmt) < 1)
return 0;
return vf_next_query_format(vf, outfmt);
}
2013-07-18 11:13:03 +00:00
static unsigned int find_best_out(vf_instance_t *vf, int in_format)
{
unsigned int best = 0;
int i = -1;
int j = -1;
int format = 0;
// find the best outfmt:
while (1) {
int ret;
if (j < 0) {
format = in_format;
j = 0;
} else if (i < 0) {
while (preferred_conversions[j][0] &&
preferred_conversions[j][0] != in_format)
j++;
format = preferred_conversions[j++][1];
// switch to standard list
if (!format)
i = 0;
}
if (i >= 0)
format = outfmt_list[i++];
if (!format)
break;
ret = check_outfmt(vf, format);
2013-12-21 16:43:25 +00:00
MP_DBG(vf, "scale: query(%s) -> %d\n", vo_format_name(format), ret & 3);
2013-07-18 11:13:03 +00:00
if (ret & VFCAP_CSP_SUPPORTED_BY_HW) {
best = format; // no conversion -> bingo!
break;
}
2013-07-18 11:13:03 +00:00
if (ret & VFCAP_CSP_SUPPORTED && !best)
best = format; // best with conversion
}
if (!best) {
// Try anything else. outfmt_list is just a list of preferred formats.
for (int cur = IMGFMT_START; cur < IMGFMT_END; cur++) {
int ret = check_outfmt(vf, cur);
if (ret & VFCAP_CSP_SUPPORTED_BY_HW) {
best = cur; // no conversion -> bingo!
break;
}
if (ret & VFCAP_CSP_SUPPORTED && !best)
best = cur; // best with conversion
}
}
return best;
}
static int reconfig(struct vf_instance *vf, struct mp_image_params *in,
struct mp_image_params *out)
{
int width = in->w, height = in->h, d_width = in->d_w, d_height = in->d_h;
unsigned int outfmt = in->imgfmt;
2013-07-18 11:13:03 +00:00
unsigned int best = find_best_out(vf, outfmt);
int round_w = 0, round_h = 0;
2013-07-18 11:13:03 +00:00
if (!best) {
2013-12-21 16:43:25 +00:00
MP_WARN(vf, "SwScale: no supported outfmt found :(\n");
2013-07-18 11:13:03 +00:00
return -1;
}
2013-07-18 11:13:03 +00:00
vf->next->query_format(vf->next, best);
vf->priv->w = vf->priv->cfg_w;
vf->priv->h = vf->priv->cfg_h;
if (vf->priv->w <= -8) {
2013-07-18 11:13:03 +00:00
vf->priv->w += 8;
round_w = 1;
}
if (vf->priv->h <= -8) {
2013-07-18 11:13:03 +00:00
vf->priv->h += 8;
round_h = 1;
}
if (vf->priv->w < -3 || vf->priv->h < -3 ||
2013-07-18 11:13:03 +00:00
(vf->priv->w < -1 && vf->priv->h < -1))
{
// TODO: establish a direct connection to the user's brain
// and find out what the heck he thinks MPlayer should do
// with this nonsense.
2013-12-21 16:43:25 +00:00
MP_ERR(vf, "SwScale: EUSERBROKEN Check your parameters, they make no sense!\n");
2013-07-18 11:13:03 +00:00
return -1;
}
if (vf->priv->w == -1)
2013-07-18 11:13:03 +00:00
vf->priv->w = width;
if (vf->priv->w == 0)
2013-07-18 11:13:03 +00:00
vf->priv->w = d_width;
if (vf->priv->h == -1)
2013-07-18 11:13:03 +00:00
vf->priv->h = height;
if (vf->priv->h == 0)
2013-07-18 11:13:03 +00:00
vf->priv->h = d_height;
if (vf->priv->w == -3)
2013-07-18 11:13:03 +00:00
vf->priv->w = vf->priv->h * width / height;
if (vf->priv->w == -2)
2013-07-18 11:13:03 +00:00
vf->priv->w = vf->priv->h * d_width / d_height;
if (vf->priv->h == -3)
2013-07-18 11:13:03 +00:00
vf->priv->h = vf->priv->w * height / width;
if (vf->priv->h == -2)
2013-07-18 11:13:03 +00:00
vf->priv->h = vf->priv->w * d_height / d_width;
if (round_w)
2013-07-18 11:13:03 +00:00
vf->priv->w = ((vf->priv->w + 8) / 16) * 16;
if (round_h)
2013-07-18 11:13:03 +00:00
vf->priv->h = ((vf->priv->h + 8) / 16) * 16;
// check for upscaling, now that all parameters had been applied
2013-07-18 11:13:03 +00:00
if (vf->priv->noup) {
if ((vf->priv->w > width) + (vf->priv->h > height) >= vf->priv->noup) {
vf->priv->w = width;
vf->priv->h = height;
}
}
2013-12-21 16:43:25 +00:00
MP_DBG(vf, "SwScale: scaling %dx%d %s to %dx%d %s \n",
2013-07-18 11:13:03 +00:00
width, height, vo_format_name(outfmt), vf->priv->w, vf->priv->h,
vo_format_name(best));
2013-07-18 11:13:03 +00:00
// Compute new d_width and d_height, preserving aspect
// while ensuring that both are >= output size in pixels.
if (vf->priv->h * d_width > vf->priv->w * d_height) {
d_width = vf->priv->h * d_width / d_height;
d_height = vf->priv->h;
} else {
d_height = vf->priv->w * d_height / d_width;
d_width = vf->priv->w;
}
*out = *in;
out->w = vf->priv->w;
out->h = vf->priv->h;
out->d_w = d_width;
out->d_h = d_height;
out->imgfmt = best;
2013-07-18 11:41:38 +00:00
// Second-guess what libswscale is going to output and what not.
// It depends what libswscale supports for in/output, and what makes sense.
struct mp_imgfmt_desc s_fmt = mp_imgfmt_get_desc(in->imgfmt);
struct mp_imgfmt_desc d_fmt = mp_imgfmt_get_desc(out->imgfmt);
2013-07-18 11:41:38 +00:00
// keep colorspace settings if the data stays in yuv
if (!(s_fmt.flags & MP_IMGFLAG_YUV) || !(d_fmt.flags & MP_IMGFLAG_YUV)) {
out->colorspace = MP_CSP_AUTO;
out->colorlevels = MP_CSP_LEVELS_AUTO;
2013-07-18 11:41:38 +00:00
}
mp_image_params_guess_csp(out);
mp_sws_set_from_cmdline(vf->priv->sws, vf->chain->opts->vo.sws_opts);
2013-07-18 11:41:38 +00:00
vf->priv->sws->flags |= vf->priv->v_chr_drop << SWS_SRC_V_CHR_DROP_SHIFT;
vf->priv->sws->flags |= vf->priv->accurate_rnd * SWS_ACCURATE_RND;
vf->priv->sws->src = *in;
vf->priv->sws->dst = *out;
2013-07-18 11:41:38 +00:00
if (mp_sws_reinit(vf->priv->sws) < 0) {
// error...
2013-12-21 16:43:25 +00:00
MP_WARN(vf, "Couldn't init libswscale for this setup\n");
2013-07-18 11:41:38 +00:00
return -1;
}
return 0;
}
static struct mp_image *filter(struct vf_instance *vf, struct mp_image *mpi)
{
struct mp_image *dmpi = vf_alloc_out_image(vf);
if (!dmpi)
return NULL;
mp_image_copy_attributes(dmpi, mpi);
2013-07-18 11:41:38 +00:00
mp_sws_scale(vf->priv->sws, dmpi, mpi);
talloc_free(mpi);
return dmpi;
}
2013-07-18 11:13:03 +00:00
static int control(struct vf_instance *vf, int request, void *data)
{
2013-07-18 11:41:38 +00:00
struct mp_sws_context *sws = vf->priv->sws;
switch (request) {
case VFCTRL_GET_EQUALIZER:
if (mp_sws_get_vf_equalizer(sws, data) < 1)
2013-07-18 11:41:38 +00:00
break;
return CONTROL_TRUE;
case VFCTRL_SET_EQUALIZER:
if (mp_sws_set_vf_equalizer(sws, data) < 1)
2013-07-18 11:13:03 +00:00
break;
2013-07-18 11:41:38 +00:00
return CONTROL_TRUE;
video, options: implement better YUV->RGB conversion control Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
}
return CONTROL_UNKNOWN;
video, options: implement better YUV->RGB conversion control Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
}
//===========================================================================//
2013-07-18 11:13:03 +00:00
static int query_format(struct vf_instance *vf, unsigned int fmt)
{
if (!IMGFMT_IS_HWACCEL(fmt) && imgfmt2pixfmt(fmt) != AV_PIX_FMT_NONE) {
if (sws_isSupportedInput(imgfmt2pixfmt(fmt)) < 1)
return 0;
2013-07-18 11:13:03 +00:00
unsigned int best = find_best_out(vf, fmt);
int flags;
if (!best)
return 0; // no matching out-fmt
flags = vf_next_query_format(vf, best);
if (!(flags & (VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW)))
return 0;
if (fmt != best)
flags &= ~VFCAP_CSP_SUPPORTED_BY_HW;
return flags;
}
2013-07-18 11:13:03 +00:00
return 0; // nomatching in-fmt
}
2013-07-18 11:13:03 +00:00
static void uninit(struct vf_instance *vf)
{
}
static int vf_open(vf_instance_t *vf)
2013-07-18 11:13:03 +00:00
{
vf->reconfig = reconfig;
vf->filter = filter;
vf->query_format = query_format;
vf->control = control;
vf->uninit = uninit;
2013-07-18 11:41:38 +00:00
vf->priv->sws = mp_sws_alloc(vf);
vf->priv->sws->log = vf->log;
vf->priv->sws->params[0] = vf->priv->param[0];
vf->priv->sws->params[1] = vf->priv->param[1];
2013-12-21 16:43:25 +00:00
MP_VERBOSE(vf, "SwScale params: %d x %d (-1=no scaling)\n",
2013-07-18 11:13:03 +00:00
vf->priv->cfg_w, vf->priv->cfg_h);
return 1;
}
#define OPT_BASE_STRUCT struct vf_priv_s
2008-04-26 13:35:40 +00:00
static const m_option_t vf_opts_fields[] = {
OPT_INT("w", cfg_w, M_OPT_MIN, .min = -11),
OPT_INT("h", cfg_h, M_OPT_MIN, .min = -11),
OPT_DOUBLE("param", param[0], M_OPT_RANGE, .min = 0.0, .max = 100.0),
OPT_DOUBLE("param2", param[1], M_OPT_RANGE, .min = 0.0, .max = 100.0),
OPT_INTRANGE("chr-drop", v_chr_drop, 0, 0, 3),
OPT_INTRANGE("noup", noup, 0, 0, 2),
OPT_FLAG("arnd", accurate_rnd, 0),
{0}
};
const vf_info_t vf_info_scale = {
.description = "software scaling",
.name = "scale",
.open = vf_open,
.priv_size = sizeof(struct vf_priv_s),
.priv_defaults = &vf_priv_dflt,
.options = vf_opts_fields,
};
//===========================================================================//