Hi,
sorry for being a bit slow ...
On 04/18/2011 12:25 PM, Antonio Ospite wrote:
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.
We should be able to make it pick color there by simply putting
the Y10B format at the end of supported_src_pixfmts
I think once we do that, that we don't need to do anything special
here. Apps which really want the grey scale data should then just request
either 640x488 or even better probably directly select Y10B and deal with
it themselves.
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?
Yeah that sounds like a bug
/me blames qv4l2
(always blame the other guy's code :)
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?
Yes, but that is an ugly UGLY hack, I don't think we will really need this,
see above.
Thanks,
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
