From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
Sebastian Fricke <sebastian.fricke@collabora.com>,
linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 15/23] media: rkvdec: h264: Validate and use pic width and height in mbs
Date: Tue, 05 Apr 2022 11:44:54 -0400 [thread overview]
Message-ID: <67742466181fef8ca42d8f5ad2815a46367f5fa7.camel@collabora.com> (raw)
In-Reply-To: <Ykg0Qw24PuGCnbLT@eze-laptop>
Le samedi 02 avril 2022 à 08:32 -0300, Ezequiel Garcia a écrit :
> Hi Nicolas,
>
> On Thu, Mar 31, 2022 at 03:37:17PM -0400, Nicolas Dufresne wrote:
> > From: Jonas Karlman <jonas@kwiboo.se>
> >
> > The width and height in macroblocks is currently configured based on OUTPUT
> > buffer resolution, this works for frame pictures but can cause issues for
> > field pictures.
> >
> > When frame_mbs_only_flag is 0 the height in mbs should be height of
> > the field instead of height of frame.
> >
> > Validate pic_width_in_mbs_minus1 and pic_height_in_map_units_minus1
> > against OUTPUT buffer resolution and use these values to configure HW.
> >
> > Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > Reviewed-by: Sebastian Fricke <sebastian.fricke@collabora.com>
> > ---
> > drivers/staging/media/rkvdec/rkvdec-h264.c | 4 ++--
> > drivers/staging/media/rkvdec/rkvdec.c | 10 ++++++++++
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > index 8d44a884a52e..a42cf19bcc6d 100644
> > --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> > +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > @@ -672,8 +672,8 @@ static void assemble_hw_pps(struct rkvdec_ctx *ctx,
> > LOG2_MAX_PIC_ORDER_CNT_LSB_MINUS4);
> > WRITE_PPS(!!(sps->flags & V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO),
> > DELTA_PIC_ORDER_ALWAYS_ZERO_FLAG);
> > - WRITE_PPS(DIV_ROUND_UP(ctx->coded_fmt.fmt.pix_mp.width, 16), PIC_WIDTH_IN_MBS);
> > - WRITE_PPS(DIV_ROUND_UP(ctx->coded_fmt.fmt.pix_mp.height, 16), PIC_HEIGHT_IN_MBS);
>
> Please add a comment so we don't forget why we use the bitstream
> fields here.
And perhaps I should clarify that only the height will vary. It remains nice if
we can decode smaller images into larger image/format, that will be needed to
handle the sub-layers in SVC (these are not to be displayed, so we don't care
much about the output stride and all). So that is also an improvement.
>
> > + WRITE_PPS(sps->pic_width_in_mbs_minus1 + 1, PIC_WIDTH_IN_MBS);
> > + WRITE_PPS(sps->pic_height_in_map_units_minus1 + 1, PIC_HEIGHT_IN_MBS);
> > WRITE_PPS(!!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY),
> > FRAME_MBS_ONLY_FLAG);
> > WRITE_PPS(!!(sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD),
> > diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c
> > index 2df8cf4883e2..1b805710e195 100644
> > --- a/drivers/staging/media/rkvdec/rkvdec.c
> > +++ b/drivers/staging/media/rkvdec/rkvdec.c
> > @@ -29,8 +29,11 @@
> >
> > static int rkvdec_try_ctrl(struct v4l2_ctrl *ctrl)
> > {
> > + struct rkvdec_ctx *ctx = container_of(ctrl->handler, struct rkvdec_ctx, ctrl_hdl);
> > +
> > if (ctrl->id == V4L2_CID_STATELESS_H264_SPS) {
> > const struct v4l2_ctrl_h264_sps *sps = ctrl->p_new.p_h264_sps;
> > + unsigned int width, height;
> > /*
> > * TODO: The hardware supports 10-bit and 4:2:2 profiles,
> > * but it's currently broken in the driver.
> > @@ -45,6 +48,13 @@ static int rkvdec_try_ctrl(struct v4l2_ctrl *ctrl)
> > if (sps->bit_depth_luma_minus8 != 0)
> > /* Only 8-bit is supported */
> > return -EINVAL;
> > +
> > + width = (sps->pic_width_in_mbs_minus1 + 1) * 16;
> > + height = (sps->pic_height_in_map_units_minus1 + 1) * 16;
> > +
>
> Let's please add a comment here, clarifying it's legal to check
> the coded format (OUTPUT queue format) at .try_ctrl time,
> because the stateless decoder specification [1] mandates
> S_FMT on the OUTPUT queue, before passing the SPS/PPS controls.
Indeed, though I come to see some flaw in the validation. First, the height
formula shall be base on formula 7-18 from the spec:
FrameHeightInMbs = ( 2 − frame_mbs_only_flag ) * PicHeightInMapUnits
So would be
+ height = (sps->pic_height_in_map_units_minus1 + 1) * 16;
+ if (sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY)
+ height *= 2;
As this driver do interleaved interlaced buffer, not alternate. Finally, we
should validate this again at STREAMON, since userland may have simply omitted
to set the SPS at all. I'll try to improve this and drop the review tag to
ensure this get fully reviewed again.
>
> [1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html
>
> > + if (width > ctx->coded_fmt.fmt.pix_mp.width ||
> > + height > ctx->coded_fmt.fmt.pix_mp.height)
>
> Can you add a debug message or error message?
> These silent errors tend to get super hard to track.
>
> With these changes:
>
> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>
> Thanks,
> Ezequiel
next prev parent reply other threads:[~2022-04-05 15:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220331193726.289559-1-nicolas.dufresne@collabora.com>
2022-03-31 19:37 ` [PATCH v2 05/23] media: h264: Use v4l2_h264_reference for reflist Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 06/23] media: h264: Increase reference lists size to 32 Nicolas Dufresne
2022-04-02 12:03 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 12/23] media: rkvdec: Stop overclocking the decoder Nicolas Dufresne
2022-04-02 11:05 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 13/23] media: rkvdec: h264: Fix dpb_valid implementation Nicolas Dufresne
2022-04-02 11:16 ` Ezequiel Garcia
2022-04-05 15:10 ` Nicolas Dufresne
2022-04-05 15:34 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 14/23] media: rkvdec: h264: Fix bit depth wrap in pps packet Nicolas Dufresne
2022-04-02 11:20 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 15/23] media: rkvdec: h264: Validate and use pic width and height in mbs Nicolas Dufresne
2022-04-02 11:32 ` Ezequiel Garcia
2022-04-05 15:44 ` Nicolas Dufresne [this message]
2022-04-05 16:04 ` Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 16/23] media: rkvdec: h264: Fix reference frame_num wrap for second field Nicolas Dufresne
2022-04-02 11:33 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 17/23] media: rkvdec: Enable capture buffer holding for H264 Nicolas Dufresne
2022-04-02 11:35 ` Ezequiel Garcia
2022-03-31 19:37 ` [PATCH v2 18/23] media: rkvdec: Ensure decoded resolution fit coded resolution Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 19/23] media: rkvdec-h264: Add field decoding support Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 20/23] media: hantro: Enable HOLD_CAPTURE_BUF for H.264 Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 21/23] media: hantro: Stop using H.264 parameter pic_num Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 22/23] media: hantro: h264: Make dpb entry management more robust Nicolas Dufresne
2022-03-31 19:37 ` [PATCH v2 23/23] media: hantro: Add H.264 field decoding support Nicolas Dufresne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67742466181fef8ca42d8f5ad2815a46367f5fa7.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=gregkh@linuxfoundation.org \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=sebastian.fricke@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox