Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

[Thibault Saunier]

Hello,


On 03/01/2017 11:35 AM, Nicolas Dufresne wrote:

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :

On 01.03.2017 12:51, Thibault Saunier wrote:

It is required by the standard that the field order is set by the
driver, default to NONE in case any is provided, but we can
basically
accept any value provided by the userspace as we will anyway not
be able to do any deinterlacing.

In this patch we also make sure to pass the interlacing mode
provided
by userspace from the output to the capture side of the device so
that the information is given back to userspace. This way it can
handle it and potentially deinterlace afterward.

As I wrote previously:
- on output side you have encoded bytestream - you cannot say about
interlacing in such case, so the only valid value is NONE,

Userspace may know. It's important for the driver not to reset it back
to NONE, it would tell the userspace that this encoded format is not
supported when interlaced.

Obviously, when userspace don't know (ANY), it does not matter, it will
fail when we try to set the CAPTURE format. Though, it's quite late in
the process for the userspace, which makes implementing software
fallback difficult.


- on capture side you have decoded frames, and in this case it
depends
on the device and driver capabilities, if the driver/device does not
support (de-)interlacing (I suppose this is MFC case), interlace type
field should be filled according to decoded bytestream header (on
output
side), but no direct copying from output side!!!

That is exact.

It is yes, in case the driver is determining it properly, which is not
the case here. So the information we have is what the userspace
figured. That part should be fixed in the driver, but meanwhile it is
better to copy to the output side than just loosing the info as otherwise
the userspace never tries to deinterlace after the decoding because the
driver always says field=NONE now.

Regards,

Thibault



Regards
Andrzej


Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v6:
- Pass user output field value to the capture as the device is not
   doing any deinterlacing and thus decoded content will still be
   interlaced on the output.

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained
in previous review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the
patches

  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ab23236aa942..3816a37de4bc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
size_t me_buffer_size;
size_t tmv_buffer_size;
  
+	enum v4l2_field field;

+
enum v4l2_mpeg_mfc51_video_force_frame_type
force_frame_type;
  
  	struct list_head ref_queue;

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..6e5ca86fb331 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void
*priv, struct v4l2_format *f)
   rectangle. */
pix_mp->width = ctx->buf_width;
pix_mp->height = ctx->buf_height;
-   pix_mp->field = V4L2_FIELD_NONE;
+   pix_mp->field = ctx->field;
pix_mp->num_planes = 2;
/* Set pixelformat to the format in which MFC
   outputs the decoded frame */
@@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file,
void *priv, struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct s5p_mfc_fmt *fmt;
  
+	if (f->fmt.pix.field == V4L2_FIELD_ANY)

+   f->fmt.pix.field = V4L2_FIELD_NONE;
+
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);
@@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void
*priv, struct v4l2_format *f)
goto out;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* src_fmt is validated by call to vidioc_try_fmt
*/
+   ctx->field = f->fmt.pix.field;
ctx->src_fmt = find_format(f, MFC_FMT_DEC);
ctx->codec_mode = ctx->src_fmt->codec_mode;
mfc_debug(2, "The codec number is: %d\n", ctx-

codec_mode);

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

[Thibault Saunier]

Hello,


On 03/01/2017 10:12 AM, Andrzej Hajda wrote:

On 01.03.2017 12:51, Thibault Saunier wrote:

It is required by the standard that the field order is set by the
driver, default to NONE in case any is provided, but we can basically
accept any value provided by the userspace as we will anyway not
be able to do any deinterlacing.

In this patch we also make sure to pass the interlacing mode provided
by userspace from the output to the capture side of the device so
that the information is given back to userspace. This way it can
handle it and potentially deinterlace afterward.

As I wrote previously:
- on output side you have encoded bytestream - you cannot say about
interlacing in such case, so the only valid value is NONE,

Well, the encoded stream contains the info about interlacing and
the most logical thing to do from my point of view is to keep that info
passe it along to the capture side, which is what I am doing.
What makes you think this is not the right way of handling that?

- on capture side you have decoded frames, and in this case it depends
on the device and driver capabilities, if the driver/device does not
support (de-)interlacing (I suppose this is MFC case), interlace type
field should be filled according to decoded bytestream header (on output
side), but no direct copying from output side!!!

