MR97310A and other image formats

MR97310A and other image formats

[Jean-Francois Moine]

Hi Kyle,

Looking at the v4l library from Hans de Goede, I did not find the
decoding of the MR97310A images. May you send him a patch for that?

BTW, I am coding the subdriver of a new webcam, and I could not find
how to decompress the images. It tried many decompression functions,
those from the v4l library and most from libgphoto2 without any
success. Does anyone know how to find the compression algorithm?

Cheers.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: MR97310A and other image formats

[Thomas Kaiser]

Jean-Francois Moine wrote:
> Hi Kyle,
> 
> Looking at the v4l library from Hans de Goede, I did not find the
> decoding of the MR97310A images. May you send him a patch for that?
> 
> BTW, I am coding the subdriver of a new webcam, and I could not find
> how to decompress the images. It tried many decompression functions,
> those from the v4l library and most from libgphoto2 without any
> success. Does anyone know how to find the compression algorithm?
> 
> Cheers.
> 

Hello Jean-Francois

Do you have some more information about the cam and the stream?
Do you know the frame header?
Any idea what the compression should be?
Can you provide a raw stream from the cam?

Thomas

Re: MR97310A and other image formats

[Thomas Kaiser]

Jean-Francois Moine wrote:
> Hi Kyle,
> 
> Looking at the v4l library from Hans de Goede, I did not find the
> decoding of the MR97310A images. May you send him a patch for that?
> 
> BTW, I am coding the subdriver of a new webcam, and I could not find
> how to decompress the images. It tried many decompression functions,
> those from the v4l library and most from libgphoto2 without any
> success. Does anyone know how to find the compression algorithm?
> 
> Cheers.
> 

Hello Jean-Francois

Do you have some more information about the cam and the stream?
Do you know the frame header?
Any idea what the compression should be?
Can you provide a raw stream from the cam?

Thomas

Re: MR97310A and other image formats

[Kyle Guinn]

On Tuesday 17 February 2009 13:09:28 Jean-Francois Moine wrote:
> Hi Kyle,
>
> Looking at the v4l library from Hans de Goede, I did not find the
> decoding of the MR97310A images. May you send him a patch for that?
>

Yes, I sent this to him some time ago.  Take a look here:
http://linuxtv.org/hg/~hgoede/v4l-dvb/rev/a647c2dfa989

-Kyle

Re: MR97310A and other image formats

[Jean-Francois Moine]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On Tue, 17 Feb 2009 20:35:28 +0100
Thomas Kaiser <v4l@kaiser-linux.li> wrote:
> Jean-Francois Moine wrote:
> > BTW, I am coding the subdriver of a new webcam, and I could not find
> > how to decompress the images. It tried many decompression functions,
> > those from the v4l library and most from libgphoto2 without any
> > success. Does anyone know how to find the compression algorithm?
> 
> Hello Jean-Francois
> 
> Do you have some more information about the cam and the stream?
> Do you know the frame header?
> Any idea what the compression should be?
> Can you provide a raw stream from the cam?

Hello Thomas,

The cam is a Tascorp 17a1:0118. I have USB traces. Starting the webcam
is easy, and so is extracting the images (0x02 + 0xa0/0xa1 at start of
image packets and 0x5a + 0xa5 for end of image with average luminosity).

I attach an image I extracted by hand from the trace, removing the 2
bytes of the packets. If it can help, I may send you the whole USB trace
(3 Mb) and/or other images.

Cheers.

-- 
Ken ar c'hentan	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[-- Attachment #2: image.dat --]
[-- Type: application/octet-stream, Size: 23530 bytes --]

Re: MR97310A and other image formats

[Thomas Kaiser]

Jean-Francois Moine wrote:
> On Tue, 17 Feb 2009 20:35:28 +0100
> Thomas Kaiser <v4l@kaiser-linux.li> wrote:
>> Jean-Francois Moine wrote:
>>> BTW, I am coding the subdriver of a new webcam, and I could not find
>>> how to decompress the images. It tried many decompression functions,
>>> those from the v4l library and most from libgphoto2 without any
>>> success. Does anyone know how to find the compression algorithm?
>> Hello Jean-Francois
>>
>> Do you have some more information about the cam and the stream?
>> Do you know the frame header?
>> Any idea what the compression should be?
>> Can you provide a raw stream from the cam?
> 
> Hello Thomas,
> 
> The cam is a Tascorp 17a1:0118. I have USB traces. Starting the webcam
> is easy, and so is extracting the images (0x02 + 0xa0/0xa1 at start of
> image packets and 0x5a + 0xa5 for end of image with average luminosity).
> 
> I attach an image I extracted by hand from the trace, removing the 2
> bytes of the packets. If it can help, I may send you the whole USB trace
> (3 Mb) and/or other images.
> 
> Cheers.
> 

Hello Jean-Francois

Thanks, for the frame (or frames?). What resolution did you use while 
recording this stream?
Can you put your USB trace somewhere on the net where I can download it?

When I was guessing the streams of webcams, I used to get the sensor 
into saturation -> complete white picture. So you know how the decoded 
picture should look like ;-)

Actually, it is quite easy to get a webcam sensor into saturation. Just 
remove the lens of the cam an put a light in front of it. Check in 
Windoz if the picture is really complete white and then record a stream 
in Linux. Now, you should get a very homogeneous stream. Look at it and ....

I hope you got the idea?

Thomas

Re: MR97310A and other image formats

[Jean-Francois Moine]

On Wed, 18 Feb 2009 13:58:00 +0100
Thomas Kaiser <v4l@kaiser-linux.li> wrote:

> Hello Jean-Francois

Hello Thomas and Steve,

> Thanks, for the frame (or frames?).

It is a full image. It is compressed: the images have different sizes,
about 25 Kb.

> What resolution did you use while recording this stream?

I have not the webcam, it is Steve's. Looking at the image size, I think
the resolution should be 640x480, but it maybe 352x288. Steve?

> Can you put your USB trace somewhere on the net where I can download
> it?

	http://moinejf.free.fr/UsbSnoop.zip

> When I was guessing the streams of webcams, I used to get the sensor 
> into saturation -> complete white picture. So you know how the
> decoded picture should look like ;-)
> 
> Actually, it is quite easy to get a webcam sensor into saturation.
> Just remove the lens of the cam an put a light in front of it. Check
> in Windoz if the picture is really complete white and then record a
> stream in Linux. Now, you should get a very homogeneous stream. Look
> at it and ....
> 
> I hope you got the idea?

Very good idea. Steve, may you do such a trace?

Cheers.

-- 
Ken ar c'hentan	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: MR97310A and other image formats

[kilgota]

On Tue, 17 Feb 2009, Kyle Guinn wrote:

> On Tuesday 17 February 2009 13:09:28 Jean-Francois Moine wrote:
>> Hi Kyle,
>>
>> Looking at the v4l library from Hans de Goede, I did not find the
>> decoding of the MR97310A images. May you send him a patch for that?
>>
>
> Yes, I sent this to him some time ago.  Take a look here:
> http://linuxtv.org/hg/~hgoede/v4l-dvb/rev/a647c2dfa989
>
> -Kyle
> --

I have several cameras with this chipset in them; they are supported in 
libgphoto2 under camlibs/mars. Therefore, I was very interested when I 
found this driver, which was based upon the old Aiptek Pencam VGA+ 
0x08ca:0x0111. I can confirm that my Aiptek Pencam VGA+ also works. I also 
tried out some other cameras, thinking that their USB Vendor:Product IDs 
should be added. I met only mixed success with them.

1. 0x093a:0x010f cameras: I own three of them. Only one of the three will 
stream. The other two will not. The streaming fails at a very early stage, 
due to a USB error. Since one of them does work, should this ID be added? 
Pro: It works quite nicely. Con: The other cameras with the same USB 
Vendor:Product number do not work at all.

2. 0x93a:0x010e cameras: All of them will emit some kind of stream, but 
the output is not viewable, coming up instead as nonsense. I am somewhat 
nonplussed by this, in view of the fact that all of these cameras but one
use the same decompression algorithm as the Aiptek. The one which uses a 
different decompression algorithm is not supported in libgphoto2, either. 
It is one of the 0x093a:0x010f cameras.

Theodore Kilgore

Re: MR97310A and other image formats

[kilgota]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3270 bytes --]



On Tue, 17 Feb 2009, Jean-Francois Moine wrote:

> Hi Kyle,
>
> Looking at the v4l library from Hans de Goede, I did not find the
> decoding of the MR97310A images. May you send him a patch for that?
>
> BTW, I am coding the subdriver of a new webcam, and I could not find
> how to decompress the images. It tried many decompression functions,
> those from the v4l library and most from libgphoto2 without any
> success. Does anyone know how to find the compression algorithm?
>
> Cheers.
>
> -- 
> Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/


How ironic that we mention a problem with a webcam's compression and we 
also mention the MR97310 chip. I posted earlier today that I have several 
cameras with MR97310 chip, in addition to the single one which is 
supported by the current module. I mentioned that none of those with ID 
0x093a:0x010e are working, because the image does not come out. Well, 
further investigation reveals that they very likely are using a different 
compression algorithm while running in webcam mode. I modified the code in 
the module to save the SOF marker (which contains the info about which 
compression algorithm is used) and the rest of the header. The rest of the 
header has information in it relating to the image which ought to be kept, 
too.  I also modified the decoding in libv4l to jump past these 12 bytes 
before starting to decode.

What I found:

After shooting a raw frame, I get

FF FF 00 FF 96 64 D0 01 27 00 06 2D

The byte D0 is a new one. I have never seen it before. What I have 
previously seen is written up in camlibs/mars/README.mars. If this byte is 
0, it signifies "no compression." If it is 0x20, the camera is using the 
unknown compression used by only one camera that I have ever seen. If it 
is 0x50 it is the "standard" mr97310 compression which is used in 
camlibs/mars and also here.

My conclusion is that the 0xD0 signifies a new, previously unknown 
compression algorithm. In a way, this is remarkable because the same 
cameras are using the "standard" compression when running in still camera 
mode.

I also looked through my collection of cheap cameras for other 
0x093a:0x010f cameras. I found one that I had missed. It streams. 
Therefore, I would tentatively recommend to add the USB ID 0x093a:0x010f 
to the list of supported cameras in the mr97310a module.

Reasoning for the above:

The two 0x093a:0x010f cameras which do stream also do it perfectly well, 
with not a single problem. The two which do not stream do not stream at 
all. Why does the streaming fail? I don't know right now, but it is clear 
from running in debug mode and from trying to capture one raw image that 
no data comes at all from those two cameras. They go thorough all the 
initial motions just fine, but no data comes out. In any event, one of 
those which do not work is also the one camera discovered years ago 
which also uses still another compression algorithm in stillcam mode and 
is therefore currently useless in stillcam mode, too.

So perhaps it is the right thing to do to include the USB ID 0x093a:0x010f 
but to provide documentation that the streaming works for some of these 
but not all? Is there any policy about things like this?


Theodore Kilgore

Re: MR97310A and other image formats

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
> ID 0x093a:0x010e are working, because the image does not come out. Well,

Just if you don't know.....

ID 0x093a is the vendor ID from Pixart. Did MARS change the name to Pixart?

> What I found:
> 
> After shooting a raw frame, I get
> 
> FF FF 00 FF 96 64 D0 01 27 00 06 2D

There is the same Frame Header for the PAC207 and PAC7311 (FF FF 00 FF 
96 ..... 12 Bytes in total as I remember).
PAC207 does a line based compression and PAC7311 is jpeg based with a 
marker in front of each MCU. Both decompression are supported by libv4l :-)

The PAC207 can be configured to run in raw mode or compressed mode. The 
same should be possible to do with the PAC7311, but I could not find the 
right register to set this :-(

Don't know if this info helps you? (or you already know)

Thomas

Re: MR97310A and other image formats

[kilgota]

On Thu, 19 Feb 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>> ID 0x093a:0x010e are working, because the image does not come out. Well,
>
> Just if you don't know.....
>
> ID 0x093a is the vendor ID from Pixart. Did MARS change the name to Pixart?

No idea. But the single camera which the module presently supports is the 
Aiptek Pencam VGA+ which IIRC has a vendor number from Aiptek, not Mars. 
So that much is consistent. Anyway, there are lots of dual-mode mr97310 
cameras. Cf. libgphoto2/camlibs/mars.

>
>> What I found:
>> 
>> After shooting a raw frame, I get
>> 
>> FF FF 00 FF 96 64 D0 01 27 00 06 2D
>
> There is the same Frame Header for the PAC207 and PAC7311 (FF FF 00 FF 96 
> ..... 12 Bytes in total as I remember).

Yes, what you quote is the SOF marker for all of these cameras. The total 
header length, including the SOF marker ought to be 12 bytes. On all of 
the mr97310 cameras that I have dealt with, the last 5 bytes are obviously 
related somehow to the image (contrast, color balance, gamma, whatever). I 
have no idea how to interpret those values, but we can hope that someone 
will figure out how. Thus, it is not a good idea to throw them away as the 
driver is currently doing. If they have to be tossed, then toss them over 
in libv4lconvert, I would say, instead of shaving them off in the driver. 
It makes for much simpler driver code when one does not try to work around 
them, too.

> PAC207 does a line based compression and PAC7311 is jpeg based with a marker 
> in front of each MCU. Both decompression are supported by libv4l :-)

The marker for compression/no compression and for what kind of 
compression if there is any is the next one that you do not quote here. 
What i know from previous experience is

FF FF 00 FF 96 64 00 	uncompressed
FF FF 00 FF 96 64 50	"standard compression" supported here and 
in libgphoto2/camlibs/mars. Supports all cameras in stillcam mode except 
for the next one listed
FF FF 00 FF 96 64 20	another compression, used by one stillcam, not 
resolved
FF FF 00 FF 96 64 D0	new compression algorithm used by all the 
0x093a:0x010e cameras that I own (several of them), when running in 
streaming mode.

What else I know about this, or think I know:

Both the 0x20 format and the 0xD0 format are probably variants of the 
differential Huffman encoding scheme which is the 0x50. One can see 
sometimes a little bit of the picture, which is recognizable. But the 
pattern is screwed up. For example, today I have been experimenting a bit 
with the new one. I am pretty sure it starts from a different row, like 
row 2 or so, instead of from row 0 as does the 0x50 algorithm. I have been 
surprised before, but I will be very surprised indeed if the algorithm 
signified by 0xD0 turns out to be one of the two you mention just now.


>
> The PAC207 can be configured to run in raw mode or compressed mode. The same 
> should be possible to do with the PAC7311, but I could not find the right 
> register to set this :-(
>
> Don't know if this info helps you? (or you already know)

No, I know nothing about how to do that. Heretofore, I have dealt with 
these cameras as still cameras.

Incidentally, I did have something to do with solving the the 0x50 
decompression. Bertrik Sikkens figured out the basics. It is a 
differential Huffman encoding, as I said. One computes a "predictor" for 
the next pixel to be decompressed by taking a weighted average of some 
previously decompressed pixel data. Then one applies a "corrector" which 
is the next piece of decoded data. Bertrik figured out the Huffman scheme, 
as I said. What I did was to figure out the right pixels to average for 
the predictor part and what weights they get assigned in the weighted 
average.

But it seems that you know something about this kind of thing and probably 
have the right tools or clues to be able to handle them. I have a couple 
of other unsolved formats lying around, too. You might be the person I 
have been trying to meet. Interested?

Theodore Kilgore

Re: MR97310A and other image formats

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
> Yes, what you quote is the SOF marker for all of these cameras. The 
> total header length, including the SOF marker ought to be 12 bytes. On 
> all of the mr97310 cameras that I have dealt with, the last 5 bytes are 
> obviously related somehow to the image (contrast, color balance, gamma, 
> whatever).  I have no idea how to interpret those values, but we can hope
> that someone will figure out how.

Two of them are luminance values (middle and edge) for the PAC207.

> Thus, it is not a good idea to throw 
> them away as the driver is currently doing. If they have to be tossed, 
> then toss them over in libv4lconvert, I would say, instead of shaving 
> them off in the driver. It makes for much simpler driver code when one 
> does not try to work around them, too.

Yes, there are always some additional Bytes in the SOF header for a good 
reason.

> FF FF 00 FF 96 64 00     uncompressed
> FF FF 00 FF 96 64 50    "standard compression" supported here and in 
> libgphoto2/camlibs/mars. Supports all cameras in stillcam mode except 
> for the next one listed
> FF FF 00 FF 96 64 20    another compression, used by one stillcam, not 
> resolved
> FF FF 00 FF 96 64 D0    new compression algorithm used by all the 
> 0x093a:0x010e cameras that I own (several of them), when running in 
> streaming mode.

So, you found the meaning of an other Byte in the SOF header. I have to 
check whats in there for the PAC207 and PAC7311.

> Incidentally, I did have something to do with solving the the 0x50 
> decompression. Bertrik Sikkens figured out the basics. It is a 
> differential Huffman encoding, as I said. One computes a "predictor" for 
> the next pixel to be decompressed by taking a weighted average of some 
> previously decompressed pixel data. Then one applies a "corrector" which 
> is the next piece of decoded data. Bertrik figured out the Huffman 
> scheme, as I said. What I did was to figure out the right pixels to 
> average for the predictor part and what weights they get assigned in the 
> weighted average.

That is a similar compression like on the PAC207 the first 2 pixels of 
the line have the real value and for the other pixels, only the diff to 
these two pixels are stored in Huffman codes.
Now you can guess who found out how to decompress -> Bertrik Sikkens

> 
> But it seems that you know something about this kind of thing and 
> probably have the right tools or clues to be able to handle them. I have 
> a couple of other unsolved formats lying around, too. You might be the 
> person I have been trying to meet. Interested?

Always interested, but my free time is very limited :-(

It looks like I have 22 webcams on my desk and 3 or 4 of them are _not_ 
working in Linux. Thus, I have a lot of homework to do.....

Thomas

Re: MR97310A and other image formats

[kilgota]

On Thu, 19 Feb 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>> Yes, what you quote is the SOF marker for all of these cameras. The total 
>> header length, including the SOF marker ought to be 12 bytes. On all of the 
>> mr97310 cameras that I have dealt with, the last 5 bytes are obviously 
>> related somehow to the image (contrast, color balance, gamma, whatever).  I 
>> have no idea how to interpret those values, but we can hope
>> that someone will figure out how.
>
> Two of them are luminance values (middle and edge) for the PAC207.

Which two, and how do those numbers translate into anything relevant?

>
>> Thus, it is not a good idea to throw them away as the driver is currently 
>> doing. If they have to be tossed, then toss them over in libv4lconvert, I 
>> would say, instead of shaving them off in the driver. It makes for much 
>> simpler driver code when one does not try to work around them, too.
>
> Yes, there are always some additional Bytes in the SOF header for a good 
> reason.
>
>> FF FF 00 FF 96 64 00     uncompressed
>> FF FF 00 FF 96 64 50    "standard compression" supported here and in 
>> libgphoto2/camlibs/mars. Supports all cameras in stillcam mode except for 
>> the next one listed
>> FF FF 00 FF 96 64 20    another compression, used by one stillcam, not 
>> resolved
>> FF FF 00 FF 96 64 D0    new compression algorithm used by all the 
>> 0x093a:0x010e cameras that I own (several of them), when running in 
>> streaming mode.
>
> So, you found the meaning of an other Byte in the SOF header. I have to check 
> whats in there for the PAC207 and PAC7311.

That information would be good to know. As far as what I already knew is 
concerned, the latest revision of libgphoto2/camlibs/mars/README.mars is 
stated at the top of the file. I have known this for quite a while before 
that, actually. That date is the date, more or less, that the 
decompression algorithm was finally made to work right.

>
>> Incidentally, I did have something to do with solving the the 0x50 
>> decompression. Bertrik Sikkens figured out the basics. It is a differential 
>> Huffman encoding, as I said. One computes a "predictor" for the next pixel 
>> to be decompressed by taking a weighted average of some previously 
>> decompressed pixel data. Then one applies a "corrector" which is the next 
>> piece of decoded data. Bertrik figured out the Huffman scheme, as I said. 
>> What I did was to figure out the right pixels to average for the predictor 
>> part and what weights they get assigned in the weighted average.
>
> That is a similar compression like on the PAC207 the first 2 pixels of the 
> line have the real value and for the other pixels, only the diff to these two 
> pixels are stored in Huffman codes.

Yes. Except that for the 0x50 compression the diff is not to the pixels to 
the left only. The pixel to the left and the nearest three above are the 
ones in use there to compute the predictor. Four neighbor pixels in all 
are used, and they do not all get the same weight in the average. If one 
does not use all four and if one does not use the correct weighting, then 
one can see that decompression is working, more or less, but the result is 
full of nasty artifacts and diagonal color striping and therefore is 
useless.

> Now you can guess who found out how to decompress -> Bertrik Sikkens

What I said. He has done a lot for us.

>
>> 
>> But it seems that you know something about this kind of thing and probably 
>> have the right tools or clues to be able to handle them. I have a couple of 
>> other unsolved formats lying around, too. You might be the person I have 
>> been trying to meet. Interested?
>
> Always interested, but my free time is very limited :-(
>
> It looks like I have 22 webcams on my desk and 3 or 4 of them are _not_ 
> working in Linux.

You remind me of myself. But mine are typically dual-mode, and I was first 
of all looking at them as stillcams. With one or two exceptions, that is 
done, now.

> Thus, I have a lot of homework to do.....

By any chance, you do not have a JL2005B or JL2005C or JL2005D camera 
among them, do you? AFAICT they all use the same compression algorithm (in 
stillcam mode), and it appears to me to be a really nasty one. Any help I 
could get with that algorithm is welcome indeed.

Theodore Kilgore

Re: MR97310A and other image formats

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
> 
>> kilgota@banach.math.auburn.edu wrote:
>>> Yes, what you quote is the SOF marker for all of these cameras. The 
>>> total header length, including the SOF marker ought to be 12 bytes. 
>>> On all of the mr97310 cameras that I have dealt with, the last 5 
>>> bytes are obviously related somehow to the image (contrast, color 
>>> balance, gamma, whatever).  I have no idea how to interpret those 
>>> values, but we can hope
>>> that someone will figure out how.
>>
>> Two of them are luminance values (middle and edge) for the PAC207.
> 
> Which two, and how do those numbers translate into anything relevant?

Looks like I had some off list (private) email conversation about the 
frame header of PAC207 with Michel Xhaard. I just paste the whole thing 
in here:

michel Xhaard wrote:
 > Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
 >
 >> michel Xhaard wrote:
 >>
 >>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
 >>>
 >>>> Hello Michel
 >>>>
 >>>> michel Xhaard wrote:
 >>>>
 >>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
 >>>>> Just relook the snoop, the header is always 16 bytes long 
starting with:
 >>>>> ff ff 00 ff 96 64 follow
 >>>>> xx 00 xx xx xx xx  64 xx 00 00
 >>>>> let try to play poker with the asumption the R mean G0 mean B mean G1
 >>>>> mean is encoded here.
 >>>>> Not sure about the 64 can you look at your snoop?
 >>>>
 >>>> I never thought about that. So, you see I have not experience with
 >>>> webcams.
 >>>>
 >>>> Anyway, here are my observations about the header:
 >>>> In the snoop, it looks a bit different then yours
 >>>>
 >>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
 >>>> 1. xx: looks like random value
 >>>> 2. xx: changed from 0x03 to 0x0b
 >>>> 3. xx: changed from 0x06 to 0x49
 >>>> 4. xx: changed from 0x07 to 0x55
 >>>> 5. xx: static 0x96
 >>>> 6. xx: static 0x80
 >>>> 7. xx: static 0xa0
 >>>>
 >>>> And I did play in Linux and could identify some fields :-) .
 >>>> In Linux the header looks like this:
 >>>>
 >>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
 >>>> 1. xx: don't know but value is changing between 0x00 to 0x07
 >>>> 2. xx: this is the actual pixel clock
 >>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
 >>>> 0xfc (bright)
 >>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
 >>>> 0xfc (bright)
 >>>> 5. xx: set value "Digital Gain of Red"
 >>>> 6. xx: set value "Digital Gain of Green"
 >>>> 7. xx: set value "Digital Gain of Blue"
 >>>>
 >>>> Regards, Thomas
 >>>
 >>> Thomas,
 >>> Cool good works :) so 3 and 4 are good candidate . To get good picture
 >>> result there are 2 windows where the chips measure the ligth condition.
 >>> Generally one is set to the center of the image the other are set 
to get
 >>> the background light. At the moment my autobrightness setting used 
simple
 >>> code and only one windows of measurement (the center one) .
 >>
 >> Some more info, 3 is the center one.
 >
 > :)
 >
 >>> Did you want i try to implement these feature ? or maybe you can have a
 >>> try :) the only problem i see is between interrupt() context and 
process
 >>> context. I have set up a spinlock for that look at the code how to 
use it
 >>> ( spca5xx_move_data() )
 >>
 >> Yes, please. Because I have no idea how to do this :-(
 >> I am good in investigating :-)
 >
 > I know, but can be very good in code to, as you know the hardware :) 
now let try to look at 1
                          ^^ What does this mean?
 > is there the black luma level ?
I don't get it. What is the black luma level?

Regards, Thomas


-- 
http://www.kaiser-linux.li


> By any chance, you do not have a JL2005B or JL2005C or JL2005D camera 
> among them, do you? AFAICT they all use the same compression algorithm 
> (in stillcam mode), and it appears to me to be a really nasty one. Any 
> help I could get with that algorithm is welcome indeed.

I have to check. Please send me the USB ID.

Thomas

PS: Now we have the 5. season in Liechtenstein, Fasnacht (means 
carnival). So, you can guess what I am doing the next couple of days :-)

Re: MR97310A and other image formats

[kilgota]

