Hi Michael,
Your previous mail slipped through the cracks, sorry about that.
On Wed, Mar 02, 2022 at 12:00:12PM +0100, Michael Rodin wrote:
> Hi Laurent,
>
> thank you for your work!
>
> On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> > From: Michael Rodin <mrodin@xxxxxxxxxxxxxx>
> >
> > The vertical subsampling factor is currently not considered in the
> > offset calculation for plane cropping done in rpf_configure_partition.
> > This causes a distortion (shift of the color plane) when formats with
> > the vsub factor larger than 1 are used (e.g. NV12, see
> > vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> > for all planes except plane 0 (luminance).
> >
> > Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> > Signed-off-by: Michael Rodin <mrodin@xxxxxxxxxxxxxx>
> > Signed-off-by: LUU HOAI <hoai.luu.ub@xxxxxxxxxxx>
> >
> > Drop generalization of the offset calculation to reduce the binary size.
>
> Dropping generalization which I have done in my initial patch [1] is ok as
> long as this will not cause any troubles. I am not aware of any case where
> bytesperline and bpp could be different between the chroma planes, so
> probably it's fine.
>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx>
> > ---
> > drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> > index 85587c1b6a37..75083cb234fe 100644
> > --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> > @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> > + crop.left * fmtinfo->bpp[0] / 8;
> >
> > if (format->num_planes > 1) {
> > + unsigned int bpl = format->plane_fmt[1].bytesperline;
> > unsigned int offset;
> >
> > - offset = crop.top * format->plane_fmt[1].bytesperline
> > - + crop.left / fmtinfo->hsub
> > - * fmtinfo->bpp[1] / 8;
> > + offset = crop.top / fmtinfo->vsub * bpl
> > + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
>
> Probably it makes sense to do the division after all multiplications are
> done in order to avoid rounding errors? Consider the case when left = 3,
> hsub = 2, bpp = 32. Then we would get for the second part of the offset:
> 3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
> and if we do division as the last operation:
> (3 * 32) / (8 * 2) = 96 / 16 = 6
This was actually done on purpose :-) If the horizontal subsampling
factor is equal to 2, for instance for the NV12 chroma plane, the
horizontal offset must effectively be a multiple of 2. Otherwise you'll
swap the Cr and Cb components.
Taking your above example with a NV12 format (left=3, hsub=2, but
bpp=16), with the rounding in this patch,
offset = crop.top / fmtinfo->vsub * bpl
+ crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
= [vertical offset]
+ 3 / 2 * 16 / 8;
= [vertical offset]
+ 2;
Byte: 0 1 2 3 4 5
Cr Cb Cr Cb Cr Cb ...
^
offset
With your rounding proposal,
offset = crop.top / fmtinfo->vsub * bpl
+ (crop.left * fmtinfo->bpp[1]) / (fmtinfo->hsub * 8);
= [vertical offset]
+ (3 * 16) / (2 * 8);
= [vertical offset]
+ 3;
Byte: 0 1 2 3 4 5
Cr Cb Cr Cb Cr Cb ...
^
offset
> The first part of the offset can probably also cause the same rounding
> issue.
>
> > mem.addr[1] += offset;
> > mem.addr[2] += offset;
> > }
> >
>
> [1] https://lore.kernel.org/all/1637679566-76975-1-git-send-email-mrodin@xxxxxxxxxxxxxx/T/
--
Regards,
Laurent Pinchart
