GStreamer apparently rendering full range color [0-255] as limited range [16-235] is this a GStreamer or monitor issue?

Apple’s Airplay (screen mirror) sends h264 video in Full range BT709 colorspace as opposed to limited range. (1:3:5:1) (full -range BT709 is not common, but allowed by the standard).

When the following page is viewed with airplay screen mirroring rendered by GStreamer on Linux (xvimagesink, but also other videosinks such as glimagesink)
the central two strips are indistinguishable white.

Could this be something that needs to be tracked down and fixed in GStreamer, or something that could be fixed in the app with GST_VIDEO_COLOR_RANGE_0_255
somewhere?

where would one start to look?

EDIT: this issue is seen on Linux and freeBSD, but not on Windows or macOS.

What version of GStreamer are you using? What pipeline? The OpenGL elements have only recently supported arbitrary color matrix conversions (including full vs limited range). Using xvimagesink may be a XV driver limitation (which generally uses OpenGL glamor under the hood and may not handle the limited vs full range case correctly).

GStreamer 1.24.10 and all earlier.

Things work perfectly with GStreamer on macOS and Windows…

There were earlier problems with recognizing BT709 Full Range (1:3:5;1)
in video4linux2 (for R Pi hardware h264 decoding) that i got fixed in GStreamer-1.20.4 but this seems unrelated since its seen on x86_64 without v4l2. v4l2object.c: add support for Apple's full-range bt709 colorspace variant (197b72f3) · Commits · GStreamer / gstreamer · GitLab

I was not aware of the present issue until users pointed it out. (I will go back and check on older GStreamer installations to make sure it’s not a regression).

here is the video pipeline:

appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! videoscale ! autovideosink name=autovideosink_h264 sync=true

appsrc injects decrypted apple h264 nalus one by one.

glcolorconvert: add support for planar yuv-> planar yuv conversion (!6596) · Merge requests · GStreamer / gstreamer · GitLab is the glcolorconvert(glimagesink) change to support arbitrary color matrices which will be part of the 1.26 release series.

Yes! This colorspace problem is indeed now fixed (for glimagesink) by these improvements in 1.25.0.1

What needs to be done to extend the solution to xvimagesink also (still showing the issue in 1.25.0.1)?