hi, a few notes...
> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer, > and convert the image to RGB24 (if it isn't already) as a Surface. I like that idea. *- it needs multiple camera support. So make it create a camera object. For example: a_camera = camera.Camera(device, width, height) a_camera.get_image() *- you could try implementing your api with the opencv python wrapper. This way you could start adding tests early on. *- since many cameras are low frame rate, it would be nice if there were events emitted for things like FRAME_AVAILABLE. eg. if a camera is 10fps then it'd be good if the get image call didn't block - so then the rest of the program can run faster. This could require buffering of frames. Perhaps in a separate thread. Or maybe there could be a blocking call, and the rest is left up to the user. What do you think is a good way to handle blocking? Also I think some cameras require you to get the image data at a certain frequency... otherwise an internal buffer overflows or something. This has been my experience with opencv anyway. *- Some way to query camera capabilities? On Tue, May 27, 2008 at 3:22 PM, Nirav Patel <[EMAIL PROTECTED]> wrote: > Hello all, > > I'd like to propose a pygame module to enable camera support. > Specifically, v4l2 support with the eventual possibility of v4l and > vfw. I realise having only v4l2 to start with limits it to linux, but > its a start. It will consist of the following functions. > > camera.open(device, width, height) > camera.start() > camera.getimage() returns Surface > camera.stop() > camera.close() > > The parameters for open are intentionally simple. Similar to > libraries like OpenCV, it will negotiate with the v4l2 drivers to pick > an acceptable pixel format. At least to start with, the supported > pixel formats would be the most common ones like RGB3 (RGB24), R444 > (RGB444), YUYV, and others that people want. > > The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer, > and convert the image to RGB24 (if it isn't already) as a Surface. > > Nirav Patel >
