Hi Guilherme, (I'm removing the old mailing list and add CC the current one) -----Original Message----- From: video4linux-list-bounces@xxxxxxxxxx [mailto:video4linux-list-bounces@xxxxxxxxxx] On Behalf Of Guilherme Raymo Longo Sent: Friday, September 11, 2009 10:17 AM To: video4linux-list@xxxxxxxxxx Subject: v4l2 driver seems to be capturing frames too slow! Hi mates. Plz, could I get some help from here. This is my first attempt of creating a v4l2 app and I am a bit confused about few things even after reading the WIKI. 1 - I am using mmap to map the memory in the device. In the example I have, there is only 1 QBUF and 1 DQBUF, so I presume that all the 4 buffers are been queued and dequeued when those functions are called. Am I committing a mistake here or that is correct? Here you can see the code: http://pastebin.com/m367448b8 Yes, I suppose you are getting right. 2 - If you notice, right after the buffers been dequeued the program calls a function "process_image (buffers[buf.index].start);" that I also presume been all the 4 buffers "buffer[start] to buffer[3]". Each buffer is 8byte long so I have 64bits of memory mapped. The compression I am using is RGB32 that stores each RGBA pixels in 4 bytes (1 for each color + 1 for alpha): If this is true and I am capturing a image 640x480 I am gonna have 307.200 pixel and a necessary space of 1.228.8 bytes to store each frame. What means approximately 1.23MB per frame. Is that correct or I am calculating it improperly Correct, and you can get the actual data size value from bytesused in v4l2_buffer on DQBUF. 3 - And the last question is, that function I mentioned earlier process_image (buffers[buf.index].start) prints approximately 6 dots per second wich means (taking in account that each buffer has 8bytes and I have them all filled with data) 6 x 8bytes read to process the image. Not even close to be a complete frame. the full program can be seen here: http://pastebin.com/m43801a5e I recognize that code. Similar thing can be found in v4l2 spec document. But I prefer to use memcpy() the image data to frame buffer rather than printing every single pixel at a time. Try to figure out to copy the whole single image frame to the frame buffer. It should be faster. You can copy exact amount of data based on bytesused value :) Cheers, Nate = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo.kim@xxxxxxxxx dongsoo45.kim@xxxxxxxxxxx -- 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