On Fri, 20 Feb 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>> 
>>> kilgota@banach.math.auburn.edu wrote:
>>>> Yes, what you quote is the SOF marker for all of these cameras. The total 
>>>> header length, including the SOF marker ought to be 12 bytes. On all of 
>>>> the mr97310 cameras that I have dealt with, the last 5 bytes are 
>>>> obviously related somehow to the image (contrast, color balance, gamma, 
>>>> whatever).  I have no idea how to interpret those values, but we can hope
>>>> that someone will figure out how.
>>> 
>>> Two of them are luminance values (middle and edge) for the PAC207.
>> 
>> Which two, and how do those numbers translate into anything relevant?
>
> Looks like I had some off list (private) email conversation about the frame 
> header of PAC207 with Michel Xhaard. I just paste the whole thing in here:
>
> michel Xhaard wrote:
>> Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
>>
>>> michel Xhaard wrote:
>>>
>>>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
>>>>
>>>>> Hello Michel
>>>>>
>>>>> michel Xhaard wrote:
>>>>>
>>>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
>>>>>> Just relook the snoop, the header is always 16 bytes long starting 
> with:
>>>>>> ff ff 00 ff 96 64 follow
>>>>>> xx 00 xx xx xx xx  64 xx 00 00
>>>>>> let try to play poker with the asumption the R mean G0 mean B mean G1
>>>>>> mean is encoded here.
>>>>>> Not sure about the 64 can you look at your snoop?
>>>>>
>>>>> I never thought about that. So, you see I have not experience with
>>>>> webcams.
>>>>>
>>>>> Anyway, here are my observations about the header:
>>>>> In the snoop, it looks a bit different then yours
>>>>>
>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>>> 1. xx: looks like random value
>>>>> 2. xx: changed from 0x03 to 0x0b
>>>>> 3. xx: changed from 0x06 to 0x49
>>>>> 4. xx: changed from 0x07 to 0x55
>>>>> 5. xx: static 0x96
>>>>> 6. xx: static 0x80
>>>>> 7. xx: static 0xa0
>>>>>
>>>>> And I did play in Linux and could identify some fields :-) .
>>>>> In Linux the header looks like this:
>>>>>
>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>>> 2. xx: this is the actual pixel clock
>>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>>> 0xfc (bright)
>>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>>> 0xfc (bright)
>>>>> 5. xx: set value "Digital Gain of Red"
>>>>> 6. xx: set value "Digital Gain of Green"
>>>>> 7. xx: set value "Digital Gain of Blue"
>>>>>
>>>>> Regards, Thomas
>>>>
>>>> Thomas,
>>>> Cool good works :) so 3 and 4 are good candidate . To get good picture
>>>> result there are 2 windows where the chips measure the ligth condition.
>>>> Generally one is set to the center of the image the other are set to get
>>>> the background light. At the moment my autobrightness setting used simple
>>>> code and only one windows of measurement (the center one) .
>>>
>>> Some more info, 3 is the center one.
>>
>> :)
>>
>>>> Did you want i try to implement these feature ? or maybe you can have a
>>>> try :) the only problem i see is between interrupt() context and process
>>>> context. I have set up a spinlock for that look at the code how to use it
>>>> ( spca5xx_move_data() )
>>>
>>> Yes, please. Because I have no idea how to do this :-(
>>> I am good in investigating :-)
>>
>> I know, but can be very good in code to, as you know the hardware :) now 
> let try to look at 1
>                         ^^ What does this mean?
>> is there the black luma level ?
> I don't get it. What is the black luma level?
>
> Regards, Thomas
>
>
> -- 
> http://www.kaiser-linux.li
>
>
>> By any chance, you do not have a JL2005B or JL2005C or JL2005D camera among 
>> them, do you? AFAICT they all use the same compression algorithm (in 
>> stillcam mode), and it appears to me to be a really nasty one. Any help I 
>> could get with that algorithm is welcome indeed.
>
> I have to check. Please send me the USB ID.

 	0x0979 is the Vendor ID from Jeilin.
 	0x0227 is the Product ID of the JL2005B/C/D cameras
 	(yes, all three of them have the same ID)
>
> Thomas

Thanks for the information. But this is an old letter. What is happening 
with Michel Xhaard these days? Do you know? I miss him.

>
> PS: Now we have the 5. season in Liechtenstein, Fasnacht (means carnival). 
> So, you can guess what I am doing the next couple of days :-)
>

I don't know. Eat too much Wienerschnitzel? Temporarily transform into 
"ein Bierfass"? Um Verzeihung. Ich hole sofort den Hut...

Theodore Kilgore

Re: MR97310A and other image formats

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
> 
>> kilgota@banach.math.auburn.edu wrote:
>>>
>>>
>>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>>>
>>>> kilgota@banach.math.auburn.edu wrote:
>>>>> Yes, what you quote is the SOF marker for all of these cameras. The 
>>>>> total header length, including the SOF marker ought to be 12 bytes. 
>>>>> On all of the mr97310 cameras that I have dealt with, the last 5 
>>>>> bytes are obviously related somehow to the image (contrast, color 
>>>>> balance, gamma, whatever).  I have no idea how to interpret those 
>>>>> values, but we can hope
>>>>> that someone will figure out how.
>>>>
>>>> Two of them are luminance values (middle and edge) for the PAC207.
>>>
>>> Which two, and how do those numbers translate into anything relevant?
>>
>> Looks like I had some off list (private) email conversation about the 
>> frame header of PAC207 with Michel Xhaard. I just paste the whole 
>> thing in here:
>>
>> michel Xhaard wrote:
>>> Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
>>>
>>>> michel Xhaard wrote:
>>>>
>>>>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
>>>>>
>>>>>> Hello Michel
>>>>>>
>>>>>> michel Xhaard wrote:
>>>>>>
>>>>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
>>>>>>> Just relook the snoop, the header is always 16 bytes long starting 
>> with:
>>>>>>> ff ff 00 ff 96 64 follow
>>>>>>> xx 00 xx xx xx xx  64 xx 00 00
>>>>>>> let try to play poker with the asumption the R mean G0 mean B 
>>>>>>> mean G1
>>>>>>> mean is encoded here.
>>>>>>> Not sure about the 64 can you look at your snoop?
>>>>>>
>>>>>> I never thought about that. So, you see I have not experience with
>>>>>> webcams.
>>>>>>
>>>>>> Anyway, here are my observations about the header:
>>>>>> In the snoop, it looks a bit different then yours
>>>>>>
>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>>>> 1. xx: looks like random value
>>>>>> 2. xx: changed from 0x03 to 0x0b
>>>>>> 3. xx: changed from 0x06 to 0x49
>>>>>> 4. xx: changed from 0x07 to 0x55
>>>>>> 5. xx: static 0x96
>>>>>> 6. xx: static 0x80
>>>>>> 7. xx: static 0xa0
>>>>>>
>>>>>> And I did play in Linux and could identify some fields :-) .
>>>>>> In Linux the header looks like this:
>>>>>>
>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>>>> 2. xx: this is the actual pixel clock
>>>>>> 3. xx: this is changing according light conditions from 0x03 
>>>>>> (dark) to
>>>>>> 0xfc (bright)
>>>>>> 4. xx: this is changing according light conditions from 0x03 
>>>>>> (dark) to
>>>>>> 0xfc (bright)
>>>>>> 5. xx: set value "Digital Gain of Red"
>>>>>> 6. xx: set value "Digital Gain of Green"
>>>>>> 7. xx: set value "Digital Gain of Blue"
>>>>>>
>>>>>> Regards, Thomas
>>>>>
>>>>> Thomas,
>>>>> Cool good works :) so 3 and 4 are good candidate . To get good picture
>>>>> result there are 2 windows where the chips measure the ligth 
>>>>> condition.
>>>>> Generally one is set to the center of the image the other are set 
>>>>> to get
>>>>> the background light. At the moment my autobrightness setting used 
>>>>> simple
>>>>> code and only one windows of measurement (the center one) .
>>>>
>>>> Some more info, 3 is the center one.
>>>
>>> :)
>>>
>>>>> Did you want i try to implement these feature ? or maybe you can 
>>>>> have a
>>>>> try :) the only problem i see is between interrupt() context and 
>>>>> process
>>>>> context. I have set up a spinlock for that look at the code how to 
>>>>> use it
>>>>> ( spca5xx_move_data() )
>>>>
>>>> Yes, please. Because I have no idea how to do this :-(
>>>> I am good in investigating :-)
>>>
>>> I know, but can be very good in code to, as you know the hardware :) now 
>> let try to look at 1
>>                         ^^ What does this mean?
>>> is there the black luma level ?
>> I don't get it. What is the black luma level?
>>
>> Regards, Thomas
>>
>>
>> -- 
>> http://www.kaiser-linux.li
>>
>>
>>> By any chance, you do not have a JL2005B or JL2005C or JL2005D camera 
>>> among them, do you? AFAICT they all use the same compression 
>>> algorithm (in stillcam mode), and it appears to me to be a really 
>>> nasty one. Any help I could get with that algorithm is welcome indeed.
>>
>> I have to check. Please send me the USB ID.
> 
>     0x0979 is the Vendor ID from Jeilin.
>     0x0227 is the Product ID of the JL2005B/C/D cameras
>     (yes, all three of them have the same ID)
>>
>> Thomas
> 
> Thanks for the information. But this is an old letter. What is happening 
> with Michel Xhaard these days? Do you know? I miss him.

Yes, I know it is an old letter, but these info are still valid for the 
PAC207 chipset!

I don't know what happened to Michel. I didn't exchange mails with him 
for a long time.

> 
>>
>> PS: Now we have the 5. season in Liechtenstein, Fasnacht (means 
>> carnival). So, you can guess what I am doing the next couple of days :-)
>>
> 
> I don't know. Eat too much Wienerschnitzel? Temporarily transform into 
> "ein Bierfass"? Um Verzeihung. Ich hole sofort den Hut...

... party .....


Thomas

Re: MR97310A and other image formats

[kilgota]

On Fri, 20 Feb 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
>> 
>>> kilgota@banach.math.auburn.edu wrote:
>>>> 
>>>> 
>>>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>>>> 
>>>>> kilgota@banach.math.auburn.edu wrote:
>>>>>> Yes, what you quote is the SOF marker for all of these cameras. The 
>>>>>> total header length, including the SOF marker ought to be 12 bytes. On 
>>>>>> all of the mr97310 cameras that I have dealt with, the last 5 bytes are 
>>>>>> obviously related somehow to the image (contrast, color balance, gamma, 
>>>>>> whatever).  I have no idea how to interpret those values, but we can 
>>>>>> hope
>>>>>> that someone will figure out how.
>>>>> 
>>>>> Two of them are luminance values (middle and edge) for the PAC207.
>>>> 
>>>> Which two, and how do those numbers translate into anything relevant?
>>> 
>>> Looks like I had some off list (private) email conversation about the 
>>> frame header of PAC207 with Michel Xhaard. I just paste the whole thing in 
>>> here:
>>> 
>>> michel Xhaard wrote:
>>>> Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
>>>> 
>>>>> michel Xhaard wrote:
>>>>> 
>>>>>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
>>>>>> 
>>>>>>> Hello Michel
>>>>>>> 
>>>>>>> michel Xhaard wrote:
>>>>>>> 
>>>>>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
>>>>>>>> Just relook the snoop, the header is always 16 bytes long starting 
>>> with:
>>>>>>>> ff ff 00 ff 96 64 follow
>>>>>>>> xx 00 xx xx xx xx  64 xx 00 00
>>>>>>>> let try to play poker with the asumption the R mean G0 mean B mean G1
>>>>>>>> mean is encoded here.
>>>>>>>> Not sure about the 64 can you look at your snoop?
>>>>>>> 
>>>>>>> I never thought about that. So, you see I have not experience with
>>>>>>> webcams.
>>>>>>> 
>>>>>>> Anyway, here are my observations about the header:
>>>>>>> In the snoop, it looks a bit different then yours
>>>>>>> 
>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>>>>> 1. xx: looks like random value
>>>>>>> 2. xx: changed from 0x03 to 0x0b
>>>>>>> 3. xx: changed from 0x06 to 0x49
>>>>>>> 4. xx: changed from 0x07 to 0x55
>>>>>>> 5. xx: static 0x96
>>>>>>> 6. xx: static 0x80
>>>>>>> 7. xx: static 0xa0
>>>>>>> 
>>>>>>> And I did play in Linux and could identify some fields :-) .
>>>>>>> In Linux the header looks like this:
>>>>>>> 
>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>>>>> 2. xx: this is the actual pixel clock
>>>>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>>>>> 0xfc (bright)
>>>>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>>>>> 0xfc (bright)
>>>>>>> 5. xx: set value "Digital Gain of Red"
>>>>>>> 6. xx: set value "Digital Gain of Green"
>>>>>>> 7. xx: set value "Digital Gain of Blue"
>>>>>>> 
>>>>>>> Regards, Thomas
>>>>>> 
>>>>>> Thomas,
>>>>>> Cool good works :) so 3 and 4 are good candidate . To get good picture
>>>>>> result there are 2 windows where the chips measure the ligth condition.
>>>>>> Generally one is set to the center of the image the other are set to 
>>>>>> get
>>>>>> the background light. At the moment my autobrightness setting used 
>>>>>> simple
>>>>>> code and only one windows of measurement (the center one) .
>>>>> 
>>>>> Some more info, 3 is the center one.
>>>> 
>>>> :)
>>>> 
>>>>>> Did you want i try to implement these feature ? or maybe you can have a
>>>>>> try :) the only problem i see is between interrupt() context and 
>>>>>> process
>>>>>> context. I have set up a spinlock for that look at the code how to use 
>>>>>> it
>>>>>> ( spca5xx_move_data() )
>>>>> 
>>>>> Yes, please. Because I have no idea how to do this :-(
>>>>> I am good in investigating :-)
>>>> 
>>>> I know, but can be very good in code to, as you know the hardware :) now 
>>> let try to look at 1
>>>                         ^^ What does this mean?
>>>> is there the black luma level ?
>>> I don't get it. What is the black luma level?
>>> 
>>> Regards, Thomas
>>> 
>>> 
>>> -- 
>>> http://www.kaiser-linux.li
>>> 
>>> 
>>>> By any chance, you do not have a JL2005B or JL2005C or JL2005D camera 
>>>> among them, do you? AFAICT they all use the same compression algorithm 
>>>> (in stillcam mode), and it appears to me to be a really nasty one. Any 
>>>> help I could get with that algorithm is welcome indeed.
>>> 
>>> I have to check. Please send me the USB ID.
>>
>>     0x0979 is the Vendor ID from Jeilin.
>>     0x0227 is the Product ID of the JL2005B/C/D cameras
>>     (yes, all three of them have the same ID)
>>> 
>>> Thomas
>> 
>> Thanks for the information. But this is an old letter. What is happening 
>> with Michel Xhaard these days? Do you know? I miss him.
>
> Yes, I know it is an old letter, but these info are still valid for the 
> PAC207 chipset!
>
> I don't know what happened to Michel. I didn't exchange mails with him for a 
> long time.

I believe you that the information is valid. The comment about the age of 
the letter related to the fact that I have not heard from Michel for 
approximately that long, myself. As to the information, though, what I 
would really like to see is a collection started which lists the known 
compression algorithms for the PAC family and, at least, their code bytes. 
So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and what else? 
For example, what is the next byte after the FF FF 00 FF 96 for the 
PAC207? That would probably be good to know, but if anyone has recorded 
that information I have missed it.

Theodore Kilgore

Re: MR97310A and other image formats

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
> 
>> kilgota@banach.math.auburn.edu wrote:
>>>
>>>
>>> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
>>>
>>>> kilgota@banach.math.auburn.edu wrote:
>>>>>
>>>>>
>>>>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>>>>>
>>>>>> kilgota@banach.math.auburn.edu wrote:
>>>>>>> Yes, what you quote is the SOF marker for all of these cameras. 
>>>>>>> The total header length, including the SOF marker ought to be 12 
>>>>>>> bytes. On all of the mr97310 cameras that I have dealt with, the 
>>>>>>> last 5 bytes are obviously related somehow to the image 
>>>>>>> (contrast, color balance, gamma, whatever).  I have no idea how 
>>>>>>> to interpret those values, but we can hope
>>>>>>> that someone will figure out how.
>>>>>>
>>>>>> Two of them are luminance values (middle and edge) for the PAC207.
>>>>>
>>>>> Which two, and how do those numbers translate into anything relevant?
>>>>
>>>> Looks like I had some off list (private) email conversation about 
>>>> the frame header of PAC207 with Michel Xhaard. I just paste the 
>>>> whole thing in here:
>>>>
>>>> michel Xhaard wrote:
>>>>> Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
>>>>>
>>>>>> michel Xhaard wrote:
>>>>>>
>>>>>>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
>>>>>>>
>>>>>>>> Hello Michel
>>>>>>>>
>>>>>>>> michel Xhaard wrote:
>>>>>>>>
>>>>>>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
>>>>>>>>> Just relook the snoop, the header is always 16 bytes long starting 
>>>> with:
>>>>>>>>> ff ff 00 ff 96 64 follow
>>>>>>>>> xx 00 xx xx xx xx  64 xx 00 00
>>>>>>>>> let try to play poker with the asumption the R mean G0 mean B 
>>>>>>>>> mean G1
>>>>>>>>> mean is encoded here.
>>>>>>>>> Not sure about the 64 can you look at your snoop?
>>>>>>>>
>>>>>>>> I never thought about that. So, you see I have not experience with
>>>>>>>> webcams.
>>>>>>>>
>>>>>>>> Anyway, here are my observations about the header:
>>>>>>>> In the snoop, it looks a bit different then yours
>>>>>>>>
>>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>>>>>> 1. xx: looks like random value
>>>>>>>> 2. xx: changed from 0x03 to 0x0b
>>>>>>>> 3. xx: changed from 0x06 to 0x49
>>>>>>>> 4. xx: changed from 0x07 to 0x55
>>>>>>>> 5. xx: static 0x96
>>>>>>>> 6. xx: static 0x80
>>>>>>>> 7. xx: static 0xa0
>>>>>>>>
>>>>>>>> And I did play in Linux and could identify some fields :-) .
>>>>>>>> In Linux the header looks like this:
>>>>>>>>
>>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>>>>>> 2. xx: this is the actual pixel clock
>>>>>>>> 3. xx: this is changing according light conditions from 0x03 
>>>>>>>> (dark) to
>>>>>>>> 0xfc (bright)
>>>>>>>> 4. xx: this is changing according light conditions from 0x03 
>>>>>>>> (dark) to
>>>>>>>> 0xfc (bright)
>>>>>>>> 5. xx: set value "Digital Gain of Red"
>>>>>>>> 6. xx: set value "Digital Gain of Green"
>>>>>>>> 7. xx: set value "Digital Gain of Blue"
>>>>>>>>
>>>>>>>> Regards, Thomas
>>>>>>>
>>>>>>> Thomas,
>>>>>>> Cool good works :) so 3 and 4 are good candidate . To get good 
>>>>>>> picture
>>>>>>> result there are 2 windows where the chips measure the ligth 
>>>>>>> condition.
>>>>>>> Generally one is set to the center of the image the other are set 
>>>>>>> to get
>>>>>>> the background light. At the moment my autobrightness setting 
>>>>>>> used simple
>>>>>>> code and only one windows of measurement (the center one) .
>>>>>>
>>>>>> Some more info, 3 is the center one.
>>>>>
>>>>> :)
>>>>>
>>>>>>> Did you want i try to implement these feature ? or maybe you can 
>>>>>>> have a
>>>>>>> try :) the only problem i see is between interrupt() context and 
>>>>>>> process
>>>>>>> context. I have set up a spinlock for that look at the code how 
>>>>>>> to use it
>>>>>>> ( spca5xx_move_data() )
>>>>>>
>>>>>> Yes, please. Because I have no idea how to do this :-(
>>>>>> I am good in investigating :-)
>>>>>
>>>>> I know, but can be very good in code to, as you know the hardware 
>>>>> :) now 
>>>> let try to look at 1
>>>>                         ^^ What does this mean?
>>>>> is there the black luma level ?
>>>> I don't get it. What is the black luma level?
>>>>
>>>> Regards, Thomas
>>>>
>>>>
>>>> -- 
>>>> http://www.kaiser-linux.li
>>>>
>>>>
>>>>> By any chance, you do not have a JL2005B or JL2005C or JL2005D 
>>>>> camera among them, do you? AFAICT they all use the same compression 
>>>>> algorithm (in stillcam mode), and it appears to me to be a really 
>>>>> nasty one. Any help I could get with that algorithm is welcome indeed.
>>>>
>>>> I have to check. Please send me the USB ID.
>>>
>>>     0x0979 is the Vendor ID from Jeilin.
>>>     0x0227 is the Product ID of the JL2005B/C/D cameras
>>>     (yes, all three of them have the same ID)
>>>>
>>>> Thomas
>>>
>>> Thanks for the information. But this is an old letter. What is 
>>> happening with Michel Xhaard these days? Do you know? I miss him.
>>
>> Yes, I know it is an old letter, but these info are still valid for 
>> the PAC207 chipset!
>>
>> I don't know what happened to Michel. I didn't exchange mails with him 
>> for a long time.
> 
> I believe you that the information is valid. The comment about the age 
> of the letter related to the fact that I have not heard from Michel for 
> approximately that long, myself. As to the information, though, what I 
> would really like to see is a collection started which lists the known 
> compression algorithms for the PAC family and, at least, their code 
> bytes. So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and 
> what else? For example, what is the next byte after the FF FF 00 FF 96 
> for the PAC207? That would probably be good to know, but if anyone has 
> recorded that information I have missed it.
> 
> Theodore Kilgore

Hello Theodore

At this time I wrote this letter, I had a lot of email conversation with 
  Michel. I got a cam with PAC207 chip and he got an other some weeks 
later. Together, we could implement the PAC207 into spca5xx -> gspca.

For the next byte after FF FF 00 FF 96:
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
1. xx: don't know but value is changing between 0x00 to 0x07

As far as I can remember (at the time I did this), the cam did 
compresses sometimes and sometimes not during streaming.

So, I guess 0x07 means a compressed PAC207 frame!?

Actually, I got some frames where some lines were compressed and the 
rest was raw. The line marker tells you if the line is compressed or 
not. So, it doesn't make a lot of sense to send this information in the 
frame header. But may be 0x07 means "you can get compressed lines"?

Thomas

Re: MR97310A and other image formats

[kilgota]

On Fri, 20 Feb 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
>> 
>>> kilgota@banach.math.auburn.edu wrote:
>>>> 
>>>> 
>>>> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
>>>> 
>>>>> kilgota@banach.math.auburn.edu wrote:
>>>>>> 
>>>>>> 
>>>>>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>>>>>> 
>>>>>>> kilgota@banach.math.auburn.edu wrote:
>>>>>>>> Yes, what you quote is the SOF marker for all of these cameras. The 
>>>>>>>> total header length, including the SOF marker ought to be 12 bytes. 
>>>>>>>> On all of the mr97310 cameras that I have dealt with, the last 5 
>>>>>>>> bytes are obviously related somehow to the image (contrast, color 
>>>>>>>> balance, gamma, whatever).  I have no idea how to interpret those 
>>>>>>>> values, but we can hope
>>>>>>>> that someone will figure out how.
>>>>>>> 
>>>>>>> Two of them are luminance values (middle and edge) for the PAC207.
>>>>>> 
>>>>>> Which two, and how do those numbers translate into anything relevant?
>>>>> 
>>>>> Looks like I had some off list (private) email conversation about the 
>>>>> frame header of PAC207 with Michel Xhaard. I just paste the whole thing 
>>>>> in here:
>>>>> 
>>>>> michel Xhaard wrote:
>>>>>> Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
>>>>>> 
>>>>>>> michel Xhaard wrote:
>>>>>>> 
>>>>>>>> Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
>>>>>>>> 
>>>>>>>>> Hello Michel
>>>>>>>>> 
>>>>>>>>> michel Xhaard wrote:
>>>>>>>>> 
>>>>>>>>>> Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
>>>>>>>>>> Just relook the snoop, the header is always 16 bytes long starting 
>>>>> with:
>>>>>>>>>> ff ff 00 ff 96 64 follow
>>>>>>>>>> xx 00 xx xx xx xx  64 xx 00 00
>>>>>>>>>> let try to play poker with the asumption the R mean G0 mean B mean 
>>>>>>>>>> G1
>>>>>>>>>> mean is encoded here.
>>>>>>>>>> Not sure about the 64 can you look at your snoop?
>>>>>>>>> 
>>>>>>>>> I never thought about that. So, you see I have not experience with
>>>>>>>>> webcams.
>>>>>>>>> 
>>>>>>>>> Anyway, here are my observations about the header:
>>>>>>>>> In the snoop, it looks a bit different then yours
>>>>>>>>> 
>>>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>>>>>>> 1. xx: looks like random value
>>>>>>>>> 2. xx: changed from 0x03 to 0x0b
>>>>>>>>> 3. xx: changed from 0x06 to 0x49
>>>>>>>>> 4. xx: changed from 0x07 to 0x55
>>>>>>>>> 5. xx: static 0x96
>>>>>>>>> 6. xx: static 0x80
>>>>>>>>> 7. xx: static 0xa0
>>>>>>>>> 
>>>>>>>>> And I did play in Linux and could identify some fields :-) .
>>>>>>>>> In Linux the header looks like this:
>>>>>>>>> 
>>>>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>>>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>>>>>>> 2. xx: this is the actual pixel clock
>>>>>>>>> 3. xx: this is changing according light conditions from 0x03 (dark) 
>>>>>>>>> to
>>>>>>>>> 0xfc (bright)
>>>>>>>>> 4. xx: this is changing according light conditions from 0x03 (dark) 
>>>>>>>>> to
>>>>>>>>> 0xfc (bright)
>>>>>>>>> 5. xx: set value "Digital Gain of Red"
>>>>>>>>> 6. xx: set value "Digital Gain of Green"
>>>>>>>>> 7. xx: set value "Digital Gain of Blue"
>>>>>>>>> 
>>>>>>>>> Regards, Thomas
>>>>>>>> 
>>>>>>>> Thomas,
>>>>>>>> Cool good works :) so 3 and 4 are good candidate . To get good 
>>>>>>>> picture
>>>>>>>> result there are 2 windows where the chips measure the ligth 
>>>>>>>> condition.
>>>>>>>> Generally one is set to the center of the image the other are set to 
>>>>>>>> get
>>>>>>>> the background light. At the moment my autobrightness setting used 
>>>>>>>> simple
>>>>>>>> code and only one windows of measurement (the center one) .
>>>>>>> 
>>>>>>> Some more info, 3 is the center one.
>>>>>> 
>>>>>> :)
>>>>>> 
>>>>>>>> Did you want i try to implement these feature ? or maybe you can have 
>>>>>>>> a
>>>>>>>> try :) the only problem i see is between interrupt() context and 
>>>>>>>> process
>>>>>>>> context. I have set up a spinlock for that look at the code how to 
>>>>>>>> use it
>>>>>>>> ( spca5xx_move_data() )
>>>>>>> 
>>>>>>> Yes, please. Because I have no idea how to do this :-(
>>>>>>> I am good in investigating :-)
>>>>>> 
>>>>>> I know, but can be very good in code to, as you know the hardware :) 
>>>>>> now 
>>>>> let try to look at 1
>>>>>                         ^^ What does this mean?
>>>>>> is there the black luma level ?
>>>>> I don't get it. What is the black luma level?
>>>>> 
>>>>> Regards, Thomas
>>>>> 
>>>>> 
>>>>> -- 
>>>>> http://www.kaiser-linux.li
>>>>> 
>>>>> 
>>>>>> By any chance, you do not have a JL2005B or JL2005C or JL2005D camera 
>>>>>> among them, do you? AFAICT they all use the same compression algorithm 
>>>>>> (in stillcam mode), and it appears to me to be a really nasty one. Any 
>>>>>> help I could get with that algorithm is welcome indeed.
>>>>> 
>>>>> I have to check. Please send me the USB ID.
>>>>
>>>>     0x0979 is the Vendor ID from Jeilin.
>>>>     0x0227 is the Product ID of the JL2005B/C/D cameras
>>>>     (yes, all three of them have the same ID)
>>>>> 
>>>>> Thomas
>>>> 
>>>> Thanks for the information. But this is an old letter. What is happening 
>>>> with Michel Xhaard these days? Do you know? I miss him.
>>> 
>>> Yes, I know it is an old letter, but these info are still valid for the 
>>> PAC207 chipset!
>>> 
>>> I don't know what happened to Michel. I didn't exchange mails with him for 
>>> a long time.
>> 
>> I believe you that the information is valid. The comment about the age of 
>> the letter related to the fact that I have not heard from Michel for 
>> approximately that long, myself. As to the information, though, what I 
>> would really like to see is a collection started which lists the known 
>> compression algorithms for the PAC family and, at least, their code bytes. 
>> So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and what else? 
>> For example, what is the next byte after the FF FF 00 FF 96 for the PAC207? 
>> That would probably be good to know, but if anyone has recorded that 
>> information I have missed it.
>> 
>> Theodore Kilgore
>
> Hello Theodore
>
> At this time I wrote this letter, I had a lot of email conversation with 
> Michel. I got a cam with PAC207 chip and he got an other some weeks later. 
> Together, we could implement the PAC207 into spca5xx -> gspca.
>
> For the next byte after FF FF 00 FF 96:
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> 1. xx: don't know but value is changing between 0x00 to 0x07
>
> As far as I can remember (at the time I did this), the cam did compresses 
> sometimes and sometimes not during streaming.
>
> So, I guess 0x07 means a compressed PAC207 frame!?
>
> Actually, I got some frames where some lines were compressed and the rest was 
> raw. The line marker tells you if the line is compressed or not. So, it 
> doesn't make a lot of sense to send this information in the frame header. But 
> may be 0x07 means "you can get compressed lines"?