Well, why? If the userspace has already parsed the headers and passed the
info to the decoder, there is no reason we should pass along that info 
to the

capture side.

Currently the bitstream parser in the decoder does not seem to take of
the interlacing properly so if userspace specified it because it already 
parsed the
stream or the info was in the container not in the codec bitstream, then 
using

it is very sensible I think!!!

Regards,

Thibault


Regards
Andrzej


Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v6:
- Pass user output field value to the capture as the device is not
   doing any deinterlacing and thus decoded content will still be
   interlaced on the output.

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ab23236aa942..3816a37de4bc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
size_t me_buffer_size;
size_t tmv_buffer_size;
  
+	enum v4l2_field field;

+
enum v4l2_mpeg_mfc51_video_force_frame_type force_frame_type;
  
  	struct list_head ref_queue;

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..6e5ca86fb331 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   rectangle. */
pix_mp->width = ctx->buf_width;
pix_mp->height = ctx->buf_height;
-   pix_mp->field = V4L2_FIELD_NONE;
+   pix_mp->field = ctx->field;
pix_mp->num_planes = 2;
/* Set pixelformat to the format in which MFC
   outputs the decoded frame */
@@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct s5p_mfc_fmt *fmt;
  
+	if (f->fmt.pix.field == V4L2_FIELD_ANY)

+   f->fmt.pix.field = V4L2_FIELD_NONE;
+
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);
@@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
goto out;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* src_fmt is validated by call to vidioc_try_fmt */
+   ctx->field = f->fmt.pix.field;
ctx->src_fmt = find_format(f, MFC_FMT_DEC);
ctx->codec_mode = ctx->src_fmt->codec_mode;
mfc_debug(2, "The codec number is: %d\n", ctx->codec_mode);

[PATCH v6 1/2] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

Use colorspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

If the user does not provide a colorspace do no make it up, we might
later while processing need to figure out the colorspace, which
is possible depending on the frame size but do not ever guess and
leak that guess to the userspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v6:
- Do not ever guess colorspace

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 9 -
 drivers/media/platform/exynos-gsc/gsc-core.h | 1 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..0241168c85af 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+   pix_mp->colorspace = ctx->out_colorspace;
}
 
pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,8 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (V4L2_TYPE_IS_OUTPUT(f->type))
+   ctx->out_colorspace = pix_mp->colorspace;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
@@ -519,8 +518,8 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
pix_mp->num_planes  = frame->fmt->num_planes;
+   pix_mp->colorspace = ctx->out_colorspace;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 696217e9af66..715d9c9d8d30 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -376,6 +376,7 @@ struct gsc_ctx {
struct v4l2_ctrl_handler ctrl_handler;
struct gsc_ctrlsgsc_ctrls;
boolctrls_rdy;
+   enum v4l2_colorspace out_colorspace;
 };
 
 void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);
-- 
2.11.1

[PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver, default to NONE in case any is provided, but we can basically
accept any value provided by the userspace as we will anyway not
be able to do any deinterlacing.

In this patch we also make sure to pass the interlacing mode provided
by userspace from the output to the capture side of the device so
that the information is given back to userspace. This way it can
handle it and potentially deinterlace afterward.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v6:
- Pass user output field value to the capture as the device is not
  doing any deinterlacing and thus decoded content will still be
  interlaced on the output.

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ab23236aa942..3816a37de4bc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
size_t me_buffer_size;
size_t tmv_buffer_size;
 
+   enum v4l2_field field;
+
enum v4l2_mpeg_mfc51_video_force_frame_type force_frame_type;
 
struct list_head ref_queue;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..6e5ca86fb331 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   rectangle. */
pix_mp->width = ctx->buf_width;
pix_mp->height = ctx->buf_height;
-   pix_mp->field = V4L2_FIELD_NONE;
+   pix_mp->field = ctx->field;
pix_mp->num_planes = 2;
/* Set pixelformat to the format in which MFC
   outputs the decoded frame */
@@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct s5p_mfc_fmt *fmt;
 
+   if (f->fmt.pix.field == V4L2_FIELD_ANY)
+   f->fmt.pix.field = V4L2_FIELD_NONE;
+
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);
@@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
goto out;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* src_fmt is validated by call to vidioc_try_fmt */
+   ctx->field = f->fmt.pix.field;
ctx->src_fmt = find_format(f, MFC_FMT_DEC);
ctx->codec_mode = ctx->src_fmt->codec_mode;
mfc_debug(2, "The codec number is: %d\n", ctx->codec_mode);
-- 
2.11.1

