Hello, I haven't had internet access for a few days, so I didn't get this message before I started coding. Luckily, I ended up doing a lot of the things you suggested.
I have written the camera as an object created with camera.Camera(device, (width, height)), and with .start() which opens and starts it, .get_image() which returns a Surface, and .close() which stops and closes it. Currently, I just have get_image blocking, though it is a simple change to make it non blocking. MMAP by nature uses buffers. When using it non blocking, the camera driver would return EAGAIN if there is no buffer available yet. I could just make it return the last frame again on EAGAIN, though I'm not sure that is the best way. For querying, I'm not sure what would be useful beyond knowing what resolutions were supported, and as far as I know v4l2 drivers don't really let you know that beyond a suggested resolution. Right now, the width, height you create the camera with is not necessarily the width, height of the Surfaces being returned. The code I'm working on is at http://git.n0r.org/?p=pygame-nrp;a=summary As of the latest snapshot, it currently supports YUYV and RGB24 (though that is untested) cameras. I've tested it so far with vivi and the webcam in the OLPC XO. Nirav On Fri, May 30, 2008 at 3:06 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > 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 >> >