That seems to me to be a very likely explanation. Perhaps also the 0x07 
indicates _what kind_ of compression will be in use for those compressed 
lines. I am guessing, of course, but my experience with the mr97310 still 
cameras indicates a 100% correlation between compression, or the lack 
thereof, and the value of that byte. Now, here I experience that a new 
compression format comes out of a camera when streaming, that I already 
knew everything about when it is a still camera. And again this byte 
changes to something new.

Do I recall something about one of the setup commands for Mars/PAC cameras 
in streaming mode is believed to have something to do with turning the 
compression mode on or off? Perhaps if that is the case, then it is 
possible to change that command such that it prescribes a different 
compression algorithm instead, perhaps the "0x50" algorithm?

Theodore Kilgore

RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

Hans, Jean-Francois, and Kyle,

The proposed patches are not very long, so I will give each of them, with 
my comments after each, to explain why I believe that these changes are a 
good idea.

First, the patch to libv4lconvert is short and sweet:

contents of file mr97310av4l.patch follow
----------------------------------------------
--- mr97310a.c.old	2009-03-01 15:37:38.000000000 -0600
+++ mr97310a.c.new	2009-02-18 22:39:48.000000000 -0600
@@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
  	if (!decoder_initialized)
  		init_mr97310a_decoder();

+	/* remove the header */
+	inp += 12;
+
  	bitpos = 0;

  	/* main decoding loop */

----------------- here ends the v4lconvert patch ------------------

The reason I want to do this should be obvious. It is to preserve the 
entire header of each frame over in the gspca driver, and to throw it away 
over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all 
of this should be kept is that it makes it possible to look at a raw 
output and to know if it is exactly aligned or not. Furthermore, the next 
byte after the 96 is a code for the compression algorithm used, and the 
bytes after that in the header might be useful in the future for better 
image processing. In other words, these headers contain information which 
might be useful in the future and they should not be jettisoned in the 
kernel module.

Now, the kernel module ought to keep and send along the header and SOF 
marker instead of throwing them away. This is the topic of the next patch. 
It also has the virtue of simplifying and shortening the code in the 
module at the same time, because one is not going through contortions to 
skip over and throw away some data which ought to be kept anyway.

contents of file mr97310a.patch follow, for gspca/mr97310a.c
--------------------------------------------------------
--- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
+++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
@@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
  					data, n);
  		sd->header_read = 0;
  		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
-		len -= sof - data;
-		data = sof;
-	}
-	if (sd->header_read < 7) {
-		int needed;
-
-		/* skip the rest of the header */
-		needed = 7 - sd->header_read;
-		if (len <= needed) {
-			sd->header_read += len;
-			return;
-		}
-		data += needed;
-		len -= needed;
-		sd->header_read = 7;
+		/* keep the header, including sof marker, for coming frame */
+		len -= n;
+		data = sof - sizeof pac_sof_marker;;
  	}

  	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
@@ -337,6 +325,7 @@ static const struct sd_desc sd_desc = {
  /* -- module initialisation -- */
  static const __devinitdata struct usb_device_id device_table[] = {
  	{USB_DEVICE(0x08ca, 0x0111)},
+	{USB_DEVICE(0x093a, 0x010f)},
  	{}
  };
  MODULE_DEVICE_TABLE(usb, device_table);


------------ end of mr97310a.patch -------------------------

You will also notice that I have added a USB ID. As I have mentioned, I 
have four cameras with this ID. The story with them is that two of them 
will not work at all. The module will not initialize the camera. As far as 
the other two of them are concerned, the module and the accompanying 
change in libv4lconvert work very well. I have mentioned this previously, 
and I did not get any comment about what is good to do. So now I decided 
to submit the ID number in the patch.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
> Hans, Jean-Francois, and Kyle,
>
> The proposed patches are not very long, so I will give each of them, with
> my comments after each, to explain why I believe that these changes are a
> good idea.
>
> First, the patch to libv4lconvert is short and sweet:
>
> contents of file mr97310av4l.patch follow
> ----------------------------------------------
> --- mr97310a.c.old	2009-03-01 15:37:38.000000000 -0600
> +++ mr97310a.c.new	2009-02-18 22:39:48.000000000 -0600
> @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
>   	if (!decoder_initialized)
>   		init_mr97310a_decoder();
>
> +	/* remove the header */
> +	inp += 12;
> +
>   	bitpos = 0;
>
>   	/* main decoding loop */
>
> ----------------- here ends the v4lconvert patch ------------------
>
> The reason I want to do this should be obvious. It is to preserve the
> entire header of each frame over in the gspca driver, and to throw it away
> over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all
> of this should be kept is that it makes it possible to look at a raw
> output and to know if it is exactly aligned or not. Furthermore, the next
> byte after the 96 is a code for the compression algorithm used, and the
> bytes after that in the header might be useful in the future for better
> image processing. In other words, these headers contain information which
> might be useful in the future and they should not be jettisoned in the
> kernel module.
>

No complaints here.  I copied off of the pac207 driver, thinking that one 
compression format == one pixel format and that all mr97310a cameras use the 
same compression.  I was hesitant to say that the mr97310a pixel format can 
correspond to multiple compression formats, especially since I only have one 
such camera and I don't know if it's preferred to use multiple pixel formats 
for this reason.

>From what I understand, sending the frame header to userspace solves at least 
two problems (if indeed the compression is specified in the header):

* One frame may be compressed and the next frame isn't, or the next frame uses 
a different compression.

* Two cameras with the same vendor/product ID use different compression 
formats.  Distinguishing the two cameras in the kernel driver could be messy.

Just a random thought, but maybe the pac207 driver can benefit from such a 
change as well?

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Tue, 3 Mar 2009, Kyle Guinn wrote:

> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>> Hans, Jean-Francois, and Kyle,
>>
>> The proposed patches are not very long, so I will give each of them, with
>> my comments after each, to explain why I believe that these changes are a
>> good idea.
>>
>> First, the patch to libv4lconvert is short and sweet:
>>
>> contents of file mr97310av4l.patch follow
>> ----------------------------------------------
>> --- mr97310a.c.old	2009-03-01 15:37:38.000000000 -0600
>> +++ mr97310a.c.new	2009-02-18 22:39:48.000000000 -0600
>> @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
>>   	if (!decoder_initialized)
>>   		init_mr97310a_decoder();
>>
>> +	/* remove the header */
>> +	inp += 12;
>> +
>>   	bitpos = 0;
>>
>>   	/* main decoding loop */
>>
>> ----------------- here ends the v4lconvert patch ------------------
>>
>> The reason I want to do this should be obvious. It is to preserve the
>> entire header of each frame over in the gspca driver, and to throw it away
>> over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all
>> of this should be kept is that it makes it possible to look at a raw
>> output and to know if it is exactly aligned or not. Furthermore, the next
>> byte after the 96 is a code for the compression algorithm used, and the
>> bytes after that in the header might be useful in the future for better
>> image processing. In other words, these headers contain information which
>> might be useful in the future and they should not be jettisoned in the
>> kernel module.
>>
>
> No complaints here.  I copied off of the pac207 driver, thinking that one
> compression format == one pixel format and that all mr97310a cameras use the
> same compression.  I was hesitant to say that the mr97310a pixel format can
> correspond to multiple compression formats, especially since I only have one
> such camera and I don't know if it's preferred to use multiple pixel formats
> for this reason.

Well, it is a fact that different compression formats are used by some 
cameras. First, the two 0x093a:0x010f cameras which I have that do *not* 
work with this module actually do use different compression algorithms. 
The proof is that what will convert the raw files of one of them, will not 
work on the other. The only place this is visible is in the header of the 
raw file (see previous discussion about this on the list). Well, OK, these 
cameras do not work. But then there are the 0x093a:0x010e cameras. They 
work very nicely with all of your code, up to the point that they use a 
different compressed format for the raw output and the frames come out 
looking wrong. Again, the only place this is marked is there is an 
indicator byte for the compression algorithm, and it is in the header.

> From what I understand, sending the frame header to userspace solves at least
> two problems (if indeed the compression is specified in the header):

It is. Really.

> * One frame may be compressed and the next frame isn't, or the next 
> frame uses a different compression.

These are very unlikely scenarios for a webcam. They assuredly do occur 
with still cameras, true. At least, one finds that the still camera will 
support a compressed mode, and an uncompressed mode. And, yes, the 
different kinds can be all mixed together. For, the user can reset the 
compression setting before each picture is shot.

>
> * Two cameras with the same vendor/product ID use different compression
> formats.  Distinguishing the two cameras in the kernel driver could be messy.

Well, sending the header along takes care of that. Once it is known how to 
decompress them, all that one needs to do is to look at the telltale byte 
from the header, and one knows which algorithm to use. Simple, actually.

>
> Just a random thought, but maybe the pac207 driver can benefit from such a
> change as well?

Probably. It just isn't my business. I would really be curious what those 
bytes are that are in the pac207 header, too, for comparison purposes and 
because someone ought to make a record of these things. Thus, if it were 
left to me I would probably rewrite the pac_common.h file change all apps 
which use it, in accord with the changes there and in accord with what I 
proposed here. But those would be too many changes which involve too many 
people at once, and something can go wrong when one does that. So better 
just to change the one driver I am interested in, hoping that you would 
not mind, and because I have a couple of cameras that I could test it with 
and I can say it works well after the changes.

Why would I change pac_common.h? Well, the sof marker should not be 
tossed, either, IMHO, because it is after all an sof marker. It is very 
comforting to be able to look at a raw output and to know for certain that 
at least it starts out right because it begins with an sof marker. One 
knows then that things are going well. That after all is part of the 
reason an sof marker is put there in the first place. To know where the 
start of a frame is. So, why throw such a thing away as if it has no 
value? I used to throw away things like that in my gphoto2 drivers, too, 
but I learned a lesson. So I am trying to pass it on.

Also, after the byte indicator for the compression algorithm there are 
some more bytes, and these almost definitely contain information which 
could be valuable while doing image processing on the output. If they are 
already kept and passed out of the module over to libv4lconvert, then it 
would be very easy to do something with those bytes if it is ever figured 
out precisely what they mean. But if it is not done now it would have to 
be done then and would cause even more trouble.

If these little changes are not made, then anyone who is curious about 
things like this and about compression algorithms (me, for instance) is 
going to have to maintain two gspca trees. One for himself, and one for 
everyone else. I was getting tired of that, and getting tired of accidents 
that I blow away my mr97310.c file whenever I do an upgrade of gspca, if I 
do not look out, and things like that.

So, let's do it. That's my suggestion.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

kilgota@banach.math.auburn.edu wrote:
> Hans, Jean-Francois, and Kyle,
> 
> The proposed patches are not very long, so I will give each of them, 
> with my comments after each, to explain why I believe that these changes 
> are a good idea.
> 
> First, the patch to libv4lconvert is short and sweet:
> 
> contents of file mr97310av4l.patch follow
> ----------------------------------------------
> --- mr97310a.c.old    2009-03-01 15:37:38.000000000 -0600
> +++ mr97310a.c.new    2009-02-18 22:39:48.000000000 -0600
> @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
>      if (!decoder_initialized)
>          init_mr97310a_decoder();
> 
> +    /* remove the header */
> +    inp += 12;
> +
>      bitpos = 0;
> 
>      /* main decoding loop */
> 
> ----------------- here ends the v4lconvert patch ------------------
> 
> The reason I want to do this should be obvious. It is to preserve the 
> entire header of each frame over in the gspca driver, and to throw it 
> away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason 
> why all of this should be kept is that it makes it possible to look at a 
> raw output and to know if it is exactly aligned or not. Furthermore, the 
> next byte after the 96 is a code for the compression algorithm used, and 
> the bytes after that in the header might be useful in the future for 
> better image processing. In other words, these headers contain 
> information which might be useful in the future and they should not be 
> jettisoned in the kernel module.
> 

+1

> Now, the kernel module ought to keep and send along the header and SOF 
> marker instead of throwing them away. This is the topic of the next 
> patch. It also has the virtue of simplifying and shortening the code in 
> the module at the same time, because one is not going through 
> contortions to skip over and throw away some data which ought to be kept 
> anyway.
> 

+1

> contents of file mr97310a.patch follow, for gspca/mr97310a.c
> --------------------------------------------------------
> --- mr97310a.c.old    2009-02-23 23:59:07.000000000 -0600
> +++ mr97310a.c.new    2009-03-03 17:19:06.000000000 -0600
> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>                      data, n);
>          sd->header_read = 0;
>          gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
> -        len -= sof - data;
> -        data = sof;
> -    }
> -    if (sd->header_read < 7) {
> -        int needed;
> -
> -        /* skip the rest of the header */
> -        needed = 7 - sd->header_read;
> -        if (len <= needed) {
> -            sd->header_read += len;
> -            return;
> -        }
> -        data += needed;
> -        len -= needed;
> -        sd->header_read = 7;
> +        /* keep the header, including sof marker, for coming frame */
> +        len -= n;
> +        data = sof - sizeof pac_sof_marker;;
>      }
> 
>      gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
> @@ -337,6 +325,7 @@ static const struct sd_desc sd_desc = {
>  /* -- module initialisation -- */
>  static const __devinitdata struct usb_device_id device_table[] = {
>      {USB_DEVICE(0x08ca, 0x0111)},
> +    {USB_DEVICE(0x093a, 0x010f)},
>      {}
>  };
>  MODULE_DEVICE_TABLE(usb, device_table);
> 
> 
> ------------ end of mr97310a.patch -------------------------
> 
> You will also notice that I have added a USB ID. As I have mentioned, I 
> have four cameras with this ID. The story with them is that two of them 
> will not work at all. The module will not initialize the camera. As far 
> as the other two of them are concerned, the module and the accompanying 
> change in libv4lconvert work very well. I have mentioned this 
> previously, and I did not get any comment about what is good to do. So 
> now I decided to submit the ID number in the patch.
> 

Adding the USB-ID sounds like the right thing to do.

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

Kyle Guinn wrote:
> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:

<snip>

> Just a random thought, but maybe the pac207 driver can benefit from such a 
> change as well?

It could, but it is to late for that, the pac207 driver and corresponding libv4l
functionality has been out there for 2 kernel releases now, so we cannot change that.

Which also makes me wonder about the same change for the mr97310a, is that cam already
supported in a released kernel ?

If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid
we cannot make these changes. In that case if we ever need to header data we need to
define a new PIXFMT for mr97310a with the header data, and deprecate the old one.

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

Hello Theodore

kilgota@banach.math.auburn.edu wrote:
> Also, after the byte indicator for the compression algorithm there are 
> some more bytes, and these almost definitely contain information which 
> could be valuable while doing image processing on the output. If they 
> are already kept and passed out of the module over to libv4lconvert, 
> then it would be very easy to do something with those bytes if it is 
> ever figured out precisely what they mean. But if it is not done now it 
> would have to be done then and would cause even more trouble.

I sent it already in private mail to you. Here is the observation I made 
for the PAC207 SOF some years ago:

 From usb snoop.
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
1. xx: looks like random value
2. xx: changed from 0x03 to 0x0b
3. xx: changed from 0x06 to 0x49
4. xx: changed from 0x07 to 0x55
5. xx: static 0x96
6. xx: static 0x80
7. xx: static 0xa0

And I did play in Linux and could identify some fields :-) .
In Linux the header looks like this:

FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
1. xx: don't know but value is changing between 0x00 to 0x07
2. xx: this is the actual pixel clock
3. xx: this is changing according light conditions from 0x03 (dark) to
0xfc (bright) (center)
4. xx: this is changing according light conditions from 0x03 (dark) to
0xfc (bright) (edge)
5. xx: set value "Digital Gain of Red"
6. xx: set value "Digital Gain of Green"
7. xx: set value "Digital Gain of Blue"

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

Thomas Kaiser wrote:
> Hello Theodore
> 
> kilgota@banach.math.auburn.edu wrote:
>> Also, after the byte indicator for the compression algorithm there are 
>> some more bytes, and these almost definitely contain information which 
>> could be valuable while doing image processing on the output. If they 
>> are already kept and passed out of the module over to libv4lconvert, 
>> then it would be very easy to do something with those bytes if it is 
>> ever figured out precisely what they mean. But if it is not done now 
>> it would have to be done then and would cause even more trouble.
> 
> I sent it already in private mail to you. Here is the observation I made 
> for the PAC207 SOF some years ago:
> 
>  From usb snoop.
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
> 1. xx: looks like random value
> 2. xx: changed from 0x03 to 0x0b
> 3. xx: changed from 0x06 to 0x49
> 4. xx: changed from 0x07 to 0x55
> 5. xx: static 0x96
> 6. xx: static 0x80
> 7. xx: static 0xa0
> 
> And I did play in Linux and could identify some fields :-) .
> In Linux the header looks like this:
> 
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> 1. xx: don't know but value is changing between 0x00 to 0x07
> 2. xx: this is the actual pixel clock
> 3. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (center)
> 4. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (edge)
> 5. xx: set value "Digital Gain of Red"
> 6. xx: set value "Digital Gain of Green"
> 7. xx: set value "Digital Gain of Blue"
> 
> Thomas

And I forgot to say that the center brightness sensor was used to do 
auto brightness control in the old gspca driver. Pixel clock was changed 
on the fly to get better brightness in dark light conditions.

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Wed, 4 Mar 2009, Hans de Goede wrote:

>
>
> Kyle Guinn wrote:
>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>
> <snip>
>
>> Just a random thought, but maybe the pac207 driver can benefit from such a 
>> change as well?
>
> It could, but it is to late for that, the pac207 driver and corresponding 
> libv4l
> functionality has been out there for 2 kernel releases now, so we cannot 
> change that.

Pretty much what I said. It would have been better so, but done is done.

>
> Which also makes me wonder about the same change for the mr97310a, is that 
> cam already
> supported in a released kernel ?

Someone else may know better than I do, but since it was only added quite 
recently, surely not?

>
> If not we MUST make sure we get this change in before 2.6.29 final, if it is 
> I'm afraid
> we cannot make these changes. In that case if we ever need to header data we 
> need to
> define a new PIXFMT for mr97310a with the header data, and deprecate the old 
> one.

I do not quite understand. Why not just do it right away. especially if 
this has not appeared yet in any kernel?

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Wed, 4 Mar 2009, Thomas Kaiser wrote:

> Thomas Kaiser wrote:
>> Hello Theodore
>> 
>> kilgota@banach.math.auburn.edu wrote:
>>> Also, after the byte indicator for the compression algorithm there are 
>>> some more bytes, and these almost definitely contain information which 
>>> could be valuable while doing image processing on the output. If they are 
>>> already kept and passed out of the module over to libv4lconvert, then it 
>>> would be very easy to do something with those bytes if it is ever figured 
>>> out precisely what they mean. But if it is not done now it would have to 
>>> be done then and would cause even more trouble.
>> 
>> I sent it already in private mail to you. Here is the observation I made 
>> for the PAC207 SOF some years ago:
>>
>>  From usb snoop.
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>> 1. xx: looks like random value
>> 2. xx: changed from 0x03 to 0x0b
>> 3. xx: changed from 0x06 to 0x49
>> 4. xx: changed from 0x07 to 0x55
>> 5. xx: static 0x96
>> 6. xx: static 0x80
>> 7. xx: static 0xa0
>> 
>> And I did play in Linux and could identify some fields :-) .
>> In Linux the header looks like this:
>> 
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>> 1. xx: don't know but value is changing between 0x00 to 0x07
>> 2. xx: this is the actual pixel clock
>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (center)
>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (edge)
>> 5. xx: set value "Digital Gain of Red"
>> 6. xx: set value "Digital Gain of Green"
>> 7. xx: set value "Digital Gain of Blue"
>> 
>> Thomas
>
> And I forgot to say that the center brightness sensor was used to do auto 
> brightness control in the old gspca driver. Pixel clock was changed on the 
> fly to get better brightness in dark light conditions.

Yes, you did send it. My point here was to preserve the header 
information, for future use. So this is a good accounting of some possible 
future uses.

As to the actual contents of the header, as you describe things,

0. Do you have any idea how to account for the discrepancy between

>>  From usb snoop.
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
and 
>> In Linux the header looks like this:
>>
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00

(I am referring to the 00 00 as opposed to F0 00)? Or could this have 
happened somehow just because these were not two identical sessions?

>> 1. xx: don't know but value is changing between 0x00 to 0x07

as I said, this signifies the image format, qua compression algorithm in 
use, or if 00 then no compression.

>> 2. xx: this is the actual pixel clock

So there is a control setting for this?

>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (center)
>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (edge)
>> 5. xx: set value "Digital Gain of Red"
>> 6. xx: set value "Digital Gain of Green"
>> 7. xx: set value "Digital Gain of Blue"

Does anyone have any idea of how actually to use this information/ for 
example, since a lot of cameras are reporting some kind of 
similar looking information, does anyone know if there are any kinds of 
standard scales for these entries? Just what are they supposed to signify, 
and how exactly is one supposed to use such values, if they have 
been presented? When I say "a lot of cameras," understand, I mean still 
cameras as well as webcams, and cameras with a lot of different chipsets 
in them, too. So this is a question whether there is any standard system 
for the presentation of such data, and how it might constructively be used 
in image processing. I have had questions about this kind of thing for a 
long time, and I do not know where to look for the answers.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote:
> Which also makes me wonder about the same change for the mr97310a, is that
> cam already supported in a released kernel ?
>
> If not we MUST make sure we get this change in before 2.6.29 final, if it
> is I'm afraid we cannot make these changes. In that case if we ever need to
> header data we need to define a new PIXFMT for mr97310a with the header
> data, and deprecate the old one.
>

I don't believe the driver has made it to any kernel yet.  Even if it has, the 
user would need to have an unreleased version of libv4l.  I think this change 
would inconvenience me and Theodore at most.  Let's change it now.

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
> contents of file mr97310a.patch follow, for gspca/mr97310a.c
> --------------------------------------------------------
> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>   					data, n);
>   		sd->header_read = 0;
>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
> -		len -= sof - data;
> -		data = sof;
> -	}
> -	if (sd->header_read < 7) {
> -		int needed;
> -
> -		/* skip the rest of the header */
> -		needed = 7 - sd->header_read;
> -		if (len <= needed) {
> -			sd->header_read += len;
> -			return;
> -		}
> -		data += needed;
> -		len -= needed;
> -		sd->header_read = 7;
> +		/* keep the header, including sof marker, for coming frame */
> +		len -= n;
> +		data = sof - sizeof pac_sof_marker;;
>   	}
>
>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);

A few notes:

1.  There is an extra semicolon on that last added line.
2.  sd->header_read no longer seems necessary.
3.  If the SOF marker is split over two transfers then everything falls apart.  
I don't know if the camera will allow that to happen, but it's better to be 
safe.

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Wed, 4 Mar 2009, Kyle Guinn wrote:

> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>> --------------------------------------------------------
>> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
>> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>   					data, n);
>>   		sd->header_read = 0;
>>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>> -		len -= sof - data;
>> -		data = sof;
>> -	}
>> -	if (sd->header_read < 7) {
>> -		int needed;
>> -
>> -		/* skip the rest of the header */
>> -		needed = 7 - sd->header_read;
>> -		if (len <= needed) {
>> -			sd->header_read += len;
>> -			return;
>> -		}
>> -		data += needed;
>> -		len -= needed;
>> -		sd->header_read = 7;
>> +		/* keep the header, including sof marker, for coming frame */
>> +		len -= n;
>> +		data = sof - sizeof pac_sof_marker;;
>>   	}
>>
>>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>
> A few notes:
>
> 1.  There is an extra semicolon on that last added line.

Oops. My bifocals.

> 2.  sd->header_read no longer seems necessary.

This is very likely true.

> 3.  If the SOF marker is split over two transfers then everything falls apart.

Are you sure about that?

> I don't know if the camera will allow that to happen, but it's better to be
> safe.

Agreed.

Note that this was a RFC. So if it is agreed that something needs to be 
done, probably things should be put into a more formal patch structure.

Also I have a question of my own while thinking about this. It relates not 
to the module but to the decompression code. What do we have over there? 
Well,

void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char 
*outp,
                                int width, int height)

and then in my patch it does

         /* remove the header */
         inp += 12;

Perhaps this is not good, and what ought to be done instead is to "pass 
off" the inp to an internal variable, and then increase it, instead.

Possibly an even better alternative exists. The easiest way, I think, 
would be to take the two previous lines back out again, but 
instead go back to the function

static inline unsigned char get_byte(const unsigned char *inp,
                                      unsigned int bitpos)
{
         const unsigned char *addr;
         addr = inp + (bitpos >> 3);
         return (addr[0] << (bitpos & 7)) | (addr[1] >> (8 - (bitpos & 
7)));
}

