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 sagawa.aki@gmail.com
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...