All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Walls <awalls@md.metrocast.net>
To: "Aguirre, Sergio" <saaguirre@ti.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [Query] What is the best way to handle V4L2_PIX_FMT_NV12 buffers?
Date: Sun, 06 Mar 2011 12:55:24 -0500	[thread overview]
Message-ID: <1299434124.2310.12.camel@localhost> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE89448861F7E6@dlee02.ent.ti.com>

On Sat, 2011-03-05 at 22:49 -0600, Aguirre, Sergio wrote:
> Hi,
> 
> I was curious in how to handle properly buffers of pixelformat V4L2_PIX_FMT_NV12.
> 
> I see that the standard convention for determining a bytesize of an image buffer is:
> 
> bytesperline * height
> 
> However, for NV12 case, the bytes per line is equal to the width, _but_ the actual buffer size is:
> 
> For the Y buffer: width * height
> For the UV buffer: width * (height / 2)
> Total size = width * (height + height / 2)
> 
> Which I think renders the bytesperline * height formula not valid for this case.
> 
> Any ideas how this should be properly handled?

For the HM12 macroblock format:

http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/cx2341x/README.hm12;h=b36148ea07501bdac37ae74b31cc258150f75a81;hb=staging/for_v2.6.39

ivtv and cx18 do this in cx18-ioctl.c and ivtv-ioctl.c:

...
	if (id->type == xxxx_ENC_STREAM_TYPE_YUV) {
                pixfmt->pixelformat = V4L2_PIX_FMT_HM12;
                /* YUV size is (Y=(h*720) + UV=(h*(720/2))) */
                pixfmt->sizeimage = pixfmt->height * 720 * 3 / 2;
                pixfmt->bytesperline = 720;
	}
...

Note that the wdith is fixed at 720 because the CX2341x chips always
build HM12 planes assuming a width of 720, even though it isn't going to
actually fill in the off-sceen pixels for widths less than 720.


Note that "pixfmt->height * 3 / 2" is just "(height + height / 2)".

It's not a definitive answer; only an example of what two drivers do for
a very uncommon macroblock format.

Regards,
Andy

> NOTE: See here for more details: http://www.fourcc.org/yuv.php#NV12
> 
> Regards,
> Sergio--



  reply	other threads:[~2011-03-06 17:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-06  4:49 [Query] What is the best way to handle V4L2_PIX_FMT_NV12 buffers? Aguirre, Sergio
2011-03-06 17:55 ` Andy Walls [this message]
2011-03-06 19:13   ` Guennadi Liakhovetski

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=1299434124.2310.12.camel@localhost \
    --to=awalls@md.metrocast.net \
    --cc=linux-media@vger.kernel.org \
    --cc=saaguirre@ti.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 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.