Take COLOR_ENCODING values into account when choosing a colorspace

Replace the generic starfive hack with proper logic to examine the
supported enum values to select a colorspace. This fixes incorrect
colors with vs-drm on the TH1520.
This commit is contained in:
Cameron Gutman 2024-06-23 19:33:37 -05:00
parent 35695642d5
commit ac0e1098b9

View File

@ -1281,16 +1281,20 @@ bool DrmRenderer::isDirectRenderingSupported()
int DrmRenderer::getDecoderColorspace() int DrmRenderer::getDecoderColorspace()
{ {
// The starfive driver used on the VisionFive 2 doesn't support BT.601, if (m_ColorEncodingProp != nullptr) {
// so we will use BT.709 instead. Rockchip doesn't support BT.709, even // Search for a COLOR_ENCODING property that fits a value we support
// in some cases where it exposes COLOR_ENCODING properties, so we stick for (int i = 0; i < m_ColorEncodingProp->count_enums; i++) {
// to BT.601 which seems to be the default for YUV planes on Linux. if (!strcmp(m_ColorEncodingProp->enums[i].name, "ITU-R BT.601 YCbCr")) {
if (strcmp(m_Version->name, "starfive") == 0) { return COLORSPACE_REC_601;
return COLORSPACE_REC_709; }
} else if (!strcmp(m_ColorEncodingProp->enums[i].name, "ITU-R BT.709 YCbCr")) {
else { return COLORSPACE_REC_709;
return COLORSPACE_REC_601; }
}
} }
// Default to BT.601 if we couldn't find a valid COLOR_ENCODING property
return COLORSPACE_REC_601;
} }
const char* DrmRenderer::getDrmColorEncodingValue(AVFrame* frame) const char* DrmRenderer::getDrmColorEncodingValue(AVFrame* frame)