[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25cc2826-fc8f-570a-07fa-8cbdb11830a7@rasmusvillemoes.dk>
Date: Thu, 25 Jul 2019 15:31:41 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Boris Brezillon <boris.brezillon@...labora.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Sakari Ailus <sakari.ailus@....fi>, linux-media@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Tomasz Figa <tfiga@...omium.org>,
Nicolas Dufresne <nicolas@...fresne.ca>, kernel@...labora.com,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
Ezequiel Garcia <ezequiel@...labora.com>,
Jonas Karlman <jonas@...boo.se>,
linux-rockchip@...ts.infradead.org,
Heiko Stuebner <heiko@...ech.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Hertz Wong <hertz.wong@...k-chips.com>
Subject: Re: [PATCH 7/9] media: hantro: Add core bits to support H264 decoding
On 19/06/2019 14.15, Boris Brezillon wrote:
> From: Hertz Wong <hertz.wong@...k-chips.com>
>
> Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
> decoding support.
>
> Signed-off-by: Hertz Wong <hertz.wong@...k-chips.com>
> Signed-off-by: Boris Brezillon <boris.brezillon@...labora.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? I know absolutely nothing about this code
or what these numbers represent, so it may be obvious that they are
smallish.
Rasmus
Powered by blists - more mailing lists