public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org,
	Mauro Carvalho Chehab <m.chehab@samsung.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	kernel@pengutronix.de
Subject: Re: [RFC] [media] v4l2: add V4L2 pixel format array and helper functions
Date: Mon, 25 Aug 2014 17:13:09 +0200	[thread overview]
Message-ID: <1794623.zNambAqeEh@avalon> (raw)
In-Reply-To: <1408971053.3191.39.camel@paszta.hi.pengutronix.de>

On Monday 25 August 2014 14:50:53 Philipp Zabel wrote:
> Hi Hans,
> 
> Am Montag, den 25.08.2014, 13:38 +0200 schrieb Hans Verkuil:
> > Hi Philipp,
> > 
> > I have to think a bit more about the format names, but in the meantime I
> > have
> > two other suggestions:
> Thank you, I haven't spent much thought about the actual descriptions
> yet. Most are just transcribed from the comments in videodev2.h without
> looking at the names used in the drivers.
> 
> [...]
> 
> > > +/**
> > > + * struct v4l2_pixfmt - internal V4L2 pixel format description
> > > + * @name: format description to be returned by enum_fmt
> > > + * @pixelformat: v4l2 pixel format fourcc
> > > + * @bpp_line: bits per pixel, averaged over a line (of the first plane
> > > + *            for planar formats), used to calculate bytesperline
> > > + *            Zero for compressed and macroblock tiled formats.
> > > + * @bpp_image: bits per pixel, averaged over the whole image. This is
> > > used to
> > > + *             calculate sizeimage for uncompressed formats.
> > > + *             Zero for compressed formats.
> > 
> > I would add a 'planes' field as well for use with formats that use
> > non-contiguous planes.
> 
> Good point, I'll add that.
> 
> [...]
> 
> > > +static inline unsigned int v4l2_bytesperline(const struct v4l2_pixfmt
> > > *fmt, +					     unsigned int width)
> > > +{
> > > +	return width * fmt->bpp_line / 8;
> > 
> > Round up: return (width * fmt->bpp_line + 7) / 8;
> 
> Right, I should use DIV_ROUND_UP(width * fmt->bpp_line, 8) here.
> 
> > > +}
> > > +
> > > +static inline unsigned int v4l2_sizeimage(const struct v4l2_pixfmt
> > > *fmt,
> > > +					  unsigned int width,
> > > +					  unsigned int height)
> > > +{
> > > +	return width * height * fmt->bpp_image / 8;
> > 
> > Ditto: return height * v4l2_bytesperline(fmt, width);
> 
> I can't use v4l2_bytesperline because that might be zero for macroblock
> tiled formats and uses the wrong bpp value for planar formats with
> subsampled chroma.
> 
> This nearly works:
>     return height * DIV_ROUND_UP(width * fmt->bpp_image, 8)

Isn't that exactly height * v4l2_bytesperline(fmt, width) ?

> For the planar 4:2:0 subsampled formats and Y41P (bpp_image == 12),
> width has to be even, so that is ok.
> Most other formats have a bpp_image that is divisible by 8, but there
> are the 4:1:0 subsampled formats (bpp_image == 9). Those would round up
> width to a multiple of eight, even though it only has to be a multiple
> of four. I'd fall back to:
> 
>     if (fmt->bpp_image == fmt->bpp_line) {
>         return height * DIV_ROUND_UP(width * fmt->bpp_image, 8);
>     } else {
>         /* we know that v4l2_bytesperline doesn't round for planar */
>         return height * width * fmt->bpp_image / 8;
>     }

Isn't that growing slightly too big for an inline function ?

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2014-08-25 15:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 10:33 [RFC] [media] v4l2: add V4L2 pixel format array and helper functions Philipp Zabel
2014-08-25 11:38 ` Hans Verkuil
2014-08-25 11:53   ` Laurent Pinchart
2014-08-25 12:50   ` Philipp Zabel
2014-08-25 15:13     ` Laurent Pinchart [this message]
2014-08-25 15:41       ` Philipp Zabel
2014-08-25 15:47         ` Laurent Pinchart
2014-08-26  9:13           ` Philipp Zabel
2014-08-26 20:18 ` Guennadi Liakhovetski
2014-08-27  9:19   ` Philipp Zabel

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=1794623.zNambAqeEh@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@pengutronix.de \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=p.zabel@pengutronix.de \
    /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