diff options
author | wm4 <wm4@nowhere> | 2013-07-16 23:22:55 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2013-07-16 23:22:55 +0200 |
commit | 18b6c01d921c1dea0986bba4bcd867da5605a3d8 (patch) | |
tree | 3489728f82c0270a72005f64590781118b02540f /video/filter/vf.c | |
parent | a98aad61f854d9a216675dc54096aa39767c4a35 (diff) | |
download | mpv-18b6c01d921c1dea0986bba4bcd867da5605a3d8.tar.bz2 mpv-18b6c01d921c1dea0986bba4bcd867da5605a3d8.tar.xz |
video: redo how colorspaces are handled
Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of
the normal video format negotiation. The colorspace is passed down like
other video params with config/reconfig calls.
Forcing colorspaces (via the --colormatrix options and properties) is
handled differently too: if it's changed, completely reinit the video
chain. This is slower and requires a precise seek to the same position
to perform an update, but it's simpler and less bug-prone. Considering
switching the colorspace at runtime by user-interaction is a rather
obscure feature, this is a good change.
The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it,
and would have to be changed to get rid of them. We'll do that later,
and convert them incrementally instead of in one go.
Note that controlling the output range now always works on VO level.
Basically, this means you can't get vf_scale to output full-range YUV
for whatever reason. If that is really wanted, it should be a vf_scale
option. the previous behavior didn't make too much sense anyway.
This commit fixes a few bugs (such as playing RGB video and converting
that to YUV with vf_scale - a recent commit broke this and forced the
VO to display YUV as RGB if possible), and might introduce some new
ones.
Diffstat (limited to 'video/filter/vf.c')
-rw-r--r-- | video/filter/vf.c | 17 |
1 files changed, 16 insertions, 1 deletions
diff --git a/video/filter/vf.c b/video/filter/vf.c index 1570e8402c..8946aeb801 100644 --- a/video/filter/vf.c +++ b/video/filter/vf.c @@ -170,6 +170,8 @@ static void print_fmt(int msglevel, struct vf_format *fmt) mp_msg(MSGT_VFILTER, msglevel, "->%dx%d", p->d_w, p->d_h); mp_msg(MSGT_VFILTER, msglevel, " %s %#x", mp_imgfmt_to_name(p->imgfmt), fmt->flags); + mp_msg(MSGT_VFILTER, msglevel, " %s/%s", mp_csp_names[p->colorspace], + mp_csp_levels_names[p->colorlevels]); } else { mp_msg(MSGT_VFILTER, msglevel, "???"); } @@ -357,8 +359,19 @@ unsigned int vf_match_csp(vf_instance_t **vfp, const unsigned int *list, // Ownership of img is transferred from caller to the filter chain. void vf_add_output_frame(struct vf_instance *vf, struct mp_image *img) { - if (img) + if (img) { + struct mp_image_params *p = &vf->fmt_out.params; + // vf_vo doesn't have output config + if (vf->fmt_out.configured) { + assert(p->imgfmt == img->imgfmt); + assert(p->w == img->w && p->h == img->h); + // Too many filters which don't set these correctly + img->colorspace = p->colorspace; + img->levels = p->colorlevels; + img->chroma_location = p->chroma_location; + } MP_TARRAY_APPEND(vf, vf->out_queued, vf->num_out_queued, img); + } } static struct mp_image *vf_dequeue_output_frame(struct vf_instance *vf) @@ -486,6 +499,8 @@ int vf_next_config(struct vf_instance *vf, .colorlevels = vf->fmt_in.params.colorlevels, .chroma_location = vf->fmt_in.params.chroma_location, }; + // Fix csp in case of pixel format change + mp_image_params_guess_csp(&p); int r = vf_reconfig_wrapper(vf->next, &p, voflags); return r < 0 ? 0 : 1; } |