H264 only ever describes the range and conversion parameters used as metadata. The encode/decode process should never change the pixel values beyond that due to the compression quantisation.
In the H264 VUI headers, you have optional flags for video_full_range_flag, colour_primaries, transfer_characteristics, and matrix_coefficients.
With colorspace = V4L2_COLORSPACE_JPEG the encoder should be setting those to full range and the BT601 parameters (as per the V4L2 docs, V4L2_COLORSPACE_JPEG is effectively V4L2_COLORSPACE_SRGB, V4L2_XFER_FUNC_SRGB, V4L2_YCBCR_ENC_601 and V4L2_QUANTIZATION_FULL_RANGE).
Actually V4L2_COLORSPACE_JPEG is invalid for any pixel format other than V4L2_PIX_FMT_JPEG, and v4l2-compliance enforces that on the driver. The driver is entitled to change the format passed in to VIDIOC_S_FMT to make the request valid, so what did it return as the colorspace?
The encode is ALWAYS as YUV420, so your RGBA will have to be converted from RGB to YUV by the firmware.
Actually any RGB format must be defined as V4L2_COLORSPACE_SRGB, so the conversion should have been to limited range BT601, and I would hope the metadata followed that.
If you're comparing RGB values on the output, then your decoder (or subsequent post-processing) has also had to do a conversion from YUV to RGB, and that needs to have used the right conversion matrices to handle the range and conversion parameters. You don't say what you've used to do that.
In the H264 VUI headers, you have optional flags for video_full_range_flag, colour_primaries, transfer_characteristics, and matrix_coefficients.
With colorspace = V4L2_COLORSPACE_JPEG the encoder should be setting those to full range and the BT601 parameters (as per the V4L2 docs, V4L2_COLORSPACE_JPEG is effectively V4L2_COLORSPACE_SRGB, V4L2_XFER_FUNC_SRGB, V4L2_YCBCR_ENC_601 and V4L2_QUANTIZATION_FULL_RANGE).
Actually V4L2_COLORSPACE_JPEG is invalid for any pixel format other than V4L2_PIX_FMT_JPEG, and v4l2-compliance enforces that on the driver. The driver is entitled to change the format passed in to VIDIOC_S_FMT to make the request valid, so what did it return as the colorspace?
The encode is ALWAYS as YUV420, so your RGBA will have to be converted from RGB to YUV by the firmware.
Actually any RGB format must be defined as V4L2_COLORSPACE_SRGB, so the conversion should have been to limited range BT601, and I would hope the metadata followed that.
If you're comparing RGB values on the output, then your decoder (or subsequent post-processing) has also had to do a conversion from YUV to RGB, and that needs to have used the right conversion matrices to handle the range and conversion parameters. You don't say what you've used to do that.
Statistics: Posted by 6by9 — Tue Jan 16, 2024 3:01 pm