Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede <j.w.r.degoede@hhs.nl>]

On 04/04/2009 10:22 PM, Erik Andrén wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> While trying to get hflip and vflip working for the stv06xx webcam
> bridge coupled to the vv6410 sensor I've come across the following
> problem.
>
> When flipping the image horizontally, vertically or both, the sensor
> pixel ordering changes. In the m5602 driver I was able to compensate
> for this in the bridge code. In the stv06xx I don't have this
> option. One way of solving this problem is by changing the
> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
> format. When a vertical flip is required, change the format to
> V4L2_SBGGR8.
>
> My current understanding of libv4l is that it probes the pixelformat
>    upon device open. In order for this to work we would need either
> poll the current pixelformat regularly or implement some kind of
> notification mechanism upon a flipping request.
>
> What do you think is this the right way to go or is there another
> alternative.
>

The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to impossible
(JPEG for example).

Regards,

Hans


p.s.

One problem with this approach is that if an apps ask for a native
cam format which is not one which we can also convert to, the
flipping won't work. I think this is best solved by simply not
listing the native formats in the enum-fmt output when the cam
needs flipping.