Re: [RFC, PATCH] libv4lconvert: Add support for Y10B grey format (V4L2_PIX_FMT_Y10BPACK)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 11 Apr 2011 23:07:36 +0200
Hans de Goede <hdegoede@xxxxxxxxxx> wrote:

[...]
> > I don't know libv4l yet, so I am asking for advice providing some code to
> > discuss on; looking at the last hunk of the patch: can I allocate a temporary
> > buffer only once per device (and not per frame as I am horribly doing now) and
> > reuse it in the conversion routines?
> 
> libv4l has a mechanism for doing this, you can "simply" do:
> 
> unpacked_buffer = v4lconvert_alloc_buffer(width * height * sizeof(unsigned short),
>                                            &data->convert_pixfmt_buf,
>                                            &data->convert_pixfmt_buf_size);
> 
> v4lconvert_alloc_buffer will remember the buffer (and its size) and return the
> same buffer each call. Freeing it on closing of the device is also taken care
> of. You should still check for a NULL return.
>

Thanks that works fine: I am still not sure I like passing 
'v4l2convert_data' to the pixelformat conversion routines but we'll 
discuss that on the next review round.

> What has me worried more, is how libv4l will decide between asking
> Y10B grey versus raw bayer from the device when an app is asking for say RGB24.
> libv4l normally does this automatically on a best match basis (together with
> preferring compressed formats over uncompressed for high resolutions). But this
> won't work in the kinect case. If we prioritize one over the other we will
> always end up giving the app the one we prioritize.
>

Mmh, I tried to materialize your worries, these are the native modes 
supported:
  - GRBG mode at 640x480 and 1280x1024
  - UYVY mode ay 640x480
  - Y10B mode at 640x488 and 1280x1024
                       ^

and this is the behavior I am observing in qv4l2 when in _wrapped_ mode:
  - If I choose the RGB3 output format all the three different
    resolutions are selectable:
      + at 640x480 I get the color image, as there is no greyscale 
        format at the same resolution,
      + at 640x488 I get the grayscale image, as there is no color 
        format at the same resolution,
      + if I choose 1280x1024 I get the grayscale image indeed, and I 
        loose the possibility of using the color image.

Everything works fine in _raw_ mode of course where only the native
formats are shown.

Ah, a strange thing (to me at least) happens in _wrapped_ mode even for 
GRBG (which is supposed to be a _native_ color format for the device):
I get the grayscale image at 1280x1024 instead of the color image; can 
this just be a bug somewhere in qv4l2 or lib4vl?

> The only thing I can think of is adding a v4l2 control (like a brightness
> control) for choosing which format to prioritize...
>

and this control would be created by libv4l when in wrapped mode?

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Attachment: pgpoztFVdXa3V.pgp
Description: PGP signature


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux