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.

1 files changed, 1 insertions, 1 deletions

diff --git a/video/decode/dec_video.h b/video/decode/dec_video.h
index 88161ee54f..141442fa19 100644
--- a/video/decode/dec_video.h
+++ b/video/decode/dec_video.h
@@ -39,7 +39,7 @@ int get_video_colors(sh_video_t *sh_video, const char *item, int *value);
 int set_video_colors(sh_video_t *sh_video, const char *item, int value);
 struct mp_image_params;
 bool get_video_params(struct sh_video *sh, struct mp_image_params *p);
-void set_video_colorspace(struct sh_video *sh);
+void set_video_output_levels(struct sh_video *sh);
 void resync_video_stream(sh_video_t *sh_video);
 void video_reinit_vo(struct sh_video *sh_video);
 int get_current_video_decoder_lag(sh_video_t *sh_video);