[maemo-developers] No subject

Thu Dec 30 00:36:54 EET 2010

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
> >
>

--0016368340cc1d50da049e963fd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2011/3/16 Marco Ballesio &lt;<a href=3D"mailto:gibrovacco at gmail.com">gibrovacco at gmail.com</a>&gt;=
 <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=
.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.. </blockquote><div> Hi=
 Marco and thank you for your response. Actually I use the gdigicam api =
which in turn uses the gstcamerabin. =A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">

<div class=3D"im"><br>
On 3/9/11, Nicolai Hess &lt;<a href=3D"mailto:nicolaihess at web.de">nicolaihe=
ss at web.de</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt; I hope someone can help me or points me to someone else how knows<br>
&gt; something about the gstv4l2camsrc.<br>
&gt;<br>
&gt; I have got a question regarding raw-image buffers in gstv4l2camsrc.c<b=
r>
&gt; (in gstreamer0.10-plugins-camera-<br>
&gt; 0.79 for Fremantle).<br>
&gt;<br>
&gt; I am interested in this method:<br>
&gt; gst_v4l2camsrc_send_raw_frame (GstV4l2CamSrc *v4l2camsrc, GstBuffer *b=
uf).<br>
&gt; I know the method can copy the raw-image buffer end send this over the=
<br>
&gt; GstBus.<br>
&gt; This would be a good way to make raw-images with the N900 camera.<br>
&gt;<br>
<br>
</div>A simpler way is to just use the buffer pushed through the pipeline.<=
br>
It&#39;s possible, for instance, to write exactly one frame to a file by<br=
>
connecting the v4l2camsrc to a filesink. Maybe I can give you more<br>
hints if you explain what you&#39;re exactly trying to do.<br></blockquote>=
<div><br>From the gdigicam api the pipeline isn&#39;t accessible (it is hid=
den in gdigicam-managers<br>private data). I am not sure if the buffer on t=
he pipeline has the right size at all.<br>
<br>This is the application I wrote: <a href=3D"http://talk.maemo.org/showt=
hread.php?t=3D70870">http://talk.maemo.org/showthread.php?t=3D70870</a><br>=
I use the gdigicam api because it seems that Nokias camera-ui uses this as =
well.<br>
As I found the above mentioned send_raw_frame function, I thought this woul=
d<br>be a great addition.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;">

<div class=3D"im"> 
&gt; But sadly not the full image data is copied. Here are my observations:=
 
&gt; 
&gt; The cameradriver somewhere decides(I couldn&#39;t find out where or ho=
w) the 
&gt; biggest 
&gt; image resolution would be 2576x1960 pixels with 2 bytes per pixel, so =
the 
&gt; image data would 
&gt; be =A010097920 bytes. 
 
</div>probably you&#39;ve not set the caps (e.g. resolution, frame rate, co=
lor 
space, etc.) on the v4l2camsrc sink pad. </blockquote><div> I don&#39=
;t set these properties, it is handled by gdigicam. And the settings fro=
m gdigcam are mostly reasonable. The main question are: - why doe=
s the camera driver capture at 2576x1960? 
 If you change the image resolution (with the caps (I said I user gdgica=
m to handle this but for testing purpose I can even manipulate this)), t=
he driver still captures at this resolution but crops and scales the ima=
ge to the new 
resolution. - the buffer filled by the v4l2 device driver actually =
uses 2592x1968 pixel resolution. Even though the camera driver (from gst=
v4l2camsrc) thinks the capture resolution is 2576x1960 the buffer is fil=
led with 2592x1968 pixel data! 
 Nicolai =A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left:=
 1ex;">
 
Regards 
<div><div></div><div class=3D"h5"> 
&gt; In the method: 
&gt; gst_v4l2camsrc_send_raw_frame (GstV4l2CamSrc *v4l2camsrc, GstBuffer *b=
uf) 
&gt; are two GstBuffer, 
&gt; the argument of this method &quot;buf&quot; which holds the image data=
 from the camera 
&gt; driver 
&gt; and the new copy of this buffer &quot;raw_buffer&quot;. 
&gt; 
&gt; buf buffer is copied with: 
&gt; =A0 raw_buffer =3D gst_buffer_copy (buf); 
&gt; 
&gt; The amount of bytes copied are based on the size of the source buffer<=
br>
&gt; (10097920 bytes). 
&gt; Now the raw_buffer size attribute is changed based on the raw_caps fro=
m the 
&gt; camera driver: 
&gt; =A0 /* calculate raw_size from raw_caps */ 
&gt; =A0 raw_s =3D gst_caps_get_structure (raw_caps, 0); 
&gt; =A0 gst_structure_get_int (raw_s, &quot;width&quot;, &amp;raw_width);<=
br>
&gt; =A0 gst_structure_get_int (raw_s, &quot;height&quot;, &amp;raw_height)=
; 
&gt; =A0 raw_size =3D raw_width * raw_height * 2; 
&gt; 
&gt; But the raw_buffer size isn&#39;t 10097920, the actual size is compute=
d based 
&gt; on the bayer-raw BA10 format with a 2952x1968 resolution with 2 bytes =
per 
&gt; pixel. 
&gt; 
&gt; That means the buffer copy send over GstBus has the size 10202112, but=
 the 
&gt; last 
&gt; 104192 are mostly garbage because the call 
&gt; =A0 raw_buffer =3D gst_buffer_copy (buf); 
&gt; only wrote bytes of &quot;buf&quot; data (10097920). 
&gt; 
&gt; Of course, I could change my application to store only a raw-image of<=
br>
&gt; 2576x1960. 
&gt; But what bothers me is, the source buffer (buf) actually has the full<=
br>
&gt; 2592x1968x2 data! 
&gt; I made a quick and dirty change to the above mentioned method to write=
 out 
&gt; the 
&gt; full buffer, and it indeed contains valid image data. 
&gt; 
&gt; So, my questions are, is it a bug, that the source buffer thinks its s=
ize is 
&gt; 10097920, 
&gt; whereas it actually holds 10202112 bytes of image data? 
&gt; And where is this 2576x1960 resolution setting? When I request the sup=
ported 
&gt; resolutions (v4l2camsrc-&gt;formats) I don&#39;t get 2576x1960 but 259=
2x1968 
&gt; instead. 
&gt; 
&gt; regards 
&gt; Nicolai 
&gt; 
</div></div></blockquote></div>

--0016368340cc1d50da049e963fd2--