>
>
> 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.
??? And they will when exposed through v4l2_buffer? It's all new
functionality, so that is a non-argument. The point is that libv4l has to
be able to detect and handle oddly mounted sensors. It can do that easily
through the already existing HFLIP/VFLIP controls. It's a one time check
when the device is opened (does it have read-only H/VFLIP controls? If so,
then libv4l knows it has to correct).
Completely independent from that is the camera pivot: this is dynamic and
while by default libv4l may be called upon to handle this, it should also
be possible to disable this in libv4l by the application.
You should definitely not mix pivoting information with sensor mount
information: e.g. if you see hflip and vflip bits set, does that mean that
the sensor is mounted upside down? Or that the camera is pivoted 180
degrees? That's two different things.
> 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.
I strongly disagree. Yes, if both sensor mount info and pivot info is
handled completely inside libv4l, then indeed it doesn't have to rotate at
all. But the application probably still wants to know that the user
rotated the camera 180 degrees, if only to be able to report this
situation. And this is of course even more important for the 90 and 270
degree rotations (think handhelds).
> My conclusion:
> 1) Since rotation can be dynamic store it in the buffer flags
Ack. But rotation != sensor mount position.
> 2) In the future we will most likely need an API to be able to query
> camera
> properties
For sensor mount position we have them in the form of HFLIP/VFLIP readonly
controls. One-time check, simple to use.
I'd like some more input on this from other people as well.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