and put the 12-byte shift into the line which computes addr, like this:

         addr = inp + 12 + (bitpos >> 3);

or if one really wants to get fancy about it then give a

#define MR97310a_HEADERSIZE	12

at the top of the file and then one could say

         addr = inp + (bitpos >> 3) + MR97310a_HEADERSIZE;

As I said, if doing any of these then one would leave strictly alone the 
decoding function and any of its contents. I am not sure if messing with 
the start of the inp variable is a good idea. Frankly, I do not know 
enough details to be certain. But on second look my instincts are against 
screwing with something like that. The thing that worries me is that what 
exactly happens to those 12 bytes. Do they disappear down a black hole, or 
what? For, in the end they will have to be deallocated somewhere. And 
what then? The alternative which I give above would do what is needed and 
also does not mess with the start location of inp.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu wrote:
> On Wed, 4 Mar 2009, Kyle Guinn wrote:
> > On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
> >> contents of file mr97310a.patch follow, for gspca/mr97310a.c
> >> --------------------------------------------------------
> >> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
> >> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
> >> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
> >>   					data, n);
> >>   		sd->header_read = 0;
> >>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
> >> -		len -= sof - data;
> >> -		data = sof;
> >> -	}
> >> -	if (sd->header_read < 7) {
> >> -		int needed;
> >> -
> >> -		/* skip the rest of the header */
> >> -		needed = 7 - sd->header_read;
> >> -		if (len <= needed) {
> >> -			sd->header_read += len;
> >> -			return;
> >> -		}
> >> -		data += needed;
> >> -		len -= needed;
> >> -		sd->header_read = 7;
> >> +		/* keep the header, including sof marker, for coming frame */
> >> +		len -= n;
> >> +		data = sof - sizeof pac_sof_marker;;
> >>   	}
> >>
> >>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
> >
> > A few notes:
> >
> > 1.  There is an extra semicolon on that last added line.
>
> Oops. My bifocals.
>
> > 2.  sd->header_read no longer seems necessary.
>
> This is very likely true.
>
> > 3.  If the SOF marker is split over two transfers then everything falls
> > apart.
>
> Are you sure about that?
>

Simple example:  One transfer ends with FF FF 00 and the next begins with FF 
96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, len stays the 
same, data now points at 3 bytes _before_ the transfer buffer, and we will 
most likely get undefined behavior when trying to copy the data out of the 
transfer buffer.  Not only that, but the FF FF 00 portion of the SOF won't 
get copied to the frame buffer.

Since we know what the SOF looks like, we don't need to worry about losing the 
FF FF 00 portion -- just copy sd->sof_read bytes from pac_sof_marker.  
Unfortunately my brain is fried right now and I can't come up with a working 
example.

> > I don't know if the camera will allow that to happen, but it's better to
> > be safe.
>
> Agreed.
>
> Note that this was a RFC. So if it is agreed that something needs to be
> done, probably things should be put into a more formal patch structure.
>
> Also I have a question of my own while thinking about this. It relates not
> to the module but to the decompression code. What do we have over there?
> Well,
>
> void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char
> *outp,
>                                 int width, int height)
>
> and then in my patch it does
>
>          /* remove the header */
>          inp += 12;
>
> Perhaps this is not good, and what ought to be done instead is to "pass
> off" the inp to an internal variable, and then increase it, instead.
>
> Possibly an even better alternative exists. The easiest way, I think,
> would be to take the two previous lines back out again, but
> instead go back to the function
>
> static inline unsigned char get_byte(const unsigned char *inp,
>                                       unsigned int bitpos)
> {
>          const unsigned char *addr;
>          addr = inp + (bitpos >> 3);
>          return (addr[0] << (bitpos & 7)) | (addr[1] >> (8 - (bitpos &
> 7)));
> }
>
> and put the 12-byte shift into the line which computes addr, like this:
>
>          addr = inp + 12 + (bitpos >> 3);
>

Let's not overcomplicate things.  I think inp += 12 with a comment is fine for 
now since we haven't completely reverse engineered the header yet.  Use one 
function to parse through the header, then use a different one to handle the 
frame decompression.  The header parser will call the correct decompressor 
function with the correct offset into the frame buffer.

> or if one really wants to get fancy about it then give a
>
> #define MR97310a_HEADERSIZE	12
>
> at the top of the file and then one could say
>
>          addr = inp + (bitpos >> 3) + MR97310a_HEADERSIZE;
>

I don't think we know this for sure yet.  Maybe the header length is variable 
and is specified along with the compression code?

> As I said, if doing any of these then one would leave strictly alone the
> decoding function and any of its contents. I am not sure if messing with
> the start of the inp variable is a good idea. Frankly, I do not know
> enough details to be certain. But on second look my instincts are against
> screwing with something like that. The thing that worries me is that what
> exactly happens to those 12 bytes. Do they disappear down a black hole, or
> what? For, in the end they will have to be deallocated somewhere. And
> what then? The alternative which I give above would do what is needed and
> also does not mess with the start location of inp.
>

inp is a local variable, so changing it inside the decompressor function will 
have no affect on anything else.  inp += 12 just moves the pointer 12 bytes 
down the buffer.  The decompressor function doesn't allocate anything, so no 
deallocation is necessary.

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Wed, 4 Mar 2009, Kyle Guinn wrote:

> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu wrote:
>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>> --------------------------------------------------------
>>>> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
>>>> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>   					data, n);
>>>>   		sd->header_read = 0;
>>>>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>> -		len -= sof - data;
>>>> -		data = sof;
>>>> -	}
>>>> -	if (sd->header_read < 7) {
>>>> -		int needed;
>>>> -
>>>> -		/* skip the rest of the header */
>>>> -		needed = 7 - sd->header_read;
>>>> -		if (len <= needed) {
>>>> -			sd->header_read += len;
>>>> -			return;
>>>> -		}
>>>> -		data += needed;
>>>> -		len -= needed;
>>>> -		sd->header_read = 7;
>>>> +		/* keep the header, including sof marker, for coming frame */
>>>> +		len -= n;
>>>> +		data = sof - sizeof pac_sof_marker;;
>>>>   	}
>>>>
>>>>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>
>>> A few notes:
>>>
>>> 1.  There is an extra semicolon on that last added line.
>>
>> Oops. My bifocals.
>>
>>> 2.  sd->header_read no longer seems necessary.

True, and if you remove it then you can also delete some other things. Try 
it and heed the compile warnings, and you will see.

>>> 3.  If the SOF marker is split over two transfers then everything falls
>>> apart.
>>
>> Are you sure about that?
>>
>
> Simple example:  One transfer ends with FF FF 00 and the next begins with FF
> 96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, len stays the
> same, data now points at 3 bytes _before_ the transfer buffer, and we will
> most likely get undefined behavior when trying to copy the data out of the
> transfer buffer.  Not only that, but the FF FF 00 portion of the SOF won't
> get copied to the frame buffer.


Yes, you are right. I was chasing through all of it, and I found the same 
thing. I will point out, though, that this danger is not a new one. The 
code which you originally had there suffers the same defect. The problem 
is not whether one decides to keep the SOF marker in the frame output. 
Rather, the problem is that one must *detect* it. And to detect it one 
must needs be able to read all of it at once. If you read only three bytes 
from it, and that is the end of the packet, then that will be analysed as 
still belonging to the same frame. Then the next packet will continue to 
be in the same frame, too.

A mitigating factor here is that when the next packet is "in the same 
frame" then what will happen in practice is that the decompressor will 
run, fill up the current frame, and stop when it reaches the end of the 
frame and will toss the rest of the data. So in other words the next frame 
will just get tossed.


> Since we know what the SOF looks like, we don't need to worry about losing the
> FF FF 00 portion

Yes, you do. You know what the marker looks like, and I know. But the FF 
FF 00 is the end of the packet. So a computer will not know. It will not 
be detected as part of an SOF marker. Instead, it will just be tacked onto 
the data from the current frame and any special meaning will be lost. 
However, the consequence is that the decompression algorithm will use 
enough data to finish the current frame, stop before it has to use the FF 
FF 00, and, since no marker has been detected in the next packet, either, 
all new data will just be ignored as junk until another SOF marker comes 
up and is detected. Then and only then a new output frame will be 
initiated.

-- just copy sd->sof_read bytes from pac_sof_marker.
> Unfortunately my brain is fried right now and I can't come up with a working
> example.
>
>>> I don't know if the camera will allow that to happen, but it's better to
>>> be safe.
>>
>> Agreed.

Maybe not. Perhaps according to my analysis above it is actually no big 
deal. My analysis of what will happen is based upon the way the 
decomressor function works (uses data until it is finished with a frame, 
and then quits). So if it occasionally happens that an SOF marker is split 
in two across two packets, then it just causes a frame's data to be 
skipped. I can't imagine any other ill effect. Of course, if this bad 
thing happens for 350 frames in succession, that would be quite 
interesting.

Therefore, what I think is that the attempt to code around the possibility 
that an SOF marker is split across two frames would be quite likely to 
cause more trouble than it is worth. What would be needed is to consider 
two successive packets at a time. If there is no SOF marker which can 
start inside the first one and end in the second one, then put the data 
from the  first packet away, get a new packet, rinse. lather, and repeat.

Probably we need the opinion of a real expert about whether it is 
necessary to go to such lengths, now that it is seen what the problem 
might be.


Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

Kyle Guinn wrote:
> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu wrote:
>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>> --------------------------------------------------------
>>>> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
>>>> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>   					data, n);
>>>>   		sd->header_read = 0;
>>>>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>> -		len -= sof - data;
>>>> -		data = sof;
>>>> -	}
>>>> -	if (sd->header_read < 7) {
>>>> -		int needed;
>>>> -
>>>> -		/* skip the rest of the header */
>>>> -		needed = 7 - sd->header_read;
>>>> -		if (len <= needed) {
>>>> -			sd->header_read += len;
>>>> -			return;
>>>> -		}
>>>> -		data += needed;
>>>> -		len -= needed;
>>>> -		sd->header_read = 7;
>>>> +		/* keep the header, including sof marker, for coming frame */
>>>> +		len -= n;
>>>> +		data = sof - sizeof pac_sof_marker;;
>>>>   	}
>>>>
>>>>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>> A few notes:
>>>
>>> 1.  There is an extra semicolon on that last added line.
>> Oops. My bifocals.
>>
>>> 2.  sd->header_read no longer seems necessary.
>> This is very likely true.
>>
>>> 3.  If the SOF marker is split over two transfers then everything falls
>>> apart.
>> Are you sure about that?
>>
> 
> Simple example:  One transfer ends with FF FF 00 and the next begins with FF 
> 96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, len stays the 
> same, data now points at 3 bytes _before_ the transfer buffer, and we will 
> most likely get undefined behavior when trying to copy the data out of the 
> transfer buffer.  Not only that, but the FF FF 00 portion of the SOF won't 
> get copied to the frame buffer.
> 

Good point, since we will always pass frames to userspace which start with the
sof, maybe we should just only pass the variable part of the header to userspace?

That sure feels like the easiest solution to me.

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

Kyle Guinn wrote:
> On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote:
>> Which also makes me wonder about the same change for the mr97310a, is that
>> cam already supported in a released kernel ?
>>
>> If not we MUST make sure we get this change in before 2.6.29 final, if it
>> is I'm afraid we cannot make these changes. In that case if we ever need to
>> header data we need to define a new PIXFMT for mr97310a with the header
>> data, and deprecate the old one.
>>
> 
> I don't believe the driver has made it to any kernel yet.  Even if it has, the 
> user would need to have an unreleased version of libv4l.  I think this change 
> would inconvenience me and Theodore at most.  Let's change it now.
> 

+1

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

Hello Theodore

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Wed, 4 Mar 2009, Thomas Kaiser wrote:
> As to the actual contents of the header, as you describe things,
> 
> 0. Do you have any idea how to account for the discrepancy between
> 
>>>  From usb snoop.
>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
> and
>>> In Linux the header looks like this:
>>>
>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> 
> (I am referring to the 00 00 as opposed to F0 00)? Or could this have 
> happened somehow just because these were not two identical sessions?

Doesn't remember what the differences was. The first is from Windoz 
(usbsnoop) and the second is from Linux.

> 
>>> 1. xx: don't know but value is changing between 0x00 to 0x07
> 
> as I said, this signifies the image format, qua compression algorithm in 
> use, or if 00 then no compression.

On the PAC207, the compression can be controlled with a register called 
"Compression Balance size". So, I guess, depending on the value set in 
the register this value in the header will show what compression level 
is set.

> 
>>> 2. xx: this is the actual pixel clock
> 
> So there is a control setting for this?

Yes, in the PAC207, register 2. (12 MHz divided by the value set).

> 
>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>> 0xfc (bright) (center)
>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>> 0xfc (bright) (edge)
>>> 5. xx: set value "Digital Gain of Red"
>>> 6. xx: set value "Digital Gain of Green"
>>> 7. xx: set value "Digital Gain of Blue"
> 
> Does anyone have any idea of how actually to use this information/ for 
> example, since a lot of cameras are reporting some kind of similar 
> looking information, does anyone know if there are any kinds of standard 
> scales for these entries? Just what are they supposed to signify, and 
> how exactly is one supposed to use such values, if they have been 
> presented? When I say "a lot of cameras," understand, I mean still 
> cameras as well as webcams, and cameras with a lot of different chipsets 
> in them, too. So this is a question whether there is any standard system 
> for the presentation of such data, and how it might constructively be 
> used in image processing. I have had questions about this kind of thing 
> for a long time, and I do not know where to look for the answers.

For the brightness, I guess, 0 means dark and 0xff completely bright 
(sensor is in saturation)?

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Thomas Kaiser wrote:

> Hello Theodore
>
> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Wed, 4 Mar 2009, Thomas Kaiser wrote:
>> As to the actual contents of the header, as you describe things,
>> 
>> 0. Do you have any idea how to account for the discrepancy between
>>
>>>>  From usb snoop.
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>> and
>>>> In Linux the header looks like this:
>>>> 
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>> 
>> (I am referring to the 00 00 as opposed to F0 00)? Or could this have 
>> happened somehow just because these were not two identical sessions?
>
> Doesn't remember what the differences was. The first is from Windoz 
> (usbsnoop) and the second is from Linux.
>
>> 
>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>> 
>> as I said, this signifies the image format, qua compression algorithm in 
>> use, or if 00 then no compression.
>
> On the PAC207, the compression can be controlled with a register called 
> "Compression Balance size". So, I guess, depending on the value set in the 
> register this value in the header will show what compression level is set.
>
>> 
>>>> 2. xx: this is the actual pixel clock
>> 
>> So there is a control setting for this?
>
> Yes, in the PAC207, register 2. (12 MHz divided by the value set).
>
>> 
>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (center)
>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (edge)
>>>> 5. xx: set value "Digital Gain of Red"
>>>> 6. xx: set value "Digital Gain of Green"
>>>> 7. xx: set value "Digital Gain of Blue"
>> 
>> Does anyone have any idea of how actually to use this information/ for 
>> example, since a lot of cameras are reporting some kind of similar looking 
>> information, does anyone know if there are any kinds of standard scales for 
>> these entries? Just what are they supposed to signify, and how exactly is 
>> one supposed to use such values, if they have been presented? When I say "a 
>> lot of cameras," understand, I mean still cameras as well as webcams, and 
>> cameras with a lot of different chipsets in them, too. So this is a 
>> question whether there is any standard system for the presentation of such 
>> data, and how it might constructively be used in image processing. I have 
>> had questions about this kind of thing for a long time, and I do not know 
>> where to look for the answers.
>
> For the brightness, I guess, 0 means dark and 0xff completely bright (sensor 
> is in saturation)?

That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or it 
could be that only the digits 0 through 9 are actually used, and the basis 
is then 100, or too many other variations to count. Also what is 
considered a "normal" or an "average" value? The trouble with your 
suggestion of a scale from 0 to 0xff is that it makes sense, and in a 
situation like this one obviously can not assume that.

What I am suspecting is that these things have some kind of standard 
definitions, which are not necessarily done by logic but by convention, 
and there is a document out there somewhere which lays it all down. The 
document could have been produced by Microsoft, for example, which 
doubtless has its own problems reducing chaos to order in the industry, or 
by some kind of consortium of camera manufacturers, or something like 
that. I really do strongly suspect that the interpretation of all of this 
is written down somewhere. But I don't know where to look.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Thu, 5 Mar 2009, Hans de Goede wrote:
> 
>>
>>
>> Kyle Guinn wrote:
>>> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu 
>>> wrote:
>>>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu 
>>>>> wrote:
>>>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>>>> --------------------------------------------------------
>>>>>> --- mr97310a.c.old    2009-02-23 23:59:07.000000000 -0600
>>>>>> +++ mr97310a.c.new    2009-03-03 17:19:06.000000000 -0600
>>>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>>>                       data, n);
>>>>>>           sd->header_read = 0;
>>>>>>           gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>>>> -        len -= sof - data;
>>>>>> -        data = sof;
>>>>>> -    }
>>>>>> -    if (sd->header_read < 7) {
>>>>>> -        int needed;
>>>>>> -
>>>>>> -        /* skip the rest of the header */
>>>>>> -        needed = 7 - sd->header_read;
>>>>>> -        if (len <= needed) {
>>>>>> -            sd->header_read += len;
>>>>>> -            return;
>>>>>> -        }
>>>>>> -        data += needed;
>>>>>> -        len -= needed;
>>>>>> -        sd->header_read = 7;
>>>>>> +        /* keep the header, including sof marker, for coming 
>>>>>> frame */
>>>>>> +        len -= n;
>>>>>> +        data = sof - sizeof pac_sof_marker;;
>>>>>>       }
>>>>>>
>>>>>>       gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>>> A few notes:
>>>>>
>>>>> 1.  There is an extra semicolon on that last added line.
>>>> Oops. My bifocals.
>>>>
>>>>> 2.  sd->header_read no longer seems necessary.
>>>> This is very likely true.
>>>>
>>>>> 3.  If the SOF marker is split over two transfers then everything 
>>>>> falls
>>>>> apart.
>>>> Are you sure about that?
>>>>
>>>
>>> Simple example:  One transfer ends with FF FF 00 and the next begins 
>>> with FF 96 64.  pac_find_sof() returns a pointer to 64, n is set to 
>>> 0, len stays the same, data now points at 3 bytes _before_ the 
>>> transfer buffer, and we will most likely get undefined behavior when 
>>> trying to copy the data out of the transfer buffer.  Not only that, 
>>> but the FF FF 00 portion of the SOF won't get copied to the frame 
>>> buffer.
>>>
>>
>> Good point, since we will always pass frames to userspace which start 
>> with the
>> sof, maybe we should just only pass the variable part of the header to 
>> userspace?
>>
>> That sure feels like the easiest solution to me.
>>
>> Regards,
>>
>> Hans
>>
> 
> Hans, that would not solve the problem. In fact, it appears to me that 
> this problem was already inherent in the driver code before I proposed 
> any patches at all.

Erm, if I understood correctly (haven't looked yet) the driver is working
with the sof detection from pac_common, which does work with a SOF split
over multiple frames.

The problem with the new code is that it takes the return value of the sof
detection (which is a pointer into the current frame) and then
substracts the length of the sofmarker, however if only part of the sof was
in the current frame the resulting pointer (after substracting the sof length)
will point to before the current frame buffer.

Hence my proposal to fix this by simple only sending the variable part of the
header to userspace (and thus not do the substraction).

Anyways this is just what I understood from the former discussion I have *not*
looked at the actual code (-ENOTIME)

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Hans de Goede wrote:

>
>
> Kyle Guinn wrote:
>> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu wrote:
>>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>>> --------------------------------------------------------
>>>>> --- mr97310a.c.old	2009-02-23 23:59:07.000000000 -0600
>>>>> +++ mr97310a.c.new	2009-03-03 17:19:06.000000000 -0600
>>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>>   					data, n);
>>>>>   		sd->header_read = 0;
>>>>>   		gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>>> -		len -= sof - data;
>>>>> -		data = sof;
>>>>> -	}
>>>>> -	if (sd->header_read < 7) {
>>>>> -		int needed;
>>>>> -
>>>>> -		/* skip the rest of the header */
>>>>> -		needed = 7 - sd->header_read;
>>>>> -		if (len <= needed) {
>>>>> -			sd->header_read += len;
>>>>> -			return;
>>>>> -		}
>>>>> -		data += needed;
>>>>> -		len -= needed;
>>>>> -		sd->header_read = 7;
>>>>> +		/* keep the header, including sof marker, for coming frame */
>>>>> +		len -= n;
>>>>> +		data = sof - sizeof pac_sof_marker;;
>>>>>   	}
>>>>>
>>>>>   	gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>> A few notes:
>>>> 
>>>> 1.  There is an extra semicolon on that last added line.
>>> Oops. My bifocals.
>>> 
>>>> 2.  sd->header_read no longer seems necessary.
>>> This is very likely true.
>>> 
>>>> 3.  If the SOF marker is split over two transfers then everything falls
>>>> apart.
>>> Are you sure about that?
>>> 
>> 
>> Simple example:  One transfer ends with FF FF 00 and the next begins with 
>> FF 96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, len stays 
>> the same, data now points at 3 bytes _before_ the transfer buffer, and we 
>> will most likely get undefined behavior when trying to copy the data out of 
>> the transfer buffer.  Not only that, but the FF FF 00 portion of the SOF 
>> won't get copied to the frame buffer.
>> 
>
> Good point, since we will always pass frames to userspace which start with 
> the
> sof, maybe we should just only pass the variable part of the header to 
> userspace?
>
> That sure feels like the easiest solution to me.
>
> Regards,
>
> Hans
>

Hans, that would not solve the problem. In fact, it appears to me that 
this problem was already inherent in the driver code before I proposed any 
patches at all. The problem is that one must _detect_ the SOF marker. The 
further problem is (and was, and nothing yet has changed that) that if the 
SOF marker is split across two packets it will fail to be detected.

Two possible courses of action:

1. Leave the matter alone. It could be maintained that one of the 
following is the case:
 	(a) this never happens
 	(b) even if it does happen (rarely), it will do no great harm, 
because the only effect will be that the output skips a frame, having not 
detected its start of frame marker. For, the frames consist of compressed 
data, and if there is too much compressed data for a given frame, then 
that extra compressed data will simply be tossed. The next frame which is 
actually seen and used will be the next frame for which an SOF marker is 
actually detected.

So, the argument for number 1 would be that, yes, this is sort of a bug, 
but it is insignificant, not serious, and could never cause a problem in 
practice even if it occurs, because the only result would be for a frame 
to get dropped. Another argument in favor of it would be that in any event 
the camera is sending isochronous packets, and there is in any event no 
guarantee of the validity and accuracy of any one single packet. Instead, 
the reliance is on the high rate at which the packets get sent, received, 
and processed.

2. If it is deemed that, yes, it can happen that an SOF marker gets split 
between two packets, and, no, if that happens it is a problem which should 
not be ignored, then there is an alternative course of action:
 	Keep a cache consisting of the last 4 bytes of each packet, and 
see if, when the next packet comes down, a SOF marker is detected in those 
bytes, plus the new bytes from the beginning of the new packet. Then a SOF 
marker will not be missed, even if it occurs in the situation described 
above.

Alternative number two is in fact not very much more difficult, but it 
would involve putting an if-then-else or two into the code and also would 
require one to have a place to put those last four bytes of each packet, 
keep them around until the next packet is obtained, and then parse the 
result. This might slow things down, but probably not by very much. So 
which way to do this would obviously depend upon some evaluation of the 
danger of doing nothing.

However, the discussion of whether or not to deal with an SOF marker which 
is split across two packets has nothing at all to do with the question of 
whether to preserve the SOF marker in the raw frame output. The two 
questions are independent.

I say that, whatever else is done, it is good to preserve the SOF marker 
in the raw frame output. It is nice to see it there because then one 
incontrovertibly knows that the frame is aligned with the SOF marker at 
its start. I mean, if there is something wrong and one needs to do 
debugging, or if there is a new compression algorithm which needs to be 
studied, then if the SOF marker is absent in the raw output how in hell 
does one know the output is correctly aligned? Simple answer. One does 
not know. There really was a way to know that, but it has been thrown 
away. It is also much easier to code in the module, because then 
there is no need to code around the need to keep everything that came 
down, unless it is an SOF marker and then one throws it away and is forced 
to re-align the remaining data.

I wonder if anyone with wider experience could come up with an intelligent 
evaluation of whether to go with item 1, or item 2? I think I have listed 
the arguments for and against each of them, but to know which one of these 
is actually best, is another thing.

Finally, again, the question of what happens if the SOF marker is split 
between two packets in fact has nothing to do with the changes I was 
proposing. It is independent. Except for one thing: Could it be that the 
simplifications I was proposing have eliminated a lot of convoluted code 
and thereby brought this problem to the surface?

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

Hello Theodore

kilgota@banach.math.auburn.edu wrote:
>> For the brightness, I guess, 0 means dark and 0xff completely bright 
>> (sensor is in saturation)?
> 
> That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or 
> it could be that only the digits 0 through 9 are actually used, and the 
> basis is then 100, or too many other variations to count. Also what is 
> considered a "normal" or an "average" value? The trouble with your 
> suggestion of a scale from 0 to 0xff is that it makes sense, and in a 
> situation like this one obviously can not assume that.

I don't really understand what you try to tell with this sentence:
"and in a situation like this one obviously can not assume that."

The values changed from 0x03 (dark) to 0xfc (bright), for me does this 
mean that the scale goes from 0x00 to 0xff!? Or I am wrong?

> 
> What I am suspecting is that these things have some kind of standard 
> definitions, which are not necessarily done by logic but by convention, 
> and there is a document out there somewhere which lays it all down. The 
> document could have been produced by Microsoft, for example, which 
> doubtless has its own problems reducing chaos to order in the industry, 
> or by some kind of consortium of camera manufacturers, or something like 
> that. I really do strongly suspect that the interpretation of all of 
> this is written down somewhere. But I don't know where to look.

I believe that this documents are exists, but not available for 
public:-( Just company confidential.

Anyway most of the Linux webcam drivers were done by re-engineering the 
Windoz driver (usbsnoop). That said, all information about the cams is 
"a guess".

For the brightness thing, I just was working with a light and studied 
what is changing in the header of the frame. At this time I did this, I 
was not aware that I could remove the lens of the webcam to be more 
sensible to light change and get more precise results.

During the work I did for the PAC7311 Pixart chip I found out that 
removing the lens and put light directly to the sensor does help a lot 
to figure out how the cam is working.

And with this idea in mind, we could even get further to guess the 
compression algo from a cam.

Assuming that the sensor has a Bayer pattern.
- remove lens.
- put white light on the sensor
- use color filter an put each spectrum (RGB) on the sensor
- check the stream and find out what is changing in the stream according 
to the different light conditions.

Looks like I get off topic, now ;-)

