From: Hans Verkuil <hverkuil@xs4all.nl>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
Mauro Carvalho Chehab <m.chehab@samsung.com>
Subject: V4L2 and frames vs fields
Date: Mon, 03 Mar 2014 15:43:36 +0100 [thread overview]
Message-ID: <53149518.3060609@xs4all.nl> (raw)
Hi all,
I've been testing and looking at how V4L2 should handle fields. The spec is awfully
vague when it comes to the V4L2_FIELD_TOP/BOTTOM/ALTERNATE field settings, so I'm
writing this down as a clarification, also for Devin who asked me about this a few
days ago and since I gave him the wrong answer I'd better get it right this time :-)
The relevant section on fields in the spec is here:
http://hverkuil.home.xs4all.nl/spec/media.html#field-order
For field formats where both fields are used the spec is reasonably clear. The
v4l2_format height field refers to the full frame height (combining both fields).
For the TOP/BOTTOM/ALTERNATE setting the format's height refers to that of the
field, not the frame. So the resulting buffer size is still height * bytesperline.
Drivers can use several strategies on how to handle this:
Some support only one field setting: INTERLACED if height > frameheight / 2 and
TOP if height <= frameheight / 2. In this case the application cannot change the
field, it is set by the driver based on the height chosen by the application.
The reverse is also possible: the driver allows you to change the field but not
the height. So INTERLACED will give a height of 576 and TOP a height of 288.
If there is a hardware scaler as well, then changing the field setting must not
change the format's height, instead the scaler is adjusted. So if the height
is 576 and the field is TOP, then the image will be scaled up by a factor of 2.
If there are limitations in what the scaler can do (say it can only downscale)
then it depends on the height which field values are honored. So attempts to
set FIELD_TOP if the height is 576 and only a downscaler is available should
result in FIELD_INTERLACE and an unchanged height. Only at heights <= 288 will
the FIELD_TOP setting work.
When implementing FIELD_ANY drivers can choose to select FIELD_TOP (or BOTTOM)
if the height <= frameheight / 2 instead of FIELD_INTERLACED.
The description of FIELD_ALTERNATE in the spec has this phrase: "Image sizes
refer to the frame, not fields." That seems nonsense to me and none of the
drivers that support FIELD_ALTERNATE does that. If any of FIELD_TOP, BOTTOM
or ALTERNATE is selected the width, height and sizeimage fields all relate
to the size of a (possibly scaled) field.
I plan on updating the spec, but I'd like to run this by you all to see if
I missed anything or got it wrong after all.
Regards,
Hans
next reply other threads:[~2014-03-03 14:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 14:43 Hans Verkuil [this message]
2014-03-03 20:27 ` V4L2 and frames vs fields Devin Heitmueller
2014-03-03 21:46 ` Hans Verkuil
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=53149518.3060609@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
--cc=m.chehab@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