Hans Verkuil wrote:
On Monday 16 February 2009 05:04:40 Trent Piepho wrote:
On Sun, 15 Feb 2009, Mauro Carvalho Chehab wrote:
On Sun, 15 Feb 2009 10:29:03 +0100
Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
I think we should also be able to detect 90 and 270 degree
rotations. Or at the very least prepare for it. It's a safe bet to
assume that webcams will arrive that can detect portrait vs
landscape orientation.
Handling those (esp on the fly) will be rather hard as width and
height then get swapped. So lets worry about those when we need to.
We will need an additional flag for those cases anyways.
The camera rotation is something that is already needed, at least on
some embedded devices, like those cellular phones whose display changes
when you rotate the device.
By looking at the v4l2_buffer struct, we currently have 4 reserved
bytes. It has also one flags field, with several bits not used. I can
see 2 possibilities to extend the API:
1) adding V4L2_BUF_FLAG_HFLIP and V4L2_BUF_FLAG_VFLIP flags. This would
work for 90, 180 and 270 rotation;
HFLIP and VFLIP are only good for 0 and 180 degrees. 90 and 270 isn't
the same as flipping.
The problem I'm seeing here is that as people are using v4l2 for digital
cameras instead of tv capture there is more and more meta-data available.
Things like shutter speed, aperture, focus distance, and so on. Just
look at all the EXIF data a digital camera provides. Four bytes and two
flags are going to run out very quickly at this rate.
It's a shame there are not 8 bytes left, as then they could be used for a
pointer to an extended meta-data structure.
I think we have to distinguish between two separate types of data: fixed
('the sensor is mounted upside-down', or 'the sensor always requires a
hflip/vflip') and dynamic ('the user pivoted the camera 270 degrees').
The first is static data and I think we can just reuse the existing
HFLIP/VFLIP controls: just make them READONLY to tell libv4l that libv4l
needs to do the flipping.
The second is dynamic data and should be passed through v4l2_buffer since
this can change on a per-frame basis. In this case add two bits to the
v4l2_buffer's flags field:
V4L2_BUF_FLAG_ROTATION_MSK 0x0c00
V4L2_BUF_FLAG_ROTATION_0 0x0000
V4L2_BUF_FLAG_ROTATION_90 0x0400
V4L2_BUF_FLAG_ROTATION_180 0x0800
V4L2_BUF_FLAG_ROTATION_270 0x0c00
No need to use the reserved field.
This makes a lot more sense to me: static (or rarely changing) data does not
belong to v4l2_buffer, that's what controls are for. And something dynamic
like pivoting belongs to v4l2_buffer. This seems like a much cleaner API to
me.
I agree that we have static and dynamic camera properties, and that we may want
to have 2 API's for them. I disagree the control API is the proper API to
expose static properties, many existing applications will not handle this well.
More over in the case we are discussing now, we have one type of data (sensor
orientation) which can be both static or dynamic depending on the camera having
2 API's for this is just plain silly. Thus unnecessarily complicates things if
some camera property can be static in some cases and dynamic in others then we
should just always treat it as dynamic. This way we will only have one code
path to deal with instead of two (with very interesting interactions also, what
if both API's sat rotate 180 degrees, should we then not rotate at all?). This
way lies madness.
My conclusion:
1) Since rotation can be dynamic store it in the buffer flags
2) In the future we will most likely need an API to be able to query camera
properties
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
