2011/3/16 Marco Ballesio <gibrova...@gmail.com> > Hi Nicolai, > > have you tried using the camerabin element? It provides much more > facilities (e.g. AWB) than v4lcamsrc (and it ultimately uses the > latter as a source). Btw, some comments below.. >
Hi Marco and thank you for your response. Actually I use the gdigicam api which in turn uses the gstcamerabin. > > On 3/9/11, Nicolai Hess <nicolaih...@web.de> wrote: > > Hi, > > I hope someone can help me or points me to someone else how knows > > something about the gstv4l2camsrc. > > > > I have got a question regarding raw-image buffers in gstv4l2camsrc.c > > (in gstreamer0.10-plugins-camera- > > 0.79 for Fremantle). > > > > I am interested in this method: > > gst_v4l2camsrc_send_raw_frame (GstV4l2CamSrc *v4l2camsrc, GstBuffer > *buf). > > I know the method can copy the raw-image buffer end send this over the > > GstBus. > > This would be a good way to make raw-images with the N900 camera. > > > > A simpler way is to just use the buffer pushed through the pipeline. > It's possible, for instance, to write exactly one frame to a file by > connecting the v4l2camsrc to a filesink. Maybe I can give you more > hints if you explain what you're exactly trying to do. > >From the gdigicam api the pipeline isn't accessible (it is hidden in gdigicam-managers private data). I am not sure if the buffer on the pipeline has the right size at all. This is the application I wrote: http://talk.maemo.org/showthread.php?t=70870 I use the gdigicam api because it seems that Nokias camera-ui uses this as well. As I found the above mentioned send_raw_frame function, I thought this would be a great addition. > > But sadly not the full image data is copied. Here are my observations: > > > > The cameradriver somewhere decides(I couldn't find out where or how) the > > biggest > > image resolution would be 2576x1960 pixels with 2 bytes per pixel, so the > > image data would > > be 10097920 bytes. > > probably you've not set the caps (e.g. resolution, frame rate, color > space, etc.) on the v4l2camsrc sink pad. > I don't set these properties, it is handled by gdigicam. And the settings from gdigcam are mostly reasonable. The main question are: - why does the camera driver capture at 2576x1960? If you change the image resolution (with the caps (I said I user gdgicam to handle this but for testing purpose I can even manipulate this)), the driver still captures at this resolution but crops and scales the image to the new resolution. - the buffer filled by the v4l2 device driver actually uses 2592x1968 pixel resolution. Even though the camera driver (from gstv4l2camsrc) thinks the capture resolution is 2576x1960 the buffer is filled with 2592x1968 pixel data! Nicolai > > Regards > > > In the method: > > gst_v4l2camsrc_send_raw_frame (GstV4l2CamSrc *v4l2camsrc, GstBuffer *buf) > > are two GstBuffer, > > the argument of this method "buf" which holds the image data from the > camera > > driver > > and the new copy of this buffer "raw_buffer". > > > > buf buffer is copied with: > > raw_buffer = gst_buffer_copy (buf); > > > > The amount of bytes copied are based on the size of the source buffer > > (10097920 bytes). > > Now the raw_buffer size attribute is changed based on the raw_caps from > the > > camera driver: > > /* calculate raw_size from raw_caps */ > > raw_s = gst_caps_get_structure (raw_caps, 0); > > gst_structure_get_int (raw_s, "width", &raw_width); > > gst_structure_get_int (raw_s, "height", &raw_height); > > raw_size = raw_width * raw_height * 2; > > > > But the raw_buffer size isn't 10097920, the actual size is computed based > > on the bayer-raw BA10 format with a 2952x1968 resolution with 2 bytes per > > pixel. > > > > That means the buffer copy send over GstBus has the size 10202112, but > the > > last > > 104192 are mostly garbage because the call > > raw_buffer = gst_buffer_copy (buf); > > only wrote bytes of "buf" data (10097920). > > > > Of course, I could change my application to store only a raw-image of > > 2576x1960. > > But what bothers me is, the source buffer (buf) actually has the full > > 2592x1968x2 data! > > I made a quick and dirty change to the above mentioned method to write > out > > the > > full buffer, and it indeed contains valid image data. > > > > So, my questions are, is it a bug, that the source buffer thinks its size > is > > 10097920, > > whereas it actually holds 10202112 bytes of image data? > > And where is this 2576x1960 resolution setting? When I request the > supported > > resolutions (v4l2camsrc->formats) I don't get 2576x1960 but 2592x1968 > > instead. > > > > regards > > Nicolai > > >
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