Something else comes in my mind. Would it good to document all this what 
we are talking bout somewhere on a webpage?

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Thomas Kaiser wrote:

> Hello Theodore
>
> kilgota@banach.math.auburn.edu wrote:
>>> For the brightness, I guess, 0 means dark and 0xff completely bright 
>>> (sensor is in saturation)?
>> 
>> That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or it 
>> could be that only the digits 0 through 9 are actually used, and the basis 
>> is then 100, or too many other variations to count. Also what is considered 
>> a "normal" or an "average" value? The trouble with your suggestion of a 
>> scale from 0 to 0xff is that it makes sense, and in a situation like this 
>> one obviously can not assume that.
>
> I don't really understand what you try to tell with this sentence:
> "and in a situation like this one obviously can not assume that."

I mean, your interpretation of 0 to 0xff is a natural and sensible 
interpretation (for us). But what one can not assume is, it made sense to 
those who constructed the system. Perhaps those guys were setting it all 
up differently.

>
> The values changed from 0x03 (dark) to 0xfc (bright), for me does this mean 
> that the scale goes from 0x00 to 0xff!? Or I am wrong?

Well, if you have actual data to back up your impressions about this, then 
clearly you have evidence. So that is good, obviously.

>
>> 
>> What I am suspecting is that these things have some kind of standard 
>> definitions, which are not necessarily done by logic but by convention, and 
>> there is a document out there somewhere which lays it all down. The 
>> document could have been produced by Microsoft, for example, which 
>> doubtless has its own problems reducing chaos to order in the industry, or 
>> by some kind of consortium of camera manufacturers, or something like that. 
>> I really do strongly suspect that the interpretation of all of this is 
>> written down somewhere. But I don't know where to look.
>
> I believe that this documents are exists, but not available for public:-( 
> Just company confidential.

That may be true. If so, then such documentation is indeed not available. 
But sometimes a document is published and available, and one just is not 
aware of the fact.

>
> Anyway most of the Linux webcam drivers were done by re-engineering the 
> Windoz driver (usbsnoop). That said, all information about the cams is "a 
> guess".

Very true. Also true about the still cameras that I supported in 
libgphoto2. There are no secrets kept on the USB bus. But what is done 
inside the computer does not appear on the USB bus and there is no log of 
it.

>
> For the brightness thing, I just was working with a light and studied what is 
> changing in the header of the frame. At this time I did this, I was not aware 
> that I could remove the lens of the webcam to be more sensible to light 
> change and get more precise results.
>
> During the work I did for the PAC7311 Pixart chip I found out that removing 
> the lens and put light directly to the sensor does help a lot to figure out 
> how the cam is working.
>
> And with this idea in mind, we could even get further to guess the 
> compression algo from a cam.
>
> Assuming that the sensor has a Bayer pattern.
> - remove lens.
> - put white light on the sensor
> - use color filter an put each spectrum (RGB) on the sensor
> - check the stream and find out what is changing in the stream according to 
> the different light conditions.
>
> Looks like I get off topic, now ;-)

But it is very interesting nevertheless.

>
> Something else comes in my mind. Would it good to document all this what we 
> are talking bout somewhere on a webpage?
>
> Thomas

Perhaps so. Also a good idea to try to collect some people who have 
similar interests and are trying to work on similar problems. I have been 
trying to do that for a while, but with mixed and limited success.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:
>>> That of course is a guess. OTOH it could be on a scale of 0 to 0x80, 
>>> or it could be that only the digits 0 through 9 are actually used, 
>>> and the basis is then 100, or too many other variations to count. 
>>> Also what is considered a "normal" or an "average" value? The trouble 
>>> with your suggestion of a scale from 0 to 0xff is that it makes 
>>> sense, and in a situation like this one obviously can not assume that.
>>
>> I don't really understand what you try to tell with this sentence:
>> "and in a situation like this one obviously can not assume that."
> 
> I mean, your interpretation of 0 to 0xff is a natural and sensible 
> interpretation (for us). But what one can not assume is, it made sense 
> to those who constructed the system. Perhaps those guys were setting it 
> all up differently.

You are right, we don't know what the developer were thinking, 
unfortunately,

You have to turn yourself in a webcam developer and think how you would 
do it. When you find, by observing/testing the cam, that it looks 
similar as you thought about how to do it, the observation should be true!

> 
>>
>> The values changed from 0x03 (dark) to 0xfc (bright), for me does this 
>> mean that the scale goes from 0x00 to 0xff!? Or I am wrong?
> 
> Well, if you have actual data to back up your impressions about this, 
> then clearly you have evidence. So that is good, obviously.

I will do this again in the next couple of weeks (lens removed).

> 
>>
>>>
>>> What I am suspecting is that these things have some kind of standard 
>>> definitions, which are not necessarily done by logic but by 
>>> convention, and there is a document out there somewhere which lays it 
>>> all down. The document could have been produced by Microsoft, for 
>>> example, which doubtless has its own problems reducing chaos to order 
>>> in the industry, or by some kind of consortium of camera 
>>> manufacturers, or something like that. I really do strongly suspect 
>>> that the interpretation of all of this is written down somewhere. But 
>>> I don't know where to look.
>>
>> I believe that this documents are exists, but not available for 
>> public:-( Just company confidential.
> 
> That may be true. If so, then such documentation is indeed not 
> available. But sometimes a document is published and available, and one 
> just is not aware of the fact.
> 
>>
>> Anyway most of the Linux webcam drivers were done by re-engineering 
>> the Windoz driver (usbsnoop). That said, all information about the 
>> cams is "a guess".
> 
> Very true. Also true about the still cameras that I supported in 
> libgphoto2. There are no secrets kept on the USB bus. But what is done 
> inside the computer does not appear on the USB bus and there is no log 
> of it.
> 
>>
>> For the brightness thing, I just was working with a light and studied 
>> what is changing in the header of the frame. At this time I did this, 
>> I was not aware that I could remove the lens of the webcam to be more 
>> sensible to light change and get more precise results.
>>
>> During the work I did for the PAC7311 Pixart chip I found out that 
>> removing the lens and put light directly to the sensor does help a lot 
>> to figure out how the cam is working.
>>
>> And with this idea in mind, we could even get further to guess the 
>> compression algo from a cam.
>>
>> Assuming that the sensor has a Bayer pattern.
>> - remove lens.
>> - put white light on the sensor
>> - use color filter an put each spectrum (RGB) on the sensor
>> - check the stream and find out what is changing in the stream 
>> according to the different light conditions.
>>
>> Looks like I get off topic, now ;-)
> 
> But it is very interesting nevertheless.

I think so, I didn't try with the color filter :-(

> 
>>
>> Something else comes in my mind. Would it good to document all this 
>> what we are talking bout somewhere on a webpage?
>>
>> Thomas
> 
> Perhaps so. Also a good idea to try to collect some people who have 
> similar interests and are trying to work on similar problems. I have 
> been trying to do that for a while, but with mixed and limited success.

May be, some people read this and have the same felling. Let's see what 
happens.

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Hans de Goede]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Thu, 5 Mar 2009, Hans de Goede wrote:
> 
>>
>>
>> kilgota@banach.math.auburn.edu wrote:
>>>
>>>
>>> On Thu, 5 Mar 2009, Hans de Goede wrote:
>>>
>>>>
>>>>
>>>> Kyle Guinn wrote:
>>>>> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu 
>>>>> wrote:
>>>>>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>>>>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu 
>>>>>>> wrote:
>>>>>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>>>>>> --------------------------------------------------------
>>>>>>>> --- mr97310a.c.old    2009-02-23 23:59:07.000000000 -0600
>>>>>>>> +++ mr97310a.c.new    2009-03-03 17:19:06.000000000 -0600
>>>>>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>>>>>                       data, n);
>>>>>>>>           sd->header_read = 0;
>>>>>>>>           gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>>>>>> -        len -= sof - data;
>>>>>>>> -        data = sof;
>>>>>>>> -    }
>>>>>>>> -    if (sd->header_read < 7) {
>>>>>>>> -        int needed;
>>>>>>>> -
>>>>>>>> -        /* skip the rest of the header */
>>>>>>>> -        needed = 7 - sd->header_read;
>>>>>>>> -        if (len <= needed) {
>>>>>>>> -            sd->header_read += len;
>>>>>>>> -            return;
>>>>>>>> -        }
>>>>>>>> -        data += needed;
>>>>>>>> -        len -= needed;
>>>>>>>> -        sd->header_read = 7;
>>>>>>>> +        /* keep the header, including sof marker, for coming 
>>>>>>>> frame */
>>>>>>>> +        len -= n;
>>>>>>>> +        data = sof - sizeof pac_sof_marker;;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>>>>> A few notes:
>>>>>>>
>>>>>>> 1.  There is an extra semicolon on that last added line.
>>>>>> Oops. My bifocals.
>>>>>>
>>>>>>> 2.  sd->header_read no longer seems necessary.
>>>>>> This is very likely true.
>>>>>>
>>>>>>> 3.  If the SOF marker is split over two transfers then everything 
>>>>>>> falls
>>>>>>> apart.
>>>>>> Are you sure about that?
>>>>>>
>>>>>
>>>>> Simple example:  One transfer ends with FF FF 00 and the next 
>>>>> begins with FF 96 64.  pac_find_sof() returns a pointer to 64, n is 
>>>>> set to 0, len stays the same, data now points at 3 bytes _before_ 
>>>>> the transfer buffer, and we will most likely get undefined behavior 
>>>>> when trying to copy the data out of the transfer buffer.  Not only 
>>>>> that, but the FF FF 00 portion of the SOF won't get copied to the 
>>>>> frame buffer.
>>>>>
>>>>
>>>> Good point, since we will always pass frames to userspace which 
>>>> start with the
>>>> sof, maybe we should just only pass the variable part of the header 
>>>> to userspace?
>>>>
>>>> That sure feels like the easiest solution to me.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>
>>> Hans, that would not solve the problem. In fact, it appears to me 
>>> that this problem was already inherent in the driver code before I 
>>> proposed any patches at all.
>>
>> Erm, if I understood correctly (haven't looked yet) the driver is working
>> with the sof detection from pac_common, which does work with a SOF split
>> over multiple frames.
> 
> That is not my impression of what the code in pac_common is doing. That 
> code, as I understand, is totally neutral about such things. What is 
> does is to parse some data and search for an SOF marker, and if it finds 
> such a thing then it declares the next byte after to be what it calls 
> "sof". Specifically, there is the function
> 
> static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
>                                         unsigned char *m, int len)
> 
> and what it does is that it searches through unsigned char *m up to the 
> extent declared in int len, looking for an SOF marker. If it finds one, 
> then it returns the location of the next byte after the SOF marker has 
> been successfully read.
> 

Check that function again, more carefully, if it fails, but finds a part of
the sof at the end of m it remembers how much of the sof it has already seen
and continues where it left of the next time it is called.

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Hans de Goede wrote:

>
>
> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Thu, 5 Mar 2009, Hans de Goede wrote:
>> 
>>> 
>>> 
>>> Kyle Guinn wrote:
>>>> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu wrote:
>>>>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>>>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu wrote:
>>>>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>>>>> --------------------------------------------------------
>>>>>>> --- mr97310a.c.old    2009-02-23 23:59:07.000000000 -0600
>>>>>>> +++ mr97310a.c.new    2009-03-03 17:19:06.000000000 -0600
>>>>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>>>>                       data, n);
>>>>>>>           sd->header_read = 0;
>>>>>>>           gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>>>>> -        len -= sof - data;
>>>>>>> -        data = sof;
>>>>>>> -    }
>>>>>>> -    if (sd->header_read < 7) {
>>>>>>> -        int needed;
>>>>>>> -
>>>>>>> -        /* skip the rest of the header */
>>>>>>> -        needed = 7 - sd->header_read;
>>>>>>> -        if (len <= needed) {
>>>>>>> -            sd->header_read += len;
>>>>>>> -            return;
>>>>>>> -        }
>>>>>>> -        data += needed;
>>>>>>> -        len -= needed;
>>>>>>> -        sd->header_read = 7;
>>>>>>> +        /* keep the header, including sof marker, for coming frame */
>>>>>>> +        len -= n;
>>>>>>> +        data = sof - sizeof pac_sof_marker;;
>>>>>>>       }
>>>>>>>
>>>>>>>       gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>>>> A few notes:
>>>>>> 
>>>>>> 1.  There is an extra semicolon on that last added line.
>>>>> Oops. My bifocals.
>>>>> 
>>>>>> 2.  sd->header_read no longer seems necessary.
>>>>> This is very likely true.
>>>>> 
>>>>>> 3.  If the SOF marker is split over two transfers then everything falls
>>>>>> apart.
>>>>> Are you sure about that?
>>>>> 
>>>> 
>>>> Simple example:  One transfer ends with FF FF 00 and the next begins with 
>>>> FF 96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, len 
>>>> stays the same, data now points at 3 bytes _before_ the transfer buffer, 
>>>> and we will most likely get undefined behavior when trying to copy the 
>>>> data out of the transfer buffer.  Not only that, but the FF FF 00 portion 
>>>> of the SOF won't get copied to the frame buffer.
>>>> 
>>> 
>>> Good point, since we will always pass frames to userspace which start with 
>>> the
>>> sof, maybe we should just only pass the variable part of the header to 
>>> userspace?
>>> 
>>> That sure feels like the easiest solution to me.
>>> 
>>> Regards,
>>> 
>>> Hans
>>> 
>> 
>> Hans, that would not solve the problem. In fact, it appears to me that this 
>> problem was already inherent in the driver code before I proposed any 
>> patches at all.
>
> Erm, if I understood correctly (haven't looked yet) the driver is working
> with the sof detection from pac_common, which does work with a SOF split
> over multiple frames.

That is not my impression of what the code in pac_common is doing. That 
code, as I understand, is totally neutral about such things. What is does 
is to parse some data and search for an SOF marker, and if it finds such a 
thing then it declares the next byte after to be what it calls "sof". 
Specifically, there is the function

static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
                                         unsigned char *m, int len)

and what it does is that it searches through unsigned char *m up to the 
extent declared in int len, looking for an SOF marker. If it finds one, 
then it returns the location of the next byte after the SOF marker has 
been successfully read.

What this function does not address in any way whatsoever is where the 
data which is called unsigned char *m came from. So, the problem is, if 
unsigned char *m is a single packet, or if it is what remains after some 
stuff from the head of the packet has previously been put away, then the 
danger is very much present that we are discussing. Namely, if the first 
part of an SOF marker is present at the end of the data being considered 
and the rest of the SOF marker is in the next packet of data which is not 
yet being considered, then this function from pac_common, if naively 
applied, will miss the SOF marker completely. By its nature, this function 
can not search data which was not yet presented to it. That is the 
problem.

Therefore, if one must make sure the SOF marker is always detected, even 
if it is split across two packets, then any application of this function 
is buggy, which does not take into account the fact that one can run out 
of data before detecting an SOF marker, even when part of it is there at 
the very end of the data, or if an incomplete part of it is there at the 
very beginning of the data it will equally be missed. This remark would 
potentially apply to any camera driver which is using this function, not 
just the mr97310a driver.  Again, the pac_find_sof() function does not 
deal with _this_ issue, at all. It is up to the user of it to code around 
any potential problem of this sort.

The only way to avoid any possible occurrence of the problem is to 
follow my suggestion number two. One must keep four bytes from the end of 
a packet, and adjoin to that four bytes from the beginning of a new 
packet, and search those eight bytes, too, for an SOF marker. That is the 
only way to be sure of not missing an SOF marker which is split across 
two packets.

>
> The problem with the new code is that it takes the return value of the sof
> detection (which is a pointer into the current frame) and then
> substracts the length of the sofmarker, however if only part of the sof was
> in the current frame the resulting pointer (after substracting the sof 
> length)
> will point to before the current frame buffer.

That would be a bad thing if it could happen. But it can't happen. What 
will have happened instead is that the SOF marker has not been detected, 
at all. Now, if that is also a bad thing, then something ought to be done 
about it. But the nightmare scenario that you describe can not occur, at 
least without violating logic.

>
> Hence my proposal to fix this by simple only sending the variable part of the
> header to userspace (and thus not do the substraction).

Again, you have to have the entire SOF marker within the present packet 
before you can detect it. Otherwise, it will not be detected. This is not 
because of a failure of pac_find_sof(), but it is a question of what data 
was given to pac_find_sof(), to be searched. If you give it a packet to 
search which has FF FF 00 at the end of it, then it will not find an SOF 
marker in that packet. And if the next packet starts with FF 96, then it 
obviously can not find any SOF marker there, either. And when you fed to 
pac_find_sof() the new packet it is not the business of pac_find_sof() to 
remember that the old packet ended with FF FF 00. So it won't remember 
that. No. Instead, it is up to the programmer who is using pac_find_sof() 
to accunt for this possibility. And if the issue is crucial, fix it. As I 
said, the way to fix it is to keep the last four bytes of the first packet 
and the first four bytes of the second packet, and then search that little 
area separately. If it does not contain any SOF marker, then proceed. If 
it does, then use it. Then and only then, one might indeed be using data 
from the first packet and the second packet at the same time. But if the 
code is written right there is no problem.

>
> Anyways this is just what I understood from the former discussion I have 
> *not*
> looked at the actual code (-ENOTIME)

We all suffer from that, sometimes. Me, too. But if you look at the code 
for pac_find_sof() over in pac_common.h then I strongly suspect that you 
will have to agree with what I said here.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Thomas Kaiser]

kilgota@banach.math.auburn.edu wrote:

> felling->feeling
spelling/writing error (I meant feeling)

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Thomas Kaiser wrote:

> kilgota@banach.math.auburn.edu wrote:
>>>> That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or 
>>>> it could be that only the digits 0 through 9 are actually used, and the 
>>>> basis is then 100, or too many other variations to count. Also what is 
>>>> considered a "normal" or an "average" value? The trouble with your 
>>>> suggestion of a scale from 0 to 0xff is that it makes sense, and in a 
>>>> situation like this one obviously can not assume that.
>>> 
>>> I don't really understand what you try to tell with this sentence:
>>> "and in a situation like this one obviously can not assume that."
>> 
>> I mean, your interpretation of 0 to 0xff is a natural and sensible 
>> interpretation (for us). But what one can not assume is, it made sense to 
>> those who constructed the system. Perhaps those guys were setting it all up 
>> differently.
>
> You are right, we don't know what the developer were thinking, unfortunately,
>
> You have to turn yourself in a webcam developer and think how you would do 
> it. When you find, by observing/testing the cam, that it looks similar as you 
> thought about how to do it, the observation should be true!

True enough. In this respect, there is not much difference between still 
cameras and webcams.

> I will do this again in the next couple of weeks (lens removed).

>>> I believe that this documents are exists, but not available for public:-( 
>>> Just company confidential.
>> 
>> That may be true. If so, then such documentation is indeed not available. 
>> But sometimes a document is published and available, and one just is not 
>> aware of the fact.

I will add to this that a lot of documentation for a lot of things really 
is available to the public.

>> 
>>> 
>>> Anyway most of the Linux webcam drivers were done by re-engineering the 
>>> Windoz driver (usbsnoop). That said, all information about the cams is "a 
>>> guess".
>> 
>> Very true. Also true about the still cameras that I supported in 
>> libgphoto2. There are no secrets kept on the USB bus. But what is done 
>> inside the computer does not appear on the USB bus and there is no log of 
>> it.

I will brag a little bit. Give me any cheap still camera that I don't know 
anything about, and a copy of the Windows driver. Provided only that the 
camera does not use an unknown, proprietary compression algorithm, I will 
promise you a working libgphoto2 driver for it within a week. Compression 
algorithms are the big obstacle there, and the only one.

>>> For the brightness thing, I just was working with a light and studied what 
>>> is changing in the header of the frame. At this time I did this, I was not 
>>> aware that I could remove the lens of the webcam to be more sensible to 
>>> light change and get more precise results.
>>> 
>>> During the work I did for the PAC7311 Pixart chip I found out that 
>>> removing the lens and put light directly to the sensor does help a lot to 
>>> figure out how the cam is working.
>>> 
>>> And with this idea in mind, we could even get further to guess the 
>>> compression algo from a cam.
>>> 
>>> Assuming that the sensor has a Bayer pattern.
>>> - remove lens.
>>> - put white light on the sensor
>>> - use color filter an put each spectrum (RGB) on the sensor
>>> - check the stream and find out what is changing in the stream according 
>>> to the different light conditions.

I would very much like to see this in action.

>>> 
>>> Looks like I get off topic, now ;-)
>> 
>> But it is very interesting nevertheless.
>
> I think so, I didn't try with the color filter :-(
>
>> 
>>> 
>>> Something else comes in my mind. Would it good to document all this what 
>>> we are talking bout somewhere on a webpage?
>>> 
>>> Thomas
>> 
>> Perhaps so. Also a good idea to try to collect some people who have similar 
>> interests and are trying to work on similar problems. I have been trying to 
>> do that for a while, but with mixed and limited success.
>
> May be, some people read this and have the same felling. Let's see what 
> happens.

felling->feeling

We are not chopping down trees. :)


Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Hans de Goede wrote:

>
>
> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Thu, 5 Mar 2009, Hans de Goede wrote:
>> 
>>> 
>>> 
>>> kilgota@banach.math.auburn.edu wrote:
>>>> 
>>>> 
>>>> On Thu, 5 Mar 2009, Hans de Goede wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> Kyle Guinn wrote:
>>>>>> On Wednesday 04 March 2009 22:34:13 kilgota@banach.math.auburn.edu 
>>>>>> wrote:
>>>>>>> On Wed, 4 Mar 2009, Kyle Guinn wrote:
>>>>>>>> On Tuesday 03 March 2009 18:12:33 kilgota@banach.math.auburn.edu 
>>>>>>>> wrote:
>>>>>>>>> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>>>>>>>>> --------------------------------------------------------
>>>>>>>>> --- mr97310a.c.old    2009-02-23 23:59:07.000000000 -0600
>>>>>>>>> +++ mr97310a.c.new    2009-03-03 17:19:06.000000000 -0600
>>>>>>>>> @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
>>>>>>>>>                       data, n);
>>>>>>>>>           sd->header_read = 0;
>>>>>>>>>           gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
>>>>>>>>> -        len -= sof - data;
>>>>>>>>> -        data = sof;
>>>>>>>>> -    }
>>>>>>>>> -    if (sd->header_read < 7) {
>>>>>>>>> -        int needed;
>>>>>>>>> -
>>>>>>>>> -        /* skip the rest of the header */
>>>>>>>>> -        needed = 7 - sd->header_read;
>>>>>>>>> -        if (len <= needed) {
>>>>>>>>> -            sd->header_read += len;
>>>>>>>>> -            return;
>>>>>>>>> -        }
>>>>>>>>> -        data += needed;
>>>>>>>>> -        len -= needed;
>>>>>>>>> -        sd->header_read = 7;
>>>>>>>>> +        /* keep the header, including sof marker, for coming frame 
>>>>>>>>> */
>>>>>>>>> +        len -= n;
>>>>>>>>> +        data = sof - sizeof pac_sof_marker;;
>>>>>>>>>       }
>>>>>>>>>
>>>>>>>>>       gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
>>>>>>>> A few notes:
>>>>>>>> 
>>>>>>>> 1.  There is an extra semicolon on that last added line.
>>>>>>> Oops. My bifocals.
>>>>>>> 
>>>>>>>> 2.  sd->header_read no longer seems necessary.
>>>>>>> This is very likely true.
>>>>>>> 
>>>>>>>> 3.  If the SOF marker is split over two transfers then everything 
>>>>>>>> falls
>>>>>>>> apart.
>>>>>>> Are you sure about that?
>>>>>>> 
>>>>>> 
>>>>>> Simple example:  One transfer ends with FF FF 00 and the next begins 
>>>>>> with FF 96 64.  pac_find_sof() returns a pointer to 64, n is set to 0, 
>>>>>> len stays the same, data now points at 3 bytes _before_ the transfer 
>>>>>> buffer, and we will most likely get undefined behavior when trying to 
>>>>>> copy the data out of the transfer buffer.  Not only that, but the FF FF 
>>>>>> 00 portion of the SOF won't get copied to the frame buffer.
>>>>>> 
>>>>> 
>>>>> Good point, since we will always pass frames to userspace which start 
>>>>> with the
>>>>> sof, maybe we should just only pass the variable part of the header to 
>>>>> userspace?
>>>>> 
>>>>> That sure feels like the easiest solution to me.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Hans
>>>>> 
>>>> 
>>>> Hans, that would not solve the problem. In fact, it appears to me that 
>>>> this problem was already inherent in the driver code before I proposed 
>>>> any patches at all.
>>> 
>>> Erm, if I understood correctly (haven't looked yet) the driver is working
>>> with the sof detection from pac_common, which does work with a SOF split
>>> over multiple frames.
>> 
>> That is not my impression of what the code in pac_common is doing. That 
>> code, as I understand, is totally neutral about such things. What is does 
>> is to parse some data and search for an SOF marker, and if it finds such a 
>> thing then it declares the next byte after to be what it calls "sof". 
>> Specifically, there is the function
>> 
>> static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
>>                                         unsigned char *m, int len)
>> 
>> and what it does is that it searches through unsigned char *m up to the 
>> extent declared in int len, looking for an SOF marker. If it finds one, 
>> then it returns the location of the next byte after the SOF marker has been 
>> successfully read.
>> 
>
> Check that function again, more carefully, if it fails, but finds a part of
> the sof at the end of m it remembers how much of the sof it has already seen
> and continues where it left of the next time it is called.

Well, here is the code in the function. I don't see. So can you explain? 
Perhaps I am dense.

{
         struct sd *sd = (struct sd *) gspca_dev;
         int i;

         /* Search for the SOF marker (fixed part) in the header */
         for (i = 0; i < len; i++) {
                 if (m[i] == pac_sof_marker[sd->sof_read]) {
                         sd->sof_read++;
                         if (sd->sof_read == sizeof(pac_sof_marker)) {
                                 PDEBUG(D_FRAM,
                                         "SOF found, bytes to analyze: %u."
                                         " Frame starts at byte #%u",
                                         len, i + 1);
                                 sd->sof_read = 0;
                                 return m + i + 1;
                         }
                 } else {
                         sd->sof_read = 0;
                 }
         }

         return NULL;
}

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Thursday 05 March 2009 14:58:54 kilgota@banach.math.auburn.edu wrote:
> Well, here is the code in the function. I don't see. So can you explain?
> Perhaps I am dense.
>
> {
>          struct sd *sd = (struct sd *) gspca_dev;
>          int i;
>
>          /* Search for the SOF marker (fixed part) in the header */
>          for (i = 0; i < len; i++) {
>                  if (m[i] == pac_sof_marker[sd->sof_read]) {
>                          sd->sof_read++;
>                          if (sd->sof_read == sizeof(pac_sof_marker)) {
>                                  PDEBUG(D_FRAM,
>                                          "SOF found, bytes to analyze: %u."
>                                          " Frame starts at byte #%u",
>                                          len, i + 1);
>                                  sd->sof_read = 0;
>                                  return m + i + 1;
>                          }
>                  } else {
>                          sd->sof_read = 0;
>                  }
>          }
>
>          return NULL;
> }