[PATCH v6 0/2] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, and
replicate users value on the capture side.

This is the sixth version of the patch serie.

Best regards,

Thibault Saunier

Changes in v6:
- Do not ever guess colorspace
- Pass user output field value to the capture as the device is not
  doing any deinterlacing and thus decoded content will still be
  interlaced on the output.

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message
- Just adapt the field and never error out.

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Thibault Saunier (2):
  [media] exynos-gsc: Use user configured colorspace if provided
  [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c| 9 -
 drivers/media/platform/exynos-gsc/gsc-core.h| 1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6 +-
 4 files changed, 12 insertions(+), 6 deletions(-)

-- 
2.11.1

Re: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

On 02/22/2017 05:03 PM, Nicolas Dufresne wrote:

Le mercredi 22 février 2017 à 15:57 -0300, Thibault Saunier a écrit :

On 02/22/2017 03:06 PM, Hans Verkuil wrote:

On 02/22/2017 05:05 AM, Thibault Saunier wrote:

Hello,


On 02/21/2017 11:19 PM, Hans Verkuil wrote:

On 02/21/2017 11:20 AM, Thibault Saunier wrote:

Use colorspace provided by the user as we are only doing
scaling and
color encoding conversion, we won't be able to transform the
colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Start using 576p as a threashold to compute the colorspace.
The media documentation says that the
V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV.
But drivers
don't agree on the display resolution that should be used as
a threshold.

   From EIA CEA 861B about colorimetry for various
resolutions:

 - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
   The color space used by the 480-line, 576-line, 240-
line, and 288-line
   formats will likely be based on SMPTE 170M [1].
 - 5.2 1080i, 1080p, and 720p
   The color space used by the high definition formats
will likely be
   based on ITU-R BT.709-4

This indicates that in the case that userspace does not
specify what
colorspace should be used, we should use 576p  as a threshold
to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M.
Even if it is
only 'likely' and not a requirement it is the best guess we
can make.

The stream should have been encoded with the information and
userspace
has to pass it to the driver if it is not the case, otherwise
we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead
unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.c
om>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung
.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v5:
- Squash commit to always use output colorspace on the
capture side
 inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on
specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej
explained in previous review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

drivers/media/platform/exynos-gsc/gsc-core.c | 20
+++-
drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx
*ctx, struct v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+pix_mp->colorspace = ctx->out_colorspace;
}
  pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h =
%d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx
*ctx, struct v4l2_format *f)
  pix_mp->num_planes = fmt->num_planes;
-if (pix_mp->width >= 1280) /* HD */
-pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-else /* SD */
-pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+if (pix_mp->width > 720 && pix_mp->height > 576) /*
HD */

I'd use || instead of && here. Ditto for the next patch.


+pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+else /* SD */
+pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+}

Are you sure this is in fact how it is used? If the source of
the video
is the sensor (camera), then the colorspace is typically SRGB.
I'm not
really sure you should guess here. All a mem2mem driver should
do is to
pass the colorspace etc. information from the output to the
capture side,
and not invent things. That simply makes no sense.

This is not a camera device but a colorspace conversion device,
in many

Not really, this is a color encoding conversion device. I.e. it
only affects
the Y'CbCr encoding and quantization range. The colorspace (aka
chromaticities)
and transfer function remain unchanged.

Well, right, sorry I am talking in GStreamer terminlogy where what
you call
colorspace is called colorimetry, and colorspace is what I am
talking
about here.


In fact, I suspect (correct me if I am wrong) that it only converts
between
RGB, Y'CbCr 601 and Y'CbCr 709 encodings, where RGB is full range
and the Y'CbCr
formats are limited range.

That sounds correct.


If you pass in limited range RGB it will probably do the wrong
thing as

Re: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

On 02/22/2017 03:06 PM, Hans Verkuil wrote:


On 02/22/2017 05:05 AM, Thibault Saunier wrote:

Hello,


