Quoting Eric Pichon <eric@xxxxxxxxxxxx>: > Each board will have its own camera, either USB or FireWire. > > We want to achieve 320x200 at 30 fps and need to use the v4l API. > > I would like to know : > - can we use FireWire cams with v4l ? As long as you have the FireWire driver for your camera... > - would a USB cam be able to do 320x200x30 ? (because of the USB 12Mb/s we > would need hardware compression, but will the compression algorithm behave OK > if the camera is always moving - as on a 25 mph RC car ?) USB cam is most likely to be too slow. Existing compression algorithms (implemented in camera's hardware) are too primitive for good motion tracking - I doubt even if MPEG would be good enough for that! Even worse: most compression algorithms are trade secrets, and Linux drivers don't implement them - except Philips driver, which contains a closed-source optional decompressor. A raw, uncompressed datastream won't give you 30 FPS. If you want you can run two cameras in parallel; but they don't have any means of synchronization, unfortunately. Otherwise you could run them in counterphase. > If you have any comment - specially about the choice of the cameras (should > be small, resist to shocks and vibrations and as cheap as possible) I'm very > interested too ! You might need to develop your own camera - which is NOT connected through USB. bt8xx chips are easy to find, and analog front ends are also available for $50 or so (the lens, the sensor and some analog outputs). So depending on what you want you can make a PCI camera. If you have a FireWire camera it might work for you. But I haven't seen any. Dmitri -- The memory management on the PowerPC can be used to frighten small children. (Linus Torvalds.)
Attachment:
pgprzMgHTEtDW.pgp
Description: PGP signature