We send a chunk of data to this function, as pointed to by m.  It could be the 
entire transfer buffer or only a part of it, but that doesn't matter.  If the 
chunk of data ends with FF FF 00 then sd->sof_read will be set to 3 when the 
function exits.  On the next call it picks up where it left off and looks for 
byte 4 of the SOF.

Way back when, I said to copy sd->sof_read bytes from pac_sof_marker if you 
want the portion of the SOF that was in the previous transfer.  There's no 
need to buffer 4 bytes from the previous transfer because the SOF is 
_constant_.

So, if it's constant, why do we need to copy it to userspace at all?  If we 
do, then every frame buffer begins with a constant, useless FF FF 00 FF 96.  
The "reassurance" doesn't matter because the frame _must_ have started with 
FF FF 00 FF 96 to get there in the first place.  I agree with Hans that it 
isn't necessary, and by not sending it to userspace we simplify the kernel 
driver.

But what if it's not constant?  Maybe the SOF is 4 bytes and the 5th byte is 
some useful data that, 99.9% of the time, is set to 96?  This is the only 
reason I see for keeping the SOF.

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[kilgota]

On Thu, 5 Mar 2009, Kyle Guinn wrote:

> On Thursday 05 March 2009 14:58:54 kilgota@banach.math.auburn.edu wrote:
>> Well, here is the code in the function. I don't see. So can you explain?
>> Perhaps I am dense.
>>
>> {
>>          struct sd *sd = (struct sd *) gspca_dev;
>>          int i;
>>
>>          /* Search for the SOF marker (fixed part) in the header */
>>          for (i = 0; i < len; i++) {
>>                  if (m[i] == pac_sof_marker[sd->sof_read]) {
>>                          sd->sof_read++;
>>                          if (sd->sof_read == sizeof(pac_sof_marker)) {
>>                                  PDEBUG(D_FRAM,
>>                                          "SOF found, bytes to analyze: %u."
>>                                          " Frame starts at byte #%u",
>>                                          len, i + 1);
>>                                  sd->sof_read = 0;
>>                                  return m + i + 1;
>>                          }
>>                  } else {
>>                          sd->sof_read = 0;
>>                  }
>>          }
>>
>>          return NULL;
>> }
>
> We send a chunk of data to this function, as pointed to by m.  It could be the
> entire transfer buffer or only a part of it, but that doesn't matter.  If the
> chunk of data ends with FF FF 00 then sd->sof_read will be set to 3 when the
> function exits.  On the next call it picks up where it left off and looks for
> byte 4 of the SOF.

It took me a while to see this, but, yes. So I agree that something needed 
to be fixed. It is fixed, now. There is a revised patch.

>
> Way back when, I said to copy sd->sof_read bytes from pac_sof_marker if you
> want the portion of the SOF that was in the previous transfer.  There's no
> need to buffer 4 bytes from the previous transfer because the SOF is
> _constant_.

True. So this is the solution which is just now adopted.

>
> So, if it's constant, why do we need to copy it to userspace at all?  If we
> do, then every frame buffer begins with a constant, useless FF FF 00 FF 96.
> The "reassurance" doesn't matter because the frame _must_ have started with
> FF FF 00 FF 96 to get there in the first place.

Unless it was a frame from some other camera. But it could have been a 
frame dumped from some other camera, and then potentially useful 
information for evaluating what it is, would have been lost.

I agree with Hans that it
> isn't necessary, and by not sending it to userspace we simplify the kernel
> driver.

My experience indicates otherwise. One of the reasons for doing this is, 
if one has _all_ of this information it is easier to recognize where it 
came from. What kind of camera. What kind of compression. That kind of 
thing. It then becomes possible to do things such as to look 
at a raw file in total isolation from the streaming app, six months later, 
and to be able to know immediately what kind of camera it came from, and 
all other information relevant for processing it on the spot with a 
program which converts raw data into finished frames or images. If only it 
were possible to embed the width and height, somehow, into the header, 
then my happiness would be total.


>
> But what if it's not constant?  Maybe the SOF is 4 bytes and the 5th byte is
> some useful data that, 99.9% of the time, is set to 96?  This is the only
> reason I see for keeping the SOF.

Very good point. It could happen, couldn't it? It already occurred to me, 
actually. We do not know that it will not happen. For, in such a situation 
we are at the mercy of some other guys who make cameras. So why paint 
oneself into a corner and be sorry later on?

Theodore Kilgore

[PATCH] to add new camera in gspca/mr97310a.c

[Theodore Kilgore]

The purpose of the following patch is to add another camera, with the new 
USB Vendor:Product number 0x093a:0x010f to gspca/mr97310a.c. The camera 
has also been added to the list of supported cameras in 
Documentation/gspca.txt.


Signed-off-by: Theodore Kilgore <kilgota@auburn.edu>
--------------------------------------------------------------------------------
diff -uprN linuxa/Documentation/video4linux/gspca.txt linuxb/Documentation/video4linux/gspca.txt
--- linuxa/Documentation/video4linux/gspca.txt	2009-03-28 11:48:44.000000000 -0500
+++ linuxb/Documentation/video4linux/gspca.txt	2009-03-28 16:12:07.000000000 -0500
@@ -209,6 +209,7 @@ sunplus		08ca:2050	Medion MD 41437
  sunplus		08ca:2060	Aiptek PocketDV5300
  tv8532		0923:010f	ICM532 cams
  mars		093a:050f	Mars-Semi Pc-Camera
+mr97310a	093a:010f	Sakar Digital no. 77379
  pac207		093a:2460	Qtec Webcam 100
  pac207		093a:2461	HP Webcam
  pac207		093a:2463	Philips SPC 220 NC
diff -uprN linuxa/drivers/media/video/gspca/mr97310a.c linuxb/drivers/media/video/gspca/mr97310a.c
--- linuxa/drivers/media/video/gspca/mr97310a.c	2009-03-28 11:48:44.000000000 -0500
+++ linuxb/drivers/media/video/gspca/mr97310a.c	2009-03-28 15:58:59.000000000 -0500
@@ -321,6 +321,7 @@ static const struct sd_desc sd_desc = {
  /* -- module initialisation -- */
  static const __devinitdata struct usb_device_id device_table[] = {
  	{USB_DEVICE(0x08ca, 0x0111)},
+	{USB_DEVICE(0x093a, 0x010f)},
  	{}
  };
  MODULE_DEVICE_TABLE(usb, device_table);

Some questions about mr97310 controls (continuing previous thread on mr97310a.c)

[Theodore Kilgore]

Thomas,

A few questions in the text below.


On Thu, 5 Mar 2009, Thomas Kaiser wrote:

> Hello Theodore
>
> kilgota@banach.math.auburn.edu wrote:
>> 
>> 
>> On Wed, 4 Mar 2009, Thomas Kaiser wrote:
>> As to the actual contents of the header, as you describe things,
>> 
>> 0. Do you have any idea how to account for the discrepancy between
>>
>>>>  From usb snoop.
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>> and
>>>> In Linux the header looks like this:
>>>> 
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>> 
>> (I am referring to the 00 00 as opposed to F0 00)? Or could this have 
>> happened somehow just because these were not two identical sessions?

In case I did not answer this one, I suspect it was probably different 
sessions. I can think of no other explanation which makes sense to me.

>
> Doesn't remember what the differences was. The first is from Windoz 
> (usbsnoop) and the second is from Linux.
>
>> 
>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>> 
>> as I said, this signifies the image format, qua compression algorithm in 
>> use, or if 00 then no compression.
>
> On the PAC207, the compression can be controlled with a register called 
> "Compression Balance size". So, I guess, depending on the value set in the 
> register this value in the header will show what compression level is set.

One of my questions:

Just how does it work to set the "Compression Balance size"? Is this some 
kind of special command sequence? Are we able to set this to whatever we 
want?


>
>> 
>>>> 2. xx: this is the actual pixel clock
>> 
>> So there is a control setting for this?
>
> Yes, in the PAC207, register 2. (12 MHz divided by the value set).
>
>> 
>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (center)
>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (edge)
>>>> 5. xx: set value "Digital Gain of Red"
>>>> 6. xx: set value "Digital Gain of Green"
>>>> 7. xx: set value "Digital Gain of Blue"


Varying some old questions: Precisely what is meant by the value of 
"Digital Gain for XX" where XX is one of Red, Green, or Blue? On what 
scale is this measured? Is is some kind of standardized scale? Or is it 
something which is camera-specific? Also what is does "set" mean in this 
context? This last in view of the fact that this is data which the camera 
provides for our presumed information, not something which we are sending 
to the camera?

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
> Hello Theodore
>
> kilgota@banach.math.auburn.edu wrote:
> > Also, after the byte indicator for the compression algorithm there are
> > some more bytes, and these almost definitely contain information which
> > could be valuable while doing image processing on the output. If they
> > are already kept and passed out of the module over to libv4lconvert,
> > then it would be very easy to do something with those bytes if it is
> > ever figured out precisely what they mean. But if it is not done now it
> > would have to be done then and would cause even more trouble.
>
> I sent it already in private mail to you. Here is the observation I made
> for the PAC207 SOF some years ago:
>
>  From usb snoop.
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
> 1. xx: looks like random value
> 2. xx: changed from 0x03 to 0x0b
> 3. xx: changed from 0x06 to 0x49
> 4. xx: changed from 0x07 to 0x55
> 5. xx: static 0x96
> 6. xx: static 0x80
> 7. xx: static 0xa0
>
> And I did play in Linux and could identify some fields :-) .
> In Linux the header looks like this:
>
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> 1. xx: don't know but value is changing between 0x00 to 0x07
> 2. xx: this is the actual pixel clock
> 3. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (center)
> 4. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (edge)
> 5. xx: set value "Digital Gain of Red"
> 6. xx: set value "Digital Gain of Green"
> 7. xx: set value "Digital Gain of Blue"
>
> Thomas

I've been looking through the frame headers sent by the MR97310A (the Aiptek 
PenCam VGA+, 08ca:0111).  Here are my observations.

FF FF 00 FF 96 6x x0 xx xx xx xx xx

In binary that looks something like this:

11111111 11111111 00000000 11111111
10010110 011001aa a1010000 bbbbbbbb
bbbbbbbb cccccccc ccccdddd dddddddd

All of the values look to be MSbit first.  A looks like a 3-bit frame sequence 
number that seems to start with 1 and increments for each frame.  B, C, and D 
might be brightness and contrast; minimum and maximum values for these vary 
with the image size.

For 640x480, 320x240, and 160x120:
  dark scene (all black):
    B:  near 0
    C:  0x000
    D:  0xC60

  bright scene (all white):
    B:  usually 0xC15C
    C:  0xC60
    D:  0x000

For 352x288 and 176x144:
  dark scene (all black):
    B:  near 0
    C:  0x000
    D:  0xB5B

  bright scene (all white):
    B:  usually 0xB0FE
    C:  0xB53
    D:  0x007

B increases with increasing brightness.  C increases with more white pixels 
and D increases with more black pixels.  A gray image has C and D near zero, 
while a high-contrast image (half black, half white) has C and D around 0x600 
or so.  The sum of C and D is not a constant.

I don't know how brightness and contrast are handled in V4L.  Hopefully 
someone can put this to use.
-Kyle

Re: Some questions about mr97310 controls (continuing previous thread on mr97310a.c)

[Thomas Kaiser]

Hello Theodore

My answers/comments inline .....

On 04/16/2009 01:59 AM, Theodore Kilgore wrote:
> 
> 
> Thomas,
> 
> A few questions in the text below.
> 
> 
> On Thu, 5 Mar 2009, Thomas Kaiser wrote:
> 
>> Hello Theodore
>>
>> kilgota@banach.math.auburn.edu wrote:
>>>
>>>
>>> On Wed, 4 Mar 2009, Thomas Kaiser wrote:
>>> As to the actual contents of the header, as you describe things,
>>>
>>> 0. Do you have any idea how to account for the discrepancy between
>>>
>>>>>  From usb snoop.
>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>> and
>>>>> In Linux the header looks like this:
>>>>>
>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>
>>> (I am referring to the 00 00 as opposed to F0 00)? Or could this have 
>>> happened somehow just because these were not two identical sessions?
> 
> In case I did not answer this one, I suspect it was probably different 
> sessions. I can think of no other explanation which makes sense to me.
> 
>>
>> Doesn't remember what the differences was. The first is from Windoz 
>> (usbsnoop) and the second is from Linux.
>>
>>>
>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>
>>> as I said, this signifies the image format, qua compression algorithm 
>>> in use, or if 00 then no compression.
>>
>> On the PAC207, the compression can be controlled with a register 
>> called "Compression Balance size". So, I guess, depending on the value 
>> set in the register this value in the header will show what 
>> compression level is set.
> 
> One of my questions:
> 
> Just how does it work to set the "Compression Balance size"? Is this 
> some kind of special command sequence? Are we able to set this to 
> whatever we want?

It looks like. One can set a value from 0x0 to 0xff in the "Compression 
Balance size" register (reg 0x4a).
In the pac207 Linux driver, this register is set to 0xff to turn off the 
compression. While we use compression 0x88 is set (I think the same 
value like in Windoz). Hans did play with this register and found out 
that the compression changes with different values.

Hans, may you explain a bit more what you found out?

> 
> 
>>
>>>
>>>>> 2. xx: this is the actual pixel clock
>>>
>>> So there is a control setting for this?
>>
>> Yes, in the PAC207, register 2. (12 MHz divided by the value set).
>>
>>>
>>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>>> 0xfc (bright) (center)
>>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>>> 0xfc (bright) (edge)
>>>>> 5. xx: set value "Digital Gain of Red"
>>>>> 6. xx: set value "Digital Gain of Green"
>>>>> 7. xx: set value "Digital Gain of Blue"
> 
> 
> Varying some old questions: Precisely what is meant by the value of 
> "Digital Gain for XX" where XX is one of Red, Green, or Blue? On what 
> scale is this measured? Is is some kind of standardized scale? Or is it 
> something which is camera-specific? Also what is does "set" mean in this 
> context? This last in view of the fact that this is data which the 
> camera provides for our presumed information, not something which we are 
> sending to the camera?

When I recall correctly, I just saw that this fields in the header have 
the same value which I set in the "digital gain of Red/Green/Blue" 
registers. Therefor, I called it "set" value. But I don't remember if a 
change of these registers had any impact on the picture.

The range for these registers is from 0x0 to 0xff but as I don't know 
what they do, I don't know any more :-(

Thomas

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Theodore Kilgore]

On Thu, 16 Apr 2009, Kyle Guinn wrote:

> On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
>> Hello Theodore
>>
>> kilgota@banach.math.auburn.edu wrote:
>>> Also, after the byte indicator for the compression algorithm there are
>>> some more bytes, and these almost definitely contain information which
>>> could be valuable while doing image processing on the output. If they
>>> are already kept and passed out of the module over to libv4lconvert,
>>> then it would be very easy to do something with those bytes if it is
>>> ever figured out precisely what they mean. But if it is not done now it
>>> would have to be done then and would cause even more trouble.
>>
>> I sent it already in private mail to you. Here is the observation I made
>> for the PAC207 SOF some years ago:
>>
>>  From usb snoop.
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>> 1. xx: looks like random value
>> 2. xx: changed from 0x03 to 0x0b
>> 3. xx: changed from 0x06 to 0x49
>> 4. xx: changed from 0x07 to 0x55
>> 5. xx: static 0x96
>> 6. xx: static 0x80
>> 7. xx: static 0xa0
>>
>> And I did play in Linux and could identify some fields :-) .
>> In Linux the header looks like this:
>>
>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>> 1. xx: don't know but value is changing between 0x00 to 0x07
>> 2. xx: this is the actual pixel clock
>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (center)
>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>> 0xfc (bright) (edge)
>> 5. xx: set value "Digital Gain of Red"
>> 6. xx: set value "Digital Gain of Green"
>> 7. xx: set value "Digital Gain of Blue"
>>
>> Thomas
>
> I've been looking through the frame headers sent by the MR97310A (the Aiptek
> PenCam VGA+, 08ca:0111).  Here are my observations.
>
> FF FF 00 FF 96 6x x0 xx xx xx xx xx
>
> In binary that looks something like this:
>
> 11111111 11111111 00000000 11111111
> 10010110 011001aa a1010000 bbbbbbbb
> bbbbbbbb cccccccc ccccdddd dddddddd
>
> All of the values look to be MSbit first.  A looks like a 3-bit frame sequence
> number that seems to start with 1 and increments for each frame.

Hmmm. This I never noticed. What you are saying is that the two bytes 6x 
and x0 are variable? You are sure about that? What I have previously 
experienced is that the first is always 64 with these cameras, and the 
second one indicates the absence of compression (in which case it is 0, 
which of course only arises for still cameras), or if there is data 
compression then it is not zero. I have never seen this byte to change 
during a session with a camera. Here is a little table of what I have 
previously witnessed, and perhaps you can suggest what to do in order to 
see this is not happening:

Camera		that byte	compression	solved, or not	streaming
Aiptek 		00		no		N/A		no
Aiptek		50		yes		yes		both
the Sakar cam	00		no		N/A		no
ditto		50		yes		yes		both
Argus QuikClix	20		yes		no	doesn't work
Argus DC1620	50		yes		yes	doesn't work 
CIF cameras	00		no		N/A		no
ditto		50		yes		yes		no
ditto		d0		yes		no		yes

Other strange facts are

-- that the Sakar camera, the Argus QuikClix, and the 
DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them 
will stream with the existing driver. The other two go through the 
motions, but the isoc packets do not actually get sent, so there is no 
image coming out. I do not understand the reason for this; I have been 
trying to figure it out and it is rather weird. I should add that, yes, 
those two cameras were said to be capable of streaming when I bought them. 
Could it be a problem of age? I don't expect that, but maybe.

-- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several 
of them) and they all are using a different compression algorithm while 
streaming from what they use if running as still cameras in compressed 
mode. This leads to the question whether it is possible to set the 
compression algorithm during the initialization sequence, so that the 
camera also uses the "0x50" mode while streaming, because we already know 
how to use that mode.

But I have never seen the 0x64 0xX0 bytes used to count the frames. Could 
you tell me how to repeat that? It certainly would knock down the validity 
of the above table wouldn't it?

B, C, and D
> might be brightness and contrast; minimum and maximum values for these vary
> with the image size.
>
> For 640x480, 320x240, and 160x120:
>  dark scene (all black):
>    B:  near 0
>    C:  0x000
>    D:  0xC60
>
>  bright scene (all white):
>    B:  usually 0xC15C
>    C:  0xC60
>    D:  0x000
>
> For 352x288 and 176x144:
>  dark scene (all black):
>    B:  near 0
>    C:  0x000
>    D:  0xB5B
>
>  bright scene (all white):
>    B:  usually 0xB0FE
>    C:  0xB53
>    D:  0x007
>
> B increases with increasing brightness.  C increases with more white pixels
> and D increases with more black pixels.  A gray image has C and D near zero,
> while a high-contrast image (half black, half white) has C and D around 0x600
> or so.  The sum of C and D is not a constant.

Yes, in crude outlines of course I already understood that something of 
this sort is happening. That is, after all, the prime reason why I came 
along with a patch which preserves the header and passes it along 
instead of tossing it out with the trash. My question was whether anyone 
knows more about this, or whether some kind of standard (not 
vendor-specific or chipset-specific) format is involved there, and in 
particular what was meant by the description of these as Red, Green or 
Blue "Gain" settings.

>
> I don't know how brightness and contrast are handled in V4L.  Hopefully
> someone can put this to use.
> -Kyle
>

This is something which is up to V4L, of course. But I have been 
interested for a long time in these cameras as still cameras. And the 
headers there look just about the same and obviously pass along the same 
kind of information.

I might also mention that one of the things I did about a year ago was to 
introduce some brightness, color balance and contrast setting routines in 
several of my still camera drivers, including specifically the 
camlibs/mars driver which supports these particular cameras. Those 
routines work by analysing the data in the photo (frame) and then doing 
certain changes. The routines rely only slightly on input such as these 
mysterious bytes we are discussing here, because I do not know enough 
about these mysterious bytes. The routines do give significantly better 
imaging results. I do not know if they would be too time-consuming to use 
in V4L. Possibly, they would. I have run no analysis on the routines, 
regarding speed. If you want to look at those routines and try them out on 
raw test images, then you can find a standalone raw converter in the 
directory playground/raw_converters/mars, on the Gphoto SVN site. Since 
you are interested in the MR97310a cameras, you might be interested in 
that.

Theodore Kilgore

Re: Some questions about mr97310 controls (continuing previous thread on mr97310a.c)

[Theodore Kilgore]

On Thu, 16 Apr 2009, Thomas Kaiser wrote:

> Hello Theodore
>
> My answers/comments inline .....

Mine, too. I will also cut out some currently non-interesting parts, in 
the interest of saving space.


>
> On 04/16/2009 01:59 AM, Theodore Kilgore wrote:
>> 
>> 
>> Thomas,
>> 
>> A few questions in the text below.
>> 
>> 
>> On Thu, 5 Mar 2009, Thomas Kaiser wrote:
>> 
>>> Hello Theodore
>>> 
>>> kilgota@banach.math.auburn.edu wrote:

>>>>>>  From usb snoop.
>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>> and
>>>>>> In Linux the header looks like this:
>>>>>> 
>>>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00

>>>> 
>>>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>> 
>>>> as I said, this signifies the image format, qua compression algorithm in 
>>>> use, or if 00 then no compression.
>>> 
>>> On the PAC207, the compression can be controlled with a register called 
>>> "Compression Balance size". So, I guess, depending on the value set in the 
>>> register this value in the header will show what compression level is set.
>> 
>> One of my questions:
>> 
>> Just how does it work to set the "Compression Balance size"? Is this some 
>> kind of special command sequence? Are we able to set this to whatever we 
>> want?
>
> It looks like. One can set a value from 0x0 to 0xff in the "Compression 
> Balance size" register (reg 0x4a).
> In the pac207 Linux driver, this register is set to 0xff to turn off the 
> compression. While we use compression 0x88 is set (I think the same value 
> like in Windoz). Hans did play with this register and found out that the 
> compression changes with different values.

I wonder how this relates to the mr97310a. There is no such register 
present, that I can see.

>
> Hans, may you explain a bit more what you found out?

(Yes, please.)

>>>>>> 2. xx: this is the actual pixel clock
>>>> 
>>>> So there is a control setting for this?
>>> 
>>> Yes, in the PAC207, register 2. (12 MHz divided by the value set).

Again, I wonder how this might translate for the mr97310a ...

The following is pretty much the same, it seems.

>>>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>>>> 0xfc (bright) (center)
>>>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>>>> 0xfc (bright) (edge)
>>>>>> 5. xx: set value "Digital Gain of Red"
>>>>>> 6. xx: set value "Digital Gain of Green"
>>>>>> 7. xx: set value "Digital Gain of Blue"
>> 
>> 
>> Varying some old questions: Precisely what is meant by the value of 
>> "Digital Gain for XX" where XX is one of Red, Green, or Blue? On what scale 
>> is this measured? Is is some kind of standardized scale? Or is it something 
>> which is camera-specific? Also what is does "set" mean in this context? 
>> This last in view of the fact that this is data which the camera provides 
>> for our presumed information, not something which we are sending to the 
>> camera?
>
> When I recall correctly, I just saw that this fields in the header have the 
> same value which I set in the "digital gain of Red/Green/Blue" registers. 
> Therefor, I called it "set" value. But I don't remember if a change of these 
> registers had any impact on the picture.

Hmmm. My experience is that these settings depend purely on the frame, and 
whether the camera is pointed at something bright or something dark, that 
kind of thing. Thus my idea was to try to use the information, somehow, in 
a constructive way. It never occurred to me, actually, that it is possible 
to "set" these things by issuing commands to a camera. But what do I know?

>
> The range for these registers is from 0x0 to 0xff but as I don't know what 
> they do, I don't know any more :-(

Yes, that I can understand.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> > On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
> >> Hello Theodore
> >>
> >> kilgota@banach.math.auburn.edu wrote:
> >>> Also, after the byte indicator for the compression algorithm there are
> >>> some more bytes, and these almost definitely contain information which
> >>> could be valuable while doing image processing on the output. If they
> >>> are already kept and passed out of the module over to libv4lconvert,
> >>> then it would be very easy to do something with those bytes if it is
> >>> ever figured out precisely what they mean. But if it is not done now it
> >>> would have to be done then and would cause even more trouble.
> >>
> >> I sent it already in private mail to you. Here is the observation I made
> >> for the PAC207 SOF some years ago:
> >>
> >>  From usb snoop.
> >> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
> >> 1. xx: looks like random value
> >> 2. xx: changed from 0x03 to 0x0b
> >> 3. xx: changed from 0x06 to 0x49
> >> 4. xx: changed from 0x07 to 0x55
> >> 5. xx: static 0x96
> >> 6. xx: static 0x80
> >> 7. xx: static 0xa0
> >>
> >> And I did play in Linux and could identify some fields :-) .
> >> In Linux the header looks like this:
> >>
> >> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> >> 1. xx: don't know but value is changing between 0x00 to 0x07
> >> 2. xx: this is the actual pixel clock
> >> 3. xx: this is changing according light conditions from 0x03 (dark) to
> >> 0xfc (bright) (center)
> >> 4. xx: this is changing according light conditions from 0x03 (dark) to
> >> 0xfc (bright) (edge)
> >> 5. xx: set value "Digital Gain of Red"
> >> 6. xx: set value "Digital Gain of Green"
> >> 7. xx: set value "Digital Gain of Blue"
> >>
> >> Thomas
> >
> > I've been looking through the frame headers sent by the MR97310A (the
> > Aiptek PenCam VGA+, 08ca:0111).  Here are my observations.
> >
> > FF FF 00 FF 96 6x x0 xx xx xx xx xx
> >
> > In binary that looks something like this:
> >
> > 11111111 11111111 00000000 11111111
> > 10010110 011001aa a1010000 bbbbbbbb
> > bbbbbbbb cccccccc ccccdddd dddddddd
> >
> > All of the values look to be MSbit first.  A looks like a 3-bit frame
> > sequence number that seems to start with 1 and increments for each frame.
>
> Hmmm. This I never noticed. What you are saying is that the two bytes 6x
> and x0 are variable? You are sure about that? What I have previously
> experienced is that the first is always 64 with these cameras, and the
> second one indicates the absence of compression (in which case it is 0,
> which of course only arises for still cameras), or if there is data
> compression then it is not zero. I have never seen this byte to change
> during a session with a camera. Here is a little table of what I have
> previously witnessed, and perhaps you can suggest what to do in order to
> see this is not happening:
>
> Camera		that byte	compression	solved, or not	streaming
> Aiptek 		00		no		N/A		no
> Aiptek		50		yes		yes		both
> the Sakar cam	00		no		N/A		no
> ditto		50		yes		yes		both
> Argus QuikClix	20		yes		no	doesn't work
> Argus DC1620	50		yes		yes	doesn't work
> CIF cameras	00		no		N/A		no
> ditto		50		yes		yes		no
> ditto		d0		yes		no		yes
>
> Other strange facts are
>
> -- that the Sakar camera, the Argus QuikClix, and the
> DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them
> will stream with the existing driver. The other two go through the
> motions, but the isoc packets do not actually get sent, so there is no
> image coming out. I do not understand the reason for this; I have been
> trying to figure it out and it is rather weird. I should add that, yes,
> those two cameras were said to be capable of streaming when I bought them.
> Could it be a problem of age? I don't expect that, but maybe.
>
> -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several
> of them) and they all are using a different compression algorithm while
> streaming from what they use if running as still cameras in compressed
> mode. This leads to the question whether it is possible to set the
> compression algorithm during the initialization sequence, so that the
> camera also uses the "0x50" mode while streaming, because we already know
> how to use that mode.
>
> But I have never seen the 0x64 0xX0 bytes used to count the frames. Could
> you tell me how to repeat that? It certainly would knock down the validity
> of the above table wouldn't it?
>

