Re: Need VIDIOC_CROPCAP clarification

["Daniel Glöckner" <daniel-gl@gmx.net>]

On Sun, Jun 08, 2008 at 02:27:16PM +0200, Michael Schimek wrote:
> I'd hope v4l2_cropcap tells me what the hardware is actually capable of,
> i.e. the maximum physical resolution, not interpolated pixels.

How many cards do support upscaling?
Defining crop units that way would make it impossible to make use of the
higher resolution in cropping after upscaling.

And it conflicts with the idea of using tv frame lines for vertical
units if the device can only capture one field.

> You think defrect should return the size and position of the active
> picture area in hardware units, not what the closest area is the
> hardware can actually capture?

Not necessarily in hardware units, but yes. Using hardware units would
suggest that the hardware is capable of cropping to that size.

> Well that's a possibility, but for once many drivers do not support
> VIDIOC_G/S_CROP, implying defrect is what they capture.

You mean drivers that support VIDIOC_CROPCAP without VIDIOC_G/S_CROP?
I see two possibilities:
1. add VIDIOC_G/S_CROP dummies
2. add to spec that drivers without VIDIOC_G/S_CROP capture bounds

> Well the idea was that all drivers support at least 1:1 scaling, defrect
> is what apps usually want to capture and what the hardware can actually
> capture, so defrect.width and .height is a valid image size and
> presumably the highest resolution image apps can get of the active
> picture area.

That makes me think about my old FAST MovieMachine Pro.
It does not have enough on board ram to capture both fields at full
resolution. It can downscale horizontally and vertically by dropping
pixels/lines in a Bresenham way. So it's either 448x576 or 704x372 maximum.
Using 13.5 MHz sample rate pixels horizontally and tv lines vertically as
crop units will make defrect too big to be a valid image size.
What do you suggest?

> That's right but I didn't pick the numbers. By default bttv always
> captured 480 lines and quite a few apps may depend on that. I guess most
> drivers capture 480 lines in NTSC-M mode, and most apps request 480
> scaled lines.

Ah those beautiful numbers divisibly by 16 needed for MPEG...
A workaround could be to decouple the startup crop region from defrect.
Then applications that don't know about cropping get 480 lines on open
while those that do can work with 486 lines. 

This is a problem for horizontal cropping as well, when the active
region is 702 pixels wide and scaling is impossible.

> The bt8x8 in particular
> cannot begin scaling on an even frame line and end on an odd frame line,
> of the opposite field, as an odd cropping height would suggest.

On bt8x8 you set the scaling factor and tell the hardware where to save
each line. You can't prevent the chip from using one more line for
scaling but you can set a scaling factor that maps 517 lines to 512
and then capture 512 lines.

> With known cropping units one can select an absolute position. Without
> that knowledge one can still move and resize the crop window relative to
> the default and pick scale factors.

So with unknown units one can still select the absolute position if defrect
is standardized.


The ability to capture without scaling could be implemented by other
means. One could for example pass v4l2_pix_format.width=0 to get the
unscaled width for the current crop region. Width and height should then
be tried independently to make it work with my old capture card.

  Daniel

P.S.: GMX hat -all im SPF TXT RR. Du solltest deren Mailserver benutzen.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list