public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Stanislawski <t.stanislaws@samsung.com>
To: Jonghun Han <jonghun.han@samsung.com>
Cc: linux-media@vger.kernel.org, m.szyprowski@samsung.com
Subject: Re: Query the meaning of variable in v4l2_pix_format and v4l2_plane
Date: Fri, 04 Nov 2011 17:02:54 +0100	[thread overview]
Message-ID: <4EB40CAE.50406@samsung.com> (raw)
In-Reply-To: <001c01cc9af2$c607e0f0$5217a2d0$%han@samsung.com>

On 11/04/2011 02:07 PM, Jonghun Han wrote:
>
> Hi,

Hi Mr. Han,

>
> I'm not sure the meaning of variables in v4l2_pix_format and v4l2_plane.
> Especially bytesperline, sizeimage, length and bytesused.
>
> v4l2_pix_format.width		= width
> v4l2_pix_format.height		= height

The fields width and height are undefined for some formats, like 
compressed JPEG and video streams.

> v4l2_pix_format.bytesperline	= bytesperline [in bytes]

The spec says "Distance in bytes between the leftmost pixels in two 
adjacent lines" for the largest plane. For YUV 4:2:0 the largest plane 
is luminance, where one pixel is one byte.

> v4l2_pix_format.sizeimage	= bytesperline * buf height  ->  Is this
> right ?

It is the upper limit for size of image of desired size. This value is 
needed if images are passed in compressed formats.

>
> v4l2_plane.length	= bytesperline * buf height  ->  Is this right ?
> I don't which is right.

This is the upper limit for a size of a given plane. For simple formats use:
v4l2_plane.length = plane_height * plane.bytesperline
The plane_height may be smaller the buf_height. For example for YUV420, 
the height of the chrominance plane, should be the half of buf_height.

For compressed formats it specify upper limit for plane size.

> v4l2_plane.bytesused	= bytesperline * (top + height)
> v4l2_plane.bytesused	= bytesperline * height
> v4l2_plane.bytesused	= width * height * bytesperpixel
> v4l2_plane.bytesused	= bytesperline * (top + height) - (pixelperline -
> (left + width)) * bytesperpixel

bytesused specify how much valid data is present in the buffer.
For simple formates you should use:
v4l2_plane.bytesused	= v4l2_plane.length
while queuing buffer into OUTPUT queue.

The inner rectangle refers to cropping rectangle for mem2mem devices. 
This rectangle should not be used in any computations of the buffer 
parameters.

Best regards,
Tomasz Stanislawski
>
> I assumed the following buffer.
>
> |                                                          |
> |<--------------------- bytesperline --------------------->|
> |                                                          |
> +----------------------------------------------------------+-----
> |          ^                                               |  ^
> |          |                                               |  |
> |                                                          |  |
> |          t                                               |  |
> |          o                                               |  |
> |          p                                               |  |
> |                                                          |  |
> |          |                                               |  |
> |          V |<--------- width ---------->|                |  |
> |<-- left -->+----------------------------+ -              |  |
> |            |                            | ^              |
> |            |                            | |              |  b
> |            |                            | |              |  u
> |            |                            |                |  f
> |            |                            | h              |
> |            |                            | e              |  h
> |            |                            | i              |  e
> |            |                            | g              |  i
> |            |                            | h              |  g
> |            |                            | t              |  h
> |            |                            |                |  t
> |            |                            | |              |
> |            |                            | |              |  |
> |            |                            | v              |  |
> |            +----------------------------+ -              |  |
> |                                                          |  |
> |                                                          |  |
> |                                                          |  v
> +----------------------------------------------------------+-----
>
>
> Best regards,
>
>


      parent reply	other threads:[~2011-11-04 16:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 13:07 Query the meaning of variable in v4l2_pix_format and v4l2_plane Jonghun Han
2011-11-04 13:28 ` Marek Szyprowski
2011-11-04 14:48   ` Hans Verkuil
2011-11-04 16:02 ` Tomasz Stanislawski [this message]

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=4EB40CAE.50406@samsung.com \
    --to=t.stanislaws@samsung.com \
    --cc=jonghun.han@samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.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