diff options
author | Hou Qi <qi.hou@nxp.com> | 2024-12-16 13:30:44 +0900 |
---|---|---|
committer | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2024-12-16 15:12:50 +0200 |
commit | e9a876acc6d3a3d8ce1cfc99e4cbcf1c6122d591 (patch) | |
tree | a00aba25414e142e0525ed0a596766111fb8e937 /test/ipa/libipa/vector.cpp | |
parent | a7aab7da8a716299661b5f451366fb6e2f3d88b2 (diff) |
The conversions back and forth between GStreamer colorimetry and
libcamera color space are not invariant for the bt601 colorimetry.
The reason is that Rec709 transfer function defined in GStreamer
as GST_VIDEO_TRANSFER_BT709 (5), is to be replaced by its alias
GST_VIDEO_TRANSFER_BT601 (16) only for the case of bt601 (aka 2:4:16:4)
colorimetry - see [1].
Currently the composition of the GStreamer/libcamera conversions:
colorimetry_from_colorspace (colorspace_from_colorimetry (bt601))
returns 2:4:5:4 instead of the expected 2:4:16:4 (bt601). This
causes negotiation error when the downstream element explicitly
expects bt601 colorimetry.
Minimal example to reproduce the issue is with a pipeline handler
that do not set the optional color space in the stream configuration,
for instance vimc or imx8-isi:
export LIBCAMERA_PIPELINES_MATCH_LIST="vimc,imx8-isi"
gst-launch-1.0 -v libcamerasrc ! video/x-raw,colorimetry=bt601 ! fakesink
Above pipeline fails to start. This change memorizes downstream required
transfer function when mapped libcamera transfer is Rec709 in
gst_libcamera_configure_stream_from_caps(), and restores the transfer
function in gst_libcamera_stream_formats_to_caps().
[1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/724
Bug: https://bugs.libcamera.org/show_bug.cgi?id=150
Signed-off-by: Hou Qi <qi.hou@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Diffstat (limited to 'test/ipa/libipa/vector.cpp')
0 files changed, 0 insertions, 0 deletions