I've modified libv4l to print out the 12-byte header before it skips over it.  
Then when I fire up mplayer it prints out each header as each frame is 
received.  The framerate is only about 5 fps so there isn't a ton of data to 
parse through.  When I point the camera into a light I get this (at 640x480):

...
ff ff 00 ff 96 64 d0 c1 5c c6 00 00 
ff ff 00 ff 96 65 50 c1 5c c6 00 00 
ff ff 00 ff 96 65 d0 c1 5c c6 00 00 
ff ff 00 ff 96 66 50 c1 5c c6 00 00 
ff ff 00 ff 96 66 d0 c1 5c c6 00 00 
ff ff 00 ff 96 67 50 c1 5c c6 00 00 
ff ff 00 ff 96 67 d0 c1 5c c6 00 00 
ff ff 00 ff 96 64 50 c1 5c c6 00 00 
ff ff 00 ff 96 64 d0 c1 5c c6 00 00 
ff ff 00 ff 96 65 50 c1 5c c6 00 00
...

Only those 3 bits change, and it looks like a counter to me.  Take a look at 
the gspca-mars (MR97113A?) subdriver.  I think it tries to accommodate the 
frame sequence number when looking for the SOF.

Maybe all or part of the 7 bytes between A and B specify the compression?  
That explains all but the last row of your table since (0xd0 & 0x7f) == 0x50.  
Double-check that it's actually d0 if you can, and that it is a constant d0 
unlike the toggling between 50 and d0 above.

For your cameras that aren't streaming anything, do they stream in Windows?  
If so, have you tried snooping the USB traffic?  I'm curious if their drivers 
use a slightly different initialization sequence, or if some of the 
initialization data varies between runs.  I know some of the initialization 
data varied between runs for the pencam, and I don't know what kind of effect 
it has on the camera.

-Kyle

Re: Some questions about mr97310 controls (continuing previous thread on mr97310a.c)

[Hans de Goede]

Hi All,

On 04/17/2009 12:50 AM, Theodore Kilgore wrote:
>
>
> On Thu, 16 Apr 2009, Thomas Kaiser wrote:
>

<snip>

>>>
>>> Just how does it work to set the "Compression Balance size"? Is this
>>> some kind of special command sequence? Are we able to set this to
>>> whatever we want?
>>
>> It looks like. One can set a value from 0x0 to 0xff in the
>> "Compression Balance size" register (reg 0x4a).
>> In the pac207 Linux driver, this register is set to 0xff to turn off
>> the compression. While we use compression 0x88 is set (I think the
>> same value like in Windoz). Hans did play with this register and found
>> out that the compression changes with different values.
>
> I wonder how this relates to the mr97310a. There is no such register
> present, that I can see.
>
>>
>> Hans, may you explain a bit more what you found out?
>
> (Yes, please.)
>

Quoting from linux/drivers/media/video/gspca/pac207.c
(easiest for me as it has been a while I looked at this):

/* An exposure value of 4 also works (3 does not) but then we need to lower
    the compression balance setting when in 352x288 mode, otherwise the usb
    bandwidth is not enough and packets get dropped resulting in corrupt
    frames. The problem with this is that when the compression balance gets
    lowered below 0x80, the pac207 starts using a different compression
    algorithm for some lines, these lines get prefixed with a 0x2dd2 prefix
    and currently we do not know how to decompress these lines, so for now
    we use a minimum exposure value of 5 */
#define PAC207_EXPOSURE_MIN             5
#define PAC207_EXPOSURE_MAX             26

And from libv4l/libv4lconvert/pac207.c:


void v4lconvert_decode_pac207(const unsigned char *inp, unsigned char *outp,
   int width, int height)
{
/* we should received a whole frame with header and EOL marker
in myframe->data and return a GBRG pattern in frame->tmpbuffer
remove the header then copy line by line EOL is set with 0x0f 0xf0 marker
or 0x1e 0xe1 for compressed line*/
     unsigned short word;
     int row;

     /* iterate over all rows */
     for (row = 0; row < height; row++) {
         word = getShort(inp);
         switch (word) {
         case 0x0FF0:
             memcpy(outp, inp + 2, width);
             inp += (2 + width);
             break;
         case 0x1EE1:
             inp += pac_decompress_row(inp, outp, width);
             break;
         case 0x2DD2: /* prefix for "stronger" compressed lines, currently the
                         kernel driver programs the cam so that we should not
                         get any of these */

         default: /* corrupt frame */
             /* FIXME add error reporting */
             return;
         }
         outp += width;
     }



So iow, the pac207 prefixes each row of a frame it sends out with 2 bytes,
indication the type of compression used, 0FF0 == no compression,
1ee1 == compression currently known in libv4l

But if you lower the compression balance register below 0x80, it will also
send out rows prefixed with 2DD2, and we (I) have no clue how to decompress
these. If we could find out how to handle these, that would be great, as we
then could lower the exposure time more when in full daylight, curing the
over exposure problems we have in full daylight.

Regards,

Hans

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Theodore Kilgore]

On Thu, 16 Apr 2009, Kyle Guinn wrote:

> On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
>> On Thu, 16 Apr 2009, Kyle Guinn wrote:
>>> On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
>>>> Hello Theodore
>>>>
>>>> kilgota@banach.math.auburn.edu wrote:
>>>>> Also, after the byte indicator for the compression algorithm there are
>>>>> some more bytes, and these almost definitely contain information which
>>>>> could be valuable while doing image processing on the output. If they
>>>>> are already kept and passed out of the module over to libv4lconvert,
>>>>> then it would be very easy to do something with those bytes if it is
>>>>> ever figured out precisely what they mean. But if it is not done now it
>>>>> would have to be done then and would cause even more trouble.
>>>>
>>>> I sent it already in private mail to you. Here is the observation I made
>>>> for the PAC207 SOF some years ago:
>>>>
>>>>  From usb snoop.
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
>>>> 1. xx: looks like random value
>>>> 2. xx: changed from 0x03 to 0x0b
>>>> 3. xx: changed from 0x06 to 0x49
>>>> 4. xx: changed from 0x07 to 0x55
>>>> 5. xx: static 0x96
>>>> 6. xx: static 0x80
>>>> 7. xx: static 0xa0
>>>>
>>>> And I did play in Linux and could identify some fields :-) .
>>>> In Linux the header looks like this:
>>>>
>>>> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
>>>> 1. xx: don't know but value is changing between 0x00 to 0x07
>>>> 2. xx: this is the actual pixel clock
>>>> 3. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (center)
>>>> 4. xx: this is changing according light conditions from 0x03 (dark) to
>>>> 0xfc (bright) (edge)
>>>> 5. xx: set value "Digital Gain of Red"
>>>> 6. xx: set value "Digital Gain of Green"
>>>> 7. xx: set value "Digital Gain of Blue"
>>>>
>>>> Thomas
>>>
>>> I've been looking through the frame headers sent by the MR97310A (the
>>> Aiptek PenCam VGA+, 08ca:0111).  Here are my observations.
>>>
>>> FF FF 00 FF 96 6x x0 xx xx xx xx xx
>>>
>>> In binary that looks something like this:
>>>
>>> 11111111 11111111 00000000 11111111
>>> 10010110 011001aa a1010000 bbbbbbbb
>>> bbbbbbbb cccccccc ccccdddd dddddddd
>>>
>>> All of the values look to be MSbit first.  A looks like a 3-bit frame
>>> sequence number that seems to start with 1 and increments for each frame.
>>
>> Hmmm. This I never noticed. What you are saying is that the two bytes 6x
>> and x0 are variable? You are sure about that? What I have previously
>> experienced is that the first is always 64 with these cameras, and the
>> second one indicates the absence of compression (in which case it is 0,
>> which of course only arises for still cameras), or if there is data
>> compression then it is not zero. I have never seen this byte to change
>> during a session with a camera. Here is a little table of what I have
>> previously witnessed, and perhaps you can suggest what to do in order to
>> see this is not happening:
>>
>> Camera		that byte	compression	solved, or not	streaming
>> Aiptek 		00		no		N/A		no
>> Aiptek		50		yes		yes		both
>> the Sakar cam	00		no		N/A		no
>> ditto		50		yes		yes		both
>> Argus QuikClix	20		yes		no	doesn't work
>> Argus DC1620	50		yes		yes	doesn't work
>> CIF cameras	00		no		N/A		no
>> ditto		50		yes		yes		no
>> ditto		d0		yes		no		yes
>>
>> Other strange facts are
>>
>> -- that the Sakar camera, the Argus QuikClix, and the
>> DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them
>> will stream with the existing driver. The other two go through the
>> motions, but the isoc packets do not actually get sent, so there is no
>> image coming out. I do not understand the reason for this; I have been
>> trying to figure it out and it is rather weird. I should add that, yes,
>> those two cameras were said to be capable of streaming when I bought them.
>> Could it be a problem of age? I don't expect that, but maybe.
>>
>> -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several
>> of them) and they all are using a different compression algorithm while
>> streaming from what they use if running as still cameras in compressed
>> mode. This leads to the question whether it is possible to set the
>> compression algorithm during the initialization sequence, so that the
>> camera also uses the "0x50" mode while streaming, because we already know
>> how to use that mode.
>>
>> But I have never seen the 0x64 0xX0 bytes used to count the frames. Could
>> you tell me how to repeat that? It certainly would knock down the validity
>> of the above table wouldn't it?
>>
>
> I've modified libv4l to print out the 12-byte header before it skips over it.

Good idea, and an obvious one. Why did I not think of that?

> Then when I fire up mplayer it prints out each header as each frame is
> received.  The framerate is only about 5 fps so there isn't a ton of data to
> parse through.  When I point the camera into a light I get this (at 640x480):
>
> ...
> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
> ff ff 00 ff 96 65 50 c1 5c c6 00 00
> ff ff 00 ff 96 65 d0 c1 5c c6 00 00
> ff ff 00 ff 96 66 50 c1 5c c6 00 00
> ff ff 00 ff 96 66 d0 c1 5c c6 00 00
> ff ff 00 ff 96 67 50 c1 5c c6 00 00
> ff ff 00 ff 96 67 d0 c1 5c c6 00 00
> ff ff 00 ff 96 64 50 c1 5c c6 00 00
> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
> ff ff 00 ff 96 65 50 c1 5c c6 00 00
> ...

Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try 
it, too, because I also have one of them.

>
> Only those 3 bits change, and it looks like a counter to me.  Take a look at
> the gspca-mars (MR97113A?) subdriver.  I think it tries to accommodate the
> frame sequence number when looking for the SOF.

No, I don't see that, sorry. What I see is that it looks for the SOF, 
which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and 
no more bytes after that.

>
> Maybe all or part of the 7 bytes between A and B specify the compression?
> That explains all but the last row of your table since (0xd0 & 0x7f) == 0x50.
> Double-check that it's actually d0 if you can, and that it is a constant d0
> unlike the toggling between 50 and d0 above.
>
> For your cameras that aren't streaming anything, do they stream in Windows?
> If so, have you tried snooping the USB traffic?  I'm curious if their drivers
> use a slightly different initialization sequence, or if some of the
> initialization data varies between runs.  I know some of the initialization
> data varied between runs for the pencam, and I don't know what kind of effect
> it has on the camera.

Me, too, I am curious. But I have had increasing trouble with Windows, and 
with the installation of the drivers. I have 3 machines for that. The 
oldest is a dual-boot Linux and Win98 box. If I want to install a driver 
over there I have to move it over on a USB stick. To get the machine to 
read a USB stick, it has to be booted in Linux. Also to get the log file 
off it, afterwards. All of this because Win98 does not recognize a 
standard device by its class, only if a driver specifically for it has 
been installed. There are also registry problems because I have done too 
many installs on it. Also it is possible to do an install of a driver, but 
apparently there is no streaming app. So I can diagnose things with still 
cameras (which I no longer need to do) but the streaming will not work. 
The streaming apps which came with those cameras, it seems that I no 
longer have or I can not find the old CD and make a definite match with 
the old camera. Then there is a Win2K box. Similar story. Then there is a 
discarded HP laptop of my youngest son, which he says had a buggy Broadcom 
wireless card in it which was frying the motherboard. It runs Vista. 
It is flaky. But I thought it might have some kind of generic streaming 
app installed. The last experience I had with it is I tried to install the 
driver for the Argus DC-1620, hoping to be able to get some sniffs. The 
machine would not accept the driver. On rebooting, it attempted to do a 
systematic check of the entire installation, which it claimed was now 
"corrupted" and finally announced after 30 minutes of looking for its 
nuts, that I had installed a bad hardware driver. Well, I guess that I 
need to try again, but my more recent experiences with that other OS, in 
its variations, have been time-consuming, unpleasant, and fruitless. This 
is all getting a bit off topic, but perhaps it will encourage others to be 
even more grateful for having Linux.

I will continue to look into these things, because there are unresolved 
mysteries. Thanks for your log of the headers. I will definitely check 
that out.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn]

On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> > On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
> >> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> >>> I've been looking through the frame headers sent by the MR97310A (the
> >>> Aiptek PenCam VGA+, 08ca:0111).  Here are my observations.
> >>>
> >>> FF FF 00 FF 96 6x x0 xx xx xx xx xx
> >>>
> >>> In binary that looks something like this:
> >>>
> >>> 11111111 11111111 00000000 11111111
> >>> 10010110 011001aa a1010000 bbbbbbbb
> >>> bbbbbbbb cccccccc ccccdddd dddddddd
> >>>
> >>> All of the values look to be MSbit first.  A looks like a 3-bit frame
> >>> sequence number that seems to start with 1 and increments for each
> >>> frame.
> >>
> >> Hmmm. This I never noticed. What you are saying is that the two bytes 6x
> >> and x0 are variable? You are sure about that? What I have previously
> >> experienced is that the first is always 64 with these cameras, and the
> >> second one indicates the absence of compression (in which case it is 0,
> >> which of course only arises for still cameras), or if there is data
> >> compression then it is not zero. I have never seen this byte to change
> >> during a session with a camera. Here is a little table of what I have
> >> previously witnessed, and perhaps you can suggest what to do in order to
> >> see this is not happening:
> >>
> >> Camera		that byte	compression	solved, or not	streaming
> >> Aiptek 		00		no		N/A		no
> >> Aiptek		50		yes		yes		both
> >> the Sakar cam	00		no		N/A		no
> >> ditto		50		yes		yes		both
> >> Argus QuikClix	20		yes		no	doesn't work
> >> Argus DC1620	50		yes		yes	doesn't work
> >> CIF cameras	00		no		N/A		no
> >> ditto		50		yes		yes		no
> >> ditto		d0		yes		no		yes
> >>
> >> Other strange facts are
> >>
> >> -- that the Sakar camera, the Argus QuikClix, and the
> >> DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of
> >> them will stream with the existing driver. The other two go through the
> >> motions, but the isoc packets do not actually get sent, so there is no
> >> image coming out. I do not understand the reason for this; I have been
> >> trying to figure it out and it is rather weird. I should add that, yes,
> >> those two cameras were said to be capable of streaming when I bought
> >> them. Could it be a problem of age? I don't expect that, but maybe.
> >>
> >> -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought
> >> several of them) and they all are using a different compression
> >> algorithm while streaming from what they use if running as still cameras
> >> in compressed mode. This leads to the question whether it is possible to
> >> set the compression algorithm during the initialization sequence, so
> >> that the camera also uses the "0x50" mode while streaming, because we
> >> already know how to use that mode.
> >>
> >> But I have never seen the 0x64 0xX0 bytes used to count the frames.
> >> Could you tell me how to repeat that? It certainly would knock down the
> >> validity of the above table wouldn't it?
> >
> > I've modified libv4l to print out the 12-byte header before it skips over
> > it.
>
> Good idea, and an obvious one. Why did I not think of that?
>
> > Then when I fire up mplayer it prints out each header as each frame is
> > received.  The framerate is only about 5 fps so there isn't a ton of data
> > to parse through.  When I point the camera into a light I get this (at
> > 640x480):
> >
> > ...
> > ff ff 00 ff 96 64 d0 c1 5c c6 00 00
> > ff ff 00 ff 96 65 50 c1 5c c6 00 00
> > ff ff 00 ff 96 65 d0 c1 5c c6 00 00
> > ff ff 00 ff 96 66 50 c1 5c c6 00 00
> > ff ff 00 ff 96 66 d0 c1 5c c6 00 00
> > ff ff 00 ff 96 67 50 c1 5c c6 00 00
> > ff ff 00 ff 96 67 d0 c1 5c c6 00 00
> > ff ff 00 ff 96 64 50 c1 5c c6 00 00
> > ff ff 00 ff 96 64 d0 c1 5c c6 00 00
> > ff ff 00 ff 96 65 50 c1 5c c6 00 00
> > ...
>
> Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
> it, too, because I also have one of them.
>

Yes, that's the one.  Try your others if you can and let me know what happens.

> > Only those 3 bits change, and it looks like a counter to me.  Take a look
> > at the gspca-mars (MR97113A?) subdriver.  I think it tries to accommodate
> > the frame sequence number when looking for the SOF.
>
> No, I don't see that, sorry. What I see is that it looks for the SOF,
> which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and
> no more bytes after that.
>

I'm talking about this code from gspca/mars.c.  Look in sd_pkt_scan().

