public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, Mats Randgaard <matrandg@cisco.com>,
	Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [PATCH 2/2] [media] tc358743: extend colorimetry support
Date: Fri, 10 Feb 2017 14:06:33 +0100	[thread overview]
Message-ID: <1486731993.2309.23.camel@pengutronix.de> (raw)
In-Reply-To: <51849519-0ed8-e123-3b60-2392c8171cb1@xs4all.nl>

Hi Hans,

On Fri, 2017-02-10 at 10:42 +0100, Hans Verkuil wrote:
> Hi Philipp,
> 
> Here is my review. Please take note of the videodev2.h colorspace patch I
> posted today, it affects how this patch works since you use V4L2_MAP_QUANTIZATION_DEFAULT.

Thank you for the review.

> On 02/08/2017 11:53 AM, Philipp Zabel wrote:
> > @@ -1486,16 +1506,40 @@ static int tc358743_get_fmt(struct v4l2_subdev *sd,
> >  
> >  	switch (vi_rep & MASK_VOUT_COLOR_SEL) {
> >  	case MASK_VOUT_COLOR_RGB_FULL:
> > +		format->format.colorspace = V4L2_COLORSPACE_SRGB;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_SRGB;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_601;
> > +		format->format.quantization = V4L2_QUANTIZATION_FULL_RANGE;
> > +		break;
> >  	case MASK_VOUT_COLOR_RGB_LIMITED:
> >  		format->format.colorspace = V4L2_COLORSPACE_SRGB;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_SRGB;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_601;
> > +		format->format.quantization = V4L2_QUANTIZATION_LIM_RANGE;
> >  		break;
> >  	case MASK_VOUT_COLOR_601_YCBCR_LIMITED:
> > +		format->format.colorspace = V4L2_COLORSPACE_SMPTE170M;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_709;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_601;
> > +		format->format.quantization = V4L2_QUANTIZATION_LIM_RANGE;
> > +		break;
> >  	case MASK_VOUT_COLOR_601_YCBCR_FULL:
> >  		format->format.colorspace = V4L2_COLORSPACE_SMPTE170M;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_709;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_XV601;
> > +		format->format.quantization = V4L2_QUANTIZATION_FULL_RANGE;
> >  		break;
> >  	case MASK_VOUT_COLOR_709_YCBCR_FULL:
> > +		format->format.colorspace = V4L2_COLORSPACE_REC709;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_709;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_XV709;
> > +		format->format.quantization = V4L2_QUANTIZATION_FULL_RANGE;
> > +		break;
> >  	case MASK_VOUT_COLOR_709_YCBCR_LIMITED:
> >  		format->format.colorspace = V4L2_COLORSPACE_REC709;
> > +		format->format.xfer_func = V4L2_XFER_FUNC_709;
> > +		format->format.ycbcr_enc = V4L2_YCBCR_ENC_709;
> > +		format->format.quantization = V4L2_QUANTIZATION_LIM_RANGE;
> >  		break;
> 
> This is wrong (and it is wrong in the original code as well).
> 
> The colorspace depends on the colorspace information in the AVI InfoFrame, not
> on what is output. Typically if RGB is received, then that maps to COLORSPACE_SRGB
> and XFER_FUNC_SRGB. For YCbCr with SMPTE170M it maps to SMPTE170M and XFER_FUNC_709,
> and REC709 maps to COLORSPACE_REC709 and XFER_FUNC_709.

So colorspace and xfer_func should be set according to the AVI info
packet, no matter whether the output is RGB or YUV?
I think that information gets parsed into the S_V_COLOR field in the
VI_STATUS3 register, so I'll use that instead of VOUT_COLOR_SEL.

> The only thing the vout_color_sel modifies are the ycbcr_enc and the quantization
> range.

Ok.

> >  	default:
> >  		format->format.colorspace = 0;
> 
> The driver should never set colorspace to 0.

Ok, I'll fix this.

> > @@ -1512,7 +1556,11 @@ static int tc358743_set_fmt(struct v4l2_subdev *sd,
> >  	struct tc358743_state *state = to_state(sd);
> >  
> >  	u32 code = format->format.code; /* is overwritten by get_fmt */
> > +	enum v4l2_colorspace colorspace = format->format.colorspace;
> > +	enum v4l2_ycbcr_encoding ycbcr_enc = format->format.ycbcr_enc;
> > +	enum v4l2_quantization quantization = format->format.quantization;
> >  	int ret = tc358743_get_fmt(sd, cfg, format);
> > +	u8 vout_color_sel;
> >  
> >  	format->format.code = code;
> >  
> > @@ -1521,16 +1569,78 @@ static int tc358743_set_fmt(struct v4l2_subdev *sd,
> >  
> >  	switch (code) {
> >  	case MEDIA_BUS_FMT_RGB888_1X24:
> > +		colorspace = V4L2_COLORSPACE_SRGB;
> 
> You can't set the colorspace and/or xfer_func in an HDMI receiver driver. This
> exclusively depends on the AVI InfoFrame information and you can't change that.

Ok, I'll fix this.

> > +		break;
> >  	case MEDIA_BUS_FMT_UYVY8_1X16:
> > +		switch (colorspace) {
> > +		case V4L2_COLORSPACE_SMPTE170M:
> > +		case V4L2_COLORSPACE_REC709:
> > +			break;
> > +		default:
> > +			if (format->format.colorspace != V4L2_COLORSPACE_SRGB)
> > +				colorspace = format->format.colorspace;
> > +			else
> > +				colorspace = V4L2_COLORSPACE_SMPTE170M;
> > +			break;
> > +		}
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +
> > +	format->format.colorspace = colorspace;
> > +
> > +	if (ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
> > +		ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(colorspace);
> > +	if (quantization == V4L2_QUANTIZATION_DEFAULT)
> > +		quantization = V4L2_MAP_QUANTIZATION_DEFAULT(false, colorspace,
> > +							     ycbcr_enc);
> 
> That also means that you cannot determine this here, since you won't know the
> colorspace until you have the InfoFrame information.
>
> You should just check the ycbcr_enc and quantization fields: for MEDIA_BUS_FMT_RGB888_1X24
> you only have to look at the quantization field, for MEDIA_BUS_FMT_UYVY8_1X16
> both fields need checking.

I assume I should set colorspace and xfer_func according to the detected
input color space then, same as in get_fmt.

regards
Philipp


  reply	other threads:[~2017-02-10 13:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08 10:53 [PATCH 1/2] [media] tc358743: put lanes in STOP state before starting streaming Philipp Zabel
2017-02-08 10:53 ` [PATCH 2/2] [media] tc358743: extend colorimetry support Philipp Zabel
2017-02-08 13:00   ` Hans Verkuil
2017-02-10  9:42   ` Hans Verkuil
2017-02-10 13:06     ` Philipp Zabel [this message]
2017-02-10 13:36       ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1486731993.2309.23.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=matrandg@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox