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, 0 deletions

diff --git a/core/mplayer.c b/core/mplayer.c
index 363d89cc53..c2efe82f13 100644
--- a/core/mplayer.c
+++ b/core/mplayer.c
@@ -2385,6 +2385,7 @@ void mp_force_video_refresh(struct MPContext *mpctx)
 {
     struct MPOpts *opts = &mpctx->opts;
 
+    // If not paused, the next frame should come soon enough.
     if (opts->pause && mpctx->last_vo_pts != MP_NOPTS_VALUE)
         queue_seek(mpctx, MPSEEK_ABSOLUTE, mpctx->last_vo_pts, 1);
 }