if (data[0 + p] == 0xff
 && data[1 + p] == 0xff
 && data[2 + p] == 0x00
 && data[3 + p] == 0xff
 && data[4 + p] == 0x96) {
	if (data[5 + p] == 0x64
	 || data[5 + p] == 0x65
	 || data[5 + p] == 0x66
	 || data[5 + p] == 0x67) {

-Kyle

Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Theodore Kilgore]

On Fri, 17 Apr 2009, Kyle Guinn wrote:

> On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
>> On Thu, 16 Apr 2009, Kyle Guinn wrote:
>>> On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
>>>> On Thu, 16 Apr 2009, Kyle Guinn wrote:

<snip>

>>> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 66 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 66 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 67 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 67 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 64 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 50 c1 5c c6 00 00
>>> ...
>>
>> Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
>> it, too, because I also have one of them.
>>
>
> Yes, that's the one.  Try your others if you can and let me know what happens.

OK. I will.

>
>>> Only those 3 bits change, and it looks like a counter to me.  Take a look
>>> at the gspca-mars (MR97113A?) subdriver.  I think it tries to accommodate
>>> the frame sequence number when looking for the SOF.
>>
>> No, I don't see that, sorry. What I see is that it looks for the SOF,
>> which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and
>> no more bytes after that.
>>
>
> I'm talking about this code from gspca/mars.c.  Look in sd_pkt_scan().
>
> if (data[0 + p] == 0xff
> && data[1 + p] == 0xff
> && data[2 + p] == 0x00
> && data[3 + p] == 0xff
> && data[4 + p] == 0x96) {
> 	if (data[5 + p] == 0x64
> 	 || data[5 + p] == 0x65
> 	 || data[5 + p] == 0x66
> 	 || data[5 + p] == 0x67) {

Ah, so: mars.c not mr97310a.c

You lost me, there, for a minute. Yes, this sequence is there.

Thanks,

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l (headers)

[Theodore Kilgore]

On Fri, 17 Apr 2009, Kyle Guinn wrote:

> On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:

<snip>

>>>>
>>>> But I have never seen the 0x64 0xX0 bytes used to count the frames.
>>>> Could you tell me how to repeat that? It certainly would knock down the
>>>> validity of the above table wouldn't it?


>>>
>>> I've modified libv4l to print out the 12-byte header before it skips over
>>> it.
>>
>> Good idea, and an obvious one. Why did I not think of that?


OK, below are some results for several cameras. They will agree, more or 
less, with what you get.

>>
>>> Then when I fire up mplayer it prints out each header as each frame is
>>> received.  The framerate is only about 5 fps so there isn't a ton of data
>>> to parse through.  When I point the camera into a light I get this (at
>>> 640x480):
>>>
>>> ...
>>> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 66 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 66 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 67 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 67 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 64 50 c1 5c c6 00 00
>>> ff ff 00 ff 96 64 d0 c1 5c c6 00 00
>>> ff ff 00 ff 96 65 50 c1 5c c6 00 00
>>> ...
>>
>> Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
>> it, too, because I also have one of them.
>>
>
> Yes, that's the one.  Try your others if you can and let me know what happens.


Some results follow now for various cameras. For some of them I have taken 
the trouble to give both 640x480 and 320x240 results. The one camera for 
which I have only given one result is a CIF camera for which we don't know 
how to do the decompression.

Some headers from the Aiptek Pencam VGA+ (0x08ca: 0x0111) at 640x480

Header:   ff ff 00 ff 96 64 d0 37 5a 27 48 91 
Header:   ff ff 00 ff 96 65 50 2c ce 1a 78 5d 
Header:   ff ff 00 ff 96 65 d0 1b 22 02 1a 4e 
Header:   ff ff 00 ff 96 66 50 0b b0 02 5c 01 
Header:   ff ff 00 ff 96 66 d0 0a 90 01 ec 09 
Header:   ff ff 00 ff 96 67 50 0b 81 02 7b fb 
Header:   ff ff 00 ff 96 67 d0 0c 64 01 ec 00 
Header:   ff ff 00 ff 96 64 50 0c 4e 02 fb f7 
Header:   ff ff 00 ff 96 64 d0 0c a3 02 eb f2 
Header:   ff ff 00 ff 96 65 50 0e c5 01 db d5 
Header:   ff ff 00 ff 96 65 d0 0f b3 03 8b bc 
Header:   ff ff 00 ff 96 66 50 10 03 03 ab bb 
Header:   ff ff 00 ff 96 66 d0 10 28 03 6b c0 
Header:   ff ff 00 ff 96 67 50 10 9a 03 5b b2 
Header:   ff ff 00 ff 96 67 d0 11 2a 03 eb 96 
Header:   ff ff 00 ff 96 64 50 11 54 03 fb 90 
Header:   ff ff 00 ff 96 64 d0 11 36 03 fb 92 
Header:   ff ff 00 ff 96 65 50 11 3c 03 fb 8f 
Header:   ff ff 00 ff 96 65 d0 11 41 04 4b 84 
Header:   ff ff 00 ff 96 66 50 11 5c 04 1b 84 
Header:   ff ff 00 ff 96 66 d0 11 69 04 3b 80 
Header:   ff ff 00 ff 96 67 50 11 75 03 fb 7e 
Header:   ff ff 00 ff 96 67 d0 10 b9 03 5b 90 
Header:   ff ff 00 ff 96 64 50 10 83 03 3b 98 
Header:   ff ff 00 ff 96 64 d0 11 0e 03 1b 99 
Header:   ff ff 00 ff 96 65 50 11 70 03 7b 92 
Header:   ff ff 00 ff 96 65 d0 11 68 03 1b a9 
Header:   ff ff 00 ff 96 66 50 11 1d 03 9b b2 
Header:   ff ff 00 ff 96 66 d0 10 e4 03 8b ba 
Header:   ff ff 00 ff 96 67 50 10 ad 03 2b cb

Some headers from the Aiptek Pencam VGA+ (0x08ca: 0x0111) at 320x240

Header:   ff ff 00 ff 96 64 d0 35 5f 2e 48 a9 
Header:   ff ff 00 ff 96 65 50 23 f4 11 e9 69 
Header:   ff ff 00 ff 96 65 d0 17 bf 0a 6b 1d 
Header:   ff ff 00 ff 96 66 50 18 31 0a 5b 11 
Header:   ff ff 00 ff 96 66 d0 1c df 0d aa 87 
Header:   ff ff 00 ff 96 67 50 19 71 09 aa db 
Header:   ff ff 00 ff 96 67 d0 12 6f 00 5b cf 
Header:   ff ff 00 ff 96 64 50 0c 46 01 1c 41 
Header:   ff ff 00 ff 96 64 d0 0e 48 02 5c 09 
Header:   ff ff 00 ff 96 65 50 0e cf 02 6b fd 
Header:   ff ff 00 ff 96 65 d0 0e 82 02 5c 05 
Header:   ff ff 00 ff 96 66 50 0e 45 02 5c 08 
Header:   ff ff 00 ff 96 66 d0 0e 94 02 6c 02 
Header:   ff ff 00 ff 96 67 50 0e 83 02 7b fd 
Header:   ff ff 00 ff 96 67 d0 0e 6f 02 7c 00 
Header:   ff ff 00 ff 96 64 50 0e 6e 02 7c 03 
Header:   ff ff 00 ff 96 64 d0 0e 61 02 4c 04 
Header:   ff ff 00 ff 96 65 50 0e 86 02 4c 00 
Header:   ff ff 00 ff 96 65 d0 0e e3 02 8b f2 
Header:   ff ff 00 ff 96 66 50 0f 62 02 fb e9 
Header:   ff ff 00 ff 96 66 d0 0e c2 02 ab f6 
Header:   ff ff 00 ff 96 67 50 0e 76 02 3c 07

Some headers from the "Ion Digital Camera" 0x093a:0x010f, at 640x480

Header:   ff ff 00 ff 96 64 d0 20 82 0c e9 af 
Header:   ff ff 00 ff 96 65 50 17 bd 00 a9 c6 
Header:   ff ff 00 ff 96 65 d0 11 90 00 1c 0c 
Header:   ff ff 00 ff 96 66 50 05 f7 00 7c 2b 
Header:   ff ff 00 ff 96 66 d0 07 4e 01 5c 17 
Header:   ff ff 00 ff 96 67 50 07 b9 01 8b fb 
Header:   ff ff 00 ff 96 67 d0 08 90 00 fc 05 
Header:   ff ff 00 ff 96 64 50 09 fc 00 db ef 
Header:   ff ff 00 ff 96 64 d0 0c e6 00 2c 05 
Header:   ff ff 00 ff 96 65 50 13 10 01 db 98 
Header:   ff ff 00 ff 96 65 d0 13 54 02 0b 82 
Header:   ff ff 00 ff 96 66 50 10 d2 02 8b b3 
Header:   ff ff 00 ff 96 66 d0 0c 46 01 7b e7 
Header:   ff ff 00 ff 96 67 50 07 1a 00 0c 5d 
Header:   ff ff 00 ff 96 67 d0 06 e4 00 0c 5f 
Header:   ff ff 00 ff 96 64 50 07 8b 00 0c 5f 
Header:   ff ff 00 ff 96 64 d0 08 60 00 0c 60 
Header:   ff ff 00 ff 96 65 50 08 fb 00 0c 60 
Header:   ff ff 00 ff 96 65 d0 09 0f 00 0c 60 
Header:   ff ff 00 ff 96 66 50 09 21 00 0c 60 
Header:   ff ff 00 ff 96 66 d0 0a f0 00 1c 40 
Header:   ff ff 00 ff 96 67 50 11 a4 00 8b e9 
Header:   ff ff 00 ff 96 67 d0 12 e2 00 0c 1c 
Header:   ff ff 00 ff 96 64 50 0c 41 01 5b e1 
Header:   ff ff 00 ff 96 64 d0 0b 72 01 2b ea 
Header:   ff ff 00 ff 96 65 50 09 67 01 2b f8 
Header:   ff ff 00 ff 96 65 d0 08 32 00 7c 08 
Header:   ff ff 00 ff 96 66 50 05 8e 00 0c 60 
Header:   ff ff 00 ff 96 66 d0 06 95 00 0c 4c 
Header:   ff ff 00 ff 96 67 50 09 95 00 1c 19 
Header:   ff ff 00 ff 96 67 d0 0a a2 00 0c 0f 
Header:   ff ff 00 ff 96 64 50 10 c2 00 5c 1a 
Header:   ff ff 00 ff 96 64 d0 10 ec 00 9b d2 
Header:   ff ff 00 ff 96 65 50 0f b4 00 eb bb 
Header:   ff ff 00 ff 96 65 d0 10 2b 01 9b 96 
Header:   ff ff 00 ff 96 66 50 0e 70 02 9b a3 
Header:   ff ff 00 ff 96 66 d0 0d 68 01 8b c2

Some headers from the "Ion Digital Camera" 0x093a:0x010f, at 320x240

Header:   ff ff 00 ff 96 64 d0 2f 56 1a c8 1a 
Header:   ff ff 00 ff 96 65 50 2e 55 17 38 9f 
Header:   ff ff 00 ff 96 65 d0 2d 61 11 e8 ed 
Header:   ff ff 00 ff 96 66 50 29 85 19 48 ff 
Header:   ff ff 00 ff 96 66 d0 29 ea 19 29 02 
Header:   ff ff 00 ff 96 67 50 28 fd 15 49 3f 
Header:   ff ff 00 ff 96 67 d0 28 40 10 c9 73 
Header:   ff ff 00 ff 96 64 50 26 8b 12 b9 6d 
Header:   ff ff 00 ff 96 64 d0 23 35 11 99 b6 
Header:   ff ff 00 ff 96 65 50 21 77 0f a9 f1 
Header:   ff ff 00 ff 96 65 d0 21 6f 10 b9 e7 
Header:   ff ff 00 ff 96 66 50 25 67 10 e9 af 
Header:   ff ff 00 ff 96 66 d0 28 97 14 c9 3a 
Header:   ff ff 00 ff 96 67 50 2b 64 16 e8 fe 
Header:   ff ff 00 ff 96 67 d0 2a 97 18 19 11 
Header:   ff ff 00 ff 96 64 50 27 99 18 89 3c 
Header:   ff ff 00 ff 96 64 d0 24 43 12 89 7f 
Header:   ff ff 00 ff 96 65 50 1f e8 0f 3a 11 
Header:   ff ff 00 ff 96 65 d0 1c e4 0c 3a 7c 
Header:   ff ff 00 ff 96 66 50 18 33 07 ba ed 
Header:   ff ff 00 ff 96 66 d0 15 d8 07 db 2a 
Header:   ff ff 00 ff 96 67 50 13 95 02 9b 7d 
Header:   ff ff 00 ff 96 67 d0 11 4a 02 4b 94 
Header:   ff ff 00 ff 96 64 50 18 8a 05 fa e6 
Header:   ff ff 00 ff 96 64 d0 20 25 0e ea 0f 
Header:   ff ff 00 ff 96 65 50 23 c7 0e 89 9d 
Header:   ff ff 00 ff 96 65 d0 1c 14 05 3a e4 
Header:   ff ff 00 ff 96 66 50 13 2b 03 1b 84 
Header:   ff ff 00 ff 96 66 d0 16 52 03 7b 33 
Header:   ff ff 00 ff 96 67 50 14 55 01 bb 44 
Header:   ff ff 00 ff 96 67 d0 0e 86 01 3b df 
Header:   ff ff 00 ff 96 64 50 0e 1a 00 fb de 
Header:   ff ff 00 ff 96 64 d0 0d 8d 01 8b dc 
Header:   ff ff 00 ff 96 65 50 0c e4 01 5b df 
Header:   ff ff 00 ff 96 65 d0 0c f2 01 7b d3 
Header:   ff ff 00 ff 96 66 50 0e 01 01 4b d0 
Header:   ff ff 00 ff 96 66 d0 11 1b 00 bb b7 
Header:   ff ff 00 ff 96 67 50 18 16 0b 9a a3 
Header:   ff ff 00 ff 96 67 d0 12 f5 03 4b 44 
Header:   ff ff 00 ff 96 64 50 0d a3 02 5b d4 
Header:   ff ff 00 ff 96 64 d0 11 70 02 9b 6e 
Header:   ff ff 00 ff 96 65 50 15 0f 09 ca db 
Header:   ff ff 00 ff 96 65 d0 0f 93 01 db a3 
Header:   ff ff 00 ff 96 66 50 0c 5b 02 3b eb 
Header:   ff ff 00 ff 96 66 d0 0c 17 01 db ee 
Header:   ff ff 00 ff 96 67 50 0b b3 01 db ee 
Header:   ff ff 00 ff 96 67 d0 0b 5b 01 fb ed 
Header:   ff ff 00 ff 96 64 50 0b d4 01 ab e3 
Header:   ff ff 00 ff 96 64 d0 0c 65 01 fb d8 
Header:   ff ff 00 ff 96 65 50 0c e7 02 3b d4 
Header:   ff ff 00 ff 96 65 d0 0c f9 02 4b d3 
Header:   ff ff 00 ff 96 66 50 0c ea 01 fb d9 
Header:   ff ff 00 ff 96 66 d0 0c d7 02 2b d5 
Header:   ff ff 00 ff 96 67 50 0c c5 02 4b d6 
Header:   ff ff 00 ff 96 67 d0 0d 07 01 fb d5 
Header:   ff ff 00 ff 96 64 50 0e 30 01 7b d1

Some headers from the "Sakar Digital" 0x093a:0x010f, at 640x480

Header:   ff ff 00 ff 96 64 d0 33 ad 24 38 5c 
Header:   ff ff 00 ff 96 65 50 30 a6 1d e7 86 
Header:   ff ff 00 ff 96 65 d0 21 5e 04 29 38 
Header:   ff ff 00 ff 96 66 50 0e aa 02 8b ad 
Header:   ff ff 00 ff 96 66 d0 0d a7 01 cb c8 
Header:   ff ff 00 ff 96 67 50 0f 5b 00 2b de 
Header:   ff ff 00 ff 96 67 d0 0f d8 04 eb 8a 
Header:   ff ff 00 ff 96 64 50 0f 6a 04 fb 8f 
Header:   ff ff 00 ff 96 64 d0 10 3a 03 eb 93 
Header:   ff ff 00 ff 96 65 50 10 e7 05 0b 7d 
Header:   ff ff 00 ff 96 65 d0 0f c9 02 1b b0 
Header:   ff ff 00 ff 96 66 50 16 26 05 db 38 
Header:   ff ff 00 ff 96 66 d0 16 c3 07 8b 1a 
Header:   ff ff 00 ff 96 67 50 15 66 07 8b 2f 
Header:   ff ff 00 ff 96 67 d0 13 a9 05 ab 64 
Header:   ff ff 00 ff 96 64 50 13 5b 07 0b 61 
Header:   ff ff 00 ff 96 64 d0 11 b9 05 bb 93 
Header:   ff ff 00 ff 96 65 50 10 66 05 0b aa 
Header:   ff ff 00 ff 96 65 d0 0e c5 05 eb af 
Header:   ff ff 00 ff 96 66 50 0c fc 04 8b ce 
Header:   ff ff 00 ff 96 66 d0 0c d0 04 8b ca 
Header:   ff ff 00 ff 96 67 50 0c a2 03 eb cf 
Header:   ff ff 00 ff 96 67 d0 0c 52 03 4b d2 
Header:   ff ff 00 ff 96 64 50 0d 04 03 7b cb 
Header:   ff ff 00 ff 96 64 d0 0d 64 03 bb c7 
Header:   ff ff 00 ff 96 65 50 0d 1d 03 0b d4 
Header:   ff ff 00 ff 96 65 d0 0c 52 01 9b ee 
Header:   ff ff 00 ff 96 66 50 0b eb 00 7c 07 
Header:   ff ff 00 ff 96 66 d0 0a eb 00 8b fa 
Header:   ff ff 00 ff 96 67 50 09 d5 00 9c 08 
Header:   ff ff 00 ff 96 67 d0 08 f7 00 6c 13 
Header:   ff ff 00 ff 96 64 50 08 8c 00 7c 11

Some headers from the "Sakar Digital" 0x093a:0x010f, at 320x240

Header:   ff ff 00 ff 96 64 d0 40 70 32 67 76 
Header:   ff ff 00 ff 96 65 50 36 93 21 67 b9 
Header:   ff ff 00 ff 96 65 d0 31 47 1f a8 89 
Header:   ff ff 00 ff 96 66 50 2a bb 1d f9 69 
Header:   ff ff 00 ff 96 66 d0 29 32 1b 29 7e 
Header:   ff ff 00 ff 96 67 50 29 33 18 c9 86 
Header:   ff ff 00 ff 96 67 d0 28 6e 17 99 a0 
Header:   ff ff 00 ff 96 64 50 29 0a 18 59 91 
Header:   ff ff 00 ff 96 64 d0 27 ed 17 99 a5 
Header:   ff ff 00 ff 96 65 50 24 38 14 5a 01 
Header:   ff ff 00 ff 96 65 d0 22 6a 13 5a 20 
Header:   ff ff 00 ff 96 66 50 1d f4 0e 1a 7f 
Header:   ff ff 00 ff 96 66 d0 18 2e 09 0a ef 
Header:   ff ff 00 ff 96 67 50 14 b2 07 0b 2e 
Header:   ff ff 00 ff 96 67 d0 15 4d 07 db 25 
Header:   ff ff 00 ff 96 64 50 17 f1 09 4a fa 
Header:   ff ff 00 ff 96 64 d0 23 a3 10 89 e8 
Header:   ff ff 00 ff 96 65 50 2d a9 17 98 e9 
Header:   ff ff 00 ff 96 65 d0 20 ab 0b ea 03 
Header:   ff ff 00 ff 96 66 50 18 9a 06 ca d1 
Header:   ff ff 00 ff 96 66 d0 1d 43 0f 1a 89 
Header:   ff ff 00 ff 96 67 50 1f 72 11 6a 40 
Header:   ff ff 00 ff 96 67 d0 1f c2 13 1a 5c 
Header:   ff ff 00 ff 96 64 50 1b 5f 0c ea 9f 
Header:   ff ff 00 ff 96 64 d0 18 3b 08 5a e6 
Header:   ff ff 00 ff 96 65 50 13 54 04 1b 73 
Header:   ff ff 00 ff 96 65 d0 11 90 03 eb 8d 
Header:   ff ff 00 ff 96 66 50 12 84 03 eb 8b 
Header:   ff ff 00 ff 96 66 d0 11 81 03 6b a1 
Header:   ff ff 00 ff 96 67 50 10 76 03 2b a2 
Header:   ff ff 00 ff 96 67 d0 16 5e 02 1a f8 
Header:   ff ff 00 ff 96 64 50 1b 4b 0d 4a c4 
Header:   ff ff 00 ff 96 64 d0 17 80 08 2b 0e 
Header:   ff ff 00 ff 96 65 50 10 fd 02 bb 93 
Header:   ff ff 00 ff 96 65 d0 0f bd 03 cb ae 
Header:   ff ff 00 ff 96 66 50 0f 2e 03 bb b1 
Header:   ff ff 00 ff 96 66 d0 0f 1e 03 bb b1 
Header:   ff ff 00 ff 96 67 50 0e 1f 03 4b b6 
Header:   ff ff 00 ff 96 67 d0 0e 9e 02 cb 9d 
Header:   ff ff 00 ff 96 64 50 0f 28 02 7b 9c 
Header:   ff ff 00 ff 96 64 d0 12 36 02 4b 74 
Header:   ff ff 00 ff 96 65 50 12 2f 03 eb 8b 
Header:   ff ff 00 ff 96 65 d0 0f fa 02 6b 9f

And last of all ...

Some headers from a Mars CIF camera (Innovage Mini Digital) 0x093a:0x010e
Dimensions were set at 352x288 (my current best guess). Compression unknown.

Header:   ff ff 00 ff 96 64 d0 00 0f 00 00 b6 
Header:   ff ff 00 ff 96 65 50 00 11 00 00 b6 
Header:   ff ff 00 ff 96 65 d0 00 13 00 00 b6 
Header:   ff ff 00 ff 96 66 50 00 12 00 00 b6 
Header:   ff ff 00 ff 96 66 d0 00 12 00 00 b6 
Header:   ff ff 00 ff 96 67 50 00 12 00 00 b6 
Header:   ff ff 00 ff 96 67 d0 00 12 00 00 b6 
Header:   ff ff 00 ff 96 64 50 00 10 00 00 b6 
Header:   ff ff 00 ff 96 64 d0 00 12 00 00 b6 
Header:   ff ff 00 ff 96 65 50 00 15 00 00 b6 
Header:   ff ff 00 ff 96 65 d0 00 15 00 00 b6 
Header:   ff ff 00 ff 96 66 50 00 0b 00 00 b6


One more comment comment about the 0x50 versus 0xd0 thing:

We do notice, of course, that 0xd0 = 0x50 | 0x80

and they occur alternately, with some degree of precision.

I probably ought to point out that something similar may be seen in the 
allocation table for these cameras, when they are used as still cameras. 
In libgphoto2/camlibs/mars (which supports these cameras in still mode) I 
wrote the file protocol.txt. Here, from that file, is a sample of an
allocation table and the entries in it:

0000  ff 00 ff 00 ff 00 ff 01-00 00 00 00 00 00 00 00
0010  08 00 04 00 0c b0 04 cc-86 13 9a 00 0c 2c 01 6c
0020  06 a6 bf 00 0c 2c 01 a4-88 39 e5 00 0c b0 04 66
0030  06 4c 7b 01 0c 2c 01 07-86 df a0 01 0c 2c 01 3f
0040  08 72 c6 01 0c b0 04 01-88 85 5c 02 0c b0 04 2b
0050  08 98 f2 02 0c b0 04 54-ff ff ff ff ff ff ff ff
0060  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff


Briefly, line 0 is simply a distinctive marker for the allocation table, 
playing a role similar to the SOF marker for the frames. Then lines 0010 
through 0050 give data about the photos. There are nine photos in the 
camera in this sample. When we reach byte 0x58 and begin repeating 0xff, 
we finished reading about these nine photos. Thus, each block of 8 bytes 
says something about a photo, until the repetition of 0xff begins. After 
this the rest of the configuration data is simply junk.

Let's rearrange the sample, throwing away the unhelpful line 0000 and also
terminating after byte 0x57:

photo   1       08 00 04 00 0c b0 04 cc
         2       86 13 9a 00 0c 2c 01 6c
         3       06 a6 bf 00 0c 2c 01 a4
         4       88 39 e5 00 0c b0 04 66
         5       06 4c 7b 01 0c 2c 01 07
         6       86 df a0 01 0c 2c 01 3f
         7       08 72 c6 01 0c b0 04 01
         8       88 85 5c 02 0c b0 04 2b
         9       08 98 f2 02 0c b0 04 54

For each photo, byte 0 of its entry is a code for its size and 
compression. Or, rather, its lower nibble does that. Observe that the 
higher nibble is either 0 or 8, depending on position. Perhaps something 
analogous is occurring here, and there is no particular significance at 
all for the fluctuation between 0x50 and 0xd0, except that in this case it 
probably would make it really easy to spot a dropped frame.

Oh, BTW, I was not always pointing the cameras at a bright light, which 
could make some difference about those bytes at the end of the header.

Theodore Kilgore

Re: RFC on proposed patches to mr97310a.c for gspca and v4l (headers)

[Theodore Kilgore]

Replying to myself:

Apologies that copying using the Cntrl-R option (read file) in pine made 
such a mess of the formatting. This was really a mess when I got a copy 
back again. Sorry, each header _was_ on a separate line :-/



>
> Header:   ff ff 00 ff 96 64 d0 37 5a 27 48 91 Header:   ff ff 00 ff 96 65 50 
> 2c ce 1a 78 5d Header:   ff ff 00 ff 96 65 d0 1b 22 02 1a 4e Header:   ff ff 
> 00 ff 96 66 50 0b b0 02 5c 01 Header:   ff ff 00 ff 96 66 d0 0a 90 01 ec 09 
> Header:   ff ff 00 ff 96 67 50 0b 81 02 7b fb Header:   ff ff 00 ff 96 67 d0 
> 0c 64 01 ec 00 Header:   ff ff 00 ff 96 64 50 0c 4e 02 fb f7 Header:   ff ff 
> 00 ff 96 64 d0 0c a3 02 eb f2 Header:   ff ff 00 ff 96 65 50 0e c5 01 db d5

...

and so on...


Theodore Kilgore

Progress with the MR97310A "CIF" cameras

[Theodore Kilgore]

by which I am referring to the cameras with ID 0x093a:0x010e :

At first it seemed to me that these cameras were using a 
different compression algorithm, because the current code in 
gspca/mr97310a.c failed to produce viewable frames while streaming, only 
junk.

However, the above seems not to be true. I finally got an old Win2k box 
going again, installed the driver, and got a sniff of the initialization 
sequence. It is quite different from the one which is in use for the 
larger cameras. But only the initialization is different, not the 
compression.

At this point I can definitely say that replacement of the initialization 
sequence in the existing sd_start() function in gspca/mr97310a.c by the 
initialization sequence which I got from the sniff log seems to make the 
test camera to run just fine.

What is still left to do is to see what comes out of the Elta camera which 
you (Thomas) are supposed to receive in the mail. For, interestingly, not 
all of these cameras seem to be doing the same thing. I have tested at 
least two others, on the Win2k machine, and they do not stream at all. Or, 
rather, they will go through the motions but the entire streaming 
activity, according to the log file, is to send repetitions of the SOF 
marker and frame header until one gets tired and quits. It may be that the 
init sequence for those two cameras is still a different one, and I do not 
have the old driver CDs because I thought they all have to be identical. 
Or perhaps they were never intended to stream.


In any event, one of the cameras is working now, an Innovage Mini Digital 
Camera. The Philips Digital Keychain camera will not stream, and neither 
will the Vivitar Mini. Since the Vivitar Mini does not support compression 
of still photos at all, it may be that it simply does not have the 
firmware to do the compression. The Philips camera, however, is a 
surprise.

I look forward with anticipation to learn what the initialization sequence 
is from the Elta camera, since we already have testimony that it will do 
streaming.

Then I guess I get busy rewriting the mr97310a.c code so that it will 
support the two different kinds of cameras ...

Thomas, sorry that we do not have a world to conquer in regard to a 
decompression algorithm. But it seems that this time we do not.

Theodore Kilgore

Preliminary results with an SN9C2028 camera

[Theodore Kilgore]

I decided recently to work on support for the SN9C2028 dual-mode cameras, 
which are supported as still cameras in libgphoto2/camlibs/sonix. Today, I 
succeeded in getting three frames out of one of them, using svv -gr, and I 
was able to convert two of the three frames to nice images using the same 
decompression algorithm which is used for the cameras in stillcam mode.

There is a lot of work to do yet: support for all appropriate resolution 
settings (which are what? I do not yet know), support for all known 
cameras for which I can chase down an owner, and incorporation of the 
decompression code in libv4l.

However, I thought you might like to know that some success has been 
achieved.

As regards "all known cameras" I have tried unsuccessfully to contact the 
owner of a Genius Smart 300. It is sold in Europe, not over here, and the 
only person I know who had one has not answered my request for further 
information. I suspect the reason for that is his old e-mail is no longer 
valid; he was a student from Armenia studying in Switzerland and may have 
gone home now. So, I ask the question of the list. Does anyone know an 
owner of a Genius Smart 300 and can get for me a USB snoop of it starting 
up to do streaming?

Theodore Kilgore

Re: Preliminary results with an SN9C2028 camera

[Hans de Goede]

On 05/16/2009 12:31 AM, Theodore Kilgore wrote:
>
> I decided recently to work on support for the SN9C2028 dual-mode
> cameras, which are supported as still cameras in
> libgphoto2/camlibs/sonix. Today, I succeeded in getting three frames out
> of one of them, using svv -gr, and I was able to convert two of the
> three frames to nice images using the same decompression algorithm which
> is used for the cameras in stillcam mode.
>
> There is a lot of work to do yet: support for all appropriate resolution
> settings (which are what? I do not yet know), support for all known
> cameras for which I can chase down an owner, and incorporation of the
> decompression code in libv4l.
>
> However, I thought you might like to know that some success has been
> achieved.
>

Cool!

I recently got a vivitar mini digital camera, usb id 093a 010e,
CD302N according to gphoto, which also is a dual mode camera. It would
be nice to get the webcam mode on this one supported too. Do you know
if there has already been some base work done on that ?

Regards,

Hans

Re: Preliminary results with an SN9C2028 camera

[Theodore Kilgore]

On Tue, 19 May 2009, Hans de Goede wrote:

>
>
> On 05/16/2009 12:31 AM, Theodore Kilgore wrote:
>> 
>> I decided recently to work on support for the SN9C2028 dual-mode
>> cameras, which are supported as still cameras in
>> libgphoto2/camlibs/sonix. Today, I succeeded in getting three frames out
>> of one of them, using svv -gr, and I was able to convert two of the
>> three frames to nice images using the same decompression algorithm which
>> is used for the cameras in stillcam mode.
>> 
>> There is a lot of work to do yet: support for all appropriate resolution
>> settings (which are what? I do not yet know), support for all known
>> cameras for which I can chase down an owner, and incorporation of the
>> decompression code in libv4l.
>> 
>> However, I thought you might like to know that some success has been
>> achieved.
>> 
>
> Cool!
>
> I recently got a vivitar mini digital camera, usb id 093a 010e,
> CD302N according to gphoto, which also is a dual mode camera. It would
> be nice to get the webcam mode on this one supported too. Do you know
> if there has already been some base work done on that ?


Hans,

Yes, I have been working on that, with some success. Here is an account:

These cameras are MR97310a cameras, specifically the "CIF" variety. They 
will stream at max resolution 352x288, and then at 320x240, 176x144, and 
160x120. I thought at first they are using a different compression 
algorithm from those which are supported currently in gspca/mr97310.c but 
I was mistaken about that. In fact, the compression algorithm is the same 
(so that no code changes in libv4lconvert are required in order to support 
them) but the initialization sequence is quite a bit different.


I succeeded in getting what seemed like a sufficient number of log files 
to be able to put together init sequences which work. I have a preliminary 
version of the code, which works for me with several of the 0x010e cameras 
that I own. Right now, Thomas Kaiser got one of these cameras recently 
(there was some discussion about this a couple of weeks ago, here on the 
list). Someone wrote in to the list and offered one of the cameras for 
testing. I responded and said it should be sent to one of the three people 
who are interested: Kyle Guinn, who wrote the mr97310a.c code, Thomas 
Kaiser, who had some interest in the decompression algorithms, or myself. 
The camera ended up going to Thomas.

About the same time, I sent my code to Thomas. Basically, what I have done 
is to write a replacement for mr97310a.c which supports these cameras in 
addition to the current ones. I hope that we have a report of his testing 
soon. Since you now have one of these cameras, would you like for me to 
send a copy to you, too?

I should mention there are several reasons why I did not feel ready to 
post a formal code patch:

1. The initialization sequences (register writes) seem to be variable from 
one session to another, and they can be influenced on the Windows 
streaming program that I am using, by such things as changing brightness, 
color balance, gamma setting, and so forth, from controls in the Windows 
program. In other words, it is feasible for various controls to talk to 
these cameras (presumably all mr97310a cameras). I was hoping that Thomas 
may know more about such things. Perhaps you do, too?

2. I have one of these "CIF" cameras which will neither stream on Linux 
nor on Windows. It goes throught all of the motions, and a "stream" 
starts. But inspection of the contents of the "stream" shows it consists 
of nothing but sucessive repetitions of the image header. I have tried to 
chase down comments about this camera (Vivitar Mini Digital Camera) 
through Google. It seems that many have had this problem; perhaps some of 
these particular cameras contained buggy hardware.

3. I have another camera (one of the 0x010f "VGA" cameras) which is 
supposed to stream but refuses to supply data across the isoc endpoint. 
Probably this is also a hardware problem. It does not work in Windows, 
either, even though it is supposed to. Perhaps it has merely suffered from 
old age or ill treatment years ago by its owner (me).


So, as I said, I am perfectly willing to send along my code privately, and 
you can have some fun, too, and perhaps you can help me figure out some of 
the remaining issues. This offer, incidentally, is also valid for anyone 
else on this list who has one of these cameras. Just ask.


Theodore Kilgore