[PATCH] winegstreamer: Color matrix conversions are needed for YUV -> RGB conversion and vice versa.

[Akihiro Sagawa]

Otherwise, for instance, we get a strange color image when viewing an MPEG
movie with RGB32 video renderer.
Fixes a regression introduced by fd25ba65e0eb9fedfb2cdfa2b7a4b16e0401dfdf.

Signed-off-by: Akihiro Sagawa 
---
 dlls/winegstreamer/gstdemux.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

[Zebediah Figura]

On 10/11/20 9:52 AM, Akihiro Sagawa wrote:
> Otherwise, for instance, we get a strange color image when viewing an MPEG
> movie with RGB32 video renderer.
> Fixes a regression introduced by fd25ba65e0eb9fedfb2cdfa2b7a4b16e0401dfdf.
> Signed-off-by: Akihiro Sagawa
>
> dlls/winegstreamer/gstdemux.c | 30 ++++++++++++++++++++++++++----
>  1 file changed, 26 insertions(+), 4 deletions(-)

Unfortunately this isn't really correct, since there might be two format
conversions, and we shouldn't really depend on the second videoconvert
being the only one to change color spaces—it might be the first, or it
might be both.

Trying to copy the colorimetry that's given to us helps a bit, but not
entirely. Because videoconvert basically clears colorimetry when
proposing formats downstream, if both of our videoconvert elements do
format conversions, the first will still do a color space conversion we
don't want.

It seems a bit undesirable to me that videoconvert clears colorimetry
when doing YUV <-> YUV transformations (and when a specific colorimetry
isn't requested). It would be nice if we could modify gstreamer to not
do that. My best guess is that we'd want an extra config option (default
off) that, when set, preserves the color matrix of the upstream element
when converting YUV to YUV; in that case negotiation would fail if the
downstream element requests a specific different color matrix. I may try
to write up such a patch in the near future, but someone else is free to
preëmpt me...