Hallo Frank!
I also just bought an ov518 camera (Terratec TerraCam USB) and use the ov51x driver with JPEG compression.
(I think it has the compression, at least in the driver README stands: For OV518/OV518+ cameras: Compression support is built into ov511.o and enabled by default. )
For me it's working fine with pdp (have you tried it?), but I have problems with GEM (very much noise in the picture and I had to exchange the blue and red color channel - as I wrote some days ago).
Do you have the same problem?
@IOhannes: Maybe this compression is the problem with GEM (I haven't thought about that earlier) ?
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
I also just bought an ov518 camera (Terratec TerraCam USB) and use the ov51x driver with JPEG compression.
Well, the EyeToy cam uses the ov519 chip, which is different from the ov518. For the ov518 I think, you also load a "decompress" module, which then handles the converting from the compressed data to <what?>. Or this is done in the driver module itself. Not so for the ov519.
Also I think, it's not jpeg compresseion with the ov518, otherwise the decompression could just be used the same for the ov519 as well, which I guess, the module author would have done then.
For me it's working fine with pdp (have you tried it?), but I have problems with GEM (very much noise in the picture and I had to exchange the blue and red color channel - as I wrote some days ago).
Do you have the same problem?
No, I don't see a real picture at all, just about 10 scanlines of noise in the top of the pdp or gem window. It might be, that this is the header of the jpeg frame taken as image in <what?> format.
Ciao
Frank Barknecht _ ______footils.org__
On Sun, 19 Dec 2004, Georg Holzmann wrote:
I also just bought an ov518 camera (Terratec TerraCam USB) and use the ov51x driver with JPEG compression. (I think it has the compression, at least in the driver README stands: For OV518/OV518+ cameras: Compression support is built into ov511.o and enabled by default. )
I heard about a decision from the linux-kernel guys that image format conversion code should not be in kernel drivers anymore. Unfortunately this puts all the burden of conversion on the application. To make things worse, there are no user-mode provisions in the V4L1 interface, so _if_ there was any user-mode wrapper that would make a V4L1 driver available in all color-models and such, programs would have to be recompiled using a function that may behave like ioctl() but can't be named ioctl(). (am I being clear?)
Now, I don't know the specifics of the ov518 camera and/or driver and whether or not it has the capability to give uncompressed frames.
I figured out that if you want to know which colormodels are supported in a given V4L1 driver you have to send a request for each possible color model and figure out whether it was accepted or not.
Actually now that I look at it, those things are called "palettes" in the V4L1 interface. GridFlow reports this when you open the camera:
[gf] This card supports palettes: 0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 13, 14, 15, 16
Those numbers are the palette #define's of /usr/include/linux/videodev.h.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
-
Frank Barknecht -
Georg Holzmann -
Mathieu Bouchard