From: "Daniel Glöckner" <daniel-gl@gmx.net>
To: Andy Walls <awalls@radix.net>
Cc: v4l <video4linux-list@redhat.com>, Michael Schimek <mschimek@gmx.at>
Subject: Re: Need VIDIOC_CROPCAP clarification
Date: Wed, 28 May 2008 04:19:13 +0200 [thread overview]
Message-ID: <20080528021912.GA789@daniel.bse> (raw)
In-Reply-To: <1211930655.3197.18.camel@palomino.walls.org>
Just looking at the intended usage of struct v4l2_cropcap and ignoring
most of the descriptions in the standard, I would explain it this way:
struct v4l2_crop x = {
type,
{ 0, 0,
v4l2_cropcap.pixelaspect.numerator,
v4l2_cropcap.pixelaspect.denominator
}
};
defines a square region on (or outside) the screen.
This does not take into account anamorphic 16:9 transmissions.
There is no information in v4l2_cropcap on how to map these values to
pixels. The mapping has to be done with VIDIOC_S_FMT.
v4l2_cropcap tells us how to calculate the DAR for a crop region.
v4l2_format defines how to calculate the PAR from the DAR.
The height of defrect should correspond to the active picture area.
In case of 625-line PAL/SECAM it should represent 576 lines.
It follows that
width = defrect.height * 4/3
* v4l2_cropcap.pixelaspect.numerator
/ v4l2_cropcap.pixelaspect.denominator;
covers 52µs of a 64µs PAL/SECAM line.
52µs equals 702 BT.601 pixels.
The defrect.left+defrect.width/2 should be the center of the active picture
area. This is 36.5µs after OH (start of horizontal sync) for PAL/SECAM
according to BT.1700.
These microsecond calculations can of course only be done if v4l2_std_id is
a known standard.
If it is unknown, the application only knows that defrect looks good and
how to scale the image to get the aspect ratio right.
All of this is how I think it should work, not necessarily how it is
standardized.
Many people use 480 lines instead of 486 lines for the active region in NTSC
and if there are inconsistencies in drivers, application may degrade the
picture by scaling. Therefore it would be nice if at least analog vertical
resolution was mapped 1:1 to cropping regions per standard.
Not doing so would make sense only if there was a tv standard where the
image is drawn column-wise.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
prev parent reply other threads:[~2008-05-28 2:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-26 21:26 Need VIDIOC_CROPCAP clarification Hans Verkuil
2008-05-27 1:16 ` Andy Walls
2008-05-27 6:53 ` Hans Verkuil
2008-05-27 7:00 ` Hans Verkuil
2008-05-27 23:14 ` Andy Walls
2008-06-06 22:29 ` Michael Schimek
2008-06-07 1:33 ` Daniel Glöckner
2008-06-08 12:27 ` Michael Schimek
2008-06-08 16:55 ` Daniel Glöckner
2008-06-07 2:28 ` Andy Walls
2008-06-08 12:27 ` Michael Schimek
2008-06-11 18:49 ` Hans Verkuil
2008-06-11 20:15 ` Daniel Glöckner
2008-05-27 23:24 ` Andy Walls
2008-05-28 2:19 ` Daniel Glöckner [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=20080528021912.GA789@daniel.bse \
--to=daniel-gl@gmx.net \
--cc=awalls@radix.net \
--cc=mschimek@gmx.at \
--cc=video4linux-list@redhat.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