From: Boris Brezillon <boris.brezillon@collabora.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Tomasz Figa <tfiga@chromium.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
kernel@collabora.com,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Jonas Karlman <jonas@kwiboo.se>,
linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>,
Andrew Morton <akpm@linux-foundation.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Hertz Wong <hertz.wong@rock-chips.com>
Subject: Re: [PATCH 7/9] media: hantro: Add core bits to support H264 decoding
Date: Fri, 26 Jul 2019 12:06:58 +0200 [thread overview]
Message-ID: <20190726120658.53022c21@collabora.com> (raw)
In-Reply-To: <25cc2826-fc8f-570a-07fa-8cbdb11830a7@rasmusvillemoes.dk>
On Thu, 25 Jul 2019 15:31:41 +0200
Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> On 19/06/2019 14.15, Boris Brezillon wrote:
> > From: Hertz Wong <hertz.wong@rock-chips.com>
> >
> > Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
> > decoding support.
> >
> > Signed-off-by: Hertz Wong <hertz.wong@rock-chips.com>
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> > ---
> > +
> > + /*
> > + * Short term pics in descending pic num order, long term ones in
> > + * ascending order.
> > + */
> > + if (!(a->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM))
> > + return b->frame_num - a->frame_num;
> > +
> > + return a->pic_num - b->pic_num;
> > +}
>
> Pet peeve: This works because ->frame_num and ->pic_num are u16, so
> their difference is guaranteed to fit in an int.
>
> > +static int b0_ref_list_cmp(const void *ptra, const void *ptrb, const void *data)
> > +{
> > + const struct hantro_h264_reflist_builder *builder = data;
> > + const struct v4l2_h264_dpb_entry *a, *b;
> > + s32 poca, pocb;
> > + u8 idxa, idxb;
> > +
> > + idxa = *((u8 *)ptra);
> > + idxb = *((u8 *)ptrb);
> > + a = &builder->dpb[idxa];
> > + b = &builder->dpb[idxb];
> > +
> > + if ((a->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM) !=
> > + (b->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)) {
> > + /* Short term pics firt. */
> > + if (!(a->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM))
> > + return -1;
> > + else
> > + return 1;
> > + }
> > +
> > + /* Long term pics in ascending pic num order. */
> > + if (a->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
> > + return a->pic_num - b->pic_num;
> > +
> > + poca = builder->pocs[idxa];
> > + pocb = builder->pocs[idxb];
> > +
> > + /*
> > + * Short term pics with POC < cur POC first in POC descending order
> > + * followed by short term pics with POC > cur POC in POC ascending
> > + * order.
> > + */
> > + if ((poca < builder->curpoc) != (pocb < builder->curpoc))
> > + return poca - pocb;
> > + else if (poca < builder->curpoc)
> > + return pocb - poca;
> > +
> > + return poca - pocb;
> > +}
>
> Here, however, poca and pocb are ints. What guarantees that their values
> are not more than 2^31 apart?
Good question. Both should normally be >= 0, which I guess prevents the
s32 overflow. This being said, it's something passed by userspace, and
I don't think we check the value (yet).
> I know absolutely nothing about this code
> or what these numbers represent, so it may be obvious that they are
> smallish.
Well, a safe approach would be to replace those subtraction by a
ternary operator.
next prev parent reply other threads:[~2019-07-26 10:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 12:15 [PATCH 0/9] media: hantro: Add support for H264 decoding Boris Brezillon
2019-06-19 12:15 ` Boris Brezillon
2019-06-19 12:15 ` [PATCH 1/9] lib/sort.c: implement sort() variant taking context argument Boris Brezillon
[not found] ` <20190619121540.29320-2-boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2019-07-25 12:40 ` Boris Brezillon
2019-07-25 12:40 ` Boris Brezillon
2019-07-26 0:05 ` Andrew Morton
2019-07-26 0:05 ` Andrew Morton
2019-07-26 6:59 ` Rasmus Villemoes
2019-06-19 12:15 ` [PATCH 2/9] media: hantro: Move copy_metadata() before doing a decode operation Boris Brezillon
2019-06-19 12:15 ` [PATCH 4/9] media: hantro: Simplify the controls creation logic Boris Brezillon
[not found] ` <20190619121540.29320-1-boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2019-06-19 12:15 ` [PATCH 3/9] media: hantro: Constify the control array Boris Brezillon
2019-06-19 12:15 ` Boris Brezillon
2019-07-05 16:05 ` Ezequiel Garcia
2019-07-05 17:17 ` Boris Brezillon
2019-06-19 12:15 ` [PATCH 5/9] media: hantro: Add hantro_get_{src,dst}_buf() helpers Boris Brezillon
2019-06-19 12:15 ` Boris Brezillon
2019-06-19 12:15 ` [PATCH 6/9] media: hantro: Add helpers to prepare/finish a run Boris Brezillon
2019-06-19 12:15 ` [PATCH 7/9] media: hantro: Add core bits to support H264 decoding Boris Brezillon
2019-07-25 13:31 ` Rasmus Villemoes
2019-07-26 10:06 ` Boris Brezillon [this message]
2019-08-01 4:06 ` Tomasz Figa
[not found] ` <CAHD77HksotqFBTE84rRM=DuNFX=YJPs=YnsuFkaN-pWUNCtoxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-08-01 5:42 ` Boris Brezillon
2019-08-01 5:42 ` Boris Brezillon
2019-08-01 7:04 ` Paul Kocialkowski
2019-08-01 7:12 ` Tomasz Figa
2019-08-05 18:38 ` Ezequiel Garcia
2019-06-19 12:15 ` [PATCH 8/9] media: hantro: Add support for H264 decoding on G1 Boris Brezillon
2019-06-19 12:15 ` [PATCH 9/9] media: hantro: Enable H264 decoding on rk3288 Boris Brezillon
2019-06-19 12:23 ` [PATCH 0/9] media: hantro: Add support for H264 decoding Boris Brezillon
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=20190726120658.53022c21@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=akpm@linux-foundation.org \
--cc=ezequiel@collabora.com \
--cc=hans.verkuil@cisco.com \
--cc=heiko@sntech.de \
--cc=hertz.wong@rock-chips.com \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=sakari.ailus@iki.fi \
--cc=tfiga@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.