On 02/21/2017 11:19 PM, Hans Verkuil wrote:

On 02/21/2017 11:20 AM, Thibault Saunier wrote:

Use colorspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Start using 576p as a threashold to compute the colorspace.
The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

  From EIA CEA 861B about colorimetry for various resolutions:

- 5.1 480p, 480i, 576p, 576i, 240p, and 288p
  The color space used by the 480-line, 576-line, 240-line, and 288-line
  formats will likely be based on SMPTE 170M [1].
- 5.2 1080i, 1080p, and 720p
  The color space used by the high definition formats will likely be
  based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v5:
- Squash commit to always use output colorspace on the capture side
inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

   drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
   drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
   2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
   } else {
   min_w = variant->pix_min->target_rot_dis_w;
   min_h = variant->pix_min->target_rot_dis_h;
+pix_mp->colorspace = ctx->out_colorspace;
   }
 pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 pix_mp->num_planes = fmt->num_planes;
   -if (pix_mp->width >= 1280) /* HD */
-pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-else /* SD */
-pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

I'd use || instead of && here. Ditto for the next patch.


+pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+else /* SD */
+pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+}

Are you sure this is in fact how it is used? If the source of the video
is the sensor (camera), then the colorspace is typically SRGB. I'm not
really sure you should guess here. All a mem2mem driver should do is to
pass the colorspace etc. information from the output to the capture side,
and not invent things. That simply makes no sense.

This is not a camera device but a colorspace conversion device, in many

Not really, this is a color encoding conversion device. I.e. it only affects
the Y'CbCr encoding and quantization range. The colorspace (aka chromaticities)
and transfer function remain unchanged.


Well, right, sorry I am talking in GStreamer terminlogy where what you call
colorspace is called colorimetry, and colorspace is what I am talking 
about here.



In fact, I suspect (correct me if I am wrong) that it only converts between
RGB, Y'CbCr 601 and Y'CbCr 709 encodings, where RGB is full range and the Y'CbCr
formats are limited range.

That sounds correct.


If you pass in limited range RGB it will probably do the wrong thing as I don't
seen any quantization checks in the code.

So the colorspace and xfer_func fields remain unchanged by this dr

Re: [PATCH v5 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

Hello,

On 02/22/2017 06:29 AM, Andrzej Hajda wrote:

On 21.02.2017 20:20, Thibault Saunier wrote:

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0976c3e0a5ce..44ed2afe0780 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -386,6 +386,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
  
+	if (f->fmt.pix.field == V4L2_FIELD_ANY)

+   f->fmt.pix.field = V4L2_FIELD_NONE;
+

In previous version the only supported field type was NONE, here you
support everything.
If the only supported format is none you should set 'field'
unconditionally to NONE, nothing more.

Afaict we  support 2 things:

  1. NONE
  2. INTERLACE

Until now we were not checking what was supported or not and basically 
ignoring that info, this patch

keeps the old behaviour making sure to be compliant.

I had a doubt and was pondering doing:

``` diff

+   if (f->fmt.pix.field != V4L2_FIELD_INTERLACED)
+   f->fmt.pix.field = V4L2_FIELD_NONE;
+

```

instead, it is probably more correct, do you think it is what should be 
done here?


Regards,

Thibault



Regards
Andrzej


mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);

Re: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

Hello,


On 02/21/2017 11:19 PM, Hans Verkuil wrote:


On 02/21/2017 11:20 AM, Thibault Saunier wrote:

Use colorspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Start using 576p as a threashold to compute the colorspace.
The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

 From EIA CEA 861B about colorimetry for various resolutions:

   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
 The color space used by the 480-line, 576-line, 240-line, and 288-line
 formats will likely be based on SMPTE 170M [1].
   - 5.2 1080i, 1080p, and 720p
 The color space used by the high definition formats will likely be
 based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v5:
- Squash commit to always use output colorspace on the capture side
   inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

  drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
  drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
  2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+   pix_mp->colorspace = ctx->out_colorspace;
}
  
  	pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",

@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
  
  	pix_mp->num_planes = fmt->num_planes;
  
-	if (pix_mp->width >= 1280) /* HD */

-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

I'd use || instead of && here. Ditto for the next patch.


+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }

Are you sure this is in fact how it is used? If the source of the video
is the sensor (camera), then the colorspace is typically SRGB. I'm not
really sure you should guess here. All a mem2mem driver should do is to
pass the colorspace etc. information from the output to the capture side,
and not invent things. That simply makes no sense.


This is not a camera device but a colorspace conversion device, in many
cases the info will not be passed by the userspace, basically because 
the info
is not encoded in the media stream (this often happens). I am not 
inventing here,
just making sure we use the most likely value in case none was provided 
(and if none
was provided it should always be correct given that the encoded stream 
was not broken).


In the case the source is a camera and then we use the colorspace 
converter then the info
should copied from the camera to the transcoding node (by userspace) so 
there should be

no problem.

What I am doing here is what is done in other drivers.

Regards,

Thibault


We may have to update the documentation or v4l2-compliance test if this
is an issue. The more I think about this, the more I think we shouldn't
do this guessing game.

Regards,

[PATCH v5 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0976c3e0a5ce..44ed2afe0780 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -386,6 +386,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
+   if (f->fmt.pix.field == V4L2_FIELD_ANY)
+   f->fmt.pix.field = V4L2_FIELD_NONE;
+
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);
-- 
2.11.1

[PATCH v5 2/3] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT provided

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry when userspace provided
V4L2_COLORSPACE_DEFAULT.

Use 576p display resolution as a threshold to set this as suggested by
EIA CEA 861B.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v5: None
Changes in v4:
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..0976c3e0a5ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +411,14 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 &&
+   pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

[PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

Use colorspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Start using 576p as a threashold to compute the colorspace.
The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

  - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
The color space used by the 480-line, 576-line, 240-line, and 288-line
formats will likely be based on SMPTE 170M [1].
  - 5.2 1080i, 1080p, and 720p
The color space used by the high definition formats will likely be
based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+   pix_mp->colorspace = ctx->out_colorspace;
}
 
pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
+
+   if (V4L2_TYPE_IS_OUTPUT(f->type))
+   ctx->out_colorspace = pix_mp->colorspace;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
@@ -519,9 +525,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 696217e9af66..715d9c9d8d30 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -376,6 +376,7 @@ struct gsc_ctx {
struct v4l2_ctrl_handle

[PATCH v5 0/3] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding 
GStreamer
spamming error at us about the driver not following the standard.

This is the fifth version of the patch serie.

Best regards,

Thibault Saunier

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message
- Just adapt the field and never error out.

Changes in v4:
- Reword commit message to better back our assumptions on specifications
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Thibault Saunier (3):
  [media] exynos-gsc: Use user configured colorspace if provided
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT
provided
  [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in
try_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 +
 3 files changed, 33 insertions(+), 5 deletions(-)

-- 
2.11.1

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

Hello Andrzej,

On 02/21/2017 06:56 AM, Andrzej Hajda wrote:

On 13.02.2017 20:08, Thibault Saunier wrote:

From: Javier Martinez Canillas <jav...@osg.samsung.com>

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
 The color space used by the 480-line, 576-line, 240-line, and 288-line
 formats will likely be based on SMPTE 170M [1].
   - 5.2 1080i, 1080p, and 720p
 The color space used by the high definition formats will likely be
 based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Hi Thibault,

Have you analyzed Hans response for the previous patchset [1] ?
I am not an expert in the subject but it seems he is right. GSCALER
datasheet uses term 'color space conversion' to describe conversions
between RGB and YCbCr, not for describe colorspaces as in V4L2.
GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
OUT_CON registers of GSCALER are probably used incorrectly, they should
not be set according to pix_mp->colorspace but rather according to
pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
just copied from output to capture side.

Please fix the patch accordingly, and if you are interested you can
prepare another patch to fix register setting.


OK, so what you describe here for the colorspace  is exactly what I am 
doing in my next patch right?

I am going to fixup them up as suggested in your other review.

I will also have a look at fixing register setting and figure out what 
you explained.


Thanks for the review.

Regards,

Thibault Saunier


[1]: https://lkml.org/lkml/2017/2/10/473

Regards
Andrzej


---

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
  
  	pix_mp->num_planes = fmt->num_planes;
  
-	if (pix_mp->width >= 1280) /* HD */

+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height   = frame->f_height;
pix_mp->field= V4L2_FIELD_NONE;
pix_mp->pixelformat  = frame->fmt->pixelformat;
-   pix_mp->colorspace   = V4L2_COLORSPACE_REC709;
pix_mp->num_planes   = frame->fmt->num_planes;
  
+	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;

[PATCH v4 0/4] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding 
GStreamer
spamming error at us about the driver not following the standard.

This is the third version of the patch serie.

Best regards,

Thibault Saunier

Changes in v4:
- Reword commit message to better back our assumptions on specifications
- Use any colorspace provided by the user as it won't affect the way we
  handle our operations (guessing it if none is provided)
- Always use output colorspace on the capture side
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Javier Martinez Canillas (1):
  [media] exynos-gsc: Use 576p instead 720p as a threshold for
colorspaces

Thibault Saunier (3):
  [media] exynos-gsc: Respect userspace colorspace setting in try_fmt
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT
provided
  [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in
try_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 28 
 3 files changed, 44 insertions(+), 5 deletions(-)

-- 
2.11.1

[PATCH v4 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT provided

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry when userspace provided
V4L2_COLORSPACE_DEFAULT.

Use 576p display resolution as a threshold to set this as suggested by
EIA CEA 861B.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v4:
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..0976c3e0a5ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +411,14 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 &&
+   pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

[PATCH v4 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Thibault Saunier]

User userspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v4:
- Use any colorspace provided by the user as it won't affect the way we
  handle our operations (guessing it if none is provided)
- Always use output colorspace on the capture side

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 14 ++
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index db7d9883861b..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+   pix_mp->colorspace = ctx->out_colorspace;
}
 
pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
+
+   if (V4L2_TYPE_IS_OUTPUT(f->type))
+   ctx->out_colorspace = pix_mp->colorspace;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 696217e9af66..715d9c9d8d30 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -376,6 +376,7 @@ struct gsc_ctx {
struct v4l2_ctrl_handler ctrl_handler;
struct gsc_ctrlsgsc_ctrls;
boolctrls_rdy;
+   enum v4l2_colorspace out_colorspace;
 };
 
 void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);
-- 
2.11.1

[PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

From: Javier Martinez Canillas <jav...@osg.samsung.com>

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

  - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
The color space used by the 480-line, 576-line, 240-line, and 288-line
formats will likely be based on SMPTE 170M [1].
  - 5.2 1080i, 1080p, and 720p
The color space used by the high definition formats will likely be
based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

---

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
-- 
2.11.1

[PATCH v4 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0976c3e0a5ce..c954b34cb988 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
+   enum v4l2_field field;
+
+   field = f->fmt.pix.field;
+   if (field == V4L2_FIELD_ANY) {
+   field = V4L2_FIELD_NONE;
+   } else if (field != V4L2_FIELD_NONE) {
+   mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
+   /* V4L2 specification suggests the driver corrects the format struct
+* if any of the dimensions is unsupported
+*/
+   f->fmt.pix.field = field;
 
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-- 
2.11.1

Re: [PATCH v3 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

On 02/10/2017 12:07 PM, Hans Verkuil wrote:

On 02/10/2017 03:10 PM, Thibault Saunier wrote:

From: Javier Martinez Canillas <jav...@osg.samsung.com>

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

Some drivers set V4L2_COLORSPACE_REC709 for 720p and higher while others
set V4L2_COLORSPACE_REC709 for anything higher than 576p. Newers drivers
use the latter and that also matches what user-space multimedia programs
do (i.e: GStreamer), so change the driver logic to be aligned with this.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
  
  	pix_mp->num_planes = fmt->num_planes;
  
-	if (pix_mp->width >= 1280) /* HD */

+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height   = frame->f_height;
pix_mp->field= V4L2_FIELD_NONE;
pix_mp->pixelformat  = frame->fmt->pixelformat;
-   pix_mp->colorspace   = V4L2_COLORSPACE_REC709;
pix_mp->num_planes   = frame->fmt->num_planes;
  
+	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;


This is a mem2mem device, right? In the case of mem2mem devices the driver 
should never
set the colorspace, instead it just copies it from what the application 
provides (the
video output side) to the capture side.

After all, you are just scaling here so the input and output colorspaces are
exactly the same, and the scaler doesn't care what the colorspace is.


This device also does color conversion so I think it matters here, am I 
misunderstanding something?
Also, is that comment only for the try_fmt part as it looks like in 
g_fmt the driver should fill up the structure

with its values?

Thanks for you review.

Regards,

Thibault Saunier

Regards,

Hans


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Thibault Saunier]

If the colorspace is specified by userspace we should respect
it and not reset it ourself if we can support it.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index db7d9883861b..021598817938 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,10 +472,13 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

From: Javier Martinez Canillas <jav...@osg.samsung.com>

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

Some drivers set V4L2_COLORSPACE_REC709 for 720p and higher while others
set V4L2_COLORSPACE_REC709 for anything higher than 576p. Newers drivers
use the latter and that also matches what user-space multimedia programs
do (i.e: GStreamer), so change the driver logic to be aligned with this.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding 
GStreamer
spamming error at us about the driver not following the standard.

This is the third version of the patch serie.

Best regards,

Thibault Saunier

Changes in v3:
- Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Javier Martinez Canillas (1):
  [media] exynos-gsc: Use 576p instead 720p as a threshold for
colorspaces

Thibault Saunier (3):
  [media] exynos-gsc: Respect userspace colorspace setting in try_fmt
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT
  [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in
try_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c | 17 +++-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 29 
 2 files changed, 41 insertions(+), 5 deletions(-)

-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry, also respect usespace setting.

Use 576p display resolution as a threshold to set this.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..16bc3eaad0ff 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +411,15 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M) {
+   if (pix_mp->width > 720 &&
+   pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>

---

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 16bc3eaad0ff..e249c5cee262 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
+   enum v4l2_field field;
+
+   field = f->fmt.pix.field;
+   if (field == V4L2_FIELD_ANY) {
+   field = V4L2_FIELD_NONE;
+   } else if (field != V4L2_FIELD_NONE) {
+   mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
+   /* V4L2 specification suggests the driver corrects the format struct
+* if any of the dimensions is unsupported
+*/
+   f->fmt.pix.field = field;
 
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] [media] exynos-gsc: Respect userspace colorspace setting

[Thibault Saunier]

If the colorspace is specified by userspace we should respect
it and not reset it ourself if we can support it.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 2beb43401987..63bb4577827d 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -445,10 +445,14 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+ pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+ pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ }
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
@@ -492,12 +496,17 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+ pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+ pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ }
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

From: Javier Martinez Canillas 

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

Some drivers set V4L2_COLORSPACE_REC709 for 720p and higher while others
set V4L2_COLORSPACE_REC709 for anything higher than 576p. Newers drivers
use the latter and that also matches what user-space multimedia programs
do (i.e: GStreamer), so change the driver logic to be aligned with this.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index cbb03768f5d7..2beb43401987 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -445,7 +445,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -492,7 +492,10 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
pix_mp->num_planes  = frame->fmt->num_planes;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 960d6c7052bd..dfb21b4aee10 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -345,7 +345,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   rectangle. */
pix_mp->width = ctx->buf_width;
pix_mp->height = ctx->buf_height;
-   pix_mp->field = V4L2_FIELD_NONE;
pix_mp->num_planes = 2;
/* Set pixelformat to the format in which MFC
   outputs the decoded frame */
@@ -369,7 +368,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   so width and height have no meaning */
pix_mp->width = 0;
pix_mp->height = 0;
-   pix_mp->field = V4L2_FIELD_NONE;
pix_mp->plane_fmt[0].bytesperline = ctx->dec_src_buf_size;
pix_mp->plane_fmt[0].sizeimage = ctx->dec_src_buf_size;
pix_mp->pixelformat = ctx->src_fmt->fourcc;
@@ -379,6 +377,14 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_debug(2, "%s-- with error\n", __func__);
return -EINVAL;
}
+
+   if (pix_mp->field == V4L2_FIELD_ANY) {
+   pix_mp->field = V4L2_FIELD_NONE;
+   } else if (pix_mp->field != V4L2_FIELD_NONE) {
+   mfc_err("Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
mfc_debug_leave();
return 0;
 }
@@ -389,6 +395,19 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
+   enum v4l2_field field;
+
+   field = f->fmt.pix.field;
+   if (field == V4L2_FIELD_ANY) {
+   field = V4L2_FIELD_NONE;
+   } else if (V4L2_FIELD_NONE != field) {
+   mfc_debug("Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
+   /* V4L2 specification suggests the driver corrects the format struct
+* if any of the dimensions is unsupported */
+   f->fmt.pix.field = field;
 
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry, also respect usespace setting.

Use 576p display resolution as a threshold to set this.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..960d6c7052bd 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+ if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+ else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +387,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +415,15 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+ if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+ else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] [media] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding 
GStreamer
spamming error at us about the driver not following the standard.

Best regards,

Thibault Saunier


Javier Martinez Canillas (1):
  [media] exynos-gsc: Use 576p instead 720p as a threshold for
colorspaces

Thibault Saunier (3):
  [media] exynos-gsc: Respect userspace colorspace setting
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT
  [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

 drivers/media/platform/exynos-gsc/gsc-core.c | 22 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 42 ++--
 2 files changed, 57 insertions(+), 7 deletions(-)

-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/4] [media] exynos-gsc: Respect userspace colorspace setting

[Thibault Saunier]

If the colorspace is specified by userspace we should respect
it and not reset it ourself if we can support it.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 2beb43401987..63bb4577827d 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -445,10 +445,14 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+ pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+ pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ }
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
@@ -492,12 +496,17 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+ pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+ pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ }
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] [media] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Changes since v1:
  - Fix a silly build error that slipped in while rebasing the patches

Javier Martinez Canillas (1):
  [media] exynos-gsc: Use 576p instead 720p as a threshold for
colorspaces

Thibault Saunier (3):
  [media] exynos-gsc: Respect userspace colorspace setting
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT
  [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

 drivers/media/platform/exynos-gsc/gsc-core.c | 22 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 42 ++--
 2 files changed, 57 insertions(+), 7 deletions(-)

-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry, also respect usespace setting.

Use 576p display resolution as a threshold to set this.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..960d6c7052bd 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+ if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+ else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +387,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +415,15 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
+   pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
+   pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
+ if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+ else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 960d6c7052bd..309b0a1bbca5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -345,7 +345,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   rectangle. */
pix_mp->width = ctx->buf_width;
pix_mp->height = ctx->buf_height;
-   pix_mp->field = V4L2_FIELD_NONE;
pix_mp->num_planes = 2;
/* Set pixelformat to the format in which MFC
   outputs the decoded frame */
@@ -369,7 +368,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
   so width and height have no meaning */
pix_mp->width = 0;
pix_mp->height = 0;
-   pix_mp->field = V4L2_FIELD_NONE;
pix_mp->plane_fmt[0].bytesperline = ctx->dec_src_buf_size;
pix_mp->plane_fmt[0].sizeimage = ctx->dec_src_buf_size;
pix_mp->pixelformat = ctx->src_fmt->fourcc;
@@ -379,6 +377,14 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_debug(2, "%s-- with error\n", __func__);
return -EINVAL;
}
+
+   if (pix_mp->field == V4L2_FIELD_ANY) {
+   pix_mp->field = V4L2_FIELD_NONE;
+   } else if (pix_mp->field != V4L2_FIELD_NONE) {
+   mfc_err("Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
mfc_debug_leave();
return 0;
 }
@@ -389,6 +395,19 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
+   enum v4l2_field field;
+
+   field = f->fmt.pix.field;
+   if (field == V4L2_FIELD_ANY) {
+   field = V4L2_FIELD_NONE;
+   } else if (V4L2_FIELD_NONE != field) {
+   mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
+   return -EINVAL;
+   }
+
+   /* V4L2 specification suggests the driver corrects the format struct
+* if any of the dimensions is unsupported */
+   f->fmt.pix.field = field;
 
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

From: Javier Martinez Canillas 

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

Some drivers set V4L2_COLORSPACE_REC709 for 720p and higher while others
set V4L2_COLORSPACE_REC709 for anything higher than 576p. Newers drivers
use the latter and that also matches what user-space multimedia programs
do (i.e: GStreamer), so change the driver logic to be aligned with this.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index cbb03768f5d7..2beb43401987 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -445,7 +445,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -492,7 +492,10 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
pix_mp->num_planes  = frame->fmt->num_planes;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
-- 
2.11.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html