On Sun, 15 Nov 2009, Oliver Neukum wrote:
Am Sonntag, 15. November 2009 00:57:49 schrieb Theodore Kilgore:
There is a sequence of commands used in the Windows driver for
setting up these cameras, which I omitted from the code in mr97310a.c. The
reason I omitted them is, some of them actually make the camera unstable
at some of the resolution settings. In particular, at 352x288 and at
176x144. The OEM driver seems to assume that the camera will stream at
320x240 and 160x120 only, even though it is capable of 352x288 and
176x144. So, as I said, I omitted the whole sequence because it seemed to
be causing nothing but trouble.
Well, so now I took a second look. There is exactly one command which sets
up the camera to stream properly if it is hooked up to a UHCI machine! I
assume, though I have no way of really knowing this without the usb
At what resolutions does it work now?
Regards
Oliver
The maximum possible resolution for an MR97310A-based CIF camera is
352x288. The video sensor chip in them will not do more. The possible
resolution settings as far as we can tell are 352x288, 176x144 (done by
downsampling), and 320x240, 160x120 (done by downsampling from 320x240).
It would not totally surprise me if by further downsampling one could get
settings such as 80x60 as well, but who would want to do that? Another
question of perhaps theoretical interest is whether resolution settings
such as 300x200 can also be done. I would say it could possibly be done,
but, again, who cares?
In spite of what Hans says about the cameras being very el cheapo, which
is certainly true, they actually do not do a bad job for what one pays for
them. Under favorable circumstances, they can get frame rates of up to 31
fps at 176x144 or 160x240 resolution and seem to be able to sustain
something like 15 to 20 fps or so, even at 352x288. And the frames coming
out look pretty decent. Not bad for something you can buy at WalMart or
Walgreen's for $10 or less, actually.
The VGA versions of the camera can do a max of 640x480, but the fps
capability is quite a bit lower, for all resolution settings. In other
words, the frame rate is not very good even if the camera is choked down
to 176x144 or 160x120. It seems that the circuitry in the camera is just
slower across the board, in order to handle 640x480.
I should have mentioned somewhere that these are all dual-mode cameras.
They can also be used non-tethered for taking pictures. They have all been
supported in libgphoto2 for quite some time. They use a differential
Huffman encoding scheme which is quite effective, though as Hans has
noted, sometimes it leads to bad results (too much data to fit into an
assumed maximum data size, apparently, and the bottom of the frame just
gets chopped in those situations). The decompression scheme was figured
out completely in the course of working on the libgphoto2 driver, and the
camera does the compression the same way in webcam mode.
Interestingly, all the variations between the different cameras and the
need to query the camera to figure out which one it is, are not needed at
all in still camera mode. As stillcams, they all really do use the same
command set. However, one aspect of their cheapness is that they use SDRAM
instead of flash RAM for storing one's pictures. So if you want to use one
of them as a still camera, you take the pictures and then you download
them to the computer before going to bed in the evening. Or else.
Now, I said something about the OEM drivers. In webcam mode, all of the
OEM drivers that I know of set the default resolution setting at 320x240.
Some of them will not even let you change that. And, using the commands
which can be detected by sniffing, one can not get a 352x288-capable
camera, nor for that matter a 640x480-capable camera, to stream decently
at 352x288 or 176x144. Something comes out, but the frames jump terribly.
It was in eliminating the sources of that jumpiness that I simply got rid
of several setup commands, and thereby landed in the soup by leaving out a
command which appears to be essential for making some of the cameras
stream on a UHCI system. There are obvious lessons to be derived. I have a
long memory, and I think I will apply them.
The OEM drivers for these cameras are a crock. One very good reason for me
to say that is, they have no command which will detect which camera is
hooked up. That is an act of obvious social irresponsibility. The fact
that there are two variants of the 0x093a:0x010e cameras which require
mutually incompatible webcam driver software is another act of obvious
social irresponsibility. The fact that there are two variants of the
0x093a:0x010f VGA cameras and, depending on one's way of counting, even
three different variants and each variant also requires a different setup
is yet another act of obvious social irresponsibility. Responsibility
would have meant that either these variant hardware versions get different
Product numbers, or at the very least there should have been some built-in
detection going on, such as reading a firmware version number or a model
number. Other OEM drivers written for other cheap hardware do that, if
there is a need. The OEM drivers for these cameras assuredly do not do any
such thing. So you can imagine the chaos, which is even visible in the
marketplace, in the form of customer complaints.
The driver for these cameras which is going to go into the Linux kernel --
sooner or later in exactly the right version -- is the only driver for
these cameras in existence, for any operating system, which does any of
this right. That is why I said yesterday evening that anyone who has one
of these cameras and wants to use it should ditch Windows and install
Linux.
Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
